Big ModelとBig Workflowsの違い｜OpenAI対LangGraph論争の要点と2026年の設計判断

Big Modelは「処理の順序や判断をモデルに任せる」設計、Big Workflowsは「処理の流れをコードで決め、その一部でLLMを呼ぶ」設計です。この2語は、2025年4月にOpenAIのエージェント構築ガイドとLangChainの反論がぶつかった論争を、AIエンジニア向けメディアLatent Spaceが名付けたものです。この記事では、両陣営の主張を一次情報で確かめ、2026年11月時点で論争がどう落ち着いたかを示したうえで、どこまでをモデルに任せ、どこからをコードで固めるかの判断基準を動くコードで説明します。

まとめ：Big ModelとBig Workflowsの要点

• 出典はLatent Spaceの記事「In the Matter of OpenAI vs LangGraph」（2025年4月20日）。「Team Big Model take the wheel」と「Team Big Workflows」の対立として整理された。
• Big Model派の根拠は、モデルが更新されるたびに手で調整したワークフローが不要になるという経験。計算資源を活かす汎用手法が最終的に勝つとしたサットン氏の「The Bitter Lesson」を、LLMの外側の設計に当てはめたもの。
• Big Workflows派の根拠は、予測可能性と、各ステップでLLMに渡す文脈をコードで制御できること。
• 二者択一ではない。ワークフローの中のLLM呼び出し1つをエージェントに置き換えても、システム全体はエージェント的に動く。
• 2026年までの製品動向から、本記事では両陣営の設計が近づいたと捉える。OpenAIはノードをつなぐAgent Builderを出したが2026年11月30日に終了予定で、LangChainは1.0でエージェントの抽象を前面に出した。
• 権限・承認ゲート・監査ログ・予算上限はコードに残し、手順の順番や再試行の仕方はモデルに任せる、という分け方が現実的。
• モデルの弱点を補うための制御は、モデルを替えるたびに評価データで「外しても正解率が落ちないか」を確かめ、落ちなければ外す。

後半では、返金問い合わせを題材に、分類・回答値の検査・回数上限をコードに残し、調査だけをエージェントに任せる構成をPythonで示し、どこまでをモデルに任せるかの判断表と、モデル更新時に制御を外せるかを確かめるコードにつなげます。

Big ModelとBig Workflowsの定義と出典

この2語は学術用語でも製品名でもありません。Latent Space（swyx氏らのニュースレター）が2025年4月20日の記事で、OpenAIとLangChainの論争を説明するために使った呼び名です。記事は対立を「Big Model take the wheel（ハンドルはモデルに任せろ）」派と、「コードを書かなければだめだ」派の対立と書き、後者を、かつてchain（チェーン）と呼ばれ今はworkflow（ワークフロー）と呼ばれる手法の支持者として「Team Big Workflows」と名付けました。

「ワークフロー」と「エージェント」の線引きは、Anthropicが2024年12月19日の記事「Building effective agents」で示した定義が広く使われています。ワークフローは「LLMとツールがあらかじめ定めたコードの経路で編成されるシステム」、エージェントは「LLMが自分の処理とツールの使い方を動的に決め、達成の仕方を自ら制御するシステム」です。Big Modelはエージェント寄り、Big Workflowsはワークフロー寄りの立場と読めば、用語の対応は取れます。

論争の発端となった3つの文書

論争の材料は、AnthropicとOpenAIのガイド、それに対するLangChain創業者Harrison Chase氏の反論です。主張の違いは「エージェントを作るべきか」ではなく、「フレームワークは何を制御すべきか」にあります。

OpenAIガイドの主張：単一エージェント優先とコード優先

OpenAIのPDF「A practical guide to building agents」は、まず単一エージェントの能力を最大化し、ツールを少しずつ足していく進め方を勧めています。そのうえで「宣言的なグラフ」を取り上げ、すべての分岐・ループ・条件をノードとエッジで事前に定義させるフレームワークは、ワークフローが動的・複雑になるにつれて扱いにくくなり、専用のDSLを覚える必要も出ると書きました。対してAgents SDKは、グラフ全体を事前に定義せず、通常のプログラミング構文で流れを書く「コード優先」だと位置づけています。名指しはしていませんが、LangGraphを念頭に置いた記述と受け取られました。

一方で同じガイドは、エージェントを優先して検討すべき条件として次の3つを挙げています。微妙な判断や例外処理を伴う意思決定（返金承認など）、ルールが膨らんで保守できなくなったシステム（取引先のセキュリティ審査など）、非構造データへの依存（保険金請求の書類読解など）です。これに当てはまらなければ「決定的な（deterministic）解決策で足りる可能性がある」とも書いており、Big Model一辺倒の文書ではありません。

LangChainの反論：問題は文脈の制御

Harrison Chase氏は同じ2025年4月20日、「How to think about agent frameworks」でガイドの記述を「misguided（見当違い）」と批判しました。反論の軸は、信頼できるエージェントを作る難しさは「各ステップでLLMに適切な文脈を渡すこと」にあり、フレームワークの価値はそれをコードで制御できる点にある、というものです。

OpenAIの比較についても、LangGraphはノードのつなぎ方こそ宣言的だが中身は普通のPython/TypeScript関数で、宣言的と命令的の混合だと指摘しました。Agents SDKのようなフレームワークは宣言的でも命令的でもなく、エージェントという「抽象」を提供しているだけで、その抽象がLLMへの入力を見えにくくする、というのがChase氏の立場です。Latent Spaceが最も説得力があったと評価したのは、「ワークフローの中のLLM呼び出しをすべてエージェントに置き換えても、エージェント的なシステムのままである」という一文でした。

Anthropicの5パターン：ワークフロー側の語彙

両者がともに引用したAnthropicの記事は、「できるだけ単純な解決策から始め、必要なときだけ複雑さを足す」ことを勧め、ワークフローの型としてプロンプトチェイニング・ルーティング・並列化・オーケストレーター・ワーカー・評価者・最適化者の5つを挙げています。このうちオーケストレーター・ワーカーは、中心のLLMが小タスクを動的に分解して配る構成です。Anthropicはこれをワークフローに分類していますが、本記事ではモデルに判断を委ねる度合いが高い構成として捉えます。段の切り方とゲートの置き方はプロンプトチェイニングの段の切り方とゲート設計で詳しく扱っています。

Big Model派の根拠：モデル更新で不要になる補助的な制御

Latent Spaceは、Big Model派の立場を「大手ラボと仕事をしていれば、何百時間もかけて手で調整したワークフローが、次のモデル更新で一夜にして無意味になるのを見てきたはずだ」と説明しています。背景にあるのは、強化学習研究者リチャード・サットン氏が2019年3月13日に書いた「The Bitter Lesson」です。同エッセイは「70年のAI研究から読み取れる最大の教訓は、計算資源を活かす汎用的な手法が最終的に最も有効で、しかも差は大きいということだ」と述べ、人間の知識を組み込む工夫は長期的に負けると論じました。原典は探索・学習と計算資源についての議論で、LLMのワークフローへの適用はBig Model派による当てはめです。

Latent Spaceは具体例として、OpenAIのDeep Research（o3を利用）やGeminiのDeep Research、Claudeを使うBoltやManusが、調査や作業の計画と実行の大部分をモデルに任せ、ワークフローの作り込みは少なかった点を挙げています。OpenAIの研究者Hyung Won Chung氏の「構造を足すと短期的には勝てるが、モデルの規模が上がると負けやすい」という講演も引用していますが、Latent Space自身が、これはモデル内部の構造についての発言を外部のシステムへ当てはめた「文脈外の引用」だと断っています。

道具の側を減らして良くなった例もあります。Vercelは2025年12月22日のブログ「We removed 80% of our agent’s tools」で、社内のデータ分析エージェントd0から、スキーマ参照・クエリ検証・エラー回復などの専用ツールを外し、bashでコマンドを実行する汎用ツール中心の構成に置き換えた結果を公開しました。代表的な5件の質問で比べた同記事の表では、平均の実行時間が274.8秒から77.4秒、成功率が5件中4件（80%）から5件中5件（100%）、平均トークンが約10.2万から約6.1万（記事の表記は37%減。概数どうしで計算すると約40%減）、平均ステップ数が約12から約7になっています。記事は旧構成を「モデルの代わりに考えてやっていた（We were doing the model’s thinking for it）」と振り返り、Claude Opus 4.5ではその制約がかえって足かせになったと書いています。専用ツールが先回りして決めていた手順を、モデル自身に組ませたほうが速く正確だったという報告です。件数が5件と少ない点に加え、Vercelが成功の前提として、構造化され、命名と定義が整ったYAMLのセマンティック層を挙げている点にも注意が必要です。

2026年にはAnthropicが同じ現象を自社の事例で書きました。2026年4月8日のエンジニアリング記事「Scaling Managed Agents」は、Claude Sonnet 4.5がコンテキスト上限が近づくとタスクを早めに切り上げる癖（context anxiety）を持っていたため、ハーネスに文脈のリセット処理を足したところ、Claude Opus 4.5では癖が消え、リセットは「お荷物（dead weight）」になったと報告しています。同記事は「ハーネスは、モデルが自力でできないことについての前提を埋め込んでおり、その前提はモデルの向上とともに古くなる」とまとめています。ハーネスの構成部品はAIハーネスの6部品とSDK別の実装で整理しています。

Big Workflows派の根拠：予測可能性と文脈の制御

Chase氏の主張の中心は「システムがエージェント的になるほど予測しにくくなる」という点です。ユーザーの信頼や規制上の理由で予測可能性が必要な場面はあり、信頼性と予測可能性は完全には一致しないものの、実務では強く結びつくと書いています。

モデルが賢くなれば全部エージェントになるのか、という問いへの答えも示しています。ツールを呼ぶエージェントの性能は上がる、それでもLLMに何を渡すかの制御は重要なまま（garbage in, garbage out）、ループだけで足りる用途もあれば、ワークフローのほうが単純・安価・高速・高性能な用途も残る、という4点です。Anthropicの記事もワークフローを「明確に定義されたタスクに予測可能性と一貫性をもたらす」と評価しており、この点では3社の認識は一致しています。

Latent Spaceも、モデル更新で確実に押し流されるワークフローがある一方で、モデルが更新されても価値を保つワークフローもあると認めています。その例として挙げたのが、2024年1月に公開されたコード生成手法AlphaCodiumで、同年のo1登場後も効果が残ったことです。

エージェントを足しすぎて戻す判断が要る例として、Latent SpaceはAugment CodeのSWE-bench Verifiedの取り組みも挙げています。Augment Codeは2025年3月31日の公開記事で、Claude 3.7 Sonnetを実装役、OpenAI o1を複数の解答候補の選択役に使った構成で65.4%を記録したと報告し、効かなかった工夫も書いています。実装役のエージェントの後に「回帰を直す」別のエージェントを走らせる構成は、正しかった解答候補にもバグを持ち込み、最終スコアは純増しませんでした。エージェントを増やせば良くなるとは限らず、構成をコードで簡単に戻せることがワークフロー側の価値になります。

2025年10月以降の各社の変化

論争後、3社とも製品と文書を更新しました。OpenAIが視覚的なワークフロー構築を一度出し、LangChainが標準のエージェントループを中心に据えたことから、この記事では両陣営が互いの側へ寄ったと解釈しています（LangGraphには2025年4月の時点でもエージェント抽象がありました）。時系列で並べると次のとおりです。

OpenAI：Agent Builderの公開と終了予定

宣言的なグラフを批判したOpenAIは、2025年10月6日のDevDayで、ノードをつないでマルチエージェントのワークフローを視覚的に組むAgent Builderを公開しました。ところが2026年6月3日に非推奨を告知し、終了予定日を2026年11月30日としています（OpenAIの非推奨一覧。2026年11月6日に確認した時点でも予定日は変わっていません）。移行ガイドによると、移行先はAgents SDKかChatGPT Workspace Agentsで、Agent BuilderのCodeメニューからAgents SDKのTypeScript/Pythonコードを書き出せますが、「ワークフローのグラフは変換されず、すべての挙動がそのまま移る保証はない」と明記されています。ガイドは「一部の挙動は手動での再作成が必要になりうる」として、制御フロー・トリガー・ツール・権限を移行先で確かめるよう求めています。製品の概要はAgent Builderの記事、移行先のAgents SDKとAgents APIの違いはOpenAI Agents APIとSDKの違いで扱っています。

LangChain：1.0のcreate_agentとミドルウェア

エージェントの抽象を批判したLangChainは、2025年10月20日に公開した1.0で、標準のエージェントループ create_agent と、そのループに処理を差し込むミドルウェアを中心に据えました。Chase氏は同年10月25日の記事で、LangChainを「エージェントフレームワーク」、LangGraphを「エージェントランタイム」、Deep Agentsを「エージェントハーネス」と呼び分け、LangChain 1.0はLangGraphの上に作られていると説明しています。つまり「ループはモデルに任せ、永続化や中断・再開はランタイムが受け持つ」構成で、Big Model側の書き方を、Big Workflows側の基盤で動かす形になりました。依存関係が逆転した経緯はLangChainとLangGraphの違いで説明しています。

2026年にはLangChain自身が、ハーネスの部品を評価で削る側に回りました。2026年7月23日の「How We Benchmark Deep Agents」は、todoリストのミドルウェアを外すことと、システムプロンプトを大幅に削ることを検討中とし、それらがまだハーネスに必要かをベンチマークで判断すると書きました。6日後の7月29日に出た「Deep Agents v0.7」では、内部で使っていた基本のシステムプロンプトを削除し、TodoListMiddlewareを既定から外して任意にしています。同社の評価で計画用のプロンプトとwrite_todosツールが性能を有意に上げていなかったためで、既定の1ターンあたりの基本入力トークンは約6千から約2千（65%減）になりました。Chase氏は2026年11月2日の「New context engineering challenges in late 2026」で、「LLMがループの中でツールを呼ぶ」構成をサンドボックスで動かす形に各社が収束しつつあると述べ、残る課題としてメモリ・非同期処理・長期の目標追跡などを挙げました。

Anthropic：セッション・ハーネス・サンドボックスの分離

Anthropicは2024年12月の記事の冒頭に「この記事で説明したツール環境の多くは2024年12月以降に変わった」という注記を加え、現在の方針としてClaude Managed Agentsを案内しています。2026年4月8日の記事では、エージェントを「セッション（出来事を追記する記録）」「ハーネス（Claudeを呼んでツール呼び出しを振り分けるループ）」「サンドボックス（コード実行環境）」の3つに分け、それぞれを互いに独立して差し替えられるインターフェースにしたと説明しています。ループの中身はモデルに合わせて変え、記録と実行環境の境界は固定する、という分け方です。

ワークフローとエージェントを組み合わせる実装例

Chase氏の「ワークフローの中のLLM呼び出しをエージェントに置き換える」を、フレームワークを使わずに書いた例です。返金問い合わせを分類し、調査部分だけをエージェントに任せ、最終判定の形式はコードで検査します。APIキー無しで動くよう、入力を読まずに台本の応答を順に返す疑似モデルを使っています。下の出力はPython 3.9.6と3.14.6で同じでした。

import json

class ScriptedLLM:
    """API キー無しで動かすための疑似モデル。入力は読まず、台本を順に返す"""
    def __init__(self, replies):
        self.replies = list(replies)
        self.calls = 0
    def __call__(self, prompt):
        self.calls += 1
        return self.replies.pop(0)

# 道具（エージェント区間で呼ばれる）
TOOLS = {
    "order_status": lambda arg: {"order": arg, "status": "shipped", "days_late": 3},
    "refund_policy": lambda arg: {"refund_if_days_late_at_least": 2},
}

def agent_step(llm, task, max_steps=4):
    """エージェント区間：次の行動はモデルの応答で決まる。上限と例外処理はコードが持つ"""
    log = []
    for _ in range(max_steps):
        try:
            action = json.loads(llm(f"{task}\n{log}"))
            if not isinstance(action, dict):
                return None, log, "invalid_action"
            if action.get("type") not in ("tool", "final"):
                return None, log, "invalid_action"
            if action["type"] == "final":
                return action["answer"], log, "final"
            result = TOOLS[action["tool"]](action.get("arg"))
        except (json.JSONDecodeError, KeyError) as e:
            return None, log, type(e).__name__   # 壊れた応答・未知のツール
        log.append({"tool": action["tool"], "result": result})
    return None, log, "step_limit"

def workflow(llm, ticket):
    """ワークフロー区間：順序・分岐・検査はコードが決める"""
    category = llm(f"分類せよ: {ticket}")            # 1. 分類
    if category != "refund":
        return {"route": "faq", "llm_calls": llm.calls}
    answer, log, stop = agent_step(llm, ticket)       # 2. 調査だけエージェントに任せる
    if answer is None:
        return {"route": "human", "reason": stop, "llm_calls": llm.calls}
    if not isinstance(answer, str) or answer not in {"approve", "deny"}:  # 3. 型と回答値を検査
        return {"route": "human", "reason": f"invalid:{answer}", "llm_calls": llm.calls}
    return {"route": "auto", "decision": answer, "tools": [s["tool"] for s in log],
            "llm_calls": llm.calls}

cases = {
    "ok": ["refund",
           '{"type":"tool","tool":"order_status","arg":"A-1001"}',
           '{"type":"tool","tool":"refund_policy"}',
           '{"type":"final","answer":"approve"}'],
    "invalid": ["refund",
                '{"type":"tool","tool":"order_status","arg":"A-1002"}',
                '{"type":"final","answer":"approve_with_coupon"}'],
    "loop": ["refund"] + ['{"type":"tool","tool":"order_status","arg":"A-1003"}'] * 4,
    "broken": ["refund", "注文を確認します"],
}
for name, replies in cases.items():
    print(name, workflow(ScriptedLLM(replies), "注文が届かないので返金してほしい"))

実行結果は次のとおりです。

ok {'route': 'auto', 'decision': 'approve', 'tools': ['order_status', 'refund_policy'], 'llm_calls': 4}
invalid {'route': 'human', 'reason': 'invalid:approve_with_coupon', 'llm_calls': 3}
loop {'route': 'human', 'reason': 'step_limit', 'llm_calls': 5}
broken {'route': 'human', 'reason': 'JSONDecodeError', 'llm_calls': 2}

疑似モデルは台本を返すだけなので、この例が示すのはモデルの判断の良し悪しではなく、応答に応じてコード側の制御がどう働くかです。okはツール2回を経て承認に至る正常系、invalidは選択肢にない「approve_with_coupon」を回答値の検査が止めて人へ回す例、loopはツールを呼び続ける応答を上限4回で打ち切る例、brokenはJSONでない応答を未知のツール名（KeyError）と同じく人へ回す例です。JSONとしては正しくても辞書でない応答（[]など）や、toolでもfinalでもない行動種別はinvalid_actionとして人へ回し、回答値が文字列でない場合も回答値の検査で止まります。この4種類はどのモデルの応答でも同じ箇所で止まりますが、これ以外の失敗（ツール自体の例外やタイムアウトなど）の処理は実装していません。

実際のモデルにつなぐには、ツールの仕様と応答のJSON形式をプロンプトかツール定義で渡す処理が別途要ります。モデルを替えても、分岐の順序・回答値の検査・回数上限・人への引き継ぎといったコード側の制御は書き換えずに残せます。ループ本体を本番向けに組む手順はAIエージェントの作り方：ツール定義からループ・承認・トレースまで、同じ構成をグラフで書く方法はLangGraphでAIエージェントを実装する手順を参照してください。

Big ModelとBig Workflowsの採用判断基準

両陣営の主張と2026年までの変化を合わせると、判断は「システム全体をどちらにするか」ではなく、「ステップごとに誰が次を決めるか」で行うのが妥当です。

モデル更新で捨てる制御と残す制御

Big Model派の指摘どおり、手組みの制御の一部はモデル更新で不要になります。ただし不要になるのは、モデルの能力不足を補うための制御です。Anthropicの文脈リセットがまさにその例で、Sonnet 4.5の癖への対処だったため、Opus 4.5では不要になりました。手順の順番を細かく指定するプロンプト、出力形式を整えるための再試行、タスク分解の固定化も同じ種類で、モデルを替えるたびに外せるか試す対象です。試し方は後の「モデル更新時に補助の制御を外せるか確かめる手順」で示します。

逆に、モデルがどれだけ賢くなっても残る制御があります。誰に何を許すかの権限、返金や送金など取り消せない操作の前の承認ゲート、後から説明するための実行記録、ループ回数や費用の上限です。これらは業務と組織の要件で、モデルの能力とは関係がありません。新しく制御を足すときは、どちらの種類かを設計書かコードのコメントに書いておくと、モデル更新時に外してよい箇所がすぐわかります。

Big Modelに寄せてはいけない場面

取り消せない操作を、ゲートを挟まずにエージェントのループから直接呼べる構成は避けるべきです。LLMは指示した選択肢以外の値を返すことがあり、ゲートが無ければその値のまま後続へ進みます。上の実装例のゲートは回答値が選択肢に入っているかを見るだけで、返金条件の検証や操作前の人による承認までは行っていません。業務で使うなら、ツール結果と規程を突き合わせる検査と承認の段をコードで足してください。承認ゲートや評価の仕組みまで含めた設計は、一創のAIエージェント開発でも相談を受けています。また、評価データが無いままループに任せると、モデル更新で性能が上がったのか下がったのかを測れません。エージェントの評価方法を決めずに「次のモデルで良くなる」前提に立つのは、Big Model派の主張の誤用です。

ワークフローを作り込んではいけない場面

逆に、入力の種類が増えるたびに分岐を足しているワークフローは、OpenAIガイドの基準2（ルールが膨らみ保守できない）に当てはまり、エージェントへ移す候補です。分岐を足す前に、その判断をモデルに任せて結果をゲートで検査する形にできないかを先に検討してください。エージェントを1体にするか複数に分けるかの判断はシングルエージェントとマルチエージェントの違い、フレームワークごとの書き方の差はAIエージェントフレームワーク主要8種の比較で扱っています。

モデル更新時に補助の制御を外せるか確かめる手順

「次のモデルで不要になるはず」という見込みで制御を外すと、性能が落ちても気づけません。外す判断は、同じ評価データを制御ありと制御なしで流し、正解率と呼び出し回数を比べてから行います。前述のLangChainが、評価で効果を確かめられなかったtodoリストのミドルウェアをDeep Agents v0.7で既定から外したのも、この手順に沿った判断です。手順は次の3段です。

1. 制御ごとに、モデルの弱点を補う「補助」か、業務要件に由来する「業務」かを台帳に書く（業務の制御は比較の対象にしない）
2. モデルを替えたら、補助の制御を1つずつ外した版で評価データを流す
3. 同じ条件で各ケースを複数回評価し、事前に決めた許容幅と結果のばらつきを踏まえて、品質の非劣化と費用・遅延の改善を確認できた制御を外す。判断できなければ残し、理由を台帳に書き足す

次のコードは、1回で判断させると返金条件を読み落とすモデルのために「段階に分けて聞く」補助制御を入れていた場合の判定です。疑似モデルの回答を表で与えており、旧モデルと新モデルで結果が変わる様子だけを示します。

# 制御の台帳：kind が「補助」のものだけを、モデル更新時に外す候補にする
CONTROLS = {
    "split_steps":  {"kind": "補助", "reason": "1回で判断させると返金条件を読み落とす"},
    "answer_check": {"kind": "業務", "reason": "選択肢外の回答で自動処理を進めない"},
}

# 評価用の問い合わせと正解（本番では過去の実データから数十件以上用意する）
EVAL = [("A-1", "approve"), ("A-2", "deny"), ("A-3", "approve"), ("A-4", "deny")]

# 疑似モデルの回答表。split=段階に分けて聞いた場合、single=1回で判断させた場合
ANSWERS = {
    "old": {"split":  ["approve", "deny", "approve", "deny"],
            "single": ["approve", "approve", "approve", "refund?"]},
    "new": {"split":  ["approve", "deny", "approve", "deny"],
            "single": ["approve", "deny", "approve", "deny"]},
}

def run(model, split_steps):
    mode = "split" if split_steps else "single"
    correct = calls = 0
    for i, (_, expected) in enumerate(EVAL):
        calls += 2 if split_steps else 1          # 段階に分けると1件あたり2回呼ぶ
        answer = ANSWERS[model][mode][i]
        if answer not in {"approve", "deny"}:     # 業務制御はどの条件でも外さない
            answer = "human"
        correct += answer == expected
    return correct / len(EVAL), calls

for name, c in CONTROLS.items():
    if c["kind"] != "補助":
        continue
    for model in ANSWERS:
        on_acc, on_calls = run(model, True)
        off_acc, off_calls = run(model, False)
        verdict = "外せる" if off_acc >= on_acc else "残す"
        print(f"{name} {model}: on={on_acc:.2f}/{on_calls}回 off={off_acc:.2f}/{off_calls}回 -> {verdict}")

Python 3.9.6と3.14.6での出力は次のとおりです。

split_steps old: on=1.00/8回 off=0.50/4回 -> 残す
split_steps new: on=1.00/8回 off=1.00/4回 -> 外せる

旧モデルでは制御を外すと4件中2件が誤りになるので残し、新モデルでは外しても正解率が変わらず、呼び出し回数が半分になるので外します。業務の制御である回答値の検査は、どちらのモデルでも動いたままです。実際の評価では4件では少なすぎるため、判定がぶれない件数を過去の問い合わせから集め、正解率の差に許容幅を決めてから比べてください。評価データの作り方と採点の自動化はDeepEvalでLLM出力を採点する方法で扱っています。

よくある質問

Big ModelとBig Workflowsは正式な用語ですか？

正式な用語ではありません。Latent Spaceが2025年4月20日の記事で、OpenAIとLangChainの論争を説明するために使った呼び名です。学術的な定義や仕様書はなく、近い概念として正式に参照されるのはAnthropicによる「ワークフロー」と「エージェント」の定義です。

中国のBigModel（智谱の開発者プラットフォーム）とは関係がありますか？

関係ありません。「BigModel」は中国の智谱（Zhipu AI）が運営する開発者向けプラットフォームの名称（open.bigmodel.cn）で、GLMシリーズのモデルAPIを提供しています。この記事のBig Modelは「大きなモデルに任せる設計思想」を指す呼び名です。

ワークフローとモデルの違いは何ですか？

モデルは入力から出力を生成するLLMそのもので、ワークフローはそのモデルをどの順番で、どの入力で呼ぶかを決めたコード上の処理の流れです。Anthropicの定義では、処理の経路をコードが決めるものがワークフロー、モデル自身が決めるものがエージェントです。

モデルが賢くなればワークフローは不要になりますか？

一部は不要になり、一部は残ります。モデルの癖や能力不足を補うための制御（文脈のリセット、手順の細かな指定など）は不要になりやすく、Anthropicは実例を公表しています。権限・承認・監査・費用上限のような業務要件に由来する制御は、モデルの性能と関係なく残ります。

OpenAIのAgent Builderで作ったワークフローはどうなりますか？

Agent Builderは2026年11月30日に終了予定です。OpenAIはAgents SDKかChatGPT Workspace Agentsへの移行を案内しており、Agents SDKのコードとして書き出せますが、ワークフローのグラフは変換されず、挙動がそのまま移る保証はないとしています。分岐や承認の流れは移行先で動作を確かめ、再現できない部分だけを組み直す計画にしてください。

関連記事

• プロンプトチェイニングとは？段の切り方とゲート設計・採用判断を実装目線で解説【2026年版】
• AIエージェントの作り方：ツール定義からループ・承認・トレースまでコードで組む
• AIハーネスとは？LLMエージェントの制御基盤を構成する6部品とSDK別の実装
• LangChainとLangGraphの違いと使い分け｜v1.0以降の関係をコードで確認【2026年10月】
• AIエージェントフレームワークとは？主要8種の比較・動作コード・選定基準【2026年9月版】