- Fable 5は、曖昧な指示から「それっぽい」出力を作る力がかなり高いです。
ただ、その賢さは、細かい約束を守り続ける力とは別物です。 - 少ない入力から大量の出力が返ってくることは、生成AIの大きな魅力です。
でも、外側に正解がたくさんある作業では、その出力の多さがそのまま負担にもなります。 - 小さなゲームデモが一発で動くことと、商品として成立するゲームを作ることの間には大きな距離があります。
その距離を、私は「Vibesの谷」と呼んでいます。 - Fable 5は、コーディング向けの万能モデルとして見るより、言語や意味を扱うモデルとして見る方が得るものがあります。
言葉の厚みがあるぶん、間違ったときにも説得力が出てしまうのが厄介です。
1. Fableは賢いが、約束を守る賢さとは違う
最近、Fable 5を使ってLPを作ったり、コードを書かせたりしています。
最初はかなり驚きました。
こちらの曖昧な言葉から、ちゃんと形のあるものが出てくる。
ただ、何度か使っていると、少し違う感触も出てきました。
これは魔法の道具というより、ものすごく弁の立つ作業者なのではないか。
賢いのに、変なところで約束を守ってくれない。
LPを作らせたときには、まさかの15年前の情報商材っぽいページが出てきました。
強い見出し。
過剰な煽り。
限定感と実績風の演出。
意図はわかります。
「売れるLP」と聞いたときに、過去の成功パターンを拾ってきたのでしょう。
でも、こちらが欲しかったのは、いまの空気に合った信頼感のあるページでした。
1.1. 新規リポジトリで「既存ユーザー」を心配された
もっと引っかかったのは、コードを書かせていたときです。
1時間前に作ったばかりの新規リポジトリで、言語移植をしようとしていました。
すると、Fableは「既存ユーザーへの影響が大きいので避けるべきです」と止めてきた。
もちろん、言語移植にはリスクがあります。
既存ユーザーがいるサービスなら、互換性や移行コストを考えないといけません。
それは正しい一般論です。
でも、この場合は新規リポジトリでした。
ユーザーはまだいない。
既存ユーザーへの影響という論点が、そもそもまだ立ち上がっていない。
ここで見えたのは、「言語移植は危険」という一般論が、目の前の文脈よりも強く働いてしまう姿でした。
賢く慎重に見える。
でも、今回の条件を見ていない。
1.2. メタ認知ではなく、メタ認知的な振る舞いを見る
Fableの良さとして、メタ認知が高いと言われることがあります。
メタ認知（metacognition：メタコグニション）は、自分の考え方を自分で見直す働きのことです。
ただ、LLM（Large Language Model：ラージランゲージモデル）に人間のような内省があるわけではありません。
私たちが見ているのは、メタ認知そのものではなく、メタ認知的な振る舞いです。
不確実なことを断定しない。
前提を確認する。
自分の判断の弱さを言葉にする。
この振る舞いは、カスタム指示でもかなり作れます。
「一般論と今回の事情を分けてください」と書けば、多くのモデルはそれっぽく分けてくれる。
「不明点は不明点として扱ってください」と言えば、それらしい顔をします。
でも、負荷がかかったときに差が出ます。
長い指示。
途中で変わる前提。
細かい禁止事項。
ここで一般論に戻ってしまうなら、それはメタ認知というより、うまく装った反射に近い1。
2. 曖昧な指示は、代表解を呼び出す
Fableが騒がれたとき、「ゲームを作って」と頼むだけで動くゲームが出てくる、という話がたくさん流れてきました。
それは本当にすごいです。
少し前なら冗談みたいな話でした。
ただ、同じように試してみると、参考にした投稿とかなり似たゲームが出てくることがあります。
ここで少し冷める。
「ああ、そういうことか」と思う。
Fableは、曖昧な指示に対して、独自に目的を掘り当てているというより、多くの人が納得しやすい代表解を出しているのかもしれません。
代表解というのは、ある状況で「たぶんこういうものが期待されている」と見なされやすい答えです。
みんなが見て「おお」と言いやすい形。
これは弱さだけではありません。
むしろ、かなり強い。
曖昧な入力から、期待されそうな完成形に一気に寄せる能力です。
2.1. 「それっぽい」は、かなり強い
Fableの強さは、言葉の扱いにあります。
感情の輪郭を拾う。
思想の差分を言い換える。
曖昧な不満を、筋の通った批評に変える。
哲学対話のようなことをすると、この強さがよく出ます。
人間がまだ言葉にできていない違和感を、きれいな文章にして返してくる。
かなり気持ちいい。
ここでいう意味理解は、semantic understanding（セマンティックアンダースタンディング）です。
単語の表面ではなく、文章全体が持つ意図や含みを読む力のことです。
Fableはこの部分が強い。
ただ、言葉がうまいことと、現実の正しさに合っていることは違います。
表現力があるモデルは、間違っているときにも説得力が出てしまう。
ここが厄介なところ。
2.2. シンプルな指示で賢く見える理由
Fableは、シンプルな指示を出すと賢く見えます。
「ゲームを作って」
「LPを作って」
「この考えを深めて」
入力が短いほど、Fableが補える余白が増えます。
余白が多いほど、Fableは自分の得意な代表解を出せる。
だから映える。
逆に、長い計画書や細かいルールを守らせると、急に苦しくなります。
「ここは変えないで」
「この仕様に合わせて」
「この禁止事項を守って」
これが積み重なると、勝手な補完が邪魔になります。
指示追従性（instruction following：インストラクションフォローイング）は、与えられた条件や手順を守る力です。
Fableは賢く解釈しようとして、守るべき制約を上書きすることがあります2。
それを温和な言葉でやるので、余計に見抜きにくい。
3. 入出力比が高いほど、Vibesの谷が深くなる
生成AIの魅力は、入出力比が高いことです。
少ない入力から、大量の出力が得られる。
画像も、文章も、音楽も、動画も、コードも。
でも、その出力は過去の完成物らしさから導かれた、妥当そうな出力です3。
外にある正解へ、自動で接続されているわけではありません。
ここを忘れると、すぐ詰んだ感じになる。
たとえば、ゲームです。
「オセロとステルスを組み合わせたゲームを作って」と投げると、本当に動くものが返ってくる。
これは素直にすごい。
でも、ゲーム開発で必要なのは、動くことだけではありません。
操作して面白いこと。
何度も遊べること。
ストアに出しても恥ずかしくないこと。
3.1. デモはできるが、商品にはならない
小さなWebゲームのデモは、正解の固定が弱いです。
多少ルールが変でも、多少UIが雑でも、「こういうもの」として見られる。
動けば驚きになる。
商品としてのゲームは違います。
プレイヤーは容赦なく触ります。
つまらなければ閉じる。
わかりにくければ離れる。
「一発で動いた」は、開発の終点ではありません。
むしろ入口です。
そこから調整が始まります。
難易度を直す。
操作感を直す。
演出を直す。
直した結果、別の場所が壊れる。
3.2. ゲーム開発は、外にある正解が多すぎる
ゲームは、コードとアセットがランタイムで交錯します。
ランタイム（runtime：ランタイム）は、プログラムが実際に動いている時間や環境のことです4。
紙の上で正しく見える仕様も、動かしてみると面白くないことがあります。
UIが正しい。
入力が正しい。
テンポが正しい。
音が正しい。
それらを束ねた先に、ようやく「面白いか」が出てきます。
しかも、面白さはコードだけに書けません。
アセットだけにも書けない。
そこで「Vibesの谷」が出てきます。
Vibes（バイブス）は、雰囲気やそれっぽさのことです。
AIは雰囲気を一気に出せる。
でも、その雰囲気を現実の正解に合わせるには、作業を分ける必要があります。
分けると、分けたところにズレが生まれます。
その谷を埋める作業が大量に発生する5。
4. Fableは、言語と意味のモデルとして見ると得るものがある
だから、Fableを「商業品質のゲームを一発で作るモデル」として見ると、かなり危ういと思います。
小さなデモを作る範囲は広がりました。
それは確かに大きな変化です。
ただ、商業品質のゲームを、暗黙の正解まで全部満たして作る力とは違います。
扱わせる範囲を越えると、他の生成AIと同じようにポンコツになります。
範囲の問題。
むしろFableは、ここ1年の商用LLMの流れの中で、言語や意味の性能に厚みを感じさせるモデルとして見た方が面白いです。
コーディングのミスを減らす方向に寄っていたモデル群の中で、久々に言葉の力を強く感じる。
その見方なら、得るものが多い。
Fableは、頭の切れる文学者のように振る舞うことがあります。
温和な口調で、こちらの考えを深い言葉に変えてくる。
悪く言えば、表現力豊かなコンサルの弁舌です。
4.1. コードの相棒ではなく、意味を組み替える相棒
コードを書く相棒として見るなら、私は細かい約束を守るモデルの方を選びたくなります。
長い制約を保持する。
禁止事項を忘れない。
勝手な判断を混ぜない。
Fableの良さは、そこではありません。
曖昧な素材を受け取り、意味のまとまりに組み替えるところにあります。
言葉にする腕の見せ所。
批評を書く。
企画の方向性を探る。
ブランドの言葉を作る。
もやもやした違和感を、読める文章にする。
そういう作業では、Fableの強さはかなり活きます。
ただ、その出力をそのまま正解にしてはいけない。
言葉がうまいほど、確認が必要になります。
4.2. 出力を現実へ接続する仕事はまだ残る
生成AIは、入力を少なくして出力を増やします。
人間は、その出力を外の正解に接続します。
この分担は、しばらく変わらないと思います。
そのまま市場に並べて通用する出力は、まだ限られています。
谷を埋めるか。
そのままが正解になる場所を作るか。
あるいは、通用しているように見せるか。
Fable 5はすごいです。
でも、すごさの場所を間違えると、期待が大きいぶんだけ失望も大きくなる。
私が最近感じていたのは、そのズレでした。
新しいモデルに触るたびに、できることは増えます。
同時に、できていないことの輪郭も少し濃くなる。
その輪郭を見るのは、けっこう面白い。
- LLMの自己反省的なふるまいは研究対象になっていますが、外部フィードバックなしの反省ではタスクによって効果が割れることも報告されています。ここでは、人間の内省そのものではなく、出力上のふるまいとして扱っています。 – When Hindsight is Not 20/20: Testing Limits on Reflective Thinking in Large Language Models
- AnthropicのFable 5向けプロンプトガイドは、Fable 5の挙動差として、effort、指示追従、長時間実行、メモリ、足場づくりの調整を扱っています。モデルの性能向上に合わせて、従来の指示やガードレールを見直す必要がある、という説明もあります。 – Prompting Claude Fable 5
- IBMは生成AIを、ユーザーのプロンプトやリクエストに応じて、テキスト、画像、動画、音声、ソフトウェアコードなどを作るAIと説明しています。大規模なデータのパターンや関係を学び、それをもとに新しい内容を返す、という説明もされています。 – What is Generative AI?
- MDNのJavaScript実行モデルは、JavaScriptの実行にはエンジンとホスト環境の協力が必要で、エンジンがコードを解析して実行し、外部とのやり取りには環境側の仕組みが関わると説明しています。ここでは、ゲームが実際に動いている場を指す言葉として使っています。 – JavaScript execution model
- Unity Learnは、ゲーム開発に必要な基礎スキルとして、C#プログラミング、音声、ビジュアルエフェクト、ユーザーインターフェース、アニメーション、マテリアル、ライティングを挙げています。ゲームの正しさが複数の層にまたがることを考える手がかりになります。 – Game Development