前編：サーバーレス構成とアクセシビリティの徹底

数年ぶりに自社サイトを全面リニューアルしました。生成AIの普及に伴い、弊社でもAIを活用したコンサルティングやデータ分析の支援案件が増加したため、現在の事業内容と提供価値を正確に伝える構成へ刷新しています。

前編では、運用の保守性を高める技術選定と、利用環境を問わず誰もがストレスなく閲覧できるように配慮したアクセシビリティ設計についてまとめます。

サーバー保守を持たない技術スタック

サイトは Astro で構築し、Cloudflare 上でホスティングしています。

• フレームワーク: Astro
• インフラ: Cloudflare
• CMS: EmDash（Astro向けヘッドレスCMS）
• データ配置: 記事本文は Cloudflare D1、画像アセットは Cloudflare R2

更新頻度が高いのは記事コンテンツのみであるため、常時稼働するサーバーやプラグインの保守コストを排除する構成を選びました。

当初は Vercel + Next.js + microCMS の構成を想定していましたが、新しく登場した EmDash を実環境で検証・運用したく方針を切り替えました。EmDash は現在ベータ版であり、将来的に別 CMS へ移行する可能性も残しています。そのため、データ取得処理を単一モジュールに集約し、ページ側のテンプレートがデータソースの差異を意識せずに済む抽象化を行っています。

WordPress を選ばなかった理由

制作の現場で最も多く使われている CMS は WordPress です。今回も候補に入れましたが、採用しませんでした。理由は機能ではなく、セキュリティの構造にあります。

WordPress は、PHP の実行環境とデータベースが常時稼働し、その上で本体・テーマ・プラグインという複数の提供元のコードが同時に動く仕組みです。この構造には、運用側の努力では消せない弱点があります。

• 入口の場所が公開されている: 管理画面のパス（/wp-admin/、/wp-login.php）は既定で決まっているため、公開した直後から総当たりのログイン試行を受け続けます。
• 弱点は本体の外側に生まれる: 公開される WordPress 関連の脆弱性情報は、その多くが本体ではなくプラグインやテーマに対するものです。セキュリティ企業 Patchstack の年次報告「State of WordPress Security in 2026」では、2025 年に見つかった WordPress 関連の脆弱性 11,334 件のうち、91% がプラグイン、9% がテーマで、本体は 6 件でした。本体の更新を欠かさなくても、導入したプラグインの一つが古いままなら、そこが侵入口になります。
• 更新作業に終わりがない: 本体・テーマ・プラグイン・PHP のバージョンを噛み合った状態に保つ作業が、サイトが存在する限り続きます。しかもプラグインは開発が止まることがあり、更新できるかどうかを自社では決められません。

弊社のサイトは、記事以外の更新頻度が高くありません。それにもかかわらず、誰も見ていない時間もサーバーとデータベースが動き続け、その保守に費用と注意を払い続けることになります。この釣り合いの悪さが、WordPress を外した理由です。

EmDash を選んだのは、この構造そのものが無くなるからです。PHP の実行環境も、常時稼働するデータベースサーバーもありません。記事は Cloudflare D1 に保存し、ページの配信時に読み出して HTML に埋め込みます。第三者のプラグインを本番環境へ持ち込む仕組みも存在しません。

もちろん、管理画面が無いわけではなく、攻撃を受ける面がゼロになるわけでもありません。ただ、守る対象が「自分たちが書いたコードと、その認証」だけに絞られます。範囲が狭いぶん、隅まで確かめられます。公開ページには Content-Security-Policy を設定し、ページ内に直接書いたスクリプトとスタイルはハッシュで一つずつ許可しました（unsafe-inline は使っていません）。HTTPS の応答には HSTS を付け、問い合わせの送信には一定時間あたりの回数制限を設けています。

ベータ版の CMS を本番に載せる不安と、保守が終わらない不安を並べて、前者を選びました。

ただ運営している自社メディアMOSHIMO-AIはWordPressで構築しているので、EmDashの使い勝手を見てから移行しようかと考えています。

色は感覚で選ばず、すべて相対輝度比で算出する

サイト内の文字色と背景色の組み合わせは、すべて相対輝度比を算出して決定しました。感覚値による配色は排除しています。

公開ページをヘッドレスブラウザで走査し、実際に描画されている全 1,316 箇所のテキストについて、前景色と背景色を取得してコントラスト比を算出しました。JIS X 8341-3:2016 の適合レベル AA（通常テキスト 4.5:1 以上、大型テキスト 3:1 以上）を全箇所で達成しています。最もコントラスト比が低かった箇所でも 5.30:1 を確保しており、これは日付表示やテーブル見出しなどの 11px の小さなラベル要素です。

表と数値は画像化せず、キーボード操作を担保する

料金表や機能比較表を画像化すると、スクリーンリーダーやクローラーが内容を読み取れません。本サイトの表はすべて HTML の <table> 要素として組んでいます。

• 視覚的インジケーター: モバイルなどの狭小画面ではみ出す場合、横スクロール可能であることを示す丸い印を重ねて表示し、スワイプ操作または数秒の経過でフェードアウトします。
• キーボード操作: 表が水平スクロールしている状態でのみコンテナへ tabindex="0" を付与し、Tab キーでフォーカスして矢印キーで送れるように制御しました。画面幅が十分ではみ出していない状態ではフォーカス順路から外し、不要なキーストロークを発生させない設計にしています。

JavaScript が停止しても本文閲覧・基本操作を完結させる

JavaScript を無効化した環境でも全ページを巡回し、本文が欠損なく読めることを確認しています。

記事の絞り込み機能も同様に、選択後に送信ボタンを押して URL クエリ経由で条件を渡す設計です。UI 操作の途中で画面が勝手に再読み込みされないため、キーボード操作や音声読み上げの文脈を乱しません。

視差効果を減らす設定では、物理的な移動のみを遮断する

OS の「視差効果を減らす（prefers-reduced-motion: reduce）」が有効な環境では、まず CSS ですべてのアニメーションを停止します。その上で、視覚フィードバックに必要なスタイル変化のみを個別に復帰させています。

復帰させているのは、色変化、不透明度変化、下線表示などの「要素の位置が 1px も動かない変化」に限定しています。前庭障害（めまいや平衡感覚の乱れ）の引き金となるのは位置の移動・回転・拡大縮小のモーションであり、色の変化ではありません。すべての演出を一律に遮断せず、コンテンツの出現アニメーションは不透明度のフェードのみに切り替えて自然な閲覧体験を維持しています。

編集後記

AI使ったサイトはいくつも公開してきましたが、自社サイトになるとあれもこれもしたくなり思ったより時間が掛かりました。本当は構想から5日で仕上げたかったのですが、8日くらいかかりました。

実際にEmDashを使ってみましたが、今のところ感覚的には問題無いかと思います。これからブラッシュアップしていくCMSなので楽しみです。