この記事で分かること
- AIシステム会社へ相談する前に整理する課題とデータ
- 費用・期間の見積もりで確認する作業範囲と前提
- PoCから本番導入までの発注と評価の進め方
- 失敗例から学ぶ契約、運用、社内体制の注意点
AIシステム会社へ頼む前に課題を一つに絞る
最初に「何を作るか」ではなく、「どの業務をどう改善したいか」を書きます。社内文書を探す時間を減らしたい、問い合わせの回答案を作りたい、Excelの集計を補助したいなど、担当者が困っている作業を一つ選びます。利用者が入力し、AIが結果を返し、人が確認して業務を完了するまでの流れを説明してください。
件数、所要時間、担当人数、発生頻度を記録すると、効果を見積もりやすくなります。AIが下書きを作っても確認時間が残る場合があるため、削減時間は作業全体から測ります。削減できる時間と実際に減る支出を分けると、稟議や効果測定で誤解が生じにくくなります。
| 相談前の情報 | 具体例 | 提案に影響する理由 |
|---|---|---|
| 業務 | 受付、検索、分類、承認、通知 | AIを入れる工程が分かる |
| 利用者 | 部署、役割、人数、端末 | 画面と権限を決められる |
| データ | Excel、PDF、CSV、DB、メール | 取り込みや連携を検討できる |
| 成果 | 時間、件数、品質、利用率 | PoCの合格条件を作れる |
| 制約 | 予算、時期、社内規程、外部送信 | 方式と範囲を調整できる |
費用の見積もりで見るべき項目
AIシステムの費用は、モデルの利用料だけで決まりません。課題整理、要件定義、データ整備、画面、認証、権限、既存システムとの連携、テスト、移行、教育、保守を分けて確認します。見積書の「AI機能」や「開発一式」に何が含まれるのかを質問してください。
初期費用と稼働後の費用を分けます。AI API、クラウド、データベース、保存領域、監視、バックアップ、問い合わせ対応が月額か従量かを確認します。利用者数だけでなく、利用回数、処理する文字量、再実行、データ更新の頻度も費用へ影響します。
安い見積もりを単純に選ばない
金額が低く見える提案でも、発注側がデータ整理、テスト、教育、連携先との調整を担当するなら、社内工数を加えて比較します。反対に、価格が高い提案でも、要件定義や運用まで含んでいる可能性があります。同じ業務範囲、データ量、利用者、運用期間へそろえることが大切です。
未確定の事項を無理に固定せず、いつ調査して、何が決まれば再見積もりできるかを残します。追加料金の基準、仕様変更の手続き、納期変更、検収条件を契約前に確認します。
期間は開発作業だけでなく社内確認を含める
AI開発の期間を考えるとき、開発会社の作業時間だけを見ると遅延しやすくなります。発注側が資料を集める期間、業務担当者が回答を評価する期間、情報システムが権限や接続を確認する期間、経営者が判断する期間を工程表に入れます。
| 段階 | 主な作業 | 遅れやすい要因 |
|---|---|---|
| 課題整理 | 目的、業務、利用者、成果の整理 | 関係者の合意がない |
| データ確認 | 所在、形式、権限、サンプルの確認 | 資料管理者が不明 |
| PoC | 試作、評価、改善、報告 | 評価者と合格条件がない |
| 本開発 | 画面、連携、権限、ログの実装 | 仕様変更が続く |
| 導入 | 移行、教育、利用開始、運用確認 | 現場の試用時間がない |
希望時期がある場合は、リリース日だけでなく、評価の締め切り、データ準備、社内承認の日付を逆算します。繁忙期や担当者の不在期間も共有してください。期間を短くする場合は、対象業務やデータを限定し、テストや権限設計を無条件に省かないようにします。
失敗例1：AI導入が目的になる
技術の導入自体を目的にすると、完成後に誰が使うのかが曖昧になります。相談前に、どの担当者が、どの作業を、どれだけ短縮したいのかを決めます。マクティズムのAI開発サービスでも、AIありきではなく、業務の流れや利用者を踏まえて活用方法を提案する考え方が示されています。
失敗例2：データを渡せば終わると考える
資料が存在しても、古い版、重複、欠損、画像化された文字、部署ごとの閲覧制限があると、そのままでは使えません。代表資料だけでなく、処理しにくい資料を見てもらい、どこまで発注側が整理し、どこから会社へ依頼するかを決めます。
失敗例3：PoCの成功条件がない
「AIが回答できた」でPoCを終えると、本番へ進む判断ができません。回答の正しさ、根拠、修正時間、待ち時間、利用費、権限、現場の利用意向を確認します。合格しなかった場合に、追加検証、対象変更、方式変更、中止のどれを選ぶかも決めます。
失敗例4：導入後の担当者がいない
リリース後は文書の更新、回答の評価、利用者からの要望、障害の連絡が発生します。保守会社へ連絡する人、データを更新する人、業務上の合否を決める人を分けます。保守契約に含まれる時間、対応方法、改善費用、契約終了時の引き継ぎも確認します。
発注前に用意する質問と資料
- 現行業務の流れと困っている作業
- 利用者、権限、利用端末、利用頻度
- データの場所、形式、件数、更新者、サンプル
- 期待する成果と測定できる指標
- 既存のExcel、Access、CRM、販売管理などとの連携
- 希望時期、予算上限、社内の承認手順
- 個人情報、営業秘密、外部サービス利用の制約
機密情報をそのまま渡せない場合は、匿名化したデータを用意します。匿名化によって失われる特徴があるなら説明し、実データで確認する範囲と方法を協議します。
発注方式と契約条件を比較する
AI開発には、調査や要件整理を先に行う方式、一定の範囲を決めて一括で開発する方式、時間や作業量に応じて進める方式があります。どれが適切かは、要件の確定度、データの状態、社内の確認体制、希望時期で変わります。契約形式の名前だけで判断せず、変更が起きたときの手続きと責任を確認します。
要件が未確定なら、最初の契約を調査や要件定義に限定し、成果物を見て次の発注を決める方法があります。全体を一括契約する場合も、工程ごとの検収条件と支払い時期を分けると、問題を早く発見できます。PoCの結果を本番開発へ引き継ぐ条件や、利用できなかった成果物の扱いも書面にします。
| 確認する契約条件 | 質問の例 | 残す内容 |
|---|---|---|
| 作業範囲 | データ、連携、テストは含むか | 対象と対象外の一覧 |
| 変更 | 追加要望をどう扱うか | 再見積もりと承認手順 |
| 知的財産 | コードや設定を誰が管理するか | 利用権、納品物、引き継ぎ |
| 保守 | 障害と改善の境界はどこか | 受付時間、料金、対応目標 |
| 終了 | 契約終了時に何を返すか | データ、アカウント、資料の返却 |
知的財産とアカウントを確認する
開発会社へ依頼する場合、ソースコード、設計書、プロンプト、評価データ、クラウドアカウント、AI API契約の管理主体を確認します。会社側の環境だけで稼働すると、将来の保守会社変更や内製化が難しくなる可能性があります。秘密情報や第三者サービスの利用条件も契約に沿って整理します。
検収の条件を業務で書く
検収を「画面が表示された」とだけ書くと、AIの品質や業務への適合を確認できません。指定したテストケースで結果が出る、根拠が表示される、権限外の情報を見られない、エラー時に再処理できるなど、業務で確認できる条件を置きます。発注側の評価者が確認する期間も工程表に入れます。
社内の推進体制を整える
AI開発は情報システムだけで決めると、現場の業務ルールが抜けることがあります。業務責任者、データ管理者、システム担当、セキュリティ確認者、予算承認者を決め、意思決定を一人に集中させない体制を作ります。会議で決めたこと、未決のこと、次回までの担当を記録します。
利用者の試用時間を確保することも必要です。実務で使う人が触れなければ、使いにくい画面や確認負担の大きさが分かりません。試用で出た意見をすべて機能追加にするのではなく、業務への影響、発生件数、費用、リスクで優先順位を付けます。
AIの出力を人が確認する場合、確認者の責任も明確にします。AIの回答を採用するか、修正するか、回答できない場合に担当部署へ回すかを決めます。顧客への送信、発注、契約判断などの処理は、承認を必須にする設計が適切なことがあります。
相談から契約までの進め方
- 業務課題と改善したい成果を一枚にまとめる
- 利用者、データ、既存システム、制約を確認する
- 同じ資料で複数社へ相談する
- 提案の範囲、費用、期間、成果物、対象外を比較する
- 不確かな点が多ければ調査やPoCから始める
- 検収条件、変更、保守、引き継ぎを契約へ書く
- 導入後の評価と改善担当を決める
初回相談で結論が出ないことは問題ではありません。相談後に、開発会社が追加で確認したい資料や質問を提示できるかを見ます。曖昧な部分を曖昧なまま説明し、次の調査へつなげる姿勢があると、現実的な計画を作りやすくなります。
提案を比較するときは、価格の差を作業の差へ置き換えます。データ整理を誰が行うか、評価に何件使うか、既存システムの調査が含まれるか、導入後に何回改善できるかを確認します。社内担当者の時間も含めて、同じ条件で総額を見ます。
判断を急がず、まず業務を限定して使い、結果を測ってから範囲を広げる方法もあります。対象を絞る場合は、将来の拡張に必要なデータ項目や権限を初期に共有し、後で作り直す範囲を把握しておきます。
この準備をしておけば、相談先から提案された方式が自社の条件に合うかを判断できます。AIを採用しない案が提示された場合も、目的に照らして評価できます。発注前の整理は、開発会社を選ぶためだけでなく、作る範囲を適切にするために行います。社内の決裁者へ説明しやすくなり、導入後の運用担当者も早く準備できます。関係者の認識をそろえた状態で、無理のない契約へ進められます。費用と責任を事前に確かめ、安心して開始できます。具体的な手順も確認しておきます。担当者間で共有し、漏れを防ぎます。確実に進めます。
AIシステム会社へ頼む前のFAQ
予算を先に伝えてよいですか？
伝えて構いません。初期開発、月額費用、社内工数のどこまでを含む上限かを分け、必須機能と後から追加する機能を相談します。
PoCから依頼するべきですか？
データの品質や方式が不確かな場合に有効です。要件が明確で小規模な改修で済む場合は、調査や本開発から始める方法もあります。
会社へどこまで資料を渡せばよいですか？
業務を理解できる範囲のサンプルを渡します。機密情報は匿名化し、保存場所、アクセス権、外部サービスへの送信範囲を確認してください。
短期間での導入は可能ですか？
対象業務、利用者、データを限定すれば短縮できる場合があります。ただし、必要な権限、業務テスト、障害時の対応を省略しないことが重要です。
開発後の保守も同じ会社へ頼むべきですか？
社内体制と技術の引き継ぎ状況で決めます。保守範囲、対応時間、改善費用、設定やデータの引き渡し条件を比較してください。
AIシステム会社への相談を始める
マクティズムのAI開発サービスでは、仕様が決まっていない相談から、要件整理、設計・開発、既存のExcelや業務システムとの連携、導入後の改善・保守までを検討できます。現在の業務やデータの状況を共有し、AIを使う範囲と別の方法がよい範囲を整理します。
相談前に完璧な提案書を作る必要はありません。困っている作業、件数、利用者、資料、希望時期を共有し、最初に調べる項目と小さな検証の範囲を決めてください。
まとめ｜費用・期間・失敗条件を先に整理する
AIシステム会社へ頼む前は、業務課題、利用者、データ、成果、制約を整理します。費用は開発費だけでなく、データ整備、連携、テスト、導入、APIやクラウド、保守まで分け、期間には発注側の準備と確認を含めます。
PoCの合格条件と導入後の担当者を決めておけば、AIを入れることだけが目的になる失敗や、リリース後に使われない問題を避けやすくなります。未確定な部分は調査項目として残し、必要な範囲から開発会社へ相談しましょう。
