1. はじめに
最近、Yes!東京 で「わびさびニキ」が気になっているmakowareです。
先日、担当しているプロジェクトでClaude Codeが使えるようになり、デフォルトでどんな設定がされているのかなと、何気なく /config を叩いてみました。
設定画面を眺めていたところ、API Providerの欄に「Amazon Bedrock」と表示されているのに気づきました。
自分の中でBedrockといえば、LambdaなどのAWSサービスからLLMを呼び出すための基盤みたいな印象で、Claude Codeのようなローカル環境で使う開発ツールとはあんまり結びついていませんでした。
普段ClaudeをProプランで使っていて、エンタープライズではてっきりTeamとかEnterpriseプランとかだろうと思っていたところ、実際はBedrock経由で、なぜTeamプランではなくBedrockなのかなと思い、これを機にBedrockの基本の「き」くらいは知っておこうと思いました。
調べてみると、Bedrockというより、Claude Code自体が「ストレージ・メモリ・推論・権限・アクション」という構造を持つある種ハーネス(=モデルを動かす環境そのもの)なんだなと分かってきて、何気なく使っているツール呼び出しの裏側の解像度が少し上がりました。
この記事では、Bedrockの触りの部分とClaude Code自体がハーネスだよねっていうことを備忘する記事です。
この記事で (きっと) わかること
- Amazon Bedrockとは? 基本的な概念
- Claude Code・Bedrock・Anthropic APIが実際にどう繋がっているか
- Claude Codeを構成するハーネス(ストレージ・メモリ・推論・権限・アクション)
- Claude Codeのツール呼び出しがどこで実行されているか
余談; 使っているClaude Codeモデルや設定
この記事内の表や図、なんなら記事本文の骨格はClaude Codeで書いてます。
自作でrulesやskillsを作成して半自動化しています。
modelに関しては、executorをSonnet 5、advisorでOpus 5にしていて、effortは基本xhighで動かしてます。
現行modelに関する検証は以下記事を参照しています。(体感でも普段使いはSonnet 5で十分かなと思ってます)
2. Bedrockってなに?
Amazon Bedrockとは、複数のAI企業が提供する基盤モデルをAPI経由で利用できるフルマネージドサービスとのことです。Claude(Anthropic)、Llama(Meta)、Nova(Amazon)など性質の異なるモデルを、単一のAPI・単一の請求・単一のIAM権限体系でまとめて呼び出せる点が、このサービスの核心的な価値だそうです。
基本構造は次の4点に整理できます。
- モデルをホストするインフラはすべてAWSが管理する(サーバー管理は不要)
- 呼び出しはAPI(SDK/CLI/HTTP)経由で行う
- 認証はSigV4(AWS標準の署名方式)またはBedrock APIキーを使う
- 課金は基本的にトークン従量課金
主な機能をClaude Codeにまとめてもらいました。
| 機能 | 内容 |
|---|---|
| 推論(Inference) | InvokeModel・Converseなどの推論APIでモデルにプロンプトを投げる |
| Guardrails | 有害コンテンツフィルタ、PII検出など |
| Knowledge Bases | RAG構築(S3等のデータをベクトル化して検索拡張) |
| Agents | ツール呼び出しを伴う自律的タスク実行 |
| AgentCore | エージェントを本番運用するためのランタイム/ゲートウェイ/認証などの基盤群 |
3. 実例1; boto3で呼び出す
概念を掴んだところで、実際にどう呼び出すのか最小構文をClaude Codeにつくってもらいました。
import boto3
import json
client = boto3.client("bedrock-runtime", region_name="ap-northeast-1")
response = client.invoke_model(
modelId="anthropic.claude-sonnet-4-5-20250929-v1:0",
body=json.dumps({
"anthropic_version": "bedrock-2023-05-31",
"max_tokens": 1000,
"messages": [{"role": "user", "content": "こんにちは"}]
})
)
result = json.loads(response["body"].read())
boto3.client() を作った時点で、SDKが裏側でIAM認証情報(Lambda実行ロールなど)を拾い、リクエストごとに自動でSigV4署名を行います。
CLIから叩きたい場合も aws bedrock-runtime invoke-model ... で同じことができます。
Lambdaからモデルを呼ぶときは、モデル一覧を取る bedrock クライアントより、この bedrock-runtime の invoke_model/converse を使う場面が多く、管理系の呼び出しはコンソール操作かIaC構築時に触る程度みたいです。
4. で、何でTeam planじゃなくてBedrockをバックエンドにしているの?
Claude Codeのログイン画面は「Anthropicホスト(Pro/Max、Team/Enterpriseプラン)」と「3rd-party platform(Bedrock、Vertex AI)」に分かれています。
コスト・セキュリティ・ガバナンスの3軸で比較すると、こんな感じです(Enterprise deployment overviewより、価格は執筆時点)。
| 観点 | Claudeネイティブ(Team/Enterprise) | Bedrock |
|---|---|---|
| コスト | シート課金($150/seat、PAYGオプションあり)。Claude on web込み | AWS請求に従量課金で統合。Claude on webは含まない |
| セキュリティ | Claude.aiアカウントのSSO・メールログイン | 既存のIAMロール・AWSクレデンシャルをそのまま使える |
| ガバナンス | チーム管理・利用状況ダッシュボード | IAMポリシー・CloudTrailで監査を一元化 |
すでにAWS環境にどっぷり浸かっている場合、Bedrockのメリットが刺さるのかなと思います。
5. Claude Code・Bedrock・Anthropic APIの全体構成
Claude Codeは実際どこに位置していて、Bedrockとどう繋がっているのか。
Claude CodeにAnthropicの一次情報を参照させながら、壁打ちして整理した図がこちらです。
図の中で1つのノードとして表していた「Claude Code」を、さらに分解してみます。
永続化されたデータ・作業用メモリ・演算・アクセス制御・実行系という、汎用的なコンピュータアーキテクチャの比喩に当てはめると少し理解しやすくなります。
Skillsってなに?MCPってなに?Subagentsってなに?どんな感じでつくるの?は以下拙書も参考になるかと思います。
クロちゃんと学ぶClaude Code ─ 第1部:全体像
有名な概念に、
AIエージェント = モデル + ハーネス
というものがあります。
私(たち)が日々せっせとチューニングしているrulesやSkillsも、Claude Code側の組み込みツール・システムプロンプトも、広義にはこのハーネスに含まれます。
Anthropic APIやBedrockは、ハーネスがモデルを呼び出すための経路(推論API)としての役割です。
6. ツール実行はどこでされているの?:サーバーサイド vs クライアントサイド
Claude Codeが呼び出すツールには「組み込みツール」「MCPツール」があると整理しました。ではこれらのツールは、実際どこで実行されているのでしょうか。
Bedrockのツール呼び出しには、実行場所の異なる2種類があります。
| クライアントサイド | サーバーサイド | |
|---|---|---|
| 実行場所 | 自分のアプリ | Bedrock/モデル提供元のインフラ |
| 対象 | 自社DB、社内API、独自ロジックなど | Web検索など汎用的で提供元が用意できるもの |
| 実装の手間 | ツール実行コードを自分で書く | 設定するだけ(コード不要な場合も) |
| 対応エンドポイント |
bedrock-runtime/bedrock-mantle両方 |
bedrock-mantleのみ |
クライアントサイドツールは、モデルが「このツールをこの引数で呼びたい」というリクエストを返すだけで、実際にツールを実行するのは自分のコード側です。
サーバーサイドツール(Web検索など)は、モデル提供元のインフラ側で実行まで完結します。社内のAthena/S3データを検索してから回答させたいケースは、Bedrock側がそのデータの存在を知らないため、クライアントサイドツールにならざるを得ません。
これもClaude Codeに図示してもらいました。
クライアントサイドは「実行→結果を返す」という往復が呼び出し側に発生するのに対し、サーバーサイドはモデル提供元の中で完結し、呼び出し側はコード不要という違いが読み取れます。
Claude Codeが使うツール(ファイル編集・bashコマンド実行・grep検索など)は、基本的にクライアントサイドツールに分類されます。(WebSearchはAnthropicのインフラで実行されるみたいです)
モデルは「このファイルを編集したい」/「このコマンドを実行したい」と判断して、ツール呼び出しリクエストを返すだけで、実際にファイルシステムを操作したりコマンドを実行したりするのは、手元で動いているClaude Code CLIプロセス自身です。
Claude Codeはローカルのファイルシステムにアクセスする必要があり、AWSやAnthropicのインフラ側には対象のローカルファイルが存在しません。
だからサーバーサイドで完結させようがなく、常にクライアントサイド、つまり手元のCLIプロセスが実行主体になります。
7. まとめ
/config の画面に表示された「Amazon Bedrock」の一行から始まった簡単な調査でしたが、AIエージェントへの理解を少し深めることができました。(Bedrock自体からはだいぶ逸れてしまいましたが、、)
これがすぐに実務に直結して役立つかというと、はてなマークですが、こうして仕組みや構成を見ていくのもきっといつかどこかで役立つでしょう。