AIに実装を頼む前に

「問い合わせフォームを作って」と頼むと、見た目はすぐに完成します。でも、空欄の扱い、二重送信、通知の失敗はどうなっているでしょうか。画面を見てから要件を足すと、実装と確認を何度も往復することになります。

作る前に、利用者の操作と、その結果を対にして書きます。受け入れ条件は、完成を判断するための約束です。コードの内部構造より、担当者が実際に確かめられる言葉を使います。以下は架空の問い合わせフォームの設計例です。

「使いやすい」を、観察できる結果へ変える

「使いやすくする」だけでは、実装者と依頼者で判断が分かれます。「必須項目を空のまま送信すると、項目の近くに理由が表示され、入力内容は消えない」なら、同じ操作で確かめられます。AIへの指示にも、確認用のテストにも使える粒度です。

通常の成功だけを定義すると、失敗後の動きが実装者任せになります。必須項目の不足、通信の失敗、同じ送信の繰り返しを選び、何を保存し何を表示するかを書きます。すべての例外を列挙する前に、影響の大きい場面を決めると議論が進みます。

条件ID：FORM-03
前提：利用者が必要項目を入力している
操作：送信ボタンを1回押す
期待結果：受付IDが表示され、受付が1件保存される
失敗時：保存が確定しない場合は、完了と表示しない
再操作：同じ受付を意図せず増やさない方針を別途定義する
確認先：画面・保存先・処理記録

再操作の方針は、「同じ内容ならすべて拒否」では済みません。同じ利用者が別の相談を送ることもあるためです。何を同じ受付と見なすか、識別子の単位まで合意します。

通知失敗時に誰が再送するか、受付データをどの期間残すかなど、開発担当だけで決められない条件があります。未決事項の欄に判断者と確認日を残します。AIに空欄を埋めさせると、もっともらしい仕様が合意済みとして混ざりやすくなります。

CyberAgentの仕様書作成の記事は、関連する情報や用語を整えてからAIへ渡す取り組みを紹介しています。本稿の小さな条件表も、何を正とするかを先にそろえる考え方です。他社のフォーマットをそのまま使うのではなく、今回の利用経路に必要な欄へ絞ります。

条件がFORM-01〜05なら、実装の説明と検証記録にも同じIDを付けます。変更が入った際、どの確認をやり直すかが分かります。テストが通っただけで業務要件も満たしたとせず、画面・データ・通知など条件に書いた結果を確認してください。

最初の依頼に付けるのは、長い仕様書でなくても構いません。利用者、操作、成功、失敗、未決事項がそろえば、実装前に話すべき点が見えます。作成後の確認項目は、AIコードのPRチェック7項目へつなげられます。

2026年11月2日確認。本文の例・図・ひな型は本記事用に作成したものです。以下は、設計や事例の背景として参照した一次資料です。