日本がソースを外に出さないのは、遅れているからではない

AIによる脆弱性診断が、急速に現実のものになりつつある。攻撃側がAIで攻撃を自動化・大規模化する一方、防御側もAIで脆弱性を洗い出す。その象徴的な動きが、2026年6月に発表されたソフトバンクとOpenAIによる脆弱性診断サービスだ。ソフトバンクは自社システムを対象にした検証で、1万件を超える脆弱性を検出したと報じられている。AIが脆弱性を見つける力そのものは、もはや疑う段階ではない。

ただ、この記事はそのサービスの良し悪しを論じるものではない。問いたいのはもっと手前にある一つの行為だ。ソースコードを、クラウド上の巨大なLLMに読ませる。これが何を意味するのか。

これは、日本のセキュリティ文化と真逆である

筆者の経験では、日本企業の多くはソースコードを外に出すことに極端に慎重だ。社外はもちろん、社内ですらGitに上げない組織も珍しくない。海外と比べて、この傾向は明らかに強い。

この姿勢は長く「閉鎖的」「遅れている」と評されてきた。コードは共有してこそ品質が上がる、隠すのは前時代的だ、と。AIに全ソースを読ませて脆弱性を洗い出す流れは、まさにこの文化の正反対を行く。

しかし、本当にそうだろうか。

出さない文化は、情報の非対称を守っていた

セキュリティの本質の一つは、攻撃者と防御者の間にある情報の非対称だ。

外部の攻撃者は、原則としてソースコードを持たない。だから彼らはブラックボックスとして、外から見える入口――公開API、認証、既知の脆弱性、設定ミス――を手探りで探る。攻撃者に見えている面は、本来かなり限られている。

ソースコードを外に出さないという行為は、意識されていたかどうかは別として、この非対称を守る行為だった。内側を見せない限り、攻撃者は内側を想像するしかない。

ところが、全ソースを外部のLLMに渡した瞬間、この非対称は反転する。攻撃者が決して持ち得なかったホワイトボックスの視点で、内部の弱点までが一覧化される。防御のために行った診断が、攻撃者が最も欲しがる完全な攻撃地図を生成してしまう。

脆弱性は「ある」より「届くか」で重みが違う

ここで、闇雲に全ソースをLLMに読ませることの、もう一つの問題に触れたい。reachability――到達可能性の視点だ。

脆弱性は、存在するかどうかより、攻撃者の到達経路上にあるかどうかで実害が大きく変わる。

直感に反するかもしれないが、システムの奥深くにある脆弱性は、そこへ至る経路がなければ、実害としての優先度は低い。一方で実害が大きいのは、外部に接している入口側だ。

つまり、全ソースをLLMに食わせて奥の奥まで網羅的に洗い出すという発想は、コストとリスクが最大の領域(奥)に、実害価値が最小の検出をかけていることになる。しかもその過程で、本来なら到達されない奥の弱点まで含めて、攻撃地図に書き込んでしまう。

だが、入口は「軽くていい」という意味ではない

ここで誤解してはいけない。reachabilityで重みが低いのは奥側であって、入口側はむしろ最も注意を払うべき領域だ。そして入口側こそ、単純なパターンチェックでは守りきれない。

理由は三つある。

第一に、入口側はそのほとんどが既知のOSSやライブラリでできている。自前のコードより、使っているライブラリの露出面が攻撃面になる。そして「既知」であることは安全を意味しない。既知だからこそ、攻撃者もそれを知っている。

第二に、作り方がワンパターン化している。特にAIがコードを書くようになって、この傾向は加速している。同じライブラリ、同じ実装パターン。攻撃者から見れば、一つ崩せば横展開できる構造になりやすい。

第三に、攻撃の戦術は日々更新される。昨日まで安全だったパターンが、今日公開されたexploitで破られる。入口の脆弱性を、静的なパターン照合や一度きりの診断で守ろうとすれば、必ず追いつかなくなる。

だから入口側は、最新の脅威情報と継続的に照合しながら見続けるべき層だ。逆に奥側は、到達経路がなければ優先度を下げ、より軽い手段から扱える。

「全ソースを闇雲にクラウドのLLMへ」という発想は、この点で二重に方向を誤っている。奥に対しては無駄に攻撃地図を作り、入口に対しては一度の診断では追いつかない。

弱点の地図を渡すとき、何が起きるか

かつて日本の金融が、内側の弱点を外部に開いた局面があった。

それは単なる資本参加や再建支援ではなかった。どこが傷んでいるのか、どの資産が弱いのか、どの判断が遅れているのか。金融システムの内側にある弱点の地図を、外部が握ることでもあった。

一度、弱点の地図を渡せば、主導権も渡る。

これは懐古ではない。構造の話だ。

ソースコードも同じである。全ソースを外部の巨大LLMに渡すということは、単にコードを見せることではない。依存関係、到達経路、認証境界、古い設計、直しにくい箇所――攻撃者が本当に欲しがる弱点の地図を、外部に作らせることでもある。

出さない文化は正しかった。ただ、論理が足りなかった

では、日本のソースを出さない文化が完全に正しかったかというと、そうではない。

そこに欠けていたのは、reachabilityという論理だ。「とにかく出さない」は守りとして正しかったが、なぜ、何を、どこまで守るのかが言語化されてこなかった。だから「閉鎖的で遅れている」という一言で片付けられ、AIという新しい号令の前であっさり揺らいでしまう。

守りの作法は正しかった。足りなかったのは、その作法を支える論理だ。

何を外に出し、何を手元で継続的に見続けるのか。入口側――reachableな外部接触面とOSS依存――は最新の脅威情報と照合しながら見続け、奥側は軽く扱う。攻撃地図の全体を、外部に作らせない。

この設計ができれば、ソースを外に出すかどうかは、文化や情緒の問題ではなく、論理の問題になる。

問うべきは「AIで診断するか否か」ではない。何を外に出し、何を手元に残すか。その線引きを、reachabilityという論理で引けるかどうかだ。

かつて、論理を言語化しないまま「古い」と切り捨てたものが、後になって足元を崩したことがあった。ソースを守ってきた文化も、同じ轍を踏ませてはならない。捨てるのではなく、論理を足して守る。それが、AIに全ソースを差し出す前に、私たちがやるべきことだ。

なお、入口側を手元で継続的に見るアプローチ――依存関係の到達可能性を解析し、脅威情報と突き合わせる仕組み――は、すでに実在する。たとえばAikidoのようなツールは、その一例だ。重要なのは、全ソースを外に出すことと、入口を手元で守り続けることは、まったく別の選択肢だという点である。