GitHub コード検索

リポジトリ、Issue、Pull Request を検索する GitHub 検索 API

GitHub を HTTP で検索し、リポジトリ、Issue、Pull Request を 1 つの結果一覧で取得します。各結果に `kind` が付き、GitHub のトークン管理やレート制限への対応は不要です。

エンドポイント
POST https://api.search1api.com/search
GitHub の検索結果に含まれるもの

結果は他のエンジンと同じ JSON 形式で返り、リポジトリとスレッドを区別する追加フィールドが付きます。

1
すべての結果に kind

`kind` は `repo`、`issue`、`pr`、または `discussion` で、URL を読まずに分岐できます。

2
リポジトリのスター数

リポジトリのスニペットは `Rust | 5113 stars | description` の形式です。`stars` と `language` は別フィールドでも返ります。

3
スレッドのコメント数

Issue のスニペットは `TanStack/router · issue · open · 2 comments` で始まります。Pull Request と Discussion も同じパターンです。

主な用途

コーディングエージェント / 障害調査 / 依存関係の検討

コードと、その周りのスレッド。GitHub トークンは不要

`search_service` に `github` を指定すると、リポジトリと一致する Issue・Pull Request が混在して返ります。エンドポイント、認証、共通の結果形式は他のエンジンと同じです。`is:issue` のような GitHub 修飾子で種類を絞れます。

1 ページに複数の kind

hydration エラーのようなクエリは、リポジトリだけでなく一致する Issue と Discussion も返します。結果はクエリ語の一致数、次いでスター数で並ぶため、別の kind も一致しているときに 1 種類だけで埋まりません。

修飾子で種類を絞る

`is:issue` や `stars:>1000` のような GitHub 修飾子を付けると、その種類だけが検索されます。修飾子がなければリポジトリ、Issue、Pull Request が含まれます。

作成日による time_range

`time_range` はリポジトリとスレッドを、その期間に *作成された* ものに限定します。以前は最終 push でリポジトリを絞っていたため、「今週」に何年も前のリポジトリが混ざっていました。

GitHub のレート制限が不要

リクエストは GitHub のトークンではなく Search1API のクレジットで課金されるため、トークンごとの時間制限を回避する必要がありません。Discussion にはサービス側の GitHub トークンが追加で必要で、それが無い場合でもリポジトリ、Issue、Pull Request は返ります。

GitHub 検索 API とは?

GitHub 検索 API は、GitHub のリポジトリ、Issue、Pull Request、Discussion を構造化された結果として返す HTTP インターフェースです。GitHub 自身も検索エンドポイントを公開していますが、パーソナルアクセストークンが必要で、検索には低いレート制限が適用され、モデルに渡す前に縮約が必要な大きなペイロードを返します。Search1API は GitHub を Search endpoint の検索サービスの 1 つとして提供し、各結果に `kind` を付け、リポジトリには言語とスター数、スレッドにはコメント数を、他のエンジンと同じ JSON 形式で返します。コーディングエージェントは 1 回のツール呼び出しでライブラリの特定と、失敗を説明する Issue の特定ができます。

実装の流れ

典型的な流れ

GitHub を HTTP で検索し、リポジトリ、Issue、Pull Request を 1 つの結果一覧で取得します。各結果に `kind` が付き、GitHub のトークン管理やレート制限への対応は不要です。

1

`search_service` に `github` を指定してクエリを送信します。

2

まず `kind` を見ます。`repo` ならスニペットをパイプで分割して言語とスター数を取ります。`issue` や `pr` なら、スニペットにリポジトリ、状態、コメント数が入っています。

3

スレッドだけ欲しいときは `is:issue` を付けます。README や Issue 本文が必要な場合は `crawl_results` を指定します。

1 回のリクエストでコードとその周りのスレッド

1 回の呼び出しで GitHub のリポジトリ、Issue、Pull Request を検索し、各結果に kind を付けて返します。多くの場合、追加リクエストなしでライブラリか対応する Issue を選べます。

bash
curl -X POST https://api.search1api.com/search \
-H "Authorization: Bearer $SEARCH1API_KEY" \
-H "Content-Type: application/json" \
-d '{
"query": "tanstack start hydration",
"search_service": "github",
"max_results": 5
}'

主な用途

コードを直す前にライブラリ、または失敗を説明する Issue を探すコーディングエージェント。

リポジトリだけでなく GitHub のスレッドを返してほしい障害調査。

勢いのあるプロジェクトを追う技術調査。

パッケージ名からソースリポジトリを解決するドキュメントツール。

FAQ

GitHub 公式の検索 API と何が違いますか?

GitHub の検索エンドポイントはパーソナルアクセストークンを必要とし、検索リクエストには特に低いレート制限が適用されます。Search1API は自身のクレジットで課金するため GitHub トークンの発行やローテーションが不要で、縮約が必要な大きな JSON ではなく、`kind` 付きのコンパクトな結果(リポジトリなら言語とスター数、スレッドならコメント数)を返します。

GitHub のトークンは必要ですか?

不要です。認証は Search1API のキーで行います。リクエストは https://api.search1api.com/search への POST で、`search_service` に `github` を指定します。Discussion だけはサービス側の GitHub トークンが必要で、それが無い場合は他の kind だけが返ります。

Issue だけを検索できますか?

できます。`is:issue` や `is:pr` のような GitHub 修飾子を付けると、その種類だけが検索されます。修飾子がなければリポジトリ、Issue、Pull Request が混在します。Discussion はサービス側の GitHub トークンがあるときだけ含まれます。

リポジトリの README は取得できますか?

取得できます。`crawl_results` に取得したい上位件数を指定すると、取得に成功したページに Markdown 形式の本文を含む `content` フィールドが付与されます。取得できなかった結果は `content` なしで返り、課金されません。

GitHub 検索の料金はいくらですか?

検索 1 回あたり 1 クレジット、`crawl_results` で取得に成功したページごとに 1 クレジットが加算されます。チャージの基本レート($1 = 1,000 クレジット)では 1,000 回の検索が $1 です。登録時にクレジットカードなしで 100 クレジットが付与されます。

他の開発者向けソースにも対応していますか?

同じ Search endpoint が論文の `arxiv`、コミュニティ議論の `reddit`、投稿の `x` に対応します。一般 Web エンジンや中国語エンジンと合わせ、1 つの契約で計 19 エンジンを利用できます。

Python、JavaScript、cURL から利用できますか?

利用できます。Search1API は任意の HTTP クライアントから使える REST API で、GitHub は別統合ではなくパラメータの値です。公式の TypeScript / Python SDK、CLI、MCP サーバーのいずれも同じ `search_service` の値を受け付けます。