この記事で分かること
- AIシステム開発会社を選ぶ前に整理しておきたい業務・目標・データ
- 発注前に確認すべき10項目と、提案内容を見極める質問
- PoCから本番運用へ進む判断基準と、見積もりの比較方法
- 開発会社への相談を具体化するための準備と進め方
AI開発会社を探す前に、自社の課題を整理する
最初に決めたいのは、導入するAIの種類ではなく、誰のどの作業をどう変えたいかです。「生成AIを使いたい」という相談だけでは、問い合わせ対応、文書検索、入力補助、予測など、提案の対象が広がります。各社が別の前提で見積もると、価格も開発範囲も比較できなくなります。
例えば、営業担当者が過去の提案書を探す業務なら、「必要な資料を見つけるまでの時間を短くしたい」「閲覧権限のある資料だけを対象にしたい」「最終的な提案内容は担当者が確認する」と整理します。これは検討用の例ですが、目的と利用条件を分けることで、検索機能だけで足りるのか、AIによる要約や回答生成も必要なのかを話し合いやすくなります。
相談前の資料は、完成した仕様書でなくても構いません。現行の業務フロー、困っている場面、利用人数、対象資料の種類、希望時期を一枚にまとめるところから始めましょう。数値が分からない項目は推測で埋めず、調べる担当者と確認時期を決めます。開発会社が不足情報を整理する姿勢も、選定時の判断材料になります。
目標は「AIの精度」と「業務の成果」を分ける
AIの回答が適切でも、確認作業が増えて現場の負担が変わらないことは考えられます。回答の正確さだけでなく、確認にかかる時間、手直しの回数、利用者が処理を完了できた割合なども評価対象にしましょう。導入前の作業時間や処理件数を記録しておけば、導入後に何が改善したかを比較できます。
一方で、金額や契約条件を扱う業務などでは、平均的な正答率だけを見て判断しないことが重要です。見逃せない誤りは何か、どの出力を人が承認するか、判断できないときにどう扱うかを先に整理します。目標を一つの数値に集約しすぎず、業務ごとの合格条件を相談できる会社を選びましょう。
AIシステム開発会社の選び方｜確認すべき10項目
1. 自社に近い業務の開発経験を説明できるか
導入企業の知名度や実績件数に加えて、対象業務、利用者、扱ったデータ、開発会社が担当した範囲を確認します。同じ業界の実績がなくても、承認フローや帳票処理、社内検索など、似た業務構造を理解していれば検討候補になります。反対に、AIのデモ制作と、日常業務で使うシステムの構築では必要な対応範囲が異なります。
商談では「似た課題に対して、何を作り、運用でどのような点に対応しましたか」と尋ねてみてください。守秘義務で顧客名を出せない場合も、匿名化した課題や担当範囲の説明は比較材料になります。実績紹介の成果が、測定結果なのか想定効果なのかも区別して確認しましょう。
2. AIを使う部分と通常のシステムで処理する部分を切り分けるか
すべての処理をAIに任せる必要はありません。定められた条件による振り分け、必須項目の確認、集計などは、通常のプログラムや既存機能で実装する案も比較できます。そのうえで、文章の要約や自由記述の整理など、AIを使う価値がある部分を検討します。
「AIを使わない案と比べて、何が改善しますか」と質問すると、提案の根拠を確かめやすくなります。入力、処理、出力を図にしてもらい、AIが担当する範囲と人が確認する範囲を確認しましょう。特定の技術を採用することが先に決まり、業務の要件が後回しになっていないかを見ることが大切です。
3. 要件定義と利用画面を業務に沿って考えられるか
AIの応答が良くても、利用者が必要な資料を毎回手作業で用意したり、結果を別画面へ転記したりする設計では、期待した効率化につながらない可能性があります。誰が、どの画面から、何を入力し、結果をどこへ戻すのかまで検討する必要があります。
候補会社には、通常の操作だけでなく、入力不足、処理待ち、やり直し、承認待ちといった場面も説明してもらいましょう。画面の簡単な試作を現場担当者が確認できる進め方なら、文章の仕様書だけでは気づけない問題を見つけやすくなります。要件の決定者と現場の確認者を分けておくことも有効です。
4. AIモデルや開発方式の選定理由が明確か
提案にモデル名が並んでいても、それだけでは自社への適合性は分かりません。候補の違いを、回答品質、処理時間、費用、利用条件、運用のしやすさという業務上の観点で説明できるかを確認します。同じ資料と質問で比較する計画があるかも重要です。
ノーコード・ローコードのツールを使う場合は、早く検証できる範囲と、画面・権限・外部連携などの制約を確認します。個別開発の場合は、自由度に加えて保守対象が増える点も見積もりに含めます。「この方式が合わなかった場合の代替案は何ですか」と尋ね、変更時にどこまで作り直す必要があるかを把握しましょう。
5. Excel・Accessや既存システムとの連携を調査するか
社内の情報がExcel、Access、販売管理システム、共有フォルダなどに分かれている場合、AIの処理だけでなく、データを集めて更新する仕組みが必要です。API連携、ファイル取り込み、データベース参照などの方式は、既存環境の制約を確認したうえで決めます。
確認したいのは、接続できるかどうかだけではありません。更新頻度、重複登録の防止、失敗時の再実行、手動で補正する方法、元のデータとの対応関係まで質問します。「AIの回答画面は作るが、データの受け渡しは発注側で行う」という分担なら、その作業量を含めて判断する必要があります。
6. データの状態と評価方法を開発前に確認するか
対象資料に古い版が混在していたり、部署によって用語が異なったりすると、期待する結果を定義すること自体が難しくなります。データの量だけでなく、形式、欠損、更新日、管理者、利用してよい範囲を確認する会社かを見ましょう。整理作業を誰が担当し、その工数をどこへ含めるかも明確にします。
評価では、調整に使った例だけでなく、別に用意した確認用の例も使う計画を求めます。よくある質問、表記ゆれ、情報が不足した質問、答えてはいけない質問などを含め、期待する対応を整理します。「精度が高い」という説明には、何を何件評価し、どの基準で判定したかを添えてもらいましょう。
7. 情報の取り扱いと権限管理を具体的に説明するか
社内資料を扱う場合は、送信先、保存先、保存期間、ログに残す内容、閲覧できる人を確認します。利用する外部サービスの条件や設定によって取り扱いが変わるため、「企業向けだから大丈夫」という説明で判断せず、今回の構成に即した回答を求めましょう。
例えば、元の文書に部署ごとの閲覧制限があるなら、検索結果やAIの回答からも権限外の内容が見えないかを評価項目にします。退職・異動時のアカウント管理や、障害調査でログを見る担当者も決めます。必要に応じて社内の情報管理担当者を商談に参加させ、運用上の要求を早い段階で共有してください。
8. PoCの合格条件と終了後の判断を決められるか
PoCは、本格開発へ進む前に実現性や業務への適合を確かめる検証です。動く画面を作るだけで終わらせず、何を確かめ、どの結果なら次へ進むのかを決めておきます。検証対象を絞るほど、期待と結果の差を具体的に把握できます。
契約前には、対象業務、使用データ、評価担当者、期間、成果物、合格条件を確認します。不合格だった場合も、追加検証、方式変更、計画の中止などの選択肢を整理しましょう。本番化に必要な権限管理、監視、バックアップ、利用者教育がPoCに含まれているかは別途確認が必要です。
9. 初期費用と運用費用、変更条件を分けて提示するか
見積金額を比較するときは、調査、要件定義、データ整備、開発、テスト、移行、教育がそれぞれ含まれているかを揃えます。保守費用に加えて、外部サービスの利用料、保存容量、検索やAI処理の利用量に応じた費用も、前提条件付きで示してもらいましょう。
利用人数だけでは費用を見積もれない場合があります。一人あたりの利用回数、処理する文書の長さ、同時利用、更新頻度などを仮定し、通常時と利用が増えた場合を比較します。追加機能や対象資料の増加が発生したとき、どの時点で再見積もりになるかも確認しておくと、社内説明がしやすくなります。
10. 担当体制と導入後の改善方法が明確か
商談の説明担当者と、実際の要件定義・開発・保守担当者が同じとは限りません。窓口、役割分担、定例会の頻度、質問への回答方法、課題の管理方法を確認しましょう。判断が必要な事項を誰が決めるかまで共有できると、待ち時間や認識のずれを抑えやすくなります。
運用開始後は、資料の更新や利用者からの指摘を受けて、検索対象や設定、画面を見直す場面が出てきます。問い合わせ窓口だけでなく、品質の確認、改善提案、変更後の再評価まで対応範囲を確認してください。ソースコード、設定、設計資料、データを引き継ぐ条件も、将来の運用体制を考えるうえで大切です。
商談で使えるAI開発会社の比較チェック表
次の表を使い、各社の回答と根拠資料を同じ欄で比較しましょう。「対応可能」という回答だけで評価せず、提案書、作業分担表、評価計画、見積もりのどこで確認できるかを記録します。自社にとって必須の条件は、合計点とは別に合否を判断してください。
| 確認項目 | 商談での質問 | 確認したい根拠 |
|---|---|---|
| 1. 業務経験 | 似た業務でどこまで担当しましたか | 課題・担当範囲・運用上の対応 |
| 2. AIの適用範囲 | AIを使わない案と何が違いますか | 処理の分担と代替案 |
| 3. 要件・画面設計 | 現場はいつ操作を確認できますか | 業務フロー・画面案・確認日程 |
| 4. 方式選定 | そのモデルやツールを選ぶ理由は何ですか | 比較条件・制約・変更時の影響 |
| 5. 既存連携 | データ更新が失敗したらどう復旧しますか | 連携方式・再実行・担当分担 |
| 6. データ・評価 | 何を使って合格と判断しますか | データ調査・評価例・判定基準 |
| 7. 情報管理 | 誰がどの情報を見られますか | データ経路・権限・ログの設計 |
| 8. PoC | 検証後に何を判断しますか | 対象範囲・終了条件・成果物 |
| 9. 費用 | 利用が増えると何の費用が変わりますか | 利用量の前提・運用費・変更条件 |
| 10. 体制・保守 | 導入後の品質改善は誰が担当しますか | 体制表・保守範囲・引き継ぎ条件 |
比較時には「確認済み」「追加確認が必要」「要件を満たさない」のように状態を分けると、単純な点数より次の行動が明確になります。例えば、費用が低くても必要な権限管理が対象外なら、追加費用と実装可否を確認するまで結論を出さないようにします。未回答の項目は、期限を決めて書面で確認しましょう。
社内検索やAIによる業務実行では、追加の確認をする
社内文書を参照する仕組みは、情報源の管理まで確認する
社内資料を検索し、その情報を参照して回答を作る構成を検討するなら、回答の文章だけでなく、参照元の表示や更新の扱いを確認してください。利用者が根拠を見られるか、古い版や削除済みの資料が残らないか、情報が見つからないときに回答を控えられるかを、具体的な操作で確かめます。
部署ごとに同じ用語の意味が異なる場合や、資料同士に矛盾がある場合の対応も検証対象です。資料を追加すれば自動的に望む結果になると考えず、情報の整理方法と更新担当者を決めましょう。検索結果と回答の両方を確認できる検証計画にすると、問題が資料側にあるのか処理側にあるのかを切り分けやすくなります。
外部システムを更新する場合は、承認と復旧を確認する
AIの提案を表示する機能と、メール送信やデータ登録まで実行する機能では、確認すべき範囲が変わります。実行を伴う案では、操作できる対象を限定し、実行前の内容確認、承認、履歴の保存、失敗時の扱いを要件に含めます。
例えば、取引先への返信案を作る段階と、実際に送信する段階を分けて検討できます。自動化の範囲を広げるときは、二重実行や誤操作を想定したテストを追加しましょう。開発会社には、便利なデモだけでなく、処理を止める方法や担当者へ引き継ぐ流れも説明してもらってください。
見積もりを比較するときに避けたい3つの進め方
初期費用の安さだけで決める
初期費用が低いこと自体は問題ではありません。ただし、データ整備や現場確認、本番化が別途費用なら、契約後に必要な金額が増えます。まず各社に同じ業務範囲を伝え、対象外の作業を明記してもらいましょう。見積もりの総額とともに、発注側が担当する作業時間も比較することが大切です。
PoCの成功を、そのまま本番導入の成功と考える
限定した資料や少人数で確認できた結果が、実際の全業務でも成立するかは別に検証します。本番では利用者の質問の幅、同時利用、例外処理、資料の更新などが変わるためです。PoCの結果を受けて本番要件を見直す工程と、段階的に利用者を増やす計画を用意しましょう。
運用を「納品後に考える」とする
誰も資料を更新せず、改善要望の窓口も決まっていなければ、導入した仕組みを維持しにくくなります。発注側にも、業務の責任者、データの管理者、問い合わせをまとめる担当者が必要です。開発会社へ任せる範囲と社内で行う範囲を決め、運用に使える時間と費用をあらかじめ確保します。
初回相談から本番運用までの進め方
進め方は対象業務によって変わりますが、まず課題と現状を整理し、必要なデータや連携条件を調査します。その後、検証する範囲と評価基準を決め、PoCや画面の試作で不確かな点を確かめます。結果を踏まえて本番の要件・費用・日程を具体化し、開発、テスト、利用者への説明、段階的な運用へ進みます。
各段階の終わりには、次へ進む判断材料を残しましょう。例えば、調査後ならデータの利用可否と不足事項、PoC後なら評価結果と残った課題、本番テスト後なら運用担当者と復旧手順です。予定日だけで工程を進めず、何が確認できたかを発注側と開発側で共有することが重要です。
相談時に用意しておくとよい情報
- 対象業務と現行の手順、困っている場面
- 利用者、処理件数、作業時間など把握できている現状
- 資料の種類、形式、保存場所、更新担当者
- 連携したいExcel・Access・業務システムの概要
- 必須条件、希望時期、予算の考え方、社内の判断体制
機密資料を初回から一式渡す必要はありません。まず構成や項目を説明し、必要に応じて共有範囲を決めたサンプルを用意します。何を確認するためにそのデータが必要なのかを開発会社へ尋ねれば、調査の目的を共有できます。未整理の情報がある場合も、その状態を伝えて整理方法から相談しましょう。
AIシステム開発会社の選定に関するFAQ
AIの専門知識がなくても開発会社に相談できますか？
はい。最初は技術名よりも、現状の業務と困りごとを説明することが重要です。対象業務、利用者、資料の種類、改善したい点を整理して伝えましょう。専門用語を業務上の意味に置き換えて説明し、複数の方法を比較できる会社かを確認すると判断しやすくなります。
AI開発を依頼する前に、仕様書を完成させる必要がありますか？
完成した仕様書がなくても相談は可能です。ただし、要件を整理する作業が見積もりに含まれるか、発注側が何を準備するかは確認してください。課題の一覧や簡単な業務フローがあれば、必要な調査と検証を具体化しやすくなります。
PoCは必ず実施するべきですか？
一律に必要とは限りません。今回のデータで期待する結果が出るか、業務に適した操作になるかなど、不確かな点が大きい場合に検証を検討します。何を確かめるためのPoCかを明確にし、終了後の判断につながる成果物を決めることが大切です。
既存のExcelやAccessを残したままAIを導入できますか？
既存の仕組みを活かす構成は検討できますが、実際の連携可否はファイル構成、利用環境、更新方法、権限などの調査が必要です。全面的な置き換えだけでなく、データの取り込みや特定業務の補助から始める案も比較しましょう。
開発費用や期間の目安は、最初の相談で分かりますか？
概算を出せる場合もありますが、対象範囲やデータの状態、連携先によって変わります。概算の前提と対象外の作業を確認し、調査後にどの情報が揃えば正式な見積もりになるかを聞きましょう。初期費用と継続費用を分けて把握することも必要です。
複数の会社から提案を受ける場合、何を揃えるべきですか？
対象業務、必須条件、利用規模、共有するサンプル、評価基準を揃えます。そのうえで、作業範囲、発注側の負担、運用費用、保守範囲を比較します。不明点の多い提案は金額だけで決めず、追加回答を受けてから判断してください。
マクティズムにAIシステム開発を相談する
マクティズムのAIシステム開発サービスでは、業務課題の整理から開発、既存のExcel・Access等との連携、導入後の運用・改善までを相談対象としています。社内ナレッジの検索や文書の要約・分類、回答案の作成など、業務に合わせた活用を検討できます。具体的な対応範囲は、自社の資料や利用環境を共有したうえで確認してください。
「何をAIに任せるべきか分からない」という段階では、まず負担の大きい業務と、その前後の作業を伝えてみましょう。実現したいこと、現状の制約、導入後に社内で運用できる範囲を整理すると、必要な調査や小さく試す対象が明確になります。
まとめ｜技術・業務・運用を同じ基準で比較する
AIシステム開発会社を選ぶ際は、業務経験、AIの適用範囲、要件定義、方式選定、既存連携、データと評価、情報管理、PoC、費用、担当体制の10項目を確認しましょう。技術の説明とともに、自社の業務で何を確かめ、誰がどの作業を担当するかを具体化することが大切です。
最初の一歩は、改善したい業務を一つ選び、現状と望む状態を書き出すことです。その情報を同じ条件で候補会社へ伝え、未確認事項と判断の根拠を比較してください。開発前の検証から運用後の改善まで話し合える相手を選ぶことが、継続して使える仕組みづくりにつながります。
