会計事務所のAIエージェント比較とは、権限と検証工程を比べる作業のことです。

製品名を横に並べた比較表は、作った翌月にはたいてい古くなっています。会計事務所が先に決めるのは、どの製品を見るかではなく、どの条件を満たさない製品を落とすかです。この記事では、会計事務所がAIエージェントを比べるときの7つの軸、業務ごとに軸の重みがどう変わるか、比較検討の進め方までを整理します。本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、行政の見解は各府省庁の公表資料で確認しています。監査の領域では、日本公認会計士協会がテクノロジー委員会研究文書第11号を2024年8月13日に公表し、監査で利用されるAIについての理解を更新する目的を掲げています。

チャット型AIとエージェントでは比べる対象がずれる

比較の前提として揃えておくのは、目の前の製品がチャット型なのかエージェントなのかという区別です。AIエージェントとは、目的を渡すと自分でツールを選び実行する仕組みのことです。チャット型は文章を返すところで止まり、その先は人が動きます。エージェントは返ってきた結果を見て次のツールを呼び、会計システムや共有フォルダに副作用を残します。

Anthropicの技術記事は、あらかじめ決めたコードパスでモデルとツールを動かすワークフローと、モデル自身が手順とツール利用を決めるエージェントを、設計上の区別として扱っています。同記事は実装の原則として、設計を単純に保つこと、計画のステップを明示して透明性を優先すること、ツールの説明文と挙動をていねいに作り込むことの3点を挙げています。会計事務所の比較検討でも、この3点はそのまま質問項目になります。

比較の場面で困るのは、製品側が使う言葉が揃っていないことです。チャット画面に検索機能を足しただけの製品も、会計システムへの書き込みまで行う製品も、同じくエージェントという名前で売られています。デモの冒頭で、この製品は人が結果を受け取る形なのか、製品側が実行まで進む形なのかを聞いて、その場で分類しておくと、以降の質問がかみ合います。

この区別が効いてくるのは、評価対象が変わるからです。チャット型なら出力の質を見れば足ります。エージェントは、出力が良いかどうかに加えて、どこまでを自分で実行し、どこで人に返し、失敗したときに何が残るかを見ることになります。同じ「AI導入」という言葉でも、検討の中身は別物です。チャット利用とエージェント利用の線引きは、士業のAIエージェント業務活用で工程の割り方から整理しています。

会計事務所がAIエージェントを比べる7つの軸

7つの軸は、上から順に重いわけではありません。どれか1つでも事務所の運用に合わないと、残り6つが良くても導入が止まる、という並びです。

軸1 入力データの取り扱い

見るのは3点です。入力がモデルの学習に使われるか、どこに保存され何日残るか、ベンダー側の担当者が閲覧しうる経路があるかです。会計事務所が投入するのは顧問先の総勘定元帳、証憑、給与データで、個人データを含みます。個人情報保護委員会は生成AIサービスの利用に関する注意喚起を2023年6月2日に公表し、個人情報を含むプロンプトの入力が特定した利用目的の達成に必要な範囲内かを確認するよう求めています。

ここで見落としやすいのは、契約書の条項と管理画面の設定を両方見ることです。約款で学習利用の除外が定められていても、既定の設定が有効化されていない製品はあります。逆に設定を切っても、接続先の第三者サービス側で扱いが変わることもあります。入力の扱いをめぐる整理は顧客情報を生成AIに入力するリスクと対策に詳しく書いています。

軸2 権限と実行範囲

製品を、読み取りだけ、下書きの作成まで、登録や送信まで、の3段階に割り付けます。同じ製品でも設定で段階を変えられるものと、全権限で動くことを前提にしたものがあります。

Model Context Protocolのセキュリティ文書は、権限の最小化について、まず低リスクの読み取り操作だけを含む最小の権限セットから始め、特権的な操作が試みられた時点で段階的に権限を上げていく設計を示しています。会計事務所の比較では、この段階分けを製品側の機能として持っているかが分かれ目になります。持っていない場合、事務所は接続先のAPIキーの権限で絞ることになり、会計システム側が全権限のキーしか発行できないと打ち手がなくなります。

もう1つ、どの権限で動くのかも見ます。事務所の共有アカウントで動かすのか、担当者個人の権限で動かすのかで、後述するログの意味が変わります。

軸3 監査ログ

残すべき項目は、いつ、誰の権限で、どのツールを、どの引数で呼び、何が返り、人がどこで承認したか、です。エージェントは1つの依頼で何十回もツールを呼ぶので、要約されたログしか出ない製品では、後から経緯を追えません。

もう1つ見ておくのは、会計システム側に残る記録との突き合わせです。エージェントが共有のサービスアカウントで会計システムに接続していると、システム側の更新履歴には一連の操作が同じ利用者名で並びます。エージェント側のログに担当者名が残っていても、会計システム側では区別が付かない状態です。どちらのログを正とするか、突き合わせる鍵を何にするかを導入前に決めておくと、後から経緯を調べるときの手間が変わります。

保持期間と持ち出し可否も確認事項です。製品を乗り換えたとき、過去のログをエクスポートできるかどうかで、事務所に残る記録が変わります。証憑を扱わせるなら、国税庁の電子帳簿保存法一問一答（スキャナ保存関係）が示す保存の要件を、エージェントの処理が壊さないかも見ておきたいところです。

軸4 既存会計システムとの接続方式

接続方式は、公式APIによる接続、CSVの受け渡し、画面操作の自動化、の3段階に分かれます。下に行くほど導入は早く、壊れやすくなります。会計システム側の画面が変わると、画面操作型は静かに動かなくなります。

事務所が使っている会計システムを軸にして製品を絞るのが現実的です。たとえばfreeeのようなクラウド会計は公式の連携手段を持ちますが、どの製品がどこまで対応しているかは製品ごとに異なります。あわせて、その接続をベンダーが保守するのか、事務所が自前で作って保守するのかも、比較表に列を1つ足して書き分けます。

接続の共通規格として、モデルと外部ツールをつなぐModel Context Protocolを採用する製品も増えました。共通規格を使うと接続先を足しやすくなる一方で、事務所の端末側で動かす種類のサーバーには別の確認事項が付きます。前掲のセキュリティ文書は、端末上で動くサーバーがクライアントと同じ権限で実行される点を挙げ、実行前に利用者へ内容を示す仕組みや、実行環境を分離する設計を対策として並べています。その接続がどこで動くのかを、比較表の1列として持っておきます。

軸5 人の確認工程の作り込み

確認をどこに置けるかを見ます。実行前に止めるのか、実行後に出力を確認するのかで、事故の種類が変わります。OpenAIのGuardrails and human reviewのドキュメントは、承認が要るツール呼び出しでは実行の代わりに中断を記録し、再開可能な状態を返し、承認または却下のあとで同じ実行を再開する流れを説明しています。

会計事務所で効いてくるのは承認の粒度です。すべてを止めると人の手間が増えて使われなくなり、何も止めないと有資格者の確認が形骸化します。金額、件数、相手先といった条件で閾値を切れるか。切れない製品なら、運用側で工程を分けることになります。いずれにしても、税理士や公認会計士が最終的に内容を確認する工程を、手順のどこに置くかを先に決めておきます。

軸6 障害時の切り戻し

途中で失敗したときに何が残るかを聞きます。仕訳の登録が半分だけ進んだ状態から、どう戻すか。取り消しのAPIがあるか、下書き止まりにできるか。同じ依頼を再実行したときに二重登録にならないか。ベンダー側の障害で止まったとき、手作業に戻す手順が書けるか。デモの場面ではまず見えない部分なので、こちらから聞かないと出てきません。

軸7 費用構造

席課金か従量課金かで、繁忙期の見え方が変わります。エージェントは1つのタスクで何度もモデルを呼ぶため、従量課金だと失敗した試行にも費用が乗ります。会計事務所は月次と決算期に負荷が偏るので、年額固定が得か繁忙期の従量が得かは、事務所の業務量の形で変わります。

見えにくい費用も列に入れます。接続の初期構築、ログを保管する基盤、職員の教育、そして承認する人の時間です。最後の1つは請求書には出ませんが、実際にいちばん重くなることがあります。

比較のときは、想定する処理量を先に書き出してからベンダーに試算を依頼します。月次の対象となる伝票の量、決算期の増分、一件あたりに想定する処理の回数の3つを渡すと、席課金と従量課金の差が金額として見えます。渡さないまま出てくる見積もりは、たいてい最小構成の数字です。

業務によってどの軸を重く見るかが変わる

同じ事務所の中でも、業務によって効く軸は入れ替わります。

記帳と仕訳では、軸2の権限と軸6の切り戻しが重くなります。件数が多く、誤りが月次資料と申告に順に伝播するためです。読み取りと下書きまでに絞り、登録は人が押す構成から始める事務所があります。

証憑の突合では、軸1のデータの取り扱いと軸3のログが重くなります。領収書と請求書は個人情報と取引先情報の塊で、どのファイルがどこへ送られたかを説明できる状態にしておきたいからです。

月次資料の作成では、軸4の接続方式と軸5の確認工程が効きます。資料の見た目より、その数字がどのデータから来たのかを追えるかが問われます。

給与計算と年末調整では、軸1と軸2が同時に効きます。扱うのはマイナンバーを含みうる従業員情報で、しかも提出の期限が動かせません。データの取り扱いで妥協できず、繁忙期に処理が止まっても困る、という条件が重なる業務です。ここを最初の対象にするより、記帳や資料作成で運用を固めてから広げる順序を採る事務所があります。

税務調査の準備では、軸3のログが最も重くなります。何を根拠に、どの資料を作ったのかを、後から順に示せるかどうかです。

監査業務では、軸3と軸5に加えて、そもそも何をAIに任せるかの整理が先に来ます。この点は監査業務へのAI導入 先に整理しておく6つの論点と、公認会計士のAI活用で監査と非監査に分けて扱っています。

顧問先データを渡す前に整理する守秘義務と規程の論点

守秘義務の条文から確認します。税理士法第38条は秘密を守る義務の見出しを持ち、税理士が正当な理由がなくて税理士業務に関して知り得た秘密を他に洩らし、又は窃用してはならないと定めています。同法第54条は、税理士法人の使用人その他の従業者について同趣旨の規定を置いています。公認会計士法第27条も、業務上取り扱ったことについて知り得た秘密を他に漏らし、又は盗用してはならないと定めています。職員がエージェントを動かす構成では、第54条の射程に入る立場の人が実際の入力者になる点を、事務所として押さえておきます。

個人データの側では、個人情報保護法第23条が安全管理措置、第25条が委託先の監督、第27条が第三者提供の制限を定めています。エージェントは、製品ベンダー、その先のモデル提供者、さらに接続先のサービスと、複数の事業者をまたいで動きます。どこまでが委託でどこからが第三者提供になるのかは、契約の構成とデータの流れによって整理が変わるため、事案ごとの検討が要ります。個別の当てはめは有資格者の判断に委ねる領域ですが、比較の段階で確認できるのは、ベンダーが再委託先を開示しているか、データの所在国を示しているか、という事実の部分です。

顧問先への説明も比較の材料になります。何のデータを、どのツールに、どの範囲で入れるのか。説明資料が作れる程度に情報を開示している製品と、そうでない製品があります。同意の取り方を決めるのは事務所ですが、説明の材料を出せるかどうかはベンダーの姿勢に左右されます。

事務所の規程に落とすとき、運用例として挙がるのは次の項目です。エージェントに投入してよいデータの区分、投入を止めるデータの区分、権限を持つ職員の範囲、承認を要する操作の一覧、ログの保管期間と点検の頻度、事故が起きたときの連絡経路です。ガバナンスの枠組みとしては、総務省と経済産業省がAI事業者ガイドライン（第1.1版）を2025年3月28日付で公表しており、事業者がAIの社会実装とガバナンスを併せて実践するための非拘束の指針として位置づけられています。規程の骨格を作る段階の参照先になります。

比較検討の進め方 要件表を先に作りPoCで確かめる

順序を逆にしないことが要点です。製品表を作る前に、事務所側の要件表を作ります。7つの軸ごとに、これを満たさない製品は見ない、という線を書きます。線を書くと候補が3つ程度に減り、そこからようやくデモを見る意味が出てきます。

要件表の下書きは、生成AIに手伝わせても構いません。ChatGPT、Claude、Geminiのいずれでも動く形にすると次のようになります。

あなたは会計事務所の業務システム選定を支援する担当者です。
以下の事務所条件をもとに、AIエージェント製品の要件表を作成してください。

【事務所条件】
- 職員数: 十数名（うち有資格者は数名）
- 主な業務: 記帳代行、月次巡回、法人決算、年末調整
- 使用中の会計システム: （システム名を記入）
- 顧問先データの機微度: 個人事業主の通帳明細と給与データを含む

【出力形式】
1. 次の7軸それぞれについて、「必須条件」と「あれば望ましい条件」を分けて記載
   (1)入力データの取り扱い (2)権限と実行範囲 (3)監査ログ
   (4)既存会計システムとの接続方式 (5)人の確認工程 (6)障害時の切り戻し (7)費用構造
2. 各軸について、ベンダーに投げる質問文を2つずつ
3. 必須条件を満たさない場合に想定される業務上の支障を1行で

制約:
- 特定の製品名を推奨しない
- 法的評価や適法性の判断は書かず、確認すべき事実項目だけを挙げる

PoCは、同じ入力セット、同じ期間、同じ評価者で回します。製品ごとに担当者を変えると、評価者の癖が差として出てしまいます。期間は2週間から1か月、対象は実データではなく、事務所が作った匿名の検証用データから始める形が扱いやすいです。

評価指標は、正答率だけに寄せないことです。人が直した回数、承認までの待ち時間、切り戻しが発生した割合、1タスクあたりの費用、職員が使うのをやめた時点、の5つを揃えると、デモの印象では埋まらない差が出ます。PoCの結果を整理するプロンプトは次のとおりです。

以下はAIエージェント製品AとBのPoC結果ログです。
7つの評価軸ごとに、事実と解釈を分けて整理してください。

【入力】
（PoC期間、対象業務、件数、修正回数、承認待ち時間、切り戻し発生数、費用の実績値を貼り付け）

【出力形式】
1. 軸ごとに「観測された事実」を箇条書き（数値は入力に含まれるものだけを使う）
2. 軸ごとに「事務所として判断が分かれる点」を1行
3. 追加で計測すべき項目を3つ
4. 現時点で結論を出せない軸を明示し、その理由を書く

制約:
- 入力に無い数値を推定して補わない
- 製品の優劣を総合点でまとめない（軸ごとに分けたまま出す）
- 最終判断は有資格者が行う前提で、判断材料の提示に留める

PoCの結果は、税理士または公認会計士が内容を確認したうえで、事務所として採否を決める工程につなげます。導入の全体の進め方は士業事務所のAI導入の進め方に、ツール選定の一般的な観点は士業の業務効率化AIツール比較にまとめています。

比較でつまずく典型パターン

デモ映えで決めてしまう例が最も多く見られます。営業デモは、うまくいく入力を選んで見せる場です。事務所が持ち込んだ崩れた形式の証憑を、その場で流させてもらうだけで、印象はかなり変わります。

既存システム側の制約を後回しにする例も繰り返し起きます。エージェント側は柔軟でも、会計システムのAPIに書き込み権限の分割が無ければ、軸2の設計はそこで詰まります。会計システムの仕様確認を、製品比較より先に済ませておく順序が向いています。

ログ要件を後から足そうとする例もあります。運用が始まってから、何を根拠に処理したのかを聞かれ、遡れる記録が無いと気づく形です。ログは後付けが効きにくいので、比較の段階で条件に入れておきます。

費用を席数だけで見る例も出ます。エージェントは処理量に費用が連動しやすく、席数と実際の請求額がずれます。繁忙期の1か月を想定した試算を、ベンダーに出してもらうのが早道です。

職員を巻き込まずに決めてしまう例もあります。承認の工程を実際に担うのは現場の職員で、比較の段階で操作感を見ていないと、導入後に承認が滞ります。PoCの評価者に、実際に手を動かす担当者を入れておくと、要件表の抜けがその場で見つかります。

最後に、全部を一度に比べようとして止まる例です。記帳、証憑突合、月次資料をまとめて評価しようとすると、比較表が埋まらないまま数か月が過ぎます。業務を1つに絞り、その業務で重い軸だけを深く見る進め方のほうが、結論に届きます。

まとめ

会計事務所のAIエージェント比較は、製品カタログを集める作業ではなく、事務所として譲れない条件を先に言語化する作業です。入力データの取り扱い、権限と実行範囲、監査ログ、既存会計システムとの接続方式、人の確認工程、障害時の切り戻し、費用構造の7つを要件表にしてから候補を絞ると、デモを見る前に半分は決まります。業務によって重い軸が入れ替わる点、守秘義務と個人データの整理は条文と事実の確認に留めて当てはめは有資格者に委ねる点、この2つを押さえておけば、比較表は作り直しの効く資産になります。

よくある質問

会計事務所のAIエージェント比較で最初に見る軸はどれですか

最初に見るのは、入力データの取り扱いと権限の分割の2つです。この2つを満たさない製品は、他の軸がどれだけ良くても顧問先データを扱えないため、候補から外れます。逆に言えば、この2つで候補が絞れるので、比較の作業量そのものが減ります。

チャット型のAIと比べて、比較項目は何が増えますか

増えるのは、実行の制御にかかわる項目です。チャット型は出力の質を見れば足りますが、エージェントは実行範囲、承認の入れ方、失敗時に残るもの、ログの粒度が加わります。出力の質だけで比べると、導入後に運用面で詰まります。

監査ログはどこまで残せばよいですか

判断の材料になるのは、いつ、誰の権限で、どのツールを、どの引数で呼び、何が返り、人がどこで承認したか、の6項目です。エージェントは一件の依頼で多数のツールを呼ぶため、要約されたログだけでは経緯を追えません。保持期間とエクスポートの可否も、比較の段階で聞いておきます。

顧問先の資料をAIエージェントに読ませてよいですか

事務所として先に決めるのは、対象データの区分と顧問先への説明の仕方です。税理士法第38条は秘密を守る義務を定め、個人情報保護法第25条は委託先の監督を定めています。個別の事案がどう整理されるかは有資格者の判断に委ねる領域なので、比較の段階では、ベンダーが再委託先とデータの所在国を開示しているかという事実確認に集中します。

PoCはどのくらいの期間で回すものですか

2週間から1か月を1区切りにする進め方が扱いやすいです。短すぎると職員が操作に慣れる前に終わり、長すぎると比較対象の製品側が更新されて条件が揃わなくなります。同じ入力セットと同じ評価者で回すことのほうが、期間の長さより結果に効きます。

費用は席課金と従量課金のどちらが合いますか

事務所の業務量の形で変わります。エージェントは1タスクで何度もモデルを呼ぶため、従量課金では失敗した試行にも費用が乗ります。月次と決算期に負荷が偏る事務所は、繁忙期の1か月を想定した試算をベンダーに依頼して比べるのが実際的です。

小規模な会計事務所でも比較する意味はありますか

あります。むしろ職員数が少ない事務所ほど、権限の分割と承認の粒度を製品側の機能に頼る場面が増えます。運用でカバーできる人手が限られるぶん、機能として持っているかどうかの差が業務に直接出ます。

参考文献

• 日本公認会計士協会 テクノロジー委員会研究文書第11号 監査におけるAIの利用に関する研究文書の公表について
• 個人情報保護委員会 生成AIサービスの利用に関する注意喚起等について
• 国税庁 電子帳簿保存法一問一答（スキャナ保存関係）
• 総務省・経済産業省 AI事業者ガイドライン（第1.1版）
• e-Gov法令検索 税理士法
• e-Gov法令検索 公認会計士法
• e-Gov法令検索 個人情報の保護に関する法律
• Anthropic Building effective agents
• OpenAI Guardrails and human review
• Model Context Protocol Security Best Practices

※士業のチカラでは、生成AIの導入支援から運用最適化まで、貴事務所の業務に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://shigyonochikara.jp/contact/