Claude Haiku 5.5 の登場を機に、Sonnet 以下のモデルで動かしていたサブエージェントの構成を見直した記事。Haiku 5.5 は Haiku シリーズで初めて effort 指定に対応し、単価は Haiku 4.5 の 1/10 になっている。Opus 5.5 / Sonnet 5.5 / Haiku 4.5 などの input・output 料金を Sonnet 比で比較しつつ、サブエージェントをどのモデルに割り当てるかを検討している。
生成AIにウェブページから情報を抽出させる際、「値がなければnullを使い推測しないこと」と指示するだけで、存在しない値を作り出す割合が70.7％から20.2％に低下したという実験結果が公開された。プロンプトに明示的な「不明時はnull」ルールを入れることが、抽出タスクのハルシネーション抑制に効くことを示す数字。
IDCは、AIエージェントの普及に伴う「SaaS終焉論」を分析したレポートを公開した。AIはSaaSを代替するのではなくデータモデルを拡張すると指摘し、市場ごとの浸透格差や成果型課金の急増など、本当に起こる構造変化を解説している。
育児記録の入力を負担に感じる声を踏まえ、iPhone内で動くAIを使い、話した内容から授乳やおむつの記録を自動で項目分けするアプリ設計を検討した記事。
TypeSafe AIが公開した「System One Model」ことJevを実際に試した記事。JevはLLMのように文章を生成せず、こちらが型付きで用意した問いに対して確率やスコアのみを返す点が特徴で、単体では何も起きず、返ってきた数値をどう扱うかは呼び出し側のコードが決める設計になっている。著者は社内問い合わせのエスカレーション先を判定できるかを題材に、バックエンドエンジニアの視点で挙動を確認している。
Sysdig の調査によれば、AI は実験段階からインフラへと移行しつつあり、自前のインフラを構築する組織が増えたことで AI の攻撃対象領域が縮小しているという。
2026年に登場した TypeSafe AI のモデル「Jev」を題材に、AIエージェントを支えるハーネスの設計がどう変わるかを整理した記事。Jev は文章やコードを長く生成する LLM ではなく、ソフトウェア内で発生する判断を高速に処理するためのモデルとして設計されており、「unstructured state in, typed probabilistic decisions out」、つまり状態を入力すると型付きの確率的な判断を返す点を特徴とする。
Claude Codeが起動時に読み込む記憶の仕組みを、公式ドキュメントと実測をもとに整理。CLAUDE.md・@取り込み・自動メモリの3経路、特に@取り込みの実際の挙動と、大きなプロジェクトの記憶を効率よく読ませる設計パターンを紹介している。
個人 AI アシスタント向けの長期記憶レイヤー。会話ログを要約せず 7 フィールドのレコードとして日次 JSONL に全文保存し、生ログを唯一の真実の源とする。全レコードにタイムスタンプを付与し、SQLite FTS5（日英バイグラム）による完全一致検索と sqlite-vec による意味検索を組み合わせるが、まず時間式（相対・絶対日付）を解析して範囲を絞り、範囲内の結果を時系列順に返す。意味検索は範囲内で結果が少ないときの最後の手段で、フォールバックした事実も出力に明示する。さらに現在の話題を示す小型インデックス LLL を毎ターン文脈に注入し、コンテキスト圧縮やセッション境界をまたいで同一性と文脈を維持する。ローカル・ファイルベース・単一マシン・サーバーなしで、1 ユーザー向けに毎日運用した記録と失敗談も docs/lessons.md に公開している。
OpenAIのVinoth Govindarajanが、モデルのハルシネーション以外で本番AIエージェントが失敗する理由を論じる。OpenClawなどの実例を通し、信頼性の高いエージェントハーネスの鍵となる原則を説明する。すなわち、明示的な状態所有権の確立、並行する状態変更の直列化、実行権限のスコープ設定、ユーザー可視の境界でのアクション検証である。
Claude や Codex/ChatGPT、Gemini はコーディングや調査には便利だが、文章作成に使うべきではないという主張。文章を書くこと自体が深く考える工程であり、箇条書きから AI に文書を生成させるとその思考を飛ばしてしまう。AI は文章は得意でも、新しいアイデアを考え出すのは苦手だと指摘する。初稿を書いた後に「この文書を読んでどんな疑問を持つか」「最も重要な点は何か」と質問してフィードバックを得る使い方は有効で、修正や改善を任せるのではなく自分で考えるべきとする。執筆前のデータ整理やパターン発見にも AI は役立つ。
判断特化型AI「Jev」の特徴を具体例で解説。アカウント作成から Playground の使い方まで紹介し、文章に個人情報が含まれるかを実際に判定。従来の LLM と比べた料金や応答速度の違いにも触れる。
Slackの案件スレッドをClaude Coworkに読み込ませ、提案書スライドの作成を3〜5時間から35分へ短縮した運用事例。コンテキスト管理、スライド自動生成、実装手順までを、プリセールス業務をAIに任せる仕組みとして紹介している。
近年のAIモデル発表はパラメータ数やベンチマーク、推論速度を競うLLMの新バージョンが中心となっているが、本記事は文字列生成を捨てたというTypeSafe AI「Jev」を取り上げ、LLMとは異なるアーキテクチャのAIがなぜその設計を選んだのかを解説する。
文章生成ではなく高速な「判断」の出力に特化したAIモデル Jev のクイックスタート。基本構造は State → Questions → Typed Decisions で、状態と質問を渡すと型付きの確率的な判断を返す。複数の質問を並列評価できる設計で高速化を実現しており、判断の型として Choice・Score・Noul の3種類を用いて質問を定義する。
LinkedIn が大規模コードベースにおける AI エージェントの限界を克服するため、Model Context Protocol（MCP）を基盤に、手順的記憶・コード検索・ランブックを coding agent に直接提供する Contextual Agent Playbooks and Tools を構築した事例。アーキテクチャの詳細と運用上のガードレールを紹介し、信頼性を損なわずに 20% の生産性向上を実現したと述べている。
AIがコードを書く時代には、実行時オーバーヘッドがなく可搬性の高いC言語が再び主流になるというSNS上の言説を検証する記事。高水準言語は人間の生産性のために性能を犠牲にしてきた、AIはメモリ管理を誤らない、安全性はAI自身が検証できる、といった前提を一次資料に当たりながら一つずつ検討している。
GitHub Podcast のエピソードをもとに、AI に関するよくある「過激な主張（ホットテイク）」を噛み砕いて検討する内容。①AI 生成コードも読むべきで、リスクの高い箇所に応じてレビューの深さを変え、説明と責任を持てるまで確認するのが実際のスキルであること、②採用では AI を使うか否かより、いつ使い・どうレビューし・どこで人を介在させるかという判断力が問われること、③Skills は MCP を置き換えるものではなく、MCP がツールやデータへの標準的なアクセスを提供し、Skills がプロセスや規約といった文脈をパッケージ化するもので、両者は補完関係にあること、④RAG は廃れたわけではなく、モデル外部の知識を取り込む手段として依然重要であり、検索が不十分だとトークン浪費や回答の不完全さを招くこと、などを議論している。
コーディングエージェントの性能を左右するハーネス設計を、計画・行動空間・コンテキスト管理の3要素に分解して実証的に比較した論文。SWE-Bench Verified と Terminal-Bench 2.1 で4モデル・176設定を評価し、コンテキスト管理は予算が厳しいほど有効で、主な効果はオーバーフロー防止にあること、LLM要約の前にルールベースの省略を行うのが最も効率的であること、計画は弱いモデルでは精度の足場、強いモデルではコスト削減になること、bashに強いモデルはbashのみのインターフェースでも低コストで動けることなどを報告している。
Jev に触発された OpenJev の実装を読み比べ、既存モデルの点数を直接読む方式と、判断用に学習し直す方式の違いを整理した記事。生成しない AI の代替設計を考える内容。
エージェントはゲームの一発生成や大規模なマイグレーションをこなせるようになったが、実際のソフトウェア開発の大部分は依然として人間のエンジニアが主導している。多くの組織が大量のトークンをエージェントに投じたものの成果は芳しくなく、幻滅期に入っている。次の段階では、エンジニアの価値は「良いアイデアを出すこと」と「適切なアーキテクチャを設計すること」に移り、バグの検出と修正、本番エラーのデバッグとパッチ適用、エージェント用プロンプトの最適化、フロントエンドの一貫性維持といった作業はエージェントに任せるべき領域として挙げられる。そのためにはループやガードレール、評価基盤など新しいプリミティブの整備が必要になる。
Jevは文章や業務データを読み取り、分類・採点・条件判定の結果を確率付きで返すAIモデル。返り値はソフトウェアの条件分岐に利用することを想定しており、プログラムが明確に判定して複雑な制御に応用できる点が特徴。本記事はJevの概要を、従来型LLMやAIエージェントとの違いという観点から整理して解説する。
AIがコードを書くようになり「認知負債」が課題として認識されつつある一方、そもそも人間が全てを認知すべきなのかという議論もある。本記事は「技術的負債に向き合うConference 2026」の聴講を踏まえ、認知負債を「仕組みを人間が認知しないまま稼働しているコードが存在すること」と定義し、その問題点を考察する。
AIエージェントに改善を繰り返させても、プロンプトの加筆や出力の整形に留まり、最初の設計を見直せず停滞することがある。本資料では、業務AIワークフローの構築・改善で経験した課題と関連研究をもとに、深層学習の訓練ループとの対応を手がかりとして、自己改善を支えるハーネスの設計を解説する。
筆者が約1年半にわたり個人の開発で育ててきたAI開発フローについて、Claude Codeを実務に取り入れ、サブエージェントによる思考レビューなど試行錯誤を経て現在の形に至るまでの変化を紹介する。
データ基盤チームが、定型の分析依頼への対応フローをAIエージェント前提に組み替えるPoCを紹介。AIに自由にSQLを書かせると結合キーの取り違えや指標定義の揺れで「それっぽい数字」が返るため、集計ロジックはdbtのymlに定義したセマンティックレイヤー（Lightdash）に委ね、AIには仕様書の解釈と言葉と定義の橋渡しだけを任せる構成にした。LightdashはOSS版をAWS上にセルフホストし、REST APIを叩く自作MCPサーバー経由でAIからexplore・チャート作成を操作する。選定理由、セマンティックレイヤーがガードレールになる仕組み、定義が網羅できない部分を補うcustomの口と昇格ループ、現時点の運用状況と展望を述べる。
Claude Code などのコーディングエージェントにより一人でフロントから運用まで組めるようになった一方、ハッカソンで最初に悩んだのは「何を作るか」だった。AIハッカソンで優勝した経験を基に、アイデアの出し方を述べる記事。
OpenSpec はソフトウェア仕様の作成・管理のための軽量で設定可能なフレームワーク。作りたいものを spec として記述し、チームとコーディングエージェントの認識を揃えながら、要件の洗練、仕様が正しい対象を記述しているかの検証、実装が仕様に一致するかの確認を行う。Claude Code、Codex、Cursor、GitHub Copilot、Gemini CLI など多数のツールと互換で、explore / propose / apply / verify / archive というワークフローコマンドを提供する。
生成AIを業務に組み込む際、生成→評価→実行の流れでは、実行しないと評価情報が得られない処理に対応できない。実行を段階的に許可し、何を観測し、その結果から次の実行範囲をどう判断するかというHuman-in-the-loopのゲート設計の必要性を論じている。
業務・完了条件・役割・受け渡し・並列化・検収・自律度・学びの蓄積を一続きで扱う、マルチエージェントによるAI開発チームの設計書。図解に加え、TypeScript製タスク管理アプリへの機能追加をCodexの実装と既設のClaudeレビューCIで実走し、仕様・差分・テスト・AIレビューをつなぐ方法を示す。並列構成の提案や未計測の効果は実走の結果と区別して扱っている。
個人開発の記録ツールにLLMでWikiを書かせる取り組みを半年続けた経験談。RSSリーダーやクリップ、バレットジャーナルなどに溜まった記録を活用するため、全文検索やタグ付けだけでなくLLMによるWiki生成を試したが、最も役立った画面はLLMが生成した文章をそのまま使うものではなかったという内容。
シンプレクスが全社展開する「AI-Native Delivery」の取り組みの一環として、開発ライフサイクル全体（要求整理・設計・実装・テスト・運用）を人間とAIの役割から再設計するAI-DLCの導入により、チームの開発プロセスがどう変わり始めたかをエンジニアが報告する記事。
Claude Code や Antigravity などの AI エージェントを使ったスポーツ予測・分析システム開発（270コミット、73 PR）で発行された延べ542件のプロンプトを調査し、指示の出し方と事前調査の有無が手戻り・バグ・CI/CDエラー・トークン消費に与えた影響を5パターンに分類した分析レポート。①明確・迅速完結型(51.1%)、②不明瞭・確認過多型(20.5%)、③不明瞭・バグ誘発型(16.6%)、④リファレンス不足によるCI/CDエラー型(10.3%)、⑤指示は明確だがAI側の影響範囲確認不足型(1.5%)。プロンプト改善で減らせる問題(③④)とAI側の検証ルールで防ぐべき問題(⑤)を区別すべきとし、プロジェクトのゴール定義や作業環境（モバイルかPCか）も成果に影響すると指摘している。
自作の Claude Code スキル47本を1ヶ月ほど運用して測定した記録。スキルは入れるだけなら簡単だが、数を増やすほど呼ばれなくなるという結果が得られたという。重くなるからではなく、登録したスキルの説明文が互いに競合し合うことが原因だと述べている。スキル設計・運用の知見を7つの観点でまとめている。
バイブコーディングで複雑化し制御不能になった GUI アプリに対し、AI へそのまま渡せる対策プロンプトを提示する記事。全コンポーネントを Root 配下に置き、各コンポーネントを MVP パターンの Passive View として描画パラメータのみ操作させ、動作は Chain of Responsibility でイベントをバブリングしてステートマシンとして振る舞う Mediator に裁定させる、という構造を指示する。macOS 常駐型 AI アシスタント「CooSenpAI」の開発経験を踏まえた内容。
ローカルでAIを動かした場合にPC購入費用や利用量から何年で元が取れるかを試算できるサイト「Sunk Cost」が公開された。費用の回収期間だけでなく、そのマシンに収まるAIモデル、生成速度、クラウドモデルとの能力比較も合わせて確認できる。本文はリンク中心の短い紹介記事で、具体的な試算結果や手法の詳細は示されていない。
Claude Code の `/goal` コマンドは、与えた条件を別のモデルが評価者として判定し、満たされるまでループを回す仕組み。本記事では終了条件の書き方によって評価者が正しく判定できるかを、7 通りの条件で検証した結果を報告している。
Yahoo!検索のフロントエンドエンジニアが、個人で使っていた Coding Agent による開発自動化をチーム全体の取り組みへ広げるまでの実践を紹介する記事。エージェント導入の進め方やチーム展開の工夫が語られている。
全28回のDevOps実践連載の振り返りとして、Git/GitHubによる開発基盤、DockerとGitHub ActionsのCI/CD、EKSとTerraformのIaC、CloudWatchによる監視、AWS BudgetsやGuardDuty/Security Hubによるフィードバックまでを総括。そのうえで「AIがコードやインフラ定義を生成するならDevOpsは不要か」という問いに対し、SRE・GitOps・プラットフォームエンジニアリング・AIOpsはDevOpsを置き換えたものではなく進化形だと整理し、AI時代に変わるもの（定型コード生成やログ解析の一次切り分けの自動化など）と変わらないものを論じる。
Difyの開発元LangGeniusの日本法人、パーソルクロステクノロジー、JTPの3社が、Difyエンジニアの育成と企業現場でのAIエージェント導入・内製化支援を共同で開始すると発表した。パーソルクロステクノロジーが人材基盤から候補者を選出し、JTPがDify導入・運用の研修を実施、今後100名の育成を目指す。背景には、現場の業務知識とAIアプリケーションの開発・運用知識を併せ持つ人材の不足があり、ツール導入後の継続的な改善・運用を担う人材と体制の整備が課題だとしている。ただし研修期間や内容、認定の仕組みなどの具体は未公表で、実態は人材派遣・SES事業の延長線上にある。
AIエージェントの文脈で頻出する「オントロジー」について解説した記事。元は哲学の存在論だが、現在はAIエージェントが理解・共有できる形式の設計図として解釈されることが多い。オントロジーとは何か、なぜAI駆動開発に必要なのかを説明している。
Meta の個人向け AI エージェント Muse の実行基盤をブラックボックス的に調査した記事。著者のセッションで subagent.spawn を使い 120 個のサブエージェントを一斉起動したところ、33 個だけが生成に成功し 87 個が同一のデータベースエラーで失敗、集約結果は返らず親は running のままなのに子 33 個はすべて completed として永続化される不整合が観測された。ランタイムが PostgreSQL に書き残した agent.agents や agent.subagent_spawns、進捗テーブル、コンテキストストアといった記録から、サブエージェントのファンアウト、永続状態、負荷時の spawn 経路を再構成している。モデル文字列 ipnext/avocado-5.16-v4 などの観測事実と推測の区別、アクセス範囲の限定も明記される。
Intigriti の研究者が DEF CON 34 の Bug Bounty Village で、AI カスタマーサポートエージェントを悪用する攻撃手法を発表した。チャットのトランスクリプト送信機能を釣りメールの配信に使う、From ヘッダのなりすましでエージェントに被害者からのメールと誤認させる、CC に攻撃者のアドレスを入れてツール呼び出しの機密応答を窃取する、RFC 822 が複数の From ヘッダを許すことを突いてメール認証を回避する、といった手口が紹介され、Burp Suite などのスキャナを使わず数週末で 5 万ドル以上の報奨金を得たという。エージェントの権限検証とツール呼び出しの設計上の弱点が主題。
筆者は、ClaudeというLLMが指示に反して矛盾を含む行動を繰り返すことを批判している。コード生成や文書作成などのタスクにおいて、指定された内容よりも相反する情報を挿入したり、不要な機能を追加したりする傾向がある。これによりユーザが自身の最初の要望通りに進めることが難しくなっている。筆者はこの行動がClaudeのトレーニング設計に起因し、ヒトを無知だと見なしている可能性を指摘している。
Nari Labs が、音声 AI 評価企業 Coval のベンチマークで公開されている Qwen3-ASR Fast と Qwen3-TTS Fast が品質・レイテンシ・コストのパレートフロンティア上にあると主張する記事。STT は TTFS 中央値 44ms・WER 3.6% でレイテンシ 1 位、TTS は TTFA 中央値 63ms・WER 3.8% でレイテンシ 2 位・精度 1 位とし、価格は STT が $0.12/時間、TTS が $10/100万文字で最安級だと述べる。ただし具体的な推論基盤や高速化手法の説明はなく、主にベンチマーク順位と料金の比較に終始している。
Linux Foundation傘下のAgentic AI Foundation（AAIF）は、オープンソースのEnvoy AI GatewayプロジェクトがAAIFに加盟し、「Agent Router」へ名称変更したと発表した。OpenAIやAnthropicなどAIベンダごとに異なるAPIを吸収・統合し、MCPやAGENTS.md、Agent2AgentプロトコルなどAIエージェント関連技術の標準化を進める狙い。
基盤モデルの仕組みと、その技術スタックがどう進化してきたか、実システムに適用したときのトレードオフを扱う技術書の紹介。対象読者は、API 利用の表面的な理解を超えて、アーキテクチャ、学習パイプライン、推論システム、検索スタック、評価ループ、エージェント的ワークフローのmental model を築きたい AI エンジニアや研究志向の読者。attention、MoE、RLHF、マルチモーダル、長文脈の推論配信、RAG、エージェントといった話題を、歴史的流れ・数理的アイデア・システム制約の観点から一つのエンジニアリングの物語として結びつけることを狙う。PyTorch の概念的なサンプルコード、小テスト、対話的な可視化を含み、品質・メモリ・スループット・レイテンシ・スケーリング・アラインメントのトレードオフを考える力を養う。初学者向けの入門書ではなく、継続的に更新される living document として運用される。
Web アプリ向けの必須 UI トランジション（カードリサイズ、数値のポップイン、モーダル開閉、タブのスライド、スケルトンローダーなど）を集めたコレクション。コピー＆ペーストで使えるほか、coding agent から skill 経由で利用できる形で提供されている。各トランジションには動きの説明が付き、Pro 版や微調整ツールも用意されている。
AWS が、セキュリティ分野における AI の信頼性を測る Deception Benchmark を公開。14,822 サンプル、16 言語、70 以上の CWE カテゴリを対象に、実際の脆弱性と、脆弱に見えても緩和策で悪用不可能なコードをモデルが区別できるかを評価する。標準プロンプトでの適合率は 50% 台半ばにとどまり、スキャフォールディングを排してコード理解そのものを測る点が特徴。
Claude Code on Bedrock の auto mode を起動時デフォルトに設定した際の挙動を、対応モデルと非対応モデルで比較した記事。具体的な設定方法や差分の詳細にはほとんど触れておらず、挙動が分かれるという結果の報告にとどまる。