AIで開発したコードを本番に出す前に、人は何を確認するか

Claude CodeやCopilotなどのAIで開発したコードを本番に出す前に、人は何を確認し、誰が最後に出すと決めるのか。答えは、AIのレビューやテストが通っても、本番に出してよいかは人が決める、です。権限・機密情報・外部への送信・追加されたパッケージ・止め方と戻し方の5点は人が確かめる範囲に固定し、作業した本人とは別の承認者が、確認の記録を見てリリースを決めます。

AIのレビューやテストが通れば、本番に出してよいのか

AIのレビューやテストが確かめるのは「正しく動くか」で、本番に出す前に人が確かめるのは「その変更が触ってよい範囲に収まっているか」です。前者が通っても、後者は確かめられていません。

提供元も、AIの判定を人の確認の代わりとしては位置づけていません。Claude Codeの公式ドキュメントは、提案されたコードとコマンドが安全かを承認前に確かめる責任は利用者にある、と書いています。Autoモードでは別の分類モデルが利用者の代わりに操作を審査しますが、これは作業中の操作を止めるための仕組みで、できあがった変更を本番に出してよいかを判断するものではありません。

GitHubも同じ線を引いています。既定のCopilotのレビューはコメントとして付くもので、プルリクエストの必須承認の数には入りません。

仮に、AIのレビューで指摘なしとなった変更が、社内の別システムへの送信先を1つ増やしていたとします。コードとしては正しく動くので、レビューもテストも通ります。止められるのは「この送信先は増やしてよいか」を問う人だけです。

本番前に人が確かめるのは、どの5点か

AIで開発したコードを本番に出す前に人が確かめるのは、権限・機密情報・外部への送信・追加されたパッケージ・止め方と戻し方の5点です。どれも、間違っていても動作は正常に見えるため、テストやAIのレビューでは見つかりにくいものです。下の表は、この5点に、AIとツールに任せる確認と最終の判断を加えた7行です。

表のうち、5点を人の側に置いたのは本記事の整理です。根拠にしたのは、提供元が自分の製品について書いている次の記述です。

権限と外部への送信は、設定ファイルで確かめる

Claude Codeの公式ドキュメントは、機密性の高いリポジトリではプロジェクト専用の権限設定を使い、権限設定を定期的に監査するよう勧めています。本番前の確認では、差分の中に権限設定のファイル（たとえば .claude/settings.json）やMCPサーバーの設定（.mcp.json）の変更が含まれていないかを最初に見ます。Anthropicは MCPサーバーのセキュリティ監査や管理をしない、と明記しているので、新しく追加されたMCPサーバーは、何に接続し、何を外へ送るかを人が確かめる対象です。

Webから内容を取得するcurlやwgetのようなコマンドは、既定では自動承認されません。提供元が既定で止めている操作は、外部とのやりとりに危険があると提供元自身が見ている操作だと読めます。アプリのコードの中で外部APIを呼ぶ箇所が増えた場合も、同じ扱いにします。

追加されたパッケージと機密情報は、差分の外も見る

GitHubの公式ドキュメントは、AIが生成したコードの依存関係について、実在しないパッケージや不審なパッケージに注意するよう書いています。依存の一覧の差分で、追加された名前が実在し、意図した提供元のものかを確かめます。

機密情報は、差分に直接書かれていなくても、ログの出力先や送信の中身に入って外へ出ることがあります。Claude Codeの公式ドキュメントが勧める「重要なファイルへの変更案を確かめる」は、この確認の入口になります。

止め方と戻し方は、出す前に書いてあるかを見る

IPAのサイトで公開されている生成AIとAIエージェントの手引書は、リリース判断の根拠と切戻しの手順を確認できる状態にしておくこと、運用手順として停止条件やエスカレーション手順を整えることを挙げています。人が見るのは、戻す手順が書かれているか、誰がどの条件で止めるかが決まっているかです。データベースの構造を変える変更は、コードを戻してもデータが戻らないことがあります。AIにデータベースの設計を任せたときにつまずきやすい点は、データベース設計にAIを使うときの注意点をまとめた記事で整理しています。

どこまでならAIやツールの確認に任せてよいか

AIの確認はどこまで任せてよいのか。構文・型・テストの実行と静的解析は任せてよく、そのための条件は、AIが動く範囲を決める権限設定を人が監査し続けることです。

GitHubの公式ドキュメントは、AIが生成したコードのレビューは、自動テストと静的解析を先に回すことから始めるとしています。機械で判定できる確認を先に終わらせておけば、人は5点に時間を使えます。Claude Codeの /security-review は、今のブランチの変更に対してその場でセキュリティの確認を走らせる機能です。人が5点を見る前の一次確認として使い、その結果を人の承認の代わりにはしません。

任せる範囲を担当者ごとに決めると、確認がばらばらに戻ります。Claude Codeの公式ドキュメントは、チームではmanaged settingsで組織の基準を強制し、承認済みの権限設定をバージョン管理で共有することを勧めています。誰がClaude Codeを使っても同じ権限の範囲で動く状態を作っておくと、本番前の確認で見る差分が減ります。設定の手順そのものは提供元のドキュメントに従ってください。

最後に本番に出すと決めるのは誰か

GitHubは2026年9月、Copilotのコードレビューがプルリクエストを承認できる機能を公開プレビューにしました。既定では承認せず、承認させるかどうかと、Copilotが承認してよいファイルのパスはリポジトリの管理者が選びます。対象はCopilotのPro・Pro+・Max・Business・Enterpriseで、内容は提供元の変更履歴による2026年10月時点のものです。

この機能を使うなら、承認してよいパスを、5点に当たらないファイルに限るのが本記事の考え方です。たとえば文言の修正や、テストのファイルだけを対象にし、権限設定・MCPの設定・依存の一覧・外部への接続を書いた箇所は外します。5点に触れる変更は、Copilotの承認があっても人の承認を待つ形にします。

最後に出すと決めるのは、作業した本人とは別の承認者です。これも公的資料の文言ではなく本記事の整理で、GitHubの公式ドキュメントが複雑な変更や機微な変更はチームの人にレビューを頼むよう書いていることを、承認の段まで広げたものです。IPAのサイトで公開されている手引書も、本番稼働の前に、試験結果を受け取るだけでなくリスクが許容できる水準まで下がったかを確かめ、承認者がリリース可否を判断するとしています。ただしこの手引書は、著者の見解であってIPAの意見を代表するものではないと明記されています。

誰が承認者になるかは、会社として先に決めておきます。総務省・経済産業省のAI事業者ガイドライン（第1.2版）は、アカウンタビリティを果たす責任者を設定すること、関係者の間では契約などで責任の所在を明確にすることを挙げています。法令ではなく指針ですが、外部の開発会社やツールが関わる場合に、どこまでを誰が承認するかを書面で分ける根拠になります。コード変更ごとの承認ではなく、AIを使ったシステムそのものを本番の運用に乗せてよいかを決める段階なら、AIのPoCを本番へ移行してよいかを判断する条件をまとめた記事が対象です。

確認したことは、何として残せばよいか

残すのは、承認者・承認日・リリース条件・リリース後の確認結果の4つです。IPAのサイトで公開されている手引書は、高リスクな変更ではこの4つを記録するとしています。5点のどれかに触れる変更を高リスクとみなし、この4欄を埋めてから出す決まりにすると、本番前の確認が担当者ごとにばらばらになるのを防げます。

承認は最後の差分に対して行います。Copilotが承認した後に新しいコミットが入ると、人のレビュアーと同じく承認は取り消されます。AIの指摘を受けて直した後や、出す直前に小さな修正を入れた後は、承認がやり直しになったことを記録の側でも確かめます。

記録の置き場所は、新しい仕組みを作るより、プルリクエストの説明欄やリリースの記録に、判断表の7行と4つの欄をそのまま入れるのが手早い方法です。障害が起きたときに、どの行の確認が抜けていたかを後から辿れるようになり、次の決まりの直し方も分かります。

公開日：2026年10月