↗お問い合わせ
Menu

Development & AI partner
技術と対話で、つくる時間を前へ。

← JournalWeb開発 · 2026/8/29

会社サイトを、WordPress前提から静的Astroへ組み直した記録

使わなくなったCMSとAWS構成を見直し、ブランド、情報設計、アクセシビリティ、SEO、GitHub運用を静的サイトとして再構築した判断と検証をまとめます。

  • Astro
  • 静的サイト
  • アクセシビリティ
  • GitHub
d-assistの緑と紺を使ったホームページ上部。静的Astroサイトへ刷新した実画面
d-assistの緑と紺を使ったホームページ上部。静的Astroサイトへ刷新した実画面

会社サイトを刷新するとき、最初に難しかったのは「新しい見た目をどうするか」ではありませんでした。すでに利用を終えていたWordPressとAWS上の構成を、この先も維持する理由があるのか。更新の自由度を保ちながら、サーバー運用と費用をどこまで小さくできるのか。さらに、長く使ってきたロゴの印象を残しつつ、会社の現在地を説明できるサイトへどう移行するか。この三つを同時に決める必要がありました。

この記事では、株式会社d-assistのホームページを静的なAstroサイトへ組み直した過程を、実際のGit履歴、Issue、表示確認、ビルド結果に基づいて振り返ります。完成画面だけでなく、一度採用しかけて戻したデザイン、ロゴ修正で形を変えてしまった失敗、情報を増やした結果ページが長くなった問題、外部フォントをセルフホストしなかった判断も記録します。

最初に決めたのは「CMSを置き換える」のではなく、責務を減らすこと

旧サイトではWordPressを使っていました。しかし、日常的に管理画面から複数人が更新する状態ではなくなっていました。この状況で独自CMSを新しく作ると、認証、権限、入力画面、プレビュー、データ保存、バックアップ、脆弱性対応といった、会社サイトそのものとは別の運用責任が増えます。

そこで、会社情報や事業ページはAstroコンポーネントで管理し、記事だけをMarkdownとして扱う構成にしました。編集履歴とレビューはGitHubに任せ、公開物は静的HTMLへ変換します。管理画面を作らなくても、develop ブランチで変更を確認し、承認したものを公開ブランチへ進められます。

採用した境界は次のとおりです。

対象 管理方法 理由
トップ・会社・事業ページ Astro / HTML レイアウトとコピーを一体でレビューするため
ブログ記事 Markdown / Content Collection 原稿とメタデータをGit差分で確認するため
画像・ロゴ 静的アセット CDNや画像管理システムを増やさないため
変更履歴 GitHub ブランチ、PR、タグで復帰点を残すため

Astro側のブログ定義は、記事を単なるMarkdownファイルとして読むだけでなく、公開に必要な項目をビルド時に検査します。以下は実装を記事用に短縮したものです。

const blog = defineCollection({
  loader: glob({ pattern: '**/*.{md,mdx}', base: './src/content/blog' }),
  schema: z.object({
    title: z.string(),
    description: z.string(),
    publishedAt: z.coerce.date(),
    category: z.string(),
    project: z.string().default('dassist-website'),
    tags: z.array(z.string()).default([]),
    ogImage: z.string().optional(),
    draft: z.boolean().default(false),
  }),
});

draft の記事は一覧、詳細ページ、サイトマップから除外します。本文を別サービスに閉じ込めず、将来Blog Studioから原稿を受け取る場合も同じファイル形式へ着地させます。

ブランド刷新で、きれいにしすぎない

もとのd-assistロゴには、d と a が連続する独特のシルエットがありました。新しいロゴでは緑を #2EAD33 に揃え、最後の + で「アシストに付加価値を加える」という意味を残しました。Webだけでなく、名刺、アイコン、ファビコンでも使えるようにSVG、PNG、PDFなどの用途別アセットを用意しました。

ここでは、ベクター化すれば自動的に品質が上がるわけではないと分かりました。輪郭の角を滑らかにしようとしてパスを描き直したところ、端部は整っても、d と a のつながり方や空白の比率が別のロゴに見える状態になりました。Git履歴には、ロゴを再描画した変更と、その修正を戻した二つのrevertが残っています。

問題はアンチエイリアスではなく、シルエットの不変条件を決めないまま形状を触ったことでした。最終的には、採用済みの輪郭を変えず、表示上のシャギーをSVGで解消する方針へ戻しました。

この経験から、ブランドアセットの修正では次を分けて確認しています。

  1. 元画像の解像度に由来する荒れなのか。
  2. SVG化したパスそのものが元の形を保っているか。
  3. 小サイズで線や空白が潰れないか。
  4. 横組みロゴ、シンボル、ファビコンで同じ印象か。

「丸くする」「滑らかにする」という指示だけでは形状変更の範囲が広すぎます。変えてよい部分と保つべき輪郭を比較画像で確認し、復帰可能なコミットを挟むことが重要でした。

デザインを良くしようとして、一度戻した

最初のサイトを作った後、画像や文字量を増やし、参考サイトに近い編集的な構成へ寄せたv2を試しました。しかし、装飾やセクションが増えたことで、d-assist自身の簡潔さより「参考サイトらしさ」が前に出ました。結果としてv2はrevertし、v1を基準にロゴ、文字サイズ、改行、余白を一つずつ直す方針へ切り替えました。

このrevertは後退ではありません。比較できる実装があったことで、残すべき特徴が明確になりました。

  • 大きな日本語見出しと緑・紺のコントラストは残す。
  • 意味のない強制改行は減らす。
  • 小さな英字ラベルは装飾ではなく、読めるサイズにする。
  • 写真がないことを図形だけで埋めず、情報の密度と余白で見せる。
  • ロゴはヘッダーの高さに押し込まず、本来の縦横比を守る。

特に日本語の改行は、デスクトップで整って見えても320pxでは一文字だけ次行に残ることがあります。見出しの <br> を固定する場所、自然改行へ任せる場所、word-break を使う場所を分け、320、390、768、1440pxで実画面を確認しました。

情報を増やした結果、会社ページと事業ページが重複した

会社としての信頼材料を増やす段階では、サービスの対象者、相談例、支援内容、進め方を詳しくしました。情報不足は改善しましたが、会社ページにも事業ページにも同じ三領域とプロセスが並び、モバイルでは重要情報へ到達するまでの距離が伸びました。

そこで二つのページの責務を再定義しました。

  • 会社ページは、理念、対応領域の要約、検証可能な自社事例、会社概要を扱う。
  • 事業ページは、各サービスの対象、相談例、支援内容、進め方、FAQを扱う。

会社ページのカードからは、事業ページの該当セクションへ通常のアンカーリンクで移動します。JavaScriptのタブや検索機能は追加していません。静的HTMLのまま情報の重複を減らし、会社ページのモバイル全長を約15〜17%短くしました。

<a class="capability-card" href="/service/#ai-integration">
  <h3>AI Integration</h3>
  <p>生成AIを、業務やプロダクトで価値を生む仕組みとして実装します。</p>
  <span>詳しく見る →</span>
</a>

ブラウザでは4画面幅すべてで scrollWidth === clientWidth を確認しました。メインコンテンツ内に12px未満の表示文字がないこと、アンカー移動後の見出しが固定ヘッダーに隠れないことも検査しています。

外部フォントを、今すぐセルフホストしなかった理由

静的サイトなら外部依存をすべてなくすべき、という考え方もあります。今回はDM SansとNoto Sans JPをGoogle Fontsから読み込んでいるため、セルフホストの容量を実測しました。

現在のCSSが参照するWOFF2は126個で、全サブセットの合計は5,277,008バイト、約5.03MiBでした。ただし、通常のブラウザが全ファイルを一括取得するわけではありません。unicode-range によって、ページ内で使われる文字に必要なサブセットだけが選択されます。

同じ挙動をローカルで維持するなら、126ファイルと生成CSSの更新が必要です。日本語フォントを一つの全量ファイルとして置けば構成は簡単になりますが、転送量が増えます。システムフォントへ変えると、ブランドの印象と日本語の改行が変わります。

そのため、今回は display=swap とpreconnectを維持し、セルフホストは見送りました。これは恒久決定ではありません。実アクセスのCore Web Vitalsでフォントがボトルネックになった場合、外部通信を禁止する方針になった場合、または公開記事の文字集合が安定して安全なサブセットを生成できる場合に再評価します。

GitHubのタグを「戻れるデザイン判断」にした

見た目の調整では、最終版だけを残すと、どの変更で印象が崩れたのか分からなくなります。このリニューアルでは、ベースライン、各フェーズ、ペルソナ評価ごとにタグを付けました。

baseline-2026-08-29
checkpoint-phase2-2026-08-29
checkpoint-phase3-2026-08-29
checkpoint-phase4-2026-08-29
evaluation-cycle1-2026-08-29
evaluation-cycle2-2026-08-29

評価は、Webデザイナー、フロントエンドエンジニア、UX・アクセシビリティ担当、Webディレクター・SEO担当、CTOという5人の専門家ペルソナによる認知的ウォークスルーです。実ユーザーインタビューではないため、その違いもレポートに明記しました。

最初の基準点は平均7.0、Phase 1〜4後は8.2、会社・事業ページの重複整理後は8.6でした。各サイクルでは平均だけでなく、前回の各ペルソナ点を一人も下回らないことを回帰ゲートにしています。点数を上げるために新機能を増やすのではなく、確認できない実績や技術情報が必要になった時点で自動改善を止めました。

検証済みのことと、まだ言えないこと

2026年8月29日時点で、次をローカル環境で確認しています。

  • astro check: 13ファイル、エラー0、警告0、ヒント0。
  • astro build: 静的ページの生成に成功。
  • 320、390、768、1440px: 横方向のオーバーフローなし。
  • 記事、canonical、OGP、構造化データ、サイトマップの生成を確認。
  • モバイルナビゲーションのTab、Enter、Escapeとフォーカス移動を確認。
  • ペルソナ評価: 平均8.6、前サイクルからの個別回帰なし。

一方、顧客案件の成果、公開許可を得た導入事例、対応可能な契約規模、セキュリティ認証、運用SLAなどは、このリポジトリだけでは確認できません。会社としての強みを説明するために必要でも、推測で補わず、オーナー確認が取れるまで掲載しません。

また、AWS構成の廃止と本番ドメイン切り替えは、サイト実装とは別の作業です。この記事はローカル実装とGitHub上の変更管理について述べており、本番インフラの削除や移行完了を主張するものではありません。

小さな会社サイトほど、作らないものを決める

今回のリニューアルから持ち帰れる一番大きな知見は、CMSを自作しなかったことでも、Astroを選んだことでもありません。「いま必要な更新責務だけを残し、確認できない価値を機能やコピーで埋めない」という境界を保ったことです。

静的サイトは、動的な機能が少ないだけのサイトではありません。コンテンツの所有場所、レビュー方法、公開条件、復帰点を先に決めれば、小さな構成でも継続的に改善できます。一方で、事実が不足したところまでコードで解決しようとすると、架空の事例、使われない管理画面、過剰な分析機能が増えていきます。

d-assistのサイトは、会社情報をHTMLで、記事をMarkdownで、判断履歴をGitHubで扱います。Blog Studioから複数プロジェクトの記事を受け取る場合も、記事は確認待ちから始まり、公開状態だけがサイトマップへ載ります。この単純な境界を維持しながら、次は実際の事例と技術記事を、確認できた順に積み上げていきます。