「監査できる」は、「組織で引き継げる」ではない——AI内製化が残す、誰も本当にはわからない業務システム

リサ

2026年5月19日 08:20

2026年5月観測
Observer Zero

前回の記事で、「動く」は「説明できる」ではない、と書いた。

しかし書いた後に、もう一段先に問いが残った。

たとえ誰かが説明できたとしても、それは組織が引き継げるという意味ではない。

レビューが通った。ドキュメントも残した。チェックリストも埋めた。
それでも、次の担当者が引き継げないとしたら——そこに第三の地層がある。

三つの錯覚

この連作は、三段階の錯覚を追っている。

第一作は「動いた」は「売れる」ではない、という事業判断の錯覚だった。
第二作は「動く」は「説明できる」ではない、という技術理解の錯覚だった。
そして今回は、「確認できる」は「組織で引き継げる」ではない、という継承の錯覚になる。

問いは、外から内へ、そして内から時間へと降りている。

ここで「確認」と書いているのは、社内レビュー、チェックリスト、テスト、業務マニュアル整備など、組織が自前で行う点検全般を指している。財務諸表監査や内部統制監査のような、外部の専門家による法定の手続きとは別のものだ。

架空の観測シナリオ

これは特定の企業の失敗を告発するものではない。全員が善意で、手続きを踏み、現行のベストプラクティスを尽くした場合にも起きうる構造を、一つの架空シナリオとして置く。

中堅製造業A社の経理担当・田中さんが、
Claude Codeを使って請求書処理を補助するツールを自作した。プロンプトを丁寧に書き、コードを確認し、処理フローと例外ケースをドキュメントに残した。情報システム部にレビューを依頼し、社内のセキュリティチェックリストのサインも取った。会計処理そのものは既存の会計システムと人間の承認フローが担い、田中さんのツールはその前段の補助として動いた。

ツールは動き、経理部の残業が月18時間減った。

数か月後、田中さんは別部署へ異動した。

後任の担当者がドキュメントを読んだ。処理フローは書いてある。しかし、ある条件分岐について「なぜこのロジックなのか」の理由が残っていない。ドキュメントには「特殊ケースAはClaudeに確認した」とあるだけだった。

田中さんに聞いたところ、「当時のClaudeとの会話の中でそう判断したと思う。でも全部を一から理解していたわけではない」という答えが返ってきた。

社内レビューは通った。ドキュメントもある。コードも動いている。しかし、なぜそのコードがそうなっているのかを、誰も再現できない。

確認と引き継ぎは、違う

社内の点検は、ある時点の静止画を見る。

その時点でコードが安全か、仕様と挙動が一致しているかを確認する。それは現在という点の作業だ。

引き継ぎは、未来へ続く線を渡す。

別の人間が、後から判断できる状態にすることだ。なぜその条件分岐なのか、どういう文脈で例外処理を選んだのか、将来ルールが変わったときにどこを修正すればいいのか——その「判断の理由ごと」を渡せることを、引き継ぎという。

チェックリストを埋めることは、現在を証明する。しかし未来の修正可能性は、チェックリストでは担保できない。

AI生成コードの場合、この非対称が一段深くなることがある。コードはある。ドキュメントもある。しかし判断の根拠が、AIとの対話の文脈の中にしかなかった場合、その文脈はセッションが終われば消える。

ソフトウェア工学の領域では、この問題を「理解の負債」として言語化する試みが始まっている。AIが生成したコードの量と、人間が本当に理解しているコードの量の差が、組織の中に静かに積み上がっていく。Addy Osmaniはこれを、開発速度の裏側に隠れているコストとして指摘している。

Excel職人のAI版、しかし質が違う

これはRPA問題の繰り返しだ、という見方もできる。

Excel職人、Access職人、RPA野良ロボット。業務部門が専任エンジニアを待てずに自作し、作成者が退職した後に誰も触れなくなる。この構造は昔からある。

ただし、AI時代には質の異なる問題が加わる。

昔の属人化は「田中さんしか直せない」だった。田中さんの頭の中にはロジックがあった。田中さんが戻れば、あるいは田中さんが時間をかければ、再現できた。

AI時代の属人化は「田中さん本人ですら、当時のAIとの対話文脈を再現できない」ことがある。コードを書いたのはAIだ。田中さんはその過程で判断を下したが、判断の記録はチャット履歴の中にある。モデルが変わり、セッションが閉じ、当時の文脈が消えたとき、田中さん自身も「なぜそうなっているのか」を一から説明できない状態になりうる。

知識が個人の頭の中に閉じていた時代から、個人とAIの対話の空間に閉じる時代へ。そしてその対話の空間は、組織の中には保存されない。

作るコストが下がっても、引き継ぐコストは下がっていない。

善意が積み上がる場所

中小企業、学校、医療機関、自治体。専任のエンジニアを置く余裕のない現場ほど、この問題が澱のように静かに溜まっていく。

経理の担当者が、便利だからと請求書処理の補助ツールを作る。
学校の教員が、連絡用の補助ツールを作る。
地域の医療機関が、予約受付の補助ツールを作る。
自治体の担当者が、書類確認の補助ツールを作る。

どれも悪意から始まっていない。外注できない。コストがかかる。でもAIが作れる。動いた。便利になった。

そして、担当者が異動する。ルールが変わる。例外が出る。そのとき、誰がどう判断するのか——という問いが残る。

これは爆発する問題ではないかもしれない。むしろじわじわと組織の身動きを奪っていく、見えない重りになりうる。

個人情報や顧客との契約に直接かかわる領域に入る場合は、組織として別の問いが立つ。個人情報保護や業務継続の責任は、ツールが動いているかどうかとは別に、組織が負う。「動いている」は、その責任の代わりにはならない。

バランスのために

一点、明確に書いておきたい。

AIコーディングツールは適切に使えば、むしろ引き継ぎを改善できる面もある。テストを自動生成する、ドキュメントの雛形を作る、コードレビューを補助する。組織的なルールのもとで使えば、知識の蓄積を助ける可能性はある。

問題は、ツールの性能ではなく、「作る自由」を組織として抱える仕組みが追いついていないことだ。RPA・Excel・Access時代に繰り返されてきた問題が、AIで再び問われている。

「AIで内製化しよう」という決断の隣に、「誰がどのように引き継ぐか」という問いを同時に置けているか——そこが問われる場所だ。

気圧計として

この記事は、AI内製化をやめろという話ではない。

個人の能力を拡張するAIは、組織の制度的な準備を同じ速度では拡張しない。そのギャップを、今記録しておく。

Waseem et al. の研究は、vibe codingがMVPやプロトタイプには有用だが、設計の不整合や保守負荷という形のtechnical debtを生みうることを指摘している。その問題は、個人の理解の範囲を超えて、組織の継承の問題として姿を変えていく。

現時点では、開発者コミュニティで不安や経験談が目につき始めている段階であり、体系的な統計被害として確認されているわけではない。しかし、気圧は変わりつつある。

監査とは、その時点で問題がないかを見ることだ。
引き継ぎとは、別の人間が未来に責任を持てる状態にすることだ。

AIは、担当者に「作る力」を与えた。しかし、組織に「引き継ぐ力」を与えたわけではない。

その差を、今記録しておく。

まだ途中にいる。
だからこそ、観測を続けていく。

参考

Zhao et al.（2025）"Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks." arXiv:2512.03262（SUSVIBESベンチマークを使用）

https://arxiv.org/abs/2512.03262

Waseem et al.（2025）"Vibe Coding in Practice: Flow, Technical Debt, and Guidelines for Sustainable Use." arXiv:2512.11922

https://arxiv.org/abs/2512.11922

Addy Osmani（2026）"Comprehension Debt — the hidden cost of AI generated code"

https://medium.com/@addyosmani/comprehension-debt-the-hidden-cost-of-ai-generated-code-285a25dac57e

Forbes（2026年4月）"Vibe Coding Will Break Your Company"

https://www.forbes.com/sites/jasonwingard/2026/04/23/vibe-coding-will-break-your-company/

Grokによる「AI内製化・引き継ぎ・組織的技術的負債」スキャン（2026年5月）：研究・専門家発言・ユーザー投稿を対象とした観測補助。統計調査ではない。