LASSIC Media らしくメディア

完成形は根拠と採否理由が分かる候補リスト

AIには、受注実績だけでなく、今回の選定条件と候補資料を渡します。資料にある事実と条件への適合案を返させ、担当者が採否を決める形を提案します。企業・資料・出力はすべて架空の設計例で、AIの実行結果ではありません。公開情報の自動取得は扱いません。

必須条件を「本店が東京都」「機械部品を製造」、除外条件を「既存顧客」とした完成形です。

採用は今回の候補リストに載せる判断であり、購買意向を確認できたという意味ではありません。

受注実績と今回の選定条件を分けて渡す

入力は、次の四つに分けます。

• 受注実績：東京都に本店がある機械部品製造企業から受注した記録。

• 今回の必須条件：本店が東京都で、機械部品を製造していること。

• 除外条件と顧客一覧：既存顧客を除外。架空の社内顧客一覧ではD社のみ該当し、A〜C社は非該当。

• 候補資料：各社の架空の「会社概要」。本店欄と事業内容欄に上表の内容があり、B社の事業内容欄は空欄。C社の拠点欄には東京都内の営業所も記載。

この例では、過去の受注先と同じ属性を狙う方針を別途指定しています。受注実績から選定条件が自動的に決まったわけではありません。

候補一覧・会社概要・顧客一覧には共通の識別記号を付けます。この例のA〜Dは架空の対応記号で、法人番号ではありません。

指示文には対象資料と不明の扱いまで書く

参照する範囲と返却項目を、次のように指示します。

入力した候補資料と顧客一覧だけを使い、指定した必須条件・除外条件と照合してください。企業名、識別情報、条件ごとの記載事実、根拠となる資料名と該当箇所、資料に明記された情報時点、条件への適合案、不明点を表で返してください。記載なし・資料間の相違・基準の曖昧さを区別し、判断できない条件と理由を示してください。相違する記述は両方残し、欠けた情報を推測で補わないでください。担当者が採否と理由を記入する列は空欄にしてください。

資料に情報時点がなければ、その欄も「不明」です。事実と適合案を分け、判断の根拠を追える形にするための指示であり、正確性を保証するものではありません。

事実と適合案を読み分けて採否を決める

A社は共通の識別記号で候補と資料を対応させます。会社概要の本店欄は「東京都」、事業内容欄は「機械部品製造」、顧客一覧では「既存顧客ではない」。この三つが記載事実で、「今回の条件を満たす」が適合案です。

AI事業者ガイドラインでは、人がAIの評価や判断を承認する際、その理由や根拠を人自身が独自に考えてから承認することが提案されています¹。ここでの採用・保留・除外の区分は、本記事の判断提案です。

A社は提示した条件を満たす候補として採用しますが、購買意向や具体的な課題は不明のままです。B社は製造業ではないと確定したわけではなく、必須条件を判定できないため保留。C社は本店条件に合わず、D社は除外条件に当たるため除外します。

誤った候補は原因に合わせて直す

同じ資料からB社とC社を誤って採用した場合を想定します。

B社は事実不足です。「推測しない」と指示を直しても、欠けた事業内容は埋まりません。判断できる資料を追加しない限り、保留を維持します。

C社は照合対象の誤りです。資料には本店と営業所が分けて記載されているので、本店欄を必須条件に対応させ直すと除外になります。資料の不足と照合の誤りを分けることで、どこを直せば採否を判断できるかが分かります。

根拠の場所と情報の時点が追える返却表にする

候補資料から判断する場合は、条件ごとに記載内容・根拠の場所・情報の時点・適合案・不明点を一組にします。以下の返却様式と採否の扱いは、本記事の設計提案です。資料と返却表で同じ識別情報や資料名を使い、担当者が適合案から元の記載へ戻れる形にします。

A社の本店条件について、記入後の形を示します。基本例と同じ架空資料を使っており、新しい情報を加えた例ではありません。

この表で判定しているのは本店条件だけです。候補全体の採否には、事業内容と既存顧客との照合結果も対応させ、担当者の採否と理由を別欄に残します。

ここでいう情報基準日は、記載がいつの状態を示すかを表す日付です。更新日は資料が更新された日、閲覧日は担当者が資料を見た日を指します。閲覧日だけを根拠に、その日の本店所在地だとは判断しません。資料全体の更新日も、個々の記載の情報基準日へ読み替えない扱いにします。

出典URLと閲覧日は、入力に添えられている場合だけ転記します。資料にない日付やURLは補わず、不明の理由を残します。基本例のA社は資料の記載に基づく採用です。現在の所在地まで条件にする場合の扱いは、情報の時点を扱う節で示します。

別法人の根拠は外して同一法人の重複をまとめる

候補と根拠資料の法人番号が異なる場合は、その資料を候補の適合根拠から外します。残る根拠では必須条件を確定できず、別の確実な除外理由もなければ保留です。根拠を取り違えたことと、候補企業が条件に合わないことは分けて判断します。

国税庁がいう基本3情報は、商号又は名称、本店又は主たる事務所の所在地、法人番号です²。この定義を、業種や購買意向の裏付けには使いません。

これらの情報を使う際は、企業名だけで候補と資料を結び付けず、法人番号を対応させ、本店所在地の記載も照合する設計にします。別法人の資料に「機械部品を製造」と書かれていても、それを当該候補の適合根拠には使いません。

同じ法人番号の候補行は一社分にまとめ、各行に付いていた資料名と情報の時点を引き継ぎます。所在地が食い違っている場合も、一方の行と一緒に相違を消さず、資料ごとに比較できる形で残します。候補の重複を解消することと、根拠の食い違いを解消することは別の作業です。

法人番号が資料にない場合は、企業名が同じという理由だけで重複と断定しません。使える識別情報では同一法人と対応付けられず、その資料が必須条件の唯一の根拠なら、別の確実な除外理由がない限り保留にします。

情報の古さは判定したい時点との対応で考える

現在の状態を選定条件にする場合は、資料が古いことだけで候補を除外せず、現在の必須条件を確定できるかで判断します。根拠の対象時点が対応せず条件を確定できないなら、別の確実な除外理由がない限り保留です。

国税庁の全件データは、前月末時点で公表している法人等の最新情報を、全国分又は都道府県・国外の単位別にダウンロードできるものです。新たな法人番号の指定や商号変更などの更新情報は、日別にダウンロードできます³。

全件データの入手日と、そのデータが表す時点は分けて扱います。日別の更新情報が提供されているというだけで、手元の全件データが当日の状態を表すとは扱いません。「最新」とだけ記すのではなく、どの時点の情報から条件を判定したかを残します。

鮮度の基準は一律の日数で決めず、今回の条件がいつの状態を求めているかから考えます。資料間で時点が違う場合も、後から閲覧した資料を優先するのではなく、条件が求める時点を示す記載を根拠にします。

AI事業者ガイドラインは、入力データの正確性や必要な場合の最新性を確保し、出力の精度とリスクを理解し、様々なリスク要因を確認した上で利用することを示しています¹。具体的な返却表や採否の区分は、ガイドラインの指定ではなく本記事の設計提案です。

この提案では、所在地や事業内容の適合案に根拠の対象時点を添えます。時点が分からない場合は不明とし、過去の記載から現在も同じ状態だと推測して埋めません。これにより、記載内容への適合と、現在の条件を判定できるかを分けて扱います。

資料が食い違っても確実な除外理由は使える

必須条件を確定できない候補でも、同一法人と対応付けられた根拠で除外条件への該当が確定していれば、その理由で除外できます。条件ごとの状態と、候補全体の採否を分ける考え方です。

ここからは別の仮定例です。同一候補の資料の一方には「本店は東京都」、もう一方には「本店は大阪府」とあり、どちらが今回の対象時点を示すか判別できないとします。必須条件は「本店が東京都」で、ほかに確実な除外理由はない設定です。

この場合は本店条件を未判定として保留にします。一方の記載だけを選んで採否を決めず、両方の所在地、資料名と箇所、分かる範囲の時点を残します。不明点には「対象時点の本店所在地を確定できない」と記入します。

次に、この仮定例へ条件を加えます。同一法人と対応付けられた顧客一覧に既存顧客と明記され、今回の除外条件が「既存顧客」だったとします。この場合は既存顧客を理由に除外します。本店所在地の相違は解消したことにせず、未判定のまま残します。

返却表には「所在地は未判定、既存顧客のため除外」と記録できます。除外の根拠が確定しているため、すべての不明点が解消するまで採否を待つ必要はありません。ただし、除外理由にした資料も別法人のものなら、その理由は採否の根拠から外します。

基準を直す場面と資料を足す場面を分ける

選定基準が曖昧なら判定対象を定め、必要な資料を入力していないならその資料を加えます。手元の資料自体に必要な事実がなく、別の確実な除外理由もなければ、根拠を追加できるまで保留です。

基準の曖昧さを考える別の仮定例として、条件が「東京の企業」とだけ指定され、資料には大阪府の本店と東京都内の営業所が記載されているとします。

本店が東京都にあることを求めるなら地域条件は不一致、東京都内の営業所があることを求めるなら地域条件は適合です。これは資料の不足ではなく、選定方針が定まっていない状態です。担当者が対象を定めるまでは地域条件を未判定とします。「本店が東京都」と最初から明確だった基本例のC社とは、直す箇所が異なります。

資料不足にも二つの場面があります。別の仮定例として、手元の会社案内には製造品目が書かれているのに、入力には所在地のページしか含めていなかったとします。この場合は製造品目のページを追加し、その記載が今回の条件を満たすかを判定し直します。追加しただけで採用になるわけではありません。

一方、手元の資料のどこにも必要な事業内容が書かれていなければ、資料の渡し方を変えても根拠は増えません。基本例のB社のように、別の確実な除外理由がなければ保留を維持します。

基準と事実が揃っていて、照合を誤っていたなら、条件と資料の該当箇所の対応を直します。基準が曖昧なら判断対象を決め、必要な資料が手元にあるなら入力へ加えます。必要な事実を含む資料がなく、別の確実な除外理由がなければ保留を残します。依頼文を直すだけで判断が変わる場面と、判断材料を追加する場面を分けるのが要点です。

必須条件を変えると同じ資料でも採否が変わる

必須条件を追加した場合は、以前の採用判断をそのまま引き継がず、追加条件の根拠まで揃っているかで判定し直します。追加条件が未判定で、ほかに確実な除外理由がなければ、新しい条件では保留です。

条件変更の仮定例として、東京都本店・機械部品製造で、既存顧客ではないA社に戻ります。元の条件では採用しましたが、新たに購買意向を必須条件へ加えるとします。元の架空資料には購買意向の記載がありません。

変更後は、追加した必須条件を判定できないため、A社も保留にします。元の条件での採用が誤りになったのではなく、採用に必要な根拠が増えた結果です。所在地や事業内容が条件に合うことを、そのまま購買意向の根拠にはしません。

返却表では、それまで判定できていた項目を残し、追加条件だけを未判定として区別します。資料の読み違いを修正したのか、選定方針を変えて再判定したのかも説明できる形になります。

手元の候補整理と新規探索では結果の範囲が違う

手元の候補を整理する場合は、候補一覧・候補ごとの資料・選定基準・除外条件を渡し、入力した候補の範囲で採否を判断します。まだ一覧にない企業を増やす場合は、これらに加えて探索対象の情報源と取得手段が必要です。候補化する範囲も、得られた項目で判定できる条件に限ります。

資料を用意する経路として、国税庁では法人番号の指定を受けた法人等の基本3情報を、CSV形式・XML形式でダウンロードできます。全件データは前月末時点で公表している法人等の最新情報であり、入手当日の状態を示すとは扱いません³。

Gビズインフォでは、法人基本情報・法人活動情報をCSV形式・PDF形式・JSON形式でダウンロードできます⁴。ただし、すべての法人に必要な項目が揃うとは置かず、実際に得られた記載を選定条件へ対応させます。この提供情報から個別企業の購買意向や課題まで確認できたとは扱いません。

今回の「機械部品を製造」という条件は、名称・所在地・法人番号だけで判定せず、製造していることを示す記載を根拠にします。情報源に企業が載っていることと、自社の必須条件を判定できることを分ける設計です。

公開データの提供経路があることは、利用するAIがその情報を自動取得・読み込み・照合できることの根拠にはしません。公開情報の取得機能がない環境では、担当者が用意した資料を、その環境で扱える入力方法に合わせて渡す設計にします。データ提供元の形式を、そのままAIの対応形式として扱わないことも必要です。

新規探索の結果にも、対象にした情報源と、判定できた条件・できなかった条件を残します。探索対象外の企業まで含む網羅性は主張せず、資料だけでは必須条件を判定できない候補を適合扱いにしません。全件データの入手と、自社に適合する営業対象を漏れなく選ぶことは別です。

リストの完成条件は、候補数だけでなく、各社を残す理由、外す理由、判断が止まっている条件を説明できることに置きます。手元の資料で判断できる範囲から始め、新たな候補が必要なら、選定条件を判定するために足りない記載を起点に資料の範囲を広げる形を提案します。

結び

自社へ置き換える起点は、受注企業の特徴をそのまま選定基準にせず、今回狙う条件を明確にすることです。その条件と資料の記載が対応すれば採否を判断でき、対応しなければ不足や誤りの場所が分かります。判断できない条件を推測で埋めず、理由を残した候補リストを目指しましょう。