AIエージェントをAPIで調達するだけでは、差別化にならない。Shopifyは自社ECプラットフォームの自動化機能「Shopify Flow」向けのAIエージェントを、Qwen3-32BのファインチューニングによってAPIサービスからの脱却を果たした。結果は2.2倍速・68%安・精度向上だ。2026年4月に公開したエンジニアリングブログで、その全工程が公開されている。
この記事でわかること：
- 本番データなしでトレーニングデータを集めた方法
- JSON DSLを捨ててPythonを中間表現に選んだ理由と効果
- ベンチマーク合格後に35%の品質ギャップが発覚した原因と対処法
- 週次で回るフライホイールの仕組み
ShopifyのAIアシスタント「Sidekick」は、自然言語からFlowワークフローを生成する機能を持つ。Shopify Flowはストアオーナーがトリガー・条件・アクションを組み合わせて注文処理や顧客対応を自動化するプラットフォームだ。
かつてこのFlow生成機能はフロンティアモデルへのAPI呼び出しで動いていた。「APIキーさえあれば誰でも同じことができる」という限界から、自社データと独自のトレーニングサイクルによる差別化へ方針を転換した。
コールドスタートを逆算で解決した
最初の課題はトレーニングデータの収集だ。機能はまだ本番稼働していないため、会話ログが一切ない。
Shopifyはこの問題を逆算で解決した。すでにストアオーナーが何千件ものFlowワークフローを手動で作っていた。そのワークフローをサンプリングし、強力なLLMに「このワークフローを作りたいユーザーはどんな言葉でリクエストするか」を生成させた。さらに「理想のエージェントがこのワークフローを作るまでのツール呼び出しシーケンス」を構築し、合成トレーニングデータとした。
本番機能なしに始める場合、ユーザーがすでに手動で作っている成果物から逆算するのが現実的な第一歩になる。
JSONでなくPythonを選んだ理由
Shopify FlowのワークフローはJSONベースのDSL（ドメイン固有言語）で管理される。バックエンドシステムとの連携には最適だが、LLMに学習させるには問題がある。条件分岐やループなどのプログラムロジックが深いネスト構造のJSONに埋め込まれており、LLMの事前学習データにこのパターンはほとんど含まれない。
解決策は、Flowワークフローを一度Pythonに変換してからモデルに学習させることだ。
Pythonで表現するとデコレータ・if/else・for文・関数呼び出しになる。これらはLLMが最も多く学習してきた構文だ。同じ学習データのまま表現形式だけをJSONからPythonに切り替えると、構文正確性が22ポイント・意味的正確性が13ポイント向上した。
実装にはJSON↔Pythonの双方向トランスパイラが必要だった。推論時はモデルがPythonを出力し、トランスパイラがFlowのJSONに変換してバックエンドへ渡す。ストアオーナーはPythonを見ることなく、バックエンドもPythonを直接解釈しない。Pythonはモデルの内部言語として機能する。
本番環境との一致が精度を左右する
表現形式の問題と並行して、学習データと本番環境の細かい差異が精度を下げていた。
ツール名が一例だ。学習データでは flow_app_agent_task_search というフルネームで記載していたが、本番APIは task_search と略称で返す。機能は同一でも、モデルは別のツールとして認識して精度が低下した。ツール名を本番に揃えると改善した。
ほかにもツールレスポンスのJSONキー順序、ツールのリスト順序、システムプロンプトの文言など、あらゆる差異が影響した。モデルはすべてのトークンをシグナルとして扱う。本番システムが更新されるたびに学習データも更新する必要がある。
ベンチマーク合格後に35%のギャップが発覚した
オフラインベンチマークで合格水準に達したあと、本番流入の1%に切り替えた。
ここで想定外の結果が出た。ストアオーナーがFlowワークフローを実際に有効化する割合が、フロンティアモデルより35%低かった。
原因はベンチマークが想定通りの質問しかカバーしていなかったことだ。実際のユーザーはワークフローの編集、メール設定、サードパーティ連携、そしてフローを作る意図なしにFlowについて質問するケースも多い。こうしたアウトオブディストリビューションな要求に、モデルが対応できていなかった。
対応策としてLLMベースのジャッジを構築した。各会話を「ユーザーの意図を正しく把握したか」「適切なコンポーネントを選んだか」「次のアクションが明確か」など複数の観点で個別評価する。人間のアノテーションで精度を校正し、本番の有効化率との相関を確認した。
ジャッジの分析でメールワークフロー関連が失敗の25%を占めていることが判明し、そのカテゴリの学習データを優先的に追加した。ワークフロー編集のケースも合成データには含まれていなかったため追加した。2週間でギャップを埋めた。
週次で回るフライホイール
現在は毎週、本番会話を取り込んで再学習するサイクルが自動で動いている。
LLMジャッジが各会話をスコアリングし、高品質な例をトレーニングプールへ、低品質なものをレビュー待ちに振り分ける。タグ付けシステムがワークフローのトリガー・条件・アクション・サードパーティ連携の有無を分類し、スライス別の精度を監視する。問題のある領域を特定した上で、重点的に学習データを追加できる体制だ。
学習インフラはH200 GPUを2ノード使ったFSDP（Fully Sharded Data Parallel）構成で、Qwen3-32Bのフルトレーニングが12時間で完了する。週次再学習が現実的なスピードだ。データ収集からデプロイまでのパイプライン全体は、ShopifyのオープンソースML実験基盤「Tangle」が管理する。
どんな状況に同じ手法が使えるか
Shopifyはこのアプローチが汎用化できる条件を3点挙げている。ツール呼び出しが必要なタスクであること、出力形式が自社DSLであること（かつそのセマンティクスをモデルが知っている言語で表現できること）、そして本番フィードバックループが得られること。この3つが揃う場面であれば、同じ手法が再現できるとしている。Sidekick内では同じレシピが他のスキルにも展開されている。
まとめ
AIエージェントの品質は、今後もフロンティアモデルの追い上げを受け続ける。Shopifyが示したのは、その競争に自社データと再学習サイクルで応戦する一つの型だ。Pythonを中間表現にする手法・本番環境との完全一致・フライホイールによる継続改善のいずれも、自社が持つデータがあって初めて機能する。API依存を脱した側が出せる速度・コスト・精度の優位性は、自社固有のデータが積み上がるにつれてさらに広がる。