AI編集者開発のリアル(3)　下書きをAIに任せる：LLM多段階記事生成パイプラインの使い方

こんにちは、パレイド思想部です。

前回まで、WordPress の記事をローカルで管理し、Markdown 形式で編集するツールを実装しました。

技術色の強い内容だったため、詳細は技術部の記事として紹介しています。

1記事に半日かかる問題
パイプラインの全体構造
Step 1：シナリオ YAML の書き方
Step 2〜4：LLM による段階的生成
Web 検索の組み込み（SearXNG）
品質チェック（ルールベース）
「AI が書いたものを自分が編集する」という意識転換
まとめ

1記事に半日かかる問題

前回は ai-editor のアーキテクチャ全体を俯瞰しました。今回は実際に使う人が最も気になる「記事生成」の部分に焦点を当てます。

記事を書くのはそれなりに大変です。トピックを決め、構成を考え、コードを動かして確認し、説明文を書き、見出しを整える——これを1記事ぶんやると、軽く1〜2時間は溶けます。

また、過去の記事が増えるにつれ、整合性や重複のチェックなど、日に日にタスクの量も指数的に増加します。毎日更新を目指していても、熱量はあっても物理的に時間が足りなくなってきました。

ai-editor で解決しようとしたのはこの問題です。シナリオを書く（15〜30分）だけで、あとは AI が記事の骨格から本文まで組み立てる。自分がやるのは「AI が出力したドラフトを読んで直す」だけ——そういうワークフローへの移行が今回のゴールです。

パイプラインの全体構造

記事生成は7つのステージで構成されます。Step 1（シナリオ設計）だけが人間の作業で、Step 2〜7 は自動実行されます。

Step 1: シナリオを書く（人間）
         ↓
Step 2: 構成生成（見出し・章立て）
         ↓
Step 3: 各セクションの本文展開
         ↓
Step 4: コードスニペット生成・埋め込み
         ↓
Step 5: レビュー（品質ゲート）
         ↓
Step 6: フロントマター補完
         ↓
Step 7: 最終整形・ファイル出力

各ステージは独立した LLM 呼び出しとして実装されており、途中の成果物（構成案・セクション本文など）はすべてファイルに保存されます。「Step 4 まで進んで止まった」という状況でも、Step 4 から再開できます。再実行コストを最小化するための設計判断です。

Step 1：シナリオ YAML の書き方

Step 1 で書く YAML形式の「シナリオ」がパイプライン全体のインプットになります。

# blog/plan/2026_02_AI編集者/scenario_03.yaml
series: "AI駆動ブログ運営ツール「ai-editor」開発記"
number: 3
title: "下書きをAIに任せる：LLM多段階記事生成パイプラインの使い方"

theme: |
  シナリオ YAML を書くだけで Step 2〜7 が自動で記事を組み立てる仕組みを解説。
  実際の生成プロンプト設計と品質ゲートの動作を示す。

key_points:
  - "パイプラインの7ステージ構造"
  - "Step 2〜4: LLM による段階的な本文生成"
  - "Step 5: レビューによる品質ゲート"
  - "「AI が書いたものを自分が編集する」ワークフロー"

tone: "技術的に正確・実践的。コードと設計判断の背景を両立"
target_word_count: 3000

テンプレートをコピペして箇条書きを加え、これを書いたら CLI を叩くだけです。普段はVS Code の tasks.json に定義して使っています。

python -m publish generate \
  --scenario blog/plan/2026_02_AI編集者/scenario_03.yaml

Step 2〜4：LLM による段階的生成

なぜ1回のプロンプトで完成させないのか

最初は1プロンプトで1記事、3000字前後の記事を出力させようと試みましたが、結果は悲惨でした—— 後半になるほど内容が薄くなり、引用や実例もなく、「詳細は省略します」という文が乱発されます。

LLM の注意機構はコンテキストの後半ほど劣化するようです。記事全体を一度に生成させると、最後の方は実質、重複や曖昧な一般論の「埋め草」になってしまう。

解決策：分割して生成する。 Step 2 で構成を固め、Step 3 でセクションごとに独立した LLM 呼び出しを行い、Step 4 でコードだけを別途生成して埋め込む。各呼び出しは500〜800字程度のターゲットに絞るため、LLM の注意が最後まで維持されます。

生成は段階的に行いつつ、直前の内容を渡すことで、前のセクションとの文脈的整合性を保ちながら、各呼び出しの実サイズを小さく抑えられます。

LLM バックエンドの選択理由

実験には Ollama とローカルLLMを利用し、gemma3:4b、qwen3.5:4b など小型のモデルから始めました。セキュリティ面もありますが、出先などネットワーク環境が不安定でも動作して欲しいためです。

結論から言うと、現状、安定した記事生成には、API キーによる各社のクラウド最新モデル利用が欠かせません。時間とコストのバランスから、GPT-5mini をメインの選択肢としています。日本語の自然な文章生成において安定した出力品質を出すからです。

小型のローカル LLM（gemma3, qwen3等）では生成される記事の品質が低く、期待の gpt-oss:20b は生成に時間がかかりすぎます。パラメータ数を増やしても、3000字規模の日本語記事では語尾の崩れや論理的跳躍が頻発しました。記事生成の用途に限っては、コストをかけて外部 API を使う判断が現時点では避けられません。

(2026年3月追記) その後の追加検証で、最新リリースの qwen3.5:27b で実用レベルと言える結果が出ました。メモリを32GBまで積めば、Macbook Air M5 でも、時間はかかりますが、ある程度品質を満たす記事が生成できます。

Web 検索の組み込み（SearXNG）

LLM の知識は学習データの時点で止まっています。技術記事では「最新のバージョン」「現在の仕様」に言及する場面が多く、LLM だけでは古い情報や存在しない情報を生成するリスクがあります。

そこで、記事生成パイプラインに SearXNG（セルフホスト型メタ検索エンジン）を組み込みました。記事のテーマからキーワードを抽出し、Web 検索結果を LLM のコンテキストに注入します。

内部では、SearXNG の JSON API にクエリを投げ、上位5件の検索結果（タイトル・URL・スニペット）を取得します。検索結果は Step 2（構成生成）と Step 3（本文展開）の両方で LLM プロンプトに含められます。これにより「2026年2月時点で〇〇は△△に対応している」のような記述が、実際の Web 情報に基づくものになります。

SearXNG は Docker で localhost:8888 にホストしており、外部サービスへの依存を最小化しています。検索に失敗した場合はスキップし、LLM の内部知識だけで生成を続行します。

品質チェック（ルールベース）

生成された記事を自動的に品質チェックする仕組みも組み込んでいます。ただし、現時点では RAG（検索拡張生成）や LLM によるレビューではなく、ルールベースの検証です。

チェック項目は以下の通りです。

H2 見出しの数: 構成案で指定したセクション数と実際の見出し数が合っているか
blogcard の有無: 前回記事への参照リンクが含まれているか
セクション間の重複: 4-gram 類似度で異なるセクションが同じ内容を繰り返していないか検出

品質チェックに失敗した場合、最終段階の記事の合成と編集をリトライします。最大リトライ回数は設定可能で、解消しなければ警告を出して人間に判断を委ねます。

過去記事との重複や矛盾チェックのため RAG もオプションで用意していますが、まだチェック内容が定型化しきれていないため、パイプラインには統合していません。将来的にはパイプラインの品質ゲートとして組み込みたい部分です。

「AI が書いたものを自分が編集する」という意識転換

このパイプラインを使い始めて、仕事の中心が変わりました。

以前： 白紙から書く → 時間がかかる → 後半になると疲弊して品質が落ちる

以降： ドラフトを読んで直す → 「ここの説明が浅い」「このコードは動かない」を指摘する → 実質的なレビュアーになる

ベースのある記事を読みながらの推敲は、一から書くより圧倒的に速い。3000字を「書く」のに3時間かけていたのが、「直す」なら30〜40分で終わります。仕事に取り掛かる心理的なハードルも格段に下がります。AI は生成する、人間はキュレートする——この役割分担が ai-editor の設計思想の核心です。

ただし、内容によってAI に任せるられる場合とそうでない場合いがあります。当サイトのように、AI技術やコーディングなど LLM が得意とする領域なら高い効果が望めます。そうでない場合は、およそ使い物にならない結果も生成されます。品質ゲートが重要なのはここで、「そのまま公開できる品質かどうか」を機械的に判断します。AI による記事生成は時間がかかり、リトライで解決できない場合は早めに諦めたほうが得策です。