Prompt Engineeringの次はLoop Engineeringだった
ここ数日、Claude Codeを使って教育コンテンツを自動生成するLoopを設計している中で、一つの結論にたどり着きました。
これまで生成AIでは
- Prompt Engineering
- Context Engineering
が重要だと言われてきました。
もちろん今でも重要です。
しかし、AIエージェントを何度も作り直して分かったのは、
本当に難しいのは「AIに何を指示するか」ではなく、「AIをどう動かし続けるか」でした。
私はこれを Loop Engineering と呼んでいます。
Promptは点、Loopはシステム
最初は私も
PDF
↓
教材生成
だけで十分だと思っていました。
その後、
PDF
↓
Lesson AI
↓
Review AI
↓
Improve AI
↓
Quiz AI
↓
Video AI
という流れに進化しました。
しかし、これでも品質は安定しません。
「Judge AIを入れれば解決する」と思っていた
次に考えたのは
Lesson AI
↓
Judge AI
↓
Improve AI
↓
Judge AI
という構成です。
ところが実際に設計してみると、新しい問題が見えてきました。
まだ改善できます
↓
改善しました
↓
まだ改善できます
↓
改善しました
……
いつ終わるのでしょうか？
Loopは、放っておくと止まりません。
Stop ConditionがLoopの品質を決める
ここで初めて気付いたのは、
Promptよりも重要なのは
終了条件（Stop Condition）
だということでした。
例えば
- Retryは最大5回まで
- 品質スコア90点以上なら終了
- 改善率が2%未満なら終了
- APIコストが上限を超えたら終了
などです。
Loop Engineeringとは、
「AIを改善する仕組み」
ではなく、
「改善をどこで止めるかを設計する技術」
でもあります。
Judge AIも万能ではない
さらにもう一つ壁がありました。
Judge AI自身もLLMです。
つまり
昨日90点だった回答が
今日は85点になることがあります。
LLMだけに品質保証を任せるのは危険です。
そこで現在は、
LLMによる評価だけでなく、
- JSON Schema Validation
- 必須項目のチェック
- Markdown構造
- 文字数
- リンク切れ
- ファイル生成確認
など、
決定論的なチェックを組み合わせる構成を考えています。
LLM Judge
│
▼
Deterministic Validation
│
▼
Final Score
WorkflowではなくStateを設計する
最初は
Lesson
↓
Quiz
↓
Video
というWorkflowを書いていました。
しかし今考えているLoopでは、
Stateが中心になります。
例えば
{
"lesson": 3,
"retry_count": 2,
"quality_score": 84,
"failed_reason": [
"具体例不足"
]
}
このStateを見て、
次に
- Improveするのか
- Human Reviewへ送るのか
- 強制終了するのか
を判断します。
Workflowは「線」です。
Loopは「状態遷移を持つグラフ」です。
この違いは非常に大きいと感じています。
Claude Codeは最高の開発環境だった
Claude Codeのおかげで、
このLoopを驚くほど高速に試行錯誤できました。
一方で、
本番環境を考えると、
Claude Code自体がLoop Runtimeになるわけではありません。
将来的には、
- LangGraph
- Pythonによる独自Runtime
- State Machine
などへ移行していくことになるでしょう。
Claude Codeは、
Loopを発明するための最高の開発環境でした。
次に見えてきた課題はObservability
Loopを数回回すだけなら問題ありません。
しかし数百回、数千回と回すようになると、
別の問題が出てきます。
「今、どこで止まっているのか」
が分からなくなるのです。
そのため、
今後は
- Stateの可視化
- Retry履歴
- Token消費
- Judgeスコアの推移
- エラー理由
などを監視する
Observability（可観測性）
も重要になると考えています。
Loop Engineeringはソフトウェア工学だった
最初は
Prompt Engineeringの延長線上にあると思っていました。
しかし今は違います。
Loop Engineeringは、
Promptを書く技術ではありません。
State
Retry
Evaluation
Stop Condition
Observability
Human in the Loop
これらを設計する、
ソフトウェアアーキテクチャそのものだと思っています。
AIエージェントが当たり前になるこれからは、
Promptを書く能力より、
Loopを設計する能力の方が重要になるのかもしれません。
現在私は、
PDFをアップロードすると
- 教材
- クイズ
- 動画台本
- ワークシート
まで自動生成する教育向けLoop Runtimeを試作しています。
まだ試行錯誤の段階ですが、この過程で得られた知見を今後もQiitaで共有していきたいと思います。
皆さんは、AIエージェントの「終了条件」や「State管理」をどのように設計していますか？