Claude Code の週次タスクを安定させたくて、MCPを捨てて公式CLI（bee / Pup）に移行した話

Posted at 2026-04-20

はじめに

GMOコネクトの永田です。

Claude Code の Skill 機能で、週次の運用タスクを自動化していました。題材は「BacklogとDatadog Case Managementのチケットを集約してAgenda.mdを更新する」という地味なやつです。最初は素直にMCPサーバーで組みましたが、運用していくうちにJSON途切れ・認証切れ・Docker起動忘れが無視できなくなりました😇

最終的に、MCPをやめて bee CLI（Backlog公式）と Pup CLI（Datadog Labs）に置き換えたのですが、どちらも2026年春リリースの新作で、AI agent用途を最初から意識した設計です。

これは、その置き換えで得た知見を整理した記録です。MCPで何か作って「あれ、こんなはずじゃなかった」と感じている人に届けばと思います。

先にまとめ

この記事の要点は4つです。

MCP起因の痛み4つ（JSON 76KB途切れ・Docker常駐・長期APIキー平文・認証切れ途中落ち）が一括で解消した
置き換え先は Backlog: bee CLI / Datadog: Pup CLI（いずれも2026年春リリース、OAuth2対応、AI agent用途を意識した設計）
MCP vs CLI の議論は、人間用途の API vs CLI と同型の構造として読み替えられる
MCPの中でも Local MCPは原則CLI置換・Remote MCPは権限が取れるなら有効、という線引きが実用的

図1: v1（MCP構成）→ v4（CLI + OAuth構成）の Before/After。Docker・Chrome依存の撤去、長期APIキーの置き換え、認証情報の保管場所変更までを含みます。

1. きっかけ: MCPで組んだ週次タスクが詰まった

やりたかったこと

週1回、以下2つを集約して Agenda.md という打ち合わせ資料を更新していました。

Backlog: 案件のチケット状況（未対応・処理中・処理済み・完了）
Datadog Case Management: 外部ベンダーとの依頼事項・障害連絡

これをClaude Codeの Skill 機能で「自然言語で指示したら自動でやる」レベルまで持っていきたかったのです。

最初の実装（v1）

素直に、両方ともMCPで組みました。

Backlog: 公式の Docker イメージ ghcr.io/nulab/backlog-mcp-server を MCP server として起動
Datadog: 当時使える公式MCPの権限が組織管理者から付与されていなかったため、Claude in Chrome MCP で Web UIをスクレイピング

一応動きましたし、何回かは週次タスクを完走できていました。

実運用でぶつかった5つの問題

ところが運用が進むにつれ、以下が頻発するようになりました。

問題	発生状況
MCP出力のJSON途切れ	`get_issues` で一覧取得すると76KB超で応答が途切れる。取りこぼしが出るとAgenda更新の意味がなくなる（※詳細は後述、Claude Code harness 側の `MAX_MCP_OUTPUT_TOKENS` 制限）
Backlog長期APIキーの運用懸念	期限なし・全権限のAPIキーが `.mcp.json` に平文で鎮座。万一漏洩したときの影響範囲が大きい
Chrome経由の逐次操作が遅い	Claude in Chrome はChromeを自動起動してくれるので「詰む」わけではないが、ページ遷移・スクロール・要素特定を1操作ずつ辿るためステータス確認完了まで数分かかる
Docker依存の不安定さ	Docker Desktopが起動していないと実行時にエラー。起動していても放置コンテナが知らぬ間に2個走っていたこともあり、運用負荷が地味に痛い
事前認証チェックなし	MCPは起動済み前提で、認証切れだと途中で落ちる。原因特定に数分持っていかれる

「MCP、大量JSON返すAPIと画面スクレイピングが絡むと脆いな」というのが当時の正直な感想でした。全体像は冒頭の図1のとおりで、以降の章ではこの Before/After にどうたどり着いたかを時系列と観点に分けて書いていきます。

2. MCP vs CLI を API vs CLI として読み替える

この「MCP脆さ」、詰まっている最中は「自分の設計が悪いのかな」と思っていましたが、途中でふと「以前どこかで MCP→CLI のトレンド記事を見かけた気がする」ことを思い出しました。調べてみると、これは自分だけの問題ではなく、業界全体で議論されているトレンドと同じ文脈だったようです。

ここでの気づきを一言でまとめると、次のようになります。

MCP = APIエンドポイント定義 + LLMが自律的にツール選択するためのメタデータ + JSON-RPC前提の標準プロトコル
すなわち AI agent 向けに標準化された API 規格 である。

そう捉えると、「MCP vs CLI」は人間用途における古典的な「API vs CLI」の議論と同型になります。

観点	API（人間用途）	MCP（AI Agent用途）	CLI（両者共通）
構造化	◎（OpenAPI/gRPC）	◎（JSON Schema）	○（テキスト、jq補完）
使いやすさ（手触り）	△（auth, retry, parse）	△（サーバー管理）	◎（パイプ/`--help`）
動的発見	△（事前ドキュメント）	△（起動時一括ロード）	◎（`--help`で都度）
高頻度・大量処理	◎	△（context消費）	◎（pay-as-you-go）

図2: 同じcontext windowでも、MCPは起動時に全ツール定義を一括ロードして72%を占有する一方、CLIは --help を通じた必要時の都度読み込みでpay-as-you-go。

ただし、人間用途と AI agent 用途には重要な非対称性があります。LLMはテキスト直接パースが得意で構造化の優位が縮小し、lazy discovery のほうが context window に優しく、試行錯誤で学習するため型システムの恩恵も人間より薄くなります。結果として、AI agent にとってCLIはAPIより劣るどころか、構造的に優位な領域がある、というのが2026年に表面化した経験則です。

概念や定量比較をより深く追いかけたい場合は、§3 末および記事末尾の参考リンクに各論者のベンチマーク・解説記事をまとめています。以降は「概念は前提として、実案件でCLIに寄せたらどう動いたか」に軸を置きます。

3. 業界動向: 2026年のMCP → CLI 回帰トレンド

主要な論客と定量データ

この話、自分で気づいたというより業界が先に言語化していたというのが実態です。主な動きを時系列で整理します。

2025年10月 Claude Skills 発表: Simon Willisonが「SkillsはMCPより大きな変化かもしれない」と言及。MCPのトークン消費がコンテキストウィンドウを食いつぶす問題を指摘
Armin Ronacher（Flask作者） が MCP → Skills/CLI への完全移行を表明
Scalekit ベンチマーク: 同一GitHub作業で MCPはCLIの32倍のトークンを消費（1,365 vs 44,026 tokens）
Mario Zechner ベンチマーク: MCP ~52,000 tokens vs CLI ~1,200 tokens（本人の結論は「プロトコルはplumbingに過ぎない」と慎重だが、数値のインパクトは大きい）
Garry Tan（Y Combinator） / Denis Yarats（Perplexity CTO） もMCP批判・移行を表明

根本原因は、MCPが起動時に全ツール定義を一括ロードするプロトコル設計にあります（仕様上の制約で、バグではありません）。3サーバー構成で200Kコンテキストの72%を占有するケースも報告されています。さらにツール数が増えるほど LLM のツール選択精度が落ちる context rot という論点もあります（定量値は観測条件で幅があるため、ここでは「ツール数増で選択精度が低下する」という定性まで）。

公式CLIの整備自体が2026年トレンド

今回採用した2つのCLIは、いずれも2026年春にリリースされたばかりの新作です。

CLI	提供元	初期リリース	最新版（執筆時）
bee CLI	Nulab 公式	2026-03-09（v1.0.0-rc.0）	v1.0.0（2026-04-01）
Pup CLI	Datadog Labs	v0.38.0（2026-03-27、現行最古の公開release）	v0.49.0（2026-04-12）

「MCP前夜にあった公式CLI」ではなく、MCPの限界が顕在化した後に各SaaS側が AI agent 用途を明確に意識して整備し始めた新世代CLI です。実際、両者ともREADMEや公式ドキュメントで「AIエージェントのcompanion」を主要ユースケースとして掲げています。

Pup CLI: README冒頭に "Give your AI agent a Pup — a CLI companion with 325+ commands across 57 Datadog product domains"（執筆時点のv0.49.0）
bee CLI: 公式ドキュメントに「AIエージェントとの連携」専用ページ

「2026年以降に公式CLIが（新規または追加で）リリースされたら、それは AI agent 向けに設計されている可能性が高い」 ——これも2026年の特徴的な動きです。既存の大手SaaS（Backlog・Datadogはまさにその例）も、AI agent 時代に合わせて改めてCLIを整備し始めています。

役割分担の議論: MCP / CLI / Skills

ただし「MCPを捨ててCLI一本に」という単純な話ではなく、各レイヤが違う役割を担う、という議論が並行して進んでいます。目立った論点をいくつか引用しておきます。

Armin Ronacher（Flask作者） は Skills vs Dynamic MCP Loadouts でSkills優先の立場を明確にし、"ask the agent to write its own tools as a skill" という方針を示しています。MCPそのものへの懐疑も強めです
Bo-Yi Wu は The Next Step for AI Agents: API + CLI + Skills Architecture で、堅牢なAPI → CLIでラップ → Skillsで組み合わせを教える という3層設計を提唱。「ほとんどのケースではMCPサーバー構築を急ぐべきでない」と断じています
Themen on Blog の Skills vs MCP: The Token Efficiency War (And Why It's Not Either/Or) は、両者を補完関係と位置付けつつ、Scalekit の 32× トークン比較で CLI/Skills の効率性を定量的に示しています

各論者の主張を踏まえて、本記事では次のように役割を整理しておきます。

レイヤ	使いどころ	トークンコスト特性
Skills	手順・ドメインルール・コーディングパターン	progressive disclosure により初期ロードはメタデータのみ（数十トークン/件）、本体は発動時のみ
MCP	動的操作（リアルタイム検索、コンテンツ生成、副作用を伴うアクション）	起動時に全ツール定義を一括ロード。サーバー数が増えると context window を強く圧迫
CLI	定型的な読み取り・書き込み（チケット一覧、issue取得、ログ検索等）	完全pay-as-you-go。`--help` やコマンド出力を必要時に都度読み込み

今回の Backlog/Datadog 連携は 定型読み取り主体のワークロード なので、CLIレイヤに寄せるのが最適解でした。

Local MCP と Remote MCP で評価軸を分ける

もう一つ、実装に入る前に線を引いておきたい観点があります。MCPは local（stdio / Docker） か remote（SaaS hosted HTTP） かで評価軸がガラッと変わります。

Local MCP（例: 今回廃止した ghcr.io/nulab/backlog-mcp-server）

Docker常駐、停止/削除の運用、image更新といったコンテナ管理コスト
.mcp.json への鍵保管、複数IDE設定との同期
ツール定義一括ロードの context 消費
ローカルプロセス相当の機能なので、CLI直叩きと機能的にほぼ同じ

結果として「MCPプロトコルの恩恵をほぼ受けず、運用コストだけ払っている」ことが多いです。公式CLIがあるなら無条件でCLI置換でよいです。

Remote MCP（例: Datadog 公式の mcp.datadoghq.com）

SaaS側がホスト、認証はOAuth、更新は自動反映で 運用コストがゼロ
ツール定義の整合性もSaaS側で担保
Context消費の問題は残るが、運用コスト消滅とのトレードオフ

今回はDatadog側の mcp_read 権限が組織管理者から付与されておらず使えませんでしたが、権限さえあれば Remote MCP は選択肢として十分有効だった可能性が高いです。軽い探索的クエリなら Remote MCP の方が手軽でしょう。

4. 移行: 段階的リファクタ

移行プロセスを時系列で晒します。先に断っておくと、綺麗な戦略があったわけではありません。

v1→v2: Backlog MCP → curl + jq

まずは先の表で最上段に挙げた JSON途切れ（get_issues の応答が76KB超で途切れ、チケットを取りこぼす件）から潰しにいきました。Backlog REST APIは普通に curl で叩けるので、MCPを剥がして curl + jq に置換します。

補足: なぜMCPだと途切れ、CLI+jqだと途切れないのか

この途切れは MCPプロトコル仕様や backlog-mcp-server の実装の問題ではなく、Claude Code ハーネス側のMCPレスポンス制限 です。Claude Codeは各MCPツールの応答を デフォルトで25,000トークン に制限しており、超過すると自動でtruncationが走ります。関連issue: #9152（"MCP tool response (137411 tokens) exceeds maximum allowed tokens (25000)" の直接エラー例）、#47631（ドキュメント不備指摘）、#42869（サーバー側の結果サイズ上書き仕様）。

「CLI/curl + jq だって同じ上限があるのでは？」はその通りで、Bash tool にもデフォルト30,000文字（BASH_MAX_OUTPUT_LENGTH）の middle-truncation があります（参考: #19901）。ではなぜCLI+jqの方が詰まりにくいかというと、パイプで「harnessに渡る前」にフィルタできる からです。同じ13件のチケット取得で、MCPは生JSONが ~76KBで丸ごとharnessに届いてから切れる一方、curl ... | jq -r '.[] | "\(.issueKey) ..."' なら shell 内で整形されて ~1KBに圧縮されてから Claude の目に入ります。--json id,name,status のようなフィールド絞り込みに対応したCLI全般の構造的優位性でもあります。

set -a; source .env; set +a

curl -sS -G "https://${BACKLOG_DOMAIN}/api/v2/issues" \
  --data-urlencode "apiKey=${BACKLOG_API_KEY}" \
  --data-urlencode "projectId[]=<YOUR_PROJECT_ID>" \
  --data-urlencode "statusId[]=1" --data-urlencode "statusId[]=2" --data-urlencode "statusId[]=3" \
  --data-urlencode "count=100" \
  | jq -r '.[] | "\(.issueKey) [\(.status.name)] <\(.issueType.name)> \(.summary)"'

これで13件のアクティブチケットを途切れなく1行サマリで取得できます。実測1秒未満です。

同時にBacklog MCPコンテナ2件とDockerイメージ（630MB）を削除しました。APIキーは .mcp.json から .env（chmod 600）へ移設しています。

v2→v3a: Datadog curl化を試みて撃沈

Backlogと同じノリで Datadog API も curl 化しようとして権限の壁に当たりました。

Datadog API は DD-API-KEY + DD-APPLICATION-KEY 認証
Application Key 発行には組織管理者が付与する user_app_keys 権限が必要
利用中のテナントでは未付与。個人用ページも見られない

公式 MCP (mcp.datadoghq.com) も試しましたが、こちらも mcp_read / mcp_write スコープがadmin承認制でした。詰みです。

v2→v3b: Pup CLI 発見、DCR で突破

Zenn の記事で Pup CLI の存在を知り、こちらを試したところ一気に抜けました。

OAuth2 + Dynamic Client Registration（DCR, RFC 7591） を採用
ブラウザで Datadog にログインすれば、Pup が自動でOAuthクライアントを登録
admin の事前承認は不要（ユーザー自身がログインできればAPIも叩ける）
Case Management API に対応

brew install datadog/pack/pup
pup auth login --read-only --subdomain <your-subdomain> --site datadoghq.com
# ブラウザが開いて認可 → トークンはmacOS Keychainに保存

pup --no-agent cases search \
  --query "project_id:<UUID> (status:OPEN OR status:IN_PROGRESS)" \
  --page-size 50 --output json \
  | jq -r '.data[] | "\(.attributes.key) [\(.attributes.status)] \(.attributes.title)"'

ここでの学びは、同じOAuth2でも「サービス側のOAuthアプリ登録モデル」次第で、個人が使えるか admin-gated か決まるという点です。Pup は DCR 採用のおかげでadmin不要になっています。

v3→v4: bee CLI も公式OAuth対応と判明

Datadogが片付いた勢いで、Backlogも公式CLIないかと検索したら bee CLI を発見しました。こっちも OAuth2 対応です。

当初は「Backlog OAuthアプリ登録は space admin 権限必要では」と警戒していましたが、実際は違いました。

Backlog の OAuth アプリ登録先は Nulab Developer Portal
space の admin 設定ではなく、個人のNulabアカウントで登録する
Redirect URIは任意、localhostも使える

npm install -g @nulab/bee
# .env に BACKLOG_OAUTH_CLIENT_ID / BACKLOG_OAUTH_CLIENT_SECRET / BACKLOG_SPACE を追加
set -a; source .env; set +a
bee auth login -m oauth

bee issue list -p <YOUR_PROJECT_KEY> -S 1 -S 2 -S 3 -L 100 --json \
  | jq -r '.[] | "\(.issueKey) [\(.status.name)] <\(.issueType.name)> \(.summary)"'

Datadog DCR vs Backlog 個人登録: どちらも admin 不要ですが、前者はCLIが自動で登録、後者は Portal で手動登録、という違いがあります。

正直なところ: 公式CLIの存在を知らなかっただけ

この MCP廃止 → curl+jq → 公式CLI という2段階の経緯、綺麗な戦略があったわけではなく、単に公式CLIの存在を知らなかっただけでした。

「SaaSにはAPIがある」というイメージはあっても「CLIがある」という発想自体が抜け落ちていたのです。この前提が更新されたきっかけは、以前見かけた MCP→CLI トレンド記事をぼんやり思い出したからという偶然でした。そこで「もしかしてBacklogにも公式CLIあるんじゃ？」と検索して見つかった、という流れです。

結果としてはこの2段階を踏んだことで「最小構成が動く安心感の上でリファクタできる」というメリットはありましたが、最初から知っていれば一気に公式CLIへ行っていました。

教訓: SaaSと連携するときは、新規・既存を問わず最初に「公式CLIあるか？」を1分でも調べる価値があります。2026年は大手既存SaaSも含めて AI agent 向けCLIを出し始めているフェーズなので、「以前調べたときは無かった」という記憶は当てになりません。半年前の調査結果でも古い可能性があります。

5. 実装ノウハウ

bee CLI: OAuth アプリ登録と認証

Nulab Developer Portal にアクセス: https://backlog.com/developer/applications/
初回は「Backlog API Developer の利用を開始しますか？」のオプトインに応諾
Application を登録:
- Redirect URI: http://localhost:5033/callback（bee v1.0.0 実測値。公式docsでは明言されていないので、将来バージョンで変わる可能性あり）
- アプリケーション名: 任意（例: MyProject Local CLI）

発行された Client ID / Client Secret を .env に書き込む（chmod 600 で権限を絞る）

# /Users/xxx/project/.env
BACKLOG_SPACE=your-space.backlog.com
BACKLOG_OAUTH_CLIENT_ID=<Nulab Dev Portal発行>
BACKLOG_OAUTH_CLIENT_SECRET=<Nulab Dev Portal発行>

set -a; source .env; set +a で環境変数をロードしてから bee auth login -m oauth でブラウザ認可

Pup CLI: インストールと認証

brew tap datadog/pack
brew install datadog/pack/pup
pup auth login --read-only --subdomain <your-subdomain> --site datadoghq.com

DCRなので事前の Client ID 発行などは不要です。初回起動時にPupが自動でOAuthクライアントを登録してくれます。トークンはmacOS Keychainに格納され、refresh tokenで透過的に更新される設計です（アクセストークンの具体的な有効期限はDatadog側仕様でバージョン依存）。

Step 0: 事前認証チェック

両CLIともOAuthなので、Skillの実行開始時にトークン状態を確認するチェックを入れています。認証切れを開始数秒で検知できるので、原因切り分けが速くなります。

# .env ロード
set -a; source /path/to/.env; set +a

# Backlog
if bee auth status 2>&1 | grep -q "Authenticated"; then
  echo "✅ Backlog: 認証OK"
else
  echo "❌ Backlog: 未認証"
fi

# Datadog
pup --no-agent auth status --output json 2>/dev/null \
  | jq -r 'if .authenticated and (.scopes|contains(["cases_read"]))
           then "✅ Datadog: 認証OK (expires \(.expires_at))"
           else "❌ Datadog: 未認証"
           end'

ハマりどころ

#	内容
1	Pup CLI 自動 agent mode: AI assistant 検出時は `--help` がJSON schemaになる。人間向けは `--no-agent` を付ける
2	bee CLI 環境変数3種必須: `BACKLOG_SPACE` / `BACKLOG_OAUTH_CLIENT_ID` / `BACKLOG_OAUTH_CLIENT_SECRET` のどれか一つ欠けるとログイン失敗。エラーメッセージが短くて原因切り分けに時間食う
3	Datadog subdomain と site: `<your-subdomain>.datadoghq.com` なら `--site datadoghq.com --subdomain <your-subdomain>` の両方指定
4	Backlog OAuth 登録先の勘違い: space admin画面ではなく Nulab Developer Portal（個人アカウント）で登録する

6. 汎用化チェックリスト: 他SaaSに展開するとき

ワークロード別の使い分け

ワークロード	第一選択	備考
定型的な読み書き（一覧取得、ステータス確認、更新）	CLI（公式優先、なければREST API直叩き）	本記事の Backlog/Datadog ケースはここ
動的・探索的タスク（複雑な検索、対話的分析）	Remote MCP（権限が取れる場合）or CLI + LLM処理	Remote MCPは運用コストゼロが強み
Local Docker MCPしかない場合	できれば CLIまたはREST APIに置換	MCPプロトコルの恩恵を受けにくく三重苦になりがち
基盤知識・手順の定型化（ドメインルール、コーディング規約）	Skills	progressive disclosureで初期コスト極小

CLI採用時に見ておくべきポイント

ワークロード的にCLIに寄せると決めたら、次の観点で候補CLIを評価するとハマりにくいです。

OAuth2 の登録モデル
- Dynamic Client Registration 対応 → 最強。admin不要
- 個人アカウントレベルで登録可 → 許容範囲
- org/space admin必要 → 依頼コスト発生、事前調整必要
JSON 出力品質
- --output json / --json で構造化出力できるか
- フィールド選択やフィルタがAPI側で効くか（クライアント側jqは次善策。§4 冒頭の補足で触れたharness制限回避の観点でも重要）
トークン保存先
- Keychain（macOS）やcredential helper（Linux）を使うCLIが堅い
- プレーンファイルでも chmod 600 が最低ライン
Agent モード対応
- Pup CLI のように AI agent 自動検出で出力を切り替える設計は使い勝手が良い

おわりに

使い分けの指針は§3・§6にまとめたので、最後は今回の個人的な教訓を2つだけ置いておきます。

「SaaSにはAPIがある」は知っていても「CLIがある」という発想が抜けやすい。新規・既存を問わず、最初の1分で「公式CLIあるか？」を検索する
半年前の調査結果は当てにならない。2026年春はSaaS公式CLI第一波（bee / Pup 等）の時期で、直近で状況が変わった領域には特に注意

MCPは有望な規格ですが、仕様レベルで「起動時一括ロード」という制約がある以上、CLI とのハイブリッドで使い分けるのが現時点での落としどころです。公式CLIが整備された SaaS では CLI ファーストで設計する、というのが今回の結論でした。

最後に、GMOコネクトではサービス開発支援や技術支援をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。

お問合せ：https://gmo-connect.jp/contactus/

参考リンク

実装関連

業界動向（MCP ⇔ CLI ⇔ Skills 議論）

Skills vs Dynamic MCP Loadouts | Armin Ronacher — Skills優先論、MCPへの懐疑的立場
The Next Step for AI Agents: API + CLI + Skills Architecture | Bo-Yi Wu — API/CLI/Skills 3層設計の提唱
Claude Skills are awesome, maybe a bigger deal than MCP | Simon Willison — Claude Skills 発表時のMCP対比評価
Skills vs MCP: The Token Efficiency War — Scalekit 32×トークン比較ベンチマーク
My Take on the MCP vs CLI Debate — バランス総論
Drop MCP? Why CLI Is Becoming the Default Tool Layer for Agents
MCP vs. CLI for AI agents: When to Use Each — 2026年版意思決定フレーム
Context Bloat in MCP: Why You Need to Slice Your MCP Servers — 72%context占有問題
Is MCP Dead? MCP vs CLI vs Agent Skills Compared

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up