生成AIの社内運用は、少し回りはじめた頃に担当者が変わることがあります。
異動、退職、兼務変更、繁忙期の一時交代。
小さな会社では、AI担当者が専任ではないことも多いです。
だから、担当者が変わること自体は特別な事故ではありません。
問題は、担当者が変わった瞬間に、なぜその運用にしていたのかが消えることです。
「このプロンプトを使ってください」
「このフォルダに実例カードがあります」
「月次レビューはこの議事録を見てください」
ここまでは引き継がれる。
でも、前任者が何に迷い、どこで止め、なぜその確認者を入れたのか。
ここが残っていない。
すると、後任者は手順だけを受け取ります。
手順はあるのに、判断ができない。
これ、けっこうしんどいです。
前任者から見ると「書いてあるやん」と思う。
後任者から見ると「書いてあるけど、どこまで変えていいか分からん」となる。
生成AIの運用は、ツールの使い方だけで成り立ちません。
入力してよい情報。
人が確認する範囲。
社外へ出す前に止める条件。
AIの下書きを採用しない判断。
月次レビューで見つけた改善タスク。
こういう小さな判断の積み重ねで、社内運用になります。
前回、生成AIの改善タスクは、月次レビュー後に1つだけ実行する で、月次レビュー後の改善案は翌月に試せる1つへ絞ると書きました。
今回は、その次の話です。
改善タスクを回しはじめたあと、担当者が変わるときに何を渡すのか。
プロンプトや手順書だけではなく、判断ログをどう引き継ぐのか。
担当者が変わっても、AI活用の月次レビューと改善サイクルを止めないための整理です。
総務省・経済産業省の AI事業者ガイドライン第1.2版 では、AIの活用にあたって、関係者の役割やリスクへの対応を継続的に見直す考え方が整理されています。
IPAの AI利用者のためのセキュリティ豆知識 でも、入力情報や出力結果を利用者が確認する重要性が扱われています。
経済産業省とIPAの デジタルスキル標準 も、AI時代の人材や役割を固定ではなく更新していくものとして示しています。
小さな会社のAI内製化も同じです。
担当者が変わっても、判断の跡が残っていれば続けられる。
逆に、判断が頭の中にしかないと、AI活用はまた最初からになります。
生成AIの担当者交代で渡すべきなのは、プロンプトより先に「なぜ止めたか」「なぜ通したか」の判断ログです。
今日は、生成AIの運用担当者が変わる前に、何をどう引き継ぐと内製化が止まりにくいのかを整理します。
担当者交代は、ツールの権限移管だけで終わらせない
担当者交代で最初に確認されやすいのは、アカウントや権限です。
管理画面に入れるか。
共有フォルダを見られるか。
AIツールの契約や支払いは誰が管理するか。
これはもちろん大事です。
ただ、ここだけで引き継ぎを終えると、AI運用は止まりやすくなります。
なぜなら、権限があっても判断できない場面が多いからです。
たとえば、後任者が問い合わせ返信のAI下書きを確認するとします。
操作はできます。
プロンプトも残っています。
でも、実際にはこういう迷いが出ます。
- お客様名は伏せるが、会社名は入れてよいのか
- 金額が含まれる場合はAIへ入れてよいのか
- AIの文章が自然なら、そのまま送ってよいのか
- 急ぎのとき、確認者を飛ばしてよいのか
- 前任者はどんなときにAI案を使わなかったのか
これは、ログイン権限では解けません。
手順書だけでも足りません。
必要なのは、前任者がどう判断してきたかです。
特に生成AIは、毎回同じ入力になるとは限りません。
同じ問い合わせ返信でも、内容によって個人情報、契約、金額、クレーム、社外送信の重さが変わります。
だから、担当者交代では「使えるようにする」だけでなく、「迷ったときに同じ方向を向けるようにする」必要があります。
権限移管は入口です。
でも、AI内製化の引き継ぎでは、その奥にある判断の移管まで見ます。
「誰がログインできるか」
「誰が最終確認するか」
「どんなときに止めるか」
この3つをセットで渡す。
ここから始めると、担当者が変わっても運用が急に空白になりにくくなります。
引き継ぐ判断ログは、成功例より「止めた例」を先に残す
判断ログというと、成功事例を残したくなります。
このプロンプトでうまくいった。
この下書きが採用された。
この業務で時間が短縮できた。
もちろん、それも大事です。
でも、担当者交代で先に渡したいのは、成功例より「止めた例」です。
なぜなら、後任者が一番迷うのは、進めていいか止めるべきかの境目です。
AIの出力がそれっぽい。
でも、事実確認が足りない。
文章はきれい。
でも、社外に出すには少し断定が強い。
返信案は便利。
でも、顧客情報を入れすぎている。
こういう場面で、前任者がなぜ止めたかを残しておくと、後任者は判断しやすくなります。
ログの形は、きれいな議事録でなくて大丈夫です。
1件につき、次の4つだけで足ります。
- どの業務で使ったか
- 何をAIに任せようとしたか
- なぜ止めたか、または人が確認したか
- 次回はどう直すか
たとえば、こんな感じです。
「問い合わせ返信。お客様の文章をそのまま入れそうになったが、個人名と具体的な相談内容が含まれていたため止めた。次回は要約してから入力する。」
これくらいでいいです。
長い文章はいりません。
むしろ、長くしすぎると続きません。
前任者の頭の中にある「これは危ない気がする」を、後任者が読める形にしておく。
この小さなログが、AI活用の安全柵になります。
生成AIの社内運用は、担当者だけに任せず引き継げる形にする でも書きましたが、AI活用はプロンプトだけを渡しても足りません。
特に担当者交代では、うまくいった型より、止めた理由を残す方が引き継ぎ効果は大きいです。
成功例は真似できます。
止めた例は、事故を減らします。
この順番で見るのが大事です。
改善タスクは、未着手・試験中・定着済みに分けて渡す
担当者が変わるとき、改善タスクを一覧で渡すことがあります。
ただ、一覧だけだと後任者は迷います。
どれが今すぐやるものなのか。
どれが前任者の思いつきメモなのか。
どれがもう現場で使われているのか。
ここが分からないからです。
改善タスクは、状態で分けて渡します。
おすすめは3つです。
未着手。
試験中。
定着済み。
未着手は、まだやると決めていない改善案です。
月次レビューで出たけれど、今月は選ばなかったもの。
これは後任者がいきなり背負わなくていい。
ログとして残し、次回レビューで見る対象にします。
試験中は、今まさに1業務で試している改善タスクです。
たとえば、「問い合わせ返信カードに社外送信前の確認者を追加し、翌月3件で使う」ようなものです。
ここは引き継ぎの中心です。
誰が試しているか。
どの業務で使っているか。
次に確認する日はいつか。
この3つを必ず渡します。
定着済みは、すでに通常運用に入ったものです。
ルールに入れた。
実例カードを差し替えた。
FAQへ反映した。
確認者が決まっている。
ここは「もう完了」と書くより、どこに反映済みかを残します。
この3分類をしておくと、後任者は全部を同じ重さで抱えずに済みます。
AI活用の改善タスクは、見つけた順に全部やるものではありません。
月次レビューで選び、翌月に試し、使われたら定着させる。
担当者交代のときも、この流れを崩さないことが大切です。
新担当者は、最初の1週間だけ操作よりログを見る
新しい担当者が入ると、早く操作を覚えてもらいたくなります。
どのAIツールを使うか。
どこにプロンプトがあるか。
どのフォルダに実例カードがあるか。
管理画面はどこか。
たしかに必要です。
でも、最初の1週間は、操作よりログを見る時間を作った方がいいです。
理由はシンプルです。
操作はあとから覚えられます。
でも、判断の背景を知らないまま操作だけ覚えると、前任者が避けていた失敗を繰り返しやすいからです。
最初の1週間で見るログは、多くなくていいです。
次の3種類だけで十分です。
1つ目は、直近の月次レビューです。
何がうまくいき、何が止まり、次に何を直すと決めたのか。
2つ目は、止めた判断ログです。
どんな入力を止めたか。
どんな出力を採用しなかったか。
どんな場面で人の確認を入れたか。
3つ目は、試験中の改善タスクです。
今月、何を1つ試しているのか。
どの業務で使うのか。
いつ振り返るのか。
この3つを見るだけで、新担当者は「この会社ではAIをどこまで任せて、どこから人が見るのか」をつかみやすくなります。
研修資料を全部読むより、実際のログを数件見る方が早いこともあります。
もちろん、操作説明をゼロにするわけではありません。
ただ、順番を間違えない。
先に判断の地図を見てから、操作を覚える。
この順番にすると、担当者交代後の1ヶ月目が安定します。
AI担当者の引き継ぎは、詳しい人を作るためだけではありません。
迷ったときに立ち戻れる判断基準を共有するためにあります。
権限と確認者は、交代日に小さく棚卸しする
担当者交代の日に、もう1つ見たいものがあります。
権限と確認者です。
ここは後回しにすると危ないです。
前任者のアカウントが残ったまま。
共有フォルダの編集権限が広すぎる。
AIツールの管理者が誰か分からない。
社外送信前の確認者が、異動した前任者のまま。
こういう状態は、すぐに大事故になるとは限りません。
でも、じわっと運用を不安定にします。
担当者交代日に見るのは、大きなセキュリティ監査ではなくていいです。
まずは、次の5つだけ確認します。
- AIツールの管理者は誰か
- 共有フォルダの編集権限は誰にあるか
- 社外送信前の確認者は誰か
- 入力禁止情報を判断する人は誰か
- 事故っぽい出力が出たとき、誰に止めてもらうか
これだけでも、かなり違います。
特に、確認者が前任者のまま残っているケースは多いです。
名前だけ変えればいいように見えて、実際には役割の理解も必要です。
確認者は、文章の誤字を見る人ではありません。
AIの出力をそのまま社外に出してよいか。
個人情報や機密情報の扱いに問題がないか。
事実と違うことを言っていないか。
会社として出す言葉になっているか。
ここを見る人です。
だから、担当者交代時には、確認者にも短く説明します。
「今月はこの改善タスクを試しています」
「この業務では社外送信前に確認をお願いします」
「この条件に当てはまったら止めてください」
この3点だけでも、確認者は動きやすくなります。
生成AIの代理運用は、担当者不在の日を先に想定して整える でも触れたように、代理や確認者が無理をしないためには、止める条件を先に渡すことが大切です。
担当者交代は、権限を広げる日ではありません。
権限と確認者を、いまの運用に合わせて小さく整える日です。
月次レビューのリズムを残すと、担当者が変わっても内製化は続く
担当者が変わると、どうしても一度止まりやすくなります。
引き継ぎで手いっぱい。
通常業務も覚えないといけない。
AI活用の改善は、少し後回しになる。
これは自然です。
だからこそ、月次レビューのリズムを残しておきます。
担当者が変わっても、毎月見る場所が同じなら、運用は戻しやすいです。
見るものは、複雑でなくて大丈夫です。
- 今月使えたAI活用
- 止めたAI活用
- 迷った入力や出力
- 試験中の改善タスク
- 次月に1つだけ直すこと
この5つです。
前任者がいなくても、この型が残っていれば後任者は進められます。
逆に、前任者の記憶だけで回っていた月次レビューは、担当者交代で止まります。
「前はどうしてましたっけ」
「たぶんこうだったと思います」
「じゃあ今月は見送りで」
こうなりやすい。
もったいないです。
生成AIの社内運用は、担当者の能力だけで続くものではありません。
小さなログ。
月1回の確認。
翌月に試す改善タスク。
止める条件。
確認者。
この地味な部品が残っているから、担当者が変わっても続きます。
AI内製化というと、ツールを使いこなす人を育てるイメージが強いかもしれません。
でも、僕はそれだけでは足りないと思っています。
詳しい人がいる会社より、詳しい人が変わっても運用が残る会社の方が強い。
特に小さな会社では、担当者がずっと同じとは限りません。
だから、担当者交代を前提にして、判断ログを残す。
月次レビューのリズムを残す。
改善タスクを状態で渡す。
この3つを持っておく。
それだけで、生成AIの活用は「その人がいたからできたこと」から「会社として続けられること」に近づきます。
生成AIの担当者交代で、まず見るべきなのはツールの権限です。
でも、そこで終わらせない。
前任者が何を止めたか。
何を通したか。
どの改善タスクが試験中か。
確認者は誰か。
次の月次レビューで何を見るか。
ここまで渡して、はじめてAI運用の引き継ぎになります。
完璧なマニュアルを作る必要はありません。
まずは、直近1ヶ月の判断ログを3件だけ残す。
試験中の改善タスクを1つだけ書く。
次回レビューの日付を決める。
このくらいからで大丈夫です。
担当者が変わっても続く運用は、派手ではありません。
でも、社内にAI活用を残すにはかなり効きます。
カタチ舎では、生成AIの社内導入、入力ルールづくり、実例カード、質問ログ、月次レビュー、改善タスク運用、担当者交代時の引き継ぎ設計まで、AI活用を社内に残すための伴走支援を行っています。
「AI担当者が変わると運用が止まりそう」
「プロンプトや手順書はあるけれど、判断理由が残っていない」
「月次レビューや改善タスクをどう引き継げばいいか分からない」
そんな状態なら、まずは今の運用ログと担当者交代時に渡すべき情報を一緒に棚卸しできます。
無料相談はこちら から、今のAI活用の進め方や、社内に残すための引き継ぎ設計について気軽に相談してください。
最初の1ヶ月で、判断ログの残し方、担当者交代時の確認項目、月次レビューへ戻す改善タスクまで一緒に整理します。
Author
村上龍平
カタチ舎代表。言葉、生成AI活用、資料・Web制作を行き来しながら、事業の考えを届く形へ整理しています。