AI開発の役割分担とチェック体制｜人の確認・自動テスト・公開判断の進め方
AIにコードの作成や修正を依頼すると、短時間でまとまった変更案を受け取れます。その一方で、「どこまで任せてよいのか」「何を確認してから採用すればよいのか」と迷うこともあるのではないでしょうか。
AI開発のチェック体制では、人が最後に読むことだけに頼らず、仕様・自動テスト・レビュー・公開後の確認を組み合わせます。この記事では、AIと人の役割を整理し、変更の影響に応じた確認手順を、小規模な開発でも使える形で紹介します。
目次
１．AIと人の役割は「得意・不得意」だけで決めない
AIは、コードの下書き、テスト項目の提案、既存処理の説明などに活用できます。ただし、提案が用途に合うかは、渡した情報や開発環境、変更内容によって変わります。「定型的な処理だから確認不要」とは判断できません。
例えば、データの登録・更新・削除はよくある機能ですが、誰が操作できるか、失敗時にどう戻すかによって設計が変わります。作業名よりも、間違ったときの影響と、結果を確かめる方法を基準に役割を決めましょう。
| 工程 | AIに依頼できる補助 | 担当者が確認・決定すること |
|---|---|---|
| 要件整理 | 不明点や確認事項の洗い出し | 必要な動作、対象者、優先順位 |
| 設計 | 複数案の提示、影響箇所の候補整理 | 既存構成との整合性、採用する方式 |
| 実装 | コードの作成・修正案 | 変更範囲、依存関係、権限の妥当性 |
| テスト | テストケースやテストコードの下書き | 期待結果、確認条件、実行結果の解釈 |
| レビュー | 問題候補の指摘、変更内容の要約 | 指摘の根拠、仕様への適合、残る課題 |
| 公開・運用 | 手順書や確認項目の下書き | 公開可否、実行権限、復旧方法、担当者 |
人にも見落としはあり、AIにも誤った指摘があります。そのため、「誰が確認したか」に加えて、「どの条件で、何を根拠に確認したか」を残すことが重要です。
２．変更の影響に合わせて、確認の深さを変える
すべての修正に同じ確認手順を適用すると、負担が増え、重要な確認に時間を使いにくくなります。一方で、小さく見える変更が、権限やデータ処理に影響することもあります。
まずは、利用者への影響、扱うデータ、元に戻せるかを確認しましょう。次の表は、確認方法を考えるための例です。
| 変更例 | 主に確認すること | 確認方法の例 |
|---|---|---|
| 説明文や余白の変更 | 内容の正しさ、表示崩れ、読みやすさ | 変更箇所と関連画面の表示確認 |
| 入力条件や計算処理の変更 | 正常時・境界値・不正な入力の扱い | 仕様に基づくテストとコード確認 |
| ログイン・権限の変更 | 許可される操作と拒否される操作 | 利用者・権限を変えたテストと設計確認 |
| 一括更新・削除・データ移行 | 対象範囲、途中失敗、再実行、復旧 | 検証環境での試行、バックアップと復旧手順の確認 |
確認の量は、変更した行数だけでは決められません。例えば、権限確認の１行を削除する変更は、画面の見た目を整える数十行の変更より、影響が大きい場合があります。
３．実装の前に「正しい動作」を決める
AIに実装を依頼する前に、何ができれば完成なのかを明確にします。この基準が曖昧だと、生成されたコードに合わせて、後から正解を決めてしまいやすくなります。
例えば、学習用のクイズアプリなら、「回答を判定する」だけでは不十分です。未回答時の動作、連続クリック、次の問題への移動、得点の更新まで整理します。
例：クイズアプリの確認条件
以下は、チェック体制を説明するための仮の仕様です。実際のアプリで検証した結果ではなく、実装前に用意する確認項目の例として見てください。
| 条件・操作 | 期待する動作 |
|---|---|
| 問題を表示した直後 | 選択肢を押せる状態で、解説は表示されない |
| 正解を選ぶ | 正解と解説を表示し、得点を１回だけ加算する |
| 回答後に選択肢を連続で押す | 判定や得点を重複して更新しない |
| 未回答で「次へ」を操作する | 次の問題へ進めない |
| 回答後に「次へ」を押す | 次の問題を表示し、前の解説を消す |
| 最後の問題を終える | 結果画面へ移動し、問題番号の範囲外を参照しない |
ここで決めた期待結果を基に、実装とテストを確認します。AIがテストを作る場合も、テストの期待値が仕様と一致しているかは別に確かめてください。
AIへの依頼では、目的・変更範囲・確認条件を揃えることが大切です。指示の作り方と、回答を見ながら修正する手順をこちらで解説しています。
AI開発のプロンプト設計｜指示の作り方・修正手順・テストの進め方 記事を読む →４．自動チェックと人の確認を組み合わせる
自動チェックは、目的に合うものを選ぶ
自動チェックには、コードの書き方を確認するもの、型の整合性を調べるもの、実際に処理を動かすものなどがあります。AIによるコードの読み取りと、テストや静的解析の実行は、同じ作業ではありません。
| 確認方法 | 主に確認できること | 限界 |
|---|---|---|
| Linter | 設定された規則への違反や、一部の不具合候補 | 業務上の正しさ全体は判断できない |
| 型チェック | 型定義に基づく不整合 | 外部入力の妥当性や権限まで保証しない |
| 自動テスト | 用意した条件で期待結果になるか | 用意していない条件の動作は保証しない |
| 依存関係の検査 | 対象データベースに登録された既知の問題など | 未登録の問題や独自実装の欠陥は別途確認が必要 |
| 人によるレビュー・操作確認 | 仕様、変更意図、利用場面との整合性 | 確認者の理解や確認範囲によって見落としがある |
「チェックが通った」は、そのチェックで問題が見つからなかったという意味です。すべての不具合がなくなったことや、安全性が保証されたこととは区別しましょう。
人の確認は、コード完成後だけに置かない
認証方式やデータの保存方法など、後から変更すると影響が大きい部分は、実装前に確認します。完成したコードを最後に読むだけでは、仕様や設計の食い違いに気づくのが遅くなることがあります。
自動チェックに失敗した場合も、単に通るよう修正するのではなく、何が原因かを調べます。テストの削除や条件の緩和によって通過させていないか、変更前後の差を確認してください。
５．「AIが確認済み」を具体的な記録に変える
AIから「テスト済みです」と説明されても、どの環境で何を実行したのかが分からなければ、確認の根拠として使えません。コードを読んだだけなのか、実際にコマンドを実行したのかを分けて記録します。
確認記録は長文である必要はありません。変更内容、実施した確認、結果、未確認事項が分かる形にしておくと、次の担当者も判断しやすくなります。
確認後にコードを変更した場合は、その変更に関係する確認をやり直します。以前の版で成功した結果を、修正後の版の確認結果として扱わないようにしましょう。
別のAIによるレビューも、検証の代わりにはならない
別のAIに確認を依頼すると、新しい指摘が得られることがあります。ただし、複数のAIが同じ意見でも、それだけで正しさは証明できません。共有している前提や情報が誤っていれば、同じ見落としにつながる可能性があります。
指摘を受けたら、該当箇所、問題が起きる条件、仕様や実行結果との関係を確認します。修正案が提示された場合も、採用後に別の機能へ影響していないかを確かめてください。
実際のコードを読む際に、仕様・テスト・保守性をどのように確認するか。具体的なレビューの進め方は、こちらの記事をご覧ください。
AI生成コードのレビュー方法｜仕様・テスト・保守性を確認する実践手順 記事を読む →６．AIが操作できる範囲と、公開する条件を決める
コードを提案するAIと、ファイル変更やコマンド実行まで行うAIでは、必要な管理が異なります。操作できるAIを使う場合は、閲覧・編集できる場所、実行できる処理、アクセスできるデータを整理してください。
例えば、検証用のデータで開発を進める段階なら、本番データベースの削除権限や、本番環境への公開権限まで与える必要があるかを検討します。作業に必要な範囲から始め、追加の権限が必要になったときに確認します。
- 作業環境：開発・検証・本番の接続先を区別する。
- 入力情報：秘密鍵、認証情報、個人情報を不用意に渡さない。
- 変更範囲：依頼に関係しない設定や依存関係の変更がないか確認する。
- 公開条件：必要な確認結果と、未解決の問題を明らかにする。
- 復旧：不具合が起きたときの停止・切り戻し方法を用意する。
コードを前の版に戻せても、削除したデータや送信済みのメールは元に戻らないことがあります。復旧方法は、コード・設定・データ・外部への操作を分けて考えましょう。
７．小規模チーム・個人開発で始めるチェック体制
人数が少ない場合でも、作成と確認の工程を区切ることはできます。まずは変更を小さくまとめ、仕様に照らして差分を確認し、必要な動作を試す流れを作ります。
- 依頼前：目的、変更範囲、期待する動作を決める。
- 変更後：何が変わったかを確認し、不要な変更を整理する。
- 検証：変更に合う自動チェックと操作確認を実施する。
- 採用判断：確認結果と未確認事項を見て、採用する範囲を決める。
- 公開後：主要な動作とエラーの発生を確認する。
個人開発では、同じ人がすべてを担当するため、前提の誤りに気づきにくいことがあります。時間を置いて見直す、別の入力条件で試すなどの工夫はできますが、第三者の専門的な確認と同じではありません。
権限管理やデータ移行など、自分だけでは妥当性を判断できない変更は、詳しい人への相談や既存の実績ある仕組みの利用を検討してください。判断できないまま公開範囲を広げないことも、開発上の重要な判断です。
８．よくある質問
AIが作ったコードは、すべて書き直した方がよいですか？
一律に書き直す必要はありません。仕様に合い、理解でき、必要な確認を行えた部分は採用できます。作成者がAIか人かにかかわらず、変更内容と確認結果を基準に判断しましょう。
テストがすべて成功すれば、人のレビューは不要ですか？
テストが成功しても、期待値そのものが誤っていたり、確認していない条件に問題が残っていたりする場合があります。仕様や設計との整合性など、テスト結果だけでは判断できない部分を確認してください。
AIに「安全性を確認して」と頼むだけでは不十分ですか？
問題候補を探す補助にはなりますが、その一言で安全性を保証できるわけではありません。扱う情報、利用者の権限、公開範囲などを整理し、具体的な確認方法につなげる必要があります。
レビューに時間がかかり、効率化できません。
一度に生成・変更する範囲が大きすぎないかを確認しましょう。機能追加と全面的な書き換えをまとめず、目的ごとに変更を分けると、確認対象を絞りやすくなります。AIに依頼する際も、変更してよい範囲と完了条件を先に伝えてください。
９．「誰が見たか」に加えて「何を確かめたか」を残す
AI開発で大切なのは、AIと人の作業量を一定の割合にすることではありません。変更の影響に応じて、仕様の確認、テスト、レビュー、公開後の確認を組み合わせることです。
まずは次の変更で、期待する動作と確認結果を短く記録してみましょう。「AIが大丈夫と言った」「人が目を通した」という説明から、どの条件で何を確認できたかが分かる運用へ進めていけます。
参考資料
- GitHub公式ドキュメント：Copilotのエージェント機能の責任ある利用 — AIによるレビューの見逃し・誤指摘と、生成内容の確認について。
- Google Engineering Practices：What to look for in a code review — 設計・動作・テストなど、コードレビューで確認する観点。
- NIST SP 800-218：Secure Software Development Framework Version 1.1 — 開発工程にセキュリティの実践を組み込むための資料。
Learning Tools
記事を検索したい方はここから！
記事を検索
関連記事や、今の内容に近いテーマをすぐに検索できます。
例: AI / 情報Ⅰ / Python / 統計 / 資格 / 学習法