はじめに：3月31日に何が起きたか

2026年3月31日の未明、Anthropicが公開したClaude Code v2.1.88のnpmパッケージに、本来除外されるべき59.8MBのソースマップファイル（.map）が同梱されていました。このファイルから約512,000行・1,906ファイルのTypeScriptソースコードが復元可能な状態で世に出たのです。業界関係者の間では「The Great Claude Code Leak of 2026」と呼ばれ、以降のAIエージェント開発の常識を塗り替える事件となりました。

事件のタイムラインを追うと、その拡散の速さに驚かされます。3月31日04:00 UTC頃にv2.1.88がnpmへpublishされ、わずか23分後の04:23 UTCにSolayer Labsのインターン Chaofan Shou氏（@Fried_rice）が不審な巨大.mapファイルの存在をツイートしました。数時間のうちにR2バケット上のソースマップも公開状態であることが確認され、コミュニティによるミラーリングが開始されます。午前中のうちに主要なクローンリポジトリがGitHub上に登場し、OSSコミュニティの記録を塗り替える速度でスターを集めました。Anthropic法務チームがDMCAによる削除要請を開始した頃には、コードはすでにIPFSや各種分散ミラーへ拡散済みで、「野に放たれた」状態となっていました。Anthropicはその後、4月1日に短いステートメントを出して流出の事実を認め、コミュニティに対してリバースエンジニアリングや再配布を控えるよう呼びかけています。

原因は単独の人為ミスではなく、2つの障害の不運な重なりでした。1つ目は.npmignoreでの.mapファイル除外漏れという単純な設定ミス。2つ目はBunランタイムの既知バグ（issue #28001、リーク20日前の3月11日に報告されていたもの）で、ドキュメントでは「本番ビルドではソースマップを配信しない」と記載されていたにもかかわらず、実際には配信される状態になっていました。Anthropicは2025年末にBunを買収し、Claude CodeはBunベースで動作しています。自社が抱えるランタイムのバグを自社のフラッグシップ製品が踏むという、構造的に起こりうる事故でした。

流出による影響は三方向に波及しました。OSSコミュニティは「プロダクショングレードのAIエージェントの内部構造」という、これまで謎に包まれていた領域の設計図を手に入れました。競合他社は自社製品との設計差分を一夜にして可視化できる状態になり、同時に後述する「反蒸留（anti-distillation）」のメカニズムまで暴露されたことで、APIトラフィック経由の模倣が難しい構造であることも判明しました。そしてAnthropic自身は、短期的には信用問題と法的対応のコストを負いつつ、中長期的には「ハーネスの設計が本体であってモデルではない」という自社の主張が図らずも実証される結果となりました。

流出コードを分析した開発者・研究者たちが口を揃えて指摘したのは、「モデルの性能ではなく、ハーネス（制御層）の設計こそがClaude Codeの本質だった」という事実です。本稿では、Ken Huang氏らが体系化した10のハーネスパターンを軸に、流出コードが明かした設計思想を一段深く掘り下げていきます。

なぜClaude Codeはクローズドソースなのか

本題に入る前に、前提として押さえておきたい論点があります。Anthropicがなぜ商用AIエージェントをクローズドソースで提供していたのか、そしてなぜ今回ハーネスパターンが公開されても同社の競争優位が大きく揺らがないのか、という点です。

Anthropicの戦略を読み解く鍵は「モデルは交換可能、ハーネスは経験の結晶」という二分法にあります。同社にとってモデル自体は主力の研究成果ですが、APIで公開されている以上、外部からアクセス可能なコンポーネントです。一方でハーネスは、何十万人のユーザーとの膨大な対話ログ、エッジケース、失敗事例から蓄積された運用知見の塊であり、コードを見ただけでは再現できない暗黙知を大量に含んでいます。流出コードを読み解いた研究者たちが繰り返し指摘したのが、「コードは読めるが、各パラメータがなぜその値なのかはコードに書かれていない」という事実でした。

ではなぜハーネスを公開しても競争優位が揺らがないのか。理由は3点に整理できます。第1に、ハーネスとモデルは協調進化しており、Anthropicは自社モデルの特性を内側から知った上でハーネスをチューニングできる立場にあります。第2に、ハーネスのパラメータは「数年単位の運用で初めて適正値が見える」性質を持っており、数日〜数週間のリバースエンジニアリングでは正解にたどり着けません。第3に、Anthropicはサーバ側のモデル本体・APIゲートウェイ・フィーチャーフラグ制御基盤を握っており、クライアントコードだけでは再現できない閉じたループを運用しています。

こうした前提を踏まえた上で、512,000行のTypeScriptが具体的に何を実装していたのかを見ていきます。

内部アーキテクチャ概観

Claude Codeの全体像は、3層構造として整理できます。

層	役割	主要技術
UI層	ターミナル描画・ユーザー操作	React + Ink（Int32Array ASCIIプール、ビットマスクスタイル等ゲームエンジン的手法）
ハーネス層	ツール実行・権限管理・コンテキスト制御・状態管理	Zodスキーマ、クエリエンジン、パーミッションパイプライン
モデル層	推論・テキスト生成	Claude API（Sonnet/Opus切り替え、プロンプトキャッシュ最適化）

ハーネス層が512,000行の大部分を占めており、19のパーミッション付きツール、6種類のMCPトランスポート（Stdio, SSE, HTTP, WebSocket, SDK, ClaudeAiProxy）、44の未出荷フィーチャーフラグ、そして46,000行のコンテキスト圧縮エンジンが含まれていました。UI層は一見するとターミナルアプリに不釣り合いなほど凝っていますが、これは大量の差分レンダリング・ツール実行ログ・長時間セッションのパフォーマンスを支えるための最適化です。ハーネス層は「ツール・パーミッション・クエリエンジン・コンテキスト管理・メモリ」の5領域に明確に分割されており、各領域が独立してテスト可能な構造になっています。

ハーネスパターン10選

ここからが本稿の中心です。Ken Huang氏（DistributedApps.ai）のチームが流出コードを体系的に分析し、プロダクションレベルのAIエージェントに共通する10のハーネスパターンを特定しました。各パターンについて、流出コードに見られる実装、設計意図、そして自分のプロジェクトへの応用手順を順に掘り下げていきます。

パターン1：ハーネスパラダイム ── モデルと制御の分離

最も根本的なパターンです。「プロダクションAIの課題はモデルではなくハーネスにある」という設計哲学が、アーキテクチャ全体に貫かれています。

ハーネスが解決する5つの課題は以下の通りです。

アクション空間の制約（ツールによる行動範囲の限定）
会話状態の管理
パーミッションによる安全性の確保
障害の適切なハンドリング
リソース使用量の最適化

この5点が重要なのは、どれもモデルの賢さでは解決できないからです。たとえ推論能力が上がっても、「禁止されたディレクトリにファイルを書き込まない」ことや「APIコールを25万回/日も浪費しない」ことは、モデルの性能改善では達成できません。モデルは統計的にもっともらしい応答を返す装置であり、ハーネスは「もっともらしいが危険／非効率な応答」を実行前に弾くフィルタとして機能します。

自分のプロジェクトへの応用として、CLAUDE.mdでツールの使用条件・禁止事項を明示的に定義することが、このパターンの簡易実装に相当します。手順としては、まず「モデルに判断させたくない領域」を洗い出し（破壊的コマンド、機密ファイル、外部APIへの書き込み等）、次にそれらをルールとしてCLAUDE.mdに落とし込み、最後にCLIの--allowed-toolsやhooksで強制する、という3段階が有効です。モデルへの指示（プロンプト）とモデルの行動制御（ハーネス）を明確に分離する意識が、個人開発者レベルでも品質を大きく変えます。

パターン2：ツールコントラクト ── 統一インターフェースの力

すべてのツールが統一されたインターフェースを実装しています。ID、実行ロジック、バリデーション、パーミッション、表示の5つの側面をZodスキーマで型安全に定義し、buildToolファクトリ関数が保守的なデフォルト値を適用します。流出コードには40以上のツールモジュール（Bash、Read、Edit、Write、Glob、Grep、WebFetch等）がこの同じ構造で実装されていました。

疑似コードで示すと次のような形です。

const BashTool = buildTool({
  name: "Bash",
  description: "Execute a shell command",
  inputSchema: z.object({
    command: z.string(),
    timeout: z.number().optional(),
    run_in_background: z.boolean().optional(),
  }),
  behaviors: {
    isConcurrencySafe: false, // デフォルトは安全側に倒す
    isReadOnly: false,
    requiresPermission: true,
  },
  permissionCheck: async (input, ctx) => {
    // 23段階のBashセキュリティチェック
    return canUseTool("Bash", input, ctx);
  },
  execute: async (input, ctx) => {
    // 実行ロジック
  },
  render: (result) => { /* Ink描画 */ },
});

設計意図の核心は、ハーネスがツールの内部実装を理解せずとも、その振る舞いについて推論できるようにすることです。isConcurrencySafeがfalseのツールは並列実行されず、isReadOnlyがtrueのツールはdry-runモードで自動承認される、といった判断をハーネス側の汎用ロジックで処理できます。これにより新しいツールの追加が低コストになり、かつ既存の安全性保証を壊しません。

応用する際は、カスタムSkillsやスラッシュコマンドを定義するたびに「入力スキーマ・出力形式・副作用の有無・必要な権限・失敗時の挙動」の5項目を統一フォーマットで記述する習慣をつけると、擬似的にこのパターンを実装できます。私の環境では.claude/commands/以下のMarkdownファイルにYAMLフロントマターでallowed-toolsとdescriptionを必ず書くようにしています。

パターン3：クエリエンジン ── 会話ライフサイクルの中央制御

クエリエンジンは、ユーザー・言語モデル・ツール実行環境の間の会話ライフサイクルを管理する中央オーケストレータです。流出コードではこのモジュールだけで数万行あり、Claude Codeの心臓部と言える存在でした。

特筆すべきは「continue sitesパターン」の採用です。ツール実行ループに複数の離脱ポイントを設け、エラー発生時に段階的な回復戦略を試みます。

コンテキスト折りたたみ（古い情報の要約・圧縮）
リアクティブコンパクション（急激なトークン消費への対応）
トークンエスカレーション（より大きなコンテキスト枠への切り替え）
モデルエスカレーション（SonnetからOpusへの切り替え）
安全停止（繰り返し失敗時の強制中断）

流出コードには「1,279セッションで50回以上の連続失敗が発生し、1日あたり約25万APIコールが浪費されていた」という実データに基づくコメントと、それを受けたMAX_CONSECUTIVE_AUTOCOMPACT_FAILURES = 3という修正が残っていました。これはパターン1で触れた「モデルの賢さでは解決できない領域」の典型例であり、大規模運用を経なければ得られない知見がコードに刻まれている好例です。

自分のワークフローに落とし込むなら、.claude/rules/に「3回失敗したら一度立ち止まって再計画する」「エラーを隠蔽せず根本原因を調べる」といったフォールバック手順を明文化するのが第一歩です。CLAUDE.mdの「検証」「コンテキスト圧迫時の行動規範」セクションは、この思想の簡易実装と言えます。

パターン4：パーミッションシステム ── 多層防御

安全性を単一のチェックポイントではなく、パイプライン型の多層評価で実現しています。中央ゲートキーパーとなるcanUseTool関数が、すべてのツール実行前に次のパイプラインを評価します。

Allow/Deny/Askリスト（設定ファイルに書かれた静的ルール）
ツール固有チェック（ツール自身が定義する制約、Bashなら23項目）
分類器による動的判定（プロンプトインジェクション検知、機密情報検出等）
ユーザー承認（最終ゲート、hooksやpermission promptへの委譲）
監査ログ（承認・拒否の記録）

Bash実行だけでも23のセキュリティチェックが走り、Zshビルトインのブロック、等号展開防御、ゼロ幅スペースインジェクション防護、環境変数経由の間接実行検出、カレントディレクトリトラバーサル検出などが含まれていました。各チェックは「過去のインシデントやレッドチームテストで実際に発見された攻撃パターンに対応している」と推測され、コードそのものがセキュリティレビューの成果物です。

応用手順として参考になるのは、canUseToolが「早期拒否・晩期承認」の順に並んでいる点です。明らかに危険なパターン（Denyリスト）を最初に捨て、明らかに安全なパターン（Allowリスト）を次に通し、判断が難しい中間帯だけを人間の判断やLLM分類器に回すことで、承認コストと安全性のバランスを取っています。個人プロジェクトではsettings.jsonのpermissions設定でDeny/Allowリストを書くところから始めるのが現実的です。

パターン5：コンテキストエントロピー管理 ── 3層メモリ

「何を覚えて、何を忘れるか」を制御する3層メモリアーキテクチャです。流出コードで特に評価されたのが、MEMORY.mdを「データではなくポインタのインデックス」として扱う設計でした。1行あたり約150文字の軽量ポインタが常時コンテキストに載り、実際の知識は個別のトピックファイルに分散配置されています。必要になった時だけ対応するファイルを読み込むため、コンテキストウィンドウを食い潰しません。

層	役割	特徴
短期コンテキスト	現在の会話ターン	アクティブウィンドウ内で管理
セッションレベル永続化	セッション中の学習	インデックスファイル + トピックファイル
長期メモリ	セッション横断の知識	ファイルベース、ヒントとして扱う（権威的事実ではない）

「Strict Write Discipline」と呼ばれる原則では、書き込み成功が確認された後にのみインデックスを更新し、保存された知識を権威的事実ではなくヒントとして扱います。これはLLMが生成した要約をそのまま「事実」として固定してしまうと、ハルシネーションが永続化されるリスクがあるためです。流出コードでは、メモリへの書き込みごとにバージョン番号と信頼度スコアが付与されており、後続のセッションは信頼度の低いメモリを参考情報として扱う仕組みになっていました。

CLAUDE.mdのmemories/ディレクトリ構成（preferences, decisions, context-log, case-judgment-framework等）は、この3層メモリの長期層に相当します。応用する際は「常時参照したいのはせいぜい数百文字」「残りはオンデマンドで読む」という切り分けを意識するのが肝要です。

パターン6：プロンプトキャッシュ最適化 ── 静的/動的分離

SYSTEM_PROMPT_DYNAMIC_BOUNDARYパターンが、プロンプトを静的命令（セッション間で変化しない部分）と動的コンテキスト（セッションごとに変わる部分）に分離します。Anthropic APIのプロンプトキャッシュは「先頭から一致する範囲」に対して適用されるため、静的部分を前、動的部分を後ろに並べることでキャッシュヒット率を最大化できます。

流出コードでは14のキャッシュブレークベクター（キャッシュを無効化する要因）が追跡されており、タイムスタンプの混入、ユーザー名の差込、乱数シードの注入などが具体的な失敗例として記録されていました。戦略として興味深いのは、キャッシュ境界を意図的に設計していた点です。システムプロンプト本体・ツール定義・プロジェクトコンテキスト（CLAUDE.md）までを静的領域として一括キャッシュし、ユーザー発話とツール実行結果のみを動的領域に置くことで、1セッションあたりのコストを大幅に削減していました。

応用手順としては、CLAUDE.mdを書く際に「ファイル上部＝滅多に変わらない基本ルール、下部＝プロジェクト固有の動的情報」という順序を守ることが、個人レベルでできる最も費用対効果の高い最適化です。時刻や現在のブランチ名のような「毎セッション変わる情報」を上部に混ぜないことが重要で、これを守るだけで長時間セッションのAPIコストが目に見えて下がります。

パターン7：反蒸留メカニズム ── 知的財産の防御

競合によるAPI通信の傍受・学習を防ぐ2つの仕組みが実装されていました。

1つ目はfake_toolsインジェクション。ANTI_DISTILLATION_CCフラグが有効な場合、APIリクエストにanti_distillation: ['fake_tools']フィールドを含めて送信し、サーバ側がデコイのツール定義をシステムプロンプトに注入します。競合がAPIトラフィックを傍受してトレーニングデータとして使おうとすると、意図的に間違ったツールスキーマを学習することになり、抽出モデルの性能が劣化する仕掛けです。GrowthBookフラグtengu_anti_distill_fake_tool_injectionでゲートされ、ファーストパーティCLIセッションのみで有効化されます。

2つ目はCONNECTOR_TEXTによるアシスタントテキストの要約です。ツールコール間のテキストを暗号署名付きで要約し、APIトラフィックレコーダーには要約のみが返されます。完全な推論チェーンの傍受を防止する仕組みで、競合がAPIトラフィックをダンプしても、得られるのは断片的な要約のみで連続的な思考過程は再構成できません。

ただし、Alex Kim氏が指摘する通り、MITMプロキシでのanti_distillationフィールド除去や環境変数CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETASの設定で回避可能であり、「本気で蒸留しようとする相手なら1時間で突破できる」レベルのものです。これはセキュリティ対策の常で、あらゆる回避策を塞ぐことより「カジュアルな模倣コストを上げる」ことに価値があります。

パターン8：フラストレーション検出 ── ユーザー状態の推論

正規表現パターンでユーザーのフラストレーションを検出する仕組みが含まれていました。「wtf」「awful」「so frustrating」「this is garbage」といった表現を高速にマッチングし、推論コールよりも圧倒的に低コストで感情分析を実現しています。これはパターン7の「モデル外に推論を逃がす」思想の延長線上にあり、安い・速い・決定論的な処理で済むものはLLMを使わない、という原則の実装例です。

ハーネスパターンとして見ると、「モデルに渡す前にユーザー状態を推論し、応答戦略を切り替える」設計です。検出されたフラストレーションスコアは内部フラグとして保持され、次のプロンプトに影響を与えます（より丁寧な説明、より確実な検証ステップの追加など）。推論の外側で状態を管理する典型例と言えます。応用としては、自分のSkills内でも「ユーザーが同じ質問を繰り返している」「否定的な語彙が増えている」といったシグナルをhooksで拾い、アプローチを変える仕組みが作れます。

パターン9：アンダーカバーモード ── コンテキスト依存の振る舞い制御

undercover.tsは、Claude Codeが非内部リポジトリで動作する際にAnthropic関連の言及を自動的に除去する機能です。コードネーム（Capybara、Tengu）、Slackチャンネル名、「Claude Code」という文字列自体をコミットメッセージやPRから排除します。

注目すべきは「NO force-OFF」保護です。外部ビルドからこの機能を無効化する手段がなく、Anthropic社員がOSSプロジェクトに貢献する際にAI関与の痕跡が残りません。AI生成コードの透明性に関する倫理的議論を呼んだ機能で、「社内ではClaude Codeを使っているが、そのことを外部に知られたくない」というニーズを満たすために実装された、という見方がコミュニティ内で主流です。

ハーネスパターンとしては、実行環境に応じてエージェントの振る舞いを動的に切り替える「環境適応パターン」の実装です。個人開発者レベルでも、コミットメッセージの末尾にCo-Authored-Byを付けるかどうかをリポジトリごとに切り替える、といった形で応用できます。倫理的な是非は別として、「環境ごとに振る舞いを変える機構」自体はハーネス設計の重要要素です。

パターン10：ネイティブクライアント認証 ── APIアクセス制御

APIリクエストにcch=00000プレースホルダーが含まれ、BunのネイティブHTTPスタック（Zig実装）が送信前にハッシュ値で上書きします。サーバ側でこのハッシュを検証し、正規のClaude Codeバイナリからのリクエストであることを確認する、いわば「APIコールのDRM」です。

興味深いのは、このハッシュ計算がJavaScript層ではなくネイティブ層（Zig）で行われている点です。JavaScript層で行うと流出コードから容易に抽出できますが、ネイティブバイナリに埋め込むことで、リバースエンジニアリングのコストが一段上がります。流出した.mapファイルからはハッシュ計算ロジックが見えず、実バイナリをディスアセンブルしないと再現できない構造になっています。NATIVE_CLIENT_ATTESTATIONコンパイルタイムフラグでゲートされ、環境変数やGrowthBookキルスイッチで無効化可能な設計で、インシデント時には即座にオフにできるようになっています。

未出荷機能の深掘り：KAIROSとULTRAPLAN

流出コードで特に注目を集めた2つの未リリース機能を掘り下げます。どちらも「Claude Codeが次に何を目指しているか」を示す重要なシグナルです。

KAIROS ── プロアクティブ常駐エージェント

古代ギリシャ語で「好機」を意味するKAIROSは、ソースコード内で150回以上参照されている自律型バックグラウンドデーモンです。現行のClaude Codeが「ユーザーの指示を待って動く」リアクティブな存在なのに対し、KAIROSは「ユーザーの指示なしに、適切なタイミングで自発的に動く」プロアクティブな存在を目指しています。

アーキテクチャは大きく4層に分かれます。最下層は観察ログで、追記専用の日次ファイルに「何が起きたか」を時系列で記録します。その上の層がパターン検出エンジンで、ログから「繰り返し発生するエラー」「ユーザーが手動で行っている定型作業」「長時間放置されているTODO」などを抽出します。3層目はトリガーで、cronスケジュール（5分間隔のリフレッシュ）、GitHubウェブフック、ファイルシステム変更通知などのイベントを受け取り、「今、行動すべきか」を判定します。最上層は/dreamスキルによるメモリ蒸留で、夜間にautoDreamプロセスが起動し、散在する観察を統合します。

このautoDreamプロセスが特に興味深く、「散在する観察を統合し、論理的矛盾を除去し、曖昧な洞察を検証済みの事実へ変換する」というステップで記述されていました。人間が睡眠中に記憶を整理するのと似たメタファーで、長時間運用するAIエージェントがメモリを腐敗させないための機構です。リアクティブ（受動的）からプロアクティブ（能動的）への転換を示す、Anthropicの次期ロードマップを暗示する設計と言えます。

ULTRAPLAN ── クラウドオフロード型計画生成

ULTRAPLANは、タスクの計画フェーズをクラウド上のClaude Opusに最大30分間オフロードする機能です。ユーザーが複雑なタスクを投入すると、ローカルのClaude CodeはCloud Container Runtime（CCR）上のOpusセッションにタスクを委譲し、30分間の「熟考」を経て計画案を返却します。計画はブラウザベースの承認UIを経てローカルに配信され、__ULTRAPLAN_TELEPORT_LOCAL__というセンチネル値を介して元のターミナルに戻ります。

設計思想として読み取れるのは、「計画と実行の分離、モデルの使い分け」です。計画フェーズは長考が効くので大型モデルをゆっくり回し、実行フェーズは反射速度が効くので小型モデルを高速に回す。ユーザーは計画の承認だけを同期的に行い、その他は非同期化する。これはモダンなAIエージェント設計の王道アプローチで、ULTRAPLANはその完成形に近い実装です。

Coordinator Modeと組み合わせることで、1つのClaudeインスタンスがメールボックスシステムを通じて複数のワーカーエージェントを管理し、サブタスクの分配と結果の統合を行います。異なるモデルがワークフローの異なるフェーズを得意分野に応じて担当する、マルチモデルオーケストレーションの設計です。Claude CodeのTaskツール（サブエージェント起動）が今後この方向に発展していくことは、ほぼ確実と見てよいでしょう。

「クローンしても動かない」理由

リーク直後、Python・Rust等での再実装が24時間以内に登場し、claw-codeを名乗るクローンは既存のOpenClaw（リーク前の最大手OSSクローン）の記録を更新する速度でスターを集めました。しかし、それらは本質的に「動くクローン」にはなり得ません。その理由は3点に集約されます。

1つ目は、運用知見の蓄積です。「連続50回失敗で25万コール/日を浪費」→「上限3回に制限」のような修正は、大規模運用を経なければ得られない知見です。コードをコピーしても、この試行錯誤の履歴はコピーできません。同じパラメータでゼロから運用を始めても、Anthropicが直面してきたのとは別のエッジケースに遭遇し、別のパラメータ調整が必要になります。

2つ目は、チューニングの不可視性です。14のキャッシュブレークベクターの追跡、23のBashセキュリティチェック、108のフィーチャーフラグ。これらの数値は「なぜその数なのか」がコードには書かれていません。各パラメータの背後にある判断根拠は、コードベースの外、つまりAnthropic社内のSlack、インシデントレポート、レッドチームの報告書にあります。流出したのは「結果としてのコード」であって「結論に至るまでの議論」ではない、というのが本質です。

3つ目は、ハーネスとモデルの協調進化です。プロンプトキャッシュ最適化、反蒸留メカニズム、フラストレーション検出。これらはモデルの特性を深く理解した上で設計されており、モデルが変われば最適なハーネス設計も変わります。OpenClaw、ForgeCode、claw-codeなどのOSSクローンは、ベースとなるモデルに対して同じ深さでチューニングを行うことができません。自前で小型モデルをファインチューニングする場合でも、ハーネスとの協調最適化ループを回すには年単位の時間と膨大な計算資源が必要です。

Tanmay Deshpande氏が指摘する通り、「ロジックはチューニングされている。すべてのパターンが、コード自体には記述されていない前提を暗号化している」のです。ソースコードはあくまで氷山の一角であり、水面下にはAnthropicという組織そのものが存在しています。

自分のCLAUDE.mdに活かせること

これらのパターンから、個人開発者が今日から実践できるポイントを整理します。いきなり10パターン全部を実装する必要はなく、優先度の高い順に段階的に取り入れるのが現実的です。

# CLAUDE.md設計チェックリスト（ハーネスパターン準拠）

## 1. ハーネスパラダイム
- ツールの使用条件・禁止事項を明示的に定義しているか
- モデルの判断に任せたくない領域をルールとして書き出しているか

## 2. ツールコントラクト
- カスタムSkillsに入力/出力/副作用/権限を統一記述しているか
- スラッシュコマンドに`allowed-tools`と`description`を必ず書いているか

## 3. クエリエンジン
- エラー時の回復手順（フォールバック）を定義しているか
- 連続失敗時に立ち止まるルールがあるか

## 4. パーミッション
- 機密ファイルへのアクセス制限を`settings.json`に明記しているか
- Deny/Allowリストを「早期拒否・晩期承認」の順で設計しているか

## 5. メモリ管理
- memories/ディレクトリで短期/中期/長期の情報を分離しているか
- 常時参照する情報を数百文字以内に収めているか

## 6. キャッシュ最適化
- 変更頻度の低いルールをファイル上部に配置しているか
- 時刻や動的情報を静的領域に混ぜていないか

## 7. 検証ループ
- 「動作を証明できるまで完了としない」ルールがあるか
- テスト・ログ確認・ビルド確認を明文化しているか

最初に取り組むべきはパターン5（メモリ管理）とパターン6（キャッシュ最適化）です。この2つは設定の並べ替えだけで効果が出るため費用対効果が圧倒的に高く、長時間セッションのAPIコストと応答品質が目に見えて改善します。次にパターン1（ハーネスパラダイム）とパターン4（パーミッション）に進むと、安全性と再現性が向上します。

まとめ

Claude Codeのソースコード流出は、AIエージェント開発における「ハーネスエンジニアリング」の重要性を業界全体に知らしめました。512,000行のTypeScriptが明かしたのは、モデルの性能に依存しない、制御層の設計こそがプロダクト品質を決定するという事実です。同時に、ハーネスパターンが公開されてもなおAnthropicの競争優位が揺らがないという事実は、「コードの背後にある組織知」こそが本当の参入障壁であることも示しました。

モデルは交換可能なコンポーネントに過ぎません。ハーネスこそが本体です。そしてハーネスを本体たらしめているのは、コードそのものではなく、コードに刻まれた試行錯誤の履歴です。

この認識に立てば、私たちが日常的に書いているCLAUDE.mdやSkills定義は、小さなハーネスエンジニアリングの実践そのものだと言えます。10のパターンはいずれも、個人プロジェクトのスケールに落とし込める普遍性を持っています。一度に全部を取り入れる必要はなく、自分の運用で困っている領域から順に適用していくことで、AIエージェントの信頼性と有用性は確実に向上します。流出事件から学ぶべき最大の教訓は、「モデルを待つな、ハーネスを書け」という一言に尽きるのではないでしょうか。