「導入したAIが半年で誰も触らなくなった」
AI 導入から 1 年程度の士業事務所の代表からは、 「PoC のときは盛り上がったのですが、 半年経ったら誰も AI を触らなくなっていて……」 というご相談を伺うことが少なくありません。 ヒアリングを進めると、 AI ツール自体は契約が継続しており、 利用ガイドラインのドラフトも残っていて、 初期に作ったプロンプト集も社内ファイルサーバに置いてある、 という構図が見えてきます。 それでも現場では使われていません。 理由を聞くと、 次のようなお答えが返ってくる傾向があります。
- 「導入時に詳しかった職員が異動してしまって、 誰が触っていいか分からなくなりました」
- 「使っているうちに精度が落ちてきた気がしますが、 誰にどう報告すればいいか分かりません」
- 「新しいモデルが出たそうですが、 切り替えていいのか分かりません」
- 「顧問先データを入れていいルールだったか、 最近自信がなくなってきました」
これらは個別の話に見えて、 構造としては 1 つの問題から派生しています。 運用担当を曖昧にしたまま導入した、 という共通点があります。
導入は契約と初期設定で終わりますが、 AI は「動き始めたあとに半永久的に運用が続く資産」 です。 誰が責任を持って維持・更新するかを明示しないと、 属人化と陳腐化が同時に進むケースが繰り返し観察される、 と整理しておきたい場面です。
担当を決めないと派生する 3 つの状態
属人化 導入時に旗を振った職員に運用が集中すると、 その人が休んだり辞めたりした瞬間に、 AI に関する判断ができなくなります。 どのプロンプトが現役で、 どれが廃止されたか分かりません。 どの顧問先のデータを入れる前提だったか思い出せません。 ログイン情報・API キー・契約条件が引き継がれていません。 「あの人に聞かないと分からない」 状態は、 IT スキルの問題ではなく、 意思決定権限と運用知識をその人に集約してしまった構造の問題と言えます。
陳腐化 生成AIは半年〜1年単位でモデル・料金体系・利用規約・推奨される使い方が動きます。 運用担当が決まっていないと、 これらの変化に追随する人がいません。 モデル更新で出力傾向が変わったのにプロンプトを直す人がいません。 利用規約改定でデータ学習の扱いが変わったのに契約条件を読み直す人がいません。 新機能 (音声入力・ファイル読み込み等) が解禁されたのに業務に組み込む人がいません。 結果として、 「なんとなく使えるのですが、 最初の頃ほど効いていない気がする」 状態に陥り、 半年後には誰も触らなくなる、 という流れが繰り返されます。
初動の空白 AI を使った業務で問題が起きたとき ——たとえば誤った情報を顧問先に送ってしまった、 顧問先データを別の顧問先の参照結果に混入させてしまった、 外部公開してはいけない情報を生成結果に含めてしまった ——のような事態で、 誰がエスカレーション先になるかが決まっていないと、 初動が大きく遅れます。 士業事務所では、 守秘義務違反に該当しうるインシデントは時間との勝負になるため、 「AI 起因の問題が起きたら、 まずこの人に連絡する」 を所内で共有しておく必要があります。
3 層モデル: 業務・技術・セキュリティに分ける
運用担当を「IT 担当」 のように 1 つの肩書きに集約しようとすると無理が出ます。 AI の運用は性質の異なる判断が同居しているため、 3 層に分けて設計する考え方が現実的です。
業務理解者 (Business Owner) 役割は、 自所の業務フロー・顧問先業種・実務慣行の知識をもって「どこに AI を当てると効くか」「何を変えてはいけないか」 を判断することです。 想定人物は所長・幹部・現場リーダーのいずれかになります。 主な仕事は、 AI に任せる範囲・任せない範囲の決定、 生成結果のレビュー責任者の指名、 顧問先ごとの「入れていい情報・ダメな情報」 の運用判断、 業務側からの改善要望の吸い上げです。 ここを所内に置けないと、 AI は「動くのに現場で使われない」 状態になります。
技術担当 (Tech Owner) 役割は、 AI サービスの選定・契約・初期設定・モデル更新・他システム連携を担うことです。 想定人物は IT 担当兼任の職員、 情報システム委託先、 外部の技術パートナーになります。 主な仕事は、 サービス契約条件・利用規約変更の追跡、 プロンプト・テンプレートの管理と更新、 他システム (会計 SaaS・案件管理・ファイルサーバ) との連携、 障害発生時の一次対応・ベンダー問い合わせです。 小規模事務所では外部委託でカバーする選択肢があります。
セキュリティ責任者 (Security/Compliance Owner) 役割は、 個人情報保護法・各士業法の守秘義務・所内ガイドラインに照らして、 AI 運用がコンプライアンス上問題ないか継続的に確認することです。 想定人物は所長・幹部・コンプライアンス委員・場合により外部顧問になります。 主な仕事は、 入力データの選別ルール・権限設計の点検、 監査ログ・操作ログのレビュー、 インシデント発生時のエスカレーション窓口、 退職者・異動者のアカウント棚卸しです。
この役割は技術担当と分けるほうが望ましいと考えています。 技術担当に「自分の設定を自分でチェックする」 を兼ねさせると、 第三者点検が機能しなくなる懸念があるためです。
なお、 「組織として AI のリスクを管理する」 考え方は、 海外のフレームワークでも整理されています。 役割・責任・説明責任を組織として明文化することがガバナンスの要素として挙げられており、 3 層モデルを設計する際の参考になる枠組みです。 詳細は公式情報をご確認のこと。
規模別の兼任パターン
「3 層を全部別の人に割り当てるなんて、 うちの規模では無理」 というご反応はもっともです。 実際には、 規模に応じた兼任パターンが取られているケースが多くあります。
| 規模 | 業務理解者 | 技術担当 | セキュリティ責任者 | 兼任の目安 |
|---|---|---|---|---|
| 5〜10名 | 所長 | IT兼任職員 or 外部委託 | 所長 (業務と兼任) | 所長が2層を兼任 |
| 10〜30名 | 業務リーダー | IT担当 or 外部委託 | 所長または幹部 | 3層を別人に分離 |
| 30名超 | 業務リーダー | IT担当 or 外部委託 | 専任 or 委員会 | セキュリティ責任者の専任化 |
5〜10 名規模: 所長が業務理解者とセキュリティ責任者を兼ねるパターンです。 技術だけ外に出す形になります。 注意点は、 所長が忙しすぎてセキュリティ点検が形骸化しないように、 月 1 回程度の点検タイミングを明示的に決めることです。
10〜30 名規模: 業務リーダーを立てて、 所長はセキュリティ責任者として最終承認の位置に置く、 という形が成立しやすくなります。 この規模になると、 所長が日常的に AI の細部まで見るのは難しくなります。
30 名超: 組織内に複数の事業部・拠点がある場合、 セキュリティ責任者を専任化する、 もしくはコンプライアンス委員会に組み込むことが選択肢になります。
いずれの場合も、 「誰が何を判断するか」 を文書化して所内で共有することが共通の要素です。 口頭での合意は半年後には消えてしまいます。
引き継ぎ・教育・セキュリティの設計
属人化を防ぐには、 運用知識を 3 層の役割ごとに文書化して回せる状態にしておく必要があります。 最低限揃えておきたいのは、 次のようなドキュメントです。
- 業務理解者向け: AI に任せる業務範囲・レビュー責任の所在・顧問先別の入力ルール
- 技術担当向け: 契約条件・アカウント一覧・プロンプト集・モデル切替時の確認手順
- セキュリティ責任者向け: 監査ログの確認手順・インシデント時の連絡経路・退職時のアカウント停止手順
これらは「立派なマニュアル」 である必要はなく、 A4 で 1〜2 枚の手順書でも十分機能します。 重要なのは、 担当者が変わったときに次の人が読める形にしておくことです。
教育設計についても、 3 層で求めるリテラシーが違います。 全員に同じ研修を受けさせるより、 層ごとにフォーカスを変えるほうが効率的です。 業務理解者には「どの業務を任せるか」 の判断軸、 技術担当には「契約条件の読み方とログの取り方」、 セキュリティ責任者には「インシデント時の判断フロー」 を、 それぞれ年 1〜2 回更新するイメージになります。
AI 運用のセキュリティは、 IT セキュリティ (パスワード・通信暗号化等) だけでは足りません。 入力データの選別、 守秘義務との整合、 モデル契約、 権限設計、 監査ログ、 インシデント連絡経路 ——これらが層ごとに割り振られていることを確認してください。
行政や監督官庁が公開している注意喚起・AI 事業者向けガイドラインの整理は、 セキュリティ責任者が年 1 回程度参照する基準として置いておきたいところです。 事務所単体ですべてを満たすのは難しい場合でも、 自所の運用が現行ガイドラインの方向性とずれていないかを定期確認する役回りが必要になります。 具体的な参照先は公式情報をご確認のこと。
観測仮説
ここまで整理したうえで、 筆者が観測している仮説をいくつか書いておきたいと思います。 確信は持っていませんが、 複数事務所で共通して見えるパターンです。
仮説 1: 「3 層のうちセキュリティ責任者が最初に手薄になる」 業務理解者と技術担当は導入時から名前がつく傾向にありますが、 セキュリティ責任者は「なんとなく所長」 で曖昧に放置されがちです。 結果として、 監査ログの定期レビューが回らず、 退職者のアカウント棚卸しが遅れます。 セキュリティ責任者を明示的に名前で書き、 月 1 回の点検タイミングをカレンダーに入れることが、 この層を機能させる起点になる、 と見ています。
仮説 2: 「導入半年でモデル更新を見落とした事務所は、 そこから取り戻すのが難しい」 モデル更新による出力傾向の変化を半年見逃すと、 プロンプト集が全体的に陳腐化します。 そこからプロンプト集を全件更新するコストは、 初期構築コストと変わらない規模になります。 月 1 回の「モデル更新追跡」 を技術担当の役割に明示しておくことで、 この事態は回避できる、 と整理しておきたい場面です。
仮説 3: 「兼任パターンは正しく書けるのに、 兼任時間が確保されない」 規模別の兼任パターンは表として書きやすいのですが、 実際に兼任した職員に「AI 運用に月何時間使えるか」 を聞くと、 ゼロに近い回答が返ってきます。 役割を割り振るだけでなく、 各層に「月 N 時間を確保する」 と明文化することが、 兼任が形骸化しないための条件と見ています。
これらの仮説は、 もう少し事例を積んで検証する必要があります。 一方で、 「役割を割り振っただけで終わる」 と「役割の稼働時間を確保する」 のあいだに、 運用継続率の差が見えそうだ、 という方向性は今のところ揺らいでいません。