組織が AI との協働をどう構造化すべきかを示すリファレンスモデル
Jose Martinez · 2026 年 10 月 1 日 · v1.8.1（Claude Code で計測。2026 年 10 月 1 日に Anthropic のドキュメントと再照合済み）
5 行でまとめると。
- 組織はツリー構造だ。会社、業務ライン、プロジェクト、タスクという階層がある。しかし Claude のプロジェクトはフラットだ。チャットには 3,000 文字の組織ブロックが 1 つあるだけで、チャットや Cowork のプロジェクトはネストも継承もしない。プロジェクト内では、コネクタアカウントは個人または組織全体に属し、決して特定の部門（ブランチ）には属さない。
- そのため、すべてのプロジェクトが業務ラインのルールを手作業でコピーすることになり、コピー同士にズレが生じ、どのルールがその回答を生み出したのか誰にも分からなくなる。
- Anthropic はすでにこのツリー構造を 2 度構築している。Claude Code はフォルダごとに指示をネストさせ、2026 年 10 月 1 日以降は個人の mod よりも組織の mod を先に実行するようになった。Slack 上の Claude Tag は、組織からワークスペース、そしてチャンネルへと指示と認証情報を継承する。だがどちらも「プロジェクト」には届いていない。同じモデルで実現できるはずだ。業務ラインのレイヤー、そのフォルダから生まれるプロジェクト、型付きタスク、モデルが読み込む前に競合を弾くコンパイラ、そして Team プランでも機能するノードごとの権限——これらである。
- 私はこれを Claude Code で 2 回計測した。相反する組織ルールとプロジェクトルールを別々の CLAUDE.md レベルに配置し、どちらも強制力を持たせなかった場合、20 回中 20 回ともプロジェクトルールが勝った。同じ組織ルールを言葉だけで「強制」とマークした場合も、20 回中 20 回勝った。優先順位を決めていたのは構造ではなく、どのレイヤーを編集する人でも書き換えられる「文言」だったのだ。
- これは今日すでに動く。私が作ったデスクトップアプリは、ツリー構造の中で Claude Code を実行する。各レイヤーを CLAUDE.md としてマウントし、そのノードでユーザーが実行できる操作だけを Claude に許可し、矛盾が書き込まれた時点で拒否し、すべての回答をそのルール、トークン数、レビュアーとともにログに残す。計測の結果、ツリー構造はフラットなコピーに比べて読み込む指示トークンが 20〜34% 少なかった。
組織はツリーだ。会社が方針を定め、業務ラインが基準を定め、プロジェクトがそれを 1 つの案件に適用し、タスクが 1 つの成果物を生み出す。私が携わってきた品質管理システムはすべてこのように作られており、ほぼすべての企業ファイルサーバーにあるフォルダツリーも同じだ。会社、業務ライン、年、そして案件ごとに 1 つのフォルダがあり、そのすべてをエンコードした案件番号で命名される。
AI プロジェクトはフラットだ。ここで Claude を例に挙げるのは、私が毎日使っている製品だからであり、すでに 2 つの自社インターフェースで答えを出しているからだ。Claude のチャットではプロジェクトをネストできず、組織の指示は最大 3,000 文字の単一ブロックとして全員に適用される。Enterprise では、管理者がグループごとに権限のスコープを設定できる。Team では、ロールが組織全体に適用される。チャットや Cowork のドキュメントには、指示を部門や業務ラインへ、さらにその下のプロジェクトへと受け渡す仕組みは一切記載されていない。Enterprise ではスキルやプロジェクトをグループと共有できるが、それは「配布」であって「継承」ではない。
欠けているのはまさにこのレイヤー、つまり組織とプロジェクトの間をつなぐ層だ。本稿では、何が欠けているのか、なぜそれが重要なのか、実際にどれほどのコストがかかるのか、そして権限やデータ構造を含め、あらゆるプラットフォームが実装できるリファレンスモデルを提示する。
1. 今あるもの
2026 年 9 月 29 日〜10 月 1 日の Anthropic ドキュメントと照合済み。Claude にはチームの作業を実行する 4 つのインターフェースがあり、それぞれ独自の指示モデルを持っている。
権限はプランによって異なる。
Anthropic は権限についてはツリーの半分を作っている。 Enterprise ではカスタムロールをグループに割り当てられ、「カスタムロールは、どのコネクタ、およびそのコネクタ上のどのツールをそのロールが使用できるかも制御する」。プラットフォーム全体を通じて、組織・ロール・ユーザーの各レベルで「最も制限の厳しいレベルが優先」され、メンバーが持つ複数のロールは加算される。管理者は「有効なロールを表示」でき、「付与元」ラベルも確認できる。グループごとに支出上限も設定可能だ。しかしこれらはフラットなグループであり、ツリーではない。しかも、どれも「指示」には及ばない。最も近いのはプラグインだ。Enterprise では、オーナーが特定のグループに対してプラグインとそのスキルを必須またはデフォルトインストールにでき、適用順序も明記されている（「グループ設定、次に組織全体設定、最後にマーケットプレイスのデフォルト」）。だが対象は人のグループであってプロジェクトではない。プロジェクト間で何かを継承することはなく、スキルは依然として Claude が関連すると判断したときにのみ読み込まれる。Team には組織全体のロールと個人単位の共有しかない。プラグイン設定について、ドキュメントは「グループ設定はない」と明言している。しかも Team は中小企業向けに設計されたプランなのだ。
Anthropic はプロジェクトの外側で、ツリー全体を 2 度構築している。
Claude Code では、フォルダ単位で。 Claude Code は 4 つの階層から CLAUDE.md ファイルを読み込む。「見つかったすべてのファイルは互いに上書きするのではなく連結されてコンテキストになる」。順序は「ファイルシステムのルートからワーキングディレクトリに向かって」であり、サブディレクトリのファイルは「オンデマンドで読み込まれる」。組織のブロックは、各マシンに管理ファイルとして配置するか、管理コンソールからのテキスト（claudeMd キー）として渡せる。ドキュメントはこの限界についても率直だ。Claude はこれらのファイルを「強制される設定ではなくコンテキストとして扱う」し、「2 つの指示が矛盾する場合、Claude はどちらかを任意に選ぶ可能性がある」と書かれている。
Claude Tag では、Slack チャンネル単位で。 Claude Tag はチームの Slack 内で動く Claude であり、Team と Enterprise でパブリックベータ版が提供されている。設定はスコープに紐づき、「スコープとはバンドルが適用される場所のこと。Default Slack access（組織全体のルート）、ワークスペース、または単一のチャンネル」を指す。本稿の残りの部分で求める 3 つの要素が、すでにここには揃っている。
• 指示は継承される。 「スコープごとのカスタム指示は連結される。Default Slack access が最初、次にワークスペース、そしてチャンネル。チャンネルの指示は、上位の設定を置き換えるのではなく追加する。」
• 認証情報はブランチに属する。 チャンネルでは、管理者がスコープに紐づけたサービスアカウントを使って Claude が動作する。「最も狭いスコープの認証情報が使われる。チャンネルはワークスペースに勝ち、ワークスペースは Default Slack access に勝つ。」
• アクセスの出所を確認できる。 コネクタ、リポジトリ、プラグインの各行には、より広いスコープからの「Inherited from（継承元）」、またはバンドルからの「Attached from（添付元）」が表示される。支出は組織全体およびチャンネルごとに上限が設けられ、チャンネルごとにレポートされる。
限界もドキュメントに記載されている。このツリーは Slack の形をしている。3 つの固定階層しかなく、Slack チャンネルはネストできない。指示は「強制力のあるガードレールではなくガイドライン」であり、スコープ間の矛盾をチェックする仕組みは記載されていない。「すべてのタスクと、誰が依頼したかのアクションごとのログはない」。そしてプロジェクトの手前で止まる。「claude.ai のプロジェクトはここでは適用されない。Claude は Slack 内でプロジェクトの指示やナレッジを読み取らず、チャンネルをプロジェクトに向けることもできない。」
2026 年 10 月 1 日に変わったこと。 Claude Code 2.1.287 で、早期アクセスだった mod が有効になった。これはプラグイン内の関数で、Claude Code の内部で実行され、プロンプトやシステムプロンプトの一部を書き換えたり、ツール呼び出しをブロック・書き換えしたり、権限要求を承認・拒否したり、インターフェースにペインを描画したりできる。ここで重要なのは次の 3 点だ。
• 宣言された順序を持つ。 組み込みのガードと組織独自の mod が最初に実行され、その後で個人がインストールした mod が実行される。「最初の mod が最も外側にある。他の mod より先にイベントを受け取り、他の mod の後に結果を受け取り、他の mod を実行するかどうかを決定する。」ガードが読み込まれる環境（管理設定のあるマシン、または Team や Enterprise でのログイン）では、個人の mod は「システムプロンプト、管理対象の CLAUDE.md、その他の管理対象の指示」を変更できず、deny ルールが拒否したツール呼び出しを承認することもできない。これこそ、本稿が求めている「構造による優先順位」だ。ただしこれはロックではなくデフォルトだ。--safe-mode を付けて Claude Code を起動した人は、インストール済みの mod（組織のものを含む）なしで実行するが、管理対象フックと deny ルールは引き続き適用される。
• 順序には 2 つのオーナーがいる。 組織の mod は個人の mod より先に実行される。組織が選択すれば、後から実行させることもできる。業務ラインのための階層は存在しない。管理コンソールから配信される設定は「組織内のすべてのユーザーに一様に適用される。グループごとの設定はまだサポートされていない。」グループごとに異なるポリシーを適用したい組織には、いずれも IT 部門を経由する 2 つの手段がある。グループのマシンごとに異なる設定ファイルを展開するか、「IdP グループごとに管理設定を配信する」セルフホストゲートウェイを運用することだ。
• チャットには届かず、Cowork への対応もまちまちだ。 「mod は Claude Code CLI と、Claude デスクトップアプリの Code タブで動作する。」mod はプラグインの hooks/hooks.json に同梱されるが、Anthropic のプラグインサポート表では、このファイルはチャットにおいて「Ignored（無視）」とされている。同じ表で Cowork は「Loads（読み込み）」となっている。「Claude デスクトップアプリの Cowork はセッションを Claude Code 上で実行する」ためだ。ただし mod のページに Cowork は記載されておらず、私もテストしていない。そこで組織が制御できる範囲はより狭い。Cowork セッションにおいて、Claude Code は「ユーザーが Team または Enterprise アカウントでサインインしている場合でも、claude.ai 管理コンソールからサーバー管理設定を取得しない」。リモートの Cowork セッションには読み込むデバイスポリシーが存在しない。
現在展開中のもの。 Cowork は Claude に統合されつつある。ヘルプセンターには「Claude Cowork は単なる Claude になった」と記載されており、まずは Pro と Max で適用され、Team と Enterprise は「現在のチャットと Claude Cowork のまま維持される」。2026 年 10 月 6 日、Pro と Max での新しい Cowork タスクはクラウドに移行する。また、新しいバージョンのプロジェクトが Pro と Max でパブリックベータ版となり、まず Claude Code から始まり、チャット、Cowork、Team、Enterprise も順次対応する予定だ。ここでは「プロジェクトは 1 つの会話」であり、Claude がそれを並列スレッドに分割する。それでも階層は 1 つだけだ。「プロジェクトは 1 人のユーザーに属し」、「ベータ期間中はプロジェクトに対する組織レベルの制御はない。」
つまり、ツリー構造は Anthropic にとって新しいアイデアではない。コードではフォルダ単位で、Slack ではチャンネル単位で既に存在しており、どちらでも組織が最優先される。企業が作業を格納する場所、すなわち「プロジェクト」にだけは、親も上位の業務ラインもない。同じ方向を指す Anthropic の他の 2 つの提供形態は本稿の範囲外だ。Claude for Government はテナント、グループ、組織の連鎖を通じて設定を解決し、サードパーティプロバイダー上の Claude Desktop はグループごとのポリシーをベータ版で提供している。
2. なぜ重要なのか
プロジェクトはコンテナではない。 実際の案件こそがコンテナだ。キー（案件番号）、親（業務ライン）、ライフサイクル（開始、終了、年ごとのアーカイブ）、フォルダ、クライアント、担当者、ルール、成果物を持つ。一方、Claude のプロジェクトにあるのは自由記述の名前だけで、キーも親も子もなく、ドキュメント化されたライフサイクルはアーカイブと削除のみだ。Cowork はプロジェクトをローカルフォルダに紐づけられるが、手作業で 1 つずつ行う必要があり、キーのパターンも親も存在しない。業務ラインによっては年間数百件の案件が発生する。その結果、悪い選択肢が 2 つ残る。案件ごとに手作業で Claude プロジェクトを作り、それぞれにルールをコピーするか、業務ラインごとに 1 つのプロジェクトを作り、異なるクライアントのコンテキストが隣り合って混在するかのどちらかだ。
荷重経路が断絶する。 構造工学では、すべての荷重が基礎まで連続した経路を必要とする。部材を 1 つ取り除けば、それより上は何も下へ伝わらない。ルールも同じだ。組織とプロジェクトの間にレイヤーがないと、業務ラインの基準、テンプレート、承認ルールが置かれる場所がなくなる。そのため、すべてのプロジェクトが手作業でコピーを持つことになる。
コピーは乖離していく。 あるプロジェクトでルールを修正しても、他は古いバージョンのままになる。各プロジェクトはそれぞれのローカルチェックには合格する。不一致が発覚するのは、誰かがプロジェクトを横並びで比較したときだけで、規制業界ではたいてい監査人がそれを行う。インフラチームはこの失敗をよく知っている。Firefly の 2026 年の調査では、回答者の約 3 分の 1 がコンフィギュレーションドリフトを高額な障害の原因に挙げ、約 5 人に 1 人がそれを検出・修正するプロセスを持っていなかった。
アイデンティティもフラットだ。 多くの人が複数の組織をまたいで働いており、それぞれに隔離されたコンテキストが必要だ。しかしチャットや Cowork では、コネクタアカウントは部門ではなく個人に属する。Enterprise のロールはグループが使えるコネクタを決定でき、管理者は組織全体に対してコネクタを一度だけ承認できる。カスタムコネクタなら、全員で 1 つの共有認証情報を使うことさえ可能だ（ベータ版）。いずれにしてもアカウントは個人か組織のものであり、部門のものにはならない。2 つのクライアントを担当するコンサルタントは、各クライアントの Drive をそのクライアントのプロジェクトに紐づけることができない。共有プロジェクトでは問題はさらに深刻になる。「コネクタはプライベートプロジェクトでのみ利用可能」だからだ。Claude Tag は別の設計が可能であることを示している。Slack チャンネルにサービスアカウントを紐づけられるし、それがどこで止まるか（プロジェクトの手前）も示している。Anthropic の Google コネクタのページは接続された Google アカウントが 1 つであることを前提としており、変更するには切断して再接続するしかないと記載されている。以下の 3 つのオープン Issue は複数アカウントを求めている。境界線は人間の頭の中にしかなく、これこそが音もなく破綻する手動の境界線の典型だ。
どのルールが適用されたか誰にも分からない。 Claude Enterprise は管理者に権限の「有効なロールを表示」し、Claude Code の /context はどのメモリファイルが読み込まれたかをリストアップする。今の Claude Code の mod は独自のペインを描画できるので、有効な指示のビューは誰でも構築できる。Claude Tag は各コネクタとリポジトリに継承元のスコープをラベル付けするが、指示についてはドキュメントで「Claude に管理者の指示を繰り返すよう頼む」と書かれているだけだ。ある回答がどのレイヤーのどの指示から生まれたのかを示すインターフェースは存在しない。来歴がなければ監査証跡はなく、監査証跡がなければ品質管理システムは成り立たない。
人々はその一部を求めている。 Anthropic の公開 Issue トラッカー（github.com/anthropics/claude-code）のオープン Issue（2026-10-01 確認時点）。
7 つ目の #47741 は組織管理の CLAUDE.md を求めていたが、Claude Code にすでに存在するためクローズされた。まさにこれが要点だ。レイヤーは Code と Slack には存在し、Issue 群はそれが「プロジェクトがある場所」でも必要だと訴えている。
3. 本当のコストと、トークンが隠すもの
3.1 トークンは障壁ではない
レイヤーが増えればメッセージごとのコンテキストが増え、AI はトークン課金だ。この説明は半分しか正しくない。従量制の Enterprise プランでは API 料金で課金されるため、コンテキストの増加は収益減ではなく収益増を意味する。Team では追加利用を有効にしない限り席数料金は固定で、追加トークンはメンバーが週次上限に早く到達する形で現れる。そして同じトークンで課金される Claude Code は、すでに 4 階層のカスケードを搭載している。トークンが障壁なら、そんなものは存在しないはずだ。3.2 節で計測したところ、私たちが指示を追加する前の Claude Code 自身のシステムプロンプトとツールで約 30,200 トークン。プロジェクトの全指示を加えても 3.5〜5.2% の増加にとどまった。
3.2 具体的な計算例
各画像のタグ：REAL = 2026 年 9 月 29 日から 10 月 1 日の間に計測、または Anthropic ドキュメントと照合したもの。EST = シミュレーション。IND = 説明用の例。
まずは計測から。 1 つのデモプロジェクトに対し、同じ質問を Claude Code（claude -p、Claude Sonnet 5.5）で条件ごとに 5 回実行し、Claude Code 自身が報告した入力トークンを取得した。9 月 30 日に Claude Code 2.1.286 で、10 月 1 日に 2.1.287 で実行したが、指示の数は同一だった。プロジェクト指示を一切入れずに実行した分を差し引くと、各構成にかかるコストが残る。
以下のシミュレーションでは示せなかったことが 2 つある。同じルールでも、カスケードはコンパイル済みファイルより 224 トークン多く消費する。追加ファイルには必ずオーバーヘッドが発生するからだ。ここではアプリ自身のマーカーと各階層ファイルの見出し、さらに Claude Code が読み込んだ各ファイルに付加する枠組みがそれに当たる。階層が増えるほどオーバーヘッドも増える。また、Claude Code は公開トークナイザーの推定値（× 1.30 補正後）よりも実際に 21〜26% 多く読み込んでいた。この差の一部も同じファイル単位のオーバーヘッドだ。比率はこの影響を受けても成立するが、絶対的な金額は成立しない。したがって、シミュレーションの金額は低めに出ていると読んでほしい。
次に企業規模でシミュレーション。 架空の企業における 1 か月分の指示トークンをシミュレーションした。3 つの業務ラインに 40 名、アクティブプロジェクト 250 件、ラインごとに 6 種類のレポートタイプ、1 営業日あたり 1 人 35 メッセージ（5 メッセージずつのセッション）、合計 29,400 メッセージ。トークン数はサンプルの指示文を Anthropic の公開レガシートークナイザー（Anthropic 自身が Claude 3 以降について「非常に大まかな近似」と呼んでいるもの）で計数し、Claude 4.7 以降のトークナイザー向けに 1.30 倍した。組織ブロックは 597 文字のサンプルから上限の 3,000 文字へ外挿し、業務ラインマニュアルは 953 文字のサンプルの 3 倍とした。価格は Claude Sonnet 5.5 のリスト価格（入力 $2、5 分キャッシュ書き込み $2.50、キャッシュ読み込み $0.20 / 100 万トークン）。プロンプトキャッシュは 5 分で、ヒットするたびに更新される。
• フラット（現在の回避策）： 組織ブロック、続いて各プロジェクトが持つ業務ラインマニュアルのコピー、6 つすべてのレポートテンプレート、プロジェクト固有の詳細。
• ツリー： 組織、業務ライン、使用中のレポートテンプレートのみ、そしてプロジェクト固有の詳細。共有頻度の高い順にコンパイル。
表の背後にあるサイズ：組織ブロック 830 トークン（3,000 文字）、業務ラインマニュアル 729、レポートテンプレート 1 つ 147、プロジェクト固有の詳細 98（四捨五入済み。合計は丸め前に計算）。シミュレーションは、組織ブロックの前に置かれる Claude 自身のシステムプロンプトを無視している。
正直な注意点が 2 つ。第一に、ツリー構造自体がトークンを節約するわけではない。−29% は型付きタスクによるものだ。6 つすべてではなく、作成中のレポートに対応するテンプレートだけが読み込まれる。−62% は主に共有頻度の高いレイヤーを先にコンパイルすることによるもので、数百のプロジェクトがバイト単位で同一のプレフィックスを共有する。6 つのテンプレートをすべて読み込んだ状態でも、順序を最適化するだけで共有キャッシュのコストは $36 から $18（−51%）になり、型付きタスクが残りを埋める。この 2 つ目の節約は、キャッシュがユーザー間で共有されて初めて成立する。Claude API ではキャッシュは組織間で分離され、同一組織内ではワークスペースごとに分離されるため、同一プレフィックスはワークスペース内のリクエスト間で再利用される。claude.ai についてはドキュメントに記載がない。現状の Claude Code では起こらない。「キャッシュは事実上 1 台のマシンと 1 つのディレクトリにスコープされる」ため、別々のプロジェクトフォルダにいる 2 人は互いのキャッシュを利用できない。最後の列は、チャットのネイティブレイヤーで得られる可能性として読んでほしい。今日利用できるものではない。もっともな反論もある。スキルはすでにオンデマンドで読み込まれるため、テンプレートを Skills に移したフラットなワークスペースでも、−29% の一部は今日得られる。しかしチャットや Cowork の Skills に欠けているのはスコープと継承だ。スキルを特定の業務ラインに属させ、そのラインのプロジェクトへ流すことはできない。（Claude Code では、サブフォルダ内のスキルはそのフォルダ以下で開始されたセッションで読み込まれる。）第二に、これらは指示トークンのみの話であり、この規模ではキャッシュ状況に応じて月額 $14 から $149 の範囲だ。実際の請求額の大部分は会話履歴と出力が占める。ツリー構造を支持する強い理由は正確性であり、Team プランにおいては処理能力だ。請求書のためではない。
上記の計測は、仮定のサイズではなく実際のツリー構造上の Claude Code で型付きタスクの効果を再現したものだ。カスケードで −20%、コンパイル済みで −34% となり、シミュレーションの −29% と一致する。タスクタイプが 1 つしかない業務ラインでは、型付きタスクによる節約はゼロだ。
3.3 実際の Claude が出した同じ回答
私は Claude Code に同じ質問を 40 回投げた。4 つの条件それぞれで 10 回ずつ独立した回答を得て、1 日空けて 5 回ずつ 2 バッチに分けて実行した。質問は、路盤の現場密度試験が合格かどうか（最大乾燥密度 115.8 pcf に対して 112.3 pcf、要求値 98%）というものだ。指示は会社の 6 つのルール、または 1 行の「親切なアシスタント」プロンプトのいずれかで、言語は英語またはスペイン語とした。40 回すべてが同じ判定を下した。97.0%、不合格。
Claude Code は 2 つの出力数値を報告する。課金されるトークン数と、そのうち読者には見えない思考（thinking）に使われたトークン数だ。
4 つの知見：
• 会社のルールを使うと、画面上の回答は 1.4 倍、課金対象は 1.8〜1.9 倍長くなった。 目に見える追加分は、ルールが要求したフラグ、基準、制限事項のセクションだ。品質管理システムにおいて、これらこそ価値のある部分である。
• 会社のルール下では、課金対象の出力の 3 分の 1 以上が見えなかった。 課金対象の出力トークンの 37% が思考に使われており、シンプルなプロンプトの 16% と対照的だ。英語の場合、読者は 447 トークンを見て、711 トークン分の料金を払う。
• スペイン語は、単語数で 4% 以内の差しかない回答に対し、英語の 1.2 倍の表示トークンを消費した。 同じ方法で計測すると、会社のルールをスペイン語で書いた場合は入力トークンが 1.53 倍になった。
• 同じ判定でも課金トークンは 317 から 953 までばらついた。 最短の回答の 3 倍が最長の回答にかかっている。トークン課金では、厳密さと無駄な水増しを区別できない。合否基準なら区別できる。
これらの比率は 5 回ごとのバッチ間で変動する。会社のルールの画面上の比率は、第 1 バッチで 1.43〜1.52、第 2 バッチで 1.27〜1.31 だった。課金比率は 1.78〜1.82、続いて 1.70〜2.05。スペイン語比率は 1.29〜1.38、続いて 1.14〜1.18 だった。傾向が変わることはなかった。数値は有効数字 1 桁程度として読むのが妥当だ。
手法：2026-09-30 に Claude Code 2.1.286、2026-10-01 に 2.1.287 を使用。claude -p --output-format json、Claude Sonnet 5.5。すべてのツールを禁止し、個人の ~/.claude ファイルを除外したため、条件間で異なるのは指定した指示のみ。トークン数は thinking_tokens を含む Claude Code 自身の使用量レポートに基づく。月額コストは、課金対象の平均値に Sonnet 5.5 の出力 100 万トークンあたり $10 を適用して算出。計測スクリプト、両バッチ、プールした数値、すべての回答は筆者が保管しており、要望に応じて提供する。本記事の初版ではサブエージェントと公開トークナイザーでこれらの数値を推定していたが、それらは今回の実測値に置き換えられる。
3.4 ルールが矛盾するとき、決めるのは文言
Anthropic のドキュメントは、矛盾する指示が「任意に」解決される可能性を認めている。業務ラインのレイヤーが欠けている場合に生じる類の矛盾を 1 つテストした。組織ルールは米国慣用単位を使用すると定め、プロジェクトルールは SI 単位で密度を報告すると定めた。ツリー構造と同じように配置した。組織ルールはストレージルートの CLAUDE.md に、プロジェクトルールはプロジェクトフォルダの CLAUDE.md に置き、両方を Claude Code のカスケードで読み込ませた。次に、組織ルールを言葉だけで「強制」とマークした同じ構成を実行した。ラベルに ENFORCED というタグを入れ、「このルールは強制されます。いかなる業務ラインやプロジェクトのルールもこれを上書きできません」という 1 文を追加した。各構成を 9 月 30 日に 10 回、10 月 1 日にさらに 10 回実行した。
結果は任意ではなかった。何も宣言していない場合、Claude は毎回、より近くて具体的なルールを選んだ。20 回の回答のうち 14 回は理由を述べた（「そのルールは全社的な米国慣用単位のルールより具体的です」、あるいはそれが会社のルールを上書きするという説明）。5 回はプロジェクトルールのみを引用し、会社のルールと矛盾していることには触れなかった。言葉で強制力を宣言した場合、組織ルールが毎回勝ち、すべての回答が強制された会社のルールが優先されると述べた。第 2 バッチも単位を完全に再現し、それぞれ 10 回中 10 回だった。2 つの行の差は偶然では到底説明できない（Fisher の正確確率検定、p < 0.0001）。説明の安定性は劣った。第 1 バッチでは 10 回中 9 回がプロジェクトルールが勝った理由を述べたが、第 2 バッチでは 10 回中 5 回にとどまった。
これはモデルにとっては良いニュースだが、ワークスペースにとっては悪いニュースだ。優先順位は存在するが、それはルールの文言の中にあり、どのレイヤーを編集する人でも変更できてしまうし、誰もそれを「優先順位の決定」としてレビューしない。そして下位のルールが勝った場合、4 分の 1 の回答では、上位のルールが除外されたことが読者に伝えられていなかった。この記事の初版で行ったパイロットテスト（カスケードではなく 1 つのプロンプトに両方のルールを入れたもの）でも、順番を入れ替えただけで結果が変わった（組織ルールを先頭にすると SI が 5 回中 5 回、最後にすると 5 回中 2 回が SI、残り 3 回は両方の単位を出すかどちらを使うか質問してきた）。
組織がルール作成時に防げたはずの衝突を、モデルに仲裁させるべきではない。Claude Code には部分的な解決策が 2 つある。/doctor prompt-audit は、人が実行したときに矛盾する指示ファイルを Claude に探させる。また 10 月 1 日以降、mod でコード上の順序を強制できるようになった。組織の mod は個人の mod より先に実行され、組み込みガードが読み込まれる場所では deny ルールが個人の mod に優先する。しかしどちらも指示テキストは対象外だ。指示ファイルは依然として連結されるだけで、ドキュメントではその結果が 3 通りに説明されている。Claude は「任意に 1 つを選ぶかもしれない」、ユーザーのルールとプロジェクトのルールが衝突した場合「Claude はいずれかに従うかもしれない」、そして「指示が衝突する場合、Claude は判断を用いてそれらを調整する」。今回示した 20 回中 20 回の結果は、まさにその「判断」の実態だ。Claude Tag は 3 つのスコープに順序を宣言しているが、その結果を「強制されたガードレールではなくガイダンス」と呼んでいる。リファレンス実装のチェックは、「R-22 は units.density=SI を設定している。R-01 (org:firm) は US を強制している」というまさにこの変更を、何も Claude に届く前に拒否する。しかも enforced はルール内の文章ではなく、ルールのフィールドだ。
指示密度は事態をさらに悪化させる。IFScale ベンチマーク（2025 年）では、同時指示が 10 個のとき 100% だった Claude Sonnet 4 の精度が、500 個では 42.9% まで低下した。
3.5 コンピューティングやエネルギーの方が公平な単位だろうか？
トークンは同一モデル内でのコンピューティングの指標としては妥当だ。トークンが増えれば、ハードウェアの負荷も実際に増える。だからこそ、コンピューティングやエネルギーに基づく価格設定では言語ペナルティは解消されない。スペイン語のコストが高いのは、トークナイザーによる圧縮率が低いためであり、その余分なトークンは実際のコンピューティング消費だからだ。これを直すには、より優れたトークナイザーか、コンテンツ量で正規化した課金が必要になる。
それでも、正規化されたコンピューティング単位は 3 つの点で役立つ。異なるモデルやベンダーを比較できる。物理的な値なので、たとえばサステナビリティ報告のために数値化しやすい。そして係数を基準ハードウェアに対して固定すれば、ベンダーは自社の効率改善の恩恵をそのまま受けられるため、適切なインセンティブになる。前例もある。クラウドプロバイダーはかつて EC2 Compute Unit のような正規化単位を販売していた。
ただし現実的な課題もある。標準と監査人がいなければ、顧客は検証できない。実際のエネルギー消費はハードウェア、データセンターの効率、バッチ処理、電力網に左右される。また Anthropic はリクエストごとのエネルギー消費量を公開しておらず、見つかったのは第三者の推計値だけだった。最も重要なのは、コンピューティングはあくまでインプットであり、回答が正しかったかどうかは分からないという点だ。
私の結論は、次の 3 つの層に分けることだ。
- トークンまたは正規化コンピューティング単位で課金する。
- タスクごと・ノードごとのエネルギー消費量を開示する。
- 検証済み成果あたりのコストで管理する。
Team プランの場合、最低限必要なのは週次上限を明確な単位で公表することだ。セッションあたりの許容量は「Pro プランのセッションあたり使用許容量の 1.25 倍」とされているが、週次上限については数値が一切公表されていない。これでは予算化できない。
FinOps Foundation が言うように、「トークンは課金単位であって、価値の単位ではない」。価値を定義可能にするのが階層構造であり、そこにこそ合格基準を置けるからだ。
3.6 構築されていない、より現実的な理由
- 暗黙の優先順位。 Anthropic 自身のドキュメントも、直接矛盾する指示は挙動のばらつきを生む可能性があると認めており、3.4 節で示したように、優先順位はルールの文言次第になってしまう。レイヤーを重ねれば衝突は掛け算で増え、指示追従性は密度とともに劣化する。IFScale ベンチマーク（2025 年）では、テストされた最高性能のモデルですら、500 個のキーワード指示を同時に与えられると精度は 68% にとどまった（3.4 節で引用したベンチマーク）。
- 権限の継承。 ナレッジがツリーの下位へ継承されるなら、アクセス権も同様に継承されなければならない。つまり、各レイヤーの下で権限モデルを作り直す必要がある。
- 静的なレイヤーよりもメモリと検索を重視する方針。
- コンシューマー向けのシンプルさ優先。 コーディングツールはファイルシステムからツリー構造を無償で手に入れられるが、チャット製品は自ら発明しなければならない。
Anthropic は、なぜ Claude チャットや Cowork に階層がないのかを公には説明していない。本節の内容はすべて、リリース済みの機能からの推論である。
4. リファレンスモデル
この設計は、すでに同じ問題を解決しているシステムから着想を得ている。クラウドのリソース階層（AWS Organizations、Google Cloud Org Policy、Azure 管理グループ）、ディレクトリポリシー（Active Directory グループポリシー）、そして Claude Code 自身の CLAUDE.md カスケードだ。ノード間の関係は 5 つの単語で表される。contains（含む）、inherits（継承する）、uses（使用する）、sealed（封印された）、shared（共有された）である。
4.1 組織がすでに持つツリーをマウントする
AI ワークスペースの中で組織構造を再構築させてはならない。ファイルサーバーや文書管理システムがすでに信頼できる情報源（ソースオブトゥルース）だ。次の 1 つのパスを見ればいい。
案件番号 26GT301 には、すでにツリー情報がエンコードされている。年度、業務ライン、連番だ。ワークスペースはこの構造をコピーするのではなく、マウントすべきである。
4.2 ルールを持つノード、グループ化ノード、プロジェクト、タスク
• ルールを持つノード：組織、業務ライン、プロジェクト、タスク。それぞれが同じ 3 つの要素を持つ。コンテキスト（指示とナレッジ）、ポリシー（許可されるツール、データ、コネクタ）、アイデンティティ（紐づけられたコネクタアカウント）。
• グループ化ノード：シリーズ、年度、地域。これらはルールを持たない。ナビゲーション、保持、ライフサイクルのために存在する。分離することでルールツリーを浅く保てる。Microsoft 自身が管理グループのガイドラインで推奨するように、3〜4 レベルに収められる（「3〜4 レベルを超えないこと」）。
• プロジェクトはキー付きのコンテナである。 自動で作成される。業務ラインのキーパターンに一致するフォルダ（たとえば業務ラインのルート配下の {YY}GT{NNN}_{Name}）が現れると、プロジェクトノードが作成され、親ラインから継承し、そのフォルダだけにスコープされたコネクタアクセスを得る。保持するのは親ラインと異なる部分だけだ。メンバー、クライアント、仕様書などである。状態は「オープン」から「クローズド」、「アーカイブ」へと遷移する（図 2）。
• タスクには型がある。 型は業務ラインのカタログ（密度レポート、ボーリングログなど）から決まる。型にはテンプレートと合格基準が含まれる。出力は事務所の命名規則に従ってプロジェクトフォルダへ格納され、レビュアーが承認する。現在、タスクの型に最も近い概念は Skills だ。Enterprise ではグループと共有できるが、それは配布であって継承ではない。ブランチの下位へは何も流れない。
この再帰構造は意図的なものだ。Stafford Beer の生存可能システムモデル（Viable System Model）はこう明言している。「再帰的な組織構造において、あらゆる生存可能システムは別の生存可能システムを含み、かつ含まれている。」
4.3 1 つの主親とオーバーレイ
Christopher Alexander は 1965 年に「都市はツリーではない」と論じた。現実の構造は重なり合う。クライアント、代理店の仕様書、タスクの型は、複数の業務ラインにまたがり得る。そこで各ノードは 1 つの主親を持ち、横断的なルールセットはオーバーレイ（uses）として付加する。衝突の解決方法は常に同じだ。deny が最優先、それ以外は最も近いノードが勝つ。
4.4 2 つのチャネル、2 つの意味論
ここが設計の核心であり、多くの階層設計がつまずくポイントでもある。
• コンテキストは連結される。 指示とナレッジは、CLAUDE.md と同様にルートから下へ向かって統合される。
• ポリシーはデフォルトで deny である。 ツールやコネクタは、ルートからの経路全体に allow が存在する場合のみ許可され、上位のどこかで明示的に deny されていればそれが優先される。AWS のサービスコントロールポリシーと同じ仕組みだ。親はルールを enforced（強制）としてマークでき、子ノードはそれをブロックできない。グループポリシーと同様である。
この 2 つを混ぜるのが典型的な失敗だ。助言的なコンテキストは混ざり合ってよい。しかし強制力はそうすべきではない。
4.5 モデルが読む前にコンパイルする
現在、矛盾する指示は回答生成時にモデルが解決している。解決策は、モデルが何も見る前に実行される有効指示コンパイラだ。
- ルートからリーフまでコンテキストを統合する。
- ポリシーを適用する。deny が優先され、allow は経路全体で成立していなければならない。
- 親からの enforced ルールを尊重する。
- すべてのルールに ID と所属レイヤーを刻印する。
- 各部分がどれだけ広く共有されているかに基づいてブロックを並べ替え、レイヤーごとにトークン予算を割り当てる。
衝突がこの段階に到達することはない。ルールが書かれた時点、つまりもっと早い段階で拒否され、承認は作成者以外の人間が行うからだ（図 3、下段レーン）。
衝突はコンパイル時に解決されるため、出力は深さの厳密な順序ではなく、共有範囲の広さに応じて並べ替えられる。組織、業務ライン、タスク型のテンプレート、そしてプロジェクト固有の設定という順だ。この順序はキャッシュヒット率を最大化する（3.2 節）。Anthropic の 4 つのキャッシュブレークポイントに対応し、レイヤーごとにトークン予算を設定できる。ただし実際には、会話自体のために 1 つのブレークポイントが必要になる場合もある。
4.6 人ではなくブランチに紐づくアイデンティティ
コネクタのアイデンティティ（アカウント、テナント、スコープ）は人ではなくノードに紐づく。Claude Tag はすでに Slack チャンネルでこの方式を採用している。管理者がサービスアカウントをスコープに紐づけ、最も狭いスコープの認証情報が優先される。ここで提案するモデルは、同じことを 1 レベル下、つまり業務ラインとそのプロジェクトで求める。2 つの組織で働く人は 2 つの封印されたツリーを持ち、アカウントではなくツリーを切り替える。両方の所有者が明示的に共有しない限り、ツリー間で何かが行き来することはない。技術的なプリミティブはすでに存在する。MCP 認可仕様はオーディエンスバインドされた OAuth トークン（RFC 8707 のリソースインジケーター、RFC 9728 の保護リソースメタデータ）を使用し、サーバーは「他のいかなるトークンも受け入れたり転送したりしてはならない（MUST NOT）」と定めている（仕様バージョン 2026-07-28）。
4.7 権限はツリーに従う
プリンシパル：人、グループ、サービスアカウント、外部ゲスト（クライアントなど）、そしてエージェント自身。
エージェントは人やノードの権限を決して超えない。 Claude は呼び出したユーザーの権限と、ノードのポリシーの積集合で動作する。ルールや権限を変更することはできず、変更を提案できるだけだ。（現在、Claude は Cowork フォルダの指示を自力で更新できる。このモデルでは、それは誰かが承認する提案になる。）
評価。 権限付与は下方向にのみ流れ、上や横には流れない。あるノードでの実効権限は、その経路上のロールが付与するもののうち、経路全体のポリシーが許可する範囲内で、上位の deny を差し引いたものだ。オーバーレイは自身のコンテンツへのアクセスのみを付与する。仕様書を閲覧しても、それを使用するプロジェクトが開かれるわけではない。
ライフサイクル。
• オープン：ロールが付与通りに適用される。
• クローズド：新規タスクは作成不可だが、保留中のレビューは完了できる。
• アーカイブ：全員が読み取り専用。復元できるのはオーナーのみで、復元はログに記録される。
• 封印されたツリー：明示的な共有なしには何も行き来できない。
例外と委任。 例外は期間限定で根拠が必要であり、要求者以外の人間が承認する。自動的に期限切れになり、件数が集計される。すべてのオーバーライドは恒久的なメンテナンスの孤島になるからだ。SharePoint の継承解除制限はその教訓である。委任は、委任者が持つ以上の権限を決して付与できない。オーナーの緊急アクセス（break-glass）は存在するが、常にログに記録され、事後にレビューされる。
Team プランでは、 グループ機能がなくてもこれが機能する。権限付与はノード上に存在するため、4 つのロールしかない組織でもブランチごとの権限を実現できる。
4.8 レイヤーはどのように相互作用するか
ツリーは、変更が伝播しなければ作る意味がない。ほとんどの処理を担うのは 3 つの相互作用だ（図 5）。
• プッシュダウン。 業務ラインのリーダーがルールの新バージョンを公開する。ライン内の全プロジェクトが次回コンパイル時にそれを読み込む。承認済みの例外は期限切れまで旧バージョンを使い、すでに格納された成果物は作成時のバージョンを保持する。
• プルアップ。 メンバーが 1 つのプロジェクト内でテンプレートを改善し、提案する。提案者ではなくラインリーダーが承認し、兄弟プロジェクトがそれを継承する。現在、こうした改善は発生したプロジェクト内に留まってしまう。
• クロス。 代理店の仕様書が 1 度だけ変更される。3 つの業務ラインのプロジェクトがそれを反映して再コンパイルされるが、ライン自体は変わらない。ラインのルールとの衝突は、更新が書き込まれる時点で拒否される。
1 つのリクエストがすべてのレイヤーを一度に動かす（図 6）。ツリーはメンバーの権限とプロジェクトの状態を確認し、コンパイラがブロックを構築し、Claude はそのプロジェクトフォルダにスコープされたアイデンティティでフィールドデータを読み取り、型付きの成果物をフォルダへ格納し、作成者ではないレビュアーが承認する。すべてのステップがログに残り、コストはプロジェクトキーに請求される。
4.9 データ構造
プロビジョニングはイベント駆動だ。業務ラインの storage_root 配下に key_pattern に一致する新しいフォルダができると、プロジェクトノードが作成される。answer_log はすべての回答の出所と、ノードごとのコストを提供する。
4.10 トークンではなく成果を測る
各タスク型には合格基準、つまり完了の定義が含まれる。これが整えば、AI の作業量を測るより良い単位が測定可能になる。
検証済み成果あたりのコスト ＝（トークンコスト ＋ レビュー時間）÷ 承認済み成果物
すべての回答がノードに紐づけてログされるため、労務費や材料費と同じように、AI コストをプロジェクトキーに振り分けられる。その一部はすでに存在する。Claude Tag はチャネルごとの支出をレポートし上限を設定でき、Claude Code のテレメトリは手動で部門、コストセンター、リポジトリ別にタグ付けできる。しかしどれもプロジェクトに紐づいておらず、承認済み成果物で割ってもいない。案件番号で請求する事務所にとって、AI は間接費ではなく直接の案件原価になる。エンジニアリングの世界では、鉛筆の芯ではなく、検査済みの封印された成果物に対価を払う。AI の作業も同じように測るべきだ。
4.11 想定される反論と回答
「Skills やプラグインで既にできている。」 Skill は Claude が関連すると判断したときに読み込まれる。これは関連性に基づくものであり、保証ではない。プロビジョニングは Skill を全員に付与する。Enterprise では、Skill を含むプラグインを特定のグループに必須化できる。これが現在のチャットや Cowork における業務ラインに最も近い概念だが、3 つの点で不十分だ。Enterprise 限定であること、人ではなくプロジェクトを対象にしていないこと、そして業務ラインからそのプロジェクト群へ何も流れ落ちないことだ。ある業務ラインで常に適用すべきルールを、関連性の検出に依存させることはできない。
「Mod で既にできている。」 2026 年 10 月 1 日以降、Claude Code では部分的にそうだ。mod はシステムプロンプトを書き換え、ツール呼び出しを拒否し、パネルを描画できる。また組織の mod は個人の mod より先に実行される。したがって、本記事のコンパイラ、書き込み時チェック、有効指示ビューは、今日 mod として構築可能であり、第 6 節でもそう述べている。ただし 3 つの限界が残る。mod は Claude チャットでは動作せず、Cowork では組織のコンソール設定が適用されない。順序の所有者は組織と個人の 2 つしかなく、その間に業務ラインが存在しない。Enterprise では、あるグループに必須としたプラグインが mod をそのグループへ運べるが、それは個人自身の mod の 1 つとして実行され、優先順位は持たない。さらに mod はサンドボックス化されていないコードだ。個人の mod より先に実行するには、組織の mod を各マシンのディレクトリに配置する必要があり、管理コンソールから配信される設定では「マシン上にディレクトリを配置できない」。デバイス管理を導入していない企業でも mod を全員にプッシュできるが、それは個人の mod と並んで実行され、先行しない。ある部署だけが異なる単位で報告するというルールのために、TypeScript を書く必要はないはずだ。
「Memory がルールを学習する。」 Memory は主に Claude が 1 人のユーザーまたは 1 つのプロジェクト向けに書き込むもので、オーナーはメンバーの Memory を読み取ったり編集したりできない。監査人に必要なのは、人が書き、バージョン管理され、承認され、各回答まで追跡可能なルールだ。Anthropic はこれをすでに 3 回構築している。権限については「View effective role」とその「Granted by」ラベル、Skills とプラグインについてはバージョン履歴と「自分自身を承認できない」レビュー手順、Claude Tag のアクセスについては「Inherited from」ラベルである。プロジェクト内の指示には、この 3 つのいずれもない。
「Claude Tag で既にできている。」 Slack チャンネルについては概ねその通りで、第 1 節でも述べた。しかし 3 つ不足している。チャンネルはプロジェクトではない。フォルダもキーもライフサイクルもなく、「チャンネルを Project に向けることはできない」。ツリーは 3 レベルに固定されているため、業務ラインと数百の案件を持つ企業は、2 レベルをチャンネル名に押し込めて平坦化しなければならない。また、指示を書く際に衝突をチェックする仕組みはドキュメントに記載されておらず、スコープは連結され、調整はモデル任せになる。むしろ Claude Tag は、本記事の設計を裏付ける最強の証拠だ。チーム向けに構築したとき、同じ会社が継承、スコープバインド認証情報、出所ラベルを選んだのだから。
「階層は複雑さを増す。」 深さが無制限の場合だけだ。Microsoft 自身の管理グループのガイドラインは「3〜4 レベルを超えないこと」である。このモデルはルールを持つレベルを 4 つに固定し、シリーズや年度といったグループ化フォルダにはルールを一切持たせない。
「継承はセキュリティリスクだ。」 アクセス権を不用意に継承させれば、確かにそうだ。クラウドの答えがそのまま当てはまる。allow はすべてのレベルに存在しなければならず、どこかの deny が優先され、Claude はユーザーとノードの積集合として動作し、Claude 自身によるルール編集は提案になる。
「レイヤーが増えるとトークンコストも増える。」 3.2 節では、Claude Code で逆の結果が測定された。フラットなコピーと比較して、カスケードでは指示トークンが 20% 減少し、コンパイル済みでは 34% 減少した。ファイルが増えるごとにわずかなオーバーヘッドは生じるため、カスケードよりコンパイルが優れる。型付きタスクは使わないテンプレートを省き、コンパイル済みのプレフィックスはプロジェクト間でバイト単位で一致するため、プロンプトキャッシュで再利用できる。Claude API ではキャッシュがワークスペースごとに分離されるので、組織ごとにワークスペースを用意すればツリーのルートに対応する。現在の Claude Code ではこれができない。キャッシュは 1 台のマシンと 1 つのディレクトリにスコープされている。
「チームが各自のプロジェクトを管理すればいい。」 それが今日の回避策だが、第 5 節のプロトタイプはその結果を測定した。小規模なデモで、貼り付けられた 6 つのコピーのうち 2 つがすでに古くなっていた。
5. すでに動く：リファレンス実装
このモデルが机上の空論ではなく構築可能であることを示すため、私は Worktree という小さなデスクトップアプリを作った（Node と Electron 製、Windows と Linux で 24 テストが通過）。Claude Desktop と似たレイアウトだ。上記の動画は実際の動作画面で、Claude が処理している部分だけを短くカットしている。これは mod ではなく、外部から Claude Code を操作する独立したアプリだ。独自のモデルは呼び出さない。すべてのチャットは、コンピュータにインストール済みの Claude Code（claude -p）を、そのログイン状態（Claude サブスクリプションまたは API キー）のまま実行する。3 つの業務ラインと 6 つのプロジェクトを持つ架空の会社でテストした。メッセージを送信すると、次の処理が行われる。
• 許可（Permit）。 操作する人はプロジェクトまたはその上位で権限を付与されている必要があり、プロジェクトはオープン状態でなければならない。業務ラインに権限のない管理者は、Claude が起動する前に停止された。
• チェック（Check）。 書き込み時チェックが最初に走る。3.4 節の SI ルールは、強制力のある会社ルールとの衝突として拒否されるため、CLAUDE.md には決して到達しない。
• マウント（Mount）。 ツリーは実際のプロジェクトフォルダに、1 レベルにつき 1 つの CLAUDE.md として書き出される（ストレージルートに組織、次に業務ライン、次にプロジェクト）。そして Claude Code 自身のカスケードがそれらを読み込む。コンパイルモードでは、代わりにプロジェクトごとに 1 ファイルを書き出す。アプリのマーカーがないファイルは決して上書きされない。
• 実行（Run）。 タスクテンプレートは --append-system-prompt-file に入る。Claude が何をできるかは CLAUDE.md ではなく Claude Code が強制する。--allowedTools は個人のロールと各レベルのポリシーの積集合であり、書き込みはプロジェクトフォルダに限定され、--permission-mode dontAsk がそれ以外をすべて拒否する。実際のテストでは、業務ラインのポリシーが Web を許可していないため Web 検索が拒否され、プロジェクトフォルダ外への書き込みも拒否されてログに記録された。
• ログとレビュー（Log and review）。 すべての回答は、実行者、ノード、全ルールタグ、Claude が引用したルール、そして Claude Code が報告した入力・キャッシュ・出力トークンとともにログされる。回答を作成していないレビュアーが承認または差し戻しを行う。デモでの実際の密度レポート実行には約 30 秒かかった。3 回の実行で、Claude Code はリスト価格ベースで回答あたり 0.08〜0.22 ドルを報告した。Claude は適用したルールを引用し、合格基準の境界に近い結果にフラグを立て、エンジニアの入力欄は空白のまま残した。
• ドリフト（Drift）。 マウントされたすべての CLAUDE.md がツリーと比較され、手動編集にフラグが立てられる。以前のコマンドライン版プロトタイプで、フラットなプロジェクトに貼り付けられたコピーを同じ方法で比較したところ、6 つのうち 2 つが古い状態だった。1 つは R-07 v3 のままで、もう 1 つはルールが手動で削除されていた。
構築を通じて得た知見は 3 つあり、いずれも Claude Code 上で指示を階層化しようとする人に関係する。
- 個人の指示が組織の実行に漏れ出す。 デフォルトでは、すべての実行で私個人の ~/.claude/CLAUDE.md、ルール、エージェント、MCP サーバーも読み込まれていた。アプリは現在、claudeMdExcludes 設定と --strict-mcp-config でこれらを除外している。私の環境では、これにより実行時のコンテキストが 29.6k トークンから 21.4k トークンに減った。明白な代替手段である --setting-sources project,local は、Windows 版 Claude Code 2.1.284 では必要なことと正反対の動きをした。個人ファイルを残したまま、組織や業務ラインを担う親フォルダの CLAUDE.md ファイルを落としてしまったのだ。
- 個人の mod も漏れ出す。 アプリ完成の翌日に mod がリリースされたのでテストした。すべてのプロンプトに 1 行を追加する単一フックの mod を自分のユーザースコープにインストールしたところ、アプリの実行にも到達した。組織の 3 つのルールが読み込まれ、私の個人的な 1 行も読み込まれ、回答はそれに従った。実行設定に disableAllHooks を追加すると mod は排除され、3 レベルの CLAUDE.md はそのまま残った。アプリは現在これを行っている。--safe-mode は代用にならない。mod だけでなく CLAUDE.md カスケード全体を消してしまったからだ。ドキュメントによれば、個人設定での disableAllHooks は、組織が管理するものを動作させたままにする。
- CLAUDE.md はコンテキストであり、強制は設定である。 Anthropic のドキュメントもそう述べている。「設定ルールは、Claude がどう判断するかにかかわらずクライアントによって強制されます。CLAUDE.md の指示は Claude の振る舞いを形作りますが、ハードな強制レイヤーではありません。」アプリはこれに依存している。ルールが保証すべきことはすべてツール権限にマッピングされ、CLAUDE.md にあるものはタグ付きのガイダンスとなる。
これは現在の Claude Code で動作し、コンパイル済みのテキストはどのプランでもチャットや Cowork プロジェクトの指示に貼り付けられる。依存関係に 1 つ期限がある。アプリは claude -p が CLAUDE.md ファイルを読み込むことに依存しているが、Anthropic のドキュメントは、これらをスキップする --bare が「将来のリリースで -p のデフォルトになる」と述べている。それが実装されたら、アプリは別の方法でツリーを渡す必要がある。コンパイルモードと --append-system-prompt-file はすでに対応可能だ。これはネイティブ版に向けた動作する仕様書であり、セキュリティ境界ではない。「acting as」はデモ用のスイッチであって、サインインではない。
6. 既存のリリースからの道筋
今すぐ、Claude Code で。 10 月 1 日以降、このツリーは mod として出荷できる。ノードのルールをシステムプロンプトの一部にコンパイルし、ノードのポリシーが拒否するツール呼び出しをブロックし、有効な指示をペインに表示するのだ。組織は、個人がインストールするものより優先してその mod を実行できる。私はこれを構築していない。これはリファレンス実装のロードマップにおける最初の項目だ。これにより Claude Code がカバーされ、おそらく同じエンジンで動作するユーザーのマシン上の Cowork セッションも対象となる。ただしチャットは対象外だ。
30 日版、チャットおよび Cowork 向け。 Anthropic には必要な要素が揃っている。Slack チャンネルが Claude Tag のワークスペースから設定を継承するように、プロジェクトが親プロジェクトを指定し、その指示を継承できるようにする。2 つを順番にコンパイルし、すべてのルールにタグを付け、既存の「View effective role」の横に「View effective instructions（有効な指示を表示）」パネルを追加する。これだけで、あらゆる業務ラインがルールを一箇所にまとめる場所を得られる。
その後は、各ステップが単独でも有用であり、まずは Team プランに役立つものから始める。
- 業務ラインノードとキーパターンによるプロビジョニング。すでにコード上で機能している CLAUDE.md のセマンティクスを再利用する。Claude Code 自体では、マッチングステップが組織の mod と個人の mod の間にあるグループ向けの階層となり、グループごとの管理設定となる。
- タスクタイプ。受け入れ基準を備えた、業務ラインにスコープされたスキルとしてのタスクタイプ。
- 書き込み時の競合チェック。矛盾はモデルによって仲裁されるのではなく、ツリーによって拒否されるようにする。
- ノードへの権限付与。グループなしの Team でも機能し、Enterprise のカスタムロールを拡張する。
- プロジェクトに対するブランチバウンドのコネクタ ID。Claude Tag がすでにサービスアカウントを Slack チャンネルにバインドしているのと同じ仕組み。
- ノードごとのアカウンティング。プロジェクトをキーとし、Claude Tag がすでにチャンネルごとにレポートしているようなもの。指定された単位での週次上限の公開、およびタスクごとのエネルギー開示。
7. 制限事項
• カバレッジ。 2026 年 10 月 1 日時点で、code.claude.com/docs および claude.com/docs の全ページインデックスをタイトルベースで選別し（466 ページ）、ここで引用したヘルプセンター記事を含め約 150 ページを読み込んだ。この記事の以前のバージョンでは Claude Tag が完全に漏れていた。今回のバージョンでも何かを見落としている可能性がある。政府機関向け Claude やサードパーティプロバイダー上の Claude Desktop については言及しているが、分析はしていない。
• プラットフォームの機能は毎月変更されており、この記事を書いている間にも 1 つ変更があった。ここでの製品に関する記述はすべて 2026 年 9 月 29 日〜 10 月 1 日時点のものであり、依拠する前に再確認すべきである。Mods はまだ 1 日前に登場したばかりだ。私はドキュメントを読み、1 つのケースをテストしたが、本番環境で使用したわけではない。
• セクション 3.1〜3.4 の測定値は、Claude Code 自身の使用状況レポートから得たもので、2 つのバッチに分かれている。2026-09-30 の Claude Code 2.1.286 と、2026-10-01 の 2.1.287 で、いずれも Claude Sonnet 5.5 上での計測だ。スクリプト、両方のバッチ、すべての回答は著者が保管しており、要望に応じて提供可能である。これらには claude.ai や Cowork にはない Claude Code 自身のプロンプト（約 30,200 トークン）が含まれており、対象は 1 つのモデル、1 つのデモプロジェクト、1 つの質問に限られている。サンプルサイズは小さい。回答長の条件あたり 10 件、競合テストの条件あたり 20 件だ。回答長の比率は 2 つのバッチ間で変動した（セクション 3.3）。1 日違いの 2 バッチは Claude Code のバージョンも異なるため、それと偶然の変動を切り分けることはできない。
• セクション 5 の実行時間、コスト、コンテキストサイズは、3 回のデモ実行と 1 回の手動分離テストというアプリ自身の回答ログから得たもので、著者自身の記録である。
• 競合テストの回答は、著者が非ブラインドで、すべての回答を読んでコーディングした（報告された単位、どのルールが勝ったかとその理由を回答が述べたか、質問をしたか）。40 件すべてが再コーディング用に要望に応じて提供可能である。テストでは「enforced」の 1 つの表現を使用した。他の表現、モデル、ルールの組み合わせでは異なる挙動をする可能性がある。
• セクション 5 の mod テストは、1 つの Linux マシン上で、1 つのフックを持つ 1 つの mod を、サブスクリプションでサインインし管理設定なしの Claude Haiku で実行したものだ。組織のポリシー mod、Team または Enterprise ログインの組み込みガード、デスクトップアプリはテストしていない。
• セクション 3.2 のコストモデルは、例示的な企業をシミュレーションしたものであり、実際の請求額を測定したものではない。対象は指示トークンのみで、実際の請求では通常、会話履歴、出力、思考が大部分を占める。トークンサイズには Anthropic の公開レガシートークナイザー × 1.30 を使用している。実測では、Claude Code はこの推定値より 21〜26% 多く読み込んでいたため、ドル換算の数値は低めに出ている。パーセンテージは比率であり、妥当性がある。セッションパターンとキャッシュ共有は仮定に基づく。
• Enterprise でのチャット利用に API キャッシュ価格が適用されるか、また claude.ai 上でユーザー間でキャッシュが共有されるかは文書化されていない。Cowork はセッションを Claude Code 上で実行し、プラグインフックもそこで読み込まれるが、mods のページには Cowork が記載されておらず、私もテストしていない。10 月 1 日時点で、デスクトップアプリはまだ mods が有効化される 1 バージョン前の Claude Code 2.1.286 をバンドルしていた。デバイスの管理ポリシーは、組織が完全な VM サンドボックスで実行しない限り、ユーザーのマシン上の Cowork セッションに到達する。ユーザー自身の ~/.claude ファイルが Cowork に到達するかどうかについて 2 つのページで記述が矛盾しているため、この記事ではどちらとも断定しない。また、親フォルダ内の CLAUDE.md ファイルが Cowork セッションで読み込まれるかもテストしていない。もし読み込まれるなら、リファレンス実装のマウントされたツリーは、今日すでにユーザーのマシン上の Cowork に到達することになる。Pro および Max では、新しい Cowork タスクがクラウドに移行する 2026 年 10 月 6 日に、このウィンドウは狭まる。
• 動機は推測である。Anthropic は、なぜ Claude チャットと Cowork がフラットな構造なのかを公に説明していない。
• コードと生データは本記事と共に公開されていない。 読者は記事だけでは測定を再現できない。動画はアプリが動作する様子を示すものであり、どのように構築されているかを示すものではない。
• リファレンス実装は架空の企業上で動作する。claude.ai や Cowork とは統合されておらず、「acting as（〜として振る舞う）」はデモ用のスイッチであってサインインではない。権限はアプリではなく、Claude Code のツールリストによって強制される。分離（Isolation）は実行時に個人自身のフックと mod をオフにするが、Claude Code に組み込まれた mod は実行され続け、パーソナルエージェントの名前がコンテキストに表示される可能性もある。このアプリは claude -p が CLAUDE.md を読み込むことに依存しているが、Anthropic はこれがデフォルトでなくなると述べている。個人ファイルの漏洩と --setting-sources の結果は Windows でテストした。測定と mod テストは Linux で実行した。
出典
• Anthropic, Set organization instructions
• Anthropic, Roles and permissions
• Anthropic, What is the Team plan? · Plans and pricing
• Anthropic, Manage custom roles on Enterprise plans
• Anthropic, Organize your tasks with projects in Claude Cowork
• Anthropic, Use Google Workspace connectors
• Anthropic, Manage groups and group spend limits on Enterprise plans
• Anthropic, What are projects?（新バージョンのプロジェクト、ベータ版）
• Anthropic, Get started with Claude Cowork（グローバルおよびフォルダの指示）
• Anthropic, How Claude remembers your project (CLAUDE.md) · All settings（claudeMdExcludes, disableAllHooks）
• Anthropic, Customize Claude Code with mods（2026 年 10 月 1 日） · Mods overview · Manage mods for your organization · React to events with a mod · Mods reference
• Anthropic, Claude Tag: What is Claude Tag? · Configure per-channel access · Customize Claude Tag · How agent identity works · Audit · Set a spend limit
• Anthropic, Projects in Claude Code（新プロジェクトベータ版） · Projects in Cowork · How Claude Code uses prompt caching · Run Claude Code programmatically（--bare） · Extend Claude Code · Manage project visibility and sharing · Use connectors · Authorize MCP connectors for your entire organization · Provision and manage skills
• Anthropic, Configure server-managed settings（グループごとの設定なし） · Manage plugins for your organization（Enterprise におけるグループ別のプラグイン利用可否） · Plugin feature support across platforms（フックはチャットでは無視され、Cowork では読み込まれる） · Deploy managed settings（Cowork はセッションを Claude Code 上で実行する）
• Anthropic, Pricing（Sonnet 5.5 の料金、トークナイザーに関する注記） · Prompt caching（API 上では組織ごと・ワークスペースごとにキャッシュが分離される）
• Anthropic, @anthropic-ai/tokenizer（カウントに使用した公開トークナイザー）
• Microsoft, Management groups · Landing-zone management group design
• AWS, SCP evaluation · Google Cloud, Hierarchy evaluation
• Microsoft, Group Policy processing · SharePoint fine-grained permissions
• FinOps Foundation, Token economics
• Jaroslawicz et al., How Many Instructions Can LLMs Follow at Once? (IFScale)
• Firefly, 2026 State of IaC research
• MCP, Authorization specification, version 2026-07-28
• GitHub, anthropics/claude-code issues #68262, #14467, #30554, #27567, #30250, #27302, #47741
• Beer, S. (1979), The Heart of Enterprise; Alexander, C. (1965), “A City is Not a Tree,” Architectural Forum; Simon, H. (1962), “The Architecture of Complexity,” Proc. Am. Phil. Soc.106(6)
• リファレンス実装およびデータ：Worktree アプリ、そのテスト、測定スクリプト、両方の結果バッチ、すべての回答は著者が保管しており、要望に応じて提供する。
