会計における生成AI:実践的な活用と精度の限界

会計担当者が原資料に照らして下書きを確認する様子で示す、会計における生成AIとは

Turn this article into takeaways for your work.

Each assistant summarizes the article only for you and suggests best practices for your work.

会計における生成AIとは、言語モデルを使って、文章中心の会計業務(技術的なメモ、方針のリサーチ、差異コメント、数式の支援、文書化)を下書きや要約として進め、資格を持つ担当者がすべての数字、引用、結論を検証してから使うことを意味します。 モデルは流暢かつ高速に書きます。しかし、確実に計算することはできず、自社の元帳を知らず、誤った基準を自信たっぷりに述べることがあります。したがって、有益な問いは「このタスクができるか」ではなく、「その出力にはどんな確認が必要か」です。

本記事は、CFO、コントローラー、財務ディレクター、経理マネージャー向けです。生成AIが役に立つ業務、業務・適性・必要な確認を整理した表、導入の順序、そして数字が監査される職業で問題になる失敗パターンを扱います。財務部門全体にわたるAIの全体像については、まず財務におけるAIをご覧ください。

重要なポイント

  • ICAEWの生成AIガイドは、モデルが「引用や参考文献をでっち上げる」ことがあり、「異議を唱えられると自己矛盾する」ことがあると述べ、人間にはオートメーションバイアス、つまり技術の出力に過度に頼る傾向があると警告しています(ICAEW, Generative AI guide: risks and limitations)。
  • AICPAは、AIを使う場合でも、能力、正当な注意、守秘義務、独立性という中核的な義務は引き続き適用され、ツールが社内で作られたものか第三者によるものかを問わず、最終的な成果物に対する責任は専門家にあると述べています(Journal of Accountancy, AICPA Professional Ethics Division, August 2026)。
  • PCAOBのスタッフが大手監査法人に対して行ったヒアリング(2024年7月)で、各法人は生成AIを主に事務的な作業やリサーチ、たとえばメモの初稿や社内の会計・監査ガイダンスの調査に使っていると説明し、出力の人によるレビューは引き続き不可欠だと述べました(PCAOB staff Spotlight, July 2024)。
  • 算術、代数、整数論の問題でGPT-4o、o1、DeepSeek-V3、DeepSeek-R1を調べた2025年の研究では、手順上のミスが最も多い誤りの種類であり、精度はモデル間で大きく異なりました(Mathematical Computation and Reasoning Errors by Large Language Models, arXiv)。

会計における生成AIの得意なことと、不得意なこと

生成AIは、ありそうな文章を予測します。それは、40ページのリース契約の要約、方針の平易な言い換え、箇条書きからのメモの初版づくりのような、言語が中心の業務では強みになります。合計、レート、条文番号、しきい値のように、正確でなければならない業務では弱みになります。

この記事のほぼすべての統制は、3つの限界から導かれます。

でっち上げをします。 この挙動はAIハルシネーションと呼ばれます。PCAOBのスタッフ報告は、監査法人が、生成された出力が虚偽や誤解を招くもの、あるいは偏りやバイアスのあるものである可能性を認識していると指摘しており、レビュー担当者がたどれるように、使用したソースデータを文書化するツールを構築している法人もあります。存在しない基準の条文番号への、もっともらしい引用は、会計における典型例です。

算術が信頼できません。 言語モデルは、電卓を渡さない限り電卓を使いません。上記のarXivの研究では、検証したモデル全体で手順上のミスが最も多い誤りでした。その研究で推論に特化したモデルは他より大幅に優れていたため、差は縮まりつつありますが、「より良い」は「元帳水準」ではありません。モデルが計算したものはすべて、自社のスプレッドシートやシステムで再計算してください。

自社の事実を知りません。 試算表、契約書、方針を渡さない限り、モデルは一般的な前提で空白を埋めます。たとえば検索拡張生成によって自社の文書に基づかせると、これは減りますが、なくなるわけではありません。

業務ごとの適性と必要な確認

この表が、本記事の実務の中核です。「適性」はリスクについての判断であり、品質の保証ではありません。検出されない誤りがどれだけの損害を与えうるか、そして出力をどれだけ容易に検証できるかを反映しています。

3つの独立した確認手段で示す、会計AIの検証チェック

業務 適性 AIが行うこと 使用前に必要な確認
技術的な会計メモの初稿 レビューを前提に良好 事実と結論をもとにメモの構成を作り、背景と分析の文章を下書きする 技術レビュー担当者が、すべての基準の引用を原文と照らして確認し、結論がモデルのものではなく自分のものであることを確認する
方針と基準のリサーチ 出発点としてのみ 基準を要約し、調べる場所を示し、検討すべき問いを列挙する 原典の基準を自分で読む。引用や条文番号は、原典で見つかるまで未検証として扱う
差異コメント レビューを前提に良好 差異の表と、ドライバーに関する自分のメモを読みやすい説明文にする 作成者が文中のすべての数字を明細表と突き合わせ、述べられた各原因を予算責任者と確認する
照合の支援 一長一短 異例の項目を説明し、フォローアップのメールを下書きし、レビュー用に照合理由の候補を提案する 照合と合計はモデルではなく自社のシステムまたはスプレッドシートから得る。例外は人が1件ずつ解消する
スプレッドシートの数式とマクロ テストを前提に良好 数式を書く、または説明する、関数間でロジックを変換する 答えが分かっている入力でテストし、空白、負の値、日付の境界などの端のケースを確認する
監査文書の下書き レビューを前提に良好 ウォークスルーの説明文を下書きし、監査調書の文言を整え、欠けているセクションを指摘する その手続を実施した本人が、実際に行ったことと合致していることを確認する。実施していない作業をAIに記述させてはならない
仕訳の摘要と勘定の説明 良好 明確な摘要と、平易な言葉での説明を下書きする 仕訳と照らして抜き打ちチェックする。低リスクで大量
計算(減価償却、リース、税、FX) 単独では不十分 手法を説明し、手順の概要を示せる スプレッドシートまたは会計システムで計算する。モデルは手法の説明にのみ使う
最終的な税務上の判断と監査意見 不適 事実を要約し、背景を下書きすることはある 専門家としての判断と最終承認は、責任ある担当者に残る
顧客や従業員の機密データを含むあらゆるもの 承認されたツールでのみ ツールのデータ条件による 自社が承認したツールだけを使い、データの取り扱い条件をレビューする

パターンは、AIは下書きと説明の層だということです。数字、引用、結論を生み出すものはすべて、モデルに依存しない検証のステップを通します。

会計の職種別の実例

技術会計と方針。 新しい種類の契約に直面したコントローラーが、収益認識の分析が答えるべき問いの概要を出し、契約の要約から背景のセクションを下書きするようモデルに頼みます。その後、コントローラーが結論を書き、引用されたガイダンスを基準の原文で読み、下書きの誤りを直します。モデルが節約したのは白紙から始める時間であり、判断はしていません。

財務計画と決算コメント。 月次決算で、アナリストが差異の表とドライバーに関する数行を貼り付けると、モデルが説明文を下書きします。ここでのリスクは見えにくいものです。モデルが数字をわずかに誤って言い直したり、差異のもっともらしい理由を作り出したりすることがあります。段落内のすべての数字を明細表と突き合わせ、すべての原因を予算責任者と確認します。関連する財務のワークフローは、AIの財務ユースケースで扱っています。

買掛金と売掛金。 モデルは、仕入先へのフォローアップの下書き、争いのある請求書に関する長いメールのやりとりの要約、支払が一致しなかった理由の説明を助けます。照合そのものは決定論的なツールの領域であり、財務向けAIエージェントやルールベースの自動化が役立つのはそこです。

監査と保証。 PCAOBのスタッフ報告は、監査法人が、監査関連のメモやプレゼンテーションの初稿の作成と、社内ガイダンスのリサーチに生成AIを使っていると述べ、監査調書が文書化要件に照らして完全かを確認するなど、法人が将来の候補とみなす分野を挙げています。同じ報告の中で、データのプライバシーと信頼性への懸念から、監査や証明の手続には生成AIを認めていない法人もありました。監査を控えた企業であれば、監査人の方針を確認してください。何をどのように渡せるかに影響するためです。

FP&AとExcel。 ルックアップの数式を書かせる、引き継いだマクロを説明させる、入れ子のIFを読みやすいものに変換させるといった使い方は、結果をすぐにテストできるため、最も安全な用途の1つです。リスクは、取締役会向け資料の元になるモデルに、未検証の数式を出荷してしまうことです。

機密保持:プロンプトに何を入れるか

プロンプトは開示行為です。AICPAの倫理ガイダンスは、公開AIツールが利用者の入力を将来のモデルの学習に使う場合があり、入力したデータが別の場所で再び現れる可能性があること、また、会計事務所に所属する会員は、守秘義務規則(Confidential Client Information Rule)のもとで、顧客データを入力する前に、その情報が機密かどうか、同意が必要かどうかを検討すべきであることを指摘しています。CPAのリスク管理ディレクターによるJournal of Accountancyの記事は、事務所が顧客と事務所の機密情報や専有情報を生成AIツールに入力することを禁止し、スタッフが入力を公開サイトへの投稿と同じように扱うことを推奨しています(Journal of Accountancy, October 2023)。

承認された入口にある封をした機密封筒で示す、会計AIのデータ機密保持

事業会社の財務チームにとって、同等の懸念は未発表の業績、M&A情報、給与データ、顧客との契約です。実務上のルールは、どのデータの種類をどの承認済みツールに入力してよいかを文書で決め、承認済みのツールを使いやすい道にすることです。承認された選択肢が遅いと、人は開いているものに何でも貼り付けてしまいます。

会計チームに生成AIを導入する方法

  1. まず業務の棚卸しから始めます。 主に書く、または説明する定期的な業務、つまりメモ、コメント、メール、文書化、数式の支援を一覧にします。件数と、出力の確認のしやすさで順位づけします。

    下書き、レビュー、責任者の最終承認の各デスクで示す、下書き・検証・最終承認

  2. 承認済みのツールを選び、データのルールを書きます。 許可するツール、入力してよいデータの種類、例外を決める人を明記します。ベンダーのデータ条件は、法務またはITと一緒にレビューします。データがこの用途に向けて整理されていない場合は、先にAIに向けた財務データの準備に取り組んでください。

  3. 業務ごとに確認を定めます。 上の表をテンプレートとして使います。用途ごとに、誰が何を検証するのかを書きます。数字は原資料と突き合わせ、引用は基準の中で見つけ、結論は名前の挙がった担当者が責任を持ちます。

  4. 責任者を明確にしたままにします。 AICPAは、責任が専門家に残ることを明確にしています。ヒューマン・イン・ザ・ループのステップを、方針だけでなく、ワークフローと最終承認の中に組み込んでください。

  5. 1つのプロセスで、1回の決算サイクル分のパイロットを実施します。 差異コメントかメモの下書きを選びます。下書きにかかる時間の短縮、レビューで見つかった修正、作成者に気づかれないままレビュー担当者に届いた誤りを測定します。

  6. AIの使用をどう記録するか決めます。 AIが作業に寄与した場合は、レビュー担当者がより注意深く見られるように、スタッフに開示を求める事務所もあります。監査調書に、ツール、入力、レビューを記録するかどうかを決めてください。

  7. 懐疑心を養う訓練をします。 ICAEWは、職業的懐疑心を主な安全策として推奨し、同じ質問を繰り返して回答が変わるかを確認することを提案しています。レビュー担当者には、出力を、自信たっぷりだが経験の浅い同僚の仕事のように扱うよう教えてください。

  8. 四半期ごとに見直します。 ツール、ベンダーの条件、専門家向けのガイダンスは変わります。承認済みのツールと確認方法を、定期的に見直してください。

よくある落とし穴

  • 正しそうに見えるから引用を信用します。 偽の参考文献は、記録されている失敗です。メモに入れる前に、基準の中でその条文を見つけてください。
  • モデルに合計を任せます。 計算過程を示していても、再計算してください。誤った合計についての流暢な説明は、やはり誤りです。
  • レビューにおけるオートメーションバイアス。 AIが下書きした文章は、よく書けているために、レビュー担当者が批判的に読まなくなります。ICAEWはオートメーションバイアスを明確に挙げています。レビュー担当者には、校正ではなく検証を割り当ててください。
  • 行っていない作業を文書化します。 ウォークスルーの説明文の下書きを頼まれたモデルは、もっともらしい手続を記述します。チームが実際に行ったことと違えば、その監査調書は誤解を招きます。
  • 承認されていないツールです。 スタッフが顧客や会社のデータに個人アカウントを使うのは、機密保持の違反が起きるのを待っているようなものです。公認の選択肢を提供してください。
  • データのルールを飛ばします。 「注意してください」という方針は機能しません。データの種類と承認済みツールを具体的に定めてください。
  • レビュー担当者にAIの使用を隠します。 あるセクションが機械で下書きされたことをレビュー担当者が知らなければ、精査の度合いを調整できません。

次に読む記事

どのチームメンバーが検証とプロンプト基準の責任を持つかを決める場合は、AIと財務チームの役割をお読みください。パイロットを選ぶ前に部門全体を整理したい場合は、AIの財務ユースケースが価値とリスクで分類しています。そして今四半期に1つだけ行うなら、1ページのルールを書いてください。承認済みのツール、許可するデータ、数字を検証する担当者の氏名です。ルールができたら、「下書き、検証、最終承認」の流れを、非公式な習慣のままにせず、承認ステップを伴う担当タスクとして、ReworkのBPMのようなプロセスツールに置いてください。

About the author

JH

Jane Ha

Head of Finance Strategy

Jane Ha is Head of Finance Strategy at Rework, helping CFOs and finance leaders turn strategy into numbers their boards trust. With 5+ years in SaaS finance and FP&A advising 50+ B2B companies, Jane shows readers how to read their own unit economics honestly, plan cash flow with confidence, and focus on the SaaS metrics that move enterprise value.