序章：AIに「もう一回お願い」と言い続けていませんか
Claude Codeを使い始めると、多くの人が同じ流れをたどります。
- 「このバグを直して」と頼む
- Claudeが「直しました」と答える
- 自分でテストを動かすと、まだ落ちている
- 「まだ失敗しています。直して」ともう一度頼む
この3と4を、人間が何度も繰り返しています。確認して、もう一度頼むという往復を、仕組みとしてAI側に任せるのがループエンジニアリングです。
先に結論を示します。
- ループエンジニアリングとは、AIへの指示を毎回書く代わりに、「作業→確認→やり直し→終わったら止まる」という繰り返しの仕組みを設計すること
- この記事では、最初の小さなループを作るために、部品を確認する方法（検証）、途中経過の記録（状態）、止まる条件（停止条件）の3つに絞って説明する
- Claude Codeでは、
/goal（条件を満たすまで続ける）、/loop（一定間隔で繰り返す）、カスタムサブエージェント（確認係）の3つで組める - 最初のループは、テストのように合否が機械的に分かる仕事を、練習用のプロジェクトとブランチで試す
この記事では、プログラミング経験が浅い人でも追えるように、言葉の意味から順に説明します。Claude Codeの仕様は、2026年10月5日時点の公式ドキュメントで確認した内容です。記事中のコマンド例は公式ドキュメントの書式に沿って作成しました。2026年10月10日に、編集部で架空のTODO管理API（Node.js、わざと失敗するテストを2件入れたもの）の練習用プロジェクトを用意し、Part 3の手順を記事どおりに試しました。各Stepの「試した結果」は、Windows 11、Claude Code v2.1.296、モデルはOpus 5.5、手動で確認するモード（claude --permission-mode defaultで起動）、ユーザー単位の設定やMCPを読み込まない起動オプションを付けた環境で確かめたものです。会話の記録は編集部で保存しています。
本記事は、Coding Agent連載の第2回です。前回は、AIが働く作業場と権限を整える「ハーネスエンジニアリング」を扱いました。次回は、仕事を複数のエージェントに分けてつなぐ「グラフエンジニアリング」を扱います。
Part 1：ループエンジニアリングとは何か
「指示を書く人」から「仕組みを書く人」へ
GoogleのエンジニアAddy Osmani氏は、「Loop Engineering」という記事で、Claude Codeを率いるBoris Cherny氏の「仕事が、AIへ直接指示することから、ループを書くことへ移った」という趣旨の発言を紹介しています。本記事では、この考え方を「ループエンジニアリング」と呼びます。
AIとの付き合い方は、大まかに次の順で関心が移ってきました。
| 呼び方 | 人間が工夫すること | たとえるなら |
|---|---|---|
| プロンプトエンジニアリング | 1回の指示文を上手に書く | 部下への頼み方を磨く |
| コンテキストエンジニアリング | 必要な資料や前提を渡す | 頼むときに資料を添える |
| ハーネスエンジニアリング | 使える道具、触ってよい範囲、作業環境を整える | 作業場と安全柵を用意する |
| ループエンジニアリング | 作業・確認・やり直し・停止を自動で回す | 仕事が回る段取りそのものを作る |
前の段階が不要になるわけではありません。良い指示、良い資料、安全な作業環境は、ループの部品としてそのまま使います。
ループは「料理の味見」と同じ形をしている
ループを身近な例で言い換えると、料理の味見です。
- 作る（調理する）
- 確かめる（味見する）
- 足りなければ直す（塩を足す）
- 合格なら止める（盛り付ける）
AIのループも同じです。ただし、AIは「おいしくできました」と言いがちです。そこで、作る人と味見する人を分けるのがループエンジニアリングの基本になります。自分の料理を自分で採点すると甘くなるのは、人間もAIも同じです。
最初のループに必要な3つの部品
ループの部品の分け方は、論者によってさまざまです。定期的な起動、作業場所の分離、外部サービスとの接続などを含める整理もあります。この記事では、最初の小さなループを作るために、次の3つに絞ります。定期起動や作業場所の分離は、慣れてから足します。
| 部品 | 役割 | ないと何が起きるか |
|---|---|---|
| 検証（Verifier） | 合格か不合格かを判定する。テスト、ビルド、チェックリストなど | AIの「できました」をそのまま信じて、未完成のまま終わる |
| 状態（State） | 何を試し、何が失敗し、次に何をするかをファイルに残す | 毎回ゼロから考え直し、同じ失敗を繰り返す |
| 停止条件（Stop condition） | 「合格したら止まる」「20回で止まる」などの出口 | 何も進まないまま動き続け、費用だけが増える |
この3つのうち、いちばん大事なのは検証です。「いい感じにして」のように合否を判定できない目標では、ループは回っても良くなりません。迷ったら、次の質問で判断してください。
自分がいないときに、悪い結果を弾くチェックを書けるか？
書けるならループに向いています。書けないなら、まだ人間がその都度判断する仕事です。
Part 2：Claude Codeでループを作る道具
Claude Codeには、ループの部品になる機能が最初から入っています。
| 機能 | 何をするか | ループでの役割 |
|---|---|---|
/goal | 条件を設定すると、満たすまでClaudeが自動でターンを続ける。各ターンの後、別の小型モデルが達成を判定する | 停止条件と、作業者とは別の判定役 |
/loop | プロンプトを一定間隔で繰り返し実行する（例：/loop 30m ...） | 時間で起動する仕組み |
| カスタムサブエージェント | .claude/agents/に置いたMarkdownファイルで、役割と使えるツールを決めた専用エージェントを作る | 作る係とは別の確認係 |
CLAUDE.mdと進捗ファイル | 毎回読み込まれるルールや、会話の外に残す作業記録 | 状態（記憶） |
Routines（/schedule） | クラウドで定期実行する。PCを閉じていても動く | 本格運用の起動役 |
ここでいうターンとは、Claudeが一度作業して応答を終えるまでの区切りです。ファイルを何回修正したかの数ではありません。
/goalは条件を満たすまでターンを続けますが、判定役が「達成できない」と判断した場合や、エラーが起きた場合には、未完了のまま止まることもあります。止まったら、テスト結果と最後の判定理由を確認してください。
/goalと/loopの違いは、何が次の一回を始めるかです。
/goal：前のターンが終わったら、条件を満たすまで次を始める（完了で動く）/loop：決めた時間が経ったら次を始める（時間で動く）
「テストが全部通るまで直す」なら/goal、「1時間ごとにテストが落ちていないか見張る」なら/loopです。
Part 3：実際にループを作る5ステップ
ここからは、小さなプロジェクトのテストが全部通るまで、自分で直して確かめるエージェントを例に作ります。テストは合否が機械的に出るため、最初の題材に向いています。
この例ではClaudeにコードを編集させます。Part 5で説明する権限の段階でいうと「段階3（隔離した場所で編集する）」にあたるため、次の準備をしてから試してください。
- Node.jsとnpmが入っていて、
package.jsonにtestスクリプトが設定されているプロジェクト src/（アプリのコード）とtest/（テスト）があり、Gitで管理されている- 未コミットの変更がない、練習用のブランチで作業する
- 先に自分でターミナルから
npm testを実行し、結果を出して終了することを確かめておく（変更を待ち続けるウォッチモードのままだと、ループが先に進まない） - テストを実行するとテストファイル自体が書き換わる題材（スナップショットテストの更新など）は、この練習では避ける
コードを編集させるのがまだ不安なら、修正はさせず、テスト結果と修正案だけをPROGRESS.mdに書かせる形から始めても構いません。
なお、npm testのようなコマンドはOSのターミナルで実行するもの、/goalや/loopはClaude Codeの入力欄に入力するものです。
Step 1：題材を「合否が分かる仕事」に絞る
最初のループに向く仕事と、向かない仕事を分けます。
| 向く仕事 | 向かない仕事 |
|---|---|
| テストを全部通す | 「読みやすいコードにして」 |
| リンク切れを0件にする | 「ブログ記事を面白くして」 |
| 型チェックのエラーを0件にする | 「デザインをおしゃれにして」 |
| 指定フォルダのファイルを規則どおりに整理する | 正解が人の好みで決まる仕事 |
左側はどれも、数字やコマンドの結果で「終わった」と言える仕事です。
Step 2：状態を残すファイルを作る
プロジェクトのフォルダに、次の2つを用意します。
my-project/
├── TASK.md ← このループの目的（何を達成したいか）
└── PROGRESS.md ← 毎回の作業記録（何をして、何が失敗して、次に何をするか）
TASK.mdは短くて構いません。
# TASK `npm test` がすべて成功する状態にする。 ## やってよいこと - src/ 配下のファイルの修正 - PROGRESS.md の更新 ## やってはいけないこと - test/ 配下のテストファイルを書き換えて、無理やり合格させること - package.json の test スクリプトやテストの設定を変えて合格させること - 新しいライブラリを追加すること - コミット、プッシュ、外部への送信 ## 変更禁止の確認対象 - test/ - package.json - テストの設定ファイル（例：jest.config.js、vitest.config.ts。自分のプロジェクトで使っているものを書く）
PROGRESS.mdには、次の見出しだけ先に作っておきます。
# PROGRESS ## 前回やったこと ## まだ失敗していること ## もう試したので繰り返さないこと ## 人間に確認してほしいこと ## 次にやること
特に「もう試したので繰り返さないこと」と「人間に確認してほしいこと」が重要です。前者は同じ失敗の繰り返しを防ぎ、後者はAIが判断できないことを抱えたまま暴走するのを防ぎます。
最後に、プロジェクトの作業ルールを書いておくファイルCLAUDE.mdへ1行足して、毎回この2ファイルを読む約束にします。
作業の最初に TASK.md と PROGRESS.md を読み、作業の最後に PROGRESS.md を更新すること。
Step 3：確認係のサブエージェントを作る
次に、作る係とは別の確認係を作ります。.claude/agents/test-checker.mdというファイルを作り、次のように書きます。先頭の---で囲まれた部分はfrontmatterと呼ばれる設定欄で、名前、説明、使えるツール、使うモデルを指定します。
--- name: test-checker description: 変更後にテストを実行し、合格か不合格かを判定する確認係。コードは修正しない。 tools: Read, Grep, Glob, Bash model: haiku --- あなたはテストの確認係です。コードやテストは修正しません。 1. 今の状態で `npm test` を実行する。完了まで待ち、終了コードと実行されたテストの件数を確認する 2. `git status --short --untracked-files=all` を実行し、TASK.md の「変更禁止の確認対象」に変更がないか確認する。 src/ と PROGRESS.md の変更、今回新しく作った TASK.md・CLAUDE.md・サブエージェント定義は判断の対象外とする。 テストの設定ファイルが分からない場合は、推測で PASS にせず FAIL として人間に確認を求める （作業開始時に変更禁止の対象に未コミットの変更がなく、作業中はコミットしない前提で確認する） 3. 次のすべてを満たす場合だけ PASS とする - テストが1件以上実行された - 終了コードが 0 だった - 変更禁止の確認対象に変更がない どれか1つでも満たさない場合や、結果が分からない場合は FAIL とする 4. 次の形式で報告する。以前の PASS を使い回さず、今回実行した結果だけを書く - 判定: PASS または FAIL - 実行したコマンド、終了コード、テストの件数 - 失敗したテスト名と、エラーメッセージの要点 - 変更禁止の確認対象ごとの変更の有無
ポイントは3つです。
EditやWriteを外し、「修正しない」と指示する：確認係の役割を、テストの実行と報告に絞る- PASSの条件を具体的に決める：「良さそうです」のような曖昧な答えや、テストが0件なのに成功扱いになる事態を防ぐ
- 失敗の理由まで返させる：「どこが、なぜ駄目か」が分かるほど、作る係は少ない回数で直せる
ただし、テストの実行に必要なBash（シェル）は、シェル経由でファイルを書き換えることもできます。この設定だけで完全な読み取り専用になるわけではありません（下の「試した結果」で、実際にこれが起きました）。最初は手動で確認するモード（Manual）で動かし、確認係が実行するコマンドを自分の目で見ましょう。書き込みを技術的に禁止したい場合は、コマンドを検証するフックや実行環境の制限を追加します（ハーネスエンジニアリングの回で扱います）。
公式ドキュメントでは、セッションを始めたときに.claude/agents/フォルダがすでにあれば、ファイルを保存してから数秒で読み込まれると説明されています。今回初めてこのフォルダを作った場合は、Claude Codeを再起動してください。そのうえで「test-checkerサブエージェントでテストを確認して」と頼み、判定が返ってくれば準備完了です。
試した結果：Step 2とStep 3のファイルを置いてからClaude Codeを起動し、「test-checkerサブエージェントでテストを確認して」と頼みました。編集部の環境（2026年10月10日、Windows 11、Claude Code v2.1.296、Opus 5.5、手動で確認するモード）では、次のようになりました。
- Claudeは
test-checkerをバックグラウンドで起動し、確認係はfrontmatterの指定どおりclaude-haiku-5-5で動いた - 確認係は
npm testとgit status --short --untracked-files=allを実行した。手動で確認するモードなので、コマンドごとに実行の確認が表示された - 報告は
## 判定: FAILで始まり、実行したコマンド、終了コード（1）、テストの件数（4件中2件失敗）、失敗したテスト名とエラーの要点、変更禁止の確認対象ごとの変更の有無がそろっていた - テストの設定ファイルについては、「jest や vitest の設定ファイルは見当たらないため、
package.jsonを対象として確認しました」と書き、FAILにはしなかった
一方で、記事の想定と違う動きもありました。確認係がPROGRESS.mdを書き換えたのです。確認係はEditとWriteを持っていませんが、Bashでcat > PROGRESS.md <<'EOF'を実行し、「CLAUDE.md の指示どおり PROGRESS.md に今回の結果を記録します」と説明していました。Step 2でCLAUDE.mdに足した「作業の最後に PROGRESS.md を更新すること」が、確認係にも効いたと考えられます。編集部はこのコマンドを、中身がPROGRESS.mdへの記録だけだったため許可しました。
確認係に記録を書かせたくない場合は、CLAUDE.mdの1行を「作業の最後に PROGRESS.md を更新すること（test-checker は更新しない）」のように対象を絞る方法が考えられます。これは編集部の提案で、試していません。手動で確認するモードで、確認係が実行するコマンドを読んでから許可するのが確実です。
Step 4：/goalでループを回す
いよいよループを動かします。Claude Codeの入力欄に次のように入力します。
/goal TASK.md と PROGRESS.md を読み、まず test-checker サブエージェントを呼ぶ。FAIL なら原因を確認し、許可された src/ だけを修正する。修正後は毎回 test-checker を呼び、最新の判定・終了コード・テストの件数・TASK.md で指定した変更禁止の対象の変更の有無を会話に示す。PROGRESS.md を更新し、更新した内容も会話に示す。最新の確認が PASS で、変更禁止の対象に変更がなく、今回の PROGRESS.md の更新を示せたら完了とする。または評価済みのターンが 15 に達したら、未完了の点を報告して停止する。毎ターン、上限に対する進み具合を報告する。
これで、次の流れが自動で繰り返されます。
Claude（作る係）がTASK.mdとPROGRESS.mdを読む
↓
test-checker（確認係）がテストを実行し、判定を報告する
↓ FAILなら
Claudeがsrc/を修正し、もう一度test-checkerに確認させる
↓
Claudeが確認係の報告とPROGRESS.mdの更新内容を会話に示す
↓
/goalの判定役が、会話の内容から「条件を満たしたか」を判断する
↓ 満たしていなければ
Claudeが判定理由を手がかりに、次の修正へ進む
条件文の上では、最初の確認ですでにPASSなら、コードは直さず、進捗の記録だけを更新して完了する指示になっています（今回は最初の確認がFAILだったので、この場合は試していません）。
試した結果：Step 3の確認のあと、同じセッションで上の/goalを一字一句そのまま送りました。編集部の環境（2026年10月10日、Windows 11、Claude Code v2.1.296、Opus 5.5、手動で確認するモード）では、次の流れで終わりました。
- Claudeが「ゴールを設定しました。上限15ターンのうち1ターン目です。」と答え、
test-checkerを呼んだ。判定はFAIL（終了コード1、4件中2件失敗） - Claudeが
src/routes/todos.jsを2か所直した（POSTのタイトルが空のときに400を返す、PATCHに認証の確認を足す） - もう一度
test-checkerを呼び、判定はPASS（終了コード0、4件すべて合格）。test/とpackage.jsonは変更なし - Claudeが
PROGRESS.mdを書き直し、更新した内容を会話に示した - 画面に
✔ Goal achieved (1m · 1 turn · 7.3k tokens)と表示されて止まった
修正は1回で、変更禁止の対象（test/、package.json）は守られました。手動で確認するモードなので、テストの実行、git status、ファイルの編集のたびに確認が表示され、編集部が中身を見て許可しました（ループの間の確認は7回）。
1つ気になる点がありました。Claudeは最後に「ターン数は15のうち3」と報告しましたが、画面の表示は「1 turn」でした。会話の記録でも、判定役の評価は1回（iterations: 1）でした。確認係の結果を待つ間にClaudeの応答がいったん終わったのを、Claudeは1ターンと数えた可能性があります。原因は切り分けていませんが、Claudeが報告する回数と判定役が数える回数は一致しないことがある、と考えておくのが安全です。
条件の書き方には、公式ドキュメントが示すコツがあります。
- 終わった状態を1つ、測れる形で書く：「最新の確認がPASS」「エラーが0件」
- どう証明するかを書く：「確認係の判定と終了コードを会話に示す」
- 変えてはいけないものを書く：「test/配下は変更しない」
ここで大事なのは、公式ドキュメントの説明では、/goalの判定役は自分でコマンドを実行したりファイルを読んだりせず、会話に出てきた内容だけで判定することです。今回の会話の記録でも、判定役の判定理由は、会話に出てきた確認係の判定、終了コード、テストの件数、PROGRESS.mdの更新内容を根拠に挙げていました。確認係の報告はClaudeに返ってきますが、PROGRESS.mdを更新したかどうかは、Claudeが会話に示さない限り判定役には分かりません。だから条件文で「会話に示す」ことまで指示しています。過去のPASSだけで完了にしないこともポイントです。
上限についても注意があります。公式ドキュメントによると、「15ターンで停止」のような回数や時間の上限は条件に書けますが、これはClaudeの進み具合の報告をもとに判定役が判断する方式で、厳密な回数カウンターによる強制停止ではありません。上で見たように、Claudeの数え方と画面の表示がずれることもあります。最初は/goalだけを入力して状況（経過時間、評価したターン数、直近の判定理由）を見ながら試し、止めたいときは/goal clearで止めます。上限で止まった場合は未完了です。残った失敗を確認してください。今回は1回で完了したため、上限での停止、/goalだけの入力、/goal clearは試していません。
また、/goalは権限の設定を変えません。手動で確認するモード（Manual）なら、許可済みでないテストのコマンドなどを実行する前に承認を求められます。最初はこれで構いません。allowやサンドボックスの設定によっては、確認なしで実行されることもあります。なお、2026年10月5日時点の公式情報では、Claude Code v2.1.283以降の対話型のターミナルとVS Codeでは、起動時の既定のモードがautoと説明されています（設定や利用条件によって変わります。今回は起動時にモードを指定したため、既定のモードは確かめていません）。このループを初めて試すときは、起動時にclaude --permission-mode defaultと指定するか、Shift+Tabで画面下の表示を⏸ manual mode onにしてから始めてください。
Step 5：慣れたら/loopで定期的に見張らせる
1回のループが安定して動くようになったら、時間で起動する見張りを足せます。
/loop 1h test-checker でテストを実行し、最新の判定と実行時刻を PROGRESS.md に記録する。FAIL なら原因を「人間に確認してほしいこと」にも書く。コードは修正しない
確認係は記録を書かない役割なので、PROGRESS.mdに書き込むのは親のClaudeです。PASSのときも実行時刻を残しておくと、「ちゃんと動いていたか」を後から確かめられます。
この例では、あえて修正はさせず、記録だけにしています。定期実行は人が見ていない時間に動くので、最初は読み取りと記録に留めるのが安全です。
公式ドキュメントによると、/loopには知っておくべき性質があります。
- Claude Codeを開いている間だけ動く：ターミナルを閉じると実行されなくなる（期限が切れていないタスクは、セッションを再開したときに復元される場合がある）
- 繰り返しのタスクは7日で自動的に終了する：消し忘れたループが動き続けない設計
- 自分で止めるときは、Claudeに「スケジュールしたタスクを止めて」と頼めばよい
PCを閉じていても毎朝動かしたい場合は、/scheduleでクラウドのRoutinesに登録できます。ただし最短間隔は1時間で、手元のフォルダではなくリポジトリを新しく取得した環境で動く点が/loopと異なります。慣れてからの発展として考えてください（今回は試していません）。
試した結果：Step 4のあと、同じセッションで上の/loopを一字一句そのまま送りました（2026年10月10日、Windows 11、Claude Code v2.1.296、Opus 5.5、手動で確認するモード）。1時間待たずに、設定されたことと止め方を確かめました。
- 最初に、クラウドで動かすかを聞かれた：間隔が1時間以上だったため、「This loop stops when you close this session. Set it up as a cloud schedule instead so it keeps running?」という質問が表示され、「Cloud schedule (recommended)」と「This session only」から選ぶ形になりました。記事の手順はこのセッションの中で動かす前提なので、「This session only」を選んでください。編集部もこちらを選びました
- 登録と同時に1回目が動いた：毎時7分に動く繰り返しのタスクとして登録され（
7 * * * *）、待たずに1回目の確認が実行されました。確認係の判定はPASSで、親のClaudeがPROGRESS.mdに「定期確認（最新）」という見出しを新しく作り、実行時刻と判定を書きました。コードは修正していません - 登録の結果には、記事の説明と同じ性質が書かれていた：会話の記録には「Session-only (not written to disk, dies when Claude exits). Auto-expires after 7 days.」とありました。このセッションだけのタスクはディスクに書かれない、と出ているので、セッションを再開したときに復元されるのは、これとは別の登録方法の場合と考えられます（再開は試していません）
- 止め方：「
スケジュールしたタスクを止めて」と頼むと、Claudeがタスクを取り消し、会話の記録にCancelled job 43e13212.と残りました。そのあとセッションも閉じました
Part 4：初心者がつまずく4つの落とし穴
ループは、失敗するときに静かに失敗します。よくある4パターンを先に知っておきましょう。
| 落とし穴 | 何が起きるか | 防ぎ方 |
|---|---|---|
| 「できました」を信じる | AIが早めに完了を宣言し、未完成のまま止まる | 作る係と確認係を分け、確認係の最新のPASSだけを完了とする |
| 停止条件が柔らかい | 「十分良くなったら止めて」は守られず、費用が膨らむ | 「15ターンで停止」のように数で上限を書き、/goalで状況を見ながら必要なら/goal clearで止める |
| テストをずるで通す | テストファイルや設定を書き換えて合格させる | 「test/とテスト設定は変更しない」を、TASK.mdと確認項目の両方に入れる |
| 中身を理解しなくなる | ループが速く進むほど、自分が理解していないコードが増える | 合格した変更は、最後に人間が差分を読む |
今回の試験（2026年10月10日）では、表の4つは起きませんでした。修正はsrc/だけで、テストやpackage.jsonを書き換えて合格させることもありませんでした。ただし、1回だけの、2件の失敗を直す小さな題材での結果です。表の4つと関係して、次の2つは起きました。
- 役割の境界がずれた：確認係が、CLAUDE.mdの指示に従ってBashで
PROGRESS.mdを書き換えた（Step 3） - 回数の数え方がずれた：Claudeは「15のうち3」と報告し、画面と判定役の記録は1回だった（Step 4）
最後の項目は特に大事です。ループは、考える手間を省くための道具ではありません。確認の手間を減らし、人間が判断すべき部分に集中するための道具です。
Part 5：権限は少しずつ広げる
ループが動いた瞬間に、プッシュや外部への送信まで任せたくなります。しかし、権限は段階的に広げるのが安全です。
| 段階 | AIに任せること | 例 |
|---|---|---|
| 1 | 読むだけ | テスト結果やログを読んで要約する |
| 2 | 下書きを書く | 報告書や修正案をファイルに書くだけ |
| 3 | 隔離した場所で編集する | 作業用ブランチの中だけでコードを直す |
| 4 | 外部への操作を準備する | プルリクエストの文面を作るが、送信はしない |
| 5 | 人間が承認した操作を実行する | 承認後にマージする |
| 6 | 限定した操作を自動で行う | 上限と記録を付けて、決まった作業だけ自動完了する |
段階1〜2の読み取りと下書きだけでも、ループは十分に役立ちます。毎朝テスト結果を要約して「人間に確認してほしいこと」を書き出すだけで、確認の時間はかなり減ります。Part 3のコード修正は段階3にあたるため、必ず練習用のブランチで試しましょう。
結論：最初の一歩は「テストが通るまで」の小さなループ
ループエンジニアリングは、難しい新技術ではありません。人間が手でやっていた「やってみる→確かめる→直す→終わったら止める」を、AIに任せられる形に書き出すことです。
今日から試すなら、次の順番がおすすめです。
- テストのように合否がはっきりする小さな仕事を1つ選び、練習用のブランチを用意する
TASK.mdとPROGRESS.mdを作る- コードを修正しない役割の確認係のサブエージェントを作り、PASSの条件を決める
- 会話に示す証拠と上限を書いて
/goalを実行する - 安定したら、記録だけをする
/loopを足す
ループを作るときに大事なのは、AIの賢さよりも確認の仕組みです。「何ができたら合格か」を自分の言葉で書けるようになれば、Claude Codeは毎回指示を待つ道具から、自分で確かめながら仕事を進めるエージェントに変わります。
参考資料
- Claude Code Docs「Keep Claude working toward a goal」 https://code.claude.com/docs/en/goal
- Claude Code Docs「Run prompts on a schedule」 https://code.claude.com/docs/en/scheduled-tasks
- Claude Code Docs「Create custom subagents」 https://code.claude.com/docs/en/sub-agents
- Claude Code Docs「Routines」 https://code.claude.com/docs/en/routines
- Claude Code Docs「Configure permissions」 https://code.claude.com/docs/en/permissions
- Addy Osmani「Loop Engineering」 https://addyosmani.com/blog/loop-engineering/
