GitHub Code Searchは「検索窓」ではない。負債を狩る「外科用メス」だ。
GitHubの検索機能がいまだに「リポジトリ名を探す場所」だと思っているなら、今すぐその認識を捨ててほしい。GitHub Code Searchは、巨大なモノレポや数百のリポジトリを跨ぐ「全社的コードベースのインデックスエンジン」であり、技術負債を殲滅するための最も強力な兵器だ。
今日は、私がテックリードとしてチームの生産性を限界突破させるために使っている「Code Searchの極限活用術」を伝授する。
—
1. 「従来の検索」と「Code Search」の決定的違い
従来の検索は、単なる「文字列マッチング」に過ぎなかった。しかし、新しいCode SearchはAST（抽象構文木）に近い構造的な理解に基づいたインデックスを構築している。
- 従来の検索: インデックスが貧弱で、記号（`{`, `(`, `.`など）が無視されがち。検索速度も遅い。
- Code Search: 記号や空白を正確に扱い、コードの構造（クラス、関数、変数）を認識する。さらに、検索対象を「特定の言語」「特定のパス」に絞り込む修飾子が驚異的に高速に動作する。
—
2. 実践：負債を狩る「超強力クエリ」テクニック
技術負債の特定は「推測」ではなく「データ」で行うべきだ。以下の検索クエリは、私が現場で実際に使用しているものだ。
① 非推奨APIの全社横断的洗い出し
古いライブラリの特定や、非推奨になったメソッドの呼び出しを瞬時に見つける。
例: 旧来の ‘Request.send()’ を使っている箇所を特定（組織配下で検索）
org:my-company “Request.send(” language:typescript -path:test/ -path:node_modules/
- ポイント: `-path` を使い、テストコードや依存ライブラリを徹底的に除外する。ノイズを消すことで、修正対象の純度を100%に高める。
② ハードコードされた「マジックナンバー/URL」の殲滅
コードベースに散らばる直書きの認証キーやAPIエンドポイントを炙り出す。
正規表現を使用して、特定のパターンを持つURLを抽出
“https://api.legacy-system.com” path:src/
- 応用: 正規表現モードをONにして `/(http|https):\/\/[^\s]+/` で全外部通信を棚卸しするのも良い。
③ 脆弱な実装パターンの発見
セキュリティ的に危うい実装（例えば、SQLインジェクションの脆弱性があるクエリ構築）を全リポジトリから検索する。
文字列結合によるSQLクエリの構築を探す（注意：AST検索ではないが強力）
“SELECT FROM” + ” WHERE id = ”
—
3. 開発スピードを劇的に上げる「神ツール・設定」
隠れたキーボードショートカット
- `Shift + /`: どこにいても即座に検索窓にフォーカス。
- `Ctrl + Enter` (or `Cmd + Enter`): 検索結果を新しいタブで開く。
- `Tab` キー: 検索フィルターのオートコンプリートを爆速で切り替える。
絶対に入れるべき神プラグイン
- [GitHub Octotree](https://github.com/ovity/octotree): 検索結果から該当ファイルに飛んだ後、即座にプロジェクト全体をツリー表示できる。これがないと大規模リポジトリの探索は地獄になる。
- [Refined GitHub](https://github.com/refined-github/refined-github): GitHubのUXを最適化する必須ツール。検索結果の表示やPRの管理を効率化する。
—
4. チームで共有すべき「設定のベストプラクティス」
チームで技術負債を管理するには、`.github/CODEOWNERS` と `.github/settings.yml` の運用が鍵だ。
`.github/settings.yml` (Probot/settings用) の構成例
CI/CDのパイプラインやブランチ保護ルールをコードとして管理し、全リポジトリで統一する。
チーム共通のブランチ保護ルール
branches:
main:
protection:
required_pull_request_reviews:
required_approving_review_count: 1
required_status_checks:
# CIのパスを強制する。ここで負債をチェックするジョブを仕込む
contexts:
- “lint”
- “security-scan”
- “unit-tests”
チームへの提言：検索結果を「アクション」に変えろ
検索して終わりでは意味がない。以下のフローをチームに導入してほしい。
1. 定期的な「負債狩りデー」: 月に一度、特定のキーワードで全社コードを検索し、Issueを立てる。
2. CODEOWNERSの活用: 特定のディレクトリに対する修正が必要になった際、即座に担当者をアサインできる状態を維持する。
3. 検索クエリの共有: チームのSlack/Discordに「このクエリで見つかったものは技術負債リストに入れる」というスニペットを蓄積する。
—
最後に：ツールに支配されるな、使いこなせ
GitHub Code Searchは、単なる検索ツールではなく、「システムの現状を可視化するダッシュボード」だ。ここに挙げた手法を使い、コードベースからノイズを排除し、本来書くべき「未来のためのコード」に集中する時間を捻出してほしい。
優れたエンジニアは、ツールを「便利だ」と褒める。
しかし、真のテックリードは、ツールを「武器」として改造し、チームの戦い方そのものを変えてしまう。
さあ、今すぐ検索窓を開いて、君たちのプロジェクトの隠れた負債を狩りに行こう。