はじめに

現場のDX推進をしていると、必ずぶつかる壁があります。

「このExcelマクロ、なんでこう作ったんだっけ...」
「あの業務フロー、担当者に聞かないと分からない」
「前任者が異動して、経緯が誰にも分からなくなった」

いわゆる業務ノウハウの属人化です。ドキュメントを整備しようにも、忙しい現場では後回しになりがちですし、書いたところで更新されず陳腐化していく、というのもよくある話です。

この記事では、AIコーディングエージェントの Claude Code と、ローカルMarkdownノートアプリの Obsidian を組み合わせて、「聞けばAIが経緯を答えてくれる」「作業の合間に自然と記録が溜まっていく」ナレッジベースになりそうかを、個人開発環境で試している段階の内容として紹介します。まだ社内提案するかどうかを検討している途中ですが、その検討材料として書き残しておきます。

課題:なぜドキュメントは書かれないのか

一般的なナレッジ管理(Wiki、Confluence等)がうまく回らない理由は、体感としてはだいたいこの3つに集約されます。

記録するコストが「今の作業」と別枠になっている → 後回しにされる
検索性が悪い → 情報はあるのに見つからず、結局本人に聞く
更新されない → 古い情報が残り続けて信頼性が落ちる

これを解決するには、「記録する」という行為を、日常的に使っているツール(AIとの対話)の副産物にしてしまうのが早い、と考えました。

全体構成

Obsidianボルト(Markdownノートの保存先フォルダ)を、Claude Codeが会話の最初に自動参照する場所として位置づけています。ポイントは、指示を都度出さなくても、AIが自発的に「関連しそうならまずここを見る」動きをするようにしていることです。

```
claude code/ ← Obsidianボルトのルート
├── ダッシュボード.md ← 全体の一覧。まずここを見れば全体像がつかめる
├── 01_Projects/
│ └── <プロジェクト名>.md ← プロジェクトごとに1ファイル
│ 「現在の状態」「関連スクリプト」「履歴」の3セクション
├── 02_Decisions/ ← プロジェクト横断の重要な意思決定を記録
├── 03_Scripts/
│ └── <スクリプト名>.py.md ← スクリプト1つにつき1ノート
│ (処理内容・目的・使い方・依存関係・更新履歴)
├── 04_Ideas/
│ └── <アイデア名>.md ← アイデア1件=1ノート(status: 未検討/検討中/保留・却下)
└── 05_Knowledge/ ← 特定プロジェクトに紐づかない汎用知識
```

この構成自体は特別な技術ではありません。重要なのは、AI側の振る舞いを固定するルールを別途持たせている点です。

保存先はOneDrive:「複数人で同じナレッジを参照する」ことを見据えて

ボルトの実体はローカルフォルダではなく、OneDrive上のフォルダに置いています。理由は、PC・ノートPCなど複数端末から同じ内容にアクセスしたかったからです。

これは個人利用の都合に見えて、実は業務への横展開を考えるときにそのまま効いてくる設計です。個人の「複数端末で同じナレッジを見たい」を、組織に置き換えると「複数人が同じナレッジをAI経由で参照・更新したい」という要求にほぼそのままスライドします。

個人:自分のPCとノートPCで、同じボルトをClaude Codeが参照する
組織:担当者Aと担当者Bが、それぞれ自分のClaude Codeセッションから同じ共有フォルダ(OneDrive/SharePoint等)のボルトを参照・更新する

つまり、この構成は最初から「単一ユーザー・単一端末」に閉じない前提で検討しています。実際に個人開発環境で複数端末運用を試してみて、同期の競合(同時編集でファイルが分岐する等)がどの程度起きるか、履歴欄への追記がどれだけ衝突するかは、組織展開する前段の実験として非常に参考になりました。

AIの振る舞いを固定する:CLAUDE.mdの役割

Claude Codeには、常に読み込まれる設定ファイル(CLAUDE.md)を置けます。ここに「どんな依頼のときにボルトを見に行くか」を明記しておくことで、都度指示しなくてもAIが自律的にボルトを参照するようになります。

現時点で試している設定(抜粋・要約)はこんな内容です。

```markdown

作業記録用Obsidianボルト

作業ログ・プロジェクト状態・スクリプト記録などを記録している
Obsidianボルトが以下にあります。作業ディレクトリに関わらず、
関連しそうな依頼(過去の作業内容の確認、各プロジェクトの進捗、
スクリプトの内容など)があれば、まずこのボルトを確認してください。

場所: <ボルトのパス>

運用ルール

新規プロジェクトはテンプレートから作成、既存プロジェクトへは
履歴欄に追記
スクリプトを新規作成したらノートを作成し、プロジェクトと
相互リンクする
作業内容・確認事項・決定事項をチャット終了時に
プロジェクトファイルの「履歴」欄へ追記する
```

この一文があるだけで、たとえば「先月のあのバッチ処理、どういう経緯で今の仕様になった?」と聞けば、AIがボルト内の該当ノートを横断的に検索し、履歴欄に残っている過去の判断理由まで含めて回答してくれます。質問した本人が別部署に異動していても、後任者が同じ質問をAIにするだけで経緯にたどり着ける、というのが最大のメリットです。

「書く」を作業の副産物にする:履歴欄への自動追記

このワークフローの肝は、記録を独立したタスクにしないことです。

スクリプトを新規作成 → 自動的に03_Scripts/にノートが作られ、関連プロジェクトと相互リンクされる
何らかの作業や意思決定が発生 → チャットの終わりに、AIが自分から「履歴欄に追記していいですか」と聞いてくる、あるいは追記した上で報告する

人間が「よし、ドキュメントを書くぞ」と意識する瞬間を作らない。AIと一緒に作業した結果として、記録が勝手に溜まっていく設計です。これにより、前述の「記録コストが別枠になっている」問題を回避しています。

検索性:プロジェクト横断の「経緯」に強い

Confluence等のWikiが苦手なのは、「このルールはなぜこうなったのか」という横断的な経緯の掘り起こしです。フォルダやページの構造は静的なので、後から「あの決定っていつ、何が理由だったっけ」を探すのはキーワード検索頼みになりがちです。

Claude Codeの場合、自然文で聞けば複数ファイルを横断的に読んで文脈をつないでくれます。たとえば「このルールっていつ決まって、なぜ今の形になったの?」と聞くだけで、02_Decisions/や関連プロジェクトの履歴欄を突き合わせて経緯を要約してくれる、という体験は、Wikiのキーワード検索よりも「聞きたいことに近い答え」が返ってきやすいと感じています。

試してみて見えてきた注意点

いいことばかりではないので、個人開発環境で触ってみて意識するようになった点も書いておきます。

情報の陳腐化リスクはゼロにはならない。矛盾する記述を見つけたら都度AIに直させる、というルールを明示的に持たせないと、古い情報が「AIのお墨付き」で残り続けてしまう(むしろWikiより気づきにくい)
記録の粒度はテンプレート化しないと崩れる。「現在の状態/関連スクリプト/履歴」のように型を決めておかないと、AIが書くノートの質にばらつきが出る
機密情報の扱い。個人の環境ではローカルフォルダ+.gitignoreで十分だが、社内展開するなら誰がどこまでのノートにアクセスできるか、アクセス権限の設計が別途必要になる

社内展開を考えるなら

個人利用ではなく組織で展開する場合、この構成をそのまま持っていくのは難しく、以下のような検討が必要になりそうです。

論点	個人開発環境での検証(今回)	組織展開する場合
保存場所	OneDrive(個人アカウント、複数端末で同期)	社内共有ドライブ・SharePoint・社内Git等、アクセス権限付き
記録のルール	CLAUDE.mdに自分用ルールを書くだけ	チーム全員が同じ粒度で書けるようテンプレート・レビュー運用が必要
AIの参照範囲	個人の全ボルト	部署・案件単位でのアクセス制御が必要
陳腐化対策	気づいたら自分で直す	定期的な棚卸しルール・責任者の明確化が必要

とはいえ、「AIとの対話の副産物として記録が溜まる」という設計思想自体は、個人でもチームでも有効だと考えています。まずは自分の担当領域で小さく試して、効果を定量的に示してから展開範囲を広げる、というのが現実的なステップかなと思います。

今後補強が必要だと考えている仕組み

個人開発環境で試す中で、「これは最低限セットで用意しないとチーム運用には耐えない」と感じている点が3つあります。

1. 定期バックアップ

OneDriveでの同期は「複数端末で同じ内容を見られる」利点がある一方、ファイル破損・同期の競合・誤った上書きが起きたときにそのまま伝播してしまうリスクとも隣り合わせです。ナレッジベースはボルト全体が資産なので、OneDriveの同期だけに頼らず、世代管理できるバックアップ(定期的なスナップショットを別の場所に取る等)を別途仕組み化しておく必要があると考えています。

2. 「AIのメモリ任せ」にしない保存ルールの徹底

Claude Codeにはセッションをまたいで参照できる記憶の仕組みがありますが、これはあくまでAI側の内部状態であり、人間が直接ファイルとして確認・共有できる場所ではありません。ここに頼りきると、「AIに聞けば分かるが、ファイルとしては残っていない」という状態に陥り、属人化ならぬAI依存化を招きかねません。

そのため、「作成したファイル・スクリプトは必ずOneDrive上のボルトに保存する」というルールをCLAUDE.md側に明記し、AIのメモリはあくまで補助、正本は必ずファイルとして残す、という優先順位を徹底する必要があると考えています。

3. 作業ログ・タスク/進捗管理

現状の「履歴欄への追記」は、プロジェクト単位の大きな意思決定・作業内容を残す粒度にとどまっています。チームで運用するなら、これに加えて以下のような仕組みが要りそうです。

作業ログ:誰が・いつ・何をAIと一緒にやったかを、プロジェクトの履歴より細かい粒度で残す(後から「あの作業、いつ誰がやった?」を追えるように)
個人タスク管理:各メンバーが今何に取り組んでいるかをボルト上で見える化する
チーム進捗管理:プロジェクト単位の進捗を横断的に一覧できるビュー(既存の「ダッシュボード」を進捗集計に拡張するイメージ)

これらは個人利用の段階ではまだ厳密に作り込んでいませんが、チーム運用を見据えるなら、ナレッジの「記録」だけでなく「進行管理」の機能もセットで設計しておくべきだと考えています。

まとめ

属人化したノウハウの継承は、「記録するコスト」「検索性」「陳腐化」の3つが壁になりやすい
Claude Code × Obsidianの組み合わせは、AIが自律的にボルトを参照するルールをCLAUDE.mdに固定することで、都度の指示なしに「聞けば経緯が分かる」状態を作れる
記録自体も「作業の副産物」として溜まる設計にすることで、ドキュメント作成を独立したタスクにしない
個人運用ではシンプルに成立するが、組織展開にはアクセス制御・記録ルールの統一・陳腐化対策の別設計が必要
バックアップ・「AIメモリ任せにしないファイル保存ルール」・作業ログ/タスク進捗管理は、チーム運用に向けて今後補強が必要な仕組み

現場のノウハウ継承に悩んでいる方の参考になれば幸いです。