AIで作った社内システムを別のAIに引き継ぐとき、
何を残すべきか

AIを使って社内システムを作ると、完成までの速さに比べて、判断の記録が不足しがちです。しかし、次のAIや担当者が必要とするのは、コードの説明だけではありません。「誰が何を入力するのか」「なぜこの確認を残したのか」「どこまで変更してよいのか」を、実際に動かして確認できる形で引き継ぐことが重要です。

引き継ぎ資料を書く前に、どのコードと設定が現在使われているのかを確定します。開発途中のファイルや古いバックアップが混在していると、別のAIへ正しい資料を渡しても、違う版を前提に修正されるおそれがあります。

認証情報やAPIキーの値は引き継ぎ文書へ直接書かず、保管場所、管理者、更新方法だけを示します。まず「何が現行版か」を一つに定めることが出発点です。

次に、システムがどの業務を支え、どこから先は人が判断するのかを整理します。機能一覧だけではなく、利用者、入力の開始点、最終的な出力、対象外の業務まで書いておくと、不要な機能追加や誤った自動化を防ぎやすくなります。

AIが生成したコードから、業務上の意図を正確に読み取れるとは限りません。判断記録には結論だけでなく、なぜ採用したのか、変更すると誰に影響するのか、どのような場合に見直すのかを残します。AIの提案と、社内で承認した判断も分けて記録します。

日付順の長いチャット履歴だけでは、確定事項を探しにくくなります。チャットは補足資料とし、承認済みの判断を一覧へ抜き出す運用が適しています。

同じ項目でも、入力した人と最終確定する人が異なる場合があります。項目名だけでなく、情報の出どころ、編集できる人、確定のタイミング、修正時に残す履歴を定義します。

出面管理の例では、職人入力と経理入力を独立させ、差額を可視化するために二重確認を残しています。この仕組みを単なる重複と判断して統合すると、確認の目的まで失われます。二重入力を残す理由と、差額を誰が確認するかをセットで記録する必要があります。

手当、締め処理、集計などは、計算式だけを見ても業務上の根拠が分からないことがあります。通常時の条件に加えて、例外、修正、再計算の扱いまで文章にします。

仕様と実装が一致しているかは、代表的な通常ケース、例外ケース、未入力ケースを用意して確認します。結果だけでなく、「何を正しい結果とするか」も残しておくことが重要です。

引き継ぎ資料は、説明書を読めることではなく、別の担当者がテスト環境を動かせることを基準にします。特定のAIとの会話がなければ再現できない状態を避け、必要な情報を一か所からたどれるようにします。

すべてを一つの文書へ詰め込む必要はありません。最初に読む案内を用意し、業務判断、データ定義、操作手順、テスト、変更履歴へ順番にたどれる構成にします。

動かし方だけでなく、誰がどの情報へアクセスできるかも引き継ぎ対象です。退職者や外部担当者のアカウント、共有アカウント、不要になった連携先が残っていないかを確認します。AIへ資料を渡す場合も、不要な個人情報や認証情報を含めないようにします。

資料を渡しただけでは、引き継ぎ完了とはいえません。作成者以外の担当者が別のAIを使い、資料だけを手掛かりにテスト環境を動かします。質問が集中した箇所は、口頭で補うのではなく文書へ戻して更新します。

運用開始後も、入力方法、計算条件、権限、外部サービスを変えたときは、コードと同時に引き継ぎ資料を更新します。業務判断の記録まで保守対象にすることで、次のAIや担当者が同じ確認を繰り返す負担を減らせます。

本記事は、現場での経験や公開時点で確認できた情報をもとに整理しています。契約・法令・制度・金額などは会社や時期によって条件が異なるため、実際に判断するときは公式情報や専門家へご自身で確認してください。

現場交差点（無料ルーム）

こういう困りごと、現場交差点の無料ルームで相談できます

運営しているのは今も現役の建設事業者です。参加は無料。名刺やQRカードと同じ入口です。

スマホで読み取って参加

関連記事

記事一覧 →

DX・AI活用

建設業の出面管理をAIでアプリ化。 職人と経理の「二重チェック」をあえて残した理由