おもちゃ工房はすべてを知っている — コンテキストエンジン

付随するソースコードリポジトリ: Santa Augmentcode Intent

人々はよく尋ねます。「エルフたちはどうやって何でも作れるのですか？」私たちは正式な大学を運営していません。エルフ・アカデミーもありません。答えは工房ライブラリ — 生きたコレクションです。あらゆるおもちゃの設計図、あらゆる素材のデータシート、あらゆる技術マニュアル、そして843年以降のすべてのクリスマスで得られたあらゆる学び。エルフが作業机に座るとき、ゼロから始めてはいません。積み重ねられてきた12世紀分の知識の上に立っているのです。Augmentはこの仕組みを彼らの「コンテキストエンジン」と呼んでいます。私はそれを「必須のもの」と呼びます。

すべてのAIツールが抱える問題

ほとんどのAIコーディングツールには、根本的な制約が1つあります。つまり、プログラミング一般についてはかなりのことを知っている一方で、あなたのコードベースに関してはほとんど何も知らない、という点です。

汎用のAIアシスタントに、アプリケーションへ機能を追加するよう頼むと、コンパイルできるものは生成します。しかし、それがあなたの命名規約を無視したり、すでにあるユーティリティを重複させたり、6か月前に決めたアーキテクチャ上の判断と衝突したり、チームが何週間もかけて確立したセキュリティのパターンを破ったりする可能性があります。

AIは「知らないこと」を知りません。そして「知らないこと」とは、あなたに固有のすべてです。

コンテキストエンジンが行うこと

Augmentのコンテキストエンジンは、これを解決します。あなたのスタック全体をライブで意味的に理解することで、開いているファイルだけでなく、すべてを対象にするのです:

• コード: リポジトリ全体にわたる、すべてのファイル、クラス、関数、インターフェース。
• 依存関係: 使用しているライブラリと、それらの使い方。
• ドキュメント: インラインコメント、README、アーキテクチャドキュメント。
• スタイル: 命名規約、コードパターン、フォーマットの好み。
• 最近の変更: 何が、いつ、なぜ変わったか（コミットメッセージやPRから）。
• 課題: オープンチケットと、トラッカーで把握されている既知の問題。

コンテキストエンジンは、これを単なるフラットなテキストとして保存するだけではありません。意味的な理解を構築します。たとえば、UserAuthService が TokenRepository に依存していること、コードベースがどこでも依存性注入（dependency injection）を使っていること、チームが署名処理すべてに RS256 を使うことを6週間前に合意していること、などを把握します。

Intent 内でスペシャリストエージェントが起動されるとき、エージェントはあなたのコードベース全体の生のダンプ（どのモデルのコンテキストウィンドウも超えてしまう可能性があるもの）を受け取りません。コンテキストエンジンは、関連するコンテキストを選別（カュレート）します。4,456の潜在的なソースから、このタスクに実際に関係する 682 を選びます。エルフは、作っているおもちゃに必要な正しい設計図を手に入れるのであって、ライブラリ全体は不要です。

北極圏のライブラリにたとえると

あなたの工房には、12世紀分のおもちゃの設計があると想像してください。コンテキストエンジンがない場合、エルフはライブラリまで歩いて行き、1時間かけて探し、関連する設計図を3つ見つけ、残りは推測します。遅い、完全ではない、そしてエラーが起きやすい。

コンテキストエンジンがあると、ライブラリはライブで知的になります。エルフに蒸気機関車（ロコモティブ）の製作が割り当てられた瞬間に、ライブラリは自動的に次を提示します:

• 過去10年で作られたすべての機関車（使われたコードパターン付き）。
• 工房が2019年に採用したホイールの規格。
• 車輪を備えたすべてのおもちゃに適用される塗装仕様。
• すべての車両が合格しなければならない安全テスト。
• この機関車のレールが一致すべき進行中の作業（ゲージ担当のエルフによる）。

エルフは、完全な状況把握から始めます。古いホイール規格を誤って使うことはありません。3年前に誰かが書いた塗装仕様のユーティリティを重複させることはありません。隣で進行中の作業と衝突するゲージのレールを作ることもしません。

なぜマルチエージェント作業で重要なのか

単一エージェントのワークフローでは、コンテキストの制限は不便にすぎません。エージェントは少しだけ汎用的なコードを生成し、整理（整形）する必要が出ます。

マルチエージェントのワークフローでは、コンテキストの制限は調整（コーディネーション）の失敗になります。もしエージェントAが、エージェントBが RS256 による署名を使っていることを知らなければ、エージェントAは別のアルゴリズムで自前の署名を実装してしまうかもしれません。検証（Verifier）はこれを検出しますが、両方のエージェントがすでに大きな作業を終え、その後に整合のための調整が必要になってからです。

コンテキストエンジンは、これを防ぎます。最初からすべてのエージェントがコードベースに対する同じ理解を共有するようにするからです。コーディネータが仕様書を起草するとき、「署名にはRS256を使う — 既存のパターンが *auth/signing.ts にある」*と宣言できます。なぜなら、その知識が利用可能だからです。その仕様書を読むすべてのスペシャリストは、そのコンテキストを継承します。

コンテキストエンジン vs バニラモデル：数値で見る

Augmentは、Elasticsearchリポジトリ（Java 360万行、2,187人のコントリビュータ）に対してエージェントの性能を比較するベンチマークを公開しています。コンテキストエンジンを動力とする彼らのエージェントは、500件のエージェント生成PRに対するブラインド評価で、他のツールを上回りました:

最大の差はコード再利用とベストプラクティス順守にありました。まさに、コードベースを知っていることが最も重要になる次元です。どんなモデルでも、コンパイルできるコードは書けます。新しいユーティリティを書く代わりに、既存のユーティリティをいつ再利用するべきかを判断するには、コンテキストが必要です。

コンテキストエンジンはIntentに対してどのように供給されるか（特に）

Intent の内部では、コンテキストエンジンは3つの異なる利用者に役立ちます:

コーディネータ は、より良い仕様書を書くためにそれを使います。既存のアーキテクチャを知っていれば、想像上の依存関係ではなく、実際の依存関係に沿ったタスク分解案を提案できます。

スペシャリスト は、より良いコードを書くためにそれを使います。彼らは守るべきパターン、ユーティリティ、インターフェースを理解しています。

検証（Verifier） は、それをコードベースの知識とともに初めて見える仕様違反を検出するためにそれを使います。「このコードは既存のレート制限ミドルウェアをバイパスしている」は、ミドルウェアの存在をVerifierが知っている場合にのみ、有用なコメントになります。

SIPOC：コンテキストエンジンの実動例

プライバシーに関する注記

返却形式: {"translated": "翻訳されたHTML"}

サンタクロースはプライバシーを真剣に守っています。Augment も同様です。コンテキストエンジンはあなたのコードベースを処理してインデックスを構築し、Augment のトラストセンターではデータの取り扱い方法がどのように説明されているかが記載されています。機密性の高いコードベースを扱うエンタープライズチームにとっては、ライブラリをエンジンに渡す前に一度確認しておく価値があります。

次に来るもの

第 7 話では、すべてを一つにまとめます。複数のエルフが同時に作業しても混乱は起きない——です。マルチエージェント・オーケストレーションとは、衝突も混乱もクリスマス級の大惨事もなく、並列のワークショップを運営する技術です。

コンテキストのないエルフは、高くつく推測をするエルフです。彼らにライブラリを渡してください。コンテキストエンジンを渡してください。彼らが奇跡を作り上げるのを見てください。ほっほっほ！

Santa Augmentcode Intent シリーズの一部です。dev.to のthe-software-s-journey 組織のもとで公開されています。