Making of
このサイトについて
生成AIが誤った答えを返すとき、原因の多くはAI自身にはない。
何を作りたいのか、その輪郭をどれだけ言葉にできているか——その精度が、そのままAIの出力の精度になる。イメージが粗ければ、返ってくるものも粗い。イメージが精緻であれば、AIはその精緻さに応える。
このページは、その過程をそのまま記録したものである。宣伝でも、完成報告でもない。上流設計者とAIのあいだで交わされた、言葉のやり取りの記録である。
01 / Background
Next.js（フロントエンド）とWordPress（ヘッドレスCMS）を組み合わせた構成には、高い開発コストを要する「高級な構成」という評価がつきまとう。実装には複数のシニアエンジニアの関与が前提とされることが多く、限られた体制で完結させる例は多くない。
このサイトは、その構成を「上流設計者」と「AI」の二者だけで実装したものである。
02 / Production Log
配色：陽極酸化チタンという、言葉にしづらい色
品質の水準を、金属の質感で語りたいという要望があった。アルミ、金、鉄、チタン——候補はいくつかあったが、行き着いたのはチタンだった。一見単純に見えながら、加工には極めて高い精度を要し、想定外の応用範囲を持つ。技術者としての価値観と、質感として重なるものがあった。
そこからさらに踏み込み、「陽極酸化チタンの焼き色」というイメージに至った。塗装でも染料でもない。酸化被膜の厚みという物理現象だけで生まれる発色である。この現象を、色の名前でも数値でもなく、言葉として伝えることから始まった。
やり取りを重ねる中で、金・青銅・紫・青・シアン・緑・マゼンタという焼き色の帯が、グラデーションとして立ち上がっていった。デザイナーは、いなかった。
形状：数式の限界と、実物への切り替え
3Dワイヤーフレームは、最初から脳の形を狙っていた。ただし、3Dモデルではなく数式による近似から始まった。球状のジオメトリを三角関数のノイズで歪ませ、前頭葉・側頭葉の膨らみを表現し、脳幹には別の円柱ジオメトリを接続した。
しかし、参考にしていたイメージとの差は埋まらなかった。数式によるパラメータ調整には、届く先があった。脳回や脳溝といった解剖学的な情報は、手続き的な変形だけでは作り込めない。
方針を切り替え、実在する低ポリゴンの脳3Dモデルを調達した。その頂点とエッジだけを取り出し、ワイヤーフレームとして描画する方式に置き換えた。数式が届かなかった場所に、実物のデータが代わりに入った。
負荷：精緻さと、表示速度のせめぎ合い
ギヨシェ模様は、曲線を重ねるほど精緻に見える。だが、重ねるほど描画の負荷も増す。
サイト全体をLighthouseという外部の検査ツールで測定したとき、この密度がそのままページの表示速度に跳ね返ってくることが分かった。美しさだけを基準にしていては、通らない検査だった。
視覚的な密度を保ったまま、描画する曲線の本数を絞り込んだ。デザインの判断と、性能の基準が、同じ天秤の上に乗った瞬間だった。
選定：知らないフレームワークを、選ばずに選ぶ
HTML、CSS、JavaScriptという、Webの基礎的な仕組みは理解していた。しかし、その先の実装——具体的にどのフレームワークで、どう構築するか、という下流の工程には、長く直接携わっていなかった。
Next.jsとWordPressのヘッドレス構成という選択は、こちら側が指定したものではない。要件と制約を伝えた先に、AIが提案してきたものだった。
知らない技術を、知らないまま採用する。普通であれば、無謀な判断である。だが、実装そのものをAIに委ねられるのであれば、選定の妥当性は、動くものが出来上がるかどうかで検証できる。判断の基準が、知識の有無から、結果の有無に移っていた。
ただし、これは何も知らずに成立する話ではない。ターミナルを開き、コマンドを打ち、Next.jsを起動する。時にはJavaScriptやCSSを直接書き換える。そうした基礎的な技術リテラシーは、指示する側に前提として求められる。
何より、AIが何を提案し、何を根拠にその判断をしているのか——それを理解し、誤りがあれば的確に指摘できることが要る。AIに委ねることと、AIに従うことは、同じではない。
この判断は、フロントエンドの技術選定に限った話ではないはずだ。オンプレミスか、AWSやAzureのような大規模クラウドか——サーバーサイドのアーキテクチャ選定も、本来はバックエンドエンジニアの経験と判断を要する領域である。
今回の実証実験では、その領域まで踏み込んではいない。ただ、フロントエンドの判断をAIが補ったのと同じ構造が、サーバーサイドの選定においても成り立たない理由はない。判断の主体が人間からAIに移るのではなく、判断の材料を、AIが的確に示せるかどうかの問題である。
こちらも当然ながら、基本的なバックエンドの基礎知識は前提として必要になる。
この姿勢は、このサイト単体の実証実験にとどまらない。
スマートフォンのネイティブアプリケーション、大規模ポータルサイト、業務系システム——領域を問わず、同じ姿勢で取り組んでいる。単純なプロンプトエンジニアリングの範囲にとどまらず、AIエンジンそのものの活用にまで及ぶ。大規模LLM、ローカルLLM、マルチモーダル処理、MCPサーバーによる外部ツール連携——これらを組み合わせながら、領域ごとに異なる技術基盤を構築している。
裾野を広げているのは、器用さではない。新しい分野であっても、AIと基礎知識によるスキルさえあれば、イメージすることができる。イメージできれば、実現できる。これが、私たちが「AIに全振りする」と決めた理由である。
03 / Architecture
このサイトの要件定義について
各要素の選定理由は示すが、具体的な実装構成・セキュリティ設定については、公開範囲の観点から解説を控える。
- フロントエンド：Next.js（React）——App Routerによるレンダリング戦略（ISR/SSR）の柔軟性を理由に採用
- バックエンド／CMS：WordPress（Headless）——記事更新・コンテンツ管理のオーナーシップを、既存のWordPress運用フローのまま維持するために採用
- データ連携：WordPress REST API——CMSと表示層を分離しつつ、既存の管理画面資産を活かすための接続方式として採用
- インフラ／デプロイ：クラウド型ホスティングサービス——ステージング環境との継続性を理由に採用
04 / Approach
上流設計者とAIだけで、下流工程を完結させるアプローチ
コーディングや環境構築などの下流工程をAIが自律的に担えるよう、上流設計者がインプットの質を極限まで高めるアプローチを取っている。
- 高解像度なシステム設計書の提示：データ構造、APIエンドポイントの紐付け、Next.jsのレンダリング戦略（ISR/SSR）をメタ情報としてAIに精緻に指示する
- 自律的デバッグ（エージェント的活用）：Next.js特有のエラーやWordPress側のAPI連携エラーに対し、ログをAIにフィードバックして自己修復させるループを構築する
- プロンプトの型（フレームワーク）化：文脈や制約条件を最適化した「設計書受け渡し用プロンプト」を開発する
この「上流設計から下流実装までを一人で完結させる」あり方は、Companyページで定義している「AIコーディネーター」という職業観そのものの実践である。
05 / Theses
技術難易度の質的転換——労働集約から、知能集約へ。プロのエンジニアでも設計に迷う「Next.js＋WordPress」の結合をAIで完結させることで、高度なIT資産が「エンジニアの労働集約型」から「AIによる知能集約型」へと、構造そのものが転換したことを示す。
開発コストと期間の圧縮——従来体制との比較において、開発期間・人件費の両面で差が生まれる。
運用・保守フェーズにおける再現性——開発初期だけでなく、納品後の仕様変更やバグ修正、プラグインアップデートへの対応も、同じAI活用アプローチで低コストに継続できる。
ただし、この試みもまた、AIと人間の関わり方における、無数の事例の一つに過ぎない。
故に、それをイメージできないものは、実現できない。イメージを言葉に変える者を、私たちは「AIコーディネーター」と呼ぶ。このサイトは、その一つの答えである。