Tech Ecosystem Analysis

Tech Ecosystem Analysis MCP

ApifyForgeで表示 | Apify Storeで使用

---

クイックスタート

MCP クライアント（Claude Desktop、Cursor、Windsurf）に追加します。

{
  "mcpServers": {
    "tech-ecosystem-analysis-mcp": {
      "url": "https://ryanclinton--tech-ecosystem-analysis-mcp.apify.actor/mcp"
    }
  }
}

---

AI エージェントや LLM ワークフロー向けのテクノロジーエコシステム分析です。テクノロジー間の関係をマッピングし、導入曲線を追跡し、CVE 脆弱性を検出して、6 つのライブデータソースからテクノロジースタックのリスクを評価します。Model Context Protocol 経由で一度接続すれば、AI アシスタントがあらゆるフレームワーク、言語、ツールを構造化されたデータに基づくインテリジェンスで評価できます。

この MCP サーバーは Apify プラットフォーム上のスタンバイモードで動作し、GitHub、NVD CVE データベース、StackExchange、Hacker News、Wikipedia、ライブ Tech Stack Detector を並行して連携させる 8 つのツールを公開します。各ツールは、テクノロジーごとのスコア、トレンド分類、実行可能な推奨事項を含む構造化 JSON を返します。あらゆるエージェントワークフローですぐに利用できます。

⬇️ アクセスできるデータ

データ項目	ソース	例
📦 リポジトリ数、スター数、フォーク数、コントリビューターの活動	GitHub Search	React：上位リポジトリ全体でスター数 45,231
🔐 CVE ID、CVSS スコア、重大度、影響を受けるバージョン	NVD CVE Database	CVE-2024-21490、CVSS 9.8、重大
💬 Q&A の件数、回答率、タグの人気度、コミュニティスコア	StackExchange	TypeScript：回答率 94％、質問数 12,400
📰 ディスカッションのエンゲージメント、賛成票の傾向、トレンドのセンチメント	Hacker News	Rust：平均 312 ポイント、投稿あたり 187 コメント
📖 テクノロジーの歴史、エコシステムの背景、成熟度の指標	Wikipedia	Go：2009 年に初登場、15 年前
🌐 ライブ URL から検出したフレームワーク、CMS、CDN、分析ツール	Tech Stack Detector	acmecorp.com：Next.js、Vercel、Cloudflare
📈 導入フェーズの分類（新興／成長中／成熟／衰退）	複合スコアリング	SvelteKit：成長中、勢い 74/100
⚠️ 加重エクスポージャースコア（重大な CVE × 3、高リスクの CVE × 2）	複合スコアリング	OpenSSL：エクスポージャースコア 60/100

MCP ツール

ツール	価格	返される内容
map_tech_ecosystem	$0.045	ノード、エッジ、グラフ密度、上位テクノロジーを含む次数中心性ネットワークグラフ
assess_tech_adoption	$0.045	GitHub のスター総数、SO の質問数、回答率、成長率、トレンドの方向
detect_tech_vulnerabilities	$0.045	CVE の一覧、CVSS スコア、重大度、テクノロジーごとの加重エクスポージャースコア
analyze_developer_sentiment	$0.045	テクノロジーごとの HN エンゲージメント（ポイント＋コメント）と SO 品質（回答率、スコア）
score_tech_stack_risk	$0.045	加重リスクスコア：CVE エクスポージャー（40％）＋コミュニティの逆数（35％）＋成熟度の逆数（25％）
track_framework_trends	$0.045	S 字カーブのフェーズ（新興／成長中／成熟／衰退）、勢いスコア、フォーク／スターの増加速度
assess_tech_maturity	$0.045	6 要素の成熟度モデル：経過年数、コミュニティ規模、ドキュメント品質、エンタープライズでの導入状況、エコシステムの広さ、安定性
generate_tech_report	$0.045	7 つすべての分析を要約、重大な所見、推奨事項とともにまとめた完全なレポート

Tech Ecosystem Analysis MCP を使う理由

エンジニアリングチーム、セキュリティアナリスト、CTO は、不完全な情報をもとに複数年にわたるテクノロジーへの投資判断を行います。GitHub、StackOverflow、CVE データベース、Hacker News を横断する手作業での調査には、フレームワークごとに何時間もかかり、すぐに情報が古くなります。コンサルティングアナリストにレポートを依頼すると、すでに数週間前の情報に基づくものでも、数千ドルの費用がかかります。

この MCP は、調査パイプライン全体を自動化します。AI エージェントは単一のツール呼び出しで、最新の採用状況データ、CVE の影響、開発者の評判、成熟度の分類を、すべて構造化されたレスポンスとして取得できます。データはキャッシュされたスナップショットではなく、クエリの実行時にソースデータベースから取得されます。

Apify 上で実行する場合のプラットフォームの利点：

• スケジュール設定 — エコシステムのチェックを毎週実行し、テクノロジースタックのリスクプロファイルが時間とともにどう変化するかを追跡できます
• API アクセス — CI/CD パイプライン、Slack ボット、または任意の HTTP クライアントから評価を実行できます
• 並列実行 — ツールの呼び出しごとに最大 6 件のアクター呼び出しを同時に実行し、レイテンシを削減します
• 支出上限 — 実行ごとの予算上限を設定できます。上限に達すると、サーバーは適切なエラーを返します
• 連携 — 結果を Zapier、Make、Webhook に接続したり、Notion や Confluence に直接送信したりできます

データソース

GitHub Search

スター数、フォーク数、主要言語、作成日、最終更新日、リポジトリのトピックなどのリポジトリメタデータを照会します。アクターはクエリごとに最大 30 件の結果を収集し、language、name、description フィールドとの照合によって、テクノロジーごとに結果を絞り込みます。スター数の合計は、採用スコア（50％の重み）とコミュニティサポートスコアの算出に使用されます。

NVD CVE Database

National Vulnerability Database から、最新の脆弱性レコードを取得します。各 CVE には、ID、CVSS 基本スコア、深刻度（LOW/MEDIUM/HIGH/CRITICAL）、影響を受ける製品の一覧、説明、公開日が含まれます。脆弱性の影響度を算出する式では、critical CVE を 3 倍、high CVE を 2 倍、それ以外を 1 倍の重みで評価し、上限を 100 とします。リスクレベルのしきい値：CVSS >= 9.0、または critical CVE が 1 件でも存在する場合は CRITICAL、CVSS >= 7.0 の場合は HIGH、CVSS >= 4.0 の場合は MEDIUM です。

StackExchange

質問のタイトル、タグ、コミュニティスコア、回答済み／未回答の状態、作成日を含む Q&A スレッドを取得します。回答率は、採用スコア（20％の重み）とセンチメントスコア（50％の重み）の両方に加味されます。30 日間の質問期間により、現在の勢いと過去の活動を比較できます。

Hacker News

各テクノロジーに一致するディスカッションスレッドを取得します。エンゲージメントの指標である賛成票のポイント数とコメント数は、センチメントの算出式に反映されます。HN でのエンゲージメントはセンチメントスコアの 50％を占めます（ポイント数：40％、コメント数：10％）。テクノロジーごとに、ポイント数上位 5 件の投稿が返されます。

Wikipedia

記事のテキストを抽出し、リリース年に関するパターン（released in YYYY、first appeared YYYY、created YYYY）を解析します。この推定経過年数は、成熟度モデル（複合成熟度スコアの 20％）の算出に使用され、ネットワークグラフのエコシステムの背景情報にもなります。

Tech Stack Detector

ryanclinton/website-tech-stack-detector アクターを使って、稼働中のウェブサイトをスキャンします。検出されたテクノロジーの名前、カテゴリー、信頼度スコア、検出されたバージョンを返します。URL が指定されている場合、map_tech_ecosystem、detect_tech_vulnerabilities、generate_tech_report で使用されます。検出されたテクノロジーは、CVE スキャンに自動的に追加されます。

スコアリングアルゴリズムの仕組み

採用スコア（0–100）

GitHub スターの加点（重み 50％）：min(totalStars / 50,000, 1) × 50。StackOverflow の加点（重み 50％）：質問数 min(count / 100, 1) × 30 と回答率 × 20 の合計です。成長率は、過去 30 日間に作成された SO の質問数の割合として測定します。30％を超える場合は rising、5％を下回る場合は declining に分類されます。

脆弱性の露出スコア（0–100）

重み付けした深刻度の合計：(criticalCVEs × 3 + highCVEs × 2 + otherCVEs × 1) × 10。上限は100です。リスクレベルの分類：平均CVSSが9以上、または重大なCVEが1件でも存在する場合はCRITICAL、平均CVSSが7以上の場合はHIGH、平均CVSSが4以上の場合はMEDIUM、CVEは存在するものの平均CVSSが4未満の場合はLOWです。

開発者センチメントスコア（0–100）

HNコンポーネント（50%）：min(avgPoints / 100, 1) × 40 + min(avgComments / 50, 1) × 10。SOコンポーネント（50%）：min(avgScore / 10, 1) × 30 + (1 - unansweredRatio) × 20。総合分類：60以上はポジティブ、30未満はネガティブ、その間はニュートラルです。

技術スタックのリスクスコア（0–100）

3要素の加重合計：CVE露出スコア × 0.40 +（100 − コミュニティサポートスコア）× 0.35 +（100 − 成熟度スコア）× 0.25。コミュニティサポート：GitHubスター数（40%）、SOのカバー率（30%）、過去90日以内に更新されたリポジトリ（30%）。リスクのしきい値：75以上はcritical、50以上はhigh、25以上はmedium、25未満はlowです。

成熟度スコア（0–100）とSカーブ分類

6つの指標：技術の経過年数 min(ageYears / 15, 1) × 20 + コミュニティの規模 min(totalStars / 100,000, 1) × 20 + ドキュメントの品質 × 0.20 + エンタープライズでの採用（スター数が1Kを超えるリポジトリ）× 0.15 + エコシステムの広がり（一意なトピック）× 0.15 + 安定性指数 × 0.10。分類：スコアが70以上かつ経過年数が8年以上の場合は成熟、スコアが45以上、または経過年数が3年以上かつコミュニティ規模が10Kを超える場合は成長、スコアが25未満かつ経過年数が10年を超え、最近の更新が2件未満の場合は衰退、それ以外は新興です。

エコシステムネットワーク（次数中心性）

ノードタイプが technology、repo、discussion、vulnerability、article、website の有向グラフを構築します。エッジタイプ：implements（repo → technology、正規化したスター数で重み付け）、describes（article → technology、重みは0.5）、uses（website → technology、検出信頼度で重み付け）。次数中心性 = ノードの次数 / (N − 1)。グラフ密度 = 2E / (N × (N − 1))。

技術エコシステム分析のユースケース

エンジニアリングチームによる技術選定

新しいフレームワークを評価するCTOやエンジニアリングリードには、ブログ記事だけでは不十分です。候補となるスタックを score_tech_stack_risk に入力し、エンジニアリングリソースを投入する前に、CVEを加味しコミュニティの状況を反映したリスクスコアを取得します。1回のツール呼び出しでReact、Vue、Svelteを比較できます。

セキュリティチームによるCVEのマッピング

四半期ごとの脆弱性レビューを実施するセキュリティエンジニアは、本番環境で使用している技術の一覧（または自動検出用のWebアプリケーションURL）を detect_tech_vulnerabilities に渡せます。このツールは、CVSSスコアと露出度の重み付けを含む、優先順位付けされたCVEの一覧を返します。修復の優先順位付けワークフローにすぐ利用できます。

VCおよびM&Aにおける技術デューデリジェンス

企業の技術的な優位性や負債を評価する投資アナリストは、対象企業のスタックが成長曲線上にあるのか、コミュニティサポートの終息に近づいているのかを把握する必要があります。generate_tech_report は、採用動向、成熟度の段階、CVEの露出、センチメントを含む全体分析を、1回のAIエージェント呼び出しで生成します。

デベロッパーリレーションズとコンテンツ戦略

カンファレンスでの講演、チュートリアル、コミュニティへのスポンサーシップにどこから投資するかを決めるDevRelチームは、track_framework_trends を使って、モメンタムスコアが高く成長段階にあるフレームワークを特定できます。これにより、高額なアンケート調査をライブデータに置き換えられます。

フレームワーク移行の計画

古くなったフレームワークから移行するためのビジネスケースを作成するチームには、候補のフレームワークが本当に成熟しているのか、それともまだ不安定なのかを示すデータが必要です。assess_tech_maturity は、エンタープライズ採用の代理指標、エコシステムの広がり、安定性指数を含む6要素の成熟度モデルを生成し、移行の意思決定に役立つ根拠を構造化して提示します。

AIエージェントによる継続的なモニタリング

AIコーディングアシスタントを使用するエンジニアリング組織は、このMCPをスケジュール実行するApifyに接続できます。本番スタックを対象に score_tech_stack_risk を毎週呼び出すことで、新たなCVEやコミュニティの健全性の低下を、インシデントになる前に自動で検出できます。

このMCPサーバーへの接続方法

Claude Desktop

claude_desktop_config.json に追加します：

{
  "mcpServers": {
    "tech-ecosystem-analysis": {
      "url": "https://tech-ecosystem-analysis-mcp.apify.actor/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_APIFY_TOKEN"
      }
    }
  }
}

Cursor / Windsurf / Cline

MCP クライアントの設定に、同じ URL と Authorization ヘッダーを追加します。サーバーは Streamable HTTP トランスポートを使用するため、SSE の設定は不要です。

HTTP から直接

curl -X POST "https://tech-ecosystem-analysis-mcp.apify.actor/mcp" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_APIFY_TOKEN" \
  -d '{
    "jsonrpc": "2.0",
    "method": "tools/call",
    "params": {
      "name": "assess_tech_adoption",
      "arguments": {
        "technologies": ["TypeScript", "Rust", "Go"]
      }
    },
    "id": 1
  }'

Python（openai-agents または任意の MCP クライアント経由）

import httpx

response = httpx.post(
    "https://tech-ecosystem-analysis-mcp.apify.actor/mcp",
    headers={
        "Content-Type": "application/json",
        "Authorization": "Bearer YOUR_APIFY_TOKEN",
    },
    json={
        "jsonrpc": "2.0",
        "method": "tools/call",
        "params": {
            "name": "score_tech_stack_risk",
            "arguments": {
                "technologies": ["Django", "Flask", "FastAPI"]
            }
        },
        "id": 1,
    }
)

result = response.json()
for tech in result["result"]["content"]:
    print(tech["text"])

入力パラメーター

パラメーター	型	必須	デフォルト	説明
port	integer	いいえ	3054	MCP サーバーのポート番号（1024～65535）。Standby モード以外で実行する場合に使用します。

MCP サーバーには、アクターレベルの入力はほかにありません。すべての設定は、各ツール呼び出し時にツール引数として渡します。

ツール引数のリファレンス

map_tech_ecosystem

引数	型	必須	説明
technologies	string[]	はい	マッピングするテクノロジー。例：["React", "Node.js", "PostgreSQL"]
urls	string[]	いいえ	追加のテクノロジーを検出するウェブサイト URL

assess_tech_adoption

引数	型	必須	説明
technologies	string[]	はい	評価するテクノロジー。例：["TypeScript", "Rust", "Go"]

detect_tech_vulnerabilities

引数	型	必須	説明
technologies	string[]	はい	NVD CVE データベースと照合するテクノロジー
urls	string[]	いいえ	ウェブサイト URL。自動検出されたテクノロジーは CVE スキャンに追加されます

analyze_developer_sentiment

引数	型	必須	説明
technologies	string[]	はい	感情を測定するテクノロジー

score_tech_stack_risk

引数	型	必須	説明
technologies	string[]	はい	複合リスクをスコア化するテクノロジー

track_framework_trends

引数	型	必須	説明
frameworks	string[]	はい	追跡するフレームワーク。例：["Next.js", "SvelteKit", "Remix"]

assess_tech_maturity

引数	型	必須	説明
technologies	string[]	はい	S カーブのライフサイクルモデルに当てはめるテクノロジー

generate_tech_report

引数	型	必須	説明
technologies	string[]	はい	レポート全体に含めるテクノロジー
urls	string[]	いいえ	テクノロジースタックの自動検出に使用するウェブサイト URL

⬆️ 出力例

assess_tech_adoption — 出力サンプル

[
  {
    "technology": "TypeScript",
    "githubMetrics": {
      "totalRepos": 18,
      "totalStars": 98421,
      "avgStars": 5468,
      "topRepos": [
        { "name": "microsoft/TypeScript", "stars": 98421, "url": "https://github.com/microsoft/TypeScript" },
        { "name": "type-challenges/type-challenges", "stars": 43102, "url": "https://github.com/type-challenges/type-challenges" }
      ]
    },
    "stackOverflowMetrics": {
      "totalQuestions": 84,
      "avgScore": 4.2,
      "answerRate": 0.94,
      "recentActivity": 31
    },
    "adoptionScore": 79,
    "trend": "rising",
    "growthRate": 0.37
  }
]

score_tech_stack_risk — 出力サンプル

[
  {
    "technology": "Log4j",
    "cveExposure": {
      "score": 89,
      "totalCves": 7,
      "criticalCves": 2,
      "highCves": 3
    },
    "communitySupport": {
      "score": 42,
      "githubStars": 3210,
      "soQuestions": 14,
      "recentActivity": 1
    },
    "maturityFactor": {
      "score": 58,
      "ageYears": 18,
      "releaseFrequency": "infrequent"
    },
    "overallRisk": 76,
    "riskLevel": "critical",
    "recommendation": "Log4j has critical risk. Immediate review: 7 CVEs (2 critical) with limited community support."
  }
]

generate_tech_report — 出力サンプル（一部）

{
  "title": "Technology Ecosystem Report: React, TypeScript, PostgreSQL",
  "generatedAt": "2026-03-21T09:14:02.341Z",
  "technologies": ["React", "TypeScript", "PostgreSQL"],
  "summary": "Analyzed 3 technologies. Ecosystem contains 47 nodes and 83 relationships. Graph density: 0.076. Top technologies: TypeScript, React, PostgreSQL. Overall risk assessment: LOW — stack is healthy.",
  "sections": {
    "adoption": [
      { "technology": "React", "adoptionScore": 88, "trend": "stable" },
      { "technology": "TypeScript", "adoptionScore": 79, "trend": "rising" },
      { "technology": "PostgreSQL", "adoptionScore": 71, "trend": "stable" }
    ],
    "vulnerabilities": [
      { "technology": "React", "riskLevel": "low", "totalCves": 2, "avgCvss": 4.3, "exposureScore": 20 },
      { "technology": "TypeScript", "riskLevel": "none", "totalCves": 0, "avgCvss": 0, "exposureScore": 0 },
      { "technology": "PostgreSQL", "riskLevel": "medium", "totalCves": 6, "avgCvss": 6.1, "exposureScore": 40 }
    ],
    "maturity": [
      { "technology": "React", "maturityLevel": "mature", "maturityScore": 87 },
      { "technology": "TypeScript", "maturityLevel": "growing", "maturityScore": 61 },
      { "technology": "PostgreSQL", "maturityLevel": "mature", "maturityScore": 91 }
    ]
  },
  "recommendations": [
    "Technology stack appears healthy. Continue regular security audits and dependency updates."
  ],
  "riskSummary": {
    "overallRisk": "LOW — stack is healthy",
    "criticalFindings": [],
    "positiveIndicators": [
      "React: positive developer sentiment (score: 74/100)",
      "TypeScript: strong growth momentum (82/100)"
    ]
  }
}

出力フィールド

assess_tech_adoption

フィールド	型	説明
technology	string	テクノロジー名
githubMetrics.totalRepos	number	このテクノロジーに一致したリポジトリ数
githubMetrics.totalStars	number	一致したリポジトリのスター数の合計
githubMetrics.avgStars	number	リポジトリあたりの平均スター数
githubMetrics.topRepos	array	スター数上位 5 件のリポジトリ。名前、スター数、URL を含む
stackOverflowMetrics.totalQuestions	number	このテクノロジーに一致した SO の質問数
stackOverflowMetrics.avgScore	number	一致した質問のコミュニティスコアの平均
stackOverflowMetrics.answerRate	number	承認済みの回答がある質問の割合（0～1）
stackOverflowMetrics.recentActivity	number	過去 30 日間に作成された質問数
adoptionScore	number	加重採用スコア（0～100）
trend	string	rising、stable、または declining
growthRate	number	SO の最近のアクティビティと全体のアクティビティの比率（0～1）

detect_tech_vulnerabilities

フィールド	型	説明
technology	string	テクノロジー名（URL から自動検出されたものを含む）
cves	array	ID、深刻度、cvssScore、説明、publishedDate を含む CVE レコード
riskLevel	string	critical、high、medium、low、または none
totalCves	number	一致した CVE の合計数
avgCvss	number	CVSS 基本スコアの平均
exposureScore	number	加重露出スコア（0～100）

score_tech_stack_risk

フィールド	型	説明
technology	string	テクノロジー名
cveExposure.score	number	CVE 露出コンポーネント（0～100）
cveExposure.criticalCves	number	CRITICAL 深刻度の CVE 数
cveExposure.highCves	number	HIGH 深刻度の CVE 数
communitySupport.score	number	コミュニティの健全性コンポーネント（0～100）
communitySupport.githubStars	number	一致したリポジトリの GitHub スター合計数
communitySupport.soQuestions	number	一致した SO の質問数
communitySupport.recentActivity	number	過去 90 日以内に更新されたリポジトリ数
maturityFactor.score	number	成熟度コンポーネント（0～100）
maturityFactor.ageYears	number	Wikipedia に基づく推定年数
maturityFactor.releaseFrequency	string	frequent、regular、または infrequent
overallRisk	number	総合リスクスコア（0～100）
riskLevel	string	critical、high、medium、または low
recommendation	string	平易な言葉で示した推奨アクション

assess_tech_maturity

フィールド	型	説明
technology	string	テクノロジー名
maturityLevel	string	emerging、growing、mature、または declining
indicators.age	string	書式設定された年数（例："15 years (since 2009)"）
indicators.communitySize	number	一致したリポジトリ全体の GitHub スター合計数
indicators.documentationQuality	number	ドキュメントスコア（0～100）：Wikipedia の掲載状況 + SO の回答率
indicators.enterpriseAdoption	number	1K 超のスターを持つリポジトリに基づく代理スコア（0～100）
indicators.ecosystemBreadth	number	リポジトリ全体の一意な GitHub トピック数を 100 に換算
indicators.stabilityIndex	number	回答率 + 最近の更新比率（0～100）
maturityScore	number	総合成熟度スコア（0～100）
description	string	平易な言葉による成熟度の説明

track_framework_trends

フィールド	型	説明
framework	string	フレームワーク名
githubTrend.stars	number	一致したリポジトリ全体のスター合計数
githubTrend.forks	number	一致したリポジトリ全体のフォーク合計数
githubTrend.recentRepos	number	過去 6 か月以内に作成されたリポジトリ数
githubTrend.growthRate	number	過去 6 か月以内に作成されたリポジトリの割合
stackOverflowTrend.questionCount	number	一致した SO の質問総数
stackOverflowTrend.recentQuestions	number	過去 30 日間の SO の質問数
stackOverflowTrend.trendDirection	string	up、stable、または down
adoptionPhase	string	S カーブ上の段階：emerging、growing、mature、declining
momentum	number	総合モメンタムスコア（0～100）

テックエコシステム分析の実行にかかる費用はどのくらいですか？

この MCP はイベントごとの従量課金制です。ツールを呼び出すたびに**$0.045**かかります。8 つのツールはすべて同じ料金です。プラットフォームのコンピューティング費用も含まれています。

シナリオ	ツール呼び出し回数	1 回あたりの料金	合計費用
脆弱性を簡易スキャン（1 つのテクノロジー）	1	$0.045	$0.045
3 つのフレームワークの導入状況を確認	1	$0.045	$0.045
1 つのテックスタックで 8 つのツールをすべて実行	8	$0.045	$0.36
毎週のモニタリング（8 ツール × 4 週間）	32	$0.045	$1.44
チームで利用 — 月 10 件のレポート	80	$0.045	$3.60

Apify の無料プランには月額 $5 分のクレジットが含まれており、サブスクリプションに加入しなくても、個別のツールを 110 回呼び出すか、8 つのツールをすべて使ったエコシステムレポートを 13 件作成できます。実行ごとに最大支出額を設定して、費用を管理できます。

手作業での調査やアナリストレポートと比較してみてください。コンサルティング会社にテクノロジーのデューデリジェンスレポートを 1 件依頼すると、通常 $2,000～5,000 かかり、完成まで 2～3 週間かかります。この MCP を使えば、AI エージェントは同じように構造化されたデータを数秒で $0.045 で生成できます。

Tech Ecosystem Analysis MCP の仕組み

ステップ 1：ツールの呼び出しと課金

MCP クライアントがツールを呼び出すと、サーバーは直ちに Actor.charge() イベントの料金を請求します。支出上限が設定されていて、その上限に達した場合、ツールは処理を続けずに構造化されたエラー JSON を返します。これにより、予期しない超過支出を防ぎます。

ステップ 2：アクターの並列実行

runActorsParallel() は、Apify クライアントを介して必要なすべてのデータソースアクターを同時に起動します。各アクターは 256 MB のメモリを使用し、タイムアウトは 180 秒です。結果は dataset.listItems({ limit: 500 }) を使用して収集されます。失敗したアクターは空の配列を返します。スコアリング関数は欠損データを適切に処理するため、例外は発生しません。

ツールごとのデータソース：

• map_tech_ecosystem：GitHub（20 件の結果）+ Wikipedia（5 件の結果）+ URL ごとの Tech Stack Detector
• assess_tech_adoption：GitHub（30 件）+ StackExchange（30 件）
• detect_tech_vulnerabilities：NVD CVE（30 件）+ URL ごとの Tech Stack Detector
• analyze_developer_sentiment：Hacker News（30 件）+ StackExchange（30 件）
• score_tech_stack_risk：NVD CVE（30 件）+ GitHub（20 件）+ StackExchange（20 件）+ Wikipedia（5 件）
• track_framework_trends：GitHub（30 件）+ StackExchange（30 件）
• assess_tech_maturity：GitHub（20 件）+ StackExchange（20 件）+ Wikipedia（5 件）
• generate_tech_report：5 つすべてのソース（それぞれ 30 件の結果）+ URL ごとの Tech Stack Detector

ステップ 3：スコアリングと分類

各スコアリング関数は、language、name、description、title、tags フィールドに対して大文字と小文字を区別しない部分文字列マッチングを行い、テクノロジーごとにアクターの生データを絞り込みます。スコアは外部 API を呼び出さず、プロセス内で計算されます。すべての中間スコアは 0～100 の範囲に制限されます。generateReport 関数は、同じデータオブジェクトに対して 7 つのスコアリング関数を順番に呼び出し、統合された出力を組み立てます。

ステップ 4：レスポンス

結果は整形済み JSON としてシリアライズされ、タイプが text の MCP コンテンツブロックとして返されます。Streamable HTTP トランスポートはリクエストごとのセッションライフサイクルを処理します。サーバーは /mcp への POST ごとに新しい McpServer インスタンスを作成し、リクエスト間で共有状態が発生しないようにします。

最良の結果を得るためのヒント

1. ネットワークグラフを充実させるため、1回の呼び出しで2～5個のテクノロジーを指定してください。 1つのテクノロジーを指定する呼び出しは脆弱性チェックには有効ですが、エコシステムのマッピングでは、意味のあるエッジを構築するために共起データが必要です。

2. デューデリジェンスには generate_tech_report を、モニタリングには個別のツールを使用してください。 フルレポートでは6つのデータソースすべてを呼び出し、7つのスコアリング関数すべてを実行するため、単発の分析に最適です。週次の自動チェックでは、コストを抑えるために score_tech_stack_risk と detect_tech_vulnerabilities のみを呼び出してください。

3. 脆弱性スキャンにウェブサイトのURLを追加してください。 本番アプリケーションのURLを detect_tech_vulnerabilities または generate_tech_report に渡してください。Tech Stack Detector が、指定していないテクノロジーを特定し、それらも自動的にCVEスキャンに追加されます。

4. 成熟度スコアは成長率と併せて解釈してください。 テクノロジーが growing フェーズ（勢いが強い）にあっても、成熟度スコアが低い場合があります。つまり、採用が進んでいる一方で、エコシステムはまだ不安定です。両方のシグナルを併せて見ることで、全体像を把握できます。

5. 候補を比較する際は、assess_tech_maturity の前に track_framework_trends を使用してください。 トレンドデータからフレームワークの今後の方向性がわかり、成熟度から現在の状態がわかります。移行を決めるには、両方の情報が必要です。

6. このMCPを複数のユーザーや、ループ内でツールを呼び出す可能性のあるエージェントに公開する場合は、Apify の実行に支出上限を設定してください。 サーバーは上限到達イベントを適切に処理し、解析可能なエラーを返します。

7. エージェントのメモリに generate_tech_report の結果をキャッシュしてください。 フルレポートは包括的なため、テクノロジーに変更がない限り、エージェントが同じセッション内で再実行する必要はありません。detect_tech_vulnerabilities のような個別のツールは、新たに公開されたCVEを評価する際に、最新の情報を得るために再実行すると役立ちます。

他のApifyアクターやMCPと組み合わせる

アクター／MCP	組み合わせ方
Website Tech Stack Detector	単独で実行して競合他社のウェブサイトを監査し、検出されたテクノロジーを detect_tech_vulnerabilities に渡します
Company Deep Research	企業情報とテックスタックのリスクを組み合わせ、ベンダーや買収候補を総合的に評価します
OSS Dependency Risk MCP	このMCPで得られるCVEへの曝露情報とサプライチェーンの依存関係分析を組み合わせ、オープンソースのリスクを包括的に把握します
Website Content to Markdown	テクノロジーのドキュメントサイトをMarkdownに変換し、LLMを活用してAPIの安定性や互換性を破壊する変更を分析します
NVD CVE Vulnerability Search	detect_tech_vulnerabilities の結果に表示された特定のCVE IDを直接検索します
GitHub Repo Search	エコシステムのマッピングで主要なプロジェクトが特定された後、特定のリポジトリを詳しく調べます
Startup Due Diligence	スタートアップのテクノロジーリスク評価における入力シグナルとして、テクノロジーエコシステムのリスクスコアを使用します

制限事項

• データの最新性はソース API に依存します。 GitHub と StackExchange の結果は、クエリ実行時の現在の状態を反映します。NVD の CVE データは公開された脆弱性を反映しており、定義上、ゼロデイ脆弱性はデータベースに含まれません。
• スコアはシグナルに基づくものであり、確定的な評価ではありません。 成熟度スコアと採用スコアは、公開されている活動シグナルから算出されます。GitHub のスター数が多くてもエンタープライズ向けの本番品質が低いテクノロジーもあれば、スター数が少なくても組織で広く利用されているテクノロジーもあります。
• テクノロジー名の照合には部分文字列検索を使用します。 「Go」を検索すると、「Django」や「MongoDB」なども一致します。フィルタリングの精度を高めるには、「Golang」や「Go programming language」のような具体的な名称を使用してください。
• Wikipedia からの経過年数の抽出は記事内のパターンに依存します。 Wikipedia に認識可能な形式でリリース年が記載されていない場合、ageYears はデフォルトで 5 に設定され、成熟度スコアの精度が低下します。
• 過去の推移データはありません。 スコアは特定時点のスナップショットを反映します。このツールではスター数の推移グラフや過去 12 か月の CVE 履歴は表示できず、現在の状態のみを表示します。
• CVE の照合は CPE ベースではなく、テキストベースです。 NVD アクターは、説明と影響を受ける製品名によって CVE を照合します。そのため、一般的なテクノロジー名では誤検出が発生したり、製品名が分かりにくい CVE を見逃したりする可能性があります。
• 並列アクター呼び出しには 180 秒のタイムアウトがあります。 テクノロジーのリストが大きい場合（10 件以上）、Apify プラットフォームの負荷が高いと一部のアクターがタイムアウトし、データが一部しか返されないことがあります。
• ウェブサイトのテクノロジースタック検出には、一般公開されている URL が必要です。 パスワードで保護されているサイト、IP アドレスの許可リストが設定されているサイト、ボットをブロックしているサイトからは、テクノロジーデータを取得できません。

インテグレーション

• Apify API — HTTP 経由で CI/CD パイプラインやセキュリティツールから評価を実行します
• Webhooks — generate_tech_report の実行で重大な CVE やリスクレベルの変化が検出されたときにアラートを発行します
• Zapier — エコシステム分析の結果を Jira のチケット作成に連携し、CVE 修正のワークフローに活用します
• Make — Slack やメールに配信する、週次のテックスタック健全性ダッシュボードを自動作成します
• Google Sheets — 採用スコアと成熟度の分類をチーム共有のスプレッドシートにエクスポートし、テックレーダーの保守に活用します
• LangChain / LlamaIndex — 自律的なテクノロジー調査や推奨のワークフローを実行する ReAct エージェント内のツールとして、この MCP を使用します

トラブルシューティング

すべてのテクノロジーでツール呼び出しの結果が空の配列になります。 これは通常、並列のアクター呼び出しがすべてタイムアウトしたか、Apify トークンのクレジットが不足していることを意味します。Apify アカウントの残高を確認し、Authorization ヘッダーで渡すトークンに Actor:run 権限があることを確認してください。各ツール呼び出しでは、基盤となるアクターの実行にクレジットが必要です。

CVE の結果が不完全に見えたり、無関係な脆弱性が含まれたりします。 NVD アクターはテキストマッチングを使用します。より具体的なテクノロジー名を試してください。たとえば、「Log4j」ではなく「Apache Log4j」、「SSL」ではなく「OpenSSL」を使用します。「Java」や「Python」のような広範な用語は、無関係な CVE にも大量に一致し、結果があふれる原因になります。

assess_tech_maturity がすべてのテクノロジーに対して ageYears: 5 を返します。 Wikipedia の記事抽出で、認識可能なパターンのリリース年が見つかりませんでした。これは、Wikipedia の記事で異なる形で歴史が説明されているテクノロジーによく見られます。スコアは引き続き機能しますが、年齢の寄与はデフォルトで最小値になります。結果を解釈する際は、ほかの成熟度指標を使用してください。

map_tech_ecosystem がエッジの少ない疎なグラフを返します。 GitHub の検索結果でテクノロジー間の共起が少ない場合、グラフは疎になります。たとえば、互いに無関係なテクノロジーである ["React", "Kubernetes", "PostgreSQL"] ではなく、よく一緒に使われる関連テクノロジー ["React", "TypeScript", "Tailwind", "Vite"] を使用してください。

generate_tech_report の実行中に支出上限に達したというエラーが発生します。 完全なレポートは、単一の呼び出しとして最も高額です（課金イベントは 1 回）。このエラーが表示された場合、実行単位の支出上限が低すぎます。Apify Console の実行設定で上限を引き上げるか、API 経由でアクターを呼び出す際に maxTotalChargeUsd をより高く設定してください。

責任ある利用

• この MCP は、オープンデータベース（GitHub、NVD、StackExchange、Hacker News、Wikipedia）で公開されているデータのみを使用します。
• NVD の CVE データは米国政府のパブリックドメインであり、利用に制限はありません。
• GitHub、StackExchange、Hacker News のデータには、それぞれの API 利用規約が適用されます。
• 脆弱性データをシステムの悪用に使用しないでください。CVE 情報は、防御的なセキュリティ調査とリスク評価のために提供されています。
• ウェブスクレイピングの合法性に関するガイダンスについては、Apify のガイドをご覧ください。

❓ よくある質問

1 回のツール呼び出しで分析できるテクノロジーの数はいくつですか？ 厳密な上限はありません。スコアリング関数は、入力配列内のすべてのテクノロジーを処理します。実際には、1 回の呼び出しで 1～10 個のテクノロジーを指定すると、最も有用な結果が得られます。非常に大きなリスト（20 個以上）では、すべてのテクノロジーが 1 つの検索クエリにまとめられるため、GitHub と SO のクエリ結果に含まれる有用な情報が薄まります。

テクノロジーエコシステム分析で、自分のコードベースの脆弱性を検出できますか？ いいえ。この MCP が分析するのはテクノロジーそのもの（フレームワーク、言語、ライブラリ）であり、特定のバージョンや設定ではありません。指定したテクノロジーについて、公知の CVE をすべて取得します。スタック内のどのコンポーネントに既知の CVE があるかを特定するために使用し、実際に使用している依存関係のバージョンと照合してください。

CVE の脆弱性データはどれくらい最新ですか？ CVE データは、各ツール呼び出しの時点で National Vulnerability Database からリアルタイムで取得されます。キャッシュはありません。detect_tech_vulnerabilities または score_tech_stack_risk を呼び出すたびに、公開済みの現在の CVE データベースの状態が反映されます。

テクノロジーエコシステム分析は、プロプライエタリなテクノロジーや社内テクノロジーでも機能しますか？ 有用なデータを返すには、テクノロジーが GitHub、StackOverflow、または NVD に存在している必要があります。社内ツールや未公開のライブラリでは、結果は空になります。公開されているフレームワーク、言語、データベース、クラウドサービス、オープンソースライブラリであれば機能します。 Snyk や Dependabot とはどう違いますか？ Snyk と Dependabot は、ロックファイル内の特定の依存関係のバージョンを分析します。この MCP は、コミュニティとセキュリティインテリジェンスの観点から技術エコシステムを分析し、採用の傾向、成熟度の段階、開発者の評価、エコシステムの健全性を調べます。両者は相互補完的です。バージョン固有の CVE 修正には Snyk を、戦略的な技術選定とリスク評価にはこの MCP をご利用ください。

この MCP をスケジュールに従って自動実行できますか？ はい。Apify API を使って、スケジュールに従いアクターを実行できます（Apify Scheduler または任意の cron サービス）。スケジュールされた実行のたびに MCP サーバーに接続し、設定したツールを呼び出します。新たな重大な CVE が見つかった場合にアラートを受け取りたい、週次の技術スタック健全性モニタリングに便利です。

ツール呼び出し 1 回あたりの一般的な応答時間はどれくらいですか？ 各ツール呼び出しでは、タイムアウトをそれぞれ 180 秒として、最大 4 つのアクターを並列実行します。一般的なレイテンシは、データソースの応答時間によって異なりますが、15～45 秒です。generate_tech_report はすべての 6 つのソースを同時に実行するため、最も時間がかかります。

GitHub、StackOverflow、Hacker News のデータをスクレイピングするのは合法ですか？ すべてのデータソースには、ウェブスクレイピングではなく、公式の公開 API 経由でアクセスします。GitHub Search API、NVD の REST API、StackExchange API、Hacker News Firebase API は、いずれも一般公開されています。ウェブスクレイピングの合法性に関する Apify のガイドをご覧ください。

出力を商用製品やレポートに利用できますか？ はい。NVD のデータは米国政府のパブリックドメインです。GitHub と StackExchange の API データは、一般に各サービスの利用規約に基づいて分析やレポート作成に使用できます。再配布する場合は、具体的な用途に応じて各データソースの規約をご確認ください。

ツール呼び出し中に、基盤となるアクターの 1 つが失敗した場合はどうなりますか？ runActorsParallel 関数はアクターごとにエラーを捕捉し、そのソースについて空の配列を返します。スコアリング関数はデータの欠落を適切に処理するため、例外を発生させず、該当するスコア要素への寄与をゼロとして扱います。ツールは常に結果を返しますが、一部のソースが失敗した場合は信頼度が低くなることがあります。

S カーブのフェーズとトレンドの方向はどう違いますか？ トレンドの方向（up／stable／down）は、StackOverflow の過去 30 日間の活動を全期間の活動と比較し、短期的な勢いを示します。採用フェーズ（emerging／growing／mature／declining）は、6 か月間のスター数のしきい値と成長率を組み合わせたライフサイクル分類です。テクノロジーが mature でありながら、トレンドが stable や down となることもあります。確立されたテクノロジーでは通常のことです。

改善にご協力ください

問題が発生した場合は、Apify アカウントで実行の共有を有効にすると、より迅速なデバッグに役立ちます。

1. アカウント設定 > プライバシーに移動します
2. 実行を公開アクターの作成者と共有を有効にします

これにより、問題が発生したときに実行の詳細を確認できるため、より迅速に修正できます。データはアクターの開発者のみが閲覧でき、一般公開されることはありません。

サポート

バグを見つけた場合や機能のリクエストがある場合は、このアクターのページにあるIssues タブで Issue を作成してください。カスタムのスコアリングアルゴリズム、データソースの追加、エンタープライズ統合については、Apify プラットフォームからお問い合わせください。