AIデュー・ディリジェンスのための会社登録データ抽出

TL;DR

• ブラウザ自動化を使用する前に、公式レジストリAPIとボリュームデータセットから開始してください。
• 会社のID、ステータス、役員、提出物、住所、ソースタイムスタンプを共通スキーマに正規化してください。
• CAPTCHAの解決は、認可された公共ポータルアクセスの制御されたフォールバックとして扱い、主な収集方法としては扱わないでください。
• AI生成のリスク結論の前に、エンティティマッチング、出典、新鮮度スコアリング、および人間のレビューを追加してください。
• 各レジストリの利用規約、レートリミット、ライセンス、プライバールールに従い、個人データを最小限に保つようにしてください。

イントロダクション

会社登録データの抽出は、記録が現在のもので、管轄をまたいで追跡可能で、正規化されている場合にのみAIによる適格性調査に役立ちます。最適なアーキテクチャはAPIを最優先にします。公式レジストリにクエリを送信し、ソースの応答を保持し、フィールドを共有される会社スキーマにマップし、適切なAPIまたはエクスポートが存在しない場合にのみブラウザ自動化を使用してください。CAPTCHAチャレンジは、公開ポータルワークフローを妨げる可能性がありますが、厳格な認証、レートリミット、データ最小化制御を備えた監査可能な復元レイヤーを通じて処理する必要があります。このガイドでは、そのパイプラインの構築方法、ソース選定、ID解決、構造化されたPythonの例、証拠の保存、変更のモニタリング、および安全なCapSolverの統合を紹介します。その結果、モデルがサポートされていない法的またはリスク判断を下さずに、ベンダーのオンボーディング、相手先のスクリーニング、ポートフォリオのモニタリング、およびリサーチエージェントをサポートできます。

AIエージェントが収集すべき会社登録データは何ですか？

役立つ記録は単なる会社名以上です。類似した名前のエンティティを区別し、すべての結論を説明する十分な安定した識別子と出典が必要です。

from dataclasses import dataclass, field
from datetime import datetime

@dataclass
class CompanyRecord:
    jurisdiction: str
    registry_company_id: str
    legal_name: str
    previous_names: list[str] = field(default_factory=list)
    company_status: str | None = None
    incorporation_date: str | None = None
    legal_form: str | None = None
    registered_address: dict | None = None
    officers: list[dict] = field(default_factory=list)
    filing_history: list[dict] = field(default_factory=list)
    industry_codes: list[str] = field(default_factory=list)
    source_url: str | None = None
    collected_at: str = field(default_factory=lambda: datetime.utcnow().isoformat())

コアフィールドは管轄によって異なりますが、記録は常に公式の会社識別子、ソース管轄、ソースURL、収集タイムスタンプを保持する必要があります。CapSolverのウェブスクレイピングFAQは信頼性の高い公開データ収集の一般的なガイドラインを提供し、CapSolverのオートメーションブログはワークフロー設計についてカバーしています。

ブラウザ自動化よりも公式APIを使用してください

公式APIは安定したスキーマ、明確なライセンス、予測可能なレートリミットを提供します。例えば、UK Companies House APIはリアルタイムの会社情報を利用可能にし、SEC EDGAR APIsは米国の提出物と提出データを公開します。EU e-JusticeビジネスレジスターのポータルはBRISを通じた国際的なレジスターへのアクセスについて説明しています。

信頼できるAI適格性調査ワークフローは、各フィールドがどのソースパスによって生成されたかを記録する必要があります。出典なしでアグリゲーターの値と公式記録を静かにマージしてはなりません。

Companies Houseから会社プロファイルを抽出する

以下のAPI最優先の例では、文書化されたCompanies Houseの会社プロファイルエンドポイントを使用します。APIキーはプロンプトやソースコードの外に保存してください。

import os
import requests

COMPANIES_HOUSE_KEY = os.environ["COMPANIES_HOUSE_API_KEY"]


def fetch_uk_company(company_number: str) -> dict:
    url = (
        "https://api.company-information.service.gov.uk/"
        f"company/{company_number}"
    )
    response = requests.get(
        url,
        auth=(COMPANIES_HOUSE_KEY, ""),
        timeout=30,
        headers={"Accept": "application/json"},
    )
    response.raise_for_status()
    raw = response.json()

    return {
        "jurisdiction": "GB",
        "registry_company_id": raw["company_number"],
        "legal_name": raw["company_name"],
        "company_status": raw.get("company_status"),
        "incorporation_date": raw.get("date_of_creation"),
        "legal_form": raw.get("type"),
        "registered_address": raw.get("registered_office_address"),
        "industry_codes": raw.get("sic_codes", []),
        "source_url": url,
    }

オフィサー、提出履歴、破産、重要な所有権を持つ人物のフィールドが必要な場合にのみ、文書化されたエンドポイントを使用してください。デフォルトで全体的なプロファイルを収集しないでください。Companies House register guidanceは、公開レジスターと検索ポリシーについて説明しています。

管轄をまたいで記録を正規化する

レジスターの用語は異なります。あるソースは「アクティブ」、別のソースは「登録済み」、別のソースは管轄固有のラベルを使用します。元の値を保持し、小さな正規化された語彙にマップしてください。

STATUS_MAP = {
    "active": "active",
    "registered": "active",
    "dissolved": "inactive",
    "liquidation": "distress",
    "administration": "distress",
    "converted-closed": "inactive",
}


def normalize_status(raw_status: str | None) -> dict:
    raw = (raw_status or "unknown").strip().lower()
    return {
        "raw_status": raw_status,
        "normalized_status": STATUS_MAP.get(raw, "other"),
    }

正規化はソースラベルを破棄してはなりません。AIエージェントは、不確実性を説明し、レジスター用語の変更に対応するために元の証拠が必要です。

CapSolver Pythonスクレイピングガイドは実用的な収集パターンを提供し、CapSolverの用語集はチームがオートメーション用語を標準化するのを助けます。

リスク分析の前にエンティティ解決を追加する

名前だけでは信頼できません。安定した識別子と補強される属性でエンティティを解決してください。

from difflib import SequenceMatcher


def entity_match_score(query: dict, candidate: dict) -> float:
    score = 0.0

    if query.get("registry_company_id") == candidate.get("registry_company_id"):
        score += 0.60

    name_a = (query.get("legal_name") or "").lower()
    name_b = (candidate.get("legal_name") or "").lower()
    score += 0.25 * SequenceMatcher(None, name_a, name_b).ratio()

    if query.get("postal_code") and (
        query["postal_code"] == candidate.get("postal_code")
    ):
        score += 0.15

    return round(min(score, 1.0), 3)

保守的な信頼度のしきい値以下の場合は、人間のレビューを要請してください。AIエージェントはマッチング証拠を要約するべきであり、名前が類似しているだけで2つのエンティティが同一であると宣言してはなりません。

公開レジスターのポータルがCAPTCHAチャレンジを提示する場合

一部のレジスターは、公開ポータルを通じてフィールドを公開するか、繰り返し検索後にトラフィック検証を追加します。利用規約が自動化を許可し、組織がワークフローを承認した場合にのみブラウザフォールバックを使用してください。

ユーザー提供のCapSolver Agentドキュメンテーションではsolve_on_pageがコアブラウザメソッドにマッピングされています。したがって、制御されたPlaywright復元ステップはモデルの自由な推論の外に残ることができます：

from capsolver_core import Capsolver

cap = Capsolver(api_key=os.environ["CAPSOLVER_API_KEY"])

async def recover_authorized_registry_page(page):
    detected = await cap.detect(page)
    if not detected:
        return {"solved": False, "reason": "No supported challenge detected"}

    result = await cap.solve_on_page(page)
    return {
        "solved": True,
        "result": result,
    }

ブラウザを同じセッションに保ち、制限付きリトライルールを適用してください。CapSolver CAPTCHA解決FAQは一般的なライフサイクルを説明し、CapSolverのウェブスクレイピング中のCAPTCHA処理に関する記事は実用的な復元パターンについて議論しています。

ボーナスコード: CapSolverダッシュボードでコード WEBS を使用すると、毎回リチャージで追加の5%のボーナスを獲得できます。

適格性調査証拠パッケージを構築する

AIエージェントは制限のないロウページではなく、証拠パッケージを受け取るべきです。正規化されたフィールド、ソーススナップショットまたはハッシュ、タイムスタンプ、明示的なデータ品質の警告を含めてください。

import hashlib
import json
from datetime import datetime, timezone


def build_evidence_package(record: dict, raw_response: dict) -> dict:
    raw_json = json.dumps(raw_response, sort_keys=True).encode("utf-8")
    return {
        "record": record,
        "provenance": {
            "source_url": record["source_url"],
            "collected_at": datetime.now(timezone.utc).isoformat(),
            "raw_sha256": hashlib.sha256(raw_json).hexdigest(),
        },
        "warnings": [
            "レジスター情報は会社によって提出される可能性があり、独立した検証が必要です。",
            "人間のレビューなしでは法的または投資判断をしてはなりません。",
        ],
    }

これは特に重要です。レジスターが事実を公開しても、その事実が現在のもので、完全で、独立して検証されたものであることを証明するものではありません。AI出力は「レジスターによって報告された」ことと「適格性調査によって確認された」ことを区別する必要があります。

全てを再スクレイピングする代わりに変更をモニタリングする

公式のWebhookやストリーミング製品が存在する場合はイベント駆動のチェックを使用してください。それ以外の場合は、正規化されたフィールドのハッシュを計算し、リスクに基づいたスケジュールで再取得してください。

MONITORING_INTERVALS = {
    "high_risk_counterparty": "daily",
    "active_vendor": "weekly",
    "prospect": "monthly",
    "archived_relationship": "quarterly",
}

会社のステータス、登録事務所、取締役、有益所有権の提出、遅延した会計、破産の指標などの意味のある変更を追跡してください。フォーマットのみの変更によるアラートは生成しないでください。

治理とコンプライアンスの制御

会社登録データの抽出は、ソースのライセンス、利用規約、プライバールール、目的の制限を尊重する必要があります。たとえ公開レジスターであっても、役員や有益所有者の個人情報が含まれている可能性があります。承認された適格性調査プロセスに必要なもののみを収集し、保持期間を強制し、下流のモデルアクセスを制限してください。

UK ICOデータ保護原則は、法的根拠、最小化、正確性、保存制限、セキュリティに関するフレームワークとして役立ちます。

結論

AI適格性調査のための会社登録データ抽出は、出典を最優先にしたデータパイプラインとして最も効果的です。可能な限り公式APIとボリュームデータセットを使用し、元の値を破棄せずに正規化し、エンティティを慎重に解決し、モデルに証拠を提供するようにしてください。認可された公開ポータルがサポートされるCAPTCHAチャレンジを提示した場合、CapSolverはパイプラインの他の部分を変更することなく、狭く制御された復元レイヤーとして機能できます。

ステージングワークフローでCapSolverをテストし、本番使用前にソースライセンス、プライバーレビュー、レートリミット、人間の承認を追加してください。

FAQ

会社登録データは常に公開されていますか？

いいえ。利用可能性は管轄、記録タイプ、アクセスポリシーによって異なります。一部のレジスターは基本的な会社情報を公開していますが、個人情報、有益所有権、歴史的データ、または文書データは制限されています。

APIが提供されている場合でもレジスターをスクレイピングすべきですか？

まず公式APIまたはボリュームデータセットを使用してください。構造化されたアクセスが利用できない許可されたフィールドに対しては、ブラウザ自動化をフォールバックとして使用してください。

AIエージェントは会社のリスクを決定できますか？

エージェントは証拠を要約し、不一致をフラグ付けできますが、重要な法的、コンプライアンス、貸出、調達、または投資決定は、検証されたルールと資格を持つ人間のレビューに残すべきです。

会社記録はどのくらいの頻度で更新すべきですか？

リスクに基づいたスケジュールを使用してください。高リスクの相手先は毎日チェックする必要がありますが、低リスクまたは非アクティブな関係は毎月または四半期ごとに更新すればよいです。

CapSolverはパイプラインでどの役割を果たしますか？

CapSolverは、認可された公開ポータルがサポートされるチャレンジを提示した場合にのみ関係があります。公式API、権限、IDコントロール、コンプライアンスレビューを置き換えてはなりません。