PR
AIで記事作成を効率化したいなら → 高品質SEO記事生成AIツール【Value AI Writer byGMO】
※本記事は、2026年9月に実際に構築・運用した自動化パイプラインの記録です。APIの仕様・料金は変更される可能性があります。
この記事でわかること
- NotebookLMのスライドPDFを、ブログ記事に自動変換するパイプラインの全手順
- テキストが画像に焼き付いたスライドから文字を取り出す方法（macOS標準のVision OCR）
- AIが混ぜてくる「それっぽい嘘」を記事に載せる前に検閲する仕組み（ファクトチェックのW検証）
- WordPress下書きの自動作成と、Pinterest用の縦型画像の自動生成まで
作ったパイプラインの全体像
[手動] NotebookLM にソース投入 → スライド生成 → PDF書き出し
↓
[自動] PDF解析（poppler）→ ページを画像化
↓
[自動] 画像OCR（macOS Vision）で文字を抽出
↓
[自動] ★ファクトチェック（固有名詞を1つずつWeb照合）
↓
[自動] 既存ブログのイラストを流用して記事を組み立て
↓
[自動] WordPress REST API で下書き作成（slug・タグ・アイキャッチ）
↓
[自動] 検証（画像200・内部リンク200・canonical・noindex）
↓
[自動] Pinterest用の縦型ピンを生成 → OCRで文字化け検証 → 投稿ポイントは、手作業をNotebookLMの1箇所だけに押し込むことです。それ以外はすべて自動化できます。
使用環境
| OS | macOS（Apple Silicon） |
| 実行環境 | OpenClaw（Node.js 26 / Python 3） |
| PDF処理 | poppler（brew install poppler） |
| 画像生成 | Pillow + ヒラギノ角ゴシック W6 |
| OCR | macOS Vision フレームワーク（JXA経由） |
| 投稿先 | WordPress REST API / Pinterest API v5 |
ステップ0：なぜNotebookLMを前提にするのか
NotebookLMは公開APIを提供していません（2026年9月時点）。つまり「全部自動」は原理的に不可能です。
そこで設計を逆転させます。「手動が必須なのはNotebookLMだけ」と決めてしまい、その前後をすべて自動化するのです。人間の作業は「ソースを入れてスライドを生成し、PDFを書き出す」の10分程度になります。
このとき最も重要なのがソース設計です。NotebookLMはソースに書かれていないことを答えません。「鎌倉のおすすめグルメ」を出したいなら、グルメ情報のソースを必ず入れておく必要があります。
ステップ1：既存ブログのイラストを資産として使う
旅のしおり記事には、AI生成した美少女イラストを挿絵として使います。ここで新規に画像生成しないのがコツです。
メインブログにすでに「鎌倉の旅コーデ3選」の記事があり、画像が3枚アップロード済みでした。これをそのまま流用します。得られる効果は3つです。
- 生成コストがゼロ（画像生成APIを呼ばない）
- 内部リンクで回遊が生まれる（コーデ記事 ⇄ しおり記事）
- 既存記事の評価が上がる（被リンクが増えるため）
記事側では、既存画像をwp-image-ID付きで貼り、altテキストも既存のものを引き継ぎます。
ステップ2：公式ソースを入れてハルシネーションを潰す
スライドの信頼性は、投入したソースの質でほぼ決まります。実際に使ったソースは次のとおりです。
- 観光協会の公式サイト（エリア全体の情報）
- 神社・寺の公式サイト（御朱印の受付時間など一次情報）
- 鉄道会社の公式サイト（交通手段）
- 自ブログの既存記事（世界観とトーンを揃えるため）
「LLMの知識」に頼らせないことが、結果的にいちばん品質を上げます。
ステップ3：スライドPDFを画像に変換する
まずPDFの構造を確認します。
$ brew install poppler
$ pdfinfo Kamakura_Lookbook.pdf
Pages: 12
Page size: 1376 x 768 pts
$ pdftotext -layout Kamakura_Lookbook.pdf -
\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0cここでテキスト抽出が空になるのがポイントです。NotebookLMのスライドは1ページ＝1枚のラスター画像として書き出されるため、PDFから文字を取り出すことはできません。
そこでページを画像化します。
$ pdftoppm -png -r 130 Kamakura_Lookbook.pdf slides/slide
$ sips -g pixelWidth -g pixelHeight slides/slide-01.png
pixelWidth: 2485
pixelHeight: 1387ステップ4：画像から文字を取り出す（macOS Vision OCR）
画像をそのままモデルに読ませる手もありますが、使用モデルが画像入力に対応していない場合や、文字だけを機械的に扱いたい場合はOCRが有効です。
macOSにはVisionフレームワークが標準で入っており、日本語OCRの精度も実用十分です。外部ライブラリのインストールは不要で、JXA（JavaScript for Automation）から呼び出せます。
ObjC.import('Vision');
const handler = $.VNImageRequestHandler.alloc.initWithURLOptions(url, $());
const request = $.VNRecognizeTextRequest.alloc.init;
request.recognitionLevel = 0; // 0 = accurate
request.recognitionLanguages = ['ja-JP', 'en-US'];
request.usesLanguageCorrection = true;
handler.performRequestsError($([request]), $());実行はこれだけです。
$ osascript -l JavaScript ocr.jxa slides/slide-01.png
鎌倉で美少女と巡る2泊3日
旅のしおり
AIが描く旅コーデと、海と古社を味わう大人女子のモデルコース
…12枚すべて、日本語の見出し・本文・箇条書きまで読み取れました。「画像しか読めない資料」をテキストとして扱えるようにするのがこのステップの目的です。
ステップ5：【核心】AIの嘘を検閲する「Wチェック」
ここが本記事でいちばん伝えたい部分です。
スライドには、店名・創業年・受付時間といった固有名詞と数字が含まれていました。生成AIはこうした情報を、いかにも正しそうな顔で間違えて出力します。それをそのまま記事に載せれば、読者の信頼を一発で失います。
やったこと：固有名詞を1つずつ外部照合する
OCRで取り出した固有名詞を、1件ずつWebで裏取りしました。実際の検証結果です。
| スライドの記載 | 外部照合の結果 | 判定 |
|---|---|---|
| こ寿々（手打ち蕎麦・わらび餅） | 老舗そば処。わらび餅が名物として実在 | 採用 |
| キャラウェイ（欧風カレー） | 小町通り周辺の行列店として実在 | 採用 |
| 茅木家（1931年創業・備長炭うなぎ） | 若宮大路の鰻老舗。昭和6年＝1931年創業と一致 | 採用 |
| 鎌倉のごはんやさん 石渡（しらす丼） | 若宮大路の海鮮丼店として実在 | 採用 |
4件すべてが実在し、創業年の数字まで一致しました。この一致率が確認できるまで公開しないというルールで運用しています。
Wチェックの2段構え
- 入力側：ソースに無い情報は書かない（NotebookLMの性質を利用）
- 出力側：出力に含まれる固有名詞は必ず外部照合する
この2つを重ねることで、「AIが勝手に補完した情報」を公開前に落とせます。疑わしいものは載せない——これが鉄則です。1つのお店の情報を間違えるだけで、記事全体の信頼が失われます。
同じ考え方は、後述の画像の文字化け検証にも使っています（生成した画像をOCRで読み返して、意図した文字が正しく描かれているか確認する）。
ステップ6：WordPressの下書きをREST APIで自動作成
記事本文を組み立てたら、WordPress REST APIで下書きを作成します。ここで必ず同時に指定すべき項目があります。
POST /wp-json/wp/v2/posts
{
"title": "【2026年秋】鎌倉2泊3日 旅のしおり｜美少女AIコーデで巡るモデルコース",
"slug": "kamakura-2days-tabi-shiori-model-course",
"content": "<p>…</p>",
"status": "draft", // 必ず明示する
"categories": [232],
"tags": [1459, 1677, 1678], // タグを忘れると後で面倒になる
"featured_media": 3192,
"excerpt": "…"
}statusを省略すると、意図せず公開状態になる事故が起きます。draft を必ず明示してください。tagsは忘れがちです。slug とタグは作成時に同時に指定するのが安全です。
なお、既存のタグ名を指定すると term_exists エラーが返りますが、レスポンスに既存の term_id が含まれるので、それをそのまま使えばOKです。
ステップ7：スライドは冒頭で「めくれる」形にする
生成したスライドは、そのまま画像として貼るよりPDFフリップブックとして冒頭に置くほうが体験が良くなります。WordPressのDFlipプラグインなら、ショートコード1行です。
[dflip id="3205"][/dflip]読者は記事を読む前に概要を掴めますし、本文にはテキストとして同じ情報が残るため、SEO的にも二重に効きます。
ただし、今回のPDFは12.8MBありました。表示速度に影響するため、画質を保ったまま3〜4MB程度に圧縮することをおすすめします。
ステップ8：Pinterest用の縦型画像を自動生成して投稿する
最後は集客です。Pinterestは縦型2:3（1000×1500）が最も有利ですが、ブログの挿絵は横型が普通です。そこで専用のピン画像を生成します。
canvas = Image.new("RGB", (1000, 1500), CREAM) # 2:3
d.rectangle([0, 0, W, 16], fill=ACCENT) # 上アクセント
center_text(d, 90, "鎌倉 2泊3日", font_w6, INK) # 大きなタイトル
canvas.paste(photo, (px, py)) # 挿絵を中央に
# …箇条書き・フッターを描画フォントはヒラギノ角ゴシック W6を使用します。絵文字や一部の記号はグリフが無く豆腐（□）になるため、記号なしのテキストのみで構成するのが安全です。
そして生成後は、その画像をOCRで読み返して文字化けゼロを確認します。これもWチェックの一種です。
投稿はimage_base64が確実
Pinterest API v5は、公開URLからの取得（image_url）のほかに、画像そのものをbase64で送る方式に対応しています。
{
"board_id": "…",
"media_source": {
"source_type": "image_base64",
"content_type": "image/png",
"data": "<base64>"
},
"title": "鎌倉2泊3日 旅のしおり｜鶴岡八幡宮の美少女AIコーデ",
"link": "https://www.conomacn.com/kamakura-2days-tabi-shiori-model-course/"
}当初は画像をWordPressメディアにアップロードして、そのURLを渡す方式で組みました。ところがセキュリティプラグイン（SiteGuard Lite）に403でブロックされ、リトライしても不安定でした。
image_base64 に切り替えると、WordPressへのアップロード自体が不要になり、この問題は根本的に消えます。3ピンすべて一発で投稿できました。
ステップ9：公開前にHTTPで機械的に検証する
「多分できている」を排除するため、公開前に以下をすべて機械的に確認します。
- 本文画像・アイキャッチが 200 を返すか
- 内部リンクがすべて 200 か（リダイレクト先も含めて）
canonicalが正しいURLを指しているかnoindexが付いていないか- slug・タグ・カテゴリ・アイキャッチが設定されているか
今回の記事では、画像3枚・内部リンク5本（本家4＋TECH1）・アフィリエイトリンク3本がすべて200であることを確認してから公開しました。
実際にハマったポイント
- スライドのテキストが取れない：NotebookLMのスライドは全面ラスター画像。
pdftotextは空を返すので、OCR前提で設計する。 - セキュリティプラグインの403：記事本文や画像のREST POSTが断続的に弾かれる。待って再試行するか、そもそも送信方式を変える（画像ならbase64）。
- WPタイトルを変えても検索結果が変わらない：SEOプラグイン側のSEOタイトルが別に設定されているため。管理画面で確認が必須です。
- タグの付け忘れ：後から気づくと記事ごとに手作業が発生する。作成時に同時指定する。
運用するとこうなる
| 作業 | 担当 | 時間 |
|---|---|---|
| ソース投入・スライド生成・PDF書き出し | 人間 | 約10分 |
| PDF解析・OCR・ファクトチェック | 自動 | 数分 |
| 記事組み立て・下書き作成・検証 | 自動 | 数分 |
| 公開判断 | 人間 | — |
人間が介在するのは「ソースを選ぶ」と「公開を決める」の2箇所だけです。この2つは、品質と責任に関わる部分なので、あえて自動化していません。
まとめ
- NotebookLMにAPIは無い。だから手動を1箇所に集める設計にする
- スライドは画像。文字はmacOS Vision OCRで取り出す
- ソースに無いことは書かせない＋出力は外部照合するのWチェックで、AIの嘘を公開前に落とす
- 生成した画像もOCRで読み返して検証する（文字化け・記号問題）
- 投稿はREST APIで status・slug・タグを明示して下書き作成
- 検証はHTTPステータスで機械的に。人の目視に頼らない
関連記事
ブログ画像3枚からYouTubeショート動画を全自動で作る方法｜BGM生成×テロップ×YouTube API連携の全手順
Pinterest APIでブログ記事を90件まとめて自動ピン化してみた！OpenClaw×Pinterest連携のセットアップ