意図連続性:コーディングエージェントの長い履歴問題に対する新たな解決策

Published · AI Daily — AI-assisted deep research, methodology & disclosure

長期プロジェクトにおけるコーディングエージェントは、初期のルールを忘れがちで、内部データベースIDの漏洩などの問題を引き起こします。従来の解決策は、より大きなコンテキストウィンドウやRAG検索に依存していますが、モデルがすべてのテキストを「記憶」できたとしても、古いルールが現在のタスクに関連するかどうかを自動的に判断することはできません。本稿では「意図連続性」の概念を導入し、軽量な純Python実装を提供します。基本検索に検証レイヤーを追加することで、要件カバレッジが57%から100%に向上し、8つのテストタスクすべてが正しくなりました。ベクトルデータベース、埋め込み、LLM呼び出しは一切使用しておらず、導入が非常に容易です。著者はまた、当初の実験のバグを正直に認めており、厳密なエンジニアリング姿勢を示しています。

背景と課題

長周期にわたるコーディングエージェントプロジェクトでは、初期に設定したルールが「忽然と消えてしまう」現象が頻発します。実際にはそのルールは削除されておらず、会話ログの中に残っています。しかし、新しいリクエストが来たとき、エージェントは過去の判断が現在のタスクに影響するかどうかを自動的にチェックしなくなります。たとえば、プロジェクト初日に開発者が「APIレスポンスで内部データベースIDを絶対に公開しない」と明示したにもかかわらず、60ターン後の認証フロー構築タスクでは、そのルールが無視され、内部IDを漏洩するエンドポイントが返されてしまいます。これは筆者が実際の検証に使用したリアルなテストケースです。

既存の技術的解決策は、この問題を根本的に解決していません。より大きなコンテキストウィンドウ(GPT-4-32kやClaude 100kなど)はモデルが扱えるテキスト量を増やすだけであり、Liu et al.(2023)が指摘したとおり、モデルは長いプロンプトの中間部分の詳細を無視します。RAG(検索拡張生成)は履歴から関連情報を探そうとしますが、そのクエリは「現在のクエリに関連する情報は何か」に留まり、「その情報はまだ有効か」や「どの履歴上の意図が現在のタスクに影響を与えるべきか」までは追求しません。結果として、エージェントはすべてのルールを記憶できていても、それらのうちどれが今適用されるべきかを判断できないのです。記憶の失敗が問題なのではなく、何が重要かを決定する能力こそが欠けているのです。

アーキテクチャと実装詳細

筆者はこの能力を「意図連続性」(Intent Continuity)と明確に命名し、三層の階層構造で定義しています。最下層がRetrieval(検索)で「どんな履歴情報が関連する可能性があるか」を問い、中間層がVerification(検証)で「その情報はまだ有効か」を問い、最上層のIntent Continuityが「どの履歴上の意図が現在のタスクに影響を与えるべきか、そして新しいルールで上書きされるまでその効果が持続するか」を問います。この三層はピラミッド構造をなし、現在のほとんどのAgent記憶方式は最下層に留まっています。

実装は純粋なPython(Python 3.12)で構築されており、ベクターデータベース、埋め込みモデル、LLM呼び出しは一切使用していません。コアとなるアイデアは、意味的類似度に依存せず、軽量な「要件登録・検証パイプライン」を構築することです。システムは要件リストを保持し、新しいタスクごとにまず基本的な検索(キーワードマッチや直接的な関連文の照合)を行い、暫定的な要件候補セットを取得します(この段階でのカバレッジは約57%)。次に独立した検証層が追加され、各候補要件が現在のコンテキストでまだ有効かどうか(たとえば、より新しいルールで上書きされていないか)をチェックし、最終的に実際に遵守すべき要件リストを絞り込みます。この検証層こそがカバレッジを57%から100%に引き上げる鍵です。

筆者はさらに、初期実験のバグを正直に報告しています。最初のバージョンでは検証層と検索層の結合が不適切で、本来は無効になるべきルールが誤って保持され、結果が実際より良く見えてしまったとのことです。修正後のデータはより正確でしたが、逆説的に検証層の決定的な役割を証明しました——検証層がなければ、システムはルールを「過剰遵守」し、不必要な制約を導入してしまうのです。

実測ベンチマークと実用的価値

筆者は8つの代表的なタスクで比較実験を実施しました。ベースライン(履歴検索なし、現在のリクエストのみ)の正解数は0、基本検索を追加すると4つ正解、そして完全な意図認識方式(検索+検証)では8つすべてが正解しました。すべてのデータはPython 3.12による実際の実行に基づいており、外部依存関係はありません。コードはGitHub(Emmimal/intent-continuity)で公開され、`run_experiment.py`で再現可能です。

この結果の工学的価値は、その極めて低いインフラコストにあります。ベクターデータベースの構築、高価なLLMによる埋め込み計算、インデックスサービスの維持が一切不要です。純粋なPythonの軽量ライブラリだけで、長期間動作するコーディングエージェントにルールの継続性を提供できます。数週間にわたるリファクタリング、大規模コードベースにおける履歴制約の追跡、チームメンバーが交代しながらプロンプトを調整するシナリオなどで、この方式は最小限のコストでエージェントの動作安定性と安全性を大幅に向上させることができます。

今後の展望と技術的示唆

現在の業界におけるAgent記憶の議論は、ほとんどが「いかに多くの履歴を保存するか」と「いかに高速に検索するか」に集中しています。本稿の研究は、別の道筋を示しています——記憶容量を無限に拡大する代わりに、エージェントに「どの記憶が今重要か」を判断させることです。意図連続性は、本質的にメタ認知能力をAgentアーキテクチャに導入するものです——受動的に「すべてを記憶する」のではなく、能動的に「忘れるか継承するかを決定する」のです。

今後の進化としては、明示的なルール依存関係グラフと組み合わせてルールのバージョン管理や自動失効を実現すること、軽量な検証モデルと統合してルール競合時に優先順位を自動調整することなどが考えられます。長期間のメンテナンスを必要とするコーディングエージェントにとって、意図連続性はどんな巨大なコンテキストウィンドウよりも実用的かもしれません。それは私たちに、エージェントに必要なのはより長い履歴ではなく、より賢い意図の継承であることを再認識させてくれます。

Sources

FAQ

コーディングエージェントが長期プロジェクトで直面する核心的な問題は何ですか?

長期プロジェクトで初期のルールを頻繁に忘れ、データベースID漏洩などの深刻な問題を引き起こし、一貫性とセキュリティを損なうことです。

従来の解決策(大コンテキストウィンドウ、RAG)ではなぜ忘却問題を完全に解決できないのですか?

モデルが全テキストを記憶しても、古いルールが現在のタスクに重要か自動判断できません。従来手法は記憶容量を拡大するだけで、能動的な検証や優先順位判断が欠けています。

「意図連続性」アプローチの核心アイデアと実装の特徴は何ですか?

基本的な検索+検証層を用い、ゼロベクトルDB、ゼロ埋め込み、ゼロLLM呼び出しで、要件カバレッジを57%から100%に向上し、8テストタスク全てを合格。元の実験のバグも正直に開示しています。