ガジェットの情報を追っていると、ある問題に気付きます。
情報がないのではなく、情報が多すぎる。
Apple、Sony、NVIDIAをはじめとするメーカーは、それぞれNewsroomや公式サイトで情報を発信しています。
そこにニュースサイト、SNS、動画、コミュニティなどが加われば、1日に確認しなければならない情報量はかなりのものになります。
新製品が発表された。新しいドライバが公開された。価格が変わった。ある製品について急にニュースが増え始めた。
重要な情報が出ていても、ほかの大量の情報に埋もれてしまうことがあります。
そこでGadgetStreemでは、新しい仕組みを作ることにしました。
その名前が、GSR — GadgetStreem Radarです。
GSRは「ニュースサイト」ではない
最初に決めたことがあります。
GSRを、単純なニュース収集ツールにはしないことです。
RSSを集めて一覧にするだけなら、すでに多くのサービスがあります。
GadgetStreemが作りたいのは、「今、何を見るべきなのか」を探すためのRadarです。
例えば将来的には、メーカーや製品を軸に、直近1時間、24時間、1週間、1か月といった時間単位で情報を探し、その中から注目すべき動きを確認できる仕組みを想定しています。
「Appleのニュースを全部読む」のではなく、「この24時間でAppleに何が起きているのかを見る」そんな使い方を目指しています。
なぜGadgetStreemが作るのか
GadgetStreemでは、もう一つ「GPI（Gadget Pressure Index）」という仕組みを開発しています。
GPIが見ようとしているのは、価格です。
為替、DRAM、NAND、GPU、物流などを観測し、PCやガジェットの価格にどの程度の上昇・下落圧力がかかっているかを捉えようとしています。
一方で、価格だけでは市場のすべてを説明できません。
新製品発表、供給問題、企業の方針変更、新しい規格、ソフトウェアアップデート。こうした出来事も、購入判断に大きく影響します。
そこで、価格を見るGPIと、情報の動きを見るGSRという2つの仕組みを作ることにしました。
最初から「AIに全部任せる」ことはしなかった
GSRという構想を考えたとき、「ニュースをAIに集めさせて、重要そうなものを10件選ばせれば完成する」という作り方もできます。
しかし、この方法は採用しませんでした。
理由は単純です。
重要そうに見えることと、信頼できることは別だからです。
どこから取得した情報なのか。同じニュースを何度も数えていないか。取得できなかったサイトはどう扱うのか。情報源を変更した場合、その結果を同じものとして比較してよいのか。商用サービスとして利用できる情報なのか。
こうした問題を解決しないままランキングだけを作っても、見た目は便利でも、その結果を信用することはできません。
そのためGSRでは、「まず情報を集める」のではなく、「情報を扱うルールを作る」ところから開発を始めました。
そして、最初の壁にぶつかる
最初の検証では、メーカーの公式情報を中心に観測する仕組みを作りました。
ここで、GSR開発にとって重要な出来事が起こります。
あるメーカーからは正常に情報を取得できる。しかし、別のメーカーからは取得できない。
「全部取れる前提」で作っていたら、ここで無理やり別の方法を使うことになっていたかもしれません。
GSRではそうしませんでした。
取得できない情報源は、取得できないまま明示的に隔離する。正常に取得できている情報と混ぜない。
この判断が、その後のGSRの設計に大きな影響を与えることになります。
GSR開発で重視していること
情報源を追跡できること
結果だけではなく、「その情報がどこから来たのか」を追跡できる状態を維持します。
取得できないものを無理に取得しないこと
取得制限や利用条件がある場合、それを回避してまで収集することはしません。使える情報源と使えない情報源を区別します。
自動化より先に信頼性を作ること
ランキング、自動更新、AIによる分析などは便利です。
しかし、その前に入力されるデータと処理のルールが安定している必要があります。
GSRでは、自動化できるかではなく、自動化してよい状態かを確認してから次へ進みます。
GSRはまだ開発途中
この記事を書いている現在、GSRは一般向けの完成サービスとして公開されているわけではありません。
データ取得、情報源の扱い、重複判定、観測履歴、公開前の安全性などを一つずつ検証しながら開発しています。
実際、この過程では、「正常に取得できない情報源」「十分な観測期間を満たすまで待つ必要」「技術的には取得できても商用利用条件を再検討すべき情報源」など、当初想定していなかった問題も出てきました。
しかし、これらはGSRを作るうえで避けて通れない問題でもあります。
この開発記では、それらを成功した部分だけではなく、失敗や方針変更も含めて紹介していきます。
次回：GSRの土台を作る
次回は、「ニュース検索だけでは足りない。GSRのデータ基盤を作る」をテーマにします。
メーカー情報の管理、情報取得の仕組み、データモデル、重複を判定する仕組み、観測結果を残す仕組みなど、GSRが現在の形になる前にどのような土台を作ったのかを紹介します。
コメント