APIキーと.envをAIに読ませないルール｜Codex・Claude Code・MCP利用前の秘密情報チェック
APIキー、Cookie、トークン、秘密鍵、.envの実値をAIに見せない方法に加え、OpenAI APIキーの権限・有効期限・ローテーションも整理します。
公開 2026.06.30 / 更新 2026.09.25
この記事のポイント
- APIキーの実値をチャットやログに貼らない
- .envの中身を表示せず、変数名とダミー値で相談する
- OpenAI APIキーは用途・権限・有効期限を確認し、期限前に交換する
- push前にログ、HTML、コミット、スクリーンショットへの混入を確認する
知らないrepoと.env/APIキーは同じ環境に置かない
初見repoをAIに確認させるときは、普段の.env、GitHub token、npm token、cloud keyが見える環境で実行しない方が安全です。まず読み取りだけで危険箇所を確認し、必要なら使い捨て環境や低権限キーに分けます。
| 確認観点 | この記事で扱うこと | 詳しく読む |
|---|---|---|
| 初見repo | 実行前にREADME、scripts、workflowを見る | ai-coding-unknown-github-repo-safety-checklist |
| setup | install hookや外部取得を確認する | ai-agent-setup-command-safety |
| 外部指示 | READMEやissueにsecret送信命令がないか見る | indirect-prompt-injection-ai-coding-agent |
AI coding agent安全運用の補足FAQ
初見repoを試すとき.envを消せば十分ですか？
.envを見せないことは重要ですが、それだけでは足りません。shellにある環境変数、GitHub token、npm token、cloud認証、ブラウザsession、SSH keyも分けて確認します。
WebFetchやnetwork accessを切ればsecret流出は防げますか？
リスクは下がりますが完全ではありません。MCP、ログ、生成HTML、コミット、ブラウザsession、外部ツール連携にもsecretが混じらないか確認します。
OpenAI APIキーは用途・権限・有効期限を分ける
OpenAI API changelogでは、2026年9月10日にproject API keyの有効期限設定、9月15日に組織・project単位で新しいAPI keyの種類を制限する機能が案内されました。発行画面の選択肢はキーの種類やworkspaceの設定で変わるため、用途と実際の権限表示を照らして決めます。
| 確認すること | 選び方・操作 | 見落としやすい点 |
|---|---|---|
| 誰が使うか | 個人の検証は本人用のproject keyを使う。アプリやCIなど常時動く処理では、組織の方針に沿ってproject service accountを候補にする | API keyを同僚と共有しない。人のキーを本番アプリへ埋め込まない |
| 環境と権限 | 開発・staging・productionのprojectを分け、user-owned keyでは必要なAPIだけをRestrictedにする | user-owned keyのAll / Restricted / Read Onlyとservice accountの権限設定は同じ画面・仕組みとは限らない。service accountはproject roleが上限で、key scopeはさらに狭める設定 |
| 有効期限 | project keyに期限を設定し、期限前に交換日と担当を決める | 管理者は組織またはprojectの最長有効期間を設定できる。project側の上限は組織の上限を超えられない |
| 発行ポリシー | 管理者はservice-account keyのみ、user-owned project keyのみ、または新規key発行なしを選べる | 組織の制限はproject設定より優先される。この制御は新規発行に適用され、既存keyは自動で失効しない |
| 交換・漏えい対応 | 新しいkeyをsecret storeとアプリへ登録し、疎通を確認してから旧keyを取り消す。漏えいの疑いがあれば先に旧keyを失効させる | 使用量・費用をkey単位で確認し、想定外の利用がないか調べる |
AI coding agent安全運用の補足FAQ
発行ポリシーを変えると既存keyも失効しますか？
いいえ。OpenAIの案内では、新規key作成を制限する設定は既存keyに影響しません。古いkeyは利用先と権限を確認し、不要なら個別に取り消します。
期限前はどの順番で交換しますか？
代替keyを作成してsecret管理先とアプリを更新し、接続を確認してから旧keyを取り消します。漏えいが疑われる場合は、通常の移行を待たず対象keyを失効させます。
Work・plugins・Programmatic Tool Callingでもsecretをtool境界に出さない
Workのconnected appsやlocal files、Programmatic Tool CallingのMCP / shell対応は、secretを見せてよい理由にはなりません。toolごとのallowed caller、approval、data retention、log、third-party serviceを確認し、store: falseだけでZDRになると扱いません。
関連記事
- AI coding agentの間接プロンプトインジェクション対策｜README・issue・外部ドキュメントを信じすぎない
AI coding agentはREADMEやissueも文脈として読みます。そこに書かれた命令を上位指示として扱わないための実務ルールです。