- 第1回：導入 ― なぜ・何を目指すか
- 第2回：設計 ― データを外に出さない仕組みをつくる（本記事）
- 第3回：効果 ― 分析が資産に変わる
まず、守るべき「境界」は2本ある
設計の全体像は、たった一枚の見取り図に収まります。社員が触れるフロント（アプリ）から外へ向かう線が2本あり、その2本ともを自社の管理下に引き戻す。これがこの設計のすべてです。
- 境界①：アプリ ↔ 推論エンジン。AIが「考える」ときの宛先です。ここを提供元のサーバーから自社のAWS内（Bedrock）に差し替えれば、会話も成果物も外に出ません。
- 境界②：アプリ ↔ データ基盤。AIが「読む・書く」データの通り道です。ここは「どのデータに、どこまで触れさせるか」を別途決める必要があり、この設計の実質的な肝になります。
境界①は、第1回で触れた"エンジンの載せ替え"で閉じます。境界②は、後半の「管理者の前準備」で、データ基盤ごとに作り込みます。順に見ていきます。
境界① ― 推論を自社内に閉じる「載せ替え」
フロントには Claude のデスクトップアプリをそのまま使い、推論の宛先だけを Amazon Bedrock に向けます。これにより、Bedrock 経由で動く Claude の会話・成果物は提供元（Anthropic）に渡らず、自社のAWSアカウントの中で処理されます。第1回で述べたデータ主権が、ここで技術的に担保されます（この前提は Bedrock／Vertex での利用に関するもので、他社基盤では扱いが異なる場合があります）。
認証の入り口は、大きく3通りあります。全員で同じ鍵を使う方式（共通キー）、普段の AWS プロファイルに載せる方式、そしてアプリ内で会社のログイン（IAM Identity Center）にサインインする方式です。どれを選ぶかは、次の「配布方式」の議論と直結します。
境界の手前で ― 社員にどう配るか（図1）
仕組みができても、社員の手元に届かなければ意味がありません。少人数で始める前提なら、社員側の作業は「アプリを入れる」「設定ファイルを当てる」の二つに畳めます。設定ファイルは接続先などを固定し、社員が中身を変えられないようにする役割を持ちます（管理者が固定した設定は上書きされません）。
配り方は大きく二系統、五つの方式に分かれます。図1にまとめました。
ふたつの系統は、次のように住み分けます。手元のパソコンで使う系統（A）では、設定ファイルに認証情報をどう持たせるかで性格が変わります。全員共通の鍵を配る②は最も手軽ですが、誰が使ったかの記録は残りにくい。一方、社員がふだん使う会社ログインに載せる③は、誰がいつ使ったかの記録が残る——手軽さと引き換えに統制が効きます。もうひとつのクラウド上の仮想パソコンで使う系統（B）は、アプリもデータも手元の端末に一切残らないのが特長です。ただし常時コスト（④）や毎回の接続というひと手間（⑤）が乗ります。「端末に何も残したくない」を最優先するならクラウド、手軽さを重視するなら手元PC、という住み分けです。
配布前の準備（管理者）― 五つの土台（図2）
社員が"アプリと設定ファイルだけ"で使えるのは、その裏で管理者が土台を整えているからです。準備は五つに整理できます。図2にまとめました。
認証は「既存の会社ログイン」に載せる
認証は、新しい仕組みをゼロから作るのではなく、すでに社内にある会社ログイン（IAM Identity Center）に載せるのが筋です。Bedrock を呼び出すための権限セットを作り、対象の少人数グループに割り当てる。ここで一点、事前に確認しておく宿題があります——機械学習基盤（SageMaker）のドメインが、この会社ログインの管理下に置かれているか。ここが揃っていないと、後の接続で手戻りが出ます。加えて、実際に配る端末が Windows 中心なら、Windows と会社ログインを組み合わせる手順を先に固めておくと、配布がスムーズです。
接続まわりの"非対称"を、経営として見込んでおく
ここが、経営として最も押さえておくべき点です。同じ「データ基盤につなぐ」でも、Snowflake と SageMaker では難易度が対称ではありません。
データ基盤の Snowflake には、公式のマネージド接続が用意されています。データは Snowflake の中に留めたまま、必要な問い合わせだけをAIに開く——という、いわば"きれいな正解"（既製品）があります。Cortex Analyst（自然言語を SQL に変える機能）などをツールとして安全に公開でき、これは一般提供（GA）されています。
一方、機械学習基盤の SageMaker には、Snowflake のような"提供元がホストするマネージド接続"がまだありません。オープンソースの接続部品（awslabs 提供のもの）は登場しましたが、現時点では高性能計算クラスタ（HyperPod）の管理が中心で、用途が限られます。そのため当面は、AIに指示書きのコードを書かせて学習を起動する（SDK直起動）のが現実的な本命となります。同じ「つなぐ」でも、片方は既製品、片方は作り込みが要る——この非対称を最初から見込んでおくと、工数の見積もりを誤りません。
全体を「境界」と「監査」で締める
そして全体を通じて、守りを固めます。通信を社内ネットワークに閉じ（VPCエンドポイント）、外部への運用メタデータを停止し、呼び出しの記録を残す（CloudTrail などの監査ログ、CloudWatch への可観測性）。これらの結果を一つの設定ファイルにまとめ、前半で見た配布（図1）へ渡す——というのが全体の流れです。
テレメトリ（運用メタデータ）を、どう扱うか
最後に、第1回で予告したテレメトリの扱いを具体化します。繰り返しになりますが、会話や成果物は外に出ません。既定で外に出るのは、利用状況やエラー情報といった運用メタデータ（集計値で、分析データの中身は含まない）だけで、これは設定で完全に停止できます。
ここで大事なのは、停止するかどうかの判断軸です。これは情報漏洩リスクの問題ではありません。中身を含まないメタデータなので、止めてもデータ保護の水準は基本的に変わらない。判断の本質は、社内規程や対外説明として運用メタデータの送信を許容するかという、コンプライアンス上の要請にあります。なお、テレメトリを止めても、アプリの動作に必要な通信（起動時の実行環境の取得など）は残ります。「外部通信ゼロ」とは言い切れない点は、対外説明の際にご注意ください。したがって現実的には、まず既定のまま少人数で始めて動作を確認し、本格展開の段階でコンプライアンス要件に合わせて停止する——という段階運用が取りやすい形です。
まとめ ― 「安全」と「簡単」は、設計で両立する
第2回で見たのは、社員にとっての"簡単"（アプリと設定ファイルだけ）が、その裏にある管理者の作り込み（推論の載せ替え・認証・接続・境界・監査）に支えられている、という構造でした。境界は2本。①はBedrockへの載せ替えで閉じ、②はデータ基盤ごとに作り込む。そしてSnowflakeとSageMakerの非対称を見込んでおくこと——これが設計の要点です。
ここまでで、社員はデータを外に出さずに、手軽に分析できるようになりました。しかし、それだけでは"回答が返ってくるだけ"で、分析の成果が組織に残りません。第3回では、この最後のピース——分析を組織の資産に変える設計を見ていきます。