Claude Code でループを作成する方法

Claude ワークフローのほとんどは、まだワンショットです。

プロンプトを書く。Claude が応答する。セッション終了。翌日にはゼロからやり直し。

単発のタスクにはそれで十分です。

しかし、反復作業（日次レビュー、CI トリアージ、プロジェクト監視、ミーティングフォローアップ）では、毎日同じコンテキストを再構築しています。

それはワークフローではありません。AI を少しかけた手作業です。

より良い抽象化はループです。

これを保存しておいてください。使うことになります。

Claude ループの正体

ループとは「もう一度 Claude に聞くだけ」ではありません。

ループとは、モデルの周りに構築された反復可能なワークフロー構造です。

ループは以下を定義します：

→ 何が実行をトリガーするか

→ Claude が行動する前に読むコンテキスト

→ Claude に許可される行動 → 出力の検証方法

→ 状態が保存される場所

→ いつ停止、繰り返し、または人間のレビューを依頼するか

モデルは依然として推論を行います。

ループは運用構造を提供します。

このシフトが重要なのは、Claude セッションが一時的だからです。

ループがなければ、毎回の実行はゼロから始まります。ループがあれば、Claude は前回の内容を読み、そこから続行します。

すべての Claude ループに必要な 6 つの要素

構造のないループは、2 回実行されるプロンプトにすぎません。

ループを実際に機能させる 6 つの要素は次のとおりです：

→ 1. トリガー

実行を開始するもの。

手動コマンド。スケジュールされたタイマー。ファイル変更。CI 障害。Git イベント。

→ 2. コンテキスト

Claude が行動する前に読むもの。

タスク定義。前回の進捗。プロジェクトファイル。指示。

→ 3. アクション

Claude が行うこと。

レポート作成。修正案の作成。障害の分類。ドキュメントの更新。

→ 4. 検証

結果を確認する方法。

チェックリスト。テストスイート。必須セクション。安全境界チェック。

→ 5. 状態更新

次回のために記憶されるもの。

PROGRESS.md の更新。ブロッカーの記録。次回の実行ガイド。

→ 6. 判断

停止。繰り返し。または人間へのエスカレーション。

これが完全なループです。

そして、すべてのステップが重要です。

検証をスキップ → ループは盲目的に自分自身を信頼します。

状態をスキップ → 毎回の実行はゼロから始まります。

判断をスキップ → ループはいつ停止すべきかを知りません。

ループを機能させる 4 ファイルシステム

インフラストラクチャは必要ありません。

必要なのは 4 つのファイルと 1 つのフォルダです。

1my-loop/
2├── TASK.md
3├── LOOP_INSTRUCTIONS.md
4├── PROGRESS.md
5└── outputs/
6    └── daily-review.md

TASK.md — 目標。このループが達成しようとしていること。

LOOP_INSTRUCTIONS.md — 運用手順。Claude の実行方法、許可される行動、検証方法。

PROGRESS.md — メモリ。前回の出来事、ブロックされていること、次回の実行で焦点を当てるべきこと。

outputs/ — Claude が結果を書き込む場所。予測可能。検査可能。安全。

これだけです。

Claude は毎回の実行開始時にこれらのファイルを読み込み、終了時に更新します。次回の実行は、前回の停止場所から続行します。

これが、ループを繰り返しプロンプトと異なるものにしています。

状態はチャットの外部に存在します。

TASK.md — 目標を明確に定義する

このファイルは、ループの目的を Claude に伝えます。

ハイレベルに保ちましょう。運用の詳細はここに書かないでください。それらは LOOP_INSTRUCTIONS.md に記述します。

このテンプレートをコピーしてください：

1# 日次プロジェクトレビューループ
2
3## 目標
4このプロジェクトフォルダをレビューし、変更点を要約し、
5ブロッカーを特定し、短い日次レビューレポートを作成します。
6
7## 期待される出力
8各実行で以下を作成または更新する必要があります：
9- `outputs/daily-review.md`
10- `PROGRESS.md`
11
12## スコープ
13Claude はこのワークスペース内のファイルを検査し、
14`outputs/` フォルダにレポートを書き込むことができます。
15
16Claude は以下を行うべきではありません：
17- ソースファイルの変更
18- ファイルの削除または名前変更
19- メッセージの送信やチケットの作成

最後のセクションに注目してください。

どのループの最初のバージョンにも、明示的な「禁止」ルールが必要です。

これは Claude が信頼できないからではありません。

これは、あなたが優れたエンジニアであるための方法です。

PROGRESS.md — ループのメモリ

これはシステムの中で最も重要なファイルです。

これがなければ、毎回の実行はゼロから始まります。これがあれば、Claude は何が起こったかを知り、そこから続行します。

実際に機能する構造：

1# ループ進捗
2
3## 現在の状態
4- ステータス: アクティブ
5- メイン目標: 日次プロジェクトレビュー
6- 現在の焦点: [現在重要なこと]
7- 最終更新日: [日付]
8
9## 前回の実行
10- 日付:
11- 概要:
12- レビューしたファイル:
13- 作成された出力:
14
15## 未解決項目
16-
17
18## ブロッカー
19-
20
21## 人間のレビューが必要
22-
23
24## 次回の実行で行うべきこと
25-
26
27## 行われた判断
28-
29
30## 繰り返さないこと
31-

「繰り返さないこと」セクションは重要です。

これは、Claude が既に失敗したことを再試行するのを防ぎます。

「人間のレビューが必要」セクションは重要です。

これは、ループがそうすべきでないときに静かに続行するのを防ぎます。

PROGRESS.md を有用に保つための 2 つのルール：

→ Claude が次のアクションを決定するためにそれが必要な場合 → PROGRESS.md に保持

→ 単に記録が必要な場合 → outputs/history/ に移動

永遠に成長し続ける状態ファイルは役に立たなくなります。

PROGRESS.md をアーカイブではなく、コントロールパネルとして維持してください。

LOOP_INSTRUCTIONS.md — 運用手順

このファイルは、Claude の制御層です。

Claude に、何を読み、何を書き、何に触れてはならず、停止する前に結果を検証する方法を正確に指示します。

機能するテンプレート：

1# ループ指示
2
3あなたは日次プロジェクトレビューループを実行しています。
4
5## 開始前
61. `TASK.md` を読む
72. `PROGRESS.md` を読む
83. プロジェクトフォルダを検査する
94. 何が変更され、何が未完了で、何が人間のレビューを必要とするかを特定する
10
11## 行うべきこと
12`outputs/daily-review.md` に短い日次レビューを書き込む。以下を含む：
13- 現在の状態の概要
14- レビューしたファイル
15- 意味のある変更
16- ブロッカーまたは未解決の質問
17- 推奨される次のアクション
18
19書き込み後、`PROGRESS.md` を以下で更新する：
20- この実行の日付
21- 発生したことの概要
22- チェックしたファイル
23- 次回の実行が行うべきこと
24- 人間のレビューが必要かどうか
25
26## 安全ルール
27- ファイルを削除しない
28- ファイルの名前を変更または移動しない
29- ソースファイルを変更しない
30- `outputs/daily-review.md` と `PROGRESS.md` にのみ書き込む
31- アクションが許可されているか不明な場合 → 停止して質問する
32
33## 検証チェックリスト
34実行を終了する前に、以下を確認する：
35- `outputs/daily-review.md` がすべての必須セクションとともに存在する
36- `PROGRESS.md` が更新された
37- 許可されたパス以外のファイルは変更されていない
38
39## 障害ポリシー
40検証が失敗した場合：
411. レポートのセクション欠落 → 1 回修正する
422. PROGRESS.md が更新されていない → 1 回更新する
433. 禁止されたファイルが変更された → 直ちに停止する
444. 同じチェックが 2 回失敗する → 人間のレビューが必要としてマークする

最後の障害ポリシーに注目してください。

ほとんどのループには障害ポリシーがありません。

そのため、何か問題が発生すると、Claude は即興で対応します。

そこでループが問題を引き起こします。

障害パスを明示的に定義してください。常に。

最初のループを手動で実行する

まだスケジュールしないでください。

最初は手動で実行します。

Claude Code または Claude Desktop/Cowork でフォルダを開き、次のプロンプトを使用します：

1このワークスペースの日次プロジェクトレビューループを実行してください。
2
3`LOOP_INSTRUCTIONS.md` に正確に従ってください。
4
5行動する前に、以下を読んでください：
6- `TASK.md`
7- `PROGRESS.md`
8- `LOOP_INSTRUCTIONS.md`
9
10次に、ワークスペースを検査し、日次レビューを
11`outputs/daily-review.md` に書き込み、`PROGRESS.md` を更新し、
12検証チェックリストを実行し、何が変更されたかを報告してください。
13
14`outputs/daily-review.md` と `PROGRESS.md` 以外の
15ファイルは変更しないでください。

実行後、2 つのことを確認します：

→ outputs/daily-review.md — すべてのセクションを含む構造化レポート

→ PROGRESS.md — 更新された状態、次回の実行ガイダンス、人間のレビューフラグ

両方とも正しければ → ループは機能しています。

次に、小さな変更を加えながら 3〜5 回実行します。

メモファイルを追加します。PROGRESS.md にブロッカーを追加します。ワークスペース内の何かを変更します。

各実行は、ゼロから始めることなく変更を拾う必要があります。

その継続性こそがすべてのポイントです。

検証：ほとんどの人がスキップする部分

誰も話さない障害モードがここにあります。

Claude がループを実行します。完了したと言います。状態を更新します。停止します。

すべて問題なく見えます。

しかし、レポートに必須セクションが欠けています。または PROGRESS.md が実際には更新されていません。または Claude が触るべきではなかったファイルを静かに編集しました。

何かが壊れたときに初めて気づきます。

そのため、検証が存在します。

ループは Claude が終了したと言ったから停止するのではありません。

具体的な条件がチェックされたから停止します。

適切な検証は次のようになります：

最新のループ実行の検証パスを実行してください。

LOOP_INSTRUCTIONS.md の検証チェックリストに対して

出力をチェックしてください。

報告：

1. どのチェックが合格したか
2. どのチェックが失敗したか
3. どのファイルが変更されたか
4. 実行を受け入れても安全か
5. 人間のレビューが必要か

この検証パス中にファイルを変更しないでください。

ワーカーを実行します。次に検証者を実行します。別々に。

時間が経てばマージできます。しかし、初期テスト中は分離しておいてください。

検証者には合格/不合格基準が必要です。

「これをレビューして、問題ないか教えてください」は検証者ではありません。

「これら 7 つの条件をチェックし、すべてが合格した場合のみ実行を承認済みとしてマークする」が検証者です。

/loop でのスケジュール設定

ループは手動で確実に実行されています。

次にスケジュールします。

Claude Code で、/loop を使用します：

1/loop 24h このワークスペースの日次プロジェクトレビューループを実行してください。
2
3`LOOP_INSTRUCTIONS.md` に正確に従ってください。
4最初に `TASK.md` と `PROGRESS.md` を読んでください。
5レポートを `outputs/daily-review.md` に書き込んでください。
6停止する前に `PROGRESS.md` を更新してください。
7検証チェックリストを実行してください。
8意味のある変更がない場合 → レポートを短くしてください。
9人間のレビューが必要な場合 → `PROGRESS.md` に明確にマークしてください。
10`outputs/daily-review.md` と `PROGRESS.md` 以外の
11ファイルは変更しないでください。

間隔オプション：

→ /loop 15m — テスト用ケイデンス（監視中に使用）

→ /loop 1h — 毎時監視

→ /loop 24h — 日次レビュー

→ /loop 7d — 週次クリーンアップまたはサマリー

重要：/loop は魔法ではありません。

プロンプトを繰り返すだけです。

ループの品質は、プロンプトの周りの構造（ファイル、指示、検証、状態）から生まれます。

/loop はトリガーを提供するだけです。

/goal についても知っておいてください：

/loop = 時間が経過したので再度実行。

/goal = 条件が満たされるまで実行を続ける。

1/goal outputs/daily-review.md が存在し、PROGRESS.md が更新され、
2検証チェックリストに合格し、禁止されたファイルが変更されていないこと。

時間ベースの作業（日次レビュー、監視）には /loop を使用します。

完了ベースの作業（テストが通るまで修正、すべてのセクションが完了するまで書き込み）には /goal を使用します。

許可の階段

ここでほとんどのループが間違えます。

人々は機能するループを構築します。そしてすぐにそれにあまりにも多くの権限を与えます。

ループは Slack に直接投稿します。レビューなしでコードをプッシュします。チケットを自動的にクローズします。

そして何かが間違うと、大混乱になります。

代わりに許可の階段を使用してください：

1レベル 1 — 読み取り専用
2Claude はファイル、チケット、ログ、問題を読み取ります。
3
4レベル 2 — 出力のドラフト
5Claude は outputs/ にのみ書き込みます。
6レポート、計画、推奨事項。
7外部への出力はありません。
8
9レベル 3 — サンドボックス編集
10Claude は制御されたサンドボックス内のファイルを変更します。
11隔離されたブランチまたはワークツリー。
12
13レベル 4 — 外部アクションのドラフト
14Claude は PR、Slack メッセージ、チケット更新を準備します。
15送信またはマージは行いません。
16
17レベル 5 — 人間承認済みアクション
18Claude は明示的な承認後にのみ変更を適用します。
19
20レベル 6 — 自動化された低リスクアクション
21Claude は狭い範囲のタスクを自動的に完了します。
22ログ、制限、ロールバック付き。

最初のループはレベル 1 またはレベル 2 に留めるべきです。

それは弱さではありません。それはエンジニアリングです。

レベル 1 とレベル 2 のループでも非常に価値があります。

Claude は GitHub の問題を検査し、CI 障害を読み、PRD をレビューし、すべてを要約できます — 重要なものには一切触れずに。

最初にレベル 2 でループが機能することを証明してください。

その後、レベル 3 に値するかどうかを判断してください。

ループがうまくいかないとき（そしてそれを防ぐ方法）

悪い最初のループ：

毎日、製品戦略を改善して、より強力に感じられるようにする。

→ 停止条件なし → 検証なし → 状態なし → 「より強力に感じられる」はチェックリスト項目ではない

このループは、有用なことを何もしないか、すべきでないものを変更します。

良い最初のループ：

毎週金曜日、製品戦略ドキュメントをレビューする。

今週変更されたセクションを特定する。

未解決の前提をリストアップする。

構造化されたレビューノートを outputs/strategy-review.md に書き込む。

戦略ドキュメントを直接編集しない。

→ 明確なスケジュール → 限定されたスコープ → 予測可能な出力ファイル → 安全な許可境界

違いは知能ではありません。設計です。

ループを沈める 5 つのこと：

→ 手動テスト前のスケジュール設定

→ 状態ファイルなし — 毎回の実行がゼロから再開

→ 検証なし — ループが自分自身を信頼

→ 障害ポリシーなし — 悪い結果が即興で対応

→ ツールが早すぎる — 爆発半径が拡大

最初の /loop コマンドの前に、5 つすべてを修正してください。

ツールとコネクタの追加

ローカルループが安定したら、拡張できます。

GitHub。Slack。Linear。Jira。CI ログ。

しかし、新しいツールごとに爆発半径が拡大します。

同じ原則に従ってください：最初に読み取り、次にドラフト、成功した実行を繰り返した後にのみ書き込みます。

ツール固有のルールは LOOP_INSTRUCTIONS.md に記述します：

1## ツール許可ポリシー
2
3### GitHub
4許可：
5- オープンな問題の読み取り
6- プルリクエストステータスの読み取り
7- CI ステータスの読み取り
8- `outputs/github-review.md` へのサマリードラフト
9禁止：
10- コミットのプッシュ
11- プルリクエストのマージ
12- 問題のクローズ
13- 承認なしの公開コメント
14
15### Slack
16許可：
17- `outputs/slack-update.md` へのメッセージドラフト
18禁止：
19- メッセージの送信
20- ユーザーのメンション
21- チャンネルへの投稿
22
23### Linear/Jira
24許可：
25- 割り当てられたチケットの読み取り
26- 提案された更新のドラフト
27禁止：
28- ステータスの変更
29- チケットのクローズ
30- 承認なしのチケット作成

ツールがリストにない場合 → 停止して人間のレビューを依頼してください。

これにより、ループがあなたが考えていなかったことを行うのを防ぎます。

最初の完全なループの外観

ゼロからの完全なセットアップは次のとおりです。

1## ツール許可ポリシー
2
3### GitHub
4許可：
5- オープンな問題の読み取り
6- プルリクエストステータスの読み取り
7- CI ステータスの読み取り
8- `outputs/github-review.md` へのサマリードラフト
9禁止：
10- コミットのプッシュ
11- プルリクエストのマージ
12- 問題のクローズ
13- 承認なしの公開コメント
14
15### Slack
16許可：
17- `outputs/slack-update.md` へのメッセージドラフト
18禁止：
19- メッセージの送信
20- ユーザーのメンション
21- チャンネルへの投稿
22
23### Linear/Jira
24許可：
25- 割り当てられたチケットの読み取り
26- 提案された更新のドラフト
27禁止：
28- ステータスの変更
29- チケットのクローズ
30- 承認なしのチケット作成

次に、各ファイルを入力します（上記のテンプレートを使用します）。

次に、手動で実行します：

1このワークスペースの日次プロジェクトレビューループを実行してください。
2
3`LOOP_INSTRUCTIONS.md` に正確に従ってください。
4行動する前に、TASK.md、PROGRESS.md、
5および LOOP_INSTRUCTIONS.md を読んでください。
6日次レビューを `outputs/daily-review.md` に書き込んでください。
7停止する前に `PROGRESS.md` を更新してください。
8検証チェックリストを実行してください。
9`outputs/daily-review.md` と `PROGRESS.md` 以外の
10ファイルは変更しないでください。

次に、検証します：

1検証パスを実行してください。
2`LOOP_INSTRUCTIONS.md` の検証チェックリストに対して
3チェックしてください。
4どのチェックが合格し、どのチェックが失敗し、
5どのファイルが変更され、人間のレビューが必要かを報告してください。
6ファイルを変更しないでください。

小さなワークスペース変更を加えながら、3〜5 回手動で実行します。

次に、スケジュールします：

1/loop 24h 日次プロジェクトレビューループを実行してください...
2[手動と同じプロンプト、先頭に /loop 24h を付ける]

スケジュールされた出力の最初の 1 週間を、信頼する前にレビューしてください。

これが完全なシステムです。

すべてを変えるシフト

ループ以前：

→ プロンプトを書く

→ Claude が答える

→ 明日、同じプロンプトを再び書く

→ Claude は昨日のことを覚えていない

→ 何が変わったかを手動で追跡する

→ すべてのセッションでリセットされる

ループ以後：

→ TASK.md が目標を一度定義する

→ PROGRESS.md が実行間でメモリを運ぶ

→ LOOP_INSTRUCTIONS.md が動作を制御する

→ Claude が読み、行動し、検証し、更新し、停止する

→ 明日は中断したところから続行する

→ プロンプトではなく出力をレビューする

ボトルネックが、作業の生成から作業のレビューにシフトします。

それが本当のレバレッジです。

Claude により良い質問をしているのではありません。

あなたなしで機能し続けるシステムを設計しているのです。

今週構築できる 10 のループ

→ 日次プロジェクトレビュー — ワークスペースを読み、サマリーを書く

→ ミーティングフォローアップ抽出 — ノートをアクションアイテムに変換

→ フォルダクリーンアッププランナー — 整理し、提案し、触らない

→ CI 障害トリアージ — ログを読み、障害を分類し、調査をドラフト

→ GitHub 問題サマライザー — オープンな問題を読み、テーマでグループ化

→ PR レビューアシスタント — diff を読み、潜在的な問題をフラグ

→ ニュースレターリサーチループ — ソースを収集し、サマリーをドラフト

→ ドキュメントギャップファインダー — ドキュメントを読み、欠落セクションをフラグ

→ 日次スタンドアップドラフター — PROGRESS.md を読み、スタンドアップを書く

→ 週次レトロスペクティブループ — 週をレビューし、パターンを特定

これらのすべてが、同じ 4 ファイルシステムから始まります。

変更されるのは TASK.md と LOOP_INSTRUCTIONS.md だけです。

これが役に立った場合：

→ リポストして、Claude を使用するすべての開発者と共有する

→ @sairahul1 をフォローして、あなたなしで機能するシステムをさらに入手する

→ これをブックマーク — テンプレートはコピペ可能

theaibuilders.co を購読して、さらに興味深い記事を入手する

私は AI、製品構築、自動化システムについて書いています。