AIの子守りは終わり AIコーディングの質を左右する「コンテキストエンジン」とは：MCPだけでは不十分
AI開発支援企業Unblockedは、企業におけるAIエージェント活用の課題は知能ではなく「コンテキスト不足」にあると指摘する。さらに、「コンテキストエンジン」が、高品質なコード生成の鍵になるとの見解を示す。
生成AIを活用したコーディング支援ツールやAIエージェントの導入が進む中、多くの開発現場で新たな課題が浮上している。それは、「AIエージェントを常に監視しなければならない」という問題だ。
コード生成自体は高速化したものの、生成されたコードが自社の設計方針や既存システムと整合しないケースは少なくない。その結果、エンジニアはAIが出力したコードを何度も修正し、追加の指示を与え続けることになる。
AI開発支援企業Unblockedのデベロッパーリレーションズを担当するブランドン・ワシルク氏は、「問題はAIの知能不足ではなく、コンテキスト不足にある」と指摘する。同氏は、AIエージェントを継続的に支援する仕組みとして「コンテキストエンジン」の重要性を説明する。
コンテキストエンジンとは
併せて読みたいお薦め記事
AIコーディングの関連記事
企業の開発環境には、ソースコードだけでなく、設計ルールや運用手順、過去の議論、チームごとの慣習など、膨大な知識が存在する。
人間のエンジニアは入社後にこうした知識を徐々に習得する。一方、AIエージェントはタスク開始時点では企業固有の知識を持たない。
ワシルク氏はこの状態を、「非常に優秀だが、自社のことを何も知らないソフトウェアエンジニアが突然入社してきた状態」に例える。生成AIは高度なコーディング能力を備えているが、自社のアーキテクチャや開発文化、利用中のサービス、組織構造を理解しているわけではない。
そのため、「Zendesk連携を実装してほしい」と指示された場合でも、既存サービスや社内標準パターンを知らないまま独自実装を進めてしまうことがある。コードはコンパイルできても、アーキテクチャとしては誤っているケースが発生する。
ワシルク氏は、この状況を「現在は人間がコンテキストエンジンになっている状態」と表現する。エンジニアがAIエージェントに対して設計方針や参照すべきファイルを都度教え、「このサービスを使え」「その実装は既に存在する」と修正を繰り返しているからだ。
結果として、多くの開発者は「AIに仕事を任せる」のではなく、「AIの子守りをする」という負のループに陥っている。
「MCPをつなげば解決」は誤解
AIエージェント活用では、「MCP（Model Context Protocol）で社内システムに接続すれば十分」と考える企業もある。しかしワシルク氏は、これは誤解だと指摘する。
MCPはあくまでデータへのアクセス経路を提供する仕組みであり、情報の意味や重要度までは理解しない。人間の新入社員が社内システムへのアクセス権を付与されたからといって、すぐに業務を理解できるわけではないのと同じだ。
AIエージェントはアクセス可能な情報の中から最初に見つけた内容を正解と判断し、それ以上調査しないケースがある。
ワシルク氏は、この現象を医療分野で知られる「検索の満足感（Satisfaction of Search）」になぞらえる。放射線科医がレントゲン画像で異常を1つ発見すると、それ以外の異常を見落としやすくなるのと同様に、AIも最初に見つけた情報を正解と見なし、探索を終了してしまうことがある。
例えば、ある設計資料を見つけた時点で探索を終了し、より適切な実装パターンが別のシステムに存在していても見落としてしまう。結果として、人間が再び「違う、その実装ではない」と修正を指示することになる。
同氏は、「MCPはデータへのパイプに過ぎない。組織全体の知識を理解し、推論する機能は提供しない」と説明する。
巨大なコンテキストウィンドウでも解決しない
近年は100万トークン級のコンテキストウィンドウを備えた生成AIモデルが登場している。しかしワシルク氏によると、「大量の情報を一度に投入すれば解決する」という考え方も現実的ではない。
コンテキストウィンドウが拡大しても、AIが全ての情報を正しく理解し、適切な情報だけを抽出できる訳ではないからだ。
社内ドキュメントやソースコード、チャット履歴などをそのまま投入しても、重要な情報と不要な情報が混在した状態になる。AIはデータの中に存在する人物やシステム、設計ルール同士の関係性を自動的に理解できるわけではなく、膨大な情報があるほど適切な推論が難しくなる場合もある。
同氏は「問題は情報量ではなく、適切なコンテキストを抽出して与えることだ」と強調する。
コンテキストエンジンが担う役割
そこで必要になるのがコンテキストエンジンだ。コンテキストエンジンは、企業内のさまざまな情報源から必要な情報だけを収集し、AIエージェントへ最適化して提供する仕組みだ。
単なるナレッジベースではない。設計書やドキュメントといった静的な情報だけでなく、現在のコードベースやチケット、チャットでの議論といった動的な情報もリアルタイムで組み合わせながら、AIに必要な文脈を生成する。
ワシルク氏によると、コンテキストエンジンには以下の機能が求められる。
企業全体の情報を横断的に理解する
ソースコードだけでなく、SaaSアプリケーション、チケット管理システム、ドキュメント、チャットツールなど複数の情報源を横断的に参照する。
ソーシャルグラフを活用する
誰がどのコードを書き、誰がレビューし、どのチームと協力しているのかといった人間関係や役割の情報を保持する。
これによって、AIは「誰が質問しているのか」「どのシステムに関わっている人物なのか」を理解し、曖昧なプロンプトからでも意図を推測しやすくなる。
情報の矛盾を解決する
ソースコードではAが正しいことになっていても、チャットでは「その実装は誤り」と議論されている場合がある。
コンテキストエンジンは情報源の信頼性や発言者の役割を考慮しながら、どちらを優先すべきか判断する。
例えば、ソースコードとSlack上の議論が矛盾していた場合でも、CTOが「その実装は間違っている」と発言していれば、その情報を優先してAIへ伝える。このような「情報の真偽」を判断する機能が重要になる。
アクセス権限を維持する
全ての情報を全社員や全エージェントに公開する訳ではない。
ユーザーごとの権限を維持しながら必要な情報だけを提供することで、情報管理のガバナンスを確保する。
常に最新の情報を返す
過去の優れた回答をキャッシュして再利用すると、コードや設計が変化した後に誤情報を返す危険がある。
そのためコンテキストエンジンは、常に最新の情報を参照しながら回答を生成する必要がある。
必要な情報だけを返す
収集した情報をそのまま渡すのではなく、AIエージェントが実行に必要な情報だけを抽出し、トークン数を最適化した形で提供する。
コンテキストが変わるとコード品質も変わる
ワシルク氏は、同じ「Zendesk連携を実装する」というタスクで比較実験を実施した。
MCPのみを利用したAIエージェントは、コードのコンパイルには成功したものの、社内の設計パターンを無視した実装を生成した。コードレビューを担当したシニアエンジニアは、「そのまま本番投入するとシステムを壊しかねない」と評価したという。
一方、コンテキストエンジンを利用したAIエージェントは、社内標準のファクトリーパターンや既存サービスとの連携方法を踏まえた実装計画を作成した。レビュー結果は軽微な修正のみで、実質的にマージ可能な品質だったという。
つまり、AIモデル自体は同じでも、与えるコンテキストによって成果物の品質は大きく変わるということだ。
AI活用のボトルネックは「知能」ではなく「文脈」
ワシルク氏は「AIの課題はもはや知能ではなくコンテキストだ」と繰り返し強調する。
生成AIはコードを書く能力自体は十分に高い。しかし、企業固有の知識や設計思想を理解していなければ、本番環境で利用できる品質の成果物を安定的に生成することは困難だ。
AIエージェントを単なるコード生成ツールとして利用する段階から、自社の知識を理解した「チームメンバー」のように機能させる段階へ進むには、コンテキスト管理の仕組みが欠かせない。
今後、企業のAI活用競争で差を生むのはモデル選定だけではない。AIにどれだけ正確で最新の文脈を与えられるか――。その基盤となるコンテキストエンジンの構築が、次の重要なテーマになりそうだ。
本稿は、AI Engineerが2026年5月26日に公開した動画「Stop babysitting your agents...―Brandon Waselnuk, Unblocked」を基に作成しました。
Copyright © ITmedia, Inc. All Rights Reserved.