AIで作ったシステムは保守できるか｜コードを読めなくても確認できる7つの指標

この記事は、AIを使って開発されたシステムを外注で受け取った、あるいはこれから受け取る中小企業の経営者と発注担当者に向けたものです。社内に開発者がいないことを前提に置きます。AI生成コードの品質を扱う記事の多くは、レビューする側の技術者に向けて書かれています。発注者向けの解説も増えており、2026年9月5日に上位を確認したところ10件中5件がその立場のものでした。ただし確認する項目までで止まり、そのまま送れる文面と、運用してから判定する基準までを渡すものは見当たりません。開発者を抱えていない会社が、その項目を見た後で受け取ってよいかをどう決めるか、というところが残ります。ここを扱います。

この記事では、コードを読まずに保守できるかどうかの当たりを付ける方法を扱います。技術用語は使いません。セキュリティ面の確認は別の観点になるため、そちらは別途扱っています。

結論

保守できるかどうかは、コードを読まなくても判断できます。環境構築の手順書、テスト、外部部品の一覧、変更履歴、ファイルの説明、設定の分離、引き継ぎの想定。この7つで当たりは付きます。そして最も効くのは、発注時に「引き継げる状態で引き渡すこと」を条件に入れることです。納品後に依頼すると費用が発生し、応じてもらえないこともあります。

問題は「AIが書いたこと」ではない

「AIで作ったから不安」という相談をよく受けます。しかし判断の軸としては正確ではありません。人が書いても保守できないものは作れますし、AIが書いても保守できるものは作れます。

AIを使ったことで変わるのは、生成される量が増え、確認されないまま納品される割合が上がりやすいことです。問題はコードの出どころではなく、確認の工程があるかどうかです。したがって発注側が見るべきは「AIを使ったか」ではありません。確認された形跡があるか、そして引き継げる状態かどうかです。

確認されないまま通ると、何が残るか

生成された量が増えれば、その分だけ確認の作業も増えます。NTTデータは自社での検証結果として、生成AIの成果物の正解率をばらつきはあるものの「おおよそ60%程度」と公表しており、生成された出力を完成品ではなくたたき台として扱うべきだと述べています（NTTデータ「生成AIを使って開発したソフトウェアの品質保証」、出典の確認日: 2026年9月5日）。開発を担う側が読み直す前提を置いているという意味で、これは発注側にとっても前提の確認になります。

確認の工程を通らないまま納品されると、動作としては問題なく見えるのに、中身には決まった形の欠けが残ります。実際には存在しないライブラリを参照している、すでに廃止された機能の呼び出しがそのまま残っている、利用者の権限を確かめる処理や入力値を点検する処理が抜けている、といったものです。いずれも使っている間は表面化せず、外部部品を更新した日や、想定外の値が入力された日にはじめて表に出ます。発注側が見るべきなのは、こうした欠けを誰かが一度は探したという形跡です。

「動く」と「保守できる」の違い

納品後に手を入れる作業は、例外ではなく仕事の大半を占めます。IPAが5,546プロジェクトを集計した「ソフトウェア開発分析データ集2022」では、開発プロジェクトの種別は新規開発が29.1%、改修・保守が51.5%でした。2016年度からの推移でも新規開発は32.5%から減り、改修・保守は45.8%から増えています。仕事の過半は、すでにあるものを直す作業に使われている、ということです（IPA「ソフトウェア開発分析データ集2022」。割合は同ページから配布されている報告書PDFに記載されています。出典の確認日: 2026年9月6日）。

	動く	保守できる
確認方法	使ってみる	別の人が変更できるか
分かる時期	納品時	半年〜数年後
問題の現れ方	エラーが出る	小さな修正の見積もりが高額になる
発注側が気付くきっかけ	利用者からの申告	次の改修を頼んだとき

保守できない状態は、納品時には見えません。気付くのは、次の改修を依頼したときか、別の会社へ引き継ごうとしたときです。そのときには手遅れで、作り直しに近い費用がかかります。つまり保守性の確認は、数年後に発生する費用を今のうちに下げる作業です。仕様が分からないシステムを抱えた場合の実際の対処はブラックボックス化した基幹システムとどう向き合うかで扱っています。この記事は、その状態を自分で作らないための話です。

納品時に確認する7つの指標

コードを読む必要はありません。資料の有無と、質問への回答で判断できます。

1｜環境構築の手順書があるか

別の会社が引き継ぐとき、最初に必要になる資料です。これがないと、引き継ぐ側は動かすところから調査になります。「新しい担当者がこのシステムを自分の環境で動かすための手順はありますか」と質問します。

2｜テストが存在するか

動作を自動で確認する仕組みがあるかどうかです。あれば、変更したときに壊れていないかを確認できます。「テストはありますか。どの機能を対象にしていますか」と聞きます。「あります」だけでなく、何を守っているかまで答えられるかを見ます。数だけ多くて中身が薄いテストは、保守の役に立ちません。

3｜使っている外部部品の一覧があるか

システムは外部の部品を組み合わせて作られます。その一覧と版が分かる資料を求めます。数が極端に多い場合、更新の手間もそれだけ増えます。

4｜変更の履歴が残っているか

いつ、何を、なぜ変えたかの記録です。履歴がまとまって1回だけ、という状態は、途中の経緯が失われている合図です。「変更の履歴は見られますか」と質問します。

5｜「このファイルは何ですか」に答えられるか

納品物の中からいくつか選び、それが何をするものかを説明してもらいます。開発した側が即答できないファイルがある場合、そのシステムは開発者自身も把握していない状態です。

6｜設定と処理が分かれているか

接続先や金額の基準といった、後から変わる値が、どこに書かれているかを聞きます。設定ファイルにまとまっていれば、変更が容易です。処理の中に直接書かれている場合、小さな変更にも開発の作業が必要になります。

7｜引き継ぎの想定を聞けるか

「将来、別の会社が引き継ぐとしたら、何を渡せばよいですか」と質問します。この問いに具体的に答えられるかどうかが、最も分かりやすい指標です。答えられる会社は、引き継げる形で作っています。

AIを組み込んだシステムの場合に足す1つ

システム自体が生成AIのサービスを呼び出している場合は、指標をもう1つ足します。「使っているAIサービスを別のものに替えるとしたら、何日かかりますか」という質問です。サービス名や接続の設定が処理のあちこちに散っている作りだと、値上げや提供終了のたびに改修費が発生します。答えが数日で済むなら、呼び出しが一箇所にまとまっているという意味になります。運用に入ってからの体制の作り方はAIを組み込んだシステムの運用保守で扱っています。

7指標の判定

該当数の区切りはこの記事で置いた目安であり、公的な基準ではありません。点数そのものより、どの指標が欠けているかを見ます。

該当数	判定	取る行動
6〜7	保守できる状態にある	資料を受け取り保管する
4〜5	一部が不足している	不足分の作成を検収条件にする
3以下	引き継ぎが困難になる可能性が高い	第三者の確認を検討する

指標のうち、1番目（環境構築の手順書）と7番目（引き継ぎの想定）は、他が揃っていても欠けていると影響が大きい項目です。この2つが不足している場合は、該当数に関わらず補完を求めます。

そのまま送れる質問文

7項目を口頭で聞くと曖昧な返事になりがちです。文面で送り、回答も文面でもらいます。次の文面がそのまま使えます。「納品後の運用と、将来の引き継ぎに備えて、以下について確認させてください。すでに納品物に含まれている場合は、その資料名をお知らせいただければ十分です。新しい担当者がこのシステムを動かすための環境構築手順は、どの資料に載っているでしょうか。自動で動作を確認する仕組み（テスト）はありますか。ある場合、どの機能を対象にしているかもお知らせください。使用している外部の部品と、それぞれの版が分かる資料をいただけますか。変更の履歴は、どこで確認できるでしょうか。納品物のうち、主要なファイルが何をするものかを一覧で示していただけますか。接続先や業務上の基準となる数値は、どこで変更できるでしょうか。将来、当社が別の事業者へ引き継ぐ場合、何をお渡しいただけますか。」

回答をそのまま保管します。この回答自体が、次の事業者へ渡す資料になります。また「後で用意します」という回答が続く項目は、実際には存在しない可能性が高いと考えます。稼働中のシステムについて聞く場合も同じ文面で構いません。すでに納品済みであっても、資料の提供を求めること自体はごく普通のことです。

3か月後に確認すること

納品時に分からないことが、運用してみると分かります。3か月後に次を確認します。

確認すること	良い状態	問題がある状態
小さな修正の見積もり	内容に見合った金額	簡単そうな変更が高額
修正にかかる日数	数日	何を変えるにも数週間
修正後の不具合	ほとんど出ない	直すたびに別の場所が壊れる
質問への回答速度	その場で答えられる	調べないと分からない

3行目が最も分かりやすい兆候です。一箇所を直すと別の箇所が壊れる状態は、構造上の問題を示します。この状態が続く場合、追加の改修を重ねるより、作り直しを含めた検討が必要になります。

月額保守に何が入っているか

3か月も動かしていると、月額の保守契約が実際には何を引き受けているのかが見えてきます。運用が始まってから食い違いが出やすいのは次の5点です。どれも契約書のどこに書かれているかまで一緒に確かめておくと、あとで解釈が割れません。

確認すること	契約書で見る場所	曖昧なままだとどうなるか
障害の一次対応と復旧の責任	保守業務の範囲、対応区分	止まったときに誰が動くかで揉め、復旧が遅れる
外部部品の更新（脆弱性対応を含むか）	保守業務の範囲、除外事項	更新が誰の仕事でもなくなり、古い部品が残る
仕様変更をともなう改修が月額に含まれるか	保守業務の範囲、別途見積の条件	小さな変更のたびに別料金の交渉が起きる
対応時間帯と応答の目安	サービス水準、受付時間	夜間や休日の連絡先が無いことに障害時に気付く
契約終了時に渡されるもの	契約終了時の措置、資料の引渡し	次の事業者へ渡す資料が揃わず、作り直しに近づく

月額保守という言葉の中身は会社ごとに違うため、金額ではなく範囲を先に確定させます。同じ金額でも、障害対応だけを見ている契約と、部品の更新まで抱えている契約では、数年後に手元へ残るものがまったく違います。

費用については、相場を示す公的な統計を確認できませんでした。IPAと経済産業省の公表資料を2026年9月5日時点で当たった範囲では、初期開発費に対する保守費の割合といった数値は見当たりません。相場が出せない以上、金額の妥当性は他社比較ではなく内訳で判断します。見積もりを「監視／障害対応／更新／改修」の工程で割ってもらい、どの工程に何時間を見込んでいるかを出させると、比べる相手がいなくても高いか安いかを自分で説明できます。

発注書と検収条件に書く

納品後に依頼すると費用が発生します。7指標のうち資料に関わるものは、発注時に納品物として指定しておきます。次の文言で足ります。

• 納品物に、環境構築の手順書を含めること
• 納品物に、使用している外部部品の一覧と版を含めること
• 実施したテストの内容と結果を提出すること
• 変更の履歴を参照できる形で引き渡すこと
• 接続先や業務上の基準値は、処理と分離して設定できる形とすること
• 契約終了時、後任の事業者が引き継げる状態で一式を引き渡すこと

この6行は独自の基準ではありません。IPAの「非機能要求グレード」は、発注側と開発側が合意しておくべき非機能要求を6つの大項目へ整理しており、そのうちの一つが「運用保守性」です。残りは可用性、性能・拡張性、移行性、セキュリティ、システム環境・エコロジーで、全体では34中項目・116小項目・238メトリクスに分かれます。上の6行は、この体系のうち発注側が自力で確認できる範囲を抜き出したものだと考えてください（IPA「非機能要求グレード」、出典の確認日: 2026年9月5日）。

効くのは最後の1行です。「引き継げる状態で引き渡す」という条件があるだけで、作り方が変わります。法的な文言の整備は専門家に確認します。契約の考え方については、IPA（独立行政法人情報処理推進機構）が「情報システム・モデル取引・契約書」を公開しています。IPAの掲載ページから入手でき、納品物と検収の条件を整理する下地として使えます。（出典の確認日: 2026年8月25日）

仕様書がない場合

小規模な案件では、仕様書がないまま開発が進むことがあります。この場合、「何が正しい動作か」を判定する基準が存在しません。保守以前の問題です。完全な仕様書は不要ですが、次の4つだけは文書にします。開発の途中でも作れます。

1つめは、誰が使うかです。利用者の種類と、それぞれができることを書きます。2つめは主要な業務の流れで、画面の順序で構いません。3つめは判断が入る箇所と、その基準。金額の区分や、承認が必要な条件のことです。4つめは扱う情報の種類で、個人情報を含むか、取引先の情報を含むかを書きます。3つめは失われやすい情報です。数値の基準は開発者の記憶にしかないことが多く、担当が変わると誰も理由を説明できなくなります。

第三者に見てもらうかどうか

7指標で3以下だった場合や、3か月後の確認で問題が出た場合、開発した会社とは別の会社に見てもらう選択肢があります。ただし常に必要というわけではありません。

状況	第三者確認の要否
社内だけで使い、規模も小さい	原則不要。7指標の補完で足りる
業務の中心で使っており、止まると困る	検討する
今後も改修を重ねる予定がある	検討する
開発会社との継続が不透明	実施する
すでに改修のたびに不具合が出ている	実施する

依頼するときは開発した会社とは別の会社へ、確認してほしい範囲を絞って依頼します。「全部見てほしい」では費用が読めません。引き継げるかどうか、次の改修にどれだけかかるか、という2点に絞るだけでも判断材料になります。あわせて、報告書の形まで指定しておきます。静的解析の結果（指摘の件数と重要度の内訳）、引き継ぎに必要な資料の不足一覧、次の改修にかかる見込み工数の3点を紙で出してもらう形にすると、費用が読めて、複数社に当たったときの比較もしやすくなります。納品物の安全性の確認については生成AIの社内ルールに必要な項目とあわせて、委託先のAI利用の申告についても整理します。

よくあるご質問

納品後に7指標を確認しても間に合いますか

確認自体はできますが、修正費用の交渉力が下がります。検収条件に入れておくと、不足があった場合に納品前の対応として扱えます。既に納品済みの場合は、次の改修契約の条件に含めます。

社内にコードを読める人がいません

7指標のうち、資料の有無と再現性の確認は読めなくてもできます。読む必要があるのは構造の評価だけで、そこは第三者に依頼する形で補えます。全部を自社で判断する必要はありません。

保守できないと分かったらどうしますか

作り直しを即断せず、現在の仕組みで何年使うかを先に決めます。短期間で置き換える予定があるなら、資料の整備だけで足ります。長く使うなら、部分的な作り直しの範囲を検討します。

保守費用の相場はどのくらいですか

公的な統計として確認できる相場はありません。2026年9月5日時点でIPAと経済産業省の公表資料を当たりましたが、該当するデータは見つかりませんでした。金額の妥当性は、監視・障害対応・更新・改修のどれにいくら見ているかという内訳で判断します。内訳を出せない見積もりは、そもそも範囲が決まっていないという意味です。

今週やること

今週着手するなら、稼働中のシステムについて7つの質問を開発会社へ送るところまでです。回答が曖昧な項目が、そのまま将来の費用になります。自社で進めるか、外部に任せるかの切り分けから相談できます。お問い合わせはこちらです。