社外に出せない資料から、ノウハウだけを取り出すClaude Code Skillを作った
案件の議事録や振り返りメモに、次にも使える学びが書いてある。それなのに相手先が分かってしまうので、どこにも残せないまま忘れていく。そんな経験はないだろうか。
社名と人名を伏せれば済む話だ、と私も思っていた。ところが公開資料で試してみると、固有名詞をすべて消した文章からでも、検索で元の文書に辿り着けてしまった。
- 固有名詞を消した文章から、出どころが辿れてしまう理由
- 出来事ではなく原理を残す、抽象化の4段階と3つの設定
- knowhow-managerの導入手順と、3つのSkillの使い方
- 5層のチェックと、それでも防げないこと
共有できないのは固有情報であって、ノウハウそのものではない
仕事で得た学びの多くは、固有情報と結びついている。相手先の名前、関わった人、金額、案件がどう進んだか。議事録や提案書をそのまま持ち出せないのは当然で、別の案件の資料に引用することもできない。
しかし、そこに書かれていること全部が秘密なわけではない。「なぜうまくいったのか」「どこで判断を誤ったのか」「次はどうするか」は、誰のどの案件の話かを切り離せば、別の場面でも使える。
あたま副業で相談を受けていると、前の案件で学んだことを次に活かしたい場面がよくあります。でも相手先が分かる書き方では、自分の知識ベースにも入れられなかったんです。
私が困っていたのは2つの場面だった。1つは個人で受けている相談や案件の知見を、相手先を伏せたまま次に活かしたい場面。もう1つは、普段から育てている自分用の知識ベースに、出どころを書けない知見を入れたい場面である。どちらも、固有情報とノウハウを切り分ける作業を手でやるのは手間がかかり、切り分けが甘いと後から取り返しがつかない。
そこで、この切り分けを生成AIに手伝わせ、結果を再利用できる形で溜めていくリポジトリを作った。それがknowhow-managerである。
固有名詞を消しただけの文章は、まだ出どころを辿れる
最初に確かめたかったのは、「固有名詞を消せば特定されない」という素朴な前提だった。非公開の資料で試すわけにはいかないので、公開されている資料を使った。
結果は期待と違った。固有名詞をすべて取り除いても、項目名、並び順、珍しい言い回し、本筋と関係のない数値が残っていると、それらを手がかりに検索して元の文書が見つかった。
固有名詞を消した文章は「持ち主の分からない出来事の記録」にすぎない。構成と言い回しが元のままなので、元の資料を知っている人や、文言で検索した人には出どころが分かる。
手がかりは固有名詞の外にいくつもあった。どれも固有名詞ではないので、置き換えでは取り除けない。
| 残っていると手がかりになるもの | なぜ辿れるのか |
|---|---|
| 項目名、分類名、並び順 | 一覧の形そのものが指紋になる |
| 造語や珍しい言い回し | 一般的な話題語と組み合わせると検索で絞り込める |
| 本筋と関係のない数値や手順の細部 | 偶然一致することが少ない |
| 語順を保った言い換え | 元の資料が見つかった後で決め手になる |
| 経緯の語り | 出来事がそのまま残る |
| 業種や役割を戻してしまうタグ | 本文から消した文脈が分類から復元される |
もう1つ、個々には無害な属性の組み合わせも特定につながる。「北陸の老舗の酒造会社で、従業員は300人ほど、2025年の春に基幹システムを入れ替えた」と書けば、社名がなくても関係者にはほぼ分かる（これはリポジトリに載せている架空の例である）。残すかどうかは「この属性が変わったらノウハウは成り立たなくなるか」で決め、成り立つなら落とす。
残すのは出来事ではなく、そこから取り出した原理
では何を残せばよいのか。置き換えで消せないなら、書き直すしかない。knowhow-managerが採ったのは、出来事を原理まで引き上げてから、自分の言葉と構成で書くという方法である。
見積もりの例で考える。「初回の見積もりは渋られたが、3案を並べたら中間の案で合意した」は出来事である。「見積もりは3案を並べて出す」まで上げると教訓になるが、まだ見積もりの場面でしか使えない。もう一段上げて「選択肢が1つだと相手の判断は『受けるか断るか』になり、複数あると『どれにするか』に変わる」まで来ると、提案書にも社内の稟議にも使える。
この段階まで上げると、別の分野で使えるようになることと、元の形が消えることが同時に起きる。見積もりという語彙も、3案という数も、合意に至った経緯も、原理の説明には要らないからだ。再利用できることと特定されないことは、別々に達成するものだと私は考えていたが、同じ操作の2つの結果だった。
ただし上げすぎると「相手の立場で提案する」のような一般論になる。成り立たない場面を挙げられず、資料を読まなくても書ける内容は、読んでも行動が変わらない。Skillには、原理を書いたら「成り立たないのはどんなときか」を言えるか確かめる手順を入れてある。
抽象化のレベルは3段階から選べる
どこまで上げるかは用途で変わるので、設定で選べるようにした。既定はhighである。
| low（具体） | medium（分野内で一般化） | high（原理） | |
|---|---|---|---|
| 残るもの | 具体的な教訓と手順 | その分野で通用する方法と理由 | 分野をまたいで成り立つ原理 |
| 分野の語彙 | 使う | 使う | 使わない |
| 1資料から残す数 | 数件以上 | 2〜4件 | 1〜3件 |
| 辿られる可能性 | 高い | 中程度 | 低い |
| 向いている場面 | 同じ作業を繰り返すチームの手順集、公開資料 | 同じ職種や分野の中での共有 | 分野をまたぐ共有、出どころを見せたくない場合 |
highで1つの資料から残す数を1〜3件に絞っているのには理由がある。同じ資料から作ったノウハウは日付と文体が揃うので、並べて読むと同じ出どころだと分かり、話題の組み合わせから元の資料を絞り込める。数が多いほど絞り込みやすくなるため、原理として弱いものや重複するものは落とす。
knowhow-managerは3つのSkillでできている
リポジトリの中身は、Claude Codeが読み込む3つのSkillと、補助のスクリプトである（Skillそのものの仕組みは「Claude Code Skillとは？使い方をやさしく解説」にまとめてある）。
| Skill | 役割 | 頼み方の例 |
|---|---|---|
| extract-knowhow | 資料や自分のコメントからノウハウを作って保存する | inboxの議事録からノウハウを抽出して |
| search-knowhow | 溜めたノウハウを検索して参照する | 来週、新規の相手に見積もりを出す。関係するノウハウはある？ |
| check-policy | 設定と運用が秘密保持契約や社内規程に適合するかを判定する | policiesの契約書に照らして、今の設定で問題ないか確認して |
導入はクローンと2つの設定で終わる
必要なのはClaude Code、git、Python 3.9以降で、追加のライブラリは要らない。
git clone https://github.com/sonchu-k/knowhow-manager.git
cd knowhow-manager
# コミット前のチェックを有効にする
git config core.hooksPath .githooks
# 検出したい固有名詞のリストを作る
cp .sensitive-terms.example.txt .sensitive-terms.txt
.sensitive-terms.txtには、ノウハウに残してはいけない固有名詞を1行に1つずつ書く。自分の屋号とその略称、主な相手先の名前、案件のコードネームなどを入れておくと、機械チェックが確実に止めてくれる。このファイルはgitの管理外なので、中身が共有されることはない。
保存されるのは、全文を読んで承認したものだけ
資料をinbox/に置き（このフォルダもgitの管理外である）、Claude Codeに抽出を頼む。Skillは固有情報を特定し、候補を集め、設定されたレベルまで引き上げ、出どころを辿ろうとする人の目で読み直し、機械チェックを走らせる。そのうえで下書きの全文を見せて、保存してよいかを尋ねてくる。
この時点では何も保存されていない。下書きと一緒に、取り除いた情報の種類、資料に書かれておらずSkillが推論で補った部分、迷った点、ノウハウにしなかった候補が示される。「2番の『十数人の部署』は特定できるので削って。3番は保存しない」のように返せば、直した全文がもう一度示される。
ある記述から相手先を推測できるかどうかを最終的に判断できるのは、元の案件を知っている本人だけである。だから保存の手前に、人が全文を読む工程を必ず挟む設計にした。
資料によっては「抽出できるものはなかった」という結果になる。事実の記録だけの資料や、固有情報を除くと何も残らない資料を、無理にノウハウへ仕立てることはしない。
資料がなくても、自分の考えをそのまま残すことはできる。「これをノウハウとして保存して。見積もりは必ず3案出す」と伝えると、Skillは主張を整理して書式に収める役に回る。主張を別のものや一般論にすり替えず、述べていない理由や条件を推測で埋めない。読み取れる原理があれば提案として添え、採用するかどうかは本人が決める。
固有情報を残さないための5層と、それでも防げないこと
固有情報の混入を防ぐ仕組みは5層に重ねてある。
機械チェックは、メールアドレス、電話番号、郵便番号、IPアドレス、登録した固有名詞を見つけるとエラーにし、解消するまでコミットを止める。「株式会社」のような法人格の表記、URL、敬称つきの名前は警告にとどめ、人が見て判断する。
5層あれば十分だろう、と言いたいところだが、そうはならない。防げないことが少なくとも3つある。
- 機械チェックは、文脈から特定できる情報（業種、地域、規模、時期の組み合わせ）と、登録していない固有名詞を検出できない
- highで書いても、同じ資料から複数のノウハウを残すと、話題の組み合わせで出どころを絞り込める
- 元の資料は、抽象化される前の形で生成AIのサービスに送られる
3つめは抽象化のレベルをどう設定しても解決しない。外部サービスへの入力そのものを禁じている契約や規程のもとでは、このリポジトリは使えない。また、派生物や分析結果までを秘密情報に含める規程では、原理に引き上げたノウハウも対象になりうる。
check-policyはこの確認のために用意した。契約書や規程を渡すと、保管、入力、蓄積、利用の4段階に分けて条項ごとに「適合」「不適合」「判定できない」を返し、設定の変更で対応できること、運用の変更で対応できること、誰かに確認が必要なことを分けて示す。疑いが残る条項は「適合」ではなく「判定できない」にする。これは見落としを減らすための下調べであって、法的な判断ではない。
よくある質問
まとめ
共有できないのは固有情報であって、ノウハウそのものではない。ただし固有名詞を消しただけでは、項目名や言い回しから出どころを辿れる。出来事を原理まで引き上げて書き直すと、別の場面で使えるようになり、同時に元の形も消える。
knowhow-managerはMITライセンスで公開している。出せないままの議事録が手元にあるなら、まずは公開されている資料で抽出を試し、どの段階まで上がるかを見てほしい。
私がこのSkillを動かしたのは、まだ公開資料に対してだけである。非公開の資料での運用はこれから始める段階で、原理まで上げたノウハウが別の案件で実際にどれだけ役に立つのかは、まだ確かめられていない。溜まってきたら、検索でどう返ってきたかも含めて続きを書く。
あたまこの記事が役に立てば嬉しいです。よかったら他の記事も見てみてくださいね。
関連記事
コメント