日本の「属人化システム」を事業承継できる資産に変える、デジタル事業承継レスキュー
「Claude CodeとCodexを使って、何を作れば儲かるのか」
この問いに対して、多くの人が最初に思いつくのは、AIアプリの受託開発、業務自動化、チャットボット、海外サービスの日本語版、あるいは小さなSaaSだろう。
しかし、そこはすでに人が集まりすぎている。
AIでコードを書くスピードが上がれば上がるほど、「コードを書けます」という価値は下がる。
顧客から見れば、A社もB社もC社も「AIを使って短期間で開発します」と言う。やがて価格競争になり、作業時間の短縮分まで値下げ圧力として返ってくる。
では、AI時代に本当に高く売れるものは何か。
答えは、コードそのものではない。
誰も説明できない業務を解明し、誰かが辞めても会社が止まらない状態を作ることだ。
Claude CodeとCodexを組み合わせて狙うべき最強の金脈は、次の事業である。
Excel、VBA、Access、古い業務システム、手作業、担当者の頭の中に埋まっている業務ルールを発掘し、仕様書・テスト・移行計画・運用手順に変換する「デジタル事業承継レスキュー」
これは単なるシステム開発ではない。
単なるDXコンサルでもない。
「社長が引退する」「ベテラン担当者が辞める」「M&Aで会社を譲る」「古いパソコンが壊れる」といったタイミングで、会社の中に埋まっている“見えないソフトウェア”を救出する仕事である。
売るものはプログラムではない。
「あの人が明日いなくなっても、会社が動く」という安心だ。
1．なぜ、これが日本で巨大な金脈になるのか
日本には中小企業が約336万者ある。
中小企業庁が公表している企業数集計では、2021年6月時点で中小企業・小規模事業者は336.5万者であり、日本の雇用のおよそ7割を担っている。
つまり、日本経済の大部分は、大企業の最新システムではなく、地域の中小企業の日々の業務によって動いている。
一方で、その現場には次のようなシステムが大量に残っている。
- 退職した社員が作ったExcelマクロ
- 一人の事務担当者しか操作できないAccess
- 20年前から改修を続けている販売管理システム
- CSVを手で加工して会計ソフトへ取り込む作業
- メール添付、共有フォルダ、紙のチェック表を組み合わせた受発注
- 担当者だけが知っている値引き、締め日、在庫引当、請求の例外処理
- 誰も触りたくないバッチファイルや古いスクリプト
- サーバーのどこにあるのかさえ分からないデータベース
重要なのは、これらが単なる「古いシステム」ではないことだ。
そこには、その会社が何十年もかけて作ってきた取引条件、顧客対応、在庫判断、品質管理、請求処理などの業務ノウハウが埋まっている。
コードが汚くても、画面が古くても、それが毎月の売上と入金を支えているなら、会社にとっては重要資産である。
ところが、多くの場合、その資産は仕様書にもマニュアルにもなっていない。
担当者の頭の中、Excelの数式、VBAの分岐、Accessのクエリ、共有フォルダのファイル名といった形で、バラバラに存在している。
ここに、事業承継問題が重なる。
2025年版中小企業白書は、中小企業経営者の半数以上が60歳を超えていることや、個人事業者の約4割が事業を継続しない意向を持つことを示している。
後継者不在率は低下傾向にあるものの、経営者の高齢化と事業承継は、依然として大きな経営課題だ。
会社の株式や不動産を引き継げても、受注から請求までの実務が一人の担当者にしか分からなければ、本当の意味で会社を引き継いだことにはならない。
M&Aでも同じだ。
買収後に初めて、
「このExcelがないと請求書を作れない」
「在庫数はシステムではなく担当者のメモが正しい」
「得意先ごとの価格計算がプログラムに直書きされている」
と判明すれば、統合作業は止まる。
つまり、日本で起きている事業承継は、株式や経営権だけの承継ではない。
業務ルール、データ、システム、操作手順を含む“デジタル事業承継”が必要になっている。
2．市場には「人がいない」。だからAIのレバレッジが効く
この仕事を従来型の人海戦術で行おうとすると、採算が合わない。
古いプログラムを読める人、業務担当者から話を聞ける人、データを分析できる人、新しいシステムを設計できる人、テストを書ける人を揃える必要がある。
しかし、日本企業のDX人材不足は深刻だ。
IPAの調査では、DXを推進する人材について「大幅に不足」「やや不足」と答えた日本企業は、合計85.1％に達している。
特に小規模企業では、生成AIへの関心は存在しても、会社として実際の利用を進めている割合は低い。
従業員100人以下の日本企業では、生成AIを積極的に業務利用する段階にある企業は約2割にとどまり、「関心はあるが予定はない」「利用予定がない」が大部分を占める。
一見すると、これはAIビジネスに不利な数字に見える。
実際は逆だ。
顧客にClaude CodeやCodexを操作してもらう必要はない。
事業者側がAIを使い、従来なら数百時間かかっていた調査、コード読解、仕様抽出、テスト作成、データ比較を短縮すればよい。
顧客に売るのはAIではない。
- 業務が止まるリスクの低下
- 退職者からの引き継ぎ完了
- M&A後の統合可能性
- システム障害からの復旧可能性
- 誰でも読める業務ルール
- 検証可能なテスト
- 次に何を廃止し、何を残すかという判断材料
である。
顧客が生成AIを使いこなせないほど、裏側で生成AIを使って成果物を作る事業者の価値は高くなる。
ここが重要だ。
「生成AI導入支援」では、顧客自身に新しい使い方を覚えてもらわなければならない。
しかし「デジタル事業承継レスキュー」では、顧客が覚える必要はない。
顧客は今まで通り業務の説明をし、既存ファイルを提示し、最終的な業務ルールを確認するだけでよい。
AIを前面に出さず、成果だけを売れる。
3．複数の金脈候補を比較すると、なぜこれが残るのか
Claude CodeとCodexを使った事業案を、次の5つの軸で比較してみる。
- 顧客の緊急性
- 支払い能力
- 商品化・反復可能性
- AIによる原価低下の大きさ
- 長期的な参入障壁
以下の点数は市場統計ではなく、事業性を検討するための編集上の評価である。
一般的なAIアプリ受託
- 緊急性：2点
- 単価：3点
- 商品化・反復可能性：3点
- AIレバレッジ：4点
- 参入障壁：2点
顧客が「作れたら便利」と考えている段階では、予算が付きにくい。
受託できたとしても相見積もりになりやすく、開発スピードが上がるほど「それならもっと安くできるはずだ」と価格を下げられやすい。
プロンプト研修・AI講座
- 緊急性：2点
- 単価：2点
- 商品化・反復可能性：3点
- AIレバレッジ：3点
- 参入障壁：1点
始めやすい反面、同様の講座を提供する競合が増えやすい。
モデルやツールの変化も速いため、教材が陳腐化しやすく、単発契約で終わりやすい。
小規模な業界特化SaaS
- 緊急性：3点
- 単価：3点
- 商品化・反復可能性：4点
- AIレバレッジ：4点
- 参入障壁：3点
成功すれば継続課金と高い利益率が期待できる。
一方で、最初から正しい業界課題を当てる必要があり、開発だけでなく営業、導入支援、データ移行、カスタマーサポートまで構築しなければならない。
海外AIサービスの日本展開
- 緊急性：3点
- 単価：3点
- 商品化・反復可能性：3点
- AIレバレッジ：4点
- 参入障壁：2点
海外で伸びたサービスを早期に日本へ持ち込めれば、一定の先行者利益を取れる可能性がある。
しかし、本家が日本語対応した瞬間に優位性が消えたり、海外企業側の契約変更によって事業基盤が揺らいだりする。
デジタル事業承継レスキュー
- 緊急性：5点
- 単価：4点
- 商品化・反復可能性：4点
- AIレバレッジ：5点
- 参入障壁：4点
この事業には明確な締め切りがある。
- 担当者が退職する日
- 社長が引退する日
- 事業譲渡の実行日
- 古いサーバーの保守終了日
- OSやOfficeの更新日
- 監査や制度変更への対応期限
- システム障害が再発する前
「いつか便利にしたい」ではなく、「この日までに何とかしなければならない」問題だ。
緊急性のある問題には、予算が付きやすい。
さらに、成果を出した後も、移行、保守、データ整備、内部統制、新システム導入へと契約を広げられる。
入口は診断だが、出口は長期的な業務基盤の再構築である。
4．「誰も気づいていない」の本当の意味
正確に言えば、レガシーシステムの刷新やモダナイゼーションという市場自体は、すでに存在する。
大企業向けには、大手SIerやコンサルティング会社が大規模な移行プロジェクトを実施している。
したがって、「競合が一社もいない」という話ではない。
本当の空白地帯は、次の条件が重なる領域だ。
大手が受注するには小さすぎる。しかし地域のIT業者が人手で調査するには複雑すぎる案件
例えば、従業員20人から200人程度の会社にある、数十個のExcel、複数のAccessファイル、共有フォルダ、古い販売管理システム、手書き伝票をつないだ業務である。
案件規模は数百万円程度。
従来のやり方では、調査だけで利益が消える。
顧客側も「全面刷新に数千万円、数億円」と聞いた瞬間に諦めてしまう。
しかし、Claude CodeとCodexを使い、調査・文書化・テスト作成を大幅に自動化できれば、これまで採算が合わなかった小規模案件を、定額商品として提供できる可能性が生まれる。
つまり、この金脈は新市場をゼロから発明するものではない。
大企業向けにしか成立しなかったモダナイゼーションを、中小企業向けの商品に圧縮する事業である。
5．なぜClaude CodeとCodexを“両方”使うのか
Claude CodeもCodexも、単にコードを補完するツールではない。
Claude Codeはコードベースを読み、ファイルを編集し、コマンドを実行するエージェント型の開発環境である。
専門タスクごとに独立したコンテキストと権限を持つサブエージェントを作成でき、フックを使ってシェルスクリプト、HTTP処理、モデルによる判定をワークフローへ組み込める。
Claude Agent SDKを使えば、ファイル操作やコマンド実行を行う独自エージェントも構築できる。
出典：Anthropic「Claude Code overview」
Codexも、機能開発、リファクタリング、移行、コードレビューまでを扱うエージェント型環境になっている。
複数エージェントやGit worktreeを使った並行作業、非対話型のcodex execによるCI・パイプライン実行、専用のコードレビュー、MCP接続、SDKやGitHub Actionsとの統合を公式に備えている。
ここで誤解してはいけない。
「Claude Codeは調査専用で、Codexは実装専用」という製品上の明確な境界があるわけではない。
両者の機能はかなり重なっている。
両方を使う理由は、性能比較で勝者を決めるためではない。
作る役と疑う役を分けるためだ。
一つのモデルに、仕様抽出、実装、テスト、レビュー、承認まで全部やらせると、そのモデルが最初に行った勘違いを、後工程でも引き継ぐ可能性がある。
そこで、次のように役割を分ける。
Claude Code：考古学者兼仕様設計者
最初は読み取り中心で既存資産を調査する。
コード、Excel、SQL、設定ファイル、ログ、マニュアルを読み、依存関係、入力、出力、例外処理、不明点を整理する。
サブエージェントを分けるなら、次のようにする。
- データ構造調査担当
- 業務ルール抽出担当
- 外部連携調査担当
- セキュリティ・権限調査担当
- 操作マニュアル作成担当
Codex：実装工場兼独立検証者
Claude Codeが作成した仮仕様を読み、実際のコード動作と一致しているか検証する。
その後、worktreeごとにテスト作成、データ変換、API化、置き換え用モジュール開発などを並行実行する。
実装後は、専用レビューやCIを使い、差分、テスト結果、危険な変更、未処理の例外を確認する。
人間：最終的な業務判断者
モデル同士の結論が一致していても、最終承認は人間が行う。
特に、次のような判断はAIに確定させない。
- この例外処理は今後も必要か
- 税務・会計上の処理が正しいか
- 顧客別の特別条件を廃止できるか
- 個人情報をどこまで移行するか
- 旧システムを停止してよいか
- 復旧手順が現場で実行可能か
理想的な構成は、「Claudeが作り、Codexが疑う」だけではない。
案件によって役割を入れ替え、同じ問題を別のモデルに独立して調査させる。
重要なのはモデル名ではなく、同じ作業者に作成と承認をさせないことである。
6．実際の商品は「システム開発」ではなく、8段階の救出工程になる
このサービスは、いきなり新システムを作ってはいけない。
古いシステムを見つけると、多くの開発者は「きれいに作り直したい」と考える。
しかし、最初に必要なのは再開発ではない。
何が動いているのかを証拠として残し、何を捨て、何を守るべきかを判断することだ。
IPAのレガシーシステム刷新に関する報告でも、ブラックボックス化した仕様の復元・文書化、属人性の排除、知識移転が重要課題として挙げられている。
また、現行機能をそのまま新システムに再現するのではなく、標準化、パッケージ、SaaSの活用、カスタマイズの最小化を検討すべきだとしている。
人海戦術には限界があるため、生成AIをレガシーコード解析やコード生成に活用する方向も示されている。
出典：IPA「レガシーシステムモダン化委員会 総括レポート」
実務では、次の8段階に商品化する。
第1段階：証拠を保全する
最初にバックアップ、ファイル一覧、更新日時、ハッシュ、サーバー構成、外部接続先を記録する。
この段階では本番環境を書き換えない。
壊れかけたExcelに対して、いきなりAIエージェントに修正を許可するのは危険だ。
原本と調査用コピーを分離し、Gitやバージョン管理へ格納できるものは格納する。
第2段階：デジタル資産の棚卸しをする
業務で利用しているものを、プログラムだけでなく一式で集める。
- Excel、VBA、Access
- スクリプト、バッチ
- データベース
- CSV、固定長ファイル
- 帳票テンプレート
- メール文面
- 共有フォルダ
- 手順書
- 紙のチェックリスト
- 外部サービスの設定
- 担当者だけが保有しているメモ
ここで「どのファイルが重要そうか」を聞くのではなく、「受注が入ってから入金されるまで、実際に何を開き、何を入力するか」を追跡する。
第3段階：実際の入出力を記録する
コードを読んだだけでは、仕様は確定しない。
典型的な入力データと、それに対する出力を採取する。
例えば、次のような代表ケースを記録する。
- 通常注文
- 値引き注文
- 在庫不足
- 月末締め
- 返品
- 得意先別単価
- 消費税の端数処理
- キャンセル
- 再請求
担当者の説明とコードの挙動が違うこともある。
その場合、「どちらが正しいか」をAIに決めさせず、差異として報告する。
第4段階：業務ルール地図を作る
Claude CodeやCodexに、コードを日本語で要約させるだけでは不十分だ。
必要なのは、判断条件を構造化することだ。
例えば、次のようなルールが存在するとする。
得意先区分がAで、注文日が月末3営業日以内であり、商品区分が定番品の場合は、標準単価から5％値引きする。ただし特別契約フラグがある場合は契約単価を優先する。
このようなルールを、次の項目に分ける。
- 入力項目
- 条件
- 計算式
- 優先順位
- 例外
- 出力先
- 根拠となるコード位置
- 現場確認の有無
- 廃止可能性
「コードの説明」ではなく、「経営資産として読める業務ルール」に変換する。
第5段階：ゴールデンマスターテストを作る
古いプログラムが正しいとは限らない。
しかし、現時点で会社がその出力を前提に動いているなら、移行時に比較できる基準が必要だ。
代表的な入力と現在の出力を固定し、新しい処理でも同じ結果になるか確認する。
これがゴールデンマスターテスト、あるいは特性テストである。
テストの目的は、「旧システムが正しい」と保証することではない。
旧システムから何が変わったかを検出可能にすることだ。
第6段階：廃止・置換・包囲・再構築に分類する
すべてを作り直してはいけない。
機能を次の4種類に分ける。
- 廃止する すでに使われていない帳票や、過去の取引慣行を削除する。
- 既製サービスに置き換える 会計、勤怠、請求、在庫など、標準SaaSで対応できるものは置き換える。
- 周囲を整備して延命する 本体は残し、バックアップ、入力チェック、API、監視、操作画面などを追加する。
- 必要部分だけ再構築する 競争力の源泉となる独自ルールだけを、小さなモジュールとして作り直す。
この分類を行うだけでも、顧客には大きな価値がある。
全面刷新しか選択肢がないと思っていた会社に、「20％だけ作り直せばよい」という道を示せるからだ。
第7段階：小さな単位で移行する
Codexのworktreeやサブエージェントを利用し、処理を独立した単位に分ける。
例えば、次のように分割する。
- 受注取込
- 単価計算
- 在庫更新
- 請求データ生成
一度に全部切り替えず、旧処理と新処理を一定期間並行稼働させ、出力差分を確認する。
第8段階：引き継げる状態で納品する
最後に納品するのは、新しいプログラムだけではない。
「デジタル継承パック」として、次のものをまとめる。
- システム・ファイル資産一覧
- 業務フロー図
- 業務ルール一覧
- データ辞書
- 外部連携一覧
- ゴールデンマスターテスト
- ソースコードと変更履歴
- 障害時の復旧手順
- 日次・月次・年次の運用手順
- 権限・アカウント所有者の一覧
- 廃止、置換、再構築のロードマップ
- 未解決事項と経営判断が必要な項目
パスワードそのものを文書へ書くのではなく、「どの認証情報を誰が管理し、どこで安全に保管するか」を記録する。
これによって、担当者が辞めても、次の人が業務を理解し、検証し、復旧できるようになる。
7．具体例：地方卸売会社の「謎Excel」を救出する
仮想的な案件を考えてみる。
従業員45人の卸売会社。
受注は取引先からCSVとメールで届く。
事務担当者がExcelマクロを実行すると、商品コードを変換し、得意先ごとの単価を計算し、在庫表を更新し、販売管理システムへ取り込むファイルを生成する。
そのExcelを作った社員はすでに退職している。
現在操作できるのは59歳の担当者一人だけ。
マクロには約1万行のVBAがあり、同じフォルダに「最新版」「最新版2」「本当の最新版」「旧」というファイルが並んでいる。
従来の提案なら、「新しい販売管理システムを導入しましょう」となる。
しかし、そのまま導入すると得意先別単価や例外条件が抜け落ちる。
そこで、デジタル事業承継レスキューでは、最初に次のことを行う。
- 実際に使われているファイルを特定する
- VBAから単価、商品コード変換、在庫更新のルールを抽出する
- 過去の受注CSVと出力を使ってテストケースを作る
- 担当者に例外処理だけを集中して確認する
- 機能を「廃止」「SaaSへ移行」「独自実装」に分類する
- 新旧処理の出力を比較する
調査の結果、20種類あると思われていた処理のうち、8種類は過去2年間使われていないことが判明する。
7種類は市販の販売管理SaaSで代替できる。
残る5種類だけが、その会社独自の価格計算と取引先対応だった。
そこで、全システムを再構築するのではなく、その5種類だけを小さな変換サービスとして実装する。
顧客が買うのは「VBAを別言語へ変換したプログラム」ではない。
- 退職予定者からの引き継ぎが完了したこと
- 独自の取引条件が文書になったこと
- 新旧の結果を自動比較できること
- どこまでSaaSへ移行できるか分かったこと
- Excelが壊れても復旧できること
である。
同じコード量でも、単なる変換作業として売るより、はるかに高い価値を説明できる。
8．商品設計と価格はどうするか
最初から「システム刷新一式」として売ると、顧客は怖がる。
価格も期間も分からず、失敗リスクが大きく見えるからだ。
入口は、小さな定額診断にする。
商品1：ブラックボックス危険度診断
期間：5～10営業日
価格案：30万～80万円
成果物は次の通り。
- 重要ファイル・システム一覧
- 一人しか分からない業務の特定
- 停止時の影響度
- データ消失・復旧リスク
- 事業承継時の障害
- 優先順位付き改善計画
- 次工程の概算費用
診断だけでも有料にする。
無料診断は、営業資料として使える範囲に限定する。
実ファイルの解析や業務ルール抽出まで無料で行うと、最も価値の高い工程を無償提供することになる。
商品2：デジタル継承パック
期間：4～8週間
価格案：120万～300万円
ここでは、業務ルール、データ辞書、テスト、復旧手順、移行方針まで作る。
新システム開発を含めず、「何があり、どう動き、どう引き継ぐか」を確定させる商品だ。
商品3：段階移行スプリント
期間：2～6か月以上
価格案：300万～1,500万円以上
必要な部分だけを、SaaS、API、小規模アプリ、データ変換処理などへ移行する。
案件を一括の巨大プロジェクトにせず、受注、在庫、請求といった単位で契約を分ける。
商品4：継続運用・変更管理
価格案：月額10万～50万円
提供内容は次の通り。
- 月次バックアップ確認
- テスト実行
- 権限棚卸し
- 仕様変更の記録
- 小規模改修
- 障害時の一次切り分け
- 年1回の復旧訓練
- 退職・異動時の引き継ぎ更新
売上を安定させるうえで、この月額契約が重要になる。
価格はClaude CodeやCodexの利用時間から逆算しない。
顧客が払うのは、トークン代でもエンジニアのキー入力時間でもない。
業務停止による損失、退職者への依存、M&A後の統合失敗といったリスクが、どれだけ下がるかを基準に価格を設計する。
9．一人会社でも成立する売上モデル
小規模事業者が初年度に次の契約を獲得したとする。
- 危険度診断：年間12件、平均60万円
- デジタル継承パック：年間4件、平均200万円
売上は次のようになる。
- 危険度診断：720万円
- デジタル継承パック：800万円
- 合計：1,520万円
ここに月額契約が加わる。
例えば、月額15万円の顧客を3社持てば、年間540万円が上積みされる。
合計売上は2,000万円を超える。
もちろん、これは利益ではない。
外注、保険、クラウド、出張、セキュリティ対策、営業、専門家確認などの費用がかかる。
案件が重なれば、一人だけで回すのも難しい。
それでも、一般的な低単価のWeb制作やAI記事作成と違い、少数案件で売上を作れる。
市場規模も、侵入率を極めて低く見積もって成立する。
日本の中小企業336.5万者のうち、年間0.05％だけが平均200万円の支援を購入すると仮定する。
対象企業数は約1,680社となる。
年間市場規模は約33.6億円になる。
年間0.1％、平均300万円なら、約100.8億円だ。
これは市場予測ではなく、企業数を基にした単純な感度分析にすぎない。
しかし、全中小企業を取る必要がなく、ごく一部の承継・退職・刷新案件だけでも十分な事業規模になり得ることは分かる。
企業数の基礎データは、中小企業庁の公表値による。
10．最初に狙う業界を絞る
最初から「すべての中小企業」を対象にしてはいけない。
営業メッセージも解析ノウハウも拡散するからだ。
初期ターゲットとして有望なのは、次の条件を持つ企業である。
- 従業員20～200人程度
- 卸売、製造、物流、専門商社など、受発注と在庫がある
- Excel、Access、CSVを多用している
- 月末処理が特定担当者に集中している
- 社長または担当者が1～3年以内に引退予定
- 近い将来、事業承継やM&Aを検討している
- 地域のIT業者に長年保守を依頼しているが、仕様書がない
- システム停止が売上や出荷に直結する
初期段階では、生命や安全に直接関わる制御システム、医療判断、高度な金融取引などは避けた方がよい。
最初は、入出力が確認しやすく、旧システムと新システムの結果を比較できるバックオフィス業務から始める。
特に狙いやすいのは、次の三つだ。
受注から請求まで
売上に直結するため、経営者が重要性を理解しやすい。
請求漏れや誤請求が起きれば、そのままキャッシュフローへ影響する。
在庫と発注
担当者の経験則が埋まりやすく、欠品や過剰在庫という分かりやすい損失がある。
「システム上の在庫数」と「担当者が本当に正しいと思っている在庫数」が違う会社も少なくない。
月次・年次処理
普段は動かさないため属人化しやすく、担当者が辞めると次の締め処理で初めて問題が発覚する。
月末、決算、棚卸し、年次更新などの低頻度業務は、マニュアル化されていないことが多い。
一業界に絞れば、共通する業務ルール、データ項目、テストケース、移行先SaaS、ヒアリング項目を再利用できる。
案件を重ねるたびに、次の案件の原価が下がる。
これが、単発受託から商品型事業へ移る鍵になる。
11．営業は経営者への直販より、「信頼の仲介者」を使う
このサービスの最大の障壁は技術ではない。
顧客が、社内のコード、売上データ、顧客情報、業務の弱点を見せることに抵抗を感じる点だ。
検索広告だけで見つけた無名の業者へ、会社の中枢データを渡す経営者は少ない。
そこで、最初から信頼を持っている人と組む。
有力な提携先は次の通りである。
- 税理士、会計事務所
- 地域金融機関、信用金庫
- M&A仲介、FA、事業承継支援者
- 社会保険労務士
- 地域のIT保守会社
- 商工会議所、商工会
- 業界団体
- システム販売会社
- 地方のコンサルタント
全国には公的な事業承継・引継ぎ支援センターが設置され、親族内承継から第三者承継まで相談支援を行っている。
このような既存の支援網に対して、「財務や株式だけでなく、業務システムの継承も必要」という専門領域を持ち込む余地がある。
営業資料では、「Claude CodeとCodexで解析します」と大きく書かない。
代わりに、次の質問を使う。
この会社で、明日一人休んだだけで止まる業務は何ですか。
そのExcelを作った人は、今も会社にいますか。
サーバーが故障した場合、何時間で受注業務を再開できますか。
3年以内に社長や主要担当者が引退する予定はありますか。
会社を譲渡するとき、買い手に業務ルールを説明できますか。
AIに興味がない経営者でも、この質問には反応する。
問題を「AI導入」ではなく、「事業継続」として提示するからだ。
12．本当の参入障壁は、プロンプトでもプログラムでもない
この事業を始めた直後は、誰でもClaude CodeとCodexを契約できる。
したがって、「二つのAIを使えます」だけでは差別化にならない。
参入障壁は、案件をこなすたびに蓄積する次の資産から作る。
1．日本企業向けの業務ルール辞書
締め日、端数、掛率、ロット、返品、仮単価、繰越、相殺、入数、リードタイムなど、日本の商取引で頻出する概念を構造化する。
業界ごとの言い回しや、帳票上の名称とシステム上の名称の違いも記録する。
2．レガシー資産ごとの解析テンプレート
Excel VBA、Access、FileMaker、古いPHP、VB.NET、Java、バッチファイルなどについて、調査順序、危険箇所、テスト方法を標準化する。
「最初にどこを見るか」が分かるだけでも、案件ごとの調査時間は大きく変わる。
3．ヒアリング設計
担当者は、日常的に行っている例外処理を「特別なルール」だと認識していない。
「どんな例外がありますか」と聞いても出てこない。
実際の伝票、月末処理、返品、クレーム、値引きなどを見ながら質問する方法を蓄積する。
4．ゴールデンマスターテストの部品
日付、税、端数、文字コード、空欄、重複、取消、月跨ぎなど、移行時に壊れやすいケースをテンプレート化する。
案件ごとにゼロからテストを考えるのではなく、共通部品を業務に合わせて調整できる状態を作る。
5．業界別の移行パターン
どの処理をSaaSに置き換え、どの独自部分を残すかという設計知識を蓄積する。
「この業界のこの処理は標準化しやすい」「この例外だけは残すべき」といった判断が、提案品質に直結する。
6．販売チャネル
税理士、地域金融機関、M&A支援者、IT保守会社との関係は、モデルを契約しただけでは手に入らない。
信頼できる紹介ルートは、技術以上に強い参入障壁になる。
7．信頼できる成果事例
「コードを何行解析したか」ではなく、次のような成果を実績として残す。
- 一人しか分からない重要業務を何件減らしたか
- 仕様不明の処理を何件文書化したか
- 復旧時間を何時間まで短縮したか
- 新旧比較テストを何件作ったか
- 廃止可能な処理を何件発見したか
- 事業承継後に誰が運用できるようになったか
顧客のコードや機密情報を、そのまま横展開してはいけない。
再利用するのは、匿名化・抽象化した業務パターン、チェックリスト、テスト設計、作業工程である。
この蓄積が増えるほど、単なるAI受託会社ではなく、「デジタル事業承継の専門会社」になっていく。
13．AIに任せてはいけない部分
Claude CodeとCodexを二重に使っても、安全性が自動的に保証されるわけではない。
Claude Codeには許可・確認・拒否のルールや、ファイルシステムとネットワークアクセスを制限するサンドボックス機能がある。
Codexも、高リスク操作を制限された環境で実行し、必要な操作には承認を求める設計を備えている。
ただし、これらは適切に設定し、運用して初めて意味を持つ。
出典：Anthropic「Claude Code permissions」
最低限、次の原則を守る。
本番環境は初期状態で読み取り専用
調査段階では、AIエージェントに本番データの更新権限を与えない。
解析のために本番へ接続する場合も、読み取り専用アカウントを基本とする。
原本と作業コピーを分離する
ファイルを直接修正せず、必ず複製とバージョン管理を行う。
どの時点のファイルを解析したのかが、後から確認できる状態にする。
秘密情報をコードやプロンプトへ直書きしない
パスワード、APIキー、秘密鍵は専用の管理環境へ置く。
ログやソースコードに認証情報が残っていないかも確認する。
外部通信を必要最小限にする
どのツールが、どの外部サービスへ接続できるかを明確にする。
顧客データを扱う作業では、不要なネットワーク接続や外部プラグインを無効にする。
AIの説明を証拠にしない
「このコードは売上計算をしています」というモデルの説明だけでは、仕様確定としない。
コード位置、実際の入力、出力結果、担当者確認を結び付ける。
破壊的操作には人間の承認を入れる
データ削除、スキーマ変更、本番反映、旧システム停止は、人間が差分と復旧方法を確認する。
「AIがテストを通した」という理由だけで、本番切り替えを実施してはいけない。
法務・税務・会計は専門家が確認する
AIはルールの所在を発見するために使える。
しかし、そのルールが法的・会計的に正しいかを最終判断する主体ではない。
この事業では、「AIで速く作りました」よりも、「どの証拠を基に、誰が承認し、どう復旧できるか」の方が重要になる。
14．ゼロから90日で立ち上げる実行ロードマップ
1～14日目：業界を一つ決める
「中小企業全般」では広すぎる。
例えば、次のように一つの業界や業務へ絞る。
- 食品卸の受発注
- 製造業の在庫・原価
- 運送会社の請求
- 専門商社の商品コード変換
実在顧客のデータを使わず、架空の古いExcel、VBA、CSV、マニュアルを自作し、Claude CodeとCodexで解析するデモ環境を作る。
この期間に、次のひな型を用意する。
- 資産棚卸し表
- ヒアリングシート
- リスク評価表
- 業務ルール記述形式
- ゴールデンマスターテスト形式
- デジタル継承パックの目次
- 秘密情報取扱ルール
- 作業前バックアップ手順
15～30日目：販売者ではなく、紹介者へ聞く
税理士、地域IT会社、M&A支援者など、10人程度へヒアリングする。
質問は「このサービスを買いますか」ではない。
次のような実態を聞く。
- 顧客企業で、退職すると困る担当者はいるか
- 事業承継時に、システムが問題になった例はあるか
- どの段階で問題が発覚するか
- 誰が予算を承認するか
- どの程度の診断価格なら紹介しやすいか
- 顧客が最も嫌がる情報管理上の不安は何か
ここで、最初の商品名、価格、成果物を修正する。
31～60日目：低価格でも必ず有料の診断を2件行う
最初の案件は、利益最大化よりも商品工程の検証を目的にする。
ただし無料にはしない。
無料案件では、顧客側の協力優先度が下がり、実際にお金を払う価値があるか検証できないからだ。
案件終了後、次を計測する。
- 何時間かかったか
- AIに任せられた工程
- 人間にしかできなかった工程
- 顧客が最も価値を感じた成果物
- 追加料金が必要だった作業
- 情報不足で止まった箇所
- 再利用できるテンプレート
61～90日目：継承パックを1件完成させ、提携商品にする
診断から本契約へ進む顧客を一社作る。
その実績を基に、紹介者向けの商品説明を作る。
例えば、税理士事務所には次のように提案する。
顧問先の社長やベテラン担当者が引退する前に、Excel、Access、業務システム、運用手順を棚卸しし、後継者が引き継げる状態にします。財務・株式の承継に加えて、実務の承継を支援するサービスです。
紹介者には、技術詳細ではなく、対象顧客の見分け方を渡す。
- 退職予定者がいる
- 月次処理が一人に集中している
- マニュアルがない
- 古いExcelやAccessがある
- 事業承継を予定している
- システム更新を何年も延期している
このチェック項目に複数当てはまれば、診断候補となる。
15．この金脈で最終的に作るべき会社
最初は、一人または少人数の専門サービスとして始める。
しかし、最終形は単なる受託開発会社ではない。
案件を通じて集めた業務パターン、解析テンプレート、テスト部品、移行方法を使い、次のような「デジタル事業承継プラットフォーム」へ進化できる。
自動棚卸しエージェント
指定フォルダやリポジトリを読み、重要ファイル、依存関係、外部接続、秘密情報の疑い、更新停止ファイルを一覧化する。
単なるファイル一覧ではなく、「このファイルが停止すると、どの業務へ影響するか」まで結び付ける。
業務ルール台帳
コードと現場ヒアリングを結び付け、各ルールの根拠、確認者、適用範囲、廃止可否を管理する。
コードが変更された場合に、どの業務ルールへ影響するかを追跡できるようにする。
継承スコア
属人化、復旧可能性、文書化率、テスト率、権限集中度を指標化する。
経営者や買い手が、「どこまで引き継げる状態になっているか」を一目で判断できる。
新旧比較基盤
旧システムと新システムへ同じデータを入力し、出力差分を自動検出する。
金額、日付、コード、在庫数、帳票内容の差異を分類し、人間が確認すべき項目だけを提示する。
事業承継ルーム
後継者や買い手が、業務フロー、システム、データ、リスク、未解決事項を安全に確認できる環境を提供する。
財務デューデリジェンスだけでは見えない「実際に会社を動かす仕組み」を共有する。
継続監視
新しいExcelやスクリプトが勝手に増え、再び属人化していないかを定期確認する。
一度きれいにして終わりではなく、ブラックボックスが再発するのを防ぐ。
この段階まで進めば、「毎回ゼロから調査する受託会社」から、「デジタル承継の標準を持つ会社」へ変わる。
Claude CodeとCodexは、その裏側で動く解析・実装エンジンになる。
顧客が買う商品名に、AIモデル名を入れる必要はない。
結論：コードを売るな。「会社が止まらない状態」を売れ
AI時代には、プログラムを書くコストが急速に下がる。
だから、「プログラムを書ける」というだけでは、長期的な金脈になりにくい。
一方で、コードを書くコストが下がっても、次の問題は消えない。
- 何を作るべきか分からない
- 現在の業務がどう動いているか分からない
- 誰が正しいルールを知っているか分からない
- 古いシステムの出力を再現できない
- 担当者が辞める前に引き継げない
- 新しいシステムへ移して壊れないか確認できない
- 会社を譲る際に、実務を説明できない
むしろ、コード生成が高速になるほど、「正しい仕様」「検証可能なテスト」「引き継げる文書」「承認の証跡」の希少性は高くなる。
Claude CodeとCodexを組み合わせる最大の価値は、二倍の速度でコードを書くことではない。
一方に既存業務を発掘させ、もう一方に疑わせる。
一方に仕様を作らせ、もう一方に実際の挙動で反証させる。
一方に移行処理を実装させ、もう一方に差分とリスクを検出させる。
この二重構造によって、従来は人海戦術でしかできなかった小規模企業のブラックボックス調査を、商品として成立させる。
日本には、すでに何百万もの中小企業がある。
その会社の中では、今この瞬間も、名前の分からないExcel、誰も触れないAccess、退職予定者しか操作できないシステムが、受注、出荷、請求、入金を支えている。
新しいAIアプリをもう一つ作るより、すでに日本経済を動かしている“見えないソフトウェア”を救出する方が、緊急性も、単価も、社会的価値も大きい。
見出しとしての「誰も気づいていない」は、厳密には誇張である。
大企業向けのモダナイゼーションは以前から存在する。
しかし、
事業承継が迫る中小企業に対し、属人化した業務とシステムをAIで発掘し、短期間・定額で“引き継げる資産”に変える
という組み合わせには、まだ大きな空白がある。
Claude CodeとCodexは商品ではない。
金鉱を掘るためのツルハシと選鉱機だ。
本当に売るべき商品は、たった一つである。
コードを売るな。
「あの人が辞めても、明日から会社が回る」を売れ。
