クロード・コードの深い解体 ソースコード：51万行のコードに隠されたエージェント・アーキテクチャの哲学

最近、AnthropicはネイティブAIコーディングアシスタントをリリースしました。 Claude のレビューに基づく。 @anthropic-ai/claude-code v2.1.88ソースコード1,902のファイルにまたがる51万行のTypeScriptコードからなるこのエンジニアリングシステムは、フル機能のエンドポイントCLIツールの構築方法を示すだけでなく、Head AIラボが大規模モデルと実際の物理システムとの相互作用、権限制御、コンテキスト管理をどのように処理しているかを明らかにするエンジニアリングレベルの分析でもある。

(注：50万行のコードの解析には1時間以上かかった）。

II.プロジェクトのパノラマと設計思想

2.1 コードのサイズと中核的責任

コード・ディレクトリ・ボリュームの分布は、プロジェクトのリソースの偏りの方向性を明確に示している。インフラレイヤーとUIレンダリングレイヤーが大部分を占めている：

モジュール	行	パーセント	中核的責任
utils	180,472	35.2%	パーミッションコントロール、Bashセキュリティインターセプト、メッセージプロセッシングパイプライン、Gitインタラクション、MCPクライアント、その他の基礎インフラストラクチャ
components	81,546	15.9%	React エンドポイントUIコンポーネント（許可確認ダイアログ、コード差分表示、メッセージレンダリングエンジン）
services	53,680	10.5%	APIコールのカプセル化、多層コンテキスト圧縮アルゴリズム、MCPバックエンドサービス、データ分析、OAuth認証
tools	50,828	9.9%	40以上のコアツールの具体的な実装（Bash実行、FileEdit編集、エージェント・ディスパッチ、MCPツールなど）
commands	26,428	5.2%	90以上のスラッシュコマンドのターミナル入力（例：/compact、/model、/mcp）
ink	19,842	3.9%	エンドポイント環境向けの高性能レンダリングエンジンである、独自のInkフレームワークのフォークバージョン。
hooks	19,204	3.7%	パーミッション処理、IDE状態の統合、音声対話ロジックを切り離すためのReactフックを提供する。
bridge	12,613	2.5%	ブリッジブリッジ環境としてローカルマシンにタスクを実行させるリモートコントロールプロトコル
cli	12,353	2.4%	CLIコマンドラインパラメータの解析とバックグラウンドセッションのライフサイクル管理

2.2 建築の航空写真

システムの最下層は多くの基本的なサービスに依存し、上層は洗練されたステートマシンとイベントメカニズムによってエージェントの意思決定と操作を行い、高度なモジュール性を示す。

2.3 横断的な5つの設計原則

これらの51万行のコードを分解した結果、アーキテクチャーの方向性を支配する5つの核となる設計指針を抽出することができた：

1. 能力の境界線としてのツールエージェントは、ツールセットをバイパスして環境を直接操作するためのバックドアを持っていない。ファイルを読むにはFileReadToolを呼び出す必要があり、ファイルを変更するにはFileEditToolに依存し、システムコマンドの実行はBashToolでのみ可能です。システム機能の拡張は、新しいツールの追加と完全に等価です。
2. フェイルクローズド・セキュリティ・デフォルトセキュリティ・プロパティに関わるすべてのデフォルト設定は、極めて保守的です。ツールはデフォルトでは並列実行を許可しません (isConcurrencySafe: false)、書き込み破壊性のデフォルトの仮定(isReadOnly: false)、すべての操作許可がデフォルトでブロックされ、ユーザーに認可を強制する。
3. プロンプト・エンジニアリングよりコンテキスト・エンジニアリングエンジニアリングの焦点は、長いキューでモデルに「あなたが誰であるか」を伝えることではなく、セグメント化されたキャッシュ、ダイナミックな状態注入、マルチレベルのコンテキスト圧縮によって、対話の各ラウンドで完全なコンテキスト環境を動的に組み立てることにある。
4. 高い組み合わせ可能性異なるモジュール間のシームレスな再利用。サブエージェントは、メインスレッドの query() MCP外部ツールはシステム内部の権限チェックパイプラインを再利用し、チームコラボレーションモデルはSubagentの基本実行エンジンを再利用する。
5. コンパイル時の消去は実行時の判断より優れているBunランタイムの使用 feature() Macro [7]は、ビルド時にデッドコード・エリミネーション（DCE）を有効にする。有効化されていない機能が実行時に実行されないだけでなく、最終的に生成されるBundleパッケージには物理的なコードが完全に存在しない。

III.エージェント・ループ：システムの心臓部

に位置する。 src/QueryEngine.ts(1295列目）vs. src/query.ts(1729行)、さらにツール実装レイヤーの StreamingToolExecutor.ts(530行）と toolExecution.ts(1745行)であり、これらが一体となってエージェントを駆り立てる核となっている。

3.1 2層サイクルモデル

エージェント・ループは、従来のwhileループの代わりに、7つの回復パスと10の終了条件を持つ暗黙のステートマシンを構築し、2つのレイヤーで構成される：

QueryEngine（外層のセッション管理）マルチラウンドの状態維持、Transcriptのディスク永続化、SDKプロトコルの適応、APIを扱う。 Token 累積消費量。
クエリループ（内側の単一ラウンド実行）APIコールの開始、ツールの解析と実行、ローカルエラー回復メカニズムに重点を置く。

2つのレイヤー間の接続は、AsyncGeneratorを通して確立される。 yield はメッセージオブジェクトを生成し、外側のQueryEngineはそれを消費する責任を負います。この設計は、3つのエンジニアリング上の問題を解決します：

1. 背圧コントロール: 呼び出し側は、モデルの膨大なストリーミング出力でメモリが溢れるのを避けるため、オンデマンドでデータを取り出します。
2. 意味伝達を混乱させるジェネレーターの .return() すべてのネストされたジェネレーター・インスタンスのクロージャーをカスケードする機能により、ユーザーのキャンセルはすべての基礎となるタスクに即座に伝搬する。
3. フロースルー・コンビネーションサブエージェント runAgent() リターンはまたAsyncGeneratorであり、メインAgentのデータストリームに直接ネストバックされることを可能にする。

3.2 queryLoopのステートマシン設計

クエリループは基本的に while(true) 各反復が「APIコール＋ツール実行」サイクルを表すループ。ループの終了は2つのタイプによって決定される：

• Terminalループを終了し、特定の原因を返す。
• Continueリカバリーパスのトリガー state = next; continue 新しい状態を次の反復に持ち越す。

状態の漏れを防ぐために、システムは断片的な変数の割り当てを使用せず、代わりに一元的に State 構造物：

type State = {
messages: Message[]
toolUseContext: ToolUseContext
autoCompactTracking: AutoCompactTrackingState | undefined
maxOutputTokensRecoveryCount: number
hasAttemptedReactiveCompact: boolean
pendingToolUseSummary: Promise<ToolUseSummaryMessage | null> | undefined
turnCount: number
transition: Continue | undefined
}

ソースコード query.ts:266-268 前節のコメントには、この動機が具体的に書かれている。複数の独立変数の変更を完全なステート割り当てに置き換えることで、開発者はすべての継続サイトですべてのステートを明示的に宣言しなければならなくなり、その結果、コンテキストの矛盾を完全に避けることができる。

3.3 メッセージ前処理パイプライン：軽いコンテキスト管理から重いコンテキスト管理まで

APIリクエストが開始される前に、メッセージリストは「最も軽いものから最も重いものへ」という原則に厳密に従った前処理パイプラインを通過する。システムは、APIクオータを消費する負荷の高い操作の前に、低コストのローカル操作を優先する。

コンテキスト折りたたみは、AutoCompactが呼ばれる前に実行される。なぜな ら、AutoCompactはコストがかかり、細かいコンテキストを破壊するからであ る。

オートコンパクトのトリガーには、以下の式で表される正確な数学的モデルが存在する：

有効コンテキストウィンドウ = モデルコンテキストウィンドウ - max(max_output_tokens, 20000)

トリガーしきい値 = 有効コンテキスト・ウィンドウ - 13000

200kのウィンドウ制限があるモデルの場合、圧縮動作は約167kとなる。 tokens 近くのスタート。注目すべきは、サーキットブレーカーのメカニズムが、3回連続して失敗すると再試行を停止するように設計されていることだ。ソースコードのコメントには、実際の遠隔測定データが引用されている。「全世界で1,279のセッションが50回以上連続して圧縮に失敗し（最大3,272回）、1日あたり約250KのAPIコールを浪費した」。この小さなメカニズムは、大規模なデプロイメントにおけるリソースのブラックホールをブロックする。

3.4 ストリーミング・ツール・アクチュエーターの同時実行制御の本質

モデルが1つのリクエスト内で複数のツールコールブロックを並行して出力する場合、システムはデフォルトで StreamingToolExecutor(ストリーミング実行）。APIストリーミング受信フェーズでは、完全なtool_useブロックを受信するとすぐに実行が開始される。

ストリーミング・アクチュエーターの並行制御モデルは、ツール・パーティショニングの考えに基づいている：

アクチュエーターは、工具の isConcurrencySafe(input) 属性は、連続するセキュリティーツールを「並列パーティション」にグループ化します。非セキュアなツール（たとえば FileEdit。2 つの FileEdit が並行して同じファイルを変更すると、行番号のオフセットや上書きが必然的に発生する）に遭遇するたびに、新しいパーティションが開かれる。パーティション間ではシリアル実行が強制されますが、パーティション内では完全な並列実行が許可されます。
防御設計の1つは、セキュリティチェック関数自体が解析例外をスローした場合、システムはフェイルクローズド原則に従い、同時実行競合のリスクよりもパフォーマンスを犠牲にするよりも、デフォルトで非セキュアツール実行として扱うというものである。

3.5 メッセージの保留とトークンの予算管理

APIから返されるすべての情報が直接フロントエンドに漏れるわけではありません。システムは3種類のメッセージを保留する：

1. プロンプト長すぎエラーreactiveCompact によって保留され、圧縮を試みた後に内部で再試行される。
2. メディアサイズエラーサイズの大きい画像添付ファイルを剥がそうとした後、内部的に再試行する。
3. max_output_tokens エラーシステムが後継コマンドを注入するかどうかを決定するのを待つためにハングする。
   この保留メカニズムの核心は、SDKコンシューマー（デスクトップ・クライアントなど）を保護することである。コンシューマーはエラー・フィールドを受け取るとセッションを終了する傾向があり、中間状態のエラーを隠すことで、内部の回復ループが外部によって早期に中断されないようにする。

モデルが正常な出力を停止したが、テキストが長すぎるためにタスクを完了できなかった場合、システムはトークン予算が十分である限り、モデルを続行するように促すナッジメッセージを注入する。サブエージェントは、無限ハングアップを防ぐために、このバジェットの使用を禁止されている。インクリメントが 3 回連続して 500 トークン未満の場合、モデルはアイドル状態であり、シ ステムは強制終了する。

IV.道具のシステム：制約と能力

ツールシステムは40以上のディレクトリと50,000行近くのコードにまたがっており、エージェントができることはすべて、システムが提供するツールライブラリによって完全に制限されている。

4.1 ツール・インタフェースの6つの機能グループ

Generic Interface Toolでは、約30のメソッドが規定されており、それらは機能的に6つのモジュールに分かれている。そのうちの buildTool 工場出荷時の機能は、過酷なセキュリティデフォルトを注入する：

因果性	デフォルト値	デザインの動機
isConcurrencySafe	false	コンカレント・コンフリクトが発生すると仮定して、シリアル・キューイングを強制する。
isReadOnly	false	書き込み操作機能を想定し、厳格な書き込み権限監査をトリガーする。
isDestructive	false	UI疲労による警告のスパムを防ぐため、破壊的なアクションとして事前に定義されていない。
checkPermissions	allow	内部デフォルトのリリースでは、実際の傍受は、フードの外側のグローバルパーミッションシステムによって処理される。

4.2 ToolUseContextの40以上の状態

インストルメンタル call() メソッドは非常に大きな ToolUseContext これは、根本的なツールが決して純粋な関数ではないことを示している：

上下テキスト段落	使用	省略できない理由
readFileState	ファイル・リード・レコード・キャッシュ	FileEditToolは、モデルによってレビューされていないファイルの編集を拒否するために、このフィールドをチェックする必要があります。
abortController	シグナルハンドルのキャンセル	BashTool によって実行される時間のかかるビルド・コマンドをいつでも中断できるようにする。
setToolJSX	UIレンダー・コールバック・インジェクション	BashToolなどのツールで、ターミナルにプログレス・バー・コンポーネントを直接描画できるようにする。
agentId	インスタンス識別	マスタープロセスとサブエージェントを区別し、別々のCWDディレクトリをバインドする。
contentReplacementState	予算管理	ツール出力の暴走を阻止し、システム・コンテクストが即座に破裂するのを防ぐ。
updateFileHistoryState	歴史的状態ポインタ	文書の変更を追跡し /rewind コマンドの根本的な依存関係を元に戻す

ツール実行後にグローバル状態を変更する必要がある場合（例えば cd (ディレクトリの切り替え）を返すことによってのみ可能である。 contextModifier フィールドは制御された変更の対象となる。そして、この許可はシリアルツールにのみ開かれており、同時に実行されるツールはグローバル環境に干渉することを固く禁じられている。

4.3 コンパイル時の消去とパーティション登録

src/tools.ts 工具の登録とローディングには3つの方法がある：

バンズ feature() ここで重要な役割を果たすのがマクロである。フィーチャーゲートの制御下にあるマクロ require() ブランチが偽と判断された場合、ビルダーはそのロジックを実行しないだけでなく、DCE（デッドコード・エリミネーション）を使って製品から完全に消去する。動的な require() 静的状態での条件文の折り返しをサポート import は機能しないので require()。
工具の組み立て段階 assembleToolPool 厳格なパーティション・ソート戦略が導入されている：ビルトイン・ツールが最初に来て、アルファベット順にソートされる。 MCP ツールをリストの最後に配置します。このハイブリッドでないレイアウトは、サーバー側のプロンプト・キャッシュ・ブレイクポイントが一貫して最後の組み込みツールの後にあることを保証し、動的にロードされたMCPが長期間のキャッシュを無効にすることを防ぎます。

4.4 BashTool: 18ファイルのセキュリティ要塞

Shellコマンドの破壊力はほぼ無制限なので、BashToolは18個のファイルだけで8層の防御システムを構築している。

非常に有益なセキュリティー・デザインがいくつかある：
コンポジット・コマンド物理的隔離システムはtree-sitterを使ってシェルASTを解析する。 cd /path && python3 evil.py SimpleCommandに正確に分割され、サブコマンドのどれかが監査に失敗すると、複合コマンド全体が拒否されます。ReDoS攻撃やイベントループの飢餓を防ぐために、一つのコマンドは最大50個のサブコマンドに分割されます。
フラグレベルのホワイトリスト検証コマンド名だけでなく、パラメータ（Flag）の値もロックされる。例えば xargs -I モデルの悪意ある悪用から守るための入力フォーマット -i プロセスインジェクションを実行するためのGNU variantセマンティクス。
25 構文インジェクションの検出：bashSecurity.ts 25以上の構文固有の検出ロジックが含まれており、コマンドの置換（バッククォートや $())、プロセス置換(<())、Zsh特有のリスクの高い組み込みメソッド(例えば zmodload、syswrite)、制御文字、さまざまな種類のUnicode迷彩空白文字。
サンドボックス環境ポケット：SandboxManager 最終的なセーフティネットのレイヤーは、ファイルシステムへの読み書きパスを制限し、ネットワークアクセスアドレスとUnixソケットを制限することによって構築される。

4.5 FileEditToolの検索置換不変量

行番号ベースの追加/削除ロジックを使用する代わりに、FileEditToolは「検索と置換」を強制する。これは、モデルが old_string コード・ブロックは、ターゲット・ソース・ファイル内で一意に一致しなければならない。もし複数のコードが一致した場合、システムは修正を中断し、一意になるまでさらにコンテキスト・コードを提供し続けるようモデルに要求します。この厳格だが信頼性の高い制約により、モデルが間違った場所を変更するような大惨事は完全に排除される。
一方、前述の readFileState 第二の防衛線は、未読ファイルの編集の禁止である。モデルは自身の「幻覚記憶」からやみくもにファイルを編集することはできない。まずFileReadを使ってファイルの現在の状態を確認しなければならない。

V. コンピテンス・システム：システムの免疫バリア

70以上の文書からなるこのシステムは、「AIの自律的な運用を可能にすること」と「システミックな大災害を防止すること」の間の信頼尺度を微妙に設定している。

5.1 信頼度勾配の連続スペクトル

権限システムは、ロックアウトから完全委任までの6つの段階を定義している：

パラダイム	核となる行動特性	適用ワークフロー
plan	すべての書き込みアクセスを禁止し、モデルはアーキテクチャプランニングとコードレビューにのみ使用できるようにする。	探索的分析と監査
default	デフォルトの起動モードでは、各ツールの呼び出し時に手動確認を要求するUIがポップアップ表示されます。	日常的な開発協力
acceptEdits	ワークスペース内のファイルの読み書きは静かに解放されるが、残りの環境は変更を確認するためにブロックされる必要がある。	信頼性の高いコード・リファクタリング
auto	モデル側にインテリジェントな分類器を導入し、リアルタイムで安全性を判断（内部環境）	高周波オートメーション
bypassPermissions	通常の手動チェックプロセスを完全にスキップし、基盤となるカーネルのブロッキングのみを保持する。	CI環境または管理された隔離容器
dontAsk	インターセプトのプロンプトが表示されたら、ポップアップウィンドウを表示せずにタスクをスキップするために、直接Denyに変換する。	純粋に自動化された無人スクリプト

このモデルと連動して、システムにはStatsigベースのゲーティングメカニズムが組み込まれている。 bypassPermissionsKillswitch.ts リモートヒューズ。ヒューズが Anthropic 大規模なセキュリティ侵害が捕捉された場合、バイパスモードのグローバルクライアントを即座にリモートでダウングレード。auto このモードは autoModeCircuitBroken カットオフのメカニズム。

5.2 配管の多層アセスメントと定期的なマスキング

向けられる rm -rf / この種の繊細な命令は、システムが開発した多層パイプラインメカニズムで評価される：

明示的なAskのルールが絶対的に優先されるたとえ現在 bypassPermissionsユーザーが手動で ask: ["Bash(npm publish:*)"]また、システムは自動実行を中止し、ウィンドウをポップアップする。これは、「ユーザーの明示的なコマンドは常にグローバル・モードを上書きする」という設計思想を実践するものである。
ハードコードされた経路イミュニティ:: へ .git/、.claude/、.vscode/ と端末設定ファイル（例えば .bashrc、.zshrcバイパス・モードに対する修正は、バイパス・モードに影響しないようにハードコードされており、すべてのケースで手動で検証する必要がある。
クラシファイア・ヒューズ保護自動モードでは、AI分類器がコマンドを3回連続で拒否した場合、または1回のセッションで合計20回拒否した場合、システムはインテリジェントな拒否から、ユーザーに介入を求める強制的なポップアップに格下げされます。システムが現在ヘッドレス・モードである場合、システムは直接 AbortError エージェントのプロセスをすべて破壊する。

5.3 ルールソース、構文、マスキング検出

各許可ルールは8つの異なるソースレベルで制御される。企業管理者は policySettings 絶対的な支配権を持っている。 allowManagedPermissionRulesOnly: true その後、システムは事業者が発行したルールブックしか認識しない。

シェルマッチ構文は、完全一致、旧プレフィックスマッチ (npm:*)とワイルドカードの正規表現である。パターン末尾がスペース＋ワイルドカードの場合（たとえば git *の両方にマッチするようにする。 git add ベアコマンドにも対応 git。
ユーザー・エクスペリエンスのペインポイントに対処するためにshadowedRuleDetection.ts ルールマスキングの検出は、コンフィギュレーションファイルに対して行われる。ユーザーが deny: ["Bash"] に置く。 allow:["Bash(ls:*)"] 以前は、評価パイプラインの順序のため、後者には決して到達できず、UIレベルではすぐに赤い警告が表示され、順序を調整するようユーザーに指示していた。

5.4 複数のエージェントで特権を受け渡すための3つのハンドラ

パーミッション・プロセッサーは、異なるタイプのサブディビジョン・エージェントに対して3つのパスに分かれる：

• interactiveHandlerインターフェイスのポップアップで要求される、標準指向の相互作用モデル。
• coordinatorHandlerクラシファイヤー＆フックと連携し、サイレント承認に優先順位をつけ、失敗した場合は手動で介入する。
• swarmWorkerHandler協力 bubble メインラインエンドポイントのリーダーパーミッションブリッジに、プロセスを越えてリクエストを送るバブリングメカニズム。
  エージェントが shouldAvoidPermissionPrompts: true タグの付いた非同期タスクは、裏付け要求に遭遇したときにポップアップするインターフェイスを持たず、単にタスクに対してサイレント拒否（自動リジェクト）を実行する。

マルチエージェント・コラボレーション：群知能の構築

複雑でリードタイムの長い開発タスクに直面したとき、このシステムはタスクの分割とワークスペースの分離によって、ロバストなマルチエージェントアーキテクチャを導き出す。

6.1 3層の抽象化境界

• Subagent非常に軽量な子ノードで、通常は親ノードから同期または非同期でプルアップされ、検索機能で定義されたものと同様のアトミックタスクを実行するために使用される。
• Team/Swarm完全なライフサイクルを持つチームトポロジー。メンバーはリーダーとチームメイトに分かれ、ピアツーピアのコミュニケーション機能を備えているため、フロントエンドとバックエンドにまたがる並行リファクタリングに最適です。
• Coordinator純粋なタスク・オーケストレーター。このモードのノードは、基礎となる読み取り/書き込みツールの起動から除外され、子ノードのレポートの解析とコマンドの発行だけに集中します。

6.2 AgentToolによる統一ルーティング

システム内のサブプロセスに対するすべてのトリガーされたアクションは、一意の AgentTool.この取り組みにより、モデル呼び出しツールの認識オーバーヘッドが大幅に削減される。

エージェントは、組み込みノード(BuiltIn)、ユーザー・オーバーライド(Custom) だけでなく、外部プラグイン (Plugin).コンフリクトは続く built-in < plugin < userSettings < projectSettings < flagSettings < policySettings 階層的上書きの原則。

6.3 非常にカスタマイズ可能な内蔵エージェント

特殊な機能を持つ複数のエージェントは、システムにハードコードされている：
エクスプローラー（検索専用）Haikuモデル（最も安価で高速）に強制的にロックされ、編集／書き込みパーミッションが完全に無効化される。さらに極端なことに、ソースコードのコメントを見ると CLAUDE.md(プロジェクト仕様の設定）とGitステータスの2つは、読み取り専用の巨大なデータだ。週に3,400万件の派生コールがある大規模なデプロイメントでは、この2つの情報を省くだけで、次のことが節約できます。 5-15 Gtok/week 恐ろしい投薬量だ。
検証プロンプトは最も長いプロンプトで、120行近くあり、結論を出す前に標準出力ログだけでなく、特定のテスト実行命令の出力を義務付けることで、LLMが陥りがちな「コードは問題なさそうだからテストはパスするはずだ」という自虐的な幻想に対抗するように設計されています。さらに background: true マーカーは常にバックグラウンドで非同期に計算される。

6.4 サブノード実行エンジンのきめ細かな制御

runAgent() は子ノードの実行負担を引き受ける。そのコア・ロジックは、マスター・ノードの query() 周期的なフレームワーク。
パーミッションのオーバーライドのために、システムは必須のセキュリティ制約ロジックを導入する。 permissionModeを実行することは決して許されない。 bypassPermissions、acceptEdits 和 auto パターンの親ノードが default モード。要するに、サブシステムは、より高いセキュリティ・レベルを装って、グローバルなトラスト・フロー・メカニズムを破ることはできない。

ツールのフィルタリングは、3段階の厳格なスクリーニングを受けた：

1. グローバル無効化テーブル（ALL_AGENT_DISALLOWED_TOOLS）は、全面的にブロックされている。
2. 内蔵されていないエージェント無効化テーブル（CUSTOM_AGENT_DISALLOWED_TOOLS）は、不正なツールをブロックします。
3. 非同期エージェント固有のホワイトリスト制御(ASYNC_AGENT_ALLOWED_TOOLS)。
   で始まる製品はすべて、「」であることは注目に値する。 mcp__ プレフィックス名の外部MCPツールは、上記のルールをすべて無視して完全にリリースされ、外部拡張が内部トポロジータイプによって制限されないことを保証する。

プロプライエタリなMCPリンクの解除、セッション・フック・リスナーのクリーンアップ、割り当て済みプロンプト・キャッシュの強制パージ、ファイル状態キャッシュ辞書の解放、Perfettoパフォーマンス追跡ハンドルの登録解除、Transcriptマッピング・テーブルの空白、孤児のTodoタスクの掃除、終了していないバックグラウンドのbash常駐プロセスの強制終了です。終了していないバックグラウンドのbash常駐プロセスを強制終了する。

6.5 フォーク・サブエージェント：キャッシュ・ヒット率の極端な絞り込み

実験モデルとして、フォークはマスターノードのメモリーコンテキストと対話記録を完全に継承することを目指している。
その中心的な仕事は、プロンプト・キャッシュのヒット率を最大化することである。すべての受信履歴メッセージ構造と tool_use プレースホルダは、データストリームの一番最後に現在の子ノードに固有の命令を 1 つだけ追加することで、ビットレベルの一貫性を保たなければならない。複数のフォークが同時に開始されると、最初の99%のデータ・シーケンスが完全に重なるため、高速プリフィックス・キャッシュの最後尾に直接ヒットする。
再帰による爆発に対する設計も同様に厳しいもので、システムは二重チェック機構を実装している。これは、querySource（アンチ圧縮チェッカー）と、メッセージストリームをスキャンして <fork-boilerplate> ラベルは、無限派生を阻止する二重の保険として機能する。
最後のインジェクション・コマンドでは、「STOP. READ THIS FIRST.」という非常にきつい全角の英語が使われ、LLMの注意を強制的にそらせ、受け継いだ古いIDを無視して新しく割り当てられたタスクを引き継ぐよう要求する。

6.6 Team/Swarm デュアルトラック・バックエンド機構

チームワークをサポートするため、システムは2つのまったく異なる基本アーキテクチャで構築されている：

tmux内にある場合はTmuxBackendを有効にし、iTerm2内にある場合はITermBackendを有効にし、どちらでもないがシステムがtmuxを保持していると検出された場合は外部のTmuxセッションを呼び出し、何もない場合はエラーをスローして強制的に中断し、ユーザーに環境設定を依頼する。純粋なSDK駆動モードでは、システムはIn-processを使用してロックされる。
これら2つのバックエンドは一貫して TeammateExecutor インターフェイスの仕様が違いを遮蔽し、トップレベルに公開されるAPIはすべてシンプルなものだ。 spawn()、sendMessage() 和 terminate()。

6.7 極めて複雑な工程内エンジン

約1,400行のコードからなる src/utils/swarm/inProcessRunner.ts 協業ネットワークの中で最も複雑なハブである。

共有メモリーの特権脱出保護。createInProcessCanUseTool() 洗練された3段階の承認フローが構築された：

1. 通常の許可/拒否チェックを行う。
2. askの場合、バックエンドのClassifierが最初に試行する。
3. 手動介入が必要な場合は、コアコンポーネントを有効にする Leader Permission Bridge(マスターノードの特権ブリッジング）。
   バックグラウンド・タスクは、ブリッジを使用して、フォアグラウンドREPLプロセスの公開された setToolUseConfirmQueue承認結果は、チームメイトのバッジとともにチームメイトに返信され、ホーム画面に特定のチームメイトのバッジが付いた上書き確認ボックスが表示されます。承認結果は preserveMode: true フラグを使用することで、サブシステムがこのパスを通してマスターシステムのグローバルな特権パターンを探ることを完全に遮断することができる。

チームメイトがタスクを完了したときに物理的にプロセスを破棄するのではなく、ハングアップしてピアツーピア通信のダイジェスト（ピアDMダイジェスト）を含むアイドルメッセージをマスターノードに送信する。
非制御的なメモリ膨張のために、このコンポーネントは TEAMMATE_MESSAGES_UI_CAP = 50 ソースコードノートは、悲惨な “くじらセッション ”ストレステスト中に、システムが2分で292のリンクされたエージェントを生成したことを明らかにした。この物理的な制限は、悲惨な "クジラセッション "ストレステストで、システムが2分間に292のLinked Agentを生成し、メモリ消費量が瞬時に36.8GBを超えたことから学んだ教訓です。

6.8 クロスネットワークのメールボックスとコーディネーターの設計コンセプト

独立した物理プロセス間の共同通信は、ローカルファイルシステムの ~/.claude/teams/<teamName>/mailbox/<agentName>/ パスの上で統一された利用 SendMessageTool ルートをマウントする。

通信プロトコルには、構造化された制御フレーム（例えば shutdown_request、shutdown_response 及 plan_approval_request)、ネットワークの自己回復と応答フロー処理能力を可能にする。

さらに上の層へ。coordinatorMode.ts Supreme Commanderの設計指針を公開。TeamCreate、TaskStop、SendMessageなど6つのコマンドツールしか持たない。260行からなる独自のプロンプトは、合成・解析、コマンド発行など4段階のロジックを定義している。
ここにはアンチパターンの核となるタブーが隠されている：“理解するプロセスを委ねてはならない”コーディネータは、子ノードに「あなたの分析に基づいてバグを修正しなさい」というような曖昧な指示を送ることを禁じられ、自分ですべてのコンテキストを噛み砕き、明確なファイルと行番号のポインタを持つ実行命令に変換しなければならない。
コーディネーターがファイルを編集できないのを補うため、コーディネーターは特別なスクラッチパッドディレクトリを持っている。すべてのワーカーは、通常の読み書き承認に関係なく、中間解析成果物をこのディレクトリにドロップすることができる。さらに、このモデルはForkと完全に排他的である。Forkはコマンダーであり、ファイルの状態に対して何の権限も持たず、有効な継承を生成することもできない。

6.9 非同期作業のインフラ：タスクシステム

メイン・インターフェースを長時間ブロックするロジックは、すべて AppState.tasks 集中管理されている。

LocalAgentTask 非常に正確なスケーリングを提供します：呼び出されたツールの総数のリアルタイムレポート、入力と出力を含むグローバルなトークンオーバーヘッドの台帳、および最後の5つの呼び出しのテキスト説明。
InProcessTeammateTask デュアルAbortControllerの制御アーキテクチャは維持される。 abortController マシン全体の物理的な抽出を担当し currentWorkAbortController 現在待機しているツールのポーリングをピンチオフするだけだ。
DreamTask （これらの概念の中で最も具体的なものは、ドリーム・オーガナイザー・タスクで ある。このタスクは、端末がアクティブでない間、デーモンとして自動的に起動し、最近の会話データを再利用し、メモリーファイルに凝縮する。予定外の割り込みがあった場合 kill() このルーチンは、次のリブート時にシームレスな再送信を確実にするために、ロックファイルのmtimeタイムスタンプ・ロールバック技術を自動的に実行する。

6.10 複数のノード間でパーミッションのフルセットを渡す

これら6つの伝達の連鎖は、「最小限の暴露＋権限の範囲を超えた拡散防止」を厳守する。

システム・プロンプト・プロジェクト：再文脈化

入る src/constants/prompts.ts 与 src/context.tsここでのロジックは、暗記型プロンプトの完全な否定である。システムは極めて洗練されたコンテキスト・エンジニアリングを行う。

7.1 メモ化分割キャッシュシステム

巨大なキュー・ワード・バンクは、1つの巨大な文字列に組み合わされるのではなく、別々の文字列に分解される。 string[] 分割されたコンテナ。コア・ドライバーはそのまま Prompt Cache 最適化。

SYSTEM_PROMPT_DYNAMIC_BOUNDARY 分水嶺のようなものだ。その上には、次のような静的定数がある。 scope: 'global' キャッシュ識別子はグローバルユーザーで共有される。多数のリクエストが同じプレフィックス定数にヒットすると、APIコストが崖のように下がるだけでなく、レスポンスタイムも極端に圧縮される。
この境界を越えることは、ユーザーだけの特権である。ソース・コードでは、この境界を破ろうとする関数を DANGEROUS_uncachedSystemPromptSection を開発者に強制するための警告接頭辞です。 _reason コードレビューのための文字通りの数量パラメータ。

7.2 静的体質と専門化戦略

コードの単純化」という原則は、Doing Tasks仕様の段落で何度もモデルに対して強調されている。時期尚早の抽象化よりも、類似した3行のコードの方が良い。これは本質的に、LLMが本来持っている「過剰なエンジニアリングと見せびらかし」の傾向を抑えるための防衛的な指示である。
アクション制御の段落では、権限分離の原則を明示的に宣言している。「ユーザーが一度許可したからといって、すべてのコンテクストで許可されるわけではない」。
特権設定の内部バージョンでは、「デフォルトでコードコメントを書かない」という奇妙な制約まである。アノテーションは、カピバラv8モデルの初期の評価において、モデルが生成した仮説ロジックが29-30%の偽ステートメント率につながることを確認し、アノテーションの全面禁止が最も速い暫定的な妥協となった。
ツールセクションについては、Bashコマンドチェーンの代わりに専用ツールを使用するようモデルが厳密に指定されている（例えば、catの代わりにFileRead）。専用ツールによって提供される構造化された出力と制御された環境は、驚きを大幅に減らすことができる。

7.3 環境検出と動的インクリメンタル注入

セッションの初期化段階ではsrc/context.ts は、レイヤーを検出し、遡って上方にマージする。 CLAUDE.md このファイルは userContext にある。これはここで採用されている --bare ピュアスタートは、自動探索を停止させるとはいえ、以下のようなルールに厳密に従う。 --add-dir 手動マウントのルール、つまり「むき出しとは、積極的に追加しない、入力を受け付けない」ということだ。
これは、分類器の内部的な行き止まりのループさえも壊すことになる：yoloClassifier → claudemd → filesystem → permissions → yoloClassifier。CLAUDE.md ロード後の初回にハードコードされる bootstrap/state.ts キャッシュブロックを提供する。
Git ステートインジェクションは、5 つの情報の流れ (現在のブランチ、マスターブランチ、ワークスペースの状態、直近の 5 つのコミット、オペレーター) を同時に取り込みます。情報の過負荷を防ぐために、ワークスペースの状態は2000文字にハードクロップされ、プロンプトモデルは必要なときにBashToolから完全なログを取得します。
外部のMCPサーバーと通信する場合。isMcpInstructionsDeltaEnabled スイッチは、トポロジーが変更されたときだけ、ダウンストリームを増分するようにコマンドを制御し、重複したバイトの無駄な送信をブロックする。

7.4 4つのディフェンスラインの圧縮と再構築

限られたトークンのコンテクストが枯渇しそうになると、システムは4つの異なるレベルの圧縮防御を可能にする：

オートコンパクト戦略使用されるブートプロンプトは非常にきめ細かく、エラールーティングを含む9つのカテゴリーの情報の保持を強制する。中心的に強調されているのは、「ツール出力に変換されないオリジナルのユーザーコマンドメッセージはすべて保持しなければならない」ということである。 LLMは、要約の段階で「Reduxはダメと言っただけだ」といった追加的なユーザーリクエストを失いがちであり、エンジニアリングは本質的に忘却防止技術である。工学は本質的に忘却防止技術である。
圧縮が完了し、再構築フェーズが開始されると、システムは再び最大5つのコアファイル（各5000トークンが上限）と25000トークンのスキルコマンドのフラグメントを抽出し、ファイルの詳細のビューを完全に失っていないことを確認するために逆再注入を行います。
さらに、オートコンパクトは非常に破壊的であるため、マイルドな漸進的折りたたみ方式であるコンテキスト・コラプスとは当然排他的である-折りたたみモードが有効化されると、オートコンパクトは強制的に抑制される。

ターミナルUI：Reactの高度なレンダリング・エンジンをリファクタリングする

CLIインターフェース全体は src/ink/ ディレクトリ内の90ファイル、約2万行のReactコードが引き継がれた。これによって、粗い出力物としてのCLIのイメージが完全に変わってしまった。

8.1 TS Yogaによるレベル5レンダリングパイプライン

1. React Reconcilerコール react-reconciler リアクトの配置 <Box> Yoga エンジンを底部に搭載したエンドポイント DOM を解析する。 ink-boxConcurrentRoot.React19の並行処理機能をサポートしたConcurrentRoot。
2. ピュアTSリファクタード・ヨガを避けるため、元のインクが参照していたWASMファイルの計算ロジックを削除します。 await loadYoga() ファーストスクリーンのラグと、長時間実行後の線形メモリの肥大化により、すべてのレンダリングインターフェイスを分離レイヤーに移動。 LayoutNode アライメント
3. 常駐オブジェクトプールASCII文字はInt32Arrayで取得される。 CharPool のO(1)インデックス・ヒットStylePool 変換前後の差動シーケンスが直接キャッシュされ、特殊なOSC 8プロトコル用のリンク書き込みを含む HyperlinkPool.5分ごとに実行される時限スカベンジャーは migrateScreenPools まだ活性のある細胞単位（Cells）を回復させ、移動させる方法。

8.2 究極のアンチフリッカー・ハードウェアレベルの最適化

の発生だけを追跡する。 dirty モーションまたは変位によって生成されるビュー領域をマークする。これにより、クロックアニメーションやプログレスバーの回転コンポーネントのCPUオーバーヘッドは、その領域にのみ依存するようになります。
大きなテキストスクロール出力に直面して総当たり再描画を実行する代わりに、基礎となる端末ハードウェアドライバレベルのDECSTBMスクロール機構がシミュレートされる（下記参照）。 CSI top;bot r 及 CSI n S 命令）、同時に内部の prev.screen ディスプレースメント・マッピングは、Diffアルゴリズムがスクリーン上に転がる唯一の新しい線を処理する必要がないように実行される。
ダブルバッファリングメカニズムは、フロントとバックチャンネルの2つのフレームを維持するために使用され、ローダッシュの高周波スロットリング（60fpsで16ms）によって補完される。 leading + trailing (DEC2026モード)、DEC2026プロトコルを介して、BSU(Begin Synchronised Update)とESUは、完全な更新データの前後にカプセル化され、端末画面のフレーム同期アトミックリフレッシュを完全に実現し、ストロボスコピックなちらつきを根絶する。インライン構文解析はまた charCache 計算されたANSI結果を強制的にヒットさせ、時間のかかる操作をスキップする。

8.3 Reduxステートなしでバブリングメカニズムをキャプチャする

洗練されたDOMレベルのイベント・インターセプター（Dispatcher）が組み込まれている。キーボード入力は絶対的な DiscreteEventPriority(即時プラグイン処理権）、ウィンドウのモーフィング（リサイズ）などは ContinuousEventPriority ディザリング合併処理を行う。
重くて冗長なReduxを捨てて、DeepImmutableベースの AppState ネイティブのReact Contextインジェクションとともに、約50のコアステート辞書を保持する。グローバルには onChangeAppState フックは、パーミッションモードの切り替えのような優先度の高い副作用をキャプチャし、リアルタイムで関連するコンポーネントにディスパッチする。

IX.MCPの統合：標準化された能力プラグイン・モジュール

直面した Model Context Protocol (MCP)という業界標準になりつつあるプロトコルで、モジュールを src/services/mcp/ 真ん中だ。

そこ config.ts 企業ポリシー、ローカルプロジェクト仕様など、6つの異なるソースからネットワーク設定をプルする。Claude.aiクラウド環境同期リストに遭遇するとdedupClaudeAiMcpServers 重複排除を引き継ぎ、優先順位の高い制御をローカルコンフィギュレーションに譲る。
新たに発見された外部ツールは、アクセス時に再キャップされる。 mcp__<serverName>__<toolName> この特定のフォーマットは上書きの衝突を防ぎ、そのJSONスキーマ定義はシステム独自のZod保護検証ネットワークに再マップされる。 refreshTools() 外部ノードへの最新の機能変更を取り込む。
内蔵 McpAuthTool 二次認証を必要とするサーバには、特別なインターフェースが提供される。モデル操作がブロックされた場合、処理を中断し、ブラウザ側で OAuth ハンドシェイクを行い、認証情報とともに戻ってくるように指示することで、ユーザーを再認証することができます。

X. 建築のインスピレーションと工学的考察の深さ

この膨大な量のエンジニアリングコードを解剖した結果、Agenticのようなシステムを構築しようとする開発者にとって、以下のような貴重なデザインパターンが生まれた：

絶対的な核となるAsyncGenerator非同期ジェネレーターは実行チェーン全体を処理し、モデル・ストリーミングの並行処理、逆背圧の抑制、安全な失効シグナルのカスケード・ダウン、組み合わせ呼び出しの解決において、プロミス・チェーンの比類なきシステム優位性を実証します。

エクストリーム・フェイルクローズド・セキュリティ・フード同時実行属性を登録しないことは、同時実行が禁止されていることを意味し、読み書き属性を指定しないことは、悪意のある書き込みとして扱われることを意味する。このような設計は、脆弱性がフレームワーク層を通して拒否としてあらかじめプログラムされているものであり、すべてのシステムの基礎となる層でエミュレートされるべきものである。

if-elseのビルド分離はもうやめよう。：feature() 物理レベルでのマクロ[7]は、未完成の機能が本番環境に入る可能性を排除し、潜在的なランタイムの異常やデコンパイルの漏れを回避する。

プロンプト・キャッシュ・サービスのリファクタリング・デザインのすべてツール・リストの非常に慎重な後方および前方順序付けから、システムの体質的なバウンダリー・スライシング、フォーク操作の非常に奇妙な接尾辞補充まで。大規模なシステム・アーキテクチャは、キャッシュ・ヒット率を後回しにするのではなく、「第一級市民」として考慮すべきである。

LLMの欠陥に対する工学的対策例えば、“戻り値を持たない生命令は破棄できない ”ことを義務付ける前の履歴の圧縮は、小さなユーザー要求を破棄して記憶喪失になりがちな大規模な言語モデルの一般化された硬さを補うために工学的な手法を用いている。

レガシー建築の危険どんなに厳格であっても、その中にあっては。 bootstrap/state.ts DO NOT ADD MORE STATE HERE “の警告は、システム内に200以上の辞書フィールドが保持されているグローバル・オブジェクト上に残っている。500,000行の複雑なシステムにとって、依存性注入ベースのきめ細かな状態管理の欠如は赤信号です。
またBashTool このフレームワークの拡張性は、もし検証ロジックを取り除き、OPA（Open Policy Agent）やRegoスタイルの宣言的なエンジン構成に置き換えることができれば、大きく向上するでしょう。
データ永続化レベルでは、ツールフローのフィードバックはまだフラットな文字列の形をしている。これを構造化された検索機能を持つデータレイヤーのストレージに再構成することができれば、長持ちするメモリシステムとContext Collapseが、より正確な折りたたみエントリーポイントを得るのに役立つだろう。
AnthropicがコアモジュールをオープンソースのSDKディストリビューションに抽出することで、将来の進化は切り離され、プラグイン化されるでしょう。

付録：コアエンジンと制御面のインデックス

システムモジュール	スケジューリングの基礎と実施に関する文書	コード量査定
エージェント・ループ・エンジン・コア	src/QueryEngine.ts, src/query.ts	3,024行
ツール・トリアージと同時実行スケジューラ	src/services/tools/StreamingToolExecutor.ts, toolExecution.ts	2,275列
抽象的な方法とツールの組み立て	src/Tool.ts, src/tools.ts	1,181行
バッシュ・フィジカル・サンドボックス・コントロール・サーフェス	src/tools/BashTool/ カタログ (18ファイル)	約5,000列
グローバル・セキュリティ認証監査センター	src/utils/permissions/permissions.ts	約1,400行
ルールのマスキングとインターセプター・ネットワークの評価	src/utils/permissions/ カタログ (24 files)	約5,000列
サブエージェント・タスクのトポロジー・ネットワーク	src/tools/AgentTool/ カタログ (20ファイル)	約6,000列
Swarm チーム間の接続とメールボックス	src/utils/swarm/ カタログ (22 files)	約5,000列
システム・プロンプト組み込み定数	src/constants/prompts.ts	914列
グローバル情報圧縮折りたたみモジュール	src/services/compact/ カタログ (11ファイル)	3,960行
React-Inkハードウェア・レンダリング・コンポーネント	src/ink/ カタログ (90ファイル)	19,842行
MCPプロトコル接続および変換レイヤ	src/services/mcp/client.ts	3,348行
MCP マルチソースの統合とデレイヤリング	src/services/mcp/config.ts	1,578行
ブートシステムバッファの初期化	src/bootstrap/state.ts	約800列
Reactアプリの不変ステートツリー	src/state/AppStateStore.ts	約400列