WordPressを公開しないサイト構成closed OSS ＋ AI ＋ Sites 実践記
WordPressをインターネットに公開せず、記事や会社情報の管理基盤として使う。AIが内容を選び、独立したフロントエンドをSitesへ反映する。このデモサイトで試した「closed OSS ＋ AI ＋ Sites」のWordPress編をご紹介します。
今回の検証は、GPTを利用するOpenAI Codexのクラウド作業環境で実施しました。WordPressは、AIサービスに付属する非公開の作業環境内で動かしています。別途WordPress用の公開サーバーを契約・設置した構成ではありません。AIが内部CLIで操作し、公開用に選別した内容だけをSitesへ反映します。
青凪ホールディングスの会社情報や業績は架空ですが、本記事で説明するサイト構成と検証結果は、このデモの制作作業に基づきます。2026年11月8日時点の試作であり、本番運用への完全適合を示すものではありません。
全体構成：管理と配信を分ける
一般的なWordPressサイトでは、WordPressが記事を管理し、テーマを使って閲覧者へページを返します。今回の構成では、この二つを分けました。WordPressはこの非公開の作業環境内に置き、閲覧者にはSitesで配信する別のサイトを届けます。
内部CLIで操作
独立フロントを作成
閲覧者へ配信
図の矢印はAIを介した制作工程です。WordPressとSitesを直接つなぐAPI・DB接続は設けていません。
同じAIサービスを、管理と公開の共通窓口にする
今回の構成の利点は、同じAIサービスから、非公開WordPressの内部操作と、公開Sitesの制作・反映を一貫して扱えることです。原稿を読み、公開対象を選び、フロントを修正し、検証して反映するまでの文脈を共有でき、別々の管理画面を往復して手作業で転記する工程を減らせます。所有者限定の管理画面も、その作業を確認・依頼する入口になります。
ただし、すべてのデータや実行基盤が一つの閉域内に収まる、という意味ではありません。WordPressを動かす非公開の作業環境、Sitesの配信基盤、外部バックアップ先は別で、権限・永続性・稼働条件も個別に確認が必要です。今回もGoogle Driveへの外部退避を利用しています。同じ窓口で操作できることと、同じ保存場所・同じセキュリティ境界にあることは区別しています。
今回のサイト構成では、WordPressと公開フロントを直接接続するためのAPIキーは用意していません。AIは内部CLIで原稿を操作し、Sitesの正式な操作機能で選別した成果物を反映します。ブラウザーや公開コードにWordPressの管理キーを埋め込まずに済み、管理すべき秘密情報の配布先や受信口を減らせる点が利点です。
一方、認証が存在しない仕組みではありません。AIアカウント、Sitesの公開操作、ソース反映時の短期的な認証情報、Drive連携には、それぞれ権限があります。バックアップの復号鍵も別に必要です。APIキーの手動設定が少ないことと、無条件に安全であることは同じではありません。アカウント保護、最小権限、公開データの選別、鍵管理を合わせて考えます。
共通窓口に集約する分、そのAIアカウントや連携権限の保護も重要になります。運用をまとめながら、管理情報と公開成果物を分離する。この組み合わせを検証するためのデモです。
ここでいう「closed OSS」は、OSSのソースコードを非公開にするという意味ではありません。OSSを動かす実行環境を外部へ公開せず、内部で管理・操作する構成を指しています。
WordPressは非公開の管理基盤
この非公開の作業環境内でWordPressとMariaDBをコンテナで動かし、AIが内部のWP-CLIから原稿を登録・更新・読み出しできるようにしました。ブラウザー用のHTTPサーバーは起動していません。通常のWordPress管理画面にログインする運用ではありません。
- WordPress操作は内部CLIから実行。
- DB接続は共有UNIXソケットを使用し、MariaDBのTCP接続は無効化。
- OSSコンテナはネットワークなし・公開ポートなしで起動。
- コンテナ内は非rootユーザーで実行し、Linux capabilityを削除。
ネットワーク試験では、CLIコンテナから外部IPへのTCP接続が「Network unreachable」となり、HTTP・MySQLのループバックTCP接続も拒否されました。DBとCLIコンテナの経路・TCP listenerも確認しています。ただし、これはOSSコンテナ内の結果です。AIが動くホストやクラウド基盤全体の通信を完全遮断した、という意味ではありません。
DBとWordPressファイルはコンテナの外側へbind mountしています。これを、実行環境から独立した永続ボリュームの保証と同一視はしていません。
実際のWordPressに保存されている内容
以下の3枚は、非公開の作業環境内のWordPressから取得したコマンド出力を、クラウドの端末で表示して撮影したものです。ブラウザーの管理画面や、その場でCLIを実行している画面ではありません。掲載に不要なホスト名・作業パスが出ない状態で撮影しています。
AIが担う、選別と公開反映
この構成でAIが担当するのは、記事を管理する作業と、その内容を公開用のサイトへ反映する作業です。閲覧者がページを開くたびにAIを呼び出す仕組みではありません。
- 内部CLIで原稿を登録・更新し、読み戻して内容を照合する。
- 公開対象を選び、下書きや内部情報の混入がないか確認する。
- 選別した内容から、WordPressのテーマに依存しないHTML・CSS・JavaScriptを作る。
- ページ間リンク、表示に必要なファイル、操作ロジックを検査する。
- 公開用の成果物だけをSitesへ反映する。
今回の試作では、原稿と公開フロントをAIの制作作業の中で作成・照合しています。WordPressの変更を検知して自動でビルドする汎用同期システムや、すべての記事を自動公開する仕組みは実装していません。
WordPressの下書きは、保存しただけではSitesに現れません。WordPress内の「公開」状態も、Sitesの公開状態とは別です。内容の選別と明示的な反映を制作工程として扱います。
Sitesは独立した公開フロント
公開側は、会社情報・事業紹介・IR情報・サステナビリティ・ニュースなど、別URLを持つ複数ページで構成しています。WordPressのテーマや管理画面を静的化して持ち出したものではありません。
IR資料の年度切替やニュースの分類絞り込みは、公開済みのデータを使ってブラウザー内で動きます。公開サイトのコードにWordPressへ問い合わせるAPI処理はありません。画像・CSS・JavaScriptも、必要な公開ファイルをまとめて配信しています。
実例：不足する機能を、AIがOSSの外側に追加する
次に試したのが、公開サイトの検索機能です。この構成ではWordPressが閲覧者からのリクエストを受けないため、通常のWordPressの検索画面や検索APIを、そのまま公開側の検索として使うことはできません。
そこでAIに、WordPressのプラグインやテーマを変更するのではなく、独立した公開フロント側に検索機能を実装させました。追加したのは、キーワード検索、分類絞り込み、検索結果へのリンク、検索条件を含むURLの共有です。
検索データは、公開用成果物の17ページからタイトル・本文・URL・分類を抽出して作成します。検索ページ自身は対象から除外しています。WordPressのDBや下書き、バックアップは読み込みません。
閲覧者が検索すると、ブラウザーはSitesから公開用の検索データを取得し、その中を検索します。全角・半角や英字の大小文字をそろえ、スペースで区切った複数の語をすべて含むページを探し、タイトルに語が含まれるページを優先する仕組みです。AIが作った通常のコードが動くので、検索のたびに生成AIを呼ぶわけではありません。
- WordPress側：本体・プラグイン・テーマは変更せず、管理用の非公開構成を維持。
- 公開側：検索画面、検索処理、公開ページだけの検索データを追加。
- 更新時：選別した内容を公開成果物に反映し、検索データも再生成して一緒に配信。
- 対象外：非公開記事、画像内の文字、ダウンロードしたCSVの中身、意味を推測するAI検索。
日本語、全角・半角、英字の大小文字、複数語、分類、空のキーワード、該当なし、タイトル優先順位の試験を実施しました。また、非公開の検証用記事の識別語が検索データに含まれないことを確認しています。サイト全体は18ページとなり、内部参照481件の参照先も検査しました。
Sitesへの配信は成功しています。ただし、検索画面の実ブラウザーでの一連の操作試験は、この記事の追記時点では未完了です。コード上の試験と、ブラウザーでの確認は分けて記録しています。
検索用のデータは公開ファイルであり、ダウンロード可能です。「画面で見えにくくする」ことで情報を保護する仕組みではありません。公開してよい内容だけを含めることが前提です。また、検索条件をURLに含めると、ブラウザー履歴や、そのURLがリクエストされた際のホスティング側ログに残る場合があります。
この実例で示したいのは、OSSにすべての機能を詰め込む必要はない、ということです。管理はWordPressに任せたまま、公開側で完結する機能を外部の独立コードとして追加できます。注文・決済のように正本の更新や即時整合性が必要な機能は、別のAPI設計が必要になります。
実例：所有者限定の管理ダッシュボードも、OSSの外側に
公開サイトの検索に続いて、管理する人のための機能も追加しました。一般公開のコーポレートサイトとは別に、所有者だけが閲覧できる非公開Sitesを作り、WordPressと公開サイトの管理情報をまとめています。
- 概要：原稿件数、公開ページ数、バックアップ世代、保存済みの復元結果を確認。
- 原稿と公開状況：WordPressの原稿21件を検索・絞り込み。公開反映先がある16件と、反映先のない原稿を区別。
- バックアップ・復元：ローカル11世代と、過去に実施した隔離復元の測定結果・未整備項目を表示。
- AIへの作業依頼：情報更新や原稿照合などの依頼文をコピーし、チャットから作業を依頼。
件数は画面の情報取得時点の値です。「公開反映先あり」は対応ページが存在するという意味で、最新の原稿と公開内容が一致していることまでは示しません。また、最新バックアップの復元を毎回確認しているわけではありません。
この画面はWordPressの管理テーマやプラグインではなく、AIが別のコードとして作った管理用フロントです。AIが内部CLIや検証記録から必要な情報を取り出し、非公開画面のスナップショットとして反映します。ページを再読み込みしても、WordPressの最新状態を自動取得する仕組みではありません。
アクセス制御は画面の見た目やURLの隠し方ではなく、Sitesの所有者限定設定で行います。配信後の設定読戻しでは、許可された利用者が所有者のみ、外部閲覧者が0であることを確認しました。匿名セッションでの拒否試験や、実ブラウザーでの全操作試験は別途必要です。
依頼ボタンから、DB更新・公開・復元が直接実行されるわけではありません。今の段階では依頼文をコピーし、AIとのチャットで作業する方式です。これにより、WordPressの受信ポートや汎用の管理APIを公開せずに、所有者向けの管理機能も追加できることを示しました。
独自ドメインは closed-demo-wordpress.chartd.net。Sites側へ登録し、DNSのCNAME・所有権確認レコードを設定した後、ドメインとSSLの有効化を確認しました。DNS変更はユーザーが実施しています。
公開範囲を変更した後、一度トップページでログイン画面が出る事象がありました。一般公開用の操作で再デプロイし、その後ユーザー提供の画面でトップページの表示を確認しています。未ログインの新規セッションによる全ページ試験は別途必要です。
保存できることと、復元できることは別
バックアップは、MariaDBのトランザクション整合性を意識したダンプと、WordPressのファイル、復元に必要な設定・イメージ情報をまとめ、AES-256-GCMで暗号化してから保存しました。復号鍵は暗号化アーカイブに含めていません。ファイルも含めた整合性のため、取得中は編集を止める運用です。
外部退避には正式なGoogle Drive連携を使いました。約35.4 MBの暗号文を保存し、再取得したデータから別ディレクトリ・別DBへ復元しています。環境へファイルを取り込むツールに32 MiBの上限があったため、実際の取得・復元試験では暗号文を二つに分割し、再取得後に結合しました。
SHA-256
不一致 0
転送時間を除く
認証付き復号、DB投入、WordPress起動、検証用下書きの本文一致を確認しました。暗号文を1 byte改変した場合に復号が拒否されることも確認しています。
この11.37秒は、同じ実行環境内に必要なイメージと鍵がある条件での復元部分だけの値です。障害発生からの完全な復旧時間や、すべての機能の復旧を保証する値ではありません。
確認できたこと・残る課題
実際に確認したこと
- 内部CLIによる原稿の保存・読み戻し。
- OSSコンテナの公開ポートなし・通信遮断。
- 独立フロントの作成とSitesへの配信。
- 独自ドメイン・SSLの有効化。
- 暗号化バックアップのDrive保存・再取得・隔離復元。
- 15ページ構成の段階で、リンク331件の参照先を検査。
引き続き検証が必要なこと
- 環境消失後も回復できる、独立した鍵管理。
- まっさらな別環境への復元と依存関係の準備。
- Drive連携の実際の許可範囲、容量・保持条件。
- 複数世代の外部保管、定期実行、失敗通知。
- RPO・RTOと、停止・休止中の実行条件。
- OSS停止中の公開表示、実ブラウザーでの全ページ・通信試験。
以前の原稿・DB・バックアップが今回のチャットでも残っていたことは確認しました。一方、別の実行環境へ自動で引き継がれることや、環境自体が失われても保持されることまでは実証していません。
自動ブラウザー検証は、プレビュー基盤の接続タイムアウトなどで完了できませんでした。コード検査・公開操作の成功と、実際のブラウザーでの全動作確認は分けて記録しています。
会社案内やブログから、小さく試す
この構成は、会社案内、サービス紹介、読み物、ニュースなど、内容を選別して反映できるサイトの検証に向いています。管理基盤と配信を分けることで、公開に必要なものだけを外へ出す境界を設けられます。
一方、注文、決済、予約、在庫更新、利用者ごとの認証データなど、即時性やトランザクションが必要な機能には、認証・認可・整合性を備えた別のAPI設計が必要です。「AIが後から転記する」だけで置き換えられるものではありません。
また、非公開であれば無条件に安全、AIが選別すれば漏洩しない、ということでもありません。AIが読む原稿を操作指示と混同しないこと、配布対象の検査、秘密情報の管理、公開側の権限設定は引き続き重要です。
今回のWordPress編で確かめたのは、非公開OSS、AIによる制作作業、独立した公開フロントを組み合わせて、一つのサイトを作れるということです。本番採用に進むには、永続化・鍵回復・運用監視・復元手順を、利用する基盤の条件に合わせて詰める必要があります。