目次
AIに実装を頼むと、画面が動き、テストも通り、変更理由まで丁寧に返ってきます。それでも、他人の情報を読めるAPIや、本番の秘密情報へ届く開発環境が残っているかもしれません。機能が完成したことと、安全に運用できることは別の確認です。
AIコーディングでは、生成されたアプリケーションの安全性と、コードを書くエージェント自身の権限を分けて考えます。さらにスキル、プラグイン、MCPを追加すると、検査を強化できる一方で、実行するコードや情報の送信先も増えます。便利な拡張を導入する行為も、開発環境への変更です。
本稿は事件の速報ではなく、Web開発者・サイト運営者に向けた実務解説です。情報確認日は2026年10月17日、Codexに関する追記の確認日は10月18日です。公式資料の説明と、本サイトが提案する運用を区別して整理します。以下の会員サイトやテスト例は説明用の仮想例で、特定サービスで確認された脆弱性ではありません。
スポンサーリンク
まず守る対象を二つに分ける
一つ目は成果物です。認証・認可、入力処理、データ保存、課金、管理画面などが安全かを確かめます。二つ目は作業環境です。AIが読めるファイル、動かせるコマンド、利用できる資格情報、外部への通信先を制限します。安全なコードを書いていても、作業中に秘密が送信されれば被害は起こり得ます。
GitHubも、Copilotの生成コードやレビューには不正確な提案、見逃し、誤検知があり、人のレビューとテストが必要だと説明しています。これは特定モデルだけの弱点として片付けず、AIの出力を受け入れる工程の設計として扱います。出典：GitHub公式：Copilot Agentsの用途と限界。
| 確認する境界 | 問い | 残す証拠 |
|---|---|---|
| アプリと利用者 | 誰がどのデータを変更できるか | 権限表と拒否系テスト |
| AIと開発環境 | どのファイル・通信・操作を許すか | 実際の権限設定と実行記録 |
| 拡張と外部サービス | 何が実行され何が送信されるか | 配布元・版・送信範囲の確認 |
| 開発と本番 | 何を満たせば公開できるか | 対象コミットと検証結果 |
実装前に安全性を受け入れ条件へ書く
「安全に作って」という一文では、必要な業務条件が伝わりません。例えば顧客向け請求書のダウンロードなら、「ログイン済み」だけでなく、「同じ組織に所属する利用者が、自分に閲覧権限のある請求書だけを取得できる」と定義します。存在しないID、別組織、権限の失効後も含めて、期待する拒否を先に決めます。
OWASPは認証と認可を区別し、最小権限、デフォルト拒否、各リクエストでの権限検証を推奨しています。本サイトの提案は、それをAIへの依頼文だけでなく、実行可能なテストへ落とすことです。画面のボタンを隠すだけでなく、APIやファイル配信側で拒否できる必要があります。出典：OWASP：Authorization Cheat Sheet。
- 資産：顧客情報、請求書、管理権限、決済情報のどれを守るか。
- 主体：未ログイン、一般利用者、別組織、管理者、バッチを区別する。
- 禁止：認証の迂回、他組織のデータ取得、本番資格情報の使用を許さない。
- 検証：成功する操作と拒否される操作を対で定義する。
WordPressの独自機能でも、ログイン判定と操作権限の確認、対象データの所有関係は別々の論点です。「投稿者だから全会員の情報を取得してよい」とは限りません。フレームワークの標準的な認証を使っても、サイト固有の業務条件まで自動で満たされると考えないようにします。
スポンサーリンク
テストが通っても認可の抜けは残る
仮想の請求書APIで、利用者Aが自分の請求書を取得するテストだけをAIが作ったとします。実装とテストがともに所有者の確認を忘れていれば、テストは成功します。そこで人が仕様から独立した観点を追加します。AIにテストを増やさせる場合も、期待値を実装から逆算させないことが大切です。
| 試す条件 | 確かめたいこと |
|---|---|
| AがAの請求書を取得 | 許可された内容だけ返る |
| AがBの請求書IDを指定 | 本文・添付・プレビューを含めて漏れない |
| 別組織の管理者がアクセス | 役職が高くても組織境界を越えない |
| 権限失効後に同じURLを再使用 | キャッシュや署名URLの有効期間を含め仕様どおり拒否する |
| 権限確認処理でエラーが起こる | 許可へ倒れず安全に失敗する |
これは認可に絞った確認例で、網羅的な試験表ではありません。更新APIなら、送信された管理者フラグや所有者IDを無条件に保存しないかも確認します。出力処理なら文脈に応じたエスケープ、DB操作なら値とクエリの分離を見ます。業務の抜けと危険な実装パターンは、別の検査で探します。
コードを渡す前にエージェントの権限を決める
開発用の複製と架空データを用意し、本番DB、管理者Cookie、SSH鍵、クラウド管理トークンを作業環境から切り離します。秘密をプロンプトへ貼らなくても、読み取り可能な設定ファイル、環境変数、ログ、ブラウザーのログイン状態から届くことがあります。Gitの追跡対象外にしただけでは、AIや子プロセスからのアクセス制限にはなりません。
別ブランチやworktreeは変更の衝突を避ける仕組みで、OS上の権限分離とは違います。コンテナも、ホームディレクトリやDockerソケットを広く共有すれば隔離が弱まります。本サイトでは、作業領域、外向き通信、資格情報の三つを実際の設定で確認し、危険な操作を文章で禁止するだけにしない運用を提案します。
Claude Codeの公式資料も、承認したBashコマンドがOSの利用者権限で動く点と、ファイル・ネットワークの隔離を区別しています。コマンド名の許可だけで通信先まで制御できるとは限りません。使うクライアントやモードで範囲が違うため、導入時の設定を確認します。出典：Anthropic公式：Claude Codeのセキュリティ。
外部のIssue、README、テストログ、MCPの応答も、第三者が命令を紛れ込ませる入口になり得ます。仮に「検査を直すため認証を外す」「診断用に設定を送る」と書かれていても、作業権限の根拠にはしません。テストのために未知のスクリプトを実行する際も、コードを読む工程と実行を許す工程を分け、失敗を直すための権限拡大を自動で繰り返さないようにします。
スポンサーリンク
Codexは実行権限とコード検査を分けて使う
Codexで最初に確認したいのは、実行している場所と権限設定です。OpenAI公式資料では、サンドボックスが技術的に可能な操作を制限し、承認ポリシーがどの操作で確認するかを制御すると説明されています。ローカルCLI・IDEとクラウドの設定を同一視せず、読み取り・書き込み・通信の実際の範囲を確かめます。出典：OpenAI公式：Codexの承認とセキュリティ。
例えば本サイトでは、既存の認可処理を調べる工程は読み取りを中心にし、修正するときだけ対象の作業領域への書き込みを許す使い方を提案します。読み取り専用でも秘密情報を読める状態なら、情報漏えいの対策は別途必要です。また、シェルの通信制限だけで、接続したアプリやMCPまで一律に停止したとは判断しません。
通常のCodexへ差分レビューを頼むことと、Codex Securityで検査することも区別します。前者には対象コミット、元の要件、成立条件を渡します。後者には検査範囲とセキュリティ上の前提を設定し、対象の版、調べた領域、未検査の領域、指摘の根拠を確認します。どちらも「指摘ゼロ」を無条件の公開許可へ変換しません。
スキル・プラグイン・MCPは役割を分けて選ぶ
スキルは繰り返す確認手順を共有するのに向きます。プラグインは複数の機能やフックなどをまとめる場合があり、MCPは外部の道具・データへ接続するために使われます。名称が同じでも各製品で仕様は異なります。スキルの文章に「送信禁止」と書くことと、送信できない権限を設定することは同じではありません。
Claude CodeではSKILL.mdに指示を記述し、補助ファイルや動的なコマンド実行を組み合わせられます。そのため、本文だけでなく同梱スクリプトや読み込む設定も確認対象です。リポジトリに含まれる手順を、そのまま安全な社内規則として扱わないようにします。出典：Anthropic公式：スキルによる拡張。
導入前には、公式サイトから配布先へたどれるか、管理者と更新履歴が確認できるか、追加される実行処理・通信・認証範囲が用途に見合うかを調べます。公式カタログへの掲載と、自分の顧客データを送ってよいという判断は分けます。導入後も、更新でフックやMCP接続が増えていないかを差分で確認します。
導入候補にできる検査ツールと公式プラグイン
以下は2026年10月17日に公式資料を確認した候補です。本サイトが同一コードで性能を比較・実測したランキングではありません。契約、対応言語、クライアントの版、データの扱いを確認して選びます。
| 候補 | 主な役割 | 過信しない点 |
|---|---|---|
| Codex Securityプラグイン | ローカルリポジトリを検査し根拠付きの指摘を確認する | 通常のCodexの権限設定とは別の機能で検査範囲と利用条件の確認が必要 |
| Semgrep Guardian | 生成中のコードを検査して指摘をエージェントへ返す | 開発中の検査はCIや人の業務レビューを置き換えない |
| Claude Code security-guidance | 同じ作業セッションで変更をセキュリティ観点から再確認する | 書き込みやコミットを止める強制ゲートではない |
| GitHub CodeQL | 対応言語のコードを解析してアラートを出す | 言語・設定・検査範囲に依存し業務要件の完全性を保証しない |
| GitHub secret scanning | リポジトリなどへ露出した資格情報を検出する | 送信前の全経路の遮断や漏えい後の失効を代行する保証ではない |
Codex Securityのローカル向けプラグインは、ChatGPTデスクトップアプリのCodexやCodex CLIで使う検査機能です。標準スキャンはソースを変更せず、根拠と修正方針を含むレポートを残します。接続したGitHubリポジトリをクラウドで扱うCodex Security Cloudは別のプラグインです。利用条件と対応環境を確認し、ローカル検査・クラウド検査・修正作業の許可を混同しないようにします。出典：OpenAI公式：Codex Securityプラグインの導入、OpenAI公式：Codex Securityの実行方法。
Semgrep GuardianはMCP、Hooks、Skillsを組み合わせます。公式資料のCodex・Claude Code向け推奨構成は、ホスト型サーバーとOAuthを使う方式です。ローカルCLI方式とは適用ルールが異なり、推奨プラグインの固定ルールには組織のPoliciesが適用されないと説明されています。既存ポリシーが効くと思い込まず、必要な検査項目と送信範囲を確認します。出典：Semgrep公式：Guardianの仕組みと構成、Semgrep公式：Codex・Claude Code向け導入手順。
Claude Codeのsecurity-guidanceは、編集時のパターン検査や変更のレビューを行う公式プラグインです。資料では、どの層も書き込み・コミットをブロックしないと明記されています。警告が出ることと、未修正のコードをマージできなくすることは別です。導入時には必要なPython環境などの前提条件も確認してください。出典：Anthropic公式：security-guidanceの導入と限界。
GitHubではCodeQLによるコード解析と、secret scanningによる資格情報検出を別の層として使えます。利用可否はリポジトリ種別や契約に依存します。秘密を検出したら値の削除だけで完了せず、失効・交換と利用履歴の調査へ進みます。出典：GitHub公式：CodeQL code scanning、GitHub公式：Secret scanning。
自作するなら小さなレビュースキルから
CodexでもSKILL.mdに手順をまとめ、必要ならスクリプトや参照資料を同梱できます。ローカルのリポジトリ用スキルは.agents/skillsが配置先の一つです。例えば「認可変更レビュー」というスキルに後述の確認手順をまとめ、関係する差分と拒否系テストを読むよう明示します。スキルは手順の再利用であり、サンドボックスやCIの強制条件を置き換えるものではありません。出典：OpenAI公式：ChatGPT・Codexのスキル作成。
最初から万能な監査スキルを作るより、「このプロジェクトの認可変更を点検する」など範囲を絞ります。次は本サイトが提案する手順の原稿です。特定クライアントへそのまま配置できる完成パッケージではなく、各ツールの対応形式と権限設定に合わせて実装します。
- 元の要件と対象コミットを確認し、実装者の説明を正解として扱わない。
- 入口からデータ取得・更新まで追い、認証、所属、所有関係の判定場所を示す。
- 拒否されるべき操作をテストにし、既存テストの削除・緩和も確認する。
- 指摘には場所、成立条件、影響、再現方法を付け、推測は未確認と書く。
- 実行した検査、失敗した検査、対象外の範囲を区別して報告する。
評価には、問題を仕込んだ架空コードと安全な比較例を使います。危険を見つけられるかだけでなく、問題のないコードを誤って修正しないかも見ます。スキルが読まれなかった、スキャナーが落ちた、対象ファイルが除外された場合に「指摘ゼロ」へまとめない設計が必要です。
スポンサーリンク
AIレビューと独立した公開条件を置く
AIが修正し、AIが安全だと言っただけでマージしないようにします。認証・認可、決済、管理機能、データ移行は、変更対象を小さくし、人が業務要件と照合します。別モデルでのレビューは観点を増やせますが、同じ誤解を共有する可能性があります。二つのAIの一致を安全性の証明にはしません。
本サイトの提案は、保護されたブランチやCIで必須検査を管理し、変更を書く権限と検査条件を緩める権限を分けることです。スキャン失敗や未実行は合格とせず、例外を認める場合は理由・責任者・期限を残します。誤検知の除外も、指摘を消すためではなく成立条件を検証して判断します。
NISTのSSDF 1.1は2022年2月公表の、安全な開発工程へ組み込む実践をまとめた資料です。AI専用の製品選定表ではありません。本稿では、生成を速くするほど、要件・検証・修正後の確認を工程に残す必要があるという位置付けで参照しています。出典：NIST：SP 800-218 SSDF 1.1。
公開後まで含めて小さく運用を始める
公開するのは、レビューしたコミットと対応する成果物に限定します。ステージングで拒否系の動作を確認し、障害時の機能停止とロールバックを準備します。DB変更はコードを戻すだけでは復旧しない場合があるため、移行手順、バックアップ、復元可否も別に確認します。
初回は「検証用データの環境」「認可の受け入れ条件」「既存の検査ツール」「人が判断する公開条件」を一つずつ整える方が、拡張を大量に導入するより運用を把握しやすくなります。認可エラーの増加や意図しない大量操作を監視し、問題が起きたらコードだけでなく、AIへ与えた権限や依頼条件も振り返ります。
OWASP ASVSのような検証基準を使う場合も、版と対象要件を明記します。「ASVSを確認した」という一文だけでは、何を試験し何が残ったか分かりません。出典：OWASP：Application Security Verification Standard。
AIコーディングで意識したいのは、生成のたびに安全を祈ることではなく、失敗を見つけて止められる流れを用意することです。スキルで手順を揃え、検査ツールで根拠を増やし、実際の権限と公開条件で影響を抑える。この三つを組み合わせて、変更の速さに見合う確認を続けます。
スポンサーリンク
関連記事
参考資料
- OpenAI公式：Codexの承認とセキュリティ
- OpenAI公式：ChatGPT・Codexのスキル作成
- OpenAI公式：Codex Securityプラグイン
- OpenAI公式：Codex Securityの実行方法
- OWASP：Authorization Cheat Sheet
- OWASP：ASVS
- Anthropic：Claude Code Security
- Anthropic：Skills
- Anthropic：Security guidance plugin
- Semgrep：Guardian概要
- Semgrep：Guardian Quickstart
- GitHub：Copilot Agentsの責任ある利用
- GitHub：CodeQL code scanning
- GitHub：Secret scanning
- NIST：SSDF 1.1（2022年2月公表）
OpenAIの資料は2026年10月18日の追記時に再確認し、その他の資料は10月17日に確認しました。随時更新されるドキュメントの確認日と、製品機能の提供開始日・資料の公表日は同じではありません。導入前に最新の対応環境と利用条件を再確認してください。
