こんにちは、PaperAgentです。Agent（エージェント）ではありません！
昨日、AnthropicのClaude Codeのソースコードが「意図せず開示された」ことで、すでに話題になっています。GitHubで76Kスターを獲得しています。
cli.js.mapから4756個のソースファイルを復元してから、数週間にわたってこのコードの中に没頭し、考古学者のようにシステムプロンプト、エージェント・スケジューリング・チェーン、ツール実行パイプライン、パーミッションモデル、フック機構、スキル・エコシステムなどを一つずつ分解して分析してきました。
正直に言うと、解析する前から強いツールだとは予想していました。しかし解析を終えて、私の感じたのは単なる「強さ」ではありません——そこには設計理念における世代の差がありました。
多くの人はClaude Codeの強さがモデルそのもの、あるいは何か「神秘的なシステムプロンプト」にあると考えています。しかし実際にソースコードを解析するとわかります：これらはすべて違うのです。
その強さは、周到に設計され、エンジニアリングとして実装されているAgentic Harness（エイジェンティック・ハーネス）から来ています。
この概念は私が作ったわけではありません。Anthropicの公式ドキュメントに明確に書かれています：
翻訳すると：Claude Code全体のシステムは、Claudeの外側に巻かれるHarness（ハーネス）そのものです。
提供されているのは単なるチャットインターフェースではなく、「モデルを実行可能なAgentに変換する」一連のランタイム・フレームワークです：ツールの呼び出し方、パーミッションの制御方法、コンテキストの管理方法、サブタスクの編成方法、フックのインターセプト方法……すべてがこのHarnessレイヤーにおいて制度化・製品化されています。
多くの人がコーディング・エージェントを複製する際、システムプロンプト＋ファイル編集ツール＋Bash＋CLIシェルだけを持ち去ろうとします。しかしClaude Codeのソースコードを解析し終えて、私は気づきました：真に差をつけているのは、これらではないのです。
本日の記事では、ソースコードの中で見た「真の差異」を細かく解説します。
https://x.com/ScarlettWeb3/status/2038940065523552263/photo/1
01 それは単なるプロンプトではなく、オペレーティング・モデルだ
まず、最も誤解されやすい問題から見ていきましょう：Claude Codeのシステムプロンプトは一体どれほど神秘的なのでしょうか？
私も最初は、prompts.tsを開けば「神託」のようなものが見えると思っていました。しかし実際に開いてみると、そこにはPrompt Assembly Architecture（プロンプト・アセンブリ・アーキテクチャ）がありました。
getSystemPrompt()は決して静的なテキストを返すだけではなく、それよりはるかに複雑なことを行っています：
まず静的なプレフィックスを組み立てる：アイデンティティの定義、システム仕様、タスク哲学、リスクアクションの仕様、ツール使用の仕様……
次に動的なサフィックスを注入：セッション・ガイダンス、メモリ、MCPインストラクション、スクラッチパッド、トークン予算、アウトプット・スタイル……
さらにソースコードには明確にSYSTEM_PROMPT_DYNAMIC_BOUNDARYが存在し、コメントには直接こう書かれています：境界より前は可能な限りキャッシュ可能、境界より後はセッション固有の内容であり、勝手に変更してはいけない、さもなけばキャッシュ・ロジックを破壊する。
これは何を意味するのでしょうか？
Anthropicはシステムプロンプトのトークンコストとキャッシュヒットまでエンジニアリング・レベルで最適化しているということです。「考えられるものはすべてプロンプトに詰め込む」のではなく、プロンプトを編成可能なランタイム・リソースとして管理しているのです。
静的な部分はキャッシュに適し、動的な部分は必要に応じて注入されます。このアプローチはコスト管理において、「全てを詰め込む」タイプのプロンプトよりも一维度も高いレベルにあります。
しかしこれは氷山の一角に過ぎません。
https://x.com/jungeAGI/status/2039007004333932929
02 良い挙動を制度化した
もう一つ印象的な詳細を見てみましょう：getSimpleDoingTasksSection()のこの部分は、基本的にAnthropicによるAIエンジニアの行動規範の制度化表現と見ることができます。
これはモデルを非常に明確に制約しています：
この部分の意味は、単に「プロンプトが詳細に書かれている」というだけではありません。本質を明らかにしています：Claude Codeは「良い習慣」をモデルの即興に委ねるのではなく、ルールとして書き込み、強制実行するのです。
多くのコーディング・エージェントが不安定なのは、モデルがコードを書けないからではなく、挙動が発散するからです。同じ要件でも、今日は動作しても、明日は「過度のリファクタリング＋大量のコメント追加＋ついでに関係のないファイルを変更する」という謎操作をしてくるかもしれません。
Claude Codeはこの制度化された制約により、挙動の分散を最小限に抑えています。
同様に制度化されているのは、リスクアクションの仕様もです：破壊的操作（destructive operations）、元に戻しが難しい操作、共有状態の変更、サードパーティー・ツールのアップロード……すべてが「確認必須」としてマークされています。ソースコードには明確に要求されています：未知の状態を発見したらまず調査し、マージ・コンフリクトやロックファイルを粗暴に削除してはいけない。
これはブラスト・レイディアス（blast radius、影響範囲）思考です——「破壊の範囲」をモデルの行動基準に書き込むのです。
03 コンテキストが希少リソースであることを深く理解している
ソースコードを解析している間、何度も感嘆したもう一つの点は：Anthropicのコンテキストに対する愛惜の念は、多くの人の想像を超えているということです。
大量の設計がコンテキストを最適化することを中心に行われています：
システムプロンプトの動的・静的境界＋キャッシュ・バウンダリー
fork pathによる親スレッドのプロンプト・キャッシュ共有
スキルのオンデマンド注入、グローバル・プロンプトへの詰め込み回避
MCPインストラクションの接続状態に応じた動的注入
関数結果のクリアリング、ツール結果の要約
compact / transcript / resume メカニズム
その中でも特にfork pathの設計は卓越しています。
モデルが子エージェントをforkすることを決定した際、ソースコードでは特別に最適化されたパスを通ります：親スレッドのシステムプロンプトとツール定義を継承し、APIリクエストのプレフィックスをバイト単位で同一に保ち、プロンプト・キャッシュのヒット率を高めます。
コメントには極めて率直に書かれています：forkは安価だ、なぜならプロンプト・キャッシュを共有するから。
これはどのレベルの最適化でしょうか？
普通の人は「サブタスクが動けばいい」と考えるだけですが、Claude Codeが考えるのは「サブタスクが動き、しかも可能な限りメイン・スレッドのキャッシュを再利用し、トークンを無駄にしない」です。
これは製品レベルのシステム思考であり、デモレベルの実装ではありません。
04 エージェントの役割分担：万能ワーカーではなくスペシャリスト
多くの人はClaude Codeのエージェントを「万能ワーカー」と考えています——タスクを与えれば、自分で分解し、実行し、検証するという具合に。
しかしビルトイン・エージェントを解析してみると、全然違うことがわかりました。
ソースコードには少なくとも以下のビルトイン・エージェントが定義されています：
Explore Agent：読み取り専用モードで、コード探索専用です。そのシステムプロンプトには明確に規定されています——ファイルの作成、変更、削除、移動、リダイレクトによるファイル書き込みは一切不可。Bashではls、git status、git log、git diff、find、grep、cat、head、tailなどの読み取り操作のみ許可されています。
Plan Agent：純粋な計画立案で、編集は行いません。その役割は、まず要件を理解し、コードベースを探索し、ステップ・バイ・ステップの実装プランを出力し、最後に必ず「Critical Files for Implementation（実装に必要な重要ファイル）」を列挙することです。
Verification Agent：これは最も驚かされたものです。そのシステムプロンプトの冒頭で明確に述べられています——あなたの仕事はtry to break it（それを壊すよう試みる）ことです。「実装が問題ないように見えることを確認する」のではなく、能動的に欠陥を探すのです。これは強制的に要求します：ビルドの実行、テスト・スイートの実行、リンター/型チェックの実行、特別な検証の実施、ブラウザ自動化やcurlによる実測の実行、各チェックのコマンドとobserved（観測結果）の出力、そして最後に必ずVERDICT: PASS / FAIL / PARTIALを出力することです。
この設計は、多くのシステムが長年抱えていた問題を解決します：一つのエージェントが調査も計画立案も実装も検証も行うと、結局どの作業も安定しないという問題です。
Claude Codeの選択は：明確な役割分担です。Exploreは読み取りのみ、Planは計画立案のみ、Verificationは破壊的検証のみ、汎用タスクはGeneral Purpose Agentに任せます。
これは「エージェントが3つ増えた」という問題ではなく、アーキテクチャにおけるスペシャライゼーション（専門化）思考なのです。
05 スケジューリング・チェーン：AgentTool → runAgent → query
エージェント・スケジューリング・チェーンを解析し終えて、「Agentic Harness」という言葉への理解がさらに深まりました。
全体のチェーンは以下のように抽象化できます：
AgentTool.call()の責務は「子エージェントに転送する」こと以上のものです——これは本質的にエージェント・オーケストレーション・コントローラー（agent orchestration controller）であり、パーミッション・フィルタリング、MCP依存関係、ワークツリーの分離、foreground/asyncタスクの登録など、多くの処理を行います。
そしてrunAgent()は完全な子エージェント・ランタイム・コンストラクター（sub agent runtime constructor）です：エージェント固有のMCPの初期化、コンテキスト・メッセージのフィルタリング、読み取り専用エージェントのためのclaudeMdスリミング処理、パーミッション・モードの構築、SubagentStartフックの実行、フロントマター・スキルのプリロード、エージェントMCPツールのマージ、そして最後にquery()を呼び出してメイン・ループに入ります。
最も感嘆させられたのは、ソースコードに大量の製品レベルの詳細があることです：recordSidechainTranscript、writeAgentMetadata、registerPerfettoAgent、cleanupAgentTracking、killShellTasksForAgent、cloned file stateのクリーニング、todos entryのクリーニング……
Anthropicはサブエージェントを「動かせるようにする」だけでなく、transcript（書き起こし）、telemetry（テレメトリ）、cleanup（クリーンアップ）、resume（再開）をすべて正式なライフサイクルに組み込んでいます。
これこそが製品レベルのランタイムです。
06 スキル、プラグイン、フック、MCP：インストール可能なだけでなく、モデルが認識可能
多くのシステムにもプラグインやツール、外部プロトコルはありますが、モデル自体は認識していません：どの拡張機能があるか、いつ使うべきか、どう使うかを。
Claude Codeは違います。
スキル・リスト、エージェント・リスト、MCPインストラクション、セッション固有のガイダンス、コマンド統合を通じて、モデルに自身の拡張能力が何であるかを認識させています。
スキルは説明ドキュメントではなく、プロンプト・ネイティブ・ワークフロー・パッケージ（prompt-native workflow package）です：マークダウン・プロンプト・バンドル＋フロントマター・メタデータ＋宣言可能なallowed-tools（許可ツール）で、必要に応じて現在のコンテキストに注入されます。
プラグインは単なるアドオンではなく、プロンプト＋メタデータ＋ランタイム制約の拡張メカニズムです。
フックはランタイム・ガバナンス・レイヤー（runtime governance layer）です：PreToolUseは入力を書き換え、直接allow/ask/denyを与え、preventContinuation（継続の阻止）さえ可能です。PostToolUseはメッセージを追加し、追加のコンテキストを注入できます。
MCPは単なるツールのブリッジではなく、ツール＋それらのツールの使い方の説明を同時に注入できます——getMcpInstructionsSection()はこれらのインストラクションをシステム・プロンプトに組み込みます。
これはMCPの価値が単純なツール・レジストリよりはるかに高いことを意味し、同時にビヘイビア・スペシフィケーション・チャネル（behavior specification channel）でもあります。
07 ツール実行チェーン：直接呼び出しではなく、パイプライン
最後に印象に残った部分は、toolExecution.tsにおけるツール実行のチェーンです。
「モデルが決定→直接関数を実行」というわけではありません。実際のチェーンはおおよそ以下の通りです：
これは標準的なランタイム・パイプライン（runtime pipeline）であり、直接接続された関数呼び出しではありません。
その中でもPreToolUseフックのインターセプト能力は非常に強力です：フックは入力を書き換え（updatedInput）、直接permissionBehavior（allow/ask/deny）を与え、preventContinuationさえ可能です——denyしなくても、フローの継続を阻止できます。
そしてresolveHookPermissionDecision()のこのレイヤー・ロジックは以下を保証します：フックのallowが設定ルールを自動的にバイパスするわけではなく、ユーザー・インタラクションが必要でフックがupdatedInputを提供しない場合、統一されたパーミッション・フローを通る必要があるということです。
フックは強力ですが、中核となるセキュリティ・モデルを迂回していません。
エピローグ：Agentic Harness設計の究極
この4756個のファイルを解析し終えて、私はずっと考えていました：Agentic Harness設計の究極とは一体何なのか？
一言で答えるなら、こう言うでしょう：
プロンプト・アーキテクチャ、ツール・ランタイム、パーミッション・モデル、エージェント・オーケストレーション、スキル・パッケージング、プラグイン・システム、フック・ガバナンス、MCP統合、コンテキスト・ハイジーン、そしてプロダクト・エンジニアリングをすべて統合したシステムのことだ。
多くの人がコーディング・エージェントを複製する際、持ち去ろうとするのは：
一つのシステムプロンプト
一つのファイル編集ツール
一つのBashツール
一つのCLIシェル
しかしClaude Codeの真の防御壁（モート）は、これらすべてを制度化・エンジニアリング化・製品化したHarnessなのです。
一つでも欠ければ、体験は一段階低下します。そしてこれらをすべて正しく、深く、大規模に安定動作するレベルまで作り込むには、「プロンプトを書く」能力だけではなく、一連のシステム・アーキテクチャ思考が必要です。
これこそがAgentic Harness設計の究極かもしれません：より賢いモデルではなく、より完全なシステムなのです。