【事例記事マニア】第1回　Siemens — 数億行のレガシーを"象の切り分け"で近代化／記事としての採点は 7.5/10点

わたしは普段、事例記事を作っているジジイです。作り手だから、他社の事例が気になって仕方がない。不定期に、10点満点で採点していきます（基準は → 第0回）。

第1回の今日は、いきなり大物にして、惜しい一本です。Siemens（産業用ソフトの世界的巨人）。Google CloudのブログでClaude Codeも使った事例。

この事例でやったこと：10年以上・数億行のレガシーコード、しかも必要な知識は、コード本体・課題チケット・社内Wiki・2000年代にスキャンされたPDFマニュアルに、バラバラに散らばっている。どこに何があるか、もはや誰も全体を把握できない。この化け物を、Siemensは「Knowledge Fabric（知識の織物）」で攻略したそうです。

ポイントは「コードは単なるテキストじゃなくて、地図みたいな構造を持っている」という気づきですね。

ふつうAIに大量の文書を読ませるときは、全部を細切れにして「意味が近いものを検索する」やり方（ベクトル検索）を使う。でもこれだと、「このクラスはこのファイルの中にある」「この機能はあの機能につながっている」といったつながりの情報が消えてしまいます。

そこでSiemensは、コードを路線図のように組み直した（Spanner Graph）。地下鉄の路線図みたいに「どのコードがどのコードと関係しているか」を地図化する。だから「この画面のロジックを変えたら、どの関数を直せばいいかな？」という問いに、影響範囲まで含めて正確に答えられるそうです。

もうひとつの工夫が、アイキャッチにもなっている**「象の切り分け」**。AIは「このモジュールを丸ごと作り直して」みたいな大きく曖昧な注文が苦手らしい。だから巨大な象さんを構成する部品を細分化した。大きなタスクを小さく割り、5つの専門エージェント（調べる・要件をまとめる・影響を予測する・作業に分解する・実装する）で分担させる。そして品質を担保するために、全工程に人間が立ち会うようにしたものです。

なんだかすごい事例ですが、記事としての採点をしてみましょう。

まず、素晴らしいところは、技術です。コードは構造を持ち、相互に関係しているから、RAG（辞書のような使い方）では不十分という着眼は、多くのエンジニアが薄々感じていることではないでしょうか。巨象の切り分けも美しい。

じゃあ、なぜ7.5なのか。犯人は定量成果です。この事例、成果の記述がこうです——「依存関係分析が数日から大幅に短縮」「コーディング作業が削減」……何日が何時間になったんですか？　削減って、何%ですか？　ひとつも数字がない。 Googleさんなら、指標を示し、定量評価を示してほしかったです。規模も技術もすばらしいだけに、もったいなさが爆発しています。

あと、個人的にはAnthropic × Google併用も気になったけど、Claude Codeがどう使われているかいまいちわからなかった。まあGoogleの事例だから仕方ないですけど、Claude好きの私としては気になりました。

さて、事例記事をつくりたい人へ――技術の凄さは、提供サービスの凄さは誰しも言いたいものですね。それに加えて、数値を示すと、読者がより身近に感じるはずです。「大幅に短縮」よりも「数日が30分になりました」とあったほうが、その技術やサービスを導入するための検討が一歩進むはずです。

レガシーコードのモダン化は、巨大な象を運ぶ仕事です。Siemensの事例は、象の切り分け方まで見せてくれました。あとは、重さや速さを測って示してほしかったですね

次回は、同じような巨象の事例で、数値を示したものを採点します。

関連記事「事例記事をつくろう」シリーズ

記事を書いているのは