Anthropic公式CLI「ant」実践ガイド — curlを卒業してYAMLでClaude APIを管理する新しい開発ワークフロー
なぜ今antなのか — curl・SDK・antの使い分け
Claude APIを叩くたびにcurlで長大なJSONを手書きしていないだろうか。2026年4月、Anthropicが公式リリースしたCLIツール「ant」は、APIリクエストをYAMLで管理し、レスポンスをGJSONで加工し、beta機能をプレフィックス一つで試せる。本記事では、curlやSDKとの比較から始め、実際のユースケース別にコマンド例を示しながら、Claude Codeとのネイティブ連携までを解説する。
curlの限界:JSONエスケープ地獄とヘッダー管理の煩雑さ
同じMessages APIリクエストを3つの方法で比較してみよう。
# curl — JSON手書き
curl -X POST https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{"model":"claude-sonnet-4-6","max_tokens":1024,"messages":[{"role":"user","content":"Hello, Claude"}]}'
# Python SDK — 本番コード向き
import anthropic
client = anthropic.Anthropic()
message = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
messages=[{"role": "user", "content": "Hello, Claude"}]
)
# ant — コマンド一発
ant messages create \
--model claude-sonnet-4-6 \
--max-tokens 1024 \
--message '{role: user, content: "Hello, Claude"}'
curlではヘッダーを毎回指定し、JSONのネストやエスケープと格闘する。SDKはアプリケーションに組み込む本番コード向けだ。antはその中間、プロンプトの検証・デバッグ・シェルスクリプトでの自動化に最適なポジションを占める。Go製のシングルバイナリで依存ゼロという点も、CIやパイプラインへの組み込みやすさに直結する。
SDK vs ant:コードを書くか、コマンドを叩くか
棲み分けはシンプルだ。SDKは本番アプリケーションのコードに組み込む用途、antはプロンプトの反復検証やCI/CDでのワンショット実行に使う。「ちょっとAPIの挙動を確かめたい」ときにPythonファイルを書くのは大げさすぎる。
インストールと初期設定
macOSならHomebrewが最も手軽だ。
# macOS
brew install anthropics/tap/ant
# Linux/WSL — バイナリ直接ダウンロード
VERSION=1.3.2
OS=$(uname -s | tr '[:upper:]' '[:lower:]')
ARCH=$(uname -m | sed -e 's/x86_64/amd64/' -e 's/aarch64/arm64/')
curl -fsSL "https://github.com/anthropics/anthropic-cli/releases/download/v${VERSION}/ant_${VERSION}_${OS}_${ARCH}.tar.gz" \
| sudo tar -xz -C /usr/local/bin ant
# Go
go install github.com/anthropics/anthropic-cli/cmd/ant@latest
APIキーを環境変数に設定し、疎通確認する。
export ANTHROPIC_API_KEY=sk-ant-api03-...
ant --version # v1.3.2
ant models list # 利用可能なモデル一覧
基本操作 — リソース:アクション構文を理解する
コマンド構造
antのコマンドは ant <resource>[:<subresource>] <action> [flags] というパターンに従う。
ant messages create ... # Messages API
ant models list # モデル一覧
ant beta:agents retrieve --agent-id agent_01... # betaリソース
ant beta:sessions:events list --session-id ... # ネストしたサブリソース
@pathによるファイルインラインと出力フォーマット制御
@path記法を使うと、ファイルの中身をリクエストに自動展開できる。テキストファイルはそのまま文字列に、バイナリファイルは自動でbase64エンコードされる。
# システムプロンプトをファイルから読み込み
ant messages create \
--model claude-opus-4-7 \
--max-tokens 1024 \
--system @./prompts/reviewer.txt \
--message '{role: user, content: "このコードをレビューして"}'
# PDFをVision APIに送信(自動base64エンコード)
ant messages create \
--model claude-opus-4-7 \
--max-tokens 1024 \
--message '{role: user, content: [
{type: document, source: {type: base64, media_type: application/pdf, data: "@./report.pdf"}},
{type: text, text: "この資料を要約して"}
]}' \
--transform 'content.0.text' --format yaml
明示的にエンコード方式を指定したい場合は @file://(テキスト強制)と @data://(base64強制)が使える。リテラルな@が必要な場合は @ でエスケープする。
出力形式は auto、json、jsonl、yaml、pretty、raw、explore の7種類。autoはターミナル出力時にpretty-print、パイプ時にcompact JSONへ自動切り替えされる。正直、この自動判定だけでも地味に便利だと感じる。--format exploreではTUI形式のインタラクティブブラウザが開き、大きなレスポンスの探索に重宝する。
--transformはGJSONパス構文でレスポンスの一部だけを抽出する。listエンドポイントでは各アイテムに個別適用される。
# テキスト部分だけ抽出
ant messages create ... --transform 'content.0.text' --format yaml
# agentのid, name, modelだけ一覧
ant beta:agents list --transform '{id,name,model}' --format jsonl
実践ユースケース3選
プロンプトの反復検証:YAMLファイルで管理してantで即実行
プロンプトのチューニングでは同じリクエストを何度も微調整して投げる。YAMLファイルに書いておけばパラメータの変更が楽になる。
# prompt.yaml
model: claude-sonnet-4-6
max_tokens: 1024
system: |
あなたはシニアコードレビュアーです。
セキュリティ上の問題を重点的に指摘してください。
messages:
- role: user
content: |
以下のコードをレビューしてください。
...
ant messages create < prompt.yaml --transform 'content.0.text' --format yaml
beta:プレフィックスでManaged Agentsを操作する
beta:プレフィックスを付けると、anthropic-betaヘッダーが自動付与される。手動でヘッダーを管理する必要がない。
# エージェント作成(YAMLヒアドキュメント)
ant beta:agents create <<'YAML'
name: Research Agent
model: claude-opus-4-7
system: |
あなたはリサーチアシスタントです。主張には必ず出典を付けてください。
YAML
# IDを変数にキャプチャ
AGENT_ID=$(ant beta:agents create \
--name "My Agent" \
--model '{id: claude-sonnet-4-6}' \
--transform id --format yaml)
シェルスクリプト・CI/CDパイプラインへの組み込み
依存ゼロのシングルバイナリなので、GitHub Actionsへの組み込みも簡単だ。
# .github/workflows/review.yml(抜粋)
- name: AI Code Review
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
run: |
DIFF=$(git diff HEAD~1)
echo "$DIFF" | ant messages create \
--model claude-sonnet-4-6 \
--max-tokens 2048 \
--system "コード差分をレビューし、問題点を指摘してください" \
--message "{role: user, content: \"$(cat)\"}" \
--transform 'content.0.text' --format yaml
listエンドポイントは自動ページネーションされるため、--max-itemsで上限を指定しない限り全件取得される。
Claude Codeとのネイティブ連携
Claude Codeはantの使い方を最初から理解している。antがインストール済みでANTHROPIC_API_KEYが設定されていれば、Claude Codeのチャット内から直接APIリソースを操作できる。
たとえば以下のような指示が通る。
- 「最近のagentセッション一覧を取得して、エラーになったものを要約して」
- 「
./reports内のPDFをすべてFiles APIにアップロードして」 - 「セッション
session_01...のイベントを取得して、agentがどこで止まったか教えて」
Claude Codeがant経由でシェルコマンドを実行し、構造化された出力をパースして結果を返してくれる。個人的には、「実装はClaude Code、API検証はant」という二刀流が最も効率的なワークフローだと感じている。
自律開発デーモンのような仕組みでも、claude -pでプロジェクト全体の実装を進めつつ、特定のプロンプトの挙動を確認したいときにantで単発のAPI呼び出しを行う、という使い分けが有効だ。
ハマりポイントと注意点
@pathのファイルパス。チルダ展開はシェルが行うため、@~/file.txtは意図通りに動かない場合がある。@./file.txtや絶対パス@/Users/.../file.txtを使うのが確実だ。
--transformのGJSON構文。配列アクセスはドット記法でcontent.0.textと書く。content[0].textではない。最初は戸惑うが、GJSON公式のSYNTAX.mdを一読しておけば迷わなくなる。
レート制限。antは自動リトライしない。シェルスクリプトに組み込む場合は自前でリトライを実装する必要がある。
# シンプルなリトライパターン
for i in 1 2 3; do
result=$(ant messages create ... 2>&1) && break
echo "Retry $i..." >&2
sleep $((i * 30))
done
beta:リソースの安定性。beta名前空間のAPI仕様は変更される可能性がある。本番ワークフローに組み込む場合は--betaフラグでバージョンを明示するか、破壊的変更に備えたテストを用意しておこう。
デバッグ。何かおかしいと思ったら--debugを付ける。HTTPリクエストとレスポンスの全文がstderrに出力される(APIキーは自動でマスクされる)。
まとめ
antはClaude APIとの対話を「JSONを手書きする作業」から「YAMLで管理してコマンド一発で実行する体験」に変えるツールだ。
- SDK = 本番アプリケーションのコードに組み込む
- ant = プロンプト検証、デバッグ、CI/CDでのワンショット実行
Claude Codeとの組み合わせにより、「実装はClaude Code、API検証はant」という効率的なワークフローが実現する。
まずは brew install anthropics/tap/ant して、普段curlで叩いているAPIリクエストを一つantに置き換えてみてほしい。YAMLでプロンプトを管理し、--transformで必要な部分だけ抽出する快適さを知ったら、もうcurlには戻れないはずだ。
