Fableをオーケストレーター、GPT-5.6 Lunaを実装者にする — 異種モデル分業の設計と実装

「一番賢いモデルに全部やらせる」が一番高くつく

エージェントにコードを書かせていると、請求書の内訳が直感とズレていることに気づきます。 設計を考えていた時間より、生成されたコードそのものが圧倒的にトークンを食っている。 難しい判断は数百トークンで終わり、その判断に従って書かれる実装は数万トークンになる。

この非対称性に対して、単一モデルの構成は無防備です。 最も高価なモデルに、最も安くていい仕事——定型的なコード生成、テスト修正の反復——をやらせ続けることになる。

本記事では、Claude Fable 5 をオーケストレーター（設計・分解・レビュー）に、GPT-5.6 Luna を実装者（コード生成・修正ループ）に据える分業アーキテクチャを扱います。 「安いモデルを混ぜればコストが下がる」という話ではありません。分業の境界をどこに引くかで、この構成は劇的に効きもすれば、往復が増えて単一モデルより高くつきもします。境界設計が本題です。

2つのモデルの素性

まず前提を揃えます。2026年8月時点の両モデルの主要スペックです。

数字で一番効いてくるのは単価差です。出力で41.7倍、入力で50倍。 Lunaは2026年7月9日にGPT-5.6ファミリーの一員として登場し、当初は $1 / $6 でしたが、7月30日にOpenAIが約80%の値下げを行い $0.20 / $1.20 になりました。この値下げが、分業アーキテクチャの経済性を一段引き上げています。

分業の原理 — 判断は短く、生成は長い

なぜ「オーケストレーター／実装者」という切り方なのか。 役割ごとのトークンプロファイルを見ると理由がはっきりします。

graph LR
  subgraph ORC["オーケストレーター的な仕事"]
    O1["要件の曖昧性解消"] --> O2["設計判断"]
    O2 --> O3["タスク分解"]
    O3 --> O4["受け入れ判定"]
    O4 --> OT["出力: 短い<br/>難易度: 高い<br/>1トークンの重みが大きい"]
  end
  subgraph IMP["実装者的な仕事"]
    I1["コード生成"] --> I2["テスト実行"]
    I2 --> I3["エラー修正"]
    I3 --> I1
    I1 --> IT["出力: 長い<br/>難易度: 中<br/>反復回数が多い"]
  end
  OT -.->|"高単価モデルを割り当てる"| ORC
  IT -.->|"低単価モデルを割り当てる"| IMP

「難しい仕事ほど出力が長い」なら分業は成立しません。実際は逆で、アーキテクチャ上の判断は一文で表現でき、その一文に従う実装は数千行になる。 だから難易度で分けると、コストとうまく分離できます。

工程ごとの担当割り当ては次のようになります。

実装A：Codex CLIに丸投げする（最短経路）

一番手っ取り早いのは、Claude Code のサブエージェントから Codex CLI を叩く形です。 Codex CLI は /model で gpt-5.6-luna に切り替えられるので、設定を1行変えるだけで「実装者はLuna」が成立します。

# ~/.codex/config.toml
model = "gpt-5.6-luna"
model_reasoning_effort = "medium"

あとは Claude Code 側のサブエージェント定義から codex を呼ぶだけです。 公式の Codex プラグイン（codex:rescue）はまさにこの形で、 「サブエージェント自身は一切考えず、プロンプトを整形して転送するだけの薄いラッパー」として実装されています。

実装Aは試すには最適ですが、本記事の主題である境界設計にはあまり手が届きません。 CLIは自分でファイルを探して読むので、「Lunaが何を知っていて何を知らないか」がこちら側から見えなくなるためです。 以降は実装Bを掘ります。

実装B：Fableのカスタムツールとして Luna を生やす

本命はこちらです。Lunaを、Fableから見た1つのツールとして定義する。 Fableは「ファイルを書く」のではなく「実装を委譲する」という道具を持った状態になります。

sequenceDiagram
  participant U as 👤 ユーザー
  participant F as Claude Fable 5<br/>（オーケストレーター）
  participant T as implement ツール
  participant L as GPT-5.6 Luna<br/>（実装者）
  U->>F: 「◯◯機能を追加して」
  F->>F: 要件の解釈・設計判断
  F->>T: spec / files / acceptance
  T->>L: 自己完結の仕様プロンプト
  L-->>T: 実装コード（+ QUESTIONS）
  T-->>F: 差分のみ返す
  F->>F: 受け入れ基準に照らしてレビュー
  alt 基準を満たす
    F-->>U: 完了報告
  else 不足あり
    F->>T: 修正仕様を再委譲
  end

TypeScript SDKの Tool Runner を使うと、エージェントループ自体はSDKが回してくれるので、 書くのは「ツールの中身」だけで済みます。

import Anthropic from '@anthropic-ai/sdk';
import { betaZodTool } from '@anthropic-ai/sdk/helpers/beta/zod';
import OpenAI from 'openai';
import { z } from 'zod';

const anthropic = new Anthropic();
const openai = new OpenAI();

const implement = betaZodTool({
  name: 'implement',
  description:
    'GPT-5.6 Luna に実装を委譲する。呼び出し側の会話履歴・思考は一切渡らないため、' +
    'spec と files だけで作業が完結するように書くこと。' +
    '設計判断と受け入れ基準の決定は、このツールの外（あなた自身）で行う。' +
    '仕様書が書けない仕事は、まだ委譲してはいけない。',
  inputSchema: z.object({
    spec: z
      .string()
      .describe('実装仕様。前提・入出力・制約・使用ライブラリのバージョンをすべて含む自己完結なテキスト'),
    files: z
      .array(z.object({ path: z.string(), content: z.string() }))
      .describe('Lunaが読む必要のある既存ファイル全文。渡し漏れると推測で書かれる'),
    acceptance: z
      .array(z.string())
      .describe('受け入れ基準。「動く」ではなく検証可能な形（コマンドと期待結果）で書く'),
  }),
  run: async ({ spec, files, acceptance }) => {
    const res = await openai.responses.create({
      model: 'gpt-5.6-luna',
      reasoning: { effort: 'medium' },
      input: [
        {
          role: 'developer',
          content:
            '与えられた仕様とファイルだけを根拠に実装する。' +
            '仕様にない機能・抽象化・エラーハンドリングを足さない。' +
            '不明点は推測で埋めず、末尾の QUESTIONS 節に列挙して停止する。',
        },
        { role: 'user', content: buildPrompt(spec, files, acceptance) },
      ],
    });
    return res.output_text;
  },
});

オーケストレーター側の呼び出しはこうなります。

const ORCHESTRATOR_SYSTEM = `
あなたは実装を委譲する側です。自分ではコードを書かず、implement ツールに委譲します。

委譲する前に、必ず次を確定させること:
- 何を作るのか（曖昧なら、まずユーザーに確認する）
- 既存コードのどのファイルが必要か
- 何をもって完了とするか（検証可能な受け入れ基準）

implement の戻り値をレビューするときは、重要度や確信度でフィルタせず、
気づいた問題をすべて挙げること。取捨選択はレビューの後段で行います。
`;

const finalMessage = await anthropic.beta.messages.toolRunner({
  model: 'claude-fable-5',
  max_tokens: 32000,
  // Fable 5 は思考が常時ON。thinking パラメータは渡さない（渡すと400）
  output_config: { effort: 'high' },
  system: ORCHESTRATOR_SYSTEM,
  tools: [implement],
  messages: [{ role: 'user', content: task }],
  // 安全性分類器による refusal をサーバー側でフォールバックさせる
  betas: ['server-side-fallback-2026-06-01'],
  fallbacks: [{ model: 'claude-opus-4-8' }],
});

境界設計こそが本体 — 仕様ハンドオフ問題

ここが本記事で一番言いたいところです。

ツール境界は、そのままコンテキスト境界です。Fableが100万トークンのコンテキストで何を理解していようと、Lunaに渡るのは spec と files と acceptance だけ。 Fableが「当然わかっているだろう」と思って書かなかったことは、Lunaにとって存在しません。

実際に事故になるのは、だいたい次のパターンです。

• 暗黙の前提：「このプロジェクトはエラーを例外でなく Result 型で返す」——Fableは会話の序盤で読んで知っているが、specに書いていない
• 知識カットオフの差：Lunaのカットオフは2026年2月。それ以降に出たライブラリのAPIは知らないので、それらしい嘘のシグネチャを書く
• 渡し漏れたファイル：型定義を渡さなかったので、Lunaが同名の型を勝手に再定義する
• 「よしなに」委譲：specが薄いと、Lunaが設計判断を代行し始める。安いモデルに一番やらせたくない仕事です

対処は3つの原則に集約できます。

そのうえで有効なのが QUESTIONS節パターン です。 Lunaに「不明点は推測で埋めず列挙して停止せよ」と指示しておくと、仕様の穴がコードのバグではなく質問リストとして返ってきます。 Fableがそれに答えて再委譲する——つまり、仕様の欠落を検出するコストが、レビューではなく委譲直後に前倒しされます。

検証ループ — 安い実装者、高い査読者

分業のもう半分はレビューです。Fable 5 はコードレビューとバグ発見のリコールが高く、 「安く大量に書かせて、高い目で見る」という構成と噛み合います。 ただし2つ、実務上の落とし穴があります。

1. 「重大な問題だけ報告して」と書いてはいけない

Fable 5 は指示を字義通りに守ります。 レビュープロンプトに「重大度の高い問題だけ」「保守的に」「些細な指摘は不要」と書くと、 バグは同じように見つけたうえで、自分で決めた基準に満たないものを黙って落とします。 結果として精度は上がるのに、測定上のリコールが下がる。 能力の劣化ではなく、指示に従った結果です。

正しい書き方は、発見とフィルタリングを分離することです。

確信が持てないものや軽微に見えるものも含め、気づいた問題をすべて報告してください。
この段階で重要度や確信度によるフィルタリングは行わないでください（後段の
検証ステップが担当します）。目的は網羅性です。後で除外される指摘を出すほうが、
本物のバグを黙って落とすよりましです。
各指摘には確信度と推定重大度を添えてください。

2. レビュー対象は差分に絞る

Lunaが生成した1,200行を丸ごとFableのコンテキストに戻すと、その1,200行は$10/1Mトークンの入力として課金されます。安く書かせた意味が消える。 レビューに渡すのは差分と、判断に必要な最小限の周辺コードだけにします。

コスト試算 — どのくらい効くのか

前提を明示したうえで概算します。あくまでモデルケースであり、 実際の値はコードベースの性質と反復回数で大きく変わります。

想定タスク：既存コードベースへの中規模機能追加。 実装の反復（生成 → テスト → 修正）が8ラウンド、設計とレビューが4ラウンド。 実装1ラウンドあたり入力50k・出力12kトークン、設計/レビュー1ラウンドあたり入力30k・出力5kトークンとします。

同じトークン量で $11.00 → $2.40、約4.6分の1。 トークンの総量は変えず、単価の高い枠から低い枠へ移し替えただけです。 さらにLunaは低レイテンシ設計なので、反復ラウンドの体感速度も上がります。

この試算には、分業のオーバーヘッド——仕様書を書くための出力トークン、 差分をレビューするための入力トークン——が含まれています（設計/レビューの4ラウンド分がそれです）。 オーバーヘッドを払ってなお効くのは、単価差が数十パーセントではなく数十倍だからです。 逆に言えば、単価差が2〜3倍のモデル間で同じことをやっても、往復コストで相殺されて終わります。

やってはいけない分け方

難しい仕事をLunaに投げる

最も基本的な失敗です。仕様が確定しない仕事をLunaに投げると、往復が増え、 そのたびにFableが差分を読み直すので、単一モデルより高くつきます。 判断基準はシンプルで、「仕様書が書けるかどうか」です。 Fableが自己完結の仕様書を書けないなら、それはまだFableの仕事——調査か、設計か、ユーザーへの確認が足りていない。

Lunaの出力をそのままユーザーに見せる

分業構成では、ユーザーとの接点はオーケストレーター1つに保つべきです。 Lunaの出力をそのまま流すと、文体も判断基準も混ざり、 「誰が何を決めたのか」が追えなくなります。受け入れ判定を通ったものだけをFableの言葉で返す。

Fableがレビュー中に自分で直し始める

Fable 5 は自律性が高いので、放っておくとレビューのついでに実装を書き直します。 一見便利ですが、それは最も高い枠でコードを書いているということです。 システムプロンプトで「自分ではコードを書かず、修正はimplementに再委譲する」と明示しておく必要があります。

計測せずに運用する

分業が効いているかは、必ず数字で確認してください。usage.input_tokens / output_tokens をFable側・Luna側それぞれで積算し、 「Fable側の入力トークンが想定より膨らんでいないか」を見ます。膨らんでいれば、 ほぼ確実に委譲の戻り値を絞りきれていません。

まとめ

この構成の要点を3つに畳むと、次のようになります。

1. 分業の原資は単価差の非線形性。Lunaの能力はFableより数ポイント低いだけで、価格は数十分の一。難易度とトークン量が逆相関しているので、難易度で切ると自然にコストが分離される
2. ツール境界＝コンテキスト境界。Fableが知っていて仕様書に書かなかったことは全部バグになる。specの自己完結性・検証可能な受け入れ基準・設計判断の禁止、この3つで境界を守る
3. コスト逆転を監視する。委譲の戻り値を絞らないと、単価差はレビュー入力に食い潰される。レビューは差分に対して行い、指示にはリコールを落とす言葉（「重大な問題だけ」）を書かない

そして運用上の判断基準は、たった一行です。仕様書が書ける仕事だけをLunaに投げる。書けないなら、それはまだFableの仕事。

参考リンク

• GPT-5.6 Luna Model — OpenAI API Docs（単価・コンテキスト長・カットオフ・対応エンドポイント）
• Advancing the price-performance frontier with GPT-5.6 — OpenAI（GPT-5.6ファミリーの発表、2026年7月9日）
• OpenAI cuts GPT-5.6 Luna prices by 80% — VentureBeat（2026年7月30日の値下げ）
• Claude Fable 5 and Claude Mythos 5 — Anthropic
• Model Migration Guide — Anthropic（Fable 5固有のAPI差分、レビュー時のリコール低下、refusalとフォールバック）
• Tool use overview — Anthropic（カスタムツール定義とTool Runner）