展示会でAIのデモを見た所長の方が、期待を持ち帰って稟議を起こそうとする場面があります。ベンダーに見積もりを依頼すると、数百万円規模の試行プランが返ってきます。提案書には精度・スピード・効率化といった言葉が並んでいるのですが、何が成果物として残るのか、試行を終えた後に何を見て継続や撤退を判断するのかが、提案書からは読み取りにくいことが多いです。所内で稟議書を回そうとしても、「これを通したあと、何を見て継続か撤退かを判断するんですか」という最初の質問で手が止まってしまいます。
経営判断力の問題というより、業務にAIを入れる動きを「単発のツール購入」ではなく「一つのプロジェクト」として段取る型が、まだ広まりきっていない時期なのかもしれません。本稿では、士業事務所が業務にAIを組み込むプロジェクトを進めるときの4つの段と、各段に置く判断のゲートを業務の流れに沿ってご紹介します。経営層の方が稟議の前に手元に置けるような構成を目指しました。
試行から本番運用までの現場担当者の動きについては、関連記事「AI PoCが本番運用で止まる理由」で扱っています。本稿は経営層・プロジェクト責任者の方が全体像を組み立てる視点でまとめています。
業務棚卸しから始める
業務にAIを入れる動きを事務所内のプロジェクトとして進めるとき、最初に置くのが業務棚卸しの段です。「AIで何ができるか」から入るのではなく、「自分たちの事務所では、誰が・どの業務に・どれだけの時間をかけているか」を可視化していきます。記帳代行、申告書作成、顧問先からの問い合わせ対応、社内議事録作成といった業務単位で、時間と件数を把握していく工程です。
ツール選定より先に業務地図を作っておくと、後段の判断が落ち着きやすくなります。利用者の方と並んで座り、業務の流れを地図化し、価値の大きい領域を特定する動きは、海外でAI実装支援を担うチームの初期活動としても語られています (Palantir公式求人: Forward Deployed Software Engineer)。
試行で実データを見る
棚卸しで特定した価値の大きい業務を1 〜 2件に絞り、AIで実際に動かしてみる段です。ここで見るのは「精度が出るか」だけではありません。「現場担当者の方がストレスなく使えるか」「想定外の入力パターンがどれくらい来るか」を実データで観察していきます。
試行をベンダー任せにせず、現場担当者の方が触り、所長の方が結果を見る、という関与体制を作っておく事務所もあります。この関与の作り方が、後段の本番化での進めやすさにつながりやすいようです。
業務フローに接続する
試行で「これは使えそうだ」と判断したものを、業務フロー・既存システム・承認経路・ログ・権限と接続していく段です。会計システム、税務システム、顧問先からの紙資料、例外的な依頼メモなど、無数のデータ経路をどう繋ぐかを決めていきます。
この段では、技術設計だけでなく「誰が・どの権限で・どの顧問先データに触れてよいか」という業務ルールの設計も同時に進める事務所が多いです。この段を飛ばして試行から直接展開すると、運用開始後に手戻りが発生しやすくなります。
運用に乗せて見続ける
本番稼働した後の継続運用の段です。KPIの月次レビュー、例外パターンの蓄積、モデル劣化の監視、担当者の入れ替えに伴う引き継ぎを、誰がどの頻度で行うかを決めていきます。
「導入して終わり」という形にせず、3か月後・6か月後にもKPIを見て改善していく体制が作れるかどうかが、業務にAIを組み込む動きを「投資」として回収できるかどうかにつながりやすいようです。
段の間に判断のゲートを置く
各段の間に「ゲート」を置いて、ゲートを通過しない限り次に進まない、という運用を取る事務所もあります。試行が止まったまま広がらない、というよく聞く場面を避ける一つの形です。
| 段 | 通過の目安 | 通過しないときの選択肢 |
|---|---|---|
| 業務棚卸し | 上位3業務について、月間時間・件数・担当者・現状の困りごとが文書化されている | 試行に進まず、ヒアリングをやり直す |
| 試行 | 業務KPI (時間・件数・品質) でベースライン比の改善が定量的に見える / 現場担当者の方の継続意向がある | 本番設計に進まず、課題設定を見直す |
| 本番設計 | 連携先システム・例外フロー・承認経路・ログ保管・権限分離が文書化されている | 本番稼働させず、設計を補完する |
| 運用 | 月次でKPIを測定し、四半期ごとに継続・撤退・再設計の判断ができている | 撤退または再設計を選択肢に入れる |
各ゲートで「進む・戻る・止める」を判断する責任者を、プロジェクト開始時に決めておく事務所もあります。判断責任者が不在のまま全段がなんとなく進んでしまうと、撤退の判断が遅れて損失が広がりやすくなります。
役割を分けておく
業務にAIを入れるプロジェクトを動かすときには、少なくとも4つの役割を分けておく事務所が多いようです。1人の方が複数を兼ねる小規模事務所でも、役割としては分けておくと意思決定が落ち着きやすくなります。
- 代表 (所長・パートナー) の方: 投資判断・撤退判断・対外的な責任の引き受け
- 業務担当 (現場リーダー) の方: 業務棚卸しの一次情報提供・試行での実利用・例外パターンの記録
- IT担当 (情報システムor兼務者) の方: 既存システム連携・権限管理・ログ運用・ベンダー窓口
- 外部の技術パートナー (実装支援者・コンサル等): 技術設計・実装・本番化アセスメント・継続改善の伴走
業務知識を持つ士業有資格者の方と、技術設計を担う外部の技術パートナーが対になって動くと、判断のスピードと品質のバランスが取りやすくなる場面があります。
スケジュールと予算の感覚
事務所規模や対象業務によって幅はありますが、おおむね次のレンジで計画される事務所が多いようです (あくまで一例で、実際の見積もりは案件ごとに変動します)。
- 業務棚卸し: 2 〜 4週間
- 試行: 1 〜 3か月
- 本番設計: 1 〜 2か月
- 運用立ち上げ: 3 〜 6か月 (KPIで効果検証)
予算面では、試行に事務所の年間IT予算の10 〜 30% 程度を上限として配分し、ゲートで継続判断する形を取る事務所もあります。最初に「全額前払い・年契約」の形で契約してしまうと、試行で思わしくない結果が出ても撤退しづらく、損失が広がりやすくなります。
費用・責任者・レビュー頻度の関係は、次のような形に整理しておくと稟議資料に転記しやすくなります。
| 段 | 費用配分の感覚 | 主な責任者 | レビュー頻度 |
|---|---|---|---|
| 業務棚卸し | 年間IT予算の数% | 業務担当 (現場リーダー) | 単発 (完了時に所長レビュー) |
| 試行 | 年間IT予算の10 〜 30% (ゲート判断付き) | 所長・パートナー | 隔週進捗 + 終了時ゲートレビュー |
| 本番設計 | 案件規模に応じて見積もり | IT担当 + 外部の技術パートナー | 月次設計レビュー |
| 運用 | 月額ランニング + 改善予算 | 所長 + 業務担当 | 月次KPIレビュー + 四半期判断 |
特に運用段の月次レビューについては、KPI測定の主担当・参加メンバー・議事録保管先を運用開始前に文書化しておくと、担当者の入れ替えに耐えやすくなります。
セキュリティ・コンプラを段に紐付ける
業務にAIを入れる動きでは、段ごとに押さえておきたい観点があります。
個人情報保護委員会は2023年6月に「生成AIサービスの利用に関する注意喚起等」を公表しています (個人情報保護委員会)。経産省・総務省も「AI事業者ガイドライン」を公表していて、AI事業者と利用者の双方への留意事項を扱っています (経産省・総務省AIガイドライン)。
これらを踏まえて、各段で意識される観点を見ていきます。
- 業務棚卸しの段: 顧問先データのうち、AIに投入してよいデータ・不可のデータを契約・規程上で分類しておきます
- 試行の段: 本番データではなくマスキング済みデータで検証する事務所もあります。本番データを使う場合は、対象範囲と保管期間を契約に明記しておく流れになります
- 本番設計の段: 誰が・いつ・何を入力したかのログ保管経路、外部AIサービスを使う場合の「学習に使われない」設定・契約条項、AIの誤回答が顧問先に届いた場合のインシデント対応フローを整えていきます
- 運用の段: 四半期ごとの権限棚卸し、退職者アカウントの即時無効化、ログの定期レビュー、規程更新時のAI利用範囲の見直しを置きます
「試行だから本番データを使ってよい」と暗黙に判断してしまう場面が、後で困りやすい経路になりやすいようです。試行の契約段階で、データ取り扱い範囲と再委託の可否を文書化しておくと、後工程が落ち着きます。
自社で進めやすい範囲と外部知見を借りる範囲
事務所の規模・社内人材によって境界は動きますが、おおむね次のような形で分けて考える事務所が多いようです。
自社で進めやすい範囲としては、業務棚卸し (誰が・何を・どれだけ時間をかけているか)、現場の困りごとの言語化、試行段での現場利用と例外パターンの記録、KPIのベースライン計測、顧問先データの分類 (投入可・不可) の業務側ルール案、といったあたりが挙げられます。
外部の技術パートナーと組みやすい範囲としては、既存システム (会計・税務・顧客管理) との連携設計・実装、権限管理・ログ保管・監査経路の技術設計、例外処理・フェイルセーフの実装、本番運用後のモデル劣化監視・再学習設計、KPIダッシュボードの構築と定期レビュー設計、セキュリティ要件・契約条項の技術観点でのレビューが挙げられます。
「試行はベンダーがやってくれる、本番化と運用は社内でなんとかする」という分担を取った事務所では、現場担当者の方の負荷が大きくなりやすく、結果として試行が広がらないまま止まりやすくなります。プロジェクト開始時に分担表を作り、四半期ごとに見直しておく事務所もあります。
残しておきたい論点
ここまでの4段は段取りの骨格ですが、実際にプロジェクトを動かしてみると、決め切らないまま残る論点がいくつか出てきます。事前に意識しておくと、走り出してから止まる場面が減りやすくなります。
- 撤退の目安の事前合意: うまくいかなかった場合に何を見て撤退と判断するかを、プロジェクト開始前にゲートと紐付けて合意しておく事務所もあります。走り出してから決めようとすると、人情で撤退しづらくなる場面が出てきます
- 担当者交代の引き継ぎ設計: 月次レビューの主担当・KPIの算出方法・ログの所在を文書化しておかないと、担当者の方が抜けたときに運用が止まりやすくなります
- 顧問先への説明範囲: 業務にAIを使っていることを顧問先にどこまでお伝えするか、契約書への明記が要るかは、事務所方針として決めておく場面が多いです
- モデル更新時の影響評価: 利用するAIサービスがモデルを更新した際、試行で取った精度が維持されるかをどう再評価するか、を考えておきます
- ベンダー依存への備え: 単一ベンダー依存になった場合の出口 (データのエクスポート可否、再委託先の候補) を見ておきます
これらは決め切らないと進めない性質のものではないのですが、四半期レビューのチェック項目として持っておくと、止まりにくい運用になります。技術の選定の前に、誰が・どの判断を・いつ下すかという段取りを決めておく動きが、士業事務所で業務にAIを組み込むプロジェクトの土台になりやすいです。
関連記事
- AI PoCが本番運用で止まる理由
参考
- Palantir公式求人「Forward Deployed Software Engineer」 https://jobs.lever.co/palantir/5168e8fd-fec1-4fea-b7a1-81bdaea65850
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」2023年6月2日 https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/
- 経済産業省・総務省「AI事業者ガイドライン」 https://www.soumu.go.jp/main_sosiki/kenkyu/ai_network/02ryutsu20_04000019.html