なぜ「AI社員を雇う」発想はもう古いのか

2025年は「AIに役割を与えて組織図を作る」ことが流行りました。マーケ担当AI、ライターAI、レビュアーAI──まるで会社を作るように、AIに肩書きを配るやり方です。発想としては分かりやすい。けれど運用を続けると、ある壁にぶつかります。結局、全員に指示を出しているのは人間（あなた）だという壁です。

マネージャーが部下一人ひとりにマイクロマネジメントをしていたら、組織は回りません。良いリーダーがやるのは、目標・レビュー体制・引き継ぎの仕組みを整えて、自分が逐一口を出さなくても回る状態を作ることです。AIエージェントの運用もまったく同じ構造をしています。

つまり問題は「どんなAI社員を雇うか」ではなく、「彼らが自分で回り続ける“循環”をどう設計するか」。ここに気づいた瞬間、ゲームのルールが変わります。これがループエンジニアリングという潮流の出発点です。

ループエンジニアリングとは何か（定義）

「ループエンジニアリング（Loop Engineering）」は、2026年6月にほぼ同時多発的に生まれ、一気に定着した設計思想です。OpenClawの作者として知られるPeter Steinberger氏が「コーディングエージェントに直接プロンプトを書くのはやめて、エージェントにプロンプトを書く“ループ”を設計すべきだ」という趣旨の投稿をしたのが発端とされ、翌日にGoogleのAddy Osmani氏がこの概念を整理したブログ記事で体系化したと報じられています。

Addy Osmani氏による定義を平たく言えば、「ループエンジニアリングとは、エージェントにプロンプトを打つ“あなた自身”を、それを代わりに行うシステムに置き換えること」です。人間の仕事は「打つ」ことから「設計する」ことへ移ります。

さらに象徴的なのが、Anthropicでクロードコード（Claude Code）を率いるBoris Cherny氏が、対談の中で「自分はもうClaudeに直接プロンプトを打っていない。代わりにループを書くのが仕事になった」という趣旨を語ったと繰り返し引用されている点です。ツールを作った本人が、ツールに指示を打たなくなった──この逆説こそ、時代の転換を象徴しています。

プロンプトエンジニアリングとの決定的な違い

これまでの「XXエンジニアリング」──プロンプトエンジニアリング、コンテキストエンジニアリング──は、いずれも「どう上手く指示を出すか」を磨くものでした。ループエンジニアリングが毛色が違うのは、「あなたが手を動かす位置から、そもそも降りろ」と言っている点です。

誤解してはいけないのは、プロンプトの技術が不要になるわけではない、ということです。ループの中で回す“1つの指示”の質は依然として重要です。違いは、それを人が毎回打つのか、ループが代わりに打ち続けるのか。後者を設計するのがループエンジニアリングです。

Claude Codeの/loopが“循環”の核になる理由

思想だけでは何も回りません。これを実際に動かす公式機能が、Claude Codeの /loop コマンドです。/loopは、指定したプロンプトやスラッシュコマンドを一定間隔で繰り返し実行する機能で、Anthropicの公式ドキュメントでは「セッションが開いている間にプロンプトを繰り返し実行する最速の方法」と説明されていると報じられています。

書式はシンプルです。「/loop ［間隔］ ＜プロンプト＞」という形で、間隔は5m（5分）・30m・1h などで指定し、省略すると約10分間隔になるとされています。

特に間隔を省略したパターンでは、Claudeが状況に応じて次の起動タイミングを1分〜1時間の範囲で自分で決め、ビルドが終わりかけなら短く、何も動いていないなら長く、と“空気を読んで”待ち時間を調整すると説明されています。これがまさに「自走」の正体です。

/loopとcron・スケジューラの違い

「それ、cronでいいのでは？」という疑問は当然です。しかし両者は決定的に違います。cronが毎回まっさらな状態で起動する“忘れっぽい”実行であるのに対し、/loopは同じ会話セッションの中で動くため、前回の調査結果・前回読み込んだ設定ファイル・前回見たPRのコメントを引き継いだ状態で次のイテレーションに入ると説明されています。

ただし重要な前提があります。/loopはセッションが開いている間だけ動く“セッションスコープ”の機能で、ターミナルを閉じると止まり、recurring taskには7日のセッション有効期限があるとされています。つまり定期実行であって、無条件の永続実行ではありません。本当に永続的な無人実行が必要なら、Desktopのスケジュール機能やGitHub Actionsを使うよう公式が案内していると報じられています。

自己検証システム＝“永久機関”の心臓部

ループを「回し続ける」だけなら誰でもできます。難しいのは「回しながら品質を保つ」こと。ここで効くのが自己検証システム（self-verification）です。Addy Osmani氏の警句が刺さります。

だからこそ、ループの中に「別モデルによる採点（judge）」と「測定可能な完了条件」を組み込みます。公式ドキュメントは、長いターンにわたって成立する完了条件には3つの要素があるとしています──測定可能な1つの終了状態（テスト結果やファイル数など）、証明方法の明示（どう証明するか）、守るべき制約（途中で変えてはいけないもの）です。

/goalコマンドはこの仕組みを製品化した分かりやすい例で、完了条件を1度だけ書くと、毎ターンごとに小さく速いモデルが条件成立を確認し、満たされなければ人間に制御を返さず次のターンを自分で始め、条件が満たされた時点で自動的にゴールが解除されると説明されています。“永久機関”の比喩が成立するのは、この検証ループが心臓のように脈打っているからです。

SNS完全自動化ループの設計手順

ここからは応用編。開発の文脈で語られがちな/loopですが、設計思想はそのままSNS運用・自動投稿に転用できます。ポイントは「投稿を作る」だけでなく「作った投稿を自分で評価し、合格分だけ流す」という循環を組むことです。

実装サンプル：投稿生成→自己採点→予約投稿

イメージを具体化するため、擬似的なループ指示を見てみましょう。実際のコマンド構文・MCP連携は環境により異なるため、これは“設計の型”として捉えてください。

5番の「要約して記録し、詳細は破棄する」が地味に効きます。/loopを長時間回すと実行結果がコンテキストウィンドウに蓄積し、埋まると応答精度が落ちたり自動圧縮が走ったりするため、前回結果を簡潔に要約して詳細を破棄するよう指示しておくとコンテキスト消費を抑えられると説明されています。

暴走を防ぐ停止条件とコスト管理

ループの最大のリスクは、品質ではなくお金です。/loopは実行のたびにトークンを消費し、トークンはAIの利用量を測る単位でそのまま課金額に直結するため、短い間隔で長時間回し続けると消費が大きくなると説明されています。

Addy Osmani氏の締めの一文を、設計の指針として置いておきます。「ループは作れ。ただし“起動ボタンを押すだけの人”ではなく、“エンジニアであり続けるつもりの人”として作れ」。自走させることと、放置することは違います。

メリット・デメリットを正直に整理する

実践者・経営者のリアルな声

まずやるべき1アクション

大上段に「全自動化」を目指す必要はありません。いま自分が「終わったか気になって何度も見に行っている作業」を、ひとつ思い出してください。それがあなたの最初のループ候補です。

SNSなら「予約投稿がちゃんと流れたか」、副業の制作なら「ビルドが通ったか」。その“見張り”を/loopに渡すところから始め、慣れてきたら採点ループ＝自己検証を一段乗せる。組織図を描くのではなく、小さな循環をひとつ回す。そこからすべてが始まります。