タグ: 議論

複数の役割を与えたAIに、一度だけ企画や提案を議論させる。これだけでも、自分一人では気づけなかった問題を発見できます。しかし、同じような調査やレビューを繰り返すたびに、役割、手順、評価基準を一から指示していては、仕事の進め方はあまり変わりません。

基本編では、複数のAIに異なる判断基準を与え、独立して評価させたうえで、対立点や未確認事項を整理する「マルチエージェント討議」の使い方を紹介しました。今回の応用編では、その方法を一度限りの壁打ちで終わらせず、営業・マーケティング・商品企画で繰り返される調査、分析、提案、施策立案のプロセスへ発展させます。

扱うのは、課題を複数の担当に分け、別々に情報を集めさせ、根拠と途中経過を残し、決めておいた合格基準で評価し、不足している部分だけをやり直す方法です。営業提案前の顧客・競合調査、マーケティング施策の事前検証、商品企画の顧客ニーズ調査など、現場社員が繰り返し行う仕事を題材に解説します。

重要なのは、AIを完全に自律させることではありません。何をもって完成とするのか、何回までやり直すのか、どの判断を人間に戻すのかを先に決め、人間が毎回細かく指示する作業を減らすことです。

チャット上で始められる最小構成から、一部の調査や評価を自動化する半自律的な運用まで、段階を追って紹介します。マルチエージェント討議を「便利なプロンプト」から、営業・マーケティング・商品企画の現場で継続的に使える仕事の仕組みへ変えるための実践ガイドです。

はじめに　マルチエージェント討議を、一度きりの壁打ちで終わらせない

前回の基本編では、複数のAIに異なる役割を与え、一つのテーマを複数の角度から検討する「マルチエージェント討議」の進め方を紹介しました。

一人のAIに「よい案を出してください」と頼むだけでは、最初に出た考えをそのまま補強してしまうことがあります。そこで、推進する立場、問題点を探す立場、実行可能性を評価する立場などに分け、まずは独立して考えさせます。その後で意見の違いを整理すれば、自分一人では気づきにくい前提やリスクを発見しやすくなります。

この方法は、企画の壁打ちや提案内容のレビューに有効です。しかし、実際の仕事で繰り返し使おうとすると、次の課題が出てきます。

毎回、役割や進め方を説明し直さなければならない。調査結果や前回の判断が、次の仕事に引き継がれない。AIが長い回答を返しても、何をもって完成とするのか分からない。不足が見つかるたびに、全体を最初からやり直してしまう。

これでは、AIを使うたびに人間が進行役を務めなければなりません。議論の内容は高度になっても、仕事の進め方は従来とあまり変わっていないのです。

今回の応用編では、マルチエージェント討議を一度きりの壁打ちで終わらせず、営業・マーケティング・商品企画で繰り返し使える仕事の流れへ発展させます。

営業であれば、顧客企業を調べ、課題の仮説を立て、競合との差を確認し、想定される反論を整理し、次回商談で確認する質問へつなげます。

マーケティングであれば、顧客課題を分析し、複数の施策案を比較し、成立に必要な前提や失敗する条件を確認したうえで、小さな検証計画へ落とし込みます。

商品企画であれば、顧客の要望と本当の課題を分け、競合商品や現在の代替手段を調べ、市場性、実現性、収益性を別々に評価します。

重要なのは、AIの人数を増やすことではありません。

マルチエージェントは、複数の方向を同時に調べられる仕事では有効です。一方で、エージェント間の調整や情報の受け渡しが増えるため、単純な仕事まで複数のAIに分担させると、かえって費用や手間が増えることがあります。Anthropicの実装報告でも、マルチエージェントは通常のチャットの約15倍のトークンを消費し、並列化しにくい仕事には向かないとされています。[2]

また、同じ計算量で比較すると、複数のAIより一人のAIを継続して使った方がよい結果を出す場合も報告されています。[3] 「何人のAIを参加させるか」ではなく、仕事を分ける意味があるかどうかを先に考える必要があります。

そこで設計するのが、次のような項目です。

何を目的に始めるのか。どの材料を使うのか。誰にどの仕事を担当させるのか。何をもって合格とするのか。不足があれば、どこだけをやり直すのか。何回で打ち切るのか。どの判断を人間に戻すのか。

こうした仕事の進め方を、AIに指示する前に決めておきます。

この考え方が、Loop Engineeringです。

Loop Engineeringという言葉を広めた実務家のAddy Osmaniは、人間が毎回AIへ指示を出す代わりに、その役目を担う仕組みを設計することだと説明しています。[1]

ただし、本記事で扱うLoop Engineeringは、AIに同じ作業を何度も繰り返させることではありません。

仕事を始める条件を決め、作業を分担し、途中の結果を残し、決めておいた基準で確認する。基準を満たさなければ、不足している部分だけをやり直す。合格したとき、上限に達したとき、または人間の判断が必要になったときに止める。

この一連の流れを、繰り返し使える形にすることを目指します。

本記事では、大がかりなシステム開発を前提にしません。まずは普段使っているチャット上で、人間が進行役となってこの流れを試します。うまく機能することを確認してから、ひな型として保存し、必要な部分だけを自動化します。

目指すのは、人間を仕事から外すことではありません。

情報収集、比較、確認、修正といった反復作業をAIに任せ、人間は論点の設定、例外への対応、顧客との対話、最終的な意思決定に集中します。重要な操作や判断の前でAIの処理を止め、人間が承認または却下する仕組みは、実際のエージェント開発基盤にも組み込まれています。[4]

本記事では、このように調査や検証の一部をAIへ任せながら、重要な判断は人間が持つ「半自律」の運用を基本とします。

まず、仕事をループ化するための共通設計を整理します。その後、営業、マーケティング、商品企画の具体例を通じて、マルチエージェント討議を「便利なプロンプト」から「繰り返し使える仕事の仕組み」へ変える方法を解説します。

第1章　マルチエージェント討議からLoop Engineeringへ

一度の討議と、繰り返し回る仕組みの違い

基本編で紹介したマルチエージェント討議では、一つの議題に対して複数のAIが異なる立場から検討します。

たとえば、新しいマーケティング施策を考える場合、顧客視点、実行担当者の視点、費用対効果を確認する視点などに役割を分けます。それぞれが独立して意見を出し、問題点を指摘し合い、最後に人間が採用する案を決めます。

基本的な流れは、次のとおりです。

議題を決める
→ 複数の役割が独立して考える
→ 相互に批判する
→ 意見を統合する
→ 人間が判断する

この方法は、一つの企画や提案を検討するには有効です。

しかし、同じ種類の仕事を毎週、毎月、案件ごとに繰り返す場合は、これだけでは足りません。

営業担当者が新しい商談を始めるたびに、顧客調査の項目や評価する役割を一から説明する。マーケティング担当者が施策を考えるたびに、顧客、競合、実行負荷、リスクの確認方法を指示し直す。商品企画担当者が新しい案を検討するたびに、市場性、実現性、収益性を確認する順番を組み立て直す。

これでは、AIが作業をしていても、その進め方を管理する負担は人間に残ります。

Loop Engineeringでは、討議の前後を含めて仕事の流れを設計します。

開始する条件を決める
→ 目的と使用する材料を確認する
→ 仕事を複数の担当へ分ける
→ 各担当が独立して作業する
→ 決められた形式で結果をまとめる
→ 合格条件を満たしているか確認する
→ 不足部分だけをやり直す
→ 人間が判断する、または終了する
→ 結果を次回のために残す

違いは、AIが何度も回答することではありません。

仕事の開始から終了までの進め方を、次回も使える形で残すことにあります。

一度のマルチエージェント討議	Loop Engineeringを取り入れた運用
人間が毎回議題を入力する	開始する条件が決まっている
その場で役割を決める	仕事の種類ごとに役割が決まっている
自由な形式で意見を出す	共通の形式で結果を残す
人間が回答全体を読む	合格条件に沿って確認する
不満があれば全体をやり直す	不足している部分だけをやり直す
その場の回答で終わる	結果と未確認事項を次回へ引き継ぐ
人間が終了を判断する	回数、期限、条件に応じて停止する

Loop Engineeringを現場の言葉で捉える

Loop Engineeringは、まだ学術的に定義が固まった言葉ではありません。実務家を中心に使われ始めた新しい考え方です。

この言葉を広めたAddy Osmaniは、Loop Engineeringを、人間がAIへ繰り返し指示する代わりに、その役目を担う仕組みを設計することだと説明しています。[1]

ただし、現場の会社員がこの考え方を使うために、複雑なシステムを作る必要はありません。

まずは、普段使っているチャットの中で、次の項目をあらかじめ決めるだけでも構いません。

• 今回、何を決めるのか
• どの資料や情報を使うのか
• どのような仕事に分けるのか
• 各担当は何を提出するのか
• 何を満たせば完成とするのか
• 不足があれば、誰が何を調べ直すのか
• 何回で打ち切るのか
• どこから人間が判断するのか

たとえば、営業の顧客調査で「情報を集めてください」とだけ頼むと、AIは顧客企業の概要、ニュース、製品、業績などを大量にまとめるかもしれません。

しかし、営業担当者が本当に知りたいのは、会社概要ではないはずです。

次回の商談で何を確認すべきか。どの部門が提案に関心を持ちそうか。どのような反対意見が予想されるか。競合と比べて何を説明すべきか。まだ確認できていないことは何か。

最終的に必要な判断から逆算すれば、AIに担当させる仕事、必要な材料、合格条件も変わります。

つまり、Loop Engineeringで先に設計するのは、AIへの詳しい命令ではありません。

仕事が前へ進んだと判断するための条件です。

Anthropicは、回答を作るAIと評価するAIを組み合わせる方法について、評価基準が明確であり、繰り返しによって目に見える改善が得られる仕事に向いていると説明しています。[5]

反対に、何をもって「よくなった」とするのかを説明できない仕事では、AIに何度やり直させても、文章が長くなったり、表現が変わったりするだけで終わる可能性があります。

営業であれば「次回商談で確認すべき事項がそろったか」、マーケティングであれば「施策を実施するための前提と検証方法が明らかになったか」、商品企画であれば「次の検証へ進むかを判断できる材料がそろったか」が、仕事が前へ進んだかどうかの基準になります。

AIの人数を増やすことが目的ではない

「マルチエージェント」という言葉から、多くのAIを参加させるほどよい結果になるように感じるかもしれません。

しかし、重要なのは人数ではなく、仕事を分ける意味があるかです。

複数のAIが有効なのは、それぞれが独立して進められる仕事です。

たとえば、顧客課題の調査、競合の調査、法規制の確認、費用対効果の試算は、ある程度別々に進められます。各担当が異なる資料や評価基準を使うため、作業を分ける意味があります。

Anthropicのマルチエージェント調査システムも、複数の独立した方向を同時に探索する調査で、特に高い効果を発揮したと報告しています。[2]

一方で、前の作業結果がなければ次の作業を始められない仕事や、全員が同じ情報を詳しく共有しなければならない仕事は、分担しにくくなります。

また、複数のAIが同じモデルを使い、同じ資料を読み、役割名だけを変えている場合、結局は似た意見が並ぶこともあります。

実際に、使用する推論量をそろえて比較した研究では、複数のAIによる仕組みより、一人のAIを複数回使う方法が同等以上の結果を出したと報告されています。[3]

そのため、最初から多数の役割を作る必要はありません。

まずは一人のAIで作業し、別の視点からの確認が必要な部分だけを分けます。

たとえば、最初は次の三つで十分です。

1. 情報を集めて案を作る担当
2. 根拠や問題点を確認する担当
3. 結果をまとめる担当

実際に使ってみて、競合調査が弱い、数字の間違いが多い、反対意見が出ないといった問題が見つかったときに、その部分だけ専任の役割を追加します。

Anthropicも、AIを使った仕組みは最も単純な方法から始め、必要な場合だけ複雑にすることを推奨しています。[5]

Loop Engineeringは、AIを増やして複雑な仕組みを作る考え方ではありません。

人間が毎回行っている進行管理を整理し、必要な部分だけをAIへ渡せる形にする考え方です。

次章では、そのために最初に決めておきたい項目を、「目的」「材料」「仕事の分解」「出力形式」「合格条件」「直し方」「停止条件と人間の判断範囲」の七つに分けて解説します。

第2章　仕事をループ化するための七つの設計項目

マルチエージェント討議を繰り返し使える仕事の仕組みにするには、何を決めておけばよいのでしょうか。

営業、マーケティング、商品企画では、扱うテーマや成果物が異なります。しかし、AIに仕事を任せる前に設計すべき項目は共通しています。

本記事では、次の七つに整理します。

1. 目的
2. 材料
3. 仕事の分解
4. 出力形式
5. 合格条件
6. 直し方
7. 停止条件と人間の判断範囲

最初からすべてを細かく決める必要はありません。まずは一つの仕事を選び、この七項目を簡単に書き出すところから始めます。

2-1. 目的を決める

最初に決めるのは、AIに何をさせるかではありません。

この仕事を終えたとき、人間が何を判断できる状態にしたいかです。

「顧客企業について調べる」「施策案を考える」「新商品を検討する」では、目的が広すぎます。AIは大量の情報やアイデアを出せますが、それだけでは仕事が前へ進んだとは限りません。

目的は、調査や討議の後に行う判断まで含めて書きます。

営業であれば、次のようになります。

次回商談で確認する質問と、提案書へ反映する仮説を決める。

マーケティングであれば、次のようにします。

三つの施策候補を比較し、最初に小さく試す施策を一つ決める。

商品企画であれば、次のように書けます。

この企画を次の検証段階へ進めるか、見送るかを判断する。

目的が決まると、必要な情報と不要な情報を分けやすくなります。

営業担当者が次回商談の質問を決めたいのであれば、顧客企業の沿革を詳しくまとめる必要はないかもしれません。一方、現在の重点事業、担当部門の課題、導入を妨げる条件は重要です。

AIに何を出させるかを考える前に、出力を使って人間が何を決めるのかを明確にします。

2-2. 材料を決める

次に、AIが使ってよい材料を決めます。

材料には、社外から集める情報だけでなく、社内にすでにある情報も含まれます。

営業であれば、顧客企業のWebサイト、決算資料、ニュース、過去の商談記録、担当者から聞いた内容などです。

マーケティングであれば、顧客アンケート、アクセス解析、広告結果、営業から寄せられた声、競合の施策、過去のキャンペーン結果などが考えられます。

商品企画であれば、顧客インタビュー、問い合わせ、レビュー、解約理由、競合商品、既存機能の利用状況などです。

ここで重要なのは、材料を増やすことだけではありません。次の三つを分けます。

• 確認できている事実
• 事実から導いた仮説
• まだ確認できていないこと

たとえば、「顧客企業がコスト削減を重視している」という記述があったとします。

決算説明資料に具体的な方針として書かれているのであれば、事実に近い情報です。業績が悪化していることからAIが推測したのであれば、仮説です。営業担当者が商談で聞いたものの記録が残っていない場合は、確認が必要な情報として扱うべきでしょう。

この区別をしないと、AIの推測がいつの間にか前提として使われます。

材料を指定するときは、次のようなルールも加えます。

資料に書かれていない内容を事実として扱わない。推測する場合は「仮説」と明記する。確認できない場合は、無理に埋めず「未確認」とする。

2-3. 仕事を分解する

目的と材料が決まったら、仕事を分けます。

ここでありがちなのが、「営業の専門家」「マーケティングの専門家」「経営コンサルタント」のように、人物像だけを設定する方法です。

役割を演じさせること自体が悪いわけではありません。しかし、役職名だけを変えても、全員が同じ資料を読み、同じ質問に答えれば、似た意見が出やすくなります。

仕事を分けるときは、それぞれに異なる作業を担当させます。

たとえば、営業提案の準備であれば、次のように分けられます。

• 顧客企業の事業課題を調べる
• 提案に関係する部門や関係者を整理する
• 競合となる選択肢を調べる
• 導入を妨げる条件を考える
• 費用対効果の根拠を確認する
• 提案仮説への反対意見を出す

マーケティング施策であれば、顧客課題、競合施策、チャネル、実行負荷、失敗条件、効果測定に分けられます。

商品企画であれば、顧客課題、現在の代替手段、競合、市場性、実現性、収益性、撤退条件に分けられます。

複数のAIを使う価値は、異なる名前の登場人物を増やすことではありません。別々に進められる仕事を分け、異なる種類の失敗を発見できるようにすることです。

ただし、すべての仕事を分ける必要はありません。最初は「案を作る担当」「問題を確認する担当」「統合する担当」の三つ程度から始めれば十分です。[5]

2-4. 出力形式をそろえる

複数の担当に自由に回答させると、結果を比較しにくくなります。

一人は長いレポートを書き、別の一人は箇条書きで回答し、もう一人は結論だけを返すかもしれません。人間は内容だけでなく、形式の違いも整理しなければなりません。

そこで、各担当の出力形式をそろえます。

多くの仕事で使いやすいのは、次の五項目です。主張何が言えるのか。根拠どの資料や事実からそう判断したのか。反対証拠・例外その主張が成立しない可能性はあるか。未確認事項何が分かっていないのか。次の行動追加で何を調べる、聞く、試すべきか。

たとえば、営業の顧客調査では、次のようになります。主張顧客企業では、店舗ごとに分かれたデータの集約が課題になっている可能性がある。根拠中期経営計画で、全社データ基盤の整備が重点施策として挙げられている。反対証拠・例外すでに別部門で基盤導入が進んでいる可能性がある。未確認事項今回の商談相手が、この施策の担当部門かどうかは確認できていない。次の行動次回商談で、現在のデータ管理方法と担当部門を確認する。

この形式であれば、調査結果がそのまま次回商談の質問につながります。

2-5. 合格条件を決める

Loop Engineeringで最も重要なのが、合格条件です。

AIに「十分に検討してください」「完成度を高めてください」と指示しても、どの状態になれば終了してよいかは分かりません。

評価と改善を繰り返す方法は、評価基準が明確で、修正による改善を確認できる仕事に向いています。[5]

合格条件は、「よい」「詳しい」「説得力がある」といった言葉ではなく、できるだけ確認可能な形で書きます。

• 必須の調査項目がすべて埋まっている
• 重要な主張には根拠が付いている
• 事実と仮説が分けられている
• 反対意見または成立しない条件が検討されている
• 数値の出典と計算方法が確認できる
• 未確認事項が明示されている
• 次の行動が三つ以内に絞られている

すべてを数値化する必要はありません。

営業提案であれば、「顧客企業の課題が正しいか」は商談前に確定できないこともあります。その場合は、「課題を事実として断定せず、確認すべき仮説として整理されている」ことを合格条件にします。

重要なのは、AIが正解を出したかではなく、人間が次の判断や行動へ進める状態になったかです。

2-6. 直し方を決める

合格条件を満たさなかった場合は、何を直すかを決めます。

ここで、回答全体を最初から作り直させないことが重要です。

根拠が不足しているのに全体を書き直させると、確認済みだった部分まで変わることがあります。文章表現は改善しても、事実関係が弱くなるかもしれません。

問題の種類と、戻す相手を対応させます。

見つかった問題	戻す担当
根拠がない	情報収集担当
二次情報に偏っている	一次情報確認担当
結論が一面的	反証担当
顧客理解が抽象的	顧客課題担当
数字が一致しない	数値確認担当
施策の実行方法が曖昧	実行可能性担当
未解決の意見対立がある	人間の判断

たとえば、マーケティング施策の案に顧客課題の根拠がなければ、施策案全体を作り直すのではなく、顧客課題の確認だけを追加します。

商品企画の収益性試算で数字が合わなければ、顧客ニーズや競合比較をやり直す必要はありません。数値確認の工程だけを戻します。

Loop Engineeringでは、失敗を「回答が悪かった」とまとめて扱いません。どの条件を満たさなかったかを特定し、その部分だけを直します。

2-7. 停止条件と人間の判断範囲を決める

AIは、頼めば追加案や追加調査を続けられます。

しかし、調べられることが残っているからといって、調査を続ける価値があるとは限りません。情報を増やしても結論が変わらないこともあります。

そこで、開始前に停止条件を決めます。

• 合格条件をすべて満たした
• やり直しが二回に達した
• 指定した時間または期限に達した
• 新しい根拠が見つからなくなった
• 同じ問題が繰り返し発生した
• 人間でなければ判断できない論点が残った

停止することは、必ずしも成功を意味しません。

「根拠が見つからなかった」「二つの資料が矛盾している」「顧客への確認が必要」と明示して終えることも、正しい停止です。

同時に、どこから人間が判断するのかも決めます。

営業であれば、価格、契約条件、顧客への約束、提案書の外部送信は人間が確認します。

マーケティングであれば、広告予算、ブランド表現、個人情報の利用、キャンペーンの公開前に人間を挟みます。

商品企画であれば、開発投資、優先順位、法的な解釈、企画の採否は人間が判断します。

現在のAIエージェント向けの仕組みにも、重要な操作の直前で処理を止め、人間の承認後に再開する考え方が組み込まれています。[4]

AIに任せる範囲を広げるほど、人間の役割がなくなるわけではありません。人間の役割は、作業を細かく指示することから、境界を決めて重要な判断を引き受けることへ変わります。

七項目を一枚にまとめる

設計項目	記入する内容
目的	この仕事の後に何を判断するか
材料	使う資料、事実、社内情報
仕事の分解	誰が何を調べ、評価するか
出力形式	各担当がどの形式で結果を返すか
合格条件	何を満たせば次へ進めるか
直し方	問題ごとにどの工程へ戻すか
停止・人間判断	何回で止め、何を人間が決めるか

この七項目が決まっていれば、まだ自動化されていなくても、仕事の進め方はすでにループとして設計されています。

次章からは、この共通設計を営業、マーケティング、商品企画の仕事へ具体的に当てはめます。まずは営業の顧客調査から提案仮説、次回商談の質問までを一つの流れとして設計します。

第3章　営業で使う――顧客調査から提案仮説までをつなぐ

営業でAIを使うとき、最初に思いつくのは顧客企業の調査ではないでしょうか。

企業名を入力すれば、事業内容、業績、ニュース、競合、経営方針などを短時間で集められます。提案書の構成案や商談用の質問も作れます。

しかし、情報が増えたからといって、提案の質が上がるとは限りません。

顧客企業について詳しくまとめたレポートができても、次のような問題は残ります。

• 顧客が本当に困っていることが分からない
• 公開情報と営業担当者の推測が混ざっている
• 自社に都合のよい課題だけを選んでいる
• 競合との違いが自社の主張にとどまっている
• 次回商談で何を確認すべきか分からない
• 根拠が弱いまま提案書に書いてしまう

営業でLoop Engineeringを使う目的は、顧客情報を大量に集めることではありません。

顧客に関する情報を、提案仮説と次回商談の質問へ変えることです。

提案書を作る前に「証拠パック」を作る

AIに顧客企業を調べさせた後、そのまま「提案書を作ってください」と頼むと、AIは不足している情報を推測で補いながら、もっともらしいストーリーを作ることがあります。

たとえば、顧客企業がDXを重点方針に掲げているという情報から、「現場業務のデジタル化が遅れている」と結論づけるかもしれません。

しかし、重点方針として掲げていることと、実際に遅れていることは同じではありません。すでに大規模な取り組みが進んでいる可能性もあります。

そこで、提案書を作る前に「証拠パック」を作ります。

証拠パックとは、提案に使う主張と、その根拠、反対材料、未確認事項をまとめたものです。

項目	確認する内容
顧客の事業課題	公開情報から何が確認できるか
課題仮説	今回の提案に関係しそうな問題は何か
根拠	どの資料や商談記録に基づくか
反対材料	仮説が間違っている可能性はないか
関係者	誰が関心を持ち、誰が反対しそうか
競合・代替手段	顧客が自社以外に選べるものは何か
未確認事項	商談で何を聞かなければならないか
提案への反映	現時点で何を提案書に書けるか

Anthropicのマルチエージェント調査システムでも、各担当は調査の全履歴を統合役へ渡すのではなく、必要な発見だけを絞り込んで返す構成が採用されています。[2]

営業でも、長い企業調査レポートを作るより、「主張」「根拠」「競合との違い」「顧客に確認すべきこと」に絞った方が、その後の商談や提案に使いやすくなります。

営業の仕事を六つに分ける

1. 顧客企業の変化を調べる

最初に、顧客企業で何が起きているかを確認します。

• 重点事業の変更
• 新商品や新サービス
• 組織変更
• 業績の変化
• 投資計画
• 採用の動き
• 提携や買収
• 法規制や市場環境の影響

ここでは、すぐに自社の提案へ結びつけません。まず、確認できた事実だけを整理します。

2. 課題の仮説を作る

確認した変化から、今回の提案に関係する課題を考えます。

ただし、「顧客の課題」と断定せず、仮説として扱います。

店舗ごとに異なる業務手順やデータ管理が、全社展開の負担になっている可能性がある。

この段階では、仮説が正しいかどうかは分かりません。次回商談で確認するための問いとして残します。

3. 関係者ごとの関心を整理する

同じ提案でも、関係者によって関心は異なります。

現場部門は使いやすさや業務負荷を気にします。IT部門は既存システムとの接続やセキュリティを確認します。経営層は投資効果を見ます。購買部門は価格や契約条件を重視します。

AIには、顧客企業を一つの人格として扱わせず、関係者ごとに次を整理させます。

• 期待する効果
• 懸念しそうな点
• 必要とする根拠
• 商談で確認すべきこと

4. 競合と代替手段を確認する

営業における競合は、同業他社だけではありません。

• 他社の商品やサービスを導入する
• 既存の仕組みを使い続ける
• 社内で対応する
• 一部の業務だけを改善する
• 今回は何もしない

「何もしない」ことも有力な競合です。

AIには、自社と他社の機能比較だけでなく、顧客が現状維持を選ぶ理由も検討させます。

5. 反対意見を作る

提案仮説を作ったAIに、そのまま提案を評価させると、自分が作った案を肯定しやすくなります。

そこで、反対意見を出す担当を分けます。

• その課題は本当に優先度が高いか
• すでに別の施策で解決していないか
• 導入効果を過大評価していないか
• 現場の負担が増えないか
• 導入を急ぐ理由はあるか
• 他社や内製で十分ではないか

反対意見の目的は、提案を潰すことではありません。商談前に弱い部分を発見し、何を確認すべきかを明らかにすることです。

6. 根拠を確認する

最後に、提案に使う主張を一つずつ確認します。

• どの資料に基づいているか
• 情報はいつのものか
• 公開情報か、商談で聞いた情報か
• 事実か、仮説か
• 数字の計算方法を説明できるか
• 顧客へ伝えてよい情報か

根拠が見つからない主張は、提案書から削除するか、「商談で確認する仮説」へ戻します。

営業ループを一つにつなぐ

顧客企業の変化を調べる
→ 課題の仮説を作る
→ 関係者ごとの関心を整理する
→ 競合と代替手段を確認する
→ 反対意見を出す
→ 根拠を確認する
→ 提案書への反映事項と次回商談の質問を作る

評価で問題が見つかった場合は、必要な工程だけを戻します。

たとえば、課題仮説が抽象的であれば、企業調査または過去の商談記録の確認へ戻します。競合との差が自社の主張だけであれば、競合調査をやり直します。費用対効果の根拠が弱ければ、数値の確認だけを追加します。

合格条件を決める

• 顧客の変化が事実と出典つきで整理されている
• 課題が事実ではなく仮説として書かれている
• 主要な関係者の関心と懸念が整理されている
• 競合だけでなく現状維持も比較されている
• 提案仮説への反対意見が検討されている
• 提案書に書ける内容と未確認事項が分けられている
• 次回商談で確認する質問が三つから五つに絞られている

情報をすべて集めることが合格ではありません。

次の商談で仮説を確認し、提案を前へ進められる状態になっていることが合格です。

最終成果物は三つに絞る

1. 提案書反映メモ

• 顧客に起きている変化
• 提案の背景として使える事実
• 顧客課題の仮説
• 自社が提供できる価値
• 競合や現状維持との違い
• 現時点では書かない方がよい内容

2. 想定反論と回答方針

• 顧客から予想される反論
• 反論の背景
• 現時点で回答できること
• 追加確認が必要なこと
• 回答に使う根拠

3. 次回商談の確認事項

• 仮説が正しいかを確認する質問
• 関係者と意思決定の流れを確認する質問
• 現在の代替手段を確認する質問
• 導入条件や制約を確認する質問
• 次の段階へ進む条件を確認する質問

ここまで整理してから、AIに提案書を書かせます。

AIに任せるのは、証拠パックの作成、抜け漏れの確認、反対意見の検討、提案書の下書きまでです。

価格、契約条件、顧客への約束、外部へ送る最終提案書は、人間が確認します。重要な操作の前で処理を止め、人間の承認後に再開する考え方は、実際のエージェント開発基盤でも採用されています。[4]

営業でLoop Engineeringを使う価値は、顧客調査を自動化することだけではありません。

調査、仮説、提案、商談を分断せず、一つの流れとしてつなげられることにあります。

第4章　マーケティングで使う――施策案を増やすのではなく、検証可能にする

マーケティングでAIを使うと、施策案を短時間で大量に出せます。

「新規顧客を増やす方法を考えてください」と頼めば、広告、SNS、セミナー、ホワイトペーパー、メール、紹介キャンペーンなど、さまざまな案が返ってきます。

しかし、案の数が増えても、実行すべき施策を選べるとは限りません。

AIが出す施策には、次のような問題が起こりがちです。

• 顧客の課題が曖昧なまま施策を考えている
• 自社の予算や人員を考慮していない
• 他社の成功事例を、そのまま当てはめている
• 同じ施策を表現だけ変えて並べている
• 成功するための前提が書かれていない
• 効果の測り方や中止条件が決まっていない

こうした状態で施策を実施すると、結果が悪かったときに、何が原因だったのか分かりません。

施策そのものが悪かったのか。対象顧客が違っていたのか。訴求が弱かったのか。チャネルが合わなかったのか。実行量が足りなかったのか。判断に必要な期間が短すぎたのか。

マーケティングでLoop Engineeringを使う目的は、施策案を自動で作り続けることではありません。

施策が成立する前提を明らかにし、小さく検証できる形へ変えることです。

施策を考える前に、顧客の行動を確認する

施策を考えるとき、最初からチャネルを選ぶと、議論が「Instagramを使うか」「広告を出すか」「セミナーを開くか」といった手段の比較になりやすくなります。

しかし、チャネルを選ぶ前に確認すべきなのは、顧客の行動です。

• 顧客はどのような状況で問題を認識するのか
• 問題を解決するために、現在何をしているのか
• どこで情報を探すのか
• どの情報を信頼するのか
• 比較するとき、何を判断基準にするのか
• 行動を起こさない理由は何か

たとえば、B2Bサービスのホワイトペーパーを作るとします。

「ホワイトペーパーでリードを獲得する」という施策から考え始めると、テーマ、タイトル、ページ数、広告方法の話に進みます。

しかし、顧客がすでに生成AIを使って一般的な情報を収集しているなら、情報をまとめただけの資料には個人情報を入力しないかもしれません。

その場合に確認すべきなのは、ホワイトペーパーを作る方法ではなく、次のような点です。

• 顧客がAIだけでは確認できない情報は何か
• 顧客が判断に迷っている点は何か
• どのような証拠や実例があれば接点を持つ価値を感じるか
• 資料を読んだ後、どの行動へ進んでほしいか

施策は、顧客の行動仮説から逆算します。

マーケティングの仕事を六つに分ける

1. 顧客課題を確認する

最初の担当は、顧客が抱えている問題を整理します。

使用する材料は、顧客インタビュー、営業記録、問い合わせ、検索語、アンケート、レビュー、過去の施策結果などです。

ここでは、顧客の発言をそのまま課題にしないことが重要です。

「もっと情報が欲しい」という声があっても、本当に足りないのは情報ではなく、選択肢を比較する基準かもしれません。「料金が高い」という声の背景には、効果を判断できる証拠が不足している可能性もあります。

事実、解釈、仮説を分けて整理します。

2. 施策候補を作る

次に、顧客の行動を変えるための施策候補を作ります。

この段階では、単なるアイデアの一覧ではなく、次の形式にそろえます。

• 対象とする顧客
• 変えたい行動
• 提供する価値
• 使用するチャネル
• 行動を促す仕組み
• 成立に必要な前提

たとえば、ウェビナーを施策候補にするなら、単に「ウェビナーを開催する」とは書きません。

検討初期の営業責任者を対象に、導入失敗の具体例と判断基準を提供し、個別相談への移行を促す。対象者が一般論よりも実例を求めていること、開催案内を届けられる接点があることを前提とする。

このように書けば、後から前提を検証できます。

3. 競合する行動を確認する

マーケティング施策の競合は、他社の広告やコンテンツだけではありません。

顧客が現在行っている行動も競合です。

• 検索だけで済ませる
• 生成AIへ質問する
• 比較サイトを見る
• 同僚や取引先に聞く
• 既存業者へ相談する
• 検討を先送りする
• 何もしない

顧客が現状の行動を変えない理由を確認しなければ、新しい施策が選ばれる理由も説明できません。

4. 実行可能性を評価する

魅力的に見える施策でも、自社が継続できなければ成果にはつながりません。

実行可能性の担当には、次を評価させます。

• 必要な人員
• 必要な専門知識
• 制作や準備にかかる時間
• 広告費や外注費
• 営業や店舗など他部門の負担
• 継続する頻度
• 法務、個人情報、ブランド上の制約

特に注意したいのが、継続運用を前提とする施策です。

「毎日SNSを更新する」「毎週記事を書く」といった案は簡単に出せますが、担当者と時間を確保できなければ続きません。

施策の魅力だけでなく、運用を続けられるかまで評価します。

5. 失敗する条件を考える

施策を実行する前に、「実施したが失敗した」と仮定します。

そのうえで、なぜ失敗したのかを考えます。

• テーマが顧客の優先課題とずれていた
• 内容が生成AIで得られる一般論だった
• タイトルから得られる価値が伝わらなかった
• 入力項目が多く、ダウンロードされなかった
• 配布するチャネルが弱かった
• ダウンロード後の営業対応が遅かった
• リード数は増えたが、対象顧客ではなかった

失敗理由を先に出すことで、実施前に確認すべき前提が見つかります。

反対意見や失敗条件を検討する担当は、施策を否定するために置くのではありません。失敗してから学ぶ範囲を減らすために置きます。

6. 効果測定を設計する

最後に、何を見て施策を判断するのかを決めます。

指標は、最終成果だけでなく、途中の行動も含めます。

• 案内ページへの訪問数
• ダウンロード率
• 対象企業・対象職種の割合
• 資料閲覧後の行動
• 商談への移行率
• 営業が有望と判断した割合
• 作成と運用にかかった費用や時間

さらに、継続、修正、中止の条件を決めます。

対象顧客のダウンロードが一定数を超え、商談移行が確認できれば継続する。訪問はあるがダウンロードされなければ、タイトルや提供価値を修正する。対象外のリードが大半であれば、配布先や訴求対象を見直す。

評価基準が具体的であるほど、AIによる評価と修正のループを設計しやすくなります。[5]

マーケティングループを一つにつなぐ

顧客課題と現在の行動を確認する
→ 施策候補を作る
→ 競合する行動を確認する
→ 実行可能性を評価する
→ 失敗する条件を考える
→ 効果測定と判断基準を決める
→ 小さな検証を実施する
→ 結果に応じて継続、修正、中止を決める

結果が基準を満たさなかった場合は、原因に応じた工程だけを戻します。

訪問者が少なければ、配布チャネルや対象顧客を見直します。訪問者は多いのに申し込みが少なければ、提供価値や申し込み条件を確認します。申し込みは多いのに商談につながらなければ、テーマ、対象者、営業への引き継ぎを見直します。

最初から大きな施策にしない

AIは、完成度の高い施策計画を短時間で作れます。しかし、資料が詳しいことと、施策が正しいことは別です。

顧客行動に関する重要な前提が未確認であれば、大きな予算を使う前に小さく試します。

• 一部の顧客だけに案内する
• 広告を出す前に営業担当者から紹介する
• 完成版を作る前に概要だけを見せる
• 一店舗または一地域で試す
• 長期契約の前に短期間で実施する
• 複数案を同時に試さず、一つの前提を確かめる

小さな検証の目的は、すぐに大きな成果を出すことではありません。

施策の成否を左右する前提が正しいかを確認することです。

合格条件を決める

• 対象顧客と変えたい行動が明確である
• 顧客課題に事実または観察結果がある
• 現在の代替行動が整理されている
• 施策が成立する前提が明示されている
• 実行に必要な人員、費用、期間が確認されている
• 主な失敗条件が検討されている
• 最初に確かめる前提が一つに絞られている
• 継続、修正、中止の判断基準が決まっている

「よさそうな施策案ができた」ことは、合格条件ではありません。

小さく実行して、結果から次の判断ができる状態になったことが合格です。

最終成果物は「施策一覧」ではなく「検証計画」にする

項目	内容
対象顧客	誰の行動を変えるのか
顧客課題	どのような問題に対応するのか
現在の行動	顧客は今、何をしているのか
施策	何を提供し、どの行動を促すのか
重要な前提	何が正しければ施策が成立するのか
失敗条件	どのような理由で失敗し得るか
最小検証	最初に何を小さく試すのか
指標	何を観察するのか
判断基準	どの結果なら継続、修正、中止するのか
人間の確認	予算、表現、個人情報など何を承認するか

広告予算の確定、顧客情報の利用、対外的な表現、キャンペーンの公開は、AIだけで決めるべきではありません。重要な操作の前に処理を止め、人間が承認する境界を置きます。[4]

マーケティングでLoop Engineeringを使う価値は、アイデアを増やすことではありません。

顧客についての仮説を、実施可能で評価可能な検証へ変えられることにあります。

第5章　商品企画で使う――顧客ニーズ、競合、実現性を分けて検証する

商品企画でも、AIは多くの案を短時間で作れます。

顧客の声や競合情報を入力すれば、新機能、サービス改善、新商品、価格プランなどの候補が並びます。各案のメリットやデメリットを比較し、企画書の下書きを作ることもできます。

しかし、もっともらしい企画案ができたからといって、開発すべきとは限りません。

• 顧客の要望を、そのままニーズとして扱う
• 声の大きい顧客の意見に引っ張られる
• 競合にある機能を、必要な機能だと考える
• 市場性と技術的な実現性を一度に議論する
• 開発できることが、売れる理由に置き換わる
• 推進する側の仮説を、AIが補強し続ける
• 企画を中止する条件が決まっていない

商品企画でLoop Engineeringを使う目的は、AIに完成した企画を考えさせることではありません。

企画を支える前提を分解し、次の検証へ進む価値があるかを判断することです。

顧客の要望と、解決すべき課題を分ける

顧客から「この機能が欲しい」と言われると、それが企画の出発点になります。

しかし、要望は必ずしも解決策として正しいとは限りません。

たとえば、業務システムの利用者から「すべてのデータをExcelへ出力できるようにしてほしい」という要望が出たとします。

• システム上で必要な集計ができない
• 上司への報告形式がExcelで決まっている
• 他のシステムへデータを移したい
• 画面上では必要な情報を探しにくい
• システムの数字を信用できず、自分で再計算したい

どの課題が背景にあるかによって、必要な解決策は変わります。

Excel出力を追加することが最適かもしれません。しかし、集計画面の改善、報告書の自動生成、他システムとの連携、数字の計算根拠の表示で解決できる可能性もあります。

顧客が求めたもの
→ その要望が出た状況
→ 顧客が達成したいこと
→ 現在困っていること
→ 現在使っている代替手段
→ 考えられる複数の解決策

「顧客が言ったから作る」のではなく、顧客がなぜそう言ったのかを確かめるところから始めます。

商品企画の仕事を七つに分ける

1. 顧客課題を整理する

最初に、どの顧客が、どのような状況で、何に困っているのかを整理します。

• 顧客インタビュー
• 営業やカスタマーサポートの記録
• 問い合わせや要望
• 商品レビュー
• 解約理由
• 利用状況
• アンケート
• 現場観察

「顧客がこの機能を使っていない」は事実として確認できるかもしれません。しかし、「機能が分かりにくいから使っていない」は仮説です。必要性を感じていない、権限がない、別の方法を使っているといった可能性もあります。

2. 利用場面を確認する

• いつ使うのか
• どこで使うのか
• 誰と一緒に使うのか
• 前後にどのような作業があるのか
• どの程度の頻度で起こるのか
• 失敗すると何が困るのか

「誰が欲しがっているか」だけでなく、どのような場面で必要になるかを明確にします。

3. 現在の代替手段を調べる

• 表計算ソフトで管理する
• 紙やメールを使う
• 人が手作業で補う
• 他社の商品を使う
• 外部業者へ依頼する
• 不便なまま我慢する
• その作業自体を行わない

新しい企画は、競合商品だけでなく、こうした現在の方法よりも選ぶ価値がなければなりません。

• なぜ現在の方法を使い続けているのか
• どの程度の不便なら許容されているのか
• 変更するために、どのような負担がかかるのか
• 新しい方法へ移る理由は十分にあるか

4. 競合を比較する

競合調査では、機能の有無だけを並べないようにします。

• 対象顧客
• 解決する課題
• 主な利用場面
• 価格
• 導入の難しさ
• 継続運用の負担
• 他商品との連携
• 顧客から評価されている点
• 不満や弱点
• 選ばない理由

競合にある機能が自社にないからといって、追加すべきとは限りません。

5. 市場性を評価する

• 同じ課題を持つ顧客はどの程度いるか
• 課題の優先度は高いか
• 顧客は解決のために費用を払うか
• 誰が予算を持っているか
• 購入までにどのような条件があるか
• 一時的な問題か、継続する問題か
• 市場が広がる要因と縮小する要因は何か

市場規模を推計する場合は、数字だけを出させず、計算式、前提、出典をセットで残します。

数字が大きいことより、なぜその数字になったのかを説明できることが重要です。

6. 実現性と収益性を分けて評価する

実現性では、次の点を見ます。

• 技術的に作れるか
• 必要なデータを取得できるか
• 既存の商品や業務と組み合わせられるか
• 法務やセキュリティ上の問題はないか
• 現場で運用できるか
• 開発後の保守を続けられるか

収益性では、次を確認します。

• 顧客はいくらなら支払うか
• どのように販売するか
• 開発と提供にどの程度の費用がかかるか
• 導入支援や問い合わせ対応の負担はどの程度か
• 継続収益につながるか
• 既存商品への悪影響はないか

「作れる」と「儲かる」を同じ担当に評価させると、技術的に魅力のある案を事業としても正当化しやすくなります。別々に評価したうえで、人間が重み付けを判断します。

7. 企画を否定する証拠を探す

• 顧客課題は一部の顧客にしか存在しない
• 課題はあるが、優先度が低い
• 顧客は現在の代替手段で満足している
• 競合との差が小さい
• 利用頻度が低く、費用を払う理由が弱い
• 導入や運用の負担が効果を上回る
• 必要なデータや技術を確保できない
• 販売や支援に想定以上の費用がかかる

反証担当には、企画をより魅力的にする改善案を考えさせません。まず、現在の企画を成立させない証拠を探させます。

商品企画のループを一つにつなぐ

顧客の声を集める
→ 要望と課題を分ける
→ 利用場面を確認する
→ 現在の代替手段を調べる
→ 複数の解決案を作る
→ 競合、市場性、実現性、収益性を別々に評価する
→ 企画を否定する証拠を探す
→ 未確認の前提を整理する
→ 次に検証する前提を決める

合格条件を満たさない場合は、問題がある工程だけを戻します。

未確認の前提を一覧にする

前提	現在の根拠	確信度	間違っていた場合の影響	確認方法
対象顧客が課題を強く感じている	5社への聞き取り	中	企画の必要性がなくなる	追加インタビュー
現在の方法より時間を削減できる	簡易試算	低	提供価値が弱くなる	試作品による比較
月額料金を支払う意思がある	未確認	低	収益モデルが成立しない	価格提示テスト
既存システムと連携できる	技術担当の初期見解	中	開発期間が延びる	技術検証

間違っていた場合に企画全体が成立しなくなる前提から確認します。

合格条件を決める

• 対象顧客と利用場面が明確である
• 顧客の要望と解決すべき課題が分けられている
• 現在の代替手段が確認されている
• 複数の解決策が比較されている
• 競合との差が機能以外の観点でも説明されている
• 市場性、実現性、収益性が別々に評価されている
• 企画を否定する証拠が検討されている
• 未確認の前提と確認方法が整理されている
• 次に検証する最重要前提が一つに絞られている

完成した企画書があることは、合格条件ではありません。

次の検証へ進む価値があるかを判断できる状態になっていることが合格です。

最終成果物は「企画決定」ではなく「次の検証判断」にする

• 解決したい顧客課題
• 対象顧客と利用場面
• 現在の代替手段
• 検討した解決策
• 採用した企画案と理由
• 競合との違い
• 市場性、実現性、収益性の評価
• 企画を否定する証拠
• 未確認の前提
• 次に実施する顧客確認や技術検証
• 継続、修正、中止を判断する条件

AIに任せるのは、情報の整理、比較、反証、未確認事項の抽出、企画書の下書きまでです。

どの市場を対象にするか、弱い前提を許容するか、開発投資を行うか、企画を採用するかは、人間が判断します。

商品企画でLoop Engineeringを使う価値は、企画案を自動生成できることではありません。

顧客の声から企画案までの間にある仮説を分解し、何を確認すれば次へ進めるかを明確にできることにあります。

第6章　チャットだけで始める最小構成

ここまで紹介した内容を見ると、Loop Engineeringには専用のシステムや自動化ツールが必要だと感じるかもしれません。

しかし、最初から仕組みを作り込む必要はありません。

むしろ、役割分担や合格条件が曖昧なまま自動化すると、うまくいかない進め方をそのまま繰り返すことになります。

最初に行うべきなのは、自動化ではなく、仕事の進め方が本当に機能するかをチャット上で確かめることです。

Anthropicも、AIを使った仕組みは最も単純な方法から始め、必要な場合だけ複雑性を加えるよう勧めています。[5]

最初は人間がループを回す

最小構成では、一つのチャットの中で人間が進行役を務めます。

目的と材料を入力する
→ AIに仕事を分解させる
→ 各担当に独立して検討させる
→ 共通形式で結果を出させる
→ 評価担当に合格条件を確認させる
→ 不足部分だけをやり直す
→ 人間が最終判断する

この段階では、AIが自動で次の工程へ進まなくても構いません。

人間が結果を確認し、「次は反証担当へ進んでください」「根拠が不足している項目だけ再調査してください」と指示します。

重要なのは、毎回の指示を減らすことではありません。

どの順番で進めると仕事の質が上がるのかを確認することです。

一回の指示にすべてを詰め込まない

便利だからといって、最初の指示にすべての工程を入れるのは避けた方がよいでしょう。

顧客企業を調べ、課題を分析し、競合と比較し、反対意見も考え、提案書を作り、評価して、問題があれば修正してください。

この指示でも回答は得られます。

しかし、調査、仮説、評価、修正が一つの回答の中で進むため、どこで間違ったのか分かりにくくなります。

また、最初に作った仮説を同じAIが評価するため、自分の結論を肯定する方向へ進む可能性もあります。

チャットだけで実行するときも、少なくとも次の四段階に分けます。

1. 設計
2. 独立検討
3. 統合
4. 評価と修正

段階1　設計する

最初に、仕事の目的と進め方を決めます。

この段階では、まだ調査や企画案の作成を始めません。

今回の目的、使用できる材料、必要な判断を確認し、仕事を複数の独立した作業に分けてください。
まだ調査や提案は始めず、役割分担、各担当の出力、合格条件、停止条件だけを提案してください。

AIが出した設計を、人間が確認します。

• 最後に何を判断するのか
• 不要な作業が含まれていないか
• 各担当の仕事が重複していないか
• 合格条件が確認可能か
• 人間が判断すべき範囲が残っているか

この設計に問題があれば、実作業へ進む前に直します。

段階2　各担当が独立して検討する

次に、設計した役割ごとに作業させます。

一つのチャットで進める場合でも、他の担当の結論を見せずに、順番に独立回答を作らせます。

まず顧客課題担当として検討してください。
他の担当がどのような結論を出すかは推測せず、与えられた材料だけを使ってください。
出力は「主張」「根拠」「反対証拠」「未確認事項」「次の行動」の形式にしてください。

回答が出たら、その内容をいったん保存します。

続いて、競合担当や反証担当にも同じ形式で回答させます。

ここで大切なのは、後の担当に前の担当の結論を必要以上に見せないことです。

反証担当には、主要な主張だけを渡し、別の資料や評価基準から独立して検討させます。

段階3　結果を統合する

各担当の回答がそろったら、統合します。

統合は、多数決で結論を決める作業ではありません。

• 複数の担当が一致した点
• 意見が分かれた点
• 根拠が強い主張
• 根拠が弱い主張
• 反対証拠がある主張
• まだ確認できていないこと
• 人間が判断すべきこと

各担当の結果を統合してください。
無理に一つの結論へまとめず、意見が分かれた点と、その理由を残してください。
事実、仮説、反対証拠、未確認事項、人間の判断事項を分けてください。

統合時に少数意見を消さないことが重要です。

調査でも、複数のAIが合意する方向へ引っ張られ、正しい少数意見や例外条件が失われることがあります。[3]

段階4　合格条件で評価する

統合結果ができたら、別の役割として評価させます。

次の合格条件に基づいて、統合結果を評価してください。
各条件を「合格」「不合格」「人間による確認が必要」に分類してください。
不合格の場合は、どの工程へ戻すべきかを示してください。
この段階では本文を書き直さないでください。

合格条件	判定	理由	戻す工程
主要な主張に根拠がある	不合格	2つの主張に出典がない	情報収集
反対意見が検討されている	合格	主要3案すべてに反証あり	―
数字の計算が一致している	要確認	前提となる単価が未確認	数値確認／人間
次の行動が絞られている	不合格	8項目あり優先順位なし	統合

不足部分だけをやり直す

評価で不合格になったら、全体を作り直させません。

評価結果のうち、「競合情報の新しさ」だけが不合格でした。
既存の顧客課題、費用対効果、反証は変更せず、競合情報のみを再調査してください。
更新した箇所と、結論への影響を示してください。

市場規模の計算に使った前提と単位を確認してください。
文章全体は書き直さず、計算式、使用した数値、出典、修正前後の差だけを示してください。

修正範囲を限定することで、確認済みの内容まで変わることを防げます。

チャットで使う共通テンプレート

## 今回の目的
この仕事を終えた後に、人間が判断したいこと：

## 使用する材料
使用してよい資料・情報：

## 使用しない材料・禁止事項
推測してはいけないこと、対象外：

## 役割分担
必要な担当と、それぞれの作業：

## 各担当の出力形式
1. 主張
2. 根拠
3. 反対証拠・例外
4. 未確認事項
5. 次の行動

## 合格条件
何を満たせば次へ進めるか：

## 修正ルール
不合格項目ごとに、どの担当へ戻すか：

## 停止条件
最大反復回数、期限、打ち切る条件：

## 人間が判断すること
AIだけで決めてはいけない項目：

まずは作業を開始せず、この設計に不足や重複がないか確認してください。

最初からすべての欄を埋める必要はありません。AIに空欄を補う案を出させ、人間が確認してから作業を始めます。

そのまま使える5段階のプロンプト

ここからは、チャット上で実際にループを回すためのプロンプトを紹介します。

すべてを一度に実行させるのではなく、各段階の出力を確認してから、次のプロンプトへ進んでください。「［　］」の部分を、自分の仕事に合わせて書き換えます。

プロンプト1　仕事の進め方を設計する

あなたは、AIを使った業務プロセスの設計担当です。
以下の仕事を、複数の担当が独立して検討し、評価結果に応じて不足部分だけを修正できる流れにしてください。

## 今回の仕事
［例：A社への提案準備］

## 最後に人間が判断したいこと
［例：次回商談で確認する質問と、提案書へ反映する仮説］

## 使用できる材料
［資料名、商談記録、顧客データ、調査結果など］

## 対象外・禁止事項
［推測で断定しないこと、調べない範囲、利用してはいけない情報など］

次の項目を設計してください。

1. 必要な担当と、それぞれが行う作業
2. 各担当に渡す材料
3. 各担当の出力形式
4. 最終成果物
5. 合格条件
6. 不合格だった場合の戻し先
7. 最大反復回数と停止条件
8. AIでは決めず、人間へ戻す判断

担当を増やしすぎないでください。最初は3〜5担当を目安とし、仕事を分ける意味がある場合だけ追加してください。
この段階では、実際の調査、分析、提案作成は開始しないでください。

プロンプト2　各担当に独立して検討させる

あなたは［担当名］です。

## あなたの担当業務
［この担当が行う作業］

## 今回の目的
［最終的に人間が判断したいこと］

## 使用してよい材料
［この担当に必要な資料や情報］

## 制約
- 資料にないことを事実として断定しない
- 推測は「仮説」と明記する
- 確認できないことは「未確認」とする
- 他の担当が出しそうな結論に合わせない
- 自分の担当範囲を超えた結論を出さない

次の形式で出力してください。

### 主張
この担当範囲から何が言えるか。

### 根拠
どの資料や事実に基づくか。出典や該当箇所も示す。

### 反対証拠・例外
主張が成立しない可能性や、異なる解釈はあるか。

### 未確認事項
現在の材料では確認できないことは何か。

### 次の行動
追加で調べる、顧客へ聞く、社内で確認することは何か。

結論を魅力的に見せることより、事実、仮説、未確認事項を正しく分けることを優先してください。

一つのチャットで進める場合は、前の担当の回答に影響されないよう、「前の担当の結論を前提にしない」と明示します。

より独立性を高めたい場合は、担当ごとに別のチャットを使い、回答だけを統合用のチャットへ集めます。

プロンプト3　結果を統合する

あなたは、複数の担当による検討結果を整理する統合担当です。

以下に、各担当の回答を提示します。

［各担当の回答を貼り付ける］

今回の目的は、［人間が最終的に判断したいこと］です。

各担当の意見を平均化したり、多数決で一つにまとめたりしないでください。次の形式で整理してください。

## 1. 確認できた事実
複数の資料または明確な根拠で確認できること。

## 2. 有力な仮説
根拠はあるが、まだ確認が必要なこと。

## 3. 反対証拠・例外
有力な仮説に反する情報や、成立しない条件。

## 4. 担当間で意見が分かれた点
意見の違いと、それぞれが使った根拠。

## 5. 未確認事項
現在の材料では判断できないこと。

## 6. 次に取るべき行動
優先度順に3つ以内。

## 7. 人間が判断すべきこと
AIだけでは決めるべきでない事項。

根拠が弱い主張を、統合時に強い結論へ変えないでください。
意見が分かれている場合は、無理に解消せず、そのまま残してください。

プロンプト4　合格条件で評価する

あなたは、成果物の品質評価を行う担当です。

以下の統合結果を、事前に決めた合格条件に沿って評価してください。

## 統合結果
［統合結果を貼り付ける］

## 合格条件
［プロンプト1で決めた合格条件を貼り付ける］

各条件を、次のいずれかに分類してください。

- 合格
- 不合格
- 人間による確認が必要

次の表で出力してください。

| 合格条件 | 判定 | 判定理由 | 不足しているもの | 戻す担当・工程 |
|---|---|---|---|---|

続けて、次の項目を示してください。

1. 修正が必要な項目
2. そのまま維持すべき項目
3. 人間が判断すべき項目
4. 停止条件に達しているか
5. 次の処理を「部分修正」「人間確認」「完了」のいずれにするか

この段階では、統合結果の本文を書き直さないでください。
表現の良さではなく、根拠、論点の充足、反証、未確認事項、次の行動を評価してください。

プロンプト5　不合格部分だけを修正する

あなたは［戻し先の担当名］です。

評価の結果、次の項目が不合格でした。

## 不合格項目
［評価結果から該当部分を貼り付ける］

## 修正対象
［例：競合情報の新しさ、費用対効果の根拠、顧客課題の具体性］

## 変更してはいけない部分
［すでに合格している項目］

次の手順で修正してください。

1. 不合格になった原因を確認する
2. 必要な情報だけを追加で調べる、または再分析する
3. 修正前と修正後の違いを示す
4. 統合結果のどこへ反映すべきか示す
5. 修正しても残る未確認事項を示す

成果物全体を最初から書き直さないでください。
修正対象以外の主張、数字、表現を変更しないでください。

修正後は、プロンプト4へ戻して再評価します。

ただし、あらかじめ決めた最大反復回数へ達した場合は、調査や修正を続けません。「未解決事項」と「人間による確認が必要なこと」を残して終了します。

営業で使うプロンプト例

A社への次回提案に向けて、顧客調査と提案仮説の検討を行います。

最終的に決めたいのは、次回商談で確認する質問、提案書へ反映できる事実、商談で確認するまで書かない仮説です。

使用できる材料は、A社の公式Webサイト、最新の決算資料、過去2回の商談メモ、自社サービス資料です。

次の担当に仕事を分けてください。

1. 顧客企業の変化
2. 顧客課題の仮説
3. 関係者ごとの関心と懸念
4. 競合・代替手段
5. 提案への反証
6. 根拠確認と統合

各担当は、「主張」「根拠」「反対証拠」「未確認事項」「次の行動」を出力してください。

合格条件は次のとおりです。

- 事実と仮説が分かれている
- 主要な主張に根拠がある
- 現状維持を含む代替手段が検討されている
- 提案への反対意見がある
- 提案書に書けることと未確認事項が分かれている
- 次回商談の質問が5つ以内である

修正は最大2回とします。価格、契約条件、顧客への約束、最終提案の採否は人間が判断します。

まずは調査を開始せず、役割の重複や不足、合格条件の曖昧さを確認してください。

マーケティングで使うプロンプト例

新しいリード獲得施策の候補を検討し、最初に実施する小規模な検証を一つ決めます。

使用できる材料は、過去1年間の施策結果、顧客アンケート、営業への聞き取り、Webサイトのアクセス状況です。

次の担当に分けてください。

1. 顧客課題と現在の行動
2. 施策候補
3. 競合する行動・代替手段
4. 実行可能性
5. 失敗条件
6. 効果測定と統合

施策候補は3つまでとし、それぞれについて「対象顧客」「変えたい行動」「提供価値」「重要な前提」「主な失敗条件」「最小検証」を示してください。

合格条件は次のとおりです。

- 対象顧客と変えたい行動が明確である
- 顧客課題に根拠がある
- 現在の代替行動が整理されている
- 施策の成立前提と失敗条件がある
- 最初に確認する前提が一つに絞られている
- 継続、修正、中止の判断基準がある

修正は最大2回です。予算、個人情報の利用、対外表現、公開判断は人間が行います。

まずは施策案を作らず、進め方だけを設計してください。

商品企画で使うプロンプト例

顧客から寄せられた［要望の内容］について、商品企画として次の顧客検証へ進める価値があるかを判断します。

使用できる材料は、顧客要望、問い合わせ記録、利用状況、競合情報、技術担当者の初期見解です。

次の担当に分けてください。

1. 顧客課題
2. 利用場面
3. 現在の代替手段
4. 競合比較
5. 市場性
6. 実現性
7. 収益性
8. 企画を否定する証拠
9. 統合

各担当は、事実、仮説、反対証拠、未確認事項を分けてください。

合格条件は次のとおりです。

- 顧客の要望と解決すべき課題が分けられている
- 対象顧客と利用場面が明確である
- 現在の代替手段が確認されている
- 市場性、実現性、収益性が別々に評価されている
- 企画を否定する証拠がある
- 重要な未確認前提と確認方法が整理されている
- 次に検証する前提が一つに絞られている

顧客または技術担当者への確認が必要になった場合は、推測で埋めず停止してください。対象市場、開発投資、優先順位、企画の採否は人間が判断します。

まずは企画案を作らず、調査と評価の進め方を設計してください。

プロンプトは完成品ではなく、仕事の記録から改善する

これらのプロンプトを一度使っただけで、完成した業務プロセスになるわけではありません。

実際に使うと、役割が重複する、反証が弱い、必要な資料が足りない、合格条件が曖昧といった問題が見つかります。

その失敗を、次回のプロンプトへ反映します。

たとえば、反証担当が推進側と同じ意見になったのであれば、次回は使用する資料や評価基準を分けます。調査範囲が広がりすぎたのであれば、対象外と最大件数を追加します。文章だけが書き換えられたのであれば、「修正対象以外を変更しない」という制約を強めます。

プロンプトを先に完成させるのではなく、仕事を実行した記録から、役割、合格条件、修正ルールを育てることが重要です。

第7章　うまくいかないときに見直す七つの失敗

マルチエージェント討議を使っても、期待した結果にならないことがあります。

役割を増やしたのに似た意見しか出ない。議論を続けるほど結論が曖昧になる。調査結果は増えるのに、次の行動を決められない。修正するたびに、別の箇所がおかしくなる。

このようなとき、「もっと性能の高いAIを使う」「さらに別の専門家を追加する」と考えがちです。

しかし、多くの場合、先に見直すべきなのはモデルではなく、仕事の分け方や評価方法です。

2025年に発表されたマルチエージェントシステムの失敗研究では、150を超えるタスクの分析から14の失敗パターンが確認されました。失敗は、大きく「役割や仕組みの設計」「エージェント間の不整合」「検証と終了条件」の三つに分類されています。[6]

失敗1　役割名は違うが、全員が同じ意見になる

「営業責任者」「マーケティング責任者」「経営コンサルタント」と役割を分けたのに、全員が似た結論を出すことがあります。

原因は、役割名ではなく、与えられた仕事が同じだからです。

全員が同じ資料を読み、同じ質問に答え、同じ成功基準で評価すれば、肩書を変えても視点はあまり変わりません。

• 顧客課題の根拠を確認する
• 実施に必要な人員と費用を確認する
• 施策が失敗する条件を探す
• 現在の代替手段と比較する

さらに、使う材料も必要に応じて分けます。

顧客課題担当にはインタビューや商談記録、実行可能性担当には社内の人員や費用、反証担当には失敗事例や否定的なレビューを優先して渡します。

違う人物を演じさせるのではなく、違う証拠を使って違う仕事をさせることが重要です。

失敗2　AI同士が早く合意しすぎる

複数のAIに討議させると、最初は異なる意見を出していても、途中から一つの結論へまとまることがあります。

問題は、根拠を比較した結果ではなく、他のAIに同調した結果として合意することです。

2025年の研究では、マルチエージェント討議を続けるうちに、正しい回答を出していたAIが誤った意見へ移る場合が確認されました。AIは誤った推論を批判するより、他者との合意を選ぶことがあると報告されています。[7]

これを防ぐには、討議を始める前に各担当の初期回答を保存します。

• 最初から一致していた点
• 討議後に一致した点
• 途中で意見を変えた担当
• 意見を変えた根拠
• 最後まで残った反対意見

合意した意見を優先するのではなく、各主張を根拠の強さで評価してください。少数意見であっても、根拠がある場合は削除しないでください。

目標は全員一致ではありません。

人間が、どの意見を採用するか判断できる状態を作ることです。

失敗3　情報は増えるが、判断につながらない

AIに追加調査を頼むたびに、新しい市場情報、競合事例、顧客の声が増えていきます。

しかし、報告書が長くなっても、何をすべきか決められないことがあります。

この原因は、調査の目的が「詳しく知ること」になっているためです。

営業であれば、顧客企業について詳しくなることではなく、次回商談で何を確認するかを決めることが目的です。

マーケティングであれば、多くの成功事例を集めることではなく、最初に試す施策と評価方法を決めることです。

商品企画であれば、市場を網羅的に理解することではなく、次に確かめる前提を決めることです。

この情報によって、どの判断が変わるのか。

判断が変わらない情報は、今回の仕事では優先度が低い情報です。

失敗4　出典はあるが、主張の根拠になっていない

AIの回答に多くの出典が付いていると、信頼できるように見えます。

しかし、リンク先が存在することと、その資料が本文の主張を裏づけていることは別です。

2026年の研究では、高性能なモデルでも、引用リンクの有効性は94％以上、内容の関連性は80％以上だった一方、引用した資料が主張を事実として支えている割合は39〜77％にとどまりました。[8]

出典確認では、主張ごとに次を確認します。

• 出典にその内容が実際に書かれているか
• 出典から直接言えることか
• AIによる解釈や推測が含まれていないか
• 発行日や対象範囲が合っているか
• 別の出典と矛盾していないか

重要な主張を一文ずつ抜き出し、各出典がその主張を「支持する」「一部支持する」「支持しない」「確認できない」のどれに当たるか判定してください。

出典が見つからない主張は、削除するか、仮説または未確認事項へ戻します。

失敗5　修正のたびに全体を書き直す

評価で一つの問題が見つかるたびに、成果物全体を書き直させると、別の問題が生まれます。

これを防ぐには、合格した部分を固定します。

• 修正する項目
• 変更してはいけない項目
• 修正が影響する範囲

競合情報の更新だけを行ってください。顧客課題、費用対効果、反証、次回商談の質問は変更しないでください。更新によって結論が変わる場合は、本文を直接変えず、影響箇所を示してください。

Loop Engineeringでは、成果物全体を作り直すのではなく、不合格になった条件だけを修正することが基本です。

失敗6　調査範囲が広がり続ける

AIは、調べようと思えば関連情報を探し続けられます。

しかし、調査範囲が広いほど、成果物の価値が高くなるわけではありません。

• 対象とする市場や顧客
• 対象期間
• 調べる競合の数
• 使用する情報源
• 追加調査の最大回数
• 調査へ使う時間
• 今回は扱わない論点

この調査結果によって、現在の判断が変わる可能性は高いか。

可能性が低ければ、未確認事項として残して終了します。

失敗7　人間へ戻すべき判断までAIが進める

AIが調査、評価、修正まで進められるようになると、そのまま最終判断も任せたくなります。

しかし、情報を整理できることと、責任を持って判断できることは別です。

営業では、価格、契約条件、顧客への約束をAIだけで決めるべきではありません。

マーケティングでは、広告予算、顧客情報の利用、ブランド表現、外部公開を人間が確認します。

商品企画では、市場の選択、開発投資、優先順位、企画の採否を人間が判断します。

AIエージェント向けの実行基盤にも、重要な操作の前で処理を一時停止し、人間が承認、却下、修正してから再開する仕組みがあります。[4]

次の項目に到達した場合は、推測で進めず処理を停止してください。判断に必要な情報、選択肢、各選択肢の根拠とリスクを整理し、人間へ確認を求めてください。

問題が起きたときの確認表

症状	最初に見直すこと
全員が同じ意見	役割ではなく作業と材料が分かれているか
すぐに合意する	初期回答と少数意見を保存しているか
情報だけ増える	最終的に何を判断するか決まっているか
出典が信用できない	主張と出典を一文単位で確認しているか
修正で別の箇所が変わる	修正対象と固定箇所を指定しているか
調査が終わらない	対象外、期限、最大回数があるか
AIが判断しすぎる	人間へ戻す条件が明記されているか

失敗を診断するプロンプト

以下は、AIを使った業務プロセスの実行結果です。

## 当初の目的
［目的を貼り付ける］

## 設計した役割と手順
［役割・手順を貼り付ける］

## 合格条件と停止条件
［条件を貼り付ける］

## 実際の結果
［成果物または問題が起きた部分を貼り付ける］

次の七つの観点から、問題の原因を診断してください。

1. 役割や作業が重複していないか
2. 他の担当への同調が起きていないか
3. 最終判断と関係のない情報が増えていないか
4. 主張と出典が正しく対応しているか
5. 修正範囲が広すぎなかったか
6. 調査範囲と停止条件が曖昧ではないか
7. 人間が判断すべき領域へAIが入っていないか

次の表で回答してください。

| 問題 | 原因 | 根拠となる箇所 | 次回変更する設計 | 優先度 |
|---|---|---|---|---|

成果物を書き直すのではなく、次回の役割、材料、合格条件、修正ルール、停止条件をどう変更すべきか提案してください。

Loop Engineeringで重要なのは、失敗をなくすことではありません。

失敗した理由を、次回の仕事の設計へ戻せることです。

第8章　どこまで仕組み化するか――三段階で導入する

ここまで紹介してきた流れは、すべて自動化しなくても使えます。

営業担当者がチャットを開き、顧客調査、反証、評価の順に指示する。マーケティング担当者が各工程の結果を確認し、不足部分だけをやり直す。商品企画担当者が未確認の前提を見て、次の顧客調査を決める。

この段階でも、仕事の目的、合格条件、直し方、停止条件が決まっていれば、Loop Engineeringの考え方は取り入れられています。

自動化は、Loop Engineeringの出発点ではありません。

人間が繰り返している進行管理のうち、手順が安定した部分を後から仕組みに移すことです。

導入は、次の三段階で進めます。

段階	人間が行うこと	AIに任せること
段階1	すべての工程を進行する	調査、分析、評価、修正
段階2	入力と最終判断を行う	保存した手順に沿って各工程を実行する
段階3	例外と重要判断を確認する	起動、情報収集、評価、部分修正までを行う

段階1　人間がループを回す

最初の段階では、第6章で紹介したプロンプトを使い、人間が一つずつ工程を進めます。

設計する
→ 各担当に検討させる
→ 結果を統合する
→ 合格条件で評価する
→ 不足部分だけを修正する
→ 人間が判断する

この段階の目的は、作業時間を減らすことではありません。

仕事の分け方と合格条件が正しいかを確かめることです。

実際に使ってみると、設計時には気づかなかった問題が見つかります。

• 顧客課題担当と市場調査担当の作業が重複していた
• 反証担当が一般的なリスクしか出さなかった
• 合格条件が曖昧で、評価するたびに判定が変わった
• 必要な資料が足りず、AIが推測で補っていた
• 修正のたびに成果物全体が書き換わった
• 人間へ戻すべき判断が明記されていなかった

これらの問題を一つずつ直します。

最初から複雑な構成を作るより、単純な方法から始め、必要な場合だけ工程や役割を追加する方が安全です。[5]

段階1で残すもの

• 最初に入力した目的と材料
• 使用した役割
• 合格条件
• 不合格になった項目
• どの工程へ戻したか
• 何回修正したか
• 最後に人間が変更した点
• 次回から追加するルール

成功した回答だけを保存するのではありません。

どこで失敗し、何を変えたら改善したかを残します。

次の段階へ進む条件

• 同じ種類の仕事で二、三回試している
• 必要な役割がほぼ固定されている
• 各担当の出力形式が決まっている
• 合格と不合格を説明できる
• よく起こる失敗と戻し先が分かっている
• 人間が判断する範囲が決まっている

逆に、実行するたびに役割や合格条件が大きく変わるのであれば、まだひな型化する段階ではありません。

段階2　仕事の型として残す

進め方が安定したら、毎回同じ指示を書き直さなくて済むように、ひな型として残します。

保存するのは、一つの長いプロンプトだけではありません。

• どのような仕事に使うか
• 最初に入力する項目
• 使用する資料
• 役割と作業範囲
• 各担当の出力形式
• 統合方法
• 合格条件
• 問題別の修正方法
• 最大反復回数
• 人間へ戻す条件
• 最終成果物の形式

普段使っているAIのプロジェクト機能や、社内の共有文書、プロンプト集などに残せます。

重要なのは、担当者だけが分かるプロンプトにしないことです。

別の社員が使っても、何を入力し、どこを確認し、いつ停止すべきか分かる形にします。

前回の成果物も次回へ引き継ぐ

繰り返し使う仕事では、手順だけでなく前回の結果も保存します。

営業であれば、次を残します。

• 前回の顧客課題仮説
• 商談で確認できたこと
• 否定された仮説
• 関係者と懸念
• 競合や代替手段
• 次回確認すること

マーケティングであれば、次のようになります。

• 実施した施策
• 成立すると考えた前提
• 実際の結果
• 前提が正しかったか
• 継続、修正、中止の判断
• 次回変更する点

商品企画であれば、次を引き継ぎます。

• 顧客課題
• 未確認の前提
• 実施した検証
• 確認できたこと
• 否定されたこと
• 次に検証すること

前回の情報を残さなければ、AIは毎回同じことを調べ、同じ仮説を出します。

ただし、過去の内容を無条件に正しい情報として使ってはいけません。

• 事実か仮説か
• 根拠となる資料
• 確認した日
• 現在も有効か
• 反対証拠
• 更新が必要な条件

段階2での人間の役割

• 入力内容が正しいか
• 今回の仕事にひな型が合っているか
• 使用する資料が最新か
• 不足部分の戻し先が正しいか
• AIが合格とした結果を本当に使えるか
• 外部へ出してよい内容か

次の段階へ進む条件

• 同じ種類の仕事が継続的に発生する
• 入力項目がほぼ決まっている
• 使用する情報源が決まっている
• 合格条件の多くを同じ基準で確認できる
• 不合格の種類と修正方法が決まっている
• 人間の確認なしで進めてもよい工程が分かっている
• 自動化によって減らせる負担が明確である

作業が月に一度しかなく、毎回内容も大きく異なるのであれば、自動化による効果は小さいかもしれません。

段階3　繰り返し部分だけを自動化する

段階3では、手順が安定した部分だけを自動化します。

• 決まった日時に情報を集める
• 新しい資料やニュースがあるか確認する
• 前回から変わった部分を抽出する
• 決められた形式で情報を整理する
• 必須項目が埋まっているか確認する
• 出典が付いているか確認する
• 数字や日付の不一致を検出する
• 不合格項目を担当工程へ戻す
• 人間が確認するための下書きを作る

一方で、次の判断まで自動化する必要はありません。

• 顧客への提案内容を確定する
• 広告予算を決める
• 対外的な表現を公開する
• 開発投資を決める
• 弱い根拠を許容する
• 相反する意見のどちらを採用する
• 重要な前提を変更する

実務では、完全自律よりも半自律を基本にする方が現実的です。

調査や比較、差分確認、形式的な評価はAIが進め、重要な判断や外部への実行前で人間に戻します。

営業で自動化する場合

商談予定が登録される
→ 顧客企業の最新情報を確認する
→ 前回の商談以降の変化を抽出する
→ 過去の仮説と照合する
→ 根拠不足や矛盾を検出する
→ 次回商談の質問案を下書きする
→ 営業担当者が確認する

自動化するのは、情報収集と整理までです。提案内容、価格、商談での発言、顧客への送信は営業担当者が判断します。

マーケティングで自動化する場合

施策結果が更新される
→ 事前に決めた指標と比較する
→ 想定と異なる箇所を抽出する
→ 原因の仮説を複数作る
→ 追加で確認すべき情報を整理する
→ 継続、修正、中止の判断材料を下書きする
→ 担当者が判断する

AIが結果を見て自動で広告予算を増やしたり、対外表現を変更したりするところまでは進めません。

商品企画で自動化する場合

新しい顧客要望やレビューが追加される
→ 既存の顧客課題へ分類する
→ 新しい課題候補を抽出する
→ 競合や代替手段の変化を確認する
→ 未確認前提を更新する
→ 追加検証が必要な企画を提示する
→ 企画担当者が優先順位を判断する

顧客の声を集めて整理する部分は自動化できます。ただし、一部の要望が増えたからといって、自動で開発項目へ追加するべきではありません。

完全自律が向く仕事は限られる

完全自律に近づけやすいのは、出力が限定され、失敗しても大きな影響がなく、合格条件を明確に書ける仕事です。

• 指定した競合企業の新しい発表があるか確認する
• 前回以降に変更された価格や機能を抽出する
• レポート内の重要な主張に出典があるか確認する
• 数字と単位の不一致を検出する
• 更新がなければ何もしない
• 結果を外部送信せず、下書きとして保存する

反対に、正解条件が曖昧で、価値判断や責任を伴う仕事は人間主導で進めます。

1. 合格条件を明確に書けるか
2. 間違えた場合の影響を限定できるか
3. 人間へ戻す境界を置けるか

自動化する価値があるかを確認する

• この仕事は繰り返し発生するか
• 毎回の手順は同じか
• 入力と出力をある程度固定できるか
• 判断基準を説明できるか
• 一部だけをやり直せるか
• 自動化してはいけない判断を分けられるか
• 失敗時に停止できるか
• 自動化の構築と管理に見合う時間を減らせるか

複数のAIを動かすほど、利用量、待ち時間、管理の手間は増えます。Anthropicの実装報告でも、マルチエージェントは通常のチャットより大幅に多くのトークンを消費しています。[2]

自動化できるかではなく、自動化する価値があるかを判断します。

導入段階を判断するプロンプト

以下の仕事について、現在の運用状況を評価し、どの段階まで仕組み化すべきか判断してください。

## 対象業務
［業務名と内容］

## 発生頻度
［毎日、毎週、案件ごとなど］

## 現在の手順
［実際の進め方］

## 使用する材料
［資料、データ、社内情報など］

## 最終成果物
［提案書、施策計画、企画評価など］

## 現在の合格条件
［分かる範囲で記入］

## 人間が必ず判断すること
［価格、公開、投資など］

次の三段階で評価してください。

1. 人間がチャット上で進行すべき工程
2. ひな型として固定できる工程
3. 自動化できる工程

次の表で回答してください。

| 工程 | 現在の課題 | 推奨段階 | 理由 | 自動化前に決めること |
|---|---|---|---|---|

続けて、最初に実施すべき最小の改善を一つ提案してください。
自動化できるという理由だけで、段階3を推奨しないでください。頻度、削減できる負担、誤りの影響、合格条件の明確さを考慮してください。

目指すのは完全自律ではなく、進行負担の削減

Loop Engineeringを導入するとき、分かりやすい目標として「人間が何もしなくても仕事が終わる状態」を置きたくなります。

しかし、営業、マーケティング、商品企画では、仕事の価値は情報処理だけでは決まりません。

顧客との関係、会社としての優先順位、ブランド、予算、現場の事情、将来への判断が関わります。

こうした判断までAIへ渡す必要はありません。

目指すのは、人間を意思決定から外すことではなく、毎回同じ進行指示を出す作業から外すことです。

• 同じ説明を毎回書かなくてよい
• 調査の抜け漏れが減る
• 事実と仮説が分かれている
• 反対意見が必ず検討される
• 不足部分だけをやり直せる
• 前回の結果を次回へ引き継げる
• 重要な判断の前で確実に人間へ戻る

自律化が進んでいることより、仕事が再現可能で、間違えたときに止まり、責任ある判断を人間が行えることの方が重要です。

まとめ　AIに仕事を任せる前に、仕事の進め方を設計する

基本編では、複数のAIに異なる役割を与え、一つのテーマを複数の角度から検討する方法を紹介しました。

今回の応用編で扱ったのは、その討議を一度きりの壁打ちで終わらせず、繰り返し使える仕事の流れへ変える方法です。

重要なのは、参加するAIの人数ではありません。

営業であれば、顧客情報を集めるだけでなく、課題の仮説、反対材料、提案書へ書けること、次回商談で確認することまでをつなげます。

マーケティングであれば、施策案を増やすだけでなく、成立に必要な前提、失敗する条件、最初に試す小さな検証、継続・修正・中止の基準までを設計します。

商品企画であれば、顧客の要望をそのまま企画へ変えず、解決すべき課題、現在の代替手段、市場性、実現性、収益性、企画を否定する証拠を分けて確認します。

どの仕事でも、最初に決める項目は共通しています。

1. この仕事の後に何を判断するのか
2. どの材料を使うのか
3. どのような作業に分けるのか
4. 各担当がどの形式で結果を返すのか
5. 何を満たせば合格とするのか
6. 不足があれば、どの工程だけをやり直すのか
7. 何回で止め、どこから人間が判断するのか

Loop Engineeringの中心は、AIへの巧みな指示文ではありません。

何をもって仕事が前へ進んだと判断するかを、先に決めることです。

AIに「もっと詳しく」「さらに改善して」と頼むだけでは、情報や文章が増え続けます。合格条件と停止条件がなければ、どこまで進めても完成したか判断できません。

反対に、目的、材料、合格条件、直し方、停止条件が決まっていれば、最初は普通のチャットだけでもループを回せます。

設計する
→ 独立して検討させる
→ 統合する
→ 合格条件で評価する
→ 不足部分だけを修正する
→ 人間が判断する

同じ仕事で何度か試し、役割と評価基準が安定したら、ひな型として残します。さらに、繰り返し発生し、判断基準が明確な部分だけを自動化します。

最初から完全自律を目指す必要はありません。

マルチエージェントは、複数の方向を独立して調べられる仕事では有効です。一方で、人数を増やすほど費用や調整の負担も増えます。[2] 同じ計算量で比較すると、一人のAIを継続して使う方がよい結果になる場合もあります。[3]

また、AI同士が議論すれば、必ず正しい結論へ近づくわけでもありません。討議を続けるうちに正しい意見が失われたり、根拠よりも合意が優先されたりする場合があります。[7]

• 各担当が異なる仕事をする
• 事実、仮説、反対証拠、未確認事項を分ける
• 重要な主張と根拠を対応させる
• 不足部分だけをやり直す
• 少数意見や例外を残す
• 回数、期限、費用の上限で止める
• 重要な判断の前で人間へ戻す

こうした進め方を再利用できる状態にすることが、現場におけるLoop Engineeringです。

AIに任せるのは、情報収集、比較、整理、反証、形式的な評価、下書きといった反復作業です。

人間は、何を問うかを決め、顧客や現場と対話し、弱い前提を許容するかを判断し、予算や契約、公開、投資といった結果に責任を持ちます。

人間の役割はなくなりません。

毎回AIへ細かな指示を出す役割から、仕事の境界と判断基準を設計する役割へ変わります。

最初に試す仕事は、大きなものでなくて構いません。

次回商談の準備、施策案の事前検証、顧客要望の整理など、繰り返し発生する仕事を一つ選びます。そして、第6章のプロンプトを使い、目的、役割、合格条件、停止条件を決めてください。

完成した回答だけでなく、どこで失敗したかも残します。

その記録が、次回のプロンプトになり、やがてチームで使える仕事の型になります。

マルチエージェント討議を「便利な壁打ち」で終わらせるか、「繰り返し使える仕事の仕組み」へ変えられるか。

その違いを生むのは、AIの人数ではなく、仕事の進め方を設計できているかどうかです。

出典

1. Addy Osmani, “Loop Engineering,” June 7, 2026.
   https://addyosmani.com/blog/loop-engineering/
2. Jeremy Hadfield, Barry Zhang, Kenneth Lien, Florian Scholz, Jeremy Fox, Daniel Ford, “How we built our multi-agent research system,” Anthropic, June 13, 2025.
   https://www.anthropic.com/engineering/multi-agent-research-system
3. Dat Tran, Douwe Kiela, “Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets,” arXiv:2604.02460, April 2, 2026.
   https://arxiv.org/abs/2604.02460
4. OpenAI, “Human-in-the-loop,” OpenAI Agents SDK Documentation, accessed July 29, 2026.
   https://openai.github.io/openai-agents-python/human_in_the_loop/
5. Erik Schluntz, Barry Zhang, “Building Effective Agents,” Anthropic, December 19, 2024.
   https://www.anthropic.com/engineering/building-effective-agents
6. Mert Cemri et al., “Why Do Multi-Agent LLM Systems Fail?,” arXiv:2503.13657, March 17, 2025.
   https://arxiv.org/abs/2503.13657
7. Andrea Wynn, Harsh Satija, Gillian Hadfield, “Talk Isn’t Always Cheap: Understanding Failure Modes in Multi-Agent Debate,” arXiv:2509.05396, September 5, 2025.
   https://arxiv.org/abs/2509.05396
8. Hailey Onweller et al., “Cited but Not Verified: Parsing and Evaluating Source Attribution in LLM Deep Research Agents,” arXiv:2605.06635, May 7, 2026.
   https://arxiv.org/abs/2605.06635