Backlog × AIエージェント連携で開発業務を回す5つの活用例【bee + Agent Skills】

はじめに

最近では、GitHub CopilotやClaude CodeなどのAIエージェントにコードを書かせる開発スタイルが広がりつつあります。

しかし、実際の開発業務には、要件や背景の把握、実装後の報告、知見のドキュメント化など、コードを書く以外にも多くの作業があります。実装だけが速くなっても、業務全体にはまだ効率化の余地があります。

私の業務では、プロジェクト管理にBacklogを使っており、要件や背景、作業記録、知見などが課題（＝チケット）・コメント・Wikiに蓄積されています。AIエージェントがBacklogの情報を参照・更新できるようになれば、開発ワークフロー全体をよりスムーズにできるのではないかと思い、方法を調べたところ、bee（Backlog CLI）+ Agent Skills の構成がぴったりでした。

この記事では、その連携方法と、実際の開発業務を想定した5つの活用例を紹介します。

この記事で使用しているBacklogの画面や課題は、私個人で登録したBacklogに作成したダミープロジェクトのものです。実際の業務プロジェクトとは一切関係ありません。

Backlogとは

Backlogは、ヌーラボが提供するプロジェクト・タスク管理ツールです。課題管理を中心に、スケジュール管理やドキュメント共有、ソースコード管理など、プロジェクトに必要な機能がひとつにまとまっています。開発だけでなく、デザインやマーケティングなど幅広い業務で利用されています。

• 課題管理: タスクに担当者・期限・ステータスを設定して管理。親子課題による構造化も可能
• ガントチャート / カンバンボード: スケジュールや進捗を視覚的に把握
• Wiki: 仕様や設計、運用手順などの情報を蓄積・共有
• Git / Subversion: ソースコードやコミット履歴の管理、コードレビュー、プルリクエストに対応

この記事では、主に課題・コメント・Wikiに蓄積された情報を、AIエージェントから参照・更新します。

bee（Backlog CLI）+ Agent Skillsで連携する

beeは、Backlogをコマンドラインから操作するためのCLIツールです。課題やWiki、ドキュメント、Gitリポジトリなどをターミナルから操作でき、GitHub CLI（gh）に近い使い勝手になっています。

beeはヌーラボの公式GitHubアカウントで公開されていますが、有志によって開発・メンテナンスされているツールであり、公式サポート製品ではありません（MITライセンス）。

なぜMCPではなくbee + Agent Skillsなのか

Backlogには公式のMCPサーバーもあり、Claude DesktopなどのMCP対応クライアントから利用できます。

ただし、2026年7月時点の公開ツール一覧では、課題コメントの編集・削除、Wikiの更新・削除、ドキュメントの更新・削除には対応していません。

beeは幅広いサブコマンドを備えているうえ、CLIで対応していない操作もbee apiからBacklog APIを直接呼び出して補えます。今回のように、ターミナルを操作できるAIエージェントからBacklogを幅広く扱う用途には、beeのほうが適していました。

Agent Skillsとは

Agent Skillsは、AIエージェントに「特定のタスクをどう進めるか」という手順をSKILL.mdとして渡すためのオープン標準です。

beeは、AIエージェント向けにusing-beeスキルを配布しています。これを追加すると、エージェントが必要なときにbeeの操作方法を読み込み、Backlogを操作できるようになります。同じスキルをClaude CodeやGitHub Copilotなどで使い回せるのも利点です。

セットアップ

beeの利用にはNode.js 20.18以上が必要です。インストール方法は公式の「はじめに」を参照してください。

以下はAPIキー認証を使う場合の例です。APIキーは、Backlogの「個人設定 → API」から発行できます。

# Backlogにログイン
bee auth login

# デフォルトのスペース・プロジェクトを指定（任意）
export BACKLOG_SPACE=your-space.backlog.com
export BACKLOG_PROJECT=YOUR_PROJECT

# using-beeをグローバルに追加
npx skills add nulab/bee --skill using-bee -g

OAuthを使う場合は、事前にOAuthアプリケーションを登録したうえでbee auth login --method oauthを実行します。詳しくは認証ガイドを参照してください。

using-beeはプロジェクト固有のルールではなく、bee自体の使い方を定義するスキルなので、ここでは-gを付けてユーザー単位で追加しています。インストール時に普段使うエージェントを選択しておけば、「Backlog」や課題キーを含む指示に応じてスキルが読み込まれます。

Backlog記法を使用するプロジェクトでは、backlog-notationスキルも追加できます。Backlog記法を使うことは自動判定されないため、プロンプトで明示するか、各エージェントが参照する指示ファイルに記載しておきます。

Case 1: 課題をAIエージェントの作業指示書にする

一番の基本かつ効果的な使い方が、課題そのものを作業指示書として読ませることです。

「課題 PROJ-123 を実装して」と依頼すると、エージェントがusing-beeスキル経由で課題の情報を読み取り、何をすべきかを理解した上で実装に入ってくれます。

実際に以下のような課題を作成して、エージェントに実装を依頼してみます。

しっかりと課題の要件を読み取り、指示どおりに実装してくれました。

今回は作業内容に「375px幅と1280px幅で表示確認する」という要件が含まれていたため、VS Codeのbrowser agent toolsを使い、指定された画面幅での表示確認まで行っています。この機能では、エージェントがIntegrated Browserを操作してスクリーンショットを撮ったり、ページの内容を読み取ったりできます。

Case 2: 実装後に課題コメントへ作業報告させる

実装が終わったら、その内容を課題のコメントとして書き込ませることもできます。

「対応内容を課題にコメントして」と依頼すると、変更点の要約や対応した観点を整理して投稿してくれます。作業記録が課題に残るので、レビュアーや後から見る人への共有がスムーズになります。

Case 1 の続きで指示を出してみます。

コメントが投稿されました。対応内容と確認した観点が整理されています。

注意点として、コメントの投稿者はAIエージェントではなく、beeで認証している自分自身のアカウントになります。「先頭に『🤖 Generated by GitHub Copilot』と付けて」のようにAI生成だと分かる一文を入れさせておくと、後から見た人が人間のコメントと区別でき、透明性の面でも安心です。

コメントの体裁を揃えたい場合は、Case 3 と同じ要領で自作スキルにテンプレートを切り出せます。

Case 3: Wikiに課題対応ログを残す

単発の課題コメントだけでなく、Wikiに対応ログをまとめて蓄積する使い方もできます。

「今回の対応をWikiの『不具合対応ログ』に残して」のように依頼すれば、Wikiを更新してくれます。コメントが課題単位のフロー情報だとすれば、Wikiは横断的に参照されるストック情報です。両者を使い分けることで、ナレッジが流れていかずに溜まっていきます。

不具合報告が上がっている課題をもとに、調査からWikiへの記録までを依頼してみます。

新しいWikiページが作成され、調査内容が記録されました。
この後、実際の修正作業とWikiへの追記も依頼して、課題の対応が完了するまでを一連のフローとして任せることもできます。

フォーマットを揃える

Wikiへの出力をそのまま依頼すると、書かせるたびに見出し構成がブレてしまいます。毎回同じフォーマットに揃えたい場合は、テンプレートを小さな自作スキルに切り出しておくと安定します。

.agents/skills/backlog-incident-log/SKILL.md

---
name: backlog-incident-log
description: Backlogの不具合対応ログをWikiに残すときに使う。子ページの定型フォーマットと親インデックスの更新ルールを定義する。
---

# 不具合対応ログの記録手順

beeの操作方法は using-bee スキルに従う。本スキルはフォーマットのみを定義する。

## 記録先
- 親ページ「SampleTaskFlow App/不具合対応ログ」に不具合のインデックス表がある
- 各不具合は親配下に `NNN_タイトル` の子ページを作る（NNN は既存最大番号+1の連番）

## 子ページのフォーマット
先頭に `# NNN_タイトル`、次行に `発生日: YYYY-MM-DD` を置き、以下の見出しで書く。

- `## 関連課題` … 関連課題キーと概要
- `## 現象` … 発生した事象と影響範囲
- `## 仮説` … 切り分けで立てた見立て
- `## 対応方針` … 実施する/した対応
- `## 追加テスト` … 回帰確認のケース（あれば）

## 親インデックスの更新
子ページ作成後、親ページの表に `No | 発生日 | タイトル | 関連課題 | 状態` の行を1つ追加する。

## 注意
- 既存ページは `bee wiki view`で全文を取得し、必要箇所を変更した本文を`bee wiki edit`で戻す（既存内容を欠落させない）
- 改行を含む本文は stdin パイプで渡す（`cat body.md | bee wiki edit <ID>`）

using-beeが「beeの使い方」を担当するのに対し、こうした自作スキルは「自分たちのチームでの使い方」を担当します。スキルを役割で分けておくと、運用ルールを変えたいときに自作スキル側だけ直せばよく、メンテナンスが楽です。

なお、using-beeスキルはグローバルに入れましたが、こうした運用ルールの自作スキルはプロジェクトの.agents/skills配下に置いてリポジトリにコミットすることで、チーム全体で共有できます。

GitHub CopilotやCodexなどは.agents/skillsをそのまま参照できますが、Claude Codeの場合は.claude/skillsへのコピーまたはシンボリックリンクが必要です。

Case 4: 課題・Wikiをもとに質問に答えさせる

連携の効果は実装中だけにとどまりません。蓄積された課題やWikiを情報源にした質問応答も便利です。

「この機能の仕様ってどうなってたっけ？」「あの不具合の対応経緯を教えて」といった質問に対し、エージェントが関連する課題やWikiを検索して答えてくれます。検索ボックスにキーワードを入れて自分で記事を探し回るより速く、複数の課題にまたがった情報も横断的にまとめてくれます。

開発中だけでなく、後から仕様を確認したり、過去の意思決定の経緯を振り返ったりする用途にも使えるのが嬉しいポイントです。

Case 5: 親課題を子課題に分解する

実装作業だけでなく、課題管理そのものも任せられます。

大きめの親課題を渡して「これをタスク分解して子課題を作って」と依頼すると、作業を適切な粒度に分割し、子課題として起票してくれます。タスクの切り出しは地味に頭を使う作業なので、たたき台を自動で作ってもらえると計画が楽になります。

以下のような親課題を作成して、子課題への分解を依頼してみます。

分割された子課題が起票されました。途中で出した期間変更の指示も反映されています。

分解ルールを揃える

Case 3 と同様に、そのまま指示を出すだけでは粒度や命名がブレてしまいます。分割ルールを自作スキルに書いておくと、出力が安定して使い勝手が良くなります。

.agents/skills/backlog-subtask/SKILL.md

---
name: backlog-subtask
description: Backlogの親課題をタスク分解して子課題を起票するときに使う。粒度・命名・デフォルト設定のルールを定義する。
---

# 子課題分解のルール

beeの操作方法は using-bee スキルに従う。本スキルは分解の方針のみを定義する。

## 粒度
- 1つの子課題は半日〜2日で完了する大きさを目安にする
- 「設計」「実装」「テスト」「レビュー対応」のように工程で分けすぎない。機能・対象単位で分ける

## 命名規則
- 子課題のタイトルは動詞で始める（例:「〜を実装する」「〜を調査する」）
- 親課題のキーをタイトルには含めない（親子関係はBacklog側で表現する）

## 起票時のデフォルト
- 親課題と同じマイルストーン・カテゴリを引き継ぐ
- 担当者は未設定のままにする（人間が割り当てる前提）

## 期間（親課題の範囲内に収める）
- 子課題の開始日・期限は、必ず親課題の期間 `[開始日, 期限]` の内側に収める。親の期限を超える子課題を作らない
- 親課題の期間を分割・並列配置して各子課題に割り当てる（順に並べる／並行できるものは重ねる）
- 親課題に開始日・期限が設定されていない場合は、マイルストーンの期間を上限として同様に収める
- 各子課題は起票時に `--start-date` / `--due-date` を明示指定する（未指定で範囲外にならないようにする）

## 進め方
1. 親課題の本文・コメントに加え、開始日・期限（未設定ならマイルストーン期間）を issue view で確認する
2. 上記ルールに沿って分解案（各子課題の日程を含む）を提示し、人間の確認を取る
3. 承認後に issue create で子課題をまとめて起票する。起票後、各子課題の期間が親の範囲内に収まっているか確認する

よかったこと・気になったこと

よかったこと

• 課題本文・コメント・Wikiをまとめて参照できるため、プロンプトへ情報を書き写す手間が減った
• 作業報告や対応ログをBacklogへ残せるため、実装後の記録を整えやすくなった
• 過去の課題やWikiを横断して調べられるため、仕様や対応経緯を確認しやすい
• 同じAgent SkillsをGitHub CopilotやClaude Codeなどで使い回せるため、エージェントが変わっても運用ルールを共有できる
• bee apiを使うことで、CLIに専用コマンドがない操作もBacklog API経由で補える

気になったこと

• bee 1.0.0では、複数行の本文をフラグで渡すと1行目で切れることがある。コメント・Wiki・ドキュメントではstdin、課題の説明ではREST APIを使うなど、操作に応じた回避が必要
• beeはCLIツールなので、シェルコマンドを実行できるAIエージェントが前提になる。Claude Desktopなどで利用する場合は、MCPサーバーのほうが向いている
• Backlogへの操作は、beeで認証したユーザーの権限で実行される。更新や削除を任せる場合は、実行前に内容を提示させて確認する運用にしておくと安心

まとめ

beeとAgent Skillsを使って、BacklogとAIエージェントを連携させた活用例を紹介しました。

• 課題を作業指示書として読ませ、実装を依頼する
• 作業報告や対応ログを課題コメント・Wikiに残す
• 蓄積された情報をもとに質問へ回答させる
• 親課題を分解し、子課題を起票させる

Backlogには、開発に必要な要件や経緯、作業記録がすでに蓄積されています。これらをAIエージェントの入力と出力の両方に使うことで、活用範囲をコード生成だけでなく、その前後の開発業務まで広げられます。

Backlogを使っている方は、まずは課題を読ませるところから試してみてください。