こんにちは、サイバーエージェント AIオペレーション室の大城 海斗(@Kaito14123925)です。
2024年にバックエンドエンジニアとして新卒で入社し、現在は生成AIを活用した社内プロダクト開発に取り組んでいます。
この記事では、私が入社1年目で開発したSlack上の議事録生成Bot「議事録くん」について、
- なぜ議事録Botを作ったのか（背景と課題）
- どんな工夫で“使われる”プロダクトになったのか
- 技術スタックとアーキテクチャ
- 実際の利用状況
を振り返り、新卒エンジニアの目線でお話しします。
PM目線で書いた記事が下記となります。 併せて読んでいただけたら幸いです。
週100人以上が使うSlackBOT「議事録くん」、“使われる”生成AIプロダクトの裏側｜CyberAgent｜AIオペレーション室
「使える」じゃなくて「使われる」生成AIを
2023年以降、ChatGPT, Gemini, Claudeなどさまざまな生成AIが急速に普及し、「議事録をAIに任せられるのでは？」と考えた人も多かったと思います。
でも実際の現場では、
- プロンプトが難しい
- 毎回アプリやブラウザを開くのが面倒
- アウトプットに不安がある
- 業務が忙しく試す時間がない
といった理由で、生成AIをうまく使いたいが使えていない現場社員の方は多くいるのではないでしょうか？
私は、サイバーエージェントの子会社であるCyberACEと協力して議事録を非エンジニアでも自然と使いたくなる・気づけば使っている──そんな「使われる」議事録ツールを目指して開発に取り組みました。
すでに行われていた施策と、その限界
実は、プロンプトの難しさを解消するために、現場ではすでにいくつかの工夫が行われていました。
- Difyで作った専用アプリを共有
- ChatGPTの「GPTs」機能を使ったテンプレBotを展開
これらは、あらかじめプロンプトを組み込んでおくことで、誰でも一定の精度で議事録を生成できるようにしたものでした。
ただ、現場で使うには他にも壁がありました。
- 「あのリンク、どこに保存してたっけ？」
- 「今、わざわざ別タブ開くの面倒…」
- 「またあのツール開くのか…ちょっと慣れない」
そんな小さな手間が積み重なって、気づけば使われなくなっていくというのが限界でした。
理想と現場と開発のギャップ
では、どのようにすれば使われる議事録ツールになるのか。まず、現場の理想は以下になります。
現場の理想
- 現状の業務を維持しつつ、勝手に業務フローに溶け込んでいき生産性が向上する。
多くの人にとって、忙しい中で新しいツールを試す時間や余裕はありません。だからこそ、説明がなくても直感的に使えて、自然と業務に溶け込む“便利な仕組み”であることが重要だと思っております。
次にみなさん、生成AI時代の議事録というと何が思い浮かびますか？
私は、最初、以下だと思いました。
理想シナリオ（ありたい未来）
- 会議が開始されたら自動で録画 & 文字起こし
- 会議終了直後に担当者へ議事録が配信
- 過去の発言を横断検索できる知識ベースが自動で構築
立ちはだかる現実
| リスクカテゴリ | 具体的な懸念 | 影響 |
|---|---|---|
| 開発時間 | 全機能を作ると数ヶ月〜半年コース | 途中で要件・技術が陳腐化する恐れ |
| 技術選定 | ASR／LLM は日進月歩でコストも変動 | リリース前にベストプラクティスが変わる |
| 品質 | 音質・話者分離・要約精度…検証項目が多い | テスト工数が膨らむ |
| プロダクト‑マーケット Fit | 作ったが使われないリスク | ROI がゼロになる |
つまり、完璧を求めて作りはじめると不確実性が高いため、使われないリスクが高まり開発した意味がなくなる。これらを防ぎつつ最小限の開発工数でリリースを目指す。
作り込みすぎ”を防ぐための5つの開発戦略 ─ 1週間で価値検証を回す
- 価値のコアを抽出 → “議事録の生成” さえ出来れば現場は助かる と定義
- 既存アセットを活用 → 発言の文字起こしファイル（Zoom/Meet）がすでに取得可能だった
- UX を最低限に削る → アップロード + 種別選択 + 生成 の 3 ステップに集中
- 測定指標を先に決める → “生成数 / 週” と “作業時間削減率” を KPI に設定
- ご近所を探せでプロンプトの責務分離→ アジャイル開発でよく用いられる「ご近所を探せ」という考え方を応用し、プロンプトエンジニアリングの役割は、私（エンジニア）よりも、その領域に詳しく、かつAIを日常的に使いこなしているCyberACEの現場社員（ドメインエキスパート）の方が適任と判断。よってプロンプト設計は現場社員が作成する形になりました。
こうして “作る → 触ってもらう → 改善点を取る” サイクルを 1 週間で回せる状態を最優先しました。
プラットホーム選定：Web? or Slackbot?
下記の理由でSlack botを選定しました。
| Web | Slackbot | ||
|---|---|---|---|
| 開発速度 | ✕ | ◎ | webは、認証認可・画面などSlackに比べて開発対象が広く提供速度が遅くなる |
| フィードバック速度 | △ | ◯ | Slack上なので、チャンネルに所属している場合、使用している様子、フィードバックをその場で確認できる |
| 現場受け入れ | △ | ◯ | 日常的に使うSlackは比較的に使われやすい、Webは認知負荷がかかる |
| UIUXの自由度や高度な機能の開発 | ◎ | △ | Web開発は、自前実装のためUIUXの自由度や高度な機能開発が非常に高い一方で、Slackbotは、SlackUIに依存します |
Webアプリケーションで提供しようとすると、
インフラ構成・画面設計・バックエンド設計・DB設計・認証認可・セキュリティなど、
本質ではない要素にも多くの設計・実装コストが発生します。
これは、単に「議事録を生成する」という1つのシンプルな価値を提供するためには、明らかに過剰で不確定要素も多く、不要なことが多すぎる状態です。
仮に私がこのWebアプリ版のスコープで見積もりを行った場合、
何かしら見積もりきれていない項目が必ず後から出てきて、工数は膨らみ、結果としてリリースは遅れます。
それはつまり、生成AI時代の開発速度に追いつけないと判断し、Slackbotにしました。
参考書籍
正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について
Slackbotでのアーキテクチャ
Slackを用いることで、シンプルなアーキテクチャにすることができました。
LLMはGPT、Geminiを以下の理由から併用しています：
- 障害発生時の冗長性
- LLMごとの特性や精度差を踏まえた柔軟な選択
採用しているLLM：
- GPT-4o
- Gemini-2.5-Flash
APIGatewayの29秒ルールは、SlackAPIの仕様上、回避
APIGatewayには、最大統合タイムアウト29秒という制約があり、LLMを内部処理に入れているとどうしても、29秒以上処理にかかるケースが存在します。自分的にはそこが初期構想の悩みポイントになると思ってました。
しかし、SlackAPIの仕様を見ると3秒以内にレスポンスを返さないと、最大3回まで複数回リクエストが実行されると書かれておりました。つまり、Slackのルールに従えば、APIGatewayのタイムアウトは無視できる。ということになります
SlackAPIの仕様: 3秒ルール
Slackbotなどからくるリクエストは、3秒以内にHTTP 200を返さないと最大3回リトライされる仕様になっています。
Slackは任意のタイミングで任意のレスポンスを送信できるAPIも提供しているため、メイン処理は非同期で走らせ、完了後に結果だけを返す、という構成が可能になります。
実装例や詳細は割愛しますが、「lazy listeners」やSlack公式ドキュメントに情報が豊富です。
プロンプトのテンプレート化
事前に、プロンプト作成をCyberACEの現場社員に依頼し、作成できたものをSlackbotに組み込みました。
ユーザは、以下の手順で議事録を生成します。
- Slack上に議事録化したいファイルをアップロード
- 以下のように表示された会議の種類を選択する
- 選択されたプロンプトテンプレートをもとに議事録が生成される
こうすることで、会議の種類ごとに最適化されたプロンプトをユーザが使用することでより欲しい議事録が生成されます。
1週間で試験導入、そして拡大：週300件・週100人に利用されるまで
スモールスタート：試験導入で価値を検証
最初に提供した対象は、マネージャー層＋業務の中で会議が多い一部の現場社員。以下の観点で初期検証を実施しました。
- ツールの受容性
- 出力品質
- 実務導線への馴染みやすさ
Slack上で、文字起こしファイルをアップロード → 会議を選択 → 議事録を生成 → 出力、という一連のフローが完結できる設計により、現場での使いやすさが評価されました。
また、プロンプトは現場業務を深く理解している社員によって設計されており、実際の運用に即したアウトプットが得られたのも好評でした。これをもってCyberACE全体への展開が決定しました。
定量成果：導入効果が数字に現れる
KPIの設定と実績
| 項目 | 初期設定 | 現在 |
|---|---|---|
| 対象会議数（週） | 50件 | 300件以上 |
| ユーザー数（週） | 限定社員 | 100人以上 |
「使われるプロダクトかどうか」は、KPIが継続的に伸びているかで評価。Slack上での利用数・ユニークユーザ数を常にトラッキングし、改善サイクルの中で伸び率を確認しました。
現場の声と継続利用の壁
一定の利用が進んだことで、ユーザーからのフィードバックも多様化しました。
よく寄せられた課題
- 「テンプレートが自分の会議には合っていない」
- 「毎回同じプロンプトを設定するのが面倒」
- 「出力される議事録の粒度が合わない」
この段階で分かったのは、「議事録の粒度や文体、構成」は職種・会議目的ごとに大きく異なるという事実です。提供するテンプレートが、どれだけよく作られていても、最大公約数でしかなく「個別最適にはなり得ない」ことを実感しました。
機能改善：カスタムプロンプトの導入
上記の課題に対しては、単なるテンプレート追加ではなく、「ユーザーが自分自身で使い慣れたプロンプトを登録・選択できる機能」＝カスタムプロンプト機能を実装。
- プロンプトをSlack上で個別に登録
- 会議種別ごとに使い分け可能
この実装によって、再現性のある継続利用が可能になり、ユーザー1人あたりの利用頻度が飛躍的に向上しました。
登録したプロンプトは通常通り使用することができます。
終わりに
Slack上で動く「議事録くん」の開発を通じて、新卒1年目の私が学んだことは、
「技術選定は自己満足ではなく、ユーザーへの価値提供のためにある」ということです。
どれほど最新の技術や美しい設計であっても、現場で実際に使われなければ、それは“価値”とは呼ばないと思ってます。今回、「まず届ける」「小さく始める」ことを大切にし、ユーザーのフィードバックを一つひとつ取り入れながら、実用性を磨いてきました。生成AIの技術は日々進化していますが、本当に重要なのは、その技術が現場の中で、自然に、継続的に使われることだと考えています。今後も私は、ユーザー視点に根ざしたプロダクトをつくると同時に、エンジニアとして技術力の向上にも取り組みながら、「すごいAI」ではなく「現場で使われるAI」を開発していきたいと思います。