Claude Codeを社員が情報漏洩を気にせず使えるようにするまで—鍵もデータもPCに残さない企業の社内導入の記録

ビジネス職の社員がClaude Codeを使って、Googleドライブの中のファイルを直接触れるようにしたいということから本記事の活動が始まりました。Claude Codeを用いて、スプレッドシートも、ドキュメントも、スライドも、開いて読んで、書き換えるところまでやりたい。しかし、そこで出てきたセキュリティの懸念をどう解決したか、が今回の記事の本題です。

株式会社プロリクの橋崎です。私はエンジニアではありません。これまで「【実践Claude Code】Google広告の操作をClaude Codeで自動化してみた——構築の全記録と6つの落とし穴」や「Facebook（Meta）広告をClaude Codeで自動化した話」、「採用管理システム（ATS）をClaude Codeで自作してみた」と、広告の入稿や採用管理システムを自分で作ってきました。同様のシリーズとして今回もClaude Codeとの格闘を記事にしていきたいと思います。

ISMS取得企業にとっての、ビジネス職がClaude Codeを使う時の個人情報、機密情報漏洩リスクを考える

Claude Codeは非常に便利ですよね。記事をご覧になっている各企業の方々もおそらくClaude Codeをどんどん使って自動化をされている企業様ではないでしょうか。

私も全社でClaude Codeを使って作業を自動化したいという思いを持って、当初全社検討を始めました。しかし、ISMS取得をしセキュリティを重視する弊社にとって、Claude Codeをビジネス職が使うことは一定程度リスクが伴うと感じており、やや導入を劣後させていたところがあります。

そもそもビジネス職にとってClaude Codeの個人情報、機密情報漏洩リスクとは？

Claude Codeは、開発AIエージェントとして作られています。つまり、開発者に向けて作られたツールです。したがって開発者の通常の業務プロセスに沿ってツールが作られています。通常、エンジニアはローカルにソースコード等のファイルを置いて開発を行い、一定程度開発が進捗すると、Githubにファイル共有することでチームと同期をはかります。

一方、IT企業を主としたビジネス職は、通常クラウド環境で仕事をします。Google Workspaceを代表としてGoogleDocs、スプレッドシート、スライドなどを用いて仕事をしています。コロナをきっかけにリモートが流行りましたので、一気にその傾向は強くなったかもしれませんね。そのため、ローカルに機密情報を置かない、あくまでクラウドだけで作業をする、という仕組みになっている企業も一定数いるのではと思います。弊社もそうです。ローカルには一切機密情報は置かず、ただの箱として使い、機密情報はあくまでクラウド（Google）だけにある、という形にしています。

そして、Claude Codeはエンジニアをベースに作られているので、ローカルで作業をしやすいようになっています。Claude Codeはローカルファイルを触り、作業のアウトプットはローカルに残っていきます。

このClaude Codeの特性が、ビジネス職のクラウド化と相反し、セキュリティがうまく担保できないという構造になっていたわけです。

とはいえ、Claude CodeはGoogle Workspaceと連携して作業ができるはず。実際のリスクはなにか？

ここまで書いてきて、「いやいや、Claude Code経由でGoogle Workspaceは触れるじゃないか」という話も当然出ると思います。Googleドライブのファイルは、社員のパソコンの中にありません。Googleのサーバーの上にあります。Claude Codeがその中身を読むには、Googleに認証を通す必要があります。

①は論外として、②以降、いくつかの方法論があることが分かります。なお、サービスアカウントは、プログラムが使うためのGoogleのアカウントです。メールアドレスの形をしていて、人と同じようにファイルやフォルダの共有先に指定できます。だから「このフォルダだけ見せる」という設定ができます。

私としては、Claude CodeとGoogle Workspaceに関連して、以下のリスクがあると考えていました。

ダウンロードは分かりやすい話です。落とした瞬間に、そのファイルは会社の管理の外に出ます。

鍵ファイルは .json の1枚のファイルです。これを持っている人は、その鍵に付いた権限をそのまま使えます。有効期限はありません。社員のパソコンに置いた鍵が、いつ、どこにコピーされたかを追う方法がありませんので、リスクが高いと判断しました。

社員本人のGoogleアカウントで許可を出すやり方も検討しました。「本人のアカウントで認可すればいい」というのは、一見安全に聞こえます。しかし、本人のアカウントで許可を出すと、その人が見られるドライブ全部にアクセスできるアクセストークンが発行されて、それがパソコンに保存されます。フォルダ1つに限定できません。Claude Codeに用意されているGoogle Driveのコネクタも、このやり方にあたります。追加するだけで使えて手軽なのですが、範囲を絞る手段がありません。

4つ目のリスクは、接続の仕方とは別の話です。Google Workspaceにうまく接続できたとしても、Claude Codeが社員のパソコンで動いている限り、そのやりとりの記録はパソコンの中にJSONのファイルとして残ります。Claude Codeに何を聞いて、どういう内容の処理をし、どういうアウトプットだったかが、そのまま残ります。ここは接続の方法を変えてもリスクが消えず、機密情報をPCに保持し続けるという状態でした。

Googleのサーバーで動かすことにした（セキュリティ対策の結論）

以上のような検討を経て、今回弊社は、社員のパソコンに何も置かない、Claude Codeも置かない、しかし1人1人がClaude Codeを使って、安全にGoogle Workspaceにアクセスし、特定のフォルダやファイルだけを操作可能とする、という方法をとりました。

具体的には、ブラウザ経由でGoogleのサーバーにアクセスし、そのサーバー上でClaude Codeを動かすという方法をとっています。これにより、ファイルの中身はGoogleサーバー内で処理され、社員のパソコンには記録は何も残りません。あくまで箱としてPCを使うという当初の考え方の通りの運用が実現できた、ということになります。

どういう権限の絞り方、仕組みで動いているか

社員はGoogle Chromeのようなブラウザを使います。ブラウザで Googleのサーバーを開きます。これは、Cloud Shell と呼ばれるものを使いました。CloudShell（クラウドシェル）とは、ブラウザから直接操作できる、事前認証済みのコマンドライン（CUI）環境のことです。Googleのサーバーの上にその人専用のLinux環境が立ち上がります。Claude Codeはその環境の中にインストールしてあり、そこでブラウザ経由で操作をするということになります。

Claude Codeがファイルを読むときは、サービスアカウントの権限を借りて、Googleドライブにアクセスすることができます。そのサービスアカウントは、招待された1つのフォルダにだけ権限が付与されており、そこでだけ操作をすることが許可されています。それ以外のファイルは、Claude Codeからは存在すら見えません。

うまくいかなかったこと、はまったこと

1. プロジェクトIDに google という文字が使えない

Google Cloudのプロジェクトを作るとき、IDに google を含めると INVALID_ARGUMENT というエラーになって作成できません。google と ssl はGoogleが予約しています。表示名の方には制限がないので、IDだけ別の名前にして、表示名は希望どおりにしました。最初はタイプミスを疑って何度か打ち直しました。

2. 新しいファイルが作れない

前述の storageQuotaExceeded です。権限の設定を疑って時間を使いましたが、原因は容量の割り当てでした。読み書きはできるのに新規作成だけができません。

3. Google形式に変換されたファイルは取り出せない

配布用のファイルをドライブに置くとき、Googleドキュメント形式に変換されていると、スクリプトからは中身を取得できません。変換しない設定でアップロードします。変換されている場合は警告を出して飛ばすようにしました。

4. Cloud Shellは1時間で切れる

1時間操作しないとセッションが終了します。この時間は設定で変えられません。ファイルもログイン状態も残っているので、claude と打ち直せば続きから使えますが、長い処理を流しっぱなしにする使い方には向きません。

5. 配布物を直したら、別の環境で試してから配る

setup.sh は社員全員の環境を作るファイルなので、自分の環境でそのまま実行して試すと、自分の設定を壊します。ホームディレクトリを一時的な場所に差し替えて実行し、同じものができるか、2回実行しても壊れないかを確認してから配るようにしました。

Workspaceに入っているなら追加費用はなし

Google Cloud側は0円です。Cloud Shellは無料で、使っているAPI（Drive、Sheets、Docs、Slides、IAM Credentials）も無料です。請求先アカウントの紐付けもしていません。

そのかわり、Cloud Shellは1人あたり週50時間までしか使えません。

週50時間は、毎日使っても1日10時間まで使える計算です。今回の使い方（ビジネス職としてよく利用する、スプレッドシートを開いて分析させる、資料を直すなど）では足りると判断しました。

足りなくなったら Cloud Workstations という別のサービスに移せます。操作しない状態が続いたときの終了までの時間を設定でき、週の上限もありません。費用は月36ドル前後です。Google Cloud側の設定はそのまま使い回せるので、移すときに作り直しは要りません。

このほかに、社員それぞれのClaudeアカウントが必要です。Googleの認証（データを触る権利）とAnthropicの認証（Claude Codeを使う権利）は別のものです。認証情報はCloud Shell側に保存されるので、社員のパソコンには残りません。

まとめ：企業がClaude Codeを導入するときに考えること

社員にClaude Codeを渡すかどうかは、Claude Codeが安全かどうかでは決まりませんでした。データと認証情報をどこに置くかで決まりました。

弊社はローカルに機密情報を置かない運用をしています。Claude Codeはローカルで作業するツールです。この2つが合わないというのが出発点でした。接続の方法を変えるだけでは、会話の記録がパソコンに残ってしまうので解決しませんでした。Claude Codeを動かす場所をGoogleのサーバーに移して、社員のパソコンではブラウザだけを動かすことにしました。

鍵ファイルを発行しなかったので、流出する鍵がありません。社員のパソコンに何も置いていないので、退職のときに回収するものもありません。社員が編集可能な範囲はGoogleドライブの共有画面で決まるので、企業側で容易にマネジメントが可能です。

Google Workspaceを使っていて、社員にもClaude Codeを使わせたいと考えている企業であれば、同じ形が作れるかと思います。

他の自動化の記録もまとめてあるので、【実践Claude Code】非エンジニアがClaude Codeで業務を自動化する方法もあわせてご覧ください。採用まわりを自分で作った記録は採用管理システム（ATS）をClaude Codeで自作してみたにあります。よろしければご参考ください。

弊社お問い合わせ窓口

株式会社プロリクでは、生成AI導入・実装・運用支援サービス「MIRAIGEN（ミライジェン）」を提供しています。本記事のようなMCP連携による広告運用の自動化から、社内業務プロセスの再設計まで、お気軽にご相談ください。

株式会社プロリク | 人とAIの働き方をリデザインする

株式会社プロリクは「人とAIの働き方をリデザインする」AHRカンパニーです。独自開発AIによるエンジニア採用支援で採用を成功に導き、生成AIソリューションで企業の業務自動化までを一気通貫で支援し、人とAIの協働を支援します。

www.prorec.jp

👤

著者について

橋崎 良哉（株式会社プロリク ）

Webサイト制作事業にて在学中に起業。家業に入り、鉄鋼加工会社で取締役として業績回復を牽引。その後グローバルに特化したデジタルマーケティング支援会社にてマーケター、データ解析などを担当した後、AIスタートアップであるエッジテクノロジー株式会社の取締役COOとして、機械学習実装支援や、機械学習を用いた営業自動化SaaSを立ち上げ、6年で0から社員70名程度までグロースさせる。2020年2月株式会社プロリクを設立。

よくある質問（FAQ）

Q. 社員にClaude Codeを使わせても大丈夫ですか？ A. 渡し方によります。判断の分かれ目は、業務のデータと認証情報がどこに置かれるかです。社員のパソコンにファイルを落として読ませる形だと、そのデータは端末に残り続けます。今回はClaude CodeをGoogleのサーバー（Cloud Shell）で動かして、社員のパソコンではブラウザだけを動かすようにしました。

Q. 社員のパソコンにデータは残りませんか？ A. 残りません。Claude Codeもファイルの処理もGoogleのサーバー側で動いていて、社員のパソコンにはブラウザに表示された画面が出るだけです。社員が自分でダウンロードの操作をしない限り、業務データが端末に保存されることはありません。

Q. サービスアカウントの鍵ファイルは必要ですか？ A. 必要ありません。今回は鍵を1つも発行していません。gcloud auth print-access-token --impersonate-service-account=（サービスアカウントのアドレス） というコマンドで、1時間だけ有効なアクセストークンを受け取り、そのままGoogleのAPIに渡しています。ファイルには書き出さないので、1時間経てば何も残りません。

Q. 誰でもサービスアカウントの権限を借りられるのですか？ A. 管理者が名前を指定して許可した人だけです。roles/iam.serviceAccountTokenCreator という権限を、そのアカウントに付けます。付けるのも外すのもコマンド1行です。付けてから実際に使えるようになるまで、実測で約30秒かかりました（Googleの説明では最大数分）。

Q. 退職する社員のアクセスはどうやって止めますか？ A. その人に付けた権限を1行のコマンドで取り消します。取り消せばサービスアカウントの権限を借りられなくなるので、そこで終わりです。鍵ファイルを配っていないため、パソコンから回収するものはありません。

Q. 社員が見られる範囲はどうやって決めますか？ A. Googleドライブの共有画面で、対象のフォルダにサービスアカウントを招待します。ファイル単位ではなくフォルダ単位で、通知のチェックは外して追加します。フォルダを指定せずに全ファイルの一覧を取って確かめたところ、招待していないファイルは0件でした。招待したフォルダの中身3件だけが見えました。

Q. Googleのサーバー側には会話の記録が残るのではありませんか？ A. 残ります。そのため、Claude Codeを起動する前と終了した後の両方で、会話の記録を毎回削除するようにしました。そのかわり claude --resume で前回の会話を再開することはできません。なお CLAUDE_CODE_SKIP_PROMPT_HISTORY=1 を設定するだけでは足りません。この環境変数が止めるのは打ち込んだ指示の履歴（history.jsonl）だけで、会話の記録の本体は残ります。弊社の環境では実測で339MBありました。

Q. Claude Codeに新しいスプレッドシートやドキュメントを作らせることはできますか？ A. 今回の構成ではできません。storageQuotaExceeded というエラーになります。Googleドライブではファイルの持ち主が容量を使う仕組みで、サービスアカウントには容量が割り当てられていないためです。人が空のファイルを作ってフォルダに置けば、中身は書き込めます。作る頻度が高いなら、共有ドライブを作ってサービスアカウントをコンテンツ管理者として招待する方法もあります（Google Workspace の Business Standard 以上のプランが必要です）。

Q. 社員に配るのにどれくらいかかりますか？ A. 社員の作業は10分ほどです。ブラウザでCloud Shellを開き、セットアップ用のスクリプトをアップロードして1回実行するだけです。2回目からは claude と打つだけになります。このスクリプトに秘密の情報は入っていません。書いてあるのはサービスアカウントのアドレスと対象フォルダのIDだけで、どちらもGoogleドライブの共有画面に表示される情報です。

Q. 費用はいくらかかりますか？ A. Google Cloud側は0円です。Cloud Shellも、使っているAPI（Drive、Sheets、Docs、Slides、IAM Credentials）も無料です。制限は1人あたり週50時間で、1時間操作しないとセッションが切れます。足りない場合は Cloud Workstations（月36ドル前後）に移せます。このほかに、社員それぞれのClaudeアカウントが必要です。