この記事で分かること
- 自社データをAIに使う前に確認する品質・権限・機密性の整理方法
- 精度だけでなく、誤回答や情報漏えいのリスクまで比較する評価軸
- AIシステム会社の設計力を見抜く質問、成果物、PoCの進め方
- 契約・運用・更新の責任分界を曖昧にしないためのチェックポイント
自社データを使うAIでは「会社選び」が精度を左右する
公開情報を検索して答えるAIと、社内の固有データを参照して答えるAIでは、失敗の原因が異なります。後者では、データの登録単位や更新時期が揃っていないだけで検索結果が変わり、部署ごとの閲覧権限を扱えないだけで利用範囲が狭くなります。回答が自然な文章で返ってくるほど、誤りに気付きにくくなる点も見逃せません。
したがって、開発会社の比較では「どの生成AIを使うか」だけを聞いても判断材料として不十分です。データをどのように取り込み、誰に何を見せ、どの条件で合格とし、問題が起きたときにどこを直すのか。その一連の設計を説明できる会社ほど、自社データ向けの開発に向いています。
モデルの性能と業務の正しさは別に考える
モデルが文章を流暢に作れても、社内規程の最新版を参照できるとは限りません。反対に、参照データが整っていても、質問の意図を取り違えれば現場では使えません。モデル、検索、データ整備、画面、業務フローを一つの仕組みとして捉え、それぞれの失敗を切り分ける設計が必要です。
候補会社から「高精度です」という説明を受けたら、何を正解と定義したのか、どのデータを除外したのか、誤回答を誰が確認するのかを追加で尋ねます。数値を一つ示すだけでなく、業務上許容できない失敗を先に共有できるかが、提案の質を判断する手掛かりになります。
選定前に自社データの利用条件を棚卸しする
会社を探す前に、AIへ渡してよいデータと、渡し方を決めます。候補会社に丸投げすると、比較するための前提が会社ごとに変わり、価格やデモの印象だけで決めやすくなります。完璧なデータ台帳を作る必要はありません。まずは代表的な業務を一つ選び、入力、判断、出力、確認者を簡単に書き出します。
目的と判断単位を一文で定義する
「社内文書をAIで活用する」では広すぎます。「営業担当が顧客からの質問に回答する前に、最新版の製品資料から根拠候補を確認する」のように、利用者、場面、期待する支援を一文にします。AIに最終判断をさせるのか、候補を提示させるのかも書き分けます。目的が定まると、必要なデータ、画面、ログ、評価方法が具体化します。
データの種類・所有者・更新責任を並べる
文書、表計算、問い合わせ履歴、画像など、形式ごとに扱いやすさは違います。ファイル名だけでなく、内容の所有部署、更新頻度、最新版を決める人、廃棄や保管のルールを記録します。過去の資料を参照してよいのか、顧客ごとに分離すべきか、個人にひもづく情報が含まれるかも、会社へ伝える前提条件です。
データの準備をどこまで発注側が担うかは、見積もりと納期に直結します。データを渡せばすぐ学習できるという説明ではなく、欠損や重複、同じ意味の別表記をどう扱うかまで提案書に記載できる会社を選びます。整備の判断を自社に戻す場合も、作業手順と完了条件が示されていることが大切です。
権限の境界を業務の言葉で表す
「社内ユーザーなら閲覧可能」では粗すぎます。部署、役職、案件、顧客、拠点、雇用状態など、実際に閲覧範囲を分けている条件を洗い出します。異動や退職、案件終了が起きたとき、いつ権限へ反映されるのかも決めます。質問文に機密情報が含まれる場合のログ保存範囲や、管理者が確認できる範囲も同時に確認します。
権限は画面の表示制御だけでなく、検索候補の生成、回答の引用、ログの閲覧まで連続しています。候補会社には「見せてはいけない文書が検索結果の候補に混ざらないか」「権限変更前のキャッシュが残らないか」「管理者のテスト用アカウントは本番と分離されるか」を確認します。回答画面だけのデモでは分からないため、権限が異なる二つの利用者で同じ質問をするテストを依頼します。
比較表に入れるべき5つの評価軸
候補会社を比べるときは、提案書を読んだ印象ではなく、同じ質問と同じ資料で評価します。次の五つは、自社データを使うAIで特に差が出やすい項目です。各項目に「確認できた証拠」と「未確認の懸念」を記録すると、担当者の主観だけで決まりにくくなります。
| 評価軸 | 見るポイント | 確認できる成果物・質問 |
|---|---|---|
| データ品質 | 欠損、重複、版、表記ゆれを扱う手順 | データ項目表、整備方針、除外基準 |
| 権限設計 | 利用者・文書・案件ごとの閲覧境界 | 権限マトリクス、異動時の反映手順 |
| 機密性 | 保管、送信、ログ、委託先のアクセス範囲 | 構成図、データフロー、削除手順 |
| 評価設計 | 正答だけでなく誤答・根拠・業務時間を確認 | 評価データ、合格条件、再評価計画 |
| 委託先の設計力 | 業務理解から運用・改善までの責任分担 | 要件定義書、試験計画、運用体制 |
1. データ品質は「量」よりも判断に使える状態かを見る
件数が多いことと、AIが正しく使えることは同じではありません。古い資料が現行資料と同じ検索対象にある、表の単位が月によって違う、問い合わせの回答欄が担当者の自由記述になっている、といった状態では、情報量が増えるほど誤った候補も増えます。
会社には、登録前の検査、版の優先順位、重複の扱い、更新失敗時の通知を聞きます。文章を細かく分割する場合も、見出しや適用条件が失われない方法かを確認します。データ整備の観点は、AIシステム開発に必要なデータの整備・評価を検討するときにも参考になります。
2. 権限は「回答できるか」ではなく「候補に出ないか」まで確認する
参照権限がない文書を回答本文へ表示しないだけでは、十分とはいえません。検索候補、要約の材料、引用元のタイトル、エラーメッセージに機密の手掛かりが残らないかを確認します。ユーザーが質問を工夫して別部署の内容を引き出す可能性もあるため、権限を変えたテストを設計できる会社が望ましいです。
権限情報を業務システムから連携するなら、連携元が停止した場合の扱い、同期の遅れ、手動で緊急停止する方法を決めます。管理画面で権限を直接編集する運用は、二重管理になりやすいので、どちらを正とするかを提案段階で明記します。
3. 機密性はサービス名ではなくデータの流れで比較する
「安全なクラウドです」という説明だけで判断せず、入力から保存、処理、ログ、バックアップ、削除までデータがどこを通るかを図にしてもらいます。外部のモデルや分析サービスへ送信するのか、送信内容をマスキングするのか、開発者が本番データを見る可能性はあるのかを分解して確認します。環境を開発・検証・本番で分ける方法も、システム構成と一緒に見ます。
秘密情報を扱う場合は、アクセスできる担当者、作業を記録するログ、保存期間、返却・削除の確認方法を契約と運用手順に落とします。匿名化やマスキングを採用する場合も、置換後に業務上必要な結び付きを保てるかをテストします。安全策を増やすほど運用負荷も増えるため、誰が実行し、失敗したら誰が判断するかまで合意します。
4. 評価は「正解率」だけでなく、失敗の重さを測る
AIの評価データには、よくある質問だけでなく、答えが存在しない質問、古い版と新しい版が競合する質問、権限外の情報を求める質問を含めます。回答文が正しそうに見えても、根拠の文書や版が確認できなければ業務では採用できない場合があります。候補会社に、回答、根拠、拒否、確認依頼をどう採点するかを示してもらいます。
評価結果は、開発会社が用意した例だけでなく、発注側が選んだ代表的なケースで測ります。部署ごとに許容できる誤りが異なるなら、全体の平均値で隠さず、業務別の表で比較します。時間短縮や確認者の負担など、導入後に観測したい指標も先に決めておくと、デモの印象に引きずられません。
5. 設計力は「作れる機能」より「作らない判断」に表れる
要望された機能をすべて実装する会社より、危険な使い方や効果の薄い範囲を指摘し、段階導入を提案できる会社の方が自社データ案件に適することがあります。たとえば、最終承認をAIに委ねず、根拠と確認者を残す設計にする、全社展開の前に一つの業務で更新処理を検証する、といった判断です。
設計力を確かめるには、抽象的な相談をそのまま見積もらず、データの制約と業務の例外を説明し、提案がどう変わるかを見ます。要求の聞き取り、データ調査、試験、教育、保守を誰が担当するかが一貫していれば、引き継ぎ後の行き違いも減らせます。
候補会社との打ち合わせで聞く質問
質問は「対応できますか」だけで終えず、具体的な状況と、回答の証拠を求めます。次のような問いを同じ資料で複数社に投げると、比較が容易になります。
データについての質問
- 文書の版が複数あるとき、どの版を優先し、古い版をどう扱うか。
- 表計算の列名や単位が異なるとき、誰が意味を確定し、どの成果物に残すか。
- データが更新されない、または取り込みに失敗したとき、利用者へどう知らせるか。
- 自社が準備すべきデータと、会社側が行う整備を境界付きで示せるか。
権限と機密性についての質問
- ユーザーの所属や案件権限を、どの仕組みから、どの頻度で連携するか。
- 権限外の文書が検索候補、引用、ログに出ないことをどう試験するか。
- 開発・検証の担当者が本番データを見る場合の条件と記録方法は何か。
- 契約終了時に、データ、バックアップ、ログ、認証情報をどう返却・削除するか。
評価と運用についての質問
- 合格条件を誰と決め、未達の場合にどの範囲を直すか。
- モデルや検索設定を変更したとき、再評価をいつ実施するか。
- 誤回答を発見した利用者が、根拠とともに報告できるか。
- 導入後の問い合わせ、監視、データ更新、改善提案を誰が担当するか。
RFPを作るなら、質問だけでなく提出物の形式もそろえます。AIの受託開発会社を選ぶときの項目整理は、RFPに入れるべき確認項目も参照しつつ、自社データの権限・削除・評価を追加してください。回答が抽象的なままの場合は、契約後に決めるのか、提案前に決められない理由があるのかを確認します。
提案書とデモで設計の実力を見抜く
最低限そろえてもらう成果物
候補会社の比較では、口頭説明を議事録へ残すだけでは足りません。データ項目と入手元をまとめた一覧、利用者と文書の権限マトリクス、データフロー図、評価ケースと合格条件、運用時の役割表を提出してもらいます。内容が初期案でも、未決定部分に担当者と期限が付いているかを確認します。
見積書も、開発費だけでなく、データ整備、連携、評価、教育、保守、モデルや利用量に応じた費用を分けてください。安価に見える提案でも、更新処理や権限連携が別途なら比較になりません。逆に、必要な作業を細かく分けた見積もりは、予算調整や段階導入の相談がしやすくなります。
デモは同じ質問を条件を変えて試す
デモ用のきれいな資料だけでは、実運用の差が分かりません。自社から匿名化した短い資料や、版の異なる文書を用意し、同じ質問を複数の条件で試します。回答に根拠が付くか、根拠の版が分かるか、答えがないときに推測せず確認へ誘導するかを観察します。
さらに、権限の異なる二つのアカウントで質問し、片方だけが見られる内容が混ざらないかを確認します。わざと曖昧な質問や権限外の依頼をして、システムが拒否・確認・限定回答のどれを選ぶかも見ます。失敗が起きたときに画面へ警告を出し、ログから原因を追えるかまで示してもらいます。
精度と安全性を両立する構成を検討する
自社データを活用する方法には、社内文書を検索して回答に使う方式、業務システムのデータを条件付きで取得する方式、特定の判定を補助する方式などがあります。どれが最適かは、データの更新頻度、許容される遅延、権限の細かさ、回答の説明責任で変わります。会社へ方式を指定するより、業務条件を伝えて複数案のリスクと費用を比較します。
検索・生成・業務処理を分けて考える
文書を探す処理、回答文を作る処理、業務システムへ登録する処理を一つにまとめると、誤りの場所が追いにくくなります。検索結果が妥当か、生成された文章が資料に沿っているか、登録前に人が確認できるかを段階別に検査できる構成が望ましいです。自動登録まで行う場合は、取り消し、承認、再実行の手順も設計します。
安全策が業務を止めないか検証する
厳しい制限を掛けるほど、必要な利用まで拒否する可能性があります。機密性を優先する範囲と、現場の応答速度を優先する範囲を業務ごとに決め、例外が起きた際の人手の代替手順を用意します。障害時に参照する従来の資料や連絡先がなければ、安全なAIを導入しても業務は止まります。
更新できる設計かを確認する
自社データは、組織変更や商品改定に合わせて変わります。初期データを登録して終わりではなく、追加・更新・廃止を誰でも同じ手順で行えるか、更新後に評価を自動または定期的に実行できるかを確認します。特定の担当者しか修正できない仕組みは、担当変更時に停滞するため、手順書と引き継ぎ方法を納品範囲へ含めます。
内製と委託を組み合わせる場合は、業務知識を持つ自社担当と、AI・連携を担う会社の境界を先に決めます。内製か外注かを判断する基準を確認しながら、データの承認者、モデルや構成の変更者、障害時の指揮者を一人ずつ置くと、責任の空白を避けられます。
候補会社を同じ基準で採点する方法
採点表は、点数の高さだけで勝者を決めるためではありません。未確認の項目や、点数では表しにくい重大なリスクを見えるようにする道具です。たとえば、五つの評価軸を各5点で採点し、根拠となる資料のページやデモ結果を併記します。機密性や権限に重大な未解決事項がある場合は、合計点とは別に「契約前に解消する条件」として扱います。
| 確認段階 | 合格とみなせる状態 | 保留・再質問が必要な状態 |
|---|---|---|
| 初回ヒアリング | 業務の目的、利用者、データの境界を質問する | モデルや機能の話だけで業務を聞かない |
| 提案・見積もり | 整備、連携、評価、運用の作業と費用が分かれる | 「データを渡せば対応」とだけ書かれる |
| デモ・PoC | 正答、根拠、拒否、権限外の挙動を同じ条件で確認できる | 成功例だけを示し、評価データを開示しない |
| 契約前 | アクセス、保存、削除、変更、障害の責任者が決まる | 安全策や再評価を「別途協議」とする |
小さなPoCで会社の対応力を検証する
本番を前提に大量のデータを渡す前に、対象業務とデータを絞ったPoCを実施します。目的は派手なデモを作ることではなく、候補会社が不確実な点を洗い出し、測定し、改善案を出せるかを見ることです。PoCの範囲には、開発会社が扱えるデータだけでなく、発注側が実際に準備できるデータも含めます。
PoCの進め方
- 代表的な質問、答えがない質問、権限外の質問を準備する。
- 利用を許可したデータと、意図的に除外するデータを分ける。
- 回答、根拠、拒否、応答時間、確認者の作業を記録する。
- 誤りを原因別に分類し、データ・検索・生成・画面のどこを直すか決める。
- 改善後に同じ評価を繰り返し、本番へ進む条件を合意する。
PoCで良い結果が出ても、別の部署や別の版の資料で同じ結果になるとは限りません。適用範囲を広げるときは、権限、更新、運用負荷を再確認します。逆に、想定どおりにいかなかった場合も、原因を説明して次の案を出せる会社なら、失敗を早く小さくできたと評価できます。
契約前に責任分界と変更条件を確定する
AIシステムは納品日に完成して終わるものではありません。データの更新、モデルや検索設定の変更、権限の変更、障害、誤回答の報告が続きます。契約書や仕様書には、誰が何を行い、どの状態をもって完了とするのかを記載します。
データとアクセスの扱い
- 利用を許可するデータ、目的、保管場所、保存期間を列挙する。
- 開発・検証・本番の環境、アクセスできる担当者、作業ログの扱いを決める。
- 委託終了、担当者変更、障害発生時の返却・削除・認証無効化を定義する。
品質と変更の扱い
- 回答の合格条件、根拠の表示、拒否すべき質問、再評価の条件を決める。
- データ形式や業務ルールが変わったときの追加費用と納期を決める。
- 重大な誤回答や権限不備を見つけたときの停止権限と連絡経路を決める。
「精度保証」という一言だけでは、データ更新や質問の範囲が曖昧です。評価ケース、測定時点、再現条件、未達時の対応を具体化します。安全性も同様に、抽象的な宣言ではなく、データフローとテスト結果、アクセス記録を確認できる状態にします。
避けたい選定パターン
デモの回答が自然だった会社だけで決める
用意された質問に自然に答えられても、最新版の根拠や権限外の拒否を確認していなければ、実務への適合性は分かりません。自社の失敗しやすい質問を持ち込み、答えられないときの挙動まで見ます。
データを一括で渡し、後から権限を考える
後付けの権限設計は、既に作られた索引やログ、バックアップの扱いに影響します。先にデータの分類と利用者の境界を定め、最小限の範囲で検証を始めます。匿名化できるデータだけで設計を確かめる段階を置くことも有効です。
責任者が「AIに詳しい人」だけになる
AIの仕組みを理解する担当者に加えて、業務の正解を決める人、情報管理を判断する人、現場で運用する人が必要です。三者の意見が分かれたときの決裁者を置かなければ、精度と安全性の優先順位が決まりません。
保守を後回しにして初期費用だけで比べる
データの追加や権限変更を自社で行えないと、毎回の小さな修正が大きな依頼になります。月次の確認、障害対応、評価の更新、担当者教育を含む総費用で比べます。安さではなく、必要な仕事が見積もりに含まれているかを確認します。
迷ったときの選定手順
候補を絞る順番を決めると、担当者の負担を抑えながら比較できます。まず秘密性と権限の条件を共有し、対応できない会社を早い段階で除外します。その後、同じデータと質問で設計案を比べ、最後にPoCと契約条件を確認します。
- 目的、利用者、データの種類、許容できない失敗を一枚にまとめる。
- 候補会社へ同じ質問を送り、データフローと責任分界の説明を求める。
- 品質・権限・機密性・評価・設計力を、根拠付きで採点する。
- 匿名化または限定したデータでPoCを行い、失敗への対応を見る。
- 運用、再評価、削除、変更費用、障害対応を契約前に確定する。
この手順で最後まで説明がつながる会社なら、採用する構成が変わっても判断を共有しやすくなります。逆に、提案の各部分が別々の担当者から出てきて、データの責任者や再評価の方法が決まらない場合は、条件を整理し直してから次へ進みます。
よくある質問
自社データが少なくても、AIシステム会社へ相談できますか？
相談できます。件数の多さより、対象業務の判断基準と代表的な例を整理することが先です。少量のデータで検索や権限の設計を確認し、必要な追加データと整備作業を見積もる進め方があります。データが少ない理由が記録不足なのか、業務上まれな事象なのかも、会社へ共有すると評価条件を作りやすくなります。
AIへ入力した情報が、別の利用者へ表示される心配はありませんか？
仕組みと設定によってリスクは変わるため、サービス名だけで判断しないことが大切です。データフロー、権限境界、ログ、バックアップ、開発者のアクセス、削除方法を確認し、異なる権限のテストを実施します。心配な情報を最初から本番へ渡さず、許可範囲を限定した検証から始める方法もあります。
提案された正答率が高ければ、精度は十分と考えてよいですか？
正答率だけでは不十分です。答えがない質問への対応、根拠の提示、古い版の混入、権限外の質問、確認者の作業時間も確認します。業務によって許容できない失敗が違うため、代表的なケースを自社で用意し、合格条件を会社と合意してから数値を比較します。
大手のAIシステム会社なら安全性も高いのでしょうか？
規模や知名度だけでは決まりません。自社のデータ分類、利用者の権限、更新手順、停止判断を具体的に設計し、証拠を提示できるかを見ます。大手・中小を問わず、担当者の経験に依存せず、運用と引き継ぎまで説明できる会社を同じ基準で比較してください。
PoCで失敗した会社は、候補から外すべきですか？
失敗の有無だけでなく、原因の切り分けと改善の進め方を確認します。データの不足、検索の設定、権限の連携、質問の定義など、原因を説明し、再評価の条件を提案できるなら、問題を小さく発見できたともいえます。失敗を隠す、評価条件を変える、根拠を示さない場合は慎重に判断します。
まとめ
自社データを活かすAIシステム会社選びでは、モデルやデモの印象だけでなく、データ品質、権限、機密性、評価、委託先の設計力を同じ条件で比べることが重要です。データをどこへ渡し、誰が何を見られ、どの回答を合格とし、更新や障害に誰が対応するのかを具体化すると、精度と安全性のトレードオフを整理できます。
最初から全社展開を決めず、代表的な業務と限定データでPoCを行い、失敗の扱いまで確認してください。候補会社が質問を返し、根拠のある成果物を示し、運用と契約の責任を明確にできるかが、長く使えるAIシステムにつながります。
