生成AIを 業務へ 組み込む 方法: 対象業務の 選定から 運用まで
まず押さえたいこと生成AIの業務組み込みとは、入力、処理、確認、保存までの業務の流れにAIを配置し、人が判断する箇所を残して進めることです。対象業務を選び、期待する結果とAIに許可する処理を決めてから試作を評価し、限定した範囲で運用するかを判断します。
この記事の要点
生成AIの導入の効果は、契約したツールの数ではなく、業務の結果がどう変わったかで判断します。最初は要約・分類・下書きなど、人が確認できる業務を選び、期待する結果、AIに許可する処理、確認者と失敗時の戻し方を決めます。試作では、回答の品質と根拠、人の確認・修正の時間、費用、有人への引継ぎを今の手順と比べて評価します。重大な誤りや権限外の処理がないことを確かめてから、範囲を限って運用へ進めます。
この 記事で わかる こと
- 生成AIに
任せる 業務の 選び方と、 試作の 前に 決める こと - PoCの
評価表で、 品質・人の 作業時間・ 費用・ 権限を 確かめる 方法 - 顧客対応で、
回答の 保留と 有人への 引継ぎを 評価する 観点 - PoCの
結果から、 範囲を限って 運用へ進むか、 検証を続けるか、 見送るかを 決める条件
「チャット導入」と 「業務組み込み」の 決定的違い
企業の
- 段階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が、文字認識(OCR)や翻訳のように用途が決まった作業には、その用途向けのAIや既存のツールが合う場合があります。どちらが合うかは、費用や精度の一般的な比較だけでは決まりません。対象業務と今の手順、誤りが起きたときの影響、運用・保守の負担を比べて決めます。生成AIを使わず、既存のルールや仕組みで足りる業務もあります。
対象の
- 頻度:毎日のように
発生する 業務か。 たまに しか 行わない 業務は、 自動化しても 費用に 見合う 効果が 出に くくなります。 - 効果:
自動化で、 どの くらいの 作業時間を 減らせるか。 - リスク:誤りが
あった ときの 影響は どの くらいか。 顧客へ 直接回答する 業務は 影響が 大きく、 社内向けの 要約は 比較的小さくなります。
あわせて、
つまずきやすい 点
よくあるつまずきは、AIに100%の精度を求めてしまうことです。生成AIの出力には、一定の割合で誤りが含まれます。人が確認・修正する手順(Human-in-the-loop)を前提に組み込んでおかないと、誤りを恐れて業務で使えない仕組みになりがちです。
1. 頻度 (Frequency)
毎日発生する定型業務か?
(低頻度ならROIが出にくい)
2. 効果 (Effect)
自動化で何時間削減できるか?
(インパクトの大きさ)
3. リスク (Risk)
間違った時のダメージは?
(社外向けは高リスク)
(慎重に検討)
必須領域
(ROI低)
Human-in-the-loop (人間参加型) を前提とすることで、
本来リスクが高い領域も、安全に自動化の恩恵を受けることが可能になります。
頻度が高く、
RAG(検索拡張生成) による 自社データ活用
ChatGPTなどの生成AIは、そのままでは自社の社内規程や顧客情報を知りません。これらを参照させる方法の一つがRAG(Retrieval-Augmented Generation、検索拡張生成)です。
たとえば「就業規則について教えて」と聞くと、まず社内の資料を検索して関連する規定を取り出し、その内容を根拠として回答を作ります。ただし、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、
入力 (質問・依頼)、 利用者の 役割と 権限 - 参照した
資料と、 モデル・プロンプト・ 検索設定の 版 - 期待する
結果と 実際の 結果、 誤り・ 不足の 分類 - 人の
作業時間・ 経過時間・ 費用 - 判断
(合否)、 未確認の 事項、 再試験の 担当
集計は、
| 評価する | 確かめ方・記録 | 判断時の |
|---|---|---|
| 回答の | 業務責任者が | Good/Badや |
| 回答の | 情報の | 回答できる |
| 人の | 同じ | AIの |
| 処理と | AIの | 並行して |
| 費用 | AIの | 初期・ |
| 権限と | 想定する | 指示文で |
| 有人への | 保留の | 通知できた |
正確さは「回答できる質問」のうち基準を満たした件数、保留は「保留すべき質問」のうち適切に保留した件数として、別々に集計します。すべての質問を断れば誤った回答は出ませんが、それを合格とはしません。評価した件数、対象から除外した件数、まだ測っていない項目も一緒に示します。
完了1件あたりの費用を出す場合は、同じ期間・範囲でかかった費用を、業務として完了した件数で割ります。失敗した処理や再試行の費用も含め、下書きを作った件数を完了件数の代わりにしません。完了が0件なら算出できないと記録します。初期費用は別に示し、1件あたりに配分する場合は期間と前提を明記します。まだ確認できていない費用は0円とせず、確認できた費用の小計と分けて記録します。
RAGを
顧客対応AIの 評価例: 回答と 有人引継ぎを 確かめる
顧客からの
| 問い合わせ・状況 | 期待する | 記録する |
|---|---|---|
| 公開している | 有効な | 根拠に |
| 個別の | 条件が | 保留の |
| 引継ぎ先が | 未処理として | 通知の |
引継ぎでは、通知を送ったこと、担当者が受け取ったこと、問い合わせが解決したことを分けて記録します。再送したときに、同じ問い合わせを二重に処理しないかも確認します。
記入例
結果:回答案の下書きは完成し、担当者への通知も送ったが、担当者が受け取ったことは確認できていない。
判断:業務の完了とはしない。運用する範囲は広げず、引継ぎの方法を確認し直してから再試験する。
PoCから 本番へ 進む条件と、 止める条件
評価の結果をもとに、次の4つから判断します。重大な項目(権限外の情報の開示、承認のない操作、業務上重大な誤り)は、ほかの項目の点数の平均で相殺しません。品質95%のような、すべての業務に共通する合格の数値は設けず、業務ごとに事前に決めた基準で判断します。
| 判断 | 条件の | 残す記録 |
|---|---|---|
| 対象範囲の | 権限外の | 発生または |
| 範囲を | 重大な | 承認者、 |
| 追加の | 回答は | 変える |
| 見送る | 人の | 見送りの |
この表は判断の見本で、NISTや特定の製品が定める合格基準ではありません。重大な項目を「試験した範囲で違反0件」と記録する場合も、対象件数、条件、試験していない範囲を示し、今後も起きないとは扱いません。
本番へ進んだ後も、モデル、プロンプト、検索設定、参照資料、権限、連携を変えたときは、該当する評価ケースで再評価します。停止と再開、日常の監視、資料の更新、障害時の手動対応の担当を決めておきます。運用へ進むかどうかは、業務の責任者が判断します。
自社の状況を確認する
- □ 監査・改善の
ために 残す記録 (入力・ 回答・ 参照資料・ 操作)と、 保存期間・ 閲覧者・ 機密情報の 扱いを 決めている - □ 利用者の
評価 (Good/Badなど)は、 評価表に よる 確認とは 別の 参考情報として 集めている - □ モデル・プロンプト・
参照資料・ 権限・ 連携を 変えた ときに、 該当する 評価ケースで 再評価している - □ AIモデルの
更新に 対応できる 設計に なっている - □ 誤った
回答や 事故の ときに、 停止・再開と 手動での 対応を 判断する 担当が 決まっている - □ 特定の
社員に、 必要以上の アクセス権限 (給与データの 閲覧など)を 与えていない - □ 生成した
文章や 画像が 第三者の 権利を 侵害していないかを 確かめる 体制が ある - □ システムの
障害や APIの 停止の ときに、 手作業で 対応する 方法が 決まっている - □ 社員向けに、
AIの 利用 ガイドラインや 倫理の 研修を 実施している - □ 費用
(APIの 利用料)が 予算の 範囲に 収まっているかを 定期的に 確認している
生成AI導入に 関する FAQ
最後に、
押さえておきたい点
よく ある 質問
Q. 社内の
AIの学習に使われることと、データが保持されることは、分けて考えます。OpenAIのビジネス向けのサービス(API / ChatGPT Business / Enterprise)では、明示的に共有へ同意した場合を除き、原則としてお客様のデータをモデルの学習に利用しないとされています。一方で、APIの入出力は、不正利用の検知などの目的で一定期間保持される場合があります。より厳しい要件がある場合は、対象の機能やエンドポイントなどの条件付きで提供されるZero Data Retention(ZDR)を検討します。
Q. 費用は
費用は、AIの利用料(従量課金や月額)、検索・保存などの基盤、評価や監視、運用の作業、人の確認・修正の時間で構成されます。一律の相場はないため、試作で利用量と人の作業時間を測り、比較する期間と範囲をそろえて、今の業務にかかっている費用と並べて判断します。
Q. 回答の
業務、参照データ、質問の曖昧さによって変わるため、一律の精度は示せません。正答率に加えて、回答を適切に保留できる割合、根拠の示し方、担当者による修正の量を実際のデータで測り、重要な回答には人の確認を残します。
Q. 内製すべきか、
プロンプトを書いて使う程度であれば、社内で対応できます。社内のデータを安全に連携させる仕組みづくりにはセキュリティの知識が要るため、基盤の構築は外部の専門家に任せ、日々の運用(プロンプトの調整など)を社内で担う形にすると進めやすくなります。
Q. AIガバナンスとは
AIを正しく、安全に使うためのルールと体制をつくることです。情報漏洩への対策に加えて、差別的な出力をさせないこと、著作権を守ること、AIの判断の結果に人が責任を持つことなど、倫理面・法律面の規程の整備も含まれます。
試作を、 業務で 使えるか 判断します。
評価表の項目や、本番へ進む条件を社内で決めきれない場合は、AI・RAGの評価と本番移行の支援内容をご確認ください。初回相談では課題と範囲を確認し、有料の支援は対象と実際に試すかどうか、成果物を決めてお見積もりします。