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

多くの人は Opus 4.7 へのアップグレードを手抜きで行う。モデルIDを変えて、Opus 4.6 と同じように作業を続けるだけだ。

それでは多くのものを取りこぼすことになる。

Anthropic が Opus 4.7 向けに示したガイダンスは、細かいながらも重要だ。このモデルは effort が高いほどより深く考え、ツール呼び出しやサブエージェントの使用をより選択的に行い、指示をより文字通りに読み取り、30秒ごとに介入するおしゃべりなペアプログラマーではなく、仕事を委任できる優秀なエンジニアとして扱うことでパフォーマンスが向上する。

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

リリース概要については Claude Opus 4.7 を、ドメイン別の具体例については Claude Opus 4.7 のユースケース を参照。

すぐに使えるコツ

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. 最初のターンに情報を前倒しする

Opus 4.7 に関する Anthropic のベストプラクティス投稿は繰り返しこの点に言及している: 仕事が本物なら、モデルに最初から完全なブリーフィングを与えよう。

最初のターンには通常、以下を含めるべきだ:

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

二つの失敗パターンを排除しようとしている:

• 仕様不足: モデルがあなたの意図を推測しなければならない
• ターンごとのパッチ当て: モデルが元のブリーフに含まれているべき修正を取り込むために毎回推論コストを払い続ける

良い構造:

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 effort 階層を追加し、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個のメタ指示を積み重ねないように。一行か二行で十分だ。

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

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

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

• 既に名指しされたファイルへの局所的な編集
• クイックリファレンス質問
• 単純な機械的リファクタリング

5. ツールを使うタイミングを Opus 4.7 に伝える

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レベルの習慣がより価値を持つ。

リキャップ

Claude Code は Opus 4.7 の直前の 2.1.108 でリキャップを導入した。Boris がこれを強調したのには理由がある: 10分後や2時間後に長時間実行中のセッションに戻るとき、スクロールバックから状態を再構築しようとするよりも短いリキャップの方が良い。

リキャップが特に役立つ場合:

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

リキャップをセッション再参入として考えよう。単なるサマリーではない。

フォーカスモード

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

フォーカスモードが役立つ場合:

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

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

11. Effort を意識的に設定する

Boris のスレッドは Anthropic のドキュメントが現在はるかに明確にしていることを強調した: effort を隠れた設定ではなく、一級の制御として扱う。

実践的なルール:

• 速い回答と低支出のために低い effort
• 難しいエンジニアリングとレビュー作業のために高い effort
• 「最高の effort」が常に最良のワークフローだと思わない

Opus 4.7 ではアダプティブシンキングにより、モデルが古い固定予算スタイルよりもはるかに自然にスケールアップまたはダウンできるため、これがより重要になる。

これらのデフォルトを維持しよう:

• 素早い編集と軽量な Q&A には low または medium
• 安価だが十分有能な作業層が必要な場合は high
• 日常的な本格的なエンジニアリングには xhigh
• 本当に難しく、失敗コストが高いタスクには max

effort を無視すると、Opus 4.7 の最大の制御の一つを使わないままにすることになる。

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

Opus 4.7 には 1M コンテキストウィンドウがある。それはすべての仕事を一つの不滅のセッションに入れ続けるべきだという意味ではない。

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/ビルドパス
• リファクタリング: コンパイル + テスト + 古い API サーフェスの grep
• ドキュメントやコンテンツ: ソース資料に対して検証すべき主張のチェックリスト

検証パスなしでは、より長い自律性はほとんどの場合、より長い未検証の実行を意味する。検証パスがあれば、有用な自律性になる。

14. 長い実行にはタスク予算を使う

Anthropic はパブリックベータとしてタスク予算を導入した。なぜなら、より長いエージェント作業には、モデルが見えないハード出力制限ではなく、モデルが見える予算が必要だからだ。

エージェントや API ワークロードを実行する場合、以下でタスク予算をテストしよう:

• 長いリファクタリング
• リサーチ + 実装ジョブ
• バックグラウンド自動化
• コードレビューと修正ループ

ベストプラクティスは「常に最大の予算を使う」ことではない:

• モデルに完了するための十分な余裕を与える
• 予算を有限に保つ
• 実際により多くを必要とする作業クラスを測定する

これは Opus 4.7 でより重要になる。なぜなら、モデルは難しい実行で高い effort でより多くの思考を費やすことを厭わないからだ。

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

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

実際のコストは以下に影響される:

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

ここでのベストプラクティスはシンプルだ:

• 実際のワークロードでベンチマーク
• high 対 xhigh のテスト
• 小さなジョブには小さな effort を使う
• 完全な忠実度が不要な画像はダウンサンプリング
• 繰り返しのユーザー確認を無料だと考えるのをやめる

一部のパートナーは Opus 4.6 が必要としたよりも低い effort でより良い品質を報告した。実践的なコスト削減はそこから来る。

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 のユースケース
• Claude Code の価格とトークン使用量
• Claude Code Auto モード
• Claude Code モデル