外部エンジニアへのAPIキー・認証情報の安全な渡し方｜Slack送信NGの理由と3つの代替策

外部のエンジニアに開発を依頼し、いよいよ稼働開始という段階で「本番環境の接続情報とAPIキーを共有してください」と連絡が来る——。多くの発注担当者が、このメッセージを受け取った瞬間に手が止まります。いつものように Slack のダイレクトメッセージで送ろうとして、ふと「これ、社外の人に普通にチャットで送って大丈夫なんだっけ?」と不安になるのです。

不安になるのは当然です。認証情報やAPIキーは、いわば会社のシステムやお金につながる「鍵」そのものです。社内の信頼できるメンバー同士で回していた渡し方を、契約で結ばれただけの社外の人にそのまま使ってよいのか、確信を持てないのは健全な感覚といえます。一方で、稼働開始は目前。何が正解か分からないまま、結局「なんとなく」チャットで送ってしまった、という方も少なくないはずです。

幸い、外部エンジニアへの認証情報の渡し方には、専門知識がなくても今日から実行できる安全な手段がいくつもあります。大切なのは「生のキーをチャットやメールに残さない」という1点を守ったうえで、自社の状況に合った方法を選ぶことです。

本記事では、まず認証情報が漏れると何が起きるかを非エンジニアにも分かる形で整理し、やりがちなNGな渡し方を具体的に示します。そのうえで、安全な3つの代替策・自社に合う選び方・渡した後にやるべき後始末・契約で定めておくべきことまでを、発注担当者がそのまま使えるよう順を追って解説します。

外部エンジニアへの認証情報の渡し方で「手が止まる」理由

「Slackで送ろうとして手が止まる」——この感覚の正体を、まず言葉にしておきましょう。漠然とした不安のままでは正しく直すこともできません。何がどうまずいのかをはっきりさせることが、安全な渡し方への第一歩です。

そもそも「認証情報・APIキー」とは何か

外部エンジニアに渡すよう求められる「認証情報」には、たとえば次のようなものがあります。

• 本番データベースの接続情報: ユーザー名・パスワード・接続先のアドレス。これがあれば顧客データや売上データに直接アクセスできます。
• 外部サービスのAPIキー: 決済サービス・地図サービス・メール配信サービスなどを、自社のシステムから使うための「鍵」です。サービスによっては、これを使うと実際に課金が発生したり、登録された顧客情報を読み出せたりします。
• 管理画面のID・パスワード: サーバーの管理画面、クラウドサービスのコンソール、CMSの管理者アカウントなど。設定変更やデータ操作の権限を握る入口です。

いずれも共通しているのは、「その文字列さえ知っていれば、誰でもシステムやお金につながる扉を開けられる」という点です。社員証や物理的な鍵と違い、コピーした人が増えても見た目では分かりません。これが認証情報の扱いを難しくしています。

漏れると起きること

では、これらが第三者に漏れると具体的に何が起きるのでしょうか。発注担当者にとって他人事ではないのは、次のような事態です。

• 外部サービスの不正利用と想定外の課金: 決済やクラウドのAPIキーが漏れると、第三者がそのキーを使ってサービスを勝手に動かせます。クラウドの計算資源を大量に使われて高額な請求が来た、という事例は実際に起きています。
• 個人情報・機密データの流出: データベースの接続情報が漏れれば、顧客の氏名・連絡先・取引履歴などがそのまま外部に持ち出される可能性があります。流出が起きれば、顧客への通知や監督官庁への報告など、対応コストは課金被害の比ではありません。
• なりすまし・改ざん: 管理画面のパスワードが渡れば、第三者がサイトの内容を書き換えたり、不正なプログラムを仕込んだりできてしまいます。

外部エンジニア本人を疑う必要はありません。問題は、渡す途中の経路で第三者の目に触れたり、渡した後にその情報がどこかに残り続けたりすることです。チャットやメールは、まさにこの「途中で漏れる」「あとに残る」というリスクを抱えています。

「社内のやり方」を社外にそのまま適用するリスク

社内でやってきた渡し方をそのまま社外に使ってよいのか——ここで手が止まるのは、正しい感覚です。社内であれば、アクセスできる範囲が会社の管理下にあり、何かあったときに就業規則や情報管理体制で統制が効きます。

しかし外部エンジニアは、自分の管理外にある環境（個人のPC・自宅のネットワーク・本人が使うチャットツール）で作業します。渡した認証情報がその環境のどこにどう保存されるかを、発注側はコントロールできません。だからこそ、社外に渡すときは「渡す経路」と「渡した後の管理」を、社内以上に意識して設計する必要があるのです。

なお、本記事は「認証情報という文字列をどう物理的に安全に渡すか」に絞って解説します。「そもそも外部エンジニアに何の権限を与えるべきか」「どのツールにどこまでアクセスを許すか」というアクセス権設計については、外部エンジニアへの情報共有体制を設計する方法で詳しく扱っています。両方をあわせて押さえると、抜け漏れのない受け渡しができます。

やってはいけない認証情報の渡し方（NG例）

安全な方法を知る前に、まず「今やっているやり方がNGかどうか」を自己診断しましょう。以下は、多くの発注担当者が実際にやりがちな渡し方です。心当たりがあっても落ち込む必要はありません。直し方はこのあと解説します。

Slack・チャットのDMで生のキーを送る

最もよくあるのが、Slack や Teams のダイレクトメッセージに認証情報をそのまま貼り付けて送る方法です。手軽ですが、次の落とし穴があります。

• 履歴に残り続ける: チャットのメッセージは、削除しない限りずっと残ります。後からそのチャットルームに招待された別のメンバーや、退職・契約終了後もアカウントが残っている人が、過去のメッセージを遡って閲覧できてしまう可能性があります。
• 通知やプレビューで漏れる: スマートフォンのロック画面通知やPCのポップアップに、送ったキーの先頭部分が表示されることがあります。本人以外の目に触れる経路です。
• ゲスト・外部連携の権限が読めない: 外部エンジニアを招いたチャンネルにゲスト権限の整理が甘いと、想定外の人がメッセージを読めることがあります（Slack使用時のセキュリティ対策のポイントでも、ゲスト権限や誤送信のリスクが指摘されています）。

チャットは「会話」のためのツールであり、「鍵を保管・受け渡しする」用途には設計されていません。

メール本文・添付で送る

メールで送るのも避けたい方法です。

• 誤送信が取り消せない: 宛先を1文字間違えただけで、まったく無関係な相手に認証情報が届きます。一度送ったメールは基本的に取り消せません。
• 転送で拡散する: 受け取った側が良かれと思って別の担当者に転送すると、発注側の知らないところでキーが広がっていきます。
• サーバーに残る: メールは送信者・受信者双方のサーバーやバックアップにコピーが残ります。「メールを消したから安心」とはいきません。

共有スプレッドシート・ドキュメントに常時記載する

「認証情報一覧」のようなスプレッドシートを作り、そこに書いて共有リンクを渡す——これも危険です。

• リンクが流出すると全部見られる: 共有リンクは、URLを知っている人なら誰でもアクセスできる設定になっていることが多く、リンクが一度でも別の場所にコピーされると、そこに書かれた全ての認証情報がまとめて漏れます。
• 権限管理が追いつかない: 誰にいつ共有したかを管理し続けるのは手間がかかり、契約終了後もアクセス権が残りがちです。
• 常時アクセス可能=常時リスク: 一度きりの受け渡しと違い、ファイルが存在し続ける限りリスクもゼロになりません。

ここまでに挙げた「チャット・メール・常時共有ファイル」に共通する問題は、渡したキーがどこかに残り続け、誰がアクセスできるかを発注側が完全には管理できないことです。次の章では、この問題を解消する安全な渡し方を紹介します。

安全な渡し方の3つの選択肢

ここからが本題です。外部エンジニアに認証情報を安全に渡す方法を、導入のハードルが低い順に3つ紹介します。難易度順なので、上から検討すれば自社に合うものが見つかります。

期限付き・閲覧回数制限のワンタイム共有

最も手軽なのが、期限付き・閲覧回数制限つきのワンタイム共有です。これは「一定時間が過ぎる、または1回閲覧されると自動的に消える」リンクを発行して、そのリンクだけを相手に伝える方法です。

仕組みはシンプルです。専用のサービスに認証情報を入力すると、たとえば「24時間で失効」「1回見たら消える」といった条件付きのリンクが生成されます。相手はそのリンクを開いて中身を確認し、条件を満たすとリンク自体が無効になります。これにより、チャットやメールの最大の弱点だった「履歴に残り続ける」問題が解消されます。

たとえば 1Password のようなパスワードマネージャーには、保存したアイテムを有効期限付きのリンクで誰とでも共有できる機能があります（1Password の機能ページ）。同様の機能を提供するワンタイム共有サービスは複数あり、単発の受け渡しであれば無料で使えるものもあります。

• 向いているケース: 「稼働開始時に一度だけキーを渡せばよい」「継続的な共有は想定していない」といった単発の受け渡し。
• 注意点: リンクそのものをチャットで送ること自体は問題ありませんが、リンクと同じ場所に閲覧用のパスワードを書いてしまうと意味がなくなります。リンクとパスワードは別の経路で伝えるのが原則です。

パスワードマネージャーの共有保管庫

継続的にキーを共有する、チームで複数の認証情報を扱う、という場合はパスワードマネージャーの共有保管庫が適しています。

パスワードマネージャー（1Password など）には、個人用の保管庫とは別に、特定のメンバーやグループだけがアクセスできる「共有保管庫（共有Vault）」を作る機能があります。ここに認証情報を登録し、外部エンジニアをその保管庫のメンバーとして招待すれば、キーの文字列そのものをチャットで送ることなく共有できます。

この方法の利点は、渡したあとの管理がしやすいことです。

• 誰がどの保管庫にアクセスできるかを一覧で管理できる
• 契約終了時は、相手を保管庫から外すだけでアクセスを止められる
• キーを更新したときも、保管庫の中身を書き換えれば全員が最新の情報を参照できる

導入の手間はワンタイム共有より少し大きい（双方がツールを使える状態にする必要がある）ものの、複数のキーを長期的に扱うプロジェクトでは、この一手間が後の管理を大きく楽にします。

• 向いているケース: 継続的な開発、複数の認証情報を扱う、チームで運用する。
• 注意点: 共有保管庫に何でもまとめて入れず、「その外部エンジニアの作業に必要なものだけ」を入れるのが鉄則です。

シークレットマネージャー・環境変数で「そもそも生のキーを渡さない」

最も安全性が高いのは、そもそも人手で生のキーを渡さない運用です。少し専門的になりますが、考え方だけ知っておくと、エンジニアと相談するときに話が早くなります。

システム開発の世界には、APIキーやパスワードといった「秘密の文字列」を専用の仕組みに預けておき、プログラムが必要なときだけそこから読み出す方法があります。代表的なのが、クラウド各社が提供するシークレットマネージャーや、.env（環境変数ファイル）を使った管理です。

この運用では、外部エンジニアにキーそのものを手渡すのではなく、「この仕組みから読み出すように作ってください」という形で開発を進めます。キーの実体はエンジニアの手元に残らず、発注側が一元管理できるため、漏洩リスクと管理コストの両方を下げられます。実際、APIキーをコードに直接書き込まず外部の仕組みで管理することは、サービス提供元の公式ガイドでも推奨されている基本方針です（OpenAI: APIキーの安全性に関するベストプラクティス）。

• 向いているケース: 本格的・長期的なシステム運用。セキュリティを重視するプロジェクト。
• 注意点: 導入には技術的な作業が必要なため、外部エンジニアや社内の技術担当に相談する前提の選択肢です。発注担当者だけで完結はしませんが、「こういうやり方がある」と知っているだけで提案の幅が広がります。

3つの手段の比較

3つの選択肢を、手間・安全性・向くケースで整理すると次のようになります。

どれを選んでも、共通する大原則は変わりません。「生のキーをチャットやメールの履歴に残さない」——これさえ守れば、現状より確実に安全になります。

自社に合う認証情報の渡し方の選び方

選択肢が分かっても、「結局うちは何を使えばいいの?」という疑問が残ります。ここでは自社の状況に当てはめて選べるよう、簡単な判断の流れを示します。

判断フロー（導入済みツール × 受け渡し頻度）

次の順に考えると、自社に合う方法が絞り込めます。

1. すでにパスワードマネージャー（1Password など）を会社で導入しているか?

   • 導入済み → 共有保管庫を使うのが最もスムーズです。外部エンジニアをゲストとして招き、必要なキーだけを入れた保管庫を共有しましょう。
   • 未導入 → 次の質問へ。

2. 認証情報を渡すのは単発か、継続的か?

   • 単発（稼働開始時に一度だけ） → 期限付きワンタイム共有で十分です。無料サービスもあり、今日この場で実行できます。
   • 継続的・複数のキーを扱う → この機会にパスワードマネージャーの導入を検討する価値があります。月数百円〜のコストで、その後の管理が大きく楽になります。

3. 長期・本格的なシステム運用を見据えているか?

   • 見据えている → シークレットマネージャーや環境変数による運用を、外部エンジニアや技術担当に相談してみましょう。最初の設計段階で組み込むのが理想です。

ツール未導入でも今日できる最低ライン

「パスワードマネージャーを導入する時間がない」「今日中に渡さないと作業が止まる」——そんなときでも、守るべき最低ラインがあります。

• 生のキーをチャット・メール・常時共有ファイルに残さない: これが絶対の一線です。
• 期限付きワンタイム共有を使う: 無料サービスでも、チャットに直貼りするより圧倒的に安全です。登録不要で使えるものもあります。
• リンクとパスワードを別経路で渡す: 共有リンクは Slack、閲覧用パスワードは電話や別のチャット、というように経路を分けると、片方が漏れても中身は守られます。

社内ルールがまだ整っていなくても、この最低ラインだけは今日から徹底できます。完璧を目指して動けなくなるより、まず「チャット直貼りをやめる」一歩を踏み出すことが大切です。

渡した後にやるべきこと（廃棄・ローテーション・失効）

認証情報の受け渡しは「渡して終わり」ではありません。むしろ、渡した後の管理こそが漏洩を防ぐ要になります。ここを押さえておくと、競合記事ではあまり触れられない「渡した後」のリスクまでカバーできます。

受け渡し直後の後始末

キーを渡したら、その日のうちに次を確認しましょう。

• 共有リンクの失効を確認する: ワンタイム共有を使った場合、相手が閲覧したらリンクが無効になっているか、または期限が切れる設定になっているかを確認します。
• 送信記録を消す: もしやむを得ずチャットでリンクを送った場合でも、相手が受け取ったことを確認したら、そのメッセージを削除します（リンク自体が失効していれば実害は小さくなりますが、習慣として残さないことが大切です）。
• 「誰に何を渡したか」を記録する: どの外部エンジニアに、どのキーを、いつ渡したかを一覧にしておきます。後でローテーションや失効を行うとき、この記録が必須になります。

稼働中の運用

開発が続いている間も、次の2点を意識します。

• 最小権限を保つ: 渡すキーは「その作業に必要なものだけ」に絞ります。「念のため全部渡す」は、漏れたときの被害を最大化するだけです。どのキーにどこまでの権限を持たせるかは、外部エンジニアへの情報共有体制を設計する方法で詳しく扱っています。
• 定期的にキーをローテーション（更新）する: APIキーやパスワードは、定期的に新しいものに切り替えると安全性が高まります。万が一どこかで漏れていても、古いキーが無効になっていれば被害を防げます。更新の頻度や方法は外部エンジニアに相談しながら決めると現実的です。

契約終了時の失効と権限削除

プロジェクトが終わったときに最も忘れられがちなのが、渡したキーの無効化と権限の削除です。契約は終わっても、渡した認証情報は相手の環境に残っているかもしれません。次を必ず実施しましょう。

• 渡したAPIキー・パスワードをすべて無効化（再発行）する
• 共有保管庫やツールから相手のアカウントを外す
• 管理画面・サービスのアクセス権を削除する

「誰に何を渡したか」の記録があれば、この作業は漏れなく進められます。契約終了時に何を引き継ぎ、何を止めるべきかについては、外部エンジニア引き継ぎドキュメントの作り方もあわせて確認しておくと、認証情報の失効を含めた終了処理を体系的に整理できます。

契約・ルールで定めておくべきこと

ここまでは「技術的にどう渡すか」を見てきました。最後に、受け渡しの安全性を個人の善意やその場の判断に頼らないための、契約・社内ルールの話をします。仕組みとして決めておくことで、「これだけ押さえれば大丈夫」という確信が持てます。

NDA・契約で定める保管/廃棄の取り決め

外部エンジニアと交わす業務委託契約や秘密保持契約（NDA）には、認証情報の取り扱いに関する条項を入れておきましょう。具体的には次のような内容です。

• 保管範囲の限定: 渡した認証情報を、業務に必要な範囲を超えて保存・複製しないこと。
• 廃棄の義務: 契約終了時、または不要になった時点で、保有する認証情報を削除すること。
• 事故時の連絡体制: 万が一漏洩や紛失が起きた場合、速やかに発注側へ報告すること。

これらを契約に明記しておくと、相手にも「認証情報は慎重に扱うべきもの」という意識が共有され、トラブル時の責任の所在も明確になります。

情報共有・アクセス権設計とのつながり

認証情報の安全な受け渡しは、より広い「外部エンジニアとの情報共有体制」の一部です。本記事で扱った「キーをどう渡すか」は受け渡しの実装にあたりますが、その手前には「そもそも何を共有してよいか」「どのツールにどこまでアクセス権を与えるか」という設計があります。

この設計の部分は、外部エンジニアへの情報共有体制を設計する方法で体系的に解説しています。受け渡しの手段（本記事）と権限の設計（関連記事）の両輪がそろってはじめて、「個人の善意に頼らず、仕組みで守る」状態が完成します。

まとめ

外部エンジニアへの認証情報・APIキー・パスワードの渡し方で迷ったとき、覚えておくべき一丁目一番地はシンプルです。生のキーを Slack・メール・常時共有ファイルの履歴に残さない——これだけで、現状より確実に安全になります。

そのうえで、本記事のポイントを振り返ります。

• やりがちなNG: チャットのDM・メール・共有スプレッドシートは、キーが残り続け、誰がアクセスできるかを管理しきれないため危険です。
• 安全な3つの選択肢: 単発なら「期限付きワンタイム共有」、継続的なら「パスワードマネージャーの共有保管庫」、本格運用なら「シークレットマネージャー・環境変数（要エンジニア相談）」。
• 選び方: 「パスワードマネージャー導入済みか」「単発か継続か」で絞り込めます。未導入でも、ワンタイム共有を使えば今日から実行できます。
• 渡した後: 共有リンクの失効確認・送信記録の削除・最小権限の維持・定期的なローテーション・契約終了時の失効と権限削除までがワンセットです。
• 仕組みで守る: NDA・契約で保管範囲と廃棄、事故時の連絡体制を定め、個人の善意に頼らない運用にします。

明日から実行できる最小ステップは、「次にキーを渡すとき、チャット直貼りをやめて期限付きワンタイム共有を使う」こと。たったこれだけで、漠然とした不安は具体的な安心に変わります。まずはその一歩から始めてみてください。