この連載について
LLM（大規模言語モデル）を実務で使い倒すために知っておきたい「LLMのクセ」を全10回で解説する連載の第7回です。
- ポチョムキン理解（第1回）
- Lost in the Middle（第2回）
- Context Rot（第3回）
- Sycophancy（迎合）（第4回）
- Context Handoff（第5回）
- Prompt Distillation（第6回）
- Project化の罠 ← 今回
- GPT化の罠
- Instruction Drift
- AI成果物の品質保証
第6回で、試行錯誤の成果を「検証済みの蒸留プロンプト」に変える方法を確立しました。次に誰もが考えるのは、**「これをClaudeのProjectsやCLAUDE.md、ChatGPTのProjectsに載せて、チームみんなで使い回そう」**です。個人の資産を組織の資産に昇格させる——一見、正しい進化に見えます。
ところが、この「Project化」の瞬間に、これまでの回では存在しなかった2つの軸が一気に開きます。**「誰が使うか」（1人→複数人）と「いつまで使うか」（1回→数ヶ月）**です。今回は、この2軸の広がりが生む固有の罠と、まだ確立された定石がない領域だからこそ「実験的」と明記した上での対策案を扱います。
まず、ありがちな失敗を1つ片付ける：詰め込みすぎ問題
筆者の周辺で実際にあった例です。外部接続が制限された環境でワークフローツールが使えないため、ChatGPTのProjectを「組織AI」として構築し、システム解析・差分抽出・テストケース作成・テストDB作成・画面打鍵・差分比較・資料作成という7種類のタスクのための22プロンプト＋18資材、計40ファイルを1つのProjectに詰め込みました。結果、Projectの成果物は単体チャットよりも精度が低くなりました。
原因は、実はこの連載の既出回で説明がつきます。ChatGPT Enterpriseのファイル処理は、一部をコンテキストに直接詰め込み、残りをプライベート検索インデックスに送って検索で引く方式で、しかもGPT系モデルは1プロンプトにつき検索を1回しか行いません。7種類の異種タスクの資材が「COBOL」「テスト」という同じドメイン語彙を共有したまま1つのプールに同居すると、表面的な類似度は高いのに中身は無関係という、第4回で扱ったdistractorの最悪の発生条件が揃います。1回きりの検索は汚染され、必要な資材が漏れ、無関係な資材が混入する。「関連しそうな情報を大量に持たせることが、逆に足を引っ張る」——第3回の「同じ話題は同じチャット」原則の、Project階層での違反です。
この「組織AIをどう設計すべきか」は、それ自体が大きなテーマなので別記事として独立して扱う予定です。今回押さえてほしいのは、この詰め込み問題は既出の原理の再発であって、Project化の本当の罠は、これを正しく回避した"後"に始まるということです。
軸の変化：これまでの回と何が違うのか
| 回 | 劣化が起きる場所 | 人数 | 時間スケール |
|---|---|---|---|
| 第3回 Context Rot | 1つの会話の中 | 1人 | 数時間 |
| 第5回 Context Handoff | 1回の受け渡しの瞬間 | 1人（1対1） | 一瞬 |
| 第7回 Project化 | 永続化された共有資産 | 複数人 | 数ヶ月 |
この2軸の広がりが、5つの固有の罠を生みます。
罠①：分布のミスマッチ——「1人に効いた」は「チームに効く」を意味しない
第6回の蒸留プロンプトは、Step B（APEループ）で検証済みでした。しかし思い出してください。あの検証は、あなた1人のBEFORE/AFTERペア、あなた1人のタスクで行われたものです。
機械学習の言葉で言えば、これは1人分のデータで訓練・検証されたモデルです。それをチーム共有Projectに載せた瞬間、訓練分布とテスト分布のミスマッチが発生します。他のメンバーの暗黙のタスク・文体の好み・前提知識は、元のBEFORE/AFTERペアに一度も登場していません。「1人に効いた指示」が「チームに効く指示」である保証はどこにもないのに、Project化した瞬間、そのプロンプトは暗黙的に「チーム標準」という権威を帯びます。
新メンバーが「この指示、うちのProjectに入ってるから正しいんだろう」と従い、実は自分のタスクには合っていない——このズレは、誰も「元の検証範囲」を知らないため、発見されないまま蓄積します。
罠②：ナレッジベースの静かな陳腐化——数ヶ月スケールのContext Rot
第3回のContext Rotは数時間スケールの話でした。Projectのナレッジベースには、同じ構造の劣化が数ヶ月スケールで起きます。
業界の観測では、エンタープライズのRAG（検索拡張生成）導入は、ローンチ直後ではなく3〜6ヶ月後に採用率が落ちることが多いと報告されています。陳腐化が可視化されるまでにそれだけかかるからです。ある分析では、埋め込み（検索用インデックス）の陳腐化だけで検索精度が最大20%劣化するとされています。
しかも厄介なのは、劣化の仕方です。古いナレッジベースは「自信満々に、古い答えを返す」。4スプリント前に仕様変更された機能のドキュメントが残っていれば、AIはそれを根拠に、不確実性のシグナルを一切出さずに回答します。第1回のポチョムキン理解、第5回の「もっともらしい補完」と同じ悪質さ——間違いが間違いの顔をしていない——が、ここでも発生します。
さらに実務あるあるとして、「Slackに貼られた手順書とConfluenceの手順書が矛盾したまま、両方ナレッジベースに入っている」ケースが挙げられます。検索は律儀に両方を返し、どちらが正しいかをAIが"勝手に判断"することになります。これはプロンプトの工夫では直せません。ナレッジ層そのものの問題です。
罠③：見えないモード切り替え——Projectの「読み方」は勝手に変わる
これは製品仕様レベルの話です。Claude Projectsの公式ドキュメントによると、Projectのナレッジがコンテキスト上限に近づくと、自動的にRAGモードに切り替わり、全文をコンテキストに読み込む方式から「関連部分だけを検索して取り込む」方式に変化します。ナレッジ量が閾値を下回れば、また元の方式に戻ります。
つまり、メンバーがファイルを追加し続けるだけで、Projectの情報の読まれ方が根本的に変わるということです。全文読み込みモードでは「全部がコンテキストにある」（第2回のU字の世界）、RAGモードでは「検索に引っかかったものしかコンテキストにない」（検索漏れという別種のリスクの世界）。この切り替わりの瞬間は、使っている側からは見えません。昨日まで拾えていた情報が、今日ファイルを2個追加したせいで検索漏れする——原因の特定が極めて困難な劣化が起きえます。
罠④：多対多の編集ドリフト——船頭多くして、指示は矛盾する
Claude Projectsの共有機能には「閲覧のみ」「編集可」の権限があり、編集可のメンバーはProject指示やナレッジを自由に変更できます。便利な反面、これは第5回のContext Handoffが「1対1・1回」だったのに対し、多対多・継続的な書き換え合戦が起きうるということです。
Aさんが追加した「出力は必ず表形式で」と、3週間後にBさんが追加した「出力は箇条書きを基本とする」が、同じProject指示の中に共存する。矛盾に気づく仕組みはなく、モデルはその場その場でどちらかに（あるいは中途半端な折衷に）従います。挙動が安定しない原因が指示の矛盾にあると気づくまで、メンバーは「最近AIの調子が悪い」としか認識できません。この「指示が時間とともに濁っていく」問題は、第9回のInstruction Driftで正面から扱います。
罠⑤：権威の固定化——「検証済み」マークは風化する
第6回で、蒸留プロンプトに「検証済み／未検証」の区別と検証モデル名を明記する仕組みを作りました。しかしProject化された資産では、この区別を維持する動機を持つ人がいなくなります。
作成者は「もう完成した」と思って手を離れ、利用者は「Projectに入っている＝公式」と受け取る。検証時のモデルからバージョンが2世代進んでも、誰も再検証しない。Anthropic自身が、Claude Code向けのCLAUDE.md公式ガイドでこのリスクを明言しています——「四半期ごとに見直して古くなったものを消せ。時代遅れの指示は、指示がないより悪い（outdated instructions are worse than none）」。公式ドキュメントが「書いた指示は腐る」前提で運用指針を出している、という事実そのものが、この罠の実在の証明です。
実験的対策案
ここからは対策です。ただし正直に言うと、この領域は登場から日が浅く、確立された定石がまだ存在しません。以下は本連載の第1〜6回で確立した原則（検証は実行で行う・生成より機械的操作・監査データを設計にフィードバック）をProject運用に外挿した実験的な提案であり、それぞれの環境で効果検証しながら使ってください。
対策①：PROJECT_META.md——Projectに「憲法」を持たせる
ナレッジベースの先頭に、Project自体のメタ情報を管理するファイルを1つ置きます。
# PROJECT_META.md (このProjectの憲法)
## 基本情報
- オーナー(編集責任者): {1名。編集はこの人に集約}
- バージョン: v1.3 / 最終棚卸し日: 2026-07-01 / 次回棚卸し予定: 2026-10-01
## このProjectの検証範囲(罠①対策)
- 検証済みのタスク種別: {コードレビュー(Java)、設計書レビュー}
- 検証したメンバー: {A, B の2名のタスクで検証}
- 検証時のモデル: {モデル名とバージョン}
- ⚠ 上記以外のタスク・大幅なモデル更新後の動作は未検証です
## 資材一覧と賞味期限(罠②対策)
| ファイル | 用途 | 追加日 | 賞味期限 | 期限根拠 |
|---|---|---|---|---|
| coding_rules.md | コーディング規約 | 2026-04-01 | 2026-10-01 | 半期改定 |
| api_spec_v2.md | API仕様 | 2026-06-15 | 次回リリース時 | 仕様変更で失効 |
## 変更ログ(罠④対策)
- 2026-07-01 v1.3: 出力形式の指示を統一(表形式に一本化)。旧・箇条書き指示を削除 [B提案/A承認]
ポイントは、検証範囲の明記（罠①：「チーム標準」ではなく「この範囲で検証済み」という正確な権威に格下げする）、資材ごとの賞味期限（罠②：知識の種類によって腐る速度は違うため、一律ではなく資材単位でTTLを設定する）、変更ログの一元化（罠④）の3点です。
このMETA自体の維持も、四半期ごとに次のプロンプトで半自動化できます（AIに下書きさせ、判断は人間が行う分担です）。
これはProjectの四半期棚卸しです。PROJECT_META.mdと現在のナレッジ一覧を
突き合わせて、以下を出力してください。
1. 賞味期限切れ・期限が今四半期中に到来する資材のリスト
2. META.mdに記載がないのにナレッジに存在する資材(無登録資材)のリスト
3. META.mdに記載があるのにナレッジに存在しない資材(幽霊エントリ)のリスト
4. 変更ログの最終記載日以降に変わった可能性のある項目
各項目について「削除候補/更新候補/要確認」のいずれかを提案してください。
ただし実際の削除・更新の判断はしないでください。判断は人間が行います。
「提案まで、判断は人間」と明示的に線を引くのは、第6回で見た通りモデルは何が重要かの判断を分布の重心に引っ張られるためです。棚卸しの実務作業（一覧化・突き合わせ）は機械的なのでAI向き、「消していいか」の判断は人間の仕事、という分担です。
対策②：編集の一本化——「編集可」を配らない
罠④への最も単純で効果的な対策は、編集権限をオーナー1名に限定し、他メンバーは閲覧のみにすることです。変更したい人はオーナーに提案し、オーナーが矛盾チェック（後述のプロンプト）を通してから反映する。コード管理で全員がmainに直接pushしないのと同じ理屈です。
反映前の矛盾チェックには、こう指示します。
以下は現在のProject指示と、新たに追加提案された指示です。
【現在の指示全文】
{現在のProject指示}
【追加提案】
{新しい指示}
追加提案が既存の指示と矛盾・重複していないか点検してください。
- 明らかな矛盾(片方に従うと他方に違反する)
- 暗黙の衝突(状況によって解釈が割れる曖昧な共存)
- 重複(既存の指示で既にカバーされている)
それぞれについて、該当する既存指示を引用した上で指摘してください。
問題がない場合も、どの指示と照合したかを明記してください。
対策③：ゴールデンタスクによる月次回帰テスト
罠①②⑤に共通して効く、この対策案の本丸です。Projectをソフトウェアとして扱い、回帰テストを導入します。
やり方：Project導入時に、「正解の出力が分かっている代表的なタスク」を3〜5個固定します（ゴールデンタスクセット）。第6回のStep Bで使った検証タスクをそのまま流用できます。そして月に1回、同じタスクをProjectに投げ、出力を初回の合格出力と比較します。
(月次で実行。新しいチャットで)
以下のタスクを実行してください。
{ゴールデンタスク#1}
--- 実行後、人間側で以下を確認 ---
- 初回合格時の出力と比較して、品質・形式・内容に劣化はないか
- 劣化があった場合、直近1ヶ月のProject変更ログ(META.md)と突き合わせ、
どの変更が原因かを特定する
出力の比較も、目視だけに頼らず補助プロンプトを使えます。ただし比較を実行するのは、Projectの外の素のチャット（検証対象のProject指示の影響を受けない、中立な環境）で行います。
(Projectの外の、素の新規チャットで実行)
以下は、同一タスクに対する「基準出力(初回合格時)」と「今回の出力」です。
【基準出力】
{ゴールデンタスク#1の初回合格出力を貼る}
【今回の出力】
{今月の出力を貼る}
2つを比較し、以下の観点で差分を列挙してください。
- 内容の差分: 結論・数値・判断が変わった箇所(最重要)
- 形式の差分: 構成・フォーマットが変わった箇所
- 欠落: 基準出力にあって今回の出力にない要素
- 追加: 今回の出力で新たに現れた要素
各差分について「劣化/改善/中立」の仮判定を付けてください。
最終判定は人間が行うため、判定に迷う場合は「要人間確認」としてください。
これは第4回のカナリア（定点観測）の月次版であり、第2回の「監査データを設計にフィードバックするループ」のProject版です。ナレッジ追加・指示変更・モデルバージョンアップという3種類の変化のどれが劣化を引き起こしたかを、変更ログと突き合わせて切り分けられるのがポイントです。逆に言えば、変更ログ（対策①②）なしで回帰テストだけやっても、劣化を検知できるだけで原因が特定できません。対策は3点セットで初めて機能します。
対策④：チーム展開前の「多人数Step B」
罠①（分布のミスマッチ）への直接対策として、Project公開前に、作成者以外のメンバー2〜3名の実タスクで第6回のStep B（アブレーション）を回します。
(展開前に、メンバーCの実タスクで実行)
【条件A】Project指示を全て適用した状態で、Cさんの実タスクを実行
【条件B】Project指示のうち、作成者固有の好みと思われる項目
{該当項目}を除いた状態で、同じタスクを実行
Cさんが両出力を比較:
- 条件Aの方が良い → その指示はチーム汎用として合格
- 差がない/条件Bの方が良い → その指示は「作成者個人の最適化」であり、
チーム標準からは外す(個人用プロンプトに退避)
「1人の最適化」と「チームの標準」を、感覚ではなく実行結果で仕分けるのが狙いです。
対策⑤：ナレッジは意図的にスリムに保つ——モード切り替えを起こさせない
罠③への対策は、シンプルにRAGモードへの自動切り替えが起きる閾値まで、そもそもナレッジを太らせないことです。Anthropic公式もCLAUDE.mdについて「短く information-dense に、目安200行以下」「全ての行がコストに見合うか吟味せよ」と指示しています。
運用ルールとしては、対策①の賞味期限テーブルと連動させて、**「1つ足したら、期限切れを1つ消す」**を原則にする。ナレッジベースを「入れたら入れっぱなしの倉庫」ではなく「定員のある本棚」として扱うイメージです。追加時のチェックには次のプロンプトを使います。
新しい資材{ファイル名}をこのProjectに追加したいと考えています。
追加の是非を判断するため、以下を確認してください。
1. この資材の内容は、既存のどの資材とも重複していないか
(重複する場合、どちらを残すべきかの比較材料を提示)
2. この資材が担う役割を1文で要約すると何か
3. PROJECT_META.mdの賞味期限テーブルに追加する場合の、
妥当な賞味期限と期限根拠の案
4. 現在期限切れ・期限間近の資材のうち、この追加と引き換えに
削除を検討すべき候補
追加/見送りの判断はしないでください。判断材料の提示までを行ってください。
どうしても大量の資材が必要な場合は、それはもはや単一Projectの守備範囲ではなく、フェーズ分割やワークフロー設計の話になります（この設計論は組織AIの回として別途書きます）。
補足：RAGモードの正体——罠③を深掘りする
罠③で触れた「見えないモード切り替え」は、この記事で最も技術的な理解が要る部分なので、仕組みから対処まで掘り下げておきます。
そもそもRAGとは何か：「全部読む」から「検索して読む」へ
RAG（Retrieval-Augmented Generation：検索拡張生成）は、2020年にMetaの論文で提唱されて以来、LLMに私有データを扱わせる際の支配的なパターンになっている技術です。仕組みは3段階です。
- Index（索引化）：文書を「チャンク」と呼ばれる細かい断片に分割し、それぞれを埋め込みベクトル（意味を数値の座標に変換したもの）にして、ベクトルデータベースに保存する
- Retrieve（検索）：質問が来たら、質問文も同じ方法でベクトル化し、「意味的に近い」チャンクを数個だけ引っ張ってくる
- Generate（生成）：引っ張ってきたチャンクだけをコンテキストに入れて、モデルに回答させる
ポイントは、モデルが読んでいるのは「全文書」ではなく「検索に引っかかった数個の断片」だけということです。第2回で「LLMにはシンボルテーブルがなく、attentionという近似的な関連度計算しかない」と説明しましたが、RAGはその外側にもう一段、別の近似的な関連度計算（ベクトル類似度検索）を追加する技術だと言えます。
Claude Projectsでは、これが「勝手に」起きる
Claude公式ドキュメントによると、Projectのナレッジがコンテキストウィンドウの上限に近づくと、RAGモードが自動的に有効化され、容量が最大10倍に拡張されます。全コンテンツを一度にメモリへ読み込む代わりに、Claudeは「project knowledge search」というツールを使って、質問に関連する情報だけを検索・取得するようになります。ナレッジ量が後で閾値を下回れば、自動的に元のコンテキスト方式へ戻ります。
利用者向けの合図は「RAG有効の視覚的なインジケータ」と「Claudeが検索ツールを使う様子が見える」ことだけ。設定も同意もなく、ファイルを追加しただけで、Projectの情報処理の性質が根本から切り替わるわけです。
なぜこれが罠なのか：2つの世界は「失敗の仕方」が違う
コンテキスト方式とRAG方式は、単なる容量の違いではありません。失敗のモードが質的に違います。
コンテキスト方式の世界（第2回の世界）：全情報がコンテキストに存在する。リスクは「存在するのに注目されない」——U字カーブ、attention希釈。情報は少なくとも"そこにある"ので、聞き方を変えれば拾える可能性が残る。
RAGモードの世界：検索に引っかからなかった情報は、そもそもコンテキストに存在しない。これは第5回で扱った「存在しないものへのattentionは計算できない」問題そのものです。モデルは「検索漏れした情報」の存在を知る術がなく、手元にある断片だけで自信満々に回答します。第2回の失敗が「読み損ね」なら、RAGの失敗は「最初から渡されていない」——そして第5回で見た通り、後者の方がはるかに検知しにくい。
さらにRAG固有の弱点が2つ加わります。
弱点①：チャンク分割が文脈を切断する。 索引化の段階で文書は機械的に断片化されます。「ただし、以下の場合を除く」という例外条項が、本文と別のチャンクに切り離されたらどうなるか。検索が本文チャンクだけを引き当てれば、モデルは例外の存在を知らないまま断定します。Anthropic自身がこの問題を認識しており、各チャンクに周辺文脈を付与してから埋め込む「Contextual Retrieval」という手法を公開しています。標準的なチャンク分割と比べて検索失敗を49%削減、リランキング併用で最大67%削減できたと報告されており、裏を返せば素朴なチャンク分割はそれだけ多くの検索失敗を起こしているということです。
弱点②：ベクトル類似度は「意味の近さ」であって「答えを含むか」ではない。 冒頭の実例（7タスク40ファイル）を思い出してください。「テストケース作成」で検索すると、画面打鍵手順書も資料作成テンプレも「テスト」「COBOL」という語彙を共有しているため、ベクトル空間上では全部"近く"に見えます。類似度検索は、distractor（第4回）を区別する能力を本質的に持っていません。むしろ「意味的に似ているが答えではないもの」を優先的に引き当てる装置とすら言えます。
「Lost in the Middleが直る」わけでもない
「検索で絞り込むなら、真ん中問題は解決するのでは？」と思うかもしれませんが、話は逆で、2つの問題は直列に繋がります。RAGで取得した数個のチャンクは、結局1つのコンテキストに並べられてモデルに渡されます。つまり「検索漏れのリスク」を通過した後に、今度は「並べられたチャンク内でのU字カーブ」（第2回）が待っている。RAGはLost in the Middleの代替ではなく、その手前にもう一つ関門を追加する仕組みです。
RAGモードへの対処
①今どちらのモードかを確認する習慣を持つ。 RAG有効時はインジケータが表示され、Claudeが検索ツールを使う挙動が見えます。「昨日と挙動が違う」と感じたら、まずモードが切り替わっていないかを疑う。トラブルシューティングの最初の分岐点です。
②境界線上での運用を避ける。 一番危険なのは、ナレッジ量が閾値の前後をうろうろしている状態です。ファイルを1個足すとRAGモード、棚卸しで2個消すとコンテキストモード——メンバーごと・週ごとに違う世界で作業していることになり、再現性が消えます。対策⑤（スリム維持）で余裕を持って閾値の下に留まるか、大規模ナレッジが本当に必要なら最初から常時RAG前提で設計し、ゴールデンタスク（対策③）もRAGモードの状態で検証する。中途半端が一番悪い。
③ファイル設計を「検索されやすさ」に最適化する。 ファイル名と冒頭に内容を端的に表す記述を置きます（検索はそこを強く見ます）。各資材の冒頭に、次のような検索用ヘッダを統一フォーマットで付けるのが実務的です。
<!-- 検索用ヘッダ(各資材の冒頭に統一で設置) -->
# {資材の正式名称}
- 用途: {この資材が使われるべきタスクを具体的に。例: 単体テストケースの作成}
- 対象外: {似ているが使うべきでないタスク。例: 画面打鍵手順には使用しない}
- キーワード: {検索で引っかかってほしい語を列挙}
- 資材ID: DOC-07
「対象外」を明記するのがポイントです。弱点②（類似度はdistractorを区別できない）に対して、誤って検索された場合でもモデル自身が「これは今回のタスク対象外」と気づける手がかりを資材側に埋め込んでおく、という二段構えです。第2回のJSON CONST・見出し構造化もここで効きます——チャンク分割は見出し等の構造を境界のヒントにするため、構造化された文書は「例外条項が本文から切り離される」事故が起きにくくなります。
④「検索されなかったもの」を検知する仕組みを足す。 RAGの検索漏れは受け取り側から見えない（第5回の原理）ので、第2回のチェックポイントIDを応用します。上の検索用ヘッダの資材IDと連動させて、Project指示に次の一文を入れます。
回答の作成にあたりナレッジ内の資材を参照した場合は、回答の末尾に
「参照資材: DOC-XX, DOC-YY」の形式で、実際に内容を利用した資材のIDを
列挙してください。IDの列挙だけで内容を利用していない資材を含めることは
禁止します。参照した資材がない場合は「参照資材: なし」と明記してください。
ゴールデンタスク（対策③）の回帰テストにこの参照チェックを組み込めば、「今月からDOC-07が検索に引っかからなくなった」という検索層の劣化を、出力側から定点観測できます。なお「IDだけ列挙して中身を使わない」空申告のリスクは第2回・第4回で見た通り存在するため、月次回帰テストでは出力内容とIDの整合を人間が抜き打ち確認します。
まとめ
- Project化とは「誰が使うか（1人→複数人）」「いつまで使うか（1回→数ヶ月）」の2軸が一気に開く操作であり、これまでの回にはなかった固有の罠を持つ
- ありがちな「詰め込みすぎ」問題は既出の原理（第3回・第4回）の再発。本当の罠はその先にある
- 罠は5つ：分布のミスマッチ（1人検証の過学習）・ナレッジの静かな陳腐化（3〜6ヶ月で顕在化、自信満々に古い答えを返す）・見えないモード切り替え（ナレッジ量でRAGモードに自動移行）・多対多の編集ドリフト・「検証済み」マークの風化（公式も「時代遅れの指示は指示がないより悪い」と明言）
- 実験的対策は5点セット：PROJECT_META.md（憲法）・編集の一本化＋矛盾チェック・ゴールデンタスク月次回帰テスト・展開前の多人数アブレーション・ナレッジのスリム維持
- RAGモードは「容量10倍」の代わりに失敗モードが質的に変わる：検索漏れした情報は最初からコンテキストに存在せず、チャンク分割は文脈を切断し、類似度検索はdistractorを区別できない。境界線上での運用を避け、検索用ヘッダ＋参照資材IDで検索層の劣化を定点観測する
- 核心は「Projectをソフトウェアとして扱う」こと。バージョン管理・権限管理・回帰テスト・棚卸し——コードに対して当たり前にやっていることを、プロンプト資産にも適用する
次回は、Project化のさらに先——プロンプトを**Custom GPTや共有ボットとして「製品化」**したときに起きる問題、GPT化の罠を扱います。Projectとの決定的な違いは、利用者から中身が見えなくなること。ブラックボックス化した瞬間、これまでの対策の前提が1つ崩れます👀
参考文献
- Anthropic, Claude Help Center: What are projects? / Retrieval augmented generation (RAG) for projects / Give Claude context: CLAUDE.md and better prompts
- OpenAI Help Center: Optimizing File Uploads in ChatGPT Enterprise
- Atlan (2026). LLM Knowledge Base Staleness: Scoring, Causes, and How to Fix It
- Brainfish (2026). RAG Accuracy Degradation in Production: Why It Happens and How to Stop It