はじめに

みなさん、こんにちは。SB C&Sの佐藤です。
AIの世界は加速度的に発展しており、とりわけ注目されているのが「エージェント」です。本記事では、OpenAIが2025年4月に公開したドキュメント「A practical guide to building agents」を概観し、その要点を整理します。本記事を通じてエージェント開発の基礎を固めましょう。

---

「A practical guide to building agents」とは？

2025年4月中旬にOpenAIが公開した技術ドキュメントで、エージェント開発に必要な考え方と実装パターンをまとめています。主な読者はLLM／AI関連のシステムエンジニアであり、内容は技術寄りです。エージェントの定義が曖昧な中で同ガイドは明確な指針を示したため、公開直後から大きな反響を呼びました。

---

ポイント整理

■エージェントとは

「ユーザーの指示からワークフローを自律的に組み立て、外部ツールを含むタスクを実行し、目的を達成するシステム」
従来の決定論的・規則ベースのアプローチが得意としない複雑・曖昧な状況を扱える点が強みです。ただし、本記事の定義はあくまでOpenAIが提唱するものである点に留意してください。

■エージェントが得意とするパターン

・Complex decision‑making -- 複雑な意思決定
・Difficult‑to‑maintain rules -- 保守が困難な大量のルール
・Heavy reliance on unstructured data -- 非構造化データの多用

エージェント開発に取り組む前に、解決したい問題がこれらに当てはまるかしっかり確認することが必須です。これらに該当しない場合は、関数呼び出しや単純なAPI連携など従来手法の方が適切です。
闇雲にエージェント化するのではなく、要件に沿って適切な構築を考えることが重要です。

■エージェントデザインの基礎

エージェントは基本的な形として、以下の3要素を核として構成されます。

・Model -- LLMなど推論を行う中枢
・Tools -- API／プラグインなど外部機能の呼び出し
・Instructions -- モデルへの指示

以下で順に解説します。

１．Model

その名の通り、AIの各モデルを意味し、エージェントの中枢です。
エージェントでは複数モデルを使用する構成も考えられますが、すべてのタスクに最も賢いモデルやバージョンを使用する必要はありません。選定における推奨手順は以下の通りです。

①各タスクに対して最も能力のあるモデルでエージェントプロトタイプを構築し、パフォーマンス (コストやレイテンシーを含む)も考慮した評価基準を確立
②より小さなモデルに切り替えても妥当な精度が得られるかを確認
③得られた場合は小さなモデルに切り替え

２．Tools

APIによる機能拡張であり、エージェントに必要なツール群です。APIがない場合はエージェントがGUIを操作することになるため、正確性や再現性が低下する恐れがあります。
構成要素及び役割は以下の通りです。

・データ -- データベースや外部ツールから取得した内容、読み取ったPDFやWeb検索結果といった、エージェントがワークフロー実施で使用する情報
・アクション -- メールやテキストを送信、データベースの更新といった、ワークフローで実際に実行される処理
・オーケストレーション -- エージェントをワークフローの一部(ツール)として機能させる際の構成

オーケストレーションについては、「オーケストレーション」セクションにて深掘りします。

３．Instructions

LLMを活用したアプリ、特にエージェントにおいては質の高い「指示(=Instructions)」が欠かせません。指示が明確であればあるほど曖昧さが減り、エージェントの判断が的確になり、ワークフローが円滑に進み、エラーも少なくなるからです。
エージェントにおけるInstructionsのベストプラクティスは以下の通りです。

・既存文書の使用 -- 既存の業務手順書・サポート用スクリプト・ポリシー文書などを活用し、LLMが扱いやすい形に落とし込み
・タスクを分解し指示 -- 密度の高い資料を細分化し、シンプルで明確な手順としたうえで指示
・明確なアクションを定義 -- ルーチンの各ステップは、必ず具体的なアクションまたは成果物にひも付け
・エッジケースを想定する -- 現実世界での実際のやり取りを想定し、想定外の質問といったケースへの条件分岐や対応方法を明確化

こういった工夫により解釈のブレや曖昧さが減り、誤動作を防ぐことが可能になります。

■オーケストレーション

オーケストレーションにはシングルエージェント／マルチエージェントの2方式があります。

①シングルエージェント

1つのエージェントに機能を集約し、プロンプト解決(もしくはやりとりの上限)まで繰り返し処理を行うという方式です。

多くのタスクを段階的にツールに追加することで処理できます。そのため評価や保守を簡素化可能という特徴があります。複数のユースケースに対応したい場合、単一のプロンプトテンプレートでも変数を使用することによって対応可能です。

例：「美味しいハンバーガー屋さんを探して」⇒「美味しい{food}を探して」とし、{food}部分はユーザー入力によって変更することで、1つのプロンプトテンプレートで複数の食べ物に対して対応可能

ただし、ロジックの複雑化(条件複雑化によるif文の過度使用)やツール過負荷(重複ツールによる誤選択等)が発生する場合はマルチエージェント化を検討する必要があります。

②マルチエージェント

シングルエージェントと異なり複数のエージェントを利用する方式です。ワークフローの実行が複数のエージェントに分散され、パフォーマンスとスケーラビリティが向上する可能性があります。反面、コンテキスト共有と整合性の担保が難しいことが特徴です。
マルチエージェントは構成により、２つのパターンに分類することが可能です。

パターンA：マネージャー型
特定分野を担当する「専門家エージェント」と、それを管理する「マネージャーエージェント」に役割を分ける方式です。
ユーザーアクセスをマネージャーエージェントの1点に集中することが可能です。
反面、入口となるエージェントがマネージャー1つに集約されているため、マネージャーエージェントがダウンすると全体使用不可となる依存性があります。

パターンB：分散型
トリガーにより処理を各専門エージェントに完全に引き継がせることでワークフローを解決する方式です。各エージェントの専門性が高い場合、それぞれ独立させモジュール性を高めるという意味でもこちらのパターンが向いています。また負荷分散もしやすく、1つのエージェントがダウンした場合でも他のエージェントは利用可能なため、全体ダウンにならないという特徴もあります。
ただし複数のエージェント間をやり取りしながらワークフローを実施するため、コンテキスト共有がマネージャー型よりも難しく、出力精度担保の難易度が高いという難点もあります。

■Guardrails

エージェントのようなLLMを活用するシステムの利用では、以下のようなリスクが考えられます。

・データプライバシー -- ユーザーが入力した機密情報や、システムプロンプトの漏洩(prompt leak問題)
・風評被害 -- 誤情報／差別的表現／暴力的表現を含むエージェントの回答や、ブランド(※)と合わないトーン／価値観を含む回答によるブランドイメージの悪化

(※)本記事内の「ブランド」は、エージェントを扱ったサービスを提供する企業・組織が持つイメージや価値などを指します。

このようなリスクを回避し、エージェントを安全に、そして安定して使用するためのルールやセキュリティに当たる内容です。
エージェントにおいては、以下のような内容を従来のセキュリティ対策と組み合わせて考えることが重要で、技術進展や運用フィードバックに合わせて継続的に更新する必要があります。

・堅牢な認証および認可プロトコル
・厳格なアクセス制御

またワークフロー中の人間の介入(操作者による操作奪取)は重要な保護手段であり、失敗の閾値を超えた場合や高リスクアクションで有用であるとされています。OpenAIのOperatorでは、IDとパスワードを入力するログイン処理時に、一時的に操作者に操作を委任するという方式を採っています。

Guardrailsの要素としては以下のように定義されています。こういった要素を既存のセキュリティ要素と共にしっかりと組み込むことで、エージェントを安全に使用することが可能となります。

・関連性による分類 -- 意図された範囲内にエージェントの応答を保つために、トピック外の問い合わせにフラグ付け
・安全性による分類 -- システムの脆弱性を利用しようとする不正な入力(脱獄やプロンプトインジェクション)を検出
・PIIフィルター -- PII(Personally Identifiable Information：個人を特定できる情報)を含むデータを精査
・モデレーション -- 危険な行為や不適切な入力(ヘイトスピーチ、ハラスメント、暴力)にフラグ付け
・ツールの安全装置 -- エージェントが利用可能な各ツールのリスクを評価し、読み取り専用と書き込みアクセス、可逆性、必要なアカウント権限、財務的影響などの要因に基づいて、低、中、高の評価付け(例：高リスク機能を実行する前にガードレールチェックのために一時停止、必要に応じて人間にエスカレーション)
・ルールベース保護 -- 禁止された用語やSQLインジェクションのような既知の脅威を防ぐためのシンプルなルールによる保護
・出力検証 -- プロンプトエンジニアリングとコンテンツチェックを通じて、回答がブランドの価値観に沿うことを保証し、ブランドの誠実性を損なう可能性のある出力を防ぐ検証

---

まとめ

OpenAIが提唱するエージェント構築について、解説しました。今回ご紹介した内容の要点を箇条書きでまとめます。

• エージェントの基本的な構成要素 = Model + Tools + Instructions
• まずシングルエージェント構成でプロトタイプを作成し、必要に応じてマルチエージェント化
• Guardrailsを策定する場合、既存のセキュリティ対策と組み合わせ、人間の介入も設計段階で考慮

原点に立ち返ってガイドラインを理解することで、エージェント開発の全体像が掴めます。今回紹介したもの以外にも各社からドキュメントが公開されていますので、併せてご一読ください。

---

参考リンク

• A practical guide to building agents