「ワークフロー vs エージェント」では足りなかった——自分のプロダクトを実コードで分類した

「エージェント基盤の開発に、体系はあるのか」。そう考え始めて、自分の手持ちのプロダクトを片っ端から実コードで読み直すことになった。結論から言うと、教科書的な「ワークフロー vs エージェント」の二分法では足りない。実在するプロダクトを分類するには、もう一本の軸が要る。そしてその軸は、コードを読むまで自分でも言語化できていなかった。

二つの「エージェント基盤」

まず言葉を区切る。「エージェント基盤」には混ざりやすい二つの意味がある。

ひとつは 開発でエージェントを使う 側。Claude Code や Cursor で自分の開発を加速する話で、/goal や 12-Factor Agents、Intent Engineering はこちらに効く。

もうひとつは プロダクトに LLM やエージェントを組み込む 側。エンドユーザー（あるいは無人のループ）が触るプロダクトの中に、LLM を部品として、あるいは自律ループとして埋め込む話。

この記事は後者だけを扱う。スコープをそう切ると、副産物として外れるものがある。たとえば探索結果を執行するだけの決定論的なトレーダーや、検索 API としての MCP サーバーは「ループの中に LLM がいない」ので対象外になる。この線引き自体が、あとで効いてくる。

既存の地図——Anthropic の5パターンと、よくある混同

出発点は Anthropic の「Building Effective Agents」。事実上の入門書で、5つのパターンを提示している。Prompt Chaining、Routing、Parallelization（分割と投票）、Orchestrator-Workers、Evaluator-Optimizer。そして「Workflows（事前定義のコードパス）」と「Agents（LLM が制御を動的に決める）」を別カテゴリとして対比する。

ここで多くの人（私を含む）がやる混同がある。5つのパターンと、Workflow/Agent の区別を、1本の分類軸だと思ってしまう ことだ。

実際には直交する2軸だ。

• 5つのパターンは トポロジー軸（データフローの形）。直列・分岐・並列・階層・循環。
• Workflow ↔ Agent は 自律度軸（次の一手とその停止を、コードが握るか LLM が握るか）。

証拠は Evaluator-Optimizer にある。あれはトポロジー的には「循環」で、自律型 Agent も本質は「環境フィードバック付きの循環」だ。同じ形が線の両側に現れる。形だけでは Workflow か Agent かは決まらない。

ついでに言えば、この区別は 観測する境界に相対的 でもある。claude -p は内部でツール使用ループを回しているので、その境界で見れば立派なエージェントだ。だがそれを外側のスクリプトが繰り返し叩いていれば、外側の境界ではワークフローになる。「これはエージェントか?」は、どの層を見るかを決めない限り答えられない。

棚卸し——手持ちを実コードで分類する

地図を持って、自分のプロダクトを実コードで読み直した。CLAUDE.md や README ではなく、LLM がどこに何点差さっているか、ループを誰が握っているか、出力を誰が検証しているかを、ファイル単位で確認した。

対象は5つ。

• マンガ制作エディタ——FastAPI とブラウザ UI のエディタ本体に、画像生成・構造抽出・編集を LLM で添えたもの。
• マルチモデル協調パイプライン——複数の LLM（異なるベンダーのモデルを併用）でドラフトを並列生成し、相互レビュー・改善・投票で1案に収束させるもの。
• 戦略の自動探索——トレード戦略を LLM エージェントが自律的に実験・改善し、バックテストで評価するもの。
• 専門ドメインのリサーチ系エージェント——その分野の一次情報を並列のサブエージェントで検索し、レポートにまとめるもの（守秘のため領域は伏せる）。
• map-reduce 型の専門文書生成パイプライン——大量の一次資料を分割して並列処理し、構造化して1つの文書に統合するもの。

読んでみると、5つはきれいに散らばらず、ある一本の性質に沿って3つの塊になった。その性質が「検証層がどこから来るか」だった。

掘り下げ——検証層はどこから来るか

LLM は間違える。だから本番で動くシステムには、必ず 出力を検証して突き返す層（enforcement）が要る。プロンプトに「正確に」「捏造するな」と書くのは弱い誘導（Steering）にすぎず、本当の保証にはならない。問題は、その検証層を どこから調達するか だ。3つの答えがあった。

① 製品内蔵型——製品と人間から借りる

マンガ制作エディタがこれ。決定論的なコードがほぼ全てを担い、LLM は画像生成や構造抽出といった数点に、単発で差さるだけ。自律ループは無い。

重要なのは、検証層を 自分で作っていない ことだ。エディタには undo があり、結果は canvas に見えていて、人間がその場で直せる。可逆性・可視性・チェックポイントを、完成品と人間が無料で供給している。だから LLM は薄くていい。これは「よく設計されたソフトウェアに LLM を点で差す」という 12-Factor の思想そのものだった。

② 外枠拘束型——継ぎ目に自作する

マルチモデルパイプライン、map-reduce 型の文書生成、専門リサーチ系エージェントがここ。無人で回るので、製品や人間から検証層を借りられない。だから 決定論的な外枠で自律を縛り、継ぎ目に検証を作り込む。

map-reduce 型なら、品質が宿るのは reduce（統合）の点だ。分割した結果を1つにまとめるときに、章間の矛盾や、参照すべきでないものを参照していないかを機械的にチェックする。投票型なら、複数モデルの出力を集約する点に検証が乗る——ただし投票は「正しさ」ではなく「多様な視点からの民主的選出」であって、モデルの誤りが相関していればむしろ増幅する、という注意が要る。

私のプロダクト群では、この外枠を回すエンジンが共通していた。検証コマンドが閾値に達するまで反復する仕組み（いわゆるループランナー）に、ほぼ全ての無人プロダクトが乗っている。これが自分の「ハウスパターン」だと、棚卸しして初めて気づいた。

③ 自律ループ型——ループの中に作り込む

戦略の自動探索だけがここ。LLM がループを 自分の文脈内で 保持し、何を試すかを毎回自分で決める。検証層は、そのループの中に作り込むしかない。

そして③は本来、一番危険だ。無人で、かつ LLM がループを握っている。

オラクル原理——なぜ1つだけが例外なのか

なぜ戦略探索だけが、外枠（ループランナー）を外して③をやれているのか。考えていくと、3つ目の決定変数に行き着いた。出力に、安い決定論的なオラクル（正解判定器）があるか だ。

トレード戦略には、それがある。バックテストの損益、訓練データでの採用判定、未知データ（OOS）での検証。「良い戦略か」を数値で機械的に判定できる。これは稀有なことだ。

オラクルがあると、外枠で縛らなくても、エージェントに自走させて安全に回せる。だから戦略探索は③でいられる。逆に言えば、大半のドメインにはこの安いオラクルが無い から、①（製品と人間から借りる）か②（継ぎ目に作る）に倒すのが正解になる。

ここで一つ、自分の予測が当たった。専門リサーチ系エージェントは③に近い自律ループだが、その分野の推論の「正しさ」を判定するオラクルが無いドメインだ。検証可能なのは引用の実在性くらいしかない。実コードを読む前に「だから検証層が弱く、プロンプト依存に堕ちているはずだ」と予測した——そして実際、出力後に引用を一次情報で機械照合する処理が無く、構造チェックはあっても引用の真正性チェックには穴が空いていた。検証可能な部分問題（引用の実在）にすら、検証器を繋いでいなかった。

分類が、コードを読む前に「どこが弱いか」を当てた。これが、この分類が単なる言い換えではないことの、一番強い証拠になった。

新分類に意味はあるか——型が「注意点」を予測するか

ここで立ち止まった。3つに名前を付けただけなら、ただのラベル遊びだ。分類が固有の意味を持つかどうかの試金石は、型が分かれば「注意すべき場所」が変わるか にある。当てはめてみた。

型	固有の失敗モード（ここで死ぬ）	見張る場所
① 製品内蔵型	借り物の検証層は、製品の可逆性・可視性が切れる所で消える	undo 不能・人間に見えないアクションを LLM が持っていないか
② 外枠拘束型	ゲートが検査しない軸は静かに漏れる（Goodhart）	ゲートのカバレッジと、致命的な失敗面とのズレ
③ 自律ループ型	LLM がオラクルを攻略する（報酬ハック・過学習）	オラクルが攻略可能か、ホールドアウトを隠せているか、自己停止するか

3つの型で、失敗モードも見張る場所も全部違う。同じなら統合すべきだが、違う。だからこの分類は意味を持つ、というのが試金石への答えだ。

そして「独自すぎないか」という当然の恐れにも答えが出る。3つの失敗モードは、いずれも既知の概念に落ちる。①は「影響範囲 × 可逆性」、②は Goodhart の法則、③は報酬ハック。つまりこれは新理論ではなく、既知の失敗モードへのルーティング層 だ。独自なのは、概念ではなく、自分のプロダクトをその上に並べた点だけ。それでいい。

正直な限界

誇張せずに言うと、この分類の標本は偏っている。②は4つの実例で裏打ちされていて頑健だが、①と③はそれぞれ1例ずつのアンカーにすぎない。特に③は手持ちで1つしかない。

ただしこれは「③が検証不足」というより、自分のポートフォリオが②に集中している という事実の反映だ。型の正しさは、このポートフォリオ内の標本数からではなく、既知の失敗モードへの対応から来ている。①と③は空間の両端を留める基準点として置いてある。

実利的な持ち帰りは、たぶんこれ一つに尽きる。自分のデフォルトは②（外枠で縛るループランナー）だった。だがループランナーに手を伸ばす前に、「製品と人間がループの中にいて、検証層を借りられないか（＝①で済まないか）」を先に問う べきだった。①で済むなら、②のゲートを自作する工数が丸ごと要らない。完成品にエージェントを薄く添えるのが一番うまくいく、というのは、怠慢ではなく設計判断だったのだ。

今日のところの結論

「ワークフローかエージェントか」は形の話だった。一段掘って「検証層をどこから調達するか」「安いオラクルがあるか」の二つに行き着いた——が、書いているうちに、その二つもさらに一本に畳めると気づいた。

検証層を人間が密に供給するのが①、継ぎ目の決定論チェックに分けるのが②、安いオラクルに任せるのが③。これは全部、完成の定義（DoD）をどれだけ機械で表現できて、人間がどれだけ密に評価するか という一本の連続軸の上の、位置でしかない。「安いオラクルがある」とは「DoD がまるごと安く機械で書けた」極限のことだったし、①の"点差し"が効くのは人間が DoD を毎手評価しているからだった。ReAct を積んだ LLM を使う以上、自律はつねに内側で回っていて、それを縛っているのは結局 DoD と人間の関与だけだ。

だから①②③は離散的な種ではなく、ドメインと DoD でスライドする相対的な位置だ。同じ取り込み処理でも、DoD が安く書けるドメインなら③に、書けなければ②に落ちる。境界は動く。

それでも分類を捨てる気にはならない。今この軸のどこに座っているか は、見張るべき失敗モードを決めるからだ——①寄りなら可逆性の天井、②帯なら Goodhart、③寄りならオラクル攻略。相対的だが、診断には使える。

……というのが、今日のところの結論。とはいえ、この地図は「出してから検証して突き返す（後ろ向き）」の一軸しか描いていない。DoD に近づく道はもう一本、「出す前に、モデル自身のドメイン知識で狙わせる（前向き＝エージェンティックな生成）」方向がある——①の例にしたマンガ制作エディタは画像生成をワンショットで叩いていて、この前向きの力を素通りしていた、と最近気づいた。検証の地図に生成の地図を重ねる話は、また別に書く。たぶん次に何かを読んだら、この軸の引き方ごと書き直すことになる。