業務マクロ引き継ぎをAIが読めるナレッジベースにする
Markdownを正本にし、Codex・Skill・MCP・NotebookLMを役割分担して使う引き継ぎ設計
Copyright © 2026 LWP 山中 一弘
本資料は、出典を明記いただければ、商用・非商用を問わず、ご自由に複製・改変・再配布していただけます。なお、著作権表示は改変せず、そのまま記載してご利用くださいますようお願いいたします。
記事要約
業務マクロの引き継ぎで本当に困るのは、操作手順がないことだけではありません。業務仕様、入力ファイル、出力ファイル、マクロ仕様、例外処理、過去のトラブル、担当者の暗黙判断が散らばり、「どれが最新で、何を信じてよいのか」が分からなくなることです。
AIを使えば、その場でマニュアルやFAQを作ることはできます。しかし、AIに読ませる正本が整理されていなければ、生成される資料も不安定になります。NotebookLM、ChatGPT、Codex、Claude、Notion、Google Drive、Word、Excelなどに情報を散らすほど、便利さの裏で正本管理が崩れやすくなります。
本記事では、業務マクロの引き継ぎを「完成マニュアル作成」ではなく「AIが読める業務ナレッジベース作成」として設計します。結論は、Markdownを正本にし、Codex・Skill・MCPを実行層、NotebookLMを参照層として使い分ける方式です。
本記事の対象とゴール
想定読者
Excelマクロ、Access、VBA、Power Queryなどの業務ツールを引き継ぐ必要がある人
担当者しか分からない業務マクロを、組織で保守できる形にしたい人
マニュアルを作ってもすぐ古くなる問題に困っている人
音声メモ、議事録、仕様書、コードをAIで整理したい人
NotebookLM、Codex、MCP、Skillを業務引き継ぎにどう使うか整理したい人
本記事で得られること
業務マクロ引き継ぎで、何を正本として残すべきか判断できます。
Markdown、Codex、Skill、MCP、NotebookLMの役割を分けて設計できます。
音声メモや口頭説明を、後から検索できる業務ナレッジへ変換する流れを作れます。
本記事で扱わないこと
特定のNotebookLM操作手順
特定MCPサーバーの実装方法
VBAコードの具体的な修正方法
GitやDropboxの詳細な運用手順
個別企業の業務仕様書そのものの作成
先に結論
業務マクロの引き継ぎは、マニュアルを一冊作って終わりにするより、AIが読める業務ナレッジベースを作るものとして設計した方が安定します。
推奨する構成は、次の三層です。
第1層 Markdown資料群
業務仕様、操作手順、マクロ仕様、例外処理、変更履歴、口頭メモを置く正本
第2層 Codex / Skill / MCP
Markdown、コード、Excel、フォルダを読み、手順書・調査結果・修正案を生成する実行層
第3層 NotebookLM
まとまった資料群を読み込ませ、要約・横断質問・教育資料・FAQ作成に使う参照層
中心に置くのはNotebookLMではありません。中心はMarkdownです。
NotebookLMは非常に強力ですが、正本管理の場所にするより、ある時点の資料群を読ませて考えさせるワークスペースとして使う方が安全です。Codex、Skill、MCPは、正本となるMarkdownやコードを読んで、必要な成果物を作る実行層にします。
第1章（引き継ぎで壊れるのはマニュアルではなく正本である）
この章では、業務マクロ引き継ぎの失敗原因を整理します。マニュアルがないことだけを問題にすると、作った瞬間に古くなる資料を増やしてしまいます。
1.1 「どれが最新か分からない」が一番危ない
業務マクロの引き継ぎで一番怖いのは、「どれが最新か分からない」状態です。
情報がWordの操作マニュアル、Excelの仕様メモ、Google Driveの共有資料、NotebookLMに投入した資料、AIとの会話ログ、担当者の音声メモ、メール、チャット、実際のVBAコードに散らばると、最初は便利でも後から破綻します。
この状態では、AIに質問しても、どの資料を根拠に答えているのかが曖昧になります。人間が読んでも、AIが読んでも、信頼できる正本が必要です。
1.2 正本に必要な条件
正本は、ただ保存されていればよいわけではありません。業務引き継ぎの正本には、人間が読めること、AIが読めること、差分管理できること、検索できること、フォルダ単位で分けられること、他のツールに渡しやすいこと、将来のAIツールに乗り換えやすいことが必要です。
この条件を満たしやすい形式がMarkdownです。
Wordは人間向けの配布資料には向いていますが、差分管理やAI処理には少し重くなります。NotebookLMは読む力が強い一方で、正本管理の場所として使うには、同期、更新、差分、権限、出し入れの点で注意が必要です。Excelは業務データには向いていますが、仕様書、判断理由、変更履歴の正本には向きません。
1.3 作るべきものは完成マニュアルではなく材料群である
「マニュアルは都度生成すればよい」という考え方は、半分正しいです。
ただし、完全に「マニュアル不要」と考えると危険です。正しくは、固定マニュアルを唯一の成果物にせず、業務知識を素材として蓄積し、目的別マニュアルを必要なときに生成する、という考え方です。
作るべきものは、完成マニュアルそのものではありません。マニュアルを生成できる材料群です。
たとえば、業務概要、操作フロー、マクロ一覧、入力ファイル、出力ファイル、エラー事例、月次処理、変更履歴、用語集、音声メモを正本として分けておきます。
この材料群があれば、同じ正本から、新人向けマニュアル、担当者向け操作手順、管理者向け概要、マクロ改修者向け仕様書、障害対応手順、月次処理チェックリスト、引き継ぎ資料、顧客説明資料を生成できます。
第2章（AIツールの役割を分ける）
この章では、Markdown、Codex、Skill、MCP、NotebookLMの役割を分けます。全部を一つのツールに寄せると、便利さと引き換えに運用の境界が曖昧になります。
2.1 Markdownは業務知識そのものを保存する
Markdownは、業務知識の保存場所です。
ここには、業務概要、操作手順、入力ファイル、出力ファイル、シート構成、列定義、マクロ一覧、エラー時の対応、過去の変更履歴、担当者の判断メモを置きます。
重要なのは、Markdownを生成物ではなく正本として扱うことです。AIで整えた資料も、確認して正本に反映して初めてナレッジになります。
2.2 Codexは読み、探し、生成し、修正案を作る
CodexやClaude Codeのようなコーディングエージェントは、資料とコードを読んで作業する実行層に向いています。
業務マクロ引き継ぎでは、Markdown資料を読み、必要な情報を探すことができます。VBAコードからモジュール一覧やプロシージャ一覧を作ることもできます。Excelファイルのシート構成や列定義を調べ、操作手順書や障害対応手順を生成し、仕様変更時に影響しそうな資料やコードを探すこともできます。
Codexは正本そのものではありません。正本を読んで、作業を進める担当者のように使います。
2.3 Skillは業務固有の作法を定義する
Skillは、AIに対して「この業務ではどう読むか、どう作るか、何を確認するか」を教えるための作法です。
たとえば、業務マクロ引き継ぎ用のSkillでは、この会社のマクロ仕様書はどこにあるか、操作手順書を作るときに必ず確認する資料は何か、月次処理ではどの順番でファイルを読むか、エラー対応手順には何を必ず書くか、変更履歴をどこへ追記するか、生成物を正本と混ぜないためにどこへ保存するかを定義します。
Skillがあると、AIが毎回その場の推測で動かず、業務ごとのルールに沿って作業できます。
2.4 MCPは外部操作の手足にする
MCPは、AIアプリケーションと外部ツールやデータを接続するための仕組みです。
業務マクロ引き継ぎでは、ファイル検索、Excel読取、PowerShell実行、Git操作、Google Drive参照、コード解析、ブラウザー操作などがMCPの役割になります。
MCPは業務知識そのものではありません。AIが外部のファイルやツールに触れるための手足です。
2.5 NotebookLMは副頭脳として使う
NotebookLMは、正本ではなく、読解、要約、教育用の副頭脳として使うのがよいです。
大量資料を読ませて全体像を把握する、マクロ仕様書・議事録・操作メモを横断して質問する、新人向けFAQを作る、教育用の説明文を作る、音声概要や学習用資料を作る、過去資料から矛盾点を探す、といった用途に向いています。
一方で、常に最新の正本として使う、大量の細かいファイルを頻繁に出し入れする、自動で完全同期される前提で使う、MCP経由で安定運用する前提にする、といった使い方には注意が必要です。
NotebookLMは強力ですが、正本を置く場所ではなく、ある時点の資料群を読ませて考えさせる場所として使う方が安全です。
第3章（推奨する資料構成）
この章では、業務マクロ引き継ぎ用の最小構成を示します。最初から大きく作りすぎず、正本と生成物を分けることを優先します。
3.1 最初の完成形
最初の完成形では、入口、業務資料、マクロ資料、操作資料、仕様資料、変更履歴、生成物を分けます。
#### 入口 全体の読み順と索引
README、00_index
#### 業務資料 業務の意味と流れ
業務概要、業務フロー、月次フロー、例外ケース
#### マクロ資料 コード側の構造
マクロ概要、モジュール一覧、プロシージャ一覧、入出力、既知の問題
#### 操作資料 担当者が実行する手順
日次操作、月次操作、取込手順、出力手順、確認手順、復旧手順
#### 仕様資料 ファイルや表の前提
ファイルレイアウト、シートレイアウト、列定義、入力チェック、業務ルール
#### 変更履歴 判断と更新の記録
音声メモ、修正メモ、仕様変更メモ
#### 生成物 AIで作る配布物
ユーザーマニュアル、開発者向け資料、引き継ぎ書、FAQ
3.2 正本と生成物を混ぜない
この構成で一番大事なのは、生成物を正本にしないことです。
新人向けマニュアルやFAQは生成物として置いてもよいですが、そこだけを更新してはいけません。
正本は、業務資料、マクロ資料、操作資料、仕様資料、変更履歴です。生成物に間違いを見つけた場合は、生成物だけを直すのではなく、正本側に原因を反映します。
そうしないと、次にAIで再生成したときに同じ間違いが戻ります。
3.3 入口を作る
資料が増えるほど、どこから読めばよいか分からなくなります。そこで、最初に読む入口を作ります。
入口には、このプロジェクトは何の業務マクロを扱うか、まず読むべき資料はどれか、月次処理で使う資料はどれか、マクロ改修時に読む資料はどれか、障害時に見る資料はどれか、生成物はどこにあるか、正本はどこにあるかを書きます。
AIに読ませるときも、人間が引き継ぐときも、入口があるだけで迷いが減ります。
第4章（音声メモを業務ナレッジに変える）
この章では、担当者の口頭説明や音声メモをどう扱うかを整理します。属人化した業務では、文章化されていない判断が最も重要な情報になることがあります。
4.1 音声入力は二段階にする
音声入力を貯める構想は正しいです。ただし、音声入力をそのまま正本にすると、後からノイズが増えます。
したがって、音声入力は、まずraw memoとして残し、その後normalized memoへ整形します。
raw memoは、口頭入力をできるだけそのまま残す証跡です。日付、対象業務、対象マクロ、話者、背景を付けます。
normalized memoは、AIで整形し、既存資料のどこに反映すべきかを分類した整理済みメモです。
4.2 音声メモの変換例
たとえば、担当者が「売上集計マクロで、今月から入力ファイルのC列に得意先コードが追加された。旧レイアウトのまま処理すると列が1つずれる。現時点では取り込み前にC列を削除して対応しているが、来月以降はマクロ側で新旧レイアウトを判定したい」と話したとします。
この音声メモは、そのままでは検索しにくく、どの資料へ反映すべきかも分かりません。
AIで整える場合は、対象を「売上集計マクロ」と「入力ファイル」に分け、変更内容を「2026年5月分から入力ファイルのC列に得意先コードが追加された」と書きます。現在の暫定対応として「取り込み前にC列を削除している」と残し、今後の対応方針として「マクロ側で新旧レイアウトを判定する必要がある」と整理します。
さらに、反映先候補として、ファイルレイアウト、既知の問題、取込手順を挙げます。ここまで整えると、音声メモは単なる記録ではなく、業務ナレッジになります。
4.3 暗黙判断を拾う
業務マクロの引き継ぎで特に重要なのは、操作手順よりも判断です。
属人化している業務では、「このエラーは無視してよい」「この場合は前月データを使う」「この会社だけ列の意味が違う」「このファイル名なら月次確定版として扱う」「このシートは一見使っていないが、別マクロが参照している」といった判断が担当者の頭の中だけに残っています。
これらはコードだけを読んでも分かりません。音声入力やヒアリングで拾い、Markdown正本に反映する必要があります。
第5章（引き継ぎで必ず確認する項目）
この章では、業務マクロ引き継ぎで最低限確認する項目を整理します。AIに読ませる資料を作る場合でも、人間が何を確認すべきかは明確にしておきます。
5.1 操作ではなく業務の意味から確認する
業務マクロの引き継ぎでは、単なる操作手順より、業務の意味から確認します。
確認すべきなのは、このマクロは何の業務を処理しているのか、入力ファイルは何か、出力ファイルは何か、どのシートを読むのか、どの列を前提にしているのか、実行前に何を確認するのか、実行後に何を確認するのか、エラー時にどこを見るのか、手修正してよい箇所といけない箇所はどこか、過去に起きたトラブルは何か、改修時に壊しやすい箇所はどこか、担当者が暗黙に判断していることは何かです。
特に重要なのは、担当者が暗黙に判断していることです。属人化している業務は、操作ではなく判断が暗黙化していることが多いからです。
5.2 入出力と確認点を分ける
マクロ仕様を残すときは、入力、処理、出力、確認点を分けます。
入力では、どのフォルダのどのファイルを読むか、ファイル名の規則は何か、必須シートや必須列は何かを確認します。
処理では、どのモジュールやプロシージャが中心か、どの順番で処理するか、途中で作る一時データは何かを確認します。
出力では、どのファイルを作るか、どのシートを更新するか、どの列や表を確認するかを確認します。
確認点では、成功時に何を見るか、エラー時にどこを見るか、手修正してよい箇所はどこかを明確にします。
この分け方をしておくと、AIに仕様書や手順書を作らせるときにも、必要な情報を取り出しやすくなります。
第6章（避けた方がよい方式）
この章では、便利に見えて後から破綻しやすい方式を整理します。AI活用では、最初の便利さだけで設計しないことが重要です。
6.1 NotebookLMだけに全部入れる方式
NotebookLMだけを正本にする方式は避けた方がよいです。
理由は、正本管理、差分管理、同期、出し入れ、自動化、権限管理の面で不安が残るためです。
NotebookLMは、まとまった資料を読ませて全体像をつかむ用途には向いています。しかし、日々更新される業務マクロの正本を置く場所にすると、どの資料をいつ反映したのかが見えにくくなります。
6.2 Wordマニュアルを完成品として作って終わる方式
Wordマニュアルを完成品として作って終わる方式は、従来型の失敗に戻りやすい方式です。
Wordは、納品物や配布資料には向いています。しかし、業務知識の正本にすると、更新されなくなりがちです。作った瞬間はきれいでも、業務変更、例外対応、担当者メモ、マクロ改修が反映されなければ、すぐに古くなります。
Wordで配布資料を作る場合でも、生成元のMarkdown正本を別に持つ必要があります。
6.3 音声メモをそのまま大量に貯める方式
音声メモをそのまま大量に貯める方式は、最初は楽です。しかし、後から検索性が落ちます。
音声や文字起こしは、必ずAIで整形し、反映先を分類します。raw memoを残すことは大事ですが、raw memoだけでは業務ナレッジにはなりません。
6.4 AIに毎回全部読ませる方式
小規模なら、AIに毎回全部読ませる方式でも動きます。しかし、資料が増えると破綻します。
必要なのは、インデックス、分類、正本構造です。AIにたくさん読ませる前に、どの資料が何を担当しているかを整理します。
第7章（現実的な運用手順）
この章では、実際に業務マクロ引き継ぎを始めるときの順番を示します。最初から完璧に作るより、正本を育てる流れを作ることを優先します。
7.1 最初に作るもの
最初に作るものは、入口、業務概要、マクロ概要、変更履歴の運用ルールです。
最初から全資料を完璧に作る必要はありません。入口、業務概要、マクロ概要、変更履歴があれば、少しずつ正本を育てられます。
7.2 次にコードと実ファイルを読む
次に、実際のマクロ、Excel、フォルダを確認します。
確認するのは、VBAプロジェクトのモジュール一覧、プロシージャ一覧、入力ファイルのシート一覧、出力ファイルのシート一覧、処理前後のフォルダ、エラー時のログです。
ここで得た事実を、Markdown正本へ反映します。
7.3 生成物は最後に作る
新人向けマニュアル、FAQ、障害対応手順、管理者向け概要は、最初に作りたくなります。
ただし、生成物を先に作りすぎると、正本が弱いまま見栄えのよい資料だけが増えます。先に正本を作り、そこから生成物を作る順番にします。
生成物に不足を見つけたら、生成物を直すだけでなく、正本に戻して反映します。
まとめ
業務マクロの引き継ぎは、マニュアル作成ではなく、AIが読める業務ナレッジベース作成として設計するべきです。
正しい方向性は、業務知識をMarkdownで日々蓄積し、音声入力をraw memoとして残し、normalized memoへ整形し、Codex・Skill・MCPで検索、整理、生成、コード解析を行い、NotebookLMは読解、要約、教育資料化に使うことです。
最も避けるべきなのは、NotebookLMを中心にしすぎることです。
NotebookLMは副頭脳として使います。正本はMarkdownに置きます。Codex、Skill、MCPは、正本と実ファイルを読んで作業する実行層にします。
この考え方なら、マニュアルがない業務の属人化を、単なる文書化ではなく、AIが扱える知識基盤として減らしていけます。
成功条件は、音声入力を貯めるだけで終わらせないことです。口頭説明、変更履歴、例外判断、コード上の事実をMarkdown正本に反映する運用まで作って、はじめて業務マクロの引き継ぎは安定します。