MANIARUでは、ChatGPTで考えを整理し、完成したMarkdown指示書をWorkへ渡して、WordPressの投稿や確認を進めています。
ChatGPTからWorkへ思いついたことをそのまま渡すのではなく、指示書を一つの中間成果物にする流れです。目的、変更範囲、確認事項を文章として確定してから、実際の環境を操作する工程へ進みます。
この記事では、現在MANIARUの記事制作やサイト改善で使っている、ChatGPT → 指示書 → Work → 検証 → 完了報告という作業の組み立て方をまとめます。
なぜChatGPTとWorkの間に指示書を挟むのか
MANIARUを作り始めた頃は、ChatGPTで相談した内容を、そのままWorkへ渡すことがありました。手軽ではありますが、相談中の案と、実際に反映する確定内容が混ざりやすくなります。
WordPressの作業では、記事本文だけでなく、カテゴリー、slug、画像、SEO、公開後の確認、変更してはいけない範囲まで伝える必要があります。会話の流れだけに任せると、今回どこまで実行するのかが曖昧になりました。
そこで、相談がまとまった時点でMarkdown指示書を作り、実行内容を確定してからWorkへ渡すようにしました。
ChatGPTは考える場所、Workは実行する場所
ChatGPTでは、作りたいもの、記事の中心テーマ、構成、変更してよい範囲を整理します。まだ決まっていないことを相談し、選択肢を比較し、今回の方針を固める工程です。
Workでは、その指示書を基準に実際のファイルやWordPressを確認し、記事作成、画像設定、公開、表示確認を行います。実環境で分かった事実が指示と違う場合は、現在の状態を確認したうえで判断します。
この役割分担の全体像は、既存のAI記事ChatGPTとWorkを使い分けてWordPressサイトを作ってみたで記録しています。今回は、その間に置く指示書の作り方へ範囲を絞ります。
Markdown指示書を中間成果物にする
指示書は、単に長いプロンプトを保存したものではありません。相談で決まった内容を、Workが実行できる形へ変換した成果物として扱っています。
Markdownにしているのは、見出し、箇条書き、禁止事項、確認項目を分けやすく、あとから人が読み直しても構造を追いやすいためです。特別な形式を使うことより、何が確定し、何が未確認かを区別できることを優先しています。
完成した指示書はiCloudのMANIARUフォルダに保存し、Workには対象ファイルを指定して実行を依頼しています。記事本文には、端末固有のパスや管理情報を掲載する必要はないため、運用の考え方だけを残します。
個別指示書に書いていること
指示書の内容は作業によって変わりますが、おおむね次の項目に分けています。
- 目的：何を完成させる作業か
- 対象：記事、ページ、機能など、今回触るもの
- 最初のチェック：名前や重複を先に確認する条件
- 実施内容：本文、設定、画像、検証などの具体的な作業
- 変更禁止：既存記事やサイト設定など、触らない範囲
- 公開前確認：公開できる状態を判断する項目
- 完了報告：作業後に記録する結果
実際の指示書全文を毎回同じ形で作る必要はありません。ただ、目的と対象、変更しないもの、完了条件が分かる構造は維持しています。
共通ルールと個別指示書を分ける
文章のトーン、カテゴリーの役割、slug、SEO、画像、公開後確認など、MANIARUで毎回変わらない条件はMANIARU_WORK_RULES.mdへまとめています。
個別指示書には、今回作る記事のテーマ、確認する実例、変更範囲、その作業だけの停止条件を書きます。共通事項を毎回全文コピーしないことで、個別の目的が埋もれにくくなりました。
この共通ルールを作った経緯は、BUILD記事ChatGPT＋Work＋共通ルールでWordPress制作フローを作ってみたで詳しく扱っています。
変更するものと変更しないものを書く
指示書では、やることと同じくらい、今回は触らないものを明確にします。
たとえば新規記事を1本作る作業なら、既存記事、テーマ、プラグイン、共通CSS、HOME、アクセス解析などは変更対象に含めません。途中で別の改善点が見つかっても、今回の目的に必要なければ作業を広げない方針です。
範囲を先に決めることで、依頼した記事を完成させる前に別の調査や修正へ進むことを防ぎやすくなります。これは、作業時間とクレジットを必要以上に増やさないためにも使っています。
実作業のあとに検証と完了報告を行う
WordPressへ入力できたことだけでは、作業完了とはしていません。公開URLを開き、タイトル、本文、見出し、画像、カテゴリー、目次、スマートフォン表示など、今回必要な項目を確認します。
その後、公開URL、slug、カテゴリー、meta description、使用画像、実際に変更した対象を完了報告へ残します。指示どおりに作業したつもりかではなく、何が公開され、どこまで確認したかを結果として記録するためです。
PROJECTとCATEGORYの記事を役割で分け、由来がある記事だけをつなぐ判断も、指示書と確認結果を使って進めています。この記事設計は、BUILD記事PROJECTとCATEGORYをつなぐ。実験記録からマニュアルを作る記事設計でまとめました。
指示書が増えて見えた問題
指示書を使えば、必ず間違いがなくなるわけではありません。ファイルが増えると、以前の指示書を複製して作ることも増え、番号、カテゴリー、記事名などに別案件の文字が残る可能性があります。
また、毎回安全を確認しようとして、全記事や全ファイルを読み直すと、実作業へ入る前の確認が大きくなります。すでに終わった投稿をもう一度作る重複は避けたい一方で、関係のない範囲まで総点検する必要はありません。
指示書が増えたことで、内容を書く方法だけでなく、実行前にどこを確認するかも決める必要が出てきました。
最初に名前を確認する
現在は、重い調査やWordPress操作の前に、指示書番号、ファイル名、対象、記事名、カテゴリーを照合するルールを加えています。
ここに別案件名やコピペの残りがあれば、そのまま進めず、不一致の箇所を示して停止します。作業を始めてから対象が違うと分かるより、最初の短い確認で止める方が影響を小さくできます。
この名前チェックは導入したばかりです。長期間の効果が確認できたとまでは言えませんが、少なくとも指示書の入口で確認する項目は明確になりました。
重複チェックは必要な範囲だけにする
名前が一致した後は、今回の対象、共通ルール、直接関係する既存記事だけを確認します。実質的に同じ記事や作業がすでに存在する場合は停止しますが、単に同じテーマへ触れているだけなら、役割の違いを確認して進めます。
今回の記事でも、既存AI記事がWordPress制作全体の役割分担を扱っていることを確認しました。そのうえで、この記事はMarkdown指示書の構造、共通ルールとの分離、名前・重複チェック、検証と完了報告へ焦点を置いています。
全ファイルを読むのではなく、重複かどうかを判断できる範囲に絞ることで、確認そのものが目的になることを避けています。
不要な公開前確認を減らす
タイトル、カテゴリー、本文、画像、SEO、表示など、指示書に書いた公開条件を満たしている場合は、最後にもう一度「公開してよいか」を尋ねず、そのまま公開と検証まで進めるルールにしました。
一方で、名前の不一致、重大な重複、指示の矛盾、必要情報の不足、正式アセットを確認できない場合などは停止します。確認をなくすのではなく、止まる条件を先に分けています。
この運用も始めたばかりで、すべての作業に合うと確認できたわけではありません。MANIARUでは、定型化できる記事制作から使い、必要に応じて見直していきます。
指示書はAI同士をつなぐ設計図になった
ChatGPTとWorkを分けるだけでは、相談から実行へ何を渡すかが曖昧でした。Markdown指示書を間に置くことで、考えた内容を、確認できる形で実作業へ渡せるようになりました。
大切だったのは、指示を長くすることではありません。目的、対象、変更範囲、完了条件を整理し、共通ルールと今回だけの条件を分けることでした。
考える、指示書にする、実行する、検証する、結果を残す。この一連の流れ自体が、MANIARUで繰り返し使うAI作業の仕組みになっています。