なぜPython/AIチームは、2026年にあえて「枯れたWordPress」を選んだのか？：『主権』を取り戻すためのアーキテクチャ論

Introduction: The “Next.js Trap”

「AI開発チームなら、当然サイトもNext.jsやRemixで作るんでしょう？」

同業者からよくそう言われます。
確かに、技術的なトレンドを追えば「Headless CMS」が正解に見えるかもしれません。Vercelにデプロイして、MicroCMSと繋げば、モダンでクールなサイトが一瞬で出来上がります。

しかし、私たちはあえて、20年以上続くレガシーな技術である「WordPress」を選びました。
しかも、多くのモダンな開発者が嫌う「PHP」のテーマ（Enfold）をベースにしています。

なぜ、そんな「時代遅れ」な選択をしたのか？
技術力が低いから？ いいえ、違います。

「ビジネスの主権（Sovereignty）」と「資産性」を最優先した結果、最新のフレームワークこそが『最大のリスク』に見えたからです。

この記事では、技術選定の裏にある「経営的な意思決定」と、それを支える独自の「Python × WordPress ハイブリッド・アーキテクチャ（Kinesis）」の全貌を、私たちの生々しい失敗談（Logs）を交えて公開します。

---

1. Context: なぜ「枯れた技術」が必要だったか

1-1. “Sovereignty”（主権）の欠如

Next.js + Vercel + MicroCMS… モダンな構成は魅力的ですが、依存先が増えるほど「主権」は失われます。
サービスの規約変更、料金改定、APIの停止。ある日突然、プラットフォームの都合でビジネスが脅かされる。
私たちは、「外部要因でビジネスが止まるリスク」を極限までゼロにしたかったのです。

1-2. テキストこそが最強のデータベース

AI時代において、最も価値があるのは「データベースの中身」ではなく「テキストファイル（Markdown）」そのものです。
WordPressはCMSですが、私たちはこれを単なる「表示装置（Viewer）」として扱っています。

「記事データは全て手元のMarkdownファイルにある。WordPressが消えても、明日から別のシステムで再開できる」

この状態こそが、私たちが定義する「資産」です。プラットフォームに人質を取られない状態。それが真の自由です。

---

2. Architecture: “Kinesis” System（脳と身体の分離）

WordPressの弱点は「重さ」と「開発体験の悪さ」です。
これを解決するために、私たちは「脳（思考・執筆）」をPython（ローカル）に、「身体（表示）」をWordPress（サーバー）に完全分離しました。

Concept: “Shadow AI”

WordPressの中に重いAIプラグインは一切入れていません。
その代わり、ローカル環境のPythonエージェント「Antigravity」が全ての重計算（SEO分析、推敲、タグ付け）を行っています。

実装ログ：Kinesis Loader

Pythonで生成されたMarkdownファイルは、SSH経由でサーバーに同期されます。
サーバー側では、軽量なPHPスクリプト（Kinesis Loader）がそれを検知し、WordPressに投稿します。

Result: 驚異の「Desktop 95点」

プラグインを極限まで排除した結果、LighthouseのスコアはDesktop 95点以上、Mobileでも90点台をマークしました。
「WordPressは遅い」というのは、大抵の場合「プラグインの入れすぎ」が原因です。アーキテクチャさえ間違えなければ、枯れた技術は誰よりも速く走れます。

---

3. Failure Log: AIは魔法使いではない

しかし、すべてが順調だったわけではありません。
私たちは「AIなら何でも自動化できる」と過信し、痛い目を見ました。

Log [2026-01-22]: テーマ設定の自動化失敗

私たちは、使用しているテーマ「Enfold」のデザイン設定（文字サイズや色）まで、Pythonから直接データベースを書き換えて制御しようと試みました。

結果は「大失敗」でした。

• 現象: データベースの値は書き換わっているのに、サイト上の見た目が変わらない。あるいはレイアウトが崩れる。
• 原因: Enfoldは設定値をシリアライズ（暗号化に近い圧縮）して保存しており、さらに複雑なバリデーションやキャッシュ機能を持っていたため、外部からの強引な書き換えを受け付けませんでした。
• 教訓: 「UI/UXの微調整は手動が最強」。

プログラムで数時間かけて解析するより、管理画面でポチッと設定する方が100倍速い。
私たちは「自動化すべき領域（記事）」と「手動であるべき領域（デザイン）」の境界線を、身を持って学びました。

---

4. Conclusion: 技術選定は「生き方」の選択である

私たちは、Next.jsを否定するわけではありません。素晴らしい技術です。
しかし、「長く、太く、自分の足で立ち続けるビジネス」を作りたいなら、流行りの技術に飛びつく前に一度立ち止まって考えてみてください。

「その技術は、5年後もあなたを裏切りませんか？」
「そのデータの『主権』は、本当にあなたが持っていますか？」

私たちがWordPressとPythonを選んだのは、それが最も「自由」に近い組み合わせだったからです。
このKinesisアーキテクチャは、技術的な最適解であると同時に、私たちの「自律（Agency）」への意志そのものなのです。

さあ、あなたも「主権」を取り戻す旅に出ましょう。

---

Category: Engineering Strategy
Tags: WordPress, Python, Architecture, Kinesis, Failure Log

Introduction: The “Next.js Trap”

「AI開発チームなら、当然サイトもNext.jsやRemixで作るんでしょう？」
同業者からよくそう言われます。確かに、技術的なトレンドを追えば「Headless CMS」が正解に見えるかもしれません。

しかし、私たちはあえて、20年以上続くレガシーな技術である「WordPress」を選びました。
しかも、多くのモダンな開発者が嫌う「PHP」のテーマ（Enfold）をベースにしています。

なぜか？
それは技術力が低いからではありません。
「ビジネスの主権（Sovereignty）」と「資産性」を最優先した結果、最新のフレームワークが『リスク』に見えたからです。

この記事では、技術選定の裏にある「経営的な意思決定」と、それを支える独自の「Python × WordPress ハイブリッド・アーキテクチャ（Kinesis）」の全貌を、失敗談（Logs）を交えて公開します。

---

1. Context: なぜ「枯れた技術」が必要だったか

1-1. “Sovereignty”（主権）の欠如

Next.js + Vercel + MicroCMS… モダンな構成は魅力的ですが、依存先が増えるほど「主権」は失われます。
サービスの規約変更、料金改定、APIの停止。
私たちは、「外部要因でビジネスが止まるリスク」を極限までゼロにしたかった。

1-2. テキストこそが最強のデータベース

AI時代において、最も価値があるのは「データベースの中身」ではなく「テキストファイル（Markdown）」そのものです。
WordPressはCMSですが、私たちはこれを単なる「表示装置（Viewer）」として扱っています。
「記事データは全て手元のMarkdownファイルにある。WordPressが消えても、明日から別のシステムで再開できる」
この状態こそが、私たちが定義する「資産」です。

---

2. Architecture: “Kinesis” System（脳と身体の分離）

WordPressの弱点は「重さ」と「開発体験の悪さ」です。
これを解決するために、私たちは「脳（思考・執筆）」をPython（ローカル）に、「身体（表示）」をWordPress（サーバー）に完全分離しました。

Concept: “Shadow AI”

WordPressの中に重いAIプラグインは一切入れていません。
その代わり、ローカル環境のPythonエージェント「Antigravity」が全ての重計算（SEO分析、推敲、タグ付け）を行っています。

実装ログ：Kinesis Loader

Pythonで生成されたMarkdownファイルは、SSH経由でサーバーに同期されます。
サーバー側では、軽量なPHPスクリプト（Kinesis Loader）がそれを検知し、WordPressに投稿します。

Result: 驚異の「Desktop 95点」

プラグインを極限まで排除した結果、LighthouseのスコアはDesktop 95点以上、Mobileでも90点台をマークしました。
「WordPressは遅い」というのは、大抵の場合「プラグインの入れすぎ」が原因です。アーキテクチャさえ間違えなければ、枯れた技術は誰よりも速く走れます。

---

3. Failure Log: AIは魔法使いではない

しかし、すべてが順調だったわけではありません。
私たちは「AIなら何でも自動化できる」と過信し、痛い目を見ました。

Log [2026-01-22]: テーマ設定の自動化失敗

私たちは、使用しているテーマ「Enfold」のデザイン設定（文字サイズや色）まで、Pythonから直接データベースを書き換えて制御しようと試みました。

結果は「大失敗」でした。

• 現象: データベースの値は書き換わっているのに、サイト上の見た目が変わらない。あるいはレイアウトが崩れる。
• 原因: Enfoldは設定値をシリアライズ（暗号化に近い圧縮）して保存しており、さらに複雑なバリデーションやキャッシュ機能を持っていたため、外部からの強引な書き換えを受け付けませんでした。
• 教訓: 「UI/UXの微調整は手動が最強」。

プログラムで数時間かけて解析するより、管理画面でポチッと設定する方が100倍速い。
私たちは「自動化すべき領域（記事）」と「手動であるべき領域（デザイン）」の境界線を、身を持って学びました。

---

4. Conclusion: 技術選定は「生き方」の選択である

私たちは、Next.jsを否定するわけではありません。
しかし、「長く、太く、自分の足で立ち続けるビジネス」を作りたいなら、流行りの技術に飛びつく前に一度立ち止まって考えてみてください。

• その技術は、5年後もあなたを支えてくれますか？
• そのデータの「主権」は、本当にあなたが持っていますか？

私たちがWordPressとPythonを選んだのは、それが最も「自由」に近い組み合わせだったからです。
このKinesisアーキテクチャは、私たちの「自律（Agency）」への意志そのものなのです。

---

Category: Engineering Strategy
Tags: WordPress, Python, Architecture, Kinesis, Failure Log