子会社の経理担当から毎月届く連結パッケージの記入方法の質問に、会計方針書・記入要領・過去の質疑を根拠にチャットで答え、判断の要るものを連結の担当へ回す

処理の起点を決める

起点は、子会社の経理担当がチャットで質問を送ったことです。 チャットはグループのポータルに置き、グループの ID でログインした担当だけが使えるようにします。ログインした担当の会社コードが、絞り込みと閲覧の範囲の判定にそのまま使われます。

報告の月は、チャットを開いた時点の締めの月を既定にし、選び直せるようにします。 前の月の数値を直している担当は、前の月を選びます。報告の月が、どの版の要領で答えるかを決めます。

1つの質問は、1つのセッションで最後まで続けます。 確認項目を聞き返すやり取りと、答えたあとの「では外貨建ての場合は」のような続けての質問を、同じセッションでつなぎます。別のシートの質問は、新しいセッションで始めてもらいます。

入力データを集める

質を決めるのは、確認項目の表の「回す条件」の列です。 「取引の種類：初めての取引」「方針：親会社と違う処理をしている」「金額：一定額を超える」のような値が選ばれたら、答えを作らずに回す、という規則をこの列に書きます。 ここが無いと、判断の要る質問がチャットで答えられてしまいます。

会社の情報の「決算日」も効きます。 決算日が連結決算日と違う子会社は、仮決算を行うのか、差が3か月を超えないので自社の正規の決算を基礎にするのかで、書く数値の期間が変わります。 会社ごとにどちらの扱いかを一覧に持たせ、回答に添えます。

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

要領・方針書・質疑は、Cloud Storage に置いてデータストアに取り込みます。 文書ごとのメタデータに、シートの種類、文書の種類（要領／方針書／質疑）、適用開始の月、適用終了の月、対象（全社共通／特定の会社）を持たせます。

絞り込みの式は、シートと版で書きます。 項目を索引可能にしておけば、sheet: ANY("intercompany") AND valid_from <= "2026-09-30" AND scope: ANY("all", "C014") のように書けます。比べる値の形をメタデータと検索の文でそろえ、日付をISO 8601の形式で書けば、報告の月より後に適用される版を除けます。 終了した版は valid_to で除きます。

過去の質疑には、閲覧の範囲を付けます。 質疑には子会社の取引の内容と金額が書かれていて、他の子会社に見せてよいものではありません。 文書のメタデータの acl_info に、その会社の担当のグループと連結の担当のグループの group_id を書きます。全社に通用する質疑は、会社名と金額を除いた共通の版を連結の担当が作り、全員に見せます。

AIへ渡す前に整形する

1. 要領をシートの単位で分ける … 1つのPDFに全シートが入っているものは、シートごとに分けます
2. 取引からシートを引く索引を作る … 「親会社からの仕入の在庫残→内部取引のシートの在庫の欄」のような対応を表にし、要領と一緒に取り込みます
3. 版の適用開始と終了を付ける … 改訂のたびに、旧版に終了の月を書きます
4. 過去の質疑を整える … 回答の根拠のページを書き添え、今の要領で通用しない回答には終了の月を付けます
5. 共通の質疑を作る … 複数の会社から届いた質問は、会社名と金額を除いて共通の版にします
6. 見出しを断片に含める … データストアの作成時に分割を有効にし、includeAncestorHeadings を有効にします
7. 閲覧の範囲を付ける … 会社ごとの質疑に acl_info を付けます

2番目の索引が、この構成でいちばん効きます。 第3章の（b）のとおり、子会社の疑問は取引の側から来るのに、要領はシートの順に書かれています。索引が無いと、検索は取引の言葉とシートの言葉のずれを埋められません。 索引は、連結の担当が過去の質疑から「この質問はこのシート」と拾って作ります。

6番目は、データストアを作る前に決めます。 分割はデータストアの作成のあとでは有効にも無効にもできず、見出しを含める設定は既定では無効です。 要領の欄の説明は短く、見出しが無いとどのシートの欄か分かりません。分割の大きさは100〜500トークンで、既定は500です。要領の様式の見本が表計算のファイルなら、レイアウトパーサーで表として読ませます。

AIに処理させる

させるのは、聞き取った条件に当たる要領と方針書と質疑の記載を見つけ、どのシートのどの欄に何を書くかを、出典を付けて短く返すことです。 何を聞き返すか、何を回すかは、確認項目の表で中継プログラムが決めます。

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

検索は、ログインした担当の ID で行います。 中継プログラムが広い権限で検索すると、他の子会社の質疑が、取引の内容と金額ごと回答に入ります。

4行目がいちばん起きやすい失敗です。 回答を作るモデルは、一般的な連結の実務を知っています。それで補うと、グループの要領に無い「この場合は消去の対象外」が、グループの決まりのように届きます。 何を書くかは、グループの要領にしか書いてありません。

指示内容を固定する

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

あなたは企業グループの親会社の連結の担当として、
子会社の経理担当から連結パッケージの書き方の質問に答えます。
読むのは、締めの期限の中でパッケージを書いている子会社の担当です。

【前提】
検索の文の最初に、会社コード、報告の月、シートの種類、
聞き取った条件（取引の相手、取引の種類、通貨）が並んでいます。
その条件に当たる記載だけを使って答えてください。

【答え方】
1. 最初に、書く場所（シートの名前と欄の名前）を書いてください。
2. 次に、その欄に書く値の種類を、要領の言葉のまま書いてください。
3. 相手先コード、通貨、符号の注意があれば、箇条書きで書いてください。
4. 最後に、根拠にした要領の版とページ、質疑があればその日付を書いてください。

【厳守事項】
- 検索結果の文書に書かれていることだけで答えてください。
  一般的な会計基準や連結の実務の知識で補わないでください。
- 会計処理の方法を判断しないでください。
  処理の方法を聞かれたときは「連結の担当へ回します」とだけ書いてください。
- 金額を計算しないでください。仕訳を作らないでください。
- 重要性の有無を書かないでください。
- 聞き取った条件と違う条件の書き方を並べないでください。
- 該当する記載が見つからないときは、
  「記入要領と会計方針書に該当する記載が見つかりません。連結の担当へ回します」
  とだけ書いてください。
- 他の会社の名前と金額を書かないでください。

「会計処理の方法を判断しない」が、この指示の要です。 子会社の質問は「どこに書くか」の形で届きますが、中身が「消去の対象になるか」という処理の判断であることがあります。 モデルは要領の近い記載を手がかりに答えを作れてしまうので、処理の方法に触れる質問は、答えられても答えさせません。

検索の文は、中継プログラムが組み立てます。 例えば「会社：C014（国内、3月決算）、報告の月：2026年9月、シート：内部取引、相手：親会社、取引：部品の仕入、在庫残あり、通貨：円。書く場所と書く値を教えてください」のように、確認項目を表の順に並べ、担当の質問の文を最後に足します。

出力形式を固定する

answer メソッドの応答を、中継プログラムが次の形に整えて、チャットと記録に渡します。

{
  "inquiry_id": "",
  "session_id": "",
  "company_code": "",
  "report_month": "",
  "sheet": "intercompany | receivable_payable | fixed_assets | other",
  "conditions": { "counterparty": "", "transaction": "", "currency": "", "first_time": false },
  "status": "answered | escalated | skipped",
  "escalate_reason": "judgment | first_time | not_in_manual | version_mismatch | skipped | user_request | none",
  "answer_text": "",
  "manual_refs": [ { "version": "", "sheet": "", "page": "", "uri": "" } ],
  "qa_refs": [ { "date": "", "scope": "all | company", "uri": "" } ],
  "feedback": "resolved | escalated_after | wrong | none"
}

1つ目の理由は、conditions を回答と一緒に残せることです。 連結の担当へ回すとき、聞き取り済みの条件がそのまま渡るので、担当は聞き直さずに判断に入れます。 誤った回答が出たときも、どの条件で検索したかが分かります。

2つ目は、manual_refs の version で検査ができることです。 中継プログラムは、出典の版が報告の月に効いていない回答を見つけたら、回答を出さずに version_mismatch で回します。 絞り込みの設定を誤ったときの最後の歯止めです。

3つ目は、escalate_reason で回った理由を数えられることです。 not_in_manual が多いシートは要領の書き足しが要り、judgment が多い取引は方針書の書き足しが要ります。 月ごとに数えて、要領の次の改訂の材料にします。

システムへ連携する

連結パッケージと連結の仕組みには、書き込みません。 この構成が出すのは書き方の案内までで、数値を入れるのは子会社の担当、連結の処理をするのは親会社の担当です。 書き込みを足すと、案内の誤りがそのまま連結の数値に入ります。

人が確認する

子会社の担当は、回答を読んだあと必ず出典の要領のページを開いてから書きます。 回答は「どのシートのどの欄か」を示すもので、欄の細かい書き方の例は要領の原文にしかありません。

1. 版とページを確かめる … 報告の月の版の要領か、ページが質問のシートかを見ます
2. 条件が取引と合っているかを確かめる … 聞き返しで選んだ値が、実際の取引と違っていないかを見ます
3. 評価を付ける … 解決した／担当へ回した／誤りを選びます

2番目を軽く見ないでください。 相手が親会社か兄弟会社かを取り違えると、相手先コードの違う欄に書くことになり、親会社の照合で差異として出ます。 回答の上に、選んだ条件を必ず並べて表示します。

連結の担当は、回ってきた質問だけを見ます。 判断を答えたら、その内容を方針書か要領に足すかを、月次の締めのあとにまとめて見直します。 共通に通用するものは、会社名と金額を除いて共通の質疑にします。

目標は、300件をならして1件5分です。 回答で解決した質問の記録の確認と、回ってきた質問を担当が答える時間の平均です。

例外に対処する

7行目は、運用の約束として子会社に伝えておきます。 締めの最終日は回る質問も増え、提出期限の近い会社から答えないと、連結の作業が止まります。 待ち行列に会社ごとの提出期限を付けて並べます。

記録を残す

• 質問の文、選んだ確認項目の値、日時、会社コード、報告の月
• 中継プログラムが組み立てた検索の文と、使った絞り込みの式
• answer メソッドの応答の全文（回答、出典、回答しなかった理由）
• 回す・回さないの判定と、その理由
• 担当の評価と、連結の担当が最終的に答えた内容
• そのとき効いていた要領と方針書の版

最後の行は、監査で効きます。 連結の数値に誤りが見つかり、「子会社はなぜその欄に書いたのか」を確かめるとき、当時の要領の版と、そのとき返した回答が要ります。 要領の改訂のたびに、版の一覧を残します。