Claude Opus 4.7 ベストプラクティス

Opus 4.7へのアップグレードを雑にやってしまう人は多いです。モデルIDを変えて、Opus 4.6のときと同じように作業を続ける。

それだと多くを取りこぼします。

Anthropicが出しているOpus 4.7向けガイダンスは微妙だけど重要です: エフォートが高いほど深く考え、ツール呼び出しやサブエージェントの起動はより慎重になり、指示をより文字通りに読み取り、30秒ごとに指示を出すペアプログラマーではなく、仕事を任せた有能なエンジニアとして扱ったときにパフォーマンスが上がります。

このページはそのアドバイスの実践版です。Anthropicのローンチガイダンス、Claude Codeドキュメント、実際のエンジニアリングワークフローで重要になるパターンをまとめています。

リリースの詳細はClaude Opus 4.7を、ドメイン別の例はClaude Opus 4.7 use casesを参照してください。

すぐできる改善

Opus 4.7でまず一つだけ習慣を変えるなら、これを使ってください:

Here is the task, the constraint set, the files that matter, and the definition of done.
Do the full job, validate before you report back, and call out missing information instead of guessing.

このシフトが重要な理由は一つ: Opus 4.7は、最初のターンで考え、計画し、実行するのに十分な余裕を与えられたときに最もパフォーマンスが良いからです。5回の修正フォローアップが必要になる状況を作ると逆効果です。

1. Opus 4.7をペアプログラマーではなく、任せた相手として扱う

これが最も重要なメンタルモデルの転換です。

以前のコーディングワークフローはよくこんな感じでした:

1. 曖昧なプロンプトを出す
2. 部分的な試みを待つ
3. もう一つ明確化を加える
4. アプローチを修正する
5. さらに制約を加える

このスタイルはOpus 4.7では高くつきます。ユーザーターンが増えるたびに推論オーバーヘッドが加算され、難しい作業に本当に使いたいインタラクティブなループへとモデルを引き込んでしまいます。

良いパターンはこうです:

1. 最初のターンで仕事を明確に述べる
2. 実際の制約と受け入れ基準を含める
3. 途中で割り込む前に、モデルが作業を進める余裕を持たせる
4. 細かいステップを管理するのではなく、意味のあるチェックポイントで結果を確認する

悪い最初のターン:

Help me fix auth.

良い最初のターン:

Fix the OAuth redirect loop where successful login returns users to /login instead of /dashboard.

Constraints:
- keep the existing session format
- do not change provider configuration
- update tests if needed

Relevant areas:
- src/lib/auth.ts
- src/middleware.ts
- app/login/*

Definition of done:
- login succeeds
- user lands on /dashboard
- no redirect loop
- tests pass

これはプロンプトエンジニアリングの見せ技ではありません。単純に、より良い引き継ぎ方です。

2. 最初のターンに情報を詰め込む

AnthropicのOpus 4.7ベストプラクティス記事が繰り返し強調しているのはここです: 仕事が本物なら、最初から完全なブリーフを渡してください。

最初のターンに通常含めるべきもの:

• 実際のタスク
• 成功の定義
• 変えてはいけないもの
• 重要なファイル、サービス、ディレクトリ
• 参照すべき既存のパターン
• 結果の検証方法

回避したい二つの失敗パターンがあります:

• 仕様不足: モデルが意図を推測しなければならない
• ターンごとのパッチ: モデルが最初のブリーフに含まれているべきだった修正を取り込むたびに推論コストが発生する

良い構造:

Task:
[what to build, fix, review, or investigate]

Constraints:
- [what must stay true]
- [what must be avoided]

Relevant context:
- [files, routes, services, tickets, docs]

Definition of done:
- [observable outcome]
- [verification step]

このパターンはコーディング、レビュー、セキュリティ、ドキュメント、マルチモーダル作業に対応します。

3. デフォルトは max ではなく xhigh

Opus 4.7は新しい xhigh エフォートティアを追加し、Claude Codeがそこをデフォルトにしたのにはわけがあります。

xhigh はほとんどの知性が必要なコーディング作業のベストデフォルトです。深い推論のメリットの大部分を捉えつつ、長いタスクで max が引き起こす「暴走した思考」の動作を避けられます。

実用的なルール:

迷ったら xhigh から始めてください。

high に下げるとき:

• 複数のセッションを同時実行しているとき
• 難しいけど存亡をかけたタスクではないとき
• 支出コントロールを強化したいとき

max に上げるのは:

• タスクが異例なほど難しいとき
• 失敗のコストが高いとき
• モデルの上限が本当に必要なとき、「おそらく良くなる」ではなく

よくある間違いは安全に感じるからと max をつけっぱなしにすること。大抵そうではありません。単にモデルが必要以上に遅くて冗長になるだけです。

4. 必要な思考の深さをプロンプトで伝える

Opus 4.7はアダプティブシンキングを使うため、いつ深く考えていつ素早く動くかをモデル自身が判断します。これは通常は良いことです。それでも方向付けは可能です。

より多くの思考が欲しいとき:

This problem is subtle. Think carefully and step by step before acting.
Verify assumptions before you edit anything.

より少ない思考が欲しいとき:

Prioritize a direct answer over deep reasoning.
Be concise and only inspect additional files if necessary.

これは慎重に使ってください。12個のメタ指示を積み重ねるのはやめましょう。1〜2行で十分です。

より多くの思考が有効なユースケース:

• アーキテクチャの変更
• マイグレーション
• コードレビュー
• セキュリティとリスク分析
• 不完全な証拠による調査

より少ない思考が有効なユースケース:

• すでに指定したファイルへのピンポイントの編集
• クイックリファレンス質問
• シンプルな機械的リファクタリング

5. ツールをいつ使うか明示的に伝える

AnthropicはOpus 4.7がデフォルトでツールをより少なく使い、行動する前にもっと推論するとはっきり述べています。これは通常は改善です。ただし、明示的に伝えない限り、モデルが思ったより少ししか調べないこともあります。

積極的な調査が必要なら、明示してください。

こう書く代わりに:

Review this service for bugs.

こう書きます:

Review this service for bugs.
Read the relevant implementation files before concluding.
Use search and file reads aggressively where needed.
Do not rely on assumptions if you can verify them from the codebase.

これが重要な場面:

• コードレビュー
• デバッグ
• セキュリティレビュー
• 大規模コードベースの調査
• ソースに基づいた執筆

モデルが「ツールが苦手」になったわけではありません。単により選択的になっています。必要なポリシーを明示してください。

6. サブエージェントをいつ使うか伝える

Anthropicはさらに、Opus 4.7がデフォルトでサブエージェントをより少なく生成すると述べています。これも通常は合理的です。常に望むものとは限りません。

並列化でメリットがある仕事なら、最初のターンでそう伝えてください。

例:

Use subagents when the work naturally splits.
Spawn multiple subagents in the same turn when fanning out across independent files or domains.
Do not spawn a subagent for work you can complete directly in one response.

並列化を強制する良い場面:

• 独立した複数のファイルをレビューするとき
• 複数のドキュメントやログを比較するとき
• 異なるドメインを別々に監査するとき: フロントエンド、バックエンド、データベース
• 実装前にコードベースを並列で読むとき

並列化を強制すべきでない場面:

• 単一ファイルの修正
• 密結合した編集
• ステップBの出力がステップAに依存するタスク

Opus 4.7はデフォルトでより慎重です。それで構いません。ワークフローがそれに依存する場合は、オーケストレーションポリシーを指定する必要があります。

7. インタラクティブな作業ではユーザーターンを減らす

これはAnthropicの最も明確な推奨の一つであり、最も無視されやすいものでもあります。

余分なユーザーターンはオーバーヘッドを追加します。インタラクティブに作業しているなら、ドリップフィードではなく、質問と修正をまとめてください。

悪い例:

Actually change the schema too.

それから:

Also update tests.

それから:

Do not touch the billing UI.

良い例:

Update the auth flow and schema, update tests, but do not modify the billing UI.
Keep the session format unchanged.

これは「割り込むな」という意味ではありません。有意義な境界で割り込んでください、数秒ごとではなく。

8. Autoモードはブリーフが良いときだけ使う

AutoモードとOpus 4.7は長いタスクで相性が良いですが、スコープが明確なときに限ります。

Autoモードが最も有効な場面:

• タスクが明確に定義されているとき
• リポジトリや環境が慣れ親しんでいるとき
• 大まかな方向性を信頼しているとき
• 許可の割り込みを少なくしたいとき

Autoモードが向かない場面:

• タスクが本番や共有インフラに触れるとき
• 目標がまだ曖昧なとき
• 人間の判断が多く求められるとき
• 環境自体が信頼できないか未知のとき

うまくいく手順:

1. 良い最初のターンのブリーフを書く
2. プランが正気かどうか確認する
3. タスクが明確に範囲が決まっているならAutoモードに切り替えて実行させる

弱いブリーフを補うためにAutoモードを使わないでください。それはただモデルを間違った方向に速く動かすだけです。

9. 許可のフリクションをクリックし続けるのではなく削減する

Boris ChernyによるOpus 4.7ローンチ当日の最良のアドバイスの一つは、モデルレベルではなく運用レベルのものでした: モデルがより長く自律的に動くなら、古い許可ワークフローがボトルネックになります。

二つのクリーンな解決策があります:

明確に範囲が決まった作業のためのAutoモード

タスクが明確で環境が信頼できるなら、Autoモードはバックグラウンドの安全チェックを維持しながら「承認、承認、承認」のループのほとんどを取り除きます。

適している場面:

• 長いリファクタリングで慣れたリポジトリのとき
• 完了の定義が明確な実装作業のとき
• 全体的な方向を信頼している調査のとき

適していない場面:

• 未知の環境
• 本番に影響する作業
• モデルにまだ強力な操舵が必要な曖昧なタスク

詳細な仕組みはClaude Code Auto Modeと公式の許可モードドキュメントを参照してください。

繰り返される安全なコマンドのための /fewer-permission-prompts

Borisはまた新しい /fewer-permission-prompts スキルを取り上げました。アイデアはシンプルです: Claudeが繰り返しブロックされているものをスキャンし、明らかに安全な繰り返しコマンドを永遠にクリックし続ける代わりに明示的な許可ルールに変える。

これはどちらの極端よりもずっと良いOpus 4.7のワークフローです:

• 同じ無害なコマンドを20回手動で承認する
• 完全なバイパスモードに直接ジャンプする

目標は「安全ゼロ」ではありません。「無意味な割り込みを減らす」ことです。

10. 長い自律的な実行には要約と集中モードを使う

Opus 4.7は実行させると良くなります。それにより二つのUI的な習慣がより価値を持ちます。

要約（Recaps）

Claude Codeは 2.1.108 で要約（recaps）を実装しました、Opus 4.7の直前です。Borisがそれを強調したのには理由があります: 10分後か2時間後に長い実行中のセッションに戻るとき、スクロールバックから状態を再構築しようとするよりも短い要約の方が優れています。

要約が特に有効な場面:

• タスクをバックグラウンドにしたとき
• その日の後でセッションに戻るとき
• 長い実行が多くのファイルやフェーズに触れたとき
• 「何が起きた/次は何か」のサマリーを素早く得たいとき

要約はただの要約ではなく、セッション再エントリーのツールとして考えてください。

フォーカスモード

Borisはまた、CLIの新しいフォーカスモードを取り上げました。タイミングは理にかなっています: Opus 4.7が独立して調査、編集、検証できることを信頼するようになると、トランスクリプトの詳細が視覚的ノイズになることがあります。

フォーカスモードが有効な場面:

• ライブのトランスクリプトよりも最終結果を重視するとき
• モデルが正確に長いコマンドシーケンスを実行しているとき
• 中間アクションをすべて見るのではなく、最終状態をレビューしたいとき

これは価値のあるワークフローの変化です。モデルが強くなるほど、ボトルネックが「できるか?」から「実際にどれだけの作業を見る必要があるか?」に移ります。

11. エフォートを意図的に設定する

Borisのスレッドはまた、AnthropicのドキュメントがはるかにL明確にしていることを強調しました: エフォートを隠れた設定ではなく、ファーストクラスのコントロールとして扱う。

実用的なルール:

• 素早い回答と低コストのためには低いエフォート
• 難しいエンジニアリングとレビュー作業のためには高いエフォート
• 「最高エフォート」が常にベストなワークフローだと思い込まない

これはOpus 4.7においてより重要です。アダプティブシンキングにより、モデルが古い固定バジェットスタイルよりずっと自然にスケールアップ・ダウンできるからです。

デフォルトを維持:

• 素早い編集と軽量なQ&Aには low または medium
• 安価でも実力のある作業ティアが欲しいときは high
• 本格的な日常エンジニアリングには xhigh
• 本当に難しく、失敗コストが高いタスクには max

エフォートを無視すると、Opus 4.7の最大のコントロールの一つを使っていないことになります。

12. タスクが変わったら新しいセッションを始める

Opus 4.7には100万トークンのコンテキストウィンドウがあります。それは一つの不死身のセッションにすべての仕事を詰め込むべきという意味ではありません。

Anthropicのセッション管理ガイダンスはシンプルです: タスクが変わったら、新しいセッションを始める。

現在のセッションを続ける場面:

• 次のステップが同じタスクの一部であるとき
• 現在のコンテキストがまだ関連しているとき
• 同じファイルを再度読むのが無駄なとき

新しいセッションを始める場面:

• 別のタスクに切り替えるとき
• セッションに複数の失敗したアプローチが蓄積されたとき
• すでに2〜3回モデルを修正したとき
• コンテキストにシグナルよりもノイズが多くなったとき

ツールを積極的に使ってください:

• 関連のないタスクには /clear
• 最後の作業ブランチが間違っていたときは /rewind
• 繊細なデバッグの最中ではなく、自然なマイルストーンで /compact
• メインスレッドをクリーンに保つために調査にはサブエージェント

大きなコンテキストは助けになります。コンテキストの劣化は依然として実在します。

13. 検証ハーネスをOpus 4.7に与える

この点はBorisのスレッドで明確に出てきており、Anthropic自身のガイダンスとも一致しています: Opus 4.7から最大の飛躍を得たいなら、実際に成功したかどうかを確認する方法を与えてください。

Opus 4.7の最良の特徴の一つは、自分の作業を検証しようとすることです。それを助けてください。

明示的な検証の言葉を追加してください:

Before you report done:
- verify assumptions you relied on
- run the relevant tests
- check the final changed files for consistency
- list remaining risk, if any

これが特に重要な場面:

• マイグレーション
• 認証の変更
• 並行処理の修正
• セキュリティレビュー
• 文書ベースの分析

モデルは以前のバージョンよりも自己確認します。それでも「完了」が具体的な何かを意味するようにしたいです。

検証ハーネスの具体例:

• バックエンド作業: テストコマンド、curlチェック、型付きビルド
• フロントエンド作業: ブラウザチェック、スクリーンショットの差分、lint/buildパス
• リファクタリング: コンパイル + テスト + 古いAPIサーフェスのgrep
• ドキュメントやコンテンツ: ソース資料に対して検証すべき主張のチェックリスト

検証パスがなければ、長い自律性はほぼ長い未検証の実行を意味します。検証パスがあれば、有用な自律性になります。

14. 長い実行にはタスクバジェットを使う

Anthropicはパブリックベータとしてタスクバジェットを導入しました。長いエージェント作業には、モデルに見えない厳しい出力上限だけでなく、モデルに見えるバジェットが必要だからです。

エージェントやAPIワークロードを動かすなら、以下でタスクバジェットをテストしてください:

• 長いリファクタリング
• 調査+実装の仕事
• バックグラウンド自動化
• コードレビューと修正のループ

ベストプラクティスは「常に最大のバジェットを使う」ではありません:

• モデルが完了できる十分な余裕を与える
• バジェットを有限に保つ
• 実際にもっと必要な作業クラスを測定する

Opus 4.7が難しい実行でより高いエフォートでより多くの思考を喜んで使おうとするので、これはより重要になります。

15. マーケティング価格ではなく実際のトークン現実に合わせる

Opus 4.7はOpus 4.6の定価を維持しました。それはワークロードのコストが同じという意味ではありません。

実際のコストは以下の影響を受けます:

• 新しいトークナイザー
• 高いエフォートレベルでの高い推論コスト
• 大きな画像パイプライン
• 作成するユーザーターンの数
• モデルが曖昧なプロンプトから回復しなければならない回数

ベストプラクティスはシンプルです:

• 実際のワークロードでベンチマークを取る
• high 対 xhigh をテストする
• 小さい仕事には小さいエフォートを使う
• フル解像度が不要な画像はダウンサンプルする
• 繰り返すユーザーの明確化を無料だと思い込むのを止める

一部のパートナーは、Opus 4.6が必要としていたより低いエフォートでより良い品質を報告しています。実際のコスト削減はそこから来ます。

16. 保持する価値のある3つのプロンプトテンプレート

テンプレート1: 高リスクの実装

Implement [task].

Constraints:
- [must preserve]
- [must avoid]

Relevant files:
- [file/path]
- [file/path]

Working style:
- think carefully before acting
- verify assumptions from code, not guesses
- use subagents only when the work naturally splits

Definition of done:
- [observable outcome]
- [test or verification]

テンプレート2: レビューと調査

Investigate [problem].

Use tools and file reads aggressively where needed.
Do not guess if the codebase can answer the question.

I want:
- root cause
- files involved
- likely fix
- edge cases or risks

テンプレート3: 文書重点の分析

Review these materials and produce a decision memo.

Requirements:
- separate facts from interpretation
- call out ambiguity explicitly
- list what evidence is missing
- cite the exact source section when possible

17. 最も避けるべき間違い

Opus 4.7を最も無駄にする習慣:

• 曖昧な最初のターン
• 通常の作業でも max をつけっぱなしにする
• どのコマンドが安全かわかった後も、デフォルトの許可フリクションを維持する
• 要約を無視して長いセッション内で手動で状態を再構築する
• フォーカスモードでレビューが楽になるのに、すべてのトランスクリプト行を監視する
• 指示なしでモデルが積極的に調査してくれると思い込む
• 古いワークフローのようにサブエージェントに自動的にファンアウトしてくれると思い込む
• 関係のないタスクを一つのセッションに積み重ねる
• 定価だけでコストを判断する

「Opus 4.7は高すぎる」という不満の大半は、実際には価格ラベルをつけたワークフローの問題です。

参考資料

• Best practices for using Claude Opus 4.7 with Claude Code
• Using Claude Code: session management and 1M context
• Claude Code best practices docs
• Claude Code permission modes
• Claude Code changelog
• Claude Code commands
• Boris Cherny, launch-day X thread on Opus 4.7 workflow tips, April 16, 2026
• Introducing Claude Opus 4.7

関連ページ

• Claude Opus 4.7
• Claude Opus 4.7 use cases
• Claude Code Pricing and Token Usage
• Claude Code Auto Mode
• Claude Code Models