シリーズ「社外に出さないAI ― Claudeデスクトップで始める、統制されたAI活用」（全3回）
  1. 第1回：導入 ― なぜ・何を目指すか（本記事）
  2. 第2回：設計 ― データを外に出さない仕組みをつくる
  3. 第3回：効果 ― 分析が資産に変わる
この記事の要点：社員にAIで分析させたい。だが二つの壁があります。ひとつは分析対象のデータが社外に出てしまうこと、もうひとつはAIの出した答えが個人のチャット履歴に溶けて組織に何も残らないことです。本シリーズは、この両方を同時に解く設計を経営の視点から追います。鍵は、使い慣れたデスクトップアプリの操作感はそのままに、その"頭脳"にあたる推論だけを自社のクラウドへ移すこと。第1回では、目指すゴールを安全・簡単・蓄積の三点として定義し、その大前提である「なぜ自社内にこだわるのか（データ主権）」を明示的に書き起こします。（機能・仕様は変わりやすいため、記述は執筆時点＝2026年7月の情報にもとづきます。）

はじめに ― AI活用が加速するいま、現場に現れた二つの壁

生成AIを「試す」段階は、多くの企業でとうに終わりました。いまや問いは「使うかどうか」ではなく、「業務にどう根づかせ、統制のもとで安全に広げるか」に移っています。とりわけ、社内にあるデータを社員がAIに読ませて分析させる——ここに踏み込もうとした瞬間、経営として避けて通れない二つの壁が現れます。

ひとつ目はデータの壁です。分析させたいデータは、たいてい会社の一番大事な資産——顧客情報、取引履歴、会員データそのものです。それを一般的なAIサービスにそのまま読ませれば、分析対象のデータが社外のサーバーを経由することになる。「便利だから」で済ませてよい話ではありません。

ふたつ目は資産化の壁です。仮にデータの壁を越えて分析できたとしても、AIが返した答えは個人のチャット履歴の中に流れ、消えていきます。同じ問いを別の人がまた一から尋ね、担当者が異動すれば知見ごと失われる。AIの利用料だけが積み上がり、組織には何も残らない——これでは「使わせて終わり」です。

本シリーズが扱うのは、この二つの壁を個別の運用ルールでなく、設計そのもので越える方法です。結論を先に言えば、両方とも設計で押さえられます。そのための最初の一歩が、フロントの選び方にあります。

構想 ― デスクトップアプリの「頭脳」だけを自社に移す

本シリーズが提案する構想の中核は、シンプルです。社員が触れるフロントには、Claude のデスクトップアプリをそのまま使う。ただし、AIが実際に考える「推論」の宛先を、提供元のサーバーではなく自社のAWS内（Amazon Bedrock）に差し替える——これだけです。

車にたとえると分かりやすい。車体（＝日々の操作感）はそのままに、エンジンだけを自社ガレージのものに載せ替えるイメージです。運転席の座り心地もハンドルの効きも変わらないのに、動力源は自分の敷地内にある。社員から見れば「いつものアプリで日本語で頼むだけ」なのに、その裏側で、会話の内容も分析の成果物も提供元には渡らず、AWSの境界の内側に留まる。使い勝手を一切犠牲にせずに、データの通り道だけを自社内に引き戻せるのが、この載せ替えの妙です。

そのうえで、社内のデータ基盤（Snowflake）と機械学習基盤（SageMaker）にアプリを接続し、社員が"データを外に出さずに"分析できるようにする。ここまでが全体像です。技術的にどう実現するかは第2回で、そして分析結果をどう組織に残すかは第3回で、順を追って見ていきます。

ゴール ― 「安全・簡単・蓄積」の三点

設計に入る前に、この取り組みが目指すゴールを一文で固定しておきます。社員が、社外にデータを出さずに、デスクトップアプリで手軽に分析でき、その知見が組織資産として残る環境をつくる——これです。ここには三つの要素が入っています。

  • 安全（データ境界）。会話も成果物も分析データも、自社の管理する境界の外に出さない。
  • 簡単（使い慣れたUI）。社員の作業は「アプリを入れる」「設定ファイルを当てる」程度に畳み、特別な訓練を要らなくする。
  • 蓄積（成果の資産化）。一度の分析を、探して再利用でき、後から再現・検証もできる形で組織に残す。

ここで強調しておきたいのは、この三つを同時に立てるからこそ設計が要る、という点です。単に「楽に分析させたい」だけなら、ここまで作り込む必要はありません。既製のサービスを配れば済みます。楽さと引き換えに統制を手放してよいなら、話は簡単なのです。しかし、楽さ（簡単）と安全（データ境界）と蓄積（資産化）を一度に成り立たせようとした瞬間、既製品の組み合わせでは足りなくなる。だからこそ、経営として設計に関与する意味が生まれます。

なぜ「自社内」にこだわるのか ― データ主権という論点

ここで、多くの検討で暗黙のまま飛ばされがちな問いを、あえて正面から立てます。「そもそも、なぜ推論を自社内に閉じ込める必要があるのか」です。この動機がはっきりしないと、第2回で見る作り込み（配布・認証・境界）の必然性が弱くなってしまいます。

理由は、扱うデータの性質にあります。冒頭で触れたとおり、社員に分析させたいのは会社の中核データ——顧客・取引・会員の情報です。一般的なクラウドAIでこれを分析すれば、入力した内容が提供元の環境を通ります。多くのサービスは「学習には使わない」と明言していますが、それでもデータが自社の管理外の経路を一度通るという事実は残ります。取引先や監督官庁に「当社の顧客データは、分析の過程でも一切社外を経由しません」と言い切れるかどうか——これは利便性とは別次元の、経営としての説明責任の問題です。

この構想が推論を Amazon Bedrock に載せ替えるのは、まさにここに効きます。Bedrock 経由でClaudeを使う場合、会話の内容も分析の成果物も、Anthropic（提供元）には渡りません。推論はあくまで自社のAWSアカウントの中で行われ、データは境界の内側に留まる。「便利さのために説明責任を諦める」のではなく、「便利さを保ったまま、データの主権を自社に取り戻す」——それがこの載せ替えの本質的な狙いです。

留保：「会話・成果物が提供元に渡らない」というこの前提は、Amazon Bedrock や Google Vertex 経由での利用を指します。他社基盤（Azure 系など）では扱いが異なる場合があるため、採用する基盤ごとに個別の確認が必要です。本シリーズはAWS（Bedrock）を前提に進めます。
ひとつだけ、正確に。会話や成果物は外に出ませんが、既定では、アプリの「運用メタデータ」（利用状況やエラー情報などの集計値で、分析データの中身は含みません）だけは提供元に送られます。これは設定で停止できます。ただし停止しても、アプリの動作に必要な通信（起動時の実行環境の取得など）は残るため、「外部通信が完全にゼロになる」わけではありません。停止するかどうかは情報漏洩リスクの問題ではなく、社内規程や対外説明として運用メタデータの送信をどう扱うかという、コンプライアンス上の判断です。この扱いは第2回で具体的に触れます。

この先の見取り図

第1回では、目指すゴール（安全・簡単・蓄積）と、その大前提となるデータ主権の考え方を確認しました。ここから先は、二本の柱で構成します。

  • 第2回：設計 ― データを外に出さない仕組みをつくる。推論を自社内に閉じる仕組み（Bedrock）、社員への配布方式（手元PCとクラウドの選択肢）、そしてその裏で管理者が整える五つの前準備（認証・データ基盤／機械学習基盤との接続・境界・監査）を、図とともに具体的に見ます。
  • 第3回：効果 ― 分析が資産に変わる。デスクトップアプリの推進が、なぜ分析の資産化を可能にするのか。一度の分析を「探せる・再現できる」記録として残す具体例を挟み、AI支出が「費用」から「資産」へと位置づけを変える経営的な意味を論じます。

AIを「使わせて終わり」にしないために。安全に・簡単に・残る——この三点を設計で同時に立てる道筋を、次回から具体的に描いていきます。