APIキー運用
完全ガイド

原則1: チャット欄に貼らない

API キーをチャット欄に貼った瞬間、そのキーは「LLM プロバイダの入力ログ」に乗る。OpenAI・Anthropic・Google いずれも、商用プランでは原則として入力データをモデル学習に使わないと明言しているが、運用ログ・安全分類・障害調査のために一定期間保持される。つまり、キーを誰かの画面に表示した瞬間に、第三者のサーバー上に痕跡が残る可能性を受け入れたことになる。さらに社内 Slack や Notion に貼られれば、Workspace admin の検索範囲に入り、退職者の履歴からも引ける。経営者が自分で試す場合こそ、この習慣は例外を作らない。Claude Code で「.env を作って」と頼むときも、値そのものはターミナルで echo せず、エディタで直接記入する。「キーの文字列を肉眼で見ない、画面に出さない、LLM に渡さない」 — この三重の禁則が最初のゲートである。国内実例として、2024 年に某スタートアップの役員がデモ中にチャット欄へキーを貼り、直後に異国からの高レート呼び出しで数十万円の請求が発生した事案が Twitter で観測されている。

原則2: .env ファイル経由

業界標準として、API キーはソースコードに書かず、環境変数または .env ファイルに分離する。Python・Node.js・Go のいずれの主要フレームワークも、dotenv 系ライブラリ経由で起動時に読み込む前提でできている。ファイルはプロジェクトルート直下に置き、アプリは起動時に process.env.OPENAI_API_KEY のような形で参照する。これによりコード本体にキーが登場しなくなり、同僚にリポジトリを共有しても、チャットログを貼っても、キーが漏れない。ai-executive でも同様で、4 本のキー(OPENAI_API_KEY / OPENAI_API_KEY_CEO / OPENAI_API_KEY_CFO / OPENAI_API_KEY_CTO) は .env に記述する。ワークショップでは、Claude Code に「.env を作って、キーは後で私が手で入れる」と頼むことで、値を LLM に渡さずにテンプレートだけ生成させる。典型的な .env は下記のとおり。

# .env  (git 管理外)
OPENAI_API_KEY=sk-proj-xxxxxxxxxxxxxxxxxxxx
OPENAI_API_KEY_CEO=sk-proj-yyyyyyyyyyyyyyyy
OPENAI_API_KEY_CFO=sk-proj-zzzzzzzzzzzzzzzz
OPENAI_API_KEY_CTO=sk-proj-wwwwwwwwwwwwwwww

対になる .env.example はキー名だけを列挙し、値は空欄。こちらはコミット可。新メンバーが「何を埋めれば動くか」を一目で把握できる。

原則3: .gitignore 確認必須

.env を分離しても、それが .gitignore に登録されていなければ意味がない。git add で誤ってコミットされ、push した瞬間に、GitHub Secret Scanning がキーを検出して自動的にプロバイダへ通報し、キーは失効 — というのが幸運なケースで、悪運な場合は攻撃者のスキャナーが先にキーを拾う。リポジトリを public に切り替えた瞬間、過去コミット全てが露出することも忘れてはならない。必須の確認は 3 ステップ。(1) .gitignore に .env が含まれているか、(2) git status で .env が untracked に表示されるか、(3) 既にコミット済みの場合は git rm --cached .env で追跡解除。GitHub Secret Scanning は public repo に対して無償で動作し、OpenAI / Anthropic / AWS / Stripe など主要プロバイダのキー形式を自動検出する。Push protection を有効化すれば、コミット時点でキー含むコミットをブロックできる。

# .gitignore (最低限)
.env
.env.local
.env.*.local
*.pem
secrets/

実例として、2024 年に国内某アプリ企業が OpenAI キーをコミットし、GitHub Secret Scanning が自動検知、OpenAI 側で即座に失効されたが、その間の約 20 分間に攻撃者が別キーで試行する予兆ログが残ったという事例がある。検知体制は整っているが、絶対ではない。

原則4: 定期ローテーション

キーは作った瞬間から「いずれ漏れる前提」で扱う。推奨頻度は 90 日ごと、加えて漏洩検知・退職者発生・委託先変更のタイミングで即時ローテーション。急な入れ替えでサービス停止を起こさないために、段階的ローテーション手順を運用 SOP に明文化する。手順は 5 ステップ: (1) 新キー生成 → Secrets Manager に保存、(2) アプリの環境変数を新キーで更新し、カナリアトラフィックで動作確認、(3) 7 日間並行運用(旧キーも有効)、(4) 旧キー無効化、(5) 月次レビュー時に廃止確認とログ突合。クラウド Secret Manager を使っていれば、バージョニング機能で新旧キーの切り替えがフラグ一つで行える。ローテーションが「手順化されていれば、現場は怖がらなくなる」— これは工事現場の安全 KY と同じで、経営者が年間スケジュールに組み込むだけで規律が持続する。役員承認で見る KPI は 2 つ: 過去 12 ヶ月のローテーション完遂率(目標 100%) と 最長キー寿命(目標 90 日以内)。

原則5: 最小権限

一つのキーで複数の用途を兼ねないこと。ai-executive のように「4 エージェント=4 キー」が理想で、1 エージェントが乗っ取られても他が無事、という Blast Radius(被害半径)の最小化を狙う。OpenAI では Organization 内で「Project」単位の API キーが作れ、Project ごとにモデル制限・月次上限・IP 制限・許可エンドポイントを細かく設定できる。Anthropic Console でも Workspace 単位で支出上限と権限境界を引ける。AWS IAM と同じ思想で、キーごとに「できること」を狭める。本番キーに管理者権限、開発キーに読み取り権限、CI/CD キーに特定モデルのみ呼び出し可、という設計が筋。さらに 未使用キーは即廃止、使っていないキーは「将来何かに使うかも」で残さない(忘れた頃に漏れる)。Anthropic / OpenAI いずれも、キー毎の最終利用日時をダッシュボードで確認できる。30 日間未使用 = 廃止候補、を運用ルール化する。

原則6: 本番/開発キー分離

本番キーと開発キーを絶対に混ぜない。これは「銀行の金庫と財布を分ける」のと同じ話で、間違って開発コードが本番キーを掴むと、壁打ちで十数万トークンを溶かすケースが発生する。命名規則で視覚的に分離するのが最も確実で、推奨テンプレは {env}-{service}-{role}-{YYYYMMDD}。例として prod-oai-ceo-20260421 / dev-oai-ceo-20260421 / workshop-20260421-demo 等。プレフィックスだけで本番か開発か見分けがつく。加えて、環境変数名も PROD_OPENAI_API_KEY と DEV_OPENAI_API_KEY のように分離し、アプリ側は環境フラグで読み分ける。ワークショップや一過性のデモには、その日のための使い捨てキーを前日に作り、終了後 24h 以内に revoke する運用が理想。本日のワークショップで配布するキーもこの方式で、終了と同時に無効化される。こうしたフローが定着すると、「いま手元にあるキーは本番か、デモか、個人の開発用か」を迷うことがなくなる。