ある士業事務所で、こんな話を伺ったことがあります。書類のドラフト・メール返信案・議事録要約をChatGPTで下書きする運用が、中堅の職員の方の試行錯誤で組み上がっていて、所内では「便利になった」という評価が定着していたそうです。
これは仮想ケースですが、特定の事務所の実話ではなく、守秘の観点も踏まえて再構成した典型的な状況です。
その職員の方が退職されたとき、いくつかのことが同時に起きました。プロンプトがどのアカウントに保存されているか、外部サービスとの連携設定はどこにあるか、エラーが出たときに何を見ればよいか — 引き継ぎ資料がほぼ残っておらず、結果として動いていた仕組みが一度ゼロに戻る形になりました。
業務システム全般に共通する話ではありますが、業務の一部にAIを入れた場面で、似たような流れが見えてくることがあります。本稿は、なぜそうした場面が起きやすいのか、どんな運用を取っている事務所があるのかを、現場でよく見る順にご紹介します。
属人化が進みやすくなる場面
AIそのものが属人化を生むわけではありません。ただ、業務の一部にAIを入れた場面で、特定の方に知識が集まりやすくなる動きがいくつか見えてきます。
一つは、プロンプトが暗黙知になっていく動きです。実務で使えるプロンプトは何度も試行錯誤を重ねて生まれます。「この言い回しでハルシネーションが減る」「この順序で指示すると引用元を返す」といった工夫は、本人の中に蓄積されていきがちで、文書化されないまま運用に組み込まれることが多いようです。
もう一つは、連携設定が複数のサービスに散らばる動きです。生成AI、RPA、スプレッドシート、業務システムを束ねた瞬間に、APIキーの所在・Webhookの宛先・認証情報の管理者が複数サービスに分かれます。全体像を把握しているのは設定した方だけ、という形になりやすいです。
最後に、稼働後に他の方が手を出しにくくなる動きです。AIを含むワークフローは内部の動きが見えにくいぶん、動き始めた後は他のメンバーがレビューや修正に入りにくくなることがあります。
それぞれ単独でも引き継ぎを難しくしますが、重なると後任の方が「動いている結果」しか見られない、という場面につながります。
引き継ぎ時に失われやすい情報
引き継ぎが滞る場面では、いくつかの層の情報が同時に失われていることが多いです。
- プロンプト本体：どのサービス・どのアカウントに、どのバージョンが保存されているか
- モデル・パラメータ設定：使用モデル、温度、最大トークン数、システムプロンプトの並び順
- 連携先と認証情報：クラウドストレージ・業務システム・メールツールへの接続、トークンの有効期限、再発行手順
これらが個人のアカウント・個人のメモ・個人の頭の中に分かれていると、後任の方は「動いている結果」しか見ることができません。コードのように差分管理されにくいので、変更履歴の追跡もしづらく、修正に時間がかかりやすくなります。
知識を「人」から「文書」と「仕組み」に移す運用例
引き継ぎやすくするために、いくつかの層を分けて整備している事務所があります。
プロンプト集（ライブラリ）
業務カテゴリごとに、タイトル・用途・入力例・期待出力・想定リスクをセットで台帳にしておきます。所内で参照できる場所（イントラ、Notion、SharePointなど）に集約し、改訂履歴を残せる形にしておく事務所もあります。
運用手順書（ランブック）
「メール返信ドラフトを作るときは、このプロンプトを、このアカウントで、こう実行する」というレベルで、誰でも追体験できる手順を残します。スクリーンショットや短い動画を併用すると、口頭の引き継ぎなしでも再現しやすくなることが多いです。
例外対応ログ
AIが誤った出力をしたとき、外部APIが落ちたとき、引用元が確認できなかったとき — こうした出来事を時系列で記録しておきます。将来のトラブル対応の素材になりますし、AIを業務に入れたときの限界を事務所として学んでいく材料にもなります。
3つの層を分けておくと、「設定した人しか知らない」状態から「文書を読めば追える」状態へ、知識の置き場所を移しやすくなります。
教育とローテーション
文書を整えるだけでは引き継ぎが進まないことがあります。文書を読むだけで実務が動かせるなら、もともと属人化していない状態だからです。
業務システム全般で取られている運用を、AIを含むワークフローにも当てはめている事務所があります。
- 二人体制：主担当と副担当を設定し、副担当も月数回は実運用に触れる
- ローテーション：半期〜年単位で主担当を入れ替える
- 所内勉強会：月1回程度、活用事例と失敗事例を共有する場を作る
- 新任の方向けハンズオン：入所時のオンボーディングに、AIツールの基本操作と避けたい運用を含める
AIを含むワークフローでは「触れる人が少ない」状態が続きやすいので、ほかのシステムよりも意識的にローテーションを設計している事務所が多いように見えます。
ローテーション設計でつまずきやすい場面
ローテーション自体は分かりやすい仕組みですが、実務に落とすと細部で詰まりやすい場面があります。
一つは、副担当の方が「研修期間」で終わってしまう場面です。月数回は触れる設計にしたつもりでも、忙しさにかまけて主担当に作業が偏戻りし、副担当の手が動かなくなることがあります。月次の業務カレンダー上で副担当の方の作業時間をブロックしておく運用を取っている事務所もあります。
もう一つは、引き継ぎ期間の長さを見誤る場面です。AIを含むワークフローは「触れば分かる」性質ではなく、「触ってみて、誤動作を経験して、原因を追って」初めて理解が定着しやすいです。最低でも数週間〜1か月は重複稼働の時間を取っている事務所もあります。
最後に、評価制度との不整合の場面です。「自分しか触れない仕組みを作った人」を高く評価する文化が残っていると、属人化を解こうとする副担当の方のモチベーションが続きにくくなります。共有設計の改訂回数や、後任の方の独立稼働開始までのリードタイムを、ローテーション制度と一緒に評価軸に組み込んでいる事務所もあります。
AIを含むワークフローでは特に「触れた時間」が品質に直結する場面が多いので、設計段階で時間配分を明示的に組み込んでおくと、形だけのローテーションになりにくいです。
セキュリティ・コンプラの観点
属人化が進む場面は、セキュリティ・コンプラの観点でも論点になります。
個人情報保護委員会は2023年6月2日付で「生成AIサービスの利用に関する注意喚起等」を公表していて、個人情報を取り扱う事業者が生成AIサービスに個人情報を入力する場面の留意点を示しています（参考1）。利用目的の特定、本人同意、第三者提供の論点などが整理されていて、依頼者の機微情報を扱う士業事務所では押さえておきたい一次情報です。
知識が特定の方に集まったままだと、これらの留意点が「分かっている人」の頭の中にしか存在しないことになり、事務所として遵守状況を確認しにくくなります。具体的には次のような場面が見えやすくなります。
- 入力データの管理が追えない：依頼者の個人情報・機微情報が、どのAIサービスに、いつ、誰によって入力されたかが分からない
- アカウント・権限が残り続ける：退職された方のアカウントが残り、外部サービスへのアクセスが切れていない
- ログが残っていない：誰がいつ、どのプロンプトで、どんな出力を得たかの記録が残っていない
- 守秘義務の境界が担当者ごとに揺れる：依頼者情報を入力してよい範囲が、担当者の方ごとに違う運用になっている
AI利用に関する事務所内ルール、アカウントの棚卸し、ログの保存方針を文書にしておき、属人化していないかを定期的に点検する運用を取っている事務所もあります。属人化対策とコンプラ対策は、同じ仕組みの裏表として動くことが多いように見えます。
残りやすい論点
共有設計の整備、ローテーション、コンプラ視点での点検 — いずれも取り組みやすい仕組みです。実務で詰まりやすいのは、これらを誰が継続するかという責任の置き場の話です。
- 共有設計の更新を、最初に設定した方以外の方にも担ってもらえる形になっているか
- ローテーションが「研修期間」ではなく「実運用期間」として動いているか
- 失敗事例を共有することへの心理的な抵抗感を、評価制度や場づくりで和らげられているか
業務の一部にAIを入れた後、その仕組みが事務所の資産として定着していくかどうかは、ツールの選び方よりも、この3点の運用設計に左右されることが多いように見えます。
参考
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等」（2023年6月2日公表）https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/
- 独立行政法人情報処理推進機構（IPA）「DX動向2024」（2024年6月27日公開）https://www.ipa.go.jp/digital/chousa/dx-trend/dx-trend-2024.html