Anri Nakamura

icon.JPG

Kakemu Fujii

image.png

Kento Kaseda

IMG_7153.jpg

Tsutomu Ikeda

IMG_r6zkvh.jpg

Reo Hakuta

T024HQQE3-U092QGQE6TD-6a515e5ed5a1-512.jpeg

Erika Sakurai

PL00879_櫻井絵理香.jpg

erikasakurai

Takaharu Nakamura

64473501.jpeg

Daichi Hachisuka

DSC04612_Original.jpg

Louis Avondet

PL00872_アボンデットルイ.jpg

Sota Sato

スクリーンショット2025-08-0410.34.30.png

Taira Ouchi

rami.png

Yuta Azumi

1000000936.jpg

Takahiro Hayashi

T024HQQE3-U05ECP8NVNC-90c78b4316d9-512.png

Kairi Ueno

2025-04-3019.32の画像.jpeg

Hiroki Tamiya

DSC01440@0.5x.jpg

Yugo Tsuchiya

登壇用.jpg

TomokiIchikawa

T024HQQE3-U05R70YBU2Z-bec7c6fdb311-512.jpeg

Yoshito Ikeda

IMG_3849_Original2.jpg

Haruki Tazoe

PL00808_田添春樹.jpg

Hajime Shiozawa

me_2.jpg

Kazuki Katsurada

PL788_桂田一輝.jpg

masashi kobayashi

LINE_ALBUM_夏合宿1日目_211219.jpg

lapla

qXlgxIG.JPG

Takehiko Okayama

ising.jpg

Kotaro Ito

IMG_5615.jpg

Yuhei Yasuda

yuhei.png

naoyashiga

1988660.jpeg

Takumi Ishii

ta9mi141.jpg

Sojiro Nishimura

icon.jpg

Katsumi Kobayashi

Kota Momoki

kF5sqT1m.jpg

Calloc

Shohei Shiraki

shiraki______.jpg

Takaaki Kanetsuki

IMG_4303.jpg

Yui Taniyama

profile_square.jpg

Kota Yatagai

icon.jpeg

Shuhei Kondo

DSC08585(3).jpg

kenshin tanaka

T024HQQE3-U05PBDAFRL6-979e9b2e96f8-512.jpg

KARTE Team

Security Team

Tomoya Koike

DSC02389.jpg

Haruki Tosa

DSC07358.jpg

Daiki Sakuma

スクリーンショット2022-09-1619.42.09.png

Takuma Shibuya

MCDV-G5y_400x400.jpeg

Takami Yamada

263231d5b255b21a5ccd1162caf4083d.jpg

Blocks Team

blocks_kaologo.png

Takanori Koga

iOSの画像.jpg

Takumi Katayama

me.jpeg

Yu Nishimura

unnamed.jpeg

Takuya Ogawa

akira.kasuga

Image-from-iOS--6------.jpg

Kosuke Oya

T024HQQE3-ULFR092SZ-a4325a429fda-512.jpeg

Yoshiyuki Komazaki

18051810.jpeg

mizchi

saboten.jpeg

Ryosuke Suzuki

myicon.jpg

koichi tanaka

Arnaud Avondet

githubprofile.png

6123322.png

kazupon

kazupon.jpg

daigo.isamatsu

-------.jpg

Jun Kusahana

kusahana.jun.jpg

Shinnosuke Ozawa

13511952_1732262680380481_2882139288629919103_n.jpg

Rei Ishikawa

rei_120.jpg

Hiroto Harada

profile_picture.jpg

Kei Tamiya

DSC06712_428.jpg

Nobuhiro Ito

itou.jpg

kazushi oohira

img_jobs_member_engineer31.jpg

Yohei Meguro

profile.jpg

Kazuto Kojima

kojimakazu.jpg

Tomoki Koga

photo_small.jpg

Kenichi Suzuki

11149348_10152861565996849_7684135567764915302_n.jpg

Takaaki Nakama

img_jobs_member_engineer24.jpg

Takahiro Tokunaga

Kohei Kadowaki

img_jobs_member_engineer21.jpg

kantetsu

img_jobs_member_engineer26.jpg

Makoto Kataigi

0404f91a9221606863b30a9472cbde90.jpg

Tatsuya Monoi

T024HQQE3-U1TBZVDEV-10a0922337c3-192.png

Jumpei Ikegami

ikegami.png

Masahiro Yamauchi

1666877493439_2.jpg

Shinji Eto

icon_eto.jpg

Yuta Nishimura

nishimura.yuta.jpg

Hideyuki Okada

IMG_8569-1.jpg

Wataru Ikarashi

20.png

Naoto Kato

kato02_480.png

Yuki Makino

img_makino.jpg

Atsushi Fujikawa

50065592145_352030691b55e725600d_1024.png

Naohiko Takemura

plaid_takemura.jpg

Daikichi Sasamori

13315227_1049838825099360_5485113047721634423_n.jpg

Atsushi Kobayashi

koba.png

Naoki Shibayama

c2c65af5b873f0db61c538c89284c9ad.jpg

Daiki Matsui

ikemonn.jpeg

Yohei Noda

profile2.jpeg

plaidinc

cover-image.png

cover-image

はじめまして。Core Platform Dept.で

今回は、日々のミーティングの議事録から、話し合った内容を元にGitHub Issueを自動的に作成する仕組みを構築した話を紹介します。

朝会やWeeklyミーティングで「これやっておきます」と発言したにもかかわらず、その内容をすっかり忘れてしまうことありませんか？私は多々発生してしまっています。自分が発言したことを忘れずに記録してリマインドできる仕組みがあったら嬉しいなと思い、自動でIssueを作成するbotを作成しました。

なぜ発言したことを忘れてしまうのか。これにはIssueを作成する作業自体の面倒さが要因の1つとしてあります。

「やる」と決めたタスクをIssueにするまでには、以下のようなステップが必要です。

これらのステップを踏んでいるうちに面倒になり、「後でやろう」と放置した結果、結局やらないままになってしまうことがありました。

一方で、現在社内で利用されているGoogle MeetのGeminiによる議事録作成機能で抽出される「推奨されるネクストステップ」の精度が実用的なレベルだと感じていました。せっかくの情報を見ずに捨ててしまうのはもったいない、これをIssue作成に活用できないかと考えました。

構築したシステムの全体の流れは以下のようになっています。

この仕組みにより、ミーティングが終わると自動的に議事録の内容が解析され、Issue作成やドキュメント更新が走るようになりました。

このシステムを構築する上で、特に工夫した技術的なポイントをいくつか紹介します。

1. Sub Agent (Task) を活用した並列実行と最適化

Issueを作成する際には、主に「アクションアイテムの抽出」「関連するソースコードの調査」「既存Issueとの重複チェック」という3つの観点での評価することにしました。この評価を効率化するために

（Task）を活用しています。Sub Agentを活用することで以下のようなメリットが得られます。

Sub Agentを用いたプロンプトの例

2. コマンド実行時のパーミッションエラー回避

GitHub Actions上でClaude Codeを動かす際、セキュリティの観点から

（ホワイトリスト）で許可する必要があります。

 コマンド自体は許可しているにも関わらず、Issue作成が失敗する現象です。

原因をログから辿ったところ、Claude CodeがIssue本文を渡す際、コマンド置換

を使用していたことが判明しました。この置換内部のコマンド実行が許可リストに含まれていない操作とみなされ、パーミッションエラーが発生していたのです。

そこで、本文を一度ファイルに出力し

はじめまして。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など）を割り当てることで、精度とコストのバランスを最適化できます。

Sub Agentを用いたプロンプトの例

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を活用したプロダクト開発を積極的に推し進めています。

今回の記事で少しでも興味を持った方がいらっしゃれば、ぜひカジュアル面談などでお話ししましょう。

プレイドの採用ページ



Gemini議事録からGitHub Issue作成を自動化する仕組み

Engineer Blog

Recent Article

Gemini議事録からGitHub Issue作成を自動化する仕組み

レガシー Monorepo を安全かつ素早く pnpm workspace に移行する方法

「契約による設計」を応用し、エラー通知のノイズを激減させる — KARTE Messageにおけるエラーハンドリング改善

Datadog の Workflow Automation を使って再起不能になった Pod を安全に削除する

KARTEの分析システムのレガシーな開発環境を高速にする。pnpm, Rspackの導入で改善できたこと。

Designing an AI Foundation with Mastra in a Microservices Architecture

マイクロサービスアーキテクチャにおける Mastra を活用した AI 基盤設計

プレイドインターン体験記：管理画面から配信基盤までを横断した機能開発

Vue Fes Japan 2025レポート | 現地で感じた技術の熱とつながり

プレイドインターン体験記：大規模システムのリアーキテクチャと負荷検証

Popular Articles

Popular Tags

Archives

Writers