新規取引先の反社・コンプライアンス確認を、根拠付きで一次調査して記録に残す

処理の起点を決める

取引先の登録申請が提出されたときが起点です。

申請フォーム（Microsoft Forms、Power Apps、基幹システムの申請画面など）の提出をトリガーにします。「契約書を作る前」に確認が終わっている状態にするためです。

半自動化では、次の2つを追加します。

• 定期の再調査： 既存取引先を、契約更新の一定期間前に再度調べる
• 属性の変更時： 代表者や商号が変わったときに、再度調べる

2つ目を必ず入れてください。 代表者が変われば、確認の前提が変わります。取引開始時に調べただけでは足りません。

再調査は月次に分割してください。 全取引先を一度に回すと、年1回の行事になります。取引先を24分割して毎月回せば、2年で一巡し、毎月の負荷が一定になります。

入力データを集める

「社内の確認基準」がこの構成の中核です。

1行に1つの検索の型を持ちます。

この表を法務が作ります。AIに作らせないでください。 何を確認するかは、自社の業種と規程によって決まります。

「該当したときの扱い」の列を必ず作ってください。 ここを「取引不可」と書くと、AIの検索結果だけで取引を止める設計になります。 同名の別会社だった場合に、取り返しがつきません。該当は常に「法務が読む」で止めてください。

データの取得方法を決める

公開情報の検索： Claude API の web search ツールを使います。ツール定義で max_uses を指定すると、1リクエストあたりの検索回数を制限できます。 検索の型が10通りあるなら、max_uses はそれに合わせて設定します。

{
  "type": "web_search_20250305",
  "name": "web_search",
  "max_uses": 12,
  "user_location": {
    "type": "approximate",
    "country": "JP",
    "timezone": "Asia/Tokyo"
  }
}

allowed_domains と blocked_domains は、どちらか一方だけを指定します。 両方を含めると、APIは400エラーを返します。官公庁の公表情報だけを対象にしたい検索では allowed_domains を、逆に信頼できない情報源を外したい検索では blocked_domains を使います。同じリクエストで両方を使い分けたい場合は、リクエストを分けてください。

出典が必ず付くことが、この用途では決定的に重要です。 web search の結果には引用（citations）が常に付き、url・title・cited_text（引用部分は最大150文字）が返ります。この3つをそのまま調査メモに残せば、「何を見てそう書いたか」が後から追えます。

会話を続ける場合は、返ってきた encrypted_content をそのまま次のリクエストに戻す必要があります。 欠けていたり書き換えられていたりすると、400のバリデーションエラーになります。調査メモを段階的に作る設計にする場合は、ここを飛ばさないでください。

社内の確認基準と過去の調査記録： Azure AI Search などの検索基盤に格納し、必要な部分だけを引いてプロンプトに渡します。過去に同じ会社を調べていれば、その結果を先に示します。

法人の実在確認： 国税庁の法人番号公表サイトなど、公的な情報源で商号・所在地・法人番号の一致を確かめてください。 検索エンジンの結果だけで実在を判断しないでください。

AIへ渡す前に整形する

1. 商号の正規化 … 「株式会社」「(株)」「㈱」、前株・後株、旧字体をそろえます
2. 所在地の正規化 … 丁目・番地の表記、ビル名の有無をそろえます
3. 代表者名の正規化 … 姓名の間のスペース、異体字（髙／高、﨑／崎）を扱えるようにします
4. 法人番号の突き合わせ … 法人番号があれば、それを主キーにします
5. 過去の調査記録の照合 … 同一・類似の取引先を過去に調べていないか確認します
6. 既存取引先との照合 … すでに取引がある会社かを確認します

3番目を軽く見ないでください。 異体字の扱いを誤ると、検索しても何も出ないのに「該当なし」と記録されます。 「該当なし」が「調べ方を間違えた結果」である可能性を、設計で潰してください。

4番目が効きます。 法人番号があれば、同名の別法人を機械的に切り分けられます。申請フォームに法人番号の欄を作ってください。

AIに処理させる

AIに次のことをさせないでください。

「反社会的勢力である」と書かせないことが、この構成で最も重要な制約です。 生成AIに「この会社は反社ですか」と聞けば、それらしい答えが返ります。その記録が社内に残り、取引を断る理由に使われれば、事実でなかった場合に会社が責任を負います。 出力は「◯月◯日の記事に、代表者と同姓同名の人物の逮捕の記載がある。出典はこのURL」までにとどめてください。

「問題ありません」と書かせないことも、同じくらい重要です。 調べていない範囲については何も言えません。「調べた条件」と「該当がなかったこと」を書かせてください。

指示内容を固定する

あなたは、新規取引先の一次調査を行う担当者です。
社内の確認基準に定められた検索条件を順に実行し、
該当した記載を出典とともに整理してください。

【厳守事項】
- 取引の可否を判断しないでください。
  「取引可能です」「取引すべきではありません」と書かないでください。
- 対象の会社や人物について「反社会的勢力である」「反社会的勢力と
  関係がある」と断定しないでください。
  該当した記載の内容と出典を示すだけにしてください。
- 「問題ありません」と書かないでください。
  調べた条件を列挙し、該当がなかったことを
  searched_no_hit に記録してください。
- リスクを点数や5段階で評価しないでください。
- 検索結果に現れていない内容を補わないでください。
  あなたの知識から会社の評判や事件を書かないでください。
- 拾った記載には、必ず出典のURLと引用箇所を付けてください。
  出典を付けられない記載は、出力しないでください。
- 検索で見つかった会社が対象の会社と同一かどうかは、
  所在地・代表者名・法人番号の一致で判断してください。
  商号が一致するだけのものは possible_other_entity に入れてください。
  「同一と思われます」と書かないでください。
- 対象の会社の関係者ではない同姓同名の人物の情報を、
  対象の情報として扱わないでください。
- 調べた検索条件は、該当の有無にかかわらず
  すべて searched_conditions に記録してください。

【社内の確認基準】
{screening_criteria}

【対象の取引先】
商号: {company_name}
法人番号: {corporate_number}
所在地: {address}
代表者名: {representative}
事業内容: {business_description}

【過去の調査記録（あれば）】
{past_records}

「問題ありません と書かない」の1行が、この構成の記録としての価値を守ります。 「問題なし」とだけ書かれた記録は、後から見たときに何の証拠にもなりません。

「同姓同名の人物を対象の情報として扱わない」も必ず入れてください。 代表者名での検索は、無関係の人物の事件記事を必ず拾います。

出力形式を固定する

自由文ではなく、固定項目を持つJSONで返させます。

{
  "company_name": "",
  "corporate_number": "",
  "checked_at": "",
  "searched_conditions": [
    {
      "criterion": "",
      "query": "",
      "domain_filter": "",
      "result": "hit | no_hit"
    }
  ],
  "findings": [
    {
      "criterion": "",
      "summary": "",
      "source_url": "",
      "source_title": "",
      "cited_text": "",
      "published_date": "",
      "entity_match": {
        "address_match": false,
        "representative_match": false,
        "corporate_number_match": false
      }
    }
  ],
  "possible_other_entity": [],
  "searched_no_hit": [],
  "existence_check": {
    "source": "",
    "corporate_number_verified": false,
    "address_verified": false
  },
  "past_record_reference": []
}

searched_conditions と searched_no_hit が、この構成でもっとも重要な出力です。 「何を調べて、何が出なかったか」の記録です。該当が1件もなかった調査でも、この2つが埋まっていれば記録として成立します。

findings には必ず source_url と cited_text を持たせます。 出典のない記載は出力させません。web search の引用は最大150文字なので、cited_text はそのまま収まります。

entity_match は、拾った記事が対象の会社のものかを示す3つの真偽値です。 ここが3つとも false の記載は、別会社の話である可能性が高いものです。 findings ではなく possible_other_entity に入れる設計にしてください。

リスクの総合スコアは持たせません。 スコアがあれば、人はスコアだけを見ます。この構成の出力は、法務が読むための材料です。

システムへ連携する

最小構成では連携はありません。担当者が生成AIに確認基準と取引先情報を貼って作業します。

半自動化では、次をつなぎます。

取引先の登録を自動で承認・却下しないでください。 この構成の出力は調査メモです。登録の可否は、法務が判断して人が操作します。

逆に、「確認が終わっていない取引先の契約を止める」仕組みは作ってよい部分です。 確認台帳に記録がない取引先について、契約書の作成に進めないようにするのは自動化に向いています。

人が確認する

取引の可否の判断は、必ず法務が行います。

1番目の「出典を必ず開いて読む」を省かないでください。 要約だけを読んで判断すると、要約が取り違えていた場合に気づけません。 cited_text は150文字です。記事全体の文脈は、開かないと分かりません。

6番目が、この構成の外にある最も重要な工程です。 疑いがある場合、社内だけで判断しないでください。 「企業が反社会的勢力による被害を防止するための指針」は、外部の専門機関との連携を求めています。警察、暴力追放運動推進センター、顧問弁護士への相談経路を、あらかじめ決めておいてください。

例外に対処する

記録を残す

• 調査メモ（searched_conditions と findings を含む全体）
• 実行した検索条件と、該当がなかったこと
• 出典のURL、取得日時、引用箇所
• 法務の判断と、その理由
• 外部の専門機関へ相談した記録
• 確認基準の変更履歴
• 再調査の実施日と結果

「実行した検索条件」の記録が、この構成でもっとも価値のある出力です。 監督官庁の検査や、取引先とのトラブルで「どのように確認したのか」を問われたとき、手順とその実行記録を示せます。

出典の取得日時を必ず残してください。 Webページは消えます。「確認した時点では、このURLにこの記載があった」ことを示せる必要があります。 該当ありの場合は、ページのスクリーンショットまたはPDFを保存してください。

確認基準の変更履歴を残してください。 「いつの時点の基準で確認したか」が分からないと、過去の記録の意味が変わります。

調査メモの保存期間は、契約期間より長く設定してください。 取引終了後に問題が表面化することがあります。