AI 量産ブログを約 1 週間で全撤退した話 — 検出・診断・緊急対応の全タイムライン

本記事に登場する HUMAN_INPUT マーカーとは、AI 執筆 skill が記事本文に残す「ここは人間が後で確定値を埋めるべき」を示すプレースホルダー（形式例: ）。

2026 年 5 月 8 日、八雲は AI 支援で書いた 48 本の記事（magazine 47 本 + editor-note 1 本）を一斉に公開した。10 日後の 2026 年 5 月 18 日、全 48 本を取り下げた。品質監査で fail 11 本、HUMAN_INPUT マーカー残存 4 記事、内部リンク 76 本が 100% 死亡、featured に選んでいた記事は 3 本中 3 本が品質基準を満たしていなかった。Google のクロールが本格的に始まる前に間に合った。

このドキュメントは、その全工程の記録である。同じことをやる前に読んでほしい。やった後に読んでいるなら、ここに書かれている手順がそのまま使える。

Executive Summary — 3 つの結論

結論を先に示す。

AI で 48 本を約 1 週間で量産して一括公開した結果、品質監査で fail 11 本を検出。HUMAN_INPUT マーカー漏出・内部リンク 100% 死滅という構造的欠陥が重なった。Google がインデックスを始める前に全撤退を決断し、同日内に実施した。撤退後に行ったのは「隠す」ではなく「仕組み化して開示する」という選択だった。

Key Takeaway:

量産できることは前提、量産後の設計こそが本質 — AI で記事を大量に出す能力は差別化要因ではなくなった。検知・撤退・rebuild の運用設計を持つかどうかが、owned media の持続可能性を分ける。
機械が検出できる失敗は機械に止めさせる — HUMAN_INPUT 漏出・内部リンク死滅・タグ揺れは、すべてスクリプトで検出できる失敗だった。これらを人間の目視レビューに任せていたことが今回の失敗の本質的な原因だ。公開前 Gate を実装すれば次回は機械が止める。
失敗を隠さず仕組み化することが E-E-A-T 戦略になる — 「1 日 37 本公開・内部リンク 76 本死亡・HUMAN_INPUT 4 記事漏出」という数字付きの失敗開示は、実際に経験した組織にしか書けない一次情報だ。AI 検索が citation するのはこの種の具体性のある記録であって、一般論の解説ではない。

技術的な実装詳細（middleware code / Python script / curl 検証）は記事末尾の #tech-detail にまとめている。経営判断と運用設計の論点を先に読みたい方はそのまま続けてほしい。

フェーズ 1 — 何が壊れていたか（5 軸スコアリングで見つかった失敗）

公開から 10 日経った時点で、記事の質感に違和感があった。AI が書いた文章として整っているのか、品質的に公開水準を満たしているのか——個別に読んで感覚で判断するのではなく、全 48 本を機械的に採点する経営判断に切り替えた。主観的なレビューでは見つからない構造的欠陥を、測定可能な形で可視化する必要があった。

5 軸スコアリングで何を測ったか

評価軸を 5 つ定めた。A1 構造、A2 一次情報、A3 トラック整合、A4 SEO、A5 独自性だ。それぞれ 1〜5 点の 5 段階で採点し、合計 25 点満点で全記事を序列化した。

5 軸を選んだ理由は、「読んで良かった」「なんとなく薄い」という印象を排除するためだ。読み手によって基準がぶれる主観的評価では、48 本の相互比較はできない。測定可能な軸を決めてから採点することで、経営判断の根拠を数字で示せるようにした。

5 軸の詳細定義（採点基準・閾値・自動化の実装例）は将来の spoke 記事 2026-06-audit-scoring-rubric で深掘り予定だ。

結果サマリー — pass 22 / weak 15 / fail 11

結果は 48 本中、pass 22 / weak 15 / fail 11。fail 率 23%。公開水準を満たさない記事が 4 本に 1 本の割合で存在していた。

判定	本数	比率
pass	22	46%
weak	15	31%
fail	11	23%

さらに深刻だったのが featured 扱いにしていた記事の結果だ。トップページで最も目立つ位置に置いていた 3 本は、3 本すべてが fail だった。

featured 3/3 fail は単なる選定ミスではない。「最も注目させたい記事」が「最も品質が低い記事」になっていたのは、editorial judgment（何を前に出すか）と quality measurement（品質を数字で確認する仕組み）の両方が機能していなかったことの証拠だ。どちらか一方が正常に動いていれば、fail 記事をトップに出すことにはならなかった。

致命的な fail ケース 3 例

特に問題が深刻だったのは、本文の中身そのものが破綻していた次の 3 ケース。

hybrid-dev-team-style（management / case） — 本文の中に未入力の穴が 7 か所残っていた。執筆プロセスで「ここは後から数字を入れる」とマークした箇所が、数字が入らないまま読者の画面に出ていた。本文の末尾には「公開前に確認が必要」という内部メモまで露出していた。

sales-docs-business-impact（sales / case） — 「月に件の提案書を送るとすると」「合わせると、月間でが書類作成に費やされていた」「に短縮された」のように、数字や対象語が抜けたまま公開されていた。読者が読むと文が途中で切れて意味が通じない状態だった。

minutes-automation（claude-code / tech） — 本文末尾に執筆プロセスの内部指示書がそのまま漏出していた。読者の目に入るのは完全に意味不明のテキストだ。品質管理プロセスが最後まで機能しなかった典型例だった。

構造的な発見 — 機械的に防げる失敗を人手に任せていた

3 つは別々の症状に見えるが、根本原因は同じだった。機械が自動的に検出できる種類の欠陥を、人間の目視に依存する工程で止めようとしていた——その構造的欠陥だ。

これはプロダクトの問題ではなく、組織の工程設計の問題だ。AI が「ここに数字が必要だが私は知らない」と正直に示した箇所を、誰も確認せずに公開した。AI の出力が問題なのではなく、AI の出力を受け取る側の工程が機能していなかった。

機械が確実に検出できる失敗を人手レビューに任せる構造は、疲れた日・急ぐ日・人員が足りない日に必ず破綻する。これはプロダクトバグではなく工程バグだ。

フェーズ 2 — Google からのペナルティリスクの査定

品質問題と並行して、もうひとつの危険なシグナルが見つかった。発行日の分布だ。

magazine 47 本中 37 本が 2026-05-08 という 1 日に集中

47 本の magazine 記事のうち 37 本が 2026 年 5 月 8 日という同じ 1 日に公開されていた。割合にして 79%。残りも数日のうちに固まっていた。

「同一著者が 1 日に 37 本」は、Google の品質システムから見ると物理的に不可能な数字だ。1 人の書き手が朝起きてから寝るまでに 1 本 30 分で書き続けても、24 時間で 48 本が限界。それを 1 日でやったように見えるドメインは、大規模出版社か AI スケール生成のどちらかしかない。

この数字がドメインの信頼性評価に何を意味するかを、リスクとして定量評価する必要があった。

Google Scaled Content Abuse とペナルティ水準

Google は 2024 年 3 月から「Scaled Content Abuse」を Spam Policy に明記した。価値を加えずに大量のページを作る行為を spam と定義し、2025 年 6 月から人間の審査官による手動ペナルティの運用を開始している。

判定は量だけで決まるのではない。一次情報の有無、編集責任の明示、公開ペースの組み合わせで判断される。月 50 本でも独自データを含み編集レビューを経ていれば通過する。一方、月 8 本でも AI 生成テンプレートが並んでいれば対象になる。

ただし「1 日 37 本」は、判定の前提となる水準そのものを超えている。一次情報の質がどれだけ高くても、「人間が書ける量を超えている」という判定が先に立つ。品質で挽回できるレンジにない数字だった。

バックデートは有効か

「もう公開してしまった、後から日付をずらせば記録を上書きできるのではないか」という発想は自然だが、これは有効ではない。

Google は検索エンジンがそのページを最初に発見した日時（discovery date）を別途記録している。公開日付の表示を後から変更しても、discovery date は変わらない。John Mueller は「日付を遡って書き換える行為自体が deceptive と判定されるリスクがある」と明言している。表示上の公開日と実際の発見日が乖離すること自体が、ドメインの信頼性スコアを下げる材料になる。

「出してしまったものを後から取り繕う」ルートは閉じている。残るのは「全部やめて clean slate で再出発する」か「そのまま行く」の二択だった。

フェーズ 3 — owned media の構造的欠陥（内部リンク・タグ・シリーズ）

発行日の分布だけが問題ではなかった。記事同士をつなぐ構造もすべて壊れていた。

内部リンク 76 本が 100% 死亡していた理由

47 本の本文に含まれる内部リンクを集計したところ、76 本あった。そして全 76 本が死リンクだった。

原因は記事を書いた段階にはない。もっと上流——サイト構築のフェーズに問題があった。URL 規約を変更した際、変更後の規約を既存記事へ適用する作業と、新規記事生成時の規約統一と、リンク切れを検出する仕組みの整備——この 3 つのいずれも実施されなかった。上流で起きた構造的判断の漏れが、下流のすべてのコンテンツに波及した結果だ。

76 本全てが死んだのは、個別記事の執筆ミスではない。「サイト構築の品質」と「コンテンツ運用の品質」が分離して管理されていなかったことの証拠だ。フェーズ間の handoff で何を引き継ぐかが明文化されていなければ、上流の判断が下流を静かに壊す。

一方でこの死リンクは、結果として Google のクロール経路を断つ防御として機能した。意図した設計ではなく構造的な偶然だが、これが indexing 前の撤退を可能にした一因でもある。

タグの分散と孤立

ユニークタグが 77 種類あった。そのうち 55 種類が 1 本でしか使われていない孤立タグだった。

表記揺れも深刻だった。同じ概念が 3 つの表記で散らばっていた:

agents（4 本）
agent-design（1 本）
エージェント設計（1 本）

記事がタグでつながらない状態では、個別記事がいくら良くても topical authority は累積しない。コンテンツ群は「同テーマを扱う記事の集まり」としての力を持たず、ただ独立した記事の集合になる。連載として読める構造がなければ、読者は 1 記事を読んで離脱するだけだ。

series フィールドが空回りしていた

前後記事をつなぐナビゲーション機能は実装済みだった。series を指定すれば連載として記事が連結されるよう設計されていた。にもかかわらず、47 本のいずれも series を使っていなかった。

「機能はある、ただし誰も使っていない」状態だ。これはコードの問題ではなく、ガバナンスの欠如だ。機能の存在を知らなければ使われない。使うかどうかが個人の裁量に委ねられていれば、運用が忙しい時期には使われない。仕組みがあるだけでは運用は変わらない。

47 本中 28 本（60%）は他の記事からのリンクがゼロの孤立記事だった。pillar-spoke 構造を意図したつもりが、実態は孤立記事の集合だった。

フェーズ 4 — 経営判断: 削除か noindex か、失敗開示か

技術的な撤退は完了したが、戦略の質問はそこから始まった。Search Console の「ページのインデックス登録」を開いた結果は「データを処理しています。1 日後にもう一度ご確認ください」——subdomain magazine.yakumo.world の routing 追加から 1 週間、robots.txt 更新から 2 日、sitemap も未送信、内部リンクは前述の通り 76 本すべて死亡している状態だった。

つまり Google にこの subdomain の URL を知らせる経路がほぼ全部断たれていた。4 重の偶然の防御が同時に効いていた:

subdomain routing が新規（routing 追加は 1 週間前）→ crawl budget が極小
外部 back-link ゼロ → discovery 経路なし
Search Console sitemap 未送信 → 積極的な discovery 信号なし
内部リンク 76 本死亡 → 本体 yakumo.world からも辿れない

意図した防御ではなく構造的偶然だが、indexing がまだ始まっていない可能性が極めて高い状態だった。「今、撤退すれば clean slate で再出発できる」——あと 1 週間遅ければ Google のクロールが始まり、品質システムに 1 日 37 本という指紋が記録されていた。

削除 vs noindex の判断ロジック

撤退の方法として選択肢は 2 つあった。

A: 物理削除する — 48 本を working tree から消す。クリーンだが pass 判定の 22 本も捨てることになる。

B: noindex のまま draft で残す — 物理ファイルを保持しつつ build からは除外する。後で再利用する余地を残す。

最初は B を選びかけた。pass 22 本は機械的指標で問題なかったので、再活性化できそうに見えた。だが質的に読み直すと、22 本の多くは「機械的指標は通るが体験談として読めない」AI トーンの記事だった。pillar-spoke 構造の意図もないままトピックが分散していた。

最終的に A を採った。48 本を working tree から物理削除し、git history のみに残す。次フェーズで書く記事はすべて完全に新規執筆する。理由は narrative の一貫性だ。「リセットしました」と言いながら 5 月の記事を半分残すと、publishedAt の整合性が破綻し、外から見て信頼を損なう。

削除した記事の中身は失われていない。git show {commit}:{path} で過去の任意の版を参照できる。「ネタの素材」が必要になったら git history から取り出す前提だ。working tree に残しておく必要はなかった。

失敗開示を E-E-A-T 戦略として使う

もうひとつの判断は「この失敗を外に開示するか」だった。

A: 沈黙する — 何ごともなかったように relaunch する。読者は気付かない可能性が高い（indexing されていなかったため）。

B: 公開する — 失敗の事実と対応の手順を、数字付きで開示する。今読んでいるこの記事がそれにあたる。

B を選んだ。理由は HouseFresh の事例にある。あのサイトは「How Google is killing independent sites like ours」という記事で Google から潰された経緯を一次情報として公開した結果、業界全体から citation を集め、E-E-A-T の Experience（実体験）軸で逆に評価が上がった。

「1 日 37 本公開、内部リンク 76 本死亡、HUMAN_INPUT マーカー 4 記事漏出」のような数字付きの失敗開示は、実際に経験した owned media にしか書けない。これは AI 検索（ChatGPT Search / Perplexity / Google AI Overviews）が citation したくなる一次情報の形そのものだ。

失敗そのものが資産になる。隠す方が損だ。

フェーズ 5 — 何を仕組み化したか（mcluhan engine への投資判断）

撤退と公開だけでは「次回も同じ失敗をする」状態は変わらない。発見した問題を Gate として実装し、機械的に検出できるようにした。

これらを束ねる仕組みを mcluhan と名付けた。八雲の owned media のための汎用運用エンジンで、Astro と Vercel の構築物に重ねる形で実装している。命名は Marshall McLuhan のメディア論「The medium is the message」から取った。メディアそのものが伝えるメッセージは、表面の記事ではなく、その記事を運用する仕組み——公開前 Gate、レビュアー SSOT、公開スケジューラ、retro の累積——にこそ宿る、という設計意図だ。

なぜ「ツール追加」ではなく「エンジン設計」と捉えるか

今回の失敗を個別のバグ修正として扱うこともできた。「HUMAN_INPUT の grep チェックを追加する」「内部リンクの正規表現チェックを追加する」——それぞれ 1 時間もあれば実装できる。

だがそれをやっても、次の新しい失敗パターンが出てきたときにまた個別対応が必要になる。Gate をスクリプトの寄せ集めにしない。scripts/blog-gate.ts 1 ファイルに集約し、npm run prebuild で毎回走るように設計した。機械が機械的に検出できる失敗は機械に止めさせる——これを方針として掲げて、Gate を継続的に育てる投資対象として位置付けた。

mcluhan に組み込んだ Gate の構成

G1 — 公開前 HUMAN_INPUT grep scripts/blog-gate.ts が src/content/magazine/**/*.md を走査し、本文に HUMAN_INPUT が残っていれば exit 1 で build を止める。最も基本的なチェックがなかったことが今回の失敗の主因だった。

G2 — 内部リンク /blog/ パス検査 /blog/... パターンが残っていれば fail。Astro の URL 規約変更時に置き換え漏れが残るのを防ぐ。

G3-G6 — frontmatter SSOT 整合 tags は src/config/tags.ts の tagCatalog に存在するキーのみ。reviewer は src/config/members.ts の slug かつ canReview: true、その reviewScope が記事の track をカバーすること。表記揺れと「誰が責任を持ってレビューしたか不明」を排除する。

G7-G8 — scheduledAt と time-slot draft: false の記事は必ず scheduledAt を持ち、その時刻は publish-policy.ts の timeSlots のいずれかと一致すること。同時刻バーストを物理的に不可能にする。

W1-W3 — rate-limit 警告 直近 1 日に 4 本超、1 週間に 14 本超、1 ヶ月に 80 本超で warning を出す。build は止めないが、編集者に「公開ペースが speed limit を超えている」ことを通知する。

AI-assisted フッターの全記事表示 すべての記事の末尾に「この記事は AI 支援でドラフトされ、〇〇が yyyy-mm-dd にレビューしました」を強制表示する。AI 利用の事実を隠さず、reviewer を明示する。

Gate を増やすのではなく、Gate に意味を持たせる

Gate の数を増やすことは目的ではない。Gate が「機械が確実に検出できる失敗パターン」を網羅しているかどうかが重要だ。mcluhan の設計方針は「検出できる失敗を増やし続ける」ではなく、「検出された失敗を Gate に変換し続ける」だ。

今回の 3 つの失敗（HUMAN_INPUT 漏出 / 内部リンク死滅 / タグ揺れ）はすべて Gate に変換された。次に出てくる失敗パターンも同様に Gate に変換されていく。パイプライン自体が改善対象であり、記事を運用するたびに Gate が充実していく構造が、AI 量産時代の owned media の持続可能性を作る。

技術詳細: 緊急撤退の実装手順 {#tech-detail}

経営判断と運用設計が固まった後、実装は急ぐ必要があった。Vercel の deploy hook が走って Google が次に来るまでが時間切れだ。

Step 1 — 全 48 本を draft: true に

Astro Content Collection は frontmatter の draft: true を見ると build から除外する。これを使えば「物理ファイルは残しつつ、生成された HTML だけ消える」状態を作れる。

48 本を 1 つずつ手で書き換えると 30 分以上かかるうえミスもする。Python で frontmatter を一括書き換えするスクリプトを書いた。

import re
from pathlib import Path

root = Path("src/content/magazine")
files = sorted([p for p in root.rglob("*.md") if p.name != "_README.md"])

for p in files:
    text = p.read_text(encoding="utf-8")
    m = re.match(r"^(---\n)(.*?)(\n---\n?)(.*)$", text, re.DOTALL)
    if not m:
        continue
    open_tag, fm, close_tag, body = m.groups()
    new_fm = re.sub(r"^draft:\s*false\s*$", "draft: true", fm, flags=re.MULTILINE)
    if new_fm != fm:
        p.write_text(open_tag + new_fm + close_tag + body, encoding="utf-8")

regex で draft: false を draft: true に書き換える。frontmatter の他フィールドは触らない。1 秒で 48 本処理が終わる。

Step 2 — middleware.ts に noindex 対策

draft 化だけでは不十分だった。magazine トップページ・カテゴリ一覧・タグ一覧などは build に残るし、404 ページにも noindex を入れる必要がある。magazine.yakumo.world 全体の検索エンジン挙動を 1 か所で制御したい。

Vercel Edge Middleware で host 判定して、magazine.yakumo.world のすべてのレスポンスに X-Robots-Tag: noindex, nofollow ヘッダを付けた。同時に magazine.yakumo.world/robots.txt には専用コンテンツ（Disallow: /）を直接 Response で返す分岐を追加した。

const MAGAZINE_HOST = 'magazine.yakumo.world';

export default function middleware(request: Request): Response | undefined {
  const url = new URL(request.url);
  const host = (request.headers.get('host') ?? '').toLowerCase();

  if (host !== MAGAZINE_HOST) {
    return next(); // yakumo.world 本体は素通し
  }

  const { pathname } = url;
  const noindexHeaders = { 'X-Robots-Tag': 'noindex, nofollow' };

  // magazine 専用 robots.txt
  if (pathname === '/robots.txt') {
    return new Response('User-agent: *\nDisallow: /\n', {
      status: 200,
      headers: { 'Content-Type': 'text/plain' },
    });
  }

  // それ以外は通常の rewrite に noindex ヘッダを付与
  url.pathname = '/magazine' + pathname;
  return rewrite(url, { headers: noindexHeaders });
}

これで magazine.yakumo.world 配下のすべてのレスポンス（404 含む）に noindex が付き、robots.txt は subdomain ごとに別物が返る。本体 yakumo.world 側は何も変わらない。

Step 3 — commit を論理単位に分割

変更を 1 つの commit にまとめると、後で history を読むときに何が変わったか分からなくなる。3 つに分けた。

docs(blog-ops/audit): record full quality audit of 48 magazine articles — 監査 CSV と Markdown レポート（判断の根拠）
chore(magazine/content): unpublish all 48 articles for quality reset — 48 本の draft 化（内容変更）
feat(middleware/magazine): block search indexing of the magazine subdomain — middleware の noindex 化（インフラ層）

判断の根拠 → 内容変更 → インフラ層、という依存順で並ぶ。後から読んでも各 commit の意図が分かる。

Step 4 — Vercel デプロイ後の確認コマンド

deploy が完了したら、実際に noindex が効いているかを curl で 4 つの観点から確認する。

# 1. magazine.yakumo.world のトップに noindex ヘッダが付いているか
curl -sI https://magazine.yakumo.world/ | grep -i x-robots-tag

# 2. magazine.yakumo.world の robots.txt が Disallow: / を返すか
curl -s https://magazine.yakumo.world/robots.txt

# 3. 個別記事 URL が 404 + noindex ヘッダになっているか
curl -sI https://magazine.yakumo.world/2026-05-foo | grep -iE "HTTP|x-robots-tag"

# 4. yakumo.world 本体には noindex が付いていないか
curl -sI https://yakumo.world/ | grep -i x-robots-tag

4 つすべて期待通り動作したことを確認した。本体 yakumo.world は無影響、magazine subdomain のみが完全に検索エンジンから隠れた。

deploy 完了から確認完了まで 5 分。撤退の決断から実装完了まで 1 日（同日内）で終わった。

まとめ — タイムラインで振り返る

日付	アクション
2026-05-08	48 本一括公開（うち 37 本が同日内）
2026-05-17	magazine subdomain 大規模整備（routing 追加は 05-11、05-17 は UI/routing redesign）
2026-05-18 朝	blog-audit で 5 軸スコアリング実行、fail 11 本・HUMAN_INPUT 漏出 4 記事を検出
2026-05-18 昼	戦略診断（Google Scaled Content Abuse の境界線確認）+ 構造診断（内部リンク死亡 76 本、孤立タグ 55、orphan 28 本）
2026-05-18 夕	Search Console で indexing 未開始を確認、全撤退の判断
2026-05-18 夜	48 本 draft 化 + middleware noindex 実装 + 3 commits を main に push + deploy + 4 観点 curl 確認

検出から撤退まで 1 日。実装から本番反映まで 1 時間。ここまで縮められるのは AI 支援のおかげだ。Google のクロール前に間に合った理由の半分は subdomain が新規だった偶然、もう半分は判断と実装の速度差で間に合わせる運用設計だった。

この出来事を、八雲では後に Phase 0 と呼ぶ。mcluhan engine 構築以降のフェーズ (Phase 1: 仕組み化、Phase 2 以降: 段階的再開) と区別する文脈アンカーとして、本記事はその「Phase 0 = 量産から仕組み化への転換点」を記録している。

そして気付いたことがある。この記事自身が、八雲が今構築している新しい執筆パイプライン（blog-plan → blog-tech-write --from-brief → blog-review → blog-publish → blog-schedule）で最初に出力された本番記事だ。パイプライン自身を記事化している。書くたびに _state.json に決定ログが累積し、それが次回の blog-plan の参照素材になる。失敗の検出と仕組み化の連鎖そのものが、この媒体のコンテンツになっていく。

AI で量産できることはもはや前提だ。問われるのは、量産後に何を検知して、どう撤退し、どう仕組み化するかの運用設計のほうだ。

そしてもう一つ。一次情報を溜め続けることが、AI 量産時代の最強の資産になる。

AI は学習データに含まれない情報は書けない。今、八雲がここに書いている数字——48 / 5 / 11 / 76 / 37 / 79% / 23%、リード文の中で並べたこれらの数値は、八雲がこの 10 日間に実際にやったことから生まれた一次情報だ。他社が同じ記事を AI で再現しようとしても、出てくるのは「一般論で AI 量産を解説するページ」までだ。失敗の具体的な数字、撤退の手順、仕組み化のコード断片、判断の根拠とトレードオフ——これらは経験した側にしか書けない。

owned media の戦略は、AI で大量の文章を出すことではない。AI で大量の文章を出せる時代だからこそ、他社が書けない一次情報を組織として継続的に蓄積する仕組みを持つことだ。失敗のログ、運用の retro、実装の経緯——これらをスキル（mcluhan の blog-retro がその一例）として組織化して、書くたびに資産が積み上がる構造を作る。

AI が citation するのも、競合が真似できないのも、結局はこの一次情報の厚みだ。量産は前提、撤退と仕組み化は運用、そして一次情報の蓄積こそが資産になる。

Sister pillar: owned media 運用エンジン mcluhan の構造設計 Related (owned-media-engine cluster): Pre-publish gate 設計 — false positive と false negative の両立 / Pre-publish gate の高度化 — 単純 grep から proximity 解析へ / Brand rule の機械チェック化