ループエンジニアリングで自己改善型 AI エージェントを構築する方法

ループエンジニアリング：自己改善型 AI エージェントを構築する方法

ほとんどの AI エージェントが失敗するのは、モデルが弱いからではない。

モデルを取り巻くシステムが弱いからだ。

プロンプトがあいまい。

ツール呼び出しが失敗する。

エージェントが間違ったことを再試行する。

2 ステップ前に学んだことを忘れる。

同じ悪い行動を繰り返す。

成功を早々に宣言する。

そして、そのミスを捉えるはずのフィードバックループが誰も構築していない。

それが本当の問題だ。

時間とともに実際に改善される AI エージェントを構築したいなら、より良いプロンプト、より多くのツール、またはより多くの自律性以上のものが必要だ。

ループエンジニアリング が必要だ。

ループエンジニアリングとは、エージェントが以下のことを行う方法を設計する学問である：

• 何が起こったかを観察する
• それが機能したかどうかを評価する
• 次の行動を更新する
• 有用なフィードバックを保存する
• インテリジェントに再試行またはエスカレーションする
• 忙しくなるだけでなく、より良くなる

そのシフトが重要だ。

なぜなら、次世代の有用な AI エージェントは、1 回のデモ実行でどれだけ印象的に見えるかで定義されるわけではないからだ。

それらは、以下のことができるかどうかで定義される：

• ミスから回復する
• 繰り返される失敗から学ぶ
• 人間が毎回監視しなくても品質を向上させる
• 本番環境で制限され、測定可能で、信頼性を保つ

それがこの記事のテーマだ。

このような実用的な AI システムをもっと知りたいですか？ ByteBuilders では、Claude、AI ワークフロー、プロンプト、自動化、実世界のエンジニアリングシステムに関する短くて役立つ解説を共有しています。

こちらから購読：

https://bytebuilders.beehiiv.com/subscribe

ループエンジニアリングを理解すれば、すべてがうまくいったときだけ機能する脆弱なエージェントの構築をやめることができる。

学習するように設計されているから改善されるシステムの構築を始めることができる。

まず、「自己改善」が実際に意味するもの

多くの人が「自己改善エージェント」と聞くと、魔法のように自分自身を再トレーニングしたり、自律的で神秘的なものに進化するシステムを想像する。

それは有用な定義ではない。

自己改善エージェントは通常、はるかにシンプルだ。

それは、以前の試行からのシグナルを使用して、次の試行でより良い決定を下すことができるエージェントだ。

それは以下の方法で実現できる：

• より良いコンテキストでの再試行
• 評価に基づく修正
• 以前の失敗の記憶
• ツール使用の修正
• 出力スコアリング
• 人間のフィードバックループ
• ルールの更新
• 保存された成功パターン

言い換えれば：

自己改善は通常、モデルの進化ではない。それはループの進化だ。

ベースモデルは同じままかもしれない。

改善されるのは、モデルを取り巻くシステムの振る舞いだ。

それははるかに実用的でエンジニアリングに適したフレームワークだ。

ほとんどのエージェントが自分自身で改善しない理由

驚くべき数のエージェントが、実際には改善するように設計されていない。

それらは 継続する ように設計されている。

それは同じことではない。

今日の多くのエージェントシステムは基本的に以下の通りだ：

1. タスクを読む
2. 考える
3. ツールを呼び出す
4. 停止されるまで継続する

問題は、この構造には以下のものが欠けていることが多いことだ：

• 明確な成功基準
• 失敗の分類
• 状態を認識した再試行
• すでに失敗したものの記憶
• 試行間の比較
• 出力評価
• エスカレーションルール

そのため、エージェントは改善しない。

ただループするだけだ。

それが、生の反復とインテリジェントな反復の違いだ。

ループエンジニアリングがその違いを生み出す。

ループエンジニアリングが本当のアーキテクチャ層である

ループエンジニアリングを理解する最も簡単な方法はこれだ：

プロンプティングはモデルに何をすべきかを伝える。

ループエンジニアリングは、試行後にシステムがどのように振る舞うべきかを伝える。

それには以下のような質問が含まれる：

• ツール呼び出しが失敗した後、エージェントは何をすべきか？
• いつ再試行すべきか、いつ戦略を切り替えるべきか？
• 何回の試行が許可されるか？
• メモリに何を保存すべきか？
• 何を自動的に評価すべきか？
• いつ人間が引き継ぐべきか？
• 何が改善とみなされるか？

これが、ループエンジニアリングがプロンプトの会話だけでなく、アーキテクチャの会話に属する理由だ。

自己改善エージェントの背後にあるコアループ

ほとんどの有用な自己改善エージェントは、次のような繰り返し構造に従う：

1目標
2  ↓
3計画
4  ↓
5行動
6  ↓
7結果を観察
8  ↓
9品質を評価
10  ↓
11シグナルを保存
12  ↓
13再試行 / 修正 / エスカレーション / 完了

それが基礎だ。

ループを通過するたびに次の決定が有用な方法で変化するときに、システムは改善される。

すべてのエージェントに複雑なバージョンが必要なわけではない。

しかし、すべての信頼できるエージェントには、この何らかのバージョンが必要だ。

ナイーブなエージェントとループエンジニアリングされたエージェントの違い

これがシフトだ。

ループエンジニアリングされたエージェントは、モデルレベルで必ずしも「より賢い」わけではない。

それは単により良いシステムの内部で動作しているだけだ。

自己改善エージェントの 5 つの構成要素

エージェントを改善したいなら、構造のあるループが必要だ。

これらの 5 つの構成要素が最も重要だ。

1. 明確な成功基準

システムが「良い」とは何かを知らなければ、それに向かって改善することはできない。

成功基準には以下のようなものがある：

• 正確な出力形式
• 正確性のしきい値
• 根拠のある回答要件
• ツール完了シグナル
• テスト結果の合格
• 人間の承認
• タスク固有のスコア

これがなければ、エージェントは最適化するための安定したものを持てない。

1. 評価層

評価層は、エージェントにその試行が機能したかどうかを伝えるものだ。

これには以下のようなものがある：

• ルールベースのチェック
• スキーマ検証
• ユニットテスト
• LLM-as-judge スコアリング
• 検索根拠チェック
• ビジネスロジック検証
• 人間によるレビュー

これが「回答を生成した」と「有用な回答を生成した」の違いだ。

1. フィードバックメモリ

自己改善にはメモリが必要だが、単なる生の履歴ではない。

エージェントには 使用可能なメモリ が必要だ。

良いフィードバックメモリには以下のようなものが含まれる：

• 最後の失敗理由
• 以前のツールエラー
• 最もよく知られている成功パス
• 避けるべき既知の悪い戦略
• ユーザーの好みや修正
• 以前の試行の圧縮された要約

すべてのコンテキストが永続化されるべきではない。

次の決定に役立つコンテキストだけが永続化されるべきだ。

1. 戦略修正

評価後、エージェントは何を変更するかを決定しなければならない。

それには以下のようなものが含まれる：

• 新しいツールを試す
• タスクを絞り込む
• 明確化の質問をする
• より多くの情報を取得する
• 行動から説明に切り替える
• 人間にエスカレーションする

ここでシステムは実際に適応的になる。

1. 境界と停止条件

自己改善エージェントにも制御が必要だ。

そうしないと、改善は得られない。

カオスが得られる。

以下の制限を設定する：

• 再試行
• コスト
• レイテンシ
• 破壊的なアクション
• 人間の承認しきい値
• タスク放棄ルール

制限されたループは、制約のないループよりも価値がある。

ループエンジニアリングが実際にどのように見えるか

以下は、多くのエージェントでうまく機能するシンプルなパターンだ。

ループ 1：試行

エージェントは現在のコンテキストでタスクを試行する。

ループ 2：評価

チェックが実行される。

例：

• スキーマは検証されたか？
• コードはテストに合格したか？
• 回答は必要なソースを引用したか？
• ツールは正しいフィールドを返したか？

ループ 3：診断

失敗した場合、その理由を分類する。

例：

• コンテキスト不足
• 悪いツール引数
• 検索失敗
• 幻覚による仮定
• 不完全な出力
• ポリシー競合

ループ 4：適応

次の試行を変更する。

例：

• より多くのコンテキストを取得する
• タスクをより狭く書き直す
• 別のツールを試す
• 検証ルールを追加する
• 不足している詳細をユーザーに尋ねる

ループ 5：有用なシグナルを保存する

将来の実行に役立つものだけを保存する。

そして繰り返す。

それが運用上の用語でのループエンジニアリングだ。

ループエンジニアリングされたエージェントのための実用的な図

1ユーザーの目標
2   ↓
3タスクインタプリタ
4   ↓
5プランナー
6   ↓
7ツール / アクション層
8   ↓
9結果
10   ↓
11評価者
12   ├── 合格 → 完了
13   ├── 失敗：コンテキスト不足 → さらに取得
14   ├── 失敗：悪いツール使用 → アクションを修正
15   ├── 失敗：低信頼度 → エスカレーション
16   └── 失敗：回復可能 → メモリで再試行

ここでエージェントの品質が偶然ではなく体系的になる。

自己改善シグナルはどこから来るべきか

これは最も重要な設計上の質問の 1 つだ。

間違ったシグナルをループにフィードすると、エージェントは間違った方向に最適化する可能性がある。

改善シグナルの強力なソースには以下のものがある：

決定論的シグナル

• テストの合格または不合格
• スキーマの検証成功または失敗
• API ステータスが成功またはエラー
• 出力に必要なフィールドが含まれているかどうか
• ポリシールールが満たされているか違反されているか

ワークフローシグナル

• 再試行回数
• ツールレイテンシ
• 失敗が発生したステップ
• 信頼度しきい値を超えた
• エスカレーション頻度

人間のシグナル

• いいね / よくないね
• 修正された出力
• 受け入れられたドラフトと拒否されたドラフト
• 手動オーバーライドパターン
• レビュアーノート

比較シグナル

• バージョン A とバージョン B の出力品質
• 検索バリアント比較
• ツールパス比較
• 繰り返し実行でのスコア改善

最良の自己改善エージェントは通常、これらのカテゴリの少なくとも 2 つを組み合わせる。

最良のループは応答だけでなくワークフローを改善する

ここで設計がより成熟する。

弱い実装は、テキストを再生成するためだけにループを使用する。

より強い実装は、ワークフロー全体を改善するためにループを使用する。

つまり、エージェントは以下を変更することで改善できる：

• 何を取得するか
• どのツールを使用するか
• ステップの順序
• 何を記憶するか
• 何を無視するか
• より早く明確化を求めるかどうか
• より早く停止するかどうか

これは「回答を再度書き直す」よりもはるかに強力だ。

システムはプロセスレベルで自己修正するようになる。

自己改善をサポートするプロンプトパターン

プロンプティングは依然として重要だ。

ただ、ループをサポートする必要がある。

以下は有用なプロンプトパターンだ。

プロンプト 1：評価認識型アクションプロンプト

1あなたは制限されたワークフロー内でタスクを実行しています。
2あなたの目標は単に回答を生成することではなく、評価に合格する回答を生成することです。
3情報が不足している場合は、それを要求するか取得してください。
4結果が不確かな場合は、自信を持って完了しないでください。
5以前の試行が失敗した場合、コンテキストが変わらない限り、同じ戦略を繰り返さないでください。

プロンプト 2：失敗診断プロンプト

1以前の試行が失敗しました。
2失敗の理由を以下のカテゴリのいずれかに分類してください：
3- コンテキスト不足
4- ツールの誤用
5- 悪い仮定
6- 不完全な出力
7- フォーマットまたはスキーマの失敗
8- ポリシー競合
9次に、成功の確率を改善する最小の次の変更を提案してください。

プロンプト 3：修正プロンプト

1以下の評価者のフィードバックを使用して、次の試行を修正してください。
2すでに失敗した同じ推論パスを繰り返さないでください。
3より狭く、より根拠のある解決策を優先してください。
4必要に応じて、回答する前にさらにコンテキストを取得してください。

プロンプト 4：メモリ要約プロンプト

1最後の試行を次の実行のための短いメモリブロックに要約してください。
2以下だけを含めてください：
3- 何が失敗したか
4- 何が機能したか
5- 何を避けるべきか
6- 次に何を試すべきか
7120 語以内に収めてください。

これらは魔法のプロンプトではない。

ループ動作を強化するように設計されたプロンプトだ。

シンプルな Python スタイルのループアーキテクチャ

以下は、ループエンジニアリングがコードでどのように見えるかの簡略化された例だ：

1MAX_ATTEMPTS = 4
2
3memory = []
4
5for attempt in range(MAX_ATTEMPTS):
6    context = build_context(task=task, memory=memory)
7    plan = agent.plan(context)
8    result = agent.act(plan)
9
10    evaluation = evaluator.check(task=task, result=result)
11
12    if evaluation.passed:
13        return {
14            "status": "success",
15            "result": result,
16            "attempt": attempt + 1,
17        }
18
19    failure_summary = agent.summarize_failure(
20        result=result,
21        evaluation=evaluation,
22    )
23
24    memory.append({
25        "attempt": attempt + 1,
26        "failure": failure_summary,
27        "suggested_fix": evaluation.next_step,
28    })
29
30    if evaluation.requires_human:
31        return {
32            "status": "escalated",
33            "reason": evaluation.reason,
34            "attempt": attempt + 1,
35            "memory": memory,
36        }
37
38return {
39    "status": "failed",
40    "reason": "max_attempts_reached",
41    "memory": memory,
42}

これは意図的にシンプルにしている。

重要なのはコード自体ではない。

構造だ：

• 試行
• 評価
• シグナルを保存
• 適応
• 再試行またはエスカレーション

それが内面化すべきパターンだ。

ループエンジニアリングが最も重要な場所

このアプローチは、最初のパスで成功が保証されていないワークフローで特に価値がある。

コーディングエージェント

ループに最適。システムは以下ができる：

• テストを実行する
• 失敗を検査する
• コードを修正する
• 出力を比較する
• 検証に合格したときにのみ停止する

サポートエージェント

有用。システムは以下ができる：

• ポリシーコンテキストを取得する
• 応答のドラフトを作成する
• 根拠をチェックする
• リスクが高い場合は承認を求める

リサーチエージェント

役立つ。システムは以下ができる：

• 複数のソースを収集する
• ギャップを特定する
• 再度検索する
• 証拠が十分な場合にのみ統合する

ドキュメント抽出エージェント

有用。システムは以下ができる：

• ファイルを解析する
• スキーマを検証する
• あいまいなフィールドを再試行する
• 低信頼度のケースをエスカレーションする

運用ワークフローエージェント

価値がある。システムは以下ができる：

• API を呼び出す
• 結果をチェックする
• 部分的な失敗から回復する
• 例外を人間にルーティングする

これらすべてのケースで、ループの品質は 1 回の生成品質よりも重要だ。

ループエンジニアリングのよくある間違い

間違い 1：再試行を改善とみなす

より多くの試行が自動的に学習の向上を意味するわけではない。

システムが同じ動作を繰り返す場合、それは改善ではない。

ただループしているだけだ。

間違い 2：メモリを保存しすぎる

すべての過去のコンテキストが役立つわけではない。

メモリが多すぎると、次の試行を汚染する可能性がある。

圧縮された、実行可能な教訓を保存する。生のトランスクリプトの山ではない。

間違い 3：評価をスキップする

チェックがなければ、エージェントは改善したかどうかを知ることができない。

これは最も一般的な構造上の失敗だ。

間違い 4：停止条件がない

制約のないエージェントは先進的ではない。

高コストだ。

間違い 5：人間のフィードバックを無視する

人間が同じことを修正し続け、ループがそのシグナルを決して使用しない場合、システムは実際には改善していない。

間違い 6：すべてのタスクに 1 つの巨大なループを使用する

異なるタスクには異なるループが必要だ。

サポートエージェントとコーディングエージェントは、同じ再試行ロジックや評価ルールを共有すべきではない。

私が推奨する実用的な構築順序

ゼロから構築する場合は、この順序を使用する。

ステップ 1：成功を明確に定義する

良い結果はどのように見えるか？

ステップ 2：失敗カテゴリを定義する

このエージェントは通常なぜ失敗するか？

ステップ 3：最初に評価者を構築する

システムはどのように成功または失敗を知るか？

ステップ 4：メモリルールを設計する

試行間で何を永続化すべきか？

ステップ 5：再試行戦略を定義する

試行 1 と試行 2 の間で何が変わるか？

ステップ 6：エスカレーションロジックを追加する

いつ人間が介入すべきか？

ステップ 7：重要なものをすべてログに記録する

観察しないものは改善できない。

ステップ 8：ループが機能した後にのみ最適化する

コアサイクルが安定する前にシステムを複雑にしすぎない。

この順序により、チームは誇大広告ではなく動作に集中できる。

エージェントを「自己改善」と呼ぶ前のシンプルなチェックリスト

これを現実チェックとして使用する。

• エージェントは成功がどのように見えるかを知っているか？
• 各試行を評価するか？
• 失敗から有用な教訓を保存するか？
• フィードバックに基づいて戦略を変更するか？
• 同じ失敗したパスを盲目的に繰り返すことを避けるか？
• いつ停止するかを知っているか？
• いつ人間にエスカレーションするかを知っているか？
• 実際に改善しているかどうかを測定できるか？

これらのほとんどが欠けている場合、システムはおそらく自己改善ではない。

それは単なる反復的だ。

最後に

AI エージェントの未来は、より良いプロンプト、より多くのツール、またはより長いチェーンだけではない。

それはより良いループだ。

それがループエンジニアリングが可能にするものだ。

エージェントを 1 回限りのジェネレーターから、以下のことができるシステムに変える：

• 観察する
• 評価する
• 適応する
• 記憶する
• インテリジェントに再試行する
• 実際の条件下で改善する

それが本番 AI における自己改善の実際の姿だ。

神秘ではない。

魔法ではない。

ただのより良いシステム設計だ。

より強力なエージェントが必要なら、どのように行動させるかだけでなく、次に何が起こったかから学習させる方法 を問うこと。

そこに本当のレバレッジがある。