Upgrade to Pro — share decks privately, control downloads, hide ads and more …

AI活用をPoCで終わらせないためのアンチパターン

 AI活用をPoCで終わらせないためのアンチパターン

2025年11月13日(木)開催のラクスルさん主催「AI活用をPoCで終わらせない ─ 実用化に導くシステム・組織・オペレーション設計」イベントのLT登壇資料です。
19年くらいからの数多くのAIプロジェクトを実施した経験からPoCで終わらせないためのアンチパターンをまとめています
イベントページ:https://raksul.connpass.com/event/373594/

Avatar for KentaroFujii

KentaroFujii

November 13, 2025
Tweet

More Decks by KentaroFujii

Other Decks in Technology

Transcript

  1. 2 登壇者 藤井 謙太郎 Fujii, Kentaro 株式会社kubell インキュベーションディビジョン R&Dユニット 新卒で富士通株式会社に入社。基幹システムやERP導入などのプログラマやプロジェクト管理

    を経験し、PwCコンサルティングで金融機関向け経営管理プロジェクトに従事。 Laboro.AIにてAIを活用したアプリ開発やAI受託開発、カメラやIoTなどを活用した事業開発お よび戦略策定コンサルティングを主導、執行役員に就任し全社売上責任を担当。 2024年4月株式会社kubell(当時 Chatwork株式会社)に入社、AI分野における新規事業の推 進とR&D領域を担当。 自然言語を用いたレコメンドや画像関連の新規事業、AIコンサルなどが得意 様々な業界でAI関連のプロジェクトを50程度実行。企画は100くらい。 直近は経理業務とシステム経験からAIエージェントに注力 AIエージェントのエンジニア、AWS運用など何でも屋化が激しい最近 ふじい  けんたろう (@kentaro_fujii_)
  2. 3 事業概要 • 国内最大級のビジネスチャット「Chatwork」を展開。業界のパイオニアであり国内利用者数No.1*1、導入社数は93.5万社*2を突破 • 圧倒的な顧客基盤のあるプラットフォームを背景に、チャット経由で業務を請け負いDXを推進するBPaaSを展開  ビジネスチャット「Chatwork」 BPaaS (Business Process

    as a Service) • 国内利用者数No.1*1 有料ユーザーの97%が中小企業ユーザー • 日本の1/5を占める導入社数93.5万社以上*2 775万ユーザー • 全業界・全職種の方が日常的に使うプラットフォーム *1 Nielsen NetView 及びNielsen Mobile NetView Customized Report 2024年4月度調べ月次利用者(MAU:Monthly Active User)調査。 調査対象はChatwork、Microsoft Teams、Slack、LINE WORKS、Skypeを含む41サービスを株式会社kubellにて選定。 *2 2025年6月末時点 チャット経由で業務を請け負いDXを推進 業務代行 経理・総務・事務な ど幅広い業務に対応 人事・労務など専門 性の高い業務に対応 採用 経理・会計 労務 営業事務 AI・SaaSを徹底活用
  3. 4 AIエージェント群 サービスの構成イメージ例 アシスタント業務実行 AI OCR 経費精算 エージェント 請求書処理 エージェント

    ユーザー照会 サービス基盤 用途別OCR ワークフロー エージェント実行/ 結果確認/結果修正 OCR実行/ 結果確認/結果修正 顧客別の業務実行 業務状況確認 取引先管理 実行履歴 認証・認可 ステート管理 依頼内容照会 電帳法 / 証跡 BPaaSサービスは、アシスタントが「業務をいかに効率的に実行できるか」がポイント SaaSやチャット型のAIエージェントと異なり「アシスタントの業務環境」が必要
  4. 6 AI活用がPoCで終わるとは?(一般例) 本来のPoC 現実のPoCで発生しやすいつまずき PoCとは? • 目的を持った実現性・価値の確認 例:事業性PoC/コストPoC/ニーズ検証 PoC/技術実現性PoC/組織導入PoC など

    位置づけ(理想) • 施策の連続線の一部 「課題整理 → 仮説 → 検証(PoC)→ 小さく 本番 → 運用 → 改善」 成功への取り組み • 目的と成功基準を事前合意 • Exit条件(Go / Hold / No-Go)を明文化 • 本番移行の最小計画(担当・予算・期日)を 用意 目的がぼんやり • 「何を確かめるか」が曖昧で、判断材料が散 らばりがち • 成功可否を決める意思決定者の関与が薄い 期待のズレ • 「他社もやっているから」という着手で、期 待値が合いにくい 車輪PoC化 • 資料は残るが試行の癖がつかない(実験プロ セスに不慣れ) • 担当部門の中で完結し、運用や他部門の課題 に接続しづらい PoCで止まる=学びは得ているが、 事業・運用への接続が見えにくい状態
  5. 8 アンチパターンの大別 ユースケースに過剰最適 目的・指標の整理不足 大作思考 運用体制が不在 PoCと本導入のつながり不足 オーナーの不在 トップとボトムの断絶 プロセスを変えない

    当事者不在(やらされ感) 組織横断の壁 特定技術活用にこだわる 完全自動化を目指す 技術関連 運用・組織 プロジェクト・施策構造 取り組み方の問題 受け皿の問題 作り方の問題 1 2 3
  6. 9 代表的アンチパターン① 〜プロジェクト・施策構造〜 目的・指標の整理不足 PoCと本導入のつながり不足 トップとボトムの断絶 • ふわっとPoC:何を確かめる か/誰が判断するかが未定。 終わらないPoCの出現 •

    指標のバランス:ROIや精度 などの評価指標にこだわって はいけないが、ないのもNG • WF型回避:前提に変更が あった際の更新方針がない • やらないこと定義:捨てる内 容が未議論 • とりあえずPoCはNG 考えすぎるPoCもNG • 運用体制:体制・スキル・工 数・セキュリティ等の前提が 設計に入っていない • 終了条件:PoC終了後の移行 条件(Go / Hold / No-Go) が未合意 • 車輪PoC:知見が担当者に依 存し、交代でリセットされや すい • トップダウンすぎてもNG ボトムアップすぎてもNG • 実行体制:トップ不在は組織 が動かない。AI推進・DX推進 の権限不足に陥る • 一方向の号令の齟齬:生産性 倍増!!と打ち出すと 倍増のもの以外取り組まない • サポート不足:業務と並行し た改善する現場サポート不足 • AI疲れ:一方的なトップダウ ンによるAI疲れ ゴールと評価軸の明確化が不足 検証から運用への橋渡しが弱い 目的共有と権限設計が薄い
  7. 10 代表的アンチパターン② 〜運用・組織〜 当事者不在 プロセスを変えない 組織横断の壁 • 現場任せもNG 横断チーム任せもNG • 意思決定:賛否が割れる場面

    で、意思決定者の判断がされ ない • 当事者意識:自分ごと化が弱 く、自分の案件と思っていな い • 納得感:全体像や意義の共有 不足から「やらされ感」が生 まれる • 現場プロセス無視はNG 変えないもNG • プロセス変更:理由がある現 場プロセスへの尊重、変更が 必要なケース両立が弱い • 意思決定:小さなプロセス変 更を即時に決める体制が不足 • 完全自動化:“AIが現場に合 わせ切る”前提や、全面置換 の期待が混在 • AI実現度:AI改善と運用対応 (例:95→96%)議論不足 • 推進組織メンバーが横並びに なりがち • カルチャー:異なるカル チャーの橋渡しが弱い • リテラシー:リテラシーの段 差により、できること・でき ないこと、言葉が壁になる • 役割:既存組織(情シス 等) と推進組織の棲み分けが曖昧 意思決定者の関与が薄く、 誰の施策かが曖昧 小さな意思決定と 変更ルールが不足 推進組織と業務組織の ロールのずれ
  8. 11 代表的アンチパターン③ 〜技術関連〜 ユースケースに過剰最適 大作思考 特定技術活用にこだわる • 特定ケースだけで成立し、業 務汎用性が低い • 実現レベル×運用負荷のト

    レードオフ評価が不足 • 業務側の変更可能性ポイント の検討が不足 • 検証ユースケースのバリエー ション不足 • 評価環境と本番環境の差分を 見落とす • AIができることがそこまでな いことへの誤解 • ITナレッジ:導入にはAI以外 のシステム/運用リテラシー が必要 • 複雑化:誰にも運用できない 大作になり、変更に弱い • やりたい事重視:インパクト 先行で、実際の価値が薄い • ガナバンス:安全性・監査性 ・観測性の設計が不足 • AIでなくてもよい課題にAIを 当てようとする • AIエージェント/LLMだから という理由で選定AIエージェ ントにこだわる • 技術ありきで要件が後追いに なる • 社内に運用能力がない技術の 採用(ベンダ依存・特定のハ イスキル) 汎用性が低く 本番運用を見据えない AIへの過大期待 実装と運用が肥大化 手段先行で 目的と運用能力の整合が薄い
  9. 13 どうすれば良いか 技術関連 運用・組織 プロジェクト・施策構造 1 2 3 元も子もないが・・・PoCの壁を越えるには 圧倒的な当事者意識とパッションを持つメンバーが

    周囲に火をつけて拡げるウェーブ発生の仕掛け Whyを掲げると進み方の合意 • プロジェクトがどうなってい くか、まずは予測する • 不要なPoCは開始しない • 地続きな小さな成功を行う仕 掛けを準備する ◦ 焦らない・成功例に こだわらない ◦ もくもく会 • 推進者は兼務ではなく専任。 調整コストは高い。 シンプルに開始・役割の段階明確化 • 運用できるように複雑なことは しない。シンプルに始める • 全員が全部できるようになるは 諦める • スキルに応じて利用者と作る人 ・施策実行する人・推進者の ロールを分ける • 第3者が施策の価値を評価し、 Go / NoGo判断をする 段階的アプローチでリスク低減 • 身近なところから段階的な技 術アプローチ 例:Gemini → NotebookLM → GAS → Dify • あったらいいねは諦める • 技術的な限界や制約を理解す る・受け入れる • 企画・検討・開発は、専門 家、運用は現場が回せる