はじめに
前回の記事では、記事構成案をもとにOpenAI APIでブログ本文の下書きを生成する仕組みについて書いた。
筆者の自動化ツールでは、承認済みテーマから記事構成案を作り、その構成案をもとに本文下書きを生成する。
しかし、本文下書きが生成できたからといって、それをそのままWordPressへ投稿するわけではない。
AIが生成した文章は、あくまで下書きである。
技術記事では、もっともらしい文章でも、内容が古かったり、環境依存の内容を断定していたり、検索意図から少しずれていたりすることがある。
そこで筆者は、生成した記事下書きを品質チェックする仕組みを作った。
流れとしては以下である。
記事構成案
↓
本文下書き生成
↓
品質チェック
↓
WordPress下書き登録
↓
人間が最終確認して公開
本記事では、この品質チェック機能をなぜ作ったのか、どのような観点でチェックするようにしたのかを紹介する。
AIが書いた文章は、それらしく見える
AIで文章を生成すると、見た目はかなり整った記事が出てくる。
見出しがあり、導入文があり、確認手順があり、まとめもある。
ぱっと見では、十分に使えそうに見える。
しかし、ブログ記事として本当に使えるかは別である。
特に社内SE向けの記事では、以下のような問題が起きやすい。
- 検索意図に対する答えがずれている
- 一般論が多く、実務で使える確認手順が少ない
- 仕様が変わりやすい内容を断定している
- 公式確認が必要な箇所が曖昧である
- 既存記事と内容が重複している
- 内部リンクがない
- アフィリエイト導線が不自然である
- WordPressに登録する前に人間が見るべき点が整理されていない
AIが書いた文章は、文章としては自然でも、記事としては弱いことがある。
そのため、本文下書きの次に品質チェック工程を入れることにした。
品質チェックは自動化のブレーキである
自動化を進めると、どうしても次のように一直線で流したくなる。
テーマ候補
↓
記事構成案
↓
本文生成
↓
WordPress投稿
しかし、この流れは危険である。
AIが生成した本文に問題があっても、そのままWordPressへ流れてしまうからである。
もちろん、最終的にはWordPress管理画面で人間が確認する。
しかし、下書きの段階で問題点が整理されていれば、確認作業はかなり楽になる。
品質チェックは、自動化を止めるためのものではない。
自動化を安全に進めるためのブレーキである。
車でいえば、エンジンを強くするほどブレーキも必要になる。
AIで記事生成を速くするなら、その分だけ検品の仕組みも必要である。
チェック結果は3段階にした
今回の仕組みでは、記事下書きのレビュー結果を大きく3段階に分けた。
pass
needs_revision
fail
それぞれの意味は以下である。
| 判定 | 意味 |
|---|---|
| pass | 大きな問題はなく、WordPress下書き登録へ進める |
| needs_revision | 修正後にWordPress下書き登録を検討する |
| fail | そのまま使わず、再生成や破棄を検討する |
さらに、WordPress下書き登録へ進めるかどうかを wordpress_ready として出力するようにした。
wordpress_ready = yes
→ WordPress下書き登録候補
wordpress_ready = after_revision
→ 修正後に登録候補
wordpress_ready = no
→ 登録しない
このようにしておくと、次工程であるWordPress下書き登録時に、対象記事を絞り込める。
AI記事をすべて同じ扱いにしないことが重要である。
ルールベースチェックとAIレビューを分けた
品質チェックには、大きく2種類を用意した。
ルールベースチェック
OpenAI APIを使った内容レビュー
まずは、OpenAI APIを使わなくても最低限のチェックができるようにした。
ルールベースチェックでは、以下のような項目を見る。
- 文字数
- H2見出し数
- H3見出し数
- 「まず結論」があるか
- 「確認手順」があるか
- 「まとめ」があるか
- 「レビュー時の確認事項」があるか
- 「要確認」または「要公式確認」が残っているか
- 内部リンク候補があるか
- リスクの高い断定表現が多すぎないか
- Markdown構造が大きく崩れていないか
一方、OpenAI APIを使った内容レビューでは、より文章の中身に近い部分を見る。
- 検索意図と記事内容が合っているか
- 社内SE向けの記事になっているか
- 実務で役に立つか
- 誤情報リスクがありそうな箇所
- 断定しすぎている箇所
- 公式確認が必要な箇所
- 追記した方がよい内容
このように、機械的に見られる部分と、意味を見た方がよい部分を分けた。
毎回OpenAIレビューを使うとAPI利用量も増えるため、まずはルールベースで確認し、必要に応じてAIレビューを使う形が現実的である。
スコアを付けて可視化する
レビュー結果には、100点満点のスコアも付けるようにした。
チェック項目は以下のようなものにした。
search_intent
reader_fit
structure
practical_value
factual_risk
originality
internal_links
readability
それぞれの意味は以下である。
| 項目 | 見る内容 |
|---|---|
| search_intent | 検索意図に合っているか |
| reader_fit | 社内SE・情シス向けになっているか |
| structure | 見出し構成が自然か |
| practical_value | 実務で使える内容か |
| factual_risk | 不確かな断定が多くないか |
| originality | 既存記事と重複しすぎていないか |
| internal_links | 内部リンク候補があるか |
| readability | 読みやすいか |
スコアはあくまで目安である。
ただ、記事下書きが増えてくると、どれから直すべきか分かりにくくなる。
そのとき、スコアや判定があると優先順位を付けやすい。
断定しすぎる表現を検出する
技術記事で特に気を付けたいのは、断定しすぎる表現である。
たとえば、次のような表現は注意が必要である。
必ず
絶対
100%
完全
間違いなく
最新
永久
もちろん、すべてが悪いわけではない。
しかし、Microsoft 365、Windows、WordPress、セキュリティ設定などは、環境や時期によって変わることがある。
そのため、AIが「必ず直る」「絶対にこの手順でよい」と書いている場合は注意した方がよい。
今回の品質チェックでは、こうしたリスクのある表現を検出し、レビュー対象にするようにした。
AIは堂々と断定することがある。
その堂々とした顔つきに油断してはいけない。
要公式確認を残す
AI生成記事では、公式情報の確認が必要な箇所を明示することも重要である。
たとえば、次のような内容は要確認になりやすい。
- Microsoft 365の管理画面の項目名
- WordPress REST APIの仕様
- Google Search Console APIの制限
- Windowsの設定画面
- セキュリティ関連の仕様
- 料金やライセンスに関する情報
今回の仕組みでは、本文下書きの中に「要公式確認」や「実機確認」などのマーカーを残せるようにした。
品質チェックでは、これらが残っているかも確認する。
これは一見すると、未完成な記事を示すマーカーに見える。
しかし、筆者はむしろ必要なものだと考えている。
AIに不確かな部分を勝手に埋めさせるより、「ここは確認が必要」と残しておく方が安全である。
Markdown構造も確認する
記事下書きはMarkdownで保存している。
そのため、品質チェックではMarkdown構造も確認する。
たとえば、以下を見る。
- H1があるか
- H2が一定数あるか
- 見出しの階層が崩れていないか
- コードブロックが壊れていないか
- front matterがあるか
- タイトルやdescriptionが取れるか
Markdownが崩れていると、WordPress投稿時に表示が乱れる可能性がある。
特に、コードブロックやリストが多い技術記事では、Markdown構造の確認は重要である。
文章の中身だけでなく、形式もチェック対象にした。
出力ファイルを分けた
品質チェック結果は、複数のファイルに分けて出力するようにした。
主な出力先は以下である。
outputs/draft_reviews/
outputs/draft_review_summary.csv
outputs/draft_review_report.md
outputs/draft_reviews/ には、記事ごとの個別レビューMarkdownを保存する。
outputs/draft_review_summary.csv には、全記事のスコアや判定を一覧で保存する。
outputs/draft_review_report.md には、全体のレビュー結果をレポートとしてまとめる。
このように分けることで、機械処理にも人間確認にも使いやすくなる。
CSVは次工程のWordPress下書き登録で使う。
Markdownレポートは、人間が確認するために使う。
自動化では、人間向けの見やすいレポートを残すことも大事である。
WordPress下書き登録へ進めるかを判定する
品質チェックの目的は、単に点数を付けることではない。
次の工程へ進めるかを判断することである。
今回の仕組みでは、draft_review_summary.csv に wordpress_ready を出力するようにした。
yes
after_revision
no
WordPress下書き登録では、この値を見て対象を絞る。
wordpress_ready = yes
→ 投稿候補
wordpress_ready = after_revision
→ 必要に応じて投稿候補
wordpress_ready = no
→ 投稿しない
これにより、品質チェックを通っていない記事がWordPressへ流れるのを防げる。
自動化の中に関所を作るイメージである。
Codexには何を作らせたか
この品質チェック機能もCodexに作らせた。
依頼した内容は、ざっくり言えば以下である。
outputs/article_drafts/ のMarkdownを読み込む
ルールベースで品質チェックする
必要に応じてOpenAI APIレビューも使えるようにする
スコアと判定を出す
個別レビューMarkdownを出力する
全体サマリーCSVを出力する
全体レポートMarkdownを出力する
wordpress_ready を出す
実行イメージは以下である。
python scripts/review_article_drafts.py --all --limit 3
OpenAI APIを使ったレビューを行う場合は、以下のようにする。
python scripts/review_article_drafts.py --all --limit 3 --use-openai-review
最初はOpenAIレビューなしで、ルールベースだけを試す。
問題なければ、必要に応じてOpenAIレビューも使う。
このように段階を分けることで、API利用量を抑えつつ、品質確認の流れを作れる。
実装して感じたこと
品質チェック機能を作って感じたのは、AI記事生成では「生成」よりも「検品」の方が重要かもしれないということである。
AIは文章を作るのが得意である。
しかし、作られた文章をどう扱うかは別問題である。
ブログ運営では、下書きが増えるほど、確認作業が重くなる。
そのとき、品質チェックレポートがあると、どの記事を直すべきか、どの記事をWordPressに送ってよいか判断しやすくなる。
特に、以下のような情報が一覧で見られるのは便利である。
- review_status
- total_score
- wordpress_ready
- main_issues
- next_action
- 要公式確認の数
- リスク表現の数
これらがあると、AIが作った下書きをただ読むのではなく、レビュー対象として整理できる。
自動化の最後に人間確認を残す
品質チェックを入れても、最終確認は人間が行う。
これは変えない。
今回の仕組みでは、WordPress下書き登録後も、自動公開はしない。
最終的には、WordPress管理画面で以下を確認する。
- タイトル
- 本文
- 見出し構成
- 内部リンク
- アイキャッチ
- カテゴリ
- タグ
- 広告表記
- 公式情報の確認
- 実機確認が必要な箇所
AIとPythonでできるところはかなり増えた。
しかし、公開判断まで自動化するつもりはない。
読者に対して責任を持つのは、AIではなく筆者である。
まとめ
筆者は、OpenAI APIで生成したブログ本文をそのまま使わず、品質チェックする仕組みを作った。
チェック項目は、検索意図、読者適合、見出し構成、実務性、誤情報リスク、内部リンク、アフィリエイト導線、読みやすさなどである。
結果は、pass、needs_revision、fail に分け、さらに wordpress_ready としてWordPress下書き登録へ進めるかを判定するようにした。
AIが書いた文章は、それらしく見える。
しかし、それをそのまま公開するのは危険である。
AI記事生成を運用に乗せるなら、本文生成と同じくらい、品質チェックの仕組みが重要である。
筆者は、AIを「公開記事を作る存在」ではなく、「レビュー前の下書きを作る存在」として扱っている。
そして、その下書きを品質チェックし、人間が確認してから公開する。
この流れにすることで、AIによる効率化と記事品質のバランスを取りやすくなる。
次回は、品質チェックを通った記事をWordPressへ下書き登録する仕組みについて紹介する予定である。
コメント