Slack AIの活用事例

フランス・ベルギー・ドイツで7つのブランドを持ち、データが2002年のMicrosoft SQL ServerからGoogle BigQueryまでばらばらの基盤に散らばっていた。

売上や顧客といった基本の数字を全社で見ようとするだけで何週間もかかっていた。

1. 古い基盤を直さずSnowflake上に基盤を作り直した
2. 25年分の古いデータベースを6か月で1つに寄せた
3. 全ブランドが同じ数字を見られる状態にした
4. CoCoで作ったAIエージェントをSlackに置いた
5. ハッカソンで約70人に触らせ3案を製品化した

25年分の基盤の統合を6か月で終え、保守に15人分かかっていた体制が2人で回るようになった。

数字が出るまで何日も待っていたのが、ほぼその場で返ってくるようになった。

顧客から修正の依頼が来るとLinearのチケットとSlackのやり取りに情報が散らばった。

全体像をつかむまでに時間がかかりコードを書く所だけが速い状態だった。

1. eveという枠組みでエージェントを作りVercel上で動かした。
2. 指示書とツールと手順を1つのフォルダにまとめた。
3. 担当者はChrome拡張で直したい内容を書いて渡す。
4. コーディング担当のエージェントが仕様とプルリクエストを作る。
5. 責任者が内容を見てから取り込む。

直近3か月で出荷の速さが3倍になった。

2人のチームは最初の4か月でLinearのチケットを800件以上終わらせ顧客の依頼は早いものだと2時間で本番へ入るようになった。

自作タスク管理ツールに繋いだAIエージェントをcronで定期実行していたが、進めるタスクが無い時間帯でも同じ間隔でLLMが起動していた。

空振りの実行でトークンを消費し、中身のない通知がSlackに流れ続けて重要な知らせが埋もれていた。

1. LLMを呼ぶ手前に起床判定の関数shouldWakeForTaskを置いた
2. 関数はタスク1件と利用者IDを受け取りbooleanだけ返す
3. 状態はタスクコメント1行目のマーカーに書き正規表現で読む
4. 最新マーカーはcreatedAtで選び再アサインなら再び起こす
5. 起こす条件と寝かせる条件をユニットテストで固定した

waitingやdoneのように待つべき状態では起動せず、再アサインや依存の解消、中断した作業の再開だけをエージェントに回せるようになった。

ただし定義外の状態名が入るとゲートが起床させない側に倒れる点は課題として残った。

プロジェクトの責任者は定例の進捗会議の準備と出席に週2〜4時間を取られていた。

表計算やスライドやMuralなど複数のツールから手で情報を集めても経営層に届くころには中身が古くなっていた。

1. 現場の技術者チームが進捗報告アプリGPSを作った
2. メンバーは口頭報告をやめGPSへ更新を書き込む
3. 投稿があると関係者へSlackで自動的に知らせが飛ぶ
4. 責任者はリスクだけなどAIの要約を選んで確認する
5. 聞きたいことを普通の言葉で質問して答えを受け取る

2025年10月に本番で動き出し、Hardware Compliance部門の約45人が使うようになった。

多くの進捗会議が減るかなくなり、技術者が本来の仕事に向かう時間が増えた。

紙の図面や検査記録が社内にあふれ、書類を探すだけで現場が1〜2時間動き回ることもあった。

創業50年でも手順書は50件ほどで、多くの作業のやり方はベテランの頭の中だけにあった。

1. AIとの対話を1500時間以上重ねコーディングを学んだ
2. タブレットとSlackで内線電話や紙探しをなくした
3. Claude Codeで社内アプリをフルスクラッチで内製した
4. 生産実績や設備稼働などを同じデータベースにひも付けた
5. 手順書アプリでAIが100点満点で採点し改善案を出す

月400〜500時間程度の作業時間を減らし、価格改定資料の作成時間は90％短縮した。

紙は月間約6000枚減り、手順書は1年足らずで290件集まった。

プロダクトの技術的な問い合わせでは過去の記録やヘルプ、仕様書を横断して調べる手間があった。

受付から調査やクローズまでをCREが抱える形で、件数と対象プロダクトが増えると回らなくなっていた。

1. 社内メンバーがSlackの起票フォームに内容を入力する
2. ワークフローの途中でエージェントを呼び出す
3. 過去の対応記録やヘルプ、似た事例を探させる
4. 根拠と次に取る行動が分かる回答をスレッドに返す
5. 回答の良し悪しをボタンや絵文字とLLM採点で記録する

起票する前にメンションで聞いて、問い合わせた本人が自力で片付く場面が増えた。

最初は検索結果の羅列で終わることが多かったが、解決そのものを目的に据えて指示文を直した結果、何をすればよいかまで示す答えが返るようになった。

少人数のスタートアップでCROもRevOps専任もいなかった。

営業の記録や請求のやり取りが人の手に残り、対応の抜けが起きかねなかった。

1. Claude中心の仕事の流れにSalesforceをつないだ
2. メールと打ち合わせの履歴を毎日自動で取り込ませた
3. 入った見込み客に追いかけの予定を自動で作らせる
4. 商談が成約に近づくとSlackへ通知が飛ぶ
5. 請求と更新のお知らせも同じ流れに載せた

売上まわりの運用を Salesforce に集めたことで、人を増やさずに規模を広げられるようになった。

CROもRevOps専任も置かないまま運用が回っている。

ローカルのファイル操作やOSコマンド実行までできるAIエージェントを全従業員に配ると、情報漏えいや誤操作の危険が大きい。

かといって一律に禁止すると、現場のスピードが落ちる。

1. 2026年5月からClaude CodeとClaude Coworkを全社に配った
2. 非エンジニアにはNotion AIと仮想環境のClaude Coworkだけを渡した
3. JamfとOktaをつなぎ開発者か非開発者かで設定を自動配布した
4. 非エンジニア端末の管理者権限を外しSlackコマンドで一定時間だけ付与した
5. API利用はLiteLLMを通しGKE上で短い有効期限のキーを自動発行した

1000人以上の非エンジニアにもエージェントを前提とした働き方が広がり、これまでエンジニアに頼むしかなかったプロダクトマネジャーが自分で新機能を実装してリリースする例が出てきた。

共通基盤でAIの費用をまとめて見られるようになり、チームごとのコスト調整も提案しやすくなった。

前に使っていたチャットのツールでは、誰が来ていて買う気がどれくらいかが分からなかった。

Salesforceとの連携も弱く画面を行き来する必要があり、会話の離脱が多く成功率も低かった。

1. チャットをQualifiedのConversationsへ入れ替える
2. 来訪者をメール経由や買う気の強い人などに分ける
3. Salesforceのデータで担当営業へ振り分ける
4. 担当先が来たらSlackの通知で名前を呼んで話しかける
5. SDR全員に使い方の研修をする

入れ替えから6週間で会話の成功率が900%伸び、生み出したパイプラインは490万ドルになった。

ROIは687%だった。

大きな組織では同じ製品の重なり合う部分を大勢が作るため足並みをそろえること自体が仕事になっていた。

知識が人の頭やSlackや会議メモに散らばりエージェントが頼れる拠り所が無かった。

1. エンジニア組織全体に2週間コードを書くなと伝えた。
2. 要件やデザインやバグ報告をLinearへ集めて置き場を1つにする。
3. まずLinearのエージェントから始め次に自社製のForgeを作った。
4. Slackのバグ報告を自動でLinearの課題にしてForgeが修正案を出す。
5. ほぼ毎週のSpeedrunで慣れた人が新しい流れを実演した。

エンジニアは朝にエージェントが夜のうちに書いたプルリクエストをレビューし日中はさらに10〜15件を回して難しい所に自分で取り組むようになった。

あるSpeedrunでは15分で500件を超えるプルリクエストが出た。

急な人員拡大とリモート中心の働き方で、社員が持つ情報が個人のフォルダや部門内にとどまっていた。

過去資料や対応履歴を探すのに時間がかかり、誰に聞けばよいかも分からなかった。

1. 社内ポータルと部門ごとのチームスペースをNotionに作る
2. 議事録や仕様書や社員プロフィールを一箇所に集める
3. プロフィールを参照して担当者を答えるエージェントを用意する
4. Slackの問い合わせからNotionに対応チケットを自動作成する
5. 過去の対応履歴から近い前例を返すBotを組む

ヘルプデスクにかかる手間は約3割減る見通しになった。

ナレッジ記事の数は2倍以上に増え、1記事あたりの作成時間も2〜3営業日から数時間に縮まった。

強い仕組みを入れても働く場所が変わるため誰も使わない状態が続いていた。

四半期末にはSalesforceの中身と実際の商談のずれが表に出て、締め日の駆け込み対応が起きていた。

1. Salesforceとデータウェアハウスを共有Slackチャンネルへつなぐ
2. 営業の運用担当へ聞く前にまずSlackbotへ聞く決まりにした
3. ClaudeとAgentforceで3つのエージェントを作った
4. 予定の管理と商談の助言と財務面の相談をそれぞれ任せた
5. データのおかしい所と直し方をSlackで知らせ了承後に値を直す

数週間で朝いちばんにSlackを見る流れが定着した。

四半期末の駆け込み対応が無くなり、締めが特別な作業ではなくなった。

事業者向け管理画面と一般ユーザー向けシステムを同時に作る大規模開発で、仕様策定やデザインの確認に時間がかかっていた。

実装が終わってから想定と違う挙動に気づき、大きな手戻りが出ることもあった。

1. デザイナーがざっくりした仕様をAIに渡し数分で動くモックを作らせる
2. モックを関係者と見ながら認識を合わせる
3. 方向性が決まったらFigmaのオートレイアウト付きデータへ変換させる
4. PdMが議事録とSlackのスレッドURLを渡しNotionのPRDへ変更点を反映させる
5. SDKチームは仕様書からコード生成までプラグインに任せ人はレビューに回る

仕様を決めてから動くものを見るまでのサイクルが、以前の2週間〜1ヶ月から1日、2日になった。

深刻な手戻りも開発の初期段階で防げるようになった。

社内の情報が文書やSlackのスレッドに散らばり、営業やサポートが顧客の細かい質問に答えるまで時間がかかっていた。

製品の担当者も優先順位を決めるために大量の顧客チケットを読み込んでいた。

1. 社内の文書やSlackのスレッドを毎日Snowflakeへ取り込む
2. ブログや記事や教材も同じ場所へ入れて答えの範囲を広げた
3. 質問が来るとCortex Searchが元になるデータを引く
4. 推論の部分が質問の意図を読んで答えを組み立てる
5. 社員はSlackでいつもの言葉で質問する

チャットボットは製品や販売や顧客に関する質問へ月に約2,500件答えている。

人が情報を探していた時間は月1,250時間減った。

ユーザーインタビューそのものに集中したい一方で、終わったあとの文字起こし整理や要約づくりに時間を取られていた。

分析を早く終えて、解決案のプロトタイプ作りへ進みたかった。

1. Google Meetの文字起こしを決まったDriveフォルダに入れる
2. GASが検知しGitHubにPull Requestを自動で立てる
3. PR作成をきっかけにClaudeが文字起こしと文脈資料を読む
4. 発話録・要約・示唆・分析の種の4つのMarkdownを作らせる
5. HTMLの図解レポートまで生成しSlackへ通知する

インタビュー終了から20〜30分で、要約5行・主な示唆5点・アイデアの種5点とHTMLの図解レポートがそろうようになった。

手作業でやっていた振り返り準備がなくなり、2人の記憶だけに頼らない振り返りができるようになった。

Slackに仕事が集まっているのに、必要な情報はチャンネルや各システムに散らばっていた。

探すたびにツールを行き来することになり、仕事の流れが止まっていた。

1. Slackの中で動くSlackbotを全社員が使える状態にした。
2. つなぎ先をGoogle WorkspaceとCRMと社内ナレッジに広げる。
3. 会議の準備や障害対応をSlackを離れずに依頼する。
4. 本人の権限と会話の文脈の中だけで答えるようにした。
5. 取材相手の経歴と要点を渡してブリーフィング資料を作る。

社員はSlackから出ずに調べ物と作業を片づけられるようになった。

一部の社員は週に最大20時間を節約した。

それまでの障害対応ツールが古い作りで変えにくく、障害の記録や振り返り、残った対応の管理をツールの外で回す場面が増えていた。

緊迫した場面で複数の画面を行き来するため担当者の負担が大きかった。

1. Datadogに障害対応の仕組みをまとめ呼び出しと監視を一画面でつないだ
2. Universal Service Monitoringで全サービスに同じ指標を付けた
3. どのサービスがどこにつながるかを自動で地図にした
4. 障害時にSlackの専用チャンネルとZoomが立ち上がる形にした
5. AIがSlackのやり取りから何が起きたかを自動でまとめた

障害の検知から原因の理解、復旧までの流れが速くなった。

画面を移る手間がなくなり、振り返りの作業も監視と同じ場所で済むようになった。

会社の伸びに分析の手が追いつかず、営業や製品の各部署から来る細かい質問にデータ担当が追われていた。

契約更新の話し合いでは先の使用量を見通す手立てがなく、ざっくりした計算に頼っていた。

1. 分析の土台をHexに寄せSnowflakeの倉庫につないだ
2. Hex ThreadsとSlackのBotを開き各部署が自分で数字を引けるようにした
3. 獲得から継続までを段階ごとのタブに分けひな形にした
4. 更新向けの予測をNotebook Agentに任せ指数平滑を選ばせた
5. 担当者が出てきたモデルと数字を確かめて社内に回す

分析担当でない人が予測モデルを30分で組めるようになり、更新の話し合いで36か月先までの使用量を数字で示せるようになった。

ひな形化でダッシュボード1件あたり4時間が浮き、年240時間の手作業がなくなった。

採用担当が2名しかおらず手作業のスカウト送付が限界に達していた。

声をかけきれない候補者が出て、会えたはずの人を逃していた。

1. AIスカウトのScout Baseに自社の採用要件を覚えさせる
2. 候補者の絞り込みとスカウト文の作成をAIに任せる
3. Slackのスレッドで挙がった候補者を採用部門と相談する
4. 相談のうえで送付を指示し文面はほぼ手直ししない
5. AIに返したフィードバックを社内のノウハウとして貯める

使い始めて1ヶ月で、カスタマーサクセスの職種について挙がってくる人材の合い方が目に見えてよくなった。

スカウトだけで一日つぶれていた状態から抜け出し、担当者は候補者との対話に時間を回せるようになった。

エンジニア採用で母集団を広げたいが、候補者を探す作業に時間がかかり、スカウト送付が月40〜45通で頭打ちになっていた。

採用代行は月40万円ほどの費用と情報の受け渡しの手間が重く、見送っていた。

1. Scout Baseに自社の採用要件を覚えさせる
2. 条件に合う候補者をAIに選ばせる
3. 候補者の確認と送付指示をSlack上で行う
4. 送るかどうかは採用担当が自分で決める
5. 担当者はスカウト文の書き分けに時間を回す

スカウト送付数は月40〜45通から78通へ増え、約1.5倍になった。

転職の意思がまだ固まっていない層にも声をかけられるようになった。

番組制作のリサーチを人手で回しており、社員が増えるだけでは事業の拡大に追いつかなかった。

社員情報などをNotionにためるにつれ、安全面の備えも足りなくなっていた。

1. 2024年10月にNotion AIを全社導入しエンタープライズプランへ切り替えた
2. コネクターでSlackやGoogleドライブをつなぎQ&Aで社内情報を探せるようにした
3. 週報の下書きをNotion AIに任せた
4. 外部で集めた情報と自社らしい構成の要素を読ませて企画案を出させた
5. 監査ログとSSOで誰が何をしたかを追える形にした

導入から2か月で番組制作の作業を軽くし、組織の安全面の体制づくりも進んだ。

一部の社員だけに入れていた他社のAIツールより、全社に入れても費用は安くなった。

必要な情報がメールやSharePointや表計算やレガシーシステムに散らばっていた。

SharePointに置いた500件以上の規程は文書を開いて読み込む必要があり1件調べるのに最大30分かかっていた。

1. 社内のやり取りをSlack Enterprise+へ全面的に移した
2. 検索でメールやSalesforceなどの情報を1つの層にまとめた
3. Slackbotへ普通の言葉で質問し規程や案件の状況を引き出す
4. 支払い状況の確認や顧客への連絡文の作成も同じやり取りで進める
5. 顧客メールの要点をつかみ返信の下書きを作らせる

最大30分かかっていた規程探しが1回の質問で済むようになった。

20分かかっていた案件まわりの作業は5分になりSlackbotの利用は月60回から14,000回以上へ伸びた。

数百人の社員がPrisma Browserのデモをするたびにアカウント作成やライセンスの初期化をSlackで頼んでいた。

頼み方が毎回違うため決まった処理の台本では読み取れず手作業が追いつかなくなった。

1. 社員はSlackに普段の言葉で依頼を書く
2. Zapierで組んだAIのワークフローが意図を読み取った
3. 複数のシステムにまたがってライセンスを割り当てる
4. アクセスの承認はチャンネルへ戻して人が押す形にした
5. 返信の書き方はA/Bテストで比べて決める

3,000人を超える社員が使うようになり、担当1人分の仕事がなくなって年15万ドルを減らせた。

個別に返す言い回しにしたことで追加の質問は20%減った。

収益部門にチームが増えた結果として取引先の情報が散らばった。

契約更新のリスクや拡大の芽が担当者のところで止まり対応が遅れていた。

1. 取引先ごとにSlackの専用チャンネルを用意した
2. 案件情報や利用状況と問い合わせを同じチャンネルへ集める
3. 会議後はGongの通話要約を同じ場所へ自動で投稿させた
4. Slackbotが各セグメント上位25社の状況を毎日まとめる
5. 週明けの全社共有の投稿もSlackbotが自動で作る

担当者がメモを配らなくても関係者が次の動きを判断できるようになり、数百万ドル規模の3年契約を取れた。

人が1時間以上かけていた月曜の共有投稿は自動で出るようになった。

情報がメールやWhatsAppや共有ドライブに散らばっていた。

基本的な状況をつかむだけで最大200種類のシステムを使い分ける必要があった。

1. Slack Enterprise+へ切り替えてSalesforceとつないだ
2. 会話とナレッジとワークフローを同じ場所へ集めた
3. 従業員がSlackbotへ普通の言葉で質問して規程を調べる
4. Slackbotとcanvasのタスク表で期限と空きを管理する
5. 新しいツールは足さず今あるSlackの中で済ませた

動画マーケティングのチームでは管理の仕事にかかる時間が週に3時間減り年間で丸2週間分にあたる。

数か月分の全社の動きをSlackbotで調べて経営陣にそのまま出せるcanvasを数秒で作れた。

営業の提案内容や技術のノウハウが部署ごとに分かれ、必要な人がすぐ見つけられなかった。

コンタクトセンターでは毎朝Agentforce Serviceのレポートを3〜4本開き、対応が要るケースを1件ずつ確かめるのに約30分かかっていた。

1. Slackbotにスキルを組み込んだ
2. 確認が要るケースと項目を自動で抜き出す形にした
3. 担当者はSlackから呼び出すだけで済むようにした
4. 重い設定画面からProfile一覧をCSVで出す仕組みを作った
5. 既存システムの通知をPower Automate経由でSlackへ流した

朝のケース確認にかかる時間は約30分から10〜15分まで縮み、リリース予定を見せる仕組みも2〜3日で形になった。

社内アンケートでは1人1日あたり平均7.2分の削減が出て、先に使い始めた層は14.0分だった。

ツールが増えすぎて社員が必要な情報にたどり着けず、中身も信用しづらかった。

要件定義書の下書きに数日かかり、開発と提供の速さを落としていた。

1. JiraとConfluenceの社内情報をRovoから引けるようにした
2. 要件定義書の下書きをボタン1つで出すエージェントを用意した
3. 出てきた下書きは担当者が読んで中身を詰める
4. 新しい案はIdea Scoring Agentが基準に沿って点数を付ける
5. Slackの中で製品の質問に答えるエージェントを置いた

営業からの質問の95%にエージェントが答え、追加のやり取りが要らない割合は40%から55%へ上がった。

要件定義書は数日かかっていた下書きが75%まで仕上がり、月40時間が空いた。

100を超えるサービスと複数の窓口に膨大な問い合わせが届いていた。

システムとデータが分かれていて対応の質もそろわなかった。

1. Agentforceがチャットでよくある質問に答える形にした。
2. 回答を社内の情報や注文データと過去の対応記録に結び付けた。
3. 定型のメールはその場で返し迷惑メールはふるい落とす。
4. 込み入った案件はそれまでの経緯を添えて担当者へ渡す。
5. MuleSoftでデータをつなぎ営業や販促も同じ顧客情報を見られるようにした。

問い合わせの80%をAIが処理し毎月25,000件のFAQと48,000件の定型メールに対応するようになった。

迷惑メールは99.9%を取り除けるようになった。

インサイドセールスから営業やカスタマーサクセスへ引き継ぐ手間が大きかった。

一つの案件に3〜5名が関わるうえ過去の商談記録が残っておらず経緯をつかみにくかった。

1. 商談はZoomの自動録画で残す
2. amptalk analysisで議事録と次の行動を自動で作る
3. 議事録をSalesforceの項目に合わせて入れる
4. 部署ごとに別のプロンプトを用意した
5. 業界用語を300語程度を辞書登録した

案件の確認会で担当者に一から説明させる必要がなくなった。

本稼働の遅れにつながる兆しを議事録から早く見つけられるようになり引き継ぎ情報の漏れもゼロになった。

問い合わせから受診までの手続きを人手でつないでいた。

患者の情報も複数のシステムに散らばり、担当チームが全体像をつかみにくかった。

1. Agentforceが問い合わせを受け患者の情報を聞き取る
2. 保険の資格を確かめて受診の予約まで進める
3. Data 360で複数システムの患者データをまとめる
4. よくある質問にナレッジ記事をもとにAIが答える
5. Slackで病歴の要約を頼み担当チームへ共有する

紹介や事務の手作業が減り、対応の速さと質が上がった。

担当チームは患者の状況をその場でつかんだうえで動けるようになった。

会社が大きくなり、オフィスの規則や手順についての質問が担当者へのDMで絶え間なく届くようになった。

答えはNotionの中に書いてあるのに、Wikiを探すより人に聞く方が早い状態だった。

1. Notion AIをSlackにつなぎメンションで回答できるようにした
2. スレッドの要約やデータベースからの情報取り出しを任せた
3. 社内の質問用チャンネルに独自エージェントを置いた
4. 誤答はスレッドや絵文字で指摘しWikiを直させた
5. 別のエージェントにアラートの一次分析を出させた

Smilersは公開してから世界全体で職場に関する依頼を2,500件以上さばき、チームは週に10〜20時間を節約できた。

担当者本人は1日2〜3時間、エンジニアはアラート対応で1日2時間以上の節約になった。

チャンネルやスレッドにもドキュメントにも情報はそろっていた。

しかし探して整理して動くまでが重く、すぐ見つかるはずの内容を探すのに何時間もかかっていた。

1. 社内Slackのbotに権限の範囲で会話や担当プロジェクトを踏まえて答えさせる
2. ドキュメント要約とSlackの会話を合わせ本人の書き方でまとめさせる
3. 会議前に関連情報を集めた概要を作らせ当日その場で直す
4. 営業では顧客向け説明や商談スコアカードの作成を任せる
5. うまくいった指示文をSlack canvasに保存してチームで使い回す

85,000人以上の従業員が週に最大20時間を短縮し、満足度は96%になった。

顧客対応の調整時間は75%減り、会議1件あたり25〜35分が削減された。

設置場所の持ち主との交渉や施設との契約確認など人と人のやり取りが多いのに、記録の仕方が手書きメモや記憶頼りでバラバラだった。

情報が抜けたり後から探せず、事業を広げる速さの足かせになっていた。

1. 現場責任者が朝礼の録音でNottaを試す
2. 交渉ではメモを取らず録音に任せ会話に集中する
3. 点検中の汚れや清掃の報告もその場で文字にする
4. 文字起こしと要約をSlackに流して部門間で共有する
5. 新人に過去の交渉記録や対応記録を読ませる

口頭のやり取りが残るようになり、内容の食い違いによるトラブルがなくなった。

人を介した伝え方による誤解もほとんど消え、カスタマーサポートの記録が開発チームに届いて2つの改善提案につながった。

キャンペーンを1本回すだけでも複数の道具をつなぎ合わせる必要があり、手作業の引き継ぎが多かった。

アプリを行き来する切り替えが仕事の勢いを削いでいた。

1. 普段使うSlack上のSlackbotをAIの入り口にした
2. 操作手順ではなく目的を言葉で書いて頼む
3. 特定チャンネルの直近24時間から詰まりどころを要約させた
4. Salesforceのデータと突き合わせ目標の危うさを判定させた
5. 定型の流れはワークフロービルダーで自動化した

Slackbotは社内で最も使われるAIの道具になり、質問から次の動きまで数秒で進めるようになった。

経営陣は毎日30分以上を取り戻し、データ集めではなく判断に時間を使えるようになった。

社員の8割が日本語を母語としないため、会議は多数派の言語で進み、終了後に内容を別の言語で説明し直す会議がもう一度必要になっていた。

会議に出た人と出ていない人の間で情報の濃さに差が生まれ、仕事が部門ごとに閉じていた。

1. 会議の音声をNottaに取り込み同時訳で各自の言語で発言できるようにする
2. 会議中はリアルタイムAI要約を各言語で画面に出す
3. 終わった要約をSlackへ自動で流す
4. 詳しい議事録はNotionに移し録画と全文はNotta上で見られるようにする
5. 決定事項のバックログへの反映は人が手で行う

翻訳のために開いていた2回目の会議が不要になり、やり取りにかかる手間が減った。

録画と要約が全員に共有されることで情報の差がなくなり、言った言わないの確認もなくなった。

リードは毎月数百件あっても商談につながらず、案件の進み具合はExcel頼りで見えなかった。

Salesforceを入れたあとも入力が受注後の事務作業になり、商談の障壁や次の一手がその場で更新されない状態が続いた。

1. 商談の文字起こしデータをSalesforceに取り込む
2. データ更新をきっかけにAgentforce for Salesを動かす
3. 議事録作成と要約に満足度判定と解約の兆し検知をつなげる
4. 基準を超えた案件だけSlackへ流す
5. 要約はGemini、成果物づくりはClaudeと使い分ける

実稼働100名のうち約7割がSlackbotを毎日使うようになり、コーポレート部門の利用率は100%に達した。

週1回の顧客向け案内文の作成は体感2時間から約1時間へ半減し、商談終了から約20分で離反の兆しが担当者に届くようになった。

推論基盤からAPIや課金やインフラまで開発の範囲が広すぎた。

従来のやり方では手が回らず、顧客から不具合の報告が来てもログや指標が5か所に散らばって切り分けに何日もかかっていた。

1. Claude Codeと他のエージェントを自社コードで比べ標準に決めた
2. プランモードで方針を固めてから実行と検証まで任せた
3. MCPでSlackやAsanaやGitHubやGrafanaをつないだ
4. 使い回す手順をSKILL.mdとして共有リポジトリに置いた
5. 子エージェントで原因の見立てと返信の下書きを作り人が承認した

社内の分析では、Claudeをよく使う開発者は使わない人の約4〜10倍の残るコードを生み出した。

顧客の障害の切り分けは数日のやり取りから数分になり、最も生産性の高いチームではおよそ95%がClaudeの書いたコードになった。

Celloの製品は顧客のシステムに組み込む性質上、コードや技術構成に合わせた細かい設定の質問が絶えなかった。

9か国に散らばる24名のリモート体制では、答えを知る人を探すだけで時間がかかっていた。

1. 顧客ごとにSlackコネクトチャンネルを開き、やり取りを寄せる
2. Slackを有料プランに切り替え、AI検索を使えるようにする
3. 設定の質問が来たらSlackbotに聞いて答えを取り出す
4. 製品更新やJiraなどの通知もSlackに集約する
5. 返ってきた内容を人が確認してから顧客に返す

400以上のSlackコネクトチャンネルで顧客とのやり取りを回し、メール中心の運用から切り替えた。

誰かがまとめ直さなくても過去の返信がそのままFAQのように積み上がり、最新の状態で答えられるようになった。

商談の記録は担当者が記憶を頼りに手で書くやり方で、主観が混じり顧客の生の言葉が残らなかった。

録画を見返して起こす作業も1件30分以上かかり、顧客対応の時間を削っていた。

1. 商談のオンライン会議にNottaを入れて録音する
2. 終了後に文字起こしと要約を自動で作らせる
3. 要約をコピーしてZohoの活動記録に貼り報告する
4. 共有リンクをSlackに流し関係者にメンションを付ける
5. 上長が録画にブックマークを付け改善点を本人に伝える

議事録づくりは1件30分以上から5分以内になり、チーム全体で週30時間近い時間が生まれた。

客観的な商談記録が部門をまたいで流れ、他サービスのクロスセル提案も出るようになった。