AIが会計データを誤解して残高を計算した：取引状況から、その結果を再評価する
YouTube:9:35
「構造化CSVでつなぐ Ledger Explorer 改定記」続報
Ledger Explorerの売掛金・買掛金管理画面を作成した際、私は生成AIに、年間を通じて取引先別残高が負にならないよう、テスト用の開始残高を計算させました。
記事『残高だけでは分からない：売掛金・買掛金から背景の仕訳をたどる』
AIは、各月末の残高が負にならないために必要な金額を、年間仕訳から逆算しました。その結果、画面上では取引先別残高が負にならず、科目合計とも一致するデータを作ることができました。
しかし今回、売上債権回転日数、仕入債務回転日数、棚卸資産回転日数及びキャッシュ・コンバージョン・サイクルという視点から再評価すると、その開始残高は取引規模に対して不自然に大きいことが分かりました。
AIは、「残高を負にしない」という指示には応答していました。しかし、そのために計算した金額を、年度開始時点に実在した債権・債務であるかのように扱ってしまいました。
年間のどの月にも負残高が生じないよう、将来12か月の取引から逆算した金額は、画面検証のための値にはなっても、適切な開始残高を示すものではありません。AIも私も、この違いを十分に区別せず、計算結果の整合性を優先してしまったのです。
今回は、この誤解に基づいて計算した開始残高を、年間の取引状況と回転日数から再評価します。
さらに、取引先別残高を改めて検証する過程で、仕訳日記帳から総勘定元帳を生成する処理にも問題があることが分かりました。
これは、「AIが誤ったから使えない」という話ではありません。
AIによる最初の計算を、別の会計的視点から再検証し、その誤解を明らかにして、プログラム、テストデータ及び説明を修正した記録です。
AIは何を誤解していたのか
前回、AIに与えた主な条件は、売掛金と買掛金について、2021年4月から2022年3月までの各月末残高が正常残高と反対方向の負数にならないようにすることでした。
AIは、取引先ごとに年間の増減を計算し、最も残高が不足する月でも負数にならない開始残高を求めました。
計算方法そのものは、与えられた条件に対応しています。しかし、この値には、年度開始後に発生する将来の取引の影響も含まれます。
開始残高は、本来、年度開始時点ですでに存在していた資産又は負債です。
これに対してAIが計算したのは、将来12か月のすべての取引を処理しても、残高が負にならないための必要額でした。
つまり、AIは次の二つを同じものとして扱っていました。
画面上で負残高を発生させないための検証用金額。
年度開始時点に存在する合理的な開始残高。
これは計算式の誤りというより、計算対象の意味に関する誤解です。
貸借が一致し、取引先別合計と科目合計が一致していても、その開始残高が実際の取引規模や支払条件から説明できるとは限りません。
残高が負にならなければ正しいのか
年間のどの月にも負残高を発生させないという方法は、Ledger Explorerの画面や集計処理を検証するには有効です。
しかし、年間のすべての取引を見て開始残高を逆算すると、場合によっては将来の取引結果まで開始残高へ反映することになります。
その金額を使えば、表示上の不整合は解消できます。
一方で、それが企業の年度開始時点に実在した債権、債務、現金、預金又は棚卸資産を表しているとは限りません。
そこで今回は、「残高が負にならないか」という視点から離れ、年間の売上、仕入、在庫、回収及び支払との関係から開始残高を再評価しました。
そのために用いたのが、棚卸資産回転日数、売上債権回転日数、仕入債務回転日数及びキャッシュ・コンバージョン・サイクルです。
CCCから見えた不自然な取引状況
資金が仕入から販売、代金回収までの営業活動に拘束される期間は、キャッシュ・コンバージョン・サイクル、略してCCCで確認できます。
CCC ＝ DIO ＋ DSO − DPO
DIOは、棚卸資産回転日数です。
DSOは、売上債権回転日数です。
DPOは、仕入債務回転日数です。
前回の開始残高候補を使い、受取手形と支払手形も含めて計算すると、次の値になりました。
棚卸資産回転日数（DIO）：0.8日
売上債権回転日数（DSO）：71.7日
仕入債務回転日数（DPO）：222.2日
CCC：マイナス149.6日
※端数処理の関係で下1桁が一致しない場合があります
CCCがマイナスであることだけを見れば、仕入代金を支払うよりかなり早く売上代金を回収しており、運転資金の面で有利に見えます。
しかし、DPOが約222日というのは、支払まで7か月以上かかる計算です。
一方、DIOは1日にも達していません。
通常の在庫販売を想定したテストデータとしては、仕入債務が大きすぎ、棚卸資産が小さすぎます。
このCCCは、資金効率の良さを示すというより、開始残高又は取引先情報の処理を再確認すべきことを示す異常検知値でした。
支払サイト60日から買掛金を見直す
前回の買掛金開始残高は269,151,001円でした。
年間仕入高512,608,024円に対して約192日分に相当し、一般的な60日の支払サイトとは大きく離れています。
今回は、2021年4月と5月に実際に記録された買掛金の支払額を、年度開始前の仕入に対する60日以内の支払と考えました。その合計は89,117,567円です。
この値を買掛金開始残高とすると、期末残高は80,527,832円、期首・期末平均は約84,822,700円となり、買掛金だけによるDPOは約60.4日になります。
再評価前
買掛金開始残高：269,151,001円
買掛金期末残高：261,104,994円
買掛金平均残高：約265,128,000円
買掛金ベースのDPO：約188.8日
60日基準への見直し後
買掛金開始残高：89,117,567円
買掛金期末残高：80,527,832円
買掛金平均残高：約84,822,700円
買掛金ベースのDPO：約60.4日
ここで重要なのは、単に「60日だから年間仕入高の60日分」と置いたのではなく、サンプル仕訳に記録された4月・5月の支払実績を根拠にしたことです。
ただし、2021年2月・3月の仕入明細がないため、これは実在する債務を請求書単位で復元した値ではなく、テスト用の推計値です。
棚卸資産も回転日数60日で見直す
再評価前の平均棚卸資産は約115万円でした。年間売上原価512,595,704円に対する棚卸資産回転率は約444.5回、回転日数は約0.82日です。受注後に仕入先から顧客へ直接納品する業態であれば説明できる可能性はありますが、一般的な在庫販売を想定したサンプルとしては不自然です。
そこで、検証用の標準値として棚卸資産回転日数を60日としました。
平均棚卸資産
＝512,595,704円 × 60 ÷ 365
≒84,262,000円
年間の商品増減も考慮し、商品開始残高は84,256,000円としました。これにより、棚卸資産回転率は約6.1回、DIOは約60日となります。支払サイトと在庫保有期間は、本来は別の条件です。今回は特定企業の実態を再現するのではなく、年間取引との関係を検証しやすい標準的なサンプルを作るため、両方を60日としています。
取引先別に適用すると、再び負残高が発生した
買掛金89,117,567円を15社の仕入先別開始残高へ配分し、年間推移を計算すると、当初は73件の負残高が発生しました。科目合計として約60日分の買掛金を設定できても、取引先別では成立しなかったのです。ここで開始残高を再び増額すれば、画面上の負数は消せます。
しかし、それではDPOが長期化した原因や、取引先別残高の不整合を開始残高で覆い隠すことになります。
そこで、年間仕訳の仕入計上と支払を取引先別に追跡し、仕訳日記帳から総勘定元帳を生成する処理までさかのぼりました。
原因は仕訳明細と取引先情報の対応だった
調査の結果、元の仕訳日記帳では、消費税額は仕入と同じ明細行の税額項目に記録され、買掛金側の仕入先コードも同じ明細に正しく記録されていました。問題は、仕訳日記帳から生成した総勘定元帳で、買掛金の各計上額と、その明細が持つ仕入先コードとの対応が正しく保持されていなかったことにありました。
構造化CSVでは、仕入先情報は伝票の先頭行から後続行へ複写するのではなく、伝票番号と明細行番号で識別される各仕訳明細に属しています。したがって、元帳を生成するときも、買掛金側の金額と仕入先コードを、同じ明細の情報として保持する必要があります。
これは、消費税の内税計算や複合仕訳の問題ではありません。仕訳明細から元帳へ取引先情報を引き継ぐ方法の問題でした。
「推測した相手先」ではなく、仕訳明細自身の取引先を保持する
修正後は、伝票番号と明細行番号を基に、買掛金側に記録された仕入先コードと名称を同じ仕訳明細へ結合し、そのまま総勘定元帳へ引き継ぐようにしました。
処理上の原則は、次の二つです。
元帳科目自身の補助科目・取引先情報は、同じ仕訳明細から取得する。
伝票番号だけでなく明細行番号も用いて、金額と取引先情報を対応付ける。
この修正によって、会計金額だけでなく、「どの仕入先に対する買掛金か」という意味を、仕訳日記帳から元帳へ正しく引き継げるようになりました。
修正後の検証結果
取引先情報の対応を修正し、買掛金開始残高89,117,567円と商品開始残高84,256,000円を適用した結果、15社すべてについて、年間を通じた買掛金の負残高は0件になりました。開始残高の貸借を一致させるため、現金及び預金は53,375,078円に調整しています。当期売上高や利益科目を開始残高の調整には使用していません。
買掛金開始残高： 89,117,567円
商品開始残高： 84,256,000円
現金及び預金開始残高：53,375,078円
買掛金期末残高： 80,527,832円
対象仕入先：15社
取引先別負残高：0件
開始残高の貸借差額：0円
取引先別合計と科目合計の差：全24区分月で0円
リリース検証：73項目すべて成功
さらに、日本語版と英語版の行構造、ID及び金額が一致すること、12か月すべての試算表で貸借が一致すること、取引先別合計と買掛金元帳残高が一致することも確認しました。
見直し後のCCCをどう評価するか
買掛金と棚卸資産を60日基準へ見直すと、買掛金だけを仕入債務として計算したCCCは、おおむね次の関係になります。
60.0日 ＋ 71.7日 − 60.4日 ≒ 71.3日
支払手形も含めればDPOはさらに長くなり、CCCは短くなります。これは、「買掛金60日」に加えて、手形による支払期間の延長があるためです。したがって、見直し後のデータは、従来の約マイナス150日という極端なCCCから、在庫を保有し、販売後に代金を回収し、買掛金又は手形で支払う事業の姿に近づきました。ただし、今回の60日は、テストデータを評価するための仮定です。
業種、取引条件、季節変動、手形の決済期日によって、適正なDIO、DSO及びDPOは異なります。実際の企業を評価する場合は、請求書、検収日、支払期日、入出金及び消込の記録に基づいて計算する必要があります。
別の視点をAIへ与えることで、最初の誤解を発見できた
今回、最初にAIへ与えた課題は、「年間を通じて残高を負にしないこと」でした。その条件だけを見れば、AIが計算した開始残高は目的を満たしていました。しかし、そこへDIO、DSO、DPO及びCCCという別の視点を加えると、DPO約222日、DIO約0.8日という不自然な取引状況が見えてきました。
AIは、自分が先に計算した結果を当然の前提として守ったわけではありません。新しい評価条件を与えることで、その結果を再計算し、不自然さを指摘し、原因をさらに調査することができました。その過程では、AI自身も、内税計算、複合仕訳、先頭行からの取引先情報の複写など、実際のデータには当てはまらない原因を一時的に推測しました。しかし、元の仕訳データ、構造化CSV及びプログラムの処理を照合することで、それらの推測を順番に訂正しました。
最終的には、消費税額と仕入先コードは同じ仕訳明細に記録されており、問題は仕訳明細から元帳へ取引先情報を引き継ぐ処理にあることを確認しました。
この経過は、生成AIの回答を一度得ただけで正解とみなしてはいけないことを示しています。同時に、異なる観点から問い直し、元データとプログラムへ戻って検証できれば、AIが最初に行った計算や推測も訂正できることを示しています。
経営指標は、結果の評価だけでなくデータ検査にも使える
今回の作業では、CCCを算出したことで、開始残高の不自然さが見つかりました。さらに、60日という取引条件を取引先別データへ適用したところ、負残高が再発し、仕訳明細から元帳へ取引先情報を引き継ぐ処理の不具合まで発見できました。つまり、経営指標は、完成した財務諸表を評価するためだけのものではありません。
取引規模と開始残高は釣り合っているか。
回収期間と支払期間は取引条件に合っているか。
在庫残高は売上原価に対して不自然ではないか。
科目合計と取引先別明細は同じ動きをしているか。
仕訳から元帳へ取引先の意味が正しく引き継がれているか。
こうした問いをデータへ返すことで、入力値、変換処理及び集計結果の不具合を検出できます。
この水準の検証は、監査支援に使えるか
今回行ったのは、単なる集計や比率計算ではありません。年間取引と開始残高の関係を評価し、DIO、DSO、DPO及びCCCから異常値を検出し、その原因を科目別、取引先別、仕訳明細別に掘り下げました。さらに、元帳生成処理の不具合を特定し、修正後の残高を再計算して、補助簿と科目合計の一致まで確認しています。
これは、監査で行われる次のような作業を支援するものです。
分析的手続：
回転率、回転日数及びCCCから不自然な残高を検出する。
期首残高の検討：
年間取引、支払実績及び想定する取引条件から開始残高を再評価する。
補助簿との照合：
取引先別残高の合計と買掛金元帳残高を照合する。
異常項目の抽出：
極端に長いDPO及び取引先別の負残高を抽出する。
データ処理の検証：
仕訳明細から元帳を生成する際の取引先情報の対応を検査する。
再計算：
修正後の月次・年次残高、試算表及び財務指標を再生成する。
網羅性・整合性の確認：
12か月、15社及び日英データを横断して検証する。
特に重要なのは、「CCCがマイナスだから資金効率が良い」と表面的に結論づけず、その構成要素であるDPO約222日とDIO約0.8日の不自然さから、開始残高を疑ったことです。そして、60日という取引条件を仮定して再計算した結果、取引先別の負残高が73件発生したため、データをさらにさかのぼり、仕訳明細と元帳の取引先情報の対応に関する不具合を発見しました。
このように、Ledger Explorerと生成AIを組み合わせれば、仕訳、元帳、取引先別残高及び財務指標を横断的に検査し、監査人が確認すべき異常値やデータ処理上の問題を絞り込むことができます。分析的手続、再計算、補助簿照合及び監査対象の抽出を支援する仕組みとしては、実用化を検討できる水準です。
ただし、これは監査人の判断そのものを代替するものではありません。例えば、次の事項は帳簿データの分析だけでは確定できません。
支払サイト60日という仮定が、実際の契約条件と一致するか。
計上された棚卸資産が実在し、適切に評価されているか。
売掛金及び買掛金の残高が、取引先の記録と一致するか。
請求書や納品記録などの証憑が真正で、取引が実在するか。
会計処理が、適用される会計基準に準拠しているか。
発見した誤りが、財務諸表又は監査意見へどのような影響を与えるか。
したがって、現段階での位置付けは、AIによる自動監査ではありません。監査人が確認すべき対象をデータ全体から発見し、関連する仕訳や残高へ案内する監査支援です。今後、仕訳から請求書、注文書、出荷・受領記録、支払・入金記録及び消込記録まで共通IDで追跡できるようになれば、異常値の検出から関連証憑の提示までを一続きに行えるようになります。
今回の事例は、そのような監査支援システムへ発展できる可能性を、具体的なデータと修正結果によって示したものです。
AIに計算させるだけでなく、AIの計算を再評価する
今回の改定は、AIが正しい開始残高を最初から提示したという事例ではありません。むしろ、AIが会計データの意味を十分に区別しないまま、「残高を負にしない」という条件に合わせて開始残高を計算してしまった事例です。しかも、その結果は、貸借が一致し、取引先別残高も負にならず、画面上では正常に見えていました。このため、数値の整合性だけを検証していれば、誤解に気付かなかった可能性があります。
今回、回転日数とCCCという別の会計的視点から再評価したことで、初めて開始残高の不自然さが明らかになりました。さらに取引先別に再計算することで、仕訳明細から元帳へ取引先情報を引き継ぐ処理上の問題も見つかりました。重要なのは、AIの回答を採用するか否かという二者択一ではありません。AIに計算させ、その結果を別の視点からAI自身にも再評価させ、元データ、プログラム及び会計上の意味へ戻って確かめることです。
構造化CSVとして、勘定科目、取引先、金額、日付、伝票番号及び明細行番号を意味とともに保持していたため、集計結果から取引先別残高へ、さらに元の仕訳明細へさかのぼることができました。
生成AIは、誤解することがあります。しかし、検証可能なデータと複数の評価視点を与えれば、その誤解を発見し、訂正し、プログラムやテストデータの改善へつなげることもできます。
今回の記事は、AIが正解を出した成功例ではありません。AIと人間が誤解を再検証しながら、より妥当な結果へ近づいていく過程の記録です。
「数字が合う」から「取引状況を説明できる」へ
貸借が一致し、月末残高が負にならず、画面に数字が表示されても、それだけでデータが妥当とは限りません。今回の改定で重視したのは、残高を合わせることではなく、その残高が年間の売上、仕入、在庫、回収及び支払という取引状況から説明できることです。
今後、請求書、注文書、出荷・受領記録、支払・入金記録及び消込記録まで共通IDで結べば、回転日数の異常から、どの請求又は支払が原因なのかをたどれるようになります。Ledger Explorerを、財務諸表を表示するだけの仕組みではなく、取引状況から会計データの妥当性を継続的に検証できる環境へ改定していきたいと考えています。
AIが新人より有効に働くとき、新人はどこで経験を積むのか
今回のように、年間の仕訳を集計し、取引先別残高を再計算し、DIO、DSO、DPO及びCCCから異常値を検出し、その原因を元の仕訳明細やプログラムまでさかのぼって調べる作業では、AIは新人より有効に働く場合があります。新人に同じ作業を任せるには、会計処理、データ構造及びプログラムの動作を段階的に説明し、途中の計算や判断を確認する必要があります。AIであれば、指示に応じて大量のデータを処理し、仮説の提示、再計算及び再検証を短時間で繰り返せます。
ただし、今回の事例は、AIの方が新人より正しいことを示したものではありません。AIも開始残高の意味を誤解し、調査の途中では、内税計算、複合仕訳、先頭行からの取引先情報の複写など、実際のデータには当てはまらない原因を推測しました。それでもAIが有効だったのは、人間が別の評価視点を与え、元データとプログラムへ戻って検証し、その誤解を訂正させることができたからです。
ここで、新たな問題が生じます。従来、新人は、集計、照合、異常値の調査、元帳から仕訳へのさかのぼりといった仕事を通じて、会計データの構造や取引の流れを学んできました。効率だけを優先して、これらの基礎的な作業をすべてAIへ任せれば、新人は完成した結果だけを見ることになります。その結果、「なぜこの数字を疑うのか」「次にどの資料へ戻るのか」「数字は合っているが、取引の意味としてはおかしいとはどういうことか」を経験する機会が失われる可能性があります。
AIの出力を適切に評価できる人を育てるには、本来、AIへ任せようとしている作業について、人間自身も一定の経験を積む必要があります。
つまり、次のような循環が生じます。
AIを使えば、経験者は新人より速く仕事を進められる。
しかし、新人に仕事を経験させなければ、将来、AIを適切に監督できる経験者が育たない。
AIを単に新人の代替として導入すれば、短期的には効率が上がっても、長期的には組織の判断能力を弱めるおそれがあります。そのため、AI時代の新人教育では、単純作業をそのまま残すのではなく、AIと新人の役割を組み替える必要があります。
例えば、今回の事例であれば、集計や再計算はAIに実行させながら、新人には次のような問いを考えさせることができます。
DPO約222日、DIO約0.8日という値は、どのような業態なら成立するのか。
貸借や科目合計が一致しているのに、なぜ開始残高を疑う必要があるのか。
AIが提示した複数の原因仮説を、どのデータによって検証又は反証するのか。
AIの説明に含まれる事実、計算結果及び推測を、どのように区別するのか。
修正後の結果を妥当と判断するには、どの証拠を確認する必要があるのか。
手作業による集計だけが、教育ではありません。AIに計算させたうえで、その前提を確認し、結果を別の観点から疑い、元データによって反証し、会計上の意味を説明する経験も、新しい実務教育になり得ます。
AIは、新人より速く、大量のデータを横断して検査できます。しかし、AIを使うことで新人の仕事をなくしてしまえば、将来、そのAIの誤解を発見できる人材も育たなくなります。AI時代の新人教育では、作業を覚えさせるだけでなく、AIが提示した仮説を検証し、誤りを説明し、最終的な判断に責任を持つ経験を、意識的に設計する必要があります。
AIは、新人を育てなくてもよい理由ではありません。むしろ、新人に何を経験させ、どのように将来の判断者を育てるのかを、改めて考える契機だと思います。
関連リンク
no+eマガジン「構造化CSVでつなぐ LedgerExplorer 改定記」
Ledger Explorer
PCA会計の仕訳日記帳を構造化CSVへ変換し、月次試算表、総勘定元帳、貸借対照表、損益計算書及び取引先別残高をブラウザーで確認できる検証用ツールです。仕訳から集計結果へ進むだけでなく、財務指標や残高から元の仕訳明細へさかのぼり、会計データと変換・集計処理の妥当性を検証することを目指しています。
https://www.sambuichi.jp/ledger/?view=tidy&month=2021-04&lang=ja
GitHub
Ledger Explorerのソースコード、構造化CSVのサンプルデータ、変換・集計処理及び検証用ファイルを公開しています。ブラウザーで動作する画面だけでなく、仕訳日記帳から総勘定元帳や財務諸表を生成する処理、取引先情報を仕訳明細から引き継ぐ仕組み、テスト方法及び改定履歴を確認できます。
本記事はChatGPTで構成・執筆し、Ledger Explorerの実装、データ再生成及び検証はChatGPT Codexとの共同作業で行っています。内容は三分一技術士事務所が確認しています。
