過去5年で起きた「ベンダー納品型 DX」の限界
2020年代前半、士業事務所の DX 文脈で繰り返し観察された出来事があります。会計事務所が RPA ツールを導入して仕訳の一部を自動化したり、社労士事務所が労務 SaaS を入れて手続きを電子化したり、法律事務所が文書管理システムで案件ファイルを電子化したり——いずれも「ツールを選定し、ベンダーが納品し、現場が使い始める」というモデルで進みました。
これらは一定の成果を出しました。一方で、2024年以降に生成 AI が業務に組み込まれ始めた局面では、同じモデルが機能しないケースが目立ち始めています。「生成 AI サービスを契約したが現場が使いこなせない」「LLM を組み込んだ文書ドラフト機能を入れたが、顧客成果物として出すには結局スタッフが書き直している」「顧問先データを参照させたいが、権限設計をベンダーが詳しく聞いてくれない」——こうした状況は、士業事務所のAI導入において起こりやすいパターンとして想定されます。
ベンダー納品型は、要件が確定したものを実装するモデルとしては優秀です。しかし AI は確率的に外す前提で運用する必要があり、要件確定の段階で「外したときにどう運用するか」まで設計に折り込まないと、本番に乗りません。前回のFDEとは何かでは、この空白を埋める役割として FDE という職種を紹介しました。本稿はその続編として、「なぜ士業というセグメントで FDE 的支援が特に効くのか」を構造として掘り下げていきます。
士業事務所が AI 導入で直面する3つの壁
具体事例を抽象化すると、士業事務所での AI 導入は次の3つの壁にぶつかる、という傾向が観察されます。
壁1: 守秘義務と個人情報の壁。弁護士法・税理士法・社会保険労務士法・行政書士法など、士業はそれぞれの業法で守秘義務を課されています。顧問先の決算書、依頼者の供述、給与情報、家族関係——AI に入力する前に「これは入れてよいか」を判断する必要があります。監督官庁からも、生成 AI サービスの利用にあたっては入力する個人情報の必要性・適法性を事前に確認すべきだと注意喚起が出ています(詳細は公式情報を確認のこと)。これは事業者全般に向けた注意ですが、業法で守秘義務を負う士業では、自所の判断ミスがそのまま懲戒事由・損害賠償につながるため、一般企業以上に丁寧な設計が必要になります。
壁2: 業務の属人化と暗黙知の壁。士業の実務は、所長や熟練スタッフの「頭の中」に多くのノウハウが蓄積されています。「この事案だとこの書面のテンプレを少しいじって出す」「この顧問先は決算期前にこういう論点を必ず確認する」——マニュアル化されていない判断が、品質を支えています。この暗黙知を、生成 AI に「自然言語のプロンプト」だけで再現させようとすると、最初は便利でもすぐ頭打ちになります。事務所固有のテンプレ・過去案件・通達・社内マニュアルを AI に参照させる仕組み(RAG: Retrieval-Augmented Generation 等)が必要になりますが、ここはツール選定だけでは解決しない領域です。
壁3: 複数 SaaS の連携と例外処理の壁。会計事務所であれば各種会計クラウド、法律事務所であれば文書レビュー系・電子契約・裁判所システム、社労士事務所であれば給与計算 SaaS と労務 SaaS。士業事務所は、業種柄、複数 SaaS と行政手続きを横断するワークフローを抱えがちです。「AI に仕訳のチェックをさせたい」「申立書のドラフトを案件管理データから自動生成したい」というニーズは、単発の生成 AI ツールでは完結しません。API スキーマの理解、例外データの扱い、誤った出力を検知してレビューに戻す仕組み——これらを設計できる人が、事務所内にも、既存のベンダーにもいない、というケースが目立ちます。
既存の支援メニューが届きにくい構造的理由
この3つの壁に対して、既存の支援メニューがなぜ届きにくいかを表で整理します。
| 区分 | 主たる成果物 | 士業 × AI 文脈での弱点 |
|---|---|---|
| IT ベンダー | システム納品 | 要件定義に書かれた範囲で動きます。「LLM は確率的に外す」前提のレビュー設計までは踏み込まないことが多い領域です |
| コンサルティングファーム | 提言書・戦略書 | 戦略レイヤーで止まり、会計 SaaS の API 例外処理までは降りてこない傾向があります |
| 情シス(社内 IT) | 社内システム運用 | 士業事務所には常勤の情シスがそもそも置かれていないケースが大半です |
| SES(客先常駐) | 工数提供 | 指示通りに作業する設計のため、守秘義務と業務フローを再設計する役は担いません |
| FDE | 業務成果(KPI 改善・本番運用) | 課題発見から実装・定着まで一気通貫で担う設計です |
どれが優れている・劣っているという話ではありません。基幹システム更改なら IT ベンダーが向きますし、経営戦略の整理ならコンサルティングファームが向きます。FDE が活きるのは、「AI という確率的なシステムを、守秘義務のある現場業務に溶け込ませる」という、領域横断の判断を必要とするフェーズです。FDEという職種そのものの定義・語源・海外での位置付けは、FDEとは何かで整理しているので、ここでは繰り返しません。
士業ドメイン × FDE が機能する4つの場面
抽象論だけだとイメージしづらいので、士業事務所で FDE 的支援が効きやすい具体場面を挙げていきます。
顧問先データの RAG 化。「過去5年分の決算書・議事録・契約書を AI に参照させて、新規依頼のヒアリングで活用したい」というニーズがあります。どのフォルダのどのファイルを参照対象に含めるか、顧問先 A の担当者が B のデータに触れない権限設計、スキャン PDF の OCR 品質と誤読の許容範囲、削除依頼・契約終了時の対応——ツール選定の前に決めるべき設計事項が多くあります。
会計 SaaS / 法務 SaaS との API 連携。「会計クラウドの仕訳データを AI でチェックして、異常値だけスタッフのレビューに回したい」というシーンです。単に API を叩くだけではなく、「LLM が確率的に外したときに、誤ったデータが顧問先に届かないようにする仕組み」を設計する必要があります。リトライ・差し戻し・人によるレビュー必須のフラグ——こうした「AI が外す前提の運用」の設計は、ベンダー納品型では対応しづらい領域です。
監査ログ・操作ログの整備。AI を業務に使い始めると、すぐに「誰が・いつ・どのプロンプトを入れて・どんな出力を承認したか」を追跡したくなります。後から「あの書面のドラフトは AI 出力をそのまま使ったのか、レビューを通したのか」を確認できるかどうかは、業法上のリスク管理にも内部統制にも直結します。この監査ログ設計は、業務フローと一体で考えないと意味のないログばかり溜まる結果になりがちで、「業務 × 技術 × 運用」を横断できる視点が必要になります。
個人情報・守秘義務の運用ルール文書化。技術的にセキュアでも、運用ルールが曖昧では事故が起きます。「Web 会議の議事録 AI 文字起こしに依頼者氏名は含めてよいか」「生成 AI サービスのエンタープライズ契約と個人契約をスタッフがどう使い分けるか」——こうしたグレーゾーンの線引きを、業法と現場運用の両面から文書化する作業も、FDE 的支援の対象になります。
「AI が外す前提」を初期設計に組み込めるか
セキュリティ・コンプライアンスの観点で、FDE 的支援が士業に向いている理由を整理します。
- LLM の確率的な振る舞いを所与とした設計: レビュー・差し戻し・ログ取得を組み込む発想が、従来型 IT ベンダーとは異なります
- 入力データの線引きを業務文脈で議論できる: 「これは AI に入れていい / いけない」の判断を、業務フローと業法の両面から一緒に詰められます
- オプトアウト・エンタープライズ契約の選定に技術知見を持ち込める: API 経由のデータが学習に使われない契約形態、データの保存リージョン、削除ポリシー——契約レイヤーの判断にも技術側の視点を持ち込めます
- 監査ログを「後付け」でなく「最初から」設計する: 運用が走ってから「ログがありません」では遅い、という前提で初期設計から組み込みます
- 生成結果の最終チェック責任を「人間に残す」設計にする: AI 完全自動化ではなく、専門家の判断を AI が支援する前提でワークフローを組みます
監督官庁の注意喚起を踏まえると、士業事務所で生成 AI を使う場合、「事前に入力情報の必要性・適法性を確認するプロセスがワークフローに組み込まれているか」を点検しておきたい場面です。これも、技術と運用の両方を見られる役割が設計に関わると、後からの手戻りは小さくなる、と考えています。
視点の置きどころ
FDE が士業に向いている、という命題は、職種の万能性を主張するものではありません。むしろ、「士業の AI 導入が抱える3つの壁(守秘義務・属人化・複数 SaaS 連携)が、業務・技術・運用の3軸横断を必要とする構造を持っている」という、ドメイン側の特性に由来する観察です。
逆に言えば、3つの壁のいずれかを既に解いている事務所——たとえば情シス機能を内製化している大規模事務所、業務マニュアル化が進んでいる事務所、SaaS 連携を社内エンジニアが担える事務所——では、FDE 的役割の必要性は相対的に下がります。導入判断の出発点は「FDE が必要か」ではなく、「自所が3つの壁のうちどれを未解決のまま抱えているか」を点検することのほうが、実態に合った視点だと整理しておきたい場面です。
事務所の AI 活用は、ツールの優劣ではなく「守秘義務のある現場業務に、確率的な仕組みをどう溶け込ませるか」という設計問題に行き着きます——これが士業ドメインで観察されている構造です。
参考
- Forward Deployed Engineers — The Pragmatic Engineer (2025-08-12): https://newsletter.pragmaticengineer.com/p/forward-deployed-engineers
- 生成AIサービスの利用に関する注意喚起等について — 個人情報保護委員会 (2023-06-02): 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 (参考リンク)