目次
この記事は ヌーラボブログリレー2026夏 の7日目 Part 1 として投稿しています。
こんにちは。Backlog Unit の simochee @lollipop_onl です。
Backlog をターミナルから操作できる CLI「bee」を公開しました。
GitHub – nulab/bee: Command-line tool to view and manage Backlog
この記事では、bee で何ができるのか、なぜ CLI という形にしたのかを紹介します。
目次
bee とは
bee は、ブラウザを開かずに Backlog の課題の確認・作成・更新をターミナルから行えるコマンドラインツールです。
課題のほかにもプロジェクト、Wiki、ドキュメント、プルリクエスト、通知など、90 を超えるサブコマンドで Backlog の主要な機能をカバーしています。
npm でインストールして、bee auth login で API キーを登録すれば使えます。
ヌーラボの有志メンバーが開発し、オープンソース（MIT ライセンス）として公開しています。
なぜ CLI なのか
Claude Code のようなコーディングエージェントを使い始めてから、私自身がターミナルに引きこもる時間が明らかに増えました。
ブランチ名にもコミットメッセージにも課題キーが書いてあるのに、課題を確認するにはブラウザに移って探し直すことになります。
ターミナルから Backlog をそのまま呼び出せて、必要なときはすぐに画面を開ける。
そういう道具が欲しくなったのが、bee を作り始めたきっかけです。
ちょっとした自動化も、CLI があればシンプルに実現できます。
スプリント終わりの課題の棚卸しや、リリース時の一括コメント。
Backlog API を叩けば済む話ですが、そのたびに認証を書いてエンドポイントを調べるのは腰が重くなります。
CLI ならシェルの部品になるので、for や jq と組み合わせて数行で済みます。
もうひとつ、エージェント自身に Backlog を触らせたい場面がありました。
アクティビティからの情報収集や、プロジェクトのセットアップといった作業を任せるには、エージェントが API にフルアクセスできると都合がいい。
コマンドとして用意していない操作も呼べる bee api を早い段階で作ったのは、このためです。
結果として、この CLI は人が打つのと同じコマンドを、CI からも AI エージェントからも呼べるようになりました。
ターミナルで課題を確認・更新する
まずは日常の操作からです。
bee issue status # 自分の担当課題をステータス別に一覧 bee issue list -a @me -p PROJECT # 自分が担当の課題を絞り込み bee issue view PROJECT-123 --comments # 課題の詳細とコメントを表示 bee issue comment PROJECT-123 -b "対応します"
腰を据えて読みたくなったら --web を付ければ、同じ課題がブラウザで開きます。
すべてをターミナルで済ませようとは考えていなくて、じっくり読み書きするときはブラウザに戻る、くらいの感覚で使っています。
AI エージェントに Backlog を任せる
bee がいちばん活きるのは、AI エージェントに Backlog の閲覧や操作を任せたいときです。
課題、プルリクエスト、Wiki といった開発の道具立ては、チームやツールが違っても通じる共通の語彙です。
「課題を読んで、ブランチを切って、PR を出して、マージされたら課題を閉じる」という一般的な開発フローを LLM はすでに学習しているため、bee の使い方を細かく教え込む必要がありません。
Claude Code のような Agent Skills に対応した環境なら、 using-bee というスキルを追加するだけで bee を使えるようになります。
npx skills add nulab/bee --skill using-bee
あとは普段の指示に Backlog を混ぜるだけです。
「PROJECT-123 の内容を読んで修正して。終わったら課題にコメントして、ステータスを処理中にして」といった指示で、エージェントが bee を叩いて課題を読み、作業し、結果を書き戻してくれます。
スキルは Backlog に関連する言葉を含めれば自動で呼ばれますが、/using-bee と頭に付けて明示的に呼び出すこともできます。
コマンドを指定しない曖昧な問いかけでも、必要なコマンドを組み立てて答えを返してきます。
朝いちばんに状況を把握したいとき、私はこんな聞き方をしています。
説明が必要になるのは Backlog 固有の部分だけです。
ステータスがプロジェクトごとの数値 ID だったり、課題キーが PROJECT-123 形式だったり、プロジェクトによって Backlog 記法と Markdown が使い分けられていたり、といったあたりです。
ここはスキルと --help、そしてドキュメントサイトの llms.txt で補えるようにしています。
Backlog 記法のプロジェクト向けには、構文リファレンスの backlog-notation スキルも用意しました。
なお、ヌーラボは Backlog MCP Server も公開しています。
Claude Desktop のような MCP クライアントから使うなら、こちらが向いています。
bee はターミナルを操作できるエージェント向けです。
使い勝手のために考えたこと
作るなかで細かい設計判断がいくつもありました。
その中から、気に入っているものをいくつか紹介します。
ひとつは @me です。
Backlog API は担当者を数値のユーザー ID でしか受け取らないため、「自分の課題を見たい」という一番よくある操作が、一番手間のかかる指定になっていました。
bee では --assignee @me と書けます。
優先度の high や完了理由の duplicate も同じで、ID との変換は内部でよしなにやってくれます。
bee browse は、カレントディレクトリの git remote から Backlog のスペース・プロジェクト・リポジトリを判定します。
bee browse 123 と課題番号だけで課題が開けますし、bee browse src/main.ts:42 でファイルの該当行を Git ビューアで開けます。
「いまどのリポジトリにいるか」は API からは分からない情報なので、CLI ならではの機能です。
また、必須の値が足りないまま実行したときは、エラーで落とさずにその場で不足している項目を入力できるようになっています。
ただし CI やパイプの中では、聞かずにそのままエラーになります。
使いはじめる
Node.js 20.18 以上の環境で、次の 3 ステップで始められます。
npm install -g @nulab/bee bee auth login bee issue list -p PROJECT
API キーは Backlog の「個人設定 > API」から発行できます。
OAuth 認証や CI 向けの設定はドキュメントを参照してください。
フィードバックをお待ちしています
bee はオープンソースとして開発を続けていきます。
要望や不具合報告は、Backlog のサポート窓口ではなく GitHub Issues にお寄せください。
使ってみた感想だけでも嬉しいです。
プルリクエストも歓迎です。
おまけ
bee にまつわる記事を Zenn に 2 本公開しています。
GitHub Actions と組み合わせて、PR を作ると課題が「処理中」になり、マージすると自動でクローズされる連動を作る話。
そして、90 以上のサブコマンドと大量のテストのほとんどを Claude Code が書いた、bee 開発の裏側の話です。
あわせてご覧ください。
