第1章 なぜエージェントは「放置」できないのか

第1節 指示待ちで止まる構造的な理由

AI エージェントを一度でも自分で組んだことがある人なら、同じ壁に当たったはずだ。最初の 30 分は魔法のように動く。 タスクを渡せば調べ、書き、テストを通し、コミットまでしてくれる。ところが席を立って 2 時間後に戻ってくると、 画面は「次はどうしますか？」で止まっている。

これを「AI がまだ賢くないから」と説明するのは、原因の取り違えだ。止まっているのはモデルの能力ではなく、 そのエージェントを動かしている器の設計である。

会話セッションという器には、3 つの構造的な性質がある。

1. セッションは自分からは始まらない。 会話モデルは入力を受けて出力を返す関数であって、 時計を持っていない。誰かが「次」と打鍵しない限り、次のターンは永遠に来ない。エージェントが「放置できない」のは、 自律性が足りないからではなく、起動のトリガーを人間が握ったままだからだ。ここを外さない限り、 どれだけプロンプトを工夫しても人間の手が離れることはない。

2. セッションは状態を持てない。 正確に言えば、セッションは「そのセッションが続いている間だけ」 状態を持つ。コンテキストウィンドウが溢れれば古い話は落ち、プロセスが死ねば全部消える。昨日の自分が何に 3 時間 溶かしたか、どの方針を試して失敗したか、次の自分は一切知らない。結果として、放っておいたエージェントは 同じ調査を何度もやり直す。賢いのに前に進まない、という最悪の燃え方をする。

3. セッションは終わり方を選べない。 人間が Ctrl-C を押した瞬間、エージェントは 「作業の途中である」という事実すら残せずに消える。次に立ち上がったとき、そこにあるのは中途半端に 書き換えられたファイル群だけだ。何が終わっていて何が終わっていないかを、人間が読んで復元することになる。 これでは自動化の意味がない。

この 3 つを裏返すと、放置で回るエージェントの必要条件がそのまま出てくる。

重要なのは、この 3 つがどれもモデルの改善で解決しないことだ。次世代のモデルが出ても、 誰かが呼ばなければ動かないし、プロセスが死ねば記憶は消える。ここは器の側で解くしかない。だから本書は、 プロンプトの書き方の本ではなく、エージェントを常駐させる器の設計の本である。

第2節 自走させたときに実際に起きる 3 つの事故

「では定期起動すればいいのか」と考えて、cron で 10 分おきにエージェントを叩く構成を作った人は、 だいたい次の 3 つのどれかで痛い目を見る。筆者も全部踏んだ。

事故 1: 暴走 — できることを全部やってしまう

エージェントに広い権限と曖昧な目標を同時に渡すと、目標の達成に「役立ちそう」なことを片端から実行する。 設定ファイルを勝手に書き換える、関係ないリポジトリのテストを直しにいく、依存パッケージを最新に上げる。 個々の行動には一応の理屈があるのが厄介なところで、ログを読むと「まあ言いたいことは分かる」という行動が並ぶ。 だが総体としては、頼んでいない変更が広範囲に入った状態になる。

原因は権限の広さそのものではなく、やってはいけないことの定義が無いことだ。人間の新人なら 「これは勝手にやったらまずいだろう」と空気を読むが、エージェントは書いていないことを察してはくれない。 第4章で扱う「憲法」は、この空気を明文にする作業にあたる。

事故 2: 無限ループ — 前に進まないのに動き続ける

より静かで、より高くつくのがこれだ。エージェントは毎回律儀に起動し、律儀に調査し、律儀に 「次はこうすべき」と結論して終わる。翌日も同じ結論を出す。成果物が 1 バイトも増えないまま、 起動回数だけが積み上がる。

これは前節の「状態を持てない」が直接効いている。前回の自分が何をどこまでやったかを読まないので、 毎回ゼロから考え直す。しかも毎回それらしい計画を出すため、ログだけ見ていると順調に見える のが最悪の性質だ。この事故は、成果物のファイル数やバイト数といった外形的な指標を見ない限り検出できない。

事故 3: コスト超過 — 止める人がいない

暴走と無限ループのどちらも、金銭的には同じ結末に着く。API 課金は起動回数と入出力トークンに比例するので、 「動き続けているが前に進んでいない」状態はそのまま請求額になる。夜中に 6 時間回り続けて、朝に気づく。

ここで効いてくるのが、エージェント自身にはコストを止める動機が無いという事実だ。 1 tick の中で「もう少し調べた方が良い結果が出る」と判断するのは、そのタスクだけを見れば正しい。 予算という制約は、タスクの外側から与えるしかない。第5章で扱う。

3 つの事故に共通する構造

3 つとも、エージェントの中ではなく外側で解いていることに注目してほしい。 「もっと賢いプロンプトを書けば暴走しない」という方向は、筆者の経験では機能しない。賢いエージェントほど、 曖昧な指示から積極的な行動を導き出してしまうからだ。

第3節 本書が扱う範囲と扱わない範囲

期待値を先に揃えておきたい。買ってから「求めていたものと違った」となるのが、お互いにとって一番の損失だからだ。

扱うこと

常駐の器の設計。 短周期の見張り役と長周期の実行役に分ける二層構成、1 起動 = 1 タスクに絞る理由、 定期起動を選ぶ理由（第2章）。
記憶を持たない実行主体に状態を引き継がせる方法。 state ファイルの分割、スキーマ、起動時と終了時に 必ず行う手順（第3章）。
禁止事項をシステムプロンプトに置く設計。 破壊的コマンド、秘匿情報、外部送信、実費支出のガード （第4章）。
コストと時間の縛り方、および時間切れ時に状態を守って終了する設計（第5章）。
エージェントにできないことを人間に逃がす仕組み。 本人確認・決済・アカウント作成を代行させない ためのキュー設計（第6章）。
動いているかを 10 秒で判断する観測性。 heartbeat、ロックファイル、status コマンド、通知経路 （第7章）。
正直さを設計に組み込む方法。 実測値と推測を型で分ける、失敗を消さずに残す、成果ゼロを成果ゼロ として報告させる（第8章）。
上記をそのまま動かせるテンプレート一式（付録A〜D）。

扱わないこと

モデルの選び方やプロンプトエンジニアリングの技法。 本書の設計は特定のモデルに依存しない。 良い本は他にたくさんある。
特定の SaaS / フレームワークの使い方。 本書が前提にするのは「コマンドラインから叩ける AI エージェント」と「OS のスケジューラ」だけだ。
マルチエージェントの協調や役割分担。 1 体を確実に常駐させる話に絞る。1 体が安定しないうちに N 体に増やすのは、問題を N 倍にするだけだった。
「これで月◯円稼げる」という話。 本書の題材である money-engine は執筆時点で収益 0 円 である。本書が提供するのは収益の実績ではなく、実際に常駐して動いている仕組みの設計と実装そのものだ。 この点は隠さずに書いておく。

前提とする読者

コマンドラインで作業したことがあり、JSON と Markdown を読み書きでき、自分のマシンでスケジューラ （cron / タスクスケジューラ）を設定できる人。プログラミング言語の知識は必須ではない。本書のテンプレートは シェルスクリプトと設定ファイルが中心で、複雑なコードは出てこない。

次章から、実際に動いている構成を上から順に分解していく。まずは全体像として、 なぜ「見張り役」と「実行役」を分けるのかから始める。