こんにちは！fumiyaki です。
私たちのチームでは半年ほど前から「AIデー」というAIを活用する日を作り、運用しています。1スプリント2週間のうち、スプリント初日をまるごとAIデーにあてて、各メンバーが自由にAIを触る日です。
この半年で、AIデーからはいろいろな成果物が生まれました。本記事ではその中から、私が個人的に「これは紹介したい」と思ったものを3つピックアップして紹介します。
- Slackスレッドでの議論反映 — スレッドでの議論を Devin が Issue やドキュメントに反映してくれる仕組み
- エラー自動調査 — Slackへのエラー通知をトリガーに Devin が自動で調査して Issue まで起票する仕組み
- kaigi — 会議後のTodoをまるごと自動化する常駐Claude Code
どれもメニューマネージャー（飲食店のメニューをフードデリバリープラットフォームへ配信するシステム）を作っているチームの中で生まれたものです。
AIデーについて
AIデーは、2週間スプリントの初日をまるごとAIを触る時間にあてるという日です。
以下のような形で運営されています。
- テーマ縛りはなし: 業務と関係ない実験でも構わない
- 成果物は必須ではない: 動くものが出来上がらなくてもOK
- 共有会: その日の終わりに何をやったのか、知見を共有
導入の背景は、「AIを皆がどうやって使っているのかがわからない」という素朴な課題感でした。毎日の業務をこなしていると、他のメンバーが普段どんなプロンプトを書いているのか、どんなツールをどう組み合わせているのかはなかなか見えません。各自の工夫が個人の中に閉じてしまっていて、チームとして「AIの使い方」を蓄積する場が無い状態でした。
スプリントの中でAIデーは１日しか無いので「成果物を出す」という縛りを意図的にかけていません。手を動かすこと、そしてその日の終わりに「こういうことを試しました」を話すこと。この2点だけを重要視していて、結果や成果物は二の次、という設計にしています。
とは言え半年もやって成果物が0だったわけではないので、いくつかの成果物をピックアップして紹介するのがこの記事となります。
① Slackスレッドの議論を Issue に反映する Devin Playbook
最初に紹介するのは、Slack のスレッドで Devin を呼び出して一言依頼するだけで、そのスレッドの内容を解析して GitHub Issue やドキュメントの PR を自動で作ってくれる Playbook です。
きっかけは、開発チームあるあるの悩みでした。Slack で決まったことが Issue に反映されない、というやつです。
仕様管理には GitHub Issue を使っているのですが、日々の議論は Slack で進むので、「Slack で『B ではなく A で行こう』と決まったのに Issue には古い情報のまま残っている」「スレッドで『これもやらないとだね』と出たタスクが誰の TODO にもなっていない」「数週間後に『あの話どうなったっけ？』と聞かれて Slack を遡る羽目になる」といったことはあるあるですよね。
こうなる原因はシンプルで、Slack の議論を Issue に書き移す作業が手動で面倒くさくて、忙しい開発の中ではどうしても後回しになっていた、という話です。結果として、Issue が最新の状態を反映していない状況が生まれます。
この Playbook は、現在の運用を変えずに問題を解決することを狙っています。普段通り Slack のスレッド内で議論する。最後に Devin に一言依頼するだけで、Devin がスレッドを読み、内容を自動で分類して、適切な場所に情報を落としに行く、というのが大まかな流れです。
分類は「知識系」と「タスク系」の2つで行っています。
- 知識系（技術仕様の議論、手順やワークフローの説明、ポストモーテムなど）→ GitHub にドキュメントの PR を作成
- タスク系（バグ報告、改善要望）→ GitHub Issue を作成し、GitHub Projects にも追加、Type フィールド（Bug / Feature / Task）まで設定
両方に該当する場合はドキュメントと Issue の両方を作りますし、「知識」「タスク」のどちらかを明示して分類を上書きすることもできます。既存の Issue に議論の続きを追記したい場合は、Issue の URL を添えて依頼すれば、そのスレッドで出た新しい内容だけが追記されます。
設計のちょっとした工夫として、Devin にはドキュメントや Issue を書かせる前に必ずコードベースを調査させるフェーズを入れています。そうすると「○○画面の △△ コンポーネント（src/components/...）で、こういう条件のときに〜」のように、ファイルパスや関数名を含んだ具体的な記述になってくれて、後から読み返したときの情報量がぐっと上がります。Devin が Slack のスレッドだけを頼りに書くと、どうしても抽象度の高いふわっとした文章になりがちなので、この「まずコードを読んでから書く」の強制はかなり効いています。
もう1つの工夫は少し背景説明が必要なのですが、tacomsという会社はmobile order lab(以降はmolと表記)との合併しており GitHub Organization が2つあります。今回作った仕組みは tacoms 側と mol 側の Devin を 2段構成 で繋いでいます。
Slack 連携している Devin は tacoms 側に紐付いているのですが、対象のリポジトリは mol 側にあるため、tacoms 側の Devin が Slack スレッドを解析して、その結果を mol 側の Devin API に curl で渡してセッションを立て、mol 側が実際の GitHub 操作を実行する、という構成です。
制約自体は面倒なのですが、結果として「解析・分類」と「GitHub 操作」の責務が自然に分かれて、見通しの良い設計にはなりました！…多くの課題がありますが早く合体して欲しいです(泣)。
この Playbook は「Slack スレッドでの議論を、運用を変えずに Issue へ集約する」ための仕組みです。Single Source of Truth は AI 時代にとても大事だと考えています。
② エラー自動調査 — 属人化を溶かす
2つ目は、エラーの自動調査を Devin にまるごと任せる Playbook です。
メニューマネージャーでは、UberEats、Menu Inc. など複数のフードデリバリープラットフォームへメニューを配信しています。エラーはどうしても発生するものなので、Slack にエラー通知が届くたびに、誰かが DB・Google Cloud のログ・コードを辿って原因を特定する、という作業が発生するものです。
調査の流れは毎回ほぼ同じで、「エラーコードを確認 → データベースでジョブやスケジュールの状態を調べる → トレース ID で Google Cloud のログを検索 → 配信基盤システムのコードを読む → 原因を特定する」というステップでした。
問題は、この調査ができる人が限られていたことです。アカウントの権限の問題やデータベースのクエリ、Google Cloud のログの検索方法、配信基盤システムのコード構造を知っていないといけません。特定の人しかエラーに対応できないという属人化状態になっていました。
これを Devin Playbook にまるごと覚えさせたのが、この仕組みです。エラー通知をきっかけに Devin のセッションが起動し、以下を自動で実行してくれます。
- 対応不要ブランド（テスト店舗など）のスキップ
- CSV データからのエラーパターン分類
- データベースのスキーマに基づく状態判定
- トレース ID を使った Google Cloud のログの横断検索
- コードパスの追跡による該当配信基盤システムの特定
- 外部 APIでの現在の状態を確認
- 調査結果の Slack スレッド投稿
- バグ疑いの場合は GitHub Issue を起票（既存 Issue との重複チェックも！）
人がやっていた調査の流れを、そのまま Devin に実行させている形です。以下、設計で気を使ったポイントをいくつか紹介します。
調査を方法論に落とし込む
8 つのステップは Observe → Trace → Analyze → Report という調査メソドロジーに沿って構造化しています。データベース調査や Google Cloud のログ調査が Observe、コードパス追跡が Trace、結果統合が Analyze、Slack 投稿と Issue 起票が Report、という対応です。
わざわざ方法論に落としているのは、Devin に「次に何をすべきか」を明確に指示するためです。自由度が高すぎると調査が発散するリスクがあって、方法論に沿って順に進める構造が調査品質の安定に効いています。
データベース調査を Google Cloud のログより先に行う
一般的にはログから調べ始めることが多いかもしれませんが、この Playbook ではデータベース調査を先に行う順番にしています。データベースで判明した trace_id やタイムスタンプを Google Cloud のログの検索条件に使うことで、ログ検索の精度を上げるためです。人間が調査するときもデータベースの状態を先に確認してからログを絞り込む方が効率的なので、その順序を明示的に Playbook に組み込んでいます。
READ-ONLY 原則
Playbook には「Forbidden Actions」として以下を明示的に書いています。
- コードの変更・ファイルの作成
- データベースへの書き込み系操作全般
- Google Cloud リソースの変更
自動で動くものだからこそ、安全性を最優先にしました。調査の目的は原因の特定であって、修正ではありません。READ-ONLY に徹することで、自動実行による意図しない副作用を排除しています。
Playbook と Knowledge を分離する
個人的に一番気に入っているのが、Devin の Playbook と Knowledge を分離していることです。
エラーパターン表、対応不要ブランドリスト、データベースクエリのテンプレート、Google Cloud のログの検索パターン、各配信プラットフォームの認証手順 — こういった「データ」に相当するものは全部 Knowledge 側に寄せていて、Playbook 側は「何をどの順番でやるか」だけに集中させています。
こうしておくと何が嬉しいかというと、新しいエラーパターンが見つかったときにコードや Playbook を触らずに、Devin の WebUI から 1 行追記するだけで次回から自動で判定してくれるようになります。運用で「このエラーコードは毎回こういう原因だった」という知見が溜まったら、Knowledge に追記するだけ。コード変更もデプロイも不要です。調査の知見がそのまま仕組みの精度に変わっていく感覚は、運用していて気持ちがいいですね。
もうひとつ、Knowledge の編集は WebUI 上の操作で完結するため、エラーパターンの追記や連絡先の変更くらいであればエンジニアでなくても触れる、というのも地味に大きいポイントです。
Issue の重複チェック
バグ疑いと判定された場合は GitHub Issue を自動で起票しますが、同じエラーが繰り返し起きたときに Issue が乱立しないよう、起票前に既存 Issue との重複チェックを入れています。
具体的には、Issue を作成するときに body の末尾に識別キーを HTML コメントで埋め込んでいます。
<!-- auto-investigation-key: {"error_code":"...","platform":"...","function":"..."} -->
次回の調査で同じエラーコード・プラットフォーム・関数の組み合わせが出てきたら、この識別キーで既存 Issue を検出して、新規起票の代わりに既存 Issue のリンクを Slack に返す、という作りにしています。
③ kaigi — 会議後のTodoを全自動化する常駐 Claude Code
3つ目は kaigi です。会議が終わるたびに発生する「議事録を書く」「GitHub Issue を起票する」「カレンダーを更新する」「ドキュメントを直す」という一連の作業を、Claude Code にまるごと任せてしまう仕組みです。
どのチームでも発生するこの地味な作業を消し去るために、Claude Code をローカルに常駐させ、Google Drive と Slack の変化をバックグラウンドで監視する構成を組みました。
技術的な肝は、Claude Code の2つの機能を組み合わせていることです。
1つ目は、バックグラウンドで監視用のプロセス(hookやポーリングなど)を動かしておき、そのプロセスが標準出力(log)に書き出したタイミングで反応する、というイベント駆動の仕組みです。Monitor tool と呼ばれています。
ログの出力がなければClaude Codeは何もしないので、待機中のコンテキスト消費をゼロに保てます。
kaigi ではこの Monitor を2つ走らせていて、片方は Google Drive を90秒間隔でポーリングして新しいトランスクリプトを見つけたら TRANSCRIPT: {...} を吐き出し、もう1つは Slack の Socket Mode で WebSocket を張って #fb を含むメッセージが投稿された時に NEW_FB: {...} を吐き出す、という分担になっています。
2つ目は、議事録のスレッドごとに独立したエージェントを立ち上げる仕組みで、こちらは Agent Teams を使っています。スレッド内で #fb のメッセージが検知されると、そのスレッド専用のClaudeインスタンスがCreateTeamで作られ、そのインスタンスが Monitor を使ってそのスレッドの返信を監視します。
FBの内容をエージェントが解釈し、 必要があれば kaigi システムを worktree で複製してPRの作成まで行います。Slackのスレッドごとに独立したインスタンスなので、仮に複数人が別々のスレッドで同時にFBしても、それぞれの文脈に集中して正確に動いてくれます。
会議後のたいくつな作業を解消するだけでなく、Slack でフィードバックを投げるとClaude Codeがこのシステムを進化させてくれます。
AIデーを回してみて
半年AIデーを続けてみて、一番変わったのはチームの AI に対する解像度だと思います。共有会で「こんなツールを試した」「このプロンプトはこう組むとうまくいく」という話をしているうちに、自然とチーム全員の AI への解像度が上がってきていると思います。
AIデー導入前に感じていた「皆がどう使っているかわからない」というモヤモヤは、今はあまり感じません。
一方で、正直に言うとまだまだ「一気に景色が変わった！」というフェーズには辿り着いていないというのが率直なところです。今回紹介した3つの仕組みも、それぞれ単体では便利なのですが、まだバラバラの点として存在している状態です。これらの点がどこかで線として繋がったとき、初めて「開発フローが変わった」と言える気がしていて、そこを目指しながらAIデーを続けています。
まとめ
AIデーの説明とそこから生まれた3つの成果物を紹介しました。
- Slackスレッドでの議論反映: Devin を使って Slack の議論を Issue・ドキュメントに自動変換する
- エラー自動調査: Devin Playbook で調査を方法論に落とし込み、属人化を剥がす
- kaigi: Claude Code の Monitor × Team で、会議後のTodoを常駐エージェントに任せる
どれも「普段の業務を少し楽にする」ための仕組みですが、AIデーというまとまった時間がなかったら、おそらくどれも着手できていなかったと思います。「成果物は必須ではない」という緩めのルールが、結果的にチームにはちょうどよかったのかもしれません。
同じような悩み（AI をどう使うかチームの中で見えない、試す時間がない、知見が個人に閉じる）を持っているチームがあれば、2週間に1日だけでもAIデーを試してみると、半年後に何かしら見える景色が変わっているかもしれません。
