システムを改修したい。でも、今の仕様が分からない〜開発会社に聞かなくても仕様を確かめ、改修の要求を自社でまとめられる【AI駆動開発の「仕様解説BOT」】〜

自社システムでやりたいことがある。例えば、

「この画面の条件を少し変えたい」
「この機能を、別の部署でも使えるようにしたい」
etc

改修したいことははっきりしているのに、今のシステムがどう動いているのかを、社内で答えられる人がいない。要求をまとめる前に、まず開発会社に確認する。返事を待って、また質問する。

長く使っている自社システムほど、仕様は担当者と開発会社の中にたまっていきます。仕様書を作り直しても、作った瞬間から古くなり始めます。

この記事では、自社システムの仕様を「聞けば正確に答えてくれる」状態にし、コードと突き合わせながらリリースのたびに最新に保つ方法を紹介します。プレスマン（弊社）が品質を軸にしたAI駆動開発の一つとして提供している「仕様解説BOT」の考え方と、大手メディアのシステムでの取り組みです。

1. 仕様は、担当者と開発会社の中にたまっていく

経済産業省が2025年5月に公表したレガシーシステムに関するレポートでは、回答した大企業の74％がレガシーシステムを保有していると答えています。レポートは、その特徴の一つにブラックボックス化を挙げ、「仕様や設計のドキュメントが整備されず、運用が属人化する」状態だと説明しています。あわせて、多くのユーザー企業が開発会社に頼り切りになっていることも課題として指摘しています。

長く運用しているシステムでは、改修の経緯や「なぜこうなっているのか」という判断が、担当者の記憶と開発会社の手元にたまっていきます。仕様書はあっても、リリースを重ねるうちに実装と少しずつずれていきます。AIでコードを書く場面が増えるほど、このずれが広がる速さも増していきます。

その結果、自社のシステムなのに、自社だけでは説明できない状態になります。

2. 仕様が分かれば、できること

現状の課題	→ こうしたい
改修したいことはあるのに、今の仕様が分からない。要求をまとめる前に、まず開発会社に確認を重ねている	今の仕様を自社で確かめて、改修の要求を自分たちでまとめたい
画面や業務ルールのちょっとした確認でも、開発会社に問い合わせている。時間も費用もかかる	その場で自分で確かめたい
仕様は担当者の頭の中にある。異動や退職のたびに知識が抜け、新任者は聞く相手がいない	担当が替わっても、そのまま引き継ぎたい

一番大きいのは1つ目です。今の仕様を自社で確かめられれば、改修の要求を自分たちの言葉でまとめてから開発会社に出せます。開発会社とのやり取りは「今どうなっていますか」という確認から、「こう変えたい」という相談に変わります。

ただし、3つとも前提があります。答えが、今のシステムと合っていることです。古い仕様書をもとに要求をまとめても、手戻りが増えるだけです。

3. 仕様書を作り直しても、うまくいかない

仕様が分からないとき、まず考えるのは仕様書の作り直しです。ただ、それだけではまた同じ状態に戻ります。

方法	最新か	正確か	使いやすさ	維持の手間
仕様書を作り直す	作った瞬間から古くなる	改修のたびに実装とずれる	探して読む。分厚いと読まれない	大きい
社内Wikiにまとめる	更新は人頼み	書き手次第	探して読む	大きい
文書を検索するAIに任せる	置いてある文書の時点まで	文書が古ければ、古い答えが返る	質問できる	文書の更新が必要
AIにコードを読ませて聞く	読ませた時点まで	もっともらしく間違えることがある	質問できる	取り込みが都度必要
仕様解説BOT	リリースのたびに更新	コードと突き合わせて検証	自然な言葉で質問できる	プレスマン（弊社）が検証・更新

足りないのは、仕様を「書くこと」ではなく、今のシステムと合っているかを確かめ続けることです。

4. 仕様を「聞けば答える」状態に。品質を軸にしたAI駆動開発で、最新に保つ

仕様解説BOTは、次の3つをリリースのたびに繰り返します。

ステップ1：AIが、コードから仕様を抽出する: AIがシステムのコード全体を読み、仕様の下書きを作ります。既存の仕様書や関連資料も取り込みます。

ステップ2：プレスマン（弊社）が、正しさを確かめる: 下書きの内容をコードと突き合わせて、正しいかどうかを判定します。コードに書かれていない業務ルールや経緯を資料から補い、全機能を網羅しているかも確認します。リリースごとに版と差分を管理し、「いつ時点の仕様か」を明らかにします。

ステップ3：質問できるBOTとして届ける: 確かめた仕様だけを根拠に答えるBOTにして、お客様に使っていただきます。

AIで仕様を書くことは、今では誰にでもできます。価値があるのは、その出力を確かめて、使える状態に保ち続けることです。

変わり続けること	起きがちな問題	品質を軸にしたAI駆動開発では
改修のたびに、仕様が変わる	仕様書が置き去りになる	リリースのたびに、抽出 → 確認 → 配信をやり直し、版と差分を残す
AIは、もっともらしく間違える	誤った仕様がそのまま答えになる	コードと突き合わせて正誤を判定し、矛盾を見つける
コードに書かれていない業務ルールや経緯がある	コードだけでは答えられない	既存の資料や業務ルールを取り込んで補う
使う人の質問は、日々変わる	答えられない質問が埋もれる	使う人からの指摘を受け付け、内容を追加・修正する

聞き方は2通りあります。

手軽な質問は、質問用のBOTに：業務や企画の担当の方が、画面や業務ルールを自然な言葉で質問できます。確かめた仕様だけを根拠にするので、誤った答えが出にくい形です。
込み入った質問は、開発者が使うAIに：開発者が普段使っているAIに、確かめた仕様を渡して、コードと照らし合わせながら答えさせます。改修の前に、関係する機能や影響範囲をすばやくつかめます。

まずは手軽な質問用のBOTから始め、必要に応じて開発者向けの使い方へ広げるのがおすすめです。

人にも、AIにも効く仕様。　プレスマン（弊社）の検証では、システム全体を説明する仕様がないと、開発者が使うAIにコードについて質問しても、実用になる答えは返ってきませんでした。確かめた仕様を加えると、答えの質がはっきり上がりました。正しい仕様は、人が読むためだけでなく、社内のAIや外部のAIに自社システムのことを答えさせるための土台にもなります。

プレスマンは、改修そのものの品質をAIの多重レビューと独自ツール（DeltaLint）で守り、仕様解説BOTで「何がどう変わったか」をいつでも説明できる状態に保ちます。

5. まずは1つのシステムで、小さく試す

ステップ1：ヒアリング: お困りごとと対象のシステムを伺い、試す範囲を決めます。

ステップ2：トライアル: 1つのシステムで仕様解説BOTを作り、想定している質問への答えの質を一緒に評価します。

ステップ3：本格導入: 既存の資料やコードにない業務ルールも取り込み、範囲と網羅性を広げます。

ステップ4：継続運用: リリースのたびに確認と更新を繰り返し、仕様を最新に保ちます。

ご用意いただくもの

対象システムのソースコードと、リポジトリの読み取り権限
仕様や答えの確認にご協力いただける窓口の方（1名から）
リリースの時期と変更内容の共有

古い仕様書や設計書、業務ルール、「こんなことを聞きたい」という質問の例があると、答えの質がさらに上がります。コードをお持ちでないシステム（パッケージなど）は、ご相談ください。

6. 事例：大手メディア向け業務システム

ある大手メディアの業務システムでは、改修を重ねるうちに、上流の工程で仕様がブラックボックス化（更新頻度が非常に高いために、仕様書の最新化と関係者間の認識共有が複雑化）していました。毎月多くのアップデートを行う中で、お客様が改修の要求をまとめるときに、今の仕様を確かめにくい（コミュニケーションが複雑化している）状態でした。

そこで、AIでコードから仕様を抽出し、リリース毎に内容の正誤を検品の上、質問できるBOTとしてお客様に提案しました。これにより、最新の仕様をお客様と常に共有可能（お客様はBOTに確認するだけ）になり、お客様側での要求仕様の作成業務が大幅に効率化されることになりました。