エージェント構築は容易に、次なる最前線は文脈—Jeff Ng氏

エージェント構築は容易になったが、次なる最前線は「文脈」である——沈黙した失敗を防ぐための新アプローチ

AI エージェントの構築自体は、Cloudflare や Vercel などのインフラ成熟により劇的に簡素化されました。しかし、組織内の暗黙知や過去の失敗事例といった「文脈」を欠いたまま動作するエージェントは、自信満々ながら致命的な誤判断を下す「沈黙した失敗」を引き起こします。

Jeff Ng 氏（Unblocked 創設エンジニア）は、単なるデータ接続に留まる従来のアプローチの限界を指摘し、情報を統合・要約し権限に基づいて提供を行う「コンテキストエンジン」の必要性を説きます。AI エージェントの真価を発揮させるには、推論能力だけでなく、組織知識の構造化と統合が次なるボトルネックであることを理解する必要があります。

インフラ成熟で構築は容易に、しかし基盤コストは残る

6 ヶ月前まで、生産環境向けの AI エージェントを構築するにはチーム全体での数ヶ月にわたる effort が必要でした。エージェントとは単なるモデルやツールの集合体ではなく、状態管理やサンドボックス、観測性（Observability）など、多数のシステムを統合した複雑なプロダクトです。

特に以下の基盤コストは依然として課題となっています：

• チェックポイントと状態永続化: エージェントは長期間稼働し状態を持つため、インフラが瞬時に消滅する（Ephemeral）環境ではセッションの再開やトークンのロスが発生します。また、副作用（Side effects）が重複実行されるリスクもあります。
• サンドボックス基盤: 生成されたコードやサードパーティ製コードを実行する際、環境シークレットへの不正アクセスやネットワークへの不要な接続を防ぐための隔離環境が必要です。
• 観測性: エージェントのどこで失敗したかを特定するため、複数のシステムにまたがるログとトレースを追跡する必要があります。

これらの要素はエージェントの能力そのものを高めるものではありませんが、ゲームに参加するために支払う「税金」のようなものです。しかし現在は、Cloudflare、Vercel、AWS などのクラウドインフラプロバイダーや、Flu、Mastra といったフレームワークがこれらの複雑さを抽象化し、プリミティブを提供しています。

「今ではエージェントを定義するコードは驚くほど少なくなりました。モデルの選択、指示（システムプロンプト）、アクセス権限のあるツール、そして実行場所の指定だけで十分です。」

これにより、開発者はコアロジックやチーム・顧客への価値提供に集中できるようになりました。

文脈欠如が招く「自信満々な誤り」

構築が容易になった反面、新たな課題が浮き彫りになっています。Jeff Ng 氏が示した事例では、Linear のチケットを分析し、コードリポジトリを検索して解決策を提案するエージェントを作成しました。

ある際、QA パイプラインの遅延問題を解決するため、非同期ディスパッチ（async dispatch）を再有効化することを推奨しました。技術的には理にかなった提案ですが、これは数日前に実際にアウトエージを引き起こし、エンジニアが明示的に無効化した変更だったのです。

なぜエージェントはこれを間違えたのでしょうか？

• エージェントには、そのチケット作成後に Slack で行われた議論や、実際のアウトエージの原因分析、そして事後報告（Postmortem）の文脈が含まれていませんでした。
• 人間であれば、コードの背景にある事情や過去の失敗、組織的な合意を補完して判断できますが、エージェントは「指示」「ツール」「コード」「チケット」という限られた情報のみしか持っていません。

「人間がループ（In the loop）にいる間は、私たちはエージェントの監視役としてエラーをキャッチし、欠けている事実を提供します。しかし、人間の介入が不要になるほどエージェントが普及すればするほど、この文脈の欠如による『沈黙した失敗』は深刻化します。」

MCP の限界と「コンテキストエンジン」への転換点

多くの人が「MCP（Model Context Protocol）を使えば解決しないか？」と考えます。確かに、Slack、Linear、GitHub などの MCP を接続すればデータへのアクセスは可能になります。

しかし、Jeff 氏はここで決定的な違いを指摘します。MCP は「アクセス」を提供しますが、「理解」や「統合」は行いません。

• ノイズとコスト: エージェントに生データを渡すため、関連性の低い情報が溢れ、コンテキストウィンドウが埋まり、コストが増大します。
• 競合解決の欠如: Linear の MCP と Slack の MCP が異なる結果を返した際、その矛盾を解決するロジックはエージェント自身に任されます。これは非効率かつ不確実です。

この課題に対し、Jeff 氏が提唱するのが「コンテキストエンジン」です。

「コンテキストエンジンとは、誰が（あるいはどのエージェントが）何を求めているかに基づき、タスクに関連する情報を提供し、複数のデータセット間の競合を解決するシステムです。」

Unblocked のコンテキストエンジンは以下の特徴を持ちます：

1. 統合: ドキュメント、コード、チケット、会話など、組織内のあらゆるデータをモデル化して接続します。
2. 権限に基づくスコーピング: エージェントのアクセスロールに基づき、必要な情報のみを提供します。
3. 要約と統合: 散らばった文脈（Scattered context）を収集し、整合性を保ちながら要約された文脈（Grounded context）としてエージェントに提供します。

実証：文脈の付与が判断を正す

同じエージェントに、Unblocked のコンテキストエンジンを接続して再テストを行いました。結果は劇的に変わりました。

• エージェントは Linear のチケットだけでなく、関連する Slack の議論や事後報告（Postmortem）も自動的に取得・要約しました。
• その結果、エージェントの提案は「非同期ディスパッチを有効化（＝失敗の原因）」から「別のアウトエージを防ぐための対策」へと修正されました。

これはチケット分析だけでなく、コーディング支援やコードレビュー、顧客対応など、組織の暗黙知（Tribal knowledge）が必要なあらゆる場面で応用可能です。例えば、コードレビューではチームのエキスパートがレビューしたかのような品質を、顧客対応では正確な回答を提供できます。

まとめ：「推論能力」から「文脈統合」へ

AI エージェントの普及において、次なるボトルネックはモデルの推論能力ではなく、組織内の知識や文脈をいかに構造化し統合するかです。単なるツール接続から、組織知識の構造化へと戦略をシフトさせることが、真に信頼できる AI エージェントを実現する鍵となります。

「解決すべきギャップは知能（Intelligence）ではなく、文脈（Context）です。」

企業における AI 導入は、単なるツールの接続から、組織の記憶と意思決定プロセスをAI に統合する段階へと進化しているのです。