はじめに

AI記事生成SaaS「Draifty」を開発・運用する中で、一番苦労したのは「文章として自然」であることと「検索エンジンに評価される構造」であることを両立させる部分でした。単に長文を生成するだけなら既存のLLMで十分ですが、それを検索順位に反映させるには、生成後に構造をスコアリングして修正するレイヤーが必要になります。この記事では、その設計思想を技術者向けに整理します。

課題:生成された文章の「読みやすさ」と「構造としての評価されやすさ」は別物

LLMに「〇〇について記事を書いて」と投げると、それなりに読みやすい文章は返ってきます。しかし検索エンジンが評価する構造的な要素(見出し階層の論理性、トピックの網羅性、内部リンクの整合性など)は、プロンプト任せだとムラが出ます。特に以下の3点が崩れやすいポイントでした。

見出し階層(H2/H3)の論理的な入れ子構造
記事内で扱うトピックの網羅性(共起語・関連キーワードの抜け漏れ)
見出しと本文の主張のズレ(タイトル詐欺的な構成になっていないか)

これらは生成"後"にチェックしないと安定しないため、Draiftyでは生成パイプラインを1段階では終わらせず、生成→構造スコアリング→再生成のループにしています。

パイプライン構成

大まかな流れは以下の3段階です。

構造設計フェーズ
キーワード → 検索意図分類 → 見出し骨子(アウトライン)生成
本文生成フェーズ
骨子ごとにセクション生成 → 具体例・数値の挿入指示を強制
構造スコアリング・修正フェーズ
生成済み記事を構造チェック → スコアが閾値未満のセクションのみ再生成

ポイントは、全文を毎回作り直すのではなく、スコアが低いセクションだけをピンポイントで再生成する設計にしたことです。全文再生成は生成コストが高く、また文脈のブレも起きやすいため、部分再生成の方がコストと品質の両面で有利でした。

構造スコアリングの評価軸

スコアリングフェーズでは、記事全体を以下のような観点でチェックしています(実装はルールベースとLLM評価のハイブリッドです)。

評価軸	チェック内容
見出し網羅性	上位表示記事群と比較して、扱われていないトピックがないか
階層整合性	H2配下のH3が論理的にぶら下がっているか、粒度が揃っているか
具体性	数値・固有名詞・実例が含まれているか（抽象論だけのセクションを検出）
一貫性	見出しと本文の主張がずれていないか

このうち「見出し網羅性」は、対象キーワードで実際に上位表示されている記事群の見出し構造を事前に解析し、頻出トピックを抽出したうえで、生成した記事のカバー率を測る形にしています。ここはSEOツールというより情報検索(IR)寄りのアプローチに近いです。

「階層整合性」は地味ですが効果が大きく、H2の粒度がバラバラだったり、H3が実質H2の内容を繰り返しているだけの記事は、人間が読んでも構造として破綻して見えます。ここをルールベースのチェック(見出しの文字数分布、包含関係の解析)で機械的に検出できるようにしています。

再生成ループでハマった落とし穴2>

部分再生成を導入した当初、セクションごとに独立して再生成すると、記事全体としてのトーンや一人称の使い方がズレる問題が出ました。対策として、再生成時には該当セクションだけでなく、前後のセクションの要約と記事全体のスタイル指示を毎回コンテキストに含めるようにしています。これによって部分再生成でも文体の一貫性を保てるようになりました。

もう一つの落とし穴は、スコアリングの閾値を厳しくしすぎると再生成ループが収束しないケースがあったことです。最大再生成回数を設けて、それでも閾値未達なら「人間のレビュー待ちキュー」に回す設計にして、無限ループを防いでいます。

今後の課題

現状は生成後のチェックで構造品質を担保していますが、本来は生成前の骨子設計の精度を上げることでスコアリング側の負荷を下げたいと考えています。検索意図の分類精度や、上位表示記事の見出し解析ロジックはまだ改善余地が大きく、引き続き取り組んでいく予定です。

同じようにAIコンテンツ生成×構造化の領域に取り組んでいる方がいれば、評価軸の設計など意見交換できると嬉しいです。

今回完成したAI記事生成SaaSです。まだ改善点はありますが、宜しければご意見ください。

AI記事生成SaaS『Drafity』