CodexでWordPressブログを管理する方法｜Easy MCP AIで執筆・投稿・更新をつなぐ

Codexでブログ運用。WordPressとGitHubをつなぐ説明用イラスト。実際の操作画面ではありません AI活用

僕のブログでは、記事の相談、リサーチ、執筆、画像の登録、投稿、既存記事の修正までをCodexと進めています。この記事では、その作業環境を自分のWordPressに作り、下書き1本を保存して、確認後に公開するところまでを説明します。

使うのは、Codexのクラウド環境、GitHub、WordPressプラグインのEasy MCP AI、そしてPythonの小さな運用コードです。CocoonのSEO設定も扱いたい場合だけ、僕の環境で使っている追加プラグインを入れます。

対象は、プラグインを導入できるWordPressをすでに持っている人です。コマンドはCodexに実行してもらえます。ローカルPCへCodex CLIをインストールする手順とは異なります。

先に完成形：自分のメモを渡す → Codexが原稿と画像を用意する → WordPressへ下書き保存 → 内容と画面を確認 → 公開 → 原稿・変更記録・引き継ぎを非公開GitHubへ保存、という流れを作ります。

確認日：2026年10月12日。Easy MCP AI 2.1.1、Cocoon Child 1.1.3、Python 3.12の環境で検証。画面名や提供範囲は更新されることがあるため、設定箇所には公式資料も併記します。

1．このブログでは、何をCodexに任せているのか

たとえば、実験レポートの骨格を作るワークフローの記事は、僕が「何を面倒だと感じたか」「どこまで試したか」「実際の大学のPDFは公開できない」という情報を伝え、公開可能な架空サンプルを使って記事にしました。

Codex側では、公開リポジトリと説明の照合、原稿、画像登録、下書き保存、表示検査、投稿、関連記事へのリンク、GitHubへの記録を進めています。本人しか分からない体験や公開範囲は、僕が伝えます。

Codex CloudのPythonクライアントからEasy MCP AIを通してWordPressへ投稿し、原稿と履歴は非公開GitHubへ保存する構成図
このブログの構成。図中のGitHubは原稿と記録の保存先で、pushしただけで記事が投稿される仕組みではありません。
部品 担当すること
Codex Cloud 調査・原稿・コード実行・検証を行う作業場所
非公開GitHub 原稿、執筆方針、コード、変更前後、次の作業を保存
Pythonクライアント 接続確認、変更計画、WordPressへの送信、保存結果の再取得
Easy MCP AI WordPress側のMCP接続口。ユーザーとトークンに応じて操作を制限
Cocoon SEO Bridge〈任意〉 CocoonのSEOタイトルと説明文の2項目をAPIへ登録

MCPは、AIが外部の道具を使うための接続方式です。この構成では、CodexがPythonを実行し、そのコードがWordPressのMCP接続口へ通信します。チャット画面にWordPressの操作ボタンが直接増える方式ではありません。

記事・画像・内部リンクは扱えますが、ASP管理画面の操作、Search Consoleの分析、テーマの自由な変更、サーバー全体の復元まで、この接続だけで完了するわけではありません。必要な道具と権限を、その作業ごとに確認します。

2．必要なものと配布ファイル

  • HTTPSで公開しているWordPress：最初にプラグインを入れられる管理者権限が必要です。WordPress.comなどでは、利用プランのプラグイン対応も確認します。
  • Codex Cloudを利用できるアカウント：クラウド環境とGitHub接続を使えることを確認します。利用枠・料金は契約によって異なります。
  • GitHubアカウント：運用用には非公開リポジトリを使います。
  • Python 3.12以上：自分のPCではなく、今回使うクラウド環境に用意します。配布コードの投稿処理は標準ライブラリだけで動きます。

接続用のEasy MCP AIはWordPress公式ディレクトリで配布されています。この記事のテンプレートとSEO Bridgeも無料配布です。WordPressのサーバー・ドメイン費用やCodexの利用料金は別です。

まだWordPressを持っていない場合は、先にWordPressブログに必要なサーバー・ドメイン・費用を確認してください。すでにブログがある人は、そのサイトを接続できます。

配布ファイル v1.0.0

テンプレートはGitHubへ置くもの、SEO BridgeはWordPressへインストールするものです。入れる場所を取り違えないようにしてください。

配布ZIPにはダミーの接続先、サンプル原稿、README、AGENTS.md、Pythonコード、テスト、空の引き継ぎを入れました。このブログの下書き、広告コード、認証情報は含みません。使用後は自分の非公開データが増えるため、作業リポジトリを公開しないでください。

僕の運用環境にはサイト全体の表示検査などもありますが、入門テンプレートは投稿・PNG画像・更新・任意のCocoon SEO・変更前後の照合に絞っています。ブラウザの自動検査や売上計測は同梱していません。

3．Easy MCP AIを導入し、APIトークンを作る

プラグインを有効化する

  1. WordPress管理画面を開き、プラグイン → 新規追加へ進みます。
  2. Easy MCP AIを検索し、公式ディレクトリのプラグインと一致することを確認します。
  3. 「今すぐインストール」→「有効化」を選びます。
  4. 管理画面のEasy MCP AI → Connectionsを開き、サイトの接続先を確認します。

ドメイン直下のWordPressなら、接続先は次の形式です。example.comは自分のサイトへ置き換えます。WordPressをサブディレクトリへ設置している場合は、管理画面が示すURLを優先してください。

https://example.com/wp-json/easy-mcp-ai/v1/mcp

このURLをブラウザで開けるかだけでは、認証付きの投稿ができるかは分かりません。後で配布コードのdoctorを使って接続を確認します。

投稿に使うユーザーとCustom権限を選ぶ

Connections → API tokens → Create tokenを開きます。Token NameにはCodex Blogなど用途が分かる名前を付けます。WordPress Userには、これからCodexが操作するときのユーザーを選びます。

自分が作成した投稿だけなら「投稿者」、他の投稿も含めた編集なら「編集者」が候補です。既存の本人名義の記事を更新する場合は、その記事を編集できるユーザーかも確認します。最初のプラグイン導入に使う管理者と、日常の執筆用ユーザーは分けて考えられます。

Access levelはCustomを選び、次を許可します。表示名が違っても、ツール名で照合してください。

用途 必要なツール
記事を探す・読む wp_list_posts、wp_get_post
カテゴリを調べる wp_list_categories
下書き作成・記事更新・公開 wp_create_post、wp_update_post
画像登録・登録結果の確認 wp_upload_media、wp_get_media
CocoonのSEOを扱う場合だけ追加 wp_get_post_meta。書き込みは上記のwp_update_postを使用

有効期限もこの画面で設定します。期限を設けた場合は、失効時に接続できなくなることを運用記録へ残します。作成後に表示されるトークンは、次の節のNetwork secretのValue欄へ保存してください。会話、GitHub、記事、スクリーンショットには載せません。

今回使うのはEasy MCP AIが発行するAPIトークンです。WordPressのアプリケーションパスワードやOpenAI APIキーを追加発行する手順ではありません。

設定画面の実物は、公式のAPIトークン作成ガイド（画面画像付き）でも確認できます。

僕の環境で詰まったのは、サイト全体の許可設定だった

このブログでは、トークンで編集操作を選んだ後も、必要な編集ツールを取得できない段階がありました。Easy MCP AI全体のWhitelist ToolsとDisabled Toolsも確認する必要があったためです。

Easy MCP AI → Settingsで、必要な操作が全体設定で除外されていないか見ます。Whitelist Toolsを使う場合は、上の表のツールを許可対象に含めます。たとえば読み取り用のwp_get_*、wp_list_*だけでは、記事の作成・更新はできません。

操作できる範囲は、WordPressユーザーの権限・トークンの許可・サイト全体の設定がすべて通る範囲です。必要な投稿・画像操作だけを通し、削除やユーザー管理までまとめて有効化する必要はありません。

「Force Draft on Create」を使うと新規作成を下書きにできます。ただし、更新ツールによる公開まで禁止する設定ではありません。下書き運用と公開権限を同じものとして扱わないことが大切です。

参考：許可したツールが表示されない場合の公式ガイド

4．GitHubとCodex Cloudに作業環境を作る

テンプレートを非公開リポジトリへ保存する

  1. GitHubの「New repository」で、たとえばmy-wordpress-opsというリポジトリを作ります。公開範囲はPrivateです。
  2. 配布したテンプレートZIPを展開します。
  3. GitHubのAdd file → Upload filesから、展開したフォルダの中身をアップロードしてコミットします。最初にREADMEを作ってリポジトリを初期化しても構いません。
  4. Code画面の直下にAGENTS.md、README.md、scripts、configがあることを確認します。.gitignoreも含めます。

外側のcodex-wordpress-starterフォルダを丸ごと1階層余分に入れた場合は、その中へ移動してコマンドを実行する必要があります。この記事ではリポジトリ直下へ配置した前提で進めます。GitHubの基本操作が不安なら、GitHubへコードをアップロードする手順も参照してください。

my-wordpress-ops/
├── AGENTS.md
├── README.md
├── config/site.json
├── scripts/article.py
├── scripts/wpops.py
├── content/demo/article.json
├── content/demo/body.html
├── tests/
└── state/handoff.json

Cloud環境を作り、Network secretを登録する

CodexでSettings → Codex Cloud → Environments → Create environmentへ進み、GitHubを接続して、作った非公開リポジトリを選びます。チャットの「Work in → Cloud」から環境を作成する入口もあります。表示が違う場合は現在の公式Cloud環境ガイドと照合してください。

環境の設定でNetwork secrets → Manageを開き、次を登録します。

項目 設定値
Key WP_MCP_TOKEN
Value Easy MCP AIで発行したトークン。秘密の入力欄にだけ貼る
Allowed domains example.comなど自分のWordPressのホスト名。https://やパスは付けない

Internet accessでは、WordPressのホストへの通信が許可されていることも確認します。Network secretは、プログラムに渡る代替値を、許可したHTTPSの宛先への通信時にプロキシが秘密の値へ置き換える仕組みです。配布コードは環境標準のHTTPSプロキシと証明書検証を使います。

環境の準備中に「Python 3.12以上で、このリポジトリのテストを実行できるようにして」とCodexへ頼みます。設定を保存し、Publishしてから、その環境を選んだ新しいタスクを開始します。ここでのPublishは作業環境の保存・利用開始であり、ブログ記事の公開ではありません。

このブログはエックスサーバーを使っていますが、記事の執筆・投稿用にXServerのAPIキーは不要です。WordPress側の接続だけで進めます。

接続先を設定し、読めることを確かめる

ここからのコマンドは、Codex Cloud内のリポジトリ直下で実行します。下の例を貼り、「example.comを自分のサイトに置き換えて実行して」とCodexへ依頼できます。

python scripts/article.py configure --site https://example.com
python -m unittest discover -s tests -v
python scripts/wpops.py doctor
python scripts/article.py catalog

configureはconfig/site.jsonの接続先を変えます。トークンはこのJSONへ書きません。doctorでconnected: true、write_tools_missing: []になり、作成・更新・画像登録の3つがwrite_tools_availableにあれば、必要なツールが見えています。

catalogには記事とカテゴリが表示されます。自分のブログの記事が返ること、使いたいカテゴリのIDを確認してください。ツール数やカテゴリIDはサイトごとに違い、このブログと同じ数である必要はありません。

5．まず、WordPressへ下書き1本を保存する

タイトル・URL・カテゴリ・本文を用意する

content/demo/article.jsonを編集します。category_idには、先ほど調べた実在する整数のIDを入れます。次の1は例です。

{
  "title": "CodexとWordPressの接続を試す",
  "slug": "codex-connection-demo",
  "category_id": 1
}

slugはURLに使う短い英数字です。新しい記事ごとに変え、すでにある記事の修正では変えません。本文は同じフォルダのbody.htmlへ書きます。

<p>この記事では、CodexからWordPressへ下書きを保存する流れを確認します。</p>
<h2>確認すること</h2>
<ul>
  <li>タイトルと本文が保存されること</li>
  <li>投稿の状態が下書きであること</li>
</ul>

この記事タイトルはWordPress側にあるので、本文に同じh1は入れません。上のサンプルは動作確認用です。実際に公開するときは、自分が読者へ伝えたい内容に書き換えます。

計画を確認してから保存する

python scripts/article.py prepare content/demo
python scripts/wpops.py plan content/demo/plan.json
python scripts/wpops.py apply content/demo/plan.json

ここまでではWordPressへ書き込みません。最初のコマンドは変更計画を作り、最後もmode: previewです。plan.jsonで接続先とタイトルを確認し、wp_create_postのstatusがdraftになっていることを見ます。

保存する内容が合っていれば、次を実行します。

python scripts/wpops.py apply content/demo/plan.json --apply

status: verifiedが返ったら、保存後の値も取得できた状態です。WordPressの投稿 → 投稿一覧を開き、同じタイトルの下書きがあるか確認します。

投稿IDはstate/deployments/article-［slug］-first-draft/journal.jsonのreferences.article、保存後の本文と状態は同じフォルダのcreate.after.jsonに記録されます。次のコマンドでも再取得できます。123は自分の投稿IDに置き換えます。

python scripts/article.py read 123

全文はruntime/post-123.jsonへ保存されます。ローカルのHTMLを作っただけなのか、WordPressへ保存したのか、公開したのかを、投稿IDとstatusで区別できます。

今回の実サイトでの結果：配布ZIPを展開したコードから、このページの下書きを投稿ID421として作成しました。図解を添付ID422で登録し、同じ投稿へ本文とアイキャッチを更新して、保存後の値を再取得しています。ここまではCocoon用のSEO連携を無効にした状態で確認しました。

下書き作成  → verified / 投稿ID 421 / status: draft
図解の登録  → verified / 添付ID 422
同じ記事の更新 → verified / 投稿ID 421 / status: draft

これは今回の結果を抜粋したものです。自分のサイトでは、返されたIDを使ってください。

6．画像を登録して、本文とアイキャッチへ使う

公開できるPNG画像をcontent/demo/example.pngへ置きます。配布テンプレートは2MBまでのPNGに絞っています。ファイル自体を処理時に変換するため、長いbase64文字列をチャットへ貼る必要はありません。

python scripts/article.py media content/demo/example.png --alt 'CodexとWordPressの接続結果を説明する図'

plans/media-…/plan.jsonという計画のパスが返ります。下のmedia-…は、実際に表示された文字列に置き換えます。

python scripts/wpops.py apply plans/media-…/plan.json
python scripts/wpops.py apply plans/media-…/plan.json --apply

登録後はstate/deployments/media-…/upload.after.jsonを読みます。source_urlが画像URL、idが添付IDです。本文ではURLを使います。

<figure>
  <img src="登録結果のsource_url" alt="図が伝えている内容"
       width="画像の実際の幅" height="画像の実際の高さ" loading="lazy">
  <figcaption>図の説明</figcaption>
</figure>

アイキャッチにする場合は、article.jsonへ"featured_media": 123を追加します。ここでの123は投稿IDではなく添付IDです。変更後にもう一度prepareとapplyを行うと、同じ下書きへ反映できます。

このブログでは、Cocoonがアイキャッチのキャプションを画像上に重ねることも確認しました。そのため、配布コードのアップロードではcaptionを空にしています。説明は本文のfigcaptionなどへ書き、画像そのものに作業メモを重ねないようにしています。

画像が大きい場合や別形式を使う場合は、Easy MCP AI公式の画像アップロード説明と、サーバー側の上限・ツール仕様を確認してください。テンプレートが対応する2MBと、WordPressの上限は別です。

7．CocoonのSEO設定も更新したい場合

Cocoon以外を使う人は、この節を飛ばせます。通常タイトルと本文の投稿に、追加のSEO Bridgeは必要ありません。

このブログでは、記事の通常タイトルを直した後も、Cocoonの検索向けタイトルに古い値が残る問題がありました。本文の見出しだけを見ても気づけないため、SEOタイトルと説明文を別に確認する仕組みを加えました。

配布するKatasuke Codex SEO Bridgeは、次の2項目だけをWordPress REST APIへ登録する小さなプラグインです。MCP接続そのものはEasy MCP AIが担当します。

  • the_page_seo_title：検索向けタイトル
  • the_page_meta_description：検索向け説明文
  1. SEO BridgeのZIPをダウンロードします。展開しません。
  2. WordPressのプラグイン → 新規追加 → プラグインのアップロードで、このZIPを選びます。
  3. インストールして有効化します。利用中のテーマがCocoonかも確認します。
  4. Easy MCP AIのトークンでwp_get_post_metaを許可します。
  5. config/site.jsonのcocoon_seoをtrueへ変更します。
  6. 記事のarticle.jsonにseo_descriptionを追加します。
"seo_description": "この記事で解決する疑問と、実際に説明する範囲を簡潔に書きます。"

JSONの最後の項目でない場合はカンマが必要です。Codexにファイル全体の形式も確認してもらってください。

配布コードは最初の下書きを作った後、次の更新時にSEOを反映します。SEOタイトルを空文字にして通常タイトルを継承させ、説明文を明示的に保存します。プラグインが未導入などでメタ項目が登録されていなければ、処理を止めます。

Bridgeは、対象記事を編集できるユーザーかを確認し、登録済みの設定を上書きしないようにしています。ただし、すべてのテーマやSEOプラグインに対応するものではありません。他のSEOプラグインを併用している場合は、公開HTMLでどの設定が出ているかも確認します。

最後に、公開ページのHTMLソースで<title>と<meta name="description">を確認します。WordPressに値が保存されたことと、テーマがその値を表示していることの両方を見るのがポイントです。

8．内容と画面を確認して公開する

原稿と画面の確認を分ける

WordPressの投稿一覧から下書きを開き、プレビューで確認します。本文を直した場合は、先にprepareとapplyで下書きへ反映します。

  • 本人の体験と調査した情報が混ざっていないか。試していないことを成功談にしていないか。
  • コードの保存先・実行場所・成功した状態が説明されているか。
  • 画像に個人情報がなく、文字が読めるか。実画面と説明用イラストを区別しているか。
  • 内部リンクが目的に合っていて、広告の正規コードが保持されているか。
  • PCとスマホ幅で、表・コード・ボタンが本文からはみ出していないか。

このブログの運用ではChromiumで360・768・1200px幅を確認しています。これはブラウザの画面幅検査で、スマートフォン実機での操作とは区別しています。入門テンプレートでは、まずWordPressのプレビューを自分のブラウザで確認すれば進められます。

配布テンプレートで保存した実際のWordPress下書きをChromiumの幅1200pxで表示した画面
実際の下書きプレビューを幅1200pxで撮影。動作確認用の本文と図解を保存した時点の画面で、現在の完成原稿とは本文・アイキャッチが異なります。
配布テンプレートで保存した実際のWordPress下書きをChromiumの幅390pxで表示した画面
実際の下書きプレビューを幅390pxで撮影。動作確認用の本文と図解を保存した時点の画面で、現在の完成原稿とは本文・アイキャッチが異なります。

この撮影ではEasy MCP AIの一時プレビューを利用しました。公式のプレビュー機能はリンクを知る人が期限内に閲覧できる仕組みなので、URL自体は記事や公開GitHubへ載せていません。通常の導入手順では、管理画面からのプレビューで確認できます。

確認した本文を記録して、公開する

内容を確認し、本人がこの記事の公開を決めたら、その最終本文についてcontent/demo/review.jsonを作ります。これはレビュー結果と、確認した本文のハッシュを記録するファイルです。

{
  "ok": true,
  "publication_authorized": true,
  "source_sha256": {
    "content/demo/body.html": "実際に確認した本文のSHA-256"
  }
}

SHA-256はファイルから計算します。自分で確認する場合のコマンドは次です。

python -c "import hashlib; from pathlib import Path; print(hashlib.sha256(Path('content/demo/body.html').read_bytes()).hexdigest())"

Codexには、次のように依頼できます。

この下書きの内容と表示を確認しました。この記事を公開して。確認済みの最終本文のハッシュをreview.jsonへ記録し、計画と変更前のWordPress本文を照合してから反映して。公開後の本文・画像・SEO・URL・新着も確認し、結果をGitHubへ保存して。

公開のコマンドは次の3つです。

python scripts/article.py prepare content/demo --publish
python scripts/wpops.py apply content/demo/plan.json
python scripts/wpops.py apply content/demo/plan.json --apply

ハッシュは、確認後に本文が変わった場合に止めるためのものです。ok: trueを書くだけで、内容の正しさや表示が確認されるわけではありません。

公開後は、保存結果のstatusがpublishになり、返されたlinkがログアウト状態でも開けるか確認します。本文、画像、title・description、ホームの新着、カテゴリ一覧まで見ます。保存結果のverifiedは、検索順位やアクセス増を示すものではありません。

9．既存記事の修正、内部リンク、広告も同じ流れで扱う

既存記事では、最初に投稿IDを指定して最新のWordPress本文を取得します。次に、ローカル原稿との差分を確認し、修正する箇所だけを反映します。別の人が管理画面で直した内容を、古い原稿で消さないためです。

投稿ID123の記事を最新のWordPress本文から確認して。この補足を該当する見出しへ追記し、読者が次の作業へ進める関連記事を1つ追加して。URLと公開状態、元のコード例、広告コードを保ち、差分と表示を確認してから公開記事へ反映して。

テンプレートはapply直前にも変更元を照合します。計画を作った後に別の編集が入った場合は止まります。ただし、計画作成前からローカル原稿が古い可能性もあるため、最初に最新本文と読み比べることは省略できません。

公開済み記事の通常のprepareでは公開状態を保ちます。修正した最終本文のレビューは必要ですが、意図せず下書きへ戻す操作にはしません。新しい記事用フォルダを複製するときは、古いwp_idを持ち越さず、別のslugにします。

アフィリエイト広告がある記事では、ASPが発行したHTMLを保存し、URL・追跡パラメータ・文言・計測画像を保持します。料金の確認日やキャンペーン期限も記事と一緒に管理します。広告が置けたことと、クリックや承認済み報酬が増えたことは別に測ります。

関連記事も全記事へ機械的に並べず、「この説明を読んだ人が次に何をしたいか」でつなぎます。たとえばこの記事なら、GitHubの保存方法や、WordPressをまだ持っていない人向けの費用記事が自然な行き先です。

10．動かないときは、ここから確認する

症状 確認する場所と次の行動
読めるのに更新できない WordPressユーザーの編集権限、トークンのCustom、全体のWhitelist/Disabledを照合。変更後にdoctorで一覧を取り直す
Network secretが見つからない 同じクラウド環境を選んだか、KeyがWP_MCP_TOKENか、保存・Publish後のタスクかを確認
401・403・通信失敗 接続先ホスト、宛先許可、トークン、WordPress/WAFを切り分ける。403だけでサーバー障害と判断しない
タイトルは直ったが検索向け表示が古い 通常タイトルとは別に、Cocoonメタと公開HTMLのtitle・descriptionを見る
画像が登録できない PNG形式・2MB以内・upload権限・サーバー上限を確認。登録済みならIDと実際の画像URLを読む
Concurrent changeと出る 別の編集が入っている。最新本文と差分を確認し、改めて計画を作る
途中で切れた／uncertainと出る 投稿一覧・slug・作成時刻・本文・journalで保存の有無を調べる。同じ新規作成を無条件に再送しない
回数制限に当たる MCP操作を並行実行せず、間隔を空ける。配布コードは読み取りだけを待機再試行し、書き込みは自動再送しない

このブログでも接続のタイムアウトは発生しています。重要なのは、エラーが出たときに「送られていないはず」と決めつけず、保存結果を確認することです。履歴を消して再実行すると、二重投稿の原因になります。

トークンの値、認証ヘッダー、環境変数の全一覧をエラー調査のために貼る必要はありません。秘密を除いたエラーと対象の操作名で切り分けます。

11．次のチャットでも続きを書けるようにする

運用を続けるには、接続できることに加えて、何を決め、どこまで反映したかを残す必要があります。僕の環境では次のように分けています。

  • AGENTS.md：記事の書き方、秘密の扱い、下書きと公開、検証と記録のルール。
  • 記事フォルダ：本文、タイトル、投稿ID、調査元、公開できる素材、確認結果。
  • state/deployments：操作前後の本文、保存結果、再開時に見るjournal。
  • state/handoff.json：公開済みのURL、未反映の作業、次に確認すること。

記事を書き終えたら、原稿と記録を非公開GitHubへコミット・pushします。新しいチャットでは、同じクラウド環境と最新の保存ブランチを選び、次のように依頼します。

AGENTS.md、README.md、state/handoff.jsonを読み、接続確認から再開して。公開済みの内容と、まだローカルにある内容を区別し、今回のメモから記事の構成を作って。僕が書いていない体験や成果は補わないで。

AGENTS.mdは作業方針であり、サーバー側のアクセス権限の代わりではありません。トークンやWordPressユーザーの権限も必要な範囲にします。また、Gitに残した本文と変更履歴は、データベース・全画像・テーマまで含むWordPress全体のバックアップとは別です。

僕が伝える部分と、Codexが実行する部分をこのように分けると、「記事を書いて」で終わらず、根拠、画像、投稿、更新、次のチャットへの引き継ぎまで一つの流れとして扱えます。最初は下書き1本で、保存された本文と実際の画面が合うところまで確かめてみてください。

目的に合わせて、次に読む記事

参考資料と今回の検証範囲

設定とAPIの仕様は、以下の一次資料と実際のツール一覧・保存結果を照合しました。管理画面の設定例はリンク先の公式画像を参照でき、この記事中の実行結果と表示画像は、今回の検証内容を区別して載せています。

配布テンプレートは、ZIPを展開した状態で14件のPythonテストを通し、二重投稿・変更元の不一致・確認後の本文変更・Cocoon連携の有無などを検証しました。SEO Bridgeの登録・権限チェックもPHP 8.3の隔離した環境で確認しています。さらに、このブログへの接続、下書き作成、PNG登録、更新を実行し、保存結果を照合しました。

掲載した下書き画像は実際のプレビュー応答をChromiumで表示したスクリーンショットです。完成原稿の表示は360・768・1200px幅でも確認しています。管理画面への初回インストールをすべてのホスティングで再現した検証や、実機・広告成果・検索順位の検証ではありません。

タイトルとURLをコピーしました