Media > AI活用ユースケース > 経理 > 海外から届く請求書と経費の説明を訳して、計上に必要な情報がそろっているか点検する

海外から届く請求書と経費の説明を訳して、計上に必要な情報がそろっているか点検する

実装ステータス:構成例 技術的に実現可能な構成として設計したもの。自社未検証

海外の取引先や拠点から届く外国語の請求書と経費の説明を訳し、計上に必要な項目がそろっているかを点検します。担当者の作業は、辞書を引きながら読み解くことから、訳された内容を確かめて計上することに変わります。

サマリー
利用ツール
ChatGPT/Claude/Gemini/Make/n8n/Power Automate
対象業界
IT・SaaS/その他/商社/建設/製造
対象部門
経理
対象業務
内容確認・チェック/書類作成
主な課題
判断に時間がかかる/属人化している/情報が見つからない
AIで行う処理
翻訳
主な効果
品質標準化/工数削減/検索時間短縮
導入難易度
★★☆☆☆
実装レベル
半自動化
費用感
API連携(中)
人間の確認
条件付き
現在工数
37.3h/月
AI導入後
11.7h/月
想定削減
69%
年間削減
308h
モデル条件による試算値です。実在企業の実績ではありません。

01導入前 / 導入後の業務フロー

導入前(Before)
  1. 海外拠点または取引先から、請求書や経費の説明がメールで届く
  2. 担当者が開いて、どの言語かを確かめる
  3. 読める言語なら自分で読み、読めない言語は翻訳ツールにかける
  4. 何の費用かを読み取る
  5. 計上に必要な項目(金額、通貨、期間、役務の内容、税の扱い)がそろっているかを見る
  6. 足りない項目があれば、現地へ問い合わせる
  7. 時差を挟んで回答を待つ(1〜3日)
  8. そろったら、科目と計上期を判断して起票する
  9. 証憑としてファイルを保管する
導入後(After)
  1. 海外拠点または取引先から、請求書や経費の説明がメールで届く
  2. 自動添付ファイルを受付フォルダへ保存する
  3. 自動言語を判別し、PDFや画像なら文字を取り出す
  4. 自動社内の用語集に沿って訳す
  5. 自動計上に必要な項目を抜き出す
  6. 自動足りない項目、読み取れなかった項目を示す
  7. 自動同じ取引先の過去の処理を併記する
  8. 自動不足がある場合、現地への問い合わせ文の下書きを作る
  9. 人担当者が、訳と抜き出した項目を確かめる
  10. 人問い合わせが要る件は、下書きを確認して送る
  11. 人そろった件を、科目と計上期を判断して起票する
各工程の詳しい説明を読む
  1. 海外拠点または取引先から、請求書や経費の説明がメールで届く
  2. 担当者が開いて、どの言語かを確かめる
  3. 読める言語なら自分で読み、読めない言語は翻訳ツールにかける
  4. 何の費用かを読み取る
  5. 計上に必要な項目(金額、通貨、期間、役務の内容、税の扱い)がそろっているかを見る
  6. 足りない項目があれば、現地へ問い合わせる
  7. 時差を挟んで回答を待つ(1〜3日)
  8. そろったら、科目と計上期を判断して起票する
  9. 証憑としてファイルを保管する

問題は7つあります。

(a)翻訳ツールの訳が実務に合わない。 会計や取引の用語が、一般的な訳になります。「Leistungszeitraum」が「性能期間」と訳されると、役務の提供期間だと分かりません。

(b)何の費用かが読み取れない。 明細に「Service fee」とだけ書かれていて、保守なのか技術指導なのか派遣なのかが分かりません。計上の科目が決まりません。

(c)足りない項目に気づくのが遅い。 月末に処理を始めて、そこで初めて分かります。問い合わせの往復で締めが遅れます。

(d)問い合わせの文面を作るのに時間がかかる。 現地の言語か英語で書きます。何をどう聞けばよいかを、毎回考えています。

(e)担当者に集中している。 中国語が読める人、ドイツ語が読める人が固定です。休むと止まります。

(f)過去の処理が参照されない。 同じ取引先から毎月似た請求書が来ていても、前回どう処理したかを探すのに時間がかかります。

(g)税の扱いが分からない。 現地の付加価値税、源泉税の記載が読み取れません。税理士へ確認する件数が多くなります。

この業務には、2つの別々の難しさが重なっています。 1つは言語の壁、もう1つは「計上に必要な情報がそろっているか」という判断です。前者は道具で解決できますが、後者は自社の基準が要ります。

翻訳ツールを入れれば言語の壁は下がります。しかし、訳した結果を見て「役務の提供期間が書かれていない」と気づくには、何が必要かを知っている必要があります。 そこは経理の知識です。

この構成が扱うのは、両方をつなぐところです。 訳したうえで、自社の基準に照らして足りないものを示す。どちらか一方だけでは、担当者の作業は半分しか減りません。

  1. 海外拠点または取引先から、請求書や経費の説明がメールで届く
  2. 【自動】 添付ファイルを受付フォルダへ保存する
  3. 【自動】 言語を判別し、PDFや画像なら文字を取り出す
  4. 【自動】 社内の用語集に沿って訳す
  5. 【自動】 計上に必要な項目を抜き出す
  6. 【自動】 足りない項目、読み取れなかった項目を示す
  7. 【自動】 同じ取引先の過去の処理を併記する
  8. 【自動】 不足がある場合、現地への問い合わせ文の下書きを作る
  9. 【人】 担当者が、訳と抜き出した項目を確かめる
  10. 【人】 問い合わせが要る件は、下書きを確認して送る
  11. 【人】 そろった件を、科目と計上期を判断して起票する

自動化されるのは「訳す」「抜き出す」「不足を示す」「過去を併記する」「問い合わせ文の下書き」の5つです。残るのは、内容の確認と、会計上の判断です。

科目も計上期も決めません。 「これは修繕費で、当月に計上」といった判断は経理が行います。この構成が出すのは、判断に必要な情報がそろった状態です。

税の扱いも判定しません。 現地の付加価値税、源泉税、国内の消費税の区分は、税法と租税条約によります。「この請求書の税は仕入税額控除の対象です」といった記述を出させないでください。

問い合わせの自動送信もしません。 下書きを作り、担当者が確認して送ります。取引先への連絡を自動化しないでください。

02今回想定するシステム構成

構成図
海外からの請求書・経費の説明(PDF / 画像 / Excel / メール本文)
   │
   ▼ 受付フォルダへ保存(メールのルールで自動)
   │
   ▼【トリガー】保存を検知
   │
   ├──▶ PDF・画像の場合
   │      Azure AI Document Intelligence
   │      ・文字と表の構造を取り出す
   │      ・ページ番号と位置情報を保持
   │
   ▼
Gemini API
   │  ・言語の判別
   │  ・社内の用語集に沿った翻訳
   │  ・計上に必要な項目の抜き出し
   │  ・足りない項目の判定
   │  ・問い合わせ文の下書き
   │  ・system_instruction で役割と禁止事項を固定
   │  ・structured outputs でスキーマどおりのJSONを返させる
   │
   ▼
点検シート(Excel / SharePoint)
   │  ・原文と訳文を並べる
   │  ・抜き出した項目と、その根拠の箇所
   │  ・足りない項目
   │  ・同じ取引先の過去の処理
   │  ・問い合わせ文の下書き
   │
   ▼
担当者が確認 ──【人】訳と項目を確かめる
   │
   ▼
不足がある件 ──【人】問い合わせを送る
   │
   ▼
そろった件 ──【人】科目と計上期を判断して起票
   │
   ▼
処理の結果を記録(次回の参照用)
役割想定する製品代替候補
生成AIGemini APIClaude API、OpenAI API
連携Power AutomateMake、n8n
保管SharePointBox、Google ドライブ
記録Microsoft ListsGoogle スプレッドシート
会計システム既存の会計システム各社の製品

会計システムに多言語の請求書の取り込み機能があるなら、まずそちらを確認してください。 自前で組む価値があるのは、用語集を自社で持ち、計上に必要な項目を自社の基準で点検したい場合です。

Gemini を選ぶ理由は、多言語をまとめて扱えることと、画像も扱えることです。 タイ語・中国語・ドイツ語・英語を1つの仕組みで扱えます。Gemini API はテキスト、画像、動画、音声の入力を扱えるため、請求書の画像をそのまま渡すこともできます。

ただし、PDFや画像の文字の取り出しは、OCRの製品に任せるほうが安定します。 表の行と列の構造を保ったまま取り出せるため、明細行が多い請求書で崩れにくくなります。 生成AIに画像から直接読ませると、明細の行がずれることがあります。

Gemini API では、system_instruction を渡してモデルの振る舞いを設定します。 役割と禁止事項をここに書き、案件ごとの内容は本体のリクエストで渡します。

複数ターンの会話も扱えます。 サーバー側で状態を持つ方式では previous_interaction_id で前のやり取りにつなげます。状態を持たない方式では store=false にして、履歴を自分で管理します。 この構成は1件ずつ完結するため、会話の連結は基本的に使いません。

03どうやって実装するのか

Step1

処理の起点を決める

受付フォルダにファイルが保存されたときを起点にします。

メールの受信箱をそのままトリガーにしないでください。 海外からのメールには、請求書以外のやり取りも大量に含まれます。受信箱のルールで、添付ファイルのあるメールから対象を絞ってフォルダへ保存する形にしてください。

絞り込みの条件を最初に決めてください。

条件例
差出人のドメイン取引先と海外拠点のドメインの一覧
件名の語Invoice、Rechnung、发票、ใบแจ้งหนี้ など
添付の形式PDF、画像、Excel
除外見積書(Quotation、Angebot など)

除外の条件が要ります。 見積書と請求書は様式が似ています。見積書を請求書として処理すると、二重計上の原因になります。

月次のトリガーも置きます。 月初に、前月に処理した件を集計します。どの取引先で不足が多いかが見えると、請求書の様式そのものを取引先と話す材料になります。

締めの前のトリガーも有効です。 月次の締めの3営業日前に、まだ不足が解消していない件を一覧にします。 締めに間に合うかが早く分かります。

Step2

入力データを集める

データ中身取得元
請求書・経費の説明原文(PDF/画像/Excel/メール本文)海外拠点・取引先
用語集現地語・英語と、社内で使う日本語の対応経理部の文書
計上に必要な項目の一覧項目名、必須かどうか、書かれる場所経理部の文書
取引先の一覧名称、国、通貨、取引の内容、担当部署会計システム
過去の処理同じ取引先の過去の請求書と、そのときの処理記録
発注・契約の情報発注番号、契約の期間、金額購買システム
通貨と為替の情報社内レート、換算の基準日経理部の定め
Step3

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

用語集がこの構成の質を決めます。 一般的な翻訳ツールの訳では実務に使えません。次の形で持ってください。

原語言語社内の訳補足
Leistungszeitraumドイツ語役務の提供期間計上期の判断に使う
Skontoドイツ語早期支払割引値引きとして処理
增值税专用发票中国語増値税専用発票仕入税額控除に関わる
ใบกำกับภาษีタイ語税額票付加価値税の証憑
Retainer fee英語顧問料(前払)期間按分の対象

「補足」の列が効きます。 訳しただけでは、その語が計上にどう関わるかが分かりません。「計上期の判断に使う」「仕入税額控除に関わる」と書いておけば、担当者が見落としません。

用語集は、過去の請求書から作ってください。 直近1年の海外請求書を30件ほど見れば、繰り返し出てくる語が50〜80語集まります。最初から網羅しようとしないでください。

計上に必要な項目の一覧も、次の形で整理します。

項目必須かよく書かれる場所書かれていない場合
請求書番号必須冒頭問い合わせる
発行日必須冒頭問い合わせる
通貨必須金額の近く記号だけの場合は要確認($ は米ドルとは限らない)
役務の提供期間必須明細行または備考問い合わせる。計上期が決まらない
役務の内容必須明細行「Service」だけなら問い合わせる
発注番号任意冒頭または備考購買システムで突合できない
税の記載必須金額の下税抜か税込かが分からない。問い合わせる
支払条件任意末尾契約の条件を見る

「書かれていない場合」の列が、この構成の本体です。 何が足りないと何が困るのかを書いておけば、問い合わせの優先度が決まります。

「$ は米ドルとは限らない」のような注意も書いてください。 シンガポールドル、香港ドル、豪ドルも記号は同じです。通貨の取り違えは金額を大きく誤ります。

過去の処理: 運用を始めてからたまります。同じ取引先から毎月同じ内容の請求書が来る場合、前回の処理を示せると判断が速くなります。

用語集は、言語ごとに分けて持ってください。 4言語分をまとめて1つにすると、毎回すべてを渡すことになり入力が長くなります。判別した言語の分だけを渡す形にすれば、費用も精度も改善します。

用語集を育てる仕組みも、最初から決めておいてください。 担当者が訳を直したとき、その語を用語集へ足す流れです。

段階やること
訂正の記録直した箇所と、元の訳・直した訳を残す
月次の集計同じ語が2回以上直されていないかを見る
用語集への追加2回以上なら追加する。補足の列も書く
反映の確認翌月、その語が正しく訳されているかを見る

「2回以上」を基準にする理由は、1回だけの訂正には文脈による例外が含まれるためです。 繰り返し直される語だけを足すほうが、用語集が肥大しません。

発注・契約の情報は、任意ですが価値があります。 発注番号が請求書に書かれていれば、購買システムの発注内容と突き合わせられます。「発注は5,000ユーロなのに請求が5,500ユーロ」という差異を、支払う前に見つけられます。 ただし、海外の取引先が発注番号を書かないことも多く、書かれていない前提で設計してください。

Step4

AIへ渡す前に整形する

  1. ファイル形式の判別 … PDF(文字あり)、PDF(画像)、画像、Excel、メール本文
  2. 文字と表の取り出し … PDFと画像は、レイアウトを保ったまま文字と表を取り出します
  3. 言語の判別 … 文字の種類と語彙から判定します。1つの請求書に2言語が混ざることがあります
  4. 取引先の特定 … 請求書の発行者名と、会計システムの取引先一覧を突き合わせます
  5. 発注番号の抽出 … 書かれていれば、購買システムの発注と突き合わせます
  6. 過去の処理の取得 … 同じ取引先の直近3件を取ります
  7. 重複の検出 … 同じ請求書番号がすでに処理されていないかを確認します

7の重複の検出は必ず入れてください。 海外からの請求書は、催促として同じものが再送されることがあります。二重計上を防ぐ最初の関門です。

3の言語判別で、混在に注意してください。 中国の取引先の請求書は、中国語と英語が混ざります。片方の言語だけを訳すと、抜けが出ます。

Step5

AIに処理させる

処理内容
翻訳原文を日本語に訳す。用語集の語は必ずその訳を使う
項目の抜き出し計上に必要な項目を、原文のどこに書かれていたかとともに
不足の判定必須の項目のうち、見つからないものを列挙
曖昧さの指摘「Service」のような具体性のない記載
過去との比較同じ取引先の前回の請求書との違い
問い合わせ文の下書き不足している項目を聞く文(現地語または英語)

科目も計上期も決めさせません。 「これは修繕費」「当月に計上」といった判断は経理が行います。

税の扱いも判定させません。 「仕入税額控除の対象」「源泉税の税率は10%」といった記述を禁じてください。租税条約と現地の税法が関わり、専門的な判断が要ります。

為替の換算もさせません。 社内レートと換算の基準日は経理部が定めています。計算はシステム側で行ってください。

Step6

指示内容を固定する

役割と禁止事項は system_instruction に書きます。

【system_instruction】
あなたは経理部で海外取引の計上を支援する担当者です。
外国語の請求書と経費の説明を訳し、計上に必要な項目がそろっているかを
点検することが役割です。

【厳守事項】
- 勘定科目を決めないでください。
  「これは修繕費です」「消耗品費に当たります」と書かないでください。
- 計上期を決めないでください。
  「当月に計上すべきです」と書かないでください。
- 税務上の判断をしないでください。
  「仕入税額控除の対象です」「源泉税の税率は10%です」と書かないでください。
  税の記載があれば、それをそのまま訳して示すだけにしてください。
- 為替の換算をしないでください。
  金額は原文の通貨と数値のまま示してください。
- 原文に書かれていないことを補わないでください。
  「一般的にこの種の請求では期間は1か月です」と書かないでください。
  書かれていなければ「記載なし」としてください。
- 用語集に載っている語は、必ず用語集の訳を使ってください。
  一般的な訳に置き換えないでください。
- 抜き出した項目には、原文のどこに書かれていたか(ページと該当箇所)を必ず添えてください。
  示せない項目は「記載なし」としてください。
- 通貨は記号だけで判断しないでください。
  「$」は米ドルとは限りません。国名や通貨コードの記載を確かめ、
  確かめられなければ「要確認」としてください。
- 数値は原文のまま写してください。桁区切りと小数点の記号が
  国によって違うことに注意してください(1.234,56 と 1,234.56)。
- 問い合わせ文は、不足している項目を聞くだけにしてください。
  支払の督促、条件の交渉を含めないでください。

抜き出しの指示は次のようになります。

下の請求書について、訳と項目の抜き出しを行ってください。

【言語】
{detected_languages}

【原文(レイアウトを保った形)】
{document_text}

【用語集(原語 / 言語 / 社内の訳 / 補足)】
{glossary}

【計上に必要な項目の一覧(項目 / 必須か / よく書かれる場所 / 書かれていない場合)】
{required_fields}

【取引先の情報(名称 / 国 / 通貨 / 取引の内容)】
{supplier_info}

【同じ取引先の過去の請求書(直近3件の項目と処理)】
{past_invoices}

【発注の情報(あれば)】
{purchase_order}

「数値は原文のまま写す」の指示が、実務では非常に重要です。 ヨーロッパでは小数点にカンマを使います。「1.234,56」を「1234.56」ではなく「1.23456」と読み違えると、金額が1000分の1になります。 訳す過程で数値を触らせないでください。

「通貨は記号だけで判断しない」も同じ理由です。 シンガポールの取引先からの「$1,000」は、米ドルかシンガポールドルかで金額が大きく違います。

「用語集の訳を必ず使う」の指示は、訳のぶれを止めます。 同じ語が月によって違う訳になると、過去との比較ができなくなります。

「問い合わせ文に督促を含めない」も入れてください。 経理からの問い合わせが督促の形になると、取引先との関係に影響します。聞きたいのは項目の内容だけです。

Step7

出力形式を固定する

{
  "document_id": "",
  "source_file": "",
  "detected_languages": [],
  "supplier": { "name_original": "", "name_matched": "", "country": "", "supplier_code": "" },
  "fields": [
    {
      "name": "",
      "value": "",
      "original_text": "",
      "location": { "page": 0, "area": "" },
      "status": "found | not_found | needs_check",
      "note": ""
    }
  ],
  "line_items": [
    { "description_original": "", "description_ja": "", "quantity": "", "unit_price": "", "amount": "", "vague": false }
  ],
  "currency": { "value": "", "confidence": "high | low", "basis": "" },
  "tax_note_original": "",
  "tax_note_ja": "",
  "missing_required": [],
  "duplicate_of": null,
  "po_matched": null,
  "differences_from_last": [],
  "inquiry_draft": { "language": "", "body": "" },
  "ready_for_entry": false
}

Gemini API で構造化した出力を得るには、response_format にオブジェクト型を指定して mime_type を application/json にし、schema にスキーマを渡します。 スキーマは JSON Schema の一部に対応しており、string / number / integer / boolean / object / array / null の型と、description / enum / required / minimum / maximum などが使えます。

ただし、JSON Schema のすべての機能に対応しているわけではありません。 また、非常に大きなスキーマや深くネストしたスキーマは受け付けられないことがあります。 出力は構文としては正しいJSONになりますが、内容が意味として正しいかは、受け取った側で確かめてください。

currency を独立させ、confidence を持たせている点が実務では効きます。 通貨の取り違えは金額を大きく誤ります。low の場合は必ず人が確かめる設計にしてください。

vague のフラグも要ります。 明細の記載が「Service」「Misc」のように具体性がない場合に立てます。科目を決めるのに足りない、という合図です。

tax_note_original と tax_note_ja を分けている理由があります。 税の記載は判断せず、原文と訳の両方をそのまま残します。 判断は税理士と経理が行います。

differences_from_last は、前回の請求書との違いです。 単価が変わった、明細が増えた、通貨が変わった。繰り返しの取引では、違いだけを見れば足ります。

Step8

システムへ連携する

会計システムへの自動起票は行いません。

出力先内容
Excel(SharePoint)点検シート。原文・訳・項目・不足
Microsoft Lists処理の記録と、不足の解消の状況
メール問い合わせの下書き(担当者が確認して送る)
会計システム担当者が判断して起票

自動起票をしない理由は、科目と計上期の判断が残っているからです。 この構成が出すのは、判断に必要な情報がそろった状態までです。

問い合わせの自動送信もしません。 取引先への連絡は、担当者が内容を確認して送ります。現地の担当者との関係を考えると、自動で送られる連絡は望ましくありません。

購買システムとの突合は自動で構いません。 発注番号が書かれていれば、発注の内容と金額を突き合わせます。ここは判断が要らない機械的な処理です。

原文のファイルは、証憑として保管します。 訳文は参考であって証憑ではありません。原文を必ず残してください。

Step9

人が確認する

担当者の確認は必ず残します。 確認の深さを、状態で分けます。

状態確認
必須項目がすべて found、通貨の確信度が高い訳を通し読みして起票へ
needs_check の項目があるその項目を原文と並べて確認
currency.confidence が low必ず確かめる。金額を大きく誤る
vague の明細がある何の費用かを現地へ確認
missing_required がある問い合わせ文を確認して送る
duplicate_of がある二重計上でないかを確かめる
differences_from_last がある単価や条件の変更を確認

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

  • 原文と訳文を左右に並べる
  • 抜き出した項目に、原文の該当箇所を示す
  • missing_required を上に集める
  • 同じ取引先の前回の処理を併記する
  • 明細の金額の合計と請求総額の一致を機械で確かめて示す

5つ目は、AIにさせずシステムで計算してください。 明細の合計と総額が合わないことがあります。この確認は計算であって、判断ではありません。

訳文をそのまま証憑にしないでください。 監査や税務調査では原文が求められます。訳は理解のための補助です。 点検シートにもその旨を書いてください。

Step10

例外に対処する

起きること対応
1つの請求書に2言語が混ざる両方を訳す。片方だけだと抜けが出る
通貨が記号だけneeds_check にする。推測しない
小数点と桁区切りの記号が国により違う原文のまま写す。変換させない
同じ請求書が再送された請求書番号で重複を検出する
見積書が請求書として処理される受付の条件で除外する
手書きの補記がある読み取れなければ人が読む
用語集にない語が出るそのまま原語を残し、訳に注記する。推測で訳さない
明細の合計と総額が合わない機械で検算して示す。人が確認する
発注番号がない購買システムで突合できない旨を示す
現地の税制の記載が読み取れない原文のまま残す。税理士へ回す
取引先名が会計システムにない新規の取引先として人が確認する
画像の質が悪くて読めない再送を依頼する。推測で読まない
訳文を証憑として保管してしまう原文を必ず保管する
問い合わせが督促の文面になる項目を聞くだけにする指示を入れる

「小数点と桁区切り」は、実務でもっとも危険な誤りです。 ドイツやタイの請求書では「1.234,56」と書かれます。これを「1,234.56」に直す処理を入れないでください。 原文のまま残し、システム側で通貨と国に応じて解釈してください。

Step11

記録を残す

この記録は、取引先ごとの傾向を見る材料になります。

  • 原文のファイル(証憑として保管)
  • 訳文と、抜き出した項目
  • 不足していた項目と、問い合わせの内容
  • 現地からの回答と、解消までの日数
  • 担当者の訂正(訳の直し、項目の直し)
  • 最終的な計上の内容(科目・金額・計上期)
  • 用語集に足した語

「解消までの日数」を必ず記録してください。 どの取引先の、どの項目の不足が、締めを遅らせているかが分かります。特定の取引先で毎月同じ項目が抜けているなら、請求書の様式そのものを話すべきです。

「担当者の訳の直し」も記録してください。 同じ語が繰り返し直されているなら、用語集に足すべき語です。

原文には、取引の内容と金額が含まれます。 保管場所と閲覧範囲を経理部に限定してください。海外拠点の経費には、現地の従業員の氏名が含まれることがあります。

保存期間は、会計帳簿と証憑の保存期間に従ってください。 訳文をどこまで保存するかも、あわせて決めてください。

04実装レベルの3段階

最小構成:請求書をチャット画面に貼り、訳と項目の抜き出しをさせる / 翻訳と抜き出し
半自動化:受付フォルダへの保存をトリガーに、OCR・翻訳・抜き出し・点検シートの作成まで / 処理の大部分
本格構成:上記+過去の処理との比較+問い合わせ文の下書き+購買システムとの突合+締め前の一覧 / 締めの管理まで

半自動化の時点で、16分が8分程度になります。 訳す作業が消えるためです。本格構成では5分になりますが、減るのは不足の問い合わせの手間です。 本格構成の「締め前の一覧」が、実務では効きます。 月次の締めの3営業日前に、まだ不足が解消していない件を一覧にします。 締めに間に合わない件が早く分かると、代替の手段(見積で仮計上する、翌月へ回す)を取れます。 「購買システムとの突合」も本格構成で入れてください。 発注番号が書かれていれば、発注の金額と請求の金額を突き合わせられます。金額が違う請求書を、支払う前に見つけられます。 段階を飛ばさないでください。 訳の精度が確かめられていない状態で締めの管理まで組むと、誤った訳に基づいて締めの判断をすることになります。 半自動化で3か月運用し、訂正の記録を見てから先へ進んでください。 言語を増やす順番にも、決まりを設けてください。 件数の多い言語から1つずつです。4言語を一度に始めると、どの言語で精度が出ていないかが分かりません。 2つ目に「読める担当者がいない言語」を置く理由があります。 英語は担当者が読めるため、時間の削減は限定的です。タイ語や中国語のように、読める人が1名しかいない言語のほうが、属人化の解消という点で効果が出ます。 ただし、読める人がいない言語ほど、訳の検証が難しくなります。 最小構成の段階で、現地の拠点の担当者に訳の正しさを確かめてもらう工程を1回入れてください。

05工数削減シミュレーション

前提値(モデル条件)
対象人数
3 名
月間件数
140 件
1件あたり現在時間
16 分
1件あたり導入後時間
5 分
現在  140件 × 16分 ÷ 60 = 37.3 時間/月
導入後 140件 × 5分 ÷ 60 = 11.7 時間/月
月間削減時間
25.7h
削減率
69%
年間削減時間
308h
年間金額換算(時間単価3,500円)
108万円
モデル条件による試算であり、実際の効果は業務内容・運用方法によって異なります。

自社条件で導入効果を整理したい方へ

このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。

AI活用について相談する

06向いている企業・向いていない企業

向いている
  1. 海外の取引先や拠点から、月に50件以上の請求書・経費の説明が外国語で届く企業。英語以外の言語(中国語・タイ語・ドイツ語など)が混ざる場合。担当者1〜2名が訳して処理しており、その人が休むと止まる場合。何の費用か分からず、現地へ問い合わせる往復に時間がかかっている場合。
向いていない
  1. 海外との取引がほとんどない企業。海外拠点との取引がすべて英語で、社内の様式に統一されている場合。購買システムで発注と請求が紐づいており、請求書の内容を読み解く必要がない場合。会計処理を現地の会計事務所へ委託しており、本社が請求書を見ない場合。

07最小構成で試す方法

  1. 言語を1つ選ぶ(件数の多いもの。多くの場合は英語か中国語)
  2. その言語の過去の請求書を20件用意する
  3. 用語集を30語作る(20件から繰り返し出る語を拾う)
  4. 計上に必要な項目の一覧を作る
  5. 生成AIのチャット画面に、用語集と請求書を貼り付けて訳と抜き出しをさせる
  6. 実際の処理内容と突き合わせる

見るのは次の4点です。

見る点判断
必須項目の抜き出しの正解率9割以上。外れる項目を特定する
数値が原文のまま写されているか1件でも変換されていたら指示を直す。ここは妥協しない
用語集の語が正しく使われているか一般的な訳に置き換えられていないか
科目・計上期・税の判断が混ざっていないか混ざったら指示を直す

2つ目が最重要です。 金額の誤りは、後から見つけにくく、影響が大きくなります。桁区切りがカンマの請求書とピリオドの請求書を両方混ぜて試してください。

次に、用語集の有無で差を測ってください。 用語集なしの版と、30語入れた版で同じ20件を訳します。差が大きければ、語を増やす価値があります。

不足の判定も試してください。 意図的に項目を消した請求書を5件作り、すべて missing_required に出るかを確かめます。 ここが機能しないと、月末の問い合わせは減りません。

この段階では、OCRは使わなくて構いません。 文字が埋め込まれたPDFを選んで試してください。訳と抜き出しの精度を先に確かめ、画像の読み取りはその後です。

08実装時につまずきやすいポイント

問題対策
数値が変換されて金額を誤る原文のまま写す指示を入れる。テストで必ず確認する
通貨を記号だけで判断する確信度を持たせ、低い場合は人が確認する
用語集がなく訳がぶれる30〜50語から始める。訂正のたびに足す
用語集にない語を推測で訳す原語を残して注記する指示を入れる
AIが科目や計上期を決める禁止する。テストで必ず確認する
AIが税務の判断を書く禁止する。原文と訳をそのまま残す
1つの請求書の2言語のうち片方しか訳さない言語の判別で混在を検出する
見積書を請求書として処理する受付の条件で除外する
同じ請求書の再送で二重計上する請求書番号で重複を検出する
明細の合計と総額の不一致に気づかないシステムで検算する
訳文を証憑として保管する原文を必ず保管する
問い合わせが督促の文面になる項目を聞くだけにする指示を入れる
画像の質が悪いまま読ませる読めなければ再送を依頼する
会計システムへ自動起票する行わない。科目と計上期は人が決める

09セキュリティ・AIガバナンス上の注意点

この構成で扱うデータ: 海外取引先の名称、取引の内容、金額、支払条件、海外拠点の経費の明細。取引条件と、場合によっては現地の従業員の氏名が含まれます。

  1. 外部AIへの入力可否 … 請求書の内容を外部のAIサービスへ送ることになります。取引先との秘密保持契約に、取引情報の第三者への開示についての定めがないかを確認してください
  2. 国をまたぐデータの移転 … 海外拠点のデータを扱う場合、現地の個人情報保護の法令が関わることがあります。 EUの拠点のデータであればGDPR、中国であれば個人情報保護法の対象になりうるため、法務部門と確認してください
  3. 送る情報を絞る … 訳と抜き出しに、取引先の銀行口座は不要です。送らなくてよい項目は前処理で伏せてください
  4. 学習利用 … 入力を学習に使わないことが契約で保証されるサービスを選びます
  5. アクセス権限 … 点検シートには、取引先ごとの取引条件と金額が集まります。閲覧を経理部に限定してください
  6. 会計上の判断との分離 … この構成は勘定科目、計上期、税の扱いを判断しません。 判断は経理部と税理士が行います。点検シートにその旨を明記してください
  7. 税務上の証憑 … 訳文は証憑ではありません。 税務調査や監査で求められるのは原文です。原文を必ず保管し、訳文はそれと紐づけてください
  8. 為替の換算 … この構成は換算を行いません。社内レートと基準日は経理部の定めに従ってください
  9. 監査対応 … 訳の内容と、抜き出した項目の根拠(原文のどこか)を記録に残してください。「AIが訳した」では説明になりません
  10. 自動実行してよい範囲 … 翻訳、項目の抜き出し、不足の判定、問い合わせ文の下書きまでです。問い合わせの送信、科目と計上期の判断、起票、支払は人が行います

誤りが起きた場合のリスクは、訳の誤りや数値の読み違いによって誤った金額で計上されること、逆に訳を信用せず結局原文を読み直す状態になることです。前者への備えとして、数値を変換させない設計と、通貨の確信度による人の確認を必ず入れてください。 後者への備えとして、原文と訳文を並べて表示する設計を守ってください。

10まず何から始めるか

1週目:用語集を30語作る

過去1年の海外請求書を30件見て、繰り返し出てくる語を拾います。「補足」の列に、その語が計上のどこに関わるかを書いてください。 この作業がこの構成の土台です。

2週目:計上に必要な項目の一覧を作る

項目・必須かどうか・よく書かれる場所・書かれていない場合の4列で整えます。「書かれていない場合」に何が困るかを書いてください。 問い合わせの優先度がここで決まります。

3週目:1言語20件で試す

件数の多い言語を選び、訳と抜き出しを試します。数値が原文のまま写されているかを、1件ずつ確かめてください。 桁区切りがカンマの請求書とピリオドの請求書を両方混ぜてください。

4週目:不足の判定を試す

意図的に項目を消した請求書を5件作り、すべて検出されるかを確かめます。ここが機能しないと、月末の問い合わせは減りません。

2か月目: 半自動化を1言語で回します。訳の訂正を必ず記録してください。 繰り返し直される語が、用語集に足すべき語です。

3か月目以降: 言語を増やし、過去の処理との比較と問い合わせ文の下書きを足します。同時に、締め前の一覧を作ってください。 締めに間に合わない件が早く分かる効果は、時間の削減より大きく感じられるはずです。

半年後: 不足の解消までの日数を、導入前と比べてください。取引先ごとに集計すると、毎月同じ項目が抜けている取引先が見えます。 そこは請求書の様式そのものを話す機会です。訳して読むより、最初から必要な項目が書かれているほうが、双方にとって早く済みます。


11関連ユースケース

12この仕組みを理解するための記事

13技術仕様の確認日・参考情報

技術仕様確認日:2026-09-25/最終更新:2026-09-25
確認した内容情報源確認日
Gemini API で system_instruction を渡してモデルの振る舞いを設定できること。複数ターンの会話について、サーバー側で状態を持つ方式では previous_interaction_id で前のやり取りにつなげ、状態を持たない方式では store=false にして履歴を自分で管理すること。テキスト・画像・動画・音声の入力を扱えることGemini API Docs: Text generation2026-09-25
Gemini API で構造化した出力を得る際、response_format にオブジェクト型を指定して mime_type を application/json にし、schema にスキーマを渡すこと。対応するのは JSON Schema の一部で、string / number / integer / boolean / object / array / null の型と description / enum / required / minimum / maximum などが使えること。すべての JSON Schema の機能に対応するわけではなく、非常に大きなスキーマや深くネストしたスキーマは受け付けられないことがあること。出力は構文として正しいJSONになるが、内容の妥当性はアプリケーション側で確かめる必要があることGemini API Docs: Structured output2026-09-25
Azure AI Document Intelligence のカスタム抽出モデルが、キーと値の組・選択マーク・表・署名などを抽出でき、カスタムテンプレートは見た目が一定の様式に、カスタムニューラルは同じ情報でページ構成が異なる書類に適すること(請求書の様式が取引先ごとに異なる場合の読み取りとして確認)Microsoft Learn: Custom document models - Document Intelligence2026-09-25

請求書に必要な記載事項、証憑の保存期間、外国語の証憑の取扱いは、法令と自社の規程によって異なります。この部分は自社の経理部門および税理士の確認に従ってください。 現地の付加価値税、源泉税、租税条約の適用については、税務の専門家の判断が必要です。この記事は税務上の判断を示すものではありません。海外拠点のデータを扱う場合、現地の個人情報保護の法令が関わることがあります。外部のAIサービスへ渡してよいかは、取引先との秘密保持契約と自社の情報管理の責任者の判断が必要です。

実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。

自社の業務に使えるAI活用候補を整理します

このユースケース(UC-0253)についてのご相談はこちらから。

AI活用について相談する
目次