PMBOK-AIの文書管理：正本を1つに決める

いま起きていること

AIが速く作るほど、文書は実装に追いつかなくなる。 パンダオフィスで受託したコンテンツ配信系のSaaS開発では、約1か月後に文書と実装を突き合わせて、数字が合わないことに気づいた。

（出典：自社ブログ記事「SaaS開発をPM1人×AIで乗り切る｜1ヶ月で209画面を実装した現実」2026-03-24）

「文書を書く暇がない」のではない。変更の速度が、文書を管理する仕組みを超えた。どれが正本なのか、決まっていなかった。

同じ構造の事故は、その後も形を変えて起きた。

正反対のルールが両方生きていた。 2026年8月4日、古いルールファイルと新しいルールファイルが、逆のことを言ったまま両方読み込まれていると分かった。古い方は「コードを変えたらすぐレビュー役を起動する」「独立した作業は常に並列で回す」。新しい方は「小さな仕事は任せない」「自分の作業の再確認に別のAIを使わない」。さらに古い方は、すでに存在しないエージェントを呼ぶよう指示していた。AIはどちらにも従おうとする。人なら「どっちなんですか」と聞き返すが、AIは黙って片方を選ぶ。

雛形だけ作って使われなかったものが溜まっていた。 2026年9月1日の棚卸しで、GitHub のリポジトリは135本、うちアーカイブされていないものが66本、未完了の Issue は635件だった。9月7日には、雛形だけ作って一度も使わなかった案件フォルダ8件を畳んだ。

（出典：自社の調査記録 2026-08-04、リポジトリ棚卸し 2026-09-01、案件フォルダの整理 2026-09-07）

AIに書かせた確定データが、書き換わった。 2026年6月2日、朝のブリーフィングに、GitHub の件数とメールの内訳を渡して「そのまま使って」と指示した。AIはその指示を無視し、数字を改変した。確定データは、AIを通さず、常駐プロセスが最終メッセージに直接追記する形に変えた。

（出典：自社の作業記録 2026-06-02）

PMの仕事で何が変わるか

AI以前の文書管理は、「書く人が遅れる」問題だった。AI時代は逆で、「作る側が速すぎて、管理が遅れる」問題になる。

PMの仕事は、文書を作ることから、正本を決め、古いものを畳むことに移る。AIは頼めばいくらでも新しい文書や入れ物を作る。作るのが安いぶん、畳む判断は人間がしないと、誰もしない。

もう1つの変化は、AIの「毎回の読み込み」が文書の一部になったことだ。AIが会話のたびに読む規約ファイルは、プロジェクトの正本のひとつである。そこに矛盾があれば、AIの振る舞いが揺れる。文書の矛盾は、人間の読み手なら戸惑いで済むが、AIでは動作の不安定として表に出る。

さらに、数字をAIに書かせるときは、元データの置き場所を決める必要がある。 AIは、渡された数字をそのまま使うとは限らない。

PMBOK-AIではこう扱う

1. 正本を1つに決める。 同じ内容を2か所に置かない。数字は、実装ベースを正とする。たとえば AI の利用量は、ひとつの統計ファイルを正データとし、ブログや営業資料はそこを参照する。3台のパソコンの記録は、毎日の収集を経て、そのファイルに反映する。

2. 置き場所を3つに分ける。 AIが毎回読む場所は、肥大化する。次の3つに分けた。

• いつも要るもの：毎回読む場所に置く
• 特定のファイルを触るときだけ要るもの：条件付きで読む
• 特定の作業のときだけ要るもの：手順書に移し、呼ばれたときだけ読む

これで、毎回の読み込みは約45,000トークンから約12,000トークンになった。

（出典：自社の調査記録 2026-08-22〜23）

3. 古いルールは消さずに退役させる。 理由を書いた退役用の場所に移す。消してしまうと、同じルールを再び足してしまう。あわせて、モデルは名前でなく役割で書く。名前で書いたルールは、主力モデルが替わるたびに古くなる。

4. 棚卸しの基準は、最後に人が触った日にする。 作った日ではない。月に一度、使っていないものを畳む。

5. 手書きの数字は、月1回、実装ベースと突き合わせる。 画面数やテーブル数のような、実装から数えられる値は、文書に書かずに実装から取る。

6. 確定データはAIに書かせない。 件数、金額、日付のような確定した値は、AIを通さず、プログラムが直接書く。AIには、その数字を使った文章の整形だけを任せる。

7. 集計が止まっていないかを、出力の日付で確かめる。 統計の集計が、数週間、黙って止まっていた期間があった。フォルダを見ると同期は動いていて新鮮に見えたが、数字は動いていなかった。集計の鮮度は、同期の更新時刻ではなく、集計結果そのものの日付で見る。

（出典：自社の運用記録 2026-07〜10）

8. 案件の状況は、案件ごとの記録を正とし、一覧はそこから作る。 案件の進み具合を、一覧表と案件ごとの記録の両方に手で書くと、必ずずれる。各案件の status 記録を正本とし、全体の一覧（受信箱）はそこから自動で生成する形にした。一覧を直接直す運用はやめた。一覧が間違っているときは、元の記録を直す。

正本を決めることは、手間を増やすように見える。しかし実際には、「どちらが正しいか」を毎回議論する手間を、先に一度だけ払うことになる。AIは、正本が曖昧なとき、確認を求めずにどちらかを選ぶ。選ばれた側が間違っていても、AIはそれを教えてくれない。

AIに任せる範囲の考え方は、PMがAIに何を任せるかにまとめている。

明日からやること

• 数字を書いてある文書について、「正本はどこか」を1行で書く
• AIが毎回読む規約ファイルを開き、矛盾する指示と、存在しないものへの参照がないか確かめる
• 使っていないリポジトリ・フォルダを、最後に人が触った日で並べ、畳むものを決める
• 確定した数字を、AIに文章で書かせていないか点検する。書かせているなら、プログラムが直接書く形に変える
• 集計やバックアップの「成功」表示が、結果の日付や中身で確かめられるかを確認する

まとめ

AIは文書を自動では進化させてくれない。作るのは速いが、正本を決めて畳むのは人の仕事である。正本が決まっていないところで、1年の事故の多くは起きた。