Causal Panopticon MCP Server

Causal Panopticon MCP サーバー

ApifyForge で表示 | Apify Store で利用

---

クイックスタート

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

{
  "mcpServers": {
    "causal-panopticon-mcp": {
      "url": "https://ryanclinton--causal-panopticon-mcp.apify.actor/mcp"
    }
  }
}

---

Causal Panopticon は、Model Context Protocol を通じて公開される、AI エージェント向けの分野横断型因果探索・推論エンジンです。経済、医療、環境、安全保障、政策、金融、学術、労働にまたがる18の異種データソースを連携させ、査読済みの8つの因果アルゴリズムを適用して、単なる相関ではなく、実際に何が何を引き起こすのかを明らかにします。

相関分析を超えて因果構造を探る必要がある研究者、政策アナリスト、AI エージェント向けに構築されています。各ツール呼び出しで最大18のデータアクターを並列実行し、因果グラフを組み立て、平均処置効果、反実仮想値、移送可能性の判定、検証済みDAG構造などの構造化された推論結果を、単一のMCP接続を通じて返します。

アクセスできるデータソース

データポイント	ソース	対象範囲
📊 経済時系列	FRED Economic Data	米国の80万件以上の時系列
👷 労働統計	BLS Economic Data	米国の雇用、賃金、物価
🌐 世界のマクロ経済指標	IMF Data	190か国
🏥 医療統計	WHO GHO Data	世界の医療指標
🧪 臨床研究	ClinicalTrials.gov	世界各地の登録済み試験
🔬 生物医学文献	PubMed Search	3,500万件以上の記事
🌦️ 気象・気候データ	NOAA Weather	米国および世界の観測データ
💨 大気質測定値	OpenAQ	世界各地の監視ステーション
🔐 サイバー脆弱性	NVD CVE Search	公開済みのすべてのCVE
📜 米国の法律	Congress Bill Search	審議中および過去の法案
📋 米国の規制関連文書	Federal Register Search	連邦規則および告示
🏢 企業のSEC提出書類	SEC EDGAR Search	すべての公開企業の提出書類
📈 市場・株式データ	Finnhub Financial Data	世界の株式
🎓 学術出版物	OpenAlex	2億5,000万件以上の学術成果
🌪️ 災害宣言	FEMA Disaster Search	米国の災害記録
⚠️ 消費者製品の安全性	CPSC Recall Search	製品リコールの警告
💊 医薬品の有害事象	FDA Drug Event Search	FAERS データベース
💼 労働市場の動向	Job Market Intelligence	雇用シグナル

Causal Panopticon MCP Server を使う理由

相関に基づく分析は速い一方、意思決定には危険を伴います。大気質と入院数に相関があると分かった政策チームも、それだけでは汚染が病気を引き起こすのか、病気の人が汚染された地域へ移住するのか、あるいは貧困が両方の交絡要因になっているのかを判断できません。この違いを見誤れば、介入が無駄になり、機会を逃すことになります。

手作業での因果分析では、18の個別のソースからデータを収集し、条件付き独立性検定を適用し、DAGを構築して、バックドア基準を確認する必要があり、訓練を受けた経済学者でも数週間かかります。このMCPサーバーなら、1回のAI エージェントのツール呼び出しで実行できます。

MCPプロトコルを介して接続すると、Claude Desktop、Cursor、その他のMCP互換クライアント上のAI エージェントに、データ収集コードを1行も書くことなく因果推論機能を追加できます。

• スケジュール設定 — 因果探索を定期的に実行し、現実世界の因果関係における構造変化を経時的に検出します
• APIアクセス — ApifyプラットフォームAPIを介して、Python、JavaScript、または任意のHTTPクライアントから実行を開始します
• プロキシローテーション — 18のソースにわたるデータ収集でApifyの組み込みプロキシ基盤を利用し、レート制限を回避します
• モニタリング — ツール呼び出しの失敗時や予期しない結果が返されたときに、Slackまたはメールで通知を受け取ります
• 連携機能 — Zapier、Make、Google Sheets、またはWebhook対応の任意のワークフローに接続します

MCP ツール

ツール	アルゴリズム	最適な用途	呼び出しごとのコスト
discover_cross_domain_causes	PC / GES / NOTEARS メタアルゴリズム + 転送エントロピー	ドメインをまたぐ因果構造の発見	$0.04
estimate_interventional_effect	Do 計算（3つのルール）、バックドア、フロントドア、IV	処置効果の推定、政策評価	$0.04
compute_counterfactual	Pearl の SCM：アブダクション → アクション → 予測	遡及的な帰属分析、もしも分析	$0.04
transport_causal_effect	Bareinboim-Pearl のトランスポータビリティ、s-許容性	母集団をまたぐ知見の一般化	$0.04
detect_confounders	グラフ構造 + 偏相関分析	因果推論に対する脅威の特定	$0.04
simulate_causal_agents	ベイズ説得、Kamenica-Gentzkow の凹包化	専門家間の意見の相違のモデリング、政策への説得	$0.04
optimize_causal_experiment	因果ベイズ最適化、期待改善量	実験設計、能動学習	$0.04
validate_causal_model	DAG の非巡回性、マルコフ適合性、忠実性、BIC	モデル検証、アルゴリズム比較	$0.04

特徴

• メタアルゴリズム選択 — auto モードでは、3 つすべての構造学習アルゴリズム（PC、GES、NOTEARS）を実行し、最も高い BIC スコアの結果を選択するため、手動で調整しなくても、データに最もよく適合する DAG を得られます
• PC アルゴリズム — Fisher の z 検定（Abramowitz-Stegun 近似）を用いた Pearson 偏相関検定による制約ベースの因果発見です。alpha パラメーターで有意水準を調整できます
• GES アルゴリズム — 前向きおよび後ろ向きの BIC スコアリング段階を備えた貪欲同値探索です。PC のスケルトンが過剰に刈り込みやすい、密な因果グラフに適しています
• NOTEARS アルゴリズム — トレース指数関数による非巡回性制約（8 次までのテイラー級数近似）を用いた連続最適化です。組合せ的な DAG 探索を微分可能な問題に変換します
• do 計算による識別 — Pearl の do 計算の 3 つの規則をすべて実装しています。バックドア基準、フロントドア基準、操作変数による識別の順に適用し、効果を識別した基準を返します
• SCM の反実仮想 — Pearl の 3 段階手順です。アブダクション（残差化によって外生ノイズ U を推論）、アクション（仮定上の状況に合わせて構造方程式を変更）、予測（変更後の SCM においてトポロジカル順に伝播）を行います
• Bareinboim-Pearl の可搬性 — 選択ダイアグラムを用いて s-許容性を評価します。ソースドメインで識別された因果効果をターゲットドメインに妥当に移送できるかを報告し、調整後の推定値も提示します
• 伝達エントロピー行列 — すべてのドメインペア間の時間遅れ付き相互情報量をカーネル密度推定します。有向グラフでは見逃す可能性のある情報の流れを捉えます
• 余極限グラフの構築 — 有向グラフ上の圏論的な余極限を用いて、ドメインごとの因果グラフを統合された因果アトラスにマージし、ドメイン固有のエッジをドメイン間の因果関係として保持します
• ベイズ的説得のシミュレーション — Kamenica-Gentzkow の送信者・受信者ゲームで、3,000 人のドメイン専門家エージェントをモデル化します。事後信念の単体上で送信者の価値関数を凹包化し、最適な情報開示ポリシーを求めます
• 交絡因子の検出 — 各交絡因子の変数名、交絡する変数のペア、交絡の強さ（偏相関の大きさ）、グラフ上で調整可能かどうか、および調整不可能な交絡因子に対する操作変数の有無を報告します
• 実験の最適化 — 因果ベイズ最適化によって、分散の低減を通じて期待情報利得を最大化する介入変数を選択します。Expected Improvement 獲得関数を適用し、検出力分析によって推奨サンプルサイズを出力します
• モデルの検証 — 独立した 4 つの検証基準を備えています。DAG の非巡回性（Kahn のトポロジカルソート）、マルコフ適合性（含意される独立性がデータ内で成立すること）、忠実性（余分な独立性がないこと）、および各検定の個別 p 値を用いた BIC 適合度です
• 並列データ収集 — runActorsParallel を介して、すべての上流アクターを同時に実行します。アクターごとのタイムアウトは 180 秒で、失敗時には空配列にフォールバックします

クロスドメイン因果発見のユースケース

政策効果の調査

立法案を評価する政策アナリストやシンクタンクは、法律と結果に相関があるかだけでなく、法律が結果を引き起こしたかを知る必要があります。estimate_interventional_effect を sourceDomain: "policy" と targetDomain: "economics" を指定して使用すると、雇用や GDP に対する立法上の変更の平均処置効果を推定できます。識別基準も報告されるため、バックドア、フロントドア、操作変数のいずれが使われたかを確認できます。

ドメイン横断的な因果仮説の生成

ナレッジグラフを構築する研究チームや AI エージェントは、単一のデータサイロ内で作業することがよくあります。discover_cross_domain_causes は、9 つすべてのドメイングループから同時にデータを取得し、メタアルゴリズムを通じてドメインごとの DAG を構築して、余極限グラフに統合します。その結果、たとえば NOAA の気候変数が FRED の失業率系列に影響するなど、単一ドメインの分析では見つからないドメイン横断的な因果エッジが明らかになります。

臨床および公衆衛生における原因帰属

疫学者や公衆衛生研究者は、原因帰属に関する問いに答えるため、反実仮想の推定値を必要とします。compute_counterfactual は、PubMed と臨床試験のデータを用いて、Pearl のアブダクション・アクション・予測手順を実装します。「介入が導入されていなかった場合、死亡率はどの程度だったでしょうか？」という問いに答えられます。外生ノイズ項は観測された残差から推定されるため、統計的根拠に基づいた事後推定値が得られます。

集団をまたいだ知見の一般化

開発経済学者や国際保健研究者は、ある国のデータから得られた知見を別の国に適用する必要がよくあります。transport_causal_effect は、ソースドメインとターゲットドメインのグラフから導出した選択図を用いて、Bareinboim-Pearl の s-admissibility を評価します。効果を輸送できる場合は、再重み付けした調整済み推定値を返します。できない場合は、輸送可能性が成立しない理由を報告します。

AI エージェントによる実験計画

因果学習パイプラインを実行する AI エージェントは、たとえば複数回の実行を通じて研究課題を反復検討するエージェントなどが、次に介入する変数を決めるために optimize_causal_experiment を利用できます。Expected Improvement 獲得関数は、ターゲットに関する事後分散を最大限に減らす変数を選択し、サンプルサイズ計画のための検出力分析も出力します。

下流で利用する前の因果モデルの検証

発見した DAG を意思決定に利用したり、下流の分析に渡したりする前に、validate_causal_model を使って、DAG の非巡回性、マルコフ適合性、忠実性を満たしていることを検証します。各基準について個別の検定 p 値が返されるため、その構造を受け入れるか棄却するかの統計的根拠を報告できます。

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

Claude Desktop

以下を claude_desktop_config.json に追加します。

{
  "mcpServers": {
    "causal-panopticon": {
      "url": "https://causal-panopticon-mcp.apify.actor/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_APIFY_TOKEN"
      }
    }
  }
}

Cursor

以下を Cursor の MCP 設定に追加します。

{
  "mcpServers": {
    "causal-panopticon": {
      "url": "https://causal-panopticon-mcp.apify.actor/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_APIFY_TOKEN"
      }
    }
  }
}

MCP 対応クライアント全般

サーバーのエンドポイントは次のとおりです：https://causal-panopticon-mcp.apify.actor/mcp

このサーバーは Streamable HTTP トランスポートを使用し、標準 MCP 操作の tools/list と tools/call をすべてサポートしています。

入力パラメーター

この MCP サーバーには、アクターレベルの入力はありません。すべてのパラメーターは、AI エージェントが各ツールを呼び出す際に直接渡します。

ツールごとのパラメーター

ツール	パラメーター	型	必須	デフォルト	説明
discover_cross_domain_causes	query	string	はい	—	すべてのドメインアクターに送信する検索クエリ（例：「inflation healthcare employment」）
discover_cross_domain_causes	domains	string[]	いいえ	all 9	次のドメインのサブセット：economics、health、environment、security、policy、finance、academia、disaster、labor
discover_cross_domain_causes	algorithm	enum	いいえ	auto	auto、pc、ges、または notears
discover_cross_domain_causes	alpha	number	いいえ	0.05	PC 条件付き独立性検定の有意水準
discover_cross_domain_causes	maxResults	number	いいえ	20	各アップストリームアクターから取得する結果の最大数
estimate_interventional_effect	query	string	はい	—	データ収集クエリ
estimate_interventional_effect	treatment	string	はい	—	処置／介入変数名
estimate_interventional_effect	outcome	string	はい	—	結果変数名
estimate_interventional_effect	domains	string[]	いいえ	all 9	データ収集の対象ドメイン
estimate_interventional_effect	maxResults	number	いいえ	15	各アクターあたりの結果の最大数
compute_counterfactual	query	string	はい	—	データ収集クエリ
compute_counterfactual	interventionVariable	string	はい	—	仮説上変更する変数
compute_counterfactual	interventionValue	number	はい	—	介入に用いる仮説上の値
compute_counterfactual	queryVariable	string	はい	—	反実仮想値を計算する変数
compute_counterfactual	domains	string[]	いいえ	all 9	データ収集の対象ドメイン
compute_counterfactual	maxResults	number	いいえ	15	各アクターあたりの結果の最大数
transport_causal_effect	query	string	はい	—	両方のドメインに共通するクエリ
transport_causal_effect	sourceDomain	string	はい	—	効果が特定されたドメイン
transport_causal_effect	targetDomain	string	はい	—	効果の移送先ドメイン
transport_causal_effect	treatment	string	はい	—	処置変数
transport_causal_effect	outcome	string	はい	—	結果変数
transport_causal_effect	selectionVariables	string[]	いいえ	—	ドメイン間で異なる変数
transport_causal_effect	maxResults	number	いいえ	15	各アクターあたりの結果の最大数
detect_confounders	query	string	はい	—	データ収集クエリ
detect_confounders	domains	string[]	いいえ	all 9	データ収集の対象ドメイン
detect_confounders	maxResults	number	いいえ	15	各アクターあたりの結果の最大数
simulate_causal_agents	query	string	はい	—	評価対象の因果関係に関する主張または仮説
simulate_causal_agents	numStates	number	いいえ	3	考えられる因果状態の数（2–10）
simulate_causal_agents	numAgents	number	いいえ	3000	シミュレーションするドメイン専門家エージェントの数
simulate_causal_agents	domains	string[]	いいえ	all 9	データ収集の対象ドメイン
simulate_causal_agents	maxResults	number	いいえ	10	各アクターあたりの結果の最大数
optimize_causal_experiment	query	string	はい	—	研究課題または対象変数のクエリ
optimize_causal_experiment	targetVariable	string	はい	—	知見を得る対象の変数
optimize_causal_experiment	budget	number	いいえ	100	実験予算（コスト見積もり用の抽象単位）
optimize_causal_experiment	domains	string[]	いいえ	all 9	データ収集の対象ドメイン
optimize_causal_experiment	maxResults	number	いいえ	15	各アクターあたりの結果の最大数
validate_causal_model	query	string	はい	—	データ収集クエリ
validate_causal_model	domains	string[]	いいえ	all 9	データ収集の対象ドメイン
validate_causal_model	algorithm	enum	いいえ	auto	検証アルゴリズム：auto、pc、ges、notears
validate_causal_model	maxResults	number	いいえ	15	各アクターあたりの結果の最大数

使用例

経済と健康の因果構造を横断的に発見する：

{
  "query": "inflation unemployment healthcare spending",
  "domains": ["economics", "health", "labor"],
  "algorithm": "auto",
  "alpha": 0.05,
  "maxResults": 20
}

政策の処置効果を推定する：

{
  "query": "minimum wage employment",
  "treatment": "minimum_wage",
  "outcome": "employment_rate",
  "domains": ["economics", "policy", "labor"],
  "maxResults": 15
}

健康介入の反事実を計算する：

{
  "query": "air quality respiratory hospital admissions",
  "interventionVariable": "pm25_concentration",
  "interventionValue": 12.0,
  "queryVariable": "hospital_admissions",
  "domains": ["environment", "health"],
  "maxResults": 15
}

入力のヒント

• 対象領域を絞る — 9つすべてを使うのではなく、焦点を絞った2～3つの領域を指定すると、コストを抑え、因果グラフのシグナル対ノイズ比を改善できます
• 説明的なクエリを使う — 「health」よりも「air quality respiratory hospital admissions」のようなクエリのほうが、各上流アクターから関連性の高いデータを取得でき、抽出される数値特徴量の品質が向上します
• 変数名をデータに合わせる — findClosestNode 関数は部分文字列で照合するため、「employment」や「pm25」のような処置／結果変数名は、IDが完全一致しなくてもノードに一致します
• 探索的な作業では alpha を大きくする — alpha: 0.10 に設定すると、PCアルゴリズムによるエッジの枝刈りが弱まり、仮説生成に使える、より密な骨格が得られます
• discover_cross_domain_causes の後に validate_causal_model を使う — まず因果関係の発見を実行し、次に同じクエリと領域パラメーターを使って検証を実行すると、結論を出す前に各モデル基準のp値を取得できます

出力例

discover_cross_domain_causes の出力

{
  "algorithm": "NOTEARS",
  "totalNodes": 24,
  "totalEdges": 31,
  "domains": ["economics", "health", "environment", "labor"],
  "perDomainGraphs": [
    {
      "algorithm": "GES",
      "nodes": 8,
      "edges": 11,
      "bicScore": -142.7,
      "dagValid": true
    },
    {
      "algorithm": "PC",
      "nodes": 6,
      "edges": 7,
      "bicScore": -98.4,
      "dagValid": true
    }
  ],
  "crossDomainEdges": [
    {
      "from": "economics_cpi_inflation",
      "to": "health_hospital_admissions",
      "weight": 0.64,
      "mechanism": "indirect",
      "confidence": 0.81
    },
    {
      "from": "environment_pm25",
      "to": "labor_absenteeism",
      "weight": 0.52,
      "mechanism": "direct",
      "confidence": 0.74
    }
  ],
  "colimitGraph": {
    "nodes": 24,
    "edges": 31,
    "dagValid": true
  },
  "transferEntropyTopPairs": [
    { "from": "economics", "to": "labor", "entropy": 0.43 },
    { "from": "environment", "to": "health", "entropy": 0.38 }
  ]
}

estimate_interventional_effect の出力

{
  "treatment": "economics_minimum_wage",
  "outcome": "labor_employment_rate",
  "averageTreatmentEffect": -0.024,
  "confidence": 0.78,
  "identificationCriterion": "backdoor",
  "adjustmentSet": ["economics_gdp_growth", "policy_labor_regulation"],
  "confidenceInterval": [-0.041, -0.007],
  "graphAlgorithm": "GES",
  "graphNodes": 18,
  "graphEdges": 22
}

compute_counterfactual の出力

{
  "query": "What would hospital admissions be if PM2.5 had been 12?",
  "factualValue": 0.47,
  "counterfactualValue": 0.31,
  "causalEffect": -0.16,
  "probability": 0.83,
  "mechanism": "direct structural pathway via environment_pm25 -> health_respiratory",
  "exogenousNoiseTerms": 6,
  "graphAlgorithm": "NOTEARS",
  "graphNodes": 14
}

transport_causal_effect の出力

{
  "sourceDomain": "health",
  "targetDomain": "economics",
  "sourceEffect": 0.38,
  "transportable": true,
  "sAdmissible": true,
  "adjustedEffect": 0.29,
  "confidence": 0.71,
  "selectionNodes": ["gdp_per_capita", "healthcare_expenditure"],
  "sourceGraphNodes": 9,
  "targetGraphNodes": 11
}

validate_causal_model の出力

{
  "overallValid": true,
  "dagConstraintSatisfied": true,
  "markovCompatible": true,
  "faithfulnessHolds": false,
  "bicScore": -214.3,
  "testResults": [
    { "test": "dag_acyclicity", "pValue": 1.0, "passed": true },
    { "test": "markov_compatibility", "pValue": 0.12, "passed": true },
    { "test": "faithfulness", "pValue": 0.03, "passed": false },
    { "test": "bic_goodness_of_fit", "pValue": 0.24, "passed": true }
  ],
  "graphAlgorithm": "PC",
  "graphNodes": 16,
  "graphEdges": 19
}

出力フィールド

共通フィールド（すべてのツール）

フィールド	型	説明
graphAlgorithm	string	選択されたアルゴリズム：PC、GES、または NOTEARS
graphNodes	number	統合された因果グラフ内のノード数
graphEdges	number	統合された因果グラフ内の有向エッジ数

discover_cross_domain_causes

フィールド	型	説明
algorithm	string	メタアルゴリズムで選択されたアルゴリズム（最良のBIC）
totalNodes	number	余極限（統合）グラフ内のノード総数
totalEdges	number	余極限グラフ内のエッジ総数
domains	string[]	この実行に含まれる領域
perDomainGraphs[]	object[]	各領域のグラフの概要。アルゴリズム、ノード／エッジ数、BICスコア、DAGの妥当性フラグを含みます
crossDomainEdges[]	object[]	端点が異なる領域グラフにまたがるエッジ
crossDomainEdges[].from	string	ソースノードID（領域プレフィックス付き）
crossDomainEdges[].to	string	ターゲットノードID（領域プレフィックス付き）
crossDomainEdges[].weight	number	エッジの重み（偏相関の大きさ）
crossDomainEdges[].mechanism	string	direct または indirect
crossDomainEdges[].confidence	number	方向に対する信頼度 [0, 1]
colimitGraph.nodes	number	統合された余極限グラフ内のノード総数
colimitGraph.edges	number	統合された余極限グラフ内のエッジ総数
colimitGraph.dagValid	boolean	余極限グラフが非巡回性を満たすかどうか
transferEntropyTopPairs[]	object[]	時間差付き転送エントロピーによる上位の領域ペア

estimate_interventional_effect

フィールド	型	説明
treatment	string	グラフ内で一致した処置ノードID
outcome	string	グラフ内で一致した結果ノードID
averageTreatmentEffect	number	ATE：E[Y | do(X=x)] - E[Y | do(X=x')]
confidence	number	ATE推定値に対する信頼度 [0, 1]
identificationCriterion	string	backdoor、frontdoor、instrumental、または direct
adjustmentSet	string[]	調整式で使用される変数
confidenceInterval	[number, number]	ATEの95%信頼区間の上下限

compute_counterfactual

フィールド	型	説明
query	string	人が読める反実仮想の質問
factualValue	number	クエリ変数の観測値
counterfactualValue	number	仮説上の介入下での推定値
causalEffect	number	反実仮想の効果：反実仮想値 - 事実値
probability	number	反実仮想シナリオの確率 [0, 1]
mechanism	string	因果経路の説明
exogenousNoiseTerms	number	推定された外生ノイズ変数の数（アブダクション段階）

transport_causal_effect

フィールド	型	説明
sourceDomain	string	効果が特定されたドメイン
targetDomain	string	転送先のドメイン
sourceEffect	number	ソースドメインにおける元の因果効果
transportable	boolean	効果を妥当に転送できるかどうか
sAdmissible	boolean	選択ダイアグラムが s-admissible かどうか
adjustedEffect	number	転送先ドメイン向けに再重み付けした効果推定値
selectionNodes	string[]	転送可能性ダイアグラム内の選択変数

detect_confounders

フィールド	型	説明
totalConfounders	number	グラフで見つかった交絡因子の合計数
confounders[].variable	string	交絡変数 ID
confounders[].confounds	[string, string]	交絡している変数のペア
confounders[].strength	number	交絡の強さ（偏相関の大きさ）
confounders[].adjustable	boolean	交絡因子が観測され、調整可能かどうか
confounders[].instrumentAvailable	boolean	操作変数が存在するかどうか
confounders[].instrument	string | null	利用可能な場合の IV 変数名

simulate_causal_agents

フィールド	型	説明
agentsSimulated	number	シミュレーション内の専門エージェント数
states	number	可能な因果状態の数
convergence	boolean	説得ゲームが均衡に達したかどうか
equilibriumBeliefs	object	状態に対する最終的な事後信念分布
senderPayoff	number	均衡シグナルにおける送信者の最適利得
receiverPayoff	number	均衡時の受信者の利得
informationRent	number	送信者が獲得した情報レント
optimalSignals	number	最適な情報開示ポリシーにおけるシグナル数
posteriorCount	number	凹包化した価値関数における事後分布の数

optimize_causal_experiment

フィールド	型	説明
targetVariable	string	グラフ内で一致したターゲット変数 ID
optimalIntervention	string	情報利得を最大化するために介入する変数
expectedInfoGain	number	事後分散の期待減少量
acquisitionFunction	number	期待改善獲得関数の値
suggestedSampleSize	number	検出力分析から推奨されるサンプルサイズ
estimatedCost	number	予算単位での実験の推定コスト
candidateVariables	string[]	検討対象となった介入候補変数すべて

validate_causal_model

フィールド	型	説明
overallValid	boolean	4 つすべての基準に合格した場合は True
dagConstraintSatisfied	boolean	カーンのトポロジカルソートが成功する（サイクルがない）
markovCompatible	boolean	含意される条件付き独立性がデータ内で成り立つ
faithfulnessHolds	boolean	データ内に余分な条件付き独立性がない
bicScore	number	ベイズ情報量規準（値が小さいほど良い）
testResults[]	object[]	p 値と合否を含む個別のテスト結果
testResults[].test	string	テスト名
testResults[].pValue	number	テストの p 値
testResults[].passed	boolean	テストに合格したかどうか

Causal Panopticon の利用料金はいくらですか？

Causal Panopticon はイベントごとの従量課金制で、ツール呼び出し1回につき $0.04です。上流のアクター実行料金は Apify の標準料金で別途請求されます（通常、上流の呼び出し1回につき $0.01～0.02）。プラットフォームのコンピューティング料金は含まれています。

シナリオ	ツール呼び出し回数	1回あたりの料金	推定合計
簡単なテスト	1	$0.04	$0.04
小規模な調査セッション	10	$0.04	$0.40
完全な分析パイプライン	50	$0.04	$2.00
毎日の自動実行	200	$0.04	$8.00
エンタープライズ向け調査ワークフロー	1,000	$0.04	$40.00

実行ごとに最大支出額を設定して、コストを管理できます。予算に達すると、アクターは停止します。

Apify の無料プランには、月額 $5 分のプラットフォームクレジットが含まれており、約125回のツール呼び出しを無料で利用できます。単一のデータドメインへのアクセスに月額 $200～2,000 を請求する商用の因果推論プラットフォームと比較してください。Causal Panopticon は、サブスクリプション契約なしで9つのドメインをカバーします。

API を使用してこのサーバーを呼び出す方法

Python

from apify_client import ApifyClient

client = ApifyClient("YOUR_API_TOKEN")

# Start the MCP server actor in standby mode and call a tool via HTTP
import urllib.request
import json

url = "https://causal-panopticon-mcp.apify.actor/mcp"
headers = {
    "Content-Type": "application/json",
    "Authorization": "Bearer YOUR_APIFY_TOKEN"
}

payload = {
    "jsonrpc": "2.0",
    "method": "tools/call",
    "params": {
        "name": "discover_cross_domain_causes",
        "arguments": {
            "query": "inflation unemployment health outcomes",
            "domains": ["economics", "health", "labor"],
            "algorithm": "auto",
            "maxResults": 20
        }
    },
    "id": 1
}

data = json.dumps(payload).encode("utf-8")
req = urllib.request.Request(url, data=data, headers=headers, method="POST")

with urllib.request.urlopen(req) as response:
    result = json.loads(response.read())
    content = result["result"]["content"][0]["text"]
    atlas = json.loads(content)
    print(f"Algorithm: {atlas['algorithm']}")
    print(f"Total nodes: {atlas['totalNodes']}, edges: {atlas['totalEdges']}")
    for edge in atlas.get("crossDomainEdges", []):
        print(f"  {edge['from']} -> {edge['to']} (confidence: {edge['confidence']:.2f})")

JavaScript

const url = "https://causal-panopticon-mcp.apify.actor/mcp";

const response = await fetch(url, {
    method: "POST",
    headers: {
        "Content-Type": "application/json",
        "Authorization": "Bearer YOUR_APIFY_TOKEN"
    },
    body: JSON.stringify({
        jsonrpc: "2.0",
        method: "tools/call",
        params: {
            name: "estimate_interventional_effect",
            arguments: {
                query: "minimum wage employment labor market",
                treatment: "minimum_wage",
                outcome: "employment_rate",
                domains: ["economics", "policy", "labor"],
                maxResults: 15
            }
        },
        id: 1
    })
});

const result = await response.json();
const content = JSON.parse(result.result.content[0].text);

console.log(`ATE: ${content.averageTreatmentEffect.toFixed(4)}`);
console.log(`Identification: ${content.identificationCriterion}`);
console.log(`Adjustment set: ${content.adjustmentSet.join(", ")}`);
console.log(`95% CI: [${content.confidenceInterval[0].toFixed(4)}, ${content.confidenceInterval[1].toFixed(4)}]`);

cURL

# Call discover_cross_domain_causes
curl -X POST "https://causal-panopticon-mcp.apify.actor/mcp" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_APIFY_TOKEN" \
  -d '{
    "jsonrpc": "2.0",
    "method": "tools/call",
    "params": {
      "name": "discover_cross_domain_causes",
      "arguments": {
        "query": "air quality respiratory disease employment",
        "domains": ["environment", "health", "labor"],
        "algorithm": "auto",
        "maxResults": 20
      }
    },
    "id": 1
  }'

# List all available tools
curl -X POST "https://causal-panopticon-mcp.apify.actor/mcp" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_APIFY_TOKEN" \
  -d '{"jsonrpc": "2.0", "method": "tools/list", "params": {}, "id": 1}'

Causal Panopticon の仕組み

フェーズ1：18のソースから並列でデータを収集

ツールが呼び出されると、サーバーは有効なドメインを特定し、DOMAIN_MAP 定数を使用して各ドメインを上流のアクター ID に対応付けます。経済ドメインは fred、bls、imf アクターに、医療ドメインは who、clinicalTrials、pubmed アクターに対応し、以下同様です。すべてのアクター呼び出しは、アクターごとの180秒のタイムアウトと空配列へのフォールバックを備えた Promise.all のラッパーである runActorsParallel によって、同時に実行されます。グラフを構築する前に、結果はドメインごとに domainData レコードにまとめられます。

フェーズ2：メタアルゴリズムによる因果グラフの構築

buildCrossDomainAtlas は各ドメインのデータ項目から数値特徴を抽出し、浮動小数点数に変換できる JSON フィールドを CausalNode.values 配列に格納します。ノードが2つ以上ある各ドメインについて、この関数は3つすべての構造学習アルゴリズムを実行し、BIC スコアが最も低い結果を選択します。PC アルゴリズムは完全な無向グラフから開始し、偏相関が alpha において有意でないエッジを反復的に削除します（フィッシャーの z 検定、Abramowitz-Stegun の CDF 近似）。GESは、貪欲法による前向きのエッジ追加と後ろ向きの削除を行い、各候補 DAG を BIC = n*ln(RSS/n) + k*ln(n) で評価します。NOTEARSは、8次テイラー級数で近似した連続的な非巡回制約として trace(exp(W ∘ W)) - d = 0 を使用して隣接行列を構築します。各グラフを返す前に、トポロジカルソート（カーンのアルゴリズム）で DAG の非巡回性を検証します。

フェーズ3：ドメイン横断グラフの統合と移送エントロピー

ドメインごとのグラフは、すべてのノードとエッジを統合して余極限グラフにまとめられます。ドメイン横断エッジは、異なるドメイングラフのノード間で生の値配列を使用してピアソン相関を計算することで推定されます。しきい値を超えたペアには、データ密度が高いドメインから低いドメインへ向かう有向エッジが設定されます。移送エントロピー行列は、時間差を考慮した相互情報量のカーネル密度推定を使用して、すべてのドメインペアについて計算されます。これにより、構造方程式に依存しない、方向性のある情報フローを示す別個のシグナルが得られます。

フェーズ 4：因果推論の計算

呼び出されたツールに応じて、統合されたグラフが5つの推論手順のいずれかに渡されます。doCalculus はグラフを探索してバックドア調整集合（処置から結果へのすべてのバックドア経路を遮断するノードの集合）を見つけ、調整公式を計算します。該当する集合がない場合は、フロントドア経路を試し、その後に操作変数を試します。scmCounterfactual は各ノードに X_j = sum(beta_ij * X_i) + U_j という形式の構造方程式を割り当て、回帰残差化によってノイズ項 U を推定し（アブダクション）、介入変数を仮説上の値に設定して（アクション）、トポロジカル順に伝播させます（予測）。transportCausalEffect は、ソースグラフとターゲットグラフにおける処置ノードと結果ノードのマルコフ境界を比較し、s-許容性を評価します。bayesianPersuasion は、確率単体上で送信者の価値関数の最も高い凹な下側包絡線を反復的に見つけることで、Kamenica-Gentzkow の凹化を適用します。

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

1. 対象を絞ったクエリでは、ドメインのリストを絞り込みます。 すべてのドメインを対象にすると、18個すべてのアクターにクエリを実行するため、レイテンシとコストが増加します。労働市場に対する経済政策の影響についての質問であれば、["economics", "policy", "labor"] で十分であり、より明瞭な因果グラフが得られます。

2. 特別な理由がない限り、algorithm: "auto" を使用します。 メタアルゴリズムは PC、GES、NOTEARS を BIC で比較し、データの密度に最も適したものを選びます。実行間で再現性が必要な場合や、想定されるグラフ構造についてドメイン知識がある場合に限り、特定のアルゴリズムを指定してください。

3. estimate_interventional_effect を実行する前に、detect_confounders を実行します。 どの交絡因子が存在し、調整可能かを把握すれば、処置効果の推定全体を実行する前にバックドア基準を適用できるかどうかがわかります。交絡因子が調整不可能で、操作変数も利用できない場合、識別はフロントドアに切り替わるか、信頼性が低くなる可能性があります。

4. 統計的な確信度の評価には validate_causal_model を使用します。 faithfulnessHolds: false という結果は、グラフが無効であることを意味するわけではありません。データに、グラフが示唆するもの以外の条件付き独立性が含まれていることを意味し、小さなサンプルではよくあることです。overallValid だけに頼らず、個々の testResults の p 値を確認してください。

5. 反実仮想分析では、interventionValue に現実的な仮説値を設定します。 観測データの範囲から大きく外れた値を使うと、確率スコアの低い外挿されたノイズ推定値が生成されます。処置変数の観測分布における10～90パーセンタイルの範囲内の反実仮想が、最も信頼できます。

6. 能動的な因果学習には、optimize_causal_experiment と discover_cross_domain_causes を組み合わせます。 まず探索を実行してグラフ構造を取得し、次に対象変数を実験オプティマイザーに渡して、次回のデータ収集で測定または介入する変数を特定します。

7. より高品質なグラフを得るには、maxResults を増やします。 各上流アクターは最大 maxResults 件の項目を返します。ノードあたりの観測値が増えるほど、PC における偏相関検定と GES における BIC スコアリングの統計的検出力が高まります。デフォルトの15～20は控えめな設定です。研究レベルの結果を得るには、50に設定してください。

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

アクター	組み合わせ方
Company Deep Research	企業インテリジェンスレポートをドメインデータの入力として渡し、estimate_interventional_effect を使って、どのビジネス要因が財務上の成果を因果的に左右しているかを特定します
Website Tech Stack Detector	企業間のテクノロジー導入データセットを構築し、discover_cross_domain_causes を使って、テクノロジーの選択とビジネスパフォーマンスの指標との因果関係を見つけます
Trustpilot Review Analyzer	時系列でセンチメントスコアを抽出し、compute_counterfactual を使って、特定の製品変更がなかった場合のレビュー評価を推定します
B2B Lead Qualifier	30以上のシグナルでリードをスコアリングし、そのシグナルを detect_confounders に渡して、どのリードスコアリング機能が実際に予測力を持ち、どれが企業規模に交絡されているかを特定します
SERP Rank Tracker	検索順位の変化を時系列で追跡し、transport_causal_effect を使って、ある市場で効果があった SEO 施策を別の市場にも適用できるかを検証します
Regulatory Change Tracker	新しい規制データを estimate_interventional_effect のポリシードメイン入力として使い、特定の規制変更が業界指標に及ぼす ATE を推定します

制限事項

• 観測データからの因果発見には、根本的な識別可能性の限界があります。 グラフ内で2つの変数が d 分離同値である場合、外部の仮定や実験データがなければ、条件付き独立性検定ではエッジの方向を特定できません。返される DAG は、マルコフ同値類に属する要素の1つを表します。
• 忠実性の仮定やマルコフ仮定が成り立たない場合があります。 実世界のデータ、特に異質な公開 API から得られるデータでは、忠実性の仮定に違反したり（経路の相殺による余分な独立性）、定常でない分布を持ったりすることがあります。結果に基づいて行動する前に、validate_causal_model で検証してください。
• JSON からの数値特徴量抽出はヒューリスティックです。 上流のアクターは、多数の文字列フィールドやカテゴリフィールドを含む構造化 JSON を返します。特徴量抽出では数値フィールドのみを変換します。PubMed の学術論文抄録など、テキスト主体のデータを扱う領域では、因果グラフが疎になります。
• 移送エントロピーが測定するのは情報の流れであり、必ずしも因果関係ではありません。 2つのドメイン間で移送エントロピーが高い場合、時間的な情報伝達を示しますが、構造的な因果関係の方向を確立するものではありません。これは補完的なシグナルであり、構造グラフに基づく識別の代わりにはなりません。
• 上流アクターの失敗時にはエラーではなく空の配列が返されます。 18個のソースアクターの一部が失敗またはタイムアウトしても、警告なしで部分的なデータから因果グラフが構築されます。レスポンスの graphNodes を確認してください。数が非常に少ない場合、そのドメインでデータ収集に問題が発生しています。
• 変数名の照合には部分文字列検索が使われます。 完全一致が見つからない場合、findClosestNode 関数は部分文字列で照合します。一般的すぎる処置変数名や結果変数名（例：「rate」）は、想定外のノードに一致することがあります。確実に照合するには、ドメイン名を付けた名前や、より具体的な語（例：「employment_rate」、「cpi_inflation」）を使用してください。
• BIC に基づくアルゴリズム選択が最適であるとは限りません。 BIC はモデルの複雑さにペナルティを課しますが、BIC が最良のアルゴリズムが、因果的に正しいとは限りません。サンプルが小さい場合（ノードあたりの観測数が30未満の場合）は、GES や NOTEARS が過剰適合する可能性があるため、algorithm: "pc" を明示的に指定することを検討してください。
• ベイズ説得シミュレーションでは、抽象的な利得行列を使用します。 simulate_causal_agents ツールは、ドメイン全体のデータ密度から事前信念を導き出しますが、送信者と受信者の利得は抽象的にモデル化されています。この結果は、専門家間の意見の不一致を定性的に方向づけて分析するのに最も有用であり、利得を正確に定量化する用途には適していません。

統合

• Zapier — スプレッドシートや CRM に新しいデータが追加されたときに因果発見の実行をトリガーし、後続のワークフローのステップで構造化された結果を受け取ります
• Make — スケジュールに従って estimate_interventional_effect を呼び出し、ATE の結果を Slack や Google スプレッドシートに送る自動リサーチパイプラインを構築します
• Google Sheets — API に触れることなく、反実仮想および処置効果の結果をステークホルダーによる確認用にスプレッドシートへ直接エクスポートします
• Apify API — Python、JavaScript、または HTTP クライアントからプログラムで MCP サーバーを呼び出します。結果は MCP プロトコルのエンベロープ内の構造化 JSON として返されます
• Webhooks — 実行時間の長い因果発見ジョブが完了したときに、完全な結果ペイロードを含む POST 通知を受け取ります
• LangChain / LlamaIndex — MCP ツールを LLM オーケストレーションフレームワークに直接公開します。エージェントは discover_cross_domain_causes を呼び出し、複数ステップのリサーチループで返された因果グラフ構造について推論できます

トラブルシューティング

幅広いクエリにもかかわらず、グラフのノード数が非常に少ない場合。 ほとんどの上流アクターが空の配列を返しています。検索 API に一致しないクエリ語を使用したか、一時的なレート制限が原因です。より広範なクエリ語を試し、指定するドメインを減らしてください。各ドメインの一般的なデータ形式に数値フィールドが含まれていることを確認してください。academia のようにテキスト中心のドメインでは、PubMed の抄録が主なデータソースの場合、グラフは疎になります。

averageTreatmentEffect が予想より大きい、または小さい場合。 ATE は、抽出された数値特徴量に当てはめた線形構造方程式から推定されます。上流データの数値範囲が非常に狭い場合や分散が大きい場合、回帰係数にはそのスケールが反映されます。ATE は、絶対的な現実世界の単位での効果ではなく、データ分布内での相対的な方向性を示す効果として解釈してください。

ドメインが類似しているように見えるのに transportable: false となる場合。 ソースグラフにおける処置ノードのマルコフ境界に、ターゲットドメインの選択ノードである変数が含まれていると、トランスポータビリティは成立しません。つまり、集団間でまさにその変数に違いがあります。ターゲットドメインに対して個別に detect_confounders を実行し、交絡因子のリストを比較すると、s-admissibility が満たされない理由を把握できます。

simulate_causal_agents で convergence: false となる場合。 ベイズ説得ゲームは、反復回数の上限までに安定した均衡に達しませんでした。事前信念がほぼ一様で、利得行列のコントラストが低い場合に起こることがあります。二値の因果的主張であれば、numStates を 2 に増やしてみてください。より単純な凹化問題となり、安定して収束しやすくなります。

ツールが支出上限エラーを返す場合。 Apify アカウントまたは実行設定で構成された、実行あたりの支出上限に達しています。アクターの起動時に maxTotalChargeUsd パラメーターを増やすか、Apify コンソールのアカウントの請求設定で上限を引き上げてください。

責任ある利用

• このサーバーは、米国の連邦データベース、WHO、NOAA、OpenAQ、NVD、FEMA、FDA、学術 API など、一般公開されているデータソースをクエリします。非公開またはアクセス制限のあるソースをスクレイピングすることはありません。
• 観察データから導かれた因果的主張は、政策や臨床上の意思決定に活用する前に、ドメインの専門知識に基づいて検証する必要があります。
• 因果的知見を下流で利用する際、適用される法令や規制を管轄区域内で遵守する責任はユーザーにあります。
• 実験による検証を行わずに、個人に影響を及ぼす重大な意思決定の唯一の根拠として、因果推論の結果を使用しないでください。
• AI を活用した責任ある研究については、Apify プラットフォームのガイドラインを参照してください。

FAQ

クロスドメインの因果発見とは何ですか。また、なぜ 18 個のデータソースが必要なのですか？ 単一ドメイン内での因果発見では、組織の境界を越える関係を見落とします。経済ショックは健康上の結果を引き起こし、気候事象は労働の混乱を引き起こし、サイバーセキュリティインシデントは規制の変更を引き起こします。こうしたクロスドメインの因果経路を特定するには、経済、健康、環境など、複数のドメインから同時にデータを取得する必要があります。18 個のソースアクターが 9 つのドメイングループをカバーすることで、メタアルゴリズムは十分に多様なデータを利用し、信頼性の高いクロスドメイン因果アトラスを構築できます。

因果発見アルゴリズムはどれを使うべきですか？ PC、GES、それとも NOTEARS？ サーバーに BIC スコアに基づいて選択させるには、algorithm: "auto"（デフォルト）を使用してください。選択の目安は次のとおりです。PC は、どの変数間に因果関係があり得るかについて強いドメイン知識があり、疎なグラフを扱う場合に最適です。GES は、中程度の密度のグラフに対応し、ノード数が多い場合は NOTEARS よりも計算が高速です。NOTEARS は、密な連続構造を想定し、組合せ探索ではなく勾配ベースの最適化を行いたい場合に最適です。 このサーバーで因果関係を証明できますか？ 観察データを使って実行する因果発見アルゴリズムでは、因果関係を証明できません。ツールは、忠実性とマルコフ性の仮定のもとで、データと統計的に整合する因果構造の候補を特定します。因果関係を真に確認するには、実験的な介入が必要です。統計的な裏付けを確認するには validate_causal_model を使用し、発見した構造を確認または反証する追試を設計するには optimize_causal_experiment を使用してください。

estimate_interventional_effect は回帰係数とどう違いますか？ 回帰係数は、含めた変数を条件とする関連性を測定します。estimate_interventional_effect は do 計算を使って P(Y|do(X)) を特定します。これは、単にある値で X を観察した場合ではなく、介入によって X をある値に設定したと仮定したときの Y の分布です。重要な違いは、do 計算が回帰に含まれる変数だけでなく、グラフ構造を使って交絡因子を調整する点です。また、バックドア経路の遮断が不可能な場合でも、フロントドア基準や操作変数（IV）基準を使って効果を特定できます。

反実仮想の推定値はどの程度正確ですか？ 正確さは、上流アクターから抽出された数値データの品質、線形構造方程式が真のメカニズムをどの程度近似しているか、そして忠実性の仮定が成り立つかどうかによって異なります。compute_counterfactual の probability フィールドは、推論された外生ノイズのシナリオの妥当性を示します。値が 0.7 を超える場合、反実仮想は観察データと整合しています。0.5 を下回る場合は、仮定した介入が学習データの分布から大きく外れていることを示唆します。

一般的なツール呼び出しにはどのくらい時間がかかりますか？ すべての領域を対象とする呼び出し（9 領域すべてを指定した discover_cross_domain_causes）では、通常 2〜4 分かかります。最大 18 個の上流アクターが並列で起動し、それぞれに 180 秒のタイムアウトが設定されているためです。単一領域の呼び出しや、2〜3 領域を指定した呼び出しは、通常 30〜90 秒で完了します。呼び出しの合間、MCP サーバーは待機モードを維持するため、サーバー自体のコールドスタートによる遅延はありません。

構造変化を検出するために、因果発見を定期的に実行するようスケジュールできますか？ はい。Apify の組み込みスケジューラーを使って、MCP サーバーアクターを毎日、毎週、または任意の間隔で実行できます。連続する実行結果の crossDomainEdges を比較すると、領域間の因果関係が変化したタイミングを検出できます。たとえば、景気後退時に経済と健康の因果関係が強まるタイミングを検出できます。

この 18 のソースからデータを収集して分析することは合法ですか？ 18 個すべての上流データソースは、米国連邦機関（FRED、BLS、Congress、SEC、FEMA、FDA、CPSC、NVD）、国際機関（WHO、IMF）、研究データベース（PubMed、OpenAlex）、環境モニタリングネットワーク（NOAA、OpenAQ）が提供する公開 API です。公開 API の使用は、各ソースの利用規約に準拠しています。ウェブスクレイピングの合法性全般については、Apify のガイドをご覧ください。

これは DoWhy や CausalML など、既存の因果推論ライブラリとどう違いますか？ DoWhy と CausalML は、独自のデータを用意する必要がある Python ライブラリです。Causal Panopticon はデータ収集、特徴量抽出、グラフ構築をエンドツーエンドで処理し、パイプライン全体をあらゆる AI エージェントから呼び出せる MCP ツールとして提供します。これは、AI が自律的にエビデンスを収集し、因果モデルを構築して、実用的な推論結果を返す必要があるエージェント型ワークフロー向けに設計されています。すでに整備済みのデータセットを持ち、細かなプログラム制御を求める研究者向けではありません。

Claude、GPT-4、またはその他の AI モデルで使用できますか？ はい。MCP クライアントに対応している AI モデルであれば、https://causal-panopticon-mcp.apify.actor/mcp でこのサーバーに接続できます。Claude Desktop と Cursor はネイティブで MCP に対応しています。その他のモデルでは、MCP 互換のクライアントライブラリを使用するか、エージェントのツール使用フレームワークから HTTP エンドポイントを直接呼び出してください。 実行中に一部の上流アクターでエラーが発生した場合、どうなりますか？ runActor 関数はすべてのエラーを捕捉して空の配列を返すため、実行は部分的なデータで続行されます。影響を受けたドメインから因果グラフにノードは追加されません。レスポンスの graphNodes を確認してください。指定したドメイン数に対して予想より大幅に少ない場合は、上流アクターのいずれかでエラーが発生した可能性があります。どのアクターでエラーが発生したかは、Apify の実行ログで確認できます。

サーバーは呼び出しの間、データを保持しますか？ いいえ。MCP サーバーは各ツール呼び出しを個別に処理し、因果グラフやデータを呼び出しの間で保持しません。Apify プラットフォームは、デバッグに利用できるよう、アカウント内に実行ごとの実行ログと出力データセットを保存します。これらには Apify コンソールまたは API からアクセスできます。

改善にご協力ください

問題が発生した場合、Apify アカウントで実行の共有を有効にすると、より迅速なデバッグにご協力いただけます。

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

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

サポート

バグを見つけた場合や機能のリクエストがある場合は、このアクターのページにあるIssues タブでイシューを作成してください。カスタムの因果推論ワークフロー、マルチドメインのリサーチパイプライン、またはエンタープライズ連携については、Apify プラットフォームからお問い合わせください。