AI開発のセキュリティ対策
｜
Claude Code・Codexの
公式ツールと点検手順

Claude CodeやCodexで作った業務アプリを、公開してよいか判断したい方へ。

AI開発のセキュリティ対策では、別の会社のデータを取得・変更できないこと、秘密情報が漏れないことを確かめます。制作担当へ、利用者の権限ごとに試した結果と、未確認の機能を確認してください。

この記事は、自社の業務アプリを作る経営者・開発責任者向けです。公式ツールの使い分け、制作担当へ渡す依頼文、公開前に試す操作を、架空の顧客管理アプリで示します。

AIを業務で使う際の入力ルールではなく、完成したアプリを利用者へ渡す前の点検を扱います。

AIに何を読ませ、どの操作を許すかはClaude Codeの法人導入で確認する権限と機密情報、直近の事件と自社の情報管理は情報漏洩の公式発表から考える生成AIの対策で扱っています。

この記事で分かること

• スキルによるコード確認と、アプリ側のアクセス制限を分けて考えます
• 架空の別会社アカウントで、他社データの閲覧・更新を拒否できるか試します
• 点検した版と未確認の範囲を残し、責任者が公開を判断します

スキルは確認の手順です。
アプリを守る機能は別に作ります

スキルは、AIへ読ませる手順や参考資料をまとめたものです。認証やデータの権限を確認するようAIへ伝えられますが、スキルを追加しただけで、アプリにアクセス制限が実装されるわけではありません。

OpenAIも、スキルを繰り返し行う仕事の指示と資料として説明しています。

例えば、顧客一覧を開くたびに利用者の所属会社を確かめ、その会社のデータだけを返す処理は、アプリ側で動かす必要があります。スキルは、その処理の抜けを探す補助です。

「安全に作って」と指示した記録と、アクセスを拒否した動作の記録は、別々に残してください。

発注する場合も、「セキュリティ対策済み」という一言だけでは確認できません。守るデータ、利用者の権限、確認した操作、残った問題を制作担当と共有します。

NISTの安全なソフトウェア開発の枠組みも、開発工程へ対策を組み込み、発注者と開発者が共通の言葉で確認する用途を説明しています。

どのスキルを、どの
AIに入れる？

スキルはAIが読む手順書、プラグインは手順書や実行機能をまとめて追加する仕組みです。次の表のCodex用3スキルは、Codex Securityプラグインに含まれています。手順書のファイルを一つずつ探して、手作業でコピーする必要はありません。

Claude Codeの同梱コマンドは追加不要で、security-guidanceは別に導入するプラグインです。Web版のChatGPTやClaudeへ、下記のコマンドを貼り付けるだけではインストールされません。

Codex側の3つは、順番に別製品を買うという意味ではありません。入れるプラグインは一つです。全体の調査はsecurity-scanから始め、守る条件や危険な経路の整理が必要なときに、対応するスキルを使います。

出典：Codex Securityの公式導入案内、define-security-policyの手順書、threat-modelの手順書、公式のスキャン手順。配布元と内容は2026年10月17日に確認しています。

Codexに取り込ませる手順

自社のコードをモデルへ送ってよい契約か、利用枠・追加費用・組織の許可を確認してから導入します。セキュリティ確認のためでも、機密情報を未承認の環境へ渡してよい理由にはなりません。

1. Codexを開き、Plugins（プラグイン）を開きます。
2. 「Codex Security」で検索し、提供元がOpenAIのプラグインを選びます。名前の似た非公式製品と区別してください。
3. 説明を確認してインストールし、有効になっていることを確認します。
4. Securityを開き、Scansから「+ Scan」へ進みます。対象のアプリのフォルダーとコードの版を確認してから開始します。

表示されない場合は、プラグインが有効か、アプリが対応する版か、管理者が利用を許可しているかを確認します。

GitHubへ接続してクラウドで調べるCodex Security Cloudは別のプラグインなので、最初から必要になるわけではありません。

アプリのフォルダーやコードの版が分からない場合は、開発担当へ「今回公開するコードの置き場所と、点検する版を教えてください」と依頼します。

自分のパソコンにコードがなければ、開発担当の許可された環境で実行してもらい、対象と結果を確認してください。

初めて使う場合は、上の画面操作から1回の調査を始めれば十分です。下の会話から頼む方法は別の入口であり、同じ調査を両方で実行する手順ではありません。

ターミナル版のCodex CLIでは、調べたいアプリのフォルダーでCodexを起動し、/pluginsで検索・導入した後、/newで新しい会話を始めるのが公式の手順です。

取り込ませた後、
AIへどう頼めばよい？

画面から開始する代わりに、条件を文章で伝えて調査を始めたい場合の例です。先頭の表記は、公式が案内するスキルの指定です。自分に調査する権限があるコードだけを対象にし、実行できる操作と利用枠は事前に確認してください。

$codex-security:security-scan を使って、この業務アプリのコードを確認してください。
最初に、対象フォルダー、コードの版、調べる範囲を私と確認してください。
会社Aの担当者が、会社Bの顧客や添付ファイルを取得・変更できないことを重視します。
本番へのアクセスや設定変更、ファイル削除、外部への報告、公開は許可しません。
見つけた問題、根拠、未確認の範囲、実際に動作を試したかを分けて報告してください。

この日本語部分は依頼文の設計例です。プラグインへ実行した結果や、その検出精度を示したものではありません。

調査対象が選ばれたか、結果に対象の版と確認範囲が書かれているかを見て、通常のチャット回答だけで終わっていないか確かめます。

守る条件から相談したい場合は「Codex Securityのdefine-security-policyを使い、このアプリで守る条件を整理してください。文書の保存先と内容は先に確認してください」と頼みます。

構成から危険な経路を整理したい場合は、threat-modelを指定し、設計の整理と動作検査を混同しないよう依頼します。

公開されたURLをAIに渡すことと、そのスキルが利用できる状態になることは別です。

手順書を読めたという返答だけでは導入完了にしません。会社の許可と、利用中の環境に合う公式の導入方法を確認してください。

ログインできることと、
他社データを扱えることを分ける

ログインは、利用者が誰かを確かめる仕組みです。どの会社の顧客を見たり変更したりできるかは、別の確認で、「認可」と呼びます。

ログイン済みの利用者でも、他社の顧客情報を取得できるなら問題があります。OWASPの認可ガイドも、この区別と、通信のたびに権限を検証する必要性を示しています。

顧客一覧だけでなく、
個別ページとCSVも確認する

ここからは、架空の会社Aと会社Bが、それぞれ自社の顧客を登録するアプリを考えます。Aの担当者はAの顧客だけを閲覧・更新でき、Bの顧客は扱えない設計です。実際の顧客や導入結果を示した例ではありません。

一覧でBの顧客を非表示にしても、個別ページのURLを開けたり、CSVにBの行が混ざったりすれば、情報は漏れます。画面のボタンを隠す処理に加え、APIという画面の裏側の通信でも、データを返す前や変更する前に権限を確かめます。

IDを長い乱数にして推測しにくくしても、権限確認の代わりにはなりません（OWASPの認可ガイド）。

コードでは、所属会社を
どこで確定するかを見る

次は確認する場所を示した擬似コードです。動くプログラムでも、AIの実行結果でもありません。「ログイン済みだから取得してよい」としていないかを、制作担当と読むための見本です。

確認が足りない処理の例：
ログインを確認する
指定された顧客IDで、顧客情報を取得する

確認したい処理の例：
ログインを確認する
認証情報と所属記録から、利用者が所属する会社を確定する
その会社で、この操作をしてよい権限があるか確かめる
顧客IDと所属会社の両方で、対象の顧客情報を探す
権限がない場合や対象が見つからない場合は、情報を返さず変更もしない

利用者が入力した「会社ID」をそのまま信用すると、別会社の番号に書き換えられるおそれがあります。所属と権限は、サーバー側で確認した情報から決めます。

更新・削除・添付ファイルの取得にも同じ考え方を適用し、データベース側で制限できる範囲も確認します。コードを読んだ後には、テスト用アカウントによる動作確認が必要です。

秘密情報と追加ライブラリも、
公開する前に調べる

APIキーは、ブラウザへ
渡していないか

外部サービスへ接続するAPIキーは、持っている人が操作できる鍵です。管理者用のキーを、利用者のブラウザへ配るJavaScriptや公開ファイルへ入れない設計にします。画面で見えなくても、配信したファイルから取得される場合があります。

すべてのキーを同じ扱いにはしません。公開を前提とする識別用の値と、管理者操作ができる秘密のキーでは役割が異なります。

制作担当には、各キーの用途と権限、置き場所、利用者へ渡るかを説明してもらいます。OWASPの秘密情報管理ガイドを基に、必要な権限への限定や更新・失効の方法まで確認してください。

既に公開した秘密情報は、コードから削除するだけで対応を終えません。gitの過去履歴、ビルド結果、ログへ残る可能性があります。

該当キーを無効化・再発行し、利用履歴と影響範囲を担当者が調べます。調査に必要な記録を保存し、同じキーを使う連携の変更も確認します。

AIが追加した部品の
名前とバージョンを残す

アプリに使うライブラリは、他の開発者が作った部品です。AIが追加した場合も、入手元、バージョン、ライセンス、更新を担当する人を確かめます。

既知の脆弱性を調べる検査と、アプリ固有の権限を読むレビューは、それぞれ必要です。Claude Securityも、依存関係の検査を置き換える製品とは説明していません（公式README）。

「警告が出たので全部最新版にする」と、動いていた機能が壊れることもあります。該当バージョンを使っているか、問題の機能がアプリから呼ばれるかを調べ、修正後に必要な操作を試します。

検査で問題が出なかった場合も、未知の問題や本番の権限設定まで確認できたとは判断しません。

各公式ツールの注意点と、
Claude Codeへの追加方法

導入前に、何を読み、どこへ送り、どの利用枠を使うかを確認します。以下は2026年10月17日に公式原典で確認した内容です。弊社で導入・稼働させた比較や、検出精度の測定ではありません。

①変更したコードを
調べる：
Claude Codeの同梱コマンド

Claude Codeの/security-reviewは、変更したコードを対象とする同梱コマンドです。「security-reviewという公式プラグインを追加する」という意味ではありません。

Anthropicの公式READMEに利用方法があり、公開されたコマンド定義も確認できます。

取り込ませる操作は不要です。調べたいアプリのフォルダーでClaude Codeを開き、内容をモデルへ送ってよいことと利用枠を確認したうえで、入力欄に次のコマンドを入れます。Web版Claudeの通常チャットではなく、開発用のClaude Codeで実行します。

/security-review

制作担当が公開前の変更内容を確認し、権限の抜けなど、新しく加わった問題を調べる用途です。公開定義には対象外とする問題もあるため、既存コード全体やサービス停止への対策まで確認済みにはできません。

公開定義の利用・改変等はMITライセンスに従い、Claudeの利用条件と利用枠も別に確認します。

②開発中に自動で
調べる：security-guidance

Anthropic公式のsecurity-guidanceは、編集時の危険なパターンの警告に加え、AIの応答が終わった際の変更箇所の確認と、変更を履歴へ保存する際の関連コードの確認を行うプラグインです。

AIモデルによる確認では、変更箇所や関連コードが設定先のモデルへ送られ、通常の作業とは別に、利用枠の消費や従量料金が発生します。

接続先がAnthropicか、会社の中継先か、別のクラウドかでも適用条件は変わります。コードを送ってよい契約か、追加利用を許可するかを決めてから有効にしてください。

ライセンスはApache 2.0です（送信・利用量の説明、ライセンス）。

自動のAIレビューは既定で有効になるため、接続先と利用量を管理する担当者が、導入の可否を判断します。許可を得て導入する場合の公式コマンドは次のとおりです。本記事の制作ではインストールしていません。

/plugin install security-guidance@claude-plugins-official

Claude Codeの入力欄で実行し、プラグインの導入・有効化の表示を確認します。対応するClaude CodeとPythonなどの実行環境が必要なので、表示が違う場合は公式の前提条件を開発担当者と確認してください。

以後の編集や作業の区切りに確認が走る方式であり、普通のチャットへ名前を書くたびに使うスキルとは異なります。

③Codex Securityの
報告書で確認すること

コード全体を対象に選んでも、実際の業務操作や本番の設定をすべて確認できる意味ではありません。導入済みという表示だけで、検査が終わったことにもしないでください。

公式の通常スキャンは、ソースを変更せず報告書を保存する流れです。読む範囲、対象の版、重要な操作を指定し、結果では見つかった問題だけでなく、確認されなかった範囲と、実行して確かめたかを読みます。

コードを読んだ根拠だけで検証される場合もあり、すべての指摘に再現操作を行うわけではありません（公式スキャン手順）。

現行の配布定義のライセンス欄はProprietaryです。公開されていることと、自由に再配布できることを分けて確認してください。コードをモデルへ渡す際の契約と設定、利用枠も事前に確認します。

古いOpenAIの
security系スキルを見つけたら

OpenAIの旧リポジトリには、security-best-practices、security-threat-model、security-ownership-mapが実在します。

順に、言語別の安全な実装、危険な経路の整理、git履歴から見た担当者の偏りを調べるスキルです。各ディレクトリのLICENSE.txtはApache 2.0でした。

ただし、openai/skillsの現行READMEはリポジトリの非推奨化と、現行のopenai/pluginsへの案内を表示しています。

古い導入記事をそのまま実行せず、現在の配布先を確かめます。旧スキルと現行Codex Securityが同じ名称・機能で移転したとは扱いません。

公開前に、別会社の権限で
実際に操作する

コードを確認した後は、公開を予定する版を試行環境へ置き、架空データで操作します。本番の顧客データを使ったり、他社サイトを試したりする必要はありません。

以下は顧客管理アプリの受入テスト、つまり発注した条件を満たすか確かめる操作の設計例です。

AとBのテスト用アカウントを作り、権限が広い管理者のログイン状態が混ざらないよう、別のブラウザープロフィール等で分けます。

Aの担当者が通常の仕事をできることも、同じ版で確認してください。「他社の操作を拒否する」と「自社の必要な操作はできる」の両方が条件です。

実際のAPIへの確認は、制作担当が合意した試行環境とテスト用データで行います。この表は実行済みの結果ではなく、合否の条件を決めるための見本です。

データ以外にも、エラー時に秘密情報を表示しないか、バックアップから復旧できるか、外部連携を止められるかをアプリの機能に合わせて加えます。

OWASPのASVSは、Webアプリの対策を検証する要件を提供しています。必要な項目を制作担当と選び、版と確認結果を記録します。

項目を埋めただけで公開を許可せず、他社データを取得できるなどの問題が残る場合は、修正して再確認します。

制作担当へ渡す
公開前の点検依頼文

「公式スキルを入れてください」だけでは、何をもって完了にするかが決まりません。利用者とデータの関係、調べる範囲、実行してよい操作を添えて依頼します。

次は、架空の顧客管理アプリを確認するために作った文面です。AIで実行した結果を保証する指示文ではありません。

顧客管理アプリの公開前点検をお願いします。

守りたい条件：
会社Aと会社Bは、それぞれ自社の顧客だけを閲覧・変更できます。
他社の顧客情報と添付ファイルは取得できません。
管理者用の秘密情報を、利用者のブラウザや出力へ渡しません。

最初に確認したいこと：
対象のコードの版と、調べる画面・通信・データ保存先を示してください。
使うスキルや検査ツール、その出所、外部へ送る情報、追加利用の有無を説明してください。
本番操作、外部送信、追加費用を伴う実行は、この依頼だけでは許可しません。

点検してほしい内容：
所属会社と操作権限を、サーバー側で確かめているか。
個別URL、CSV、更新・削除、添付ファイルにも制限があるか。
キーの保存先と公開範囲、追加ライブラリのバージョンに問題がないか。

結果の報告：
確認した範囲、問題の根拠、修正案、未確認の範囲を分けてください。
コードを読んだ判断と、実際に操作した結果を分けてください。
動作確認は、事前に合意した試行環境・架空データ・テスト用アカウントに限ります。
本番公開は点検に含めず、残る問題と確認結果を責任者へ戻してください。

依頼後に受け取るのは、「指摘が何件だったか」という数字だけではありません。例えば「CSV出力は確認したが、添付ファイルは未確認」と分かれば、公開前に残すべき作業を決められます。

AIが「問題なし」と返しても、調べなかった範囲が消えるわけではありません。

公開は、対象の版と
残った問題を見て判断する

公開を決める責任者は、点検した版と公開する版が同じか、未確認の機能が残っていないかを確かめます。コードの修正後に権限や外部連携を変更した場合は、影響する操作を試し直してください。

確認した範囲・根拠・対象の版を残す考え方は、Codex Securityの公式手順でも説明されています。

公開後の修正担当、問題が起きたときの連絡先、停止する方法も引き継ぎます。スキルを使った人が異動した後も、キーの失効や権限変更を行える体制が必要です。

複数のサービスを連携するアプリでは、連携先の契約や設定を含めて確認できる担当者を決めておきます。

最初の一歩は、制作担当へ「誰が、誰のデータを、どこまで扱えるアプリか」を渡すことです。まるっとAIへの相談でも、使いたい業務と公開範囲を基に、必要な権限、点検、運用中の確認を含めて検討できます。