はじめに
最近、地震が多いと感じることが増えました。しかし、それはあくまで「体感」であり、 実際にどの程度揺れているのかを自分の環境で定量的に知る手段は持っていませんでした。
一方で、ChatGPTの進化が著しいという情報に触れ、 「これを開発パートナーとして使えば、自分でも観測システムが作れるのではないか」 と考えるようになりました。
そこで本プロジェクトでは、ChatGPTを単なる検索代替ではなく、 設計・判断・実装・デバッグを伴走する相手として活用しながら、 地震観測システムの構築と解析プログラムの開発を進めてきました。
システムの全体像
基本的な流れは次の通りです。
- 加速度センサーで地面の揺れを計測する
- マイコンでデータを取得し、PCへ送る
- PC側でリアルタイム表示し、地震を検知する
- イベント前後のデータを保存する
- 保存データを解析し、震度・規模・震源方向・距離を推定する
- まずは観測できるものを作る
- 次に精度を高める
- 最後に解析とUIを強化する
開発の流れ
最初から高性能・高価格の構成を目指すのではなく、まずは地震が観測できる原型を作ることを優先しました。 センサー選定にあたっては、気象庁の観測方法との違いや、 個人開発として実現可能な費用対効果を意識し、 最初の段階では簡易加速度型（ADXL345）を採用しました。 これは、いきなり高価な構成に進むのではなく、 震度2クラスの揺れが見えるかどうかを確かめるためのプロトタイプとして位置付けたものです。
ChatGPTの助けを借りながら、配線、センサーとマイコンの接続、 マイコンとPCをつなぐプログラム、波形表示までを一歩ずつ整備しました。 そして観測されたノイズ波形を見ながら、 このノイズレベルで震度2が判別できるかを検討し、 システム全体の出発点としての妥当性を判断しました。
次の段階では、より精度の高い加速度センサー（ADXL355）へ移行しました。 その背景には、簡易加速度型（ADXL345）の観測システムではセンサー分解能に限界があり、 震度2をよりはっきり観測するには、さらに分解能の高いセンサーが必要だと分かってきたことがあります。
つまり、簡易加速度型（ADXL345）は「見えるかどうかを試す段階」としては有効でしたが、 実際に地震波形をより明瞭に捉え、解析精度を上げるためには、次の段階へ進む必要がありました。 ところが、高性能なセンサーほどノイズの影響が無視できず、 単純な置き換えでは性能を活かせませんでした。ここから、配線・GND・実装方法を含む、 本格的なノイズ対策に取り組むことになります。
PC側ではProcessingを用いて、リアルタイム波形表示、ズーム、スケーリング、検知、保存の仕組みを発展させました。 「止めない観測」と「後から解析できる保存」を両立させることが、この段階の重要テーマでした。
保存したCSVを再解析する仕組みを整え、FFT、速度・変位、主要動の抽出、震源方向・距離推定など、 解析プログラムとしての機能を拡張しました。観測だけでなく、 「どこで何が起きたか」を読み取る段階に踏み込んだフェーズです。
ノイズ対策で直面した現実
より精度の高い加速度センサー（ADXL355）へ移行したことで、避けて通れなかったのがノイズの問題でした。 特に重要だったのがGND配線です。ノイズ対策としては、信号線とGNDをツイストペアにする方法が有効ですが、 それをきれいに半田付けで実現するのは、素人の自分には難しいと判断しました。
無理をして不安定な配線にするよりも、自分でも再現できる方法を探した結果、 たどり着いたのがワイヤーラッピング方式でした。 これにより、半田付けに頼らず、比較的扱いやすい形でツイストペア構成を実現することができました。
理想的な方法をそのまま真似するのではなく、自分の技術で実現できる形に置き換えることも、 個人開発では重要な設計判断だった。
初めて「地震を捉えた」と実感した瞬間
地震波形は見たい。しかし、地震が起きてほしいと思うのはあまりにも不謹慎です。 このプロジェクトには、そうした感情の葛藤が常にありました。
そんな中、たまたま群馬県でM4.2の地震が発生しました。 観測地点では、気象庁発表で震度2。そして自作システムでも、その地震波形を観測することができました。
さらに解析した結果、推定震度も震度2となり、 規模、震源方向、震源距離についても、完全ではないにせよ不正解ではない値を得ることができました。 これは、観測と解析の両方が現実の地震に対して機能した、最初の手応えでした。
JavaFX化への挑戦
観測プログラムと解析プログラムは、当初Processingを中心に発展させてきました。 しかし開発が進むにつれて、複数画面の扱い、設定画面の分離、責務分離、再利用しやすい設計といった面で、 より汎用性の高い構成が必要になってきました。
そこで次の段階として取り組んだのが、JavaFXによる観測システム・解析システムの再構築です。 これは単なる見た目の変更ではなく、 観測、表示、解析、設定変更を整理された形で扱えるシステムへ進化させるための挑戦でした。
ただしこの時点で私は、Java開発経験がないだけでなく、 Visual Studio Codeの存在も使い方も分からない状態でした。 それでもChatGPTの助けを借りながら、開発環境の準備、フォルダ構成、ビルドと実行、 エラー対応、画面設計、クラス分割を一つずつ進めることで、 素人の状態からでもJavaFXによるシステム構築に踏み出すことができました。
ここで重要だったのは、ChatGPTが単にコードを出す存在ではなく、 開発環境そのものの理解と、設計の整理を支える相手として機能したことです。 その結果、Processingで蓄積してきた観測・解析ロジックを、より発展性のある形へ移していく道筋が見えてきました。
なぜChatGPTを使うと開発できたのか
このプロジェクトでChatGPTが本当に役立ったのは、単にコードを自動生成できるからではありません。
一番大きかったのは、チャットを通じて、問題点の確認、判断、実施までの過程で思考の整理がスムーズにできたことです。
個人開発では、何が問題なのかをうまく言語化できなかったり、解決策が一つしか見えなかったり、 方針が定まらずに止まってしまうことがあります。しかし今回は、 問題を言葉にし、複数案を比較し、実装方針を決め、修正していく流れを、対話の中で継続的に回すことができました。
観測プログラム、解析プログラムの双方において、コードの自動生成とデバッグ作業はChatGPTがなければ進まなかった と言ってよいレベルです。特に、JavaやJavaFXの経験がないだけでなく、 Visual Studio Codeの存在も使用法も分からない状態から開発を始められたことは、 この対話型の開発スタイルがあったからこそでした。
問題点の確認
何が詰まっているのかを、チャットを通じて言語化しやすかった。
判断の比較
複数の案を並べて検討し、今の自分に合った方法を選びやすかった。
実施までつなげる
方針だけで終わらず、実装やデバッグまで流れを止めずに進められた。
現在地と今後
現在は、Processingで蓄積した観測・解析ロジックを活かしつつ、 JavaFXによる観測・解析システムへの移行を進めています。
- 解析エンジンと表示ロジックの分離
- CSV読込と再解析機能の強化
- 複数ウィンドウ・設定画面の整備
- 観測系と解析系の責務分離
目標は、単なる試作ではなく、継続運用できる観測・解析システムへ育てていくことです。
まとめ
この開発は、センサーをつなぎ、波形を表示し、保存し、解析し、さらにUIを改善していくという、 ハードウェアとソフトウェアの両方にまたがる長い試行錯誤の積み重ねでした。
その中で強く感じたのは、ChatGPTは単なるコード生成ツールではなく、 個人開発における思考整理と判断支援の相手になり得るということです。
地震を「体感」ではなく「観測」として捉えたい。その思いから始まったこのプロジェクトは、 今ではChatGPTとともに進める開発スタイルそのものを含んだ記録になっています。