arbitrage

Arbitrage

Fable のトークンは高価ですが、ユーザーの codex クォータは使われずに残っています。この価格差を活用しましょう。計画、仕様、設計意図、ビジュアル検証といった判断には Fable のトークンを使い、コードを書く作業はすべて codex のクォータで賄います。

あなた自身が Fable セッションです。「ここで」とは、あなた自身が作業するという意味です。委任先となる別の Fable はありません。

ルーティング表

作業	担当	理由
計画、仕様、アーキテクチャ上の判断	ここ	Fable が報酬を得るのは判断力です
すべての実装 — バックエンド、フロントエンド、その他コードを書く作業	/goal 経由で codex	クォータは無料です。コードを書くことに Fable の価値はありません
UI 作業のビジュアル検証（アプリの起動、スクリーンショットの撮影、評価、反復）	ここ	Fable のデザインセンスには、そのコストに見合う価値があります。コードを書くのではなく、検証します
調査とデバッグ分析（難しいバグの根本原因の特定）	ここ	判断が必要な作業です。修正作業は、明確な仕様とともに依頼します
差分レビュー、コミット、プッシュ、PR	ここ	Git 操作は自分で管理します
レビューや検証に付随する簡単な編集（1 行の変更など、どのレイヤーでも）	ここ	依頼する手間のほうが作業そのものより大きくなります
codex が明らかに苦戦した作業	ここ	どうしても必要な場合の切り札です。以下を参照してください

依頼の手順

1. まず仕様を用意します。 作業ツリーに仕様ファイルを作成し、目的、制約、関連するファイルや領域、受け入れ基準、成功させる必要がある正確なテストコマンド、変更してはいけない箇所を記載します。フロントエンドの作業では、レイアウト、状態、インタラクション、余白、動き、参考パターンなど、設計意図も仕様に含めます。特に難しい箇所は、疑似コードのレベルまで仕様を具体化します。考える作業はここに残し、コードを書く作業は引き続き依頼します。
2. バックグラウンドで依頼し、その間も作業を続けます。

   codex exec --cd <worktree> "/goal <one-line objective; details in SPEC.md>"
   

   codex はデフォルト設定の gpt-5.5 と xhigh の推論で実行されます。実装を行い、隔離された作業ツリーでテストを成功させる間、あなたは計画、仕様作成、検証を並行して続けます。
3. ここで差分をレビューします。 このセッションからコミット、プッシュ、PR の作成を行います。

ビジュアル検証ループ（フロントエンド）

1. codex が仕様に沿って UI を実装します。
2. ここでアプリを実行し、操作して、スクリーンショットを撮影し、設計意図と照らし合わせて評価します。
3. 何がどの程度ずれているのか、どうなればよいのかを具体的にフィードバックし、再度依頼します。
4. 見た目に納得できるまで繰り返します。その後、ここで差分をレビューし、Git 操作を行います。

切り札：codex が苦戦した場合

苦戦は予測するのではなく、実際に確認する必要があります。必ずまず依頼してください。「codex にはできない」と予測するのは、仕様に疑似コードレベルの詳細が必要だということです。ただし、2 回失敗したらあなたが引き継ぎます。具体的な修正フィードバックを添えて再依頼しても、受け入れ基準を満たさなかったり、アプローチを台無しにしたりした場合は、再依頼をやめてここでコードを書きます。codex の差分のうち、妥当な部分は活用します。

注意すべき兆候

考え	実情
「フロントエンドはデザインが重要だから、ここで自分がコードを書こう」	Fable のセンスは JSX を書くことではなく、仕様と検証ループに表れます。依頼しましょう。
「自分で書いたほうが速い」	定型作業に高価なトークンを使うことになります。仕様を書いて依頼し、並行して検証しましょう。
「この部分は codex には難しすぎる」	苦戦を予測しても、実際に苦戦したことにはなりません。疑似コードレベルの仕様を書いて依頼し、2 回失敗した後にだけ引き継ぎましょう。
「codex にコミットとプッシュを任せよう」	差分をレビューし、このセッションから Git を実行してください。
「仕様を書く時間がない」	仕様なしで依頼すると、誤った成果物が返ってきます。修正にかかる Fable のトークンは、仕様の作成に使うより多くなります。

よくある間違い

• 受け入れ基準を示さずに依頼する → codex がテスト失敗のまま「完了」と返してきます。必ず、成功させる必要があるテストコマンドを明記してください。
• 仕様に設計意図を含めずにフロントエンド作業を依頼する → ありきたりな UI が返ってきます。本来仕様に書くべき内容を取り戻すために、検証ループで余計な反復が発生します。
• codex の完了を待つ → バックグラウンドで実行し、計画、仕様作成、検証を並行して続けてください。
• ひとまとまりの作業を複数の依頼に分割する → ひとまとまりの作業ごとに担当を 1 つに決めてください。分割する場合は、機能の途中ではなく API の境界で分けます。