--- title: "「おまけ」のはずだった — Discord Botに地震・津波・天体イベントを実装したらロマンが暴走した話" description: "読み上げBotに地震速報・天体・YouTube通知を足したら、震度マップを自前で描き、満月を天文計算し……「おまけ」のはずが作り込みが暴走した記録。専門知識なしで読めます。" url: https://ryuuneko.com/blog/zunda-omake-roman published: 2026-06-16 06:51:38.067845 updated: 2026-06-18 05:27:08.284252 --- Discord読み上げBot「ずんだー」に、本来の仕事とはまったく関係のない機能を立て続けに追加しました。 - 🎬 **金曜ロードショー**の次回放送を教えてくれる - 🌏 **緊急地震速報・地震情報・津波予報**を流す - 🌕 **満月・流星群・日食**などの天体イベントを知らせる - 📺 好きな**YouTubeチャンネルの新着・配信開始**を通知する - 🗾 そして地震が来たら、**震度マップの画像を自動生成して貼る** 読み上げBotなのに、なぜ地震速報? という話なのですが——せっかく作るならと、気づいたら「おまけ」とは思えない作り込みになっていました。この記事は、その**ロマン優先で面倒なことをやった記録**です。専門知識がなくても読めるように書きます。 --- ## そもそも「おまけ機能」とは ずんだーの本業は、Discordのボイスチャットで文字を読み上げることです。ふりがなを振ったり、声を合成したり、そっちが本体。 でも、Botがいつも居るサーバーって、ちょっとした「街の掲示板」みたいな場所なんですよね。だったら「今夜の金ローなに?」とか「地震大丈夫?」みたいな、日常の隙間を埋める機能があってもいいよね——という発想で生まれたのが、これから紹介する一連の機能です。 ### なぜ「おまけ」と呼ぶのか 先に、ひとつ大事なことを。これらを「おまけ」と呼んでいるのには、はっきりした理由があります。**どれも、自分ではコントロールできない“よそ”の情報源に頼っているから**です。 金ローは日本テレビのサイト、地震はよそのAPI、天体は国立天文台、YouTubeはYouTube——どれも、相手の都合でいつ仕様が変わってもおかしくないし、最悪「もう使わせてもらえない」ことだってあり得ます。つまり私たちには、これらの機能が**この先ずっと動き続けることを保証できません**。相手の事情で止まるかもしれないし、こちらの判断でいつか廃止するかもしれない。 だから、読み上げという「本体」と同じ重さでは約束できない。でも、あれば楽しい。**「保証はしないけど、動いている間は全力で良いものにする」**——それが、ここで言う「おまけ」の意味です。気軽に使ってほしいけれど、いつか静かに消えても怒らないでね、というくらいの距離感。 そんな立ち位置のくせに、中身は妙に本気です。順番に見ていきます。 --- ## その1：金曜ロードショー — 「放送がない週」をどう見抜くか いちばんシンプルに見える機能から。`/kinro` と打つと、次の金曜ロードショーの放送内容を教えてくれます。 ``` 🎬今夜の金曜ロードショーは 「天空の城ラピュタ」です！✨ ``` 「公式サイトを見にいって、タイトルを取ってくるだけでしょ?」と思いますよね。だいたい合っています。でも、ひとつ厄介な問題があります。 ### 「放送がない週」がある 金曜ロードショーは、毎週必ず映画をやるわけではありません。特番でお休みの週もあります。公式サイトは、放送がある週のページは存在しますが、**お休みの週のページは存在しない**。 ここで普通にアクセスすると、サイトは「ページがないので別の場所に飛ばします」という応答（HTTPの世界で言う「リダイレクト」）を返してきます。つまり—— - ページが普通に表示された → その週は放送あり - 「別の場所に飛ばすよ」と言われた → その週はお休み この「飛ばすよ」のサインを検知したら、Botは黙って翌週のページを見にいきます。それも無ければさらに翌週……と、**最大20週先まで**探しにいって、最初に見つかった放送日を「次回」として返します。 ``` 🎬今夜の金曜ロードショーはお休みです。😔 次回の金曜ロードショーは 6月27日（金） 「君の名は。」です！✨ ``` ### 「サイトの作りが変わったとき」に気づける設計 もうひとつのこだわり。ページは取れたのに、肝心のタイトルが抜き出せなかった場合です。 これは2パターン考えられます。「本当にデータが空」なのか、「サイトのHTML構造が変わって、こちらの読み取り方が時代遅れになった」のか。後者は放置すると、Botが**何も言わずに壊れ続ける**やつです。地味にいちばん怖い。 なので「200（正常）が返ってきたのに中身が抜けない」場合は、ただの取得失敗とは区別して「構造が変わったかもしれない」という専用の警告を管理者に飛ばすようにしています。サイレント故障を許さない、という方針です（これは後の地震速報でもっと徹底します）。 --- ## その2：緊急地震速報 — 「静かに壊れない」ことに全力を注ぐ `/eew` で、地震・津波の速報を受け取れるようにしました。**非公式**です。気象庁から直接もらっているわけではなく、有志コミュニティが整形して公開しているデータを利用しています。なので本文には必ず「非公式である」という免責を添えます。 数秒おきにデータを見にいって、新しい地震・津波の情報が来たらDiscordに流す。やっていることはシンプルです。が、防災に関わる機能なので、**「壊れていることに気づけない」状態が最悪**という前提で設計しています。 ### 失敗を3種類に区別する 普通のプログラムなら「取得できた / できなかった」の2択で済ませがちです。でもこの機能では、取得結果を3つに分けています。 | 結果 | 意味 | 対応 | |------|------|------| | 成功 | データを取れて、中身も読めた | 通常処理 | | 通信失敗 | ネットが繋がらない等 | 一時的なものとして待つ | | 構造異常 | 応答は来たのに中身が読めない | **データ仕様が変わった疑い → 警告** | 3つめが大事です。「応答は正常（200）なのに、こちらが期待する地震データの形になっていない」——これはデータ提供元の仕様変更を意味することが多く、放置すると地震が来ても無言になります。だから他の失敗とは分けて、はっきり警告を出します。 ### 「同じ地震」を追いかけて、メッセージを編集する 緊急地震速報は、ひとつの地震に対して第1報・第2報……と続報が来ます。これを毎回新しいメッセージとして投稿したら、チャンネルが速報で埋め尽くされて逆に読めません。 そこでBotは「これはさっきと同じ地震だな」と見分けて、**最初のメッセージを上書き編集**していきます。識別の方法は情報の種類で変えています。 - 緊急地震速報 → 地震ごとに振られるイベントIDで同一判定 - 地震情報 → 地震の発生時刻で同一判定 - 津波予報 → 進行中はつねに1つ、解除されるまで同じメッセージを更新 さらに細かい話だと、地震の情報は30分で「もう古い」と捨てるのに対し、**津波だけは3時間**保持します。津波は長く続くので、短い時間で捨てると続報が「別の新しい津波」として二重に流れてしまうからです。こういう、現実の災害の時間スケールに合わせた調整が地味に効きます。 --- ## その3：震度マップの自動生成 — ここが今回いちばんの「ロマン」 ここからが本題です。地震が来たとき、ただ文字で「最大震度5強」と出すだけじゃ味気ない。**日本地図に震度を色分けした画像を、その場で描いて貼りたい**。 気象庁が出すような、あの地図です。あれを、外部のサービスに頼らず、Bot自身が一から描いています。おまけ機能のくせに。 ![地震情報の震度マップ。観測点ごとの震度を色付きの点で打ち、震源に発光する★を重ねた、ずんだー自作の地図](/blog/uploads/zunda-shindo-quake.png) *▲ 実際にずんだーが生成した地震情報の震度マップ。一つひとつの点が地震計で、色が震度。海上の光る★が震源。すべてBotがその場で描いています。* ### 地図を「自前で」描くということ 世の中には地図を表示してくれる便利なサービスがたくさんあります。でも今回は、**日本地図のデータ自体を内部に抱えて、ゼロから絵を組み立てる**方式にしました。理由はシンプルで、外部サービスに依存すると、そこが落ちたら震度マップも出なくなるから。防災機能が外部都合で死ぬのは避けたい。 そのために用意したデータが3種類あります。 | データ | 中身 | 用途 | |--------|------|------| | 観測点リスト | 全国の地震計の位置（緯度・経度） | 観測点ごとに震度を点で打つ | | 都道府県の形 | 47都道府県の輪郭線 | 県を色で塗る | | 津波予報区の海岸線 | 海岸の区域ごとの線 | 津波警報を海岸沿いに色付け | これらは、気象庁や公開データから元データを取ってきて、**ビルド時にBot本体へ焼き込んで**います。実行中にダウンロードしたりしません。最初から体の中に地図を持っている状態です。 ### 緯度・経度を、画像のピクセルに変換する 地図データは「北緯35度、東経139度」みたいな座標で持っています。これを画像の「左から何ピクセル、上から何ピクセル」に変換しないと絵になりません。 ここで素朴にやると、日本地図が**横に間延び**します。地球は丸いので、緯度が高い（北にいく）ほど、経度1度あたりの実際の距離は縮むからです。日本くらいの緯度だと、経度方向はだいたい0.8倍くらいに圧縮しないと正しい形になりません。 なので、**緯度に応じて経度方向を縮める簡易的な地図投影**（地球の丸みをざっくり補正するやり方）をかけています。さらに、地震が起きた地域に自動でズームインして、余白をいい感じに取って……と、「ただ点を打つ」だけのはずが、気づけば地図投影の実装をしていました。 ### 県の輪郭線を「軽くする」 都道府県の輪郭線、正確なデータはものすごく細かくて、海岸線なんかは点が数百万個あったりします。そのまま抱えるとBotが重くなる。 でも、Discordに貼る小さな画像なら、そんな精度はいりません。そこで「**ほぼ直線な部分は、間の点を間引いても見た目が変わらない**」という考え方（専門的にはダグラス・ポーカー法という古典的なアルゴリズム）で、形をほとんど崩さずに点の数を大幅に減らしています。津波の海岸線にいたっては、数百万点を一気に削ぎ落としています。「見た目が同じなら軽いほうがいい」を徹底した結果です。 ### 3種類の地図を、状況で描き分ける 情報の種類によって、地図の描き方を自動で変えています。 - **地震情報**（揺れた後） → 観測点ごとの実測震度を、色のついた点で打つ。震源には★マーク。 - **緊急地震速報**（揺れる前の予想） → まだ観測値がないので、予想震度で都道府県をまるごと塗る。 - **津波予報** → 海岸線を、警報の強さ（大津波警報・警報・注意報）で色分け。 ![緊急地震速報の震度マップ。揺れる前なので観測点の点ではなく、予想震度で九州の各県をまるごと塗り分けている](/blog/uploads/zunda-shindo-eew.png) *▲ 緊急地震速報のとき。まだ揺れていない＝観測値がないので、点ではなく「予想震度で県を塗る」表現に自動で切り替わります。* そして、**地震が続いている最中に津波警報が出た**ら——震度の点と津波の海岸線を1枚に重ねた「合成版」を描きます。凡例（色の説明）も2段組みに切り替わる。ここまで来ると完全に趣味です。 ![地震と津波の複合震度マップ。県の震度塗りに加え、太平洋側の海岸線が大津波警報＝紫、津波警報＝赤、注意報＝黄で色分けされている](/blog/uploads/zunda-shindo-composite.png) *▲ 地震＋津波の「合成版」。県の塗り（震度）と、海岸線の色（紫＝大津波警報／赤＝津波警報／黄＝注意報）が1枚に同居します。ここまでやる必要はない、でもやりたかった。* ### 細かすぎるこだわり 仕上げの部分にも、誰も気づかないであろう手間がかかっています。 - **震源の★に「グロー」（発光）をかける** — 中心から外側へ淡くにじむ光彩。一目で震源がわかるように。 - **津波の海岸線は二重線** — 細い色の線の下に、太い白い線を敷く。こうすると地図の上で線がくっきり浮き上がって、震度の点と混ざらない。 - **日本語フォントを丸ごと同梱** — 画像に「最大震度5強」みたいな日本語を焼き込むため、Noto Sans CJKという日本語フォント（数MBある）をコンテナに積んでいます。これが無いと文字が豆腐（□□□）になる。 おまけ機能のために、わざわざフォントを積む。そういう作業の積み重ねです。 --- ## その4：天体イベント — 満月の日付から「見え方」まで `/astro` で、満月・新月・流星群・日食・月食などの天体イベントを知らせます。 「満月の日なんてカレンダー見ればいいじゃん」と思うでしょう。私もそう思っていました。でも、**満月が何月何日かをプログラムに計算させようとすると、これがまた沼**なんです。 ![満月の通知カード。「満月（フラワームーン）5月20日」と書かれ、月のアイコンと説明文が添えられている](/blog/uploads/zunda-astro-fullmoon.webp) *▲ 満月の通知カード。日付も「フラワームーン」などの呼び名も、すべて計算と内蔵データから組み立てています。* ### 満月の日付は「天文計算」しないと出ない 満月や新月の正確な日時は、単純な周期計算では出ません。月の公転は微妙にゆらいでいて、ちゃんと出すには天文学の計算式が必要です。 そこで、天文計算の世界で有名なミーウス（Jean Meeus）という人の本に載っている公式を、そのまま実装しました。太陽と月の位置関係を表す角度をいくつも計算して、補正項を何十個も足し込んで……という、なかなかゴツい計算です。結果として、**検証した範囲では、国立天文台が公表している満月・新月の時刻と分単位で一致**します（誤差は数分以内）。日付を出すだけなら完全にオーバースペックですが、ロマンなので。 ### ついでに「ブルームーン」と「スーパームーン」も判定 せっかく月の計算をしているので、おまけのおまけで遊びました。 - **ブルームーン**（同じ月に満月が2回来るレアな現象） → その月の頭から全部の日をチェックして、すでに満月があったかを確認して判定。「31日が満月ならブルームーン」みたいな雑な判定だと、月初に1回目が来るパターンを取りこぼすので、ちゃんと全日走査しています。 - **スーパームーン**（月が地球に近づいて大きく見える満月） → 月と地球の距離を計算して、一定より近ければスーパームーン認定。厳密な定義がない言葉なので、その年に「スーパームーンだ」と話題になる満月と一致するように、距離のしきい値を調整しました。 ### 流星群や日食は、自動で取り込む 満月・新月は計算で出せますが、流星群の極大日や日食・月食は、毎年日付が変わるので計算では出しづらい。これらは国立天文台の「ほしぞら情報」というページを**毎日自動で読みにいって**、Botのデータベースに取り込んでいます。 ここでも細かいルールを入れています。 - **「日本では見られない」日食は取り込まない** — 見えないものを通知しても意味がないので。 - **二十四節気や祝日は無視** — 「天体イベント」として面白いものだけ選ぶ。 - **その年だけの正確な日付を、毎年の概算より優先する** — たとえば流星群は「毎年だいたい8月13日ごろ」という情報と、「今年は8月12日が極大」という年指定の情報の両方があり得ます。年指定があればそちらを優先します。 そして、取り込みに失敗しても**計算で出せる満月・新月の通知は止まりません**。外部サイトが落ちても、内部で計算できる分は動き続ける。「一部が壊れても全部は止めない」設計です。 ![ペルセウス座流星群の通知カード。放射点を地平線つきの概略図に示し、方角ラベルを色分け、高さの目盛りと見頃時刻・月明かりの条件を添えている](/blog/uploads/zunda-astro-meteor-v3.webp) *▲ 流星群にいたっては、放射点（流れ星が飛び出してくる方向）を示す簡単な星図まで描いています。方角は色分け、高さの目盛りつき。月明かりの条件まで添える凝りよう。完全におまけのおまけ。* ### 「いつ・どの方角に見えるか」まで計算する 放射点の星図を描いていたら、欲が出ました。「方角が分かるなら、惑星の接近や月の位置も同じ図で見せられるはず」と。 そこで、天体の位置を**その時刻・その場所から見上げたときの「方角と高さ」**に変換する計算を入れました。さらに夜のあいだ何度も時刻をためして、「空が十分暗くて、対象が地平線からしっかり上がっている」いちばん見やすい時間帯を選びます。おかげでカードに「今夜20時ごろ・西北西の低い空」といった**具体的な見え方**が出るようになりました。方角は16方位、高さは「低い／中ほど／高い」の3段階に丸めています。「方位278度・高度12度」と数字で言われても、空を見上げる役には立たないので。 ### 同じ見え方なら、1枚にまとめる ここで沼にはまりました。「日本のどこから見るか」です。北海道と沖縄では、同じ星でも見える方角・高さが少しずれます。律儀に47都道府県ぶん描いてみたら——**ほとんど同じ絵が47枚**できあがりました。地味に違うけど、ほぼ一緒。これは無駄です。 そこで各県の見え方を「16方位＋高さの段階」で**ひとつの符号**にして、同じ符号どうしをまとめました。全国でほぼ同じなら**共通の1枚**、見え方が変わるイベントだけ**観測地点を選べる**ようにし、その時間に**地平線の下で見えない地点は、正直に「見えません」と出す**。見えないのに無理やり図を描くより、見えないと言うほうが親切です。 ![惑星接近の見え方カード。方角を色分けした地平線つきの図に、金星と木星が並んでいる](/blog/uploads/zunda-astro-mikae.webp) *▲ 見え方カード。方角を色で分け、地平線や「↑見上げる」といった目印を添えました（このカードはちょうど月が地平線の下なので描かれていません。月が空に出ていれば、本体でなくても淡い目印としてそっと置きます）。* ### 月は、その日の満ち欠けで描く 月が絡むイベントでは、月を**その日の月齢どおり**（三日月なら三日月、満月なら満月）に描きます。さらに、月が主役でないイベント（惑星の接近や流星群）でも、**月が空に出ていれば淡く「目印」として**そっと添えました。「あの月の少し右」と言えるだけで、ぐっと探しやすくなるからです。月が地平線の下なら、邪魔なので描きません。 *（この見え方まわりは比較的新しいバージョンの作り込みで、初期は満月・新月の情報カードだけでした。計算の中身は、別の記事にくわしく書くつもりです。）* --- ## その5：YouTube新作通知 — 「見にいく」のをやめて「待ち受ける」 *（この機能は少し前のバージョンの仕組みです。現在は細部が変わっています）* `/yt` で、好きなYouTubeチャンネルの新着動画や配信開始をDiscordに通知できます。 ここまでの金ローや地震は、すべて「**こちらから定期的に見にいく**」方式でした。でもYouTube通知は発想が逆で、**YouTube側から「動画が出ましたよ」と教えてもらう**仕組みを使っています。 ### 「更新したら教えて」を予約しておく YouTubeは WebSub（旧称 PubSubHubbub）という仕組みを公開しています。ざっくり言うと「このチャンネルが更新されたら、私のサーバーに連絡してね」という**予約**を入れておける仕組みです。新着が出ると、YouTube側（正確には間に立つ“ハブ”）が、こちらのサーバーにデータを送りつけてくれます。 うれしいのは、毎分YouTubeに「まだ?まだ?」と問い合わせなくていいこと。無駄なアクセスをかけずに、しかも新着をほぼリアルタイムで拾えます。礼儀正しくて効率的。 ただ、この「予約」がまた一筋縄ではいきません。 - **合言葉の確認** — 予約するとYouTube側から「本当にお前が予約したのか?」と確認の問い合わせが来るので、正しく合言葉を返す必要がある。 - **有効期限がある** — 予約は数日〜10日ほどで切れるので、切れる前に**こまめに更新し続ける**。 - **なりすまし対策** — 届いた通知が本物のYouTube由来か、署名で毎回チェックする。 ### 困りごと①：通知に「種類」が書いていない 届く通知には、それが**通常動画なのか・配信予定なのか・今まさに配信中なのか**が書かれていません。でも通知文は「🔴ライブ開始!」と「新着動画」で変えたい。 仕方ないので、その動画のページを実際に見にいって、HTMLの中身から種類を判定しています。ここでもやっぱりスクレイピング。 ### 困りごと②：同じ動画が何度も届く 配信は「枠を作る → 配信開始 → タイトル編集」と状態が変わるたびに通知が飛んできます。さらにハブは念のため同じ通知を再送もする。素直に流すと「同じ配信で通知が何回も」になってしまう。 そこで「**（動画ID, 状態）の組**」で見たことがあるか記録して、ただの再送や編集はスキップ、でも「**配信予定 → 配信開始**」という意味のある変化はちゃんと拾う、という細かい仕分けをしています。さらに、終わったライブ配信が後から「新着動画」として二重通知されないようにもしている。地味だけど、これが無いと通知が騒がしくて使い物になりません。 ### 専用の「受付係」を立てる WebSubの受け口は、bot本体とは別の小さなRust製サーバー（中継係）が担当しています。受け取った通知を、内部の即時通信路でbotに流す。こうしておくと、複数のbotが同じチャンネルを見たくても、**YouTubeへの予約は1回で済む**（みんなで1つの予約を共有する）。 待ち受け型、署名チェック、期限の自動更新、状態の仕分け……「動画が出たら教える」というだけの機能に、これだけの裏方がいます。おまけなのに。 --- ## 全部に共通する「裏方の哲学」 ここまでバラバラの機能を紹介してきましたが、実は全部、同じ思想で作っています。 ### 「取りにいく係」と「しゃべる係」を分ける 外部サイトを見にいったり、データを溜めたりする面倒な仕事は、すべて裏方の常駐プログラム（スケジューラー）に集約しています。一方、ユーザーがコマンドを打ったときに反応するBot本体は、**裏方が用意しておいた結果を読むだけ**。 こうすると何が嬉しいか。 - ユーザーが `/kinro` を打った瞬間にサイトを見にいかないので、**返事が速い**。 - Bot本体を再起動しても、データ収集は止まらない。 - 外部サイトの仕様変更で直すべき場所が、裏方に閉じる。 ### プライバシーは「データベースを覗かれても漏れない」 地震速報は「自分の地域だけ受け取る」設定ができます。この**地域情報は暗号化して保存**しています。つまり、データベースのダンプを見ても、管理画面を開いても、SQLを叩いても、誰がどの地域に住んでいるかは分かりません。鍵は別管理。おまけ機能とはいえ、住んでいる地域は立派な個人情報なので、ここはきっちりやっています。 ### テストで「壊れる変更」を捕まえる これらの判定ロジック——震度のしきい値、満月の計算、放送の有無——は、すべて自動テストで守っています。さらに「テストにわざとバグを仕込んでみて、ちゃんとテストが失敗するか」まで確認する手法（ミューテーションテスト）で、テスト自体がザルになっていないかを点検しています。「テストが緑だから安心」ではなく「テストが本当に異常を検知できるか」を測る、というスタンスです。 ### よそのサイトには、礼儀正しく 地震・天体・金ローのデータは、よそのサイトやサービスから頂いています。だからこそ、相手に迷惑をかけないことを大前提にしています。 - **地震データは、公式に公開されている開発者向けAPIを使う** — 勝手に覗いているのではなく、提供者が「使っていいよ」と用意してくれている窓口です。決められたアクセス回数の上限に対して、実際の利用は8分の1以下に抑えています。 - **金ローと天体カレンダーは1日1回だけ取りにいく** — 毎秒張り付くようなことはせず、1日1回そっと確認するだけ。相手のサーバーに負荷をかけません。 - **国立天文台のデータには「提供：国立天文台」と出典を明記する** — 使わせてもらっているものへの最低限の礼儀です。 - **「どこの誰か」を正直に名乗る** — アクセスするとき、自分が何者で連絡先はどこかを名乗るようにしました。これなら、もし先方が「このアクセスは止めてほしい」と思ったとき、すぐに連絡・対処してもらえます。 便利な機能を作ることと、データの提供元に敬意を払うことは両立できます。むしろ、長く続けたいなら後者こそ大事だと思っています。 --- ## なぜ「おまけ」にここまでやるのか 正直に言うと、ここまでの作り込みは、機能の重要度から考えれば**完全に過剰**です。金ローの次回放送を知るだけなら、もっと雑でいい。満月の日付なんてカレンダーを見ればいい。 でも、 - 地図投影を実装して日本列島を正しい形で描いて、 - ミーウスの公式で満月を数分の誤差で当てて、 - サイトの構造変更を「静かに壊れる前」に検知して、 こういうのって、**作っていて単純に楽しい**んですよね。実用性とは別の軸で「やってみたかった」が原動力になっている。趣味で作っているからこそ許される贅沢だと思っています。 「おまけ機能のくせに、なんでこんなに作り込んでるの?」——その問いへの答えは、たぶん「おまけだからこそ、好きにやれた」です。実装にロマンを乗せられるのは、趣味のプロジェクトの最高の特権だと思います。 そして最初に書いたとおり、これらは**いつか消えるかもしれない機能**です。よその情報源に頼っている以上、提供を保証はできないし、こちらの気まぐれで畳むこともある。でも、だからといって手を抜く理由にはなりません。むしろ「いつ終わってもいいように、動いている今を全力で良いものにする」——儚さとロマンは、案外相性がいいのです。 --- ずんだーはDiscordで実際に動いています。地震が来たら、この自前の震度マップがしれっと貼られます。見かけたら「これ全部自前で描いてるんだな」と思い出してもらえたら嬉しいです。……まあ、いつか無くなっているかもしれませんが。それも含めて、おまけということで。 --- *※この記事は2026年6月時点の実装をもとにしています。「おまけ」なので、細部は予告なく変わっている可能性があります（実際、この記事を書いた直後から、天体イベントの日食計算を自前ライブラリ化し始めました。ロマンの暴走に終わりはないようです）。*