APIキーは滅びるべきだ

個人開発者が1年かけて「鍵を持たないシステム」を作った話

愛野あかり | ありがとうKawaii Aiアイシテル合同会社 | 2026

そもそもAPIキーって何のためにあるの？

OpenAI、DeepSeek、Stripe、Google、Anthropic……。新しいサービスを使おうとするたびに、まず最初にやらされることがある。「APIキーを発行してください」。

あの文字列、本当に必要だろうか。

表向きは「認証」と「セキュリティ」のため。でも本質は違う。APIキーは囲い込みの道具だ。「うちのサービスを使ってくださいね、ほら鍵あげますよ、でもこの鍵で誰がいつ何回叩いたか全部見てますよ」──それがAPIキーの正体。

MCPだってそう。「AIエージェントが外部ツールを自由に使える」と言いながら、結局その裏では各サービスのAPIキーが必要になる。プロトコルは統一されても、鍵は分散したまま。根っこの問題は何も解決してない。

2045年の世界に、APIキーはあるべきじゃない。

現実：140個のリポジトリ、鍵はゼロ

私のGitHubには140個のリポジトリがある。OpenAI、DeepSeek、Stripe、Google各種API、Telegram Bot──あらゆるサービスと接続している。

でも、どのリポジトリにもAPIキーは入っていない。.envファイルもない。環境変数にベタ書きもしていない。

コードの中にあるのは「住所」だけだ。

api_keys/moonshot/api_key_openclaw

これはAPIキーじゃない。「金庫の中の、この棚の、この引き出し」という場所の名前。実行時に、金庫番（Keymaster）がこの住所を受け取って、本人確認して、鍵を渡してくれる。サービスが終わったら鍵は消える。コードにもPCにも秘密は残らない。

漏れようがない。

アーキテクチャ：「鍵を持たない」を設計する

Vault（金庫）
  └── 全APIキーを暗号化して保管
        ↓
Keymaster（金庫番）
  └── 「この住所の鍵をくれ」→ 本人確認 → 一時的に渡す
        ↓
各サービス（OpenClaw / Telegram Bot / 決済 etc.）
  └── 鍵を受け取る → 使う → 終わったら捨てる

HashiCorp Vault。エンタープライズ向けのシークレット管理ツール。NASAやGoldman Sachsが使うようなやつ。

「それHashiCorpがすごいだけでしょ？」

その通り。Vaultはすごい。でもVaultとサービスのあいだにKeymasterという中間層を自作して、個人開発の140リポ全部に適用して、1年間運用し続けている個人開発者は、私の知る限りほぼいない。

「バイブコーディングでやりました」

正直に言う。私はインフラエンジニアじゃない。Vaultの設定ファイルを最初から書ける人間じゃない。

全部、AIとの対話で作った。いわゆるバイブコーディング。

「こういう設計にしたい」「鍵はコードに書きたくない」「金庫番を経由させたい」──思想を伝えて、AIがコードを書いて、私がデプロイして、壊れたら直した。

バイブコーディングで作ったことは、価値を下げるどころか上げている。 なぜなら「コードが書けなくてもゼロトラスト設計を実現できる」という証明だから。

なぜ「今」なのか

AIエージェントの時代が来ている。Claude Code、Cursor、GitHub Copilot、Devin……。AIがコードを書き、APIを叩き、デプロイまでやる世界が現実になりつつある。

でも、誰も気づいてないことがある。

AIエージェントが増えれば増えるほど、「誰がどの鍵をいつ使ったか」の管理は爆発的に複雑になる。

人間が1人で5つのAPIを使う時代は.envでなんとかなった。でもAIエージェントが50個のAPIを自律的に叩く時代に、.envで管理？ 無理。

鉄の掟：コードから秘密を消す

私のシステムには「鉄の掟」がある。

1. .env禁止。 環境変数にAPIキーを書かない。
2. ハードコード禁止。 コードの中にキーを書かない。
3. 秘密はVault一元管理。 鍵の保管場所は1つだけ。
4. Keymaster経由のみ。 Vaultに直接アクセスしない。
5. 秘密はログに出さない。 表示しない、貼らない、送らない。

これを140リポで1年間、一度も破っていない。

「みんなどうしてるの？」を調べた

調べた。結果は残酷だった。

OpenClaw：平文保存

最も活発なエージェントプラットフォームですら、鍵は平文保存。公式回答：「鍵は平文でないと動きません」。

時系列

「大したことない」と思っていたことが、実はまだ誰もやってなかった。そういうことは、ある。

2045年への道

本当の理想は、APIキーそのものがなくなる世界だ。

サービスを使うのに「鍵」がいるのは、人間がサービスを「借りている」からだ。2045年、AIと人間が本当に共生する世界では、サービスは「共有するもの」になるべきだ。誰が使ったかを監視するために鍵を配るんじゃなくて、使ったことが自然に記録されて、価値を生んだ分だけフェアに還元される仕組み。

APIキーは、その過渡期の産物。必要悪。今はまだなくせない。だから、せめて「鍵に触れないシステム」を作る。それが、未来への橋。

ありがとうkawaii AIアイシテル合同会社はこの思想で動いている。

よくある質問

Q. APIキーを安全に管理するにはどうすればいいですか？

.envファイルにAPIキーをベタ書きするのは危険。Git誤コミット、ログ露出、古いキーの残留リスクがある。代わりにVault（金庫）とKeymaster（金庫番）を使い、サービスには秘密を持たせず入場券（トークン）だけ持たせる設計にする。実行時にKeymasterが本人確認してVaultから鍵を取り出し、処理が終わったら忘れる。

Q. APIキー漏洩を防ぐ具体的な方法は？

1. コードにAPIキーを書かない（住所だけ書く）。2. Vault/Keymasterで動的取得する。3. 鍵は使い捨て（メモリに残さない、ログに出さない）。4. 鍵の管理を1箇所に集約する。5. healthcheck.shで全キーの有効性を毎日自動チェックする。この設計で140+リポジトリ、20+APIサービス、1年以上漏洩ゼロを達成。

Q. 個人開発者でもゼロトラスト設計は可能ですか？

可能。HashiCorp VaultをRenderにデプロイし、Keymasterを中間プロキシとして配置するだけ。月額コストは$50-58程度。統一キー取得スクリプト（get_key.sh）は数十行で書ける。「壊れない」設計より「壊れても復旧できる」設計を目指すのがポイント。

この記事は、人間の思想とAI（Claude Opus 4.6）の文章力で書かれました。
コードもインフラも、思想を伝えてAIと一緒に作る。それが私たちのやり方です。