AIエージェントとAIワークフロー:本番で本当に使えるのはどれか

公開: 2026年5月12日

最終更新: 2026年10月5日

AIエージェントとAIワークフロー:本番で本当に使えるのはどれか

2026年のベンダー資料は、どれも「エージェント」と書いてあります。しかし実際に本番で動いているものの多く(エージェント企業を名乗る会社の内部でさえ)は、もっと単純な構成です。これは批判ではありません。6か月後もそのシステムが動いている理由そのものです。

この混同は高くつきます。「エージェント」を買ったチームは信頼できるシステムを期待し、即興で動くデモを受け取り、「AI自動化は使えない」と結論づけます。多くの場合、技術に問題はありませんでした。仕事に対してアーキテクチャが間違っていたのです。

ワークフローか、LLMステップか、エージェントか:実際のスペクトラム

「エージェント」はYes/Noで決まる性質ではありません。3つの段階があり、リスクと運用コストの差は、能力の差よりも大きいのが実情です。

  • 決定的ワークフロー。 固定の手順を固定の順序で実行し、モデルは何も判断しません。請求書が届き、ルールでフィールドを抽出し、レコードを書き込む。退屈でテスト可能。そして今でも、驚くほど多くの自動化の正解です。
  • LLMステップを含むワークフロー。 構造は固定のまま、個々のステップでモデルを呼びます。このメールを分類する、この文書を要約する、JSONスキーマへフィールドを抽出する。次に何が起こるかをモデルは決めません。決めるのはワークフローです。
  • ツールを使うエージェントループ。 モデルはゴールとツール群を渡され、実行時にどのツールをどの順で呼ぶか、いつ終わるかを自分で判断します。能力はここで最大になります。ばらつきも最大になります。

有用な問いは「エージェントが欲しいか」ではありません。「このスペクトラム上で、この問題を解く最も安い点はどこか」です。

2026年に本番へ届く構成と、デモ映えで終わる構成

当社が自ら構築・運用しているシステムでは、パイロットを越えて生き残るのは中間の段階(LLMステップを含む固定ワークフロー)です。SLAの下に置けるほど予測可能で、量を捌けるほど安く、深夜2時にデバッグできるほど単純だからです。

エージェントループも本番に届きます。届くものには共通点があります:狭いゴール、10未満のツール、上限つきの反復回数、そして取り返しのつかない操作の手前にある人間のゲート。パイロットで止まるものにも共通点があります。

  • 反復回数に上限がなく、類似タスク間で実行時間とコストが20倍ぶれるリサーチエージェント
  • 承認ステップなしで基幹システムに直接書き込むエージェント
  • 評価セットではなく印象(「賢そう」)で判断されるエージェント
  • 「念のため」社内のすべてのツールを渡されたエージェント

エージェントが本当に勝つ場面

  • オープンエンドな調査。 ベンダー比較、市場スキャン、デューデリジェンスの下調べ。手順を事前に書き下せないため、固定ワークフローでは表現できません。
  • エスカレーションつきのトリアージ。 受信チケットや共有インボックス。簡単な大多数をエージェントが処理し、確信度がしきい値を下回るものは人へ回す。このエスカレーション経路こそが本番品質の根拠です。
  • 既存のレビューゲートの内側でのドラフト作成。 人がもともと全件レビューしている提案書、返信、レポート。エージェントのばらつきは、もともと存在するレビュー工程が吸収します。

ワークフローが勝つ場面

  • SLAのあるすべての業務(応答時間と1実行あたりコストが予測可能であること)
  • 大量処理。失敗率2%が月数百件のインシデントを意味する場面
  • 規制・監査対象のステップ。何がなぜ起きたかを正確に説明する義務がある場面
  • 1年間変わっていない安定した業務(エージェントが判断すべきことが残っていない)

最初のエージェントPoCを安全にスコープする

最初のエージェント案件は、オープンエンドにした時点で失敗します。対策は、通常のAIワークフロー自動化と同じ規律に、エージェント固有の4つのルールを足すことです。

  • ツールの限定。 型付きの入出力を持つ3〜7個のツール。読み取り専用ツールは安く許可できますが、書き込みツールは1つずつ正当化が必要です。
  • 初日からの監査ログ。 すべてのツール呼び出し、モデルの判断、入出力を1つのテーブルに記録します。任意でもフェーズ2でもありません。パイロットをデバッグする手段そのものです。
  • 人間の承認ゲート。 取り消しコストの高い操作(送信、支払い、削除、公開)は、人が処理するキューに入れます。パターンはAIワークフローの人手レビューにまとめました。
  • ローンチ前の評価セット。 正解について合意済みの実例30〜50件。チームがこれを用意できないなら、「動いている」の定義を誰も言えないということであり、開発を始めるべきではありません。

このスコープなら、最初のエージェントは2週間スプリントに無理なく収まります。当社の短期DX PoC(¥1,880,000-¥2,780,000)の形そのものです:1つのエージェント、1つのキュー、毎週のデモ、そして最後に「感触」ではなく評価レポート。

判断チェックリスト

予算を確定する前に、上から順に確認してください。

  • 手順を事前に書き下せるか?→ 決定的ワークフローを作る。
  • 手順は固定だが、一部に判断(分類、抽出、要約)が要るか?→ LLMステップを含むワークフロー。
  • ケースごとに経路が本当に変わり、列挙できないか?→ エージェント候補。
  • レイテンシや1実行コストにSLAがあるか?→ 設計をワークフロー側へ戻す。
  • 取り返しのつかない操作はすべて人間のゲートの内側か?違うなら、足すか止める。
  • 正解が分かっている実例が30件以上あるか?なければ、まず集める。
  • タスクごとの反復回数と支出に上限を設定できるか?できなければ、まだ配備できない。

デモが指す場所より、1段下から始める

エージェントを本番に届けるチームは、ほぼ例外なく、ベンダーのデモが指した場所より1段下から始めています。今四半期に出荷するワークフローが、データ契約、失敗モード、レビューの習慣を教えてくれます。来四半期のエージェントはその上に立ちます。しかもその間、ワークフロー自体が元を取ってくれます。

特定の業務がスペクトラムのどこに属するかを決めかねているなら、当社のパッケージは、その問いに書面で答える1週間の監査から始まります。スコープを切ったUrbano本人が構築まで担当します。再委託はないため、答えと納品が乖離しません。

このテーマでPoCを始める

アプリ、API、LLM機能、AIワークフローの目的、データ状況、希望時期をお知らせください。

相談する