私は今、AIエージェントに実装やテスト、レビューを分担させながら、ソフトウェア開発を進めています。
作っているのは、利用者が情報を入力し、計算した結果を画面で確認する試作ツールです。
その開発で、「機能を実装した」と言う前に何を確かめればよいのか、考え直す出来事がありました。
新しい入力項目のコードはあるのに、普段使う画面には出てこない。別の変更では、画面の見出しは正しいのに、表示されるデータが別の処理から作られていました。
どちらも、部品の存在や画面の見た目だけでは気づきにくい問題です。
AIエージェントに実装を任せる場合は、何を作るかだけでなく、どの画面から何を操作し、どの処理の結果が表示されたら完成なのかも指定する。 今回は、実際の開発で見つかった不一致をもとに、その確認方法を整理します。
なお、これらの不具合がAIエージェントを使ったために起きたとは確認できていません。
30秒でいうと
- 新しい入力項目のコードはあっても、通常画面は古い一覧を参照していた
- 別の画面では、見出しと実際のデータ生成元が一致していなかった
- 既存テストでは主要な画面操作を確認していたが、詳しい比較表示や画面遷移は当時の対象外だった
- 完成条件には、普段使う画面からの操作とデータの出どころの確認まで含める
2つの不一致が同じ原因で起きたと証明できたわけではありません。ただ、どちらも「作った部品が実際の画面で正しく使われるか」という問いにつながっています。
新しい機能があるのに、いつもの画面には出てこない
最初に見つかったのは、新しい入力項目と画面の食い違いです。
開発用の別ブランチには、追加した項目を扱うコードがありました。ところが、通常の入力画面には古い項目が表示されたままでした。
原因は、画面が入力候補を読み込む場所にありました。新しい項目の定義があっても、通常画面は以前の一覧を参照していたのです。
構造だけを単純化すると、次のようになります。
新しい入力項目 → 新しい定義に追加済み
通常の入力画面 → 古い候補一覧を参照
この段階で確認すべきだったのは、追加したコードの有無だけではありません。利用者が実際に開く画面で、新しい項目を選べるかどうかです。
画面に正しい名前が出ても、中身が違う
次の不一致は、見た目だけではさらに分かりにくいものでした。
この試作ツールには、別々の処理で作った計算結果を比較して表示する画面があります。ここでは、その2種類を結果Aと結果Bと呼びます。
本来、結果Bの画面にはB用の処理で作られたデータが届くはずです。しかし実際に調べた記録では、Bの表示ラベルが付いた画面に、A側の結果に由来する表示用データが渡る経路が見つかりました。
期待した経路
入力B → B用の処理 → 「結果B」の画面
見つかった経路
A側の処理 → A由来の表示用データ → 「結果B」の画面
これは仕組みを説明するための模式図で、実際のソースコードをそのまま写したものではありません。
画面が開き、名前やデータが表示されるだけなら、こうした違いを見逃すおそれがあります。「結果B」と書かれていることを検査しても、裏側のデータがB用の処理から来たことまでは確かめられません。
必要なのは、画面の表示と、実際にデータを作った処理を結び付けて確認することでした。
この2件は、見つけて終わりではありません。最初の例では入力候補の参照先を修正し、通常画面で使うコードに反映しました。2件目でも、表示用データを本来の計算結果から受け取るよう修正し、実際の画面を操作するテストで対応関係を確認しました。これらの変更は、その後mainブランチへ取り込まれています。
ただし、関連する画面の確認事項がすべて完了した、という意味ではありません。
AIエージェントへの実装指示と、完成を認める条件は別
AIエージェントに実装やテストを任せても、何をもって完成と判断するかは別に定める必要があります。
例えば「結果を比較する画面を追加して」と依頼したとします。画面のコードができ、画面が表示されれば、実装が進んだことは分かります。しかし、それだけでは通常画面から操作できるか、結果BにB用の処理で作られたデータが表示されるかは確認できません。
「比較画面を作る」は作業内容。「通常画面から操作でき、結果BにB用の処理の出力が表示される」は完成条件。 今回の2つの事例は、この区別が必要な理由を示しています。
そこで、今後の依頼に使う完成条件を6項目に整理しました。これは今回の経験からの提案であり、過去に実際に送った指示を再現したものではありません。
- 通常の画面を開き、そこから実際に操作できること
- 新しく追加した項目が、その画面の選択肢にも反映されていること
- 表示した結果が、意図した処理と入力データに由来すること
- 入力を訂正したら、訂正前の入力から作った結果を新しい結果として表示しないこと（結果がどの時点の入力に対応するか区別できること）
- テスト用の近道だけを使わず、利用者が操作する入口から一連の流れを確かめること
- 完了報告に、どの画面から操作し、どの入力を使い、何を確認したかを記載すること
特に3番目は、表示画面が自分で名乗っている名前だけを調べても十分ではありません。入力から結果を作る処理までたどり、表示内容の出どころを確かめる必要があります。
結果に生成元の処理を示す識別情報を付け、画面側のテストで期待した処理と照合する方法も候補になります。これは今後の検証案であり、今回その方法の効果を確認したわけではありません。
単体テストは、個々の部品の動きを確認するために必要です。ただ、今回のような不一致は、部品のテストや「画面が表示された」という確認だけでは見落とす可能性があります。
利用者が操作する入口から結果の表示まで、一連の流れをたどります。その際、何が表示されたかだけでなく、どの入力を、どの処理が使い、その結果が画面に渡されたかを確認する必要があります。
E2E（エンドツーエンド）テストでも、データの出どころを受け入れ条件に含めなければ、今回のような不一致を検出できるとは限りません。
既存のテストでも、画面の主要な操作は確認していました。一方、開発途中の画面については、比較後の詳しい表示や画面遷移を当時の検証対象から外していました。
これが今回の不一致を見逃した直接の原因だとまでは分かりません。今回の教訓は、画面やデータの経路を追加した際に、既存テストがどこまでを検証対象としているか確認し直すことです。
「完了した」と「何を確認した」は分けて記録する
エージェントとの開発では、実装・テスト・レビューを別々の作業として進めることがあります。そのとき、部品の実装が終わったという報告だけでは、通常の画面まで確かめたかは分かりません。
完了報告には実装やテストの実施有無だけでなく、どの画面から操作し、どの入力を使い、何を確認したかを残します。
ただし、これらの完成条件をすべての画面で検証し終えたわけではありません。実際に起きた不一致と、今後の確認項目として整理した条件は区別しています。
何をまだ言えないか
今回の事例から、AIエージェントは人間より接続ミスを起こしやすい、と結論づけることはできません。また、2つの不一致に一つの共通原因があったと証明したわけでもありません。
提案した完成条件やE2Eテストが、あらゆる不具合を防ぐとも言えません。
今回の事例から得た教訓は、AIエージェントに実装やテストを任せることと、その成果を完成と認めることは別だという点です。
「通常の画面から操作できる」「表示されたデータが正しい処理から来ている」という判定条件を依頼時点で明示する。そして、実際に確認できた範囲だけを完了と扱う。その区別が、今回の開発で必要になりました。
AI利用について
取り上げた開発では、実装・テスト・レビューにAIエージェントを利用しています。この記事の構成や文章化にもAIを利用しました。技術的な経緯については、開発時のIssueや記録と照らし合わせています。