概念: ループエンジニアリング
ループエンジニアリングとは
コーディング AI に仕事を任せても、1 回の指示で終わる仕事はまずありません。 AI が作って確かめたものを人が判断します。使った人の反応を受けてまた直します。 ループエンジニアリングはこの流れを偶然に任せず設計して回すやり方です。
Looptrack はこれを入れ子になった 3 つのループとして扱います。 内側ほど速く外側ほどゆっくり回ります。
| ループ | 周期の目安 | 回す人 | 1 周の中身 |
|---|---|---|---|
| ① AI の周 | 数分 | AI | next（次のイシューに着手）→ 作業 → コメント → 検証 → Done → 次の next |
| ② 人の周 | 数十分〜数時間 | 人 | AI が In Review に置いたものを人が判断します。了承かやり直しかを決め、人からのフィードバックも入ります |
| ③ 外の周 | 数時間〜数週 | 参加者・テスター | 使った人の反応をイシューに戻し、次の作業に生かします |
① AI の周
AI は着手できるイシューのうち優先度がいちばん高いものを取ります。 取ったイシューに付いてくるのは本文・受け入れ条件・関連です。 作業を進めながら原因や判断が分かればその時点でコメントに残します。 受け入れ条件を 1 つずつ確かめて結果をコメントに書きます。Done にするのはその後です。 そして次のイシューへ進みます。
人が毎回この周に加わる必要はありません。
② 人の周
仕様の解釈・見た目・方針の選択は AI だけで決めてはいけません。 だから AI は Done にせず In Review に置きます。 人は都合のよいときに In Review をまとめて見てください。 了承なら 判断: で始まるコメントを残します。やり直しなら 差し戻し: で始めます。それだけです。 AI は次の周に入る前にそれを受け取って Done か Todo に動かします。
③ 外の周
作ったものは使う人に届いてはじめて評価できます。 参加者・テスター・利用者の反応を聞いたら、フィードバック: で始まるコメントにしてイシューに戻しておきましょう。 まだ誰も応えていない反応は要約に「未応答」として並びます。 方針のコメント・新しい起票・状態の変更のどれか 1 つで応答すれば、並びから消えます。
なぜイシューを正本にするのか
AI のコンテキストはセッションが終われば消えます。 長いセッションでも要約されると細かいところが抜け落ちます。 次のセッションの AI は前に何を決めたかを覚えていません。
そこで、次の 2 つをイシューに置きます。
- 次に何をするか: 状態・優先度・待ち（blocked_by）・受け入れ条件
- なぜそうしたか: 原因・判断・差し戻しの理由・検証の結果（コメント）
イシューはサーバの DB に 1 つだけあります。どの AI もどのセッションも同じイシューを読みます。 コメントは追記だけで書き換えも削除もできません。閉じたイシューの本文も変えられません。 だから、あとから経緯をたどれるわけです。
会話やメモだけで進めると、この 2 つは次のセッションに渡りません。 「作業はイシューから始める」が Looptrack の基本の約束です。
要するにイシューは AI の外部記憶です。コンテキストウィンドウに収まらないものはここに残り、次のセッションはここから始まります。 とはいえ、プロジェクト本来のイシューの一覧を置き換えるものではありません。 人が話し合う要望や不具合の報告はふだんの置き場に残して大丈夫です。ここに置くのは AI がその仕事を分解した作業単位です。 どれも 1 件ずつ取れる大きさで、それぞれが作業計画・判断・その作業で消費したトークンを持ちます（トークンレポート）。
規則はサーバが守らせる
採番・追記だけのコメント・閉じたイシューの不変・プロジェクト別ルールは、サーバが検査します。 CLI と MCP のどちらから使っても通る検査は同じです。 違反すると次に何をすればよいかを書いたエラーが返ってきます。 AI はそのメッセージに従って先へ進むだけです。