AI業務自動化
約15分
更新

生成AIを業務へ組み込む方法:対象業務の選定から運用まで

執筆・編集Malake株式会社
まず押さえたいこと

生成AIの業務組み込みとは、入力、処理、確認、保存までの業務の流れにAIを配置し、人が判断する箇所を残して進めることです。対象業務を選び、期待する結果とAIに許可する処理を決めてから試作を評価し、限定した範囲で運用するかを判断します。

この記事の要点

生成AIの導入の効果は、契約したツールの数ではなく、業務の結果がどう変わったかで判断します。最初は要約・分類・下書きなど、人が確認できる業務を選び、期待する結果、AIに許可する処理、確認者と失敗時の戻し方を決めます。試作では、回答の品質と根拠、人の確認・修正の時間、費用、有人への引継ぎを今の手順と比べて評価します。重大な誤りや権限外の処理がないことを確かめてから、範囲を限って運用へ進めます。

この記事でわかること

  • 生成AIに任せる業務の選び方と、試作の前に決めること
  • PoCの評価表で、品質・人の作業時間・費用・権限を確かめる方法
  • 顧客対応で、回答の保留と有人への引継ぎを評価する観点
  • PoCの結果から、範囲を限って運用へ進むか、検証を続けるか、見送るかを決める条件

「チャット導入」と「業務組み込み」の決定的違い

企業のDX戦略の一環として、生成AIの活用には2つの段階があります。

  • 段階1:チャットツールの導入
    ChatGPTなどを、社員がそれぞれ個別に使う状態です。アイデア出しや文章の作成には便利ですが、ツールを導入しただけでは、どの処理をAIに任せ、誰が確認し、結果をどこへ残すかまでは決まりません。
  • 段階2:業務への組み込み
    基幹Webシステムやチャットツール(Slackなど)の裏側でAIが処理し、その結果を人が確認・修正する状態です。
    Malakeでは、定型処理・監視・一次対応を自動化して運用の手間を減らす取り組みをZeroOpsと呼び、待ち時間や手作業を減らす対象として扱っています。

業務組み込みの具体例

  • 1. 問い合わせへの回答案の作成
    メールを受信 → AIが過去のFAQを参照して回答案を作成 → Slackに通知 → 担当者が確認して送信。
    担当者は一から文面を書く必要がなくなり、確認と修正に時間を使えます。
  • 2. 会議後の次の対応の抽出
    録音データ → AIが文字起こし・要約 → 決定事項とタスクを箇条書きにする → プロジェクト管理ツール(Jiraなど)に登録する案を作成。
    自動化の流れの例:
    [音声の入力] → [文字起こし] → [要約(LLM)] → [人による確認] → [保存] → [通知]
    会議で決まったことの食い違いや、タスクの登録漏れを防げます。
  • 3. 社内規程への質問にすぐ答える(RAG)
    Slackで「交通費精算の期限は?」と質問 → AIが有効な版の就業規則を検索し、根拠の箇所とともに回答する。
    担当部署の問い合わせ対応の負担を減らせるかを評価します。

失敗しないユースケースの選び方

生成AIは幅広い作業に使えますが、すべての業務に向いているわけではありません。

段階2をさらに進めると、1つの処理の自動化から、複数の工程をまとめて任せる形になります。Malakeが提供するAIAG(AI業務Orchestrator)はこの形の製品です。依頼に対して作業計画と担当を組み立て、専門AIチームが分担して進め、参照した情報と承認の履歴を記録として残します。

エージェント機能を持つ製品の使い始め方と、問い合わせ対応などの具体的な活用例は、AIエージェントの始め方と活用例で扱っています。

汎用の生成AIと、用途を絞ったAIの選び方

文章の要約や下書きのように指示の幅が広い作業には汎用の生成AIが、文字認識(OCR)や翻訳のように用途が決まった作業には、その用途向けのAIや既存のツールが合う場合があります。どちらが合うかは、費用や精度の一般的な比較だけでは決まりません。対象業務と今の手順、誤りが起きたときの影響、運用・保守の負担を比べて決めます。生成AIを使わず、既存のルールや仕組みで足りる業務もあります。

対象の業務は、次の3つの観点で選びます。

  1. 頻度:毎日のように発生する業務か。たまにしか行わない業務は、自動化しても費用に見合う効果が出にくくなります。
  2. 効果:自動化で、どのくらいの作業時間を減らせるか。
  3. リスク:誤りがあったときの影響はどのくらいか。顧客へ直接回答する業務は影響が大きく、社内向けの要約は比較的小さくなります。

あわせて、AIの誤りを人が確認して直せる手順(Human-in-the-loop)を、業務の流れの中に組み込んでおきます。

つまずきやすい点

よくあるつまずきは、AIに100%の精度を求めてしまうことです。生成AIの出力には、一定の割合で誤りが含まれます。人が確認・修正する手順(Human-in-the-loop)を前提に組み込んでおかないと、誤りを恐れて業務で使えない仕組みになりがちです。

1. 頻度 (Frequency)

毎日発生する定型業務か?
(低頻度ならROIが出にくい)

2. 効果 (Effect)

自動化で何時間削減できるか?
(インパクトの大きさ)

3. リスク (Risk)

間違った時のダメージは?
(社外向けは高リスク)

導入推奨マトリクス
RISK
EFFECT & FREQUENCY
見送り
(慎重に検討)
Human-in-the-loop
必須領域
後回し
(ROI低)
Recommended最優先社内要約・検索等

Human-in-the-loop (人間参加型) を前提とすることで、本来リスクが高い領域も、安全に自動化の恩恵を受けることが可能になります。

縦軸にリスク、横軸に効果・頻度をとったマトリクス図。リスクが低く効果が高い領域(右下)が最優先。リスクが高くても効果が高い領域(右上)は人が介在することで対応可能となる。

頻度が高く、効果が大きく、誤りの影響が小さい右上の領域(要約・抽出・下書きの作成)が、最初の候補になります。

RAG(検索拡張生成)による自社データ活用

ChatGPTなどの生成AIは、そのままでは自社の社内規程や顧客情報を知りません。これらを参照させる方法の一つがRAG(Retrieval-Augmented Generation、検索拡張生成)です。

たとえば「就業規則について教えて」と聞くと、まず社内の資料を検索して関連する規定を取り出し、その内容を根拠として回答を作ります。ただし、RAGを使っても回答が正しいとは限りません。必要な資料を取り出せたか(検索)、取り出した資料に沿って回答を作れたか(生成)、根拠にした資料自体が有効な版か、を分けて確かめます。古いマニュアルや重複したファイルが検索対象に残っていると、資料に忠実な回答でも業務上は誤りになります。

RAGの構築手順と、検索・回答・権限を確かめる評価質問の作り方は、RAGの精度評価表で扱っています。

自社の状況を確認する

  • □ 解決したい課題が、生成AIを使わずに既存のルールや仕組みで解決できないかを確かめたか
  • □ AIに参照させる資料(マニュアルなど)がデジタル化され、有効な版と管理者が決まっているか
  • □ 期待する結果と、許容できない誤り(業務上重大な誤り)を業務責任者が決めているか
  • □ 利用する契約・機能ごとに、入力データの学習利用、保存、ログ、閲覧できる人を確認したか
  • □ 利用規約やプライバシーポリシーの改定の要否を確認したか
  • □ 悪意のある入力でAIの動作を変えようとする攻撃(プロンプトインジェクション)への対策を検討しているか
  • □ 画像の生成など、著作権を侵害するおそれのある作業を含んでいないか
  • □ 初期・継続の費用と人の確認・運用の時間を含め、利用量と比較期間をそろえて見積もっているか
  • □ 現場の担当者が、AIの回答を評価する時間を確保できるか
  • □ 対象と期間を絞った試作(PoC)で評価してから、範囲を広げる計画になっているか

評価指標と運用・ガバナンス

AIを使う仕組みは、公開した後も改善を続ける前提で運用します。プロンプト(AIへの指示文)は、一度書いて終わりにせず、出力を確認しながら調整を重ねます。AIに実装作業そのものを任せる場合の進め方は仕様駆動開発とLoop Engineeringで扱っています。

プロンプトの改善例(修正前と修正後)

× Before(曖昧な指示)

「この議事録を要約して。」

→ 何を、どのくらいの長さで書けばよいかが分からず、結果がばらつく。

◎ After(具体的な指示)

「以下の議事録に明記された【決定事項】と【次の対応】を、それぞれ最大3点の箇条書きで抽出してください。該当する記載がなければ『記載なし』とし、件数に合わせて補わないでください。担当者・期限は明記された場合だけ記載し、不明なら『未記載』としてください。文体は常体(だ・である)で。」

→ 出力の形式と、不明な場合の扱いを指定する。抽出した内容が原文にあるかは、人が確認する。

試作を業務で使えるかは、利用者の満足度(Good/Bad)や回答の速さだけでは判断できません。業務として求める結果に対して、品質と根拠、人の作業、費用、権限、有人への引継ぎを評価します。評価表、顧客対応の評価例、本番へ進む条件は、この下の3つの小見出しで扱います。

プロンプトや回答の記録(ログ)は、監査や改善のために何を残すかを決めて保存します。記録する項目(入力・回答・参照した資料・操作)、機密情報・個人情報の扱い、保存期間、閲覧できる人を決め、権限の管理とあわせて運用します。モデルを動かす場所(社内・クラウド上の自己運用・事業者のAPI)や運用の担当を決める際に使える、データの送り先や費用を比べる確認票を、生成AIのローカルLLMと外部APIの選び方にまとめています。

生成AIのPoC評価表:品質・時間・費用を比べる

評価を始める前に、対象の業務と利用者の役割、参照する資料の有効な版、期待する結果、AIに許可する処理、合格の基準(受入基準)、判断する人を決めます。評価に使う例には、よくある依頼に加えて例外も含め、プロンプトの調整に使う例と、最終確認に使う例を分けます。最終確認用の例に合わせて調整した結果は、独立した確認として扱いません。NISTの生成AIプロファイルも、実際の利用に近い条件で性能を測って記録すること、限られた事例の評価から性能を一般化しないことを挙げています(NIST AI 600-1)。

1件ごとに、次の項目を記録します。

  • ケースID、入力(質問・依頼)、利用者の役割と権限
  • 参照した資料と、モデル・プロンプト・検索設定の版
  • 期待する結果と実際の結果、誤り・不足の分類
  • 人の作業時間・経過時間・費用
  • 判断(合否)、未確認の事項、再試験の担当

集計は、次の7項目で行います。

▼ 業務評価表(7項目)
評価すること確かめ方・記録判断時の注意
回答の正確さ・根拠業務責任者が決めた期待する答えと有効な資料に照らし、誤り・不足・根拠との食い違いを記録するGood/Badや自動の採点だけで採用を決めない
回答の保留情報の不足や対象外の質問で、回答できないことを認め、確認すべき点を示せるか回答できる質問とは分けて集計する。すべてを断って高い評価にしない
人の作業時間同じ種類・難易度・範囲の業務で、今の手順とAIを使う手順の準備・確認・修正・例外対応の時間を比べるAIの応答の速さだけを削減の効果としない
処理と待ちの時間AIの処理、担当者の待ち、業務が完了するまでの経過時間を分けて記録する並行して進む時間を単純に足して、二重に数えない
費用AIの利用料、検索・保存の基盤、評価・監視・運用、人の作業など、合意した範囲の費用を記録する初期・継続・未確認の費用を分け、利用量と比較期間をそろえる
権限と許可する処理想定する利用者・資料・操作で試し、承認の前に送信や登録が起きないかを確認する指示文で禁止しただけで、アクセスを制御できたとしない
有人への引継ぎ・運用保留の理由、引継ぎ先、受領の確認、期限超過、手動での処理、停止と再開の担当を確認する通知できたことを、問い合わせが解決したこととしない

正確さは「回答できる質問」のうち基準を満たした件数、保留は「保留すべき質問」のうち適切に保留した件数として、別々に集計します。すべての質問を断れば誤った回答は出ませんが、それを合格とはしません。評価した件数、対象から除外した件数、まだ測っていない項目も一緒に示します。

完了1件あたりの費用を出す場合は、同じ期間・範囲でかかった費用を、業務として完了した件数で割ります。失敗した処理や再試行の費用も含め、下書きを作った件数を完了件数の代わりにしません。完了が0件なら算出できないと記録します。初期費用は別に示し、1件あたりに配分する場合は期間と前提を明記します。まだ確認できていない費用は0円とせず、確認できた費用の小計と分けて記録します。

RAGを使う場合の検索・回答・権限の評価は、RAGの精度評価表の質問セットを使えます。

顧客対応AIの評価例:回答と有人引継ぎを確かめる

顧客からの問い合わせにAIが回答案を作り、人が確認して送信する場合の評価例です。すべてのAI業務に同じ承認の方式が必要という意味ではありません。

▼ 顧客対応の評価例(回答案を人が確認して送信する場合)
問い合わせ・状況期待する結果記録すること
公開しているFAQにある窓口や申込みの方法有効なFAQを根拠に回答案を作る。確認者が見てから送信する根拠にしたFAQと版、誤り・不足、人の修正、送信までの時間
個別の契約による返金の可否など、資料だけでは決められないこと条件が足りないことを伝え、確認事項をまとめて担当者へ戻す。返金を約束しない保留の理由、確認事項、担当者、受領・期限・判断の結果
引継ぎ先が不在、通知が失敗した、期限を過ぎた未処理として残し、決めておいた再通知・代わりの担当・手動での対応へ進む通知の到達と受領、期限の超過、再送したときの二重対応、解決までの状態

引継ぎでは、通知を送ったこと、担当者が受け取ったこと、問い合わせが解決したことを分けて記録します。再送したときに、同じ問い合わせを二重に処理しないかも確認します。

記入例(説明用。実際の実行結果ではありません)

結果:回答案の下書きは完成し、担当者への通知も送ったが、担当者が受け取ったことは確認できていない。
判断:業務の完了とはしない。運用する範囲は広げず、引継ぎの方法を確認し直してから再試験する。

PoCから本番へ進む条件と、止める条件

評価の結果をもとに、次の4つから判断します。重大な項目(権限外の情報の開示、承認のない操作、業務上重大な誤り)は、ほかの項目の点数の平均で相殺しません。品質95%のような、すべての業務に共通する合格の数値は設けず、業務ごとに事前に決めた基準で判断します。

▼ 本番へ進む条件と止める条件
判断条件の例残す記録
対象範囲の公開・拡大を止める権限外の開示、承認のない実行、業務上重大な誤りが見つかった。または重大な項目をまだ確認できていない発生または未確認の内容、影響の範囲、封じ込めと手動での運用、再試験の担当
範囲を限って運用へ進む重大な項目の確認を終え、品質・時間・費用が事前の基準を満たし、利用者・データ・操作を限定できる承認者、対象と期限、監視と停止の条件、残る課題
追加の検証・設計の見直し回答は使えるが、修正の負担、引継ぎ、更新の反映、費用などを判断できない、または基準を満たさない変える箇所、評価ケースの版、再確認の条件
見送る人の作業や費用が増える、今の手順で足りる、受入基準を満たす構成を作れない見送りの理由と、再検討する条件

この表は判断の見本で、NISTや特定の製品が定める合格基準ではありません。重大な項目を「試験した範囲で違反0件」と記録する場合も、対象件数、条件、試験していない範囲を示し、今後も起きないとは扱いません。

本番へ進んだ後も、モデル、プロンプト、検索設定、参照資料、権限、連携を変えたときは、該当する評価ケースで再評価します。停止と再開、日常の監視、資料の更新、障害時の手動対応の担当を決めておきます。運用へ進むかどうかは、業務の責任者が判断します。

自社の状況を確認する

  • □ 監査・改善のために残す記録(入力・回答・参照資料・操作)と、保存期間・閲覧者・機密情報の扱いを決めている
  • □ 利用者の評価(Good/Badなど)は、評価表による確認とは別の参考情報として集めている
  • □ モデル・プロンプト・参照資料・権限・連携を変えたときに、該当する評価ケースで再評価している
  • □ AIモデルの更新に対応できる設計になっている
  • □ 誤った回答や事故のときに、停止・再開と手動での対応を判断する担当が決まっている
  • □ 特定の社員に、必要以上のアクセス権限(給与データの閲覧など)を与えていない
  • □ 生成した文章や画像が第三者の権利を侵害していないかを確かめる体制がある
  • □ システムの障害やAPIの停止のときに、手作業で対応する方法が決まっている
  • □ 社員向けに、AIの利用ガイドラインや倫理の研修を実施している
  • □ 費用(APIの利用料)が予算の範囲に収まっているかを定期的に確認している

生成AI導入に関するFAQ

最後に、よくいただく質問にお答えします。

押さえておきたい点

AIの導入で成果が出るかどうかは、ツールの性能よりも、業務の流れをどう組み直すかで決まります。まずは小さな業務から始め、AIに任せる部分と人が判断する部分の境目をはっきり決めておくと、その後に使う範囲を広げやすくなります。

よくある質問

Q. 社内の機密情報がAIの学習に使われませんか?

AIの学習に使われることと、データが保持されることは、分けて考えます。OpenAIのビジネス向けのサービス(API / ChatGPT Business / Enterprise)では、明示的に共有へ同意した場合を除き、原則としてお客様のデータをモデルの学習に利用しないとされています。一方で、APIの入出力は、不正利用の検知などの目的で一定期間保持される場合があります。より厳しい要件がある場合は、対象の機能やエンドポイントなどの条件付きで提供されるZero Data Retention(ZDR)を検討します。

Q. 費用はどのくらいかかりますか?

費用は、AIの利用料(従量課金や月額)、検索・保存などの基盤、評価や監視、運用の作業、人の確認・修正の時間で構成されます。一律の相場はないため、試作で利用量と人の作業時間を測り、比較する期間と範囲をそろえて、今の業務にかかっている費用と並べて判断します。

Q. 回答の精度はどのくらいですか?

業務、参照データ、質問の曖昧さによって変わるため、一律の精度は示せません。正答率に加えて、回答を適切に保留できる割合、根拠の示し方、担当者による修正の量を実際のデータで測り、重要な回答には人の確認を残します。

Q. 内製すべきか、外注すべきか?

プロンプトを書いて使う程度であれば、社内で対応できます。社内のデータを安全に連携させる仕組みづくりにはセキュリティの知識が要るため、基盤の構築は外部の専門家に任せ、日々の運用(プロンプトの調整など)を社内で担う形にすると進めやすくなります。

Q. AIガバナンスとは具体的に何ですか?

AIを正しく、安全に使うためのルールと体制をつくることです。情報漏洩への対策に加えて、差別的な出力をさせないこと、著作権を守ること、AIの判断の結果に人が責任を持つことなど、倫理面・法律面の規程の整備も含まれます。

試作を、業務で使えるか判断します。

評価表の項目や、本番へ進む条件を社内で決めきれない場合は、AI・RAGの評価と本番移行の支援内容をご確認ください。初回相談では課題と範囲を確認し、有料の支援は対象と実際に試すかどうか、成果物を決めてお見積もりします。

AIの評価・本番移行の支援内容を見る

IT課題を、
優先順位から整理します。

Malakeは外部IT責任者として、現状の確認から実装・運用まで支援します。