「うちの基幹システムにもAIを入れられないか」という相談が増えています。ただ、いざ検討を始めると「どの業務から手をつけるか」で止まってしまうケースが少なくありません。技術的にできることと、業務として成立することの間には、思った以上に距離があるためです。
この記事では、すでに動いている業務システムにAI機能を追加する際に、どこから着手すれば手戻りが少ないかを、判断の順序として整理します。結論を先に言えば、「人の判断を置き換える機能」ではなく「人の下書きを作る機能」から入るのが、もっとも失敗が少ないルートです。
なぜ「AIを足す」プロジェクトはつまずくのか
つまずきの原因は、技術力より着手点の選び方にあることが多い、というのが現場での実感です。典型的には次の3つです。
- 一番難しい業務から始めてしまう：経営層の目に留まりやすい花形業務（与信判断、価格設定など）は、同時にもっとも間違いが許されない領域です。
- 精度の合格ラインを決めずに作り始める：「だいたい合っていればいい」のか「99%必要」なのかで、設計もコストも桁が変わります。
- 出力の受け取り手が決まっていない：AIが出した結果を誰がどう扱うのかが曖昧だと、作っても使われません。
ここで前提となる用語を一つ整理しておきます。ハルシネーションとは、生成AIがもっともらしい嘘を出力してしまう現象のことです。学習データにない情報を聞かれたときでも、AIは「分かりません」と言わずに自然な文章で埋めてしまう性質があります。これは設定で完全にゼロにできるものではなく、「起きる前提で業務フローを設計する」というのが現時点での現実的な向き合い方です。
最初の判断軸：その出力を「誰が受け取るか」
着手点を決める際、最初に見るべきは業務の重要度ではなく、AIの出力が誰の手に渡るかです。ここで難易度がはっきり分かれます。
| 出力の受け取り手 | 難易度 | 求められる精度 | 具体像 |
|---|---|---|---|
| 社内担当者（下書きとして） | 低 | 修正前提で可 | 議事録の要約案、メール返信の原案 |
| 社内担当者（判断材料として） | 中 | 根拠の提示が必須 | 過去事例の検索、問い合わせの分類 |
| 顧客（人のチェックあり） | 中〜高 | 高め | オペレーター支援型のチャット応対 |
| 顧客（人のチェックなし） | 高 | 非常に高い | 無人チャットボット、自動審査 |
最初のプロジェクトは、迷わず一番上の行から選ぶことをおすすめします。下書きであれば、AIが間違えても業務は壊れません。担当者が修正するという工程が最初から組み込まれているからです。この「人が間に入る仕組み」をヒューマン・イン・ザ・ループと呼びます。AI導入初期は、これを省かない設計が安全です。
着手順を決める4つのステップ
対象業務の候補が複数ある場合、次の順序で絞り込むと判断がぶれません。
- 既存システムに、すでにデータが溜まっている業務を選ぶ
新たにデータ収集から始める案件は、それだけで数か月遅れます。過去の問い合わせ履歴、報告書、受注データなど、蓄積済みの資産がある領域を優先します。 - 「正解」が後から確認できる業務を選ぶ
AIの出力が合っていたかどうかを人が判定できないと、改善ができません。分類や要約のように、後で答え合わせできる業務が向いています。 - 月あたりの発生件数を数える
月に数件しか発生しない業務を自動化しても、効果が見えません。件数×1件あたりの所要時間で、削減効果を先に概算します。 - 失敗したときの影響範囲を確認する
間違いが社外に出る業務か、社内で止まる業務か。初回は後者を選びます。
たとえば次のような場面です。問い合わせメールが月に数百件届き、それを担当者が読んで種別ごとに振り分けている——こうした業務は、過去の振り分け結果がデータとして残っており、正解も確認でき、件数も十分あり、間違えても社内で気づけます。4条件をすべて満たすため、初回案件としては有力な候補になります。
既存システムとの接続は4パターンで考える
着手業務が決まったら、次は技術的な接続方法です。ここで押さえておきたいのがAPIという仕組みです。APIとは、ソフトウェア同士が機能やデータをやり取りするための窓口のことで、AIサービスの多くはAPI経由で既存システムから呼び出せるようになっています。
接続方法は、おおむね次の4パターンに整理できます。
| パターン | 既存システムへの改修 | 向いているケース |
|---|---|---|
| 別ツールで並行運用 | なし | 効果検証の初期段階 |
| バッチ処理で夜間に一括処理 | 小（出力の取り込みのみ） | リアルタイム性が不要な分類・要約 |
| 既存画面にAPI呼び出しを追加 | 中 | 入力支援、候補提示 |
| 業務フロー自体をAI前提で再設計 | 大 | 十分な実績が出てから |
初回は、上の2パターンに留めるのが無難です。既存システムを改修せずに効果を測れる形から入ると、「やってみたが効果がなかった」となったときの損失が小さく済みます。
社内文書を参照させたい場合
「自社のマニュアルや規程をAIに読ませたい」という要望はほぼ必ず出ます。ここで使われるのがRAG（検索拡張生成）です。これは、AIに回答させる前に社内文書から関連する部分を検索して渡し、その内容に基づいて答えさせる方式を指します。AI自体を学習し直す必要がないため、文書を差し替えれば回答も更新される点が実務上の利点です。
ただし、RAGの品質は元の文書の整理状態にほぼ比例します。同じ内容の新旧バージョンが混在していたり、スキャン画像のPDFばかりだったりすると、検索段階で精度が落ちます。RAGの検討を始めたら、先に文書の棚卸しに着手してください。
精度の合格ラインは「評価セット」で決める
AI案件でもっとも軽視されがちなのが、評価の仕組みです。開発前に、過去の実データから30〜100件程度を抜き出し、人が正解を付けた評価セットを作ります。これを使ってAIの出力を採点する作業をEval（評価）と呼びます。
評価セットを先に作っておく利点は3つあります。
- プロンプト（AIへの指示文）を変更したとき、改善したのか悪化したのかを数字で判断できる
- AIモデルを別のものに乗り換える際、同じ基準で比較できる
- 関係者との間で「どこまでできれば合格か」の合意が取れる
発注側としては、開発を依頼する時点で「評価セットの作成と評価結果の提示を成果物に含めてください」と伝えるだけで、プロジェクトの進め方が大きく変わります。
社内ルールと法令で押さえておくべき点
実装と並行して、社内の運用ルールも整えておく必要があります。参照できる公的な資料としては、総務省・経済産業省が2024年に公表した「AI事業者ガイドライン（第1.0版）」があり、AIを開発・提供・利用する各立場に求められる考え方が整理されています。内容は更新される場合があるため、検討時点での最新版を確認してください。
また、個人情報を含むデータを外部のAIサービスに送る場合は、個人情報保護法上の取り扱い（利用目的の範囲、第三者提供や委託にあたるかの整理など）を確認する必要があります。著作権については、文化庁の文化審議会著作権分科会法制度小委員会が2024年に取りまとめた「AIと著作権に関する考え方について」が、生成・利用段階の論点を整理しています。
海外向けにサービスを提供する場合は、EUで2024年に成立したAI法（EU AI Act）のように、リスクに応じて規制の強度を変える枠組みの動きもあります。適用対象や施行時期は段階的であるため、該当しそうな場合は専門家への確認をおすすめします。
明日から着手できる3つの作業
システム開発を発注する前に、社内だけで進められる準備があります。
- 業務の棚卸しを1枚の表にする：業務名、月間件数、1件あたりの所要時間、データの所在、間違えたときの影響範囲。この5列だけで構いません。候補が自然に絞れます。
- 候補業務の過去データを30件抜き出す：入力と、人が出した正解をセットで用意します。これがそのまま評価セットになります。
- 手持ちの生成AIで、その30件を手作業で試す：APIを使わず、画面に貼り付けるだけで構いません。何件正解したかを数えれば、開発に進む価値があるかの一次判断ができます。この段階で機密情報を扱う場合は、入力データが学習に使われない設定かどうかを必ず確認してください。
まとめ
既存システムへのAI追加は、技術選定より着手点の選定が勝負です。整理すると次の通りです。
- 人の判断を置き換える機能ではなく、人の下書きを作る機能から始める
- データが溜まっていて、正解が確認でき、件数があり、失敗が社内で止まる業務を選ぶ
- 初回は既存システムを改修せず、並行運用やバッチ処理で効果を測る
- 開発前に評価セットを作り、合格ラインを数字で合意しておく
- AI事業者ガイドライン（2024年）などを参照し、社内の運用ルールを並行して整備する
最初の一歩で大きな成果を狙う必要はありません。小さく始めて、評価の仕組みを残すこと。これが、2件目・3件目の展開を速くする最短ルートになります。
この記事は、AI で下書きを作り、益山康秀（運営者）が内容を確認して公開しています
