Hana’s Note
はじめに
AIを使った自動化を調べていると、Agentという言葉が目に入ります。目的を伝えれば、AIが次の手順を考え、ツールを使い、結果を見ながら作業を進める仕組みです。けれども、すべての仕事に最も自律的な構成が必要とは限りません。
この記事では、あらかじめ決めた流れで進めるWorkflowと、状況に応じて次の行動を選ぶAgentを、優劣ではなく設計の選択肢として整理します。
AIで自動化する仕事は、同じ形ではない
「AIで仕事を自動化する」と聞くと、一つの大きな仕組みがすべてを処理するように想像しがちです。実際には、仕事の性質によって必要な仕組みは変わります。
たとえば、毎朝同じ項目を集めて定型レポートにする仕事なら、入力、集計、文章化、保存の順番を先に決められます。資料を決まった列へ変換する作業も、入力と出力の形式を定めやすい仕事です。
一方で、「このテーマについて調べ、足りない情報があれば別の資料を探して」と頼む場合は、最初から必要な手順をすべて書くのが難しくなります。調査の途中で、検索先や次に確認する条件が変わるからです。
見るべきなのは、どちらがAI向きかという順位ではありません。手順を予測できる仕事か、状況を見て次の行動を変える必要がある仕事かを見分けます。
Workflowとは何か
Confirmed｜設計解説から確認できること
Anthropicは、大規模言語モデル（LLM）とツールをあらかじめ決めたコード経路で組み合わせるものをWorkflow、LLMが処理やツール利用を動的に決めるものをAgentとして区別しています。これは同社の設計上の整理であり、業界全体に一つの定義が確定しているという意味ではありません。
Workflowは、処理の道筋を先に設計する構成です。たとえば、次のような流れです。
入力を受け取る
↓
内容を分類する
↓
決めた処理を実行する
↓
形式を確認して保存する途中でLLMを使って分類や文章化を行う場合もあります。条件による分岐や、複数の処理を並列に実行する設計もWorkflowに含められます。したがって、Workflowを「AIを使わない単純なプログラム」と限定するのは正確ではありません。
Article interpretation｜Workflowの向きやすい条件
Workflowは、手順、入力、出力の形式を比較的予測できる仕事に向きます。経路を先に決められるため、どの段階でモデルを呼び出すか、どこに権限が必要か、どの結果を保存するかを確認しやすくなります。
再現しやすい流れを設計できても、結果が正しいと保証されるわけではありません。途中のモデル出力、入力データ、外部サービスの状態は確認が必要です。
Agentとは何か
Confirmed｜Agentに含まれる要素
OpenAIの実務ガイドは、Agentの基本要素としてモデル、ツール、指示を挙げています。モデルが状況を読み、外部のデータや機能へ接続するツールを選び、指示とガードレール（AIの行動を制限するルール）の範囲で処理を進めるという考え方です。
Agentは、決められた目的に向けて、次の処理やツール利用を状況に応じて選ぶ構成です。検索結果を見て別の検索を行う、ファイルを変更したあとテスト結果を確認する、といった複数段階の作業が候補になります。
Agentは、何でも自由に実行する存在ではありません。どのツールを使えるか、どのデータへ触れられるか、いつ停止するか、どの段階で人間へ戻すかを設計したシステムです。
Agent化すると、設計するものが増える
Agentを使う場合は、少なくとも次の項目を決める必要があります。
- 権限：読み取りだけか、ファイル変更や外部送信まで許可するか
- 停止条件：最大反復回数、時間制限、予算、エラー時の停止方法
- 人間確認：送信、購入、公開、削除などの前に承認を求めるか
- ログ：どの指示で、どのツールを使い、何が返ったかを追跡できるか
- 失敗時対応：再試行するか、別の手順へ戻るか、人間へ引き継ぐか
MCP（AIアプリケーションと外部ツールをつなぐための仕様）の認可仕様でも、アクセス権を設計することが前提になっています。ツールが使えることは便利さだけでなく、外部へ影響を及ぼす可能性も意味します。
WorkflowとAgentは、連続した設計として考える
Source-derived observation｜段階的なパターン
Anthropicの解説では、単純な処理を組み合わせるパターンから、モデルがサブタスクを分け、次の行動を動的に決めるAgentまで、複数の構成が紹介されています。記事ではこれを複雑さの順位ではなく、選択肢が増えていく設計の連続として扱います。
たとえば、最初は一つのLLM呼び出しで足りる仕事でも、出力の確認を加えたり、入力の種類ごとに処理を分けたりできます。Agentへ移る前に、固定できる部分をWorkflowとして残す設計も可能です。
この連続性を意識すると、「WorkflowかAgentか」という二択ではなく、「どの段階まで柔軟性が必要か」という問いに置き換えられます。
どちらを選ぶか
以下は、設計を考えるときの目安です。一律の判定表ではなく、確認すべき条件を並べたものです。
| 視点 | Workflowを先に検討しやすい条件 | Agentを検討する条件 |
|---|---|---|
| 手順 | 順番を事前に決められる | 状況に応じて順番が変わる |
| 入力 | 形式や種類がそろっている | 曖昧で、途中の理解が必要 |
| 出力 | 固定の列・形式・保存先が必要 | 調査結果に応じて内容が変わる |
| 例外 | 主要な例外を先に列挙できる | 例外の種類を事前にすべて予測しにくい |
| コスト | 呼び出し回数や処理時間を見積もりたい | 柔軟性に追加コストを払う価値がある |
| 確認 | 確認点を固定できる | 状況ごとに判断や承認が必要 |
どちらを選んでも、人間の確認点は設計に残ります。必要な柔軟性と、許容できる運用負荷を同時に考えます。
具体例で考える
Workflow向きの概念例：定型レポート
毎日の売上データを読み、決められた項目を集計し、同じ形式のレポートへ保存する仕事を考えます。入力、集計の手順、出力の項目が決まっているなら、取得、変換、検算、保存をWorkflowとして固定できます。
文章の要約や異常値の説明にLLMを使うことはできますが、保存先や列順まで毎回モデルに決めさせる必要はありません。固定できる部分をプログラムや決まった処理へ分け、内容の解釈だけをモデルに任せる設計です。
Workflow向きの概念例：データ変換
複数の入力を同じ列順へ変換し、ファイル名をそろえて保存する仕事も、Workflowを先に検討しやすい例です。入力の違いを分類する段階だけLLMを使い、変換と保存は固定することもできます。
Agentを検討する概念例：状況で調査先が変わる調査
「あるテーマについて、信頼できる資料を探して要点をまとめる」という依頼では、最初から必要な検索語や資料数を決められないことがあります。検索結果を読んで不足を見つけ、別の資料を探し、矛盾を確認する必要があるなら、Agentの柔軟性を検討できます。
Agentに任せれば調査が正しくなるわけではありません。使用できる情報源、検索回数、出典の確認、停止条件を決め、最終的な主張は人が一次資料へ戻って確認します。
Agentを検討する概念例：複数ツールを使う作業
ファイルを読み、必要な計算を行い、結果に応じて別のデータを参照するような作業では、利用するツールが入力によって変わる場合があります。Agentにツール選択を任せる余地がありますが、書き込みや外部送信の権限は分け、重要な操作には人間確認を置きます。
Agent化で増えるもの
Agentの柔軟性には、運用上の負担が伴います。
- トークン/APIコスト：複数の判断やツール呼び出しが重なると、入力・出力の量や呼び出し回数が増える場合がある
- 遅延：処理が複数段階になるほど、完了までの時間が伸びる場合がある
- 誤りの累積：途中の誤った判断やツール結果が、後の手順へ引き継がれる可能性がある
- 権限リスク：読み取りだけでなく、変更・送信・削除などの権限を持たせると影響範囲が広がる
- 状態管理：どこまで進んだか、何を試したか、どの結果を採用したかを保持する必要がある
- 人間確認の設計：すべてを止めるのか、危険な操作だけ止めるのかを決める必要がある
これらの影響は、構成、モデル、入力、ツール、再試行条件によって変わります。削減率や成功率を一つの数字で示せるものではありません。
限界と注意点
- Agentという名前だけでは能力は決まらない。 同じ名前でも、ツール、権限、停止条件、モデルの違いで動作は変わる。
- 自律性は権限設計に依存する。 自分で次の手順を選べても、許可された範囲が狭ければ実行できることも限られる。
- 柔軟性と安全性は両立の設計が必要。 自由度を増やすほど、監督、ログ、テスト、失敗時の復旧が重要になる。
- 概念と製品仕様は別である。 Anthropicの2024年の設計解説は設計パターンの参考であり、現在の各製品の性能・価格・提供条件を保証するものではない。
- 人間の確認はなくならない。 重要な外部操作、機密情報、公開や契約に関わる処理では、適切な承認と検証が必要になる。
Summary
AI活用では、最初から最も自律的なAgentを選ぶ必要はありません。手順が決まっている部分はWorkflowとして固定し、分岐や複数処理を加え、それでも事前に経路を決めにくい部分だけAgentの柔軟性を検討します。
重要なのは、Agentという名前や複雑さではなく、仕事に必要な柔軟性と、許容できるコスト・遅延・権限・確認の範囲を合わせることです。
Taka’s View
Hana & Taka
Hana賢そうなものを選ぶんじゃなくて、仕事に合わせるんだね。
Taka固定できる部分は固定して、必要な部分だけ柔軟にする。それがAIを安全に使う設計になると思う。