xecin.jpをAstroで運用して1年、ドッグフーディングで分かった現実

「自分たちで使っていないものを他社に勧めるのは気持ち悪い」という感覚が、自社サイトをAstroで作り直した一番の動機でした。

クライアントへの提案資料にAstro+S3+CloudFrontの構成を書くたびに、「これで本当に回るのか、うちはどうなの」という引っかかりがあったんですよね。だから去年の春、既存のWordPressサイトをそっくりAstroに移し替えて、1年間実際に自分たちで使ってみることにしました。

あれからちょうど1年が経ったので、正直に振り返ってみます。

1年分のデータを先に出す

まず数字を出しておきます。

「月数百円」という話は本当でした。最初の月、請求額が380円だったときは少し笑いました。

ビルド失敗7回はすべてフロントマターのミスで、titleが100文字を超えていたとか、publishedAtの形式が崩れていたといった類のものです。実際のビルドスクリプトのバグでは一度も失敗していない。これは今思えば、Zodスキーマで厳密にバリデーションが走っているおかげで、コンテンツの問題がビルド時に確実に検知できているということでもあります。

想定通りに楽だった部分

インフラコストとセキュリティ運用は、本当に心配しなくなりました。

WordPressの頃は毎月「プラグインのアップデートをいつやるか」「PHPのバージョンが古くなっていないか」という判断をしていたんですが、静的サイトにしてからはそういう悩みが消えた。サーバーサイドで動くものがないので、脆弱性のサーフェスが極端に小さくなる。

CloudFrontの設定も、一度作ったら基本的に触らないです。オリジンのバケット設定、TTL、カスタムエラーレスポンスあたりを初期に整えてしまえば、以降は黙って動き続けてくれます。

// astro.config.mjs の基本設定
// CloudFront側のキャッシュ設定と合わせて、これだけで動く
export default defineConfig({
  site: 'https://xecin.jp',
  output: 'static',
  integrations: [react(), mdx(), sitemap()],
});

表示速度も期待通りでした。LighthouseのスコアはPerformanceが97〜100、Accessibilityが98、Best Practicesが100で安定しています。WordPressの頃は良い日で75くらいだったので、これは大きな違いです。

想定外に手間だった部分

正直に言うと、3点あります。

1つ目は画像最適化です。

Astroの <Image> コンポーネントは優秀なんですが、クライアントから渡ってくる画像ファイルのサイズがまちまちで、毎回「この画像はWebPに変換した上でどのsizesを指定すべきか」という判断が入ってしまう。自動最適化はされるんですが、自動化ゆえに「なぜかビルドが遅い」という現象が起きたりして、最初は原因がわからなかったです。

---
// 改善の余地がある: 毎回手動でwidth/heightを指定しているが、
// 後から画像を差し替えた時に忘れがちで、レイアウトシフトが起きるケースがある
import { Image } from 'astro:assets';
import thumbnail from '../../assets/news/sample.jpg';
---

<Image src={thumbnail} width={800} height={450} alt="サムネイル" />

これは今もベストな解決策を探しています。

2つ目はMDX編集体験です。

エンジニアは問題ないんですが、非エンジニアのメンバーに「ニュース記事をMarkdownで書いてください」とお願いした時の反応が思っていたより厳しかった。「フロントマターって何ですか」という質問から始まり、Wikiページを作って説明しても「やっぱり難しい」という声がなくならない。

ここは自分の想定が甘かったです。「Gitさえ覚えれば大丈夫」と思っていたんですが、「Gitを覚えること自体が壁だった」という事実を見落としていました。

現状、非エンジニアメンバーの更新作業はAIエージェントに中継させる形で回しています。ドラフトをドキュメントツールに書いてもらって、AIがMDXに変換してPRを出す、という流れです。

3つ目はリダイレクト管理です。

古いURLへのアクセスが来た時のリダイレクト設定は、CloudFront+S3の構成ではastro.config.mjsに書くか、CloudFront Functions/Lambda@Edgeを使うかの選択になります。

// astro.config.mjs のredirects設定
// シンプルなケースはこれで済む
export default defineConfig({
  redirects: {
    '/old-path': '/new-path',
    '/blog/[slug]': '/news/[slug]',
  },
});

単純なリダイレクトはこれで問題ないんですが、クエリパラメータを含む複雑なパターンや条件分岐が必要なケースになると、Astroのconfig側では対応できなくてCloudFront Functionsに書き直すことになります。このへんの境界線を最初に整理できていなかったので、途中で設定を書き直す羽目になりました。ドキュメントにはconfigのredirectsが推奨として書いてあるんですが、実際の運用では「このケースはFunctions側で書かないとダメだ」という判断が必要なシーンが結構あるんですよね。

1年経って「他社に勧められる構成かどうか」への今の答え

今の答えは「向くサイトと向かないサイトがある、というのが前提条件」です。

コーポレートサイトのうち、以下の条件を満たすなら自信を持って勧めます。

• コンテンツ更新の主担当がエンジニアまたはエンジニアが近くにいる
• 会員機能・リアルタイム検索・予約機能が不要（または別サービスで補える）
• 表示速度・セキュリティ・運用コストを重視している

逆に、非エンジニアだけで運用したい場合や、WordPressのリッチエディタに慣れている編集者がメインになる場合は、ヘッドレスCMSとの組み合わせを先に考えた方がいいと思っています。

1年通して「このサイトをWordPressに戻したい」とは一度も思いませんでした。インフラの不安がなくなって、Lighthouseスコアが安定していて、月のランニングコストが数百円というのは、一度慣れると手放したくない状態なんですよね。

おわりに

ドッグフーディングの良さは「自分が困ったことを正直に話せること」だと思っています。画像最適化もMDX編集体験もリダイレクト管理も、実際に自分たちが困った話なので嘘がない。

この構成に関して、もっとうまい解決策を知っている方がいたら教えてもらえると助かります。特に非エンジニア向けのMDX編集体験の改善は、まだ良い着地点が見えていないです。