[AFFILIATE: Dify]のWorkflowモードを試した後、「もっと自由に動くAIを作れないか」と思ってAgentモードに手を出した。
WorkflowはLLMに決まった処理をさせるためのモードだ。外部APIを叩いて結果を返す、というような決定論的な処理には向いている。ただ、「状況を見て判断してほしい」「必要なら検索してほしい」という要求には応えられない。そういうことができるのがAgentモードだという説明を読んで、試してみることにした。
この記事では、DifyのAgentモードで情報収集AIエージェントを実際に設計した手順を書く。Workflowとの違い、ツール設定、プロンプト設計、テストの流れ、そして「やってみてわかった限界」も含めて正直に書くつもりだ。
この記事でわかること
- DifyのAgentモードとWorkflowモードの違い
- Agentアプリの作成手順・ツール設定・システムプロンプト設計
- 実際に作ってテストしてみた記録（失敗談含む）
- AgentとWorkflowの使い分け基準
DifyのAgentモードとは何か：WorkflowモードとAgentモードの違い
Difyには4つのアプリモードがある。チャットボット、テキストジェネレーター、エージェント、Workflowだ。
AgentモードとWorkflowモードは一見似ているが、根本的な設計思想が違う。
Workflowモード：
処理の手順が最初から固定されている。START→HTTPリクエスト→LLM→ENDというように、流れがあらかじめ決まっていて、LLMはその流れの中の1ステップとして機能する。何をするかはプログラマー（設計者）が決める。
Agentモード：
ユーザーの指示を受けて、LLMが「次に何をすべきか」を判断する。使えるツールの一覧の中から、状況に応じて何を使うかをLLMが選ぶ。設計者は「使えるツール」と「判断基準（システムプロンプト）」を定義するだけで、実行順序はLLMが決める。
つまり、Workflowは「決めた手順をこなす機械」で、Agentは「指示を受けて自分で考えて動く助手」というイメージに近い。
AgentがWorkflowと違う点：LLMが判断して動く
Agentで重要なのは「ReAct」という推論フレームワークだ。これは「考えて（Reasoning）、行動する（Acting）」の繰り返しで、LLMがツールを使いながら段階的に問題を解いていく。
具体的にはこういう流れになる：
- ユーザーが「今日の東京の天気を教えて」と入力する
- LLMが「天気を調べるには検索が必要だ」と判断する
- 検索ツールを呼び出して「東京 今日 天気」で検索する
- 検索結果を受け取る
- 結果を元に「今日の東京は晴れです」と回答する
このプロセスを1回のチャットで自動でやってくれる。Workflowだとこの手順を設計者が全部ノードで組む必要があるが、Agentだとシステムプロンプトで「検索ツールを使って最新情報を調べなさい」と指示するだけでいい。
ただ、「自由に動く」ということは「想定外の動きをする可能性もある」ということだ。これがAgentの難しさでもある。
Agentが向いているケース・向いていないケース
向いているケース：
- 検索や計算など、状況によって使うツールが変わる処理
- 会話の流れを見ながら必要な情報を集めてくれるアシスタント
- 何段階かの情報収集が必要なリサーチタスク
向いていないケース：
- 毎回同じ手順で確実に処理したい業務 → Workflowを使う
- 処理の結果を正確にコントロールしたい → Workflowを使う
- 大量の自動処理（何百回も実行する） → Agentはクレジット消費が多いのでWorkflowが安全
Agentを設計する基本手順
実際の設計手順を順番に書いていく。
アプリを「エージェント」モードで作成する
Difyダッシュボードの「アプリを作成」から「エージェント」を選ぶ。Agentモードの詳細仕様はDify公式日本語ドキュメント（エージェント）でも確認できる。
チャットボットとAgentはUIが似ているが、エージェントには「ツール」というセクションがある。ここが設定の核になる。
アプリ名は何でもいい。今回は「情報収集アシスタント」にした。
ツールを設定する：Dify組み込みツールと外部APIの違い
Agentが使えるツールには2種類ある。
組み込みツール（Built-in tools）：
Difyにはじめからバンドルされているツールだ。有効化するだけで使える。利用可能なツールの一覧はDify公式ツールドキュメントで確認できる。
主な組み込みツール：
無料で使えるのはWikipediaと計算機程度で、Google SearchはGoogle Cloud Console でAPIキーの発行が必要、Bing SearchはAzureのAPIキーが必要だ。最初から全部設定しようとすると手間がかかる。
カスタムツール：
OpenAPIスキーマ（API仕様書）を貼り付けることで、外部のAPIをAgentのツールとして登録できる。自社サービスのAPIや特定のデータAPIを使いたい場合はこちらを使う。
最初に設定するなら、まずWikipediaと計算機だけ有効化して試すのが無難だ。ツールを増やすほどAgentが複雑な判断をしようとして、クレジットを消費しやすくなる。
システムプロンプトで「役割」と「判断基準」を定義する
Agentの挙動を決める最重要の設定がシステムプロンプトだ。ここが一番試行錯誤が必要なところでもある。
基本的に書くべきことは3つ：
1. 役割の定義：
あなたはフリーランスの情報収集をサポートするAIアシスタントです。
ユーザーが知りたいことを調べて、簡潔にまとめて回答します。2. ツールをいつ使うかの指示：
以下の場合にツールを使ってください：
- ユーザーが最新情報を求めている場合
- 具体的な数値や固有名詞の確認が必要な場合
以下の場合はツールを使わないでください：
- 一般的な知識の説明や意見を求められている場合
- 挨拶や雑談に応じる場合3. 出力形式の指定：
回答は日本語で、200字以内で簡潔にまとめてください。
箇条書きが適切な場合は使ってください。ここで重要なのは「ツールを使わないケース」を明示することだ。最初にこれを書かないと、Agentは何でも検索しようとする。挨拶に対しても検索を走らせて、クレジットを無駄に消費した。
僕が最初に設定したシステムプロンプトには「ツールを積極的に使ってください」とだけ書いた。結果、「おはようございます」に対してもGoogle Searchが走った。これで気づいた。
テストして挙動を確認する
設定が終わったらチャット欄で実際に試す。
確認すべきポイント：
テストを重ねてシステムプロンプトを修正していく。僕は7回書き直した。
実際に作ってみた：情報収集AIエージェントの設計記録
設計から実用できるレベルになるまで、約3時間かかった。
最初の設計はこんな感じだった：
ツール設定： WikipediaとCalculator（Bing SearchはAPIキー設定が手間だったのでいったんスキップ）
初期システムプロンプト：
あなたは情報収集アシスタントです。ユーザーの質問に答えてください。
ツールを積極的に使ってください。これで試したら「ツールを積極的に使ってください」という指示が効きすぎて、質問があるたびにWikipediaを検索し始めた。「今日の気分は？」という会話にも検索を走らせた。
修正1：ツールを使わないケースを追加
以下の場合はツールを使わないでください：
- 会話・挨拶・感想の表明
- LLMが持っている一般知識で回答できる場合これで不要な検索は減った。
修正2：回答の品質が不安定
Wikipedia検索の結果をそのまま使いすぎて、回答が長く・読みにくくなることがあった。「検索結果を要約して300字以内で返すこと」という指示を追加した。
修正3〜7：細かい挙動調整
「日本語で聞いているのに英語のWikipediaを参照する」「情報が古い」などの問題を修正していった。
最終的なツール数は2個（Wikipedia + Calculator）。最初は5個設定していたが、使用頻度が低いものは外した。ツールが多いほどLLMの判断負荷が増えて、挙動が不安定になる印象があった。
結果として、「何かを調べて教えて」という使い方には十分実用できる状態になった。ただ、Workflowのように「必ずこの手順で処理する」という確実性はない。同じ質問をしても、毎回少し違う回答になる。
AgentとWorkflowをどう使い分けるか
この2つを使ってみた感想から、使い分けの基準を整理した。
Workflowを選ぶとき：
- 入力→処理→出力の手順が決まっている
- 毎回同じ品質の出力が必要
- 外部APIと連携した定型処理を自動化したい
- 処理を何百回も実行する可能性がある（クレジット節約）
Agentを選ぶとき：
- ユーザーの質問内容によって使うツールが変わる
- 「必要なら調べる」という柔軟な判断が必要
- 会話形式でインタラクティブに使いたい
- 手順を設計するより「自律的に動く」方が楽な場面
フリーランスの実務で考えると、Agentが向いているのは「調べ物アシスタント」「情報収集のファーストカット」あたりだ。定型処理（毎週のレポート生成、決まったAPIからデータを取ってくる）はWorkflowの方が安定する。
Difyの使い方入門記事でも触れたが、まずWorkflowで使い方を学んでからAgentに来るのが順番としてスムーズだと思う。Workflow→Agentの順で試した方が、Agentが「何をしているか」を理解しやすい。
また、DifyのWorkflowとAPIを組み合わせた具体的なフロー設計についてはDify APIフロー設計の記事を参照してほしい。Agentと組み合わせると何ができるかのイメージが膨らむはずだ。
やってみてわかった限界と注意点
1. クレジット消費に注意
Agentは1回の対話でツールを複数回呼び出すことがある。その場合、1回のチャットで3〜5クレジットを消費することもある。Sandboxの200クレジットはAgentのテストだけであっという間に消えた。本格的に使うなら有料プランへの移行を前提に考えた方がいい。
2. 挙動の再現性がない
同じ質問をしても毎回同じ答えが返ってくるとは限らない。これはAgentの性質上仕方ないが、「必ずこの形式で出力してほしい」という要件がある業務には向かない。
3. ループ回数の上限を設定する
Agentにはツールの呼び出しを繰り返す「反復」という設定がある。デフォルトの上限回数を確認しておくこと。上限が高すぎると、解決策が見つからない質問に対してループし続けてクレジットを大量消費する可能性がある。設定画面で「最大反復回数」を確認し、5〜10回程度に抑えておくのが無難だ。
4. 「思ったより賢くない」という現実
正直に言うと、Agentが自律的に考えてくれる場面は思ったより少なかった。単純な情報収集ならうまく動くが、複雑な推論や多段階のタスクになると、途中でおかしな判断をすることが増えた。「AIが自分で考えて複雑な業務をこなしてくれる」という期待は少し下げた方がいい。
それでも、「検索して要約する」「複数の情報を組み合わせて答える」という用途には十分使える。
5. モデルの選択がAgentの性能に直結する
Agentモードで使うLLMのモデルは設定から変更できる。GPT-4o-miniのような軽量モデルを使うとコストは抑えられるが、複雑な判断が必要な場面では判断の精度が落ちた。ツールを使う判断自体がおかしくなる（使うべき場面で使わない、使わなくていい場面で使う）ことが増えた。
Agentをちゃんと動かすには、それなりに賢いモデルを使う必要がある。GPT-4o程度のモデルを使うとかなり挙動が安定する。ただしそのぶんAPIコストもかかる。費用対効果を考えながらモデルを選ぶ必要がある。
まとめ：Agentは「試してみる価値あり」だが過度な期待は禁物
DifyのAgentモードは、Workflowよりも柔軟な自律動作ができるモードだ。ツールを組み合わせて状況に応じた処理をさせたい場合には有効で、情報収集アシスタントのような用途には実用的だった。
ただ、「何でもやってくれる万能AIエージェント」ではない。プロンプト設計に時間がかかるし、挙動が安定しない場面もある。クレジット消費も多いので、コスト意識が必要だ。
試してみる価値はある。ただし、「まずWorkflowで基本を掴む→必要に応じてAgentに移行する」という順番が、非エンジニアにとっては最も遠回りが少ない進め方だと思う。
合わせて読みたい
コメント