00:00:00Claudeのモデルは単体では不十分です。Opusは推論力に優れていますが
00:00:04制限をすぐに使い果たします。Sonnetは高速ですが、難易度の高い判断で壁に突き当たります。
00:00:10解決策はどちらかを選ぶことではなく、すべてを組み合わせて使うことです。
00:00:14Claude Codeはすでにある程度これを行っており、自律的にモデルを調整します。
00:00:18しかしAnthropicは、トークンを節約しつつ、小型モデルを大型並みに
00:00:23有能にする手法をリリースしました。Claudeで開発している際、気づいたかもしれません。
00:00:28Opusにタスクを渡して、それほど労力を必要としないと判断されると
00:00:32SonnetやHaikuにタスクを委譲し、トークン使用量を管理しようとします。
00:00:37しかし、このアプローチには問題があります。前回の動画で触れたように
00:00:42Anthropicは制限を厳しくしており、ピーク時には5時間の枠がすぐに埋まります。
00:00:47さらにOpusは単純なタスクでも多くのトークンを消費し、コンテキスト上限にすぐ達します。
00:00:52そこでAnthropicはこの状況を逆転させる「アドバイザー戦略」を打ち出しました。
00:00:55この戦略では、Sonnetモデルに「実行者」の役割を与え
00:01:00Opusを純粋に、実行者が本当に必要とした時だけ相談を受ける「アドバイザー」として使います。
00:01:052つのエージェントが登場します。実行者はSonnetで動くメインエージェントで
00:01:10ツール呼び出し、コード変更、ユーザー出力を担当します。アドバイザーはOpusで動き
00:01:15実行者が行き詰まった時に導くのが唯一の仕事です。コードを書いたり変更したりはしません。
00:01:20Anthropicが実験したところ、この手法はSWE-benchにおいて
00:01:25Sonnet単体よりも性能とコストの両面で上回ることが分かりました。
00:01:31Opusをメインにするより大幅に安く済みます。なぜならOpusは
00:01:36全工程ではなく、本当に重要な時だけ呼び出されるからです。
00:01:40「すでに優れたフレームワークがあるのに、なぜこれが必要なのか」と思うかもしれません。
00:01:45その理由は、既存のフレームワークの多くがコストや効率を重視していないからです。
00:01:50それらは目的を果たせますが、Claudeをより長く、効率的に動かす点では劣ります。
00:01:54トークン使用量の最適化よりも、アプリ構築そのものに焦点を当てているからです。
00:01:59この構成なら、非力なモデルで実用的なアプリを構築でき、プロセス全体を
00:02:04はるかに効率化できます。これが先ほどの制限問題につながります。
00:02:09以前の動画で、利用枠を維持するために小型モデルへの切り替えを勧めましたが
00:02:13ここでリンクします。Sonnetは消費トークンが非常に少なく、労力も抑えられます。
00:02:19Opusは非常に巨大で強力なため、単純なタスクでも大量のトークンを消費しますが
00:02:24Sonnetはそれらをより効率的に処理できます。そのため、難しい判断が必要な
00:02:30性能のギャップを埋める時だけOpusを使うことに、真のインパクトがあります。
00:02:35必要な時だけその力を借りることで、全体のトークン効率が向上し
00:02:40同じ制限内でより多くの作業が可能になります。このチャンネルではAI製品開発の
00:02:45知見を共有しているので、興味があればぜひ登録して今後の動画をチェックしてください。
00:02:50では、Sonnetで構築済みのアプリで実際にどう機能するかテストしてみましょう。
00:02:55Claude Code内でこの戦略を使うには、アドバイザーコマンドで
00:03:00Opus 4.6をアドバイザーに設定します。実行者（メイン）は元々Sonnetにしてありました。
00:03:05このアプリはリアルタイム同期機能を持つはずで、要素の移動やサイズ変更は
00:03:10同期されましたが、削除が全く同期されませんでした。Sonnet単体で何度も
00:03:16デバッグを試みましたが、どれだけ修正を試みても問題は解決しませんでした。
00:03:20そこでOpusをアドバイザーとして起動し、Claudeに問題を説明するプロンプトを送ると
00:03:25Sonnetはすでに何度も失敗していたため、自力で再試行する代わりに
00:03:30今回はアドバイザーを呼び出しました。アドバイザーはこれまでの会話をレビューし
00:03:34状況を把握しました。そして修正すべき箇所、同期ロジックが壊れている場所
00:03:40具体的にどう再構築すべきかを提示しました。実行者モデルはその助言を取り入れ
00:03:45追加のやり取りなしに直接修正を適用しました。複数のデバイスで
00:03:50同期をテストしたところ、問題は解決していました。削除操作が正しく反映され
00:03:55一方の端で選択中でも、もう一方で削除されると正常に動作するようになりました。
00:04:00もしこれをSonnet単体で直そうとしていたら、何度もやり取りが必要だったでしょう。
00:04:05Sonnetは本来それほど強力ではなく、複雑なロジックを自力で扱うには限界があるからです。
00:04:09一方でOpus単体なら、はるかに多くのトークンを消費し、速度もこれほど出なかったはずです。
00:04:15SonnetにOpusをアドバイザーとして添えることで、プロセスが格段に効率化されました。
00:04:20結果として、この戦略により同期問題のデバッグが以前よりずっと速くなりました。
00:04:25次に進む前に、スポンサーのJetBrainsによるJuniについてお話しさせてください。
00:04:30開発者なら、ターミナル、IDE、CIパイプライン間での文脈の切り替えに苦労するはずです。
00:04:36多くのコーディングエージェントは環境や特定のLLMに依存しがちですが
00:04:41Juni CLIは違います。LLMに依存せず、どこでも動作するエージェントです。
00:04:47ターミナル、IDE、GitHub、CI/CD、タスクマネージャーまで。一つのエージェントで完結します。
00:04:54テスト作成、バックエンド構築、リファクタ、コミットごとのコードレビュー自動化も可能です。
00:04:59現在JetBrainsは無料の早期アクセスプログラムを実施中で、50ドルのGeminiクレジット付きで
00:05:04試用でき、BYOKサポートで好みのモデルも使えます。全機能へのアクセスや
00:05:10開発チームの直接サポートも受けられます。Juniを使えば開発はもっと快適になります。
00:05:15固定コメントのリンクから無料で参加できます。さて、次にSonnetが大きなUI変更でも
00:05:20アドバイザーに相談するかテストしました。既存のアプリのUIを
00:05:25別のライブラリに移行しようと試みました。さらに一度に複数の変更を加えるという
00:05:31通常は推奨されない方法で、大規模タスクにおける連携を検証しました。
00:05:36まずPlaywright MCPを使用して現在のUIを把握しました。
00:05:41レイアウトを理解すると、すぐにコードを書くのではなく、まずアドバイザーに相談し
00:05:46最善のアプローチを判断しました。重大な変更であり、誤るとアプリを壊す可能性があるからです。
00:05:50アドバイザーは、選んだ新しいライブラリと既存のプロジェクトの間で
00:05:55バージョンの競合があることを指摘しました。UI作業の前に、Claudeはまず
00:06:00これらを解決する必要がありました。Sonnetはまずそれに対処し、コマンドを実行して
00:06:04依存関係を適用し、Playwrightでアプリが正常に動いているか再度確認しました。
00:06:09準備が整うと、アドバイザーの提案通りに各コンポーネントを一つずつ修正し
00:06:14アプリ全体を効果的に再設計し始めました。
00:06:18完成したUIはよりインタラクティブで、以前よりもずっと洗練されたものになりました。
00:06:23まだ課題はありましたが、明らかな改善が見られました。しかしここで限界も露呈しました。
00:06:27全工程に約31分かかりました。Opus単体ならもっと速かったでしょう。
00:06:32並列実行可能なタスクを特定し、同時に処理するオーケストレーション能力に優れているからです。
00:06:37小型モデルのSonnetは、並列処理を行わずにすべてを順次処理しました。
00:06:43それほど複雑でないアプリに31分かかるのは、本来より長すぎます。
00:06:48軽微な修正ならアドバイザー抜きで自律的にこなせますが、これは正しい動作です。
00:06:53しかし、アプリ全体に及ぶような大規模な変更を行う場合は
00:06:58最初からOpusを直接使ったほうが、時間と労力を大幅に節約できるでしょう。
00:07:03次に、既存のコードベースに全く新しい機能を正しく実装できるかテストしました。
00:07:08既存のアプリに、別の機能を持つ新しいページを追加しようとしました。
00:07:13やりたいことを説明するプロンプトを与えた際、単純なタスクではないため
00:07:17アドバイザーを使うと予想していましたが、Sonnetはアドバイザーに相談せず
00:07:22自力で変更を実装し始めました。機能の規模を考えればそうではないはずですが
00:07:27通常のルーチンワークとして処理してしまったのです。実際にアプリをテストすると
00:07:31複数の問題が見つかりました。何かを修正して実行ボタンを押すと
00:07:37見出しの更新や色の変更が、プレビュー外のコンポーネントにも反映されてしまいました。
00:07:41さらに、変更のたびに実行ボタンを押すのではなく、直接同期させたいと考えました。
00:07:46そこで再度プロンプトを送り、アドバイザーを使って修正するよう指示しました。
00:07:51指示を受けると、まずアドバイザーを呼び出しました。アドバイザーは
00:07:56実装を確認し、両方の問題の原因を特定しました。それは
00:08:00コンポーネントの選択ミスでした。何を変えるべきか、なぜ元の方法が
00:08:06問題を引き起こしたのかを提示しました。実行者はその指導に従い、アプリに適用しました。
00:08:10再テストするとストリーミングが正しく機能し、編集が即座に反映されるようになりました。
00:08:16実行ボタンを押す必要もありません。他のコンポーネントへの影響という問題も
00:08:20解決され、すべてが適切な境界内で更新されるようになりました。
00:08:25意図通りに動く時もありますが、実行者がタスクを過小評価して
00:08:30相談を怠ることもあります。その場合は、ワークフローに従うよう促す必要があります。
00:08:35モデルは常に人間と同じように複雑さを判断できるわけではありません。判断を誤ると
00:08:40アドバイザーなら最初から防げたはずのバグが発生してしまいます。
00:08:44もし内容を気に入っていただけたら、高評価ボタンをお願いします。励みになります。
00:08:49分散状態のリアルタイム処理などが絡むと、このアプローチでも
00:08:54すべてが正常に動くまでに何度かやり取りが必要でした。
00:08:58戦略としては有効ですが、プロジェクトに導入する前に限界を理解しておくべきです。
00:09:02初級から中級規模のアプリであれば、アドバイザー戦略を使うことで
00:09:07Sonnetの限界を自力で突破させようと無駄に繰り返す手間を省けます。
00:09:11時々深い思考が必要になる程度で、大半が単純な実装なら
00:09:16これは非常に優れた構造です。モデルの判断を逐一監視したり
00:09:20Opusに頼りきりになったりせずに、トークン制限内でより多くの開発ができます。
00:09:25依存関係が多く複雑なアプリや、失敗箇所が複数ある場合は
00:09:30最初からOpusをメインに使うべきです。Sonnetが助言に正しく従ったとしても
00:09:36推論の深さが足りないため、誤った実装パスを選んでしまうことがあります。
00:09:40複数のアプローチを評価し、後々の影響を天秤にかけることが難しいのです。
00:09:45アドバイザーはその差を埋めてくれますが、完全ではありません。
00:09:50そうしたケースでは、最初からOpusを動かすより時間がかかることもあります。
00:09:54つまり、トークン制限が厳しく、常にOpus級の推論が必要でない場合に有効です。
00:09:58その両方の条件が満たされているなら、試してみる価値は十分にあります。
00:10:03今回の動画は以上です。もしチャンネルを応援していただけるなら
00:10:08下のスーパーサンクスボタンからお願いします。ご視聴ありがとうございました。
00:10:12また次の動画でお会いしましょう。