取引先から届くセキュリティチェックシートに、過去の回答から下書きを作る

処理の起点を決める

SharePointの受付フォルダにファイルが置かれたことを起点にします。営業が受け取ったチェックシートをそこに置く運用にします。

受付の窓口を1つにすることが前提です。 営業が個別にメールで担当者に転送している状態だと、処理が始まりません。この運用の整理は、技術より先に必要です。

入力データを集める

回答台帳の作り方が、この構成の成否を決めます。 過去400件のExcelをそのまま検索対象にしないでください。1行1設問に分解し、次の列を持たせます。

「根拠文書」と「版数」と「有効期限」の3列がないと、この構成は機能しません。 回答だけを検索できても、それが今も正しいかが分からなければ、結局規程を読み直すことになります。

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

設問の抽出： 様式ごとに扱いが違います。

Excelがもっとも多く、かつ扱いが面倒です。 設問が複数シートに分かれている、設問番号が階層になっている（3.2.1）、回答欄が結合セルになっている、といった事情があります。取引先の上位20社の様式に対応すれば、件数の大半が収まります。

検索の準備： 回答台帳と社内規程をインデックスに登録します。

• 回答台帳は1設問1件で登録します
• 社内規程は章立ての単位に分割します。文書まるごと1件にすると、検索で当たっても該当箇所が分かりません

分割した各件について、埋め込み（ベクトル）を作ります。Azure AI Search には、インデックスを作る際に自動でベクトル化する仕組みがあります。

検索の実行： ハイブリッド検索を使います。キーワード検索（BM25）とベクトル検索を並行して実行し、それぞれの上位を統合した結果を、セマンティックランカーで並べ替えます。セマンティックランカーは、統合された結果の上位50件までを意味に基づいて再採点します。

AIへ渡す前に整形する

1. 設問の正規化 … 設問番号、設問文、回答形式（選択式／記述式／添付要求）に分解します。回答形式の判定が重要です。 「はい／いいえ」で答える設問と、300字で説明する設問では、回答案の作り方が違います
2. 設問の分野分類 … アクセス管理、暗号化、ログ、委託先管理、物理セキュリティ、教育、事業継続、個人情報、といった分野に振り分けます。照会先の判定に使います
3. 重複設問の検出 … 1つのチェックシートの中で、同じことを違う言い方で聞いている設問があります。まとめて扱えるようにします
4. 添付要求の抽出 … 「ISMS認証書の写しを添付してください」のように、文書の提出を求める設問を分けます。回答文ではなく、文書の準備が必要です
5. 規程の改定日の突合 … 回答台帳の各行について、根拠文書の現在の版数と照らし、改定されていれば印を付けます

AIに処理させる

検索は検索基盤に任せます。 LLMに全文を読ませて探させるのではなく、ハイブリッド検索とセマンティックランキングで候補を絞ってからLLMに渡します。LLMが受け取る入力を絞らないと、精度が落ち、費用もかかります。

LLMにさせること：

「根拠が見つからない設問に、それらしい回答を作らせない」ことが、この構成でもっとも重要です。

セキュリティチェックシートの設問は、「はい」と答えれば通りやすいという性質があります。LLMに自由に書かせると、「はい、適切に管理しています」という無難な回答が並びます。それが実態と違えば、取引先への虚偽の説明になります。 契約上の表明保証に関わることもあります。

根拠のない設問は、空欄のまま「要照会」に回す設計にしてください。

指示内容を固定する

あなたは、取引先から届いた調査票への回答を支援する担当者です。
検索で得られた過去の回答と社内規程だけを根拠に、回答案を作ってください。

【厳守事項】
- 検索結果に根拠がない設問には、回答を作らないでください。
  answer を null にし、status を "needs_inquiry" として、
  inquiry_to に照会先の候補を入れてください。
  「適切に管理しています」のような、根拠のない一般的な回答を書かないでください。
- すべての回答に、根拠を evidence として必ず記載してください。
  過去回答なら回答台帳のID、規程なら文書名と章節を書いてください。
  根拠を書けない回答は出さないでください。
- 過去の回答をそのまま使ってよいかを判断しないでください。
  根拠文書の版数と、過去回答の日付を freshness に転記するだけにしてください。
  「問題ありません」と書かないでください。
- 自社が実施していない対策について、「実施予定」「検討中」と書かないでください。
  予定の有無はあなたには分かりません。needs_inquiry にしてください。
- 選択式の設問では、選択肢の文言をそのまま使ってください。
  選択肢にない答え方をしないでください。
- 文書の添付を求める設問は、回答文を作らず、
  status を "document_required" として、必要な文書名を挙げてください。
- 同じ調査票の中で矛盾する回答になっている場合は、
  inconsistencies に設問番号の組を入れてください。

【今回の設問】
設問番号: {question_no} / 回答形式: {answer_type}
設問文: {question_text}
選択肢: {options}

【検索で見つかった過去の回答（上位5件）】
{past_answers}

【検索で見つかった社内規程（上位5件）】
{policy_excerpts}

【根拠文書の現在の版数】
{document_versions}

【認証・監査の取得状況と有効期限】
{certifications}

「根拠のない一般的な回答を書かない」の1行が、この構成の安全装置です。 これを書かないと、120問のうち100問が「はい、適切に管理しています」で埋まります。そして担当者は、そのうちどれが根拠に基づくものかを見分けられません。

「過去の回答をそのまま使ってよいかを判断しない」も外せません。 鮮度の判断は、規程の改定内容を読んで行うものです。LLMに「問題ありません」と書かせると、確認が省かれます。

出力形式を固定する

{
  "questionnaire_id": "",
  "answers": [
    {
      "question_no": "",
      "question_text": "",
      "answer_type": "choice | free_text | document",
      "status": "drafted | needs_inquiry | document_required",
      "answer": "",
      "supplement": "",
      "evidence": [
        {
          "type": "past_answer | policy",
          "reference": "",
          "version": "",
          "excerpt": ""
        }
      ],
      "freshness": {
        "policy_revised_after_last_answer": false,
        "last_answered_date": "",
        "current_document_version": "",
        "certification_expiry": ""
      },
      "inquiry_to": "",
      "confidence": "high | medium | low"
    }
  ],
  "inconsistencies": [],
  "documents_to_attach": [],
  "summary": {
    "total_questions": 0,
    "drafted": 0,
    "needs_inquiry": 0,
    "document_required": 0,
    "stale_evidence": 0
  }
}

freshness.policy_revised_after_last_answer が true の回答が、この構成でもっとも注意すべきものです。 過去に回答したあとで根拠の規程が改定されている、という意味です。回答文は出ますが、そのまま使ってはいけません。

summary の数字を最初に見ることで、担当者は作業量を見積もれます。「120問中、90問が案あり、20問が要照会、10問が文書添付」と分かれば、要照会の20問を先に関係部門へ投げてから、90問の確認に入れます。

なお、Claude API には出力をJSONスキーマに沿わせる構造化出力の機能があります（2026-09-15時点ではベータ機能として提供）。設問ごとに同じ形で返させる必要があるため、利用できると安全です。

システムへ連携する

回答台帳への登録は、提出後に行ってください。 案の段階で登録すると、確定していない回答が次回の検索で出てきます。誤った回答が自己増殖します。

取引先の様式への書き戻しは、機械的に行うと崩れます。 結合セル、入力規則、書式が設定されたExcelに値を入れると、様式が壊れることがあります。上位20社の様式については個別に対応し、それ以外は一覧を出して人が転記する運用のほうが確実です。

人が確認する

全設問を担当者が確認します。自動提出はしません。

確認の重さを分けます。

上長の確認も必ず入れてください。 取引先への回答は、自社の対策状況の表明です。誤った回答は、契約上の問題になり得ます。

例外に対処する

記録を残す

• 受領したチェックシートの原本
• 抽出した設問と、抽出できなかった設問
• 回答案と、その根拠・鮮度の判定
• 担当者が修正した回答と、修正前後
• 関係部門への照会と、その回答
• 上長の確認記録
• 提出した最終版と提出日
• 回答台帳への登録内容

「担当者が修正した回答と、修正前後」が資産になります。 「この設問は毎回書き直している」が見えれば、回答台帳の記述を直すべき箇所が分かります。 修正が減っていくことが、この構成が育っている証拠です。

回答台帳に提出先の社名を持つ場合、検索結果には出さない設計にしてください。 「A社にはこう答えた」という情報が、他社への回答を作るときに画面に出る必要はありません。取引先との秘密保持の観点からも、分けておくのが安全です。