Claude Code（クロードコード）のナレッジ管理｜手順書の次に入れるべきは「人間関係の相関図」
CLAUDE.mdは作った。手順もいくつか書いた。それでもClaude Code・Codexの成果物が「なんとなく惜しい」まま止まっている——この段階で足りていないのは、たいてい書き方ではなく書く対象です。
結論から書きます。ナレッジに入れるべきものは、業務の手順や仕様だけではありません。誰から来た話で、誰に渡すべきかという人間関係の相関図まで書いてください。ここが抜けていると、AIは正しい手順で間違った相手に届けてしまいます。
Claude Codeのナレッジ管理とは Claude Code・Codexに読ませる前提知識（ナレッジ）を、テーマごとにファイルへ分けて置き、古くなったら更新していく運用のことです。事業の前提・作業手順・過去の事例に加えて、取引関係や連絡先の役割といった業務の文脈まで含めると、AIの出力が実務に使える精度に近づきます。
この記事では、みやっち🧑💻が自社の業務基盤を組みながら気づいた「ナレッジに何を入れるか」を扱います。前提知識の渡し方そのものの原則はコンテキストエンジニアリング、毎回読ませるCLAUDE.mdの作り方はCLAUDE.mdの作り方にまとめてあるので、そちらと合わせて読んでください。Codexと併用している方は、同じナレッジを両方に読ませる仕組みをAGENTS.mdとCLAUDE.mdの違いで解説しています。
ナレッジには何を入れればいいのか
「ナレッジを整備しましょう」と言われて手が止まるのは、置き場所ではなく中身が決まらないからです。入れるものを整理すると、おおむね次の4種類に分かれます。
- 毎回の前提 — 事業内容、文章のトーン、絶対にやらないこと。CLAUDE.mdに置いて毎回読ませる土台です
- 作業ごとの手順 — 記事の書き方、請求の締め方といった、その作業のときだけ要るもの。Skills（手順書）に逃がします
- 事実の台帳 — 料金、サービスの内容、用語の定義。数字や固有名詞が入るので、正本を1つに決めて他から参照させます
- 人間関係の相関図 — 誰から来た案件か、誰に渡すべきか。ここが多くの人の抜けている4つ目です
1から3までは「情報を整理する」という発想の延長で作れます。問題は4つ目で、そもそもナレッジに書くという発想が出てきません。仕事のうえで当たり前すぎて、わざわざ言語化しないからです。
抜けているのは「誰から来て、誰に渡すか」
みやっち🧑💻が自分の業務基盤を作り込んでいるときに気づいたのが、この4つ目でした。ナレッジの整備に、自分の人間関係の相関図も入れるとよい、ということです。
書く内容は、たとえばこうした一文です。
- この案件は、あの紹介元から来たもの
- この件は顧問税理士の担当なので、確認はそちらに送る
一見すると業務システムに入れるような情報ではありません。けれど、実際の仕事はこの情報で動いています。仕事は手順だけで進むのではなく、誰から来た話で、誰に返すかという線の上を流れているからです。
たとえばAIに「この件の連絡文をつくって」と頼んだとき。相関図がなければ、返ってくるのは誰にでも出せる無難な文面です。相関図があると、AIは宛先を担当している人に向け、紹介元とのつながりや経緯を踏まえた下書きを書けるようになります。手順は同じでも、成果物が実務に近づきます。
みやっち🧑💻自身の言葉でいえば、AIは結局のところ人と人のコミュニケーションを助けてくれる部分もある。だから相関図をナレッジに入れる価値がある、ということです。
ただし、書く前に決めることがある
ここから先は慎重にいきます。人間関係を文字にするというのは、他人の情報を自分の管理下に置くということです。ナレッジの中身以前に、扱いの設計が先に来ます。順序としては、次の3つを決めてから書き始めてください。
- 外に出ないローカルのナレッジに限る — まずは置き場所を自分のパソコンの中に限ります。共有ドライブやクラウドの共同編集フォルダに置くと、想定していなかった相手の目に触れます
- 役割ベースから始める — 実在の氏名ではなく、顧問税理士・紹介元・請求担当といった役割で書きます。役割だけでもAIは十分に判断できますし、万一の流出時の影響が小さくて済みます
- 共有範囲を先に決める — このファイルは誰まで読めるのかを決めてから中身を書きます。書いてから考えると、たいてい消す判断ができなくなります
そのうえで、これだけやれば安全と言い切れるものではありません。取引先との契約に守秘の条項があるか、自社に情報管理の規定があるか、扱う情報が個人情報にあたるかで、書いてよい範囲は変わります。士業の方であれば、職業上の守秘義務がそもそもの前提になります。判断に迷う情報は、自社の規定を確認し、必要に応じて弁護士や情報システムの担当者に相談しながら進めてください（本記事は法的助言ではありません）。
権限とナレッジの階層を合わせる
みやっち🧑💻が講座でお伝えしているナレッジ整備の原則は12個ありますが、相関図の話と直結するのは次の2つです。
権限とナレッジの階層構造を合わせる。 人が読める範囲と、AIに読ませる範囲を一致させる、という原則です。社内で部長しか見られない情報を、全員が使うAIのナレッジに置けば、権限の壁は実質的に消えます。ナレッジは階層をまたいで情報を配り直してしまう仕組みでもある、と考えてください。なお「AIに読ませない」制御は、ルールとして書いておくだけでなく、読み取りの動作そのものを止める形でも作れます。仕組みはhooks（フック）の記事で解説しています。
共有範囲を設計する。 ファイルを作る前に、これは自分だけか、社内までか、外部の協力者も含むかを決めておきます。相関図のように「他人が主語になる情報」は、この設計が済んでいない段階では書き始めないのが安全です。
この2つは、手順書や事実の台帳だけを扱っているうちは意識しなくても回ります。人間関係を書き込む瞬間から、急に効いてくる原則です。
ナレッジは書いた日から古くなる
もう1つ、相関図に特有の性質があります。人の情報は手順よりも早く古くなるということです。担当が替わる、取引が終わる、関係の距離が変わる。手順書は半年放っておいてもだいたい使えますが、相関図は放置すると、実在しない関係を前提にした連絡文を、AIが自信たっぷりに出しかねません。
だからナレッジの鮮度管理は、相関図の場合とくに重要です。関係が変わったと気づいたその場でファイルを直す。もう関係のない相手の記述は消す。ここまでを含めて、相関図をナレッジに入れるという運用になります。
ナレッジを貯めること自体を仕組みにしてしまう方法は、ブログのネタ出しを自動化する仕組みで書いた考え方がそのまま応用できます。思いついたときに書き留める場所を1つに決めておくのが起点です。
なぜ汎用のAIサービスではここまで届かないのか
ここまで読んで気づいた方もいると思います。相関図のようなナレッジは、自分の事業の中にしか存在しない情報です。誰でも使えるチャットAIに毎回貼り付けるには重すぎるし、汎用のSaaSにこの形でそのまま置ける場所はまずありません。人に頼めば、その人が辞めた瞬間にまた最初からになります。
自分のパソコンの中にファイルとして置き、それをAIが読み込んだうえで動く——この形にできるのが、Claude Code・Codexを土台にしてAIエージェントを組む価値です。手順を自動化するツールではなく、自分の事業の文脈を知っている分身を育てる、と考えると腑に落ちると思います。
まずは、いま抱えている案件を1つ思い浮かべて、「これは誰から来た話で、誰に返すのか」を1行書いてみてください。それがあなたのナレッジの4つ目の始まりです。AI Crewでは、こうした自分専用のナレッジの設計を、実際に業務のファイルを一緒に作りながらお伝えしています。気になる方は、まず無料セミナーでお会いしましょう。
