軽い前置き
はじめまして、AETS代表の伊藤あきらです。Qiita初投稿です。
最近のClaude Code流出事件を見ていて、自分が続けているROCm研究と、思いがけず一本の線でつながる感覚がありました。これは単なる感想ではなく、いまの時代における「ソフトウェアの守り方」を考えるうえで、かなり大きなヒントになるのではないかと思っています。
そんな話を、今回は書いてみます。
はじめに
先週のClaude Codeソースコード流出事件は、AI業界に大きな衝撃を与えました。
ただ、私が本当に重要だと思ったのは、「ソースが漏れた」という事実そのものではありません。
むしろ重要なのは、漏れたあとに何が起きたかです。
公開された約51万行規模のTypeScriptコードを起点に、AIコーディングエージェントを使った再実装・移植の動きが短期間で立ち上がりました。DMCAテイクダウンがあっても、別言語への移植やクリーンルーム的な再構成が進んでしまえば、もはや「元のコードを消す」だけでは止めにくい局面に入ります。
一方で、モデルの重み（weights）やトレーニングデータは流出していません。
この非対称性を見たとき、私はすぐに、自分が続けてきたROCm研究との接点を感じました。
私の研究：ROCmの深層を読んで9.4倍の高速化を得た
私はAMDのオープンソースGPUスタック「ROCm」上で、レガシーGPU（MI25/gfx900）のランタイム実行パスを観測・最適化する研究をしています。
やっていることをざっくり言うと、
- ROCm関連コードを読む
- 実機で動かす
- GPUとソフトウェアスタックの各層で何が起きているかを見る
- どの推論経路が生きているか、どこでフォールバックしているかを確かめる
という作業です。
この研究の意図は、単に古いGPUを速く使いたい、というだけではありません。
スタック全体を俯瞰して、どの層で何が起きているかを構造化することは、科学計算コミュニティ全体にとっても意味があると考えているからです。
その過程で、たった1つのランタイムパラメータ ROCBLAS_TENSILE_LIBPATH を変更するだけで、特定条件下で9.4倍のスループット改善を観測しました。これは既に論文化しています。
- 論文（Zenodo, DOI付き）: https://doi.org/10.5281/zenodo.19388994
- 研究サイト: https://aets-magi.github.io/ROCm-pages/
ただし、ここで本当に言いたいのは「9.4倍すごいでしょ」という話ではありません。
その結果にたどり着くまでに必要だったのは、ソースコードを読むだけでは見えない、複数層にまたがるランタイム観測でした。
HIPランタイム → rocBLAS → Tensile → GPU ISA
という各層で、実際にどのカーネルが選ばれているかは、コードを読むだけでは確定できません。実行して観測しないとわからないのです。
外から見ると、たった1つの環境変数を変えただけに見えるかもしれません。
でも、その「たった1つ」が本当に効いていると確認するまでには、深いスタックをまたいだ観測と切り分けが必要でした。
そして、ここにこそ今回の話の核心があります。
浅いスタックは守れないかもしれない。深いスタックは、開いていても守れるかもしれない
ここで、Claude CodeとROCmを並べてみます。
| Claude Code | ROCm | |
|---|---|---|
| 言語 | TypeScript（約50万行） | C/C++/ASM（数百万行、複数リポジトリ） |
| 公開状態 | クローズド（だった） | オープンソース |
| AI再実装の容易さ | 短期間で再実装・移植が立ち上がる | 極めて困難 |
| 本当の競争優位 | モデルweights、データ | ハードウェアIP、ISA設計 |
Claude Codeの中で、今回強く露出したのはスクリプト言語で書かれたオーケストレーション層でした。
この層はロジックが可読で、AIが理解・翻訳しやすい構造を持っています。
一方でROCmは、完全にオープンソースです。コードは読めます。検索もできます。ビルド方法も追えます。
でも、だからといって「AIに全部リライトして」と言って済む世界ではありません。
ハードウェア固有のフォールバックパス、ISAレベルの命令依存、動的なランタイムパス選択、複数ライブラリをまたぐ振る舞い。こうした多層結合は、ソースが見えていても、そのまま再現できるものではありません。
つまり、ここで言いたいのはこういうことです。
守るべき本質が浅い層にあるシステムは、コードが見えた瞬間に急速に再構成されうる。
一方で、深い層に本質があるシステムは、たとえオープンでも簡単には写せない。
スタック深度の両刃性
ただし、ここには重要な注意点があります。
深いスタックは、再実装者だけでなく、最適化者にとっても壁になる ということです。
私自身、ROCmの最適化を進める中で、「スタックが大きくて複雑すぎると、外から真似しにくいだけでなく、中にいる側も把握しにくい」ということを痛感しました。
9.4倍の改善は、bounded observation（限定的観測手法）によって、その壁を少しずつ越えていった結果です。
言い換えると、
-
depth = 防御はかなり正しい - でも
depth = 安全ではない
ということです。
深ければ勝手に守られるわけではありません。
観測できなければ、最適化も改善も保守も難しくなります。
つまり、深さは「天然の防御壁」であると同時に、「内部の進化を遅くする壁」にもなりうるのです。
提言：何を隠し、何を開くか
ここまでの話から、実務的には次のような示唆が得られると思います。
1. 浅いオーケストレーション層を隠しても、長期的には守りにくい
TypeScriptやPythonで書かれたハーネスや制御コードは、いまやAIが理解し、別言語へ移植し、かなりの速度で再構成できる対象です。
もちろん、秘匿がまったく無意味とは言いません。
ただ、秘匿にかかるコスト――サプライチェーンリスク、コミュニティ監査の欠如、閉じた保守体制の負荷――に見合うだけの防御効果があるかは、かなり怪しくなってきているように感じます。
2. 本当の競争優位は、深い層にあることが多い
モデルweights、トレーニングデータ、推論インフラ、ハードウェア近傍の実装、深いシステムスタック。
こうしたものは、ソースを見ただけでは置き換えにくい領域です。
表層の制御コードではなく、再現コストの高い深い層に何を持っているか が、これからの競争優位を左右するのだと思います。
3. オープンであることが、防御と両立する場合もある
ROCmの事例は、オープンであることと、防御的であることが必ずしも矛盾しないことを示しています。
もちろん、何でも公開すればよいという話ではありません。
ここで言いたいのは、競争優位の中心が深い層にあるなら、浅い層の秘匿はコストに見合わない可能性がある ということです。
オープンにすることでコミュニティの観測・改善・最適化の力を取り込みつつ、深い層の再現コストはなお高いまま保たれる。そういう設計もありうる、ということです。
論文について
この分析は、学術論文としてもまとめています。
-
ROCmの研究論文（MI25/ROCm実証研究、公開済み）
https://doi.org/10.5281/zenodo.19388994 -
コード防衛に関する論文（Stack Depth as Code Defense、公開済み）
https://doi.org/10.5281/zenodo.19394537
Qiita向けにはなるべく平易に書きましたが、論文版ではもう少し概念的に、
- shallow orchestration
- deep runtime-coupled stack
- defensive depth
- behavioral reconstruction cost
といった軸で整理しています。
おわりに
Claude Code流出事件は、単なるセキュリティインシデントではないと思っています。
この事例は、AI支援による再実装圧力が高まる時代に、ソフトウェア資産の防御設計をどう考えるべきか という問いを、わたしたちに、かなり強い形で突きつけた出来事でした。
そして、その問いへの答えは、単純に「もっと厳重に隠す」ではないのかもしれない。
むしろこれから重要になるのは、
自分たちの競争優位がどの層に宿っているのかを見極めること
その深い層を観測・改善できるだけの手法と基盤を持つこと
なのだと思います。
もし自分のプロダクトやOSSについて「何を隠せば守れるのか」を考えているなら、まず見るべきなのはソース公開の有無ではなく、競争優位がどの層に宿っているか ではないでしょうか。わたしたち開発者は、このことを、いまいちど考える地点に来ているのかもしれません。
筆者: 伊藤あきら / AETS (Akatsuki Enterprise Technology Solutions)
研究サイト: https://aets-magi.github.io/ROCm-pages/