APIキー・トークンの管理ルール|社内アプリとAIツールの秘密情報を守る置き場所・貼らない決まり・無効化と再発行の手順

想定読者

AIツールの連携や自作の社内アプリを使い始めたものの、APIキーやトークンが社内のどこにあるのか把握できていない中小企業の経営者・情報システム担当者・兼任のIT担当者の方です。

置き場所や扱いのルールを、これから決めたい方に向けています。

要点

  • APIキー・トークンは「機械が使う合鍵」です。まず自社にどんな鍵が、誰の名義で、どこにあるかを一覧にすることが管理の出発点になります。
  • 置き場所と、チャット・コード・画像に貼らない決まりを先に決めておくと、うっかり漏えいを防げます。
  • 担当者の交代時と漏えいが疑われたときは、「誰が・何を・いつ」までに行うかを表で決めておけば、無効化と再発行を落ち着いて進められます。

見えない鍵が増えている背景

AIツールや社内アプリを使い始めると、社内の「鍵」が静かに増えていきます。ここでいう鍵とは、人が画面に入力するパスワードではなく、プログラムやツール同士がやり取りするときに使う文字列のことです。

APIキーとトークンとは何か

APIキーは、機械が使う合鍵のようなものです。たとえばAIサービスを自社のアプリから呼び出すとき、アプリは「私は正規の利用者です」と示すためにこの文字列を毎回添えます。

トークンも同じ仲間で、「一定期間だけ有効な入館証」にたとえると分かりやすいでしょう。

パスワードとの違いは、使う主体です。パスワードは人が覚えて入力しますが、APIキーやトークンは機械が自動で使います。

そのため、次のような特徴があります。

  • 人が毎回入力しないので、どこかのファイルや設定に書き込まれて残りやすい
  • 二段階認証のような「本人かどうかの追加確認」が効かないことが多く、文字列を知っていれば誰でも使える
  • 誰が使ったかが見えにくい

つまり「持っている人は、持ち主として扱われる」鍵です。落とした合鍵を拾った人が、そのまま玄関を開けられるのと同じ状態になります。

本記事では、機械が使う鍵に絞って扱います。

鍵が増える場面

AIツールや社内アプリの連携で鍵が少しずつ増えていく様子を表した場面

鍵が増える代表的な場面は、次の三つです。

  • AIツールの連携:AIサービスを業務ツールやチャットと連携させるとき
  • 自作の社内アプリ:業務を効率化するために社内で作ったアプリが、外部サービスやAIを呼び出すとき
  • 外部サービスとの接続:会計、顧客管理、メール配信などのサービスを相互につなぐとき

当社(QuadCom)でも社内アプリを自作して運用しており、外部サービスとつなぐ仕組みが増えるほど、鍵の把握が欠かせなくなると感じています。

便利な連携を一つ足すたびに、鍵も一つ増えるわけです。

漏えいすると何が起きるか

鍵が外部に漏れると、持ち主になりすまして使われるおそれがあります。想定される被害は主に二つです。

  • 不正利用による高額請求:従量課金のサービスでは、第三者に大量に使われると、思わぬ金額の請求につながる可能性があります。
  • データ流出:顧客管理や会計などのサービスにつながる鍵だと、保存されている情報を読み出されるおそれがあります。

しかも、鍵はソースコードや設定ファイルに書かれたまま、公開の場所に置かれてしまう失敗がよく知られています。

「見えない鍵」は、見えないまま増え、見えないまま漏れます。だからこそ、最初に「見える化」から始めます。

自社の鍵を一覧にする

管理の出発点は、自社にどんな鍵があるかを一覧にすることです。把握していない鍵は、守ることも、止めることもできません。

一覧に書く項目

表計算ソフトなどで、1つの鍵につき1行で、次の項目を記録します。

  • 名前:「請求書アプリ用AIキー」のように、何の鍵か一目で分かる呼び名
  • 用途:どのアプリやツールが、何のために使っているか
  • 発行元:どのサービスで発行したか
  • 名義:誰のアカウントで発行したか(個人名義か、会社共通のアカウントか)
  • 保管場所:実際の文字列がどこに保存されているか
  • 有効期限:期限があるものは、その日付
  • 権限の範囲:読み取りだけか、書き込みや削除もできるか

注意したいのは、一覧には鍵の文字列そのものを書かないことです。一覧は「鍵の台帳」であり、鍵の実物ではありません。

見本として示すときも、`sk-xxxx` のようなダミー値にとどめます。一覧が漏れても、鍵そのものは漏れない状態にしておくためです。

洗い出しのやり方

鍵を探す3つの場所をまとめたチェックリスト図

一覧づくりでは、次の場所を順に確認すると見つけやすくなります。

  1. 外部サービスの管理画面:各サービスの管理画面で、発行済みの鍵やトークンの一覧を確認します。画面の名称や場所はサービスごとに異なるため、各サービスの管理画面で確認してください。
  2. 自作アプリの設定:アプリが読み込んでいる設定ファイルや環境変数を確認します。
  3. 担当者への聞き取り:「自分が発行した鍵はありますか」と、AIツールを使っている人や開発に関わった人に声をかけます。

発行元の管理画面に載っていて、一覧に載っていない鍵があれば、それが「見えない鍵」です。名義が退職者のものや、用途が分からないものが見つかることも珍しくありません。

置き場所のルール

鍵を一覧にしたら、次は「どこに置いてよいか」を決めます。ルールの基本は、実物を置く場所を少数に絞ることです。

置いてよい場所/置いてはいけない場所

場所置いてよいか理由の要約
パスワード管理ツール置いてよい暗号化と共有範囲の指定ができる
環境変数置いてよいコードと鍵を分けて持てる
共有シート置いてはいけない閲覧者が増え、履歴にも残る
メール置いてはいけない転送や長期保存で広がる
ソースコード置いてはいけない共有や公開で一緒に流出する

表の下で補足します。

パスワード管理ツールは、人が共有する鍵の保管に向いています。

ただし、ここでも「誰が見られるか」を絞ることが大切です。環境変数は、アプリの外側に鍵を置いて、動くときだけ読み込む仕組みです。

コード本体に鍵を書かずに済むため、コードを共有しても鍵は一緒に渡りません。

なお、サーバーを提供するサービスには、鍵を安全に預かる専用の仕組みが用意されていることもあります。

使えるかどうかは各サービスの管理画面や資料で確認してください。

共有シートやメールは「手軽だから」と使われがちですが、閲覧できる人が増え、削除したつもりでも履歴や転送先に残ります。

ソースコードに直接書く方法は、コードを共有した時点で鍵も一緒に渡ってしまうため、最も避けたい置き方です。

見落としやすい場所と権限の絞り方

権限を絞る3つの工夫を示す要点図

置き場所のルールを決めても、実際には次のような場所に鍵が残っていることがあります。

  • 個人のメモアプリやデスクトップのテキストファイル
  • 過去のチャットのやり取り(「とりあえずここに貼ります」と送ったもの)
  • 以前に作った試作アプリのフォルダ
  • 共有ドライブに保存された手順書やスクリーンショット

一覧づくりの際に、これらも探してみてください。見つけたら、正式な保管場所へ移したうえで、元の場所の記載を消します。

チャットなど消せない場所に出てしまっていた鍵は、後述のとおり無効化して作り直すのが安全です。

もう一つの対策が、権限を絞ることです。

  • 用途ごとに鍵を分ける:1本の鍵を複数のアプリで使い回さず、アプリごとに別の鍵を発行します。1本が漏れても、被害と止める範囲を限定できます。
  • 必要な権限だけにする:読み取りだけで足りる用途なら、書き込みや削除ができない鍵にします。
  • 名義を会社として管理できる形にする:個人名義だけで発行すると、その人が退職したときに管理が難しくなります。

サービスによって権限の細かさは異なるため、設定できる範囲は各サービスの管理画面で確認してください。

チャット・コード・AIに貼らないルール

置き場所を決めても、人が別の場所へ貼ってしまえば意味がありません。そこで「貼らない決まり」を、具体的な場面で示します。

貼らないルールの具体例

AIへの質問時の避けたい例と良い例を比べた図
場面貼らない決まり代わりにやること
チャット鍵の文字列を送らない保管場所の名前だけ伝える
メール本文・添付に書かない管理ツールで共有する
画面共有鍵が映る画面を開かない設定画面は閉じておく
スクリーンショット鍵が写った画像を残さない撮る前に隠す
AIへの質問実際の鍵を入力しないダミー値に置き換える

特に意識したいのが、AIへの質問です。エラーの原因をAIに尋ねるとき、設定ファイルをそのまま貼りつけると、中の鍵まで一緒に送ってしまいます。

質問する前に、鍵の部分を `sk-xxxx` のようなダミー値に置き換える習慣をつけましょう。

入力した内容がどう扱われるかはサービスごとに異なるため、そもそも実物を入れない運用が確実です。

画面共有やスクリーンショットも同様です。オンライン会議で設定画面を映した瞬間に、鍵が参加者全員に見えてしまうことがあります。

録画が残る場合は、後から何度でも見返されます。共有する前に、鍵が表示されている画面を閉じる、あるいは表示を隠す習慣をつけてください。

公開リポジトリへの誤登録を防ぐ

プログラムの管理に使う仕組み(リポジトリ)に、鍵を含む設定ファイルをうっかり登録してしまう事故は、典型的な漏えい経路です。

特に公開の設定になっていると、誰でも見られます。次の点を決めておきましょう。

  • 除外設定を最初に入れる:鍵を書く設定ファイルは、登録の対象から外す設定を、開発を始める最初の段階で入れておきます。
  • 鍵はコードの外に置く:前述のとおり、環境変数などで外から渡す形にします。
  • 公開範囲を確認する:リポジトリが公開か非公開かを、作成時とメンバー追加時に確認します。

AI開発ツールを使ってアプリを作る場合も注意が必要です。AIが提案したコードに、鍵を直接書く形の例が含まれていることがあります。

そのまま使わず、「鍵は環境変数から読み込む形にして」と指示するか、出てきたコードを確認してから登録してください。

AIに作業を任せる場合も、鍵の実物を渡さず、置き場所だけを伝える運用が安全です。

誰が・何を・いつの運用表

ルールは、決めただけでは続きません。誰が担当し、どのくらいの頻度で何を行うかを、表にして共有します。

運用の役割分担表

作業担当者頻度
鍵の発行利用部門の担当者必要なとき
一覧への記録情報システム担当発行時すぐ
保管場所の点検情報システム担当半年に1回
一覧と実態の突き合わせ情報システム担当年1回
不要な鍵の無効化情報システム担当見つけたとき
点検結果の確認経営者年1回

表の下で、運用のポイントを補足します。

小さな会社では、担当者を一人が兼ねることも多いでしょう。その場合も、「発行する人」と「確認する人」は別にすると、見落としが減ります。

難しければ、経営者が年1回、一覧を見て「この鍵は何か」と問う場を設けるだけでも効果があります。

定期的に鍵を更新するかどうかは、リスクと手間のバランスで決めます。有効期限があるトークンは期限前に更新し、期限のない鍵は「年1回の点検時に、使っているか・権限は適切かを確認する」と決めておくと続けやすくなります。

更新の頻度は、鍵が守っている情報の重要度に応じて、重要なものほど短くします。

担当者の交代・退職時の手順

退職する担当者が後任に鍵を引き継ぐ打ち合わせの場面

担当者の交代は、鍵の事故が起きやすい場面です。名義が個人になっている鍵や、本人しか保管場所を知らない鍵が残るからです。

人のアカウント権限は別の機会に扱います。ここでは機械が使う鍵に絞ります。

手順担当者時期
担当鍵の一覧を出す退職・異動する本人交代の決定直後
引き継ぎ先を決める情報システム担当最終出社の前
新しい鍵の発行と切り替え引き継ぎ先の担当者最終出社の前
旧い鍵の無効化情報システム担当切り替え確認後すぐ
一覧の名義を更新情報システム担当無効化と同日

ポイントは、「引き継ぐ」より「作り直す」を基本にすることです。本人が知っている鍵をそのまま使い続けると、その人が持ち出している可能性を否定できません。

新しい鍵に切り替えてから、旧い鍵を無効化します。

ただし、切り替え前に無効化すると業務が止まるため、動作確認が済んでから止める順番を守ります。

漏えいが疑われたときの無効化と再発行

どれだけ備えても、鍵が漏れた可能性が出ることはあります。そのとき大切なのは、原因の調査よりも先に鍵を止めることです。

最初の30分でやること

漏えいが疑われたときの初動4手順を示す流れ図

鍵がチャットに貼られていた、公開の場所に置かれていたなど、漏えいが疑われたら、次の順で進めます。

  1. 鍵を無効化する:各サービスの管理画面で、該当する鍵を無効にします。画面の操作はサービスごとに異なるため、各サービスの管理画面で確認してください。「漏れたか確定していない」段階でも、まず止めます。止めて困ることは、後で作り直せば解消できるからです。
  2. 新しい鍵を再発行する:用途と権限を一覧で確認し、必要最小限の権限で新しい鍵を発行します。
  3. 切り替えと動作確認:アプリやツールの設定を新しい鍵に差し替え、正常に動くことを確認します。
  4. 一覧を更新する:旧い鍵を無効化済みとして記録し、新しい鍵を登録します。

利用履歴の確認と報告の判断

鍵を止めて再発行したら、次に「その間に不正に使われなかったか」を確認します。

  • 利用履歴の確認:多くのサービスには、鍵の利用状況や請求の履歴を見られる画面があります。身に覚えのない時間帯や量の利用がないかを確認します。確認できる範囲はサービスによって異なります。
  • 影響範囲の整理:その鍵でどんなデータに触れられたかを、一覧の「権限の範囲」から判断します。
  • 報告の判断:個人情報などが流出した可能性がある場合は、社内の責任者への報告と、取引先や関係機関への連絡が必要かを検討します。判断に迷うときは、専門家や関係機関への相談も視野に入れてください。

あわせて、同じ手順を日ごろから練習しておくと、いざというとき落ち着いて動けます。机上で流れを確かめておくだけでも、初動の迷いは大きく減ります。

年末前の点検チェックリストとまとめ

年末前に担当者と経営者が鍵の一覧を一緒に点検している場面

年末は、担当者の入れ替わりや休暇前の整理が重なる時期です。休みに入る前に、一度、自社の鍵を点検しておきましょう。

年末前に自社の鍵を点検するチェックリスト

  • [ ] 自社で使っているAPIキー・トークンを、名前・用途・発行元・名義・保管場所・有効期限・権限の範囲つきで一覧にできる
  • [ ] 一覧の内容と、各サービスの管理画面で見える鍵が一致していることを確認した
  • [ ] すべての鍵の実物が、決めた置き場所だけにあることを確認した
  • [ ] 個人のメモや過去のチャットに、鍵が残っていないことを確認した
  • [ ] 用途ごとに鍵が分かれ、必要な権限だけになっていることを確認した
  • [ ] 退職者や異動者の名義になっている鍵がないことを確認した
  • [ ] 使っていない鍵を無効化した
  • [ ] 公開リポジトリに鍵が登録されていないことを確認した
  • [ ] 漏えいが疑われたときの最初の手順と連絡先を、担当者全員が説明できる

小さく始める優先順位

全部を一度にやろうとすると、手が止まってしまいます。次の順番で、小さく始めてください。

  1. まず一覧をつくる:完璧でなくてかまいません。分かる範囲の鍵を書き出します。
  2. 次に実物の置き場所を一つにそろえる:パスワード管理ツールなど、置いてよい場所へ集めます。
  3. 貼らない決まりを共有する:チャットとAIへの質問時のルールから周知します。
  4. 最後に運用表を決める:誰が・何を・いつ行うかを決め、年1回の点検につなげます。

APIキーやトークンは、普段は意識しなくても動くぶん、管理の抜けに気づきにくい存在です。まず「どこに、どんな鍵があるか」を見える状態にすることが、最大の予防策になります。

今年のうちに一覧を一度つくっておけば、来年以降の点検は格段に楽になります。

▼略歴

1970年 東京都世田谷区生まれ。
少年期を豊かな自然に囲まれた栃木県日光市で過ごす。
趣味は山歩きや渓流釣り、そして中学生の頃から始めたパソコンとBASICのプログラミングでした。
部活は陸上部に所属。短距離走や砲丸投げの選手で、度々表彰されていました。
高校からギター部に入ってギターを学び、作詞・作曲をするようになりました。上京後、路上ライブをしたりしていました。

高校・専門学校にて経営・財務の分野を学ぶ。
新卒で建設・不動産業界の経理部に就職し、次の業務を経験。

  • 住宅ローンアドバイザー

パソコン販売専門チェーンにて、次の業務を経験。

  • 複数店舗のマネージャー
  • PCソフトウェアのマーチャンダイザー

家電メーカーグループ企業にて、次の業務を経験。

  • 直営店舗の運営と商品のマーチャンダイザー
  • PCのBTOビジネスや家電ホームネットワークの普及推進
  • デジタル一眼の使い方セミナーの講師
  • WEBマスターとして、ポータルサイト、イントラサイト、楽天などのeコマースサイトの制作・運営
  • 情報セキュリティマネジメント(ISMS)とナレッジマネジメントの推進
  • 銀座のツーリスト向け店舗に勤務

家電量販店にて、次の業務を経験。

  • 六本木の店舗にて店長を経験
  • 店舗開発部での営業支援(新店舗出店時のレイアウト設計や出店準備、VMDの企画・制作など)

ホテル宴会場などの常駐イベント支援やAVシステム事業を行う業界中堅企業にて、インテグレーターとして次の業務を担当。

  • 手術室・血管造影室の画像・映像配信システムの開発・設計とエンジニアリング
  • 医療向けシステムやフェリーの設備を安全にリモートメンテナンスするソリューションの開発・運用
  • メディカル部門のマネージャーを経験

同企業にて、全社の事業推進プロジェクト部門に参画し、次の業務を経験。

  • 室長と共に、ゼロからデジタルマーケティングの仕組みを立ち上げ
  • 会社のリブランディングプロジェクト

SaaS開発・販売企業にて、次の業務を経験。

  • セールスエンジニア

アプリ開発の設計や仕組みを学びました。

  • 論文 医師偏在の課題と向き合う遠隔手術支援ソリューション(CiNiiで検索)
  • 論文 手術室の生産性向上に貢献する医療映像ソリューション(CiNiiで検索)
  • 現在、企業向けにIT技術者育成セミナー(ネットワーク/企業のAI導入等)を行っています。