メインコンテンツへスキップ
メニュー

AI導入後の運用を外注する範囲:止まった日に分ける2つの仕事

AIの仕組みが止まった日の仕事は、処理の復旧と業務の立て直しに分けると、外注する範囲を決められます。

この記事の要点

  • AIが止まった日の仕事を2つに分ける:処理の復旧と業務の立て直し
  • 朝の資料が届かないことに気付く確認と、知らせを受ける人を決める
  • 処理の復旧は、外注先が受け持つ範囲と対応時間を契約に書く
  • 遅れた資料を使うか作り直すかは、社内の担当が決める
AIの仕組みが止まった日の仕事は、処理の復旧と業務の立て直しに分けると、外注する範囲を決められます。
この記事の要点を図にしたものです。
目次

AIが止まった日の仕事を2つに分ける

A&Aの考え方

AIの仕組みが止まった日の仕事は、処理の復旧と業務の立て直しの2つに分かれます。ここでいうAI導入後の運用とは、外注先が作ったAIの仕組みを毎日動かし続け、止まった時に元へ戻す仕事のことです。

A&Aの考え方

処理の復旧は、止まった仕組みを調べて、もう一度動くようにする仕事です。業務の立て直しは、止まっていた間に遅れた仕事を、その日どう片付けるかを決める仕事です。前者は外注先の技術で進み、後者は社内の事情で決まります。

仮想例

たとえば、次のような架空の仕組みがあるとします。毎朝8時に、前日の問い合わせをAIがまとめた社内資料が、共有フォルダに置かれます。9時の朝会は、この資料を見て始まります。

仮想例

この仕組みが止まった朝、外注先は原因を調べて処理を戻します。けれども、9時の朝会に何を出すかは、外注先には決められません。前日の資料で済ませるか、要る数字だけ手で集めるかは、朝会を開く側が判断します。

A&Aの考え方

この記事を書いているのは、Automate & Augment(A&A)です。A&Aは、2つを一つの「保守」にまとめて契約すると、業務の立て直しが誰の仕事でもなくなると考えます。止まったことに気付く所から2つを分けて書いたこの節の表が1枚あれば、上司や取締役会にも、止まった日に誰が動くかを示せます。

A&Aの考え方

表の最初の行は、届かないことに気付く確認です。社内の受け取り手と外注先が受け持ち、確かめる時刻、知らせる先、休みの日の代わりの人を決めます。次の行の処理の復旧は外注先が受け持ち、受け持つ作業と受け持たない作業、連絡する順番、対応時間を決めます。

A&Aの考え方

その次は、原因が外部のサービスにあって復旧を待つ間です。外注先が状況を追って社内へ知らせます。決めるのは、知らせる人と、その間の代わりのやり方です。最後の行の業務の立て直しは社内の担当が受け持ち、遅れた資料を使うか、作り直すか、配らないかを決めます。

エラーが出なくても届かないことに気付く

A&Aの考え方

止まった日に最初に要るのは、予定の時刻に資料が届いていないことに気付く確認です。エラーの通知は、処理が動いて失敗した時に出ます。処理がそもそも始まらなければ、通知が出ないこともあります。

出典に基づく事実

クラウドのサービスを提供するMicrosoftは、利用する企業に向けて、仕組みを運用するための設計の指針を公開しています。その中で、通知は受けた人がすぐ動けるものにし、状況が分かる情報を添えるよう勧めています。

Microsoft Learn ↗

出典に基づく事実

通知の進め方として、誰が受け持ち、何をし、どこまでを対象にするかを決めておくことも挙げています。さらに、仕組みの不調が、利用者の仕事にどう響くかまで見えるようにする、とも書いています。

Microsoft Learn ↗

A&Aの考え方

A&Aはこの考えを、届くはずの物が届いたかを見る確認に当てはめます。朝の資料の例なら、8時15分に共有フォルダに今日の資料があるかを確かめ、無ければ知らせます。知らせには、どの資料がいつから届いていないかを書きます。

A&Aの考え方

知らせを受ける人は、社内に1人決めます。休みの日の代わりの人も決めておきます。知らせが多すぎると読まれなくなるので、すぐ動くもの、その日のうちに見るもの、後でまとめて見るものに分けます。

処理の復旧は外注先が受け持つ範囲を契約に書く

A&Aの考え方

処理の復旧で外注先がどこまで受け持つかは、範囲と対応時間を契約の前に書き出してもらい、契約に書きます。書いていない作業は、止まった日に誰もやらないことがあるからです。

出典に基づく事実

Microsoftの障害対応の指針は、計画の中で役割と責任を決めておくよう書いています。例として、全体を仕切る人、技術の担当、連絡の担当が挙がっています。

Microsoft Learn ↗

出典に基づく事実

外部の業者に頼る場合は、各当事者が受け持つ範囲、除外する範囲、手に負えない時に回す手順、見込みの対応時間を、計画に書くよう勧めています。サポートの契約は、障害が起きる前に用意しておくよう書いています。

Microsoft Learn ↗

A&Aの考え方

A&Aは、外注先に次の作業を分けて書いてもらうのがよいと考えます。状況の確認、もう一度動かすこと、設定の修正、外部サービスへの問い合わせ、途中で止まって欠けたデータの直しです。顧客へ案内を送る処理のように、動かし直すと同じ案内が二重に送られるものは、動かす前に社内へ確かめると書き添えます。

A&Aの考え方

対応時間は、知らせが届くまで、外注先が手を付けるまで、処理が戻るまでの3つに分けて聞きます。「すぐ対応します」だけでは、どの時間の約束か分かりません。夜や休日を含めるかは、朝会の時刻と費用で決めます。

A&Aの考え方

原因が外部のサービスにある時は、外注先にも直せない時間が残ります。その間に状況を追って社内へ知らせる人を、外注先の側に決めておくと、社内の担当は業務の立て直しに手を回せます。

遅れた資料の扱いは社内の担当が決める

A&Aの考え方

遅れた資料を使うか作り直すかは、外注先ではなく社内の担当が決めます。朝会で何が要るかを知っているのは、社内の側だからです。

出典に基づく事実

Microsoftの障害対応の指針は、外部の業者に頼る場合の人の分け方も書いています。業者と直接やり取りする人と、社内で原因を探して対処を続ける人が、同時に要るとされています。

Microsoft Learn ↗

仮想例

朝の資料の例に戻ります。8時15分に資料が無いと知らせを受けた担当は、外注先に復旧を頼みます。同時に、9時の朝会に出す物を決めます。前日の資料に「昨日の分です」と書き添えるか、要る数字だけ手で集めるかです。

仮想例

古い資料を、今日の資料として黙って配ることはしません。昼に処理が戻っても、終わった朝会の資料を後から配るとは限りません。この例では、抜けた日の分は記録にだけ残し、翌朝から通常の時刻に戻すと担当が決めます。

A&Aの考え方

記録には、仕組みが戻った時刻と、遅れた仕事の扱いが決まった時刻を分けて書きます。前者は外注先の対応の記録で、後者は社内の判断の記録です。分けておくと、次に契約を見直す時に、どちらに時間がかかったかが分かります。

まとめ

処理が止まった朝、進行役が復旧を外注先へ渡し、経営者が遅れた資料を使うか作り直すかを決める場面

A&Aの考え方

AIが止まった日の仕事は、処理の復旧と業務の立て直しの2つに分けます。朝の資料が届かないことに気付く確認と、知らせを受ける社内の1人を決めます。

A&Aの考え方

処理の復旧は、外注先が受け持つ範囲と対応時間を、契約の前に書き出してもらい、契約に書きます。遅れた資料を使うか作り直すかは、社内の担当が決めます。

AIの仕組みの運用をどこまで外注するかは、止まった日の仕事を処理の復旧と業務の立て直しに分けると決められます。契約の前に、外注先が受け持つ作業と対応時間を書き出してもらい、遅れた資料の扱いを決める社内の担当を決めておきます。

よくある質問

業務の立て直しまで、外注先に任せることはできますか。

手作業の代わりまで外注先に頼む契約なら、作業は任せられます。ただ、遅れた資料を朝会で使うかどうかの判断は、社内の担当に残ります。

夜間や休日の対応まで、契約に入れる方がよいですか。

止まって困る時刻から逆に数えて決めます。9時の朝会に使う資料なら、朝の早い時間に手が付けば間に合います。夜間も含めるかは、その分の費用と比べて決めます。

外注先の担当者が替わっても困らないように、何を残せばよいですか。

仕組みが動く場所、管理者、止め方、再開の条件、連絡先を残します。Microsoftの障害対応の指針は、社内と業者の連絡先を最新に保ち、外部の人に権限を渡す手順を簡単で安全にしておくよう書いています。

出典・編集情報

記事の調査で確認した一次資料です。資料の公開・更新時期と、調査時の確認日を分けて記載しています。

  1. Architecture Strategies for Designing a Monitoring System

    Microsoft Learn · Living documentation; updated 2026-02-11

    確認日 2026-10-23
  2. Architecture strategies for designing an incident management (IcM) process

    Microsoft Learn · Living documentation; updated 2026-02-11

    確認日 2026-10-23

編集方針

← 記事一覧へ