AIエージェントの作り方：業務に組み込むための設計手順と5つの基本パターン

AIエージェントを業務で使えるものにする最大のポイントは、最初から自律的なエージェントを作ろうとせず、目的を満たす最もシンプルな構成から始めることです。Anthropicが公開しているガイド「Building effective agents」でも、できるだけシンプルな解決策を探し、必要なときにだけ複雑さを増やすことが推奨されています。

AIエージェントへの関心は高まっていますが、「作ってみたが業務で使えなかった」という声も少なくありません。本記事では、AnthropicやOpenAIの公開ガイドをもとに、業務にAIエージェントを組み込むための設計の手順と、知っておきたい5つの基本パターンを解説します。

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

Anthropicのガイドでは、LLMを使ったシステムを次の2つに分けて説明しています。

業務の多くは、実はワークフローで十分に対応できます。エージェントは柔軟な反面、処理にかかる時間や費用が増え、結果の予測もしにくくなります。まずワークフローで作れないかを検討し、それでは対応できない部分にだけエージェントを使うのが現実的です。AIエージェントの基本はAIエージェントとはでも解説しています。

業務で使える5つの基本パターン

Anthropicのガイドでは、ワークフローの基本的なパターンとして次の5つが紹介されています。

これらのパターンを組み合わせるだけで、多くの業務の自動化に対応できます。問い合わせ対応での活用は問い合わせ対応のAI活用をご覧ください。

あわせて読みたいGAS（Google Apps Script）で業務を自動化する方法：できること・制限・運用ルール

AIエージェントを作る6つのステップ

ステップ1：業務と成功条件を決める

最初に、「どの業務の、どの部分を任せるのか」と「何をもって成功とするのか」を決めます。たとえば「問い合わせの一次回答を作成し、担当者の確認時間を減らす」「回答案のうち、修正なしで送れるものの割合を測る」といった形です。成功条件が決まっていないと、改善の方向も判断できません。

ステップ2：最小の構成を選ぶ

まず、1回のLLMの呼び出し（プロンプトと必要な情報の検索）で解決できないかを試します。それで足りなければ、5つのパターンのうち最も単純なものから試し、必要な場合にのみエージェントに進みます。

ステップ3：ツールと権限を設計する

エージェントが使えるツール（検索、データベースへの書き込み、メール送信など）と、その権限を決めます。Anthropicのガイドでは、エージェントとツールの接点（ACI：agent-computer interface）を、丁寧なツールの説明とテストによって設計することが重要な原則の1つとして挙げられています。

MCPを使ってツールを接続する場合はMCPとは、権限設計の注意点はAIエージェントのセキュリティリスクで解説しています。

ステップ4：指示（プロンプト）を作る

OpenAIのガイドでも、エージェントの基本的な要素として、モデル、ツール、指示（インストラクション）の3つが挙げられています。指示には、役割、手順、判断の基準、迷ったときの対応（人に確認する、分からないと答えるなど）を明確に書きます。既存の業務マニュアルや手順書は、指示を作るための良い材料になります。

ステップ5：評価データで検証する

実際の業務の入力と、期待する出力の例を20〜50件ほど用意し、エージェントの出力と比べます。

評価データは、モデルを切り替えるときの比較にも使えます。モデルの提供終了への備えは生成AIモデルの提供終了に備える移行チェックリストで解説しています。

ステップ6：人の確認を入れて運用する

運用を始めたら、最初はすべての出力を人が確認するところから始め、品質が安定した部分から確認の範囲を減らしていきます。Anthropicのガイドでは、エージェントの計画の手順を明示的に示して透明性を高めることも原則として挙げられています。何を考え、どのツールを使ったかの記録を残しておくと、問題が起きたときの原因の特定や改善に役立ちます。

運用開始前のチェックリスト

• 任せる業務の範囲と、成功条件（測る指標）が決まっている
• ワークフローで足りる部分と、エージェントに任せる部分を分けた
• ツールの一覧と、それぞれの権限（読み取り・書き込み・送信）を整理した
• 影響の大きい操作には、人の承認を挟んでいる
• 評価データ（実際の入力と期待する出力）を用意し、結果を記録した
• 計画・ツールの呼び出し・結果のログを残している
• 誤りが見つかったときの連絡先と、停止・修正の手順を決めた

開発の手段の選び方

Anthropicのガイドでは、まずLLMのAPIを直接使うことから始め、フレームワークを使う場合はその内部で何が起きているかを理解することが勧められています。抽象化の層が増えると、プロンプトや応答が見えにくくなり、問題の原因を探しにくくなるためです。ノーコードの選択肢はDifyとはで解説しています。

よくある失敗と対策

FlowStack Labsの見解：エージェントの価値は「賢さ」より「任せ方の設計」で決まる

AIエージェントの開発では、どのモデルやフレームワークを使うかに注目が集まりがちです。しかし、私たちが業務への組み込みを支援するなかで実感しているのは、成果を左右するのは「どこまで任せ、どこで人が確認するか」の設計だということです。

たとえば問い合わせ対応では、エージェントに回答の送信まで任せるのか、回答案の作成までにとどめるのかで、必要な精度も、リスクも、効果も大きく変わります。最初は回答案の作成までにとどめ、担当者の修正内容を評価データとして蓄積し、品質が十分になった種類の問い合わせから送信まで任せる、という段階的な進め方が現実的です。

また、エージェントは一度作って終わりではなく、業務の変化やモデルの更新にあわせて改善し続けるものです。評価データ、ログ、権限の一覧という3つの「運用の土台」を最初から用意しておくことが、長く使えるエージェントを作るための近道だと考えています。

よくある質問

まとめ

• AIエージェントは、最もシンプルな構成から始め、必要なときだけ複雑にすることが重要です。
• 決めた手順で動く「ワークフロー」と、自ら判断する「エージェント」を使い分けます。
• プロンプトの連鎖、振り分け、並列化、指揮者と作業者、評価と改善の5つのパターンを組み合わせると、多くの業務に対応できます。
• ツールと権限は必要最小限にし、評価データで検証してから運用します。
• 人の確認を入れて運用を始め、ログと評価データをもとに改善を続けましょう。

業務に合わせたAIエージェントの設計・開発、既存システムとの連携は、FlowStack Labsの無料相談でご相談いただけます。AI導入の全体の進め方はAI導入支援もご覧ください。

参考資料

• Anthropic「Building effective agents」
• OpenAI「A practical guide to building agents」（PDF）
• Anthropic「Model deprecations」