業務別 AI自動化の進め方 — 経理・サポート・PM ほか6業務の実装パターン

2026.06.15 ・ 約14分で読めます

「うちの業務、AIで自動化できるんだろうか」。AI自動化の相談で最初に聞かれるのは、たいていこの問いです。一般論を読んでも判断が付かないことが多いので、私たちが実装してきた6つの業務シナリオを、構成図・技術スタック・人の介入ポイント・工数の目安・落とし穴まで含めて並べます。

どの業務でも共通しているのは、AIに全部任せる設計にしないことです。下書きや候補出しまでをAIが担い、最終確定は人が行う。この線をどこに引くかが、業務に定着するかどうかを分けます。

6業務の早見表

各業務の特徴・人が残す役割・想定工数を並べます。自社の業務がどれに近いかを見つけて、該当章に進んでください。

業務特徴人が残す役割想定工数
経理:請求書/領収書定型・繰返しが多い下書きの確認・確定3〜4ヶ月
カスタマーサポートFAQ準備済みなら早い回答送付の最終判断2〜3ヶ月
プロジェクト管理音声品質に依存タスク化判断と割当1〜2ヶ月
バックオフィス判断ルール言語化が前提承認・差戻し2〜3ヶ月
営業提案書テンプレあり前提ストーリーと数字の最終調整1〜2ヶ月
エンジニアリング継続的な組み込みマージと本番反映1ヶ月〜継続
表1:6業務の早見表。どれも「人の確認を設計に残す」点は共通しています。

経理:請求書・領収書の読み取りと転記

月末に紙とPDFが届く。会計システムへの手入力で残業が発生し、ミスも避けられない。経理担当が月40時間以上をこの作業に取られている、というのは典型的な相談です。

INPUT
請求書PDF
領収書画像
AI
項目を抽出し
仕訳の下書きを作成
HUMAN
担当者が確認
修正して確定
SYSTEM
会計システムへ
登録(API/CSV)
図1:請求書・領収書の読み取りと転記のフロー
項目内容
技術スタックLLMによる文書理解(Claude / GPT-4o)、Bedrock / Vertex AI、社内データベース、freee / マネーフォワード等の会計API
人の介入AIが作る下書きを担当者が確認して確定する。完全自動化は狙わない
工数の目安3〜4ヶ月(試験導入を含む)。書式バリエーション数で変動
落とし穴請求書の書式が極端に多い、手書きが混ざる、押印が必須など、要件が99%精度を求める領域は対象を絞らないと検収で詰まる

カスタマーサポート:問い合わせの一次対応とFAQ自動回答

同じ質問が繰り返し届く。FAQページは整備したが、お客様は読まずに問い合わせてくる。一次対応の時間が膨らみ、本当に対応が必要な相談に手が回らない、という状況です。

INPUT
問い合わせ
(メール / フォーム)
AI
社内FAQ・規程を
検索して回答案作成
HUMAN
オペレーターが確認
送信
CRM
対応履歴を
記録
図2:問い合わせの一次対応とFAQ自動回答のフロー
項目内容
技術スタックRAG(検索拡張生成)、ベクトルデータベース(Pinecone / pgvector)、Slack / Zendesk / メールAPI、Kong AI Gateway によるコスト管理
人の介入AIが回答案を作る、オペレーターが「送る/修正する/専門担当に回す」を判断
工数の目安2〜3ヶ月、FAQ整備の状態で大きく変動
落とし穴元のFAQ・規程に矛盾や古い記述があると、回答もそのまま矛盾する。導入工数の半分はドキュメント整備に充てる前提

プロジェクト管理:議事録から決定事項とタスク自動起票

会議は録音されている。議事録もAIが起こしてくれる。でも、決定事項とタスクは誰かが拾って起票しないと動かない。議事録は作られるのに誰も読まない、やると決まったはずなのに実行されない、という状態です。

INPUT
会議音声
(Zoom / Teams)
AI
文字起こし+
決定/宿題を抽出
HUMAN
PMが内容を確認
担当者を割当て
SYSTEM
Notion / Jira /
Asana へ起票
図3:議事録から決定事項とタスク自動起票のフロー
項目内容
技術スタック音声→テキスト(Whisper等)、Claude / GPT による要約と抽出、タスク管理API(Notion / Jira / Asana)
人の介入PMが「これはタスク化する/しない」を確認し、担当者と期日を決める。AIの抽出を鵜呑みにしない
工数の目安1〜2ヶ月、業務システムとの接続に依存
落とし穴音声品質が低い・複数人の声が重なる・専門用語が多いと精度が落ちる。会議の運用ルール(発言者を明示する等)も含めた設計が要る

バックオフィス:稟議・申請の不備チェックと仕分け

稟議書や申請書を受け取り、内容を確認し、必要な部署に回付する。判断基準は言語化できるのに、担当者の経験に依存していて属人化しがちな業務です。

INPUT
稟議・申請書類
(社内システム)
AI
項目チェック+
仕分け先を提案
HUMAN
担当者が承認
または差戻し
SYSTEM
ワークフロー
に進行
図4:稟議・申請の不備チェックと仕分けのフロー
項目内容
技術スタック既存ワークフローシステムのAPI連携、LLM(Claude / GPT)、業務ルールベースのバリデーション
人の介入AIは「不備チェック」と「仕分け先候補」を出すだけ。最終判断は人が残す
工数の目安2〜3ヶ月、業務ルールの整理に依存
落とし穴判断ルールが暗黙知で言語化されていない場合、要件定義に想定以上の時間がかかる。ルールを言語化すること自体が価値になる

営業:提案書の論点整理と顧客別カスタマイズ

既存の提案書テンプレートを顧客に合わせて書き直す作業に時間が取られる。営業担当が個人で工夫しているため、品質にばらつきがあり、ナレッジも蓄積されない。

INPUT
顧客情報+
過去の提案資料
AI
論点整理+
提案書ドラフト生成
HUMAN
営業が読み込み
修正・確定
OUTPUT
顧客向け
提案書
図5:提案書の論点整理と顧客別カスタマイズのフロー
項目内容
技術スタックClaude / GPT、社内ナレッジベース、CRM(Salesforce / HubSpot)API、社内提案書テンプレート
人の介入AIが叩き台を作り、営業がストーリーと数字を最終調整する。人が書いたことが価値になる場面では使い分け
工数の目安1〜2ヶ月、ナレッジ整備の状態で変動
落とし穴ハルシネーション(事実誤認)が顧客向け資料に混ざると致命的。チェックポイントを明示的に設計する

エンジニアリング:コードレビューと運用手順書の整備

私たち自身が日常的に使っている領域です。コーディングエージェントが Pull Request を作る、レビューの観点を整理する、運用手順書を最新状態に保つ。実装速度よりも、レビューと文書化の手間が減ることのほうが大きい効果です。

INPUT
Pull Request
変更内容
AI
観点別レビュー+
手順書差分提案
HUMAN
エンジニアが
判断・マージ
OUTPUT
本番反映+
手順書更新
図6:コードレビューと運用手順書の整備のフロー
項目内容
技術スタックClaude Code、GitHub Actions、内部Wiki/Notion、IaC(Terraform)
人の介入AIの提案は「レビューの観点出し」「ドラフト生成」までで、マージ判断と本番反映は人が必ず行う
工数の目安1ヶ月〜、開発体制への組み込みは継続的
落とし穴AIが書いたコードが動くが意図と違う状態が起きる。テスト戦略と監視を先に整える

業務を選ぶ時の判断軸

6業務を並べましたが、どこから手をつけるかは組織の状況で変わります。私たちが顧客と最初に整理する判断軸を3つ示します。

(1) 「人の確認」が許容される業務か。AIに全部任せられる業務は実はかなり限定的です。経理・営業の最終確定など、人の判断を残す設計にして自然な業務は、定着しやすい順番が上です。

(2) 入力データの整備状況。RAG系(カスタマーサポート・バックオフィス)は元ドキュメントの状態が成果を決めます。整備が進んでいない場合、AI導入の半分の工数はドキュメント整備になります。これを見積もりに織り込んでいない案件は、本番直前で詰まります。

(3) 工数削減の見える化が可能か。AI自動化の効果は「○○の作業時間が×時間減った」で測ります。逆に言えば、現状の作業時間を測れていない業務は、効果が測れず継続予算が付きません。先に作業時間を計測する仕組みを入れるのが、結果として近道です。

これら3軸でスコアリングして優先順位を決めると、最初の試験導入が成功しやすくなります。私たちは試験導入の段階で成功条件を数字で先に決めることを必ずやります。動くものができたから成功ではなく、◯時間削減できたら成功、という基準です。

自社の業務、どの業務から手をつけるか一緒に整理しませんか。
業務の棚卸しから、優先順位付け、試験導入の設計まで日本語で担います。
AI・自動化の導入支援を見る
相談する →