Bedrock 経由の Claude Code で使えない機能——導入前に整理すべき制限一覧

Bedrock 経由で Claude Code を動かすなら、Anthropic サブスクリプションと機能セットが異なることを前提に設計する必要がある。Auto Mode、Remote Control、Claude Code on the web——これらはいずれも公式ドキュメントが Bedrock を明示的に除外している機能だ。本記事は、導入判断や組織展開の前に確認しておきたい制限事項を、公式引用付きで一覧にまとめた。

IAM/CloudTrail 統合やデータガバナンスの観点から Bedrock を選ぶ判断自体は合理的だが、何を失うかを把握した上で選ぶかどうかが、展開後の運用コストを分ける。

Bedrock 経由で使えない機能——機能差の全体像

公式ドキュメントをもとにした機能差を表にまとめた。以降のセクションで各行を掘り下げる。

機能Bedrockサブスク根拠の種別
/login /logout コマンド✗◎◎ 公式直接引用
Auto Mode（permission mode）✗◎◎ 公式直接引用
Remote Control✗◎◎ 公式直接引用
Claude Code on the web✗◎◎ 公式直接引用
Dispatch（モバイルからタスク投入）✗◎○ 構造推論
Slack 連携✗◎○ 構造推論
Scheduled tasks（cloud 版 Routines）✗◎○ 構造推論
Converse API✗n/a◎ 公式直接引用
Prompt caching（全リージョン）△◎◎ 公式直接引用
Haiku モデル指定（全環境で確実）△◎◎ 公式直接引用
デフォルトのプライマリモデルSonnet 4.5Sonnet 4.6◎ 公式直接引用

◎ 公式直接引用 は Claude Code 公式ドキュメントに「Bedrock では不可」と明記された記述。○ 構造推論 は claude.ai サブスクの上に構築された機能であることから帰結するもので、公式ドキュメントが Bedrock 非対応と直接断言しているわけではない。この違いは後述する。

Auto Mode と Remote Control——claude.ai 認証が壁になる理由

Auto Mode は Anthropic 側で分類器を動かす仕組みだから

◎ Choose a permission mode（公式） に次の記述がある。

> Auto mode is available only when your account meets all of these requirements: > （Plan・Admin・Model の要件を省略） > - Provider: Anthropic API only. Not available on Bedrock, Vertex, or Foundry.

Auto Mode は、Claude がツールを実行する前に Anthropic 側のサーバーが「この操作は安全範囲か」を判定する分類器を動かす。分類器は Anthropic のインフラ上にあるため、Bedrock・Vertex・Foundry のような外部プロバイダ経由では起動しない構造になっている。

当ブログの Auto Mode 解説記事（2026-05-19）で扱った「93% acceptance rate」「17% false-negative」という安全性の数字は、この分類器があることで成立する。Bedrock 環境ではその前提がない。代わりに使えるのは default、acceptEdits、plan、dontAsk、bypassPermissions の5モードだ。acceptEdits はパーミッションプロンプトをスキップするが、安全判定はない。

Remote Control は claude.ai セッション管理への依存が深い

◎ Continue local sessions from any device with Remote Control（公式） のエラーリファレンスには次の記述がある。

> "Remote Control is not yet enabled for your account" > The eligibility check can fail with certain environment variables present: > - CLAUDE_CODE_USE_BEDROCK, CLAUDE_CODE_USE_VERTEX, or CLAUDE_CODE_USE_FOUNDRY: Remote Control requires claude.ai authentication and does not work with third-party providers.

Remote Control はスマホや別のマシンから手元の Claude Code セッションを継続できる機能で、claude.ai が短命クレデンシャルを発行してセッションをルーティングする基盤の上に立っている。Bedrock 環境では claude.ai 認証がそもそも成立しないため、この基盤に接続できない。

結果として Bedrock ユーザーは、外出先からローカルのセッションを継続することも、モバイルアプリの Code タブからセッション一覧を確認することもできない。Remote Control 単体の話ではなく、「外出先からの継続作業フロー全体」が対象外になる。

Web 版・Dispatch・Slack 連携——構造的に切り離されている機能群

Claude Code on the web は claude.ai 上で動く

◎ Use Claude Code on the web（公式） には次の記述がある。

> Claude Code on the web runs tasks on Anthropic-managed cloud infrastructure at claude.ai/code.

Bedrock 版 Claude Code はあくまでローカル端末で動く CLI だ。ブラウザからセッション起動・GitHub 連携 PR 自動作成・Auto-fix PR・並列タスク実行といった Web 版の機能群は、claude.ai の契約と紐づいている。Bedrock ユーザーが Claude Code on the web を使うには、別途 claude.ai のサブスクリプション（Pro/Max/Team または Enterprise の該当シート）を契約する必要がある。

Dispatch・Slack・Routines（cloud 版）は構造推論による帰結

Dispatch（モバイルアプリからローカルの Claude Code にタスク投入する機能）、Slack 連携（@Claude メンションで PR を作らせる機能）、Scheduled tasks の cloud 版（Routines のクラウド実行形式）の3つについては、公式ドキュメントに「Bedrock では不可」と直接断言した記述は見当たらない。

ただし、これらはいずれも claude.ai の認証・セッション管理・Anthropic クラウド基盤の上に構築されている。Bedrock 経由では claude.ai 認証が成立しないため、構造上使えないと帰結できる。公式の直接引用ではなく構造からの推論であることを、ここで明示しておく。

なお、ローカル起動型の claude --schedule "..." コマンドは Bedrock 環境でも動作する。「Scheduled tasks が使えない」というのは cloud 実行型（Routines）の話であり、CLI ベースのローカル定期実行は対象外だ。

Prompt caching のリージョン制限と Haiku フォールバックの落とし穴

リージョンによってキャッシュが無効になる

◎ Use Claude Code with Amazon Bedrock（公式） には次の記述がある。

> Prompt caching may not be available in all Bedrock regions.

Anthropic 直接 API では Prompt caching は全リージョンで利用できる（5分 TTL / 1時間 TTL）。Bedrock ではリージョンによって無効になる場合がある。

Claude Code は長時間セッションで同じ system prompt・tool 定義を再利用する。当ブログの Prompt caching 記事（2026-05-19）で解説したベストプラクティス（tool 定義固定・system prompt 不変・メッセージで状態更新）が、キャッシュ無効リージョンでは丸ごと効かなくなる。同じ作業に対して Anthropic 直と比べてトークンコストが大幅に膨らむケースが起き得る（Prompt caching が全く効かない場合、キャッシュヒット分のコスト削減がゼロになるため）。

展開リージョンを決める段階で、対象リージョンが Prompt caching に対応しているか確認しておいてほしい。

Haiku 指定が黙って無視される

◎ 同じく公式より:

> Background tasks such as session title generation use the small/fast model, normally a Haiku-class model. On Bedrock, Claude Code defaults this to the primary model because Haiku may not be enabled in every account or region.

Anthropic 直では --model claude-haiku-4-5-20251001 を指定すれば確実に Haiku が動く。Bedrock では、アカウントまたはリージョンで Haiku が有効化されていない場合、バックグラウンドタスク（セッションタイトル生成など）のモデルがプライマリモデル（Sonnet 4.5）にフォールバックする。明示的に ANTHROPIC_DEFAULT_HAIKU_MODEL を設定することで回避できる。

Haiku でコスト最適化する設計——/goal の評価器・Subagent の軽量タスク・大量バッチ処理——を組んでいると、実際には Sonnet で動いていてコストが想定の数倍になっていた、という事故が起き得る。AWS コンソールで Haiku のモデルアクセスを明示的に有効化して、CloudWatch で実際のモデル使用比率を監視しておいてほしい。

デフォルトモデルは1世代古い（2026-05-25 時点）

◎ 公式 amazon-bedrock docs に記載のデフォルトプライマリモデルは us.anthropic.claude-sonnet-4-5-20250929-v1:0（Sonnet 4.5）。Anthropic 直のデフォルトは Sonnet 4.6 だ。

--model を明示指定しなければ、Bedrock 側は1世代前のモデルで動く。最新モデルの性能を期待している場合や、Auto Mode の対応モデル要件（Sonnet 4.6 以上）を考慮している場合は、明示指定を忘れずに。デフォルトモデルは Anthropic・AWS どちらも随時更新するため、最新状態は公式ドキュメントで確認する。

それでも Bedrock を選ぶ組織の論拠と、現実的な運用パターン

Bedrock の強みは「AWS の傘下に入ること」

公平のため、Bedrock 経由の長所を整理しておく。

  • IAM と CloudTrail によるアクセス制御・監査証跡
  • AWS リージョン内に閉じたデータフロー（データガバナンス要件を満たしやすい）
  • 既存の AWS Enterprise Discount Program・コミット消費に組み込める
  • VPC エンドポイント経由のプライベート接続
  • AWS Marketplace 経由の調達（セキュリティ審査・購買フローが整備済みの組織に有利）

上記の要件を持つ組織——特に金融・医療・公共といった規制産業——にとっては、Auto Mode や Remote Control を失うコストを超えるメリットがある。

現場で見られる3通りの分け方

組織の規制要件と開発速度のバランスによって、実際の展開パターンはおおよそ3通りに落ち着く。

Bedrock 一本（エンタープライズ規制重視） は、全員 Bedrock で統一し claude.ai サブスクは契約しない形だ。Auto Mode・Remote Control・Web 版は使えない前提で、PreToolUse Hooks・CLAUDE.md・managed settings を厚く設計して補う。安全チェックは人手のレビューと組織ルールで代替する。

サブスク一本（個人・スタートアップ） は、全員 Anthropic Pro/Max/Team を契約する。Auto Mode・Remote Control・Web 版をフルで使えるが、AWS との直接的なデータパス連携は薄い。コンプライアンスは Anthropic の SOC 2 / HIPAA / BAA に依存する。

Dual 運用（規制部署＋一般エンジニア） は、規制対象部署（金融・医療系チーム）を Bedrock、一般エンジニアを Anthropic サブスクと使い分ける。同じ組織内で認証フローが2系統になるため、CLAUDE.md は両方の環境で動作するよう書く必要がある。機能差を組織が許容する前提で、実際に多く見かけるパターンだ。

どれが合うかは「どの機能を諦められるか」ではなく「どの制約条件が優先されるか」で決まる。規制・調達・データガバナンスが先に立つなら Bedrock 軸、開発速度と機能の完全性を取るならサブスク軸だ。

まとめ

Bedrock 経由の Claude Code は、公式ドキュメントが明示的に除外している機能だけで Auto Mode・Remote Control・Web 版・/login//logout がある。加えてリージョンによる Prompt caching の制約、Haiku フォールバックの黙認、デフォルトモデルの世代差が重なる。

Auto Mode や Remote Control を将来的に使う可能性があるなら、その判断を今どこかに残しておいてほしい。Bedrock 一本で進めるか、Dual 運用を視野に入れるか。要件が変わった時点で再評価できる状態にしておくことが、展開後の運用コストを変える。

参考

コメント

タイトルとURLをコピーしました