退職者が作った社内アプリを、引き継げなくなる前に。最も厄介な仕様漏れと、AIが書いたコードの保守

社員がAIで作ったアプリの引き継ぎでは、仕様が記録されていないことが大きな課題になります。

この記事では、引き継ぎの手順と、仕様・名義・鍵・セキュリティの確認点を説明します。

引き継ぎで時間がかかるのは、仕様の確認

退職者が作ったアプリの引き継ぎでは、次の3つを確認します。

1. サーバーやAPIの契約を、会社の名義に移すこと
2. セキュリティの穴を見つけて、直すこと
3. アプリが従っている決まりごと（仕様）を、書き起こすこと

特に時間がかかるのは、3の仕様の書き起こしです。契約やセキュリティの情報は管理画面などから調べられますが、仕様は本人の記憶やAIとの会話履歴にしか残っていないことがあります。

1円が合わない見積もりアプリ

営業部の社員が、AIに指示を出しながら見積もりアプリを作ったとします。この開発方法をVibe Coding（バイブコーディング）と呼びます。アプリは定着しましたが、1年後に作成者の退職が決まり、情報システム部門のCさんが引き継ぐことになりました。

退職までの2週間で、Cさんはサーバーの契約を会社名義に移し、ソースコードを社内のGitHubに置きました。

退職から1か月後、営業部から連絡が来ます。

「同じ商品なのに、見積もりの画面と請求書の画面で、合計が1円違うんですが」

Cさんはコードを開きます。金額を計算している箇所が、見積もりの画面と請求書の画面で別々に書かれていました。片方は端数を切り捨て、もう片方は四捨五入しています。 AIに画面ごとに作らせたため、同じ計算が2か所に、別々のルールで書かれていたのです。

どちらの丸め方が正しいのか、営業部にも退職した本人にも分かりません。本人がAIとやりとりした会話履歴も、アカウント削除と一緒に消えていました。

アプリとソースコードは残っていても、本来どう動くべきかを示す記録がありません。このように、必要な仕様が記録から抜けている状態を仕様漏れと呼びます。

この例をもとに、仕様漏れが起きる理由と、退職前後に確認する項目を説明します。

AIで作られたアプリの引き継ぎとは

通常の引き継ぎとの違い

Vibe Codingで作られたアプリの引き継ぎは、人が設計して書いたアプリの引き継ぎと、次の3点で異なります。

観点	何が起きるか	Cさんの会社では
仕様書が残っていない	開発者がAIと対話しながら仕様をその場で決めるため、決定事項が文書にならない	端数の扱いを、誰も文書で確かめられなかった
作った本人も、コードの全体を把握していない	AIが生成したコードを、開発者がすべて読んでから使っているとは限らない	計算が2か所にあることを、本人も知らなかった
誰も決めていない動作が含まれる	AIは、指示されていない部分を推測で補ってコードを書く	2つの画面で、丸め方が別々になっていた

仕様漏れの2つのタイプ

仕様漏れとは、アプリが従っているはずのルールのうち、どこにも記録されていないものを指します。 Vibe Codingで作られたアプリの仕様漏れは、大きく2つに分かれます。

• 決めたものの、記録されていないルール。「端数は切り捨て」「値引きには部長の承認が必要」といったものです。本人の記憶と、AIとの会話履歴の中にしか残っていません
• 誰も決めていない動作。Cさんの会社の、画面ごとに違う丸め方がこれにあたります。AIが推測で補ったもので、本人に尋ねても答えは返ってきません

2つ目は、コードを読み解いて初めて見つかります。

仕様漏れが、時間とともに埋めにくくなる理由

仕様漏れを埋めるための材料は、時間とともに失われていきます。

• AIとの会話履歴が消える。会話履歴は個人のアカウントに紐づいているため、退職に伴うアカウントの削除と一緒に失われます
• 本人に確認できなくなる。退職後は連絡が取りにくくなり、取れたとしても記憶が薄れていきます
• 利用者が現状に慣れる。利用者は現在の動作を「そういうもの」として受け入れていくため、バグなのかルールなのかを、次第に誰も判断できなくなります

一方、サーバーやドメインの名義、APIキーは、管理画面や請求書から確認できます。Cさんの会社が移管できたのは、このように後から調べられる情報でした。

退職の前後で確認するポイント

仕様漏れとは別に、アプリを動かしている契約と権限も、個人から会社へ移します。これを怠ると、契約が本人の個人アカウントとクレジットカードで結ばれていた場合に、カードの失効をきっかけにアプリが止まります。退職者の管理者アカウントが有効なままなら、退職後もログインできてしまいます。

観点	何をするか
契約の名義	サーバー、データベース、ドメイン、生成AIのAPI、GitHubの契約者を一覧化し、個人名義のものを会社のアカウントへ移管する
鍵（APIキー）	退職者が知っている鍵は、退職後も使える。すべて再発行し、古い鍵は無効化する
管理者のアカウント	退職者のアカウントを停止し、管理者は会社のアカウントで2名以上にする
起動と反映の手順	手元で起動するまでの手順と、必要な設定値（環境変数）を文書化する。サーバー上で直接書き換えていて、GitHubと本番が一致しない状態もここで見つかる

本番環境しかない場合は、検証環境を1つ用意し、GitHubに反映した変更が自動で本番にデプロイされる仕組みを整えておきます。

AIが書いたコードで、脆弱性が出やすい4つの箇所

AIが書いたコードの脆弱性は、画面を操作しているだけでは見えない箇所に集中します。「この人にはこのデータを見せない」という条件は、指示に含まれていなければコードにも反映されないためです。

この点は、攻撃する側の変化によって重みが増しています。 IPA（情報処理推進機構）の「情報セキュリティ10大脅威 2026」（組織編）では、「AIの利用をめぐるサイバーリスク」が初めて選出されて3位に入り、その内容には、AIの悪用による攻撃の容易化と手口の巧妙化が含まれています。 2025年11月には、AIエージェントが標的の偵察から侵入までの大半を自動で実行した攻撃が、AI企業のAnthropicから報告されました。脆弱性を探すコストがAIで下がれば、小さな社内ツールも攻撃の対象から外れません。

私たちがAIの書いたコードをレビューする際に、必ず確認している4つの箇所は次のとおりです。

箇所	よくある状態	自分で確かめる方法	対処
認証と認可	ログイン画面はあるのに、裏のAPIは誰でも呼べる。URLの番号を変えると他人のデータが見える（IDOR）	ログインしていないブラウザ（シークレットウィンドウ）でAPIのURLを直接開く	サーバー側で毎回「この利用者にこのデータを見せてよいか」を検証する
データベース	Supabaseなどで行単位のアクセス制御（RLS）が無効のまま。公開用の鍵だけで全テーブルを読み書きできる	管理画面で、RLSが無効のテーブルが無いかを見る	全テーブルでRLSを有効にし、公開用の鍵では何も読めないことをテストで確かめる
鍵	APIキーが画面側のコードに直書きされ、ブラウザの開発者ツールで誰でも読める	開発者ツールで key secret token を検索する。GitHubのシークレットスキャンを有効にする	鍵をサーバー側の環境変数へ移し、再発行する
部品	ライブラリやフレームワークが古いまま、既知の脆弱性を抱えている	npm audit などで、既知の脆弱性を持つ部品を一覧にする	部品を更新し、脆弱性の通知（GitHubのDependabotなど）を導入する

データベースの項目は、AIでアプリを作るサービスがRLSを無効のまま生成していた件として、脆弱性（CVE-2025-48757）が公表されています。部品の項目では、2025年3月にNext.jsで、リクエストに特定のヘッダーを1つ加えるだけで認証チェックを回避できる脆弱性（CVE-2025-29927）が公表されました。修正版はすぐに公開されましたが、作った人がいないアプリは誰も更新しません。

社内で対応するか、外部に依頼するか

線引きは、誰が使い、どんなデータを扱い、どこからアクセスされるかで判断します。

• 部署内の数人だけが使い、個人情報や金銭を扱わず、社外からアクセスされないアプリであれば、仕様の書き起こしと名義の移管を社内で行えば、使い続けて問題ありません
• 複数の部署で使う、顧客情報や金銭を扱う、社外からアクセスされるアプリであれば、上の4つの箇所は専門家の目でレビューしたほうが安心です

外部に依頼したときの費用は、何で決まるか

依頼の単位	内容	費用が上がる方向
診断	仕様の書き起こし、名義と鍵の棚卸し、コードレビューを行い、リスクの高い順に並べた一覧を受け取る	画面とAPIの数が多いほど、外部連携や定期処理があるほど
修正	一覧から選んだ項目を修正する	件数が多いほど、認証やデータベースの設計に関わる修正ほど
保守	部品の更新、脆弱性への対応、小規模な改修を月単位で続ける	月あたりの対応時間が長いほど

診断だけを依頼し、修正は社内で行うこともできます。また、本人が在籍しているうちに依頼すれば、ヒアリングで埋まる仕様漏れが増えるため、診断の工数はその分だけ下がります。

退職前の1時間で、本人に聞くこと

Cさんの会社が退職前の2週間でできたことは、もう1つありました。本人に1時間だけ時間をもらい、仕様漏れが出やすい領域について質問しておくことです。

仕様漏れは、画面に見えている機能よりも、その裏側の決まりごとに集中します。私たちが引き継ぎのヒアリングで使っている6つの領域と、質問の例は次のとおりです。

領域	本人に聞くこと	Cさんの会社なら
計算と丸め	金額や数量の計算で、端数・税率・割引の順番をどう決めたか	端数は切り捨てか四捨五入か。全画面で同じか
権限と承認	誰がどのデータを見られ、誰の承認で何が確定するか	値引きの上限と、承認する人
例外とエラー	入力が不正なとき、外部サービスが応答しないときにどうなるか	単価が未登録の商品を選んだとき
同時操作と重複	同じデータを複数人が同時に編集したとき、同じ登録が二重に届いたときの扱い	同じ見積もりを2人が開いて保存したとき
外部連携と定期処理	他のシステムとのデータ連携、毎晩・毎月に自動で動く処理	会計ソフトへの書き出しが、いつ・何を送っているか
手作業の運用	アプリの外で、本人が定期的に手で直していたこと	月末に、データベースを直接直していなかったか

6つ目は、とくに見落とされがちです。アプリの外で行っていた作業は、コードにもAIとの会話履歴にも残りません。

あわせて、AIとの会話履歴をエクスポートしてもらいます。会話履歴は、ヒアリングで本人が思い出せなかった決まりごとを、あとから確かめる材料になります。

聞いたあとに、仕様を書き起こす

ヒアリングのあとは、次の3つの材料を突き合わせて仕様を書き起こします。

1. ヒアリングと会話履歴。本人が決めたこと、決めた理由
2. コード。AIにコードを解析させ、画面・API・定期処理ごとに「入力・処理・出力・前提条件」を一覧にさせたもの。誰も決めていない動作は、多くの場合ここで見つかります
3. 利用者の期待。日々の操作の流れと、「この場合はこうなるはず」という期待

3つが食い違った箇所が、「バグか仕様か」を決めるべきポイントです。決めた内容は、現在の動作をそのまま検証する自動テスト（特性テスト）として残します。特性テストがあれば、今後どこかを修正したときに、別の箇所を壊していないかを自動で確認できます。

Cさんの会社なら、「端数は切り捨て、全画面で同じ計算を使う」と決めて計算を1か所にまとめ、その結果を特性テストで固定します。次に誰かがアプリを直しても、1円のずれは戻ってきません。

退職が決まったら進める、引き継ぎのチェックリスト

ここまでの内容を、進める順に並べました。退職が決まった時点で、この表の上から順に進めてください。

#	やること	誰が	いつまでに
1	6つの領域について、本人に1時間ヒアリングする	引き継ぐ担当者	退職前（後からはできない）
2	AIとの会話履歴をエクスポートしてもらう	作った本人	退職前（アカウント削除で消える）
3	契約の名義を会社のアカウントへ移す	引き継ぐ担当者と本人	退職前が望ましい
4	鍵を再発行し、本人の管理者アカウントを止める	引き継ぐ担当者	退職日
5	仕様を書き起こし、特性テストで固定する	引き継ぐ担当者（または外部）	退職後でもよい
6	脆弱性が出やすい4つの箇所を確認する	引き継ぐ担当者（または外部）	退職後でもよい

1と2は、退職後に本人へ確認できない場合があります。ほかの作業が間に合わなくても、この2つを先に進めてください。

よくある質問

退職者が作ったアプリは、作り直したほうがよいですか？

多くの場合、作り直す前に引き継ぎを試す価値があります。作り直すにしても、今のアプリがどう動いているかという仕様は必要です。仕様漏れを埋めないまま作り直すと、端数の扱いのような決まりごとが、新しいアプリでまた抜け落ちます。

退職者のAIとの会話履歴は、会社が受け取ってよいものですか？

業務で作ったアプリについての会話であれば、業務の記録として受け取るのが自然です。ただし、個人のアカウントで使っていた場合は、私的なやりとりが混ざっていることもあります。業務に関わる部分だけを本人に選んでエクスポートしてもらうなど、本人と相談して進めてください。

コードが読めない担当者でも、引き継ぎはできますか？

一部はできます。名義の移管、鍵の再発行、管理者アカウントの停止、本人へのヒアリングは、コードを読まずに進められます。仕様の書き起こしと脆弱性の確認は、コードを読める人が関わる必要があります。

AIにコードを読ませれば、仕様書は作れますか？

下書きは作れますが、それだけでは足りません。 AIが読み取れるのは「コードが今どう動くか」であって、「本来どう動くべきか」ではありません。 Cさんの会社のように、2つの画面で丸め方が違っていても、AIはどちらが正しいかを判断できません。コードから作った下書きを、ヒアリングと利用者の期待に突き合わせる工程が必要です。

外部に頼むと、どのくらいの期間がかかりますか？

アプリの規模と、本人が在籍しているかで変わります。画面とAPIが少なく、本人にヒアリングできる状態であれば、診断は短い期間で終わります。本人が退職していて会話履歴も残っていない場合は、仕様をコードから読み解く分、期間が延びます。

フィードのVibe保守では、エンジニアとセキュリティの専門メンバーが、退職前のヒアリングから仕様の書き起こし、修正・保守まで伴走します。担当者の退職が決まった段階でも、退職したあとでも、お気軽にご相談ください。