AIで記事本文を書く前に、まず記事構成案を自動生成するようにした理由

はじめに

前回までの記事では、Google Search Console APIから検索クエリを取得し、WordPress既存記事と照合して、新規記事候補、リライト候補、追記候補に分類する仕組みについて書いた。

ここまでで、記事にできそうなテーマは見つかるようになった。

しかし、テーマが見つかったからといって、すぐにAIへ本文を書かせればよいわけではない。

たとえば、次のようなテーマ候補があったとする。

Teams 添付ファイル 開けない

これをそのままAIに渡して、

このテーマでブログ記事を書いて

と依頼すれば、それなりの記事は出てくる。

しかし、それが本当に読者の検索意図に合っているか、社内SE向けの記事になっているか、既存記事と重複していないか、内部リンクをどう入れるかまでは分からない。

そこで筆者は、AIで本文を書く前に、まず記事構成案を自動生成する仕組みを作った。

本記事では、なぜ本文生成の前に構成案を挟むようにしたのか、どのような情報を構成案に入れたのかを紹介する。

いきなり本文生成すると、見た目だけ整った記事になりやすい

AIに記事本文を書かせると、文章としてはそれなりに整ったものが出てくる。

見出しもあり、導入文もあり、まとめもある。
ぱっと見では記事らしい。

しかし、ブログ運営で重要なのは「文章として自然か」だけではない。

実際には、次のような観点が必要である。

検索意図に合っているか
読者の悩みに答えているか
既存記事と重複していないか
社内SEや情シス担当者向けになっているか
公式確認が必要な箇所を断定していないか
内部リンクを入れやすいか

AIにいきなり本文を書かせると、これらの観点が曖昧なまま文章化されることがある。

特に技術記事では、見た目が整っていることよりも、読者の作業に役立つことが重要である。

筆者は、AI本文生成の前に「記事の設計図」を作る必要があると考えた。

記事構成案は、本文を書く前の設計図である

今回作った仕組みでは、承認済みテーマから、まず記事構成案をMarkdownで生成するようにした。

記事構成案には、次のような情報を入れている。

基本情報
想定読者
検索意図
読者の悩み
推奨タイトル案
見出し構成案
本文で触れるべきポイント
既存記事との差分
内部リンク候補
メタディスクリプション案
注意事項

これは、建物でいえば設計図である。

いきなり本文を書くのは、設計図なしで家を建てるようなものだ。
外から見ると家っぽいが、階段の先が壁だったり、窓の位置が妙だったりする。

記事でも同じである。

先に構成案を作っておけば、本文生成の前に記事の方向性を確認できる。

想定読者を先に決める

記事構成案で最初に重要なのは、想定読者である。

同じテーマでも、誰に向けて書くかで内容は変わる。

たとえば、次のテーマを考える。

Teams 添付ファイル 開けない

このテーマの読者は、複数考えられる。

Teamsを使っている一般社員
問い合わせを受けた社内SE
Microsoft 365管理者
ファイル共有や権限を管理する担当者

一般社員向けなら、まず試す操作を分かりやすく書く必要がある。

一方、社内SE向けなら、管理者側で確認すべきポイントも必要になる。

たとえば、以下のような内容である。

OneDriveやSharePoint側の権限確認
Teamsのチャネルとファイル保存先の関係
ユーザー単位の問題か、組織全体の問題か
ブラウザ版とデスクトップ版での切り分け
問い合わせ対応時の確認項目

この違いを本文生成後に直すのは面倒である。
そのため、構成案の段階で想定読者を決めるようにした。

検索意図を分類する

次に、検索意図を分類する。

検索意図とは、読者が何を知りたくて検索しているかである。

今回の仕組みでは、検索意図を次のような分類で考えるようにした。

トラブル解決
設定手順
原因調査
比較検討
用語理解
管理者向け設定
一般ユーザー向け案内

たとえば、

Outlook 文字化け UTF-8

であれば、検索意図は「トラブル解決」または「原因調査」に近い。

読者はOutlookの文字化けについて、原因や直し方を知りたいはずである。

一方、

Microsoft 365 E3 Business Standard 違い

であれば、「比較検討」に近い。

この場合は、機能差、価格差、対象ユーザー、管理者向け機能などを整理する必要がある。

検索意図が違えば、記事構成も変わる。

そのため、構成案の段階で検索意図を推定し、本文生成時の前提にするようにした。

読者の悩みを箇条書きにする

構成案には、読者の悩みも入れるようにした。

たとえば、

SharePoint 404 復旧

というテーマであれば、読者の悩みは次のようになる。

SharePointサイトにアクセスできなくなった
削除されたのか、権限がないのか分からない
管理画面のどこを確認すればよいか分からない
ユーザーから問い合わせを受けているが、原因を切り分けられない

このように、読者の悩みを先に書き出しておくと、本文が読者の困りごとからズレにくくなる。

AIに本文を書かせる場合でも、「読者は何に困っているか」を渡した方が、実務記事として使いやすい内容になりやすい。

ブログ記事は、単に情報を並べるものではない。
読者の困りごとに順番に答えるものである。

タイトル案を複数出す

記事構成案では、タイトル案も複数出すようにした。

たとえば、以下の3種類である。

直接解決型タイトル
初心者向けタイトル
社内SE向けタイトル

「Teams 添付ファイル開けない」であれば、次のようなタイトル案になる。

Teamsで添付ファイルが開けない時の原因と確認ポイント

Teamsの添付ファイルが開けない時にまず確認したいこと

社内SE向け：Teamsで添付ファイルが開けない問い合わせへの確認手順

同じテーマでも、タイトルによって読者の印象は変わる。

検索流入を狙うなら、検索語句を自然に含める必要がある。
一方で、社内SE向けであることを明示した方が、ブログの読者には刺さる場合もある。

タイトルは本文を書いた後に考えることもできるが、構成案の段階で複数案を持っておくと方向性を決めやすい。

見出し構成を先に作る

記事構成案で最も重要なのは、見出し構成である。

今回の仕組みでは、新規記事、リライト候補、追記候補で構成を分けるようにした。

新規記事の場合

新規記事では、次のような構成を基本にする。

まず結論
よくある原因
確認手順
管理者側で確認すること
再発防止策
まとめ

社内SE向けのトラブル解決記事では、原因と手順を分けると読みやすい。

また、一般ユーザー向けの説明だけでなく、管理者側で確認することを入れると、社内SEブログらしさが出る。

リライト候補の場合

リライト候補では、新規記事の構成ではなく、既存記事をどう改善するかを整理する。

現在の記事で強化すべきポイント
追加した方がよい見出し
タイトル改善案
メタディスクリプション改善案
内部リンク改善案

リライト候補に対して、新規記事のような本文を作ってしまうと、既存記事との関係が分かりにくくなる。

そのため、リライト候補は「改善案」として扱うようにした。

追記候補の場合

追記候補では、既存記事に追加するセクションを作る。

追加すべき見出し案
追記する本文の要点
既存記事内のどこに追加するか
関連する内部リンク候補

このように、記事の種類によって構成案を変えることで、後続の本文生成やリライト作業がしやすくなる。

既存記事との差分を見る

記事構成案には、既存記事との差分も入れるようにした。

新規記事候補であっても、本当に既存記事で扱っていないのかを確認する必要がある。
リライト候補や追記候補なら、なおさら既存記事との差分が重要である。

たとえば、既存記事がOutlookの文字化け全般を扱っている場合でも、UTF-8の設定や添付ファイル名の文字化けについては薄いかもしれない。

この場合、構成案では次のように整理できる。

既存記事で扱っている内容
- Outlookの文字化けの概要
- 一般的な表示確認

追加するとよい内容
- UTF-8との関係
- 送信元環境による違い
- 添付ファイル名の文字化け
- 社内SEが問い合わせ対応時に確認する項目

この差分が見えると、新規記事にするか、追記にするか判断しやすい。

ブログ運営では、記事を増やすだけでなく、既存記事を育てることも重要である。

内部リンク候補を出す

構成案には、内部リンク候補も入れるようにした。

内部リンクは、読者の回遊だけでなく、記事同士の関係を整理する上でも重要である。

たとえば、Teamsのトラブル記事を書くなら、以下のような既存記事にリンクできるかもしれない。

Microsoft 365関連の記事
OneDriveやSharePointの記事
Teams会議やチャットのトラブル記事
社内問い合わせ対応の記事

内部リンク候補を本文完成後に探すのは意外と面倒である。

構成案の段階で候補を出しておけば、本文生成時にも自然にリンク導線を意識できる。

もちろん、自動で出した内部リンク候補が必ず正しいとは限らない。
最終的には人間が確認する必要がある。

しかし、候補が最初からあるだけで、記事編集はかなり楽になる。

アフィリエイト導線も候補として出す

今回の仕組みでは、アフィリエイト導線も候補として出すようにした。

ただし、いきなり本文に無理やり商品リンクを入れるのではない。
あくまで「自然に紹介できそうな商品カテゴリ」を出すだけである。

たとえば、カテゴリごとに次のような候補が考えられる。

Microsoft 365
- Microsoft 365関連書籍
- 情シス向け実務書

Windows
- Windows管理者向け書籍
- バックアップソフト
- 外付けSSD

セキュリティ
- セキュリティソフト
- パスワード管理ツール
- セキュリティ書籍

PC / 周辺機器
- モニター
- キーボード
- マウス
- USBハブ
- ドッキングステーション

ただし、トラブル解決記事に無理やり商品紹介を入れると、記事の信頼性が落ちることがある。

そのため、構成案では「アフィリエイト導線なし」も選べるようにした。

収益化よりも、まず記事の主目的を守る方が重要である。

注意事項を残す

構成案には、注意事項も入れるようにした。

特に技術記事では、以下のような項目を確認する必要がある。

公式情報を確認した方がよい項目
実機検証が必要そうな項目
古い情報になりやすい項目
断定を避けた方がよい項目

AIが生成した文章は、それらしく見える。
しかし、技術仕様や管理画面の項目名は変わることがある。

そのため、構成案の段階で「ここは要確認」と残すようにした。

これは、本文生成後の品質チェックにもつながる。

Codexには何を作らせたか

この機能もCodexに段階的に作らせた。

Codexには、承認済みテーマCSVを読み込み、優先度順に記事構成案Markdownを生成する処理を実装させた。

実装の考え方は以下である。

approved_topics.csv を読み込む
priority_score の高い順に並べる
1テーマにつき1つのMarkdownを作る
新規記事・リライト・追記で構成を変える
内部リンク候補を既存記事データから探す
アフィリエイト候補をカテゴリから推定する

出力先は以下である。

outputs/article_briefs/

構成案はMarkdownファイルとして保存する。

これにより、本文生成前に人間が確認できる。
また、後から構成案だけを見返すこともできる。

AIにその場で構成を出させるだけでは、結果が会話の中に埋もれやすい。
Markdownファイルとして残しておけば、運用フローの中で扱いやすい。

本文生成の前に一呼吸置ける

記事構成案を挟む最大のメリットは、本文生成の前に一呼吸置けることである。

自動化を進めると、どうしても次のように流したくなる。

テーマ候補
↓
本文生成
↓
WordPress投稿

しかし、この流れは少し怖い。

テーマ候補が不十分でも、本文はそれらしく生成されてしまう。
すると、見た目は記事だが、中身が弱いものが増える可能性がある。

そこで、筆者は次の流れにした。

テーマ候補
↓
承認
↓
記事構成案
↓
本文下書き
↓
品質チェック
↓
WordPress下書き登録

記事構成案を挟むことで、本文生成前に「この方向で書いてよいか」を確認できる。

これは、自動化のブレーキであり、品質を守るための関所でもある。

実際に作って感じたこと

記事構成案生成を入れて感じたのは、AI記事生成の成否は本文生成前にかなり決まるということである。

本文生成AIの性能だけでなく、事前に渡す情報の質が重要である。

構成案で以下が整理されていれば、本文もかなり安定しやすい。

誰に向けて書くか
何を解決する記事か
どの見出しで展開するか
既存記事との差分は何か
どこに内部リンクを入れるか
どこを公式確認すべきか

逆に、これらが曖昧なまま本文生成すると、文章はうまくても記事として弱くなる。

AIに良い記事を書かせたいなら、いきなり本文を頼むのではなく、先に設計図を整えるべきである。

自動化しすぎないための工程でもある

記事構成案は、自動化を進めるための工程であると同時に、自動化しすぎないための工程でもある。

自動化では、何でも一気通貫にしたくなる。

しかし、ブログ記事には人間が判断すべき部分がある。

このテーマは今のブログに合うか
読者にとって本当に役立つか
既存記事と重複しないか
筆者が責任を持って書ける内容か
公開前に確認すべきことは何か

構成案は、これらを確認するための中間成果物である。

中間成果物を残すことで、自動化の流れを止めずに、人間の確認ポイントを作れる。

筆者は、この設計がかなり重要だと感じている。

まとめ

AIでブログ記事を書く場合、いきなり本文を生成させることもできる。

しかし、それだけでは検索意図とのズレ、読者像の曖昧さ、既存記事との重複、内容の薄さが起きやすい。

筆者はその対策として、本文生成の前に記事構成案を自動生成する仕組みを作った。

記事構成案には、想定読者、検索意図、読者の悩み、タイトル案、見出し構成、内部リンク候補、アフィリエイト導線候補、注意事項などを入れている。

これにより、本文生成前に記事の方向性を確認できる。

AIに良い記事を書かせるには、いきなり本文を依頼するのではなく、先に設計図を作ることが重要である。

今回の仕組みでは、記事構成案を挟むことで、AI記事生成をより安全で実用的な流れにできた。

次回は、この構成案を元にOpenAI APIで本文下書きを生成する仕組みについて紹介する予定である。

リンク