AIのAPIキーを共有資料に貼らない。保管・担当・失効を決める

動くことを確かめる前に、そのキーで何ができ、誰が止められるかを確認する。

APIキーを、接続先へ渡す秘密として扱う

APIキーは、プログラムからサービスを利用する際の認証などに使われる情報です。具体的に何ができるかは製品と権限の設定によります。GitHubの公式資料も、APIキーなどをソースへ直接書き込むと、不正利用の対象になることを説明しています。SONAEは、AI連携を始めるとき、キーの発行元、用途、利用する処理、管理担当を整理する方法を提案します。名前や説明を記録する台帳と、秘密の値を保管する場所は分けましょう。

開発・検証と、業務の利用を分ける

架空データを使った検証に、本番で広い範囲を操作できるキーを渡す必要があるかを確認します。可能なら環境や用途ごとに分け、必要な権限や利用条件を設定できるかを公式資料で調べます。すべてのサービスで同じ細かさの制限ができるとは限りません。制限できないものは、その条件を記録し、別の連携方法も検討します。個人が発行したキーに業務が依存する場合は、異動や退職の影響も確認してください。

ソース以外の配布先にも目を向ける

コードに書かなくても、手順書、チャット、画面の写真、エラーの記録、AIへの質問へ値を貼ると複製が増えます。設定の説明には架空の表示や参照名を使い、本物の値を資料へ含めない方法を決めます。秘密を管理する仕組みを使う場合も、利用できる人と処理、取り出した後の扱い、復旧する方法を確認します。ツールへ移したことだけで管理が完了したとせず、実際に利用する経路を把握することが必要です。

漏れた疑いがあれば、削除だけで終えない

GitHubは、漏えいの通知を受けた認証情報の更新・失効を優先するよう説明しています。共有した文章を消すことと、キーの利用を止めることは別です。社内の対応責任者へ連絡し、発行元の公式手順に沿って判断します。利用している処理への影響、代替の準備、利用記録の確認を管理担当と進めます。この記事から実キーを発行・更新・失効したり、外部の有効性確認を行ったりすることはありません。

引継ぎには、値ではなく管理の関係を書く

架空の連携処理Aなら、発行元、検証用であること、使う処理、管理担当、承認した保管先、利用を終える条件を台帳にします。後任へ秘密をメールで転送するのではなく、正式な利用者の追加と引継ぎを計画します。期限がある場合は期限、ない場合も見直す時期を記録します。誰も使っていないキーを発見したときは、依存する処理がないか確かめ、管理者の判断で整理する手順を用意してください。

一件のキーで、停止までの机上確認をする

「検証を終了する」「担当者が交代する」「資料に値を貼った疑いがある」の三場面で、誰が何を確認するかをたどります。秘密を実際に作らず、架空の管理番号で練習できます。完了の目安は、用途と担当が明確で、保管、利用、終了、事故時の連絡を説明できることです。見つかった秘密を無断で外部サービスへ送って有効性を調べることは、この点検の範囲に含めません。

相談前の確認表

• 用途と環境を分けて把握した
• 秘密の値を資料やAIへ貼らない
• 保管と利用できる人を決めた
• 終了・漏えい時の担当と手順を用意した

参考資料（確認日：2026年10月23日）：GitHub Docs：Secret scanning ↗

一般的な説明とSONAEの運用提案です。製品の公式条件と自社の管理責任者の判断を確認してください。