プロジェクト 07. 初めての自動ループを構築する

関連講義: 第13回なぜエージェントにプロンプトを与えるのをやめるべきか

このプロジェクトですること

これは「ハーネス」から「ループ」への移行プロジェクトです。適切な環境、指示、フィードバックを備えたエージェントのセットアップ方法は既に知っています——今度はそのセットアップを、自ら動き出すループに変えます。

3つの段階的な実験を行います：まずタスクを手動から /goal に変え、次に監視タスクを /loop タイマーに変え、最後に完全なmaker-checkerループを構築して、あなたがループの外側に出るとはどういうことかを体験します。

プロジェクトファイル

リポジトリパス: projects/project-07/

ディレクトリ	中身	あなたがすること
`starter/`	完全なハーネス（P06最終状態）を備えた小さなナレッジベースプロジェクト。AGENTS.md、feature_list.json、init.sh、session-handoff.md、clean-state-checklist.md を含む。	このハーネスを自動でループできるものに変える。
`solution/`	3つのループの完全な実装：ゴールループ、タイマーループ、maker-checkerループ。ループ状態ファイルと検証スクリプトも含む。	ループ設計パターンと状態管理のリファレンス。

使用するツール

Claude Code または Codex
Git
P06 の完全なハーネス
ターミナルマルチプレクサ（tmux または screen、長時間実行されるループを観察するため）
オプション：GitHub Actions または cron（高度なイベント駆動 / スケジュール実験用）

ステップ

準備

P06を終えたのと同じコミットから始めてください。
3つのブランチを作成してください：p07-goal-loop、p07-timer-loop、p07-maker-checker。
ハーネスが動作することを確認してください：init.shを実行し、状態ファイル、機能リスト、引き継ぎドキュメントがすべて揃っていることを確認します。
ループに繰り返し取り組ませたい対象タスクを一つ選んでください。完了基準が明確な中規模のものを選んでください——例：「すべてのモジュールに単体テストを追加してカバレッジ80%に達する」または「すべてのAPIエンドポイントに入力検証を追加する」。

実験1：ゴールループ — 手動実行から自動実行へ

p07-goal-loop ブランチに切り替えてください。

ゴールの説明を書く：選んだタスクを goal.md ファイルにしてください。含める内容：
- 明確なゴール（「何をもって完了とするか」）
- 検証方法（「どうやって完了を確認するか」——テストを実行する？lintを実行する？カバレッジをチェックする？）
- 停止条件（「いつ止めるべきか」——最大ターン数？時間制限？予算制限？）
- 制約（「何に触れてはいけないか」——本番環境の設定、データベーススキーマなど）
最初の手動実行：自分でタスクをエージェントに手動で与えてください。何ターンかかったか、何回介入したか、結果の品質を記録してください。これがベースラインになります。
/goal で実行：同じ goal.md を入力として使い、/goal モードで実行してください。エージェントは、ゴールに到達するか停止条件がトリガーされるまで、自らループします。
結果を比較する：
- ターン数の違い
- 介入回数の違い
- 結果の品質の違い（同じ検証基準を使用）
- 費やした時間の違い
goal.mdを反復する：結果が芳しくなければ、ゴールの説明を修正して再実行してください。結果に満足するか、このタスクでゴールループができることの限界を確認するまで続けてください。

実験2：タイマーループ — 監視を鼓動に変える

p07-timer-loop ブランチに切り替えてください。

監視タスクを選ぶ：普段手動で行っている反復的なチェックを見つけてください。例：
- 1時間ごとにテストスイートを実行し、失敗を修正する
- 毎朝、依存関係のセキュリティアップデートを確認する
- 各コミットの後、コーディングスタイルの違反がないかチェックする
- 定期的にTODOコメントをスキャンして、古くなっているものがないか確認する
監視プロンプト/スクリプトを書く：監視の手順を明確にレイアウトしてください——何をチェックするか、問題が見つかったら何をするか、いつ人間を呼ぶか。
/loop（またはCodexスレッドオートメーション）で実行：
- 適度な間隔を設定してください（10～30分を推奨——短すぎると煩わしく、長すぎると効果が見えません）
- 少なくとも2時間は動かしてください（または他のことをしてから後で戻ってきてください）
結果を記録する：
- いくつの問題を発見したか？
- いくつを自分で修正したか？
- いくつが誤検知だったか？
- いくつを悪化させたか？
- 結果のフォローアップにどれくらいの時間を費やしたか？
振り返る：この監視タスクは自動化する価値がありますか？節約した時間とフォローアップに費やした時間を比較してください。価値がないとしたら、タスクの選び方が悪かったのか、それともループの設計が悪かったのか？

実験3：Maker-Checkerループ — ループから自分を外す

p07-maker-checker ブランチに切り替えてください。

これは3つの実験の中で最も重要です。あなたがそこにいなくても動く完全なループを構築します：

ループ構造を設計する：
- Makerエージェント: 実装する、コードを書く、ファイルを修正する
- Checkerエージェント: 検証する、テストを実行する、コードレビューをする、合格 / 不合格を判定する
- 状態ファイル（loop-state.md）：現在のラウンド、何をしたか、検証結果、次は何かを記録する
- 停止条件：N回連続合格、または最大ラウンド数に到達
3つのプロンプトを書く：
- Makerの指示（何をするか、どうやるか、何に触れてはいけないか）
- Checkerの指示（何を検証するか、どう検証するか、何をもって合格とするか、どうフィードバックするか）
- ループ制御ロジック（誰が最初か、引き継ぎはどう行うか、次のラウンドをどう始めるか）
少なくとも5ラウンド実行する：
- ラウンド1：Makerが実装 → Checkerが検証 → 不合格 → Makerへフィードバック
- ラウンド2：Makerがフィードバックに基づいて修正 → Checkerが検証 → ...
- ...
- 連続合格するか、あなたが打ち切るまで
各ラウンドの状態を記録する：
- ラウンド番号
- Makerが何をしたか
- Checkerがどんな問題を発見したか
- 合格 / 不合格
- あなたは介入したか？（もしそうなら、なぜ？）
最終レトロ：
- 何回介入したか？なぜ？
- 介入しなかったら何が起こったか？
- Checkerは見落とした問題があったか？
- Makerは同じ間違いを繰り返していたか？
- このループの品質の天井はどこか？Makerの能力か、それともCheckerの能力か？

結果の測り方

指標	実験1（ゴール）	実験2（タイマー）	実験3（Maker-Checker）
タスク完了率	ゴールは達成されたか？	何サイクルの監視が実行されたか？	合格までに何ラウンドかかったか？
人間の介入	何回介入したか？	フォローアップにどれくらいの時間を費やしたか？	何回介入したか？
結果の品質	手動と比べてどうか？	誤検知率？見落とした問題？	Checkerが発見した問題のうち、あなたなら見つけられなかったものはいくつあるか？
節約時間	どれくらいの時間を節約したか？	自動化する価値はあるか？	ループの設計に費やした時間 vs. 節約した時間
信頼性	停止条件は信用できるものだったか？	暴走したか？	ループは同じ場所で動けなくなることがあるか？

提出するもの

goal.md（実験1のゴールの説明、少なくとも2回の反復）
実験1の比較メモ：手動 vs ゴールループ
実験2の監視プロンプト + 2時間の実行ログ
実験3の3つのプロンプト（Maker / Checker / ループ制御）
実験3の loop-state.md（少なくとも5ラウンド記録）
最終レトロ：3つの実験すべてからの学び、ループエンジニアリングに対する理解がどう変わったか、どんなものがループ化の良い候補でどんなものはそうでないか

プロジェクト 07. 初めての自動ループを構築する ​

このプロジェクトですること ​

プロジェクトファイル ​

使用するツール ​

ステップ ​

準備 ​

実験1：ゴールループ — 手動実行から自動実行へ ​

実験2：タイマーループ — 監視を鼓動に変える ​

実験3：Maker-Checkerループ — ループから自分を外す ​

結果の測り方 ​

提出するもの ​

関連講義 ​