運用を委託している会社の月次の運用報告書を、契約のサービスレベルと前月の報告に照らして点検し、確認の質問を作る

処理の起点を決める

システムごとのフォルダに、その月の運用報告書が保存されたことを起点にします。 報告書は委託先ごとに月初の数日に届くので、1日1回の定時実行にすると、届いた順に点検を始められません。定例会までの日数が短い委託先ほど、早く点検を返したいからです。

フォルダの名前は「委託先コード／システムコード／年月」にそろえます。ワークフローはフォルダの名前から、どのSLA台帳と前月の点検結果を引くかを決めます。 報告書のファイル名は委託先ごとにばらばらなので、ファイル名からは決めません。

報告書の本文と添付の両方がそろってから動かします。 本文だけで動かすと、障害の一覧を見ないまま「障害0件」という本文の記述を信じることになります。添付が24時間届かないときは、担当者へ通知して止めます。

入力データを集める

質を決めるのは、SLA台帳の「除外条件」の列です。 稼働率の計算から何を除くか、問い合わせの一次回答の時間を営業時間で数えるか暦の時間で数えるか。ここが空のままだと、AIは報告書の数字を契約の定義で読めません。 第3章の（b）は、この列が無いことから起きます。

計画停止の合意記録は、除外条件を確かめるために持ちます。 報告書が「計画停止を除く」と書いていても、その停止が事前に合意したものかどうかは報告書からは分かりません。合意した日時の一覧と照らして、初めて判定できます。

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

前月の報告書そのものではなく、前月の点検結果を渡します。 前月のPDFをもう一度読ませると入力が倍になり、しかも前月の判定と今月の判定が別々の読み方になります。前月に確定した継続課題の一覧を、今月の入力として固定で渡します。

一覧の表ファイルは、列名をそろえてからCSVにします。 委託先ごとに「発生日時」「発生時刻」「Occurred」と列名が違うので、ワークフローの側で対応表を持ち、決まった列名に置き換えてからテキストにします。

AIへ渡す前に整形する

1. 形式の確認 … 報告書がPDFであることを確かめます。Office形式で届いたものはPDFに変換します
2. パスワードの確認 … パスワードや暗号化のかかったPDFは扱えません。委託先に解除したものを送り直してもらいます
3. サイズとページ数の確認 … 1回のリクエストは32MB、600ページ（コンテキストウィンドウが100万トークン未満なら100ページ）まで。超えるものは、本文と付録で分けます
4. 一覧の変換 … 表ファイルをCSVのテキストにし、列名を対応表でそろえます
5. 時刻の統一 … 一覧の時刻を、日本時間・24時間表記にそろえます。初動までの時間の計算がずれるのを防ぎます
6. SLA台帳の版の確認 … 契約の変更で目標値が変わっていないか、台帳の適用開始日を確かめます
7. 前月の点検結果の有無 … 初月は前月が無いので、継続課題の照合だけを飛ばします

6番目を軽く見ないでください。 契約を更新して稼働率の目標を上げたのに、台帳が古いままだと、未達を達成と判定します。 台帳には適用開始日の列を持たせ、報告の対象月に合う版だけを渡します。

AIに処理させる

させるのは、SLA台帳の指標ごとに「報告書に何と書いてあるか」を読み取り、測り方が台帳の定義と合っているかを判定することです。 あわせて、あいまいな記述と、前月の継続課題の今月の状況を拾います。

真ん中の行が、この構成でいちばん大事な判定です。 報告書の脚注に「計画停止はすべて除外」とあり、台帳の除外条件が「事前に合意した計画停止のみ」なら、数値がいくつであっても definition_mismatch です。 目標値と比べる前に、比べてよい数字かどうかを決めます。

あいまいな記述は、拾うだけにします。 「概ね安定稼働」が問題かどうかは、その月に障害があったかで変わります。AIには該当箇所を写させ、障害の一覧と並べて人が読みます。

2行目がいちばん起きやすい失敗です。 障害の一覧と計画停止の日時を渡しているので、AIは契約の定義で稼働率を計算し直せてしまいます。計算した値を reported_value に入れた瞬間、委託先が契約どおりに報告していないという事実が消えます。

指示内容を固定する

あなたは情報システム部で、運用の委託先から届いた月次の運用報告書を
契約のサービスレベル（SLA台帳）に照らして点検する立場です。
報告書と添付の一覧に書かれていることだけを根拠にしてください。

【指標ごとにすること】
SLA台帳の指標ごとに、次の4つを書いてください。
1. reported ......... 報告書にその指標の値が書かれているか
2. reported_value ... 書かれている数値と単位を、そのまま写す
3. method_status .... 測り方が台帳の定義・除外条件・集計期間と合うか
   - match ............ 合っていることが記載から読み取れる
   - mismatch ......... 記載された測り方が台帳と違う
   - not_stated ....... 測り方の記載が無い
4. evidence ......... 根拠にした文字列と、そのページ番号

【厳守事項】
- 値が書かれていなければ reported を false にし、reported_value は空にしてください。
  前月の値や、添付の一覧の件数から推測して埋めないでください。
- 稼働率や対応時間を、自分で計算し直さないでください。
  台帳の定義で計算すると違う値になりそうでも、書かれている値を写してください。
  違いそうだと考えた理由は note に書いてください。
- 目標値を満たしているかは判定しないでください。数値の比較は別の工程で行います。
- 「概ね」「順次」「適宜」「安定稼働」「問題なし」のように、数値も期日も無い記述は
  vague_statements にすべて写してください。良し悪しは判断しないでください。
- 前月の継続課題の一覧にある課題ごとに、今月の報告書での記載を探してください。
  記載が無い場合は missing_this_month とし、完了したと推測しないでください。
- evidence には、報告書の文字列を変えずに写してください。要約しないでください。
- 減額、是正の要否、委託先の評価は書かないでください。

【SLA台帳】{sla_ledger}
【前月の継続課題】{carryover_issues}
【計画停止の合意記録】{agreed_maintenance}
【添付の一覧（CSV）】{incident_csv} {inquiry_csv}

「自分で計算し直さない」を明記しないと、親切に計算します。 障害の時刻と計画停止の日時を渡している以上、計算の材料はそろっています。禁じるのは計算の能力ではなく、計算した値を報告値として扱うことです。

「完了したと推測しない」も同じ理由です。 前月「来月中に完了予定」とあった課題が今月の報告に無いと、AIは完了したものとして扱いがちです。記載が無いという事実そのものを、委託先に聞く材料にします。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "vendor_code": "",
  "system_code": "",
  "report_month": "",
  "metrics": [
    { "metric_id": "", "reported": true, "reported_value": "", "unit": "",
      "method_status": "match | mismatch | not_stated",
      "evidence": "", "page": 0, "note": "" }
  ],
  "vague_statements": [ { "text": "", "page": 0 } ],
  "carryover": [
    { "issue_id": "", "status_this_month": "updated | missing_this_month",
      "evidence": "", "page": 0 }
  ]
}

返答の形は、Claude API の構造化出力で固定します。 ドキュメントでは、output_config.format にJSONスキーマを指定すると、返答がスキーマに従うとされています。enum が使えるので、method_status を3つの値に限れます。 オブジェクトには additionalProperties: false を指定する必要があります。

一方で、minimum や maximum のような数値の制約はサポートされていません。 ページ番号が報告書のページ数を超えていないか、reported_value が数値として読めるかは、プログラムの側で確かめます。

最終の判定は、このJSONを受けてプログラムが決めます。

表の上から順に当てはめます。 測り方が違う指標は、数値が目標を満たしていても met にしません。比べてよい数字かどうかを、比べる前に決めるのが、この表の並びの意味です。

根拠の文字列は、プログラムが報告書のテキストと照合します。 evidence が報告書の該当ページに実際にあるかを確かめ、見つからなければ unclear に落とします。 根拠の場所を返す Citations の機能は構造化出力と同時に使えないため、この照合を自前で持ちます。

システムへ連携する

課題管理表へは書き込みません。 この構成が出すのは点検の結果と質問の下書きまでで、課題管理表に何を載せるかは担当者が決めます。委託先と共有している表に、確認前の判定が載るのを避けます。

委託先への送付も自動にしません。 質問の文面は、委託先との関係とその月の事情で変わります。

人が確認する

人が開くのは、not_met ／ definition_mismatch ／ not_reported ／ unclear の行と、missing_this_month の課題だけです。 met の行は、指標名と根拠の文字列を一覧で流し見ます。

1. definition_mismatch を先に見る … 根拠の文字列と台帳の除外条件を並べ、本当に違うかを確かめます。台帳の書き方があいまいなだけのこともあります
2. not_reported を確かめる … 報告書の目次と付録を見て、本当に書かれていないかを確かめます。グラフの中にだけ数字がある報告書は珍しくありません
3. missing_this_month の課題を確かめる … 完了の連絡が別のメールで来ていないかを見ます
4. あいまいな記述を障害の一覧と並べて読む … 障害があった月の「安定稼働」は質問の対象にします
5. 質問を直して送る … 下書きを、定例会で聞くものと書面で聞くものに分けます
6. 判定を覆したら記録する … どの指標を、どちらに変えたかを残します

1番目を省かないでください。 definition_mismatch は、委託先に「契約どおりに測っていない」と伝えることに直結します。 台帳の側の誤りで問い合わせると、次の月から委託先は質問を真剣に読まなくなります。

目標は、1件40分です。 問題ありと出る行が1件あたり数行という想定で、それより多い月は、台帳の除外条件が足りていないか、報告書の書式が変わっています。

例外に対処する

上の3行と5行目で、例外のほとんどを占めます。 どれもAIの問題ではなく、受け取り方と台帳の整備の問題です。 委託先に「パスワードを付けない」「本文と一覧を同じメールで送る」と頼むだけで、半分は消えます。

記録を残す

• 受け取った報告書と添付、受け取った日時
• AIに渡した入力（そのとき使ったSLA台帳の版、前月の継続課題、計画停止の記録）
• AIが返したJSONの全文と、プログラムが付けた判定
• 根拠の照合の結果 … 見つかった／見つからなかった
• 人が判定を覆した記録と、その理由
• 委託先へ送った質問と、回答の日付
• 委託先ごと・指標ごとの判定の推移

2つ目で台帳の版を残すのは、契約が途中で変わるためです。 目標値を見直した月の前後で判定の意味が変わり、当時の基準が残っていないと、過去の未達が本当に未達だったのかを説明できません。

最後の行は、委託先との契約更新の材料になります。 同じ指標で not_reported が3か月続くなら、報告の様式そのものを相談します。