結論: AIを既存業務に差し込むのではなく、AIが標準工程に組み込まれた前提で業務フローをゼロから組み直す。月次決算・面談準備・申告書作成の3工程は、人が起点の設計とAIが起点の設計で、工程数も役割分担も別物になります。
士業事務所でAI活用が話題になるとき、多くの場合『どの業務にAIを入れるか』という議論から始まります。仕訳入力にAIを使う、議事録の文字起こしにAIを使う、契約書のチェックに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 整合性検証 → AI 異常値抽出 → 担当者の解釈 → 顧問先向け報告書生成 → 担当者の最終確認』 に組み替わります。
ポイントは2つです。1つは、担当者が手を動かす工程が『解釈』 と『最終確認』 の2つに集約されること。もう1つは、報告書のフォーマットが『試算表の数字を並べる』 から『顧問先が知りたいことに直接答える』 に変わることです。
この設計の難しさは、AI の精度ではなく『顧問先が何を知りたいか』 を事務所として言語化できているかにかかっています。言語化されていなければ、AI に指示も出せません。
顧問先面談準備工程の再設計
顧問先面談の準備も、AI 前提でゼロから組み直せます。
人起点の設計では、担当者が試算表を眺め、過去の議事録を読み返し、顧問先業界のニュースを検索し、想定質問を考え、資料を準備します。所要時間は1件あたり1〜2時間が一般的です。
AI 前提の設計では、起点に『この面談で顧問先が次に取るべき行動は何か』 を置きます。面談の目的を『情報共有』 から『次の行動の合意形成』 に再定義します。
工程は『試算表データ + 過去議事録 + 業界ニュース を AI に入力 → AI が論点候補を抽出 → 担当者が論点を選定 → AI が論点ごとに想定問答を生成 → 担当者が問答を編集 → 面談実施』 になります。
担当者の仕事は『資料を集めて読む』 から『論点を選定し、問答を編集する』 に変わります。読む対象は資料ではなく、AI が抽出した論点候補です。
この設計でも、難しさは AI の精度ではなく『論点とは何か』 『この顧問先にとっての次の行動とは何か』 を担当者が判断できる経験値にあります。AI は論点候補を出せますが、選定する目を持つのは担当者です。
申告書作成工程の再設計
申告書作成は、最も AI 前提の再設計が効きやすい工程です。
人起点の設計では、月次決算の積み上げ → 年次決算 → 申告書下書き → 内部レビュー → 顧問先確認 → 提出、という流れになります。各工程で担当者がデータを集計し、申告書ソフトに入力し、整合性を確認します。
AI 前提の設計では、月次決算の段階で『申告書作成に必要なデータ項目』 を AI が継続的に整理しておきます。年次決算の段階では、申告書下書きが半自動で生成される状態を目指します。
工程は『月次の AI データ整理 → 年次の AI 申告書下書き → 担当者の論点確認 → AI 整合性検証 → 顧問先確認 → 提出』 になります。
担当者の仕事は『申告書を作成する』 から『論点を確認し、整合性を検証する』 に変わります。論点とは、例えば特定の控除適用の妥当性、税務調査リスクのある処理、過年度との一貫性、といった判断を要する部分です。
この設計の前提として、月次決算の段階から AI を組み込んでおく必要があります。年次の段階で初めて AI を入れても、データの整理状態が追いつかず、効果が薄くなります。
ゼロから設計するために事務所が用意するもの
3工程の再設計を見てきました。共通しているのは、AI を入れる前に事務所として言語化が必要な要素がある、という点です。
月次決算なら『顧問先が何を知りたいか』、面談準備なら『論点とは何か』、申告書作成なら『判断を要する論点はどこか』。これらは AI が答えを出せる領域ではなく、事務所の方針として定義する領域です。
つまり、AI 前提の業務設計は、AI ツール選定の問題ではなく、事務所の業務方針を言語化する問題です。言語化されていれば、AI ツールが何であっても設計は機能します。言語化されていなければ、どんな高性能な AI を入れても、業務フローは変わりません。
この順序を逆にすると、AI 導入の試行錯誤が長引きます。先に PoC を走らせて『どの AI が使えるか』 を探すよりも、先に『この事務所の業務方針は何か』 を言語化したほうが、結果的に早く目的地に着けます。
業務方針の言語化は、関連記事『FDE モデルで考える士業事務所のAI導入』 や『PoC 失敗の3パターン』 の文脈とも繋がります。AI 前提の設計と、AI 導入の進め方は、両輪で考える必要があります。