Amazon Web Services ブログ

Amazon Bedrock における Anthropic の Claude 3.5 Sonnet から Claude 4 Sonnet に移行する

この投稿は Anthropic の Gareth Jones と共同で執筆されています。

Anthropic の Claude 4 Sonnet モデルが Amazon Bedrock でローンチされ、基盤モデルの機能において大幅な進歩を遂げました。これに伴い、Anthropic の Claude 3.5 Sonnet (v1 および v2) の廃止スケジュールが発表されました。この進化により、本番 AI アプリケーションにとって二つの重要な考慮事項が発生しています。強化されたパフォーマンスを活用する機会と、廃止前に移行するという運用上の必要性です。組織は、モデル移行を AI 推論戦略の中核要素として扱う必要があります。なぜなら、実行が不適切だとサービス中断、パフォーマンス低下、コスト超過を招く可能性があるからです。

この投稿では、Amazon Bedrock で Anthropic の Claude 3.5 Sonnet から Claude 4 Sonnet に移行するための体系的なアプローチを提供します。主要なモデルの違いを検証し、重要な移行の考慮事項を強調し、この必要な移行を組織にとって測定可能な価値をもたらす戦略的優位性に変える実証済みのベストプラクティスを提供します。

モデルの違いの概要

モデルバージョン間の具体的な変更を理解することは、成功する移行を計画する最初のステップです。Anthropic の Claude 3.5 Sonnet から Claude 4 Sonnet への移行では、活用できる機能と動作の変化が取り入れられています。

  • コンテキストウィンドウの拡大 – Anthropic の Claude 4 Sonnet は、コンテキストウィンドウを 200 K トークンから 1 M トークン (ベータ版) に拡張します。これにより、アプリケーションは単一のプロンプトでコードベース、財務レポート、または長い法的文書を処理し、推論することができ、複雑なワークフローを簡素化します。
  • ネイティブ推論メカニズム – Anthropic の Claude 3.5 Sonnet モデルが思考の連鎖 (chain-of-thought、CoT) プロンプト技術に依存するのに対し、Claude 4 モデルは 拡張思考インターリーブ思考 などの組み込み で API 対応の推論機能を導入します。これらにより、モデルは回答前に思考するための専用の計算時間を得て、複雑な問題でのパフォーマンスを劇的に向上させます。
  • 高度なツール使用 – Anthropic の Claude 4 Sonnet モデルは、ツール呼び出し機能を大幅にアップグレードします。複数のツールを並列実行 し、ツール呼び出し間で拡張思考を使用できるため、古いモデルの順次ツール使用と比較して、より洗練された効率的なエージェントワークフローが可能になります。

モデルの違いについて詳しく知るには、完全なモデル比較ガイド を参照してください。

移行を成功させるためには、いくつかの重要で技術的・戦略的な考慮事項が鍵となります。これらについては以下のセクションで説明します。これらの点を積極的に対処することで、リスクを最小化し、本番環境への道のりを加速できます。

前提条件

Anthropic の Claude 4 Sonnet モデルの使用を開始する前に、Amazon Bedrock でこれらのモデルへのアクセスを有効にする必要があります。手順については、Amazon Bedrock 基盤モデルへのアクセスをリクエストする を参照してください。モデルアクセスリクエストを進める前に、モデルのエンドユーザーライセンス契約 (EULA) を確認し、同意することを確認してください。Claude 4 Sonnet が意図した AWS リージョンで利用可能であることを最初に確認することが重要です。なぜなら、モデルサポートは場所によって異なる可能性があるからです。サポートされているリージョンの最新リストについては、Amazon Bedrock でのリージョン別モデルサポート を参照してください。さらに、モデル推論を実行する際に推論プロファイルを指定することで クロスリージョン推論 (CRIS) を使用でき、これによりスループットの向上とリソース可用性の最大化に役立ちます。サポートされているクロスリージョン推論プロファイルのリストについては、推論プロファイルでサポートされているリージョンとモデル を参照してください。

API の変更とコードの更新

Amazon Bedrock においてモデルを移行する際は、モデル固有の InvokeModel API または統一された Converse API のいずれかを使用できます。

InvokeModel API を使用する場合、移行は簡単です。Anthropic の Messages API のリクエストボディ構造はバージョン間で一貫しているため、コード内の modelId を更新するだけで済みます:

  • 旧モデル ID'anthropic.claude-3-5-sonnet-20240620-v1:0' または 'anthropic.claude-3-5-sonnet-20241022-v2:0'
  • 新モデル ID'anthropic.claude-4-sonnet-20240514-v1:0'

モデルに CRIS プロファイル を使用する場合は、ソースリージョンの 中から 正しい推論プロファイル ID 1 つを指定してください。例:'us.anthropic.claude-sonnet-4-20250514-v1:0'

この移行は、Converse API に切り替える絶好の機会です。Amazon Bedrock の言語モデルに対して標準化されたリクエスト/レスポンス形式を提供し、将来の異なるモデルやプロバイダーへの移行をはるかに簡単にします。以下のコードを参照してください:

import boto3

bedrock_runtime = boto3.client(service_name='bedrock-runtime')
# モデルを切り替えるためには、単にモデル ID を変更
response = bedrock_runtime.converse(
modelId='us.anthropic.claude-sonnet-4-20250514-v1:0',
messages=[{'role': 'user', 'content': [{'text': "Your prompt here"}]}],
inferenceConfig={'maxTokens': 1024}
)

print(response['output']['message']['content'][0]['text'])

以下はいくつかの重要な変更点です:

  • 更新されたテキストエディタツール – エージェントワークフローで Anthropic の組み込みテキストエディタツールを使用している開発者は、ツール定義が更新されていることを認識する必要があります。ツールタイプは現在 text_editor_20250124 で、ツール名は現在 str_replace_based_edit_tool です。テキストエディタツールは Anthropic の Claude 4 で一般提供されているため、anthropic_beta ヘッダーの computer-use-2024-10-22 は削除できます。このツールを使用するコードは、これらの変更を反映するように更新する必要があります。詳細については、Anthropic 定義ツール を参照してください。
  • 削除された undo_edit コマンドundo_edit コマンドは Anthropic の Claude 4 Sonnet でサポートされなくなりました。このコマンドを使用するコードは削除する必要があります。
  • 新しい refusal 停止理由 – モデルは現在 新しい拒否停止理由 を導入しています。この理由は、モデルが安全ポリシーによりコンテンツ生成を拒否した場合に返されます。モデルレスポンスを処理するアプリケーションロジックは、この新しい停止理由を認識し、管理するように更新して、予期しない動作やエラーを防ぐ必要があります。例えば、マルチターンインタラクションで refusal 停止理由を受け取った場合、拒否されたターンを削除または更新することで会話コンテキストをリセットする必要があります。

プロンプトエンジニアリングと動作の変化

既存のプロンプトが新しいモデルで完璧に動作すると仮定してはいけません。モデル固有のベストプラクティスの遵守が重要です。

最適な結果を得るために、Anthropic がリリースした Claude 4 プロンプトエンジニアリングベストプラクティス を参照してください。例えば、Anthropic の Claude モデルは、入力の異なる部分を明確に分離するために XML タグ (例:<document></document>) で構造化されたプロンプトで最高のパフォーマンスを発揮します。

Anthropic の Claude 4 Sonnet は、指示により正確に従うように設計されています。これは大きな利点ですが、明示的にプロンプトされない限り、Claude 3.5 Sonnet よりも冗長性や詳細性が低い可能性があります。AI のペルソナを定義するシステムプロンプトは調整が必要かもしれません。

新しい思考推論機能

Anthropic の Claude 4 Sonnet モデルに組み込まれている拡張思考は強力な機能です。新しいモデルの深い推論機能を解放するために、開発者は API 呼び出しに thinking キーワード引数を含めることで拡張思考を有効にできます。ただし、戦略的に使用することを確認してください。拡張思考は追加コストが発生します。なぜなら、推論トークンは標準モデル料金で出力トークンとして課金されるからです。 (表示される要約だけでなく) 完全な思考プロセスに対して課金され、設定した思考予算に応じてコストが拡大する可能性があります。

精度が最重要である深い多段階分析を必要とするタスク (例:複雑な科学的問題や高度なコーディングチャレンジ) では、拡張思考を有効にすることをお勧めします。

単純なクエリや遅延に敏感なアプリケーションでは、拡張思考を無効にすることをお勧めします。この機能はコスト (推論トークンが課金される) と応答時間の両方を増加させます。多くのタスクでは、適切に作成された CoT プロンプトが依然として最も効率的な選択です。

拡張思考を使用するには、thinking 設定で additionalModelRequestFields パラメータを追加して Converse API 呼び出しを更新するだけです。budget_tokens の値を設定することで、モデルが使用できる最大思考トークン数を指定できます。拡張思考では、maxTokensbudget_tokens より大きくする必要があることに注意してください。以下のコードを参照してください:

import boto3

bedrock_runtime = boto3.client(service_name='bedrock-runtime')

# 拡張思考を有効にするために設定を追加
response = bedrock_runtime.converse(
    modelId='us.anthropic.claude-sonnet-4-20250514-v1:0',
    messages=[{'role': 'user', 'content': [{'text': "Your prompt here"}]}],
    inferenceConfig={'maxTokens': 2048},
    additionalModelRequestFields={"thinking":{"type": "enabled",
     "budget_tokens": 1024}}
)

reasoning_text = response['output']['message']['content'][0]['reasoningContent']['reasoningText']['text']
assistant_response = response['output']['message']['content'][1]['text']

以下の表は、拡張思考の例とそれがどのように応答精度を向上させるかを示しています。Anthropic の Claude 3.5 Sonnet v2 と Claude 4 Sonnet (拡張思考有効) にサンプルのプロンプトを与えます:

Alan、Bob、Colin、Dave、Emily が円形に立っています。Alan は Bob の真左にいます。Bob は Colin の真左にいます。Colin は Dave の真左にいます。Dave は Emily の真左にいます。Alan の真右にいるのは誰ですか?

表は 2 つのモデルからの応答を示しています。拡張思考により、モデルは問題を慎重に推論し、正しい答えに到達できます。

モデル 拡張思考 出力 正解/不正解
Claude 3.5 Sonnet v2 N/A (参考訳)
段階的に解決してみましょう。まず、わかっていることを理解しましょう:Alan は Bob の真左にいます。Bob は Colin の真左にいます。Colin は Dave の真左にいます。Dave は Emily の真左にいます。任意の人から始めて、順番に配置してみましょう:Dave が Emily の真左にいる場合、Emily は Dave の真右にいます。Colin が Dave の真左にいる場合、Dave は Colin の真右にいます。Bob が Colin の真左にいる場合、Colin は Bob の真右にいます。Alan が Bob の真左にいる場合、Bob は Alan の真右にいます。つまり、時計回りの順序は:Alan → Bob → Colin → Dave → Emily です。円形なので、Emily は円を完成させるために Alan の隣にいる必要があります。したがって、Emily は Alan の真右にいます。答えは Emily です。
不正解
Claude 4 Sonnet (参考訳)
段階的に取り組んでみましょう。
円形に立っている 5 人がいます:Alan、Bob、Colin、Dave、Emily。 与えられた情報を追跡してみましょう: Alan は Bob の真左にいます Bob は Colin の真左にいます Colin は Dave の真左にいます Dave は Emily の真左にいます 円形なので、順序を把握する必要があります。1 人から始めて周りを回ってみましょう。 Alan が Bob の真左にいる場合、時計回りに:Alan、次に Bob。 Bob が Colin の真左にいる場合、時計回りに:Bob、次に Colin。 Colin が Dave の真左にいる場合、時計回りに:Colin、次に Dave。 Dave が Emily の真左にいる場合、時計回りに:Dave、次に Emily。 つまり、円の時計回りは:Alan → Bob → Colin → Dave → Emily しかし、円なので、Emily は誰かに接続する必要があります。Alan → Bob → Colin → Dave → Emily があり、これは 5 人の完全な円なので、Emily の次は Alan でなければなりません。 つまり、完全な時計回りの円は:Alan → Bob → Colin → Dave → Emily → Alan これは Emily が Alan の真左にいることを意味し、したがって Alan の真右は…慎重に考えてみましょう。 時計回りに行くと:Alan → Bob → Colin → Dave → Emily → (Alan に戻る) つまり、Alan の真右 (Alan から時計回りに) は Bob です。そして Alan の真左 (Alan から反時計回りに) は Emily です。 与えられた条件を再確認してみましょう: Alan は Bob の真左にいます ✓ (Alan は時計回りで Bob の直前に来ます) Bob は Colin の真左にいます ✓ (Bob は時計回りで Colin の直前に来ます) Colin は Dave の真左にいます ✓ (Colin は時計回りで Dave の直前に来ます) Dave は Emily の真左にいます ✓ (Dave は時計回りで Emily の直前に来ます) 円形配置で Bob が Alan の真右に座っていることを確認します。
(参考訳)
段階的に見てみましょう:与えられた情報:Alan は Bob の真左にいます。Bob は Colin の真左にいます。Colin は Dave の真左にいます。Dave は Emily の真左にいます。円の時計回りの順序を追跡してみましょう:Alan → Bob (Alan が Bob の真左にいるため)。Bob → Colin (Bob が Colin の真左にいるため)。Colin → Dave (Colin が Dave の真左にいるため)。Dave → Emily (Dave が Emily の真左にいるため)。円形に立っているので、Emily は円を完成させるために接続する必要があります:Emily → Alan。つまり、完全な時計回りの順序は:Alan → Bob → Colin → Dave → Emily → Alan。したがって、Bob が Alan の真右にいます
正解

拡張思考が有効な場合、API はデフォルトで、誤用を防ぐための保護措置として設計された、完全な推論チェーンではなく モデルの完全な思考プロセスの要約を返します。これにより、完全なインテリジェンス利益を提供しながらも、ストリーミング応答でチャンクまたは遅延パターンが生じる可能性があり、開発者はアプリケーションのユーザーエクスペリエンスでこれを考慮する必要があります。

Anthropic の Claude 4 モデルは、ツールで拡張思考を使用する際の インターリーブ思考 機能を備えており、モデルがツール呼び出し間で中間推論を実行し、受け取ったツール結果に基づいてより微妙な分析結論を開発できます。ツール呼び出しで インターリーブ思考を有効にする には、Converse API リクエストの additionalModelRequestFields に追加パラメータ "anthropic_beta": ["interleaved-thinking-2025-05-14"] を追加します。

拡張思考の使用について詳しくは、拡張思考 を参照してください。

堅牢な評価の必要性

新しいモデルが特定のタスクで古いモデルと同等以上のパフォーマンスを発揮することを検証する必要があります。本番トラフィックを高度に代表する、厳選されたプロンプトと期待される出力のセットを作成してください。このカスタムベンチマークは、報告されたベンチマークスコアよりもはるかに価値があります。

このデータセットを自動評価パイプラインに統合してください。このパイプラインは、継続的インテグレーションおよび継続的デリバリー (CI/CD) プロセスの一部となり、将来のモデルやプロンプトの変更に対する永続的な回帰スイートとして機能する必要があります。ツールについては、チームは Amazon Bedrock の評価 などの組み込みソリューションや、RAGASDeepEval などのオープンソース評価フレームワークを使用できます。

統合された安全性とガバナンスの管理

モデルの安全プロファイルは各バージョンで変化します。これは統合システムの一部としてテストする必要があります。新しいモデルを単独でテストしてはいけません。移行テスト計画は、本番環境で使用するのと全く同じガードレール設定 (例:Amazon Bedrock ガードレール) で新しいモデルを評価する場合にのみ有効です。新しいモデルの会話スタイルが既存のガードレールを予期しない方法でトリガーし、ブロックされた応答の急増につながる可能性があります。

安全なデプロイメント戦略の実装

Anthropic の Claude 4 Sonnet を本番環境にデプロイする際は、リスクを最小化するために段階的ロールアウト戦略を実装してください。ユーザーに影響を与えることなく、ミラーリングされたトラフィックを使用してモデルパフォーマンスを比較するシャドウテストを検討し、その後ビジネス KPI への影響を測定するための A/B テストを実施してください。実際のロールアウトでは、少数のユーザーを新しいモデルに段階的に公開するカナリアリリースアプローチ、または即座にロールバック機能を持つ並列環境を維持するブルー/グリーンデプロイメント戦略のいずれかを使用してください。この構造化されたアプローチにより、ビジネス継続性を維持しながら新しいモデルのパフォーマンスを安全に検証できます。

まとめ

Anthropic の Claude 3.5 Sonnet (v1 および v2) から Claude 4 Sonnet への移行を構造化されたエンジニアリングプロジェクトとして扱うことで、移行プロセスのリスクを軽減し、大きな利益を得ることができます。主要なモデルの違いを理解し、プロンプトと API 呼び出しを適応させ、堅牢で自動化された評価戦略を実装することが、成功するアップグレードの柱です。

この移行は、ビジネス継続性を維持し、次世代機能でアプリケーションを強化する機会です。今日から分析とテストを開始することをお勧めします。

詳細については、Claude 4 への移行Amazon Bedrock における Anthropic の Claude を参照し、移行固有のお問い合わせについてはお気軽にお問い合わせください。

このブログはソリューションアーキテクトの福本が翻訳しました。原文はこちらです。


About the authors

MelanieMelanie Li 博士は、オーストラリアのシドニーを拠点とする AWS のシニア生成 AI スペシャリストソリューションアーキテクトで、最先端の AI/ML ツールを使用したソリューション構築でお客様と協力することに焦点を当てています。彼女は APJ 全体で複数の生成 AI イニシアチブに積極的に関与し、LLM の力を活用しています。AWS に参加する前、Li 博士は金融および小売業界でデータサイエンスの役割を担っていました。

DeepakDeepak Dalakoti 博士は、オーストラリアのシドニーにある生成 AI イノベーションセンターのディープラーニングアーキテクトです。AI の専門知識を持つ彼は、クライアントと協力してカスタマイズされた革新的なソリューションを通じて生成 AI の採用を加速しています。AI の世界以外では、新しい活動や体験を探求することを楽しんでいます。

MahsaMahsa Paknezhad 博士は、AWS 生成 AI イノベーションセンターのディープラーニングアーキテクトです。スケーラビリティと本番準備に焦点を当て、Mahsa は多様な業界の組織が高度な生成 AI モデルを活用して意味のあるビジネス成果を達成することを支援しています。Mahsa は、特に鉱業および医療セクターでプロジェクトを成功裏に提供した実績があります。

NicholasNicholas Moore は AWS のソリューションアーキテクトで、スタートアップやあらゆる規模の企業がアイデアを現実に変えることを支援しています。彼は AI、分析、モダンアプリケーション開発に焦点を当てたクラウドソリューションを専門としています。

DerrickDerrick Choo は、クラウド採用、AI/ML、生成 AI ソリューションを通じて企業のデジタル変革を加速する AWS のシニアソリューションアーキテクトです。彼はフルスタック開発と ML を専門とし、フロントエンドインターフェース、IoT アプリケーション、データ統合、ML モデルにまたがるエンドツーエンドソリューションを設計し、特にコンピュータビジョンとマルチモーダルシステムに焦点を当てています。

SovikSovik Kumar Nath は、AWS の AI/ML および生成 AI シニアソリューションアーキテクトです。彼は、金融、運用、マーケティング、医療、サプライチェーン管理、IoT におけるエンドツーエンドの ML およびビジネス分析ソリューションの設計において豊富な経験を持っています。彼は南フロリダ大学とスイスのフリブール大学で修士号を、インド工科大学カラグプール校で学士号を取得しています。仕事以外では、Sovik は旅行、フェリーライド、映画鑑賞を楽しんでいます。

SaurabhSaurabh Trikande は、Amazon Bedrock と Amazon SageMaker Inference のシニアプロダクトマネージャーです。彼は顧客やパートナーとの協力に情熱を持ち、AI の民主化という目標に動機づけられています。彼は、複雑な AI アプリケーションのデプロイ、マルチテナントモデルでの推論、コスト最適化、生成 AI モデルのデプロイをより身近にすることに関連するコアチャレンジに焦点を当てています。余暇には、Saurabh はハイキング、革新的技術について学ぶこと、TechCrunch をフォローすること、家族と時間を過ごすことを楽しんでいます。

GarethGareth Jones は、Claude API に焦点を当てた Anthropic のプロダクトマネージャーです。彼の仕事には、Claude を開発者に広くアクセス可能にするための Amazon Bedrock での AWS との協力が含まれます。