AIと相談した記事を下書き登録する方法
- 前編・準備編：なぜ接続したいのか、AI専用ユーザーとアプリケーションパスワードの作成
- 中編・接続設定編：カスタムGPTとActionsの設定、接続エラーの原因と解決
- 後編・実運用編：記事の相談、下書き登録、長文で分かったメリットとデメリット
前編では、WordPressにAI専用ユーザーを作り、ChatGPTから接続するためのアプリケーションパスワードを発行しました。
ここからはChatGPT側の設定です。
WordPressへ新しい下書きを送るためのカスタムGPTを作り、接続先や認証方法、実行できる操作を設定していきます。
正直なところ、ここから先は私にとって未知の世界でした（笑）。
スキーマ、Basic認証、Base64など、普段ほとんど使わない言葉が続きます。
設定内容はノンに教えてもらいながら進めました。専門用語を全部理解していなくても、何のための設定なのかが分かるように、できるだけ順番に書いていきます。
このシリーズは、まず読んでから試してください
今回の仕組みは、すべての人におすすめできる方法とは限りません。一般的な長さの記事なら便利ですが、長文になると別の方法が早いこともあります。
設定を試す場合は、必ず自分の環境に合わせて内容を確認し、自己責任で進めてください。
STEP4 カスタムGPTを設定する
WordPress側の準備が終わったので、次はWordPress接続専用のカスタムGPTを作ります。
このGPTは、記事の相談や画像作成をするためのものではありません。
普段のノンと相談して完成させた記事を受け取り、WordPressへ下書きとして送ることだけを担当します。
カスタムGPTの作成画面を開く
ChatGPTの左側にある「さらに表示」から「GPT」を選びます。
GPTが開いたら、右上「+作成する」をクリックし新しいGPTを作成します。
画面上部にある「構成」をクリックすると、名前、説明、指示などを自分で設定できます。
名前、説明、指示を入力する
今回は、次の内容で設定しました。
名前
ノン WordPress接続
説明
のんびり研究所の記事をWordPressへ下書きとして登録・確認する接続専用GPTです。
指示
あなたは「のんびり研究所」のWordPress接続専用アシスタントです。
役割は、ユーザーとノンが相談して完成させた記事を、WordPressへ下書きとして登録・更新・確認することです。
必須ルール：
- 投稿ステータスは必ず「下書き（draft）」にする。
- 記事を公開（publish）しない。
- 予約投稿、非公開投稿、既存記事の削除を行わない。
- ユーザーから明確な指示がない限り、既存記事を変更しない。
- WordPressへ書き込む前に、タイトル、本文、カテゴリ、操作内容を提示して確認する。
- 認証情報、パスワード、APIキーを会話へ表示しない。
- 操作後は、成否、記事タイトル、投稿ID、状態が下書きであることを報告する。
- エラーが発生した場合は、無理に再実行せず内容を説明する。
- 公開操作はユーザー本人がWordPress管理画面から行う。会話のきっかけ
この記事をWordPressへ下書きとして登録して
公開、削除、既存記事の変更などを勝手に行わないように、指示の中でも禁止する操作をはっきり書いています。
ただし、文章で禁止するだけでは心配なので、このあと登録するスキーマでも実行できる操作を制限します。
接続に使わない機能はOFFにする
このGPTは、WordPressへの接続だけを担当します。
記事内容の相談やスクリーンショットの加工は、普段のプロジェクトにいるノンへお願いするため、接続用GPTに余計な機能は持たせません。
- ウェブ検索：OFF
- キャンバス：OFF
- 画像生成：OFF
- コードインタープリターとデータ分析：OFF
役割を接続だけに絞ることで、このGPTが何をするためのものなのか分かりやすくなります。
画像ではすべてOFFになっています。実際の設定画面でも、チェックが外れていることを確認します。
新しいアクションを作成する
画面を下へスクロールし、「アクション」にある「新しいアクションを作成する」をクリックすると下記の画面になります。
アクションは、カスタムGPTからWordPress REST APIへ接続し、下書き作成などの操作を実行するための設定です。
この時点では「認証」が「なし」になっているため、最初に認証方法を設定します。
認証方式を設定する
「認証」の右側にある歯車をクリックします。
認証タイプは「APIキー」を選び、認証方式は「基本」を選びます。
ここで少し分かりにくかったのが、「APIキー」の入力欄へ何を入れるのかという点です。
今回使うのは、OpenAI PlatformのAPIキーではありません。
WordPressのAI専用ユーザー名と、STEP3で発行したアプリケーションパスワードを組み合わせ、Basic認証で使える形へ変換した文字列を入力します。
組み合わせる内容は、次の形です。
ユーザー名:アプリケーションパスワード変換ツールはChatGPTに作ってもらう
今回は、ローカル環境で動く「wordpress-basic-auth-converter.html」を使って変換します。
認証用の文字列を作るための小さなHTMLファイルもChatGPTに作ってもらいました。
のんびり研究所から変換ツールを配布する方法も考えましたが、認証情報を入力するファイルなので、「本当に安全なの？」と不安になる人もいると思います。
せっかくChatGPTを使っているので、読者の環境でも同じように作ってもらうことにします。
次の依頼文をコピーして、ChatGPTへ送ります。
WordPressのBasic認証で使用する文字列を、PC内だけで作成するHTMLファイルを作ってください。
ファイル名：
wordpress-basic-auth-converter.html
必要な機能：
・WordPressのユーザー名を入力する欄
・アプリケーションパスワードを入力する欄
・パスワードは伏せ字で表示する
・アプリケーションパスワード内の空白は自動的に除去する
・「ユーザー名:アプリケーションパスワード」の形に連結する
・連結した文字列をUTF-8でBase64へ変換する
・変換結果を表示する
・変換結果をコピーするボタン
・入力内容と変換結果を消す「消去する」ボタン
安全上の条件：
・1つのHTMLファイルだけで動作させる
・インターネットへ接続しない
・外部ライブラリやCDNを使用しない
・fetch、XMLHttpRequest、WebSocket、sendBeacon、フォーム送信を使用しない
・外部のJavaScriptやCSSを読み込まない
・Cookie、localStorage、sessionStorage、IndexedDBへ保存しない
・入力内容や変換結果をconsoleへ出力しない
・入力した認証情報をファイル内へ保存しない
・PCへ保存し、Chromeで直接開いて使えるようにする
完成したHTMLファイルをダウンロードできる形で作ってください。
ダウンロード形式で渡せない場合は、HTMLの全文をコードブロックで出してください。
作成後は、完成したファイルをもう一度確認し、外部通信や入力内容の保存を行う処理が入っていないか説明してください。実際の認証情報はChatGPTへ送らないでください
ChatGPTへお願いするのは、変換用HTMLファイルの作成だけです。
WordPressのユーザー名、通常ログイン用パスワード、アプリケーションパスワード、変換後の文字列は、チャットへ貼り付けないでください。
HTMLファイルを受け取ったら、PCへ保存します。
- 「wordpress-basic-auth-converter.html」をPCへ保存する
- 保存したファイルを右クリックする
- 「プログラムから開く」→「Google Chrome」を選ぶ
- アドレス欄が「file:///」から始まっていることを確認する
- ユーザー名とアプリケーションパスワードを入力して変換する
- 使用後は「消去する」を押して入力内容を消す
Chromeのアドレス欄が「file:///」から始まっていれば、Webサイトへアクセスしているのではなく、自分のPC内にあるHTMLファイルを開いている状態です。
なお、ChatGPTが作ったファイルだからといって、必ず安全とは限りません。
作成時の条件と確認結果を読み、少しでも不明な通信処理や保存処理が含まれている場合は使用しないでください。
- ユーザー名が「nonbiri-ai」になっていることを確認する
- 保存しておいたアプリケーションパスワードを入力する
- 「変換する」を押す
- 表示された文字列をコピーする
- ChatGPTの「APIキー」欄へ貼り付ける
- 認証方式が「基本」になっていることを確認する
- 「保存する」を押す
- 変換ページへ戻り「消去する」を押す
今回使った変換ページは外部通信を行わず、入力内容も保存しない作りにしました。
WordPressのアプリケーションパスワードに入っている空白も、自動的に取り除いてから変換します。
変換前後の文字列は、どちらも公開しないでください
アプリケーションパスワードだけでなく、変換後の文字列もWordPressの認証に使える重要な情報です。
画面を撮影するときは、入力欄と出力欄を空にします。漏れた可能性がある場合は、WordPress側でアプリケーションパスワードを削除し、新しく発行します。
スキーマを登録する
続いて「スキーマ」の欄へ、WordPressで実行できる操作を登録します。
スキーマという言葉だけを見ると難しそうですが、簡単にいえば「接続先と、GPTに許可する操作を決める設計図」のようなものです。
今回は、次の内容をそのまま貼り付けました。
openapi: 3.1.0
info:
title: のんびり研究所 WordPress下書き接続
description: WordPressへ記事を下書きとして登録するためのAPI
version: 1.0.0
servers:
- url: https://nonbiri-lab.jp/wp-json/wp/v2
paths:
/posts:
post:
operationId: createWordPressDraft
summary: WordPressへ新しい下書きを登録する
description: 投稿ステータスを必ずdraftにして、新しい記事を下書きとして登録します。
requestBody:
required: true
content:
application/json:
schema:
type: object
required:
- title
- content
- status
properties:
title:
type: string
description: 記事タイトル
content:
type: string
description: WordPressへ登録する記事本文。WordPressブロックまたはHTMLを使用できます。
excerpt:
type: string
description: 記事の抜粋
status:
type: string
enum:
- draft
description: 必ずdraftを指定します。
categories:
type: array
description: WordPressカテゴリーID
items:
type: integer
tags:
type: array
description: WordPressタグID
items:
type: integer
responses:
"201":
description: 下書きの作成に成功
content:
application/json:
schema:
type: object
properties:
id:
type: integer
status:
type: string
link:
type: string
title:
type: object
properties:
rendered:
type: string
"400":
description: 入力内容に問題があります
"401":
description: 認証に失敗しました
"403":
description: 投稿を作成する権限がありません
専門用語がたくさん並んでいますが、このスキーマで決めている大事な点は、次の3つです。
- 接続先は「nonbiri-lab.jp」のWordPress REST API
- 実行できるのは、新しい投稿の作成
- 投稿状態は「draft」のみ
公開、削除、既存記事の変更を行うアクションは用意していません。つまり、GPTが実行できるのは「新しい下書きを1件作る」ことだけです。
作成済み下書きの読み取りや更新も、今の段階ではできません。最初から機能を詰め込むと、問題が起きたときに原因を探しにくくなります。
まずは最小構成で新しい下書きを作れることを確認し、必要になった機能はあとから少しずつ追加することにしました。これで、WordPressへ接続するための認証と、実行できる操作の設定は完了です。
次のSTEPでは、いよいよ接続テストを行います。
STEP5 接続テストとエラー解決
ここまで設定できたら、いよいよWordPressとの接続テストです。
正直、このあたりは私にとって未知の世界でした（笑）。
スキーマの内容も、何がどう動いているのか完全には理解できていません。それでも、画面を一つずつ確認しながら進めていきます。
スキーマが認識されているか確認する
スキーマが正しく読み込まれると、画面下部の「利用可能なアクション」に「createWordPressDraft」が表示されます。
画面を見ると、メソッドが「役職」、パスが「/投稿」と表示されていました。
一瞬、「設定を間違えたか？」と思いましたが、これはChromeの自動翻訳が、英語の「POST」を「役職」、「/posts」を「/投稿」と訳してしまっただけでした（笑）。
スキーマ内部の設定が書き換えられたわけではありません。
こういった技術的な設定画面では、Chromeの自動翻訳をOFFにしておいたほうが混乱しにくそうです。
「テストする」を押して接続する
「利用可能なアクション」の右側にある「テストする」をクリックします。
すると、ChatGPTから外部サイトへ情報を送信するための確認画面が表示されます。
接続先が自分のWordPressであることを確認し、送信内容に問題がなければ「許可する」をクリックします。
確認画面が複数回表示された場合も、その都度、接続先と送信内容を確認してから許可します。
最初の接続テストはエラーになった
これで下書きが作られると思ったのですが、最初のテストは失敗しました。
画面には「ClientResponseError」と表示され、WordPressへ下書きを登録できませんでした。
この時点では、どこが原因なのか分かりません。
考えられそうなものを並べると、次のような感じでした。
- WordPress REST APIの設定
- Basic認証の設定
- アプリケーションパスワードの間違い
- 接続先URLの間違い
- WordPressのセキュリティ設定
- サーバー側のアクセス制限
- 一時的な通信エラー
同じ操作を何度も繰り返しても原因は分からないので、WordPress側とサーバー側を順番に確認することにしました。
CloudSecure WP Securityを確認する
のんびり研究所では、セキュリティ対策として「CloudSecure WP Security」を使用しています。
このプラグインにはREST APIを無効にする機能があるため、最初にここを確認しました。
設定画面を見ると、「REST API無効化」は「無効」になっています。
ちょっと分かりにくい言い方ですが、「REST APIを無効にする機能」が無効なので、REST API自体は使える状態です。
つまり、今回のエラーはCloudSecure WP Securityが原因ではありませんでした。
原因はXserverの国外REST APIアクセス制限だった
次に、Xserverのサーバーパネルから、対象ドメインの「WordPressセキュリティ設定」を確認しました。
すると、「国外アクセス制限」の中にある「REST APIアクセス制限」がONになっていました。
ChatGPTからWordPressへの通信が、Xserver側では国外からのアクセスとして扱われ、ここで止められていたようです。
対象ドメインの「REST APIアクセス制限」だけをOFFに変更しました。
ほかの国外アクセス制限まで全部解除する必要はありません。今回は、WordPressとの接続に必要なREST APIアクセス制限だけをOFFにしました。
セキュリティ設定を一つ緩めることになるので、その代わり、ChatGPT側とWordPress側で実行できる操作をかなり小さくしています。
- AI専用ユーザーを使用する
- ユーザー権限は寄稿者にする
- 通常のログインパスワードとは別のアプリケーションパスワードを使用する
- スキーマは新しい下書きの作成だけにする
- 公開を表す「publish」は指定できないようにする
- 既存記事の変更や削除を行うアクションは用意しない
- カスタムGPTは自分だけで使用する
今後この接続を使わなくなった場合は、WordPressのアプリケーションパスワードを削除し、XserverのREST APIアクセス制限もONへ戻せます。
設定変更後のテストは成功
Xserverの設定を変更したあと、ChatGPTへ戻ってもう一度テストしました。
今度はエラーが発生せず、WordPressへ下書きとして登録されたと表示されました。
画面には、記事タイトル、投稿ID、投稿状態が表示されています。状態が「draft」になっているので、記事は公開されず、下書きとして保存されています。
WordPress管理画面の「投稿」から「投稿一覧」を開くと、テスト用の記事が追加されていました。
作成者はAI専用ユーザーの「ノン」、記事の状態は「下書き」です。これで、WordPressの接続設定、認証、スキーマが正しく動くことを確認できました。
カスタムGPTを自分だけで保存する
接続テストが成功したら、STEP4でそのままになっていた、ChatGPTの画面右上にある「作成する」をクリックします。
「GPTを共有する」という画面が表示されたら、共有範囲を「自分だけ」に設定して保存します。
このカスタムGPTには、WordPressへ接続するための認証設定が含まれています。
ほかの人に使ってもらうものではないので、リンク共有やGPTストアでは公開せず、自分専用として保存しました。
保存したGPTは、開き方によって結果が違った
ここで完成だと思ったのですが、実際の記事作成チャットから使おうとすると、もう一つ問題が見つかりました。
2026年7月15日に、同じカスタムGPTをいくつかの方法で動かしてみました。
- GPT編集画面の「テストする」から実行：下書き作成に成功
- GPT一覧からカスタムGPTを直接開く：下書き作成に成功
- 通常チャットから「@ノン WordPress接続」で呼び出す：下書きは作成されない
- プロジェクト内から「@ノン WordPress接続」で呼び出す：下書きは作成されない
- プロジェクト外のWorkモードから呼び出す：下書きは作成されない
「@ノン」で呼び出した場合も、外部通信の許可画面までは表示されました。
ところが、「許可する」を押したあとに処理が完了せず、WordPressにも下書きが作られていませんでした。
長文だから止まったのかと思いましたが、短い本文でも同じ結果でした。
プロジェクト内から呼び出した画面では、途中でActionsツールが利用できない状態になっていると表示されました。
Workモードでも許可画面は表示されましたが、そのあと何も言われずに処理が終わったような状態になり、WordPressには登録されていませんでした。
一方、GPT一覧から「ノン WordPress接続」を直接開いて同じ操作を行うと、下書きを作成できました。
この結果を見る限り、WordPressや認証設定そのものではなく、保存したカスタムGPTを別のチャットへ「@」で呼び出したときに、Actionsが正しく引き継がれていない可能性が高そうです。
これは2026年7月15日時点の、私の環境での検証結果です。ChatGPT側の仕様や動きは、今後変わる可能性があります。
現時点での回避方法
現時点では、普段の記事作成用チャットから「@ノン」で呼び出す方法は使わないことにしました。
記事の相談と作成は、いつもの「のんびり研究所」プロジェクト内で進めます。
記事が完成したら、GPT一覧から「ノン WordPress接続」を直接開き、完成した本文を渡してWordPressへ送ります。
- 普段のノンと記事内容を相談する
- 記事本文を完成させる
- GPT一覧から「ノン WordPress接続」を直接開く
- 登録予定のタイトルや本文を確認する
- 問題がなければ下書き登録を実行する
- WordPress管理画面で下書きを確認する
少しワンクッション増えましたが、今のところはこの方法が一番確実でした。
最初に考えていた「いつものチャットから接続用GPTを呼び出して、そのまま登録する」という形にはなりませんでした。
それでも、GPT一覧から直接開けば下書き登録はできるので、完全に失敗というわけでもありません。
予定とは少し違うけど、とりあえず使えるところまで持っていけた。今回はそんな結果になりました（笑）。
【中編はここまでです。次の記事では、実際に記事を相談して、GPT一覧から接続用GPTを直接開き、WordPressへ下書き登録するところを試します。】
