実施 2025.05 ・ 更新 2026.08.14
生成AIで古い基幹システムの仕様書を自動生成、1週間30本を作った実証実験
※イメージ画像です

取り組み概要
やさしく事例解説
プロジェクト解析
実施・導入企業
こんな方へおすすめのAI解説です
- 古いシステムの中身が分からない
- ベテランの退職で引き継ぎが不安
- 仕様書づくりに時間を取られている
どのようなAIの取り組み?
生成AIとRAGで古い基幹システムの仕様書を自動生成し、新任の担当者がAIに相談しながら開発を進められる環境を検証したAI取り組み
業種
独立系SIer(IT・通信)
取り組み領域
システム開発/レガシーシステムの仕様書作成
使ったAI
生成AI+RAG(Gemini/Google Cloud)
主な成果
PoCで1週間に30本の仕様書を自動生成
東京システムハウスは1976年創業の独立系SIerで、COBOLで書かれたレガシーシステムのマイグレーション支援を長年の柱としてきました。COBOLは扱える開発者が減り続け、長年の改修やドキュメント不足、担当者の退職が重なることで、システムの内部構造や仕様が把握しづらくなっていました。そこで同社が着手したのが、COBOLのソースコードから仕様書を生成し、その仕様書をもとに質疑応答ができる社内向けシステム「AIベテランエンジニア」の開発です。RAG(社内の文書を検索してAIの回答に使う仕組み)の構成やプロンプト設計、仕様書データのベクトル化、複数回のやり取りへの対応といった生成AI側の実装はGoogle CloudのパートナーであるG-genが技術面から支援し、開発そのものは自社チームが内製で進めました。PoC(小規模な試験導入)の段階で、仕様書の自動生成と新任担当者による実務対応まで確認されています。
出典:東京システムハウス株式会社様 - 導入事例 - 株式会社G-gen(ジージェン) 発行元:株式会社G-gen
やさしく事例解説
何に困って、AIを入れたのか
1959年に生まれたCOBOLは今も多くの企業の基幹業務を動かしていますが、それを扱える開発者は減り続けています。長年の改修の積み重ね、ドキュメントの不足、そしてベテランの退職が同時に進むと、何がどこで動いているのかを誰も説明できない状態が生まれます。東京システムハウスがマイグレーションの現場で向き合っていたのは、この二つが並行して進行する状況でした。
編集部の見立てでは、困りごとの本質は開発者の頭数ではなく、動いているコードと、それを説明する言葉との間が切れてしまっていた点にあります。コードが残っていても、その意図を読み解ける人がいなければ、新しく入った担当者は手の出しようがありません。人を採っても、渡すべき説明がなければ戦力にはならない。打ち手が採用ではなく、コードから説明を取り出して形式知に変える方向へ向かったのは、その構造を捉えていたからだと考えられます。
どうやって、うまくいったのか
人間が読む仕様書とは別に、AIが参照するための構造化仕様書を用意した設計が、この取り組みの中心にあります。開発の途中では、コードを直接見て答える開発支援ツールと比べて回答に出てくる情報量が乏しいという壁に突き当たり、仕様書にソースコードを埋め込むという工夫でそれを越えました。読み手を人間とAIに分け、それぞれに適した形の文書を別々に用意する割り切りが、質疑応答の土台になっています。
外部の知見を、詰まった一点に絞って投入した分担も効いています。RAGの構成、プロンプト設計、仕様書データのベクトル化、複数回のやり取りを成立させる実装といった生成AI固有の領域はG-genが技術面で支援し、COBOLの知識と業務理解を持つ自社チームが手を動かして組み上げる形をとりました。公開されているブログ記事で進められる部分は自力で進め、資料がほとんど存在しないマルチターン対応のように調べても届かない箇所だけを質問してコードを教わる。外注でも独力でもないこの受け方が、内製の速度を落とさずに実装の確実性を上げたのではないでしょうか。
利用の入り口を、普段使っているチャットに置いた点も見逃せません。Google ChatとGeminiのエージェント基盤をつなぎ、一問一答で終わらせずに会話を継続できるようにしたことで、分からないことをその場で聞くという行為が、特別な操作ではなく日常の動作の中に収まりました。相談のために別のツールを開かせない設計は、まだ知識の少ない担当者ほど効いてくるはずです。
具体的に、どんな成果が出たのか
改善・向上したこと
推進したこと
この事例で出た成果
PoCの段階で、1週間に30本の仕様書を自動生成できることが確認されています。さらに、新任のエンジニアがこの仕組みを使ってCOBOLの開発業務を実際に担当し、デリバリーまで到達しました。プロンプトを作り込む過程でAIが生成した仕様書と元のコードを見比べたことにより、開発メンバー自身のCOBOL理解が深まるという副次的な効果も生まれています。今後の課題としては、顧客への展開を見据えた管理画面やセキュリティ面の強化、COBOL以外の言語への対象拡大が挙げられています。
うちでも使える?
応用できるかどうかを分けるのは、説明したい対象が、すでに機械の読める形で残っているかどうかです。ソースコードや設定ファイルのように動作の根拠がテキストとして揃っている領域なら、生成AIに説明文を書かせ、それ自体を検索の対象にするという筋道は、対象がCOBOLでなくても成り立ちます。逆に、判断の理由が担当者の記憶や紙のメモにしか残っていない業務や、コードを社外のクラウドに出せない制約が強い領域では、同じ形をそのまま持ち込むのは難しくなります。仕様書を作ること自体が目的化しやすい点にも注意が必要です。この事例で価値が生まれたのは、生成した文書を人が読むだけで終わらせず、AIへの質問の材料として使い回したからでした。
試すなら、社内で最も読み解きにくいプログラムを1本だけ選び、生成AIに仕様の説明を書かせてみる。出てきた文章をその処理を知る担当者に見てもらい、どこが足りないかを指摘してもらえば、AIに渡す文書へ何を足すべきかが具体的に見えてきます。
この事例は2025年5月時点の情報です。AI分野は変化が速いため、現在は同様の取り組みをより短い期間・少ない負担で実現できる場合があります。
プロジェクト解析
プロジェクト内容
AI導入・支援形態
導入部門・データ活用
導入部門:全社共通・汎用業務
活用したデータ:文書・ナレッジ
採用したAI技術・ツール
採用したAI技術:テキスト・言語AI
AIモデル・ツール
連携ツール
連携したシステム・外部サービス
プロジェクト実施・導入企業
株式会社G-gen
Google Cloud(旧称GCP)プレミアパートナー。請求代行、システム構築から運用に至るまで顧客のニーズに合わせたサービスを提供し、Google Cloud 専任プロフェッショナルサービスとして技術選定やセキュリティ対策などの相談に対応する。
東京システムハウス株式会社
掲載企業の方へ:本記事は公開情報をもとに作成しています。内容の修正・削除、または貴社確認のうえでの公式掲載をご希望の場合はこちらからご連絡ください。
