取引先から届くサステナビリティ・人権の調査票に、過去の回答から回答案を作る

処理の起点を決める

調査票が受付フォルダに保存されたときを起点にします。SharePoint の受付フォルダを Power Automate の「ファイルが作成されたとき」で監視します。

届く経路は、取引先からのメール添付、取引先のWebポータルからの通知、業界団体からの一斉配信の3つです。経路ごとに自動化しようとせず、受付フォルダという入口を1つ作るほうが確実です。 メールの添付を自動保存する作りにもできますが、見積書や図面が大量に混ざります。最初は人が受付フォルダへ置く運用から始めます。

保存のときに、提出期限と提出先を入力させます。 期限から逆算して、担当部署への確認依頼の締切（期限の7日前）と部門長の承認依頼の締切（3日前）を自動で置きます。この逆算が無いと、期限の前日に「未確認が30問あります」と分かることになります。

入力データを集める

回答台帳に「承認者」と「根拠資料」の列を必ず持たせてください。 この2列が無いと、出どころが「いつ、どこへ出したか」までしか書けません。確認する人が知りたいのは「誰が責任を持って出した回答なのか」です。

実績値台帳を作ることが、この構成でいちばん手間のかかる部分です。 排出量は環境安全部の集計表、残業時間は勤怠システム、外国人労働者の人数は人事の名簿、と今はばらばらの場所にあります。1枚の表にまとめ、各部署が四半期ごとに書き込む運用へ変えます。 言い換え表も要ります。Azure AI Search では、フィールドにシノニムマップを割り当ててセマンティック構成に含めると、再ランクの処理でも設定したシノニムが自動で適用されると公式の説明にあります。

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

Excelの調査票： Power Automate の Excel のコネクタで読みます。ただし取引先が作ったExcelは「テーブル」として定義されていないことがほとんどで、記入欄のセル位置が様式ごとに違います。シートの範囲をそのまま読み取り、シート名とセル番地を必ず保持してください。 回答を同じセルへ戻すために要ります。

PDFの調査票： OpenAI API にファイルとして渡します。公式の説明では、コンテンツの配列に type: "input_file" を指定し、file_id（Files API でアップロード）、file_data（base64。filename も要る）、file_url の3つの方法があります。1ファイル50MB未満、合計も50MBまでです。 視覚に対応したモデルには、抽出したテキストとページの画像の両方が渡されます。テキストだけを抜き出すと設問と記入欄の対応が崩れるため、表の形をした調査票にはこの渡し方が向いています。

回答台帳と社内資料： Azure AI Search の1つのインデックスに入れ、type のフィールドで「過去回答」と「社内資料」を分けます。検索は両方まとめて実行します。 過去回答が無くても、社内資料に根拠がある設問はあるためです。

インデックスのフィールドは、セマンティック構成に合わせて3層に分けます。公式の説明では、要約のモデルは「title」「keywords」「content」から入力を組み立て、title は128トークン、keywords は128トークン、content は残りのトークンという上限が置かれています。title には設問の要旨、keywords にはカテゴリ名と言い換え表の語、content には設問文と回答本文を入れます。上限を超えた内容は無視されるため、1レコード＝1設問＋1回答を基本にします。

AIへ渡す前に整形する

1. 設問の切り出し … 設問番号、設問文、選択肢、字数制限、記入欄の位置（シート名とセル番地、またはページ番号）を取り出します。枝番は親子の関係で持ちます
2. 設問の正規化 … 全角と半角のそろえ、改行の除去、注記の分離を行います。表示用には原文を残します
3. カテゴリの判定 … 12の区分に分けます。労働時間と賃金／強制労働と児童労働／外国人労働者／安全衛生／差別とハラスメント／化学物質／温室効果ガスと省エネ／廃棄物と水／紛争鉱物／贈収賄と公正な競争／下請取引／事業継続。担当部署表で部署を決めます
4. 数値設問の判別 … 「量」「率」「時間」「人数」「件数」といった語、単位の記載、記入欄の書式から機械的に見分け、実績値台帳の metric_key を当てます
5. 設問の埋め込み … OpenAI API の埋め込みで、正規化した設問文をベクトルにします。入力の上限は8,192トークン、dimensions で次元を落とせ、ベクトルは長さ1に正規化されているためコサイン類似度は内積だけで計算できます
6. 候補の検索 … Azure AI Search のハイブリッド検索を実行します。search に正規化した設問文、vectorQueries に埋め込みを渡します
7. 候補の絞り込み … @search.rerankerScore の低いものを外し、上位5件を候補にします
8. 鮮度の判定 … 提出日が今日から365日より前の候補に印を付けます。根拠資料の改定日が提出日より後の場合も、365日以内であっても印を付けます
9. 実績値の取り出し … 数値設問には、実績値台帳から metric_key と基準期間の合う行を引きます。合う行が無ければ、値を入れずに「未確認」として担当部署へ回します

6番目に注意が必要です。 公式の説明では、セマンティックランカーを使う場合は k を50に設定するとされ、既定のランク付けで上位50件に入った結果だけが再ランクの対象になります。 対象が数千件でも、実際に見られるのは50件です。カテゴリで絞り込んでから検索すると、この50件の質が上がります。

8番目が「1年以上前の回答は必ず人に回す」の実装です。 日付の比較で済むため、生成AIには渡しません。改定日の条件を足しているのは、半年前の回答でも規程が変わっていれば誤りになるからです。

AIに処理させる

計算処理に任せること：

生成AI（OpenAI API）にさせること：

数値を書かせないことが、この構成でいちばん重要な制約です。 過去回答には数値が入っており、何も言わなければ生成AIはそれを新しい回答にそのまま写します。前年度の排出量を今年度の値として提出することになります。 そこで、数値が要る設問では回答文の中に数値の位置だけを空けさせ、実際の値は後段の処理が実績値台帳から入れます。

「未確認」を選べるようにしてください。 これが無いと、生成AIは候補のいちばん近い回答を無理に当てはめて、それらしい文を作ります。社内に無い制度をあるものとして取引先へ表明したことになります。

指示内容を固定する

あなたは、取引先から届くサステナビリティ・人権に関する調査票に対して、
自社の回答案を作る担当者です。
下に与えた「過去の回答の候補」と「社内資料の抜粋」だけを使って、
1つの設問への回答案を作ってください。

【厳守事項】
- 回答案は、下に与えた候補回答と社内資料に書かれている内容だけで作ってください。
  与えられていない制度、方針、取り組み、認証を書かないでください。
- 数値（排出量、労働時間、人数、比率、金額、件数、年月日）を回答案に書かないでください。
  数値が必要な設問だと判断した場合は needs_number を true にし、
  answer_draft では数値の位置を {{数値}} と書いて空けてください。
  候補回答に書かれている数値を写すことは、理由を問わず禁止です。
- 候補回答にも社内資料にもこの設問に対応する記載が無い場合は、
  status を "未確認" にし、answer_draft を空にしてください。
  それらしい回答を作らないでください。
- 使った候補回答の answer_id を、必ず used_sources に入れてください。
  社内資料を使った場合は、資料名と条項・見出しまで used_documents に書いてください。
  与えられていない answer_id や資料名を作らないでください。
- 候補回答に stale: true の印が付いている場合、その候補を使うことはできますが、
  confirm_points に「前回の回答から1年以上経過。実態が変わっていないか担当部署に確認」
  と書いてください。
- 選択式の設問では、選択肢の文字列を一字一句そのまま selected_choice に入れてください。
  どの選択肢にも当たらない場合は空にし、status を "未確認" にしてください。
- 字数の上限が指定されている設問では、その字数に収めてください。
- 回答案は、自社を主語にした事実の記述にしてください。
  意気込み、方針の言い換え、「努めています」のような曖昧な述語を足さないでください。
- confirm_points には、この案を出す前に人が確かめるべき点だけを書いてください。
  無ければ空にしてください。

【今日の日付】{today}
【提出先】{customer_name}
【調査票の様式名】{form_name}

【設問】
設問番号: {question_no}
設問文: {question_text}
選択肢: {choices}
字数の上限: {max_length}
カテゴリ: {category}
担当部署: {department}

【過去の回答の候補】（answer_id / 設問文 / 回答本文 / 提出先 / 提出日 / 承認者 / 根拠資料 / stale）
{candidates}

【社内資料の抜粋】（資料名 / 条項・見出し / 本文 / 改定日）
{documents}

数値の禁止を厳守事項の2番目に置いているのは、ここが最も破られやすいからです。 「当社の温室効果ガス排出量は」と書き始めた文は、数値が無いと終われません。{{数値}} という置き場所を先に与えると、文を完成させたまま数値だけを空けられます。

answer_id を写させることで、後段で機械的に検証できます。 返ってきた answer_id が渡した候補の中に無ければ、その出どころは作られたものです。その設問は「未確認」に書き換えて人に回します。 出どころを付けること自体ではなく、付いた出どころが本物かを確かめられることが目的です。 「意気込みを足さない」も効きます。これが無いと「今後も継続的に改善に努めてまいります」といった文が付き、字数制限のある欄では必要な事実が押し出されます。

出力形式を固定する

{
  "question_no": "",
  "status": "回答案あり | 未確認",
  "answer_draft": "",
  "selected_choice": "",
  "needs_number": false,
  "metric_key": "",
  "used_sources": [
    {
      "answer_id": "",
      "customer": "",
      "answered_on": "",
      "approver": ""
    }
  ],
  "used_documents": [
    {
      "doc_name": "",
      "section": ""
    }
  ],
  "confirm_points": [],
  "department": ""
}

OpenAI API の Structured Outputs を使います。公式の説明では、text.format に type: "json_schema" と strict: true とスキーマを渡すと応答がスキーマに沿った形になり、モデルが必須のキーを落としたり列挙にない値を作ったりする心配が無くなります。 strict では、スキーマのフィールドをすべて required に並べ、オブジェクトに additionalProperties: false を付けます。そのため「空でよい項目」という概念がありません。 空文字列や空の配列を入れる約束にします。

status は enum で2つに固定します。「要確認」は生成AIには選ばせません。 鮮度は前処理で決まるため、回答案シートへ書き込む段階で、stale の候補を使った設問を機械的に「要確認」へ上書きします。安全上の理由で応答が拒否された場合は refusal のフィールドに入り、構造化された出力とは別に返るためプログラムで見分けられます。 その設問は「未確認」として人に回します。

JSONにする理由は、様式へ戻すためです。 設問番号と記入欄のセル位置を保持しているので、answer_draft と selected_choice を対応するセルへ書き戻せます。

システムへ連携する

回答案シートを SharePoint のリストに作ります。1行を1設問にします。

担当部署への確認依頼は、部署ごとに1通にまとめます。 人事部には人事が見る設問だけを送ります。120問の一覧をそのまま4部署へ回すと、誰も自分の担当箇所を探しません。

部門長の最終承認には、Power Automate の承認の機能を使います。 公式の説明では、承認 - 開始して承認を待機のアクションを追加し、割り当て先にメールアドレスを入れ、タイトルと詳細を設定します。承認者は、メールの受信箱からでも承認センターからでも応答できます。 承認の種類はドロップダウンから選べ、カスタム値も入力できます。実行期間が30日を超える可能性がある場合は、承認のデータを Microsoft Dataverse に保存し、承認の作成 (v2) に基づく別のフローで応答を処理する形が案内されています。 調査票は、海外工場への照会が入ると1か月を超えることがあります。

提出後に、確定した回答を回答台帳へ登録します。 ここが「台帳が育つ」動線です。登録するのは部門長が承認して実際に提出した文だけで、却下された案や直される前の案は登録しません。 提出先・提出日・承認者・根拠資料・カテゴリを付け、埋め込みを作り直してインデックスへ入れます。この1工程を飛ばすと、半年後も候補の数が今のままです。

人が確認する

確認は4段階に分けます。全設問を人が読む設計にはしません。

1. 担当部署の確認 … 「要確認」「未確認」「数値待ち」の設問だけを、人事・調達・環境安全・法務が見ます。「回答案あり」で確認すべき点も無い設問は、部署へ回しません
2. 取りまとめ担当の通し読み … 全設問を上から読み、設問どうしの矛盾と、様式の記入ルール（字数、選択肢の記号）を確かめます
3. 部門長の最終承認 … 取引先へ出す文書として承認します。この承認が無い限り提出しません
4. 提出後の登録 … 確定した回答を回答台帳へ登録します

1番目の線引きが、削減の中身です。 月120問のうち、候補があり鮮度も新しく確認すべき点も無い設問は、想定で7割から8割です。部署の手が要るのは20問から30問になります。

確認を速くするための設計が効きます。

• 回答案の横に、使った過去回答の本文と提出先・提出日・承認者を並べて表示する
• 「要確認」の設問には、どの候補が古いのかと、その後に改定された規程名を出す
• 数値の設問には、実績値台帳から引いた値と基準期間を、調査票が求める期間と並べて出す
• 前回の同じ取引先への提出内容を、別の列で必ず見せる

4番目が効きます。 同じ取引先には毎年ほぼ同じ様式が来るため、前年と回答が変わっている設問だけを見れば確認はさらに短くなります。 なお部門長が承認するのは、内容と、答えていないことの両方です。

例外に対処する

記録を残す

この記録は、次回の調査票を軽くするための材料になります。

• 調査票ごとの設問数、状態の内訳（回答案あり／要確認／未確認／数値待ち）、提出までの日数
• 設問ごとに、使った候補回答の answer_id と @search.rerankerScore
• 担当部署の確認結果（このままでよい／直した／答えられない）と、直した場合の前後の文
• 部門長の承認結果とコメント、差し戻しの理由
• 「未確認」のまま提出した設問と、その理由を決めた人
• 実績値台帳から引いた値、基準期間、引いた日時

「部署がこのままでよいと答えた割合」を必ず残してください。 この割合が上がれば、部署へ回す設問をさらに絞れます。下がっているなら、候補の鮮度か検索の絞り込みに問題があります。