INSIGHT
AIで直せる。その一言で、保守の担当と時間を消さない
AIが修正案を出せることを根拠に、変更の判断・確認・問い合わせを引き受ける担当までなくしていないか。
「不具合が出ても、そのときAIに直してもらえばいい」。試作品を日常業務へ広げる会議で、その一言が保守費をゼロにし、社内担当を置かない理由になっている。
AIが修正案を早く作れる場面はある。しかし、利用者の連絡を受け、業務への影響を判断し、直す範囲を決め、変更を確かめ、公開し、結果を伝える仕事は残る。AIへ依頼する人も、その結果を採用する人も決まっていなければ、「直せる」は保守体制ではない。
問い合わせ、変更、障害、復旧を引き受ける担当と時間がないまま、保守を不要とする決裁は止める。
保守は、壊れたコードを直す作業だけではない
月曜日の朝、利用者から「昨日まで見えた案件が表示されない」と連絡が来たとする。原因はコードとは限らない。利用者の権限が変わった、参照先のデータが更新された、外部サービスの設定が変わった、使い方が伝わっていない、という可能性もある。
最初に必要なのは、すぐコードを書き換えることではない。いつ、誰が、どの案件で、どの操作をし、業務がどこまで止まっているかを記録することだ。そのうえで問い合わせ、変更要望、障害のどれとして扱うかを決める。
- 問い合わせ：使い方や表示の意味を答えれば解決する
- 変更要望：業務ルールや使い方の変化に合わせ、直すかを判断する
- 障害：約束した条件で利用できず、復旧や利用制限が必要になる
入口を分けると、誰が何を引き受けるかも分けられる。受付、影響判断、修正案、業務確認、公開承認、利用者連絡である。一人が複数を担ってもよいが、連絡が来たら誰が最初に持つかは一本にする。
「AIに聞く」の前後にある判断を数える
修正一件を、受付から終了まで追ってみる。現象を再現する。影響する利用者、データ、連携を調べる。いま直すか、利用を止めるか、回避手順を案内するかを決める。変更案を作り、試し、公開を承認し、利用者へ伝え、記録を更新する。
AIが短くできる可能性があるのは、この流れの一部である。再現用の手順を整理する、修正候補を出す、試験項目を増やす、変更内容を説明する、といった補助が考えられる。一方、顧客への影響を受け入れるか、業務ルールを変えてよいか、どの時点で公開するかは、担当者の判断として残る。
「小さなアプリにも、大きな保守契約が要るのか」と思うかもしれない。必要な規模は同じではない。翌営業日に確認すれば足りる社内の補助ツールと、止まると顧客への支払いが滞る仕組みでは、確保する時間も連絡経路も変わる。費用を下げるなら、対応範囲を狭めるか、待てる時間を合意する。その代わりに何を引き受けなくなるのかまで、見積もりへ残す。
NISTのSecure Software Development Framework は、設計やレビューだけでなく、公開後に見つかった脆弱性への対応も扱う。AI生成コードに同じ手順を一律に課す資料でも、個別製品の品質を保証する資料でもない。公開後の対応が、作成時の仕事とは別に残ると整理するための一般的な枠組みになる。
保守費はコードを書く時間だけで見積もらない。受付、調査、判断、確認、公開、連絡、記録に使う時間を一件ずつ数える。
引き受ける人には、止める権限と時間が要る
保守担当の名前だけを置いても、対応する時間や権限がなければ仕事を引き受けたことにはならない。通常業務の合間に見るのか、特定の時間帯は優先して見るのか。業務を止める判断、試験環境で変更する権限、本番公開を依頼する経路、外部事業者へ連絡する契約上の窓口が必要になる。
優先度は「急ぎ」「通常」の感覚だけで決めず、業務の影響で分ける。確定処理が誤って進む、他人の情報が見える、外部へ重複送信する状態は、利用を止める判断が必要かもしれない。表示のずれや改善要望は、記録したうえで次の変更日にまとめられる場合がある。具体的な対応時間は外部の数字を借りず、自社が許容できる停止と担当者の勤務条件から決める。
NIST AI 600-1 は、生成AIに関するリスク管理で、役割、継続評価、第三者依存、停止・廃止などを整理している。日本企業に対する一律の法的義務や、このアプリに必要な担当人数を示す資料ではない。AIを含む仕組みを使い続けるなら、導入後の役割と停止判断も管理対象に残す視点として参照できる。
作成者以外が、一件を終えられるか試す
自作した人だけが、設定場所、接続先、公開方法を知っていることがある。その人が休んだ日に変更できないだけでなく、誤った変更を止められないなら、保守は個人に残ったままだ。
引継ぎ資料には、すべての制作過程ではなく、次の担当者が判断するための情報を残す。
- 仕組みの目的と、対象となる業務
- 扱うデータ、外部連携、主要な設定
- 利用者・管理者・公開者の権限
- 現在使っている版と変更履歴
- 通常時と主要例外の確認方法
- 公開、停止、切戻し、復旧の手順
- 社内外の連絡先と契約上の依頼方法
資料が使えるかは、作成者以外の人で試す。過去の問い合わせ一件を渡し、対象を特定し、影響を判断し、試験環境で変更を確かめ、公開または見送りを記録できるかを見る。途中で作成者へ聞かないと進まなかった箇所が、追加で引き継ぐ情報になる。
予算を見直すのは、保守の引受けが成立してから
AIによって修正時間が短くなり、外注範囲や社内工数を見直せる可能性はある。その判断は、誰が何を引き受けるかを決めた後に行う。
再開に必要なのは、問い合わせ・変更・障害の受付、影響に応じた優先度と停止基準、変更を確認して公開する経路、作成者以外が使える引継ぎ、復旧と利用者連絡の担当である。さらに、通常時に確保する時間と、障害時に動ける連絡経路を予算へ入れる。
AWS Well-Architectedの復元確認に関する資料 は、復元したデータの内容、利用可否、時間を確認し、業務の復旧目標と比べる考え方を示す。AI固有の事故率や特定の復旧時間を示すものではない。復旧を「バックアップがある」で終わらせず、保守が引き受ける一つの仕事として数える参考になる。
これらがない間は、保守費と担当時間をゼロにしない。利用者を限る、外部送信や確定操作を外す、変更を凍結する、既存手順へ戻せるようにする。再開するのはAIが修正案を出せた日ではなく、担当者が一件を受け、止め、確かめ、公開し、説明できた日である。
保守を減らす決裁は、AIが直せるかではなく、残る仕事の引受人・時間・権限・引継ぎを示せたときに再開する。
保守の一件を受付から連絡までたどり、残る仕事を引き受ける
AIは、保守の中にある調査、修正案、試験準備を速くできるかもしれない。その価値を継続して使うには、依頼する人、採用を決める人、利用者へ答える人を先に置く必要がある。
次の見積もりでは、コードを直す時間だけを見るのではなく、直近の一件を受付から連絡までたどりたい。そこで残った判断と作業を引き受ける体制が、保守の本体である。