agentという言葉には、どこか「自律的に動き続けるもの」という印象がある。
ユーザーが目的を与える。
AIが計画を立てる。
toolを呼ぶ。
結果を見る。
また考える。
また実行する。
このloopを見ると、agentとは「目的に向かって自動的に進み続けるAI」のように見える。
しかし、agentic systemを安全に設計するうえで、本当に重要なのは「どう続けるか」だけではない。
むしろ重要なのは、いつ止まるかである。
agentic loopとは、モデルが自律的に動き続けることではない。observe、decide、act、verifyを繰り返しながら、明示された停止条件・検証条件・予算・権限・安全条件に従って、続行または停止を選ぶ制御ループである。
07では、agentが「続行する」「再試行する」「検証する」「人間に確認する」「別agentへ渡す」「停止する」を、何を根拠に決めるのかを扱う。
1. agentic loopは無限ループではない
agentic loopを単純化すると、次のようになる。
receive task
↓
observe context
↓
decide next action
↓
act / call tool / answer / ask user / handoff
↓
observe result
↓
verify
↓
continue or stop
ここで重要なのは、最後が continue だけではないことだ。
agentic loop = continue forever
ではない。
より正確には、次である。
agentic loop = decide whether to continue
agentは、まだできることがあるから続けるのではない。
続ける理由があり、続ける権限があり、続ける予算があり、続ける安全性があり、続けた結果を検証できるときだけ続ける。
more steps ≠ better agent
more tool calls ≠ more autonomy
longer loop ≠ better completion
safe stopping ≈ reliable agent
agentの賢さは、長く走り続けることでは測れない。
不要に続けないこと、危険なまま進めないこと、根拠なく完了扱いしないことが重要である。
2. stopはfailureではない
停止という言葉は、失敗のように聞こえる。
処理が止まった。
先へ進めなかった。
完了できなかった。
しかし、agentic workflowにおいて、停止は必ずしも失敗ではない。
むしろ、正しく止まることはagentの能力である。
| 停止種別 | 意味 | 例 |
|---|---|---|
| completed | 成功条件を満たして完了した | レポートを作成し、検証も通った |
| failed | 必要な処理に失敗し、回復不能 | 必須APIが失敗し続けた |
| blocked | 外部条件が足りず進めない | 権限、ファイル、接続、情報が不足している |
| needs_user | ユーザー判断が必要 | 曖昧な選択、承認、追加情報が必要 |
| manual_review | 人間の確認なしに進めるべきではない | 法務、財務、削除、送信、公開など |
| handoff | 別agent・別workflowへ渡す | 専門agent、承認者、外部systemへ移す |
| aborted | 安全・権限・方針により中止 | 危険操作、policy conflict、意図不明な破壊的操作 |
ここで大事なのは、すべてを failed にしないことである。
ユーザー確認が必要な状態は、失敗ではない。
権限が足りない状態も、失敗とは限らない。
成功条件を満たして止まることは、もちろん失敗ではない。
安全上止めることも、むしろ成功した制御である。
stop ≠ failure
blocked ≠ failed
needs_user ≠ failed
handoff ≠ failed
safe abort ≠ failed
3. success criteriaがないagentは止まれない
agentが止まれない最大の理由は、成功条件が曖昧なことである。
たとえば、ユーザーがこう依頼したとする。
この件を調べて、いい感じにまとめて。
この依頼だけでは、agentはどこで止まればよいか分かりにくい。
何件調べるのか。
どのsourceを信頼するのか。
どの深さまで読むのか。
どの形式でまとめるのか。
矛盾があったらどうするのか。
最新情報をどこまで確認するのか。
ユーザー判断を挟むべきか。
success criteriaが曖昧なままagentにtoolを渡すと、次のような挙動になりやすい。
search
↓
read
↓
more search
↓
more read
↓
maybe enough?
↓
summary
↓
maybe more search?
これは賢く調べているように見える。
しかし設計上は、停止条件が弱い。
agentには、次のような明示条件が必要である。
stop when:
- required sources have been checked
- contradictions have been noted
- confidence threshold is met
- output format is complete
- no unresolved required fields remain
- budget is not exceeded
- no approval-gated action remains pending
停止条件は、task goalから自動的には出てこない。
application側が、成功条件、失敗条件、確認条件、handoff条件として定義する必要がある。
4. loop stateとbudget
agentic loopを制御するには、現在の状態を持たなければならない。
今、何step目なのか。
どのtoolを何回呼んだのか。
どの試行が失敗したのか。
あと何回retryできるのか。
これ以上続けるとcostやriskが高すぎないか。
状態を持たないloopは、自分が同じ場所を回っていることに気づけない。
予算を持たないloopは、どこまで続けてよいかを判断できない。
loop without state
→ 自分が何をしたか分からない
loop without budget
→ どこまで続けてよいか分からない
agentic workflowで扱うbudgetには、少なくとも次がある。
| budget | 意味 | 停止・分岐例 |
|---|---|---|
| turn budget | 思考・応答step数の上限 | 上限到達でsummary / handoff / stop |
| tool call budget | tool実行回数の上限 | 検索やAPI呼び出しの暴走を防ぐ |
| time budget | 実行時間の上限 | 時間切れならpartial resultやhandoff |
| cost budget | APIや外部処理の費用上限 | 高額処理前に確認 |
| token budget | context / output量の上限 | 要約・分割・圧縮へ切り替える |
| retry budget | 失敗時の再試行上限 | 無限retryを防ぐ |
| risk budget | 許容される危険度の上限 | 権限・安全・法務境界で止める |
| side effect budget | 外部状態変更の許容量 | 送信、削除、公開、決済などを制御 |
特に重要なのは、read-onlyなtool callとstate-changingなtool callを分けることである。
ファイルを読む、検索する、カレンダーを見る。
これらは基本的に観測である。
一方で、メールを送る、予定を作る、ファイルを削除する、PRをmergeする、支払いを実行する。
これらは外部状態を変える。
read-only action
≠ state-changing action
state-changing action
requires stronger gate
5. verification loop
agentが「完了しました」と言うことと、実際に完了していることは違う。
モデルは、もっともらしく完了を宣言できる。
tool resultは、呼び出しが成功したことを示すかもしれない。
JSONはschema validationを通るかもしれない。
しかし、それだけではtaskが完了したとは限らない。
model says completed ≠ task completed
tool call succeeded ≠ task goal achieved
valid JSON ≠ correct answer
file created ≠ useful artifact
verification loopとは、agentの自己申告やtool resultの存在を完了とみなさず、成功条件・証拠・成果物・差分・テスト・reconciliationを通じて、taskが本当に完了したかを確認する仕組みである。
検証には、少なくとも次の種類がある。
| verification | 確認するもの | 例 |
|---|---|---|
| schema validation | 形式が契約に合うか | JSON Schemaに通る |
| tool result verification | toolの返り値が期待通りか | 作成したページのURLが返る |
| artifact verification | 成果物が存在し、内容が入っているか | 作成した文書をfetchして確認する |
| evidence check | 主張が根拠に支えられているか | 引用元と本文が対応している |
| diff check | 変更が意図通りか | 不要な削除がないか確認する |
| dry run / test | 実行前に安全に試せるか | 本番前にpreviewやtestを走らせる |
| reconciliation | 複数sourceが一致するか | 会計データや在庫数を照合する |
completedは、自己申告ではない。
completedとは、成功条件を満たし、必要な検証を通った状態である。
6. guardrailsとstop gates
guardrailsは、単なる注意書きではない。
「危ないことをしないでください」とpromptに書くだけでは、agentic workflowの制御としては弱い。
guardrailは、各stepで続行可否を判定するstop gateである。
observe
↓
guardrail check
↓
decide
↓
guardrail check
↓
act
↓
guardrail check
↓
verify
↓
continue or stop
主なguardrailには次がある。
| guardrail | 対象 | 例 |
|---|---|---|
| input guardrail | ユーザー入力 | 危険依頼、個人情報、意図不明な破壊的操作 |
| output guardrail | agent出力 | 機密漏洩、誤った断定、禁止された形式 |
| tool guardrail | tool call | 許可されないAPI、危険な引数、過剰実行 |
| permission guardrail | 権限 | 認可不足、他人のデータ、未承認操作 |
| safety guardrail | 安全性 | 危険行為、違法行為、身体的・経済的被害 |
| privacy guardrail | 個人情報・機密情報 | 不要な露出、越境共有、保存範囲違反 |
重要なのは、policy failureとtask failureを混同しないことである。
ユーザーの依頼を完了できない理由が、技術的失敗なのか、権限不足なのか、安全上の停止なのかで、返すべき状態は変わる。
task failure
= 目的達成に失敗した
policy failure
= その目的または手段では進めない
permission failure
= 権限が足りない
verification failure
= 完了したと確認できない
不確実なときは、安全側に倒す。
これがfail closedである。
if uncertain and risk is high:
do not proceed silently
ask user / require approval / handoff / stop
fail openは、危険なまま続ける設計である。
fail closedは、危険なときに止まる設計である。
7. ask user / manual review / handoff
agentは、自分だけで完結するほどよいとは限らない。
正しいagentは、必要なときにユーザーへ確認し、人間のreviewを挟み、別agentや別workflowへhandoffできる。
ここでは、三つを分ける。
| 分岐 | 意味 | 例 |
|---|---|---|
| ask user | ユーザー判断や追加情報が必要 | 候補A/Bの選択、曖昧な条件の確認 |
| manual review | 人間の確認なしに進めるべきではない | 送信、公開、削除、契約、支払い |
| handoff | 別agent・別workflowへ責務を渡す | 専門agent、承認者、別システムへ移す |
ask userは、agentの失敗ではない。
むしろ、判断権限を人間に戻す正常な制御である。
manual reviewは、情報不足とは限らない。
情報が足りていても、人間の責任や承認が必要な場面がある。
handoffは、放棄ではない。
責務範囲の移転である。
ただし、handoffにはcontext lossが起きやすい。
何を引き継ぐのか、どこまで確認済みなのか、何が未解決なのかをmanifestとして渡す必要がある。
type HandoffManifest = {
taskId: string;
fromAgent: string;
toAgent: string;
reason:
| "specialized_skill_required"
| "permission_required"
| "manual_review_required"
| "insufficient_context"
| "budget_exceeded"
| "risk_too_high";
currentState: string;
completedSteps: string[];
verifiedResults: string[];
unresolvedQuestions: string[];
requiredApprovals: string[];
artifacts: {
name: string;
url?: string;
status: "draft" | "verified" | "needs_review";
}[];
recommendedNextAction: string;
};
handoffが成立するには、単に「次お願いします」と言うだけでは足りない。
context packが必要である。
8. trace / audit / evaluation
agentic loopは、その場でうまく動くだけでは不十分である。
後から説明できなければならない。
再現できなければならない。
評価できなければならない。
改善できなければならない。
そのために必要なのが、trace / audit / evaluationである。
traceは単なるログではない。
重要なのは、「何をしたか」だけではない。
「なぜそのactionを選んだのか」「なぜ別のactionを選ばなかったのか」「なぜ止まったのか」を再構成できることである。
trace = what happened
+ why it happened
+ what was considered
+ what was rejected
+ why it stopped
agentic workflowでは、実行したactionだけでなく、実行しなかったactionも重要になる。
たとえば、メールを送れるtoolがあったが、承認がなかったため送らなかった。
ファイルを削除できたが、破壊的操作なので止めた。
追加検索できたが、必要なsource確認が済んでいたため止めた。
これらはすべて、agentの正常な判断である。
type AgentDecisionLog = {
runId: string;
stepId: string;
observedState: string;
candidateActions: {
action: string;
expectedBenefit: string;
risk: "low" | "medium" | "high";
cost: "low" | "medium" | "high";
requiresApproval: boolean;
selected: boolean;
reason: string;
}[];
verificationStatus?: "not_checked" | "passed" | "failed" | "inconclusive";
stopReason?:
| "completed"
| "failed"
| "blocked"
| "needs_user"
| "manual_review"
| "handoff"
| "aborted"
| "budget_exceeded";
};
traceは、debugのためだけではない。
監査のためでもある。
どのtoolが呼ばれたか。
どのデータが読まれたか。
どの外部状態が変更されたか。
どの承認があったか。
どのguardrailが発火したか。
どこで停止したか。
これらがなければ、agentic workflowは運用できない。
9. evaluationとregression test
agentの評価は、答えの良し悪しだけではない。
停止できたかも評価対象である。
- 成功条件を満たしたら止まれたか
- 根拠不足のまま完了扱いしなかったか
- budgetを超えて走らなかったか
- 危険なtool callの前で止まれたか
- 承認が必要な場面でask userできたか
- handoff時にcontextを失わなかったか
- 同じ失敗を次回防げるか
agentic systemの評価では、成功例だけでなく停止例もtest caseにする必要がある。
should_continue cases
should_stop cases
should_ask_user cases
should_handoff cases
should_fail_closed cases
replayは、過去のrunを再実行または再検討する仕組みである。
regression testは、以前防げた失敗を再発させない仕組みである。
agentは、その場限りの会話相手から、運用可能なsystemへ移るほど、traceとevaluationが重要になる。
10. 07まとめ
agentic loopとは、AIが勝手に動き続けることではない。
observe、decide、act、verifyを繰り返しながら、停止条件、budget、verification、guardrails、handoff、traceに従って、続行または停止を選ぶ制御loopである。
model
+ tools
+ context
+ loop state
+ budget
+ verification
+ guardrails
+ handoff
+ trace
+ evaluation
= operable agentic system
ここまで来ると、生成AIアプリケーションは単なる「モデルへの入力と出力」ではなくなる。
01でrequest objectを組み立てた。
02でinstruction hierarchyを扱った。
03でcontext windowを扱った。
04でtool call loopを扱った。
05でstructured outputsを扱った。
06でmemoryとpersonalizationを扱った。
07でagentic loopの停止条件と検証を扱った。
次の08では、これらを一つの全体アーキテクチャとして組み直す。
model、application、runtime、context、memory、tools、schema、guardrails、trace、人間の承認。
これらがどの層にあり、どこで接続し、どこで失敗し、どこで制御されるのかを、全体図として整理する。