---
title: "ドキュメントは読まれないのではなく更新されない"
description: "手順書が現場で信頼されなくなる理由を、読まれないことではなく、運用差分が反映されないこととして整理したメモ。"
lang: "ja"
canonical: "https://llm-lab.dev/posts/docs-are-not-updated-note/"
source: "https://llm-lab.dev/posts/docs-are-not-updated-note.md"
publishedAt: "2024-07-02"
updatedAt: "2024-07-02"
category: "技術メモ"
tags:
  - "documentation"
  - "operations"
  - "workflow"
---

# ドキュメントは読まれないのではなく更新されない

> [!NOTE]
> この記事で確認したこと: 手順書が読まれない理由を「現場が読まないから」だけで片づけると、例外対応の判断が手順書へ戻らない問題を見落とします。運用で発生した差分を1行でも戻す仕組みを作る方が、完璧な初期ドキュメントよりも手順書の信頼を保ちやすくなります。

手順書を書いても読まれない、という話はよくあります。自分も以前はそう考えていました。

ただ、運用を見ていると、問題は読まれないことだけではありません。手順書が現実に追いつかなくなり、読む価値が少しずつ下がっている場合があります。

例外対応は、だいたい急に発生します。月末だけ処理順を変える、特定の取引先だけ別ファイルを見る、エラーが出てもこの条件なら進める。こうした判断はSlackや口頭で決まり、その場では問題を解決します。

しかし、その判断が手順書に戻らないと、次に同じことが起きたときにまた人を探すことになります。手順書は最初から無視されているのではなく、更新されないことで信頼を失っていきます。

```text
現場で例外が起きる
  -> その場で判断する
  -> 作業は終わる
  -> 手順書には戻らない
```

この流れを止めるには、完璧なドキュメントを作るより、差分を戻す小さい仕組みが必要です。例外対応後に1行だけ追記する、判断理由だけ残す、次回確認する項目をチェックリストにする。そのくらいでないと続きません。

AIエージェントを使う場合も、プロンプトやツール定義はすぐ古くなるはずです。運用ログから何を戻すのかを決めておかないと、きれいな初期設計だけが残り、実際の動きはまた属人化します。