結論: AI 導入は業務・技術・運用の3点セットで判断する仕事であり、IT 担当者の単独タスクとして閉じてしまうと、射程の届かない領域が必ず残ります。
「ITに詳しい職員に任せた」の半年後に起きていること
AI 導入を社内の特定個人に委ねたままにすると、ある時点で必ず詰まる構造があります。本稿ではその構造を解きほぐしていきたいと思います。
「うちは IT に詳しい職員がいるので、AI もその人に任せています」——この体制は、何も分かる人がいない状態よりは健全な出発点です。ただ、半年から1年経った時点で似たパターンに行き着く事例が観察されています。生成 AI のアカウントは契約済み、社内ガイドラインのドラフトもある、デモも何度かやっている、それでも現場のスタッフは相変わらず手作業で書類を作っており、AI は「詳しいあの人」しか触っていない、という状態です。
問題は IT 担当者個人の力量ではなく、AI 導入を「IT 担当の単独タスク」として閉じてしまう設計の側にあります。AI 導入は業務・技術・運用を横断する課題であり、IT の知識だけでは射程が届かない領域が含まれる、という構造上の理由によるものです。
IT 担当者だけに任せると現れる3つのパターン
事務所の IT を兼任で見ている職員に AI 導入を委ねた場合、次のようなパターンが観察されます。
業務理解が抜け落ちます。IT 担当者は「動くもの」を作るのは得意でも、「どの業務のどこを変えるべきか」という判断は、現場の実務を熟知していないと組み立てにくい領域です。税理士事務所で「仕訳の自動化を試したい」となったとき、IT 担当者が OCR と生成 AI を組み合わせて領収書を読ませる仕組みを作っても、「どの勘定科目に寄せるかは顧問先ごとの会計方針に依存する」「期末調整との兼ね合いで、ここは絶対に手で確認する」といった業務側の前提が抜けると、現場では使われずに終わってしまいます。
運用設計が後回しになります。IT 担当者の関心はしばしば「動くかどうか」に集中しがちです。一方、AI 導入で問われるのは「動いた後にどう運用するか」のほうです。誰がプロンプトを承認するか、どの顧問先データは AI に投げてよいか、生成結果のレビュー責任は誰が持つか、ログは誰が点検するか、スタッフが AI に依存しすぎたとき誰が止めるか——これらは技術的に「実装」する話ではなく、組織として「決める」話であり、IT 担当者単独では決められない領域を含んでいます。
属人化します。「あの人に聞かないと AI のことは分からない」状態になると、IT 担当者が抜けた瞬間にプロジェクトが止まってしまいます。初期段階では仕方ない側面もありますが、半年・1年経ってもこの状態が続くようなら、組織の運用に乗っていないサインだと考えられます。属人化は技術スキルの問題ではなく、意思決定を一人に集中させてしまった設計に起因するものです。
3つはそれぞれ独立に見えますが、構造的には連動しています。業務理解の欠落が運用設計の後回しを生み、その曖昧さが意思決定の一極集中を許し、結果として属人化が固定化する、という連鎖を起こします。早い段階で連鎖の起点を断たないと、半年単位で修正が効きにくい状態に進んでしまいます。
業務・技術・運用の3点セットを噛み合わせる
AI 導入で観察される構造は、業務・技術・運用の3領域を横断する判断が必要だ、というところに収斂していきます。各領域で問われる論点を整理しておきたいと思います。
業務（Business）。自所の業務フロー（受任 → ヒアリング → 書類作成 → 提出 → 顧問先報告）のどこに時間がかかっているか。顧問契約・スポット案件・補助金申請といった収益構造の中で、AI 化で実際に効くのはどこか。スタッフ・所長・顧問先の「何を変えてはいけないか」「何を変えたいか」。ここを言語化できるのは所長や現場リーダーであり、IT 担当者単独で決められる領域ではありません。
技術（Technology）。生成 AI サービスの選定（無料・法人プラン・API 利用）と、データの学習利用に関する契約条件の確認。既存システム（会計 SaaS・案件管理・ファイルサーバ）とのつなぎ方。LLM の確率的な振る舞いを前提とした、チェック・差し戻し・ログ取得の組み込み。ここは IT 担当者・ベンダー・外部の専門家の領域となります。
運用（Operations）。個人情報・守秘義務の取り扱いルール。スタッフのオンボーディング・教育。監査ログ・操作ログを残す仕組みと、内部統制への組み込み。入退職時のアカウント棚卸し。所長・幹部の意思決定と現場のオペレーションを噛み合わせる必要がある領域です。
3点セットは、いずれかが先行すると他が空回りしやすい関係にあります。たとえば技術選定だけ先行して契約してしまうと、運用ルールが追いつかないまま現場が触り始め、入力してはいけないデータが混入する事故につながりかねません。逆に運用ルールだけ作って技術選定を後回しにすると、書面上は整っているけれど現場では別ツールがこっそり使われている、という乖離が起きてしまいます。3領域を同じ時期に立ち上げる、という設計だけが、PoC から本番運用への移行を実現する道筋になります。
加えて、士業事務所特有の論点として、業法上の守秘義務、複数顧問先を抱えることに起因する利益相反、有資格者が判断責任を負うという専門判断の構造があります。弁護士法・税理士法・社労士法・行政書士法はそれぞれ守秘義務を課しており、「便利だから」で顧問先の固有情報を生成 AI に投げる前に、入力する情報の範囲・保存期間・第三者提供の有無を確認する必要があります。生成 AI サービスへの個人情報入力にあたっては、利用目的の達成に必要な範囲かを事前に確認することが求められており、所管行政の最新の注意喚起を確認しておくのが安全です。最終的に書類に判子を押すのは有資格者であり、生成 AI が下書きを作っても、税務判断・法的判断・登記判断の責任は人にあります。これらは IT スキルだけでは判断できず、業法・倫理規程・実務慣行の理解と組み合わせて初めて運用設計が成立します。
規模に応じた体制設計の選択肢
IT 担当者だけに任せない体制とは具体的にどんな形になるのでしょうか。事務所の規模に応じて、いくつかの選択肢があります。
| 体制 | 想定規模 | 主な担い手 | 弱点 |
|---|---|---|---|
| 兼任体制 | 〜10名 | 所長 + IT 担当 + 業務リーダー | 本業の合間で動くため進捗が遅れやすい |
| 専任体制 | 20〜50名 | AI 推進担当（兼任可） | 専任化のコスト・採用難易度 |
| 外部伴走 | 規模問わず | 期間限定の外部支援 | 内製化に向けた引き継ぎ設計が必須 |
兼任体制（小規模事務所向け）。所長 + IT 担当 + 業務リーダーの3者で AI 推進チームを組みます。月1回程度の定例で、業務側の困りごと・技術側の進捗・運用ルールを擦り合わせます。専任は置かず、それぞれが本業の片手間で見る形です。10名未満ならこの体制で回るケースがありますが、重要なのは「IT 担当に丸投げしない」体制を明示することです。
専任体制（中規模事務所向け）。AI 推進担当を1名置きます（IT 担当兼任でも構いません）。業務理解のための現場ヒアリング・運用ルール策定の時間を、業務として割り当てます。所長・幹部との定例会で意思決定ラインを確保します。20〜50名規模になると、片手間では回らなくなる傾向があります。
外部伴走の活用。業務・技術・運用を横断する外部の支援を期間限定で入れる選択肢もあります。自所の体制が立ち上がるまでの伴走役として、PoC から本番運用への移行が止まっている局面で検討する設計です。役割設計の詳細は FDEとは何か で扱っています。
セキュリティの観点でも、IT 担当者だけに任せると技術的なセキュリティ（パスワード強度・通信暗号化など）は押さえられても、業務運用上のセキュリティが手薄になりがちです。入力データの選別、モデル提供事業者との契約条件、権限設計、監査ログ、生成結果のレビュー工程、インシデント時の連絡経路——これらは IT 担当者だけでは決められず、所長・幹部・業務リーダーを巻き込んで決めるべき論点になります。運用担当・責任者の置き方は AI運用担当者をどう任命するか も合わせてご参照ください。
抜けやすい点
体制を見直すときに、特に抜けやすい論点を3つ挙げておきたいと思います。
意思決定ラインが書面で示されていません。「AI 関連は IT 担当に任せている」という暗黙の了解だけで運用が回っている場合、IT 担当者が退職した瞬間に決定権の所在が分からなくなってしまいます。AI 推進の最終意思決定者と、業務領域ごとのレビュー責任者を、組織図上に明示しておく必要があります。
契約条件が IT 担当者だけの手元に閉じています。利用している AI サービスがデータを学習に使う設定なのか、解約時にデータが削除されるのか、インシデント時の通知 SLA はどうなっているのか——これらは所長・幹部もリスクを把握しておく対象です。契約書を IT 担当だけが読んで終わると、判断の質が下がってしまいます。
ログの点検が誰のタスクにも入っていません。AI のログを取る設定はしてあるけれど、定期的に見返す担当が決まっていない、というのは観察される頻度が高いパターンです。月次・四半期で誰がどのログを点検するか、点検の結果をどこに報告するかを、運用フローに組み込んでおく必要があります。点検サイクルがないと、ログは「集めただけ」の状態にとどまり、インシデント時に初めて見返す資源になってしまいます。事前点検と事後参照では、ログから読み取れる情報量に大きな差が出てきます。
加えて、IT 担当者の負荷管理も忘れやすい論点になります。AI 推進を「兼任の片手間」で進めると、本業の手が止まる時期が必ず来ます。所長・幹部が業務として工数を割り当て、進捗を四半期単位でレビューする体制を整えないと、担当者の燃え尽きと共にプロジェクトが止まってしまいます。「任せた」と「丸投げした」の差は、工数の割り当てと進捗レビューの有無にあると整理しておきたい場面です。
IT に詳しい職員に任せる選択は、健全な出発点として機能します。一方で、業務理解・運用設計・専門判断まで一人で抱えさせる構造は、半年から1年のスパンで必ず限界に達してしまいます。事務所側で「IT 担当者の単独タスクにしない」設計を、最初の段階から明示しておくことが要となります。
関連記事
- FDEとは何か
- AI運用担当者をどう任命するか
参考
- 生成AIサービスの利用に関する個人情報の取り扱いについては、所管行政（個人情報保護委員会等）の公式情報を確認のこと
- Forward Deployed Engineer の概念については、関連する技術系メディアの公開情報を確認のこと