「分析して」の一言を、会社の資産に
― Claude Desktop × SageMaker 連携PoCの記録（番外編）

はじめに ― チャットの答えは、翌週には消えている

「AIに聞けば分析してくれる」時代になっても、企業のデータ分析には根深い課題が残っています。Pythonが書けないと本格的な分析はできない。SageMaker Studio（AWSが提供する分析作業環境）やJupyterLab（ブラウザで動く分析ツール）の操作は、分析担当者にしか扱えない。そして何より、チャットで得た分析結果はその場で消えてしまい、会社の資産として残らない。翌週、別の担当者が同じ質問をすれば、また一から同じ分析をやり直しです。

そこで今回、次の仕組みが実現できるかをPoCで検証しました。

• 一般社員が、Claude Desktopに日本語で分析を依頼する
• 裏側でPythonが実行され、分析結果が返ってくる
• 同時に、Notebook・Pythonプログラム・レポート・グラフが成果物として自動保存される

結果だけ返すのではなく、「分析の過程」ごと資産として残す。これが今回のPoCの狙いです。

出発点の仮説 ― 「ClaudeがNotebookを直接触ればいい」

最初に立てた仮説はシンプルでした。Claude DesktopからSageMaker Studioに直接つなぎ、ClaudeがNotebookを開いて編集・実行すればよいのではないか、というものです。

先に結論を言うと、この仮説は成立しませんでした。ただし、その確認の過程で得られた発見が、最終的な設計の土台になりました。4つの検証を順に見ていきます。

4つの検証で分かったこと

検証1：SageMaker Studioの中でClaude Codeは動くか → 動いた

まず、SageMaker Studioの環境内にClaude Code（コマンド操作型のClaude）を導入し、Amazon Bedrock（AWS上でClaudeなどのAIモデルを利用できるサービス）に接続して動かしました。結果は良好で、Pythonの実行、Notebookの生成・編集、さらに「実行済みの状態のNotebook」の生成まで、すべて成功しました。

ここで得られた気づきが、後の方針を決めます。Notebookは「分析を実行するための環境」というより、「手順と結果が1つに記録された分析資産」として価値が高いということです。実行はどこで行ってもよい。大事なのは、再現可能な形で成果物が残ることでした。

一方で、率直な感想もありました。この構成で恩恵を受けられるのは、SageMaker Studioに入って作業できる人——つまり分析担当者だけです。Claude Codeは優秀ですが、このやり方ではコード作成のサポート役にとどまり、「一般社員が日本語で頼むだけ」という目指す姿には届かない、と感じました。ならば、Studioの中ではなく外から操作する道を探るしかありません。

検証2：AWS CLIからSageMakerを操作できるか → 操作できた

次に、コマンドライン（AWS CLI）からSageMakerの管理操作を試しました。認証には「aws login」——2025年11月に追加された、ブラウザの管理画面へのログインだけでCLIの認証が完了する新しい方式——を使い、環境情報（Domain・Space）の取得や設定変更まで問題なく行えました。SageMakerの「管理」は、APIやCLIから十分に操作できることが確認できました。

この結果から、次の仮説が生まれます。Claude DesktopにAWS CLIを操作させれば、目指す姿に近づけるのではないか。CLIで環境の管理までできるなら、あとはNotebookの中身まで手が届くかどうか——それを確かめたのが次の検証です。

検証3：Notebookの中身をAPIから直接操作できるか → 公式にはできない

ここが仮説の分かれ目でした。AWSの公式APIやCLIで操作できるのは、Domain・Space・Appといった「環境の箱」までです。Notebookの中身（セル）を編集・実行するための公式API/CLIは存在しませんでした。

厳密には、Jupyter標準の仕組みを使った回避策や、Notebookを丸ごとジョブとして実行する機能はあります。しかし「ClaudeがNotebookのセルを直接いじる」という設計は、公式にサポートされた道ではなく、本命にはなりにくいと判断しました。

検証4：Remote Accessは使えるか → 用途が違った

SageMakerのSpaceには「Remote Access」という接続機能があり、有効化にも成功しました。ただし調べてみると、これはVS Codeなどのエディタから開発者が接続するための公式機能であり、Claude Desktopをつなぐための入り口ではありませんでした。ここでも「直接つなぐ」道は閉じられます。

なぜMCPにたどり着いたのか

検証3と4で「Claude DesktopからSageMakerへ直接つなぐ」道が閉じたとき、改めて構図を整理しました。Claudeは言葉を扱うAI（LLM）であり、SageMakerはPythonの実行基盤です。性質の異なる両者の間には、依頼を「実行できる形」に変換して取り次ぐ仲介役が必要——そう考えると、答えは自然にMCPに行き着きました。

MCPは、AIと外部システムをつなぐための共通規格です。電源プラグの形が統一されているように、「AIから道具への接続口」を統一する仕組みだと考えてください。MCPサーバーという取り次ぎ役を1つ立てれば、ClaudeはSageMakerに限らず、データベースでもファイル保管庫でも、同じ作法でつなげます。

もう1つの発見は、この構成が画面の種類を選ばないことです。当初は「Cowork（非エンジニア向けのエージェント機能）では難しいのでは」と考えていましたが、調べるとCoworkもMCPを利用できます。本質はどの画面を使うかではなくMCPであり、Chat・Cowork・Codeは用途に応じて選べばよい、という整理になりました。

最終アーキテクチャ ― 全体像

たどり着いた構成が次の図です。企業利用を想定し、AIへの通信はゲートウェイ（社内の出入口サーバー）を経由してAmazon Bedrockに向かう形にしています。Claude DesktopをBedrock経由で使う構成は、現在は公式にサポートされています。

ポイントは、Claudeが「賢い頭脳」に徹し、実行はMCPの先のSageMakerが担う分業です。依頼した本人はPythonもAWSも意識しませんが、裏側では毎回、Notebook・Pythonプログラム・レポート・CSV・グラフが成果物として保存されます。

用途別の使い分け

すべての依頼が重い分析基盤を通る必要はありません。用途に応じて経路を分けます。

特に4行目の「定型分析」に注目してください。過去の成果物（Notebook）が残っているからこそ、「前回と同じ分析を、新しいデータで」が一言で頼めるようになります。成果物を残す設計は、ここで効いてきます。

最大の学び ― 「答えるAI」ではなく「資産がたまる基盤」

このPoCを始めたときの目的は「分析の自動化」でした。しかし検証を終えて明確になったのは、目指すべき姿がその先にあることです。

「分析結果を返すAI」は、その場では役に立ちますが、答えはチャットとともに流れていきます。一方、Notebook・Python・レポート・CSV・グラフを毎回成果物として残す仕組みは、使えば使うほど「会社の分析資産」が積み上がります。次の分析は過去の資産の再利用から始まり、分析の品質と速度が組織として向上していく。AIの導入効果を一過性で終わらせないための答えが、ここにあると考えています。

次のPoCで検証すること

今回のPoCで全体構成は固まりました。次のステップでは、実運用に向けて以下を検証します。

• MCPサーバーの構築と、SageMakerの分析ジョブ（Processing Job）の起動
• 成果物の自動保存（S3への標準保存、Git（変更履歴の管理システム）との連携）
• Snowflake・Redshiftなどのデータ基盤との連携によるデータ取得経路の確立
• ゲートウェイ経由での全社配布

まとめ

「ClaudeがNotebookを直接操作する」という最初の仮説は成立しませんでした。しかし、その検証の過程で「Notebookは実行環境ではなく分析資産である」という気づきを得て、MCPを軸にした現実的なアーキテクチャにたどり着きました。

PoCの価値は、仮説どおりに動くことを確認する点だけでなく、「成立しない道」を早く安く見極め、目指すべき姿を修正できる点にあります。自然言語での分析依頼を、その場限りの回答で終わらせず、企業の資産として蓄積していく——次回のPoCの結果も、本コラムで報告する予定です。