生成はAIが回す。詰まるのは「公開の一歩」──ループを14日回して見えた本当のボトルネック

「ループエンジニアリング」という言葉を、僕は2026年の半ばから急に見かけるようになった。

AIに毎回プロンプトを打つ人から、AIが自律で回り続ける仕組みを設計する人へ。

概念の解説記事はいくつも見かける（例: LangChain 社ブログ Sydney Runkle “The Art of Loop Engineering” 2026-06-16、https://www.langchain.com/blog/the-art-of-loop-engineering ）。

でも僕がずっと不思議だったのは、僕が見ている範囲では、実際に回した「数字」まで出している人が多くないことだ。

だから自分のログを開ける。

僕は自分のコンテンツ生成を自作の自律エージェント基盤に任せていて、その実行ログ・タスク台帳・公開台帳が全部ファイルとgitに残っている。

だから以下の数字は外部の第三者監査ではなく、自分のエージェントの記録を自分で数えた実測値だ。

集計元は3つ。

ループが何回起動したかは実行ログ（1起動＝1行の記録）、成果物の本数はタスク台帳と生成ファイル、公開できた本数はnoteの公開台帳から数えた。

そこから14日ぶんをそのまま出す。

きれいな成功譚ではない。

むしろ「一番詰まる場所はどこか」がくっきり出た記録だ。

14日間の実測値

期間は2026年6月20日から7月3日までの14日間。

ループが起動した回数は101回（内訳: 実タスク92回、やることが無くて空振りした待機9回）。

その14日で生まれた成果物は69本だった。

• 記事の下書き 32本
• スライドデッキ 15本
• 調査レポートと自己改善の提案 19本
• 受講生向けの配布用解説 3本

1日あたり約5本のペースで何かが出来上がっている計算になる。

ここまでは「ループは回っている」という話だ。

問題は次だ。

生成量と公開量のあいだにある段差

この69本のうち、実際に外へ出たものはどれくらいか。

note で公開まで漕ぎ着けた記事は5本。

記事の下書きは32本あるから、**公開率にすると約16%**だ。

Xでのスレッド発信は9本。

残りの大半――調査19本、スライド15本、記事の下書き27本――は、外に出ていない。

社内で使うか、僕の「出していい」という判断を待って止まっている。

生成は1日5本のペースで回るのに、外に出るのはその2割前後。

この段差が、僕がこの14日で一番はっきり見た事実だ。

ボトルネックは、もう生成ではない。

賢いプロンプトを書けるかどうかでもない。

詰まっているのは、作ったものを「外に出す一歩」のほうだった。

なぜ「公開の一歩」で詰まるのか

理由は単純で、生成と公開はリスクの性質がまるで違うからだ。

下書きを1本作るのは可逆で、内部の操作だ。

気に入らなければ捨てればいい。

だから僕の用途では、AIに遠慮なく作らせていい。

でも公開は不可逆で、外向きの操作だ。

一度出した数字や固有名詞は、後で消しても誰かのスクショに残る。

発信の信頼は資産で、失うのは一瞬だ。

つまり「作る」と「出す」を同じ速度で自動化してはいけない。

作るほうは全力でアクセルを踏み、出すほうには人間のブレーキを残す。

この非対称をどう設計するかが、ループ運用の実際の勝負どころだった。

僕がやっている承認設計

僕は人間（＝僕自身）の関与を、2つのルールで設計している。

1. リスクでタスクを2つに仕分ける

すべてのタスクに、着手前に「可逆か・不可逆か」のラベルを付ける。

• 可逆（低リスク）: 下書き・調査・提案の「作成」。これは人間の承認を待たず、AIが作り続けていい。
• 不可逆（高リスク）: 公開・送信・課金・削除・本番反映。これは提案を整えたところで必ず止まり、僕のGOを待つ。

この線引きがあるから、AIは夜中でも勝手に69本を作れるし、それでいて危ない一歩は人間のGO無しには踏まない設計にできる。

2. 承認は「veto（拒否権）」であって、指図ではない

僕は一本ずつ内容を指示していない。

AIが勝手に作ったものに対して、僕は「採用する／却下する」を押すだけだ。

これは細かく口を出すマイクロマネジメントの逆で、拒否権だけを握るやり方だ。

だから僕のラベルは「作っていいか」ではなく「公開していいか」のゲートになっている。

却下したものは、公開もしないし作り直しもしない。

人間が全部の生成に関わろうとすると、そこが律速になってループが止まる。

拒否権だけに絞ると、AIは走り続けたまま、危険な出口にだけ人間の判断が挟まる。

3. 品質の下限は機械に守らせる

もうひとつ効いているのが、生成したAI本人とは別のモデルに「検証ゲート」をかけることだ。

僕の運用では、モデルは自分の成果を甘く採点しがちだと感じている。

だから別プロセスが「具体例・数字・出典・結論があるか」を反証し、通らなければ公開候補にすら上げない。

これで僕は「品質が最低ラインを超えているか」を自分でチェックしなくてよくなる。

僕が使う判断力は、「出すか・出さないか」の一点だけに集中できる。

公開率16%は、失敗ではなく設計どおり

ここで大事なのは、公開率が低いこと自体は失敗ではない、ということだ。

作ったものを全部出す運用のほうが、むしろ危ない。

可逆なうちにたくさん作って、不可逆な公開だけ絞る――その結果として16%になっている。

これは設計どおりの数字だ。

ただし正直に言うと、この「出す一歩」は今の僕のスループットの律速でもある。

少なくとも僕の用途では生成側の詰まりはもう小さく、むしろ僕の採用判断が追いつかず、GO待ちの棚に成果物が積み上がっていく。

つまり次に設計を改善すべき場所は、生成側ではなく承認側だ。

「作る速さ」ではなく「安全に出す速さ」を上げること。

そこがループ運用の、次のフロンティアだと思っている。

まとめ

生成はもうAIが回す。

14日で101回起動して69本が出来た。

ボトルネックは賢いプロンプトでも生成速度でもなく、作ったものを外に出す「不可逆な一歩」をどう設計するかに移っていた。

僕の答えは、リスクで仕分けて可逆な作成は無制限に回し、不可逆な公開だけに人間の拒否権を残すこと。

ループを設計する人が次に磨くべきなのは、モデルの賢さではなく、この「出口の承認設計」だ。