AI駆動開発の事例｜中小企業の4つの現場で、うまくいった点と詰まった点

「AI駆動開発は、実際にどんな場面で役に立っているのか」を知りたい方に向けて、SalesDockが支援した中小企業の4つの現場を紹介します。いずれも、エンジニアではない担当者が使う業務の道具をAIで作った場面で、AIにコードを書かせて業務アプリを作る、いわゆるバイブコーディングの事例でもあります。

数字は記録に残っているものだけを使い、「相談段階で、効果は未検証」の事例もそのまま書きます。AI駆動開発とは何かから知りたい場合はAI駆動開発とは？業務から始める進め方をご覧ください。

AI駆動開発の事例は、3つの現場で「先に決めたこと」が結果を分けました

先に4つの事例の要点を表にします。業種は大まかに、規模は「中小企業」とし、件数は丸めて書いています。

現場	困りごと	やったこと	結果
人材紹介の会社	AIで作った履歴書アプリの修正が、支援者の空き待ちだった	AIへの指示から本番反映までを、本人が回せる流れにした	1件の文言変更で、本人が本番反映まで完了できた。反映までの所要時間は未計測
人材紹介の会社	履歴書の様式が原本と合わず、4往復した	様式を作り直すのをやめ、元のWordファイルに差し込む方式にした	原因を特定し、方式を1本化する手順を渡した（その後の往復回数は未計測）
営業支援の会社	架電リストに会社を一意に決めるキーがなかった	国税庁の法人番号の全件データと突き合わせるプログラムを作った	約1.9万社のうち約96%に法人番号を付与。残る約4%は人が確認
外装工事の会社	図面からの数量拾いを、手作業でしていた	立面図から面積を自動で測る仕組みを作り、正解の内訳書と答え合わせした	足場面積は−5.1%、外壁（タイル）は−4.5%。作業時間の変化は未検証

事例1〜3では、AIの性能よりも、AIに渡す前の決め事（誰が使うか、何を正とするか、どのデータとつながるか）が結果を分けました。事例4は決め事の例ではなく、正解のあるデータで差を測る例として読んでください。

事例1｜AIで作ったアプリの修正を、本人だけで回せる流れにした（人材紹介）

人材紹介の会社の担当者が、AIで履歴書の作成アプリを作りました（バイブコーディングで作った業務アプリの例です）。作るところまでは本人でできましたが、公開は支援者側の環境から手作業で行っていました。文言を1か所直すにも支援者の空き待ちになり、本人が自分で直せない状態でした。

そこで、Claude・GitHub・ホスティングサービスをつなぎ、「AIに指示する → 変更の提案が出る → プレビューで確認する → 承認すると本番に反映される」という流れを作りました。

AIに任せるのは1と2、人が持つのは3と4です。本番に出す判断を本人の手に残したまま、支援者の空き待ちをなくす流れです。

この流れで、社名表記の文言変更1件を、本人が本番反映まで完了できました。反映までの所要時間は計っていないため、「何分で終わる」とは書けません。

AIで作ったアプリの修正を本人だけで回すために、先に決めたのは次の2点です。

誰が直すか。本人が自分で指示を出して直します。
どこで確認してから出すか。プレビューの確認と承認を、人の手に残します。

AIの出力をいきなり本番へ出さないことが、本人だけで修正を回すうえでの要です。

事例2｜様式が原本と合わず4往復した原因は、AIが画像を目で数えていたこと（人材紹介）

人材紹介の会社の担当者がAIで作った履歴書アプリが、指定の様式と合わず、直しの依頼が4往復しました。画像から様式を起こすと、AIが行数や枠を見た目で数えるため、原本のWordとずれが出ていました。

原因から対処までを、順に整理します。

渡したもの：様式を写した画像。
起きたこと：AIが画像の行数や枠を目で数えて再現し、原本のWordとずれた。
直し方：画像から作り直すのをやめ、元のWordファイルに情報を差し込む方式に1本化した。

1本化する手順は、担当者に渡しました。AIに渡す資料が画像だったか原本だったかで、結果が変わった例です。「何を正とするか」を決める、という点がそのまま出ています。なお、この変更のあとの往復回数は、記録がないため数字では書けません。

事例3｜約1.9万社の架電リストに、法人番号を付けた（営業支援）

営業支援の会社では、架電リストに会社を一意に決めるキーがなく、重複や名寄せ（同じ会社を1社にまとめる作業）ができませんでした。

公開情報から集めた約1.9万社のリストと、国税庁の法人番号の全件データを突き合わせるプログラムをAIで作り、結果を営業管理システムに入れました。

約96%を機械に任せ、残る約4%を人の確認に回しています。全件を機械で決め切る設計にはしていません。

結果は、約1.9万社のうち約96%に法人番号を付けられました。残る約4%は人の確認に回しています。その内訳は次のとおりです。

「同じ名前が複数ある」が、人の確認に回した分の約55%。
「見つからない」が、同じく約45%。主な原因は社名変更です。

ここでの決め事は、「会社を決めるキーは法人番号にする」ことと、「機械で決められない分は人に回す」ことの2つです。この2つは、AIにプログラムを書かせる前の設計で置いた前提です。

事例4｜図面から外壁の面積を自動で測る検証（外装工事）

外装工事の会社では、図面からの積算を少人数の担当者が手拾いしています。この作業をAIで楽にできるかを、相談段階で検証しました。

先方から借りた多数のスキャン図面と、正解の数量が入った内訳書を使い、立面図から面積を自動で測る仕組みを作って、答え合わせをしました。

足場の面積は、正解に対して−5.1%でした。
外壁（タイル）は、正解に対して−4.5%でした。
吹付を含めた総量では、正解に対して−25.7%でした。タイルと吹付を分けられていないためです。
窓などの開口部の差し引きは仮の値で、正確な数字ではありません。

この事例は、成果として語れる段階ではありません。作業時間がどう変わるかは未検証で、相談段階の検証にとどまっています。ただ、正解の内訳書で答え合わせをしたので、どこまで合っていて、どこが足りないのかは数字で言えます。AIの出力を信じる前に、正解のあるデータで差を測る進め方の例として載せました。

事例から分かること｜詰まりは「決めていなかったこと」から出ていた

事例1〜3を、AIにコードを書かせる前に決めておく3つの項目で見直すと、次のようになります。事例4は決め事の例ではなく、正解で差を測る別枠として、最後の行に置いています。

決めること	事例で起きたこと	先に決めておくこと
誰が使うか・直すか	履歴書アプリを本人が直せない	作った本人が、自分で直して反映できる流れを先に決める
何を正とするか	画像で見た様式と、元のWordが食い違った	原本（元のファイル）を正とし、AIには原本へ情報を差し込ませる
どのデータとつながるか（ER図で先に描く）	架電リストに会社を決めるキーがなかった	法人番号のような、会社を一意に決めるキーを先に決める
（事例4は別枠）正解で差を測る	図面の数量を自動で測ったが、どこまで合うかは答え合わせで初めて分かった	正解のあるデータを用意し、AIの出力との差を数字で出す

AIが速くコードを書くほど、決めていなかったことの直しも速く積み上がります。決めずに始めて直しが止まらなくなる状態はバイブコーディングのデメリットと失敗例で、決める3つの中身と進め方はAI駆動開発のベストプラクティスで詳しく書いています。3つ目の「どのデータとつながるか」は、データの箱と線を先に描くER図で決めておく項目です。紙に描く方法はER図の書き方が参考になります。

自社で事例をまねるなら、正解のある小さなデータで差を測る

事例の数字は、それぞれのデータで測った結果で、自社にそのまま当てはまるわけではありません。まねるときは、次の順で小さく試します。

正解が分かっている業務を1つ選びます。たとえば、手作業で付けた名寄せの結果が残っているリストです。
誰が使うか、何を正とするか、どのデータとつながるかを、A4の1枚に書きます。
AIに作らせ、出力を正解と照らして、差の割合を出します。
差が大きい部分を「人が確認する範囲」として切り分けます。
手作業の時間と、確認にかかった時間を記録し、1か月後に比べます。

差の割合だけで判断せず、確認にかかる時間まで足して比べてください。差が小さくても、確認に手間がかかれば、手作業より遅くなることがあります。本番へ出す前の確認項目はAIで作った社内ツールの本番導入前チェックリストにまとめています。

SalesDockが支援する領域

SalesDockは、成長に管理や業務の仕組みが追いつかない中小企業を、経営者や部門責任者と一緒に、業務の構造を整理してから実装まで支援しています。AI駆動開発は、その実装の手段の1つです。公開している事例は事例001と事例002をご覧ください。

自社の業務で、どこから試すかを30分で整理できます

いまの業務の流れを伺い、AIに任せる範囲と人が確認する範囲、作る前に決めることを30分の無料相談で整理します。

30分の無料相談を予約する

AI駆動開発の事例のよくある質問

AI駆動開発の事例には、どのようなものがありますか？

この記事では、中小企業の現場で取り組んだ4つを紹介しています。AIで作った履歴書アプリの修正と公開を本人だけで回せるようにした例、様式が原本と合わず4往復した例、約1.9万社の架電リストに法人番号を付けた例、図面から外壁などの面積を自動で測る検証です。事例1〜3は、AIにコードを書かせて業務アプリを作る、いわゆるバイブコーディングの事例でもあります。どれも非エンジニアの担当者が使う業務アプリが対象です。

AI駆動開発とバイブコーディングの事例は同じものですか？

重なる部分が大きく、AIにコードを書かせて業務の道具を作る点は同じです。SalesDockでは、AI駆動開発を、業務の聞き取りから運用までにAIを組み込む全体の進め方の呼び名として、バイブコーディングを、日本語で頼みながら動くものを作っていく作り方の呼び名として使い分けています。公的な定義はなく、事例の見方はどちらでも変わりません。

事例の数字は、そのまま自社に当てはまりますか？

当てはまりません。法人番号の付与率や面積の差は、それぞれのデータと図面で測った結果です。自社で試すときは、まず小さな範囲で正解が分かっているデータを用意し、AIの出力と照らして差を測ります。差の大きい部分は人の確認に回す前提で設計します。

AI駆動開発の事例から、最初に真似するとよいことは何ですか？

コードを書かせる前に、誰が使うか、何を正とするか、どのデータとつながるかを1枚に書くことです。事例1〜3の詰まりと成果は、ここを先に決めたかどうかで分かれました。事例4は、正解のあるデータで差を測る別の例です。