エージェントのベビーシッターを止めるべきだ

エージェント開発の真の課題は「知能」ではなく「文脈欠如」。ベビーシッター不要な環境構築とは？

AI エージェントの開発において、多くのチームが直面している最大の壁は、モデル自体の知能不足ではありません。真の問題は、組織固有の文脈やランタイムデータへのアクセス欠如にあります。

本記事では、単なる RAG（検索拡張生成）やツール接続だけでは不十分であり、エージェントを自律的に動かし続けるには「動的なコンテキストエンジン」が必要であるという核心を解説します。人間のベビーシッターに依存せず、組織の文脈を理解するインフラを整備する方法を探ります。

エージェントは「天才だが無知」：ゼロコンテキストの現実

AI エージェントを CLI で起動すると、それはまるで天才的なソフトウェアエンジニアが突然誕生したようなものです。しかし、そのエージェントには組織に関する情報が一切ありません。「頭の中は完全にゼロコンテキスト」です。

人間が新入社員の頃を思い出してください。初日は何も知らず、時間をかけて市場やチームと接し、「これは PR だ」と提案して却下されるなどの経験を通じて文脈を蓄積していきます。最終的に、役に立たない情報を切り捨て、正確な質問ができるようになるのです。

エージェントは現在、その「文脈を構築する人間」の代わりとして機能させられていますが、それは非効率です。

多くの企業が AI 導入を進める際、この「人間がベビーシッターとなって文脈を与え続ける状態」に陥っています。これが現在の主流ですが、これではエージェントは自律的に動くことができません。

3 つの誤解：なぜ既存のアプローチは失敗するのか？

コンテキストエンジンを構築する過程で得られた重要な教訓として、以下の 3 つの一般的な誤解が指摘されます。

1. 「ドキュメントを RAG すれば文脈になる」という思い込み

多くのチームが、静的なリポジトリや MD ファイルに企業情報を格納し、RAG（検索拡張生成）でアクセス可能にするアプローチを取ります。しかし、これには致命的な欠陥があります。

まず、これらの情報は「静的」であり、誰かが常に維持・更新する必要があります。また、最も重要な「ランタイムデータ」（その瞬間の状況や最新の動き）が含まれていません。

さらに深刻なのは「検索満足度（Search Satisfaction）」という現象です。これは医療画像診断で知られる問題ですが、エージェントにも同様に発生します。

エージェントが「Zenesk の統合を行いたい」と指示された際、MCP を通じて最初のデータを見つけると、「これが答えだ」と判断して検索を止めてしまいます。しかし、それが正解とは限りません。根本原因や最適な実装方法を見逃し、後でエンジニアに却下されるというループに陥るのです。

2. 「MCP ツールを接続すれば解決する」という誤解

ツール接続（MCP）は、エージェントが外部サービスにアクセスするための「パイプ」を提供します。しかし、これだけでは「理解」や「推論」は生まれません。

実際の実験では、MCP アクセス権限を与えた素朴な実行でもコードチェックを通過し、コンパイルも成功しました。しかし、シニアエンジニアが指摘したように、「これは完全に間違っている」のです。試みられた実装は、もし出荷されていればシステム全体を壊す結果になっていた可能性があります。

3. 「コンテキストウィンドウを広げれば全て解決する」という幻想

100 万トークンもの巨大なコンテキストウィンドウを夢見る声もありますが、計算リソースの観点からも実用的ではありません。大量のデータをただそこに置くだけでは、エージェントは「針を探す」ことしかできず、エンティティや関係性を理解できません。

コードベース全体でファクトリーパターンを検索するには、セッション内で長時間 grep を実行し、莫大なトークンを消費する必要があります。ターミナルを閉じればその情報は消え去り、最初からやり直す必要があります。誰もそんな非効率なコストを繰り返すことは望んでいません。

必要なのは「動的コンテキストエンジン」

真の解決策は、静的ドキュメントとランタイムデータを統合し、権限管理や情報の真偽を推論する「動的コンテキストエンジン」の構築です。

このエンジンは、組織全体の知識コーパスにあるすべての静的ソースを横断し、SaaS アプリや異なるシステムからリアルタイムでデータを取得・分析します。そして、必要な詳細を含んだトークン最適化された回答だけをエージェントに送信します。

ソーシャルグラフ：誰に相談すべきかを知る

コンテキストエンジンの核心となるのが「ソーシャルグラフ」です。これは開発者の関係性やコードレビュー履歴をグラフ化したものです。

例えば、「Zenesk の統合方法を教えて」という質問に対し、エンジンが以下の情報を推論できます。

• あなたはどのコードベースで作業しているか
• あなたの PR 履歴はどうなっているか
• 誰と協力しているか

大企業では数万人のメンバーがいるため、単純な検索ではなく、「誰に相談すべきか」を判断する能力が不可欠です。このグラフ化された関係性が、エージェントに「文脈」を与えます。

真実性の推論：矛盾する情報をどう解決するか

組織内では、ソースコードの記述と Slack の会話、あるいは CTO の発言が矛盾することがあります。

ソースコードはこう言い、Slack では CTO が「これは誤って実装された」と述べている場合、コンテキストエンジンはこれを推論して解決します。おそらく CTO の発言の方が真実であるため、エージェントはその情報を優先して行動すべきです。

このように、情報の「真偽（Truthfulness）」を判断し、権限に基づいて矛盾を解決する能力が、自律的なエージェントには必要不可欠です。

データガバナンスとパーソナライズ

20 人以上の組織では、データアクセスの管理も重要です。すべてのデータを格納する必要はありません。プライベートチャットや機密情報は、その人の権限に応じてのみ表示されるべきです。

エージェントが質問した際、他の人がプライベートチャットを参照して回答することはできません。適切なコンテキストとモデルを、適切なタイミングで、トークン単位で最適化して提供する必要があります。

成果：ベビーシッター不要な未来へ

このアプローチを実証するために、Claude に「素朴な MCP 接続」と「コンテキストエンジン搭載」の 2 つの環境で比較テストを行いました。その結果、明確な違いが生まれました。

• 素朴な実行: ベッドロック（Fallback）をバグのように出力したり、組織の慣習を破るコードを生成したりしました。
• コンテキストエンジン搭載: シニアエンジニアのフィードバックを受け入れ、「マージできます。ただここを直してください」というような、人間が書いたかのような高品質なコードを生成しました。

エージェントは、誰かが書いたかのようなコードを書くべきです。何年もチームに在籍している人が書いたかのように感じられるコードこそが、期待されるべき標準なのです。

このコンテキストエンジンは、単なるコーディング支援にとどまりません。Ask Engineering チャンネルでの自動回答や、インシデント管理、チケットのトリアージなど、組織全体のサポート体制を強化する基盤としても機能します。

まとめ：文脈を理解するインフラへ

AI エージェントの実用化において、単なるコード生成能力の向上だけでなく、組織固有の文脈を動的に理解するインフラの重要性が再認識されます。これにより、エンタープライズ環境での AI 導入リスク（セキュリティ違反や誤った実装）が低減し、開発者の生産性が劇的に向上することが期待されます。

エージェントを「育てる」のではなく、「文脈を理解させる」環境を整備すること。それが、ベビーシッター不要な未来への唯一の道です。