{"content_id":"z9qcc6lzi3","slug":"claude-code-loop-engineering-guide","locale":"ja","schema_type":"TechArticle","category":"tutorial","category_name":"チュートリアル","title":"Claude Code Loop Engineeringガイド：4つのLoopと安全な自動化設計","summary":"Claude CodeのLoopは、エージェントが観察・行動・検証を終了条件まで繰り返すようにする制御構造だ。4種類のLoopの違いとともに、検証証拠、強制終了、冪等性、コスト、最小権限を含む実務上の設計方法を説明する。","author":{"name":"Injoys 編集部","url":"https://injoys.com/ko/about"},"key_points":["Claude CodeのLoopはコードのループ文ではなく、観察・行動・検証を終了条件まで繰り返すエージェント実行構造だ。","Turn-basedは検証手順、Goal-basedは終了判断、Time-basedは再実行のタイミング、Proactiveは作業開始とオーケストレーションをシステムに委ねる。","優れたLoopには、測定可能な完了条件、外部の検証証拠、強制終了、冪等性、最小権限が備わっている必要がある。","`/goal`評価モデルは、対話に現れた証拠だけを判断するため、テスト出力、終了コード、変更範囲を明確に報告する必要がある。","決定論的な変換はScriptで処理し、Dynamic Workflowと複数のAgentは、実際の並列性が必要な大規模作業にのみ適用すべきだ。"],"content_markdown":"Claude CodeのLoopは、単にモデルを長時間実行する機能ではない。核心は、確率的に行動するAI Agentの周囲に **Trigger, Verifier, Success condition, Hard stop, Permission boundary** を配置し、反復作業を制御可能なシステムにすることにある。本稿では、Turn-based、Goal-based、Time-based、Proactive Loopの違いと実務上の設計原則を一度に整理する。\n\n## 1. Claude CodeにおけるLoopとは何か\n\nここでいうLoopは、プログラミング言語の`for`や`while`文ではない。Claude Codeチームが説明するLoopは、Agentが現在の状態を観察し、行動し、結果を検証した後、終了条件が満たされるまで再び作業する実行構造だ。\n\n```text\n作業開始\n  ↓\n状態とコードの把握\n  ↓\n計画策定\n  ↓\nコード修正またはツール実行\n  ↓\nテスト・検証\n  ↓\n完了条件を満たしたか？\n  ├─ いいえ: 次の反復\n  └─ はい: 終了および結果報告\n```\n\nLoopを区別するときは、次の4つの質問が役に立つ。\n\n1. 何が作業を開始させるのか？\n2. 何が作業を終了させるのか？\n3. どのClaude Code機能が反復を制御するのか？\n4. どのような種類の作業に適しているのか？\n\nすべての作業を複雑なLoopにする必要はない。1つのファイルの誤字修正や単純な名前変更のように、結果をすぐ確認できる作業には通常のプロンプトのほうが効率的だ。Loopは、複数回の観察・修正・検証が実際に必要な場合にのみ選択すべきだ。\n\n## 2. 4種類のLoopタイプ比較\n\n| タイプ | 開始条件 | 終了条件 | 主に使用する機能 | 適した作業 | 人が委ねる責任 |\n|---|---|---|---|---|---|\n| Turn-based | ユーザーのプロンプト | Claudeが完了したと判断するか、追加情報が必要なとき | 通常の会話、Skills、テスト・ブラウザツール | 短く一回性の実装・修正 | 反復検証手順 |\n| Goal-based | ユーザーが完了条件を指定 | 評価モデルが条件達成を確認するか、ユーザーが中断 | `/goal`、必要に応じてAuto mode | テスト・ビルド・マイグレーションのように完了状態を測定できる作業 | 終了判断 |\n| Time-based | 指定した時間・間隔・スケジュール | ユーザーがキャンセルするか、外部作業が終わる | `/loop`、`/schedule` | PR・CI・デプロイ監視、定期要約、状態Polling | 次の実行時点 |\n| Proactive | スケジュール、API、GitHubイベントなど | 個別作業の目標達成、Routineの無効化 | Routines、`/goal`、Skills、Dynamic Workflows、Auto mode | イシュー分類、バグ対応、大規模マイグレーションなどの継続業務 | 作業発見、プロンプト実行、オーケストレーション |\n\nこの分類の核心は、「AIがどれだけ賢いか」ではなく、**人がどの制御責任をシステムに委ねるか**だ。Turn-basedでは人が次のプロンプトを作り、Goal-basedでは完了判断を委ね、Time-basedでは再実行時点を委ねる。Proactive段階では、作業発生を検知し、適切なプロンプトを実行する責任までシステムへ移動する。\n\n## 3. Turn-based Loop: 検証手順を委ねる\n\nTurn-based Loopは、ほとんどの開発者がClaude Codeを使う基本形だ。\n\n```text\nHuman → Claude → Human → Claude\n```\n\nユーザーが依頼すると、Claudeは関連ファイルを探し、コードを修正し、テストし、結果を報告する。内部的には複数回の観察・行動・検証が起きることがあるが、次の作業を開始する権限はユーザーに残っている。\n\n### コード修正と機能完成は異なる\n\nClaudeが「実装とテストを完了した」と報告しても、実際の製品では次の問題が残ることがある。\n\n- ボタンをクリックしても状態が変わらない。\n- ブラウザコンソールにエラーが発生する。\n- モバイルレイアウトが崩れる。\n- アクセシビリティ属性が抜けている。\n- テストは通るが、実際のブラウザフローは失敗する。\n- 変更と無関係なファイルまで修正された。\n\nしたがって完了基準は、「コードを変えた」ではなく「外部証拠で動作を確認した」でなければならない。\n\n### `SKILL.md`で検証を再利用する\n\nSkillは、繰り返し使う指示と手順を`SKILL.md`に保存する方式だ。Claudeが関連性を判断して自動で読み込むか、`/skill-name`で直接実行できる。長い運用手順を常に`CLAUDE.md`に入れるより、必要な瞬間にだけSkillをロードするよう分離すれば、コンテキストをより効率的に使える。\n\n```markdown\n---\nname: verify-ui-change\ndescription: UI変更を完了扱いにする前に、実際の実行環境で検証する。\n---\n\n# UI変更の検証\n\n1. 開発サーバーを実行する。\n2. 変更された画面をブラウザで開く。\n3. 新しいコントロールを実際に操作する。\n4. 期待した状態変化が発生するか確認する。\n5. ブラウザコンソールの新しいエラーと警告を確認する。\n6. アクセシビリティおよび主要なパフォーマンス指標を点検する。\n7. 失敗した場合は修正後、最初から再度検証する。\n8. 実行したコマンド、結果、スクリーンショットなどの証拠を報告する。\n```\n\n良いSkillは、抽象的なお願いではなく実行可能なチェックリストを含む。「より慎重に検討する」より「`npm test`が終了コード0か確認する」のほうが、はるかに強いルールだ。\n\n### 検証証拠の強度\n\n| 証拠 | 信頼度 | 理由 |\n|---|---:|---|\n| 「正常だと思われる」というAgentの説明 | 低い | 実行結果ではなく推論にすぎない |\n| コードDiffと静的レビュー | 中程度 | 変更内容は見えるがRuntime動作は確認できない |\n| 実際のテスト出力と終了コード | 高い | 再現可能な外部結果が存在する |\n| ブラウザ操作、スクリーンショット、コンソール・パフォーマンス結果 | 非常に高い | ユーザー経路とRuntime状態を直接検証する |\n| 独立したReview AgentとCIが同じ結論を出す | 非常に高い | 実装Agentの自己確証バイアスを減らす |\n\nClaude Code公式ドキュメントには、実行中のアプリケーションを確認する`/run`、変更を実際の実行環境で検証する`/verify`のようなbundled Skillも説明されている。プロジェクトの実行方式が複雑なら、チーム固有のSkillに正確な開始コマンド、環境変数、データ準備手順を記録するほうが安全だ。\n\n## 4. Goal-based Loop: 終了判断を委ねる\n\nGoal-based Loopでは、「もう一度作業するか」をユーザーが毎回決めない。ユーザーは完了状態を定義し、Claudeはその条件が満たされるまで複数のTurnを続ける。\n\n```text\nユーザーがGoalを指定\n  ↓\nClaude作業Turn\n  ↓\n別の評価モデルが完了条件を確認\n  ├─ 未達成: 理由を次のTurnに伝達\n  └─ 達成: Goal終了\n```\n\n`/goal`はClaude Code v2.1.139以上で使用できるよう文書化されている。1つのセッションでは1つのGoalだけを有効化できる。\n\n### 評価モデルが実際に見るもの\n\n各Turnが終わると、別のsmall fast modelが完了条件と会話内容を見て、`達成`または`未達成`を判断する。デフォルト設定はHaiku系の評価モデルだ。重要な制限は、評価モデルがファイルを直接読んだり、テストを別途実行したりしない点だ。\n\nしたがって、作業を行ったClaudeが次の証拠を会話に明確に残さなければならない。\n\n- 実行したコマンド\n- テスト数と成功・失敗結果\n- 終了コード\n- ビルド結果\n- 変更ファイル一覧\n- 残っている失敗原因\n- 範囲制約を守ったという確認結果\n\n評価モデルは「実際に何が起きたか」ではなく、「会話にどのような証拠が示されたか」を判断する。\n\n### 良いGoalの4要素\n\n良いGoalは次の4要素を含む。\n\n1. **測定可能な成功条件**: テスト通過、ビルド成功、キューが空になる、スコア閾値達成\n2. **検証方法**: どのコマンドやツールで成功を証明するかを明示\n3. **変更範囲の制約**: 修正可能なディレクトリ、禁止ファイル、許可されたSide effect\n4. **強制終了条件**: 最大Turn、最大時間、連続失敗回数、権限エラー時の中断\n\n```text\n/goal auth関連テストとlintがすべて成功し、\ngit diffにはsrc/authと関連テストファイルのみ含まれていなければならない。\n各Turnで実行結果と終了コードを報告する。\n最大12ターンまたは45分に達したら中断し、残った失敗を整理する。\n```\n\n`/goal`自体の核心的な終了条件は、評価モデルの成功判定またはユーザーの`/goal clear`だ。Turn・時間上限を強制するには、Goal条件の中に明示しなければならない。\n\n### 良い条件と悪い条件\n\n| 良い条件 | 悪い条件 |\n|---|---|\n| `npm test`が終了コード0で終わる | コードを完璧にする |\n| 認証関連テスト48個がすべて通過する | ユーザー体験を最大限改善する |\n| すべてのAPI呼び出し箇所が新しいインターフェースに変更され、ビルドが成功する | より良い構造にリファクタリングする |\n| 処理対象イシューキューが空になり、各イシューに結果が記録される | 可能な限り多くのイシューを処理する |\n\n曖昧な目標は、早すぎる終了や終わりのない改善の反復につながることがある。\n\n### 状態確認と中断\n\n- `/goal`: 有効条件、実行時間、評価Turn数、トークン使用量、最近の評価理由を確認\n- `/goal clear`: 有効なGoalを中断\n- 新しいGoal設定: 既存Goalを置き換え\n- `--resume`または`--continue`: 未完了Goalの復元が可能\n\n再開時に条件は維持されるが、Turn数、時間、トークンの基準線は初期化されることがあるため、Hard stopを運用指標と併せて管理するのがよい。\n\n### `/goal`と権限は別物だ\n\n`/goal`は次のTurnを自動的に開始するだけで、ツール権限を広げるわけではない。ファイル書き込み、テストコマンド、Git作業が承認対象なら、Goal中でも承認が必要になることがある。\n\n無人実行にはAuto modeを併用できるが、Auto modeは「すべてのツールを無条件に許可する」機能ではない。分類器が破壊的、または元に戻しにくい、あるいは信頼境界の外を対象とする作業をブロックし、明示的な`ask`と`deny`ルールは分類器より先に適用される。\n\n## 5. Time-based Loop: 再実行時点を委ねる\n\nGoal-based Loopが「いつ止まるか」を扱うなら、Time-based Loopは「いつ再び実行するか」を扱う。外部システムの状態が時間とともに変化する作業に適している。\n\n- PRに新しいレビューが付いたか確認\n- CIまたはデプロイが終わったか確認\n- 長時間ビルドの状態確認\n- 毎日のSlackメッセージ要約\n- イシューキューの新規項目確認\n\n### `/loop`: 現在のセッション内で反復実行\n\n```text\n/loop 10m 現在のPRを確認して新しいレビューを反映し、\n失敗したCIがあれば原因を分析して修正する。\n```\n\n現在のドキュメントで説明されている主な形式は次のとおりだ。\n\n| 入力 | 動作 |\n|---|---|\n| `/loop 5m \u003cprompt\u003e` | 指定した固定間隔でPromptを実行 |\n| `/loop \u003cprompt\u003e` | Claudeが反復ごとに間隔を選択 |\n| `/loop` | built-inメンテナンスPromptまたはプロジェクトの`loop.md`を実行 |\n| `/loop 20m /review-pr 1234` | 許可されたSkillを指定間隔で再実行 |\n\n`/loop`は現在のClaude Codeセッションに依存する。コンピューターとセッションが実行中でなければならず、新しい会話を始めるとセッション範囲の作業は消える。未期限切れの作業は`--resume`または`--continue`で復元できるが、反復作業は基本的に作成後7日で期限切れになる。逃した周期をすべて遡って実行することもない。\n\nセッションSchedulerにはJitterが適用されることがあるため、「正時に必ず実行」しなければならない運用要件には適さない場合がある。\n\n### `/schedule`: Anthropic管理Cloud Routine\n\n`/schedule`はPromptとRepository、Connector、Triggerを束ね、Anthropic管理インフラで実行するRoutineを作る。ノートPCを閉じても実行でき、公式ドキュメントではResearch Previewとして案内されている。\n\nRoutineがサポートするTriggerは次のとおりだ。\n\n- 反復スケジュール\n- 特定の未来時点の一回限りのスケジュール\n- 認証済みAPI呼び出し\n- GitHub Pull requestまたはReleaseイベント\n\n1つのRoutineに複数のTriggerを接続できる。たとえばPR Review Routineを毎晩実行しつつ、`pull_request.opened`イベントにも反応させることができる。\n\n### `/loop`と`/schedule`の比較\n\n| 区分 | `/loop` | `/schedule` Routine |\n|---|---|---|\n| 実行場所 | 現在のコンピューターとセッション | Anthropic管理Cloud |\n| コンピューター終了後の実行 | 一般的に不可 | 可能 |\n| 開いているセッション | 必要 | 不要 |\n| ローカルの未コミットファイル | アクセス可能 | アクセス不可、実行ごとにRepositoryを新たにClone |\n| 最小間隔 | 公式ドキュメント基準1分 | 公式ドキュメント基準1時間 |\n| 持続性 | セッション中心、反復作業は7日で期限切れ | アカウントに保存されるRoutine |\n| 権限Prompt | 現在のセッションポリシーを継承 | 対話型承認なしで自律実行 |\n| 適した用途 | 短いPR・デプロイ監視 | 継続的な運用自動化 |\n\n### PollingよりEventが優れている場合\n\n変更が少ないPRを1分ごとに確認すると、ほとんどの実行は何もせず終了する。外部システムがイベントを送れるなら、次の構造のほうが効率的だ。\n\n```text\nCI失敗またはPR更新\n  ↓\nGitHub TriggerまたはRoutine API\n  ↓\n必要なときだけClaude実行\n```\n\nEventベースの設計は遅延を減らし、不要なモデル呼び出しとトークン消費を減らす。Pollingが避けられないなら、実際の変更頻度に合わせて間隔を伸ばし、長時間変化がないときはBackoffを適用するのがよい。\n\n### 時間ベース作業の必須条件\n\n1. **冪等性**: 同じイベントを複数回受け取っても、重複コメント、重複PR、重複デプロイが発生してはならない。\n2. **処理状態**: 最後に処理したEvent ID、Commit SHA、Review Comment IDなどを記録しなければならない。\n3. **終了状態**: PR merge・close、Queue empty、Deploy success・rollbackのように終了を判定できなければならない。\n4. **書き込み範囲**: コメント許可、Merge禁止、`claude/*` BranchのみPushなど、Side effectを制限しなければならない。\n5. **失敗処理**: 外部サービス障害、認証期限切れ、Rate limit、権限不足時の再試行とEscalationルールが必要だ。\n\n## 6. Proactive Loop: 作業発見とオーケストレーションを委ねる\n\nProactive Loopは1つのコマンドではなく、複数の機能を組み合わせた常時自動化アーキテクチャだ。\n\n```text\nTrigger\n+ Goal\n+ Skills\n+ Dynamic Workflow\n+ Auto mode\n+ Repository・Connector・Browser・CIツール\n```\n\n人がリアルタイムでプロンプトを入力しなくても、新しい作業が検知され、処理され、検証され、結果が報告される。\n\n### 例: バグフィードバックの自動処理\n\n```text\nGitHub IssueまたはSlackフィードバック受信\n  ↓\n重複・優先順位・再現可能性の分類\n  ↓\n再現テスト作成\n  ↓\n候補解決策の探索\n  ↓\n選択した解決策の実装\n  ↓\n独立したReview Agentが反例を探索\n  ↓\nテスト・ビルド・セキュリティ検証\n  ↓\nDraft PRと結果報告\n```\n\n構成要素ごとの責任は次のとおりだ。\n\n| 構成要素 | 責任 |\n|---|---|\n| Triggerまたは`/schedule` | 新しい作業を開始する時点を決定 |\n| `/goal` | 今回の実行で何が完了状態かを定義 |\n| Skill | 再現、実装、検証、報告手順の標準化 |\n| Dynamic Workflow | 複数Subagentの並列実行と条件分岐 |\n| Auto mode | 許可されたツール呼び出しを承認待ちなしで実行 |\n| Permission policy | 禁止・承認・自動許可範囲を固定 |\n\n### Dynamic WorkflowとWorktree\n\nDynamic Workflowは、Claudeが作成したJavaScriptオーケストレーションScriptをRuntimeが実行する構造だ。通常のSubagent呼び出しでは、ClaudeがTurnごとに次のAgentを選ぶが、WorkflowではLoop、並列処理、分岐、中間結果の保存がScriptに移る。\n\n```text\nWorkflow Script\n  ├─ Agent A: 要件分析\n  ├─ Agent B: テスト設計\n  ├─ Agent C: 実装候補探索\n  ├─ Agent D: セキュリティレビュー\n  └─ Judge: 証拠ベースの比較\n```\n\n中間結果がメイン会話ContextではなくScript変数に残るため、大規模作業をより再現可能に組織できる。現行ドキュメントには、同時に最大16個のAgent、実行あたり最大1,000個のAgentというRuntime上限が明記されているが、製品Preview段階の制限は変わる可能性がある。\n\n複数の実装候補を同時に試す必要があるなら、Git Worktreeで作業空間を分離できる。\n\n```text\nrepo/\nworktree-solution-a/\nworktree-solution-b/\nworktree-solution-c/\n```\n\n各Agentが独立したBranchとディレクトリで作業すれば、同じファイルを同時に上書きする問題を減らせる。Judge Agentは、要件充足、テスト結果、回帰リスク、変更範囲、複雑度、性能、セキュリティ、既存アーキテクチャとの一貫性を基準に候補を比較しなければならない。\n\n### Agentが多ければ常に良いわけではない\n\n並列性のない作業でAgent数だけを増やすと、コストと遅延が増える。複数のAgentが同じ誤った仮定を共有すれば、エラーが拡大することもある。\n\nDynamic Workflowが適している場合は次のとおりだ。\n\n- 数百ファイルに同じ変換を適用するMigration\n- コードベース全体のセキュリティ・品質Audit\n- 独立した複数観点のPlan比較\n- 多くの項目を分割処理し、相互検証しなければならないResearch\n- 1つのAgentのContextにすべての中間結果を入れるのが難しい作業\n\n小さなバグ修正、1ファイルのリファクタリング、単純なテスト追加には、通常のTurn-based Loopや`/goal`のほうがよい。\n\n## 7. Loopでコード品質を維持するシステム\n\nLoop結果の品質は、モデル自体だけでなく、モデル周辺の検証システムに大きく左右される。\n\n### 7.1 コードベースを整える\n\nClaudeは既存コードのパターンを強く踏襲する。古いAPI、重複実装、不明確なテスト構造、巨大なモジュール、一貫しない例外処理ルールがあると、Loopがその問題を素早く複製してしまうことがある。\n\n必須の基盤は次のとおりだ。\n\n- Formatterとlint\n- 明確なディレクトリとモジュール境界\n- 信頼できるUnit・Integration・E2E Test\n- 使用中のAPIとDeprecated APIの区別\n- プロジェクト別の開発ルール\n- 再現可能なBuild・Dev環境\n\n### 7.2 変更タイプ別Definition of Doneを作る\n\n| 変更タイプ | 最小検証 |\n|---|---|\n| API | 契約テスト、後方互換性、Schema・ドキュメント例の更新 |\n| Frontend | 実際のブラウザ操作、コンソールエラー、アクセシビリティ、レスポンシブ画面 |\n| Database | Forward・Rollback Migration、Lock範囲、実行計画 |\n| Dependency | Build、主要回帰テスト、License・Security確認 |\n| Infrastructure | Plan Diff、最小権限、Rollback、秘密情報露出検査 |\n\nこの基準はPromptに毎回長く繰り返すより、Skill、Hook、Script、CI Ruleとして固定するほうがよい。\n\n### 7.3 最新ドキュメントと正確なバージョンを提供する\n\nLoopは誤った仮定を何度も繰り返すことがある。プロジェクトで使う正確なVersion、公式ドキュメント、内部Architecture文書、API仕様、Migration Guide、承認済みの例を簡単に見つけられるようにしなければならない。\n\n### 7.4 実装AgentとReview Agentを分離する\n\n実装したAgentは、すでに選択した設計と推論の影響を受けている。新しいContextのReview Agentは、次の質問をより独立して投げかけることができる。\n\n- テストを弱めて通したのではないか？\n- 範囲外ファイルを変更していないか？\n- セキュリティ境界が破られていないか？\n- 失敗経路と境界値テストが抜けていないか？\n- 既存機能に回帰が生じていないか？\n\nReview Promptは、「良い点を要約せよ」より「実装が間違っているという仮定で反例を探し、各指摘に再現証拠を付けよ」のように書くほうが効果的だ。\n\n### 7.5 個別の失敗をシステム改善につなげる\n\n同じエラーが繰り返されるなら、その結果だけを修正してはいけない。失敗タイプが再発しにくくなるよう、次のいずれかを変える必要がある。\n\n- Regression Test追加\n- Skill検証手順の強化\n- `CLAUDE.md`ルール追加\n- Hookまたはlint Rule追加\n- 権限Deny Rule追加\n- Goalの完了条件強化\n- Review Checklist補完\n\n良いLoop Engineeringとは、1回の失敗を直す作業ではなく、**その種類の失敗が再び出にくいシステムを作る作業**だ。\n\n## 8. Tokenとコスト管理\n\nLoopのコストは単一Promptより大きく増えることがある。\n\n```text\n総コスト ≈\nメインAgent Turnコスト\n+ Goal評価コスト\n+ Subagentコスト\n+ Workflow反復コスト\n+ ツール結果を読むContextコスト\n+ 時間ベース実行頻度\n```\n\n正確な課金はPlan、Model、Providerによって異なるが、コスト構造を決める原理は同じだ。\n\n### コストを減らす実務原則\n\n1. **小さな作業にはLoopを使わない。** 誤字、名前変更、1ファイルの型エラーは単一Turnで処理する。\n2. **成功条件とHard stopを併せて置く。** 成功、最大Turn、最大時間、連続失敗、権限エラーをすべて考慮する。\n3. **大規模Workflowは小さい範囲で試す。** 5個のファイル、1つのディレクトリ、一部のIssueでコストと品質を検証した後に拡大する。\n4. **決定論的作業はScriptで処理する。** AST置換、JSON変換、Formatting、固定形式生成は、検証済みのScriptのほうが安く再現可能だ。\n5. **Polling周期を実際の変更頻度に合わせる。** 可能ならEvent Triggerを使う。\n6. **進行中の使用量を観察する。** `/usage`、`/goal`、`/workflows`でSkill・Subagent・MCP・Turn・Token使用量を確認する。\n7. **同じエラーが繰り返されるなら、再試行を続けない。** 連続失敗上限を置き、人にEscalationする。\n\n### ModelとEffortは別のレバーだ\n\n- **Model**は基本的な推論能力と解決可能な問題の範囲を変える。\n- **Effort**は読むファイル数、使用するツール数、検証の幅、複数段階作業をどこまで最後まで押し切るかを変える。\n\nClaudeが必要なファイルとテストをすべて確認したにもかかわらず判断自体がずっと間違うなら、より強いModelが必要なことがある。逆に、重要なファイルを読まない、テストを飛ばす、リファクタリングを途中で終えるなら、Effortを高めるほうがより適切なことがある。\n\n## 9. 権限と安全境界\n\nProactive Loopで最も危険な設計は、Agentに広い権限を与え、成功条件と中断条件を緩く置くことだ。\n\nAuto modeは通常の権限Promptを減らすが、元に戻しにくい、破壊的、または信頼境界の外を対象とするTool callは分類器がブロックすることがある。また、明示的な`permissions.ask`と`permissions.deny`はAuto modeより優先される。\n\n### 権限階層の例\n\n| レベル | 例 |\n|---|---|\n| 自動許可 | コード読み取り、テスト・lint・Build、分析、`claude/*` Branch作成、Draft PR作成 |\n| 人の承認 | Default Branch反映、本番デプロイ、DB Migration適用、外部顧客メッセージ送信 |\n| 常に禁止 | Force push、Secret出力、本番データ削除、権限迂回、監査ログ削除 |\n\n会話で「Pushするな」と一度言うより、永続的な`ask`・`deny` Ruleとして固定するほうが安全だ。Context圧縮やセッション変更によって、会話上のルールが弱まることがあるからだ。\n\nCloud Routineは実行ごとにRepositoryを新たにCloneし、接続されたGitHub・Connector権限で動作する。次の範囲を最小化しなければならない。\n\n- アクセス可能なRepositoryとBranch\n- 許可されたNetwork Domain\n- 使用するConnector\n- 環境変数とSecret\n- 外部システムの書き込み権限\n- PR作成・Push・Merge範囲\n\nRoutine実行一覧の「正常終了」状態は、InfrastructureエラーなしにSessionが終わったという意味である場合があり、業務目標が成功した保証ではない。Transcript、Test evidence、生成されたDiffを別途レビューしなければならない。\n\n## 10. 開発プロジェクト用Loop設計テンプレート\n\n次のYAMLは実際のClaude Code文法ではなく、設計レビュー用Templateだ。\n\n```yaml\ntrigger:\n  type: manual | interval | schedule | github_event | api_event\n\nscope:\n  repositories:\n    - target-repository\n  allowed_paths:\n    - src/**\n    - tests/**\n  prohibited_paths:\n    - production/**\n    - secrets/**\n\ntask:\n  objective: 変更または処理する目標\n  input: 新しく入ってくるIssue、Event、Fileまたは状態\n\nverification:\n  commands:\n    - unit-test\n    - integration-test\n    - lint\n    - build\n  runtime_checks:\n    - browser-interaction\n    - console-errors\n    - accessibility\n  evidence:\n    - command-output\n    - exit-code\n    - test-summary\n    - screenshots\n\nsuccess:\n  condition: 真偽で判定可能な完了状態\n\nstop:\n  max_turns: 12\n  max_duration_minutes: 45\n  max_consecutive_failures: 3\n  stop_on_permission_error: true\n  escalate_on_external_outage: true\n\nside_effects:\n  idempotency_key: event-id-or-commit-sha\n  allow_branch_push: claude/*\n  require_human_for_merge: true\n  require_human_for_deploy: true\n\nreview:\n  independent_agent: true\n  adversarial_review: true\n\nobservability:\n  report_progress: true\n  report_token_usage: true\n  report_changed_files: true\n  report_remaining_failures: true\n```\n\n最も重要な項目は、プロンプト文そのものより次の5つだ。\n\n```text\nTrigger\nVerifier\nSuccess condition\nHard stop\nPermission boundary\n```\n\n## 11. どのLoopを選ぶべきか\n\n| 状況 | 推奨方式 |\n|---|---|\n| 1回の修正と検証で終わる作業 | Turn-based |\n| 複数回試す必要があるが完了状態が明確な作業 | `/goal` |\n| 外部CI・PR・デプロイ状態をしばらく待つ必要がある作業 | `/loop` |\n| ノートPCを閉じても反復実行する必要がある業務 | `/schedule` Routine |\n| GitHubイベントやAlertに即時反応しなければならない業務 | Event-triggered Routine |\n| 数百項目を並列処理し、相互検証しなければならない業務 | Dynamic Workflow |\n| 入力と出力ルールが完全に決定論的な変換 | ScriptまたはCI Job |\n\n選択順序は「最も強力な機能」ではなく、「目標を達成する最も単純な制御構造」を基準にすべきだ。\n\n## 12. 安全な導入順序\n\n1. 人が繰り返し確認しているボトルネック業務を1つ選ぶ。\n2. まず検証手順をSkill、Script、CIとして作る。\n3. Turn-based方式で検証品質を安定化する。\n4. 完了状態が明確なら`/goal`を付ける。\n5. 外部状態を待つ必要があるときだけ`/loop`を使う。\n6. 長期実行が必要なら`/schedule` Routineへ移す。\n7. 冪等性、権限、コストが検証された後にのみDynamic WorkflowとProactive Loopへ拡張する。\n\n## 13. よくある誤解\n\n| 誤解 | 正確な解釈 |\n|---|---|\n| Loopは無限実行だ | 成功条件とHard stopがある制限付き反復構造だ |\n| Agentの完了報告は検証だ | 外部コマンド出力、終了コード、Runtime結果が必要だ |\n| `/goal`がすべての権限を自動許可する | 次のTurnだけを自動開始し、権限ポリシーは別物だ |\n| `/loop`は長期運用Schedulerだ | セッション中心であり、7日で期限切れになることと実行環境の制約がある |\n| Agentが多いほど結果が良くなる | 役割・観点・検証が異なるときだけ並列化の価値が生まれる |\n| すべての反復作業はLLMがすべきだ | 決定論的な部分はScriptのほうが安く、再現性が高い |\n\n## 結論\n\nLoop Engineeringは、AIを長時間実行させる技術ではなく、**AIが間違ったときに自ら発見し、コスト上限内で修正し、危険な地点では止まるようにする制御システム設計**だ。\n\nLLMは探索、推論、実装、例外分析、代替案比較に強い。システムは実行時点、変更範囲、検証方法、終了基準、コスト上限、承認境界を担当すべきだ。この役割分担が明確であるほど、Claude Code自動化は単なるコード生成ツールを超え、再現可能で監査可能な開発運用システムに近づく。","content_html":"\u003cp\u003eClaude CodeのLoopは、単にモデルを長時間実行する機能ではない。核心は、確率的に行動するAI Agentの周囲に \u003cstrong\u003eTrigger, Verifier, Success condition, Hard stop, Permission boundary\u003c/strong\u003e を配置し、反復作業を制御可能なシステムにすることにある。本稿では、Turn-based、Goal-based、Time-based、Proactive Loopの違いと実務上の設計原則を一度に整理する。\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#1-claude-codeにおけるloopとは何か\" class=\"anchor\" id=\"1-claude-codeにおけるloopとは何か\"\u003e\u003c/a\u003e1. Claude CodeにおけるLoopとは何か\u003c/h2\u003e\n\u003cp\u003eここでいうLoopは、プログラミング言語の\u003ccode\u003efor\u003c/code\u003eや\u003ccode\u003ewhile\u003c/code\u003e文ではない。Claude Codeチームが説明するLoopは、Agentが現在の状態を観察し、行動し、結果を検証した後、終了条件が満たされるまで再び作業する実行構造だ。\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e作業開始\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e状態とコードの把握\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e計画策定\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eコード修正またはツール実行\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eテスト・検証\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e完了条件を満たしたか？\n\u003c/span\u003e\u003cspan\u003e  ├─ いいえ: 次の反復\n\u003c/span\u003e\u003cspan\u003e  └─ はい: 終了および結果報告\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eLoopを区別するときは、次の4つの質問が役に立つ。\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e何が作業を開始させるのか？\u003c/li\u003e\n\u003cli\u003e何が作業を終了させるのか？\u003c/li\u003e\n\u003cli\u003eどのClaude Code機能が反復を制御するのか？\u003c/li\u003e\n\u003cli\u003eどのような種類の作業に適しているのか？\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eすべての作業を複雑なLoopにする必要はない。1つのファイルの誤字修正や単純な名前変更のように、結果をすぐ確認できる作業には通常のプロンプトのほうが効率的だ。Loopは、複数回の観察・修正・検証が実際に必要な場合にのみ選択すべきだ。\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#2-4種類のloopタイプ比較\" class=\"anchor\" id=\"2-4種類のloopタイプ比較\"\u003e\u003c/a\u003e2. 4種類のLoopタイプ比較\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eタイプ\u003c/th\u003e\n\u003cth\u003e開始条件\u003c/th\u003e\n\u003cth\u003e終了条件\u003c/th\u003e\n\u003cth\u003e主に使用する機能\u003c/th\u003e\n\u003cth\u003e適した作業\u003c/th\u003e\n\u003cth\u003e人が委ねる責任\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eTurn-based\u003c/td\u003e\n\u003ctd\u003eユーザーのプロンプト\u003c/td\u003e\n\u003ctd\u003eClaudeが完了したと判断するか、追加情報が必要なとき\u003c/td\u003e\n\u003ctd\u003e通常の会話、Skills、テスト・ブラウザツール\u003c/td\u003e\n\u003ctd\u003e短く一回性の実装・修正\u003c/td\u003e\n\u003ctd\u003e反復検証手順\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eGoal-based\u003c/td\u003e\n\u003ctd\u003eユーザーが完了条件を指定\u003c/td\u003e\n\u003ctd\u003e評価モデルが条件達成を確認するか、ユーザーが中断\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/goal\u003c/code\u003e、必要に応じてAuto mode\u003c/td\u003e\n\u003ctd\u003eテスト・ビルド・マイグレーションのように完了状態を測定できる作業\u003c/td\u003e\n\u003ctd\u003e終了判断\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTime-based\u003c/td\u003e\n\u003ctd\u003e指定した時間・間隔・スケジュール\u003c/td\u003e\n\u003ctd\u003eユーザーがキャンセルするか、外部作業が終わる\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/loop\u003c/code\u003e、\u003ccode\u003e/schedule\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003ePR・CI・デプロイ監視、定期要約、状態Polling\u003c/td\u003e\n\u003ctd\u003e次の実行時点\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eProactive\u003c/td\u003e\n\u003ctd\u003eスケジュール、API、GitHubイベントなど\u003c/td\u003e\n\u003ctd\u003e個別作業の目標達成、Routineの無効化\u003c/td\u003e\n\u003ctd\u003eRoutines、\u003ccode\u003e/goal\u003c/code\u003e、Skills、Dynamic Workflows、Auto mode\u003c/td\u003e\n\u003ctd\u003eイシュー分類、バグ対応、大規模マイグレーションなどの継続業務\u003c/td\u003e\n\u003ctd\u003e作業発見、プロンプト実行、オーケストレーション\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eこの分類の核心は、「AIがどれだけ賢いか」ではなく、\u003cstrong\u003e人がどの制御責任をシステムに委ねるか\u003c/strong\u003eだ。Turn-basedでは人が次のプロンプトを作り、Goal-basedでは完了判断を委ね、Time-basedでは再実行時点を委ねる。Proactive段階では、作業発生を検知し、適切なプロンプトを実行する責任までシステムへ移動する。\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#3-turn-based-loop-検証手順を委ねる\" class=\"anchor\" id=\"3-turn-based-loop-検証手順を委ねる\"\u003e\u003c/a\u003e3. Turn-based Loop: 検証手順を委ねる\u003c/h2\u003e\n\u003cp\u003eTurn-based Loopは、ほとんどの開発者がClaude Codeを使う基本形だ。\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eHuman → Claude → Human → Claude\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eユーザーが依頼すると、Claudeは関連ファイルを探し、コードを修正し、テストし、結果を報告する。内部的には複数回の観察・行動・検証が起きることがあるが、次の作業を開始する権限はユーザーに残っている。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#コード修正と機能完成は異なる\" class=\"anchor\" id=\"コード修正と機能完成は異なる\"\u003e\u003c/a\u003eコード修正と機能完成は異なる\u003c/h3\u003e\n\u003cp\u003eClaudeが「実装とテストを完了した」と報告しても、実際の製品では次の問題が残ることがある。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eボタンをクリックしても状態が変わらない。\u003c/li\u003e\n\u003cli\u003eブラウザコンソールにエラーが発生する。\u003c/li\u003e\n\u003cli\u003eモバイルレイアウトが崩れる。\u003c/li\u003e\n\u003cli\u003eアクセシビリティ属性が抜けている。\u003c/li\u003e\n\u003cli\u003eテストは通るが、実際のブラウザフローは失敗する。\u003c/li\u003e\n\u003cli\u003e変更と無関係なファイルまで修正された。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eしたがって完了基準は、「コードを変えた」ではなく「外部証拠で動作を確認した」でなければならない。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#skillmdで検証を再利用する\" class=\"anchor\" id=\"skillmdで検証を再利用する\"\u003e\u003c/a\u003e\u003ccode\u003eSKILL.md\u003c/code\u003eで検証を再利用する\u003c/h3\u003e\n\u003cp\u003eSkillは、繰り返し使う指示と手順を\u003ccode\u003eSKILL.md\u003c/code\u003eに保存する方式だ。Claudeが関連性を判断して自動で読み込むか、\u003ccode\u003e/skill-name\u003c/code\u003eで直接実行できる。長い運用手順を常に\u003ccode\u003eCLAUDE.md\u003c/code\u003eに入れるより、必要な瞬間にだけSkillをロードするよう分離すれば、コンテキストをより効率的に使える。\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e---\n\u003c/span\u003e\u003cspan\u003ename: verify-ui-change\n\u003c/span\u003e\u003cspan\u003edescription: UI変更を完了扱いにする前に、実際の実行環境で検証する。\n\u003c/span\u003e\u003cspan\u003e---\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e# UI変更の検証\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e1. 開発サーバーを実行する。\n\u003c/span\u003e\u003cspan\u003e2. 変更された画面をブラウザで開く。\n\u003c/span\u003e\u003cspan\u003e3. 新しいコントロールを実際に操作する。\n\u003c/span\u003e\u003cspan\u003e4. 期待した状態変化が発生するか確認する。\n\u003c/span\u003e\u003cspan\u003e5. ブラウザコンソールの新しいエラーと警告を確認する。\n\u003c/span\u003e\u003cspan\u003e6. アクセシビリティおよび主要なパフォーマンス指標を点検する。\n\u003c/span\u003e\u003cspan\u003e7. 失敗した場合は修正後、最初から再度検証する。\n\u003c/span\u003e\u003cspan\u003e8. 実行したコマンド、結果、スクリーンショットなどの証拠を報告する。\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e良いSkillは、抽象的なお願いではなく実行可能なチェックリストを含む。「より慎重に検討する」より「\u003ccode\u003enpm test\u003c/code\u003eが終了コード0か確認する」のほうが、はるかに強いルールだ。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#検証証拠の強度\" class=\"anchor\" id=\"検証証拠の強度\"\u003e\u003c/a\u003e検証証拠の強度\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e証拠\u003c/th\u003e\n\u003cth\u003e信頼度\u003c/th\u003e\n\u003cth\u003e理由\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003e「正常だと思われる」というAgentの説明\u003c/td\u003e\n\u003ctd\u003e低い\u003c/td\u003e\n\u003ctd\u003e実行結果ではなく推論にすぎない\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eコードDiffと静的レビュー\u003c/td\u003e\n\u003ctd\u003e中程度\u003c/td\u003e\n\u003ctd\u003e変更内容は見えるがRuntime動作は確認できない\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e実際のテスト出力と終了コード\u003c/td\u003e\n\u003ctd\u003e高い\u003c/td\u003e\n\u003ctd\u003e再現可能な外部結果が存在する\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eブラウザ操作、スクリーンショット、コンソール・パフォーマンス結果\u003c/td\u003e\n\u003ctd\u003e非常に高い\u003c/td\u003e\n\u003ctd\u003eユーザー経路とRuntime状態を直接検証する\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e独立したReview AgentとCIが同じ結論を出す\u003c/td\u003e\n\u003ctd\u003e非常に高い\u003c/td\u003e\n\u003ctd\u003e実装Agentの自己確証バイアスを減らす\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eClaude Code公式ドキュメントには、実行中のアプリケーションを確認する\u003ccode\u003e/run\u003c/code\u003e、変更を実際の実行環境で検証する\u003ccode\u003e/verify\u003c/code\u003eのようなbundled Skillも説明されている。プロジェクトの実行方式が複雑なら、チーム固有のSkillに正確な開始コマンド、環境変数、データ準備手順を記録するほうが安全だ。\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#4-goal-based-loop-終了判断を委ねる\" class=\"anchor\" id=\"4-goal-based-loop-終了判断を委ねる\"\u003e\u003c/a\u003e4. Goal-based Loop: 終了判断を委ねる\u003c/h2\u003e\n\u003cp\u003eGoal-based Loopでは、「もう一度作業するか」をユーザーが毎回決めない。ユーザーは完了状態を定義し、Claudeはその条件が満たされるまで複数のTurnを続ける。\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eユーザーがGoalを指定\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eClaude作業Turn\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e別の評価モデルが完了条件を確認\n\u003c/span\u003e\u003cspan\u003e  ├─ 未達成: 理由を次のTurnに伝達\n\u003c/span\u003e\u003cspan\u003e  └─ 達成: Goal終了\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e\u003ccode\u003e/goal\u003c/code\u003eはClaude Code v2.1.139以上で使用できるよう文書化されている。1つのセッションでは1つのGoalだけを有効化できる。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#評価モデルが実際に見るもの\" class=\"anchor\" id=\"評価モデルが実際に見るもの\"\u003e\u003c/a\u003e評価モデルが実際に見るもの\u003c/h3\u003e\n\u003cp\u003e各Turnが終わると、別のsmall fast modelが完了条件と会話内容を見て、\u003ccode\u003e達成\u003c/code\u003eまたは\u003ccode\u003e未達成\u003c/code\u003eを判断する。デフォルト設定はHaiku系の評価モデルだ。重要な制限は、評価モデルがファイルを直接読んだり、テストを別途実行したりしない点だ。\u003c/p\u003e\n\u003cp\u003eしたがって、作業を行ったClaudeが次の証拠を会話に明確に残さなければならない。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e実行したコマンド\u003c/li\u003e\n\u003cli\u003eテスト数と成功・失敗結果\u003c/li\u003e\n\u003cli\u003e終了コード\u003c/li\u003e\n\u003cli\u003eビルド結果\u003c/li\u003e\n\u003cli\u003e変更ファイル一覧\u003c/li\u003e\n\u003cli\u003e残っている失敗原因\u003c/li\u003e\n\u003cli\u003e範囲制約を守ったという確認結果\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e評価モデルは「実際に何が起きたか」ではなく、「会話にどのような証拠が示されたか」を判断する。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#良いgoalの4要素\" class=\"anchor\" id=\"良いgoalの4要素\"\u003e\u003c/a\u003e良いGoalの4要素\u003c/h3\u003e\n\u003cp\u003e良いGoalは次の4要素を含む。\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003e測定可能な成功条件\u003c/strong\u003e: テスト通過、ビルド成功、キューが空になる、スコア閾値達成\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e検証方法\u003c/strong\u003e: どのコマンドやツールで成功を証明するかを明示\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e変更範囲の制約\u003c/strong\u003e: 修正可能なディレクトリ、禁止ファイル、許可されたSide effect\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e強制終了条件\u003c/strong\u003e: 最大Turn、最大時間、連続失敗回数、権限エラー時の中断\u003c/li\u003e\n\u003c/ol\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e/goal auth関連テストとlintがすべて成功し、\n\u003c/span\u003e\u003cspan\u003egit diffにはsrc/authと関連テストファイルのみ含まれていなければならない。\n\u003c/span\u003e\u003cspan\u003e各Turnで実行結果と終了コードを報告する。\n\u003c/span\u003e\u003cspan\u003e最大12ターンまたは45分に達したら中断し、残った失敗を整理する。\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e\u003ccode\u003e/goal\u003c/code\u003e自体の核心的な終了条件は、評価モデルの成功判定またはユーザーの\u003ccode\u003e/goal clear\u003c/code\u003eだ。Turn・時間上限を強制するには、Goal条件の中に明示しなければならない。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#良い条件と悪い条件\" class=\"anchor\" id=\"良い条件と悪い条件\"\u003e\u003c/a\u003e良い条件と悪い条件\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e良い条件\u003c/th\u003e\n\u003cth\u003e悪い条件\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003enpm test\u003c/code\u003eが終了コード0で終わる\u003c/td\u003e\n\u003ctd\u003eコードを完璧にする\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e認証関連テスト48個がすべて通過する\u003c/td\u003e\n\u003ctd\u003eユーザー体験を最大限改善する\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eすべてのAPI呼び出し箇所が新しいインターフェースに変更され、ビルドが成功する\u003c/td\u003e\n\u003ctd\u003eより良い構造にリファクタリングする\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e処理対象イシューキューが空になり、各イシューに結果が記録される\u003c/td\u003e\n\u003ctd\u003e可能な限り多くのイシューを処理する\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e曖昧な目標は、早すぎる終了や終わりのない改善の反復につながることがある。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#状態確認と中断\" class=\"anchor\" id=\"状態確認と中断\"\u003e\u003c/a\u003e状態確認と中断\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ccode\u003e/goal\u003c/code\u003e: 有効条件、実行時間、評価Turn数、トークン使用量、最近の評価理由を確認\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003e/goal clear\u003c/code\u003e: 有効なGoalを中断\u003c/li\u003e\n\u003cli\u003e新しいGoal設定: 既存Goalを置き換え\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003e--resume\u003c/code\u003eまたは\u003ccode\u003e--continue\u003c/code\u003e: 未完了Goalの復元が可能\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e再開時に条件は維持されるが、Turn数、時間、トークンの基準線は初期化されることがあるため、Hard stopを運用指標と併せて管理するのがよい。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#goalと権限は別物だ\" class=\"anchor\" id=\"goalと権限は別物だ\"\u003e\u003c/a\u003e\u003ccode\u003e/goal\u003c/code\u003eと権限は別物だ\u003c/h3\u003e\n\u003cp\u003e\u003ccode\u003e/goal\u003c/code\u003eは次のTurnを自動的に開始するだけで、ツール権限を広げるわけではない。ファイル書き込み、テストコマンド、Git作業が承認対象なら、Goal中でも承認が必要になることがある。\u003c/p\u003e\n\u003cp\u003e無人実行にはAuto modeを併用できるが、Auto modeは「すべてのツールを無条件に許可する」機能ではない。分類器が破壊的、または元に戻しにくい、あるいは信頼境界の外を対象とする作業をブロックし、明示的な\u003ccode\u003eask\u003c/code\u003eと\u003ccode\u003edeny\u003c/code\u003eルールは分類器より先に適用される。\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#5-time-based-loop-再実行時点を委ねる\" class=\"anchor\" id=\"5-time-based-loop-再実行時点を委ねる\"\u003e\u003c/a\u003e5. Time-based Loop: 再実行時点を委ねる\u003c/h2\u003e\n\u003cp\u003eGoal-based Loopが「いつ止まるか」を扱うなら、Time-based Loopは「いつ再び実行するか」を扱う。外部システムの状態が時間とともに変化する作業に適している。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003ePRに新しいレビューが付いたか確認\u003c/li\u003e\n\u003cli\u003eCIまたはデプロイが終わったか確認\u003c/li\u003e\n\u003cli\u003e長時間ビルドの状態確認\u003c/li\u003e\n\u003cli\u003e毎日のSlackメッセージ要約\u003c/li\u003e\n\u003cli\u003eイシューキューの新規項目確認\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\u003ca href=\"#loop-現在のセッション内で反復実行\" class=\"anchor\" id=\"loop-現在のセッション内で反復実行\"\u003e\u003c/a\u003e\u003ccode\u003e/loop\u003c/code\u003e: 現在のセッション内で反復実行\u003c/h3\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e/loop 10m 現在のPRを確認して新しいレビューを反映し、\n\u003c/span\u003e\u003cspan\u003e失敗したCIがあれば原因を分析して修正する。\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e現在のドキュメントで説明されている主な形式は次のとおりだ。\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e入力\u003c/th\u003e\n\u003cth\u003e動作\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop 5m \u0026lt;prompt\u0026gt;\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e指定した固定間隔でPromptを実行\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop \u0026lt;prompt\u0026gt;\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eClaudeが反復ごとに間隔を選択\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003ebuilt-inメンテナンスPromptまたはプロジェクトの\u003ccode\u003eloop.md\u003c/code\u003eを実行\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop 20m /review-pr 1234\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e許可されたSkillを指定間隔で再実行\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e\u003ccode\u003e/loop\u003c/code\u003eは現在のClaude Codeセッションに依存する。コンピューターとセッションが実行中でなければならず、新しい会話を始めるとセッション範囲の作業は消える。未期限切れの作業は\u003ccode\u003e--resume\u003c/code\u003eまたは\u003ccode\u003e--continue\u003c/code\u003eで復元できるが、反復作業は基本的に作成後7日で期限切れになる。逃した周期をすべて遡って実行することもない。\u003c/p\u003e\n\u003cp\u003eセッションSchedulerにはJitterが適用されることがあるため、「正時に必ず実行」しなければならない運用要件には適さない場合がある。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#schedule-anthropic管理cloud-routine\" class=\"anchor\" id=\"schedule-anthropic管理cloud-routine\"\u003e\u003c/a\u003e\u003ccode\u003e/schedule\u003c/code\u003e: Anthropic管理Cloud Routine\u003c/h3\u003e\n\u003cp\u003e\u003ccode\u003e/schedule\u003c/code\u003eはPromptとRepository、Connector、Triggerを束ね、Anthropic管理インフラで実行するRoutineを作る。ノートPCを閉じても実行でき、公式ドキュメントではResearch Previewとして案内されている。\u003c/p\u003e\n\u003cp\u003eRoutineがサポートするTriggerは次のとおりだ。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e反復スケジュール\u003c/li\u003e\n\u003cli\u003e特定の未来時点の一回限りのスケジュール\u003c/li\u003e\n\u003cli\u003e認証済みAPI呼び出し\u003c/li\u003e\n\u003cli\u003eGitHub Pull requestまたはReleaseイベント\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e1つのRoutineに複数のTriggerを接続できる。たとえばPR Review Routineを毎晩実行しつつ、\u003ccode\u003epull_request.opened\u003c/code\u003eイベントにも反応させることができる。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#loopとscheduleの比較\" class=\"anchor\" id=\"loopとscheduleの比較\"\u003e\u003c/a\u003e\u003ccode\u003e/loop\u003c/code\u003eと\u003ccode\u003e/schedule\u003c/code\u003eの比較\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e区分\u003c/th\u003e\n\u003cth\u003e\u003ccode\u003e/loop\u003c/code\u003e\u003c/th\u003e\n\u003cth\u003e\u003ccode\u003e/schedule\u003c/code\u003e Routine\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003e実行場所\u003c/td\u003e\n\u003ctd\u003e現在のコンピューターとセッション\u003c/td\u003e\n\u003ctd\u003eAnthropic管理Cloud\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eコンピューター終了後の実行\u003c/td\u003e\n\u003ctd\u003e一般的に不可\u003c/td\u003e\n\u003ctd\u003e可能\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e開いているセッション\u003c/td\u003e\n\u003ctd\u003e必要\u003c/td\u003e\n\u003ctd\u003e不要\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eローカルの未コミットファイル\u003c/td\u003e\n\u003ctd\u003eアクセス可能\u003c/td\u003e\n\u003ctd\u003eアクセス不可、実行ごとにRepositoryを新たにClone\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e最小間隔\u003c/td\u003e\n\u003ctd\u003e公式ドキュメント基準1分\u003c/td\u003e\n\u003ctd\u003e公式ドキュメント基準1時間\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e持続性\u003c/td\u003e\n\u003ctd\u003eセッション中心、反復作業は7日で期限切れ\u003c/td\u003e\n\u003ctd\u003eアカウントに保存されるRoutine\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e権限Prompt\u003c/td\u003e\n\u003ctd\u003e現在のセッションポリシーを継承\u003c/td\u003e\n\u003ctd\u003e対話型承認なしで自律実行\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e適した用途\u003c/td\u003e\n\u003ctd\u003e短いPR・デプロイ監視\u003c/td\u003e\n\u003ctd\u003e継続的な運用自動化\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\u003ca href=\"#pollingよりeventが優れている場合\" class=\"anchor\" id=\"pollingよりeventが優れている場合\"\u003e\u003c/a\u003ePollingよりEventが優れている場合\u003c/h3\u003e\n\u003cp\u003e変更が少ないPRを1分ごとに確認すると、ほとんどの実行は何もせず終了する。外部システムがイベントを送れるなら、次の構造のほうが効率的だ。\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eCI失敗またはPR更新\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eGitHub TriggerまたはRoutine API\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e必要なときだけClaude実行\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eEventベースの設計は遅延を減らし、不要なモデル呼び出しとトークン消費を減らす。Pollingが避けられないなら、実際の変更頻度に合わせて間隔を伸ばし、長時間変化がないときはBackoffを適用するのがよい。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#時間ベース作業の必須条件\" class=\"anchor\" id=\"時間ベース作業の必須条件\"\u003e\u003c/a\u003e時間ベース作業の必須条件\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003e冪等性\u003c/strong\u003e: 同じイベントを複数回受け取っても、重複コメント、重複PR、重複デプロイが発生してはならない。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e処理状態\u003c/strong\u003e: 最後に処理したEvent ID、Commit SHA、Review Comment IDなどを記録しなければならない。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e終了状態\u003c/strong\u003e: PR merge・close、Queue empty、Deploy success・rollbackのように終了を判定できなければならない。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e書き込み範囲\u003c/strong\u003e: コメント許可、Merge禁止、\u003ccode\u003eclaude/*\u003c/code\u003e BranchのみPushなど、Side effectを制限しなければならない。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e失敗処理\u003c/strong\u003e: 外部サービス障害、認証期限切れ、Rate limit、権限不足時の再試行とEscalationルールが必要だ。\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2\u003e\u003ca href=\"#6-proactive-loop-作業発見とオーケストレーションを委ねる\" class=\"anchor\" id=\"6-proactive-loop-作業発見とオーケストレーションを委ねる\"\u003e\u003c/a\u003e6. Proactive Loop: 作業発見とオーケストレーションを委ねる\u003c/h2\u003e\n\u003cp\u003eProactive Loopは1つのコマンドではなく、複数の機能を組み合わせた常時自動化アーキテクチャだ。\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eTrigger\n\u003c/span\u003e\u003cspan\u003e+ Goal\n\u003c/span\u003e\u003cspan\u003e+ Skills\n\u003c/span\u003e\u003cspan\u003e+ Dynamic Workflow\n\u003c/span\u003e\u003cspan\u003e+ Auto mode\n\u003c/span\u003e\u003cspan\u003e+ Repository・Connector・Browser・CIツール\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e人がリアルタイムでプロンプトを入力しなくても、新しい作業が検知され、処理され、検証され、結果が報告される。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#例-バグフィードバックの自動処理\" class=\"anchor\" id=\"例-バグフィードバックの自動処理\"\u003e\u003c/a\u003e例: バグフィードバックの自動処理\u003c/h3\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eGitHub IssueまたはSlackフィードバック受信\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e重複・優先順位・再現可能性の分類\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e再現テスト作成\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e候補解決策の探索\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e選択した解決策の実装\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e独立したReview Agentが反例を探索\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eテスト・ビルド・セキュリティ検証\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eDraft PRと結果報告\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e構成要素ごとの責任は次のとおりだ。\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e構成要素\u003c/th\u003e\n\u003cth\u003e責任\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eTriggerまたは\u003ccode\u003e/schedule\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e新しい作業を開始する時点を決定\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/goal\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e今回の実行で何が完了状態かを定義\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eSkill\u003c/td\u003e\n\u003ctd\u003e再現、実装、検証、報告手順の標準化\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eDynamic Workflow\u003c/td\u003e\n\u003ctd\u003e複数Subagentの並列実行と条件分岐\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eAuto mode\u003c/td\u003e\n\u003ctd\u003e許可されたツール呼び出しを承認待ちなしで実行\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003ePermission policy\u003c/td\u003e\n\u003ctd\u003e禁止・承認・自動許可範囲を固定\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\u003ca href=\"#dynamic-workflowとworktree\" class=\"anchor\" id=\"dynamic-workflowとworktree\"\u003e\u003c/a\u003eDynamic WorkflowとWorktree\u003c/h3\u003e\n\u003cp\u003eDynamic Workflowは、Claudeが作成したJavaScriptオーケストレーションScriptをRuntimeが実行する構造だ。通常のSubagent呼び出しでは、ClaudeがTurnごとに次のAgentを選ぶが、WorkflowではLoop、並列処理、分岐、中間結果の保存がScriptに移る。\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eWorkflow Script\n\u003c/span\u003e\u003cspan\u003e  ├─ Agent A: 要件分析\n\u003c/span\u003e\u003cspan\u003e  ├─ Agent B: テスト設計\n\u003c/span\u003e\u003cspan\u003e  ├─ Agent C: 実装候補探索\n\u003c/span\u003e\u003cspan\u003e  ├─ Agent D: セキュリティレビュー\n\u003c/span\u003e\u003cspan\u003e  └─ Judge: 証拠ベースの比較\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e中間結果がメイン会話ContextではなくScript変数に残るため、大規模作業をより再現可能に組織できる。現行ドキュメントには、同時に最大16個のAgent、実行あたり最大1,000個のAgentというRuntime上限が明記されているが、製品Preview段階の制限は変わる可能性がある。\u003c/p\u003e\n\u003cp\u003e複数の実装候補を同時に試す必要があるなら、Git Worktreeで作業空間を分離できる。\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003erepo/\n\u003c/span\u003e\u003cspan\u003eworktree-solution-a/\n\u003c/span\u003e\u003cspan\u003eworktree-solution-b/\n\u003c/span\u003e\u003cspan\u003eworktree-solution-c/\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e各Agentが独立したBranchとディレクトリで作業すれば、同じファイルを同時に上書きする問題を減らせる。Judge Agentは、要件充足、テスト結果、回帰リスク、変更範囲、複雑度、性能、セキュリティ、既存アーキテクチャとの一貫性を基準に候補を比較しなければならない。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#agentが多ければ常に良いわけではない\" class=\"anchor\" id=\"agentが多ければ常に良いわけではない\"\u003e\u003c/a\u003eAgentが多ければ常に良いわけではない\u003c/h3\u003e\n\u003cp\u003e並列性のない作業でAgent数だけを増やすと、コストと遅延が増える。複数のAgentが同じ誤った仮定を共有すれば、エラーが拡大することもある。\u003c/p\u003e\n\u003cp\u003eDynamic Workflowが適している場合は次のとおりだ。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e数百ファイルに同じ変換を適用するMigration\u003c/li\u003e\n\u003cli\u003eコードベース全体のセキュリティ・品質Audit\u003c/li\u003e\n\u003cli\u003e独立した複数観点のPlan比較\u003c/li\u003e\n\u003cli\u003e多くの項目を分割処理し、相互検証しなければならないResearch\u003c/li\u003e\n\u003cli\u003e1つのAgentのContextにすべての中間結果を入れるのが難しい作業\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e小さなバグ修正、1ファイルのリファクタリング、単純なテスト追加には、通常のTurn-based Loopや\u003ccode\u003e/goal\u003c/code\u003eのほうがよい。\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#7-loopでコード品質を維持するシステム\" class=\"anchor\" id=\"7-loopでコード品質を維持するシステム\"\u003e\u003c/a\u003e7. Loopでコード品質を維持するシステム\u003c/h2\u003e\n\u003cp\u003eLoop結果の品質は、モデル自体だけでなく、モデル周辺の検証システムに大きく左右される。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#71-コードベースを整える\" class=\"anchor\" id=\"71-コードベースを整える\"\u003e\u003c/a\u003e7.1 コードベースを整える\u003c/h3\u003e\n\u003cp\u003eClaudeは既存コードのパターンを強く踏襲する。古いAPI、重複実装、不明確なテスト構造、巨大なモジュール、一貫しない例外処理ルールがあると、Loopがその問題を素早く複製してしまうことがある。\u003c/p\u003e\n\u003cp\u003e必須の基盤は次のとおりだ。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eFormatterとlint\u003c/li\u003e\n\u003cli\u003e明確なディレクトリとモジュール境界\u003c/li\u003e\n\u003cli\u003e信頼できるUnit・Integration・E2E Test\u003c/li\u003e\n\u003cli\u003e使用中のAPIとDeprecated APIの区別\u003c/li\u003e\n\u003cli\u003eプロジェクト別の開発ルール\u003c/li\u003e\n\u003cli\u003e再現可能なBuild・Dev環境\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\u003ca href=\"#72-変更タイプ別definition-of-doneを作る\" class=\"anchor\" id=\"72-変更タイプ別definition-of-doneを作る\"\u003e\u003c/a\u003e7.2 変更タイプ別Definition of Doneを作る\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e変更タイプ\u003c/th\u003e\n\u003cth\u003e最小検証\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eAPI\u003c/td\u003e\n\u003ctd\u003e契約テスト、後方互換性、Schema・ドキュメント例の更新\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eFrontend\u003c/td\u003e\n\u003ctd\u003e実際のブラウザ操作、コンソールエラー、アクセシビリティ、レスポンシブ画面\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eDatabase\u003c/td\u003e\n\u003ctd\u003eForward・Rollback Migration、Lock範囲、実行計画\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eDependency\u003c/td\u003e\n\u003ctd\u003eBuild、主要回帰テスト、License・Security確認\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eInfrastructure\u003c/td\u003e\n\u003ctd\u003ePlan Diff、最小権限、Rollback、秘密情報露出検査\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eこの基準はPromptに毎回長く繰り返すより、Skill、Hook、Script、CI Ruleとして固定するほうがよい。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#73-最新ドキュメントと正確なバージョンを提供する\" class=\"anchor\" id=\"73-最新ドキュメントと正確なバージョンを提供する\"\u003e\u003c/a\u003e7.3 最新ドキュメントと正確なバージョンを提供する\u003c/h3\u003e\n\u003cp\u003eLoopは誤った仮定を何度も繰り返すことがある。プロジェクトで使う正確なVersion、公式ドキュメント、内部Architecture文書、API仕様、Migration Guide、承認済みの例を簡単に見つけられるようにしなければならない。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#74-実装agentとreview-agentを分離する\" class=\"anchor\" id=\"74-実装agentとreview-agentを分離する\"\u003e\u003c/a\u003e7.4 実装AgentとReview Agentを分離する\u003c/h3\u003e\n\u003cp\u003e実装したAgentは、すでに選択した設計と推論の影響を受けている。新しいContextのReview Agentは、次の質問をより独立して投げかけることができる。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eテストを弱めて通したのではないか？\u003c/li\u003e\n\u003cli\u003e範囲外ファイルを変更していないか？\u003c/li\u003e\n\u003cli\u003eセキュリティ境界が破られていないか？\u003c/li\u003e\n\u003cli\u003e失敗経路と境界値テストが抜けていないか？\u003c/li\u003e\n\u003cli\u003e既存機能に回帰が生じていないか？\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eReview Promptは、「良い点を要約せよ」より「実装が間違っているという仮定で反例を探し、各指摘に再現証拠を付けよ」のように書くほうが効果的だ。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#75-個別の失敗をシステム改善につなげる\" class=\"anchor\" id=\"75-個別の失敗をシステム改善につなげる\"\u003e\u003c/a\u003e7.5 個別の失敗をシステム改善につなげる\u003c/h3\u003e\n\u003cp\u003e同じエラーが繰り返されるなら、その結果だけを修正してはいけない。失敗タイプが再発しにくくなるよう、次のいずれかを変える必要がある。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eRegression Test追加\u003c/li\u003e\n\u003cli\u003eSkill検証手順の強化\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eCLAUDE.md\u003c/code\u003eルール追加\u003c/li\u003e\n\u003cli\u003eHookまたはlint Rule追加\u003c/li\u003e\n\u003cli\u003e権限Deny Rule追加\u003c/li\u003e\n\u003cli\u003eGoalの完了条件強化\u003c/li\u003e\n\u003cli\u003eReview Checklist補完\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e良いLoop Engineeringとは、1回の失敗を直す作業ではなく、\u003cstrong\u003eその種類の失敗が再び出にくいシステムを作る作業\u003c/strong\u003eだ。\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#8-tokenとコスト管理\" class=\"anchor\" id=\"8-tokenとコスト管理\"\u003e\u003c/a\u003e8. Tokenとコスト管理\u003c/h2\u003e\n\u003cp\u003eLoopのコストは単一Promptより大きく増えることがある。\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e総コスト ≈\n\u003c/span\u003e\u003cspan\u003eメインAgent Turnコスト\n\u003c/span\u003e\u003cspan\u003e+ Goal評価コスト\n\u003c/span\u003e\u003cspan\u003e+ Subagentコスト\n\u003c/span\u003e\u003cspan\u003e+ Workflow反復コスト\n\u003c/span\u003e\u003cspan\u003e+ ツール結果を読むContextコスト\n\u003c/span\u003e\u003cspan\u003e+ 時間ベース実行頻度\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e正確な課金はPlan、Model、Providerによって異なるが、コスト構造を決める原理は同じだ。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#コストを減らす実務原則\" class=\"anchor\" id=\"コストを減らす実務原則\"\u003e\u003c/a\u003eコストを減らす実務原則\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003e小さな作業にはLoopを使わない。\u003c/strong\u003e 誤字、名前変更、1ファイルの型エラーは単一Turnで処理する。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e成功条件とHard stopを併せて置く。\u003c/strong\u003e 成功、最大Turn、最大時間、連続失敗、権限エラーをすべて考慮する。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e大規模Workflowは小さい範囲で試す。\u003c/strong\u003e 5個のファイル、1つのディレクトリ、一部のIssueでコストと品質を検証した後に拡大する。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e決定論的作業はScriptで処理する。\u003c/strong\u003e AST置換、JSON変換、Formatting、固定形式生成は、検証済みのScriptのほうが安く再現可能だ。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePolling周期を実際の変更頻度に合わせる。\u003c/strong\u003e 可能ならEvent Triggerを使う。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e進行中の使用量を観察する。\u003c/strong\u003e \u003ccode\u003e/usage\u003c/code\u003e、\u003ccode\u003e/goal\u003c/code\u003e、\u003ccode\u003e/workflows\u003c/code\u003eでSkill・Subagent・MCP・Turn・Token使用量を確認する。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e同じエラーが繰り返されるなら、再試行を続けない。\u003c/strong\u003e 連続失敗上限を置き、人にEscalationする。\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch3\u003e\u003ca href=\"#modelとeffortは別のレバーだ\" class=\"anchor\" id=\"modelとeffortは別のレバーだ\"\u003e\u003c/a\u003eModelとEffortは別のレバーだ\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eModel\u003c/strong\u003eは基本的な推論能力と解決可能な問題の範囲を変える。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eEffort\u003c/strong\u003eは読むファイル数、使用するツール数、検証の幅、複数段階作業をどこまで最後まで押し切るかを変える。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eClaudeが必要なファイルとテストをすべて確認したにもかかわらず判断自体がずっと間違うなら、より強いModelが必要なことがある。逆に、重要なファイルを読まない、テストを飛ばす、リファクタリングを途中で終えるなら、Effortを高めるほうがより適切なことがある。\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#9-権限と安全境界\" class=\"anchor\" id=\"9-権限と安全境界\"\u003e\u003c/a\u003e9. 権限と安全境界\u003c/h2\u003e\n\u003cp\u003eProactive Loopで最も危険な設計は、Agentに広い権限を与え、成功条件と中断条件を緩く置くことだ。\u003c/p\u003e\n\u003cp\u003eAuto modeは通常の権限Promptを減らすが、元に戻しにくい、破壊的、または信頼境界の外を対象とするTool callは分類器がブロックすることがある。また、明示的な\u003ccode\u003epermissions.ask\u003c/code\u003eと\u003ccode\u003epermissions.deny\u003c/code\u003eはAuto modeより優先される。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#権限階層の例\" class=\"anchor\" id=\"権限階層の例\"\u003e\u003c/a\u003e権限階層の例\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eレベル\u003c/th\u003e\n\u003cth\u003e例\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003e自動許可\u003c/td\u003e\n\u003ctd\u003eコード読み取り、テスト・lint・Build、分析、\u003ccode\u003eclaude/*\u003c/code\u003e Branch作成、Draft PR作成\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e人の承認\u003c/td\u003e\n\u003ctd\u003eDefault Branch反映、本番デプロイ、DB Migration適用、外部顧客メッセージ送信\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e常に禁止\u003c/td\u003e\n\u003ctd\u003eForce push、Secret出力、本番データ削除、権限迂回、監査ログ削除\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e会話で「Pushするな」と一度言うより、永続的な\u003ccode\u003eask\u003c/code\u003e・\u003ccode\u003edeny\u003c/code\u003e Ruleとして固定するほうが安全だ。Context圧縮やセッション変更によって、会話上のルールが弱まることがあるからだ。\u003c/p\u003e\n\u003cp\u003eCloud Routineは実行ごとにRepositoryを新たにCloneし、接続されたGitHub・Connector権限で動作する。次の範囲を最小化しなければならない。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eアクセス可能なRepositoryとBranch\u003c/li\u003e\n\u003cli\u003e許可されたNetwork Domain\u003c/li\u003e\n\u003cli\u003e使用するConnector\u003c/li\u003e\n\u003cli\u003e環境変数とSecret\u003c/li\u003e\n\u003cli\u003e外部システムの書き込み権限\u003c/li\u003e\n\u003cli\u003ePR作成・Push・Merge範囲\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eRoutine実行一覧の「正常終了」状態は、InfrastructureエラーなしにSessionが終わったという意味である場合があり、業務目標が成功した保証ではない。Transcript、Test evidence、生成されたDiffを別途レビューしなければならない。\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#10-開発プロジェクト用loop設計テンプレート\" class=\"anchor\" id=\"10-開発プロジェクト用loop設計テンプレート\"\u003e\u003c/a\u003e10. 開発プロジェクト用Loop設計テンプレート\u003c/h2\u003e\n\u003cp\u003e次のYAMLは実際のClaude Code文法ではなく、設計レビュー用Templateだ。\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003etrigger\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003etype\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003emanual | interval | schedule | github_event | api_event\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003escope\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003erepositories\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003etarget-repository\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eallowed_paths\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003esrc/**\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003etests/**\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eprohibited_paths\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eproduction/**\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003esecrets/**\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003etask\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eobjective\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003e変更または処理する目標\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003einput\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003e新しく入ってくるIssue、Event、Fileまたは状態\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003everification\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ecommands\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eunit-test\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eintegration-test\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003elint\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003ebuild\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eruntime_checks\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003ebrowser-interaction\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003econsole-errors\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eaccessibility\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eevidence\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003ecommand-output\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eexit-code\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003etest-summary\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003escreenshots\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003esuccess\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003econdition\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003e真偽で判定可能な完了状態\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003estop\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003emax_turns\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003e12\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003emax_duration_minutes\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003e45\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003emax_consecutive_failures\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003e3\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003estop_on_permission_error\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eescalate_on_external_outage\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003eside_effects\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eidempotency_key\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003eevent-id-or-commit-sha\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eallow_branch_push\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003eclaude/*\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003erequire_human_for_merge\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003erequire_human_for_deploy\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003ereview\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eindependent_agent\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eadversarial_review\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003eobservability\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ereport_progress\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ereport_token_usage\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ereport_changed_files\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ereport_remaining_failures\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e最も重要な項目は、プロンプト文そのものより次の5つだ。\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eTrigger\n\u003c/span\u003e\u003cspan\u003eVerifier\n\u003c/span\u003e\u003cspan\u003eSuccess condition\n\u003c/span\u003e\u003cspan\u003eHard stop\n\u003c/span\u003e\u003cspan\u003ePermission boundary\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003ch2\u003e\u003ca href=\"#11-どのloopを選ぶべきか\" class=\"anchor\" id=\"11-どのloopを選ぶべきか\"\u003e\u003c/a\u003e11. どのLoopを選ぶべきか\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e状況\u003c/th\u003e\n\u003cth\u003e推奨方式\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003e1回の修正と検証で終わる作業\u003c/td\u003e\n\u003ctd\u003eTurn-based\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e複数回試す必要があるが完了状態が明確な作業\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/goal\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e外部CI・PR・デプロイ状態をしばらく待つ必要がある作業\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/loop\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eノートPCを閉じても反復実行する必要がある業務\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/schedule\u003c/code\u003e Routine\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eGitHubイベントやAlertに即時反応しなければならない業務\u003c/td\u003e\n\u003ctd\u003eEvent-triggered Routine\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e数百項目を並列処理し、相互検証しなければならない業務\u003c/td\u003e\n\u003ctd\u003eDynamic Workflow\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e入力と出力ルールが完全に決定論的な変換\u003c/td\u003e\n\u003ctd\u003eScriptまたはCI Job\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e選択順序は「最も強力な機能」ではなく、「目標を達成する最も単純な制御構造」を基準にすべきだ。\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#12-安全な導入順序\" class=\"anchor\" id=\"12-安全な導入順序\"\u003e\u003c/a\u003e12. 安全な導入順序\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e人が繰り返し確認しているボトルネック業務を1つ選ぶ。\u003c/li\u003e\n\u003cli\u003eまず検証手順をSkill、Script、CIとして作る。\u003c/li\u003e\n\u003cli\u003eTurn-based方式で検証品質を安定化する。\u003c/li\u003e\n\u003cli\u003e完了状態が明確なら\u003ccode\u003e/goal\u003c/code\u003eを付ける。\u003c/li\u003e\n\u003cli\u003e外部状態を待つ必要があるときだけ\u003ccode\u003e/loop\u003c/code\u003eを使う。\u003c/li\u003e\n\u003cli\u003e長期実行が必要なら\u003ccode\u003e/schedule\u003c/code\u003e Routineへ移す。\u003c/li\u003e\n\u003cli\u003e冪等性、権限、コストが検証された後にのみDynamic WorkflowとProactive Loopへ拡張する。\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2\u003e\u003ca href=\"#13-よくある誤解\" class=\"anchor\" id=\"13-よくある誤解\"\u003e\u003c/a\u003e13. よくある誤解\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e誤解\u003c/th\u003e\n\u003cth\u003e正確な解釈\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eLoopは無限実行だ\u003c/td\u003e\n\u003ctd\u003e成功条件とHard stopがある制限付き反復構造だ\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eAgentの完了報告は検証だ\u003c/td\u003e\n\u003ctd\u003e外部コマンド出力、終了コード、Runtime結果が必要だ\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/goal\u003c/code\u003eがすべての権限を自動許可する\u003c/td\u003e\n\u003ctd\u003e次のTurnだけを自動開始し、権限ポリシーは別物だ\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop\u003c/code\u003eは長期運用Schedulerだ\u003c/td\u003e\n\u003ctd\u003eセッション中心であり、7日で期限切れになることと実行環境の制約がある\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eAgentが多いほど結果が良くなる\u003c/td\u003e\n\u003ctd\u003e役割・観点・検証が異なるときだけ並列化の価値が生まれる\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eすべての反復作業はLLMがすべきだ\u003c/td\u003e\n\u003ctd\u003e決定論的な部分はScriptのほうが安く、再現性が高い\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\u003ca href=\"#結論\" class=\"anchor\" id=\"結論\"\u003e\u003c/a\u003e結論\u003c/h2\u003e\n\u003cp\u003eLoop Engineeringは、AIを長時間実行させる技術ではなく、\u003cstrong\u003eAIが間違ったときに自ら発見し、コスト上限内で修正し、危険な地点では止まるようにする制御システム設計\u003c/strong\u003eだ。\u003c/p\u003e\n\u003cp\u003eLLMは探索、推論、実装、例外分析、代替案比較に強い。システムは実行時点、変更範囲、検証方法、終了基準、コスト上限、承認境界を担当すべきだ。この役割分担が明確であるほど、Claude Code自動化は単なるコード生成ツールを超え、再現可能で監査可能な開発運用システムに近づく。\u003c/p\u003e\n","tags":["Claude Code","ループエンジニアリング","AIエージェント","開発自動化","エージェントワークフロー"],"faqs":[{"question":"Claude CodeのLoopは、一般的なfor・whileの反復文と何が違いますか？","answer":"一般的な反復文は、コードに定義された命令を決定論的に繰り返します。Claude CodeのLoopは、Agentがコードと外部状態を観察し、次の行動を推論し、ツールを実行し、結果を検証したうえで、終了条件に応じて再び作業するエージェント制御構造です。"},{"question":"Turn-based Loopはいつ最も適していますか？","answer":"短く単発で、ユーザーが結果をすぐに確認できる作業に適しています。ただし、UI・API・データベースのように検証手順が繰り返される場合は、その手順をSkillやScriptとして作成し、Claudeが同じ基準で自己検証できるようにするのがよいです。"},{"question":"`/goal`評価モデルはファイルとテスト結果を直接確認しますか？","answer":"いいえ。評価モデルはツールを呼び出したりファイルを直接読んだりせず、Goal条件と会話に表れた証拠を判断します。作業Claudeがテストコマンド、終了コード、変更ファイル、失敗原因を結果に明確に残す必要があります。"},{"question":"良い`/goal`条件には何を含めるべきですか？","answer":"測定可能な完了状態、その状態を証明するコマンドやツール、変更可能な範囲と禁止範囲、最大Turn・時間・連続失敗のようなHard stopが必要です。「きれいにリファクタリング」よりも、「テストとlintの終了コードが0で、指定パス外のDiffがない」のほうが良い条件です。"},{"question":"`/goal`には自動の最大Turnや時間制限がありますか？","answer":"Goalは、評価モデルが成功を判定するか、ユーザーが`/goal clear`で中断するまで続きます。実行予算を制限するには、「最大12ターンまたは45分後に中断」のように、Goal条件にTurn・時間の条項を直接含める必要があります。"},{"question":"`/goal`を使用すると、ツール権限も自動的に許可されますか？","answer":"いいえ。`/goal`は次のTurnを自動的に開始しますが、ファイル書き込み、Shell、Git、外部Connectorの権限ポリシーはそのまま維持されます。無人実行が必要な場合はAuto modeを検討しつつ、`ask`・`deny`ルールで危険な作業を別途制御する必要があります。"},{"question":"`/loop`と`/schedule`の最大の違いは何ですか？","answer":"`/loop`は、現在のClaude Codeセッションとコンピューターで反復実行する短期のPolling手段です。`/schedule`はPromptとRepository、Connector、TriggerをCloud Routineとして保存し、Anthropic管理インフラで実行するため、開いているセッションや起動中のノートPCは必要ありません。"},{"question":"コンピューターをオフにすると、`/loop`は実行され続けますか？","answer":"一般的には実行され続けません。`/loop`はセッション範囲の作業であり、Claude Codeが実行中である必要があります。長期自動化にはCloud Routine、Desktop scheduled task、GitHub Actionsのような持続可能なSchedulerを使用する必要があります。"},{"question":"時間PollingよりEvent Triggerのほうが良い理由は何ですか？","answer":"変化がないときに不要なモデル呼び出しを発生させず、実際の変更直後に実行できるためです。CI失敗、PR更新、Alertのようにイベントを発行できるシステムは、GitHub TriggerやRoutine APIで接続するほうが、コストと遅延の両面で有利です。"},{"question":"検証手順を`CLAUDE.md`ではなく`SKILL.md`に置く理由は何ですか？","answer":"`CLAUDE.md`はプロジェクト全体に常に適用する短いルールに適しており、Skillは特定の作業でのみ必要な手順とサポートファイルをまとめるのに適しています。長い検証チェックリストをSkillとして分離すれば、関連する作業でのみロードし、直接再実行できます。"},{"question":"Dynamic Workflowは一般的なSubagent呼び出しとどう違いますか？","answer":"一般的なSubagent方式では、ClaudeがTurnごとに次の作業者を選択し、結果がContextに蓄積されます。Dynamic WorkflowはJavaScript Scriptが並列実行、分岐、反復、中間結果を管理するため、大規模なMigration・Audit・クロス検証をより再現可能な形で組織できます。"},{"question":"複数のAgentを使用すると、常に品質は向上しますか？","answer":"いいえ。役割と観点が重なると、同じエラーを繰り返しながらコストだけが増える可能性があります。実装、テスト設計、セキュリティレビュー、回帰分析、Judgeのように責任を分離し、各結論に独立した証拠を求めてこそ、並列Agentの価値が生まれます。"},{"question":"Time-basedまたはProactive Loopで重複作業はどのように防ぎますか？","answer":"Event ID、Commit SHA、Review Comment IDのようなIdempotency keyと最後の処理状態を保存する必要があります。すでに回答したメッセージ、すでに作成したPR、すでに処理したCommitを再処理しないというルールを検証段階に含める必要があります。"},{"question":"最初に自動化するLoopはどのような業務がよいですか？","answer":"人が繰り返し確認するものの、危険なSide effectは少なく、完了状態を明確に測定できる業務が適しています。たとえば、PRの失敗したCI原因の要約、ドキュメントとコードの不一致検出、定められたテスト・lint検証から始め、その後、修正とPush権限を段階的に拡大していく方法が安全です。"}],"sources":[{"url":"https://claude.com/blog/getting-started-with-loops","title":"ループエンジニアリング：ループ入門 | Claude by Anthropic","type":"source"},{"url":"https://code.claude.com/docs/en/skills","title":"スキルでClaudeを拡張する - Claude Code Docs","type":"source"},{"url":"https://code.claude.com/docs/en/goal","title":"Claudeが目標に向かって作業を続けられるようにする - Claude Code Docs","type":"source"},{"url":"https://code.claude.com/docs/en/scheduled-tasks","title":"スケジュールに従ってプロンプトを実行する - Claude Code Docs","type":"source"},{"url":"https://code.claude.com/docs/en/routines","title":"ルーチンで作業を自動化する - Claude Code Docs","type":"source"},{"url":"https://code.claude.com/docs/en/workflows","title":"動的ワークフローでサブエージェントを大規模にオーケストレーションする - Claude Code Docs","type":"source"},{"url":"https://claude.com/blog/claude-model-and-effort-level-in-claude-code","title":"Claude CodeでClaudeモデルとエフォートレベルを選択する | Claude by Anthropic","type":"source"},{"url":"https://code.claude.com/docs/en/auto-mode-config","title":"自動モードを設定する - Claude Code Docs","type":"source"}],"images":[{"id":195,"url":"https://injoys.com/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsiZGF0YSI6MTg3OSwicHVyIjoiYmxvYl9pZCJ9fQ==--cac49ec584371c2261bd3272e7574ca38ecc1f85/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2016%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2006_56_28.webp","is_representative":true,"generation_method":"upload","mime_type":"image/webp","original_filename":"ChatGPT Image 2026년 7월 16일 오후 06_56_28.png","translations":{"ko":{"alt":"AI 로봇과 코드 화면을 중심으로 반복 화살표, 목표·시간·보안·비용 아이콘이 연결된 자동화 구조","caption":"관찰·실행·검증을 반복하는 AI 에이전트와 목표, 일정, 권한, 강제 종료, 비용 제어 요소를 함께 보여준다.","description":null},"en":{"alt":"AI robot and code dashboard surrounded by loop arrows, goal, schedule, security, and cost control icons","caption":"The illustration shows an AI agent repeating observation, action, and verification within goal, timing, permission, stop, and cost controls.","description":null},"ja":{"alt":"AIロボットとコード画面を中心に、循環矢印、目標、時間、安全、コスト管理のアイコンが連結された構成","caption":"観察・実行・検証を繰り返すAIエージェントを、目標、実行時期、権限、停止、コストの制御要素とともに示している。","description":null},"es":{"alt":"Robot de IA y panel de código rodeados por flechas de ciclo e iconos de objetivo, tiempo, seguridad y coste","caption":"La ilustración muestra un agente de IA que repite observación, acción y verificación bajo controles de objetivo, tiempo, permisos, parada y coste.","description":null},"id":{"alt":"Robot AI dan dasbor kode dikelilingi panah loop serta ikon tujuan, waktu, keamanan, dan biaya","caption":"Ilustrasi menampilkan agen AI yang mengulang observasi, tindakan, dan verifikasi dengan kontrol tujuan, waktu, izin, penghentian, dan biaya.","description":null},"pt":{"alt":"Robô de IA e painel de código cercados por setas de ciclo e ícones de meta, tempo, segurança e custo","caption":"A ilustração mostra um agente de IA repetindo observação, ação e verificação sob controles de objetivo, tempo, permissão, parada e custo.","description":null},"zh-hant":{"alt":"AI 機器人與程式碼面板置於循環箭頭中央，周圍連結目標、時間、安全與成本控制圖示","caption":"圖中呈現 AI 代理在目標、排程、權限、強制停止與成本控制下反覆觀察、執行與驗證。","description":null}}},{"id":196,"url":"https://injoys.com/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsiZGF0YSI6MTg4NiwicHVyIjoiYmxvYl9pZCJ9fQ==--e5ead4b7a604375b9c6a192eb3a981cf4c93b3c9/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2016%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2007_02_56.webp","is_representative":false,"generation_method":"upload","mime_type":"image/webp","original_filename":"ChatGPT Image 2026년 7월 16일 오후 07_02_56.png","translations":{"ko":{"alt":"보호 울타리 안의 AI 에이전트가 검증, 중단 장치, 권한 게이트와 비용 계측을 거쳐 작업하는 자동화 구조","caption":"트리거부터 검증과 강제 중단, 자원 관리, 승인된 결과 출력까지 안전하게 통제되는 에이전트 워크플로를 보여준다.","description":null},"en":{"alt":"AI agent inside a guarded workspace with verification, stop controls, permission gates, and resource monitoring","caption":"The illustration shows an agent workflow controlled from triggers through validation, hard stops, resource checks, and approved output.","description":null},"ja":{"alt":"検証、強制停止、権限ゲート、資源監視に囲まれた保護領域内のAIエージェント","caption":"トリガーから検証、停止制御、コスト管理、承認済み出力まで安全に統制されたエージェント処理を表している。","description":null},"es":{"alt":"Agente de IA en un entorno protegido con verificación, parada forzada, permisos y control de recursos","caption":"La ilustración muestra un flujo de agente controlado desde los disparadores hasta la validación, los límites y la salida aprobada.","description":null},"id":{"alt":"Agen AI dalam area terlindungi dengan verifikasi, penghentian paksa, gerbang izin, dan pemantauan sumber daya","caption":"Ilustrasi ini menunjukkan alur agen yang dikendalikan dari pemicu hingga validasi, batas aman, pemantauan biaya, dan keluaran yang disetujui.","description":null},"pt":{"alt":"Agente de IA em área protegida com verificação, parada forçada, controle de permissões e monitoramento de recursos","caption":"A ilustração mostra um fluxo de agente controlado desde os gatilhos até a validação, os limites de segurança e a saída aprovada.","description":null},"zh-hant":{"alt":"受保護工作區中的AI代理，周圍設有驗證、強制停止、權限閘門與資源監控","caption":"圖中呈現從觸發、驗證、停止控制與成本監測，到核准輸出的安全代理工作流程。","description":null}}}],"published_at":"2026-07-17T09:40:17+09:00","updated_at":"2026-07-17T09:40:17+09:00","license":"cc_by","translation_status":"reviewed","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant"],"url":"https://injoys.com/ja/articles/claude-code-loop-engineering-guide"}