結論: 士業事務所の AI 導入は、 提案書を渡した時点ではまだ完了していません。 業務文脈に踏み込み、 コードを書き、 現場の運用と監査体制まで一気通貫で伴走する役割を、 ここでは FDE モデルと呼んでいます。
提案書だけでは現場の AI 利用は始まりません
過去数年、 多くの士業事務所が AI 導入を試してきました。 商用 AI チャットツールを所員に配り、 セミナーに代表者が参加し、 ベンダーに POC を依頼するところまでは、 どの事務所もできています。 しかし、 半年後に振り返ってみると、 業務フローに AI が組み込まれた事例は驚くほど少ないというのが実情です。「提案書はもらいました」 「POC は動きました」 「現場では使われていません」 という三段の構造が、 業界全体で繰り返されています。
このパターンに対して、 ShigyoAI が採用しているのが FDE モデルです。 FDE は Forward Deployed Engineer の略で、 米国を中心とした AI スタートアップ業界で広まってきた職種名になります。 直訳すれば「前線配備エンジニア」 で、 本社で待機して指示を出すのではなく、 顧客の現場に入り込んで実装まで担うエンジニアを指しています。 提案書を作って終わりにせず、 現場の業務理解と技術実装を一人の責任で結ぶ点が、 従来のコンサルや SI とは異なっています。
本記事では、 この FDE モデルを日本の士業事務所、 特に税理士法人や弁護士法人に適用する場合の設計を、 ShigyoAI の実装経験から整理していきます。 関連して、 FDE の概念全般については 士業AI 導入で使う FDE とは何か で別途解説しています。
士業特有の業務文脈が、 FDE モデルを必要としています
汎用 SaaS では士業の業務は回りません。 これは技術的な制約ではなく、 業務の構造に由来するものです。
第一に、 守秘義務が業務の前提にあります。 税理士法 38 条、 弁護士法 23 条が定める守秘義務は、 個人情報保護法より範囲が広く、 業務を通じて知り得た一切の情報が対象となります。 AI ツールに顧客の試算表や契約書を渡す行為は、 学習利用の有無、 保存場所、 アクセスログの保持期間まで含めて、 法律論として整理が必要になります。 汎用 SaaS のサポートではこの整理が提供されていません。
第二に、 業務システムが事務所ごとに分散しています。 業界標準の会計ソフト、 税務申告システム、 文書管理サービスのどれを採用しているかは事務所ごとに異なり、 ファイル管理は社内サーバー、 クラウドストレージが混在しているケースが多いのが現状です。 特定の経営手法を採用していれば月次採算管理が独自に走り、 業務処理簿の作成は税理士法上のリスクと結びつきます。 こうした文脈に AI を組み込むには、 既存システムとの統合と、 業務フロー全体の再設計が同時に必要となってきます。
第三に、 所員のリテラシーに大きな分散があります。 ベテラン税理士は判断業務に集中したいものの新しいツールには慎重で、 中堅スタッフは業務効率化のメリットを実感しているけれど学習時間が取れず、 若手は AI を業務外で日常的に使うものの業務内での使い方は手探りという状況になっています。 単一のツール導入では、 この三層を同時に動かせません。
これらの文脈を踏まえて業務フローを再設計し、 ガードレールを設計し、 所員の利用を継続的にモニタリングしていくのは、 提案書では完結しない作業です。 だからこそ FDE モデルが必要になってきます。
FDE が士業事務所で具体的に何をするのか
ShigyoAI における FDE の作業は、 大きく四つに分かれています。
一つ目は業務棚卸しと AI 適用領域の特定です。 月次決算、 顧問先面談の準備、 申告書作成、 税制改正対応——どの業務にどの程度の時間が使われているかを所員と一緒に洗い出し、 AI で削減可能な作業と人間が判断すべき作業を分離していきます。 ここで業務処理簿の整備や CRM の不在といった、 AI 以前の組織課題が表面化することも多くあります。 FDE はこれらを記録し、 AI 導入の前提として並走しながら整理していきます。
二つ目は実装です。 業務フローに組み込むコードを実際に書いていきます。 多くの場合、 既存の SaaS の機能を組み合わせるだけでは不十分で、 事務所固有のロジック——例えば顧問先の業種別の通信パターン、 内部レビューの承認フロー、 申告書の最終チェック手順——を、 LLM のプロンプトやエージェントの動作として実装していく必要があります。 業界標準の会計ソフトの API 連携機能を介して仕訳データを取得し、 公的データベース参照型の AI で税法を参照させ、 商用 AI チャットツールの API でレビューを走らせる、 といった構成は実例の一つです。
三つ目は基盤の設計です。 AI を組織で運用するには、 認証 (AUTH)、 権限管理 (ACCESS)、 監査ログ (AUDIT) の三層が必要になります。 誰が、 いつ、 どの AI に、 何を入力し、 何が出力されたかを、 案件単位で追跡できる構造を持たないと、 守秘義務違反や情報漏洩の事後対応ができません。 異常検知 (DETECT) と追加認証 (STEP-UP) を並列に重ねることで、 監査要件と業務スピードのバランスをとっていきます。 これらの基盤は、 一度設計すれば事務所内のあらゆる AI 利用で再利用できる共通インフラとなっていきます。
四つ目は定着伴走です。 実装が終わった後も、 現場での利用率、 出力品質、 所員のフィードバックを継続的に観測し、 プロンプトやフローを改善していきます。 商用 AI チャットツールのバージョンアップ、 業務要件の変化、 法改正への対応——これらは一度の導入で完結せず、 数か月から年単位の伴走が必要になってきます。
提案書納品型コンサルや SI との違いは何でしょうか
FDE モデルを選ぶか、 従来型のベンダーを選ぶかは、 事務所の事情によって判断が分かれてきます。 違いを表で整理すると、 おおむね次のようになっています。
| 観点 | 提案書納品型コンサル | SI ベンダー | FDE モデル |
|---|---|---|---|
| 成果物 | 提案書・分析レポート | システム納品 | 業務フロー+実装+運用 |
| 業務理解の深さ | ヒアリング段階で完結 | 要件定義書まで | 現場の運用にまで踏み込む |
| 実装の主体 | 別ベンダーに引き継ぎ | SI ベンダー | FDE 本人 |
| 法令対応 | 一般論の整理 | システム要件として | 個別ケースの判断にまで踏み込む |
| 価格 | 工数ベース | 工数ベース | 成果ベース |
| 期間 | 数週間〜数か月 | 半年〜年単位 | 数か月〜年単位の継続 |
提案書納品型は、 経営戦略の枠組み整理には強みがあります。 一方で、 現場で動くシステムを残さないため、 半年後に「何も変わっていません」 という結果になることが多くなります。 SI ベンダーは大規模システムの実装に強い反面、 業務フローの細部に踏み込まないため、 出来上がったシステムが現場の運用に合わないこともあります。 FDE モデルは、 これら二つの中間ではなく、 「業務理解+実装+運用」 を一つの責任で持つ別カテゴリの役割と捉えるのが正確だと考えています。
どんな事務所が FDE モデルを選ぶでしょうか
ShigyoAI が伴走してきた事務所には、 共通するパターンがあります。 規模は概ね 30 名から 200 名、 既に何らかの AI ツールを試したことがあり、 期待した成果が出ていない、 経営層が AI 活用を経営課題として認識している、 という三点が揃っている事務所では、 FDE モデルが機能しやすいといえます。
逆に、 規模が極めて大きい事務所 (1000 名以上) では、 既に内製の IT 部門があり、 グループ会社で自前の SaaS を開発しているケースが多くなっています。 この場合、 ShigyoAI のような外部の FDE よりも、 内部のエンジニアと自社専属のコンサルで進めるほうが合理的になります。 また、 個人事務所 (5 名以下) では予算規模が合わず、 既存の汎用 AI ツールを工夫して使うほうが現実的なケースも多くなります。
スイートスポットは中堅事務所です。 ShigyoAI の伴走実績でも、 50-200 名規模の税理士法人や弁護士法人で、 業務時間の削減と顧問先からの評価向上が同時に観測されています。 具体的な数字は秘密保持契約の関係で本記事には記載できませんが、 初回相談時に類似事務所の事例として共有することは可能です。
関連記事
- 業務棚卸しの進め方については 税理士事務所が AI 導入で最初にレビューすべき業務フロー で具体的なチェックリストを公開しています。
- 守秘義務と AI の関係は 士業事務所が ChatGPT に入力してはいけない情報 で 3 区分の判断基準を整理しています。
- AI 導入が PoC で止まる典型パターンは なぜ AI 導入は本番展開で頓挫するのか で 3 つの構造的原因を整理しています。
初回相談で確認できること
FDE モデルが自事務所に合うかどうかは、 業務フローと AI への期待が明確になった段階で判断するのが望ましいです。 ShigyoAI では 60 分の初回相談で、 業務棚卸しの方向性と AI 適用領域の見立てをその場でお示ししています。 受注を前提としない議論として活用していただける構造であり、 秘密保持契約を締結のうえで具体的な業務文脈に踏み込んだ議論も可能です。