top of page

AIでワークフローを作るのか?エージェントを作るのか?この問いを間違えるとあなたのAI活用は永遠に中途半端なまま終わるかもしれない。

  • 執筆者の写真: yuki kato
    yuki kato
  • 12 分前
  • 読了時間: 13分

AIを業務に組み込もうとするとき、ほとんどの人は最初の分岐を意識しないまま走り出します。


その分岐とは…

自分はいまワークフローを作ろうとしているのか?


それともエージェントを作ろうとしているのか?

という問いです。


私はこの問いこそがAI活用内製化の成否を分ける最初の関門だと考えています。


そもそもこの2つは、似ているようでいて思想がまるで違います。


ここを混ぜたまま設計に入ると、ワークフローで十分なものに過剰な自律性を持たせて暴走させたり、本来エージェントにすべきものを固いワークフローに押し込めて使いものにならなくしたりします。


よって、この問いそのものの概念を整理することから始めたいと思います。



なぜこの2つを区別する必要があるのか?


世間一般では、AI活用といえばChatGPTやClaudeに指示を出して回答をもらう、という1往復のイメージで語られがちです。


プロンプトを工夫すればいい、という話に終始します。


確かにそれもAI活用ではあります。

ですが業務に本気で組み込もうとした瞬間、1往復では足りなくなります。


複数の処理をつなげたい

外部のツールを呼び出したい

判断を挟みたい

こんな欲求が必ず出てきます。


ここで多くの人が、なんとなく

「自動化」という言葉で全部をひとくくりにしてしまいます。


私はこの自動化という言葉の雑さに、ずっと違和感を持っていました。


自動化と一口に言っても、その内実には2つのまったく異なる思想が同居しているからです。


片方は手順をあらかじめ全部決めておいて、AIにはその決められた道を歩かせる思想です。


もう片方は、ゴールだけ渡してそこへどう辿り着くかはAI自身に考えさせる思想です。


前者がワークフロー、

後者がエージェントです。


この区別はAnthropic自身が明確に言語化しています。


ワークフローとは、LLMとツールがあらかじめ書かれたコードの経路に沿って制御されるシステムのこと。


エージェントとは、LLMが自分自身でプロセスとツールの使い方を動的に方向づけ、どうタスクを達成するかを自分で決めるシステムのことです。


つまり違いの本質は機能の差ではなく、制御を誰が握っているかの差なんです。


経路を人間が握っているのがワークフロー。


経路をAIに委ねているのがエージェント。


ここを起点に考えると、すべての設計判断が一本の軸で見えてきます。



ワークフローから説明します


まずワークフローから入るのには理由があります。


ワークフローは制御を手放さない設計なので、挙動が予測可能で検証もしやすく、失敗してもどこで止まったかが分かります。


AIを業務に組み込む最初の一歩としては圧倒的に安全で、しかも成果が出やすい。


だからエージェントよりも先に、ここを徹底的に理解すべきだと私は考えています。


ワークフローというのは、要するに処理のブロックを直列・並列・分岐でつないだ流れ図です。


各ブロックの中でAIが働く。

でも次にどのブロックへ進むかは設計者が事前に決めてある。


AIは賢い部品として、決められた持ち場で決められた仕事をする。


経路そのものを変える権限はAIに与えられていません。


ワークフローには、いくつかの典型的な型があります。

順番に背景例と解決方法を出しながら見ていきます。




■ワークフローの型1:

処理を直列につなぐ(プロンプトチェーン)


たとえば私がやっているX投稿代行。


1つの投稿を作るとき、頭の中では実は複数の工程が走っています。


まずクライアントの伝えたい核を1行に絞る。次にそれを投稿の型に流し込む。最後にトンマナを整える。


これを1回のプロンプトで全部やらせると、どこかが必ず雑になります。


核がぼやけたまま型に入ってしまったり、トンマナを整える段でメッセージが薄まったり。


解決方法としては…

工程を3つのブロックに割って直列につなぐ。


1つ目のブロックは核を1行に絞ることだけに集中させる。その出力を2つ目のブロックに渡して型に流し込む。さらにその出力を3つ目のブロックに渡してトンマナを整える。


各ブロックは1つの仕事しか担わないので、それぞれの精度が上がります。しかも途中の出力を人間が確認できるので、どこで品質が落ちたかがすぐ分かる。


ここで効くのが、ブロックとブロックの間に検問所を置く発想です。


1つ目のブロックが出した核が、そもそもズレていたら2つ目に進ませない。条件を満たさなければ差し戻す。


この検問所があるだけで最終成果物の質が劇的に安定します。


直列につなぐとはただ並べることではなく、間に判断を挟めるということなんです。




■ワークフローの型2:

入力を仕分けてから処理する(ルーティング)


弊社には採用支援の相談もあれば、AI導入の相談もあれば、X投稿代行の問い合わせもきます。


これを全部おなじプロンプトで処理しようとすると、どうしても無理が出ます。


採用の相談に最適な思考の型と、AI導入の相談に最適な型はまるで違うからです。


1つの万能プロンプトは結局どの領域でも平凡な答えしか返しません。


解決方法は入り口に仕分け係を1人立てることです。


まず最初のブロックでこの問い合わせはどの種類か?を判定させる。


採用なのか、AI導入なのか、X投稿なのか。

判定結果に応じてそれぞれ専用に作り込んだ別のブロックへ流す。


採用には採用の文脈をたっぷり持たせたブロック、AI導入にはAI導入の文脈を持たせたブロックへ振り分ける。


この型のうまみは、各専用ブロックを思いっきり尖らせられる点にあります。


1つのプロンプトに全部詰め込むと、あれもこれもと指示が増えてどんどん鈍ります。


仕分けてしまえば各ブロックは自分の領域だけに最適化できる。


仕分け係というたった1ブロックを足すだけで、システム全体の解像度が上がるわけです。




■ワークフローの型3:

仕事を分割して同時に走らせる(並列化)


あるクライアントの求人原稿を作るとき、私は1つの原稿を複数の観点から同時に評価したいことがあります。


求職者に響くかという観点、誇大表現になっていないかという観点、検索で見つかりやすいかという観点。


これを1つのブロックに全部背負わせると、観点同士が干渉してどれも中途半端なチェックになります。


解決方法は、おなじ原稿を3つのブロックに同時にコピーして渡し、それぞれ別の観点だけで評価させることです。


求職者目線のブロック、コンプライアンス目線のブロック、検索最適化目線のブロック。


3つを並列で走らせて、最後に結果を1つに束ねる。

各ブロックは1つの観点に専念できるので、チェックが鋭くなります。

しかも同時に走るので、直列より速い。


並列化にはもう1つの使い方があります。おなじ仕事を複数回やらせて多数決を取る、という使い方です。


投稿のキャッチコピーを5案出させて、その中から良いものを選ぶ。


1回の出力に賭けるより、複数の出力から選ぶほうが当たりを引きやすい。

分割して同時に走らせるという発想は観点を分けるだけでなく、試行回数を稼ぐためにも使えるんです。




■ワークフローの型4:

司令塔が仕事を割り振る(オーケストレーター方式)


ホームページの改善提案書を作る場面を考えます。

これは事前に何ブロック必要かが読めません。

ページ構成の分析が必要なときもあれば競合調査が深く要るときもあるし、採用ページだけ重点的に見る案件もある。


型1から型3までは、ブロックの数と並びを設計者が固定していました。


でも案件によって必要な作業が変わる場合、固定した流れでは対応しきれません。


解決方法は司令塔のブロックを1つ立てて、その司令塔に作業の分解と割り振りをさせることです。


司令塔はまず、この案件には何の作業が必要かを洗い出す。

そして、洗い出した作業を実働のブロックたちに割り振る。

各実働ブロックが仕事を終えたら、司令塔が結果を回収してまとめる。


ここまでくると、エージェントとの境界が少し曖昧に感じられるかもしれません。


実際司令塔がその場で作業を分解する点は、自律性の入り口に近い。


ですが決定的な違いがあります。

司令塔がやれることの枠組み、つまりどんな作業を割り振っていいか?どのツールを使っていいかは?設計者があらかじめ定めた範囲に収まっているんです。


経路の自由度は上がっても、外枠は人間が握っている。

だからこれはまだワークフローの側にいます。




■ワークフローの型5:

自分の出力を自分で直させる(評価と改善のループ)


ブログを書かせると初稿はだいたい甘いです。

論理が飛んでいたり、結論がぼやけていたり。


私が手で直すのが普通ですが、その直しの観点はある程度言語化できます。だったらその観点をAI自身にチェックさせて直させられるはずです。


解決方法は生成するブロックと評価するブロックの2つを向き合わせて、ループを回すことです。


生成ブロックが初稿を出す。

評価ブロックがあらかじめ決めた基準で採点して、ダメな点を指摘する。

指摘を受けて生成ブロックが書き直す。

これを基準を満たすまで繰り返す。


人間が初稿と完成稿の間でやっていた往復を、機械の中で回してしまうわけです。


この型が効くのは、良し悪しの基準が明確に言葉にできる場合です。

基準を言語化できないものには向きません。


ループの回数に上限を設けておかないと延々と回り続けることもあるので、そこは設計者が手綱を握っておく必要があります。



ここまでがワークフローです。

5つの型を振り返ると、共通しているのは1点です。


AIがどれだけ賢く働いても、経路の設計図そのものは人間が握っている。


AIは図の上を動く部品であって、図を描き換える権限は持っていない。

これがワークフローという思想の核です。



次にエージェントを説明します


エージェントは最後の一線を越えます。

経路の設計図をAI自身に描かせるんです。


エージェントは、ゴールと使えるツール群だけを渡されます。

そこからどういう順番で何をするか、どのツールをいつ呼ぶか、いつ終わりにするかをAIが自分で判断しながら進めます。


途中で環境から返ってきた結果を見て、次の一手を変える。

うまくいかなければやり直す。

この状況を見て自分で次を決めるループを回し続けるのがエージェントです。


ワークフローが地下鉄だとしたら、エージェントはタクシーです。


地下鉄は線路が敷かれていて、駅の順番は決まっている。


タクシーは目的地だけ告げれば、どの道を通るかは運転手が状況を見て決める。

渋滞していれば迂回するし、近道があれば使う。


このその場で経路を選ぶ自由こそがエージェントの本質です。




■エージェントの背景例


私が普段やっている、AI導入の現状調査を例にします。


あるクライアントの業務にどこからAIを入れられるか?を調べるとき、最初から手順は決まっていません。


まず何の業務があるか聞き出す必要があるかもしれないし、既存のツールを調べる必要があるかもしれない。


聞いた内容によって、次に調べるべきことが変わります。Aと答えたらBを掘る、Cと答えたらDを掘る、という分岐が無限に枝分かれしていく。


これをワークフローで設計しようとすると、ありとあらゆる分岐をあらかじめ図に描かなければなりません。


でも現実の調査は相手の答え次第で進路が変わるので、全分岐を事前に描くのは不可能に近い。


ここがワークフローの限界点です。

経路が事前に読めないとき、固い流れ図はむしろ足かせになります。



■エージェントによる解決方法


解決方法は経路の決定そのものをAIに委ねることです。

AIにゴール、つまりこのクライアントにAIを導入できる箇所を洗い出す、というゴールを渡す。


あわせて使えるツール、たとえば質問する、業務一覧を取得する、既存ツールを調べる、といった道具を渡す。

あとはAIが自分でいま何を知るべきか、そのためにどのツールを使うかを判断しながら進めます。


AIは1手打つたびに、返ってきた結果を見ます。

業務一覧を見てここが手作業で重そうだと判断したら、その業務を深掘りする方向へ自分で舵を切る。


十分な情報が集まったと自分で判断したら、調査を終えて結論をまとめる。

この一連の判断を人間が指図せずにAIが回す。

これがエージェントによる解決です。


ただし、ここには代償があります。

自由を与えるということは、予測不能性を受け入れるということです。

AIが想定外の経路を選ぶこともあるし、ツールを誤って使うこともある。コストも読みにくくなります。


何手で終わるか事前に分からないからです。

だからエージェントを作るときは、暴走を止める仕組みが必須になります。


何手まで、いくらまで、という上限を必ず設ける。


危険な操作の前には人間の承認を挟む。自由を与えるほど、外側のガードレールを厚くする必要があるんです。



ここまでを踏まえて私なりに2つを定義し直します。



ワークフローとは…


人間が経路を設計し、AICにその経路上で賢く働いてもらう仕組みです。

制御は人間にある。

だから予測でき、検証でき、安く済む。代わりに、事前に経路が読めない仕事には対応できません。



エージェントとは…


人間がゴールと道具だけを渡し、経路の決定をAIに委ねる仕組みです。

制御はAIにある。

だから事前に読めない仕事にも対応できる。代わりに、予測しにくく、検証しにくく、コストが膨らみやすい。



つまりこの2つは、優劣の関係ではありません。

制御をどこまで手放すかというダイヤルの両端なんです。


完全に握るのがワークフロー、大きく委ねるのがエージェント。


実際の現場ではこのダイヤルを案件ごとに回して、ちょうどいい位置を探ることになります。


そして私がいちばん伝えたいのはここです。


多くの人は、いきなりエージェントを作りたがります。 


自律的に動くAIは魔法のように見えるからです。

でもほとんどの業務はワークフローで足ります。


経路が読めるならわざわざ経路をAIに委ねる必要はない。


委ねた瞬間に予測不能性とコストを抱え込むことになるからです。


だから設計の鉄則はこうです。

まずワークフローで解けないかを徹底的に考える。

経路が事前に描けるなら、ワークフローにする。

どうしても経路が事前に描けない、相手次第で進路が変わる、というときだけエージェントに踏み込む。


複雑さは本当に必要なときにだけ足す。これが私の結論です。



ところで…あなたがいまAIにやらせたいと思っているその仕事は、経路を事前に描けますか?


もし描けるなら、それはワークフローの仕事です。


エージェントという派手な選択肢に惑わされず、まずは処理を分けて、間に検問所を置くところから始めてみてください。


もし描けないなら、つまり相手や状況次第で進路が枝分かれしていくなら、そのときはじめてエージェントの出番です。


この問いを最初に立てられるかどうかで、あなたのAI活用が中途半端で終わるか、複利的に積み上がっていくかが決まります。


私はAIを便利な道具としてではなく、自分の思考を外に出して回し続けるための土台として捉えています。


ワークフローとエージェントの区別は、その土台をどう組むかの設計思想そのものなんです。


あなたなら、最初のどの仕事を、どちらで組みますか?



合同会社Lepnet 

代表社員 加藤勇気 http://lepnet.biz 

異次元の成果を出す最強求人顧問 

AI未来鑑定士 

1日1000円のX投稿代行

コメント


〒330-9501 埼玉県さいたま市大宮区桜木町2−3 大宮マルイ 7階 アントレサロン大宮内

  • X
  • Instagram
  • Facebook
  • YouTube
  • Google Places

©2021 by 合同会社Lepnet

bottom of page