AIにコードを書いてもらう前に、完成条件と変更範囲を渡す
動いた画面だけで判断せず、仕様・差分・確認結果を残す開発を始めます。
公式資料確認資料確認：2026年10月3日。完成条件・依頼書・確認手順は編集上の提案です。本稿の例に対応する生成コードの実装・動作検証は未実施です。
AIに「検索を付けて」と頼む前に、何を残し、何ができれば合格かを書きましょう。この記事では、小機能1つの実装依頼書を作り、コードの差分と確認結果を完成条件へ対応付けます。
公式資料から分かること：履歴と差分は確認の材料
Gitの入門資料は、バージョン管理をファイルの変更を記録し、特定の版を参照できる仕組みとして説明しています。git diffは変更の比較に使います。ただし、履歴があることや差分が小さいことは、動作や安全性の保証ではありません。記録していない変更が自動で保存されるわけでもありません。
仕事の具体例：記事一覧にカテゴリ絞り込みを追加する
架空のサイトで、合格条件を「カテゴリを選ぶと対象記事だけ表示」「0件なら案内を表示」「既存の記事リンクと検索を維持」の3つにします。未公開情報を扱うなら、表示から隠すだけでなく、配信内容にも含まれない仕組みが必要です。HTMLへ埋め込んだ下書きを非表示にしても非公開にはなりません。
AIには、既存の構成を確認し、不明な前提を示したうえで変更するよう依頼します。作業中のユーザー編集は今回の変更と区別し、勝手な依存追加や無関係な書き換えを避ける条件も渡します。
コピーして使える実装依頼書
目的／利用場面：
現在の技術・構成：確認済み／不明
今回の変更対象：
変更しないもの：既存のID・リンク・検索など
合格条件：
1. 通常の入力では：
2. 空・0件・不正な入力では：
3. 既存機能と情報の公開範囲は：
依存追加・設定変更：必要なら理由と影響を提示
既存の未保存・未コミット変更を保持する
秘密情報・実データは例へ含めない
提出する結果：変更点／差分／試験結果／未確認事項
外部公開・送信：別途承認が必要結果の確認ポイント
- 変更前の状態と既存の編集を把握し、復元できる記録方法を用意する。
- 差分を読み、対象外の変更、設定変更、依存追加、秘密情報の混入がないか確認する。
- 合格条件ごとに、環境・操作・期待結果・実際の結果を記録する。画面が開くことだけを合格としない。
今回の変更箇所に加え、既存リンク・検索・該当なし・スマートフォンなど関連する利用経路も確認します。試験できなかった条件は未確認と書き、AIの「動きます」という説明で埋めないでください。認証、支払い、削除など影響の大きい処理は、責任者の確認を組み込みます。
今日試すこと
小機能1つについて合格条件3つと「変更しないもの」を書いてください。その条件を、生成依頼と確認記録の両方で使うと修正の範囲を追いやすくなります。
参考資料
- Git｜About Version Control：変更履歴の考え方。
- Git｜git diff：差分の比較。