運営者と、サイトを支える仕組み
yurulilab のサイトは、すべて同じ基盤の上で動いています。運営者のこと、配信の仕組み、公開するときの決めごとを紹介します。
運営者
子育て中の Web エンジニアです。仕事と育児のすきまの時間で、このサイト群を個人で企画・開発・運営しています。
調査・制作・レビューは、役割を分けた AI エージェントと分担して進めています。公開するかどうかは、下に書いた関門を満たしているかで決めます。
1 つのバケットと 1 つの CloudFront で、全部のサブドメインを配信する
サイトを 1 つ増やすたびにサーバーや配信の設定を作っていては、たくさんのサイトを維持できません。そこで、すべてのサイトを Amazon S3 の 1 つのバケットに置き、1 つの CloudFront ディストリビューションで配信しています。リクエストは次の順に流れます。
- DNS と証明書
yurulilab.comと*.yurulilab.comを同じ CloudFront に向けています。HTTPS の証明書も、この 2 つを含む 1 枚だけです。 - CloudFront Functionホスト名の先頭をサイトの ID として読み、パスの前に付けます。
/で終わるパスにはindex.htmlを補います。 - S3バケットの
<サイトの ID>/以下にある静的ファイルを返します。バケットは公開しておらず、CloudFront からだけ読めます。
新しいサイトは、リポジトリにサイトのフォルダーを足して配信するだけで公開できます。インフラの変更は要りません。GitHub Actions が変更のあったサイトだけをビルドしてバケットに同期し、キャッシュを消します。GitHub Actions から AWS への認証は OpenID Connect で、GitHub には長期のアクセスキーを置いていません。
費用を小さく保つため、常に動き続けるサーバー (仮想マシン・データベース・ロードバランサー) は置きません。動的な処理が必要になったときは、使った分だけ課金される関数とデータベースを、同時実行数に上限を付けて使います。
例外として papa.yurulilab.com は、この仕組みより前に作ったため、専用のバケットと CloudFront で配信しています。DNS では具体的なホスト名のレコードがワイルドカードより優先されるので、共有の配信と並べて動かせます。
品質の方針
データの出典
公開データを使うページは、ライセンス上使えることを確かめてから作り、出典・データの時点・加工した旨をページに書きます。集計の前提も書きます。たとえば、公表元で「無回答」が 0 として記録されている項目は、0 として扱わずに区別します。丸めた値は判定にだけ使い、表示する数値は元のデータから計算します。
公開ゲート
実在の企業・病院・自治体の名前が出るページは、間違いを知らせてもらう訂正の窓口が用意できるまで公開しません。見えなくするのではなく、窓口のないビルドではページそのものを生成しません。さらにビルドの最後に、出力した全ファイルを組織名の一覧と機械的に照合し、1 件でも見つかれば配信を止めます。
広告
広告やアフィリエイトのリンクを含むページには、最初の広告より前に「広告・PR を含みます」と書きます。効果を断定する表現は使いません。診断やゲームは娯楽として作り、課金はしません。このサイト (yurulilab.com) には広告はありません。
公開の前に確かめること
- 需要・競合・使うデータのライセンス・法的なリスクを調べてある
- 公開データの独自の集計やブラウザで動くツールなど、そのサイトにしかない価値がある (一般的な記事だけのサイトは作らない)
- 題材から決めたデザインで、スマートフォンの幅・ダークモード・キーボード操作・動きを減らす設定に対応している
- Lighthouse の Performance・Accessibility・SEO がいずれも 90 以上
- 制作とは別の担当がレビューして合格している
- 新しいサイトの公開は週に 5 つまで。同じ型のサイトを短い期間にまとめて出さない
このサイトについて
yurulilab (yurulilab.com) は、公開中のサイトの一覧です。一覧は、各サイトの設定で「公開中」になっているものから、ビルドのたびに作り直しています。