Claude Codeの「スキル」機能で定例会議前後のBacklog更新を自動化

はじめに

こんにちは！経営企画部兼ソリューション事業部の三沢です。

内容が古いのですが過去のインタビュー記事はこちら

【社員インタビュー】開発エンジニア：三沢さん

受託Web制作のPMをやっていると、週次の定例会議のたびに繰り返す作業があります。

Backlogのチケットを見ながらアジェンダを作る
会議後に議事録の内容を各チケットにコメントとして転記する

1件1件は大した作業ではないのですが、チケットが10件以上あると地味に30分〜1時間かかります。しかもやっていることは「情報を集めて整形する」「情報を転記する」という、判断よりも作業の比重が大きいタスクです。

これをClaude Codeの「スキル」機能を使って自動化したところ、合計で週1時間程度の工数削減になりました。本記事では、その仕組みと作り方を紹介します。

前提: Claude Codeの「スキル」とは

Claude Codeには、繰り返し行う作業手順をMarkdownファイルとして定義し、コマンド一つで呼び出せる「スキル」という仕組みがあります。

.claude/skills/
  └── my-skill/
      └── SKILL.md    ← 作業手順を自然言語で記述

SKILL.mdに「どのAPIを叩いて」「どんなデータを取得して」「どう加工して」「どこに出力するか」を書いておくと、Claude Codeがその手順に従って自律的に作業を実行してくれます。

プログラムコードを書くのではなく、作業手順書をMarkdownで書くというのがポイントです。

作ったもの

今回、あるWeb制作プロジェクトの定例会議運用に合わせて2つのスキルを作りました。

スキル1: 定例アジェンダ自動生成

やること: 会議前に、Backlogのチケット情報と前回議事録のネクストアクションからアジェンダを自動生成する

データソース:

Backlog API（処理中のチケット、最近完了したチケット、ステータス別件数）
Google Apps Script API（前回議事録のネクストアクション）

処理の流れ:

1. Backlog APIとGAS APIから並列でデータ取得
2. チケットをセクション別に分類（デザイン/マーケ/システム/保守/その他）
3. 前回のネクストアクションを各セクションに挿入
4. 顧客向けの丁寧語でアジェンダを生成
5. Markdownファイルとして出力

呼び出しは一言だけ:

> 定例のアジェンダ作って

これで、チケット20件以上あるプロジェクトでも1〜2分でアジェンダが完成します。

スキル2: 議事録→Backlogチケット自動反映

やること: 会議後に、議事録（Googleドキュメント）の内容を読み取り、関連するBacklogチケットにコメントとして反映する

処理の流れ:

1. GAS APIで最新議事録の全文を取得
2. 議事録からチケット番号（XXX-123形式）を検出
3. 各チケットに関する議論・決定事項を抽出
4. Backlog APIで現在のチケット状態を確認
5. 更新内容をユーザーに提示して確認を取る  ← ここが重要
6. 承認後にBacklog APIでコメント追記を実行

呼び出し:

> 定例の議事録をBacklogに反映して

ステータス変更も提案してくれるのが便利なポイントです。議事録に「対応済み」「完了」と書かれていれば、ステータス変更を提案します。ただし自動では変更せず、必ず確認を挟みます。

実際のSKILL.md全文

ここからは、実際に運用しているSKILL.mdの全文を掲載します。APIキーやURL、顧客名などの機密情報はマスキングしていますが、構成や記述の粒度はそのままです。「どのくらい具体的に書けばいいのか」の参考にしてください。

スキル1: 定例アジェンダ自動生成（SKILL.md）

# ○○社 定例会議アジェンダ作成スキル

○○社サイトリニューアルプロジェクトの顧客定例会議アジェンダを、Backlog APIから自動生成する。

## 使い方

「○○の定例アジェンダ作って」「○○の定例資料作成して」等で呼び出し。

## プロジェクト情報

| 項目 | 値 |
| --- | --- |
| Backlogドメイン | {your-space}.backlog.com |
| プロジェクトキー | PRJ |
| プロジェクトID | {project-id} |
| プロジェクト名 | ○○社-サイトリニューアル |

### 議事録API設定

| 項目 | 値 |
| --- | --- |
| GAS API URL | `https://script.google.com/macros/s/{deployment-id}/exec` |
| ドキュメントID | `{google-docs-id}` |
| 最新タブ形式 | `M/D 定例議事録`（例: "2/13 定例議事録"） |
| GASプロジェクト | `~/projects/{gas-project}/` |

### 対象サイト

| サイト | ドメイン | 備考 |
| --- | --- | --- |
| ○○本体 | example.co.jp | メインサイト |
| ○○採用 | example.co.jp/career/ | 採用サイト |
| メディア | example.co.jp/media/ | オウンドメディア |
| LP | example.co.jp/lp/ 等 | ランディングページ |
| 別ブランド | another-brand.jp | 別ドメイン |

### チームメンバー

| 名前 | 役割 | 主な担当領域 |
| --- | --- | --- |
| A | PM兼開発 | 全体管理、システム |
| B | インフラ・保守 | サーバー、セキュリティ、WP保守 |
| C | デザイナー | デザイン全般 |
| D | コーダー | コーディング、WP実装 |
| E | ディレクター | コンテンツ管理、顧客折衝 |

## ワークフロー

```
[設定ファイルからAPIキー取得]
     ↓
[並列データ取得]
  ├─ Backlog: ステータス別件数 (statusId: 1=未対応, 2=処理中, 3=処理済み, 4=完了)
  ├─ Backlog: 最近更新されたチケット (updatedSince=7日前, sort=updated, order=desc)
  ├─ Backlog: 処理中チケット (statusId=2)
  ├─ Backlog: 最近完了したチケット (statusId=4, updatedSince=7日前) ※完了報告用
  └─ GAS API: 前回議事録のネクストアクション取得
     ↓
[重要チケットのコメント取得] ← 並列実行
  ├─ 処理中チケット全件
  ├─ 処理済みチケット（完了確認用）
  └─ 最近コメント追加されたチケット
     ↓
[データ統合・分類]
  ├─ Backlogチケットをセクションに分類
  └─ 前回アクションをカテゴリ別に分類（デザイン/マーケ/システム/保守/その他）
     ↓
[アジェンダ生成] → work/active/YYYY-MM-DD-○○定例アジェンダ.md
  └─ 各進捗セクションの冒頭に「前回アクション確認」を挿入
```

## アジェンダ構成（固定テンプレート）

該当チケットがないセクションも枠を残す。顧客定例のため丁寧語で記述。

```markdown
# ○○様 サイトリニューアルプロジェクト 定例会議

**日時**: YYYY年M月D日（曜日）

---

## 1. サイト制作の進捗報告

### デザインの進捗

**前回アクション確認:**
{前回議事録のデザイン関連アクション}
{例: "✅ デザイン要素の要不要検討（E様、Slackにて順次）"}
{なければ省略}

**今週の進捗:**
{[デザイン]タグのチケット}
{なければ「現時点で進行中のタスクはございません。」}

### マーケの進捗

**前回アクション確認:**
{前回議事録のマーケ関連アクション}
{なければ省略}

**今週の進捗:**
{マーケティング・SEO・広告関連のチケット}
{なければ「現時点で進行中のタスクはございません。」}

### システムの進捗

**前回アクション確認:**
{前回議事録のシステム関連アクション}
{なければ省略}

**今週の進捗:**
{[システム]タグのチケット}
{なければ「現時点で進行中のタスクはございません。」
 未着手でも今後の予定として触れる}

### その他の進捗

**前回アクション確認:**
{前回議事録のその他アクション}
{なければ省略}

**今週の進捗:**
{PM・管理、制作、QA、上記に分類できないチケット}

---

## 2. 保守の進捗報告

**前回アクション確認:**
{前回議事録の保守関連アクション}
{なければ省略}

**今週の進捗:**
{[保守]タグ・インフラ保守作業種別のチケット（処理中のみ）}
{今後の保守作業予定も記載}

**完了報告:**
{前回定例以降（7日以内）に完了した保守タスクのみ記載}
{7日より前に完了したタスクは掲載しない}
{完了タスクがない場合はこのセクションごと省略}

---

## 3. 質疑応答

{顧客に確認・相談したい事項をリスト化}

---

次回定例: M月D日（曜日）予定

*YYYY年M月D日時点の情報に基づき作成*
```

## チケット分類ルール

チケットのサマリ先頭 `[タグ]` と種別(issueType)で振り分ける。

| 判定条件 | アジェンダセクション |
| --- | --- |
| `[デザイン]` タグ or issueType=デザイン | デザインの進捗 |
| `[マーケ]` `[SEO]` `[広告]` タグ | マーケの進捗 |
| `[システム]` タグ or issueType=システム | システムの進捗 |
| `[保守]` タグ or issueType=インフラ保守作業 | 保守の進捗報告 |
| `[制作]` タグ or issueType=制作 | その他の進捗 |
| `[管理]` タグ or issueType=PM・管理 | その他の進捗 |
| `[QA]` タグ or issueType=QA・テスト | その他の進捗 |
| 上記に該当しない | その他の進捗 |

## 課題種別一覧（プロジェクト固有）

| 種別名 | 分類先セクション |
| --- | --- |
| PM・管理 | その他の進捗 |
| バグ | その他の進捗 |
| 要望 | その他の進捗 |
| その他 | その他の進捗 |
| インフラ構築 | 保守の進捗報告 |
| システム | システムの進捗 |
| 制作 | その他の進捗 |
| デザイン | デザインの進捗 |
| コンテンツ・移行 | その他の進捗 |
| QA・テスト | その他の進捗 |
| インフラ保守作業 | 保守の進捗報告 |

## ステータスID対応表（プロジェクト固有）

| ID | ステータス名 |
| --- | --- |
| 1 | 未対応 |
| 2 | 処理中 |
| 3 | 処理済み |
| 370123 | 要件・WF |
| 370124 | デザイン |
| 370126 | 実装・開発 |
| 370128 | 受入確認 |
| 4 | 完了 |

## 文体ルール（顧客向け）

### 使う表現

- 「〜いたしました」「〜しております」「〜存じます」
- 「ご確認いただく」「ご相談させてください」
- ステータス: 「完了」「対応中」「未着手」

### 使わない表現

- 内部議論口調（「〜は？」「オンスケか？」「方針を決めて」）
- 「顧客への報告方針」等の社内メモ的表現
- 見積/実績時間（内部管理情報）
- 担当者間の引き継ぎ経緯の詳細

### セキュリティ報告時

- 技術的事実を客観的に報告
- 「ご相談させてください」で対処方針を顧客に委ねる
- 過度に不安を煽らない

## Backlog API メモ

### 認証

```
https://{your-space}.backlog.com/api/v2/{endpoint}?apiKey={API_KEY}
```

APIキーは設定ファイルから取得。

### 主要エンドポイント

| 用途 | エンドポイント |
| --- | --- |
| 課題一覧 | `/issues?projectId[]={project-id}&count=100&sort=updated&order=desc` |
| ステータス別件数 | `/issues/count?projectId[]={project-id}&statusId[]={id}` |
| 課題詳細 | `/issues/{issueKey}` |
| コメント一覧 | `/issues/{issueKey}/comments?count=20&order=desc` |
| 最近更新 | `/issues?projectId[]={project-id}&updatedSince={YYYY-MM-DD}&count=100&sort=updated&order=desc` |
| 最近完了 | `/issues?projectId[]={project-id}&statusId[]=4&updatedSince={YYYY-MM-DD}&count=100&sort=updated&order=desc` |

### 技術的注意点

- コメントの `content` が空で `changeLog` のみ = フィールド変更通知
- `changeLog` の `field: "description"` は全文入るため巨大 → 実質コメント(content非空)を優先
- `assignee` が null のチケットあり → パース時にnullチェック必須
- bash内python3 -cでのf-string `'` 衝突 → `%` フォーマットを使う

### 完了報告のルール

- **対象期間**: 前回定例以降（7日以内）に完了したチケットのみ報告
- **判定方法**: `statusId=4` かつ `updatedSince={7日前の日付}`
- **掲載基準**:
  - 7日以内に完了 → 完了報告に掲載
  - 7日より前に完了 → 前回定例で報告済みのため掲載不要
  - 完了タスクがない → 完了報告セクションごと省略
- **理由**: 定例会議は週次開催のため、前回報告済みのタスクを重複掲載しない

## 出力先

```
work/active/YYYY-MM-DD-○○定例アジェンダ.md
```

## 前回アクション取得API

### API仕様

```bash
curl -L "https://script.google.com/macros/s/{deployment-id}/exec?documentId={google-docs-id}"
```

### レスポンス例

```json
{
  "success": true,
  "latestTab": "2/13 定例議事録",
  "documentId": "{google-docs-id}",
  "actions": [
    {
      "action": "ページ選別シートの叩き台作成",
      "assignee": "E・F",
      "deadline": "2/13",
      "category": "その他"
    },
    {
      "action": "デザイン要素の要不要、FVコピーの検討",
      "assignee": "E",
      "deadline": "Slackにて順次",
      "category": "デザイン"
    },
    {
      "action": "管理画面の課題に対する解決策一覧の作成",
      "assignee": "A・D",
      "deadline": "2/13",
      "category": "システム"
    }
  ],
  "count": 3
}
```

### カテゴリ分類

GAS APIが自動的にアクション内容からカテゴリを判定：

| カテゴリ | キーワード | 担当者 |
| --- | --- | --- |
| デザイン | デザイン, design, ui, ux, fv, ビジュアル | C |
| マーケ | マーケ, seo, 広告, コンテンツ, analytics, ga4 | - |
| システム | システム, api, 管理画面, データベース, db, 実装 | - |
| 保守 | 保守, インフラ, サーバー, セキュリティ, wp更新 | B |
| その他 | 上記に該当しない | - |

### アジェンダへの統合方法

1. GAS APIから前回アクションを取得
2. カテゴリ別に分類（`actions[].category`を使用）
3. 各進捗セクション（デザイン/マーケ/システム/保守/その他）の「前回アクション確認」に挿入
4. 表示形式:
   - `✅ {action}（{assignee}、{deadline}）`
   - 該当アクションがない場合はセクションごと省略

### 実装メモ

- API呼び出しはBacklogデータ取得と並列実行
- エラー時はログに記録し、前回アクション確認セクションを省略
- デプロイ更新時は本ファイルのAPIエンドポイントURLを更新

スキル2: 議事録→Backlogチケット自動反映（SKILL.md）

# ○○社 定例会議後 Backlogチケット更新スキル

定例会議の議事録（Googleドキュメント）を読み取り、議論された内容をBacklogチケットにコメントとして反映する。

## 使い方

「○○定例の議事録をBacklogに反映して」「○○議事録からチケット更新して」等で呼び出し。

## プロジェクト情報

| 項目 | 値 |
| --- | --- |
| Backlogドメイン | {your-space}.backlog.com |
| プロジェクトキー | PRJ |
| プロジェクトID | {project-id} |

### 議事録API設定

| 項目 | 値 |
| --- | --- |
| GAS API URL | `https://script.google.com/macros/s/{deployment-id}/exec` |
| ドキュメントID | `{google-docs-id}` |
| 全文取得パラメータ | `&mode=fulltext` |

### Backlog API設定

| 項目 | 値 |
| --- | --- |
| ベースURL | `https://{your-space}.backlog.com/api/v2` |
| APIキー取得元 | 同ディレクトリの `config.json` から `BACKLOG_API_KEY` を読み取る |
| 認証方式 | `?apiKey={API_KEY}` をURLに付与 |

## ワークフロー

```
[Step 1] GAS APIで最新議事録の全文をMarkdown取得
  curl -sL "{GAS_API_URL}?documentId={DOC_ID}&mode=fulltext"
  → JSON: { success, latestTab, content }
     ↓
[Step 2] 議事録の内容を分析
  - PRJ-xxx 形式のチケット番号を検出
  - チケット番号が明示されていなくても、議題の文脈からBacklogチケットとの関連を推定
  - 各チケットに関する議論・決定事項・指示・ステータス変更の情報を抽出
     ↓
[Step 3] Backlog APIで対象チケットの現在状態を確認
  - GET /api/v2/issues/{issueKey}?apiKey={API_KEY}
  - 現在のステータス、担当者、最新コメントを取得
  - 議事録の情報と現在の状態を比較
     ↓
[Step 4] ユーザーに更新内容を提示して確認
  チケットごとに以下を一覧表示:
  - 追記するコメント内容
  - ステータス変更（該当する場合のみ）
  ユーザーの承認/修正を待ってから実行
     ↓
[Step 5] Backlog APIでチケット更新を実行
  - コメント追記: POST /api/v2/issues/{issueKey}/comments?apiKey={API_KEY}
    body: content={コメント内容}
  - ステータス変更（必要な場合）: PATCH /api/v2/issues/{issueKey}?apiKey={API_KEY}
    body: statusId={ステータスID}
     ↓
[Step 6] 結果サマリを表示
  - 更新したチケット一覧
  - 各チケットの追記内容とステータス変更
```

## コメントフォーマット

Backlogチケットに追記するコメントの形式:

```
【{M/D} 定例会議メモ】
{議事録から抽出した該当チケットに関する内容}
```

例:
```
【2/20 定例会議メモ】
- WordPress管理外のページについて調査報告書を共有。分類済み。
- 新サイト構築時にWordPress管理対象とするかどうか、顧客にご判断いただく。
- 緊急対応が必要なものは対応実施済み。
```

## ステータス変更の判断基準

| 議事録での言及 | 提案するステータス変更 |
| --- | --- |
| 「完了」「対応済み」「クローズ」 | → 完了 (statusId=4) |
| 「確認待ち」「レビュー待ち」 | → 処理済み (statusId=3) |
| 明確な言及なし | ステータス変更しない |

**重要**: ステータス変更は常にユーザー確認後に実行する。自動変更しない。

## ステータスID対応表（プロジェクト固有）

| ID | ステータス名 |
| --- | --- |
| 1 | 未対応 |
| 2 | 処理中 |
| 3 | 処理済み |
| 370123 | 要件・WF |
| 370124 | デザイン |
| 370126 | 実装・開発 |
| 370128 | 受入確認 |
| 4 | 完了 |

## Backlog API エンドポイント

### チケット詳細取得

```
GET https://{your-space}.backlog.com/api/v2/issues/{issueKey}?apiKey={API_KEY}
```

### コメント追加

```bash
curl -X POST "https://{your-space}.backlog.com/api/v2/issues/{issueKey}/comments?apiKey={API_KEY}" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "content={コメント内容（URLエンコード）}"
```

### ステータス更新

```bash
curl -X PATCH "https://{your-space}.backlog.com/api/v2/issues/{issueKey}?apiKey={API_KEY}" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "statusId={ステータスID}"
```

## 注意事項

- APIキーの取得: 同ディレクトリの `config.json` から `BACKLOG_API_KEY` を読み取る。見つからない場合はユーザーに確認。
- 議事録にチケット番号がない議題でも、文脈から関連チケットを推定して提案する（ユーザー確認必須）
- コメント内容は事実ベースで簡潔に。社内の口語表現はそのまま転記しない
- 議事録の「質疑応答」セクションの内容も、関連チケットがあればコメントに反映
- 大量のチケット更新時は、5件ずつバッチで確認を取る

SKILL.mdの書き方のコツ

上の全文を踏まえて、実際に運用してわかったポイントをいくつか紹介します。

1. APIの仕様は具体的に書く

「Backlog APIでチケットを取得する」ではなく、エンドポイントURL、パラメータ、認証方法まで明記します。

### チケット一覧取得
GET https://example.backlog.com/api/v2/issues?projectId[]=12345&statusId[]=2&count=100&sort=updated&order=desc&apiKey={API_KEY}

Claude Codeはこの記述をそのまま使ってcurlコマンドを組み立てます。曖昧な書き方をすると、毎回APIドキュメントを調べに行く分のオーバーヘッドが発生します。

2. 分類ルールはテーブルで書く

チケットの振り分けルールなど、条件分岐が多いものは表形式が効果的です。

| 判定条件 | アジェンダセクション |
| --- | --- |
| `[デザイン]` タグ | デザインの進捗 |
| `[保守]` タグ | 保守の進捗報告 |
| 上記に該当しない | その他の進捗 |

自然文で書くよりも解釈のブレが少なくなります。

3. 出力フォーマットはテンプレートで示す

最終的にどんな形で出力してほしいかを、具体的なテンプレートで記述します。

## コメントフォーマット
【{M/D} 定例会議メモ】
- {議事録から抽出した内容}
- {決定事項}

4. 「やらないこと」も書く

やってほしくないことを明示するのも重要です。

### 使わない表現
- 内部議論口調（「〜は？」「オンスケか？」）
- 見積/実績時間（内部管理情報）

**重要**: ステータス変更は常にユーザー確認後に実行する。自動変更しない。

特に「確認なしに実行しない」というガードレールは、業務で使う上で必須です。

5. エラー時の振る舞いも定義する

APIが失敗したときにどうするかも書いておくと、途中で止まらずに済みます。

- エラー時はログに記録し、前回アクション確認セクションを省略
- APIキーが見つからない場合はユーザーに確認

議事録APIの工夫

議事録はGoogleドキュメントに書いているのですが、Claude Codeから直接Google Docs APIを叩くと認証が面倒です。そこで、Google Apps Script（GAS）で薄いAPIを作り、以下の2つの機能を提供しています。

ネクストアクション取得: 議事録の「決定事項とネクストアクション」セクションを解析して、構造化データとして返す
全文取得: 議事録全文をMarkdown形式で返す（議事録→チケット反映で使用）

GASをAPIとして公開しておくことで、Claude Codeからはシンプルなcurlだけでアクセスできます。

導入効果

定量的な効果

作業	Before	After
アジェンダ作成	20〜30分	2分（生成）+ 5分（確認・微調整）
議事録→チケット反映	30〜40分	2分（生成）+ 3分（確認・実行）
合計	約1時間/週	約12分/週

定性的な効果

アジェンダの品質が安定した: 毎回同じフォーマットで、漏れなくチケット情報が入る
会議準備のストレスが減った: 「あとでBacklog更新しなきゃ」というタスクが消えた

まとめ

Claude Codeのスキル機能は、「判断は人間、作業はAI」という分担を自然に実現できる仕組みです。

今回のケースでは：

アジェンダ生成: データ収集・整形はAI、内容の最終確認は人間
チケット更新: 情報抽出・コメント下書きはAI、更新の承認は人間

という役割分担になっています。

スキルの定義はMarkdownで書くだけなので、プログラミングの知識がなくても作れます。一方で、APIの仕様や分類ルールを正確に記述する「ドキュメント力」は求められます。普段から作業手順書を書いている人にとっては、その延長線上にある仕組みだと思います。

定型的だけど量が多い作業を抱えているPMの方は、まず一番面倒な作業をスキル化するところから試してみてください。