Amazon BedrockのAnthropicモデルをどのように選択すべきか

3種類のAnthropicモデルを選んだことがあるか

突然ですが、皆様は、AIエージェント（Agentic AI）を開発するにあたって、どのモデルを使うかという判断をすることがあるでしょうか。

最も高い性能を持った最上位のモデルを選んでおけば間違わないという考えが先にあり、実はモデル選びを考えない方も多いのではないでしょうか。

最上位のモデルを選ぶことに対して、それが妥当だと説明することは比較的簡単です。しかし、なぜ中位のモデルで良いのか、最も下位のモデルで良いのかという説明をするのは難しいです。これは実際に難しく、数年前よりも確実に難しくなっています。難しくなった理由は、選択肢のせいではなく、同じ価格帯でできることの幅がモデルの進化で急速に広がっているためです。また、既に開発されたAIエージェントのモデルを選び直す場面では、今まで何となく上位のモデルで実行していた処理を、中位や下位のモデルで良いと評価することに難しさを感じられる方が多いようです。

2026年5月時点で、Amazon Bedrockから利用できるAnthropicの最新世代のモデルは3つです。

• Claude Opus 4.7（2026年4月16日リリース）
• Claude Sonnet 4.6（2026年2月17日リリース）
• Claude Haiku 4.5（2025年10月16日リリース）

この3つは性能・速度・コストの3軸でそれぞれ異なる特性を持っており、用途に応じて使い分けることが基本的なアプローチです。ただし「高い＝性能が良い」「安い＝性能が低い」という単純な対応にはなりません。

本記事では、3種類のAnthropicモデルが持つ特徴を丁寧に読み解き、実際の本番利用でも参考にされているモデル選択の判断基準について解説します。具体例として2026年5月時点のモデルの仕様を引用しながら説明していますが、進化の早さに対応するため、これから新しいモデルが出た場合にも本質的な考えとして参考にできるように執筆しました。

Claude Opus 4.7

Opus 4.7は、2026年5月時点でAnthropicが提供する最も高性能なモデルです。価格はインプット$5/MTok、アウトプット$25/MTokです。

このモデルを語るうえで外せないのが、コーディングエージェント向けのベンチマーク結果です。Anthropicの発表によると、SWE-bench Proで64.3%を達成しており、比較対象となるGPT-5.4（57.7%）とGemini 3.1 Pro（54.2%）をどちらも上回っています。

SWE-benchとは、GitHubに実際に存在するissueをAIエージェントが解決できるかを測るベンチマークで、本物のオープンソースリポジトリで実際に報告されたバグや機能改善の課題を対象としています。SWE-bench Verifiedはその中から検証済みの500問を抽出したバージョン、SWE-bench Proはさらに本番環境の複雑さに近い難しい課題を対象にしたバージョンです。後者のほうが実際の開発業務への近さという意味で参考になる指標と言えます。

Opus 4.7のSWE-bench Proスコアを前バージョンと比較すると、前バージョンの53.4%から64.3%へと10ポイント以上も向上しています。複雑な本番課題を完遂できる頻度が体感的に上がったと感じられるレベルの変化と考えられます。

Adaptive Thinkingへの移行

Opus 4.7では、推論方式が変わっています。以前のモデルではbudget_tokensでトークンの上限を手動設定するManual Extended Thinkingを使えましたが、Anthropicの公式ドキュメントによれば、Opus 4.7では400エラーになります。

代わりに使うのがAdaptive Thinking（thinking: {type: "adaptive"}）です。モデル側がリクエストの複雑さを判断して、思考の深さを自動的に調整します。単純な質問では思考を省略し、難しい課題には深く考えるという動的な制御をモデル自身が行います。

思考の深さはeffortパラメータで大まかに指定できます。low、medium、high（デフォルト）、max、xhighの5段階で、xhighはOpus 4.7のみで使える高レベルな思考です。xhighを使うとアウトプットトークンが増えやすく、それに伴いコストも上がりやすくなります。

コンテキスト・出力の仕様

コンテキストウィンドウは1Mトークンで、最大アウトプットは128Kトークンです。Sonnet・Haikuのアウトプットが64Kなので、Opusはその倍を一度に出力できます。AgentCore上で複数ステップのタスクを長時間実行する構成では、この差がタスク完遂率に影響することがあります。

コストの実態

公式の価格はOpus 4.6と変わりませんが、Opus 4.7の新しいトークナイザーの仕様で、同じテキストを処理する際のトークン消費量がOpus 4.6比で1.0〜1.35倍になります。トークン単価は同じでも消費量が増えるため、実効コストは最大35%ほど増加する可能性があります。

Batch APIを使えば入出力とも50%割引になるため、リアルタイム性が不要なバッチ処理にはBatch APIとの組み合わせが現実的な選択です。

Claude Sonnet 4.6

価格はインプット$3/MTok、アウトプット$15/MTokで、Opusの60%です。

そのうえで、Anthropicの公式発表によればSWE-bench VerifiedのスコアはSonnet 4.6が79.6%で、前世代のOpus 4.6の80.8%との差は1.2ポイントしかありません。冷静に評価すると、コストパフォーマンスが非常に良く見えてきます。

これが何を意味しているかを理解するには、モデルの世代進化に伴ってスコアがどう変遷してきたかを考える必要があります。Anthropicに限らず、大規模言語モデルは世代をまたぐたびに、同じ計算コストでより高品質な出力を得られるようにするという改善が繰り返されています。その度に、新世代の中位モデルが旧世代の上位モデルの性能水準に達しています。現在のSonnet 4.6にも、まさに同じことが言えています。モデルの名前やブランドに左右されず、ユースケースに応じて評価を行って採否を決められれば、コストパフォーマンスの良いAIエージェントになります。

Computer Useでの強み

AWSのアナウンスでは、Sonnet 4.6を「Anthropic史上最高のcomputer useモデル」と説明しています。Computer useとはブラウザや画面上のUIをエージェントが自律的に操作する機能で、その精度は94%と報告されています。業務ツールのブラウザ操作・スプレッドシート処理・社内システムへの自動入力といったUIベースの自動化を、実用的な信頼性でスケールさせたいユースケースに向いています。

推論と出力の仕様

Sonnet 4.6もAdaptive Thinkingに対応しており、effort パラメータによる深さの制御も使えます。以前のManual Extended Thinking（budget_tokens）はまだ動作しますが、非推奨とされており、将来削除されることを前提にして扱うべきです。

コンテキストウィンドウは1Mトークン（beta）、Batch API経由では1リクエストあたり300Kトークンの出力が可能です。

マルチエージェント構成では、オーケストレーター（全体を管理するリードエージェント）としても、サブエージェント（個別タスクを担当するエージェント）としても機能します。Sonnetで試して出来ないことをOpusで実装するという段階的な検証を行えば、コストパフォーマンスの良いAIエージェントを開発できます。

Claude Haiku 4.5

価格はインプット$1/MTok、アウトプット$5/MTokで、Opusの5分の1、Sonnetと比べても3分の1です。応答速度は3モデル中最速のレイテンシを持ち、リアルタイム応答が求められるチャットボット、大量の分類処理、マルチエージェントシステムでの振り分け判断など、速い応答や安く使うことが最優先される用途に向いています。

コンテキストウィンドウは200Kトークンで、OpusとSonnetの1Mより小さくなっています。表面的に見れば単純なカタログ値の違いで見劣りしますが、コストと速度とのトレードオフを理解して使うべきモデルと言えます。一般的にはコンテキストを大きくすると処理データ量が増え、レイテンシが上がり、コストも増加します。Haikuの設計意図を考えると、200Kで足りる用途に絞って使うのが正しい使い方です。

また、Haiku 4.5はExtended Thinkingに対応していますが、Adaptive Thinkingには非対応です。このように機能で不足する点は、コストとのトレードオフだと考えて割り切る必要があります。深い思考を必要としない単純な置換や翻訳などに使用するのが、コストパフォーマンスの良い使い方です。

3種類のモデルを比較する

Opus、Sonnet、Haikuのモデルを様々な項目で比較した表を掲載します。このように一度表形式でまとめてしまえば、新たなバージョンが登場した時にAIに対して「最新バージョンの情報にアップデートして」と指示するだけで最新化することができます。

項目	Claude Opus 4.7	Claude Sonnet 4.6	Claude Haiku 4.5
AWS Bedrockモデルカード	リンク	リンク	リンク
Anthropicシステムカード	リンク	リンク	リンク
リリース日	2026年4月16日	2026年2月17日	2025年10月16日
AWS Bedrock ID	anthropic.claude-opus-4-7	anthropic.claude-sonnet-4-6	anthropic.claude-haiku-4-5-20251001-v1:0
価格（input/1Mトークン）	$5	$3	$1
価格（output/1Mトークン）	$25	$15	$5
コンテキストウィンドウ	1Mトークン	1Mトークン（beta）	200Kトークン
最大出力トークン	128K	64K	64K
Adaptive Thinking	✓（唯一のモード）	✓（推奨）	—
Manual Extended Thinking	—（非対応・400エラー）	△（非推奨・利用可）	✓（唯一の対応方式）
xhigh effortレベル	✓	—	—
Task Budgets（beta）	✓	—	—
SWE-bench Pro	64.3%	—	—
SWE-bench Verified	87.6%	79.6%	73.3%
ビジョン解像度	3.75MP（2,576px）	1.15MP（1,568px）	1.15MP（1,568px）
Tokenizer	新バージョン （旧バージョンに比べて最大1.35倍のトークン消費となる可能性）	旧バージョン	旧バージョン
Knowledge cutoff	2026年1月	2025年8月	2025年2月
Training data cutoff	2026年1月	2026年1月	2025年7月
EOL予定	未定	未定	2026年10月1日以降

Claudeの2つの推論モードを比べる

Claudeの推論機能（Thinking）には、設定方式が異なる2つのモードがあります。

Extended Thinkingでは、推論に使うトークンの上限budget_tokensを開発者が明示的に指定するため、コストと推論深度を細かくコントロールできます。Sonnet 4.6とHaiku 4.5で利用できます。パラメータはthinking: {type: "enabled", budget_tokens: N}のように指定します。

Adaptive Thinkingでは、モデルがリクエストの複雑さを自ら判断し、推論の深さを動的に調整します。推論の深さはeffortパラメータで制御でき、low・medium・high（デフォルト）・max・xhighの5段階があります。thinking: {type: "adaptive"}と指定して使用します。

Adaptive Thinkingの何が良いのか

Anthropicの内部評価では、Adaptive ThinkingはExtended Thinkingに比べて一貫してパフォーマンスが高いとされており、Opus 4.7からはAdaptive Thinkingが唯一の方式になりました。Extend Thinkingと比較すると、budget_tokensを細かく指定できないため柔軟性に欠けるイメージがありますが、何が優れているのかを考えると、次のようなポイントになります。

• コスト効率
  Extended Thinkingではbudget_tokensを細かく指定できるものの、言い換えれば、指定した上限まで使って推論を実行する可能性があります。例えば、単純なリクエストでも不要なトークンを消費するケースが考えられます。Adaptive Thinkingは、リクエストの複雑さを自動判断するため、推論コストを必要な分だけに抑えやすいと考えられます。

• 設定の簡潔さ
  設定はbudget_tokensの最適値を試行錯誤してチューニングする代わりに、effortパラメータのレベルを選ぶだけとなります。コストを重視するならlow、精度を優先するならhighまたはxhighという直感的な選択が可能です。

Haikuを除く最新モデルにおいて、Extended Thinkingは非推奨とされています。Sonnet 4.6ではExtended ThinkingはAdaptive Thinkingと並行して使えますが、将来的に使用できなくなる可能性を考えておくべきです。新たにAIエージェントを開発する際は、Adaptive Thinkingを選ぶようにします。

エージェント設計での選び方

ベンチマークを並べ、3モデルの性能（カタログスペック）差を比較することは重要ですが、エージェント設計においては、そのモデルがオーケストレーター（指揮者）になるのか、サブエージェント（実行者）になるのかという役割の割り当てが重要となります。

Anthropicの公式モデル選択ガイドにも分担についての言及があります。Opus 4.7は大規模なコード移行や複雑なシステム設計、数時間に及ぶ自律タスクを担うオーケストレーター向けとあります。Sonnet 4.6はコーディング・分析・エンタープライズのワークフローを広くカバーし、Haiku 4.5は高速・低コストを活かしてサブエージェントの実行役を担うことが期待されています。性能の高低だけではなく、設計上の役割でモデルを選ぶという発想は大切です。

オーケストレーターの選び方と注意点

Anthropicの公式プロンプトガイドによると、Opus 4.7はデフォルトでサブエージェントをあまり生成しない傾向があるとされています。複数のサブエージェントに作業を分散させたい場面では、「並列実行できる場合や独立したコンテキストが必要な場合はサブエージェントに委任する」という旨をプロンプトに明示的に書く方が安定するようです。

Haikuでサブエージェントを作る

実行役となるサブエージェントにHaikuを選ぶのは合理的な選択と言えます。公式ガイドでもサブエージェントタスクの代表例として明示されており、分類・フォーマット変換・繰り返しのデータ処理のような定型的な作業であれば十分な精度を発揮します。effortパラメータでlowを指定することでさらにコストを抑えられ、定型的なタスクの大部分を任せることを期待できます。コーディングエージェントでOpusに慣れている開発者ほど、Haikuを選ぶことには不安があるかもしれませんが、任せたい処理を検証することが大事です。

新しいモデルが登場したときの評価と移行の進め方

Anthropicのモデルは年に数回のペースで更新されており、新しいモデルが出るたびに「すぐ移行すべきか」「今のモデルで様子を見るべきか」という判断を迫られます。基本的には同価格で高性能ならば新しいモデルを使おうという判断で良いのですが、ここまでAdaptive Thinkingなどの解説を読まれた方なら、その判断を感覚的に行うのにリスクがあることはご理解いただけるはずです。ここでは評価から移行完了までの進め方と観点を整理します。

ベンチマークスコアを確認する

Anthropicはリリースのたびにコーディング系ベンチマーク（SWE-bench VerifiedやSWE-bench Proなど）のスコアを公開しています。基本的に新しいモデルは古いモデルよりもスコアが良くなりますので、このスコアだけを見ても移行すべきという考えが先に出てくることになります。本番環境に近い指標として、課題がより新鮮で難しいSWE-bench Proのスコアを確認します。

例えば、Opus 4.7は、SWE-bench Proで53.4%から64.3%と10ポイント以上向上しています。これだけスコアが上がると、モデルを変えるだけで実質的な性能改善が見込めます。これが1〜2ポイント程度の差であれば、敢えて移行せずに保留する選択肢もあります。

自社のユースケースに近い評価タスクを用意して、新旧モデルで実際に比較検証するのが最も信頼性の高いアプローチです。

Playgroundのモデル比較モードを使用して評価する

Amazon Bedrockのコンソールには、Playgroundという推論テスト環境があります。ここで「比較モード」をオンにすると、最大3つのモデルに同一のプロンプトを同時送信できます。各モデルの応答はパネルで横並びに表示され、レイテンシ、入力トークン数、出力トークン数を画面上で比較できます。

新しいモデルがリリースされた直後に、代表的なプロンプトをいくつか選んで、同じブロンプトで挙動を確認するという最初の検証はこれで十分なことが多いです。ただし、定性的な比較にとどまります。自社のユースケースに対して再現性のある評価データを得るには、次に紹介するModel Evaluationを使う必要があります。

Model Evaluationで自社データを使った体系的な検証を行う

Amazon Bedrock Model Evaluationを使うと本格的な比較検証が行えます。S3バケットに自社のプロンプトデータセットを用意して評価ジョブを実行すると、指定したモデルの応答に対してスコアが計算されます。

• LLM-as-a-Judge
  別のLLMが採点者として応答の正確さ・完全性・ハルシネーション・有害性などを採点するもので、精度とコストのバランスが取れており最も汎用的です。
• プログラム的評価（Programmatic）
  BERTScoreやF1などの従来型NLPメトリクスによる自動採点です。
• 人間による評価
  その名の通り人間が応答を評価するもので、ブランドボイスへの準拠など定量化しにくい指標に向いています。

自社のプロンプトデータセットを持ち込むことができ、カスタムメトリクスの定義も可能であり、汎用ベンチマークではなく自社の評価軸で新旧モデルを比較できます。複数の評価ジョブの結果はコンソール上で横並びに比較できるため、どこで差があるかを具体的に把握できます。

実効コストを再計算する

新モデルの価格が前バージョンと同じだと発表されていても、Opus 4.7のトークナイザーのように、そのまま鵜呑みにできない場合があります。実効コストに関わる仕様変更がないかを良く調べて判断する必要があります。

• トークナイザーの変更有無
  Opus 4.7のように新しいトークナイザーが採用されて、同じテキストでも消費トークン数が大幅に変わる可能性があります。Anthropicのリリースノートで確認し、変更があれば代表的なプロンプトを新旧モデルで実際に処理してトークン数を比較します。
• Thinkingモードの変化とeffort設定
  Adaptive Thinkingに移行するモデルでは、effort の設定によってアウトプットトークンが大幅に変わります。デフォルトの high で問題ないか、コスト観点から medium に下げられるか、実際の品質を確認しながら調整します。
• Batch APIの適用範囲
  新モデルがBatch APIをサポートしているか確認します。Batch APIをサポートしていない場合、知らずにモデルIDだけを変更するとエラーになります。基本的に全てのアクティブモデルはBatch APIに対応しますが、観点として覚えておくと万が一に備えられます。Batch APIが使えるとコストを50%下げられます。

APIの互換性を確認する

APIでモデルIDだけを変えれば移行完了するイメージを持たれますが、最新モデルで廃止されたパラメータを使っているとエラーになります。これは破壊的な変更と呼ばれる類のアップデートです。例えばOpus 4.7でbudget_tokensが廃止されたように、次のモデルでも同様の変更が起きる可能性はあります。新しいモデルの登場スピードが速く、またパラメータ定義が見直されるスピードも速いのがAI関連技術の特徴でもあります。APIの互換性を確認する必要があります。

• Thinkingモードの対応状況
  Adaptive ThinkingのみかManual Extended Thinkingも使えるかを確認します。
• 廃止されたパラメータの有無
  既存のリクエストに含まれているパラメータが新モデルでエラーになる可能性を確認します。リリースノートが最初の手掛かりになります。
• モデルIDの変更
  BedrockのモデルIDが変わる場合、呼び出し側の設定更新が必要です。基本的にモデルIDの文字列全体を置き換える必要があります。

AnthropicのMigration Guideには、バージョン間の変更点と移行上の注意点がまとめられています。新モデルのリリース時に必ず確認する習慣をつけると、移行時のトラブルを減らせます。

モデルを段階的に移行する

本番環境では段階的にモデルの移行を進めます。

1. サンドボックスでの動作確認

新モデルに対して、既存の代表的なプロンプトを流して、レイテンシ、入力トークン数、出力トークン数を記録します。本番トラフィックではなく、事前に準備した評価セットで検証します。

2. コストの試算

サンドボックスで取得したトークン数（消費量）をもとに、現在の利用パターンに当てはめた月次コストを計算します。トークナイザーの変更がある場合は特に入出力の両方で確認します。

3. A/Bテストによる品質比較

本番トラフィックの一部（例：5〜10%）を新モデルに向けて、旧モデルとの出力品質を比較します。エージェントの場合、タスク完遂率・エラー率・ユーザー満足度などを指標として設定します。LLM-as-judge評価を活用すると、人手によるチェックのコストを抑えながら品質をできます。

Amazon Bedrock AgentCoreをバックエンドに置くチャットボット型のAIエージェントでは、API GatewayとLambdaを組み合わせてストリーミングレスポンスを実現しているケースが多いです。API Gatewayのカナリアリリース機能や、Lambdaの重み付きエイリアスを使ってリクエストを分配しながらテストする方法が考えられます。

また、AgentCore Runtimeのinvoke_agent_runtimeでqualifierパラメータを使用して、同じAgentCore Runtime ARNに対して呼び出し先のランタイムのバージョンを変えることができます。指定しない場合はDEFAULTエンドポイント（常に最新版を指す）が使われます。この機能を使用してテストすることもできますが、本番環境で初めからqualifierの指定を徹底しておく必要があります。

4：段階的な切り替え

テストの結果が許容水準であれば、トラフィックを段階的に新モデルへ移行します。移行後もしばらくはモニタリングを継続し、想定外の品質低下やコスト増加が発生した場合はすぐに戻せる体制を維持します。

EOLスケジュールの把握と移行タイミング

新モデルがリリースされた後に、多くの場合、既存モデルの廃止スケジュールが発表されます。廃止の数ヶ月前から対応を進めることが理想ですが、実際には直前になって気づくケースも少なくありません。

AWSのモデルカードには各モデルのEOL日程が記載されており、定期的に確認することで、移行の見通しを立てられます。AWS Healthを通じてEOLの案内を受け取るケースもありますので、必ず確認するようにしておきます。

廃止直前に駆け込んで移行しようとすると、テスト期間が短くなり、プロンプトの再調整や互換性確認が不十分になります。例えば、新モデルが出たら2ヶ月以内にサンドボックス検証を完了するといった目安を社内で持っておくと、計画的に対応できます。

BedrockのAnthropicモデルに関連する設計上の選択肢

最後に、モデル選択と合わせて確認しておくべきBedrock固有の設定をまとめます。

エンドポイントの選択

Claude Sonnet 4.5以降のモデルでGlobal endpointとRegional endpointの2種類が使えます。データの処理リージョンを問わないならGlobal endpoint、医療・金融・行政などデータの所在地に規制がある場合はRegional endpointを選択します。

サービスティア

BedrockにはStandard（通常）・Flex（非リアルタイム向け割引）・Priority（高速・優先処理）・Reserved（容量予約）の4段階のサービスティアが用意されています。

Flexはモデル評価やバッチ処理に適しており、Standardの半額です。Priorityはユーザー向けリアルタイムインタラクションに向いていますが、コストはStandardの1.75倍となります。FlexのリクエストはStandardのリクエストよりも後に処理されるため、このような遅延を許容できる必要があります。Reservedは、長期利用をコミットすることで大きな割引を得られます。

なお、記事執筆時点でAnthropicのモデルはReservedのみ選択でき、他ベンダーもモデルごとに選べるティアが異なるようです。

プロンプトキャッシング

エージェントが長いシステムプロンプトやツール定義を毎リクエスト送信する構成でコストを大幅に削減できます。最新のAnthropicのモデルでは、最小1,024トークンのキャッシュポイントを最大4つ設定でき、TTLは5分または1時間から選択できます。

まとめ

様々な角度から、Anthropicのモデルの選び方について解説しましたが、基本的には最新のモデルを選ぶ方針で間違いないと言えます。しかし、本番環境のAIエージェントでは、限られた予算で、期待された成果を上げることを目指す必要があり、Opusか、Sonnetか、それともHaikuかという選択を丁寧に考えなければなりません。

例えば、Sonnet 4.6のSWE-bench VerifiedスコアがOpus 4.6と1.2ポイント差しかないという事実を見た時、旧世代の上位モデルにさせていた仕事を6割のコストで任せられるかもしれないと解釈できるのです。本記事でもモデルに担わせる役割について、公式サイトの記述を引用しながら触れています。オーケストレーターとして複雑な判断と長期タスクを担わせるのか、サブエージェントとして定型処理を高速かつ安価にこなさせるのかという問いのもとで、Opus、Sonnet、Haikuのどれを選ぶかを絞り込むことができます。

一方で、Adaptive Thinkingへの移行が示すように、APIの仕様はモデルの世代をまたぐたびに変化することがあります。仕様の違いが挙動の変化と連動する場合、移行は単純なモデルIDの差し替えでは済まない場合があります。ベンチマーク、実効コスト、API互換性という3つの確認軸を知って、新モデルのリリースを迎えることが大事です。

モデル選択に唯一の正解はなく、一度移行しても、おそらく半年後にはまた選び直すことになります。ベンダーごとの競争が激しく、各社の新モデルの登場スピードがそれほどに速いからです。新しいモデルが出た時に、何を考えて判断すれば良いかを知っておくことで、スピーディーに対応できるようになります。本記事がその一助となれば幸いです。