github-repo-intelligence-mcp

保守性の評価であり、別のダッシュボードではありません。

GitHub Repo Health Check は、依存関係の一覧からはわからない、ただ一つの問いに答える MCP サーバーです。このリポジトリはまだメンテナンスされていますか。それとも、砂上に建物を築いているのでしょうか。 最終コミット日はあてになりません。スター数もあてになりません。一つのシグナルだけでは評価できません。そこで、4 つの側面（アクティビティ、イシュー、PR、コントリビューター）を総合し、根拠となった透明性が高く検証可能な閾値とともに、「活発にメンテナンスされている」「勢いが鈍化している」「リスクあり」「放棄された可能性が高い」の 4 段階で評価します。任意の owner/name（または GitHub URL）を指定すれば、エージェントは判断に使える評価と、その理由を正確に確認できる生の数値を取得できます。同じリポジトリの状態と設定なら、毎回同じ評価が得られます。

Apify プラットフォーム上でスタンバイアクターとして実行されます。常時起動し、/mcp パスでストリーム可能な HTTP トランスポート経由で接続でき、API アクセス、スケジュール設定、モニタリングも含まれています。

実際の動作を見る

2 つのリポジトリに対する、まったく異なる 2 つの評価と、その背後にあるメトリクスの詳細を、すべて MCP 経由で確認できます。

対象ユーザー

• エージェント開発者 — オープンソースのライブラリやツールを採用、推奨、監視するかどうかをエージェントに判断させたい方
• 依存関係のデューデリジェンス — パッケージに依存する前に、上流プロジェクトが今も活動しているかを確認したい方
• OSS ベンダーの評価 — プロジェクトを基盤に開発する前に、その健全性を確認したい方
• 大規模なリポジトリのトリアージ — 人が確認する前に、候補の一覧を健全性で順位付けしたい方
• 自動モニタリング — 定期的なチェックをスケジュールし、依存関係の勢いが鈍化し始めたときに通知を受けたい方

「このリポジトリは放棄されているのか」と疑問に思ったことや、GitHub リポジトリの健全性を手作業で確認したことがあるなら、このサーバーを使って、規模を問わずプログラムからチェックできます。

GitHub Repo Health Check を使う理由

多くの GitHub ツールは、エージェントに生の API アクセスを渡し、判断をモデルに任せます。その結果、呼び出すたびに一貫性のない、独自実装のヒューリスティックが使われます。このサーバーなら、評価の総合を代わりに行います。

差別化要因は生のアクセスではなく判断です。すべての評価には、その根拠となった固定済みの閾値と生のメトリクスが付属するため、エージェントもあなたも判断過程を検証できます。同じリポジトリの状態と同じ設定なら、常に同じ評価が得られます。

リポジトリごとに GitHub から取得するデータは 1 回だけで、5 つのツールすべてでキャッシュを共有します。概要の評価から特定の側面の詳細に進んでも、上流への追加呼び出しは発生しません。

GitHub Repo Health Check の使い方

1. アクターをデプロイする — Apify のスタンバイモードで実行します。入力を指定せずに起動できます。
2. MCP クライアントを接続する — ストリーム可能な HTTP トランスポートを使って、スタンバイエンドポイント（https://<your-standby-url>/mcp）に接続します。
3. get_repo_health を呼び出す — repo 引数（"owner/name" または任意の https://github.com/owner/name URL）を渡して、概要の評価を取得します。
4. GitHub トークンを追加する — 実質的に必須です。アクターの主なデータソースである GitHub の GraphQL API は、認証されていないリクエストを拒否します。また、Apify が共有する送信元 IP では、GitHub の匿名利用枠がほぼ即座に上限に達します。トークンがない場合、アクターは評価ではなくレート制限エラーを返します。設定については入力を参照してください。
5. 各側面の詳細を確認する — 概要だけでは不十分な場合は、get_activity_metrics、get_issue_health、get_pr_health、または get_contributor_insights を呼び出します。5 つのツールすべてが同じキャッシュ済みペイロードを読み取ります。

5 つのツール

すべてのツールは repo 引数を 1 つ受け取ります。値は "owner/name" または任意の https://github.com/owner/name[/...] URL です（大文字と小文字は区別されません）。

get_repo_health — 概要の評価

全体の評価、側面ごとの内訳、および最も状態が悪い側面を説明する根拠の文字列を返します。

{
  "repo": "honojs/hono",
  "overallVerdict": "Actively maintained",
  "dimensions": {
    "activity":     { "verdict": "Healthy", "lastCommitDaysAgo": 1, "commits90d": 412 },
    "issues":       { "verdict": "Healthy", "medianFirstResponseDays": 2.4, "staleOpenRatio": 0.12 },
    "pullRequests": { "verdict": "Healthy", "mergeRate": 0.88, "oldestOpenPrDaysAgo": 14 },
    "contributors": { "verdict": "Healthy", "totalContributors": 312, "busFactorFlag": false }
  },
  "rationale": "Overall: activity is Healthy; weakest dimension is issues (Healthy).",
  "stars": 21000,
  "forks": 640,
  "fetchedAt": "2026-06-01T00:00:00.000Z",
  "authenticated": true
}

get_activity_metrics — コミットの頻度と勢い

直近の各期間におけるコミット数、リリース頻度、勢いの傾向です。

{
  "repo": "honojs/hono",
  "verdict": "Healthy",
  "lastCommitDaysAgo": 1,
  "commits30d": 140,
  "commits90d": 412,
  "commits365d": 1680,
  "releaseCount365d": 48,
  "lastReleaseDaysAgo": 3,
  "momentumTrend": "steady",
  "fetchedAt": "2026-06-01T00:00:00.000Z"
}

momentumTrend は、30 日間のコミット率と 90 日間のコミット率から算出される accelerating／steady／declining のいずれかです。GitHub Releases を作成せず、タグを付けているリポジトリでは、releaseCount365d: 0 および lastReleaseDaysAgo: null となりますが、これだけで評価が下がることはありません。

get_issue_health — 対応の迅速さと未解決課題の管理状況

メンテナーがどれくらい迅速に issue に対応しているか、また未解決の issue のうちどれだけが長期間放置されているかを示します。

{
  "repo": "honojs/hono",
  "verdict": "Healthy",
  "openIssues": 32,
  "closedIssues": 1840,
  "openClosedRatio": 0.017,
  "medianFirstResponseDays": 2.4,
  "medianTimeToCloseDays": 5.1,
  "staleOpenIssues": 4,
  "staleOpenRatio": 0.12,
  "fetchedAt": "2026-06-01T00:00:00.000Z"
}

issue は、90 日を超えて更新がない場合に長期未対応とみなされます。分析期間内に該当するイベントがない場合、中央値は null になります。データがないことはゼロと同じではありません。

get_pr_health — PR の処理状況と滞留期間

プロジェクトがコントリビューションをどれだけ効果的にマージまたはクローズしているか、および最も古い未解決 PR がどれくらいの期間残っているかを示します。

{
  "repo": "honojs/hono",
  "verdict": "Healthy",
  "openPrs": 6,
  "mergedPrs": 220,
  "closedUnmergedPrs": 30,
  "mergeRate": 0.88,
  "medianTimeToMergeDays": 1.2,
  "oldestOpenPrDaysAgo": 14,
  "fetchedAt": "2026-06-01T00:00:00.000Z"
}

mergeRate の分母には、まだオープンの PR は含まれません。分析期間内に判断が下された PR がない場合、値は null になります。

get_contributor_insights — コントリビューションの集中度とバス係数のリスク

プロジェクトに何人のコントリビューターがいるか、またコミット活動が危険なほど集中していないかを示します。

{
  "repo": "honojs/hono",
  "verdict": "Healthy",
  "totalContributors": 312,
  "topContributorShare": 0.28,
  "topTwoContributorShare": 0.41,
  "busFactorFlag": false,
  "fetchedAt": "2026-06-01T00:00:00.000Z"
}

busFactorFlag は、最多コミットのコントリビューターがコミットの 50% 超を占める場合、または上位 2 人が合わせて 80% 超を占める場合に true になります。totalContributors は、リポジトリの全期間のコントリビューター数です（GitHub の安定した /contributors リストエンドポイントから取得）。過去 90 日間に活動した人数ではありません。

評価のしきい値

評価は明示され、固定されたしきい値に基づきます。同じリポジトリの状態と同じ設定であれば、常に同じ評価になります。

項目	Healthy	Moderate	At-Risk	備考
活動状況	最終コミットから 30 日以内	30～180 日	180～365 日	365 日超の場合は Likely abandoned
issue	初回応答までの中央値が 7 日以内 かつ staleOpenRatio ≤ 0.40	30 日以内 かつ ≤ 0.60	それ以外	中央値が null の場合は staleOpenRatio のみで判定
プルリクエスト	mergeRate ≥ 0.60 かつ 最古のオープン PR が 30 日以内	mergeRate ≥ 0.30 または 最古のオープン PR が 90 日以内	それ以外	mergeRate が null の場合は最古のオープン PR のみで判定
コントリビューター	totalContributors ≥ 3 かつ バス係数に該当しない	コントリビューターが 1～2 人、または 3 人以上でバス係数に該当	コントリビューターが 0 人	活動中のメンテナーが 1 人の場合、評価は最大でも Moderate

総合評価は活動状況を重視し、上から順に判定します（最初に一致したものを適用）。

1. 放棄された可能性が高い — 活動状況が Likely abandoned（365 日を超えてコミットがない）。
2. リスクあり — 活動状況が At-Risk、または {issue、PR、コントリビューター} のうち 2 項目以上が At-Risk。
3. 活発にメンテナンスされている — 活動状況が Healthy で、At-Risk の項目がない。
4. 勢いが衰えている — 上記以外（例：活動状況が Moderate、または活動状況は Healthy だが 1 項目が At-Risk）。

入力

サーバーの起動に入力は不要です（Standby の制約上、起動時にコンテナがクラッシュループしないよう、スキーマ内のすべてのフィールドが任意です）。実際には、レート制限エラーではなく判定結果を Actor が返すには、GitHub トークンを指定する必要があります。

フィールド	型	デフォルト	説明
githubToken	string (secret)	—	実質的に必須です。 GitHub の GraphQL API（この Actor の主なデータソース）は、認証されていないリクエストを拒否します。また、Apify の共有 IP では、匿名 REST の割り当て（IP あたり約 60 リクエスト／時）は通常、他のトラフィックによってすでに使い切られています。トークンを使うと、5,000 リクエスト／時が可能になり、プライベートリポジトリの分析も有効になります。
cacheTtlMinutes	integer	20	リポジトリから取得したペイロードを、再取得するまで再利用する時間です。値を小さくするとデータが新しくなり、大きくすると GitHub API の呼び出しが減ります。
analysisWindowDays	integer	90	issue と PR のアクティビティを測定する期間（過去 30～365 日）です。

GitHub トークンの設定。 パブリックリポジトリには、スコープを設定していないクラシックトークンで十分です。特定のリポジトリを対象にしたファイン・グレインド・トークンは、プライベートリポジトリの分析に使用できます。Standby デプロイでは、トークンを入力フィールドに貼り付けるのではなく、Actor に GITHUB_TOKEN 環境変数として設定する方法（シークレットとして保存されます）を推奨します。再起動後も設定が維持されます。どちらの方法も使用でき、どちらの場合もシークレットとして保存され、ログに表示されることはありません。

出力

各ツールは、構造化された単一の JSON オブジェクトを返します（各ツールのセクションに掲載）。レスポンスは決定的です。同じリポジトリの状態と同じ設定であれば、常に同じ判定結果になります。各レスポンスには、基になる GitHub ペイロードを取得した時刻を示す fetchedAt タイムスタンプが含まれます。キャッシュから読み込んだ場合、該当する TTL の期間中は、最初に取得したときと同じタイムスタンプが返されます。

データフィールドのリファレンス

フィールド	意味
overallVerdict	概要の判定：積極的にメンテナンス中／勢いが低下／リスクあり／放棄された可能性が高い
lastCommitDaysAgo	最も新しいコミットからの経過日数。コミットが見つからない場合は null
commits30d / commits90d / commits365d	過去 30 日、90 日、365 日間のコミット数
momentumTrend	コミット率が上昇中、安定、低下中のいずれか（30 日と 90 日の率を比較）
medianFirstResponseDays	新しい issue にメンテナーが最初に応答するまでの時間（日数）の中央値
staleOpenRatio	90 日以上アクティビティのないオープン issue の割合
mergeRate	マージ済み PR ÷（マージ済み PR + マージされずにクローズした PR）。オープン中の PR は除外されます
oldestOpenPrDaysAgo	現在もオープン中の PR のうち、最も古いものの経過日数
totalContributors	これまでの全コントリビューター数（過去 90 日間のアクティブユーザー数ではありません。FAQ を参照）
busFactorFlag	コミットのアクティビティが 1～2 人に危険なほど集中している場合は true

料金

この Actor は Standby モードで実行され、ウォーム状態でリクエストを処理している間に使用したコンピューティングに対して課金されます。ヘルス情報の読み取りは軽量です。各リポジトリの GitHub データは一度取得され、キャッシュ（デフォルトは 20 分）され、5 つすべてのツールで共有されます。同じリポジトリについて複数の観点を調べても、上流からの取得は 1 回で済みます。

実際の利用には GitHub トークンが必要ですが（入力を参照）、Apify の追加料金はかかりません。

ヒント

• まず get_repo_health を使って概要の判定を確認し、詳細が必要な場合にのみ各観点のツールを呼び出してください。すべてのツールで同じキャッシュ済みペイロードが共有されます。
• 多数のリポジトリを一括でトリアージする場合は、GitHub API の呼び出しを最小限に抑えるため、cacheTtlMinutes の値を大きくしてください。最新の情報が必要な場合は小さくしてください。
• Actor の入力フィールドではなく、環境変数として GITHUB_TOKEN を設定してください。入力を再指定しなくても、Standby の再起動後に設定が維持されます。
• issue と PR のシグナルをどの程度直近のものにするかに合わせて、analysisWindowDays（30～365）を調整してください。期間を短くすると最近の傾向が表れ、長くするとより安定した基準期間で平均化されます。

仕組み

1. MCP クライアントが repo 引数を指定してツール呼び出し（例：get_repo_health）を送信します。
2. サーバーはメモリ内の LRU キャッシュを確認します。キャッシュにない場合は、GitHub の API に GraphQL クエリを 1 回送信し（コントリビューターデータ取得のための REST 呼び出しも行います）、生のペイロードをキャッシュします。
3. 純粋なメトリクス計算関数がペイロードから件数、中央値、比率を算出します。追加のネットワーク呼び出しはありません。
4. 判定関数が各メトリクスを config.ts に固定されたしきい値と比較し、各ディメンションの判定を返します。
5. 全体の判定は、上記のアクティビティ優先ルールに基づいて 4 つのディメンションの判定から構成されます。
6. 判定、ディメンションごとの内訳、生のメトリクス、fetchedAt を含む完全な結果を MCP クライアントに返します。

5 つのツールすべてで、手順 2 のキャッシュ済みペイロードを共有します。判定ロジックは決定論的で、時刻を注入できるため、ネットワークなしでテストできます。

相性のよいツール

エージェントに特化した Apify Actor の小規模なラインナップの一部です。

• SERP Topic Gap Monitor — 検索結果の網羅範囲におけるトピックのギャップを見つけ、スコア付きのギャップレポートを作成します。
• Changelog Triage Agent — サービス全体の製品変更履歴を監視し、新しいエントリーをそれぞれ BREAKING／WARNING／INFO に分類して、重複を除いたトリアージレポートを配信します。これにより、チームは非推奨機能が問題を引き起こす前に把握できます。
• Docs MCP Server — AI アシスタントがフレームワークのドキュメント（Next.js、React、Tailwind、TypeScript、Prisma）を検索できる MCP サーバーです。

FAQ とサポート

プライベートリポジトリでも使えますか？ はい。リポジトリへの読み取りアクセス権を持つ githubToken を指定してください。

判定は主観的ですか？ また、設定できますか？ いいえ。すべての判定は、上記に記載された固定のしきい値に基づいています。同じリポジトリの状態であれば、常に同じ判定になります。すべての呼び出しを監査できるよう、生のメトリクスも判定とともに返されます。

totalContributors が過去 90 日間のアクティブなコントリビューター数ではないのはなぜですか？ GitHub の期間別コントリビューター統計エンドポイント（/stats/contributors）は、キャッシュがない状態では信頼性が低く、202 を返すうえ、リクエストサイクル内にキャッシュが更新されることはほとんどありません。そのため、コントリビューターは安定している全期間の /contributors リストから取得します。このフィールドが示すのはリポジトリの存続期間全体にわたるコントリビューターの広がりであり、最近のアクティビティではありません。

rationale フィールドには何が含まれますか？ アクティビティの判定と、アクティビティ以外で最も低いディメンションが記載されます。例：「全体：アクティビティは Healthy です。最も低いディメンションは issues（Moderate）です。」エージェントのログや人間による監査記録向けに設計されており、ユーザー向けの文面ではありません。

Actor がレート制限エラーを返しました。どうすればよいですか？ GitHub トークンを追加してください。Input を参照してください。スコープのないクラシックトークンは無料で、github.com/settings/tokens で 1 分もかからずに作成できます。

バグを見つけた場合や、機能を追加してほしい場合はどうすればよいですか？ Actor の Issues タブから Issue を作成してください。ご要望に応じてカスタム版も提供できます。

ライセンス

Copyright © 2026 Joe Slade.

GNU Affero General Public License v3.0（AGPL-3.0）の下でライセンスされています。このソフトウェアは自由に使用、調査、変更、セルフホストできます。変更したバージョンをネットワークサービスとして運用する場合、AGPL により、同じライセンスの下で変更後のソースコードをユーザーに提供する必要があります。AGPL のネットワークコピーレフトの適用を受けない商用ライセンスについては、作者にお問い合わせください。