委託先との障害の振り返り会議（Teams）の記録から、原因・暫定対処・再発防止策と期限を議事録にまとめ、対策管理表の更新案を作る

処理の起点を決める

振り返り会議が終わり、文字起こしが保存されたことを起点にします。 Teams 会議の Copilot は、会議の後にプロンプトを送ったり、会話の履歴を見たりするには、文字起こしがオンになっている必要があるとされています。振り返り会議は記録を残す会議なので、毎回の文字起こしを規程で決めておきます。

運用管理グループの会議ポリシーは、Copilot を「On with saved transcript required」にします。 この値にすると、主催者の会議オプションが「会議中と会議後」になり、主催者は変えられないとされ、これが既定の値です。文字起こしを付け忘れた回に Copilot が使えない、という事故を、設定の側で防ぎます。

振り返り会議は、障害ごとに1回ずつ設定します。 委託先ごとの定例の会議の繰り返しに乗せると、公式のページにあるとおり、後の回の文字起こしが行われた時点で、前の回の Copilot との会話の履歴が使えなくなります。 定例の会議で障害を振り返る場合も、振り返りの回だけは別の会議として設定します。

エージェントを動かすのは、会議の後1時間以内の手作業です。 担当者は会議に出ていたので、出力のおかしな箇所に記憶で気づけます。翌日に回すと、言葉の強さを記憶で確かめられなくなります。

入力データを集める

質を決めるのは、2行目の障害の基本情報です。 障害番号と時刻が会議の前にチャットにあれば、エージェントは会議の発言を正しい障害と時刻に結び付けられます。基本情報には次の5つだけを書き、委託先の経過のメモは別の添付にします。

【障害の基本情報】
障害番号：INC-2026-1012-03
対象：EC サイト（委託先：A社）
発生：10/09(木) 19:42　検知：19:55（お客様の問い合わせ）　復旧：21:10
影響：注文の確定画面でエラー。約1時間30分、注文の一部が確定できない
前回までの同じ委託先の振り返り：INC-2026-0921-01、INC-2026-0930-02

障害管理規程には、区分の定義を書き足します。 原因は「確定（再現または証跡で確かめた）」「推定（証跡はあるが確かめていない）」「調査中」の3つ。対策は「実施済み」「実施を約束（担当・期限あり）」「検討（結論の期限あり）」の3つです。「検討」にも、結論を出す期限を付けると決めておきます。

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

会議は、Agent Builder の知識で個別に指定します。 「自分の Teams のチャットと会議」をまとめて選ぶと、すべての会議の文字起こしと予定表を探すとされています。担当者は委託先との定例や社内の会議にも多く出るので、別の会議で出た対策の話が混ざります。 必ず会議を個別に指定し、振り返りのたびに差し替えます。

指定できる会議は5つまでです。 今回の会議と、同じ委託先の直近の振り返り会議を最大4回分入れます。前回より前の約束は、対策管理表のリストから引けるので足ります。

「指定した知識だけを使う」設定を有効にします。 Agent Builder の「Only use specified sources」は、指定した知識を優先させる設定で、一般的な知識を完全には止めないとされています。指示の側でも「一般的な障害対策の例で補わない」と書いておきます。 補われると、会議で誰も言っていない「監視の強化」が対策の欄に入ります。

AIへ渡す前に整形する

1. 振り返り会議を自社が主催する … 委託先から届いた招待は使わず、運用管理グループで設定します
2. 障害の基本情報を前日にチャットへ貼る … 障害番号・対象・時刻・影響・前回までの振り返りの5つにします
3. 会議の冒頭で障害番号を言う … 「INC-2026-1012-03 の振り返りを始めます」と言い、記録の頭を決めます
4. 原因と対策ごとに区分を読み上げる … 担当者が「これは推定、確定は10月20日まで」「これは実施の約束、担当はA社の佐藤さん、期限は10月31日」と言い直します
5. 会議の終わりに、約束した対策だけを読み上げる … 「約束は3件、検討は2件です」と件数と担当を言い直します

どれも、会議の進め方の決まりです。 システムの前処理ではなく、担当者が会議の中で行う前処理です。この構成では、ここを整えるほうが指示を工夫するより効きます。

4番目の読み上げは、委託先との関係にも効きます。 担当者が「これは実施の約束でよいですか」と言えば、委託先の責任者がその場で「検討にしてください」と言い直せます。 会議の後に議事録で区分が食い違うより、角が立ちません。

AIに処理させる

させるのは、会議で言葉にされた原因・対策とその区分を拾い、決まった欄に並べることだけです。

1行目がいちばん大事です。 委託先の担当者が「次のリリースまでに監視の閾値を見直す方向で考えています」と言った。これを約束と読むか検討と読むかは、AIにも人にも決められません。 区分の読み上げが無ければ「区分の確認が要る」とし、担当者が委託先に確かめます。

2行目も同じくらい大事です。 原因の区分は、その障害を閉じてよいかを決める基準です。推定のまま閉じた障害は、同じ型の障害が次に起きたときに「原因は分かっていたはず」という話になります。

指示内容を固定する

あなたは情報システム部の運用管理グループの担当者を手伝い、
システムの委託先と行う障害の振り返り会議の議事録と、対策管理表の更新案を作る立場です。
指定した会議の文字起こしと会議のチャット、対策管理表のリスト、
埋め込んだ障害管理規程・委託先管理の要領・議事録の様式だけを見てください。
一般的な障害対策の例や、指定していない会議の内容で補わないでください。

【拾うもの】
- 経過：発生・検知・連絡・暫定対処・復旧の時刻と出来事。
- 原因：発言の引用、区分（確定／推定／調査中）、推定と調査中は確定の期限。
- 暫定対処：実施済みと未実施に分けた引用。
- 再発防止策：発言の引用、区分（実施を約束／検討）、担当会社、担当者、期限。
- 前回までの対策：対策管理表のうち、同じ委託先で状態が未完了のもの。
- 業務部門の代表からの要望。

【区分の付け方】
- 区分は、会議で読み上げられた区分の言葉だけで付けてください。
- 「対応します」「検討します」「持ち帰ります」などの言い方から、区分を推し量らないでください。
  読み上げが無い場合は「区分の確認が要る」としてください。
- 迷ったときに、原因を「確定」に、対策を「実施を約束」にしないでください。

【書き方】
- 原因と対策は、発言の言葉どおりに引用してください。短くしたり、言い換えたりしないでください。
- システムの名前、処理の名前、設定の値、日付は、そのまま残してください。
- 担当か期限が言われていなければ「要確認」としてください。
- 根拠にした発言の時刻と発言者を、行ごとに付けてください。

【前回までの対策】
- 対策管理表から、同じ委託先で状態が「完了」以外の対策を引いてください。
- そのうち、今回の原因の発言と同じシステム・同じ処理の名前が出てくるものだけを挙げ、
  名前が出てくる発言を引用してください。関係を推し量って挙げないでください。

【厳守事項】
- 対策が十分か、委託先に責任があるかは書かないでください。
- 対策管理表に書き込まないでください。更新案を表で示すだけにしてください。

【出力】
1. 経過（時刻の順の表）
2. 原因（引用・区分・確定の期限・時刻）
3. 暫定対処（実施済み／未実施）
4. 再発防止策（引用・区分・担当会社・担当者・期限・時刻）
5. 前回までの未完了の対策で、今回と同じ名前が出てくるもの
6. 対策管理表の更新案
7. 担当者への注意（区分の確認が要る箇所、要確認の箇所）

この指示は、エージェントの指示として Agent Builder に書いておきます。 担当者は毎回「この会議の振り返りの議事録を作って」と頼むだけにします。担当者3名が毎回指示を貼り直すと、人によって区分の付け方が変わります。

「迷ったときに確定や約束にしない」を明記しているのは、誤りの重さが左右で違うからです。 検討を約束と取り違えれば、委託先は約束していない期限で催促され、関係がこじれます。約束を検討と取り違えても、委託先に確かめれば済みます。

前回までの対策を「同じ名前が出てくるもの」に絞るのも同じ理由です。 関係を推し量らせると、委託先の未完了の対策がすべて今回の障害と関係があるように並びます。 名前の一致という確かめられる基準にしておけば、担当者は引用を見て判断できます。

出力形式を固定する

エージェントには、表の形で返させます。 この構成では対策管理表への自動登録をしないため、JSON ではなく、担当者と委託先の責任者が読んで直しやすい表を出力の形にします。

【原因】
| 区分 | 内容（引用） | 確定の期限 | 発言者 | 時刻 |
| 推定 | 「受注確定のバッチが19時40分に二重に起動し、在庫の引当てがロックで待たされたと見ています」 | 10/20(月) | A社 佐藤 | 00:12:30 |

【再発防止策】
| 区分 | 内容（引用） | 担当会社 | 担当者 | 期限 | 時刻 |
| 実施を約束 | 「ジョブの起動に排他の確認を入れる修正を、10月31日のリリースに含めます」 | A社 | 佐藤 | 10/31(金) | 00:31:05 |
| 検討 | 「注文の確定画面のタイムアウトの値の見直し」 | A社 | 要確認 | 結論 10/24(金) | 00:36:40 |
| 区分の確認が要る | 「監視の閾値を見直す方向で考えています」 | A社 | 要確認 | 要確認 | 00:39:15 |

【前回までの未完了の対策で、今回と同じ名前が出てくるもの】
| 対策の番号 | 障害番号 | 内容 | 期限 | 状態 | 今回の発言（引用） |
| CM-0921-02 | INC-2026-0921-01 | 受注確定のバッチの起動時刻の分散 | 10/10(金) | 未完了 | 「受注確定のバッチが…」（00:12:30） |

1つ目の理由は、時刻で文字起こしに戻れることです。 Copilot の会議での応答は、チャットのメッセージと文字起こしのどこを使ったかを示すとされています。担当者は時刻から発言を開き、引用と区分を照らします。

2つ目は、「区分の確認が要る」を独立した行にできることです。 この行は、そのまま委託先の責任者に確かめる質問の一覧になります。議事録の案を送るときに、この行だけを先に聞けば、往復が1回で済みます。

3つ目は、前回までの対策と今回の発言を同じ表に並べられることです。 例の表では、期限を過ぎた未完了の対策と同じバッチの名前が、今回の原因に出てきています。 この1行が、振り返り会議でいちばん重い論点になります。

システムへ連携する

対策管理表にはエージェントから書き込みません。 この表は、期限の前に委託先へ進み具合を問い合わせる根拠になります。委託先の確認を経ていない約束が入ると、催促の根拠が揺らぎます。

業務部門には、委託先の確認が済んだ議事録だけを配ります。 エージェントの出力そのものは担当者の作業用の資料です。

人が確認する

この構成では、全件を人が確かめます。 原因の確度と対策の約束は、委託先との約束事そのものだからです。

1. 「区分の確認が要る」を先に見る … 区分の読み上げが無かった原因と対策です。委託先の責任者に区分を確かめます
2. 原因の区分を文字起こしで確かめる … 根拠の時刻から発言を開き、推定を確定と取り違えていないかを見ます
3. 約束した対策の担当と期限を確かめる … 引用の中に担当と期限の言葉があるかを見ます。「要確認」は委託先と決めます
4. 前回までの対策の行を確かめる … 同じ名前が出ていても、関係が無ければ議事録から外します
5. 委託先の責任者が議事録を確認する … 確認が済んでから表を更新し、業務部門と上長に共有します

1番目と2番目を省かないでください。 区分の誤りは、障害を閉じてよいかの判断と、委託先との約束の範囲を左右します。

目標は、1件あたり20分です。 録画の見返しが無くなり、確かめる箇所が時刻で示されることで、見る場所が決まります。

例外に対処する

上から2行目が、最初の数週はいちばん多く起きます。 担当者が読み上げに慣れるまでは、会議の終わりの「約束は何件、検討は何件」を必ず言う決まりにしておくと、抜けた区分がそこで見つかります。

3行目は、担当者が会議で「これはどちらが持ちますか」と聞く決まりにします。 担当会社の無い対策は、どちらも実施しません。

記録を残す

• 会議の文字起こしと、会議のチャットに貼った障害の基本情報
• エージェントの出力（経過・原因・対策・前回までの対策・更新案）の全文
• 担当者が直した箇所 … どの原因や対策の区分を、どう変えたか
• 委託先の責任者の確認の記録と、会議の後に委託先から届いた追加の報告
• 対策管理表の更新の記録と、期限の前に送った問い合わせの日時
• 会議ごとの「区分の確認が要る」の件数

エージェントの出力は、議事録とは別に保存します。 Copilot との会話の履歴は、文字起こしが使えなくなると消えるとされています。出力を Word の別ファイルとして、障害ごとのフォルダに置きます。

最後の行が減っていけば、区分を会議の中で言い切る習慣が定着したということです。