AIセキュリティ入門｜APIキー漏洩・入力情報・権限設定で確認すべきこと

01AIセキュリティで最初に確認する4項目

AIセキュリティでは、情報が外へ漏れること、データが書き換わること、サービスや予算が使えなくなることを分けて考えます。「AIに何を頼んだか」だけでなく、何を読めて、どこへ送れて、何を変更できる状態かを確認することが出発点です。

Web版とAPI版では確認場所が違います

Web版を使う人は、ログイン設定、会話・ファイルの保存、共有リンク、データ利用設定、外部アプリとの接続を確認します。APIを組み込む人は、これにキーの管理、サーバー側の権限、実装した処理、利用量と請求の管理が加わります。Web版の有料契約だけでAPI料金まで含まれると決めつけず、使っている契約と請求先を確認してください。

読み取りから始める方法は、書き換えや削除の危険を減らします。ただし、機密情報を読めるなら、読み取り専用でも情報漏洩の影響は大きくなり得ます。次の章から、キー・データ・権限・費用を順に分けて見直します。

根拠：OpenAI｜Best practices for API key safety、OWASP｜AI Agent Security Cheat Sheet

02APIキー漏洩時の対処と、漏らさない管理

ここで扱うのは、AI APIへの認証に使う秘密のAPIキーです。漏れると、そのキーに許可された範囲で不正利用やデータへのアクセスが起き、想定外の請求につながる可能性があります。公開用の識別子と同じものとして扱わないでください。

注意公開場所から消すだけでは、漏れたキーは無効になりません。環境変数へ移す、リポジトリを非公開にする、履歴を書き換えるという対応だけでは、すでに取得されたキーによる利用を止められません。

漏洩が疑われるときの対応

1. 対象と影響を確認します。どのプロバイダー・プロジェクト・キーか、公開場所と時刻、本番への影響を確認します。調査のためにキーの全文をチャットや問い合わせへ貼り直さないでください。
2. 提供元の手順で、漏れたキーを速やかに無効にします。不正利用が進行中、または強い権限を持つキーの公開など、危険が大きい場合は停止を優先します。本番の停止を避ける切替が必要な場合は、責任者と調整し、新キーへの短時間の移行と旧キー失効を一続きで進めます。
3. 新キーを安全な場所へ設定します。漏洩経路を直し、本番・開発・定期実行・外部連携などの利用箇所を更新します。新キーを古い公開コードへ戻さないでください。
4. 旧キーの失効とアプリの復旧を別々に確認します。旧キーが管理画面で無効になったことと、新キーで必要な処理が動くことの両方を確認します。
5. 利用履歴と請求を調べます。確認できる期間・モデル・プロジェクト・操作の記録を照合し、見覚えのない利用があれば提供元と組織の担当者へ相談します。キー失効は、すでに送信されたデータや発生した料金を取り消す操作ではありません。
6. 露出の除去と再発防止を行います。現在のコードだけでなく、コミット履歴、配布済みファイル、ログ、スクリーンショットも確認します。調査に必要な記録はアクセスを制限して保全し、不要な秘密の複製は残さないようにします。

根拠：GitHub｜Remediating a leaked secret

根拠：OpenAI｜Best practices for API key safety、Anthropic｜APIキーの侵害が疑われる場合、Google｜Using Gemini API keys

無効化の順序は、提供元の仕様と事故の重大さ、本番停止の影響で変わります。どの場合も、漏洩したキーを有効なまま使い続けるための猶予と考えないでください。

旧キーがファイルに残る問題も分けて見ます。有効な旧キーが残れば不正利用の余地があります。一方、提供元で失効済みの旧キーをアプリが使い続けると、主な問題は認証エラーやサービス停止です。失効したキーが残るだけで、そのキーによる認証が引き続き成功するという意味ではありません。

環境変数やシークレット管理は、予防策として使います

コードへ秘密の値を直接書かず、サーバー側の環境変数やシークレット管理から必要な処理にだけ渡します。ただし、環境変数に入れたこと自体は安全の保証ではありません。実行プロセス、ログ、デバッグ出力、ビルド成果物に値が出る経路も確認します。クライアントへ配布するHTML・JavaScript・アプリに埋め込まれれば、変数を使っていても秘密ではなくなります。

• ローカル開発：.envを使う場合は、リポジトリや公開フォルダへ入れません。.gitignoreはすでに追跡中のファイルや過去の履歴を消す機能ではありません。
• 本番：ホスティングやクラウドのシークレット管理を使い、値を取得できる実行環境と担当者を絞ります。管理画面の画像や障害ログへの写り込みも確認します。
• 用途分け：開発・本番・試作でキーやプロジェクトを分け、権限も必要範囲へ絞ります。キーだけ分けても、すべて同じ広いデータ権限を持つなら、データの分離にはなりません。

根拠：OWASP｜Secrets Management Cheat Sheet、GitHub｜Ignoring files、Google｜Using Gemini API keys、OpenAI｜Managing projects in the API platform

確認日時：
サービス／プロジェクト：
対象キーの管理用名称（秘密の値は記載しない）：
露出した場所・期間：
対応責任者：
旧キーの失効日時と確認方法：
新キーへ更新した利用箇所：
更新が残る箇所と復旧状況：
不審な利用・請求の確認結果：
漏洩経路の修正と相談先：

03入力情報と学習・保存・外部送信を分ける

クラウド型AIへ文章やファイルを渡すことは、そのサービスへデータを送ることです。会話欄への入力だけでなく、連携先から取得したメール、アップロードしたPDF、RAGが検索した文書、外部検索に使う語句も対象になります。

送信前に、情報を必要な範囲へ減らします

• 認証情報：APIキー、パスワード、アクセストークン、秘密鍵は相談文やコード例から除きます。エラー相談ではYOUR_API_KEYなどのダミー値に置き換えます。
• 個人情報・社内情報：氏名だけでなく、所属、日付、案件名、取引内容などの組み合わせを確認します。名前を「Aさん」にしただけで、必ず個人を特定できなくなるわけではありません。
• 機密資料：そのAIサービスと機能で扱ってよいか、社内ルールや契約、データ管理の担当者に確認します。許可を確認できなければ、実データではなく架空の例や必要箇所だけの相談に切り替えます。

公開情報でも、正確さや利用できる範囲の確認は必要です。また、公開用のプロジェクトIDや広告タグのIDを、秘密のAPIキーと一律に同じものとして扱う必要はありません。何の権限を与える値か、公開を想定したものかを提供元の説明で確認します。

「学習されない」と「保存されない」は別です

例えばChatGPTでは、「Improve the model for everyone」をオフにすると新しい会話はモデルの学習に使われませんが、通常の会話は履歴に残り得ます。OpenAI APIも、明示的にデータ共有へ同意しない限り学習に使わない方針と、不正利用監視ログや機能ごとの保存条件を分けて説明しています。こうした条件は、別サービスへそのまま当てはめず、利用中の入口と機能ごとに確認してください。

根拠：OpenAI｜Data controls in ChatGPT、OpenAI｜Data controls in the OpenAI platform

RAGでは、元の閲覧権限を検索結果にも引き継ぎます

RAGは、関連文書を検索してAIの回答材料に加える仕組みです。社内文書が入っているから安全とは限りません。利用者が見られない文書は、AIへ渡す前の検索段階で除外します。元文書の権限変更や削除を、検索用の断片・索引・キャッシュにも反映させる設計が必要です。「この人には見せないで」とAIに頼むだけで代用しないでください。

根拠：OWASP｜RAG Security Cheat Sheet

04読み取り・変更・外部送信の権限を分ける

最小権限とは、作業に必要な対象と操作だけを許可する考え方です。予定確認には予定を読む権限、返信案の作成には必要なメールを読む権限があればよく、最初から削除や送信まで許可する必要はありません。

注意「読み取り専用」でも、外部への情報送信は起こり得ます。例えば、読んだ秘密情報がURLの一部に入った状態で外部ページや画像を取得すると、取得先へその情報が渡る可能性があります。ファイルを変更しないことと、秘密が外へ出ないことは別です。

根拠：OpenAI｜Preventing URL-Based Data Exfiltration in Language-Model Agents（2025年1月20日）

承認は「何を、どこへ、どの内容で」に結び付けます

メールや投稿は宛先・本文・添付、ファイル操作は対象・変更点・共有範囲、外部APIは送信先と引数を確認してから実行する設計にします。読取系のツールでも、機密情報を新たな送信先へ渡すなら確認対象です。内容が変わったのに以前の承認を使い回さないよう、実行側で承認した操作との一致を確かめます。

「外部文書の命令に従わない」という指示は補助になりますが、強制的なアクセス制御の代わりにはなりません。MCPなどの連携も、接続先の実体と与えた権限を確認します。サンドボックスは設定された対象の隔離に役立ちますが、読める秘密、許可した通信、隔離の対象外のツールまで一律に守るものではありません。

根拠：OWASP｜AI Agent Security Cheat Sheet、OWASP｜LLM Prompt Injection Prevention Cheat Sheet、Anthropic｜Configure the sandboxed Bash tool

外部文書がAIの判断を変える問題を詳しく知りたい場合は、プロンプトインジェクションの意味と対策で、RAG・MCP・Web取得に分けて確認できます。

05Usage・Billing・上限と、日常の見直し

APIの利用量を見て、普段の時間帯・モデル・用途と比べます。急増は不正利用の手がかりですが、処理のループ、再試行、正規のアクセス増加でも起きます。増えた理由を確認せずに、不正利用とも安全とも決めつけないでください。漏洩の根拠がある場合は、請求の確定を待たずにキーの対応を進めます。

通知・支出上限・レートリミットは役割が違います

確認時点のOpenAI APIでは、組織またはプロジェクトに月間の支出上限を設定し、「Enforce a hard limit」を有効にする仕組みが案内されています。支出通知だけの場合は処理が続きます。強制上限を有効にした場合も反映は瞬時ではなく、記録される費用が設定額を少し超える可能性があります。上限で正規の処理も止まるため、業務影響と通知先をあわせて決めてください。

根拠：OpenAI｜Spend limits、OpenAI｜Managing projects in the API platform

他社の画面で「予算」「上限」と表示されていても、同じ動作とは限りません。公式の料金・制限の説明と、自分のアカウントで有効になっている設定の両方を確認します。モデル名、提供終了、機能、データ利用条件が変わったときも、料金ページや変更履歴を見て見直します。

使い方ごとに、見直す場所を決めます

• 個人利用：不要な個人情報を渡していないか、共有リンクや外部連携が残っていないかを確認します。履歴・ファイルの削除は、必要な記録を失わないよう対象と各サービスの削除条件を確認して行います。
• ブログ運営・個人開発：WordPress本文、カスタムHTML、公開JavaScript、配布ファイルへ秘密のキーを入れません。キーをサーバーへ置くだけで終わらず、公開したAPI呼出し機能に認証・利用制限が必要かも確認します。
• 業務利用：使えるサービスと情報、責任者、閲覧範囲、外部送信、承認、事故の報告先を決めます。操作ログにも秘密や個人情報を必要以上に残さず、閲覧権限と保存期間を設けます。

根拠：Google｜Using Gemini API keys、OWASP｜AI Agent Security Cheat Sheet

利用サービス／入口／プラン：
利用目的と責任者：
渡す情報と、送信が認められている根拠：
モデル学習・保存・削除の条件：
AIが読める対象：
AIが変更できる対象：
外部送信先と渡すデータ：
承認が必要な操作：
APIキーの保管先・用途・失効方法（値は記載しない）：
利用量の確認先・通知先・強制上限の有無：
ログの範囲・保存期間・相談先：
次に見直すきっかけ：

これは整理用の記入例です。埋めるだけで安全を保証するものではありません。実際の権限、設定、管理者の確認と組み合わせて使ってください。

06AIセキュリティのよくある質問