SiemensとGoogle Cloudは2026年6月、巨大な産業向けソフトウェアをAIで近代化する事例として、Knowledge Fabricという仕組みを公開しました。ポイントは、単にコードを要約するのではなく、コード・要件書・Jira・Confluence・古いPDFまでをつないだ知識グラフを前提に、AIへ小さな作業単位を順番に渡すことです。レガシーコード刷新を考える企業にとって、モデル選定より先に『文脈をどう束ねるか』『人間承認をどこに置くか』が勝負だと分かる事例です。
Siemensの事例で何が変わったのか
Google Cloudの公式ブログによると、Siemensは数億行規模のコードベースを抱え、しかも10年以上前の要件や設計判断が複数システムに分散していました。従来型のAIコーディング支援では、巨大リポジトリ全体の関係性や履歴の意味まで追えず、産業ソフトウェアに必要な説明責任も満たしにくかったとされています。そこで両社は、コード理解を『検索の問題』ではなく『関係性の問題』として捉え直し、Knowledge Fabricを中核にした agentic workflow を設計しました。
背景にあった4つの壁
公開内容では、課題は主に4つです。1つ目は規模で、標準的なモデルのコンテキスト窓を大きく超えるリポジトリが対象でした。2つ目は断片化で、知識がコード、Jira、Confluence、紙由来のPDFに散らばっていました。3つ目は複雑さで、あるコード行と10年前の要求仕様を結び直す必要がありました。4つ目は責任で、品質・コンプライアンス・長期保守を前提に、AI出力の説明可能性と検証可能性が求められていました。
Knowledge Fabricの構成
Google Cloudは、この仕組みが Spanner Graph、Google Agent Development Kit、Gemini API、Agent Platform、Gemini CLI、そして Anthropic Claude Code を組み合わせて作られたと説明しています。重要なのは、コードや文書をただベクトル化するのではなく、クラスはどのファイルに属するか、要件はどの機能に紐づくか、といった関係をグラフとして保持する点です。Siemens側の知識グラフ紹介ページでも、知識グラフはサイロ化したデータを単一の信頼できる基盤に置き換え、AIエージェントが推論し行動するための文脈を与えると整理されています。
なぜRAGだけでは足りないのか
今回の示唆は明快です。通常のRAGは『関連文書を探して答える』には有効でも、複数システムをまたぐ依存関係をたどりながら、変更計画を分解し、影響範囲を説明し、次の作業へ渡す用途では不足しやすいということです。Google Cloudはこの考え方を『slicing the elephant』と表現し、大きなリファクタ依頼を小さな作業へ分割し、専門エージェントに順番に処理させる設計を採っています。さらに各段階で人間をループに残し、現場のエンジニアが確認できる形にしているため、産業領域でも運用しやすい構造です。
自社導入で先に確認したい5項目
この事例を自社へ引き寄せるなら、先に5点を確認したいです。第1に、コード以外の設計資産をどこまで集約できるか。第2に、変更理由を後から追跡できる識別子を残せるか。第3に、AIへ丸投げせず、分解・実装・レビューのどこで承認を入れるか。第4に、Graph RAG や知識グラフをどの領域から始めるか。第5に、速度ではなく『実装工数削減』『レビュー時間短縮』『互換性維持』のような業務KPIで効果を測れるかです。レガシー刷新は派手なモデル導入より、文脈整備と統制設計のほうが先に差になります。
大規模コードの再設計やAIエージェント導入を社内ルールまで含めて整理したい場合は、 HelloCraftAIに相談してください 。PoCの前提整理から運用設計まで一緒に進められます。
よくある質問
Q. この事例は製造業以外でも参考になるのでしょうか。A. 参考になります。効いている本質は業界固有機能ではなく、巨大コードベースと分散文書を知識グラフでつなぎ、AIへ小さな単位で仕事を渡す設計だからです。金融、公共、基幹業務のように説明責任が重い領域でも応用しやすい考え方です。
Q. まず何から始めるべきでしょうか。A. いきなり全社の知識グラフを作るより、変更頻度が高く、要求仕様とコードの対応づけで毎回苦しむ1領域に絞るのが現実的です。Siemensの事例でも、大きな課題を小さく切る発想が中心でした。対象領域、関連文書、承認者、効果測定指標を先に決めると、AI導入が検証可能なプロジェクトになります。
