広報、SNS投稿係だけではもったいない――検索・口コミ・ツール・研究・Botまで「人が来る仕組み」140案

広報を「新記事をSNSに投稿する仕事」だと思うと、かなり早い段階で限界が来る。料理を作るたびに厨房から皿を窓の外へ投げて、「誰か拾って店に来ないかな」と祈っているようなものだ。本当に強い集客は、検索される、推薦される、共有される、引用される、埋め込まれる、使われる、購読される、そして読者が次の読者を連れてくる、という複数の循環を同時に持つ。

0. 広報は「チャネル一覧」ではなく「流通の設計図」で考える

Googleも、検索だけを狙った量産ではなく、人に役立つ独自情報・分析・体験を重視し、検索される語を適切な場所に置き、クロール可能なリンクを作り、関連コミュニティでサイトを知らせることを基本としている。 つまりSEO、SNS、紹介、メールは別部署ではない。すべて「価値あるものを、必要な人が見つけ、使い、次の人へ渡せる状態」にする一つのDistribution Systemである。以下は、そのための140案を14群に整理したものだ。

1. 検索・アルゴリズム発見：まず「探している人」に拾われる

検索は一度当たると長く効く。新記事量産より、発見・内部リンク・既存表示の改善を閉ループにする。

1. 検索語フィードバック — Search Consoleで実際に表示された語をタイトル・見出し・導入改善へ戻す。
2. サイトマップ健全性 — 公開・更新・削除をサイトマップへ正確に反映し、発見経路を壊さない。
3. 孤立記事ゼロ — 新記事から旧記事だけでなく、関連する旧記事から新記事へも被リンクを作る。
4. Discover向け大画像 — 伸びそうな記事だけ高品質な大画像と適切なプレビュー設定を用意する。
5. 画像検索用図解 — 比較表、意思決定木、フローチャートを画像単体でも役立つ形にする。
6. 動画検索面 — 人気記事だけ短い動画や解説動画へ変換し、動画検索の入口を増やす。
7. Dataset Search — 独自データをDataset構造化データ、CSV、説明ページで検索可能にする。
8. IndexNow — 追加・更新・削除URLを対応検索エンジンへ即通知する。
9. 地域検索エンジン — 韓国語ならNaverなど、localeごとの主要検索面を別監視する。
10. 季節・再燃検知 — 過去記事の検索需要が戻ったら更新・再配信し、死蔵を防ぐ。

2. 読者紹介・口コミ：1人の読者を「次の入口」にする

「シェアしてください」より「誰に送りたい？」の方が自然だ。読者を宣伝係にするのではなく、相手へ情報を渡しやすくする。

1. OS共有ボタン — Web Share APIなどでスマホの共有シートを1タップで開く。
2. リンクコピー — PCでも迷わず使える最小の共有手段を常設する。
3. 引用共有 — 選択した一節＋URLをそのまま共有できるようにする。
4. 引用画像カード — 一文や図表をSNS向け画像に変換する。
5. 記事ギフト束 — 「転職する友達へ5本」など複数記事を1URLで渡す。
6. 読者コレクション — 読者自身が公開読書リストを作り共有できるようにする。
7. 紹介リンク — 共有元をプライバシーに配慮して計測できるreferral URLを発行する。
8. 購読者紹介制度 — 紹介人数に応じて特典を出す。Substackにも同種の仕組みがある。
9. 越境共有 — 相手の言語版があれば同一記事の適切なlocaleへ送る。
10. QR・対面共有 — スマホ同士、資料、イベント、紙からWebへ戻せる入口を作る。

3. 自前の読者基盤：アルゴリズムに毎回レンタル料を払わない

検索やSNSは借り物の道路。メール、Feed、通知、フォローは自前の帰り道になる。

1. メールニュースレター — 全新着ではなく、週次やテーマ別で本当に読む価値があるものだけ送る。
2. トピックFollow — AI、仕事、暮らしなど興味カテゴリ単位で購読できるようにする。
3. 保存検索 — 検索条件に合う新記事が出た時だけ知らせる。
4. ブラウザ通知 — 明示opt-inかつ低頻度で、重要更新だけ通知する。
5. メッセージング購読 — LINE、Kakao、WhatsApp、Telegram等を地域に応じて使う。LINEはnarrowcastも提供する。
6. RSS・Atom・JSON Feed — 人間のFeed readerと機械の両方に配信できる出口を持つ。
7. WebSub — Feed更新をhub経由で購読者へPushする標準を使う。
8. ActivityPub — サイト自体をFediverseでフォロー可能な発行主体にする。
9. Webmention — 他サイトから言及・返信されたことをWeb同士で受け取る。
10. カレンダー・更新Watch — 制度締切、料金変更、記事更新などを必要な人だけ購読できるようにする。

4. SNS・コミュニティ・外部面：投稿先ではなく「別の発見市場」として使う

SNSを増やす目的はアカウント数ではない。それぞれの場所にしかいない読者と、その場所固有の推薦面を借りることだ。

1. Bluesky通常投稿 — 記事の要点とURLを自然な短文で配る。
2. Bluesky Custom Feed — 自分の記事だけでなくテーマ全体の良質投稿を集める面を作る。
3. Bluesky Starter Pack — 関連アカウントやFeedをまとめ、コミュニティ入口そのものを配る。
4. Reddit回答型配信 — 宣伝投稿ではなく、質問へ完全回答し必要な時だけ記事を補足する。
5. Hacker News・技術コミュニティ — AIや実装記事は「作ったもの」「検証したもの」として出す。
6. LinkedIn Newsletter — 仕事・AI・組織記事をLinkedIn内部の購読面へ載せる。
7. Medium再配信 — 上位記事だけcanonicalを元サイトへ向けて再掲載する。
8. Hashnode・DEV系 — 技術記事だけを開発者コミュニティへ選択配信する。
9. Pinterest・Flipboard — 図解、Article Pin、RSSなど長寿命の発見面へ変換する。
10. Product Hunt・GitHub・Hugging Face・Kaggle — 記事ではなくツール、OSS、Dataset、デモとして別市場へ出す。

5. 記事以外を入口にする：便利なら、人は「読む前」に来る

最強の記事宣伝は、記事を宣伝しなくても人が来る道具を持つことかもしれない。

1. 計算機 — 年収差、費用、時間、複利など検索需要のある計算を無料化する。
2. 診断 — 属人化度、意思決定傾向など結果が次の解説記事につながる診断を作る。
3. 意思決定木 — 質問に答えると読むべき記事や次の行動候補へ進める。
4. 比較セレクター — A/B/Cを選ぶと比較軸と関連解説を出す。
5. テンプレート — 会議、1on1、比較表、メール、チェックリストをそのまま使える形で配る。
6. チェックリスト — 「10項目中7つ」など自己点検から深掘り記事へつなげる。
7. 用語集 — 専門語の短い定義を入口にして関連する長文へ送る。
8. FAQ・Q&Aデータベース — 1質問1回答を蓄積し、長文記事への検索入口にする。
9. 事例・失敗DB — 成功談だけでなく、どこで失敗したかを構造化して検索可能にする。
10. 価格・仕様履歴DB — サービス料金や仕様変更を時系列で追い、定期的に戻る理由を作る。

6. データ・研究・引用：引用される側に回る

他人の記事を引用するだけでは流入は片道だ。独自データを作ると、記者・研究者・ブロガー・AI回答から逆向きのリンクが生まれる。

1. 独自Dataset — 匿名化・集計した実データをCSV/JSONで公開する。
2. Benchmark — 自分の数値を平均や分布と比較できる基準値を作る。
3. 年次・月次レポート — 変化が蓄積するテーマを定点観測する。
4. 独自Index — 複数指標をまとめた指数を透明な計算方法付きで公開する。
5. Trend Dashboard — 更新され続ける可視化ページを持つ。
6. CSVダウンロード — グラフだけでなく再分析できる元データを渡す。
7. SVG・図表配布 — 他メディアが引用しやすい高品質図表を用意する。
8. DOI・Zenodo — 研究成果として残す価値があるものだけ永続識別子を付ける。
9. BibTeX・RIS・CITATION — 正しく引用できる形式を1クリックで出す。
10. 方法論・再現パック — 収集方法、限界、コード、versionを公開し、信頼性を上げる。Crossrefのようなmetadata流通も研究成果の発見性を支える。

7. 埋め込み・API・Bot：他人のサイトや仕事を自分の入口にする

人を毎回トップページへ呼ぶのではなく、相手が普段使う場所へ機能を貸す。

1. oEmbed対応 — URLを貼るだけで整った記事カードを外部サービスに表示できるようにする。
2. 埋め込みWidget — ランキング、診断、表などを他サイトへ貸し出す。
3. 埋め込み計算機 — 便利ツールをiframe等で提供し、Powered byで戻り道を作る。
4. 自動更新グラフ — 引用先に置かれた図も元データ更新に追従させる。
5. 公開API — 検索、ランキング、Datasetなどを外部アプリが利用できるようにする。
6. MCP・ChatGPTアプリ — 会話から記事DBや独自データを検索できる入口を作る。
7. Slack Bot — 職場で質問すると関連記事や短い答えを返す。
8. Teams・Discord Bot — チームやコミュニティの会話内に検索を常駐させる。
9. ブラウザ拡張 — 選択文字を右クリックして関連解説を探せるようにする。
10. Notion・Obsidian・Raycast等の連携 — 知識管理やランチャーの中に保存・検索機能を置く。

8. 提携・Earned Media：他人の読者基盤を借りる

広告費より強いのは、相手にも価値があるため相手自身が紹介したくなる状態だ。

1. Creator共同企画 — 同じテーマを別視点で作り、双方のaudienceへ届ける。
2. ニュースレターSwap — 読者層が近い媒体同士で推薦枠を交換する。
3. 媒体間Recommendation — Substackのように良い外部媒体を推薦し合う仕組みを参考にする。
4. Expert Roundup — 複数専門家の短い見解を集め、参加者にも共有しやすくする。
5. 共同調査 — 他媒体・団体とSurveyやDatasetを作る。
6. 記者向けData Room — 数字、図表、方法論、引用文、連絡先を1ページにまとめる。
7. ニュース性がある時だけPress Release — 単なる新記事公開をニュース扱いしない。
8. 地方紙・専門媒体Pitch — 全国向けで弱い話でも、地域・業界特化なら強いことがある。
9. Vendor共同マーケティング — 比較・検証で扱った企業に再利用可能な図表や事例を渡す。
10. ライセンス・Syndication Feed — 条件を明示し、他媒体が合法的に要約・転載・Feed取得できるようにする。

9. B2B・教育：1人の読者から100人へ配られる資料を作る

人事担当1人が社内100人へ配る資料は、100回のSNSクリックより強いことがある。

1. 新人研修パック — テーマ記事、チェックリスト、演習を1セットにする。
2. 管理職研修パック — フィードバック、属人化、権限などをケース教材化する。
3. 人事Resource Hub — 採用・離職・Engagementの資料を職務別にまとめる。
4. AI利用Playbook — 導入、評価、リスク、使い分けを現場向けにまとめる。
5. Team Reading List — チームで共通認識を作るための5本セットを作る。
6. 社内ポータルFeed — IntranetへRSSやAPIで新着・更新を供給する。
7. LMSミニコース — 記事を短い学習順序、問い、確認問題に変換する。
8. 教師用Worksheet — 授業で使える問い、資料、回答ガイドを用意する。
9. 大学向け引用・Syllabus支援 — 恒久URL、版、引用形式、Reading Listを整える。
10. 図書館・Repository連携 — 研究成果なら標準metadataやrepository連携を検討する。

10. 形式を増やす：1つの原料を複数市場へ

記事を12回書く必要はない。同じ核を、その面で消費しやすい形式へ変える。

1. 音声記事・Podcast — Article PlayerやTTSをPodcast RSSへ接続する。
2. YouTube Podcast RSS — 対象地域ではRSSから静止画動画を自動生成できる。
3. Short動画 — 伸びた記事だけ30〜60秒の縦動画へ変える。
4. スライド — 講義・社内共有向けに10枚程度へ圧縮する。
5. PDF 1枚版 — 決裁者・先生・同僚へ転送しやすい要約を作る。
6. 電子書籍 — 同テーマの記事群を章構成に再編集する。
7. Infographic — 一枚で完結する図解を配布・転載しやすくする。
8. Interactive Quiz — 読む前に答えさせ、結果から本文へ導く。
9. Webinar・AMA — 一度のライブを録画、FAQ、記事へ分解して再利用する。
10. 印刷物＋QR — 紙だけで完結させず、更新可能なWebへ戻る導線を入れる。

11. 参加・ゲーム的ループ：読者を観客だけにしない

毎日起動を強制する必要はない。参加した結果、もう一度見たくなる仕掛けだけ使う。

1. 先に投票 — 研究結果を見る前に自分の予想を選ぶ。
2. 予測と実測比較 — 自分の見立てと実データの差を見る。
3. 読了進捗 — シリーズの何本を読んだかを可視化する。
4. Learning Path — 初級→中級→応用の順番を提示する。
5. 今日・今週の1本 — 選択肢を減らし、再訪理由を作る。
6. 年末Wrapped — 自分が読んだテーマや傾向を振り返れるようにする。
7. 役立った投票 — 星評価より「役に立った/足りなかった」を編集feedbackにする。
8. 質問→次記事 — コメントや検索0件をそのまま記事候補へ変換する。
9. 公開Roadmap投票 — 次に何を調べてほしいか読者が選べるようにする。
10. 共同目標 — 回答100件で集計公開など、参加が新しいコンテンツを生む形にする。

12. 計測・Growth OS：何が効いたか分からない広報を卒業する

全部に投稿してPVだけ見ると、何が増分だったか分からない。配信自体を実験系にする。

1. source×locale計測 — 流入元と言語を最低単位として追う。
2. Share→Landing→Read — 共有回数ではなく、紹介先の読了までつなげて測る。
3. 紹介係数 — 1読者が平均何人の新読者を連れてくるかを見る。
4. Content Lifecycle — 新着、成長、成熟、再燃、死蔵を分類する。
5. Bandit配分 — 複数見出し・面へ少量配り、反応が良い所へ追加配分する。
6. Holdout — 一部を意図的に配信しない群にして、増分効果を測る。
7. Locale勝者移植 — ある言語で当たったテーマを他localeへ優先展開する。
8. サイト内検索0件回収 — 探されたのに無かった問いを次の企画へ回す。
9. Copy・Scroll停止分析 — よくコピーされる文や長く止まる箇所を共有素材へ昇格する。
10. 飽和・Cooldown — 同じ読者へ配り過ぎたら自動で頻度を下げる。

13. 広告・アフィリエイトを「需要調査装置」にする

広告は買い続けるだけでなく、まだデータがない時に安く学ぶ実験装置として使える。

1. 検索広告Demand Probe — 少額で検索語や見出しの反応を見てSEOへ返す。
2. Creative A/B — 同じ記事を複数コピー・画像で小さく試す。
3. 地域Demand Probe — 国・地域別に反応差を見て優先localeを決める。
4. Qualified Retargeting — 50%読了など価値を受け取った人へだけ次の記事を案内する。
5. Micro Creator協賛 — 大物1人より専門性の高い小規模Creatorを複数試す。
6. Newsletter協賛 — 読者属性が明確なニッチ媒体を選ぶ。
7. Contextual広告 — 追跡依存より、内容との文脈一致を重視する。
8. Affiliate EPC feedback — 収益額だけでなく、どの読者課題が行動につながったかを編集へ戻す。
9. Vendor Resource獲得 — 紹介企業にデータや図表を渡し、公式Resources等から自然な言及を狙う。
10. 編集独立のSponsored Research — 費用提供と結論を分離し、方法・利害関係を明示する。

14. locale別流通：12言語を「同じSNSの翻訳版」にしない

言語が同じでも市場は違う。enを米国1市場、esをスペイン1市場として扱うと取りこぼす。

1. 検索面をlocale別に選ぶ — Googleだけでなく、地域で実際に使われる検索面を確認する。
2. 日本・台湾・タイのLINE — 公式要件と同意を守り、メッセージング購読を使う。
3. 韓国のKakao — Channel等の現地導線を実装時に公式仕様で確認する。
4. 韓国のNaver — Sitemap・RSS等をGoogleとは別に監視する。
5. 中国語簡体の現地面 — WeChat、Weibo等は本人・法人・規制要件を個別確認し、他localeの延長で自動化しない。
6. ベトナムの現地面 — Zalo等は実装時点の公式API・アカウント条件を再確認する。
7. WhatsApp中心市場 — ブラジル、インドネシア、スペイン語圏などで共有・Channel候補として検証する。
8. 同一言語の市場分割 — enは米英印豪等、esは中南米とスペイン、fr/deも地域別需要を見る。
9. 現地発テーマ — 日本語で当たった記事の翻訳だけでなく、その市場固有の問いを発芽させる。
10. 逆輸入 — 海外localeで先に当たったテーマを日本語や他言語へ戻す。

15. 今の段階なら、何からやるべきか

優先順位は「新しいSNSをもう10個作る」ではない。まず P0: Share/引用共有、孤立記事ゼロ、source×locale計測、共有→読了計測、Free Toolを1つ、独自Data Reportを1つ、画像/図解面の強化、Podcast RSS、locale固有の検索・メッセージング導線、Holdout実験。次に P1: Bluesky Feed/Starter Pack、Medium/Hashnode等の選択再配信、Dataset/DOI、Bot/API、B2B研修パック、WebSub/ActivityPub/Webmention。最後に P2: ブラウザ拡張、White-label Widget、複数Marketplace、複雑なGamification。基準は「面白そう」ではなく、既存コンテンツを再利用でき、計測でき、勝てば自動で拡張できるかである。

16. やらない方がいい広報

避けたいのは、①計測前にSNSアカウントだけ増やす、②大量自動Follow/Like/Replyで人間関係をスパム化する、③検索語の組合せだけで薄いページを量産する、④存在しないUGCや専門家評価を捏造する、⑤同じ本文をcanonical無しで各所へ全文転載する、⑥全localeへ同じ媒体・同じ時刻・同じ投稿文を押し込む、⑦PVだけ見て「成功」とする、⑧広告流入を自然需要と混同する、⑨通知やGamificationで不必要に不安・依存を煽る、⑩全記事を全チャネルへ流して読者を飽和させる、である。自動化はアクセルであり、スパム砲ではない。

17. 結論：広報は「SNS担当」ではなくDistribution Engineeringである

完成形は、Own audience（メール・Feed・メッセージング）、Borrowed audience（検索・SNS・Community）、Embedded audience（Widget・Bot・API・教材）、Earned audience（口コミ・引用・報道・被リンク）、Algorithmic audience（検索・推薦）、Recursive audience（読者が次の読者を連れてくる）を同時に持つことだ。記事を140通り宣伝するのではない。1つの価値ある原料を、各Surfaceが欲しい形式に変換し、結果を計測し、勝った経路へ次の配信を寄せる。広報部が「投稿しました！」で仕事を終える世界から、記事が自分で道路を増やしていく世界へ進む。

参考資料

• Google Search Central「有用で信頼性の高い、ユーザーを第一に考えたコンテンツの作成」: https://developers.google.com/search/docs/fundamentals/creating-helpful-content
• Google Search Central「Search Essentials」: https://developers.google.com/search/docs/essentials
• IndexNow 公式ドキュメント: https://www.indexnow.org/documentation
• Substack「Subscriber referrals」: https://support.substack.com/hc/en-us/articles/16142857300372-What-are-subscriber-referrals-on-Substack
• Substack「Recommendations」: https://support.substack.com/hc/en-us/articles/5036794583828-How-can-I-recommend-other-publications-on-Substack
• Bluesky「Starter Packs」: https://bsky.social/about/blog/06-26-2024-starter-packs
• Bluesky「Custom Feeds」: https://bsky.social/about/blog/7-27-2023-custom-feeds
• Medium「Canonical link」: https://help.medium.com/hc/en-us/articles/360033930293-Set-a-canonical-link
• Pinterest「Article Pins」: https://developers.pinterest.com/docs/web-features/article-rich-pins/
• LinkedIn「Newsletters」: https://www.linkedin.com/help/linkedin/answer/a522525
• YouTube「RSSフィードを使用してポッドキャストを配信」: https://support.google.com/youtube/answer/13525207?hl=ja
• Google Search Central「Dataset structured data」: https://developers.google.com/search/docs/appearance/structured-data/dataset
• LINE Messaging API: https://developers.line.biz/en/reference/messaging-api/nojs/
• Naver Search Advisor「RSS・サイトマップ提出」: https://searchadvisor.naver.com/guide/request-feed
• W3C ActivityPub: https://www.w3.org/TR/activitypub/
• W3C WebSub: https://www.w3.org/TR/websub/
• W3C Webmention: https://www.w3.org/TR/webmention/
• Zenodo「DOI」: https://help.zenodo.org/docs/deposit/describe-records/reserve-doi/
• Crossref「Register and maintain your records」: https://www.crossref.org/documentation/register-maintain-records/