【ITニュース解説】The Hard Part of AI Coding Agents Isn't Writing Code — It's Preserving Engineering Context

AIを活用したコーディングエージェントは、近年驚くほど進化し、既存のコードベースを読み込み、それに合わせて変更を加える能力が向上してきた。しかし、長期にわたるプロジェクトでこれらのエージェントを利用する中で、コード自体は残るものの、そのコードが「なぜ」存在するのかという、いわゆる「エンジニアリングの文脈」が失われてしまうという新たな問題が浮上している。

新しいエージェントは、ある検証ルールが存在することを知っていても、そのルールがなぜ必要とされているのかまでは理解できない場合がある。また、実装された動作を目にしても、それが承認された要件に基づいているのか、アーキテクチャ上の重要な決定によるものなのか、あるいは単に以前のエージェントが推測で実装した結果なのかを判別できないといったケースも発生する。プロジェクト期間が長くなるにつれて、このような「なぜ」という根拠の有無が、開発の品質や効率に大きく影響することが明らかになってきた。

この問題の根本は、単にAIエージェントに与える情報の量が不足しているという点ではない。当初は、より良いプロンプトや、大量のプロジェクト指示ファイル、あるいはセッションごとに多くのドキュメントを提供することで解決できると考えられたが、それは表面的な解決策に過ぎなかった。ソフトウェア開発プロジェクトには、単なるコードだけでなく、「システムが果たすべき機能」「特定のアーキテクチャが採用された理由」「正式に承認された要件」「既に考慮済みの例外ケース」「実装が満たすべき制約」「まだ決定されていない事項」「変更が完了したと判断する基準」など、多種多様な知識が存在する。これらの知識を一つの大きなファイルに詰め込んでも、かえって情報が散漫になり、適切な利用は困難になる。問題の本質は、エンジニアリング知識に「明確な構造」を与えられていないことにある。

コードは「何が存在するか」という現在の事実を語るが、「何が存在すべきか」という意図や根拠までは語らない。例えば、「ユーザーは60分以内に5回まで操作を再試行できる」というコードがあったとして、エージェントはそれが現在のルールであることを知る。しかし、それが製品の要件なのか、なぜそのような制限が必要なのか、変更するには人間の承認が必要なのか、他の機能に依存性があるのか、といった情報はコードからは直接読み取れない。エエージェントはこれらの情報を推測しようとするが、推測はあくまで推測であり、誤った判断につながる危険性をはらんでいる。重要なエンジニアリングの意思決定において、エージェントに「最も妥当な推測」をさせるべきではなく、「権威ある情報が不足しているため、この決定はできない」と明確に伝達させるべきである。

このことから、知識の欠如はエージェントに推測を促す機会ではなく、明確な意思決定プロセスを経るべき「結果」として扱われるべきだという原則が生まれた。理想的な開発プロセスは、「権威ある知識がない」→「知識のギャップを認識」→「人間による意思決定」→「権威ある知識の確立」→「実装」という流れである。これにより、人間はエージェントが推測して実装した後のコードをレビューするのではなく、実装が行われる前に重要な意思決定を下すことが可能になる。これは、後の手戻りを防ぎ、品質を確保する上で非常に重要な違いとなる。

これらの課題に対処するためには、異なる種類のエンジニアリング知識に、それぞれに適した「権威ある保管場所」を与える必要がある。例えば、機能の振る舞いがアーキテクチャの文書の中に埋もれていたり、アーキテクチャ上の制約がAIエージェントへのプロンプトの一部として曖昧に存在したり、製品に関する意思決定がチャットのログの中にしか残っていなかったりする状況は望ましくない。また、検証の結果が、検証対象であるはずの要件自体を暗黙のうちに再定義してしまうことも避けるべきである。筆者は、プロジェクトやドメインに関する知識、具体的な仕様、アーキテクチャ上の決定、再利用可能な振る舞いの契約、エンジニアリングのワークフロー、検証やレビューの基準といった要素を明確に分離する構造を試している。どのような具体的な構造を採用するかよりも重要なのは、「この知識はどこに属するのか？」という問いに、常に明確な答えがあるという原則である。

さらに、AIエージェントが単なるコードスニペットの生成を超えて、プロジェクト全体の検査、複数のファイルの変更、テストの実行、そして一連のワークフローの継続までできるようになると、「人間がプロセスに関与する（Human in the loop）」という概念も変化する。エージェントがほとんどの作業を完了させ、人間がそれを後から確認するだけになってしまうと、それは「承認」とは異なる意味を持つ。特定の重要な工程においては、人間による明示的な承認が不可欠である。例えば、「人間の意図」→「仕様」→「人間の承認」→「実装」→「検証・レビュー」という流れを設けるべきだ。エージェントは仕様の発見や定義を支援できるが、システムが何をすべきかを承認する責任は、それを実装する責任とは明確に区別されるべきであり、この境界線は非常に重要となる。

検証とレビューのプロセスにおいても同様の境界線が存在する。検証段階で問題が発見された際、その場でエージェントに修正させ、プロセスを続行させたくなる誘惑に駆られることがある。しかし、これでは検証の目的が「実装が期待される振る舞いを満たしているか」を評価することから逸脱し、評価対象そのものを変更する行為になってしまう。問題が発見された場合は、適切なエンジニアリングワークフローに戻して修正を施し、その後、新しい状態に対して再度評価を行うべきである。これにより、検証は「証拠に基づく評価」としての本来の役割を保ち、自己修正のプロセスとは切り離される。

これらの考えを具現化したのが、オープンソースプロジェクト「Gnomon」である。Gnomonは、AIコーディングエージェントを活用してソフトウェアを開発する際に、プロジェクト知識、仕様、人間の意思決定、実行、そして検証を明示的に分離するためのコマンドラインインターフェース（CLI）とリポジトリ構造を提供する。Gnomon自体がClaude CodeやCodexといったコーディングエージェントを代替するものではなく、これらのエージェントがリポジトリを検査し、コードを書き、テストを実行し、実際のエンジニアリング作業を行うための「より良いエンジニアリング環境」を提供することを目指している。

Gnomonにおける開発のライフサイクルは、「人間の意図」→「関連するプロジェクト知識」→「仕様」→「人間の承認」→「エージェントの実行」→「テスト/証拠」→「検証/レビュー」→「次の変更」という簡潔な流れで構成される。すべての情報はリポジトリ内でローカルに管理され、永続的な知識は主にMarkdown形式で、必要に応じて少量の構造化されたアーティファクトで構成される。データベースやホストされたサービスは不要であり、プロジェクトを別のプラットフォームに移行する必要もない。

Gnomonを実際のプロジェクトに適用する中で、予期せぬ問題も明らかになった。例えば、CLI自体が、以前の設計変更で削除されたコマンドを推奨してしまうケースなどである。根本的なワークフローは正しかったものの、提供されるガイダンスが古くなってしまっていた。この問題を解決する過程で、「推奨コードが、エンジニアリングにおける新たな真実の源となるべきではない」という新たな原則が生まれた。現在では、CLIが提示する利用可能なアクションは、システム全体で使われている適格性ルールから導き出されるようになっている。これは小さな例だが、より大規模な視点で見れば、まさに防ぎたいと考えていた情報の乖離（ドリフト）の一種である。

Gnomonはまだ初期段階であり、長期的なソフトウェア開発プロジェクトでコーディングエージェントと協調するための最終的な答えを見つけたとは言えない。どの程度の構造が効果的で、どこからが官僚主義になるのか、自動化された環境で人間の承認はどのように機能すべきか、特定のタスクに対してエージェントはどの程度の知識を読み込むべきかなど、興味深い問いがまだ残っている。しかし、確信しているのは、単に優れたコード生成能力だけでは、エンジニアリングの根本的な問題は解決しないということだ。エージェントの実装能力が向上するにつれて、その実装を取り巻く「なぜそう決まったのか」という推論、意思決定、制約、そして証拠を正確に保存し、維持することの重要性はますます高まっている。Gnomonは、この問題を探求し、解決を目指すオープンソースプロジェクトとして進行中である。