「使えない」の連絡を、過去の障害と設定変更の履歴に照らして切り分ける

処理の起点を決める

ITサービス管理ツールにチケットが作られたことを起点にします。 定時実行にはしません。切り分けは受けた直後にしか意味がなく、まとめて処理すると、全社の障害に気づくのが夕方になります。

トリガーの直後に置くのが、件数を数える処理です。 チケットが作られるたびに、直近15分の同種のチケットを数えます。この処理だけはAIを通しません。 数えれば分かることに推測を挟みません。

入力データを集める

正直に書いておきます。過去の障害の記録が残っていない会社では、この仕組みは動きません。 記録が手元のメモやチャットの流れにしかなければ、検索する先が存在しないからです。先に要るのは、記録番号と日付が付いた記録を1年分ためることで、これはAIではなく運用の話です。 変更の履歴も同じで、メールに散らばっていると72時間で絞れません。

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

インデックスは2つに分けます。 探し方が違うからです。

記録側で効くのは、セマンティックランカーの制約です。 これは既定のランク付けアルゴリズムでスコア付けされた上位50件を再ランク付けするもので、50を超える結果が含まれている場合でも、上位50件のみが進みます。

だから、母数を先に絞ります。 対象サービスと拠点で filter をかけてから引けば、50件の枠に近いものが入ります。絞らずに全社1年分から引くと、上位50件が別のサービスの記録で埋まります。 公式の記述にも、セマンティックランカーを使用している場合は k を 50 に設定して入力を最大化する、とあります。

並べ替えは指定しません。 明示的な並べ替え順序は関連性の順位を上書きするとされています。後段で使う値は @search.rerankerScore、範囲は 4 から 0（高から低）です。

AIへ渡す前に整形する

1. 氏名の置き換え … 氏名を社員番号に置き換えます。宛名と署名の両方です
2. 端末名の置き換え … 資産管理番号は下3桁だけを残し、機種名は残します
3. 署名と定型の挨拶の除去 … 落とさないと検索の言葉がぶれます
4. サービス名の統一 … 「勤怠」を正式名称に、対応表で寄せます
5. 件数の集計 … 直近15分の同種のチケットを数えます。同じ利用者の連続は1件です
6. 記録の分割 … 長い対応記録を、見出しごとに分けて入れます
7. 変更履歴の絞り込み … 適用日時が直近72時間のものだけにします

6番目に理由があります。 セマンティックランク付けでは、ドキュメントごとに要約モデルが最大2,000個のトークンを受け入れ、トークンは約10文字とされ、入力は「title」「keywords」「content」から組み立てられます（タイトル128、キーワード128、コンテンツが残り）。長すぎる文字列はトリミングされ、上限を超える内容は無視されます。 何時間も続いた対応記録を丸ごと入れると、末尾の「原因はこれだった」が捨てられます。

1番目と2番目は、第13章につながります。 外部のAPIへ渡すのは置き換えのあとの文面で、前処理に置かないと、渡す直前に確かめることになって漏れます。

AIに処理させる

呼び出しを2つに分けます。 渡すものと受け取る形が違うからです。

分けているのは、好みの問題ではありません。併用できないからです。 Claude の引用（citations）と構造化出力は併用できず、渡したドキュメントで引用を有効にしたうえで output_config.format パラメーター（および非推奨の output_format）を含めると、APIは400エラーを返します。 引用はテキスト出力に引用ブロックを差し込む必要があり、構造化出力の厳格なJSONスキーマの制約と両立しないためとされています。

呼び出しAで引用を使うのは、出どころを人に書かせないためです。 応答は複数のテキストブロックに分かれ、各ブロックが主張と、それを支える引用を持ちます。

下から2行目が、いちばん起きやすい失敗です。 記録番号を本文に書かせると、「INC-2416の事例では」と書きながら、引用は別の記録を指すことが起こります。

指示内容を固定する

呼び出しA（記録を引用付きで読ませる）

あなたは情報システム部門で、利用者からの「使えない」という連絡の切り分けを
手伝う立場です。渡した記録に書かれていることだけを使ってください。

【出すもの】次の3つを、この見出しのまま順に書いてください。
1. 似た過去の事例
2. 直近の変更で関係しそうなもの
3. 次に確かめること

【厳守事項】
- 1と2は、渡した記録のどれかを根拠にしてください。根拠にできる記録が
  無ければ「該当なし」と書き、なぜ該当しないかを1文で書いてください。
  それらしい事例を思い出して書かないでください。
- 記録の番号と日付を本文に書かないでください。番号はこちらで付けます。
- 原因を断定しないでください。「〜が原因です」と書かず、「〜の事例では
  〜だった」「〜の変更が同じ対象に当たっている」と書いてください。
- 再起動する、設定を戻すといった復旧の操作を書かないでください。
- 外部のサービスが止まっているかどうかを書かないでください。
- 3は確かめる順に3つまで。結果で次にやることが変わる順に並べてください。
- 利用者の氏名を、文面に残っていても書き写さないでください。

【利用者からの連絡】{ticket_body}
【同じ時間帯の連絡件数】直近15分に {concurrent_count} 件
【過去の障害の記録／設定変更・リリースの履歴】
  documentブロックで渡す（引用を有効にする）

「それらしい事例を思い出して書かない」を書かないと、書きます。 記録に近いものが無いとき、よくある障害の話を、記録から読んだ体裁で並べます。

呼び出しB（連絡の本文だけを決まった形で受け取る）

あなたは情報システム部門の受付です。利用者からの連絡の本文だけを見て、
切り分けに必要な項目が書かれているかを確かめ、足りない項目を聞き返す文を作ります。

【型の項目】
- since ... いつから  - who_scope ... 本人だけか周りにもか
- screen ... どの画面・操作で  - device ... 端末の種類
- error_text ... 画面に出ている文言  - service_name ... どのシステムか

【厳守事項】
- 書かれていない項目は空のままにし、missing に入れてください。
  文面から推測して埋めないでください。
- 「たぶん全社」のような書き方をせず、本人が書いた範囲だけを読んでください。
- ask_back_draft は、missing に入れた項目だけを尋ねる文にしてください。
  200文字以内、箇条書きで、謝罪や前置きを入れないでください。
- 原因、対処、復旧の見込みと、利用者の氏名を出力に含めないでください。

【連絡の本文】{ticket_body}

「200文字以内」をプロンプトに書くのは、スキーマで縛れないからです。 構造化出力のJSONスキーマでは、minLength と maxLength といった文字列の制約がサポートされていません。

出力形式を固定する

呼び出しAは、テキストと引用で返ります。 引用を有効にするには各ドキュメントに citations.enabled=true を設定します。 現時点では、1つのリクエスト内のすべてのドキュメントで有効にするか、すべてで無効にするかのどちらかにする必要があります。

{
  "type": "text",
  "text": "同じ拠点の利用者から、同じ画面で同じ文言が出た事例がある",
  "citations": [
    { "type": "char_location",
      "cited_text": "（記録から引かれた文がそのまま入る）",
      "document_index": 2,
      "document_title": "INC-2416 / 2026-06-11 / 申請画面が開かない",
      "start_char_index": 0, "end_char_index": 128 }
  ]
}

記録番号と日付は document_title から取ります。 タイトルは長さに制限があるため、メタデータをテキストまたは文字列化したJSONとして保存するには context フィールドが役に立つとされています。拠点や対象サービスはそちらへ入れます。

引用の付いていない記述は、ここで落とします。 citations が空のテキストブロックを捨てます。禁じたうえで、機械でも落とします。

呼び出しBは、次のスキーマで受け取ります。 8項目すべてを required に入れます。

{
  "type": "object",
  "properties": {
    "since":        { "type": "string" },
    "who_scope":    { "type": "string", "enum": ["self_only", "others_too", "unknown"] },
    "screen":       { "type": "string" },
    "device":       { "type": "string" },
    "error_text":   { "type": "string" },
    "service_name": { "type": "string" },
    "missing":      { "type": "array",
                      "items": { "type": "string",
                                 "enum": ["since", "who_scope", "screen",
                                          "device", "error_text", "service_name"] } },
    "ask_back_draft": { "type": "string" }
  },
  "additionalProperties": false
}

オブジェクトの additionalProperties は false に設定する必要があります。 決めた項目以外が混ざらず、後段の分岐が書きやすくなります。

2つの結果は、ワークフローが1枚にまとめます。 similar_incidents と recent_changes には引用から取った記録番号・日付・cited_text を、asked_back には呼び出しBの missing と下書きを入れます。その先頭に、数えた結果である concurrent_count と「全体障害の疑い」を置きます。 AIの出力ではありませんが、担当者が最初に見る場所をそろえるために同じ1枚に載せます。

システムへ連携する

チケットへは書き込みません。 出すのは担当者が見る1枚までで、結果を書くのは人です。 書き込みを足すと、候補が事実として記録に残り、次の検索で引かれます。

承認は、全社周知を出すかどうかにだけ使います。 Power Automate では「承認 - 開始して承認を待機」アクションを任意のフローに追加することで承認を管理でき、承認者は承認センターまたはメールから返信できます。「詳細」フィールドは Markdown で書式を設定できるので、件数と時間帯と拠点の内訳を並べます。

人が確認する

人が見るのは全件です。 減らすのは1件あたりの調べ物の時間です。

1. 全体障害の疑いを先に見る … concurrent_count と内訳を見ます。3件以上なら、個別の端末を見に行く前に止まります
2. 候補の出どころを確かめる … 記録番号と日付から元の記録を開き、cited_text を読んで今回の連絡と本当に近いかを見ます
3. 外部サービスの稼働情報は自分で読む … リンクを開いて現在の状態を読みます。AIの出力を経由しません
4. 確かめる順番を決める … 「次に確かめること」は候補です。並べ替えても、捨ててもかまいません

2番目を省かないでください。 引用が付いていても、その記録が今回と似ているかの判断は人の仕事です。 同じ文言のエラーでも、原因が違うことはいくらでもあります。

例外に対処する

外部サービスの稼働情報を渡さないのは、書式が一定でないからです。 ページには現在の状態と過去の障害の記載が並び、過去の記載を現在の状態として読まれると、対応の方向が丸ごと変わります。

しきい値を細かく決めないのにも根拠があります。 公式の記述では@search.rerankerScore の分布はインフラストラクチャレベルの条件により若干の変動を示す可能性があるとされ、最小しきい値のカスタムコードを書くときは限度を細かくしすぎないようにとあります。

記録を残す

• 連絡の本文（置き換え後）と、置き換える前との対応表（社内にだけ置く）
• 検索に投げたクエリと、返ってきた記録の番号・@search.rerankerScore
• 呼び出しAの応答全文と、引用が無くて落とした記述の件数
• 呼び出しBのJSONと、聞き返しを送ったかどうか
• 担当者が実際に確かめた順番と、候補のうち役に立ったもの
• 切り分けの結果（範囲と出どころ）と、最終的な原因
• 全体障害の疑いが立った回数と、そのうち実際に全体障害だった回数

5番目と6番目が、翌日の検索の材料になります。 どの候補が当たったかを残さないと、検索が良くなっているのか誰も言えません。

最後の行は、件数のしきい値を直すための数字です。 疑いが外れることが多ければ、15分か3件のどちらかが合っていません。