「役立つ情報だけでは、読者に選んでもらえない」。BtoBコンテンツを作っていると、こんな悩みが出てくるかもしれません。そこで企業の価値観や開発者の物語を発信することには意味があります。しかし「ノウハウはAIに任せ、熱量を伝えれば独自性になる」と考えると、読者が本当に必要とする正確な情報を軽視しかねません。
この記事では、情報の有用性と、企業がどのような考えで判断しているかを伝える編集スタンスを対立させません。事実・見解・経験を分け、何を公開できるかを確認し、継続可能な発信にする方法を考えます。
有用性と情緒的価値は、どちらか一つを選ぶものではない
例えば「この会社はセキュリティを大切にしています」と語るだけでは、読者が導入条件を評価することはできません。一方、認証と仕様を正確に並べても、なぜその条件を重視するのか、どういう顧客に役立ちたいのかが分からなければ、会社の考え方までは見えてきません。
製品の適用範囲、サポート上の約束、事実としての検証結果を示したうえで、どの価値観で意思決定したかを語る。機能的な情報と発信者の立場は組み合わせられるというのが本記事の立場です。ただし、その組み合わせが必ず売上や指名検索を増やすという一般法則ではありません。
「誰が、どのように、なぜ書いたか」を明らかにする
Google検索セントラルの「Creating helpful, reliable, people-first content」は、情報を評価する際に「誰が」「どのように」「なぜ」作ったのかを自問することを推奨しています。オリジナルな情報、調査、著者の実際の経験や専門性がどう示されているかも論点です。
このガイダンスは「感情のこもった文章なら上位表示される」という公式ではありません。また、実在しない著者像、架空の経歴、経験していない導入案件を、一人称で語ってよいという意味でもありません。匿名・イニシャルの著者を使う場合も、公開できる事実だけで説明します。
「スタンス」は、強い断定ではなく判断の基準
旧稿では、業界の常識を批判し、あえて偏った意見を言い切ることを推奨していました。しかし「私はこう考える」という立場と、「他社は間違っている」「この方法が常に正解」という検証不能な断定は別です。
編集上の立場を示すなら、たとえば「当社は初期費用の安さより、顧客が移行・運用まで見通せることを重視する」と書き、そのために何を公開し、どんな条件では採用を勧めないのかを説明します。対立する立場にも理由があり得ることを明示した方が、読者が比較しやすくなります。
事実・見解・経験を混同しない3列メモ
- 事実：公式仕様、実施したテスト、確認された日付・結果。検証可能な資料と適用範囲を記録
- 見解：何を重視し、どう解釈し、どんな場合にその選択を支持するか。反論や適用限界も残す
- 経験：実際に誰が何を観測したか。公開許諾の範囲と個人・契約情報の扱いを確認
例えば「移行に6か月かかった経験がある」という記事を書く場合、実際の事例の話か、想像上のケースか、一般的なリスクとしての説明かを分けます。数字を示すなら何を起点・終点とし、どんな条件で計測したかを明記します。架空例を実績に見せないことが必要です。
『制作の裏側』を語るときの公開境界
開発やマーケティングの意思決定には、試行錯誤がつきものです。その過程を説明できれば、読者は結論の前提を理解しやすくなるかもしれません。しかし「泥臭いプロセスを全部公開すればブランド資産になる」とは限りません。
- 公開可能な事実：公式に発表済みの仕様・手順・設計思想、許諾のあるデータ
- 要レビュー：顧客が関わる事例、数値、取引先の固有事情、社員の発言
- 公開を避けるもの：権限のない会議録、契約条件、個人情報、実際の顧客を識別できる逸話
- 説明用の架空例：読者へ架空であることを明示し、実際の顧客の証言に装わない
米国FTCのエンドースメントに関するガイドは、広告で紹介する経験や評価が真実に基づき、誤認を招かないようにする原則を扱っています。これは米国の規律であって日本のBtoB事例掲載を一律に判定するものではありませんが、経験談の捏造や出所不明な推薦を避けるための参考になります。
架空例：『生成AI導入で働き方を変える』というコンテンツ
次は編集方針の例で、実際の企業の成果を示すものではありません。企業が生成AIの導入支援について発信するときの構成を考えます。
- 最初に読者へ提供する情報：入力できる情報の範囲、確認体制、適用対象、費用と導入条件
- 立場：「業務をすべて自動化することより、人が根拠を確認できる仕組みを優先する」など、意思決定で重視する原則
- 検証できる根拠：利用するモデル・製品の公開仕様、試験条件、承認された事例
- 反対の立場：自動化率の高さを優先する場合の利点と、選択が変わる条件
- 未確認：すべての業務で同じ効果があるか、長期の運用費用、個社の内部手続き
自分の価値観だけで競合の能力を判断せず、顧客が現実に比較できる材料を整えることが重要です。
物語は『熱量の演出』ではなく経緯の説明
ストーリーテリングは、誰かを悪者にしたり、感動する言葉を増やしたりする技法と同義ではありません。何を見て問題だと考え、どんな選択肢を比べ、なぜその判断に至ったかという経緯を、事実と見解を区別して記述できます。
顧客自身の課題を中心とした記事構成についてはBtoBのストーリーテリング、AI時代の記事に独自情報を加える方法についてはBtoBコンテンツの独自価値で詳しく扱っています。本記事では、発信者の立場を示す際の出典・公開権限・編集責任に焦点を絞ります。
AIは主張の整理に使えるが、体験は作り出させない
AIは見解の整理、反対論点の候補出し、原稿の読みやすさの確認などを支援できます。一方、AIが生成した「ある企業での成功談」は、実際の体験を確認したことにはなりません。
AIに未公開の顧客情報を送る場合は、契約・個人情報・利用規約・社内ルールを確認する必要があります。外部サービスへ入力してよいという承認がないなら、固有情報を含む原文を投入しない選択が必要です。
数値で確認できること、直接は測れないこと
記事公開後、滞在時間、クリック、問い合わせ、指名検索などの変化を観測できる場合があります。ただし、それだけで「共感が生まれた」「信頼が蓄積した」とは直接証明できません。
読者から具体的に何が理解できたか、どの情報が不足していたかを聞く方法もありますが、発言した人が読者全体を代表しているとは限りません。数値と発言と推測を区別し、仮説を見直していきます。
公開前の編集チェック
- 読者が実際に知りたい情報を提供しているか。価値観の話だけになっていないか
- 主張の根拠はどの資料・経験で確認できるか
- 事実と編集者の見解を分けたか。反論や適用条件も記したか
- 許可のない顧客・社員・契約の情報を公開していないか
- 実在しない事例・推薦・発言を作っていないか
- AIの生成した資料名や体験を、そのまま原典・一次体験にしていないか
- 関連記事とテーマの役割が重複していないか
まとめ：役立つ情報と、企業の考え方を両方届ける
読者が求める実務情報と、発信者がなぜその判断を重視するのかという背景は、どちらも伝えられます。強い言い切りや感動的なストーリーを増やすより、検証できる情報と、意見の根拠・限界を示すことから始めましょう。
次の記事では「事実」「見解」「経験」の三列に一度分けてから本文を組み立てると、独自の立場と読者への説明責任を両立しやすくなります。
参考資料・関連する実務記事
- Google検索セントラル：有用で信頼できるユーザー第一のコンテンツ：誰が・どのように・なぜ作ったか、オリジナルな根拠と著者情報を明確にする考え方
- 米国FTC：Endorsements, Influencers, and Reviews：推薦や体験談の正確性に関する米国の実務案内。日本の法令判断を直接示すものではない
- Nielsen Norman Group：Content Standards in Design Systems：編集プロセス、内容の基準、構成要素ごとのルールを整理する資料
- 関連記事：BtoBのストーリーテリング：顧客の状況と判断の伝え方
- 関連記事：BtoB製品選定の不安と判断材料：仕様や契約条件としての価値を確認する
- BtoBマーケティング総合ガイド