遺産を葬れ：GitHub Code Searchで技術的負債を「秒速」で殲滅する極限術
多くのエンジニアが「GitHubの検索機能」を、単なるコードの断片探しに使っている。それは、フェラーリを買い物カゴを載せる台車にするのと同じだ。
真のDevOpsエンジニアにとって、GitHub Code Searchは「数百万行のコードベースに対するリアルタイム・フォレンジック・スキャナ」である。従来の検索（Elasticsearchベースの旧来型）が「単なるテキストマッチング」だったのに対し、現在のBlackbirdエンジン（GitHubの次世代検索基盤）は、構文木レベルのインデクシングを行っている。
本稿では、このツールを骨の髄まで掌握し、技術的負債を根絶するための極限のテクニックを伝授する。
—
1. 概念の転換：検索ではなく「クエリによる静的解析」
従来のUI検索は、インデックスの遅延や、意図しないファイル（`node_modules`や`vendor`）のノイズに悩まされてきた。新世代のCode Searchは、`path:`, `language:`, `org:` などの修飾子を組み合わせることで、ビルドを走らせずに「静的解析」に近い結果を得られる。
必須の検索修飾子ハック
- `path:/deprecated/` : 特定ディレクトリのみに絞り、ノイズを排除。
- `-path:/tests/` : テストコードを除外し、プロダクションコードの負債のみに焦点を当てる。
- `language:typescript` : 言語固有の構文解析に基づいた検索を行う。
—
2. 負債特定の実践：非推奨APIの「全社横断的」殲滅
全社規模で「古いライブラリの呼び出し」や「安全でない暗号化アルゴリズム」を一掃する場合、UIでポチポチ探すのは愚の骨頂だ。
例：非推奨の `Buffer()` コンストラクタを全リポジトリから炙り出す
多くのNode.jsプロジェクトに残る負債だが、これを正規表現で叩く。
/new Buffer\(/ language:javascript -path:test/
さらに、これに「最近更新されていないリポジトリ」という条件を加えれば、手付かずの負債が浮き彫りになる。
/new Buffer\(/ archived:false pushed:<2023-01-01 これをCLIと組み合わせ、自動的にIssueを作成するフローへ繋ぐのが、我々DevOpsエンジニアの流儀だ。 ---
3. GitHub CLI + `gh api` による「負債スキャン・オートメーション」
UIで検索するのは一度きり。本気で負債を撲滅するなら、GitHub APIを直接叩き、検索結果をJSONで回収し、自動チケット化するパイプラインを組め。
以下のスクリプトは、検索結果をJSONで取得し、特定のAPIを叩くためのテンプレートだ。
!/bin/bash
検索クエリをGraphQLで実行し、負債の発生箇所をリストアップするハック
検索APIではなく、Search.codeのエンドポイントを叩くのがコツ
QUERY=”new Buffer\( path:src/.\.js”
gh api graphql -f query=’
query($q: String!) {
search(query: $q, type: CODE, first: 100) {
nodes {
… on Code {
path
repository { nameWithOwner }
url
}
}
}
}’ -f q=”$QUERY” > debt_report.json
取得したJSONをパースし、JiraやGitHub Issuesへ流し込む（jqで整形）
cat debt_report.json | jq ‘.data.search.nodes[] | “\(.repository.nameWithOwner): \(.path)”‘
—
4. パフォーマンスを極める：インデックスの「裏側」を知る
GitHub Code Searchがなぜ爆速か。それは、「トランスフォーマー・ベースの埋め込み」と「カスタム構築の分散インデックス」を組み合わせているからだ。
- メモリとレイテンシの最適化: `is:fork` や `is:archived` を明示的に指定することで、検索対象のインデックス・パーティションを絞り込むことができる。膨大な組織リポジトリを持つ企業こそ、このフィルタリングを徹底すべきだ。
- クエリの正規化: 正規表現（Regex）は非常に強力だが、複雑すぎると検索エンジン側でタイムアウトや制限がかかる。可能な限り「具体的な文字列」で絞り込み、その後に正規表現を適用する「段階的アプローチ」をとれ。
—
5. 結論：技術的負債は「管理」ではなく「排除」せよ
技術的負債を「管理」しようとするマネージャーは多いが、それは間違いだ。負債は金利を生む。負債は、「自動化された検索クエリ」によって常に監視され、CIパイプラインの中で「警告」ではなく「ビルド失敗（Fail）」として扱うべきものだ。
1. Code Searchで負債のパターンを特定
2. GitHub Actionsの定期実行ジョブで検索クエリを走らせる
3. 負債が検知されたら、該当リポジトリのオーナーに自動でPRを送る
これが、レガシーを食い潰し、次世代のアーキテクチャへと進化し続けるための唯一の道だ。
ツールに遊ばれるな。ツールを支配し、コードベースという大海原を、あなたの意のままに操れ。