新しい稟議を起案・審査するときに、過去の稟議と決裁時のコメントから似た案件を探し、付いた条件と判断の理由を稟議番号付きで返す

処理の起点を決める

トリガーは2つあります。 1つは審査担当が前例検索の画面で稟議番号を指定したときで、検索とまとめはこのときだけ動きます。審査に回ってきた全件で自動的に動かす設計にはしません。定例の稟議まで一覧を作ると、読まれない一覧が積み上がります。

もう1つはインデックスの更新で、毎晩1回動かします。その日に決裁が終わった稟議を取り込みます。決裁前の稟議は取り込みません。 審査中の稟議が前例として返ると、まだ付いていない条件を前例として扱うことになります。

起案部門が起案前に使う入口も作れます。 ただし起案部門の閲覧権限は審査担当より狭いため、同じインデックスを、閲覧グループの絞り込みを変えて引きます。

入力データを集める

質を決めるのは、3行目と4行目です。 本文だけを入れると「似た稟議」は見つかりますが、なぜ条件が付いたかは返せません。 コメントと差戻しの履歴を同じ稟議のまとまりとして持つことが、第1章で書いた「判断の前例」を探す前提になります。

否決と取下げの稟議も必ず入れます。 承認された稟議だけを入れると、否決された前例が見えないまま同じ案件が通ることになります。

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

電子稟議からは、決裁が終わった稟議を1件ずつ書き出します。 本文・コメント・差戻し履歴・結果・閲覧設定を1つのJSONにまとめ、稟議番号をキーにします。

紙の時代の稟議は、Document Intelligence のレイアウトモデルで読みます。 レイアウトモデルはテキスト・表・選択マーク・文書の構造を取り出し、タイトルやセクション見出しといった段落の役割を付けます。outputContentFormat=markdown を指定すると Markdown で出力でき、表は HTML の表として表されるとされています。稟議書の「件名」「金額」「決裁欄」の表をそのまま読めます。

インデックスの設計で大事なのは、日本語のアナライザーです。 既定の Standard Lucene は空白や記号で語を区切る考え方で、空白で区切られない日本語では、文全体が1つのトークンになる可能性があるとされています。本文とコメントのフィールドには ja.microsoft か ja.lucene を指定します。アナライザーはデータを読み込む前、インデックスの作成時に設定します。

インデックスのフィールドは、次のように持たせます。

本文とコメントでベクトルを分けるのは、似方が違うからです。 本文は「何を買うか」で似ていて、コメントは「何を心配したか」で似ています。同じ設備でなくても、同じ心配をされた稟議が、コメントのベクトルから見つかります。

審査のときの検索は、1つの要求にまとめます。

{
  "search": "射出成形機 更新 第2工場 老朽化",
  "vectorQueries": [
    { "kind": "vector", "vector": [ ], "k": 50, "fields": "body_vector" },
    { "kind": "vector", "vector": [ ], "k": 50, "fields": "comments_vector" }
  ],
  "filter": "category eq '設備投資' and amount_jpy ge 30000000 and amount_jpy le 120000000 and group_ids/any(g: search.in(g, '{reviewer_groups}'))",
  "queryType": "semantic",
  "semanticConfiguration": "ringi-semantic",
  "top": 10
}

k を50にしているのは、セマンティック ランカーへの入力を最大にするためです。 ハイブリッド検索の公式の説明でも、セマンティック ランカーを使う場合は k を50にすることが勧められています。filter の末尾の閲覧グループの条件は、どの検索にも必ず付けます。

AIへ渡す前に整形する

1. 稟議ごとに1つのまとまりにする … 本文・コメント・差戻し履歴を稟議番号でまとめ、コメントは決裁者と日付を付けて並べます
2. 長い稟議を分ける … 添付が長い稟議は、本文とコメントを1つ目の塊に、添付の要旨を2つ目以降に分けます。コメントは必ず本文と同じ塊に入れます
3. 項目をそろえる … 金額は円に換算した数値、種類は社内の区分の一覧のどれかに寄せます。絞り込みに使うので、自由記述のまま入れません
4. 閲覧グループを付ける … 電子稟議の閲覧設定をグループIDの一覧にします
5. スキャンPDFの読み取り … ページ数は最大2,000、有料（S0）レベルで500MBまで。パスワード付きのPDFは提出前に解除が必要です
6. 個人名の扱いを決める … 決裁者の名前は役職に置き換えて入れる設計にできます

2番目の「コメントは本文と同じ塊に」を外さないでください。 セマンティック ランカーは文書ごとに最大2,000トークンを受け付け、タイトル128トークン、キーワード128トークン、残りがコンテンツという配分で、上限を超えた内容は無視されるとされています。コメントを末尾に置いた長い塊は、肝心のコメントが並べ替えの材料から落ちます。

AIに処理させる

生成AIの出番は2回あります。 1回目は検索の前で、新しい稟議から検索語と絞り込みの条件を組み立てます。2回目は検索の後で、上位の稟議を読んで前例の一覧にまとめます。

3行目がいちばん起きやすい失敗です。 「回収期間の前提を保守的に見直すこと」を「回収期間を短くすること」と要約すると、決裁者が求めたことと逆になり得ます。 条件と理由は抜き出しに限ります。

指示内容を固定する

あなたは稟議の審査担当を補助します。
新しい稟議と、検索で見つかった過去の稟議が与えられます。
過去の稟議に書かれていることだけを使ってください。

【やること】
過去の稟議それぞれについて、次を書いてください。
- similarity ... 新しい稟議と何が同じか（設備、相手先、目的、金額の規模）
- conditions ... 決裁者のコメントに書かれた付帯条件。原文のまま引用する
- reasons ...... 差戻し・否決の理由。原文のまま引用する
- differences .. 新しい稟議との違い（金額、相手先、期間、前提）
- relevance .... high / medium / low

【厳守事項】
- ringi_no は、下の【過去の稟議】に含まれる番号だけを使ってください。
  ほかの番号を書かないでください。
- conditions と reasons は、コメントの文言をそのまま写してください。
  要約、言い換え、補足をしないでください。
  コメントに条件や理由が書かれていなければ、空の配列にしてください。
- 新しい稟議が承認されるか、否決されるかの見込みを書かないでください。
- 一般的な注意点や助言を書かないでください。
- 似ていない稟議は relevance を low にし、無理に似ている点を書かないでください。
- 過去の稟議に書かれていない数字（回収期間、利率など）を計算しないでください。

【新しい稟議】{new_ringi}
【過去の稟議】{retrieved}

「原文のまま写す」を2か所に書いているのは、生成AIが要約したがるからです。 1か所だけだと、長いコメントを短くまとめて返します。条件の文言は、短くすると意味が変わります。

「似ていない稟議を無理に似せない」も明記します。 検索は必ず何件かを返すため、指示が無いと、関係の薄い稟議にも似ている点を作文します。

出力形式を固定する

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

{
  "new_ringi_no": "",
  "search": { "query": "", "filters": { "category": "", "amount_min": 0, "amount_max": 0, "date_from": "" } },
  "precedents": [
    {
      "ringi_no": "",
      "title": "",
      "decision": "approved | approved_with_conditions | approved_after_return | rejected | withdrawn",
      "decided_on": "",
      "similarity": "",
      "conditions": [ { "quote": "", "by_role": "" } ],
      "reasons": [ { "quote": "", "by_role": "" } ],
      "differences": [ "" ],
      "relevance": "high | medium | low"
    }
  ]
}

構造化出力を使う理由の1つ目は、ringi_no を機械で照合できることです。 Azure OpenAI の構造化出力は、json_schema に strict: true を指定して、渡した JSON スキーマに従わせます。全フィールドを required にし、additionalProperties: false を指定する必要があります。番号が決まった場所に入るので、第5章の7番目の照合がコードで書けます。

2つ目は、conditions と reasons を引用の配列にできることです。 引用の文字列が原本のコメントに含まれるかを、文字列の一致で検査できます。一致しない引用は、生成AIが言い換えたものとして一覧から外します。

3つ目は、search を残せることです。 どの語とどの絞り込みで探したかが残るので、前例が見つからなかったときに、探し方が悪かったのか、本当に無いのかを見分けられます。

システムへ連携する

電子稟議へは書き込みません。 一覧は審査担当の画面に出すだけで、稟議のコメント欄にも自動で貼りません。AIのまとめが稟議の記録に混ざると、後から前例として検索されてしまいます。

人が確認する

1. 一覧で relevance: high の稟議から見る … 似ている点と違いを読み、使えそうな前例を選びます
2. 使う前例の原本を開く … 一覧のリンクから電子稟議の画面を開き、引用されたコメントが原本にあるかを確かめます
3. 審査メモには原本から引用する … 一覧の文章ではなく、原本の稟議番号とコメントを書きます
4. 見つからなかったときは検索条件を見る … search の語と絞り込みを見て、広げて再検索します
5. 役に立った前例・外れた前例を記録する … 次の改善の材料にします

2番目を省かないでください。 引用の一致を機械で検査していても、どの決裁者のどの時点のコメントかは原本で見ないと分かりません。 差戻し前のコメントと最終の決裁のコメントは、意味が逆のことがあります。

例外に対処する

4行目の「件数も表示しない」は大事です。 「閲覧できない前例が3件あります」と出すだけで、M&Aや処遇の稟議が存在することが伝わります。 セキュリティ フィルターは、グループIDを Collection(Edm.String) のフィルター可能なフィールドに持たせ、search.in で絞る方法が推奨されています。このフィールドは retrievable を false にして検索結果に返さないようにしますが、公式の説明では、これはフィールド単位の保護の仕組みではなく、すべてのクエリにフィルターをかけることで文書単位の承認を実現するものとされています。

記録を残す

• 検索した日時、審査担当、新しい稟議の番号
• 生成AIが組み立てた検索語と絞り込みの条件
• 検索結果の上位（稟議番号と @search.rerankerScore）
• 生成AIが返したJSONと、番号の照合・引用の一致検査で除いたもの
• 審査担当が原本を開いた稟議と、審査メモに使った稟議
• インデックスの更新の記録（取り込んだ件数、読めなかったPDF）

4つ目の「除いたもの」は、生成AIの癖を見るために残します。 実在しない番号や言い換えた引用が増えたら、指示の書き方かモデルの設定を見直します。

5つ目は、前例の価値を測る材料になります。 審査メモに使われた稟議の種類を見ると、どの種類の稟議で前例が効いているかが分かります。