ここ1〜2年で、LLMを使ったドキュメント生成が非常に簡単になりました。
例えば
- コードから仕様書を生成する
- READMEや設計書を自動生成する
- 既存ドキュメントを整理してくれる
といったことが、ほぼワンプロンプトで可能です。
これは非常に便利です。
しかしプロジェクトで使い始めると、いくつか構造的な問題が見えてきました。
この記事では、LLM時代のドキュメント管理の懸念点を整理します。
1. Git管理すると仕様・実装と乖離していく
多くのプロジェクトではドキュメントを
docs/
のようにしてGit管理します。
しかし現実にはこうなりがちです。
仕様変更 → コード修正 → ドキュメント更新忘れ
つまり
- 実装
- 仕様
- ドキュメント
の3つが簡単に乖離します。
LLMによってドキュメント作成は簡単になりましたが、更新が自動化されたわけではありません。
そのため
「最初は綺麗だったドキュメントがだんだん信用できなくなる」
という昔からの問題はそのまま残っています。
2. LLMが古いドキュメントを信じる問題
LLM時代になって新しく出てきた問題があります。
それはLLMが古いドキュメントを信じるという問題です。
例えばRAGなどで
docs/
を読み込ませている場合、
- 実装は変わっている
- 仕様も変わっている
- しかしドキュメントが更新されていない
という状態だと、LLMは古い情報を「正しい仕様」として扱います。
つまり
・人間は「このドキュメント古いな」と気づく
・LLMは普通に信じる
という問題が発生します。
これは従来よりも危険です。
なぜならLLMは自信満々に間違うからです。
3. 総括ドキュメントは更新箇所が分からなくなる
ドキュメント構造にも問題があります。
例えば
仕様A → docA.md
のような 1対1対応 なら更新は簡単です。
しかし実際のプロジェクトでは
- 全体設計
- アーキテクチャ概要
- 機能一覧
- システム全体仕様
のような 総括ドキュメント が作られます。
この場合、
仕様Aを変更
↓
docA.mdは更新
↓
全体設計も影響する？
↓
機能一覧も？
↓
アーキテクチャ図も？
となりどのドキュメントを更新すればいいのか人間でも分からなくなります。
結果として
とりあえず放置
が発生します。
4. 最終的にLLM更新コストが増大する
ドキュメントが増えると、最終的にこうなります。
仕様変更
↓
全部のドキュメントを確認する必要
つまり
全仕様 vs 全ドキュメント
または
全実装 vs 全ドキュメント
という関係になります。
この状態になると、
LLMにまとめて更新させる
という運用になりがちです。
しかしこれは
- トークン量が増える
- コンテキストが巨大になる
- LLM利用コストが増える
という問題を生みます。その結果、
LLMによってドキュメント作成は簡単になったが
ドキュメント維持コストはむしろ増える可能性がある
という逆説が起きます。
まとめ
LLM時代のドキュメント管理の問題を整理すると
- Git管理しても実装と乖離する
- LLMが古いドキュメントを信じる
- 総括ドキュメントは更新箇所が分からない
- 最終的にLLM更新コストが増大する
という構造的な問題があります。
LLMでドキュメントを書くコストは劇的に下がりました。
しかし、ドキュメントを正しく保つコストは、まだほとんど解決されていません。
むしろ
「LLMが読むドキュメント」
になったことで、ドキュメントの正確性の重要度はむしろ上がったとも言えるかもしれません。