PAP-40-Layer Framework 第22層のアイキャッチ

食い違う複数の資料から結論を出すための統合と裁定の基本

  • URLをコピーしました!

複数の資料が食い違うときは、まず同じ対象と時点について述べているかを確かめます。対象が違えば条件別に整理し、同じ条件で矛盾していれば、版や効力、発行主体を調べて採用する根拠を示します。根拠が揃わない対立は一つの結論へ丸めず、未解決のまま確認責任者へ渡します。

AIに複数資料を渡すと、読みやすい一文にまとめる過程で違いが消えることがあります。両立する内容はつなぎ、両立しない内容は判断が必要な箇所として残します。読みやすさのために、採否が決まっていない主張まで一つにしないようにします。

社内資料と公開資料のように、性格の違う資料が食い違う具体例は「社内資料と公開資料が食い違うときの扱い」で扱います。この記事では、食い違いを統合・裁定する基本の手順を説明します。

目次

統合する前に問いと主張を揃える

たとえば「このサービスの問い合わせ対応は何日か」という問いには、サービス名、プラン、対象窓口、受付条件、対象日が必要です。また、「初回回答まで」と「問題解決まで」は違う指標です。同じ五日という数値でも、何の期間かが違えば、そのまま比較できません。

資料から主張を取り出すときは、数値だけを抜かず、主語、対象、条件、時点、例外を一緒に残します。元のページや節も付けます。後で矛盾が見つかったとき、要約同士を比べるだけでは、どの条件が落ちたかを確認できないためです。

W3CのPROV-DMは、情報の出所や派生などの関係を記述するためのモデルです。一次資料についても、何を知りたいかとの関係や分野の慣行が重要であると説明しています。出所を追えることは判断の材料になりますが、公式資料や一次資料であることだけで、すべての主張が正しいと保証されるわけではありません。PROV-DM §5.2.4

実務では、まず「資料名・版・対象・適用時点・主張・根拠箇所」の小さな対照表を作ると、食い違いの位置を絞れます。この表は、資料の関係を確認するための作業案であり、標準仕様が定める採否の採点表ではありません。

条件が違うなら両方を残せる

架空のサービスQについて、2026年10月9日時点の初回回答の目安を案内する場面を考えます。次の二資料はいずれも発行元の正式な案内として確認できたと仮定します。日数は説明用の値で、実在サービスの性能ではありません。

資料 対象・版・適用時点 記載された主張
標準プラン利用案内 標準プラン、第2版、10月1日から適用 初回回答の目安は五営業日
法人プラン利用案内 法人プラン、第3版、10月1日から適用 初回回答の目安は二営業日

この場合、五日と二日の違いだけを見て矛盾と呼ぶ必要はありません。対象プランが違うので、「標準プランは五営業日、法人プランは二営業日が初回回答の目安」と整理できます。質問者が標準プランなら、標準プランの案内をその結論の根拠にします。法人プランの記述を、誤った情報として消す必要もありません。

「目安」という条件も残します。二つの資料を合わせた結果を「必ず五営業日以内に解決する」と書けば、目安を保証へ強め、初回回答を問題解決へ変えてしまいます。統合後の一文が元資料の意味を保つかは、対象の一致とは別に照合します。

プランごとの条件が明確で、改訂履歴にも不整合がなく、案内文の下書きだけを作るなら、二資料の対象を分けた記録で進められます。関係しない契約条項を大量に集めたり、別地域の資料まで同列に並べたりする必要はありません。ただし、今回使う資料の対象と記述の確認は残します。

同じ条件の矛盾は要約で解消しない

今度は、二つ目の資料だけを変えます。サービスQの「標準プランFAQ、第2版」に、「10月1日以降の標準プランの初回回答の目安は二営業日」とあるとします。対象、適用時点、初回回答という指標は一つ目の利用案内と同じです。ところが値は五営業日と二営業日に分かれています。

FAQのページ更新日が新しくても、その日付が対応日数の改定を意味するとは限りません。誤字修正や別項目の追記で更新された可能性があります。改訂履歴、適用通知、資料の位置付けを確認し、どの記述が今回の案内に有効かを調べます。

DCMI Metadata Termsが発行、変更、有効な期間を別の項目で扱うように、日付の意味は区別する必要があります。資料を今日読んだという事実から、今日その条件が施行・適用されたと結論することもできません。DCMI Metadata Terms

確認の結果、FAQが承認済みの変更通知を反映し、利用案内には反映が遅れていると分かれば、その変更の対象と適用日を根拠に採用できます。反対に、FAQの対象欄の誤記だと正式に確認できれば訂正の対象です。いずれも、どちらが新しく見えるかではなく、変更を示す資料と権限者の確認に基づく判断です。

この例では、その追加資料をまだ取得できていないとします。そこで「標準プランは二〜五営業日」「平均すると三・五営業日」とまとめてはいけません。資料にない範囲や平均を作っても、矛盾は解決しないためです。特に範囲表示は、両資料の条件を安全側に統合したように見えて、実際にはどちらにもない案内になります。

採用と保留の理由を短く残す

未解決の状態は、次のように整理できます。

  • 確認できたこと:二資料とも、標準プラン、10月1日以降、初回回答の目安を対象としている
  • 食い違うこと:利用案内は五営業日、FAQは二営業日と記載している
  • 不足していること:対応日数を変更した通知、どちらを現行案内とするかの確認
  • 今回の扱い:顧客向けに一つの日数を確定して案内することを保留する
  • 確認先:サービスの案内内容を管理する責任者

依頼するときは二資料の該当箇所と版を添え、「どちらが正しいですか」だけで終えず、対象条件と適用時点も伝えます。回答を得た後は、その回答が今回の対象へ適用されるかを確認し、採用根拠に加えます。別プランへの回答を、標準プランの対立を解消する根拠にしないようにします。

保留するのは、対立によって決められない主張です。サービスの問い合わせ先など、別の確認済み情報まで一律に削る必要はありません。一方、未解決の日数を前提に利用者へ予定を確約することは避けます。どこまで答えられるかは、不足がその判断にどう影響するかで決めます。

採用しなかった資料も、理由を残します。「誤り」と断定できないなら、「対象プランが異なるため今回の回答には使わない」「対象日は一致するが変更根拠が未確認のため保留」と書き分けます。資料全体への評価と、一つの主張への採否は同じではありません。

検索と人の確認へつなぐ

複数資料の統合には、必要な資料を探す処理、対象時点の版を選ぶ処理、主張と根拠を照合する処理が関わります。検索で上位に出たことは、その資料の効力や適用範囲を保証しません。引用リンクが付いていても、引用箇所と回答の主張が一致しているかは別に確かめます。

W3CのData on the Web Best Practicesは、版識別子や変更履歴を示すことを扱っています。これらが揃えば、どの版がどの変更を含むかを追いやすくなります。ただし、履歴が不完全なら、記載されていない変更がなかったと決め付けず、不足している期間や項目を限定します。Data Versioning

AIには、資料ごとの主張と条件の抽出、対照表、確認質問の下書きを任せられます。対立を解く承認や正式な解釈が必要な場合は、権限を持つ担当者へ引き継ぎます。特に契約や制度など、効力の判断が利用者へ影響する内容では、文書名だけの順位付けで結論を出さないようにします。

比較の記録をすべて長文にする必要はありません。対象と時点、採用した主張と根拠、未解決の点が分かれば、次の確認を進められます。サービスQの例では、条件の違いだけだった段階はプラン別に整理し、同条件の対立になった段階は日数の確定を保留します。確認責任者から回答が届いたら、その記録をもとに該当する日数の説明を更新します。

出典・参考資料

  1. W3C「PROV-DM: The PROV Data Model」(確認日:2026年10月12日)
  2. Dublin Core Metadata Initiative「DCMI Metadata Terms」(確認日:2026年10月12日)
  3. W3C「Data on the Web Best Practices」(確認日:2026年10月12日)
よかったらシェアしてね!
  • URLをコピーしました!

この記事を書いた人

さかっぺのアバター さかっぺ PAP Research運営 / AIガバナンス・アーキテクト / プロンプトデザイナー

ITインフラの実務経験をもとに、AIの安全性と実用性を両立する仕組みを研究。PAP Researchでは、AIモデルの継続観測と、プロンプト・AI技術の実務解説を発信しています。

経歴や研究方法、発信方針は運営者プロフィールで紹介しています。

目次