「AI エージェントを業務に入れたい」という相談は年々増えていますが、いざ設計に入ると、何をどう組み立てればよいかでつまずくケースがほとんどです。エージェントという言葉が指す範囲は広く、決め打ちの自動処理から、LLM が自分で次の一手を選ぶ自律システムまでが同じ名前で語られています。ここを整理しないまま「とりあえず賢いエージェントを」と作り始めると、挙動が読めず、コストが膨らみ、本番に出せないものができあがります。
本記事では、AI エージェントを実務で動かすための設計を 6 つのパターンに整理します。ワークフロー型から ReAct、プランナー実行型、人間協調まで、どの業務にどの型が向くのか、ガードレールやリトライをどう設計するのかを、実装と運用の判断基準まで掘り下げて解説します。これから PoC を検討している方が、自分たちの業務にどの型を当てるべきかを判断できる状態を目指します。
AI エージェントとワークフローの違い — まず線を引く
設計を始める前に、最初に引いておくべき線があります。それは 「処理の流れを誰が決めるのか」 です。この一点で、ワークフローとエージェントは明確に分かれます。
ワークフローは、人間が手順をあらかじめ固定したものです。「入力を受け取る → 分類する → 該当する処理を呼ぶ → 結果を返す」というように、分岐も次にやることも設計時に決まっています。LLM はその各ステップの中で「分類する」「要約する」といった部品として使われるだけで、全体の流れを決める権限は持ちません。挙動が読みやすく、テストもしやすいのが利点です。
一方で AI エージェントは、次に何をするか、どのツールを呼ぶか、いつ終わるかを LLM 自身が実行時に判断します。同じ入力でも、状況に応じて取る経路が変わります。未知の入力や、事前に分岐を書き切れないタスクに強い反面、挙動のばらつきが大きく、放っておくとコストが膨らんだり、想定外の操作をしたりします。
実務での原則はシンプルです。まずワークフローで解けないかを考え、解けない部分だけをエージェント化する。多くの業務は、判断の分岐を人間が書き切れる範囲に収まっており、決め打ちのワークフローで十分に回ります。自律性は「便利だから入れる」ものではなく、「人間が手順を固定できないから、やむをえず LLM に判断を委ねる」ものだと捉えると、設計の筋が良くなります。
以下で紹介する 6 つのパターンは、左から右へ進むほど自律性が高く、その分だけ挙動の制御が難しくなります。自分たちの業務に必要な自律性の最小限を見極めることが、設計の出発点です。
パターン 1 — 決め打ちワークフロー型
最もシンプルで、最も多くの業務で正解になるのがこの型です。処理の手順をすべて人間が定義し、LLM は各ステップの中で限定的に使われます。
たとえば「問い合わせメールを受け取り、内容を 3 つのカテゴリに分類し、カテゴリごとに定型の返信テンプレートを生成して、担当チームに振り分ける」という業務を考えます。ここで LLM が担うのは「分類」と「テンプレートへの当てはめ」だけで、振り分け先や処理順は固定です。LLM が自分で「次に別のツールを呼ぼう」と判断する余地はありません。
この型の強みは、どの入力でどのステップを通るかが設計時に決まっているため、挙動を事前に追えることです。テストが書けて、コストも見積もれます。LLM 呼び出しの回数が固定なので、コスト爆発のリスクもありません。
向いているのは、入力のパターンがある程度限られ、処理手順を人間が言語化できる業務です。データの抽出・分類・要約・定型文の生成といった「LLM の一発の出力で完結する処理を、順番に並べる」タスクの大半はこの型で足ります。AI エージェントというと自律的なものを思い浮かべがちですが、本番で安定して回っている多くのシステムは、実態としてこのワークフロー型です。エージェント化を検討する前に、まずこの型で解けないかを必ず確認してください。
パターン 2 — ツール呼び出しとルーティング型
ワークフロー型に「分岐の判断を LLM に任せる」要素を一段加えたのが、この型です。大きく 2 つの形があります。
ひとつは ルーティング型 です。入力を見て、LLM が「これはどの処理に回すべきか」を判断し、入力内容に対応づけた経路へ振り分けます。先ほどの問い合わせ分類で、分類結果に応じて呼ぶ処理を LLM が選ぶ、というイメージです。手順自体は固定ですが、どの手順に入るかの入口判断を LLM に委ねます。
もうひとつは ツール呼び出し型 です。LLM に複数のツール（関数）を渡しておき、入力に応じて「どのツールを、どんな引数で呼ぶか」を LLM に決めさせます。たとえば「在庫を調べて」と言われたら在庫検索ツールを、「注文状況は」と言われたら注文照会ツールを呼ぶ、という具合です。1 回の判断で 1 つのツールを呼んで終わる単発の形であれば、挙動はかなり読みやすく保てます。
この型の設計で重要なのは、ツールの定義です。ツールの名前・説明・引数のスキーマが曖昧だと、LLM が誤ったツールを選んだり、引数を取り違えたりします。ツールの説明は「いつ使うべきか」を明示し、引数には型と必須項目を定義して、呼び出し後にパラメータの妥当性を検証する層を必ず挟みます。ツール呼び出しの精度は、LLM の賢さよりもツール定義の質に大きく左右される、というのが実務の感覚です。
向いているのは、使えるツールや経路が限定されていて、入口の判断だけを自動化したい業務です。社内の問い合わせ窓口や、複数のデータソースを使い分ける検索アシスタントなどが典型です。
パターン 3 — ReAct とプランナー実行型
ここから先が、本来の意味での「自律的なエージェント」です。手順を事前に固定できず、状況に応じて次の一手を変える必要があるタスクに使います。
ReAct 型 — 考えて、動いて、観察する
ReAct は Reasoning（推論）と Acting（行動）を交互に繰り返す型です。LLM が「次に何を調べるべきか」を考え、ツールを呼び、その結果を観察して、また次の一手を考える、というループを回します。
たとえばシステム障害の一次調査を考えます。「エラー率が上がっている」という入力に対し、エージェントはまずログを調べ、結果を見て「特定の API で 500 が増えている」と判断し、次にそのデプロイ履歴を確認し、直近の変更を特定する、という流れを自分で組み立てます。どこを調べるべきかは状況次第なので、手順を事前に固定できません。こうした調査・トラブルシュート・複数ステップの問い合わせ対応に ReAct は向いています。
注意点は、推論のたびに LLM 呼び出しが発生することです。手順がほぼ決まっている定型処理に ReAct を使うと、コストと遅延が膨らみ、挙動も不安定になります。使いどころは「分岐は事前に書き切れないが、使えるツールは限定できる」業務に絞ってください。そして後述するループ上限のガードレールとセットで設計するのが前提です。
プランナー実行型 — 先に計画を立ててから動く
ReAct が「一手ずつ考えながら進む」のに対し、プランナー実行型は 最初にタスク全体の計画を立て、それから各ステップを順に実行する 型です。LLM がまず「このタスクは A → B → C の順で進める」と計画を出し、その計画に沿って実行していきます。
この型の利点は、計画段階で全体を見渡せることです。計画を人間が一度レビューしてから実行させる、という挟み方ができるため、複雑だが見通しを立てやすいタスクに向きます。コード生成における「設計を先に固めてから実装する」流れや、複数の成果物を順に作っていくドキュメント生成などが好例です。
一方で、実行の途中で前提が崩れた場合に、最初の計画に固執してしまう弱点があります。実務では「計画どおりに進まなくなったら、計画を立て直す」リプランの仕組みを持たせることが多く、ここを丁寧に設計しないと、的外れな手順を機械的に踏み続けてしまいます。
パターン 4 — 人間協調 (Human-in-the-loop) の組み込み
自律性を上げるほど、人間がどこで関与するかの設計が品質を左右します。全ステップに人間を挟めば自動化の意味が薄れ、まったく挟まなければ取り返しのつかない操作を勝手に実行されかねません。鍵は 「どの操作に承認ゲートを置くか」 の線引きです。
判断基準はシンプルで、可逆な操作は自動、不可逆な操作は人間承認 です。情報の検索、下書きや提案の生成といったやり直せる操作はエージェントに任せます。一方、外部への送信、課金が発生する処理、データの削除・更新、本番環境への反映といった取り返しのつかない操作は、実行の手前で人間の承認を必須にします。
設計のコツは、エージェントの出力を 「提案」と「実行」に分ける ことです。エージェントには「何をしようとしているか」「その根拠は何か」をセットで提示させ、人間はそれを見て可否だけを判断します。判断材料が揃っていれば、人間は短時間で承認・却下を返せます。逆に、根拠のない「実行してよいですか」だけを投げると、人間が毎回中身を調べ直すことになり、ボトルネックになります。
運用が安定してきたら、承認の対象を段階的に狭めていきます。低リスクで、過去の承認実績から判断が定型化できる操作は自動承認に移し、本当に判断が必要な操作だけを人間に残す。こうして自動化率を上げながら安全性を保つのが、人間協調型の運用の勘所です。私たちが 顧客対応オペレーションの自動化事例 で一次対応の大部分を自動化できたのも、この「リスクに応じた承認の線引き」を業務ごとに設計したからでした。
失敗を減らすガードレールとリトライ設計
自律性を持つエージェントは、放っておくと暴走します。同じツールを延々と呼び続けたり、コストが想定の何倍にも膨らんだり、想定外の操作を実行したりします。これを防ぐガードレールは、後付けが難しいため、PoC の段階から組み込んでおくべき要素です。
最低限入れておきたいのは次の制御です。ループの最大反復回数 を設け、無限ループを物理的に止めます。1 タスクあたりのトークン・呼び出し回数の上限 を決め、コスト爆発を防ぎます。ツールごとの権限 には最小権限の原則を適用し、削除・送信・課金のような危険な操作は人間承認の後ろに置きます。ツール呼び出しのパラメータ検証 を実行前に挟み、不正な引数での実行を弾きます。タイムアウト を設定し、応答しないツールでエージェントが止まらないようにします。
リトライの設計にも勘所があります。失敗したときに無条件で同じ操作を再試行しても、同じエラーを繰り返すだけです。エラーの内容を観察し、方針を変えてから再試行する 設計にします。たとえば「引数が不正」というエラーなら引数を直して再試行し、「外部サービスが一時的に応答しない」なら少し待ってから再試行する、という具合に、エラーの種類で対応を分けます。そして再試行の回数にも必ず上限を設けます。
さらに、運用上きわめて重要なのが ログ です。各ステップで「どんな入力を受け、何を考え、どのツールをどんな引数で呼び、何が返ってきたか」を残しておきます。エージェントは挙動が確率的なので、問題が起きたときに後から追跡できる状態を作っておかないと、原因の特定に膨大な時間がかかります。この観点は AI 駆動開発全体の品質設計とも共通しており、何を機械で保証し、どこを人間が見るかの切り分けは AI 生成コードのレビュー設計 と同じ発想で組み立てられます。
業務別の型の選び方と実装の勘所
ここまでのパターンを、実際の業務にどう当てるか。判断の出発点は繰り返しになりますが 「人間が手順を書き切れるか」 です。
手順を書き切れるなら、迷わず ワークフロー型（パターン 1） です。分類・抽出・要約・定型文生成を順に並べるだけの業務は、これで十分に本番運用できます。入口の判断や使うツールだけを自動化したいなら、ルーティング・ツール呼び出し型（パターン 2） を足します。社内ヘルプデスクや、複数データソースを使い分ける検索アシスタントが典型です。
手順を書き切れず、状況次第で取るべき行動が変わるなら、初めて ReAct 型（パターン 3） の出番です。障害調査、複雑な問い合わせ対応、外部情報を集めながら結論を出す調査タスクが向きます。タスクが大きく、先に全体計画を立てられるなら プランナー実行型 を選び、計画を人間がレビューしてから実行させます。そして、いずれの型でも不可逆な操作を含むなら 人間協調（パターン 4） を重ねる、という構成になります。
実装でつまずきやすいのは、最初から最も自律的な型を選んでしまうことです。「賢いエージェントを作りたい」という気持ちが先行すると、ReAct やプランナーから入りがちですが、それは挙動の制御もコスト管理も最も難しい選択です。最小の自律性で解けないかを常に確認し、必要な分だけ自律性を足していく のが、本番に乗るエージェントを作る近道です。
PoC の進め方としては、まず対象業務を 1 つに絞り、ワークフロー型で土台を作り、自動化しきれない判断の部分だけをエージェント化します。その際にガードレールとログを最初から組み込んでおけば、本番移行で作り直す必要がありません。検証フェーズの設計や合格基準の決め方は AI エージェントの PoC の進め方 で詳しく解説しています。エージェントの精度は、検索や知識参照の質にも大きく依存するため、社内ナレッジを扱う場合は RAG 構築の実践ガイド もあわせて検討すると、回答の根拠と精度を両立させやすくなります。
AI 駆動開発でエージェントを業務に組み込むなら
AI エージェントの設計は、「どれだけ賢く作るか」ではなく「どれだけ自律性を最小限に抑えながら、業務の目的を果たすか」の設計です。ワークフロー型で土台を固め、必要な部分だけ ReAct やプランナーで自律性を足し、不可逆な操作には人間協調を挟み、全体をガードレールとログで囲む。この順序で組み立てれば、挙動が読めてコストも管理でき、本番で安定して回るエージェントになります。
FIXIT は AI 駆動開発のクリエイティブスタジオとして、業務分析からエージェント設計、ガードレールと運用設計までを一気通貫で伴走しています。どの業務にどの型を当てるべきか、PoC をどう始めるべきかでお悩みの方は、AI エージェント開発サービス からお気軽にご相談ください。貴社の業務に最小限の自律性で成果を出す設計を、実装と運用の両面からご提案します。