| この記事でわかること |
|
| この記事の対象者 |
|
| 効率化できる業務 |
|
「2025年の崖」という言葉、もう聞き飽きたという方も多いでしょう。でも、実際に古びた基幹システム（レガシーシステム）の保守や移行を担当されている方にとって、これは単なるバズワードではありません。毎日が崖っぷち、そんな感覚ではないでしょうか？
「仕様書がない」「当時の担当者が定年退職して誰も中身を知らない」「スパゲッティのように絡み合ったコード」……。 そんな絶望的な状況下でシステム移行を進めなければならない現場の苦労は、計り知れません。
そんな中、希望の光とも言えるニュースが飛び込んできました。 大手ITベンダーの富士通が、基幹システムのOS更新作業に生成AIを活用し、作業時間をなんと65％も削減したというのです。
「どうせ、大手だからできたんでしょ？」 「AIにコードを書かせても、結局デバッグが大変なんでしょ？」
そう思われたかもしれません。ですが、この事例の肝は「AIの性能」そのものよりも、「AIへの指示の出し方（プロンプト）」にありました。これは、莫大な予算を持つ大企業でなくても、今すぐ私たちが参考にできる「知恵」の宝庫です。
今回は、富士通の事例を紐解きながら、私たち一般企業がシステム移行やDX推進において、どう生成AIを「相棒」にすべきか、その具体的なヒントを探っていきましょう。
なぜ、システム移行はここまで泥沼化するのか
本題に入る前に、少しだけ「痛み」を共有させてください。なぜ、私たちはこんなにもレガシーシステムの移行に苦しめられるのでしょうか？
最大の敵は、「暗黙知」です。 数十年前に構築されたシステムの多くは、度重なる改修でツギハギだらけ。ドキュメント（仕様書）が更新されていないことなど日常茶飯事です。「このコード、何のためにあるの？」「消していいの？」とエンジニアが頭を抱え、結局怖くて触れない……なんてこと、よくありますよね。
これまでは、これを解決するには「人海戦術」しかありませんでした。ベテランエンジニアが一行一行コードを読み解き、新しい環境に合わせて書き直す。しかし、エンジニア不足が叫ばれる今、そんな贅沢なリソースはどこにもありません。
そこで登場したのが「生成AI」です。「AIにコードを書かせればいいじゃないか」と誰もが思いました。しかし、実際にやってみると、「AIが勝手に存在しない関数をでっち上げる（ハルシネーション）」「動くけど、セキュリティホールだらけ」といった問題に直面し、挫折する企業が後を絶ちません。
なぜ富士通は成功し、他は失敗するのか。その違いはどこにあったのでしょうか？
富士通の事例深掘り：OS更新を激変させた「プロンプトの妙」
今回の富士通の事例（日経クロステック報道等による）で特筆すべきは、彼らがAIに「ゼロから新しいシステムを作らせた」わけではない、という点です。
ターゲットを「定型作業」に絞り込んだ
彼らがターゲットにしたのは、「OSのバージョンアップに伴うプログラム修正」です。 具体的には、SolarisなどのOSを更新する際、古いOSでしか動かない書き方を、新しいOSの仕様に合わせて書き換える作業です。
これは創造性が求められる仕事ではありません。 「Aという書き方は、新しいバージョンではBと書かなければならない」 という明確なルールが存在します。しかし、対象となるファイル数は膨大です。人間がやれば単純ミスが多発し、集中力が持ちません。まさに、AIが得意とする領域です。
「プロンプト（指示出し）」の技術が凄かった
ここで富士通が使ったのが、「技あり」のプロンプトエンジニアリングです。単に「このコードを新しいOSに対応させて」と投げるのではありません。
「Few-shot プロンプティング」と呼ばれる手法をご存じでしょうか？ これは、AIに対して「少数の例（ショット）」を見せて学習させる手法です。
富士通のアプローチはこうです。
- 修正のルールを明確にする： 「この関数は廃止されたので、こっちを使う」というルールを定義。
- 具体例（Before/After）を見せる： 「修正前はこう書いてあるけど、修正後はこう直してね」という「正解のペア」をプロンプトの中に含める。
これにより、AIは「ああ、こういうパターンで直せばいいんだな」と文脈を理解し、驚異的な精度で修正を行えるようになったのです。結果として、従来の手法に比べて作業時間を65％削減。これは、数ヶ月かかるプロジェクトが数週間で終わるレベルのインパクトです。
自社で真似できる？「技ありプロンプト」作成の極意
「なるほど、Few-shotプロンプティングね。専門用語が出てきて難しそうだ」 そう構える必要はありません。要は、「新人への引き継ぎマニュアル」を作るのと同じなのです。
もしあなたが、新人のアルバイト君に大量のデータ修正をお願いするとしましょう。「いい感じに直しといて」と言って、完璧な成果物が上がってくると思いますか？ 絶対に来ませんよね。
- 「ここを見て」
- 「もしAだったらBにして」
- 「例えば、このケースはこう直すんだよ（実例）」
こうやって教えるはずです。生成AIに対しても、まったく同じことをするのです。
明日から使えるプロンプトのコツ
- 「察して」は禁物： AIは文脈を読み取ろうと努力しますが、指示が曖昧だと「もっともらしい嘘」をつきます。修正ルールは箇条書きで明確に伝えましょう。
- 「思考の連鎖」を促す（Chain of Thought）： いきなり答えを出させるのではなく、「まずコードを分析して、修正が必要な箇所をリストアップしてください。その後に、修正案を提示してください」と手順を踏ませると、精度が格段に上がります。
- 成功パターンを「ライブラリ化」する： 富士通は、うまくいったプロンプトを社内で共有・蓄積しているそうです。一度作った「最強の指示書」は、チームの資産になります。
AI任せは事故の元！「人間」が握るべきハンドル
ここまでAIの可能性を絶賛してきましたが、ここで冷や水を浴びせるようなことを言わなければなりません。 「AIは、平気で嘘をつきます」
これは生成AIの仕組み上、避けられない特性です。特に専門的なコード修正において、AIが自信満々に出してきたコードが実は動かない、なんてことはザラにあります。
だからこそ、「Human-in-the-loop（人間がループの中に入る）」ことが絶対条件です。
富士通の事例でも、AIがやったのはあくまで「下書き」や「一次修正」まで。最終的にそれが正しいかどうかを判断し、テストを行い、責任を持つのは人間のエンジニアです。
しかし、役割は大きく変わります。 これまでのエンジニアは「ひたすら書く人」でしたが、これからは「AIが出してきた成果物をレビュー（検査）する人」になります。 「書く」苦しみから解放され、「品質を担保する」という、より本質的で高度な業務に集中できるようになったのです。そう考えると、少しワクワクしませんか？
2025年以降、エンジニアと情シスの仕事はどう変わる？
今回の事例は、単なる「OS更新の効率化」にとどまりません。企業のIT部門のあり方そのものが変わる予兆です。
最新のSEO戦略やAIトレンドのレポート（※添付資料参照）でも触れられていますが、これからは「AIエージェント」の時代が到来します。人間が細かく指示しなくても、AI自身が「あ、OSのバージョンが変わったから、関連するコードを調査して修正案を作っておきましたよ」と提案してくる未来も遠くありません。
その時、私たち人間に求められるのは、「AIを使いこなすディレクション能力」と、「システム全体を見渡す設計能力」です。
まとめ：まずは「小さく、賢く」始めよう
富士通の「65％削減」は、魔法のような数字に見えますが、その裏には「OS更新」という具体的でルール化しやすいタスクへの「選択と集中」、そして「Few-shotプロンプティング」という「具体的な技術」がありました。
いきなり基幹システムのすべてをAIに任せるのは危険です。でも、こんなところからなら始められるのではないでしょうか？
- Excelマクロ（VBA）の簡単な修正
- エラーログの解析と原因の一次切り分け
- 古い仕様書の要約と現代語訳
「AIなんて信用できない」と食わず嫌いをするのではなく、まずは小さなタスクで、AIという新しい「相棒」の実力を試してみてください。その際、ぜひ「具体例を見せて教える（Few-shot）」アプローチを忘れずに。
あなたの現場の「胃が痛くなる作業」が、少しでも楽になることを願っています。
引用元
日経XTECH 「富士通が基幹システムのOS更新に生成AI、技ありプロンプトで作業時間65％削減」
