業務プロセスにAIを組み込む5つのパターン

2026.06.10 ・ 約6分で読めます

「ChatGPTを全社契約したのに、使っているのは一部の社員だけ」。AI自動化の相談で、いちばんよく聞く話です。原因はツールの性能ではなく、業務プロセスのどこに組み込むかが決まっていないことです。私たちが自社と案件の両方で確かめてきた組み込みパターンを、5つに整理しました。

「AI導入」という案件を立てない

試験導入が止まる理由のほとんどは、技術ではありません。「AIで何かやってみよう」という案件の立て方に原因があります。デモまでは作れます。ただ、誰のどの作業が何分減るのかを誰も言えないため、その先に進みません。

私たちは社内で、「AI導入」を目的にした案件を立てないことにしています。立てるのは「請求書の転記をなくす」「問い合わせの一次回答を自動にする」という、業務の言葉の案件です。この言い換えだけで、成功条件が「動いた」から「工数が減った」に変わります。

パターン向いている業務人の役割つまずきやすい点
1. 問い合わせ・ナレッジ検索答えが文書のどこかに書いてある問い合わせ回答の確認とドキュメント整備元ドキュメントの不備がそのまま回答に出る
2. 帳票・文書処理書式がばらつく帳票の読み取りと転記下書きの確認・確定99%精度が前提の業務を選ぶと進まない
3. 議事録の構造化会議の決定事項のタスク化起票内容の確認文字起こしだけでは既製ツールと差が出ない
4. 定型判断仕分け・一次チェック・不備確認最終判断最初から全部任せる設計は受け入れられない
5. 開発・運用プロセス実装・レビュー・手順書整備方針決定とレビュー方針を決めずにツールだけ入れると定着しない
表1:5つのパターンと人の役割。どのパターンも、人の確認を設計に残すことが前提です。

パターン1:問い合わせ対応・社内ナレッジ検索

社内規程やマニュアルを読み込ませて回答させる構成です。RAG(検索拡張生成)と呼ばれます。最初の一歩に選ばれることが多い領域ですが、運用を始めると精度への不満が出ます。調べていくと、その大半はAIではなくドキュメント側の問題です。同じ質問に対して矛盾する規程が2つある。改訂日が書かれていない。最新版がどれか誰も知らない。RAGを入れると、ドキュメントの不備がそのまま回答の不備として表に出ます。

SOURCE
社内規程
マニュアル
SEARCH
検索基盤
(ベクトルDB)
LLM
該当箇所をもとに
回答を生成
OUTPUT
回答+出典の
提示
図1:RAG構成の基本形です。回答の品質は、LLMよりも検索と元ドキュメントの状態で決まります。

だからこの種の案件では、見積もりの半分をドキュメント整備に充てています。長年手つかずだった文書整理が「AI導入」をきっかけに進む、という副次的な効果もあります。

パターン2:帳票・文書の読み取りと転記

請求書や申請書を読み取って、基幹システムへ転記する業務です。書式が揃っていない帳票は従来のOCRでは読み取れませんでしたが、LLMと組み合わせると書式のばらつきをかなり吸収できます。

設計では全自動を狙いません。AIが下書きを作り、人が確認して確定します。それでも、ゼロから入力する場合と比べれば作業時間は大きく減ります。逆に、最初から99%の精度が必要な業務(経理の仕訳確定など)を対象に選ぶと、検収条件を満たせず先に進めなくなります。

INPUT
帳票
(PDF・画像)
AI
項目を抽出し
下書きを作成
HUMAN
人が確認・修正
して確定
SYSTEM
基幹システムへ
登録
図2:帳票処理の流れです。3つ目の「人の確認」を省かない設計が、このパターンの前提になります。

パターン3:議事録とナレッジの構造化

文字起こしと要約だけなら、既製ツールで足ります。開発の出番はその先にあります。決定事項と宿題を抽出して、タスク管理ツールへの起票まで自動でつなぐ部分です。議事録は作られるのに誰も読まない、という状態が、決まったことがタスクとして登録され実行される状態に変わります。

この接続部分は各社の業務システムに依存するため、個別の作り込みが必要です。

パターン4:定型判断への組み込み

対象になるのは、審査の一次チェックや問い合わせの仕分け、申請内容の不備確認です。判断基準を言語化できる業務に、AIを一次判定として組み込みます。最終判断は人に残します。

失敗する案件には共通点があって、最初から全部を任せようとします。任せる範囲を絞って人の確認を残した設計のほうが、現場に受け入れられ、結果として自動化できる範囲は広がります。

パターン5:開発・運用プロセスそのもの

私たち自身がいちばん効果を実感しているのはここです。例を一つ挙げると、いまご覧いただいているこのサイトは、エンジニアとAIコーディングエージェント(Claude Code)の対話で開発・運用しています。ページの追加も、SEOの改善も、問い合わせフォームの不具合調査も、人間が方針を決め、AIが実装し、人間が確認してリリースしています。

提案書の論点整理や設計レビューにも毎日使っています。社内で日常的に使っているため、お客様への提案も「ツールを入れましょう」ではなく「この工程のこの作業に組み込みましょう」という具体的な話から始められます。

私たちが社内で日常的に使っている主なスタックです。
Claude Code Anthropic API Amazon Bedrock Vertex AI GitHub Actions Terraform Kong AI Gateway

進め方

順番が決まっています。最初に業務を棚卸しして、繰り返しが多く判断基準を言語化できる工程を探します。次に1つの業務に絞って試行し、作業時間がどれだけ減るかを数字で確かめます。効果が確認できたら既存システムやデータと接続して本番に組み込み、利用状況を見ながら定着させます。

01
業務の棚卸し
繰り返しが多く、判断基準を言語化できる工程を探します。
02
1業務で試行
作業時間がどれだけ減るかを数字で確かめます。
03
本番に組み込み
既存システム・データと接続します。
04
定着
利用状況を見ながら対象業務を広げます。
図3:進め方の4段階です。ツールの選定は、効果を数字で確かめたあとで行います。

ツールの選定から入った案件は、高い確率で止まります。モデルは数か月で入れ替わるため、特定のモデルを前提にした設計にもしません。複数のLLMを使い分ける段階になると、コストと利用状況の管理が次の課題になります。この領域は AI Gateway という仕組みで解決できます。

APPS
業務アプリ
社内ツール
Kong
AI Gateway
認証・コスト管理
ログ・プロンプト保護
MODELS
Claude/GPT
Gemini/社内モデル
図4:複数のLLMを使い分ける段階の構成です。アプリとモデルの間にゲートウェイを挟み、利用を一元管理します。
自社の業務のどこでAIの効果が出るか、一緒に整理しませんか。
「何から始めればいいか分からない」段階からご相談いただけます。
AI・自動化の導入支援を見る
相談する →