サイト構成を技術者ファーストに

継続しやすい環境づくりをしたかった

このサイトをつくるとき、見た目と同じくらい大切にしたかったのが「技術者自身が無理なく更新できること」でした。

発信を外注したり、CMSでログインして決まった入力欄を埋めたりする方法もあります。ただ、画面を切り替えて、入力して、確認して、、、ってやることが多ければ多いほど、記事を書くこと自体が億劫になりやすいと感じています。

そこでこのサイトでは、記事をMarkdownで管理しています。普段コードを書くのと近い流れで、見出し・文章・リンク・画像をひとつのファイルに書く。Pull Requestで内容を確認し、公開する。この距離感を大切にしました。

記事は articlesディレクトリ にMarkdownファイルを置いて管理します。タイトル、概要、公開日、タグ、下書きかどうかは、ファイル冒頭のフロントマターにまとめています。

---
title: "記事のタイトル"
description: "一覧や検索結果に表示する概要"
publishedAt: 2026-08-17T00:00:00+09:00
draft: true
tags:
  - Astro
  - Web制作
---

draft: true の間はサイトに表示されません。内容を確認したら false に変えるだけです。URLはファイル名から決まり、一覧、タグ別ページ、サイトマップにも同じ情報が使われます。

CMSの操作を覚える必要はありません。エディタで書き、Gitで差分を見て、必要なら画像も一緒に管理する。技術者にとって自然な執筆環境を、サイト側に寄せました。

記事はこのサイトだけで閉じるものではありません。技術者が記事を届ける場所としてQiitaやZennも大切です。

そのため、投稿用のMarkdownをローカルのBunコマンドから扱える形にしています。自社サイト向けのフロントマターを整理しながら、QiitaやZennで必要な形式へ変換・投稿できる入口を用意する方針です。

一つの記事を複数の場所に出すために、最初から同じ文章を何度も貼り付ける必要はありません。まずはGitで管理するMarkdownを正本にし、公開先ごとの差分だけを小さく吸収する。発信の負担を増やさず、届け先を増やせる構成を目指しています。

インフラも、今の規模に合わせて選びました。小さく始める会社にとって、最初からAWSのサービスを組み合わせて運用することが正解とは限りません。

このサイトはAstroで静的なHTMLを生成し、Cloudflare Pagesで配信しています。トップ、事業、プロダクト、会社情報、コラムといった多くのページは、配信時にサーバー処理を必要としません。表示が速く、構成もシンプルで、保守する場所を増やさずに済みます。

動的な処理が必要なのは、主にお問い合わせです。ここだけをCloudflare Workers／Pages Functionsに寄せ、Turnstileによるボット対策とメール送信を組み合わせます。

静的に配信できるものは静的に。動的な処理は必要な場所だけに。費用も運用負荷も、最初から大きくしないための選択です。

見た目にも、このサイトの構成をそのまま反映しています。

トップページでは、左側にある円弧状のナビゲーションを縦スクロールに合わせて動かし、右側のコンテンツを横方向へ切り替えています。いまどこを見ているのか、次に何があるのかを、一般的な縦長のページとは少し違う形で伝えるためです。

派手な演出を増やすのではなく、動きには役割を持たせました。ページ遷移、セクション移動、原子モデルの小さなアニメーションも、情報の流れを邪魔しない強さに留めています。動きを減らしたい環境では、OSやブラウザの設定を尊重します。

そして、最初に見せる導線は「まずは相談する」です。コラムを読んでもらうことも大切ですが、相談したい人が迷わず次へ進めることを優先しました。

サイトは公開した日が完成ではありません。記事を書き、改善点を見つけ、必要になったときだけ仕組みを足していくものです。

Markdownで書けること。Gitで確認できること。Cloudflareで小さく運用できること。自社サイトを起点に、QiitaやZennにも広げられること。

この構成は、技術者が発信を続けるための土台です。これから実装したこと、試したこと、うまくいかなかったことも、この土台の上に積み重ねていきます。