# AI Agentとは — Webシステムに組み込むための構成と責任境界

> AI Agentの定義、ワークフローやチャットボットとの違い、Tool・Memory・Identity・評価を含む本番実装の判断基準を整理します。

Canonical URL: https://labs.eastbraver.com/guides/ai-agent
Published: 2026-07-01
Updated: 2026-07-24
Category: field-guide
Tags: ai-agent, software-engineering, agentic-infra

AI Agentは、[LLM](/guides/llm)が[PromptとInstruction](/guides/prompt-and-instruction)で与えられた目標に応じて処理の進め方や[Tool](/guides/tool)の利用を選び、外部システムとやり取りしながら複数のステップを進めるシステムです。

チャット画面からLLMを呼び出しただけでは、AI Agentとは呼びません。判断を伴う実行ループがあり、必要に応じてデータを読み、Toolを呼び、結果を確認する。そこから続行・停止・人間への引き継ぎを選ぶところまでが中心になります。

## ワークフローとの境界は、処理経路を誰が決めるか

AI Agentには業界全体で一つに固定された定義があるわけではありません。[Anthropicは、事前に定義されたコードパスでLLMとToolを動かすものをWorkflow、LLMが処理とTool利用を動的に決めるものをAgentとして区別しています](https://www.anthropic.com/engineering/building-effective-agents)。[OpenAIは、LLMがワークフローの実行を管理し、Toolを動的に選びながら利用者に代わってタスクを完了するシステムとして説明しています](https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/)。

このGuideでは、**処理経路の一部をモデルが決め、外部の状態を読み書きしながら目標へ進むシステム**をAI Agentとして扱います。

| 仕組み | 処理経路 | 外部への操作 | 主な用途 |
| --- | --- | --- | --- |
| チャットボット | 会話やルールに沿う | 通常は限定的 | 質問応答、案内 |
| [RAG](/guides/rag) | 検索して回答へ渡す流れを実装側が決める | 主に読み取り | 社内検索、根拠付き回答 |
| 決定的なWorkflow | コードや設定で固定する | 定義した範囲 | 定型処理、承認フロー |
| AI Agent | モデルが次の処理やToolを選ぶ | 読み取りと更新 | 調査、運用支援、複雑な業務処理 |

RAGやWorkflowをAI Agentの内部で使うこともあります。排他的な分類ではなく、どこまでモデルに判断を渡すかを見るための境界です。

## Webエンジニアに関係するのは、モデルより外側の設計

WebシステムへAI Agentを入れると、これまでアプリケーションコードが決定的に選んでいたAPIやデータ更新を、モデルの判断から呼び出す場面が生まれます。

問い合わせ内容を読んで注文を検索するだけなら、失敗時の影響は比較的小さく抑えられます。同じAgentへ返金・アカウント停止・メール送信まで許可すると、Tool選択や引数の誤りが、そのまま業務上の操作になります。

ここは、プロンプトを細かく書くだけでは足りません。

- 誰の権限で実行するか
- どのデータとToolを見せるか
- どの操作で人間の承認を求めるか
- 再試行してよい処理か
- どの状態を[Memory](/guides/memory)へ残すか
- 何をログとして追跡するか
- どこで停止し、人間へ戻すか

既存の認証・認可・API・監査ログへAI Agentをどう接続するか。これは、Webエンジニアが扱ってきたシステム設計の延長にあります。

## AI Agentは実行ループと運用境界からできている

[OpenAIの整理では、Agentの基本要素はModel、Tools、Instructionsの三つです](https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/)。本番のWebシステムでは、そこへ実行状態と運用境界を加えて考えると、構成を切り分けやすくなります。

### AI Agentを構成する実行loopと統制

Agent loopはModel、Tools、Stateを反復利用し、結果をHuman handoffとLogsへ接続します。IdentityとPolicyはAgentとToolの両方へ適用し、実行主体と許可範囲を統制します。

- UserまたはEventがAgent loopを開始します。
- AgentはModel、Tools、Stateを往復しながら処理を進めます。
- 必要な処理をHuman handoffへ渡し、Logs、Traces、Evalsへ記録します。
- IdentityとPolicyをAgentとToolの双方へ適用します。

*Agent loopを中心にModel、Tool、State、承認、観測を接続する構成*

### Model

目標や現在の状態をもとに、次の処理やToolを選びます。性能だけを見ればよいわけではなく、レイテンシ・コスト・利用可能なリージョン・データ取り扱い条件も選定に影響します。

### Instructions

Agentの役割、守るべき業務ルール、終了条件、禁止事項を伝えます。ただし、Instructionsは認可機構の代わりにはなりません。実行してはいけない操作は、Tool側やAPI側でも拒否できる状態にしておきます。

### Tools

検索・データ取得・更新・通知といった外部操作を提供します。Toolの名前と説明、入力Schema、返却値、エラーが曖昧だと、モデルは正しく選びにくくなります。広い管理APIを一つ渡すより、業務上の一操作へ絞ったToolの方が、権限と評価を整理しやすいと思います。

### Agent loop

モデル呼び出し、Tool実行、結果の取り込み、続行判断を繰り返します。最大ターン数、タイムアウト、キャンセル、失敗時の引き継ぎをここで管理します。長時間の反復と停止条件は[Loop Engineering](/guides/loop-engineering)で扱います。

### StateとMemory

現在の処理状態と、セッションをまたいで保持する情報を分けます。すべての会話やTool結果を長期保存すると、古い情報・個人情報・削除要件まで抱えることになります。[Context Engineering](/guides/context-engineering)では、次の判断へ何を渡すかまで含めて設計します。**何を覚えないか**も設計対象です。

### IdentityとPolicy

利用者、Agent、実行先ToolのIdentityを区別します。[IdentityとAuthorization](/guides/ai-identity-authorization)では、利用者の代理として動くのか、Agent固有のサービス権限で動くのかを分けます。ここが違うと、認可と監査の意味も変わります。

### Observabilityと評価

最終回答だけでなく、選択したTool・引数・Tool結果・再試行・停止理由を[Trace](/guides/observability-tracing)で追えるようにします。ログは障害調査に、評価は期待した振る舞いの継続確認に使います。

[Amazon Bedrock AgentCoreはRuntime、Memory、Gateway、Identity、Observability、Evaluationsを分けて提供しています](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/)。[Cloudflare AgentsもAgent harness、永続状態を持つRuntime、Tools、Observabilityを別の構成要素として説明しています](https://developers.cloudflare.com/agents/)。製品の違いはありますが、モデルの外側に複数の責任がある点は共通しています。この外側を作業環境としてまとめて設計する考え方が[Harness Engineering](/guides/harness-engineering)です。

## AI Agentを使うかは、曖昧さと失敗時の影響で決める

手順をコードで安定して表現できるなら、決定的なWorkflowを先に選ぶ方が運用しやすいと思います。Agentが候補になるのは、状況に応じて手順が変わり、非構造データを読み、すべての分岐を事前に書き切れない仕事です。

導入前には次の条件を確認します。

- 成功状態と失敗状態を観測できる
- Toolを最小権限へ分割できる
- 高リスク操作を承認または拒否できる
- 同じ入力を複数回試して評価できる
- 途中状態から再開または安全に中止できる
- 人間へ戻す条件を決められる

判断が曖昧な業務だからAgentを使うとしても、権限や停止条件まで曖昧にしてよいわけではありません。ここは分けて考えたいところです。

## よくある誤解

### 自律性が高いほど優れたAgentになる

自律性を広げるほど、予想していなかった経路と操作も増えます。固定Workflowで十分な部分までモデルに決めさせる必要はありません。必要な判断だけを渡し、それ以外はコード・Policy・Toolの境界で固定します。

### 強いモデルへ変えれば本番運用できる

モデルを変えても、認証・認可、冪等性、監査、データ保持、切り戻しは残ります。モデルの改善と運用設計は別の作業です。

### プロンプトへ禁止事項を書けば安全になる

InstructionsはAgentの判断を助けますが、強制力のあるアクセス制御ではありません。許可されていない操作は、APIとToolの実装で拒否します。

### Multi-Agentから始めた方が拡張しやすい

Agentを分けると、引き継ぎ・権限・状態・評価対象も増えます。単一Agentと少数のToolで責任を説明できなくなった時点で、分割を検討するくらいがよいと思います。

## EastBraver Labsの判断基準

EastBraver Labsでは、AI Agentの価値を自律性の高さだけでは判断しません。

**Agentが間違えても、影響範囲を限定でき、どの判断と操作をしたか後から追えること**を本番利用の前提として考えます。

モデルが選ぶ範囲と、システム側で強制する範囲を分けます。まずは読み取りから。更新操作はToolを小さくし、取り消せない操作には承認を置きます。Agentが成功した一例より、失敗時にどこで止まり、誰が戻せるかを先に確認します。

実装基盤を選ぶときも、対応モデル数やデモの作りやすさだけではなく、Identity、状態の分離、監査ログ、評価、デプロイと切り戻しを比較します。

## 関連記事

- [AI Agent 時代に、エンジニアは何を設計する人になるのか](/blog/ai-development-20260706)
- [エージェント基盤は非同期運用へ](/digest/ai-digest-20260708)
- [エージェント運用の境界が具体化](/digest/ai-digest-20260709)
- [GPT-5.6とAI実行基盤の境界](/digest/ai-digest-20260710)

## 検証範囲

- 一次情報: 公式ドキュメント / 設計面からの分析
- ローカル検証: 手元で再現しています
- 実運用: 関連するWeb業務システムの設計・運用経験をもとにしています

## 変更履歴

- 2026-07-24: Mermaid図にテキスト等価物を追加
- 2026-07-15: 検証範囲と根拠区分を明示
- 2026-07-01: 初版公開