判断を、AIが読める形にする

この報告書について

本書は、BtoBマーケティング組織がAIをどう業務に組み込んでいるかを、公開されている一次情報から確認してまとめたものです。

企業事例・数値・直接引用は、出典を原典まで当たって照合しました。 確認できなかったもの、条件が原典と食い違っていたものは載せていません。そのぶん扱う事例は少なくなっています。Prollectの解釈と提案は、原典の記述と区別したうえで、根拠との対応と本文の整合を確認しています。〔解釈〕〔提案〕として明示します。

本書は「AI活用の全体像」ではありません。限られた数の事例について、何をAIに渡し、どこで人間が判断しているかを分解したものです。

4つの区別

本書では次の4つを明示的に分けて書きます。混ぜません。

数値の扱い

数値は、主張に必要で、対象・単位・期間・条件を原典で確認できたものだけを残しました。企業が自社ブログや自社資料で公表した数値には〔自己申告〕と付けています。

〔自己申告〕の数値は、AIの導入によって生じた効果を実証したものではありません。 対照群がなく、他施策や時期要因との分離もされていません。目標値として使わないでください。

第1章｜何を確認したか

1-1. 出発点

多くの組織で起きているAI活用は、おおむねこの形です。

担当者がチャットを開く → 今日の状況を説明する → 何かを頼む → 出てきたものを直す → 翌日また、同じ説明をゼロからやり直す。

一方、本調査で確認できた事例では、説明が毎回ゼロから始まっていません。何を見るべきか、何が良い出力か、どのデータが正か——それが事前にファイルとして存在しています。

〔事実〕Ahrefs の Ryan Law（Director of Content Marketing）は、自分のコンテンツ生成パイプラインが機能する理由をこう書いています。

"This process works well because it mirrors our existing human editorial process, built from decades of collective content marketing experience."

（このプロセスがうまく機能するのは、数十年分の集合的なコンテンツマーケティング経験から作られた、既存の人間の編集プロセスを写しているからだ）

〔事実〕CircleCI の Ron Powell（5名のマーケティングチーム）は、より直接的です。

"If something isn't in CLAUDE.md, Claude doesn't know about it."

（CLAUDE.mdに書かれていないことを、Claudeは知らない）

"The actual decision was 'let's stop pretending we can remember the process and make the process remember itself.'"

（実際に下した決定は、「プロセスを覚えていられるふりをやめて、プロセス自身に覚えさせよう」ということだった）

1-2. 確認できた範囲

〔解釈〕本調査で原典まで確認できた事例に限れば、AIに渡しているものの中身は、ツールの設定ではなく「判断基準を書いた文書」でした。何をどう書いているかは事例ごとに違いますが、「文書が先にある」という点は共通しています。

ただし、これを「AIネイティブの正体は判断の外部化である」と一般化はしません。 本調査が確認できたのは、公開情報を出している少数の組織——その多くは英語圏のソフトウェア企業——に限られます。判断基準を文書化していないのに成果を出している組織や、文書化しても進まなかった組織を、本調査は探せていません。反証側を確認していない以上、法則としては書けません。

1-3. 日本の活用状況——利用率・組織内浸透・方針・成果を分けて見る

〔事実〕日本については4つの調査があります。それぞれ別のことを測っています。

• [S14a]全国10,312社の調査で、生成AIを活用している企業は34.5%。活用企業のうち86.7%が「効果あり」と回答する一方、課題として情報の正確性を50.4%が挙げている（帝国データバンク、2026年3月17〜31日、23,349社対象・10,312社回答）
• [S14b]BtoBマーケティング従事者では、「ときどき活用」41.7%＋「日常的に活用」28.8%。しかし「メンバーの80%以上が日常的に活用している組織」は12.2%（才流、n=600、2025年7〜8月）
• [S14c]企業のAI活用方針について、日本は「方針を明確に定めていない」が31.8%。米国9.1%、ドイツ12.9%、中国4.2%（総務省、2024年度調査）
• [S14d]PwC Japan の調査（日本 n=945、2025年2月、売上500億円以上・課長職以上）では、活用は56%に達する一方、「期待を上回る効果」を出せている企業の割合は米国・英国のおよそ4分の1の水準。※原典は比率で示しており、日本側の実数は公表されていません

4つは対象も設問も時期も違うため、足し合わせて1つの結論にはできません。帝国データバンクは全業種の企業単位の活用率、才流はBtoBマーケティング従事者の組織内浸透度、総務省は方針の有無、PwCは売上500億円以上の大企業の実感です。

〔提案〕自社の状況を見るときは、この4つを分けて確認することを提案します。 「AIを使っているか」だけでは足りません。個人の利用状況に加えて、業務手順と判断基準がチーム内で共有されているか、方針が決まっているか、成果をどう見ているか——を別々に確認したいところです。

〔事実〕国内の実務者からは、次のような証言があります。1名の見解であり、全国的な傾向を示すものではありません。

「AIを使っているのに、組織の業務プロセスが何も変わっていない」

— 太田翔葵（シャコウ CEO）／2026年4月24日[S15]

1-4. 自己申告の時間短縮を、そのまま信じない

〔事実〕[S16a]METR の RCT（n=16、熟練OSSコントリビュータ、246課題、自分のリポジトリの実課題）では、被験者は事前に「24%速くなる」と予測し、実際には19%遅くなり、事後も「20%速くなった」と信じていました。

これは2025年前半のAIツールと、当該の開発作業の条件での結果です。 マーケティング業務を調べたものでも、日本の組織状態を調べたものでもありません。

〔事実〕[S16b]同チームは2026年2月に追跡報告を出しています。そこでは、被験者の30〜50%が「AIなしではやりたくない課題を提出しなかった」と答えるなどの選択バイアスが強く、効果の大きさを推定するのが難しいと報告されています。「新しい実験のデータは、現在のAIツールの生産性への効果について信頼できるシグナルを与えていない」とも書かれています。

この追跡報告を「効果が改善した証明」として使うことはできません。 同報告は「2026年初頭の開発者は2025年初頭より速くなっている可能性が高い」とも述べていますが、直後に「選択効果のため、我々のデータはその増加幅についてごく弱い証拠にしかならない」と限定しています。

〔解釈〕ここから言えるのは、自己申告だけでは実際の時間短縮を判断できないということです。本書に出てくる〔自己申告〕の数値は、この前提で読んでください。

第2章｜確認できた事例

主要な5事例を、①どの業務か ②何を外部化したか ③AIが担う工程 ④人間が判断・介入する場面 ⑤原典で確認できること／できないこと ⑥Prollectの解釈と提案 で分解します。章の最後に、補足として3つの短い事例を置きます。

本章の数値は、断りのない限りすべて各社の〔自己申告〕です。 測定方法・母数・ベースライン・対照群は開示されていません。

事例1｜Ahrefs コンテンツチーム[S1][S2]

① 業務：情報系SEO記事のキーワード選定〜ほぼ完成原稿までの生成、および既存記事の更新。

② 外部化したもの：既存の編集プロセスに対応する約23個のスキルファイルと、それらを順に発火させる blog-pipeline スキル。工程はキーワード調査 → トピックギャップ分析 → リサーチ集約 → 構造的アウトライン → ドラフト → HTMLプレビュー → 最終フォーマット。設計の核は「各ステップが自前の出力ファイルを持つ」ことです。

③ AIが担う工程：上記の各工程の実行。

④ 人間が判断・介入する場面：4つのゲート。

加えて、著者は主張を検証できるだけそのトピックを理解している必要があり、編集者が全記事の全語を読み、編集者は「no」と言う権限と意思を持つとされています。

⑤ 確認できたこと：スキル約23個、blog-pipeline、4ゲートの名称と問い、ドラフト生成6〜12分〔自己申告〕、この新プロセスでの公開実績が「約15本の新規公開と約30本の更新」（原文も "around" "some 30 or so" と概数）、画像挿入は現状手動で "not a solved problem, yet" と明記。自社調査でのAI検出スコアと検索順位の相関 0.011（実質ゼロ）。

Ryan Law が front-loading について述べているのは、正確には次の形です。

"My thesis is that small amounts of expert direction provided at the start of the content creation process are vastly more effective than lots of human editing at the end."

（私の仮説は、工程の開始時に与える少量の専門的方向づけは、最後に大量の人間の編集を加えるよりはるかに効果的だ、というものだ）

これは本人が「仮説」と明示している主張です。 検証結果として書かれてはいません。

そして、あえてやらなかったことが明記されています。

"I could use this process to scale the Ahrefs blog to tens of thousands of articles. I will not."

〔事実〕Si Quan Ong（同社）は、順位低下について次のように書いています。原文には条件節があります。

"But as AI use increased, search performance tended to decline. ... It's that companies often use AI to skip the difficult work and publish more average content."

（AI利用が増えるにつれて、検索パフォーマンスは低下する傾向にあった。……企業がAIを、困難な作業を飛ばして平均的なコンテンツをより多く公開するために使いがちだからだ）

⑤' 確認できないこと：6〜12分の測定方法、比較対象、母数。約15本／約30本がどの期間のものか。

⑥ Prollectの解釈と提案

〔解釈〕この事例で外部化されているのは「AIの使い方」ではなく、13年分の編集実務で培われた判断基準そのものです。4ゲートの問いは、AIがなくても成立する編集基準です。

〔提案〕真似する対象は23個のスキルではなく、4つのゲートの問いを自社の言葉に翻訳することだと考えます。スキルの本数は、工程を分解した結果として決まります。

「6〜12分」を目標にしないでください。 この数字は front-load する専門知と、読者・製品・競合の3データソースが揃っている前提の結果値です。

事例2｜CircleCI マーケティングチーム（5名）[S3]

① 業務：ブログ記事・チュートリアルの制作と公開。

② 外部化したもの：CLAUDE.md と .claude/rules/ 11ファイル（ブランドボイス、禁止フレーズ、レビュー基準の pass/fail、内部リンク規約、会社の行動原則、スケジューリングほか）。エージェント7体、スキル6種（seo-geo-post／tutorial-update／publish-prep／promote／the-guild／workflow-skill-check）。

③ AIが担う工程：生成（Architect／Librarian／Mouthpiece）と、4段階のレビュー（Corrector／Webcrawler／Censor／Focus Group）。

④ 人間が判断・介入する場面：プロダクションマネージャーが、公開前のチェックリストを人手で回します。 チームは「生成する人」と「公開可否を判断する人」を人的に分離しています。

"A review process that agrees with everything you write is not a review process."

（すべてに同意するレビュープロセスは、レビュープロセスではない）

原文はこう続きます——"so each of these is built with specific friction."（だから、それぞれに固有の摩擦を組み込んである）

⑤ 確認できたこと：チーム5名の構成、ルール11ファイル、エージェント7体、スキル6種、上記2つの引用、公開前チェックリストが人手であること。

⑤' 確認できないこと：定量的な成果（時間削減・本数・効率の数値）は、原典に一切ありません。 本事例に成果数値は存在しません。

⑥ Prollectの解釈と提案

〔解釈〕成果数値がないにもかかわらず、この事例が参考になるのは、「何をファイルに書いたか」が具体的に開示されているからです。禁止フレーズのリスト、レビュー基準の pass/fail——これらは他社が真似できる粒度で書かれています。

〔提案〕5名規模で最初に置くべきは、生成者と検査者の人的分離だと考えます。1人チームではこれが構造的に成立しないため、代替が要ります（第4章）。

事例3｜Anthropic 社内のマーケティング／営業チーム

Anthropic は自社の Claude 活用事例を複数公開しています。すべて自社製品の宣伝文脈で公開されたもので、数値は〔自己申告〕です。 本書は数値ではなく、何を文書化したかを扱います。

3-1. マーケティング・オペレーション（Ian Chan）[S4]

① 業務：週次のマーケティング指標レビューの準備。

② 外部化したもの：3つのスキル（prep／proofreading／action-items）。

③ AIが担う工程：毎週日曜の夜にスケジュール実行され、前週のレポートを読み、直近のミーティング文字起こしを確認し、Slackを検索し、データにクエリを投げ、指標テーブルと論点候補を置いておく。

④ 人間が判断・介入する場面：担当者は月曜の朝にそれを開き、数値を検証し、どこにナラティブの焦点を当てるかを決める。

⑤ 確認できたこと：3スキルの名称、日曜夜のスケジュール実行、準備工数が「週1〜2日」から「最大2時間」になったという記述〔自己申告〕。

⑤' 確認できないこと：測定期間、比較方法。

⑥ Prollectの解釈と提案

〔提案〕ここで人間に残っているのは「どこに焦点を当てるか」です。校正スキル（proofreading）が数値レポートの照合先を持っているという設計は、指標定義を1箇所に揃えている組織でないと成立しません。

3-2. フィールドマーケティング（Adam Ward）[S5]

① 業務：社内の営業担当者（AE／BDR／カスタマーサクセス／アライアンス）に向けた週次のSlack DM配信。 担当アカウントに合わせて、イベントや紹介できるコンテンツを知らせるものです。顧客への配信ではありません。

② 外部化したもの：配信プロンプトに9つのコンテンツルール。そのすべてが、1件ずつのフィードバックに対応しています。

③ AIが担う工程：毎週月曜、各営業担当者の担当アカウントに合わせて配信内容を生成し、Slack DMで送る。定期配信は本人の承認待ちを挟まずに実行されます。本人は配信内容の確認を続けています。

④ 人間が判断・介入する場面：配信前の承認待ちは外していますが、本人による内容の確認は続いています。

"I still read what goes out, though the system no longer waits for my approval."

（システムはもう私の承認を待たないが、私は出ていくものを今も読んでいる）

休暇中も月曜の配信が自動で出た、とも書かれています。

⑤ 確認できたこと：配信先が社内の営業担当者であること、Slack DMであること、9つのルールがそれぞれ1件のフィードバックに対応していること、承認待ちを外していること、上記の引用。

⑤' 確認できないこと：内容確認のタイミングと、全件を見ているかどうか。

⑥ Prollectの解釈と提案

〔解釈〕この事例で外れているのは「配信前の承認待ち」であって、「内容の確認」ではありません。承認待ちを外したのは9つのルールが揃った後のことで、出発点ではありませんでした。これはこの1社の運用例です（第3章）。

〔事実〕本人は非技術者で、記事の小見出しに "You don't need to code, you need to explain"（コードを書く必要はない。説明する必要がある）と置いています。

3-3. 営業（Travis Bryant／Jared Sires）[S6][S7][S8]

この節は、担当者も業務も異なる3つの記述をまとめています。数値がどれに紐づくかを分けて示します。

① 業務：担当アカウントの優先順位づけ[S6]と、営業向け社内ツールの内製[S7]。

② 外部化したもの：アカウント評価の5次元ルーブリック（agent opportunity／internal transformation／AI commitment／white space／industry fit）[S6]。※原典は tech 向けと industries 向けの2本立てで、本書は tech 側のみを扱います。

③ AIが担う工程

• Bryant[S6]：4,000件のアカウントを一晩でルーブリックに照らして採点する。
• Sires[S7]：CLAFTS（約4,300行、ほぼ全てを Claude Code が記述）が動き、/customer-context が約90秒で顧客のコンテキストをまとめる。

④ 人間が判断・介入する場面：Bryant はこう書いています。

"Claude builds the what; I do the why."

（Claudeがwhatを作り、私がwhyをやる）

〔事実〕Jared Sires[S7]は、入社までコードを1行も書いたことがないAEでしたが、約4,300行のツールを作り、営業組織の約80%が採用したと書かれています〔自己申告〕。

〔事実〕インバウンド／アウトバウンドを担当する John Albert は、2つの教訓を挙げています。

"Keep a person on every send."

（すべての送信に、人を1人置け）

"Collect the questions your team answers repeatedly ... into a single external-facing document."

（チームが繰り返し答えている質問を……外部向けの1つの文書に集めよ）

"external-facing"（外部向け）という限定が付いています。 社内ナレッジベース一般の話ではありません。

⑤ 確認できたこと（数値はいずれも〔自己申告〕）

⑤' 確認できないこと：BDRの削減後の時間、コンバージョン率、ROI——いずれも原典に記載がありません。

⑥ Prollectの解釈と提案

〔解釈〕採点そのものはAIが担い、人間は「なぜその順序か」の側に残っています。ルーブリックの5次元は、AIがなくても営業の優先順位づけに使える判断基準です。

〔提案〕"Collect the questions ... into a single external-facing document." の限定に注意してください。ここで作れと言われているのは、社内の万能ナレッジベースではなく、外部に出せる形のQ&A文書です。

事例4｜Attio RevOps（Kyle Doherty）[S9]

① 業務：商談後のCRM更新と、失注理由の分類。

② 外部化したもの：「Update Deal」で抽出する7属性（stage／close date／value／next steps／people／current solution／competitors）。

③ AIが担う工程：商談の記録から7属性を抽出してCRMのレコードを更新する。失注理由の分類は別のエージェントが担い、その出力に確信度スコアを付けます。

④ 人間が判断・介入する場面：失注理由の分類について、確信度が低いものだけを人が見る設計。7属性の抽出・CRM更新の側に、この仕組みがあるとは書かれていません。

"Scoring is a prioritization tool, nothing more."

（スコアリングは優先順位づけの道具であって、それ以上のものではない）

"Give them good data and let them decide where their hour goes."

（良いデータを渡して、その1時間をどこに使うかは本人に決めさせる）

⑤ 確認できたこと：CRM更新で抽出する7属性の内訳、失注理由を分類する別エージェントとその出力への確信度スコア、上記2つの引用。

⑤' 確認できないこと：定量的な成果は原典にありません。

⑥ Prollectの解釈と提案

〔提案〕確信度スコアは、全件を人が見る／全件を自動で通す、の二択を避けるための設計です。Attio がこれを置いているのは失注理由の分類であって、CRM更新の全工程ではありません。

ただし「AIに確信度を書かせ、低いものだけ見る」をそのまま導入することは勧めません。 そのスコアが実際に誤りの発見に役立つかは、出力と正誤を突き合わせて検証する工程を経なければ分かりません。確信度が高ければ確認不要、ということにはなりません。 高確信のまま誤っている出力があるかを、まず自分のデータで確かめる必要があります。

事例5｜Fin（fin.ai／Dee Kapila）[S10]

① 業務：週次レポートの作成。

② 外部化したもの：「Ground Truth」＝データウェアハウスに対するAIファーストのセマンティックレイヤー。指標の定義、参照すべきテーブル、既知の罠がここに書かれています。

③ AIが担う工程：エージェントは、データに触れる前に必ず Ground Truth を検索し、正しい定義・正しいテーブル・既知の罠を取得します。データ接続は Snowflake MCP と Slack MCP を経由します。週次レポートについては、初版を約45分の対話で構築し、以後は約5分の運用で回っていると書かれています〔自己申告〕。

④ 人間が判断・介入する場面：Research and Data（RAD）チームが、Ground Truth を人手で保守します。 自動更新ではありません。

⑤ 確認できたこと：Ground Truth の位置づけと RAD チームによる保守、Snowflake MCP ＋ Slack MCP、週次レポートについて「初版は約45分の対話で構築」「以後は約5分の運用」「週約2時間の手作業を削減」「v67で3四半期以上稼働」〔自己申告〕。

⑤' 確認できないこと：「45分」「5分」「週2時間」の測定方法と比較条件、RADチームの人数、v67 に至るまでに何を変えたか——いずれも原典に記載がありません。

Dee Kapila 本人は、自身の経験としてこう述べています。

"For every 20-25 build experiments you'll have one major breakthrough."

（20〜25回のビルド実験に対して、大きなブレイクスルーは1回）

本人の見解であり、標準的な成功率や必要な試行回数を示すものではありません。

⑥ Prollectの解釈と提案

〔解釈〕指標の定義を人間が保守し続ける専任の担い手を置いている点が、この事例の中心です。自動更新ではありません。

〔提案〕小規模組織では専任チームは持てませんが、「指標定義のファイルを1つ持ち、数値を出すたびにそこを照合先にする」ところまでは同じ形で作れると考えます。

補足事例｜少人数チームの3例[S11][S12]

以下は短い記述しか公開されていないため、対象業務／AIがすること／人間が確認することだけを取り出します。

Kramer が目視確認をした理由は、AIが「何年も前に退職した役員を、自信満々に現職として出力した」ためです。

"Automation gets you to a starting point; manual verification gets you to the finish line."

（自動化はスタート地点まで連れて行く。ゴールまで連れて行くのは手作業の検証だ）

〔解釈〕3例とも、人が通る一点を置いています。ただし置き場所は同じではありません。Mintlify は更新の承認、Buffer は全社公開前のスキルのテスト、Kramer は公開する調査データの目視確認です。対象も、事前か事後かも違います（第3章）。

第3章｜人間はどこに立っているか

3-1. 確認できた配置

人間の関わり方は、事例ごとに別のものでした。まとめて「人間が承認している」とは書けません。関与には少なくとも2つの層があり、1つの事例で両方が併存します。

層1：ルール・スキルの事前確認——AIに渡す判断基準やスキルを、使い始める前に人が確認するか。

層2：個別出力の確認——出てきたものを、公開・送信の前後に人が見るか。

「承認待ちがない」ことと「内容を確認していない」ことは別です。 承認を通さずに出る仕組みでも、担当者が内容を読んでいる場合があります。表では分けて書きます。

原典で確認できる範囲は、次のとおりです。原典に記載がないものは「記載なし」と書き、推測で埋めていません。

Buffer について確認できるのは「新しいスキルを専門家がテストしてから全社公開する」ことだけです。 その後の個別出力を確認しているかどうかは、原典に書かれていません。「確認していない」という意味ではありません。

Anthropic フィールドマーケティングの9つのルールについて、原典から確認できるのは「それぞれが1件のフィードバックに対応している」ことです。 ルールを正式な承認工程にかけているかどうかは書かれていません。ルールの作成・修正と、承認工程とは別のものです。

〔解釈〕確認できた事例を、まとめて一つの原則にはできません。 言えるのは各事例についてだけです——Anthropic BDR は「すべての送信に人を1人置く」を自チームの原則として明言している。Ahrefs と CircleCI は公開記事を個別に人が通している。Anthropic フィールドマーケティングは、社内向け配信の承認待ちを外したうえで、本人が内容を読み続けている。Attio は失注理由の分類について、確信度の低いものだけ人に戻している。 これらは同じ設計ではなく、どれが正しいかを本調査は判定できません。

3-2. 「入口と出口」だけでは足りない

〔解釈〕これを「人間は入口と出口、AIは中間工程」という配置に単純化すると、危険な場面が抜けます。 確認できた事例自体が、中間で人間に戻す必要を示しています。

中間で人間に戻すべき条件（事例から読み取れるもの）：

• 原典どうしが食い違っているとき。 同じ施策の成果が、出典によって単位も基準も違う形で書かれていることがあります。突き合わせは人間の仕事です
• 顧客固有の情報が足りないとき。 Emily Kramer の例のように、AIは欠落を「自信満々の出力」で埋めます
• 商品・提供範囲の判断が要るとき。 何が言えて何が言えないかは、判断基準の側の問題です
• 抽出した内容が、以後の前提として蓄積されるとき。 検証のないまま社内の正史になると、誤った前提の上に企画が積み上がります

〔提案〕「顧客に出る文面と、数字を含む主張は、必ず人が承認する」を1行で決め、それとは別に、上の4条件に当たったら工程の途中でも止めると決めておくことを提案します。

第4章｜Prollectからの提案

本章は〔提案〕です。実証されたものではありません。 第2章の事例から Prollect が読み取ったものを、日本の小規模なBtoBマーケティング組織向けに翻訳したものです。

4-1. 一業務に必要な判断基準から始める

〔提案〕判断基準を網羅的に揃えてから着手する必要はありません。 1つの業務を選び、その業務に必要なものから始めることを提案します。

ここで「判断基準」と「作業対象のデータ」は別のものです。判断基準はAIに渡す物差しで、データは物差しを当てる対象です。両方が要ります。

指標定義を1ファイル書けば校正が回る、という話ではありません。 定義があっても、照合先のデータと集計条件が揃っていなければ検算はできません。

〔実装中〕Prollectは、顧客像・商品の事実・指標定義・禁止表現の4ファイルを作り、実際の制作で参照を始めたところです。有効性は検証中です。

4-2. 「検証できる仕事」から選ぶ

〔提案〕最初にAIへ渡す業務は、合否を判定できるものから選ぶことを提案します。

「数値が検証済みソースと一致するか」「URLが一字ずつ一致するか」「文字数制限内か」は、そのまま判定できます。

一方「良い記事か」は、そのままでは判定基準が曖昧です。 判定が不可能という意味ではなく、読者・主張・証拠といった要素へ分解する必要があるということです。Ahrefs の4ゲート（第2章）は、その分解の一例です。「読者を助けているか」「主張を裏付けられるか」「獲得していない確信が混ざっていないか」——ここまで分ければ、人もAIも判定に加われます。

分解の済んでいるものから始めるのが早い、というのが提案の趣旨です。

4-3. 修正の理由を記録し、続けて使うものだけ判断基準にする

〔事実〕Anthropic のフィールドマーケティングでは、プロンプトの9つのコンテンツルールが、それぞれ1件のフィードバックに対応しています。

〔提案〕ここから提案するのは、修正した理由を記録し、再発性と重要性に応じて判断基準を更新するという運用です。すべての指摘をルールにするという意味ではありません。一度きりの修正で済むものと、継続して使う判断基準になるものを、記録の中から選びます。

〔実装中〕Prollect 自身も、その線引きを試している最中です。まだ結論は出ていません。

4-4. 順序についての提案

〔提案〕以下は Prollect の提案する順序であり、実証された処方箋ではありません。 期間も目安です。

• 1つの業務を選ぶ（合否を判定できるもの）
• その業務に必要な判断基準だけを書く
• 工程を分解し、各工程の出力をファイルにする
• 人間の承認線を1行で決める
• 修正した理由を記録し、再発性と重要性に応じて、継続して使う判断基準を更新する
• 繰り返し実行する必要があり、確認と停止の条件を決められた業務だけ、スケジュール実行に移す（すべての業務が対象ではありません）

〔提案〕この順序に共通しているのは、小さく試し、結果を見て、続行・修正・停止を判断するという進め方です。最初から本番規模で走らせません。

第5章｜本調査の限界

5-1. 対照群について

第2章で扱った企業のマーケティング実装事例の中に、対照群を置いた比較として原典で確認できたものはありませんでした。

ここで言っているのは、企業が自社で公開した実装事例についてです。効果を検証した学術研究とは別に扱います。 第1章で引用した METR の RCT は対照群を置いた実験ですが、これは開発作業を対象とした学術研究であって、マーケティング業務へのAI実装の効果を測ったものではありません。本書は前者を「事例」、後者を「研究」として区別しています。

したがって、第2章の〔自己申告〕数値は、いずれも他施策や時期要因との因果分離がなされていないものとして読んでください。

5-2. 国内について

「マーケティング組織をAIエージェント前提に再設計した」国内の一次事例（数字つき）を、本調査の範囲では確認できませんでした。

存在しないと断定はできません。本調査がアクセスできた公開情報の範囲で見つからなかった、ということです。

公開事例が少ないことから、先行者利益や競争上の優位は導けません。 国内での適用条件と、実際に成果が出るかどうかは、今後の実装と検証を待つ必要があります。

5-3. その他

• 自己申告だけでは、実際の時間短縮を判断できません。 本書の各事例についても、測定方法や比較条件を個別に確認する必要があります（第1章 1-4）
• 「マーケ1人目がフルファネルを1人で回している」という一次証言は、確認できませんでした
• Reddit / Indie Hackers / LinkedIn長文投稿は未調査です。 小規模な運用の実装レポートが集まりやすい場であり、本調査の空白として認識しています
• 主要ツールの、日本語・日本企業データにおける精度は、いずれの出典でも検証されていません
• 〔解釈〕〔提案〕と付した箇所は、すべて Prollect の判断であり、出典に書かれていることではありません

第6章｜本調査を公開している立場について

Prollectは、AIツールの導入支援やAI研修を提供している会社ではありません。受注から逆算して「どんなコンテンツを、誰に、どの順番で作るか」を設計する会社です。本調査でAIを正面から扱ったのは、AIが商品だからではなく、作れる量が増えたときに「何を作るか」の判断がどこまで価値を持つのかを、確かめる必要があったからです。

〔実装中〕第5章に書いたとおり、「マーケティング組織をAIエージェント前提に再設計した」国内の一次事例（数字つき）を、本調査の範囲では確認できませんでした。 存在しないという意味ではありません。他社に提案を出しておいて自社では試していない状態を避けるため、Prollect自身でも判断基準の外部化に着手しています。

現時点で報告できるのは、次の2点だけです。

• 顧客像・商品の事実・指標定義・禁止表現の4ファイルを作成した
• それを実際の制作業務で参照し始めた

これは組織再設計の成果事例ではありません。 効果は測っていません。何がうまくいき、何がうまくいかなかったかは、検証できる形になった時点で、本書が他社の数値に適用したのと同じ基準——対照群の有無、自己申告か実測か——を自分たちにも当てて公開します。

出典一覧

出典の種類について

種類は、証拠の強さや引用可否を決めるものではありません。 出典がどこから来たかを示すだけです。

種類にかかわらず、次の4つは出典ごとに個別に確認が必要です。

• 記述が原典と一致しているか
• どのような方法で得た情報か（母数・設問・期間・対象）
• 当事者の自己申告か、第三者が測ったものか
• その調査・記述が、どの範囲の主張までを支えられるか

公的資料や学術研究であっても、対象・方法・時期・適用範囲の確認は要ります。種類だけで「そのまま引用してよい」と判断しないでください。

1. 事例（本文 第2章）

[S1] Ahrefs — コンテンツ制作パイプライン

Ryan Law「How I Do Content Engineering With Claude Code」Ahrefs Blog／2026-04-28

https://ahrefs.com/blog/how-i-do-content-engineering-with-claude-code/

＝約23個のスキルファイル／blog-pipeline／4ゲート／ドラフト生成6〜12分〔自己申告〕／約15本の新規公開・約30本の更新／画像挿入は手動／"My thesis is that..." の引用

種類：当事者の自己開示

[S2] Ahrefs — AIスロップと検索順位

Si Quan Ong（Reviewed by Ryan Law）「How We Use AI Without Making AI Slop」Ahrefs Blog／2026-08-28

https://ahrefs.com/blog/how-we-use-ai-without-making-ai-slop/

＝AIスロップの定義／AI検出スコアと検索順位の相関 0.011／順位低下の説明

種類：当事者の自己開示

[S3] CircleCI — マーケティングチーム（5名）

Ron Powell「Inside CircleCI's Claude marketing folder」CircleCI Blog／2026-04-14

https://circleci.com/blog/claude-marketing-folder/

＝チーム5名／.claude/rules/ 11ファイル／エージェント7体／スキル6種／公開前チェックリストは人手／2つの引用。定量的な成果数値は原典に記載なし

種類：当事者の自己開示

[S4] Anthropic — マーケティング・オペレーション

「How Anthropic's marketing operations team uses Claude Cowork to automate reporting and campaign builds」Anthropic／2026-07-08

https://claude.com/blog/how-anthropics-marketing-operations-team-uses-claude-cowork-to-automate-reporting-and-campaign-builds

＝3スキル（prep／proofreading／action-items）／日曜夜のスケジュール実行／週1〜2日→最大2時間〔自己申告〕

種類：当事者の自己開示

[S5] Anthropic — フィールドマーケティング

「How an Anthropic field marketer uses Claude Code to send weekly personalized updates to every sales rep」Anthropic／2026-08-24

https://claude.com/blog/how-an-anthropic-field-marketer-uses-claude-code-to-send-weekly-personalized-updates-to-every-sales-rep

＝社内営業担当者（AE／BDR／CS／アライアンス）への週次Slack DM配信／9つのコンテンツルール（それぞれ1件のフィードバックに対応）／配信前の承認待ちは外しているが「I still read what goes out」と説明／"You don't need to code, you need to explain"

種類：当事者の自己開示

[S6] Anthropic — 営業（アカウント評価）

Travis Bryant「How an Anthropic sales leader uses Claude Cowork to run a 4,000-account book」Anthropic／2026-05-20

https://claude.com/blog/how-an-anthropic-sales-leader-uses-claude-cowork-to-run-a-4-000-account-book

＝Travis Bryant（Head of US Mid-Market GTM）。5次元ルーブリック（tech向け）／4,000件のアカウントを一晩で採点〔自己申告〕／日次90分・週次3時間の削減〔自己申告〕／"Claude builds the what; I do the why."

種類：当事者の自己開示

[S7] Anthropic — GTMエンジニアリング

「How Anthropic uses Claude for GTM engineering」Anthropic／2026-06-05

https://claude.com/blog/how-anthropic-uses-claude-gtm-engineering

＝Jared Sires。CLAFTS 約4,300行（ほぼ全てを Claude Code が記述）／CLAFTS による週10〜15時間の節約〔自己申告〕／営業組織の約80%が採用〔自己申告〕／/customer-context が約90秒〔自己申告〕／入社までコード未経験

種類：当事者の自己開示

[S8] Anthropic — BDR（インバウンド／アウトバウンド）

John Albert「How Anthropic's business development team uses Claude to run inbound and outbound at scale」Anthropic／2026-08-07

https://claude.com/blog/how-anthropics-business-development-team-uses-claude-to-run-inbound-and-outbound-at-scale

＝"Keep a person on every send."／"Collect the questions ... into a single external-facing document."。削減後の時間・コンバージョン率・ROIは原典に記載なし

種類：当事者の自己開示

[S9] Attio — RevOps

Kyle Doherty「How Attio runs RevOps on Attio」GTM Strategist／2026-09-04

https://knowledge.gtmstrategist.com/p/how-attio-runs-revops-on-attio

＝別の業務が2つ。①商談後のCRM更新（「Update Deal」で抽出する7属性）②別のエージェントによる失注理由の分類と、その出力への確信度スコア／2つの引用。定量的な成果数値は原典に記載なし

種類：当事者の自己開示（本人寄稿）

[S10] Fin（fin.ai）— Ground Truth と週次レポート

Dee Kapila「How to use Claude Code as a GTM leader」Growth Unhinged／2026-08-26

https://www.growthunhinged.com/p/how-to-use-claude-code-as-a-gtm-leader

＝Ground Truth（RADチームが人手で保守）／45分→週5分／週約2時間の削減／v67・3四半期以上〔自己申告〕／"For every 20-25 build experiments..."

種類：当事者の自己開示

[S11] Mintlify / Buffer — 少人数チームの運用

「Multiplayer Claude」MKT1 Newsletter／2026-07-27

https://newsletter.mkt1.co/p/multiplayer-claude-1

＝Mintlify（マーケ7名・エンジニアゼロ／Knowledge Engineer が全承認／Signal agent 30分ごと）、Buffer（内部リンク切れ87%削減〔自己申告〕／新スキルは社内専門家がテストしてから全社公開）

種類：当事者の自己開示

[S12] Emily Kramer（MKT1）— 調査制作での手作業検証

「State of Marketing Report Part 3: How to research in Claude Code」MKT1 Newsletter／2026-05-06

https://newsletter.mkt1.co/p/state-of-marketing-report-part-3-how-to-research-in-claude-code

＝100社×90以上のデータポイント／100人分のプロフィールを手作業で目視確認／退職役員の誤出力／"Automation gets you to a starting point..."

種類：当事者の自己開示

2. 日本の活用状況（本文 第1章）

[S14a] 帝国データバンク

「生成AIの活用に関する企業の意識調査」／2026-05-14

https://www.tdb.co.jp/report/economic/20260514-genai/

＝活用34.5%／活用企業のうち86.7%が「効果あり」／課題は情報の正確性50.4%

対象：全国23,349社に調査・10,312社回答（2026年3月17〜31日）／種類：調査

[S14b] 才流

「BtoBマーケティングにおける生成AI活用実態調査」PR TIMES／2025-09-19

https://prtimes.jp/main/html/rd/p/000000023.000022074.html

＝「ときどき活用」41.7%＋「日常的に活用」28.8%／「メンバーの80%以上が日常的に活用している組織」12.2%／外注費削減65.7%

対象：n=600（2025年7〜8月）／種類：調査（BtoBマーケティング支援会社による自社調査）

[S14c] 総務省

『情報通信白書』令和7年版／2025-07

https://www.soumu.go.jp/main_content/001019264.pdf

＝AI活用方針を「明確に定めていない」日本31.8%（米国9.1%／ドイツ12.9%／中国4.2%）

対象：2024年度調査／種類：公的

[S14d] PwC Japan

「生成AIに関する実態調査2025」／2025-06-23

https://www.pwc.com/jp/ja/knowledge/thoughtleadership/generative-ai-survey2025.html

＝活用56%／「期待を上回る効果」を出せている企業の割合は米国・英国のおよそ4分の1の水準（原典は比率で示しており、日本側の実数は非公表）

対象：日本 n=945（売上500億円以上・課長職以上、2025年2月19〜25日）／種類：調査（コンサルティング会社による自社調査）

[S15] 太田翔葵（シャコウ CEO）

note／2026-04-24

https://note.com/shoking_shakou/n/n1cfc6a99a2e2

＝「AIを使っているのに、組織の業務プロセスが何も変わっていない」

種類：個人の見解（1名の見解であり、全国的な傾向を示すものではありません）

3. 自己申告と実測（本文 第1章 1-4）

[S16a] METR — 開発者のAI利用に関するRCT

「Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity」／2025-07-10

https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/

＝n=16、246課題／事前予測「24%速くなる」／実測19%遅い／事後も「20%速くなった」と認識

2025年前半のAIツールと、当該の開発作業の条件での結果です。 マーケティング業務を調べたものではありません。

種類：公的・学術

[S16b] METR — 追跡報告

「Uplift update」／2026-02-24

https://metr.org/blog/2026-02-24-uplift-update/

＝被験者の30〜50%が「AIなしではやりたくない課題を提出しなかった」と回答するなどの選択バイアス。「新しい実験のデータは、現在のAIツールの生産性への効果について信頼できるシグナルを与えていない」。「2026年初頭の開発者は速くなっている可能性が高い」とも述べるが、「選択効果のため、我々のデータはその増加幅についてごく弱い証拠にしかならない」と限定

効果が改善した証明としては使えません。

種類：公的・学術

4. 直接引用

原典で一字一句を確認したもののみ。訳文は Prollect による翻訳です。角括弧は出典番号です。

Ryan Law（Ahrefs）[S1]

"This process works well because it mirrors our existing human editorial process, built from decades of collective content marketing experience."

"My thesis is that small amounts of expert direction provided at the start of the content creation process are vastly more effective than lots of human editing at the end."

※「My thesis is that（私の仮説は）」を含みます。本人が仮説と明示しています

"I could use this process to scale the Ahrefs blog to tens of thousands of articles. I will not."

Si Quan Ong（Ahrefs）[S2]

"But as AI use increased, search performance tended to decline. ... It's that companies often use AI to skip the difficult work and publish more average content."

※冒頭の条件節と末尾を含む完全な形です

"AI slop is content published without enough human understanding, judgement, evidence, or original contribution to justify the reader's attention."

※ "without enough"＝「十分な〜を欠いたまま」。「欠いたまま」と訳すと原文より強くなります

Ron Powell（CircleCI）[S3]

"If something isn't in CLAUDE.md, Claude doesn't know about it."

"The actual decision was 'let's stop pretending we can remember the process and make the process remember itself.'"

"A review process that agrees with everything you write is not a review process, so each of these is built with specific friction."

John Albert（Anthropic）[S8]

"Keep a person on every send."

"Collect the questions your team answers repeatedly ... into a single external-facing document."

※ "external-facing"（外部向け）の限定を含みます

Travis Bryant（Anthropic）[S6]

"Claude builds the what; I do the why."

Adam Ward（Anthropic）[S5]

"You don't need to code, you need to explain"

※本文中の発言ではなく、本人執筆記事の小見出しです

"I still read what goes out, though the system no longer waits for my approval."

（システムはもう私の承認を待たないが、私は出ていくものを今も読んでいる）

Kyle Doherty（Attio）[S9]

"Scoring is a prioritization tool, nothing more."

"Give them good data and let them decide where their hour goes."

Dee Kapila（Fin）[S10]

"For every 20-25 build experiments you'll have one major breakthrough."

Emily Kramer（MKT1）[S12]

"Automation gets you to a starting point; manual verification gets you to the finish line."