ループエンジニアリングは、止め方を決める仕事でした
AI エージェントの話で「ループエンジニアリング」という言葉を見かけるようになりました。
エージェントに毎回指示を打つのをやめて、「動く→確かめる→直す」を勝手に回す仕組みのほうを作る、という考え方です。
私は一人会社を Claude Code で運用していて、無人のタスクを毎日3本回しています。
なので、公式は何と言っているのかを確かめ、自分の記録と並べてみました。
確かめたのは2026年10月12日です。
言葉の出どころ
この語を題名にした早い文章として、Addy Osmani 氏の個人ブログの「Loop Engineering」（2026年6月7日）があります。
本人のプロフィールには、長く Google にいて、いまは Anthropic で Claude Code に携わっていると書かれています。
その文章は、先に出ていた Peter Steinberger 氏と Boris Cherny 氏の発言を引いています。Cherny 氏は Claude Code を率いる人として紹介され、発言は「もうプロンプトは書かない。仕事はループを書くことだ」という趣旨です。
ただ、Cherny 氏の発言のリンク先は本人ではなく別の人の投稿でした。本人の発言の原文は見つからず、二次情報でしか確かめられませんでした。
公式側では、Claude のブログに「Loop engineering: Getting started with loops」（2026年6月30日）があります。題名にこの語が入っています。
ただ、書き出しは「いま話題になっている」という扱いで、Anthropic が名付けたとは書かれていません。Claude Code の用語集にもこの語は無く、載っているのは agentic loop や verification loop でした。
前回のハーネスの記事では、ループエンジニアリングに対応する語は私が読んだ3本には無かった、と書きました。そのあと公式のブログでこの語を題名にした記事を見つけたので、前の記事にも書き足しました。その話は別に書いています。
https://note.com/bebsite/n/nbd46a14a4599
公式は何と言っているか
その記事は、Claude Code チームの定義として、ループを "loops as agents repeating cycles of work until a stop condition is met" と定義しています。
止める条件を満たすまで、仕事の輪を繰り返すエージェント、という意味です。
輪の中身は、「Building agents with the Claude Agent SDK」（2025年9月29日）に書かれています。文脈を集める、動く、確かめる、繰り返す、の4つです。
ループの種類は、何で始まり、何で止まるかで4つに分けられていました。
人が1回指示するたびに回るもの
目標を決めて、達するか上限の回数に当たるまで回るもの（/goal）
決まった間隔で回るもの（/loop と /schedule）
人がその場にいないまま、出来事や予定で回るもの
使う量の抑え方と、出来の守り方も書かれています。
目標型には「5回で止める」のような回数の上限を付ける
回す間隔は、見ている対象が変わる頻度に合わせる
決まった手順はスクリプトにして、毎回考えさせない
書く役と確かめる役を分け、別のエージェントに確かめさせる
ドキュメント側にも歯止めがあります。セッションの中で回す /loop の定期実行は、作ってから7日で自動的に消えます。忘れたループが走り続ける長さに上限を置く、という説明でした。
BEBSITE で毎日回しているループ
回しているのは3本です。
毎朝、数字を取って記録し、その日の打ち手を1つと合格条件を書く
毎晩、朝に書かれた打ち手を1つだけ実行する
1日2回、投稿の予約リストの上から1本を SNS に出す
朝と夜で輪になっています。夜が動き、朝が数字で確かめます。判定は早くても3日後です。
指示書には、止める条件をこう書いています。
合格条件が書かれていなければ、夜は何もしない
同じ対象は、判定まで3日は重ねて変えない
投稿は、文面が予約リストと1文字単位で一致しなければ押さない
投稿できたか確かめられなければ、2回目を押さない（二重投稿になるので）
ログイン中のアカウントが違えば、ほかのアカウントで代わりにやらない
ツールが承認待ちや拒否で止まったら、迂回策を作らずに終える
報告は1行だけです。結果の判定と、捨てた件数を必ず書かせています。捨てた件数は0でも書きます。
止まったのに、3日気づかなかった
10月2日の昼から5日の未明まで、投稿のループが6回続けて止まりました。
原因は文面でした。「簡単です。」の句点の直後にドメインを書いていて、SNS 側がそれを1つのドメインと読み、無関係なサイトへのリンクを付けました。
ループは「本文に無いリンクが付いた」として、6回とも押さずに止まっています。これは正しい動作でした。
問題は読む側です。異常を書く受信箱には6回とも書かれていたのに、持ち場の担当は読みに行く手順を持っていませんでした。
気づいたのは、管理役の別のエージェントからの一報です。1日2本にした初日から、実際には1本も出ていませんでした。
直したのは3つです。文面を直し、決まりに1行足し、起動したら最初に受信箱の末尾を読む手順を入れました。
異常を受信箱へ書くのは、書く側の手順です。読む側の手順が無いと、片道で終わるんですよね。
デメリット
止まったこと自体が書かれない止まり方もあります。
アカウント側の問題で、4日間すべての無人タスクが起動の直後に失敗していました。受信箱にも報告にも1行も増えません。「何も出ていない」と「全部止まっている」が見分けられませんでした。
自己申告も当てになりません。
別の無人タスクで、最初のコマンドが承認待ちになり19時間あまり止まっていたのに、報告には「停止なし」と書かれていました。待たされた側には、待った時間が見えないためです。
合う使い方
合うのは、入力だけが変わる決まった仕事で、合格条件を先に1行で書けるものだと思います。
逆に、価格やサービスの中身のように、変えると困るものは、無人の側では触らせていません。
日付で動く約束も、引き継ぎの資料に書くだけだと消えます。対話のセッションしかそれを読まないからです。なので毎朝のタスクに見張らせ、気づいて書くところまでをやらせています。
確かめた日付
この記事に書いた公式の説明は、2026年10月12日に本文を読んで確かめた範囲のものです。機能や名前は版で変わります。
私の記録で手間がかかったのは、回し方より止まり方のほうでした。止まったことに気づける形を作るところまでが、ループの設計なんだと思います。
この記事の仕組みを、業務に合わせて組むところまでをココナラで引き受けています。
