AIエージェントに渡す『鍵』をどう守るか——VibeCoding内製化のシークレット管理・APIキー管理

「gitignoreしているから大丈夫」で終わらなかった話

ある内製化担当者から、こんな相談を受けたことがあります。Claude Codeに外部APIを叩かせるツールを作り、APIキーは.envファイルに書いて.gitignoreに登録していました。ルール通りの対応に見えます。ですが、開発を急ぐ中で一度だけ、動作確認用に.env.exampleではなく.envをそのままコピーしてリポジトリに含めてしまった瞬間がありました。プッシュ履歴を遡らないと気づけない、ほんの一手間のミスです。

GitGuardianが発表した2026年版のレポートによれば、2025年だけで公開GitHub上に露出した新規シークレットは約2,900万件にのぼり、前年比34%増という過去最大の伸びを記録しています。つまり、これだけAPIキーの取り扱いが注目されるようになった今でも、事故の件数そのものは減るどころか加速しているということです。私たちの現場経験では、この種の事故は「不注意な担当者」に起きるのではなく、「急いでいるときの誰にでも」起きます。gitignoreは有効な対策ですが、それだけで守り切れると考えるのは楽観的すぎると私たちは考えています。

正直に言えば、私たち自身もこの種のヒヤリとする瞬間と無縁ではありません。VibeCoding内製化のスピードは、じっくり確認する時間との引き換えに成り立っている部分があります。だからこそ、「気をつける」という精神論ではなく、うっかり事故が起きても被害を限定できる仕組みを、最初から組み込んでおく必要があると私たちは考えています。

APIキーを「コードに書く」という発想そのものを疑う

多くの担当者が最初に学ぶのは、「APIキーをソースコードに直接書かず、環境変数に逃がす」という作法です。これは正しい第一歩ですが、最終形ではありません。.envファイルは結局、ディスク上に平文で存在するファイルです。Claude CodeのようなAIエージェントがプロジェクトフォルダ全体を読み書きできる状態であれば、.envもまた「読めるファイルの1つ」に過ぎません。

以前お伝えしたpermissions(denyルール)の話を思い出してください。denyルールで.envへのアクセスを塞いでいたとしても、そのAPIキーを使った処理の結果——たとえばエラーメッセージやログ——にキーの断片が紛れ込み、AIとのやり取りの中に残ってしまうことがあります。ある海外のセキュリティ専門メディアは、AIエージェントに渡す認証情報の管理について「答えは"APIキー衛生の改善"ではなく、"認証情報そのものをなくすこと"だ」と踏み込んだ主張をしています。私たちはここまで急進的にする必要はないと考えていますが、「キーをどこかに書いて渡す」という発想自体を一度疑ってみる価値はあります。

誤解のないように言えば、環境変数への切り出し自体を否定しているわけではありません。ソースコードへの直書きよりは、はるかにましな状態です。ただし、「.envに書いたから終わり」で思考を止めてしまうと、そのファイルが結局どこからでも読める平文のテキストファイルであるという事実を見落とします。ファイルの中身を暗号化する、アクセス権限をOSレベルで絞る、といった一段階先の工夫を組み合わせて、初めて「envに逃がした」ことの意味が出てきます。

「渡さない」設計——Vaultとランタイム注入という考え方

理想は、AIエージェントにもコードにもAPIキーの値そのものを見せないことです。具体的には、AWS Secrets ManagerやHashiCorp Vaultのような専用のシークレット管理サービスに鍵を預け、実行時にだけ必要な鍵を取得する設計です。コードには「どのサービスの鍵が必要か」という指示だけを書き、値そのものはVaultサービスとの通信の中でその場限り取得します。

私たちがMCPの信頼境界についてお伝えした際、MCPサーバー経由の連携が複数サービスの認証情報を集約する構造になりやすいと指摘しました。この構造を逆手に取り、MCPサーバー自体をVaultへの「取次役」として設計する方法もあります。AIエージェントはMCPサーバーに「このツールを使いたい」とだけ伝え、実際の認証情報のやり取りはMCPサーバーとVaultの間で完結させる。エージェント自身は鍵の値を一度も目にしません。

正直に言えば、この設計をVibeCoding内製化の初期段階からフルで組むのは、非エンジニアの担当者にはハードルが高い作業です。ですが、発想としては覚えておく価値があります。「鍵をどこに書くか」ではなく「鍵をエージェントに見せずに済ませられないか」を、まず考えてみることです。

鍵を「長生きさせない」——短命トークンという発想

APIキーのもう1つの弱点は、多くが「一度発行したら、明示的に無効化するまでずっと使える」長命な鍵だという点です。長命な鍵は、一度漏れると被害が発覚するまでの間ずっと悪用され続けるリスクを抱えます。

企業向けの認証基盤を扱うある記事では、AIエージェント向けの認証設計として、有効期限を15分程度に絞った短命トークンを軸に据える設計パターンが紹介されています(詳細は参考リンクをご覧ください)。トークンが漏れても、悪用できる時間そのものが極めて短いという発想です。SPIFFE/SPIREのような仕組みでこれを本格的に実装するのは大企業のインフラチーム向けの話ですが、「鍵は長生きさせるほど危険が積み上がる」という原則自体は、規模を問わず当てはまります。

私たちの現場経験では、VibeCoding内製化の担当者が発行するAPIキーの多くは、有効期限の設定すら意識されていません。まず着手できるのは、使っているサービスの管理画面でキーの有効期限やローテーション設定を確認することです。設定できるなら、90日など無理のない範囲で区切っておくだけでも、漏洩時の被害を頭打ちにできます。

鍵を「使い回さない」——1つの侵害を全体に広げない設計

MCPの信頼境界についてお伝えした際、1つのトークンを複数サービスにまたいで使い回す「token passthrough」の危険性を指摘しました。これはMCP経由の連携に限った話ではありません。開発環境と本番環境で同じAPIキーを使う、複数のツールに同じ管理者キーを配る、といった「使い回し」は、私たちが内製化の現場で最も頻繁に見かける設計の甘さです。

考え方はシンプルです。1つの鍵が破られたときに、影響が及ぶ範囲をあらかじめ最小化しておく。開発用・本番用でキーを分ける、ツールごとに必要最小限の権限を持つ専用キーを発行する、この2点だけでも、事故が起きたときの被害範囲は大きく変わります。私たちの現場経験では、「面倒だから」という理由で1つの管理者キーを使い回している案件ほど、後になって「どこまで影響があったか分からない」という調査コストの高さに苦しんでいます。鍵を分けるコストは、事故が起きてから調査するコストに比べれば、ずっと小さいというのが私たちの実感です。

鍵1本に「何でもできる力」を持たせない——権限の絞り込み

もう1つ見落とされがちなのが、APIキー自体が持つ権限の広さです。多くのサービスは、発行の手間を惜しんで「管理者権限を持つキーを1本だけ発行し、あらゆる用途で使い回す」ことを許してしまいます。以前お伝えした「confused deputy(混乱した代理人)」の構造と同じで、AIエージェントが本来必要とする範囲を大きく超えた権限を、鍵という形でうっかり渡してしまうのです。

考え方は単純です。「請求書を読み取るだけのツール」には読み取り専用のキーを、「Slackに通知を送るだけのツール」には投稿権限だけのキーを発行する。管理画面でスコープ(権限範囲)を選べるサービスは年々増えています。私たちの現場経験では、この「スコープを選ぶ」というひと手間を惜しんで管理者キーを使い回している案件ほど、後になって「このAIエージェントは、本当はどこまで操作できる状態だったのか」を説明できなくなります。理想を言えば、必要になった瞬間にだけ短時間だけ権限を発行する「JIT(Just-In-Time)アクセス」という考え方まで踏み込めると、より安全になります。ですが、まずは「常時発行されている鍵の権限を、今の用途に対して絞り込む」ことから始めれば十分です。

鍵の使用履歴を残す——「誰が、いつ、どの鍵を使ったか」

権限を絞り、鍵を分けても、最後に頼りになるのは記録です。私たちがAI-Path自身のシステム(AIPLA)で徹底しているのは、機能単位でのアクセス権限の分離に加えて、操作の履歴を残し、必要であれば巻き戻せる状態を保つという発想です。APIキーについても同じ発想が当てはまります。どのキーが、いつ、どのサービスに対して使われたかというログを残しておけば、万が一の漏洩時に「どこまで影響が及んだか」を後から特定できます。

これは大掛かりな監査基盤を組む話ではありません。多くのクラウドサービスやAPIプロバイダは、キーごとのアクセスログを標準機能として提供しています。私たちの現場経験では、この標準機能の存在自体を知らずに使っていない担当者が少なくありません。まずは、自社が使っている主要なサービスの管理画面に、キーの利用ログを確認できる項目がないかを探すことをお勧めします。ログが残っていれば、鍵が漏れたときに「気づくまでの時間」を大きく短縮できます。

私たちが自社で経験した、地味だが効いた移行

私たちAI-Path自身も、この課題と無縁ではありませんでした。社内システムを運用する中で、複数のサービスにまたがる約900件近いシークレットが、環境変数や設定ファイルに平文に近い形で分散している状態に気づいたことがあります。1件ずつ手作業で移行すれば数週間かかる規模でしたが、私たちはこれをVaultへの移行として扱い、移行処理そのものもシークレットの値を平文で展開せず、メモリ内で処理を完結させる形で実行しました。

この経験から私たちが得た実感は、「シークレット管理は、後から一気に直そうとすると規模の大きさに心が折れる」ということです。だからこそ、件数がまだ少ないVibeCoding内製化の初期段階のうちに、鍵の置き場所と棚卸しの習慣を作っておく方が、結果的にずっと楽になります。1件のAPIキーを発行する瞬間に「これはどこに書くか」を意識するだけで、半年後・1年後に抱える技術的負債の量が変わってきます。

私たちがAIエージェントに渡す認証情報を扱う際に徹底しているのは、「本番反映は二段階、環境は色で見分ける」という運用です。ステージング環境で動作確認が済んでから本番に反映する二段構えにし、さらに研修・検証用の環境は画面の配色を変えて、本番とひと目で区別できるようにしています。シークレット管理そのものを一足飛びに完璧にしようとするのではなく、「うっかり本番の鍵を検証環境で使ってしまう」といった、起きやすい小さな事故から順に潰していく発想です。

非エンジニアでも今日からできること

ここまでVaultサービスや短命トークンの話をしてきましたが、これらをすべて一度に整えるのは現実的ではありません。私たちが内製化担当者に最初にお願いしているのは、次の3つだけです。

まず、今使っているAPIキーを一覧化すること。どのサービスの、どんな権限を持つ鍵が、どこに書かれているか。この一覧が存在しない状態そのものが、実はリスクです。次に、開発用と本番用でキーを分けること。今日から新しく発行するキーだけでも、この原則を適用します。最後に、使っていないキーを無効化すること。退職者が発行したキー、検証用に作って放置されたキーは、私たちが棚卸しを手伝ったほぼすべての現場で見つかっています。

この3つに共通するのは、特別な技術知識を必要としないという点です。一覧化はスプレッドシート1枚で始められますし、開発用・本番用の分離は、サービスの管理画面から新しいキーを発行し直すだけで完了します。私たちの現場経験では、この地味な棚卸し作業を後回しにする理由の多くは「時間がない」ではなく「どこから手をつければいいか分からない」ことにあります。まずは1つのサービスから、この3つの手順を試してみることをお勧めします。

鍵が漏れたときの訓練——「本当にローテーションできるか」を試す

以前お伝えした「すり抜けテスト」の発想は、シークレット管理にもそのまま当てはまります。設定したはずのローテーション手順が、実際に緊急時に機能するかを、平常時に一度試しておくことです。

具体的には、あるサービスのAPIキーを1つ選び、実際に無効化して新しいキーに差し替える手順を、落ち着いているときにやってみます。どのシステムがそのキーを参照しているか把握できているか、差し替えの際にどのサービスが停止するか、想定していなかった依存関係が見つかることは珍しくありません。私たちの現場経験では、「鍵を漏らさないこと」ばかりに意識が向き、「漏れた後にどれだけ早く鍵を差し替えられるか」を訓練できていない案件がほとんどです。合格の基準は、慌てずに、影響範囲を把握した状態で差し替えが完了することです。

AI-Pathの見解——鍵の設計は、後回しにするほど高くつく

一般的なSaaS利用であれば、認証情報の管理はベンダー側の管理画面に閉じています。ですが私たちが支援するVibeCoding内製化の現場では、AIエージェントに渡すAPIキーの発行から失効まで、自分たちで設計する必要があります。

これは地味で、後回しにされやすい作業です。ですが、機密情報の多層防御やMCPの信頼境界をどれだけ丁寧に設計しても、その土台にある鍵の管理が杜撰であれば、そこが最も破られやすい一点になります。私たちの現場経験では、キーの棚卸しと分離を最初の1週間で済ませた案件と、半年放置してから着手した案件とでは、後者の方が調査・移行のコストが何倍にも膨らみます。VibeCoding内製化を始めるタイミングこそ、鍵の管理ルールを最初に決めるべき瞬間だと私たちは考えています。

これは、経営層が最初に方針を決めるべき話でもあります。現場の担当者に「気をつけてください」と伝えるだけでは、忙しさの中でいつか同じ事故が起きます。どのサービスの鍵を、誰が、どう管理するのかというルールを、VibeCoding内製化のプロジェクトが立ち上がる最初の段階で決めておくこと。それが、後から高くつく手戻りを防ぐ、いちばん確実な投資だと私たちは考えています。

よくある質問

Q1. .envファイルにAPIキーを書くこと自体が間違っていますか。 間違いではありません。ソースコードへの直書きよりはるかに安全です。ただし、それだけで十分だと考えず、開発用・本番用の分離や有効期限の設定まで含めて設計することをお勧めします。

Q2. Vaultサービスの導入は、小規模な内製化チームにも必要ですか。 初期段階では必須ではありません。まずはAPIキーの一覧化と、開発用・本番用の分離から始めてください。扱うキーの数が増え、複数人でチームを組むようになった段階で、Vaultサービスの導入を検討するのが現実的です。

Q3. Claude CodeなどのAIエージェントに、APIキーを直接プロンプトで伝えても大丈夫ですか。 避けてください。プロンプトやチャットのやり取りはログとして残ることが多く、意図せず別の場所に転記・共有されるリスクがあります。環境変数やVaultサービス経由で、エージェントが値そのものを見ずに済む形を優先してください。

Q4. 退職者が発行したAPIキーが残っているかもしれません。何から確認すればよいですか。 まずは主要な外部サービス(クラウド、決済、AIモデルAPI等)の管理画面で、発行済みキーの一覧と最終利用日を確認してください。長期間利用されていないキーは、無効化しても業務に支障が出ないか関係者に確認したうえで削除することをお勧めします。

Q5. APIキーのローテーション頻度は、どのくらいが適切ですか。 サービスの重要度によりますが、90日を1つの目安にすることをお勧めしています。決済や本番データベースに関わる鍵はより短く、検証用の鍵はやや長くても構いません。大切なのは頻度そのものより、ローテーションの手順が実際に機能するかを事前に確認しておくことです。

Q6. すでに複数人でAPIキーを共有してしまっています。今から個別に分けるべきですか。 可能であれば分けることをお勧めします。共有キーは、誰がいつ何をしたかを後から特定できないという弱点を抱えます。人数が多く一度に切り替えるのが難しい場合は、まず新しく発行するツール・サービスから個別キーの運用に切り替え、既存の共有キーは順次置き換えていく進め方が現実的です。

まず試すなら

• 現在使っているAPIキー・認証情報を一覧化し、どこに書かれているかを洗い出すこと
• 開発用と本番用でAPIキーを分けること(今日新しく発行するキーからでも構いません)
• 使われていない、あるいは退職者が発行したキーを無効化すること
• 主要なサービスのAPIキーを1つ選び、実際にローテーション(無効化→差し替え)を試してみること

どれも、外部への発注や大きな予算を必要としない、社内だけで今日から始められることです。AI-Pathでは、無償の業務プロセス診断(BPR)を実施しています。自社のVibeCoding内製化におけるAPIキー・認証情報の管理に不安がある場合は、まずは棚卸しからご相談ください。

参考リンク

• 7 Best Secret Management Tools for AI Agents in 2026(GitGuardianの2025年シークレット流出統計を含む)
• AI Agent Security Best Practices for 2026 — 認証情報の"排除"という考え方
• AIエージェントの認証・アクセス制御｜OAuth・APIトークン管理の実践