ここ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が読むドキュメント」

になったことで、ドキュメントの正確性の重要度はむしろ上がったとも言えるかもしれません。