要件変更に耐えうるエージェントの育てかた
Date2026/09/24
Last Modified2026/09/24
概要
「ちょっと要件変わったんだけどさ……」
なんてことが、一日の中で何度かある。朝に決まった要件を実装してたら夕方にはもう変わってる。
初めはもっと要件定義をきれいにしてからと思っていたけれども、どうやら無理だと気づいた。何ひとつ確定事項など存在しない。
「これは絶対に変わらない」と言質を取っても「やっぱりお客さんがダメっていうから変えて」となるので、全てが変わる前提で動かないといけない……。
AIコーディングの時代、作り替えることは容易になってきた一方、AIにも変更に対する耐性の限度というものがある。
一度言ったことを忘れず遂行してくれるAIでも、過去のログが堆積してくるとどれが正しい情報なのかわからなくなってパフォーマンスも落ちてくる。
しかしながらドキュメントは人の手で管理できる限界があり……となればAI自身が自浄作用を以って変更に強くなってもらおう。
そんなわけで、要件変更の多い案件でも耐えうるエージェントの育て方について調べてみた。
そもそも論理的であれば長くても正確に答えを出す
「AとBを実装して」「AにはCとDをくっつけて、Bは廃止して」「やっぱり逆で、Aを廃止してBにCとDをくっつけて」
こんな変更が続くと、人間はいったい何が何だかわからなくなってくる。新しいものがどんどん増えてくるよりも、出したり引っ込めたりされる方がキツイ。
しかしこれは、AIが非常に得意とするところである。すべての条件が正確に与えられていれば、最終的な結果を間違えることはほぼないと言ってもよい。
なので、似たような変更がたくさんあること自体は別にAIにとってはそれほど負荷ではないのだ。
その一方で弱点があるのは「コンテキストの圧縮による取り違え」である。
例えば「9/1にAをBに変更」というログと「9/5にやっぱりAをCに変更」というログがあったとして、たまたま日付に関する記述を見落としてしまった場合は「どっちが最新の変更なんだろう？」という風に迷って、判断材料が他になければ間違ってしまう。
特に起こりやすいのが、ドキュメントが散在していて構造化されていないときなどで、仮にどこかに正解が書いてあったとしても埋もれてしまうことがある。
このことから、大量の情報を保持しながら最新の要件を正しく把握してもらうには、以下の要素が必要になる。
- 導線の辿りやすいドキュメント構造
- 最新状態と過去ログを明確に別の場所で管理する
- 過去のステータスは必ず変更済みとわかるように明記する
ADRという取り組み方
ADR(Architecture Decision Record)とは？
ソフトウェアやシステムの設計において、重要な技術的決定とその背景（なぜその選択をしたのか）を記録する短いテキスト文書
例としてはこのような感じ。