Claude Opus 4.6の主要機能をAmazon Bedrock上で利用する方法
はじめに
皆さん、Claude Opus 4.6 を早速使ってますか？ 本記事では、Claude Opus 4.6で利用可能な主要機能について、各機能の概要と Amazon Bedrock上での具体的な実装コード を紹介していきます。
Claude Opus 4.6 とは
Claude Opus 4.6 は、Anthropicが2026年2月5日に発表した最新フラッグシップモデルです。前モデルからコーディング能力が向上し、より慎重な計画立案、長時間のエージェントタスク持続、大規模コードベースでの信頼性向上、自身のミスを発見できるコードレビュー・デバッグ能力を備えています。Opusクラス初の100万トークンコンテキストウィンドウ（Beta）に対応。また、財務分析、リサーチ、ドキュメント・スプレッドシート・プレゼンテーションの作成・編集など日常業務にも活用できます。
本記事で取り扱う機能
| 機能 | 概要 |
|---|---|
| Adaptive Thinking + Effort | リクエストの複雑さに応じてClaudeが自律的に思考の深さを調整。effortパラメータで思考量をガイド |
| 1M コンテキストウィンドウ (Beta) | デフォルト200Kトークンを1Mトークンに拡張。大量のドキュメントやコードベースを一度に処理可能 |
| 最大128K 出力トークン | 出力トークンの上限を128Kまで指定可能。長文のコード生成や翻訳、レポート作成に有用 |
| 構造化出力: JSON Outputs | LLMのレスポンスを指定したJSON Schemaに厳密に準拠させ、パースエラーのない出力を保証 |
| Compaction (Beta) | 長い会話でトークン数がしきい値を超えた際、会話を自動要約して圧縮し継続可能にする |
InvokeModel API / Converse API について
本記事のコードは InvokeModel API (bedrock.invoke_model) を使って説明します。InvokeModel API は Anthropic Messages API 形式のリクエストボディを直接送信でき、Bedrockが対応しているClaudeの機能を全て利用できます。
Converse API (bedrock.converse) はモデル非依存の統一チャットインターフェースであり、基本はこちらの利用を推奨していますが、2026年2月時点で Compaction 等の一部機能に未対応のため、ここではInvokeModelに揃えて説明します。なお、Converse API での書き方はNotebookのAppendixに記載しています。
以下はInvokeModelを利用する際の基本的なコードです。
import boto3
import json
from botocore.config import Config
MODEL_ID = "global.anthropic.claude-opus-4-6-v1"
session = boto3.Session()
bedrock = session.client(
"bedrock-runtime",
region_name="ap-northeast-1",
config=Config(read_timeout=300), # デフォルト60秒 → 300秒に延長
)
body = json.dumps({
"anthropic_version": "bedrock-2023-05-31",
"max_tokens": 256,
"messages": [
{
"role": "user",
"content": "日本の首都はどこですか？"
}
],
})
response = bedrock.invoke_model(
modelId=MODEL_ID,
body=body
)
result = json.loads(response["body"].read())
text = result["content"][0]["text"]
1. Adaptive Thinking + Effort
Adaptive Thinking は Claude Opus 4.6 で推奨される思考モードです。
従来の Extended Thinking では固定の thinking token budget (budget_tokens) を手動設定する必要がありましたが、Adaptive Thinking ではリクエストの複雑さに応じて Claude が 「考えるかどうか」「どの程度深く考えるか」 を自律的に判断します。Adaptive Thinking は Interleaved Thinking（ツール使用の合間にも思考を挟む機能）も自動的に有効化します。
Effort パラメータ
output_config.effort を指定することで、思考量のガイダンスを与えられます。Opus 4.6 では新たに max レベルが追加されました。
| effort level | 挙動 |
|---|---|
max |
常に思考し、思考の深さに制約なし (Opus 4.6 専用) |
high (デフォルト) |
常に思考する。複雑なタスクで深い推論を行う |
medium |
適度に思考する。非常に簡単な質問では思考をスキップする場合がある |
low |
思考を最小限にする。速度優先の簡単なタスクで思考をスキップ |
Adaptive Thinking で使われる thinking トークンは 出力トークンとして課金 され、max_tokens の対象に含まれます。
実装コード
リクエストボディに thinking と output_config を追加します。
body = json.dumps({
"anthropic_version": "bedrock-2023-05-31",
"max_tokens": 4096,
"messages": [
{
"role": "user",
"content": "LLMに途中の思考を言語化させる(CoT)と精度が上がるのはなぜか。モデルの中で何が起きているのか",
}
],
"thinking": {"type": "adaptive"},
"output_config": {"effort": "medium"},
})
response = bedrock.invoke_model(modelId=MODEL_ID, body=body)
result = json.loads(response["body"].read())
# レスポンスの content 配列から thinking / text ブロックを取り出す
for block in result["content"]:
if block["type"] == "thinking":
print(f"[思考] {block['thinking']}...")
elif block["type"] == "text":
print(f"[回答] {block['text']}...")
レスポンス構造の違い
Adaptive Thinking が有効な場合、effortレベルとリクエストの複雑さ によってレスポンスの構造が変わります。
thinking あり — 複雑な質問や高effortの場合、content 配列に thinking ブロックと text ブロックが混在します。thinking ブロックには内部思考と改ざん防止用の signature が含まれます（マルチターン時にそのまま返す必要があります）。
{
"content": [
{"type": "text", "text": "\n\n"},
{
"type": "thinking",
"thinking": "...(内部思考)...",
"signature": "...(改ざん防止用署名)..."
},
{"type": "text", "text": "回答..."}
],
"usage": {"input_tokens": 100, "output_tokens": 500}
}
thinking なし — effort=low で「日本の首都はどこですか？」のような簡単な質問を投げると、Claude は思考をスキップし text ブロックのみが返ります。thinking ブロックが生成されない分 output_tokens が大幅に少なくなり、レイテンシ・コストともに低く抑えられます。
{
"content": [
{"type": "text", "text": "日本の首都は**東京**です。"}
],
"usage": {"input_tokens": 97, "output_tokens": 16}
}
タスクの複雑さに応じて effort レベルを使い分けることで、コストとパフォーマンスのバランスを取ることができます。
2. 1M コンテキストウィンドウ (Beta)
Claude Opus 4.6 のデフォルトは 200K (20万) トークン のコンテキストウィンドウですが、beta flag を指定することで 1M (100万) トークン まで拡張できます。
1Mトークンは、ハリー・ポッターと賢者の石 約3冊分に相当する量です。大量のドキュメント分析、長大なコードベースの理解、膨大なログの検索などに有用です。
実装コード
リクエストボディに anthropic_beta を追加するだけです。モデルIDは通常と同一です。
body = json.dumps({
"anthropic_version": "bedrock-2023-05-31",
"anthropic_beta": ["context-1m-2025-08-07"], # 1M コンテキストを有効化
"max_tokens": 256,
"messages": [{"role": "user", "content": prompt}], # 大量テキストを含むprompt
})
response = bedrock.invoke_model(modelId=MODEL_ID, body=body)
result = json.loads(response["body"].read())
print(result["content"][0]["text"])
count_tokens による事前見積もり
大量のテキストを送信する前に bedrock.count_tokens() で入力トークン数を事前に確認できます。API呼び出しなしでトークン数が分かるため、コスト見積もりやコンテキストウィンドウ超過の防止に有用です。
# count_tokens はベースモデルIDのみ対応 (global.から始まるプロファイルは不可)
response = bedrock.count_tokens(
modelId="anthropic.claude-opus-4-6-v1",
input={"invokeModel": {"body": body}},
)
print(f"推定入力トークン: {response['inputTokens']:,} tokens")
注意点:
-
count_tokensは ベースモデルID (anthropic.claude-xxxx) のみ対応。Cross-region inference profile (global.anthropic.claude-xxx) は指定不可 - 結果は実際の
usage.input_tokensより約20トークン多い（内部システムトークンを含むため。課金対象外） -
count_tokens自体は無料（レート制限あり）
Notebookでは、約100万トークンのダミーテキストの中にパスフレーズを埋め込むNeedle-in-Haystackテストを実施し、正確に抽出できることを確認しています。
3. 最大128K 出力トークン
Claude Opus 4.6 では max_tokens を最大 128,000トークン まで指定できます（従来のOpus/Sonnet 4.5では64Kが上限）。長文のコード生成、翻訳、レポート作成などに有用です。
100Kトークン規模の出力は数10分掛かりうるので、invoke_model_with_response_streamの利用や、非ストリーミングでは read_timeout の設定変更を推奨します。
実装コード
以下は、invoke_model_with_response_streamを利用してストリームで最大128Kトークンの文章を出力させるサンプルです。
body = json.dumps({
"anthropic_version": "bedrock-2023-05-31",
"max_tokens": 128000,
"thinking": {"type": "adaptive"},
"output_config": {"effort": "max"},
"messages": [
{"role": "user", "content": "長文の出力を要求するプロンプト..."}
],
})
response = bedrock.invoke_model_with_response_stream(modelId=MODEL_ID, body=body)
4. 構造化出力 (Structured Outputs)
Structured Outputs は、LLMのレスポンスを 指定したスキーマに厳密に準拠した形式に制約する 機能です。
通常のLLM出力は自由形式のテキストなので、プログラムで後処理する際に JSONのパースエラー、必須フィールドの欠落、型の不一致、リトライ処理の必要性 といった問題が起こり得ます。Structured Outputs は Constrained Decoding（制約付きデコーディング） により、これらの問題を根本的に解決します。
AWS Blog や ドキュメント にもBedrockでの利用方法が記載されています。
2つのアプローチ
Structured Outputs には 2つの補完的な機能 があり、独立して使うことも同じリクエスト内で併用することもできます。
| 機能 | パラメータ | 制約対象 | 用途 |
|---|---|---|---|
| JSON outputs | output_config.format |
Claudeのレスポンス形式 | データ抽出、レポート生成、API連携 |
| Strict tool use |
strict: true (Tool定義内) |
Toolの入力パラメータ | エージェントワークフロー、型安全な関数呼び出し |
ここでは JSON outputs を例に説明します。
実装コード
output_config.format にJSON Schemaを指定します。
# 出力スキーマ定義
book_schema = {
"type": "object",
"properties": {
"title": {"type": "string"},
"author": {"type": "string"},
"year": {"type": "integer"},
"genre": {
"type": "string",
"enum": ["fiction", "non-fiction", "science", "history", "philosophy"],
},
"summary": {"type": "string"},
"recommended": {"type": "boolean"},
},
"required": ["title", "author", "year", "genre", "summary", "recommended"],
"additionalProperties": False,
}
body = json.dumps({
"anthropic_version": "bedrock-2023-05-31",
"max_tokens": 1024,
"messages": [
{"role": "user", "content": "「2001年宇宙の旅」という本について教えてください。"}
],
"output_config": {
"format": {
"type": "json_schema",
"schema": book_schema,
}
},
})
response = bedrock.invoke_model(modelId=MODEL_ID, body=body)
result = json.loads(response["body"].read())
# 最後の text ブロックから JSON をパース
parsed = json.loads(result["content"][-1]["text"])
print(json.dumps(parsed, ensure_ascii=False, indent=2))
実行結果:
{
"title": "2001年宇宙の旅",
"author": "アーサー・C・クラーク",
"year": 1968,
"genre": "fiction",
"summary": "人類の進化と宇宙探査をテーマにした...",
"recommended": true
}
スキーマに準拠したJSONが確実に返るため、json.loads() で安全にパースでき、リトライ処理も不要になります。
5. Compaction (Beta)
Compaction は、長い会話セッションでコンテキストウィンドウを効率的に管理するための機能です。
会話が設定したトークンしきい値に近づくと、Claude が自動的に会話の要約を生成し、圧縮されたコンテキストで会話を継続できます。長時間のエージェンティックタスクや、マルチターンの対話型アプリケーションで有用です。Bedrockでの利用方法も公式ドキュメントに記載されています。
動作の流れ：
- 入力トークン数がトリガーしきい値を超えたことを検知
- 現在の会話の要約を生成
- 要約を含む compaction ブロックを作成
- 圧縮されたコンテキストを使って応答を継続、もしくは、一時停止してクライアントに処理を委譲
実装コード
anthropic_beta flag compact-2026-01-12 を指定し、context_management.edits に compaction 設定を記述します。
def invoke_with_compaction(messages):
"""Compaction 対応の invoke_model 呼び出し"""
body = json.dumps({
"anthropic_version": "bedrock-2023-05-31",
"anthropic_beta": ["compact-2026-01-12"],
"max_tokens": 15000,
"messages": messages,
"context_management": {
"edits": [
{
"type": "compact_20260112",
"trigger": {"type": "input_tokens", "value": 50000},
"pause_after_compaction": True,
}
]
},
"thinking": {"type": "adaptive"},
"output_config": {"effort": "high"},
})
response = bedrock.invoke_model(modelId=MODEL_ID, body=body)
return json.loads(response["body"].read())
主要なパラメータは以下の通りです。
| パラメータ | 説明 |
|---|---|
type |
"compact_20260112" を指定 |
trigger |
compaction を発動するタイミング。デフォルト150,000トークン。最低50,000以上 |
pause_after_compaction |
true にすると compaction 後に stop_reason="compaction" で一時停止し、クライアント側でハンドリング可能 |
instructions |
カスタム要約プロンプト（デフォルトプロンプトを完全に置き換える） |
Compaction 発動時の挙動とハンドリング
Notebookのサンプルでは、会話が進むにつれ入力トークンが増加し、trigger のしきい値を超えると自動的にCompactionが発動する様子が見て取れます。
[1/9] input: 1,000
[2/9] input: 8,000
[3/9] input: 16,000
...
[7/9] input: 52,000 → 50,000 超過で Compaction 発動
├─ stop_reason="compaction" で一時停止
├─ クライアントが compaction ブロック + 直近メッセージで再リクエスト
└─ input: 5,000 に大幅削減されて再開
[8/9] input: 13,000
pause_after_compaction=true の場合、Compaction 発動時のレスポンスは stop_reason が "compaction" になり、content[0] に会話の要約が格納されます。
{
"content": [
{
"type": "compaction",
"content": "これまでの会話の要約: ユーザーはWebアプリケーション開発の..."
}
],
"stop_reason": "compaction",
"usage": {"input_tokens": 53000, "output_tokens": 2000}
}
このレスポンスを受け取ったら、クライアント側で compaction ブロック + 直近のメッセージ を使って messages を再構築し、APIを再呼び出しします。以下は、マルチターン会話でCompactionをハンドリングする実装例です。
conversation = [] # 会話履歴
def chat(user_message):
"""ユーザーメッセージを送信し、compaction 発生時はハンドリングして応答を返す"""
conversation.append({"role": "user", "content": user_message})
result = invoke_with_compaction(conversation)
# Compaction が発動して一時停止した場合のハンドリング
if result.get("stop_reason") == "compaction":
compaction_block = result["content"][0]
# compaction ブロック + 直近 2 メッセージで会話を再構築
preserved = conversation[-2:] if len(conversation) >= 2 else conversation[:]
messages_after = [
{"role": "assistant", "content": [compaction_block]}
] + preserved
# 圧縮済みコンテキストで再度呼び出し
result = invoke_with_compaction(messages_after)
conversation.clear()
conversation.extend(messages_after)
# 最終応答を履歴に追加
conversation.append({"role": "assistant", "content": result["content"]})
text_parts = [b["text"] for b in result["content"] if b["type"] == "text"]
return "\n".join(text_parts).strip()
ここでのポイントは、Compaction発動時に conversation[-2:] で直近2メッセージを保持していることです。例えば7回目のユーザーからの質問で発動した場合、compactionブロックの要約に加えて、6回目のClaudeの回答と7回目のユーザーからの質問だけ原文を付与してリクエストする形になります。要約 + 直近の原文で会話の連続性を保ちつつ、入力トークンを大幅に削減できます。
まとめ
本記事では、Claude Opus 4.6 on Amazon Bedrock で利用可能な主要機能を紹介しました。最後に、ユースケース別の使い分けを整理します。
| やりたいこと | 使える機能 | ポイント |
|---|---|---|
| タスクに応じて推論の深さを自動調整したい | Adaptive Thinking + effort |
effort を low 〜 max で切り替え。簡単なタスクは low でコスト削減、複雑な推論は high / max
|
| 大量のドキュメントやコードを一度に処理したい | 1M コンテキスト |
anthropic_beta を追加するだけ。count_tokens で事前見積もりも便利 |
| 長文のコードや翻訳を一度に出力させたい | 最大128K 出力トークン |
max_tokens: 128000 を指定。出力に数10分掛かるので注意 |
| LLMの出力を後続プログラムに構造化して渡したい | 構造化出力: JSON Outputs |
output_config.format にJSON Schemaを指定。パースエラーやリトライが不要に |
| 長いマルチターン会話を破綻なく継続したい | Compaction |
anthropic_beta を付与。context_management を設定しCompactionの挙動は工夫可能 |
Opus 4.6 は単にモデル性能が上がっただけでなく、Adaptive Thinking による思考制御の簡素化、構造化出力による型安全な出力保証、Compactionによる長い会話の管理など、開発者がモデルをプロダクションで使いやすくするための改善 が数多く含まれています。
既存の実装を移行する際は Migration Guide も合わせて確認してください。なお、破壊的変更 として Opus 4.6 では Assistantメッセージのprefill（先頭固定）が廃止 されています。従来 Assistant: { のように回答の書き出しを強制するテクニックを使っていた場合、構造化出力やシステムプロンプトでの指示に置き換える必要があります。
ここまでの内容がAmazon BedrockでClaude Opus 4.6を活用される上でお役に立てば幸いです。それでは、よりよいAmazon Bedrockライフを！
Discussion