SaaSの導入前に利用規約とセキュリティ資料を確認項目に沿って一覧にする

処理の起点を決める

導入申請フォームが送信されたことを起点にします。定時実行にはしません。

契約更新時の再確認については、契約管理台帳の更新期日の60日前を起点に自動で走らせる形が有効です。規約は改定されるため、前回の確認結果がそのまま使えるとは限りません。更新の判断材料を、期日の前に用意しておく設計にします。

入力データを集める

確認項目の文言が、そのまま検索の精度を決めます。 「セキュリティは十分か」ではなく、「保管されるデータのリージョンが明記されているか」「顧客データを学習に使用しない旨が明記されているか」というように、その記述があるかないかで答えが決まる形に書き直しておく必要があります。

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

URLの探索： 生成AIに検索ツールを持たせ、製品名から各文書のURLを探させます。検索ツールには allowed_domains を指定でき、ベンダーの正規ドメインに限定できます。これを指定しないと、まとめ記事やレビューサイトの記述を根拠にしてしまいます。

検索は1回あたりの利用回数を max_uses で制限できます。1製品あたり5〜8回程度が目安です。費用は1,000回あたり10米ドルです。

文書の取得： 取得ツール（web fetch）に確定したURLを渡し、本文を取得します。HTMLとPDFの両方を扱えます。PDFの場合は、そのまま文書として処理されます。取得ツール自体には追加費用はかかりません。取得した内容がトークンとして課金されるだけです。

このとき、必ず押さえておくべき制約が3つあります。

1つ目は設計に直結します。AIに探させたURLをそのまま取得させようとすると url_not_in_prior_context のエラーになります。探索と取得を1回の依頼でつなげず、人の確定を挟む2段構えにするのは、正確さのためだけでなく、この制約に沿った設計でもあります。

allowed_domains で取得先も限定し、max_content_tokens で1文書あたりの読み込み量に上限を置きます。利用規約は長大なことがあり、上限がないとトークン費用が読めなくなります。

AIへ渡す前に整形する

1. 確認項目の書き直し … 30項目を「記述の有無で答えが決まる」形に整えます。これが最大の準備作業です
2. 必須／任意の区分 … 「記載がなければ導入不可」の項目と、「記載がなければ確認する」の項目を分けます
3. 正規ドメインの登録 … ベンダーの公式ドメインを台帳に持ちます。同じベンダーの2製品目からは探索を省けます
4. 過去の審査結果の参照 … 同一ベンダーの過去の確認結果があれば、差分だけを見る形にします
5. 文書の取得日の記録 … 規約は改定されます。いつ時点の版を見たかを必ず残します

AIに処理させる

法的な評価はさせません。 「この規約は自社の基準を満たす」「この条項は不利である」といった判断は、この構成の出力に含めません。出すのは「何が書かれているか」までです。判断は人が行います。

指示内容を固定する

あなたはSaaS導入審査の資料を整える担当者です。
渡された文書だけを根拠に、確認項目それぞれについて記述の有無を答えてください。

【厳守事項】
- 渡された文書に書かれていないことを書かないでください。
  一般的な業界慣行、他社の事例、あなたの知識を混ぜないでください。
- 該当する記述が見つからない場合は、推測せず status を not_found にし、
  checked_documents に確認した文書名を列挙してください。
- 該当した場合は、原文をそのまま quote に入れてください。
  要約・言い換え・和訳をしないでください（原文が英語なら英語のまま）。
  訳が必要な場合は translation に別途書いてください。
- 「安全である」「問題ない」「十分である」といった評価をしないでください。
  書かれている内容を示すだけにしてください。
- 文書どうしで内容が食い違う場合は、両方を示し conflict に理由を書いてください。
- 文書の版・改定日が記載されていれば document_date に入れてください。

【確認項目】
{checklist_items}

【対象文書】
{documents}

「原文をそのまま引く」の指示が要になります。 要約させると、「データは適切に暗号化されます」のような、どの製品にも当てはまる文になります。これでは審査の材料になりません。原文を引かせれば、「保管時はAES-256で暗号化される」と書かれているのか、「暗号化されます」としか書かれていないのかが区別できます。

「評価をしない」の指示も必ず入れてください。 評価を許すと、担当者がその評価を読んで判断を省くようになります。この構成が置き換えているのは探して読む作業であって、判断ではありません。

出力形式を固定する

{
  "product_name": "",
  "vendor_name": "",
  "checked_at": "",
  "documents": [
    { "type": "terms | privacy | dpa | subprocessors | security", "url": "", "document_date": "" }
  ],
  "items": [
    {
      "item_id": "",
      "item_text": "",
      "status": "found | not_found | conflict",
      "quote": "",
      "translation": "",
      "source_url": "",
      "checked_documents": [],
      "conflict": ""
    }
  ],
  "questions_for_vendor": [
    { "item_id": "", "question": "" }
  ],
  "needs_review": []
}

checked_documents を not_found のときに必ず埋めさせるのが要点です。「どこにも書いていない」と「探していない」を区別するためです。

ここで実装上の制約があります。 引用元を機械的に扱いたい場合、citations機能を使うと、引用された原文と出典の位置（PDFならページ番号、テキストなら文字位置）が構造化された形で返ります。引用文は出力トークンとして課金されません。ただし、citationsと、JSONスキーマを強制する構造化出力は同時に使えません。両方を指定すると400エラーになります。

どちらを取るかは、次のように分けます。

30項目の欠落が困る運用なら後者、原文の正確さを機械的に保証したいなら前者です。両方が必要なら、処理を2回に分けてください。

もう1点、スキャン画像だけのPDF（テキストが埋め込まれていないもの）は引用できません。古いセキュリティ資料が画像PDFで提供されていることがあります。この場合は取得ツールでは扱えないため、人が読むか、別途OCRにかけます。

システムへ連携する

確認結果を2つの出力先に書き込みます。

出典URLと確認日を必ず残してください。 これがあると、契約更新時に「前回と変わっているか」だけを見れば済みます。現在の運用で毎回ゼロから調べ直しているのは、根拠が残っていないためです。

人が確認する

全件、人が確認します。

理由は2つあります。1つは、書かれていないことを書かれているように見せる誤りが、審査を無意味にするためです。もう1つは、書かれている内容が自社の基準を満たすかどうかの判断が、この構成の出力に含まれていないためです。判断は最初から人の仕事として残しています。

確認を速くするための設計が重要です。

• 確認シートで、項目・原文・出典URLを1行に並べる
• not_found の項目を最上部にまとめる（ベンダーへの質問対象になるため）
• conflict の項目を色分けする
• 出典URLをクリックすると該当文書が開くようにする
• 必須項目で not_found のものを、目立つ形で示す

確認の順序は「記載なし」からです。 記載があった項目は原文を読めば済みますが、記載がない項目はベンダーへの照会が要るため、着手が早いほど審査が早く終わります。

例外に対処する

記録を残す

• 取得した文書のURL、取得日時、取得時点の本文
• 項目ごとの判定結果と引用した原文
• 人が修正した項目と、修正前後の内容
• ベンダーへの質問と回答
• 最終的な導入可否の判断と、判断した人

取得時点の本文を保存する点が重要です。 規約は改定され、過去の版が公開され続けるとは限りません。「導入を決めた時点の規約はこうだった」と示せる状態にしておくことは、後の監査や契約上の議論で意味を持ちます。