提携・出資の検討先について、公開情報を集めて比較できる形にそろえる

処理の起点を決める

半自動の段階では、候補表の行を選んで人が実行します。 検討は経営会議の日程で動くので、常時監視は要りません。

本格構成では週1回の定時実行を足します。 n8n の Schedule Trigger は Trigger Interval を選ぶ形で、Weeks Between Triggers、Trigger on Weekdays、Trigger at Hour、Trigger at Minute を指定できます。Custom (Cron) も使えますが、n8n のクーロンは6桁で、6番目が秒を表します。

タイムゾーンは必ずワークフロー側で指定してください。 適用はワークフロー個別のものが先、次にインスタンスのもので、既定はセルフホストで America/New_York、Cloud で GMT とされています。実行漏れには Options の If Execution Is Missed と Missed Execution Grace Period (Seconds) を使います。

入力データを集める

質を決めるのは下から2番目です。 「規模」が従業員数なのか売上なのか拠点数なのかを決めていないと、会社ごとに違う値が入り、列としては並んでいても比べられません。 定義表には、値の単位とどの時点の値かまで書きます。案件コードは、以降の処理で社名の代わりに使います。

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

順番が決まっています。会社の特定が先、10項目の調査が後です。

web_search と web_fetch は、この順でしか動きません。 web_fetch は会話にあらかじめ現れたURLしか取得できず、Claude自身の出力にだけあるURLは url_not_in_prior_context になります。

web_search は引用が常に有効で、url、title、cited_text（最大150文字）が付きます。web_fetch の引用は既定で無効なので、"citations": {"enabled": true} を指定します。 長いページは max_content_tokens で切られ、キャッシュを避けるときは use_cache を false にします。

AIへ渡す前に整形する

1. 手がかりの正規化 … 全角と半角、「株式会社」の前後、旧社名の併記をそろえる
2. 法人番号での固定 … 1社に決まらなければ、候補の一覧を返して止める
3. 過去の調査記録の照合 … 法人番号で検索基盤を引き、前回の値と公表日を渡す
4. 巡回範囲の指定 … allowed_domains か blocked_domains のどちらか一方を渡す
5. URLの長さの確認 … 250文字を超えると url_too_long になる
6. 取得日の固定 … その実行の日付を1つ決め、全項目に同じ取得日を付ける
7. 案件コードへの置き換え … ファイル名、ログ、通知から社名を外す

2番目を飛ばさないでください。 止まるのは月10件のうち1件か2件ですが、その1件を通すと、150分かけて別会社の資料を作ります。 6番目で取得日をそろえるのも同じ理由です。

AIに処理させる

させるのは、10項目について「公開情報に書かれているか」を調べ、値と根拠と出どころを書き出すことだけです。

項目ごとに status を1つ付けさせます。 found ／ not_found ／ conflicting の3つです。not_found を選べる形にしておくことが、この構成の要です。

下から2行目が、いちばん起きやすい失敗です。 「この規模なら従業員は50名程度と見られる」という文が入ると、出どころの無い記述が比較表に載ります。

指示内容を固定する

あなたは経営企画部門で、提携や出資の検討先について公開情報を集める立場です。
下の1社について10項目を1項目ずつ調べ、事実と出どころのURLを書き出してください。

【調べる会社】
商号: {name} ／ 本店所在地: {address}
法人番号: {corporate_number} ／ 代表者名: {representative}
この4つがすべて一致する会社の情報だけを使い、
一致を確かめられない情報は捨ててください。

【調べる10項目】
business ／ scale ／ history ／ customers ／ shareholders ／
financials ／ licenses ／ litigation ／ patents ／ hiring
定義は {item_defs} に従い、公表されている範囲に限ってください。

【status の選び方】
- found ... 出どころを特定でき、値が書ける
- not_found ... 探したが、公開情報に見当たらない
- conflicting ... 出どころで値が食い違い、1つに決められない
迷ったときに found を選ばないでください。

【厳守事項】
- 項目ごとに、実際に開いたページのURLを source_url に入れてください。
  出どころを書けない事実は、書かないでください。
- 見つからなかった項目は not_found にしてください。
  業界の一般論や、似た会社の値で埋めないでください。
- published_on にはページに書かれた公表日を入れ、無ければ null にしてください。
  取得日で代用しないでください。retrieved_on には実行日 {run_date} を入れます。
- evidence には根拠にしたページ上の文をそのまま写し、要約しないでください。
- conflicting のときは食い違う値と出どころを両方 note に書き、
  どちらが正しいかを決めないでください。
- 点数、順位、評価、「提携すべきか」の結論、与信の判断、
  反社会的勢力に当たるかの判断を書かないでください。
- 渡されたドメインの一覧にないページ、会員登録が要るページ、
  有料記事の本文を開いたり再現したりしないでください。
- ページが読めなかった項目は not_found にせず、note に「本文を取得できず」と書いてください。

【過去に調べた記録】{past_records}
【実行日】{run_date}

「一致を確かめられない情報は捨てる」を明記しないと拾います。 社名だけが一致する記事は検索で上位に出るので、何も言わなければ出どころとして書きます。

「取得日で代用しない」を書いているのは、埋めたくなるからです。 公表日の欄を空にするのを避けようとして取得日を写すと、古い情報が新しい情報に見えます。 厳守事項の末尾で「読めなかった」を分けているのも同じで、混ぜると、見に行けば分かる項目を「確認できず」として会議に出します。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "case_code": "",
  "company": {
    "name": "", "address": "", "corporate_number": "", "representative": "",
    "identified_by": "houjin_bangou | manual | unresolved"
  },
  "run_date": "2026-09-28",
  "items": [
    { "key": "business", "status": "found | not_found | conflicting",
      "value": "", "evidence": "", "source_url": "",
      "published_on": null, "retrieved_on": "2026-09-28", "note": "" }
  ]
}

items にはこの形の要素を10個並べます。key はプロンプトに挙げた10項目の英字名です。

形はスキーマで縛れます。 構造化出力は output_config.format に {"type": "json_schema", "schema": ...} を渡す形で、すべてのオブジェクトに additionalProperties: false が必要です。 status は enum で3つに限り、published_on は anyOf で date の文字列と null のどちらかにします。

縛れないこともあります。 pattern などは使えず法人番号が13桁かは確かめられませんし、minItems は0と1しか使えないので「10項目ちょうど」も表せません。どちらも n8n で数えます。

この形にする理由は、status と比較表の見え方を切り離せることです。 「確認できず」と表示するかは比較表側の話で、記録には not_found が残ります。古いかどうかを決めるのもワークフローです。

システムへ連携する

候補表へは書き戻しません。 入口にAIの出力を混ぜると、次の実行の入力が汚れます。比較表には、値だけでなく出どころと2つの日付も同じ行に入れます。 離れた瞬間に、第3章の（b）が戻ってきます。

人が確認する

人は全項目を読み直します。ここは減らしません。

1. 会社の特定を確かめる … 商号・本店所在地・代表者名が候補表と合っているかを見る
2. found の項目を、出どころを開いて確かめる … evidence の文がそのページにあるかを見る
3. published_on を見る … 古い値を、古いと分かる形で残す
4. conflicting を裁く … 両方を読み、どちらを載せるかを人が決める
5. not_found の扱いを決める … 調べ直すか、「確認できず」のまま会議に出すかを決める

2番目に、この構成でいちばん長い時間を置いています。 10項目を開いて突き合わせる作業で、1社あたり36分です。ここを縮めると、出どころが付いているだけの資料になります。

例外に対処する

Error Trigger は失敗を知るための仕掛けです。 自動実行のワークフローが失敗したときだけ動き、手動実行では動かないので手元では試せません。 使うには元のワークフローの設定でエラーワークフローを指定します。受け取れる execution.error.message と execution.lastNodeExecuted で、どのノードで止まったかが分かります。

記録を残す

• 候補表の1行と、実行日
• 会社の特定の結果と、候補が複数出たときはその一覧
• エージェントが返したJSONの全文（10項目の value ／ evidence ／ source_url ／ 2つの日付）
• 人が読み直して直した記録 … どの項目を、何から何に変えたか
• 比較表の確定版と、経営会議に出した日
• 項目ごとの not_found の発生率

4つ目を必ず残してください。 人が直す項目が毎回同じなら、項目の定義表が足りないか、巡回の範囲が狭すぎます。 記録が無いと、どちらか分かりません。最後の行は、公開情報からは取れない列を見つけるために使います。