社内申請の不備を、AIとの対話で提出前に埋めさせて差し戻しを減らす

処理の起点を決める

申請者がTeamsでエージェントに話しかけたときに始まります。 定時実行にはしません。申請が発生するのは申請者の都合であって、総務の都合ではないからです。

入口はTeamsの1対1のチャットに限ります。 グループチャットとチャネルでは、SharePoint のようにエンド ユーザー認証を必要とする知識源が使えません。これは設計上の制限で、意図しないデータの漏えいを防ぐためのものです。 規程の閲覧範囲が役職や所属で分かれている以上、1対1以外で動かす選択肢はありません。

Teamsで使うには、エージェントを少なくとも1回公開したうえで、Teams と Microsoft 365 Copilot チャネルに接続します。 そのあと、管理者の承認を得てTeamsアプリストアの「組織用に構築」の区画に載せ、アプリのセットアップ ポリシーで自動インストールとピン留めをしてもらえば、アプリ バーから直接開けます。

トリガーフレーズは、様式名で書かないでください。 申請者は「旅費精算申請書（様式第12号）」とは打たず、「タクシー代を精算したい」「はんこをもらいたい」と打ちます。利用者の応答を理解するようAIを訓練するには5〜10個のトリガーフレーズが必要とされ、長文ではなく短い語句が推奨されています。 1行に1つ書いたファイル（最大3MB）で追加できるので、過去の問い合わせメールの件名が素材になります。

入力データを集める

質を決めるのは、太字にした3つです。 様式マスタに必須項目と必要な添付が入っていなければ、対話で聞くことが決まりません。「様式を選ぶ」まではできても、「何を埋めるか」が出てきません。 承認ルート表は、申請種別と金額帯と部門の組み合わせに承認者の並びが1つ決まる形にし、金額帯は境目をどちらに含めるかまで書き切ります。

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

規程と様式の説明は、Copilot Studio のナレッジとして読ませます。 SharePoint を知識源として追加すると、エージェント利用者の Microsoft Entra ID 認証が働き、その利用者がアクセスできるコンテンツのみが表示されます。

下の3行をナレッジに入れないのが、この構成の要点です。 ナレッジ（生成回答）は文章を読んで答えを作る仕組みで、表を読ませると、表の内容を根拠にした「それらしい答え」が返ります。 引き方は、公開したエージェント フローをツールとして追加し、オーケストレーターに実行時に呼ばせる方法を想定します。 前提として、フローには「エージェントがフローを呼び出すとき」のトリガーと「エージェントに応答する」アクションが必要です。追加のときに、いつそのフローを使うべきかを理解できる明確な説明を書きます。「承認ルートを取得する」だけでは規程の質問でも呼ばれるので、「申請種別と金額と部門が確定したあとに引く」と、呼ぶ条件まで書きます。

AIへ渡す前に整形する

1. 様式マスタを作る … 様式コード、様式名、用途、必須項目、必要な添付、提出先を1行にします。ここが最大の準備作業です
2. 承認ルート表を1枚の表に直す … シートが分かれているExcelを1行1組み合わせにし、金額帯は「以上」「未満」を明記します
3. 規程を条単位に切る … 条番号を持たせます。切らないと、根拠が「就業規程に書かれています」で終わります
4. 廃止された様式を索引から外す … 共有フォルダに残っている旧版が、いちばんよく引かれます
5. 言い換えを集める … 「立替」「精算」「仮払」、「はんこ」「押印」「捺印」のような言い方を洗い出します
6. 規程に書かれていない運用を洗い出す … 慣行で回っているものを、規程に書くか「総務へ回す」対象にするかを決めます

5番目は、クローズド リスト エンティティのシノニムとして登録できます。 各値に同義語を加えてマッチングのロジックを広げられ、1行1値・パイプ（|）区切り・最大3MBのファイルからアップロードできます。スマート マッチングを有効にすると、エージェントは曖昧な論理で入力を解釈し、スペルミスを自動修正し、マッチングのロジックを意味的に拡張します。 便利ですが、費目のように取り違えてほしくないリストでは、有効にするかを一度考えてください。

6番目を飛ばすと、導入後に必ず跳ね返ってきます。 規程に無い運用は、対話では答えが出ません。「答えられないもの」として先に名指ししておくことが、作り話を防ぐいちばん確実な方法です。

AIに処理させる

「まだ埋まっていないものだけ」を実現するのが、プロアクティブ スロット フィリングです。 利用者が一度に複数の情報を伝えたときに、どの情報がどのエンティティに属するかをエージェントが理解し、すでに埋まった項目の質問ノードを飛ばします。 「先週の火曜に客先に行ったタクシー代3,200円を精算したい」には日付・用途・金額が入っており、3つとも聞き直すエージェントは、その時点で使われなくなります。 逆に毎回必ず確かめたい項目は、「質問をスキップする」を「毎回尋ねる」にします。

上から2行目が、いちばん起きやすい失敗です。 「10万円以上は部門長の承認が必要」と規程にあれば、AIは10万円ちょうどの申請にも答えを出します。表を引かせれば、この揺れは起きません。

指示内容を固定する

エージェントの指示として、次の内容を書きます。

あなたは総務部の申請受付の担当者です。
社員が出そうとしている社内申請を、提出する前に対話で完成させることが役割です。
申請を代わりに提出することはしません。埋め終わった内容は本人が確認して出します。

【進め方】
1. 用件を聞いて、どの様式で出すべきかを様式マスタから1つに絞る。
   2つに絞れなければ違いが分かる質問を1つだけし、3つ以上残れば総務へ回す。
2. 決めた様式の必須項目のうち、まだ埋まっていないものだけを1つずつ聞く。
   すでに本人が書いた内容から読み取れる項目は、聞き直さない。
3. 必要な添付を、何を・何枚・どの形式でかまで伝える。
4. 承認ルートは、承認ルートを引くツールを呼んで得た結果だけを返す。
5. 最後に、埋まった内容と根拠の一覧をまとめて出す。

【根拠の示し方】
- すべての回答に、どの規程の何条か、どの様式かの引用を本文内に必ず含める。
- 引用を付けられない内容は回答しない。総務の担当へ回す。

【厳守事項】
- 承認者と承認の順番を、自分で考えないでください。
  規程の文章から読み取れたとしても、ツールの結果以外を返さないでください。
- 金額の閾値を、自分で判断しないでください。
  「10万円以上」「10万円未満」のどちらに当たるかは、ツールの結果に従ってください。
- 規程と様式マスタに書かれていないことを聞かれた場合は、
  推測で答えず「規程に記載が見つかりません」と伝え、総務の担当へ回してください。
  過去の慣行、他社の運用、一般的な商習慣を根拠にしないでください。
- 例外を認めてよいかを答えないでください。「今回だけ」の可否は総務が決めます。
- その申請が必要かどうか、金額が妥当かどうかを評価しないでください。
- 申請を提出しないでください。提出するのは本人です。
- 金額・日付・氏名を、本人が言っていない値で補わないでください。

【参照するもの】
様式マスタ：{form_master}／承認ルート：ツールの戻り値のみ／規程：ナレッジのみ

「ツールの結果以外を返さない」を2か所に書いているのには理由があります。 承認ルートは規程にも書かれているので、禁じるだけでは「規程によれば部門長です」と答えます。 答えの出どころを1つに固定することが目的です。

引用については、ドキュメントに具体的な助言があります。 指示でモデルに必ず出典を明記するよう書くことが推奨され、例として「すべての文に対して必ず出典への本文内引用を含める」が挙げられています。逆に、「JSONでのみ応答する」のような厳格な出力形式を強制すると、エージェントが必要とする引用マーカーが抑制されるとされています。対話は引用つきの文章で行い、構造化は最後に別のノードで作ります。

出力形式を固定する

対話が終わった時点で、次の形にまとめます。

{
  "request_id": "",
  "requester": { "upn": "", "department": "", "site": "" },
  "form": { "code": "", "name": "", "source": "" },
  "fields": [
    { "key": "", "value": "", "status": "filled | missing | unknown", "source": "" }
  ],
  "attachments": [
    { "name": "", "count": 1, "status": "ready | missing", "source": "" }
  ],
  "approval_route": {
    "resolved_by": "table", "threshold_key": "",
    "approvers": [], "table_version": ""
  },
  "unanswered": [
    { "question": "", "reason": "not_in_policy | ambiguous", "handoff": "soumu" }
  ],
  "ready_to_submit": false
}

作り方は、値の解析ノードを使う想定です。 このノードはある型から別の型へ値を変換するもので、サンプルJSONからスキーマを取得して、レコード型の変数に変換できます。 フローの戻り値をこの形で受け、対話で埋めた変数と合わせて1つにします。

source に何を入れるかが、この形のいちばん大事なところです。 様式なら様式コード、記載事項なら規程の条番号を入れます。根拠の無い値がここで見つかります。 画面には項目ごとに source を並べ、申請者が「なぜこれが要るのか」を確かめられるようにします。

approval_route.resolved_by は必ず table です。 設計上、ここに table 以外が入ることはありません。入っていたら、モデルが承認ルートを作ったということなので、その場で止めます。 table_version を持つのは承認ルート表が改定されるからで、引いた時点の版が無いと、表が変わったのか引き方が誤ったのかを切り分けられません。

ready_to_submit を true にするのは、fields と attachments に missing が無く、approvers が空でなく、unanswered が空のときだけです。 埋まっているかどうかではなく、答えられなかった問いが残っているかどうかも見ます。

システムへ連携する

いちばん下の行が、この構成の輪郭です。 申請システムに書き込まないので、誤って申請が出る経路がありません。 差し戻しの記録だけは書き込みますが、書く内容は未回答の問いと、最後まで埋まらなかった項目だけです。 対話の全文は書きません。

公開のたびに管理者の再承認が要るわけではありません。 再承認が必要なのはアイコンや説明といった詳細を変える場合だけとされているので、様式マスタや規程の入れ替えはいつでも反映できます。

人が確認する

この構成で人が確認する場所は、3つあります。

1. 申請者が、下書きを確認して自分で出す … 必須です。埋まった内容と根拠の一覧を読み、自分の申請として出します。AIは提出しません
2. 総務が、提出された申請の内容そのものを見る … 260件すべてです。この時間は減りません。 減るのは、様式・記載事項・添付・承認ルートの確認の時間です
3. 総務が、月に1回、未回答と差し戻しの記録を読む … 何が答えられなかったか、どの様式で何の不備が残ったかを見ます

2番目を減らそうとしないでください。 その出張が必要か、その金額が妥当かは、規程を引いても出てきません。 第10章の削減率が50.0％にとどまるのは、ここを残しているからです。3番目は、月に1時間ほどの作業として組み込みます。 未回答の一覧には規程に書かれていない運用が名前つきで並び、そのいくつかは、規程に1行足せば翌月から答えられるようになります。

承認ルートを人が上書きしたときも記録します。 表から引いた並びを総務が変えたのなら、表が間違っているか、表に無い組み合わせが来たかのどちらかです。

例外に対処する

上から5行目は、仕様として理解しておく必要があります。 「根拠のない応答を許可する」をオフにすると、エージェントは知識源やツールを使わなかったターンで生成した応答をブロックし、フォールバック トピックを起動します。 作り話を止めるための設定です。ただし、この動作は断続的になります。 モデルが正しい答えを生成しても引用を含めないことがあり、その場合は情報が見つからなかったかのように反応します。 指示に「必ず本文内引用を含める」と書き、出力形式で引用を潰さないことが、ここで効いてきます。

記録を残す

• 対話の記録（プロンプトと応答は統合監査ログにキャプチャされます）
• 埋まった内容のJSONと、そのとき参照した様式マスタと承認ルート表の版
• unanswered の一覧 … 規程に無いと判断した問いの全文
• 承認ルートを人が上書きした記録 … 何を、どう変えたか
• 様式ごと・理由ごとの差し戻しの件数（月次）
• 引用が返らずに回答が止まった回数

2番目で「そのときの版」を残すのは、改定があるためです。 承認ルート表を直すと、過去に出した下書きの承認者が今の表と合わなくなります。版が残っていないと、どの下書きを出し直させるべきかが決まりません。 そして3番目が、この構成でいちばん価値のある記録です。 規程に書かれていない問いが申請者の言葉のまま並ぶので、総務が想像で規程を直すのではなく、実際に聞かれた問いから直せます。