「生成AIでコードは速く書けるようになった。でも、レビューが追いつかない」「AIが書いたコードの品質を、誰がどう保証するのか決まっていない」——開発チームで生成AIを使い始めると、多くの現場がこの壁に当たります。

先に答えを書くと、開発での生成AI活用は「AIに下書きさせ、人が検証して責任を持つ」線引きを工程ごとに決め、テストとレビューで確かめる仕組みを先に作ると成果が出ます。

本記事では、開発リーダー・エンジニア・情報システム部門の責任者に向けて、生成AIが効く5つの開発工程（仕様・設計／コード生成／テスト／コードレビュー／ドキュメント）、工程ごとにAIに任せる範囲と人が持つ判断、品質を落とさないレビュー体制、機密コードの扱い、PoC（試験導入）で小さく始める手順を、私たちが自社プロダクトや社内システムの開発で生成AIを使ってきた知見をもとに整理します。情報システム部門の問い合わせ対応や運用の効率化は情シス部門の生成AI活用で扱っており、本記事は「ソフトウェアを作る工程」に絞ります。

結論：開発の生成AI活用は「工程ごとの分担表」と「検証の仕組み」で決まる

開発で生成AIの成果を分けるのは、ツールの性能差より「どの工程で、どこまでをAIに任せ、何で確かめるか」を先に決めているかどうかです。私たちはこの線引きを「開発AI分担表」と呼び、開発案件の最初に作ります。

要点は3つです。

1. AIは「下書き・候補出し」に徹させる。 定型の実装、テストケースの洗い出し、差分の一次レビュー、READMEの下書きはAIが速く、実用に届きます。
2. 判断と責任は人に残す。 何を作るか、どのライブラリを採用するか、どの指摘を採るか、マージしてよいかは人が決めます。
3. 「できました」を信じず、実行結果で確かめる。 テスト・ビルド・画面の比較など、合否が機械的に出る検証を用意してからAIに書かせます。

背景には、利用は広がる一方で、出力への信頼は下がっているという現実があります。Stack Overflowの2025年開発者調査（177か国・4.9万件超の回答）では、84%の開発者がAIツールを使っている・使う予定と答える一方、AIの出力の正確さを信頼しない人は46%に増え、45%が「AIが生成したコードのデバッグに時間がかかる」と答えています（出典：Stack Overflow 2025 Developer Survey プレスリリース）。問われているのは「使うか」ではなく、「どう確かめる仕組みで使うか」です。

開発で生成AIが効く5つの工程は？

生成AIが効くのは、①仕様・設計 ②コード生成 ③テスト ④コードレビュー ⑤ドキュメントの5工程です。どれも「書く・読む・突き合わせる」作業が多く、AIの得意領域と重なります。一方で、どの工程にも人が手放してはいけない判断があります。

①仕様・設計：AIに「質問させる」と要件の抜け漏れが減る

仕様・設計でAIを使うときは、いきなり設計書を書かせるより、AIに質問させる使い方が効きます。作りたいものを短く伝え、「実装上の論点・例外ケース・考慮漏れを質問して、最後に仕様書にまとめて」と頼むと、人が見落としがちな論点が先に出てきます。Anthropicの公式ガイドでも、大きな機能は先にAIにインタビューさせて仕様書を書き、そのあと新しいセッションで実装に入る流れが推奨されています（出典：Claude Code公式ドキュメント「Best practices」）。

私たちの開発現場では、ここに「画面モックを正典にする」ルールを足しています。項目・選択肢・状態・出力をモックの段階で詰めて関係者と合意し、実装ではAIに「モックどおりに配線するだけ」と指示します。仕様の解釈をAIに委ねないことで、後工程の手戻りが目に見えて減りました。

②コード生成：既存のパターンと「守るルール」を先に渡す

コード生成は、生成AIの効果が最も分かりやすい工程です。ただし、「ログイン画面を作って」のような曖昧な指示では、動くけれど自社の流儀に合わないコードが返ってきます。効くのは次の3点を渡すことです。

• 参照すべき既存コード：「この画面の実装パターンに合わせて」とファイルを指定する
• プロジェクトのルール：コーディング規約、使ってよいライブラリ、テストの走らせ方
• 完了の条件：「このテストが通ること」「このコマンドのエラーがゼロになること」

プロジェクトのルールは毎回説明せず、AIが毎回読むルールファイル（例：Claude CodeのCLAUDE.md）に書いておくのが定石です。私たちはここに、実際に踏んだ落とし穴を1行ずつ追記しています。たとえば「ある自動化処理は、ファイルが別の画面で開かれていると“保存成功”を返しながら中身を捨てる」といった、コードを読んでも分からない環境固有の癖です。同じ失敗を二度させない仕組みとして、最も費用対効果が高い投資でした。

③テスト：AIに書かせるほど、テストの設計は人が持つ

テストケースの洗い出しとテストコードの生成も、AIに任せやすい工程です。ただし、テストの「何を確かめるか」を人が決めないと、AIは通りやすいテストを書きがちです。

私たちが実際に経験したのは、分類ごとの集計で「合計金額は合っているのに、名前が1文字違う分類がまるごと画面から消えていた」ケースです。合計だけを見るテストは通ってしまいます。以後、件数・分類の網羅・境界値を検証項目として人が指定し、AIにはその項目に沿ってテストを書かせる分担にしています。

④コードレビュー：AIは「一次レビュー」、別モデルで二重に見る

コードレビューでは、AIに差分の一次レビューを任せ、人は指摘の取捨選択と最終承認に集中します。GitHubの公式ドキュメントも、Copilotのコードレビューは存在しない問題を指摘したり、大きく複雑な変更では問題を見逃したりすることがあるため、人による注意深いレビューで補うべきだと明記しています（出典：GitHub Docs「Responsible use of GitHub Copilot code review」）。

私たちの現場で効いているのは、書いたAIとは別のモデル（または別のセッション）にレビューさせる運用です。書いた本人の思い込みを引き継がないため、秘密情報の埋め込みやゼロ除算、暗号化されていない通信といった指摘が優先度付きで返ってきます。一方で、二つのAIが同じ誤った前提を共有して、そろって間違えたこともありました。前提（業務ルールやデータの意味）が正しいかどうかは、最後は業務を知る人が確かめる必要があります。

⑤ドキュメント：コードから下書きし、「なぜ」だけ人が書く

README、API仕様、変更履歴、運用手順書は、コードや差分からAIに下書きさせると一気に楽になります。書く手間が減るため、ドキュメントが「後回しにされて古くなる」問題も起きにくくなります。

ただし、AIがコードから読み取れるのは「何をしているか」までです。「なぜこの設計にしたか」「何を捨てたか」は人が書き足します。私たちは、AIとの作業が一区切りするたびに、決定事項と理由を1トピック1ファイルで記録する運用にしています。次に同じコードを触るとき、人にとってもAIにとっても最良の前提資料になります。

5工程のまとめ

AIで開発は本当に速くなる？品質を落とさない条件は？

速くなるかどうかは、「検証の仕組み」があるかで決まります。 検証なしで使うと、書く時間が減った分をデバッグとレビューで取り返され、かえって遅くなることがあります。

示唆的なのが、非営利の研究機関METRが2025年7月に公表したランダム化比較試験です。熟練のオープンソース開発者16人が自分のリポジトリで実タスクに取り組んだところ、AIツールを使えるときのほうが所要時間が19%長く、しかも本人たちは「AIで20%速くなった」と感じていました（出典：METR「Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity」）。METR自身は、現在のツールや働き方には必ずしも当てはまらない過去の結果と位置付けていますが、「速くなった実感」と「実際の効果」はずれうるという教訓は今も有効です。

品質を落とさずに速くするために、私たちは次の「検証ゲート3層」を置いています。

1. 機械の検証：テスト・ビルド・型チェック・画面の比較など、合否が自動で出るもの。AIには「テストを走らせ、通るまで直して、実行結果を見せて」と頼みます。
2. 別の目の検証：書いたAIとは別のモデル・別セッションによるレビュー。書き手の思い込みを持ち込ませないのが目的です。
3. 人の検証：業務上の前提、設計方針、マージの可否。ここだけは自動化しません。

特に大切なのが1層目で、AIの「完了しました」ではなく、テスト結果やコマンドの出力という証拠で判断することです。前述の「保存成功を返しながら中身を捨てる」ケースも、証拠で確かめる運用だったから気付けました。AIの誤答全般への対策は生成AIのハルシネーション対策でも詳しく解説しています。

開発で生成AIを使うときの注意点は？

注意点は①機密コード・秘密情報 ②権利・ライセンス ③依存関係と権限の3つです。開発の現場は、ソースコードそのものが営業秘密であり、顧客の設計情報を含むことも多いため、他部門より慎重な線引きが要ります。

①機密コードは「送らない」か「学習に使われない環境」で扱う

外部の生成AIサービスにコードを送ると、そのコードは社外のサーバーを通ります。私たちは、顧客案件の機密コードは、入力が学習に使われない法人契約の環境でしか扱わず、別モデルによるレビューも非機密・自社内のコードに限るというルールで運用しています。APIキーやパスワードなど秘密情報をコードやプロンプトに含めないことも前提です。全社ルールの作り方は生成AIのセキュリティ対策と生成AI 社内利用規程の作り方を参照してください。

②生成コードの権利とライセンスを確認する

AIが生成したコードが、既存のオープンソースのコードと酷似する可能性はゼロではありません。ライセンス条件のあるコードの混入を防ぐため、利用規約の確認と、ツール側の重複検出機能の有効化を検討します。論点の整理は生成AIの著作権リスクと対策が参考になります。

③AIに与える権限と、追加されるライブラリを絞る

コードを書くだけでなくコマンドまで実行する「AIエージェント型」の開発ツールは強力ですが、本番環境への接続や外部への送信、ファイルの一括削除まで許すと事故のもとです。権限は必要最小限にし、危険な操作は人の承認を挟みます。また、AIが提案するライブラリは実在性・保守状況・ライセンスを人が確認してから採用します。AIエージェントと生成AIの違いと使いどころはAIエージェントの業務活用で解説しています。

開発チームへの導入はどう進める？

導入は、1チーム・1工程のPoCから始め、効果と品質を数字で確かめてから広げるのが確実です。いきなり全社にツールを配ると、使い方も品質基準もばらばらになり、「結局レビューが大変になっただけ」で終わりがちです。

1. 対象の工程を1つ選ぶ。 効果を測りやすいのは「テストコードの生成」か「差分の一次レビュー」です。
2. 開発AI分担表を1枚作る。 その工程でAIに任せる範囲、人が持つ判断、必ず人に回す条件を書きます。
3. ルールファイルと検証を用意する。 コーディング規約・テストの走らせ方・禁止事項を書き、合否が自動で出る検証を整えます。
4. 評価指標を決めて2〜4週間試す。 リードタイム、レビューの手戻り件数、リリース後の不具合件数、AI出力の修正率など、速さと品質の両方を測ります。
5. 撤退基準と展開条件を決めておく。 不具合が増えたら止める、手戻りが減ったら隣の工程に広げる、と事前に合意します。

PoCの設計とKPI・撤退基準の決め方は生成AIのPoCの進め方、費用対効果の測り方は生成AI導入のROIの考え方で詳しく解説しています。

私たちの開発現場から（所感）
自社プロダクトや社内の業務システムを、生成AIを前提に開発してきた実感として、効いたのはモデルの性能差よりも「前提の渡し方」と「検証の仕組み」でした。ルールファイルに落とし穴を書き足し、テストの検証項目を人が決め、別モデルでレビューする——この3点がそろってから、AIに任せる範囲を安心して広げられるようになりました。逆に、前提を渡さずに任せた部分ほど、後で読み解きと手直しに時間がかかりました。

生成AIを組み込んだ自社システムやPoCを外部の支援を受けて進めたい場合は、生成AI開発・PoC支援｜サービス内容と進め方・費用・事例も参考にしてください。内製と外注の判断は生成AIは内製か外注かで整理しています。

今日から始める3ステップ

1. チームの開発工程を書き出し、時間を食っている工程を1つ選ぶ。 それがPoCの第一候補です。
2. その工程の「開発AI分担表」を1枚作る。 AIに任せる範囲・人の判断・確かめ方を書きます。
3. PoC企画書に落とす。 対象工程・評価指標・撤退基準・機密コードの扱いを1枚にまとめ、開発責任者と情報システム部門で合意します。

PoCの企画書づくりに使える「生成AI PoC企画テンプレート」を無料で配布しています。対象業務の選定からKPI・撤退基準まで、埋めるだけで企画書の骨子ができる形式です。

• 生成AI PoC企画テンプレートを無料ダウンロードする
• 自社の開発チームにどう当てはめるか相談したい方は、無料相談からお気軽にお問い合わせください。

よくある質問（FAQ）

Q. 生成AIが書いたコードをそのまま本番に使ってもよいですか？
A. そのままは推奨しません。テスト・ビルドなどの機械的な検証と、人によるレビューを通してから本番に入れるのが原則です。AIの出力は「下書き」として扱い、マージの最終判断と責任は人が持ちます。

Q. コード生成AIに社内のソースコードを入力しても大丈夫ですか？
A. 入力が学習に使われない法人向けの契約や、社内の閉じた環境で使うことが前提です。顧客案件の機密コードは対象外にする、APIキーなどの秘密情報を含めない、といったルールを利用規程に明記しておきましょう。

Q. AIでコードレビューを自動化すれば、人のレビューは不要になりますか？
A. 不要にはなりません。AIのレビューは存在しない問題を指摘したり、複雑な変更で問題を見逃したりすることがあります。AIは一次レビューと指摘出しを担い、指摘の取捨選択とマージの承認は人が行う分担が現実的です。

Q. 開発チームへの生成AI導入は何から始めればよいですか？
A. テストコードの生成や差分の一次レビューなど、効果を測りやすい1工程のPoCから始めるのがおすすめです。速さだけでなく、レビューの手戻りや不具合件数など品質の指標もあわせて測ります。

まとめ：開発の生成AI活用は「分担表」と「検証ゲート」から始める

• 開発で生成AIが効くのは、仕様・設計／コード生成／テスト／コードレビュー／ドキュメントの5工程。
• 成否を分けるのは、工程ごとにAIに任せる下書きと、人が持つ判断を線引きした「開発AI分担表」。
• 品質は「検証ゲート3層」（機械の検証・別の目の検証・人の検証）で守る。AIの「完了しました」ではなく実行結果で確かめる。
• 注意点は機密コードの扱い・権利とライセンス・権限と依存ライブラリの3つ。
• 導入は1チーム・1工程のPoCから。速さと品質の両方を数字で確かめてから広げる。

まずは時間を食っている開発工程を1つ選び、分担表とPoC企画書に落とし込むところから始めてみてください。

• 生成AI PoC企画テンプレートを無料ダウンロード
• 無料相談はこちら

監修：大槻 伸夫（キュリオシティ株式会社 代表取締役CEO）
業務改善(BPR)とAI活用を”現場主義 × AI”で支援。業務の可視化から生成AIのPoC・社内実装まで、現場に定着する形で伴走しています。