AIエージェント開発をやめて、より賢いLLMワークフローを使おう

 (decodingml.substack.com)
63 ポイント 投稿者 GN⁺ 2025-07-07 | 6件のコメント | WhatsAppで共有
  • LLMベースのシステムを作る大半のチームは まずエージェント（Agent）から作ろうとするが、その多くは 複雑さ、制御の難しさ、デバッグ難易度 のために簡単に破綻する
  • 記憶、RAG、ツール利用、ワークフロー制御 がすべて必要な真のエージェントパターンは実際にはまれで、ほとんどの問題は 単純なワークフロー（チェイニング、並列化、ルーティングなど） のほうがより効果的に解決できる
  • 現実で役立つ5つのLLMワークフローパターン をまず適用することを勧め、エージェントは本当に必要なときにだけ慎重に使うべき
    • プロンプトチェイニング、並列化、ルーティング、オーケストレーター-ワーカー、評価者-最適化
  • エージェントが必要な場合でも、結局は 人の関与と明確な制御、観測可能性（Observability） が核心となる

AIエージェント、本当に必要か？

間違った出発点: なぜ誰もがエージェントに執着するのか

  • 多くのチームは LLM プロジェクト開始時に エージェント、メモリ、ルーティング、ツール利用、キャラクター性 などの複雑な構造を優先的に導入する
  • 実際に構築してみると、エージェント間の協調、ツール選択、長期メモリ などさまざまな部分で継続的な異常動作や失敗が頻繁に発生する
  • 例として、CrewAI ベースの研究エージェントプロジェクトで、各役割（リサーチャー、要約者、コーディネーター）が期待したほど協力できず、なすすべなく崩れていくことを経験した

エージェントとは何か？

  • LLMシステムの4つの特性: メモリ、情報検索（RAG）、ツール利用、ワークフロー制御
  • 最後のワークフロー制御（LLM が次のステップやツール利用の可否を直接決定すること）は エージェント的特性 と呼ばれる
  • 実際には大半の業務で 単純なワークフロー（チェイニング、ルーティングなど） のほうが高い安定性を示す

エージェントの代わりに使うべき、実務で役立つLLMワークフローパターン

1. プロンプトチェイニング（Prompt Chaining）

  • 説明: 複数の作業を一連の段階（チェーン）に分割し、各段階を順番に LLM が処理するよう設計する
  • 例: LinkedIn プロフィールから氏名、役職、会社情報を抽出 → その会社の追加情報（ミッション、採用など）を追加 → プロフィール+会社情報をもとにカスタマイズしたメールを作成
  • 利点: 各段階が明確に分離されているため、バグ発生時に原因を追跡・修正しやすく、デバッグと保守に有利
  • ガイドライン:
    • 順次つながるタスクに適している
    • 1段階でも失敗するとチェーン全体が崩れる可能性がある
    • 小さな単位の作業に分割すれば、予測可能な結果と容易なデバッグが可能

2. 並列化（Parallelization）

  • 説明: 複数の独立した作業を同時に実行して、全体プロセスの速度を高める
  • 例: 複数人のプロフィールからそれぞれ学歴、職歴、スキルなど複数項目を並列に抽出し、全体の処理時間を短縮
  • 利点: 独立したデータ抽出・処理などで大規模データにも効率的で、分散処理環境とも相性がよい
  • ガイドライン:
    • 各作業が相互に独立しており、同時実行で全体速度が大きく向上する場合に有効
    • 並列実行中の race condition、タイムアウトなどの例外に注意が必要
    • 大量データ処理、複数ソースの同時分析に適している

3. ルーティング（Routing）

  • 説明: 入力データを LLM が分類（classification）し、それぞれに合ったワークフローへ自動的に分岐させる
  • 例: カスタマーサポートツールで、入力内容が製品問い合わせ、決済問題、返金依頼のどれかを分類して該当ワークフローで自動処理し、タイプが曖昧ならデフォルトハンドラーに渡す
  • 利点: 入力タイプごとに特化した処理ロジックを適用し、さまざまなケースをきれいに分離できる
  • ガイドライン:
    • 異なる入力タイプや状況ごとに別処理が必要なときに活用
    • 境界ケースや例外状況ではルーティングが失敗したり漏れが起きる可能性がある
    • 未分類・例外状況のための catch-all ハンドラーを必ず設計する

4. オーケストレーター-ワーカー（Orchestrator-Worker）

  • 説明: オーケストレーター役の LLM が作業を分解・判断し、ワーカー（実行 LLM）に詳細作業を委任して、全体の流れと順序を直接制御する
  • 例: ターゲットプロフィールを tech / non-tech に分類 → tech なら専門ワーカーにメール生成を委任し、non-tech なら別のワーカーに委任
  • 利点: 意思決定（分類・判断）と実行（個別処理）を分離でき、動的なフロー制御と拡張に有利
  • ガイドライン:
    • タスクごとに専門的なハンドリングが必要な場合、複雑な分岐と段階的な調整に適している
    • オーケストレーターがタスクを誤って分解・委任すると全体フローにエラーが生じる
    • ロジックは明示的かつ単純に保ち、委任・順序・終了条件を明確に設計する

5. 評価者-最適化（Evaluator-Optimizer）

  • 説明: LLM が成果物を評価し（スコア/フィードバック）、基準に満たなければ反復的に修正・改善する構造
  • 例: メール下書きを生成 → 評価者が品質スコア/フィードバックを返す → 一定基準を満たすか最大反復回数を超えたら終了、そうでなければ再修正
  • 利点: 最終成果物の品質を目標レベルまで繰り返し改善でき、定量的基準の活用に向いている
  • ガイドライン:
    • 速度より品質が重要な状況、反復最適化が必要なワークフローに適している
    • 終了条件がないと無限ループに陥る可能性がある
    • 明確な品質基準と反復回数制限の設定が必須

エージェントが本当に必要な場合

  • 人間のリアルタイム介入（Human-in-the-loop）が保証される環境 では、エージェントが真価を発揮する
    • 例1: データサイエンス支援 - SQL クエリ、可視化、データ分析の提案などで LLM が創造的に試み、人が結果を判断・修正する
    • 例2: クリエイティブパートナー - コピー案、見出し提案、テキスト構成の提案などで、人による方向修正と品質審査が鍵になる
    • 例3: コードリファクタリング支援 - デザインパターン提案、エッジケース検出、コード最適化などで開発者が承認・補完する
  • 特徴: エージェントが「すべてを勝手に」処理するのではなく、人がリアルタイムでエラーや方向性を修正する環境 で最も効果的

エージェントが適さない場合

  • エンタープライズ・ミッションクリティカルシステム（金融、医療、法律など）:
    • 自動化の信頼性と決定論的な動作が重要なため、LLM エージェントに判断させる構造は危険
    • オーケストレーター、ルーティングなどの明確な制御パターンを活用すべき
  • 安定性と予測可能性が重要なあらゆる状況
    • 異常事例: エージェントが文脈/メモリなしにツール選択を繰り返し誤ったり、分業/調整に失敗して全体フローが崩れる問題
  • 実務で頻繁に発生するエージェントシステムの失敗要因
    • 明示的メモリシステムの未設計による文脈欠落
    • ツール選択の制約不足（不要な/誤ったツール利用）
    • 自由な委任構造に依存しすぎて協調調整に失敗

実務設計での教訓

  • エージェント導入時であっても、「完成度の高いソフトウェアシステム」レベルの設計・観測性・制御体系 が必ず必要
  • 複雑なエージェントフレームワークより、観測可能性（Observability）、明確な評価ループ、直接制御できる構造 で設計するほうが、より速く安全

結論（TL;DR）

  • エージェントは過大評価・過剰活用されていることが多い
  • 実務上の大半の課題には単純なワークフローパターンのほうが適している
  • エージェントは「人が直接関与する」環境で真価を発揮する
  • 安定したシステムではむしろリスク要因になる
  • 観測可能性と明示的制御、反復評価構造で設計すべき
  • 複雑なエージェントフレームワークの代わりに、観測性、明確な評価ループ、直接制御できる構造 で設計することが、実際にはより速く安全な LLM ベースサービス開発の秘訣である

関連記事

6件のコメント

 
samdo103 2025-07-12

1か月前、CURSORを活用してAIコーディングとは何かを学ぶつもりで、開発フレームワークの開発に着手しました。

3週間ほど、成功したかと思えばAI Agentによって検証済みだったソースコードが壊されることを繰り返し、あらゆる方法を動員してAI Agentを制御しようと努めましたが、失敗しました。

その後、開発フレームワークを作る前に、まずAI Agentを制御するソースコードを開発することが優先だと気づきました。

結局、最初にAIとは何かを知ろうとして始めてからちょうど1か月で、AI Agentを完全に制御し（正確には外部LLMやAI Agentを必要としない）、AIによる100%実装 + 100%運用が可能なソフトウェアの開発を完了するという成果を達成しました。

現在は14日目で、さらなる高度化のためにそのMETA AIを追加学習させながら、運用規定を作って守らせるプロセスを進めています。また、従来人手によって不完全に作られていたMESシステム3件を同時に移行・改善し、さらに標準化も進めており、仕上げの段階に入っています。

そして今、また別の進化を準備しています。
 
spilist2 2025-07-09

しかし、プロンプトチェイニングにおいて、個々のプロンプトを実行するLLM、実行ワーカー、オーケストレーター・ワーカー、評価者LLMなどをそれぞれエージェントと呼んでも差し支えないのではありませんか？
 
spilist2 2025-07-09

ああ、「最終的なワークフロー制御（LLMが次のステップやツール使用の有無を直接決定すること）はエージェント的な特性と呼ばれる」ということですね。理解しました。自律エージェントを対象にして語った文章だったのですね。私がまだエージェントについてあまりよく分かっていなくて……
 
GN⁺ 2025-07-07
Hacker Newsの意見
  • エージェント開発は本当に面白かったが、「コンテキストエンジニアリング」に深刻な問題があるのは明らかだった。どれだけコンテキストウィンドウを広げても、エージェントに見せる要素をキュレーションする必要があり、本当に重要な情報だけを選び出す効果的なフィルタが不足していると感じる。だから *.md ファイルをあちこちにばらまくような形で補助する必要があり、役割分担も重要になる。この *.md システムは一種の原始的なメモリシステムであり、もっと堅牢に発展させられるはずだ。ユーザーとの相互作用に基づいてリアルタイムでプログラムやモデル（自然言語ベース）を作り出すことも可能だと思う。Claude Code を使っていて、テストスイートでエージェントを「操縦」することが非常に強力な強化学習メカニズムだと気づいたし、このループが大半うまく回るので、今後エージェントをより賢い協業者にできる新しいアイデアが出てくることを期待している
    • 実際の作業よりもツールとの格闘に多くの時間を使っている気がする
    • こうしたシステムで .md ファイルを構成するおすすめの方法があるのか気になる。人が読みやすいようにマークアップを多く入れると LLM の処理に問題が出ないか心配だ。人間向けと同じように .md ファイルを作った場合、それが LLM 利用の妨げにならないのか知りたい
    • 自分の経験では、コンテキスト管理がほぼすべての問題の核心だ。たとえば並列・再帰的な作業に合った正しいコンテキストを作ること、一部の段階（例: 前の応答の編集）は除外して修正済みの結果だけを見せること、自分がコメントを付けたときに、そのコメントによってエージェントが自分の出力を認識できるようにすることなど、実際にはさまざまな状況がある
    • テストスイートでエージェントを強化するという話が興味深い。具体的にどういう手順で進めているのか、もう少し詳しく説明してほしい
  • AI エージェントが人々がLinkedInで語るような形で大衆的に使われるかはまだ確信がないが、その可能性は残している。自分はいま Claude Code や Cursor のように、AI を強く統制しながら使っている。理由はモデルが足りないからではなく、自分で「テイスト」や方向性を頻繁に示したいからだ。AI により多くの自律性を与えることは、むしろあまり魅力的ではない。自分が介入してこそ、アイデンティティやつながりを感じられるからだ。今後、作業の進め方が変わったり新しい UX が出てきたりすれば考えが変わるかもしれないが、現時点では AI がエージェント的すぎることは望んでいない
    • 時間がたてばモデルの振る舞いをよく理解できるようになり、より多く／より良いコンテキストと指示を与えるだけで、ユーザーのテイストや方向性の要求をある程度満たせるようになると思うか気になる。自分の経験では、よくできたプロンプトエンジニアリングだけでもかなり多くのワークフローで AI を望みどおりに動かせるので、頻繁に介入しなくて済むことも多い
    • まったく同感だ。別の場所でも似たようなコメントをしたが、「ただ飯はない」という古い言い回しは今も正しいと思う。LLM が人間を完全に排除して問題を解けるなら、数行のプロンプトだけで誰もが同じ精巧なシステムを作れてしまうことになり、その時点でシステムごとの差別化や価値は失われる。もしプロンプトが新しい抽象化レベルだとしたら、たとえば Claude に「ノートアプリを作って」と頼むとき、何百万人もの人が同じ低コストのプロンプトを入力することになる。そのときプロンプターが付け加える意味とは何なのか疑問だ
    • 自分としては、時間がたつにつれて、こうした個々の「テイスト」要素もプロンプトとして徐々に体系化できると思っている。たとえばあるプロンプトでは、コード変更時に不要な可変性を生まず、可能ならすでに immutable で書くよう促す。別のプロンプトでは、無駄なログ出力を避けること（自分が具体的に定義したやり方で）などのルールを定める。コード変更をレビューするとき、これらすべてのプロンプトを個別に実行し、構造化された MCP 出力として集約している。こうした要素をコードエージェントに適用して、自動レビューの反復を実現している。もし自分でコンテキストを追加しなければならない状況が出てきたら、新しいプロンプトを作るか既存のプロンプトを拡張して補強する
  • 不思議なことに、キャリアが1〜2年しかなさそうな分野に「権威者」が現れる現象が面白い。まるで「2年目の言語で10年経験者を探すミーム」の逆バージョンみたいだ
    • 自分は GPT-3 が出た頃から「ai agent」と呼ばれるものを作ってきたし、自分以外にも同じ経験をした人は多い。もう5年もたっているので、5年たっても専門家が生まれないなら、もう専門家というもの自体が存在しないのだと思う。もちろん最近は「エージェント」という言葉がバズワード化していて、意味が薄れてきている
    • いざ「自分は数十のチームと一緒に働いた…」みたいな体験談を読むと、少し大げさに感じる
  • 要点のまとめ: 事前定義されたソリューションがあるなら、わざわざエージェントを使う必要はない（例: 記事に出てくる「パターン」）。たいていプログラマーは、プログラムで解ける問題に対しては、もっと単純で信頼できる解決法を勧める。将来は AI が本当に賢くなって、どんな問題でもブルートフォースで解決するのかもしれないが、今は複雑さを増やすだけだ。人々がエージェントに熱狂する理由の一つは、多くの人が LLM にチャットアシスタント用途で触れたからだと思う。こうしたチャットアシスタントは、定まった解決法がなく相互作用も複雑な場合が多いため、むしろエージェントが真価を発揮する。例: 「いちばん近い金曜の夜を探して、Bob に会えるか SMS を送って」――こういうものは、あらゆるケースをあらかじめプログラムするには限界がある。アシスタントとの相互作用の仕方がほぼ無限になり、エージェントが適してくる
    • 確認の速さが自分で直接やるより速いときは非常にうまく機能する。ただ、自分は検証なしで AI を信頼するのが難しい
  • なぜこんなに多くの例が結局「スパムを速く、もっと上手に送る方法」に行き着くのか疑問だ
    • まさにそれが例だったのではないかと思う。LinkedIn をクロールして人を見つけ、「パーソナライズされた」メールでスパムを送るという話だ
    • 車輪も結局油なしでは回らない、というたとえにできる
  • 2023年末〜2024年初めには正しかった話だが、いま2025年半ばあたりでは、SOTA LLM を使えば多くの作業には当てはまらないと思う。以前はたいてい関数として LLM を呼び出していたが、それはツール選択が間違っていた面もある。今の最上位 LLM（Gemini 2.5 Pro、Claude 4 など）は本当に賢くて、instruction following と ツール選択 の能力が非常に高い。チェックリストツールや delegate コマンド、タスク分割などは今でも必要だ。しかし、指示を作りコマンドを指定するやり方――特に UI 環境でツールコマンドを簡単に指定できるなら――は、ワークフローより柔軟で一段高い抽象化だ。視覚的ワークフローも結局は壊れやすく、調整が難しいプログラミングにすぎない。6〜12か月前にはこうしたことは不可能だったが、LLM が良くなければまだ当てはまらない。大局的には、instruction following と ツール連携 がうまいモデルが少数しかないので、こうしたモデルにエージェントを適用するのは有利だ。今後1〜2年のうちに、ブラウザ／コンピュータ活用エージェントの大規模なトレンドが生まれるだろう。彼らも優れたメモリシステムと「デモ／観察モード」を組み合わせ、ユーザーが UI を使う過程を学習（記録）するようになり、人間の口頭／文書による指示から最適化された手順も学習するようになるはずだ
    • 最近、最も強力なエージェントモデル（Claude Opus 4 など）が登場して、状況は完全に変わった。依然として良いコンテキストは必要だが、ツールに対する正確な選択が本当に素晴らしい
    • 元の投稿の手法は大半が「データフローグラフで問題をモデル化し、その通りに進める」ことだ。モデリングを飛び越えて「うまくやってくれるだろう」と考えるなら、それは工学ではなく信仰だ
  • この3週間、エージェントを安定して動かそうと努力してきたが、結局はるかに単純なパターンへ切り替えることになった。今のエージェントは、まるで「六本指の手」のような進化初期段階に感じられる
  • 「コーディネーターがタスク定義が明確でないと諦める」といった話を見て、「ならコーディネーターも捨てて命令型ロジックにしよう」と結論づける場合、実際にはプロンプトやツール説明をもっと具体的に書き、中間要約や LLM コンテキスト圧縮 のような手順を入れれば解決する問題かもしれない。記事に実際に使えるような長文のツール説明やプロンプト例すらないなら、判断はしにくい。直感的には、タスクに合ったオーケストレーションを使うのが答えだが、実際にはもっと多くのタスクでエージェント的オーケストレーションが効果的に使えると信じている
  • 自分も100%同意する。エージェントは本当に面白く、実験には向いているが、実際に生産性を上げるには、特定のワークフローやプロセスをうまくオーケストレーションし、AI でしかできない部分に集中するのが重要だ。参考までに、ai.intellectronica.net のAI ワークフローに関する記事もおすすめしたい
  • 最近よく見るのは、既存のワークフローオーケストレーションツールに LLM を導入して、はるかに簡単にシステムを構築していることだ。複雑さの大半は a) モデル自体（最新の研究所が使いやすいモデルを提供）、b) ワークフローの本番運用化（ワークフローツールが容易にしてくれる）にある。こうしたワークフローは既存業務に基づいているので、価値を容易に認識し、測定できる。このパターンが増えてきたので、Airflow（非常に人気のあるワークフローツール）向けに SDK をパッケージ化して公開した。
    https://github.com/astronomer/airflow-ai-sdk
 
sto1111 2025-07-08

私も現在 UseDesktop

https://youtu.be/aBkbsvMxP_A?si=uaugxKQEu4ZEz7jq

usedesktop.com

という Computer-use Agent を作っていますが、ほとんど同意です。

この記事では実践的なコツというより大きな overview だけを扱っているので、LLM based agentic/agent を開発するときのコツをいくつか補足すると、結局 LLM はトランスフォーマー（i.e probabilistic based 推論、現在のトークン/state をもとに次のトークンを文脈的/semantic に理解して次の単語を吐き出すというより、確率的に output する）ベースなので、どれだけ sys prompt をうまく書いても、しばしば欲しい回答を返さないことが多いです（e.g JSON output で答えてほしいのに、たまに } を忘れる、など）。なので、常に regex ベースの複数の fallback fn を追加するのは必須です。

そして structured output を与える sys prompt を書くなら、通常は non reasoning model を使い、context が長くなればなるほど hallucination が頻繁に発生するので、むしろ sys prompt を複数作って chaining するほうが良いです。

サービスを開発する場合はさまざまなエラーが発生しうるため、モジュール化し、fault tolerant にサービス構造を設計することが重要です（e.g supervisor agent は async にし、残りの agent は sync にする）。特に unexpected output が頻繁に発生する agentic / agent ではなおさらです。 だから最初からできるだけコードを書くときに SRP を守りつつ declarative に書くのがよく、関数型でアプローチするのが良いと言いたいです（= side effect がなく、フローが直感的）。

また、LLM を API 経由で使うのか、それとも直接モデルサービングをするのかによっても違いますが、もし直接 SLM や LLM をサービングするなら、バックエンドをホスティングしているのと同じサーバーで Model serving をせず、IO bound task と CPU bound tasks（i.e GPU が必要で、行列積のような処理が必要な task）を別サーバーに分けて置くほうが fault tolerant で良いです（e.g runpod に cpu bound task をホスティング）。

このほかにも開発のコツはいろいろありますが、長くなりすぎそうなのでここまでにしておきます。

誰かの役に立てばうれしいです。
 
jypark 2025-07-09

貴重なご経験とご意見を共有してくださり、本当にありがとうございます。現場にいらっしゃる方のご意見は、本当に大変参考になります。