制作ノート

サイトを作る側の設計についての記録です。 運営方針に書いた原則を、実際にどうやって維持しているかを扱っています。

「出典を書く」「確認日を添える」と決めるのは簡単ですが、数百ページで守り続けるのは別の話です。 書き忘れが起きない形にしておかないと、少しずつ抜けていきます。 ここに書いているのは、規律を意志ではなく仕組みで保つための工夫と、 その限界についてです。

• 検証に通らなければ、公開できないようにする

  正確さを気合いで保つのは無理です。仕組みで落とすようにした話。

• AIに事実を作らせない、という運用

  これらのサイトはAIを使って作っています。どこまで任せ、どこから任せないかの実際について。

• 静的サイトで出典主義をやるための設計

  出典と確認日をページに出し続けるには、データの持ち方をそれ用にしておく必要があります。

• 「スキップ印」がpush全体を無かったことにする

  コミットメッセージに1つ印を入れただけで、そのpushに含まれる変更がまるごと本番に出ない。エラーも出ません。実測で挙動を確定させた話です。

• ライセンス違反を、ビルドで落とす

  「出典を書く」「使えないライセンスの写真を載せない」を人の注意力で守るのはやめました。データの検査をビルドの通過条件にした話です。

• 課金経路を作らずに、実用的な地図を載せる

  地図APIはキーと課金アカウントが要ります。個人運営で青天井の請求を抱えたくないので、別の方法にしました。

• 検証コマンド自身を疑う

  「確認したので問題ありません」と言うとき、確認の道具が壊れていることがあります。このサイトの制作中に実際に踏んだ3つを書きます。

• iPhoneの写真を、公開できる形に変換する

  定番のライブラリが1枚も開けませんでした。差し替えたうえで、EXIFを捨て、写り込みをぼかすところまでを一本の処理にした話です。

• 縦書きでは、揃える方向が入れ替わる

  背表紙の文字が中央に来ませんでした。原因は、縦書きにしたことで軸の意味が90度回っていたことです。

• 多言語ページで、訳し方より先に決めること

  翻訳の品質を決めるのは訳文の巧さではなく、固有名詞をどう書くかを先に決めてあるかどうかでした。

• 警報コードの一覧は、PDFではなくZIPの中のExcelにあった

  公式が仕様を公開していても、欲しい表がどこにあるかは別問題です。探し当てるまでに踏んだ回り道を書きます。

一次情報源を読む

資料そのものの性質と読み方については一次情報源を読むにまとめています。 暦要項、辞典データの利用条件、気象庁、公的統計、確認日の考え方を資料ごとに扱っています。