1. 最初に、動作中もAIを使うかを分ける
AIがコードの作成を手伝っただけなら、運用時の主な確認対象はプログラム、保存先、連携、権限です。動作中にもAIを呼び出すなら、そこに入力情報の扱いと出力の確認が加わります。
| ツールの種類 | 運用で確認すること |
|---|---|
| AIでコードを作った集計ツール | 計算ルール、読み書きするファイル、使っている部品、更新・復旧の担当 |
| AIで書類を分類するツール | 上記に加え、AIへ送る項目、契約・設定、分類の誤りを確認する担当 |
| AIの提案を別のシステムへ登録するツール | 上記に加え、登録前の承認、登録済みの照合、再実行と二重登録を防ぐ仕組み |
経済産業省・総務省のAI事業者ガイドライン第1.2版の第5部は、利用時の留意点として、提供者が想定する範囲での利用、仕様に沿った動作、入力データや出力のリスクの確認を示しています。AIを呼び出す処理は、この観点も含めて点検します。
以下の一覧や手順は、小さな業務ツール向けに整理した運用提案です。ガイドラインの全項目を満たす確認表や、安全性を認定するものではありません。入力してよい情報の判断は、顧客情報を生成AIへ入力する前の確認手順で別に整理しています。
2. ツール一つにつき、管理情報を一か所に残す
まず業務担当者と技術担当者で、今分かる情報をまとめます。不明な項目は推測で埋めず、確認先を残します。IPAのガイドライン第4.0版では、利用する機器・ソフトウェアの把握、情報の分類、IDの管理、更新対応などが示されています。次の項目は、それを業務ツールの管理に結び付けるための整理例です。
- 用途と限界：何を入力して何を出すか、対象外の書類・処理、業務上の正しい結果を誰が決めるか。
- 構成と版：ソースコードの保管先、動かす方法、使う部品と版、設定項目、現在動いている版。
- 接続先とデータ：読む場所、書く場所、外部へ送る情報、保存期間、バックアップと削除の担当。
- 契約と管理者：会社の契約・支払い窓口、サービスの管理者、アカウントや契約の期限。
- 日常の担当と代替手段：結果の確認者、不在時の代行者、止まったときの連絡先と手作業の方法。
パスワードやAPIキー（サービスへ接続するための秘密情報）の値は、この資料やコードに書きません。権限を限定した管理方法と、必要な人が取得・更新する手順を別に用意します。画面のJavaScriptなど、利用者へ配られるファイルに秘密情報を入れないことも技術担当者が確認します。
作った社員の個人アカウントだけで契約や設定を管理しているなら、会社で管理できる方法を確認します。契約条件を確かめずにアカウントを共有・譲渡せず、次の管理者を登録できるか、連携設定の移行が必要かを提供元の案内で調べます。
3. 利用者・管理者・連携処理の権限を分ける
「画面を開ける人」と「設定を変えられる人」は同じにする必要がありません。担当者が必要な仕事だけできるようにし、誰が操作したかを追える個別のアカウントを基本にします。
| 役割 | 任せる操作の例 | 権限を広げる前に確認すること |
|---|---|---|
| 業務担当者 | 自分の担当分の閲覧、下書きの確認・修正 | 他の担当や部署の情報まで見える必要があるか |
| 業務責任者 | 内容の承認、処理の停止・再開の判断 | 承認対象と、不在時に代行する範囲 |
| 保守担当者 | 設定・コードの更新、障害調査、復旧 | 作業期間、接続先、触れるデータ、変更の承認者 |
| 連携処理 | 指定した保存先の読み取り・書き込み | 削除・送信まで必要か、対象外の保存先へ接続できないか |
この表は分担の例です。少人数で兼務するときも、普段の利用と管理作業を区別します。AIの出力や受け取った書類の文面だけで、権限を広げたり、接続先を変えたりする流れにしません。
権限は画面のボタンを隠すだけでなく、保存先や連携先でも制限します。通常の利用者で管理操作ができないか、別の担当のデータへアクセスできないかを、本番とは分けた環境で確認します。確認が済むまでは、利用者や処理範囲を広げません。
異動・退職・外部保守の終了時には、不要になった権限を解除します。解除前に、新しい担当者が必要な操作をできることと、自動処理が古い担当者のアカウントに依存していないことを確認してください。引き継ぎのために、退職者のログインを残す運用にはしません。
4. 更新は「変更案・確認・承認・復旧」を一組にする
AIが修正案を作っても、変更したコードと影響範囲は保守担当者が確認します。計算・承認・外部連携に関係する変更を、画面が開いたという理由だけで反映しないようにします。
- 変更する範囲を決める：変更理由、対象画面や出力、維持する業務ルールを記録します。AIへコードを渡す場合も、契約や社内ルールで共有できる範囲を確認し、秘密情報を除きます。
- 本番と分けて確認する：別の保存先と確認用アカウントを使い、実際の宛先への送信、本番データの更新・削除を防ぎます。入力から結果確認まで、業務担当者も操作します。
- 変更の影響を確かめる：正常な入力に加え、空欄、形式の違い、権限不足、同じ処理の再実行、連携が途中で止まった場合を確認します。どの条件を確認したかを残します。
- 戻す方法を確認する：変更前のコード・設定と必要なデータを保全し、隔離した環境で復旧できるか確かめます。コードを戻しても、すでに変更したデータや送ったメールは戻らない点を区別します。
- 責任者が切り替えを承認する：確認結果、反映する版、切り替える日時、失敗時に戻す担当者を合意します。登録・送信を行う仕組みは一つにし、新旧両方から処理しないようにします。
部品の更新や連携先の変更も同じ流れで扱います。保守担当者が提供元の更新・サポート情報を確認し、対応期限と担当を決めます。AIへ送る項目や利用サービス、出力の用途が変わる場合は、業務責任者と情報管理の担当者も再確認します。
止める条件と、再開する条件を決めておく
金額の不一致、承認していない登録、二重処理、想定外のデータへのアクセスなどがあれば、該当する自動処理を止めて担当者へ連絡する運用にします。止め方を知らないまま、再実行を繰り返さないことが大切です。
停止後は、いつ・どの処理が止まり、どこまで登録・送信されたかを確認します。記録には必要以上の顧客情報や秘密情報を残さず、閲覧できる人を限定します。原因と処理済みの範囲を整理し、修正・復旧の確認後に責任者が再開を判断します。漏えいが疑われる場合は、情報管理の窓口へ速やかに報告します。
バックアップの頻度は「失ってよいデータの範囲」、復旧の目標は「業務を止められる時間」から決めます。バックアップがあることと戻せることは別なので、取得結果だけでなく復旧手順も確認します。
自社の実践：運用ファイルの変更で止まった作業から学んだこと
2026年10月8日、hirostaの社内の開発基盤で、自社サイトの運用手順のファイルを別のファイルへの参照リンクに変えたところ、自動作業の安全確認が止まりました。参照リンクを含むファイルの扱いと、安全確認の条件が合っていなかったため、調査の作業が開始直後に停止したものです。
安全確認を外すのではなく、参照リンクを通常のファイルへ置き換え、同じ手順を複数箇所で使う場合は内容を同じ変更で揃えるルールを残しました。原因に対応した修正は同日に取り込まれました。ただし、止まった調査がその後最後まで完了したかは、出典記事の集計では確認していません。
この経験で分かったのは、画面の表示を変えない運用ファイルも、作業を動かすための確認対象になることです。また、修正が取り込まれた記録だけでは、利用を再開できたか、業務が完了したかを判断できません。 詳しい経緯と集計の条件は、AIチームでサイトを運営した記録・第1回をご覧ください。これは自社の実践であり、お客様の案件の成果を示すものではありません。
この学びを、上の更新手順では次のように使います。以下は今後の保守に向けた確認・記録の提案で、停止した調査の復旧を確認済みとするものではありません。
- 変更前（手順1〜4）：コードや画面だけでなく、運用資料と、そのファイルを読む処理の制約も変更範囲に含めます。変更後のファイルを使って作業を始められるかを別の環境で確認し、確認条件と元へ戻す方法を残します。
- 修正の反映時（手順5）：停止した工程、原因、変更内容、反映した版・日時を記録します。修正の取り込みをもって、復旧完了とは記録しません。
- 利用再開の確認時：処理済みの範囲と二重処理の防止を確認したうえで、再開の判断を記録します。作業が開始できたか、最後まで完了したか、結果が正しいかを分けて確認し、確認者・日時・条件・結果を残します。確認できない項目は、未確認の範囲と次に確認する担当を明記します。
今回の情報確認は、2026年10月10日に出典記事の停止・修正・未確認の範囲を確認したものです。外部ガイドラインの参照範囲は、出典欄に記した2026年10月9日時点の確認です。
5. 想定シナリオ：担当者が作ったCSV集計ツールを引き継ぐ
ここからは進め方を示す想定シナリオです。hirostaや顧客が実際に導入・検証した記録ではありません。
営業担当者が、AIの助けを借りて受注CSVを月別に集計する社内ツールを作った会社を想定します。運用中にはAIを呼び出さず、受注管理システムへの書き込みや顧客への送信もしません。担当交代に向けて、別の社員が集計・更新・停止をできる状態を目指します。
引き継ぐ範囲と、画面のイメージ
画面は「対象月を選ぶ → CSVを指定する → 集計候補と確認待ちの行を見る → 確認済みの集計を出力する」という流れを想定します。元の受注CSVは書き換えず、出力先を分けます。
現在の担当者は、CSVの列と集計条件を説明します。税込・税抜、取消済み受注、日付の基準など、不明な条件は業務責任者へ確認します。形式が違うCSVや日付が空欄の行は確認待ちにし、AIに推測させて集計へ混ぜません。
技術担当者は、会社で管理する保管先へコードと構築手順を残し、必要な部品・版・設定を整理します。閲覧するフォルダと出力先への権限を絞り、顧客情報を含まない確認用の内容で、次の担当者が入力から出力まで操作します。業務担当者が手作業の集計と突き合わせ、確認した条件を記録する想定です。
資料を渡すだけで終わらせない
次の担当者に、起動、集計、確認待ちの解消、停止、復旧を順に説明してもらいます。操作できない箇所があれば、手順か権限を補います。引き継ぐのは、ソースコード、入力・出力の仕様、操作・更新・復旧の手順、契約・管理者の一覧、連絡先です。秘密情報の値は資料に転記しません。
新しい担当者の操作と自動処理への影響を確かめたうえで、古い担当者の不要な権限を解除します。交代後の初回集計は業務責任者も結果を確認し、差があれば確定せず、手作業の集計へ戻す流れを想定します。
費用と期間は、調査と運用まで含めて比べる
この例の見積りは、現状の調査、管理先と権限の整理、手順の作成、動作・復旧の確認、引き継ぎ説明、保守に分けます。ツールを動かす環境や外部サービスの利用料、社内の確認時間も含め、どこから追加費用になるかを決めます。AIの利用だけを理由に費用削減を見込むことはできません。
期間は、コードの修正だけでなく、集計ルールの確認、管理者の変更、別環境の準備、担当者が説明を受ける日程で変わります。資料が不足しているなら、まず調査の範囲・費用上限・回答日を決め、結果を見て引き継ぎや改修へ進みます。この記事では実測の費用や日数は示していません。
6. 保守を社内で担うか、外部へ相談するか
社内で続けるなら、変更を読める人、業務上の結果を判断する人、更新・障害対応の時間が必要です。担当者が一人に集中する、接続先が分からない、復旧できない場合は、範囲を絞った調査や保守の相談を検討します。内製・外注の分担はAI導入の内製と外注の判断基準をご覧ください。
操作説明の参考には、Web勤怠と給与計算の自動化の事例があります。現地での運用指導と社員の増減時の対応方法を伝えた事例で、AIは使っていません。今回の想定ツールの安全性や、引き継ぎ費用・期間を裏付けるものではありません。
改修や連携の支援はシステム開発、支援範囲・料金はサービス・料金で確認できます。無料相談では、最初からソースコードや顧客データを送らず、用途、困っている点、管理者と資料の状況からお伝えください。
7. よくある質問
Q. AIで作ったコードなら、保守もAIに任せられますか？ 変更案の作成を補助できますが、影響範囲の確認、業務上の承認、反映・復旧の責任は人が担います。AIの出力を読む担当者と、不具合時の窓口を決めてください。
Q. 社内だけで使うツールにも権限管理は必要ですか？ 必要です。扱う情報と操作に合わせ、閲覧、承認、設定変更、連携処理の権限を分けます。社内利用という理由だけで、全員に管理権限を渡さないようにします。
Q. 引き継ぎはソースコードだけあれば足りますか？ 起動方法、部品の版、入力・出力の仕様、管理者、更新・停止・復旧の手順も必要です。次の担当者が必要な操作をできるか確認してから、権限と保守窓口を切り替えます。
Q. 少し直すだけでも別の環境で確認しますか？ 保存先や計算、権限、外部連携に影響する変更は、本番から分けて確認します。実際の送信・本番データの更新を防ぎ、確認範囲と戻す方法を決めてから反映してください。