Gemini議事録からGitHub Issue作成を自動化する仕組み
Posted on
はじめまして。Core Platform Dept.でJourney機能の開発に携わっているTsutomu Ikedaです。
今回は、日々のミーティングの議事録から、話し合った内容を元にGitHub Issueを自動的に作成する仕組みを構築した話を紹介します。
背景と課題
朝会やWeeklyミーティングで「これやっておきます」と発言したにもかかわらず、その内容をすっかり忘れてしまうことありませんか？私は多々発生してしまっています。自分が発言したことを忘れずに記録してリマインドできる仕組みがあったら嬉しいなと思い、自動でIssueを作成するbotを作成しました。
なぜ発言したことを忘れてしまうのか。これにはIssueを作成する作業自体の面倒さが要因の1つとしてあります。
「やる」と決めたタスクをIssueにするまでには、以下のようなステップが必要です。
- GitHubを開く
- タイトルを考える
- どこまでやるか（スコープ）を考える
- だいたいこの辺から着手するというあたりを付けてメモする
これらのステップを踏んでいるうちに面倒になり、「後でやろう」と放置した結果、結局やらないままになってしまうことがありました。
一方で、現在社内で利用されているGoogle MeetのGeminiによる議事録作成機能で抽出される「推奨されるネクストステップ」の精度が実用的なレベルだと感じていました。せっかくの情報を見ずに捨ててしまうのはもったいない、これをIssue作成に活用できないかと考えました。
システムの全体像
構築したシステムの全体の流れは以下のようになっています。
- ミーティングが終了し、Googleドライブに議事録ファイルが作成される。
- GAS（Google Apps Script）が議事録の作成を検知し、その内容を元にGitHubへPull Request (PR) を作成する。
- PR作成がSlackに通知される。
- PR作成をトリガーに、GitHub Actionsで次の2つのワークフローが実行される。
- Issue作成ワークフロー
- ADR（Architecture Decision Record）やアーキテクチャドキュメントの更新ワークフロー
この仕組みにより、ミーティングが終わると自動的に議事録の内容が解析され、Issue作成やドキュメント更新が走るようになりました。
実装における工夫点
このシステムを構築する上で、特に工夫した技術的なポイントをいくつか紹介します。
1. Sub Agent (Task) を活用した並列実行と最適化
Issueを作成する際には、主に「アクションアイテムの抽出」「関連するソースコードの調査」「既存Issueとの重複チェック」という3つの観点での評価することにしました。この評価を効率化するためにSub Agent（Task）を活用しています。Sub Agentを活用することで以下のようなメリットが得られます。
- 並列実行: 独立したタスクとして並列に処理できるため、全体の実行時間が短縮されます。
- コンテキスト削減: 個別のタスクがそれぞれセッションを持つことで、全体のコンテキストが肥大化することを防げます。
- 批判的なレビュー: 一度生成された内容に対し、別の視点（エージェント）から批判的にレビューさせることで、LLMが自身の生成内容を妄信してしまうリスクを低減できます。
- コスト最適化: 難易度の高いタスクには高性能なモデル（Opusなど）を、比較的単純なタスクには軽量なモデル（Sonnetなど）を割り当てることで、精度とコストのバランスを最適化できます。
2. コマンド実行時のパーミッションエラー回避
GitHub Actions上でClaude Codeを動かす際、セキュリティの観点から実行可能なコマンドを allowedTools（ホワイトリスト）で許可する必要があります。
ここで少しハマったのがgh issue create コマンド自体は許可しているにも関わらず、Issue作成が失敗する現象です。
原因をログから辿ったところ、Claude CodeがIssue本文を渡す際、コマンド置換$(...)を使用していたことが判明しました。この置換内部のコマンド実行が許可リストに含まれていない操作とみなされ、パーミッションエラーが発生していたのです。
そこで、本文を一度ファイルに出力しgh issue create --body-file path/to/file を用いて読み込むようプロンプトを改善しました。細かい対応ですが、挙動を安定化させる上で重要なポイントでした。
3. Issue作成の閾値調整
いくつか議事録を読み込ませた結果、Claude Codeがかなり賢く重複の排除を行ってくれるため「これはIssue化するほどではない」と判断し、Issueが作成されないケースが多く見られました。しかし、今回の目的は精度高くIssueを抽出することではなく、「取りこぼしをなくす」ことです。
そこで、Issue作成の条件を緩めに調整し、「実行可能であればとりあえずIssue化する」方針に変更しました。不要なIssueであれば後から人間がクローズすれば良いため、まずは漏れなく拾い上げることを優先しました。
導入してみての変化
導入してから1ヶ月ほど経過した時点で以下のような変化がありました。
1. ミーティング終了後のIssue作成作業からの解放
数分から数十分の作業ではあるものの、ミーティングで出たやることリストを覚え、忘れずに記載するという脳内メモリを消費する作業から解放されたことで、会議後スムーズに開発作業に集中できるようになりました。
2. 議事録を振り返るきっかけができた
これまで取るだけで終わっていた議事録からIssue作成まで行えるようになったため、Issue起点やドキュメント更新起点でどのような議論をしていたか振り返る習慣が付きました。
なんとなく理解していた議論内容もアウトプットベースで見返すことで言語化の手助けになると感じています。
今後の展望
現状の仕組みでも一定の自動化は出ていますが、まだまだ改善の余地があります。
出力面においては、ドキュメント更新の精度向上や、簡単な内容のIssueであれば自動的にPR作成まで行ってくれるように進化させたいと考えています。
一方、入力面でも改善が必要です。毎日溜まっていく議事録が肥大化してしまうため、週次・月次で情報をコンパクション（圧縮・要約）する仕組みを検討しています。また、現在はテキスト化された議事録をインプットとしていますが、元の音声データから直接情報を抽出した方がGeminiとClaudeの2段階を踏むよりデータのロスが少なくなるのではないかと考えています。
終わりに
プレイドでは、今回紹介したような開発プロセス自体の改善を含め、AIを活用したプロダクト開発を積極的に推し進めています。
今回の記事で少しでも興味を持った方がいらっしゃれば、ぜひカジュアル面談などでお話ししましょう。