How I build / Loop
ループ設計
1 件ずつ指示するのをやめて、指示を出す役を仕組みに任せるまで
何を作るかを 1 つずつ指示する代わりに、
指示を出し続ける仕組みを作っている。
この作品集の作品は、1 行ずつ指示して作ったものではない。1 つずつ指示を出す代わりに、AI が同じ手順を自分で回し続ける仕組みのほうを作ってきた。この考え方をループエンジニアリングと呼ぶ。
要点は、速く回すことより、回し始める前に決めておくことにある。何をもって終わりか、どう確かめるか、どこで止めるか、進み具合をどこに残すか、の 4 つだ。
以下では、その仕組みの組み方と、まだ組めていないところを書く。
実測の条件
- 計測日
- 2026-08-01 時点
- 対象
- 手元の開発プロジェクト 52 件と、すべてに共通する設定
- 数え方
- 設定があるかどうかではなく、実際に動いた記録で数えた
このページでは、破線は「未完成・意図的に空・繋がっていない」を表す。
何を設計しているのか
AI をうまく使うために設計するものは、この数年で土台から 4 段積み上がった。図のいちばん下が 2023〜2024、いちばん上が 2026/07。新しい層が古い層に取って代わるのではなく、上に積み重なる。土台が弱いと、上の層も崩れやすい。
-
2026/07
グラフ ループどうしのつなぎ方（どのループが、どこへ何を渡すか）
-
2026/06
ループ AI を回す周期（誰が、いつ起動するか） このページの話
-
2026 初
ハーネス AI を取り囲む足場（どんな道具と決まりを持たせるか）
-
2025
コンテキスト AI に渡す情報一式（何を見せるか）
-
2023〜2024
プロンプト 1 回ごとの指示文（何と言うか） 土台
このページはループの層を扱う。1 つ下のハーネスの層は、ハーネス設計のページにまとめた。AI に持たせる道具と決まりの一式で、権限の設定、決まった場面で自動で走る処理（フック）、役目を 1 つに絞って呼び出す別の AI（専門役）、自分で定義した呼び出しなどが入る。そこで使う手順書は、スキル一覧にある。
回す前に決める 4 つ
人が指示を出さなくても回り続ける仕組み（このページでは「自走」と呼ぶ）は、4 つの条件で支える。1 つ欠けても動きはするが、欠けたぶんの危険は人が引き受けることになる。
自走するループ
ゴール定義
完了を 1 文で言える
検証の関門
機械で合否が出る
停止条件
回数・時間・費用の上限
手順書のみ状態の書き出し
進み具合を会話に溜めない
4 本それぞれについて、欠けると何が起きるかを並べた。「自分の場合」の欄には、自分の環境で何がその条件を受け持っているかを書いた。
条件
ゴール定義完了を 1 文で言える欠けるとどうなるか
何をもって終わりなのか、誰も判断できない自分の場合
始める前に成功条件を 1〜3 行で書く。2 回試して満たせなければ、止めて判断を仰ぐ条件
検証の関門機械で合否が出る欠けるとどうなるか
AI の自己申告を信じるしかなくなる自分の場合
作る役と検査役（どちらも専門役）を分けている。検査役は読むだけで、直さずに報告する。ただし、検査役を呼ばずに進めても機械は止めない。機械で合否が出るのは、ビルドとテストまでだ条件
停止条件回数・時間・費用の上限欠けるとどうなるか
暴走しても走り続け、そのぶん費用がかさむ自分の場合
手順書では決めてある（ゴール定義の欄に書いた、2 回試して満たせなければ止める決まり）。回数・時間・費用の上限を機械で強制する仕組みは、まだ無い（第 05 節）条件
状態の書き出し進み具合を会話に溜めない欠けるとどうなるか
毎回、会話の流れから組み立て直すことになる自分の場合
次に使える結論だけをファイルに書き出す。会話の中に置いたままだと、セッション（1 回の作業のまとまり）が切れた瞬間に消える自走させると、AI の利用量はふつうの作業の 5〜30 倍になり、最悪で 1000 倍に達した（2026-08-01 までの、自分の環境での実測）。停止条件は、この伸びに上限をかけるためのもの。
停止条件そのものは、次の 4 種類を組み合わせるのが定石とされる（この節の冒頭の 4 条件とは別の話。第 07 節の資料による）
- 回数の上限
- 費用の上限
- 進んでいないことの検出
- 異常時の強制停止
実際に効いている習慣
作る役と検査役を分ける
いちばん効いているのはこれで、いちばん地味でもある。
作る役
書き込み権限
検査役
読み取り専用・あら探しの目
同じ AI に書かせて、そのまま採点もさせると、採点が甘くなりがちだ。そこで、別の指示と別の権限を与え、あら探しに徹する検査役を立てる。検査役は、その日の気分で呼ぶものではない。完了を報告する前に必ず通す手順として書いてある。ただし、呼ばずに進めても、機械が止める形にはまだなっていない。
完了を報告する前に通す 2 段（直す側と、報告だけする側）
482回
2026-08-01 までの、スキルの使用記録から数えた。記録が残る呼び出しの中では、いちばん多かった。2 つのうち、検査役にあたるのは「バグ検出」のほう
品質改善297
バグ検出185
権限は 3 段階で渡す
いきなり無人で動かそうとはしない。1 つの段で一度最後まで通してから、次の段に上げる。
L3 無人実行 時刻での起動まで
すべて自動で動き、異常があったときだけ知らせる段。決まった時刻に走る定期実行は、すでにある（12 プロジェクトで 21 本）。足りないのは、ループが自分で仕事を選んで始めるところと、止まったときに気づく仕組みだ（第 05 節）。
L2 検証付き修正 現在地
実装まで進めて、まとまった単位で確かめる段。日常の開発はここ。
L1 報告のみ 通過済み
分析と提案まで。変更は、すべて人が見て承認する段。
1 体で足りるなら 1 体
作業を分けて同時に進めるのが、いつも得とは限らない。数回の操作で終わる作業は、分担させない。小さな仕事を分けると、受け渡しのぶん、手間も時間も倍になる。どう進めるかは、次の表を上から当てはめて決める。
- 1 数回の操作で終わる 分けずに 1 体のまま進める 既定
- 2 ほかと切り離せる調べもので、結果だけ欲しい 専門役を 1 体
- 3 1 つの作業を、完了条件を満たすまで繰り返す 完了条件つきの自走
- 4 決まった間隔で動かす 定期実行（クラウド / 手元の PC）
- 5 10 体以上が要り、段取りが決まっていて、同じ段取りをまた使う 手順をワークフローとして組む
- 6 同じファイルを同時に編集する 作業場所を分けてから並べる
この「10 体以上・段取りが決まっている・また使う」という自分の基準は、第 07 節に挙げた、グラフとループの使い分けを扱う解説と照らし合わせた。違っていたのは呼び方だけで、どこで分けるかは同じだった。
いま、どこまで自走しているか
ページの冒頭に書いたとおり、実際に動いた記録で数えている。置いてあるだけの仕組みは、動いていないのと同じなので、数に入れていない。
86
段取りを決めて、一気に流した回数（6/18〜8/1、13 プロジェクト）
1,198
そのとき動いた専門役の延べ数（1 回あたり平均 13.9 体、最大 74 体）
約 4 分
次に人が指示を入れるまでの時間の中央値（同じ数え方で、15 分を超えた回は 193 回）
21
決まった時刻に走る処理（12 プロジェクト）
できていること
1 回の作業のあいだは、1 操作ずつ承認する使い方から抜け出せている
指示と指示の間隔から言えるのは、ここまでだ。1 手ごとには承認しておらず、15 分以上まとめて任せた回もある。ただ、測ったのは指示の間隔だけで、そのあいだ画面を見ていたかどうかまでは分からない。
仕組みとして欠けている 2 点
- 人がいない時間に、仕組みのほうから動き出すこと
- 機械で止める条件
どちらも手順書を書くだけでは埋まらず、仕組みを 1 つ足さないと解決しない。運用の穴は、次の節に並べた。
足りていないところ
良いことだけを書かないための欄。
ループを固める前に、つなぐ層を使っている
第 07 節に挙げた解説は、「ループを固めてから、ループどうしをつなげ」を原則にしている。自分の環境では、停止条件を機械で強制しないまま、ループどうしをつなぐ層も使っている。いまは人が短い間隔で指示を挟んでいて（次に指示を入れるまでの中央値は約 4 分。第 04 節）、止める判断はおもに人がその場でしている。実害はまだ出ていない。人がいない時間に回す仕組みは、機械で打ち切る仕組みと一緒に作る（次のカード）。
人がいないときに動き出せない
定期実行は動いているが、「人がいない時間に、ループが自分で仕事を選んで始める」ところまでは届いていない。次は、条件つきでやることを積んでおく置き場と、最大 3 回で打ち切る仕組みを、1 つにまとめて作る。この仕組みだけは、また「報告のみ」の段から始める。
定期実行が止まっても気づけない
動いている 21 本が止まっても、知らせる仕組みが無い。自走する仕組みでは、失敗して目立つより、黙って止まるほうが危ない。
自分で作った測定を、判定として使わない
自走の話でいちばん危ないのは、手元で作った測定を、そのまま判定（進めるか止めるかの決め手）にしてしまうことだ。だから数字には、実測なのか仮説なのかを書き添える。信じる前に、「どういう条件ならこの測定を信用してよいか」も書いておく。この決めごとは、机の上だけの話ではない。このページの数字を出すあいだにも、2 回破った。1 件は測定そのものを信じすぎた例、もう 1 件は結果を読むのが早すぎた例で、どちらも数字を出し直した。
使用ログを根拠に「実績 0 回」と判定した
スキルの使用ログを見て、「まとめて回した実績は一度も無い」と結論した。ところが、そのログは特定の呼び出し方しか記録しないもので、数えている範囲がそもそも違っていた。実際に動いた記録で数え直すと 86 回あり、評価を上へ直した。手元で作った測定は仮説にすぎない、ということを、自分でそのまま示してしまった。
まだ終わっていない出力を、確定した値として読んだ
裏で動いているコマンドの途中経過を読んで、確定した数字として扱った。終わったあとには、値が変わっていた（結論は、確かめ直しても変わらなかった）。
自分の考えを自分の考えで確かめても、閉じた輪からは出られない。抜け出すには、実際に走らせた出力や、人が確かめた事実、元の記録といった、外の事実に当てるしかない。
参照した資料
言葉の定義は、次の 8 件の解説を突き合わせて確かめた。
- ループエンジニアリングとは？ AI エージェントを自律で回す設計手法と 6 つの構成要素を解説（AI 総合研究所）
- グラフエンジニアリングとは？ 主要フレームワークや Loop Engineering との違い、移行判断を解説（AI 総合研究所）
- Loop Engineering（ループエンジニアリング）とは（Qiita / y-morimatsu）
- Loop Engineering とは｜「プロンプトの次」のループ設計を実務者が解説（Claude Code for Business）
- Graph vs Loop: Which Should Your Agent Use?（AI Builder Club）
- Agent Harness Engineering vs. Loop Engineering vs. Graph Engineering（Medium / Bijit Ghosh）
- 3 Years of Graph Engineering with LangGraph（LangChain）
- 「もうプロンプトは書かない」Claude Code 開発者が提唱するループエンジニアリング（AI 新聞）
実測の内訳
数字はいずれも 2026-08-01 時点。その後の変化は反映していない。
c:\work 作品紹介ギャラリー