はじめに
こんにちは。
GadgetStreemでは現在、ガジェット価格の上昇圧力を一つの数字で確認できる独自指数、
GPI（Gadget Pressure Index／ガジェット価格圧力指数）
を開発しています。
最初の記事では、
「ガジェット価格は予測できるのか？」
という問いから、GPIの基本構想を発表しました。
GPIでは、現時点で次の5項目を組み合わせる予定です。
| 構成要素 | 暫定的な重み |
|---|---|
| ドル円 | 30% |
| DRAM価格 | 25% |
| NAND価格 | 20% |
| GPU需給 | 15% |
| 海上運賃 | 10% |
前回の「GPI開発日誌 Vol.1」では、GitHub、Docker、PostgreSQL、FastAPI、データベースマイグレーションなど、GPIを継続的に開発するための基盤を構築しました。
そして今回から、いよいよ実際の市場データを扱うSprint 2へ進みます。
最初に取り組むデータは、
USD/JPY、つまりドル円です。
なぜ最初のデータが「ドル円」なのか
日本国内で販売されるガジェットの多くは、製造・部品調達・輸送・メーカー間の取引において、米ドルの影響を受けます。
そのため、円安が進めば、
- 海外から輸入する完成品
- 半導体やストレージなどの部品
- 海外メーカー製のPC・スマートフォン
- GPUや周辺機器
などの円換算コストが上昇しやすくなります。
もちろん、
円安になったら、すべての製品がすぐ値上がりする
という単純な関係ではありません。
メーカーの在庫、為替予約、販売戦略、競合状況などによって、実際の価格改定までには時間差があります。
それでもドル円は、日本のガジェット市場全体へ広く影響するため、GPI Ver.0.1では最も大きい『暫定30%』の重みを設定しています。
為替データなら、どれを使っても同じではない
「ドル円を取得するだけなら、為替サイトの数字を使えばよいのでは？」
と思うかもしれません。
しかし、指数として継続利用する場合は、単に画面に表示されている最新価格を保存するだけでは不十分です。
データごとに、
- どの時点のレートなのか
- 買値・売値・仲値のどれなのか
- どの市場を基準にしているのか
- 休日や欠損値をどう扱うのか
- 過去データが訂正される可能性はあるのか
- 商用サイトで継続利用できるのか
が異なるからです。
GPIでは「そのとき見つけた数字」を使うのではなく、
同じ条件で繰り返し取得でき、計算方法を第三者が確認できるデータ
を優先します。
公式データ「Federal Reserve H.10」を採用
USD/JPYの一次データソースとして選定したのが、米国のFederal Reserve Boardが公開している
H.10 Foreign Exchange Rates
です。
H.10では、日本円を
1米ドル当たりの日本円
として掲載しています。
また、日次の二国間為替レートは、原則として前営業週分が毎週月曜日の米国東部時間16時15分に更新されます。
ここで重要なのは、この値がリアルタイムの為替レートでも、一般的な意味での「ニューヨーク終値」でもないことです。
H.10およびFREDの系列では、ニューヨーク市における正午の買いレートを基礎としたデータとして説明されています。
そのため、GadgetStreem Intelligenceでは、このデータを単に
ドル円の終値
とは表記しません。
観測条件を正確に残したうえで、
Federal Reserve H.10によるUSD/JPY日次観測値
として管理します。
なぜリアルタイム為替を使わないのか
GPIは将来的に、Webページへアクセスしたときに最新の状況を確認できるサービスを目指しています。
しかし、
常に最新情報を表示すること
＝すべての構成データを秒単位で更新すること
ではありません。
GPIを構成するDRAM、NAND、物流費などは、必ずしもリアルタイムで更新されるデータではありません。
そのため、初期のGPIでは、
- 公式に公表されている
- 更新時刻と定義が明確
- 過去データを継続して取得できる
- 同じ条件で再計算できる
ことを優先します。
速さよりも、
指数としての再現性と信頼性
を重視する方針です。
Collectorとは何か
今回開発する機能は、
USD/JPY Collector
と呼んでいます。
Collectorとは、外部のデータ提供元から必要なデータを取得し、GadgetStreem Intelligenceのデータベースへ保存するプログラムです。
大まかな流れは次のようになります。
Federal Reserve H.10
↓
USD/JPY Collector
↓
データ形式・単位を検証
↓
重複・欠損・訂正を確認
↓
PostgreSQLへ保存
↓
将来のGPI計算に利用Collectorは、ただ数字をコピーするだけではありません。
保存する前に、
- 日本円の系列であるか
- 1米ドル当たりの円という単位か
- 観測日が正しいか
- 数値として変換できるか
- 欠損値ではないか
- すでに保存済みではないか
を確認します。
同じデータを何度取得しても増殖させない
データ収集を自動化すると、同じ期間を複数回取得することがあります。
そのたびに同じ値が新しいデータとして追加されると、データベース内に重複が発生します。
そこでUSD/JPY Collectorでは、
同じデータを何度実行しても、同じ結果になる
という性質を持たせます。
ソフトウェア開発では、この性質を
冪等性（べきとうせい）
と呼びます。
例えば、同じ日付・同じ値・同じ提供元のデータがすでに存在する場合は、新しく追加せず、
変更なしとして処理します。
将来的に毎週または毎日、自動取得するようになっても、観測値が無制限に重複しない仕組みです。
公式データが訂正された場合はどうする？
データ提供元が、過去の数値を訂正する可能性もあります。
このとき、古い値を無言で上書きしてしまうと、
- 当時どの値を使っていたのか
- なぜGPIの計算結果が変化したのか
- いつ訂正されたのか
が分からなくなります。
そこでGadgetStreem Intelligenceでは、訂正値が見つかった場合、
以前の値を削除せず、新しいRevisionとして保存する
方針を採用します。
例えば、
2026年7月17日
Revision 0：159.50円
後日訂正
Revision 1：159.48円という形です。
現在の計算では最新Revisionを使いながら、過去の値も履歴として残します。
これは、GPIが将来公開されたときに、
なぜこの数字になったのか
を説明できるようにするためです。
データの「出どころ」も保存する
GPIでは、数値だけを保存するのではありません。
観測値と一緒に、
- データ提供元
- 系列名
- 観測日
- 公表日時
- 取得日時
- 単位
- Revision番号
- データ品質の状態
- 取得データを識別するハッシュ値
なども記録します。
これを『データプロベナンス（データの来歴）』と呼びます。
市場データを長期間扱う場合、
数字そのものと同じくらい、その数字がどこから来たのか
が重要です。
システム全体の設計も正式に決定
Sprint 2へ進む前に、GadgetStreem IntelligenceのSystem Architecture v1.0も策定しました。
採用したのは、
モジュラーモノリス＋役割ごとに分かれた実行プロセス
という構成です。
現時点では、一つのリポジトリで管理しながら、
Collector
検証処理
Database
Calculation Engine
API
Dashboardを役割ごとに分離します。
特に重要なルールは次のとおりです。
- Webページへのアクセス時に外部データを取得しない
- Collectorが事前に取得・検証してDBへ保存する
- GPI計算エンジンは外部通信を行わない
- WordPressはPostgreSQLへ直接接続しない
- WordPressやダッシュボードはAPIを通じて値を取得する
- AIがGPIの数値や重みを勝手に変更しない
これにより、最初は小さく開発しつつ、将来のダッシュボードや複数指数にも対応できるようにします。
現在までに完了したこと
今回の開発では、USD/JPY Collectorの実装に入る前に、次の設計を完了しました。
- System Architecture v1.0
- USD/JPY Collector Specification v0.1
- Federal Reserve H.10のData Source Review
- USD/JPYのデータソースを決定するADR
- 欠損値・重複値・訂正値の処理方針
- データ来歴の保存方針
- Unit Test・Integration Testの要件
つまり、
どこから、何を、どのように取得し、どんな条件で保存するのか
を先に固定しました。
その場で動けばよいコードではなく、長期間継続できるCollectorを作るためです。
次のステップ
次は、今回決定した設計に基づいてUSD/JPY Collectorを実装します。
実装予定は次のとおりです。
- Federal Reserve公式データの取得
- XMLまたは公式配布形式の解析
- 日本円系列の抽出
- 欠損値の除外
- PostgreSQLへの保存
- 重複実行の防止
- 訂正値のRevision管理
- CLIからの手動実行
- Unit Test
- PostgreSQL Integration Test
- GitHub Actionsでの自動検証
USD/JPY Collectorが完成すると、GadgetStreem Intelligenceのデータベースへ、初めて本物の市場データが入ります。
その後は、
DRAM
↓
NAND
↓
GPU需給
↓
海上運賃
↓
GPI Calculation Engineという順で、構成要素を追加していく予定です。
まとめ
GPI開発日誌 Vol.1では、システムを動かすための基礎を構築しました。
今回のVol.2では、その基礎の上に、
最初の実データとなるドル円を、どのように取り込むか
を決定しました。
まだGPIの数値は表示されていません。
しかし、
- データの取得元
- 観測値の定義
- 保存方法
- 重複処理
- 訂正履歴
- システム全体の役割分担
まで、一つずつ具体化しています。
GPIは少しずつ、
構想から、実際に動くデータプラットフォームへ
変わり始めました。
次回のVol.3では、USD/JPY Collectorの実装結果と、実際に取得したデータがPostgreSQLへ保存されるまでをご紹介する予定です。
引き続き、GadgetStreem Intelligenceの開発過程を公開していきます。
ぜひ一緒に完成まで見守っていただけるとうれしいです。
※GPIは現在開発中の実験的な市場分析指標です。
個別製品の将来価格、値上げ、値下げ、在庫状況、購入利益を保証するものではありません。
また、投資判断を目的とした金融指標ではありません。
コメント