【AIに何を任せ、どこで止めるか】Loop Engineeringから考える仕事の設計

はじめに

本連載は、生成AIコミュニティ「IKIGAI lab.」で活動するメンバーが、それぞれの専門領域で培ってきた知見を持ち寄りながら、生成AIを取り巻く動向を技術・ビジネス・ガバナンスの観点から整理しお届けしています。

Loop Engineeringの登場－「もうプロンプトは書かない？」

2026年6月、Loop Engineeringという言葉が広がりを見せています。Claude Codeの開発者として知られるBoris Cherny氏が、「もうClaudeに直接プロンプトを書いていない」という趣旨の発言をしたと報じられ、この言葉への関心が高まっています。

この発言は、「プロンプトが不要になる」という単純な話ではありません。むしろ、人間の役割が「毎回AIに指示する人」から、「AIが動く仕組みを設計する人」へ広がりつつあることを示す一例として受け止められています。

Loop Engineeringは、ソフトウェア開発の文脈で語られることが多い言葉です。ただ、その考え方は、ソフトウェア開発に閉じた話なのでしょうか。

本稿では、Loop Engineeringを単なる「自動化のための実装技術」としてだけでなく、AIへの依頼やレビューの流れを設計する考え方として読み解いていきます。

Loop Engineeringは「繰り返すこと」だけではない

Loop Engineeringとは、具体的に何を指すのでしょうか。GoogleでChromeやAI領域に携わってきたソフトウェアエンジニアのAddy Osmani氏は自身のブログで、Loop Engineeringを「人間が毎回エージェントにプロンプトする代わりに、エージェントにプロンプトする仕組み自体を設計すること」として説明しています。

Loop Engineeringは、単にAIを何度も動かす「回す技術」ではありません。重要なのは、「何が達成できればゴールなのか」を明確に定義し、そのゴールに向けてAIが何をし、誰が検証し、どの状態になったら止まるかを設計することです。ゴール、検証方法、停止条件までセットで組み込む考え方です。

例えば、ソフトウェア開発であれば、CI^*でテストの失敗を検知したときに、エージェントが関連するファイルやログを読み、修正用の作業場所を作り、プロジェクトのルールを参照しながら修正案を作る。別の検証役やテストがその修正を確認し、テストが通れば停止する。何度試しても同じ失敗が続く場合は、人間に引き渡す。

このように、どの情報を見て、どの環境で作業し、誰が検証し、どの条件で次に進むか、あるいは止めるかという「一連の流れ」を設計することこそが、Loop Engineeringだと言えます。

同氏のブログでは、こうした流れを支える具体的な構成要素として、次のような項目が定義されています。

• Automations：定期実行や特定条件での起動など、「いつ動くか」を決める要素
• Worktrees：複数の作業を安全に並行して進めるために、作業場所を分ける要素
• Skills：作業ルールやプロジェクト知識など、「何を前提に作業するか」を参照できる形にする要素
• Plugins / Connectors：ファイル、チケット、データベースなど、「どの資料やツールを見るか」を決める要素
• Sub-agents：作成したAI自身にレビューさせると同じ見落としを引き継ぎやすいため、作成役、批評役など、役割ごとに異なるエージェントを走らせる要素
• Memory / State：何を試し、何が解消され、何が残っているかという「前回までの状態」を残す要素

これらの要素が組み合わさることで、エージェントは単発の回答ではなく、状況を見ながら作業し、検証し、必要に応じて修正し、条件を満たしたところで止まる流れを持てるようになります。

より実装寄りの具体例を知りたい方には、「Loop EngineeringをClaudeを使って実践してみた。」も参考になります。本稿では概念整理を中心に進めますが、実際にLoopの仕組みを組む流れを知りたい場合は、あわせて確認すると理解しやすいかと思います。

Prompt Engineering、Context Engineering、Loop Engineeringは何が違うのか

ここで、いま見てきたLoop EngineeringをPrompt EngineeringやContext Engineeringとの関係から整理してみます。 生成AIの活用をめぐっては、当初は「どのような指示文を書くか」というPrompt Engineeringが注目されてきました。

その後、AIにどの情報を渡すかを考えるContext Engineeringの重要性が語られるようになりました。さらに最近は、AIが作業・検証・改善を繰り返す流れを設計するLoop Engineeringへと、設計の対象が広がってきたと捉えることができます。

大まかに整理すると、次のようになります。

Anthropicは、Context EngineeringをPrompt Engineeringの自然な発展として位置づけています(Effective context engineering for AI agents)。これは、AIに渡す情報の集合を選び、維持するための戦略です。プロンプトだけでなく、外部データ、これまでのやり取りの履歴、ツールや外部データを接続する規格(MCPなど)も含まれます。

Loop Engineeringにおいても、AIがループの中で過去の修正履歴や現在の状態を見失わずに作業を続けるには、適切な文脈を渡し続けるContext Engineeringが土台になります。

つまり、Prompt Engineering、Context Engineering、Loop Engineeringは、どれかがどれかに置き換わるというより、積み重なっていく関係と整理できます。プロンプトを書く力は、Context EngineeringやLoop Engineeringの中に吸収され、より大きな設計の一部になっていくと考えられます。

Loop Engineeringに向くタスク、向きにくいタスク

完了条件を置けるかが分かれ目

こうしてLoop Engineeringの位置づけを整理したうえで、向くタスクを考えると、特に重要になるのは「これで完了した」と判断できる材料を置けるかどうかです。AIが作業を繰り返す以上、どの状態になったら十分なのか、どこまで来たら人間に引き渡すのかを決めておかなければ、ループは終わりません。

Zennの記事「もうプロンプトを書くな──『Loop Engineering』という新しいパラダイムの正体」でも、Loopを始める前に、受け入れ基準、停止条件、ロールバック^*、人間への引き渡しなどを確認する考え方が示されています。これは言い換えれば、AIに何を任せるかだけでなく、「どこで止めるか」「どこから人間が引き取るか」をあらかじめ設計しておく必要がある、ということです。

単に「よくなるまで直して」と指示しても、終わりは見えません。どの状態になったら十分なのかを決めておかなければ、AIは修正を続けたり、似たような改善案を何度も出したりします。

停止条件が曖昧だと、低品質な生成物が量産されたり、無限ループに近い挙動になったりする可能性があります。APIを使って自動化する場合は、実行コストやトークン消費が膨らむリスクもあります。

ソフトウェア開発と相性がよい理由

だからこそ、Loop Engineeringが設計しやすいのは、合否や完了を判断しやすいタスクです。代表例として挙げられるのが、ソフトウェア開発の中でも、テストやログ、差分によって結果を確認しやすい作業です。

例えば、書いたプログラムが想定どおり動くか、コードの書き方に問題がないか、変更前後の差分が期待どおりか、エラーログが出ていないか。こうした点は、テストやCIの結果を通じて確認しやすいものです。

このように、ソフトウェア開発では、人間が1つひとつ目視で確認しなくても「答え合わせ」しやすい場面が比較的多くあります。こうした性質も、Loop Engineeringがソフトウェア開発の文脈で語られやすい理由の一つだと考えられます。

定性的な仕事では、どこで止めるかが難しい

では、企画提案、方針検討、調査、資料作成など、合否や完了条件を明確に置きづらい仕事には関係ないのでしょうか。

筆者自身はエンジニアではなく、上記のような成果物の良し悪しを一言で判定しづらい仕事に向き合うことが多くあります。こうした仕事をAIに任せたまま本格的な自律Loopとして回すには、やはりハードルがあると感じます。

ただし、それはLoop Engineeringの発の発想が無関係だという意味ではありません。完全な自律Loopとして実装するのではなく、AIへの依頼、レビュー、修正、そして人間への引き渡しという流れを設計することで、日々のAI活用を一段引き上げるヒントは得られるのではないかと考えています。

自律Loopにしにくい仕事に、筆者なりに引き寄せてみる

ここからは、一般的な方法論ではなく、参考記事から読み取ったLoop Engineeringの発想を、筆者自身が企画提案や資料作成のような定性的な仕事に引き寄せてみる試行として整理します。

例えば新規企画の提案資料を作る場合を考えてみます。企画の切り口が魅力的か、資料に説得力があるか、意思決定に必要な情報がそろっているかは、単純な合否判定をしづらいものですが、以下のような「確認しやすい条件」に分解することはできます。

• 目的、背景、提案内容、期待効果、懸念点が含まれているか
• 主張と根拠のつながりに大きな矛盾や飛躍がないか
• 指定フォーマットや必要な構成に沿っているか

ただし、これだけでは十分ではありません。条件をAIに渡して「この通りに作って」と依頼するだけでは、従来のプロンプトやContext Engineeringに近い使い方にとどまります。Loop Engineeringの発想を借りるなら、できたものが本当に説得力を持つか、見落としがないかを検証する流れまで含めて考えたいところです。

Loop Engineeringでは、Sub-agentsのように作成役と検証役を分ける考え方が、見落としを減らす要素として語られています。Addy Osmani氏のブログでも、作成役自身による評価は甘くなりやすく、別のエージェントに見せることで見落としを拾いやすくなると説明されています。筆者もこの発想を借り、作成役とレビュー役を分け、それぞれの動きを管理役が整理する形で考えてみました。

ただし、役割の分け方はテーマや成果物によって変わるため、この3分類が正解というわけではありません。そのうえで、レビュー結果を受けて管理役がどう動くかの目安も決めておきます。例えば、次のような条件です。

• ループ継続：重大な指摘が残っている場合は、作成役に戻して修正を続ける
• 人間が介入：AI同士で同じ指摘が繰り返される場合は、人間が前提や方針を見直す
• 人間レビューへ渡す：残る課題が社内事情への配慮や微細な表現調整のレベルになったら、人間が引き取る

いずれの場合も、最終的にどこまで直すか、どの案を採用するかという判断は、人間が行います。

ここで紹介しているのは、本格的なLoop Engineeringそのものではありません。また、複数のAIに役割を分けること自体が目的なのでもありません。通常のChatGPTやClaudeのWeb UIではAI同士は自動連携しないため、人間が出力をつなぐハブとして動く必要があります。

本稿でも、発想を小さく試してみた

今回の記事執筆でも、筆者はChatGPTを編集長／管理役、Claudeを執筆者／作成役、Geminiを批評家・読者代表としてのレビュー役に見立てて使いました。

前章で整理したように、これは本格的なLoop Engineeringそのものではなく、Loop Engineeringの発想を記事制作の流れに小さく取り入れてみたものです。

実際に試してみると、作成したAI自身に自己レビューさせるより、別のAIに読ませた方が、論理の飛躍や読者に伝わりにくい点などの改善点が出やすいと感じました。執筆者としてのClaude、批評家・読者代表としてのGeminiというように役割を分けることで、同じ原稿を別の視点から見直しやすくなりました。

また、役割ごとにスレッドを分けたことで、議論の流れも整理しやすくなりました。1つの会話に企画、執筆、レビュー、修正方針を詰め込むより、「このAIには何を見てほしいのか」「どの観点で返してほしいのか」を保ちやすくなりました。

もちろん、それでも人間が見ると物足りない部分や、追加で確認したい観点は残ります。その都度、レビュー観点を追加したり、修正方針を調整したりする必要がありました。

それでも、最初のたたき台を人間が直しやすい水準まで引き上げるスピードは上がったと感じています。その分、筆者自身は「文章をどう整えるか」だけでなく、「この記事で何を伝えたいのか」「読者にとってどこが面白いのか」といった判断に、より多くの時間を使えるようになりました。

結論。プロンプトは終わらないが、人間の仕事は「設計」へ広がる

ここまで調べてみると、Prompt Engineeringは終わるわけではなく、Context EngineeringやLoop Engineeringの中に吸収され、より大きな設計の一部になっていくのだと感じました。

システム指示や役割定義、レビュー観点、停止条件を言語化するには、プロンプトを書く力が引き続き必要です。ただ、その役割は、AIへの単発の指示文を磨くことだけにとどまらず、どの文脈を渡し、誰に検証させ、どこで止めるかまでを含めて設計する段階へと広がりつつあるのだと考えています。

定性的な仕事であっても、ゴール、レビュー観点、修正条件、停止条件を言語化するという発想は、AIへの依頼やレビューの流れを見直すヒントになるのではないでしょうか。