クラウドサービスの設定を社内基準に照らして毎月点検する

処理の起点を決める

毎月1日の定時を起点にします。n8n の Schedule Trigger ノードで月単位の間隔を指定します。

取得だけを毎週行い、突き合わせと判定は月1回にするという組み方も考えられます。Schedule Trigger は複数のトリガールールを追加でき、異なるスケジュールでノードを動かせるためです。日単位を選ぶ場合は「Days Between Triggers」「Trigger at Hour」「Trigger at Minute」を指定します。

タイムゾーンの確認を先にしてください。 Schedule Trigger はワークフローの設定を優先し、未設定ならn8nインスタンスの設定を使います。自己ホスト版の既定は America/New_York です。 日本時間の1日朝に動かすつもりが、前月末の夜に動いていた——という取り違えが起きます。

Schedule ノードをトリガーに使うワークフローは、保存して公開する必要があります。 編集しただけでは動きません。また、Cron式で変数を使う場合、値はワークフローの公開時にだけ評価されます。 変更したら再公開してください。

実行を逃した場合の動作も決めておいてください。 インスタンスが停止していて実行を逃した場合の動作は設定できます（n8n 2.36 以降）。月次の点検は、月に1回しか機会がありません。 欠けた月があると、翌月の「前月との差分」も取れません。

手動で起動できる入口も用意してください。 取引先からの照会が届いたとき、月初を待たずに取りたくなります。

入力データを集める

「受け入れたリスクの記録」を独立した入力にしている点が要です。 これがないと、意図して外している項目が毎月「未対応」として並び直します。

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

推奨されるアクションと現在の状態： Microsoft Defender ポータルのセキュア スコアから取ります。ここで押さえておくべき性質が3つあります。

第1に、ライセンスの有無に関わらず、製品に関して考えられる推奨事項の完全なセットが表示されます。 契約していない機能の推奨も一覧に含まれるため、点検の対象から外す判定を、こちら側で持つ必要があります。

第2に、更新の頻度が項目によって違います。 スコアはリアルタイムで更新され、毎日同期して各アクションで達成されたポイントのシステムデータを受信します。ただし、Microsoft Teams と Microsoft Entra 関連の推奨事項は、構成状態の変更で更新されるほか、それぞれ月に1回・週に1回更新されます。 毎月1日に取った値でも、項目によっては数週間前の状態を見ていることがあります。

第3に、スコアの付き方が一様ではありません。 推奨される各アクションは10ポイント以下の価値があり、そのほとんどはバイナリ形式で、その他は構成全体に対する割合でスコア付けされます。完全に完了した時点でのみポイントが与えられるものと、一部のデバイスやユーザーで完了すると部分的なポイントになるものがあります。 ポイントの数字をそのまま判定に使わないでください。

アクセス許可は読み取り専用で組んでください。 アクセス許可は Microsoft Defender Unified RBAC（Exposure Management の read または manage）か、Microsoft Entra のグローバルロールで与えられます。セキュリティ リーダーやグローバルリーダーなどは読み取り専用です。 点検の処理は読むだけなので、書き込める権限を持たせる理由がありません。

その他のSaaSの設定： セキュア スコアの対象に含まれないサービスは、個別に取ります。APIがあればAPIで、なければ管理画面のエクスポート機能で取ります。12種すべてを最初からAPIでつなごうとしないでください。 手作業でエクスポートしたファイルを読む形で始めれば、早く動き出せます。

社内のセキュリティ基準の構造化： ここがこの構成でいちばん重い作業です。 基準が文章のままでは突き合わせられません。次の形にしてください。

「例外を認める条件」の列が、この構成でもっとも効きます。 これがないと、外れている項目はすべて是正の対象になります。

この一覧は、一度に作り切ろうとしないでください。 まず前月の点検で問題になった項目と、取引先から聞かれたことのある項目から埋めてください。 対応が付いていない項目は「判断が付かない」として人へ回せばよく、空白のまま運用を始められます。

前月の点検結果： 差分を取るために、点検記録は毎月同じ形で残す必要があります。月ごとにExcelファイルを分ける今の形のままでは、機械で比べられません。 1行1項目1月の形にして、1つの表に積んでください。

AIへ渡す前に整形する

1. 項目の名寄せ … 推奨事項の名称は、製品の更新で変わることがあります。突き合わせ用の識別子を、名称とは別に持ってください
2. 対象外の判定 … 契約していない機能の推奨を、点検の対象から外します
3. 状態の正規化 … 「完了」「一部完了」「未対応」「代替の軽減策で対処」といった形に揃えます
4. 値の時点の付与 … その項目が、いつ時点の状態なのかを付けます。更新の頻度が項目によって違うため、ここを省けません
5. 社内基準への対応づけ … 構造化した基準の一覧と、項目を突き合わせます
6. 前月との差分の算出 … 状態が変わった項目を洗い出します
7. 識別子の除去 … テナント名、管理者のアカウント名、組織の固有の識別子を落とします

7が、外部のAIサービスへ渡す設計を決めます。 突き合わせに必要なのは、設定の項目名、現在の状態、社内基準の文言までです。

6の差分は、Pythonで取るのが確実です。 前月と今月の表を突き合わせるだけの処理です。ここを生成AIにやらせると、見落としが出ます。 機械的に決まることは機械で決めてください。

AIに処理させる

4つの処理をさせます。

（1）社内基準との突き合わせと、区分への振り分け

accepted_risk を区分として持つことが、この構成のいちばんの工夫です。 セキュア スコアには、推奨されるアクションを適用できない、または実行したくない場合に「リスクを受け入れる」または「残りのリスクを受け入れる」を選べる仕組みがあります。また、推奨されるアクションを、Microsoft 以外のソリューションまたは代替の軽減策の対象としてマークすることもできます。

外していること自体は悪ではありません。 サービス側に、そのための選択肢が用意されています。問題は、外している理由が記録されていないことです。 deviation と accepted_risk を分けるのは、この違いです。

（2）前月からの変化の説明

前月から状態が変わった項目について、何がどう変わったかを文章にします。 誰が変えたかは、管理画面の監査ログから取れる範囲で付け、取れなければ空にします。

（3）外している理由の候補の作成

deviation と判定された項目について、なぜ外れているのかの候補を書かせます。 社内基準の「例外を認める条件」、前月までの記録、同じ製品の他の項目の状態を材料にします。書けるのは「こういう理由である可能性がある」までです。実際の理由は、設定を変えた人しか知りません。

（4）人が見るべきものの切り分け

undetermined と判定した項目について、なぜ判断が付かないのかを書かせます。 「基準に対応する記述が見当たらない」「値が取得できなかった」「複数の基準に当たる」——理由が分かれば、人の確認が速くなります。

させないことを先に決めてください。

• 設定の変更を実行させない。 この構成は読むだけです
• 理由を確定させない。 候補までです
• 承認させない。 承認者の欄をAIに埋めさせないでください
• リスクの大小を断定させない。 「この設定は危険です」といった記述を出させないでください

指示内容を固定する

あなたは情報システム部で、クラウドサービスの設定の月次点検を担当する者です。
取得した設定の状態を、社内のセキュリティ基準に照らして区分に振り分けてください。

【厳守事項】
- 設定の変更を提案しないでください。
  「この設定を有効にしてください」と書かないでください。
  区分の振り分けと、外れている理由の候補までにしてください。
- 外している理由を確定しないでください。
  reason_draft に書くのは候補です。
  「〜という理由で外していると考えられる」という形にし、
  断定の形で書かないでください。
- approver（承認者）の欄を、あなたが埋めないでください。
  必ず空にしてください。承認は人が行います。
- 記載がなければ「不明」としてください。
  社内基準に対応する記述が見当たらない場合は、
  status を undetermined とし、推測で対応づけないでください。
- 前月の記録に理由と承認者が残っている項目だけを accepted_risk としてください。
  理由が残っていない項目は、外れていれば deviation です。
  「たぶん意図的だろう」と判断しないでください。
- state_source_date には、その値がいつ時点のものかを必ず入れてください。
  分からない場合は「不明」とし、needs_human を true にしてください。
- リスクの大小を断定しないでください。「危険です」と書かないでください。
- スコアの点数を根拠に優先度を決めないでください。
  優先度は社内基準の必須度で決めます。
- 一般的なセキュリティの推奨で補わないでください。
  社内基準に書かれていないことを、基準として扱わないでください。

【社内のセキュリティ基準（基準ID／文言／対応する推奨アクション／必須度／
  例外を認める条件／承認者／再確認の時期）】
{internal_baseline}

【今月取得した設定の状態（項目名／サービス／現在の状態／値の時点）】
{current_state}

【前月の点検結果（項目名／区分／理由／承認者／再確認の時期）】
{previous_result}

【当社が契約している機能の範囲】
{licensed_scope}

【前月からの差分（機械的に算出したもの）】
{diff}

「approver をあなたが埋めないでください」の指示が、この構成の芯です。 承認者の欄が埋まっていると、それを見た人は「誰かが承認した」と受け取ります。AIが埋めた承認者は、監査で説明できません。

「理由が残っていない項目は deviation とする」も外せません。 生成AIは、外れている理由をそれらしく補おうとします。補われると、記録として残っていないことが見えなくなります。

出力形式を固定する

{
  "check_date": "",
  "items": [
    {
      "item_id": "",
      "service": "",
      "recommended_action": "",
      "current_state": "",
      "internal_baseline": "",
      "status": "compliant | deviation | accepted_risk | changed_since_last | undetermined",
      "reason_draft": "",
      "approver": "",
      "last_checked": "",
      "state_source_date": "",
      "needs_human": { "value": false, "why": "" }
    }
  ]
}

構造化する理由は、この出力が毎月積み上がるからです。 項目ごとに同じ形で残して初めて、changed_since_last の判定が成立します。

state_source_date を別に持たせる理由は、更新の頻度が項目によって違うからです。 点検した日と、その値が実際に取られた時点は同じではありません。「いつ時点の値か」を持たないと、点検の意味が薄れます。 監査で示した日付と実際の時点がずれていれば、記録そのものの信頼が落ちます。

reason_draft は候補にとどめます。 ここがこの記事の要です。AIが書いた理由をそのまま記録に残すと、監査で説明できません。 出せるのは、判断した人が確定した理由だけです。候補は、確定作業を速くするための下書きです。

approver が空であることに意味があります。 空は「まだ誰も承認していない」という状態です。埋まっていない項目が一覧で見えることが、点検の成果物になります。

システムへ連携する

出力は点検記録へ書き込み、是正が必要なものを起票するところまでです。

設定を変える連携は作らないでください。 外している理由が業務上の必要だった場合、戻した瞬間に業務が止まります。

起票も、deviation に限ってください。 accepted_risk を起票すると、意図して外しているものに毎月作業依頼が立ちます。現場は、その起票を閉じるために時間を使うことになります。

再確認の時期が来た accepted_risk だけは、別に知らせてください。 受け入れたリスクを、永久に受け入れたままにしないためです。

人が確認する

この構成では、人の確認が成果物そのものです。 自動処理は材料を作るだけです。

1つ目が最重要です。 deviation と出た項目のうち、実際には理由があるのに記録されていなかっただけ、というものが最初の数か月は大量に出ます。 これを1件ずつ潰していく作業が、この構成の導入そのものです。

3つ目の法務の確認が、この構成を「聞かれたときに答えられる」状態にします。 情報システム部が書いた技術的な説明は、社内では通じても、取引先のセキュリティ確認の回答としては言葉が足りないことがあります。

undetermined の確認結果を、基準の一覧へ戻してください。 対応が付かなかった項目に人が対応を付けたら、それを基準の一覧に書き足します。この積み上げで、翌月の undetermined が減ります。

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

• deviation と changed_since_last を上に並べる
• 前月の理由と、今月の候補を左右に並べる
• 承認者が空の項目に印を付ける
• 再確認の時期が過ぎた accepted_risk を別に出す
• 各項目に、社内基準の該当箇所を引用して添える

5つ目が、確認の速さを決めます。 基準の文書を開き直さずに、その場で判断できる形にしてください。

例外に対処する

「前月の値を流用しない」が、いちばん守るべきところです。 取得できなかった月を前月の値で埋めると、記録の上では点検したことになります。取れなかったことを、取れなかったと残してください。

記録を残す

この記録は、監査と取引先のセキュリティ確認でそのまま使われます。

• 取得した設定の状態と、その値の時点
• 項目ごとの区分と、確定した理由
• 承認者と、承認した日
• 前月からの差分
• AIが出した候補と、人が確定した文言の両方
• undetermined から対応を付けた履歴
• 取得できなかった項目と、その理由

候補と確定文言の両方を残すことに意味があります。 候補がどれだけ書き直されたかが分かれば、基準の一覧の「例外を認める条件」を厚くすべき箇所が見えます。

記録は、改ざんできない形で残してください。 点検の記録は、監査で「その時点でそうだった」ことの証拠として使われます。あとから書き換えられる形では、証拠になりません。 追記だけができる形にするか、月次で確定して別の場所へ複製してください。