AI開発会社に依頼する前に何を準備するか：本当にコストを下げるシステムにするために

1. ベンダー探しの前に、社内の準備を整える

家を建てるとき、施工会社にいきなり「どんな家を建てたらいいですか」と聞きに行く人はいません。まず、何人で住むのか、予算はいくらか、土地の間口はどれくらいかを伝えます。ソフトウェアのプロジェクトも同じです。

業務プロセスを変える権限があり、質問に答えられる業務の責任者（Business Owner）を任命します。ITチームや秘書に調整役を丸投げするのは避けてください。中心となる判断は、ルール、リスク、KPIに関わるものだからです。責任者がいないと、開発会社は回答を待たされ、すき間を推測で埋めることになります。

ベースラインのデータを集めます。件数、工程ごとの時間、ミス、サイクルタイム、人数、費用です。まだ数字がなければ、それを集めるための調査フェーズ（Discovery Phase）を依頼します。「AIで会社を助けてほしい」といった説明だけで、システム一式の見積もりを求めるのはやめましょう。提案書ごとに解釈が違ってしまい、比べられなくなります。

予算の幅と期間を決め、制約条件も伝えます。たとえば、データはタイ国内に保管しなければならない、既存のシステムを使う、顧客データを社外に出してはいけない、重要な繁忙日がある、といった条件です。ここを隠さず伝えれば、ベンダーは過剰な設計にも、要件に届かない設計にもならない、自社に合ったアーキテクチャを提案できます。

2. 機能一覧を書く前に、1枚のビジネスブリーフを書く

課題は何か、誰が使うのか、すでにあるデータは何か、効果をどう測るのかを書いた1枚の資料があれば、どのベンダーも同じ課題に対して提案することになり、提案を本当の意味で比べられます。

まず課題とその影響から書きます。たとえば「事務チーム6人が月4,000件の注文を処理し、1件に平均12分かかり、3%に誤りがある。件数が20%増えるたびに1人増員しなければならない」といった書き方です。次に、目指す成果を書きます。作業時間（Touch Time）を4分に減らし、人を増やさずに50%多い件数をこなす、などです。

現在のワークフロー、データの入り口、システム、関わる人、例外、間違えたときの損害を説明します。範囲に含めないことも明記します。たとえば、支払いの承認はまだ扱わない、ERPは変えない、顧客への自動返信はまだしない、といったことです。対象外を書いておくと、プロジェクトが途中で膨らむのを防げます。

技術を早い段階で決めつけるのは避けましょう。実際にはルールどおりにデータを移すだけの仕事なのに、「AIエージェントを使わなければならない」と決めてしまうような場合です。どの部分に自動化を使い、どの部分にAIを使うのか、その理由は何かは、ベンダーが説明すべきです。賢さでは劣る仕組みのほうが、安くて安定していることがよくあります。

3. 開発会社が評価できるよう、データとシステムを準備する

データの所在を一覧にします。CRM、ERP、データベース、メール、ファイルストレージ、スプレッドシート、マニュアル、外部データなどです。それぞれの責任者、形式、量、更新頻度、品質、アクセス権限を書きます。個人のファイルやシステムの外で行っている手順があるなら、正直に伝えてください。システム連携のコストが一番かさむのは、たいていそこです。

標準的なケース、情報が欠けたケース、乱れた言葉づかい、例外を含む多様なサンプルを少なくとも50〜100件用意し、それぞれに正解か確認方法を添えます。正解データ（Ground Truth）がなければモデルを評価できず、デモでは簡単なケースばかりが選ばれることになります。

個人データ、営業秘密、顧客との契約に関する要件を確認します。どのデータを開発に使ってよいか、マスキングが必要か、保存期間はどれくらいか、モデルの提供元がデータを学習に使うかどうかを決めます。NDA（秘密保持契約）、アクセス権限、適切な受け渡し経路が整う前に、本番データをベンダーに送ってはいけません。

4. 見積もりを取る前に、試験導入の範囲とKPIを決める

試験導入の役目は中心となるリスクを確かめることで、画面を全部そろえる必要はありません。入力の経路を1つか2つ、主な出力を1種類、システム連携は必要な分だけに絞ります。利用者の人数とテストする件数も明記します。ベンダーには、調査（Discovery）、試験導入（Pilot）、本番運用（Production）、保守（Maintenance）の価格を分けて出してもらい、どこまで約束するのかを段階ごとに確認できるようにします。

5. AI開発会社に聞くべき15の質問

1. 私たちの事業の課題とKPIを、御社の言葉で説明していただけますか？
2. どの部分にAIを使い、どの部分に通常の自動化を使うべきですか？その理由は何ですか？
3. 実データで正確さをどう測りますか？正解データは誰が決めますか？
4. 情報が欠けている場合、指示が食い違う場合、範囲外のケースを、システムはどう扱いますか？
5. どのモデルとどの提供元を使いますか？私たちのデータは学習に使われますか？
6. データはどの国や地域に送られますか？どう暗号化され、どれくらいの期間保存されますか？
7. エージェントやシステムの権限はどう制限されていますか？人による承認はどこに入りますか？
8. プロンプトインジェクション、データ漏えい、同じ処理の重複実行をどう防ぎますか？
9. ログ、監視、予算アラート、インシデント対応として、どんな仕組みがありますか？
10. モデルのAPIや連携元のシステムが止まったら、業務をどう継続しますか？
11. 件数が少ない場合、中程度の場合、多い場合で、1件あたりと月あたりのコストはいくらですか？
12. ソースコード、プロンプト、ワークフロー、データ、出力結果の所有者は誰ですか？
13. モデルの変更、ホスティングの移転、ベンダーの変更は、どれくらい難しいですか？
14. 納品後、SLA、セキュリティパッチ、評価は誰が担当し、費用はいくらですか？
15. 似たような本番システムの事例と、うまくいかなかったプロジェクトからの教訓を見せていただけますか？

見るべきなのは、答えの自信より中身です。よいベンダーは、まだわからないことを認め、評価のためにデータを求め、リスクを下げるための試験を提案します。データを見る前から高い精度を保証する営業担当者や、AIがすべて自分で学習すると言う相手は、もっと詳しく確認する必要があります。

6. 「AI」という言葉の下にある、提案書の本当の中身を読む

7. 契約と所有権で押さえるべきこと

8. 早く、しかもリスクを抑えた選定の進め方

1. 3社に絞る：似た分野での経験、システム連携の力、自社の事業への理解を見ます。
2. 全社に同じ説明をする：データ、範囲、KPIは同じものを渡します。質疑応答の場を設け、重要な回答はすべてのベンダーに等しく共有します。
3. 検討ワークショップ：ベンダーの実際のチームに、業務プロセスと例外を一緒に分析してもらいます。営業用のスライドより、考え方を見てください。
4. 有償の調査・試験導入：複雑な課題では、保護したデータを使ってリスクのある部分を実証してもらい、その費用を払います。表面的な無料デモで済ませようとしないでください。
5. リファレンスチェック：既存の顧客に、本番稼働後の状況、実際にかかった費用、インシデントへの対応、ノウハウの引き継ぎについて聞きます。
6. スコアカード：事業との適合性、技術力、セキュリティ、チーム、コスト、乗り換えやすさ（Exitability）を採点します。重みづけは価格を開ける前に決めておきます。

この重みづけは一例にすぎません。規制を受ける業種なら、セキュリティとコンプライアンスの比重を上げるべきです。実際にシステムを使う現場の人を、選定から外さないでください。安くても使いにくいシステムは、システムの外で回る非公式な手順（Shadow Process）を生み、実際には人員を減らせません。

9. 作業開始から30日で見えているべきもの

毎週、短い意思決定の会議を開きます。デモ、指標、リスク、決定事項を分けて扱い、活動報告に時間の大半を使わないようにします。データやルールの面で作業が止まっている問題は、経営者がすぐに解決しなければなりません。自社のチームがサンプルやフィードバックを期限までに出さなければ、ベンダーが技術でその穴を埋めることはできません。

仕事の変化に向けた計画は、最初の月から始めます。新しいSOP、確認する人、代替のシステム、価値を回収する方法を決めておきます。たとえば、残業をやめる、新しいポジションを補充しない、といった方法です。システムが完成してから人の話を始めると、会社にはAIシステムが1つ増えるだけで、古い手順とコストはそのまま残ります。

まとめ：AI開発会社選びは、発注する側の準備から始まります。課題とKPIを書き出し、実データを用意し、試験導入の範囲を決め、ミス、権限、コスト、移行計画について質問してから、契約を成果に結びつけます。ふさわしい開発会社は、デモを早く作るだけで終わらず、実際に動き、効果を測れ、安全で、自社で保守を続けられるシステムを手に入れる手助けをしてくれます。