entity-research

エンティティ調査

企業または人物の詳細な背景調査 → 人が読んで行動に移すための出典付きの調査資料。ベンダーの審査、契約前の取引相手の確認、採用候補者やパートナーの調査、メディアの主張の検証など、汎用的な調査に利用します。

調査と情報の取りまとめであり、判定ではありません。 このスキルは、人物をスクリーニング、承認、評価、またはブロックするものではありません。制裁リスト／PEP／ウォッチリストに関するシグナルは、資格を有するコンプライアンス／AML 部門にエスカレーションするためのシグナルであり、判断結果ではありません。ネガティブ報道は、出典と日付を伴う申し立てであり、証明された事実ではありません。すべてに出典を明記し、自動的な措置は行いません。

対象範囲と振り分け

一般的な背景調査と、公開情報に基づく迅速なシグナルの確認には、このスキルを使用します。専門家による CDD／AML スクリーニング、制裁対象の確認、PEP スクリーニング、またはコンプライアンス上の判断の代わりとして使用しないでください。また、個人のプライバシーを侵害するプロフィールを作成しないでください。

使用する場面

• 取引や契約締結の前に、ベンダー／サプライヤー／取引相手を審査する。
• 採用候補者、パートナー、または共同投資家の主要人物について背景を調べる。
• 名前に関するネガティブ／不利な報道や訴訟を確認する。
• 公開制裁リストのシグナルを迅速に確認する（承認ではなく、エスカレーションのため）。
• 公開情報に基づいてPEP 該当の兆候を迅速に確認する（承認ではなく、エスカレーションのため）。
• 「X の実際の所有者／運営者は誰か？」— 所有権と主要な経営陣の背景を調べる。

調査の観点

1. 身元と背景 — 対象のエンティティが正しいことを確認します（登録番号、管轄区域、設立日、ウェブサイト、別名／旧称。人物の場合は、役職、勤務先、所在地、公開されている場合は生年月日）。同名のエンティティは早い段階で区別します。
2. 所有権と主要な経営陣 — 株主／UBO の兆候、取締役、上級管理職、グループ／親会社の構造を確認します。適切な場合は、人物情報や企業情報の調査に people-enrichment スキル／PDL を使用します。
3. 不利な報道／ネガティブ報道 — 不正行為の申し立て、調査、スキャンダル、支払不能、詐欺、環境／労働問題などを調べます。それぞれに出典、日付、申し立てか確定した結果かを明記します。
4. 制裁／PEP／ウォッチリストのシグナル — screen_lists(name) は公開制裁リストのみを確認します（OFAC SDN + Consolidated、英国 OFSI、国連）。PEP 該当の兆候は、公開されている公職、国有企業の上級職、近しい関係者である可能性、公式略歴など、手作業による公開ウェブ情報の調査から得られるシグナルです。いずれも承認を意味しません。
5. 訴訟と規制 — 重要な訴訟、規制当局の措置、罰金、入札参加資格の停止を調べます。
6. 要約と注意事項 — コンプライアンス担当者による確認のためのエスカレーションフラグを含め、簡潔にまとめます。

データソース（単独で使える基本情報源 + 任意の詳細調査）

• オープンウェブ — web_search + web_extract を使って、報道、訴訟、登記情報への言及、所有権の手掛かり、公開情報に基づく PEP 該当の兆候を調べます。
• 詳細調査エンジン — 徹底的に調査する場合は、対象のエンティティと調査の観点を、利用可能であれば詳細調査エンジン／スキルに渡します。利用できない場合は、検索を直接分散して実行します。
• PDL（人物情報／企業情報） — 適切な場合は、所有者／主要な経営陣／企業の情報を調べるために people-enrichment スキルを実行します（PDL_API_KEY が必要です）。
• 公開制裁リスト — scripts/entity_research.py → screen_lists(name) は、政府の公式統合リスト（米国（OFAC SDN + Consolidated）、英国（OFSI）、国連）を取得し、トークン化した名前を照合します。返されるのは一致の可能性を示すシグナルのみです。曖昧一致や音声照合によるスクリーニングではなく、各地域のすべての独自リストを網羅するものでもありません。ある国の独自の制裁措置を確認する場合は、公式ポータルを手動で調べてください。一致はコンプライアンス部門で確認するためのシグナルです。一致しなくても、承認されたことにはなりません。

ワークフロー

1. 対象を特定する — 名前と識別情報（管轄区域、登録番号、ウェブサイト、個人の場合は役職／勤務先）を確認します。調査を始める前に、同姓同名による曖昧さを解消します。
2. 調査を計画する — 対象について、各観点を網羅する3～6個の調査項目に分解します（例：「Xの所有者は誰か？」「Xに対する訴訟はあるか？」「Xは制裁リストに掲載されているか？」）。成功基準を定めます。完全な調査資料には何が含まれるべきでしょうか？この計画によって、優先する観点を決め、調査漏れを防ぎます。
3. 各観点を調査する — 観点ごとにウェブ検索を並行して実行します。個人や企業属性の調査にはPDLを、公開制裁リストの兆候の確認にはscreen_lists()を使用し、PEPの兆候や各地域の制裁リストは公式情報／公開情報を手動で確認します。すべての主張について、出典URLと日付を記録します。
   • 日付の基準（必須）。 検索前に、実際の現在の日付を確認します。「今日の日付は{current date}です。検索クエリには{current year}を使用し、学習データから推測した年は決して使わないでください。」
   • 品質フィルター。 抽出前に、情報量の乏しい、または無関係な検索結果を除外します。ランディングページ、内容のある文章が100語未満のアグリゲーターの簡易ページ、キーワードは一致しても実際には関連性のないページ（部分文字列ではなく、単語境界で対象の名前が一致するかを確認）、重複URLが対象です。
4. 不足を分析する — 最初の調査後、調査結果をステップ2の計画と照らし合わせます。未回答の調査項目はどれでしょうか？情報が不十分な観点はどれでしょうか？不足を埋めるための追加クエリを作成し、2回目の検索を実行します。重大な不足が残る場合は、さらに1回繰り返します（最大3回）。
5. 評価する — 一次／公式情報源 ＞ 信頼できる報道機関 ＞ ブログ／フォーラムの順に重視します。申し立てと結果を区別し、情報の新しさを考慮し、裏付けを確認します（重大な主張には、相互に独立した2件以上の情報源が必要です）。確信度が低い項目にはその旨を明記し、うわさを事実として扱わないでください。
6. まとめる — dossier(...)で、出典を明記したMarkdownの調査資料（6つの観点、「判断ではない」というヘッダー、エスカレーションのフラグ）を作成します。チャットに送信するか、.mdとして保存します。
7. エスカレーションのフラグを付ける — 制裁リストの兆候、PEPの兆候、重大な否定的所見、または誠実性に関する懸念があれば、**「コンプライアンス／AMLのレビュアーにエスカレーション」**と明示します。

調査対象と検索クエリのパターンについてはreferences/research-lenses.mdを、兆候と判断の区別、誤検知、プライバシー保護のガードレールについてはreferences/boundaries-and-sanctions.mdを参照してください。

出力パターン

否定的な所見、訴訟、規制に関する所見には、簡潔な表を使用することを推奨します。

項目	出典	日付	申し立て／訴因／結果	確信度	エスカレーション要否

制裁リスト／PEP／監視リストの兆候について、「問題なし」や「ブロック済み」とは決して書かないでください。次のような表現を使用します。

• screen_lists()による公開制裁リストの確認では、[date]時点でOFAC SDN/Consolidated、UK OFSI、UNに潜在的な一致は見つかりませんでした。これはクリアランスを意味するものではありません。各地域のリストの確認および専門家によるスクリーニングは、このヘルパーの対象外です。
• "[matched name]"（[list]、スコア[x]）に制裁リスト上の名前が一致する可能性があります — コンプライアンス／AMLのレビュアーにエスカレーションして確認してください。
• 公開情報からPEPの兆候を確認：[source, date]に基づく[公職／国有企業での役職／近親者・関係者に関する兆候] — コンプライアンスレビューにエスカレーションしてください。これはPEPスクリーニングによる判定ではありません。

境界と安全性

• 調査であり、判定／クリアランスではありません。 制裁リストまたは PEP のシグナルがあればエスカレーションします。「問題なし」と判定したり、ブロックしたりしてはいけません。一致しないことは、問題がないことを意味しません。
• PEP に関する明確化。 screen_lists() は PEP スクリーナーではありません。PEP の兆候は公開情報源の調査から得られるものであり、資格を有するコンプライアンス部門による確認が必要です。
• 疑惑と事実。 否定的な情報にはすべて出典と日付を付け、疑惑、起訴、結果を区別してください。名誉を毀損するような表現を避け、出典を明記して、情報源が述べている内容を報告してください。
• 個人 — 正当な目的と公開情報のみ。 個人の調査は正当な目的（審査）のために限り、公開されている情報のみを対象としてください。センシティブな個人データ（健康、信条、性的指向など）を収集したり、プライバシーを侵害するプロファイルを作成したりしないでください。
• 調査資料は人間が確認するための草案です — 自動的な措置の根拠にしてはいけません。

原則

• 助言ではなく草案 — 調査資料は、人が読んで対応するための調査補助資料です。
• 決して捏造しない — すべての主張に出典と日付を付け、根拠が薄い、または裏付けのない情報にはその旨を示してください。
• 判定ではなくシグナル — 制裁リスト／PEP／監視リストのシグナルはエスカレーションにつなげます。「問題なし」と判定したり、ブロックしたりしてはいけません。
• 誠実さと適切な確度 — 疑惑と結果を区別し、矛盾する情報を提示して、確信度を明記してください。
• ワークスペースの衛生管理 — 調査資料はローカルに保管してください。内部資料であり、個人名が含まれる場合があります。

データの取り扱い — 関係性ではなく名前を検索する

関係性を付記しない名前だけであれば、オープンウェブで調査して問題ありません。ただし、次の点を守ってください。

• 検索の文脈を決して漏らさないでください。 「[entity]」を検索し、「[entity]に投資を検討している」や「[entity]は当社の顧客」といった検索は避けてください。取引先や顧客との関係を外部の検索クエリに含めないでください。
• 対象が進行中の取引または顧客と関係している場合、その関係は機密情報です（検索クエリから省いてください）。名前に関する公開情報の調査は引き続き行います。
• 調査資料はローカルマシンに保管してください。個人名が含まれる場合があります。

ファイル

• scripts/entity_research.py — screen_lists（公開制裁リストの名前一致シグナル。キャッシュ対応、正常なフォールバックあり）、dossier（出典付きの Markdown 調査資料とエスカレーションフラグを作成）、名前の正規化／引用ヘルパー。--self-test（オフラインで実行。照合機能と調査資料をテスト）。
• references/research-lenses.md — 観点ごとのチェックリスト、適切な検索クエリのパターン、情報源の重み付け。
• references/boundaries-and-sanctions.md — リスト、判定ではなくシグナルであること、誤検知、エスカレーション、個人のプライバシー保護に関するガードレール。

検証チェックリスト

• 対象を特定し、同姓同名の曖昧さを解消した（または両方を提示した）。
• 調査計画を作成した（複数の観点にまたがるサブクエスチョンを3～6件、成功基準を定義）。
• 日付の基準を適用した — クエリでは学習データのカットオフ年ではなく、現在の年を使用している。
• 品質フィルターを適用した — 抽出前に、根拠の薄い、無関係な、重複する検索結果を除外した。
• ギャップ分析を実施した — 少なくとも2回検索し、残るギャップを記録した。
• すべての主張に出典 URL と日付を付けた。重大な主張は複数の情報源（2件以上）で裏付けた。
• 疑惑の出典を明記し、結果と区別した。根拠の薄い情報にはその旨を示した。
• screen_lists() は公開制裁リストのシグナルとしてのみ提示した。PEP のスクリーニングやクリアランスとして扱っていない。
• PEP の兆候がある場合、公開情報源から得たものに限り、エスカレーションシグナルとしてのみ提示した。
• 個人の調査を正当な目的と公開情報のみに限定した。
• エスカレーションフラグを明示し、調査資料をローカルに保管した。

要件

• Python 3.8 以降（screen_lists／dossier は標準ライブラリのみ）。
• 調査の各観点に使用するセッションのウェブ検索および取得ツール（同梱されていません）。
• screen_lists（公開リスト）にはネットワーク接続が必要です — --self-test はオフラインで実行できます。
• 任意：PDL_API_KEY と、人物／企業属性情報レイヤー用の people-enrichment スキル。さらに詳細な調査には、ディープリサーチエンジン／スキルも使用できます。