「発行元にも渡すな」と書かれている鍵｜APIキーとパスワードの扱い方

業務でAIに何かを頼むとき、設定ファイルの中身をそのまま貼りたくなる場面があります。エラーの原因を調べてほしい、この設定で合っているか見てほしい。ところがその中に、外に出してはいけない文字列が混ざっていることがあります。

先に結論をお伝えします。この記事は「危ないから渡すな」という話ではありません。業務では認証情報を扱わざるを得ない場面があります。お伝えしたいのは、値そのものを見せずに渡す方法があることと、漏れたときに最初にやるべきことの順序です。

そもそもAPIキーとは何か

先に用語を片づけます。APIキーとは、プログラムからAIを呼び出すときに使う、長い文字列のことです。

普段チャット画面から使っている場合は、この鍵を直接目にすることはありません。目にするのは、社内の仕組みにAIを組み込むときです。たとえば、問い合わせメールの下書きを自動で作る、日報を要約して回覧する、といった仕組みを作った場面です。

ここで押さえておきたいのは、この鍵が「誰が使っているか」を示す唯一の手がかりだということです。人間のように顔や声で確認するわけではありません。正しい鍵を持っていれば、それが誰であっても本人として扱われます。

マンションのオートロックの暗証番号のようなものです。番号さえ合っていれば、住人かどうかは問われません。

もう1つ、業務上の性質があります。この呼び出しには費用がかかります。使った分だけ請求される仕組みなので、鍵を持っている人は、その会社の費用で使えることになります。

つまりAPIキーは、身分証と支払いカードを兼ねた1本の文字列です。この理解が、次章の「なぜそこまで強く書かれているのか」につながります。

鍵は、思いがけない場所から出ていく

公式が挙げているのは「公開の場・メール・サポートへの問い合わせ」ですが、実務ではもう少し身近な経路があります。

よくあるのは、設定ファイルを共有する場面です。「この設定で動いています」と、ファイルをそのまま同僚に送る。あるいは、外部の協力会社に環境を引き継ぐ。そのファイルに鍵が書かれていれば、一緒に渡っています。

次に多いのが、画面の共有と撮影です。打ち合わせで画面を映したとき、資料に貼ったスクリーンショットに、設定画面が写り込んでいる。文字が小さくても、拡大すれば読めます。

そして、この記事の主題であるAIへの相談です。動かないので原因を調べてほしい、と設定を丸ごと貼る。目的は正当ですが、渡している中身は同じです。

共通しているのは、どれも悪意のない、むしろ丁寧な仕事のつもりの行動だということです。だから注意喚起だけでは止まりません。次章以降で扱う「そもそも値を書かない渡し方」が要るのは、このためです。

公式が「自分たちにも渡すな」と書いている

APIキーの扱いについて、Anthropicの公式ヘルプに、印象的な一文があります。

公開の場での議論、メール、サポートチケットに鍵を含めないよう指示したうえで、こう続けています。

even between you and Anthropic.

「あなたと私たちの間であっても」。鍵を発行している当の会社が、自分たちとのやり取りにも含めるなと書いています。

サポートに問い合わせるとき、状況を正確に伝えるために設定をそのまま貼りたくなります。その相手が発行元であっても駄目だ、という水準です。

そして同じページは、扱いの基準をこう示しています。

Just as you wouldn’t share your personal password, don’t share your API key.

「自分の個人的なパスワードを共有しないのと同じように、APIキーを共有してはいけない」。

この言い方には意味があります。APIキーという言葉に馴染みがなくても、パスワードなら誰でも感覚を持っています。「他人に教えるものではない」という判断が、説明なしにできます。

なぜそこまで強く書かれているのか

理由は、鍵がアカウントそのものへのアクセスを意味するからです。

同じ公式ヘルプは、第三者のツールに鍵を渡す場合について説明しています。要旨は、鍵を渡すことは、そのツールの提供者に自分のアカウントへのアクセスを与えることになる、というものです。

ここが理解の分かれ目です。鍵は「使うための道具」ではなく、「本人であることの証明」です。持っている人が本人として扱われます。

たとえるなら、家の鍵を預けるのと同じです。「郵便物を取っておいて」と鍵を渡せば、その人は郵便物以外のものにも触れられます。渡した側が用途を限定しても、鍵そのものは全部開きます。

そしてもう1つ、業務上見落とせない点があります。API経由の利用には費用が発生します。鍵を持っている人は、その費用を使えます。情報が漏れるだけでなく、請求が発生しうるということです。

公式が支出の上限設定や利用状況の確認を勧めているのは、この点への備えです。鍵が漏れたときに、被害が青天井にならないようにするという発想になっています。

第三者のツールに登録するとき

実務でいちばん判断に迷うのが、この場面だと思います。便利なツールを見つけて、そこに自社の鍵を登録するケースです。

AIを使った業務ツールの多くは、利用者自身に鍵を用意させます。「お使いのAPIキーを入力してください」という画面です。これ自体は一般的な作りで、それだけで怪しいわけではありません。

ただし、公式ヘルプは、この行為の意味をはっきり書いています。要旨は、鍵を渡すことは、そのツールの提供者に自分のアカウントへのアクセスを与えることになる、というものです。

ツールの機能を借りているつもりが、こちらのアカウントを預けている。方向が逆だという理解が要ります。

合鍵を渡して庭の水やりを頼むようなものです。頼んだのは水やりだけでも、その鍵は家の中も開きます。相手を信用するかどうかの話であって、頼んだ内容の話ではありません。

では、どう判断すればよいのか。公式は、評判の確かな提供元に限ること、そして渡す場合も暗号化された秘密情報として登録することを勧めています。

実務向けに翻訳すると、判断の順序はこうなります。

3番目が最も効きます。そのツール専用の鍵を作っておけば、問題が起きたときにその鍵だけを消せば済みます。他の仕組みは動き続けます。

公式が「開発用・試験用・本番用で鍵を分ける」ことを勧めているのは、同じ発想です。分けておけば、切り離せます。

チャット欄に貼ると、何が起きるか

では、AIのチャット欄に鍵を貼ってしまった場合はどうなるのでしょうか。

ここで、入力した内容がどこに残るかという話が関わってきます。公式のプライバシーセンターによると、削除した会話は履歴から即座に消えたあと、社内の保管システムから30日以内に削除されます。

つまり、貼ってすぐ消しても、その瞬間に無かったことになるわけではありません。

さらに、訓練への利用を許可している設定であれば、公式は匿名化した形式で最大5年間、訓練の工程内に保持すると書いています。

ここから導かれる結論は単純です。鍵をチャット欄に貼るということは、すぐには取り消せない場所に鍵を置くことになります。

だから「貼ってしまったら消す」では間に合いません。正しい対処は、次章以降で扱う「そもそも貼らない渡し方」と、貼ってしまった場合の「鍵を無効にする」という操作です。

投函してしまった手紙のようなものです。ポストの前で気づいても、もう取り戻せません。できるのは、その手紙が届いても意味がない状態を作ることだけです。

入力した情報がどこにどれだけ残るかについては、その設定、本当に学習に使われていませんかで契約の種類別の確認手順を扱っています。

正しい渡し方は「値を見せない」

ここからが本題です。業務では、鍵を使わざるを得ません。禁止だけを並べても仕事が回らないので、公式が推奨している渡し方を見ます。

中心にあるのは環境変数という仕組みです。技術的な言葉ですが、考え方は難しくありません。

鍵の値そのものを書類に書くのではなく、「鍵はあの引き出しに入っている」という場所だけを書いておく。そして、実際に必要になったときに、その場所から取り出す。いわば、金庫の中身を手紙に書く代わりに、金庫の場所と開け方だけを伝えるようなものです。

公式が挙げている具体的な扱いを整理します。

2026年8月29日時点のAnthropic公式ヘルプの記載にもとづく

技術の担当でなくても決められるのは、最後の2つです。用途ごとに鍵を分けることと、定期的に入れ替えること。どちらも技術ではなく運用の話で、決めれば実行できます。

特に「分ける」は効きます。1本の鍵をすべてに使っていると、1回の漏洩で全部が影響を受けます。分けてあれば、影響は分けた範囲に留まります。

使われ方を見張る仕組み

ここまでは「渡し方」の話でした。公式はもう1つ、別の方向の備えを挙げています。使われ方を見ておくことです。

推奨されているのは3つです。

1つ目は、記録と利用状況を定期的に見ること。いつ、どれだけ使われたかを確認します。見慣れない時間帯や、急に増えた量が、最初の手がかりになります。

2つ目は、支出の上限を設定しておくこと。これは実務上、非常に効きます。鍵が漏れても、上限を超えれば止まります。被害額に天井を作っておく、という考え方です。

3つ目は、鍵が誤って外に出ていないかを自動で調べる仕組みを入れること。公式は、バージョン管理の提供元が用意している検出機能を有効にすることと、開発の流れの中で自動検査を組み込むことを勧めています。

日々の業務でAIを使っている立場に置き換えると、「うっかり鍵を書いたまま保存してしまったファイルがないか、機械に見張らせる」ということです。人間の注意力に頼らない仕組みを1つ入れておく、という発想になっています。

ここまでの3つのうち、最初にやるべきは2つ目の支出上限です。設定は一度で済み、効果がはっきりしています。火災保険をかけるようなもので、起きないに越したことはありませんが、起きたときの額が変わります。

ベンダーや外部のサービスを選ぶときに、こうした管理機能があるかを見る観点は、生成AIセキュリティ比較で扱っています。

漏れたときに最初に押すボタン

ここが、この記事で最も実用的な部分です。公式が、画面の操作まで書いています。

鍵がさらされた可能性がある場合、公式はまずその鍵を無効にするよう求めています。手順はこうです。

2026年8月29日時点のAnthropic公式ヘルプの記載にもとづく

順序が重要です。新しい鍵を先に作ってから古いものを消したくなりますが、公式は「ただちに無効化する」ことを先に置いています。

理由は明快です。無効にすれば、その鍵は誰が持っていても使えなくなります。一方、新しい鍵を作る作業をしている間も、古い鍵は生きたままです。

火災報知器を鳴らす前に避難経路を確認するようなものです。順序が逆になると、その間の被害が止まりません。

無効化が終わってから、新しい鍵を発行し、利用状況のログを見て想定外の使われ方がなかったかを確認します。この3つの順序（止める → 作り直す → 確かめる）を、事前に決めておくと迷いません。

ここで注意していただきたい点があります。AIとの会話を削除しても、鍵が無効になるわけではありません。削除は表示を消す操作で、鍵そのものは有効なままです。消すべきは会話ではなく、鍵のほうです。

そしてもう1つ。「漏れたかどうか分からない」ときは、漏れた側で扱うのが安全です。鍵の入れ替えは数分で終わり、失うものがほとんどありません。一方、様子を見て何もしなかった場合、その間ずっと有効なままです。

迷ったら入れ替える。この判断を先に決めておくと、現場が「これは報告すべきか」で止まらずに済みます。報告のハードルを下げておくことが、結果として発見を早めます。

パスワードは、少し扱いが違う

ここまではAPIキーの話でした。パスワードについては、公式の書き方の強さが違います。正確にお伝えします。

機微な情報の扱いを説明した公式ヘルプは、共有について慎重であるよう推奨するものとして、いくつかを挙げています。金融に関する情報（社会保障番号、クレジットカード、銀行口座）、健康に関する記録、パスワード、機密の文書です。

2026年8月29日時点のAnthropic公式ヘルプの記載にもとづく

公式の記述としては、APIキーのほうが強い言い方です。この違いは、記事として正確に伝えるべきだと考えています。

ただし、実務での扱いは同じでよいと考えています。理由は1つで、どちらも「持っている人が本人として扱われる」情報だからです。性質が同じなら、扱いを分ける理由がありません。

公式の記述の強さと、自社の運用の厳しさは、別に決めてよいものです。公式が推奨に留めているものを、自社では禁止にする。これは矛盾ではありません。

社内のルールをどう書くか

ここまでの内容を、社内で使える形にします。

おすすめは、強さを2段階に分けて書くことです。

1段階目は「入れない」。APIキー、パスワード、クレジットカード番号。ここは例外を作らず、原則として入れないと書き切ります。判断の余地を残さないほうが、迷いません。

2段階目は「加工して入れる」。取引先名を伏せる、金額を丸める、個人名を役職に置き換える。使い道を残すための逃げ道です。

禁止だけのルールは守られません。現場は仕事を止められないので、隠れて使うようになります。加工して使う道を用意しておくほうが、結果として守られます。

誰が鍵を持つかを決めておく

もう1つ、ルールに入れておくと効く項目があります。鍵を発行してよい人を決めることです。

小さな組織では、必要になった人がその場で発行しがちです。すると、誰が何本持っているか分からなくなります。この状態がいちばん困るのは、漏れたときではなく、担当者が退職したときです。

本人しか知らない鍵が動き続けていて、止め方も、止めてよいかも分からない。使われ続ける鍵と、誰も管理していない請求だけが残ります。

合鍵を何本作ったか記録していない状態と同じです。回収しようにも、何本あるかが分かりません。

決めることは2つで足ります。発行してよい人を限ること。そして発行したら、用途と担当者を1行書き足すこと。台帳は表計算の1シートで構いません。大事なのは形式ではなく、本数が分かることです。

ルール全体の作り方は、生成AIの社内ガイドライン作成ガイドで扱っています。項目の抜けを確認したい場合は、AIセキュリティ対策チェックリストが使えます。

そして、ルールを作っても把握されていない利用が社内にあると、そこはルールの外側になります。その状態への対処はシャドーAI対策ガイドで扱っています。

明日から始める3つの手順

ここまでを、実行できる形にまとめます。

1つ目は、いま持っている鍵を数えることです。誰が、何本、どの用途で持っているか。数が分からない状態では、漏れたときにどれを止めればいいかも分かりません。

2つ目は、漏れたときの手順を1枚にしておくことです。止める・作り直す・確かめる。この順序と、押すボタンの名前を書いておきます。慌てている時に調べ始めると、その間も鍵は生きています。

3つ目は、入れてはいけないものの一覧を配ることです。APIキー、パスワード、カード番号。公式が名指ししているものを並べれば、説明の手間が省けます。

まとめ｜渡さないのではなく、渡し方を変える

整理します。APIキーについて、公式は公開の場・メール・サポートへの問い合わせに含めるなと書き、そこに「発行元とのやり取りであっても」と付け加えています。個人のパスワードと同じ扱いを求める、という基準です。

理由は、鍵がアカウントそのものへのアクセスを意味するからです。第三者のツールに渡すことは、その提供者にアカウントへのアクセスを与えることになる、と公式は説明しています。

私たちが実務で大事だと考えているのは、「渡すな」で終わらせないことです。業務では認証情報を扱わざるを得ない場面があり、禁止だけを並べても回りません。

公式が示しているのは、値そのものを見せずに渡す方法です。そのうえで、用途ごとに分け、定期的に入れ替える。後ろの2つは技術ではなく運用なので、決めれば今日から実行できます。

そして、漏れたときの順序を先に決めておくこと。止める、作り直す、確かめる。この3語を1枚の紙にしておくだけで、慌てている時の判断が変わります。

この記事で扱った内容は、どれも道具を買わずに、今日決められることばかりです。鍵を数える。手順を書いておく。発行してよい人を決める。費用がかからないのに、事故が起きたときの結果が変わります。

まず1つだけ選ぶなら、漏れたときの手順を紙にしておくことをおすすめします。自社の鍵の管理をどこから見直すべきか迷われている場合は、無料相談でも承っています。

よくある質問

APIキーをAIのチャット欄に貼ってしまいました。何をすればいいですか？

公式は、鍵が外部にさらされた可能性がある場合、ただちにその鍵を無効化するよう求めています。手順も示されており、Consoleのアカウントにログインし、API keysのページへ進み、該当する鍵の横にある3点メニューを開いて「Delete API Key」を選びます。ここで重要なのは順序です。先に新しい鍵を発行してから古い鍵を消すのではなく、まず無効化します。無効化すれば、その鍵は誰が持っていても使えなくなるためです。そのうえで新しい鍵を発行し、利用状況のログを確認して、想定外の使われ方がなかったかを見ます。会話を削除しても、鍵が無効になるわけではありません。削除は表示を消す操作であり、鍵そのものは有効なままです（2026年8月29日時点の公開情報）。

なぜAPIキーは、発行元にも渡してはいけないのですか？

公式ヘルプが「Just as you wouldn’t share your personal password, don’t share your API key」と書いており、個人のパスワードと同じ扱いを求めているためです。そのうえで、公開の場での議論、メール、そしてサポートチケットに鍵を含めないよう指示しており、そこには「even between you and Anthropic」という表現が添えられています。発行元とのやり取りであっても含めるな、という水準です。理由は、鍵がアカウントそのものへのアクセスを意味するからです。公式は第三者のツールに鍵を渡す場合について、そのツールの開発者に自分のアカウントへのアクセスを与えることになると説明しています。鍵は本人確認の手段であり、持っている人が本人として扱われます（2026年8月29日時点の公開情報）。

パスワードもAPIキーと同じように扱うべきですか？

公式の記述の強さが違うため、同じ強さの禁止としては扱えません。APIキーについては「含めるな」という明確な指示があります。一方でパスワードについては、機微な情報の扱いを説明した公式ヘルプが、金融に関する情報や健康の記録、機密の文書と並べて、共有に慎重であるよう推奨するという書き方をしています。指示ではなく推奨です。ただし実務上の扱いは同じでよいと考えています。どちらも、持っている人が本人として扱われる情報だからです。社内のルールを作るときは、APIキーは禁止、パスワードは原則入れないという形にしておくと、公式の記述の強さとも整合し、現場でも迷いません（2026年8月29日時点の公開情報）。

参考にした情報

• Anthropic 公式ヘルプ｜API Key Best Practices: Keeping Your Keys Safe and Secure
• Anthropic 公式ヘルプ｜Who can view my conversations?
• Anthropic プライバシーセンター｜How long do you store my data?

本記事は2026年8月29日時点で公開されている情報にもとづいています。各社の仕様や画面の項目名は更新される場合があるため、運用の判断前に最新の記載をご確認ください。