何を設計する話なのか

AI の使い方は、設計する対象が 2 年で 4 段階ぶん上がった。 下の層が消えて上の層に乗り換わるのではなく、積み上がる。土台が弱いと上は必ず崩れる。

このページはループの層の話。1 つ下のハーネス層（権限・自動実行・専門役の装備）は ハーネス設計に、そこで使う手順書はスキル一覧に分けてある。

回す前に決める 4 つ

ループが成立する条件は 4 つあり、1 つでも欠けると自走は事故になる。 右列は、自分の環境でそれを何が担っているか。

停止条件は最も軽視されやすい。自走の消費は通常の作業の 5〜30 倍、最悪で 1000 倍に達しうるので、 本来は回数の上限・費用の上限・進んでいないことの検出・異常時の遮断を併用するのが定石になっている。

実際に効いている習慣

作る役と検査役を分ける

いちばん効いているのはこれで、いちばん地味でもある。同じ AI に「書かせて」「採点させる」と必ず甘くなるので、 別の指示・別の権限・敵対的な視点を与えた検査役を立てる。 直近の集計では、この 2 段構えを呼ぶ操作が 482 回（品質改善 297 回・バグ検出 185 回）で、 あらゆる操作の中で最も回数が多かった。意識してやっているのではなく、通らないと先へ進めない形にしてある。

権限は 3 段階で渡す

いきなり無人運転を目指さない。1 本通してから次の段に上げる。

• L1 報告のみ 安定

  分析と提案まで。変更は人が承認する。全件を見る。

• L2 検証付き修正 安定

  実装まで進み、まとまった単位で確認する。日常の開発はここ。

• L3 無人実行 部分的

  完全自動で、異常時だけ通知。定期実行は 12 プロジェクトで 21 本動いているが、全体としてはまだここに達していない。

1 体で足りるなら 1 体

並列化はいつでも得ではない。数回の操作で終わる作業は分業させない — 小さい仕事では、 分けたぶんの受け渡しでコストも時間も倍になる。判断は次の順で降りていく。

この「10 体以上・段取り確定・再現性」という自前のしきい値は、 一般に言われている移行の判断軸とほぼ同じところに落ちていた。過剰に配線する方向へは寄っていない。

いま、どこまで自走しているか

設定ファイルが置いてあるかではなく、実行の痕跡で数えた。置いてあるだけのものは動いていないのと同じなので。

応答の間隔から言えるのは、セッション単位ではすでに人がループの外側に出ているということ。 1 操作ごとに承認する使い方はしておらず、起動したら結果を受け取るまで見ていない時間のほうが長い。 構造的に欠けているのは 在席していない時間に仕組みの側から始まること と、 機械的な停止条件 の 2 点だけになっている。

足りていないところ

良い面だけ書かないための欄。

• 順序が逆になっている 現在の露出

  原則は「ループを固めてから、ループ同士を配線せよ」。ところが自分の環境は、 ループ側（停止条件）が未完成のまま配線の層を常用している。 成果が出ているので実害は表に出ていないが、延べ 1,198 体を回している以上、 停止条件が無いことは将来のリスクではなくいま抱えている露出にあたる。

• 在席なしでの起動が無い 構造の欠落

  定期ジョブは動いているが、「人がいない時間にループ自身が仕事を選んで始める」ところまでは行っていない。 受け入れ条件つきの作業待ち行列と、最大 3 回で打ち切る仕組みを 1 本で作るのが次の一手。最初は報告のみから。

• 定期ジョブの死活監視が無い 運用の穴

  動いている 21 本が止まっても気づけない。自走の仕組みは、失敗より「静かに止まること」のほうが危ない。

この評価自体で測り方を 2 回間違えた

自走の話で最も危ないのは、自分で作った測定を判定として扱うこと。この棚卸しでも実際に踏んだので、そのまま残す。

• 使用ログを根拠に「実績 0 回」と判定した

  スキルの使用ログを見て「ワークフローは一度も使っていない」と結論した。 しかしそのログは特定の経路からの呼び出ししか記録しない種類のもので、母集団が違っていた。 実行の痕跡を数え直したら 86 回で、評価を上方修正することになった。 手元で作った測定は仮説であって判定ではない、を地で行った例。

• まだ終わっていない出力を確定値として読んだ

  裏で走っているコマンドの途中経過を読み、確定した数字として扱った。完了後に値は変わっていた （結論そのものは再検証で維持された）。

この 2 件があったので、いまは数字に「実測なのか仮説なのか」を明示し、 信じる前に「どういう条件ならこの測定を信用してよいか」を先に書く運用にしている。

参照した資料

概念の定義は一次解説 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 新聞）