【ITニュース解説】Not An Insider (Just Lucky)

システムエンジニアの皆さん、今回は「Not An Insider (Just Lucky)」というプロジェクトについて解説する。このプロジェクトは、オンラインの予測市場、つまり将来の出来事を予測して賭けるようなシステムで、インサイダー取引のような不公平な状況を防ぐための仕組みを開発したものだ。

まず「インサイダー取引」とは、まだ一般には公開されていない内部の情報を利用して、自分だけが有利になるような取引をすることだ。これは市場の公平性を損ね、信頼を失わせる大きな問題となる。例えば、ある企業の関係者が、その企業に関する重要な未公開情報を知っていて、その情報に基づいて株を売買するようなケースがこれにあたる。一般的な市場では、インサイダー取引は厳しく規制されており、事後に調査して違反者を取り締まる仕組みがとられている。しかし、このプロジェクトでは、そうした後からの調査ではなく、そもそも取引が成立する「前」に、利益相反（インサイダー取引につながる可能性のある関係）がないかをチェックし、不適切な取引を未然に防ぐプロトタイプシステムを作った。

このシステムが解決しようとした問題は、「取引をしようとしている人が、その取引の結果に影響を与えられる人物である場合、どうすべきか」ということだ。単に「誰が取引しようとしているか」という身元（ID）が分かっても、その人がその取引をして良いかどうかまでは判断できない。例えば、ある大学のスポーツ部に所属する人が、自分の大学が出場する試合の予測市場で取引しようとしている場合、これは利益相反にあたる可能性がある。しかし、同じ人が、全く関係のない別の市場（例えば、国際政治の動向を予測する市場など）で取引することは問題ないはずだ。つまり、特定の利益相反があるからといって、その人のあらゆる取引を全世界的に禁止する必要はない、ということだ。このシステムは、トレーダーの身元と、その市場固有の制限を組み合わせて判断する仕組みを目指した。

具体的に、システムが取引リクエストを受け付けた際に、バックエンド（システムの裏側で動く部分）ではいくつかの重要なチェックが行われる。一つ目は「有効な暗号署名」の確認だ。これは、取引リクエストが本当にその本人によって作成され、途中で改ざんされていないかを電子的に証明するものだ。二つ目は「ノンス」の確認で、これは一度使われたリクエストが再利用される（「リプレイ攻撃」と呼ばれる不正な取引）のを防ぐための仕組みだ。三つ目は「GoDaddy ANS（Agent Name Service）」というサービスを使った身元登録の有効性チェックだ。これはトレーダーが正式に登録されたエージェント（代理人）であることを確認する。さらに、トレーダーの「所属」や「年齢」に関する制限、利用可能な「口座残高」、そして宣言された「重要なイベント（例えば試合開始時間など）」への近接性もチェックされる。特に「重要なイベント」への近接性チェックは、自動的に取引をブロックするのではなく、「レビューが必要な取引」としてフラグを立てることで、柔軟な対応を可能にしている。これらの取引に関する決定とその理由（なぜブロックされたのか、なぜ許可されたのか）は、すべて「ハッシュリンクされた監査証跡」に記録される。これは、取引履歴が改ざんされていないことを保証し、後から誰が見ても「なぜこの取引がこの結果になったのか」を明確に理解できるようにするための重要な機能だ。

このプロトタイプを構築するために、様々な技術が使われている。ユーザーが直接操作する画面（インターフェース）はHTML、CSS、JavaScriptといった基本的なWeb技術で作られており、Next.jsというフレームワークとTypeScriptというプログラミング言語が、バックエンドのAPI（データのやり取りをするための窓口）を動かすのに使われた。データベースにはSupabase PostgreSQLが採用され、トレーダーの身元情報、所属、市場データ、先ほど説明した再実行保護のための記録、そして取引の決定内容などが保存されている。市場の参照データとしてはPolymarketのものが使われたり、デモのためにシミュレートされた市場が用意されたりもした。開発したWebアプリケーションはVercelというサービスを使ってインターネット上に公開され、Vitestというツールで自動テストが行われた。

特に重要な役割を果たしたのが、前述のGoDaddy ANSだ。これはトレーダーの身元を検証し、署名されたリクエストと結びつけるために使われた。トレーダーのブラウザ上で、取引内容（これを「ペイロード」と呼ぶ）に電子署名を行い、バックエンドはその署名を公開鍵を使って検証する。ANSは、その身元が登録されているか、そして公開鍵が一致しているかを確認する。このプロジェクトから得られた重要な教訓の一つは、「身元検証（誰が行動しているかを確認すること）」と「資格チェック（その行動が許可されているかを確認すること）」は別物だということだ。身元が確認できたとしても、その人がその取引をして良いかどうかは、また別の判断が必要になる。現在のシステムでは所属情報は自己申告制だが、将来的には独立した機関からの証明（例えば、雇用主からの証明など）を取り入れることを目指している。

また、このプロジェクトではCapital One Nessieというサービスと連携し、シミュレートされた銀行口座の動きと取引決定がどう連携するかを試した。これにより、単に画面上の残高が変わるだけでなく、実際の資金移動がどう記録されるか、という点を検討できた。しかし、ここでも難しい課題が浮上した。「支払い処理」と「データベースの更新」は、同時に完全に成功するか失敗するかという「アトミックな（不可分な）操作」ではない、という問題だ。もし片方だけが成功し、もう片方が失敗した場合、システムは矛盾した状態に陥ってしまう。これを防ぎ、常にデータの一貫性を保つための「信頼性の高い調整（リコンシリエーション）」の仕組みが必要であることがわかった。これは今後の開発課題の一つだ。

開発期間はハッカソンという短期間だったが、SupabaseやVercelといったツールが、データベース管理やWebアプリの公開を簡単にしてくれたため、開発チームは取引審査やインターフェースの構築に集中できた。しかし、それでも様々な部品を組み合わせる「統合」の段階では、多くの課題があった。チームメンバー間のコミュニケーション、GitHubでの変更管理、データ形式の統一、そして各機能間の連携テストが、コードを書くことと同じくらい重要だと痛感した。

このプロジェクトを通して、いくつかの重要な教訓が得られた。一つ目は、「署名があるからといって、その要求が常に許可されるわけではない」ということだ。正しく署名されたリクエストであっても、そのトレーダーに利益相反があれば、取引はブロックされるべきだ。二つ目は、「監査証跡の安全性には注意が必要だ」ということだ。ハッシュリンクを使うことで、記録が改ざんされていないかを後から検出できるが、データベースそのものを魔法のように変更不可能にするわけではない。システムの信頼性を確保するには、様々な側面からの考慮が必要だ。三つ目は、「デプロイされた環境は、もう一つのテスト環境である」ということだ。開発環境で問題なく動作したとしても、実際に公開された環境では、認証、決済、ユーザー体験など、あらゆる要素が想定通りに機能するかどうか、改めて厳密な検証が必要となる。

このプロジェクトは、インサイダー取引を完全に排除したと主張するものではない。彼らが求めたのは、「市場が、既知の利益相反を取引前にチェックし、その決定の理由を後で誰もが理解できるようにできるか？」という、より限定的で具体的な問いへの答えだった。このアイデアをさらに発展させていくことが、今後の目標だ。この解説が、システムエンジニアを目指す皆さんの学習の一助となれば幸いだ。