「社員に Claude を使わせたい。ただし機密データは外に出したくない」。その言葉は一見シンプルですが、どこでAIに処理（推論）させるか、誰が管理するか、どこまで使わせるかによって、設計はまったく異なります。ここでいう「推論」とは、AIが入力を受け取って回答を作り出す処理のことです。
この記事は、IT部門に丸投げする前に意思決定者が把握しておくべき設計の考え方と、判断すべきポイントを整理したものです。技術の細部ではなく、「なぜその構成が必要なのか」という理由に焦点を当てています。
まず「要件」を経営側が決める
企業での AI ツール展開で最初に必要なのは、技術選定ではなく要件の言語化です。次の問いに答えられるかどうかが、設計の出発点になります。
- 社内秘の資料（提案書・財務データ・会議資料など）を AI に渡して処理させることを、会社として許容するか
- 許容する場合、そのデータはどこで処理され、どこに残るのか
- インターネット検索はどの範囲まで使わせるか。社内のフィルタリングをそのまま適用できるか
- 誰に使わせるのか。全社員か、特定部門か
これらは技術の問題ではなく、情報管理方針とリスク許容度の問題です。IT部門はその答えを受けて設計しますが、答えを出せるのは経営・マネジメント側だけです。
「データが外に出ない」とはどういう状態か
Claude Desktop を一般的な使い方（Anthropic のサービスに直接接続）でインストールした場合、チャットの内容やアップロードしたファイルは Anthropic のサーバーで処理されます。これは多くの企業の情報管理ポリシーと相容れません。
一方、Amazon Bedrock 経由で接続する構成では、処理が AWS の環境内で行われます。Anthropic のサーバーには届かず、社内のデータが外部の AI 企業に渡ることはありません。さらに AWS の閉じたネットワーク経路を使えば、推論のやり取り（AIとの通信）をインターネットに出さずに済ませることもできます。ただしこれは推論経路の話で、アプリ自体は起動時の実行環境の取得など、Anthropic側への通信を一部必要とします。「外部通信が完全にゼロになる」わけではない点にご注意ください。なお、GCP（Vertex AI）や Azure（Azure AI Foundry）経由でも同様の閉じた構成が取れる可能性がありますが、Claude Desktop との接続方法や契約条件が異なるため、本記事では AWS Bedrock に絞って解説します。他クラウドを検討する場合は別途調査をお勧めします。
「社内秘の資料を上げてレビューさせたい」という用途は、この構成があってはじめて許容できるものです。逆に言えば、この構成なしに社員が社内秘資料を Claude に渡すことを黙認することは、情報管理の観点から大きなリスクになります。
「社内プロキシを通す」の意味
多くの企業では、社員のインターネットアクセスに何らかのフィルタリングや監視が入っています。Claude に「調べ物をしてきて」と頼む機能（検索連携）も、この社内の仕組みをそのまま通す形で設計できます。
技術的には、AI が検索に行くときの通信を社内プロキシ経由に設定するだけです。すでに社内で確立しているルールが AI にも自動的に適用されるため、「AIだけ別ルールで動く」という抜け穴をつくらなくて済みます。
配布と認証 ― 「野良インストール」を防ぐ
もう一つ、マネジメント側が関与すべきポイントが配布の管理です。「各自でダウンロードしてください」では、設定がバラバラになり、意図しない接続先（Anthropic 直接など）に繋いでいる社員が出てきます。
現実的なアプローチは、IT部門が社内のファイルサーバーやポータルにインストーラーを置き、そこから取得させることです。同時に、誰でも自由に設定を変えられないよう、接続先や動作設定を IT 側で管理します。
認証についても同様です。個人が自分のアクセスキーを管理する運用は、退職時の対応漏れや情報漏洩リスクにつながります。社内の ID 基盤（AWS SSO など。社員が一度のログインで各種システムを使えるようにする仕組み）と連携させることで、入退社に合わせたアクセス管理が一元化できます。
社内文書を AI に「読ませる」には ― RAG という考え方
「就業規則を聞いたら答えてほしい」「製品仕様書を参照しながら提案書を作ってほしい」という用途は、社員が都度ファイルを添付しなくても実現できます。あらかじめ社内文書を AI が検索できる形で準備しておく仕組みを RAG（検索拡張生成） と呼びます。
AWS には、この仕組みを手間なく提供するサービスがあり、S3（AWS上のファイル保管場所）に文書を置くだけで自動的に検索可能な状態にしてくれます。データは AWS 内に留まります。
ただし、RAG の精度は「何を入れるか」で決まります。古い文書・下書き・個人メモまで放り込むと、誤った情報を参照してしまいます。「承認済みの規程・マニュアル・FAQ だけを入れる」など、情報の質を管理するルール作りがセットで必要です。これはデータの整備と同じ話で、技術だけでは解決しない経営判断の領域です。
もうひとつ注意が必要なのが社内のアクセス権との整合性です。RAG に機密度の高い文書を入れると、本来その情報を見る権限のない社員でも「Claude に聞けば答えが返ってくる」状態になります。データは社外に出なくても、社内の情報管理ルールが崩れることになるため、誰でも参照してよい文書だけを RAG に入れるか、部門ごとにアクセスできるナレッジを分けて管理する設計が必要です。
また、Azure などに既存の文書がある場合は、どの文書を選んで AI に読ませるかを整理し、AWS 側に連携する運用フローを設計することになります。最初から完全自動化を目指す必要はなく、パイロット段階では手動で選抜・登録しながら精度を確認するアプローチが現実的です。
ガバナンス ― 技術だけでは守れないもの
設計と配布が整っても、使い方のルールを定めなければガバナンスは完成しません。技術的に機密資料を処理できる環境を整えたとしても、「このツールで何をして良くて、何をしてはいけないか」を社員が理解していなければ意味がありません。
たとえば次のような項目を、利用開始前に文書化しておくことを推奨します。
- どの機密レベルまでの情報を入力して良いか（データが社外に出なくても、端末のローカルに会話履歴が残るため、社内のアクセス権管理の観点で範囲を定める必要がある）
- 生成された文書を社外に出す際の確認フローはどうするか
- AI の出力を「鵜呑みにしない」ための判断基準はどこに置くか
- 問題が起きたときの報告ルートはどこか
これらは IT 部門が決めることではなく、情報セキュリティポリシーや業務ルールとして、経営・マネジメントが決めることです。
展開の進め方 ― 小さく始めて広げる
全社一斉展開ではなく、段階的なアプローチが失敗を減らします。
IT 担当者と一部の業務担当者で試す。接続・配布・認証が正しく動くかを確認し、「どんな用途で価値が出るか」を実感する段階。RAG はまだ不要。
パイロットの知見をもとに設定を整備し、特定部門に展開。社内文書の RAG も段階的に追加する。利用ポリシーの文書化もこの段階で完成させる。
MDM（端末管理ツール）を使った自動配布と、ヘルプデスク体制を整えたうえで全社へ。コスト管理・監査ログの運用も定常化させる。
まとめ ― マネジメント層が決めるべきこと
| 判断事項 | 決める主体 |
|---|---|
| 機密データを AI に渡すことの可否・範囲 | 経営・情報セキュリティ責任者 |
| AWS Bedrock 経由での構成採用 | 経営・IT責任者 |
| インターネット検索の許可範囲 | 情報セキュリティ責任者 |
| 誰に使わせるか・いつから | 経営・事業部門責任者 |
| RAG に入れる文書の選定基準 | 業務責任者・情報管理担当 |
| 利用ポリシーの策定 | 経営・法務・情報セキュリティ担当 |
| 配布・設定・認証管理の実装 | IT部門 |
Claude Desktop の社内展開は、ツールを入れることではなく仕事のやり方と情報管理の仕組みを更新することです。IT部門は設計と実装を担いますが、何を実現するかを決めるのはマネジメント側の仕事です。その判断を先送りにすることが、導入の失敗や形骸化の最大の原因になります。