Claude Codeで助言モデルを使う方法

TL;DR

普段の作業はSonnetに任せ、探索や優先順位の見直しが必要な局面だけFable 5へ相談すると、複雑なタスクの性能とコストを両立しやすくなる。簡単な作業ではモデル間のやり取りが割高になるため、タスクの形を見極めて使い分ける。

Transcript

おしまそうです。本日ですね、クロード faイブル5、え、このモデルをですね、 より効率的に使っていくエージェント ハーネスみたいな話でですね、え、 アンソロピックの中の人から、え、ブログ が共有されていましたんで、これについて ね、え、何を言ってるんだっていう話を できたらなという風に思います。え、最近 ですね、ちょこちょこ話題になってるん ですけど、クロードの中でですね、え、 アドバイザー機能みたいなのが登場してい て、ま、これは何かって言うとね、え、 スラッシュアドバイザーみたいな感じで やっていくとはい。え、ま、例えばね、 faイブルとかソネットとかオパスとかね 、え、ま、モデル例えばいつも使ってる モデルがソネットなんだったら、え、 アドバイザーにFブル5みたいな感じで 指定をして、... Read More

Key Insights

• アドバイザー型は、Sonnetを作業主体に据え、難しい判断が発生した局面だけFable 5へ相談することで、高性能モデルの利用範囲を限定する設計である。
• Fable 5の役割は、全体の計画を担うオーケストレーター、途中で助言するアドバイザー、成果を確認するベリファイアの3種類に整理できる。
• 探索的タスクは、途中の結果によって次に試す内容や優先順位が変わるため、最初の計画だけでなく実行中にも高性能モデルの判断を挟む価値がある。
• 決定的タスクは、実施事項が初めから明確であるため、高性能モデルが序盤に計画し、その後をSonnetへ委任する構成が適する場合がある。
• Sonnet 5は、話者の説明では些細な改善に固執して局所的な山登りを続けやすく、視点を引いて優先順位を組み直す傾向が弱いとされる。
• 助言役を使った実験では90％の性能を34％のコストで達成したと紹介されたが、動画内ではベンチマークの詳しい条件や再現手順まで示されていない。
• 簡単なタスクは、複数モデル間のトークン交換や呼び出し自体が追加負担となり、Fable 5単独やSonnet単独より割高になる可能性がある。
• モデル選定は、必要な知能やセンス、探索性、作業量、トークン効率を判断基準としてハーネス側に与え、役割ごとに委任先を変える方法が示されている。
• 🎬 このチャンネルの他の動画:
  • Claude Codeサブエージェントの使い方
  • Grok BuildでClaude資産を使う方法
  • Claude自動化制限後の移行先を選ぶ方法
• 📺 このチャンネル: まさおAIじっくり解説ch

Questions & Answers

Q: Claude Codeでアドバイザー機能を使う方法は？

普段の作業モデルをSonnetなどに設定し、難しい局面でアドバイザーとしてFable 5やOpusへ意見を求めます。動画内の例では、Sonnetで進めている作業の途中にアドバイザーを呼び出し、その助言を受けて作業を継続しています。具体的なコマンド構文の詳細までは示されていません。

Q: アドバイザー型が適しているタスクとは何ですか？

アドバイザー型は、途中の結果によって次に試す内容が変わる探索的タスクに適しています。最初に完全な計画を固定しにくい仕事では、行き詰まりや方針転換の局面で高性能モデルへ相談することで、優先順位を見直しながら作業を進められます。

Q: オーケストレーター型とアドバイザー型の違いは何ですか？

オーケストレーター型は高性能モデルが主に序盤で計画や作業配分を決め、アドバイザー型は作業の途中でも必要に応じて助言を加えます。実施事項が明確なら前者、試行結果に応じて方針が変わるなら後者が適する場合がある、という使い分けが示されています。

Q: Fable 5にはどの役割を任せるべきですか？

Fable 5には、計画を組み立てるオーケストレーター、作業途中の難所で意見を出すアドバイザー、結果を検証するベリファイアという3つの役割を任せられます。どれを選ぶかは、判断が必要になる時点と、タスクが探索的か決定的かによって変わります。

Q: なぜSonnetだけで探索的タスクを進めないのですか？

話者によれば、Sonnet 5は小さな改善に固執して局所的な山登りを続けやすく、全体を見直して優先順位を組み替える傾向が弱いからです。そのため、作業の途中でより高い判断力が必要になった局面にFable 5の助言を挟む構成が提案されています。

Q: アドバイザー型でコストを下げる方法は？

高性能モデルを全工程で動かさず、通常の作業をSonnetへ任せ、行き詰まりや検証など必要な局面だけFable 5へ相談します。ただし、モデル間のやり取りにもトークンが必要なため、簡単な作業には使わず、複雑で探索的なタスクへ限定することが重要です。

Q: 90％の性能を34％のコストで実現できるのですか？

動画では、アドバイザー型の実験で90％の性能を34％のコストで達成した例が紹介されています。ただし、評価対象、測定方法、比較条件、再現手順の詳細は動画内で説明されていません。この数値は紹介された実験結果として扱い、すべてのタスクに当てはまるとは判断できません。

Q: マルチエージェント構成を避けるべき場合は？

簡単で手順が明確なタスクでは、マルチエージェント構成を避ける選択肢があります。複数モデルを使うと、モデル間のトークン交換や追加の呼び出しによってコストが増えるためです。高性能モデルが短時間で単独処理できる仕事では、分担による節約効果が得にくいと説明されています。

Summary & Key Takeaways

• アドバイザー型は、Sonnetなどの普段使いのモデルを主な作業者とし、途中で行き詰まったときや高度な判断が必要になったときだけFable 5などへ相談する構成である。高性能モデルを全工程に使わず、必要な局面へ知能を投入できる点が特徴で、話者は助言役のほか、計画役や検証役としての利用も挙げている。

• 設計方式はタスクの性質で選ぶ。実行内容が初めから明確な決定的タスクや、重要なレビューが序盤に集中する仕事では、高性能モデルが最初に計画し、その後をSonnetが処理するオーケストレーター型が適する場合がある。一方、試行結果によって次の行動が変わる探索的タスクでは、作業途中で助言を受けられるアドバイザー型が有効になる。

• コスト面では、高性能モデルとの相談やモデル間のトークン交換が追加負担になるため、簡単なタスクではアドバイザー型やマルチエージェント構成が割高になり得る。話者が紹介したベンチマークでは、複雑なタスクにおいて90％の性能を34％のコストで達成した例が示されたが、評価条件の詳細は動画内で提示されておらず、一般化には注意が必要である。