第1章 なぜ同じ失敗を繰り返すのか

第1節 tick ごとに記憶を失うエージェントの宿命

このエージェントを動かしている仕組みの中核には、次の一文がある。

あなたは 60 分ごとに 1 回起動され、1 つのタスクを実行して終了します。記憶は引き継がれません。状態はすべてファイルに書いてください。書かなかったことは次回のあなたには存在しません。

これは比喩でも脅し文句でもなく、実際にこのエージェントが従っているシステムプロンプトの一文そのものである。60 分に 1 回、まっさらなプロセスが立ち上がり、1 つのタスクをこなし、そして消える。次の 60 分後に立ち上がるのは「続きをやる自分」ではなく、「同じ名前を名乗る、記憶のない別のプロセス」である。

この宿命を「まだ技術が未熟だから仕方ない」と捉えるのは、原因の取り違えである。セッションが記憶を持たないのは欠陥ではなく設計であり、次のモデルが賢くなっても解消しない類の制約だ。会話モデルは、そのセッションに渡されたコンテキストの範囲でしか判断材料を持てない。プロセスが終了すれば、そのコンテキストは跡形もなく消える。次に起動したプロセスは、良くも悪くも白紙の状態から始まる。

問題は、この宿命が単に「不便だ」で済まないところにある。記憶がゼロから始まるということは、前回の自分が何を調べ、何を試し、何がうまくいかなかったかを、次の自分がまったく知らないということだ。人間のチームで新人が毎回総入れ替えになり、しかも引き継ぎ資料が一切無い状態を想像してほしい。新人は毎回同じ資料を読み、同じ仮説を立て、同じ調査をやり直す。運が悪ければ、前任者が「これは効果がなかった」と結論づけた打ち手を、知らないまま再び選んでしまう。

これが「同じ失敗を繰り返す」という現象の正体である。エージェントの判断力が低いからではない。前回の判断結果にアクセスする手段が無いから、毎回ゼロから同じ賢さで同じ道を選び直してしまうのだ。賢さが同じでも、材料が無ければ結論は同じところに収束する。

この宿命そのものを消すことはできない。60 分ごとに記憶を失うという制約は、このエージェントを動かす仕組みの土台であり、本書の対象でもそこを覆す方法を提供するものでもない。できるのは、記憶が消える前に 次の自分が読める形で、状態を外部のファイルに書き残しておくこと だけだ。冒頭に引いた一文が「状態はすべてファイルに書いてください」で終わっているのは、この一点に尽きる。書いたことだけが次回に存在し、書かなかったことは無かったことになる。

では、書きさえすれば問題は解決するのか。次節では、この「書く」という行為だけでは実は不十分であるという、もう一段深い落とし穴を見ていく。

第2節 ふり返りを書くだけでは学習にならない理由

「毎回ファイルに書き残す」という発想自体は、それほど特別なものではない。日報を書く、作業ログを残す、issue にコメントを追記する——多くの現場で当たり前に行われている習慣だ。この money-engine でも、1 tick が終わるたびに、その tick で何を試し、何が起きたかを 1 レコードとして state/reflections.jsonl というファイルに追記する仕組みが動いている。

このファイルの 1 行（1 レコード）は、自由な感想文ではなく、決まった型で書かれる。実際のレコードを 1 つ見てみよう（数値や固有名は実例そのもの、文章はそのまま引用している）。

{
  "task_id": "T59",
  "title": "tokushoho.htmlの記載がproduct-2.html(¥1,480)とも矛盾しないか検証する",
  "status": "completed",
  "hypothesis": "tokushoho.htmlはproduct-1のみが存在した時点で自動生成された可能性があり、その後追加されたproduct-2(価格が異なる)の情報が反映されていないと、特定商取引法に基づく表記として不正確なまま公開され続けているリスクがある。",
  "outcome": "tokushoho.htmlの「販売価格」欄はどの商品の価格にも依存しない文言になっていることを確認し、矛盾なしと判定した。",
  "hypothesis_verdict": "refuted",
  "root_cause": "エンジン本体が生成するページは商品固有の価格を書き込む固定形式ではなく、商品ページへの参照文言で価格変動に対応する設計だったため、複数商品追加による矛盾リスクは最初から発生しない構造だった。",
  "lesson": "法的ページが『各商品ページを参照する』形式か『固定値を埋め込む』形式かを先に一度確認しておけば、新商品追加ごとに同種の矛盾懸念を毎回検証する必要はない。",
  "next_action": "human-queueの完了状況を確認し、全て未完了なら次の制作・検証タスクに進む。"
}

見てのとおり、1 レコードは hypothesis（何を確かめようとしたか）、outcome（実際に何が起きたか）、hypothesis_verdict（仮説は当たったか外れたか、あるいは判定不能か）、root_cause（なぜその結果になったのか）、lesson（次に活かせる教訓）、next_action（次の tick が具体的に何から始めるべきか）という、性質の異なるフィールドに分かれている。ここには ts（時刻）、title、status、cost_usd も含めて 11 個のフィールドがあり、それぞれ書く内容の役割が固定されている。

なぜここまで型を固定するのか。答えは、型を固定しない自由記述のログだと、書いた本人にしか読めない文章になりやすいからだ。「うまくいった」「思ったより難しかった」といった感想は、書いた瞬間の自分には意味が通るが、記憶を持たない次の自分がそれだけを読んでも、何を根拠に何を判断すればいいのか分からない。型に分けて書くことで初めて、次の自分は next_action だけを拾い読みして tick を始められるし、hypothesis_verdict を横串で見れば「これまで確認できた仮説」と「まだ判定できていない仮説」を機械的に区別できる。

ただし、ここで見落としてはいけない事実がある。型を決めて書くことと、それが次の判断に活きることは、また別の話だ。 reflections.jsonl は 1 tick ごとに 1 レコードずつ、単純に末尾へ追記されていくファイルである。tick を重ねるほど行数は増え続け、数十行、数百行になっていく。次の tick のエージェントは、記憶が無い以上、判断材料が欲しければこのファイルを読むしかない。だが数百行に膨れ上がったログを、60 分の持ち時間の中で全部読み返し、そこから今の状況に関係のある教訓だけを拾い出す、というのは現実的ではない。生のログは増えるほど、かえって「読み切れないから読まれない」という状態に近づいていく。これは第2章・第2節で見た CLAUDE.md の事故（読まれない・矛盾する・膨張して埋もれる）と、根っこは同じ構造の問題である。

つまり、「書く」だけでは学習は起きない。 書いたものを、後から誰か（あるいは何か）が読み返し、束ね、要らなくなった詳細を削ぎ落として、次に効く形に整理し直す工程がなければ、ログはただ増え続けるだけの倉庫になる。本エンジンの憲法にも、次のような一文がある。

あなたは記憶を持ちませんが、ふり返り・定期まとめ・知恵袋・作戦が積み上がることで、回を重ねるほど判断が良くなるように作られています。

この一文が「ふり返り」の後に「定期まとめ」「知恵袋」「作戦」という 3 つの言葉を続けているのは偶然ではない。1 tick ごとの生のふり返り（reflections.jsonl）だけでは学習は完結せず、それを 6 時間、1 日、1 週間という単位で束ねて要約し（定期まとめ）、そこから繰り返し効く教訓だけを抽出し（知恵袋）、今どこに集中すべきかを決める（作戦）という、複数段の加工を経て初めて、次の tick の判断材料として機能する形になる。この段階を踏む設計が、本書の中心テーマである。

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

期待値を先にそろえておきたい。買ってから「思っていた内容と違った」となるのが、書き手にとっても読み手にとっても一番の損失だからだ。

扱うこと

• 1 tick ごとのふり返りを型で残す設計。 hypothesis / outcome / hypothesis_verdict / root_cause / lesson / next_action という各フィールドに何を書かせ、何を書かせないかという設計判断（第2章）。
• 生ログを階層的に束ねる設計。 6 時間 → 1 日 → 1 週間 → 1 ヶ月 → 3 ヶ月 → 半年という単位で、ひとつ下の単位のまとめを束ねて要約し直す入れ子構造と、多重実行を防ぐ実行タイミングの管理（第3章）。
• 知恵袋（playbook）の設計。 「効いたこと」「効かなかったこと」「次に試す仮説」「次に優先すべきこと」という区分と、根拠を必ず付けさせる運用、書き換え権限をエンジン本体だけに限定する理由（第4章）。
• 作戦（strategy）の設計。 今どこに集中するかを、判定指標つきで機械的に決めさせる仕組みと、成果が動かない打ち手から撤退する継続判定のルール（第5章）。
• 仮説検証ループの正直さを支える型。 hypothesis_verdict を「判定不能」のまま放置しない運用、実測値と推測を混同させない設計（第6章）。
• 自分のプロジェクトへの移植手順。 最小構成から始めて、階層まとめ・知恵袋・作戦を段階的に足していく順序と、移植時に陥りやすい失敗（第7章）。
• 上記をそのまま使える テンプレート一式（付録A〜C。reflections.jsonl のスキーマ定義、階層別まとめの雛形、詰まりどころの対処）。

扱わないこと

• モデル自体の学習やファインチューニングは対象外。 本書が扱う「学習」は、モデルの重みを更新することではない。モデルは 60 分ごとに毎回まっさらな状態で呼び出され、その中身は本書の範囲では一切変わらない。変わるのはモデルの外側にあるファイル——ふり返り・まとめ・知恵袋・作戦——の中身であり、次に呼び出されたときに同じモデルへ与えられる材料が変わることで、結果として判断が改善していく。この仕組みは money-engine の設計そのものが「株・投資のシステムには触らない」「money-engine のスコープ外」と同じ理屈で、モデルの学習という別領域には踏み込まない、というスコープの外側に置かれている。ファインチューニングや強化学習によってモデル自体を賢くする話をお探しの方には、本書は向かない。
• モデルの選び方やプロンプトエンジニアリングの技法。 本書の設計は特定のモデルの性能や言い回しの巧拙に依存しない。
• 「このループで◯円稼げた」という実績訴求。 本書の題材である money-engine は、本書の執筆時点で収益実績を誇れる段階にはない。本書が提供するのは収益の実績ではなく、実際に稼働の中で使われているふり返り・階層まとめ・知恵袋・作戦更新の設計と、それをそのまま動かせるテンプレートそのものである。この点は隠さずに書いておく。

前提とする読者

AI エージェントやスクリプトを定期的に自動実行させたことがあり、JSON と Markdown を読み書きでき、自分の運用に「同じ失敗を繰り返している」という実感がある人。特定のモデルやフレームワークの知識は前提にしない。本書のテンプレートはファイルのスキーマと運用手順が中心で、複雑なコードは出てこない。

次章では、この学習ループの最小単位である「1 tick ごとのふり返り」を、実際にどういうフィールド設計で、どう書かせるかという具体的な話に入っていく。