高性能AIモデルの価値は、モデル自体の知能だけでなく、その思考手順や検証方法を再利用可能な仕組みに落とし込むことにある。Fable 5の判断、計画、反証、検証の習慣をスキル化してOpusなどへ移植し、さらにタスクに応じて安価なモデルへ処理を委譲することで、品質を維持しながらコストを大幅に削減する方法を解説する。所有できないモデルではなく、プロセス、システム、方法論を資産として蓄積する重要性を説く内容である。
モデルの知能よりも重要なもの
私たち全員がFable 5を使えるようになってから、私は利用クレジットに数千ドルを費やして、ひたすら試しながら、どう動くのか、そしてそれ以上に重要なこととして、これほど強力なモデルから私たち人間がどうすれば最大限の価値を引き出せるのかを理解しようとしてきました。
そこで得た最も重要な気づきの一つは、確かにFable 5は信じられないほど優れたモデルですし、そこを誤解してほしくはないのですが、本当の堀、つまり競争優位性の源泉は、モデルそのものではないということです。
こう考えてみてください。AI初心者と、たとえばアンドレイ・カーパシーのような人がいるとします。初心者にFable 5を渡し、カーパシーにはSonnet 3.7を渡したとしても、初心者が使っているモデルのほうが指数関数的に優れているにもかかわらず、カーパシーのほうが優れたものを作るでしょう。
なぜなら、モデルにどう指示するか、どんなシステムを構築するか、そしてモデルの周囲にどんなループを作るかのほうが、はるかに重要だからです。
もう一つ考えてほしい例があります。私は当然Fable 5をかなり試してきました。それと同じように、OpusもSonnetも大量に試しています。最近特に気に入っているのが、Claude Codeで立ち上げられる動的ワークフローを使うことです。
私はこれまで何度も動的ワークフローを試してきました。たとえばFableに、ワークフローを設計して、その中の小さなサブエージェントも全部Fableにしてくれ、と指示します。
そしてまったく同じテストを、Fableが複数のOpusサブエージェントをオーケストレーションする構成や、Fableが複数のSonnetエージェントをオーケストレーションする構成でも行いました。
そこで分かったのは、こうした動的ワークフローを実行すると、結果はほぼ同じだということです。Fableだけで実行した場合は、コストが指数関数的に高かったにもかかわらずです。
要するに、私が言いたいのはこういうことです。モデルの知能そのものを手元に残すことはできませんが、そのモデルのプロセスは残せます。
今日は、Opusのようなモデルを、どうすればもっとFableのように感じられるものへ変えられるのかを、手短に話していきます。
Fableを作業員ではなく教師として使う
まず最初に、このモデルを単なる作業員ではなく、教師のように考える必要があります。
私たちがFableを使えるようになったとき、おそらく全員が、ひたすらその限界まで働かせようとしていました。Anthropicも、長時間のタスクが非常に得意だという内容を公開していました。目標に向かって進み、計画を立て、実行し、その後に検証するような仕事です。
実際、それは本当に得意です。
ですが、モデルルーティングという考え方の本質は、バランスを見つけることです。このタスクにはこの程度の知能が必要だ、と考えるわけです。
もっと小さく安価なモデルを使っても同じ品質で仕事を完了できるのに、なぜそれよりはるかに高い知能を持ち、これほど高額なモデルを使う必要があるのでしょうか。
結局、ゲームの本質はそこにあります。そして今後数年のAI時代に進んでいく中で、これは非常に重要な習得すべきスキルになるでしょう。
ですから、Fableにすべてを計画させ、すべてを実行させるのではありません。Fableがどのように考えるのかを抽出し、もっと小さなモデルにも同じような考え方をさせ、同じような方法で実行させようとしているのです。
私はFableに自分の環境構成を確認させて改善してもらったり、自分のスキルファイルを確認させて改善してもらったりしてきました。
そこで気づいたのですが、私はFableを単なる従業員ではなく、共同創業者、あるいは会社の役員のように扱っていたのです。
もうすぐ退職するシニアエンジニアが、自分の知っていることをすべて整理してパッケージ化し、これから入ってきて自分の役割を引き継ぐ若手エンジニアの新しい世代へ渡そうとしているようなものです。
システムプロンプトから学べる思考習慣
最近起きたことの一つとして、Claude Fable 5のシステムプロンプトが流出しました。そこで私は最初から最後まで全部読みました。さらにFable 5自身にも全体を読ませ、このプロンプトから読み取れる重要な点をいくつか拾い出しました。
訓練時の記憶に部分的に見覚えがあるからといって、それが現在の知識であるとは限らない、という考え方があります。つまり、何かが記憶の中にあるからといって、それをそのまま信じるのではなく、おそらく検証すべきだということです。
これと非常によく似た指示として、プロンプトがファイルの存在を示唆していても、実際にそのファイルが存在するとは限らない、というものもあります。
つまり、本当に存在するのかを確認するよう指示されているのです。要するに、プロセスのあらゆる段階で、自分がやっていること、そしてすでに行ったことが正確なのかを確認するわけです。
曖昧な質問であっても、確認を求める前にまず対応する、という指示もあります。つまり、最初に答え、その後に質問するとしても最大一つまでです。
何が問題だったのかを認め、問題そのものに集中し続け、自尊心を保つ、という内容もあります。
単純な事実確認なら1、一般的な中程度のタスクなら3から5、より深い調査や比較なら5から10です。
これは基本的に、どれだけの努力量を使うかという話です。
つまり、どのモデルがそのタスクに適しているかという議論だけではありません。そのタスクにはどの程度の努力レベルが適切なのか、という議論も必要なのです。
モデルと努力レベルの最適な組み合わせ
私が参考にするのが、Claude Fable 5とMythos 5のリリースブログに掲載されていたこの例です。
ここではFable 5、Opus 4.8、そしてGPT 5.5を比較しています。Y軸がスコア、X軸がコストで、それぞれのモデルについて異なる努力レベルが示されています。
ですから、Fable 5を有効にして、ずっとデフォルトの努力レベルだけで使っている人や、Opusでも同じように努力レベルを一度も変更したことがない人は、ぜひいろいろ試してみてください。かなり興味深い結果になります。
たとえばここを見ると、Fable 5のlowは、Opus 4.8のhighとかなり近いことが分かります。
この図で分かるように、Fable 5のほうが少し高価で、品質も少し高いのですが、かなり近い位置にいます。
ただし、努力レベルを高くすれば必ず良くなるというわけでもありません。
私はFableを使うとき、多くの場合は基本的にhighにしています。なぜなら、さらに上のmaxを使うと、Opusでも同じなのですが、処理時間がはるかに長くなり、コストも大幅に増え、考えすぎるようになるからです。
その結果、自分の判断を何度も疑い始めて、最終的にはOpus 4.8のhighやFableのhighをそのまま使った場合よりも悪いものを出してしまうことがあります。
Fableの方法を抽出してスキル化する
いずれにしても、システムプロンプトを読み、長い間これらのモデルを使い続けてきた結果、皆さんにやってほしいことが二つあります。
一つ目は、これまでFableをどのように使ってきたのか、その使い方やハーネスと呼べるものを、OpusやSonnetでも実行できる形に変えることです。
つまり、Fableの方法論を抽出するのです。
ここで一つおすすめしたいことがあります。Fableから受け取った成果物の中に、ものすごく気に入ったけれど、なぜそれほど良いと感じたのか自分ではうまく説明できないものがあったなら、それをFable自身かOpusに分析させてください。
そのときのセッションまで振り返れるなら、さらに良いです。
ここにたどり着くために何を考えたのか。どうやってここまで到達したのか。それが機能することを証明するために何をしたのか。なぜこれほど優れた出力を生み出せたのか。
そうした情報を抽出して、スキルに変えるのです。
私は今、Fable modeというスキルを持っています。
OpusにFable modeを使わせたいときや、非常に難しい問題が目の前にあるとき、Opus 4.8にFable modeを組み合わせて使っていますが、かなり良い感触です。
Fableのプロンプトのようなものが注入されているため、モデルの能力が少し引き上げられたように感じるのです。
5つのゲートで思考プロセスを再現する
この方法は5つのゲートで動きます。
スコーピング、証拠、攻撃的検討、検証、そして報告です。
これは、目標プロンプトを設定して動的ワークフローを使い、基本的にループを組む方法とかなり似ていますが、それをスキルファイルとしても実装しているわけです。
スコーピング、そして一般に計画と呼ばれるものについて、非常に重要なことがあります。
単に、これが全ステップです、これを計画して実行してください、と進めることと、悪魔の代弁者として考えることの間には大きな違いがあります。
つまり、起こり得る問題をすべて考えたらどうなるか、この計画に含まれている未知の要素をすべて調査したらどうなるか、と考えることです。
そして、Fableはこれを非常に得意としています。
だからこそ、私がFableに、ある最終目標を達成するための動的ワークフローを立ち上げさせると効果があります。
Fableが考えられるすべてのステップを計画し、起こり得るあらゆる問題を検討したうえで、Sonnetが実作業をすべて担当できるように動的ワークフローを設計します。
Sonnetは作業結果をFableに報告し、すべてをFableへ送り返し続けます。するとFableは、そのプロセスの次のステップを継続的に設計できます。
だからこそ、FableとSonnetで動的ワークフローを実行したときの結果が、FableとFableで実行した場合とかなり似ているのです。
これは私にとって、本当に大きなひらめきの瞬間でした。なぜ同じくらい良いのに、コストは大幅に安いのだろう、と思ったのです。
Fable modeの作り方
まず、次のような指示から始められます。
Opus 4.8が、あなたの判断力、計画、検証、推論の習慣に従って動作する、完全でインストール可能なスキルファイルを作成し、Fable modeのような名称で起動できるようにしてください。
たとえば、ここに私のFable modeスキルがあります。これは無料のSchoolコミュニティに完全無料で添付しておきます。リンクは説明欄にあります。
そこに参加して、classroomへ移動し、all YouTube resourcesをクリックしてください。私がこれまでYouTubeで無料公開したものは、すべてそこから見つけられます。
Fable modeスキルもそこで入手できますが、もちろん自分で作ることもできます。
ここを見ると分かるように、Fableの仕事上の規律を、あらゆるモデルが実行できる形で順に定義しています。
つまり、望むならGPT 5.5にこれを実行させることもできますし、オープンソースモデルに実行させることもできます。
基本的には、先ほどの5つのゲートを順番に通ります。
作業前のスコーピングを行い、そこから詳細に入ります。推論より先に証拠を確認し、敵対的な視点から推論し、完了を宣言する前に検証し、最後にキャリブレーションを行います。
さらに、常に守るべき習慣や、確認すべきいくつかの項目もあります。
先ほど言ったように、興味があればこのファイルの中身を確認できますが、これをOpus 4.8に与えると、先ほども言ったように、Opusの能力が少し底上げされたように感じられます。
これは非常に役立つ戦略でした。
モデルルーティングで知能とコストを最適化する
そして、この方法と非常に相性が良いのが、もう一度言いますが、モデルルーティングという考え方です。
Fableのような賢いモデルが、必要に応じて小さなモデルへどう処理を振り分けるかを考えるのです。
最近私がやっていることの一つは、Claudeに、ツールキット内にあるさまざまなモデルと、それぞれをいつ使うべきかをまとめた表を渡すことです。
Codexに委任させることもできますし、オープンソースモデルへ委任させることもできます。
先ほども言ったように、企業がユニットエコノミクスについて考え始めると、これは非常に大きなテーマになります。
小さなチームでも同じですし、個人でも、毎月のAI予算を決めている人がいるかもしれません。
こういう工夫が、はるかに少ない費用で、はるかに多くの成果を得られる人と、そうでない人を分けていくことになります。
分け方としては、まず、これが私たちのツールキットに入っているモデルです、それぞれのコストはこれくらいです、と整理すると良いです。
たとえばコストスコアは、数字が高いほど良い、つまり安いという意味にできます。
そして、知能とセンスという評価軸を加えます。
自分のワークフローに応じて別のカテゴリーを追加したければ、自由に追加してください。
知能とは、どれくらい賢いと感じるか、自分の意図をどれくらい理解してくれるか、コードレビューなどがどれくらい得意か、といったことです。
一方、センスというのは、私の中ではもっと、創造性、型にはまらない発想、UIやUXのデザインといった能力を意味しています。
エージェントチームをモデルごとに役割分担する
こうした評価は、エージェントチームを設計するとき、サブエージェントに仕事を委任するとき、そして動的ワークフローを立ち上げるときに非常に役立ちます。
動的ワークフローの中では、複数のSonnet、複数のHaiku、さらにOpusまで組み合わせて使えるからです。
ここに、私が実際に行ったテストの例があります。
私はOpusをオーケストレーターとして使い、先ほど話したプロンプトを与えました。
あれ、どこだったかな。そう、Fable modeプロンプトのようなものです。
そのOpusに、複数のSonnetワーカー、Opusワーカー、Haikuワーカーを使わせました。それぞれ別々に、3種類のテストを行いました。
その中で、OpusオーケストレーターがすべてのHaikuスカウトへ仕事を委任した構成は、これほど安くなりました。だいたい3分の1のコストです。
そして結果はまったく同じでした。
ですから、先ほどのFableの例と同じように、これは本当に真剣に考える価値があることです。
所有すべきなのはモデルではなくプロセス
今回は短い内容でしたし、実際に短くしたかったのですが、最近コメント欄やコミュニティで非常に多くの人が、Fableが使えなくなることについて質問したり、不安になったりしているのを見てきました。
Fableはサブスクリプションに戻ってくる予定です。少なくともAnthropicはそう言っています。
いつ戻るかは分かりませんが、戻ってくる予定です。
ただ、政府が関与したり、モデルが使えなくなったりする一連の出来事を見ていると、私たちは何も所有していないのだという事実を強く考えさせられます。
私たちは、こうしたモデルを所有していません。
だからこそ、私たちが所有できるものは、自分たちのプロセス、システム、方法論、そしてこれらのモデルをどう使うかという考え方です。
さらに、ハードウェアを所有することもできますし、ローカルモデルを所有することもできます。
ですから私は、今後この種のテーマをもっと深く掘り下げていくつもりです。
こういったテーマについて、どんな内容を見たいか、ぜひ教えてください。
それでは、何か新しいことを学べた、あるいは動画を楽しめたという方は、ぜひ高評価をお願いします。本当に大きな助けになります。
そしていつものように、最後まで動画を見てくださった皆さんに感謝します。また次の動画でお会いしましょう。
皆さん、ありがとうございました。
コメント