デイリーミーティングアップデート
インタラクティブなインタビューを通じて、デイリースタンドアップ/ミーティングアップデートを生成します。ツールが設定済みであるとは決して想定せず、必ず最初に確認してください。
ワークフロー
START
│
▼
┌─────────────────────────────────────────────────────────┐
│ フェーズ1: 統合機能の検出と提案 │
│ • チェック: Claude Code履歴? gh CLI? jira CLI? │
│ • Claude Code → 昨日のセッションダイジェストを取得 │
│ → ユーザーが multiSelect で関連アイテムを選択 │
│ • GitHub/Jira → ユーザーに確認し、承認されれば取得 │
│ • データはインタビュー前に取得する │
├─────────────────────────────────────────────────────────┤
│ フェーズ2: インタビュー（インサイト付き） │
│ • 取得したデータをコンテキストとして表示 │
│ • 昨日: 「PR #123をマージしていますね、他に何かありますか？」 │
│ • 今日: 今日は何に取り組みますか？ │
│ • ブロッカー: 何か障害はありますか？ │
│ • トピック: ミーティングの最後に議論したいことは？ │
├─────────────────────────────────────────────────────────┤
│ フェーズ3: アップデート生成 │
│ • インタビュー回答 + ツールデータを結合 │
│ • クリーンなMarkdownとして整形 │
│ • ユーザーに提示 │
└─────────────────────────────────────────────────────────┘
フェーズ1: 統合機能の検出と提案
Step 1: サイレント検出
利用可能な統合機能をサイレントに確認します（エラーを抑制し、ユーザーには表示しません）:
| 統合機能 | 検出方法 |
|---|---|
| Claude Code履歴 | ~/.claude/projects ディレクトリが存在し、.jsonlファイルがある |
| GitHub CLI | gh auth status が成功する |
| Jira CLI | jira コマンドが存在する |
| Atlassian MCP | mcp__atlassian__* ツールが利用可能 |
| Git | Gitリポジトリ内である |
Step 2: GitHub/Jira統合機能の提案（利用可能な場合）
Claude Codeユーザー: このフェーズではすべての質問に
AskUserQuestionToolツールを使用してください。
GitHub/Git:
HAS_GH または HAS_GIT の場合:
「GitHub/Gitが設定されていることを検出しました。最近のアクティビティ（コミット、PR、レビュー）を取得しますか？」
オプション:
- 「はい、情報を取得してください」
- 「いいえ、すべて手動で入力します」
「はい」の場合:
「どのリポジトリ/プロジェクトを確認しますか？」
オプション:
- 「現在のディレクトリのみ」（gitリポジトリ内の場合）
- 「リポジトリを指定します」→ ユーザーがリストを提供
Jira:
HAS_JIRA_CLI または HAS_ATLASSIAN_MCP の場合:
「Jiraが設定されていることを検出しました。チケットを取得しますか？」
オプション:
- 「はい、チケットを取得してください」
- 「いいえ、すべて手動で入力します」
Step 3: GitHub/Jiraデータの取得（承認された場合）
GitHub/Git — 承認された各リポジトリについて:
- 昨日以降のユーザーによるコミット
- ユーザーがオープン/マージしたPR
- ユーザーが行ったレビュー
Jira — ユーザーに割り当てられ、過去24時間以内に更新されたチケット
重要なポイント: 結果を保存し、フェーズ2のインタビューでコンテキストとして使用します。
Step 4: Claude Code履歴の提案
この統合は、Claude Codeで行ったすべての作業を取得します。gitやJiraにない作業（調査、デバッグ、計画など）を思い出すのに役立ちます。
検出:
ls ~/.claude/projects/*/*.jsonl 2>/dev/null | head -1
Claude Code履歴が存在する場合、以下のように質問します:
「昨日のClaude Codeセッション履歴も取得できます。gitやJiraに記録されていない作業（調査、デバッグ、計画など）を思い出すのに役立ちます。確認しますか？」
オプション:
- 「はい、Claude Codeのセッションを取得してください」
- 「いいえ、必要な情報はすべて揃っています」
「はい」の場合、ダイジェストスクリプトを実行:
python3 ~/.claude/skills/daily-meeting-update/scripts/claude_digest.py --format json
次に、multiSelectでセッションを表示:
multiSelect: true を指定した AskUserQuestionTool を使用して、ユーザーに関連アイテムを選択させます:
「昨日のClaude Codeセッションはこちらです。スタンドアップに関連するものを選択してください:」
オプション（複数選択可）:
- 「認証バグの修正 (backend-api)」
- 「OAuthフローの実装 (backend-api)」
- 「ホームページスタイルの更新 (frontend-app)」
- 「決済プロバイダーの調査 (docs)」
重要なポイント: ユーザーは作業に関連するセッションのみを選択します。個人プロジェクトや実験は除外できます。
以下の場合、ダイジェストスクリプトを実行しないでください:
- ユーザーがClaude Code履歴に対して明示的に「いいえ」と答えた場合
- ユーザーがすべて手動で入力すると言った場合
~/.claude/projectsディレクトリが存在しない場合
ダイジェストスクリプトが失敗した場合:
- フォールバック: Claude Code統合をサイレントにスキップし、インタビューに進む
- よくある問題: Pythonがインストールされていない、昨日のセッションがない、権限エラー
- スタンドアップフローをブロックしないでください — スクリプトは補足的なものであり、必須ではありません
フェーズ2: インタビュー（インサイト付き）
Claude Codeユーザー: インタビューを実施するには
AskUserQuestionToolツールを使用してください。これにより、構造化されたオプションを備えたより良いUXが提供されます。
取得したデータをコンテキストとして使用し、質問をよりスマートにします。
質問1: 昨日
データが取得されている場合、最初に表示:
「アクティビティから以下が見つかりました:
- PR #123をマージ: ログインタイムアウトの修正
- backend-apiに3つのコミット
- PR #456をレビュー（承認済み）
昨日、他に取り組んだことはありますか？」
データが取得されていない場合:
「昨日（前回のスタンドアップ以降）何に取り組みましたか？」
ユーザーの回答が曖昧な場合、フォローアップ:
- 「Xについてもう少し詳しく教えてください」
- 「具体的に完了したことはありますか？」
質問2: 今日
「今日は何に取り組みますか？」
オプション:
- [テキスト入力 - ユーザーが自由に入力]
Jiraデータが取得されている場合、提案できます:
「以下のチケットが割り当てられています:
- PROJ-123: OAuthフローの実装（進行中）
- PROJ-456: 支払いバグの修正（未着手）
今日はこれらのいずれかに取り組みますか？」
質問3: ブロッカー
「何かブロッカーや障害はありますか？」
オプション:
- 「ブロッカーはありません」
- 「はい、ブロッカーがあります」→ 詳細を尋ねるフォローアップ
質問4: 議論トピック
「デイリーの最後に話し合いたいトピックはありますか？」
オプション:
- 「いいえ、特にありません」
- 「はい」→ 詳細を尋ねるフォローアップ
トピックの例:
- 意見が必要な技術的決定
- 別のチームとの調整
- 優先順位に関する質問
- チームへのお知らせや情報
フェーズ3: アップデート生成
すべての情報をクリーンなMarkdownに結合:
# デイリーアップデート - [日付]
## 昨日
- [インタビューからの項目]
- [取得した場合はGitHub/Jiraからの項目]
## 今日
- [インタビューからの項目]
## ブロッカー
- [ブロッカー、または「ブロッカーなし」]
## PRとレビュー（GitHubから取得した場合）
- [オープンしたPR]
- [マージしたPR]
- [実施したレビュー]
## Jira（Jiraから取得した場合）
- [更新されたチケット]
## 議論トピック
- [トピック、または「なし」]
---
*リンク:*
- [PRリンク]
- [チケットリンク]
基本原則
- インタビューが主体 — ツールは補足であり、人間のコンテキストを置き換えるものではありません
- アクセス前に同意を得る — 統合機能からデータを取得する前に必ず確認する
- コンテキストを考慮した質問 — インタビュー中に取得したデータを表示し、記憶を刺激する（「PR #123をマージしていますね、他に何かありますか？」）
クイックリファレンス
| フェーズ | アクション | ツール |
|---|---|---|
| 1. 検出と提案 | gh/jira/claude履歴を確認、ユーザーに確認、データを取得 | Bash（サイレント）、AskUserQuestionTool* |
| 2. インタビュー | インサイトを交えて4つの質問 | AskUserQuestionTool* |
| 3. 生成 | Markdownを整形 | テキスト出力 |
*Claude Codeのみ: 構造化された質問には AskUserQuestionTool ツールを使用してください。
Claude Codeダイジェストスクリプト
# 昨日のセッションをJSONとして取得
python3 ~/.claude/skills/daily-meeting-update/scripts/claude_digest.py --format json
# 今日のセッションを取得
python3 ~/.claude/skills/daily-meeting-update/scripts/claude_digest.py --date today --format json
# 特定のプロジェクトにフィルタリング
python3 ~/.claude/skills/daily-meeting-update/scripts/claude_digest.py --project ~/my-app --format json
セッション例
Claude: 「デイリーの準備をしましょう！GitHubが設定されていることを検出しました。最近のアクティビティを取得しますか？」
ユーザー: 「はい」
Claude: 「どのリポジトリを確認しますか？」
ユーザー: 「backend-api と frontend-app」
[ClaudeがGitHubデータをサイレントに取得]
Claude: 「昨日のClaude Codeセッション履歴も取得できます。確認しますか？」
ユーザー: 「はい」
[Claudeがダイジェストスクリプトを実行し、5つのセッションを取得]
Claude: 「昨日のClaude Codeセッションはこちらです。スタンドアップに関連するものを選択してください:」
☑ 認証タイムアウトバグの修正 (backend-api)
☑ OAuthフローの実装 (backend-api)
☐ 個人ブログの更新 (blog) - [ユーザーが個人プロジェクトのチェックを外す]
☑ 決済プロバイダーの調査 (docs)
☐ テスト失敗のデバッグ (experiments)
ユーザー: [関連する3つのアイテムを選択]
Claude: 「アクティビティから以下が見つかりました:
- PR #120をマージ: ログインタイムアウトの修正
- PR #125をオープン: feat: OAuthフロー追加
- PR #123をレビュー（承認済み）、PR #456をレビュー（変更要求）
- backend-apiに5つのコミット
- [Claude Codeから] 認証タイムアウトバグの修正
- [Claude Codeから] OAuthフローの実装
- [Claude Codeから] 決済プロバイダーの調査
昨日、他に取り組んだことはありますか？」
ユーザー: 「いいえ、それで全部です」
Claude: 「今日は何に取り組みますか？」
ユーザー: 「OAuth機能を続けて、ステージングにデプロイします」
Claude: 「ブロッカーはありますか？」
ユーザー: 「ありません」
Claude: 「デイリーの最後に話し合いたいトピックはありますか？」
ユーザー: 「はい、新しい決済モジュールのアーキテクチャについて議論したいです」
[Claudeがアップデートを生成]
出力例
# デイリーアップデート - 2026-01-22
## 昨日
- 認証機能に取り組んだ
- 決済プロバイダーの調査
- PR #120をマージ（修正: ログインタイムアウト）
- PR #125をオープン（機能: OAuthフロー追加）
## 今日
- OAuth機能を続ける
- ステージングにデプロイ
## ブロッカー
- ブロッカーなし
## PRとレビュー
- **オープン:** PR #125 - 機能: OAuthフロー追加
- **マージ:** PR #120 - 修正: ログインタイムアウト
- **レビュー:** PR #123（承認済み）、PR #456（変更要求）
## 議論トピック
- 新しい決済モジュールのアーキテクチャ
---
*リンク:*
- https://github.com/org/repo/pull/125
- https://github.com/org/repo/pull/120
アンチパターン
| 避けるべきこと | 理由（専門知識） | 代わりに |
|---|---|---|
| 確認なしでgh/jiraを実行する | ユーザーの個人リポジトリが表示されたり、公開したくない機密プロジェクトコンテキストにある可能性がある | 常に最初に確認し、ユーザーにリポジトリを選択させる |
| カレントディレクトリだけが唯一のプロジェクトだと想定する | 開発者はしばしば2〜5個のリポジトリを同時に扱う（フロントエンド、バックエンド、インフラ） | 「どのプロジェクトに取り組んでいますか？」と尋ねる |
| ツールデータがあるのにインタビューをスキップする | ツールはWHATを捉えるが、WHYやコンテキスト（調査、ミーティング、計画）を見逃す | インタビューが主体で、ツールは補足 |
| 4つの質問すべての前にアップデートを生成する | ユーザーが重要なブロッカーや議論トピックを持っていて、それが全体像を変える可能性がある | インタビューを完了してから生成する |
| 生のコミットメッセージを含める | コミットメッセージはしばしば cryptic（「fix」、「wip」）で、ストーリーを伝えない | 人間が読める成果に要約する |
| インタビュー後にデータを要求する | インタビュー中にインサイトを表示することで質問がよりスマートになる（「PR #123をマージしていますね、他に何かありますか？」） | 最初にデータを取得し、コンテキストを持ってインタビューを行う |
絶対にやってはいけないこと
- ツールが設定済みだと決して想定しない — 多くの開発者はghをインストールしているが認証していない、またはjira CLIが間違ったインスタンスを指している
- 「議論トピック」の質問を決してスキップしない — これはツールでは捉えられない、スタンドアップで最も価値のある部分であることが多い
- 15個以上の箇条書きを決して生成しない — スタンドアップは読むのに2分未満であるべき。長いアップデートは読む気を失わせる
- コンテキストなしでチケット/PR番号だけを含めない — 「PROJ-123」は意味をなさない。必ずタイトルや概要を含める
- ユーザーが明示的に承認していないリポジトリからデータを決して取得しない — 他のリポジトリが見えても、境界を尊重する