「この支出はどの科目か」の問い合わせに、科目表と過去の仕訳を根拠に答える

処理の起点を決める

社員が Teams でエージェントに質問したときを起点にします。

窓口を Teams に置くことが重要です。 経理への問い合わせは、いまも Teams とメールと口頭に分かれています。エージェントを別のアプリに置くと、そこへ行く手間が増えて使われません。

メールと口頭は残してください。 「エージェントに聞け」と強制すると、使いにくいと感じた人が聞かずに申請します。聞かずに申請されるほうが、経理の手戻りは大きくなります。

もう1つの起点として、経費精算システムで申請が差し戻されたときがあります。差し戻しの理由が科目の誤りなら、その時点で正しい科目と根拠を示せると、同じ誤りが減ります。

月次の見直しのトリガーも置いてください。 月初に、前月の質問と回答を集計して経理へ渡します。この見直しがないと、科目表は古いままになります。

入力データを集める

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

科目表がこの構成の質を決めます。 現状の科目表は「科目コード・名称・定義」の3列だけのはずです。これを次の形に作り直してください。

「含まないもの」の列が、この構成でいちばん効きます。 定義文だけでは「これは当たるのか」が判断できません。「これは含まない、代わりにこの科目」と書かれていれば、その場で分かります。

「判断の分かれ目」の列も必須です。 現場の質問の大半は、2つの科目のどちらかで迷っているものです。「何を見れば決まるのか」を1文で書いてください。

「よくある誤り」は、過去の振替の記録から拾えます。 期末に科目間の振替をした事例を10件ほど見れば、繰り返し起きている誤りが分かります。

過去の仕訳の索引： 会計システムから月次で書き出します。全件は要りません。直近24か月、費用科目のみで十分です。

摘要の書き方がばらつく問題への対処が要ります。書き出すときに、次の列を足してください。

この正規化は、決まった置き換えの表で行ってください。 生成AIに毎回寄せさせると、寄せ方が安定しません。同義語の表を作り、機械的に置き換えるほうが確実です。

回答集： 運用を始めてからたまります。最初は空で構いません。 ただし、過去に経理がメールで答えた内容が残っているなら、そこから30件ほど拾って初期データにしてください。 これがあるだけで、最初の1か月の当たり方が変わります。

経費規程と科目表を、同じ知識ソースに混ぜないでください。 経費規程は「精算してよいか」を定めた文書、科目表は「どの科目か」を定めた文書です。質問の性質が違います。

混ぜると、科目の質問に規程の記述が引かれてきます。 生成回答ノードの「選択したソースのみ検索する」で、科目の照会には科目表と回答集だけを見せる形にしてください。

金額の基準は、科目表の側に書いてください。 「10万円未満は消耗品費、10万円以上は工具器具備品」という基準は、科目の判断に直結します。経費規程を見に行かないと分からない状態にしないでください。

部署と人数の情報は、この構成では必須ではありません。 ただし、「案件に紐づくかどうか」が判断の分かれ目になる会社では、質問者の所属と進行中の案件が分かると、聞き返しが1往復減ります。 個人を特定する情報を渡すことになるため、必要性を検討してから決めてください。

AIへ渡す前に整形する

1. 科目表の形式の変換 … Excel のままでは生成回答ノードの対象外です。PDF か Word に書き出すか、SharePoint リストへ移します
2. 文書の粒度をそろえる … 科目1つにつき1ページ、または1項目にします。120科目を1つのファイルに詰め込むと、引用の粒度が粗くなります
3. 摘要の正規化 … 同義語の表で機械的に置き換えます
4. 個人名・取引先名の扱い … 過去の仕訳には取引先名が入ります。索引に残すかを経理部で決めてください
5. 古い仕訳の除外 … 科目体系を変更した時期より前の仕訳は、索引から外します。古い体系の仕訳を根拠にすると誤った回答になります
6. 知識ソースの限定 … 生成回答ノードの「選択したソースのみ検索する」を使い、科目の照会に使うソースだけに絞ります

6の設定について補足します。 この設定をオンにすると、そのノードは選んだソースだけを検索し、エージェント全体に登録した知識ソースは検索しません。 選んだソースで答えが出なくても、全体のソースへ自動でフォールバックすることはありません。科目の照会に、就業規則や営業資料が混ざるのを防げます。

AIに処理させる

科目を確定させません。 「この科目で計上してください」ではなく、「科目表ではこう書かれています」「過去はこう処理されています」と示すにとどめます。

税務上の判断もさせません。 損金算入の可否、消費税の区分、償却の方法は、この構成の範囲外です。「交際費は年間800万円まで損金になります」といった記述を出させないでください。

金額の按分もさせません。 「この費用は3つの案件に按分してください」という判断は、実態を知る人が行います。

指示内容を固定する

エージェントの指示には、次の内容を書きます。

あなたは経理部で勘定科目の照会に答える担当者です。
社員からの「この支出はどの科目か」という質問に、
自社の科目表と過去の仕訳を根拠にして候補を返すことが役割です。

【厳守事項】
- 科目を確定させないでください。
  「この科目で計上してください」と書かないでください。
  「科目表ではこう書かれています」「過去はこう処理されています」
  という事実の提示にとどめてください。
- 税務上の判断をしないでください。
  損金算入の可否、消費税の区分、償却の方法について書かないでください。
  聞かれた場合は「経理部へご確認ください」と返してください。
- 金額の按分を指示しないでください。
- 科目表と過去の仕訳に書かれていないことを、一般的な会計の知識で補わないでください。
  該当が見つからない場合は「該当が見つかりません。経理部へお回しします」と返してください。
- すべての回答に、根拠となる文書と該当箇所を必ず引用してください。
  引用を示せない回答は返さないでください。
- 判断に必要な情報が足りない場合は、1つずつ聞き返してください。
  一度に4つ質問しないでください。
  聞くのは「何を買ったか」「何のためか」「案件に紐づくか」「金額」の4点です。
- 候補が2つ以上に絞れない場合、無理に1つへ絞らないでください。
  候補を並べ、何で決まるのかを示したうえで、経理部へお回しします。
- 過去の仕訳を示すときは、それが必ずしも正しい処理とは限らないことを添えてください。
- 回答の最後に「最終的な科目は経理部が確認します」と必ず書いてください。

「引用を示せない回答は返さない」の指示が、この構成の安全装置です。 Copilot Studio 側の設定でも、「根拠のない回答を許可する」をオフにしておくと、知識ソースへの本文中の引用を含む回答だけが返ります。 引用が付かない場合、回答は差し控えられます。

ただし、モデルが正しい回答を作りながら引用を付け忘れることがあり、そのときは回答が保留されます。 公式の案内では、指示の中で「すべての記述に出典の引用を付ける」と明示すること、出力形式を厳しく固定する指示（「JSONのみで返す」など）を避けることが対策として挙げられています。

「一度に4つ質問しない」の指示も実務では効きます。 「何を買いましたか、何のためですか、案件はありますか、金額は」と一度に聞かれると、社員は答えるのが面倒になります。1つずつ聞くほうが、結果として早く終わります。

「過去の仕訳が正しいとは限らない」の一文は、必ず入れてください。 過去に誤った科目で処理されていた場合、それを根拠に同じ誤りが繰り返されます。

「候補が2つ以上に絞れない場合、無理に1つへ絞らない」の指示にも理由があります。 現場の質問の多くは、2つの科目のどちらかで迷っているものです。そこで機械的に1つを選ばせると、判断の分かれ目を示す機会が失われます。

「交際費と会議費のどちらか」という質問に対して、「参加者に社外の人が含まれるかで分かれます」と示せれば、現場は自分で判断できます。 次回から聞かずに済むようになります。この構成の目的は、照会に答えることではなく、照会が減ることです。

指示のテストでは、次の4つを意図的に試してください。

2つ目が実務ではよく起きます。 現場は「経費で落ちるか」と「どの科目か」を区別していません。質問の意図を確かめる工程が、対話の最初に要ります。

出力形式を固定する

回答は文章で返しますが、次の要素を必ず含めます。

記録には、次の形で残します。

{
  "asked_at": "",
  "asker_department": "",
  "question": "",
  "clarifications": [],
  "candidates": [
    { "account_code": "", "account_name": "", "evidence_doc": "", "evidence_text": "" }
  ],
  "past_entries_found": 0,
  "routed_to_accounting": false,
  "accounting_answer": "",
  "final_account_code": "",
  "answer_matched": null
}

answer_matched の列が、この構成を育てます。 エージェントの候補と、最終的に計上された科目が一致したかを記録します。一致率が測れると、どの科目で外しているかが分かります。

routed_to_accounting も必ず記録してください。 経理へ回った件が減っているかが、削減の実感につながります。

past_entries_found が0の質問は、新しい種類の支出です。 科目表に項目を足す候補になります。

システムへ連携する

回答を返すだけで、会計システムや経費精算システムへの書き込みは行いません。

経費精算システムへ科目を自動で入れないでください。 申請の内容は申請者が決めます。自動で入ると、申請者が内容を確認しないまま出すようになります。

会計システムへの書き戻しも行いません。 仕訳の起票は経理の作業です。

過去の仕訳の索引は、月次で作り直してください。 リアルタイム連携は要りません。月に1回、前月分を足すだけで十分です。 ただし、索引の最終更新日を回答に添えるようにしてください。古い索引で答えていることが分かります。

人が確認する

経理担当者の確認は、2つの場面で残します。

（1）経理へ回された件

候補が絞れなかった件、科目表に該当がない件です。ここは従来どおり経理が調べて答えます。 月180件のうち、40件程度がここに残る想定です。

（2）申請された内容の確認

エージェントの回答を見て申請された経費も、これまでどおり経理が確認します。エージェントを通ったことは、科目が正しいことを意味しません。

確認を速くするための設計が効きます。

• 経理へ回った件に、エージェントが提示した候補と根拠を添える
• 同じ質問が過去にあった場合、そのときの回答を併記する
• 質問者の部署と案件を併記する（判断の分かれ目が案件の有無であることが多い）
• past_entries_found が0の件に印を付ける（新しい種類の支出）

2つ目が効きます。 「この質問は3か月前にも出ていて、そのときは研修費と答えている」と分かれば、経理は即答できます。回答のぶれも減ります。

月次の見直しも、人が行う作業として組み込んでください。 前月の記録を見て、次を判断します。

例外に対処する

「Excel の科目表が検索されない」は、導入初期に必ず起きます。 経理の文書はほとんどが Excel です。生成回答が扱えるのは SharePoint のモダンページ、docx、pptx、pdf なので、そのままでは読まれません。 科目表を SharePoint リストにするか、PDF に書き出す作業が先に要ります。

記録を残す

この記録は、科目表を育てる材料になります。

• 質問の全文と、聞き返しのやり取り
• 提示した候補と、根拠にした文書
• 経理へ回したかどうか
• 経理の回答（回った場合）
• 最終的に計上された科目
• 候補と最終の科目が一致したか
• 質問者の部署（個人は記録しない）

質問者を個人単位で記録しないでください。 「誰が何回聞いたか」という記録は、聞きにくさを生みます。部署単位で十分です。

「最終的に計上された科目」は、月次で会計システムから突き合わせてください。 申請番号と仕訳を紐づければ機械的に取れます。これがないと、当たっているかどうかが永久に分かりません。

保存期間は、会計帳簿の保存期間に合わせるのが安全です。 科目の判断の経緯は、監査で問われることがあります。

科目表と過去の仕訳には、取引先名と金額が含まれます。 SharePoint の閲覧権限を、この用途に必要な範囲へ限定してください。ただし、Entra ID 認証を使う構成では、利用者本人が見られない文書は回答に出ません。 この点は設計上の利点です。