業務プロセスにAIを組み込む5つのパターン
「ChatGPTを全社契約したのに、使っているのは一部の社員だけ」。AI自動化の相談で、いちばんよく聞く話です。原因はツールの性能ではなく、業務プロセスのどこに組み込むかが決まっていないことです。私たちが自社と案件の両方で確かめてきた組み込みパターンを、5つに整理しました。
「AI導入」という案件を立てない
試験導入が止まる理由のほとんどは、技術ではありません。「AIで何かやってみよう」という案件の立て方に原因があります。デモまでは作れます。ただ、誰のどの作業が何分減るのかを誰も言えないため、その先に進みません。
私たちは社内で、「AI導入」を目的にした案件を立てないことにしています。立てるのは「請求書の転記をなくす」「問い合わせの一次回答を自動にする」という、業務の言葉の案件です。この言い換えだけで、成功条件が「動いた」から「工数が減った」に変わります。
パターン1:問い合わせ対応・社内ナレッジ検索
社内規程やマニュアルを読み込ませて回答させる構成です。RAG(検索拡張生成)と呼ばれます。最初の一歩に選ばれることが多い領域ですが、運用を始めると精度への不満が出ます。調べていくと、その大半はAIではなくドキュメント側の問題です。同じ質問に対して矛盾する規程が2つある。改訂日が書かれていない。最新版がどれか誰も知らない。RAGを入れると、ドキュメントの不備がそのまま回答の不備として表に出ます。
マニュアル
(ベクトルDB)
回答を生成
提示
だからこの種の案件では、見積もりの半分をドキュメント整備に充てています。長年手つかずだった文書整理が「AI導入」をきっかけに進む、という副次的な効果もあります。
パターン2:帳票・文書の読み取りと転記
請求書や申請書を読み取って、基幹システムへ転記する業務です。書式が揃っていない帳票は従来のOCRでは読み取れませんでしたが、LLMと組み合わせると書式のばらつきをかなり吸収できます。
設計では全自動を狙いません。AIが下書きを作り、人が確認して確定します。それでも、ゼロから入力する場合と比べれば作業時間は大きく減ります。逆に、最初から99%の精度が必要な業務(経理の仕訳確定など)を対象に選ぶと、検収条件を満たせず先に進めなくなります。
(PDF・画像)
下書きを作成
して確定
登録
パターン3:議事録とナレッジの構造化
文字起こしと要約だけなら、既製ツールで足ります。開発の出番はその先にあります。決定事項と宿題を抽出して、タスク管理ツールへの起票まで自動でつなぐ部分です。議事録は作られるのに誰も読まない、という状態が、決まったことがタスクとして登録され実行される状態に変わります。
この接続部分は各社の業務システムに依存するため、個別の作り込みが必要です。
パターン4:定型判断への組み込み
対象になるのは、審査の一次チェックや問い合わせの仕分け、申請内容の不備確認です。判断基準を言語化できる業務に、AIを一次判定として組み込みます。最終判断は人に残します。
失敗する案件には共通点があって、最初から全部を任せようとします。任せる範囲を絞って人の確認を残した設計のほうが、現場に受け入れられ、結果として自動化できる範囲は広がります。
パターン5:開発・運用プロセスそのもの
私たち自身がいちばん効果を実感しているのはここです。例を一つ挙げると、いまご覧いただいているこのサイトは、エンジニアとAIコーディングエージェント(Claude Code)の対話で開発・運用しています。ページの追加も、SEOの改善も、問い合わせフォームの不具合調査も、人間が方針を決め、AIが実装し、人間が確認してリリースしています。
提案書の論点整理や設計レビューにも毎日使っています。社内で日常的に使っているため、お客様への提案も「ツールを入れましょう」ではなく「この工程のこの作業に組み込みましょう」という具体的な話から始められます。
進め方
順番が決まっています。最初に業務を棚卸しして、繰り返しが多く判断基準を言語化できる工程を探します。次に1つの業務に絞って試行し、作業時間がどれだけ減るかを数字で確かめます。効果が確認できたら既存システムやデータと接続して本番に組み込み、利用状況を見ながら定着させます。
ツールの選定から入った案件は、高い確率で止まります。モデルは数か月で入れ替わるため、特定のモデルを前提にした設計にもしません。複数のLLMを使い分ける段階になると、コストと利用状況の管理が次の課題になります。この領域は AI Gateway という仕組みで解決できます。
社内ツール
ログ・プロンプト保護
Gemini/社内モデル