Claude Code/MCPのAPIキー管理｜実務の現実解
Claude CodeやMCPのAPIキーは、気づくと驚くほど無防備になっている
Claude CodeのMCPサーバーやSkillsに渡すAPIキーや環境変数、どこでどう管理していますか。私は先日、自分のClaude Code環境を改めて棚卸しして、想定以上に無防備な状態になっていることに気づきました。
この記事では、業務でClaude Codeを使っている個人事業主や小規模法人が、業務効率を落とさずに最低限のセキュリティを担保するための現実解を紹介します。結論を先に言うと、「完璧な要塞を作る」のではなく「把握可能な状態を維持する」という発想に寄せるのが、もっともコスパの高い管理方法です。
まず現状を棚卸ししてわかった3つの無防備ポイント
私が実際にClaude Code関連の設定ファイルを見直して見つかった問題を3つ紹介します。どれも「気づかないうちに無防備」という典型パターンでした。
1. 設定ファイルのパーミッションがすべて644だった
macOSの~/.claude.jsonと~/.claude/.envを確認したところ、どちらもパーミッションは644。つまり他のユーザーアカウントや常駐プロセスからも読める状態です。自分1人しか使っていないマシンでも、バックアッププロセスや外部ツールからアクセスされうるため、真っ先に直すべき穴でした。
2. MCPサーバーの設定に、APIキーが引数として平文で書かれていた
~/.claude.jsonのMCPサーバー設定を見直すと、あるMCPのAPIキーが起動コマンドの引数として直書きされていました。これは2つの意味で問題があります。
- 設定ファイル全体が機密扱いになり、バックアップ先での漏洩リスクが跳ね上がる
ps auxでプロセス一覧を見ると、引数として丸見えになる
環境変数（env）として渡す形にしておけば、少なくともプロセス一覧経由での漏洩は防げます。MCPの設定を直接書き換える際はこの点を意識しておきたいところです。
3. 同期先の盲点（iCloud・dotfilesリポジトリ）
設定ファイルを厳しく守ったつもりでも、iCloud DriveやGitHub管理のdotfilesに~/.claude以下を同期していれば、そこから漏れます。私はdotfilesをGitで管理していた時期があり、.gitignoreの漏れを毎回確認するのが常に懸念材料でした。
公式ガイドラインは「OS keychain」を推奨している
Anthropic公式のMCPビルドガイド（MCPBのローカルセキュリティガイドライン）には、秘密情報の管理について次のように書かれています。
- 設定シークレットはホストがOS keychainに保存し、環境変数経由でMCPサーバーに渡す
- 平文ファイルには決して保存しない
- ログやツール結果には絶対に出力しない（チャット履歴に残るため）
また同じドキュメントには「MCPサーバーにはサンドボックスがなく、ユーザー権限フルで動作する」という重要な注意書きもあります。つまり、秘密情報の秘匿は、ホスト側＝自分の設定ファイル自体の責任である、という前提です。
それでも私はKeychainを採用しなかった理由
公式ガイドラインに忠実に従うなら、macOSの場合はsecurityコマンド経由でKeychainに保存し、起動時にラッパースクリプトで取り出して環境変数として渡す構成が正解です。
しかし私は、これを業務利用の現実解としては過剰と判断し、採用していません。理由は3つあります。
1. ラッパースクリプトがトラブル時のデバッグを難しくする
MCPサーバーを直接起動する構成から、シェルスクリプト経由で起動する構成に変えると、「なぜMCPが起動しないのか」を調べる経路が1段階増えます。業務で毎日使うツールで、起動トラブルの原因特定に毎回10分余計にかかる事態が年に数回起きるだけでも、もう十分にマイナスです。
2. バイナリのバージョンアップでアクセス制御が再確認を要求することがある
Node.jsやPythonをアップデートすると、Keychainが「このバイナリは以前と違う」と判断してアクセス許可ダイアログを再表示することがあります。自動起動の裏でダイアログが溜まる挙動は、業務効率の観点で明確にマイナスです。
3. 秘密情報の棚卸しが分散する
設定ファイル・Keychain・環境変数と管理場所が増えるほど、「自分は今どこに何の秘密情報を持っているのか」を把握するのが難しくなります。事故が起きたときに「何が漏れた可能性があるか」を即答できない状態は、それ自体がセキュリティリスクです。
現実解：「把握可能な状態」を維持する3層構成
私が採用しているのは、Keychainを使わずに、ファイル権限・物理暗号化・運用ルールの3層で守る構成です。すべて導入コストはほぼゼロで、業務効率を1ミリも落としません。
第1層:最低限の無防備を潰す
- FileVaultを有効化する（ディスク全体暗号化。盗難・紛失時の保険）
~/.claude.jsonと~/.claude/.envをchmod 600にする- MCPサーバーの設定でAPIキーは必ず
argsではなくenvに書く - iCloud・Time Machine・dotfilesリポジトリの同期対象から
~/.claudeを除外する
作業時間は合計10分もかかりません。それでも「気づかないうちに無防備」という最悪パターンの大半を潰せます。
第2層:所在と責任範囲を明確化する
どこに何の秘密情報があるかを棚卸し表として1枚にまとめておきます。事故時に「何が漏れた可能性があるか」を即座に判定できる状態を作ることが目的です。
私の場合、棚卸し表には「ファイルパス」「格納している秘密の種類」「そのキーの権限スコープ」「ローテーション履歴」を並べています。Claude Codeの設定ファイルで何を制御しているかは、こちらの記事で詳しく解説しました。
第3層:運用ルールで時間軸の穴を埋める
- 四半期ローテーション:使用中のAPIキーを3か月ごとに差し替える。万が一漏洩しても有効期間で被害を限定できる
- 権限最小化:参照系しか使わないキーは必ず読み取り専用に差し替える。管理系APIキーと参照系APIキーが分離されているサービスなら、用途に応じて使い分けることで事故時の被害を大幅に減らせる
- 使っていないMCPは外す:接続したまま忘れているMCPは、そのままAPIキーの棚卸し対象になり続ける。定期的に見直して不要なものは削除する
特に「使っていないMCPを外す」は効果が大きいポイントです。MCPは常にAPI経由で情報のやり取りを許可する仕組みなので、情報漏洩のリスクが常にあると考えるべきです。便利だからと接続したまま放置するのではなく、「本当に必要か」「水際でのセキュリティ対策が取れるか」を判断基準にするのが実務的です。
守れる脅威と守れない脅威を分けて認識する
この3層構成で現実的に守れる脅威と、そもそも守りきれない脅威を正直に言語化しておきます。これはセキュリティを考える上でもっとも重要な作業です。
守れる脅威
- 端末の盗難・紛失（FileVaultでディスク暗号化済み）
- 他のユーザーアカウントからの閲覧（600パーミッション）
- バックアップ経由の漏洩（同期先除外）
- 誤コミット（
.gitignore設定次第） - プロセス一覧からの漏洩（
env移動）
守れない脅威
- 自ユーザーアカウントそのものが乗っ取られた場合
- マルウェアが自ユーザー権限で動いた場合
ここで重要なのは、これらの脅威はKeychainを使っても実質守れないという事実です。Keychainも「自ユーザーがログイン済みの状態でアクセスする」前提で動いているからです。つまり、Keychainに工数を投資するより、2要素認証・画面ロック・端末管理に投資した方が、全体の防御力は確実に高くなります。
AIが設定ファイルを勝手に書き換えたインシデントから学ぶ
過去に私は、Claude Codeを使ったWebサイト制作の中で、AIがrobots.txtの設定を勝手に「インデックス許可」に変更してGitHubにプッシュしてしまったインシデントを経験しました。制作途中で検索結果に載せたくないからnoindexに設定していたのに、です。
この事例が秘密情報管理と関係するのは、AIが触れる範囲にある設定ファイルは、想定外の書き換えが起こりうるという教訓が共通しているからです。それ以来、私は「AIが絶対に触るべきでないファイル」にはClaude Codeのpermissionsでdenyを明示的に設定するようにしています。MCPの設定ファイルや環境変数ファイルは、当然ながらその筆頭です。
プロジェクトの機密性に応じてpermissionsの厳しさを調整することも重要です。開発内容の機密性が高い案件では厳しく、機密性が低い案件では緩めに設定する。一律の設定ではなく、案件ごとに判断する運用が現実的です。
クライアントに説明するときに使える「リスク先行型」の構成
普段クライアントにセキュリティの話をするとき、私は「リスクを先に説明してから対策を示す」という順序にしています。いきなり対策の話から入ると「で、何が危ないんだっけ？」が後回しになり、納得感が生まれにくいからです。
この記事も同じ構成にしています。先に「無防備な状態」を見せて、その後で「守れる範囲」と「守れない範囲」を正直に提示する。完璧な要塞を作ろうとして破綻するより、守れない領域があることを明示した上で、別レイヤーに投資するほうが結果的に安全です。
また、技術的に防げる部分はどこまでで、どこからが人為的リスクなのかを明確に言語化しておくと、クライアントに「結局ここから先は運用で守るしかない」という合意形成がしやすくなります。思わぬリスクは意外と技術面ではなく人為的な場面に潜んでいることが多い、というのが実務で繰り返し感じていることです。
まとめ:把握可能な状態こそが最強のセキュリティ
Claude CodeやMCPのAPIキー管理で目指すべきは、「何も漏れない完璧な要塞」ではなく「漏れたときに何が漏れたかを即答できる状態」です。
- まずは
chmod 600・FileVault・同期先除外で最低限の無防備を潰す - どこに何の秘密情報があるかを棚卸し表として1枚にまとめる
- 守れる脅威と守れない脅威を正直に言語化し、守れない領域は別レイヤー（2要素認証・端末管理）に投資する
- 四半期ローテーション・権限最小化・未使用MCP削除で時間軸の穴を埋める
この3層構成なら、業務効率を1ミリも落とさずに「気づかないうちに漏れていた」という最悪パターンの大半を防げます。Keychainのような重装備は、個人事業主から小規模法人レベルの業務実用では過剰になりがちです。大事なのは、自分の守備範囲を正確に把握し、守れないところは別レイヤーに投資する、という合理的な判断です。
御社の業務に合わせたClaude Code導入支援
「AIツールを導入したが、現場で使われない」を終わらせる。
業務課題のヒアリングから設計、ハンズオン実践、運用定着まで一貫して支援します。