loop を増やしていく話、手元の検証から組織の未来まで

最近「loop」って言葉をやたら見る。僕にとってはもう普段の回し方になってるので、目新しいというより「これをこの先どう増やしていくか」のフェーズに入ってる。で、手元の小さい loop から、組織の未来の話まで、思ってたより地続きだったので一本にまとめる。

最近 loop って言葉をよく見る

少し前に /goal の記事を書いた。目的地を渡すと、そこに着くまで自動でループして動いてくれる、というやつ。

shinofara.dev

あれを書いたあたりから、タイムラインで「loop」とか「Loop Engineering」って言葉をやたら見るようになった。ざっくり言うと、もう自分でエージェントに毎回プロンプトを打つんじゃなくて、エージェントを叩く側を仕組みにしちゃおう、みたいな話。Claude Code を作ってる Boris Cherny が「もう Claude にプロンプトしてない、僕の仕事は loop を書くこと」って言ってたのが発端っぽい。

addyosmani.com openai.com code.claude.com

まとめも、仕組みの解説もいろいろ出てるけど、だいたい「文脈を集める → 動く → 検証する → また繰り返す」っていう同じ形に落ち着いてるらしい。

一番効いてるのは「検証して回す」ところ

普段 loop を回してて一番効いてるのは、派手な自動化じゃなくて「検証を挟んで、通るまで回す」ところだと思ってる。

一番地味な例だと、このブログは記事を出す前に textlint と velite build を通す。怒られて、直して、また流して、また別のところで怒られて、を繰り返す。これも立派な「動く → 検証する → また繰り返す」の loop で、大層な自動化じゃなくても、検証を挟めば loop になる。

Boris が別のところで「Claude に自分の仕事を検証する手段を渡すと、最終成果の品質が 2〜3 倍になる」って言ってた。

@bcherny on X

要は、loop の半分は「回す設計」で、もう半分は「No と言える検証」。textlint がまさにそれで、僕の文章に容赦なく No を出してくる。回す側の道具は揃ってきたので、伸ばすべきは検証のほうだと思ってる。

今、手元で回ってる部品

冒頭の Loop Engineering の記事は、ループを5つの部品＋メモリで整理してる。自動化・worktree・スキル・コネクタ・サブエージェント、それと状態を覚えておく場所。これを「今、手元で開発してるもの」に当てはめると、だいたい揃ってる。スキルは繰り返す手順の手順書、コネクタで Slack や Linear まで手が届き、worktree とサブエージェントで別 topic を並行で回す。メモリは AGENTS.md / CLAUDE.md（忘れるのはエージェントで、忘れないのはリポジトリ）と、次に何を作るかを積む issues。たまたま今いじってるのがこのブログってだけで、対象が何であれ部品は同じだと思う。

で、最近この部品を一個、自分で足した。成果物にペアがある時、片方だけ直して片方を忘れたまま終わろうとしたら止める検証。日本語を直して英語版を忘れたら終了時に止まる Stop フックで、中身は git の差分で「ja だけ変わって en が変わってない」を見てるだけ。これも「No と言える検証」を loop に足す部品で、必要なぶんだけ少しずつ増やしてる。

ここからどう増やしていくか

で、ここからが本題。loop はもう回ってるので、次にやりたいのは「増やす」ことなんだけど、増やす対象を間違えたくない。

増やすべきは回転数じゃなくて、検証のほうだと思ってる。今の検証は textlint と velite build くらいだけど、ここに「事実関係おかしくない?」とか「前に書いた記事と矛盾してない?」みたいな、これまで人間がやってたチェックを一個ずつ loop に足していく。/loop を間隔なしで回して通るまで直す、みたいな使い方なら、夜中の自動化を組まなくても積み上げられる。検証が増えるほど、安心して回せる範囲が広がる、という順番でいきたい。

逆に、検証が雑なまま回す数だけ増やすのは怖い。Loop Engineering の記事でも、loop のリスクとして「検証責任が薄くなる」「理解度が下がる」「思考停止する」が挙げられてた。ループが勝手にやってくれるほど、自分が中身を分かってない成果物が増えていく。便利すぎて「とりあえず出てきたやつでいいや」になると、たぶん良くない。同じループでも、わかってる仕事を速くするために使う人と、わかるのをサボるために使う人とで、結果が逆になる。だから僕は、回す側を増やす前に検証を増やす、最終的な判定とマージは自分の手元に残す、という順番を守りたい。

ループは複利で効く資産になる

検証を足していく、というのを「ただの品質管理」だと思ってたんだけど、サティア・ナデラの長文ポストを読んで、もう一段上の意味があるなと思った。

@satyanadella on X

ナデラはこれからの企業は2つの資本を持つ、と言ってる。人の知識・判断・パターン認識みたいな human capital と、自社で構築して所有する AI 能力＝token capital。で、本当の勝負はベストなモデルを選ぶことじゃなくて、モデルの上に乗る learning loop を作って、その2つを複利で増やすことだ、と。一番刺さったのがこの一文。

タスクや仕事は手放せても、自分の学習は手放せない

これ、さっきの「検証をサボると理解してない成果物が増える」と完全に同じことを言ってる。ループにタスクを手放すのはいい。でも学習まで手放したら、複利で増えるはずの資産がたまらない。ただトークンを消費してるだけになる。

ナデラの言い方で面白いのは、たまっていく暗黙知が、ベースモデルじゃなくて自分のループ側に乗る、というところ。だからモデルを差し替えても「会社の熟練者」の知は残る。これ、抽象論に聞こえるけど、僕の手元にもうミニ実例がある。このブログには僕の文体や避けたい表現を書いた著者ペルソナのファイルがあって、記事を書くたびにエージェントがそれを読む。あれは「捕まえた僕の声」を、AI が再現可能な形にしたもので、まさに「judgment が systems の一部になって replicable になる」やつ。汎用モデルが何に変わろうと、このペルソナは僕の側に残る。

つまり同じ loop でも、トークンを消費してるだけか、token capital を作ってるかは別物。差は「検証して、結果を自分の側に戻してるか」。スキルやペルソナや issues に判断を残すのは、便利さだけじゃなくこの複利のためでもあった。loop を増やすときも「回した結果が自分の側に資産として残るか」を基準にしたい。

ナデラはここから「だから少数のモデルに価値を吸い上げさせず、各社が自分の learning loop を所有できるエコシステムを作ろう」という話に広げてる。これはモデルもプラットフォームも売ってる側のポジショントークでもあるので、全部を鵜呑みにはしない。けど「ループを所有しているか、ただ消費しているか」という問いは、僕の手元のリポジトリでも普通に効く。

結局これ、業務のサイクルそのものだ

ここまで書いてて思ったんだけど、結局この loop って新しい概念でもなんでもなくて、業務のサイクルそのものなんだよね。

たとえば KPI を改善する仕事。KPI を見て、施策を考えて、AB を回して、勝ったら採用する。あるいは問題を見つけて対策を打つ。で、モニタリングして、KPI の変化を見て、また次を考える。ずっと PDCA とか言ってやってきたやつで、「集める → 動く → 検証する → また繰り返す」と完全に同じ形。loop は AI が持ち込んだ概念じゃなくて、僕らがもともと回してたサイクルだ。

じゃあ何が変わるのか。その各ステップを skills とか knowledge に落とせるようになったこと。「KPI はこう見る」「この種の施策はこう設計する」「結果はこう読む」みたいな判断を書いておくと、毎回ゼロからプロンプトを書かなくても loop が回り始める。しかも回すたびに、その skills や knowledge のほうが育っていく。loop を回すこと自体が、loop を賢くしていく。

これがさっきの token capital と地続きで、業務サイクルを skills/knowledge にエンコードして回す＝学習が複利でたまる loop になる。回せば回すほど成長する loop。逆に、skills/knowledge に戻さずに AB だけ回してたら、前と同じ人力の業務サイクルのままで、複利はつかない。

組織も loop になっていくんじゃないか

業務サイクルを skills/knowledge に落として回す、という形は、そのまま組織にスケールする話でもある。

Loop Engineering の肝って「自分がプロンプトする側をやめて、loop を設計する側に回る」ことなんだけど、これマネジメントでずっと言われてきたことにすごく似てる。毎回細かく指示する（＝人にプロンプトする）んじゃなくて、放っておいても回る仕組みを作りましょう、っていうやつ。新しい話ではない。

何が変わるかというと、その loop の中で回ってる作業の一部を、AI が担えるようになること。今まで人がやってた「集める・動く・検証する」のうち、定期的な確認とか一次チェックみたいなところを AI loop に持たせられる。特に「検証（No と言える）」は、組織だと特定の人やレビュー工程に詰まりがちで、そこに self-verification を差し込めると、人はもっと判断とか設計のほうに寄れる。

ただ、個人でも怖いと書いたリスクは組織だともっと怖い。誰も中身を分かってないけど回ってる、みたいになると早晩おかしくなる。だから組織で loop をやるなら、設計する人と、検証そのものを検証する人の比重が上がる。叩く人が減るぶん、設計と最終的な責任を持つ側が大事になる。

そしてナデラの token capital を組織でやるなら、「組織の学習をどこに集約するか」を決めないといけない。さっき個人の話で「issues か Linear か Notion か散らかってる」と書いたけど、組織だとそのまま「組織知をどこに溜めるか決まってない」という話になる。器がバラバラだと、ループが回っても学習が一箇所に複利でたまらない。ここは自分の組織でもまだ全然できてなくて、これから一番考えないといけないところだと思ってる。

これから

loop、地味なところ（textlint に怒られて直す）から始まって、広いところ（組織の学習をどこに溜めるか、価値を誰が持つか）まで地続きに伸びてる。

手元はもう回ってるので、ここから増やしていくのは検証と、「回した結果を自分の側に資産として戻す」ところ。それをサボらずにやれるかどうかで、同じループが消費にも資産にもなる。組織だとその分かれ目がもっと効いてくる。とりあえず自分は、/loop の回転数を上げる前に検証を一個ずつ足して、そのうち組織の学習をどこに集約するか、まで持っていきたい。