社内システムの改修・設定変更を出すたびに、変更のチケットと仕様メモから、利用者に向けたお知らせ文（変わること・影響・対応が要ること・問い合わせ先）を作る

処理の起点を決める

変更の担当者が、作業の日程が決まったチケットについてエージェントを開くことを起点にします。 チケットが作られた時点ではなく、日程が決まった時点にするのは、お知らせに一番大事な日時がそれまで決まらないからです。 日程が決まる前に書くと、日時の欄が【要確認】のまま下書きが残り、出す直前に書き直すことになります。

自動では動かしません。 チケットの状態が変わったら自動で下書きを作る、という作り方もできますが、改修・設定変更のうち利用者に知らせる必要があるものは一部です。知らせるかどうかの判断を先に担当者がしてから、エージェントを開きます。 知らせなくてよい変更まで下書きが出ると、出さない下書きを捨てる手間が増えます。

出す日の目安を、変更の種類ごとに決めておきます。 画面が変わるものは作業の5営業日前、停止を伴うものは3営業日前、といった目安です。

入力データを集める

質を決めるのは、2行目のお知らせ用の入力欄です。 チケットの本文は作業の記録なので、利用者に関わることが散らばっています。停止の時間、利用者の対応、問い合わせ先の3つは、担当者に欄として書いてもらいます。 AIに本文から探させると、見落としたときに「無い」のか「書いていない」のかが分かりません。

言い換えの表は、この構成でいちばん効く知識です。 「IdP」「閾値」「キャッシュをクリア」「SSO」のような言葉と、利用者向けの言い方（「社内のログイン画面」「この金額以上」「ブラウザの履歴を消す」「1回のログインで複数のシステムに入れる仕組み」）を並べた表です。部署で使われている言い方に合わせて、ヘルプデスクが育てます。

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

最小構成と半自動化では、担当者がチケットの内容をエージェントへ貼り付けます。 Jira の画面からチケットの本文と入力欄を写し、仕様メモは SharePoint のファイルを添付します。貼り付けは1件1分ほどで、チケットの中で何を渡すかを担当者が選べる利点があります。社外の取引先の名前や、セキュリティの設定値のように、お知らせに関係のないものを渡さずに済みます。

手本と利用部署の一覧は、エージェントの知識として持たせます。 毎回添付するのではなく、エージェントを作るときに一度指定すれば、担当者は意識しなくて済みます。 SharePoint に新しく置いたファイルは、使えるようになるまで数分かかることがあり、その間は「Preparing」と表示されるとされています。手本を入れ替えた直後に試すときは、表示が消えてから確かめます。

本格構成では、Copilot connectors で Jira のチケットを知識に加え、プロジェクトを指定して範囲を絞ります。

AIへ渡す前に整形する

1. お知らせ用の入力欄を埋める … 停止の有無と時間、利用者の対応の有無、問い合わせ先。空のまま渡すと、【要確認】が多い下書きになります
2. チケットの本文から、お知らせに関係のないものを外す … 取引先の担当者名、設定の値そのもの、作業者の名前、確認の手順の細部
3. 仕様メモの版を確かめる … 古い版を添付すると、変わる前の仕様でお知らせが書かれます。ファイル名か本文の先頭に版と日付を入れる決まりにします
4. 複数のチケットをまとめるかを決める … 同じ日に同じシステムで3件の変更がある場合、お知らせは1本にまとめます。まとめるときは、チケットを全部同時に渡します
5. 利用部署の一覧が最新かを、月に1回見直す … 一覧が古いと、送る先の候補が古くなります

2番目を省かないでください。 チケットは作業者のための記録で、利用者が知らなくてよいこと、知られてはいけないことが混ざっています。 認証まわりの変更なら、設定の値そのものは外に出すものではありません。

AIに処理させる

させるのは、チケットの事実を利用者の行動に置き換えて、決まった並びの下書きにすることです。 作業の手順や技術的な理由を説明させるのではありません。

右端の列が、この構成でいちばん大事な決まりです。 お知らせの下書きを作らせると、生成AIはそれらしい日時や「再ログインは不要です」のような一文を補って、文章を完成させようとします。書かれていないことを書くと、間違ったお知らせが整った文章で出ます。 補わずに【要確認】と出させ、それを担当者への聞き返しにします。

4行目は起きやすい失敗です。 「セキュリティ強化のため」「利便性向上のため」と書かせると、理由が実際と違っていても、もっともらしく読めてしまいます。 チケットに書かれた理由だけを使わせます。

指示内容を固定する

エージェントの指示（Agent Builder の指示の欄）に、次のように書きます。

あなたは情報システム部で、社内システムの改修・設定変更を利用者に知らせる
お知らせ文の下書きを作る担当です。読む人は、システムに詳しくない社員です。

【使ってよい材料】
- 担当者が貼り付けたチケットの本文と、お知らせ用の入力欄
- 担当者が添付した仕様メモ
- 知識として登録された、過去のお知らせの手本、システムと利用部署の一覧、
  書き方の基準と言い換えの表
これ以外の情報で、日時・対象・手順を補わないでください。

【本文の並び（必ずこの順）】
1. 件名：【システム名】変わること（日付）
2. 何が変わるか（利用者から見た変化を2〜3文）
3. いつから（日時。停止がある場合は停止の時間と使えない機能）
4. あなたがすること（対応が要る／知っておくだけ／対応は不要 のどれか）
5. 変わらないこと（利用者が心配しそうな点で、変わらないもの）
6. 問い合わせ先

【厳守事項】
- 日時、停止の時間、対応の期限、問い合わせ先が材料に無いときは、
  【要確認：何が無いか】と書いてください。推測で埋めないでください。
- 「対応は不要です」は、入力欄に対応不要と書かれているときだけ書いてください。
  入力欄が空なら【要確認：利用者の対応の有無】と書いてください。
- 変更の理由は、チケットに書かれているときだけ書いてください。
  「セキュリティ強化のため」などを補わないでください。
- 言い換えの表にある言葉は、表の言い方に置き換えてください。
  表に無い専門用語は残し、unreplaced_terms に挙げてください。
- 設定の値、サーバー名、作業者の名前、取引先の名前を本文に書かないでください。
- 影響する部署は、システムと利用部署の一覧にあるものだけを候補にしてください。
- 想定問答の答えが材料に無いときは、answer を「担当者に確認」にしてください。
- お知らせを出すべきか、誰に送るべきかの結論は書かないでください。

【出力】指定のJSONの形で返してください。

担当者が会話の欄に入れるのは、次の一文と材料だけです。

次のチケットについて、お知らせの下書きを作ってください。
【チケット】{チケットの本文と、お知らせ用の入力欄を貼り付け}
【仕様メモ】{添付}
【まとめるチケット】{同じ日に出すチケットがあれば、ここに続けて貼る}

「対応は不要です」を条件付きにしているのが、この指示の要です。 何も言わないと、利用者の対応が書かれていないチケットから「特に対応は不要です」と書きます。読む側にとって一番安心させる一文が、根拠なしに入ることになります。 入力欄に書かれているときだけ許します。

エージェントは指示に従いますが、知識の外を完全に遮断はしません。 「指定したソースのみを使用する」の設定は、指定した知識を優先させるもので、一般的な知識を遮断するものではないとされ、より厳しく制御するなら Copilot Studio を使うよう案内されています。この構成では、【要確認】の一覧と担当者の確認で補います。

出力形式を固定する

次の形のJSONで返させ、担当者が読む画面では本文とそれ以外を分けて表示します。

{
  "ticket_ids": ["ITCHG-1234"],
  "system": "経費精算",
  "change_type": "rule_change | screen_change | outage | retirement | setting_change",
  "user_action": "required | awareness | none | unknown",
  "teams_post": "",
  "mail_body": "",
  "subject": "",
  "affected_departments": [
    { "department": "", "reason": "", "source": "利用部署の一覧の行" }
  ],
  "needs_confirmation": [
    { "field": "outage_time", "note": "チケットに停止の時間の記載がない" }
  ],
  "unreplaced_terms": [""],
  "faq": [
    { "question": "", "answer": "", "basis": "チケットまたは仕様メモの該当箇所" }
  ]
}

1つ目の理由は、needs_confirmation を本文から切り離せることです。 本文の中に【要確認】が埋もれていると、確かめ漏れが起きます。一覧として外に出せば、空になるまで出さない、という決まりが守れます。

2つ目は、user_action で読む側の扱いを変えられることです。 required のものはメールの件名の先頭に【要対応】を付け、awareness のものは Teams のチャネルだけにする、といった分け方ができます。unknown は、入力欄が空だったということで、そのまま出してはいけない印です。

3つ目は、faq の basis で想定問答の根拠を確かめられることです。 根拠の無い答えはヘルプデスクを誤らせます。basis が空の答えは、ヘルプデスクへ渡す前に担当者が埋めます。

システムへ連携する

この構成から、どこにも自動で書き込みません。 Agent Builder で作ったエージェントは、公開資料では Teams のグループチャットや1対1のチャットでは使えないとされています。エージェントは Microsoft 365 Copilot の画面で開き、出てきた本文を担当者がチャネルとメールに貼ります。 自動で投稿させない理由は、第13章で書きます。

チケットへの書き戻しもしません。 どのお知らせを出したかは、担当者がチケットに投稿のリンクを貼ることで残します。

人が確認する

下書きは、すべて変更の担当者が確かめます。 見るところは決まっています。

1. needs_confirmation を空にする … 日時、停止の時間、対応の期限、問い合わせ先。空にならないうちは出しません
2. 日時を、チケットの作業の日時と突き合わせる … 曜日と時刻まで見ます。下書きの日時がチケットと1文字でも違えば、チケットを正とします
3. 「あなたがすること」を読む … 自分が利用者だったら、これを読んで何をするかが分かるかを見ます
4. 送る先を決める … affected_departments の候補を見て、足すか削るかを決めます
5. 想定問答の basis を見る … 根拠の無い答えを直します
6. 部長に回すかを決める … 停止を伴うもの、全社に出すもの、規則が変わるものは、部長が見ます

2番目を省かないでください。 下書きの日時は、チケットの日時を写したものですが、まとめたチケットの日時を取り違える、曜日を付け間違える、ということが起こります。 お知らせの誤りで一番重いのが日時です。

目標は、1件をならして16分です。 下書きの確認と直しに10分、【要確認】を埋めるのに4分、貼り付けと投稿に2分という見込みです。needs_confirmation が毎回多いなら、入力欄の埋め方を見直します。

例外に対処する

下から2行目を、運用の最初に決めてください。 障害やセキュリティの事故の連絡は、出す内容と時期を部長や関係部署と詰めるもので、下書きの速さより正確さと判断が先です。 このエージェントは、計画された変更のお知らせに限ります。

記録を残す

• 出したお知らせの本文（Teams の投稿とメール）と、もとのチケットの番号
• エージェントが出したJSON（下書き、needs_confirmation、affected_departments、faq）
• 担当者が直した箇所 … 日時、送る先、言い換え、「あなたがすること」の一文
• 出した日時と、送った部署
• お知らせを出した後の問い合わせの件数と内容（ヘルプデスクが、お知らせごとに記録する）
• unreplaced_terms の月ごとの集計

3つ目の「直した箇所」が、指示と手本を直す材料になります。 毎回同じところを直しているなら、指示か手本のどちらかに問題があります。

5つ目の問い合わせの記録は、お知らせの出来を測る唯一の物差しです。 同じ質問が多く来たお知らせは、想定問答か本文のどちらかに抜けがあります。その質問を、次のお知らせの想定問答の手本にします。