合同会社小村ソフト
日本語 English 한국어 繁體中文 العربية
相談する
メニュー

Fableが使えなくなったけど諦めるな ── OpenRouter Fusion＋中華LLM＋レビュー層で凌ぐ

· · AI, LLM, OpenRouter, Claude, ChatGPT, DeepSeek, プロンプトエンジニアリング, 開発効率化, ツール紹介

1. Fableが死んだ。さて困った

正直に申し上げます。Fableには遠く及びません。

本稿執筆時点で、Anthropicが提供していたAIコーディングエージェント「Fable」はサービスを終了しています。あの精度、あの速度、あの統合感。あれを超える代替は、いまのところ存在しません。

とはいえ、手をこまねいているわけにもいきません。代わりを探すと、選択肢は次のような顔ぶれです。

  • Claude Code / Claude Sonnet：賢い。でも単体ではFableの精度に届かず、料金もかさみます
  • GPT-5 / GPT-5.5：意外とポンコツです。長いコードベースを扱うとすぐに息切れします。しかも高い
  • Cursor / Windsurf：体験は良いですが、バックエンドのモデル次第です。自由な構成はできません
  • ローカルLLM（Ollama等）：速度は出ますが、実リポジトリを渡すと精度がガクッと落ちます

で、あれこれ試した末にたどり着いたのが、OpenRouterのFusion機能＋中華LLMでコードを生成し、仕上げに gpt-5.5-proのレビュー または CodexのPRレビュー を通す構成です。Fableにはまったく敵いませんが、素のgpt-5.5よりはずっとマシです。それなりに使えます。

ただし、中華LLMなので仕事のコードを食わせるのはさすがに怖いです。あくまで趣味プロジェクトや個人開発の範囲で使う前提です。

2. OpenRouter Fusionとは

OpenRouterは、複数のLLMプロバイダを統一的に呼び出せるAPIゲートウェイです。ClaudeもGPTもGeminiもDeepSeekも、全部同じインターフェースで使えます。

そのOpenRouterに「Fusion」という機能があります。

これは簡単に申しますと、1つのプロンプトを複数のモデルに投げ、その回答を分析したうえで、最終的な出力を1つのモデルがまとめる仕組みです。いわば「モデルたちの合議制」です。

具体的には、次のような流れで動きます。

  1. ユーザーがプロンプトを入力する
  2. analysis_models に指定した複数のモデルが 同時に 同じプロンプトに対して回答を生成する
  3. それらの回答を model に指定したモデルが比較・分析し、合意点・矛盾点・抜け漏れ・盲点などを構造化する（= judge の役割）
  4. 続けて、同じモデルがその分析を踏まえて最終的な回答を書く

重要なのは、各分析モデルに別々の役割やプロンプトを与えることはできないという点です。全モデルが同じプロンプトを受け取り、それぞれ独立に回答し、その差分を judge が評価する——というシンプルな仕組みです。

opencodeというCLIコーディングエージェントは、このFusionをプラグインとしてネイティブサポートしています。opencode.jsonに設定を書くだけで、複数モデルが協調してコードを生成・レビューするエージェントが手に入ります。

3. 実際の設定

以下が、いま私が使っているopencode.jsonの核心部分です。

{
  "model": "openrouter/openrouter/fusion",
  "provider": {
    "openrouter": {
      "models": {
        "openrouter/fusion": {
          "name": "OpenRouter Fusion (Custom DeepSeek V4 Pro)",
          "options": {
            "plugins": [
              {
                "id": "fusion",
                "analysis_models": [
                  "xiaomi/mimo-v2.5-pro",
                  "z-ai/glm-5.1",
                  "deepseek/deepseek-v4-pro",
                  "moonshotai/kimi-k2.7-code",
                  "minimax/minimax-m3"
                ],
                "model": "deepseek/deepseek-v4-pro",
                "max_tool_calls": 8
              }
            ]
          }
        }
      }
    }
  }
}

5つの分析モデルと1つの実行モデルで構成されています。

分析モデル（全員が同じプロンプトを見て、同時に回答する）

モデル 開発元 特徴
xiaomi/mimo-v2.5-pro Xiaomi（小米） 中国最大級のスマホメーカー謹製。コストパフォーマンスが非常に高い
z-ai/glm-5.1 智譜AI（Zhipu AI） 清華大学発。中国語圏のベンチマークで上位常連。論理推論に強い
deepseek/deepseek-v4-pro DeepSeek（深度求索） いわずと知れた中国発の破壊的LLM。コーディング性能が突出
moonshotai/kimi-k2.7-code Moonshot AI（月之暗面） コード生成特化モデル。長文コンテキスト処理に定評
minimax/minimax-m3 MiniMax（稀宇科技） マルチモーダル・長文処理で評価急上昇中の新鋭

実行モデル（分析結果を踏まえて最終回答を書く）

  • deepseek/deepseek-v4-pro：分析モデルたちの回答を踏まえて、実際のコード生成・ファイル編集を担当します。

なぜ中華LLMなのか

単純にコストパフォーマンスが圧倒的だからです。

2026年現在、中国発のLLMはAPI価格がAnthropicやOpenAIの1/5〜1/20で、性能は同等かそれ以上です。特にDeepSeek V4 Proのコーディング性能は、実務レベルでClaude SonnetやGPT-5.5と互角かそれ以上に感じる場面が少なくありません。

4. どう動くのか ── Fusionだけでは足りない

Fusion単体のフローはこうです。

  1. ユーザーがプロンプトを入力
  2. 5つの分析モデルがそれぞれ独立に回答を生成
  3. 実行モデル（DeepSeek V4 Pro）がそれらの回答を比較・分析し、合意点・矛盾点・抜け漏れを抽出した構造化分析を生成する
  4. その分析を踏まえて、同じ実行モデル（DeepSeek V4 Pro）が最終的なコードを生成する

これは人間のチーム開発に近いです。5人のエンジニアが同じ仕様を見て各自レビューコメントを出し、1人（DeepSeek V4 Pro）がそれを分析・整理したうえで実装する——そんなイメージです。

コンテキストウィンドウの制限について： Fusionのコンテキストウィンドウは128Kトークンです。一見すると少ないように見えますが、会話履歴に加えて5モデル分の回答すべてを含める必要があるため、意外とすぐに埋まります。ただし、慌てる必要はありません。128Kを超えてFusionの合成ステップが失敗しても、各分析モデルは個別に（DeepSeek V4 Proは100万トークン、Kimi K2.7は約26万トークンなど、それぞれ十分大きなコンテキストウィンドウで）プロンプトの処理を終えています。opencodeもセッション全体の会話履歴を保持しているため、モデルの「記憶」が失われるわけではありません。実用上の大きな支障にはならない、というのが実際の感触です。

ですが、これだけではFableにはまったく届きません。何しろFableは単一モデルでありながら、複数モデル合議制を軽く凌駕する精度を出していました。Anthropicの底力です。

そこで、Fusionの出力にさらにレビュー層を一つ噛ませます。選択肢は二つです。

選択肢A：gpt-5.5-proによるコードレビュー

  1. Fusion構成でコード生成
  2. 生成されたコードをgpt-5.5-proに「レビューして修正案を出せ」と投げる
  3. その修正案を元の実行モデルに適用させる

gpt-5.5-proは単体のコード生成ではポンコツですが、既存コードのレビューは意外と得意です。

選択肢B：GitHub CodexのPRレビュー

  1. Fusion構成でコード生成
  2. PRとして出し、GitHub CodexのPRレビューに通す
  3. Codexがバグの可能性や設計上の懸念を指摘してくるので、それを反映する

CodexはGitHubの文脈（Issue、過去のPR、プロジェクト構造）を踏まえたレビューをするため、汎用LLMレビューとは違う視点で突っ込んできます。

どちらか一方で十分です。Fusion（5モデル合議）→ レビュー（gpt-5.5-pro または Codex）の二段構え。Fable一発には遠く及ばない分、プロセスでカバーする発想です。

素のgpt-5.5でやらかすライブラリのバージョン間違いや存在しないAPIの使用は、この構成でかなり減りました。

5. 速度と実用性

速度自体は単一モデルと大して変わりません。5モデル並列で動きますので、生の応答時間は許容範囲です。

問題は精度です。Fableなら一発で通るところを、この構成だと何度か手戻りが発生します。結果として、トータルの開発時間はFableより明らかに遅いです。間違える分だけ遅くなります。

ただし、素のgpt-5.5よりはずっとマシです。Fusion＋レビューで生成されたコードは初回からそこそこ正解に近く、gpt-5.5単体で生成→修正→修正→修正の無限ループに陥るよりは確実に早いです。

体感としては、「スピードは悪くない。Fableには精度で遠く及ばないが、素のgpt-5.5よりは数段マシ」という塩梅です。

6. おまけ：レビュー層とそのほかのopencode設定

レビュー層：gpt-5.5-pro または Codex PRレビュー

Fusion構成だけでは心もとないので、どちらか一方をレビュー層として使います。

gpt-5.5-pro：opencodeのtask機能でサブエージェントに指定し、生成されたコードを「レビューして修正案を提案せよ」と指示します。ゼロからコードを書かせると微妙ですが、他人の書いたコードの粗探しは妙に得意です。

GitHub Codex：PRを出すタイミングでCodexのPRレビューを走らせます。プロジェクト全体の文脈を踏まえたレビューをしてくれる点が、汎用LLMレビューとは一味違います。

どちらを使うかは気分次第です。両方はさすがにやりすぎで遅すぎます。

そのほかの設定

opencode.jsonには、Fusion以外にも実用的な設定をいくつか入れています。

{
  "permission": {
    "read": "allow",
    "glob": "allow",
    "grep": "allow",
    "task": "allow",
    "webfetch": "allow",
    "websearch": "allow",
    "lsp": "allow",
    "edit": "allow",
    "bash": {
      "*": "allow",
      "Remove-Item *": "deny",
      "del *": "deny",
      "rm *": "deny",
      "rmdir *": "deny",
      "rd *": "deny",
      "erase *": "deny",
      "git clean *": "deny"
    }
  },
  "experimental": {
    "primary_tools": ["task"]
  }
}

ポイントは2つです。

1. 削除系コマンドのブロック

Remove-Item、del、rm、rmdir、rd、erase、git cleanを明示的に拒否しています。AIエージェントにファイル削除を任せるのは怖いからです。どうしても削除が必要なときは自分でやります。

2. primary_tools: ["task"]

サブエージェント（task）による並列探索を優先させています。大きなコードベースで複数ファイルを同時に読んだり検索したりするとき、task経由のほうが圧倒的に速いです。

7. まとめ

Fableの終了は痛いです。本当に痛いです。あれを超えるものは今のところありません。

ですが、手をこまねいている場合ではないので、OpenRouter Fusion＋中華LLMで生成し、gpt-5.5-pro または Codex PRレビューで仕上げる構成で凌いでいます。

この構成の要点：

  • OpenRouter Fusionで5モデルの「合議制」によるコード生成
  • 分析モデル：Xiaomi Mimo / GLM / DeepSeek / Kimi / MiniMax
  • 実行モデル：DeepSeek V4 Pro
  • 仕上げのレビュー層：gpt-5.5-pro または Codex PRレビュー（どちらか一方）
  • 速度は単一モデル並み。ただしFableより精度が落ちる分、手戻りで遅くなります
  • 素のgpt-5.5よりはずっとマシ。Fableには遠く及ばないが、実用には耐えます
  • 中華LLMなので仕事のコードには使いにくい。趣味・個人開発まで

AIコーディングエージェントで「Fableロスがつらい」「素のgpt-5.5がポンコツすぎる」と感じている方は、繋ぎとして試す価値はあります。

OpenRouterのアカウントさえあれば、今日から使えます。

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。

お問い合わせ
ブログ一覧に戻る