AIで作ったコード、半年後に誰がメンテする？ — 属人化を防ぐ運用保守の考え方

「動いた。これ、自分で作れちゃったな」——そう思った方は多いはずです。AIコーディングツール（Claude Code：Pro $20/月・Max $100〜200/月）を使う方は多いはず。Codex CLI（ChatGPT Plus $20/月〜）で、社内ツールが自分の手で形になる時代です。

ただ、現場でじわじわ効いてくる問題は作った瞬間には見えません。それは「半年後、これを誰がメンテするのか」という問いです。作った日の高揚感のなかでは、まず誰も考えない一行——でも、半年後のあなたは確実にこれを思い出します。

動かすところまでは AI が一気に連れて行ってくれます。けれど、作ったあとの「運用・保守・改修」は、想像以上に静かに、確実に重くのしかかってきます。この記事では、その重さの正体を分解して、見極め方を整理します。

なお本記事は、すでに AI で自分でツールを作れる段階の方を読者に想定しています。ツール選びの段階という方は、AIコーディングツールの比較・選び方はこちらから読むと、この先の保守の話が立体的に見えてきます。

まず確認：あなたのツールは「運用フェーズ」に入っているか

あなたのツールの状況	おすすめの読み方
一度動かして終わり・自分しか使わない	保守はほぼ不要。気軽に作り続けてOK
部署で毎週使う・止まると業務が困る	「4つの詰まりポイント」を重点的に
顧客に出す・お金やデータが絡む	全体を通して、特に「責任の所在」を最優先で

「止まっても自分が困るだけ」なら運用保守は軽い、「止まると他人や事業が困る」なら運用保守こそが本番——この一線が出発点です。

AI生成コードの運用保守で詰まる、4つのポイント

1. 属人化: AIに指示して作ったコードは、書いた本人ですら数ヶ月後には中身を忘れています。担当者が異動・退職したら誰も触れないツールが残り、「とりあえず動いてるから触らない」がブラックボックスを生みます。
2. 障害対応: AIが生成したコードは想定どおりの入力では綺麗に動きますが、現実の業務データは常に想定外を含みます。ログが残らず、テストもないと「直したつもりが別の場所を壊す」モグラ叩きが始まります。
3. セキュリティ更新: ライブラリやランタイムの更新を放置すると、ある日とつぜん脆弱性として問題になります。「動いてるから」と1年以上アップデートしないまま運用が続くのはよくあるパターンです。止まっていないこと＝安全ではありません。
4. 引き継ぎ: 属人化の最終形が引き継ぎ不能です。担当者が休んだ日に限ってツールが止まり、誰も対処できない——これは個人ではなく体制の問題です。

「自分で運用する」と「任せる」の境界線

全部任せましょう、という話ではありません。 作れる領域はどんどん自分で作ったほうがいい。問題は「運用保守の重さ」に応じて線を引くことです。

ツールの性質	運用保守の方針	理由
使い捨て・自分専用	自分で運用でOK	止まっても被害が小さく、AIが最も得意な領域
部署で常用・止まると困る	自分で運用＋設計レビューを一度入れる	エラー処理・引き継ぎ資料に一手間が要る
顧客向け・お金やデータが絡む	設計〜運用まで伴走を検討	被害が大きく、責任の所在が問われる

判断軸はシンプルに3つ。①止まったら誰が困るか、②直せる人が何人いるか、③データの重要度。「重い」に寄るほど、運用まで含めて設計できる相手を巻き込む価値が上がります。

「作る」と「持続的に運用する」は別のスキル

これは能力の問題ではありません。AIで7割、8割を自分で作れるようになったのは進歩ですが、「作れること」と「半年後も止めずに運用し続けられること」は、必要なスキルがそもそも違います。

実際、運用・保守まで踏み込んで作り切ると効果が一気に出ます。入退室ログと人事システムを自動でつなぐ仕組みを運用まで作り切った案件では、日次の集計作業が 2時間/日 → 5分/日（96%削減） になりました。月3件あった転記ミスも 0件（100%解消） です。共有リンク作成の自動化では 月17時間 が浮いた実績もあります。デモが動いた時点ではなく、運用に耐える形まで持っていったからこその数字です。

playpark は Web制作から業務改善、SaaS開発までを同じチームで対応しています。自社でもシフト管理のサービス（Shift Bud）を開発・運営し、日常的に AI コーディングツールを使う当事者です。だからこそ「ここは自分で運用できますよ」の線引きも率直にお伝えできます。

技術者向け：AI生成コードを「運用に乗せる」ときに増える論点

観点	動くだけのデモ	運用に乗せた状態
入力検証	ハッピーパスのみ	異常系・境界値の網羅
ログ	なし／print頼り	構造化ログ＋追跡可能性
エラー検知	落ちてから気づく	失敗を能動的に通知
テスト	手動で一度確認	自動テストで回帰を防ぐ
依存更新	放置	定期的な脆弱性対応の体制
引き継ぎ	本人の記憶	ドキュメント・運用手順

AIは各項目の「実装」は手伝ってくれますが、「どこまでやるべきかの線引き」と「壊れたときの責任分界」は人間の設計判断として残ります。ツールを併用する場合の運用設計は、Claude Code と Codex の共存運用ガイドも参考になります。

まとめ：運用保守を設計できると、AIの威力が伸びる

ツールの性質	運用保守	見るべきポイント
使い捨て・自分用	自分で運用でOK	失敗コストが低い
部署で常用	自分＋設計レビュー	ログ・テスト・引き継ぎ資料
顧客向け・データ重要	運用まで伴走を検討	障害対応・セキュリティ更新・責任の所在

「AIで作れる」は、もう揺るがない事実です。作る段階で「半年後、誰がどう面倒を見るか」まで一度想像してみる——これだけで、属人化やブラックボックス化のかなりの部分は防げます。

「うちのこのツール、このまま自分たちで運用していいのか」——その線引きに迷ったら、まずは現状を一緒に整理するところから始めませんか。具体的な相談先はAI実装支援からどうぞ。

この記事を読んだ方へ — 関連記事

• AIに書かせたコードのテスト、どこまで信用していいか — 自分で保守すると決めたら、次は品質。AIが書いたテストの「緑」が保証すること・しないこと