Claude Code opusplan｜設計Opus×実行Sonnetの戦略

/model opusplanは、考える工程と手を動かす工程で別のモデルを使い分ける仕組みです。AI活用の勝ち負けは「どのモデルを使うか」ではなく「どの工程にどのモデルを置くか」で決まります。

/model opusplanとは、Claude Codeの計画（Plan）フェーズでは推論力の高いOpusを使い、実行（Execute）フェーズでは高速・低コストなSonnetに自動で切り替えるハイブリッドエイリアスです。複雑な設計判断はOpusの推論力で、大量のコード生成はSonnetの速度で処理することで、品質とコスト効率を両立させる運用手法になります。

本記事は「Claude Code実践ガイド｜AI開発の生産性を高める運用設計」シリーズの一部です。

この記事でわかること

Claude Codeでモデルを切り替えながら開発を進めているものの、「結局どの場面でどれを使うべきか」を言葉にできていない方に向けて、opusplanの仕組みから実務での判断基準までを整理しました。

• /model opusplanの動作原理とモデル切り替えの仕組み — Planフェーズでは推論力の高いOpus、Executeフェーズでは高速なSonnetに自動で切り替わるエイリアスの中身を、フェーズごとの役割分担として整理します。
• Opus単体・Sonnet単体との比較（品質・速度・コスト） — 推論品質・実行速度・コスト・長時間作業の持続性という4つの観点で、3つの選択肢を表で比較します。
• 実務でのopusplan活用パターンと使い分け判断基準 — 新機能の設計と実装、大規模リファクタリング、バグ調査など、「思考」と「実行」が混在するタスクでの使い方を具体的に示します。
• 向かないケースと正直な限界 — 単純作業や短時間タスクではopusplanが過剰になる場面もあるため、あえて使わない判断基準もあわせて書いています。
• チームで定着させるための仕組み化 — 個人の慣れに頼らず、新しく入ったメンバーでも同じモデル選択ができる状態にするための運用設計を解説します。

Claude Codeのモデル選択とコスト最適化に関心があるエンジニア・テックリード、そしてAI開発ツールの利用方針を決める立場の方に向けて書いています。最後まで読むと、自社のタスク特性に合わせて「どの工程にどのモデルを置くか」を自分で判断し、チームの標準ルールとして言語化できるようになります。

opusplanとは何か：思考と実行を分離するという発想

opusplanを単なる「コストを抑えるための設定」として捉えると、本質を見誤ります。この機能の核心は、AIへの依頼を「何をすべきかを決める工程」と「決まったことを形にする工程」に分け、それぞれに適した頭脳を割り当てるという設計思想にあります。ここではまず、コマンドの実体と動作の仕組みを押さえます。

コマンドの実体と基本の使い方

opusplanは、Claude Codeの/modelコマンドで選択できるハイブリッドエイリアスです。セッション内で以下のように入力するだけで切り替わります。

# Claude Codeのセッション内で
/model opusplan

現在どのモデルが選ばれているかを確認したいときは、引数なしで/modelを実行します。

/model
# → 現在のモデル: opusplan (Plan: Opus, Execute: Sonnet)

特別なインストールや設定ファイルの編集は不要で、セッション内のコマンド1行で切り替えが完結します。試してみて合わなければ/model sonnetに戻せばよいため、導入のハードルは低い部類に入ります。設定変更を伴わない分、チームメンバー個々人が自分の作業スタイルに合わせて試しやすい点も、opusplanの扱いやすさにつながっています。

フェーズごとの役割分担

opusplanは、作業のフェーズに応じて使用モデルを自動で切り替えます。役割分担は次のとおりです。

Planフェーズでは、Opusの高度な推論能力を使って「何をすべきか」を分析・設計します。その計画に基づいて、Sonnetが実際のコード生成やファイル操作を高速に実行するという流れです。ユーザーが手動で切り替える必要はなく、/model opusplanを設定するだけで、Claude Codeが内部的にフェーズを判断してモデルを選択します。

なぜハイブリッドが有効なのか

Opusは推論能力に優れますが、コストが高く、レートリミットにも早く到達します。Sonnetはコスト効率と速度に優れますが、複雑な設計判断では精度が落ちることがあります。どちらか一方に寄せると、どこかに歪みが出やすくなるわけです。

opusplanの本質は「思考と実行の分離」です。複雑な設計判断にはOpusの推論力を投入し、定型的なコード生成にはSonnetの速度とコスト効率を活かす。この適材適所の考え方が、結果としてコストの最適化にもつながります。

ただし、すべてのタスクにopusplanが最適というわけではありません。この点は後半の「向かないケース」で率直に整理します。

「どのモデルを使うか」ではなく「どの工程に置くか」という設計思考

私たちがAI活用のご相談をいただくときに最初にお伝えしているのは、ツールの選定よりも工程の分解が先だということです。これはHubSpotの導入支援でも同じで、機能を眺める前に、自社の業務がどのような工程でできているかを描かないと、設計がうまくいきません。

工程を分解してから道具を割り当てる

HubSpotの導入では、パイプラインの設計から入ることを基本にしています。商談が「アポ取得→初回提案→見積もり提示→受注内示→契約」とどう進むのかを分解し、それぞれのステージに定義と必須入力項目を置いていく。営業プロセスを工程として先に描くからこそ、どのステージで何を確認すべきかが決まり、属人化を防げます。

AIのモデル選択もまったく同じ構造です。「Opusとsonnet、どちらが優秀か」という問いの立て方では答えが出ません。作業を「分析する」「設計する」「書く」「検証する」という工程に分解し、それぞれに必要な能力を見極めてから、どのモデルを割り当てるかを決める。opusplanは、この分解をツール側が自動でやってくれるエイリアスだと捉えると腹落ちしやすいかと思います。

属人的な運用で起きる問題

モデル選択を個人の感覚に任せたままにしておくと、個人単位では回っているように見えても、組織として見ると成果物の品質にばらつきが出ます。レビュー担当者から見れば「このコードはなぜこの設計になっているのか」が読めず、レビューコストが上がる。工程を分解せずに感覚でモデルを選んでいると、この属人的な運用の限界がそのまま表面化してしまうわけです。

判断基準を言語化して共有する

対策はシンプルで、モデル選択の基準を文書に落として共有することです。「アーキテクチャ変更を伴うタスクはopusplan」「既存パターンの複製で済む作業はsonnet」のように、判断のルールを書き出しておく。こうしておけば、新しく入ったメンバーでもルールを読むだけで同じ選択ができます。

私たちがHubSpotのパイプライン設計で必須入力プロパティを推奨する理由も同じです。必須項目は、データ品質を担保すると同時に「新人が何を確認すべきか」を教えるツールにもなります。モデル選択のルールも、ベテランの勘を新人に引き継ぐための仕組みとして機能します。個人の記憶やその場の判断に頼らず、書かれたルールで回る状態を作ることが、opusplanをチームの資産にする第一歩です。

セットアップと他のモデルオプションとの比較

opusplanの導入そのものは数秒で終わります。ここで重要なのは、他の選択肢との違いを理解したうえで、どの場面でどれを選ぶかを決めておくことです。選択肢を並べて比べると、それぞれの立ち位置がはっきりします。

3つのモデル指定の違い

Claude Codeの/modelコマンドで選べる主な指定は次のとおりです。

日々の細かな修正やテストの追加であればsonnetで十分です。一方、設計の良し悪しがその後の保守コストを大きく左右するような作業では、Planフェーズにopusを置く価値が出てきます。モデル/Effort選択の解説記事で扱っている/modelコマンドの選択肢の中で、opusplanはコスト効率と品質のバランスを取りにいくオプションという位置づけです。

切り替えのタイミングを決めておく

切り替え自体はいつでもできますが、セッションの途中で何度も変えると、どのフェーズがどのモデルで処理されたかが追いづらくなります。タスクを開始する前にモデルを決めて、そのタスクが終わるまでは変えない。この運用にしておくと、後から成果物の品質を振り返るときに原因が特定しやすくなります。

スモールスタートの進め方

いきなり全員・全タスクでopusplanに切り替える必要はありません。まずは1〜2名のメンバーが、設計判断を伴うタスクに限定して試してみる。そこで「設計の質が上がったか」「レビューの手戻りが減ったか」を振り返り、効果が見えたタスク種別から順にルール化していく、という進め方をおすすめしています。

効果が出そうなところを見極めて優先順位をつけ、そこからトライしていく。この段階的な進め方は、HubSpotの導入支援でも一貫してお伝えしている考え方です。まずは自分たちが最も手戻りに悩んでいるタスク種別を1つ選び、そこから範囲を広げていくのが現実的な進め方かと思います。

実務での活用パターンと使い分け判断基準

ここからは、実際にどのようなタスクでopusplanが効くのかを、代表的な4つのパターンで整理します。共通するのは、いずれも「何をどうすべきかの判断」と「大量の手作業」が1つのタスクに混在している点です。

パターン1：新機能のアーキテクチャ設計と実装

新しい機能を追加する際、まずOpusにアーキテクチャを設計させ、その設計をSonnetが実装します。例えば、次のような依頼の出し方です。

「HubSpot APIからコンタクトデータを取得し、
Supabaseに同期するパイプラインを設計・実装してください。
エラーハンドリングとリトライロジックを含めて。」

この依頼に対して、各フェーズの担当は以下のように分かれます。

エラーパターンの洗い出しやリトライ戦略の判断は、システム全体の理解が必要な作業です。ここをOpusに任せることで、後から「この例外処理が漏れていた」という手戻りを減らせる可能性が高まります。

パターン2：大規模リファクタリング

既存コードベースのリファクタリングでは、「何をどう変更すべきか」の判断が最も重要になります。

「src/services/配下のAPI呼び出しを、共通のHTTPクライアントに統合してください。
エラーハンドリングのパターンも統一して。」

Opusがコードベース全体を分析してリファクタリング計画を立案し、Sonnetが計画に従って各ファイルを効率的に修正します。実行フェーズはファイル数に比例して時間がかかるため、Claude Code Dispatchで外出先から進捗を確認する運用とも相性の良い作業です。

パターン3：バグの原因調査と修正

複雑なバグの調査には、Opusの推論力が有効に働きます。原因が特定された後の修正作業はSonnetが担う形です。

「ダッシュボードの売上グラフが特定の日付範囲で表示されない問題を調査して修正してください。」

原因の特定は仮説を立てて検証する思考の作業であり、修正はその結論を反映する手作業です。工程の性質がはっきり分かれるため、opusplanの分離が活きやすいパターンになります。

パターン4：ドキュメント生成

API仕様書やアーキテクチャドキュメントでは、構成をOpusが設計し、実際のドキュメントファイルをSonnetが生成するという分担になります。どの章立てで何を書くべきかという判断と、各章の文章を埋めていく作業を分けるイメージです。4つのパターンに共通しているのは、判断の部分だけをOpusに絞り込み、それ以外はSonnetに任せるという線引きの明確さです。

コストと品質のバランスをどう捉えるか

opusplanの導入理由を「コストのため」だけに置いてしまうと、社内の合意形成でつまずきやすくなります。私たちがお客様にご説明するときは、「必要な場面にだけ高性能な頭脳を投入する」というリソース配分の考え方として整理しています。

コスト構造の考え方

opusplanのコスト構造は、Planフェーズのみ高コストなOpusを使い、Executeフェーズは低コストなSonnetが担当するという形になります。

実際の削減幅はタスクの性質や設計フェーズの比重によって変わるため、自社の利用実態で数週間計測してから判断するのが確実です。

レートリミットという見えないコスト

金額以上に効いてくるのが、レートリミットによる作業の中断です。Opus単体で長時間作業を続けると上限に達しやすく、作業が途中で止まると、そこまでの文脈を取り戻す時間が別途かかります。opusplanは実行フェーズの消費を抑えるため、長時間の作業を持続しやすくなる点が実務上の利点になります。

コスト最適化の全体戦略と組み合わせることで、より効果的な運用が可能です。

経営視点での位置づけ

opusplanの考え方は、ビジネスにおける「設計と実行の分離」そのものです。経営戦略の立案には時間をかけて考える力が必要で、日々のオペレーションには効率的に回す力が必要になる。この二つを同じリソース配分で扱わないのは、組織運営では当たり前の発想かと思います。

少数精鋭の組織ほど、限られた予算でAIの恩恵を最大化する必要があります。opusplanは「必要な場面にだけ高性能モデルを投入する」という合理的なリソース配分を、ツールのレベルで実現する選択肢です。

planモードとの違いと組み合わせ方

/model opusplanとplanモードは名前が似ているため混同されやすいのですが、まったく異なる概念です。ここを整理しておかないと、「planモードにしたのにOpusが使われない」といった行き違いが起きます。

概念の違い

opusplanが決めるのは「どのモデルを使うか」であり、planモードが決めるのは「書き込みを許すかどうか」です。前者はモデル選択の話、後者は権限の話であり、制御している対象がそもそも違います。

二段階ワークフローの組み立て

両者は組み合わせて使えます。例えば、まずplanモードでOpusに分析させ、その分析結果を人間が確認したうえでautoモードに切り替えてopusplanでタスクを実行する、という二段階のワークフローです。

autoモードの設定と安全な運用範囲はClaude Codeのautoモード完全ガイドで解説しています。

人間のレビューを挟む理由

私たちは、AIの出力をそのまま本番に反映させる運用は避けるべきだと考えています。AIは方向性の提示や下書きの作成が得意ですが、そのアウトプットが自社の事情に合っているかどうかの判断は人間が担うべき領域です。

特に、影響範囲の大きい変更ほど、計画段階で一度止めて中身を見る価値があります。二段階ワークフローは、その「止める場所」を運用に組み込むための型として有効かと思います。

AIに任せる範囲と人間が判断する範囲

opusplanを導入しても、「どこまでAIに委ねるか」の線引きが曖昧なままだと、結局レビューの負荷が別の形で戻ってきます。ここでは役割分担の考え方を整理します。

役割分担の整理

opusplanはこの表の左側を効率化する仕組みであり、右側を代替するものではありません。Planフェーズの出力が優れているほど「そのまま通してよさそう」に見えますが、そこで一度止めて中身を読む習慣が、結果的にチーム全体の理解度を保ちます。

叩き台としてのAI活用

初めて触れる領域の設計では、まずAIに叩き台を作らせて、後から人間が手を入れるという進め方が取っ掛かりとして有効です。ゼロから考えるよりも、たたき台に対して「ここは違う」と指摘するほうが、判断の負荷は軽くなります。

opusplanのPlanフェーズは、まさにこの叩き台づくりに適したポジションにあります。Opusの推論で一通りの設計案を出させ、それを人間がレビューして方向を修正し、Sonnetが実装する。この流れが定着すると、設計レビューの文化そのものがチームに根付いていきます。

対話型AIとの併用イメージ

AIエージェントを「自社の業務ルールを理解したアシスタント」として使う発想は、開発以外の領域でも同じです。上の画面は、当社の公式サイト上で稼働しているサポートAIが、サイト上で製品に関する質問に回答している様子です。手元の作業を助けるコーディングエージェントと、顧客接点で問い合わせに答えるエージェント。役割は違いますが、どちらも「何を任せ、何を人が見るか」を設計しておくことが前提になります。

HubSpot側でも、Breezeを使ったカスタマーエージェントでは、トーンや回答スタイルをガイドラインとして設定し、回答の根拠を提示させる設計ができます。任せる範囲をガイドラインとして明文化するという点で、モデル選択ルールの言語化と発想は共通しています。

opusplanが向かないケースと運用上の注意点

メリットばかりを並べても実務の判断材料にはなりません。ここでは、あえてopusplanを使わないほうがよい場面と、運用時に気をつけたい点を率直に書きます。

使わないほうがよい場面

特に注意したいのが最後の行です。成果物の品質に問題が出たときに、Planの設計が悪かったのかExecuteの実装が甘かったのかを切り分けたい場面では、いったん単一モデルに固定して比較するほうが原因を特定しやすくなります。

フェーズ判定は自動である点の理解

opusplanでは、Plan/Executeの切り替えをClaude Code側が自動で判断します。ユーザーが明示的に「ここからExecute」と指定するものではないため、想定と異なるフェーズ判定になる可能性はあります。設計が特に重要なタスクでは、Planフェーズの出力を人間が確認してから実行に進むほうが安全です。

チームで運用に載せるときの注意

個人で使う分にはモデル選択は自由でよいのですが、チームで使うとなると話が変わります。誰がどのモデルでどのタスクを処理したかが記録されていないと、成果物の品質を振り返る材料が残りません。

現実的なのは、プルリクエストのテンプレートに「使用モデル」の記入欄を1つ足しておく程度の軽い仕組みです。入力を必須にしておけば、後から「設計が甘かったタスクはどのモデルで処理されていたか」を確認できます。HubSpotのパイプラインでステージ移行時に必須入力を設けるのと同じ発想で、人の意識ではなく仕組みで記録を残すという考え方です。

自社に合わせた設計が前提

ここまで書いてきた使い分けは、あくまで一般的な整理です。企業様によって最適な形は異なります。既存コードベースの複雑さ、チームの習熟度、扱うシステムの重要度によって、どこに高性能モデルを置くべきかは変わってきます。

コードベースが小さく設計がシンプルな段階であればsonnet中心で十分ですし、複数システムが絡む改修が増えてくればopusplanの価値が出てきます。自社の開発がいまどの段階にあるかを見極めたうえで、判断基準を自分たちの言葉で定義していくことが大切かと思います。

開発の効率化を事業データの活用につなげる

Claude Codeのモデル選択は開発現場の話ですが、当社がこのテーマを扱っているのは、開発の効率化が最終的に事業データの活用につながるからです。ここでは全体像の中での位置づけを整理します。

個別のツール最適化で終わらせない

AI開発ツールの導入が「エンジニアの作業が少し速くなった」で終わってしまうケースは少なくありません。本来は、開発が速くなることで、これまで手が回らなかったデータ連携や社内ツールの整備に着手できるようになるはずです。

私たちがご支援している領域で言えば、HubSpotに蓄積されたコンタクト・取引・顧客のデータを、外部のデータベースやBIツールと連携させて経営判断に使えるようにする、といった取り組みがこれにあたります。opusplanのパターン1で挙げた「HubSpot APIからデータを取得して同期する」という例は、まさにこの文脈の作業です。

一気通貫で捉える

HubSpotの活用では、コンタクトの獲得から取引の管理、顧客化、その後の請求までを一気通貫のフローとして設計することを重視しています。各段階で発生するデータを分断させず、ワークフローで自動化し、ダッシュボードで可視化する。この一元管理・自動化・可視化の3点が揃って初めて、CRMが事業成長のエンジンとして機能します。

開発の効率化は、このフローの隙間を埋める作業を可能にするものです。標準機能だけでは届かない連携や集計を、自前で素早く作れるようになる。AI開発ツールの価値は、単体の生産性ではなく、この全体フローへの寄与で測るべきだと考えています。

まずは小さく検証する

とはいえ、いきなり大きな連携基盤を作る必要はありません。まずは月次でスプレッドシートに手作業でまとめている集計が1つでもあれば、そこを自動化の対象にする。効果が見えたら対象を広げていく。この段階的な進め方が、結果的に定着率を高めます。

AI活用の具体的な取り組みについては、経営データBI支援やコンテンツマーケティング支援のページもご覧ください。

よくある質問

Q1. opusplanはどのようなタスクに向いていますか？

新機能のアーキテクチャ設計と実装、大規模リファクタリング、複雑なバグの原因調査と修正など、「高度な設計判断」と「大量のコード生成」の両方が求められるタスクに向いています。逆に、単純なファイル編集やテスト実行だけであればsonnet単体で十分です。1つのタスクの中に思考と手作業が混在しているかどうかが、判断の目安になります。

Q2. opusplanとplanモード（--mode plan）の違いは何ですか？

opusplanはPlan/Executeフェーズで使用するモデルを自動切り替えするエイリアスで、planモードは読み取り専用で書き込みを一切しないパーミッションモードです。制御している対象が「モデル」と「権限」で異なります。両者は組み合わせて使うことも可能で、まずplanモードで分析させ、確認後にautoモードに切り替えてopusplanで実行するワークフローが構築できます。

Q3. PlanフェーズとExecuteフェーズの切り替えは自動ですか？

自動で切り替わります。Claude Codeが内部的にタスクの分析・設計フェーズと判断した場合はOpusが使用され、実際のコード生成やファイル操作に移行するとSonnetに切り替わります。ユーザーが手動で切り替える必要はなく、/model opusplanを設定するだけで済みます。ただし判定はツール側が行うため、設計が特に重要なタスクではPlanの出力を人間が確認してから進めるほうが安全です。

Q4. opusplanはマルチエージェント開発でも使えますか？

マルチエージェント構成でも有効です。メインエージェント（オーケストレーター）をopusplanに設定すれば、タスク分解や設計判断にはOpusの推論力が使われ、サブエージェントへの指示発行や結果の統合にはSonnetの速度が活かされます。複数エージェントが並列で動作する場合、レートリミットの消費を抑えられる点もメリットになります。

Q5. チーム全体でopusplanに統一すべきでしょうか？

一律に統一するよりも、タスクの種類で使い分けるルールを決めるほうが現実的かと思います。「アーキテクチャ変更を伴う作業はopusplan、既存パターンの複製はsonnet」のように基準を文書化して共有すれば、メンバーごとの判断のばらつきを抑えられます。まずは一部のメンバーが設計タスクで試し、効果が見えたものからルール化していく進め方をおすすめしています。

まとめ

本記事では、Claude Codeの/model opusplanによるハイブリッド戦略を、工程設計の観点から解説しました。要点を整理します。

• opusplanは、Planフェーズに推論力の高いOpus、Executeフェーズに高速・低コストなSonnetを自動で切り替えるハイブリッドエイリアスです
• 本質は「思考と実行の分離」であり、どのモデルが優秀かではなく、どの工程にどのモデルを置くかという設計の問題として捉えることが重要です
• 新機能のアーキテクチャ設計、大規模リファクタリング、複雑なバグ調査など、思考と手作業が混在するタスクで効果が出やすくなります
• 単純なファイル編集や既存パターンの複製ではsonnet単体で十分であり、モデル差の検証をしたい場面ではむしろ単一モデルに固定したほうが原因を切り分けやすくなります
• planモード（--mode plan）とは制御対象が異なる別概念ですが、分析→人間のレビュー→実行という二段階ワークフローとして組み合わせられます

まずは、直近で着手する設計判断を伴うタスクを1つ選び、そこでopusplanを試すところから始めてみてください。次の3ステップで進められます。

1. 対象タスクを1つ決める — アーキテクチャ変更やリファクタリングなど、設計の良し悪しが後工程に影響する作業を選びます
2. /model opusplanで実行し、Planの出力を確認する — 実行に入る前に計画の中身を読み、自社の事情に合っているかを人間が判断します
3. 結果を振り返り、判断基準を文書化する — 手戻りが減ったかを確認し、「どの種類のタスクでopusplanを使うか」をチームのルールとして書き出します

このサイクルを何周か回すと、個人の慣れではなくチームの基準としてモデル選択が定着していきます。

CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお気軽にお問い合わせください。

あわせて読みたい

• Copilot Coworkとは？料金・Claude Coworkとの違い・いつから使えるかを解説
• Claude Code SDK活用ガイド｜Python/TypeScriptからAIエージェントをプログラムで制御する
• Claude Codeの/compactコマンド活用法｜コンテキスト管理で長時間作業の品質を維持する

Claude Codeの全コマンド一覧はClaude Codeチートシートをご覧ください。AI活用の全体像はAI活用完全ガイドで解説しています。