Knowledge

背景と課題

生成AIに業務の相談をすると、答えを得る前に長い背景説明が必要になります。相談1件ごとに、案件の経緯や相手の会社の状況、過去にどう判断したかを、人が思い出して書くことになります。

企業側で見ると、負担は3つに分かれます。

1つめは、説明そのものにかかる時間です。相談のたびに発生するため、AIを使う回数が増えるほど増えます。

2つめは、説明できる人が限られることです。経緯を知っているのは担当者だけで、情報は本人の記憶とチャット履歴の中にあるため、担当者が変わると同じ相談を再現できません。

3つめは、回答が一般論になることです。自社の規模や方針を渡していないので、すでに社内で検討して見送った案が繰り返し提案されます。

私はこの3つを、記録の置き方を変えることで減らしました。

私がやったこと

社内の記録をマークダウンのファイルとして1か所に貯め、生成AIから直接読ませています。

貯め方は3階層です。会議や作業の生ログをそのまま置く層、そこから再利用できる学びを抜いて抽象化する層、それらを束ねて棚卸しする層に分けます。運用ルール自体も同じ場所にファイルとして置き、AIに毎回読ませます。

入力と抽象化は夜間の自動処理に任せ、人が判断するのは、抽象化したものを正式な知識として採用するかどうかの部分だけにしています。

用語の補足

技術者以外の方が読むために、この記事に出てくる語をまとめます。読み飛ばして構いません。

• Obsidian: マークダウン形式のファイルでメモを管理するアプリ。保存先は普通のフォルダ
• vault: Obsidian が管理するフォルダのこと。中身はテキストファイルの集まり
• マークダウン: 記号で見出しや箇条書きを表す、テキストの書き方
• MCP: AIツールに外部のデータやサービスを接続するための共通仕様
• frontmatter: ファイルの先頭に置く、種類や日付などの属性
• cron: 指定した時刻に処理を自動実行するための書き方

対応方針

AIツールは文脈を溜めて育てるもの、という前提

生成AIの回答の質は、渡した文脈で決まります。同じ質問でも、案件の経緯と自社の方針を渡したときと渡さないときでは、別の答えが返ります。

そのため私は、AIツールを質問のたびに使い捨てる道具ではなく、社内の文脈を溜めて育てる対象として扱っています。育てるために必要なことは2つあります。

1つめは、属人的な文脈を人の外に出すことです。案件の経緯や取引先の事情は、担当者の記憶とチャット履歴の中にあります。AIツールが外部から読み込める場所に置き換えないかぎり、毎回人が思い出して渡す構図は変わりません。

2つめは、文脈を一覧ではなく関係のつながりとして持たせることです。情報をフォルダに整理するだけだと、AIの検索語が想定と違ったときに何も見つかりません。ノート同士をリンクでつないでおくと、直接ヒットしなかった情報にも関連からたどり着けます。私が参加しているAI開発関連の勉強会でも、AIに渡す文脈をグラフの形で持たせる設計が話題に上がるようになっています。

保存先にObsidianを選んだ理由

保管の実体がただのマークダウンのフォルダである点を最も重視しました。専用形式のデータベースではないため、AIから見ると普通のファイルの読み書きになります。全文の横断検索ができ、変更履歴をバージョン管理に乗せられます。

ノート同士のリンクが双方向になる点も理由の1つです。リンクを1本張ると張られた側にも参照が自動で付き、ノート間の関係が図としてつながるため、上に書いたグラフの形をそのまま実現できます。

Local REST API というコミュニティ製の拡張機能を入れ、そこに MCP のサーバを重ねると、AIツールから検索と読み書きができます。全文検索、ファイル取得、追記、部分更新が、AI側からは通常のツール呼び出しに見えます。

生ログと抽象化した知識を混ぜない

貯める場所を3階層に分けたのは、生ログをそのまま検索対象にすると、抽象化した知識が検索結果に埋もれるためです。

• 第1段: 日次ログ、議事録、メモ。加工していない生の記録
• 第2段: 生ログから抜いた学び、そこから昇華した永続ノート、人物、案件
• 第3段: テーマ別の目次と、週次・月次のダイジェスト

第2段の成果物は人ではなくAIが読むものとして作っていて、人が読むのは第3段です。

判断のルールはファイル、実行の手順は処理側

運用ルールを vault の中にマークダウンで置いています。フォルダ規約、命名規則、ノートの型、知識として採用してよいかの判定基準を、ファイルとして並べます。

AIに作業させるときは、毎回このフォルダを先に読ませます。ルールを毎回指示文に書く必要がなくなり、変更したいときはファイルを1行直せば、そのあとの全処理に反映されます。

ルールを処理側の設定に書く方法もありますが、私は vault 側に置きました。1か所にまとまっているほうが、夜間の自動処理と複数のAIツールの両方から読ませやすいためです。

副次的な効果として、AIが検索したときにルール自体がヒットします。渡していない判定基準をAIが自分で見つけて確認してから作業するのは、ルールが知識と同じ場所にあるからです。

線引きは、判断のルールは vault、実行の手順は処理側としています。迷ったときは、そのルールを人が読んで納得する必要があるかで決めます。納得が要るものは vault、機械が動くための設定は処理側です。

知識として採用する基準を先に決める

生ログから永続ノートに上げてよいかを、4条件で判定しています。

1. 再利用できる。別の場面、別の相手にも当てはまる
2. 抽象化されている。社名、日付、金額が本文に残っていない
3. 1ノートにつき主張が1つ。2つ以上あるなら分割する
4. 結論が言える。タイトルを断言の形にできる

4条件を満たさないものは、日付を付けた学びログに置いて保留します。生成AI関連のように陳腐化が速い知識は原則としてここで止めます。モデルが変わると前提ごと無効になるためです。

具体的な使い方

前提を先に書きます。私は普段から Claude に資料の作成や方針の相談をしていて、仕事のやりとりのかなりの部分がチャットの中で進みます。Obsidian をつないだのは、その相談相手に過去の経緯を持たせるためです。

つないだあとは、秘書に近い使い方になります。用件を一言渡すと、AIが先に vault を検索し、関係する議事録、人物ノート、過去に決めたことを読んでから応答します。こちらが資料を探して添付したり、経緯を説明し直したりする手順がなくなります。

以下は実際に使っている場面です。

商談と打ち合わせの前

「A社の件、次どうする」とAIに聞くと、過去の議事録と担当者ノートを引いた状態から会話が始まります。相手の会社の経緯を人が説明し直す必要がありません。前回何を持ち帰ったか、誰が何に懸念を示したかを、その場でさかのぼれます。

方針を決めるときの相談

方針を検討するとき、AIは回答の前に会社としての立場を集めたノートを読みます。会社の規模では選ばないと決めてある案が、最初から候補に出てこなくなります。一般論の提案を読んで判断し直す手間が減ります。

資料と文章の作成

文章を作らせるときも同じノートを読ませています。表現の好みや、使わないと決めている言い回しが反映されるため、書き上がったものの直しが少なくなります。

担当の引き継ぎ

人物ノートには、その人の働き方や強みに加えて、実際に受けた発言をそのまま残しています。担当が変わるときに、どこまでが観測した事実で、どこからが前任者の解釈かを判別できる状態で渡せます。

別の案件への横展開

永続ノートは社名と日付を落とした形で書いてあるため、案件をまたいで引けます。過去に一度考えたことを、次の案件でもう一度考え直す作業が減ります。

手順

ここから先は、実際に構築する方向けの内容です。

1. 種類でフォルダを切る

フォルダは「これは何か」だけで切り、テーマはタグ、文脈はリンクで持たせます。1つのノートに、種類とテーマと文脈という3つの経路からたどり着ける状態になります。

私の構成です。

00_Inbox/              未整理の一時置き場（週次で空にする）
10_Daily/              日次ノート、議事録、メモ
20_People&Orgs/        人、自社、取引先
30_Projects/           進行中と完了のプロジェクト
40_Areas/              責任領域の目次
50_Resources/          永続ノート、立場、学びログ、読書ハイライト
80_Archive/            アーカイブ
90_Meta/               運用ルール（AIが毎回読む）
99_Attachments/        画像と添付

全体を束ねる中心ノートは作らないと決めています。目次を1枚に集約すると、更新が止まるためです。

フォルダを切る前に決めておくことが1つあります。この構成では取引先や担当者に関する記述が入るため、どこまでをAIに読ませてよいかの線引きが必要になります。判断は各社の情報管理方針によるので、この記事では扱いません。

2. 運用ルールをvaultに置く

90_Meta/ にルールのファイルを並べます。私はフォルダ規約、frontmatter の型、命名規則、タグ体系、表記揺れの正規化表、知識の採用基準、抽出手順、棚卸しのルール、ノート種別ごとのテンプレートを置いています。テンプレートは18本です。

型が決まっていると、AIが書いても人が書いても同じ形になります。

3. 記録の入力を自動化する

商談と打ち合わせは録音デバイスで記録し、文字起こしを自動連携でクラウドストレージに保存しています。毎晩23時の定期処理がそのフォルダを見に行き、論点を構造化して議事録ノートを作ります。

要約は論点がずれることがあるため、自動要約は使わず生の文字起こしを処理しています。処理の内容も要約ではなく論点の列挙とし、実際に挙がった問いと主張、固有の用語と数字を残します。

議事録ノートの末尾には「切り出し候補」の欄を置き、次の段への申し送りにしています。

4. 抽象化を自動化する

AIとの作業ログから再利用できる学びを抜く処理を、毎日22時に走らせています。抜いた学びを永続ノートや人物ノートに振り分ける処理は、その後に続けます。

自動処理を組むときの決めごとは3つです。

• 各処理の最初のステップを「規約を読む」にする
• 移動、リネーム、削除をさせない。書き足すだけにする
• 同じ処理を二度走らせても結果が変わらないよう、処理済みの記録を残す

議事録から知識への振り分けは、週次の処理が未処理分を見つけて案を出すところまでが自動で、実行は人が判断しています。誤った配置がノート間のつながりを壊すためです。読書のハイライトは自動化の対象外で、1冊1ファイルで160冊ほど貯めた中から都度抜いています。

私は定期処理を8本動かしていますが、これは多すぎます。最小構成は、録音の文字起こしを取り込む処理と、週に1回の棚卸しの2本です。

5. AIから読ませる

AIツール側に、相談を受けたらまず vault を検索するよう指示しています。回答の前に、永続ノート、過去の議事録、人物ノート、会社としての立場を集めたノートを引いてから答える形です。

まとめ

生成AIへの背景説明の手間は、AIの使い方ではなく記録の置き方の問題として減らせます。

社内の記録をマークダウンで1か所に貯め、生ログと抽象化した知識を層で分け、運用ルール自体も同じ場所に置きます。ノート同士をリンクでつなぎ、文脈をグラフの形で持たせます。入力と抽象化は自動処理に寄せ、人は採用の判断だけを持ちます。

効果として、相談時の背景説明が不要になり、自社の方針を踏まえない一般論の提案が減りました。知識への振り分けの判断と、AIに渡してよい情報の線引きは、引き続き人が持つ部分です。

記載した構成と数値は2026年8月時点の私の環境にもとづくもので、会社共通の仕組みでも、公式の推奨構成でもありません。

参考リンク

• Obsidian 公式サイト（2026年8月28日確認）
• Model Context Protocol 公式サイト（2026年8月28日確認）
• この運用の記録は note にも書いています。テンプレートの中身や定期処理の一覧など、より詳細な手順はそちらをご覧ください。