なぜ「1+1」なのか ― 気軽に確かめたかった
前回の記事では、Claude Desktop・Bedrock・MCP・SageMakerを組み合わせた最終アーキテクチャを描きました。ただ、絵にした構想がそのまま動く保証はありません。本番用のMCPサーバーを作り込むには相応の手間がかかります。その手前で、そもそもの一点だけ先に確かめたくなりました——「手元のClaudeから、AWSのSageMakerに実際に計算をさせられるのか？」。
大がかりな分析でいきなり試すと、うまくいかなかったときに原因の切り分けが大変です。そこで、成否がひと目で分かる世界一小さな計算「1+1」を題材にしました。答えが「2」で返ってくれば経路は通っている、来なければどこかで詰まっている——それだけの、気軽な実験です。
やったこと ― Claudeにコマンドを実行させるだけ
Studioの画面（Notebook）は一切開いていません。今回は手軽さを優先し、Claude Desktopの画面ではなく開発向けのコマンドライン版のClaudeを使いました。手元のClaudeに、AWSを操作するコマンド（AWS CLI）を通じて、SageMakerに使い捨ての計算ジョブ（Processing Job）を発注させただけです。渡した命令は、Pythonでたった一行です。
print("1+1 =", 1+1)
あとは、ジョブの発注 → 実行の見守り → 結果ログの回収、という3ステップをClaudeに順にこなしてもらうだけです。数分待つと、実行ログにこう出ていました。
SageMakerが計算し、答えの「2」が手元のClaudeまで返ってきました。「手元のClaude → AWS → SageMakerで実行 → 結果が戻る」という往復が、確かに成立することを確認できた瞬間です。
うれしい誤算 ― 後始末がいらない
前回の記事では、PoC後に消し忘れたリソースが課金を生む点を気にしていました。ところが今回使ったProcessing Jobは、実行が終わると計算用のマシンが自動で消える使い捨ての仕組みです。つまり「止め忘れ」が構造的に起きません。今回の費用は、この1回でおよそ1円未満でした。
| 項目 | 結果 |
|---|---|
| やったこと | 手元のClaudeにSageMakerで「1+1」を計算させる |
| 出力 | 1+1 = 2（実行ログに出力、手元まで回収） |
| 所要時間 | 発注から結果回収まで約5分（うち計算は約2分） |
| 費用 | 約1円未満。マシンは実行後に自動消滅、消し忘れなし |
| Studioの操作 | 不要（Notebook画面は一度も開いていない） |
今回のPoCでは ― まだBedrock経由ではない
前回の理想図では、社員が使うClaudeの頭脳をAWS上のBedrockに置く形にしていました。企業利用では、推論を自社の管理下（AWS）で回せることが重要だからです。
一方で今回の最小実験は、手軽さを優先した「最短ルート」でした。実際にAWSの記録（CloudTrail）で確認したところ、今回の経路でBedrockは一度も呼ばれていません。つまり——
- 指示（AIの判断）：Anthropic側の推論で生まれた（＝まだBedrock経由ではない）
- 実行：AWS CLI から SageMaker へ（ここは自社のAWS内で完結）
言い換えると、「実行させられるか」は確認できたが、「頭脳をBedrockに載せる」ところはこれから、という現在地です。ここを飛ばして「もう理想どおり動いた」と書くのは不正確なので、区別して残しておきます。
肝心なところ ― Claude Desktopは「そのまま」だと窓口になりません
ここが企業利用でいちばん大事な注意点です。前回の図では Claude Desktop を「ただの窓口（UI）」として描きましたが、アプリを入れて何も設定しなければ、Claude Desktopは標準でAnthropicに接続します。つまり、社員が打ち込んだ指示も、返ってきた回答も、Anthropic側で処理される——これが初期状態です。「窓口」にするには、ひと手間が必要なのです。
やり方 ― 会社の端末管理で「接続先」を配る
難しい話ではありません。要は「社員のPCのClaude Desktopに、会社の接続先を上書き配布する」だけです。個々の社員が手で設定するのではなく、情報システム部門がまとめて配ります。手順を分解すると3つです。なお、この設定方法はAWSの公式解説で公開されているものにもとづきます（記事末尾の参考にも掲載）。
| ステップ | やること | ねらい |
|---|---|---|
| ① 接続先を上書き | 端末管理ツール（Intune・Jamf・グループポリシー等）から、推論の宛先を「自社のBedrock」に指定した設定を配布する（使うモデル・リージョン・認証方式を含む） | 頭脳をAnthropicから自社AWSへ移す |
| ② 出入口を一本化 | 必要に応じてゲートウェイのURLを指定し、全社の通信をそこに集約する | 認証・ログ・コストを一元管理 |
| ③ 抜け道をふさぐ | 社員が勝手に設定を戻せないよう固定し、社外への動作記録の送信もオフにできる | 「窓口」から外れるのを防ぐ |
この3つを配って初めて、Claude Desktopは「送って受け取るだけの窓口」になり、指示も回答も自社のAWS（Bedrock）の中で処理されるようになります。逆に言えば、この設定を省くと——たとえ画面が同じでも——中身は社外に出ます。「Desktopを配れば安全」ではなく、「接続先を会社が設定して初めて安全」。ここは企業導入の分かれ目です。
この小さな成功が意味すること
「1+1」はおもちゃのような題材ですが、確認できたことは小さくありません。前回の最終アーキテクチャでいう下半分——「実行 → SageMaker → 結果が戻る」の部分が、実際に動くことを証明できました。
しかも、今回Claudeにやらせた3ステップ（発注 → 見守り → 結果回収）は、そのまま次に作るMCPサーバーが自動でこなす処理の下書きになります。人が手でCLIを叩く代わりに、この一連をMCPの「道具」として包めば、前回描いた構想にぐっと近づきます。前回の記事で「Notebookのセルを直接操作する道」が公式には閉じていた件も、Processing Jobという正規の実行手段で代替できることがはっきりしました。
次の一歩
- 頭脳をBedrockへ：今回Anthropic側だった推論を、Bedrock経由に切り替える（企業利用の前提を満たす）
- MCPサーバーで包む：今回の「発注→見守り→回収」をMCPの道具にして、Claudeから自然言語で呼べるようにする
- 「1+1」を本物の分析へ：一行の計算を、実データの集計・可視化と、成果物のS3保存に差し替える
大きな構想も、最初の一歩は「1+1」で十分でした。次は頭脳をBedrockに載せ替えるところから進めます。その結果も、また本コラムで共有する予定です。