AIに実装と評価を分担させていると、評価役からの不合格をどう返して修正させるか、迷う場面があります。実装役へ渡すのは、満たしていない受入条件と、修正後に再確認する操作です。依頼時に決めた条件を、修正と再評価の基準にも使います。
2026年8月、思い出を記録するアプリのローカル試作を、5つのスプリントに分けてAIへ実装を任せました。計画役が条件を決め、実装役がコードを変更し、評価役が仕様と操作結果を確かめる分担です。
前提は、依頼時に完了条件を決めておくこと
最初に作ったのは、題名だけの思い出を保存し、再起動後も見返せる範囲です。依頼時の完了条件（受入条件）には、一連の流れを標準文字で操作できることと、変更した画面の必須操作がiPhoneの最大文字サイズでも使えることが含まれていました。評価役はこの条件に照らして、合否を判断します。
不合格を、未達の条件と再確認する操作で返す
評価役が最大文字サイズで新規インストールから初回案内を開くと、「理解して始める」をタップできず、操作テストは不合格でした。案内のカードが画面より高くなり、スクロールできないため、開始ボタンが画面外に残っていたと記録されています。
案内を終えられなければ、最初の記録を作る画面へ進めません。依頼した「題名だけの思い出を残して見返す」という目的に届かないため、次へ進む前に直す指摘として実装役へ差し戻しています。
この指摘を、修正を依頼する書式へ組み直すと次のようになります。当時のレポートの原文ではなく、評価記録をもとにした要約です。
対象:
iOS 26.5のiPhone Simulatorへ新規インストールしたアプリの初回案内。
文字サイズはアクセシビリティ設定の最大。
満たしていない受入条件:
「変更した画面の必須操作を、最大文字サイズでも使えること」。
起きている問題と影響:
開始ボタンが画面外に残り、案内を終えられない。
最初の記録を作り始められない。
修正後に再確認する操作:
同じ初期状態と最大文字サイズで案内を開く。
説明を読めて、スクロールして開始ボタンを実行できることを確かめる。
標準文字での開始操作も維持できているか確認する。
この形なら、直す対象、依頼時のどの条件に届いていないか、修正後に何を操作するかを揃えて返せます。評価で使った条件が、そのまま修正依頼と再評価の基準になります。
修正後は、同じ条件で操作して合否を決める
修正では、初回案内を画面内に収まる高さに制限し、説明文と「理解して始める」を同じ縦スクロール領域へ入れました。
再提出を受けた評価役は、アプリを新規に入れた状態から操作を再確認しています。
- 最大文字：初回案内をスクロールして開始ボタンを表示し、実行できた。
- 標準文字：初回案内から保存・詳細・一覧への移動と、再起動後に記録が残ることまで通した。
最大文字で確かめた必須操作と、標準文字で通した一連の流れは、確認範囲が異なります。これらの操作結果と型チェック・テストを根拠に、最初のスプリントは合格になりました。
修正報告には、変更した箇所に加え、どの環境で何を操作できたか、その証拠と未確認項目を残します。評価役は報告を受け、元の受入条件に照らして操作を再確認します。修正したという報告から、条件を満たしたという判断へ進むための受け渡しです。
不合格を返すときのテンプレート
以下は、自分の開発で使うために組み直した提案テンプレートです。実装役へ返す一件の指摘について、該当する受入条件と、修正後の確認方法を埋めます。
対象:
問題が起きる画面・処理と、対象のソースの版。
問題を再現した環境と初期状態。
満たしていない受入条件:
元の依頼文から、今回満たせていない条件を書く。
起きている問題と影響:
どの操作で何が起き、利用者が何をできないのかを書く。
修正後に再確認する操作:
- どんな環境・初期状態から始めるか。
- どの操作をし、何が起きれば合格か。
- 変更後も維持する既存動作は何か。
修正報告に含めるもの:
変更箇所、対象のソースの版、確認した環境、操作と結果、その証拠。
未確認の項目があれば、確認済みの結果と分けて書く。
計画役・実装役・評価役の分担や、再試行を止めて判断を戻す条件は、ハーネス設計の記事で扱っています。このテンプレートは、評価役から実装役へ一件の不合格を返す場面に使います。
まずは一つの指摘について、元の依頼文から該当する受入条件を抜き出し、修正後に確かめる操作と組にしてみてください。修正依頼と再評価で見るものを揃える出発点になります。