AIエージェントの設計パターンとは？6つの型と業務に合わせた選び方

AIエージェントを業務に組み込むときは、まず最も単純な構成で作り、足りないと確かめられた部分だけを複雑にする進め方が基本です。AIエージェントの設計パターンは、処理の手順をあらかじめ決めておく「ワークフロー型」と、AIが自分で手順を決める「エージェント型」に大きく分かれます。この記事では、AnthropicとMicrosoftの公開資料をもとに6つの設計パターンを整理し、パターンごとに向く業務、人が承認する場面、業務に合わせた選び方の手順を解説します。

AIエージェントの設計パターンとは

ワークフローとエージェントの違い

AIエージェントという言葉は、長時間にわたって自律的に動くシステムを指すこともあれば、決められた手順どおりに動くシステムを指すこともあります。Anthropicは2024年12月に公開した記事「Building effective agents」で、これらをまとめて「エージェント的なシステム」と呼んだうえで、構成の違いから2つに分けています。

• ワークフロー：AIとツールを、あらかじめコードで決めた手順に沿って動かす構成
• エージェント：AI自身が処理の進め方とツールの使い方を決めながら動く構成

ワークフローは手順が決まった業務で結果が安定しやすく、エージェントは手順を事前に決められない業務で柔軟に対応できます。2つは優劣の関係にあるものではないため、業務の性質に合わせて使い分けます。

どのパターンにも共通する部品

どの設計パターンでも、基本の部品は検索・ツール・記憶の機能を加えたAIです。Anthropicはこれを「augmented LLM」と呼んでいます。社内文書を検索して回答するAIや、顧客管理システムの情報を参照してメール案を作るAIは、この部品1つでできた構成です。

Anthropicは、多くの用途では検索と例示を組み合わせた1回のAI呼び出しを工夫すれば十分なことが多い、としています。MicrosoftのAzure Architecture Centerの解説も、複雑さを「1回のモデル呼び出し」「ツールを使う単一のエージェント」「複数のエージェントの連携」の3段階に分け、要件を確実に満たす中で最も低い段階を使うよう勧めています。業務での利用では、ツールを使う単一のエージェントが標準的な選択になることが多いとも書かれています。

ワークフロー型の5つの設計パターン

Anthropicの記事は、実際の本番環境でよく使われている構成として、次の5つのワークフローを挙げています。

プロンプトチェーン（Prompt chaining）

1つの作業を決まった順番の工程に分け、前の工程の出力を次の工程に渡す構成です。途中の工程にプログラムによる確認（ゲート）を入れて、処理が想定どおりに進んでいるかを確かめられます。処理時間は増えますが、各工程の作業が簡単になるため精度を上げやすくなります。Anthropicは、文書の構成案を作り、構成案が条件を満たすか確認してから本文を書く例を挙げています。報告書や提案書の作成のように、工程が毎回同じ業務に向いています。

ルーティング（Routing）

入力を分類し、種類ごとに用意した処理へ振り分ける構成です。種類ごとに指示やツールを分けられるため、ある種類に合わせた調整がほかの種類の結果を悪くすることを防げます。Anthropicは、問い合わせを一般的な質問、返金の依頼、技術サポートに分け、それぞれ別の手順とツールで処理する例を挙げています。分類を正確に行えることが前提です。

並列化（Parallelization）

複数のAI呼び出しを同時に動かし、結果をプログラムでまとめる構成です。独立した作業を分けて同時に進める「分割」と、同じ作業を何度か行って結果を比べる「投票」の2種類があります。分割の例として、1つのAIが利用者の質問に答え、別のAIが不適切な依頼でないかを確かめる構成が挙げられています。投票の例は、複数の指示でプログラムの脆弱性を確認し、どれかが問題を見つけたら知らせる使い方です。

オーケストレーター・ワーカー（Orchestrator-workers）

中心となるAIが作業を分解し、担当のAIに割り振って、結果をまとめる構成です。並列化と形は似ていますが、どの作業に分けるかを事前に決めず、入力に応じて中心のAIが決める点が違います。Anthropicは、変更するファイルの数や内容が依頼ごとに変わるプログラム修正や、複数の情報源を調べて分析する調査を例に挙げています。

評価・改善ループ（Evaluator-optimizer）

1つのAIが回答を作り、別のAIが評価と指摘を返し、それをくり返す構成です。Anthropicは、評価の基準が明確で、指摘を受けて直すことで目に見えて質が上がる場合に向くとしています。文学作品の翻訳のように、最初の訳では細かな意味を拾いきれない作業が例です。Microsoftの解説では同じ構成を「maker-checker loop」と呼び、くり返しの上限を決めること、上限に達したら人の確認に回すなどの扱いを決めておくことを求めています。

自律型のエージェントを使う場面

自律型のエージェントは、人からの指示や対話で作業内容が決まった後、計画を立てて自分で作業を進めます。ツールの実行結果などを各段階で確かめながら進み、必要に応じて人に情報や判断を求めます。

Anthropicは、必要な手順の数を予測できず、決まった手順を書けない課題にエージェントが向くとしています。一方で、自律的に動く分だけ費用が増え、誤りが積み重なるおそれもあります。そのため、隔離した環境で十分に試験すること、適切な安全策を設けること、くり返し回数の上限などの停止条件を入れることを勧めています。

同じ記事は、エージェントが特に成果を上げやすい分野として、顧客サポートとプログラム開発を挙げています。どちらも対話と操作の両方を含み、成功の基準が明確で、結果を見て直すことができ、人による監督を組み込める業務です。プログラム開発の例でも、自動テストで動作を確かめた後、システム全体の要件に合っているかは人が確認する必要があるとしています。

設計パターンごとに向く業務と人が確認する場面

6つの設計パターンを、向く業務と人が確認する場面で整理すると次のようになります。図のオーケストレーター・ワーカーと自律型のエージェントは、手順を事前に決められない点が共通するため同じ行にまとめました。

図をタップすると拡大します

図の要点をテキストで読む

AIエージェントの設計パターンと、向く業務、人が確認する場面の対応表。プロンプトチェーンは工程が毎回同じ報告書や提案書の作成に向き、途中のゲートと完成前に人が確認する。ルーティングは種類ごとに処理が違う問い合わせの振り分けに向き、分類の誤りと返金などの例外を人が確認する。並列化は複数の観点での確認や安全チェックに向き、結果が食い違ったときに人が判断する。評価・改善ループは翻訳や文書の推敲のように基準が明確な作業に向き、くり返しの上限に達したら人が確認する。オーケストレーター・ワーカーと自律型のエージェントは調査やプログラム修正のように手順を決められない作業に向き、外部に影響する操作の前に人が承認する。

人の承認は操作の単位で置く

人が確認する場面は、影響の大きい操作に絞って置くこともできます。Microsoftの解説は、人の確認をエージェントの出力全体ではなく特定のツールの実行に限定すれば、リスクの低い操作は自動で進め、重要な操作だけ承認を求められるとしています。あわせて、確認が必須か任意か、人の応答が処理を先に進める「承認」なのか、AIに差し戻す「指摘」なのかを決めておくことも挙げています。

業務に置き換えると、社内向けの下書きや情報の収集はAIに任せ、顧客へのメール送信、返金、契約に関わる回答、基幹システムのデータ更新などの前に人の承認を置く、という分け方になります。任せる仕事と人が確認する仕事の分け方は、AIエージェントに任せる仕事、人が確認する仕事の分け方で詳しく解説しています。どの工程に人を入れるかは、Q&A「Human-in-the-Loop（人間介在）はどこに入れるべきですか？」でも整理しています。

AIエージェントの設計パターンを選ぶ手順

設計パターンは、複雑なものから検討すると必要以上に大きな構成になりがちです。最も単純な構成から試し、足りない部分だけを追加する順番で検討します。

図をタップすると拡大します

図の要点をテキストで読む

AIエージェントの設計パターンを選ぶ5つの手順。1は対象業務を1つに絞り、成功とする状態を決める。2は検索と例示を組み合わせた1回のAI呼び出しで、どこまで処理できるかを測る。3は手順が決まっている業務ならプロンプトチェーン、ルーティング、並列化などのワークフロー型を選ぶ。4は手順を事前に決められない部分だけ、オーケストレーター・ワーカーや自律型のエージェントにする。5は人の承認が必要な操作、くり返しの上限、停止の条件を置く。評価の結果を見て、構成を足すか見直すかを判断する。

1. 業務と成功の基準を決める：対象業務を1つに絞り、どの状態になれば成功とするかを先に決めます。
2. 単純な構成で試す：社内文書の検索と例示を組み合わせた1回のAI呼び出しで、どこまで処理できるかを測ります。
3. 手順が決まっていればワークフロー型を選ぶ：工程が毎回同じならプロンプトチェーン、種類で処理が変わるならルーティング、観点ごとに確かめたいなら並列化を使います。
4. 手順を決められない部分だけエージェント型にする：作業の分け方や必要な手順の数が入力ごとに変わる部分に限って、オーケストレーター・ワーカーや自律型のエージェントを使います。
5. 承認と停止の条件を置く：人の承認が必要な操作、くり返し回数の上限、処理を止める条件を決め、評価しながら構成を見直します。

最も単純な設計から始める理由

Anthropicは、エージェント的なシステムは処理時間と費用を増やす代わりに性能を上げるものが多いとし、複雑さを加えるのは結果が目に見えて良くなる場合だけにするよう勧めています。Microsoftの解説も、複数のエージェントを連携させると、連携のための処理、待ち時間、失敗の起き方が増えると指摘しています。

構成が単純であれば、誤りが起きたときにどの工程が原因かを見つけやすく、評価や改善の手間も小さく済みます。フレームワークについてもAnthropicは、内部の指示や応答が見えにくくなり、問題の原因を探しにくくなることがあるため、使う場合は内部の動きを理解しておくよう注意しています。単一のエージェントと複数のエージェントの比べ方は、Q&A「マルチエージェント構成とシングルエージェント、どちらがよいですか？」でも整理しています。複数のエージェントで役割を分ける構成は、マルチエージェントとは？で解説しています。

単純な構成で始めると、試作から本番運用に進むときの判断もしやすくなります。評価の基準や確認の手順をどう本番に引き継ぐかは、AIのPoCを本番運用に移すには？で解説しています。

設計パターンの検討を相談する場合

AIエージェントの設計では、業務の手順の整理、使うデータとツールの権限、人の承認を置く場所、評価の方法を同時に決める必要があります。社内に設計と実装を進められる担当者がいる場合は、この記事の手順を検討の出発点に使えます。

inovieでは、対象業務の整理から設計パターンの選定、試作品での検証、既存システムへの組み込みまでを支援しています。AIエージェントの導入と改善についてはAIエージェント導入・改善支援、システム開発全体についてはAI導入・システム開発の支援をご覧ください。どの設計パターンから始めるべきかのご相談は、お問い合わせから受け付けています。

出典確認日：2026-10-06