---
title: コーポレートサイト
project: swept
kind: web
question: なぜ Astro で作ったのか
answer: 情報要件自体はシンプルなのでフレームワークは最小構成にし、その軽い土台の上にブランド表現として 3D を乗せる、という組み方が Astro + Cloudflare に一番きれいに収まったから。
canonical_url: "https://toyoshima.work/works/swept/web"
---

# コーポレートサイト

import ChapterLink from '@/components/pages/works/ChapterLink.astro';
import Figure from '@/components/pages/works/Figure.astro';
import InlineVideo from '@/components/pages/works/InlineVideo.astro';

「愛着」テーマに切り替わった Phase 2 で、コーポレートサイトを設計から実装まで一人で担当しました。**Astro を本格採用したのはこのサイトが最初**で、Cloudflare にデプロイしたのもまだ 2〜3 回目という初期です。技術選定を一つずつリサーチしながら組んだ、自分にとっての土台づくりの案件でした。

## デザインの方向性を先に決めた

技術選定より前に、デザインの方向性は固まっていました。ロゴの延長で **卵モチーフ** と **余白を持たせたゆったりした雰囲気** はすでに決まっていて、そこに乗せる細部の作法として、ちょうど仕様が公開されたばかりだった **Material Design 3 Expressive** を読み込んでいます。

Material Design は 2 の頃から追っていて、Expressive で一段化けたと感じていました。Web サイトにそのまま持ち込めるわけではありません(どちらかというとアプリケーション向けの概念)が、学べる部分は多いと思っています。

- **丸み** — 角があるとどうしても視点がそこに固まってしまう
- **色と形の組み合わせで状態を表現する**という発想
- **ヒエラルキー**の大切さ。ボタンの優先順位をこの頃から強く意識するようになった

もう一つ、他のメンバーの希望も加味して **グラスモーフィズム** を採用しました。ゆったり・余白という方向性と相性が良いという判断です。

## Astro を選んだ理由

実装は Astro + Tailwind。選定理由は、

- Cloudflare に置きたく、Next.js は当時相性が悪かった
- コーポレートサイトの**情報要件自体は重くない**。極論 HTML/CSS で足りる
- その要件に対して、React 系の中で最小構成で組めるものを探した

結果 Astro が一番きれいに収まりました。**同じ要件なら今でも第 1 候補は Astro** です。唯一変えるとしたら、当時は Cloudflare Pages に置きましたが、今は Astro のアダプタが Pages 非対応になったので Cloudflare Workers にデプロイします。逆に言うと、それ以外の技術選定は 1 年経った今リサーチし直しても、ほぼ同じ構成を選びます。当時そこそこ真面目に調べて組めていた、という手応えがあります。

## 3D はブランド表現として乗せた

土台をあえて軽くしたぶん、表現に振れる余白ができました。ここで **Blender で 3D モデリングを起こし、Three.js でサイト上に描画する**、という挑戦を乗せています。

<InlineVideo src="/works/swept-hero.webm" caption="Blenderで作った3Dモデルをトップページで描画" />

創業期のスタートアップは、良くも悪くも情報が薄いものです。「具体的に何をやっているか」を言葉で説明しきれない段階でも、抽象度の高い 3D モデルなら雰囲気で「こういうことをやろうとしている」を伝えられる、というのがこの表現を選んだ理由です。ロゴの卵モチーフ(→<ChapterLink to="swept/logo" />)をはじめとする世界観を、平面のあしらいで終わらせず 3D 表現まで一貫させたかった、という思いもありました。Astro / Cloudflare はこの案件でしっかり自分のものにしましたが、Three.js は今回軽く触れた程度で、本格的に使いこなせるところまでは至っていません。それでも技術的な挑戦として、素直に勉強になった一本です。

## お問い合わせは、あえてラジオボタンにした

問い合わせ種別の選択肢は、一般的にはプルダウンで済ませることが多いところを、あえて **ラジオボタン** にしています。

<Figure src="/Swept/contact-form.png" alt="お問い合わせページ、種別選択をラジオボタンにしている" caption="問い合わせ種別をラジオボタンで選ばせるお問い合わせページ" />

もちろんデメリットもあります。プルダウンに比べて **一覧性が低く**、下までスクロールしないと自分がどの項目に該当するか分かりにくい。それを理解した上でラジオボタンを選んだのは、当時の自分たちのフェーズに合っていると判断したからです。

- **to B の窓口ならプルダウンで十分** — やることが明確に決まっている相手なら、選択肢を畳んでしまっても迷わない
- ただし社会起業・愛着というテーマ上、**個人からの問い合わせも大事にしたい**。「企業へのお問い合わせ」然とした固さがあると、個人は書き込みにくくなる
- 選択肢を全部開いて見せることで、「どんな人の、どんな問い合わせでも受け付けている」というウェルカムな空気を出したかった

創業初期は「来るもの拒まず」で、ユーザーも取材も研究協力も何でもウェルカムに受け止めた方がメリットが大きいと考えていて、この設計もその発想を反映したものです。

## コンテンツ管理は MicroCMS、今なら MDX

お知らせなどの更新用に、当時は **MicroCMS** を CMS として入れました。ここは今なら変えます。

外部のライターが書くわけではなく、**更新するのは内部だけ**の運用です。それなら外部 CMS を挟むより、**MDX でリポジトリ内にマークダウンを持つ**方が素直でした。今のコーディングエージェントを前提にすれば、Keystatic を使う / あるいは CMS を使わずマークダウンを更新しやすい仕組みを用意する、といった形にすると思います。

## Figma で全ページと画面遷移を組んだ

実装前に、Figma 上で全ページのデザインを組んでいます。実装の段階で「このページはなし」「このページを追加」といった変更もあったので、今の実装と完全には一致しませんが、サイト全体の雰囲気を掴むには十分でした。

<Figure src="/Swept/figma-pages.png" alt="Figmaで組んだ全ページのデザイン" caption="全ページのデザイン" />

画面遷移のアニメーションも軽く付けています。最終的に実装するのは自分自身だと分かっていたので、凝ったアニメーションを作り込む必要はなく、「ここはこう動く」という遷移の流れさえ掴めれば十分、という判断でした。

<Figure src="/Swept/figma-flow.png" alt="画面遷移のフロー図" caption="画面遷移のフロー" />

## Atomic Design は Figma 止まりにすべきだった

当時 Figma 上のコンポーネント管理は **Atomic Design**(Atoms → Molecules → Organisms)で組んでいました。この分割自体は、Figma 上でコンポーネントを管理する分にはとても便利で、悪い判断ではありません。

<Figure src="/Swept/figma-atomic-design.png" alt="AtomsからOrganismsまでのAtomic Design分割" caption="Atoms → Molecules → Organisms の分割" />

反省しているのは、これをそのまま実装側のコンポーネント分割にまで引きずったこと。デザインと実装の両方をやってみて分かったのですが、Figma 上では便利な Atomic Design も、実装でコンポーネントを管理する段になると混乱しやすい。**デザイン(Figma)のコンポーネント管理と、実装のコンポーネント管理は、別々に最適解を考えた方がいい**、というのがここでの学びです。それ以降のサイト制作では、Atomic Design を実装まで持ち込まないようにしています。

## 以前は、モバイルファーストで情報設計をやりすぎていた

今のデザインの前に、実は別のデザイン一式を作っていました。ロゴ(卵モチーフ)が決まる前の段階で、ブランドとして依って立つモチーフがまだなく、方向性を決めるのに苦労した記憶があります。

<Figure src="/Swept/old-design-mobile-first.png" alt="以前作っていたモバイルファーストのデザイン一式" caption="以前作っていたデザイン(不採用)" />

この時は **モバイルファースト** で組んでいました。ただ、その後 Web 制作会社に入って学んだのは、Web サイトに関しては **PC を基本の重心にしつつ、崩し方を頭の片隅に置いておく** バランスの方がやりやすい、ということ。PC のデザインをしている最中にも「これはモバイルだとどう見えるか」をうっすら想像しておく。モバイルの見え方をまったく想像できていない PC 一辺倒のデザインもそれはそれでバランスが悪いので、どちらかに寄せすぎないことも大事にしつつ、基本の軸足は PC 側に置く、というのが今の自分のやり方です。

このデザインを作る過程で、情報アーキテクチャやサイトマップ、ユーザーフローも一通り用意しています。

<Figure src="/Swept/information-architecture.png" alt="以前作っていた情報アーキテクチャ" caption="以前作っていた情報アーキテクチャ" />

正直、今の規模感からすると **ここまで作り込む必要はなかった**と今は思っています。実際、その後のデザインでこれらを直接参考にしたわけでもありません。ただ、こういう情報設計を一通り自分の手で作った経験自体は、次に真面目にやるときの引き出しになっていると思います。

ロゴで卵モチーフが決まってからは、そこから逆算してデザインを組めるようになりました。ブランドのアイデンティティが先に立つとここまで作りやすくなるのか、と実感した一件です。今のデザインの方が気に入っています。

## 持ち帰ったもの

- Astro / Cloudflare / Three.js を、リサーチしながら**同時に立ち上げて出荷まで通した**こと。ここで組んだ技術選定の型が、今も基本そのまま通用している
- ただのコーポレートサイトを、ブランドの世界観まで背負った**そこそこの規模のサイトとして、保守性を保ちながら**実装できたこと

細部のデザインは、その後サイト制作の場数が一気に増えたこともあり、今ならもっと詰められると思っています。ただ「余白・ゆったり」というブランドの方向性の置き方自体は、当時から悪くなかったと思っている一本です。