Anthropicが公開した、大規模なコードベースでClaude CodeなどのAIコーディングエージェントを効果的に機能させるための実践的な戦略を解説する動画。モデルの性能そのものよりも、エージェントを取り巻くコンテキストやツールのエコシステムである「AIレイヤー（ハーネス）」の構築がいかに重要であるかを説明し、グローバルルールの階層化、自動更新フック、特定のパスに限定したスキル、LSPやMCPサーバーを活用した高度なコード探索、そして探索と編集を分離するサブエージェントの運用方法まで、具体的なデモとプラグインの紹介を交えて詳しく紹介している。
大規模コードベースにおけるAIコーディングの課題
最近はClaudeやAIコーディングに関するチュートリアルが巷にあふれています。しかし、大規模なコードベースでこれらのツールをどのように活用すべきかという点については、まだ十分に語られていません。今回はまさにそのテーマについて皆さんと掘り下げていきたいと思います。
皆さんもおそらく、すでに1つや2つ、あるいは3つ以上の複雑なコードベースをお持ちでしょう。独自のアプリやプラットフォームの開発を進めているかもしれません。数万行、あるいは数十万行にも及ぶ巨大なコードベースを前にすると、コーディングエージェントに中身を正しく把握させ、効果的に機能させるのは至難の業です。今はまだそこまで複雑なコードベースが手元になくても、いずれその段階に到達します。最初はシンプルなアイデアとシンプルなコードベースから始まりますが、コードが進化していくにつれて、それまで通用していたエージェントの戦略がまったく通用しなくなってしまうのです。
だからこそ、今回の内容はとてもエキサイティングです。Anthropicは数日前、大規模コードベースでClaude Codeを活用する方法についての記事を公開しました。ここで示されているアイデアは、皆さんがどのようなコーディングエージェントを使っていても共通して適用できるものです。このブログ記事には非常に価値のある情報が詰まっているので、すべて詳しく見ていきましょう。
ただ、ブログ記事の内容はかなり抽象的な概念にとどまっています。そこで、彼らの戦略をすべて盛り込んだデモ用のコードベースをこの動画のために用意しました。記事の解説だけでなく、すべての戦略が実際にどのように機能するのか、具体的な例をお見せします。さらに、わずか2つのコマンドを実行するだけで、今回紹介する戦略の多くを皆さんが普段触っているコードベースに即座に導入できるClaudeプラグインも用意しました。そちらの紹介にも進みますが、まずは全体像から始めて、各戦略を詳しく確認し、実際の動きを見ていきましょう。
Anthropicの発表によると、Claude Codeはすでにエンタープライズレベルの非常に素晴らしい現場で導入されています。数百万行に及ぶモデルのリポジトリや、数十年前のレガシーシステム、さらには数十個のリポジトリにまたがる分散アーキテクチャなどで活用されているそうです。要するに、自分のコードベースが複雑すぎてClaude Codeには対応できないと思っているなら、それは間違いだということです。
では、AIのレイヤーが本格的に機能する前に、Claude Codeがどのようにコードベースを探索しているのかを見てみましょう。このツールは標準の状態で、エージェント検索と呼ばれる仕組みを使用しています。つまり、従来のRAG（検索拡張生成）やセマンティック検索を行っているわけではありません。Claude Codeはコードベースのインデックスを作成しないのです。その代わりに、人間のエンジニアがgrepなどのコマンドラインツールを使ってフォルダ構造を確認するように、利用可能なコマンドラインツールを駆使してコードベースを探索します。大規模なコードベースのどこに注目すべきか、どこを編集すべきかを自ら特定していくのです。
インデックスを常に同期させる必要がないため、これは非常に強力なアプローチです。しかし、トレードオフもあります。Claudeがどこを探すべきかを知るためには、最初に十分なコンテキストが与えられている必要があるのです。ここから、今回ご紹介する多くの戦略へとつながっていきます。ユーザーの要求に基づいて、Claudeが複雑なコードベースを効果的に探索し、実際に注目すべき場所を把握できるよう、事前にどのようにコンテキストを整理しておくか、という点が重要になります。
そこで、このブログ記事の核心であり、すべての戦略の土台となる重要なポイントに突き当たります。それは、モデルそのものと同じくらい、それを取り囲むハーネス（仕組み）が重要であるということです。多くの人はモデルのベンチマークに過度に執着し、Claude Codeやその他のツールの真のパワーはベースとなる大規模言語モデルの性能だけで決まると思いがちです。もちろんそれも重要ですが、正直なところ、それ以上に重要なのはモデルの周囲に構築されたエコシステム、すなわちハーネスです。私はこれをAIレイヤーと呼んでいますが、その方が実態を表していると思います。記事の中でも数段落にわたって説明されていますが、もっと分かりやすくするために図を用意しました。
AIレイヤーとは、コーディングエージェントがコードベースで作業するために与えられる、コンテキストとツールのセットのことです。従来、コードベースは主にコードとテストという2つの要素で構成されていました。しかしこれからは、AIレイヤーの登場によって、すべてのコードベースに3つ目のコンテキスト要素が導入されることになります。ここには、グローバルルール、スキル、MCPサーバー、サブエージェントなどが含まれます。Claude Codeの個々の機能のうち、ツールやコンテキストを提供するものは、すべてこのAIレイヤーの一部です。ここには7つの要素があります。LSPやフックなど、あまり馴染みのないものもあるかもしれませんが、すべて解説していきます。これら7つの要素は、ブログ記事で紹介されている各戦略にそのまま対応しており、それぞれに具体的な例を用意しています。それでは中身に入っていきましょう。
グローバルルールの階層化とコンテキストの最適化
Anthropicが最初に紹介している戦略は、大規模なコードベースにおいてClaude Codeの探索をできる限りスムーズにするためのものです。その多くは、AIレイヤーの中で最も重要と言っても過言ではない最初の要素、すなわちグローバルルールを中心に構成されています。
画面をご覧ください。これは、Claude Codeのセッション中にAIレイヤーの各要素がどれくらいの頻度で使用されるかを視覚的に表したものです。フックやスキル、ナビゲーション用のLSPなどは、セッションを通じて散発的に使われているのが分かります。これらについても後ほど詳しく説明します。しかし、土台となるグローバルルールは、セッションの最初から最後まで常にClaude Codeの挙動を規定し続けています。そのため、ここでのコンテキストの整理には、しっかりと時間をかけて戦略を練る必要があります。
彼らの最初のヒントは、グローバルルールを軽量に保ち、階層化することです。残念ながら、数千行にも及ぶ巨大なグローバルルールファイルを作成してしまう人をよく見かけますが、これは良いアイデアではありません。あまりに膨大なルールは、かえって開発エージェントのパフォーマンスを低下させるという研究結果も出ています。詳細かつ包括的に書いた方が役に立つと思うかもしれませんが、LLMに過剰なコンテキストを与えて圧倒してしまうだけです。本当に必要なのは核心となる情報だけです。このコードベースは何のためのものなのか、技術スタックやアーキテクチャの概要はどのようなものか、といった情報です。これはこのリポジトリにある一例ですが、他には一般的な規約や注意点、テストの実行コマンド、開発サーバーの立ち上げ方法などがあれば十分です。このようにルールを軽量に保ちます。
そして、Anthropicが言う階層化とは、サブディレクトリごとに claude.md ファイルを配置できる仕組みを指しています。私はリポジトリのルートにメインの claude.md を置いています。これにより、このようにClaudeのセッションを開始すると、常にこれらのルートルールが読み込まれます。しかし、そこからディレクトリを移動し、特定のサブディレクトリ内のファイルを編集し始めると、そのディレクトリにある claude.md も自動的に追加で読み込まれるのです。例えば、APIサービスのディレクトリで作業を始めると、すでに読み込まれている共通ルールに加えて、その別個の claude.md に書かれたAPIサービス固有のルールが読み込まれます。つまり、コードベース内で実際に作業している場所に応じて、適用する規約を段階的に積み上げていくことができるわけです。これはClaude Codeのスキルで採用されている、段階的開示という考え方に似ています。
巨大なコードベースを扱っている場合、無数の規約が存在することになりますが、そのほとんどはコードベースの特定の領域にしか関係ありません。したがって、作業している場所に応じて必要な規約だけを読み込むのが最適です。GitHubのイシューやJiraのチケットで作業する場合、通常はコードベースの特定の場所にスコープが絞られているはずだからです。
さらに、コードベース内のどこで作業すべきかがはっきりと分かっている場合は、そのサブディレクトリ内で直接Claude Codeを初期化するという方法もあります。JiraのチケットやGitHubのイシューから、今回はAPIサービスの中だけで作業することが分かっているなら、VS Codeでそのパスを右クリックしてコピーし、そのディレクトリに移動してからClaudeを開きます。この方法の強みは、そのディレクトリがClaude Codeのカレントワーキングディレクトリになる点です。指示をしない限り、エージェントは基本的にそのディレクトリ内のファイル編集だけに集中します。その際、該当するディレクトリの claude.md が読み込まれ、さらに自動的にディレクトリツリーを遡ってルートの claude.md も読み込まれます。ルートのコンテキストを失うことなく、Claude Codeの意識をコードベースの特定の領域に完全に集中させることができるのです。つまり、エンジニア自身が最初のナビゲーションを行ってあげるわけです。
残りの戦略は、Claude自身に効果的なナビゲーションをさせるための方法ですが、エンジニアであれば通常はどこから手を付けるべきか見当がつくはずです。もしどこから始めればいいか分からない場合は、ディレクトリ構造だけでは全容が掴めないときのために、コードベースのマップを構築するという戦略が有効になります。私は通常、これをグローバルルールに記述します。このサンプルには含まれていませんが、多くの場合、ディレクトリ構造や各サブディレクトリの簡単な説明をまとめたセクションを用意します。そうすることで、Claudeがコードベースの探索を手助けしてくれ、取り組むべきタスクに基づいて、大規模なコードベースのどの領域に集中すべきかを割り出すことができます。基本的には、Claudeに探索を手伝ってもらうか、あるいは自分で即座に判断してそのディレクトリでClaude Codeを起動するかのどちらかになります。
ここで、今日の動画のスポンサーであるJetBrains Academyをご紹介させてください。私はこれまで多くのAI関連の講座を受けてきましたが、その多くには共通する問題がありました。一言で言えば、実際の業務が始まる手前の段階で講座が終わってしまうのです。教材を読み、非常に基本的な演習をこなすものの、実際に何かをデプロイする段階まではカバーされていません。しかし、JetBrains Academyのスキルパスは違います。概念を学んだら、すぐに実際のプロジェクトに適用することができます。IDEの中でレッスンを進めながらコードを書き、構築したものをそのままAWSのサンドボックス環境にデプロイできるのです。
例えば、今まさに必要とされている、PythonとAWSを使ってカスタムLLMを構築・デプロイするパスを選択してみましょう。ここにシラバスが表示されています。各セクションを開くと、PyCharm IDE内で講座が展開されます。普段コードを書いている環境のまま教材を進めることができ、AIアシスタントもIDEに直接組み込まれています。レッスン間の移動も非常にスムーズです。演習問題もIDE内でそのまま解くことができるので、いつも通りの感覚でコーディングが可能です。そして、このレッスンにあるようなファインチューニングしたモデルを実行してデプロイする段階になると、AWSのサンドボックス環境を利用できます。これは模擬環境ではなく、実際にクラウド上で動作するものです。費用はすべて事前に支払われているため、個人のAWSアカウントを用意する必要はありません。私がモデルの構築やファインチューニングを学んでいた頃に、まさに欲しかった仕組みです。
スキルパスを完了すると、GitHubに公開したり面接でアピールしたりできる、実際に稼働するプロジェクトが手に入ります。さらに、JetBrainsとAWSの両方から認定証が発行され、そのスキルが証明されます。生成AIやLLMエンジニアリングのスキルを高め、信頼性を築きたいと考えている方には、JetBrains Academyのスキルパスを心からおすすめします。概要欄にリンクを貼っておきます。
さて、サブディレクトリごとにテストやlintコマンドのスコープを絞る方法や、ビルド生成物などの特定のファイルをエージェントが読み込まないように除外する方法など、カバーすべき戦略はまだありますが、AIレイヤーの次の要素であるフックの話に進みましょう。グローバルルールの直後にこれを取り上げる理由は、すぐに納得していただけるはずです。
自己改善するAIレイヤーと自動更新フック
フックを利用することで、AIレイヤーのセットアップ全体を自己改善していく仕組みを作ることができます。これは本当に素晴らしい手法で、私が冒頭でお話しした価値ある仕組みの一つです。多くのチームは、フックをClaudeの誤操作を防ぐためのスクリプトと考えています。例えば、特定のディレクトリの編集を禁止したり、ファイルやフォルダの削除を制限したりする事前フック（pre-tool use hook）として利用するケースが多いでしょう。しかし、フックのより価値ある使い道は、継続的な改善にあります。
セッションの終了時に実行される事後フック（stop hook）を使えば、そのセッション中に何が起きたかを振り返り、記憶が鮮明なうちに claude.md の更新を提案させることができます。実際のデモを用意しているのでお見せしましょう。今回は開始フックと終了フックの両方を構築しました。開始フック（start hook）を使えば、チーム固有のコンテキストを動的に読み込むことができます。これにより、開発者が手動で設定を行わなくても、全員が適切なセットアップで作業を開始できます。開発者の役割や編集しているコードの領域に基づいて、例えばConfluenceに自動でアクセスし、そのチームや機能、コード領域に該当するドキュメントを取得してくるフックを作ることができるのです。
手元には基本的な実装例があります。 settings.json の中で、開始フックと終了フックを定義しています。終了フックには claude.md の更新提案スクリプトを、開始フックにはセッション開始時のコンテキスト読み込みスクリプトを指定しています。この開始フックは、Gitに関連するコンテキストを読み込みます。まだステージングされていない変更ファイルや、Gitのコミット履歴などを確認します。
実際にClaudeの新しいセッションを開始して、開始フックがこのセッションについて何を教えてくれたか尋ねてみましょう。少し不自然な尋ね方ですが、コンテキストが読み込まれているか確認するためです。すると、現在の状況が表示されます。ワーキングツリーはクリーンで、最近のコミット履歴はこうなっている、という情報が共有されています。これからどのような作業に取り組むのか、直前にどのような作業が行われていたのかというコンテキストが、セッションの開始時点でエージェントに与えられているわけです。これを拡張すれば、先ほど言ったように、Claude Codeを起動した開発者に応じてConfluenceから情報を引っ張ってくることも可能です。工夫次第で多くのことができます。
次に、終了フックのデモをお見せします。簡単な変更要求を出してみましょう。実際の業務であれば、設計、実装、検証というもっと詳細なプロセスを踏みますが、ここではルールの変更提案を発生させるために、あえてシンプルな変更を依頼します。コードベースを進化させていくにあたっては、ルールも同時に進化させていくことが非常に重要です。コードベース側に加えた変更によってグローバルルールへの追加や更新が必要になっているにもかかわらず、 claude.md が古いまま放置されてしまうのは最悪の状況だからです。だからこそ、こうした変更を自動的に提案してくれるプロセスを裏で走らせておくことが強力な武器になります。
このフックは、Claudeが処理を停止したとき、つまりエージェントが自分のターンを終えるたびに毎回実行されます。先ほど一瞬ターミナルが立ち上がったのが見えたと思いますが、裏で別のClaudeセッションがヘッドレスモード（画面表示なし）で起動し、今回の変更内容とグローバルルールを照らし合わせて、微調整が必要な箇所がないかを検証しているのです。そして、その結果をMarkdownドキュメントとして出力します。
出力されたMarkdownを確認してみましょう。たった今実行された振り返りの内容が記載されています。今回影響を受けた2つの領域が表示されており、該当するサブディレクトリのグローバルルールも検証されています。今回の結果は、変更の必要なし、となっています。トライアルの列挙型（enum）の値を追加したことは、既存のモデル規約に準拠しているため、グローバルな方針は今回の変更後も維持されていると判断されたわけです。
何も変更が不要という結論になったため、デモとしては少し物足りないかもしれませんが、これもまた非常に強力な仕組みです。通常、 claude.md の規約を頻繁に変える必要はありませんし、だからこそファイルをごく軽量に保っているのですから。では、今度は claude.md の更新が必要になるような、もう少し大きめの変更を課金サービス（billing service）に加えてみましょう。
実行されました。課金サービスに大きめの変更を加えた結果、Markdownのレビューを確認すると、課金サービスのサブディレクトリにある claude.md の2番目の箇条書きを更新することが推奨されています。実に見事な動きです。あとはこの推奨事項を確認し、自分たちで反映させるだけです。別のClaudeセッションを開いて、これらの変更を適用させるための対話をしてもいいでしょう。これをどう活かすかは皆さん次第です。ここで示したいのは、こうした自己反省のプロセスをバックグラウンドで常に走らせ、必要なときにいつでも人間が対応できる形で提案を受け取れるようにしておける、という強力な手法です。
スキルによるプログラミングワークフローの段階的開示
Anthropicが次にフォーカスしているAIレイヤーの要素は、スキルです。スキルについては、ここ数ヶ月でインターネット上で大きな話題になっているので、ご存知の方も多いでしょう。現在、Claude Codeに新しいワークフローや機能を追加して拡張するための主要な方法となっています。
ここにあるのは、このコードベースにAPIルートを追加するためのスキルの例です。スキルとは、Claude Codeに実行させる一連の手順や、再利用可能なプロンプトのプロセスのことです。大規模なコードベースでは、処理すべきタスクのタイプが何十、何百と存在するため、スキルは非常に重要な役割を果たします。今回の例であれば、APIエンドポイントを構築するというタスクタイプに適用されます。すべてのセッションに、あらゆる領域の専門知識を最初から詰め込んでおく必要はありません。これは、サブディレクトリごとに異なる claude.md ファイルを用意しているのと同じ理由です。これら2つのアプローチには共通する部分もあるので、その違いについても説明します。
スキルは、段階的開示によってこの問題を解決します。専門的なワークフローやドメイン知識を外部化しておき、実際に必要になった瞬間にだけ読み込むのです。これにより、現在のタスクに関係のないプロンプトやワークフローをセッションに持ち込んで、コンテキストを無駄に消費してしまうのを防ぐことができます。
スキルを定義する際は、名前と説明（description）を設定します。この説明部分が、まず最初に開発エージェントに提示されます。エージェントがその説明を読み、現在のタスクにおいてこのスキルを使用すべきだと判断した場合に初めて、詳細が書かれた skill.md ファイルの全体が読み込まれる仕組みです。私のチャンネルでもスキルについては何度も取り上げてきました。
しかし、多くの人がまだ知らないパラメーターが存在します。それこそが、Anthropicが記事の中で言及している、スキルを特定のパスにスコープ指定できる機能です。これにより、コードベースの関連する領域でのみスキルを有効化することができます。例えば、APIルートを追加する手順を何度も再利用したい場合、そのスキルはAPIサービスのディレクトリ内にあるファイルを読み書きしているときにだけ有効になればいいわけです。そこにスコープを絞ることで、特定の領域に触れた瞬間に、対応する規約やワークフローを自動的にセッションのコンテキストに組み込むことができます。これは非常に強力な機能です。
先ほど触れたように、この機能はサブディレクトリ内の claude.md ファイルの役割と少し重なる部分があります。どちらも特定の場所で作業するときにのみ読み込まれるからです。私なりの使い分けとしては、グローバルルールは規約、つまり守るべきルールを定義するものとして捉えています。例えば、すべてのルートはここに登録しなければならない、といった内容です。一方で、スキルはワークフロー、つまり実行する具体的な手順を定義するものです。このように、ルールとワークフローという形で区別すると、整理がしやすくなります。とはいえ、多くの規約において、スキルとして実装すべきか claude.md に書くべきかは、どちらでも対応できるケースがあります。重要なのは、これらの規約やルールを作業対象の領域だけに絞り込み、エージェントに関係のないコンテキストを大量に与えて混乱させないようにすることです。
Anthropicの記事では次にプラグインについて触れていますが、それについては最後に回します。私が作成したプラグインを使って、これらのアイデアを皆さんのコードベースに組み込む方法をお見せするためです。まずは、LSP（Language Server Protocol）のトピックに進みましょう。
LSPとMCPサーバーを組み合わせた高度なコード探索
LSPの活用については、私自身も自分のClaude Code環境に導入し始めたばかりなので、とてもワクワクしています。これは本当に強力な仕組みです。一言で言えば、人間の開発者がIDEの中で使っているのと同じナビゲーション能力を、そのままClaudeに与えることができます。特に大企業では、Claudeがコードベース内を効率的に探索できるように、独自のカスタムLSPを構築しているケースが多々あります。
LSPは、基本的にはどのようなIDEにも最初から組み込まれている機能です。例えばVS Codeで、クラスや変数をコントロールクリックしたときに、別ファイルにあるその定義元へ即座にジャンプできるのはLSPのおかげです。こうした型のヒント、ナビゲーション、ハイライトなどの機能全般をLSPが支えています。
つまり、MCP（Model Context Protocol）サーバーを介することで、私たちがIDEで享受しているこの機能をそのままClaude Codeに提供できるのです。これにより、単純なgrep単体よりもはるかにインテリジェントな検索が可能になります。あるいは、Claude Codeに標準のCLIコマンドとして組み込まれているgrepなどのツールを補完する形で機能させることもできます。
ここで私が構築したものは、一石二鳥の仕組みになっています。記事の中でLSPと、すべてを拡張するための方法としてのMCPサーバーについて触れられているため、このコードベースに付属するローカルMCPサーバーを構築しました。後ほど紹介するプラグインにも含まれているもので、Claude Codeに新しいコードベース検索機能を追加します。
新しいClaudeセッションを開いて確認してみましょう。 /mcp コマンドを実行すると、コードベース検索（codebase search）が有効になっていることが分かります。ここには、既存の検索機能を補完するための3つのツールが用意されています。ここに、このリポジトリ内で monthly_total_cents が参照されているすべての場所を探して、というプロンプトを入力してみます。非常にピンポイントな要求ですが、それこそが狙いです。ここでは検索の具体的な威力を試す必要があります。デモのために、あえてgrepは使わないように指示し、シンボルレベルのアプローチをとるよう伝えます。これにより、LSPを活用して構築したカスタムMCPサーバーが呼び出されるようになります。
これによって、grepを禁止されたエージェントは、LSPの仕組みを裏で動かしているMCPサーバーのツールが必要だと判断し、よりインテリジェントな検索を実行します。指示をしなくても自発的に判断させることもできますし、グローバルルールの中にこれらの検索ツールの使い方の指示を組み込んでおくことも可能です。結果を見ると、カスタムMCPサーバーの find_references ツールなどがしっかりと使用されているのが分かります。定義が1箇所、参照が2箇所見つかりました。素晴らしい動きです。
デモのコードベース自体はシンプルに作ってありますが、実際の複雑なコードベースを想定した動きをしています。結果がクリアで分かりやすい状態を保ちつつ、複雑な構造に対応するバランスをとる必要があったためです。これが、MCPサーバーを使ってLSPの機能を拡張する具体的な例です。コードが数十万行を超えるような巨大なコードベースになると、こうした仕組みが絶対に不可欠になります。grepだけでは処理が遅くなりますし、コードベース内を探索しようとするだけで大量のトークンを消費してしまい、非常に非効率だからです。クラスや変数の定義、参照を直接狙い撃ちするこのようなアプローチの方が、はるかに的確で効率的な検索が行えます。
以上が、LSPとMCPを組み合わせて活用する方法の概要です。大規模なコードベースでClaude Codeを使用する際は、検索能力を向上させるためのこうしたハーネスが欠かせません。これらはスキルと同じように、セッションを通じて必要なときにだけ散発的に呼び出されます。特定の規約やワークフローが必要になったらスキルを読み込むように、定義や参照を検索したくなったらLSPのツールを呼び出すわけです。MCPも同様で、検索を実行したり外部のアクションを起こしたりする必要があるときに、その都度MCPサーバーのツールを呼び出します。
AIレイヤーの最後の要素として、サブエージェントが残っていますが、これは非常にシンプルです。Anthropicのアドバイスもシンプルながら非常に強力なものです。
サブエージェントによる探索と編集の分離
サブエージェントに関する核心的なアイデアは、探索（リサーチ）と編集（実装）のプロセスを分離する、ということです。サブエージェントの運用プロセスでは、まず特定のタスクを切り出して別個に処理させます。例えば、特定のアーキテクチャのベストプラクティスをウェブで検索させたり、コードベースの探索を行って修正すべき具体的な箇所を特定させたりします。タスクを受け取ったサブエージェントは、完全に独立した独自のコンテキストウィンドウの中で動作します。必要な解析をすべて実行した上で、その要約だけをメインのClaude Codeセッションに返します。メインのセッションはその要約を基に思考し、実際の編集アクションを起こすのです。
サブエージェントに任せるような探索タスクは、場合によっては何十万トークンもの膨大な量に膨れ上がることがあります。もしサブエージェントを使わずに、メインのClaude Codeセッションにそのウェブ検索やコードベース探索を直接やらせてしまうと、いざ実際のコード編集を始める段階になったときには、コンテキストウィンドウがすでに不要な情報でパンパンに膨れ上がってしまっています。だからこそ、そうした重い作業はサブエージェントに委託すべきなのです。特に探索タスクにおいては、最終的なおすすめの技術スタックや、Jiraのチケットに基づいて修正すべきコードの領域といった、結論の要約だけが手に入れば十分だからです。これが、サブエージェントにタスクを割り振る理由です。
ここではサブエージェントの複雑なデモは行いません。というのも、私は普段から会話の冒頭などでごく当たり前のようにサブエージェントを活用しているからです。例えば、データベース担当、バックエンド担当、フロントエンド担当の3つのサブエージェントを立ち上げて、認証機能の追加方法を検討して、といった指示を日常的に出しています。現在、Claude Codeをはじめとする多くの開発エージェントには、こうしたサブエージェントの仕組みが標準で組み込まれています。そのため、昔のようにユーザーが自分でカスタムのサブエージェントを定義する必要はありません。このように要求を投げるだけで、Claude Codeに内蔵されている探索用のサブエージェントが自動的に作動します。タスクの切り出しから要約の回収まで、すべてのプロセスを自動で処理してくれるのです。
ブログ記事の残りの部分では、先ほど触れたような、文字列ではなくシンボル単位で検索できるようにLSPサーバーを構築する話や、 claude.md ファイルを積極的にメンテナンスしていく重要性など、私がすでに説明した戦略が多くカバーされています。 claude.md のメンテナンスについては、先ほどお見せした、Claude Codeの操作中に推奨事項を提示してくれる終了フックがまさにその役割を果たします。
ここで、皆さんのために用意したプラグインの話をしておきましょう。概要欄のリポジトリのREADMEに、この仕組みをご自身のコードベースに導入するための手順が書かれています。もちろん、各サブディレクトリの claude.md の中身などは私固有の設定ですが、このプラグインを導入すれば、自己改善を行う終了フックや、私がカスタム構築した探索用サブエージェント、そしてLSPを搭載したコードベース検索用のMCPサーバー一式がすべて手に入ります。検索用のハーネスが丸ごと手に入るわけです。さらに、パスパラメーターを使ってスキルの有効範囲を特定のサブディレクトリに限定する具体的な方法を示す、汎用的なスキルのサンプルも同梱しています。まずはご自身のコードベースでこれらの手法を素早く実験するためのスタートラインとして、このプラグインを活用してみてください。すでに独自のAIレイヤーを構築し始めているコードベースであっても、このプラグインを追加でインストールすることが可能です。
導入の手順は簡単です。Claude Codeのセッション内で、 /plugin marketplace add に続けてローカルのリポジトリパスを指定します。まだnpmなどにはホストしていないので、一度リポジトリをローカルにクローンしていただく必要があります。そのパスの末尾に tooling フォルダを指定してください。その後に /plugin install helpline-ai-layer @helpline/tooling を実行します。画面の指示に従ってインストールプロセスを進めれば、すべての機能がセットアップされ、すぐに使い始めることができます。これが一つの方法です。プラグインの形で簡単に導入できるように用意しておきました。
ブログ記事を読むこと以外で、ここで紹介したアイデアを体験するもう一つの方法は、このリポジトリをそのままクローンし、そこに向けてClaude Codeを起動することです。ディレクトリのパスをコピーしてClaude Codeに渡し、これは動画で紹介されていた複雑なコードベース向けの戦略が集まったリポジトリだから、これらがどのように機能しているのか、そして自分のコードベースにどう応用できるかを教えて、と頼んでみるのです。最近のリポジトリの理解方法としては、これが最も手っ取り早いでしょう。エージェント自身にコードベースを読み込ませ、解説や適用を手伝ってもらうのが一番簡単です。まずはそこから始めてみることをおすすめします。
組織におけるAIコーディング環境の標準化
今回ご紹介した戦略が、皆さんの大規模なコードベースの開発において、すぐに役立つ実践的なものになっていれば幸いです。すでにいくつかのアプローチを取り入れていた方にとっても、何かしら新しい気づきや有益なヒントが見つかったのであれば嬉しく思います。
最後に、Anthropicが記事の最下部で示している、非常に優れたアドバイスを紹介して締めくくりたいと思います。それは、Claude Codeの管理と社内導入推進の責任（オーナーシップ）を明確に割り当てる、という組織的なアプローチについてです。私はこれまで多くの企業でコンサルティングや研修を行ってきましたが、これは本当に的を射たアドバイスだと実感しています。彼らが言っているのは、組織のためのAIレイヤーの初期構築を牽引する、1人の担当者、あるいは小規模な専門チームを公式に任命すべきだということです。
具体的な進め方としては、まず静かな投資期間を設けます。数人のメンバーが先行して、組織全体のルール、スキル、LSP、MCPサーバーといったAIレイヤーの基盤をしっかりと構築します。そして、完成したものを時間をかけて他のメンバーへと段階的に展開していくのです。このアプローチの強みは、全員が共通して利用できる強固な土台を最初に作れる点にあります。これにより、メンバー全員が最初からClaude Codeなどの開発エージェントを使って、ブレのない一貫した成果を素早く出せるようになります。
最悪なのは、最初にツールを使ったときにAIレイヤーが何も用意されていないせいで、メンバーが落胆して使わなくなってしまうことです。そうした初期の失望は絶対に避けるべきです。また、標準化された基準がないまま、メンバーがそれぞれ個別に独自のAIレイヤーをバラバラに構築し始めてしまう状況も防がなければなりません。組織として共通のスタンダードを持つことが重要です。これは本当に素晴らしい指摘です。
ちなみに、これは私自身が普段からサポートしている領域でもあります。私は企業向けの研修を提供しており、AIレイヤーの構築支援や、AIコーディングの核心的な手法のレクチャー、そしてClaude Codeをはじめとする開発エージェントツールを組織に定着させるための標準化プロセスの策定をお手伝いしています。プロフィールの連絡先にメールアドレスを載せていますので、興味のある企業の方はぜひお気軽にご連絡ください。
今回の戦略が皆さんのお役に立てば幸いです。最後までお付き合いいただき、本当にありがとうございました。何か分からない点があれば、ぜひ下のコメント欄で教えてください。この動画が参考になり、今後もAIコーディングやClaude Codeに関するコンテンツをもっと見たいと思っていただけたなら、高評価とチャンネル登録をよろしくお願いいたします。それでは、また次の動画でお会いしましょう。
コメント