searching-sourcegraph

Sourcegraph で検索する

作成する前に検索しましょう。既存のパターンを活用することで、トークンを節約し、一貫性を保ち、検証済みの解決策を見つけられます。

ツールの選択ロジック

まずはこちらから：

1. 正確なシンボルやパターンがわかっていますか？ → keyword_search
2. コードではなく、概念がわかっていますか？ → nls_search
3. 仕組みや理由を理解する必要がありますか？ → deepsearch → deepsearch_read
4. シンボルの使用箇所を追跡していますか？ → find_references
5. 実装全体が必要ですか？ → go_to_definition → read_file
6. ユーザーが作業したリポジトリを知る必要がありますか？ → get_contributor_repos

目標	ツール
概念／意味検索	nls_search
正確なコードパターン	keyword_search
使用箇所の追跡	find_references
実装の確認	go_to_definition
詳細検索の開始	deepsearch
詳細検索結果の読み取り	deepsearch_read
ファイルの読み取り	read_file
構造の閲覧	list_files
リポジトリの検索	list_repos
コミットの検索	commit_search
変更の追跡	diff_search
バージョンの比較	compare_revisions
ユーザーが作業したリポジトリの検索	get_contributor_repos

スコープ設定（必ず行う）

repo:^github.com/ORG/REPO$           # Exact repo (preferred)
repo:github.com/ORG/                 # All repos in org
file:.*\.ts$                         # TypeScript only
file:src/api/                        # Specific directory
file:.*\.test\.ts$ -file:__mocks__   # Tests, exclude mocks

まずは絞り込んで検索します。結果が空の場合にのみ範囲を広げます。

フィルターを組み合わせます：repo:^github.com/myorg/backend$ file:src/handlers lang:typescript

コンテキストに応じた動作

ユーザーがファイルパスやエラーメッセージを提示した場合：

• シンボル、関数名、エラーコードを抽出します
• まず、それらの正確な語句を検索します
• エラーが既知のシンボルに関連する場合は、参照を追跡します

ユーザーが「X の仕組みは？」と尋ねた場合：

• deepsearch で検索を開始し、次に deepsearch_read で結果を取得します
• 回答で挙げられた主要なファイルを read_file で読み取ります

ユーザーが、何かに携わった人や、コントリビューターが関与したリポジトリを尋ねた場合：

• 1 つ以上のユーザー名を指定して get_contributor_repos を使い、対象のアクティブなリポジトリを特定します
• 次に、それらのリポジトリに範囲を絞って検索します

ユーザーが新機能を実装している場合：

• まず、類似する既存の実装を検索します
• 使用例を確認するためにテストを読みます
• 新しいものを作成する前に、共有ユーティリティがないか確認します

エラー、ビルドの失敗、またはランタイム例外を調査する場合：

• スタックトレースやビルド出力から、正確なシンボル、エラーコード、ログ行を抽出します
• エラー箇所を検索し、次に find_references で呼び出しチェーン全体を追跡します
• 早い段階で diff_search と commit_search を使って最近の変更を確認します。リグレッションはよく発生します
• 修正を提案する前に、影響を受けるすべてのコードパスとサービスを特定します

バグを修正する場合：

• エラーメッセージまたはスタックトレースから正確なシンボルを抽出します
• エラー箇所を検索し、次に find_references で呼び出しチェーン全体を追跡します
• 早い段階で diff_search と commit_search を使って最近の変更を確認します。リグレッションはよく発生します
• 修正を作成する前に、影響を受けるすべてのコードパスを特定します
• 期待される動作を把握するため、既存のテストを読みます

ワークフロー

手順ごとの詳細なワークフローについては、以下を参照してください：

• workflows/implementing-feature.md — 新機能を開発する場合
• workflows/understanding-code.md — 不慣れなシステムを調べる場合
• workflows/debugging-issue.md — エラー、ビルドの失敗、スタックトレース、サポート案件、またはランタイム例外を調査する場合
• workflows/fixing-bug.md — Sourcegraph で広範囲に検索してバグを修正する場合
• workflows/code-review.md — プルリクエストまたは変更セットをレビューする場合

効率化のルール

ツール呼び出しを最小限にする：

• 検索は論理的につなげます：検索 → 読み取り → 参照箇所 → 定義
• 同じパターンを再検索しないでください。以前の呼び出しの結果を使います
• 正確な用語が分かっている場合は、nls_search より keyword_search を優先します（より高速で正確です）

理解をまとめて進める：

• 1つのファイルを読んで質問するのではなく、関連するファイルを2〜3個読んでから内容をまとめます
• 「Xはどのように動作しますか」のような質問には、複数のキーワード検索ではなく、deepsearch + deepsearch_read を使います

よくあるトークンの無駄遣いを避ける：

• 対象のリポジトリが分かっている場合は、すべてのリポジトリを検索しないでください
• 単純な「すべて検索」クエリに deepsearch を使わないでください。keyword_search の方が高速です
• この会話ですでに確認したファイルを再読しないでください

クエリパターン

意図	クエリ
React フック	file:.*\.tsx$ use[A-Z].*= \(
API ルート	file:src/api app\.(get|post|put|delete)
エラー処理	catch.*Error|\.catch\(
型定義	file:types/ export (interface|type)
テストのセットアップ	file:.*\.test\. beforeEach|beforeAll
設定ファイル	file:(webpack|vite|rollup)\.config
CI/CD	file:\.github/workflows deploy

その他のパターンについては、query-patterns.md を参照してください。

出力形式

検索結果：

• 生のツール出力ではなく、簡潔な要約として提示します
• 最も関連性の高いファイルと行を明示します
• 質問に直接答える場合に限り、コードスニペットを含めます

コードの説明：

• 1文の要約から始めます
• コードベース独自の用語を使います
• 具体的なファイルと関数を示します

推奨事項：

• 実行可能な内容は番号付きの手順として提示します
• コードベース内で見つかった具体的なパターンにリンクします
• 再利用すべき既存のユーティリティがあれば記載します

よくある間違い

間違い	修正方法
すべてのリポジトリを検索する	repo:^github.com/org/repo$ を追加します
結果が多すぎる	file: パターンまたはキーワードを追加します
関連するコードを見落とす	意味的に一致する nls_search を試します
コンテキストを把握できていない	deepsearch_read を使います
パターンを推測する	read_file で実装を読みます

原則

• 範囲を絞って始め、必要に応じて広げます
• ツールを順につなげます：検索 → 読み取り → 参照箇所の検索 → 定義
• 使用例を確認するためにテストをチェックします
• 生成する前に読みます