【非エンジニアのためのClaude/Claude Codeシリーズ】ループエンジニアリングを営業の仕事に持ち込んだ ── 私は初稿を読む人をやめた

こんにちは。アカウント営業部でマネージャーをしている福島です。エンジニアではありません。メンバー6名のチームで、自分でも案件を持ちながらマネジメントをしています。

このシリーズでは、営業ツールをClaude Codeにつないだ話（MCP連携編）、公式スキルを使わずに自分の業務向けの指示書を育てた話、effortという設定の話を書いてきました。

今回は、英語圏で出てきた ループエンジニアリングという考え方を読んで、それを営業の自分の仕事に持ち込んだ話です。エンジニア向けに書かれたものなので、そのまま持ってこられた部分と、持ってこられなかった部分がありました。

いちばん変わったのは、道具ではなく私の仕事のやり方でした。私はもう、AIが最初に書いたものを読んでいません。 何周か回ったあとのものを読んでいます。

そこに至るまでに、6つある構成要素のうち2つは、そのままの形では持ち込めませんでした。 ひとつは使わずに済み、もうひとつは使い方を変えました。そのあたりも、試した順番のまま書きます。

ループエンジニアリングという言葉

2026年6月、Addy Osmani 氏が「Loop Engineering: Designing loops that prompt coding agents」という記事を出しました（本人のブログ／ニュースレター・6月8日／O'Reilly Radar に転載・6月22日）。Googleで14年以上にわたって開発者向けの領域を率い、直近はGoogle Cloud AIのDirectorを務めた方です。この呼び方を記事としてまとめた、代表的な一次資料にあたります。

定義は本人の言葉がいちばん短い。

ループエンジニアリングとは、エージェントにプロンプトを打つ「自分」を置き換えることである。代わりに、それをやる仕組みのほうを設計する。

もうひとつ、本人はこう補足しています。「ここで言うループとは、目的を定義したらAIが完了まで反復する、再帰的なゴールと考えればいい」。

Osmani氏はこの記事で2人の発言を引いています（以下はいずれもOsmani氏の記事内での引用です）。Peter Steinberger 氏の「もうコーディングエージェントにプロンプトを打つべきではない。エージェントにプロンプトを打つループのほうを設計すべきだ」と、AnthropicでClaude Codeを率いる Boris Cherny 氏の「私はもうClaudeにプロンプトを打っていない。Claudeにプロンプトを打って何をすべきか考えるループを走らせている」。

読んだとき、これは営業の仕事にも効くと思いました。私の1日は、繰り返しでできています。 朝の予定の組み立て、訪問前の調査、議事録の整理、案件の棚卸し。毎回内容は違うけれど、やる手順はほぼ同じです。だったら手順のほうを仕組みにできるはずだ、と。

ひとつ注意です。日本語の解説記事も増えていますが、私が最初に読んだものは英語の原典に一切触れずに書かれていて、危うく「日本語圏で生まれた新語」と勘違いするところでした。使うときは出典を確かめたほうがいいです。

原典の5要素を、営業の仕事に落とす

Osmani氏は、ループの構成要素を5つ挙げています（＋もうひとつ）。エンジニア向けの言葉なので、営業の私の仕事に置き換えながら作りました。

先に全体像を出します。私の1日は、いまこうなっています。

営業の1日をループにした状態。オレンジがループの外にいる私、青がClaudeが回す部分、緑が実行と実行のあいだを生き延びる記憶、赤が外に出る手前の停止線です。番号は原典の構成要素に対応しています。

※本記事用に作成した模式図です。実際の画面・顧客名・案件名は含みません。

以下、番号ごとに何を作ったかを書きます。

① Automations（自動実行）— 仕事を見つけて仕分ける定時処理
ここから作りました。平日の朝6時30分に、クラウド側で処理が自動で走ります。カレンダー、メール、チームのチャンネル、タスク、進行中案件の状態を読んで、「今日はこれが山場」という1日のストーリーを1枚のファイルに書き出す。私が起きる前に終わっています。夕方18時30分にもう一度走り、その日の議事録を顧客ごとのカルテに反映して、完了したタスクを掃除します。

私が打つ言葉は「おはよう」と「おつかれ」の2語だけになりました。

② Worktrees（作業の隔離）— 並行作業がぶつからないようにする
これは作りませんでした。 コードを並行で書くための仕組みなので、営業の私の仕事にはそのまま持ってくる相手がいません。5つ全部を埋めなくても回っています。 エンジニア向けの枠組みを非エンジニアが読むときは、ここで無理をしないほうがいいと思います。

③ Skills（スキル）— 仕事の型を書き出して再利用する
訪問前の調査、週次報告、請求の照会。繰り返す仕事をスキルとして書き出しました。これは前々回の記事で書いたとおりです。

④ Plugins and Connectors（外部ツール接続）— 実際の道具につなぐ
顧客管理システム、メール、チャット、ドライブ、カレンダー。MCP連携編の話です。

＋ State / Memory（外部の記憶）— 実行と実行のあいだを生き延びる状態
顧客ごとのフォルダとカルテ、それとは別に「私がどう動くか」を1ファイル1事実で書いたメモリ。次の日のセッションは、記憶を読んだ状態から始まります。ここが無いと、毎朝ゼロから説明し直すことになります。

⑤ Sub-agents（別エージェントによる検証）— 作った本人に自分の仕事を採点させない
順番を変えて最後に置きました。ここだけ、書いてあるとおりの形にはなりませんでした。 立てる場所を何度か変えて、いまの形に落ち着いています。次はその話です。

いちばん効いたのは「止め方」だった

やってみて分かったのは、ループを作るときにいちばん難しいのは、回し始めることではなく止め方を決めることです。

自動で走る処理には、外部システムへ書き込ませていません。読むだけです。メールもチャットも顧客管理システムも、Claudeは読むが書かない。Claudeが書いていいのは、自分のファイルと予定表だけ、と決めています。

これは慎重さの話ではなく、ループの設計そのものです。人間がループの外に出るということは、中で起きることを一件ずつ見ないということでもある。見ないものが外に出ていくと事故になるので、外に出る手前で必ず止まるように作ってあります。下書きまでは自動で作る、送るのは自分。ここは今後も変えないつもりです。

これは原典も釘を刺している点でした。Osmani氏は、ループを回しても検証と理解の維持はエンジニアの責任として残るとし、それを手放すことを「cognitive surrender（認知の明け渡し）」と呼んで警告しています。回す仕組みを作ることと、中身を分からなくなることは別だ、ということだと理解しました。

別のAIを立てる前に、一度試してみた

⑤ Sub-agents に取りかかります。原典はこう書いています。

コードを書いたモデルは、自分の宿題を採点するには優しすぎる。指示を変えた第2のエージェントが、最初のエージェントが自分を納得させて通してしまったものを捕まえる。

ここは読み違えないほうがいいところでした。原典が言っているのは「指示を分けた第2のエージェントを置け」であって、別のモデルを使えとは書いていません（モデルを替えるのは任意、という書き方です）。

ただ私は、読んだ当初これを「別のAIを使え」と受け取りました。自分の実感とも合っていたからです。

「自分に書かせた文章を、同じAIにレビューさせても甘いはずだ」

書いた本人なんだから、自分の文章を厳しくは見られない。私の環境にはOpenAIの Codex もつないであるので、これを第二の脳として使えばいい、と考えました。

もっともらしい。ですが、私は確かめていませんでした。

ここで扱うのは文章です。コードではありません。コードなら、テストが通るか通らないかで検証できます。文章にはそれがない。 同じ話として扱っていいのかを含めて、作る前に試してみました。

やったこと

Claudeに、社内向けの提案文書を1本書かせます（テーマは「週次営業会議の再設計」。実在の資料ではなく、この検証のために書かせたものです）。それを3通りにレビューさせて、指摘を数えました。観点は毎回同じで、目的が冒頭で伝わるか／能動態で主語が明確か／結論ファーストか／数字と根拠があるかの4つと、文書全体の構造です。

本命は③です。自分が書いた文章を、自分でレビューさせたらどうなるか。

結果

手加減は、しませんでした。

③のClaudeは、自分が書いたばかりの文書に対してこう言いました。読み手に何を判断してほしいのかが最終行まで出てこない。課題がすべて印象論で数字がひとつもない。前提とリスクの記述が丸ごと抜けている。効果を測る計測を「第1週」に置いているが順序が逆で、書く前に測るべきだ。

極めつけは、自分で文末に付けた注記に対して「社内提出物としてはノイズになる」と切ったことでした。

私の仮説は外れました。同じAIでも、自分の書いたものをちゃんと批判します。

では、別のAIを使う意味はあったのか

①と②を比べます。同じ文書を、Codexと（別セッションの）Claudeに読ませた結果です。

Codexの指摘8件のうち、7件はClaudeも指摘していました。 ほぼ重複です。

• Codexだけが拾ったもの：1件。タイトルが「〜について」になっていて、報告なのか承認依頼なのか判別できない、という指摘。文書の外形の話です。
• Claudeだけが拾ったもの：3件。読み手が必ず返してくる反論への備えがない（他人の案件を聞く時間は若手の学習機会だったのでは、案件の選定はマネージャーの工数を増やすのでは）、課題と提案の対応関係が読み手に追えない、効果の並び順が課題の優先順位と逆になっている。文書の中身の話です。

差は「厳しさ」ではなく、着眼点の種類でした。Codexは短く外形と体裁を突き、Claudeは長く論理と中身を突く。

このときは「粗い初稿なら、どちらに読ませても似たようなことを言うんだな」というくらいの感想でした。この感想は、あとでひっくり返ります。

なお、この比較には不公平があります。Claude側には私の指示書が読み込まれていて、Codexには何の文脈も渡していません。条件を揃えれば結果は動くかもしれません。ここを「地力の差」として書くつもりはありません。

学術のほうはどう言っているか

調べたら、自己批評については否定的な報告もありました。GPT-4は自分の誤りを自分で検知できず、自己批評を回すと正解を誤答に書き換えることすらある、という研究です（GPT-4 Doesn't Know It's Wrong）。

一方で、初稿を出させ、同じモデルに批評させ、その批評を渡して改稿させる Self-Refine という枠組みもあり、こちらは同一モデルで回すことが前提です。

矛盾しているようですが、たぶん扱う対象が違います。正解が一意に決まる推論問題では自己批評が効きにくく、文章の構成レビューのように「正解はないが良し悪しはある」領域では機能する。 今回の結果はこの整理と噛み合います。

では、何周回せばいいのか

ここまでは1周目の話です。ループを名乗る以上、回し続けたらどうなるかを確かめないと片手落ちなので、レビュー→改稿→再レビューを3周回しました。

私の予想は「2周目で指摘が半分になり、3周目で好みの問題しか出なくなる」でした。これも外れました。

減りません。 理由は3つありました。

理由1：改稿が新しい欠陥を作る
2周目の指摘のうち2件は、1周目の修正によって新しく生まれたものでした。文書の構造を整理するために「複雑化」「問い」という見出しを立てたら、2周目に「それは書き手が構成を考えるための言葉であって、読み手に見せるラベルではない」と叩かれた。承認を求める期間の書き方を直したら、後半の日程表と食い違いが生じた。直すたびに、直した場所の周辺が新しく壊れます。

理由2：指摘の粒度が下がっていく
1周目は「依頼事項が最終行まで出てこない」「前提とリスクが丸ごとない」という構造の話でした。2周目は評価指標の設計の話になり、3周目は「アラートの定義がない」「宛先が書かれていない」という文面の話になっていく。論点が上から下へ降りていきます。

理由3：ループは振動する
これがいちばん厄介でした。2周目が「承認を2段階に分けて、まず計測だけ承認を求めるべきだ」と指摘したので、そのとおり直しました。すると3周目が「今回求めているのは計測してよいかだけで、承認者からすれば承認するまでもない内容になっている」と、前の周の修正そのものを否定してきました。

これは先ほどの研究が警告していたことと同じです。自己批評を回し続けると、直したものを戻す方向にも動きます。

そして、3周とも消えなかった指摘がひとつあります。受動態と主語の曖昧さです。1周目で指摘し、2周目でも指摘し、3周目でもまだ指摘されている。改稿のたびに直しているのに、書き直すと別の場所でまた出る。これはもう癖なのだと思います。人間と同じです。

止め時は、AI自身が言ってきた

では何を見て止めるのか。答えは3周目のレビューの最後の1行にありました。

1〜3は本文の構造・指標設計に関わるので直す価値があります。4〜8は文面の調整で、ここまで来ると読み手の判断は変わりません。次の改訂で1〜3を反映したら、いったん止めて誰か1人にレビューしてもらう段階だと考えます。

止める基準は指摘の数ではなく、指摘の粒度でした。「これを直すと読み手の判断が変わるか」で見て、変わらない指摘しか出なくなったら終わり。数を数えていたら永遠に終わりません。

ついでに、AIのほうから「人に見せろ」と言ってきたのが良かったです。ループの終点は完成ではなく、人間に戻すことだという設計になっていました。

回したあとに、別のAIを当ててみた

最初にCodexを当てたのは、粗い初稿でした。そのときは重複ばかりだったので、正直あまりピンときていませんでした。

3周回したあとの原稿に、もう一度当ててみました。13件出ました。 そして中身が、初稿のときとは違っていました。

出てきたのは、Claudeが3周のあいだに自分で足した記述どうしの食い違いです。

• 2周目で「更新されていない案件は議題として扱わない」というルールを足し、同じ2周目で「課長が停滞している案件を拾い上げる」とも書いていた。この2つは噛み合っていません。
• 「その場で決着させる」と書いた一方で、条件つきで持ち帰りも認めていた
• 3周目で宛先を部長にしたのに、判断する人も実行する人も課長のままだった

どれも、Claudeが自分で書いて、自分で3周読んで、3周とも素通りしたものです。

私なりの理解はこうです。初稿には、誰が読んでも分かる大きな穴が空いています。 だから誰に読ませても同じことを言う。ループを回すとその穴は埋まりますが、代わりに自分が各周で足したものどうしのつじつまが合わなくなっていく。そこは、足した本人には見えにくいのだと思います。

なので私は、回したあとに一度だけ別のAIを通す、という使い方をしています。毎回ではありません。初稿の段階でやったときは、あまり手応えがありませんでした。

ひとつ正直に書いておくと、この比較には対照が足りていません。 3周後の原稿に当てたのはCodexだけで、同じ原稿を新しいClaudeのセッションに読ませていません。 なので今回出てきたものが「別のモデルだから」なのか「その原稿を初めて読む相手だから」なのかは、切り分けられていません。

原典が「指示を分けた第2のエージェント」と書いていて、モデルの入れ替えを必須にしていないことを踏まえると、後者の可能性はそれなりにあると思っています。ここは試せていません。

私自身の立ち位置が変わった

ここまでは仕組みの話でした。最後に、自分の仕事のやり方がどう変わったかを書きます。ここがいちばん大きい変化でした。

ループを作る前、私は出てきたものを端から端まで、100%自分でレビューしていました。 AIに何かを書かせたら、全文を頭から読んで、直すべきところを全部自分で見つける。当然ですが、これをやっていると自分が読める量が上限になります。

いまは、ループを回してから見ています。 書かせて、観点を渡して読ませて、直させて、それから私が読む。

体感として、上がってくるものの質は上がり、私が直す箇所は減りました。

ただし、ここは正直に書きます。これは実感であって、計測した数字ではありません。 しかもこの間にモデル自体が進化しています。 私が直す箇所が減ったのは、ループを挟んだからなのか、単にモデルが賢くなったからなのか、私には切り分けられません。

それでも、ひとつだけ確かなことがあります。私が読み始める位置が、後ろにずれました。 昔は初稿を読んでいた。いまは、何周か回ったものを読んでいる。同じ時間で見られる量が増えたのは、たぶんこれが理由です。

これは、まさに原典が言っていたことでした。ループエンジニアリングとは、プロンプトを打つ自分を置き換えることです。私の場合は、置き換わったのがレビューする自分の立ち位置でした。全数を見る役から降りて、回ったあとを見る役に移った。

なくなったわけではありません。最後は必ず私が読みます。 顧客に出るものであればなおさらです。Osmani氏の言う「認知の明け渡し」をしないための線は、そこに引いています。

コーディングの話を、営業の成果物に移せるか

ループエンジニアリングは、ほぼコーディングの文脈で語られています。 原典もコーディングエージェントの話ですし、構成要素にも作業ツリーの隔離のような、コードを書く前提のものが入っています。日本語の解説記事も同じです。

それでも私は、営業の成果物レビューでも使えると感じています。提案文書、報告書、メール、議事録。営業が作るものはほとんどが文章で、しかも繰り返し同じ型のものを作ります。 ループが噛み合う条件は揃っています。

やってみて、移せたものと移せなかったものがはっきり分かれました。

そのまま移せたもの：自動実行、スキル、外部ツール接続、外部の記憶。そしてループを回してから人が見るという順番そのもの。ここは何の翻訳もなく効きました。

移せなかったもの：作業ツリーの隔離。前述のとおり捨てました。

置き換えが必要だったもの：検証です。ここが一番大事でした。

コーディングには、テストがあります。 通るか通らないかを機械的に判定できる仕掛けが、ひとまず手元にある（もちろん、テストが通ることとコードが正しいことは同じではありません。原典も「完了とは主張であって証明ではない」と釘を刺しています）。営業の文章には、その手前の仕掛けすらありません。 「この提案文書は正しい」を機械的に判定する方法は無いからです。

だから最初、私は「別のAIに読ませる」ことでその穴を埋めようとしました。粗い初稿では、それだけでは足りませんでした。

先に判定装置になったのは、観点でした。目的が冒頭で伝わるか、主語は明確か、結論は先か、数字はあるか。これを渡したときは、AIが自分の文章を9件叩きました。（観点を渡さない条件は今回の検証では試していないので、「渡さないとどうなるか」のほうは私の普段の印象です。）

つまり私の場合、コードにおけるテストに当たるものが、文章では観点だった。 最初に必要だったのは、モデルを増やすことではなく、何をもって良しとするかを言語化することでした。別のAIは、その観点で何周か回したあとに効いてきます。

営業の仕事でこれをやるなら、自分の商売で「良い文書」とは何かを、先に4つか5つの箇条書きにするところから始めることになります。私は文章の作法を学ぶ社内の研修で使った観点をそのまま流用しましたが、提案書には提案書の、メールにはメールの観点があるはずです。そこが自分の資産で、ループはそれを回す装置にすぎません。

ひとつ断っておくと、これは1人が1種類の文書で試した結果です。 提案文書以外、たとえば議事録や見積の説明文で同じことが言えるかは、まだ確かめていません。

まとめ

• ループエンジニアリングは、プロンプトを打つ技術ではなく、プロンプトを打つ自分のほうを仕組みに置き換える考え方。2026年6月、Addy Osmani氏の記事が出所です
• 要素は5つ＋記憶（自動実行・作業の隔離・スキル・外部ツール接続・別エージェントによる検証・外部の記憶）。エンジニア向けの枠組みなので、非エンジニアが全部埋める必要はありません。私は作業の隔離を捨てました
• 別のAIによる検証は、当てる場所を変えました。 粗い初稿に当てても重複ばかりでしたが、3周回したあとに当てたら、Claudeが自分で足した記述どうしの食い違いが出てきました。いまは回したあとに一度通しています
• 作るときにいちばん難しいのは止め方。人間がループの外に出るなら、外に出ていく手前で必ず止まる設計が要ります
• 「自分の文章を自分でレビューさせても甘い」は、私が試した範囲では起きませんでした。ただし観点を渡したときの話です
• 原典が言っているのは「指示を分けた第2のエージェント」で、別のモデルを使えとは書かれていません。私は最初これを読み違えていました
• 回しても指摘は減りませんでした（9→9→8）。改稿が新しい欠陥を作り、論点は下に降りていき、前の周の修正を次の周が否定します
• だから止める基準は指摘の数ではなく粒度。「直すと読み手の判断が変わるか」で見て、変わらないものしか出なくなったら止めて、人に見せる
• いちばん変わったのは私が読み始める位置。初稿を全数レビューする役から、回ったあとを読む役に移りました。ただし質が上がった実感は計測しておらず、モデルの進化と切り分けられていません
• それでも最後は必ず自分が読みます。特に顧客に出るものは

ひとつ思ったのは、思い込みを確かめるのは、思ったより安かったということです。「別のAIを立てるべきか」を確かめるのに使ったのは、原稿1本と数回のやりとりでした。仕組みを組んでから半年運用して気づくより、先に1回試すほうが早い。回す仕組みを作る前に、その仕組みが要るかどうかを回して確かめる、という順番だったように思います。

同じシリーズの他の記事もよろしければどうぞ。

• MCP連携編
• 公式スキルを使わずに自分の指示書を育てた話
• effortは「賢さ」ではなく「仕事量」のつまみだった