Claude Mythosを使っても日本の金融機関は絶対にセキュリティを強化できない

はじめに

先日、Anthropic が日本の金融機関向けに Claude Mythos へのアクセス権を解放することがニュースになりました。
https://ledge.ai/articles/anthropic_mythos_japan_megabanks_financial_cybersecurity

これまで米国の一部企業のみに提供されていたアクセス権を日本の金融機関も手にしたことは、大きな第一歩だと感じます。

これで金融システムすべての脆弱性をスキャンでき、事前に防御策を講じられる。たとえ他国や他組織によって、サイバー攻撃に長けた AI が開発されたとしても大丈夫だ。

……そんな都合のよい話は、さすがにあり得ないと思っています。

私は、日本の金融機関がセキュリティを本当の意味で強化するには、単に強力なツールを導入するだけでは不十分だと考えています。むしろ、組織構造、委託構造、責任分界、予算、説明責任といった、より泥臭い問題に向き合わなければならないはずです。

本記事では、その問題意識を伝えるために、物語形式のフィクションとして一つのシナリオを描きます。

なお、ここで描く内容は筆者自身の実体験ではありません。一般的に語られる金融系システム開発・保守のエピソード、SIer や金融系 SE にまつわる公開情報、また友人・知人から聞いた話などをもとに構成した架空の物語です。登場人物、組織、会話、判断はいずれもフィクションであり、特定の企業・組織・個人を指すものではありません。

また、念のため強調しておきますが、筆者はこの物語に出てくるような判断を肯定しているわけではありません。むしろ、システムに関わる SE は、セキュリティ上のリスクを過小評価せず、委託元・利用者・社会に対してより責任ある行動を取るべきだと考えています。

前提

まず、日本の IT 業界における産業構造を整理しましょう。ここが今回の問題の中核です。

日本では、企業がシステムの開発・保守を別の会社に委託するケースが多くあります。

社内には、IT にまつわる事務手続きや問い合わせ対応を担う情報システム部門を設置し、実際に設計・開発・保守の手を動かす技術者は外部の会社が担う、という構造です。何かトラブルが発生した場合、情報システム部門の担当者が保守を委託している会社に連絡し、対応してもらうという流れです。

正直なところ、そうした構造になること自体は自然な面もあります。

例えば、家を建てようとしたとき、ほとんどの人は自分で建てようとは思いません。普通は住宅メーカーや工務店に発注します。

システムもそれに近いところがあります。社内で何らかの業務をシステム化しようとしても、必要な専門人材を常に社内に抱えているとは限りません。そのため、外部の専門会社に委託することが多いのです。常に高度な専門人材を抱えておくには、当然コストもかかります。

今回の物語は、とある金融機関からインターネットバンキングのシステム保守・運用を受託している会社の課長視点で進みます。

ある日、その会社が Claude Mythos を使って、自社が保守しているシステムの脆弱性スキャンを実施した、という架空のケースを考えます。

課長！1万件ぐらい脆弱性が検出されちゃいました！！

「課長！ 1万件ぐらい脆弱性が検出されちゃいました！！」

ある日、部下が泣きそうな顔をしながら、そんなことを報告してきた。

この部下には、最近話題の Claude Mythos によるシステムの脆弱性スキャンをお願いしていた。月末までに各脆弱性に対する対策方針を整理して報告してもらう想定だったが、想定外に多くの脆弱性が検出されたため、緊急でエスカレーションしてくれたようだ。

「ありがとう。ちなみに、どんな脆弱性が多い？」

「まだしっかり見られていないのですが、サポート切れの OS やソフトウェアを使っていることによる脆弱性がほとんどみたいです！」

「よし、それなら慌てることはないから安心して。」

うちでは、サポート切れの OS やソフトウェアを使っている。これには、やむにやまれぬ事情があるのだ。

OS やソフトウェアは、長くても数年、早ければ半年程度で現行バージョンのサポートが終了することがある。

過去に保守費用の見積もりをしたときには、当然、バージョンを最新に追従する方針で見積もっていた。しかし、その見積もりは高すぎるとして委託元から却下されたのである。

情報システム部門の担当者にはリスクをきちんと説明しておいたのだが、おそらく、それを上層部に十分説明しきれなかったのだろう。

そこで、ソフトウェア更改の頻度を大幅に下げた見積もりを再度提出した。

サポート切れでも許容する理由として、見積書には次のような趣旨のことを記載した。

「脆弱性の多くは、外部から侵入された際に顕在化するものである。しかし、本システムは銀行で共通利用しているネットワーク基盤上に構築されており、ファイアウォール等により厳重に保護されている。そのため、外部からの侵入可能性は限定的であり、サポート切れに起因するセキュリティリスクも限定的とみなす。」

もちろん、これはセキュリティ的には本来かなり危うい整理である。
ただ、元の見積もりでは通らないのだから仕方がない。

「そもそもの見積もりで、サポート切れ運用を前提にしている。だから、それらは対応不要と整理できるね。アプリケーション周りのところだけ対応計画をまとめて、向こう一年ぐらいで対応しよう。」

「ありがとうございます！ それでやってみます。」

1000件まで対応項目を減らせました！

「1000件まで対応項目を減らせました！」

後日、部下から上がってきた脆弱性の調査結果を見ると、全体の 90% はサポート切れに起因するものであるため対応不要、残り 10% は自分たちが実装した部分に起因するものであるため対応要、という整理になっていた。

「1000件か。かなり減ったけど、こんなに対応要にすると、我々の品質が疑われちゃうね。」

「でも、これらは我々の実装箇所が原因なので、対応しなければいけないと思うのですが……。」

「例えば、この脆弱性が顕在化するのって、セキュリティ監視が機能しなかった場合や、内部犯が悪用した場合だったりしないかな。」

「確かにそうですね。」

「うん。潜在的なリスクではあるけど、その境界線は銀行のセキュリティ基盤が担っている。だから、今すぐ我々が対応すべきものではない、という整理にしようか。」

「わかりました！！」

大規模な銀行になればなるほど、セキュリティやネットワークを専門に扱う部署がある。そして、それらの部署が責任を持って共通基盤を管理している。

銀行には無数のシステムが存在する。個別のシステムごとにバラバラのセキュリティ対策をしていては、全体のガバナンスが取れない。そのため、共通のネットワーク基盤やセキュリティ基盤を整備し、各システムはその上に乗る形になっている。

我々のシステムも、そうした部署が用意した基盤の上に乗っている。普段から、システム構成や接続方式について何かと制約を受けているのだから、その分、責任も持ってもらわなければ割に合わない。

「ただ、さすがに何も対応なしというのは違和感があるから、20件ぐらいは対応項目として残しておいてね。」

「承知しました！」

従順で助かる。

その後、部下からは、いい具合に 20件ほど対応項目を残した報告書が出てきた。

部長にも口頭で共有しておいたが、「対応項目は20件ぐらいでした」と伝えると、あとは任せると言って、そそくさと別の打ち合わせに行ってしまった。

自分も特に問題なしとして、銀行への報告に進む承認を下した。

以上の理由から、深刻な脆弱性は見つかりませんでした

「以上の理由から、深刻な脆弱性は見つかりませんでした。」

部下が銀行担当者へ脆弱性スキャンの結果を報告した。

「ありがとうございます。安心しました。一応、何点か質問してもいいでしょうか。」

銀行担当者から質問が飛んでくる。

この方は3年前まで支店勤務だったが、お子さんが生まれたことをきっかけに、全国転勤のない情報システム部門へ異動してきた。当然、IT への理解はまだ深くない。しかし、人当たりが柔らかく、とても仕事がしやすい担当者だ。

「この脆弱性は RHEL の Kernel に関する脆弱性でして……。」

部下が適切に質問をさばいている。

技術的な内容を説明しても、どこまで理解いただけているかは不明だ。何なら、興味があって質問しているのかすら怪しい。何も質問しないと仕事をしている感じが出ないから、質問しているに過ぎないのかもしれない。

「わかりました。ご説明いただきありがとうございます。これで上にも説明してみますね。」

「ありがとうございます。それでは、こちらで失礼します。」

よかった。今回も無事に乗り切れた。

そうやって安堵してオンライン会議を終了しようとすると、銀行担当者が「あの……」と遮ってきた。

「もし、ネットワークやセキュリティ基盤が突破されたら、どうなりますかね。」

痛いところを突いてきた。

少し部下には荷が重いため、自分で答えよう。

「ありがとうございます。その場合には、確かにリスクが顕在化する可能性があります。ただし、そうならないために、専門の部署がネットワークやセキュリティ基盤を管理しています。また、そのリスクまで考慮するとなると、バージョンアップ運用などを見直す必要があり、再見積もりを含む大きな対応が必要になります。」

「そうですよね……。」

ここまで言えば、無事にクロージングできるだろう。

正直、1万件の脆弱性にすべて対応するのは現実的ではない。実質的には不可能だ。

「さらに言うと、もしそこが突破されるようであれば、他のシステムも同様に被害を受ける可能性があります。そのため、我々のシステムだけが特別に責められる、という事態にもならないのではないかと考えておりますが、いかがでしょうか。」

「それもそうですね。すみません、余計なことを聞きました。こちらで大丈夫です。」

最後に部下が打ち合わせを締めて、これにて脆弱性スキャンの一次対応は完了となった。

これから 20件もの脆弱性対応をしなければならない。大変だ。

最後に

上記は、あくまで一つの架空シナリオです。

繰り返しますが、これは筆者自身の経験談ではありません。特定の金融機関、SIer、ベンダー、SE、情報システム部門を指しているわけでもありません。一般的に見聞きする金融系システム開発・保守の構造、SE の現場で語られがちな話、友人・知人から聞いたエピソードなどをもとに、問題提起のために構成したフィクションです。

ただし、完全な荒唐無稽とも言い切れないのではないでしょうか。

強力な AI ツールが導入されれば、これまで見えていなかった脆弱性やリスクが一気に可視化される可能性があります。しかし、可視化されたリスクにどう向き合うかは、結局のところ人間と組織の問題です。

「見つかったけれど、予算がないから対応しない」
「共通基盤が守っているから、自分たちの責任ではない」
「委託元が了承しているから問題ない」
「全件対応は現実的ではないから、報告上うまく整理する」

そうした考え方が積み重なれば、どれほど高性能な AI を導入しても、セキュリティは本質的には強くなりません。

SE は、単に指示された作業をこなすだけの存在ではありません。システムのリスクを理解し、必要な情報を正しく伝え、委託元が適切な判断をできるように支える責任があります。もちろん、すべての問題を現場の SE だけで解決できるわけではありません。それでも、リスクを小さく見せたり、責任の所在を曖昧にしたりするのではなく、誠実に向き合う姿勢が必要だと思います。

AI によって脆弱性が見つかる時代は、同時に、見つかった脆弱性から目をそらせない時代でもあります。

この物語が現実にならないことを、切に願っています。