Claude Opus 4.7 完全ガイド — 公式情報で読み解くモデル仕様とClaude Codeでの実践ノウハウ

こんにちは！
Qualitegプロダクト開発部です！

2026年4月に、AnthropicからClaude Opus 4.7がリリースされました。

今回のアップデートは、単にベンチマークが上がったという話ではありません。命令の解釈の仕方、応答長、ツール呼び出しの頻度、subagentの起動方針まで、モデルの振る舞いそのものが変わっています。

それに伴い、4.6までに作り込んだプロンプトや設定の一部は、外したり再評価したりする必要があります。本記事では、そうした移行時の落とし穴と、4.7時代に合わせた運用作法を、できるだけ実践的にまとめました。

この記事では、まずOpus 4.7で何が変わったのかを確認し、そのうえでClaude Code CLI版とClaude Code Web版でどう使いこなすべきかを見ていきます。 (通常のclaude.aiチャットUIは対象外です。)

なお、けっこう長めの記事になっているので、
頭から通読していただく必要はありません。

下の目次から、気になるところや今すぐ困っているところだけ拾い読みしていただいて大丈夫です。

たとえば「とりあえず4.6から4.7に上げて何が変わるのか知りたい」という方は第1部の3章だけ、

「Claude Code CLIで明日から使える運用ノウハウが欲しい」という方は第2部の8章と9章だけ、

「Web版を試してみたい」という方は第3部だけ、といった読み方を想定して書いています。

困ったときのリファレンスとしても使えるよう、各章は独立して読めるようにしてあるので、ブックマークしておいて必要なときに戻ってきていただくのもおすすめです。

目次

第1部:Claude Opus 4.7とは何か

1. 4.6から4.7への移行で変わるもの
振る舞いの変更9項目とAPIレベルの破壊的変更5項目の概観です。

2. モデルとしてのClaude Opus 4.7
基本仕様、高解像度画像、新トークナイザー、1Mコンテキストの標準価格化を確認します。

3. 振る舞いの変化 — 4.6から4.7で何が変わったのか
命令解釈、応答長、ツール使用、subagent、トーン、進捗報告など、プロンプト再評価が必要な変化を見ます。

4. 補足:Claude Code利用者も知っておきたいMessages API側の破壊的変更
Messages API直接利用時に影響する変更点を、Claude Code利用者の視点で整理します。

5. 新機能
新effortレベル xhigh、task budgets、ファイルベースメモリの改善を見ます。

第2部:Claude Code CLI版で使うOpus 4.7

6. Claude CodeにおけるOpus 4.7の前提
バージョン要件、エイリアス解決、プラン別デフォルトを確認します。

7. Claude Codeの基本操作 — CLIコマンドの使い方一覧
起動・終了、スラッシュコマンド、設定ファイル、環境変数の早見表です。

8. 日常運用のリズム — Claude Codeをふだんどう使うか
初回ターンへの情報集約、Auto Mode、effort切り替えなど、1日の典型的な使い方を見ます。

9. Effort Levelの使い分け
5段階の定義と使い分け、ultrathink の小ワザを見ます。

10. 1Mコンテキストの正確な扱い方
プラン別の可用性、opus[1m] サフィックス、opusplan の落とし穴を確認します。

11. Claude CodeにおけるAdaptive Reasoning
Opus 4.7では無効化できないという仕様と、誘導の方法を見ます。

12. Opus 4.7を最大限引き出すプロンプティング
依頼書スタイル、肯定形の例示、検証機構などのプロンプト設計の原則を見ます。

13. エンタープライズ運用
モデル制限、Default解決の制御、prompt cachingなど、組織展開時のポイントを確認します。

第3部:Claude Code Web版で使うOpus 4.7

14. Claude Code Web版とは何か
ブラウザで動くクラウド実行環境としての立ち位置を、CLI版との違いとともに見ます。

15. Web版を使い始める — GitHub連携と環境設定
GitHub認証、Environment、セットアップスクリプト、ネットワークアクセスを見ます。

16. ターミナルとWeb版を行き来する
--remote と --teleport を使った連続的な作業パターンを見ます。

17. Web版でのセッション運用
セッション永続性、コンテキスト管理、diffレビュー、Auto-fixを確認します。

18. Web版でOpus 4.7を活かすコーディング作法
タスク粒度、Web版仕様の依頼書プロンプト、並列実行、デバッグ作法を見ます。

まとめ

第1部:Claude Opus 4.7とは何か

1. 4.6から4.7への移行で変わるもの

2026年4月16日、AnthropicはClaude Opus 4.7をリリースしました。Anthropic公式が「最も高性能な汎用モデル」と位置づけており、コーディング、長期エージェントワーク、ナレッジワーク、ビジョン、メモリ関連のタスクで前世代を上回る性能を発揮するとされています。

ただし、Opus 4.7への移行は単なる性能アップデートではありません。Anthropic公式のMigration Guideには、Opus 4.6までと同じプロンプトでは想定通りに動かなくなる可能性のある「振る舞いの変更」が9項目、APIレベルの破壊的変更が5項目、明示的に列挙されています。これらを把握せずに切り替えると、「以前は通っていたAPI呼び出しが400エラーで返ってくる」「同じプロンプトなのに応答の品質や長さが変わる」「トークン消費が増えてコストが膨らむ」といったことが起きやすくなります。

第1部では、まずモデルとしてのOpus 4.7の仕様を見ていきます。

↑ 目次に戻る

2. モデルとしてのClaude Opus 4.7

2.1 基本スペック

Claude Opus 4.7の主要スペックは以下の通りです(出典:What's new in Claude Opus 4.7)。

最大出力128kは同期Messages APIにおける値です。Message Batches APIでは、ベータヘッダー(output-300k-2026-03-24)により別枠で最大300kトークン出力に対応します。

トークン単価はOpus 4.6と同等で、価格帯としては据え置きです。Prompt caching、Batch processing、Files API、PDF support、Vision、各種ツール(bash、code execution、computer use、text editor、web search、web fetch、MCP connector、memory)といったAPI・プラットフォーム機能の大枠もOpus 4.6と同等です。

ただし、後述する通り新しいトークナイザーの導入により、同じテキストでも消費トークン数が約1.0〜1.35倍に増える可能性があります。トークン単価が同じだからといって、ワークロード全体のコストが据え置きになるわけではない点には注意が必要です。

2.2 高解像度画像対応の刷新

Claude Opus 4.7は、Claudeモデルとして初めて高解像度画像をネイティブにサポートしました。最大解像度は2576ピクセル / 3.75メガピクセルで、従来の1568ピクセル / 1.15メガピクセルから大幅に拡張されています。

技術的に重要な変更がもう一つあります。モデルが返す座標が実画像のピクセルと1:1で一致するようになった点です。Opus 4.6までは、ポインティングやバウンディングボックス座標を取得した後、表示サイズに合わせたスケール変換を独自に実装する必要がありました。Opus 4.7ではこの変換コードが不要になります。

computer use、スクリーンショット解析、ドキュメント解析、図表分析といった視覚処理中心のワークロードで、実装の簡素化と精度向上の両方が期待できます。

ただしコスト面で注意点があります。フル解像度の画像は、従来モデル比で約3倍のトークンを消費する可能性があります。具体的には1画像あたり最大約4,784トークン(従来は約1,600トークン)まで増加し得ます。視覚中心のワークロードでは、max_tokens の予算とコスト試算をやり直す必要があります。

公式ドキュメントでは、画像の追加解像度が不要なケースでは送信前にダウンサンプリングすることが案内されています。

2.3 新トークナイザーの導入と、コスト試算への影響

Claude Opus 4.7は新しいトークナイザーを採用しています。これは性能改善に寄与している一方、同じテキストでも従来モデルと比べてトークン数が約1.0倍から1.35倍(最大で約35%増)になる可能性があります。増加率はコンテンツの種類によって変動します。

実務では、影響は大きく3つあります。

まず、トークン数の見積もりです。/v1/messages/count_tokens エンドポイントが返すトークン数がOpus 4.6と異なります。クライアント側でトークン数を見積もるロジックや、文字数からトークン数を推定する固定比率を持つコードは、Opus 4.7で再テストが必要です。

次に、max_tokens の設定です。同じプロンプトと出力でも消費トークン数が増える可能性があるため、余裕を持たせた設定が望ましいです。コンテキスト圧縮のトリガー条件も同様に再調整が必要です。

最後に、月次コストの試算です。トークン単価は据え置きですが、同じワークロードを処理する際の総トークン数が増える可能性があるため、コスト見積もりはOpus 4.7ベースで再計算するのが適切です。

コスト管理の手段としては、プロンプトの工夫(簡潔さの指示など)、task_budget の活用(後述)、effort パラメータの調整の併用が基本になります。これらは性能とのトレードオフを伴うため、使い方によって設定を変える必要があります。

2.4 1Mコンテキストの標準価格化が持つ意味

Opus 4.7は1Mトークンのコンテキストウィンドウを標準API価格で提供します。200Kトークンを超えるリクエストに対する追加料金(long-context premium)は存在しません。

これはOpus 4.6から引き継がれた仕様ですが、ビジネス判断の観点では改めて評価する価値があります。従来、長コンテキスト処理は専用の高価格帯モデルや別料金体系で提供されることが一般的でしたが、Opus 4.7では「標準価格で1Mまで使える」という前提でアーキテクチャを設計できます。

実務では、たとえば次のようなケースで効きます。

• 大規模リポジトリ全体を一度に読み込ませる解析ワークフロー
• 数百ページに及ぶドキュメントセットの横断分析
• 長時間の会話履歴を保持し続けるエージェントシステム
• 過去のチケットやログを丸ごと参照したカスタマーサポート

これらのワークフローを「都度プロンプトを工夫して詰め込む」ではなく、「必要な情報をまとめて入れる」という設計で組めるようになります。プロンプト圧縮やRAG(Retrieval-Augmented Generation)の必要性自体は残りますが、その境界は明らかに後ろ倒しになります。

ただし、長コンテキストはトークン消費が増える方向の選択であることに変わりはありません。コスト面での恩恵は「割増がない」点であって、「無料で長くできる」という意味ではない点には注意が必要です。

↑ 目次に戻る

3. 振る舞いの変化 — 4.6から4.7で何が変わったのか

ここからは、APIパラメータ的には互換性があるものの、プロンプトの再評価や補助的な指示の見直しが必要になる挙動の変化を見ていきます。Anthropic公式のMigration Guideの「Behavior changes」セクションには9項目の変更が列挙されていますが、そのうち「高解像度画像サポート」は第2.2節で先に扱ったため、本章では残りの8項目を見ていきます。

3.1 命令を字面通りに解釈する傾向が強まった

Opus 4.7は、Opus 4.6と比べて命令をより字面通りに、明示的に解釈するようになりました。依頼されていないことを推測して実行することはなく、ある項目への指示を別の項目に黙って一般化することもありません。

この傾向は、特に低いeffortレベルで顕著に現れます。

実務的な意味は2つあります。

ひとつは、曖昧なプロンプトのリスクが上がったことです。Opus 4.6までは「察して埋めて」くれていた部分を、Opus 4.7は埋めません。「いい感じにしてください」というプロンプトは、Opus 4.7では「いい感じ」の定義をモデルが自分で決めるのではなく、最小限のスコープで返ってくる傾向があります。

もうひとつは、API用途や構造化された抽出タスクには有利だということです。丁寧にチューニングされたAPIパイプライン、構造化抽出、予測可能な挙動を必要とするワークフローでは、字面通りに解釈する傾向はむしろ歓迎されます。意図しない拡張解釈が減り、出力が予測しやすくなるためです。

一方で、対話的に「察してくれることを期待する」使い方には合わなくなりました。移行作業として、プロンプトと実行フレームワークのレビューが基本になります。

3.2 応答長がタスクの複雑さに合わせて伸縮するようになった

Opus 4.7は、応答の長さを「固定的な冗長さ」ではなく「タスクの複雑さに応じた長さ」に調整するようになりました。

具体的には、単純な問い合わせに対しては短く返し、オープンエンドな分析にはより長く返します。Opus 4.6までと同じプロンプトでも、出力の長さが変わる可能性があります。

製品の出力フォーマットや一定の冗長さに依存しているケースでは、プロンプトの調整が必要です。過剰な説明を抑えたい場合は、「簡潔で焦点を絞った応答を返してください。必須でない文脈は省き、例は最小限に抑えてください」のような明示的な指示を加えるのが基本です。

また、「やってはいけないこと」を伝える否定的な指示よりも、「こう書いてほしい」という肯定的な例示の方が効果的でもあります。

3.3 ツール呼び出しを減らし、推論を優先するようになった

Opus 4.7は、Opus 4.6と比べてツールを呼ぶ頻度が減り、その代わりに推論を多用する傾向があります。多くのケースでこれがより良い結果につながります。

ツール使用を増やしたい場合は、effortレベルを上げるのが基本です。high または xhigh のeffort設定では、エージェント的な検索やコーディングにおけるツール使用が大幅に増加します。プロンプトで明示的に「いつどのようにツールを使うべきか」を指定する方法も有効です。

3.4 Subagentをデフォルトではあまり起動しなくなった

Opus 4.7は、デフォルトでsubagentをあまり起動しなくなりました。ただしこの挙動はプロンプトで制御可能です。

並列処理や複数subagentへの明示的な委譲が必要なワークフローでは、「いつsubagentを使うべきか」をプロンプトに明示します。

3.5 トーンが直接的に、絵文字が減った

長文ライティングにおける文体が、Opus 4.6と比べて変化しています。Opus 4.7はより直接的で、より強い意見を持ち、Opus 4.6のような相手を肯定するような言い回しや絵文字が減ったスタイルです。

製品が特定のトーンや声に依存している場合(カスタマーサポート、ブランドボイス、教育コンテンツなど)、スタイル指示プロンプトをOpus 4.7のベースラインに対して再評価する必要があります。

3.6 自発的な進捗報告が増えた

長時間のエージェント処理において、Opus 4.7はより定期的で質の高い進捗報告をユーザーに返すようになりました。

ここは実務上かなり重要です。Opus 4.6までに「3回ツール呼び出しごとに進捗をまとめてください」のような進捗報告を強制する補助的な指示を組み込んでいた場合、それを外すことが公式に案内されています。

進捗報告のフォーマットや内容が用途に合わない場合は、いったん外したうえで「進捗報告はこのように出してほしい」と明示的に書き、例を提供する形に切り替えます。

3.7 Effortレベルがより厳格に守られるようになった

Opus 4.6から大きく変わった点として、Opus 4.7はeffortレベルを厳格に解釈するようになりました。特に低effort側で顕著です。

low および medium effortでは、モデルは「依頼された範囲」にスコープを絞って動作し、それを超えて気を利かせることはしません。これはレイテンシとコストの面では有利ですが、中程度に複雑なタスクを low effortで動かすと推論が浅くなるリスクがあります。

複雑な問題で浅い推論が観察された場合は、プロンプトで回避するのではなくeffortを high または xhigh に上げるのが基本です。

レイテンシ要件で low を維持する必要がある場合は、ターゲットを絞った指示を追加します。「このタスクは多段階の推論を含みます。応答する前に問題をよく考えてください」といった具体的な指示が有効です。

3.8 セキュリティ関連トピックの拒否が強化された

Opus 4.7で新たに追加された挙動として、禁止されたトピックや高リスクなトピックに関するリクエストは拒否される可能性が高まりました。リアルタイムのサイバーセキュリティ関連の安全策が組み込まれています。

ペネトレーションテスト、脆弱性研究、レッドチーミングといった正当なセキュリティ業務でこのモデルを使う場合、AnthropicのCyber Verification Programに申請することで制限の緩和を受けられます。

3.9 これらの変化が業務ワークフローに与えるインパクト

ここまでの8項目を業務インパクトの観点でまとめると、ポイントは4つです。

まず、プロンプト設計の力点が「察してもらう」から「明示する」に移ったこと。Opus 4.7は字面通りに読み、依頼されたスコープに絞って動きます。曖昧さを残したプロンプトは、4.6時代より結果のばらつきが大きくなります。

次に、4.6時代に組み込んだ補助的な指示は、外して再評価するのが基本ラインだということ。進捗報告の強制、過剰な確認指示、subagentへの明示的な誘導といった足場は、4.7では逆効果になり得ます。

そして、effortレベルをタスクに応じて意識的に選ぶ運用が前提になったこと。これまでデフォルト任せでよかった部分が、4.7では明示的な選択を求めます。

最後に、スタイルやトーンに依存する製品は、必ず再ベースライン化が必要だということ。Opus 4.6とOpus 4.7では、同じプロンプトでも文体・長さ・絵文字使用が変わります。

これらは破壊的変更ではないため、プロンプトを変えなくても動作はします。ただし、品質を維持・向上させたいのであれば、移行時のレビューは避けて通れません。

↑ 目次に戻る

4. 補足:Claude Code利用者も知っておきたいMessages API側の破壊的変更

本記事はClaude Codeでの利用を主軸にしています。ただし、Opus 4.7ではMessages API側にも破壊的変更があり、モデル挙動の理解や移行判断に関係します。そのため、Claude Code利用者にも影響し得る範囲でAPI側の変更点も補足します。

なお、ここで扱う変更はMessages APIを直接利用しているケースのみに該当します。Claude Managed Agentsを利用している場合は、Messages API直接利用とは移行手順が異なります。詳細は公式Migration Guideを確認してください。

4.1 Extended thinking budgetsの廃止とadaptive thinkingへの一本化

Opus 4.7では、固定のthinking budgetモードが廃止されました。

# Opus 4.6(動作する)
thinking = {"type": "enabled", "budget_tokens": 32000}

# Opus 4.7(400エラー)
thinking = {"type": "enabled", "budget_tokens": 32000}

Opus 4.7でthinkingを有効化する唯一の方法はadaptive thinkingです。代わりに、思考の深さは effort パラメータで制御します。

# Opus 4.7での書き方
response = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=64000,
    thinking={"type": "adaptive"},
    output_config={"effort": "high"},
    messages=[{"role": "user", "content": "..."}],
)

Anthropicの内部評価では、adaptive thinkingは固定budgetのextended thinkingを一貫して上回る性能を示しているとされています。

4.2 Adaptive thinkingのデフォルト無効と明示的な有効化

Messages APIにおける重要な仕様として、Opus 4.7ではadaptive thinkingがデフォルトで無効です。

thinking フィールドを指定しないリクエストは、thinkingなしで実行されます。これはOpus 4.6の挙動と一致しています。Thinkingを有効にしたい場合は thinking: {type: "adaptive"} を明示的に指定します。

なお、これはMessages API直接利用時の話です。後述するClaude Codeでは、effort levelを通じた制御に統一されており、ユーザーがthinkingを意識的に切り替える必要はありません。

4.3 Samplingパラメータの禁止

Opus 4.7では、temperature、top_p、top_k のいずれかをデフォルト値以外に設定すると400エラーになります。

最も安全な移行方針は、これらのパラメータをリクエストペイロードから完全に削除することです。Opus 4.7でモデルの挙動を制御する手段は、プロンプトでの誘導が基本です。

temperature = 0 を決定論的な出力のために使っていたケースについて、これは過去のモデルでも同一出力を保証するものではなかった、と公式ドキュメントには注記があります。完全な再現性が必要な用途では、別のアーキテクチャ(出力のキャッシュ、構造化出力の活用など)を検討する必要があります。

4.4 Thinking contentのデフォルト省略とdisplayオプション

Opus 4.7では、レスポンス内のthinkingブロックがデフォルトで空になりました。Thinkingブロック自体はレスポンスストリームに含まれますが、display: "summarized" を明示的に指定しない限り、thinking フィールドは空のまま返ります。

これはサイレントな変更です。エラーは発生しませんが、Opus 4.6では要約されたthinkingテキストが返っていたのに、Opus 4.7では何も返らなくなります。

UI上で思考プロセスを表示している製品の場合、復元するには次の設定を加えます。

thinking = {
    "type": "adaptive",
    "display": "summarized",  # デフォルトは "omitted"
}

特に思考プロセスをユーザーにストリーム表示している製品では、この設定を入れないと「出力前に長い無音時間が発生する」ように見えるため、注意が必要です。

4.5 新トークナイザーによる max_tokens 設定の見直し

新トークナイザーの導入により、同じテキストでも消費トークン数が変わります。具体的な影響範囲は次の通りです。

• /v1/messages/count_tokens の返り値がOpus 4.6と異なる
• クライアント側でトークン数を見積もるコードパスは再テストが必要
• 文字数とトークン数の固定比率を仮定するロジックは要検証
• max_tokens には余裕を持たせる必要がある
• コンテキスト圧縮のトリガー条件は再調整が必要

max または xhigh effortで動かす場合、max_tokens を64,000トークン以上から開始してチューニングするのが基本になります。Subagentやツール呼び出しを跨いだ思考と行動のために、十分な出力予算が必要です。

4.6 Prefillの廃止(Opus 4.6から継続)

これはOpus 4.6で既に導入された変更ですが、4.5以前から直接移行する場合は注意が必要です。Opus 4.7では、アシスタントメッセージのprefillが400エラーになります。

代替手段は次の通りです。

• 構造化出力(structured outputs)の利用
• システムプロンプトでの指示
• output_config.format の利用

Prefillの典型的な用途と、それぞれの推奨移行先を整理します。

↑ 目次に戻る

5. 新機能

5.1 xhigh effort levelの追加と推奨デフォルト化

Opus 4.7では、effortパラメータに xhigh という新しいレベル が追加されました。これは high と max の中間に位置します。Claude Codeのコーディング・エージェント用途では、xhigh を基本線にする運用がリリース時から繰り返し示されています。一方、Messages APIを直接利用する場合は、APIのデフォルト値と用途別の推奨値を分けて確認するのが安全です。

各レベルの位置づけは次の通りです。

Opus 4.7では、effortがこれまでのOpusよりも重要になる、というのが公式リリースで強調されているメッセージです。アップグレード時には積極的に試してみるのが基本です。

つまりOpus 4.7では、「とりあえずデフォルト」ではなく、用途に応じてeffortを意識的に選ぶ運用が前提になっています。

max の使用については慎重さが求められます。maxには「収穫逓減(diminishing returns)」と「必要以上に考え込む傾向」が明記されており、難しいタスクで実テストしてから広く採用するのが安全です。

5.2 Task budgets(beta)

Opus 4.7で導入された新機能として、task budgetsがあります。これは、エージェントループ全体(思考、ツール呼び出し、ツール結果、最終出力すべてを含む)に対する助言的なトークン予算をモデルに伝える仕組みです。

モデルはこの予算と、進行中のカウントダウンを認識し、それに基づいて作業を優先順位付けし、予算が消費されるにつれてタスクを適切に終了させます。

利用方法は次の通りです。

response = client.beta.messages.create(
    model="claude-opus-4-7",
    max_tokens=128000,
    output_config={
        "effort": "high",
        "task_budget": {"type": "tokens", "total": 128000},
    },
    betas=["task-budgets-2026-03-13"],
    messages=[
        {"role": "user", "content": "Review the codebase and propose a refactor plan."}
    ],
)

max_tokens との違いを明確にしておきます。

max_tokens は「絶対に超えない上限」、task_budget は「目標として伝える予算」と理解すると正確です。

使い分けの目安は以下の通りです。

• 品質重視のオープンエンドなエージェントタスクにはtask budgetを設定しない
• ワークロードを特定のトークン量に収める必要がある場合に利用する
• 最小値は20,000トークン
• 予算が制限的すぎると、タスクが浅くなったり、モデルが予算を制約として明示的に言及したりする

実用上は、CI/CDパイプラインに組み込むエージェントや、コスト上限を厳格に管理する必要があるバッチ処理に向いています。対話的な探索や創造的な作業には不向きです。

5.3 ファイルベースメモリの改善

Opus 4.7は、ファイルシステムベースのメモリの読み書き能力が改善されています。スクラッチパッド、ノートファイル、構造化メモリストアをターン跨ぎで利用するエージェントは、自分用のメモを書き残し、それを後のタスクで活用する能力が向上しています。

自前で構築せずに利用したい場合は、Anthropicが提供するclient-sideのmemory toolを使うことで、管理されたスクラッチパッドをClaudeに与えられます。

長期にわたるエージェントワーク、複数セッションをまたぐプロジェクト、複雑なコンテキストを蓄積していくワークフローで、この改善は意味を持ちます。

ここまで見てきたように、Opus 4.7は単に性能が上がったモデルではありません。命令解釈、応答長、ツール使用、進捗報告、subagentの扱い、effort制御まで、エージェントとしての振る舞いが変わっています。

この変化が最も実務に現れやすいのが Claude Code です。以降では、CLI版とWeb版のClaude Codeで、Opus 4.7をどのように使いこなすべきかを見ていきます。

↑ 目次に戻る

第2部:Claude Code CLI版で使うOpus 4.7

6. Claude CodeにおけるOpus 4.7の前提

Claude Codeは、ターミナルで動作するAnthropic公式のエージェント型コーディングツールです。Opus 4.7を業務で活用する場合、CLIを経由した利用が最も柔軟性が高く、本記事ではその前提で解説していきます。本章のモデル設定関連の仕様は、公式のModel configurationドキュメントに基づきます。

6.1 バージョン要件と更新手順

Opus 4.7をClaude Codeで利用するには、Claude Code v2.1.111以降が必要です。これより古いバージョンではOpus 4.7を呼び出せません。

現在のバージョン確認と更新は次のコマンドで行います。

# 現在のバージョン確認
claude --version

# 最新版に更新
claude update

特定バージョンを指定してインストールする場合は次の通りです。

claude install 2.1.118
claude install stable
claude install latest

6.2 モデルエイリアスの解決ルール

Claude Codeでは、opus や sonnet といったエイリアスを使ってモデルを指定できます。ただし、エイリアスがどのモデルに解決されるかは利用環境によって異なります。

これはClaude Codeにおけるaliasの解決先の話であり、Bedrock / Vertex AI / FoundryでOpus 4.7自体が利用できないという意味ではありません。Opus 4.7はこれらのサードパーティプラットフォームでも提供されています。最新モデルを使う場合は、フルモデル名(claude-opus-4-7 など)を明示的に指定するか、ANTHROPIC_DEFAULT_OPUS_MODEL 環境変数を設定する必要があります。

エイリアスは時間とともに更新されるため、特定バージョンに固定したい場合はフルモデル名を使うのが安全です。

6.3 プラン別のデフォルトモデル

Claude Code起動時のデフォルトモデルは、契約プランによって異なります。これは特に意思決定者にとって重要な情報です。

つまり、ProプランやTeam Standardプランの利用者は、明示的に切り替えない限りOpus 4.7を使っていません。コーディングや複雑なエージェントタスクでOpus 4.7を使いたい場合、/model opus で切り替える必要があります。

なお、2026年4月23日からはEnterprise pay-as-you-goとAnthropic APIユーザーのデフォルトもOpus 4.7に変更されます。

↑ 目次に戻る

7. Claude Codeの基本操作 — CLIコマンドの使い方一覧

ここでは公式ドキュメントに記載されている主要なコマンドを、利用頻度の高いものから整理します。網羅的な一覧は公式のCLI referenceを参照してください。

7.1 起動と終了

最も基本的な起動・終了の操作です。

セッション中の終了は Ctrl+C を二回、もしくは /exit コマンドで行います。

claude -c と claude -r の違いは押さえておくと便利です。-c は「現在のディレクトリでの最新会話」を引き継ぐもので、-r は「特定のセッション名やIDを指定して再開」するものです。複数のプロジェクトを並行で進めている場合、セッションに名前を付けておくと再開時に明確に区別できます。

7.2 セッション中のスラッシュコマンド早見表

セッション中にプロンプト入力欄で / を入力すると、利用可能なコマンドの一覧が表示されます。実務でよく使うものは次の通りです。

特に意識して使いたいのは次の3つです。

/effort はOpus 4.7で重要なコマンドです。タスクの性質に応じて切り替える運用が基本になります。

/effort xhigh    # コーディングやagenticタスクの推奨
/effort high     # コスト・並列実行重視
/effort medium   # コスト重視のスコープが小さいタスク
/effort max      # 最高難度タスクで意図的に使う

/compact は長時間セッションでコンテキストが膨らんできたときに使います。Claude Codeは限界が近づくと自動的にトリガーしますが、長いタスクの前に明示的に圧縮しておくのも有効です。

/model はモデルを切り替えます。ProプランでSonnet 4.6がデフォルトの場合、複雑なタスクの前に /model opus でOpus 4.7に切り替える運用が必要です。

7.3 設定ファイルの階層

Claude Codeの設定には、モデル選択の優先順位とsettingsファイル全体のスコープ優先順位という、2つの異なる階層があります。混同しやすいため、それぞれ分けて見ていきます。

モデル選択の優先順位(高い順)

/model、--model、ANTHROPIC_MODEL、settings.json の model フィールドの間では、次の順序で優先されます。

1. セッション中の /model コマンド
2. 起動時の --model フラグ
3. 環境変数 ANTHROPIC_MODEL
4. settingsファイルの model フィールド

settingsファイル全体のスコープ優先順位(高い順)

permissions、hooks、env、availableModels といったsettings全体の優先順位は、Anthropic公式のClaude Code settingsドキュメントで次のように定められています。

1. Managed settings(最高、上書き不可)
2. Command line arguments(一時的なセッションオーバーライド)
3. .claude/settings.local.json(プロジェクトローカル、Git管理対象外)
4. .claude/settings.json(プロジェクト共有、Git管理対象)
5. ~/.claude/settings.json(ユーザー設定、最も低い)

Managed settingsはIT部門やDevOpsチームが配布する組織ポリシー用で、サーバー管理、MDM/OSレベルのポリシー、ファイルベースのいずれかの形で配布されます。これは最高優先度で、ユーザーやプロジェクトの設定からは上書きできません。

なお、配列形式の設定値(permissions.allow や sandbox.filesystem.allowWrite など)は、複数のスコープにまたがって結合・重複排除されます。上書きではなく追記される、というのが重要なポイントです。

実務では、次のような使い分けが想定されます。

• ユーザー設定(~/.claude/settings.json):個人の好みのデフォルトeffortや好みのモデル
• プロジェクト設定(.claude/settings.json):プロジェクト固有のツール権限、利用可能モデル制限
• ローカル設定(.claude/settings.local.json):個人がプロジェクト内で一時的に上書きしたい設定

設定ファイルの基本的な構造は次の通りです。

{
  "model": "opus",
  "effortLevel": "xhigh",
  "permissions": {
    "allowedTools": ["Read", "Write", "Bash(git *)"],
    "deny": ["Read(./.env)", "Read(./.env.*)"]
  }
}

7.4 環境変数で覚えておくべきもの

公式ドキュメントから、業務でよく使う環境変数を整理します。

サードパーティ環境(Bedrock、Vertex、Foundry)でのモデルピン留めには、それぞれ専用の ANTHROPIC_DEFAULT_OPUS_MODEL 等を使います。

# Bedrockの例
export ANTHROPIC_DEFAULT_OPUS_MODEL='us.anthropic.claude-opus-4-7'

# 1Mコンテキストを有効にしたピン留め
export ANTHROPIC_DEFAULT_OPUS_MODEL='claude-opus-4-7[1m]'

7.5 状態確認の作法

「今どのモデル・どのeffortで動いているか」を確認する手段は複数あります。

最も簡単なのはステータス行です。Claude Codeはロゴとスピナーの隣に現在のeffortレベル(例:with xhigh effort)を常時表示します。これで現在の設定を一目で確認できます。

詳細を確認したい場合は /status を使います。これでモデル名、プラン情報、認証状態がJSONで返ります。

セッション終了時に「結局このタスクでいくらかかったか」を知りたい場合は /usage を使います。入出力トークン数とコスト概算が表示されます。

↑ 目次に戻る

8. 日常運用のリズム — Claude Codeをふだんどう使うか

ここからは、公式ブログ「Best practices for using Claude Opus 4.7 with Claude Code」(2026年4月16日)で示されている運用指針を中心に、ふだんの使い方を見ていきます。

Opus 4.7の使い方の基本姿勢は、「ペアプログラマーとしてではなく、業務を委譲する有能なエンジニアとして扱う」というものです。一行ずつ指導するのではなく、必要な情報を渡して任せる、という発想の転換です。

この姿勢の転換が、以下のすべての運用作法の根拠になります。

8.1 タスク投入の基本フロー — 初回ターンに全部入れる

Opus 4.7で最も重要なのは、初回ターンにタスクを完全に記述することです。初回プロンプトには、少なくとも次の4点をまとめて渡すのが基本です。

• 意図(何を達成したいか)
• 制約(守るべきルール、使ってはいけない技術、既存設計への配慮)
• 完了条件(どうなれば完了と判定するか)
• 関連ファイルの場所(どのファイルを参照・編集すべきか)

複数ターンに分けて曖昧なプロンプトを出すアプローチは、トークン効率も最終品質も下がる傾向があります。

初回プロンプトのテンプレート例を示します。

[Intent]
ユーザー認証APIをOAuth 2.0ベースに移行する。

[Constraints]
- 既存のセッション管理ロジック(src/auth/session.ts)は変更しない
- 移行は段階的に行い、既存の認証エンドポイントとの互換性を保つ
- TypeScriptのstrictモードを維持

[Acceptance criteria]
- 既存テスト(tests/auth/)がすべてパスすること
- 新しいOAuthフロー用のE2Eテストが追加されていること
- README.mdの認証セクションが更新されていること

[Relevant files]
- src/auth/*.ts
- tests/auth/*.test.ts
- README.md

このように初回で全情報を渡すと、Opus 4.7は途中で確認を挟まずに最後まで進めようとします。これが「任せる」運用の基本形です。

8.2 ユーザーターン数を減らす

2つ目の指針は、ユーザーとのインタラクション回数を減らすことです。

これはOpus 4.7の特性に基づく指針です。Opus 4.7はインタラクティブな設定でユーザーターンの後により多く推論する傾向があり、その推論がコヒーレンス・指示追従・コーディング品質を向上させます。一方で、ターンが増えるたびにトークン消費も増加します。

実務では、次のような運用が基本になります。

• 「これで合っていますか?」のような確認質問を最小限に絞る
• 修正指示があれば一度にまとめて伝える
• 「次のステップに進んでください」のような中継的なターンを減らす

8.3 Auto Modeの活用

Opus 4.7の長時間自律実行性能を最大限引き出す機能として、Auto Modeがあります。

Auto Modeは、モデルが安全に実行できると判断したタスクについて、頻繁な確認なしで実行できるモードです。長時間タスクで初回プロンプトに完全なコンテキストを与えた場合に特に有効です。

利用方法は次のいずれかです。

# 起動時からAuto Modeで開始
claude --permission-mode auto

セッション中であれば、Shift+Tab を押すことで権限モードが切り替わります(normal → auto-accept on → plan modeの順にサイクル)。

Auto ModeはClaude Code Maxユーザー向けの試験提供版(research preview)機能として提供されています。

8.4 完了通知の設定

長時間タスクをAuto Modeで走らせる際の運用上の工夫として、タスク完了通知の設定が便利です。Claude自身に「タスク完了時に音を鳴らすフックを設定してほしい」と頼めば、Claude Codeのhook機能を使ってその設定を組んでくれます。

8.5 effortレベルをタスクに応じて切り替える

effortレベルは「最初に設定して放置する」のではなく、タスクの性質に応じて切り替えていく運用が基本です。同じタスク内であっても、トークン使用と推論をより効果的に管理するためにeffortを切り替えてよい、というスタンスです。

具体的な切り替え例を整理します。

8.6 thinkingの量をプロンプトで制御する

Opus 4.7ではアダプティブシンキングモードが常時動作し、固定budgetは廃止されました。thinkingの量を制御したい場合は、プロンプトで直接指示します。

具体例は次の通りです。

もっと考えてほしい場合
「ステップバイステップに、慎重に考えてから応答してください。この問題は見た目より難しいです。」

もっと早く返してほしい場合
「深く考えるよりも、素早い応答を優先してください。迷ったら直接答えてください。」

後者を使うとトークンを節約できますが、難しいステップで精度が下がる可能性がある点に留意が必要です。

8.7 Subagentの扱い

Opus 4.7はデフォルトでsubagentをあまり起動しません。並列実行が必要なタスクでは、明示的に指示を出す必要があります。

具体例として示されているプロンプトは、要約すると次のような内容です。

単一の応答で完結できる作業(既に見えている関数のリファクタなど)にはsubagentを作らないこと。複数のアイテムにまたがる作業や複数ファイルを読む場合は、同じターン内で複数のsubagentを作ること。

つまり、subagentを使うべき条件は2つに絞られています。

• 複数アイテムへの並列処理
• 複数ファイルの並列読み取り

これ以外のケースでは、Claude自身の判断に委ねるのが基本です。

8.8 4.6時代の補助的な指示を外す

ここまで触れてきた指針と関連して重要なのが、Opus 4.6までに組み込んだ補助的な指示を外すことです。

Migration Guideで明示的に外せと言われているのは次の3パターンです。

進捗報告を強制するプロンプト。「3回ツール呼び出しごとに進捗をまとめてください」のような指示は、Opus 4.7では自発的に行うようになったため不要です。

確認を強制するプロンプト。「スライドのレイアウトを返す前にダブルチェックしてください」のような指示は、Opus 4.7が自己検証するようになったため、外して再評価するのが基本です。

出力長を一定に保つためのプロンプト。Opus 4.7はタスクの複雑さに応じて長さを調整するため、固定的な冗長さを期待した指示は外して、必要なら明示的にスタイルを指示します。

これらの補助的な指示を外すと、トークン消費が減り、応答品質が安定する場合があります。

8.9 1日の典型的なワークフロー

ここまでの指針をまとめると、Opus 4.7でClaude Codeを使う1日のリズムはこんなかんじになります。

朝:セッション開始

# 新しいタスクを始める場合
claude -n "feature-oauth-migration" --model opus --effort xhigh

# 昨日の続きを再開する場合
claude -r "feature-oauth-migration"

タスク投入:初回プロンプトで全情報を渡す

意図 / 制約 / 完了条件 / 関連ファイルの4要素を含むプロンプトを書きます。長くなっても構わないので、後から「これも追加で」と細切れに渡すよりも初回に詰め込みます。

実行中:基本的に介入しない

Auto Modeを使っている場合は完了通知を待ちます。介入が必要になっても、まとめて一度に伝えます。中継的な「次に進んで」のターンは避けます。

完了後:レビューと検証

/review で変更点を確認、必要に応じてテストを走らせます。完了条件に対する達成度をClaude自身に確認させます。

コンテキストの管理

長時間セッションで応答が遅くなってきたら /compact で履歴を圧縮します。タスク自体が変わるなら /clear で新しいセッションに切り替えるか、claude -n で別セッションを立ち上げます。

終了時:セッション保存

/exit で終了します。セッション名を付けておけば翌日 claude -r <name> で再開可能です。

↑ 目次に戻る

9. Effort Levelの使い分け

第8章で運用の中での切り替え方を扱いましたが、ここでは公式ドキュメントに基づく各レベルの正確な定義を整理します。

9.1 5段階の公式定義

Opus 4.7では、effortレベルが5段階に拡張されました。Opus 4.6とSonnet 4.6は4段階のままです。

9.2 xhighをデフォルトとして使う理由

xhighは大半のコーディングおよびエージェント用途で最良の設定として位置づけられています。max が長時間実行で起こしうる暴走的なトークン消費なしに、強い自律性と知性を発揮するためです。

つまりxhighは、max の知性を90%カバーしつつ、max の必要以上の考え込みリスクを回避する設定です。

xhighが基本になる用途は次の通りです。

• API・スキーマ設計
• レガシーコードの移行
• 大規模コードベースのレビュー
• 一般的なagenticコーディング

9.3 maxが考え込みすぎる場面と回避策

max は性能向上の可能性がある一方、収穫逓減と必要以上に考え込む傾向が公式ドキュメントに明記されています。これはOpus 4.7のリリース時から繰り返し強調されているポイントです。

max の適切な用途は次のように限定されます。

• 評価でモデルの最大性能を測定する場合
• 知性が極めて重要で、コストを問わない用途
• 真に困難な問題でxhighが解けなかった場合の試行

逆に、日常的なコーディングや通常のエージェント実行で max を常用すると、トークン消費が増えるだけで品質向上は限定的、という結果になりがちです。

9.4 設定方法

effortレベルの設定方法を優先順位順に整理します。

(1) セッション中の /effort コマンド(最も即時性が高い)

/effort                # スライダーを開く
/effort xhigh         # 直接指定
/effort auto          # モデルのデフォルトに戻す

(2) /model ピッカー内のスライダー

/model でピッカーを開いた状態で左右矢印キーを押すとeffortスライダーが操作できます。

(3) 起動時のフラグ

claude --effort xhigh

(4) 環境変数

export CLAUDE_CODE_EFFORT_LEVEL=xhigh

(5) 設定ファイル

{
  "effortLevel": "xhigh"
}

(6) Skill / Subagentのフロントマター

特定のSkillやSubagentが動作する間だけ別のeffortを使いたい場合、それぞれのMarkdownファイルのフロントマターに effort を指定できます。

優先順位は、環境変数が最も強く、次に設定値、最後にモデルデフォルトです。フロントマター指定はそのSkill / Subagentが動作している間のセッション設定を一時的に上書きしますが、環境変数は上書きできません。

なお、low / medium / high / xhigh はセッションを跨いで永続化されますが、max だけは現セッション限りです(環境変数経由で設定した場合は永続化)。

9.5 ultrathink — 1ターンだけ深く考えさせる小ワザ

セッション全体のeffort設定を変更せずに、特定の1ターンだけ深く考えさせたい場合の小ワザがあります。

プロンプトに　"ultrathink" という単語を含めると、そのターンだけ文脈内の追加指示として「より深く推論せよ」という命令が加わります　。これはeffortレベルそのものを変更するものではなく、APIに送られるeffort値も変わりません。

実装上は単純な仕組みですが、「全体はxhighで動かしたいが、この一手だけは念入りに考えてほしい」という場面で使えます。

↑ 目次に戻る

10. 1Mコンテキストの正確な扱い方

10.1 プラン別の可用性マトリクス

Opus 4.7、Opus 4.6、Sonnet 4.6は1Mトークンのコンテキストウィンドウをサポートしています。利用可否はプランによって異なります。

Max、Team、Enterpriseプランでは、opus を選択すると追加設定なしで1Mコンテキストに自動アップグレードされます。

10.2 1Mに追加プレミアムが付かない料金体系の意味

公式ドキュメントには、1Mコンテキストウィンドウは標準モデル価格を使用し、200Kトークンを超える分にプレミアムは付かないと明記されています。

これはOpus 4.6から引き継がれた仕様ですが、ビジネス判断として改めて認識しておく価値があります。

長コンテキスト処理に対する割増料金がないため、次のようなアーキテクチャ判断が変わります。

• 大規模リポジトリ全体を読み込むワークフローの設計
• 大量のドキュメントセットの横断分析
• 過去のチケット・ログを丸ごと参照するエージェントシステム

ただし、トークン消費自体は当然増えるため、コスト管理には引き続き task_budget や effort の調整が必要です。

10.3 opus[1m] エイリアスと [1m] サフィックスの使い方

Max / Team / Enterpriseプランでは自動アップグレードされるため明示は不要ですが、明示的に1Mを指定したい場合や、Proプランでextra usage経由で1Mを使う場合は次のように指定します。

# セッション中の切り替え
/model opus[1m]
/model sonnet[1m]
/model claude-opus-4-7[1m]

サードパーティ環境でモデルをピン留めする場合は、環境変数に [1m] サフィックスを付けます。

export ANTHROPIC_DEFAULT_OPUS_MODEL='claude-opus-4-7[1m]'

このサフィックスは opusplan を含むそのエイリアスのすべての利用に1Mを適用します。Claude Codeはプロバイダーに送る前にサフィックスを除去します。[1m] を使えるのは、Opus 4.7やSonnet 4.6のように1Mコンテキストをサポートするモデルだけです。

10.4 注意点:opusplanは1Mに自動アップグレードされない

落とし穴として明確に押さえておきたい仕様があります。

opusplan モデルエイリアスは、PlanモードでOpus、実行モードでSonnetを使うハイブリッドモードです。便利な機能ですが、opusplan のPlanモード時のOpusフェーズは標準の200Kコンテキストで動作します。10.1で説明した1M自動アップグレードは opus モデル設定にのみ適用され、opusplan には及びません。

つまり、Maxプランで「自動的に1Mが使える」と思って opusplan を使うと、PlanフェーズのOpusは200K止まりになります。大規模リポジトリのプランニングで1Mを使いたい場合は、opusplan ではなく opus を直接使う必要があります。

opusplan で1Mを使いたい場合は、環境変数で [1m] サフィックスを明示的に付ける方法があります。

export ANTHROPIC_DEFAULT_OPUS_MODEL='claude-opus-4-7[1m]'

10.5 1Mを無効化するケース

何らかの理由で1Mコンテキストを利用したくない場合は、環境変数で無効化できます。

export CLAUDE_CODE_DISABLE_1M_CONTEXT=1

これを設定すると /model ピッカーから1Mバリアントが除外されます。

無効化を検討する典型的なケースは、コスト上限を厳格に管理したい場合や、コンテキスト圧縮の挙動を従来通りに保ちたい場合などです。

↑ 目次に戻る

11. Claude CodeにおけるAdaptive Reasoning

第4.1〜4.2節で扱ったadaptive thinkingはMessages APIの話でしたが、Claude Codeでは同じ概念が「adaptive reasoning」として、effort levelを通じて制御される仕組みになっています。本章ではClaude Code側の挙動を見ていきます。

11.1 Opus 4.7ではadaptive reasoningが常時動作し、無効化できない

Claude Code公式ドキュメントに明記されている重要な仕様です。Opus 4.7ではadaptive reasoningが常時動作し、これを無効化する手段は存在しません。固定thinking budgetモード(CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING など)はOpus 4.7では効きません。

これは、Opus 4.7ではユーザーが「thinkingの量」を直接的に指定する手段がない、ということを意味します。代わりに次の二つの間接的な手段があります。

• effortレベルによる制御(レベルが高いほどthinkingが増える傾向)
• プロンプトでの誘導(第8.6節で説明した方法)

つまり、Messages APIでは thinking パラメータで明示的に有効化／無効化を切り替えるのに対し、Claude Codeではeffort levelがその役割を担う、というアーキテクチャの違いがあります。

11.2 4.6で残っている固定thinking budget

参考までに、Opus 4.6とSonnet 4.6では従来の固定thinking budgetモードが残っています。

# Opus 4.6 / Sonnet 4.6で固定budgetに戻す
export CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1
export MAX_THINKING_TOKENS=32000

ただしこれらのモデルでも公式ドキュメントはadaptive thinkingを推奨しており、固定budgetモードは互換性のために残っている位置づけです。Opus 4.7への移行を見据えるなら、4.6の段階からadaptive thinkingベースの運用に切り替えておくのが合理的です。

11.3 プロンプトとCLAUDE.mdによる誘導の作法

thinkingの量をコントロールする最も確実な方法は、プロンプトでの直接指示です。これは個別のターンに書く方法と、CLAUDE.mdなどで常時適用する方法の二段構えで運用できます。

ターン単位での指示は第8.6節の例文を参照してください。

CLAUDE.mdレベルで「このプロジェクトでは慎重に考えてほしい」という指示を入れる場合は、自然言語で書きます。

# Project Guidelines

## Reasoning style
This project handles financial transactions. Think carefully and verify
your reasoning step-by-step before making changes to payment-related code.

このような指示は、effort設定の上に重なる形で動作します。

↑ 目次に戻る

12. Opus 4.7を最大限引き出すプロンプティング

ここまでの章で運用と設定の話をしてきました。最後に、Opus 4.7におけるプロンプト設計の原則を整理します。すべて公式ブログと公式Prompting Best Practicesに基づきます。

12.1 「依頼書」スタイル

第8.1節で示した4要素を、改めて構造として整理します。

• 意図(何を達成したいか)
• 背景(既存設計、使用技術)
• 制約(守るべきルール、禁止事項)
• 完了条件(完了の判定基準)

これは「指示」ではなく「依頼書」です。ペアプログラマーへの会話ではなく、外部のシニアエンジニアに渡す業務委託の指示書を書くという発想で組み立てます。

12.2 否定形より肯定形の例示

Migration Guideが明確に示している原則として、適切なコミュニケーションの仕方を示す肯定的な例示の方が、否定的な指示よりも効果的だ、というものがあります。

たとえば「冗長にしないでください」と書くより、「次のような簡潔さで応答してください:[例文]」と書く方が効きます。

12.3 effortとthinkingはプロンプトと組み合わせて使う

effortレベルだけでも、プロンプトだけでも完全には制御できません。両者の組み合わせが基本です。

12.4 Subagentや並列化を明示する

Opus 4.7はデフォルトで控えめにsubagentを起動するため、並列化が必要なら明示的に指示します。第8.7節のプロンプト例を参考にしてください。

12.5 検証機構を渡す

公式Prompting Best Practicesには、コードレビューハーネスのチューニングについて重要な記述があります。Opus 4.7はバグ発見性能が大幅に向上しており、Anthropic内部の評価ではrecall(バグ検出再現率)が11pp改善しています。一方で、Opus 4.6向けに調整されたハーネスでは初期にrecallが下がって見えることがある、という注意喚起もあります。

これはOpus 4.7が指示により忠実だからです。「重大な問題のみ報告してください」「保守的に」「些細なことは指摘しないで」といった指示を、Opus 4.6よりも忠実に守ります。同じ深さで調査しても、報告される件数が減る、ということが起こります。

実務的な意味は、Opus 4.7に切り替えた直後は、ハーネスのプロンプトを再評価する必要があるということです。指示を緩めるか、報告基準を明示し直すことで、本来の性能を引き出せます。

↑ 目次に戻る

13. エンタープライズ運用

ここからは、チームや組織でClaude Codeを使うときのガバナンスとコスト管理について見ていきます

13.1 availableModelsによるモデル制限

エンタープライズ管理者は、availableModels 設定でユーザーが選択可能なモデルを制限できます。

{
  "availableModels": ["sonnet", "haiku"]
}

これをmanaged settingsまたはpolicy settingsに置くと、ユーザーは /model、--model フラグ、ANTHROPIC_MODEL 環境変数のいずれを使ってもリストにないモデルに切り替えられなくなります。

ただし注意点として、Defaultオプション(モデルピッカーの「Default」選択肢)は availableModels の影響を受けません。Defaultは常に表示され、ユーザーのプラン階層に応じたシステムデフォルトに解決されます。

availableModels を [] に設定しても、ユーザーはDefaultモデルでClaude Codeを利用できます。

13.2 defaultモデル設定とプラン別フォールバック

ユーザーが「Default」を選択した場合のモデルを完全に制御するには、3つの設定を組み合わせる必要があります。

{
  "model": "claude-sonnet-4-5",
  "availableModels": ["claude-sonnet-4-5", "haiku"],
  "env": {
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "claude-sonnet-4-5"
  }
}

この例では、ユーザーをSonnet 4.5で起動し、ピッカーをSonnetとHaikuに制限し、Default選択時の解決先もSonnet 4.5に固定しています。

env ブロックがないと、Defaultを選んだユーザーは最新のSonnetリリースに自動的にアップグレードされ、model と availableModels で固定したバージョンがバイパスされます。

13.3 サードパーティでのモデルピン留め

Bedrock、Vertex AI、Foundryでデプロイする場合、本番ロールアウト前にモデルバージョンをピン留めしておくのが基本です。

# Bedrockの例
export ANTHROPIC_DEFAULT_OPUS_MODEL='us.anthropic.claude-opus-4-7'

# Vertex AIの例
export ANTHROPIC_DEFAULT_OPUS_MODEL='claude-opus-4-7'

# Foundryの例
export ANTHROPIC_DEFAULT_OPUS_MODEL='claude-opus-4-7'

ピン留めしないと、Claude Codeはエイリアスを最新版に解決します。Anthropicが新しいモデルをリリースした際、ユーザーのアカウントでまだ有効化されていない場合、BedrockやVertex AIのユーザーは前バージョンへフォールバックする通知を見ることになり、Foundryユーザーはエラーを見ることになります。

ピン留めしておけば、新モデルへの移行タイミングを組織側で管理できます。

13.4 Prompt cachingの制御

Claude Codeは自動的にprompt cachingを利用してパフォーマンスとコストを最適化します。これを無効化したい場合は次の環境変数を使います。

特定モデルのデバッグや、クラウドプロバイダーごとに異なるキャッシュ実装の検証で使います。

13.5 ガバナンスとコスト管理の観点でチームに敷くべき設定

組織展開する際の設定指針をまとめます。

(1) モデルの制限

セキュリティや予算上の理由で特定モデルだけを許可したい場合は、managed settingsに availableModels を設定します。これは最高優先度で、ユーザー側からは上書きできません。

(2) effortレベルのデフォルト

組織として「コスト重視で運用したい」「品質重視で運用したい」の方針がある場合、ユーザー設定で effortLevel のデフォルトを揃えます。Proプランでも品質を確保したい場合は effortLevel: high 以上が目安、コスト重視なら medium を出発点として検討します。

(3) 1Mコンテキストの制御

大規模リポジトリで1Mを活用したいケースがある一方、コスト爆発を避けたいケースもあります。組織として1Mを制限したい場合は CLAUDE_CODE_DISABLE_1M_CONTEXT=1 をmanaged settings経由で配布します。

(4) ツール権限のガードレール

.claude/settings.json でツール権限を細かく定義し、リポジトリにコミットします。これによりチーム全員に同じ権限ルールが適用されます。

{
  "permissions": {
    "allowedTools": ["Read", "Write", "Bash(git *)", "Bash(npm *)"],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Write(./production.config.*)"
    ]
  }
}

(5) 利用状況の監視

エンタープライズ利用では、管理者向け設定、利用状況の可視化、OpenTelemetry連携などを通じて、利用状況とコストを監視します。詳細は公式のMonitoring usageを参照してください。

↑ 目次に戻る

第3部:Claude Code Web版で使うOpus 4.7

14. Claude Code Web版とは何か

本記事では、公式ドキュメントで "Claude Code on the web" と呼ばれている機能を、日本語では「Claude Code Web版」と表記します。

Claude CodeにはCLI版だけでなく、ブラウザから使えるクラウド実行環境があります。公式ドキュメントUse Claude Code on the webによれば、Web版は claude.ai/code で動作し、Anthropicが管理するクラウドインフラ上で各セッションを実行します。リサーチプレビューとして提供されており、Pro / Max / Teamプラン、Enterpriseプランのpremium seatまたはChat + Claude Code seatで利用可能です。

なお、Web版はAnthropic管理のクラウド実行環境でコードを扱うため、企業利用ではリポジトリアクセス権限、GitHub Appの導入範囲、環境変数、ネットワークアクセス、PRコメントによる自動実行トリガーを事前に確認しておく必要があります。第15章以降で具体的な制御ポイントを見ていきます。

14.1 CLI版との違い

CLI版とWeb版の最大の違いは、実行場所とセッションの扱いです。

CLI版は「自分のマシンでエージェントを動かす」ツールです。Web版は「クラウドにエージェントを派遣する」ツールです。これは単なるUIの違いではなく、仕事の任せ方そのものが変わります。

CLI版は対話的なコーディングや、ローカル環境に強く依存するタスク(ローカルDB、ローカルの認証情報、プライベートな依存関係など)に向きます。Web版は明確なゴールを与えて自律実行させ、結果を後で確認する非同期的なワークフローに向きます。Opus 4.7の長時間自律実行性能は、Web版で特に活きます。

14.2 Web版で「使えるもの」「使えないもの」

公式ドキュメントが整理している「クラウドセッションで何が利用可能か」を、Opus 4.7を使う前提で再構成します。

クラウドセッションはリポジトリの新規クローンから始まります。リポジトリにコミットされているものはすべて利用できますが、ローカルマシンにしかない設定は持ち込まれません。

利用可能なもの

• リポジトリ直下の CLAUDE.md
• .claude/settings.json のhooks定義
• .mcp.json のMCPサーバー定義
• .claude/rules/、.claude/skills/、.claude/agents/、.claude/commands/
• .claude/settings.json で宣言したプラグイン(マーケットプレイスから自動インストール)

利用できないもの

• ユーザーレベルの ~/.claude/CLAUDE.md
• ユーザー設定の enabledPlugins
• claude mcp add で追加したMCPサーバー(ユーザー設定に書き込まれるため)
• ローカルのAPIトークンや静的な認証情報
• AWS SSOのような対話的なブラウザ認証

エンジニアリード視点で重要なのは、**「チームでWeb版を使うなら、すべての設定をリポジトリにコミットする運用に切り替える必要がある」**ということです。~/.claude/ に書いていた個人ルールも、チームで使うなら .claude/settings.json や CLAUDE.md に移し、レビュー対象にします。

14.3 プリインストールされている開発ツール

クラウドVMには主要な言語ランタイムとビルドツールがプリインストールされています。実務でよく使うものを整理します。

PostgreSQLとRedisはインストール済みですが、デフォルトでは起動していません。セッション内で service postgresql start のようにClaudeに頼んで起動させます。

正確なバージョンを確認したい場合は、セッション内でClaudeに check-tools を実行させると一覧が出ます。これはクラウドセッション専用のコマンドです。

14.4 リソース上限

公式ドキュメントが明示しているクラウドセッションのリソース上限は次の通りです(変更される可能性あり)。

• 4 vCPU
• 16 GBメモリ
• 30 GBディスク

大規模なビルドジョブやメモリを大量に使うテストはこの上限を超える可能性があります。それを超えるワークロードは、Remote Control機能で自分のハードウェア上でClaude Codeを動かす形になります。

エンジニアリードの判断材料としては、「この上限に収まるタスクはWeb版に任せ、それを超えるタスクはCLI版かRemote Controlに回す」という線引きになります。

↑ 目次に戻る

15. Web版を使い始める — GitHub連携と環境設定

15.1 GitHub認証の2つの方法

クラウドセッションはGitHubリポジトリにアクセスしてコードをクローンし、ブランチをプッシュします。認証方法は2通りあります。

両方とも有効です。Auto-fix(後述)を使う場合はGitHub Appが必須です。/web-setup で接続した後にAuto-fixを使いたくなったら、対象リポジトリにAppを追加でインストールします。

Team / Enterprise管理者は claude.ai/admin-settings/claude-code で /web-setup を無効化できます。Zero Data Retentionを有効にしている組織は、/web-setup を含むクラウドセッション機能を利用できません。

15.2 Environment(環境)の設定

Web版ではEnvironmentという単位でクラウド環境を管理します。Environmentにはネットワークアクセス権限、環境変数、セットアップスクリプトが紐づきます。

エンジニアリードがチームにWeb版を展開する際、最初に整備するのがEnvironmentです。具体的な作業項目は次のとおりです。

環境変数は .env 形式で書きます。1行に1つの KEY=value ペア、値をクォートで囲まない(クォートは値の一部として保存されてしまいます)。

NODE_ENV=development
LOG_LEVEL=debug
DATABASE_URL=postgres://localhost:5432/myapp

重要な注意点: 専用のシークレットストアはまだ用意されていません。環境変数とセットアップスクリプトはEnvironment設定として保存され、そのEnvironmentを編集できる人なら誰でも閲覧できます。本物の本番認証情報を入れるのは避け、ステージング環境やテスト用のキーに留めます。

15.3 セットアップスクリプト

Environmentにはセットアップスクリプトを設定できます。これは新しいクラウドセッションが開始する際、Claude Codeが起動する前に実行されるBashスクリプトです。

• 実行ユーザーはroot(Ubuntu 24.04)
• apt install などのパッケージインストールが可能
• スクリプトが非ゼロで終了するとセッション起動が失敗
• 致命的でないコマンドには || true を付けると安全

例　プリインストールされていない gh CLIを入れる場合

#!/bin/bash
apt update && apt install -y gh

15.4 Environmentキャッシング

セットアップスクリプトは最初の1回だけ実行され、以降はファイルシステムのスナップショットが再利用されます。これがWeb版の起動を高速に保つ仕組みです。

• 初回起動時にスクリプトが走る → ファイルシステムのスナップショットを取得
• 2回目以降のセッションは、スナップショットから起動 → スクリプト再実行なし
• 起動済みのプロセスはキャッシュされない(ファイルだけ)
• 約7日でキャッシュ失効、または環境設定変更時に再実行
• セッションを --resume で再開する場合はスクリプトは走らない

巨大なtoolchainのインストールやDockerイメージのpullをセットアップスクリプトに入れても、毎回起動が遅くなる心配はありません。

15.5 セットアップスクリプトとSessionStart hookの使い分け

両者は似ているようで役割が違います。実務で混同しやすいので整理します。

判断基準はシンプルです。

• 「クラウドにだけ必要なもの」(言語ランタイムやCLIツール) → セットアップスクリプト
• 「プロジェクトとして必要な準備」(npm install やDBマイグレーションなど、ローカルでも走るべきもの) → SessionStart hook

クラウドのみで動かしたいhookを書く場合、CLAUDE_CODE_REMOTE 環境変数(クラウドでは true)でガードを入れます。

#!/bin/bash
if [ "$CLAUDE_CODE_REMOTE" != "true" ]; then
  exit 0
fi
npm install
pip install -r requirements.txt

15.6 ネットワークアクセスの制御

クラウド環境の外向き通信は、Environment単位で4段階のアクセスレベルで制御します。

デフォルトはTrustedです。Trustedで許可されているドメインは公式ドキュメントに網羅されており、npm、PyPI、RubyGems、crates.io、Docker Hub、GCR、ECR、AWS、GCP、Azure、Sentry、Datadogなど、一般的な開発で使うドメインはほぼ含まれています。

社内のprivateレジストリなどを使いたい場合はCustomを選択し、Allowed domainsにドメインを列挙します。*.internal.example.com のようなワイルドカードも使えます。

エンジニアリードの観点では、ここはセキュリティポリシーの線引きに直結します。社内ネットワークやプロキシ経由でしかアクセスできないリソースに依存するタスクは、Web版よりCLI版(あるいはRemote Control)の方が向きます。

↑ 目次に戻る

16. ターミナルとWeb版を行き来する

CLI版とWeb版は別々のツールではなく、同じセッションを行き来できる連続体です。これがエンジニアリード視点で重要なポイントになります。

ターミナルからWeb版へ、Web版からターミナルへ、それぞれ移送する仕組みが用意されています。両方の機能を使うには、CLI版が同じclaude.aiアカウントでサインインしている必要があります。

16.1 ターミナルからWeb版へ — --remote

--remote フラグでターミナルから新しいクラウドセッションを起動できます。

claude --remote "Fix the authentication bug in src/auth/login.ts"

これでclaude.ai上に新しいクラウドセッションが作られ、現在のディレクトリのGitHubリモートを現在のブランチでクローンします。

ローカルにコミットしていない変更はVMに反映されないので、必要なら先にプッシュしておきます。VMはGitHubからクローンするのであって、自分のマシンからではないからです。

--remote でクラウドに送ったあとは、自分のターミナルでは別の作業を続けられます。並列で投げることもできます。

claude --remote "Fix the flaky test in auth.spec.ts"
claude --remote "Update the API documentation"
claude --remote "Refactor the logger to use structured output"

それぞれ独立したクラウドセッションとして並走します。/tasks コマンドで進捗を一覧できます。

エンジニアリード的な使い方としては、**「自分はターミナルで主要なコードを書きながら、付随する雑務を --remote でクラウドに振る」**というパターンが効きます。テスト修正、ドキュメント更新、小さなリファクタなど、注意を割きたくないが誰かにやってほしいタスクをクラウドに任せる感覚です。

16.2 ローカルでプランを立て、クラウドで実行する

複雑なタスクでは、ローカルでプランを立ててからクラウドで実行するという二段構えが有効です。

# 1. ローカルでplanモードに入る
claude --permission-mode plan

planモードでは、Claudeはファイルを読み、コマンドを実行して状況を調べ、ソースコードには触れずにプランを提案します。納得できるプランができたら、リポジトリにコミットしてプッシュ。

# 2. クラウドで実行
claude --remote "Execute the migration plan in docs/migration-plan.md"

このパターンは、戦略の決定権は人間が握り、実行はクラウドに任せる形になります。Opus 4.7の自律実行性能を活かしつつ、判断ミスのリスクを抑えられる構造です。エンジニアリードがチームに展開する際、推奨ワークフローとして示しやすい形でもあります。

「プランそのものをクラウドで作りたい」場合はultraplanを使います。Webセッションでプランを生成し、ブラウザでセクションごとにコメントを付けて改善し、納得したらクラウドで実行するか、プランをターミナルに送り返してローカル実行します。

16.3 GitHub連携なしのローカルリポジトリを送る

GitHubに接続していないリポジトリで claude --remote を実行すると、Claude Codeはローカルリポジトリをバンドルしてクラウドに直接アップロードします。バンドルにはすべてのブランチの履歴と、追跡対象ファイルの未コミット変更が含まれます。

GitHub接続済みでも強制的にバンドルを使いたい場合は CCR_FORCE_BUNDLE=1 を設定します。

CCR_FORCE_BUNDLE=1 claude --remote "Run the test suite and fix any failures"

制約:

• git リポジトリで、コミットが少なくとも1つ必要
• バンドルサイズは100 MB未満(超過時は自動的にカレントブランチのみ → 単一スカッシュスナップショットへフォールバック)
• 追跡されていないファイルは含まれない(git add してから送る)
• バンドルから作ったセッションはGitHubプッシュができない(GitHub認証も併用していれば可能)

GitLabやBitbucketのリポジトリをWeb版で扱いたい場合、この方法でクラウドに送れますが、結果のプッシュバックはできない点に注意が必要です。

16.4 Web版からターミナルへ — --teleport

クラウドで動いているセッションを、自分のターミナルに引き取って続きを書くこともできます。

# インタラクティブにセッションを選ぶ
claude --teleport

# セッションIDを直接指定
claude --teleport <session-id>

セッション内ですでにClaude Codeを動かしているなら、/teleport(/tp)でも同じことができます。/tasks でセッション一覧を出し、t キーを押してteleportすることも可能です。

teleportは**--resume とは別物**です。--resume はこのマシンのローカル履歴を再開するだけで、クラウドセッションには触れません。--teleport はクラウドセッションのブランチをチェックアウトし、会話履歴をすべてターミナルに引き取ります。

teleportの前提条件は次のとおりです

• 作業ディレクトリにコミットされていない変更がない(あればstashプロンプトが出る)
• 同じリポジトリのチェックアウトから実行している(forkではダメ)
• セッションのブランチがリモートにプッシュ済み
• 同じclaude.aiアカウントで認証されている

エンジニアリード視点での使い方は、**「クラウドが大方やってくれた仕事を、最後の微調整だけターミナルで詰める」**というワークフロー。たとえば、CIで失敗していた問題をクラウドが直してくれたあと、--teleport で自分の手元に持ってきて、コミットメッセージを書き直してpushする、といった具合です。

逆方向(ローカル → Web)への送出はコマンドラインからは現在サポートされていません。Desktopアプリの「Continue in」メニューが提供されています。

↑ 目次に戻る

17. Web版でのセッション運用

17.1 セッションの永続性とモバイル監視

Web版の最大の強みのひとつが、セッションの永続性です。ブラウザを閉じても、ノートPCを閉じても、クラウドのセッションは動き続けます。

監視方法は3つあります。

• ブラウザでclaude.ai/codeを開く
• Claudeモバイルアプリを開く
• ターミナルで /tasks を実行(CLI版がサインイン済みの場合)

エンジニアリード視点で意味を持つのは、**「自分が会議に入っている間、Claudeにコードを書かせ続けられる」**という点です。30分の会議の前に claude --remote "..." を投げて、会議が終わった頃に結果を確認する、というワークフローが成立します。

17.2 コンテキスト管理

Web版でもCLI版と同じく、セッション内のコンテキスト管理が重要です。Web版で使えるビルトインコマンドは限定的です。

コンテキストウィンドウが容量に近づくと自動圧縮が走ります。これはCLI版と同じ挙動で、デフォルトは約95%でトリガーされます。早めに圧縮させたい場合は、Environment変数に CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=70 のように設定すれば、70%で圧縮を始めるよう調整できます。

17.3 変更内容のレビュー

各セッションには +42 -18 のようなdiffインジケーターが表示されます。クリックするとdiffビューが開き、特定の行にインラインコメントを残せます。次のメッセージでClaudeにコメントが渡され、修正を依頼できます。

このフローは、エンジニアリード視点では「コードレビューをそのまま指示に変える」体験になります。GitHub PRレビューと同じ感覚で、コメントが直接Claudeへのフィードバックになる、という流れです。

セッションから直接PRを作成することもできます。詳細は公式のReview and iterateガイドを参照してください。

17.4 セッション共有

Web版のセッションはチームで共有できます。共有設定はアカウント種別で異なります。

Enterprise / Teamでは、受信側のアカウントに紐づいたGitHubアカウントでリポジトリアクセス検証がデフォルトで有効です。Max / Proではこの検証はデフォルト無効なので、共有前に内容を確認します(プライベートリポジトリのコードや認証情報が含まれる可能性があるため)。

Slack連携経由のセッションは自動的にTeam可視性で共有されます。

エンジニアリードがチームでセッション共有を活用するなら、**「困ったタスクをセッション共有で渡す」**というパターンが有効です。新メンバーがハマっているバグを、自分のセッションで原因まで調べてからセッションURLを渡す、という流れがそのまま再現できます。

17.5 Auto-fix — PRを見守らせる

これはWeb版でしか使えない機能で、なかなか強力です。

ClaudeにプルリクエストをWeb版で監視させ、CI失敗やレビューコメントに自動対応させられます。

仕組み:ClaudeはPRのGitHubイベントを購読し、CIチェック失敗やレビューコメントが入るたびに調査して、明確な修正があればプッシュします。

判断基準

• 明確な修正 → 修正してプッシュし、セッションで何をしたか説明
• 曖昧な依頼 → 解釈が複数ある場合や設計上重要な変更の場合は、人間に確認
• 重複・無対応で済むイベント → セッションにメモして次へ

Auto-fixを有効にする方法は複数あります:

• Web版で作成したPR:CIステータスバーからAuto-fixを選択
• ターミナルから:PRのブランチで /autofix-pr を実行
• モバイルアプリから:Claudeに「このPRを見張って修正してください」と頼む
• 既存のどんなPRでも:PRのURLをセッションに貼って指示

Auto-fixはGitHub Appが必須です(PR webhookを受信するため)。

注意点:Auto-fixがPRコメントに返信する際、ユーザー名はあなたのGitHubアカウントとして表示されます(個別のラベルでClaude Code経由とは識別されます)。Atlantis、Terraform Cloud、issue_comment で発火するGitHub Actionsなど、コメント駆動の自動化を使っているリポジトリでは、Claudeのコメントがそれらを起動する可能性があります。インフラデプロイや特権操作をPRコメントで実行できる仕組みがあるリポジトリでは、Auto-fixを有効にする前にレビューが必要です。

エンジニアリードとしては、「Auto-fixを許可するリポジトリの線引き」をチーム方針として決めておくのが安全です。アプリケーションコードのPRはOK、インフラリポジトリはNG、というポリシーを明文化しておく形です。

17.6 アーカイブと削除

セッションが増えすぎたら整理できます。

• アーカイブ:サイドバーで対象セッションをホバーしてアーカイブアイコン。デフォルトのリストから消えるが、フィルタで表示可能
• 削除:アーカイブ済みセッションのリストからホバーして削除アイコン、またはセッションを開いてタイトル横のドロップダウンからDelete

削除は取り消せません。

↑ 目次に戻る

18. Web版でOpus 4.7を活かすコーディング作法

ここまでがWeb版の機能解説です。最後に、Opus 4.7をWeb版で使う際のコーディング実務上の作法をまとめます。エンジニアリードとしてチームに教える際にも、自分で手を動かすときにも使える形で整理します。

18.1 タスクの粒度設計

Web版に投げるタスクは、CLI版で対話しながら進めるタスクとはちょうどいい大きさが違います。Web版は途中で口を出すのにひと手間かかるので、1つのセッションで1つのタスクが完結するくらいの大きさに揃えるのが現実的です。

向いているタスクの例

• 機能を1つだけ実装する(APIエンドポイントを足す、フォームのバリデーションを足す、など)
• CIで落ちている1つのテストを直す
• ドキュメントを更新する(README、APIリファレンス、変更ログなど)
• 特定のモジュールだけをリファクタリングする
• 依存ライブラリをアップデートして、それに伴う修正をする
• テストカバレッジを増やす

向いていないタスクの例

• どう作るか決まっていない、探索しながら進めるような開発(planモードと組み合わせれば可能)
• 本番の認証情報が必要なタスク
• ローカルにあるコミットしていない変更を前提とするタスク
• VMのリソース上限を超えそうな重いビルド

18.2 初回プロンプトの書き方(Web版仕様)

第2部第8.1節で紹介した「依頼書スタイル」はWeb版でも基本になりますが、Web版ではこれにいくつか項目を足します。

[目的]
ユーザー認証APIをOAuth 2.0ベースに作り変える。

[守ってほしいこと]
- 既存のセッション管理ロジック(src/auth/session.ts)は触らない
- 段階的に移行し、既存の認証エンドポイントとの互換性は保つ
- TypeScriptのstrictモードは外さない

[完了の条件]
- 既存テスト(tests/auth/)がすべてパスすること
- 新しいOAuthフロー用のE2Eテストが追加されていること
- README.mdの認証セクションが更新されていること

[見てほしいファイル]
- src/auth/*.ts
- tests/auth/*.test.ts
- README.md

[ブランチ運用]
- 現在のブランチから派生させ、`feature/oauth-migration` という名前にする

[PR作成について]
- 完了したらPRを作る
- PR本文に、このセッションへのリンクを貼っておく

Web版で特に大事なのが最後の2項目です。Web版はクラウドのVMの中だけで作業が完結するので、ブランチを切るところからPRを作るところまで、最初のお願いの中に書いておくと、人間があとから介入する手間が減ります。

PR本文にセッションリンクを入れる運用は公式でも推奨されています。レビュアーが「このPRはどのセッションから生まれたんだろう?」と気になったとき、リンクから元の作業をたどれるようになります。Claudeにセッションリンクを作ってもらうときは、この1行で済みます。

echo "https://claude.ai/code/${CLAUDE_CODE_REMOTE_SESSION_ID}"

CLAUDE_CODE_REMOTE_SESSION_ID という環境変数は、クラウドセッションの中だと自動でセットされています。

18.3 4.6時代の補助的な指示はWeb版でも外す

第1部・第2部で繰り返し書いた通り、Opus 4.7では「念のため確認して」「進捗をこまめに報告して」のような補助的な指示は外します。Web版では特にこの方針が効きます。

理由はシンプルです。Web版が想定している「ブラウザを閉じても動き続ける長時間タスク」では、そもそも人間がそばで見張っている前提を捨てているからです。Claudeが自分で動作を検証し、自分で進捗を報告し、迷ったら自分で止まる。この挙動を信じて任せる設計が必要になります。

CLAUDE.mdにチーム共通のルールとして書くなら、4.7向けにはこんな書き方が合います。

# 開発のガイドライン

## 作業の進め方
- これはクラウドセッションで動く、長時間の自律タスクです。
- 大きな変更を加えたら、そのつどテストを走らせて動作を確かめてください。
- 仕様が本当にどちらとも取れる場合だけ、手を止めて質問してください。それ以外は自分で判断して進めて構いません。
- 途中の細かいステップごとに、人間に確認を取る必要はありません。

18.4 並列実行を活かす

Web版の構造的な強みが、複数のタスクを同時に走らせられることです。CLI版で同じことをやろうとすると、ターミナルを複数立ち上げて、それぞれの権限プロンプトに答えて……と手間がかかります。Web版なら --remote を3回叩くだけで、3つのクラウドセッションが同時に動き始めます。

Opus 4.7はsubagentをデフォルトでは控えめにしか起動しません。そのため、Web版で大規模に並列処理したい場合は、**「--remote を何回か叩いて、独立したタスクとして並走させる」**ほうが、subagentを明示的に指示するより素直なやり方です。それぞれ別のVM、別のコンテキスト、別のブランチで動くので、お互いに干渉する心配もありません。

向いている例

• 複数のレガシーモジュールを並行して移行する
• 複数のサービスにセキュリティパッチを当てて回る
• 複数言語の翻訳ファイルをまとめて更新する
• ジャンル別のテストを並行で直す

/tasks で全セッションの進み具合を一覧で確認し、終わったものから順に手元に引き取る(teleport)か、レビューに回します。

18.5 1Mコンテキストの恩恵

Opus 4.7で標準価格になった1MコンテキストはWeb版で特に効きます。クラウドVMはリポジトリをまるごとクローンしたところから始まるので、リポジトリ全体をClaudeに読ませる前提のタスクが現実的になります。

具体例はこんな感じです。

• 数百ファイルにまたがるリファクタリング(命名規則を揃える、APIを移行する、など)
• 複数のサブシステムをまたぐ依存関係の調査
• レガシーコードベース全体を読んだうえで、段階的に作り直す
• リポジトリ全体のセキュリティ監査

第2部第10章で触れた [1m] サフィックスや、opusplan の落とし穴(1Mに自動アップグレードされない)は、Web版でも同じです。

18.6 うまくいかなかったときの動き方

Web版のセッションがうまくいかなかったとき、人間の動き方はCLI版と少し違います。

セッションの中でできることは限られています(ターミナルで対話的に探るような動きができないため)。代わりに次の選択肢があります。

1. diffビューの気になる行にコメントを残し、次のメッセージで指示を出す:Web版で軌道修正する一番自然なやり方
2. /compact で会話履歴を要約してから、別のアプローチを指示する:暴走しかけたセッションを、リセットせずに引き継ぎたいとき
3. --teleport でターミナルに引き取って、自分の手で直す:Claudeがループから抜けられなくなったり、対話的なデバッグが必要になったとき
4. そのセッションは諦めて、もっと良いプロンプトで新しいセッションを作る:そもそも方針自体が違ったとき

エンジニアリードの目線で言うと、**「Web版のセッションは安いし、並列でいくらでも走らせられる。粘らないで切り替える判断も大事」**というのが現場感覚です。Opus 4.7が変な方針のまま長く動き続けるよりは、新しいセッションで仕切り直したほうが結果的に速いことが多いです。

18.7 チームに広げるかどうかの判断材料

ここまでが18章の各論ですが、最後にチームへの展開をどう判断するかをまとめておきます

ただ、その判断の前にもっと大事な前提を一つ書いておきます。

Claude Codeは、動作環境と直結させて、その場で検証させながら進めるのが大原則です。

これはCLI版・Web版どちらを選ぶかの議論より前に来る話です。Claudeに依頼を投げて「たぶんいい感じに直してくれているだろう」と放置していると、コンパイルすら通っていないコードが量産される、テストが落ちたまま完了報告される、見た目が壊れたUIが「直しました」と返ってくる、ということが普通に起こります。Opus 4.7は4.6より自己検証する傾向が強くなったとはいえ、検証手段が手元に用意されていなければ、Claudeも検証のしようがありません。

具体的には、こういう状態を作っておくのが基本です。

• コードを書いたら、すぐビルド・テストを走らせる:Claudeが変更を加えるたびに npm test や cargo test、pytest が動く状態にしておく
• APIを直したら、すぐ叩いてみる:ローカルのサーバーを立ち上げておいて、curl やテストクライアントで実際にレスポンスを確認する
• DBを触ったら、実データで動かしてみる:開発用DBに接続して、クエリが通るか、想定どおりのデータが返ってくるかを確認する
• UIを直したら、ブラウザで実際に表示する:Playwright系のMCPやClaude in Chromeで、見た目とインタラクションを確認する
• エラーが出たら、ログを直接読ませる:推測で対処させるのではなく、実際のスタックトレースやサーバーログをClaudeに見せて原因を切り分けさせる

このループを回せるかどうかが、Claude Codeで成果が出るチームと出ないチームの分かれ目になります。「依頼書を書いて、結果を見る」だけのワークフローでは、いずれ品質が崩れます。

この前提に立つと、CLI版が基本になる

動作環境と直結させて検証させながら進める、という原則を置くと、CLI版を中心にすべき理由が自然に出てきます。CLI版でしかできない、もしくはCLI版のほうが圧倒的にやりやすいことが多いからです。

• ローカルDBに直接つなげる:開発用のPostgreSQLやMySQLが手元で動いていれば、Claudeにスキーマを読ませたり、実データでクエリを試させたり、マイグレーションを当てて結果を確認させたりが普通にできます。Web版だとクラウドVMからローカルのDBは見えないので、検証用データを別途用意したり、本番に近い環境を再構築したりという余分な手間がかかります。
• MCP経由でChromeを操作させられる:Claude in Chrome やPlaywright系のMCPと組み合わせれば、実際のブラウザでフロントを動かして、見た目を確認しながら直してもらえます。「画面で確認しないと分からない」種類のバグでは、これがあるかないかで作業の質がまるで違います。
• ローカルにしかないリソースが使える:社内ネットワーク経由でしか叩けないAPI、VPN越しの検証環境、ローカルのDocker Composeで立ち上げた一式、~/.aws/credentials のような認証情報。こういうものを巻き込んで動作検証できるのはCLI版だけです。
• 書いたコードをすぐ自分の目で確かめられる:エディタ、ブラウザのプレビュー、ホットリロード、デバッガ。普段使っている開発体験をそのまま活かして、Claudeの変更を即座に検証できます。
• 新機能がCLI版から先に来る:Claude Codeの新機能は、基本的にCLI版に先に入って、しばらくしてからWeb版にも来る、というリリースパターンです。最新機能を早く触りたいならCLI版です。
• 権限やhookを細かくコントロールできる:.claude/settings.local.json で個人ごとに調整したり、hookで特定のコマンドの前後に処理を挟んだり、設定の自由度はCLI版のほうが高いです。

要するに、CLI版は 「Claudeを自分の開発環境の中に住まわせて、自分の目の前で動作検証させながら進める」 ためのツールです。

Web版を積極的に使うといいケース

一方で、CLI版の小回りが要らない場面では、Web版のほうが圧倒的に楽です。Web版の魅力は性能の高さでも機能の豊富さでもなく、**「とにかく楽」**という一点に尽きます。

• 複数セッションを同時に走らせるのがとにかく楽:CLI版で並列実行しようとすると、ターミナルを複数開いて、それぞれの権限プロンプトに答えて、進捗をタブ間で見比べて……と地味に手間がかかります。Web版なら --remote を3回叩くか、ブラウザでセッションを3つ開くだけで終わりです。複数タスクを並列で進めたいときの「楽さ」は、Web版が頭ひとつ抜けています。
• ブラウザを閉じても作業が進む:長時間タスクをWeb版に任せて、自分はノートPCを閉じて移動する、会議に出る、別の仕事をする、ということができます。
• GitHubへのプッシュやPR作成までお任せにできる:ブランチを切ってコミットしてプッシュしてPRを作る、という一連の流れを、自分の手でやらずにWeb版に任せたいときに便利です。CLI版でも同じことはできますが、Web版はGitHub周りが最初から組み込まれていて、認証も含めて手間が少ないです。
• 動作検証が「ビルド + テスト」で完結する作業:バックエンドのリファクタリング、CI修正、ドキュメント更新、依存関係のアップデート。クラウドVMの中でビルドして、テストを走らせて、それで品質が担保できるタイプの作業は、Web版の得意分野です。逆に言うと、ローカルDBや実ブラウザでの確認が必要な作業はWeb版では検証しきれない、ということでもあります。
• リポジトリの中だけで話が完結する:ローカルの何かに依存しない、リポジトリ内のコードとテストだけで完結するタスクなら、Web版に投げて困ることはほとんどありません。
• 非同期で進める働き方が受け入れられる文化がある:「投げて、しばらく経ってから結果を見る」というリズムが合うチームなら、Web版の良さを引き出しやすいです。

Web版を選ぶときの注意点

• ローカル環境での動作検証が必要な作業はWeb版では完結しません
• ローカルDB、ローカルブラウザ、社内ネットワーク内のリソースに依存する作業も同様です
• リソース上限(4 vCPU / 16 GB / 30 GB)を超える重いビルドやテストは、そもそもWeb版で動きません
• セルフホストのGit(GitHub Enterprise Server以外のGitLab、Bitbucketなど)中心のチームは、Web版の恩恵を受けにくいです

現実的な始め方

ここまでをまとめると、CLI版を主役にして自分の開発環境の中で動作検証しながら進める。並列で走らせたい雑務だけWeb版に振るというのが、いちばん安全で効果が出やすいやり方です。

たとえばこんな使い分けが現実的です。

• 自分は手元のCLI版で主要な実装を進める。ローカルDB、ブラウザ、テストランナーをすべて巻き込んで、その場で動作検証させながら進める
• 並行して走らせたい雑務(明らかな小規模リファクタ、ドキュメント更新、CIで落ちている既知のテスト修正など)は --remote でクラウドに振る
• クラウドのセッションが終わっていたら、--teleport で手元に引き取って、最後の動作確認だけ自分の環境でやる

この使い分けに慣れてくると、「これは動作検証が手元で必要だからCLI版」「これはビルド+テストで足りるからWeb版」の感覚が自然と身につきます。チーム展開もこの段階から始めるのが無理がないです。

↑ 目次に戻る

まとめ

ここまで、Claude Opus 4.7のモデル仕様、Claude Code CLI版での実践ノウハウ、Claude Code Web版の使い方を、公式情報をもとに見てきました。最後に、全体を通しての要点を簡潔にまとめます。

Opus 4.7で最も大きく変わったのは、性能そのものよりもモデルの振る舞いです。命令を字面通りに解釈し、必要なときだけ深く考え、自発的に進捗を報告し、自分の出力を検証する。このモデルを最大限活用するには、人間側のインタラクションパターンを変える必要があります。公式が繰り返し強調しているメッセージは、「ペアプログラマーとして一行ずつ指導するのではなく、業務を委譲する有能なエンジニアとして扱う」という一点に集約されます。

実務上の要点は5つです。

まず、初回プロンプトに依頼の全情報を集約すること。意図、制約、完了条件、関連ファイルを最初に渡し、途中介入を最小限に抑えます。これがトークン効率と品質の両方を最大化します。

次に、4.6時代の補助的な指示を外して再評価すること。「念のため確認して」「進捗を報告して」「ダブルチェックして」のような指示は、4.7では自発的に行われるか、字面通りに過剰反応するかのどちらかになります。公式が「外せ」と明示している補助的な指示は、いったん外してから再評価するのが基本ラインです。

そして、effortレベルを意識的に選ぶこと。CLI版では xhigh をデフォルトとし、用途に応じて切り替えます。max は必要以上に考え込むリスクがあるため意図的にのみ使い、コスト重視の作業では medium や high に下げます。

さらに、1Mコンテキストの活用と注意点を理解すること。Max / Team / EnterpriseプランのClaude Codeでは自動でアップグレードされ、追加プレミアムは付きません。一方で opusplan には適用されない、トークン消費は当然増える、といった点を踏まえてアーキテクチャを設計します。

最後に、CLI版とWeb版を連続体として使うこと。対話的な作業や手元の検証はCLI版、明確なゴールがある自律実行と並列タスクはWeb版、というのが基本線です。--remote でクラウドにタスクを送出し、--teleport で手元に引き戻す、という行き来がOpus 4.7の自律実行性能を最大限に引き出します。

APIを直接利用している場合は、これに加えてMessages APIの破壊的変更(temperature などのsamplingパラメータ禁止、固定thinking budgetの廃止、prefillの廃止、新トークナイザーによるトークン消費の増加)への対応が必要です。Claude Managed Agentsを利用している場合は、モデルIDの更新だけで移行が完了します。

これらの指針はすべて、Anthropicの公式ドキュメントに基づいています。本記事で参照した主要な情報源は次の通りです。

仕様や挙動は今後も更新される可能性があるため、最終的な判断は常に最新の公式ドキュメントを参照することをお勧めします。本記事が、Opus 4.7を業務で活用する際の判断材料として役立てば幸いです。

↑ 目次に戻る