技術要約: AAL – ジャストインタイム・コンテキスト注入のためのインバンド・ソース・アノテーション

1. 問題提起

自律型ソフトウェア開発エージェント（Cursor、GitHub Copilot Workspaceなど）への大規模言語モデル（LLM）の統合は、「コンテキスト汚染（context pollution）」として知られる重大なパフォーマンス上のボトルネックをもたらしている。現在のパラダイムは、リポジトリ全体の組織的なガイドラインをエージェントのコンテキストウィンドウにロードする、モノリシックなアウトオブバンド・システムファイル（.cursorrulesなど）に依存している。このアプローチは、主に2つの問題を引き起こす：

• トークン予算の膨張（Token Budget Inflation）: 余計なガイドラインが貴重な入力ウィンドウの制約を消費し、エージェントの実際のコード生成能力を制限する。
• 注意力の希釈（Attention Dilution）: 「Lost in the Middle（中だるみ現象）」[1] を引用すると、肥大化したシステムプロンプト内で関連する詳細を見つけ出すよう強制されると、エージェントの実行品質が低下する。

2. メソドロジー：エージェンティック・アノテーション・ランゲージ（AAL）

グローバルなファイルからポリシー適用を切り離すために、著者らは、軽量なインバンド・コメント・アノテーション（例：# @!security）を利用して、ドメイン固有の指示をジャストインタイム（JIT）で注入する「プッシュ・トゥ・プル（push-to-pull）」システムであるAALを提案する。

コア・アーキテクチャ

システムは、2段階のパース・パイプラインを通じて動作する：

1. ホスト抽出（Host Extraction）: ホストIDEは、ネイティブのASTパーサー（Rosot, Tree-sitterなど）を利用して、コードからコメントを分離し、特定のAAL構文を理解する必要なく生のテキストを抽出する。
2. AAL検証（AAL Validation）: 抽出されたペイロードは、形式的なEBNF文法によって検証され、ドメインキー（例：Payload → AAL_Directive → [Domain1, ...]）を分離する。

ASTを考慮した優先順位とスコープ解決

AALは、抽象構文木（AST）を用いてスコープ解決を数学的に定式化する。ソースファイルは有向木 $T = (V, E)$ としてモデル化される。編集がライン $N_{edit}$ で発生した場合、リゾルバは以下を行う：

• 編集を含む最も深い一致構文ノード $v^*$ を特定する。
• $v^*$ からモジュールルートへの祖先パスを構築する。
• 非空のアノテーションを持つ最初のノードを選択し、アクティブなドメイン集合 $D_{active}$ を決定する。
• 「ネストされたモノリス」による肥大化を防ぐため、ノードあたり最大3つのドメインという厳格な上限を課す。

ハイブリッド・レジストリとキャッシュ

• レジストリ: ドメイン構成は、ドメインをローカルパスまたは外部URI（ソース管理されたリポジトリに限定）にマッピングする中央のYAMLファイルで定義される。
• 非ブロッキング・キャッシュ: ネットワーク遅延によるIDE実行の停止を避けるため、リモートリソースはライフサイクル・フック（例：プリコミット）中にローカルにキャッシュされる。システムは、同期的なリクエストを行うのではなく、Local_Cache_Path(URI) から読み込む。
• ツイン・プロベナンス監査（Twin-Provenance Audit）: エンタープライズ・コンプライアンスを確保するため、システムはCLIバージョンとスキルのディレクトリのGitコミットSHAを固定する。これにより、リポジトリの状態が、エージェントの決定を支配する正確な指示の再現可能なアーカイブとして機能する、不変の監査証跡が作成される。

エンジニアリングによる緩和策

IDEの応答性を確保するために、AALは以下を採用している：

1. ファイル書き込みごとのトランザクション隔離: マルチファイルによるモノリシックなプロンプトの劣化を避けるため、ファイル書き込みコールごとに指示を解決する。
2. 非同期コンパイル: AST生成とスキャニングは、ルーチン・フック（保存、プリコミット）中にバックグラウンド・スレッドで実行され、キーストロークのレイテンシをパーサーの実行から隔離する。
3. フェイルソフト・フォールバック（Fail-Soft Fallback）: AST生成が失敗した場合（例：構文エラー）、エンジンは、先行するタグに対する行スキャン・正規表現スキャナーへと退行し、中断のない動作を保証する。

3. 主な貢献

• インバンド・コンテキスト注入: コンテキスト管理をグローバルなファイルから、コードに隣接するローカルなインライン・コメントへと移行させる新しいプロトコル。
• ASTベースの優先順位モデル: 編集された行の正確なスコープに基づき、最も具体的な適用可能ドメイン指示を解決するための形式的なメカニズム。
• ツイン・プロベナンス・モデル: コードと共にキャッシュされたスキルとオーバーライドをバージョン管理することで、エージェントの決定が監査可能なものとなるコンプライアンス・フレームワーク。
• ハイブリッド・ローカル/リモート取得: 非ブロッキング・キャッシュを介して、中央集権的な「ゴールデン・スタンダード」とローカルなプロジェクト特化型を両立させるシステム。

4. 実証評価および結果

著者らは、4つのドメイン（Security, Storage, Testing, Generic Helpers）にわたる20個のソースファイルを用いたデータセットを使用して、AALをモノリシックなベースラインと比較評価した。ベースラインは、組織の全指令を含む静的な4,923トークンのシステムプロンプトを使用している。

定量的結果:

• トークン削減: AALは、エージェントのトークン消費量を平均で 62.4% 減少させた。
  • セキュリティ・タスク: 26.3% の削減（3,628 トークン vs 4,923 トークン）。
  • ストレージ・タスク: 65.6% の削減。
  • テスト・タスク: 77.7% の削減。
  • ジェネリック・タスク: 79.9% の削減。
• 分布分析: 結果はヘビーテイル分布を示した。セキュリティ・タスク（高組成バンド）は、再帰的なガイドライン構成により大きなコンテキストを保持したが、テストおよびジェネリック・タスク（低組成バンド）は最高の効率を達成し、約1,000トークンの範囲に落ち着いた。
• 累積節約量: 20のタスク・スイート全体で、AALはモノリシック・ベースラインと比較して、合計 61,400 トークン以上 を節約した（37,042 トークン vs 98,460 トークン）。

5. 意義と主張

本論文は、AALが、トークン疲弊を引き起こすことなく、デベロッパー・エージェントに「ターゲットが豊富な（target-rich）」コンテキストを届けるためのエレガントで分散型の方法を提供すると主張している。その意義は以下の通りである：

• スケーラビリティ: エージェントはもはや些細な変更に対して無関係なグローバル・コンテキストのコストを支払う必要がないため、トークンの節約は局所的な編集の数に応じて乗算的にスケールする。
• アーキテクチャの効率性: AALは、単なるレキシカルな密度ではなく、セマンティックおよびアーキテクチャ的な包含をターゲットにすることで、既存のプロンプト圧縮フレームワーク（LLMLinguaなど）の上流の構造的ゲートとして機能し、それらを補完する。
• コンプライアンス: ツイン・プロベナンス・モデルは、エージェントの決定がバージョン管理された再現可能な指示によって制御されることを保証することで、エンタープライズの障壁に対処する。

著者らは、AALが深いアーキテクチャ上の効率性を示す一方で、複雑なマルチターン・ワークフローにおいて、孤立したコンテキストが機能的なコンプライアンスを低下させないことを検証するために、パス/フェイルの成功率をマッピングする今後の研究が必要であると結論づけている。