「仕事が終わる」までを設計する— 決定論と非決定論、そしてHuman in the Loopを使い分けてつくる Chatwork × BPaaS × AI Agent 体験 —
kubell CPOの徳原です。
前回、COOの記事で「中小企業のデジタル化が進まないのは意欲ではなく“構造”の問題」という話がありました。まさにその通りで、現場は“紙・口頭・メール”が合理的な最適解として残り続けやすいです。
今回は、その“構造”に対して、プロダクトとしてどうやって挑戦するか、「仕事が終わる」までをどう設計し、どう実装し、どう伸ばしていくか、という話を書きます。
先日開催された「AI Engineering Summit Tokyo 2025」での登壇資料も公開していますので、ぜひあわせてご覧ください。
TL;DR
目指すのは、チャットが“会話の場”で終わらず、意思決定 → 実行 → 完了 → 証跡までを駆動する経営を支援するプラットフォームです。
その成立条件は、AI・人・ルールベース（ワークフロー）を同一の座標系で“最適配置”するコーディネーションレイヤーを、プロダクトとして持つことです。
LLMは非決定論で強い一方、業務では“壊れない仕組み”が最優先です。だからこそ、決定論（ルール／ワークフロー）とガードレール（HITL・予算上限・承認・監査ログ）を分離して統合する設計が勝ち筋になります。
そしてもう一つ大事なのは、最初から100%精度のホームランを狙わないことです。最初は成功確率は10%程度と前提を置き、ラウンドを積み上げ、30%、50%、80%へと引き上げられるプロダクトプロセスと体制を作ります。※アルベルト・サヴォイア『Google×スタンフォード NO FLOP! 失敗できない人の失敗しない技術』p.241 の趣旨を、筆者が要約・解釈して使用。
0. まず前提：ホームラン狙いは、だいたい失敗します
AIを業務に入れるとき、いちばん危ないのは「一発で100の精度で当てにいく」設計です。
理由はシンプルで、現実の業務は例外の集合だからです。しかも、監査・権限・責任・説明可能性（判断根拠と経緯が追える状態）が絡むので、リソースと予算を過度にかけ過ぎてしまうと、1回の挑戦が“学び”では済まないことがあります。
だから私たちは、最初からこのように割り切ります。
どんな施策も初速の成功確率は10%くらいだと思って始めます
10%でもいいので、「完了」までのプロセスをまず回します
上手く行かなかったログを“資産”として溜めます（何が原因で止まったか、どこで人が介入したか）
上記資産の活用によりルール／ワークフロー／HITLを厚くしながら、成功確率を30%→50%→80%へ引き上げます
ここで大事なのは、AIの導入は「精度勝負」ではなく、「改善の速度勝負」だという点です。
つまり、当てにいくのではなく、当たるように設計して、当たるように運用して、当たるようにプロダクトを進化させます。
1. ビジネスチャットを起点に経営を支援するとは
“経営支援”は、情報共有やコミュニケーションの効率化だけではありません。
例えば、契約・決済・記録（台帳化）までを連鎖的に起動させることを含みます。
現在、中小企業の現場で起きているのは、COOの記事でも触れていた通り、意欲の問題ではなく構造の問題です。現場が止まるパターンはだいたい同じで、
意思決定が会話に依存し、記録が残りにくい
実行が人の頭と手に閉じてしまう
完了が“誰かの記憶”に依存してしまう
証跡が“後付け”になってしまう
その結果、構造的に改善が積み上がりにくい
ここを壊すには、UIやオペレーションを磨くだけでは足りず、「誰（AI／人／ルール）が、どの順で、どこまで責任を持つか」を、現場の暗黙知ではなくプロダクトのロジックにする必要があります。
そのために私たちが開発するのが、Coordination Engine（コーディネーションエンジン）です。
主な役割は以下の4点です。
タスク分解： 業務を最小単位へ分解し、目的と制約をもとに“組み合わせ問題”として最適手順を生成する。
リソース配置： AIエージェントと人材を、コスト・品質・期限・権限に応じて最適配置できる状態にする。
一気通貫の実行： チャット上の対話を起点に、要件補完→実行→完了までをシームレスに一気通貫で実行する。
安全性の担保： ガードレールとして、HITL（Human in the Loop）＋予算上限＋承認フロー＋監査ログで安全に運用する。
これにより会話を議論だけで終わらせずに「会話が起点になって、仕事が終わる」を設計します。
2. North Star：会話が起点になり、業務の完了まで繋がる世界観
ここでは目指す世界観という意味でNorth Starという言葉を使います。
会話が起点になり、インテント認識から業務発生、納品確認の会話から決済・仕訳までがつながる世界観です。
これを重要な要素を4つのレイヤーに分けて設計します。
(1) Conversation Front（Chat UI）：二層UXで「前に進む入口」を作ります
COOの記事でも触れられていた通り、中小企業では「入口が軽いこと」がすごく重要です。そこで、Chat UIは二層で設計します。
中央：トークルーム（トーク相手に見える）
社内外の会話の間に立って、不明点を明確にしたり、取引を前に進めるサポートをします
AIエージェントのアクションやメッセージは、他の参加メンバーにも見えます
契約ドラフト、請求、支払い、資料授受などを支援し、不備や不足を指摘して前に進めます
取引先とのNext Actionタスクを、会話から自然にドラフト化します
右：サイドパネル（自分だけに見える）
“秘書”のように、作業そのものを補助します（下書き・提案・リサーチ・補助線）
ここで作った成果物を、必要なときだけチャットへ投稿できます
取引先リサーチ、交渉の論点整理、合意形成のための草案作成などを支援します
この二層は見た目の工夫ではなく、会話を「議論」で止めず、「次のアクション」へ押し出し、「ナレッジ」の落とし込みと、「実行」に接続し、「完了」と「証跡」を回収するところまで実現します。
(2) Agentic Layer（生成AI・推論）：非決定論の強みを最大化します
ここはLLMが扱える非決定論の強みを最大化する層です。
要件整理、検索・要約、ドラフト生成
タスク分解、候補の列挙、段取り設計
“探索・推定”が価値になる領域
ただし、ここがプラットフォームの本体ではありません。
LLMは“推論する部品”であって、業務の責任を持つ構造は別レイヤーに置きます。ここを混ぜると、精度だけではなく、責任の範囲と説明の強度が曖昧になってしまいます。
(3) Rule-based / Workflow Layer（決定論）：監査・責任・説明可能性の土台です
規程、承認、台帳、監査、権限など、決めた通りに動くべき領域を担保する仕組みです。
ここを曖昧にしないことが、監査・責任・説明可能性を強固にするポイントです。このレイヤーは「LLMが賢いから置き換える」ではなく、ルール／ワークフローをガードレールとして強化する設計になります。
(4) BPaaS（User-Ops）：人は“作業者”ではなく“業務を完了させるスペシャリスト”として配置します
BPaaSは「人の作業」ではありません。非決定論×決定論×Human in the Loopを束ねて、業務を完了させる運用モデルです。
COOの記事で触れられていたA〜Dの整理で言うと、A〜D全部が私たちの扱う範囲です。ただし、理想は右側（C/D）の比率がテクノロジーの進化で高まっていく構造です。※kubell COO 福田升二『中小企業向けの「BPaaS」という難題をkubellが本気でクリアしにいく話』
ここで大事なのは、人がいるからスケールしないではなく、人が“最後の責任”を持てるから、AIを前に進められるという設計です。
3. Coordination Engine：誰がやるかを、現場の勘からプロダクトのロジックへ
Coordination Engineは「誰がやるか」を現場の頭の中から剥がし、プラットフォームのロジックにするエンジンです。ここでの設計要件は、顧客業務を完成させることになります。
AI Agentと人材リソースを、コスト・品質・期限・権限で最適配置します
HITL・予算上限・承認フロー・監査ログで安全に運用します
「なぜこの人材／このAgentなのか」を自然言語で根拠提示できるようにします
承認／非承認データを、継続的な改善（評価・学習）に接続します
そして、Coordination Engineを“OS”として強くするには、長期的な記憶（メモリの設計）が重要です。あわせて人もAIも同じ座標系に載せる必要もあります。
そのために、人の稼働を例えば次のような状態（簡易版）で計測・紐付けします。
勤務ON/OFF
進行中（IN PROGRESS）
完了（DONE）
案件側には次（簡易版）が紐づきます。
どのアシスタント／Agentが
どの企業の
どのカテゴリ業務を
どれくらいの時間で
どの満足度・リテンション・売上を生んだのか
これがないと、意思決定に感覚要素が強く出ます。AIに任せた方が良いのか、人に任せた方が良いのか、誰が強いのか、どの案件が利益を生んだのか、全部が“それっぽい”議論で終わってしまいます。
逆に言えば、この“完了データ”が溜まり始めると、AIと人を同じ座標系で比較できるようになり、改善の速度を飛躍させられます。
そして、モデル性能ではなく、完了データ資産で自動化率を上げていくフライホイールが実現できます。
実装要素としては、以下が必須です。
ベクトル検索： タスクとスキルの潜在的な関連性を捉える
埋め込みモデル最適化： 検索品質を向上させ、完了率に直結させる
Chatwork API/Webhook連携： 会話から実行フェーズへシームレスに接続する
認証・権限管理＆監査ログ： 誰が・いつ・何を承認したかを残し、ガバナンスの土台とする
4. PoCの30〜50%圧縮を「量産」へ
PoCでは、以下のような給与顧問領域のAIエージェントで作業時間を30〜50%削減し得る見立てです。
仕訳の確認リストを読み取り、SaaSへ入力するAIエージェント
OCRで紙証憑を読み、SaaSへ入力するAIエージェント
ドメイン別にエージェントを“カタログ”として揃える設計です（給与顧問・労務・経理など）ここで重要なのは、すごいデモを見せることではなく、“完了サイクル”をカタログ化して、横展開できる形にすることです。
入力（イベント）
推論（LLM）
検証（スキーマ）
実行（ツール呼び出し）
承認（HITL）
証跡（ログ）
完了（DONE）
この完了サイクルを業務カテゴリごとにカタログ化し、Chatwork上から「依頼→完了」までの動線でシームレスに提供できる状態を目指します。
そうなると、成功したものを次に運ぶ速度が上がり、再現性テストを高頻度で回せるようになります。
5. 非決定論の力を、決定論とガードレールで“事業”にします（そして、確率を上げます）
LLMは非決定論的なアプローチに向いています。探索・推定・ドラフトは強いです。
一方で、誤った形式（キー違い）も出ますし、ハルシネーションも起きます。だから実運用では「プロンプトの工夫」だけで押し切るのは危険です。
私たちは最初から、決定論とHITLの安全装置を“標準仕様”として組み込みます。
スキーマ検証（想定外の値・キー/形式は弾きます）
HITL（重要判断は必ず承認します）
ツール実行の確認フロー（勝手に外部操作させません）
予算上限／承認／監査ログ（運用ガードレールを設計します）
そして、ここからは冒頭で示した「成功確率」の前提の話に繋がります。
最初は10%の成功確率という前提に立ち、その10%を“回る回路”として成立させ、失敗から改善できる体制にすることです。
どこで止まったかを、ログとして残します
例外をルールに切り出し、ワークフローを強化します
人が介入した理由を構造化し、次の自動化候補を明確にします
同じ失敗を繰り返さない“型”を作り、カタログに反映します
こうやってラウンドを積み上げると、成功確率は10%→30%→50%→80%と上げられます。ホームランではなく、“ヒットを積み上げて勝つプロダクトプロセス”を作る戦略です。
6. 最後に：入口（Chatwork）×完了責任（BPaaS）×最適配置（Coordination Engine）が回り始めると、業務の前提が変わります
Chatwork（入口）とBPaaS（実行）を、AIとルールと人を束ねるCoordination Engineで接続します。これによってBPaaS事業がさらに強化され、「仕事が終わるBusiness OS」へ進化させる計画です。
ここで実現するのは機能追加ではなく、前提の書き換えです。
担当者の経験で回していたものを、プロダクトのロジックで回します
完了データで学習し、最適配置と自動化率を上げます
自動化率で粗利を作り、次のドメインへ再投資します
この循環に入ることで「AIと人が共存するプラットフォーム」が実現できます。
これは、顧客にとっては“ツール導入”の話ではなく、会社の完了能力が増える話になります。「今月を回せる」という生存本能に寄り添いながら、裏側ではAX（AI変革）を積み上げていける構造です。
この構造が当たり前が回り始めた瞬間、完了データが資産になり、資産が自動化率を押し上げ、自動化率が次の投資余力を生みます。
私たちは、ミッションである、「働くをもっと 楽しく、創造的に」とビジョンである「すべての人に、一歩先の働き方を」本気で実現するためにChatwork × BPaaS × AI Agentの体験設計を強化しています。
もしこの文章を読んで、kubellのミッションや価値観に興味をもち一緒に実現してみたいと思った方は、ぜひ一度お話しさせてください。
私たちがやろうとしているのは、流行りのAI機能を足すことではなく、日本の中小企業の“仕事が終わる”を構造として実装し、社会全体の生産性を底上げすることです。
ミッション・バリューに共感できて、目指す方向と自己実現がきれいに重なる方
日本の生産性を上げるなら、まず中小企業の現場からだと思う方
仕事の時間を「世の中を少しでも良くする」ことに使いたい方
そして、プロダクト・エンジニアリング・オペレーションをまたいで、“仕事が終わるBusiness OS”を本気で作り切りたい方
積極的に採用を行っているので、興味を持っていただけたら、応募・カジュアル面談どちらでも大歓迎です。お待ちしています。
