ChatGPT Dotsで、記事の調査からWordPressへの下書き入稿まで進められるのでしょうか。当メディアでは、記事制作ルールをまとめた自社版ArticleOSと記事計画、Google Drive、WordPressを組み合わせ、原稿・画像・QA記録の保存と下書き入稿を確認しました。
ArticleOS（アーティクルOS）は、当メディアが開発・提供する、企業や媒体ごとの記事制作ルールを組み込んだAI記事制作システムです。メディア設計・記事計画から一次情報の調査、SEO構成、本文・CTA・画像の制作、公開前チェックまでを一つのワークフローとして整え、記事制作の内製化を支援します。本記事では、当メディア向けに構築した自社版を使っています。
ただし、接続や承認が不要になったわけではありません。この記事では2026年10月15日の5記事の下書き保存記録を中心に、実際にできた工程、止まった理由、再現に必要な条件を分けて解説します。自社メディアの運用を効率化したい担当者向けの検証です。
ChatGPT Dotsによる記事制作の自動化：検証結果と確認範囲
当メディアの検証で確認できたのは、制作物を用意し、WordPressに下書きとして保存して再確認するところまでです。「毎日必ず5本を完全無人で公開できる」という実証ではありません。
2026年10月15日に保存されたQA記録には、次の5記事について投稿ID、下書き状態、画像、本文の読み戻し結果が残っています。ここでの状態は記録時点のもので、後日の公開状況とは区別します。
| 記事ID | 内容 | 投稿ID | 保存時の状態 | 専用画像 |
|---|---|---|---|---|
| SIDE-025 | 記事制作コストの削減 | 4515 | 下書き | 4点 |
| SIDE-029 | AI副業の本の選び方 | 4521 | 下書き | 4点 |
| SIDE-033 | AI業務自動化の副業 | 4527 | 下書き | 4点 |
| TOOL-079 | Kaiber AIの料金 | 4533 | 下書き | 4点 |
| TOOL-081 | Kaiber AIの商用利用 | 4539 | 下書き | 4点 |
これは当メディアの特定環境で確認した結果です。専用画像は合計20点ですが、画像数だけで記事品質や検索順位を評価することはできません。また、同じ日付の作業でも調査、画像制作、認証待ちなどが並行するため、保存時刻の差をそのまま1記事の制作時間とは扱いません。
成功と課題を同じ記録に残す
下書き保存の成功と公開前QAの合格は別でした。たとえばSIDE-025では、本文の一致や画像配置を確認した一方、プレビューHTMLのパンくず参照先に不整合を検出しています。TOOL-079とTOOL-081のパンくず検査は合格記録でしたが、公開後の再確認は必要とされていました。
つまり、この検証で得られた価値は「すべて問題なく終わった」という報告ではなく、どこまで保存でき、どこを人が確認すべきかを分けられた点です。公開判断を下書き入稿と切り離すことが、安全に運用する前提になります。
ChatGPT Dotsで記事制作を自動化するArticleOS・WordPressの役割
Dotsは作業の進行、ArticleOSは記事制作の基準、WordPressは下書きの保管と表示を担当します。今回使ったArticleOSは当メディア自社版V1.4であり、Dotsの標準機能だけで同じ制作ルールが付属するわけではありません。
ArticleOSは媒体ごとの制作工程を仕組み化するサービス
ArticleOSは、企業の商品・ターゲット・キーワード・文体・CTA・画像仕様・利用媒体に合わせて構築するシステムです。一般的な文章生成の依頼に加え、何を書くかを決める記事計画や、出典・内部リンク・SEO項目・品質確認のルールを制作工程に組み込みます。サービス全体の内容はArticleOSのサービス紹介で確認できます。
今回の「ArticleOS連携」は、その自社版の制作ルールをDotsが参照し、記事計画・保存先・WordPressへの作業をつなげる運用を指します。サービスの導入だけで、すべてのサイトへの自動入稿や無人公開が設定されるという意味ではありません。必要な接続、操作権限、入稿先に合わせた設定は別途確認します。
| 要素 | 今回の役割 | 任せない判断 |
|---|---|---|
| Dots | 計画照合、調査、工程の進行、結果報告 | 許可範囲を超えた公開や設定変更 |
| ArticleOS | 構成、出典、SEO、画像仕様、品質チェックの基準 | 未確認事実や架空の体験の補完 |
| 記事計画 | 記事ID、検索意図、優先度、URLの正本 | 空いている題材の無断追加 |
| Google Drive | 原稿、画像、QAの保存 | 保存確認前の完成扱い |
| WordPress | 既存の投稿タイプへの下書き保存 | 自動での公開判断 |
ArticleOSの設計例はChatGPTプラグインの作り方で扱っています。本記事ではプラグインを作る手順ではなく、導入済みの制作基準を使って実際の成果物につなげる工程に集中します。
DotsとArticleOSを使うだけで、どのWordPressサイトにも入稿できるわけではありません。サイト側の投稿タイプやURLの作り方、利用できるブラウザ、接続の権限が異なるためです。今回の入稿経路を、WordPress公式APIや専用コネクターの標準提供を実証したものと読み替えることもできません。
ChatGPT Dotsで記事制作を自動化する環境・接続・権限
最初に確認すべきなのは、利用する各サービスへ実際にアクセスできるかです。プラグインが一覧に存在すること、アカウントへ接続できること、必要な操作が許可されていることは、それぞれ別の条件です。
当メディアでは、ArticleOSの指示・Flow・Qualityを読み、記事計画と保存先への接続を確認してから制作に進む設計にしました。読み込めない場合に一般的な文章生成で代用すると、記事計画に沿った検証ではなくなってしまいます。
WordPressへのアクセスでは、クラウド側のブラウザと利用者のMacのブラウザを区別します。MacでWordPressへログインしても、別のクラウドブラウザへ同じログイン状態が引き継がれるわけではありません。OpenAI公式資料でも、それぞれのブラウザセッションは別と説明されています。
Macを使う工程には稼働条件がある
ローカルのMacが必要な作業では、接続、操作許可、オンライン状態、アプリの稼働を確認します。当メディアの運用でも、WordPressへのログインに加えてPCアプリを開く必要がある場面がありました。「スマートフォンから指示を送れた」だけで、Mac上の作業も実行できるとは判断できません。
承認が必要な操作は、その都度止めます。通常の編集判断を事前に任せることと、新しい認証情報を作ったり権限を拡張したりすることを許可するのは異なります。記事制作に必要な資料へ範囲を絞り、関係のない顧客資料を調査対象に含めないことも重要です。
ChatGPT Dotsによる記事制作の自動化：未制作記事の選定
新規制作の前に、記事計画だけでなくDriveとWordPressを照合します。計画の「選定候補」は暫定情報であり、そこに並ぶ記事をそのまま書き始めると重複するおそれがあります。
当メディアで用いた確認軸は、記事ID、タイトル、予定URL、検索意図です。タイトルが少し違っていても同じ検索意図の記事が保存済みなら、別記事と決めつけません。反対に、同じツールを扱っていても料金と商用利用では答える問いが異なります。
- 制作済み、公開待ち、公開済みの記事は新規制作から外す
- 既存の下書きやDrive成果物がある場合は再利用を検討する
- 制作中の記事は担当と現在の作業を確認する
- 保留、見送り、執筆NG、要確認の記事は自動選定しない
- 適格な記事が足りなければ、上限より少ない件数で終える
制作開始時には、対象IDへ担当、開始日時、制作中状態を記録し、反映を読み戻します。別の作業が同時に進んでいるなら、その予約を上書きしてはいけません。記事番号だけでなく元計画の同じIDを探し直すことで、行の追加や並べ替えにも対応します。
一般的な工程設計はAIで記事制作を自動化する方法も参考になります。今回の検証では、その設計を実ファイルと下書きへ接続したときに生じる確認作業まで含めています。
ChatGPT Dotsによる記事制作の自動化：調査・本文・画像・QA
本文制作は、公式情報を集めてから構成、本文、FAQ、SEO、出典、画像へ進めました。文章が流暢かどうかだけでなく、記事タイトルの問いに答えているかを検査します。
たとえば料金記事では、現在の公式価格と旧情報を混在させないことが必要です。公式ページ同士で表示が違う場合も、単に都合のよい価格を採用せず、適用時点やプラン条件を確かめます。商用利用記事なら、サービスの利用許可と入力素材の権利処理を区別します。
ArticleOSでは、記事の根拠を末尾の出典一覧にそろえ、本文で使った主張と対応させます。体験を記載する場合は、当メディアが実際に確認した操作なのか、公式情報による説明なのかを分けました。試していない契約、生成、解約の体験を作ることはしません。
結論カードと画像は別の役割
当メディアの結論カードは、リード直後・目次前に置く共通HTMLです。記事タイトルへの直接回答を1〜2文で示し、必要なら補足を付けます。これを画像に置き換えず、本文として読める形を維持します。
画像はアイキャッチ1点と本文図解3点を基本にし、それぞれ別の役割を持たせました。画像のファイル名、挿入位置、代替テキストを入稿資料に記録することで、保存先に画像があるだけの状態から、記事内で使える状態へつなげます。
品質確認の対象は、事実、出典、重複、表現、リンク、画像の一致です。AI記事の品質チェック方法で示すように、作成者の自己点検と入稿後の表示確認は分ける必要があります。原稿内で問題が見つからなくても、WordPress上の検査が自動的に合格するわけではありません。
ChatGPT Dotsによる記事制作の自動化：Drive保存と計画更新
成果物は保存先へ置き、実際に存在することを確認してから計画へ反映します。会話に本文が出力された状態と、次の担当者が開ける原稿・画像・QAがそろった状態は同じではありません。
当メディアでは記事ごとに原稿、入稿用資料、QA結果、専用画像を対応させました。確認記録には記事IDを含め、ファイルの内容と保存先が同じ記事を指しているかを照合します。ファイル名が似ているだけで別記事の画像を使わないためです。
計画更新では、既存の設計や備考を消さず、成果物の保存先と残課題を追記します。制作状況の「公開待ち」と入稿状況の「下書き入稿済み」は別々に管理しました。前者だけでは、WordPressに投稿が存在することまでは確認できません。
保存に失敗した場合は、完成済みの原稿まで作り直さず、保存できた範囲を保持します。再開時には同じ成果物を探し、欠けている工程だけを進めます。失敗したから別の記事へ切り替える運用では、途中の成果物が取り残されて重複の原因になります。
ChatGPT Dotsによる記事制作の自動化：WordPress下書き入稿と読戻し
下書き入稿では、本文を貼り付けて保存ボタンを押すだけでなく、保存後に開き直して内容を確認しました。投稿IDとdraft状態の両方が、工程完了を判断する基本になります。
今回のQA記録では、本文、見出し、表、FAQ、結論カード、画像、カテゴリー、スラッグ、SEOタイトル、メタディスクリプションを確認対象としています。画像4点のうち1点はアイキャッチ、残りは本文へ配置するため、メディアに4点存在するだけでは配置確認の代わりになりません。
| 確認対象 | 見落とすと起こる問題 |
|---|---|
| 本文の読み戻し | 保存時の欠落や別原稿の混入 |
| 投稿タイプ・カテゴリー・URL | 予定外の階層や別ページへの遷移 |
| 画像・alt・アイキャッチ | 欠けた画像、内容と合わない説明 |
| SEO項目 | 本文と異なるタイトルや説明 |
| PC・スマートフォン表示 | 表のはみ出しや読みにくさ |
| パンくず構造化データ | 見た目だけでは分からない参照不整合 |
パンくずは画面表示だけでなく、HTML内のBreadcrumbListも確認します。項目数、名称、順序、URL、参照先の存在を点検し、取得できなければ未確認と記録します。本文へ別の構造化データを足して無理に補修する方法は採りませんでした。
下書きプレビューと公開後のHTMLは、条件が異なる場合があります。今回も公開後の再検査やGoogle側の確認は残課題として扱い、プレビューの合格だけで検索結果上の警告まで解消したとは報告していません。
ChatGPT Dotsによる記事制作の自動化で止まった接続・カテゴリーの問題
止まった工程を調べると、文章生成能力よりも接続先やサイト構造が原因の場面がありました。これらは、指示文を長くするだけでは解決できません。
当メディアの作業履歴には、クラウド側からのWordPressアクセスがXserverの画面で拒否され、ログイン済みMacでの経路を確認した例があります。クラウドの拒否を見てWordPress自体が使えないと決めつけず、許可済みの別経路が使えるかを確認する必要がありました。
また、Dots関連記事の予定URLに対応するサイト側の定義が不足していたため、入稿を保留した時期があります。このときは別のURLで投稿したり、新カテゴリーを勝手に作ったりせず、運営者による対応を待ちました。サイト構造が整ったという連絡だけでなく、実際の入稿先を再確認して進めることも大切です。
このような停止は、失敗を隠して本数をそろえるよりも、問題箇所を特定するために必要です。再開条件を「接続確認」「保存確認」「入稿先確認」のように具体化しておけば、次の作業で同じ調査や生成を繰り返さずに済みます。
定期実行の設定と未検証部分
定期実行の保存と、毎回同じ品質で完走することは別の検証です。当メディアでは定期制作を依頼していますが、設定本数を日数で掛けて月間の制作保証や収益に換算することはできません。
2026年10月16日には、13時予定の作業を前倒しする依頼があり、同日の重複実行を避けるため、次の定期実行を10月17日13時（日本時間）へ変更する確認を行いました。これは日程変更の確認であり、変更後の全工程が将来必ず成功することを示すものではありません。
本数を増やす前に、候補不足、接続切断、承認待ち、保存失敗をどう扱うかを決めます。前回の制作が続いているなら新しいバッチを始めず、担当と出力を確認して再開可能な工程だけ進める設計が必要です。
再現条件とよくある質問
再現のポイントは、使うツールをそろえることに加え、完成条件と停止条件を明確にすることです。以下は今回の検証から整理した判断の目安です。
Dotsだけで同じ記事制作ができますか？
今回の検証は自社版ArticleOS、記事計画、Drive、WordPressの組み合わせです。Dots単体に当メディアのルールや投稿先設定が最初から含まれるわけではありません。自分の媒体に合う出典基準、URL設計、確認項目を用意してください。
PCの電源を切ってもWordPress入稿まで進みますか？
クラウドで行える仕事とMac依存の工程を分けて判断します。今回のようにログイン済みMacを使う工程では、そのMacが利用可能であることが必要です。すべてをクラウドだけで完走できたとは検証していません。
画像や記事を作り直せば失敗から復旧できますか？
まず既存の成果物と投稿を確認します。保存が成功したのに応答だけ途切れた可能性があるため、確認せずに再生成・再投稿すると重複します。欠けた工程を特定して再開する方が安全です。
公開まで自動化した実験ですか？
いいえ。今回の確認対象は下書き保存です。公開・予約公開は工程に含めていません。下書きの完成後も、内容とサイト表示の確認を経て運営者が公開を判断する必要があります。
導入すれば工数や収益はどれくらい改善しますか？
この検証では一律の削減率や収益を算出していません。調査難度、画像、サイト設定、接続待ち、人の確認時間で変わります。導入前後で同じ品質基準の作業時間を測り、修正や保守の負担も含めて判断してください。
まとめ：下書きまでの自動化は確認、運用条件の整備が必要
当メディアではDotsとArticleOSを使い、原稿・画像・QAの保存からWordPress下書きまで進められました。一方、接続、権限、URL構造、公開前の残課題は別途管理が必要でした。最初は少数記事で保存と読み戻しを確かめ、止まった理由を記録しながら運用範囲を広げるのが現実的です。
出典・参考情報
公式情報確認日：2026年10月16日。当メディアの実証範囲は2026年10月15日の5記事の下書きQA記録、および10月16日の定期設定変更確認です。管理画面URLや非公開ファイルは一般公開していません。
- OpenAI「Meet dots」
- OpenAI「Tasks and memory」
- OpenAI「Connect computers and apps to your dot」
- OpenAI「Control your dot」
- 当メディア編集部：ArticleOS自社版V1.4、記事計画、原稿・画像保存記録、5記事のWordPress下書き保存・読み戻しQA記録（非公開の一次記録）。
