Notionで管理した記事をWordPressへ自動で下書き保存する方法｜プラグイン不要

2026年8月18日2026年9月27日

ブログの記事が増えると、「次に何を書くか」「どこまで進んでいるか」「いつ公開したか」を管理するだけでも手間がかかります。

ぼくは、記事の進み具合や検索キーワードをNotionで管理し、本文はローカルのMarkdownファイルで作成しています。完成した原稿は、Claude Codeで作成したPythonスクリプトからWordPressへ下書きとして送ります。

使っているのは、Notion APIとWordPress REST APIです。WordPressの連携プラグインや、有料の自動化サービスは使っていません。

この記事では、Notion・Markdown・WordPressをどのように分けているか、下書きを送るまでの流れ、WordPressで修正した内容を上書きしないための対策を紹介します。

※ボタンを押さなくても自動で動き続ける仕組みではありません。スクリプトを1回実行すると、対象の記事がWordPressへ下書き保存される運用です。

この仕組みでできること

この仕組みを作ると、次の作業をまとめて行えます。

Notionで記事の進み具合、検索キーワード、公開日、URLを管理する
Markdownで作成した本文をWordPressへ下書き保存する
タイトル、カテゴリー、スラッグなどを記事データから設定する
公開後のURLと公開日をNotionへ戻す
WordPress側に新しい修正がある場合は、上書きする前に処理を止める

記事を書く作業そのものを自動化する仕組みではありません。記事の管理と、WordPressへ移す作業を減らすためのものです。

Notion・Markdown・WordPressの役割を分ける

記事の情報をすべて1か所へ集めるのではなく、次のように分けています。

場所	管理するもの	主な内容
Notion	記事の進行管理	ステータス、検索キーワード、カテゴリー、公開日、URL
ローカルのMarkdown	WordPressへ送る前の本文	執筆、修正、Gitによる変更履歴
WordPress	下書きの確認と公開	プレビュー、アイキャッチ、内部リンク、予約・公開
Pythonスクリプト	データの受け渡し	Notionの情報取得、本文変換、下書き保存、公開情報の更新

Notionは記事一覧の管理に使い、本文はMarkdownファイルに保存します。WordPressは、実際の表示を確認して公開する場所です。

Pythonスクリプトは、NotionとMarkdownから必要な情報を読み取り、WordPress REST APIへ送ります。

Notion、Markdown、Python、WordPressを連携する流れを示した図

なぜNotionだけで本文を書かないのか

Notionの本文をWordPressへ同期する方法もあります。WP Sync for Notionの無料版では、Notionページの本文や対応ブロックをWordPressへ同期できます。

ただ、ぼくは次の理由から、本文をローカルのMarkdownファイルへ分けました。

Claude Codeから複数の記事ファイルをまとめて扱いたい
Gitで変更履歴を残したい
ファイル名と記事IDを対応させたい
Notionの項目を自分の運用に合わせて増減したい
WordPressへ送るブロックの形を自分で制御したい

Notionで本文を書きたい場合は、プラグインを使うほうが簡単です。今回の方法は、Notionを記事管理に使い、本文をファイルとして管理したい人に向いています。

用意するもの

この仕組みでは、次のものを使います。

記事を管理するNotionのデータベース
Pythonを実行できる環境
WordPress REST APIへ接続するための認証情報
Notion APIのインテグレーション
Markdownで作成した記事ファイル

WordPressへの接続には、通常のログインパスワードではなく、アプリケーションパスワードを使います。認証情報はコードへ直接書かず、環境変数や1Passwordなど、Gitの管理対象に入らない場所から読み込ませます。

Notion APIでは、2025年9月3日版から「データベース」と「データソース」が分かれました。現在のAPIで項目の定義や記事一覧を扱う場合は、データベースIDだけでなくdata_source_idを使います。以前のAPIを前提にしたコードを参考にする場合は、この違いを確認してください。

Notionに記事管理用の項目を作成する

Notionには、記事本文ではなく、記事を管理するための情報を保存します。

ぼくが使っている主な項目は次のとおりです。

項目	保存する内容
Article ID	Markdownファイルと対応させる記事番号
Title	記事タイトル
Status	アイデア、執筆中、確認中、公開済みなど
Target Keyword	狙う検索キーワード
Cluster	記事をまとめるテーマ
Content Type	手順、比較、解説などの記事形式
WordPress Post ID	作成されたWordPress投稿のID
Blog URL	公開後の記事URL
Published Date	公開日

すべての項目を最初から用意する必要はありません。下書きを送るだけなら、Article ID、Title、Statusがあれば始められます。

Notionの記事管理画面。タイトル・Article ID・Status・検索キーワードなどを一覧で管理している

WordPressへ下書きを保存するまでの流れ

普段は、次の5つの手順で進めています。

STEP

Notionに記事を登録する

Notionの記事一覧へ新しいページを追加します。

最初に入力するのは、記事ID、仮タイトル、ステータス、検索キーワード、記事の種類などです。記事を書き始めたら、ステータスを「執筆中」へ変更します。

Notionを開けば、どの記事がアイデアの段階で、どの記事が確認中なのかを一覧で確認できます。

STEP

Markdownで本文を作成する

本文は、次のようなファイル名で保存します。

content/drafts/<Article ID>-<slug>.md

たとえば、記事IDがA8なら次のようにします。

content/drafts/A8-notion-to-wp-pipeline.md

記事IDをNotionとファイル名の両方へ入力しておくと、スクリプトから対応する記事を見つけやすくなります。

STEP

スクリプトを実行してWordPressへ送る

原稿ができたら、Pythonスクリプトを実行します。

python3 scripts/notion_to_articles.py

スクリプトは、Notionからタイトルやカテゴリーなどを取得し、対応するMarkdownファイルをWordPress用の本文へ変換します。その後、WordPress REST APIの/wp-json/wp/v2/postsへ送ります。

このとき、投稿状態は必ずdraftにします。公開済みの記事を誤って更新しないよう、対象の記事IDと現在の状態も確認してから送信します。

初回はWordPressへ投稿を新規作成し、返ってきた投稿IDをNotionへ保存します。2回目以降は、その投稿IDを使って同じ下書きを更新します。投稿IDを保存しないと、実行するたびに下書きが増えるため注意が必要です。

STEP

WordPressで表示を確認する

下書きが作成されたら、WordPressの編集画面とプレビューを確認します。

主に見るのは次の項目です。

見出し、段落、リストが正しいブロックになっているか
画像が表示されているか
パソコンとスマートフォンで崩れていないか
アイキャッチ、カテゴリー、内部リンクが合っているか
SEO SIMPLE PACKなど、REST APIから設定していない項目が残っていないか

スクリプトがエラーなく終了しても、実際の表示が正しいとは限りません。公開前の確認はWordPressで行います。

STEP

公開情報をNotionへ戻す

WordPressで公開したあと、投稿ID、記事URL、公開日をNotionへ反映します。

これで、Notionの記事一覧から、公開済みの記事とURLを確認できます。公開後に毎回入力するのではなく、WordPress REST APIから取得した値を使います。

WordPressで直した内容を上書きしないためのルール

この運用で最も注意したいのは、WordPressで直接直したあとに、古いMarkdownをもう一度送ってしまうことです。

全文をそのまま送り直すと、WordPressで追加した文章やリンクが消える可能性があります。

そのため、次のルールを決めています。

公開前はMarkdownを本文の基準にする

WordPressへ送る前の修正は、原則としてMarkdownで行います。WordPressはプレビューと、WordPress側でしか設定できない項目の確認に使います。

修正場所を1つに決めておけば、同じ記事に異なる内容が残りにくくなります。

WordPress側が更新されていたら処理を止める

WordPressの投稿には、最後に更新された日時を表すmodified_gmtがあります。

下書きを送った時点の更新日時や本文のハッシュをローカルへ保存しておき、次の実行前に現在の値と比べます。WordPress側だけが更新されていた場合は、自動で上書きせず処理を止めます。

WordPress側に新しい変更があります。
本文を取得して差分を確認してから、もう一度実行してください。

この確認を追加しておけば、編集画面で加えた変更を古い原稿で上書きする事故を減らせます。

一部分だけ直す場合も、置換件数を確認する

WordPressから最新の本文を取得し、特定の文章だけを書き換える方法もあります。ただし、単純なstr.replace()は、同じ文章が複数あると意図しない場所まで変更します。

置換する場合は、次の条件を設けます。

変更前の文字列が1か所だけに存在することを確認する
0件または2件以上なら更新を止める
送信前に差分を表示する
更新前の本文をバックアップする
公開済み記事ではなく、まず下書きで試す

old = "<h2>古い見出し</h2>"
new = "<h2>新しい見出し</h2>"

if content.count(old) != 1:
    raise ValueError("置換対象を1か所に特定できません")

updated = content.replace(old, new, 1)

取得時にcontext=editを指定すると、編集権限のある認証情報を使っている場合に、投稿の編集用データを取得できます。

WordPressからMarkdownへ戻すときは差分を確認する

WordPressの本文は、ブロックの区切りを含んだHTMLとして保存されています。SWELL独自ブロックやカスタムHTMLを使っている場合、Markdownへ変換すると一部の属性や構造が失われることがあります。

そのため、WordPressから取得した本文でMarkdownを自動的に置き換えるのではなく、次のどちらかにします。

WordPressのcontent.rawをHTMLのバックアップとして保存する
Markdownへ変換したあと、Gitの差分を確認してから反映する

「逆同期を実行すれば必ず同じ内容になる」とは考えず、変換後の差分を確認します。

Claude Codeには、小さい機能から順に作成を依頼した

スクリプトは、Claude Codeへ次の順番で作成を依頼しました。

Notionから記事を1件取得して表示する
Markdownファイルを1件読み込む
WordPressへ1件だけ下書き保存する
作成された投稿IDをNotionへ戻す
公開後のURLと公開日をNotionへ反映する
WordPress側の更新を検知して、上書きを止める
一連の処理を1回の実行で動かす

最初から「NotionとWordPressを同期するツールを作って」とだけ頼むと、どこで失敗したのか分かりにくくなります。取得、変換、送信、更新確認を分け、1つずつ動作を確認しました。

たとえば、WordPressへの下書き保存は次のように依頼できます。

Markdownの記事をWordPress REST APIで下書き保存するPythonスクリプトを作成してください。

要件：
- 投稿状態は必ずdraftにする
- 新規作成後の投稿IDを保存する
- 同じ投稿IDがある場合は、新規作成せず更新する
- 送信前にタイトルと対象URLを表示する
- 認証情報をコードやログに表示しない
- タイムアウトとHTTPエラーを処理する
- WordPress側に新しい変更がある場合は、上書きせず停止する

Claude Codeが作ったコードも、そのまま本番へつながず、テスト用の記事1件で確認します。