バラバラに動く4つの観測システムを、壊さずに繋いだ話
- ⏱ 約7分で読めます - 👁 … viewsうちの観測拠点には、いつのまにか4つのシステムが住みついています。地震計のデータからリアルタイムに震度を計算するもの、夜空を見張って流星を自動で見つけるもの、防犯と流星観測を兼ねた24時間録画のカメラ、それに気象観測機。どれも別々のきっかけで作ったり導入したりしたもので、お互いのことは何も知りません。地震が来た夜に空はどんな様子だったのか、流星がよく飛んだ晩の湿度はどうだったのか——そういう「重ねて見れば分かること」が、いまはどこにも繋がっていない。それぞれが自分の画面だけを持って、孤立して動いていました。
前回、ラズパイで自作NVR「Argus」を作った話を書きましたが、あれもこの4つのうちの1台です。録画システムが一段落して、ふと顔を上げたときに、残りの3つがそれぞれ勝手に動いているのが妙に気になりました。同じ拠点で、同じ空を、同じ時間に観測しているのに、データは一度も出会わない。これはもったいない。「いま観測所で何が起きているか」を一枚で見られたら、と思ったのが始まりでした。
既存のシステムには、指一本触れたくなかった
統合と聞くと、4つを作り直して一つの大きなシステムにまとめる、という絵を思い浮かべる人もいるかもしれません。でも私は、最初から逆のことを考えていました。動いているものには、できるだけ触りたくない。
理由は単純で、4つともいまちゃんと仕事をしているからです。地震計のシステムは、気象庁のアルゴリズムに合わせて震度を計算する部分を、公式の観測値と突き合わせて検証してあります。録画システムは本番のラズパイで24時間休まず動いている。流星検出は深夜にひとりで星を数えている。こういう「すでに正しく動いているもの」に手を入れると、たいてい何かが静かに壊れます。しかも壊れたことに、しばらく気づかない。
だから今回の方針は、「統合システムは、4つのデータをただ読ませてもらうだけ」にしました。新しく作るのは読み取り専用の係で、各システムには書き込まない、設定も変えない、計算の中身にも触らない。例えるなら、4つの工房を一つに合併するのではなく、それぞれの工房の前に「今日の様子を教えてくれる窓口」を一つだけ増やして、それを見て回る連絡係を一人雇う、という感じです。窓口を増やすぶんの小さなお願いはしますが、工房の中の仕事は何も変えてもらわない。
この「壊さないことを最優先する」という姿勢は、たぶん私のクセです。新しく華やかな仕組みを足すより、いま動いているものを止めないことのほうを、いつも先に考えてしまう。
繋ごうとして初めて、バラバラさに気づいた
いざ4つのデータを並べようとすると、面白いほど作法が揃っていませんでした。
いちばん手こずったのが時刻です。あるシステムは日本時間の文字列でそのまま記録し、別のシステムはタイムゾーンの情報すら付けずに時刻を書き、録画システムは世界標準時で保存していました。同じ「夜の10時」を指していても、書き方が三者三様。これを揃えずに並べると、後で必ず時間がずれて、地震と流星が実際とは違う順番で並んでしまう。そこで統合システムの中では、入ってきた時刻をすべていったん世界標準時に直し、表示するときだけ日本時間に戻す、と決めました。地味ですが、ここをいい加減にすると全部が狂うので、いちばん最初に固めました。
それから、出どころ。どのデータも、それが「いつ・どのシステムから・どのファイルの何行目から来たのか」を必ず一緒に記録するようにしました。後から「この数字、本当に合ってる?」と疑ったときに、元をたどれないデータは信用できません。一枚にまとめると見栄えは良くなりますが、出どころを捨ててしまうと、ただの綺麗なグラフになってしまう。研究の役に立てたいなら、出どころこそ命です。
「全部残そう」が、いちばん危なかった
設計を詰めるなかで、自分の早とちりに気づかされた場面があります。
地震が検出された前後の録画クリップを、自動でよけて保存しておきたい、と考えていました。録画は古いものから消えていくので、地震があった瞬間の映像は、消える前に退避させないと失われます。最初、私は「地震の検出を取りこぼしたくないから、全部の検出について映像を残そう」としていました。取り逃しゼロ、いいことのように聞こえます。
ところが実際の検出ログを開いてみて、青ざめました。3週間で千件以上ある「地震検出」のうち、本当に地震らしいものはたったの2件。残りの99.86%は、車が通った振動やら設置場所のノイズやらの、ごく微弱な揺れでした。これを全部、前後3分・カメラ4台ぶん映像で残したら、ディスクは初週でパンクします。「取り逃しゼロ」という美しい方針が、そのまま「システム停止」に直結するところでした。
結局、ある程度の強さ以上の揺れだけを残し、古くなったものは段階的に間引いていく仕組みにしました。この一件は、自分への戒めとして覚えておこうと思っています。**理想を言葉にすると気持ちがいいけれど、実際のデータを一度のぞいてみるまでは、その理想が現実的かどうか分からない。**机の上で「全部残す」と書くのは簡単で、ログを開いて数えるのは面倒くさい。でも、面倒なほうを先にやらないと、こういう落とし穴にはまります。
思想を揃えてから、手を動かす
もう一つ、今回こだわったことがあります。新しく作る統合システムを、既存の4つと「同じ人が、同じ考えで書いたように」見せること。
正直に書くと、最近は開発の大半をAIに任せています。手を動かすのが速くて助かるのですが、困ったこともあります。そのときどきで、設計の方針が微妙に変わってしまうのです。同じ「時刻の持ち方」でも、ある日はこう書き、別の日には違う書き方になっている。一つひとつは小さな差ですが、積み重なると、システム全体が「いろんな人が少しずつ書き継いだ建物」みたいに、ちぐはぐになっていきます。
だから今回は、いきなり統合システムを作り始める前に、まずいま動いている4つの機能をあらためて読み直すことから始めました。それぞれが時刻をどう扱い、設定をどう持ち、コメントをどう書いているか。一つずつ確かめていくと、用途は違っても、底のほうに共通する手グセのようなものが見えてきます。その共通項を「これがこの拠点の流儀だ」と一度きちんと言葉にして、固定する。そのうえで、統合システムはその流儀に合わせて書く、と決めてから手を動かしました。
具体的には、新しいからといって流行りの道具を持ち込んだりせず、既存の4つが使っている地味な作法を踏襲する。便利な計算ロジックを他のシステムから借りたいときも、直接繋いで依存させるのではなく、出どころをコメントに書いたうえで自分のところに書き写す。そうすれば、片方が変わってももう片方が巻き添えで壊れることはありません。
要するに、AIに気持ちよく走ってもらうためにこそ、走り出す前にレールを敷いておく、ということなのだと思います。思想がぶれないように先に一本筋を通しておけば、誰が——人であれAIであれ——書き継いでも、全体は一つの作品のままでいられる。コードは結局、後から読む人への手紙のようなものですから、文体だけは揃えておきたいのです。
まだ何も動いていません
正直に書いておくと、ここまでは全部「設計」の話で、統合システムのコードはまだ一行も書いていません。設計図と、画面の見た目の試作と、各システムにお願いするための仕様書だけが揃った段階です。それでも、いきなり作り始めなかったことには満足しています。バラバラさに気づき、99.86%の落とし穴を先に見つけ、壊さない繋ぎ方を決めてから手を動かす。遠回りに見えて、これがいちばん早い。そう思える程度には、過去に何度も急いで失敗してきました。
統合システムは、これも専用のラズパイを一台あてがって、24時間静かに4つのデータを集めさせるつもりです。完成したらまた、この場所で続きを書きます。