「あの人が辞めたら、うちの請求システム誰も触れないでしょう」――半年後、その「あの人」は退職届を持ってきました。 残ったのは ドキュメント無き Python スクリプト 30 本 + VBA マクロ 50 個 + 暗黙の運用知識 だけ。後任は引き継ぎ書 1 枚を渡され、月末締めの請求処理が走らなかった夜、上司に呼び出されます。
これがバイブコーディング (vibe coding = AI に書かせて雰囲気で作る開発スタイル) 時代の 属人化リスク です。「動いている」と「継承可能」は完全に別物です。AI で簡単にシステムが作れる今、1 人が作って 1 人で運用するシステムが量産 されています。その人が辞めた瞬間、業務継続が崩壊します。
経済産業省「DX レポート」(2018-09) は 「2025 年の崖」 という言葉で、レガシーシステム保守人材の枯渇が 年間最大 12 兆円の経済損失 を生むリスクを警告しました。バイブコーディングは その崖を中堅企業規模で量産する 構造を持っています。
本記事は連載「バイブコーディング危機」第 8 回として、属人化が経営リスクになる 3 つの瞬間、公開事例 5 件、退職通知 30 日前 チェックリスト 10 項目、AI でドキュメント無きコードを継承可能化する 5 ステップ、ドキュメント生成 AI 5 ツール比較、90 日継承プラン、後任オンボーディング 14 項目、緊急 5 項目、FAQ を一次ソース 22 件で整理します。
**連載「バイブコーディング危機」**は、AI で自社システムを開発する中堅企業向けに、専門家不在で起きるリスクを1 本ずつ深掘りします。 第 1 回(概論 + 7 リスク類型) 第 2 回(SQL Injection) 第 3 回(認可漏れ) 第 4 回(江崎グリコ BCP) 第 5 回(DELETE FROM データ消失) 第 6 回(ランサム 気づかない 6 ヶ月) 第 7 回(法令違反 3 法令)
目次
- 「属人化システム」が経営リスクになる 3 つの瞬間(退職 / 病欠 / 監査)
- 公開事例 5:経産省 2025 年の崖 + みずほ + COCOA + COBOL 高齢化 + 自治体 RPA
- 退職通知 30 日前 チェックリスト 10 項目
- AI でドキュメント無きコードを継承可能化する 5 ステップ
- ドキュメント生成 AI 5 ツール比較
- 90 日継承プラン(属人化解消ロードマップ)
- 後任エンジニアのオンボーディング 14 項目
- 既存システムの「今すぐ」やる緊急 5 項目
- よくある質問(FAQ 12 問)
- 参考一次ソース
「属人化システム」が経営リスクになる 3 つの瞬間(退職 / 病欠 / 監査)
「属人化システム」が経営リスクとして顕在化するのは、いつも 「平常時には見えない」 3 つの瞬間です。
瞬間 1: 退職(最も予測可能、最も対策しやすい)
典型: 情シス 1 名 + 経理 1 名で 10 年運用してきた社内システム。情シス担当者が転職決意 → 退職通知 1 ヶ月前 → 後任未確保 → 引継ぎ書 1 枚 → 退職日。
実害:
- 月末締めの請求処理が走らなくなる
- 在庫管理マクロが壊れて出荷遅延
- 個人情報の取扱責任者が空席に
- 認証情報 (API key / クラウド admin / DB パスワード) が誰も知らない状態に
対策しやすい理由: 退職は通常 1-3 ヶ月前に通知される → 計画的継承が可能です。やらない企業に責任があります。
瞬間 2: 病欠 / 事故 / 災害(予測不能、最も危険)
典型: 情シス担当者が休日のスキー事故で 2 ヶ月入院。代替できる人材なし。社内の請求 / 在庫 / 出荷システムがブラックボックス化したまま 2 ヶ月。
実害:
- 業務継続不能 (江崎グリコ 4 ヶ月停止と類似インパクト、第 4 回参照)
- 緊急時の障害対応が回らない (連絡先 / 復旧手順 不明)
- 取引先・顧客対応が混乱
- 復職時には業務が止まっている / 退職に追い込まれる二次被害
対策の難しさ: 予測不能なため 「いつ起きても対応できる体制」 が必要です。退職対策とは別です。
瞬間 3: 監査 / 税務調査 / 顧客監査(予測可能だが見えにくい)
典型: 取引先からの 「セキュリティチェックシート」 が来ます。または税務調査で「電子取引データを見せてくれ」と要求されます。「すみません、あの担当者が辞めてから誰も触れません」 では通りません。
実害:
- 取引先との契約打ち切り / 新規取引機会喪失
- 税務調査時の説明不能 → 追徴課税
- 内部統制不備 → 上場企業なら適時開示 / 改善命令
- ISO 27001 / SOC 2 等の認証取消 (該当する場合)
対策の難しさ: 「監査要件 = ドキュメント化義務」 を平時から守る習慣が必要です。
3 瞬間に共通する根本問題
| 問題 | 詳細 |
|---|---|
| ドキュメント不在 | システム仕様書 / 運用手順書 / 障害対応書 がない |
| 認証情報の集約 | 1 人の頭の中にパスワード / API key / SSH 鍵がある |
| 暗黙の運用ルール | 「月末はこの順番で実行」「○○の時は△△を呼ぶ」が口頭伝承 |
| 後任候補不在 | 採用 / 育成計画なし、その人が辞めたら詰む構造 |
バイブコーディング環境では 4 つすべてが同時成立しやすくなります。「動くものができた → 本番運用 → 1 人で持ち続ける」のループが原因です。
AI ASSESSMENT
PoC の前に「そもそも使えるか」を30分で見極めませんか?
情シス部門の稟議書作成をサポートする無料の30分壁打ち。ROI 試算シート・失敗要因チェックリストをその場で共有します。
公開事例 5:経産省 2025 年の崖 + みずほ + COCOA + COBOL 高齢化 + 自治体 RPA
各事案は 「当時の状況下で発生したもの」 であり、「バイブコーディング起因」と断定するものではありません。中堅企業のバイブコーディング環境で 同種の継承失敗が発生する確率が高い という観点で参照します。
事案 1: 経産省「DX レポート」2018-09「2025 年の崖」警告
概要: 経済産業省が 2018 年 9 月に発表した「DX レポート」で、「2025 年の崖」 という言葉が登場しました。日本企業のレガシーシステム保守が技術者高齢化 + 後継不足で困難化、放置すれば 2025 年以降に年間最大 12 兆円の経済損失 を生むと警告しています。
主要な指摘:
- 既存システムの保守費用が IT 予算の 80%+ を占有、新規投資不足
- COBOL 等のレガシー技術者が 2025 年に大量退職予定
- ブラックボックス化したシステムの引継ぎ困難
- 中堅企業ほどこの問題が深刻 (人材確保困難)
結果:
- 「2025 年の崖」が IT 業界全体の警鐘ワードに定着
- 経産省「DX 推進ガイドライン」「DX 認定制度」発足
- IT 投資の優先度見直し議論
バイブコーディングとの関連: AI で簡単にシステムが作れる時代こそ、「動くが継承不能」のレガシー を中堅企業規模で量産しています。バイブコーディングは「2025 年の崖」を 2027 年・2030 年・2035 年と先送り するのではなく、より早期に低い規模で発生 させる可能性が高いといえます。
出典:
事案 2: みずほ銀行 2021-2022 システム障害(年間 10+ 件)
概要: みずほフィナンシャルグループのシステム障害が 2021-2022 年に 年間 10 件以上 連発しました。ATM 全停止、振込不能、勘定系ダウン等です。原因の一つとして 「MINORI システム (基幹) の属人化 + 統合の失敗」 が公式調査委員会報告書で指摘されました。
MINORI システム背景: 2019 年完全稼働、19 年以上開発、4,000 億円超の投資。第一勧銀 / 富士銀行 / 日本興業銀行の 3 行統合の集大成として構築されましたが、システム理解者の集約、部門間連携の不備 が継続的に問題視されていました。
公式調査委員会の指摘 (2021-06「業務改善計画」より):
- システム理解者がサイロ化、横断的に把握する人材が不足
- 障害発生時の指揮命令系統が機能不全
- ドキュメント整備が部門単位で異なる
- 教育 / 継承プロセスの体系化不足
結果:
- 金融庁から 行政処分 (業務改善命令)
- 社長 + 銀行頭取の辞任
- 全社的なシステム理解 / ガバナンス改革
バイブコーディングとの関連: メガバンクという最大級の人材・予算がある組織でも、システムの属人化 + 継承不備は経営を揺るがすリスク になります。中堅企業のバイブコーディング環境では、より少ない人数で、より高速にこの構造が成立します。
出典:
事案 3: 新型コロナ接触確認アプリ COCOA の保守破綻(2020-2022)
概要: 2020 年 6 月リリースの 新型コロナウイルス接触確認アプリ COCOA が、約 4 ヶ月間 Android 版が機能停止していた (2020-09 〜 2021-02) ことが 2021 年 2 月に判明しました。検査体制が機能せず、保守体制の不備が露呈しました。
技術的原因 (デジタル庁 + 厚労省合同会議報告書より):
- 主要開発者が複数の業務委託先にまたがり、保守責任が不明確
- Google Apple の Exposure Notification API 更新時のテストが回らなかった
- 不具合報告から修正までのフィードバックループが機能不全
結果:
- 厚生労働省が陳謝、COCOA 保守体制を見直し
- 2022 年 11 月に COCOA 機能停止 (ワクチン接種進捗 + 行動制限緩和の文脈)
- デジタル庁が GovTech 全般のドキュメント整備 + 継承体制ガイドラインを強化
バイブコーディングとの関連: 「外部委託先のサイロ化 + 保守責任の不明確化」 は、中堅企業が SIer に発注する場合も同様です。「誰が責任を持って改修するか」 が文書化されていないと、退職 / 委託契約終了で COCOA と同じ構造が起きます。
出典:
事案 4: COBOL 技術者高齢化問題(IPA / 経産省)
概要: 金融機関 / 保険会社 / 公官庁の基幹システムは COBOL で書かれたものが多く、現役 COBOL 技術者の平均年齢が 50 歳超 (IPA 調査) とされています。新規育成が困難で、退職とともにメンテナンス不能になるリスクがあります。
統計 (IPA「IT 人材白書」+ 経産省 DX レポート):
- 国内 COBOL コードベース: 数十億行規模 (推定)
- 現役 COBOL 技術者: 高齢化 + 減少傾向
- 大学・専門学校での COBOL 教育: ほぼゼロ
- 既存コードのドキュメント化: 進捗遅延
結果:
- 金融機関の基幹システム移行プロジェクト連発 (みずほ / SMBC / 三菱 UFJ 等が大規模投資)
- COBOL 専業の SIer に依存 → 価格高騰
- 「2025 年の崖」の主要原因の 1 つ
バイブコーディングとの関連: 「あと数年後に保守不能になる」負債の塊 を、AI で簡単に作れる時代に より小さい規模で量産 すれば、未来の「2030 年の崖」を中堅企業規模で生むことになります。
出典:
事案 5: 自治体 RPA 担当者退職問題(各種報道)
概要: 自治体で導入された RPA (Robotic Process Automation) が、導入担当者の退職 / 異動で動かなくなる 事案が複数報告されています。「動いていた RPA が突然エラー」「メンテできる人がいない」が典型パターンです。
典型 (一般的な報道傾向):
- 1-2 名の RPA 担当者が WinActor / UiPath で 50-100 シナリオ構築
- 異動 / 退職で担当者が代わると、エラー対応不能
- 結果として RPA 全廃、人手作業に逆戻り
- 投資 数百万 - 数千万円が無駄に
結果:
- 総務省 / 自治体 DX 担当部局が RPA ガバナンス強化を勧告
- 「RPA 導入時点で継承体制を必須化」する自治体が増加
- 一部自治体は「RPA 撤退」を決定
バイブコーディングとの関連: 「1 人で作って 1 人で運用する」構造は、AI による開発加速で量産されます。RPA から任意のバイブコーディングシステムへと同じ構造が広がります。
出典:
- 総務省「自治体 DX 推進計画」
- 各種報道 (自治体特有の RPA 事例は地方紙・専門メディア)
5 件の共通パターン
| 共通点 | 該当事案 |
|---|---|
| ドキュメント不足 / 属人化 | 経産省 2025 年の崖 / みずほ / COCOA / COBOL / 自治体 RPA |
| 後継人材不在 | COBOL / 自治体 RPA / みずほ部分的 |
| 委託先サイロ化 | COCOA / 自治体 RPA |
| 経営層への警告無視 | 2025 年の崖 / みずほ部分的 |
| 復旧不能 / 撤退 | COCOA / 自治体 RPA |
退職通知 30 日前 チェックリスト 10 項目
エンジニア / 情シス担当者から退職通知が来た瞬間にやるべき 10 項目です。
チェック 1: リポジトリ アクセス権 棚卸(実施: Day 1)
- GitHub / GitLab / Bitbucket の組織アカウントで該当者の権限を確認
- 退職者個人アカウント からの commit / push 履歴を一覧化
- 退職日に 個人アカウント権限を全削除
- 個人アカウントで作成した repo があれば組織 repo に移管
チェック 2: 認証情報 (パスワード / SSH キー / API key) 完全棚卸(実施: Day 1-3)
□ AWS / GCP / Azure コンソール ログイン情報
□ DB 接続情報 (本番 / ステージング / 開発)
□ SSH 鍵 (各サーバ)
□ API key (Stripe / SendGrid / Twilio / OpenAI 等)
□ ドメイン管理者アカウント
□ DNS 管理者アカウント
□ SSL 証明書 管理者
□ 監視ツール (Datadog / Mackerel / 等) 管理者
□ Slack / Microsoft Teams Workspace 管理者
□ Google Workspace / Microsoft 365 管理者
- 退職日に全パスワード変更 + 鍵 rotation
- API key は新規発行 + 旧キー無効化
チェック 3: クラウドアカウント / SaaS 契約名義 移管(実施: Day 3-7)
- 個人名義で契約されている SaaS / クラウドを全リストアップ
- 会社名義 / 共有メールアドレス名義に移管
- 個人クレジットカード払いになっているサービスを社用カードに切替
チェック 4: ドキュメント作成依頼(実施: Day 1 - 退職日)
- システム仕様書 (主要 5 システム)
- 運用手順書 (日次 / 週次 / 月次 / 年次 / 緊急時)
- 障害対応書 (過去 1 年の障害事例 + 対応履歴)
- 連絡先リスト (取引先 / ベンダー / クラウド SE)
書ききれないものは「動画化」で代替: Zoom 録画で 30 分 × 5-10 本撮影、Notion / Google Drive にまとめます。
チェック 5: コードレビュー全件(実施: Day 7-14)
- 過去 1 年の主要 commit を後任 (or 暫定後任) と一緒にレビュー
- 「なぜこの実装にしたか」「想定外パターン」「リスク」 を口頭で説明 → メモ化
- AI ツール (Claude Code / Cursor) で要約も並行
チェック 6: dev → ステージング → 本番 デプロイフロー文書化(実施: Day 7-14)
- 全システムのデプロイ手順を文書化
- CI / CD 設定の解説
- ロールバック手順 (連載第 5 回参照)
- 緊急時の手動デプロイ手順
チェック 7: 取引先 / ベンダー 連絡先 共有(実施: Day 14-21)
- SIer / クラウドベンダー SE / セキュリティベンダー
- 各社の 「24h 緊急連絡先」 を明確化
- 後任との顔合わせミーティング (営業 + 技術両方)
チェック 8: 暗黙知の動画化(実施: Day 14-21)
- 「画面録画 + 口頭解説」 で 30 分 × 5-10 本
- 内容例:
- 月末締めの実行順序
- クラウドコスト最適化のコツ
- よくある障害パターンと対応
- 取引先別の独特な対応ルール
- 動画は Google Drive / Notion で全社員アクセス可能に
チェック 9: cron / バッチジョブ / スケジュールタスク 全件棚卸(実施: Day 14-21)
# Linux サーバの cron 一覧
crontab -l
ls /etc/cron.*/
# Windows サーバのスケジュールタスク
schtasks /query /fo LIST
# クラウド (AWS EventBridge / GCP Cloud Scheduler / Azure Functions Timer)
aws events list-rules
gcloud scheduler jobs list
- 各ジョブの 目的 / 依存関係 / 失敗時のリカバリ を文書化
- 不要なジョブは退職前に削除 (整理)
チェック 10: 後任との 1on1 週次(実施: Day 1 - 退職日)
- 毎週 1 時間、後任 (or 暫定後任) と 1on1
- ドキュメント化進捗 + 疑問点 解消
- 退職後の連絡可能性 (緊急時のみメール OK 等) を合意
チェックリスト実施の心構え
- 「やらせる」のではなく「一緒にやる」: 退職者の心情に配慮し、嫌がらせと受け取られないようにします
- 退職金 / 有給消化との両立: 法的に保護される権利を侵害しない範囲で
- 金銭的インセンティブ: 「30 日チェックリスト完了で 退職金 + α」を約束する企業もあります
- 後任未確保時の対応: 「暫定的に外部 SE / 外部 CTO に引継ぐ」も視野に
AI でドキュメント無きコードを継承可能化する 5 ステップ
退職者がドキュメントを残さなかった (or 残せない) 場合、AI に既存コードを「読ませて」継承可能化 する手順です。
Step 1: コードを AI に流し込む(所要時間: 1-2 日)
対象:
- Python / Ruby / Node.js / Go 等の業務スクリプト
- VBA マクロ (Excel / Access)
- Excel 関数 (複雑な SUMIFS / VLOOKUP / Power Query 等)
- Shell スクリプト / Batch ファイル
- SQL クエリ
ツール:
- Claude Code (Anthropic、リポジトリ全体を読ませる)
- Cursor (IDE 統合、複数ファイル一括コンテキスト)
- GitHub Copilot Workspace (リポジトリ全体での改修)
- Devin (Cognition AI、自律エージェント)
プロンプト例 (Claude Code):
このリポジトリの全ファイルを読み、以下を行ってください:
1. 各ファイルの目的を 1 文で説明
2. ファイル間の依存関係を可視化 (Mermaid)
3. 「想定される入力 / 出力」を関数単位で抽出
4. 「触ると危ない箇所」を 5 つ抽出
5. ドキュメント化が必要な暗黙知を 5 つ抽出
Step 2: コードコメントの自動生成(所要時間: 2-3 日)
- AI に各関数 / クラスにコメントを追加させる
- 「なぜこの実装か」を推測 + 明示
- 既存コードへのコメント挿入 PR を作成 → 後任 + 退職者でレビュー
プロンプト例:
このファイルの全関数に、以下のフォーマットで JSDoc / docstring を追加してください:
- 関数の目的 (1 文)
- 引数 (型 + 説明)
- 戻り値 (型 + 説明)
- 想定エラー / 例外
- 関連する関数 / 外部 API
- 「触ると危ない」場合はその理由
Step 3: 単体テストの自動生成(所要時間: 3-5 日)
- AI に既存コードの単体テストを書かせる
- カバレッジ計測 (Python なら pytest-cov / Node.js なら jest --coverage)
- カバレッジが低い箇所は 「テスト書けない = 仕様不明」 として要調査
プロンプト例:
このファイルの全関数に対し、以下を含む単体テストを pytest / jest / RSpec で書いてください:
- 正常系 (3-5 ケース)
- 異常系 (3-5 ケース、null / 空 / 型不一致 / 範囲外 等)
- 境界値 (2-3 ケース)
- モック化が必要な外部依存 (DB / API / ファイル) は明示
Step 4: アーキテクチャ図の自動生成(所要時間: 1-2 日)
- AI にコードを読ませて Mermaid / PlantUML / draw.io 形式の図を出力させる
- データフロー / コンポーネント関係 / シーケンス図
- README / Wiki に貼る
プロンプト例:
このリポジトリ全体を読み、以下の図を Mermaid 形式で出力してください:
1. コンポーネント図 (主要モジュールとその関係)
2. シーケンス図 (月次バッチ処理の流れ)
3. ER 図 (DB スキーマ)
4. データフロー図 (外部 API → 内部処理 → DB)
Step 5: リファクタリング候補の抽出(所要時間: 2-3 日)
- AI に「改善余地」を提案させる
- ただし 即時リファクタしない、後任が読解してから実施
- 改善優先度 + 想定リスク を整理
プロンプト例:
このリポジトリのコードを読み、以下を提案してください:
1. リファクタリング候補 (10 個、優先度つき)
2. 削除可能と思われるコード (Dead code、3 個)
3. パフォーマンス改善余地 (5 個)
4. セキュリティ懸念 (5 個、OWASP Top 10 観点)
5. テスト不足箇所 (5 個)
ただし、実行や変更は提案のみで、コード修正は行わないでください。
5 ステップ実施の注意点
- 退職者の同意を取る (倫理的 + 契約的観点)
- 機密データを AI に流し込まない (個人情報 / 認証情報 / 顧客情報 はマスク)
- AI の出力は鵜呑みにしない、後任 or 外部 CTO で必ずレビュー
- 「ドキュメント完成 = ブラックボックス解消」ではない、運用経験は時間が必要
ドキュメント生成 AI 5 ツール比較
中堅企業向けの、ドキュメント生成 AI ツールの比較です。
比較表
| ツール | 形態 | 料金 (目安) | 強み | 弱み |
|---|---|---|---|---|
| Claude Code (Anthropic) | CLI + API | 従量課金 (API トークン単価) | リポジトリ全体把握、コード理解精度高 | CLI 環境 必須 |
| GitHub Copilot Workspace | クラウド SaaS | Copilot Business: 月額約 $19/user | GitHub 統合、PR 単位での改修支援 | GitHub リポジトリ前提 |
| Cursor | デスクトップ IDE | Pro: 月額 $20、Business: $40 | VSCode フォーク、複数ファイル コンテキスト | デスクトップ環境 必須 |
| Devin (Cognition AI) | クラウド エージェント | 月額 $500+ (Team プラン) | 自律的タスク完了、PR まで自動 | コスト高 |
| Mintlify Writer | ブラウザ拡張 + SaaS | 無料枠 + 有料 | ドキュメント生成特化、UI 綺麗 | コード理解の深さは劣る |
参考:
中堅企業向け選び方フロー
予算重視 + 既に GitHub 利用 → GitHub Copilot Workspace
予算 OK + 最強コード理解 → Claude Code
IDE 内で完結したい → Cursor
完全自動化したい (PR まで) → Devin (予算余裕あれば)
ドキュメント生成のみ → Mintlify Writer
複数ツール併用パターン
中堅企業の実用構成例です。
| 用途 | ツール |
|---|---|
| 日常開発 + コードレビュー支援 | Cursor + Copilot |
| リポジトリ全体ドキュメント化 | Claude Code |
| ドキュメント文書整形 | Mintlify Writer |
| 検証 + 高度な改修 (たまに) | Devin |
複数ツール併用で 月額 5-15 万円程度、ドキュメント化工数 50% 削減が現実的です。
90 日継承プラン(属人化解消ロードマップ)
退職者の有無に関わらず、「属人化を解消し続ける」習慣 を中堅企業に定着させるための 90 日プランです。
Week 1-2: 現状棚卸し(20h)
- 全システムを「主担当者」軸でリストアップ
- 「1 人しか触れないシステム」 をマークで集計
- 全認証情報 / API key / SSH 鍵を棚卸 (連載第 3 回 認可漏れ と統合可)
成果物: 属人化リスクマップ (Excel 1 シート)
Week 3-4: ドキュメント生成 AI 導入(10h)
- Claude Code / Cursor / Copilot のいずれかを情シスに展開
- 既存リポジトリで Step 1-4 を 試行
- 自社の運用に合わせて プロンプトをカスタマイズ
成果物: 主要 5 システムの README.md + アーキ図 + テストカバレッジ レポート
Week 5-6: 認証情報 共有化(15h)
- パスワードマネージャ (1Password Business / Bitwarden / LastPass) 全社展開
- API key を 環境変数 + Secret Manager (AWS Secrets Manager / GCP Secret Manager) で管理
- 個人名義の SaaS を会社名義に移管
成果物: 全認証情報の共有化、個人ロックなし
Week 7-8: 運用手順書整備(15h)
- 日次 / 週次 / 月次 / 年次 / 緊急時 の運用手順書を作成
- AI 支援 (Mintlify Writer) でフォーマット統一
- 主要 5 業務システム分
成果物: 運用手順書 5 セット
Week 9-10: 後任候補 オンボーディング(15h)
- 既存社員 1-2 名を後任候補として指名
- 14 項目オンボーディング (後述) を実施
- 主担当者の業務を 50% シャドーイング
成果物: 後任候補のシステム理解度 80% 以上
Week 11-12: 演習 + 改善(10h)
- 「主担当者が 1 週間休暇取得」シミュレーション
- 後任候補のみで業務を回す
- 詰まった箇所をリスト化 → ドキュメント追記
成果物: 改善版ドキュメント + 後任の自立度
90 日後の到達目標
- 全システムに 主担当 + 副担当 の 2 名体制
- 全認証情報の共有化 (個人ロックなし)
- 主要システムのドキュメント完備 (README + アーキ図 + 手順書)
- AI ツール定常利用、新規コードも継承可能な状態で量産
- 演習で 後任候補が 1 週間業務継続可能
コスト
- AI ツール: 月 5-15 万円 (Claude / Cursor / Copilot 等)
- パスワードマネージャ: 月 1-3 万円 (Business plan)
- 人件費: 90h × 1-2 名 = 50-100 万円相当
- 合計年 100-300 万円、退職リスクが 1 回顕在化したら数千万円〜数億円規模の損失リスクを抑制
後任エンジニアのオンボーディング 14 項目
属人化解消した後、新規後任エンジニアを 30 日でオンボーディング するための 14 項目チェックリストです。
法務 / コンプラ系 (Day 1)
□ 1. 入社時 NDA + 個人情報取扱規程の確認
□ 2. アクセス権限 ポリシーの説明 (最小権限)
システム全体理解 (Day 1-7)
□ 3. 全システムの俯瞰図 + 主担当 / 副担当の紹介
□ 4. データフロー + 主要外部 API + クラウド構成
□ 5. ドキュメント保管場所 (Notion / Wiki / GitHub Wiki) のツアー
コード読み込み (Day 7-14)
□ 6. 主要リポジトリ 5 つの README + アーキ図 通読
□ 7. AI ツール (Claude Code / Cursor) のセットアップ + 1 リポジトリ走らせる
□ 8. 過去 1 年の主要 PR + 障害対応 ログ通読
運用ハンズオン (Day 14-21)
□ 9. 日次運用 (ログ確認 / アラート対応) シャドーイング
□ 10. 月次運用 (締め処理 / レポート) シャドーイング
□ 11. ステージング環境への デプロイ実践
障害対応 (Day 21-28)
□ 12. 過去障害の事例研究 (5 件)
□ 13. テーブルトップ演習 (障害シナリオ) 参加
□ 14. 緊急連絡先 + エスカレーション フロー 暗記
オンボーディング達成基準
- 30 日後に 1 人で日次運用を回せる
- 60 日後に 小規模な改修 PR を提出できる
- 90 日後に 本番デプロイを単独実行できる
既存システムの「今すぐ」やる緊急 5 項目
「90 日プランは分かった、でも来週何する?」という経営者向けに、今週中にやる 5 項目 です。
緊急 1: 「あの人辞めたら詰む」システムリスト化 (1h)
- 全社員にヒアリング: 「主担当が 1 人しかいないシステム / ツール / ファイル」
- リストにして経営層と共有
- 致命度 (停止時の業務影響) でランク付け
緊急 2: 認証情報 (パスワード / API key) 棚卸 (2h)
- 全システムの認証情報を棚卸
- 個人 PC のメモ / 個人メール / 個人 Notion に存在する情報を会社共有に移管
- パスワードマネージャ未導入なら 今週中に Bitwarden / 1Password 試用開始
緊急 3: クラウド / SaaS の管理者名義確認 (1h)
- AWS / GCP / Azure / GitHub / Slack / Google Workspace の管理者名義
- 個人名義 のものは会社名義 / 共有メールアドレス に移管
- 個人クレジットカード払いも社用カードに切替
緊急 4: cron / バッチジョブ全件 ドキュメント化 (1-2h)
- 全サーバ / クラウドで動いている cron / EventBridge / Scheduler を全件抽出
- 各ジョブの目的 / 失敗時影響 を 1 行で文書化
- 不明なジョブは 「触らずそのまま」 にして担当者特定
緊急 5: 主要システム 5 つの README に 「主担当 / 副担当 / 緊急連絡先」を追記 (30 分)
## システム情報
- **主担当**: 山田太郎 (yamada@example.com / Slack: @yamada)
- **副担当**: 鈴木花子 (suzuki@example.com / Slack: @suzuki)
- **緊急連絡先**: 03-XXXX (24h)
- **外部 SIer**: ABC 社 (sla@abc.com / 03-XXXX)
- **クラウド SE**: AWS Business Support (Web ケース起票)
- **最終更新**: 2026-05-28
5 項目で見つかったら、72h 以内にやる
- 「あの人辞めたら詰む」リスト → 副担当を即時指名 + シャドーイング開始
- 認証情報個人保管 → パスワードマネージャ展開
- 個人名義クラウド → 会社名義移管
- 不明 cron → 担当者特定 + 文書化
- README 連絡先未記載 → 即時追記
よくある質問(FAQ 12 問)
Q1. 「あの人辞めたら詰む」状態の解消、最低コストの方法は何でしょうか?
A. 副担当指名 + 週 1 シャドーイング + AI ドキュメント生成 の組み合わせです。AI ツール代 月 5 万 + 副担当の工数 週 2-3h で、3-6 ヶ月でブラックボックス解消が可能です。即時着手こそが最低コストです。
Q2. 退職者がドキュメント作成を拒否したらどうすればよいでしょうか?
A. 金銭的インセンティブ + 法的助言 の併用です。
- 退職金 + α (10-30 万円) を提示、ドキュメント完了で支払い
- 雇用契約 / 就業規則に「業務引継ぎ義務」明記 (退職金減額条件)
- 顧問弁護士に相談 (悪質な場合は損害賠償請求も)
ただし 円満退職 が長期的には最善であり、強硬手段は最終手段にとどめましょう。
Q3. AI に既存コードを読ませる際、機密データ漏えいリスクはどうでしょうか?
A. 個人情報 / 認証情報 / 顧客情報は必ずマスクしましょう。安全な選択肢は以下です。
- Claude Code / Cursor の Privacy モード (データを学習に使わない)
- GitHub Copilot Business / Enterprise (学習に使わない契約)
- Azure OpenAI Service (Microsoft 経由、データ保管 region 選択可)
- オンプレミス / プライベートクラウド版 (Cohere / IBM watsonx 等)
連載第 7 回 改正個情法 海外移転対応 と整合します。
Q4. 後任が未確保のまま退職日になったらどうすればよいでしょうか?
A. 外部 SE / 外部 CTO に暫定継承 が現実解です。月 30-100 万円で 3-6 ヶ月対応してもらいながら、社内採用 / 育成を進めます。「採用できないなら外注」 が最後の砦です。
Q5. ベテラン社員が「自分しかできない」をプライドにしている場合はどうすればよいでしょうか?
A. 「あなたが休めない / 異動できない」というメッセージとして再フレームしましょう。
- 「副担当育成は あなたの昇進条件」 と人事評価に組み込む
- 「副担当育成完了で あなたは別の新プロジェクトに昇格」 と機会提供
- ドキュメント化 / 育成スキルを評価指標化
ベテランも「成長 / 認知 / 昇進」を望んでおり、属人化への執着は単なる不安の表れであることが多いといえます。
Q6. RPA / ノーコードツールも継承の対象でしょうか?
A. 対象です。RPA (UiPath / WinActor / Power Automate) / ノーコード (kintone / Bubble / Airtable) も同様の属人化リスクがあります。シナリオ / フロー設計書 + 動画化 + 副担当 を必ず 用意しましょう。
Q7. SaaS の管理画面 設定も継承対象でしょうか?
A. 重要な対象です。Salesforce / HubSpot / freee / Slack 等の管理画面設定は 設計者が辞めたら触れない リスクが高いです。設定変更履歴 + 設定意図 を Notion / Wiki に記録し、定期スクリーンショット保管をおすすめします。
Q8. 退職者の連絡先を退職後も保持するのは違法でしょうか?
A. 本人同意があれば可能です。退職時に「退職後 1 年間、緊急時のみ連絡可能」の同意書を取りましょう。連絡頻度 / 対価 (1 時間 5,000 円〜) を明確化します。
Q9. 個人事業主 / フリーランス委託先の継承はどうすればよいでしょうか?
A. 業務委託契約に「契約終了時 引継ぎ義務」+ 「ドキュメント納品物」 を明記しましょう。契約終了 1-3 ヶ月前から継承期間を確保します。SaaS 開発委託の場合は ソースコード + ドキュメント + 認証情報 を成果物として明示します。
Q10. 上場企業の場合、属人化解消は内部統制要件でしょうか?
A. 該当します。金融商品取引法 J-SOX (内部統制報告制度) で 「IT 全般統制 (ITGC)」 が要求されます。属人化システムは 「適切な権限管理 + 変更管理 + 運用管理」 が困難 → 内部統制不備として開示対象となります。年度監査で指摘されると有価証券報告書に記載必須です。
Q11. 中小企業 (従業員 30 名以下) でも 90 日継承プランは必要でしょうか?
A. 必要であり、むしろ重要です。中小ほど 1 人が複数業務を兼ねる属人化が深刻です。最小コストで AI ツール + 副担当指名 + ドキュメント化を回しましょう。社員が 1-2 名辞めるだけで業務継続不能になる規模ほど BCP として必須です。
Q12. AI が将来 完全に保守してくれる時代は来るでしょうか?
A. 部分的には Yes、完全には No (当面) です。AI コーディングエージェント (Devin / Claude Code 等) は急速に進化しており、定型保守は自動化が可能です。ただし 業務文脈の理解 / 取引先との関係性 / 例外的判断 は当面人間が必要です。「AI + 人間 1 名」 の体制が現実解であり、「AI 単独」 はまだおすすめできません。
参考一次ソース
本記事の事実認定で参照した一次ソース一覧です。
経済産業省 関連
- 経済産業省「DX レポート ~IT システム『2025 年の崖』克服と DX の本格的な展開~」(2018-09-07)
- 経済産業省「DX レポート 2」(2020-12)
- 経済産業省「DX レポート 2.1」(2021-08)
- 経済産業省「DX 推進ガイドライン」
みずほフィナンシャルグループ 関連
COCOA 関連
COBOL / 人材白書 関連
自治体 DX / RPA 関連
AI コーディングツール
パスワードマネージャ / Secret 管理
J-SOX / 内部統制
IPA / JPCERT/CC
まとめ:「あの人しか触れないシステム」を「AI + 副担当」に変える
本記事の要点を 7 行で整理します。
- 属人化が経営リスクになる 3 瞬間 = 退職 / 病欠 / 監査、対策しやすいのは退職のみ
- 経産省 2025 年の崖 = レガシー保守人材枯渇で年間最大 12 兆円損失、バイブコーディングはそれを中堅規模で量産
- 公開事例 5 (経産省 / みずほ 2021 / COCOA / COBOL / 自治体 RPA) は全部「ドキュメント不足 + 後継不在 + 委託先サイロ化」の構造
- 退職通知 30 日チェック 10 項目 = アクセス権 / 認証情報 / クラウド名義 / ドキュメント / コードレビュー / デプロイフロー / 連絡先 / 動画化 / cron 棚卸 / 1on1
- AI でブラックボックス継承可能化 5 ステップ = 流し込み → コメント → テスト → 図 → リファクタ候補
- AI ツール 5 比較 = Claude Code / Copilot Workspace / Cursor / Devin / Mintlify、月 5-15 万円で工数 50% 削減
- 90 日継承プラン + 緊急 5 項目 で今週から動き出せます、属人化 1 件顕在化したら数千万 - 数億円規模の損失リスクを抑制
「あの人しか触れないシステム」を「AI + 副担当」に変える投資が、AI 時代の中堅企業を守ります。
次回(連載第 9 回)は バックアップが動いてない、を発見する方法 を取り上げ、月次リストアテスト + 自動検証スクリプト + GitLab 5 段階バックアップ全不全事案から学ぶ実装パターンを整理します。
関連記事
- 第 1 回 バイブコーディング危機 概論 + 7 リスク類型
- 第 2 回 SQL Injection の現実 5 パターン
- 第 3 回 認可漏れの現実 5 シーン
- 第 4 回 サービス停止の財務影響:江崎グリコ 4 ヶ月の教訓
- 第 5 回 DELETE FROM データ消失 + AI が書かない 6 安全機構
- 第 6 回 ランサムウェアに気づかない 6 ヶ月
- 第 7 回 法令違反の罠:電子帳簿 + 特商法 + 改正個情法
「うちの属人化、本当に解消できる?」と思ったら
GXO の バイブコーディング監査 + 属人化解消設計サービス では、中堅企業向けに以下を提供します:
- 属人化リスクマップ作成 (本記事チェック 10 項目を専門家が代行、3-5 営業日)
- AI ドキュメント生成支援 (Claude Code / Cursor / Copilot 導入 + プロンプト設計)
- 90 日継承プラン 進行 (週次ミーティング + ドキュメント レビュー)
- 後任エンジニア オンボーディング 14 項目 進行
- 緊急時 外部 SE / 外部 CTO 暫定継承 (3-6 ヶ月、月 30-100 万円)
著者: GXO株式会社 初回公開: 2026 年 5 月 28 日 最終更新: 2026 年 5 月 28 日 連載: バイブコーディング危機 第 8 回(全 20 回)
