AI自動化の保守範囲をどう決める？｜納品後対応と月額保守の実務FAQ
小さなAI自動化を納品した後の不具合、仕様変更、障害、データ修正、追加開発、教育、監視、バックアップ、復旧、終了対応を分け、保守契約の境界を決める記事です。
AI自動化の小さな案件は、作った瞬間よりも、動き始めた後に本当の範囲が見えます。フォームから表へ転記する、問い合わせを振り分ける、定型文の下書きを作る、毎朝の集計を送る。こうした地味な一工程は、件数と削減時間を測りやすく、最初の利益を説明しやすい仕事です。
しかし「一度作れば永久に無人で動く」と考えると、受注側も発注側も苦しくなります。入力欄が一つ増える、担当者が変わる、外部サービスが止まる、APIが廃止される、過去データを直したい、利用者が手順を忘れる。納品前には見えにくかった需要が、問い合わせ、外部仕様変更、納品後対応として現れるからです。
この記事の結論は単純です。保守は「何でも直す月額」ではなく、出来事を分類し、受付、証拠、優先度、対応時間、追加費用、停止権限を決める仕事です。24時間対応や完全自動復旧を約束する必要はありません。むしろ、対応できる時間と、止める判断を先に書いた方が、安全で続けやすい契約になります。
最初の自動化候補の選び方は毎日の作業を自動で回す型、導入効果と価格の考え方はAI自動化の成果と価格をどう決めるか、入力条件を固定する方法はAI自動化テンプレートの変数設計を先に読むと整理しやすくなります。
保守需要は「壊れた」以外からも生まれる
自動化案件の需要を見つけるとき、派手な機能要望だけを見る必要はありません。公開されている業務委託案件には、既存フローの修理、継続監視、API変更への追随、変数の動的化、手順書、利用者教育まで含む依頼があります。これは個別案件の品質や成約を保証する証拠ではありませんが、「構築後にも別種の仕事が発生する」という需要の観察材料になります。
- UpworkのZapier案件一覧には、エラー修正、既存設定の仕上げ、実装支援などの掲載例があります: https://www.upwork.com/freelance-jobs/zapier/
- Upworkの継続保守案件には、deprecated step、API変更、監視、更新への対応が明記された例があります: https://www.upwork.com/freelance-jobs/apply/Zapier-Automation-Specialist-Ongoing-Maintenance-Updates_~022008759392691468685/
- Upworkの修理案件には、固定された日付条件を動的にし、複数月でテストし、手順書と教育を納品する例があります: https://www.upwork.com/freelance-jobs/apply/ZAPIER-AUTOMATION-SPECIALIST-NEEDED-Fix-Broken-Zaps-Build-Automations_~022009480264873306225/
- ランサーズには、既存の社内自動化システムについて改善、機能追加、保守性を含める掲載例があります: https://www.lancers.jp/work/detail/5484897
- クラウドワークスには、API連携、自動化設計、改善提案の経験を求める掲載例があります: https://crowdworks.jp/public/jobs/13184184
この観察から言えるのは、「地味な一工程を作る需要」と「作った後に維持する需要」は分離できるということです。言えないのは、誰でも同じ価格で受注できること、掲載件数がそのまま成約件数になること、保守を付ければ必ず利益になることです。
| 見えている依頼 | 背後にある運用課題 | 最初に確認する証拠 | すぐ約束しないこと |
|---|---|---|---|
| 壊れた自動化を直してほしい | いつから、どの入力で、どこが止まったか不明 | 実行ID、時刻、入力の識別子、エラー、直前変更 | 原因不明のまま即日完全復旧 |
| 固定日付を動的にしたい | 変数と境界条件が不足している | 対象月、タイムゾーン、締め日、例外日 | 全期間の過去データ修正 |
| API変更へ追随してほしい | 外部仕様へ依存している | 変更履歴、廃止日、代替API、影響する処理 | 外部サービスの永続互換 |
| 継続監視してほしい | 失敗が利用者から見えない | 成功件数、失敗件数、最終成功時刻、通知先 | 24時間有人監視 |
| 手順書と教育がほしい | 担当者交代で運用知識が消える | 対象者、利用場面、権限、質問履歴 | 無制限の個別研修 |
まず十種類に分ける
「保守」という一語に全部を入れると、初期不具合と追加開発が同じ扱いになります。次の十種類へ分けると、無償か有償か、保守内か別見積もりかを判断しやすくなります。
1. 初期不具合
合意済みの仕様どおりに入力したのに、納品時点から期待した結果にならない状態です。たとえば、必須項目がそろっているのに転記されない、同じ条件なのに一部だけ処理されない、合意済みの形式と違う値が出る、といったものです。
ただし、仕様書にない新しい入力、納品後に変更された接続先、権限の失効、利用者による設定変更は、初期不具合と分けます。「使えない」という感想だけで決めず、受入テストの入力と期待結果を再現できるかで判定します。
2. 仕様変更
業務手順、入力項目、命名規則、承認者、営業時間、保存先などを変える仕事です。小さく見えても、分岐、テスト、手順書、過去データとの互換性へ影響します。変更要求は、保守に含める軽微変更と、別見積もりの変更へ分けます。
3. 外部サービス障害
自動化本体が正しくても、接続先SaaS、メール、ストレージ、認証基盤、ネットワークが止まれば処理できません。Makeの公式ステータスページには、地域別の状態、シナリオ実行、Webhookなどの稼働状況と過去インシデントが掲載されています: https://status.make.com/
外部障害時に受託者ができるのは、影響確認、処理停止、再送候補の隔離、公式情報の共有、復旧後の再開判断です。外部事業者の復旧時間そのものは約束できません。
4. データ修正
誤った入力、重複、欠損、文字化け、過去仕様との不一致を直す仕事です。プログラム修正とデータ修正は別です。プログラムを直しても、既に作られた誤データは自動で元に戻りません。
データ修正では、対象件数、修正規則、原本、承認者、実行前バックアップ、実行後照合が必要です。大量修正を「不具合修正のおまけ」にしない方が安全です。
5. 機能追加
新しい接続先、分岐、画面、帳票、通知、承認、AI判断などを増やす仕事です。既存機能の修理ではありません。小さなボタン一つでも、新しい権限や個人データが増えるなら、設計、テスト、説明、費用を別にします。
6. 利用者教育
操作説明、エラーの読み方、停止方法、問い合わせの出し方、担当者交代時の引継ぎです。仕組みが正しくても、入力ルールが伝わらなければ失敗します。教育は一度の納品説明だけで終わらず、質問履歴を手順書へ戻す改善として扱えます。
7. 監視
最終成功時刻、成功件数、失敗件数、未処理、処理時間、利用量を確認し、異常候補を知らせる仕事です。「動いたログ」だけでは、結果が正しいか分かりません。自動化の静かな失敗を見つける方法で扱うように、件数差、古い未処理、空の成功、宛先違いも監視対象です。
8. バックアップ
設定、処理定義、変数一覧、手順書、変更履歴、必要なデータの複製を、復旧に使える形で残す仕事です。バックアップが存在することと、復元できることは別です。定期的に復元手順を試し、誰がアクセスできるかを確認します。
9. 復旧
停止した処理を元に戻し、未処理を整理し、安全に再開する仕事です。完全自動復旧は既定にしません。原因が不明なまま再実行すると、重複送信や二重登録を増やす可能性があるからです。Webhookの二重処理を防ぐ方法のように、同じ処理を一度だけ反映する仕組みと、再開前の照合が必要です。
10. 契約終了
アカウント、接続、秘密情報、データ、手順書、ログ、バックアップ、所有権、削除確認、移管を整理する仕事です。契約が終わっても受託者の個人アカウントで処理が動き続ける状態は避けます。終了対応の費用と期間を開始時に決めます。
| 区分 | 典型例 | 保守内にしやすい範囲 | 別見積もりにしやすい範囲 | 主な承認者 |
|---|---|---|---|---|
| 初期不具合 | 合意済み入力で転記失敗 | 再現、原因修正、同じテストの再実行 | 新しい入力形式への対応 | 業務責任者 |
| 仕様変更 | 列名、承認者、時間帯変更 | 月一回までの文言や通知先変更 | 分岐、データ構造、権限変更 | 業務責任者 |
| 外部障害 | SaaS停止、認証障害 | 影響確認、停止、公式情報確認 | 代替基盤への移行 | システム所有者 |
| データ修正 | 重複、欠損、誤転記 | 少数件の手順提示 | 一括修正、原本調査、再計算 | データ所有者 |
| 機能追加 | 接続先、帳票、承認追加 | 原則含めない | 設計から検収まで | 発注責任者 |
| 利用者教育 | 操作説明、交代者研修 | 定例内の短い質問 | 個別研修、教材制作 | 運用責任者 |
| 監視 | 失敗、未処理、利用量 | 決めた頻度の確認と通知 | 常時監視、個別ダッシュボード | 運用責任者 |
| バックアップ | 設定、手順、データ複製 | 決めた対象の定期確認 | 新しい保管先、長期保存 | データ所有者 |
| 復旧 | 再開、再送、照合 | 手順に沿う復旧支援 | 大量再処理、原因不明の調査 | 停止権限者 |
| 契約終了 | 移管、接続解除、返却 | 合意した終了チェック | 追加形式への変換、長期伴走 | 契約責任者 |
受付票は「困っています」から証拠へ変える
保守の利益を削るのは、修理時間だけではありません。状況を聞き直す往復、対象を探す時間、優先度の衝突、証拠なしの推測が大きな負担になります。受付経路を一つにし、最低限の証拠をそろえます。
問い合わせ票には次を入れます。
- 受付番号
- 発生を確認した日時とタイムゾーン
- 対象の自動化名と実行ID
- 期待した結果
- 実際の結果
- 影響する件数と業務
- 入力データの識別子
- 画面またはログのエラー
- 最後に成功した日時
- 直前に変えた設定、権限、入力、接続先
- 再実行済みか
- 個人情報や秘密情報を除いた再現用データ
- いま止める必要があるか
- 連絡を受ける担当者
パスワード、認証コード、APIキー、顧客の生データを問い合わせ本文へ貼らせません。必要なログも、個人情報をマスクして共有します。個人情報保護委員会の通則編は、個人データの安全管理措置、委託先の監督、漏えい等が発覚した場合の措置を扱っています: https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/
同ガイドラインは、委託先の選定、委託契約、取扱状況の把握を示しています。したがって「ツール会社が安全と言っているから終わり」ではなく、委託するデータと業務に応じて、発注側も委託先を確認する必要があります。
| 受付時の状態 | 必要な証拠 | 最初の判断 | やってはいけないこと |
|---|---|---|---|
| 一件だけ失敗 | 実行ID、入力識別子、期待値、実値 | 個別データか共通ロジックか | 全件を無条件再実行 |
| 全件が止まった | 最終成功、外部ステータス、認証状態 | 停止維持か迂回か | 原因不明の接続再作成 |
| 成功表示だが結果なし | 出力件数、保存先、照合キー | 静かな失敗か条件除外か | 成功ログだけで完了扱い |
| 重複が発生 | 同一キー、実行回数、再送履歴 | 追加処理を止めるか | 重複のまま自動復旧 |
| 個人データ漏えいの疑い | 発覚時刻、対象範囲、アクセス記録 | 通常保守から事故対応へ切替 | 証拠を消す、独断で公表 |
優先度は「怒っている順」ではなく影響で決める
優先度は、影響範囲、元へ戻せるか、個人情報、金銭、対外送信、代替手段、時間制約で決めます。連絡の強さだけで順番を変えると、本当に危険な静かな失敗が後回しになります。
| 優先度 | 判定例 | 受付確認の目安 | 最初の行動 | 目標であって保証しないもの |
|---|---|---|---|---|
| P1 緊急 | 個人情報漏えいの疑い、誤送信継続、二重請求の恐れ | 契約時間内に最優先確認 | 自動処理停止、証拠保全、責任者連絡 | 原因究明と完全復旧の時刻 |
| P2 高 | 中核処理が全件停止、手作業の代替が難しい | 契約時間内の当日確認 | 影響範囲確認、迂回手順、再開条件整理 | 外部SaaSの復旧時刻 |
| P3 通常 | 一部失敗、代替手順あり、期限に余裕 | 次の対応枠で確認 | 再現、原因分類、修正案 | 即時修正 |
| P4 変更 | 文言、通知先、列追加、改善要望 | 定例または変更受付日 | 影響調査、保守内外判定 | 無料対応 |
「受付確認」は、問い合わせを受け取り、必要な追加情報と暫定行動を返すまでです。「復旧」は別です。受付確認時間を復旧保証と書かないことが重要です。
IPAの「インシデント発生時の緊急対応体制の整備」は、事象に応じた組織内外の連携や演習を扱っています: https://www.ipa.go.jp/security/economics/practices_navi/practice226.html
NIST SP 800-61 Rev.3は、インシデント対応をサイバーセキュリティリスク管理へ組み込み、検知、対応、復旧の有効性を高めるための考慮事項を示しています: https://csrc.nist.gov/pubs/sp/800/61/r3/final
これらは小規模な自動化保守へそのまま契約文として貼るものではありません。ただし、準備、検知、対応、復旧、改善を一続きにし、担当と証拠を決める考え方は使えます。
SaaSは便利な部品であり、責任の外注先ではない
自動化サービスを選ぶとき、機能一覧だけでなく、変更履歴、サービス状態、契約上の可用性、APIの廃止方針を確認します。次は2026年7月24日に確認した入口です。
| 候補 | 変更履歴の入口 | 障害・可用性の入口 | API廃止・変更の入口 | 契約前に残す判断 |
|---|---|---|---|---|
| Microsoft Power Platform | 2026 wave 1 release plan | Microsoft Online Services SLAとService health | API versioning and support、deprecations | 対象製品がSLAのどの条項か、廃止通知後の移行担当 |
| Zapier | Platform News | Zapier Status | Platform News、integration version管理 | 公開された数値SLAの適用有無、連携先ごとの変更責任 |
| Make | 公式のWhat’s new、Terms内の製品資料 | Make Status | Developers Hubと契約資料 | 契約プラン固有のSLA、API変更通知、ログ保存 |
Microsoft Power Platformの2026 release wave 1は、2026年4月から9月の予定を扱い、オンライン計画は週次更新と説明されています。予定は変更または未提供になり得る旨も記載されています: https://learn.microsoft.com/en-us/power-platform/release-plan/2026wave1/
Power Platformのdeprecationsページは、deprecatedとremovedを区別し、廃止情報を準備に使うよう案内しています: https://learn.microsoft.com/en-us/power-platform/release-plan/2026wave1/deprecations
Power Platform APIのversioning and supportは、一般提供版APIについて、新版公開時に旧版をdeprecatedとし、原則として少なくとも12か月前に通知する方針を説明しています。サービス健全性やセキュリティでは例外があり得ます: https://learn.microsoft.com/en-us/power-platform/admin/programmability-versioning-support
MicrosoftのOnline Services SLAページは、オンラインサービスの稼働率と接続性に関するコミットメントの現行版と過去版を提供しています。自動化の契約では、利用するサービスと契約形態が対象かを原文で照合します: https://www.microsoft.com/licensing/docs/view/Service-Level-Agreements-SLA-for-Online-Services
Power Platformのサービス状態は管理センターから確認できると公式文書にあります: https://learn.microsoft.com/en-us/power-platform/admin/check-online-service-health
ZapierのPlatform NewsにはDeveloper Platformの変更履歴があり、2026年にもCLI名の削除やバージョン移行の制約が掲載されています: https://docs.zapier.com/integrations/news
Zapier Statusは製品別の状態と過去の事象を確認する入口です: https://status.zapier.com/
Zapierの利用規約は、サービスが外部サービスを含む複数の依存関係を持つこと、保証、責任制限などを定めています。公開ページで自分のプランに適用される数値SLAを確認できない場合、受託者が独自に同等の稼働率を顧客へ約束しません: https://zapier.com/legal/terms-of-service
MakeのStatusページは地域、シナリオ実行、Webhookなどを分けて状態と履歴を公開しています: https://status.make.com/
MakeのTerms and ConditionsはMaster Services Agreement、Data Processing Agreement、製品説明、過去版への入口をまとめています。契約前には顧客のプランへ適用されるSLAやサポート条件を個別文書で確認します: https://www.make.com/en/terms-and-conditions
ここで大切なのは、ステータスページの過去稼働率を自分の顧客への保証へ転記しないことです。SaaSが復旧しても、保留された実行、重複、順序入れ替わり、期限切れトークン、未処理データは残る可能性があります。自分の保守契約は、外部SaaSのSLAではなく、自分が確認し、止め、証拠を残し、再開を判断する範囲を定めます。
架空契約A: 月次確認だけのライト保守
以下は契約範囲を考えるための架空例です。実在の顧客、標準価格、法的に有効な条文ではありません。
対象は、問い合わせフォームの内容を担当別の確認表へ転記し、営業時間内に下書きを作る一つの自動化です。外部送信は人が承認します。
| 項目 | 架空の条件 |
|---|---|
| 契約名 | 月次確認ライト |
| 対応時間 | 平日10時から17時。祝日と指定休業日を除く |
| 受付経路 | 専用フォーム一つ。電話、私用SNS、複数チャットは受付外 |
| 受付確認 | P1は対応時間内4時間以内を目標、P2は当日、P3は次の2営業日以内 |
| 証拠 | 実行ID、発生時刻、期待結果、実結果、入力識別子、エラー |
| 含む作業 | 月一回の成功・失敗・未処理確認、通知先一件の変更、初期不具合 |
| 追加費用 | 新しい分岐、接続先、過去データ修正、個別研修は事前見積もり |
| 停止権限 | 誤送信、重複、個人情報事故の疑いでは受託者が暫定停止できる |
| 再開権限 | 顧客の業務責任者が影響と未処理を確認して承認する |
| バックアップ | 月次で設定書と変数一覧を顧客所有の保管先へ出力 |
| 契約終了 | 接続解除、手順書返却、保有コピーの削除確認を終了票で行う |
この契約は24時間監視ではありません。営業時間外の事象は次の対応枠で確認します。人命、医療判断、決済確定、法定期限へ直接つながる処理は対象にしません。
架空契約B: 週次監視と変更枠を含む標準保守
対象は、受注メールの添付を保存し、項目を読み取り、担当者の確認待ち一覧へ入れる自動化です。AIの抽出結果は人が確認し、基幹台帳への確定登録は自動化しません。
| 項目 | 架空の条件 |
|---|---|
| 契約名 | 週次監視スタンダード |
| 対応時間 | 月曜から土曜の9時から18時。日曜、祝日、指定休業日を除く |
| 受付経路 | 専用フォーム。P1のみ登録済み責任者からの電話併用 |
| 受付確認 | P1は対応時間内2時間以内を目標、P2は4時間以内、P3は次の営業日 |
| 証拠 | 実行ID、添付の匿名識別子、抽出結果、期待値、最終成功時刻、直前変更 |
| 含む作業 | 週一回の件数照合、月一回60分までの軽微変更、四半期ごとの復元手順確認 |
| 追加費用 | 60分超の変更、一括データ修正、新帳票、新しいAIモデル評価 |
| 停止権限 | 誤登録の連続、件数差、外部障害、利用量急増で受託者が暫定停止 |
| 再開権限 | 受託者が再現テストを示し、顧客のデータ責任者が承認 |
| 利用者教育 | 四半期一回60分、録画ではなく更新済み手順書を正本にする |
| 契約終了 | 30日前の申出を想定し、設定、未処理、ログ、権限を一覧で移管 |
この契約でも完全自動復旧は行いません。再実行前に重複キーと未処理範囲を確認し、送信や確定登録がある場合は人の承認を残します。
架空契約C: 重要業務向けの運用伴走
対象は、複数店舗の日次報告を集計し、欠損を店舗へ差し戻し、責任者の承認後に月次集計へ反映する自動化です。金銭の確定、会計仕訳、給与計算は対象外です。
| 項目 | 架空の条件 |
|---|---|
| 契約名 | 運用伴走プレミアム |
| 対応時間 | 平日8時から20時、土曜10時から16時。日曜、祝日、指定休業日を除く |
| 受付経路 | 専用チケット。P1のみ登録済み責任者の電話連絡を追加 |
| 受付確認 | P1は対応時間内60分以内を目標、P2は3時間以内、P3は次の営業日 |
| 証拠 | 店舗コード、対象日、実行ID、件数差、承認履歴、直前の設定変更 |
| 含む作業 | 営業日の件数監視、月二時間の変更枠、月次報告、半期の復旧訓練 |
| 追加費用 | 新店舗追加、大量再計算、保存期間変更、外部SaaS移行、現地研修 |
| 停止権限 | 誤集計の拡大、承認飛ばし、権限異常、個人データ事故の疑いで即時停止 |
| 再開権限 | 顧客責任者、データ責任者、受託者の三者で影響と再処理範囲を確認 |
| バックアップ | 設定は週次、重要データは顧客方針に従う。半期に復元可能性を確認 |
| 契約終了 | 45日前から移行票を作り、接続、所有、データ、ログ、未処理、削除を照合 |
「プレミアム」という名称でも、24時間対応、無制限修正、外部SaaSの復旧保証、損失の全額補償を意味しません。重要なのは名前ではなく、表の中身です。
三契約を並べて選ぶ
| 比較軸 | ライト | スタンダード | 運用伴走 |
|---|---|---|---|
| 対象 | 低リスクの一工程 | 日常業務の一連の流れ | 複数部門へ影響する流れ |
| 監視頻度 | 月次 | 週次 | 営業日 |
| 軽微変更 | 通知先一件 | 月60分 | 月120分 |
| 教育 | 別見積もり | 四半期一回 | 定例と手順書更新 |
| 復旧確認 | 手順書確認 | 四半期 | 半期訓練 |
| P1受付確認目標 | 対応時間内4時間 | 対応時間内2時間 | 対応時間内60分 |
| 24時間対応 | なし | なし | なし |
| 完全自動復旧 | なし | なし | なし |
| 適さない業務 | 高リスク送信、決済 | 人命、法的判断 | 人命、金銭確定、無人の最終判断 |
月額は「いつでも何でも頼める権利」ではありません。確保する確認枠、監視頻度、変更枠、報告、復旧準備へ払うものです。成果と価格の評価はAI自動化の成果と価格をどう決めるか、実行費と確認費の記録はAI作業のコストを記録する方法につなげます。
追加費用が発生する境界
追加費用の有無を、受託者の気分で決めてはいけません。変更の種類と影響で決めます。
| 判断軸 | 保守内の例 | 追加見積もりの例 | 中止または再設計の例 |
|---|---|---|---|
| 入力 | 表示名の修正 | 新しい必須項目、別形式 | 原本の信頼性がない |
| 分岐 | 既存条件の閾値変更 | 新しい顧客区分、承認経路 | 差別的判断や説明不能な判定 |
| 接続 | 同一アカウントの再認証支援 | 新SaaS、新テナント | 規約で自動化が禁止 |
| データ | 数件の確認手順 | 一括修正、履歴再計算 | 原本不明、本人同意が必要 |
| AI | プロンプト文言の軽微修正 | モデル変更、評価セット追加 | 人が検証できない高リスク判断 |
| 通知 | 既存宛先の変更 | 新チャネル、外部送信 | 同意や送信権限がない |
| 保管 | 既存期間内の整理 | 保存期間延長、海外移転 | 必要な安全措置を満たせない |
仕様変更票には、変更理由、変える箇所、変えない箇所、影響するデータ、ロールバック、テスト、費用、実施日、承認者を書きます。小さな変更でも記録を残す方法はAIコーディングの引継ぎメモやAI生成コードの検品チェックリストの考え方を転用できます。
監視は成功率だけで終わらせない
自動化の静かな失敗は、エラーにならないことがあります。処理は成功でも入力がゼロ、保存先が違う、古い列を読んでいる、条件から全件外れた、送信先が退職者のまま、といった状態です。
最低限、次を記録します。
- 最終成功日時
- 入力件数
- 出力件数
- 除外件数と理由
- 失敗件数
- 未処理件数と最古日時
- 重複候補
- 人の修正率
- 実行時間
- 利用量と上限
- 設定の最終変更者と変更日時
- 外部サービスの状態
Zapierの公式ヘルプでは、実行状態としてErrored、Held、Needs review、Safely haltedなどを区別しています: https://help.zapier.com/hc/en-us/articles/20505304170637-Review-run-statuses-in-Zap-workflows
また、一定条件でZapが自動停止し得ること、TeamとEnterpriseでは通知や猶予の扱いが異なることが公式ヘルプにあります。具体条件は変更され得るため、運用開始時と障害調査時に原文を確認します: https://help.zapier.com/hc/en-us/articles/8496216132621-Zap-is-not-running
通知が来る前提にせず、最後に成功した時刻と期待件数を顧客側でも見られるようにします。失敗通知の基本はGitHub Actionsの失敗通知、定期実行の設計はcron自動化の安全設計も参考になります。
バックアップと復旧は別々に検収する
バックアップ契約では、対象、頻度、保存先、暗号化、保持期間、削除、復元担当を決めます。顧客データを受託者の私物ストレージへ置かないこと、秘密情報を設定書へ平文で残さないことも必要です。
復旧テストでは、次の順で確認します。
- 復旧対象の版と日時を選ぶ
- 本番ではない安全な場所へ復元する
- 設定、接続先、変数、権限を照合する
- 匿名化した試験入力で実行する
- 入力件数と出力件数を照合する
- 重複防止と停止操作を試す
- 本番再開の承認者へ結果を渡す
- 復旧にかかった時間と不足物を記録する
NISTのインシデント対応資料が準備から復旧までをリスク管理の中で扱うように、バックアップは置物ではなく復旧能力の一部です。復元できないバックアップは、保守の証拠として不十分です。
個人情報を扱うときの最低境界
個人情報保護委員会の通則編は、安全管理措置について組織的、人的、物理的、技術的な観点を示し、委託先の監督も扱っています。自動化保守では、少なくとも次を契約と運用へ落とします。
- 何の個人データを扱うか
- 何の目的で必要か
- 誰がアクセスできるか
- どのSaaSと再委託先へ渡るか
- どこに、いつまで保存するか
- ログや問い合わせ票へ何を残さないか
- 誤送信、漏えい、滅失、毀損の疑いを誰へ報告するか
- 契約終了時に返却または削除するもの
- 顧客が取扱状況を合理的に確認する方法
漏えい等の疑いを通常のP3不具合として処理しません。自動処理を止め、証拠を保全し、顧客の責任者へ連絡します。法令上の報告や本人通知の要否は、事実関係と適用法をもとに顧客側が専門家と判断します。受託者が独断で公表したり、証拠を消したりしません。
秘密情報の管理はAIコーディングの秘密情報管理、外部文面を命令として扱わない考え方はAIコーディングのプロンプトインジェクション対策にもつながります。
契約終了は最後の保守作業
終了時に確認するのは請求だけではありません。次の終了票を使います。
| 項目 | 終了時の確認 |
|---|---|
| 所有 | 自動化、設定、文書、データ、アカウントの所有者 |
| 接続 | OAuth、APIキー、Webhook、メール、ストレージの接続解除 |
| 権限 | 受託者、退職者、共有アカウントのアクセス削除 |
| 未処理 | 保留、失敗、再送待ち、手動対応中の一覧 |
| データ | 返却形式、保存先、保持期間、削除対象 |
| ログ | 引き渡す期間、個人情報のマスク、閲覧権限 |
| バックアップ | 最終版、復元手順、保管責任者 |
| 文書 | 構成図、変数、停止、再開、問い合わせ、変更履歴 |
| SaaS | 契約者、請求先、プラン、解約後のデータ扱い |
| 削除確認 | 受託者が持つ作業コピーと秘密情報の削除記録 |
移管先が決まっていない場合でも、受託者の個人アカウントで無期限運転を続けません。安全に停止し、未処理と再開条件を顧客へ渡します。
保守を利益にするための原価記録
保守の利益は、月額からSaaS料金を引くだけでは分かりません。問い合わせの往復、再現、ログ確認、変更調査、報告、教育、待機、請求、終了対応を記録します。
月間保守原価
= 定例確認時間
+ 問い合わせ受付と聞き直し
+ 再現と原因調査
+ 修正とテスト
+ 変更履歴と手順書の更新
+ 利用者教育
+ SaaSと監視の実費
+ 契約管理と報告
月間保守粗利
= 月額保守料
- 月間保守原価この式は価格の答えではなく、赤字の場所を見つけるための台帳です。問い合わせが多いなら料金を上げる前に、受付票、変数、エラーメッセージ、手順書を改善できるか見ます。同じ質問が三回出たら、個別回答を続けるより入力画面か手順書へ戻した方が、次回の人手を減らせます。
自動化を増やしても収益が自動で生まれるわけではないという実践記録は自動化を30日続けた記録にあります。保守でも同じで、月額契約数だけでなく、人の手が何手減ったか、再発を何件防いだか、復旧に必要な証拠がそろったかを見ます。
FAQ
Q1. 納品後は無償で直すべきですか
合意した仕様と受入テストを満たさない初期不具合は、無償修正期間と対象を決めやすい部分です。新しい入力、業務変更、外部SaaS変更、データ修正、機能追加は分けます。期間だけでなく「何を不具合とするか」を書いてください。
Q2. 保守契約がなければ一切対応しないのですか
緊急停止やスポット調査の受付方法を別に用意できます。ただし、受付可能時間、調査開始条件、単価、証拠、復旧保証ではないことを先に示します。常時待機を無償で抱えません。
Q3. 月額保守には何を含めるべきですか
監視頻度、定例報告、問い合わせ受付、受付確認時間、軽微変更枠、バックアップ確認、教育、終了対応を選びます。「保守一式」だけにしないでください。
Q4. 軽微変更とは何ですか
既存の構造、権限、データ型を変えない通知先や文言の変更などです。時間上限も付けます。列追加、分岐追加、接続先追加、保存期間変更は軽微と決めつけません。
Q5. SaaSの障害も受託者の責任ですか
外部サービス自体の復旧は受託者が支配できません。保守では、公式状態の確認、影響範囲、暫定停止、未処理の隔離、復旧後の再開判断を担当範囲にできます。
Q6. 24時間対応を付けた方が売れますか
一人や小規模体制で実行できない約束は付けません。必要なら営業時間を広げた契約、登録責任者だけの緊急経路、代替手順を設計します。人命や重大な金銭処理は、体制がないなら対象から外します。
Q7. 受付確認一時間とは、一時間で直す意味ですか
違います。受付確認は、受領、証拠確認、優先度、暫定行動を返すまでです。原因調査、外部サービス復旧、データ修正、再開承認は別の時間です。
Q8. 完全自動復旧はできませんか
限定された低リスク処理では再試行を自動化できますが、重複、誤送信、順序変更を防ぐ条件が必要です。原因不明、高リスク、外部送信を含む処理は、人の確認を残します。
Q9. エラー通知が来なければ正常ですか
正常とは限りません。入力ゼロ、出力ゼロ、保存先違い、全件除外などは成功表示になり得ます。件数、最終成功、未処理、修正率を照合します。
Q10. 問い合わせ時にスクリーンショットだけあれば足りますか
足りない場合があります。実行ID、発生時刻、期待結果、実結果、入力識別子、直前変更があると再現しやすくなります。画像内の個人情報と秘密情報はマスクします。
Q11. 顧客からパスワードを教えてもらえば早いですか
共有しません。顧客所有のアカウント、最小権限、正式な招待、OAuthなどを使います。本人確認や多要素認証は顧客本人が行います。
Q12. データ修正は不具合修正に含まれますか
プログラム修正と分けます。既存データの件数、原本、修正規則、承認、バックアップ、照合に別の工数とリスクがあるからです。
Q13. 外部サービスのAPI廃止は誰が追うのですか
契約で担当を決めます。受託者が変更履歴を確認する場合も、廃止通知の入口、確認頻度、影響調査、移行費用、顧客承認を定めます。
Q14. API廃止へ追随する費用は月額に含めますか
影響調査だけを含め、移行実装は別見積もりにする方法があります。予測不能な大規模変更まで定額へ入れると、双方に不透明です。
Q15. SLAが99.9パーセントなら自分も同じ保証を出せますか
出せるとは限りません。SaaSのSLAは対象サービス、契約、除外、救済が定められています。自分の自動化は複数サービスと顧客運用に依存するため、自分が支配できる受付と対応を定めます。
Q16. バックアップは何世代残せばよいですか
一律の答えはありません。変更頻度、復旧点、法令、データ量、費用、削除義務で決めます。世代数より、対象と復元可能性を確認してください。
Q17. バックアップがあれば復旧訓練は不要ですか
不要ではありません。権限、変数、接続、版がそろわず復元できないことがあります。本番外で小さく復元し、所要時間と不足物を記録します。
Q18. 利用者教育は一度で十分ですか
担当者交代、画面変更、手順変更があれば再教育が必要です。質問を手順書へ反映し、同じ説明を繰り返さない仕組みにします。
Q19. 機能追加を保守内にすると喜ばれませんか
短期的には喜ばれても、優先順位と費用が見えなくなります。変更枠の時間を決め、超える機能追加は影響調査と見積もりへ分けます。
Q20. 顧客が設定を変えて壊した場合は初期不具合ですか
通常は分けます。ただし、誤変更しやすい設計や権限が原因なら、再発防止として設定保護や変更記録も検討します。
Q21. 重大事故の疑いがあるとき、受託者だけで止めてよいですか
契約で暫定停止権限を決めます。誤送信や漏えいが広がる可能性があるなら停止を優先し、証拠と影響を責任者へ伝えます。再開は別の承認にします。
Q22. 外部障害から復旧したら自動ですぐ再送してよいですか
重複、期限切れ、順序、宛先、件数を確認してからです。未処理一覧を作り、再送対象を顧客が承認できるようにします。
Q23. 個人情報を含むログは長く残すほど安全ですか
長ければよいとは限りません。調査に必要な期間と削除義務を両立し、アクセス制御、マスク、保管先、削除日を決めます。
Q24. 契約終了時に自動化を削除すれば終わりですか
終わりではありません。未処理、接続、権限、データ、ログ、バックアップ、文書、SaaS契約、受託者の作業コピーを確認します。削除は所有者と対象を確定してから行います。
Q25. 月額保守が赤字になったらどう見直しますか
案件ごとに受付、調査、修正、報告、教育の時間を記録します。同じ問い合わせを受付票や手順書で減らせるか、保守範囲が広すぎないか、監視頻度が価値に合うかを先に見直します。
Q26. 保守を付けない方がよい案件はありますか
あります。発生頻度が低く手動で安全に戻せる、顧客が自分で管理できる、外部依存がなく変更も少ない案件です。保守を売ることではなく、総負担を減らすことが目的です。
Q27. 一人で重要業務の保守を受けてもよいですか
不在時の代替、対応可能時間、停止権限、復旧手順、責任上限を満たせないなら対象を狭めます。人命、医療判断、決済確定などは、小規模体制の一般的な自動化保守から外す判断が必要です。
Q28. 保守契約を始める前の最低テストは何ですか
正常入力、必須欠損、重複、外部エラー、権限失効、停止、再開、未処理照合、バックアップ復元を試します。正常な一件だけで検収しません。
導入前チェックリスト
- 対象業務と対象外業務を一文で書いた
- 初期不具合、仕様変更、外部障害、データ修正、機能追加を分けた
- 教育、監視、バックアップ、復旧、終了対応を分けた
- 受付経路を一つにした
- 必要な証拠を受付票にした
- P1からP4の優先度を影響で定義した
- 受付確認と復旧を別にした
- 対応時間と休業日を示した
- 追加費用の境界を示した
- 暫定停止と再開の権限者を決めた
- 24時間対応を安易に約束していない
- 完全自動復旧を安易に約束していない
- SaaSの変更履歴、状態、SLA、API廃止方針の入口を保存した
- 個人データ、再委託、ログ、保管、削除を確認した
- 終了票と移管物を開始時に決めた
まとめ
小さなAI自動化は、地味な一工程だからこそ成果を測りやすく、最初の利益へつなげやすい仕事です。同時に、変数不足、問い合わせ、外部仕様変更、納品後対応が見えないまま受けると、保守の原価が膨らみます。
保守を利益にする出発点は、月額を先に決めることではありません。初期不具合、仕様変更、外部サービス障害、データ修正、機能追加、利用者教育、監視、バックアップ、復旧、契約終了を分けることです。その上で、対応時間、受付経路、証拠、優先度、追加費用、停止権限を契約ごとに選びます。
24時間対応も完全自動復旧も、できる体制と検証がなければ約束しません。止めるべき時に止まり、証拠を残し、人が再開を判断できる仕組みの方が、派手ではなくても長く使えます。
Sources
以下は2026年7月24日に確認した公式、公的、または需要掲載元のページです。製品の契約前には現行版を再確認してください。
公的資料
- IPA「インシデント発生時の緊急対応体制の整備」 https://www.ipa.go.jp/security/economics/practices_navi/practice226.html
- IPA「政府機関等の対策基準策定のためのガイドライン」 https://www.ipa.go.jp/security/vuln/scap/ug65p9000001994c-att/guider3_2.pdf
- NIST SP 800-61 Rev.3 https://csrc.nist.gov/pubs/sp/800/61/r3/final
- NIST Incident Response Project https://csrc.nist.gov/projects/incident-response
- 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」 https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/
- 個人情報保護委員会「委託先において個人データが漏えいした場合の対応」 https://www.ppc.go.jp/all_faq_index/faq3-qb3-8/
SaaSの変更、SLA、API、障害、契約
- Microsoft Power Platform 2026 release wave 1 https://learn.microsoft.com/en-us/power-platform/release-plan/2026wave1/
- Microsoft Power Platform deprecations https://learn.microsoft.com/en-us/power-platform/release-plan/2026wave1/deprecations
- Microsoft Power Platform API versioning and support https://learn.microsoft.com/en-us/power-platform/admin/programmability-versioning-support
- Microsoft Online Services SLA https://www.microsoft.com/licensing/docs/view/Service-Level-Agreements-SLA-for-Online-Services
- Microsoft Power Platform service health https://learn.microsoft.com/en-us/power-platform/admin/check-online-service-health
- Zapier Platform News https://docs.zapier.com/integrations/news
- Zapier Status https://status.zapier.com/
- Zapier Terms of Service https://zapier.com/legal/terms-of-service
- Zapier「Review run statuses in Zap workflows」 https://help.zapier.com/hc/en-us/articles/20505304170637-Review-run-statuses-in-Zap-workflows
- Zapier「Zap is not running」 https://help.zapier.com/hc/en-us/articles/8496216132621-Zap-is-not-running
- Make Status https://status.make.com/
- Make Terms and Conditions https://www.make.com/en/terms-and-conditions
需要の観察材料
- Upwork Zapier jobs https://www.upwork.com/freelance-jobs/zapier/
- Upwork「Zapier Automation Specialist, Ongoing Maintenance and Updates」 https://www.upwork.com/freelance-jobs/apply/Zapier-Automation-Specialist-Ongoing-Maintenance-Updates_~022008759392691468685/
- Upwork「Fix Broken Zaps and Build Automations」 https://www.upwork.com/freelance-jobs/apply/ZAPIER-AUTOMATION-SPECIALIST-NEEDED-Fix-Broken-Zaps-Build-Automations_~022009480264873306225/
- ランサーズ「社内自動化システムの改善・機能追加」 https://www.lancers.jp/work/detail/5484897
- クラウドワークス「AI業務エンジニア」 https://crowdworks.jp/public/jobs/13184184
続き（結論と実データ）はnoteに置いています
ここでは手順のところまで書きました。実際に出た数字、うまくいかなかった条件、そのまま使える設定ファイルは、 note の記事にまとめてあります。