AI活用で設計書作成の概念が変わる：開発段階と理解段階での資料形式の分離を提言
本記事は、システム開発における「設計書」という概念について再考したものであり、従来の単一形式（Word, Excelなど）にこだわる必要はないという視点を提供している。筆者は、設計書には大きく分けて二つの役割があると考えた。
一つ目は、「合意のための設計書」（作る前）。この段階では、関係者間の認識合わせや承認を得ることが目的であるため、コメントや修正指示が容易なWord、Excel、PDFなどの従来型のクラウド形式が最も適していると述べている。これはシステムを正確に表現することよりも、人間同士のコミュニケーションツールとしての役割が大きいからだ。
二つ目は、「理解のための設計資料」（実装後）。これまではMarkdownなどエンジニア向けの形式で作成されることが多かったが、筆者はAI（Codex）を活用し、完成したコードを読み込ませることで「HTML一枚」のインタラクティブな資料を作成できることに着目した。このHTML資料は、アプリの構成、主要機能、データフローなどを視覚的に整理しており、単に読むだけでなく「見る」ための設計資料として非常に有用であると評価している。
結論として、筆者は設計書をこれら二つの役割に明確に分離することを提唱し、開発前後の最適な形式や作成プロセスを変えるべきだと主張している。特に実装後の理解資料については、AIがコードから構造を整理し、人間にとって最も理解しやすいインタラクティブな形で出力する手法が、今後の主流となる可能性を示唆している。
背景
従来のシステム開発では、設計書は単一のドキュメント（WordやPDFなど）に全ての情報を網羅することが一般的でした。しかし、情報量の増大と複雑化に伴い、この「全てを一つの資料にまとめる」という手法が非効率となり、情報の取捨選択や視覚的な理解が課題となっていました。
重要用語解説
- インタラクティブな設計資料: 単なる静的なテキストではなく、ユーザーの操作（クリックなど）によって情報が表示されたり展開したりするWeb形式の資料。システム全体像を動的に把握しやすくする。
- Markdown: 軽量マークアップ言語の一つで、プレーンテキストに近い形で構造化された文書を作成できる。Gitでの管理や差分確認が容易なため、エンジニア間で広く利用される。
- Codex: OpenAIなどが開発した大規模言語モデル（LLM）の名称。本記事では、このAIにコードを読み込ませることで、設計資料の自動生成・構造化を行う技術的な根拠として使用されている。
今後の影響
本提言は、システム開発におけるドキュメンテーションプロセスを大きく変革する可能性を持つ。今後は、開発フェーズ（合意）と運用フェーズ（理解）で最適なツールや形式が使い分けられ、AIによる自動生成・視覚化が標準的なワークフローとなることが予想される。これにより、設計書作成の工数削減と、システムの初期理解度の向上に貢献するだろう。