システム変更の諮問会議（CAB）の Teams 会議の記録から、変更ごとの承認・条件付き承認・差し戻しと付いた条件を整理し、変更管理台帳の更新案を作る

処理の起点を決める

CAB の会議が終わり、文字起こしが保存されたことを起点にします。 Teams 会議の Copilot は、会議が終わった後に質問するには文字起こしが必要とされています。CAB は社内の会議なので、毎回の文字起こしを運営要領で決めておきます。

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

CAB は定期的な会議の繰り返しではなく、毎週1回ずつ会議を設定します。 公式のページでは、定期的な会議で後の回の文字起こしが行われると、前の回の Copilot とのやり取りの履歴が使えなくなるとされています。会議のテンプレートで設定をそろえ、1回ずつ招待を送ります。

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

入力データを集める

質を決めるのは、2行目の審議の一覧です。 会議の中で変更の番号が言葉になれば、AIは発言を正しい変更に振り分けられます。一覧には番号・件名・リスクの区分・実施予定日時の4つだけを書き、冒頭に件数を書きます。

【10/13 CAB 審議の一覧（30件）】
RFC-1041 インターネットバンキング 証明書の更新   高  10/18(土) 02:00
RFC-1042 情報系DB 索引の追加                    中  10/16(木) 21:00
RFC-1043 為替連携サーバー OSのパッチ適用          高  10/18(土) 02:00
RFC-1044 営業店端末 帳票の様式の変更             中  10/20(月) 07:00

運営要領には、判定の区分の定義を書き足します。 承認、条件付き承認、差し戻し、保留の4つに加え、「議長の読み上げで決まる」と明記します。 条件付き承認の条件は、「守ること」と「実施の前に済ませること」に分けて言うと決めておきます。

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

会議は、Agent Builder の知識で「その回の CAB」を個別に指定します。 「自分の Teams のチャットと会議」をまとめて選ぶと、すべての会議の文字起こしと予定表を探すとされています。事務局はプロジェクトの会議にも多く出るので、別の会議で話された変更の話が混ざります。 必ず会議を個別に指定し、毎週差し替えます。

前の週の CAB も知識に残します。 会議は5つまで指定できるので、今週と前の3週の4回分を入れておきます。 保留になった変更が今週再審議されたとき、前回の保留の理由と並べて出せます。

「指定した知識だけを使う」設定を有効にします。 Agent Builder の「Only use specified sources」は、指定した知識を優先させる設定で、一般的な知識を完全には止めないとされています。指示の側でも「一般的な変更管理の慣行で補わない」と書いておきます。

AIへ渡す前に整形する

1. CAB を事務局が主催する … 委員や外部委託先から届いた招待は使わず、事務局で設定します
2. 審議の一覧を前日にチャットへ貼る … 番号・件名・リスクの区分・実施予定日時の4つだけにします
3. 変更を番号で呼ぶ … 「では RFC-1043、為替連携サーバーのパッチ適用」と、議題に入るたびに番号を言います
4. 議長が判定と条件を読み上げる … 変更ごとの議論の最後に、判定と条件を1文で言います
5. 会議の終わりに、保留と差し戻しをまとめて読み上げる … 「保留は RFC-1048 と 1052、差し戻しは 1055」と番号だけを言い直します

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

4番目の読み上げは、CAB の運営としても効きます。 委員にとっても、判定がその場で言葉になる場面です。「いえ、その条件だと夜間バッチと重なります」と言われれば、その場で条件を直せます。 読み上げの無い変更は、判定の解釈が会議の後に残ります。

AIに処理させる

させるのは、会議で言葉にされた判定と条件を変更ごとに拾い、決まった区分を付けることだけです。

1行目がいちばん大事です。 委員が「夜間バッチへの影響は大丈夫ですか」と聞き、申請者が「確認済みです」と答えて議長が次に進んだ。これを承認と読むか保留と読むかは、AIにも人にも決められません。 読み上げが無ければ「確認が要る」とし、議長に確かめます。

2行目の「言い換えない」も同じくらい大事です。 条件は、実施の当日に守られたかを確かめる基準です。言葉どおりに残さないと、確かめようがありません。

指示内容を固定する

あなたはシステム部の変更管理グループの担当者を手伝い、
変更諮問会議（CAB）の議事録と、変更管理台帳の更新案を作る立場です。
指定した会議の文字起こしと会議のチャット、変更管理台帳のリスト、
埋め込んだ変更管理規程・運営要領・議事録の様式だけを見てください。
一般的な変更管理の慣行や、他の会議の内容で補わないでください。

【拾うもの】
- 審議の一覧の変更ごとに、変更の番号、判定、守ること、
  実施の前に済ませること（担当・期限）、差し戻しまたは保留の理由、根拠の時刻。
- 一覧にあるが議長の読み上げが無かった変更。
- 一覧に無いが会議で話された変更。

【判定の付け方】
- 判定は、議長がその変更の議論の最後に読み上げた言葉だけで付けてください。
- 承認／条件付き承認／差し戻し／保留 のどれかを、読み上げの言葉どおりに選んでください。
- 議長の読み上げが無い場合は「確認が要る」としてください。
  委員の懸念や申請者の回答から、判定を推し量らないでください。
- 迷ったときに「承認」を選ばないでください。

【条件の書き方】
- 条件は、議長の読み上げの言葉どおりに引用してください。短くしたり、言い換えたりしないでください。
- 時刻、日付、システムの名前、手順書の名前は、そのまま残してください。
- 条件を「守ること」と「実施の前に済ませること」に分けてください。
- 実施の前に済ませることに、担当と期限が言われていなければ「要確認」としてください。

【厳守事項】
- 差し戻しと保留の理由は、議長と委員の発言を引用してください。理由が述べられていなければ「理由の発言なし」とします。
- 変更のリスクを評価したり、実施してよいかを書いたりしないでください。
- 変更の番号は、会議のチャットの一覧と変更管理台帳で特定してください。
  特定できない発言は「要確認」としてください。
- 台帳に書き込まないでください。更新案を表で示すだけにしてください。

【出力】
1. 変更ごとの判定（表。一覧の件数と同じ数）
2. 実施の前に済ませること（担当・期限・変更の番号・実施予定日時）
3. 差し戻しと保留の理由（変更の番号ごとに引用）
4. 台帳の更新案（変更の番号／状態／条件の欄に入れる文）
5. 事務局への注意（確認が要る変更、要確認の箇所、一覧に無く話された変更）

この指示は、エージェントの指示として Agent Builder に書いておきます。 事務局は毎週「今週の CAB の議事録を作って」と頼むだけにします。毎回指示を貼り直すと、担当者によって指示が変わります。

「迷ったときに承認を選ばない」を明記しているのは、誤りの重さが左右で違うからです。 保留を承認と取り違えれば、審議の終わっていない変更が本番に入ります。 承認を保留と取り違えても、議長に確かめれば済みます。

出力形式を固定する

エージェントには、表の形で返させます。 この構成では台帳への自動登録をしないため、JSON ではなく、事務局と議長が読んで直しやすい表を出力の形にします。

【変更ごとの判定（30件）】
| 番号 | 件名 | 判定 | 守ること（引用） | 時刻 |
| RFC-1043 | 為替連携サーバー OSのパッチ適用 | 条件付き承認 | 「実施は土曜の2時から5時に限る。全銀の接続の時間帯にかからないこと」 | 00:21:40 |
| RFC-1044 | 営業店端末 帳票の様式の変更 | 確認が要る | （議長の読み上げなし） | 00:26:10 |

【実施の前に済ませること】
| 番号 | 内容（引用） | 担当 | 期限 | 実施予定 |
| RFC-1043 | 「切り戻しの手順書を更新して運用の確認を受けること」 | 開発グループ 田中 | 10/17(金) | 10/18(土) 02:00 |

【差し戻しと保留の理由】
| 番号 | 判定 | 理由（引用） | 発言者 | 再審議 |
| RFC-1048 | 保留 | 「月末の締めの処理と重なるかが分からない」 | 業務部門の代表 | 10/20 の CAB |

1つ目の理由は、根拠の時刻で文字起こしに戻れることです。 Copilot は、応答に使った情報源を示すとされています。事務局は時刻から発言を開き、読み上げの言葉と照らします。

2つ目は、「実施の前に済ませること」を独立した表にできることです。 この表は、そのまま実施の前日の確認リストになります。期限と実施予定を同じ行に並べておけば、期限が実施の後になっている誤りも目で分かります。

3つ目は、差し戻しの理由を申請者への連絡にそのまま使えることです。 委員の言葉で理由が書かれていれば、申請者は再申請で何を足せばよいかが分かります。

システムへ連携する

台帳にはエージェントから書き込みません。 台帳の状態の欄は、運用の担当が実施の可否を見る欄です。議長の確認を経ていない判定が入ると、確認の前に実施の準備が始まります。

委員には、議長の確認が済んだ議事録だけを配ります。 エージェントの出力そのものは事務局の作業用の資料です。

人が確認する

この構成では、全件を人が確かめます。 判定と条件は、本番への変更の実施を左右するからです。

1. 「確認が要る」の変更を先に見る … 読み上げが無かった変更です。議長にチャットで判定を確かめます
2. 条件付き承認の条件を、文字起こしで確かめる … 根拠の時刻から読み上げを開き、引用が言葉どおりかを見ます
3. 実施の前に済ませることの「要確認」を埋める … 担当と期限が言われていなければ、申請者と決めます
4. 差し戻しと保留の理由を確かめる … 申請者に送る前に、引用が発言どおりかを見ます
5. 議長が議事録を確認する … 確認が済んでから台帳を更新し、申請者に連絡します

1番目と2番目を省かないでください。 判定と条件の誤りは、本番の障害の原因になりえます。 金融庁の分析レポート（2024年6月）は、外部委託先からリリースの作業が遅れていると報告を受けながら、リリースの時間が全銀システムに与える影響を認識しないままリリースを承認した事例を挙げています。条件を言葉どおりに残すのは、この種の見落としを実施の前に拾うためです。

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

例外に対処する

上から2行目が、最初の数週はいちばん多く起きます。 議長が読み上げに慣れるまでは、事務局が「判定をお願いします」と促す決まりにしておくと防げます。

緊急変更の行も、決まりを先に作っておきます。 夜間の障害対応で議長の電話の承認だけで入れた変更は、次の CAB で事後報告として読み上げ、台帳に記録を残します。 読み上げておけば、この構成の出力にも並びます。

記録を残す

• 会議の文字起こしと、会議のチャットに貼った審議の一覧
• エージェントの出力（判定・条件・理由・台帳の更新案）の全文
• 事務局が直した箇所 … どの変更の判定や条件を、どう変えたか
• 議長の確認の記録と、会議の後に議長が変えた判定と条件
• 台帳の更新の記録と、申請者への連絡の日時
• 会議ごとの「確認が要る」の件数

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

最後の行は、CAB の運営の質を測る数字になります。 「確認が要る」が減っていけば、議長の読み上げが定着したということです。