なぜ鍵を「作らない」のが一番安全なのか
プログラムからデータベースやクラウドを使うには API キーが要る — 長くそれが常識でした。けれど最近は、手元の作業ツールがブラウザのログインをそのまま使えます。鍵を 1 本も作らずに毎日の作業が回る仕組みを、動く図でたどりましょう。
鍵を発行しないログインの流れ
各ステップ・参加者・分岐をクリックすると、その仕組みの説明がここに表示されます。
この図をテキストで読む
シーケンス図「鍵を発行しないログインの流れ」。参加者3人、ステップ5個。 【参加者】（左から右） - あなた: ブラウザで本人確認 - 作業ツール: パソコン上の道具 - クラウドサービス: DB・クラウドの受付 【流れ】（上から下へ） ── ① 最初の 1 回だけ（ブラウザでログイン） ── 1. 作業ツール → あなた: ブラウザを開いて本人確認を依頼 2. あなた → クラウドサービス: ブラウザでログイン（二段階認証） 3. クラウドサービス → 作業ツール: 短命の通行証を発行（応答） ── ② 日々の作業（鍵は登場しない） ── 4. 作業ツール → クラウドサービス: 通行証を自動で提示して作業 5. クラウドサービス → 作業ツール: 有効性を確認して実行（応答）
もし API キーを配っていたら?
各ステップ・参加者・分岐をクリックすると、その仕組みの説明がここに表示されます。
発行した瞬間から、保管・配布・更新・失効の管理が一生続く
この図をテキストで読む
シーケンス図「API キーを配る運用」。参加者2人、ステップ3個。 【参加者】（左から右） - 発行する人: 鍵の一生を管理 - 各メンバーの PC: 鍵が居座る 【流れ】（上から下へ） 1. 発行する人（自身で処理）: 管理画面で API キーを発行 2. 発行する人 → 各メンバーの PC: 全員に配って設定ファイルに保管 3. 発行する人 → 各メンバーの PC: 更新のたびに全員へ配り直し
実際の運用から
- 1
実例: データベースの管理
当サイトのデータベース（Neon）は、管理コマンドがブラウザログインの認証をそのまま使えるようになり、API キーの発行手順ごと廃止できました。
- 2
実例: 権限は招待で渡す
クラウド（Google Cloud など）はお客様の組織に担当者のアカウントを招待してもらう形にします。鍵を渡さずに権限を渡せて、取り消しも組織側の操作ひとつです。
無人の自動処理だけは例外
テストや公開を自動で行う仕組み（CI）には、ブラウザを開く人がいません。ここは鍵なし連携（OIDC）を最優先し、やむを得ず鍵を使う場合も、範囲を最小に絞って金庫に預け、個人ではなく組織に紐づけます。
押さえておきたい用語
- ブラウザ認証（OAuth）
- API キー
- 短命トークン
- 招待（メンバーシップ）
- 鍵なし連携（OIDC / WIF）