AI・自動化のAPIキー管理：用途別の権限と失効手順
この記事の内容
APIキーは、自動処理がサービスを利用するための秘密情報です。人が画面へログインするパスワードと同様に保管が必要ですが、停止する対象や影響は異なります。キーを一つ消すだけで、複数の自動処理が同時に止まることもあります。
少人数のチームでは、事業主個人のキーを全員へ渡す方法から始めがちです。最初から用途と担当を分け、何に使い、どこで保管し、いつ失効させるかを記録すると、担当交代時の手戻りを抑えられます。
人のログインと自動処理の権限を分ける
APIキーで実行できる操作は、発行先の権限や設定に依存します。読むだけの処理に編集権限まで必要か、テスト処理に本番の顧客データを見せる必要があるかを、用途から確認します。
OpenAIの公式ガイドでは、個人のAPIキーの共有を避け、メンバーを適切に招待して権限を設定するよう案内しています。機械処理ではサービスアカウント等、提供される仕組みを用途に合わせて使います。OpenAIのAPIキー安全管理
| 情報 | 主な用途 | 管理で見ること |
|---|---|---|
| ログインパスワード | 人の画面操作 | 本人・認証・復旧 |
| APIキー | 自動処理からの利用 | 用途・権限・失効 |
| OAuthの接続 | アプリへのアクセス許可 | 接続先・許可範囲・解除 |
| Webhook URL | 外部からの受付等 | 公開範囲・認証・再発行 |
名前が違っても秘密に相当するものはあります。WebhookのURLを一般の資料へ載せる前に、そのURLだけで何ができるかを確認してください。
テストと本番を分け影響範囲を小さくする
テスト用と本番用のキーや接続を分けると、試験で本番データを変更する可能性を減らせます。プロジェクトや利用上限も分けられる場合は、必要な範囲で設定します。
架空の問い合わせ分類なら、テストは架空メールを保存した専用フォルダ、本番は会社の対象メールだけを読む構成にします。どちらも同じ管理者の全メールを読める接続では、フォルダを分けただけで権限が限定されたとは言えません。
接続名には「会社名・用途・環境」を入れます。例えば「自社_問い合わせ分類_テスト」と「自社_問い合わせ分類_本番」を区別すれば、設定画面で取り違えを発見しやすくなります。秘密そのものを名前に含める必要はありません。
自動化ツールでは接続を使える人を確認する
APIキーの文字列が見えなくても、保存された接続を使って処理を作れる人には、実質的な操作権限があります。保管画面のマスク表示だけで共有範囲を判断しないでください。
Makeの公式ヘルプでは、チーム内のユーザーが、そのチームで作成した接続を使用・管理できることが案内されています。個人アカウントの接続を、他の人も使うチームへ置く場合は注意が必要です。Makeの接続管理
契約プランでチームや権限を分けられるか、接続の利用先を確認できるかを調べます。外注先へ自動化の編集を依頼する際は、キーをチャットに貼る前に、サービスが用意する認証の委任や接続設定の方法を確認します。招待した相手がどの操作まで実行できるかを、仕事の範囲に合わせて決めます。
画面・コード・ログへ秘密を残さない
キーは、公開するコード、ブラウザへ配信するJavaScript、スマホアプリの中など、利用者が取り出せる場所へ埋め込まないようにします。OpenAIも、クライアント側への配置やリポジトリへの保存を避けるよう案内しています。OpenAIの保管場所に関する指針
ノーコードの自動化でも、説明用のスクリーンショット、実行ログ、CSV書出し、サポートへの添付に秘密が混ざる場合があります。問い合わせにはキー全文を貼らず、接続名、時刻、エラーの種類など、調査に必要な情報を使います。
環境変数や専用の秘密管理機能を使う場合も、値をログへ出力しないことを確認します。設定できたかを見るために、秘密そのものを画面へ表示する必要はありません。台帳には発行先、用途、担当、保管場所、更新日を記録し、キー本体は分離します。
漏えい時は処理停止とキー失効を分けて進める
漏えいが疑われる場合は、対象のキーと影響する処理を特定し、公式手順で失効や更新を行います。自動化を停止しても、外部へ渡ったキーが有効なら、別の場所から利用される可能性は残ります。
使用量と課金の異常も確認します。OpenAIの現行案内では、支出アラートだけではAPI通信は止まらず、強制上限の設定にも即時性の限界があると説明されています。通知を設定したから費用が必ず上限内に収まる、と考えないでください。
記録には、発見時刻、対象キーの識別情報、停止・失効した操作、確認した使用量を残します。キーの全文は記録しません。顧客データへの影響がある場合は、社内担当や契約先の窓口へ事実を伝えて対応を確認します。原因を直さず新しいキーだけを同じ公開場所へ置くことは避けます。
更新は接続先を洗い出してから小さく確認する
通常の更新では、新しいキーを用意し、対象の接続を変更し、限定した処理で動作を確認してから、古いキーを失効させる順序を検討します。漏えい時は停止を優先する必要があるため、通常の更新と同じ手順とは限りません。
架空の更新例なら、問い合わせ分類、週報作成、テスト用の三つが同じ接続を使っていないかを先に確認します。一つの画面で更新できても、別に保存した古いキーが残る場合があります。実行履歴と接続一覧から利用先を整理してください。
定期更新や期限の設定ができるサービスでは、更新担当と予告日を決めます。担当者の退職や外注終了時は、メンバー権限とキーの両方を点検します。外注先との共有設計やAI APIの費用計算と合わせ、利用できる人と発生する費用を追える状態にしておきましょう。