前回、AI エージェントから Backlog を操作するために API キーを発行する という記事で、Claude Code や Codex から Backlog の REST API を叩く運用を紹介しました。API キーを渡して curl を投げれば動くのですが、実運用に入れてみると細かい摩擦が積み上がります。
- API キーを環境変数に置いても、URL クエリに
apiKey=...として載る以上、コマンド履歴や共有スクリプトに残りやすい - レスポンスが生 JSON なので、エージェントに渡す前に整形するかどうか毎回悩む
- 「自分の未対応課題」など、頻出の操作でもエンドポイントとクエリを毎回組み立てる必要がある
このあたりを一段抽象化してくれる CLI が Nulab 有志から出ていました。今回はそれ、bee を試したので、AI エージェント運用にどう効くかを共有します。
bee とは何か
bee は、一言でいえば GitHub CLI（gh）の Backlog 版です。プロジェクト・課題・Wiki・通知・ダッシュボードといった Backlog の主要リソースを、gh issue list 風のコマンド体系で扱えます。
ひとつ注意点として、bee は Nulab の公式サポート製品ではありません。README にも明記されているとおり、Nulab 有志によるボランティア OSS（MIT ライセンス）です。とはいえ実装は Nulab の中の人が主導しており、Backlog の 公式 REST API を叩く構造なので、認証やアクセスの筋は前回記事で紹介した API キー運用とそのまま重なります。前回の「エージェント専用ユーザーで API キーを持つ」という結論を、そのまま bee 側に引き継げます。
インストールと初回認証
bee は npm パッケージとして配布されており、Node.js 20.18 以上が必要です。
npm install -g @nulab/bee初回はスペースごとにログインします。ブラウザ経由の OAuth と、前回発行した API キーの両方に対応しており、エージェント用途では API キー方式のほうが扱いやすいはずです。
bee auth login
bee auth status複数の Backlog スペースを併用している場合は bee auth switch でアクティブなスペースを切り替えられます。ここまで通っていれば、以降のコマンドは認証情報を暗黙に使ってくれます。
AI エージェントから bee を使う流儀
curl 直叩きからの一番大きな変化は、API キーがコマンドラインの表舞台から消えることです。bee の認証情報はローカルの設定ファイルに隔離されるため、Claude Code や Codex に渡すシェルコマンドに apiKey=xxx を書かなくて済みます。エージェントのプロンプトやコマンド履歴に API キーが混入するリスクが、構造的に下がります。
もう一つは、出力の扱いやすさです。デフォルトは人間向けの整形出力ですが、多くのサブコマンドは --json フラグで機械可読な JSON を返します。エージェント側にパースを任せるにしても、生 REST を叩くよりフォーマットが安定します。
それでも生の REST に降りたい場面（Backlog 側の新しめのエンドポイントを試したいなど）では、bee api <endpoint> を使えば認証を再利用したまま任意のエンドポイントを叩けます。curl を書き足すより安全で、しかも短く済みます。
代表的なユースケース
bee --help で並ぶサブコマンドは auth・project・issue・document・notification・pr・repo・team・user・wiki・category・milestone・issue-type・space・status・star・watching・dashboard・browse・api・completion と、Backlog のリソースにほぼ一対一で対応しています。AI エージェントに任せたい典型操作は、だいたいこの中に収まります。
例えば「自分向けの未読通知や未対応課題の状況」を一枚にまとめて把握したいときは、次の一行で足ります。
bee dashboard課題の詳細を確認するときは、Backlog 側の課題キーをそのまま渡します。
bee issue view PROJ-123新規課題の作成やコメントの追加も、gh issue create に近い感覚で書けます。
bee issue create -p PROJ -t "デプロイ後のスモークテスト自動化" --description "対象環境: staging"
bee issue comment PROJ-123 --body "本番反映しました"Wiki の閲覧も、Web UI に切り替えずに済みます。
bee wiki list -p PROJハマりどころ: --status open は動かない
ここまで書いておいて、実運用に入れて素直にハマったのが bee issue list のステータス指定です。GitHub CLI の癖で、こう書きたくなります。
bee issue list --status openこれは動きません。bee の --status は status ID（数値）を要求するため、"open" を渡すと Invalid type: Expected number but received NaN というエラーで弾かれます。
Backlog の標準ステータスは 1=未対応・2=処理中・3=処理済み・4=完了 なので、「未完了の課題」（GitHub 的な “open” 相当）を出したければ、-S（ステータス ID）を複数指定します。
bee issue list -a @me -S 1 -S 2-a @me は「自分がアサインされている課題」を意味するショートハンドで、これが一発で書けるのは CLI ならではの気持ちよさです。プロジェクトによっては標準ステータスの外にカスタム状態が定義されているので、事前に ID を確認しておくと確実です。
bee status list -p PROJなお、オプション名の大文字小文字にも注意が必要です。-S はステータス ID、-a は担当者と、gh の慣習 から少しだけ外れています。エージェントに渡すプロンプトやスニペット集を整備するときは、この辺りをテンプレート化しておくとハマりが減ります。
まとめ
Backlog を AI エージェントから扱う運用は、前回記事で紹介した「エージェント専用ユーザーの API キー方式」で十分に成立します。そのうえで、日常の操作を bee に寄せると、API キーをコマンドラインから見えなくできる・出力が構造化される・bee api で生 REST にも降りられる、といった実用面のメリットが積み上がります。
bee は Nulab 有志によるボランティア OSS なので、公式サポート製品と同じテンションで期待しすぎるのは避けるべきですが、CLI としての完成度は高く、AI エージェント時代の Backlog 運用を一段ラクにしてくれます。当面は「エージェント専用ユーザー ＋ bee」を基本装備にしつつ、bee 本体および Backlog 公式の API キー実装がさらに整うのを楽しみに待ちたいところです。
以上、curl 直叩きから Backlog CLI「bee」に乗り換えて AI エージェント連携をもう一段ラクにした、現場からお送りしました。