【geek-terminalニュース】Agent基盤論の最新情報

【事象の全貌と背景】
以前お伝えした2026年7月21日のコードハーネス論の続報です。前回はAIコーディングにおける検索、ルール、hooks、権限、監査ログの話が中心でしたが、今回はコーディング限定ではありません。業務AIエージェント全般で、勝敗の焦点がモデル名からAgent Harness、つまりモデルを囲む実行制御層へ移っている、という話です。

ここでいうハーネスは、単にLangChainやCrewAIのようなフレームワーク名を指す言葉ではありません。モデルにどのツールを使わせるか、どのデータを読ませるか、どこで人間承認を挟むか、失敗したらリトライするのかロールバックするのか、全手順を後から追えるログとして残すのか、という運用の骨格そのものです。検索結果1の論調では、エージェントの性能や信頼性はモデル単体では説明できず、実行制御、権限、記憶、検証、失敗時処理まで含めたソフトウェアとして見るべきだ、という整理が出ています。ただし、これはコミュニティや実務者記事側の問題提起であり、個別フレームワークの優劣を公式事実として断定するものではありません。

公式・研究系の裏付けとして重要なのは、エージェント評価の側でも同じ分解が始まっている点です。arXivの「Coding Benchmarks Are Misaligned with Agentic Software Engineering」は、従来のコーディングベンチマークがモデル、ハーネス、環境を単一のエンドツーエンド点数に畳み込んでしまい、エージェント的ソフトウェア工学の評価として不整合があると指摘しています。つまり、点数が高い低いの裏で、モデルが強いのか、コンテキスト供給がうまいのか、ツール実行環境が強いのか、検証ループが効いているのかが見えない。この問題意識は、今回のAgent基盤論を研究側からも支える事実です。

【技術的ディープダイブ】
Agent Harnessを技術的に分解すると、少なくとも6つの層があります。第一に、モデルへ渡すコンテキストを選ぶ検索・記憶層。第二に、ツール、API、DB、CRM、S3、社内ファイルストアなどへのアクセスを制御する権限層。第三に、ワークフロー状態を保持して、どのエージェントがどの順序で何をするかを決めるオーケストレーション層。第四に、失敗時のリトライ、キャンセル、ロールバック、代替経路を扱う回復層。第五に、取り出したチャンク、呼び出したツール、読んだデータ、支出、リトライ回数を記録する観測性と監査ログ層。第六に、最終判断をモデルに丸投げせず、決定的コードで検証・制約・証跡要求を担う評価層です。

研究面では、CyberGym-E2EがClaude Code、OpenAI Codex、Gemini CLI、OpenHandsという4種類のエージェントハーネスを評価対象にしており、それぞれが異なるインターフェースと相互作用パターンを持つことを明示しています。これは、同じタスクでもモデル名だけでは比較できず、ハーネスの設計差そのものが評価対象になることを示す強い材料です。

さらにFlashRTの論文では、リアルタイム・マルチモーダル応用向けのagent harnessが提案されています。音声エージェントやインタラクティブ動画生成のように、複数の異種モデルをパイプラインとして組み合わせる用途では、単一LLMの呼び出し速度だけでなく、配置、ストリーミング、モデル内並列化、データ依存関係、永続状態スコープまで設計対象になります。FlashRTはchain-of-programパラダイムを用い、汎用コーディングエージェントに参照実装を中間表現へ変換させ、逐次インタプリタで検証し、静的解析で変換候補を特定するとされています。評価では、NVIDIA B200 GPU上で最大約70倍のレイテンシ削減と2.8倍のスループット改善、AMD MI355X GPU上で最大3.6倍のスループット改善が示されています。ここまで来ると、ハーネスは単なるプロンプトの外枠ではなく、AIアプリケーションの実行計画コンパイラに近い存在です。

【コミュニティの生々しい熱量と議論】
Redditのr/AI_Agentsでは、この問題意識がかなり露骨な言葉で語られています。投稿では、production AI agentsではオーケストレーション層、つまりharnessが決定的要因であり、生のモデル性能より重要だ、という主張が出ています。具体的には、memory、tools、permission gates、workflow state、recovery/retry logic、observability、rollback mechanismsを統合する層が、本番投入の背骨になるという見方です。

熱量が高いのは、これが抽象論ではなく監査と事故の話に直結しているからです。コミュニティでは、モデルを少し賢くするより、permission-aware retrieval、取得チャンクごとの構造化ログ、明示的な支出上限とリトライ上限、透明な失敗処理を優先すべきだ、という声が出ています。また、間違ったオーケストレーション層を選ぶと、lock-in、brittle debugging、exploding costs、さらに監査人が即座に問題視するuntraceable data accessを招く、という強い表現も見られます。

一方で、Reddit上の個別比較には注意も必要です。LangChainは最大限の柔軟性を求めるエンジニア向け、CrewAIはOSSのマルチエージェント構成向け、n8nはセルフホスト可能なビジュアルワークフロー自動化向け、という整理が投稿内で語られています。ただし、これらはコミュニティ投稿上の評価であり、公式ベンチマークにより一律確認された事実ではありません。特に、DataGOLだけがデータソースレベルのログ、ガバナンス、コンプライアンス、トレース可能性を完全に答えている、という趣旨の主張は、少なくとも提示された公式・大手メディア系の確認済み情報だけでは断定できません。ここは、コミュニティでそういう評価軸が浮上している、と伝聞として扱うべき部分です。

それでも、この議論が刺さる理由は明快です。エージェントが本当にDB、CRM、データウェアハウス、S3、社内ファイルストアを読む段階に入ると、監査人は「エージェントが走ったか」ではなく、「どのデータに触れたのか、誰が許可したのか」を問うようになります。これはモデル性能ランキングでは答えられません。答えられるのは、アクセス制御、ログ、証跡、ロールバックを持つハーネスです。

【今後の展望とエコシステムへの影響】
今後オワコン化していくのは、モデルに巨大な権限を渡して、うまく推論してくれることを祈るタイプの万能エージェント幻想です。もちろんモデル性能は重要ですが、本番ではモデルが少し賢くなることより、失敗した時に止まれること、再現できること、誰が何を許可したか説明できることの価値が上がります。特に金融、医療、人事、法務のような領域では、agentが正解を出したかだけでなく、正解に至る途中で触れたデータの正当性が問題になります。

パラダイムシフトは、モデル選定から実行系設計への移動です。これまでの比較は、どのLLMが一番賢いか、どのベンチで勝ったかに寄りがちでした。しかしAgent Harness時代の比較軸は、どのデータを読ませるか、どの操作に人間レビューを挟むか、どのログを保存するか、どこまで自動ロールバックできるか、評価をモデル・ハーネス・環境に分解できるかへ移ります。

重要なのは、ハーネスを大げさに作ればいいわけでもない点です。検索結果1の実務者記事では、多くの業務エージェントはコーディングエージェントや個人用万能エージェントほど複雑ではなく、必要なハーネスの複雑さは「どれだけ複雑な行動を取るか」と「どれだけ複雑な文脈を扱うか」に応じて決めるべきだとされています。これはかなり実務的な警告です。最初から汎用自律エージェント基盤を作るのではなく、目の前の仕事に必要な権限、ログ、検証、回復だけを小さく作る。その地味な設計思想こそ、派手な新モデル発表の裏でギークに刺さる本題です。

結論として、2026年のAIエージェント論は「どのモデルを使うか」から「そのモデルをどう閉じ込め、どう観測し、どう失敗させ、どう復旧させるか」へ移っています。モデルは頭脳ですが、本番システムでは神経系、免疫系、監査証跡、非常停止ボタンまで含めて初めてエージェントになります。Agent Harnessは地味ですが、ここを雑にしたAIスタックは、賢いモデルを積んでも運用で折れる。逆にここを押さえたチームは、モデル乗り換え時代にも壊れにくいAI実行系を持つことになります。