WordPressは、よくできている。だが、よくできた檻でもある。テーマの作法、プラグインの相性、管理画面という決められた入口——「ちょっとここをこうしたい」のたびに、用意された枠の内側で妥協する。今回、自社のコーポレートサイトを建てるにあたって、私たちはその枠を一度すべて外した。既製CMSを使わず、隅々まで自分たちで設計できるオリジナルを、AIと1から建てた。いま読んでいるこのサイトが、その成果物だ。
これは「WordPressが悪い」という話ではない。"既製の枠に自分を合わせる時代"から、"枠ごと自分で作れる時代"へ——いま何が変わったのか。それを、実装の判断ごと開示する制作事例だ。

01何を、1から建てたか
作ったのは、ばらばらのツールの寄せ集めではない。コーポレートサイト・ランディングページ・ブログ・お知らせ、そして問い合わせ(=AIチャット)までを、ひとつのコードベースに統合した。バラバラの契約も、ツール間の連携設定も無い。
それぞれの面の役割を表に整理する。
| 面 | 役割・最適化の軸 |
|---|---|
| トップ | 「魅せる」面——スクロールとモーションで世界観を体感させる |
| ブログ/お知らせ | 「読ませる」面——可読性・表示速度・検索最適化を最優先 |
| ランディングページ | 受注専用の導線 |
| 問い合わせ | 静的フォームではなく、その場で会話して要件を聞き取るAIチャット |
既製CMSなら、これらは「サイト本体+問い合わせプラグイン+フォーム+外部チャットツール」と複数サービスの継ぎ接ぎになりがちだ。私たちは全部を地続きの一枚岩にした。継ぎ目がないことが、速度にも、体験にも、保守にも効く。
02サイト自体が"動く証拠"/AIっぽさを禁止する
CAGの旗印は「サイト自体が、AI開発力の動く証拠」。だから見た目も中身も妥協できない。ここで強い禁止を自分たちに課した——"いかにもAIが作った風"のデザインを全面禁止する。
- 意味もなく光るグラデーションの塊(blob)を置かない。
- 絵文字をアイコン代わりに使わない。
- 英語の大文字ラベルを装飾として散らさない。
これらは「AIに任せると勝手に出てくる手癖」だ。そのまま出荷すれば"AIが作った安いサイト"になる。見せたいのは逆——AIを道具として使いこなし、人が美意識で仕上げた"作品"。ダーク基調・シネマティック・精密。AIに任せる部分と人が握る部分の線引きそのものが、品質になる。
この「禁止リスト」は口約束ではなく、設計ドキュメントとして明文化してAIに渡してある。だからどのページを増築しても、どのAIセッションで作業しても、同じ美意識が貫かれる。面白いもので、禁止を明文化した途端にAIの提案の質が一段上がった。AIの出力品質は、モデルの賢さだけでなく「何を禁じるか」の言語化で決まる——これはデザインに限らず、AI駆動開発全般に効く発見だった。
03問い合わせフォームが、AIチャットだ
このサイトでいちばん尖っているのは、間違いなく問い合わせだ。普通のサイトの問い合わせは、名前とメールと用件を書いて送る静的フォーム。返事は早くて翌営業日。私たちはここを根本から変えた。
問い合わせフォームそのものが、AIチャットになっている。訪問者が「LPを作りたい」と打てば、AIがその場で会話を始める。目的は何か、予算感は、いつ欲しいか——雑談ではなく、受注に必要な要件を会話で聞き取っていく。そして聞き取った内容を、裏側で構造化されたデータに変換する。人間の営業が頭の中でやっている"見立て"を、その場で形にする。

訪問者から見れば、フォームに黙々と入力するのではなく、話しているうちに要件が整理され、概算と次の一歩まで見えている。「フォーム+自動返信メール」では絶対に届かない体験だ。
問い合わせは、待たせた瞬間に冷める。だから一次対応は、人を待たせないAIに任せる。
※ この受注AIの"中身"——ヒアリング設計・要件の構造化・確度の測り方——は、それだけで一本の記事になる。近いうちに別稿で深掘りする。
関連記事 | 予告した受注AIの「別稿」このサイトで対応しているAIは、自分たちで作った ──設計書を渡したら、1日で本番に立った「顧客対応AI」の制作記録
→
04なぜ、一次対応をAIに任せるのか
「AIに問い合わせ対応させるなんて雑では」と思うかもしれない。逆だ。一次対応こそAIの独壇場で、人間が出るべきは"その先"だ。
- 速い:質問にその場で答える。検討の熱が冷めない。
- 24時間:深夜でも休日でも、最初のヒアリングは止まらない。
- その分、安い:一次対応の人件費が要らない分を、価格に還元できる。
そして——ここが透明性として大事なところ——複雑な判断や最終的な約束は、必ず人間(職人)が引き継ぐ。AIが暴走して勝手に請け負うことはない。重要な分岐は人が握る(HITL[2])。「AIが一次対応するから速くて安い、でも肝心なところは人がやる」——この設計を、隠さずそのまま訪問者に伝えている。速さと誠実さは、両立する。
裏側の実務も書いておくと、AIとの会話で要件が一定の濃さに達したものは、即座に通知が飛んでくる仕組みにしてある。つまり訪問者がチャットを閉じた数分後には、人間側はもう整理済みの要件と温度感を手にして検討を始めている。従来の「フォーム受信→読み解き→ヒアリング日程調整→初回打ち合わせ」という数日がかりの工程が、会話一本に畳み込まれる。一次対応をAIに任せるのは省力化のためではなく、商談の立ち上がりを最速にするためだ。
05管理画面を、作らなかった
オリジナルでCMSを建てる、と聞くと「じゃあ記事を書く管理画面も作るんでしょ」と思われる。作らなかった。
記事もお知らせも、データベースに格納し、それをAI(Claude Code)が直接読み書きする。つまりAI自身がCMSの役割を担う。「この記事のタイトルをこう直して」「この事例を公開して」——言語化すれば、AIがデータベースを更新し、サイトに反映する。ログイン画面も、入力フォームも、プレビュー画面も要らない。
これが効くのは、WordPressの管理画面という"檻"から完全に自由になるからだ。既製CMSでは、管理画面が許す操作しかできない。オリジナルなら、隅々まで、やりたいことを直接やれる。更新はデータベースに反映された瞬間、オンデマンドの再生成(ISR[1])で即座にサイトへ。"管理画面を作らない"のは手抜きではなく、「人が触るUIを一個まるごと消す」という設計判断だ。作らないものを決めることも、設計だ。
副次的な恩恵も大きい。管理画面が無いということは、ログイン画面という攻撃の入口が無いということでもある。既製CMSの運用で延々と続く「管理画面への不正ログイン対策」「プラグインの脆弱性アップデート」という保守労働が、構造ごと消える。実際この記事も、管理画面を一度も開かずに——「この記事を公開して」という言葉から——あなたの画面に届いている。
06魅せると読ませるを、分けて最適化する
ひとつのサイトでも、ページの役割は違う。トップは世界観を体感させたい。記事は速く正確に読ませたい。この2つを同じ作りで処理すると、必ずどちらかが犠牲になる。
そこでレンダリングを2系統に分けた。トップは動きと演出に振り、記事面は可読性・表示速度・検索最適化に振る。記事は2モード——AIが書いた通常記事と、デザインまで作り込んだリッチ記事(この記事のように章ごとに図解アニメが入るもの)。「全部同じテンプレに流し込む」既製CMSの発想を、最初から捨てている。見せる場所では見せ、読ませる場所では読ませる。
07速さと品質の、地味な作り込み
派手な機能だけでは"作品"にならない。体感速度と安定性という地味な部分にこそ、作り手の質が出る。
- 重い演出は、見えていない時は止める:背景で動く粒子アニメは、画面外やタブ非表示のあいだ完全に停止。常時CPUを焼き続ける"もっさり"を最初から断つ。
- 依存ライブラリの地雷を、確実に対処:本番でだけ特定ページが落ちる厄介な不具合を、依存パッケージのバージョン固定まで遡って根治。「ローカルでは動く」で止めない。
- 更新は即時、でも常時再生成はしない:普段は静的配信で速く、更新が入った時だけ対象ページを再生成。速さと鮮度を両取りする。
一つひとつは見出しになりにくい。だが"とりあえず動く"と"納品できる"のあいだの距離は、まさにここで詰まる。AIで速く作れるからこそ、空いた時間を品質に回せる。実際このサイトも、公開後に「もっさり重い」と感じた箇所を計測から潰し、ページの転送量を二桁削った(その実測ログは別記事で全部開示している)。自社サイトは、品質改善の実験台としても働き続ける——既製の枠では踏み込めない深さまで、自分たちのコードだから踏み込める。
関連記事 | その実測ログ(別記事)「もっさり重い」の正体は、たいてい画像だった ──自社サイトを10MB→0.3MBに軽くした実測ログ
→
08デザインと透明性、そしてこれから
デザインは、AI任せでも人任せでもなく、人間とAIで詰めた。AIに大量の案を出させ、人が美意識で選び、整える。手癖を禁止し、配色や余白の規則を一元化して、隅々まで一貫させる。速く、かつ作品として整っている——この両立が、オリジナルで建てる最大の見返りだ。

公開も、誠実にやっている。完成までは一時的に閲覧を制限し、整った状態で世に出す。背伸びした人数訴求はしない。いま動かしているのは、数名の職人+AI駆動。それで「早い・安い・高品質」を成立させている、という事実だけを見せる。
そして、このサイトは完成品ではなく生きた工房だ。ブログの図解の作り方、画像の最適化、問い合わせAIの受け答え——公開後も毎週どこかが良くなっている。既製テンプレのサイトは公開日が品質のピークだが、自分たちのコードで建てたサイトは公開日が品質のスタート地点になる。この差は、運用が長くなるほど開いていく。
WordPressをやめろ、と言いたいのではない。"既製の枠に自分を合わせる"必要が、もう無くなったと言いたい。言語化できるものは、AIと1から作れる。隅々まで、思った通りに。プラグインを探す時間で、その機能そのものが作れてしまう時代だ。次にあなたが「これ、WordPressじゃ無理だよな」と諦めたもの。——まず、言葉にしてみてほしい。
既製CMS vs AIで建てるオリジナル。同じ"サイトを持つ"でも、何が変わるか——要点を一枚に。
| 観点 | 既製CMS(WordPress等) | 電脳技巧集団(AI職人ギルド) |
|---|---|---|
| 土台 | テーマ/プラグインの制約内 | フルスクラッチ・隅々まで設計可能 |
| 更新の入口 | 管理画面にログインして編集 | 管理画面なし=AIが直接更新 |
| 問い合わせ | 静的フォーム→自動返信メール | AIチャットがヒアリング→要件を構造化→受注処理 |
| 表示 | テーマ任せ(一律) | 魅せる/読ませるを2系統で最適化(速度・SEO) |
| カスタマイズ | プラグイン依存・限界あり | 要件に合わせて何でも実装・自社資産化 |
| 反映速度 | 手作業で編集・公開 | 言語化→AIが反映、ISRで即時 |
※ 本記事は自社サイト(cag-web)の実装に基づく制作事例。受注AIチャットの内部設計の詳細は別稿で扱う。
脚注
- ISR(Incremental Static Regeneration)=普段は静的配信で高速、更新が入った対象ページだけをオンデマンドで再生成する仕組み。速さと鮮度を両立する。
- HITL(Human-in-the-Loop)=重要な判断や最終的な約束に必ず人間が介在する設計。AIは一次対応に徹し、肝心な分岐は職人=人が握る。








