Claude Code（Anthropic 製の CLI 型 AIコーディングエージェント）にバックグラウンド実行の仕組みが追加されたと聞いて、業務のスクリプト自動化に応用できないか気になっている開発者もいるかもしれません。
この記事では、AIエージェントに「毎日ループでコードを生成させ続ける」運用を検討している方に向けて、何が起きるか、なぜ危険なのか、自分のプロジェクトが該当するかの確認方法までを整理します。
何が起きるか：ループ実行が「動くコード」を量産する
2026年3月、Anthropicは Claude Code に /loop コマンドを追加しました。
これはローカルの crontab（Linuxでよく使われる時刻指定の定期実行の仕組み）のように、セッションを開いたまま裏でプロンプトを繰り返し実行させる機能です。
具体的には次のようなコマンドが例として紹介されています。
claude --loop 1d create trading strategy which will be profitableこれは1日ごとに「儲かる取引戦略を作れ」という指示を投げ続けるものです。
一見便利に見えますが、実際にこの命令文だけを渡すと、要求が曖昧なまま大量のコードが生成され続けます。
フロントエンドやバックエンドの自動化タスクに置き換えても構造は同じです。
「毎日このAPIを最適化しろ」「毎晩UIコンポーネントを改善しろ」といった曖昧な指示をループで投げると、エージェントは検証基準を持たないまま変更を積み重ねます。
気づいたときには、動くが誰も説明できないコードベースが出来上がっている、という事態になりかねません。
なぜ起きるか：受け入れ基準がないまま自動化している
この問題を段階的に分解すると、原因は大きく2つに分かれます。
1つ目は、要求を具体化できていないことです。
「儲かる戦略を作れ」という指示は、人間同士の会話でも成立しません。
AIエージェントに対しても同様で、曖昧な指示はエージェントの解釈に委ねられ、結果の再現性が失われます。
2つ目は、本番投入前の検証基準（acceptance criteria、成果物が合格かどうかを判定する条件）が存在しないことです。
取引戦略の文脈では「過去の値動きデータでバックテストして基準を満たすか」を指しますが、これはWeb開発における「CIでテストが通るか」「Lighthouseのスコアが閾値を超えるか」と同じ役割を果たします。
検証基準がないままループ実行を続けると、生成物の良し悪しを判定する仕組みがないまま量産だけが進みます。
この2つが揃わない限り、/loop のような自動再実行機能は「効率化」ではなく「制御不能な自動化」になります。
これはエージェント型ツール全般に共通する落とし穴で、GitHub Copilot Workspace や Cursor のバックグラウンドタスクでも同じ構造のリスクが指摘されています。
自分のプロジェクトが該当するか確認する方法
以下のチェックリストで、現在の運用がこの落とし穴に該当するかを確認できます。
- CLAUDE.md やエージェント向けの設定ファイル（システムプロンプトに相当）に「何をしてはいけないか」が明文化されているか
- 生成物を評価する自動テスト・バックテスト・受け入れ基準がリポジトリ内に存在するか
- ループ実行やスケジュール実行の対象コマンドが、単一の狭いタスクに絞られているか（範囲が広すぎないか）
- 生成されたコードに
TODOや副作用のある状態変数（グローバル変数やvar相当のもの）が紛れ込んでいないか - 1回のループ実行が対象とする期間・範囲が明確に区切られているか（無期限の最適化になっていないか）
該当する項目が2つ以上ある場合、ループ実行を止めて設計を見直す価値があります。
対策の手順
実際にAIエージェントの自動再実行を安全に運用するための手順です。
1. 禁止事項を先に書く
CLAUDE.md（またはエージェントの設定ファイル）には、まず「やってはいけないこと」を列挙します。
たとえば「既存ファイルへの逐次追記でごまかさない」「副作用のある状態を持つコードを書かない」「無限に条件を後ろにずらす終了条件を作らない」といった項目です。
これはPineScript（TradingViewのスクリプト言語）向けの指針として紹介されていますが、フロントエンドのコンポーネント生成やAPI連携コードの自動生成にもそのまま応用できます。
2. 対象期間・対象範囲を固定する
1回の生成タスクは、月単位や機能単位など、明確に区切られた範囲に限定します。
複数月・複数機能をまたぐ最適化は、途中で前提条件が変わり、評価そのものが意味を失います。
3. 検証データを先に用意する
本番投入前に評価できるデータセットやテストケースを用意します。
取引戦略であれば過去の値動きデータ、Web開発であればE2Eテストやパフォーマンス計測のベースラインがこれにあたります。
npx @backtest-kit/cli --init --output my-projectこのように、評価用の雛形を先にコマンド一発で生成できる状態にしておくと、ループ実行の各サイクルで機械的に合否判定できます。
4. 1日1回以上のシグナル頻度を確保する
評価対象となる出力が少なすぎると、統計的に意味のある判断ができません。
数日に1回しか成果物が出ない設定は、たまたま上手くいった1件を「成功」と誤認するリスクがあります。
日次以上の頻度で評価できる粒度にタスクを分解しておくことが、判断の信頼性を支えます。
まとめ
/loop のような自動再実行機能そのものは便利な仕組みです。
ただし「曖昧な指示」「検証基準の不在」という2つの穴を放置すると、量産されたコードの品質を誰も判断できなくなります。
手元のプロジェクトでは、まずエージェント向け設定ファイルに禁止事項が書かれているかを確認してください。
次に、生成物を機械的に評価できるテストやバックテストの仕組みがあるかを見直してください。
この2点が揃っていない状態でループ実行を有効化するのは、まだ一歩早いかもしれません。