大規模コードベースでClaude Codeが動作する仕組み：ベストプラクティスと出発点

• Claude Codeはインデックスをアップロードせず、開発者マシン上でファイルシステムを探索し、grepや参照追跡でライブなコードベースを直接読み取る
• パフォーマンスはモデルだけでなく、CLAUDE.md、hooks、skills、plugins、MCPサーバーで構成されるハーネスと、その構築順序に大きく左右される
• 大規模リポジトリでは、薄く階層化された**CLAUDE.md**、サブディレクトリからの開始、スコープを絞ったテスト・lint、除外ルールが探索効率を高める
• LSP統合は文字列検索の代わりにシンボルベースの定義・参照追跡を提供し、多言語・大規模コードベースで誤った探索を減らす
• 導入を成功させるには、3〜6か月ごとに設定を見直し、plugin・権限・ルールを管理するDRIまたはagent managerが必要になる

---

大規模コードベースでClaude Codeが探索する仕組み

• Claude Codeはソフトウェアエンジニアのようにファイルシステムを巡回し、ファイルを読み、grepで必要な内容を探し、コードベース全体の参照をたどる
• 開発者マシン上でローカルに動作し、コードベースのインデックスを構築・維持したり、サーバーにアップロードしたりする必要がない
• RAGベースのAIコーディングツールはコードベース全体を埋め込み、クエリ時に関連チャンクを取得するが、大規模環境では埋め込みパイプラインが活発な開発速度に追いつかないことがある
• インデックスが数週間前、数日前、数時間前の状態を反映していると、すでに名前が変わった関数や前スプリントで削除されたモジュールを返すことがあり、その情報が古いというシグナルすらない場合がある
• Claude Codeのエージェント型検索は、埋め込みパイプラインや中央インデックスなしに、各開発者インスタンスが生きたコードベースを基準に作業できるようにする
• 欠点もある。Claudeは、どこを見るべきかを把握できる開始コンテキストが十分にあるときに最もよく機能する
• 曖昧なパターンの全インスタンスを10億行規模のコードベースから見つけるよう求めると、作業が始まる前にコンテキストウィンドウの限界にぶつかる可能性がある
• コードベースを適切に整備し、CLAUDE.mdファイルやskillsでコンテキストを階層化したチームほど、より良い結果を得られる

モデルと同じくらい重要なハーネス

• Claude Codeの性能は、モデルそのものよりも、モデルの周囲に構築された**ハーネス(harness)**に大きく左右される
• ハーネスは、CLAUDE.md、hooks、skills、plugins、MCPサーバーという5つの拡張ポイントで構成される
• 各レイヤーは前のレイヤーの上に積み重なるため、チームが構築する順序も重要になる
• LSP統合とsubagentsは、この構成を補完する追加能力として機能する

• CLAUDE.mdファイル

  • CLAUDE.mdは、Claudeがすべてのセッション開始時に自動で読むコンテキストファイルである
  • ルートファイルには全体像を、サブディレクトリのファイルにはローカルルールを入れる
  • すべてのセッションに読み込まれるため、広く適用される内容に集中しないと性能低下を招きやすい

• Hooks

  • Hooksは、Claudeの誤った挙動を防ぐスクリプトにとどまらず、設定を継続的に改善するうえでより大きな価値がある
  • stop hookはセッション中に起きたことを振り返り、コンテキストが新鮮なうちにCLAUDE.mdの更新を提案できる
  • start hookはチームごとのコンテキストを動的に読み込み、開発者が手動設定しなくても自分のモジュールに合った設定を受け取れるようにする
  • lintやformattingのような自動チェックは、Claudeに指示を覚えさせるよりも、hookでルールを決定的に強制した方が一貫した結果を生みやすい

• Skills

  • Skillsは、すべてのセッションを肥大化させずに、必要な専門性をオンデマンドで維持できるようにする
  • 大規模コードベースには数十種類の作業タイプがあり得るが、すべての専門性がすべてのセッションに必要なわけではない
  • Skillsは段階的開示(progressive disclosure)によって、特化したワークフローやドメイン知識をコンテキスト空間の外に置き、必要なときだけ読み込む
  • たとえば、セキュリティレビューskillはClaudeが脆弱性を評価するときに読み込まれ、ドキュメント処理skillはコード変更後にドキュメント更新が必要なときに読み込まれる
  • Skillsは特定パスにスコープを設定できるため、決済サービスチームのデプロイskillをそのディレクトリにだけバインドし、モノレポ内の他領域の作業では自動ロードされないようにできる

• Plugins

  • Pluginsは、うまく機能する設定を属人的な知識のままにしないための配布手段である
  • pluginはskills、hooks、MCP設定を1つのインストール可能なパッケージにまとめる
  • 新しいエンジニアが初日にpluginをインストールすれば、すでにClaudeを使っていた人たちと同じコンテキストと機能をすぐに得られる
  • pluginの更新はmanaged marketplacesを通じて組織全体に配布できる
  • ある大手小売組織は、Claudeを社内分析プラットフォームに接続するskillを作成し、ビジネスアナリストがワークフローを離れずに実績データを取得できるようにしたうえで、全社展開前にそれをpluginとして配布した

• Language Server Protocol統合

  • Language Server Protocol(LSP)統合により、Claudeは開発者のIDEと同じコード探索能力を持てるようになる
  • 大規模コードベース向けIDEの多くは、すでに「go to definition」や「find all references」を動かすLSPを実行している
  • これをClaudeに公開すると、関数呼び出しを定義までたどり、ファイル全体の参照を追跡し、異なる言語で同名の関数を区別するシンボルレベルの精度を得られる
  • LSPがない場合、Claudeはテキストのパターンマッチングに依存するため、誤ったシンボルに到達することがある
  • あるエンタープライズソフトウェア企業は、CおよびC++の探索を大規模環境で安定させるため、Claude Codeのロールアウト前にLSP統合を全社導入した
  • 多言語コードベースでは、最も価値の高い投資の1つである

• MCPサーバー

  • MCPサーバーは、Claudeが直接到達できない内部ツール、データソース、APIに接続する方法である
  • 最も成熟したチームは、Claudeが直接呼び出せるツールとして構造化検索を公開するMCPサーバーを構築している
  • 別のチームは、Claudeを社内ドキュメント、チケットシステム、分析プラットフォームに接続している

• Subagents

  • Subagentsは探索と編集を分離する
  • subagentは独自のコンテキストウィンドウを持つ隔離されたClaudeインスタンスで、タスクを受け取って実行し、最終結果だけを親に返す
  • ハーネスが整った後、一部のチームは読み取り専用subagentを立ち上げてサブシステムをマッピングし、結果をファイルに書き出させ、その後メインエージェントが全体像を踏まえて編集するようにしている

• 構成要素ごとの役割とよくある混同

  • CLAUDE.md: Claudeが自動で読むコンテキストファイルで、すべてのセッションに読み込まれる。プロジェクトごとのルールやコードベース知識に適している一方、skillに入れるべき再利用可能な専門性まで入れやすい
  • Hooks: 重要なタイミングで実行されるスクリプトで、イベントによってトリガーされる。一貫した動作の自動化やセッション学習の捕捉に適している一方、自動実行すべきことをプロンプトで処理しがちである
  • Skills: 特定の作業タイプ向けにパッケージ化された指示で、関連する場合にオンデマンドで読み込まれる。セッションやプロジェクトをまたいで再利用される専門性に適している一方、すべてをCLAUDE.mdに入れがちである
  • Plugins: skills、hooks、MCP設定のバンドルで、設定後は常に利用可能。組織全体に有効な設定を配布するのに適している一方、良い設定を属人的な知識のままにしがちである
  • LSP: 言語ごとのサーバーを通じたリアルタイムのコードインテリジェンスで、設定後は常に利用可能。型付き言語でのシンボルレベル探索や自動エラー検出に適している一方、自動で使えるものだと思い込みやすい
  • MCPサーバー: 外部ツールやデータへの接続で、設定後は常に利用可能。Claudeが直接アクセスできない内部ツールへのアクセスに適している一方、基本機能が動く前にMCP接続から作り始めがちである
  • Subagents: 特定タスク用の別個のClaudeインスタンスで、呼び出し時に実行される。探索と編集の分離や並列作業に適している一方、探索と編集を同じセッションで処理しがちである
  • LSPはpluginレイヤー経由でアクセスされ、subagentsは設定された拡張ポイントではなく委任能力である

成功した展開で繰り返し見られた3つの設定パターン

• 大規模でも探索可能なコードベースにする

  • Claudeが大規模コードベースで支援できる範囲は、正しいコンテキストを見つける能力によって制限される
  • すべてのセッションに多すぎるコンテキストを読み込むと性能が落ち、少なすぎるとClaudeは手探りで探索することになる
  • 効果的な導入では、初期段階でコードベースをClaudeが読みやすい形にすることへ投資している

  • CLAUDE.mdファイルは薄く、階層的に保つ

    • Claudeはコードベース内を移動しながら、CLAUDE.mdファイルを加算的に読み込む
    • ルートファイルは全体像を、サブディレクトリのファイルはローカルルールを担う
    • ルートファイルにはポインタと致命的な注意点だけを入れるべきで、それ以外はノイズになりやすい

  • リポジトリルートではなくサブディレクトリから始める

    • Claudeは、タスクと実際に関係するコードベース部分にスコープが絞られているときに最もよく機能する
    • モノレポでは、ツールがルートアクセス前提であることが多く、直感に反するかもしれない
    • Claudeはディレクトリツリーを自動で上にたどり、見つけたすべてのCLAUDE.mdファイルを読み込むため、ルートレベルのコンテキストは失われない

  • テストとlintコマンドはサブディレクトリごとにスコープを絞る

    • Claudeが1つのサービスしか変更していないのにテストスイート全体を実行すると、タイムアウトが起き、無関係な出力でコンテキストを浪費する
    • サブディレクトリのCLAUDE.mdファイルには、コードベースのその部分に適用されるコマンドを明記すべきである
    • 各ディレクトリが独自のテストやビルドコマンドを持つサービス指向のコードベースではうまく機能する
    • 深いクロスディレクトリ依存を持つコンパイル言語のモノレポでは、サブディレクトリ単位のスコープ設定はより難しく、プロジェクトごとのビルド設定が必要になることがある

  • .ignoreファイルで生成ファイル、ビルド成果物、サードパーティコードを除外する

    • .claude/settings.jsonにpermissions.denyルールをコミットすれば、除外ルールがバージョン管理される
    • チームのすべての開発者が、個別設定なしで同じノイズ削減効果を得られる
    • 一部のコードベースでは、生成ファイル自体が開発対象である場合もある
    • コードジェネレーターを扱う開発者は、プロジェクトレベルの除外ルールをローカル設定で上書きでき、他のチームメンバーには影響しない

  • ディレクトリ構造だけでは足りないならコードベースマップを構築する

    • コードが一般的なディレクトリ構造に整理されていない組織では、ルートに置く軽量なMarkdownファイルが役立つ
    • 各トップレベルフォルダとその中身を1行で説明すれば、Claudeがファイルを開く前に目を通せる目次になる
    • トップレベルフォルダが数百ある場合は、ルートファイルでは最上位構造だけを説明し、サブディレクトリのCLAUDE.mdが次のレベルの詳細をオンデマンドで提供する階層型アプローチが最も効果的である
    • より単純な場合は、Claudeが参照すべき特定のファイルやディレクトリを@でメンションするだけでも同じ役割を果たせる

  • LSPサーバーで文字列ではなくシンボルベースで検索する

    • 大規模コードベースで一般的な関数名をgrepすると何千件もヒットし、Claudeは何が重要か判断するためにファイルを開いてコンテキストを消費してしまう
    • LSPは同じシンボルを指す参照だけを返すため、Claudeが何も読む前にフィルタリングが行われる
    • 設定するには、言語向けのcode intelligence pluginと対応するlanguage serverバイナリをインストールする必要がある
    • Claude Codeのドキュメントには、利用可能なpluginとトラブルシューティング方法が含まれている

  • 例外

    • 階層型CLAUDE.mdアプローチでも崩れるエッジケースがある
    • 数十万個のフォルダと数百万個のファイルを持つコードベースや、Gitではないバージョン管理にあるレガシーシステムがそれに当たる

• モデル知能の変化に合わせてCLAUDE.mdファイルを保守する

  • モデルが進化すると、現在のモデル向けに書いた指示が将来のモデルには邪魔になることがある
  • 過去にClaudeが苦手としていたパターンを導くCLAUDE.mdルールは、新しいモデルでは不要になったり、逆に制約になったりする
  • たとえば、すべてのリファクタリングを単一ファイル変更に分割するというルールは、以前のモデルが流れを維持する助けになったかもしれないが、新しいモデルがうまくこなせる調整済みの複数ファイル編集を妨げることがある
  • モデル推論やClaude Codeツールの特定の限界を補うために作られたskillsやhooksは、その限界がなくなればオーバーヘッドになる
  • Perforceコードベースでp4 editを強制するためにファイル書き込みを横取りしていたhookは、Claude CodeがネイティブPerforceモードを追加した後は重複になる
  • チームは3〜6か月ごとに意味のある設定レビューを見込むべきである
  • 主要なモデルリリースの後で性能が頭打ちになったように感じるときも、設定を見直す価値がある

• Claude Codeの管理と導入のオーナーを明確にする

  • 技術的な設定だけでは導入は進まない
  • 最も速く広がったロールアウトでは、広範なアクセスの前にインフラ投資が行われていた
  • 小さなチーム、時には1人だけで、ツールを接続し、開発者が初めてClaudeに触れた時点ですでにワークフローに合うようにしていた
  • ある企業では、数人のエンジニアが初日から使えるpluginとMCPの束を構築した
  • 別の企業では、AIコーディングツール管理を専任とするチームがロールアウト前にインフラを整備した
  • この作業は通常、新規エンジニアのオンボーディングや開発者ツール構築を担当するDeveloper ExperienceまたはDeveloper Productivity組織の傘下に置かれる
  • 複数の組織では、Claude Codeエコシステムを管理するハイブリッドなPM/エンジニア職としてagent managerが登場している
  • 専任チームがない場合の最小実行形は、DRIを1人置くことだ
  • このDRIは、Claude Codeの設定、設定値の判断、権限ポリシー、plugin marketplace、CLAUDE.mdルールのオーナーシップと最新状態の維持責任を持つべきである
  • ボトムアップの導入は熱意を生むが、効果のあるものを中央集約する人がいなければ断片化しやすい
  • 標準化されたCLAUDE.md階層や厳選されたskills・pluginsといったClaude Codeの規約を集約し、広める個人またはチームが必要である
  • この作業がなければ、知識は属人的なものとして残り、導入は停滞する

ガバナンスとロールアウト

• 大規模組織、特に規制業界では、ガバナンス上の問いが早い段階で浮上する
• どのskillsやpluginsを使えるのかを誰が統制するのか、何千人ものエンジニアが同じものを独立に作り直さないようにする方法、AI生成コードに人間作成コードと同じレビュー手順を通させる方法が主な論点である
• 初期段階では、承認済みskillsの定義済みセット、必須のコードレビュー手順、制限付きの初期アクセスから始め、信頼が積み上がるにつれて拡張していくアプローチが推奨される
• 最もスムーズな展開は、初期のうちにエンジニアリング、情報セキュリティ、ガバナンスの代表が参加するクロスファンクショナルなワーキンググループを作り、要件とロールアウトロードマップを共同で定義した組織で見られた

組織に適用する際の前提と限界

• Claude Codeは、エンジニアが主要なコードベース貢献者であり、リポジトリがGitを使い、コードが標準的なディレクトリ構造に従う伝統的なソフトウェアエンジニアリング環境を中心に設計されている
• ほとんどの大規模コードベースはこの枠組みに当てはまるが、大きなバイナリアセットを持つゲームエンジン、非伝統的なバージョン管理環境、非エンジニアがコードベースに貢献する環境では追加の設定作業が必要になる
• ここで示したパターンは伝統的な構成を前提としており、複数の顧客環境で機能している
• 残る複雑さは、各組織のコードベース、ツール、組織構造に合わせて判断する必要がある
• AnthropicのApplied AIチームは、このようなパターンを各組織の具体的な要件へ落とし込むために、エンジニアリングチームと直接協業している

[GN⁺]

Hacker Newsのコメント

• 「ソフトウェアエンジニアのように」コードベースを探索するという表現と結論が、互いに食い違っているように見える
  自動補完やLSPは常に使うし有用だが、それも一種のインデックスではないのか？ Claudeがなぜそれを使えないのかも疑問だ
  ソフトウェアエンジニアはコードベースを記憶していることもあるが、それは実質的にはRAGに近く、自動補完されるCMD+Pで必要なファイルを探す筋肉記憶も多い
  何千人ものエンジニアが同時に変更するコードベース全体についてリアルタイムである必要はなく、単に自分が作業中のブランチだけをしっかり見ればよい
  最初からファイルシステムを巡回しながらコードベースを探索することはまれで、普通は新しいコードベースのときくらいだが、その場合でも最適な体験とは言いがたい

  • 自分の働き方とまったく同じだ
    LSPがなかった時代から大きなコードベースの探索方法を身につけていて、長年vimを使いながらgrepで関連ファイルを探してきた
    去年Claude Codeを初めて使ったとき、「なんだ、まさに自分がやろうとしていたことをやっているな」という感覚だった
  • 答えは記事の導入部にある
    Claude Codeは、数百万行規模のモノレポ、数十年物のレガシーシステム、数十のリポジトリにまたがる分散アーキテクチャで運用されることが前提だ
    だから、どこでも動作する堅牢なツールを使う一般的なケースに最適化されていて、特に大きくて散らかったコードベースでそうだという話だ
    ただし、整理された小さなリポジトリなら、より良いツールを使えるし使うべきだという指摘も正しい
    少なくともCodexはそのように動作し、たとえばgrepをする前にまず go doc を使う
  • 本当に大きなコードベースでは、grepとfindはタイムアウトする
    その規模で仕事をすると、Claudeが検索を可能にするために用意されたツールを使わないことにすぐ気づく
  • 短い段落の中にもっともらしい表現が多いが、実際には希望的観測を含んだ主張に見える
    「ソフトウェアエンジニアのように」という言い方は部分的にしか当てはまらない
    人間もシンボル検索は使うが、特定の作業コンテキストで記憶しているシンボルを検索する
    今のClaude Codeがシンボルを無差別に探索するやり方は、エンジニアの働き方とは違う
    タイポ1つでエージェントが何かを再実装すべきだと判断することもあり、運よくファイルを読めても簡単にハルシネーションに陥りうる
    それは大きなコードベースでの働き方でもない
    「grepで正確に必要なものを見つける」という部分が特に引っかかる
    grepをするには何をgrepすべきか知っていなければならず、結果が何千件も出れば全部確認しなければならない
    そういう結果が出たら、人間は機械的に総当たりで眺めるのではなく、出力を絞る方法を考える
    記事のアプローチは、堅実な推奨事項というより現在のやり方を正当化する説明に近い
    「コードベースのインデックスは不要だ」という話も間違いではないが、grep-read-grepで文脈を膨らませながら、いつか答えにたどり着くという意味でしかない
    それは「Claude Codeがなくても開発者が自分で実装できるのだから、Claude Codeは不要だ」という話に似て聞こえる
    この「不要だ」というメッセージは、その判断を絶対命題のようにコミュニティへ伝えている点で誤っていると思う
    全体として組織コストについては率直だ
    複数の組織で「エージェントマネージャー」という、PMとエンジニアを混ぜたような役割がClaude Codeのエコシステムを管理するために生まれており、チームは3〜6か月ごとに意味のある設定レビューを行うべきだと述べている
    これは、事前構築されたコードインテリジェンス層なしで大規模なClaude Codeを使う現実を正確に示している
    方向性は正しいが、読み終えると「問題は解けておらず、ここが我々の限界だ」という後味が残る
  • コードベースの一部を最初から探索するとしても、決して変わらない部分もあるのに毎回探索するのはトークンの無駄が大きい
    Claudeとよく衝突する点も、探索をもっと減らしてほしいということだ
    ほとんど変わらないものを遅くて高価な方法でなぞるより、自分のほうがよく知っているし速い
    それなのに毎回同じ種類のウサギ穴に入っていく

• 逸話として、LLMのオンボーディングとオーケストレーション用プロジェクトを設計していたとき、Claudeは各ファイルの最初の40行だけを読むことを選んだ
  後で別セッションで品質の低さの原因を探っていたClaudeがその欠陥を見つけ、ドキュメント行と関数シグネチャの入出力を入力とするAST解析を行うようコードを変更した
  Claudeの初期アプローチは本当にひどかった
  Claude Codeがどれほど多く修正・レビューされれば良くなりうるのか、そもそも良いコードを作れるのか疑問に感じる
  一般化すると、Claudeは「最初の40行だけ読む」のような局所的で識別可能な悪い判断は直せる
  欠陥が切り分けられていて、1つのコード片に追跡できるからだ
  しかし実際のソフトウェア品質問題は、個別には合理的な小さな判断が積み重なって悪い結果を生むことが多い
  その場合、どれか1つが明白な「欠陥」ではないので、低品質な構成要素を断片的に生成するツールは、各断片が単独では問題なさそうに見えるため、良いコードへ収束できないかもしれない

  • 文脈保持のために、ソースコードを細い穴からのぞき込むように学習されているように見える
    この場合は、下位ロジックや完全なサブエージェントがうまくはまるかもしれない
    たとえばサブエージェントに「このファイルをざっと見て要約し、XとYに関係する部分を示してくれ。そうしたら自分がメインコンテキストで見る」と任せるやり方だ
    また、メインの作業フローを定期的に観察し、自分が考えているファイル内の何かが現在の作業に関係している、あるいは方向を変えうると判断したら割り込ませることもできる

• Claude Codeが大きなコードベースでどう動くかって？ 簡単だ
  小さなプロジェクトでも最初のプロンプトで5時間利用枠の35% まで食い、5分以内に素早く応答しないとキャッシュが飛んで次のプロンプトでまた12〜15%払うことになる

  • リンク先の記事はこれを避ける方法を説明している
    大きなコードベースに素朴に放り込めば、探している間に大量のトークンを燃やすのはその通りだ

• Claude Codeがコードベースを検査して、効果的なハーネスを自動生成してくれないものか？
  CLAUDE.md や AGENTS.md、skills、プラグインを定義してみたが、他の人たちが言うほどの効果は得られていない
  たとえばLSPプラグインがあってもClaude CodeはLSPのシンボル名変更を使わず、ファイルを1つずつ遅く修正したり、プロンプトに特定の手がかりが入っていたらskillを呼び出せと明記しても呼び出さなかったりする
  自分の使い方が悪いのだろうか？ コピーして使える堅牢なハーネスの例があるのか知りたい

  • これは何年も続いている痛点で、まだまったく解決されていない
    「AならXをしろ。B、C、Dをしろ。Aをしろ」と言っても、ただXを使わない
    「忘れた」からだ
    ルール作成に費やした時間が本当に報われるか信じられず、むしろいつか失敗すると信じられてしまう
    RAG、ハーネス、skillsはすべてこれを直すと言っていたが、現実には直せていない
  • /init の使用と、コードベースを説明する CLAUDE.md または AGENTS.md ファイルを置くのをやめた
    残したのは、コードベースを探索する方法と、調査時に git log を使えという内容だけで、これもおそらく重複している
    自分にも答えはわからない
    作業しているコードベースはだいたい10万行程度で、大きい部類に入るのかはわからないが、個人的にはこれまで触った中で最大のリポジトリだ
  • 場合によっては、スクリプトを付けた hooks がコンテキストウィンドウに情報を入れてくれる方式が有効に見える
    コンテキストを制限するため、不要なリンターメッセージは一部削る必要があった
    OSのパッケージリポジトリからインストールしてスクリプトから呼び出せるリンターや言語別チェッカーも役立つ
    モデルとskillコンテキストの組み合わせも差を生むことがある
    4.6で「動いていた」skillが4.7ではうまく合わないことがあるが、4.7は4.6より比較的安定している一方で、より明示的な指示を必要とする
    skillを更新するのも役立つことがあり、その前後でテストと実行を比較すべきだ
    Claude Codeは不要なツール呼び出しもコンテキストに入れるので、たとえばbeadsが好きなら作業を抑制しなければならないこともある

• コードベースのインデックスに関する主張には同意しない
  PHPStormや他のJetBrains IDEではインデックスがかなりうまく機能する

  • PHPStormのインデックスはすばらしい
    ごくまれに壊れたことはあるが簡単に直せたし、古い結果を受け取ったこともない
    Claudeの検索ツールを使ったことがあるなら、あのチームがインデックスについて何もわかっていないと言われても驚かないだろう
    主力製品がテキストベースのチャットである会社が、ユーザーにそのチャット内でテキスト検索を簡単にさせないのは理解できない
  • Claude CodeはJetBrainsのMCPを使ってそのインデックスを利用できる
  • 奇妙な主張だ
    AIの粗製乱造記事か？ GitHub Copilotもかなり良いローカルインデックスを持っている
    コードをベクターデータベースに入れるのは、そこまで難しい問題ではない

• この記事はClaudeが書いたのが明らかだ
  無駄が多く、実質的な内容はあまりない

• C、C++、C#、Java、PHPのように、チームがAIコーディングツールと常に結びつけて考えるわけではない言語も含まれるという表現は奇妙だ
  なぜClaude Codeがそうした言語でうまく動かないと予想しなければならないのか？ どんな言語を想定しているのだろう、PythonやJavaScriptか？

• 数週間どころか数か月単位でも様相が変わる業界で、明確なパターンが現れるほど十分な時間があり、そのパターンが大きなコードベースで成功していたというのは興味深い
  成功基準とは何だろう？ 本番データベースを消さなかったことか、チームの速度が上がったことか、コードベースの寿命が延びたことか、運用チームがより幸せになったことか？

  • AIツールのせいで本番データベースが吹き飛んだのなら、それは本番リソースを削除できる本番権限を開発者に与えた本人と組織の失敗だと言い続けたい
    そんなレベルの無制限アクセス権を持つ会社で働いたことはない

• 最近のストレスはすべてClaude Codeが指示に従わないことから来ていて、コードベースが大きくなるほど悪化している
  誤解しないでほしいが、Claudeはすごいし大好きだ
  しかしClaude Codeだけを雇ってコードベースを保守したり機能追加させたりすることはまったくできない
  過去のミスに関するメモリ項目を追加し続けているが、重要な指示を無視する問題はいまだに約90%の確率で起こる
  避ける唯一の方法は、すべての作業を横で見張って結果を徹底的にレビューすることだけだ
  Claude Codeはドキュメント化や大きなコードベースの理解にはすばらしいが、全体を理解する必要がある変更作業には弱い
  たとえばコードベース全体で複数エンティティ向けに使っているレジストリパターンが約10個あるのだが、「この1つのレジストリパターンを使え」という明示ルールがあったにもかかわらず、Claude Codeはエンティティごとに独立したレジストリを4つ別々に実装した
  この単純な作業を正しくやらせるために半日ほどClaude Codeに怒鳴るようなことをし、結局ストレスと時間を節約するため自分で直した

• 各 CLAUDE.md ファイルに正確に何を入れるべきかを具体的な用語で説明してもくれないのに、そんなファイルがどれほど重要なのかわからない

  • 魚: ここで読める https://code.claude.com/docs/en/best-practices#write-an-effe...
    釣り方: 1) 公式の skill-creator をインストールする 2) 上のリンクを使って claude-md-improver を作る 3) 公式ドキュメントで progressive-disclosure トピックを調べさせてskillを改善する 4) 新しいskillを CLAUDE.md ファイルに適用し、変更を受け入れる