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

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

最初に「いま動いている状態」を固定する

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

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

システムの目的と業務範囲を言葉にする

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

業務判断は「理由」と「見直す条件」まで残す

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

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

入力者、確定者、修正履歴をデータごとに決める

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

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

計算条件と例外処理をコードの外にも残す

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

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

別の環境で再現できる資料を一式にする

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

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

権限、個人情報、障害時の連絡先を確認する

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

引き継ぎ完了は、資料を使った再現テストで判断する

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

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

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

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

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

スマホで読み取って参加

関連記事

記事一覧 →

DX・AI活用

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