AIエージェントという言葉を聞くと、

自分で考える
Toolを使う
ブラウザを操作する
コードを書く
複数Agentが連携する
長時間、自律的に働く

といった派手な機能を想像しがちです。

もちろん、それらもAgentの一部です。

ただ、実務で先に壊れるのはもっと地味なところです。

目的が残っていない。現在地が分からない。次の処理を始められない。途中停止したら最初からやり直し。

どれだけ賢いModelでも、この4つが閉じていなければ長時間の仕事は安定しません。

そこで本教材では、AIエージェントを製品名やSDKではなく、

Goal
State
Trigger
Recovery

という4つの運用要素へ分解します。

目標は「何時間も止まらず動くAgent」を作ることではありません。

途中で止まっても、何が終わり、何が残り、次にどこから再開するか説明できる仕事へ変えること。

専用Agent Frameworkがなくても始められます。

普通のChat、JSON、File、Python程度でも、この骨格は作れます。

30秒診断――そのAgent、停止したら戻れますか？

いま動かしているAIを強制終了したとします。

新しいThreadや別Modelへ移ったとき、次の4問へすぐ答えられるでしょうか。

GOAL
何をもって完了か？

STATE
どこまで確定し、何が未確認か？

TRIGGER
次の処理は何をきっかけに始まるか？

RECOVERY
壊れたらどこへ戻るか？

一つでも「会話を全部読み直さないと分からない」なら、その部分はまだ外部化されていません。

これが本教材の出発点です。

この教材で持ち帰るもの

AgentをGoal / State / Trigger / Recoveryへ分解する方法
GoalとPromptの違い
Human-known StateとAI-accessible State
最小State Schema
Job Stateの分離
Liveness / Progress / Acceptance
CheckpointとRecovery Unit
Real-time Mirror / Manual Snapshot
再実行しやすいJob設計
Retry Delta
ReviewerとRepairの分離
Human Handoff
Model / Code / Humanの役割分担
Failure Matrix
開始・停止・再開チェックリスト

1. AIエージェントを「自律性」だけで考えない

「AIが自分で次の作業を考えられる」

これは便利です。

しかし、前回どこまで終わったかを失えば、同じ仕事をもう一度始めます。

ブラウザ操作ができても、途中停止後の復帰地点がなければ最初からやり直しです。

高性能Modelでも、Goalが途中でズレれば、長時間かけて間違った方向へ進みます。

つまり、

自律的に動けること

と、

長時間の仕事を安定して完了できること

は別です。

Agent運用では、「賢さ」だけでなく仕事を継続する構造を持たせます。

2. Goal――何を「完了」とするのか

「記事を書いて」

これは依頼ではありますが、強いGoalではありません。

完成条件が分からないからです。

たとえば記事制作なら、

本文が完成
タイトルが確定
タグがある
ヘッダーがある
有料境界が決まっている
最終検査を通っている

まで決めれば終了を判定できます。

Goalは「やってほしいこと」だけではありません。

終了条件を含んだ仕事の定義です。

3. GoalとPromptを分ける

Promptは、今回どう動いてほしいかを伝えるものです。

Goalは、何を達成すれば仕事が終わるかを決めるものです。

例：

GOAL
35記事を公開可能な状態へする

PROMPT
次の未処理記事を開き、
価格・タグ・ヘッダー・本文を確認し、
条件を満たせば次へ進む

Promptは変わってもGoalは同じことがあります。

逆にGoalが変わったなら、Promptだけ修正して済ませない方が安全です。

4. State――今どこにいるのか

Agentが長時間作業するなら、現在地を会話だけへ置かない方が扱いやすくなります。

最小なら、こんなStateで十分です。

{
  "job": "article_batch",
  "current": "draft_003",
  "completed": ["draft_001", "draft_002"],
  "pending": ["draft_004", "draft_005"],
  "last_checkpoint": "cp_012",
  "next_action": "draft_003を検査"
}

重要なのは豪華なSchemaではありません。

再開時に必要な質問へ答えられること

です。

5. 「AIが覚えている」と「Stateが存在する」は別

会話内で覚えているように見えても、

Threadを変える
Modelを変える
Contextが長くなる
Tool経由の別Workerへ渡す

と前提が崩れることがあります。

そこで、

会話中の記憶ではなく、外部から確認できるState

を持ちます。

JSONでもMarkdownでも構いません。

大事なのは、必要なCurrent StateをAIが読める場所へ置くことです。

6. Human-known StateとAI-accessible Stateを分ける

人間側では、

「前回決めた」
「当然わかっている」
「最新版はv3」

と思っていても、AIがその情報へアクセスできるとは限りません。

人間はv3を知っている。 AIが読めるFolderにはv2しかない。

この場合、実行上の世界はv2です。

重要判断は、

人間の頭の中だけでなく、AIが読めるStateへ反映する

必要があります。

7. Stateを巨大Wikiにしない

Stateを外部化すると、今度は全部記録したくなります。

しかし巨大Stateは、

読み込みCostが増える
古い判断が残る
最新値が埋もれる
更新漏れが増える
AIが不要情報に引っ張られる

という問題を生みます。

StateはWikiではありません。

再開のための薄い地図です。

詳細LogやArchiveは別に持ちます。

8. Trigger――次の処理をどう始めるか

Agentは「次に何をするか」が決まっていても、実行開始のきっかけが必要です。

Trigger例：

人間が「次」と送る
Timer
Scheduler
Webhook
前Taskの完了
Queue追加
File作成
外部Event

ここで大事なのは、

Triggerが来たら、何を一件だけ始めるのか

が決まっていることです。

Triggerの役割と、AIの推論を混ぜすぎない方が安定します。

9. 同じTriggerが2回来たらどうするか

実務では二重Triggerが起こります。

Webhook再送
UI二重クリック
Scheduler重複
復旧後の再実行
Network Retry

そのとき、

同じ記事を2回公開する。同じメールを2回送る。同じFileを二重生成する。

では困ります。

そこでJob IDやTask IDを持ち、

このTaskは完了済みか
現在誰かが処理中か
再実行しても安全か

を確認できるようにします。

10. Recovery――壊れた後に戻れるか

Recoveryは、Agentが壊れたときだけ考える特別機能ではありません。

長時間作業では、普通に発生する運用の一部です。

たとえば、

開始
↓
State読込
↓
必須File確認
↓
欠損あり？
├─ No → 続行
└─ Yes → Checkpointから復元

を通常の開始手順へ入れます。

「止まらないAgent」を目指すより、

止まっても再開できるAgent

の方が管理しやすい場合があります。

11. Working Directoryを正本にしない

作業中Folderには、

一時File
未完成Artifact
旧版
Debug用File

が混ざります。

それをそのままSource of Truthにすると、Recovery時に誤認しやすくなります。

正本と作業領域を分けます。

canonical/
working/
checkpoints/
archive/

全部の案件でこの名前にする必要はありません。

現在有効なものと、作業途中を区別する

ことが重要です。

12. Checkpointは「保存しました」では足りない

CheckpointはBackupと少し違います。

意味は、

ここまでは確認済みなので、ここへ戻れば安全

です。

Checkpointには、

checkpoint_id
対象Artifact
Version / Hash
確認済み状態
作成時点
次Action

などを残します。

ただZIPを作っただけでなく、読み戻せることも確認します。

13. 「次、次、次」は必ずしも雑な運用ではない

単純な反復作業なら、人間が毎回長い指示を入力する必要はありません。

外部Stateが正しく、

現在地
次のTask
完了条件
保存先

が決まっているなら、

次

だけで動かすこともできます。

この場合「次」はTask内容を説明しているのではありません。

既に定義済みのState Machineを一Step進めるTrigger

です。

ここを作れているなら、短い指示でも安定します。