社内やAIで作った業務ツールが直せない｜引き取り・保守の判断基準

「担当の人が異動したら、誰も直せなくなった」

社内やAIで作った業務ツールについて、相談で聞く悩みで最も多いのがこれだ。AIコーディングやノーコードのおかげで、現場の担当者が自分で業務ツールを作れる時代になった。これは良い変化だと思っている。ただ、作れることと、直し続けられることは別の能力で、問題は作った後に出る。

本記事では、社内で作ったツールを外部に引き取ってもらうかどうかの判断基準と、引き取り前に確認すべき点を整理する。

先に結論

• 小さな業務ツールを、社内やAIで作るのは有効な選択。やめる必要はない
• 直せる人が1人しかいないなら、その1人が不在になった日を想定して備える
• 外部に引き取ってもらう前に、資料・アカウント・環境の3点を揃えると、費用も期間も抑えられる
• 業務の中核で、頻繁に機能を足す段階なら、保守の外注より社内の体制づくりを優先する

作った後に起きやすいこと

状況	原因	影響
作った担当者が異動・退職した	構成や手順が本人の頭の中にしかない	不具合が出ても誰も直せない
AIサービスやAPIの仕様が変わった	外部サービスの更新に追従していない	ある日突然、動かなくなる
ライブラリの更新が止まっている	依存関係の更新を確認する人がいない	セキュリティ上の懸念が残る
アカウントが個人名義になっている	作成者のメールアドレスで契約・認証している	退職とともに利用できなくなる
機能を足すたびに動作が不安定になる	全体の構造を把握せずにAIで修正を重ねた	修正のたびに別の箇所が壊れる

AIに「ここを直して」と頼み続けて作ったツールは、動いてはいても、全体の設計を説明できる人がいない状態になりやすい。動いている間は問題が見えず、止まったときに一気に表面化する。

引き取り前に確認する5点

外部に保守を依頼する場合、次の5点があるかで、受入可否と初期の調査費用が大きく変わる。

1. ソースコード・設定の所在：どこに保存されているか。バージョン管理されているか。担当者のPCだけにないか
2. 動いている環境：どのサーバー・サービスで動いているか。誰の契約か
3. 外部サービスとの接続：利用しているAPI・AIサービス・クラウドと、そのアカウント名義、利用料の支払い元
4. 使い方と業務上の位置づけ：誰が、いつ、何のために使っているか。止まったときの影響範囲
5. 既知の不具合と、直したい点：現在困っていることの一覧

すべて揃っている必要はない。揃っていない項目は、引き取り前の現状調査で洗い出す。ただし、3のアカウント名義が個人になっている場合は、保守の前に移管が必要で、ここは社内で先に手当てしてほしい。

外部に任せる範囲と、社内に残す範囲

項目	外部に任せやすい	社内に残した方がよい
稼働確認・エラー確認	○
不具合の一次調査と軽微な修正	○
依存ライブラリ・外部APIの更新対応	○
業務ルールの判断・優先順位づけ		○
新機能の要望の取りまとめ		○
大きな機能追加・作り直し	別途相談

保守は「今あるものを止めない」ための仕組みで、機能を増やす開発とは別に考える。月3〜5時間程度の保守作業で見られるのは、現状維持と軽微な修正までだ。新機能や大規模な改修は、保守の範囲外として別途見積もりになる。

引き取りより、先に社内で決めておくこと

保守を外注する前に、社内で次の3つを決めておくだけで、事故の確率は下がる。

• 主担当と副担当：直せる人を2人にする。難しければ、副担当が手順書を読んで復旧できる状態にする
• アカウント名義の整理：個人のメールではなく、会社の共通アドレスで契約・認証する
• 止まったときの連絡先と手順：誰に連絡し、代替手段（手作業・Excel）で何日もつか

引き取らない方がよいケース

正直に言うと、次のようなケースでは、外部への保守依頼をおすすめしない。

• ツールの数が多く、全体像を誰も把握していない：保守の前に、棚卸しと整理が必要。先に業務整理から始める方が早い
• 業務の中核で、毎週のように機能を足している：外部に依頼するたびに時間がかかる。社内に開発できる人を置くか、開発を外部に委託する方が合う
• 既存の基幹システムの本体を改修したい：ベンダーの領域なので、そのベンダーに相談するのが筋

また、ツールが小さく、直せる担当者が2人以上いて、資料もあるなら、外部に頼む必要はない。無理に保守契約を結ぶことはおすすめしない。

相談するときの進め方

1. 使っているツールの名前と、何をするものかを書き出す（3〜5行で十分）
2. 上の「5点」のうち、分かる範囲を確認する
3. 現在困っている点、または心配している点をまとめる
4. 相談する。初回30分の無料オンライン相談で、受入可否と最初の一歩を一緒に決める

保守の内容と範囲は、運用保守のページにまとめている。他社開発・社内開発のシステムは、資料やソースコードを確認したうえで受入可否を判断する。

まとめ

• 社内やAIでツールを作るのは、業務改善の有効な手段。ただし、直し続ける仕組みは別に必要
• 引き取り前に、資料・環境・アカウント名義の3点を整えると、保守の費用と期間を抑えられる
• 保守は現状維持と軽微な修正まで。機能追加は別の話
• ツールが小さく、社内に直せる人が複数いるなら、外部に頼む必要はない

基幹システムのような大きな仕組みについては、基幹システムの選び方で、内製が向かない理由と例外を整理している。AI活用全体の進め方は中小企業のAI導入ガイドを参照してほしい。