AIコーディング公開前セキュリティチェック｜Claude Code・Codex・Cursor【2026年10月】
公開日: 2026年10月9日
【結論】AIコーディングの公開前セキュリティチェックとは、Claude Code・Codex・Cursorなどで生成・編集した成果物を、インターネットや社内本番に出す前に、人が確認する項目一覧です。
- Veracodeの2025年調査では、評価条件のもとでAI生成コードの約45%がOWASP Top 10に該当する欠陥を含んだ（100以上のLLM・80タスク）
- 公開前に見る軸は4つ——秘密情報、エージェント権限、生成コードと依存、公開面の認証・入力検証
- ツールのサンドボックスは開発時の事故を減らすが、公開後のWebアプリ脆弱性は別問題。人のレビューを省略しない
この記事は、開発リーダー・情シス・PM向けに、バイブコーディングやAI駆動開発で速度を上げたあと、公開前に何を止めるかを実行できる形で書きます。特定ベンダーの性能比較や、出典のない「9割が脆弱」といった断定は使いません。
この記事で分かること
- AIコーディング公開前チェックの定義と、開発時ガードとの違い
- 公開前チェックリスト（印刷・チケット化用）
- Claude Code／Codex／Cursorの公式ドキュメントに基づく権限・無視ファイルの差分
- 生成コードで起きやすい欠陥の型（Veracode・OWASP）
- 生成AIへの誤入力インシデントとの切り分けと、社内規程へのつなぎ
AIコーディング公開前セキュリティチェックとは
AIコーディング公開前セキュリティチェックとは、AI支援で書いたコードや設定を、外部公開・本番反映・顧客納品の直前に、秘密情報・権限・欠陥・依存関係の観点で人が確認する手順です。
開発中のサンドボックスや承認プロンプトは「エージェントが今このマシンで何をしてよいか」を制限します。公開前チェックは「出来上がった成果物を誰がどう使えるか」を確認します。両方必要で、どちらか一方では足りません。
概念の入口はバイブコーディングとはとAI駆動開発（AIDD）とはにあります。本記事はその先の、公開ゲートのHOWです。
なぜ公開前チェックが必要か（数字は出典つきだけ）
Veracodeの「2025 GenAI Code Security Report」は、Java／JavaScript／Python／C#の80タスクについて100以上のLLMにコードを生成させ、静的解析で欠陥の有無を見ました。結果、全体では約45%のケースでOWASP Top 10に分類されるセキュリティ欠陥が入り、セキュリティ通過は約55%でした（出典：Veracode公式ブログおよびレポートPDF）。
同社が2025年10月に出した更新では、新しいモデルごとに通過率が分かれており、特定モデルでは70%台の通過率も報告されています。つまり「AIなら必ず危ない／必ず安全」ではなく、モデルとタスクで幅があるので、公開前に人間側のゲートを置くのが実務の答えです。
エージェント側のリスクの整理として、OWASPはLLMアプリケーション向けTop 10（2025）に、プロンプトインジェクション、機微情報の開示、過剰な自律性（Excessive Agency）、不適切な出力処理などを挙げています。コーディングエージェントに広い権限を渡す運用は、この「過剰な自律性」と直結します。
公開前チェックリスト（共通）
Claude CodeでもCodexでもCursorでも、公開・本番投入の直前に次を通します。チケットのDefinition of Doneにそのまま貼れます。
| 軸 | 確認項目 | 合格の目安 |
|---|---|---|
| 秘密情報 | .env、APIキー、証明書、社内URL、顧客データがリポジトリ／画面／ログに出ていない | スキャンまたは目視でゼロ。サンプルはダミー値 |
| 認証・認可 | 管理画面・API・Webhookに認証がある。権限が「全員フル」になっていない | 未ログインで機微操作ができない |
| 入力検証 | ユーザー入力・ファイル名・URL・SQL／HTML埋め込みの扱い | 結合文字列のままDBやHTMLに渡していない |
| 依存関係 | 追加したパッケージの出典・既知CVE・ライセンス | lockファイルがあり、出所不明のバイナリを同梱していない |
| 公開面 | デバッグエンドポイント、テスト用バイパス、CORS、ディレクトリ一覧 | 本番設定で無効化済み |
| 人の承認 | 本番デプロイ・DNS・権限変更・課金に触る操作 | 担当者と承認ログが残る |
印刷用チェック（短文）
- □ 秘密情報をコミット・画面・ログから除去した
- □ 認証なしで管理操作や個人情報APIに届かない
- □ SQL／HTML／コマンドへのユーザー入力の埋め込みをレビューした
- □ 依存パッケージの追加理由とlockを確認した
- □ デバッグ用のバイパス・詳細エラー表示を本番で切った
- □ 本番反映の承認者と時刻を記録した
- □ （外部公開の場合）脆弱性スキャンまたは同等のレビューを実施した
開発時：ツール別の権限と秘密情報（公式ベース）
公開前チェックの前段として、開発中に事故を減らす設定を公式ドキュメントの範囲で整理します。設定名や既定値は製品更新で変わるため、運用時は各公式ページを再確認してください（本稿の確認日：2026年10月9日）。
| ツール | 公式が示す要点 | 現場で決めること |
|---|---|---|
| Claude Code | Bashサンドボックスはシェルコマンドのファイル／ネットワーク境界。ファイルツール・MCP・hooksはサンドボックス外。権限モードと隔離（コンテナ／VM）は別レイヤー。未承認実行（dangerously-skip-permissions）は隔離環境が前提 | 社内ではサンドボックス有効を標準にするか。MCPの接続先を誰が承認するか |
| Codex | ローカルではOSレベルのサンドボックスと承認ポリシー。既定のworkspace-writeではネットワークオフが基本。ネットワークを開く場合は設定と承認が必要 | ネットワークをいつ許可するか。承認ポリシー（都度確認／自動）の下限 |
| Cursor | Privacy Modeで学習利用を抑止できる（個人／チームで設定経路が異なる）。.cursorignoreと.gitignoreでインデックス・Agentのファイルアクセスを制限。.env*は既定無視に含まれるが、ターミナル／MCPは別経路で読める場合がある | 秘密情報の置き場をターミナルから届かない設計にするか。組織でPrivacy Modeを強制するか |
ツール比較の機能面はClaude Code／Cursor／Codex比較を参照し、本記事はセキュリティゲートに絞ります。
生成コードで起きやすい欠陥の型
Veracodeの評価タスクでは、次のような弱点が相対的に多く検出されました（レポート記載のCWEと失敗率）。公開前レビューの着眼点として使えます。
| 型 | レポート上の示唆 | 公開前に見る場所 |
|---|---|---|
| クロスサイトスクリプティング（CWE-80） | 該当タスクで高い失敗率（レポート記載86%） | テンプレートへのユーザー入力のエスケープ／サニタイズ |
| ログインジェクション（CWE-117） | 該当タスクで高い失敗率（レポート記載88%） | ログに渡す文字列の扱い |
| SQLインジェクション（CWE-89） | 相対的には通過しやすいが残る | 動的SQLの結合箇所 |
| 弱い暗号（CWE-327） | 一部タスクで残存 | 自前の暗号アルゴリズム選択 |
言語別では、同レポートでJavaのセキュリティ失敗率が特に高い帯として示されています。言語を変えただけでは安全にはなりません。
AIエージェント経由の攻撃面（プロンプトインジェクション等）はプロンプトインジェクションとは、MCPの権限設計はMCPガバナンスとはを合わせて読んでください。
公開面のHOW（最小手順）
- 秘密情報の最終掃討：リポジトリ全文検索（API_KEY、BEGIN PRIVATE、パスワード文字列）。ビルド成果物とブラウザのNetworkログも見る
- 未認証アクセスの試し打ち：管理URL・「/api/」配下・Webhookを、別ブラウザのシークレットで叩く
- 入力の代表値テスト：引用符、<script>、パス区切り、長い文字列を主要フォームに入れる
- 依存の固定：lockファイルを本番ビルドに含める。手置きの未知バイナリを削除する
- 本番フラグ：DEBUG、詳細スタックトレース、テスト用マスターパスワードを無効化する
- 人の署名：誰が公開を承認したかをIssue／PR／変更管理に残す
人がループに入る位置の設計はHITL（Human in the Loop）とはと同じ発想です。公開ボタンの直前に、チェックリスト担当を固定してください。
情報漏洩インシデントとの切り分け
2026年秋前後、国内で不正アクセスや個人情報漏洩の公表が続いた局面では、「AIが攻撃を自動化したのでは」という会話も増えます。公開前チェックの文脈では、次を分けて扱います。
- サイバー攻撃・脆弱性悪用による漏洩：公表文の原因類型（既知脆弱性、委託先、設定不備など）に従う。AI関与は、事業者が公式に示していない限り断定しない
- 生成AIへの誤入力による漏えい懸念：社員が顧客情報やソースを個人向け生成AIに貼ったケース。初動は別手順になる
後者の初動は生成AIに顧客情報を入力してしまったときの初動、未許可ツールの棚卸しはシャドーAIの発覚と対処、ルール文書化は社内AI規程・ガイドラインとホワイトペーパーAI利用におけるリテラシーセキュリティを参照してください。
よくある質問（FAQ）
Q1. サンドボックスを有効にすれば公開前チェックは不要ですか？
いいえ。サンドボックスは開発マシン上のエージェント動作を制限します。公開後の認証欠如やXSSは、別の確認が必要です。
Q2. Veracodeの45%は「今の自社コード」の数字ですか？
いいえ。特定の80タスクと多数のLLMに対するベンチマーク結果です。自社リスクは、公開前チェックと必要に応じたスキャンで測ってください。
Q3. どのツールが一番安全ですか？
本記事では勝敗を付けません。公式の権限モデルが違うので、社内で「既定の厳しさ」と「誰が緩和を承認するか」を決める方が先です。
Q4. .envを.gitignoreに入れれば十分ですか？
最低限です。Cursor公式も、ターミナルやMCP経由では無視ファイルでも読める場合があると注意しています。秘密はエージェントが実行するシェルから届きにくい置き方にしてください。
Q5. 脆弱性診断は毎回必須ですか？
インターネットに出すもの、個人情報や決済に触れるものは、組織の基準に応じた診断または同等レビューを公開条件にするのが安全です。内部向け試作でも、認証と秘密情報の項目は省略しないでください。
Q6. バイブコーディングは禁止すべきですか？
禁止よりゲートです。速度を取る工程と、公開を許可する工程を分けます。
Q7. プロンプトインジェクションと公開前チェックの関係は？
エージェントが外部コンテンツや広いツール権限を持つと、意図しない操作が起き得ます。権限を最小にし、公開成果物側も入力検証する、の両方が必要です。
Q8. 社内でチェックリストを定着させるには？
PRテンプレートかリリース手順に6〜7項目を埋め、承認者を固定します。研修で「生成の速さ」と「公開の責任」を同じ週に扱うと形骸化しにくいです。
Q9. エンジニア育成やレビュー体制の相談はできますか？
はい。エンジニア・PM育成研修とAIシステム・AIエージェント開発支援、お問い合わせから相談できます。
参考文献・出典
- Veracode「Insights from 2025 GenAI Code Security Report」（約45%がセキュリティ欠陥／80タスク・100以上のLLM。2026年10月9日確認）
- Veracode「2025 GenAI Code Security Report」PDF
- Veracode「GenAI Code Security Report — October 2025 Update」PDF（モデル別通過率の更新）
- OWASP Gen AI Security Project「Top 10 for LLM Applications 2025」
- Claude Code Docs「Configure the sandboxed Bash tool」
- Claude Code Docs「Choose a sandbox environment」
- OpenAI Developers「Agent approvals & security」（Codex）
- Cursor Help「Privacy and data」
- Cursor Docs「Ignore file」
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」（2023年6月2日）
本記事は2026年10月9日時点の公開情報に基づきます。ツールの権限・料金・既定値は更新されるため、最新は各公式ドキュメントを確認してください。二次要約の未検証エピソードや、出典のない脆弱性割合の断定は採用していません。
関連：バイブコーディングとは ／ AI駆動開発とは ／ エンジニア・PM育成研修 ／ お問い合わせ