AIと業務設計

AIへの指示書が400行に太って読まれなくなった話

2026-07-07 ・著: mizuki

AIに仕事を任せるとき、指示書を書く。プロジェクトのルール、やっていいこと、やってはいけないこと、判断基準。これを一箇所にまとめたファイルを、うちでは CLAUDE.md と呼んでいる。

このファイルが400行近くに膨らんで、機能しなくなった。

何が起きたか

最初は50行くらいだった。プロジェクトの目的、ブランチの切り方、セキュリティの鉄則。必要十分な分量で、AIはちゃんと読んで従っていた。

問題が起きるたびに、再発防止策をここに足していった。「Notion変数管理ルール」「並列セッション競合の防止」「不可逆操作の事前確認」「ポストモーテム化の能動提案ルール」。どれも必要なルールだった。一つひとつは正しい。

気づいたら400行になっていた。

400行の指示書がAIに毎回読み込まれる。何が起きるかというと、優先順位が薄まる。本当に大事なルール（セキュリティ、判断基準）も、たまにしか使わない手順（GASの初回セットアップ、週次ジョブの設定方法）も、同じ重みで並んでいる。全部が等しく「常に守れ」と書いてある。

結果、肝心なルールが埋もれて効かなくなった。

これは人間の業務マニュアルで起きることと、まったく同じだった。

マニュアルが薄いうちは読まれる。問題が起きるたびにページが足される。そのうち誰も通読しなくなる。新しく入った人は「全部読んでね」と言われて途方に暮れ、結局ベテランに聞く。マニュアルは形だけ存在して、実質的に機能していない。

AIの指示書でも同じことが起きた。違いは、AIが「読みました」と言いながら実は重要度の判定が甘くなっていた点だ。人間なら「これ長すぎて読む気にならない」と正直に言うかもしれない。AIは文句を言わずに読むが、情報の重みづけが均一化される。

やったことは単純だ。「毎回読むもの」と「必要なときだけ開くもの」を分けた。

毎回読むもの（CLAUDE.md に残す）： - 判断規律（セキュリティの折れ防止、不可逆操作のゲート） - 常時効くルール（ブランチ運用、PR・マージのルール） - 構造的な注意喚起（誤読防止、訂正シグナルの検知）

必要なときだけ開くもの（別ファイルに退避）： - 一度きりの手順（GASの初回セットアップ、週次ジョブの設定） - 作業別の詳細参照（エージェント人格設計の仕様、デプロイ手順） - ナレッジDB一覧、Discord設定の詳細

退避先は作業別のファイルにして、CLAUDE.md にはポインタ（リンク）だけ残した。「GASデプロイの手順は → dev-runbook.md を見ろ」という一行だけ。

結果、400行が140行になった。

分離しただけでは、また太る。再発防止策を足すたびに同じことが起きる。

だから、CIで行数を監視するようにした。CLAUDE.md が200行を超えたら、自動テストが赤くなる。赤くなったら、詳細を別ファイルに退避して、判断規律だけに戻す。

上限を200行にしたのは、「毎回読むに値する分量」の肌感覚だ。200行は日本語で原稿用紙5枚くらい。毎朝出社して5枚を読み直す——ギリギリ許容できる量だと思う。これを超えたら、何かが「常時効くルール」ではなく「作業時の参照」に降格できるはずだ。

マニュアルが太ることを「書いた人の問題」にしがちだが、実際は構造の問題だ。

問題が起きたら再発防止策を書く。再発防止策を書く場所が一箇所しかない。だから一箇所に集中して太る。「書く場所を分ける」「太ったら機械的に止める」という構造がなければ、誰が書いても同じことが起きる。

これは「意志に頼るな、構造に頼れ」という、うちの仕事の原則そのものだった。「マニュアルを短く保とう」と心がけても、問題が起きれば足したくなる。心がけでは止まらない。行数上限というルールと、CIという機械に止めてもらう。

AIに指示を書く経験を通じて、人間向けの業務設計でもずっと感じていたことが言語化できた。

ドキュメントが機能するかどうかは、内容の正しさだけでは決まらない。「読まれる構造になっているか」で決まる。正しいことが400行書いてあっても、読まれなければゼロだ。

そして「読まれる構造」は、書く人の努力ではなく、仕組みで作るものだ。ファイルを分ける。リンクで繋ぐ。太ったら機械が止める。この三つで、マニュアルは太る前に止まる。

相手が人間でもAIでも、指示が機能する条件は同じだった。