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

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

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

本稿執筆時点で、Anthropicの最上位モデル「Fable」は、定額のサブスクリプションの枠内では使い続けられなくなりました。あの精度、あの速度、あの統合感。あれを超える代替は、いまのところ存在しません。

Fableとは何か ── 前提の整理

Fableを知らない方のために、前提を整理しておきます。

Fableは、Anthropicが2026年6月9日に発表した最上位モデル Claude Fable 5 のことです。公式アナウンスによれば、次のような位置づけになります。

提供形態も同じアナウンスに書かれています。Claude APIと従量課金のEnterpriseプランでは発表と同時に利用可能、一方でサブスクリプションプランでは2026年6月22日までは追加費用なしで含まれ、それ以降は容量が確保できるまでusage creditsが必要、という扱いです。

つまり、モデルが消えたわけではありません。定額のサブスクリプションの枠内で、これまでと同じように使い続けられなくなったというのが実態です。本記事が代替構成を探しているのは、あくまでこの「定額の枠内で」という条件のもとでの話です。APIに従量課金で繋げる予算があるなら、素直にFableを使うほうが早いです。

失われたのはモデルそのものというより、「1つのモデルに投げれば通る」という体験のほうです。以降で組む構成は、これを複数モデルの合議とレビュー層で近似しようとするものだと考えてください。

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

• 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なので仕事のコードを食わせるのはさすがに怖いです。あくまで趣味プロジェクトや個人開発の範囲で使う前提です。何がどう怖いのかは、3章の「中華LLMに何を渡すのか」で分解します。

この記事の評価の読み方

先にお断りしておきます。本記事に出てくる「ポンコツ」「同等かそれ以上」「ずっとマシ」といった評価は、すべて筆者が自分の作業で使ってみた体感です。標準ベンチマークのスコアや、条件を揃えた比較実験にもとづくものではありません。以降、断りのない評価はすべて体感だと思って読んでください。

客観的に確かめられるのは料金くらいで、それも変動します。各モデルの現在の単価はOpenRouterのモデル一覧で確認できます。採用を検討する場合、価格は必ずご自身で突き合わせてください。

裏を返せば、体感でよければこの構成は今日から試せます。以降は、そういう記事として読んでいただければと思います。

この記事の知識マップ

Anthropicの最上位モデルClaude Fable 5が定額サブスクリプションの枠内では使い続けられなくなったことを受け、CLIコーディングエージェントopencodeでOpenRouter Fusionを使い、Xiaomi MiMo・GLM・Kimi・MiniMax・DeepSeek V4 Proという5つの中華LLMに同じプロンプトを投げて合議させ、DeepSeek V4 Proが分析結果の統合と最終的なコード生成を担う構成を組む。この出力にgpt-5.5-proによるレビューまたはGitHub CodexのPRレビューをどちらか一方重ねて精度を補う。OpenRouterは学習利用・ログ保持・データ越境といったプロバイダ側のデータポリシーを構造化情報として持ち、Zero Data RetentionエンドポイントへのルーティングやEU内処理ルーティングで制御できるが、業務で個人情報を渡す場合は個人情報保護法上の外国にある第三者への提供に該当し得る点への注意も必要になる。

flowchart LR
    accTitle: OpenRouter Fusionと中華LLMによるコーディングエージェント構成の知識マップ
    accDescr: opencodeがOpenRouter Fusion経由で複数の中華LLMを合議させてコードを生成し、レビュー層とデータポリシーの制御を組み合わせる関係を示す図。
    openrouter_fusion["OpenRouter Fusion"]
    opencode["opencode"]
    openrouter["OpenRouter"]
    xiaomi_mimo["Xiaomi MiMo"]
    zhipu_glm["GLM(智譜AI)"]
    moonshot_kimi_k2["Kimi(Moonshot AI)"]
    minimax_m3["MiniMax M3"]
    deepseek_v4_pro["DeepSeek V4 Pro"]
    claude_fable_5["Claude Fable 5"]
    gpt_5_5_pro["gpt-5.5-pro"]
    github_codex_pr_review["GitHub CodexのPRレビュー"]
    zero_data_retention["Zero Data Retention(ZDR)"]
    llm_provider_data_policy["推論プロバイダのデータポリシー"]
    eu_data_residency_routing["EU内処理ルーティング"]
    personal_data_cross_border_transfer["外国にある第三者への個人情報の提供"]
    opencode -->|"利用する"| openrouter
    opencode -->|"利用する"| openrouter_fusion
    openrouter_fusion -->|"前提とする"| openrouter
    openrouter_fusion -.->|"利用する"| xiaomi_mimo
    openrouter_fusion -.->|"利用する"| zhipu_glm
    openrouter_fusion -.->|"利用する"| moonshot_kimi_k2
    openrouter_fusion -.->|"利用する"| minimax_m3
    openrouter_fusion -.->|"利用する"| deepseek_v4_pro
    openrouter_fusion -->|"軽減する"| claude_fable_5
    opencode -.->|"利用する"| gpt_5_5_pro
    opencode -.->|"利用する"| github_codex_pr_review
    opencode -->|"で構成できる"| openrouter
    openrouter -->|"で構成できる"| zero_data_retention
    zero_data_retention -.->|"軽減する"| llm_provider_data_policy
    openrouter -->|"利用する"| llm_provider_data_policy
    openrouter -->|"で構成できる"| eu_data_residency_routing
    llm_provider_data_policy -.->|"原因になり得る"| personal_data_cross_border_transfer
    openrouter_fusion -.->|"原因になり得る"| personal_data_cross_border_transfer

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全18件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

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の導入とOpenRouterの接続

設定ファイルの中身に入る前に、そこにたどり着くまでの手順をまとめておきます。

1. opencodeを入れる

curl -fsSL https://opencode.ai/install | bash

パッケージマネージャからでも入ります。Windowsでは、公式ドキュメントでWSLの利用が推奨されています。

npm install -g opencode-ai            # Node.js
brew install anomalyco/tap/opencode   # macOS / Linux
scoop install opencode                # Windows

2. OpenRouterのAPIキーを登録する

OpenRouterのダッシュボードで Create API Key からキーを作ります。次に、作業したいディレクトリでopencodeを起動し、/connectを実行してプロバイダ一覧からOpenRouterを選び、キーを貼り付けます。

cd /path/to/project
opencode

/connect

登録したキーは~/.local/share/opencode/auth.jsonに保存されます。設定ファイルに直接書く必要はありませんし、書かないでください。

3. opencode.jsonを置く

設定ファイルの置き場所は主に2か所です。

両方ある場合はマージされ、キーが衝突したときだけプロジェクト側が優先されます。次に示すFusionの設定は、どちらに書いても動きます。私は常用しているのでグローバル側に置いています。なお、ファイルの先頭に"$schema": "https://opencode.ai/config.json"を入れておくと、エディタで補完と検証が効きます。

4. プロジェクトを初期化する

/init

opencodeがプロジェクトを解析してAGENTS.mdを作ります。このファイルはGitにコミットしておくことが推奨されています。プロジェクトの構造やコーディングの癖を踏まえた出力になります。

Fusionの設定

以下が、いま私が使っている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つの実行モデルで構成されています。

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

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

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

なぜ中華LLMなのか

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

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

ただし、この「1/5〜1/20」も「同等かそれ以上」も、1章で断ったとおり筆者が使った範囲での感触です。価格はモデルとプロバイダによって幅があり随時変わるので、OpenRouterのモデル一覧で実際の単価を突き合わせてから判断してください。性能のほうも、公開ベンチマークで裏を取ったものではありません。

中華LLMに何を渡すのか ── 業務利用の判断基準

1章で「仕事のコードを食わせるのは怖い」と書きました。漠然と怖がっていても判断できないので、何が起きうるのかを項目に分解しておきます。

注意点として、ZDRの強制が効くのは推論リクエストのルーティングだけです。Web検索のようなプラグインやツールは第三者のサービスが動かしており、それぞれのデータ保持ポリシーに従います。有効にするツールのポリシーは別途確認してください。

そのうえで、業務で使えるかどうかは次の順で考えると整理しやすくなります。

1. 渡すものを分ける。 秘密保持契約や委託契約の対象になっているコード、仕様書、顧客データは渡さない。渡すのは自分に権利がある範囲か、すでに公開されている範囲に限る。この線引きが引けないなら、その先を検討する意味はありません。
2. 契約を確認する。 受託開発なら、多くの場合「再委託の可否」や「情報の外部持ち出し」の条項があります。外部のLLMサービスに送る行為がこれに当たるかは、自己判断ではなく発注元と合意しておくべき事項です。個人情報が混ざる場合は、個人情報保護法上の「外国にある第三者への提供」に当たる可能性があるため、個人情報保護委員会のガイドライン（外国にある第三者への提供編）に沿った確認も必要になります。
3. 設定で塞ぐ。 1と2をクリアしたうえで、上の表の学習利用・ログ保持・越境を設定で塞ぎます。
4. 記録を残す。 どのモデルに何を渡す運用にしたのかを書き残しておきます。あとで説明を求められたときに効きます。

本記事の構成は、この1の段階で「趣味プロジェクトと個人開発に限る」と割り切ったものです。業務で使いたい場合は、少なくとも2と3を通してからにしてください。

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. その修正案を元の実行モデルに適用させる

実際には、opencodeのtask機能でサブエージェントとしてgpt-5.5-proを指定し、「レビューして修正案を提案せよ」と指示する形になります。

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レビュー）については4章で書いたとおりです。ここではそれ以外の設定を扱います。

そのほかの設定

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なので仕事のコードには使いにくい。趣味・個人開発まで（判断の手順は3章の表を参照）
• 上の評価はいずれも筆者の体感です。料金はOpenRouterのモデル一覧で確認してください

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

OpenRouterのアカウントを作り、3章のセットアップ手順どおりにopencodeを入れれば、今日から試せます。

参考リンク

• OpenRouter: Fusion plugin
• OpenRouter: Fusion Router
• OpenRouter: OpenCode integration
• OpenRouter: Provider Logging ── プロバイダごとの学習利用・データ保持ポリシーと、その絞り込み設定
• OpenRouter: Zero Data Retention ── ZDRエンドポイントだけにルーティングする設定と、その適用範囲
• OpenRouter: Models ── 各モデルの現在の単価
• opencode: Intro ── インストールと/initまでの手順
• opencode: Providers ── OpenRouterの接続手順と認証情報の保存場所
• opencode: Config ── 設定ファイルの置き場所とマージ順序
• GitHub Codex: PR review
• Anthropic: Claude Fable 5 and Claude Mythos 5 ── Fableの位置づけ、料金、提供形態の一次情報
• 個人情報保護委員会: ガイドライン（外国にある第三者への提供編） ── 個人情報が絡む場合のデータ越境の扱い

関連する記事

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

関連トピック

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

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

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

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

OpenRouterのFusionとはどんな機能ですか？

1つのプロンプトを複数のモデルに同時に投げ、それぞれの回答を1つのモデル（judge役）が比較・分析して合意点・矛盾点・抜け漏れを構造化し、同じモデルがその分析を踏まえて最終的な回答を書く仕組みです。いわばモデルたちの合議制です。各分析モデルに別々の役割やプロンプトを与えることはできず、全モデルが同じプロンプトを受け取ります。CLIコーディングエージェントのopencodeはFusionをプラグインとしてネイティブサポートしており、opencode.jsonに設定を書くだけで使えます。

なぜ中華LLMを使うのですか？

コストパフォーマンスが圧倒的だからです。2026年現在、中国発のLLMはAPI価格がAnthropicやOpenAIの1/5〜1/20で、性能は同等かそれ以上です。特にDeepSeek V4 Proのコーディング性能は、実務レベルでClaude SonnetやGPT-5.5と互角かそれ以上に感じる場面が少なくありません。ただし中華LLMに仕事のコードを渡すのはリスクがあるため、趣味プロジェクトや個人開発の範囲で使う前提です。

Fusionだけでは足りないのはなぜですか？

5モデルの合議制でもFableの精度には届かないためです。そこでFusionの出力にレビュー層を一段追加します。選択肢は、生成コードをgpt-5.5-proにレビューさせて修正案を適用する方法と、PRとして出してGitHub CodexのPRレビューに通す方法の2つで、どちらか一方で十分です。gpt-5.5-proは単体のコード生成では性能が低い一方、既存コードのレビューは得意で、Codexはプロジェクト全体の文脈を踏まえた指摘をしてくれます。

この構成の実用性はどの程度ですか？

速度は5モデル並列で動くため単一モデルと大きく変わりません。ただし精度はFableに遠く及ばず、手戻りが発生する分トータルの開発時間は明らかに遅くなります。それでも素のgpt-5.5単体で生成と修正の無限ループに陥るよりは確実に早く、ライブラリのバージョン間違いや存在しないAPIの使用もかなり減りました。OpenRouterのアカウントがあればすぐに試せます。

著者プロフィール

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

小村 豪

合同会社小村ソフト 代表

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