この記事で分かること
- AIを導入しても使われなくなる原因を、発注先選定の観点から切り分ける方法
- 業務観察、画面設計、既存システム連携を提案書で確認する質問
- 研修だけに頼らず、利用開始から習慣化まで支える教育・運用設計の見方
- 利用率や完了率など、導入後に改善判断へつなげられる指標の設計
- 候補会社を同じ条件で比較し、契約前に責任範囲を明確にするチェック方法
「使われない」は技術より発注設計で起こる
AIシステムが使われないとき、現場の意欲やITリテラシーだけが原因とは限りません。発注時点で「何を自動化するか」だけを決め、「誰が、どの画面で、どのタイミングに、何を判断するか」を決めないまま開発を始めると、完成品が既存の仕事から浮いてしまいます。担当者は別画面へ移動して結果をコピーし、元の台帳へ戻って確認することになります。数十秒の追加作業でも、繁忙時間に何度も発生すれば従来の手順へ戻る十分な理由になります。
もう一つの典型は、PoCの成功を本番利用の成功と取り違えることです。限られたデータを使った検証で高い精度が出ても、現場には例外処理、入力漏れ、権限の違い、担当者の交代があります。こうした条件を本番設計へ移す役割を誰が担うのかが提案書に書かれていなければ、発注者側に見えない作業が残ります。会社選びでは「AIを作れるか」から一歩進み、「現場で使い続ける状態を設計し、その結果を測って改善できるか」を確認しなければなりません。
候補会社の比較表に、モデル名、対応言語、開発人数、納期だけを並べるのは危険です。業務理解の進め方、画面の試作回数、連携対象の洗い出し、利用開始後の問い合わせ窓口、改善の判断基準も同じ重さで比較してください。AI開発のサービス内容を確認する場合も、機能一覧だけでなく、業務への組み込み方まで説明しているかを AIシステム開発の案内で確認すると、面談で聞くべき論点を整理しやすくなります。
見極めの第一歩は業務観察を提案しているか
現場定着を重視する会社は、いきなり要件一覧を求めるのではなく、実際の業務を理解するための調査方法を提示します。ヒアリングだけでは、担当者が無意識に行う確認や、忙しいときだけ発生する例外を拾えません。実務画面を見ながら、入力前後の判断、紙や表計算ソフトとの行き来、承認者が確認する箇所、差し戻しの理由まで観察する計画があるかを聞きましょう。
業務観察で確認してほしいのは、単なる作業手順ではありません。誰が最初に情報を受け取り、どの条件でAIの結果を信頼し、どのケースで人が修正し、最終的にどの記録を残すのかという責任の流れです。AIの提案を採用しなかった場合にも説明が必要な業務なら、修正理由や判断者を残す欄が必要です。反対に、参考情報として見るだけの業務なら、過剰な承認画面は利用を妨げます。会社がこの違いを観察項目に含めているか確認してください。
面談で確認したい質問
- 現場観察は何時間、何職種、何拠点を対象にし、成果物として何を提出するか
- 通常処理だけでなく、入力漏れ、急ぎの依頼、差し戻し、担当者不在をどう調査するか
- 業務フロー図と画面一覧のどちらを先に作り、誰の合意を取って更新するか
- 観察で見つかった「やらない作業」や二重入力を、要件から外す判断基準は何か
回答が「担当者からヒアリングして要件定義書にまとめます」だけで終わる場合は、観察の深さを追加で確認しましょう。作業記録、画面遷移、例外一覧、利用者の役割表など、後の設計判断へつながる成果物のサンプルを見せてもらうと、会社ごとの差が分かります。業務の整理を先に行いたい場合は、要件定義・業務整理の相談を使い、AIの方式を決める前に現状の論点を言語化する方法もあります。
UIと既存システム連携を一つの提案にできるか
AIの回答が正しくても、利用者が別のツールを開き、結果を転記し、根拠を探す設計では定着しません。候補会社には、AIを単独のチャット画面として提供するのか、現在使っている業務システムの画面へ組み込むのか、判断材料を示してもらいましょう。導入初期は専用画面でも、利用が定着した段階で既存画面へ埋め込むなど、段階的な案を比較できる会社は、使う場面を具体的に考えています。
UIの提案では、きれいなモックアップの見た目だけを評価しないことが大切です。結果が表示されるまでの待ち時間、処理中に別作業ができるか、回答の根拠や参照日時が分かるか、誤りを修正して再実行できるか、利用者が困ったときに戻れるかを確認します。AIの提案を採用するボタンと、保留・修正するボタンが同じ画面にあるだけでも、現場の心理的な負担は変わります。利用者の判断を奪わず、判断を早くする設計かどうかを見てください。
連携の検討では、APIの有無だけでなく、データの所有者、同期頻度、エラー時の再送、権限、監査ログ、個人情報の扱いを確認します。既存システムのデータをAIへ渡すとき、項目名が同じでも意味や更新タイミングが異なることがあります。連携会社がデータマッピング表を作り、サンプルデータで検証し、失敗時に元の処理を止めない設計まで提案できるかが重要です。
画面と連携の提案を比較する表
| 確認項目 | 具体的に聞くこと | 見極めのポイント |
|---|---|---|
| 利用場所 | 利用者は今どの画面にいて、AI結果をどこへ返すのか | 新しい画面を増やす理由と既存画面へ組み込む条件が説明されている |
| 判断と修正 | 採用、修正、保留、却下をどう記録するのか | 人の最終判断と、後から追える履歴が設計されている |
| 連携障害 | API停止やデータ不整合が起きたときの業務手順は何か | 手作業の代替、通知、再送、復旧確認の担当者が決まっている |
| アクセス管理 | 職種・拠点・役職ごとに何を見せるのか | AIの回答だけでなく、元データの権限も含めて考えている |
既存の仕組みを残すか、段階的に置き換えるかで費用とリスクは変わります。診断の段階で現状を整理し、修正・保守・刷新の選択肢を比較するなら、開発前診断・ロードマップのように、開発着手前の判断材料まで扱うサービスかを確認してください。
教育を研修日だけで終わらせない会社を選ぶ
「操作説明会を一度開催します」という提案は必要条件ですが、十分条件ではありません。現場でつまずくのは、研修で扱わなかった例外が出たときや、数週間後に操作を忘れたときです。発注先には、導入前の役割別研修、試行期間の伴走、問い合わせの受付、初回利用の記録、追加説明の方法を一続きの計画として示してもらいましょう。
利用者を一括して「社員」と扱う会社には注意が必要です。入力する人、AI結果を承認する人、設定を変更する人、問い合わせを受ける管理者では、必要な知識も不安も異なります。役割ごとに、最初にできるべき操作、判断してはいけない範囲、困ったときの連絡先を定義し、短い手順書や画面内のヒントへ落とし込める会社が望ましいでしょう。研修資料のページ数ではなく、業務のどの瞬間に支援が表示されるかを確認します。
また、教育の成果を受講人数だけで測らないことも重要です。研修後に実際の業務で一度使ったか、結果を確認して完了まで進めたか、質問が同じ箇所に集中していないかを見る必要があります。候補会社が、利用者の声を収集し、画面改善や手順書の更新へ戻す仕組みを提案しているか確認してください。AIシステムの導入体制を比較する際は、内製か外注かを判断する記事で整理されているような、社内の担当者と開発会社の役割分担も質問に含めるとよいでしょう。
運用設計と責任分界を契約前に言葉にする
AIは運用を始めてからデータの傾向や利用者の質問が変わります。納品日に動けば終わりという開発会社では、使われない兆候が出ても改善の相談先が分かりません。契約前に、誰がモデルやプロンプトを更新するのか、学習・参照データを追加するのか、誤回答を報告するのか、障害時に業務をどう継続するのかを決めてください。
責任分界は、RACIのような表にすると曖昧さを減らせます。たとえば、発注者は業務ルールと最終承認を担い、開発会社はシステム障害の一次切り分けと改善案の提示を担う、といった具合です。AIの回答内容を最終決定する責任まで開発会社へ移せるとは限りません。会社ができることと、発注者・利用部門が判断することを分け、各作業に期限と成果物を設定しましょう。
運用提案に含めたい項目
- 問い合わせ、誤回答、情報漏えいの疑いを受ける窓口と初動時間
- モデル・プロンプト・参照データの変更申請、テスト、承認、履歴管理
- 利用ログを誰が見て、どの条件で改善会議を開くか
- 担当者の異動や退職があっても設定と判断基準を引き継げる資料
- 保守契約に含まれる範囲、追加費用になる作業、終了時のデータ返却方法
特に、障害対応と精度改善を同じ「保守」と書く見積書は詳しく読みます。サーバーが動くことと、現場の回答品質が保たれることは別の仕事です。要件の抜けを減らすには、AIシステム開発の要件定義に関する非公開記事も参照し、検収条件、利用者受け入れテスト、変更管理を別々に記載してもらうと安心です。
利用指標を提案できるかで本気度が分かる
「導入後も支援します」という言葉を具体化するのが利用指標です。単にログイン数を増やすだけでは、役に立たない画面を開いてすぐ閉じる行動も成功に見えてしまいます。業務の目的に応じて、利用開始、AI結果の確認、人による修正、最終処理の完了までを一つの流れとして定義しましょう。
指標は、先行指標と成果指標に分けると判断しやすくなります。先行指標は、対象業務で利用を開始した割合、週あたりの利用回数、推奨結果を確認した割合など、使い続ける兆候を示します。成果指標は、処理時間、差し戻し件数、入力漏れ、問い合わせの再発率など、業務がどう変わったかを示します。AIの出力を人が修正した割合も、精度の問題とは限りません。業務ルールが未反映なのか、画面が修正しづらいのかを聞き分けるために使います。
指標を決めるときの確認表
| 段階 | 指標の例 | 見るべき質問 |
|---|---|---|
| 到達 | 対象者の初回利用率、初回利用までの日数 | 対象者の定義と未利用者への支援方法は決まっているか |
| 継続 | 週次利用率、業務単位の再利用率 | 使わない理由をログとヒアリングで区別できるか |
| 完了 | AI結果の確認後に業務処理を完了した割合 | 途中で別ツールへ戻ったケースを把握できるか |
| 成果 | 処理時間、差し戻し、転記、問い合わせの変化 | 導入前の基準値と比較期間、他要因の影響を説明できるか |
優れた会社は、指標の取得方法と限界も説明します。ログに残らない紙の確認や口頭の相談があるなら、定期的な短時間インタビューやサンプル監査を組み合わせます。利用者を監視するための指標ではなく、困っている箇所を発見し、改善の優先順位を決めるための指標だと共有できるかも大切です。
利用率が低いときに、すぐ「研修を増やす」と結論づける会社は避けましょう。ボタンが業務画面から遠い、応答が遅い、権限で見えない、回答の根拠がなく承認できないなど、原因は複数あります。指標から仮説を立て、画面・連携・教育・業務ルールのどこを直すかを小さく試す改善サイクルを提案しているかを確認してください。
候補会社を比較する実務的な進め方
会社を選ぶときは、各社へ同じ資料と質問を渡し、回答を同じ採点軸で比較します。自社の課題を詳しく書きすぎると、会社ごとに違う前提で提案されるため、対象業務、利用者、既存システム、守るべきルール、期待する変化を一枚にまとめます。AIに任せたい判断と、人が必ず行う判断も明記してください。
提案依頼に入れるべき観点
- 業務観察の範囲、参加者、期間、成果物、追加調査が必要になる条件
- 画面の試作と利用者テストの回数、修正を見積もりへ含む範囲
- 既存システムとの連携方式、データ項目、エラー処理、権限と監査
- 研修、マニュアル、試行期間、問い合わせ窓口、利用開始後の伴走期間
- 利用指標、基準値の取り方、定例レビュー、改善を判断する条件
- 納品物、検収条件、保守、追加費用、データと設定の引き渡し
採点では、提案内容が自社の課題に合うかだけでなく、根拠があるかを見ます。担当予定者が面談で業務の例外を質問したか、画面やデータの前提を確認したか、できないことを明確にしたかを記録します。過去事例を聞く場合も、華やかな導入社名だけでなく、利用開始後に何を測り、どんな改善を行い、誰が運用を担ったかを聞いてください。
RFPを用意して比較項目を揃えたい場合は、AI受託開発会社の選定でRFPに入れる項目を扱った記事が参考になります。価格だけで判断せず、業務整理、UI試作、連携テスト、教育、運用支援の各工程にどれだけ時間を使う提案かを見れば、安さの理由や後から増える作業も見えやすくなります。
面談後は、候補会社へ同じ追加質問を返し、回答の速さではなく回答の具体性を比較します。「対応可能です」だけでなく、前提、方法、担当、成果物、リスク、追加費用を説明できるかがポイントです。会社選びの一般的な確認項目を広げたいときは、AIシステム開発会社の選び方を整理した記事も候補比較の補助線になります。
契約前に注意したい危険なサイン
最初の面談で「AIなら何でもできます」と断言し、現場の業務やデータについて質問しない会社は注意が必要です。できることを広く見せるより、前提条件や適用しないケースを説明する方が、導入後の期待値を合わせられます。無料のデモが自社の実データでなく、きれいなサンプルだけで進む場合も、入力のばらつきや例外をどう扱うかを確認してください。
見積書に「AI機能一式」「連携対応」「運用支援」とだけ書かれ、画面数、連携先、テスト条件、支援回数がない場合は、後から認識差が生じます。納期が極端に短いのに、業務観察、データ整理、受け入れテストの期間が見えない場合も同じです。価格が高いか安いかではなく、使われる状態へ至る作業が見積もりに含まれているかを確認しましょう。
契約条件のリスクを細かく確認する場合は、AI開発会社との契約前に確認したいリスクを扱った記事を参照し、再委託、知的財産、データ利用、障害時の責任、終了時の引き継ぎを質問してください。質問への回答を議事録へ残し、提案書や見積書の修正版に反映してから契約へ進むことが大切です。
導入後の90日を提案できる会社か
発注先の見極めは契約時で終わりません。提案段階で、導入後の最初の90日をどのように進めるか聞いてみましょう。最初の30日は対象者を限定して操作と連携を確認し、次の30日は利用ログとヒアリングからつまずきを直し、その後の30日で対象業務や拠点を広げる、といった段階案があれば、利用開始後の不確実さを織り込んでいます。期間の数字そのものより、各段階の判断条件と成果物があるかを見ます。
段階導入では、成功した利用者だけを見て全社展開を決めないことも重要です。未利用者、途中で離脱した人、修正が多い人、管理者の視点をそれぞれ集めます。利用しない理由を責めず、業務上の制約、画面の問題、権限、教育不足、AIへの不信を分けて記録できる会社なら、次の改善が具体的になります。
さらに、社内に運用オーナーを置けるよう、設定変更の手順、ログの読み方、問い合わせの分類、月次レビューの進め方を引き継いでもらいます。発注先が永遠にすべてを抱える前提ではなく、社内で判断できる範囲を増やす計画を持っているかが、長期の定着に影響します。
よくある質問
AIの技術に強い会社なら、現場定着も任せられますか？
技術力は重要ですが、それだけでは判断できません。業務観察、画面試作、既存システム連携、教育、運用、利用指標を誰が担当し、どの成果物を出すのかを確認してください。技術担当者が現場の例外や責任分界を質問し、利用開始後の改善まで提案できるなら、定着を任せられる可能性が高まります。
候補会社には、どの段階で自社のデータを渡すべきですか？
最初から本番データを広く渡すのではなく、利用目的、保管場所、アクセス権限、削除方法、検証期間を合意したうえで、必要最小限の匿名化・サンプルデータから始めます。候補会社がデータの取り扱いと、検証終了後の返却・削除を説明できるかも選定基準に含めてください。
利用率が低いとき、まず研修を増やせばよいですか？
研修が原因の場合もありますが、画面の導線、応答時間、権限、連携エラー、回答への不信、業務ルールとの不一致が原因かもしれません。初回利用から処理完了までの離脱箇所をログと聞き取りで確認し、原因に応じて画面改善、連携修正、説明、業務手順の変更を選ぶ会社が望ましいでしょう。
提案価格が安い会社は避けるべきでしょうか？
価格だけで避ける必要はありません。ただし、業務観察、テスト、教育、運用支援、改善のどこを含み、どこが別費用なのかを同じ形式で比べてください。安い理由が対象範囲の明確化や段階導入によるものなら合理的ですが、使われるための作業が抜けているだけなら、後で追加費用や社内負担が発生します。
発注前に最低限そろえる社内情報は何ですか？
対象業務の目的、利用者と承認者、現在の手順、困っている例外、既存システム、扱うデータ、守るべき規程、導入後に変えたい指標を整理します。すべてを確定する必要はありません。分からない点も未確定として示し、候補会社に調査方法と追加確認事項を提案してもらうことが大切です。
まとめ
「AI導入したのに使われない」を防ぐ会社選びでは、AIの機能や実績の数だけを競わせないことが大切です。業務観察で現場の判断と例外を理解し、既存システムの画面とデータへ自然に組み込み、役割別の教育と問い合わせを設計し、運用上の責任分界を契約へ落とし込み、利用指標で改善を続けられるかを確認します。
候補会社へは、提案書の中に利用開始後の姿を具体的に書いてもらいましょう。誰が何を使い、どこで迷い、どんなログを見て、どの会議で何を変えるのかまで説明できる会社なら、開発物の納品にとどまらず、現場で価値が出る状態を一緒に作れます。自社の課題を整理しきれていない段階でも、調査・診断から始める選択肢を含めて比較してください。
