生成AI製の社内ツール引き継ぎ書｜作者のアカウント失効前に残す7項目

社員が生成AIで作った社内ツールを、異動後も部署で使いたい。ところが、作者のアカウントが変わると何が止まるのか、情シスにも部門長にも分からない。この場面では、画面の使い方とソースコードに加え、仕事の受け渡しを記録した引き継ぎ書が必要です。

社内ツールの属人化をほどくには、目的、入出力、データの置き場、権限、失敗時の止め方を先に確かめます。そのうえで、実行条件と引受人をそろえ、作者が抜けても仕事をつなげる状態を目指しましょう。以下は、異動に伴って個人のアカウントや端末が使えなくなる前に残す7項目です。

記入例には「申請CSVから必須欄の不足を抽出するツール」を使います。説明のための架空の例であり、導入事例ではありません。

1. 用途と締切：止まると誰の仕事に影響するか

冒頭には、利用する部署、対象の仕事、実行するタイミング、結果を待つ人を書きます。「申請を効率化する」だけでは範囲が広いため、「受付担当が申請CSVを読み込み、不足欄のある行を担当者へ戻す」と、前後の行動まで具体化してください。申請を承認する判断は、人に残すと明記します。

作者に聞きたいのは、操作説明から抜けやすい仕事です。入力前に別の一覧を確認していないか、出力後に電話で補足していないか。その確認を省いたまま引き継ぐと、同じボタンを押しても、次の担当者へ正しく仕事が渡りません。普段の作業を入力の受け取りから結果の受け渡しまでたどります。

また、「開発時だけ生成AIを使った」のか、「稼働中も外部のAIサービスを呼ぶ」のかを分けます。前者なら通常のプログラムとしての実行条件、後者なら送信データやAPIの契約も確認対象です。

残す欄：用途／利用者／対象外の判断／実行頻度／後工程の締切／使えない場合の手作業と担当。止まっても翌日に回せる仕事と、締切前に代替が必要な仕事を区別します。

2. 入出力の見本：後任が結果を照合する材料

入力ファイルと期待する出力を対にして保管します。CSVなら列名、文字コード、日付の書式、空欄や重複の扱いも必要です。画面のスクリーンショットだけでなく、後任が試せる見本を残しましょう。見本には実データをそのまま複製せず、社内で利用を認めたテストデータを使います。

申請の例なら、必須欄が埋まった行、不足がある行、同じ申請が重複した行を用意します。出力のどの行に不足が表示されるか、重複は除くのか警告するのかを説明してください。「処理が完了しました」という表示と、業務上正しい結果になったことを分けて確認するためです。

稼働中に生成AIを呼ぶ場合は、文章の完全一致だけを合格条件にせず、必ず拾う項目、見落としてはいけない状態、人が原文と照合する箇所を決めます。反対に、金額や申請番号など完全一致が必要な値は、その条件を曖昧にしません。

残す欄：入力の入手先／入力仕様／正常と例外の見本／期待する出力／照合方法／結果を受け取る人。空の出力についても「対象なし」と「読取失敗」をどう見分けるかを書きます。

3. 保存場所：異動で消えるファイルを分ける

原本、取り込み用の複製、出力、ログ、一時ファイルを分け、それぞれの保存場所と管理者を記載します。共有フォルダに結果があっても、元の一覧が作者の端末だけにあるなら、その端末の返却が仕事の停止につながる可能性があります。ファイル名に加え、組織として管理する場所への経路を示しましょう。

「原本→読み込み→一時保存→結果の保管→担当者への受け渡し」と書き、外部サービスへ送る箇所には送信する項目を付けます。ログにも入力内容を残していないか確認します。生成AIを実行時に使うツールでは、どの情報が社外に送られるかを社内のデータ取扱方針と照合してください。

保管先を移す場合は、後任が移管先から開けること、実行設定が古い場所を見続けていないことを確認します。削除する時点と担当、戻すためのコピーの有無も残します。APIキーやパスワードの値は引き継ぎ書に貼らず、認められた保管先と利用申請の窓口を書きます。

残す欄：データの種類／保存先／所有者／閲覧範囲／外部への送信先／保存・削除の担当／復元用データの所在。

4. 所有者と接続：名義変更と再認証を分ける

アプリの所有者、処理を実行するアカウント、メールやストレージとの接続、契約の管理者を別々に記載します。画面を共有しただけで、裏側の接続まで移ったと判断しないことが大切です。異動で削除される権限と、引き続き必要な権限を管理者と確認します。

たとえばMicrosoftは、Power Automateで所有者が不在になったフローの管理方法で、元の利用者アカウントに紐付く接続によって処理が失敗し得ることを説明しています。共同所有者を追加する手順も示されています。引き継ぎ書でも、所有者の欄と、各接続が誰の認証を使うかの欄を分けておきましょう。

作者のIDとパスワードを後任に渡す方法で済ませず、社内方針とサービスの仕様に沿って所有者や接続を切り替えます。必要な利用権や契約も確認し、後任の権限で実行できた記録を残してください。作者のアクセス削除は、移管先の動作確認と順序をそろえます。

残す欄：対象サービス／所有者／接続の認証主体／必要な権限／変更の承認者／切替日／後任での確認結果。

5. 起動元と現行版：作者の端末を閉じても動くか

起動する端末やサーバー、起動方法、定期実行の設定場所、現在動いている版を記録します。作者の端末を閉じると処理できない場合は、会社で認めた実行先へ移すか、当面は手作業へ戻すかを決めます。移す予定があることと、移した先で動いたことを別の状態として扱ってください。

コードの正本、必要なソフトとライブラリ、設定項目名、外部API、費用の確認先も残します。AIへの依頼文や会話履歴は背景説明として整理し、現行のコードと設定を特定できる情報に結び付けます。後任が変更する際は、検証用の場所で入出力の見本を通してから反映します。

英国Home Officeの2026年3月20日更新のAI利用に関する技術標準は、AI支援の成果物を本番前に人がレビュー・承認し、変更を開発工程で追跡できるようにすることを求めています。以下で触れる英国行政機関の基準や取り組みは、日本の民間企業への法的義務を示すものではありません。権限、データ、契約の扱いは自社の規程に合わせます。

残す欄：起動元／起動手順／コードの正本と稼働版／必要なソフト／設定の管理場所／変更の確認者。環境や依存先を含む保守移管の詳細は、担当交代時に保守へ必要な情報をそろえる方法も参照できます。

6. 停止と再開：処理途中の申請を取り残さない

失敗時には、再実行する前に止める対象を確認します。新しい入力の受け付け、次回の定期起動、すでに実行中の処理は別です。定期起動を切っても実行中の処理が続く構成なら、その状態を確認する場所と、誰が停止を判断するかを記載します。

申請CSVの例では、入力が想定外の書式だった、出力を保存できなかった、不足一覧が空なのに読取件数も確認できない、といった状態を後工程へ渡さない条件として挙げます。「エラーが出たら連絡」だけで済ませず、結果を利用してよいと判断できない場合も止める対象にします。

続いて、未処理と処理済みの見分け方、途中まで書き込まれたデータ、再実行による二重登録の有無を確認します。後任が区別できなければ、再実行せず技術窓口へ引き渡す手順を残しましょう。停止中に誰が手作業を行い、どの記録を使って後から照合するかも必要です。

残す欄：停止する条件／停止箇所と操作権限／処理状態の確認先／未処理一覧／手作業への戻し方／再開の承認者。異常の再現や停止操作は、許可された検証環境で確認し、本番で故障を起こして試すことは避けます。

7. 受領判定：異動日までに確かめたことと保留すること

最後の欄には、異動日以降の業務担当、技術的な相談先、費用の管理者を記載します。部門長は用途と結果の妥当性、情シスなどの技術担当は実行先・データ・権限を確認する、と役割を分けます。後任にコードをすべて理解させる前提にせず、どの範囲を受け持てるかで判断します。

後任自身のアカウントで保存場所へたどり、正常と例外の見本を使って出力を照合します。作者は、口頭の補足が必要になった箇所を引き継ぎ書へ戻します。英国Defraが2026年8月3日に公開した開発者育成の取り組みでは、研修を受けた開発者が同僚向けに具体的な使い方を共有し、AIが経験者による支援やペア作業を補うことを重視しています。引き継ぎでも、資料の受け渡しに実演と後任の操作を組み合わせましょう。

「使えた」「失敗した」「未確認」を分け、未確認には影響、代替担当、確認期限を付けます。個人の認証に依存した接続が残るなら、引き継ぎ済みの印を付けず、利用を保留する範囲と手作業に戻す仕事を決めます。

部署としてのルールや教育まで整理する場合は、社内展開の役割分担と定着の進め方が関連します。また、担当交代を継続的な体制づくりとして考える視点は、自社で運用と改善を続ける体制の整理にもつながります。

残す欄：引受人／確認日と資料の版／確認結果／保留事項／代替担当と期限。次にAI化・効率化する範囲を広げるときも、実際の仕事と人の判断をたどり直し、入出力の見本で確かめてから進めます。作者の説明を待たずに、使う・止める・相談する先が分かることを、引き継ぎの完了条件にしましょう。