稟議内容を要約して決裁者向けの論点を出す

処理の起点を決める

稟議が申請されたときが起点です。ワークフローシステムがWebhookを提供していればそれを、なければ定期的に新規申請をポーリングします。

申請前のチェック（§5の4〜5）を実現する場合は、起案者が「下書き保存」した時点、または申請ボタンを押す前のチェック機能として実装します。 ここが実現できるかは、ワークフローシステムの拡張性に依存します。この部分は利用環境に応じた個別確認が必要です。

入力データを集める

過去の稟議データを渡すことが、この構成の差別化点です。 単なる要約なら価値は限定的ですが、「半年前に同じ内容の稟議が、この条件で承認されている」という情報は、決裁の判断を速くします。

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

稟議書と添付資料： ワークフローシステムのAPIで取得します。添付がPDFの場合はテキスト抽出が必要です。見積書などの帳票は、UC-0012（見積比較）と同じくOCRが必要な場合があります。

過去の稟議： 過去2年分の稟議データを検索対象にします。件数が数千件規模なら、キーワード検索で足ります。この構成では、RAGの基盤を作るほどの必要はありません。 稟議には「購買」「投資」といった種別と金額が構造化されて入っているため、種別と金額帯での絞り込みが有効です。

決裁権限規程： 金額と種別から決裁者を導く表を、構造化データで持ちます。

{
  "type": "購買",
  "thresholds": [
    { "max_amount": 1000000, "approvers": ["部長"] },
    { "max_amount": 10000000, "approvers": ["部長", "本部長"] },
    { "max_amount": null, "approvers": ["部長", "本部長", "取締役会"] }
  ]
}

決裁経路の判定は、AIにさせずにプログラムで行います。 金額の閾値判定にAIを使う理由はありません。

AIへ渡す前に整形する

1. 添付資料のテキスト化 … PDF、Excel、Wordをテキストにします
2. 金額の抽出 … 稟議書の金額欄と、添付見積書の金額が一致するかを機械的に照合します。不一致はそれ自体が指摘事項です
3. 決裁経路の判定 … 金額と種別から、規程上の正しい経路を計算します
4. 類似稟議の検索 … 種別・金額帯・キーワードで過去案件を検索し、上位5件を取得します

AIに処理させる

「承認すべきか」の判断はさせません。 これは§13に書く理由によります。

指示内容を固定する

あなたは稟議の決裁者を補佐する担当者です。
以下の稟議書と添付資料から、決裁判断に必要な要約と論点を作成してください。

【厳守事項】
- 承認・却下の推奨をしないでください。
  「妥当と考えられます」「問題ありません」といった評価も書かないでください。
- 金額、数量、日付を書き換えないでください。
- 稟議書と添付資料に書かれていない情報を補わないでください。
  書かれていない項目は insufficient_items に列挙してください。
- 効果の記載について、根拠が示されているかを確認してください。
  「業務効率が向上する」とだけ書かれ、
  時間や金額の根拠がない場合は insufficient_items に入れてください。
- 本文と添付資料で数値が食い違う場合、discrepancies に記載してください。
  どちらが正しいかを推測しないでください。
- 過去の類似案件との違いは、事実として記載してください。
  「今回のほうが高い」ではなく
  「前回は単価◯円、今回は単価◯円」と書いてください。
- リスクについて、稟議書に記載のないリスクを想像して
  書き加えないでください。

【稟議の種別】{type} / 【金額】{amount}
【規程上の決裁経路】{required_approvers}
【申請された決裁経路】{actual_approvers}

【稟議書本文】
{ringi_body}

【添付資料（テキスト抽出結果）】
{attachments}

【過去の類似稟議（上位5件）】
{similar_cases}

「承認・却下の推奨をしない」の1行が、この構成でもっとも重要です。 稟議は組織の意思決定であり、その責任は決裁者が負います。AIが「妥当と考えられます」と書けば、忙しい決裁者はそれを読んで承認します。それは決裁の形骸化であり、内部統制上の問題になります。

「稟議書に記載のないリスクを想像して書き加えない」も重要です。AIは一般論としてのリスク（「為替変動リスク」「納期遅延リスク」）をいくらでも生成できますが、それは案件固有の情報ではなく、ノイズになります。

出力形式を固定する

{
  "summary": {
    "what": "",
    "amount": 0,
    "why": "",
    "when": "",
    "who_benefits": ""
  },
  "key_points": [
    { "point": "", "source": "稟議書 / 添付資料名" }
  ],
  "alternatives_considered": {
    "described": true,
    "content": ""
  },
  "expected_effect": {
    "described": true,
    "has_basis": false,
    "content": ""
  },
  "risks_described": [],
  "insufficient_items": [],
  "discrepancies": [],
  "similar_cases": [
    { "ringi_no": "", "date": "", "amount": 0, "outcome": "", "difference": "" }
  ],
  "approval_route_check": "規程どおり | 不足 | 過剰"
}

insufficient_items と discrepancies が、実務上もっとも使われる出力です。決裁者はここだけを見て、起案者に確認すべきことが分かります。

システムへ連携する

起案者向け（申請前）： insufficient_items と discrepancies を、申請ボタンの前に表示します。「代替案の検討が記載されていません」「稟議書の金額と添付見積書の金額が一致しません」といった指摘です。起案者が申請前に直せば、決裁段階での差し戻しがなくなります。

決裁者向け（申請後）： 承認画面に要約を表示します。原本へのリンクを必ず併記し、要約だけで判断させない設計にします。

ワークフローシステムの画面に要約を埋め込めるかは、システムの拡張性によります。埋め込めない場合は、承認依頼の通知メールに要約を含める形にします。この部分は利用環境に応じた個別確認が必要です。

人が確認する

決裁者が原本を確認できる状態を必ず維持します。

この構成には、他のユースケースとは違う注意点があります。AIの出力を「人が確認する」のではなく、「人が判断するための材料として使う」ものだからです。

したがって設計上の要件は次の2つです。

1. 要約と原本を並べて表示する … 要約だけの画面にしない
2. 要約に「これは補助資料です」と明示する … 決裁の根拠は稟議書本文であることを画面上で示す

例外に対処する

記録を残す

• 稟議書と添付資料（ワークフローシステム側で保存）
• AIの要約と指摘
• insufficient_items の指摘に対して、起案者が補った内容
• 決裁者が要約を見たか、原本を開いたか

最後は、内部統制の観点で意味を持ちます。決裁者が原本を一度も開かずに承認している状態が続くなら、それは要約の精度の問題ではなく、決裁の形骸化の兆候です。 記録して定期的に確認してください。