自律型AIエージェント：数時間働かせても「ゴミ」を出さないための設計

自律型AIエージェントとは何か、通常の依頼とどう違うのか

通常のエージェントとの作業は段階的です。プロンプトを書き、エージェントが1ステップ実行し、結果を見て次を決めます。自律型AIエージェントはループで動きます。最終状態を一度記述すると、あとは「実行 → 検証 → 修正」を、ゴールに到達するか予算が尽きるまで自分で繰り返します。起動したら、その場を離れられます。

考え方は単純ですが、初めて試すと次のような失敗がよく起きます。朝にタスクを渡したのに、夕方になって、1時間前に自分で直したバグを何時間も直し続けていたと分かる。エージェントは、いつ止まりいつ人を呼ぶべきかを教えてもらっていなかったのです。以下では、そうした事態を防ぐループの設計を説明します。

ただし注意点があります。ループはハーネスの代わりにはなりません。ハーネスは1回の実行を確実にし、ループは実行を連続させます。質の悪いハーネスの上にループを載せても、ゴミがより速く生まれるだけです。

そのタスクは自律エージェント向きか

最初に確認すべきことは、作業に機械で確認できるゴールがあるかどうかです。「tests/payments 配下のテストがすべて通る」「リストの機能がすべて passing になる」「基準値に比べて指標が上がる」は向いています。「コードをもっと良くして」「決済を改善し続けて」は向いていません。そのようなゴールには終わりがなく、ループは予算を使い切るまで回り続けます。

ループには4つの種類があります。

• ステップ型：プロンプトを1つずつ入力する。通常の対話的な作業です。
• ゴール型：ゴールを与え、独立した検査か予算で止まる。数時間動く自律エージェントはこれにあたります。
• 時間型：スケジュールで起動する（例：朝にCIの失敗をまとめる）。停止は手動で行います。
• イベント型：外部のトリガー（新しいissue、失敗したデプロイ）で起動し、イベント処理の完了か再試行の上限で止まる。

よくある間違いは、時間型とゴール型を混同することです。「10分ごとに決済の作業を続けて」と指示すると、スケジュールされた実行は毎回ゼロから指示を読み、何が済んでいるかを知りません。終わりのあるタスクには、進捗の記憶を持つゴール型のループが必要です。

ステップ1：サンドボックス。エージェントが壊してよい場所を決める

無人のエージェントは、遅かれ早かれ何かを間違えます。ファイルを削除する、マイグレーションを書き換える、重いコマンドを実行する、などです。そこで問うべきは「間違えないようにするにはどうすればよいか」ではなく、「間違えても何も失わないようにするにはどうすればよいか」です。

• 独立した作業コピー。 git worktree を使うと、同じリポジトリの上にエージェント専用のディレクトリとブランチを作れます。メインのブランチには触れず、複数のエージェントが互いを邪魔せず、失敗した実行は1コマンドで削除できます。
• コンテナまたは仮想マシン。 エージェントにコマンドの完全な権限が必要なら、ホームディレクトリ、鍵、本番DBにアクセスできないコンテナで動かします。
• テスト用データ。 ローカルのDB、決済サービスのサンドボックス、ダミーのキー。エージェントの環境に本番のシークレットを一つも入れないでください。

# 自律実行専用のブランチとディレクトリ
git worktree add ../shop-agent -b agent/f03-refunds

# 実行後：結果を確認するか、捨てる
git -C ../shop-agent log --oneline main..
git worktree remove ../shop-agent

ステップ2：権限。タスクに必要な最小限だけ与える

エージェントが一人で長く動くほど、権限は狭くなければなりません。Claude Code では権限を settings.json で設定します（ツールとコマンドの allow と deny のリスト）。タスクに必要なもの（テストの実行、リンターの実行、作業コピー内のファイル編集）は明示的に許可し、危険なもの（メインブランチへの push、シークレットの扱い、不要なネットワークコマンド）は禁止します。

すべての確認を省略して実行するモードは、隔離されたサンドボックス内でのみ許容されます。その場合の最悪の結果は、捨ててしまえるコンテナだからです。鍵やリポジトリにアクセスできる普段の作業マシンでは、このモードを使ってはいけません。

絶対に破ってはならないルールは、テキストではなく仕組みで守ってください。指示文に「migrations/ に触れるな」と書くのは願望にすぎません。そのディレクトリへの編集をブロックするフック、またはファイルシステムの権限があって初めて保証になります。

ステップ3：目標・検証・停止条件。開始前に3行書く

動作する最小のループは3つの要素で成り立ちます。途中で考えるのではなく、開始前に書き出してください。

1. 目標：最終状態がどう見えるか。
2. 検証：目標に達したかを機械で確かめる方法。成功か失敗かを返すコマンド。
3. 停止条件：目標に届かなくても止まる、試行回数・時間・コストの上限。

これは方法論のファイルとして保管するとよいでしょう。そのファイルを編集するのは人だけにします。決済バックエンドの例は次のとおりです。

# program.md — 自律実行の方法論

## 目標
.agent/feature_list.json のすべての機能が passing になっている。

## 指標
passing の機能数。単調に増える。後退したら即ロールバック。

## 制約
- 同時に作業する機能は1つだけ。
- migrations/ と infra/ は変更しない。
- 依存関係の変更は記録してから行う。

## 作業順序
1. passing でない最初の機能を取る。
2. 実装し、pytest とリンターを実行する。
3. 緑なら、コミットして .agent/progress.md に記録。赤なら、修正する。

## 停止とエスカレーション
- 1つの機能で3回失敗したら blocked にして次へ進む。
- 残りがすべて blocked になったら、停止して報告書を書く。
- 顧客のお金、アクセス権、データ削除に関わるタスクは実行せず、人にエスカレーションする。

ステップ4：検証と修正のループ。ディスク上のメモリを使う

コンテキストウィンドウは長い作業を支えきれません。溢れて圧縮され、セッションは再起動されます。そのため進捗はエージェントの「頭の中」ではなく、ファイルに置かなければなりません。状態付きのタスク一覧、何をしたか・何が失敗したかのログ、git の履歴です。

良いモデルは、Andrej Karpathy が公開した autoresearch プロジェクトの「一方向にしか進まない歯車」です。このプロジェクトではエージェントが一晩で数百回の ML 実験を行います。各イテレーションでは、方法論を読み、仮説を立て、変更を加え、固定の時間予算で実験を走らせ、基準値と比較します。改善したらコミット、改善しなければロールバック。結果をログに書き、次の仮説に移ります。

この設計から取り入れるべき決定は2つです。

• 試行ごとに固定の予算。 試行が比べられるようになり、1つの失敗した仮説が一晩を食い尽くすことがなくなります。
• メインブランチには改善だけを入れる。 うまくいかなかった変更は、脇に残すのではなくロールバックします。git log が検証済みの作業ログになり、朝に読むだけで済みます。

同じ仕組みはファイルごとの役割分担も示しています。インフラと評価の仕組みは誰も変更しません。実験のコードはエージェントだけが変更します。方法論は人だけが変更します。こうすれば、エージェントが計測方法を書き換えて結果を「良く」することはできません。

ステップ5：完了を決めるのは誰か。独立した評価者

人がループに入っていないとき、エージェント自身の自己評価が唯一のブレーキになります。そしてそのブレーキは効きません。コードを書いたばかりのエージェントは、それを正しいと思いがちです。自分の推論を見ており、何をしたかったかを「知っている」からです。

生成役と評価役を分けるルールは次のとおりです。

• 作業をしたセッションは評価しない。Claude Code ではサブエージェントが向いています。それぞれが独自のコンテキストを持ちます。
• 評価者はクリーンなコンテキストを受け取る。要件、差分、テストの結果だけを渡し、実装者の推論は一切渡しません。
• 可能なら、評価者は別のモデルか、少なくとも別の役割のプロンプトにします。
• 判定はルーブリックに基づき、各項目は証拠（テストの行、コマンドの出力、差分の位置）を示す。

それでも機械による検査が第一です。評価者が必要になるのは、テストでは捕まえられないもの、たとえば要件の解釈違い、テストが実装に合わせて書き換えられていること、変更がタスクの範囲を超えていることなどです。

停止条件：エージェントはいつ諦めるべきか

停止条件のないループは、いずれ空回りします。最低限、次のセットを用意してください。

進捗は試行の回数ではなく中身で確かめてください。「40回イテレーションした」は何も意味しません。「緑の機能が5から9に増えた」は意味があります。タスクが詰まっているなら、もう一度ループを回すのではなく、人に渡すべき合図です。

自律エージェントの、すぐには見えないリスク

削除されたファイルや壊れたビルドといった明白なリスクは、サンドボックスと権限で防げます。より危険なのは、数週間かけて静かに積み重なるコストです。

• 検証の負債。「機械で確認済み」ではなく「大丈夫そうに見える」で進んでしまうこと。対策は、例外なく機械で検証できる停止条件だけを使うことです。
• 理解の低下。自分のコードを理解できなくなっていくこと。対策は、差分を必ず読むことです。ループの速度が、あなたが読む速度を超えてはいけません。
• 認知的な降伏。結果について意見を持たず、何でも受け入れてしまうこと。「あとで見る」と言って見なかった回数を正直に数えておくと有効です。
• コンテキストの肥大化。長い実行は履歴を蓄積し、ステップごとにコストが上がり、精度が落ちます。コンテキストの圧縮と外部メモリは、最初のループから用意してください。問題が起きてからでは遅いのです。

最初の自律ループを一晩で動かす方法

「エージェントが自分でタスクを見つけて片付ける」から始めないでください。自律性は段階を踏んで高めます。最初は、目標と停止条件を持つ1つのタスク。次に、スケジュールによる1つの自動化。その次に、隔離された作業コピーの中で実行役と検証役を分けること。そして最後に、自分で仕事を見つけて並列に動くループです。

1. 週に2回以上手作業でやっていて、検証可能な終わりがあるタスクを1つ選ぶ。
2. 目標、検証、停止条件を3行で書く。
3. 専用の worktree を作り、権限を設定する。テストと編集は許可、push とシークレットは禁止。
4. 進捗ファイルを作り、毎イテレーションで更新するようエージェントに指示する。
5. 役割を分ける。実装者が書き、検証者が別のコンテキストで差分を評価する。
6. 全体の上限を設定し、最初の結果は朝ではなく1時間後に確認する。

まとめ

自律型AIエージェントは、その枠組みの信頼性がそのまま信頼性になります。失敗しても何も失わないサンドボックス、最小限の権限、機械で検証できる目標、ディスク上のメモリ、独立した評価者、そして人へのエスカレーションを伴う厳格な停止条件。これらがなければ、長時間の実行は時間の節約ではなく、後で片付けるべき混乱を先送りしているだけです。このようなループを、設計図となる program.md から独立した評価者まで、通しのプロジェクトで実際に組み立てる方法は、ハーネスエンジニアリングのコースで実践的に扱っています。