はじめに：最初の発注は「規模」ではなく「境界」で失敗する
AI 導入の相談で一番多いのが、「とりあえず小さく始めたいのですが、どこまで頼めばいいか分からない」という悩みです。予算を絞ること自体は正しい判断ですが、金額だけ小さくして範囲を曖昧にしたまま発注すると、1 か月後に残るのは「なんとなく動くデモ」と「次に何を頼めばいいか分からない状態」になりがちです。
小さく始めるとは、作る量を減らすことではなく、決めるべきことを決め切る範囲を先に区切ることです。この記事では、初回 1 か月の発注で何を含め、何を次フェーズに送るか、その線の引き方を整理します。発注側の担当者が、見積もり依頼メールを書く前に使えるチェック項目まで落とし込みます。
用語を 3 つだけ揃えておく
ベンダーとの会話で前提がずれる原因の多くは、言葉の定義です。最低限、次の 3 つは社内で共通認識にしておくと話が早くなります。
- PoC（ピーオーシー／概念実証）：本格的に作る前に、「技術的に成立するか」「業務で使えそうか」を小規模に試す工程。成果物は本番システムではなく、判断材料です。
- RAG（検索拡張生成）：社内文書やマニュアルを検索し、見つかった文章を AI に渡して回答させる仕組み。AI 自体に自社の知識を覚え込ませる（追加学習する）のではなく、都度参照させる方式のため、初期導入で選ばれることが多い構成です。
- スコープ：発注する作業の範囲。「何を作るか」だけでなく「どこまでを完了とみなすか」を含みます。初回発注でもめるのはほぼここです。
最初の 1 か月の成果物は「動くもの」ではなく「次の判断材料」
初回 1 か月で本番システムを完成させようとすると、業務要件の確認が甘いまま実装に入り、後から大きな手戻りが発生します。逆に、調査だけで終わると社内の説得材料が作れません。現実的な落としどころは、限定された 1 業務で動く試作と、それを本番化するための見積もり根拠をセットで受け取ることです。
1 か月を週単位で区切るなら、たとえば次のような配分が考えられます（あくまで一例で、業務の複雑さによって変わります）。
| 期間 | やること | 発注側の作業 |
|---|---|---|
| 第 1 週 | 対象業務のヒアリング、現行手順の分解 | 担当者の時間確保、現行帳票・マニュアル提供 |
| 第 2 週 | 試作の方式決定、サンプルデータでの検証 | データの持ち出し可否・マスキング方針の決定 |
| 第 3 週 | 限定機能の試作、現場担当者による試用 | 実際に触る担当者を 2〜3 名アサイン |
| 第 4 週 | 精度・工数の評価、本番化の概算見積もり | 継続判断の社内決裁ルート確認 |
重要なのは第 4 週です。「良さそうだったので次も頼みます」で終わらせず、本番化するなら何が必要で、いくらかかり、どのリスクが残るのかを文書で受け取る契約にしておきます。ここを初回スコープに入れておかないと、次の稟議が通りません。
発注範囲の切り方：4 つの型から 1 つを選ぶ
「小さく始める」と言っても切り方は一通りではありません。何を小さくするかで、得られる知見が変わります。
| 切り方 | 内容 | 向いているケース | 注意点 |
|---|---|---|---|
| 業務を絞る | 複数業務のうち 1 つだけを対象にする | 適用先が複数あり、どれが効果的か未確定 | 選んだ業務が例外的だと横展開できない |
| 工程を絞る | 1 業務の中の「下書き作成まで」など前半だけを担当 | 最終判断を人が持つ必要がある業務 | 人の確認工数が減らないと効果が出ない |
| 利用者を絞る | 1 部署・数名だけが使う形で開始 | 現場の受け入れ度合いを測りたい | 熱心な人だけで試すと評価が甘くなる |
| データを絞る | 特定の文書種別・特定期間のデータのみ扱う | 社内データの整備状況が不明 | 本番データで精度が落ちる可能性が残る |
初回は「業務を絞る」と「工程を絞る」の組み合わせが扱いやすいことが多いです。たとえば次のような場面です。問い合わせ対応業務のうち、よくある質問カテゴリ 3 種類に限定し、回答の下書きを AI が作り、送信は必ず人が確認する——という範囲なら、1 か月でも検証できる粒度になります。
逆に、初回に入れないほうがよいもの
- 基幹システムとの本格連携：権限設計やテスト環境の準備だけで 1 か月が終わります。初回は CSV 手動取り込みで十分です。
- 全社向けの UI 作り込み：使われ方が固まる前のデザイン投資は無駄になりやすい領域です。
- 複数業務の同時検証：どの要因で精度が出なかったのか切り分けられなくなります。
見積もり依頼の前に、自社で決めておく 4 項目
ベンダーが見積もりを出せない最大の理由は、情報不足ではなく判断の未確定です。次の 4 つは発注側にしか決められません。
- 合格ラインの定義：「精度 90 パーセント」のような数字を先に置くより、業務上の基準に翻訳するほうが実務的です。たとえば「担当者が下書きをそのまま使えた割合」「修正にかかった時間が現行より短いか」といった、現場が判定できる形にします。
- データの扱いの方針：個人情報を含むデータを外部サービスに送ってよいか。これは個人情報保護法の観点と社内規程の両方で確認が必要です。あわせて、総務省・経済産業省が公表しているAI 事業者ガイドラインのような指針を社内方針づくりの参照先にしておくと、説明がしやすくなります。
- 契約形態：成果物を確定しにくい探索段階は準委任、作るものが決まっている段階は請負、という使い分けが一般的です。初回検証を請負で固定すると、途中で方針変更できず双方が苦しくなります。
- 検証後の撤退条件：「この条件を満たさなければ本番化しない」を先に書いておくと、惰性での継続を避けられます。
依頼文に入れておきたい一文
見積もり依頼には、次のような趣旨の文を入れておくと、提案の粒度が揃います。
- 対象業務と、検証に含めない範囲を明記する
- 利用する AI サービスの種類と、学習にデータが利用されない設定かどうかの確認を求める
- 検証終了時に、本番化の概算見積もりと残存リスクの一覧を納品物に含めるよう指定する
- 既存資料（マニュアル、過去の対応履歴など）の提供可能範囲を先に伝える
著作権・社内規程まわりで先に潰しておく確認
AI が生成した文章や画像を業務で使う場合、入力したデータと出力物の双方に配慮が必要です。他社の著作物を無断で入力・出力して公開すると問題になり得るため、著作権法の観点を社内の法務・管理部門と事前にすり合わせておきます。判断が難しい論点も多いため、断定的な自己判断を避け、必要に応じて専門家に確認する前提で進めるのが安全です。
また、生成 AI サービスの利用規約は改定されることがあります。「入力データが学習に使われない設定になっているか」は、契約プランや設定によって変わるため、導入時点の公式ドキュメントで必ず確認することをベンダーとの合意事項に含めてください。
まとめ：1 か月で手に入れるべきは「次の一手の根拠」
初回発注を成功させるポイントを整理します。
- 小さく始めるとは金額を削ることではなく、スコープの境界を明文化すること
- 1 か月の成果物は、限定機能の試作に加えて本番化の見積もり根拠とリスク一覧
- 範囲の切り方は「業務・工程・利用者・データ」の 4 軸。初回は業務と工程を絞るのが扱いやすい
- 合格ライン、データ方針、契約形態、撤退条件の 4 つは発注側が決める
- 基幹連携や UI 作り込みは、使われ方が固まってから
明日からできることは単純です。自社の業務を 1 つ選び、その手順を箇条書きで 10 行程度に分解してみてください。そのうち「文章を読んで要約する」「定型文を書く」といった工程がどれかを印を付ければ、それがそのまま初回発注の対象候補になります。この 1 枚があるだけで、ベンダーからの提案の精度は目に見えて変わります。
この記事は、AI で下書きを作り、益山康秀（運営者）が内容を確認して公開しています
