マニュアルをAIに作らせる前に、更新の担当を決める

マニュアルをAIで作るとは、文章を書く手間を機械に肩代わりさせる作業ではなく、業務が変わった日にマニュアルのほうも直る状態をつくることです。この記事は、AIでマニュアルを作りたい経営者に向けて、作らせる前に決めておく「誰がいつ直すか」と、AIに渡してよい仕事の範囲を書きます。

僕はAIVESTという会社を経営していて、経営しながら自分でも毎日AIを動かしています。「マニュアル AI」で出てくる上位記事を2026年9月時点で3本読みました。型は3本ともほぼ同じで、メリット、使えるAIの種類、作成手順6ステップ、注意点、ツールおすすめN選。書かれていることは正確です。ただ、3本とも「作った後に誰がいつ直すか」が空白でした。更新に触れているのは「継続的に見直す」「変更点があれば都度更新する」という一文だけで、誰が・いつ・何をきっかけに直すのかは書かれていません。そこを埋めます。

マニュアルをAIで作るとは？減らすのは書く手間ではなく、古くなる速度

初版の生産コストは、もう問題ではない

生成AI（文章や画像を作るAI）にマニュアルを書かせると、初版は驚くほど速く出てきます。手元の断片を投げれば、見出しと手順の並んだ体裁のいい文書が数分で返ってくる。ここはもう解決済みの問題です。

問題は次です。作る速度が上がった分だけ、古いマニュアルが増える速度も上がります。以前は半日かかったから10本しかなかった。今は20本作れる。ところが直す仕組みは元のままなので、放置される文書の数だけが倍になります。

判断の基準は「今正しいか」ではなく「3か月後も正しいか」

だから、AIでマニュアルを作ると決めたときに評価すべきなのは、出てきた初版の出来ではありません。3か月後にその文書がまだ現場と一致しているかです。この基準で見ると、必要なのはツール選びではなく、更新の担当と起点を先に決めることだと分かります。

マニュアルが使われなくなる原因は、初版の出来ではない

変更が起きた日に、誰も直さない

業務マニュアルが読まれなくなる典型は、こう進みます。ツールの画面が変わる。承認のルートが1つ増える。担当者が交代して、やり方が少し変わる。そのたびに現場は自分のやり方を調整しますが、文書は誰の担当でもないので触られません。

1回のズレは小さい。ただ、これが3回4回と積み上がると、手順書に書いてある通りにやると失敗する状態になります。そうなると現場は読むのをやめ、隣の人に聞く方式に戻ります。文書は残っているのに機能していない、という一番もったいない形です。

「読まれていない」は結果であって原因ではない

このとき社内でよく出る対策が「もっと分かりやすく書き直そう」「動画にしよう」です。表現の問題として扱うと、また立派な初版ができて、3か月後に同じ場所へ戻ります。

AIに渡してよい3つの仕事と、人が手放してはいけない2つの判断

AIに渡してよいのは、この3つです

AIにできることを機能一覧で並べるのではなく、渡してよい仕事を3つに限定します。

1. 既存の断片から手順の下書きを起こす。チャットのやりとり、会議の議事録、操作画面の録画の文字起こし。すでに社内にある断片を渡して、手順の形に並べ直させます。ゼロから書かせるより速く、内容も現場に近くなります。

2. 担当者の口頭説明を構造化する。ベテランに10分しゃべってもらい、その文字起こしを渡して、前提・手順・例外に分けさせます。書くのが苦手な人でも、話すことはできます。

3. 現物との差分を指摘させる。今の手順書と、今の画面のスクリーンショットや今の帳票を両方渡して「食い違っている箇所を挙げて」と頼みます。これが3つの中でいちばん効きます。書く作業ではなく、ズレを見つける作業こそAIに向いています。人間には退屈すぎて続かないからです。

人が手放してはいけないのは、この2つです

• 正しさの最終確認。その手順で実際に業務が通るかを確定させるのは人です。AIの出力はもっともらしく間違えます。

• 例外が起きたときの判断。「この条件のときはどうするか」を決めるのは責任を持つ人の仕事で、文書化の対象は判断の結果であって判断そのものではありません。

更新が止まらない業務マニュアルの作り方。手順書の作り方を5ステップで

作る順番を変えるだけで、更新が止まる確率はかなり下がります。手順書の作り方としては、書き始める前に2つ決めるのが肝心です。

更新の起点は「気づいた人が直す」でいいのか？変更イベントに紐づける

善意に依存した更新は、必ず止まります

「気づいた人が直してください」は運用ルールに見えて、実際には誰の仕事でもありません。気づく人はたいてい忙しく、直す権限があるかも分からず、周知の手間まで見えると、そっとしておく方が合理的になります。

引き金を、業務側の出来事に置き換える

そこで、更新のきっかけを人の気づきではなく変更イベントに移します。僕が実務で使っている割り当ては4つです。

ポイントは、4つとも「業務側で必ず起きること」に紐づいていることです。ツール変更も担当交代もクレームも、放っておいても発生します。そこに更新を相乗りさせれば、更新のためだけの会議はいりません。月次の棚卸しも1本だけに絞ります。

全部は書かない。使われている手順から順に直す

上位記事は「網羅的に作る」前提で書かれていますが、捨てる基準がありません。実務では、書かない判断と、更新をやめる判断が要ります。

判断の材料はアクセスです。誰も開いていない手順書は更新対象から外して構いません。逆に毎週開かれている数本は、多少雑でも先に直す価値があります。ここを平等に扱うと、全部が少しずつ古くなります。

属人化の解消も同じで、全業務を文書化する必要はありません。その人が休んだ日に止まる業務だけを先に書く。これだけで、文書の本数は現実的な数に収まります。なお、書いた文書が探せない状態だと更新もされないので、社内で見つけられる状態は前提条件です（社内ナレッジをAIで探せる状態にする話は別記事にまとめています）。

AI向けの前提ファイルと、人向けの業務マニュアルは別物

AIに社内の前提を読ませるファイル（CLAUDE.mdのような、AIが起動のたびに読み直す指示ファイル）を整え始めた会社から、「これと業務マニュアルは一本化していいか」と聞かれることがあります。僕は分けています。

役割が違うからです。AI向けは毎回必ず読ませる制約で、短く、例外を書かず、矛盾があってはいけません。人向けの業務マニュアルは例外が起きたときに人が引く索引で、長くてよく、例外や背景こそ価値になります。混ぜるとAIには長すぎて効かず、人には抽象的すぎて読まれず、両方が使われなくなります。

関連記事CLAUDE.mdの書き方。会社の前提をAIに毎回読ませる1枚CLAUDE.mdは設定ファイルではなく、AIが毎回読み直す会社の前提を書く1枚です。僕が全社・部門・業務の3階層で運用している実物から、書く4つ・書いてはいけない4つ・非エンジニアが最初に書く3節・誰がいつ更新するかを渡します。→

僕が自分の仕組みでやっていること。正本の所在表と、追記だけの台帳

ここからは、僕が自社で毎日動かしている仕組みの実物です。AIと人が共用する運用文書ですが、古くならないための設計は業務マニュアルと同じなので、移植できる部分を書きます。

正本の所在表を1枚に固定し、矛盾したときの勝者を先に決める

僕のブログ記事ハーネス（記事を企画から検証まで回す自作の仕組み）の規約ファイルには「正本の所在表」という表があり、2026年9月18日時点で15行あります。設計計画はどこ、評価基準はどこ、声と文体はどこ、というように、何がどのファイルに書いてあるかだけを集めた表です。

そして、その上の原則にこう書いてあります。

記事の正本はローカル `articles/`。CMS(本番DB)は追従。矛盾したらローカルが正

（ブログ記事ハーネス規約ファイル 原則2・2026年9月18日時点）

2つの版が食い違ったときにどちらが勝つかを、食い違う前に決めてある。これが所在表の本体です。業務マニュアルなら「紙の掲示とサーバー上のPDFが違ったらサーバーが正」の一行を先に書いておくのと同じです。

判定は追記だけの台帳に残し、毎朝1画面で回収する

決めたことは、追記しかしない台帳に貯めます。僕の場合は各仕組みに散らばった判断を1本の検索可能な台帳に集約し、毎朝の受信箱という1枚のファイルに未判定のものだけを並べて、`判定: ____` の欄に1行書き込む運用にしています。書き込んだ内容は、あとから各ファイルへ自動で書き戻されます。

上書きせず追記だけにしているのは、「なぜ当時そう決めたか」を後から検索するためです。改訂履歴を残す理由もこれと同じで、履歴が消えると同じ議論を半年後にもう一度やることになります。

呼ばれ方と手順は、人の記憶の外に置く

もう2つ、更新が止まらない理由になっている仕掛けがあります。

1つは、使われ方そのものを文書に書くこと。僕の手元にはAIに作業手順を覚えさせた定義ファイルが2026年9月18日時点で63枚あり、うち26枚には「どういうときに使うか」と「こういうときは使わない」の両方を明記しています。使う条件と使わない条件が書いてあると、迷ったときに人が判断しなくて済みます。

もう1つは、手順を人の記憶ではなくコードに置くこと。記事を公開する前の検査は264行のスクリプトが自動で回し、条件を満たさないと先へ進めません（2026年9月18日時点）。「確認する」と手順書に書くのではなく、確認しないと進めない形にしてあります。

この3つは、どれも高機能なツールではなくて、ただのテキストファイルと短いスクリプトです。効いているのは道具ではなく、置き場所と勝ち負けと担当を先に決めてある、という部分だけなんですよね。

よくある質問

最初に決めるのは中身ではなく、誰がいつ直すか

マニュアルをAIで作る話は、どうしても「何で作るか」から始まります。ただ、初版を作る力はもう安く手に入るので、勝負が決まるのはその先です。

決める順番はこうです。まず、その文書の持ち主を1人決める。次に、置き場所を1か所に決め、矛盾したときにどちらが勝つかを書いておく。それから、更新のきっかけをツール変更・担当交代・クレーム・月次棚卸しの4つに紐づける。ここまで決まってからAIに下書きを渡します。この順番を逆にすると、立派な初版が3か月で使われなくなります。

属人化の解消を目的に文書化を始めるなら、全部を書く必要はありません。その人が休んだ日に止まる業務から順に、更新の担当ごと決めていくのが最短です。

関連記事属人化は引き継ぎ書では解消しない。72時間しのぐ代替1本属人化は引き継ぎ書を書いても解消しません。担当者が明日いなくなる前提で、業務を1つだけ選び、72時間しのぐ代替を1本置く設計を、自社で無人運転させている仕組みの実物から解説します。→