ねこ宿研究所をAIでどう運用している？記事制作・WordPress公開の実例

ねこ宿研究所では、記事原稿の作成、WordPressへの登録、内部リンクの更新、公開後の確認にAIとWP-CLIを使っています。ただし、AIへ「サイトをよろしく」と任せているわけではありません。

実際の運用では、依頼の途中で前提の間違いに気付いたり、実装したのに画面へ反映されなかったり、公開前バックアップが正常終了しなかったりしました。そのたびに、作業を止め、確認し、次回のルールへ反映しています。

この記事では、ねこ宿研究所で起きた事例を、他の宿でも使える判断方法として紹介します。サーバーの接続先、内部パス、利用者名、認証方法、実際のコマンドラッパーなど、攻撃の手がかりになり得る環境情報は掲載しません。

AIに任せているのは「判断」ではなく「作業の補助」
実際の基本フロー
実例：一つの記事を相談から公開まで進める
WordPressをAIの唯一の記憶にしない
正本はWordPressだけに置かない
ケース1：ファイル名の間違いを自分のサイトでも直した
ケース2：ZIP配布をMarkdown直リンクへ変えた
ケース3：具体的すぎる公開サンプルから環境情報を消した
ケース4：トップページの新着除外が最初は効かなかった
ケース5：記事は公開できても内部リンクが不足した
ケース6：バックアップが失敗したとき、成功したことにしなかった
一回の依頼で全部を任せない
WP-CLIは自由に実行させない
AIの完了報告に必要な項目
失敗を次回のルールへ変える
1. 会話からルールになった実例
宿主さんが小さく始めるなら
まとめ
参考資料

AIに任せているのは「判断」ではなく「作業の補助」

AIが得意なのは、複数ファイルの調査、文章の下書き、変更候補の整理、決められた手順の実行、確認結果の比較です。一方、次の判断は人が持ちます。

何をサイトで伝えるか
誰を対象にした記事か
どの情報を公開してよいか
実体験と調査情報をどう区別するか
どの変更を本番へ反映するか
バックアップ失敗時に続行できる範囲か
宿泊者、宿猫、関係者に不利益がないか

この分担を曖昧にすると、AIが文章をきれいに整えても、宿の実情と違う記事や危険な運用になる可能性があります。

実際の基本フロー

ねこ宿研究所では、作業を次の段階へ分けます。

宿主が目的と条件を伝える
  ↓
AIが既存記事・計画・公式情報を調査する
  ↓
ローカルのMarkdown原稿と画像を作る
  ↓
内部リンク・分類・descriptionを確認する
  ↓
本番変更前のバックアップを取得・検証する
  ↓
WP-CLIで対象を限定して反映する
  ↓
投稿ID・投稿者・カテゴリ・画像を読み直す
  ↓
公開URL、本文、リンク、トップページを確認する
  ↓
失敗と学びを運用ルールへ残す

重要なのは、記事作成と本番反映を一つの操作にしないことです。調査中は変更せず、原稿ができてもすぐ公開せず、本番反映後も「コマンドが成功した」だけで完了にしません。

実例：一つの記事を相談から公開まで進める

ねこ宿研究所で宿主向け記事を一件追加するときは、次のように進めています。

1. 会話で目的を絞る

最初の依頼が「記事を作って」だけでも、AIは既存のコンテンツ計画と公開済み記事を確認します。次に作る予定の記事があるか、同じ結論の記事がすでにないか、前の記事から自然につながるかを調べます。

似た記事が存在する場合は、別URLを増やさず既存記事へ統合します。検索語が違うだけで内容が同じページを増やすと、読者にも検索エンジンにも違いが分かりにくくなるためです。

2. 変わりやすい事実を公式情報で確認する

WordPress、Codex、Claude Code、予約サービス、決済、Googleの機能は変更されます。AIの記憶だけで書かず、現在の公式資料を開いて確認します。

猫の健康や行動に関する記事では、獣医師会、動物福祉団体、査読論文などを優先します。宿紹介では宿の公式サイト、公式SNS、自治体・観光協会などを確認し、実際に泊まっていない内容を体験談にしません。

調査時には、参照URLと確認日を残します。ただし、検索結果に表示された短い説明だけで断定せず、元ページの本文を読みます。

3. 原稿、画像、内部リンクを一組で作る

原稿にはタイトルだけでなく、slug、description、分類、確認日、アイキャッチ画像の場所と代替テキストを記録します。

記事内の画像は、実在する宿や猫の記録写真に見える使い方を避けます。宿や猫の写真を許可なく転載せず、生成イラストの場合も「実際にその場面を撮影した写真」と誤認させない構図にします。

内部リンクは新記事から既存記事へ付けるだけでなく、関連する既存記事と宿主向け案内ページから新記事へ戻る道も作ります。

4. 人が公開範囲を確認する

公開前に、次を人の判断として確認します。

読者に伝えたい結論と合っている
宿泊していない内容を体験談にしていない
宿、猫、人物の情報を公開してよい
接続先、内部パス、利用者名、秘密値が入っていない
予約条件、料金、法律、健康情報を推測していない
関連記事と内容が重複していない

文章が自然であることだけを承認条件にしません。

5. 対象を限定して本番へ反映する

変更前にバックアップを実行し、正常終了と整合性を確認します。公開するのは承認した原稿、画像、必要な内部リンクだけです。依頼と関係のないテーマ、プラグイン、サーバー設定を同時に変更しません。

バックアップが失敗したときは、成功したことにせず停止条件と続行条件を確認します。可逆的な記事更新と、データ削除・移行・サーバー更新では復旧リスクが違います。

6. 読者が見る結果を確認する

WordPressから投稿者、公開状態、slug、カテゴリ、description、アイキャッチを読み直します。その後、公開URL、宿主向け案内、関連記事、トップページを確認します。

パソコンとスマートフォンの画面も撮影し、表、画像、見出し、予約導線が崩れていないかを目で確認します。宿主向け記事の場合は、意図どおり専用ページから読め、一般向けトップの新着へ混ざっていないことも確認します。

WordPressをAIの唯一の記憶にしない

WordPressは読者へ公開する場所ですが、記事計画、根拠資料、監査記録、運用ルールをすべて保存する場所ではありません。

情報	正本の例
公開記事の本文と属性	Markdown原稿
記事テーマと公開順	コンテンツ計画
宿や機能の確認元	調査記録
AIが守る作業ルール	`AGENTS.md`、`CLAUDE.md`
WordPress上の公開状態	投稿IDと公開ページ
公開後の結果	点検・監査記録

AIとの会話だけに重要な判断を残すと、別の日の作業で見つけられません。結論が固まったら、役割に合う正本へ記録します。

正本はWordPressだけに置かない

記事本文は、手元のMarkdownファイルを正本にしています。タイトル、slug、description、カテゴリ区分、アイキャッチの場所、確認日なども原稿側へ記録します。

title: "記事タイトル"
slug: "example-article"
description: "記事内容を説明する文章"
category: "宿主さん向け"
owner_section: "ai-site-management"
status: "publish"
fact_checked: "YYYY-MM-DD"
featured_image: "公開用画像の場所"
featured_image_alt: "画像の内容を説明する文章"

WordPress管理画面だけで直接編集すると、何を変更したか、以前の原稿がどれか、関連ページも直したかを追いにくくなります。手元に正本があれば、AIは本文だけでなく内部リンクや記事計画とのずれも確認できます。

ただし、公開用Markdownへサーバー構成や認証情報を入れません。AIが作業に使う内部の運用ルールと、読者へ配布するサンプルは分けています。

ケース1：ファイル名の間違いを自分のサイトでも直した

状況

Codexへプロジェクトの運用ルールを伝えるファイルを、単数形のAGENT.mdとして扱っていました。宿主向けテンプレートを作る過程で、正式なファイル名が複数形のAGENTS.mdであることを確認しました。

判断

配布記事の説明だけを直し、自分のプロジェクトでは旧名を使い続けると、読者へ勧める方法と実運用が一致しません。正本をAGENTS.mdへ統一することにしました。

実行と確認

ファイル名だけを変更せず、プロジェクト内で旧名を参照している説明、テンプレート、スクリプト、Claude Code向け案内を全文検索しました。新旧二つの正本が残らないことも確認しました。

学び

名称や仕様の誤りを見つけたら、公開記事だけでなく、自分の運用と参照元も一緒に直します。AIへ「名前を変えて」だけでなく、「旧名の参照箇所を調べ、変更候補を示して」と頼むと漏れを減らせます。

ケース2：ZIP配布をMarkdown直リンクへ変えた

状況

当初、AGENTS.mdとCLAUDE.mdのテンプレートをZIPで配布しました。しかし、ITに慣れていない宿主さんにとって、中身を開くまで確認できないZIPは不安になり得るという指摘がありました。

判断

技術的に配布できることと、利用者が安心して使えることは別です。ダウンロード前にブラウザで内容を読めるMarkdown直リンクへ変更しました。

実行と確認

新しいリンクが開くだけでなく、Markdownとして直接取得できること、古いZIPへのリンクが記事や一覧に残っていないことを確認しました。

学び

AIは「ファイルを置けた」「HTTPで開けた」を完了条件にしがちです。利用者の不安、保存時のファイル名、古い導線の残存まで完了条件へ加える必要があります。

ケース3：具体的すぎる公開サンプルから環境情報を消した

状況

AI運用の例を分かりやすくしようとして、公開テンプレートへ実際のサーバー方式、内部構成、作業コマンドに近い情報を含めていました。

判断

具体例は理解を助けますが、公開する必要のない内部情報は攻撃や不正アクセスの手がかりになり得ます。「具体的であるほど親切」とは限りません。

実行と確認

環境固有の記述を削除し、「権限を限定する」「復元できるバックアップを取る」「公開前に人が承認する」のように、構成を明かさず行動を再現できる表現へ置き換えました。テンプレートだけでなく、それを説明する記事や一覧も検索しました。

学び

読者へ公開するのは、判断原則、確認項目、架空環境の例までにします。接続先、内部パス、利用者名、秘密値、実運用の防御方法は公開しません。AIへは「秘密値を消す」だけでなく、「攻撃の手がかりになる構成情報も候補として示す」と依頼します。

ケース4：トップページの新着除外が最初は効かなかった

状況

宿主さん向け記事をトップページの通常の新着記事から除外する処理を追加しました。設定とコード上は正しく見えましたが、公開ページのHTMLを確認すると記事カードが残っていました。

判断

「機能を有効にしたから完了」ではなく、読者が見る最終結果を確認する必要があります。通常の記事一覧とトップページ独自の新着欄が、別の仕組みで投稿を取得している可能性を調べました。

実行と確認

トップページ内で対象記事が何件表示されているかを調べ、対象の取得処理へ除外条件を追加しました。修正後は次の二つを確認しました。

宿主さん向け記事のカードが0件
トップページの新着記事全体は予定件数を維持

学び

「表示されないこと」を確認するときは、対象が消えたことだけでは足りません。新着欄全体まで消えていないことも確認します。設定画面、データベース、HTML、実際の画面は別々の確認地点です。

ケース5：記事は公開できても内部リンクが不足した

状況

宿主さん向けの記事を増やしたところ、カテゴリは正しく設定されていても、初期記事に関連記事リンクがなく、新しい記事がハブページへ載っていない状態が見つかりました。

判断

カテゴリだけに頼らず、次の三層で読者の経路を作ることにしました。

ヘッダーメニューから「宿主さん向け」へ入る
ハブページで目的や分類を選ぶ
記事本文から前後・関連する記事へ進む

実行と確認

公開記事のURLと内部リンクを一覧化し、ハブへの掲載、記事間の往復リンク、カテゴリ分類を確認しました。ヘッダーには全記事を並べず、記事が存在する分類への入口だけを置きました。

学び

記事公開の完了条件へ「入口」「関連記事」「戻り道」を含めます。新記事だけにリンクを付けても、既存記事から到達できなければ片方向です。関連する既存記事も同時に更新します。

ケース6：バックアップが失敗したとき、成功したことにしなかった

状況

本番変更前のバックアップ中に、稼働中のファイルが変更されたことを検知し、新しいバックアップ処理が正常終了しませんでした。

判断

バックアップコマンドを実行したことと、正常なバックアップを取得できたことは別です。失敗を隠さず、次を確認しました。

作成途中の不完全ファイルが残っていないか
直近に整合性確認済みのバックアップがあるか
今回の変更は個別に元へ戻せるか
データ削除、移行、サーバー更新を含まないか

実行と確認

続行条件を満たす場合だけ、個別に非公開化や差し戻しができる記事追加へ範囲を限定しました。失敗したアーカイブを「取得済み」と報告せず、完了報告へ制約を明記しました。

学び

エラー時の安全な判断は、その場の気分で決めません。運用ルールへ「直近の検証済みバックアップ」「不完全ファイルの確認」「可逆的な変更だけ」「削除や移行は続行しない」と条件を書きます。

一回の依頼で全部を任せない

実際のやり取りでは、次のように依頼を分けています。

調査だけ

関連する原稿、記事計画、WordPress上の状態を確認してください。
今回は読み取りだけにし、ファイル編集、設定変更、公開はしないでください。
不足情報、重複、内部リンク候補、確認が必要な事実を報告してください。

ローカル原稿の作成

確認済みの情報だけでMarkdown原稿を作ってください。
本番WordPressは変更しないでください。
タイトル、slug、description、分類、内部リンク、参考資料、
公開してはいけない情報の有無を自己点検してください。

本番反映

承認した原稿1件と関連する内部リンクだけを本番へ反映してください。
変更前にバックアップを取得し、正常終了と整合性を確認してください。
対象外の記事、テーマ、プラグイン、サーバー設定は変更しないでください。

公開後の検証

投稿ID、投稿者、状態、slug、カテゴリ、アイキャッチ、descriptionを確認してください。
公開記事、ハブ、関連する既存記事、トップページのHTTP応答とリンクを確認してください。
表示されるべき場所と、表示されないべき場所を分けて報告してください。
未確認事項と失敗は完了扱いにしないでください。

依頼を分けると、どの段階で認識がずれたか分かりやすくなります。

WP-CLIは自由に実行させない

ねこ宿研究所の公開記事では、仕組みを学べる架空のコマンド例を紹介しています。一方、実運用の接続方法や実行経路は公開しません。

重要な考え方は共通しています。

最初は読み取りだけ
対象サイト、投稿ID、件数を固定
下書き作成と公開を別の操作にする
分類は変更前と変更後を比較
画像は1ファイルずつ取り込み、添付IDを確認
公開は人が承認した投稿IDだけ
削除、任意コード実行、DB操作を通常経路から外す
実行後はWordPressから値を読み直す

自由なWP-CLIではなく許可した操作だけを通す考え方は、制限付きラッパーの作り方で解説しています。

AIの完了報告に必要な項目

「公開しました」だけでは、宿主が安全性を判断できません。少なくとも次を報告させます。

作業結果
- 対象：記事名、slug、投稿ID
- 変更したもの：原稿、画像、内部リンク、WordPress投稿
- 変更していないもの：対象外記事、設定、サーバー
- バックアップ：正常終了、整合性、保存時刻
- WordPress確認：投稿者、状態、カテゴリ、画像、description
- 外部確認：記事、一覧、トップページのHTTP応答
- 表示確認：表示される場所、除外される場所
- 未確認事項：人の画面確認、予約フォームなど
- エラー：発生内容、停止した段階、続行判断の根拠

失敗や未確認事項を報告できるAI運用の方が、「すべて問題ありません」と断定する運用より信頼できます。

失敗を次回のルールへ変える

同じ指摘を毎回会話で繰り返さないため、判断が確定したら適切な正本へ残します。

学び	残す場所
AIが常に守る安全ルール	`AGENTS.md`、`CLAUDE.md`
記事テーマ、公開順、分類	コンテンツ計画
実際に起きた失敗と判断	ケースノート
記事本文、description、画像情報	各Markdown原稿
公開後の確認結果	運用記録・監査記録

一つの巨大な指示書へすべてを書かず、役割ごとに正本を分けます。ルールを追加したら、AIへ「次回から守ります」と言わせるだけでなく、実際のファイルへ反映され、参照できるか確認します。

OpenAIの公式ドキュメントでは、Codexは作業前にAGENTS.mdを読み、プロジェクトのルートから現在の作業場所へ向かって指示を重ねる仕組みが説明されています。ねこ宿研究所では、この仕組みを「AIへのお願い」ではなく、公開範囲、バックアップ、記事品質、停止条件を毎回確認するための運用ルールとして使っています。