設計書の自動生成ツールを個人開発しました｜AIに設計書づくりも奪われる時代に

設計書。この二文字を見ただけで、胃が痛くなる人は多いと思います。

書くのに時間がかかる。書いても、誰も読まない。それなのに、ないと確実に困る。システム開発の中で、いちばん報われにくい仕事の筆頭が設計書ではないでしょうか。

その設計書づくりを、AIにやらせるツールを作りました。画面のスクリーンショットやソースコードを放り込むと、基本設計書や詳細設計書に載る資料が、Excelになって出てきます。

完成して、正直に言います。うれしい。そして同時に、ちょっと悲しい。

マンチーは、上流工程で10年以上、設計書を書いてきた人間です。その仕事を、自分の手でAIに渡してしまったのですから。でも、これは時代の流れで、しょうがない。それなら、奪われる側にいるより、奪うAIを使いこなす側に回ろう。そう決めて、最後まで作り切りました。

今日は、このツールで何ができるのか、中身を全部書きます。

設計書がない現場は、本当に地獄です

まず、なぜ設計書にこだわるのか。その話をさせてください。

システムは、作って終わりではありません。数年たつと、必ずリプレイス(システムの作り替え)の日が来ます。

担当になったSEは、まず現状を知ろうとします。「現行の設計書を見せてください」。そこで返ってくる答えが、「ありません」だったら。

画面を一つずつ触って、挙動を確かめる。ソースコードを読み解いて、項目の意味を推測する。作った人は、とっくに辞めている。目の前にあるのは、動いているシステムと、誰もその全体を説明できないという事実だけです。

SEは、路頭に迷います。調べるだけで時間が溶けていき、開発の人件費は一気に跳ね上がります。

たとえば、エンジニア4人が3か月かけて、現行システムの調査をするとします。人月90万円で計算すると、4人×3か月×90万円で、1,080万円。設計書が残っていれば、払わなくて済んだかもしれないお金です。

マンチーは、これを何度も経験してきました。「現状の設計書がないのに、どうやってやるんだ！」と叫びたくなったことは、数えきれません。大変な苦労をしました。

だから、はっきり言えます。設計書は、システム開発に絶対に必要です。

それなのに、現場では後回しにされます。納期が迫る。テストが終わらない。設計書は「あとで直す」の山に埋もれていく。そして、動いているけれど誰にも説明できないシステムが、また一つ生まれます。

設計書づくりが、AIに奪われていく

設計書を書く仕事は、AIがもっとも得意とする種類の仕事です。画面を見て、ソースを読んで、項目を拾って、表にまとめる。ルールが決まっていて、量が多くて、人間が飽きる。

基本設計書や詳細設計書をつくる作業は、上流工程の一部です。その一部が、これからAIに奪われていきます。悲しいですが、もう始まっています。

だったら、AIに任せてしまおう。ただし、いい加減な設計書では意味がありません。現場で使えるレベルまで作り込む。そう決めて、作ったのがこのツールです。

作ったのは、3つのモードを持つ設計書の自動生成ツール

ツールには、3つのモードがあります。画面系の設計書、DB系の設計書、そしてレガシーコードの解読です。まずは、画面系とDB系から説明します。

モード1：画面系設計書 ―― スクリーンショットから、画面の設計書一式を

画面系の設計書は、システムにある画面の数だけ作らなければなりません。ログイン画面、一覧画面、登録画面、確認画面、完了画面。画面が増えるたびに、画面レイアウト、項目定義、遷移、入力チェックと、同じ種類の設計書が何枚も必要になります。一枚一枚は単純でも、数がそろうと、工数は恐ろしいことになります。ここを、AIに任せられるのは大きいです。

入れるものは、画面のスクリーンショット(PNG・JPG・WebPに対応)です。これだけで動きます。もしあれば、その画面のソースコード(HTML・PHP・Blade・Twig・ERB・JSP・Vue・JSXなど)も一緒に入れると、精度が上がります。「この画面はログイン後のダッシュボードで、権限が2種類あります」といった補足も、文章で添えられます。

出てくるものは、次の5つです。

• 画面レイアウト図：画面上の項目を一覧にしたもの。種別、表示桁数、入力桁数、既定値、入力例、表示書式まで入ります。

• 画面項目定義書：項目ID、データ型、桁数、必須かどうか、初期値などをまとめたもの。

• 画面遷移図：この画面に来る前と、この画面から行ける先を、図にしたもの。

• 入力チェック仕様書：プログラマー向けの資料です。必須、形式、桁数、範囲、項目同士の関係といったチェックの種類と、エラーメッセージが並びます。

• 自己チェック：AIが、自分で作った設計書を、自分で見直した結果です。

こだわったのは、現場の人が「そこ、見てほしい！」と思うところを、AIが拾ってくれることです。

• 表示桁数は、画面の見た目(CSSの幅)から。入力桁数は、入力欄の上限(maxlength)から取ります。表示できる幅より、入力できる文字数のほうが多い項目には、「見切れ仕様」の警告を付けます。画面に入りきらない文字が出る、というバグの種を、設計の段階で見つけられます。

• 読み取り専用の項目、入力できない項目、ほかの入力で値が変わる項目、条件によって有効・無効が切り替わる項目には、「要確認」の印を付けます。ソースだけでは仕様を断定できない部分を、AIが勝手に決めつけないようにしています。

• ボタンを押すと、ほかの項目の値が自動で入る画面。この動きは、備考欄に「押下で〇〇を自動セット」と書かれます。

• 最初に、画面上の全項目を漏れなく洗い出した「確定項目リスト」を作ります。そして、すべての設計書が、この同じリストを元に作られます。設計書ごとに項目がズレる、という、人間がやってもよくやらかす事故を防ぐためです。

• 画面に表示されていない値は、「-」にします。ソースがなく、画面から推測した部分には「(推測)」と書きます。AIに、もっともらしい嘘を書かせないための工夫です。

モード2：DB系設計書 ―― SQLのリバースエンジニアリング。ソースが読めなくても、DBの設計図が手に入る

既存のデータベースから、設計書を逆向きに起こす。いわゆる、リバースエンジニアリングです。

ソースコードを読めない人にとって、これは画期的だと、マンチーは思っています。プログラムの中身がわからなくても、データベースの構造さえ書き出せれば、テーブルの設計書とER図が出てくるからです。システムの「データの置き場」が、一枚の図でわかる。リプレイスの見積もりでも、業務の人との打ち合わせでも、この図が一枚あるだけで、話が一気に進みます。

入れるものは、SQLダンプ(データベースの構造を書き出したファイル)です。サーバーの設定ファイル(nginx・Apacheなど)も、あれば一緒に入れられます。対応しているデータベースは、MySQL、PostgreSQL、Oracle、SQL Server、SQLite、DB2です。

出てくるものは、次の4つです。

• テーブル仕様書：テーブルごとに、列の名前、型、制約などを整理したもの。

• ER図：テーブル同士の関係を描いた図です。

• 構成相関図：Webサーバー、アプリケーション、データベースが、どうつながっているかを描いた図です。

• 主要処理のシーケンス図：ログイン、データ登録、データ取得といった代表的な処理で、誰が誰に何を頼むのか、やり取りの順番を描いた図です。

サーバーの設定ファイルがない場合は、SQLの内容から構成を推測して図を作ります。もちろん、推測した部分はそうとわかるようにしています。

UMLの一部の図にも対応しています

UML(システムの構造や動きを、図で表すための世界共通の書き方)の図も、一部ですが出せます。UMLは、UML 2.xで14種類の図が定義されていて、システムの「構造」を表す図と、「振る舞い(動き)」を表す図に分かれます。設計書で使われる代表的な図は、次のとおりです。

• クラス図：データや部品の構造と、その関係を表す図。

• シーケンス図：誰が誰に何を頼むのか、やり取りの順番を表す図。

• アクティビティ図：処理の流れを表す図。

• ステートマシン図(状態遷移図)：状態が、何をきっかけにどう変わるかを表す図。

• ユースケース図：利用者とシステムのやり取りを表す図。

このツールが出す図は、次のとおりです。

• シーケンス図：DB系のモードで、ログイン、データ登録、データ取得といった代表的な処理を図にします。UMLの代表的な図です。

• 処理フロー図：レガシーコード解読で、プログラム全体の流れを図にします。UMLのアクティビティ図にあたる役割の図です。

• 画面遷移図：画面系のモードで、画面の移り変わりを図にします。状態遷移図(ステートマシン図)に近い図です。

• ER図：UMLそのものではありませんが、データの構造を表す図として、クラス図と並ぶ設計書の定番です。

どの図も、Mermaidとdraw.ioの形式で受け取れます。UMLを描き慣れた人が、そのまま手直しして、自社の設計書の形に仕上げられます。

COBOLの案件は、ごくまれ。でも、いざ発生すると、人が集まらない

ここからは、SEの方にとくに読んでほしい話です。

COBOL(銀行や基幹システムなどで、古くから使われてきた言語)の案件は、ごくまれにしか発生しません。ところが、いざ案件が出ると、スキルを持った人が集まらない。案件が少ないから、人が離れていく。人が離れたから、いざという時に足りなくなる。現場にいると、そんな悪循環を感じます。

これは、マンチーの実感だけではありません。経済産業省のレガシーシステムモダン化委員会の総括レポート(2025年5月)では、レガシーシステムが問題になる要因の筆頭として、古い技術に対応できる技術者が高齢化・離脱し、要員の確保が難しいことが挙げられていると報じられています。リクルートの調査(2025年2月発表)では、登録されたスキルの上位10言語にCOBOLが入っていたのは、50歳以上の層だけだったとのことです。

学ぶ入り口も、狭くなっています。基本情報技術者試験の午後試験では、COBOLの出題が2019年秋期で終わったと報じられています。一方で、メインフレーム(大型の汎用コンピューター)については、富士通が2022年に、販売を2030年度に終息し、保守を2035年度に終了する計画を発表しています。いつかは、必ず次の基盤へ移す日が来ます。

COBOLができる人は減っていく。でも、COBOLで動くシステムは、まだ動いている。そして、そのシステムには、設計書がない。リプレイスの案件が来て、急いで集められたSEが最初にやるのは、ソースを読んで、このプログラムが何をしているのかを解き明かす作業です。

だからこそ、レガシーコード解読のモードを、いちばん作り込みたかったのです。

モード3：レガシーコード解読 ―― ソースを、読める資料に変換する

対応している言語は、COBOL、PL/I、RPG(AS/400向け)、Perl、VBA、Fortran、クラシックASP、アセンブリなどです。上のどれでもない場合は、AIが言語を自動で判定します。

入れるものは、メインのソースコードです。関数の定義書があれば一緒に入れられますが、なくても大丈夫です。ソースから推測して解読します。

出てくるものは、次の4つです。

• プログラム概要：何をするプログラムなのか。入力データと出力データは何か。

• 関数・段落の解説：COBOLなら段落(PARAGRAPH)、PerlならSUBといった単位で、処理の概要、入力、出力を表にまとめます。処理の内容を日本語で記した、処理記述書にあたる資料です。

• 処理フロー図：プログラム全体の流れを、図にします。

• 変数・定数の一覧：COBOLなら、データの定義を書く部分(WORKING-STORAGEやFILE SECTION)を元にまとめます。

COBOLのソースを入れると、「何をしているのか」が日本語の資料になって返ってくる。COBOLに詳しくない人でも、まずこの資料を読めば、リプレイスの議論の席につけます。

ただし、AIの解読は、あくまで下書きです。COBOLがわかる人によるレビューは、必ず必要です。それでも、白紙のソースの山の前で固まる時間が、なくなる意味は大きいと考えています。

出力は、「現場の言葉」で渡す

作った設計書は、ブラウザの画面で確認できます。そこから、Excelでダウンロードします。全シートを一括でも、セクションごとでも選べます。

Excelにこだわったのには、理由があります。開発の現場は、Excel一本のところが多いのです。AIがどれだけ立派な設計書を出しても、現場が使い慣れた形で出てこなければ、使われません。

とくに悩んだのが、画面遷移図でした。最初は、Mermaid(テキストで図を書く形式)のコードが、そのままExcelのセルに入っていました。図になっていないのです。ところが、Mermaid形式を覚えてください、とは、現場には言えません。

「大手企業の開発現場って、新しいものを取り入れない。これだと、また人間が手を加えて作り直すことになる。せっかくシステムがあるのに、なんやねん！ってことになる」

そう考えて、図はExcel、Mermaid、draw.io(図を編集できるツールで開ける形式)の3つの形式で受け取れるようにしました。ボタンごとに、どんな形式なのかを小さな文字で書いてあります。

遷移図の矢印には、どのボタンやリンクで遷移するのか、という情報を必ず付けます。現場で見る遷移図は、そうなっているからです。AIは、ここを省略しがちなので、省略禁止と指示しています。

ファイル名は、モード、セクション名、元のファイル名、日付の順で自動で付きます。何を元に、いつ作った設計書なのか。あとから探すときに迷いません。

作りながら、何度も叫びました

このツールは、AIに作ってもらいながら、マンチーが何度もダメ出しをして育てました。そのダメ出しの一部を、書いておきます。

• 最初に出てきた結果は、Excelではなく、ただの文字の羅列でした。「Excelダウンロードは実装してないの？」と聞いて、気づきました。

• Excelに、交互の行に色を塗る縞模様を付けたときは、「これは要らないよね」と言いました。見やすそうに見える飾りは、作業する人にとっては、むしろ邪魔になります。いまは、ヘッダーとグループ行だけに色が付く、最小限のデザインです。

• 結果を、ダッシュボードのようにカードで並べたときは、「作業者はExcelの形式が見たいだけで、ダッシュボードなんてどうでもいい」と言いました。いまは、目次と本文だけの、すっきりした画面です。

• 既定値の読み取りでは、「既定値、違う。画面上の既定値だから『年/月/日』が答え」とやり直しました。HTMLのvalue属性を読むだけでは、企業の本番画面には通用しません。実際の画面では、valueは空で、あとからJavaScriptやサーバーが値を入れるからです。HTMLのvalue属性を信じてはいけない。これは、動かしてみて初めて気づいたことでした。そこで、画面のスクリーンショットから見たまま読み取る方式に変えました。

• 画面レイアウト図と画面項目定義書で、項目の数や名前が違っていることがありました。「同じ画面から取ってきているのだから、数も見た目も同じにならないといけないよね」。この一言から、確定項目リスト方式と、自己チェックが生まれました。AIが、自分で矛盾を見つけて直す仕組みです。

• 読み取り専用の項目に、印が付かない事故もありました。原因は、画面レイアウト図のプロンプトには指示があったのに、画面項目定義書のプロンプトには書き漏れていたことでした。AIの出力は、確かめるたびに本物のAIを呼び出す必要があります。1回1〜2分の生成待ちを何度も繰り返し、途方もない時間を使いました。

設計書は、ただ作ればいいものではありません。使う人の「そこじゃない」「それ、現場では違う」を、一つずつ潰していって、初めて使えるものになります。

使い方は、3ステップです

1. ログインする(このツールは、以前作ったSSO認証kitを採用していて、ログインした人だけが使えます)

2. スクリーンショットやソースコードを、ドラッグ＆ドロップで放り込む

3. 「設計書を生成する」ボタンを押して、Excelなどでダウンロードする

AIの呼び出しは、AWSの東京リージョンを経由しています。使った回数は、記録して管理する仕組みも入れました。AIは使うたびに利用料がかかるので、コストの見える化は最初から入れておきたかったのです。

正直に書いておく、限界

ここまで書いてきましたが、AIの作る設計書が、そのまま完璧だとは言いません。

• 推測が混じった箇所には「(推測)」、確定できない箇所には「要確認」と印が付きます。この印のところは、人間が確認してください。AIは下書きを作ってくれる相棒で、最終チェックは人間の仕事です。

• 画面系は、1画面ずつの生成です。画面の数だけ、投入を繰り返すことになります。また、一度に読み込めるHTMLソースの長さにも上限があり、約1万5000文字までです。大きな画面は、分けて入れる必要があります。

• スクリーンショットだけで入れた場合は、ソースを入れた場合より精度が下がります。入れられるなら、ソースも一緒に入れてください。

• UMLのすべての図に対応しているわけではありません。クラス図やユースケース図などは、いまのところ出力していません。出せるのは、上に書いた図です。

• 画面の項目が、データベースのどのテーブルのどの列から来ているのか。この紐付けは、HTMLのソースだけでは判断できません。画面系とDB系を一緒に投入して、自動で紐付ける機能は、これからの課題です。

それでも、ゼロから人間が書くのに比べれば、スタート地点がまるで違います。白紙の前で固まる時間が、なくなります。

このツールを、開発に携わるすべての人に使ってもらいたい

設計書が未完成のままのシステムを抱えている会社。数年後のリプレイスを控えている会社。設計書のないシステムを、引き継ぐことになったSE。COBOLの案件が突然降ってきて、途方に暮れているチーム。プロジェクトを任されたものの、資料が何もないPM。ソースコードは読めないけれど、システムの中身を知りたい業務の担当者。自分で作ったアプリの設計書が、頭の中にしかない個人開発者。

開発に関わる人なら、誰でも、一度は設計書で苦労しているはずです。

設計書を人の手で書く時代は、終わりつつあります。でも、設計書が必要な時代は、終わりません。むしろ、AIがコードを書く時代になるほど、「何をどう作ったのか」を残しておく設計書の価値は上がっていくと、マンチーは思っています。

書く手間は、AIに任せましょう。数年後に、路頭に迷うSEをつくらないために。

【この記事が興味深かった方は、以下記事もおすすめです】

＜おすすめ記事①＞
設計書づくりのほかにも、面倒な作業を自分で自動化してきた、7つの「勝手にやってくれる」仕組みを知りたい方はこちら。

＜おすすめ記事②＞
設計書を書く側にいた上流の人間が、なぜAIで実装側に戻ってきたのか。マンチーの自己紹介はこちら。

＜おすすめ記事③＞
設計書も「あとで直す」の山に埋もれていく。その怖さを、国のシステムの漏洩から考えた記事はこちら。

#設計書 #AI活用 #システム開発 #リプレイス #レガシーコード #COBOL #リバースエンジニアリング #UML #ITエンジニア #バイブコーディング #munchie ＃マンチー