AI駆動開発時代のベンダーマネジメント ― 受発注の構造を組み替える

「ベンダーが見積もり3,000万円・10か月と言ってきた案件を、社内のAI駆動開発で2か月・300万円で作れた」「逆に、AI活用を謳うベンダーに発注したら、ChatGPTで生成しただけのコードを納品されて炎上した」。AI駆動開発の浸透で、受発注の構造そのものが変わりつつあります。発注側・受注側の双方にとって、これまでの常識が通用しない局面が増えています。

ベンダーマネジメントは、AIDD時代に評価軸・契約形態・期待値・関係性のすべてを再設計 する必要があります。本記事では、AIDD時代のベンダー選定・契約・運用を、発注側の視点から整理します。

要点：AIDD時代のベンダー管理は「選定基準の再設計・契約形態の柔軟化・成果ベースの評価・知財ルールの明確化」の4点で組み替えます。従来の人月見積もりは機能しなくなります。

1. なぜベンダーマネジメントが変わるのか

AIDD以前のベンダー管理は、「人月単価×期間」で見積もる前提でした。要件定義に1人月、設計に2人月、実装に5人月、テストに2人月。1人月100万円なら1,000万円。この計算式が長年通用してきました。

AIDDはこの前提を崩します。AIを使えば実装工数が3〜10倍速くなります。同じ機能を、人月で計算すると500万円分の工数が、AI活用で50万円分になります。発注側は「もっと安くできるはず」と感じ、受注側は「人月では適正利益が取れない」と感じます。両者の認識ギャップが、AIDD時代のベンダー管理を難しくする最大要因です。

加えて、ベンダーのスキル差が拡大 しています。AIを使いこなすベンダーは、品質と速度で従来の2〜3倍の生産性を出します。使いこなさないベンダーは、人月単価が高いだけで成果が出ません。発注側は、ベンダーのAI習熟度を見極める力が必要になります。

AIDD前後のベンダー構造変化

2. AIDD時代のベンダー選定基準

ベンダー選定の基準を、AIDD時代に合わせて再設計します。重要なのは「何を、どのように作るか」を見極める力です。

第一に、AI活用の習熟度です。Cursor・Claude Code・GitHub Copilot等の使用経験、社内規約の整備状況、ベテランの活用事例を確認します。「AIを使っています」だけでは不十分です。具体的な活用方法・成果指標を示せるかが分水嶺になります。

第二に、成果物の品質基準です。AI生成コードのレビュー体制、テストカバレッジ、セキュリティ・OSS監査の仕組みを確認します。「AIで生成しただけ」のコードを納品されると、後で大きな修正コストになります。

第三に、コミュニケーション能力です。AIDDは要件の頻繁な変更に強い反面、発注側との対話量が増えます。週次・隔週でのデモ・レビュー、プロト即生成での共同検討ができるかを確認します。

第四に、知財・契約への理解です。AI生成コードの所有権・OSSライセンス・機密情報取扱について、ベンダー側の規約・運用が整っているかを確認します。

ベンダー選定の評価項目

💡 ポイント：選定時に 小規模PoC（2-4週間・100-300万円） をやってもらうと、AI活用力・コミュニケーション・品質が一気に見えてきます。本契約前のリトマス試験になります。

3. 契約形態の選び方

AIDD時代の契約形態は、3つの選択肢が現実的です。

請負契約：成果物を約束する契約です。AIDDでは要件変更が頻繁なので、固定スコープの請負はリスクが高くなります。短期・小規模なら選択肢に入ります。

準委任契約：労働を約束する契約です。柔軟性は高いのですが、発注側のコントロール力が問われます。AIDDの不確実性とは相性がよい形態です。

成果ベース契約：機能単位・マイルストーン単位で支払う形です。「ログイン機能完成で50万円・決済機能完成で100万円」など。AIDDの速度感と相性がよく、近年増えています。

契約形態の比較

実務的には、初期PoCは準委任、本格化フェーズは成果ベース、運用は準委任 のハイブリッドが多くなっています。フェーズに応じて契約形態を切り替えるのが、AIDDと整合的です。

4. 知財・著作権の契約条項

AIDDでは、知財・著作権の契約条項が複雑化します。標準条項を整備しておきましょう。

AI生成コードの所有権：原則として発注側の所有とします。ベンダー側で再利用する場合の条件を明記します。

OSS取扱：AIが提案したコードがOSSライセンスを含む場合の対応を明記します。検知ツールの使用・ライセンス遵守の責任分担を決めます。

機密情報の取扱：ベンダーが発注側の機密情報をAIに渡す場合のルールを明記します。エンタープライズ契約のAIに限定する、ローカルAIで処理するなどの方法があります。

第三者著作権：AI出力が第三者の著作物を模倣した場合の責任です。発注側か受注側か、グレーゾーンになりがちです。事前に定義しておきましょう。

知財条項のチェックポイント

⚠️ 見落としがちな論点：「AIに送ったデータがAIサービス側で訓練に使われない」ことを契約で担保しておきます。エンタープライズ契約なら通常は保護されますが、明文化しておくと安心です。

5. 価格交渉と見積もり評価

AIDD時代の見積もり評価は、従来の「人月×期間」では機能しません。新しい評価軸が必要です。

機能単価の比較：「ログイン機能=50万円」「決済機能=100万円」など、機能単位で複数ベンダーを比較します。市場価格が形成されつつあります。

過去実績の参照：類似機能をいくらで作ったか、過去事例を参照します。AIDD前と後で価格が乖離している場合は要注意です。

TCO（5年）の試算：初期費用だけでなく、5年間の運用・改修費用を含めて評価します。安く作っても改修費が高ければ意味がありません。

価格妥当性の3層チェック：①機能単価が市場相場か、②工数推定が現実的か、③ベンダーの利益率が適正か（過剰利益・赤字双方リスク）、という3つの観点で見ます。

価格評価の3層フレーム

📊 経営判断のコツ：「安すぎるベンダー」も「高すぎるベンダー」も警戒しましょう。安すぎは品質リスク・赤字撤退リスク、高すぎは中抜きリスクが高くなります。複数ベンダー相見積もりで適正値を見極めるのがおすすめです。

6. プロジェクト中の運用

契約後の運用も、AIDD時代に合わせて変えていきます。

週次デモ・隔週レビュー：従来の月次レビューでは遅すぎます。週次でデモを見て方向修正します。

プロト即生成セッション：要件討議の場で、その場でプロトを生成します。「こういうイメージですか？」をリアルタイムで確認します。

KPIの可視化：完成機能数・テストカバレッジ・コードレビュー数・デプロイ頻度などを週次で共有します。透明性が信頼を生みます。

変更管理の柔軟化：要件変更を「変更請求」ではなく「自然な進化」として扱います。固定スコープにこだわると、AIDDのメリットが消えてしまいます。

運用フレームの新旧比較

7. ベンダーロックイン回避

AIDD時代でも、ベンダーロックインのリスクは残ります。むしろ、ベンダー独自のAI活用ノウハウに依存すると、ロックインが深刻化する場合があります。

ドキュメント納品の徹底：コードだけでなく、設計・運用・AI活用ノウハウ（CLAUDE.md・プロンプト集等）も納品してもらいます。

コードの所有・継続性：GitHub等で発注側のリポジトリを使います。ベンダーが去ってもコードベースが残る状態にします。

標準ツールの採用：ベンダー独自ツールではなく、業界標準ツール（Cursor・Claude Code等）を採用してもらいます。乗り換えコストが下がります。

複数ベンダー戦略：重要システムは複数ベンダーで分担します。1社に依存しない形にしておきます。

ロックイン回避の具体策

8. 失敗パターンと予防策

AIDD時代のベンダーマネジメントには、新旧織り交ぜた失敗パターンがあります。

失敗1：「AIで作るから安くて速い」期待過剰：AIは万能ではありません。複雑な業務ロジック・既存システム統合は依然として時間がかかります。期待値の調整が必要です。

失敗2：AI生成コードの品質チェック不足：AIは「動くコード」を出しますが、保守性・セキュリティ・性能までは保証しません。レビュー体制が前提になります。

失敗3：要件凍結の固執：AIDDの強みは柔軟性です。要件凍結に固執すると、メリットが消えてしまいます。

失敗4：ベンダーのAI習熟度を見抜けない：「AIを使っています」レベルの自己申告で選定すると、実態が伴わないことがあります。事例とPoCで検証しましょう。

失敗5：知財条項の曖昧さ：契約時に明文化しないと、後で揉める原因になります。標準条項を整備しておきましょう。

失敗パターン早見表

9. 内製とのバランス

AIDD時代でも、すべてを内製化する必要はありません。内製・受託・SaaSの3層構造 で、領域ごとに最適解を選びます。

内製領域：差別化要因・コア業務・継続改修が必要なシステムです。社内に知見を蓄積する価値がある領域になります。

受託領域：専門性が高い・短期で必要・社内人材がいない領域です。AIDDで内製コストが下がっても、専門性差は残ります。

SaaS領域：コモディティ化・標準化された機能です。自作する意味がない領域になります。

内製・受託・SaaSの判断軸

💡 戦略的判断：内製比率を 戦略的に管理 しましょう。100%内製は組織能力が高くなりますが、リソース集中リスクがあります。100%外注はコスト柔軟性が高い反面、ノウハウが社内に蓄積しません。50:50が一つの目安です。

10. ベンダーとの共創関係

最後に、最も重要なのは ベンダーとの関係性そのもの です。受発注ではなく、共創パートナーとしての関係を構築していきます。

透明性の高い情報共有：戦略・優先度・経営状況を、ベンダーと共有します。ベンダーが顧客の事業を理解できると、提案の質が劇的に変わります。

長期的な関係構築：1案件ごとに切り替えるのではなく、3〜5年スパンの関係を築きます。ベンダーが事業を理解する時間を投資します。

Win-Winの設計：ベンダーが利益を出せる構造にします。ベンダーが疲弊すると品質が落ちます。長期的なWin-Winが、結果的に発注側のメリットになります。

共創関係の特徴

まとめ

AIDD時代のベンダーマネジメントは、選定基準・契約形態・運用フレーム・知財ルールのすべてを再設計 する必要があります。AI習熟度の評価、成果ベース契約の活用、週次レビュー・プロト即生成での運用、ロックイン回避、共創関係の構築が新しい標準になります。「人月×期間」の見積もり方式は機能しなくなり、「機能単価×成果」へ移行していきます。発注側にも見極める力が問われる時代です。ベンダーを敵対関係でなく共創パートナー として扱える組織が、結果的に最も大きな成果を出しています。

ベンダー管理整備チェックリスト

• AI習熟度評価軸の整備
• 契約形態の使い分け方針（請負・準委任・成果ベース）
• 知財条項の標準化
• 価格評価の3層フレーム
• 週次デモ・隔週レビュー体制
• プロト即生成セッションの運用
• ベンダーロックイン回避策
• 内製・受託・SaaSの判断基準
• 共創関係の長期育成戦略
• 失敗パターンの予防策

IT COMPASSのAI駆動開発支援

IT COMPASS では、CTO経験者が外部CTO・技術顧問として、AIDD時代のベンダーマネジメントを伴走支援しています。

支援できること

• 🤝 ベンダー選定・評価：AI習熟度評価・PoC設計・契約形態選定
• 📋 契約書レビュー：知財・OSS・機密情報の標準条項整備
• 🛠 ツール選定とパイロット設計：Claude Code / Cursor / GitHub Copilot 等の評価・PoC設計
• 🛡 ガバナンス・セキュリティ整備：AI利用ポリシー、権限設計、知財・契約ルール
• 📈 経営会議への定例参加：取締役会・経営会向けのKPI設計と進捗レポート

こんな方におすすめ

• ベンダー選定基準を再設計したい経営者・購買責任者の方
• AI時代の契約条項を整備したい法務・調達担当の方
• ベンダーロックインを避けて自社主導のシステム戦略を作りたいCTOの方

お問い合わせ

スポット相談（1回／契約不要・最短当日）から、月額契約での継続伴走まで、フェーズに応じて柔軟に対応します。

👉 IT COMPASS お問い合わせフォーム

経営と技術の両面から、御社のAI駆動開発を一緒に設計しましょう。

監修者

西脇　靖紘（lanitech合同会社 代表取締役CEO 兼 CTO）

「テクノロジーで人と社会をつなぐ」をミッションに、企業のDX推進・AI導入支援から、デジタル教育・地域共創まで幅広く活動。エンジニアとしての現場経験と経営視点を活かし、外部CTO・AIコンサルティングなどを通じて企業のデジタル変革を支援しています。著書はオライリー・ジャパンから複数刊行。

 
lanitech合同会社 webサイト