グループ会社の担当から出る「この案件は親会社の承認・報告が要るか」の質問に、グループ会社管理規程と決裁権限表を根拠にチャットで答え、判断の要るものを経営企画へ回す

処理の起点を決める

起点は、グループ会社の担当がグループ内のチャット画面で質問を送ったことです。 画面はグループ共通の ID でログインした、各社の経営企画・総務の担当と親会社のグループ管理課だけが使います。案件の概要、金額、予定の決定日を入れないと送信できない作りにします。

金額は数値の欄と、但し書きの選択肢で入れさせます。 「税抜か税込か」「単年度か複数年の総額か」「同じ案件を分けて発注する予定があるか」を選ばせます。決裁権限表の注記が問うのは、この3つが多いからです。予定の決定日は、決裁権限表の改定の前後を分けるのに使います。

1件の案件は1つのセッションで続け、「リースで調達する場合は」と聞き足すと同じセッションで絞り直します。別の案件は、新しいセッションで始めます。 担当が種類を選んだ時点で、区分の計算に進みます。

入力データを集める

質を決めるのは、決裁権限表を2つに分けて持つことです。 閾値と区分は表データにしてプログラムが引き、注記と種類の説明は文として検索の対象に入れます。表のまま検索に入れると、モデルが閾値を読んで区分を答え始めます。

文書ごとのメタデータは、会社のコード、会社の区分、文書の種類（規程／注記／取り決め／Q&A）、適用開始日、適用終了日です。 個別の取り決めにはその会社のコードだけを付け、規程と注記には all を付けます。

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

文書は Cloud Storage に置き、メタデータ付きでデータストアへ取り込みます。 規程は Word、決裁権限表は Excel、取り決めは PDF で持っていることが多く、レイアウトの解析は PDF・HTML・DOCX・PPTX・XLSX・XLSM の配置を検出します。 注記の段落と見出しを見分けられます。

絞り込みの式は、会社と日付で書きます。 項目を索引可能にしておけば、company_id: ANY("JV02", "all") AND valid_from <= "2026-11-20" AND valid_to >= "2026-11-20" のように、合弁会社2の、11月20日に効いている規程と取り決めを引けます。日付は ISO 8601 の文字列で比べられます。索引可能にしても絞り込みに使えない項目があるとされているので、 項目ごとに確かめます。

会社ごとに見せる文書を分けるには、データストアのアクセス制御を使います。 合弁会社の取り決めは、他のグループ会社の担当に見せない文書です。アクセス制御はデータストアの作成時に選ぶ設定で、既存のデータストアで切り替えることはできません。 Cloud Storage の文書ではメタデータの acl_info に読める人を書き、1つの文書の読み手は3,000までで、グループは1つの読み手として数えられます。会社ごとに担当のグループを作り、その会社の取り決めの読み手にします。

AIへ渡す前に整形する

1. 決裁権限表を表データにする … 案件の種類、閾値、区分、金額の数え方の区分、適用期間を1行ずつにし、グループ管理課が確かめます
2. 注記を文として残す … 表の欄外の注記と種類の説明を、表データとは別の文書にします
3. 規程を版ごとに分ける … 改定のたびに上書きされた規程と決裁権限表は、版ごとに適用期間を付けます
4. 個別の取り決めに会社のコードを付ける … 合弁契約のうち親会社の承認・事前協議に関わる条を抜き出し、その会社のコードで取り込みます
5. 運用のQ&Aを作る … グループ管理課が過去に答えた「この案件はどの種類か」を、問いと答えと根拠の形にします
6. 見出しを断片に含める … データストアの作成時に分割を有効にし、includeAncestorHeadings を有効にします

1番目が、この構成でいちばん大事な作業です。 閾値をプログラムで比べるために、表の1行1行を、人が読んで決めたデータにします。 案件の種類は数十で、一度作れば改定のたびに直すだけです。

6番目は、データストアを作る前に決めます。 分割はデータストアの作成後に有効にも無効にもできず、見出しを含める設定は既定では無効です。 「税抜で判定する」とだけ書かれた断片は、見出しが無いとどの種類の注記か分かりません。 分割の大きさは100〜500トークンで、既定は500です。

AIに処理させる

させるのは、案件の概要から、決裁権限表のどの種類に当たりうるかの候補を、根拠の条と注記付きで並べることです。 区分を決めること、閾値と比べること、承認してよいかを言うことはさせません。

answer メソッドの設定は次のようにします。

1行目と2行目がいちばん起きやすい失敗です。 注記を読んだモデルは、「5,000万円以上は承認のため、本件は承認です」と書きたがります。 区分の文が画面に出ると、プログラムの出した区分と並び、食い違ったときにどちらを信じるかで迷います。 区分はプログラムの1か所でだけ出します。

指示内容を固定する

answer メソッドの preamble に、次の指示を入れます。

あなたは持株会社の経営企画部グループ管理課で、グループ会社の担当からの
「この案件は親会社の手続きが要るか」の問い合わせを手伝う立場です。
検索結果に出た、グループ会社管理規程・決裁権限表の注記・この会社の個別の取り決め・
運用のQ&Aだけを根拠に答えます。読むのはグループ会社の担当です。

【答え方】
1. 案件が決裁権限表のどの種類に当たりうるかの候補を、1〜3個挙げてください。
   種類の名前は、決裁権限表の注記に書かれた名前のまま書いてください。
2. 候補ごとに、当たりうる理由と、根拠の条または注記の箇所を書いてください。
3. 金額の数え方（税抜・総額・合算）の注記があれば、その文のまま書いてください。
4. この会社の個別の取り決めで扱いが変わる場合は、その条を書いてください。

【厳守事項】
- 承認・事前協議・報告・不要のどれに当たるかを書かないでください。
  区分は別の仕組みが決裁権限表から出します。
- 金額を閾値と比べないでください。「閾値を超えるので」と書かないでください。
- 承認されるかどうか、問題がないかどうかを書かないでください。
- 子会社の取締役会に付議が要るかは答えないでください。
  「子会社の機関決定は別に確認が要る」とだけ書いてください。
- 他の会社の取り決めや、一般的なグループ管理の慣行で補わないでください。
- 候補が決まらないときは「種類が決まらない」と書き、迷う理由を並べてください。

「区分を書かない」を書くのは、区分が正しくても困るからです。 区分の文がモデルとプログラムの2か所から出ると、担当はモデルの文のほうを読みます。 注記の但し書きを読み落とした区分が、文として信じられます。

「子会社の機関決定は別」と書かせるのは、第3章の（d）を防ぐためです。 担当が混ぜて聞いても、答えの側で2つを分けて見せます。

出力形式を固定する

answer メソッドの応答と、担当の選択、決裁権限表のデータからの区分を、中継プログラムが次の形にまとめて画面と記録に渡します。

{
  "query_id": "",
  "session_id": "",
  "requester_id": "",
  "company_id": "JV02",
  "company_type": "wholly_owned | joint_venture | overseas",
  "decision_date": "2026-11-20",
  "amount": { "value": 48000000, "tax": "excluded", "basis": "single_year", "split_order": false },
  "question": "",
  "category_candidates": [
    { "category": "", "reason": "", "refs": [ { "doc_type": "rule | note | agreement | qa",
                                                "location": "", "uri": "" } ] }
  ],
  "selected_category": "",
  "procedure": "approval | prior_consultation | report | none | undetermined",
  "rule_row_id": "",
  "near_threshold": true,
  "conflicts": [ { "summary": "", "refs": [""] } ],
  "status": "answered | routed",
  "hq_review": { "confirmed_procedure": "", "note": "" }
}

1つ目の理由は、category_candidates と procedure を別の層に置けることです。 候補はモデルが出し、selected_category は担当が選び、procedure と rule_row_id は中継プログラムが決裁権限表のデータから入れます。閾値が改定されても、直すのは表データだけです。

2つ目は、near_threshold で回し先を機械的に決められることです。 金額が閾値の近くにあれば、区分を出したうえで親会社の待ち行列にも載せます。 注記の但し書きで区分が変わりうる案件を、人の目に通します。

3つ目は、amount を数値と但し書きに分けて持つことです。 決裁権限表の注記は金額の数え方を問うので、入力の段階で数え方をそろえておけば、比較はプログラムで確実にできます。

システムへ連携する

申請の受付（ワークフロー）には、つなぎません。 区分が「承認」と出ても、申請は担当がこれまでどおり出します。 画面から申請が自動で起きると、種類の選び間違いがそのまま親会社の決裁に流れます。

親会社の担当が回ってきた案件の区分を決めたら、運用のQ&Aに足すかを決めます。 同じ種類の迷いが2回来たら、Q&Aに書いて取り込むところまでを1件の完了とします。

人が確認する

人が確かめるのは、種類の選択と、回ってきた案件です。

1. 担当が種類を選ぶ … 候補と根拠を読み、1つを選びます。迷えば「決まらない」を選びます
2. 親会社の担当が回ってきた案件の区分を決める … undetermined、near_threshold、conflicts のもの
3. 「承認」「事前協議」と出た案件は、申請の段階で親会社が区分を確かめる … 画面の区分は、申請の受付の点検の代わりになりません
4. 月に1回、「報告」「不要」と出た案件から20件を抜いて読む … 種類の選び間違いで手続きを飛ばしていないかを見ます

4番目を省かないでください。 「不要」と出た案件は、親会社に何も届かないので、誤りに気づく機会がありません。 抜き取りで読むのは、届かない側の案件です。

目標は、120件をならして1件9分です。 親会社の担当の時間は、回ってきた案件の判断と抜き取りの確認に使う想定です。

例外に対処する

4行目が、件数の割に重い行です。 閾値の近くの案件は、区分の誤りが親会社の承認の漏れに直結します。 幅をどこまでにするかは、運用の最初の数か月の件数を見て決めます。

記録を残す

• 質問の文、担当の ID、会社のコード、金額と但し書き、予定の決定日、日時、セッションの ID
• 絞り込みの式と、answer メソッドの応答の全文（出典と根拠のスコアを含む）
• 種類の候補、担当が選んだ種類、決裁権限表のデータの行と版、出した区分
• 親会社の担当の確認の結果と、運用のQ&Aに足した文
• 記録の閲覧の履歴

3つ目で「担当が選んだ種類」を残すのは、後から手続きの漏れが見つかったときのためです。 監査で「この案件はなぜ報告で済ませたのか」と問われたとき、どの候補が出て、誰がどれを選び、どの版の表で区分が出たかを示せます。

記録は、グループ会社ごとに閲覧を分けます。 案件の記録には、他のグループ会社に見せない投資や取引の情報が入ります。