受託でお預かりしているサイトの Project に、資料を一つずつ足しておりました。打ち合わせの議事メモ、旧サイトから抜き出した文章、配色とフォントの決めごと、ページごとの文言案。手元にあるものは全部渡しておいたほうが親切だと考えていたのです。
ところがある朝、いつもの質問——「このページの見出し案を3つください」——を投げたところ、前の週より当たり障りのない答えが返ってきました。どの案も、そのサイトでなくても通ってしまう言葉でした。
資料は増えているのに、答えは浅くなっていました。
足した数と、答えの手触りが逆に動きました
薄くなり方には特徴がありました。事実の間違いが混ざるわけではないのです。書かれていることはおおむね正しく、ただ、どこにでもある言い方に寄っていきます。
たとえば書道家の方のサイトであれば、「筆」「余白」「一枚に向き合う時間」といった言葉が出てくるはずの場面で、「魅力を伝える」「想いを届ける」といった一般的な言い回しが返ってきます。間違ってはいないので、指摘しづらいのが厄介でした。
最初のうち、私は自分の指示が悪いのだろうと考えて、質問のしかたを何度も書き換えておりました。長く書き、短く書き、条件を足し、例文を添えました。どれも芳しくありませんでした。
効いたのは、逆の操作でした。資料を3つ外したのです。すると次の質問で、見出し案にそのサイト固有の言葉が戻ってきました。
浅くなる原因は、量ではなく重なりでした
Projects にアップロードした資料は、会話のたびに全文が丸ごと読まれるわけではありません。質問に関係する箇所が引かれて、根拠として使われます。ここまでは多くの方がご存じのとおりです。
見落としやすいのは、その先です。似た記述が複数のファイルに散っていると、どれを根拠にすべきかが決まりません。結果として、複数の資料に共通して書いてある部分——つまりいちばん抽象的な部分——が残り、それぞれのファイルにしか書かれていない固有の部分が落ちます。
もっと厄介なのは矛盾です。制作の途中で変わった仕様のメモを、変更前と変更後の両方とも置いたままにしておりました。古いほうが引かれた答えを、私は二度ほどそのまま受け取っています。気づいたのは、クライアントに提出する直前でした。胃が痛くなる場面でした。
資料を足すことは、根拠を増やすことではなく、選ばせる手間を増やすことです。 この言い方に落ち着いてから、ファイルを追加する前に一度手が止まるようになりました。
重なりは、目で読む前に数字で見られます
とはいえ、10 枚も 20 枚もある資料を読み比べて重複を探すのは骨が折れます。そこで、フォルダの中のファイルがどれだけ互いに重なっているかを先に数字で出すようにしました。
やっていることは単純です。各ファイルの文章から空白を取り除き、3文字ずつの連なりの集合にして、他のファイルの集合とどれだけ重なるかを測ります。日本語は英語のように空白で単語へ切れませんので、文字の連なりで比べるのがいちばん手軽なのです。
#!/usr/bin/env python3
"""Claude Projects の知識ファイルが、どれだけ互いに重なっているかを測ります。
使い方: python3 kb_overlap.py <知識ファイルを置いたフォルダ>
出力: 被覆率 = そのファイルの言い回しのうち、他のファイルにも既にある割合"""
import sys, pathlib, re
EXT = {".md", ".txt", ".mdx"}
N = 3 # 日本語は単語に切れないので、空白を詰めた3文字の連なりで比べます
def grams(text):
t = re.sub(r"\s+", "", text)
return {t[i:i + N] for i in range(len(t) - N + 1)}
def main(folder):
files = sorted(p for p in pathlib.Path(folder).iterdir()
if p.is_file() and p.suffix.lower() in EXT)
if len(files) < 2:
print("知識ファイルを2つ以上置いてから実行してください")
return
sets = {p: grams(p.read_text(encoding="utf-8", errors="ignore")) for p in files}
rows = []
for p, g in sets.items():
if not g:
continue
others = set().union(*[s for q, s in sets.items() if q != p])
covered = len(g & others) / len(g)
near, near_ratio = max(((q, len(g & s) / len(g)) for q, s in sets.items() if q != p),
key=lambda x: x[1])
rows.append((covered, p.name, near.name, near_ratio))
rows.sort(reverse=True)
print(f"{'被覆率':>6} ファイル")
for covered, name, near, near_ratio in rows:
flag = " ← 畳む候補" if covered >= 0.60 else ""
print(f"{covered*100:5.1f}% {name}{flag}")
print(f" └ 最も近い: {near}（{near_ratio*100:.1f}%）")
if __name__ == "__main__":
main(sys.argv[1] if len(sys.argv) > 1 else ".")手元のフォルダで走らせると、こういう出力になります。請求書と見積書の書式メモをそれぞれ別ファイルに置き、撮影の設営メモを並べた状態です。
$ python3 kb_overlap.py ./knowledge
被覆率 ファイル
72.1% invoice_format.md ← 畳む候補
└ 最も近い: quote_format.md（72.1%）
69.4% quote_format.md ← 畳む候補
└ 最も近い: invoice_format.md（68.1%）
2.9% shooting_setup.md
└ 最も近い: quote_format.md（2.9%）請求書と見積書のメモは、書式の指定がほとんど同じでした。違うのは末尾の数行——振込先か有効期限か——だけです。この2枚は1枚に畳めます。撮影の設営メモは誰とも重なっておらず、そのまま残す側です。
なぜ 60% を目安にしているのかも書き添えておきます。根拠のある数字ではなく、自分の資料で試して落ち着いた値です。日本語の文章は助詞や語尾が共通するため、無関係な文書同士でも 20% 前後は出ます。逆に、書式や定型文を含むファイルは 50% を超えてきます。ですので 60% は「偶然ではなく、同じことを二度書いている」と疑ってよい線として使っております。皆さまの資料では 50% でも 70% でも構いません。大事なのは閾値の正しさではなく、並べ替えて上から見る順番が手に入ることです。
残す・畳む・外すを、三つの問いで決めています
数字が出たら、あとは判断です。私は次の三つを順に当てています。
| 問い | 答えが「いいえ」のときの扱い |
|---|---|
| この資料は、いま正しいと言い切れますか | 外す。古い仕様・変更前の文言・途中で捨てた案は、答えに混ざる危険のほうが大きいので、Project からは下ろして別フォルダへ移します |
| 同じことが、他のファイルには書かれていませんか | 畳む。重なっている部分を1枚にまとめ、固有の数行だけを残します。被覆率が高い組み合わせから順に手をつけます |
| これは事実の参照ですか（判断の基準ではありませんか） | 移す。守ってほしい方針・書き方のルール・優先順位は、知識ファイルではなくカスタム指示に置いたほうが安定して効きます |
三つめは、私がいちばん長く間違えていたところです。「敬体で書く」「専門用語には短い説明を添える」といったルールを、他のメモと一緒に知識ファイルへ入れておりました。ルールは検索で引かれるものではなく、毎回効いていてほしいものです。カスタム指示の書き方そのものはClaude Projects カスタム指示の効果的な書き方に整理してありますので、あわせてご覧いただけると流れがつながります。
畳んだあとの形は、索引1枚と薄い専門ファイル数枚に落ち着きました。索引には、どのファイルに何が書いてあるか、そしてどれが最新かを一覧にしてあります。これを最初の1枚に置いてから、「どこを見ればよいか」を Claude が外すことが減りました。
畳んだあとは、同じ質問を3つ投げて比べています
間引いた効果は、体感では分かりません。私はあらかじめ3つの質問を決めておいて、畳む前と後で同じものを投げるようにしています。
- そのサイトや案件でしか成立しない答えを求める質問（見出し案・キャッチコピー案など）
- 事実を1つ確認する質問（決まった納期・確定した仕様など）
- 判断を求める質問（2つの案のどちらを勧めるか、理由つきで）
あわせて「いまの答えは、どの資料を根拠にしましたか」と一度聞きます。ファイル名が挙がれば、その資料は届いています。挙がらないファイルが続くようなら、不要なのではなく置き場所が違うのかもしれません。カスタム指示へ移すか、その会話にだけ直接貼るほうが早い場合があります。
個人開発で長く運用しているアプリのストア文言でも、同じことをしております。多言語のストア説明文は表現の型が共通するため、言語ごとにファイルを分けると被覆率が跳ね上がります。いまは1枚にまとめ、言語ごとの差だけを箇条書きで添える形にしました。資料の総量は減りましたのに、返ってくる文案は前より各言語の癖を拾ってくれています。
デスクトップアプリから Projects を使っている方は、資料の置き場所そのものを見直す手もあります。ローカルのフォルダを参照させる構成についてはClaude デスクトップアプリ 2026で扱っております。
まずは、いちばん古い資料を1つ下ろしてみてください
今日できることを1つだけ挙げるなら、Project の中でいちばん日付の古い資料を外し、いつも投げている質問を1つだけ投げ直すことです。それで答えが変わらなければ、その資料は害になっていなかったということが分かります。変わったなら、次の1枚に進めます。
私自身、足すことは覚えが早かったのに、下ろすことはずっと後になって覚えました。資料の棚卸しは、月に一度でいいので手順に入れておく。 この一つだけは、忙しい月でも崩さないようにしています。
お読みいただきありがとうございました。皆さまの Project でも、残す1枚が見つかれば嬉しく思います。