社員のSaaSの利用申請ごとに、公開情報から確かめるべき点の質問と承認者向けの要約を作り、情報システムの審査へ回す

処理の起点を決める

申請フォームの送信を1件ずつきっかけにします。 フォームの側で、送信時に Catch Hook のURLへ申請の内容を送る設定を入れます。毎日まとめて処理する形にはしません。 申請者は使いたいから申請しているので、審査に入るまでの待ちが1日延びるごとに、申請を通さずに使い始める誘惑が増えます。

申請者が申請を取り下げ、出し直したときも、新しい申請として動きます。 台帳には申請番号ごとに1行ずつ足し、同じサービスかどうかは次の段の過去の審査の照会で見ます。

Catch Hook はJSONの配列を受け取ると、要素ごとに Zap を動かします。フォームの側で1件ずつ送る設定にし、まとめて送らないようにします。

入力データを集める

質を決めるのは、申請者が貼るURLです。 提供元のトップページのURLだけでは、セキュリティの記載はほとんど取れません。申請フォームの説明に「セキュリティ」「トラスト」「プライバシー」などの名前のページを探して貼ってください、と書き、見つからなければ空でよいとしておきます。空のときは、AIは申請内容だけで質問を作ります。

過去の審査は、サービス名ではなく提供元のドメインで引きます。 申請者によって「〇〇」「〇〇 Pro」「〇〇（英語名）」と書き方が変わるので、申請フォームに「提供元のドメイン（例：example.com）」の欄を設け、それで引くほうが確実に一致します。

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

ページは最大3つまでにします。 1つの申請で何十ページも取得すると、本文が長くなり、AIが根拠の文を取り違えます。セキュリティ、プライバシー、データの取扱いの3つで、審査の観点の大半は埋まります。

取得に失敗したページは、失敗したと記録します。 ログインが要るページ、ブラウザでスクリプトを動かさないと本文が出ないページは、GET では中身が取れません。取れなかったことを「書かれていない」と区別するために、取得の結果（成功・失敗・本文が短すぎる）をAIに一緒に渡します。

過去の審査が見つかったら、その結果もAIに渡します。 前回の質問と提供元の回答があれば、今回の質問から、すでに答えのあるものを外せます。

AIへ渡す前に整形する

1. URLの形を確かめる … https:// で始まらないもの、社内のアドレスは取得しません
2. ドメインの書き方をそろえる … 申請フォームの説明に「www. を付けず、example.com の形で」と書き、台帳の側も同じ形で持ちます。書き方がずれると、過去の審査があっても引けず、同じサービスを最初から調べ直すことになります
3. ページを取得する … GET で取得し、応答の状態を記録します。Webhook のアクションで扱える大きさは5MBまでです
4. タグを外す … Remove HTML Tags で本文だけにします
5. 本文の長さを確かめる … 数百文字しか残らないページは「本文が取れなかった」として印を付けます
6. ページごとに見出しを付ける … 「ページ1（URL）：本文」の形で並べ、AIが根拠のURLを書けるようにします
7. 審査の重さを決める … 扱うデータの種類の選択肢から、規則で heavy か light を決めます

5番目を省くと、取れなかったページを「何も書かれていないページ」としてAIが読みます。 その結果、すべての観点が not_found になり、提供元に聞かなくてよい質問まで並びます。

AIに処理させる

させるのは、7つの観点ごとに、ページに書かれていることを根拠付きで拾い、書かれていないことを質問に変えることです。

状態は3つに分けます。 found（ページに書かれていて根拠の文がある）、not_found（取得できたページのどこにも書かれていない）、unclear（書かれているが条件付き、プランによる、など一意に読めない）です。not_found は「対応していない」という意味ではないことを、指示と要約の両方に書きます。

3行目が最も起きやすい失敗です。 有名なサービスほど、AIは「このサービスはSAMLに対応している」と知っていることを書きます。それが正しくても、今日のページに書かれていない限り根拠になりません。 プランや時期で変わるからです。

指示内容を固定する

あなたは情報システム部門で、社員から届いたSaaSの利用申請の一次整理をする立場です。
与えられた申請内容と、提供元のページの本文だけを根拠にしてください。
あなたが知っている一般的な情報で補わないでください。

【観点】次の7つについて、それぞれ status を1つ選ぶ
1. storage ....... データを保存・処理する国・地域
2. auth .......... シングルサインオン、多要素認証
3. integration ... API、連携アプリ、求める権限の範囲
4. certification . 第三者の認証（ISO/IEC 27001、SOC 2 など）
5. subprocessor .. 再委託先の一覧
6. termination ... 解約後のデータの削除・返却
7. ai_training ... 預けたデータを提供元のAIの学習に使うか

【status の選び方】
- found ....... ページに書かれている。evidence にその文をそのまま写し、source_url を書く
- not_found ... 取得できたページのどこにも書かれていない
- unclear ..... 書かれているが、プランや条件によって変わるなど一意に読めない
「書かれていない」ことを「対応していない」と書かないでください。

【質問の作り方】
- not_found と unclear の観点について、提供元への質問を1つずつ作る
- 申請の内容が足りないもの（連携先の権限、扱うデータの具体例など）は、
  申請者への質問にする
- 過去の審査で答えが出ている観点は、質問を作らない
- 丁寧な日本語で、1問1文。はい・いいえで終わらない聞き方にする

【承認者向けの要約】
- 300字以内。申請の目的、扱うデータの種類、found の要点、
  まだ分からないことの数を書く
- 「利用してよい」「問題ない」「危険」といった結論を書かない
- not_found は「公開ページでは確認できなかった」と書く

【取得の結果】{fetch_status}
（取得に失敗したページ、本文が短すぎるページは、根拠に使わないでください）

【申請】{request}
【過去の審査】{past_review}
【提供元のページの本文】{pages}

「一般的な情報で補わない」を最初に置くのは、前節の3行目のためです。 書かなければ、ページに無い記載をもっともらしく found にし、evidence に要約した文を入れます。evidence に「そのまま写す」と書くのも、写した文がページに本当にあるかを審査担当が検索で確かめられるようにするためです。

結論を書かせない指示は、要約の側にも置きます。 観点ごとの status では結論を避けても、要約で「総じて問題ないと考えられる」と締めくくることがあります。

出力形式を固定する

Analyze and Return Data の出力の項目を、次の形で定義します。

{
  "service_name": "",
  "checks": [
    { "aspect": "storage", "status": "found | not_found | unclear",
      "evidence": "", "source_url": "" }
  ],
  "questions_to_vendor": [""],
  "questions_to_requester": [""],
  "approver_summary": "",
  "pages_used": [""]
}

checks には7つの観点を1つずつ並べます。aspect は storage ／ auth ／ integration ／ certification ／ subprocessor ／ termination ／ ai_training です。

1つ目の理由は、台帳の列にそのまま書けることです。 観点ごとに status の列を持たせると、台帳を見ただけで、どのサービスがどの観点で not_found のままかが並びます。 自由文の要約だけでは、この一覧は作れません。

2つ目は、質問を2つの宛先に分けておけることです。 提供元への質問は審査担当が提供元の窓口に送り、申請者への質問は申請者に返します。宛先が混ざると、申請者が提供元に聞くべきことを聞かれて困ります。

3つ目は、pages_used で根拠の範囲が残ることです。 審査の後で提供元がページを書き換えても、どのページを見た時点の整理かが分かります。

システムへ連携する

提供元への質問は Create Draft で下書きにします。 送るのは審査担当です。提供元の窓口の宛先は、申請者か審査担当が確かめてから入れます。 AIが宛先を推測する経路を作りません。

台帳には、観点ごとの status と根拠のURL、質問の一覧、要約を1行に書きます。 審査担当は台帳の行を見ながら確認を進め、可否の意見と承認の結果も同じ行に書き足します。

人が確認する

この構成の出力は、すべて審査担当が確かめてから使います。 自動で送るものはありません。

1. found の根拠を開く … source_url を開き、evidence の文がページにあるかを確かめます。特に storage と ai_training は必ず開きます
2. 質問を直す … 自社の基準に照らして要らない質問を消し、足りない質問を足します
3. 提供元と申請者に送る … 下書きを確かめて送ります
4. 回答を台帳に書き、可否の意見を付ける … 承認者は要約と意見を読んで決めます
5. AIの整理を覆したら記録する … どの観点を、どの status に直したかを残します

1番目を省かないでください。 found の evidence が別のプランの説明だった、旧版のページだった、ということは起きます。承認者が読む要約は、この確認を通った後のものです。

目標は、60件をならして1件15分です。 軽い審査は根拠を数か所開いて質問を送るまでで10分前後、重い審査は30分を超えます。重い審査が増える月は、扱うデータの種類の選び方が申請者に伝わっていないことがあります。 申請フォームの選択肢の説明を見直してください。

例外に対処する

上から3行目までが大半を占めます。 どれもAIの問題ではなく、提供元のページが取れたかどうかの問題です。 取れなかったことを正直に記録しておけば、審査担当はそこだけをブラウザで見に行けば済みます。

記録を残す

• 申請の内容と申請番号、申請日時
• 取得したページのURL、取得日時、取得の結果、タグを外した本文
• AIの出力（checks、質問、要約）
• 審査担当が直した箇所と、直した後の質問
• 提供元と申請者からの回答、可否の意見、承認の結果
• 同じ提供元の審査の履歴（ドメインで引けるように）

2つ目で本文そのものを残すのは、提供元のページが変わるためです。 半年後に「このときは国内保存と書いてあった」と確かめたくなったとき、取得した時点の本文が無ければ、要約が正しかったのかを確かめようがありません。