セキュリティの事象が起きるたびに、対応チケット・ログの抜粋・チャットのやり取りから社内向けのインシデント報告書の下書きを作る

処理の起点を決める

チケットのステータスが「報告書作成」に変わったことを起点にします。 対応の最中に下書きを作っても、記録が途中で終わっていて使えません。担当者が「ここで一区切り」と判断した時点が、記録のそろった時点です。

チケット管理システムから Webhook（ステータスが変わったときに、決めておいたURLへ通知を送る仕組み）を Azure Functions に送らせます。Webhook が使えない製品なら、15分おきにステータスが「報告書作成」のチケットを問い合わせる定時実行でも足ります。報告の期限は日単位なので、数分の遅れは問題になりません。

同じチケットで2回目の「報告書作成」が来たら、下書きを作り直します。 対応が再開して記録が増えた場合です。前の下書きは消さず、版を分けて残します。

入力データを集める

ログは、担当者が抜き出したものだけを使います。 ログの収集基盤から生のログを丸ごと渡すと、量が多すぎるうえに、事象と関係の無い他の社員の操作が混ざります。 担当者が「この行が根拠だ」と貼ったものは、それ自体が調べの結果です。

判断材料の項目は、個人情報保護委員会が示す報告の対象の類型に合わせます。 要配慮個人情報が含まれるもの、不正に利用されると財産的被害が生じるおそれがあるもの、不正の目的をもって行われたおそれがあるもの、本人の数が1,000人を超えるもの、の4つです。

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

チケットはチケット管理システムのAPIで、番号を指定してコメントと添付を取ります。Teams のチャネルは Microsoft Graph の「チャネルのメッセージの一覧」を使います。

いちばん落としやすいのは返信です。 チャネルのメッセージの一覧は、返信を含まない最上位の投稿だけを返します。対応のやり取りの多くは、最初の投稿にぶら下がった返信の中にあります。返信を取らずに要約すると、「受付」と「完了」の間がほとんど空になります。

権限は最小にします。 アプリの権限で動かすなら、ChannelMessage.Read.Group はチームごとに同意する方式で、CSIRT が事象の対応に使うチームだけに読む範囲を絞れます。全社のチャネルを読める権限を中継の処理に持たせないでください。

AIへ渡す前に整形する

1. 時刻をそろえる … チケット、チャット、ログの時刻をすべて日本時間（JST）に直します。元の時刻とタイムゾーンも残します
2. 出典のIDを振る … チケットのコメントは T-3、チャットの投稿は C-12、ログの行は L-5 のように、1件ずつにIDを付けます
3. 個人情報を置き換える … メールアドレス、氏名、電話番号、社外のIPアドレスを <EMAIL_1> <PERSON_2> のような記号に置き換え、対応表は中継の処理の側だけに持ちます
4. システムの通知を除く … チャネルへの参加、名前の変更などの自動の投稿は除きます
5. 重複を除く … チケットに転記されたチャットの文面は、チャットの側を残し、チケットの側に「転記」の印を付けます
6. 量を確かめる … 合計の文字数が決めた上限を超えたら、ログの抜粋の行を、担当者がコメントで言及した行に絞ります

1番目を省くと、時系列が9時間ずれます。AIに「時刻を直してから並べて」と頼むのではなく、渡す前に機械で直します。 時刻の換算をAIに任せると、日付をまたぐ行で誤ります。

3番目は、宛先を確かめるためにも要ります。 誤送信の事象では、誤って送った先のメールアドレスが記録の中心です。置き換えた記号のまま報告書の下書きを作り、最後に中継の処理の側で元に戻します。 AIには、記号どうしの関係（同じ人か別の人か）だけが見えれば十分です。

AIに処理させる

させるのは、記録に書かれていることを、出典を付けて報告書の形に並べ直すことだけです。

confirmed と presumed を分ける基準は、出典の性質です。 ログの行、画面の写し、相手からの返信で裏付けられたものが confirmed。チャットで担当者が「〜と思われる」「たぶん」と書いたものは、どれほど確からしくても presumed です。判断の根拠を、文体ではなく出典の種類に置きます。

最後の行がいちばん起きやすい失敗です。 報告書らしい文体にしようとすると、推測の語尾が落ちます。「〜と思われる」を消した瞬間に、確かめていないことが事実になります。

指示内容を固定する

あなたは情報システム部門で、セキュリティの事象について社内向けの
インシデント報告書の下書きを作る立場です。
渡した記録に書かれていることだけを使ってください。推測で補わないでください。

【記録の読み方】
- 記録の1件ごとに出典ID（T-n はチケット、C-n はチャット、L-n はログ）があります。
- 時刻はすべて日本時間に直してあります。
- <EMAIL_1> <PERSON_2> などは個人情報を置き換えた記号です。そのまま使ってください。
  記号の中身を推測しないでください。

【時系列の書き方】
- 出来事ごとに、日時・内容・出典IDを書いてください。出典IDの無い行は書かないでください。
- status は次のどれかです。
  confirmed … ログ、画面の写し、相手からの返信など、記録で裏付けがある
  presumed .. 担当者の見立て。「思われる」「たぶん」「はず」などと書かれている
  unknown ... 報告に必要だが記録で確かめられない
- 担当者の見立てを、断定の文に書き直さないでください。
  「たぶん開いていない」は「開封していないと担当者は見ている（未確認）」と書きます。

【報告書の8欄】
概要／発見の経緯／時系列／影響範囲／原因／実施した対応／再発防止策／未確認の事項
- 各欄の文の末尾に、根拠にした出典IDを [C-12] の形で付けてください。
- 原因と影響範囲は、担当者が記録に書いた結論だけを使ってください。
  書かれていなければ空にして、未確認の事項に入れてください。
- 再発防止策は、記録に挙がった案だけを並べてください。新しい案を足さないでください。

【漏えい等報告の判断材料】
次の項目を、記録にある範囲で書いてください。書かれていなければ not_stated です。
個人データが含まれるか／要配慮個人情報が含まれるか／財産的被害のおそれがある情報か／
不正の目的をもった行為によるおそれがあるか／本人の数
報告が必要かどうかの結論は書かないでください。

【記録】{records}
【様式の説明】{template}

「出典IDの無い行は書かない」を最初に置くのが要です。 時系列を作らせると、前後の出来事のあいだを自然な文でつなごうとして、記録に無い「その後、担当者が確認した」が入ります。 出典を必須にすれば、つなぎの文は書きようがありません。

「記号の中身を推測しない」も明記します。 置き換えた記号の前後の文脈から、もとの社名やドメインを書き足すことがあります。元に戻すのは中継の処理の役目です。

出力形式を固定する

Azure OpenAI の構造化出力で、次の形のJSONを受け取ります。 構造化出力は、指定したJSONスキーマの定義にモデルの出力を従わせる機能で、有効なJSONを保証するだけだった以前のJSONモードとは違います。

{
  "ticket_id": "SEC-0412",
  "incident_type": "misdirected_email",
  "timeline": [
    { "time": "2026-10-05T14:02:00+09:00", "event": "", "status": "confirmed",
      "sources": ["L-3", "T-1"] }
  ],
  "sections": [
    { "name": "impact", "text": "", "sources": ["C-8"], "status": "presumed" }
  ],
  "breach_factors": {
    "personal_data": "yes | no | not_stated",
    "sensitive_data": "yes | no | not_stated",
    "financial_damage_risk": "yes | no | not_stated",
    "malicious_act": "yes | no | not_stated",
    "number_of_persons": null
  },
  "open_questions": [""]
}

sections には8欄を summary ／ discovery ／ timeline_note ／ impact ／ cause ／ actions_taken ／ prevention ／ open_items の名前で並べます。

1つ目の理由は、出典を機械で検証できることです。 sources に入ったIDが、前処理で振ったIDの一覧に実在するかを中継の処理で確かめます。実在しないIDが1つでもあれば、その行は差し戻します。 自由文の報告書では、根拠を付けたつもりの文が本当に記録に基づくかを人が全部読むしかありません。

2つ目は、判断材料を本文と別に渡せることです。 breach_factors だけを抜き出して、個人情報保護の責任者へ先に送ります。number_of_persons は人数が書かれていなければ null です。構造化出力ではすべての項目を必須にし、省略したい項目は null との共用体型で表します。

スキーマの書き方には制約があります。 オブジェクトには additionalProperties: false を必ず付け、プロパティは最大100個、入れ子は最大5レベルです。文字列の minLength や pattern は使えません。時刻の形式や出典IDの書式は、スキーマではなく中継の処理の側で確かめます。

システムへ連携する

チケットには書き戻しません。 下書きのリンクをチケットのコメントに1行足すだけにします。チケットは対応の記録そのもので、AIが作った文がそこに混ざると、次に報告書を作るときの入力が汚れます。

Teams への確認依頼は、報告書を書く人とCSIRTのリーダーだけに送ります。 事象のチャネルに投稿すると、関係部署の人が下書きを確定版と思って読みます。

人が確認する

1. unknown と open_questions を最初に読む … 記録が足りない箇所です。担当者に聞くか、ログを取り直して埋めます
2. presumed の行を確かめる … 出典を開き、担当者の見立てのままでよいか、確かめて confirmed にできるかを決めます
3. 影響範囲と原因の欄を読む … 担当者の結論どおりかを、対応した本人が確かめます
4. 判断材料を責任者へ渡す … breach_factors を個人情報保護の責任者へ送ります。要否を決めるのは責任者です
5. CSIRTのリーダーが通して読む … 直してから委員会へ回します

2番目で presumed を confirmed に変えるときは、出典を足します。 「確かめた」と書き換えるだけでは、何で確かめたかが残りません。ログの行やメールの返信をチケットに足し、そのIDを付けます。

目標は、1件40分です。 下書きを読み、presumed と unknown を埋め、委員会向けに言葉を整える時間です。それより長くかかる事象は、記録の残し方に穴があります。 どの欄で時間がかかったかを記録し、チャットの書き方の決まりに戻します。

例外に対処する

拒否の行を読み飛ばさないでください。 マルウェアの名前、攻撃の手口の説明、不審なURLが記録に並ぶと、安全のための仕組みが働いて出力が止まることがあります。止まったら、その事象だけ人が書けば足ります。 無理に回避の書き方を探す必要はありません。

記録を残す

• 前処理後の入力の全文（出典ID付き）と、置き換えの対応表（中継の処理の側だけに置き、閲覧者を絞る）
• Azure OpenAI が返したJSONの全文と、呼び出した日時・モデルのデプロイ名
• 出典IDの検証結果（除外した行と理由）
• 人が直した差分 … どの行の区分を変えたか、どの欄を書き直したか
• 判断材料を責任者へ渡した日時と、責任者の判断
• 委員会へ回した確定版

最後の2つは、事後に問われる記録です。 報告の期限は発覚日から数えるため、いつ材料がそろい、いつ判断したかを日時で残します。

人が直した差分は、プロンプトを直す材料です。 presumed を confirmed に変えた行が多いなら、確かめた結果がチャットに書かれていない運用です。AIの側ではなく、記録の残し方を直します。