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

「動いた。これ、自分で作れちゃったな」——AIコーディングツール（Claude Code（Pro $20/月、Max $100〜200/月）や、ChatGPT のサブスク（Plus $20/月〜）に紐づく Codex CLI など、自然言語で開発を進められるツール）に指示を出して、これまで外注していたような社内ツールが自分の手で形になったとき、そう思った方は多いはずです。情シスの方も、技術に明るい経営者の方も、いま確実にこの段階に来ています。

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

動かすところまでは AI が一気に連れて行ってくれる。けれど、作ったあとの「運用・保守・改修」は、想像以上に静かに、確実に重くのしかかってきます。この記事では、その重さの正体を分解して、「放置すると詰むポイント」と「どこをプロに任せると楽になるか」を、あなた自身が見極められるように整理します。

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

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

同じ「AIで作ったツール」でも、運用保守の重さはまるで違います。最初にここを切り分けると、判断がぐっと楽になります。

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

ざっくり言うと、「止まっても自分が困るだけ」なら運用保守は軽い、「止まると他人や事業が困る」なら運用保守こそが本番——この一線が出発点です。作ること自体ではなく、作ったあと止まらず動き続けることに、本当のコストはあります。

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

「動くものが作れた」あとに、なぜ運用保守でつまずくのか。よくある詰まり方を4つに分けて見ていきます。

1. 属人化：作った本人しか中身がわからない

AIに指示して作ったコードは、書いた本人ですら数ヶ月後には中身を忘れています（自分で書いたはずのコードを「これ誰が書いたの？」と思う瞬間、地味につらいですよね）。ましてや AI が生成したコードは、なぜその実装になっているのかの背景がドキュメントに残りにくい。

結果、こうなります。

• 作った担当者が異動・退職したら、誰も触れないツールが残る
• 仕様変更の依頼が来ても「どこをいじれば壊れないか」がわからない
• 「とりあえず動いてるから触らない」が、改修できないブラックボックスを生む

便利なはずのツールが、いつのまにか「触ると怖いもの」に変わっていく。動いてはいるけど誰も中を開けたがらない——そんなツールが、気づけば社内に一つ二つ住み着いている。これが属人化の正体です。

2. 障害対応：止まったとき、原因にたどり着けない

デモで動くことと、本番で動き続けることは別の話です。AIが生成したコードは、想定どおりの入力（ハッピーパス）では綺麗に動きますが、現実の業務データは常に想定外を含んでいます。空欄、全角半角の混在、想定外の桁数、文字化け——。

そして本番で止まったとき、問われるのは「なぜ止まったのか」を追える状態になっているか、です。

• エラーが出ても、どこで何が起きたかのログが残っていない（手がかりゼロから犯人探し）
• 夜間バッチが静かに失敗していて、翌朝になるまで誰も気づかない（出社して気づくのが一番つらい）
• 直そうにも、テストがないので「直したつもりが別の場所を壊す」（モグラ叩きの始まり）

「動くものを作る」のは AI の得意分野ですが、「壊れたときに気づける・原因にたどり着ける」状態を設計するのは、また別の仕事なんですよね。

3. セキュリティ更新：気づかないうちに放置される

ツールが使っている部品（ライブラリやランタイム）には、定期的にセキュリティ上の更新が出ます。これを放置すると、ある日とつぜん脆弱性として問題になる。

内製ツールでありがちなのは、作って動いた時点で「完成」だと感じてしまい、その後の更新が誰の担当にもならないパターンです。

• 「動いてるから」と1年以上アップデートしないまま運用が続く
• 個人情報や取引先データを扱っているのに、更新方針が決まっていない
• いざ更新しようにも、テストがないので「更新して壊れたら怖い」と止まる

止まっていないこと＝安全、ではありません。むしろ動き続けているツールほど、誰にも気づかれないまま静かなメンテナンス（と、それを担う誰か）を必要としています。

4. 引き継ぎ：「あの人がいないと回らない」状態

属人化の最終形が、引き継ぎ不能です。「あの人がいないと、あのツールだけは触れない」——そんな名前が一つ二つ、頭に浮かぶ職場、案外少なくありませんか？　作った本人の頭の中だけに「どう動かすか」「壊れたらどうするか」が入っていて、外に出ていない。

• 担当者が休んだ日に限ってツールが止まり、誰も対処できない（休暇明けに待っているのは謝罪と火消し）
• 新しく入った人に渡そうにも、説明する資料が一切ない
• 結局「作った人が一生面倒を見る」前提で運用が回ってしまう（有給を取るたびに胃が痛い）

これは個人の問題ではなく、体制の問題です。ツールが事業に効いてくるほど、「特定の一人に依存しない形」にしておく価値が上がります。

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

では、どこまで自分でやり、どこからプロを巻き込むと楽になるのか。判断軸を整理します。全部任せましょう、という話ではありません。 むしろ、作れる領域はどんどん自分で作ったほうがいい。問題は「運用保守の重さ」に応じて線を引くことです。

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

判断のものさしは、シンプルに3つです。

1. 止まったら誰が困るか — 自分だけなら軽い。他部署・顧客・取引先に及ぶなら重い
2. 直せる人が何人いるか — 1人だけなら、その人が抜けた瞬間に止まる
3. データの重要度 — 個人情報・お金が絡むなら、セキュリティ更新は止められない

この3つで「重い」に寄るほど、自分一人で抱え込まず、運用・保守まで含めて設計できる相手を巻き込む価値が上がります。

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

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

実際、運用・保守まで踏み込んで「作り切る」と、内製の手前で止まっていた効果が一気に出ることがあります。たとえば入退室ログと人事システムを自動でつなぐ仕組み（システム同士を自動でデータ連携させる仕組み）を、異常なデータでも落ちない・夜間に自動で動く・壊れたら気づける、というところまで作り切った実際の導入案件では、日次の集計作業が 2時間/日 → 5分/日（96%削減）——毎朝の2時間が、コーヒーを淹れる間に終わる作業に変わりました。月3件あった転記ミスも 0件（100%解消）、「あの数字、合ってる？」と差し戻される気まずさごと消えています。共有リンク作成の自動化では 月17時間 が浮いた実績もあります（まる二日分の手作業が返ってくる計算です。いずれも実際の案件での計測値です）。

これらの数字は、デモが動いた時点ではなく、運用に耐える形まで持っていったからこそ出たものです。逆に言えば、ここを設計しないまま本番に乗せると、便利なはずのツールが「いつ止まるかわからない不安の種」になりかねません。

playpark の場合、Web制作から業務改善、SaaS開発までを同じチームで対応していて、自社でもシフト管理のサービス（Shift Bud）を開発・運営しています。AIコーディングツールを日常的に使っているからこそ、「ここは自分で運用できますよ」「ここは任せたほうが楽ですよ」の線引きも、率直にお伝えできます。そして法人として、作って終わりではなく、その後の運用・改修まで責任を持って伴走できます。

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

「動くもの」から「運用できる業務システム」への昇格でよく追加される観点：

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

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

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

整理すると、こういうことです。

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

「AIで作れる」は、もう揺るがない事実です。だからこそ、作る段階で「半年後、誰がどう面倒を見るか」まで一度想像してみる——これだけで、属人化やブラックボックス化のかなりの部分は防げます。作れる領域はどんどん作って、運用保守でつまずきそうな領域だけ、止まらない設計ができる相手を巻き込む。その境界線を引けるようになると、AIツールの威力を長く引き出せます。

「うちのこのツール、このまま自分たちで運用していいのか、それともどこかで体制を整えたほうがいいのか」——その線引きに迷ったら、まずは現状を一緒に整理するところから始めませんか。何を自分で持ち、何を任せると楽になるか、率直にお伝えします。具体的な相談先はplaypark のソリューション一覧からどうぞ。動かなくなってから慌てる前に、お気軽にご相談ください。