「AI 機能の外注を任されたが、社内標準のウォーターフォール＋一括請負でいいのか、それともベンダー提案どおり準委任アジャイルに切り替えるべきか」——AI 開発の発注担当者が最初にぶつかる意思決定です。
背景には、稟議を通すためには総額と納期を確定させたい社内文化と、精度・データ・再学習など事前に確定しづらい AI 特有の不確実性の衝突があります。「AI＝アジャイル一択」と言い切るベンダー提案は稟議通過の説明材料として弱く、逆に社内文化に合わせてウォーターフォールに寄せると、精度目標の後追い修正で追加費用が膨らむ構造リスクを負います。
本記事は、この意思決定を「AI 開発特有の 4 つの不確実性軸」で分解し、案件条件からウォーターフォール／アジャイル／ハイブリッドのいずれを選ぶかを判定できる 4 軸マトリクスと、判定結果を稟議書 3 欄（開発手法・契約形態・費用管理方針）に転記する文言例、そしてベンダー選定時に「AI アジャイル実績」を確認する 5 つの質問までを整理します。
読み終わったときに、自社案件の手法・契約・費用管理方針を稟議書に自分の言葉で書ける状態を目指します。
はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ
この資料でわかること
AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。
こんな方におすすめです
- AI導入を検討しているが、何から始めればよいか分からない
- ベンダーの選び方や費用感がつかめず、判断できない
- 社内でAI導入の稟議を通すための資料が必要
入力いただいたメールアドレスにPDFをお送りします。
AI 開発でウォーターフォール／アジャイル選びを間違えるとどうなるか
AI 開発は「システム開発」の一種でありながら、通常のシステム開発以上に開発手法の選定ミスが失敗コストに直結します。理由は、AI 機能が持つ 3 つの構造的不確実性——精度が事前に確定できない・学習データの整備工数が読めない・再学習運用が発生する——のいずれかが、ウォーターフォール前提の一括見積を破綻させやすいためです。
まずはこの 3 パターンを可視化し、「社内文化がウォーターフォールだから」という理由だけで手法を決めることのリスクを言語化します。
精度が事前確定できない特性による追加費用
AI 機能の精度（正解率・再現率・F1 スコア等）は、実データで学習・評価するまで最終値が確定しません。ウォーターフォール＋一括請負で「精度○% を保証」と契約すると、開発着手後に目標未達が発覚した際に「精度改善のスコープ」が要件変更として計上され、追加費用と納期延伸を招きます。
特に「業務で許容できる精度水準」自体が発注側で言語化されていないケースでは、要件定義書に精度目標を書き込んだ時点で認識ズレが確定し、後工程で必ず修正が入る構造になっています。
学習データ準備の見積もり漏れによる失敗
AI 機能の品質はモデル選定より学習データの品質・量に依存します。しかし要件定義段階では「社内にあるデータで学習できる」という前提で見積もられがちで、実装フェーズに入ってから「データが不足している」「ラベル付けが必要」「クレンジング工数が想定の 3 倍かかる」といった問題が顕在化します。
一括請負契約でこの追加工数を吸収させると、ベンダー側の採算が悪化してモチベーションが落ちるか、追加費用の請求で稟議差戻しが発生します。データ準備工数を最初から可変として扱える契約形態を選ぶことが、この失敗パターンを回避する鍵になります。
再学習運用の想定漏れによる保守費用膨張
AI モデルは、時間経過とともに精度が劣化します（データドリフト）。ユーザー行動の変化・市場環境の変化・扱う商品の入れ替わりなどで、学習時点と本番運用時点のデータ分布がずれるためです。
初回リリース時点で「再学習運用」の設計がなされていないと、リリース半年後にモデル精度が業務許容水準を下回り、慌てて追加開発を発注することになります。保守費用が読めなくなり、社内で「AI プロジェクトは費用対効果が悪い」という評価を招く典型的なパターンです。開発手法の選定時点で、再学習運用のリリースサイクルを組み込めるかを検討する必要があります。
ウォーターフォールとアジャイルの違い（AI 開発観点で最小限に要約）
一般的なウォーターフォール／アジャイルの定義比較は既に多くの記事で解説されているため、本記事では AI 開発文脈で意味を持つ差分だけを 4 項目に絞って要約します。定義そのものの詳細を確認したい場合は、ウォーターフォール開発とアジャイル開発の違い をご覧ください。
要件変更許容度（AI 開発で最重要となる差分）
ウォーターフォールは要件定義書を凍結して後工程に進める前提で、要件変更は追加見積として扱います。アジャイルはスプリント単位で優先度を再評価し、要件変更を前提として運用します。
AI 開発では精度目標・学習データ・再学習方針の 3 領域で要件が動きやすいため、要件変更許容度の差はほぼそのまま「AI 特有の不確実性を吸収できるか」の差になります。この 1 軸だけで見ると、AI 開発はアジャイル寄りに設計する合理性があります。
契約形態（一括請負 vs 準委任）と AI 開発でのフィット
ウォーターフォールは一括請負契約と親和性が高く、成果物と対価が事前に確定します。アジャイルは準委任契約（時間・工数ベース）と親和性が高く、成果物ではなく作業実施に対価を支払います。
AI 開発で一括請負を選択する場合、精度未達時の責任分界が争点になります。準委任は責任分界が明確になる代わりに、稟議書で「総額いくら」を書けないため、社内説明の工夫が必要になります。この論点は後述の契約形態セクションで詳しく扱います。
費用確定タイミングの違い（社内稟議との整合性）
ウォーターフォール／一括請負は稟議申請時点で総額が確定します。アジャイル／準委任は月額の上限枠を設定し、実績ベースで清算する構造です。
社内稟議が「総額いくら」を求める文化の場合、アジャイル提案をそのまま持ち込むと稟議差戻しが発生します。マイルストーン型（PoC 定額＋本番化準委任）などの折衷案を設計しないと、稟議通過と AI 開発の柔軟性を両立できません。
リリース単位（一括カットオーバー vs 段階リリース）
ウォーターフォールは全機能を一括でカットオーバーします。アジャイルは MVP・段階リリースで小さく出して大きく育てます。
AI 開発では、初回リリース後の再学習・モデル入れ替えが継続発生するため、段階リリースを組み込めるアジャイル寄りの設計が構造的にフィットしやすいのが実情です。
AI 開発でアジャイルが選ばれやすい 3 つの構造的理由
多くのベンダーが AI 案件でアジャイルを提案する理由は、営業上の都合ではなく AI の技術特性に根差した合理性があります。発注者としてベンダー提案を評価する際、以下 3 点を「技術的必然性」として理解しておくと、提案の妥当性を判断しやすくなります。
精度検証は 1 回で決着しない（実データでの評価反復が構造的に必要）
AI モデルの精度は、学習データ・特徴量設計・アルゴリズム選択・ハイパーパラメータの組み合わせで大きく変動します。「1 回の学習で目標精度を達成」というシナリオはむしろ稀で、通常は複数のモデル・特徴量セットを試行し、実データでの評価を反復します。
この反復サイクルをウォーターフォールの単一の「実装フェーズ」に押し込めると、進捗管理が破綻します。スプリント単位で「今回試行したモデルの精度」「次スプリントで試すアプローチ」を可視化するアジャイル運用の方が、精度改善プロセスの管理と整合します。
PoC から本番化への遷移で仕様は必ず更新される
AI プロジェクトは PoC（概念実証）→ 本番化の 2 段階で進むケースが多く、PoC で得た知見（精度限界・データ課題・処理性能）を反映して本番化フェーズの要件が更新されます。この更新を「要件変更」として追加見積するウォーターフォール／一括請負の設計は、PoC の学習を活用しづらい構造になります。
アジャイル前提で「PoC の学びを次スプリントの計画に反映する」運用を組めば、PoC 投資が本番化に自然に接続されます。
継続学習・モデル入れ替えを前提としたリリースサイクル
前述のとおり AI モデルは時間経過で精度劣化するため、再学習・モデル入れ替えが継続発生します。この運用フェーズをアジャイルのスプリントサイクルに組み込めば、「四半期ごとにモデル評価・入れ替え判断・本番デプロイ」を定型化できます。
ウォーターフォールで「保守フェーズ」に切り出すと、モデル入れ替えのたびに稟議追加が発生し、対応スピードが落ちます。
AI プロジェクトをアジャイルで進める具体的な運用手順については、AI アジャイル開発の進め方（発注者ガイド） にまとめています。
AI 開発でもウォーターフォールが妥当なケース
一方で「AI＝アジャイル一択」の思い込みも危険です。AI 開発でも、以下の 3 条件のいずれかを満たすケースではウォーターフォール（または上流ウォーターフォール型ハイブリッド）が有効な選択肢になります。社内文化がウォーターフォールの環境で「無理にアジャイルに寄せない方が結果が良い案件」を見極めるための判定基準として活用してください。
精度目標が業界ベンチマーク・既存モデルで既定されているケース
汎用的な画像分類・OCR・音声認識など、業界ベンチマーク（ImageNet / COCO 等）で達成可能な精度水準が公開されており、案件固有のカスタマイズが最小限で済む場合は、精度目標を事前確定できます。この場合は精度未達リスクが低く、ウォーターフォール＋一括請負でも成立します。
ただし「業務データに合わせたファインチューニングが必要」「対象クラスが業界ベンチマークにない」場合は、この条件から外れます。
規制業種・監査要件で要件凍結が必要なケース
金融・医療・公共分野など、規制当局への申請・監査対応で「要件定義書の凍結が制度上必要」なケースがあります。この場合、アジャイルの「要件変更を前提とする」性質は制度側と整合せず、上流だけでもウォーターフォールで固める設計が求められます。
規制対応の合意形成と AI 開発の柔軟性を両立するには、後述するハイブリッド（要件定義後に切り替え）の設計を検討する余地があります。
学習済みモデル導入・API 統合中心で再学習運用が発生しないケース
OpenAI API・Google Cloud Vertex AI・AWS Bedrock などの学習済みモデルを API 経由で呼び出し、社内システムと統合するだけのケースでは、自社での再学習運用が発生しません。開発対象は「API 呼び出し・プロンプト設計・システム統合」に閉じるため、通常の SaaS 連携開発と同じ性質になり、ウォーターフォール＋一括請負でも成立します。
RAG（検索拡張生成）を組み合わせる場合も、社内ドキュメント側の更新運用が主となり、モデル自体の再学習は発生しないため同じ扱いになります。
はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ
この資料でわかること
AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。
こんな方におすすめです
- AI導入を検討しているが、何から始めればよいか分からない
- ベンダーの選び方や費用感がつかめず、判断できない
- 社内でAI導入の稟議を通すための資料が必要
入力いただいたメールアドレスにPDFをお送りします。
AI 開発の手法選定 4 軸マトリクス
ここまでで「AI 開発でアジャイルが選ばれやすい構造的理由」と「ウォーターフォールが妥当なケース」を整理しました。この章では両者を統合し、AI開発の開発手法を案件条件から判定できる 4 軸マトリクス（AI開発の手法選定を発注者視点で標準化する枠組み）を提示します。
軸は「AI 開発特有の 4 つの不確実性」——精度目標の事前確定可能性／学習データの整備状況／再学習運用の必要性／規制・監査要件——です。一般案件向けの選定マトリクス（コスト・納期・スコープ変動性・内製リソース等）を確認したい場合は、アジャイル・ウォーターフォールの選び方（一般案件向け 4 軸マトリクス） をご覧ください。
軸1「精度目標の事前確定可能性」の判定手順
以下の 3 質問すべてに Yes と答えられれば「事前確定可能（High）」、1 つでも No があれば「事前確定困難（Low）」と判定します。
- 業務で許容できる精度水準（例: 誤検知率 5% 以下）を発注側が明文化できているか
- その精度水準が業界ベンチマーク・既存モデルの実測値で既に達成可能と示されているか
- 精度未達時の業務影響と代替運用（人手フォールバック等）が事前合意できているか
軸2「学習データの整備状況」の判定手順
以下の 3 質問すべてに Yes と答えられれば「整備済み（High）」、1 つでも No があれば「未整備（Low）」と判定します。
- 学習に必要なデータが社内にすでに蓄積されているか（過去 1 年分以上）
- ラベル付け・クレンジングの必要工数がベンダー・発注者双方で合意されているか
- データ利用に関する法務・個人情報保護の確認が完了しているか
軸3「再学習運用の必要性」の判定手順
以下の 2 質問のいずれかに Yes があれば「必要（High）」、両方 No なら「不要（Low）」と判定します。
- 対象データが時系列で変化する性質を持つか（ユーザー行動・市場・商品構成の入れ替わり等）
- 自社データで学習・ファインチューニングを行うか（学習済み API 呼び出しのみでないか）
軸4「規制・監査要件」の判定手順
以下の 2 質問のいずれかに Yes があれば「厳格（High）」、両方 No なら「一般（Low）」と判定します。
- 規制当局への申請・監査対応で要件定義書の凍結が制度上必要か
- 開発プロセスの記録・成果物の完全性保証が契約上求められるか
4 軸を組み合わせた 8 パターン推奨手法マトリクス
上記 4 軸の判定結果（High/Low）を組み合わせて、推奨手法を判定します。
# | 精度目標 | 学習データ | 再学習運用 | 規制監査 | 推奨手法 | 補足 |
|---|---|---|---|---|---|---|
1 | High | High | Low | Low | ウォーターフォール | 学習済み API 統合・要件凍結型に近く一括請負が成立しやすい |
2 | High | High | Low | High | ウォーターフォール | 規制要件との整合を優先。要件凍結で監査対応 |
3 | High | High | High | Low | ハイブリッド | 上流 WF ／運用アジャイル。再学習フェーズを準委任で切り出す |
4 | High | High | High | High | ハイブリッド | 要件定義後に切り替え型。再学習運用の稟議は年次で分割 |
5 | Low | High | Low | Low | アジャイル | 精度検証の反復が必要。PoC 定額＋本番準委任推奨 |
6 | Low | Low | Low | Low | アジャイル | データ整備工数も可変で扱う。準委任＋月額上限型 |
7 | Low | * | High | Low | アジャイル | AI 開発の最もアジャイル適合的なパターン |
8 | Low | * | * | High | ハイブリッド（PoC 完了後切替型） | 規制対応の要件凍結は PoC 後に実施 |
* は「High/Low いずれでも同じ推奨」を意味します。自社案件を 4 軸で診断し、上記マトリクスから推奨手法を特定した上で、次章のハイブリッド設計・契約形態設計に進んでください。
ハイブリッド（Water-Scrum-Fast）を採用する場合の切り分け方
マトリクスで「ハイブリッド」が推奨された場合、次に決めるのは「どこで手法を切り替えるか」です。ハイブリッド型のAIプロジェクトの進め方は、上流をウォーターフォール／下流をアジャイルという一般論だけで組み立てると「ミニウォーターフォールに退化するリスク」を回避できません。ここでは切り替え点を 3 案で比較し、案件条件に応じた選定基準を提示します。
要件定義後に切り替える設計（社内稟議親和性が高いパターン）
要件定義フェーズをウォーターフォールで固め、実装以降をアジャイルで進める設計です。稟議書に「要件定義書を成果物として一括請負で発注し、実装フェーズは準委任で月額上限枠を確保」と書けるため、社内稟議との整合性が最も高くなります。
一方で、要件定義段階では AI 特有の不確実性（精度未達・データ不足）が可視化されていないため、実装フェーズ開始後に大幅な要件更新が発生した場合の追加費用計上がしばしば争点になります。要件定義書に「AI 精度目標は PoC 実施後に再合意する」と明記し、追加費用条件を稟議書側にも書いておく設計が必要です。
PoC 完了後に切り替える設計（精度リスクを先出しするパターン）
要件定義＋PoC までをウォーターフォール（PoC 定額）で発注し、精度・データ課題を可視化した後に本番化フェーズをアジャイル（準委任）で発注する設計です。PoC の学びを本番化計画に反映できるため、要件定義段階での見積不確実性を最も抑えられます。
稟議書は「PoC フェーズ」「本番化フェーズ」の 2 段階で分割申請する形になります。PoC フェーズの稟議通過後、PoC 結果に基づいて本番化フェーズの稟議を追加申請する運用です。稟議プロセスが 2 回発生する代わりに、本番化フェーズの見積精度が上がります。
MVP リリース後に切り替える設計（早期リリース重視パターン）
要件定義＋MVP リリース（最小構成での本番投入）までをウォーターフォールで発注し、MVP リリース後の機能拡張・再学習運用をアジャイルで発注する設計です。競合先行を避けたい・業務変革のインパクトを早期に測りたいケースで有効です。
MVP の範囲を最小化する意思決定が発注側にも求められます。「MVP＝要件の 30% を 2 ヶ月でリリース、残り 70% は運用フェーズで段階拡張」といった水準感を、ベンダーと事前合意する必要があります。参考として、秋霜堂株式会社の TechBand では新規 SaaS の MVP を 2 ヶ月で構築し、その後月額 100〜300 万円で継続拡張する運用実績があります（自社実績に基づく）。
「ミニウォーターフォールに退化しない」ための運用チェックポイント
ハイブリッドを名乗りながら、下流フェーズが実質「短いスパンで区切られたウォーターフォール」になっているケースが少なくありません。以下 3 点を運用チェックポイントとして、ベンダーとの合意事項に含めてください。
- スプリント計画で「今スプリントで検証する仮説」を明示している（要件消化ではなく仮説検証を主眼にする）
- スプリントレビューで「今回学んだこと・次スプリントへの反映」を発注者が確認する（進捗報告ではなく学びの共有にする）
- バックログの優先順位は毎スプリント再評価する（要件定義書の順序で固定しない）
契約形態と費用管理の設計（稟議書に転記できる粒度で）
選定した手法に応じて、契約形態と費用管理方針を組み合わせます。この章では、稟議書の「契約形態」「費用管理方針」欄に転記できる文言テンプレートを提示します。
一括請負が成立する条件（AI 開発でも成立するケース）
4 軸マトリクスの「精度目標 High × 学習データ High × 再学習運用 Low」パターン（マトリクス#1〜#2）では、一括請負が成立します。稟議書には以下の要領で記載します。
- 契約形態: 一括請負契約（成果物完成基準）
- 費用管理方針: 総額固定型。追加要件発生時は変更契約で対応
- 特記事項: AI 精度目標は業界ベンチマーク（○○% 相当）で事前確定。学習データは弊社（発注側）保有分で学習可能
「弊社」の表記は発注側の社内稟議で使う自然な表現として例示しています。
準委任契約で総額上限を稟議通過させる書き方
4 軸マトリクスでアジャイルが推奨されたパターンでは準委任契約が第一選択ですが、稟議書に「総額いくら」を書けないため、社内説明の工夫が必要です。以下の要領で「月額上限×期間」で総額を稟議通過させる書き方が定石になります。
- 契約形態: 準委任契約（作業実施基準）
- 費用管理方針: 月額上限型(○○万円/月 × ○○ヶ月 = 総額上限 ○○万円)
- 特記事項: 月次でスプリントレビュー実施。上限超過時は次月のスコープ調整で吸収。総額上限を超える要件は変更契約で追加稟議
社内稟議で「準委任」への抵抗が強い場合は、「作業内容を月次レポートで報告し、成果を発注側が承認するプロセスを組み込む」旨を稟議書に明記すると通過率が上がります。
マイルストーン型（PoC 定額 + 本番化準委任）の設計
ハイブリッドで「PoC 完了後切替型」を選定したパターンで有効な設計です。稟議は 2 段階で分割申請します。
- 第 1 段階（PoC フェーズ）: 一括請負契約（成果物: PoC 結果レポート）／総額 ○○万円 ／期間 ○○ヶ月
- 第 2 段階（本番化フェーズ）: 準委任契約 ／ 月額上限 ○○万円 × ○○ヶ月 = 総額上限 ○○万円
- 特記事項: PoC 結果に基づき第 2 段階の見積を再合意。第 2 段階着手前に追加稟議を実施
「PoC 定額」の水準は、精度検証に必要なモデル試行回数と工数から逆算します。ベンダー提案時に「PoC で何を検証するか・何回の試行を含むか」を確認してください。
追加費用の発生条件を稟議書に明記する文言例
AI 開発の稟議書で最も揉めやすいのが「追加費用の発生条件」です。稟議書に以下の文言を先出しして書いておくと、事後の稟議差戻しリスクを大きく下げられます。
- 「学習データのクレンジング・追加取得が想定を超える場合、追加費用として計上する（見込み: ○○万円 / 想定超過ケース）」
- 「精度目標未達で追加試行が必要となった場合、変更契約で対応する（見込み: ○○万円 / 見込み想定）」
- 「本番リリース後の再学習運用は、別途保守契約で対応する（月額 ○○万円想定）」
先出しの文言があれば、追加費用の発生自体は稟議差戻しの対象になりません。「事前に想定していた追加費用」と「想定外の追加費用」を分けて説明できる稟議書を目指してください。
ベンダー選定時に「AI アジャイル実績」を確認する 5 つの質問
ここまでで手法・契約形態・費用管理方針まで整理できました。最後に、ベンダーヒアリング時に「本当にこのベンダーは AI アジャイルを回せるのか」を確認する 5 つの質問を提示します。読み終わった直後にベンダーヒアリングで使える形にしています。
質問1「週次スプリントで AI モデル評価をどう回すか」
期待回答の水準感: 「毎スプリント（1〜2 週）で 1〜3 個のモデル試行を実施し、評価指標（精度・処理時間・コスト）をスプリントレビューで報告」「試行の優先順位を発注者と合意してから次スプリント計画に入る」
参考として、秋霜堂の TechBand では全案件で週 1 回の定例＋リアルタイムチャット対応をベースに、1 スプリント＝ 5 営業日で「ヒアリング → 設計 → 実装 → デモ・リリース」を回す運用を採用しています（自社実績に基づく）。ベンダーが提示するスプリントピッチと運用密度を、この水準感と照らして確認してください。
質問2「精度未達時のスコープ調整合意プロセス」
期待回答の水準感: 「スプリントレビューで精度実測値を共有し、目標未達時は次スプリントで『試行するアプローチの優先順位』を発注者と合意する」「代替アプローチが尽きた場合の判断基準（追加学習データ取得／モデル変更／業務要件緩和）を事前に定義している」
「精度未達 = 全面追加費用」というスタンスのベンダーは、AI 特有の不確実性を前提としたスコープ調整の運用経験が浅い可能性があります。
質問3「再学習運用の想定期間と費用」
期待回答の水準感: 「月次または四半期ごとに精度モニタリングを実施し、劣化検知時に再学習を発動する運用を提案できる」「再学習 1 回あたりの想定工数と月額保守費用の目安を提示できる」
再学習運用の設計がない・保守は別途相談としか答えられないベンダーは、AI 本番運用の実績が浅い可能性があります。
質問4「PoC 定額の設定根拠」
期待回答の水準感: 「PoC で検証する仮説（達成すべき精度水準・比較するモデルの数・想定するデータ量）を明示できる」「PoC 定額に含まれる試行回数・除外条件（追加試行が必要な場合の変更契約条件）を提示できる」
「PoC 定額 ○○万円」とだけ提示され根拠が説明できないベンダーは、PoC の学びを本番化に接続する運用経験が浅い可能性があります。
質問5「稟議通過を助ける進捗レポートの粒度」
期待回答の水準感: 「月次レポートで『実施した試行・得られた学び・次月の計画』を発注者の社内稟議に転用できる粒度で報告できる」「スプリントレビュー資料を発注者側の経営層・稟議承認者向けに再編集した形で提供できる」
準委任契約で稟議通過を支えるのは、月次レポートの粒度と社内転用しやすさです。この 5 番目の質問への回答が具体的なベンダーは、発注者側の社内合意形成プロセスを理解している可能性が高くなります。
まとめ ― 自社案件を 4 軸マトリクスで診断し、稟議書に落とす
ここまでの内容を、実務で使える手順に凝縮します。
4 軸診断チェックシート（1 分で診断できる 4 質問）
- 精度目標: 業務許容精度が業界ベンチマーク相当で事前確定できるか？（Yes → High / No → Low）
- 学習データ: 社内に必要データが蓄積済みでラベル・法務確認まで完了しているか？（Yes → High / No → Low）
- 再学習運用: 対象データが時系列で変化するか、自社データで学習するか？（いずれか Yes → High / 両方 No → Low）
- 規制監査: 要件定義書の凍結が制度上必要か、開発プロセスの完全性保証が求められるか？（いずれか Yes → High / 両方 No → Low）
この 4 質問の結果を、先ほど提示した 8 パターン推奨手法マトリクスに当てはめて、ウォーターフォール／アジャイル／ハイブリッドのいずれを選ぶかを確定してください。
稟議書 3 欄への転記例
上記診断で選定した手法に応じて、稟議書 3 欄（開発手法・契約形態・費用管理方針）に以下の要領で転記します。
アジャイル選定時の転記例
- 開発手法: アジャイル開発（週次スプリント、月次スプリントレビュー）
- 契約形態: 準委任契約
- 費用管理方針: 月額上限 ○○万円 × ○○ヶ月 = 総額上限 ○○万円。上限超過時は次月スコープで吸収、超過が継続する場合は変更契約で追加稟議
ウォーターフォール選定時の転記例
- 開発手法: ウォーターフォール開発（要件定義 → 設計 → 実装 → テスト → リリースの一括カットオーバー）
- 契約形態: 一括請負契約（成果物完成基準）
- 費用管理方針: 総額固定型 ○○万円。追加要件発生時は変更契約で対応。想定される追加費用条件は特記事項に明記
ハイブリッド選定時の転記例（PoC 完了後切替型）
- 開発手法: ハイブリッド（要件定義＋PoC はウォーターフォール、本番化以降はアジャイル）
- 契約形態: PoC は一括請負 ／ 本番化は準委任
- 費用管理方針: PoC 定額 ○○万円 ／ 本番化は月額上限型 ○○万円 × ○○ヶ月。PoC 結果に基づき本番化フェーズを追加稟議
次のアクション
診断結果と稟議書ドラフトができたら、次のアクションはベンダーヒアリングです。先ほど提示した 5 つの質問を持ってヒアリングに臨み、各ベンダーの回答を並べて比較すると、AI アジャイルの運用経験差が可視化されます。
関連情報
AI 開発の発注準備をさらに進めたい方は、開発会社選定・見積比較・要件整理に役立つ お役立ち資料一覧 をご覧ください。稟議書テンプレートや発注前チェックリストをご用意しています。
AI 開発の発注方針や社内稟議の設計についてご相談されたい方は、お問い合わせフォーム からご連絡ください。要件が固まっていない段階から、手法選定・見積レンジのすり合わせに伴走します（構想段階からの伴走実績あり／自社実績に基づく）。
はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ
この資料でわかること
AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。
こんな方におすすめです
- AI導入を検討しているが、何から始めればよいか分からない
- ベンダーの選び方や費用感がつかめず、判断できない
- 社内でAI導入の稟議を通すための資料が必要
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- ウォーターフォールとアジャイル、AI開発ではどちらか一方しか選べないのですか？
必ずしも二択ではありません。4軸マトリクスの判定結果によっては、上流をウォーターフォール・下流をアジャイルで進めるハイブリッド（Water-Scrum-Fast）が推奨されるケースも多くあります。
- 社内稟議で「総額いくら」を求められますが、準委任契約（アジャイル）だとどう書けばよいですか？
「月額上限×契約期間＝総額上限」という形で総額を明記できます。上限超過時は次月のスコープ調整で吸収し、それでも収まらない場合は変更契約で追加稟議する旨を併記します。さらに月次でスプリントレビューを実施し、成果を発注側が承認するプロセスを稟議書に明記すると通過率が上がります。
- PoCだけ先に発注し、本番化は様子を見てから決めることはできますか？
可能です。要件定義とPoCを一括請負の定額で発注し、PoC結果を踏まえて本番化フェーズを準委任で追加稟議する「マイルストーン型」設計が、見積の不確実性を最も抑えられる方法です。稟議書はPoCフェーズと本番化フェーズの2段階に分割申請し、PoC結果に基づいて本番化の見積精度を上げる運用になります。
- ベンダーから「AI開発はアジャイル一択」と言われましたが、鵜呑みにしていいですか？
精度目標が業界ベンチマークで確定できる、規制で要件凍結が必須、API統合のみで再学習が発生しない、のいずれかに該当する場合はウォーターフォールも十分成立します。自社案件を4軸で診断してから判断してください。
- ハイブリッドで進めても、結局ミニウォーターフォールになってしまいませんか？
ベンダーがスプリント計画で「今スプリントで検証する仮説」を明示し、発注者がスプリントレビューで学びと次スプリントへの反映を確認し、バックログの優先順位を要件定義書の順序に固定せず毎スプリント再評価する、という3つの運用チェックポイントを合意事項に含めることで回避できます。
- ベンダーの「AIアジャイル実績」が本物かどうか、契約前にどう見極めればよいですか？
週次スプリントでのモデル評価方法、精度未達時のスコープ調整プロセス、再学習運用の想定期間と費用などを具体的に提示できるかを確認してください。抽象的な回答しかできないベンダーは実績が浅い可能性があります。
