－ 迷探偵よたろーの酩酊推理【第2話】
昨夜の推理と、新たな容疑者「AI」
昨夜、焼酎を飲みながら岩井コスモ証券の不正取引事件を推理した。
どうやら犯人は、顧客のパスワードを盗んでログインしたわけではなく、裏側のシステムを直接狙ったらしい。
そこまでは覚えている。
しかし、今日になって証券会社から気になる発表が追加された。
「攻撃者がAIを用いてシステムの脆弱性を突き、総当たり攻撃を仕掛けた」
AIだと！？
最近は何でもAIだ。
文章を書くのもAI。絵を描くのもAI。
そして、システムを攻撃するのもAIか。
だが待てよ。
「総当たり攻撃（ブルートフォース）」と聞いて、私は一瞬「パスワードを1番から順に打ち込みまくったのか？」と思った。
しかし、証券会社は「パスキー認証は突破されていない」と明言している。
ということは、パスワードの総当たりではない。
AIを使って「システムの裏口の穴（脆弱性）」を片端から総当たりで探し出し、そこを突いたということか？
素面の私より、酔っぱらったAIの方が仕事が早いのかもしれない。
おっと、感心している場合ではない。
机の上には、昨夜の私が書いた殴り書きのメモが残っていた。
「トランザクションデータを直接生成？」
うーむ。トランザクションとは何だ？
まず、そこから調べなくてはならない。
株の注文もコンピューターの伝票
昔、会社の経理部門では、売上や仕入れを伝票に記入していた。
取引日、相手先、商品、金額などを記入した伝票である。
今は、そうした情報をコンピューターで管理する。
証券取引でも同じように、誰が、何を、何株、いくらで売買するのかという注文情報が扱われる。
こうした処理を理解するうえで、「トランザクション」という言葉が出てくる。
厳密には、データベースでいうトランザクションとは、複数の処理を一つのまとまりとして確実に実行する仕組みのことだ。
例えば銀行で、AさんからBさんへ1万円を送金する。
Aさんの残高を1万円減らしたのに、Bさんの残高が増えなかったら大事件だ。
だから、両方の処理をまとめて成功させるか、失敗したら双方をもとの状態に戻す。
なるほど。ここまでは理解できた。
そこで迷探偵は、新たな仮説を思いついた。
注文データを直接作ったらどうなる？
普通、株式を売買するときは、顧客が証券会社にログインして注文内容を入力する。
しかし、その裏ではコンピューターが注文を管理している。
仮に、AIが見つけ出した穴を通って、不正な注文データをシステムに直接渡せたらどうだろう。
例えば、顧客が何も指示していないのに、システムの内部に「A社の株を100株買う」という注文が紛れ込んだとする。
その注文が正規のものとして認識されれば、取引所に発注されてしまう可能性がある。
これなら、わざわざ顧客のパスワードを盗む必要はない。
よし。事件の全貌が見えてきた！
……と思ったら、ここで大きな問題にぶつかった。
データベースに注文データを追加しただけでは、必ずしも株式の売買は実行されないのだ。
注文を受け付けたことと、取引所に注文を出すこと、そして実際に売買が成立することは、それぞれ別の処理である。
どうやら、犯人が偽の注文を作ったとしても、それを発注処理まで進める何らかの仕組みが必要らしい。
一気に話が難しくなってきた。
ここで焼酎を追加する。
犯人はAPIを使ったのか？
調べていると、今度は「API」という言葉が出てきた。
APIとは、異なるプログラム同士が決められた方法でやり取りするための仕組みらしい。
レストランに例えるなら、客と厨房の間で注文を取り次ぐ「店員」のようなものだ。
客がカレーを注文する。
店員が厨房に伝える。
厨房がカレーを作る。
実に分かりやすい。
では、犯人が客席に座らず、厨房に向かって直接「カレー100皿！」と叫んだらどうなる？
普通のレストランなら、料理長が怒るだろう。
しかし、コンピューターの中で不正な依頼が正規のものとして扱われれば、処理が進んでしまう場合がある。
これが「APIの認証や権限管理の問題」というものらしい。
まさか、AIを使ってそのAPIのアクセス方法を総当たりで調べ上げたのか？
頭が混乱してきた。
SQLという新たな容疑者
さらに調べると、「SQL」という言葉に行き着いた。
エス・キュー・エル。
データベースの情報を検索したり、追加したり、更新したりするための言語だという。
例えば、データを追加する命令には「INSERT」というものがある。
つまり、プログラムからデータベースに新しい注文レコードを追加することもできる。
ここで迷探偵の頭に電球がともった。
「これだ！」
もし、不正なSQLが実行できる状態（SQLインジェクションなど）だったとしたら？
あるいは、正規の管理機能を悪用して注文を作成できたとしたら？
ところが、ここからさらに話がややこしくなる。
「SQLインジェクション」もあれば、「権限昇格」「認証回避」「業務ロジックの悪用」というものもある。
分からないことが増えるたびに、容疑者が増える。
これは迷探偵にとって、非常に都合が悪い。
推理小説なら、登場人物が増えすぎて読者が名前を覚えられなくなる場面である。
真相は、トランザクションのACID特性に隠されている！
さて、ここからが迷探偵よたろーの本領発揮である。
今回の不正取引は、ひょっとするとトランザクションのACID特性と関係しているのではないか。
ACIDとは、Atomicity（原子性）、Consistency（一貫性）、Isolation（独立性）、Durability（永続性）。
これはデータベース処理の信頼性を保つための基本的な考え方だ。
しかし、ここで問題になるのは、アプリケーション層の認証状態とデータアクセス層の権限境界であり、仮に内部APIが適切な認可チェックを行わず、注文イベントがメッセージキューに投入され、その後のコンシューマーがイベントの真正性を検証しなければ、非同期処理によって注文管理システムから発注ゲートウェイへ不正な命令が伝播し、さらに冪等性制御、コミット処理、ロールバック、監査ログの整合性が……
ん？
ちょっと待て。
私は、いったい何を説明しているのだ？
そうか！
CQRSとイベントソーシングを組み合わせ、さらにゼロトラストアーキテクチャによるサービス間認証を……
いや、違う！
そもそも今回のシステムが、そのような構成だったという情報はどこにもない。
では、認証トークンのスコープとRBACのロール設定が……
待て待て！
RBACとは何だ？
ABACとはどう違う？
JWTの署名検証と注文イベントの真正性は……
ええい！
もう分からん！
読者の皆さん、まだいらっしゃいますか？
……。
もしもし？
ここまで読んでくださっている方はいらっしゃるだろうか。
どうやら、最初に登場した金庫と泥棒の話あたりで、大半の読者は帰宅されたようだ。
APIで半分が脱落。
SQLでさらに半分。
ACID特性で、ほぼ全滅。
そして、最後まで残った読者は……
たぶん、コンピューターの専門家だけだろう。
そんな方には、ぜひ今回の事件の仕組みを私に教えていただきたい。
もちろん、焼酎を飲みながら、分かりやすくお願いしたい。
酔っぱらい探偵の最後の警告
冗談はここまでにして、今回の事件には大切な教訓がある。
ID、パスワード、電話番号認証、パスキー。
こうした本人認証の仕組みは、もちろん大事だ。
しかし、これらが守っているのは、基本的には「本人になりすましてサービスを利用される危険」である。
金融機関の内部システムや注文処理機能そのものが攻撃された場合、顧客側の認証だけでは防ぎきれないことがある。
だからといって、パスキーが無意味になったわけではない。玄関の鍵が役に立たないわけでもない。
問題は、玄関の鍵だけをいくら頑丈にしても、家全体を守れるとは限らないということだ。
今回、岩井コスモ証券は問題箇所を修正し、再発防止策を講じたと発表している。
顧客の負担も生じていない。それは幸いだった。
だがこれからは、証券会社も銀行も、外からの侵入だけでなく、内部で処理される指示そのものが正当かどうかを、さらに厳しく確認する必要があるだろう。
そして私たち利用者も、時々は取引履歴や口座残高を確認しておきたい。
事件解決！……したことにする
さて、迷探偵よたろーの推理も、いよいよ大詰めだ。
犯人は誰なのか。
AIをどうやって使ったのか。
どんな命令で株の売買を成立させたのか。
すべてを解き明かすには、システムの詳細な調査結果が必要である。
しかし、残念ながら私にはそこまでの情報がない。
つまり、結論は……
分からん！
これが、焼酎を二晩にわたって飲み続けた迷探偵の結論である。
でも、一つだけ分かった。
昨夜の私は、「トランザクション」という言葉を覚えた。
今夜の私は、それを説明している途中で、また分からなくなった。
そして明日の朝には、おそらく「SQL」という言葉も「AI」という言葉も忘れているだろう。
事件の真相は、まだ霧の中。
焼酎のグラスも、すでに空。
迷探偵よたろーは、そっとパソコンを閉じた。
――完――
※本記事は、2026年10月21日までの岩井コスモ証券の公表資料を基にした、架空の迷探偵による推理です。実際の攻撃方法を特定するものではありません。記事中のデータベース操作、API、SQLなどの説明は、攻撃の可能性を考えるための一般的な例です。
コメント