ChatworkとBPaaS 異なる特性で学んだAI機能開発の ベストプラクティス

2026年6月8日(月)に実施された「AI Engineering Summit Tokyo 2026」での発表資料です。
イベントページ：https://ai-engineering-summit-tokyo.findy-tools.io/2026-summer
登壇者：株式会社kubell 上田 隼也

Transcript

1. ChatworkとBPaaS 異なる特性で学んだAI機能開発の ベストプラクティス 株式会社kubell プロダクトディビジョン AIプロダクトグループ グループ長 兼 Principal AI Engineer 上田隼也 2026年06月8日 1
2. 自己紹介 2 役職：プロダクトディビジョン AIプロダクトグループ グループ長 兼 Principal AI Engineer 専門領域：機械学習・データサイエンス・エンジニアリングマネジメント 職歴： • 筑波大学大学院でコンピュータサイエンスを専攻し、2018年に株式会社メルカリに 機械学習エンジニアとして入社。機械学習システムの開発を牽引し、その成果 論 文として国際会議にも採択されるなど、AI技術のビジネス貢献を実践 • その後、PayPay株式会社で技術リード兼エンジニアリングマネージャーとして金融 領域の機械学習活用戦略を統括 • 「AIをビジネス価値へ転換させる」という指針に共感し、2025年に株式会社kubell に参画しAIプロジェクトの推進に没頭 • 個人の活動として機械学習の技術書の執筆や「Human-in-the-Loop 機械学習」の翻 訳を手掛けたり、勉強会運営なども行っている。 上田 隼也 (うえた しゅんや)
3. アジェンダ AGENDA 01. ChatworkとBPaaS 02. Chatwork AI と AIエージェント 03. AI機能開発ベストプラクティス 04. 課題とこれから 3
4. 01 | ChatworkとBPaaS 4
5. 働くをもっと 楽しく、創造的に ⼈⽣の⼤半を過ごすことになる 「働く」という時間において、 ただ⽣活の糧を得るためだけではなく、 1⼈でも多くの⼈がより楽しく、 ⾃由な創造性を存分に発揮できる社会を実現する MISSION 5
6. 事業概要 • 国内最大級のビジネスチャット「Chatwork」を展開。業界のパイオニアであり国内利用者数No.1*1、導入社数は98.9万社*2を突破 • 圧倒的な顧客基盤のあるプラットフォームを背景に、チャット経由で業務を請け負いDXを推進するBPaaS「タクシタ」を展開 　ビジネスチャット「Chatwork」 BPaaS「タクシタ」 • 国内利用者数No.1*1 有料ユーザーの97%が中小企業ユーザー • 日本の1/5を占める導入社数99.0万社以上*2 809万ユーザー • 全業界・全職種の方が日常的に使うプラットフォーム チャット経由で業務を請け負いDXを推進 業務代行 経理・総務・事務な ど幅広い業務に対応 人事・労務など専門 性の高い業務に対応 採用 経理・会計 労務 営業事務 AI・SaaSを徹底活用 *1 Nielsen NetView Customized Report 2025年7月度調べ月次利用者（MAU:Monthly Active User）調査。 調査対象はChatwork、Microsoft Teams、Slack、LINE WORKSを含む44サービスを株式会社kubellにて選定。 *2 2026年3月末時点 6
7. BPaaSとは BPaaSとは Business Process as a Service の略。ソフトウェアの提供ではな 、業務プロセスそのものを提 供するクラウドサービスであり、クラウド経由で業務アウトソーシング 可能 オンプレミス IaaS Infrastructure as a Service PaaS Platform as a Service SaaS Software as a Service BPaaS Business Process as a Service DX人材 DX人材 DX人材 DX人材 DX人材 業務オペレーション 業務オペレーション 業務オペレーション 業務オペレーション 業務オペレーション アプリケーション アプリケーション アプリケーション アプリケーション アプリケーション データ データ データ データ データ ミドルウェア ミドルウェア ミドルウェア ミドルウェア ミドルウェア OS OS OS OS OS サーバー サーバー サーバー サーバー サーバー ストレージ ストレージ ストレージ ストレージ ストレージ ネットワーク ネットワーク ネットワーク ネットワーク ネットワーク =ユーザー 管理 =サービス提供者 管理 BPO Business Process Outsourcing DX人材 アプリケーション データ ミドルウェア OS サーバー ストレージ ネットワーク 業務オペレーション 7
8. 人手による解決 競合優位性：ABCD全領域をカバーするハイブリッドアプローチ 顧客の課題に応じて 最適な解決方法を提案 業務に応じて、A〜Dすべての解決手法の提供で る 体制を構築する。人による判断や対応 必要な業務 ら、AIを含めたテクノロジーによる完全自動化まで、 柔軟に組み合わせで対応する。業務毎での最適化によ り生産性と利益率の向上を目指す。 TECH＋人で解決 TECHによる解決 （チェック） A 人＋TECHで解決 B C D 人が中心、経験と手作業 人が主導、ツールで効率化 自動化が主、人が監視・承認 完全自動化、AI・ロボット 他社のBPOは「A」中心、AI事業は「C/D」中心。 弊社は全てをカバーし、ラストワンマイルまでタッチ可能。 8
9. Chatwork AI と AIエージェントのデモ動画 ※細 い見た目は変更になる可能性 あります。9
10. 02 | Chatwork AI と AIエージェント 10
11. Chatwork AI によるコミュニケーション支援 11 業務に関する 会話履歴 AI コミュニケーション 支援 Chatworkでのやり取り（業務上の会話履歴）をコンテキストとして 「読む・探す・書く」の負荷を下げ、コミュニケーション支援
12. Chatwork AI:要約 12 構造化して整理することで読む負荷を下げる Structured Output の活用により、情報を段階的に提示可能なUXを実現 ※細 い見た目は変更になる可能性 あります。
13. Chatwork AI:下書き作成 面倒なメッセージ作成の下書 はAIに 任せ 13 人間は Human in the Loop として体裁を整え送信する ※細 い見た目は変更になる可能性 あります。
14. Chatwork AI:行政ニュース配信・ディープリサーチ・資料生成 行政による一次情報をAI 整理・構造化、その後の対応まで一気通貫でサポート 14 Human-in-the-Loop として最後の文章のレビューは人間 行い送信する ※細 い見た目は変更になる可能性 あります。
15. AIエージェントの大まかな画面遷移例 1: 依頼する処理を選択 「住民税決定通知書入力代行」 を選択 2: 顧問先名を選択 「山田工業株式会社」を選択 3: ファイル場所を指定 Boxに保存した住民税決定通知 書のPDFファイルのURLを指定 4: OCR処理→結果表示 しばらく待つと、住民税決定通 知書の読み取り結果が表示され る。終了タイミングで Chatwork上でも通知を実施。 5: 給与計算ソフトへの入力 OCR読み取り結果を確認後、給 与計算システムに自動入力 30秒程度 1~5分 ※読み取り枚数による 30秒〜1分 ※読み取り枚数による ※細 い見た目は変更になる可能性 あります。 • 顧問先ごと・業務ごとに分散した複数のSaaSを、単一の入力インターフェースに統合する • これにより、担当者は複数ツールを横断して操作を覚える必要がなくなり、利用者の限定や属人化も解消 • 特に、顧問先数や処理件数が多い現場ほど、画面切替・運用負荷・教育コストの削減効果が大きい 15
16. AIエージェントが解決する問題は、分割による単純化は必須 16 専門エージェント： シート選択 コーディネーター エージェント 専門エージェント： Spreadsheet 専門エージェント： Box 専門エージェント： 給与更新 専門エージェント： 手当インポート 専門エージェント： 控除インポート 専門エージェント： 退職日チェック Excel らシート名を取得する Spreadsheet ら各フォー マットのデータを出力する Boxのエクセル ら各フォー マットのデータを出力する 基本給をSaaS APIで更新する 手当をブラウザ操作で 更新する 控除をブラウザ操作で 更新する 退職日をSaaS APIで取得して 未入力をチェックする コーディネーターはユーザー の指示を理解し専門エージェ ントと双方向で通信し、指示 されたタスクを完了させる AIエージェント
17. 03 | AI機能開発ベストプラクティス 17
18. LLMのレスポンスは遅いので工夫が必要 提供サービスにより、許容できるレスポンス速度は異なる 第4章 処理と生成段階のための設計 “待たせるな 遅延と遅延の管理 ” Chatwork: • ユーザー チャット画面で利用するため、速度面 重要* • 非推論モデル中心に選定し、性能面の要求を満たすために推論モデルを採用 • ✗とりあえずフロンティアモデルを採用する 💮 状況に応じたベストなモデル選択が必要 • 打ち手: Prompt Caching, ならProvisioned Throughput, reasoning_effort の調整, ストリーミング表示による体感時間の改善、クロス推論 BPaaS: • 業務代行のバックエンド処理は、時間 っても精度を優先したい → 推論モデルを採用しやすい *GoogleのSpeed Matter 実験でもレスポンスタイムは顕著に継続率に影響 https://research.google/blog/speed-matters/ 18
19. LLMのAPI代金は高い 💸 サービス特性により、トークン消費量は顕著な差が発生 • Chatwork: 気兼ねな 利用で ること 価値→トークン消費量の累積 →事業継続のため、赤字にならない管理機能は必須* • BPaaS: 業務に応じて消費されるため、トークン消費量はChatwork と比べて 比較的低い。付加価値 高いため相対的にコストを回収しやすい • 打ち手: バッチ処理(最大半額)、価値提供とコストのバランス 満たされる モデル選定、AWS:クロス推論処理、Amazon Bedrock Intelligent Prompt Routing(モデルファミリーでの最適なモデルのルーティング) *Gemini 2.0 Flashシリーズはコストと性能のバランスで、有力候補だった モデルのサンセット 早す るので除外😱 19 *GitHub CopilotのUsage-Based Billing移行について - GitHubブログ GitHub も厳格なコスト管理へ移行
20. データを国内に保持したい・データは学習されなくない レジデンシー・ガバナンス・コンプライアンス・セキュリティの改善 • Chatwork・BPaaSともに、ToB SaaSのためレジデンシー・ガバナンス・コ ンプライアンス・セキュリティは重要 • 打ち手: ◦ 現状データは学習されないの デファクトスタンダード ◦ 国内保持:AWSで利用サービスを統一することで上記の目標を達成可能 20
21. そもそも、そのモデルは使い物にならないかも? RPM, TPMの制限はモデルごとにかなり幅がある • RPM (Requests Per Minute): 1 分間に送信で るリクエスト数に対してモデ ルレベルで設定されたクォータ ◦ NEW: Bedrock で特定のモデルはRPMの制限 な なる • TPM (Tokens Per Minute): 1 分間に使用で るトークンの数 (入力と出力の 両方を含む) のモデルレベルで設定されたクォータ ◦ *バーンダウンレート: Anthropic Claude モデルバージョン 3.7 以降の バーンダウンレートは、出力トークンに対して 5 倍です (1 つの出力 トークンはクォータ ら 5 つのトークンを消費します） • 打ち手: AWSならProvisioned Throughput、クロスリージョン推論、 Prompt Cache、Claude Platform on AWS(2026/04/21) https://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/quotas-token-burndown.html 21
22. AWSでの各モデルのRPM, TPM,コスト モデルごとにかなり幅があり、適切なモデル選択が必要 22 Model Name cost:1M input tokens cost:1M output tokens RPM TPM Claude Sonnet 4.6 $3 $15 1,0000 600,0000 Claude Haiku 4.5 $1 $5 1,0000 500,0000 Amazon Nova2 Pro $1.25 $10 100 100,0000 Amazon Nova2 Lite $0.3 $2.5 2000 800,0000 gpt-oss-120b $0.15 $0.6 1,0000 1,0000,0000 gpt-oss-20b $0.07 $0.3 1,0000 1,0000,0000 *https://aws.amazon.com/jp/bedrock/pricing/ *https://docs.aws.amazon.com/general/latest/ gr/bedrock.html#limits_bedrock
23. Chatwork: 牛丼三原則モデル 期待される「うまい」を満たしつつ、「やすい」&「はやい」を実現させたい うまい やすい はやい ・「はやい」と相関 ・「やすい」ほど、多く提供可 能→同じ予算で多くのトークン 消費が可能に ・価値提供の解像度を上げ、ど のモデルなら「うまい」か? を まずは明確化する ・過剰な「うまさ」を追求する と「たかい」「おそい」になる ・基本的に「やすい」と相関* ・「おそい」とお客様は待ちき れない *例外として「やすい」が遅いモデルもある 23
24. BPaaS: フルコースモデル うまい たかい おそい ・値段を気にせず「うまい」が 最重要なので、その実現のため に「たかい」は許容 ・人間が行っている作業を代替 するためには最高の「うまい」 を追求する必要がある ・「はやさ」は最重要ではな く、「うまい」料理を届けるこ とが大事 24 最高の「うまい」を提供するために「たかい」&「おそい」は許容
25. 04 | 課題とこれから 25
26. AIバブルの崩壊リスク: 投資から回収フェーズへ API代金がX倍に値上されたら事業継続できますか? • AIバブルはいつ弾けるわ らない、回収期になれば利用代金は...* • 打ち手: ◦ オペレーションコストは掛 る 、OpenLLMを利用して、自前でホスト 可能な選択肢をPlan Bとして検討 OpenLLMもいつまで継続して れる わ らないリスクはあるので注意 *LLM「Qwen3.5」の開発コアメンバー 突然の辞任　「オープンウェ イト戦略は継続」、開発元のAlibaba コメント - ITmedia AI＋ ◦ 従来の機械学習モデルで代替可能なタスクの場合は、機械学習モデルを 内製で運用して代替する →組織のケイパビリティを上げる必要がある 26 * Microsoft Ends Claude Code Licenses As It Shifts Developers To Copilot MSは数ヶ月で年間のAI開発費用を消化してし まい、Claude Code の利用を停止して、自社のGitHub Copilot へ移行 Uber Caps Usage of AI Tools Like Claude Code to Manage Costs Uberも 4か月でAI予算を消化。一人あたり月額24万円を 上限に設定
27. モデルのライフサイクル・種類はベンダーの一存で決定 そのモデルずっと利用できますか? • 自分たち 利用したいモデル 恒久的に提供されない ◦ 事例: Amazon Nova は2 ら最軽量だったMicroの提供を停止 • リカバリープランを悲観的に考えて ◦ メジャーアップデートに追従 ？ ▪ メジャーアップデート事に基本的にコストは高 なる💸 ▪ また挙動も互換性 あるとは正直保証されない ◦ 類似モデルに乗り換える ? • 打ち手: テストコレクションを作り性能のモニタリングも必要 Rubric Test などを備えて性能を担保できるようにしておくのが大事 27
28. AIによって今までの常識を変えられるか？ 人月の神話問題をAIで解決できないか試行錯誤 28 *Andrej Karpathy 提案するllm-wiki V.S. LLM Wiki V.S.
29. 働くをもっと楽しく、創造的に 29