AI Agentとは何か｜Workflowとの違いと自律実行の仕組みを理解する

「AI Agent」という言葉は、2026年のAI分野で最も頻繁に使われる一方、最も意味が広がっている用語の一つです。

チャットボットにToolを一つ追加したものをAgentと呼ぶ場合もあれば、複数時間にわたりPC上で作業を続けるシステムをAgentと呼ぶ場合もあります。

そのため、製品名ではなくシステム構造から理解する必要があります。

最初に結論を示すと、AI Agentは概念的に、

Goal
↓
Observe
↓
Decide / Plan
↓
Act
↓
Environment changes
↓
Observe again
↓
...

という閉ループの問題解決システムとして捉えると整理しやすくなります。

重要なのは「AIが自動で動く」ことだけではありません。

実行結果を観測し、その結果によって次の行動を変更できることがAgentを理解する中心になります。

今日の到達点

この記事では、次の状態を目指します。

• AI Agentという言葉を技術構造から説明できる
• Agentと決定論的Workflowの違いを説明できる
• Tool Use、Planning、Memory、Environment、Feedback Loopの役割を分離できる
• Agentへ自由度を与えるほど、権限・検証・observabilityが重要になる理由を理解できる
• 工学・設計・自動化で「Agentにすべき処理」と「Workflowのままにすべき処理」を判断できる

AI Agentの定義は一つではない

AI Agentについて注意すべき最初の点は、業界全体で完全に統一された単一定義が存在するわけではないことです。

一方、現在の主要なAgent frameworkを見ると、共通する構造があります。

OpenAIのAgents SDKでは、モデルがtoolやfileを扱いながらagent loopを実行するためのharnessと、隔離されたsandbox環境が提供されています。OpenAI

Microsoft Agent Frameworkは、model、tools、context providers、middleware、multi-step workflowを組み合わせる実行基盤として提供され、2026年にはAgent Harnessがmodel reasoningとshell、filesystem、human approvalなどの実行環境を接続する層として明示されています。Microsoft Dev Blogs

Google CloudもAgent Development Kitについて、multi-step agentがplan、loop、collaboration、dynamic tool callを行うシステムとして説明しています。Google Cloud

これらから共通部分を抽出すると、Agentは概念的に次の要素で構成できます。

Agent
├─ Goal
├─ Model / Reasoning
├─ Tools
├─ Environment
├─ State / Memory
└─ Feedback Loop

すべてのAgentがすべての要素を同じ形で持つわけではありません。

しかし、この分解を使うと「何をAgentと呼んでいるのか」を比較できます。

WorkflowとAgentを分けて考える

Agentを理解するうえで最も重要なのが、Workflowとの違いです。

たとえば毎朝、

Spreadsheetを読む
↓
条件判定
↓
記事を生成
↓
保存

という処理があるとします。

処理順序がprogram側で決まっているなら、これは基本的にWorkflowです。

flowchart TD
    A[Trigger] --> B[Read Data]
    B --> C{Condition}
    C -->|Yes| D[Generate]
    C -->|No| E[Stop]
    D --> F[Save]

分岐はありますが、どの条件でどこへ進むかを人間があらかじめ定義しています。

Agentでは少し違います。

Goal
↓
AIが現在状態を確認
↓
次に必要なActionを選択
↓
Tool実行
↓
結果確認
↓
次のActionを再判断

つまり、

Workflow
→ 経路をprogrammerが決める

Agent
→ 次の行動選択の一部をmodelへ委譲する

という違いがあります。

ここが重要です。

LLMを使っているからAgentなのではありません。

LLM APIをWorkflowの一工程として呼び出しているだけなら、システム全体は依然として決定論的Workflowとして設計できます。

決定論と自律性は二択ではない

実際のシステムは、

Workflow
or
Agent

という完全な二択ではありません。

その中間があります。

たとえば、

Trigger
↓
固定Workflow
↓
Agentに調査を依頼
↓
固定Validation
↓
Human Approval
↓
固定Workflow

という構成が可能です。

つまり、

Deterministic
──────────────
        ↓
   Agentic
        ↓
──────────────
Deterministic

とできます。

実務では、このAgentを限定区間へ埋め込む設計が非常に重要です。

すべてをAgentへ任せる必要はありません。

Agent Loop

Agentの中核がAgent Loopです。

最も単純化すると、

flowchart TD
    G[Goal] --> O[Observe]
    O --> R[Reason / Plan]
    R --> A[Act]
    A --> E[Environment]
    E --> O
    R --> F{Finished?}
    F -->|Yes| X[Result]
    F -->|No| A

重要なのは、Actした後に処理が終了しないことです。

結果を再び観測します。

たとえばWeb調査Agentなら、

「油圧ポンプの最新資料を調査せよ」
↓
Search
↓
検索結果を見る
↓
メーカー公式資料を選択
↓
Open
↓
仕様を読む
↓
不足情報を判断
↓
別資料をSearch
↓
比較
↓
Report

となります。

最初のprompt時点では、何回検索するか、どのページを読むかを完全には決めていません。

実行途中の情報によって次のActionが変わります。

Tool UseはAgentの「手」に相当する

LLM単体は、基本的には入力を受けて出力を生成します。

Input
↓
Model
↓
Output

AgentではToolを接続します。

Model
├─ Search
├─ Browser
├─ Database
├─ Python
├─ Filesystem
├─ Shell
├─ Calendar
└─ API

Modelは、

何をするべきか

を判断し、Toolは、

実際に外界へ何をするか

を担当します。

したがって、

Reasoning
≠
Execution

です。

AIが「ファイルを確認すべきだ」と判断することと、本当にfilesystemへアクセスできることは別です。

Agentには実行interfaceが必要です。

Environmentとは何か

Agentを理解するうえで、Toolと同じくらい重要なのがEnvironmentです。

Environmentは、Agentが観測し、作用する対象世界です。

Coding Agentなら、

Repository
Filesystem
Shell
Compiler
Test Runner
Git

がEnvironmentになります。

Web Agentなら、

Browser
Web Page
Form
Session

がEnvironmentです。

業務Agentなら、

Email
Calendar
CRM
Database
Documents

などがEnvironmentになります。

OpenAIの現在のsandbox agent環境も、filesystem、shell、package、port、snapshotなどを持つ隔離された実行環境として設計されています。OpenAI Developers

つまりAgentは、

Model単体ではなく、ModelとEnvironmentの相互作用

として見る必要があります。

Planningは「最初に完璧な計画を作る」ことではない

Agentというと、

Goal
↓
完全なPlan
↓
実行

を想像しがちです。

しかし現実のAgentでは、実行中に状況が変化します。

したがって、

Plan
↓
Action
↓
Observation
↓
Re-plan

の方が重要です。

たとえば、

公式仕様書を探す

というActionが失敗した場合、

別queryを使う
メーカーsite内検索へ切り替える
GitHub repositoryを調べる

などへ計画を修正できます。

このre-planning能力が、固定Workflowとの大きな違いです。

MemoryとStateを混同しない

Agentの説明ではMemoryという言葉も頻繁に登場します。

しかしMemoryには複数の意味があります。

最低限、次のように分けて考えると安全です。

たとえばAgentが、

3件中2件まで処理済み

と保持するのはtask stateです。

一方、

このuserはMarkdownを好む

のような情報を次回sessionでも使うならpersistent memoryです。

さらに、

メーカーcatalogの仕様

はmemoryというよりexternal knowledge sourceとして管理した方が明確な場合があります。

Day 8ではContext、RAG、Memoryを詳しく分離します。

Feedback LoopがAgentを閉ループにする

工学的に見ると、Agentはfeedback systemとして考えると理解しやすくなります。

Open-loopなら、

Input
↓
Process
↓
Output

です。

Closed-loopでは、

Input
↓
Process
↓
Output
↓
Measurement
↓
Correction

となります。

Agentも似ています。

Goal
↓
Action
↓
Environment
↓
Observation
↓
Correction

ただし、制御工学のfeedback controllerとAgentを同一視してはいけません。

PID controllerなどは数理モデルに基づく決定論的制御です。

Agentは自然言語・Tool・環境状態などを扱い、次の行動選択に確率的modelを使う場合があります。

したがって、

Control Loop
≠
Agent Loop

ですが、

出力結果を観測して次のActionへ戻す閉ループ構造

という点は共通しています。

Agentにしない方がよい処理

「Agent化できる」と「Agent化すべき」は別です。

たとえば、

流量から配管流速を計算する

処理を考えます。

流速は、\[ v = \frac{Q}{A} \]

円管なら、\[ A = \frac{\pi D^2}{4} \]

で計算できます。

入力条件と式が決まっているなら、AI Agentに判断させる理由はありません。

Python関数や計算logicにする方が、

• 高速
• 安価
• 再現可能
• test可能
• audit可能

です。

同様に、

圧力 > 許容圧力ならNG

というruleもAgentへ判断させる必要はありません。

if pressure > allowable_pressure:    status = "NG"

で十分です。

Agentが向いている処理

Agentが価値を出しやすいのは、次に何をすべきかが事前に完全には決められない問題です。

たとえば、

設備異常の原因候補を調査する

場合、

症状確認
↓
履歴確認
↓
図面確認
↓
メーカー資料検索
↓
候補原因生成
↓
不足情報確認
↓
追加調査

と進みます。

どの資料を何件読むか、途中でどの仮説を捨てるかは、取得情報によって変わります。

このようなtaskはAgent向きです。

AgentとWorkflowを組み合わせる

実務で強力なのはHybrid Architectureです。

flowchart TD
    A[Input] --> B[Deterministic Validation]
    B --> C[Agent Investigation]
    C --> D[Structured Output]
    D --> E[Rule Engine]
    E --> F{Valid?}
    F -->|No| G[Agent Revision]
    G --> D
    F -->|Yes| H[Human Approval]
    H --> I[Deterministic Execution]

Agentには、

調査
比較
候補生成
説明

を担当させます。

固定logicには、

計算
validation
constraint
permission

を担当させます。

人間には、

risk判断
最終承認
責任

を残します。

これはAgentを「何でもするAI」にしない設計です。

自律性が上がるほど失敗経路も増える

Agentは柔軟ですが、その柔軟性自体がriskになります。

固定Workflowなら、

A → B → C

しかありません。

Agentでは、

A
├─ B
├─ C
├─ D
└─ E

から行動を選び、その後も新しい分岐が生まれます。

長いtrajectoryでは、一つの誤判断が後続処理へ影響します。

Microsoft Researchが2026年に公開したAgentRxも、Agentのfailureは長く確率的なtrajectoryに埋もれ、root causeの特定が難しいことを問題として扱っています。Microsoft

Agentの品質評価では、最終回答だけを見るのでは不十分です。

Observabilityが必要になる

Agentでは、

何を考えたか

を完全に読むことより、

どのToolを呼んだか
何を入力したか
何が返ったか
どの状態からどの状態へ進んだか

を追跡できることが重要です。

OpenAI Agents SDKでは、run、model call、tool call、handoff、guardrailなどをtraceとして記録する仕組みが提供されています。OpenAI Developers

Google CloudもADK Agentについて、予測不能性、cost、security riskを管理するためobservabilityが重要だと説明しています。Google Cloud

つまりAgentでは、

Automation
+
Observability

が必要です。

自動化したから人間が見なくてよい、ではありません。

自動化したからこそ、後から追跡可能にする必要があります。

Agentの失敗モード

Agentでは通常のLLMとは異なる失敗があります。

誤ったToolを選ぶ

正しい情報源があるのに別Toolを使用する場合があります。

同じ処理を繰り返す

終了条件を適切に判断できず、

Search
↓
Search
↓
Search
↓
...

となる可能性があります。

Goalから逸脱する

長時間taskでは途中の情報へ引きずられ、本来の目的から離れることがあります。

誤ったActionがEnvironmentを変更する

文章のhallucinationとは異なり、Agentの誤りはfile、database、calendarなど現実の状態を変える可能性があります。

Costが予測しにくい

loop回数、Tool call数、context量が固定されていなければ、処理costも変動します。

Stop Conditionを設計する

Agentには「いつ終わるか」を定義する必要があります。

たとえば、

Goal達成
最大iteration到達
時間上限
cost上限
Tool failure
Human approval要求

などです。

概念的には、

while not goal_reached:    observe()    decide()    act()    if iteration >= max_iterations:        break

のような境界が必要です。

無制限の自律性は能力ではありません。

制御不能なloopです。

Permission Boundary

AgentがToolを使うなら、permissionも設計対象です。

たとえば、

Agentに与える権限は、

能力が高いから広くする

のではなく、

taskに必要な最小範囲だけ与える

のが基本です。

Agentの評価方法

Agent評価では、最終成果だけでなくtrajectoryも評価します。

単純なbenchmark scoreだけでは、production Agentの良し悪しは判断できません。

たとえば成功率が高くても、毎回100回Toolを呼ぶAgentは運用上問題になる可能性があります。

工学Agentを考える

機械設計でAgentを作るなら、すべてをAIへ任せるのではなく、Engineering Knowledgeと接続する必要があります。

たとえば配管径選定なら、

flowchart TD
    A[Design Requirement] --> B[Agent]
    B --> C[不足条件を確認]
    C --> D[Engineering Database]
    D --> B
    B --> E[候補条件を構造化]
    E --> F[Deterministic Calculation]
    F --> G[Rule Engine]
    G --> H{Valid?}
    H -->|No| B
    H -->|Yes| I[Candidate Design]
    I --> J[Engineer Review]

ここでAgentが担当するのは、

要求理解
不足条件発見
資料探索
候補整理

です。

一方、

流速計算
圧損計算
許容値判定

は決定論的logicへ任せます。

これにより、

AIの柔軟性
+
工学計算の再現性

を組み合わせられます。

Knowledge AssetとAgent

Agent時代に重要になるのは、AIモデルそのものだけではありません。

Agentが参照できる、

Data
Rules
Functions
Tests
Documents
APIs

が資産になります。

たとえば設計知識を文章だけで保存するより、

Knowledge
↓
Structured Data
↓
Design Rule
↓
Calculation Function
↓
Validation Test
↓
Agent Tool

へ変換すると、Agentから再利用できます。

ここで重要なのは、Agentに知識そのものを埋め込むのではなく、知識資産をAgentから呼び出せる形にすることです。

そうすれば、将来modelやAgent frameworkを交換しても、設計logicを再利用できます。

Agent Frameworkは交換可能にする

2026年にはOpenAI Agents SDK、Google ADK、Microsoft Agent Frameworkなど複数のAgent基盤があります。Microsoft Agent Frameworkは2026年4月2日に1.0 GAとなり、AutoGenとSemantic Kernelの流れを統合したSDK/runtimeとして展開されています。Microsoft Dev Blogs

重要なのは、特定frameworkのAPIをすべて覚えることではありません。

次の抽象構造を理解しておけば、frameworkが変わっても考え方を再利用できます。

Goal
↓
Agent Harness
├─ Model
├─ Context
├─ Tools
├─ State
├─ Guardrails
└─ Observability
↓
Environment

この構造を理解する方が、製品固有UIを暗記するより長期的な価値があります。

AI Agentの本質

Agentの本質を「AIが勝手に仕事をすること」と考えると、設計を誤ります。

本質は、

不確実な環境で、観測結果に応じて次のActionを選択する能力をmodelへ部分的に委譲すること

です。

したがってAgent化には必ずtrade-offがあります。

Autonomy ↑
Flexibility ↑

しかし

Predictability ↓
Cost Variance ↑
Failure Paths ↑
Governance Need ↑

AgentはWorkflowの上位互換ではありません。

問題によって使い分けるものです。

まとめ

AI Agentは、単なるLLMでも、単なるAutomationでもありません。

概念的には、

Goal
+
Reasoning
+
Tools
+
Environment
+
State / Memory
+
Feedback Loop

を組み合わせた問題解決システムです。

固定Workflowとの最大の違いは、

実行途中の観測結果によって、次の行動選択をmodelへ委譲できること

にあります。

一方で、計算式、設計rule、validationなど、決定論的に処理できるものまでAgentへ渡す必要はありません。

実務では、

Deterministic Workflow
+
Agentic Decision
+
Deterministic Verification
+
Human Approval

というHybrid Architectureが重要になります。

AI Agentの価値は「人間を完全に外すこと」ではありません。

あらかじめ全手順を書けない仕事の一部をAIへ委譲しながら、Tool、permission、validation、observability、human reviewによって制御可能なsystemにすることです。

そして長期的に重要なのは、Agentそのものより、そのAgentが利用できる再利用可能な知識です。

Document
↓
Data
↓
Rule
↓
Function
↓
Test
↓
Tool
↓
Agent

この順に知識を構造化すれば、Agent frameworkやAI modelが変わっても資産を残せます。

参考情報

• OpenAI「The next evolution of the Agents SDK」
• OpenAI API「Sandbox Agents」
• OpenAI API「Integrations and observability」
• Microsoft「Agent Framework at BUILD 2026」
• Microsoft Research「AgentRx」
• Google Cloud「Monitoring ADK agentic applications」
• Microsoft Research「Orchard」

今日の確認問題／学習課題

1. WorkflowとAgentの違いを、「次のActionを誰が決めるか」という観点から説明してください。
2. 自分が知っている自動化処理を一つ選び、決定論的Workflow / Agentへ委譲 / Human Approvalの3領域へ分解してください。
3. 流量・配管径から流速を計算する処理をAgent化する必要がない理由を、再現性・cost・testabilityの観点から説明してください。
4. Agentを長時間動かす場合に必要なStop Conditionを、iteration・時間・cost・permissionの観点から設計してください。

次回予告

Day 7｜MCP・A2A・Agent接続

次回は、Agentが外部世界と接続する仕組みを整理します。

API
Function Calling
MCP
A2A
Connector
Tool

は似た文脈で使われますが、役割は同じではありません。

Day 7では、それぞれを「誰と誰を接続する仕組みなのか」「どこまでをprotocolが担当するのか」という責務境界から分解します。

特にMCPとA2Aについては、2026年10月時点の公式仕様status・versionを再確認したうえで、Agent ecosystemの接続層として技術地図へ配置します。