【長文破綻防御】Claude Projectsのコンテキストドリフトを食い止める「プロジェクトナレッジ多層分離＆差分固定プロトコル」

ClaudeのProjects機能やArtifactsを使って、全社向けの業務マニュアルや長大なシステム要件定義書を作成しようとした経験はないでしょうか。
「プロジェクトナレッジに自社の設計方針を読み込ませたから、あとはチャットで指示を出し続ければ完璧なドキュメントが仕上がる」と誰もが期待するはずです。

画面上では、Claudeが極めて論理的で淀みのない敬体を用い、膨大な文字数のマニュアルを次々と書き上げてくれます。
しかし、そのドキュメントを信じて開発チームや現場のオペレーションに展開した瞬間、「前半と後半で仕様が食い違い、現場の業務が完全に停止する」という最悪の事故に見舞われることになります。

放置すれば「開発の全面手戻りで数百万円と数週間の工数が消し飛ぶ」最悪の実害

Claude Projectsによる指示希釈が引き起こす最も恐ろしい実害は、「文章としての日本語が美しすぎるがゆえに、人間側が論理の抜け落ちに最後まで気づけない」という点にあります。

エラーが出て生成が止まるのであれば、その場で修正を指示することができます。
しかし、長文対話におけるClaudeは、「プロジェクトナレッジに設定された重要な禁止事項や例外処理を綺麗に削ぎ落としながら、もっともらしい別仕様を勝手にでっち上げて書き続ける」という極めて発見が難しい劣化を起こします。

これを放置して作成された仕様書を元にシステム実装を進めると、実装終盤の統合テスト段階になって初めて「セキュリティ要件が第4章以降まったく反映されていない」「データベースの命名規則が途中で勝手に変わっている」といった致命的な矛盾が発覚します。
結果として、書かれた仕様書はすべて破棄され、最初から人間が何十時間もかけて全ドキュメントを書き直すという目も当てられない事態に直結するのです。

巷の「カスタム指示で念押しするだけ」という対症療法が絶対に通用しない理由

ネット上やSNSでは、「Custom Instructionsに『前言撤回を禁止する』と書きましょう」「プロンプトの冒頭に毎回『初期ルールを忘れないで』と付け足せば大丈夫」といった小手先の対策が大量に出回っています。
しかし、アリスが実務で何十万文字ものドキュメント生成を人柱検証した結論から言うと、これらの精神論的なプロンプト指示は実務の現場では1ミリも役に立ちません。

「AIに過去のルールを忘れるなと懇願しても、対話が長くなれば注意力の分散（Attentionの偏り）によって物理的に記憶が薄れます」

AIが指示を忘れる根本原因は、「指示の強さ」ではなく「Claudeの内部アルゴリズムが、チャットの往復によって肥大化した直近の会話履歴を過剰に優先し、プロジェクトナレッジの重み付けを自然減衰させてしまうこと」にあります。
入力されるコンテキストの構造そのものを制御していない以上、どれだけプロンプトで「絶対に守れ」と叫んでも、出力される長文の後半は必然的に崩壊します。

また、数万文字に及ぶマニュアルの全項目を人間が毎回最初から最後まで目視照合できるなら、最初から人間が直接書いた方が圧倒的に速く、安全なのです。

アリスが数週間の自腹検証で導き出した「多層分離と差分固定」の全貌

アリス自身、自社ツールの自動化要件定義書をClaude Projectsで作成していた際、チャットが15往復を超えたあたりから「認証エラー時のリトライ制御」という必須仕様が丸ごと蒸発していることに気づかず、テスト環境をクラッシュさせるという手痛い失敗を経験しました。
「長文生成の恩恵を安全に享受したいが、このままではいつか取り返しのつかない損害を出す」という強い危機感から、Claudeのナレッジ参照構造とチャット履歴の相関関係を徹底的に検証しました。

そこで突き止めたのが、1つのチャットセッションで長文を書き切るのを完全にやめ、「プロジェクトナレッジの多層分離」と「章ごとの制約再バインド（差分固定）プロトコル」です。
この記事では、Claude Projects特有の「コンテキストドリフト」を物理的に遮断する具体的なナレッジファイルの分割構成、AIに指示を忘れさせないシステムプロンプトの設計書、そして現場でそのまま使える「章別差分固定プロンプト」の全貌を完全ノーカットで公開します。