APIキーの直書きは何が危ないのか—動くから気づけない。確認手順と見つけたときの対応

AIに「このAPIを使ってツールを作って」と頼むと、動かすためにキーが必要になる。手っ取り早く動かしたいので、いったんコードに直接書く。動いた。そのまま使い始める。——非エンジニアが作ったツールで最も多いのがこのパターンで、しかもこの状態は、何年放置しても不具合として表面化しない。この記事では、何が危ないのか、どこを見れば分かるのか、見つけたら何から手を付けるのかを順に整理する。

APIキーは「パスワード」だと思っていい

技術的な説明を抜きにすると、APIキーはそのサービスにおいて自分になりすませる合鍵だ。持っている人は、自分と同じ操作ができる。

何ができてしまうかは、キーの種類で変わる。

• 生成AIサービスのキー：他人があなたの契約で使い放題になる。気づくのは請求が跳ね上がったとき
• クラウドストレージのキー：保存しているファイルを取り出される
• データベースのキー：顧客情報を丸ごと読み出される。書き換えや削除ができるキーなら、消される
• メール配信サービスのキー：自社のドメインを名乗って第三者がメールを送れる

いずれも「パスワードが漏れた」のと同じ扱いをする必要がある。そして重要なのは、漏れていてもツールは正常に動き続けることだ。異常が出ないので、社内の誰も気づけない。

なぜ直書きが残ってしまうのか

これは注意力の問題ではなく、作り方の順序による。

1. まず動かしたいので、キーをコードに直接書く
2. 動いた。うれしい。次の機能に進む
3. 「あとで環境変数に移す」と思っている
4. 移す前に完成して、使い始める

AIに「環境変数から読む設計にして」と最初から指示していても、この落とし穴は残る。動作確認のために一時的に直接書いた値が、そのまま残っているケースが非常に多い。指示したかどうかではなく、実際のファイルを見ないと分からない。

キーが残っている場所は5つある

コードを開いて検索するだけでは足りない。実際に確認する場所はこれだけある。

特に3番目は非エンジニアにはほぼ知られていない。Gitはファイルの変更履歴をすべて保存する仕組みなので、後からファイルを書き換えても、古いバージョンを見れば元の値が読める。「消したから大丈夫」が通用しない。

確認手順（技術がなくてもできる範囲）

1. 使っている外部サービスを全部書き出す。生成AI、クラウド、メール配信、決済、地図など。それぞれキーが必要だったはずなので、キーの本数が分かる
2. 各サービスの管理画面で、発行済みキーの一覧を見る。身に覚えのないキーがないか、いつ発行したものかを確認する。ここは管理画面を開くだけなので誰でもできる
3. 作った人に「このキーはどこに書いてありますか」と聞く。即答できれば場所は把握できている。「たしか環境変数にした気が」なら、実際に開いて確認する
4. Gitを使っているか聞く。使っているなら、履歴にキーが含まれていないかの確認が別途必要になる。ここは技術者の領域
5. 利用量とアクセス記録を見る。多くのサービスは管理画面で使用量が見られる。想定より多い、深夜に使われている、といった兆候があれば漏洩を疑う

見つかったときの対応は、順序を間違えない

直書きが見つかると、まずコードを直したくなる。それは順序が逆だ。

コードから消すだけでは、すでに漏れている可能性のあるキーが有効なまま残る。無効化して初めてリスクが止まる。多少ツールが止まってもいいので、失効を先にやる。

次に同じことを起こさないために

• キーは用途ごとに分けて発行する。1本を使い回さない。漏れたときに影響範囲を切り分けられる
• 権限は必要最小限にする。読み取りだけで足りるなら、書き込み・削除ができるキーを使わない
• AIにコードを貼るときは、キーをダミーに置き換えてから貼る。ルールとして決めておく
• 半年に一度、キーを棚卸しする。使っていないキーを消すだけでもリスクは減る

まとめ

APIキーの直書きは、技術的には初歩的な問題だが、症状が出ないという一点で厄介になる。動いているから誰も見に行かず、見に行かないから見つからない。確認は管理画面を開くところから始められるので、まず発行済みキーの一覧を見るところから手を付けるといい。