気づいたら記事もloopで、組織もそうなっていくのかな
Loop Engineering が話題だけど、僕はまだ /loop をちゃんと使ったことがなかった。記事を書くのも検証ループになっていた、という小さい気づきから、これからどう使い込むか、そして組織にも loop を広げられるんじゃないか、というところまで考えてみた。
最近 loop って言葉をよく見る
少し前に /goal の記事を書いた。目的地を渡すと、そこに着くまで自動でループして動いてくれる、というやつ。
あれを書いたあたりから、タイムラインで「loop」とか「Loop Engineering」って言葉をやたら見るようになった。ざっくり言うと、もう自分でエージェントに毎回プロンプトを打つんじゃなくて、エージェントを叩く側を仕組みにしちゃおう、みたいな話。Claude Code を作ってる Boris Cherny が「もう Claude にプロンプトしてない、僕の仕事は loop を書くこと」って言ってたのが発端っぽい。
Addy Osmani がそのへんをまとめてくれてる。
addyosmani.com仕組みの話としては、OpenAI が Codex の agent loop の中身を解説してたり、
openai.comAnthropic 側も Agent SDK の loop はこう動く、ってドキュメントを出してる。
code.claude.com中身は両者でちょっと違うけど、だいたい「文脈を集める → 動く → 検証する → また繰り返す」っていう同じ形に落ち着いてるらしい。
正直、まだ使ってなかった
で、ここまで書いておいてなんだけど、僕はまだ /loop をちゃんと使ったことがなかった。
/goal は触ったし記事も書いたのに、loop のほうは「へぇ便利そう」で止まってた、というのが正直なところ。なんとなく、ちゃんとした自動化を組まないと使えないやつ、みたいなイメージがあったんだと思う。定期実行で夜中に勝手に走らせる、みたいな。そこまでやることないしな、と。
記事を書くのにも loop が顔を出した
ところがこの記事を書いてて気づいたんだけど、僕はもう小さい loop なら回してた。
このブログは記事を出す前にいくつかチェックを通すことになってて、日本語の文体を見る textlint と、コンテンツをビルドする velite build がある。で、これを「通るまで直して、また流す」っていうのを毎回やってる。怒られて、直して、また流して、また別のところで怒られて、を繰り返すやつ。
これ、まさに「動く → 検証する → また繰り返す」の loop じゃん、と。大層な自動化じゃなくても、検証を挟んで回すのが loop なんだなと、書いてて腑に落ちた。
Boris が別のところで「Claude に自分の仕事を検証する手段を渡すと、最終成果の品質が 2〜3 倍になる」って言ってて、Delba Oliveira がその検証ループの話を丁寧に分解してた。
@bcherny on X要は、loop の半分は「回す設計」で、もう半分は「No と言える検証」なんだと思う。textlint がまさにそれで、僕の文章に容赦なく No を出してくる。
実際、この記事もその検証ループを意識して仕上げた。下書きを書いて、textlint を流して、怒られたら直して、また流す。green になるまで繰り返す前提で構えてた。正直に書くと今回は一発で通っちゃって拍子抜けしたんだけど、その「通るまで回す」を最初から前提に置いてること自体が、もう僕の中で loop になってるんだなと思った。
もっと使い込むなら、増やすのは検証な気がする
じゃあこれからどう使い込んでいくか。
たぶん最初にやるのは、自動化を派手にすることじゃなくて、検証を増やすことだと思う。今は textlint と velite build だけど、たとえば「事実関係おかしくない?」とか「前に書いた記事と矛盾してない?」みたいな、人間がやってたチェックを一個ずつ loop に足していく。/loop を間隔なしで回して、通るまで直す、みたいな使い方なら、夜中の自動化とか組まなくても今日から始められる。
逆に言うと、検証が雑なまま回す数だけ増やしても意味がなくて、むしろ怖い。Addy Osmani も loop のリスクとして「検証責任が薄くなる」「理解度が下がる」「思考停止する」みたいなことを挙げてた。回せば回すほど、自分が中身を分かってない成果物が増えていく、というのは普通にありえる。だから増やすべきは回転数じゃなくて、ちゃんと No を出せる検証のほう、という感じがしてる。
組織も loop なんじゃないか、と考え始めてる
ここまで個人の手元の話なんだけど、書いてて、これ組織でも同じ構造だなと思い始めた。
Loop Engineering の肝って「自分がプロンプトする側をやめて、loop を設計する側に回る」ことだと思うんだけど、これマネジメントでずっと言われてきたことにすごく似てる。毎回細かく指示する(=人にプロンプトする)んじゃなくて、放っておいても回る仕組みを作りましょう、っていうやつ。新しい話ではない。
何が変わったかというと、その loop の中で回ってる作業の一部を、AI が担えるようになってきたことだと思う。今まで人がやってた「集める・動く・検証する」のうち、定期的な確認とか、一次チェックみたいなところを AI loop に持たせられる。特に「検証(No と言える)」は、組織だと得てして特定の人やレビュー工程に詰まりがちで、そこに self-verification を差し込めると、人はもっと判断とか設計のほうに寄れるんじゃないか、と。
ただ、個人でも怖いと書いたリスクは、組織だともっと怖い。誰も中身を分かってないけど回ってる、検証も AI 任せで人は判定の判定をしてない、みたいになると、たぶん早晩おかしくなる。なので組織で loop をやるなら、loop を設計する人と、検証そのものを検証する人が、今までより大事になる気がしてる。叩く人が減るぶん、設計と最終的な責任を持つ人の比重が上がる、というか。
正直、これを自分の組織でちゃんとやれてるかというと、ぜんぜんで、まだ考え始めてるだけ。記事を書く手元の loop からそこまで地続きに見えてきた、というところで、今日のところは止めておく。loop、思ってたよりずっと地味なところから始まって、思ってたより広いところまで伸びてる気がしてる。