機能・コンテンツマップで記事企画を効率化する — プロダクト機能から逆引きする方法

はじめに — 「次に何を書くか」が決まらない問題

ブログを運営していると、遅かれ早かれ直面する問題があります。

「何を書けばいいのかわからない」

ZERONOVA Focus のブログを始めた当初、この問題に悩みました。記事のネタ自体はあるのですが、「どの順番で」「どの切り口で」書くべきかが定まらない。結果として、思いついたトピックを場当たり的に書く状態になっていました。

これでは SEO 効果も限定的で、記事からプロダクトへの導線（CVR）も弱くなります。そこで考えたのが「機能・コンテンツマップ」というアプローチでした。

背景 — プロダクトの記事は「機能」から逆引きできる

2026年1月28日の開発日記にはこう書いています：

機能・コンテンツマップ: プロダクトの機能と記事を紐づけることで、SEO と CVR を両立させたい

• ユーザーが「課題」で検索 → 記事がヒット → 記事内でプロダクトを紹介 → CVR

この発想の出発点は単純です。プロダクトには機能がある。機能は「誰かの課題」を解決するために作られている。その「課題」で検索するユーザーがいる。なら、課題にフォーカスした記事を書けば、検索流入からプロダクトへの導線ができるはずです。

従来の記事企画は「書けそうなネタ」から出発していました。機能・コンテンツマップは「プロダクトの機能」から出発して、記事を逆引きします。

機能・コンテンツマップとは

機能・コンテンツマップは、プロダクトの機能一覧と、それに対応する記事を一覧化したドキュメントです。

構造

機能A → ターゲット課題 → 記事タイトル案 → ステータス
機能B → ターゲット課題 → 記事タイトル案 → ステータス
機能C → ターゲット課題 → 記事タイトル案 → ステータス

具体的には、以下のような表になります：

従来の方法との違い

実践 — IdeaSpool での適用

最初に機能・コンテンツマップを作ったのは IdeaSpool（AI搭載アイデア管理ツール）です。

開発日記にはこう書いています：

IdeaSpool 機能・コンテンツマップを作成

• 12 機能（当時）と対応記事の整理

IdeaSpool の12機能を洗い出し、それぞれに「このツールがなかったらユーザーはどう困っているか」を考えました。例えば：

• AI タグ自動分類 → 「アイデアの分類が面倒」→ 「アイデアの分類・タグ付けをAIで自動化する方法」
• AI フレームワーク分析 → 「アイデアの評価方法がわからない」→ 「アイデアを体系的に分析する7つのフレームワーク活用法」
• AI ペルソナ評価 → 「誰に刺さるかわからない」→ 「ターゲットユーザーの視点でアイデアを評価する方法」

これにより、IdeaSpool だけで16本の記事タイトル案が生まれました。「何を書くか」で悩む時間がほぼなくなりました。

粒度の問題 — 機能単位かユースケース単位か

マップを作る際に悩んだのは粒度です。

機能・コンテンツマップの粒度

• 機能単位か、ユースケース単位か
• 最終的に機能単位で整理し、ユースケースは記事企画時に検討

機能単位だと「AIタグ分類 → 1記事」のように対応がシンプルになります。ユースケース単位だと「エンジニアがコーディング中にアイデアを記録する → 1記事」のようにペルソナ別に細分化できます。

この粒度の問題について、Claude Code と議論しました。

Zeronova

機能・コンテンツマップの粒度で迷っている。機能単位で整理するか、ユースケース単位で細分化するか。ユースケース単位の方がSEO的にはターゲットが絞れそうだけど、マップが膨大になりそう。

Claude Code

マップの目的は「俯瞰的に抜け漏れを確認する」ことなので、まず機能単位で整理する方がおすすめです。1機能に複数のユースケースが紐づくケースが多いので、ユースケース単位だとマップの管理自体が負担になります。ユースケースの切り口は、実際に記事を書く段階で検討する方が柔軟性があります。

Zeronova

確かに、IdeaSpool の12機能をユースケース単位にすると50行を超えそうだ。マップは機能単位で俯瞰し、記事企画時にペルソナ別の切り口を考える2段階方式にしよう。

この判断は正解でした。機能単位のマップはA4で1ページに収まり、「どの機能に記事がまだないか」が一目で把握できます。ユースケースの検討は記事を書くときに行うことで、マップの維持コストを低く保てています。

優先順位の決め方

すべての機能に記事を書くのは現実的ではありません。優先順位をつける必要があります。

開発日記にはこう書いています：

記事の優先順位付け

• 検索ボリュームと記事の書きやすさのバランス
• まずは書きやすいものから着手

実践的に使っている基準はこの3つです：

1. 検索需要

「フリーランス 請求書 効率化」のようなキーワードは検索ボリュームが見込めます。一方、「AIペルソナ比較分析」のような用語は検索する人が少ない可能性があります。

Google のサジェストや「他の人はこちらも検索」で、実際にユーザーが使っているキーワードを確認します。

2. 記事の書きやすさ

その機能について深い知見があるか。開発日記に具体的なエピソードがあるか。書きやすい記事から着手する方が、モメンタムが生まれます。

3. プロダクトの成熟度

リリース済みの機能に対応する記事を優先します。開発中の機能の記事を先に書くと、仕様変更で記事の修正が必要になるリスクがあります。

テンプレートの設計

機能・コンテンツマップのテンプレートも作成しました。新しいプロダクトでマップを作る際に、毎回ゼロから考えなくて済みます。

テンプレートには以下のセクションを含めています：

1. 機能一覧: プロダクトの全機能をリストアップ
2. 対応記事マトリクス: 機能 × 記事の対応表
3. 優先度: High / Medium / Low
4. ステータス: 未着手 / 執筆中 / 公開済み
5. 想定キーワード: SEO のターゲットキーワード

このテンプレートは docs/templates/feature-content-map-template.md に置いてあり、新しいプロダクトのマップ作成時に使っています。

効果 — 何が変わったか

機能・コンテンツマップを導入してから、いくつかの変化がありました。

記事企画の速度

「次に何を書くか」で悩む時間がほぼなくなりました。マップを見て、未着手の中から優先度の高いものを選ぶだけです。

SEO の改善

記事が「課題ベース」になったことで、検索意図に合致するコンテンツが増えました。「フリーランス 請求書」「アイデア管理 ツール」のような実用的なキーワードで記事を書くことで、ターゲットユーザーに届きやすくなりました。

プロダクトへの導線

各記事の末尾に関連プロダクトへの CTA（Call to Action）を自然に配置できます。記事の内容が機能と紐づいているため、「この課題を解決するツールがあります」という導線が不自然になりません。

網羅性の確認

マップを見れば「この機能に対応する記事がまだない」ことが一目でわかります。コンテンツの抜け漏れを防げます。

この方法が合わないケース

正直に書くと、機能・コンテンツマップは万能ではありません。

• プロダクトがない場合: 機能起点なので、ツール系でないブログには適用しづらい
• 機能が少ないプロダクト: 3機能程度なら、マップを作るまでもない
• 速報性が求められるブログ: ニュースやトレンドは機能とは無関係に書く必要がある

機能・コンテンツマップは「プロダクトの認知を広げるためのコンテンツマーケティング」に特化した手法です。

Journal との棲み分け

ここまで説明した機能・コンテンツマップは Focus Blog（フリーランス向け）の記事企画に使っています。一方、Journal（開発者向け）の記事企画には別のアプローチ — 開発日記（devlog）からの逆引き — を使っています。

この棲み分けは、ターゲット読者の違いに起因しています。Focus Blog は「課題を持つユーザー」に向けたコンテンツ、Journal は「開発プロセスに興味がある人」に向けたコンテンツです。

機能からコンテンツを逆引きする設計は、記事企画の効率を上げる

開発日記のこの結論は、実際にマップを作って記事を量産できた実感に裏打ちされています。

関連記事

コンテンツ運用に関連する Journal 記事もどうぞ：

• 開発日記を書く習慣で記事ネタが尽きなくなった話 — Journal 側の記事企画手法
• 個人開発で6プロダクトを同時に運用する方法 — 複数プロダクトの運用全般
• GitHub Actionsで複数リポジトリの開発日記を自動集約する方法 — devlog の自動管理

まとめ

「機能・コンテンツマップ」は、プロダクトの機能一覧から記事を逆引きする企画手法です。

持ち帰りポイント:

1. 「何を書くか」で悩むなら、プロダクトの機能から逆引きする — 機能の数だけ記事のネタがある
2. マップの粒度は「機能単位」がおすすめ — ユースケースは記事企画時に検討
3. 優先順位は「検索需要 × 書きやすさ × 機能の成熟度」で決める — 書きやすいものからモメンタムを作る
4. SEO と CVR を同時に設計できる — 課題ベースの記事 → プロダクトへの自然な導線

この仕組みを Claude Code と一緒に設計した結果、IdeaSpool だけで16本、Wakulier でも10本以上の記事タイトル案が生まれました。「ネタがない」と悩む前に、まず自分のプロダクトの機能を一覧化してみることをおすすめします。