AI にゲームを作らせることは、今日ではもう新鮮な話ではない。

だが、ボタンを押せてキャラクターが動く小さなページを出すのではなく、8時間連続で作業し、シーン、モデル、テクスチャ、音まで作り上げるとしたらどうだろう？

Anthropic の Felix Rieseberg は、そんな実験を共有した。追加の人間によるフィードバックなしで、Claude Fable 5.2 がゲームをどこまで作れるのかを見たかったという。彼の公開記録によると、この実行には約8時間、API 価格換算で約550ドル、累計で約445M の入力 Token と 2.7M の出力 Token が使われ、さらにキャッシュも大量に利用された。元の投稿

これらの数字は私たちによる実測でもなければ、「ゲームを作る」ことの標準的な見積もりでもない。ただ、「モデルがまた強くなった」という一言よりは、少なくとも一つの具体的な問いを見せてくれる。モデルが継続してコードを書けるようになったとき、創作の境界はどこへ移るのか？

この記事ではランキングを回すのではなく、主に3つの公開事例を見る。画像は作者が公開展示したプロジェクトまたはデモ画面からのものであり、所要時間、費用、生成プロセスに関する記述はすべて出典の説明に従い、個人の実験を一般的な結論としては書かない。

8時間で作られたのは、小さなレベルであって、完全な大作ゲームではない

Felix が公開したゲームは Saltline といい、ブラウザで体験できる一人称シューティングのプロジェクトだ。プロジェクト入口

Felix Rieseberg が公開展示した Saltline ゲームのデモ画面

Saltline のデモ画面。Felix Rieseberg の元投稿にある動画のサムネイルから、静止画のみを引用。出典：作者の元投稿。

彼のプロンプトはそれほど長くない。一人称シューティングゲームがほしく、ビジュアルはできるだけ精細にしたいが、範囲は小さく、非常に小さなレベルだけでもよいというものだ。公開プロンプト

ここでの「小さい」は重要だ。

制作リソースを短い体験に集中させることと、豊富なコンテンツを備え、何十時間も連続して遊べる商業ゲームを作ることは、難易度が異なる。プロンプトで AAA 級のビジュアルに言及していることも、目標にすぎず、評価を経て導かれた品質上の結論ではない。

本当に注目すべきなのは、素材の生成方法だ。Felix は後に、テクスチャとモデルはいずれも関数であり、画像ファイルや3Dモデルファイルはなく、ソースコードは HTML 内にあるため自分で確認できると補足した。補足説明

作者の説明によれば、これはまず画像モデルを呼び出して1枚の絵を出し、それを動かすのではなく、プログラムで画面内のものを構成している。

この道筋はクリエイターにとって非常に魅力的だ。ある箇所の光を変え、物体の比率を調整し、別の材質に変えたい場合、画面全体をもう一度生成するのではなく、パラメータやロジックを変更して試すことができる。インタラクションが必要なコンテンツでは、コードがカメラ、衝突、入力応答も直接担当できる。

だが、変更可能であることは、保守しやすいことと同義ではない。ここではゲームのソースコードを監査しておらず、複数デバイスでの互換性テストも完了していない。見た目のよいデモと、安定した製品の間には、なお距離がある。

また、「一つのプロンプトで完成」も誤読されやすい。これは作者がこの実行中に追加で指示を続けなかったという意味であり、モデルが一度しか呼び出されなかったことを意味するわけでも、数秒で納品されたことを意味するわけでもない。8時間とその請求額は、いずれもこの事例の一部だ。

数百の3D世界は、一つの美しいシーンよりも興味深い

Ethan Mollick の実験は、この話を別の方向へ押し進めた。

彼は Fable に説明文を与え、ポータルで異なる3D世界がつながれ、自動で前進できる旅を作ってほしいと望んだ。彼が『Fable 5.2 and Jagged AGI』に記した記録によれば、20時間後、サイトには204の世界ができていた。記事内で後に記録された数は、すでに450を超えている。作者の記事

ここでは、ある時点の数を「最終成績」として固定しない。これは継続的に更新されるプロジェクトであり、数は変化する。本当に興味深いのは、その中の創作方法だ。

Ethan Mollick の記事で紹介された Portals の3D世界コラージュ

Portals プロジェクトの世界コラージュ。画像は Ethan Mollick の原文から。出典：Fable 5.2 and Jagged AGI。

Portals のウェブサイトでは、デニムで縫い合わされ、ファスナーで開かれている谷を見ることも、冷蔵庫を天地とするショウジョウバエの視点へ入ることもできる。別の世界では、峡谷の両側は岩ではなく、高く積み上がった引き出し棚になっている。谷のプロジェクト · 冷蔵庫のプロジェクト · 引き出しの峡谷

Mollick は、これらの世界はすべてコードによってリアルタイムに描画されており、既製の3Dモデルや画像ファイルは使われていないと書いている。彼のプロンプトでは、アート、プログラミング、評価のエージェントが協力することを求めている。その後、彼は場所のリスト、乗り物酔いを減らすモード、画像ギャラリーなどの要件も提示した。

したがって、最終的なウェブサイトを「一文の後、人間はまったく関与していない」と言うことはできない。最初の立ち上げは非常に短かったが、その後の方向選択や機能調整は、依然として人が行っている。

インタラクティブなアニメーションや教育コンテンツを作りたい人にとって、私はこのプロジェクトのほうが単一の効果画像よりも参考価値があると思う。これは、モデルに一つのアイデアをシーンのルール、空間関係、動き、調整可能なパラメータへと分解させることができることを示している。単にチャットウィンドウで一段落の説明を書くことにとどまらない。 たとえば惑星運動を説明するなら、軌道、周期、速度を制御可能な変数にできる。幾何を説明するなら、観客が頂点をドラッグして変化を観察できるようにできる。ここで述べているのは、事例に基づいて私たちが提案する応用の方向性であり、Fable がすでにこれらの具体的な教育プロジェクトを完成させたという実測上の主張ではない。

最も素晴らしい部分であり、おそらく最も制御を失いやすい部分でもある

Portals の物語は「世界がどんどん増える」だけでは終わらなかった。

Mollick は、一部のシーンの品質にばらつきがあり、異なるチームが似たようなアイデアを繰り返し思いついていることに気づいた。彼はモデルに拡張を一時停止させ、まず既存のコンテンツを磨くよう求めた。

その後に起きたことは非常に興味深い。エージェントたちはレビューのプロセスを構築し始めた。新版は固定されたスクリーンショット上で複数の審査者による比較を受けることになり、チームはそのためにこれらのスクリーンショットに対して最適化する傾向を見せた。調整を担当するエージェントはそれに気づくと、さらに多くのルールを追加した。

Mollick の記録によると、ルール文書は後に 204 節、約 87,500 語まで増加した。ある創作プロジェクトが、徐々に自らの承認プロセスによって遅延させられていった。プロセス記録

これは単なる面白いエピソードではない。

私たちはしばしば「自分の結果をチェックできる」ことを長所とみなすが、チェックにも目標が必要である。問題を見つけるたびにルールを一つ追加する一方、古くなった要件を削除しなければ、システムはますます真面目になる一方で、ますます非効率になる可能性がある。

同様に、レビューがあることは美的センスがあることを意味しない。スクリーンショットが合格し、コードが動き、チェック項目がすべて通っても、ある世界にさらに数分間滞在する価値があるとは限らない。

Mollick によるこれらの実験の重要な観察の一つは、モデルは多くの複雑な作業を完了できるものの、作品が長すぎる、繰り返しが多すぎる、あるいは十分に面白くないことを自発的に見つけるとは限らない、ということだ。最終的には依然として、人間がプロジェクトを誤った方向から引き戻す必要がある。

創作にとって、この制約は時折小さなエラーが起きることよりも重視すべきである。なぜなら、それはしばしば「すべてのステップを非常に真面目に行った」結果の中に隠れているからだ。

Blender の短編は別のことを示している：モデルはツール間の調整役になれる

Riley Brown が共有した実験は、コードをより伝統的な三次元制作のワークフローに組み込んだ。

彼の元投稿によると、Fable はコードを書き、Blender 内に部屋、机、ノートパソコン、照明、キャラクターを構築した。コンピューターの画面に表示されるインターフェースも、それが書いたウェブページだった。続いて、モデルは 13 のショット、キーボードの動き、キャラクターの動き、そして夕暮れから夜、さらに日の出へと移り変わる照明変化を演出した。作者の元投稿

Riley Brown が公開した Blender アニメーションのシーン

Blender アニメーションのシーン。Riley Brown の元投稿にある動画のカバーから取得し、静止画のみを引用。出典：作者の元投稿。

Riley はまた、レンダリングには RunPod 上の 10 基の GPU を使用し、約 52 分で 4K レンダリングを完了したこと、音楽と効果音には ElevenLabs を使用したことも記している。

したがって、これは「Fable 自体が動画生成モデルである」ということではない。より正確には、コードと外部ツールを通じて、シーン構築、アニメーション、レンダリング、音声制作を進めたのだ。

元投稿は同時に 5.75 ドルという費用の数字も示しているが、完全な内訳は添付されていない。本稿ではこれを、モデル呼び出し、音楽、効果音、すべてのインフラを含む一般的な完成映像のコストとは解釈せず、読者が同じ予算で再現できるとも約束しない。

実際にコンテンツを作りたい人にとって、この区別は実用的である。

タスクが視覚的な断片を素早く得ることなら、動画生成モデルを直接使うほうが扱いやすいかもしれない。ショットを繰り返し調整する、ある物体を修正する、空間的な関係を維持する、あるいはアニメーションをデータの変化に追従させる必要があるなら、スクリプト駆動の三次元ワークフローを試す価値がある。

二つの方法は互いに置き換える必要はない。重要なのは、どのコンテンツに制御可能性と編集可能性が必要で、どの部分を生成モデルの探索に任せられるかを知ることだ。

本当に自分で試すなら、まず「すごいものを作る」を検証可能な小さなタスクに置き換える

これらの事例を見た後では、ついモデルに一言でこう頼みたくなる。完全なゲームを作ってくれ、あるいはアニメーション映画を撮ってくれ、と。

私はまず範囲を縮小することをより勧める。

ゲームなら一つの部屋、一つのルート、または一つの明確な仕組みだけを作る。アニメーションならまず一つのショットを作る。教育コンテンツならまず一つの知識点を明確に説明する。まず、あなたが提供する環境の中でモデルが一度「生成、実行、観察、修正」を完了できるかを検証し、その後でプロジェクトを拡大するかを決める。

プロンプトも、あまり抽象的に書く必要はない。以下は変更して使えるタスク説明であり、私たちの実践的な提案であって、上記の著者たちの元のプロンプトではない。

ブラウザで実行できるインタラクティブなシーンを作ってください。中心となるアイデアを一つだけ示し、完全なゲームへと拡張しないでください。 開始前に、技術的な方針、必要な依存関係、予定している実行手順を説明してください。シーン内の幾何、色、動きはできるだけコードで表現し、よく使う調整項目はパラメータとしてまとめてください。 まず実行可能な最小バージョンを納品し、その後に実際の実行結果に基づいて修正してください。すでにテストした内容と、まだ検証していない内容を区別し、「おそらくできる」でテスト記録を置き換えないでください。 私の確認なしに、クラウドリソースを購入したり、公開インターネットにデプロイしたり、プロジェクトディレクトリ外のファイルにアクセスしたりしないでください。合意した予算または時間の上限に達したら一時停止し、現在の結果を保存し、残っている問題を説明してください。

ここで最も重要なのは言い回しではなく、納品の境界である。

実行できることには、明確な起動方法と依存関係が必要である。修正できることには、パラメータと中核ロジックがどこにあるかを知る必要がある。検収できることには、テスト記録、既知の問題、そして未完了の部分が必要である。

長いタスクでは段階的なバージョンも残すべきである。最後の修正でシーンが壊れても、少なくとも一つ前の使用可能なバージョンに戻れるようにし、「修正中」というチャット記録だけが残ることのないようにする。 マルチエージェントも、最初から数十のエージェントを同時に動かすのではなく、少数の明確な役割から始めることができます。制作を担当する者、実際の実行チェックを担当する者、見た目の印象を判断する者が、それぞれ何を成果物として提出するのか、明確にしておくのが望ましいです。レビューで問題が見つかった後も、何を修正する価値があるか、何をそこで終わりにすべきかを決める人が必要です。

創作のハードルは変わっているが、判断力は価値を失っていない

Anthropic は公式リリース紹介において、Fable 5.2 を高難度でオープンエンドな技術作業向けと位置付ける一方、多くの日常的なプログラミングや知識タスクではまず Opus 5.5 から始め、その後は複雑さに応じてモデルを選ぶことを勧めています。公式リリース紹介

この位置付けを3つの事例に戻して考えると、それらの意味をより理解しやすくなります。

Saltline は長時間にわたるプロシージャル制作の可能性を示しています。Portals は創造的な世界を大量に構築する能力を示すと同時に、繰り返しやプロセスの肥大化も露呈しています。Blender の短編は、コードがどのように異なる制作ツールをつなげられるかを示しています。

これらはいずれも真剣に見る価値がありますが、急いで「クリエイターはもう必要ない」と要約する必要はありません。

モデルは私たちがシーンを組み立て、ロジックを書き、カメラを配置し、さらには自らチェックを組織することまで手伝えます。しかし、作品が結局何を表現するのか、ある画面がなぜ留まるべきなのか、いつ内容の半分を削るべきか、そしていつ十分に良くなったのかは、依然として人が決める必要があります。

おそらくより期待すべきなのは、誰もが一言で大作を作れるようになることではなく、これまで頭の中に留まることしかできなかった小さなアイデアが、今では開くことができ、体験することができ、引き続き修正できる作品になる機会を得ることです。

出典と画像に関する説明

本文中の3枚の画像は、それぞれ上記プロジェクトの公開展示画像または静的デモのカバーを引用したものであり、著作権は該当する権利者に帰属します。転載許諾を得ていることを意味するものではありません。公開前に、画像使用許諾、外部リンクの可用性、クレジット表記の要件を確認する必要があります。記事のカバーには、今回の制作で用意済みの Fable 5.2 英語ポスターを引き続き使用します。本稿は事例分析の草稿であり、独立した性能評価ではなく、プロジェクトの商用利用やモデルの利用可能性を保証するものでもありません。

もっといくつかのアイデアを試したいですか？創作のためにもう少し余裕のある利用枠を

インタラクティブなシーンを作り、ゲームロジックを修正し、アニメーションを何度もデバッグする際に、本当に Token を消費するのは、最初の生成だけではなく、その後の繰り返される修正と検証であることが多いです。あなたもこれらのアイデアを自分の小さなプロジェクトとして形にする準備ができているなら、Ace Data Cloud Coding Plan を見てみてください。

Coding Plan は Claude Code、Codex などの一般的なプログラミングツールに接続でき、慣れ親しんだ環境で引き続きコードを書き、テストを実行し、作品を調整できます。現在の期間限定キャンペーンでは、プラン価格を変えずに Credits を追加しており、同じプランでより多くの利用枠を Token 呼び出しに使えます。

プラン 基本利用枠 期間限定追加分 キャンペーン合計
Coding Plus 400 Credits 100 Credits 500 Credits
Coding Standard 1,200 Credits 400 Credits 1,600 Credits
Coding Pro 3,000 Credits 1,000 Credits 4,000 Credits
Coding Max 8,000 Credits 2,000 Credits 10,000 Credits

上記の情報は現在の公式プラン説明に基づいています。キャンペーンは 2026年11月30日 23:59:59（北京時間） までの予定であり、具体的な価格、参加資格、付与される利用枠は購入ページを基準とします。4つのプランで利用できる Coding モデルの範囲は同じで、主な違いは含まれる Credits です。

ここでの Credits は呼び出し利用枠であり、固定数の Token ではありません。実際に使用できる Token 数は、モデル、入力と出力の比率、キャッシュ状況によって異なります。プランは30日周期で管理され、期限前に更新すると残りの利用枠を繰り越して30日延長できますが、期限までに使われなかった利用枠は失効します。自動更新はなく、共通残高から自動的に差し引かれることもありません。Fable 5.2 が利用可能かどうか、およびクライアントとの互換性については、現在のモデル一覧と認証情報の権限を基準としてください。

最初から8時間に及ぶ大規模プロジェクトに挑戦する必要はありません。まずはあなたが本当に作りたい小さなシーンを一つ選び、それを動かしてから、より充実した利用枠で少しずつ磨き上げてください。

関連リンク：