少し前にOpenAIのA Practical Guide to Building Agentsから生まれた、Big Model vs Big Workflowsの議論を元に、エージェント設計指針を自分なりに再確認するためにまとめた読書メモな記事です。
下記三つの記事を元にしています。
ちなみに一つだけ読むとしたら、LangChainの記事が、（時系列的に当たり前ですが）OpenAIのガイドやAnthropicのBuilding effective agentsに言及しながら指摘を行っており、一番主張やスタンス、全体感はわかりやすいです。Anthropicの記事のことは絶賛です。
大枠描き終わってから思い出したのですが、Google Cloud／Kaggleチームのホワイトペーパーもあります。
それぞれの記事の要点
簡単にそれぞれの記事のポイントです。
| 記事 | 一言で言うと | ３行まとめ |
|---|---|---|
| OpenAI Guide | まずはシングルエージェント＋高性能モデルで走れ | 1) whileループ＋ツール呼び出しが出発点 2) 複雑性が閾値を超えたらマネージャ型→分散型へ段階拡張 3) 品質キープできる所はスモールモデルに置換しコストを削減 |
| LangChain Blog | 見える化しないと壊れた理由が追えない | 1) 信頼性の核心は「LLM に渡すコンテキスト制御」 2) 抽象エージェントだけではブラックボックス化しデバッグ不能 3) LangGraph は宣言・命令両 API＋低層関数で High Ceiling を確保 |
| Latent Space | 態度の対立：Big Model vs Big Workflows | 1) “モデル任せ”と“構造重視”を歴史と事例で対比 2) モデル更新で壊れる／保たれる実例を紹介 3) フェーズに応じたハイブリッドが現実解 |
OpenAIガイド – 最小ループで始め、段階的に拡張する
まずは大元のOpenAIのガイドに関して簡単に。詳細は日本語訳の記事などをご覧ください。
OpenAIのガイドでは、伝統的なルールベースが機能しづらい「複雑な意思決定」「保守困難なルール」「非構造化データ」依存のワークフローでエージェントがワークするとしつつ、エージェント自体の実装は 「最初はシングルエージェント＋ツール呼び出しループで始め、必要に応じてマルチエージェントへ拡張せよ」 と説きます。
- エージェント = LLM（思考）＋ツール（行動）＋指示（ガードレール）でワークフローを自律実行する仕組み
- まずシングルエージェントから始める。ループを回し、ツール呼び出しとガードレールを添える
- 複雑性・ツール数・分岐増加に合わせてマルチエージェントへ段階的に拡張
- モデル選択は、最も高性能なモデルでベースラインを取り、品質を保てる所はスモールモデルに置き換えてコスト／レイテンシを最適化する、という段階的手法を推奨
- シングル -> マネージャー型（中央集権型）→分散型（ハンドオフ）という順で拡張
- リスク管理は入力フィルタやPII検出などのガードレールを配置し、「失敗数の閾値」と「高リスク操作」で人間を介入させる例外ハンドラ型
LangChainブログ ― コンテキストの信頼性と見える化が最優先
LangChain CEOのHarrison Chase氏は「信頼性の核心はLLMが毎ステップ受け取るコンテキスト制御だ」と強調し、抽象クラス中心の現在の多くのエージェントSDKはその視認性を奪うと批判します。
- 信頼できるエージェントシステムを作る最大の難所は、各ステップでLLMに“適切なコンテキスト”を渡し続けること
- エージェンティックシステムは大きくワークフローとエージェントで分類され、ワークフロー vs. エージェントは“度合い”の問題
- 対立概念ではなく同じ“エージェンティック・システム”の両極。多くのサービスは両者のハイブリッド
- 多くの「エージェントフレームワーク」は、実際には宣言的／命令的なオーケストレーション基盤ではなく、ただのエージェント抽象クラスの寄せ集めにすぎない。
- こうした抽象は手軽だが、LLMに入る情報をブラックボックス化し、チューニングを難しくする
- LangGraphは宣言的・命令的APIの両方を備えたオーケストレーションフレームワークで、その上にエージェント抽象を“追加で”載せている点が特徴
- 将来すべてが「エージェント」になるわけではない
- モデルが強くてもワークフローの方が速く・安く・シンプルな場面は多い
- OpenAIのガイドは、宣言型 vs 非宣言型・ワークフロー vs エージェントを混同しており、本質的課題を外している
コード数行で動くSDKの“低いハードル”には賛同しつつも、それではビジネスクリティカルなレベルの信頼性は難しいと警告する立場です。
特に後半以降はLangGraphの利点やエージェントフレームワークの比較表について言及しています。
Intent / Memory / Planning / Auth / Control flow / Toolsの６点を満たすかどうかで判断するフレームワークです。
Latent Space記事 – Big Model／Big Workflows
Latent Spaceのポッドキャストでは両者の衝突を「Big Model vs Big Workflows」と命名し、技術というより“態度”の対立として描きます。
- Big Model派
- 「モデル進化が速すぎてワークフローはすぐ陳腐化する」と考え、Deep Researchやo3系モデルの成功を引用
- Big Workflows派
- 「監査・説明責任の観点でコード化されたフローが必須」と主張し、AlphaCodiumがモデル更新後も性能を保った例を挙げる
「どちらか一方ではなく行き来するハイブリッドこそ現実解、エージェント or ワークフローではない」という着地。
論点
エージェント観
OpenAIは「ユーザに代わってタスクを独立遂行するシステム」と定義し、コアコンポーネントは モデル＋ツール＋指示 の三点セットだと定義します。
また、ワークフロー実行の制御にLLMを使用しないアプリケーションはエージェントではないとしています。
LangChainはAnthropicと足並みをそろえ、エージェントとワークフローを同じ“エージェンティック・システム”のスペクトラム上に置く、LLMが自律的に処理の分岐を選ぶときだけを狭義のエージェントと呼び、残りはワークフローと区別しています。
細かな違いはありそうですが、大枠は何をエージェントと呼んでいるのか？に関しては大きな差異はないように思えます。
Latent Spaceはこの定義論を踏まえつつ、「Big Model take the wheel」派と「We still need code」派に分類しています。
設計アプローチ
OpenAIは シングルエージェントのwhileループ から着手し、必要に応じてマネージャー型・分散型に段階拡張する“ミニマムスタート”を推奨します。
モデルの性能向上が速い以上、最初からシステムを重く作るべきではないという判断です。
LangChainはワークフローが使える場合は、ワークフローを使うべきとしつつ、よりコンテキスト制御を重要視するスタンスだと捉えました。
| 観点 | OpenAI Guide | LangChain Blog |
|---|---|---|
| 分割基準 | 複雑性・ツール数・分岐が閾値を超えたら → マネージャ型 → 分散型へ段階的に |
ロジックが肥大化し “if/else”だらけになったら → 責務ごとにサブグラフ化 |
とはいえOpenAIもエージェント構築のガイドであるからこの主張・表現と言うだけで、大枠は変わらず、どの辺りに重点を置くか？の違いです。
また、Harrison Chase氏は「エージェントを増やし過ぎたと感じたら、後から統合し直す選択肢も残すべき」と補足しており、分割と統合を行き来できる設計を推奨しています。
フレームワーク選定軸 ― “Low Floor / High Ceiling”
LangChain Blogでは、エージェントフレームワークを選ぶときに 「開発の敷居（Floor）が低いか／拡張の天井（Ceiling）が高いか」 をまず確認すべきだと説きます。
敷居が低い＝数行コードで動く抽象クラスは魅力的だが、本番で複雑化すると“天井”に頭をぶつける危険がある、という警告です。
要は「PoCで楽をする抽象」と「あとから潜れる低層API」を両取りできるかが肝心、という主張になります。([LangChain Blog])
この観点で見直すと、OpenAI Guideが示す “まずシングルエージェント＋高性能モデルで走れ” は Low Floor側を徹底した戦略と言えますし、LangChain Blogが強調する“見える化できる余白を残せ”はHigh Ceilingを確保せよというメッセージです。
コンテキスト制御と信頼性
LangChainのブログ記事での主張で最重要視されているのが 「LLMに渡すコンテキストの制御」 です。
LLMが毎ターン受け取る入力を観測・再現できる設計が、最終的な品質とデバッグ速度を決める。
- OpenAI Guide も「最小構成で走らせてステップごとにログを取れ」と勧めるが、多くの既存SDK は内部ステップがブラックボックス化しやすい
- LangChain Blog はここを核心に据え、「ブラックボックス抽象ではなくグラフ＋素の関数まで降りられれば任意段階のログ／差し替えが可能」と主張
自社ケースでの自動評価、Eval Drivenというのは、“Big Model派”も“Workflows 派”も共通の課題ですね。
Human‑in(the/on)‑Loopとガードレール
- OpenAI Guide: 「失敗回数 > N 」「高額操作」等で 例外を投げて処理終了 → 人間に引き継ぐ 設計を推奨
- LangChain Blog: 中断後に再開できる“チェックポイントの粒度”とHuman-in-the-Loopを重視
- Latent Space: 「Big Workflowsは監査と再実行コストの低さが武器」と整理
OpenAIはガイドの中で、失敗回数超過・高リスク操作 をトリガーとする例外ハンドラ型の介入モデルについて言及しています。
（OpenAI SDKもフックはあるが、ガイドでは“失敗→終了→人手”の一括ハンドオフを主シナリオに据えている）
一方で、LangGraphは、ワークフロー上のどのノードでも interrupt → approve → resumeを宣言的に設定可能なブレークポイント型です。
まとめ
色々読み比べてみると、大枠は似ていますが多少のスタンスの違いや、言及内容の違い（OpenAIのガイドではツールの分類やガードレールには言及しているが、メモリについては比較的深入りしていない。など）を考えるのは楽しかったです。
感想をまとめると、
- PoC段階では“シングルエージェント＋最高性能モデル”がもっとも速いだろう
- 運用段階に入ると、ワークフローは信頼性の面で効いてくる
-
コンテキスト制御こそ信頼性
- LangChainが繰り返すメッセージはエージェントでもワークフローでも変わらず重要
- 入力品質の可視化は、どんな設計でも求められる
- 可観測性はコストではなく保険
- モデルの進化がワークフローを壊すリスクと、フローがモデル更新後も精度を底上げする利点は両立しうる
-
Big ModelとBig Workflowsの行き来、再統合できる設計が理想
- モデル性能が上がった時に「2Agent → 1Agent」に巻き戻せる
-
エージェント間の協調は“何を分け、どう渡すか”
- 分割の目的は「責務明確化 × コンテキスト削減」。そしてハンドオフ設計の重要性
- 例えば、入力／出力スキーマを固定し、バージョン差異を吸収できる Adapter 層を挟むと、モデル更新→片側だけ差し替えが容易
モデルの進化が著しい今だからこそ、“いつでも乗り換えられる・改善が回せる”ことが、最大の設計資産と言うのは変わらないですね。
（個人的にはEval Driven Developmentなどの詳細なガイドが読みたい）
Views: 0
