Claude Code を使うとき、つい「いいプロンプトを書けば何とかなる」と考えがちです。私もその感覚はよくわかります。1回きりの質問なら、それで十分なことも多い。でも、同じような作業を何度も回す、途中の結果を確認する、前回の状態を覚えておく、となると話は変わります。そこで必要になるのが、単発の指示ではなく「loop」という考え方です。
元記事は、Youssef Hosni氏が Medium の Level Up Coding に書いたもので、Claude Code を使った agentic automation、つまり「AI にある程度の自律性を持たせて作業を進める仕組み」をどう設計するかを扱っています。面白いのは、AI をいきなり全自動にするのではなく、まずは安全で नियंत्र可な形で回し、少しずつ賢くしていく発想にあると思います。
TASK.md、LOOP_INSTRUCTIONS.md、PROGRESS.md、outputs/ フォルダを使った最小構成から始める/loop による定期実行、権限の分離、外部連携を足していく普通のAI活用は、だいたいこうです。人が質問する。AIが答える。人が見て、次の質問を考える。これでも便利です。でも、同じ流れを何十回も繰り返すなら、毎回ゼロから考えるのはかなり面倒です。しかも、途中の状態が人の頭の中にしかないと、抜け漏れが起きやすい。
そこで loop です。この記事でいう loop は、単なる「繰り返し処理」ではありません。Claude が何を読んで、何をしてよくて、どうやって結果を確かめ、どこに記録を残し、いつ止まるかまで含めた、ひとまとまりの運用設計です。
ここが地味に重要です。AI は賢いけれど、勝手に気を利かせてくれる存在ではありません。むしろ、仕組みが雑だと、毎回ちょっとずつズレたことをやり始める。だから loop は、AI に自由を与えるためのものというより、自由に動いても破綻しないための「柵」だと私は思います。
元記事では、最初の一歩として TASK.md、LOOP_INSTRUCTIONS.md、PROGRESS.md、それに outputs/ フォルダを使う案が出てきます。
名前からだいたい想像できますが、TASK.md は何をやるかを書く場所、LOOP_INSTRUCTIONS.md はその進め方やルールを書く場所、PROGRESS.md は今どこまで終わったかを残す場所です。outputs/ は、作った成果物や途中生成物を置く場所でしょう。こういう構成は派手さはないですが、かなり実務的です。
個人的には、ここがこの話の一番おもしろいところでした。最先端っぽい話に見えて、やっていることは「ファイルを分けて、状態を見えるようにする」なんですよね。結局、信頼できる自動化は、魔法ではなく整理整頓から始まる。かなり人間くさい発想です。
この記事が強調しているのは、Claude をただ繰り返し動かすだけでは不十分だということです。大事なのは verification、つまり検証です。AI はそれっぽいものを出すのは得意でも、正しいかどうかの保証は別問題だからです。
たとえば、毎回の出力をそのまま次の処理に渡すと、ひとつの小さなミスがループ全体に広がることがあります。だから「出力した」「終わった」で終わらせず、チェックする工程を入れる。これは地味ですが、実運用ではここが命綱になるはずです。
私はここに、AI 自動化の本質があると思っています。AI を使う最大の難しさは、生成そのものより、生成結果をどう信用するかです。だから loop engineering では、能力の話よりも、監視と確認の設計の方がむしろ大事になる。
この記事では persistent state、つまり状態を持ち続ける仕組みも扱います。人間なら「前回どこまでやったか」を覚えていますが、AI は毎回その記憶を持っているとは限りません。だから PROGRESS.md のようなファイルに記録して、次回の実行でも参照できるようにするわけです。
この発想はかなり実用的です。たとえば、調査、テスト、文書作成、コード修正のような作業は、1回で終わらないことが多い。途中の判断や失敗の履歴が残っていないと、毎回同じ穴に落ちます。状態を外に出しておくことで、Claude は「前提を引き継ぎながら進む道具」に近づく。
ここは AI というより、良い現場運営の話に近いです。仕事ができるチームって、だいたい記録がうまい。loop も同じで、覚えていることが価値になります。
/loop のような定期実行は、雑務を減らす方向に効く元記事では scheduled execution、つまりスケジュール実行にも触れています。/loop のような仕組みで定期的に動かせば、人が毎回起動しなくてもよくなる。これはたとえば、毎朝のチェック、状態変化の監視、決まった手順の反復に向いています。
ただし、ここで気をつけたいのは「定期実行できる」ことと「安心して放置できる」ことは別だという点です。自動化は、止め方が設計されていないと怖い。だからこそ、この記事が controlled workflow を強調しているのは筋が通っています。全自動より、管理できる自動化のほうが先です。
安全な permission boundaries、つまり権限の境界線をしっかり決める話も出てきます。AI に何でもさせると気持ちはよさそうですが、実際には危ない。読めるファイル、書ける場所、実行できるコマンドを分けておくほうが、ずっと現実的です。
この辺りは、セキュリティの基本をそのまま AI ワークフローに持ち込んでいる感じです。派手ではないけれど、こういう制限があるからこそ運用できる。自由度の高い道具ほど、境界線が大事になります。
元記事では optional connectors も示されています。つまり、必要に応じて外部サービスやツールとつなげるということです。ここまで来ると、Claude は単に文章を返す存在ではなく、周辺の道具とつながった作業のハブになります。
ただ、私はこの段階では少し慎重でいたいです。つなげればつなげるほど便利ですが、同時に複雑になります。だから順番としては、最小構成で安定して回す → 検証を入れる → 状態を持たせる → そのあとで外部連携、が自然だと思います。記事の流れも、まさにその順番でした。
この記事の価値は、Claude Code を「賢いチャット相手」から「繰り返し動く作業システム」に見立て直しているところにあります。しかも、いきなり大げさな自律エージェントを作るのではなく、ファイル、記録、検証、権限、スケジュールという、かなり現実的な部品で組み立てようとしている。
私はこういう設計思想がかなり好きです。AI の未来っぽい話をしながら、実際には地味な運用の工夫に落とし込んでいるからです。派手なデモより、ちゃんと回る仕組みのほうが強い。この記事は、その感覚をはっきり言語化している印象でした。
参考: How to Create Loops with Claude Code: A Practical Guide to Agentic Automation