何が起きたか:「毎回の修正」をシステムの学習に変える7つのループ
Search Engine Landに掲載された記事は、著者のTania Brown氏が自身のコンテンツ制作で実践している考え方から始まります。「あなたはすでに、自分のコンテンツワークフローにフィードバックを与えている。ドラフトを編集するたび、同じ不格好な移行を直すたび、曖昧な見出しを言い換えるたびに、イテレーションループが捕捉できる修正を提供しているのだ(“You’re already giving your content workflows feedback. Every time you edit a draft, fix the same awkward transition, or reword a vague heading, you’re providing corrections that an iteration loop can capture, so the next run starts closer to what you’d approve.”)」と述べています。
著者は、記事・LinkedIn投稿・動画台本・ランディングページのコピーといった複数の制作物にまたがってこれらのループを運用しているとし、「編集パターンが別々の3つの制作物で現れたとき、システムは自身の指示への更新を提案する。私はそれを承認するか、しないかだ(“When an edit pattern shows up three times across separate pieces, the system proposes an update to its instructions. I approve it, or I don’t.”)」と説明。使用ツールについては「私はClaude Codeを使っているが、これらの構造はどんなエージェントフレームワークでも機能する(“I use Claude Code, but these structures work in any agent framework.”)」と補足しており、特定のツールに依存する話ではないと位置づけています。
7つのフィードバックループ:何を計測し、何をライターに戻すか
ループ1:上流フィルターループ(The upstream filter loop)――執筆前にアイデアを「パス/修正/キル」で仕分ける
1つ目は執筆前の段階で機能するループです。記事は「大半のイテレーションは生成の後に起きる。このループは執筆が始まる前に走る(“Most iteration happens after generation. This loop runs before writing begins.”)」と説明し、その理由を「弱いアングルはパイプラインの中で最もコストの高い失敗だから(“a weak angle is the most expensive failure in the pipeline”)」としています。完成したドラフトに達するまでに、フルのパイプライン実行と自分自身のレビュー時間を費やしてから、本来はストラテジストエージェントが事前に指摘できたはずの問題に気づくことになるためです。
ストラテジストエージェントが、何も書かれる前の段階でブリーフやアングルを定義済みの基準に照らして評価し、次の3つの判定のいずれかを下します。
何を計測して何を戻すか:「Pass(合格)」はそのまま執筆・持ち込みに進む判定。「Revise(修正)」はアングルが既発表の記事に近すぎる、テーゼが広すぎて支持できない、テーマは合うが読者層が違う、論証に未収集の裏付けが必要、といった具体的な変更点がある場合の判定。「Kill(却下)」は修正では直せないアングルで、独自の視点がない、あるいはそれを支える情報源が存在しない場合に下され、エージェントは却下理由を文書化し、その根拠がログに記録されます。著者は「キルログこそがこのループが報われる場所だ。十分な回数を重ねると、個々の判定を人がレビューしなくても、どのアングルのパターンが一貫して失敗するかが見えてくる(“The kill log is where this loop pays off. After enough runs, it shows which angle patterns consistently fail without anyone reviewing individual verdicts.”)」と述べています。
ループ2:検索改善ループ(The retrieval refinement loop)――執筆前に情報源の強度を1-10で採点
2つ目は、リサーチと執筆の間にチェックポイントを設けるループです。通常のパイプラインでは、リサーチエージェントが情報源を集め、ライターがそれを使い、問題が表面化するのは最後にエディターが「情報源が支持していない主張」にフラグを立てた時点だと記事は指摘します。その時点では修正コストが高く、「エディターは根拠のない主張にフラグを立てられるが、欠けている情報源を作り出すことはできない(“An editor can flag an unsourced claim, but can’t produce the missing source.”)」ため、著者はリサーチと執筆の間にこのチェックポイントを挟んでいます。
著者自身の記事パイプラインでは、リサーチエージェントが企画済みの記事のために情報源を集めた後、ライターが動く前にマッピングエージェントがアウトラインと情報源を読み合わせ、各セクションについて「この根拠はこのセクションが主張すべき内容を裏付けているか」という1つの問いを立てます。そのうえで、各セクションのソースの強度を1-10スケールで採点し(“It scores each section’s sourcing strength on a 1-10 scale.”)、閾値を下回るセクションについては、何が不足しているかをエージェント自身が把握しているため、追加で行うべき検索クエリ自体をエージェントが書き出します。ライターが動き出すのはその後です。著者は、企画中の主張をやや裏付けきれていない情報源から書くライターは「ヘッジ(曖昧な留保表現)と一般論(“hedges and generalizations”)」を生みがちである一方、検証済みの情報源から書くライターは「具体的で反証可能な主張(“specific, defensible claims”)」を生むと違いを説明しています。
ループ3:修正上限付き品質ゲート(The quality gate with a revision cap)――2回までの往復で人に振り分ける
3つ目は、初めてループを組むならここから始めるべきだと著者が位置づけるループです。「1回書いて終わりにするとAIスロップ(AI slopquality＝質の低いAI生成コンテンツ)を生む。品質ゲートを加えるのが最もシンプルな解決策だ(“One-shotting content produces AI slop. Adding a quality gate is the simplest fix.”)」とし、同じコンテキストウィンドウで生成して終わりにする代わりに、2つ目のエージェントが定義済みの基準に照らしてドラフトをレビューし、何が問題かを分類したうえでライターに差し戻し、ライターが修正して再びレビュアーに戻す、という往復を回します。
著者はこのループを回す際、各エージェントにクリーンなコンテキストウィンドウを与え、修正回数の上限を設定しているとし、「2ラウンドを経ても通らないドラフトは、修正では直せない構造上またはソーシング上の問題を抱えている(“A draft that won’t pass after two rounds has a structural or sourcing problem that revision can’t fix.”)」と述べています。またレビュアーは1つのエージェントである必要はなく、著者自身も当初はエディターにファクトチェックまで兼務させていたが、2つの仕事を1体に持たせると「どちらも十分にできなかった(“combining the two jobs meant neither got done well”)」ため、専任のファクトチェッカーを独立したクリーンなコンテキストウィンドウで走らせ、ドラフトと引用元の情報源すべてを受け取り、リンクが存在するというだけでなく、ドラフトが情報源の内容を正確に描写しているかを1件ずつ確認する体制に分割したといいます。
何を計測して何を戻すか:判定は3種類。「Pass(合格)」はすべての主張に出典があり、ボイスガイドに沿い、構成が論旨に資する場合。「Flag(要修正)」は未定義の用語、弱い書き出し、より強い出典が必要な主張など、直せる問題がある場合。「Escalate(エスカレーション)」はアングルが薄い、リサーチが欠けているなど、修正では直せない問題がある場合で、修正上限に達したものはループを続けさせず人間に振り分けます。ゲートが機能するようになったら、同僚のドラフトをワークフロー全体に通さずレビュアーへ直接投入できる「再入場ポイント」を明示的に加えるとよいとしています。
ループ4:ルーブリックベースのスコアリングとアンサンブル選定(Rubric-based scoring and ensemble selection)――「なぜ落ちたか」を数値で戻す
4つ目は、品質ゲートが「合否」しか教えないのに対し、「なぜ落ちたか、何を直せば通るか」を教えるスコアリングループです。まず、作成するコンテンツの種類と目的に応じたルーブリック(評価基準表)を用意します。著者は例として、自身のLinkedIn投稿用ルーブリックが「具体性と具象性、独自の視点、単一の明確な洞察、すべての行が紋切り型を避けているか」を含む10の基準でスコアリングしていると明かしています(“my LinkedIn post rubric scores 10 criteria, including specificity and concreteness, original point of view, a single clear insight, and whether every line avoids platitudes.”)。また、応募要項をもとにアワード応募書類の分析にもルーブリックを組み込んでおり、複数の応募案を比較し、それぞれで何を強化すべきかを的確に示す点で最も役立っているといいます。
何を計測して何を戻すか:1-10のような定義済みスケールで各基準に対する出力をスコアリングし、閾値を下回る基準ごとに、スコアリングエージェントに曖昧な判断ではなく具体的な診断を出させ、その情報をライターエージェントに戻して修正させます。ここにも修正上限を設け、「2回の書き直しを経てもギャップが埋まらない基準は、アングルかリサーチそのものに問題がある。2回の修正サイクル後も具体性が6点で頭打ちのドラフトは、原資料に存在しない何かが欠けている。再スコアリングしても助けにはならない(“A draft stuck at a six on specificity after two revision cycles is missing something that doesn’t exist in the source material. Scoring it again won’t help.”)」と述べています。ルーブリックは、異なる切り口で複数バージョンを生成し、それらをルーブリックを指針とするジャッジエージェントに比較させる用途にも使えるとしています。
ループ5:対抗的チャレンジループ(The adversarial challenge loop)――最強の反論をぶつけてから公開する
5つ目は、対抗的(アドバーサリアル)なエージェントが「そのコンテンツに対する最強の反論」を構築するループです。ドラフトが完成した後、対抗的エージェントがテーゼ・根拠・それらをつなぐ論理を攻撃し、根拠を伴って支持できる反論をすべて出力します。著者は「求めているのは『この主張には出典がない』ではない。求めているのは『これが最強の反論であり、これがその根拠であり、ここであなたの論理が成立していない』だ(“You’re not asking for ‘this claim is unsourced.’ You’re asking for ‘here is the strongest counterargument, here is the evidence for it, and here is where your logic doesn’t hold.'”)」と説明しています。
その出力はライターエージェントに共有され、ライターは各反論に答える義務を負います。記事を強化するか、あるいはその反論が論旨を変えない理由を文書化するかのいずれかです。著者は、このループは「論証そのものが商品である」オピニオン記事や思想的リーダーシップ(ソートリーダーシップ)の記事で最も効果を発揮するとし、自分自身の署名記事には他の誰かが読む前にこのループをかけているといいます。一方、ハウツーやエクスプレイナー(解説記事)には挑戦すべきテーゼがないため、品質ゲートのみで十分だとしています。
ループ6:差分学習ループ(The diff-and-learn loop)――公開版と凍結版を突き合わせ、3回以上の同一修正でルール化
6つ目は、個々の記事ではなくパイプライン自体を改善するループです。著者自身の記事生成システムがこのループを回しており、ドラフトが著者の手元に届くまでにリサーチャー・アウトライナー・ライター・複数のエディター・ファクトチェッカーを経ています。ワークフローはその後、凍結したまま保持するMarkdown版と、著者が編集してWordPressにアップロードするDOCX版の2つのファイルを保存します。記事が公開されると、差分エージェントが凍結版と実際に公開した内容を行単位で比較します。
このループを機能させるには、レビュー前にパイプラインの出力を凍結し、そのファイルには一切手を加えないこと、編集は作業用コピーの側で行うことが条件になります。凍結版がなければ、システムが何を生成したかの記録が残らず、編集内容と比較する対象もなくなるためです。
何を計測して何を戻すか:編集が終わると、差分エージェントはすべての差分を「言語の簡潔化」「トーンの変化」「構成の並べ替え」「事実関係の修正」「見出しの書き直し」の各カテゴリーに分類し、カテゴリーごとに件数をカウントします。あるカテゴリーが閾値に達すると――著者の場合は「1つの記事内で、または複数の記事にまたがって、同種の修正が3回以上(“for me, three or more similar fixes on one piece or across several”)――ループはそのパイプライン段階の担当箇所の指示を更新する提案を出します。著者はこの提案を承認するか却下するかを判断し、承認したルールは以降自動的に適用されます。著者は「システムが自分より先に見つけた修正ルールを承認する瞬間は、これらのループの中で間違いなく一番好きな瞬間だ(“Approving a rule the system caught before I did is easily my favorite moment in any of these loops.”)」と述べています。
このループを機能させる歯止めは2つあるとされます。1つ目は、提案されたすべてのルールを人間が承認すること。ある記事で1つの統計を、その論旨に合わないという理由だけで削った場合、承認ステップがなければシステムはその1回限りの編集を「統計を避ける」といった恒常ルールに変え、以降すべてに適用してしまう恐れがあるためです。2つ目は、差分結果の恒常的な保管場所を持つこと。毎回の記事でリセットされてしまうと、同じ修正が4本の異なる記事にまたがって現れたことにループが気づけず、その蓄積こそがこのループの意義そのものだからです。この保管場所はスプレッドシート、JSONファイル、Markdownログのいずれでもよく、重要なのは単一のセッションの外に存在し、記事をまたいで保持され続けることだとしています。
ループ7:パフォーマンスフィードバックループ(The performance-feedback loop)――公開後の検索データを次のブリーフに戻す
7つ目は、公開後の検索パフォーマンスを次のブリーフ作成に生かすループです。記事は「大半のチームはその評決(検索パフォーマンス)を報告のためだけに集めて終わる。このループはそれを実際に働かせる。検索が公開済みの記事について教えてくれることが、次に書くブリーフを変えるべきだ(“Most teams collect that verdict for reporting and stop. This loop puts it to work: What search tells you about published pieces should change the briefs you write next.”)」と説明しています。
何を計測して何を戻すか:週次でパフォーマンスシグナルを取得し、良い方にも悪い方にも動いている記事にフラグを立てる、スケジュール化されたルーティンまたはエージェントを設定します。シグナルは「順位、クリック率、インプレッション、トラフィックで、Semrush MCPまたはAPI経由、あるいはBigQueryコネクタ経由のGoogle Search Consoleから取得(“Rankings, click-through rate, impressions, and traffic, pulled through the Semrush MCP or API, or from Google Search Console via a BigQuery connector.”)」するとされ、頻度は「週次、変化に対応する時間がまだあるうちに動きを捉えるため(“Weekly, so you catch movement while there’s still time to respond.”)」。フラグを立てる対象は、自社の類似コンテンツを下回っている記事、想定していた順位が実現しなかった記事、以前保持していた順位を失った記事、そして期待を上回っている記事で、勝ち記事も負け記事と同じくらい重要だとし、それは「どの意思決定を繰り返すべきかを示してくれるから(“they show you which decisions to repeat”)」としています。
記事は「1本の記事が社内のすべてのゲートを通過しても、検索では失敗しうる(“A piece can pass every internal gate and still fail in search.”)」と指摘し、フラグが立った記事ごとに、元のブリーフとパフォーマンスデータをエージェントに渡し、「このパフォーマンスを踏まえると、このブリーフの何を変えるか」という1つの問いに答えさせます。類似記事は順位を取れているのに、ある記事だけ一度も順位を取れなかった場合は多くの場合アングルの問題であり、「新たに言うべきことが何もない会話に入り込んでしまった(“It entered a conversation where you had nothing new to say.”)」ケースだとしています。狙っていなかったクエリで順位を取った記事は、ブリーフが想定していたのとは別の問いに答えてしまったケースだとしています。
ここで著者は注意点として、「クリック率の低下だけを失敗と読むべきではない。AIによる回答が検索全体でクリック率を押し下げているため、前年のベンチマークではなく、自社の類似コンテンツと比較すべきだ(“Don’t read a falling click-through rate alone as failure. AI answers have pushed click-through rates down across search, so compare each piece against your own similar content, not last year’s benchmarks.”)」と述べ、そのうえで学びを恒常化するために、ストラテジストエージェントの評価基準とキルログにその教訓を加え、次のブリーフが今回の記事から学んだすべてを踏まえて始まるようにすべきだとしています。
なぜ重要か・SEO/コンテンツ制作実務への影響
この記事が示す7つのループに共通するのは、「人間が毎回同じ修正を繰り返す」という状態そのものを、システムが検知して改善提案に変える仕組みだという点です。著者は記事の締めくくりで「自分が同じ修正を繰り返していることに気づいたところから、大半のループが生まれた。あるとき、なぜシステムがそれを捕捉しないのかを自問するようになった。その問いこそが、次に構築すべきループのブリーフになることが多い(“I created most of my loops because I found myself making the same corrections. At some point, I started asking why the system wasn’t catching them. That question is usually the brief for the next loop to build.”)」と述べています。
AIを使ったコンテンツ制作パイプラインを運用する日本のチームにとっても、この7つの型は「どの工程で」「何を基準に」「誰(どのエージェント)が判定し」「結果をどこに戻すか」を切り分けて設計する際の具体的な参照点になります。特にループ3(修正上限付き品質ゲート)は、著者自身が「初めて構築するならここから(“start with the quality gate”)」と位置づけているとおり、既にAIでドラフトを生成しているが人手でのチェックが属人化しているチームにとって着手しやすい起点だといえます。またループ6(差分学習ループ)と7(パフォーマンスフィードバックループ)は、公開後のデータをパイプラインの指示改善に戻す仕組みであり、日本語コンテンツでも「編集で毎回同じ直しが入る」「順位が想定どおりに出ない」といった課題を抱えるチームであれば、同じ考え方(閾値を決めて人間が承認したうえでルール化する)をそのまま応用できる設計です。
所感
Scale Basics編集部としては、この記事の核心は個々のループの技術的な仕組みよりも、「同じ修正を3回以上繰り返したらルール化候補にする」「最終判断は必ず人間が承認する」という2つの原則にあると考えています。AIによるコンテンツ生成が一発勝負(記事の言う「One-shotting」)になっているチームほど、まず着手すべきはループ3の品質ゲートであり、そこに修正回数の上限と、上限に達した場合の人間へのエスカレーション経路を必ずセットで組み込むことが重要だという点は、自社のワークフローを見直すうえでも参考になります。
特に日本のコンテンツチームにとって示唆的なのは、ループ6の「差分の恒常的な記録」という発想です。編集者が毎回同じ指摘をしていても、その記録がその場限りで消えてしまえば、パターンとして蓄積されず、いつまでも同じ修正を繰り返すことになります。スプレッドシートやMarkdownログでよいので、記事・ライターをまたいで修正パターンを蓄積する仕組みを持つこと自体が、AI活用の成熟度を上げる第一歩になるといえるでしょう。また、ループ7が指摘する「クリック率の低下を単純に失敗と見なさない」という注意点も、AI Overviewsの拡大が進む現状では日本語検索でも当てはまりうる視点であり、自社の類似記事同士で比較するという基準の立て方は実務にそのまま取り入れられます。
まとめ
・Search Engine Land(Tania Brown氏、2026年7月27日付)が、AIコンテンツ制作を自己改善させる7つのフィードバックループを解説する記事を公開した
・7つは、上流フィルターループ(Pass/Revise/Kill判定)、検索改善ループ(情報源を1-10スケールで採点)、修正上限付き品質ゲート(Pass/Flag/Escalate判定)、ルーブリックベースのスコアリング(LinkedIn投稿では10基準)、対抗的チャレンジループ、差分学習ループ(同種の修正が3回以上でルール化提案)、パフォーマンスフィードバックループ(週次で順位・クリック率・インプレッション・トラフィックを監視)である
・差分学習ループとパフォーマンスフィードバックループは、いずれも「人間の承認」を経てはじめてルール化・ブリーフ更新につながる設計になっている点が共通する
・著者は特定ツールへの依存を否定しており(自身はClaude Codeを使用)、これらの構造はどのエージェントフレームワークでも機能するとしている
・記事は、クリック率の低下を単純に失敗と見なさず、AI回答による検索全体の傾向を踏まえて自社の類似コンテンツと比較すべきだと注意を促している
よくある質問
Q1: この記事が紹介する「7つのフィードバックループ」とは、それぞれ何ですか?
上流フィルターループ(The upstream filter loop)、検索改善ループ(The retrieval refinement loop)、修正上限付き品質ゲート(The quality gate with a revision cap)、ルーブリックベースのスコアリングとアンサンブル選定(Rubric-based scoring and ensemble selection)、対抗的チャレンジループ(The adversarial challenge loop)、差分学習ループ(The diff-and-learn loop)、パフォーマンスフィードバックループ(The performance-feedback loop)の7つです。ブリーフ作成前の段階から公開後の検索パフォーマンス計測まで、パイプラインの各段階に対応しています。
Q2: 差分学習ループ(The diff-and-learn loop)は、具体的にどのように「学習」しますか?
公開前に凍結したパイプライン出力と、実際に公開した編集済みバージョンを行単位で比較し、差分を言語の簡潔化・トーンの変化・構成の並べ替え・事実関係の修正・見出しの書き直しといったカテゴリーに分類してカウントします。著者の場合、同種の修正が1本の記事内、または複数の記事にまたがって3回以上現れると、該当するパイプライン段階の指示を更新する提案が出され、人間が承認した場合のみ以降のルールとして自動適用されます。
Q3: パフォーマンスフィードバックループ(The performance-feedback loop)では、何を、どのくらいの頻度で確認すればよいですか?
記事によれば、Semrush MCPやAPI経由、またはBigQueryコネクタ経由のGoogle Search Consoleから、順位・クリック率・インプレッション・トラフィックのシグナルを週次で取得し、自社の類似コンテンツを下回っている記事や、想定した順位が出なかった記事、逆に期待を上回っている記事にフラグを立てます。フラグが立った記事については、元のブリーフとパフォーマンスデータをもとに、ブリーフの何を変えるべきかをエージェントに検討させ、その学びをストラテジストエージェントの評価基準に反映させます。
出典:7 feedback loops for self-improving AI content workflows(Search Engine Land、Tania Brown氏、2026年7月27日)https://searchengineland.com/self-improving-ai-content-workflows-483404
