Claude Code×顧客のツール連携で、APIキーと権限の社内ルールを決める｜顧客のアカウントを預かる前の名義・保管・返却の型

この記事は、Claude Codeで顧客のツール連携を作るときに、APIキーと権限をどう預かるかの社内ルールを扱います。

「とりあえずチャットでキーを送ってください」から始めていないか

「APIキー、チャットに貼っておきました」
「管理者のIDとパスワードで、全部つないでおいてください」

ツール連携の案件では、こうした渡され方が今も起きます。
そして案件が終わったあとも、そのキーは誰かのパソコンや会話の記録に残ります。

キーが漏れたとき、問われるのは「誰が、どの権限で、どこに置いていたか」です。

APIキーの社内ルールとは、誰の名義で、どの権限を、どこに置き、いつ止めるかを、案件の前に決めておくことである

黒字化の外科医です。顧客のアカウントとAPIキーを預かるときの社内ルールを解剖します。

なお私は弁護士ではありません。実務の指針として読み、個別の判断は専門家や公的な窓口に確認してください。

ルールを先に決める理由は、三つあります。

第一に、APIキーは、顧客の権限そのものだから。
キーを持つ人は、顧客の画面に入らなくても、顧客のデータを読み書きできます。だから、必要な操作だけに権限を絞ったキーを、顧客の名義で発行してもらうのが出発点です。

第二に、人と案件は、必ず入れ替わるから。
担当者の退職、案件の終了、外注先の交代。そのたびに「どのキーを誰が持っているか」が分からなくなります。台帳がなければ、止めることもできません。

第三に、個人情報を扱う連携は、委託の関係になるから。
e-Govの法令検索で、2026年11月2日に個人情報保護法の条文を確認しました。第25条は、個人データの取扱いを委託する事業者に、委託先への「必要かつ適切な監督」を求めています。第27条第5項第1号は、委託に伴う提供の場合、提供を受ける者は第三者に当たらないとしています。
つまり顧客は、自社を監督する立場になります。監督に応えられる記録を、こちらが用意しておく必要があります。

委託を受ける側として決めておく項目は、こちらで扱っています。

▶ 個人情報の委託と安全管理措置、制作会社は「受ける側」として何を問われるか──委託元の監督に応える体制と、覚書で決める10項目

Claude Codeで、キーを「書かない・読ませない」設定

Claude Codeの公式ドキュメントで、次のことを確認しました（Claude Code公式ドキュメント、2026年11月2日確認）。

• 設定ファイルの permissions の deny に `Read(./.env)` のような規則を書くと、.env ファイルを読ませないようにできる
• MCPの設定をチームで共有する `.mcp.json` では、`${API_KEY}` のように環境変数を展開でき、キーそのものをファイルに書かずに済む
• `.mcp.json` のプロジェクト単位のサーバーは、対話の画面では使う前に承認を求められる
• 公式は、つなぐ前に各サーバーを信頼できるか確かめるよう注意している
• `claude mcp remove` は手元の認証トークンを消すが、認可サーバー側では取り消さない。対応している場合は、先に `claude mcp logout` を実行する

MCPをつなぐ前の点検は、こちらで扱っています。

▶ Claude CodeのMCPで社内ツールをつなぐ前に──信頼できるサーバーか、どこまで許すか、どの情報が流れるかの点検表

今すぐ試せる：預かり台帳の下書きを作るプロンプト

私はWeb制作会社の経営者です。顧客のツール連携案件で預かる、APIキーとアカウントの台帳を下書きしてください。

【前提】
・顧客名と案件名：〔記載〕
・つなぐツール：〔例：顧客管理、チャット、フォーム〕
・連携で必要な操作：〔例：問い合わせの登録、通知の送信〕
・扱う個人情報：〔例：氏名、メールアドレス〕
・自社の担当者：〔記載〕

1. ツールごとに、必要な権限を「読む・書く・管理」で最小にした案を出す。
2. キーとアカウントの名義を、顧客名義にする前提で台帳の行を作る。
3. 保管場所、有効期限、見直しの日、止める手順の列を作る。
4. 顧客に確認すべき質問を5つ挙げる。

キーの値そのものは、台帳に書かない前提で作ること。

預かりルール工場：台帳・依頼文・社内の10条

台帳の列

案件名／ツール名／キー・アカウントの名義（原則：顧客）
権限の範囲（読む・書く・管理）／発行日／有効期限
保管場所（共有のパスワード管理の仕組み、または顧客の環境変数）
使う人（個人名）／最後に見直した日
止める手順（誰が、どの画面で）／終了時の処理（返却・失効・削除の日付）

キーの値は書かず、「どこにあるか」だけを書きます。

顧客への依頼文

〇〇様

連携の作業にあたり、APIキーの発行をお願いいたします。

・名義：御社のアカウントで発行してください
・権限：〔問い合わせの登録〕と〔通知の送信〕のみで足ります。管理者の権限は不要です
・受け渡し：チャットやメールの本文には貼らず、〔共有の方法〕でお願いします
・期間：案件の終了時に、御社で失効していただくか、弊社から失効の手順をご案内します

弊社では、預かったキーを台帳で管理し、使う担当者を限定します。

社内ルールの10条

1. キーとアカウントは、原則として顧客名義で発行してもらう
2. 権限は、連携に必要な操作だけに絞る
3. 社長や担当者の個人のアカウントで、顧客のツールをつながない
4. キーをチャット・メール・ソースコードに書かない
5. Claude Codeでは .env を読ませない設定を、案件の共有設定に入れる
6. MCPの共有設定には、キーではなく環境変数の名前を書く
7. 預かったキーは、台帳に場所と使う人を記録する
8. 半年に一度、台帳と実際の権限を照らして見直す
9. 担当者の退職・交代の日に、その人が使っていたキーを再発行する
10. 案件の終了時に、失効と削除を顧客と確認し、日付を記録する

顧客から預かるIDとパスワードの扱いは、こちらで整理しています。

▶ パスワード管理、顧客から預かるIDで事故を起こさない制作会社のルール──FTP・管理画面・サーバー・ドメインの受け取り、保管、返却と依頼文

構造的なリスク

逆説を指摘しておきます。

ルールを細かくするほど、現場は面倒になり、個人のメモ帳にキーを控える人が出てきます。
厳しいルールが、見えない場所での保管を増やすのです。

10条をすべて守らせる前に、まず「顧客名義」「台帳」「終了時の失効」の三つだけを全案件で徹底してください。

漏れてしまったときの初動は、こちらにまとめています。

▶ APIキーの漏洩対策、制作会社は「書かない仕組み」と「漏れたら止める初動」──Git・.envの置き方、シークレットスキャン、鍵の無効化と再発行

よくあるQ&A

Q. 顧客が「全部任せる」と言い、管理者のIDを渡してきた。

受け取る前に、連携に必要な権限だけのキーを発行してもらうよう、依頼文を送ってください。顧客の同意があっても、広い権限を預かるほど、事故のときの説明が難しくなります。

Q. 自社名義で契約したほうが、管理が楽ではないか。

楽になる代わりに、解約時の引き渡しと、データの持ち主の説明が難しくなります。自社名義にするなら、その理由と終了時の扱いを契約に書きます。

Q. 社内の自動化でも、同じルールが要るか。

要ります。社内の自動化の権限と記録の決め方は、こちらで扱っています。

▶ 社内のAI・自動化の権限とログ、制作会社は「便利だから全部つなぐ」をやめる──誰の名義で何にアクセスさせるか、記録を何日残すか、顧客の情報を流してよい範囲の決め方

最後に

APIキーは、顧客から預かる鍵です。鍵の管理は、技術よりも記録で決まります。

名義・権限・保管・失効を案件の前に決めた会社だけが、顧客のツールを安心してつなげるのです。

これまでの記事は、メンバーシップ「黒字化オペ室」でまとめて読めます。月額1,980円、記事2本分の金額です。詳しくはプロフィールから。

#Web制作会社 #ClaudeCode #APIキー #権限管理 #情報セキュリティ #個人情報保護 #制作会社経営 #中小企業 #ツール連携 #社内ルール