導入

金曜日の午後4時、マーケティングチームのリーダーである李秀珍さんは、モニターの前でため息をつきます。競合他社5社の価格政策が変更されたというニュースがSlackに届き、CEOは月曜日の朝の会議までに競合分析レポートの提出を求めていました。かつてであれば、各競合他社のウェブサイトを一つずつ開いて価格表をコピーし、Excelに転記し、PowerPointでチャートを作成するのに週末の半分を費やす必要があったでしょう。

しかし、李秀珍さんはノートパソコンを開き、Claude Codeに一文を入力します。「当社ブランドガイドラインに基づき、競合他社5社の最新価格政策を分析し、PDFレポートを作成してください。」15分後、社ロゴとカラーリングを反映した12ページのレポートが画面に表示されます。

これがエージェント型ワークフロー（Agentic Workflow）の姿です。人間が各手順を手動でつなぐのではなく、AIエージェントが自ら判断し、ツールを選択し、エラーを修正しながら成果物を完成させます。

80億ドルから500億ドルへ：エージェント型AI市場の爆発的成長

まず数字から確認しましょう。エージェント型AI市場の規模は2025年時点で約80億ドル（日本円換算で約11兆円）と推定されています。業界の予測によれば、2030年までに400億〜500億ドル（日本円換算で約55兆〜69兆円）規模に成長すると見込まれています。これは小さな飛躍ではありません。目の前で一つの産業が形成されつつあるのです。

これらの数字が単なる予測に過ぎないと考える方もいるかもしれません。しかし、現場での動きはすでに始まっています。世界の企業の約25%がエージェントの試験導入プロジェクトを稼働させており、2027年にはその割合が50%に達すると予測されています。主要企業2社に1社がエージェントの作業フローを運用する時代が到来するということです。

これに伴い、大規模な予算投入、新たなセキュリティ要件、そしてこのシステムを構築できる人材への需要が同時に急増しています。

企業の25%がすでに導入したエージェントの試験運用

エージェントの試験運用（アジェンティック・パイロット）とは、企業が本格導入に先立ち小規模で実験するエージェント作業フロープロジェクトを指します。全社展開前に、特定の部署や業務にまず適用して検証するものです。例えば、マーケティングチームで競合他社のモニタリングを自動化したり、営業チームで潜在顧客リストの作成をエージェントに任せるようなケースです。

このパイロット段階において、企業たちが共通して発見する事実があります。エージェントのワークフローは、構築過程において自ら問題を解決します。従来の自動化ツールでワークフローを構築する際は、開発者が例外ケースを一つひとつ事前に予測し、処理ロジックを組み込む必要がありました。

エージェントのワークフローでは、実行中にエラーが発生すると、エージェントがその原因を分析し、アプローチを変更し、ツールを修正した上で継続して進めます。この自己修復能力が、構築段階の生産性を劇的に向上させます。

従来の自動化の天井と、エージェントへの転換を促す原動力

n8nやZapierのような自動化ツールでワークフローを構築した経験があれば、そのプロセスをご存じのことと思います。各ステップを設計し、ノードを接続し、例外ケースを直接処理します。順調に動作します。予期せぬ入力が入るまでは。従来のワークフローは、予期せぬ事態に直面すると停止してしまいます。

誰かがログを開いて、どこでどのようなエラーが発生したかを確認し、手動で修正する必要があります。それがメンテナンスであり、時間であり、コストです。

企業がエージェントへの移行を急ぐ背景には、これがあります。従来の自動化が到達できる天井にぶつかったのです。単純な反復作業は自動化で解決しましたが、判断を要する業務、文脈によって処理経路が変化する業務、例外が頻発する業務の前では、既存のツールは限界を露呈します。エージェントのワークフローは、その限界を超えて機能します。

大規模言語モデル（LLM）が推論し、判断し、複数の段階にわたる作業を一貫して実行できるレベルに到達したからです。

ここに、MCP（Model Context Protocol）のような標準化されたツール接続プロトコル、VercelやModalのようなデプロイインフラ、そしてClaude Codeのような非開発者向けのエージェントツールが登場し、エージェントワークフローを構築するために必要な技術的障壁が急速に低下しています。

列車のレールに例える：手作業による建設から建設クルーへの委任へ

エージェントワークフローの価値を理解する上で役立つ比喩があります。

従来の自動化は、手作業で列車のレールを敷くようなものです。レール、分岐点、接続部をすべて直接設置します。一方、エージェントのワークフローは、建設クルーに「ここからあそこまでレールを敷いてください」と指示を出すようなものです。建設クルーが作業中に岩盤にぶつかった場合、自ら迂回経路を見つけます。その結果、より優れたレールが、より速く、より少ないミスで完成します。

それは、構築の過程で人間が思い浮かべられなかった例外事態をエージェントが処理してくれるからです。

デプロイ前には、このレールを徹底的に試験します。重量の異なる列車、長さの異なる列車、車輪規格の異なる列車を交互に走らせます。さまざまな種類の列車が問題なく走行できるという確信が持てて初めて、レールを実際の運行に投入します。これがエージェントワークフローにおける構築・検証・デプロイのサイクルです。

自己修復とデプロイの境界：エージェントをデプロイするのではなく、コードをデプロイする

エージェントワークフローに関するオンライン上の議論には、誇張が含まれています。「一度作れば、永遠に自ら修復しながら稼働し続ける」といった話です。この言葉は半分だけ正しいのです。どの文脈で実行されるかによって異なるからです。

Claude Code 内で直接ワークフローを実行すると、エージェントがそばにいます。作業中にエラーが発生すれば、エージェントが即座に検知し、アプローチを修正し、ツールコードを直して続行します。自己修復がリアルタイムで行われます。

しかし、ワークフローを予約実行に切り替えたり、ウェブフックトリガーに接続して自動実行させたりすると状況は異なります。このときデプロイされるのは、ワークフロー（W）とツール（T）のコードであり、エージェント（A）そのものではありません。WATフレームワークでは、W と T だけがクラウドへ移行し、A は残されます。エージェントなしで実行されるコードは、従来の自動化と同様に、同じ入力には同じ結果が返る方式で動作します。

これは弱点のように思えるかもしれませんが、むしろ強みです。予測可能で、反復可能、結果が一定な自動化こそが、運用環境において最も信頼できる形態だからです。エージェントワークフローの真の利点は、「デプロイ後に永遠に自己修復する」ことではなく、「構築プロセスにおいて、はるかに迅速かつ精巧に作れる」ことにあります。

建設クルーが軌道敷設を終えた後、その軌道自体は堅牢で予測可能なレールの上を列車が走ります。

李秀珍さんの競争分析レポートは、月曜日の朝の会議テーブルに置かれました。CEO はレポートのグラフをめくりながら、「これを一人でやったのですか？」と尋ねました。李秀珍さんは頷きながら、頭の中では別の問いを巡らせていました。このレポートを作成したエージェントを、他部署でも活用できるのではないか。そして、この技術を教える人が現れたら、そこにもビジネスチャンスがあるのではないか。

[図 2-01: エージェント型 AI 市場規模の成長推移。2025 年の約 80 億ドルから 2030 年には 400 億〜500 億ドルへと成長する曲線を示すグラフ。]