同意チェック一つで、ループはもう自動で回り始めていた ── 5プロジェクト並走で気づいたループエンジニアリングの実感
タグ：AI ClaudeCode ループエンジニアリング Supabase プロダクト開発
はじめに
昨日の夜、19時02分から20時03分までの1時間で、私は同じチェックボックスの文言を5回書き直していた。
作っていたのは「心の重り偏差値マップ」という診断ツールだ。
ACEs（Adverse Childhood Experiences／逆境的小児期体験）と呼ばれる、子ども時代に負った心理的な負荷を、科学的根拠に基づいて数値化するツール単体に絞る予定だったが、それだけでは飽き足らずエビデンスベースの研究結果を7本を統合し、限りなく人生のライフイベントを全網羅するように努めた。現在は任意団体であるが一般社団法人に移行予定の ACEs CARE HUB JAPAN のツールの一つだ。
その夜、私がやっていたのはこういう作業だった。Claude に「これでpushして」と言う。Claude が1〜2行で変更内容を要約してくる。私が「OK」と返す。コミットされて、push される。また直す。また「これでpushして」。
git のログを見返すと、笑ってしまうくらい正直に残っている。
19:02 同意チェックボックスの文言を修正し任意性を明記
19:10 同意チェックボックスの文言を簡潔化
19:50 同意チェックボックスの文言を2行以内に短縮
19:55 同意チェックボックスの文言から補足を削除し1文に短縮
20:03 同意チェックボックスの文言に「政策提言」を追加
同じ画面の、同じチェックボックスの、同じ一文を、1時間で5回。しかもその1時間前の18時01分には、スコアの重み付けを見直して、判定区分を9段階に細分化するという、もっと大きな修正も入れている。
神は細部に宿るという、少しでもユーザーが使いやすく、みやすく、気軽に試せるように妥協はしない設計だ。
このチェックボックスは、ただの同意文言ではない。診断結果のページで、このチェック一つを入れるだけで、匿名化されたデータが自動で Supabase に記録される仕組みになっている。つまり私が1時間かけて磨いていたのは、UI コピーである以上に、ループの入口そのものだった。
この記事は、その一晩の作業を、いま話題になっている「ループエンジニアリング」という枠組みで数え直してみた記録だ。そして書いている途中で、自分自身がこの記事の中で一度、事実誤認をして訂正を受けている。その顛末も含めて書く。
TL;DR
- 「ループエンジニアリング」は2026年6月、元 Google の Addy Osmani 氏が言葉にし、Anthropic が公式に定義づけた考え方。「AI にプロンプトを打つ」から「AI が回るループを設計する」への転換を指す
- 私がやっていた「これでpushして」の繰り返しは、この枠組みでいう最も原始的な形のループ（ターン駆動ループ）にすでに当てはまっていた
- 同意チェックひとつで匿名データが Supabase に自動記録される仕組みはすでに動いており、これは同じ型を使う4つのプロジェクトを並走させたことで、初めて「ループが回っている」という実感につながった
- 5回書き直した理由は「文言が長くて読みにくかった」という単純な話。結果判定を9区分に分けた理由は「当事者の実感と区分がズレていた」という、もっと大事な話だった
- この記事の初稿には、私自身の見落としがあった。「フィードバックは手動でしか反映していない」と書いたが、実際には自動記録の仕組みがすでに動いていた。訂正した経緯も記録として残す
- 判定できるものと、できないもの。この線引きが、次に何を仕組み化すべきかを教えてくれた
ループエンジニアリングとは何か
まず、言葉の出どころを整理しておく。
2026年6月、AI エージェント開発者の Peter Steinberger 氏が「エージェントにプロンプトを打つのはやめて、プロンプトを打つループを設計しろ」という趣旨の発言をした。ほぼ同じ頃、Claude Code のリード開発者である Boris Cherny 氏も、自分はもうプロンプトを打っていない、ループを書いていると語っている。
これを言葉として整理し、広めたのが Addy Osmani 氏だ。2026年6月7日、自身のニュースレターに「Loop Engineering」という記事を公開し、6月22日には O'Reilly Radar にも転載されている。
Loop Engineering | by Addy Osmani – Elevate
https://addyo.substack.com/p/loop-engineering
同じ頃、Claude を開発する Anthropic 自身も公式ブログでこの考え方を定義した。
Loop engineering: Getting started with loops | Claude by Anthropic
https://claude.com/blog/getting-started-with-loops
Anthropic の定義を私の言葉に直すとこうなる。
止まる条件が満たされるまで、作業のサイクルを繰り返すエージェント。
それがループエンジニアリングだ。
短い定義だが、ここに核心がある。「止まる条件」が定義の中に入っている。
逆に言えば、いつ終わるかが決まっていないものは、そもそもループとは呼ばない。
Anthropic の記事では、人間の関与が多い順にループを4種類に分類している。
| 種類 | 何で止まるか | 向いている仕事 |
|---|---|---|
| ターン駆動 | AI 自身が「完了」と判断したとき | 短い、一度きりの作業 |
| ゴール駆動 | 別のモデルが条件達成を確認したとき、または上限回数に達したとき | 終わりを判定できる作業 |
| 時間駆動 | 人間が止めるか、作業が完了したとき | 定期実行、監視 |
| 先回り駆動 | タスクごとにゴールで終わるが、仕組み自体は動き続ける | 定型化された繰り返し作業 |
そして安野貴博氏（エンジニア、起業家、政治家）が2026年7月末、自身の YouTube チャンネルでこの流れを日本語で解説している。
【ゆる解説】ループエンジニアリングって何？／なぜ第一線のエンジニアが「プロンプトを書くな」と言っているのか／"Human in the Loop"から"Human on the Loop"へ
https://www.youtube.com/watch?v=K6KX41tLH2s
安野氏の整理では、AI との関わり方はプロンプト→コンテキスト→ハーネス→ループの4段階で進化する。ハーネスは「AI が安全に、検証されながら作業できる足場」、ループは「その足場の上で、人間が毎回ボタンを押さなくても回り続ける仕組み」にあたる。
自分のログを、この定義に当ててみる
昨夜の作業を、上の表に当ててみる。
「これでpushして」の繰り返しは、ターン駆動ループの、さらに手前の形だった。
私「同意チェックボックスの文言、長すぎるから直して」
↓
Claude が文言を書き直す
↓
Claude が1〜2行で変更内容を要約
↓
私が画面を見て「OK」と判定
↓
コミット・push
↓
（気に入らなければ）また直す
止まる条件は、私の頭の中にしかなかった。「もういいな」と思ったら止める。それだけだ。だから5回かかった。1回目で「まだ長い」、2回目で「まだ堅い」、3回目で「まだ2行を超えている」、4回目で「まだ言葉が足りない」、5回目でようやく「これでいい」。
Anthropic の定義でいう「ターン駆動ループ」は、まさにこれだった。AI 自身の判断で止まるのではなく、私が毎回、目で見て止めていた。 名前を知らなかっただけで、形としては完全にループの中にいた。
そして、この5回の書き直しの先にあったものが、次の話につながる。
そのチェックボックスは、ループの入口だった
このチェックボックスにチェックが入ると、匿名化された診断データが自動で Supabase に記録される。ユーザーが操作するのはチェック一つだけで、その先の記録・保存はすべて自動だ。
つまり私が1時間かけて磨いていたのは、単なる同意文言の読みやすさではなかった。観測（Observation）の入口の精度を上げていたことになる。読みにくい同意文言は、チェックされる率を下げる。チェックされなければ、データは集まらない。データが集まらなければ、そもそもループは回り始めない。
そしてこの仕組みは omori-hensachi 一本だけの話ではない。同じ「同意→自動記録」の型を使ったプロジェクトを、いま4本並走させている。1本ずつ見ていたときは「まだ手作業に近い」という感覚だったが、4本を同時に回してみて初めて、データが積み上がっていく実感が生まれた。1本のループは細くても、4本束ねると、ようやく「回っている」という手応えになる。
二つの修正は、似ていて別物だった
同意文言の5回は、私一人で完結していた。読んで、長いと思ったら削る。判定材料は「読みやすいかどうか」で、これは私の目の前の画面だけで判定できる。
結果判定の9区分への細分化は、そうではなかった。理由は、従来の区分では当事者の実感とズレていたからだ。「自分の背負ってきた重さが、この診断だと正しく反映されない」という違和感が先にあって、それを埋めるために区分を増やした。
この違いは、Anthropic の記事にも安野氏の解説にも出てくる、ある一線と重なる。
AI（あるいは開発者本人）が自分で「できた／できていない」を判定できる仕事は、ループが強く効く。判定材料が自分の外側にある仕事は、外からのフィードバックなしには回らない。
同意文言の修正は前者だった。だから1時間で5往復もできた。9区分の修正は後者だ。当事者の実感というのは、私の画面の中には存在しない。診断を実際に受けた人が「これは違う」と言ってくれなければ、私には永遠に分からない種類の情報だった。
ただし、その「外からのフィードバック」を受け取る経路自体は、もう自動化されている。同意チェック→匿名データが Supabase に溜まる、というところまでは仕組みになっている。まだ仕組みになっていないのは、その先だ。溜まったデータを、いつ・どういう条件で見直しの判断材料として拾い上げるか。ここはまだ、私が気が向いたときにデータを見て、手で判断している。
この記事自体が、一度ひっくり返った
正直に書いておきたい。この記事の投稿で、私は「当事者からのフィードバックを受け取る仕組みが、まだループになっていない」と書いた。手で区分を直しているだけの、ワークフローだと。
それは事実ではなかった。同意チェック一つで匿名データが自動で Supabase に記録される仕組みは、すでに動いている。だから改めて、この記事を書き直した。
これは、調べていた Loop Engineering の議論の中に出てきた話と、そのままつながる。AI に何かを作らせて、最後に「確認してください」と付け足しても、精度はほとんど上がらない。しかし、別の目で検分させると、伸び幅は大きくなる。 自分の答案を自分で採点させない、という原則だ。
この記事の下書きは Claude が書いた。「フィードバックはまだ手動だ」という誤った一文も、Claude が書いたものだ。それを見つけて訂正したのは、実装の詳細を知っている私自身だった。AI が知らないことを、人間だけが知っている。今回それは、ACEs の当事者心理の話ではなく、自分のインフラ構成の話だった。
つまりこの記事そのものが、小さな Human on the Loop の実例になっている。AI が下書きを書き、人間が事実関係を検分し、間違っている箇所だけを押し戻す。そうやって初稿から今の形に直った。
残っている宿題
数え直して、まだ足りていないものが2つある。
一つ目。止まる条件を、事前に書いていない。
昨夜の5回は、たまたま5回で収束した。しかし止まる条件を決めていなかったので、6回目、7回目に続いていた可能性もある。Anthropic の記事は、ゴール駆動ループには最低でも2つの停止条件を持たせるべきだとしている。目的を達成したかどうかの条件と、それとは別に、上限回数や時間による強制停止の条件だ。私にはどちらも書かれていなかった。
二つ目。溜まったデータを、判断材料として拾い上げる周期が決まっていない。
観測（同意→自動記録）は自動化されている。しかし、そのデータを「そろそろ重み付けを見直そう」という判断に変える部分は、まだ私の気分次第だ。定期的に、あるいは一定件数が溜まった時点で、見直し候補として自動的に浮かび上がってくる仕組みにする。そこまでやって、ゴール駆動ループに一歩近づく。
いまの私が持っているのは、ハーネスの一部と、ターン駆動ループと、自動化された観測の入口だ。ゴール駆動ループへの一歩は、まだ踏み出していない。
事実と見立ての切り分け
事実。omori-hensachi のツールは実在し、上記のコミット履歴・時刻は git ログに記録されている実データである。同意チェックにより匿名データが Supabase に自動記録される仕組みは実装済みであり、同じ型を使ったプロジェクトを4本並走させている。Loop Engineering という言葉が2026年6月に Addy Osmani 氏によって整理・発信されたこと、Anthropic が公式に定義を出したこと、安野貴博氏が2026年7月末に日本語で解説動画を公開したことは、いずれも公開情報として確認済みである。
見立て。「5回の修正がターン駆動ループに当てはまる」という分類は、私（田前）自身によるこの記事のための解釈であり、Anthropic や Osmani 氏がこの事例を評価したものではない。「5本束ねて初めてループの実感が生まれた」という感覚も、私個人の体感であり、データで裏づけたものではない。
正直な線引き。この記事は、ループエンジニアリングの教科書ではない。自分の一晩の作業ログを、後から知った枠組みに当てて数え直しただけの記録である。溜まったデータを見直し判断に自動的に変える仕組みは、まだ設計段階にあり、実装はしていない。
おわりに
「これでpushして」を繰り返していたとき、私は方法論のことは何も考えていなかった。ただ、同意文言が長いと感じて、削っていただけだ。
それが後から「ループエンジニアリング」という名前で世界に整理されていたと知って、少し意外だった。しかも、名前を知って初めて、自分のやり方の中で何がすでに仕組みになっていて、何がまだ私の勘に頼っているだけなのかが、はっきり見えるようになった。しかもその見え方自体、一度は間違えて、指摘されて直った。
ACEs CARE HUB JAPAN で目指しているのは、優しさが偶然や自己犠牲に頼らず、制度として機能する仕組みを作ることだ。その一番小さな入口である同意チェックボックスが、実はもうその制度の起点になっていた。気づいていなかったのは、私の側だった。
次にやるべきことは、たぶん新しい概念を輸入することではない。止まる条件を先に書くこと。溜まったデータが見直しの判断に自動的に上がってくる周期を決めること。それだけだ。
今夜もまた、同じチェックボックスを直すことになるかもしれない。そのときは、何回目で止めるかを、先に決めてから始めようと思う。
参考文献・引用元
- Addy Osmani, "Loop Engineering", Elevate (Substack), 2026年6月7日 https://addyo.substack.com/p/loop-engineering
- O'Reilly Radar, "Loop Engineering", 2026年6月22日 https://www.oreilly.com/radar/loop-engineering/
- Anthropic, "Loop engineering: Getting started with loops", Claude Blog https://claude.com/blog/getting-started-with-loops
- 安野貴博, 「【ゆる解説】ループエンジニアリングって何？」, YouTube, 2026年7月 https://www.youtube.com/watch?v=K6KX41tLH2s
関連キーワード
ループエンジニアリング / Loop Engineering / ハーネス / Harness Engineering / Claude Code / AIエージェント / ACEs / Supabase / Care Capitalism / 工場主