生成AIは、設計では選択肢を広げ、実装では小さな差分を作り、テストでは見落とした条件を列挙するために使えます。
同じ「作って」という指示を全工程へ使うと、誰が要件を決め、何を根拠に合格したのかが曖昧になります。
工程ごとに入力材料、AIの権限、人が承認する証拠を変えることが安全な活用の基本です。
生成AIの導入範囲を専門家と決めたい場合は、アプリ開発の目的別相談ガイドで外注と内製の境界を比較できます。
| 工程の出口 | AIへ渡す材料 | 人が承認する証拠 |
|---|---|---|
| 設計の確定 | 調査結果、制約、未決事項 | 採否理由付きの仕様 |
| 実装の完了 | 対象ファイル、再現手順、テスト | 小さな差分と実行結果 |
| テストの終了 | 期待結果、境界値、過去障害 | 再現可能な合否記録 |
AI製品そのものの選び方は、AI開発ツールを工程別に比較したガイドで整理しています。
設計、実装、テストで生成AIの役目を切り替える
工程ごとに「AIが提案してよい範囲」と「人が決める範囲」を表にします。
| 工程 | AIへ頼む作業 | 省略させない条件 | 合格証拠 |
|---|---|---|---|
| 課題整理 | 発言の分類、矛盾の抽出 | 元の観察記録 | 発言ID付きの論点表 |
| UI設計 | 複数案と利点欠点 | 対象者とアクセシビリティ | 選定理由と試作結果 |
| コード実装 | 限定した変更案 | 対象外ファイルと既存規約 | 差分、ビルド、テスト |
| コードレビュー | 不具合候補と質問 | 人による最終判断 | 指摘の採否と根拠 |
| テスト設計 | 境界値と異常系の候補 | 期待結果の人間定義 | 失敗から成功への記録 |
Googleのプロンプト設計ガイドは、文脈、明確な指示、制約、例、出力形式を組み合わせ、結果に応じて反復する方法を説明しています。
OpenAIのコード生成ガイドは、コードの作成、レビュー、編集、デバッグを代表的な用途として案内しています。
OpenAIのEvalsガイドは、評価対象、入力データ、採点方法を明示して反復測定する流れを扱います。
GitHubのAI生成コード確認ガイドは、生成コードを人が正しさ、安全性、保守性の観点でレビューする実務を示しています。
設計では事実と提案を別の列へ出させる
利用者調査の記録を要約させるときは、元の発言とAIの解釈を混ぜません。
各論点へ発言IDを付け、「確認された事実」「推測」「追加質問」の三列で返させます。
GOV.UKのユーザー調査計画は、根拠のない仮定や意見を調査質問へ変え、優先する問いを合意するよう案内しています。
生成AIが補ったペルソナを実在利用者の証拠として扱わず、調査で確かめる仮説へ戻します。
| 出力の区分 | 記載例 | 次の扱い |
|---|---|---|
| 確認事実 | 参加者P03は入力に四分かかった | 設計判断の根拠候補 |
| 推測 | 項目名が原因かもしれない | 次回調査の質問 |
| 提案 | 入力欄を二つに分ける | 比較する試作案 |
設計書にはAIとの会話全文ではなく、採用した案、却下した案、判断者、根拠を残します。
後から前提が変わったとき、どの決定を再検討すべきか追える形が重要です。
実装では差分を小さくして実行証拠を求める
生成AIは広い変更を一度に提案できますが、レビューできない差分は速く作れても安全に統合できません。
一回の依頼を、一つの不具合、一つのAPI、一つの画面状態へ限定します。
- 失敗を再現するテストか操作手順を固定する
- 変更可能なファイルと触らない領域を指定する
- 実装前に変更案とリスクを短く出させる
- 差分と実行した検証を確認する
- 想定外の変更があれば分割してやり直す
生成されたコメントや型名が自然でも、実際のライブラリ版と一致するとは限りません。
コンパイル、静的解析、自動テスト、実機操作の順に、機械で再現できる証拠を増やします。
テストでは期待結果をAIより先に決める
AIへテストと答えを同時に作らせると、誤った実装に合わせた誤った期待値が通る可能性があります。
商品仕様、法令、過去障害、利用者行動から、人が重要な期待結果を先に定めます。
NISTのSecure Software Development Frameworkは、安全な開発実務を開発ライフサイクルへ組み込む共通枠組みです。
OpenAIの評価ガイドも、評価の目的とデータを用意し、変更を同じ条件で比較する手順を示しています。
AIには、未入力、最大長、同時操作、通信断、時刻境界、権限拒否の候補を追加させます。
追加されたテストの期待結果は仕様へ照合し、仕様がなければ実装前に担当者が決めます。
生成AI活用を六つのゲートで進める
便利な出力が得られた時点ではなく、次の条件を通過した時点で工程を進めます。
- 入力へ機密情報が含まれないか確認する
- AIへ許可する読取りと書込みの範囲を決める
- 提案と事実を区別した出力形式を指定する
- 変更を小さな差分として生成する
- 自動検証と人のレビューを通す
- 採否理由と残ったリスクを記録する
ゲートを省略する特例を設ける場合は、対象を公開サンプルや捨てる試作へ限定します。
本番データ、署名鍵、課金設定を扱う操作は、AIの自動実行範囲から外してください。
12画面で異常系テストを増やす計算例
ここでの数字は品質基準ではなく、AIへ候補を出させる前の見積例です。
十二画面に主要操作が二つずつあるなら、正常系は二十四件あります。
| テスト群 | 算出 | 件数 |
|---|---|---|
| 正常な主要操作 | 12画面×2操作 | 24件 |
| 空入力と最大長 | 8入力欄×2条件 | 16件 |
| 通信断 | 5通信処理×1条件 | 5件 |
| 権限拒否 | 3権限×1条件 | 3件 |
| 合計 | – | 48件 |
AIがさらに二十件を提案しても、重複と仕様外を除き、採用理由を付けた件だけをテスト資産へ入れます。
件数を増やすことより、重大な失敗を再現でき、修正後も同じ条件で回せることを優先します。
指示文を仕様、制約、証拠、停止条件に分ける
長い依頼文を書くより、四つの見出しへ情報を分けると抜けを確認しやすくなります。
仕様: 利用者がメールアドレスを入力して確認コードを受け取る
制約: 認証モジュール以外を変更せず、新しい依存を追加しない
証拠: 既存テストと追加する三つの異常系テストを実行する
停止条件: 仕様が不明、外部契約が必要、対象外ファイルの変更が必要なら実装せず質問するプロンプトには成功時だけでなく、判断できないときに止まる条件を入れます。
実行権限のあるエージェントでは、外部送信、削除、公開、購入を別の承認へ分けます。
生成AI活用のよくある質問
AI生成コードはそのまま使っても安全ですか？
そのまま安全だとは判断できず、既存コードと同じレビュー、テスト、依存関係確認が必要です。
GitHubの公式チュートリアルは、AI生成コードの機能、セキュリティ、品質を人が確認する手順を説明しています。
認証、暗号、課金、個人情報を扱う差分には専門レビューも追加してください。
生成AIにテストケースを作らせてもよいですか？
境界値や異常系の候補作成には使えますが、期待結果をAIだけで決めると実装の誤りを追認する危険があります。
OpenAIのEvals公式ガイドに沿い、評価対象、データ、採点条件を先に定めて同じ入力で変更前後を比較します。
AIが追加したケースは、仕様根拠と採否理由を付けてから正式なテストへ入れてください。
バイブコーディングは初心者にも向きますか？
画面を素早く試す用途には向きますが、生成されたコードを理解せず本番公開する方法ではありません。
Google AI StudioのBuildモード公式説明は、プロンプトからアプリを生成し、コードを表示、編集、書き出す流れを案内しています。
初心者は一経路だけ生成し、各ファイルの役割、データ保存、エラー処理を説明できることを次の条件にします。
生成速度ではなく検証可能な変更を増やす
生成AIの価値は、コード量ではなく、判断と確認に使える選択肢を短時間で増やすことです。
- 設計では、確認事実、推測、提案を別の列で扱います。
- 実装では、一つの再現手順と小さな差分を一回の依頼単位にします。
- テストでは、人が決めた期待結果へAIの異常系候補を追加します。
- 十二画面の例では、正常系二十四件を起点に合計四十八件を数えています。
- 本番へ進める証拠は、差分、自動検証、人の採否理由、残存リスクです。
特定製品での指示と検証を具体化するなら、ChatGPTでアプリ開発を進める手順も続けて確認してください。
