AIで作ったシステムが保守できません！を防ぐチェックリスト
AIツールで開発したシステムほど、実は保守できなくなるリスクを抱えがちです。属人化を防ぎ「本当に保守できる状態か」を見極めるための、7つのチェック項目を整理しました。
「保守できない」は、ある日突然発覚する
スタートアップや小〜中規模のシステムほど、少人数の中核メンバーで開発・運用を回しがちです。効率的な反面、担当者の離任や開発会社の変更、新人の加入といった場面で一気にボトルネックとなり、組織の競争力を静かに削っていきます。
AIの登場で既存コードの学習・改修コストは下がりました。一方で「誰も経緯を把握していない」情報が増えたり、情報が一元化されず分散するリスクも高まっています。保守できる状態を保つことは、人間側が意識してメンテナンスし続けるべき「全体最適化」の一つです。
本当に保守できるシステムかどうかを判定する、一番厳しいテストがあります。それは「今日、担当者が全員入れ替わっても回るか」――つまり引き継ぎができる状態かどうかです。以下の7つのチェックで、その状態にどれだけ近いかを確認できます。
チェック① システム全体を「なぜ」まで説明できる人がいるか
システムの全体像を、アーキテクチャやモジュール構成のレベルで「なぜこうなっているか」まで説明できるメンバーがいることは重要です。AIに細かいコードの中身を聞けるようになった今も、この役割は代替されていません。
AIは局所最適な機能追加を積み重ねる形で開発を進めます。「今どこに負債が溜まっているか」「何を優先して解消すべきか」を判断するには、情報を集約して全体を理解している人間が必要です。
引き継ぎの際は、可能な限り引き継ぎ元の開発者とのコミュニケーションパスを一定期間残しておくことも、将来のリスクを減らします。
チェック② デザインドキュメントが維持されているか
「ドキュメントはAIに作らせればいい」と思われがちですが、AIが再現できるのはソースコードから読み取れる仕様だけです。なぜその仕様になったか、なぜ変更したか、何が課題として残っているかは、能動的に記録しない限り残りません。
この経緯情報が失われると、例えば外部システムとのインターフェースで変えてはいけない値を誤って変更し障害を起こしたり、クライアントと合意した仕様との齟齬が発生したりします。担当者個人の暗黙知になりやすく、引き継ぎで最もトラブルになりやすい部分です。
アカウント情報やDNS設定など、コードの外で管理されがちな情報も見落とせません。可能な範囲でIaC（Infrastructure as Code）化し、コードから読み取れないものはドキュメントに残しておく必要があります。
- アカウント情報・DNS設定・SSL証明書
- バックアップ運用方針・シークレット管理
- テスト環境情報・メール/ログ設定・請求情報
チェック③ テストコードが維持されているか
テストコードは「こう動作すべき」という仕様を、実行可能な形で残したものです。変更のたびに既存機能が壊れていないかを確認するリグレッションテストとして機能し、自動テストがなければすべて手動確認が必要になり生産性が落ちます。
AIにコードを書かせる場面でも、テストコードは新機能を実装するAIに対して「正解となる動作」を伝える役割を果たします。特に引き継ぎ直後は品質リスクが高まりやすいため、テストコードの有無が既存機能の維持に大きく貢献します。
チェック④ 業務フローが可視化されているか
担当者が体で理解している業務フローほど、可視化されにくいものです。すでに分かっていることをわざわざ書き出すインセンティブが働かないためですが、引き継ぎの場面ではこれを次の担当者へ正確に伝える必要があります。
業務フローが不明瞭だと、複数システムや外部システムをまたぐ場面でのプロセスが分からず、障害時の連絡先や対応手順が不明になったり、機能変更の周知が漏れたりします。特に「システム化されていない部分」の業務フローほど複雑でクリティカルになりがちです。
AIの力を借りることで、こうした情報も以前より可視化しやすくなりました。システムと関連付けて、後任が理解しやすい形でドキュメント化しておくのが理想です。
チェック⑤ データベースの構造・経緯が残っているか
既存のデータベースのスキーマや業務フローから、全体の構造を理解すること自体はさほど難しくありません。ただし、個々のデータの中身や現在使われていないカラムといった情報は、コードだけでは読み取れず失われやすいものです。
過去にスキーマを変更してデータを修正した経緯や、障害対応でのデータ修正、運用変更で使わなくなったカラムなどは、コード上では埋もれがちです。これらを正確に引き継がないと、後から例えばユーザーデータの不具合を招くことがあります。
チェック⑥ 運用・オペレーションとの連携情報があるか
システムを引き継ぐ際に見落とされやすいのが、運用部門やバックオフィスとの連携です。システム担当と運用側のやり取りは、暗黙の前提知識で成り立っていることが少なくありません。
「よくある問い合わせ時の調査方法」や「障害復旧時の手続き・業務フロー」といった情報は、担当者レベルでは把握していても明文化されておらず、優先度の判断もつきにくいまま引き継がれてしまいがちです。
チェック⑦ 障害時のフローや過去の障害情報が残っているか
過去に発生した障害やインシデントの一覧、発生した経緯や原因は、そのシステムや組織が抱えてきた課題を具体的に言語化した資産です。AIに読み込ませて振り返りに活用することもできます。
現在も残っている課題とセットで参照できる状態にしておくと、次の担当者が同じ失敗を繰り返さずに済みます。障害対応のたびに記録を残す運用を、仕組みとして定着させることが大切です。
まとめ
7つのチェックに共通するのは、「情報が特定の個人の頭の中だけにあるか、組織の資産として残っているか」という一点です。
- システム全体を「なぜ」まで説明できる人がいるか
- デザインドキュメントが維持されているか
- テストコードが維持されているか
- 業務フローが可視化されているか
- データベースの構造・経緯が残っているか
- 運用・オペレーションとの連携情報があるか
- 障害時のフローや過去の障害情報が残っているか
私たちITものづくり株式会社では、これらの観点をもとに現状のシステムを調査し、リスクと対応方針をまとめる「コードベース健診」を提供しています。まずは自社の状態を客観的に把握したいという方は、お気軽にご相談ください。