AIモデルは数か月単位で入れ替わる。ベンダーに縛られたままでは、開発現場が止まるリスクを抱え続けることになる。
本記事では、Shopifyが構築したLLMプロキシと自動フェイルオーバー、蒸留パイプライン、利用監視の仕組みを整理する。エンタープライズのAI導入で押さえるべき設計の考え方がわかる。
この記事でわかること
- LLMプロキシがモデル切替とコスト管理をどう担うか
- 蒸留で速度・コスト・精度をどう両立しているか
- 利用ダッシュボードとサーキットブレーカーで何を防ぐか
モデルは消える前提で設計する
LLM（大規模言語モデル）の提供元は、性能向上のたびにモデルを更新・廃止する。Claude Fable 5の提供終了は、その典型例だ。Shopifyのエンジニアリング責任者Farhan Thawar氏は、VentureBeatのポッドキャスト「Beyond the Pilot」で、同社がこの前提をどう受け止めているかを語っている（参考）。
多くの企業は特定ベンダーのAPIに直結したまま運用する。モデルが消えた瞬間、社内のツール連携やエージェントが一斉に止まる。Shopifyは2024年から「コードはAIと共に書かれる」という前提でインフラを整え、2026年時点ではLLMプロキシを中核に据えた。
LLMプロキシが担う自動フェイルオーバー
Shopifyは全エンジニアのAIリクエストを社内LLMプロキシに集約している。トークンは一括購入し、OpenAI・Anthropic・Googleなど複数プロバイダへルーティングする。いずれかのモデルがダウンしたり廃止されたりしても、プロキシが別モデルへ自動切替する。
Claude Fable 5終了時、Shopifyのエンジニアは手動で設定を変える必要はなかった。プロキシがClaude OpusやGPT 5.5へ切り替え、作業を継続した。Thawar氏は「モデルが来ては消える。アップデートだけでも同じ」と述べ、複数プロバイダへリクエストを分散できる仕組みの価値を強調している。
フロントエンドの開発ツールは固定していない。Claude Code、Codex、Cursor、GitHub Copilot for VS Codeなど、エンジニアが選んだハーネス（AIを動かす実行環境）をそのまま使える。標準化したのはツールではなく、その下のプロキシ層だ。
蒸留でサブタスクを小型モデルへ移す
プロキシだけではコストとレイテンシの課題は残る。Shopifyは蒸留（distillation）を第2の柱に置いている。教師モデルの出力から生徒モデルを学習させ、用途を絞ったSLM（小型言語モデル）を作る手法だ。
EC向けAIアシスタントSidekickは、店舗運営の細かいサブタスクを担う。汎用の大規模モデルを常時使うより、蒸留済みの小型モデルの方が速く安い場面がある。Thawar氏によると、用途次第で2倍の速度・コスト改善にとどまることもあれば、最大30倍に達することもある。ただし「コストとレイテンシだけではない。精度が本質だ」とも語っている。
エンジニアは蒸留パイプライン（社内ではUDPと呼ばれる）に教師モデル、学習データ、評価セット、ターゲットモデルを渡す。例としてOpus 4.8からQwen 3.5への蒸留が挙げられている。パイプラインはおよそ1日で完了し、速度・コスト・精度の評価結果が返る。トレードオフが許容範囲なら、承認プロセスなしでデプロイできる。
実験の可視化には社内プラットフォームTangleを使う。Shopify公式エンジニアリングブログでは、Flow自動生成タスクでQwen3-32Bを微調整した事例が公開されている。フロンティアモデル比で2.2倍速く、コストは68%削減され、精度も上回ったと報告されている（参考）。
Thawar氏の次の目標は、ターゲットモデルを人が指定せず、パイプライン自身が最適な生徒モデルを提案することだ。「スマホで動くほど小さいモデルが選ばれるかもしれない。逆に、フロンティア級を超えられないと判断されることもある」と語っている。
利用ダッシュボードとサーキットブレーカー
トークンを無制限に使える環境では、使い方の偏りが見えにくい。Shopifyは利用ダッシュボードを導入し、単なる支出だけでなく次の問いに答えられるようにした。
- 最も高価なトークンを誰が使っているか
- 推論（reasoning）に時間をかけているのは誰か
- 職種やレベルごとにどのモデルが選ばれているか
「tokenmaxxing」と呼ばれる過剰消費への対策として、サーキットブレーカー（circuit breaker）も設置している。モデルが長時間（例：10時間）動き続け、大量のトークンを消費している場合、ユーザーに「この支出を意図したか」と通知する。意図的な長時間実行ならそのまま続行し、バックグラウンドで忘れていた処理なら即停止できる。
Shopifyは従来の分散システム向けにSemianというサーキットブレーカーライブラリを公開してきた。今回のAI基盤でも、障害や異常消費を早期に遮断する発想は同じだ。単一プロバイダへの依存を避けるプロキシと、異常利用を止めるブレーカーは、セットで効く。
エージェント基盤AquiferとRiver
https://shopify.engineering/under-the-river
エンジニア向けの社内エージェントRiverは、Slack上でコード閲覧・テスト実行・PR作成を担う。Shopify公式ブログによると、直近30日間で約5.9万セッションが走り、マージされたPRの8分の1がRiverの共著になっている（参考）。
Riverの下にはエージェント基盤Aquiferがある。セッション（会話の永続ログ）、ハーネス（モデル呼び出しループ）、サンドボックス（コード実行環境）を分離する設計だ。ハーネスとサンドボックスを切り離すことで、モデルやランタイムを差し替えても会話と作業状態を維持できる。Thawar氏が語る「AI reflexivity（反射的なAI利用）からAI leverage（AIを武器として使う）へ」という転換は、この基盤の上で進んでいる。
他社が参考にできる設計原則
Shopifyの事例から、規模を問わず応用できる原則が3つ見える。
インフラを先に作る。 Thawar氏は「これまでも、これからもインフラを増やし続ける」と述べている。機能より先にルーティング・観測・フェイルオーバーを整える。
モデル選定をプロキシ層に閉じ込める。 エンジニアは好きなツールを使い、切替判断は中央で行う。ベンダーロックインを個人の設定変更コストにしない。
蒸留と監視をセットにする。 安いモデルへ寄せる判断は評価データに基づく。同時に、異常なトークン消費はダッシュボードとサーキットブレーカーで止める。
AIモデルの寿命は短い。だからこそ、どのモデルが生き残るかに賭けず、切り替えられる基盤を先に敷く。ShopifyのLLMプロキシは、その方針を具体化した実例だ。