仕様書から動きの調整まで、コーポレートサイトの作り方
Massivのコーポレートサイトを2026年9月30日に公開しました。
ページ本体はCodex、トップのヒーロー背景のアニメーションはClaude Codeが実装していて、人は基本的に文言とか見た目とか動きを選ぶ役をやっていました。
この記事では、仕様書を書いてからAIエージェントに実装を任せた流れと、ヒーロー背景の動きを調整ページで選んで組み込んだ話を紹介します。
仕様書
Massivでは、AIエージェントにソフトウェア開発の工程を任せるSoftware Factoryという仕組みを作っています。要求仕様、設計、実装、テスト、デプロイの各工程をAIエージェントが進めて、人は仕様を書くところとレビューをやる、という考え方です。
コーポレートサイトもこの流れで作ったので、実装の前に次の3つのドキュメントを書いています。
product.md誰に何を伝えるサイトかコーポレートサイト
概要
「コーポレートサイト」は、Massiv に興味を持った企業や投資家に対して、いまの事業と目指していることを伝え、問い合わせやプロダクトサイトへつなぐ受け皿となる会社紹介のサイトである。
背景と解決する課題
- 事業内容は「Software Factory」「事業承継・成長支援」「AX コンサルティング」の 3 つである
feature-requirements.md公開と更新の要件と受け入れ条件コーポレートサイトの公開・更新
このドキュメントについて
コーポレートサイトで会社情報・記事を閲覧し、問い合わせへ進むための要件を記述する。社員による掲載内容の更新も対象とする。
スコープ
- トップページ、Aboutページ、共通のヘッダー・フッターと各リンク
- トップでのブログ・お知らせの紹介、お知らせ一覧・詳細の閲覧
- PC・スマートフォンに対応した表示と、トップの背景アニメーション
feature-design.md構成と実装の方針コーポレートサイトの公開・更新の設計・実装方針
このドキュメントについて
コーポレートサイトの公開・更新の要件を実現するため、画面、コンテンツ処理、静的ビルドと公開の実装方針を定める。
フレームワークと静的出力
コーポレートサイトを Next.js App Router と StyleX で実装する。Next.js の output: "export" によって静的ファイルを生成し、Cloudflare Workersの静的アセットとして配信する。
会社紹介のサイトに仕様書を書くのは結構大げさな感じもしますが、AIエージェントに任せるなら「誰向けか」「何を載せないか」のような前提はドキュメントで渡しておく必要があります。人が実装するときは頭の中にある前提も、エージェントはドキュメントからしか読めないためです。
実際に、ページ本体はCodexがFigma Console MCPでFigmaのフレームや文字、余白を読み取って実装しました。最初のプレビューの時点で体感9割ぐらいはできていて (測った値ではないです)、あとはプレビューを見ながら、Figmaでは表現されてなかったHoverなどの動きを調整していきました。
ページを作る前に、FigmaのVariable (変数) をStyleXのデザイントークンとして定義するといったサイトを作る上でのビルディングブロックを用意したのが良かったと思います。
ヒーロー背景の分担
Figmaでデザインを作った時点で、ヒーロー背景に動きをつけたいという話はありましたが、どう動かすかは決まっていませんでした。そこで、Figmaで決まっているページ本体の実装と、まだ決まっていない背景の動きを試して探す作業を分けて、並行して進められるようにしました。
ページ本体はCodex、背景の動きはClaude Codeの担当として分けて、実装を並行して進めました。ページ本体は最終的には人がレビューしながら進めますが、ヒーロー背景は特にどんなパターンを描くかを模索する段階でした。いろいろなイメージを伝えて、それを表現できる形にするという、まとめて渡せるタスクだったのが分けた理由です。
ページ側はFigmaの静止した背景を敷いて先に作り、動く背景は別の場所で試して、動きが決まったら差し込むという形です。
ページ本体とヒーロー背景の境界は、次の2つだけにしています。
- 描画処理の関数
mountHeroBackground(要素, 設定)(とそれを包むReactのコンポーネント) - 動きの設定を持つJSON
ページ側はこの関数とJSONのことだけ知っていればいいので、動きが決まるまで待たなくても進められます。
うまくいかなかったこととしては、方針が行ったり来たりしてる間に、ヒーロー背景の組み込みが本体側と試作側の2か所で進んでしまいました。最終的には試作側を採用して、本体側は捨てています。同じファイルを触る作業は、担当を1か所に決めてから始めた方が良かったです。
動きの調整ページ
ヒーロー背景で困ったのは、動きの指示が言葉だと全然伝わらないことでした。「ゆっくり色が動く」「マウスでかき混ぜる」と言っても、どれぐらいの速さや量なのかは人によってイメージが違います。
実装してプレビューを見て「もう少し弱く」と返す往復は、1回の待ち時間が長いです。それなのに、さっき見たものとは比べられないのが微妙です。
そのため、最終形を先に決めるのはやめて、値を触って見比べるための調整用のテストページを先に作り、そこで動きを調整しました。左に本番と同じ描画処理で動く背景、右に動きの強さや色の流れなどのスライダーが並んでいて、値を動かすとその場で背景に反映されます。PRごとにプレビューのURLが発行されるので、URLを渡せばデザイナーも同じものを触れます。
作りとしては、動きを決める要素を全部パラメータとして持たせて、それをすべて画面の操作で調整できるようにしています。そのうえで、調整の出発点になる具体的な設定を、いくつかのプリセットとして用意しました。プリセットは完成形として選ぶものではなく、プリセットを起点に自分で値を変えて動きを詰めていくためのものです。
進め方は大きく3段階でした。最初は、イメージするパターンをいろいろ渡して、それをパラメータで表現し、プリセットをいくつも作りました。この段階は正解を探すというより、選択肢の幅を見るためのものです。
次に、デザイナーと調整ページを触りながら、動きの大枠の方向性を決めました。ここで「外形は動かさずに中の色がゆっくり動く」「細かいピクセル模様」「マウスで色をかき混ぜる」の3つを組み合わせた方向性にしています。いろいろなプリセットを実際に見ながら「これは違う」と言えた部分が大きいので、言葉だけで最初からこの3つを出すのは難しかったと思います。
大枠が決まったあとは、その方向性に沿って細かい値を詰めました。たとえば、マウスで色をかき混ぜる強さなどは、パラメータを変えながら調整した値を使っています。
調整ページでは、調整したパラメータを共有リンクやJSONとして書き出せるので、それを渡して「こんな感じ」と伝え合いながら進めていました。本番でも、採用した設定をまとめたJSONを描画処理が読み込んでいます。
採用する値が決まった後に、調整ページやプリセット、採用しなかった動きは削除しました。Gitの履歴には残っているので、また動きを変えたくなったら戻せます。
組み込み
動きが決まったら、トップページに組み込みます。最終的には次のような動きになっています。
組み込んでみると、調整ページでは起きていなかったパフォーマンスの問題がいくつか出てきました。
- ぼかしの多いSVGを背景の下に敷いたら、GPUがない環境のChromeで1枚描くのに約0.9秒かかり、Firefoxでは描画が詰まった
- ヘッダーの
backdrop-filter: blur()が、毎コマ描き直すWebGLの上でぼかしを計算し直すので重くなった - 静止画をCSSの背景にしたら、それがLCPの対象になってLighthouseの点数が下がった
- 読み込み直後に一瞬白くちらついた
どれも調整ページでは起きていなかったので、組み込んだときに起きた問題だとすぐに切り分けられました。
WebGLみたいに、実装を間違えると簡単に重くなったり、LCPの問題が起きたりするものは、最初から別の場所で作って調整していたのが良かった点です。
あとは、デスクトップのLighthouseでスコアが100になるように、ChromeのPerformanceパネルやLighthouseを使って細かい点を調整していきました。
たとえば、CPUを6倍遅くしたプロファイルで、ハイドレーションの115msのタスクのうち約90msをWebGLの準備が占めていたので、別のタスクに分けています。また、GPUが使えずWebGLをCPUで描く環境では、背景を描くだけでページ全体が重くなります。そのため、CPUで描く端末では、WebGLを使わずに2Dのcanvasへ静止した背景を描くようにしています。
まとめ
Massivのコーポレートサイトは次のように作りました。
- 仕様書 (product、feature-requirements、feature-design) を書いてから、ページ本体をCodex、ヒーロー背景をClaude Codeに任せた
- ページ本体とヒーロー背景の境界は描画の関数と設定のJSONだけにして、並行して進めた
- 動きは調整ページで触りながら決めて、調整した設定を共有して「こんな感じ」と伝え合った
- 調整ページでは起きていなかったので、組み込んだときに出たパフォーマンスの問題をすぐ切り分けられた
AIエージェントに実装を任せると、実装よりも「どれを選ぶか」を決める方に時間がかかる場合もあります。言葉で伝えにくいものは、決めるための道具を先に作るのが結構良かったです。動きに限らず、色やレイアウトなども同じようなやり方でいけそうな気がしています。