おもちゃ工房はあらゆるおもちゃを知っている — コンテキスト・エンジン

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

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

あらゆるAIツールが抱える問題

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

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

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

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

Augmentのコンテキスト・エンジンは、あなたのスタック全体をリアルタイムかつ意味論的に理解することでこの問題を解決します。つまり、開いているファイルだけでなく、すべてを対象にします。

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

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

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

北極圏の図書館（ライブラリ）のたとえ

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

コンテキスト・エンジンがあると、ライブラリは生きていて賢いものになります。エルフが蒸気機関車（レール上を走る機関車）を作るよう割り当てられた瞬間、ライブラリが自動的に次を提示します。

• 過去10年で作られたすべての機関車（使われているコードパターン付き）。
• 工房が2019年に採用した車輪の標準。
• 車輪付きのおもちゃすべてに適用される塗装仕様。
• すべての車両が通過しなければならない安全試験。
• この機関車のレールが一致すべきゲージ・エルフによる進行中の作業。

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

なぜこれがマルチエージェント作業に重要なのか

単一エージェントのワークフローでは、コンテキストが限られていることは不便に過ぎません。エージェントは、少しだけ一般的なコードを生成し、整えが必要になります。

しかしマルチエージェントのワークフローでは、コンテキストが限られていることは連携の失敗になります。もしエージェントAがエージェントBがRS256で署名をしていることを知らなければ、エージェントAは別のアルゴリズムで自前の署名を実装してしまうかもしれません。検証（Verifier）はそれを見つけますが、両方のエージェントが、後で突合・調整が必要になるほど実質的な作業を終えた後になってからです。

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

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

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

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

コンテキスト・エンジンはIntentにおいて具体的にどう供給されるか

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

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

スペシャリストが、より良いコードを書くために使います。彼らは、尊重すべきパターン、ユーティリティ、インターフェースを把握しています。

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

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

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

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

サンタクロースはプライバシーを真剣に扱います。Augmentも同様です。Context Engineはコードベースを処理してインデックスを構築し、AugmentのTrust Centerではデータの取り扱い方法を説明しています。機密性の高いコードベースを持つエンタープライズチームにとっては、ライブラリをEngineに渡す前に確認しておく価値があります。

これから何が起こるか

第7回では、すべてをひとつにまとめます。複数のエルフが同時に作業しながら、混乱なく――クリスマスの大惨事もなく。マルチエージェント・オーケストレーション――衝突や混乱、そしてクリスマスの大惨事を起こさずに、並行してワークショップを運営する技です。

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

Santa Augmentcode Intentシリーズの一部。dev.toで、the-software-s-journey組織のもと公開。