業務マニュアルをAIに書かせたら、新人役の妻が2箇所で止まった｜社内ナレッジベースをAIで構築する手順
当サイトはアフィリエイトプログラムを利用しており、紹介リンク経由での申込により報酬を得る場合があります。記事内で紹介するサービスには筆者が実際に使用しているものと、客観情報として比較掲載しているもの（未使用・PR表記あり）が含まれます。
「自分がいないと回らない業務」を1つ、AIでマニュアル化してみた。台帳の運用ルールを丸ごとAIに渡し、新人が読んでそのまま動ける手順書に変換させる、という試みだ。結果は半分成功・半分失敗だった。できあがったマニュアルを家族に「新人役」として渡して実際にやらせてみたら、2箇所で完全に止まった。原因は精度ではなく、自分が「書かなくても分かるだろう」と省略していた前提だった。
結論
社内ナレッジベースをAIで作るときのボトルネックは、AIの文章生成力ではなく「何を暗黙知として省略しているか、自分では気づけない」ことにある。解決策は、AIに一度書かせて終わりにせず、業務を知らない人に実際に読んで動いてもらい、止まった場所を聞くという検証を挟むこと。この工程を省くと、マニュアルは「書いた本人にしか分からない文書」のまま完成してしまう。
なぜ「暗黙知を形式知に」だけでは書けないのか#
「社内ナレッジベース AI構築」で検索すると、企業向けSaaS導入コンサルのオウンドメディア記事が並ぶ。内容はだいたい共通していて、「属人化はリスク」「暗黙知を形式知化しましょう」「AIでナレッジベースを構築しましょう」という三人称の一般論で終わっている。
ここに欠けているものが2つある。
- 実際に書いたマニュアルの中身（どんな粒度で、どんな失敗をしたか）
- 他人が読んで本当に動けたかの検証結果
企業向けの記事がここまで踏み込まないのは、たぶん取材ベースで書いているからだ。自分で手を動かして、自分の失敗を晒す必要がない。この記事は逆で、非エンジニアの個人事業主・小規模チームを想定して、自分の実際の業務台帳を使い、AIにマニュアル化させ、他人にテストさせた記録をそのまま出す。
台帳から始める、が結論から先にある理由#
いきなり「マニュアルを書こう」と思うと、多くの人はゼロから文章を組み立てようとして止まる。私も最初はそうだった。
うまくいったのは、すでに動いている「台帳」や「運用ルール」をAIに読ませて、そこから逆算してマニュアル化するというやり方だ。台帳とは、経費精算の記録表やメールの仕分けルールのように、日々の判断がすでに文字とルールになって蓄積されている場所を指す。
自分の場合、立替精算を自動化する台帳を作って運用していた。この台帳には「立替者は送信者から取る」「分からない行は赤くする」「二重計上は警告するが自動で消さない」といったすでに言語化されているルールが大量に入っている。ゼロから思い出しながら書くより、この台帳の設計思想をAIに読ませて「これを初めて触る人向けの手順書に変換して」と頼むほうが、圧倒的に速い。
メモ
台帳・スプレッドシート・過去のSlackやり取り・メールのテンプレートなど、「すでに運用ルールが文字になっている場所」があるなら、そこがマニュアル化の起点になる。真っ白なドキュメントから書き始めるより失敗が少ない（筆者の体感）。
実際にやった手順（5ステップ）#
手順
- マニュアル化したい業務を1つ選ぶ（欲張って全部やろうとしない）
- その業務に関連する台帳・ルール・過去のやり取りをテキストでAIに渡す
- 「初めてこの業務をやる人向けの手順書」としてAIに草稿を作らせる
- 業務を知らない人に実際に読んでもらい、その場で手を動かしてもらう
- 止まった場所・誤解した場所だけをピンポイントで直す
順番に、実際にやったことと詰まった点を書く。
ステップ1：業務を1つに絞る#
最初に手を出したのは「経費精算まわりの運用」だった。理由は単純で、立替精算の台帳というすでに言語化された素材があったから。マニュアル化は初回ほど時間がかかるので、一番素材が揃っている業務から着手するのが遠回りに見えて実は近道だった（体感）。
ステップ2：台帳の中身をそのままAIに渡す#
台帳の設計メモ・運用ルール・「こういう例外があったらこう処理する」という記述を、そのままテキストでAIに渡した。整形せず、箇条書きの生データのままで問題なかった。
ステップ3：AIへの指示（実際に使ったプロンプト）#
草稿づくりで使ったプロンプトはこれだ。
以下は経費精算業務の運用ルールのメモです。
このメモをもとに、「この業務を今日初めて担当する人」が
迷わず作業できる手順書を作ってください。
【条件】
- 前提知識ゼロの人が読む前提で書く
- 専門用語（勘定科目・立替・精算など）が出てきたら
1行で意味を添える
- 「なぜそうするか」の理由も各手順に一言添える
- 判断に迷いやすい場面（例外処理）は
「こういう時はこうする」で個別に書き出す
- 最後に「困ったときの連絡先・確認先」の欄を作る
【運用ルール】
（ここに台帳の設計メモを貼り付け）このプロンプトで出てきた草稿は、見た目としてはかなり整っていた。手順が番号付きで並び、専門用語には注釈がつき、一見「これで渡せる」と思えるレベルだった。
注意
ここで安心して確定版にしてしまうのが一番の落とし穴だった。AIが書いた手順書は「読んで分かった気になる」文章としては優秀だが、「実際にやらせてみると詰まる」文章になっていることがある。読みやすさと、動けるかどうかは別の指標だ。
ステップ4：新人役に実際にやらせてみたら、2箇所で止まった#
草稿ができたところで、経費精算の実務をまったく知らない家族に「新人のつもりでマニュアルだけ見て実際にやってみて」と頼んだ。画面を録画して、どこで手が止まるかを観察した。
結果、想定より早い段階で2回止まった。
| 止まった場所 | 何が起きたか | 原因 |
|---|---|---|
| 立替者の判定ルール | 「送信者から取る」の意味が分からず、誰の欄に書けばいいか迷って作業が止まった | 「送信者」がチャットの投稿者を指すことを自分の中では当然だと思い、明示していなかった |
| 二重計上の警告 | 警告が出たとき、消していいのか放置していいのか判断できず固まった | 「検知はAIが出す、削除するかは人が決める」という前提を自分は知っているが、マニュアルには結論しか書いていなかった |
どちらも、「自分にとっては当たり前すぎて、書く必要すら思いつかなかった」部分だった。AIが書いた文章としては誤りではない。ただし、その業務の文脈を知らない人にとっては、言葉の定義や判断の分かれ道が抜けていた。
この数字は1回の検証結果であり、サンプル数は1人分に過ぎない。それでも「一見完成しているように見えたマニュアルが、実際には動けなかった」という事実そのものが、AI任せで終わらせてはいけない理由になっている。
抜け漏れを直すときにやったこと#
止まった2箇所を直すために、AIへの指示を追加した。
先ほどの手順書について、以下2点を追記してください。
1. 「立替者は送信者から取る」の「送信者」が具体的に
何を指すか（チャットに写真を投稿した人のアカウント名である
こと）を、専門用語を使わずに1文で補足する
2. 二重計上の警告が出た場面の対応を、判断フローとして
書き直す（誰が・何を根拠に・削除するかしないかを決めるか）この2点を追記した第2版を、同じ人にもう一度読んでもらったところ、止まらずに最後まで進んだ。マニュアル化で効いたのは、AIの文章力ではなく、この「実際に動かして詰まった箇所だけをピンポイントで埋める」往復作業だった。
AIでマニュアル化してよかった点
- ゼロから書くより草稿完成までの時間が大幅に短い（体感で3〜4割程度に圧縮された印象）
- 専門用語への注釈を「入れ忘れる」ことがAIは少ない（指示すれば機械的に全部つけてくれる）
- 台帳のような構造化データがあれば、そこから抜け漏れの少ない箇条書きを作りやすい
AIまかせでは足りなかった点
- 「暗黙のうちに省略している前提」はAIには分からない（書いた本人にも分からないことが多い）
- 実際に手を動かす検証をしないと、読みやすさと動けるかの差に気づけない
- 例外処理・判断が分かれる場面は、こちらが具体例を出さないとAIも一般論で埋めてしまう
新人教育に使うときのコツ#
マニュアルを「置いておく」だけでは新人教育にならない、というのが今回の一番の学びだった。実際にやってみて分かったコツを3つ書く。
- 読ませるだけでなく、その場で操作させる。 マニュアルを黙読しただけでは詰まる場所が分からない。実際にやらせて、手が止まった瞬間を観察するほうが、はるかに多くの抜け漏れが見つかる。
- 判断が分かれる場面は「フロー」で書く。 文章の羅列だと読み飛ばされやすい。「こういう時はA、こうでなければB」という条件分岐の形にすると、迷ったときに戻ってこられる場所になる。
- マニュアルは一度で完成させない前提で作る。 最初のバージョンで全部拾おうとせず、実際に使った人からのフィードバックで版を重ねる、という運用込みで設計したほうが現実的だった。
台帳とマニュアルの役割の違い
台帳は「今どう運用されているか」の記録。マニュアルは「初めての人がどう動けばいいか」の説明。似ているが目的が違うので、台帳をそのままコピーしても新人向けの文書にはならない。台帳を材料にしつつ、視点を「初めての人」に切り替えて書き直す工程が必要だった。
属人化したままの業務とマニュアル化した業務の違い#
| 状態 | 引き継ぎにかかる時間の目安（体感） | リスク |
|---|---|---|
| 口頭説明のみ・マニュアルなし | 都度30分〜1時間の説明が必要 | 説明者が不在だと業務が止まる |
| AI草稿のまま未検証のマニュアル | 説明は短縮されるが、詰まった時に自己解決できない | 「読んだのに動けない」でかえって不信感につながる |
| 実際に検証して直したマニュアル | 初回の説明はほぼ不要、詰まっても手順書内で自己解決できる | 判断が分かれる新しい例外が出るたびに更新が要る |
この表の一番下、「実際に検証して直したマニュアル」に到達するには、AIに書かせる工程だけでは足りない。書かせる→動かしてみる→直すの往復が最低1回は必要、というのが今回の実感だ。
AIエージェント開発やプロンプト設計を体系的に学びたい場合#
今回のようなマニュアル化・業務の型化は、独学のプロンプト調整でも十分にできる範囲だ。ただ、複数業務を横断してナレッジベースを設計する、判断フローをAIに扱わせる仕組みまで作り込む、というレベルまで踏み込みたい場合は、体系立てて学んだほうが遠回りが減る場面もある。
PR無料カウンセリングでAI活用の適性を相談するAI Agent Camp（非エンジニア向けAIスキル講座）業務フロー構築・プロンプト設計を体系的に学べる講座。無料カウンセリングで自分の業務にどこまで応用できそうか相談できる。受講の要否は向き不向きで判断したほうがよく、成果や収益を保証するものではない。よくある質問#
Q. マニュアル化はどの業務から始めればいいですか？#
自分の場合、すでに台帳やルールとして言語化されている業務から始めるのが早かった。何も文字になっていない業務をゼロから聞き起こすより、既存の記録をAIに読ませて逆算するほうが、初回の草稿作成にかかる時間が短くなる（体感）。何から手をつけるか迷う場合は、非エンジニアのAI自動化全手順で業務の棚卸しの考え方も参考になる。
Q. AIに書かせたマニュアルは、そのまま新人に渡していいですか？#
今回の検証では、AIが書いた第1版だけを渡していたら2箇所で作業が止まっていた。読みやすい文章であることと、実際に動けることは別の指標だ。少なくとも1回は、業務を知らない人に実際に操作してもらい、止まった場所を直す工程を挟むことをおすすめする。
Q. マニュアルとナレッジベースは何が違いますか？#
マニュアルは1つの業務の手順書、ナレッジベースはそうした手順書やルールの集合体を指すことが多い。今回書いたのは経費精算という1業務のマニュアルだが、こうした個別マニュアルを蓄積し、AIが横断的に読める場所にまとめていく段階になると「ナレッジベース」と呼べる規模になっていく。日々の説明の手間を減らす発想自体は、AIに毎回説明し直すのをやめた話で書いた「前提ファイル」の考え方とも共通している。
まとめ#
- 社内ナレッジベースをAIで作る作業は、草稿づくりまではAIが速い。台帳やルールなど、すでに文字になっている素材があるとさらに速い
- ただし、自分にとって当たり前すぎる前提はAIには分からない。今回の検証では8手順中2箇所で新人役が実際に止まった
- 効いたのは、AIの文章力よりも「実際に動かしてみて、止まった場所だけを直す」という往復作業
- マニュアルは一度で完成させず、検証して版を重ねる前提で設計したほうが現実的だった
まずは1業務だけ、すでにルール化されている台帳やメモを材料にAIへ渡してみるところから始めるとつまずきにくい。関連して、日々のルーティン業務をAI化するテンプレートはルーティン業務のAI自動化テンプレート6選にまとめている。
