Bedrock 調査の記録: なぜそうなるのか

最初の見立て

Bedrock は Anthropic のサーバーへ転送する窓口で、少し機能が遅れて届くだけだろう。

原典で確かめたこと

• AWS の文書では、モデル提供元から渡された推論用と学習用のソフトウェアを AWS が丸ごと複製し、リージョンごと・提供元ごとの専用アカウント(Model Deployment Account)に置いて AWS が運用する。Anthropic はそのアカウントに触れない。
• つまり Bedrock の Claude は「Anthropic に転送される」のではなく、「AWS の中で動いている別のコピー」。Anthropic 側の文書も、推論基盤に Anthropic の社員がアクセスできない(zero operator access)と書いている。
• Claude Code の機能比較では、Bedrock の欄で WebSearch・Remote Control・クラウドセッションが Not available。これらはモデルではなく Anthropic のサーバー側のサービス(検索の実行、会話の保存と同期)で成り立っている。「複製されないから使えない」という理由そのものは両社の文書に書かれていないが、文書から読み取れる構図はそうなる(なお AWS 自身は bedrock-mantle で Web 検索を含む独自のサーバー側ツールを提供していて、Claude のモデルカードにはそれが載っていない)。

最初の見立て

bedrock-mantle は新しいモデル専用の新基盤で、旧来の bedrock-runtime は型落ち向け、と読める名前の付け方。

原典で確かめたこと

• AWS の Endpoints の文書は、裏で動く推論エンジンは1つ(AWS はこれを Mantle と呼ぶ)で、bedrock-runtime と bedrock-mantle はそこへ入る2つの入口だと説明し、「bedrock-mantle という名前は入口を指すもので、別の推論エンジンではない」と明記している。
• bedrock-runtime は AWS の推奨で、Claude には InvokeModel・Converse・Messages の3つの形式で送れる。Guardrails・Knowledge Bases などの Bedrock の機能はこちらでだけ使える。
• bedrock-mantle は Anthropic の API と同じ形のまま使う入口で、サーバー側ツールや background inference などの「Mantle だけの機能」がある代わりに、Bedrock の周辺機能は使えず、IAM の権限名(bedrock-mantle:)もクォータも別枠。

最初の見立て

検索できないなら、新しい脆弱性情報や最新のドキュメントは参照できず、知識が凍る。

原典で確かめたこと

• 止まるのは WebSearch(検索エンジンに問い合わせる Anthropic 側のサービス)だけで、WebFetch(URL を直接取りに行く)は Bedrock でも使える。URL さえわかれば、公式ドキュメントや RFC を取って読める。
• ただし WebFetch は取得前の安全確認で、ホスト名(URL 全体や中身ではない)を api.anthropic.com に送る。これは Bedrock でも行われるので、閉じたネットワークでは通信を許可するか skipWebFetchPreflight を設定する必要がある。
• 確認なしで取りに行けるドメインは管理設定の permissions.allow で指定でき、それ以外は都度確認になる(allowManagedPermissionRulesOnly で利用者が「常に許可」を足せなくできる)。ただし deny に WebFetch(domain:*) を書くと allow が全部無効になる。deny → ask → allow の順で評価され、allow で例外は作れない。

最初の見立て

AWS に来るのは一世代前のモデルだけで、東京はさらに遅れる。

原典で確かめたこと

• AWS のモデルカードでは、Opus 5.5 は jp.(東京と大阪で処理する地域の推論プロファイル)で使える。Sonnet 5.5 は us / eu / global のみ、Fable 5.1 は東京からは global.(世界中の空いているリージョン)だけ。
• 「東京で使える」には2通りある。東京の中だけで処理する(In-Region)と、東京から送って日本の中(jp.)で処理する。bedrock-runtime では東京の In-Region に対応する Claude はない。Mantle では Opus 4.8・Opus 4.7・Haiku 4.5 が東京の単一リージョンで使えるが、Opus 5.5 の Mantle には東京の行がない。Opus 5.5 を国内で使うなら jp. が実質の答え。
• Claude Code は ap-* リージョンでは既定で apac.(アジア太平洋の複数国で処理)を優先する。国内に閉じたいなら ANTHROPIC_BEDROCK_REGION_PREFIX=jp を明示し、さらに IAM で jp. 以外を拒否する。global. は aws:RequestedRegion が unspecified になる点で見分けられる。
• Sonnet 4.5 と Haiku 4.5 は、AWS のカードの「EOL no sooner than」(この日より前には提供を終了しない)が 2026-10-06 時点で過ぎている(Sonnet 4.5: 2026-09-30)か目前(Haiku 4.5: 2026-10-16)だった。カード上の状態はどちらもまだ Active で、終了したわけではない。

最初の見立て

解説ページ(service tiers)に対応表があるはず。

原典で確かめたこと

• 解説ページには仕組みの説明だけで、どのモデルが対応するかは書かれていなかった。対応の有無は各モデルカードの Service Tiers の表にあり、しかも ○× がテキストでなくアイコン画像で示されている。
• 機械で取得すると、アイコンは本文に出てこない。「ページに記載なし」と判定されやすい形。

最初の見立て

1周目の指摘を直せば終わり。監査役の指摘は正しい前提。

原典で確かめたこと

• 2周目で、1周目の修正文そのものに誤りが2件あった。「OTEL の利用者属性はゲートウェイが付ける」→ 実際はゲートウェイが発行したトークンをもとに CLI が付け、ゲートウェイは中身を変えずに中継するだけ。「Budgets のアクションを Identity Center のロールに当てる」→ Identity Center が作るロールは保護されていて直接変更できず、SCP で当てる。
• さらにその次の監査では、監査役の報告の中に、原典に存在しない「逐語引用」が1件あった(README に無い文を引用として書いていた)。grep で確かめて初めてわかった(これは作業の経緯なので、公開文書で検証できる出典はない)。

最初の見立て

ZDR はデータの保存ポリシーの話で、機能には関係ない。

原典で確かめたこと

• ZDR は「プロンプトと応答を、返答後に Anthropic が保存しない」取り扱い。Enterprise の標準には含まれず、管理画面で ON にはできない。適格な組織に Anthropic が個別に有効化する。
• 公式は、保存を前提に成り立つ機能はバックエンドで自動的に無効化されると書き、理由を機能ごとに挙げている: クラウドセッション(会話履歴をサーバーに保存)、Remote Control(端末間で同期するためトランスクリプトを保存)、Artifacts(公開ページを Anthropic の基盤に保存)、Claude Tag(チャンネルのメモリと記録を保持)。
• Code Review と Ultrareview は、それぞれの機能ページに「ZDR 組織では利用不可」とある。クラウドセッションが止まるので、その上で動くルーティンも止まる。
• ZDR でもポリシー違反とフラグされたセッションは最長2年保持されうる。Fable 5 / 5.1 は「Covered Models」として保持が既定で必要で、ZDR 組織では使えない場合がある。

最初の見立て

編集ツールを外せばファイルは書き換えられない。

原典で確かめたこと

• Bash が残っていれば、sed -i やリダイレクトでファイルは書き換えられる。公式は、disallowedTools に Bash(git push *) のように条件付きで書いても「Bash ごと消える」と明記していて、Bash の中身だけを絞る手段は permissions.deny 側にある。
• 同じ構図がフックにもある。フックの Bash 入力の判定(if フィルタ)は「最善努力」で、多くのイベントでは終了コード 1 では止まらず、2 で止まる(JSON の決定でも止められ、worktree 系のイベントは非 0 で止まる例外がある)。絶対に通したくない操作は permissions で止めろ、と公式が書いている。

最初の見立て

公開済みのページを再公開するだけなら、無人でも通る。

原典で確かめたこと

• ルーティンが確認なしで再公開できる Artifact は5条件すべてを満たすものだけ。自組織で自分が編集できる・公開リンクにしていない・共有相手が新しい版を自動では見ない設定・ページだけを公開し上書きしない・コネクタ呼び出しのような外に届く権限を持たない。チームに「常に最新版を共有」で配っていると、無人の再公開は確認待ちで止まる。
• ブランチ保護は「ルーティンの作成者が接続した GitHub アクセス」に対して効く。その人がバイパスできる立場なら、push は止まらない。
• 組み込みの GitHub ツールが文書で明記しているのは Issue の読み取り・PR 一覧・差分取得・コメント投稿。Issue の新規起票は書かれていない(公式の例は draft PR を開く形。gh CLI は入っているので起票できる余地はあるが、文書の保証はない)。
• クラウド環境の環境変数は、その環境を使う全員が読める。公式は秘密情報を置かないよう警告している(Team / Enterprise には代わりの API credentials がまだない)。

最初の見立て

CodeCommit の「PR にコメント」イベントを EventBridge で拾い、本文に @claude があれば CodeBuild を起動すればいい。

原典で確かめたこと

• CodeCommit のコメントイベント(Comment on Pull Request)には、コメント ID・PR ID・前後のコミット ID・投稿者の ARN は入るが、コメントの本文が入らない。EventBridge のルールだけでは @claude を絞れず、起動した側が GetComment で本文を取って判定する必要がある。
• 同じ型が他にもあった。CODEBUILD_WEBHOOK_TRIGGER は Webhook 起動のビルドでだけ使えると明記されている(他の WEBHOOK_* も Webhook 前提の変数で、スケジュール起動での値は文書に明記がない)。SNS → Lambda は「少なくとも1回」届く方式で重複しうる。ビルド自身の投稿で再起動するループは、自前で防ぐ必要がある。