背景
Claude CodeのCI/CD自動化コマンド（/loop・/schedule・/goal・/autofix-pr）を組み合わせて開発パイプラインを自動化するハンズオンをやりました。似た用途に見える/loopと/scheduleが、実は「どこで実行されるか」という根本的に異なる設計思想を持っている点が興味深かったです。
1. /loopはローカルセッション、/scheduleはクラウドに常駐する
/loop: ローカルセッション内で定期実行。セッションが終わると停止する
/schedule: クラウドエージェントとして永続化。PCの電源を切っても実行され続ける
/loopはターミナルを閉じれば止まりますが（/bgでバックグラウンドに送らない限り）、/scheduleで登録したルーティンはローカル環境が起動していなくてもクラウド側で動き続けます。「一時的な監視」か「恒常的な定期タスク」かで使い分けます。
2. /loopは間隔省略でモデルが自動ペース調整する
/loop 5m /code-review # 5分ごとに実行
/loop /verify # 間隔省略 → モデルが自動でペースを判断
間隔を明示しない場合、Claude自身が「次の実行まで何秒待つか」を状況に応じて判断します。デプロイ完了待ちなど「条件が満たされるまで待ち続けたい」場面で、固定間隔よりも柔軟なポーリングが可能になります。
3. /scheduleはcron形式でのフル制御が可能
/schedule # ルーティン一覧・管理画面
/schedule create # 新規ルーティン作成
/schedule run <name> # 今すぐ手動実行（テストに便利）
/loopのシンプルな間隔指定と違い、/scheduleはcron形式で「毎週月曜9時」のような複雑なスケジュールを組めます。ただしクラウドエージェントとして実行されるためAPI利用コストが発生し、高頻度な登録前には/schedule runでの手動テスト実行が推奨されます。
4. /goalは終了条件を具体的に書かないとClaudeが判断に迷う
❌ /goal "コードを改善して"（曖昧）
✅ /goal "ESLintエラーをすべて解消して、npm test が全件パスするようにして"（具体的）
/goalはゴールが達成されるまで確認なしで自律的に進み続けます。「何ができたら完了か」を具体的に伝えないと、終了条件の判断がぶれてしまいます。「全テストがパスしたら停止」のように機械的に判定できる条件にするのがコツです。
5. /autofix-prが対応できないケースは設計判断・テスト仕様変更・権限が必要な操作
対応できる: CI失敗の自動修正、lintエラー、型エラー
対応できない: アーキテクチャの見直し、テストの期待値そのものの変更、外部サービスへのアクセス
/autofix-prはPRのレビューコメントを読んで自動対応しますが、コードの書き換えでは解決できない設計レベルの指摘は、Claudeが判断を保留してユーザーに確認を求めます。レビューコメントを具体的に書くほど対応精度が上がる、という運用上のコツもあります。
まとめ
/loop（ローカル・一時的）と/schedule（クラウド・永続的）という実行場所の違いを理解しておくと、CI/CD自動化コマンドの使い分けに迷わなくなります。/goalは終了条件を機械的に判定できる形で具体的に書くことが、自律実行を安全に任せるための鍵でした。