AIエージェントを信頼できるものにする方法：測定から自律作業までの段階的な計画

強力なモデルでも、エージェントが不安定な理由

エージェントの信頼性は、モデルだけでなくシステム全体の性質です。長いタスクは数十のステップからなり、エラーは積み重なります。各ステップの正答率が95%なら、10ステップを一度もエラーなしで通過するのは約60%の実行にとどまります（0.95^10 ≈ 0.60）。50ステップでは10%未満です。モデルの正答率を直接上げることはできませんが、エラーが起きた場所で捕まえ、その修正コストを小さくすることはできます。これがハーネスの仕事です。指示、ツール、環境、状態、フィードバックをモデルの周りに組み立てます。

以下の計画は、「なんとなく」の評価から、測定可能な信頼性、そして自律作業へと進みます。ステップは効果の大きい順に並んでおり、各ステップは前のステップの上に成り立っています。

ステップ1：感覚で評価するのをやめる

ある技術者は新しいプロンプトで何もかも変わったと確信し、別の技術者は違いが分からず、誰も指標を取っていません。まず失敗ログから始めましょう。エージェントが止まった、何かを壊した、動かない機能を報告した、そのたびに一行記録します。

| 日付  | タスク           | 何が起きたか                   | サブシステム   |
|-------|------------------|--------------------------------|----------------|
| 10/10 | カートの割引     | 「完了」と報告、e2eは未実行    | フィードバック |
| 10/10 | 決済webhook      | DBを起動できなかった           | 環境           |
| 11/11 | API のリファクタ | 却下済みの方法を繰り返した     | 状態           |

「サブシステム」の列が最も重要です。一週間もすれば、ボトルネックがどこにあるかが見えてきます。そこだけを直せばよく、全部を直す必要はありません。成功した実行の回数だけで信頼性を測るのは誤りです。エージェントがどこで転ぶかを示すのは、失敗ログのほうです。

ステップ2：MTBFとMTTRの二つの指標を導入する

信頼性は二つの数字で表せます。MTBF（平均故障間隔）は、エージェントが詰まるまでに何ステップ進めるかです。MTTR（平均修復時間）は、障害の後に作業可能な状態へ戻るまでの時間です。可用性は、前者が伸び、後者が縮むほど高くなります。

決してミスをしないエージェントを追い求めるのは、終わりのない競争です。MTTRを縮めるのは一日でできることが多いので、まず二つ目の数字から始めてください。

ステップ3：エラーを安くする

エージェントを自律的に働かせられるのは、もうミスをしなくなったからではなく、ミスのコストがほぼゼロまで下がったからです。そのために必要なものは三つです。

• 小さく、きれいなコミット——どんな変更も一つのコマンドで戻せること。
• 隔離——エージェントは専用のブランチや作業コピーで、例えば git worktree を使って作業し、本番にアクセスできないサンドボックスで動かします。
• 環境リセットのスクリプト——データベース、依存関係、サービスを一つのコマンドで初期状態に戻せること。

git worktree add ../shop-agent -b agent/discount
cd ../shop-agent
make reset   # DBを作り直し、マイグレーションを適用し、フィクスチャを読み込む

作業可能な状態へ完全に戻すのにかかる時間をストップウォッチで測ってください。それがあなたのMTTRです。同時に影響範囲も制限します。一つのタスクで変更できる差分の行数に上限を設け、タスクの範囲外のファイルの変更を禁止します。

ステップ4：フィードバックのループを閉じる

検査がなければ、エージェントは自分一人が裁判官となり、作業が終わったと誠実に信じ込みます。自己確認に使えるコマンドを与え、それを必須にしてください。

• fail-fast：検査は最初のエラーで止まり、100行のノイズではなく分かりやすいメッセージを出します。
• 編集のたびの高速な検査：エージェントのフックを通じて、リンターと型チェックを走らせます。
• 冗長性：同じ性質を独立した二つ目の検査でも確認します。例えば単体テストの上にE2Eシナリオを置きます。単体テストが通っても、ユーザーの環境で機能が動くことは証明されません。

「完了」の基準は検証可能な条件として書いてください。「実装済み」ではなく、「クーポン付き注文のE2Eシナリオが通る」とします。

ステップ5：記憶をファイルに移す

エージェントは前回のセッションを覚えていません。作業を続けるために必要なものはすべてリポジトリに存在しなければなりません。目標、完了した作業とその検証方法、理由付きの決定、行き詰まり、次のステップです。良いサインは、新しいセッションがリポジトリと「続けて」という一言だけを受け取って、すぐに有益な作業を始めることです。

圧縮された長い会話履歴は連続性の感覚を与えますが、最も大切なもの、つまり却下された方法の理由を失ってしまいます。書面の状態を完全に残してセッションを意図的に終えるほうが、たいてい安上がりです。

ステップ6：一度に一つのタスク

リトルの法則によると、システム内のタスク数は、到着率に各タスクの滞在時間を掛けたものに等しくなります。処理能力が一定なら、並行して進めても作業は速くなりません。各タスクが長引くだけです。エージェントにとってはさらに顕著です。三つの機能を同時に扱うことは、同じコンテキストウィンドウに三つのドメインモデルを詰め込むことを意味します。

• WIP（仕掛品）は1に保つ。一つの機能を検証済みの結果まで仕上げてから次に進みます。
• タスクを小さく切る。検証可能なユーザーの機能一つ、1〜3ファイル、検証は一分以内が目安です。
• 「ついでに」の受け皿として BACKLOG.md を作る。隣接する欠陥に気づいたら、勝手に直さず、バックログに一行書きます。

ステップ7：実行者と検査者を分ける

エージェントの自己評価は弱いブレーキです。コードを書いたのと同じセッションは、そのコードが正しいと考えがちです。結果の評価は、別のサブエージェントまたは別のセッションに任せてください。そのセッションが受け取るのは、要件、差分、検査結果だけで、実行者の推論は見えません。検査者の結論は、「見た目は問題ない」ではなく、機械的な検査に基づくべきです。

ステップ8：エージェントを自律ループに送り出す

ハーネスが単一の実行を信頼できるものにし、ループが一連の実行を自律的なものにします。悪いハーネスの上でループを回すと、エラーがより速く増えるだけです。だからこのステップは最後です。最も単純なループは三行で書けます。

目標：    クーポン付き決済のE2Eシナリオが通る
検証：    make lint && make test && make e2e
停止：    目標達成 または 15回の試行 または 2時間 → 人を呼ぶ

タスクに応じてループの種類を選びます。作業に明確なゴールがあるなら、目標に基づくループが必要です。進捗の記憶、独立した検査者、ステップ数の予算を持たせます。ゴールがない作業（毎朝のCI確認、新しいエラーの整理など）には、スケジュールに基づくループが向いています。よくある間違いは、ゴールのあるタスクをスケジュールで回すことです。毎回ゼロから始まってしまいます。

安全な自律のルール

• 停止条件は機械的に検証できるものだけにし、試行回数と予算の上限も設ける。
• ループに任せてはいけないことを事前に列挙する。本番環境のマイグレーション、お金、データの削除など。
• タスクが停滞し、検査の結果が実質的に進まないなら、それは人に引き継ぐべきサインです。延々と回し続けてはいけません。
• 差分は必ず読む。ループの速度があなたの読むスピードを超えてはいけません。さもないと、自分のコードベースが理解できなくなります。

この道で起こりがちな間違い

最初に指示を書き直す

エージェントの失敗に対する最も一般的な反応は、AGENTS.md にルールを一つ追加することです。数か月もすればファイルは数百行に膨らみ、重要なルールが埋もれます。失敗ログから、エージェントが検査を実行していなかったと分かったなら、直すべきはフィードバックです。検証コマンドとフックを用意してください。段落を一つ追加するのではありません。

すべてを一度に直そうとする

五つのサブシステムを同時に改善したくなります。しかしそうすると、何が効いたのかが分からなくなります。各サブシステムを1〜5点で採点し、最も弱いものに30分かけ、同じ五つの典型的なタスクを修正の前後で実行してください。失敗ログの差が、効果があったかどうかを示します。

「テストが通る」を「機能が動く」と混同する

エージェントは、要件ではなく自分の実装を検査するテストを書くことがあります。そのテストは常に緑です。防ぐ方法は、ユーザーの視点で検証すること（E2Eシナリオ）です。実装より前に書くか、独立した検査者が書きます。そして、エージェントがテストを通すためにテストを書き換えてはいけない、というルールを定めます。

速度のために検査を切る

遅い検査は「今回だけ」と飛ばしたくなる誘惑を生みます。より良いのは分けることです。速いリンターと型チェックは編集のたびに、テスト全体とE2Eは「完了」と言う前に実行します。こうすればフィードバックループは短いままで、作業を妨げません。

アブレーションを最初のステップにする

ハーネスのサブシステムを一つずつ切って、品質がどれだけ落ちるかを見ることもできます。有用な確認ですが、コストが高く、最初にやることではありません。まず失敗ログでボトルネックを見つけ、アブレーションは仮説を確かめるために使います。コンポーネントを外しても何も変わらないなら、不要と断定してはいけません。選んだタスクがたまたまそれを使わなかっただけかもしれません。

成熟度のはしご

まとめ

AIエージェントを信頼できるものにするには、測定し、失敗ログから弱いサブシステムを見つけ、エラーを安くし、フィードバックのループを閉じ、記憶をファイルに移し、一度に一つのタスクに集中し、実行者と検査者を分けます。そのあとで初めて、機械的に検証できる停止条件を持つ自律ループが安全になります。この計画の各ステップは、ハーネスエンジニアリングの講座で実際のプロジェクトを通して解説しています。