AI駆動開発とは？バイブコーディングとの違いと業務から始める進め方

AI駆動開発という言葉には、現時点で1つに定まった使い方があるわけではありません。AIにコードを書かせる開発を指す場合もあれば、企画から運用まで開発全体へAIを組み込む意味で使われる場合もあります。

この記事では、SalesDockでの使い方を明確にします。バイブコーディングと技術的にまったく別のものだとは考えていません。違いを置くなら、コードを書くところだけで終わらず、その前に業務をよく聞き、AIを使う前提で仕事の流れを書き換えるところです。

AI駆動開発とバイブコーディングの違い

バイブコーディングは、作りたいものを自然言語で伝え、AIとの対話を重ねながらコードを形にする方法として語られます。画面や小さなツールを早く試すときに役立ちます。

ただし、動く画面ができても、どのデータを正しいとするか、誰が承認するか、失敗したときにどこへ戻すかは決まりません。そこを決めずに現場へ渡すと、AIが速くコードを書いた分だけ、使い始めてから直す範囲が増えます。

どちらが優れているという話ではありません。試作をすぐ見たいならバイブコーディングから入り、会社の業務として使うなら、前後の業務と運用まで範囲を広げます。すでに作ったツールを社内で使う場合の境目は、バイブコーディングで作ったツールの本番公開ラインで詳しく整理しています。

コードを書く前に、業務ヒアリングを徹底する

ヒアリングでは「どんな機能がほしいですか」から始めません。担当者が今日も行った仕事を、最初から最後まで聞きます。メールが届いたあと何を見るのか、Excelのどの列へ写すのか、迷ったら誰へ聞くのか、過去に何を間違えたのかまで確認します。

手順書だけでは足りません。実際の業務では、顧客ごとの違い、担当者だけが覚えている判断、古い情報、クレームにつながった失敗が動きを変えています。AIへ覚えさせる材料には、社内規定やマニュアルだけでなく、過去の商談メール、議事録、日々の会議、うまくいかなかった事例も含まれます。

そのうえで、業務一覧、担当者、頻度、1件あたりの時間、使う情報、完了の条件を出します。書き出し方は業務棚卸しのやり方、項目ごとの決定者は要件定義を進める前に決めることで確認できます。

現在の手順を、AI前提の業務フローへ書き換える

いまの作業をそのままAIへ渡すと、人がやっていた無駄な受け渡しまで残ります。先に、処理を3つへ分けます。

単純な転記や決まった条件での振り分けは、AIを使わない通常の自動処理で十分です。文章の意味を読み、過去の記録と照らし、次に何をするか候補を出すところでAIを使います。そして、会社や顧客への影響が大きい操作は人が確定します。

営業会議のあとを例にすると

会議の文字起こしが届いたら、AIが決定事項、宿題、期限、顧客の懸念を整理し、次に送るメールと社内の更新候補を作ります。ここまではAIが続けて進められます。

顧客へ送る文面、提示する金額、約束する期日は人が確認します。承認された内容だけを顧客対応や案件管理へ反映し、AIが何を参照して何を変えたかを記録します。人の役割は全文を最初から作ることではなく、重要な判断と承認へ移ります。

AI駆動開発を進める7つの工程

AIを使う工程を実装だけに置かず、次の順番で進めます。

安全な開発手順について、NISTのSecure Software Development Frameworkは、組織の準備、ソフトウェアの保護、安全な成果物の作成、問題への対応を開発ライフサイクルへ組み込む考え方を示しています。AIがコードを書く場合も、レビュー、権限、記録、問題が起きたあとの対応は開発の外へ置けません。

AIが進めるほど、人は作業確認から運用管理へ移る

AIの利用範囲が広がると、人が毎回の作業を横から見る運用では続きません。人が確認する対象は、AIが何を出したかだけでなく、AIの処理が動いているか、何の情報を見たか、その情報は今も正しいかへ変わります。

古いマニュアルを正しい情報として答える状態は、1件ずつ直すだけでは再発します。AIが参照した資料と更新履歴を定期的に流し、現場が違いに気づけるようにします。間違いを見つけたら、同じ情報を使う処理をまとめて直せる形にしておくことが大切です。

AIによるコード変更を扱うGitHubの公式資料でも、エージェントが変更をプルリクエストとして提示し、人がレビューしてから取り込む流れが案内されています。AIへ作業を任せても、重要な変更を確認できる単位で出し、承認後に反映する考え方は同じです。

AIを止めて人へ戻す条件

「分からなければ人へ聞く」だけでは、AIがいつ止まるかを判定できません。少なくとも次の場合は、自動で確定せず人へ戻します。

• 回答や判断の参照元を示せないとき。
• 複数の資料で内容が食い違う、または更新日が古いとき。
• 通常業務で見たことのない入力や例外が来たとき。
• 金額、契約、顧客対応、外部公開など、決めた承認箇所へ到達したとき。
• 実行履歴を残せない、元の状態へ戻せない、止める担当者がいないとき。

本番へ出す前の権限、データ、復旧、引き継ぎはAIで作った社内ツールの本番導入前チェックリストで確認できます。

最初の1業務を選ぶ基準

最初から顧客対応や基幹業務を選ぶ必要はありません。頻度が高く、書式が安定し、同じ情報を写したり整理したりしている社内業務から始めます。例外が少なく、失敗しても人の作業へ戻せることも条件です。

一方で、顧客へ自動送信する、請求金額を確定する、重要なデータを上書きする業務は後に回します。まずはAIが下書きや候補を作り、人が承認する形で精度と運用を確かめます。

開発の速さだけでなく、業務がどう変わったかを測る

AI駆動開発では、コードを何日で作れたかだけを成果にしません。現場で使い始めたあと、次を同じ期間で比べます。

• 1件あたりの処理時間と、人が確認した時間を分けて記録します。
• AIの出力を直した回数と、最初からやり直した回数を残します。
• 例外として人へ戻した件数と、その理由を分類します。
• 顧客対応や金額など、承認が必要な操作をAIだけで進めていないか確認します。
• 担当者が不在でも、別の人が参照元と実行履歴を確認して止められるか試します。

削減時間だけでなく、ミスによる損失を減らせたか、営業活動に使える件数を増やせたかも確認します。1件の損失額や営業活動の価値を算出できない場合は、まずミスの件数、手直し時間、実行できた営業件数を実数で残します。金額への換算は、その記録が貯まってからで構いません。

一次情報・公式情報

• NIST「Secure Software Development Framework」
• NIST「DevSecOps Practices」
• GitHub Docs「About third-party coding agents」
• GitHub Docs「Responsible use of Copilot coding agent」

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