はじめに
Claude Code（ターミナル上で動くAnthropicのAIコーディングエージェント）の /loop コマンドを使って、個人開発のWebアプリを対象に「要件定義→設計→開発→検証（lint/テスト/ビルド）→デプロイ→修正」のサイクルを半日以上、自律的に回し続けてみました。
この記事は /loop・/goal などの機能紹介ではなく、実際に回して分かった運用ノウハウのまとめです。「AIに開発を任せて、人間は方針決めとレビューに集中する」スタイルを試したい人に向けて書いています。
TL;DR
- ループ用プロンプトは運用契約書として書く（品質ゲート・報告形式・終了条件まで全部入れる）
- タスク一覧をMarkdownファイル（BACKLOG.md）で共有し、AIが上から消化・人間がいつでも並び替える運用が最強
- 要件定義と起票もAIに任せられる。ざっくりした要望を投げれば、Claude Codeが要件に落としてバックログに追記してくれる
- イテレーションを細かく刻むとアジャイルのスプリントのように回せる。手戻りが小さくなり、トークン消費も削減できる
- CI（テスト＋lint＋ビルド）はループの安全網。先に作る
-
/goalを設定すると「全タスク完走」を強制できる（16項目を1ターンで完走した） - 人間の仕事は「優先順位の並び替え・実機フィードバック・権限が必要な1回作業」の3つに収束する
前提：題材にしたプロジェクト
実験台にしたのは、私が1人で開発している小規模なWebアプリです。固有名は伏せますが、構成は個人開発でよくある形なので、同じような構成なら本記事のやり方はほぼそのまま使えるはずです。
- アプリ: 家族で使う記録系のWebアプリ（画面数は10前後の規模）
- 技術スタック: Next.js（フロント＋API）/ Supabase（DB・認証）/ Vercel（ホスティング）
-
デプロイ: GitHub連携済みで、
git pushすると Vercel が自動でビルド＆本番デプロイする構成 -
タスク管理: やりたいことをリポジトリ直下の
BACKLOG.mdに箇条書きで溜めてある（実験開始時点で残り16項目）
つまり「pushすれば本番に出る個人開発アプリ」と「やることリスト」がある状態からスタートして、消化作業をAIのループに任せた、という話です。
1. /loop の基本と2つのモード
/loop は、Claude Codeに同じ指示を繰り返し実行させるコマンドです。2つのモードがあります。
-
/loop <プロンプト>… 間隔を指定しないと動的モード。モデルが自分で次の実行タイミングを決めて自走します（デプロイ待ちは短く、ユーザー返答待ちは長く、のような自己ペーシング） -
/loop 5m <プロンプト>… 固定間隔モード。セッション内のcron（定期実行ジョブ）として一定間隔で実行されます（最長7日で自動失効・セッションを閉じると消える） - 毎日実行のような長周期なら
/schedule（クラウド実行）を案内されます
実際に使って分かった使い分けはこうでした。
開発サイクルのような「1イテレーション数分〜十数分」の作業は固定間隔cron（5〜10分）が安定。動的モードはデプロイ完了確認のような「待ち」が絡む場面で効くが、後述の表示問題があった。
2. ループ用プロンプトは「契約書」として書く
ループに渡すプロンプトに、やること以外の運用ルールまで全部書くのが最大のコツでした。実際に使った構成は次の5点です。
- 何をするか: 「BACKLOG.md の残バックログを上から1イテレーション実行」
- 品質ゲート: 「lint・テスト・ビルドを通してから push」
- 報告形式: 「結果を必ず日本語のテキストで報告。ターンの最後はツール呼び出しではなくテキストで終える」
- 継続性: 「前回の続きが未完なら先にそれを完了させる」
- 終了条件: 「バックログが空になったら完了を記録して cron を自分で停止」
特に 4) と 5) が重要です。会話が長くなるとClaude Codeは古いやりとりを要約に置き換えてコンテキストを節約します（compaction）。これで過去の経緯の詳細が失われても、プロンプト自体が自己完結していればループは壊れません。終了条件を書いておくと、やることがなくなった後に空回りしません。
3. バックログを「共有ファイル」にして人間がハンドルを握る
タスク一覧を BACKLOG.md というMarkdownファイルとしてリポジトリに置き、AIは上から順に消化、人間はいつでも並び替え・追加・削除できる運用が非常に相性が良かったです。中身はこんなイメージです。
## 残バックログ（上が優先）
1. 一覧画面に日付フィルタを追加する
2. グラフ画面のモバイル表示崩れを修正する
3. データのCSVエクスポート機能を追加する
## 完了済み
| 項目 | コミット |
|:--|:--|
| ダークモード対応 | abc1234 |
- 完了した項目はコミットIDと一緒に「完了済み」表へ移す。これが進捗ログと監査証跡を兼ねる
- ループ中にユーザーがバグ報告や要望を投げると、AIはバックログより優先して割り込み対応し、終わったらループに復帰する
- Claude Codeは画像も読めるので、画面のスクリーンショット＋「ここがこうなる」という症状だけ貼ればバグ修正まで進む。この体験はループ中でも健在
専用のタスク管理ツールではなく「ただのMarkdownファイル」なのがポイントで、人間はエディタで行を並び替えるだけ、AIは普通のファイル編集として読み書きするだけで連携が成立します。
要件定義と起票もClaude Codeに任せられる
バックログの項目は、人間が全部書く必要はありません。ざっくりした要望を投げるだけで、要件定義から起票までClaude Code側でやってくれます。
たとえば「データを後から見返しやすくしたい」のような曖昧な一言を投げると、Claude Codeが既存のコードと画面構成を踏まえて、
- 目的（何を解決したいのか）
- 具体的な実現方法（どの画面にどんなUIを足すか、既存のどの機能を使うか）
- スコープ（今回やること・やらないこと）
を整理し、実装可能な粒度のタスクに分解して BACKLOG.md に追記してくれます。つまり**「要望→要件→起票」の翻訳作業ごとAIに任せられる**ということです。
さらに、ループ中にAI自身が気付いた改善点（リファクタリング候補・テスト不足・表示の不整合など）を、その場で対応せずバックログの下の方に起票しておく、という動きもします。人間の役割は、起票された項目をレビューして、順番を決める（または消す）ことに絞られます。
書き殴りの要望メモを渡して「これをバックログに整理して」と頼むのも有効でした。優先順位の最終決定だけ人間が握っていれば、起票はAIに任せて問題ありません。
4. /goal で「完走」を強制する
/goal は、Claude Codeに達成条件を設定するコマンドです。条件を満たすまでAIがターン（ひとまとまりの作業）を終了できなくなります。
/goal バックログのタスクが全て完了すること
これを設定した途端、5〜10分間隔でコツコツ進んでいたループが、1ターンで残タスクを連続消化するマラソンモードに入りました（残っていた16項目を1ターンで完走）。
「少しずつ進めて様子を見たい」場合は設定しない方がいいです。逆に「今日中に全部終わらせたい」場面では強力です。
5. 1イテレーションの型
ループの中身は毎回ほぼこの型に収束しました。
| フェーズ | 内容 |
|---|---|
| 要件定義 | 着手前に「何をどう作るか」の設計判断を短く宣言させる |
| 実装 | 既存コードの規約（コンポーネント・定数・表示ロジック）に乗せる |
| 検証 | lint → ユニットテスト → 本番ビルド |
| デプロイ | push（Vercelが自動デプロイ）→ 完了をCLIで確認 → 本番URLにcurlでスモークテスト |
| 記録 | バックログ更新・ドキュメント更新・コミット |
| 報告 | 何ができるようになったかをユーザー視点の日本語で |
ポイントは**「検証をプロンプトで強制する」**ことです。書いておかないと省略される可能性がありますが、書いておけば毎回必ず通してから push します。
イテレーションを回すと「アジャイルっぽい開発」になる
この型を細かい単位で回し続けると、流れ全体がそのままミニスプリントとして機能することに気付きました。アジャイルの用語に対応させるとこうなります。
| アジャイルの概念 | ループ運用での対応物 |
|---|---|
| プロダクトバックログ | BACKLOG.md |
| 起票・要件定義 | 人間のざっくり要望をAIがタスクに分解して起票 |
| スプリント | 1イテレーション（数分〜十数分） |
| スプリントレビュー | ループ後の日本語報告＋本番URLでの実機確認 |
| バックログリファインメント | 人間によるBACKLOG.mdの並び替え・追加・削除 |
| ふりかえり | ハマった点をプロンプトやCLAUDE.mdのルールに反映 |
毎イテレーションの終わりに「動くもの」が本番にデプロイされ、人間がそれを触ってフィードバックを返す——ウォーターフォール的に全部作ってから確認するのではなく、動くものベースで方向修正しながら進む開発が、AIとの間で自然に成立します。
細かいイテレーションは手戻りとトークン消費を減らす
イテレーションを細かく刻むことには、開発スタイル以外にも実利が2つありました。
- 手戻りが小さくなる: 1回の変更が小さいほど、方向性のズレに早く気付けます。大きく作り込んでから「思っていたのと違う」となると、書き直し・デバッグのやり直しが丸ごと発生しますが、小さく刻んで毎回検証＋実機確認を挟めば、ズレはその1イテレーション分で済みます
- トークン消費が削減できる: 手戻りはそのままトークンの再消費です。書き直しになったコードの生成・読み直し・デバッグに使ったトークンはすべて無駄になります。また、大きいタスクを1ターンで進めるとコンテキストが膨らみ、要約（compaction）や過去のやりとりの読み直しにもトークンを食います。小さいイテレーションは1ターンのコンテキストを短く保てるので、同じ成果に対する総トークン量が安く済みました
「速く作らせる」より「小さく作らせて早く確認する」方が、結果的に速くて安い。これはループ運用で一番体感した教訓です。
6. CI はループの安全網（先に作る）
ループで開発速度が上がるほど「壊れたまま push」の事故率も上がります。ユニットテスト＋CIはループ運用とセットで早期に入れるべきでした。
ハマりどころ1: GitHub Actions のワークフローファイル（.github/workflows/ 以下）は、gitの認証トークンに workflow スコープ（権限）がないと push も API 経由作成も拒否されます。
gh auth refresh -s workflow
で再認証が必要です（対話型のブラウザ認証なので人間の作業）。
回避策: Vercel はデプロイ時、package.json に vercel-build というスクリプトがあると、通常の build の代わりにそれを実行します。これを利用すると、次の1行を足すだけで「push毎に lint+テスト+ビルドが走り、どれか失敗したらデプロイ中止」という実質CIになります。GitHub Actions を作る権限が足りない時の代替として優秀でした。
{
"scripts": {
"vercel-build": "npm run lint && npm test && npm run build"
}
}
ハマりどころ2: 次のようにパイプすると exit code（コマンドの成否を表す終了コード）がパイプ先のものになり、ビルド失敗を見逃して push する事故が実際に起きました。
# NG: tail の exit code になりビルド失敗を見逃す
npm run build 2>&1 | tail
# OK: ファイルにリダイレクトして $? を見る
npm run build > build.log 2>&1
echo $?
7. 人間にしかできない作業を「1回の作業」に圧縮する
ループ中でも人間の手が必要な場面は残ります。私のケースでは次の3つでした。
- DBの権限設定: SupabaseのRLS（Row Level Security：行単位のアクセス制御）ポリシーのようなDDLは、管理画面のSQLエディタで実行する必要があった
-
対話型のブラウザ認証: 前述の
gh auth refreshのように、ブラウザを開いて人間が承認する操作 - コストに関わる機能の採否判断: 有料サービスを使うかどうかのような、お金が絡む意思決定
うまく回ったやり方は次の3つです。
- AIに、実行すべきSQLやコマンドを**「コピペで終わる形」まで用意**させ、人間は貼り付けて実行するだけにする
- 判断が必要なものは選択肢形式の質問でまとめて聞かせ（Claude Codeには選択式で質問するAskUserQuestionという仕組みがあります）、回答に応じてループを続行する
- 人間の作業待ちでループを止めない。待っている間に別のタスクを進めさせる
8. ハマった点と対処（正直ベース）
- 動的モードで報告が表示されないことがあった: 動的モードでAIが次回実行を予約してターンを終えると、直前の報告テキストがターミナルに表示されないことがありました。固定cron方式に切り替えて「ターンの最後は必ずテキストで終える」ようプロンプトに明記したら解消しました
- 二重実行に注意: 動的モードの予約と固定cronが二重に動くと同じタスクが重複実行されかねません。移行時は片方を確実に止めること
-
セッションcronは揮発する: 7日で失効し、セッションを閉じると消えます。永続させたいなら
/schedule（クラウド実行）へ - コードブロックが表示されない環境があった: 重要なコマンドはプレーンテキストでも書く・ファイルに書き出してエディタで開く、という逃げ道が役に立ちました
9. ドキュメントもループに組み込む
要件定義書・設計書・運用ガイドを docs/ ディレクトリに整備した上で、CLAUDE.md（Claude Codeが毎セッション自動で読み込むプロジェクト指示ファイル）に「機能追加・仕様変更をしたら同じ作業内で該当ドキュメントを更新する」というルールと、機能とドキュメントの対応表を書きました。
以降のイテレーションでは、機能実装と同じコミットでドキュメントが更新されるようになりました。「ドキュメントを書いて」と毎回頼むのではなく、ルールとして仕組みに埋め込むのがループ運用との正しい組み合わせだと思います。
まとめ
/loop は「定期実行の仕組み」にすぎませんが、次の組み合わせで「方針を渡して定期報告を受ける」開発スタイルが成立しました。
| 要素 | 役割 |
|---|---|
| ループプロンプト | 運用契約書 |
| BACKLOG.md | 人間のハンドル |
| AIによる要件定義・起票 | 要望をタスクに翻訳する入口 |
| 細かいイテレーション | 手戻り防止とトークン削減 |
| CI | 安全網 |
| /goal | 完走の強制力 |
| CLAUDE.md | 毎回守らせるルール置き場 |
要件定義・起票から実装・デプロイまでをAIが回し、イテレーションを細かく刻むことで、AI相手でも**アジャイルのスプリントに近い「動くものベースの開発」**が成立します。人間の仕事は、優先順位の並び替え・実機でのフィードバック・権限が必要な1回作業、の3つに収束していきました。