AIによる刷新提案を受け取った方へ

「生成AIで既存システムを解析して作り替えます」という提案を受け取り、どこを見て判断すればいいか迷っている方に向けて書いています。

判断材料が1つ増えました。同じことを実際にやった会社が、工程の分け方まで公開したからです。

公開されたのは成果ではなく構成です

Google Cloudが2026年6月16日、Siemensと共同で構築したAIシステム「Knowledge Fabric」の中身を公開しました（How Siemens “slices the elephant”）。日本語では＠ITが2026年8月3日に報じています。

対象は工場・電力・交通のインフラを動かすSiemensのソフトウェアです。10年以上かけて積み上がった、数億行規模のコードベース。既存のコーディング支援ツールでは扱えなかったと書かれています。

注目したいのは、削減率でも導入効果でもありません。どの作業をどう分けたかが、そのまま出ていることです。

標準的なRAGでは読めませんでした

最初に否定されたのは、いま最も普及している手法でした。

Google Cloudのテクニカルリードは「標準的なRAGでは不十分だと気付いた」と述べています。理由も具体的です。「コードは単なるテキストではなく、固有の構造を持っている。クラスはファイルに、ファイルはモジュールに属している。これらをベクトルデータベースにフラット化して格納してしまうと、コードベースの要素間の関係性が失われてしまう」。

代わりに使われたのがナレッジグラフです。コードの構造をグラフとして持ち、ドキュメントにも同じ扱いを適用して、両者の間をつなぐ。これで「特定のコード片を仕様書の要件へ直接リンクさせる」ことができるようになったとしています。

グラフ照会と、ベクトル検索と、全文検索。この3つを組み合わせて、はじめて「軸制御パネルのロジックを変更したら、どの関数を更新する必要があるか」に答えられるようになった、という順序です。

象を切り分ける

もう1つの発見は、AIエージェントの側にありました。大きくて曖昧な仕事が苦手だというものです。

そこで「このモジュールをリファクタリングする」といった依頼を細かく割り、それぞれに専門のエージェントを当てました。この設計パターンに付いた名前が「象を切り分ける（slicing the elephant）」です。

順 エージェント 役割
1 検索 コードのグラフをたどり、ドキュメントと照合する
2 ユーザーストーリー プロダクトオーナーに聞き取り、受け入れ基準つきの要件を書く
3 アーキテクチャ影響 変更案をグラフと照合し、1行も書く前に副作用を予測する
4 タスク分解 影響分析を受け取り、各変更に必要な文脈を持たせた小さな単位へ割る
5 コーディング 割られたタスクの変更を実装する

書くのは5番目だけです。1から4は、書くための材料を揃える工程です。

この一文が全部です

原文には、こう書かれています。

「文脈と事前分析なしにこの段階へ至ると、使用できないコードが生成される」（Reaching this step without context and prior analysis produces unusable code）。

コーディングエージェントの説明に、わざわざこの注記が付いている。うまくいった事例の説明として、ここは異例です。

4つの制約は日本の現場と同じです

Siemensが挙げた課題は4つでした。読むと、国内の基幹システムで聞く話とほとんど重なります。

4つ目が効きます。**ハルシネーションや未検証の変更は「非効率」ではなく「運用上許容されない」**と書かれています。だから各ステップに人が入る構成になっている。エージェントを増やしたぶん人が減る設計ではありません。

これは私たちがAIが書いたコードを人がレビューする理由で書いた立場と同じです。

成果の数字は出ていません

ここは正確に読む必要があります。

公開された成果の書き方は「以前はシニアエンジニアが数日かけていた依存関係の分析が、はるかに短時間で終わるようになった」「本番パイロットで全体のコーディング工数を削減した」。削減率も、期間も、対象の規模も書かれていません。

宣伝目的のブログで数字を出さないのは、むしろ誠実な部類です。工程の分け方まで公開したうえで、効果は定性的にとどめている。

比べたいのは、数字だけが大きく出ている提案のほうです。測定範囲を示さない生産性の数字は、どの工程で何を測ったかが確認できません。今回の事例は逆に、工程が全部見えていて数字がない。**発注側にとって使えるのは、後者の情報です。**工程の分け方は自社の提案書と突き合わせられますが、範囲の分からない倍率は突き合わせようがありません。

AI刷新の提案書で確認する5点

  • コードを書く前の工程がいくつありますか: 現状解析、要件の確定、影響範囲の予測、作業の分割。この4つが独立した工程として書かれているか。「AIが解析して変換します」の一言で済んでいる提案は、5番目だけを売っています
  • 既存の構造をどう保持しますか: コードとドキュメントの関係を、何の形で持つのか。全文をベクトル化して検索するだけの構成では、依存関係の追跡はできません
  • 散らばった資料の扱いはどこに書いてありますか: チケット、Wiki、紙の設計書。どこまでを取り込み対象にするかで工数が変わります。範囲が書かれていない見積もりは、後から動きます
  • 人が判断する箇所はどこですか: 工程ごとに人が入るのか、最後にレビューするだけなのか。長期運用するシステムほど、出力の説明可能性と追跡可能性が要ります
  • 効果の数字は何を測ったものですか: 短縮率が示されているなら、対象工程・規模・比較対象を聞きます。答えられないなら、その数字は自社に当てはめられません

ベンダー選定の評価シートや、社内の投資判断資料にそのまま転記して使えます

現場メモ

私たちも、既存システムの解析から入る案件では同じ順序で進めています。読む、聞く、影響を出す、割る。書き始めるのはそのあとです。

正直に言うと、この順序は営業上は不利です。**最初の数週間、目に見える成果物が出ないからです。**画面もコードも出てこない期間に費用が発生することを、事前に説明しておく必要があります。ここを飛ばして先に動くものを見せたほうが、提案は通りやすい。

それでも順序を変えていないのは、飛ばした案件の後半で何が起きるかを見てきたからです。作り直しの工数は、解析にかけた工数より大きくなります。Siemensの事例で「文脈なしにコーディングへ至ると使用できないコードが生成される」と明記されていたのを見て、これは規模を問わず同じなのだと確認できました。数億行でも、数万行でも、順序は同じです。

何を持ち帰るか

この事例が示したのは、AIでレガシーを扱えるかどうかではありません。扱うために何を先に用意するかです。

コードとドキュメントの関係を構造として持つこと。作業を、AIが扱える大きさまで割ること。各段階で人が判断すること。この3つは、道具が変わっても残ります。

そして提案を受ける側にとっては、確認の順番が1つ決まりました。倍率の前に工程数を見る。書く前の工程が説明できないベンダーは、仕様書のないシステムを読むところで止まります。移行元がIBM系か国産かで難易度が変わるという話も、この工程の重さの違いとして現れます。

自社のシステムで、どこまでが読める状態にあり、どこから人が要るのかを整理したい段階でしたら、お問い合わせからご相談ください。作り替えの提案ではなく、現状を数えるところから入ります。