Claude Code at scale 第1弾を構造解説する: ハーネスとロールアウトの実務パターン¶
対象 / ポイント
対象: エンタープライズで Claude Code を導入・運用するエンジニア、開発者生産性チーム、AI コーディングツール展開を担うマネージャ。
ポイント:
- Anthropic の第1弾は、Claude Code を「モデル」ではなく「ハーネス込みの運用システム」として扱っている
- 5つの拡張点は、常時ロードとオンデマンドの違いを意識しないと文脈窓を浪費する
- 普及の決定要因は機能表ではなく、初体験を生産的にする組織側の準備である
Anthropic は 2026年5月14日、Claude Code at scale シリーズの第1弾を公開した1。対象は、数百万行のモノレポ、数十年規模のレガシー、数十リポジトリのマイクロサービスといった大規模環境である。
この記事の問いは明確だ。Claude Code を大規模に入れるとき、最初にどこを整えるべきか。
原文は単なる Tips 集ではない。探索方式、拡張点、ロードタイミング、運用保守、組織ロールアウトを一つの導入パターンとしてつないでいる。ここでは、その構造を5つの図に分けて読む。
1. 探索方式: インデックスを持たないことの強みと前提¶
Claude Code の大規模対応は、中央インデックスを前提にしない点から始まる。 原文は、Claude Code がファイルシステムを辿り、grep で候補を絞り、参照を追って文脈を集めると説明している1。 これはエンジニアが既存コードを読む動きに近い。
対比されるのは、コードベース全体を埋め込み、検索時に関連チャンクを返す RAG 型のコーディングツールだ。 原文の論点は、RAG が悪いという話ではない。 アクティブな開発組織では、埋め込みパイプラインが最新状態に追従できず、 削除済みモジュールや改名済み関数を返す失敗モードが起きるという指摘である。
ただし、agentic search にも前提がある。 出発点の文脈が貧弱だと、探索だけで文脈窓を使い切る。 つまり、インデックスを持たない方式は「何も整備しなくてよい」ではない。 コードベースを Claude が読み始めやすい形に整えるほど効くという設計である。
2. ハーネス: モデル性能と同じくらい結果を左右する層¶
原文の中核は、Claude Code の性能をモデル単体ではなくハーネス込みで捉える点にある。 Anthropic は、ハーネスを5つの拡張点で説明している。 CLAUDE.md、Hooks、Skills、Plugins、MCP servers である1。
それぞれの役割は分かれている。 CLAUDE.md はセッション開始時に読まれるプロジェクト文脈であり、基礎になる2。 Hooks はイベントに応じてスクリプトを走らせ、毎回必要な処理を決定的に実行する3。 Skills はタスクに応じて専門知識をオンデマンドで読み込む4。
Plugins は、Skills、Hooks、MCP 設定を配布可能な単位にする5。 MCP servers は、社内ツール、データソース、API へ Claude Code を接続する層である6。 加えて、LSP integrations はシンボル単位の探索を支える。 Subagents は探索や調査を別の文脈窓に分離する7。
誤用も見えやすい。 CLAUDE.md に専門手順を詰め込むと、常時ロードされる文脈が太る。 本来 Hooks で自動化すべき処理をプロンプトに書くと、毎回の遵守が確率的になる。 基礎がないまま MCP から始めると、接続先は増えても作業品質は安定しない。
3. ロードタイミング: 文脈窓は設計対象である¶
文脈窓を守るには、何を「常時ロード」に置き、何を「オンデマンド」に逃がすかを分ける必要がある。 CLAUDE.md は毎セッション読まれるため、全タスクに効く情報だけに絞る。 原文も、ルートは大局と重要な落とし穴に限り、ローカル規約はサブディレクトリ側に寄せることを推奨している1。
一方、Skills は必要なときだけ本文が読まれる。セキュリティレビュー、ドキュメント更新、特定サービスのデプロイ手順のように、使う場面が限られる知識は Skills 側に置くほうが文脈効率がよい。
Hooks はロードというよりイベント駆動で効く。 Lint、format、Stop 時の学習メモ生成など、 「思い出して実行する」ではなく「必ず走る」にしたい処理に向く。 Subagents も同じく、調査ログを親セッションに流し込まず、結果だけ返すための隔離手段として機能する。
この整理を一言で置くなら、常時ロードは広く軽く、オンデマンドは深く重くである。大規模コードベースで Claude Code を運用するほど、この分離が効いてくる。
4. 3つの構成パターン: 技術、運用、組織を分けて見る¶
原文は、成功導入のパターンを技術構成だけで閉じていない。 3つの層に分けると読みやすい。
| 層 | 実務でやること | 失敗しやすい点 |
|---|---|---|
| 技術構成 | CLAUDE.md を薄く階層化し、起動位置と検証コマンドを局所化する | ルートに全知識を詰め、毎回フルスイートを走らせる |
| 運用保守 | モデル進化に合わせて、3〜6か月ごとに構成を見直す | 旧モデル向けの制約や Hook が負債化する |
| 組織設計 | DRI または Agent Manager を置き、Skills や Plugins の所有者を決める | 良い設定が個人知に閉じ、普及が頭打ちになる |
ここで重要なのは、Claude Code の導入が「ツールを配る」だけでは終わらない点だ。 原文は、モデルが進化すると過去の制約が逆に性能を縛る場合があると指摘している1。 たとえば、古いモデルを守るための「1ファイルずつリファクタせよ」という規則は、 新しいモデルのクロスファイル編集能力を邪魔する可能性がある。
導入後の見直し頻度まで含めて設計する。そこまでやって、ハーネスは一度作って終わりの設定ファイルではなく、運用資産になる。
5. ロールアウト: 初体験を生産的にする¶
普及の最初の分岐点は、開発者の初体験である。 最初に触ったとき、Claude Code が既存ワークフローに自然に入り、 テストや権限やドキュメント参照が整っていれば、導入は広がりやすい。 逆に、初回から迷子になったり、不要な承認や失敗ログだらけになったりすれば、 ボトムアップの熱量は落ちる。
原文の示す進め方は、4段階に分けられる。 最初に Plugins、MCP、標準 CLAUDE.md 階層などのインフラを整える。 次に、承認済み Skills、必須レビュー、限定アクセスを定義する。 信頼が積み上がったらアクセス範囲や Skill 数を増やし、最後に全社運用として定期レビューへ移す。
規制業界では、Engineering、InfoSec、Governance を初期から巻き込むことも推奨されている1。 後から統制を足すのではない。 最初から、どの Skills を承認するか、AI 生成コードをどうレビューするか、 誰が marketplace や設定を所有するかを決めておく。
エンタープライズ視点での含意¶
日本の大企業文脈では、技術より先に運用責任の置き場所が問題になる。 CLAUDE.md の階層運用は、モノレポや複数サービス構成と相性がよい。 一方で、リポジトリルートに全権限と全規約を集める組織では、 サブディレクトリ起動や局所テストの設計と衝突しやすい。
Agent Manager 相当の役割も、そのまま置けるとは限らない。 DevEx 部門があれば自然な受け皿になる。 ない場合は SRE、情シス、アーキテクト組織のいずれかが DRI を担う必要がある。 肩書きより、設定・権限・配布物・レビュー基準を更新できる権限が重要だ。
最後に、3〜6か月の構成レビューを運用サイクルに入れられるかが問われる。AI コーディング環境は、年次計画だけで管理するには変化が速い。モデル更新、Claude Code の機能追加、社内規制の変更を、ハーネス側に反映する習慣が必要になる。
まとめ¶
Claude Code at scale 第1弾は、Claude Code を「賢いモデル」ではなく、探索、文脈、検証、自動化、配布、統制を組み合わせる運用システムとして扱っている。
実務での優先順位は、MCP を増やすことではない。 まず CLAUDE.md を薄く階層化し、Hooks と Skills の役割を分ける。 良い構成を Plugins として配れる状態にする。 そのうえで、DRI を置き、定期的に古い制約を捨てる。
新しい示唆はここにある。大規模導入で競争力になるのは、どの AI コーディングツールを選ぶかだけではない。モデルが進化しても、現場の学習をハーネスに戻し続けられる組織能力である。