AIで作ったアプリは誰が直す？パッチが追いつかない時代の保守運用

作る速さと、直す速さは別のもの

Claude CodeやCodexのような、AIの開発支援ツールが広がっています。
現場の担当者でも、業務アプリを短期間で作れるようになりました。
例えば、SESやSIの会社の管理部門。エンジニアの勤怠を集計し、取引先への請求額と突き合わせるツールを、担当者が自分で作れます。
この記事では、こうして作られる社内向けのツールをまとめて「AIで作ったアプリ」と呼びます。

大きな前進だと思います。
そのうえで、よく聞く考え方があります。

「AIで速く作れるなら、壊れたらまた作り直せばいい」

でも、それは違うと私たちは考えています。
ツールの一生は、作った日より、作った後のほうがずっと長いからです。
その間も、ツールが頼っている部品やモデルは、外の誰かの都合で変わり続けます。
作る手はAIで増えても、直す手は増えません。

では、作った後を誰が、いつまで、どう直すのか。
保守運用とは、システムを動かし続けるために、更新・修正・監視を続けることです。
これを作る前に決めておけば、現場のツールは安心して使い続けられると、私たちは考えています。

まずは、直す側がどれだけ追いつけていないかから見ていきます。

見つかる数は2.2倍、直すには3か月

脆弱性（ソフトウェアの弱点）が見つかる速さが、上がっています。
共同通信が米MITREのデータを集計したところ、2026年は10月21日までに約8万5千件。前年同期の約2.2倍です（デイリースポーツ掲載の共同通信集計・10月24日）。
生成AIの普及で、研究者が短時間に多くの弱点を見つけられるようになったことが背景とされます。

直す側は、そこまで速くなっていません。
Moody'sのレポート（2026年10月19日）では、修正にかかった日数の中央値は、悪用が確認された脆弱性で87日。確認されていないもので107日でした（Infosecurity Magazine）。
過去2年に公開された脆弱性の集計です。悪用が確認されたものでも、半数は直すのに約3か月以上かかっています。

比べると、開きがよく分かります。
米国のサイバーセキュリティ・インフラ安全保障庁（CISA）は、米連邦機関に期限を課しています。悪用が確認された脆弱性は、原則2週間以内に直すこと。

2週間と、87日。

民間に課された義務ではありません。
でも、この開きの間ずっと、攻撃者には付け入る隙が残ります。

作った日に安全でも、それは出発点にすぎません。
では、ツールを1本作ると、何を追い続けることになるのでしょうか。

1本作れば、追う対象が一式増える

作るのが速くなっても、ツールが頼るものは減りません。
下の図は、AIを使う業務ツール1本が依存するものを、層に分けたものです。

自社の仕事は、その更新に気づき、影響を確かめ、適用するところまでです。
ただ、この「気づく」が曲者です。
担当が決まっていなければ、更新は誰にも気づかれないまま止まります。
作った人が異動すると、誰も中身を知らないツールだけが残ります。

AIが書いたコードも、直す対象に入ります。
米Veracodeは、100以上の大規模言語モデルが書いたコードを検証しました。45%が、Webアプリの代表的な弱点を含んでいました（Veracode・2025年7月）。
AIが、存在しない部品の名前を勧めることもあります。その割合は商用のモデルで平均5.2%以上、公開されたモデルで平均21.7%という報告です（USENIX Security 2025で発表された研究）。
攻撃者がその名前で不正な部品を公開しておけば、ツールに入り込めます。
作った後にも、中身を確かめる人が要ります。

だからといって、AIでの内製をやめるべきだとは考えていません。
数週間で使い終え、終わったら捨てると決めてある検証や分析のツール。外部に公開せず、機密情報や個人情報を扱わないツール。自社の差別化に直結し、更新を追える担当者と予算がある業務。
こうした場面では、内製は理にかなっています。

分かれ目は1つです。
作る前に「誰が、いつまで、どう直すか」を決めているかどうか。

そして、追う対象は自社のコードとライブラリだけではありません。
AIを使うツールでは、部品の供給元そのものが広がりました。

部品の供給元は、モデルや接続口まで広がった

ソフトウェアのサプライチェーンとは、自社のシステムが依存する外部の部品と、その供給元の連なりです。
AIを使うツールでは、ここに新しい供給元が加わりました。
AIのモデル。AIを外部のツールにつなぐMCPサーバー。AIサービスの提供元。

それぞれで押さえておくことは、そう多くありません。
モデルなら、使っている版と提供終了日、更新の通知を受ける窓口。
MCPサーバーや外部ツールなら、提供元が公式か、誰が導入を認めたか。
ライブラリなら、使っている部品の一覧。経済産業省のSBOMの手引（2024年8月）も、部品と依存関係を機械で読める一覧にする考え方を示しています。一覧があれば、新しい脆弱性が見つかったときに、影響を受けるツールがすぐ分かります。
委託先なら、渡すデータと権限を絞り、更新と連絡の約束を契約に書くこと。

委託先は、いま特に目を離せないところだと思います。
2026年9月末から続いた不正アクセスでは、委託先を起点とする事案が相次ぎました。国家サイバー統括室は10月9日、委託先の管理体制と責任分界の確認、委託先へ渡すデータと権限の最小化を求めています（国家サイバー統括室）。

MCPサーバーにも、別の注意が要ります。
信用を積んだ後で、中身が変わることがあるからです。
2025年9月、メール配信サービスのMCPサーバーを名乗る非公式の部品が、15の版を正常に出しました。その後の版から、送信メールすべての写しを攻撃者に送るようになりました。ダウンロードは1週間で約1,500回でした（The Register・2025年9月29日）。

導入した日に安全でも、後の版が安全とは限りません。
更新を確かめる担当がいれば、部品は安心して使い続けられます。

ここまでは、中身が変わったことに気づけば直せる話です。
厄介なのは、自社が何も変えていないのに、答えが変わる部品があることです。

モデルは、ある日答え方を変える

自社のコードを一行も変えていなくても、提供元がモデルを更新すれば、AIの答え方は変わります。
OpenAIは2025年4月24〜25日にGPT-4oを更新しました。利用者に過度に迎合する応答が増え、28日から以前の版に戻しています。公開前の評価もこの問題を捉えられなかったと、同社は説明しています（OpenAI）。

提供元の評価は、提供元が想定した用途に合わせたものです。
自社の業務で壊れていないかは、自社で確かめるしかないと私たちは考えています。

モデルには寿命もあります。
2026年10月時点で、Anthropicは公開モデルの提供終了を少なくとも60日前に通知するとしています。OpenAIは、一般提供のモデルで少なくとも6か月前です。
切り替えは、いずれ必ず来ます。

では、どう確かめるか。
私たちの答えは、業務の正解例を持っておくことです。

正解例は、現場がいちばん持っている

回帰テストとは、以前は正しく動いていたことが、変更の後も壊れていないかを確かめるテストです。
自社の業務の例を「期待する答え」付きで持っておき、モデルが変わる前に新旧の答えを比べます。

正解例は、新しく作らなくても手元にあります。
請求の突き合わせなら、過去に担当者が確定した突き合わせの結果。入金消込なら、人が承認した消し込みと、却下した消し込み。
判断ログも使えます。AIの提案と、人の承認・却下とその理由の記録です。残っていれば、それがそのまま材料になります（AIエージェントの権限設計）。
うまくいった例だけでは足りません。断るべき依頼。金額が合わない境界の例。読んだメールに仕込まれた指示。こうした例も一緒に入れておきます。

言葉にするとありきたりに聞こえます。
でも、業務部門が自分で持てる確かめ方の中で、これがいちばん頼りになると考えています。
システムに詳しくなくても、「この入力ならこの答えが正しい」は、業務の担当者がいちばんよく知っているからです。
国の指針も同じ方向です。総務省・経済産業省のAI事業者ガイドライン（第1.2版、2026年3月）は、必要に応じて定期的かつ客観的なモニタリングを行い、人が制御できる状態を保つよう求めています。

確かめ方が決まれば、残る問いは1つです。
ここまでの仕事を、誰が持つのか。

誰が持つかで、自社に残る仕事が変わる

持ち方は、大きく4つあります。
内製。SIerや委託先。完成品のSaaS。そして、マネージド基盤やローコード基盤。
完成品のSaaSと、自社がその上にアプリや業務の定義を作るマネージド基盤とでは、自社に残る保守が違います。ローコード基盤での市民開発も、「基盤は提供元、アプリは現場」という分担なので、マネージド基盤と同じ形として扱います。

私たちは、毎月使い続ける業務ほど、土台の保守を任せられる持ち方が向くと考えています。
マネージド基盤なら、自社に残るのは業務の定義と正解例になります。修正が利用者全体にまとめて届くのも利点です。

ただ、裏を返せば、提供元の弱点も全利用者に同時に及びます。
2025年8月には、Salesloft社のチャットツールとSalesforceの連携に使われていた認証の鍵が盗まれました。多数の企業のSalesforceから、データが持ち出されています（Google Threat Intelligence Group）。
だから、提供元の更新や連絡の約束は、あらかじめ確かめておきます。

基盤の上に自社で作った部分は、担当者がいなければ誰も直しません。
委託先に期待できるのも、契約に書いたことだけです。更新の期限や引き継ぎの範囲は、契約に書いておきます。

業務部門での振り分けは、例えばこうなります。
一度きりの集計や分析は、内製で作り、使い終えたら捨てる。廃止の日は最初に決めておきます。
毎月の勤怠集計や請求の突き合わせは、マネージド基盤に載せる。土台の保守は提供元に任せ、自社は業務の定義と正解例を持ちます。
基幹システムと密につなぐ処理は、委託先に任せる。更新と連絡の約束を、契約に書いておきます。

持ち方が決まれば、費用も見積もれます。

直す費用は、作る費用と分けて書く

作った後の費用は、毎年かかり続けます。
見積もりの出発点は、図1の層ごとに「年間の更新の回数 × 1回あたりの確認と適用の時間 × 人件単価」を足すことです。そこに、回帰テストの実行費と、契約や道具の費用を加えます。

見落としやすい費用もあります。
作った人が兼務で直していると、その人件費は予算に現れず、ゼロに見えます。
委託先との保守契約では、モデルの変更への追随や軽微な改修が、都度見積もりになることがあります。
マネージド基盤でも、更新を受け入れる確認の工数は自社に残ります。

作る費用だけが下がり、直す費用が変わらなければ、全体に占める直す費用の割合は大きくなります。
だから稟議には、作る費用と並べて、直し続ける費用を書いておきます。
承認する側も、そのほうが判断しやすくなるはずです。

請求や入金のような財務報告にかかわる業務に使うなら、もう1つ考えておくことがあります。
金融庁の内部統制の基準（2023年改訂、2024年4月以後に始まる事業年度から適用）は、外部に委託した業務の統制も評価の範囲に含めるとしています。IT全般の統制の例には、「システムの開発、保守」が挙がっています。
モデルの切り替えも、保守にあたる変更として、承認・テスト・反映の記録を残しておくのが自然です。
扱いは、早めに監査人と相談しておくと安心です。

導入がスムーズに進みやすい保守の決め方

次のことを作る前に決めておくと、情シスへの説明が短く済み、現場で作ったツールも社内で認められやすくなります。

1. 誰が持つか、何につなぐか、いつまで使うかを届け出る：届け出は3項目程度に絞ると、届けずに作られるツールが減ります
2. 主担当と副担当を決める：作った人が異動しても、代わりに直せる人がいる状態にします
3. 業務の正解例を持つ：モデルや部品が変わったとき、業務の担当者が自分で確かめられます
4. 更新を知る窓口を決める：使っているモデルの版と提供終了日、部品の更新の通知を、誰が受け取るかを決めます
5. 土台の保守を任せられる持ち方を選ぶ：毎月使い続ける業務は、基盤の保守を提供元に任せ、自社は業務の定義に集中します

情シスに説明するときの要点

• このツールは「誰が持つか・何につなぐか・いつまで使うか」を決めて届け出ており、主担当と副担当がいます
• 土台（基盤・モデル・部品）の更新を誰が適用するかを、層ごとに決めています。基盤の保守は提供元が持ちます
• モデルが変わる前に、業務の正解例で新旧の答えを比べ、切り替えの承認を記録に残します
• 直し続ける費用は、作る費用と分けて見積もっています
• 一度きりの用途のものは、廃止の日を決めて使い終えたら捨てます

直す人を決めれば、任せる範囲は広げられる

AIで、現場がツールを作れるようになりました。
これは前進です。止める理由はありません。

ただ、ツールの一生は、作った後のほうが長い。
1本増えるたびに、モデルや部品を含めて、更新を追う対象が一式増えます。

だから、層ごとに担当を決める。
モデルの変化には、業務の正解例で備える。
毎月使う業務は、土台の保守を任せられる持ち方を選び、自社は業務の定義と正解例に集中する。

作る前に「誰が、いつまで、どう直すか」を決めておく。
それだけで、現場が作ったツールは、社内で認められる道具になります。
直す人さえ決まっていれば、AIに任せる業務は、安心して増やしていけます。
私たちは、そう考えています。

関連記事

• 相次ぐ不正アクセスはなぜ止まらない？原因と今すぐ確かめる8項目：保守運用とAPIの設計という二つの穴
• AIエージェントの責任は誰が負う？システムと運用の責任分界：システムと運用、自社と委託先の責任分界
• AIエージェントの導入審査をスムーズに通すには？推進担当の準備と選び方：社内審査を通すための準備

参考資料

• デイリースポーツ（共同通信の集計）：AIで欠陥発見、今年急増（2026年10月24日）
• Infosecurity Magazine: Exploited Vulnerabilities Typically Take Three Months to Patch, Moody’s Finds（2026年10月19日）
• CISA: BOD 22-01 Reducing the Significant Risk of Known Exploited Vulnerabilities
• IPA「情報セキュリティ10大脅威 2026」を決定（2026年1月29日）
• Veracode: 2025 GenAI Code Security Report（2025年7月30日）
• Spracklen et al., We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs（USENIX Security 2025）
• 経済産業省「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 Ver2.0」（2024年8月29日）
• 内閣官房 国家サイバー統括室「不正アクセスによる漏えい等の事案を踏まえた対応について」（2026年10月9日）
• The Register: postmark-mcpの不正な変更（2025年9月29日）
• OpenAI: Expanding on what we missed with sycophancy（2025年5月2日）
• Chen, Zaharia, Zou, How is ChatGPT's behavior changing over time?（2023年）
• Anthropic: Model deprecations、OpenAI: Deprecations
• 総務省・経済産業省「AI事業者ガイドライン（第1.2版）」本編（2026年3月31日）
• Google Threat Intelligence Group: Widespread Data Theft Targets Salesforce Instances via Salesloft Drift（2025年8月26日、28日更新）
• 金融庁 企業会計審議会「財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準の改訂について（意見書）」（2023年4月7日）

Askhubについて

Askhubは、日本の中堅・大企業がAIに業務を任せるための基盤です。業務の型（オントロジー）でAIに許す操作を定め、承認と判断ログで任せる範囲を広げながら、国産の基幹システムまで書き込めるようにします。導入はコンサルタントが伴走します。

この記事の4つの持ち方でいえば、Askhubはマネージド基盤にあたり、基盤の更新と脆弱性対応は当社が持ちます。緊急度の高い脆弱性は14日以内、重要な脆弱性は30日以内に修正を終える目標で運用し、提供時間や復旧の目標はサービスレベルに関する規定で定めています。新しいモデルや送信先を加えるときは、標準・国内リージョン限定・Pマーク準拠のどの構成で使ってよいかを必ず分類します。分類を忘れると自動のテストで落ちるので、確かめないまま新しい送信先が使われないようにしています。モデルの自動の切り替えは、提供元の一時的な障害のときに、あらかじめ決めた別の提供元のモデルへ1回だけ行います。切り替え先も、お客様が許可した送信先と処理地の範囲からしか選びません。お客様が作ったアシスタントや業務の定義の保守と、切り替え先も含めて自社の正解例で動きを確かめることは、お客様の側に残ります。

※Askhubのサービスに関する記載は、2026年11月時点の情報です。

関連する機能：製品の全体像、伴走支援