JA
CRUMBロゴのパンのキャラクターだけを残した画像：右上の角をひと口かじった、笑顔の食パン
展示室へ戻る

CRUMB

Generative Game Studio · Demo

1行のゲーム企画からプレイ可能な草案まで、エージェントの作業を見ながら介入します。

CRUMBは、カジュアルゲームのプロトタイピングのためのマルチエージェント・スタジオハーネスです。

設計・開発 · AIコーディングエージェントを活用

  • CLIローカルデモ
  • Web Studioローカルデモ

ゲームを作るエージェントと、それを判定する根拠を分けています。

1行のゲーム企画を、仕様、ビルド、実行検査へとつなぐローカルスタジオのデモです。すべての段階がJSONL transcriptに記録され、純粋なreducerが次のeffectを決め、副作用はdispatcherだけが実行します。実行QAとモデルの判定を分けて、通過、再設計、修正、人による介入のいずれかを決めます。

1行のゲーム企画を入力すると、Claude Code、Codex、Gemini CLIのエージェントがPlanner → Builder → 決定論的QA → Verifierの順に協働し、CRUMB Studioはイベント、進捗、成果物を表示して、自然言語による介入を受け付けます。

公開リポジトリをcloneして、ローカルで実行するデモです。

システム構成図 · 公開コミットf5e17c0のコードパスから作図
CRUMBスタジオのシステム人はStudioからゲームを企画して介入し、Studioはinboxにコマンドを書き込みます。コーディネーターはinboxとtranscriptの新しいイベントを順にreducerへ渡し、純粋なreducerが状態と次のeffectを決め、副作用はdispatcherだけが実行します。Plannerの仕様、Builderのビルドと成果物、実行QAの結果、Verifierの判定は、すべてtranscriptイベントになります。Verifierは投影された根拠だけを受け取り、reducerはそのスコアをQAの結果と照らして検査・補正します。PASSならセッションを終了し、PARTIALなら人を待ち、それ以外は再設計か修正に戻します。ゲームの企画 · 介入ローカルで使う人packages/studioイベント · 成果物の表示inboxにコマンドを書き込みsrc/transcripttranscript.jsonl · append-onlysrc/loop/coordinator.tsイベントループ · リプレイ · tailsrc/reducer状態 → 次のeffect判定のルーティングsession done終了 · PASSまたは停止理由src/dispatcher/live.tseffectの実行 · actorのspawn判定入力の投影model-config · presetactor → ハーネス · モデルagent actor · CLIPlanner Lead · 仕様Builder · ゲームを作成artifacts/ゲームファイルdispatcher/qa-runner.ts実行QA · 検査Verifier actorVerifier · モデルの判定src/validatoranti-deception · スコア補正人 · Studioイベント制御transcriptが状態の源作業エージェント · 成果物検証 · 決定1企画 · 介入2userイベント3順にreduce4effect5actorの設定6Plannerを実行7spec8Builderを実行9ファイル10ビルド記録11qa_check12実行対象13qa.result1qa.result2根拠のみ3判定入力4judge.score5スコア · QAの根拠6補正された判定7終了1補正された判定2PARTIALの確認3再設計 · 修正4終了5企画 · 介入1新しいイベント · リプレイ2順にreduce3読み取り · SSE

企画からプレイまで

企画が仕様、ビルド、実行QAへと進みます。すべての段階がtranscriptを経由し、actor同士が互いを呼び出すことはありません。

  1. ゲームの企画 · 介入企画 · 介入inboxにコマンドを書き込みpackages/studio

    1行のゲーム企画と自然言語の介入をStudioで入力すると、Studioはinboxにコマンドを書き込みます。Studioがtranscriptを直接編集することはありません。

  2. inboxにコマンドを書き込みpackages/studiouserイベントイベントループ · リプレイ · tailsrc/loop/coordinator.ts

    コーディネーターがinboxのコマンドを読み、userイベントとしてtranscriptに記録します。

  3. イベントループ · リプレイ · tailsrc/loop/coordinator.ts順にreduce状態 → 次のeffectsrc/reducer

    ライブのイベントはキューから1つずつreduceし、各イベントのeffectの順序を保ちます。dispatch自体は非同期で動きます。

  4. 状態 → 次のeffectsrc/reducereffecteffectの実行 · actorのspawnsrc/dispatcher/live.ts

    reducerは、状態と次のeffectだけを決める純粋関数です。goalならPlanner、specならBuilder、buildならqa_checkを選びます。

  5. actor → ハーネス · モデルmodel-config · presetactorの設定src/dispatcher/live.ts

    actorをどのハーネス、プロバイダー、モデルで動かすかは、CLIフラグ > 設定 > プリセット > ambient > fallbackの順で決まります。actorは固定のプロバイダーではありません。

  6. effectの実行 · actorのspawnsrc/dispatcher/live.tsPlannerを実行Planner Lead · 仕様agent actor · CLI

    dispatcherは投影された入力でPlannerを実行します。条件付きのリサーチはPlannerのリサーチ計画と証拠の引き継ぎを経て続きますが、この構成図では折りたたんでいます。

  7. Planner Lead · 仕様agent actor · CLIspectranscript.jsonl · append-onlysrc/transcript

    Plannerの仕様はtranscriptイベントとなり、reducerがそれをもとにBuilderを選びます。actor同士が互いを呼び出すことはありません。

  8. effectの実行 · actorのspawnsrc/dispatcher/live.tsBuilderを実行Builder · ゲームを作成agent actor · CLI

    dispatcherがBuilderを実行します。同じactorが失敗を繰り返すとcircuitが開いてadapterを切り替え、それでも失敗が続けば停止します。

  9. Builder · ゲームを作成agent actor · CLIファイルゲームファイルartifacts/

    Builderは、エントリファイル、ソース、アセットを成果物として書き込みます。

  10. Builder · ゲームを作成agent actor · CLIビルド記録transcript.jsonl · append-onlysrc/transcript

    buildイベントとartifact.createdが、成果物のidentityとともにtranscriptに記録されます。

  11. effectの実行 · actorのspawnsrc/dispatcher/live.tsqa_check実行QA · 検査dispatcher/qa-runner.ts

    buildイベントの後、reducerは成果物とビルドのidentity、受け入れ条件を含むqa_check effectを発行し、dispatcherがそれを実行します。

  12. ゲームファイルartifacts/実行対象実行QA · 検査dispatcher/qa-runner.ts

    実行QAは、実際の成果物をコードとブラウザの検査で実行します。既定のタイムアウト120秒は設定値です。

  13. 実行QA · 検査dispatcher/qa-runner.tsqa.resulttranscript.jsonl · append-onlysrc/transcript

    成功でも失敗でも、結果はsystemのqa.resultイベントとして記録されます。検査が例外を投げても、失敗した項目を含む結果が記録されます。

検証の信頼境界

実行QAは成果物を実際に動かして得た根拠で、Verifierは投影された根拠を判定するモデルです。reducerは両者を突き合わせてから次の経路を選びます。

  1. 実行QA · 検査dispatcher/qa-runner.tsqa.resulttranscript.jsonl · append-onlysrc/transcript

    成功でも失敗でも、結果はsystemのqa.resultイベントとして記録されます。検査が例外を投げても、失敗した項目を含む結果が記録されます。

  2. transcript.jsonl · append-onlysrc/transcript根拠のみ判定入力の投影src/dispatcher/live.ts

    Verifierの入力は、最新のgoal、spec、build、qa.result、artifact.createdと、選ばれたリサーチの証拠から投影されます。コンテキストを絞るだけで、隔離や漏洩がないことを証明するものではありません。

  3. 判定入力の投影src/dispatcher/live.ts判定入力Verifier · モデルの判定Verifier actor

    dispatcherは投影された入力でVerifierを実行します。

  4. Verifier · モデルの判定Verifier actorjudge.scoretranscript.jsonl · append-onlysrc/transcript

    Verifierの判定はjudge.scoreイベントとして記録されます。モデルの判断であり、実行についての事実ではありません。

  5. 状態 → 次のeffectsrc/reducerスコア · QAの根拠anti-deception · スコア補正src/validator

    judge.scoreを受け取ると、reducerはそれをQAの結果、Builderのプロバイダー、リサーチ計画と証拠とともにanti-deception検査に渡します。

  6. anti-deception · スコア補正src/validator補正された判定判定のルーティングsrc/reducer

    成功した実行がないPASSはFAILになり、実行に関するスコアは決定論的なQAから補正されます。その他のルールは条件付きの補正であり、真実性一般の証明ではありません。

  7. 判定のルーティングsrc/reducer終了終了 · PASSまたは停止理由session done

    PASSならセッションはdoneで終わります。予算やcircuitによる停止もdoneで終わりますが停止理由が残るため、doneが常にPASSとは限りません。

失敗と人による介入

PARTIALは人へ、Criticalは再設計へ、ImportantとMinorは修正へ進み、予算やcircuitによる停止は停止理由を残します。

  1. anti-deception · スコア補正src/validator補正された判定判定のルーティングsrc/reducer

    成功した実行がないPASSはFAILになり、実行に関するスコアは決定論的なQAから補正されます。その他のルールは条件付きの補正であり、真実性一般の証明ではありません。

  2. 判定のルーティングsrc/reducerPARTIALの確認ゲームの企画 · 介入

    PARTIALは人の確認を待ちます。

  3. 判定のルーティングsrc/reducer再設計 · 修正src/dispatcher/live.ts

    FAILとREJECTのうち、CriticalはPlannerへの再設計に、ImportantとMinorはBuilderへの修正フィードバックに戻り、いずれもdispatcherのeffectとして実行されます。

  4. 判定のルーティングsrc/reducer終了終了 · PASSまたは停止理由session done

    PASSならセッションはdoneで終わります。予算やcircuitによる停止もdoneで終わりますが停止理由が残るため、doneが常にPASSとは限りません。

  5. ゲームの企画 · 介入企画 · 介入inboxにコマンドを書き込みpackages/studio

    1行のゲーム企画と自然言語の介入をStudioで入力すると、Studioはinboxにコマンドを書き込みます。Studioがtranscriptを直接編集することはありません。

リプレイと観測

transcriptから状態を再構築してもeffectは実行されず、Studioは同じ記録を読んで表示します。

  1. transcript.jsonl · append-onlysrc/transcript新しいイベント · リプレイイベントループ · リプレイ · tailsrc/loop/coordinator.ts

    writerはスキーマを検証し、ULIDと時刻を付けて追記します。リプレイ時は過去のイベントをreduceするだけで、そのeffectは再実行しません。

  2. イベントループ · リプレイ · tailsrc/loop/coordinator.ts順にreduce状態 → 次のeffectsrc/reducer

    ライブのイベントはキューから1つずつreduceし、各イベントのeffectの順序を保ちます。dispatch自体は非同期で動きます。

  3. transcript.jsonl · append-onlysrc/transcript読み取り · SSEイベント · 成果物の表示packages/studio

    Studioはtranscriptと成果物を読み、SSEで進捗、メトリクス、成果物を表示します。リモートのサービスに送るテレメトリではありません。

すべての接続を同じ太さで表示します。フローを選ぶと、その経路だけを番号付きで強調します。

  • 実線 · 入力、結果、記録の流れる方向
  • 破線 · 実行、判定、要求
  • 長い点線 · 観測と報告、判定とは別
  • 太い黒線 · 選んだフロー。番号は順序
  • ボックス · コードまたは状態の境界、見出しに名前
  • 内側のチップ · その境界の構成要素
  • 点線ボックス · その境界の外
  • オレンジの枠 · モデルが判断する場所
  • イベントループ · reducer · dispatcher
  • 記録 · 設定 · 成果物
  • 決定的な検査 · 補正
  • Studio · actor

公開コミットf5e17c0のコードパスから描きました。actorはランタイムの実行役割であり、このリポジトリの開発に使ったコーディングエージェントとは別のものです。

状態の源
transcriptが状態の源であり、reducerは純粋関数です。副作用（actorの実行、QA、ファイルの書き込み）を行うのはdispatcherだけなので、リプレイは副作用なしで状態を再構築します。
リプレイの範囲
リプレイで得られるのは同じ状態であり、LLMの生成やブラウザ・ネットワークの挙動まで決定的になるわけではありません。
判定の範囲
実行QAは設定された検査だけを確認し、Verifierのスコアは根拠のひとつです。どちらも、ゲームのすべての挙動や面白さ、ユーザーの満足度を測るものではありません。