BtoBで伝わる情報設計とは?処理流暢性・認知負荷の研究と実務チェック

機能一覧は詳しいのに、問い合わせが増えない。資料を配ったのに「結局何ができる製品なのか」と聞かれる。BtoBでは、情報をたくさん載せることと、顧客が判断できる状態にすることは同じではありません。

考える手掛かりになるのが、心理学の処理流暢性(processing fluency)と、学習・認知の研究で使われる認知負荷(cognitive load)です。ただし、この二つを同じ意味で扱ったり、読みやすい文章なら必ず売上が伸びると飛躍したりしてはいけません。研究で確かめられたことと、BtoBへの応用案を分けて紹介します。

処理流暢性とは――情報を処理しやすい感覚

処理流暢性は、情報を読み、理解し、思い出し、判断する際の処理の容易さにかかわる概念です。流暢に読めるかどうかは、内容の印象や判断に影響する場合があります。

心理学者Daniel M. Oppenheimerの研究「Consequences of erudite vernacular utilized irrespective of necessity」は、不要に複雑な言葉が使われた文章を提示し、書き手の知性に関する評価が下がる条件を実験で示しました。論文は『Applied Cognitive Psychology』第20巻2号(2006年)に掲載されています。

ただし、この実験の結果から言えるのは、特定の課題・参加者・文章条件における印象評価への影響です。「簡単な文章ならどんな相手にも正しく理解される」「文字を減らせば成約する」といった結論ではありません。専門用語が必要な場面もあります。

認知負荷とは――理解と判断に使える処理能力には限界がある

認知負荷の研究は、作業記憶にかかる処理の負担と、学習や問題解決の関係を扱います。John Swellerの1988年論文は、問題解決に多くの処理能力を使うと、概念や解法の構造を学ぶための余力が不足し得ることをモデルと実験から論じました。

認知負荷理論は学習場面の研究から発展したものであり、BtoBサイトでの購買行動すべてを直接説明する理論ではありません。処理流暢性が「処理しやすさの感覚」や判断への影響を扱うのに対して、認知負荷は「理解・学習に必要な処理能力の制約」を検討するものです。両者を混同せず、情報設計の視点として使います。

BtoBサイトの読み手は、同じページで同じ情報を探していない

導入を検討している担当者にも、役割によって必要な情報が異なります。現場担当者は日々の業務がどう変わるかを知りたいかもしれません。情報システム部門は連携仕様や権限設定を、購買部門は費用と契約条件を、決裁者は成果とリスクを確認したいかもしれません。

どの順番が最適かは製品や顧客によって違いますが、すべての情報を一度に押し出すより、主要な問いから詳細へ段階的にアクセスできる構造は一つの候補です。

  • まず対象と課題:誰の、どんな業務課題に向く製品なのか。向かない条件も書く。
  • 次に選択理由:代替手段と比べて何が違い、その違いをどのように検証できるか。
  • 導入の現実:費用、必要な設定、既存システムとの連携、責任分界、運用負荷。
  • 根拠と例外:実績がある条件、未確認の事項、制約、社内説明用の資料。

これはサイト制作の提案であって、OppenheimerやSwellerがこのBtoB導線を直接検証したという意味ではありません。

「機能 → 便益 → 判断材料」に翻訳する

例えば「権限の一括管理機能を搭載」という機能説明だけでは、何が便利で、導入のために何を確認すればよいか分からない場合があります。

  • 機能:権限を一括で設定・変更できる。
  • 便益の仮説:担当者の手作業や設定漏れを減らせる可能性がある。
  • 確認すべき材料:既存のID基盤との接続方式、設定できる権限の範囲、監査ログ、移行時の権限の扱い。
  • 成果の証明:顧客環境での操作時間やエラー率を測定できたなら条件とともに提示する。未検証なら見込みとして区別する。

数字で説明したい場合も、架空の改善率を実績のように書かず、測定方法、対象業務、検証期間、比較条件を明記します。製品の優位性は伝え方だけで成立するわけではありません。

減らすべき情報と、減らしてはいけない情報

情報量を削ること自体を目標にすると、導入判断に欠かせない条件まで省いてしまう危険があります。例えばセキュリティ、個人情報、可用性、契約範囲、価格条件は、見た目を簡潔にするために曖昧にしてはいけません。

代わりに、情報を削除するのではなく整理することを考えます。主要な判断には短い要約を置き、詳細仕様には見出しや目次、参照できる資料、問い合わせ窓口を用意します。実行時に必要な警告や重大な制約は、奥のページだけに隠さず、適切な場面で示すべきです。

「見た目の読みやすさ」と「根拠のある説明」は独立の品質です。とても滑らかに読める文章が、誤情報を伝えている可能性もあります。読みやすさのために根拠を失えば、短期的に印象が良くなっても信頼を損ねかねません。

改善例――一つのサービス紹介ページをどう直すか

架空の業務分析サービスのページに、50機能の一覧、専門略語だけの説明、料金のない「お問い合わせ」ボタンしかないとします。初めての担当者は、どこから読めばよいか分からない可能性があります。

  • 冒頭:対象業務と解決を目指す問題を二、三文で紹介する。
  • 比較:既存の表計算・内製・他社サービスとの選択基準を明記する。
  • 機能詳細:利用頻度が高い業務から整理し、仕様や制約を確認できるようにする。
  • 導入条件:必要なデータ、権限、運用担当、費用の考え方を示す。
  • 次の行動:まず仕様を確認したい人と、相談したい人に別の自然な導線を用意する。

この例は説明のための仮想設計です。現実の成果を示す事例ではありません。

改善が本当に効いたか、何を測ればよいか

「わかりやすくした」だけで終了せず、公開後の利用者の反応を確認します。スクロール率や滞在時間の増減だけでは、理解が深まったとも、困惑したとも断定できません。

  • 理解:初見の読み手が対象顧客と主要な価値を自分の言葉で説明できるか。
  • 探索:想定した利用者が価格、導入条件、セキュリティ情報を迷わず見つけられるか。
  • 判断:社内比較に必要な条件が欠けていないか。相談の際に繰り返される質問は何か。
  • 副作用:説明を簡潔にした結果、誤解や導入後の期待違いが増えていないか。

小さなユーザーテストで疑問点を確認し、ページの変更前後で比較できる状態を作ると、表面的な「読みやすさ」の自己評価より学びが増えます。測定値の変化は季節性や流入経路にも左右されるため、効果の断定は慎重に行います。

AIには要約だけでなく「誤解される点」を探させる

生成AIを使うなら、文章を短くするだけでなく、受け手に必要な前提、曖昧な語、説明の飛躍、根拠の不足を洗い出す用途が考えられます。例えば、非技術職と情報システム担当の二つの立場で「何が不明か」を整理させ、人が実際の顧客との違いを確認します。

ただしAIが分かりやすいと判定しても、実際の顧客が理解した証拠にはなりません。事実確認とユーザーテストは別に必要です。顧客の選択理由を設計する視点はBtoBの差別化でも扱います。

まとめ――伝える情報を減らすより、判断の順番を設計する

処理流暢性の研究は、不要な複雑さが情報の受け取り方に影響し得ることを示しています。認知負荷の研究は、学習や問題解決で処理能力が制約になることを示してきました。どちらも「短い文章ほど正しく、売れる」と保証するものではありません。

BtoBに応用するなら、顧客の問いに沿って情報の順番を設計し、重要な条件は隠さず、根拠と例外に到達できるようにすることです。技術的な複雑さをなかったことにせず、相手が適切な判断をするための複雑さへ整理することを目指します。

参考資料と検証範囲

ほかの記事を探す

記事の訂正・出典情報は、お問い合わせから該当記事のURLと根拠資料をお知らせください。