公式ブログを参考に、Claude Opus 4.7 を使うときのベストプラクティスをまとめてみた
こんにちは。
Mythos の読み方は「みそす」派
オペレーション部のかわいです。
いきなりですが、Anthropic が Claude Opus 4.7 のベストプラクティス記事を公開しました。
Opus 4.7 は、特にコーディング用途での性能が大きく向上したモデルで、Claude Code のエージェントとして使う際のお作法が少し変更されています。
本記事では Opus 4.7 のベストプラクティスを、公式ブログをベースに備忘録がてらに紹介したいと思います。
本記事で書くこと
- effort レベルの選び方
- 最初の会話で何を伝えるべきか
- thinking budget 廃止と、何が変わったか
- Opus 4.7 が得意なこと
また、Claude Opus 4.7 は 2026年4月16日に Amazon Bedrock でも利用可能になっており、ベンチマークスコア等も既に公表されています。
effort レベルは xhigh から始めましょ
Opus 4.7 から effort レベルに xhigh が追加されました。
これは high と max の間に位置する新しいレベルで、Opus 4.7 のデフォルト として設定されています（他モデルでは high）。
| effort | 使いどころ |
|---|---|
| low / medium | コスト・速度優先。軽い質問や確認タスク |
| high | 複数セッションを並列で動かすとき等 |
| xhigh | 通常のコーディングタスク（Opus 4.7 デフォルト値） |
| max | 難しい問題限定。収穫逓減（*トークン増加に対して性能向上が頭打ちになりやすく、場合により過度な思考傾向あり） |
※ /effort コマンド（v2.1.111 以降）でレベルを動的に切り替えられます。詳しくは以下参照
最初のターンでコンテキストを全部乗せる
公式ブログで強調されているのが、初回の情報集約です。
Specify the task up front, in the first turn. Well-specified task descriptions that incorporate intent, constraints, acceptance criteria, and relevant file locations give Opus 4.7 the context it needs to deliver stronger outputs. Ambiguous prompts conveyed progressively across many turns tend to reduce both token efficiency and, sometimes, overall quality.
- やりたいこと
- 制約条件
- ファイルの場所
ドキュメントでは、この3つを可能な限り最初のメッセージにぜんぶ盛り込むことが推奨されています。
後から「あ、これも忘れてたから追加して」と追加するたびに Opus は状況を再評価するので、その分のトークンと時間がかかります。
公式ドキュメントによると、段階的に情報を追加するスタイルはトークン効率だけでなく、パフォーマンス自体も低下させる傾向があるとのこと。
Ambiguous prompts conveyed progressively across many turns tend to reduce both token efficiency and, sometimes, overall quality.
なので、できるだけ質問もまとめて送ります。
「これってどういう意味？」「このファイルどこ？」を1回ずつ送るより、まとめて聞いた方が効率がいいです（難しいときもあるのでベストエフォートで）。
thinking budget は廃止され、適応的思考に変更
以前は "thinking_budget": 10000 のように「何トークン分考えさせるか」を指定できました。
Opus 4.7 ではこの固定バジェット方式は廃止され、適応的思考（adaptive thinking） という仕組みに置き換わっています。
"Extended Thinking with a fixed thinking budget is not supported in Opus 4.7. Instead, Opus 4.7 offers adaptive thinking. This makes thinking optional at each step and allows the model to decide when to use more thinking based on context."
適応的思考では、モデル自身がタスクの複雑さを判断して thinking の量を決めます。
シンプルなクエリでは thinking をスキップして直接回答し、複雑なクエリでは深く推論する挙動を取ります。
※effort レベルが外部から制御できる調整手段、という位置づけはそのままです。
もちろん「もっと深く考えて」「手短に」といった自然言語での指示は引き続き有効です。
ツール呼び出しより推論を優先するようになった
Opus 4.6 以前は「とりあえずファイルを読む」「とりあえず grep する」といった、ツール優先の動きが目立ちました。
Opus 4.7 は状況を推論してからツールを呼ぶ傾向に変わったようです。
The model calls tools less often and reasons more.
サブエージェントの生成も選択的になりました。並列実行が有効な場面では明示的に指示すると動きます。
It spawns fewer subagents by default. Opus 4.7 tends to be more judicious about when to delegate work to subagents.
「並列で」「同時に」といった言葉を入れると、Opus 4.7 がサブエージェントを生成する判断をしやすくなります。
応答の長さがタスクに比例するようになった
Opus 4.6 以前では、回答量が多く感じることがありました（当社比）。
Opus 4.7 はタスクの複雑さに応じて応答の長さを自動調整するようになっています。
Response length is calibrated to task complexity. Opus 4.7 isn't as default-verbose as Opus 4.6. You can expect shorter answers on simple lookups and longer ones on open-ended analysis.
単純な質問には短く、オープンエンドの分析には長く、という具合です。
Opus 4.7 が得意な場面
▼ 公式ガイドに記載されているユースケースです
Opus 4.7 performs better on long-running tasks than prior models...complex multi-file changes, ambiguous debugging, code review across a service, and multi-step agentic work.
- 複数ファイルにまたがる複雑な変更
- 問題が明確でない状況からのデバッグ
- サービス全体のコードレビュー
- マルチステップのエージェントワーク
反対に、単純な質問や1ファイルへの小さな変更は Sonnet 4.6 等、低コストモデルで十分です。
Claude Code の /model でセッション中にモデルを切り替えられるので、タスクに応じて使い分けるのが理想です。
まとめ的な
本記事では、Anthropic 公式の Opus 4.7 Claude Code ベストプラクティスガイドの要点を簡易的にまとめました。
大きな変更点は「thinking budget の廃止」と「effort レベルの追加（xhigh）」の2点です。
どちらも Opus 4.7 自身が判断する方向への設計変更で、会話の初回ターンで十分な情報を渡すことの重要性が増した印象です。
Mythos の件もありますし、今後のモデル展開が楽しみです。では！
完
【参考リンク】
