想定読者
AIツールの連携や自作の社内アプリを使い始めたものの、APIキーやトークンが社内のどこにあるのか把握できていない中小企業の経営者・情報システム担当者・兼任のIT担当者の方です。
置き場所や扱いのルールを、これから決めたい方に向けています。
要点
- APIキー・トークンは「機械が使う合鍵」です。まず自社にどんな鍵が、誰の名義で、どこにあるかを一覧にすることが管理の出発点になります。
- 置き場所と、チャット・コード・画像に貼らない決まりを先に決めておくと、うっかり漏えいを防げます。
- 担当者の交代時と漏えいが疑われたときは、「誰が・何を・いつ」までに行うかを表で決めておけば、無効化と再発行を落ち着いて進められます。
見えない鍵が増えている背景
AIツールや社内アプリを使い始めると、社内の「鍵」が静かに増えていきます。ここでいう鍵とは、人が画面に入力するパスワードではなく、プログラムやツール同士がやり取りするときに使う文字列のことです。
APIキーとトークンとは何か
APIキーは、機械が使う合鍵のようなものです。たとえばAIサービスを自社のアプリから呼び出すとき、アプリは「私は正規の利用者です」と示すためにこの文字列を毎回添えます。
トークンも同じ仲間で、「一定期間だけ有効な入館証」にたとえると分かりやすいでしょう。
パスワードとの違いは、使う主体です。パスワードは人が覚えて入力しますが、APIキーやトークンは機械が自動で使います。
そのため、次のような特徴があります。
- 人が毎回入力しないので、どこかのファイルや設定に書き込まれて残りやすい
- 二段階認証のような「本人かどうかの追加確認」が効かないことが多く、文字列を知っていれば誰でも使える
- 誰が使ったかが見えにくい
つまり「持っている人は、持ち主として扱われる」鍵です。落とした合鍵を拾った人が、そのまま玄関を開けられるのと同じ状態になります。
本記事では、機械が使う鍵に絞って扱います。
鍵が増える場面

鍵が増える代表的な場面は、次の三つです。
- AIツールの連携:AIサービスを業務ツールやチャットと連携させるとき
- 自作の社内アプリ:業務を効率化するために社内で作ったアプリが、外部サービスやAIを呼び出すとき
- 外部サービスとの接続:会計、顧客管理、メール配信などのサービスを相互につなぐとき
当社(QuadCom)でも社内アプリを自作して運用しており、外部サービスとつなぐ仕組みが増えるほど、鍵の把握が欠かせなくなると感じています。
便利な連携を一つ足すたびに、鍵も一つ増えるわけです。
漏えいすると何が起きるか
鍵が外部に漏れると、持ち主になりすまして使われるおそれがあります。想定される被害は主に二つです。
- 不正利用による高額請求:従量課金のサービスでは、第三者に大量に使われると、思わぬ金額の請求につながる可能性があります。
- データ流出:顧客管理や会計などのサービスにつながる鍵だと、保存されている情報を読み出されるおそれがあります。
しかも、鍵はソースコードや設定ファイルに書かれたまま、公開の場所に置かれてしまう失敗がよく知られています。
「見えない鍵」は、見えないまま増え、見えないまま漏れます。だからこそ、最初に「見える化」から始めます。
自社の鍵を一覧にする
管理の出発点は、自社にどんな鍵があるかを一覧にすることです。把握していない鍵は、守ることも、止めることもできません。
一覧に書く項目
表計算ソフトなどで、1つの鍵につき1行で、次の項目を記録します。
- 名前:「請求書アプリ用AIキー」のように、何の鍵か一目で分かる呼び名
- 用途:どのアプリやツールが、何のために使っているか
- 発行元:どのサービスで発行したか
- 名義:誰のアカウントで発行したか(個人名義か、会社共通のアカウントか)
- 保管場所:実際の文字列がどこに保存されているか
- 有効期限:期限があるものは、その日付
- 権限の範囲:読み取りだけか、書き込みや削除もできるか
注意したいのは、一覧には鍵の文字列そのものを書かないことです。一覧は「鍵の台帳」であり、鍵の実物ではありません。
見本として示すときも、`sk-xxxx` のようなダミー値にとどめます。一覧が漏れても、鍵そのものは漏れない状態にしておくためです。
洗い出しのやり方

一覧づくりでは、次の場所を順に確認すると見つけやすくなります。
- 外部サービスの管理画面:各サービスの管理画面で、発行済みの鍵やトークンの一覧を確認します。画面の名称や場所はサービスごとに異なるため、各サービスの管理画面で確認してください。
- 自作アプリの設定:アプリが読み込んでいる設定ファイルや環境変数を確認します。
- 担当者への聞き取り:「自分が発行した鍵はありますか」と、AIツールを使っている人や開発に関わった人に声をかけます。
発行元の管理画面に載っていて、一覧に載っていない鍵があれば、それが「見えない鍵」です。名義が退職者のものや、用途が分からないものが見つかることも珍しくありません。
置き場所のルール
鍵を一覧にしたら、次は「どこに置いてよいか」を決めます。ルールの基本は、実物を置く場所を少数に絞ることです。
置いてよい場所/置いてはいけない場所
| 場所 | 置いてよいか | 理由の要約 |
|---|---|---|
| パスワード管理ツール | 置いてよい | 暗号化と共有範囲の指定ができる |
| 環境変数 | 置いてよい | コードと鍵を分けて持てる |
| 共有シート | 置いてはいけない | 閲覧者が増え、履歴にも残る |
| メール | 置いてはいけない | 転送や長期保存で広がる |
| ソースコード | 置いてはいけない | 共有や公開で一緒に流出する |
表の下で補足します。
パスワード管理ツールは、人が共有する鍵の保管に向いています。
ただし、ここでも「誰が見られるか」を絞ることが大切です。環境変数は、アプリの外側に鍵を置いて、動くときだけ読み込む仕組みです。
コード本体に鍵を書かずに済むため、コードを共有しても鍵は一緒に渡りません。
なお、サーバーを提供するサービスには、鍵を安全に預かる専用の仕組みが用意されていることもあります。
使えるかどうかは各サービスの管理画面や資料で確認してください。
共有シートやメールは「手軽だから」と使われがちですが、閲覧できる人が増え、削除したつもりでも履歴や転送先に残ります。
ソースコードに直接書く方法は、コードを共有した時点で鍵も一緒に渡ってしまうため、最も避けたい置き方です。
見落としやすい場所と権限の絞り方

置き場所のルールを決めても、実際には次のような場所に鍵が残っていることがあります。
- 個人のメモアプリやデスクトップのテキストファイル
- 過去のチャットのやり取り(「とりあえずここに貼ります」と送ったもの)
- 以前に作った試作アプリのフォルダ
- 共有ドライブに保存された手順書やスクリーンショット
一覧づくりの際に、これらも探してみてください。見つけたら、正式な保管場所へ移したうえで、元の場所の記載を消します。
チャットなど消せない場所に出てしまっていた鍵は、後述のとおり無効化して作り直すのが安全です。
もう一つの対策が、権限を絞ることです。
- 用途ごとに鍵を分ける:1本の鍵を複数のアプリで使い回さず、アプリごとに別の鍵を発行します。1本が漏れても、被害と止める範囲を限定できます。
- 必要な権限だけにする:読み取りだけで足りる用途なら、書き込みや削除ができない鍵にします。
- 名義を会社として管理できる形にする:個人名義だけで発行すると、その人が退職したときに管理が難しくなります。
サービスによって権限の細かさは異なるため、設定できる範囲は各サービスの管理画面で確認してください。
チャット・コード・AIに貼らないルール
置き場所を決めても、人が別の場所へ貼ってしまえば意味がありません。そこで「貼らない決まり」を、具体的な場面で示します。
貼らないルールの具体例

| 場面 | 貼らない決まり | 代わりにやること |
|---|---|---|
| チャット | 鍵の文字列を送らない | 保管場所の名前だけ伝える |
| メール | 本文・添付に書かない | 管理ツールで共有する |
| 画面共有 | 鍵が映る画面を開かない | 設定画面は閉じておく |
| スクリーンショット | 鍵が写った画像を残さない | 撮る前に隠す |
| AIへの質問 | 実際の鍵を入力しない | ダミー値に置き換える |
特に意識したいのが、AIへの質問です。エラーの原因をAIに尋ねるとき、設定ファイルをそのまま貼りつけると、中の鍵まで一緒に送ってしまいます。
質問する前に、鍵の部分を `sk-xxxx` のようなダミー値に置き換える習慣をつけましょう。
入力した内容がどう扱われるかはサービスごとに異なるため、そもそも実物を入れない運用が確実です。
画面共有やスクリーンショットも同様です。オンライン会議で設定画面を映した瞬間に、鍵が参加者全員に見えてしまうことがあります。
録画が残る場合は、後から何度でも見返されます。共有する前に、鍵が表示されている画面を閉じる、あるいは表示を隠す習慣をつけてください。
公開リポジトリへの誤登録を防ぐ
プログラムの管理に使う仕組み(リポジトリ)に、鍵を含む設定ファイルをうっかり登録してしまう事故は、典型的な漏えい経路です。
特に公開の設定になっていると、誰でも見られます。次の点を決めておきましょう。
- 除外設定を最初に入れる:鍵を書く設定ファイルは、登録の対象から外す設定を、開発を始める最初の段階で入れておきます。
- 鍵はコードの外に置く:前述のとおり、環境変数などで外から渡す形にします。
- 公開範囲を確認する:リポジトリが公開か非公開かを、作成時とメンバー追加時に確認します。
AI開発ツールを使ってアプリを作る場合も注意が必要です。AIが提案したコードに、鍵を直接書く形の例が含まれていることがあります。
そのまま使わず、「鍵は環境変数から読み込む形にして」と指示するか、出てきたコードを確認してから登録してください。
AIに作業を任せる場合も、鍵の実物を渡さず、置き場所だけを伝える運用が安全です。
誰が・何を・いつの運用表
ルールは、決めただけでは続きません。誰が担当し、どのくらいの頻度で何を行うかを、表にして共有します。
運用の役割分担表
| 作業 | 担当者 | 頻度 |
|---|---|---|
| 鍵の発行 | 利用部門の担当者 | 必要なとき |
| 一覧への記録 | 情報システム担当 | 発行時すぐ |
| 保管場所の点検 | 情報システム担当 | 半年に1回 |
| 一覧と実態の突き合わせ | 情報システム担当 | 年1回 |
| 不要な鍵の無効化 | 情報システム担当 | 見つけたとき |
| 点検結果の確認 | 経営者 | 年1回 |
表の下で、運用のポイントを補足します。
小さな会社では、担当者を一人が兼ねることも多いでしょう。その場合も、「発行する人」と「確認する人」は別にすると、見落としが減ります。
難しければ、経営者が年1回、一覧を見て「この鍵は何か」と問う場を設けるだけでも効果があります。
定期的に鍵を更新するかどうかは、リスクと手間のバランスで決めます。有効期限があるトークンは期限前に更新し、期限のない鍵は「年1回の点検時に、使っているか・権限は適切かを確認する」と決めておくと続けやすくなります。
更新の頻度は、鍵が守っている情報の重要度に応じて、重要なものほど短くします。
担当者の交代・退職時の手順

担当者の交代は、鍵の事故が起きやすい場面です。名義が個人になっている鍵や、本人しか保管場所を知らない鍵が残るからです。
人のアカウント権限は別の機会に扱います。ここでは機械が使う鍵に絞ります。
| 手順 | 担当者 | 時期 |
|---|---|---|
| 担当鍵の一覧を出す | 退職・異動する本人 | 交代の決定直後 |
| 引き継ぎ先を決める | 情報システム担当 | 最終出社の前 |
| 新しい鍵の発行と切り替え | 引き継ぎ先の担当者 | 最終出社の前 |
| 旧い鍵の無効化 | 情報システム担当 | 切り替え確認後すぐ |
| 一覧の名義を更新 | 情報システム担当 | 無効化と同日 |
ポイントは、「引き継ぐ」より「作り直す」を基本にすることです。本人が知っている鍵をそのまま使い続けると、その人が持ち出している可能性を否定できません。
新しい鍵に切り替えてから、旧い鍵を無効化します。
ただし、切り替え前に無効化すると業務が止まるため、動作確認が済んでから止める順番を守ります。
漏えいが疑われたときの無効化と再発行
どれだけ備えても、鍵が漏れた可能性が出ることはあります。そのとき大切なのは、原因の調査よりも先に鍵を止めることです。
最初の30分でやること
鍵がチャットに貼られていた、公開の場所に置かれていたなど、漏えいが疑われたら、次の順で進めます。
- 鍵を無効化する:各サービスの管理画面で、該当する鍵を無効にします。画面の操作はサービスごとに異なるため、各サービスの管理画面で確認してください。「漏れたか確定していない」段階でも、まず止めます。止めて困ることは、後で作り直せば解消できるからです。
- 新しい鍵を再発行する:用途と権限を一覧で確認し、必要最小限の権限で新しい鍵を発行します。
- 切り替えと動作確認:アプリやツールの設定を新しい鍵に差し替え、正常に動くことを確認します。
- 一覧を更新する:旧い鍵を無効化済みとして記録し、新しい鍵を登録します。
利用履歴の確認と報告の判断
鍵を止めて再発行したら、次に「その間に不正に使われなかったか」を確認します。
- 利用履歴の確認:多くのサービスには、鍵の利用状況や請求の履歴を見られる画面があります。身に覚えのない時間帯や量の利用がないかを確認します。確認できる範囲はサービスによって異なります。
- 影響範囲の整理:その鍵でどんなデータに触れられたかを、一覧の「権限の範囲」から判断します。
- 報告の判断:個人情報などが流出した可能性がある場合は、社内の責任者への報告と、取引先や関係機関への連絡が必要かを検討します。判断に迷うときは、専門家や関係機関への相談も視野に入れてください。
あわせて、同じ手順を日ごろから練習しておくと、いざというとき落ち着いて動けます。机上で流れを確かめておくだけでも、初動の迷いは大きく減ります。
年末前の点検チェックリストとまとめ

年末は、担当者の入れ替わりや休暇前の整理が重なる時期です。休みに入る前に、一度、自社の鍵を点検しておきましょう。
年末前に自社の鍵を点検するチェックリスト
- [ ] 自社で使っているAPIキー・トークンを、名前・用途・発行元・名義・保管場所・有効期限・権限の範囲つきで一覧にできる
- [ ] 一覧の内容と、各サービスの管理画面で見える鍵が一致していることを確認した
- [ ] すべての鍵の実物が、決めた置き場所だけにあることを確認した
- [ ] 個人のメモや過去のチャットに、鍵が残っていないことを確認した
- [ ] 用途ごとに鍵が分かれ、必要な権限だけになっていることを確認した
- [ ] 退職者や異動者の名義になっている鍵がないことを確認した
- [ ] 使っていない鍵を無効化した
- [ ] 公開リポジトリに鍵が登録されていないことを確認した
- [ ] 漏えいが疑われたときの最初の手順と連絡先を、担当者全員が説明できる
小さく始める優先順位
全部を一度にやろうとすると、手が止まってしまいます。次の順番で、小さく始めてください。
- まず一覧をつくる:完璧でなくてかまいません。分かる範囲の鍵を書き出します。
- 次に実物の置き場所を一つにそろえる:パスワード管理ツールなど、置いてよい場所へ集めます。
- 貼らない決まりを共有する:チャットとAIへの質問時のルールから周知します。
- 最後に運用表を決める:誰が・何を・いつ行うかを決め、年1回の点検につなげます。
APIキーやトークンは、普段は意識しなくても動くぶん、管理の抜けに気づきにくい存在です。まず「どこに、どんな鍵があるか」を見える状態にすることが、最大の予防策になります。
今年のうちに一覧を一度つくっておけば、来年以降の点検は格段に楽になります。
























