決裁の権限について「これは誰の承認が要るか」に、規程の根拠付きで答える

処理の起点を決める

照会フォームの送信を起点にします。Apps Script のインストール型トリガーには「フォーム送信時」があり、そのまま使えます。

窓口を1つに絞ってください。 メール、チャット、電話、口頭と経路が分かれていると、記録が残りません。「決裁者の照会はこのフォームから」と決めることが、この構成の前提です。

チャットから使えるようにすると、利用率が上がります。現場の担当者は、フォームを開くより、いつも使っているチャットで聞くほうが自然です。 ただし、チャットでは必須項目の入力を強制しにくいため、聞き返しの設計が重要になります。

もう1つの起点として、規程が改定されたときに索引を作り直す処理を置きます。改定後も古い索引を引いていると、誤った決裁者を答えます。 これは致命的なので、改定の運用と必ず紐づけてください。

入力データを集める

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

職務権限規程： 別表を構造化して取り込むことが、この構成の要です。PDFのまま検索させないでください。 次の形に直します。

この表を作る作業が、準備の大半です。 180行なら1〜2日で終わります。一度作れば、改定のたびに差分を直すだけです。

「原文」の列を必ず持ってください。 回答に添える根拠は、構造化した値ではなく原文です。構造化の過程で意味が変わっている可能性があるため、利用者が原文で確かめられる形にします。

組織図と決裁者の対応表： 規程には「部長」と書かれていますが、現場は「誰に出せばよいか」を知りたいと思っています。申請部署から、その部署の課長・部長が誰かを引ける表が要ります。

兼務の扱いに注意してください。 「営業部長が営業一課長を兼務している」場合、課長決裁と部長決裁が同じ人になります。この場合、上位の決裁者へ上げる必要があるかは、規程に書かれていることが多いので、その条項も索引に入れます。

過去の照会記録： 運用を始めてからたまります。最初は空で構いません。 総務が判断した案件が記録されていくことで、索引が育ちます。

AIへ渡す前に整形する

1. 別表の構造化 … 上記の表の形に直します。金額区分は「〜50万円未満」のような表記を、数値の下限・上限に直します
2. 決裁事項の言い換え辞書 … 「パソコン」「PC」「ノートパソコン」→「什器備品」のように、現場の言葉と規程の言葉を対応づけます。50語程度から始めてください
3. 金額の正規化 … 照会に書かれた金額を数値に直します。「50万」「500,000円」「50万円（税抜）」をそろえます。税抜・税込の別を必ず保持してください
4. 契約期間の抽出 … 「3年契約」「月額20万円」といった記述から、契約総額の計算に必要な情報を取り出します
5. 改定日との突合 … 規程の索引が最新版かを確認します。古い版を引いていないかのチェックを入れます

AIに処理させる

検索基盤にさせること： 照会の内容から、該当しそうな決裁事項の候補を引き当てること。表記が違っても意味で引けるようにします。

生成AI（Claude API）にさせること：

計算処理にさせること：

金額の比較をAIにさせません。 「500万円は、500万円未満の区分に入るか」という境界の判定は、単純な比較で確実に行えます。 AIに任せると、境界で誤る可能性が残ります。

規程に書かれていない案件について、答えを作らせません。 「一般的には部長決裁でしょう」といった回答は禁止です。「規程に該当する条項が見つかりませんでした。総務へお問い合わせください」と返させます。

指示内容を固定する

あなたは総務部の決裁権限の照会に答える担当者です。
下の照会について、職務権限規程の該当条項を特定し、決裁者を示してください。

【厳守事項】
- 回答は、下の「規程の検索結果」に含まれる条項のみを根拠にしてください。
  **一般的な決裁権限の考え方や、他社の慣行で補わないでください。**
  検索結果に該当する条項がない場合は、status を "not_found" にし、
  「規程に該当する条項が見つかりませんでした」と回答してください。
  **推測で決裁者を答えないでください。**
- 根拠として、該当する別表の行または条文の**原文をそのまま**引用してください。
  要約や言い換えをしないでください。
- 金額の比較をしないでください。
  該当する決裁事項の番号と、金額区分の候補を返すところまでが役割です。
  金額区分の判定は後段の処理で行います。
- 次の場合は status を "needs_check" にし、理由を書いてください。
  ・複数の決裁事項に当たりうる
  ・金額の解釈が分かれる（契約総額か年額か、税抜か税込かが規程から読めない）
  ・条件や但し書きに該当するか、照会の情報では判断できない
  ・申請部署の組織が規程の記載と対応しない
  **迷ったときに "answered" にしないでください。**
- 決裁者を決めるのに必要な情報が不足している場合、status を "need_info" にし、
  不足している項目を列挙してください。
  聞き返しの文は、必要な項目を3つ以内にまとめてください。
- 決裁の要否そのもの（この案件は稟議が必要か）を判断しないでください。
- 回答文には、必ず根拠の条項番号を含めてください。

【照会の内容】
{inquiry}

【規程の検索結果（決裁事項の候補・上位5件、原文つき）】
{retrieved_rules}

【過去の類似照会と回答（上位3件）】
{past_inquiries}

【申請部署の組織情報】
{department_info}

「迷ったときに answered にしない」の1行が、この構成でもっとも重要です。 決裁者の回答は、間違えると稟議が差し戻され、やり直しになります。答えられないことを正直に返すほうが、間違った答えを返すより価値があります。

「一般的な考え方で補わない」も必須です。 職務権限は会社ごとに違います。「300万円を超える契約は通常、取締役会の決議が必要です」といった回答は、自社の規程に基づかない限り誤りです。

「金額の比較をしない」の指示も効きます。 「498万円は500万円未満か」の判定でAIが誤る可能性をなくします。候補の決裁事項と金額区分を返させ、比較は計算処理で行います。

出力形式を固定する

{
  "inquiry_id": "",
  "status": "answered | needs_check | need_info | not_found",
  "matched_rule": {
    "rule_no": "",
    "rule_name": "",
    "source_text": "",
    "amount_tiers": [
      { "lower": 0, "upper": 0, "approver_title": "" }
    ],
    "conditions": ""
  },
  "alternative_rules": [
    { "rule_no": "", "rule_name": "", "why_possible": "" }
  ],
  "need_info_items": [],
  "followup_question": "",
  "needs_check_reason": "",
  "related_rules": [],
  "past_inquiry_refs": [],
  "answer_text": ""
}

JSON Schema を指定して出力を固定します。Claude API では output_config.format にJSONスキーマを渡すことで、応答をスキーマに沿った形に制約できます。

amount_tiers を配列で返させている点に注目してください。 AIには「この決裁事項には、50万円未満は課長、50万〜300万円は部長、300万円以上は本部長という3つの区分がある」という情報を返させ、実際にどの区分に当たるかの判定は計算処理で行います。

alternative_rules は、該当しうる他の決裁事項です。「什器備品の取得」と「情報システムの導入」の両方に当たりうるパソコンの購入のような案件で、ここに候補が入ります。status を needs_check にする根拠にもなります。

past_inquiry_refs は、過去の類似照会への参照です。総務が過去に判断した案件があれば、それを示すことで一貫性が保てます。

システムへ連携する

回答は、照会フォームの送信者へ返します。回答文の構成を決めておいてください。

【決裁者】営業部長

【根拠】職務権限規程 別表 3-12「什器備品の取得」
  「1件あたり50万円以上300万円未満のもの ……… 部長」

【ご申請部署】営業部 第一営業課
【決裁者（氏名）】◯◯ ◯◯ 営業部長

【ご注意】
ご照会の金額は税抜120万円とのことでした。本規程の金額区分は税抜で判定します
（別表 注記2）。税込の場合は区分が変わる可能性がありますのでご確認ください。

【関連する規程】購買規程 第8条（相見積の取得）

根拠の原文を必ず含めてください。 これがあることで、照会した側が自分で確認できます。「なぜその決裁者なのか」が分かると、次から似た案件は自分で調べられるようになります。

照会記録は、スプレッドシートへ追記します。 Apps Script から SpreadsheetApp を使って行を追加します。列は次の構成です。

not_found と needs_check の記録が、規程の改善材料になります。 同じ種類の案件が毎月 not_found になるなら、規程にその決裁事項がないということです。 追加を検討する材料になります。

稟議システムへの連携は行いません。 この構成は照会に答えるだけで、稟議の起票には関与しません。

人が確認する

answered は人が確認しません。needs_check、need_info の再照会、not_found を総務が対応します。

全件確認にすると、この構成の効果が消えます。規程に明確に書かれている案件は、機械が答えて構いません。 ただし、次の2つを必ず入れてください。

1. 根拠の原文を回答に含める … 照会者が自分で検証できる
2. 回答のフィードバック … 「解決した」「違う気がする」を返せるボタンを付ける

2つ目が、この構成の安全装置です。 誤った回答が出ていても、照会者が「違う気がする」と返せれば、総務が気づけます。フィードバックがない設計にすると、誤りが静かに積み上がります。

総務が対応する照会の確認では、次の設計が効きます。

• not_found を最上部に集める（規程の抜けの可能性）
• needs_check の理由ごとにまとめる（同じ論点が繰り返されていれば規程の問題）
• 過去に同じ内容の照会があったかを併記する
• 「違う気がする」のフィードバックが付いた answered を別に集める

最後の項目を毎週見てください。 誤答の兆候がここに出ます。

例外に対処する

記録を残す

この記録は、決裁の運用が一貫していたことを示す資料になります。

• 照会の内容と、回答した決裁者・根拠
• 判定に使った規程の版
• needs_check と not_found の理由
• 総務が判断した案件と、その判断の根拠
• 照会者からのフィードバック
• 誤答が見つかった場合、その内容と修正の記録

「判定に使った規程の版」が特に重要です。 規程は改定されます。「その時点ではこの回答が正しかった」ことを示せる状態にしてください。

not_found と needs_check の集計を、四半期ごとに見てください。 同じ種類の案件が繰り返し引っかかっているなら、規程にその決裁事項を追加するか、金額の判定基準を明記する必要があります。 この構成のもう1つの価値が、ここにあります。