自社でメディア（お役立ち記事のサイト）を運営していると、多くの会社がある壁にぶつかります。「記事は読まれている。なのに、問い合わせにつながらない」——アクセスはあるのに、成果に変わらない状態です。私たちも同じ壁にぶつかりました。
そして出した答えは、記事の質をさらに上げることではなく、サイトの中の“つなぎ方”（導線）を構造から設計し直すことでした。この記事では、その判断に至った経緯と、実装で最も効いた設計判断——記事側に手を入れず、既存の category からハブ（テーマのまとまり）を導出した話を、実装した立場から記録します。
筆者（馬込）は、この自社メディアの回遊構造を実際に設計・実装しました。派手な施策ではなく、地味な情報設計の連続でしたが、「良い記事を書く」だけでは埋まらない溝が確かにあり、それを構造で埋めた過程は、同じ壁に当たっている方の参考になると思います。この導線設計を含め、自社のSEOメディアを13ヶ月かけて外注せず内製で立ち上げた全体像は自社SEOメディアを13ヶ月・内製で立ち上げた記録にまとめています。
「記事は読まれるのに問い合わせが来ない」という壁
メディアを始めた頃、私たちのなかにも「良い記事さえ書けば、読者が自然に問い合わせしてくれるはず」という思い込みがありました。けれど現実はそう甘くありませんでした。
記事を読んだ人の多くは、読み終えるとそのまま静かに去っていきます。理由はシンプルで、「次にどこを見ればいいか」が示されていないからです。記事は読者の悩みには答えます。でもそれだけでは「では相談してみよう」という次の行動には、なかなかつながりません。良い記事と問い合わせの間には、渡し損ねている“橋”がある——これが最初の、そして肝心な気づきでした。
記事を1本ずつ良くするのではなく「導線を構造で作る」
そこで私たちは、記事を1本ずつ良くするのではなく、「記事を読んだ人が次にどこへ進むか」という道そのものを、サイトの構造として作り直すことにしました。考え方はこうです。
- 記事の中で、関連する別の記事へ自然につなぐ
- その記事のテーマに合った相談窓口へ、文脈に沿って案内する
- 記事を「テーマのまとまり（ハブ）」で束ね、その中を回遊させる
大事にしたのは、読者を無理に引っぱるのではなく、**「今読んでいる内容の、自然な次の一歩」**を、さりげなく置いておくことです。一つひとつは小さな工夫ですが、この積み重ねで「読んで終わり」だった人が「もう少し読む」「相談する」へ進みやすくなります。
ハブを新フィールドにせず、既存categoryから導出した設計判断
ここが実装で最も効いた判断です。「テーマのまとまり＝ハブ」で回遊させると決めたとき、素直な実装は、記事のメタデータに hub という項目を新しく足すことでした。ですが、これは採りませんでした。
理由をトレードオフで整理すると、判断の軸が見えます。
| 観点 | ハブを新フィールドで持つ | categoryから導出（今回） |
|---|---|---|
| 既存記事の修正 | 全記事に hub を追記 |
不要（記事側は無変更） |
| 概念の重複 | category と hub が二重に存在 |
1箇所（ハブ定義）で対応づけ |
| IAの変更 | 全記事を触る | 対応表を編集するだけ |
| 事故のリスク | 片方だけ更新される | 一元管理で起きにくい |
category は記事の実体に近い細かい単位、hub はIA上の粗い単位です。両者を1箇所で対応づければ、記事側は無変更のままIAを載せ替えられます。導出そのものは、素直に書けます。
// category から hub を導出する（記事側は category だけ持てばよい）
export function hubForCategory(category: string): Hub {
for (const h of HUBS) {
if (h.categories.includes(category)) return h.id
}
return "select" // 未知カテゴリは汎用ハブに寄せ、一覧が壊れないようにする
}
未知の category をエラーにせず汎用ハブへ寄せているのは、記事側の入力ミスや新カテゴリ追加で一覧が壊れないほうが運用上は安全だからです。厳密さより、落ちないことを取りました。「記事に持たせる情報」と「IA側で導出する情報」を分ける——この原則は、他の設計にも応用が効きました。記事に直接 hub を持たせていたら、IAを変えるたびに全記事を触ることになっていたはずです。
実際、この設計のおかげで、後から新しいテーマの区分を足すときも、記事を1本も触らずに対応表を1行増やすだけで済みました。導出にしておけば、IAは実装側の関心事として閉じられます。厳密に固定するより、落ちない・変えやすいことを優先した判断です。
ハブ導出には、もう一つ効いた使い道がありました。関連記事の選び方です。素朴に新着順で関連記事を出すと、「開発体制」の記事を読んだ人に「生成AI」の記事を薦めるようなことが起きます。読者の関心から外れた提案は、回遊ではなく離脱を招きます。そこで関連記事を、同じハブ内から優先的に選ぶように変えました。当たり前に聞こえますが、「関連記事がある」ことと「回遊が起きる」ことは別でした。ハブという軸を1つ持って初めて、「関連」を意味のある形で定義できるようになった、という順番です。一覧・関連記事・相談窓口の出し分けが、すべて同じ導出の上で揃う——ここがハブ導出の効きどころでした。
やりすぎない——導線は「数」より「文脈」
導線づくりには、はっきりした注意点が一つあります。つなぎを増やしすぎ、誘導が強すぎると、かえって読者は離れていくことです。
記事のあちこちに「お問い合わせはこちら」を貼り、関連リンクを大量に詰め込む——これは「読者のための次の一歩」ではなく「こちらの都合の押しつけ」になります。読者は宣伝の気配に驚くほど敏感で、押しが強いと感じた瞬間に去ります。目指すのは、あくまで読んでいる内容の自然な延長として、次の一歩がそっと置かれている状態です。導線は「数を増やす」より「文脈に合っているか」で判断する——ここは今も調整を続けています。
そして効果は、感覚ではなく数字で確かめる必要があります。どの記事から相談につながっているか、どのページで離脱しているか。これが見えていないと、「良かれと思って作った導線」が実は機能していない、というズレに気づけません。導線設計は一度作って終わりではなく、確かめて直しての繰り返しです。計測の考え方は「開発生産性の測り方と改善の始め方」の姿勢とも通じます。
TechMateのメディア・開発設計支援
私たちTechMateは、こうしたメディアと開発の設計を、月単位の準委任でまとめて伴走しています。導線の構造設計から実装・計測まで手を動かして並走します。メディアや開発体制の相談はこちらからどうぞ。
よくある質問
Q. 記事数が少ないうちから導線を設計すべきですか？ A. 全記事に一気に張るより、まず読者が多く読んでいる記事から整えるのが現実的です。効果の出やすいところから直すほうが手応えを確かめやすく、続けやすい。限られた人手で回すなら、この「効くところから」という順序づけが思っている以上に効きます。狭く始めて広げるほうが、結局は遠くまで進めました。
Q. ハブ（テーマのまとまり）は、いくつくらいに分けるべきですか？ A. 数の正解はありませんが、読者が迷わない程度に粗く、が目安です。細かく分けすぎると「どこを見ればいいか」がかえって分からなくなります。私たちは大きなテーマで束ね、記事が増えても迷子になりにくい状態を優先しました。「この分野のことがここにまとまっている」という体系としての信頼も、副次的に生まれます。
Q. 導線を増やしたのに問い合わせが増えないときは、何を見ればいいですか？ A. まず「導線が機能しているか」を数字で確認してください。クリックされているのに問い合わせに至らないなら、送り先（相談窓口）の側に問題があるかもしれません。そもそもクリックされていないなら、置き場所や文脈が合っていない可能性があります。感覚で足すのではなく、どこで止まっているかを見てから直すのが近道です。
「記事は読まれるのに問い合わせが来ない」とき、原因は記事の質そのものではなく、記事から次の行動への“つなぎ”が設計されていないことにあるのかもしれません。関連記事へ、相談窓口へ、テーマのまとまりへ——読者の自然な次の一歩を用意し、それが効いているかを数字で確かめ続ける。そして実装では、記事に情報を足すのではなく、既存の情報から導出する。この地道な設計が、メディアを成果につなげる土台になると考えています。
自社メディアで同じ壁に当たっている方は、記事を増やす前に「つなぎ」を見直してみてください。メディア・開発設計のご相談から、お気軽にお問い合わせください。