2026年9月1日訂正: 初版には、面談準備の一般的な所要時間、部分導入の効果、申告書作成への適合性を、調査・実装・試験の裏付けなく断定した記述がありました。これらを撤回します。以下は、月次決算・面談準備・申告書作成を題材にした思考実験であり、実装済み・効果検証済みの業務フローではありません。
AIを既存工程の一部へ追加する案と、工程全体を見直す案では、確認すべき範囲が異なります。本記事では後者の考え方を検討します。
しかし、この『入れる』という発想自体が、業務フローを根本から変えることを難しくしている、というのが本記事の主張です。既存の工程を前提に『どこにAIを差し込むか』を考えると、AIは既存工程の補助役にしかなりません。結果として、削減できる時間も、得られる質的変化も限定的になります。
この記事では、AIが標準工程に組み込まれた前提で業務フローをゼロから組み直す思考法を、月次決算・顧問先面談準備・申告書作成の3工程を例に整理します。
なぜ『AIを入れる』 では業務が変わらないのか
既存業務にAIを差し込む発想では、工程の順序も役割分担も変わりません。たとえば月次決算の工程が『資料受領 → 仕訳入力 → チェック → 試算表作成 → 担当者レビュー → 顧問先共有』という6工程で組まれていたとします。
ここに『仕訳入力をAIで自動化する』と差し込んでも、工程の数は6のままです。仕訳入力の所要時間が減るだけで、チェックも、試算表作成も、レビューも、共有も、人が起点で動きます。
さらに困ったことに、AIが介在する工程が増えるほど、人がやるべき確認作業も増えます。AIの出力を信頼するためには、入力データの正しさ・出力の整合性・例外パターンの検知、といった『AIを使うために増えた仕事』 が発生します。
部分導入で業務全体の負荷が減るかは、対象工程、後工程のレビュー、例外処理、連携作業を含めて測らなければ判断できません。
AI前提でゼロから設計するとはどういうことか
発想を切り替えます。『AIが標準工程に組み込まれている前提で、もし今この事務所をゼロから立ち上げるなら、業務フローをどう組むか』 を考えます。
この問いに答えるとき、起点になるのは『人が判断すべき意思決定ポイントはどこか』 です。AIが処理できる作業ではなく、人の判断が価値を生む場面を先に特定します。
月次決算の思考実験では、『この仕訳パターンが顧問先の経営判断にどう影響するか』という解釈を人の判断点として置きます。ただし、AIが仕訳の正しさを保証できるわけではありません。資料との照合、ルールによる検算、例外処理、有資格者の確認を別工程として設計します。
この起点を据えると、工程の順序が変わります。人が起点だった『資料受領 → 仕訳入力 → チェック』 の順序は、AI起点の設計では『資料受領 → AI仕訳生成 → AI整合性検証 → 例外パターン抽出 → 担当者は例外のみ判断』 に変わります。
担当者の仕事は『仕訳を入力する』 ではなく『AIが抽出した例外パターンを解釈する』 になります。同じ月次決算でも、担当者がやっていることは別物です。
月次決算工程の再設計
具体的に、月次決算の再設計を整理します。
人起点の設計では、工程は『資料受領・仕訳入力・チェック・試算表作成・レビュー・共有』 の順で進みます。各工程で担当者が手を動かし、レビュー段階で誤りを発見すると前工程に戻ります。
AI前提の設計では、起点に『顧問先が何を知りたいか』 を置きます。前月比の異常値か、特定勘定科目の推移か、キャッシュフローの傾向か、を先に明確にします。
そのうえで、工程は『資料受領 → AI仕訳生成 → AI整合性検証 → AI異常値抽出 → 担当者の解釈 → 顧問先向け報告書生成 → 担当者の最終確認』 に組み替わります。
ポイントは2つです。1つは、担当者が手を動かす工程が『解釈』 と『最終確認』 の2つに集約されること。もう1つは、報告書のフォーマットが『試算表の数字を並べる』 から『顧問先が知りたいことに直接答える』 に変わることです。
この設計の難しさは、AIの精度ではなく『顧問先が何を知りたいか』 を事務所として言語化できているかにかかっています。言語化されていなければ、AIに指示も出せません。
顧問先面談準備工程の再設計
顧問先面談の準備も、AI前提でゼロから組み直せます。
人起点の設計例では、担当者が試算表を読み、過去の議事録や業界情報を確認し、想定質問と資料を準備します。所要時間は事務所・案件ごとに異なり、本記事には一般値を示せる測定記録はありません。
AI前提の設計では、起点に『この面談で顧問先が次に取るべき行動は何か』 を置きます。面談の目的を『情報共有』 から『次の行動の合意形成』 に再定義します。
工程は『試算表データ + 過去議事録 + 業界ニュース をAIに入力 → AIが論点候補を抽出 → 担当者が論点を選定 → AIが論点ごとに想定問答を生成 → 担当者が問答を編集 → 面談実施』 になります。
担当者の仕事は『資料を集めて読む』 から『論点を選定し、問答を編集する』 に変わります。読む対象は資料ではなく、AIが抽出した論点候補です。
この設計でも、難しさはAIの精度ではなく『論点とは何か』 『この顧問先にとっての次の行動とは何か』 を担当者が判断できる経験値にあります。AIは論点候補を出せますが、選定する目を持つのは担当者です。
申告書作成工程の再設計
申告書作成は誤りの影響が大きいため、AIを含む再設計では慎重な検証が必要な工程です。
人起点の設計では、月次決算の積み上げ → 年次決算 → 申告書下書き → 内部レビュー → 顧問先確認 → 提出、という流れになります。各工程で担当者がデータを集計し、申告書ソフトに入力し、整合性を確認します。
仮想設計では、月次決算の段階から申告書作成に必要なデータ項目を整理し、年次に参照できる状態を検討します。AIに整理や下書きを補助させる場合も、入力の完全性、税制改正、顧問先固有事情、計算結果を別経路で検証します。
工程は『月次のAIデータ整理 → 年次のAI申告書下書き → 担当者の論点確認 → AI整合性検証 → 顧問先確認 → 提出』 になります。
担当者の仕事は『申告書を作成する』 から『論点を確認し、整合性を検証する』 に変わります。論点とは、例えば特定の控除適用の妥当性、税務調査リスクのある処理、過年度との一貫性、といった判断を要する部分です。
この設計の前提として、月次決算の段階からAIを組み込んでおく必要があります。年次の段階で初めてAIを入れても、データの整理状態が追いつかず、効果が薄くなります。
ゼロから設計するために事務所が用意するもの
3工程の再設計を見てきました。共通しているのは、AIを入れる前に事務所として言語化が必要な要素がある、という点です。
月次決算なら『顧問先が何を知りたいか』、面談準備なら『論点とは何か』、申告書作成なら『判断を要する論点はどこか』。これらはAIが答えを出せる領域ではなく、事務所の方針として定義する領域です。
つまり、AI前提の業務設計は、AIツール選定の問題ではなく、事務所の業務方針を言語化する問題です。言語化されていれば、AIツールが何であっても設計は機能します。言語化されていなければ、どんな高性能なAIを入れても、業務フローは変わりません。
業務方針を先に言語化する案と、限定的なPoCから要件を発見する案には、それぞれ利点があります。自所では対象業務、試験期間、測定項目、停止条件を決め、どちらが適するか比較します。
業務方針の言語化は、関連記事『FDEモデルで考える士業事務所のAI導入』 や『PoC失敗の3パターン』 の文脈とも繋がります。AI前提の設計と、AI導入の進め方は、両輪で考える必要があります。