プロジェクトへ戻る

チームで運用中 · 改善中

BerryTicket

Discordの会話に散らばるチームの業務を、AIが拾ってボードとMacアプリにまとめる業務管理システムです。

Discordの会話に散らばるチームの業務を、AIが拾って業務にし、Macアプリ「Betty」とDiscordボットで確かめられる仕組みです。チームの合意のもとで生成AIを活用して1人で作り、チーム17人で運用しながら改善しています。

結果業務照会 約30秒→1〜2秒台 · 抽出呼び出し55%減(再現試算)

期間
2026.10 - 現在
担当範囲
生成AIを活用して1人で開発 · サーバー · AI抽出 · Macアプリ · Discordボット
チーム
個人開発(生成AI活用) · チーム17人で運用
リポジトリ
非公開リポジトリ

会話の中に、業務が埋もれていた

Blueberry Teamでは、業務の依頼や進捗がDiscordの会話の中で生まれます。会話はすぐ流れてしまい、誰が何を進めているのかが見えにくくなっていました。役割がはっきりしたチームほど、業務管理を誰かが続けることが負担になります。

そこで私が引き受け、チームの合意のもとで、会話をAIが読んで業務を作り、進行・完了を反映するBerryTicketサーバーと、Macアプリ「Betty」、Discordボットを生成AIを活用して1人で作りました。現在はチーム17人で使っています。運用開始から約1週間で、運用しながら全体を直している段階です。

会話を業務にし、担当者を空けない

業務の依頼や進捗は会話の中で生まれますが、そのままでは流れてしまい、後から一覧にできません。

メンバーに別のツールへの入力を求めると続きません。一方で、進行中なのに担当者が決まっていない業務が残ると、誰も手を付けないまま止まります。

Codexが会話を読み、業務の作成と進行・完了の反映を行う仕組みにしました。担当者のいない業務を自動で進行中・完了にするときは、根拠になったメッセージの書き手が登録済みのメンバー1人だけなら、その人を担当者にします。GitHubではPRの作成者か、担当者が1人だけのイシューの担当者を使います。書き手が複数、知らないアカウント、すでに担当者がいる場合は空けたままにし、自動処理を取り消すと割り当ても戻ります。

適用前(2026年10月24日)は、進行中の業務70件のうち45件に担当者がいませんでした。同じ日に適用し、効果は測定中です。過去の業務はさかのぼって変更していません。

実装の詳細を見る
  • Discordの会話からAIで業務を作成
  • 進行・完了の発言を既存の業務へ反映
  • 判断できるときだけ担当者を自動で割り当て、曖昧なら空けたまま

自動で決める仕組みでは、決められるときより、決めずに空けておく条件を先に決めることが大事だと学びました。

聞かれたら、すぐ答える

ボットに「やることを教えて」と聞くたびにAIモデルを呼んでいたため、返事まで約30秒かかっていました。

業務の一覧はすでにデータベースにあり、答えに必要なのは整形だけでした。待ち時間が長いと、ボットに聞くより自分で探す方が早くなってしまいます。

業務照会ではモデル呼び出しをやめ、データベースから取り出した業務をテンプレートで返すようにしました。完了は返事のボタンからその場で処理できます。

変更前は、2026年10月21〜24日の運用ログ72時間分で、モデルが答えた会話16〜17件の中央値が準備8.0秒+生成23.2秒(生成のp90は50.5秒)でした。変更後は10月24日の1回の測定で、ボットがメッセージを受けてから返事を送るまで1.2〜1.4秒でした(単一測定)。決まった質問以外の会話は、今もモデルが答えて30秒前後かかります。

実装の詳細を見る
  • 業務照会からモデル呼び出しを除去
  • テンプレート応答で自分の業務を返却
  • 返事のボタンで完了を処理

AIを使う機能でも、答えがすでにデータにあるなら、モデルを呼ばない方が速く確実だと学びました。

AIを呼ぶ回数と量を減らす

会話を読むたびにAIを呼ぶと、費用と待ち時間が会話の量に比例して増えます。

減らしすぎると業務の取りこぼしが増えます。抽出の質を保ちながら、呼び出しの回数と渡す量を減らす必要がありました。

既存の業務と照らし合わせるときは、モデルが実際に読む項目だけを渡し、確認は元のデータで別に行うようにしました。リアルタイム抽出は、会話が30秒止まるたびに呼んでいたのを、2分止まったところ(最長10分)でまとめて呼ぶ形に変え、笑いや絵文字だけのメッセージでは呼ばないようにしました。

2026年10月22日の変更で、1時間ごとのDiscord照合1回あたりの入力トークンは平均202,472から104,074へ約49%減りました(変更前後それぞれ4回の平均)。リアルタイム抽出は、直前24時間の実際のメッセージ1,854件で規則だけを変えて再現した試算で、229回から103回へ55%減りました(再現の元になった実際の呼び出しは231回)。その代わり、抽出までの平均待ち時間は約4.9分になります。

実装の詳細を見る
  • 照合にはモデルが読む項目だけを渡し、確認は元データで実施
  • 抽出は2分の静けさ(最長10分)でまとめて呼び出し
  • 笑い・絵文字だけのメッセージでは呼び出さない

AIの費用と速さは、モデルの選び方より、いつ何を渡すかで大きく変わること、そして減らすたびに待ち時間とのトレードオフを数字で確かめる必要があることを学びました。

作業ツールと業務を、一か所に

業務はGitHubのPR・イシューやFigmaの変更とも結びついていますが、それぞれ別の場所にありました。

ブラウザでボードを開く手間があると、毎日確かめる習慣になりません。

GitHubのイシュー・PRは読み取り専用で定期的に同期し、本文の業務番号やDiscordのリンク、closes参照で先に結びつけ、残りはAIが範囲を比べて結びつけるか確認を求めます。Figmaはファイルとコメントを定期的に取得して前回と比べ、変わった画面や新しい依頼を既存の業務と照らし合わせます。そのうえでGo・Wails v3・Svelte 5でMacアプリ「Betty」を作りました。ログインはDiscordのOAuthです。

チーム17人が、Discord・Macアプリ・ボットから同じ業務を見られる状態で運用しています。

実装の詳細を見る
  • GitHubは業務番号・リンク・closes参照で連結し、残りはAIが比較
  • Figmaは定期取得したスナップショットの差分を業務と照合
  • 自分の業務・チームボード・チェックリスト・ゴミ箱・整理モードを持つMacアプリ

道具を増やすより、すでに使っている場所に業務を届ける方が使われると学びました。

業務が流れる道

会話から業務を作り、どこからでも同じ業務を見られるようにする

  1. 01

    Discordの会話

    依頼・進捗・完了

  2. 02

    BerryTicketサーバー

    Node.js · SQLite · Docker Compose

  3. 03

    AIによる抽出

    Codexで業務を作成・反映

  4. 04

    作業ツールの連結

    GitHub · Figma(定期同期)

  5. 05

    見る場所

    Macアプリ Betty · Discordボット

チーム17人で運用しています(運用開始から約1週間)。リポジトリは非公開で、画面はデモデータで撮影しています。

AIに任せる部分と、データから決まる部分を分けて考えるようになりました。

未検証の範囲

運用を始めたばかりで、全体的に改善を続けている段階です。業務照会の変更後の時間は1回の測定、抽出呼び出しの減少は実際のメッセージを使った再現試算、担当者の自動割り当ては効果を測定中です。業務抽出の精度や取りこぼし、チームの業務の進み方の変化はまだ測っていません。

次に確かめること

  • 業務抽出の精度と取りこぼしを測る
  • 使う人の声をもとにBettyの画面と操作を直す
  • 業務が実際に早く進むようになったかを確かめる