はじめに
前回の記事では、AIで記事本文を書く前に、まず記事構成案を自動生成する仕組みについて書いた。
筆者は、ブログ記事をAIで作る場合、いきなり本文を生成するのは危険だと考えている。
そのため、承認済みテーマからまず記事構成案を作り、想定読者、検索意図、読者の悩み、見出し構成、内部リンク候補などを整理するようにした。
今回の記事では、その次の工程である「本文下書き生成」について書く。
具体的には、記事構成案Markdownを入力として、OpenAI APIを使い、ブログ本文の下書きを生成する仕組みを作った。
ただし、ここで重要なのは、生成した文章を完成記事として扱わないことである。
今回の仕組みでは、OpenAI APIで生成した本文は、あくまでレビュー前の下書きとして保存する。
その後に品質チェックを行い、さらに人間が確認した上で、WordPressへ下書き登録する流れにしている。
記事構成案
↓
OpenAI APIで本文下書き生成
↓
品質チェック
↓
WordPress下書き登録
↓
人間が最終確認して公開
AIに本文を書かせること自体は難しくない。
難しいのは、生成された文章を安全に運用することである。
本文生成の前に構成案を挟んだ理由
今回の仕組みでは、OpenAI APIにいきなりテーマだけを渡して本文を書かせることはしない。
たとえば、次のような依頼だけで記事を書かせることは避けた。
「Teams 添付ファイル 開けない」というテーマでブログ記事を書いて
これでも、それなりの記事は生成される。
しかし、この依頼では前提が不足している。
- 読者は一般ユーザーなのか、社内SEなのか
- トラブル解決記事なのか、管理者向け記事なのか
- 既存記事への追記なのか、新規記事なのか
- どの見出しで展開するのか
- 公式確認が必要な箇所はどこか
これらが曖昧なまま本文を生成すると、文章としては整っていても、記事としては弱くなりやすい。
そこで、本文生成の前に記事構成案を作るようにした。
記事構成案には、以下のような情報が含まれる。
- action
- priority_score
- category
- query
- suggested_title
- 想定読者
- 検索意図
- 読者の悩み
- 見出し構成案
- 本文で触れるべきポイント
- 既存記事との差分
- 内部リンク候補
- アフィリエイト導線候補
- 注意事項
この構成案をOpenAI APIに渡すことで、本文生成の方向性を安定させるようにした。
今回作った本文下書き生成の流れ
本文下書き生成の流れは、以下である。
outputs/article_briefs/
↓
scripts/generate_article_drafts.py
↓
outputs/article_drafts/
outputs/article_briefs/ には、前工程で作成した記事構成案Markdownが入っている。
この構成案を読み込み、OpenAI APIへ渡して、本文下書きを生成する。
生成した本文は、outputs/article_drafts/ にMarkdownとして保存する。
実行イメージは以下である。
python scripts/generate_article_drafts.py --source approved --limit 1
あるいは、特定の構成案ファイルを指定して生成することもできる。
python scripts/generate_article_drafts.py --input outputs/article_briefs/001_xxx.md
このようにしておくと、一括生成も単体生成もできる。
最初は1件だけ生成し、出力内容を確認する。
問題なければ、少しずつ件数を増やす。
自動化では、最初から大量実行しないことが大事である。
小さく流して、どこで詰まるかを見る方が安全である。
OpenAI APIキーは.envで管理する
OpenAI APIを使うため、APIキーを設定する必要がある。
ただし、APIキーをコードに直接書くことはしない。.env に設定し、Python側で読み込むようにした。
OPENAI_API_KEY=your_openai_api_key_here
OPENAI_MODEL=gpt-5.2
実際のAPIキーは .env に書く。.env.example にはダミー値だけを書く。
OPENAI_API_KEY=your_openai_api_key_here
OPENAI_MODEL=gpt-5.2
.env はGitHubに上げない。.env.example は設定項目の見本としてGitHubに上げてもよい。
この分け方は、OpenAI APIに限らず、WordPress Application PasswordやGoogle OAuthの認証情報でも同じである。
APIキーを扱う自動化ツールでは、機能そのものよりも、秘密情報をどう守るかが重要になる。
本文生成プロンプトでは、断定しすぎないようにした
本文生成時には、OpenAI APIへ記事構成案を渡すだけでなく、文章の方針も指定した。
主な方針は以下である。
社内SE・情シス担当者向けに書く
実務で使える確認手順を重視する
不確かな仕様は断定しない
公式確認が必要な箇所は「要公式確認」として残す
架空のURLを作らない
記事構成案に含まれる情報を優先する
Markdownで出力する
特に重視したのは、断定しすぎないことである。
技術記事では、環境によって動作が違うことがある。
Microsoft 365、Windows、WordPress、セキュリティ設定などは、時期や環境によって画面や仕様が変わることも多い。
AIが「必ずこうすれば直る」と書いてしまうと、読者に誤解を与える可能性がある。
そのため、本文生成時には、不確かな部分を断定せず、必要に応じて「要公式確認」や「環境によって異なる可能性がある」と残すようにした。
AIが弱いのは、分からないことを分からないままにすることである。
そこをプロンプトで補う必要がある。
新規記事・リライト・追記で出力形式を変える
本文下書き生成では、すべての候補を同じ形式で扱わないようにした。
前工程の分類には、以下のようなactionがある。
create_new_article
rewrite_existing
add_section_to_existing
このactionによって、生成するMarkdownの構成を変える。
新規記事の場合
新規記事の場合は、通常の記事本文として生成する。
構成は以下のような形である。
この記事で分かること
まず結論
よくある原因
確認手順
管理者側で確認すること
一般ユーザーに案内する場合の文例
再発防止策
関連記事・内部リンク候補
まとめ
レビュー時の確認事項
社内SE向けの記事では、単にユーザー向けの手順を書くのではなく、管理者側の確認ポイントを入れることが重要である。
リライト候補の場合
リライト候補の場合は、新規記事本文ではなく、既存記事の改善案として出力する。
対象記事
改善方針
タイトル改善案
メタディスクリプション改善案
追加した方がよい見出し
追記本文案
既存本文のどこに入れるか
内部リンク改善案
レビュー時の確認事項
既存記事を直すべき候補に対して、新しい記事本文を作ってしまうと、重複記事が増えるだけである。
そのため、リライト候補は「改善案」として扱うようにした。
追記候補の場合
追記候補の場合は、既存記事に追加できるセクション案として出力する。
対象記事
追加する見出し案
追記本文案
追記する位置の提案
関連する内部リンク候補
レビュー時の確認事項
この形式にしておくと、WordPressの既存記事に貼り付けて使いやすい。
新規記事、リライト、追記を同じ扱いにしないことは、ブログ自動化ではかなり重要である。
記事を増やすだけでなく、既存記事を育てる流れを作れるからである。
出力はMarkdownにした
本文下書きはMarkdownで保存するようにした。
理由はシンプルである。
- 人間が読みやすい
- Git管理しやすい
- WordPress投稿前に確認しやすい
- 後工程でHTML変換しやすい
- 品質チェックにも使いやすい
たとえば、以下のような形式で出力する。
---
title: Teamsで添付ファイルが開けない時の原因と確認ポイント
description: Teamsで添付ファイルが開けない時に確認したい原因と対処法を、社内SE向けに整理する。
action: create_new_article
review_status: draft
---
# Teamsで添付ファイルが開けない時の原因と確認ポイント
## この記事で分かること
- Teamsで添付ファイルが開けない時の主な原因
- ユーザー側で確認すること
- 管理者側で確認すること
- 問い合わせ対応時の切り分けポイント
front matterを入れておけば、後工程でタイトルやdescriptionを読み取りやすい。
本文だけでなく、メタ情報も含めておくことで、WordPress下書き登録にもつなげやすくなる。
dry-runを用意した
本文下書き生成では、dry-runも用意した。
dry-runでは、OpenAI APIを呼ばずに、実際に送る予定のプロンプトだけ保存する。
python scripts/generate_article_drafts.py --input outputs/article_briefs/001_xxx.md --dry-run
これにより、APIを使う前に次のことを確認できる。
- どの構成案を読み込んでいるか
- OpenAI APIへ渡すプロンプトが適切か
- 不要な情報を渡していないか
- 記事生成の方針が反映されているか
APIを呼ぶと料金がかかる。
また、プロンプトが間違っていれば、望まない下書きが生成される。
そのため、dry-runで確認できるようにした。
自動化では、実行する前に「何が実行されるか」を見られることが大事である。
最初に詰まったのはOPENAI_API_KEY未設定だった
E2Eスモークテストを実行したとき、本文生成の工程で一度止まった。
原因は単純である。
OPENAI_API_KEY が未設定
Search Console取得、承認キュー、記事構成案生成までは成功していた。
しかし、本文下書き生成だけがOpenAI APIキー未設定で失敗した。
これは実装ミスというより、環境設定の問題である。
そこで、.env に以下を設定した。
OPENAI_API_KEY=実際のAPIキー
OPENAI_MODEL=使用するモデル名
その後、1件だけ本文生成を実行し、Markdown下書きが作成されることを確認した。
この段階で大量生成しなかったのは正解だった。
最初から10件、20件と流していたら、問題が出たときの切り分けが面倒だったはずである。
OpenAI APIについて
OpenAI APIについて補足すると、今回のようなアプリやプログラムなどからOpenAIの機能を呼び出すことができるAPIである。
OpenAI APIを使うためには、1.アプリやプログラム用のAPIキーの登録、2.アプリやプログラムでのAPIキー読み込み、を行う必要がある。
注意点としてはChatGPT PlusやProの料金とは別にAPI料金が必要な点だ。
また、APIの料金は事前にクレジットを購入する方式で、使用モデルとトークン数でクレジットが使用されて行く。因みに試作で作った記事は0.2ドル程の消費量だった。
生成した下書きは完成記事ではない
今回の仕組みで最も重要なのは、生成した下書きを完成記事として扱わないことである。
OpenAI APIで生成した文章は、あくまで下書きである。
そのため、出力ファイルにも review_status: draft を持たせている。
生成後は、次の品質チェック工程に進める。
本文下書き
↓
品質チェック
↓
wordpress_ready 判定
↓
WordPress下書き登録
AI生成記事をそのままWordPressへ登録し、さらに自動公開するのは危険である。
特に社内SE向けの記事では、読者が実際に手順を試す可能性がある。
そのため、誤った情報や古い仕様が混ざっていないか、必ず確認する必要がある。
AIは下書きを作る係である。
編集長ではない。
実装して感じたこと
OpenAI APIによる本文下書き生成を実装して感じたのは、AI生成の品質は入力の整理でかなり変わるということである。
単にテーマだけを渡すより、記事構成案を渡した方が出力は安定する。
特に、以下の情報があると記事としてまとまりやすい。
- 想定読者
- 検索意図
- 読者の悩み
- 見出し構成
- 本文で触れるべきポイント
- 内部リンク候補
- 注意事項
- 要公式確認の項目
AIは文章を生成するのは得意である。
しかし、何を書くべきかが曖昧なままだと、無難で薄い記事になりやすい。
そのため、本文生成は最後の工程ではなく、構成案と品質チェックに挟まれた中間工程として扱うのがよい。
構成案
↓
本文下書き
↓
品質チェック
この形にすることで、AI生成記事を運用しやすくなる。
自動化しても、人間の確認は残す
今回の自動化では、かなりの工程をPythonとAIで処理している。
しかし、人間の確認は残している。
具体的には、以下の部分で人間が関与する。
テーマ承認
構成案確認
本文レビュー
品質チェック結果の確認
WordPress管理画面での最終確認
公開判断
これは、自動化が不完全だからではない。
むしろ、ブログ運営ではこの方が安全である。
自動化すべきなのは、繰り返し作業や整理作業である。
一方で、記事の責任、読者への配慮、公開判断は人間が持つべきである。
AIで本文が作れるようになったからこそ、確認の仕組みも必要になる。
次の工程は品質チェックである
本文下書きが生成できたら、次は品質チェックである。
チェックする項目は、たとえば以下である。
- 検索意図に合っているか
- 社内SE向けの記事になっているか
- 見出し構成が自然か
- 実務で使える内容か
- 断定しすぎていないか
- 要公式確認が残っているか
- 内部リンク候補があるか
この品質チェックを通して、WordPress下書き登録へ進めるかどうかを判定する。
本文生成ができたからといって、すぐWordPressへ送るわけではない。
その前に、検品台を通すのである。
まとめ
筆者は、承認済みテーマと記事構成案をもとに、OpenAI APIでブログ本文の下書きを生成する仕組みを作った。
ただし、生成した文章は完成記事としては扱わない。
あくまでレビュー前のMarkdown下書きとして保存し、その後に品質チェックを行う設計にしている。
本文生成では、構成案を入力として渡し、想定読者、検索意図、見出し構成、注意事項などを反映するようにした。
また、新規記事、リライト候補、追記候補で出力形式を変えるようにした。
AIに本文を書かせること自体は難しくない。
本当に重要なのは、生成された本文を安全に運用することである。
筆者は、AIを「完成記事を書く存在」ではなく、「レビュー前の下書きを作る存在」として扱う方がよいと考えている。
次回は、生成した本文下書きをそのまま使わず、品質チェックする仕組みについて紹介する予定である。
コメント