DEV Community

Cover image for 無料オープンソースCLIツール 開発向け
Akira
Akira

Posted on • Originally published at apidog.com

無料オープンソースCLIツール 開発向け

ほとんどの開発者ワークフローは、依然としてターミナルを中心に動いています。長く使われ続けるツールには共通点があります。それは、コードを確認でき、必要なら自己ホストやフォークができ、シートライセンスや「営業担当に問い合わせる」といった制約に依存しないことです。MIT、Apache、BSD、GPLなどのライセンスでGitHubに公開されているツールなら、ライセンス、メンテナンス状況、コミット履歴を自分で検証できます。

今すぐApidogを試す

この記事では、日々のAPI開発やバックエンド作業に使える、無料かつ真にオープンソースなCLIツールを7つ紹介します。各ツールについて、ライセンス、リポジトリ、すぐに試せるコマンド例、向いている用途と制約を整理します。なお、後半では商用フリーティア製品にも触れますが、OSSツールとは明確に区別します。

対象にする作業は、HTTPリクエストの送信、JSONの解析、APIテスト、GitHub操作、ローカルサーバーの公開、バージョン管理です。まずは必要なツールを1つずつ導入し、必要になった時点で組み合わせてください。

開発用CLIツールを「オープンソース」と判断する基準

「無料で使える」ことと「オープンソース」であることは同じではありません。無料ダウンロードできても、コア機能がクローズドだったり、実用的な機能が有料プランに限定されたりするツールもあります。

このリストでは、次の条件を満たすものをOSSツールとして扱います。

  • OSI承認ライセンスであること MIT、Apache 2.0、BSD、GPLなどのライセンスで提供されていること。商用利用、改変、自己ホスト、フォークの条件を確認できます。
  • ソースコードを確認できること GitHubなどでソース、issue、コミット履歴、リリース履歴を追えること。
  • 不要なロックインがないこと 強制的なアカウント登録、無効化できないテレメトリー、ベンダー運用のサーバーに依存する必須構成がないこと。サービスが必要でも、自分で実行できること。

スター数や直近のコミット数も参考になりますが、標準化の判断では二次的です。導入前に必ずリポジトリのLICENSEファイルを確認してください。

curl: ユニバーサルHTTPクライアント

curlは、HTTP CLIの基準となるツールです。多くのOSに標準搭載されており、シェルスクリプト、Dockerイメージ、CIジョブでも使いやすいのが強みです。ライセンスは寛容なcurlライセンス（MIT/X派生）で、ソースコードはgithub.com/curl/curlで公開されています。

curlロゴ

APIへPOSTリクエストを送る基本例です。

curl -s -X POST https://api.github.com/repos/curl/curl/issues \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"title":"Test issue","body":"Filed from curl"}'
Enter fullscreen mode Exit fullscreen mode

実務では、以下を基本セットとして覚えておくと便利です。

# HTTPステータスとレスポンスヘッダーを確認する
curl -i https://api.example.com/health

# 失敗時に終了コードを非ゼロにする
curl --fail --silent --show-error https://api.example.com/health

# JSONレスポンスをファイルへ保存する
curl -s https://api.example.com/users -o users.json
Enter fullscreen mode Exit fullscreen mode

最適な用途: ポータブルなHTTPリクエスト、シェルスクリプト、CI。

制約: ヘッダー指定やJSON処理が冗長になりやすく、レスポンスの整形にはjqなどを併用することが多くなります。

HTTPie: 人間に優しい出力のcurl

HTTPieは、手動でAPIを調査・デバッグするためのHTTPクライアントです。コマンドが読みやすく、JSONリクエストを簡潔に書けます。レスポンスは色付け・整形されるため、curlよりも対話的な確認に向いています。

ライセンスはBSD-3-Clauseで、リポジトリはgithub.com/httpie/cliです。

インストール後、httpコマンドを使います。

pip install httpie

http POST httpbin.org/post name=apidog role=platform
Enter fullscreen mode Exit fullscreen mode

name=apidogやrole=platformはJSONフィールドとして扱われます。認証ヘッダーを追加する場合も、読みやすい形式で記述できます。

http GET https://api.github.com/user \
  Authorization:"Bearer $TOKEN"
Enter fullscreen mode Exit fullscreen mode

レスポンスヘッダーも確認したい場合は、-vを付けます。

http -v GET https://api.example.com/users
Enter fullscreen mode Exit fullscreen mode

最適な用途: 手動でのAPI探索、レスポンス確認、デバッグ。

制約: Pythonパッケージとして導入するため、厳しく最小化されたCIイメージではcurlの方が扱いやすい場合があります。

jq: JSONパイプラインのためのプロセッサー

APIレスポンスがJSONなら、jqはそのJSONを抽出、変換、整形するための定番CLIです。curlやHTTPieの出力にパイプで接続し、必要なフィールドだけを次の処理に渡せます。

jqはMITライセンスで提供され、github.com/jqlang/jqでメンテナンスされています。

GitHub APIのレスポンスから、必要な情報だけを取り出す例です。

curl -s https://api.github.com/repos/jqlang/jq \
  | jq '{name: .name, stars: .stargazers_count, license: .license.spdx_id}'
Enter fullscreen mode Exit fullscreen mode

配列から必要な要素だけを抽出する場合は、次のように書けます。

curl -s https://api.github.com/users/jqlang/repos \
  | jq -r '.[] | select(.fork == false) | .name'
Enter fullscreen mode Exit fullscreen mode

環境変数やスクリプトで使う値を取得するなら、-rでJSONの引用符を外すのが実用的です。

LATEST_TAG=$(gh api repos/cli/cli/releases --jq '.[0].tag_name')
echo "$LATEST_TAG"
Enter fullscreen mode Exit fullscreen mode

最適な用途: 大きなJSONレスポンスから必要な値だけを取得し、パイプラインへ渡すこと。

制約: 複雑な変換では構文が読みづらくなりがちです。まずは.、.field、.[]、select()、map()から始めるとよいでしょう。

gh: GitHub CLI

ghは、プルリクエスト、issue、リリース、GitHub Actions、REST API、GraphQL APIをターミナルから操作するためのCLIです。GitHub中心の開発フローなら、トークン処理やページネーションを自前で実装せずに済みます。

Goで書かれており、MITライセンスで公開されています。リポジトリはgithub.com/cli/cliです。

まず認証します。

gh auth login
Enter fullscreen mode Exit fullscreen mode

最新リリースのタグを取得する例です。

gh api repos/cli/cli/releases --jq '.[0].tag_name'
Enter fullscreen mode Exit fullscreen mode

issueを作成するなら、次のように実行できます。

gh issue create \
  --title "APIレスポンスの確認が必要" \
  --body "ステージング環境で再現しました。"
Enter fullscreen mode Exit fullscreen mode

PRをCIから操作する場合は、gh prやgh apiを組み合わせます。

gh pr view --json number,title,state
Enter fullscreen mode Exit fullscreen mode

最適な用途: GitHub上のリリース、issue、PR、Actionsをスクリプト化すること。

制約: GitHub専用です。GitLabやGiteaを利用する場合は、それぞれのCLIまたはAPIクライアントを使います。

Hurl: コミット可能なプレーンテキストHTTPテスト

Hurlは、HTTPリクエストとアサーションをプレーンテキストで定義し、テストとして実行するツールです。テストシナリオを.hurlファイルとしてGit管理できるため、API確認を再現可能なチーム資産にできます。

HurlはRust製で、Apache 2.0ライセンスです。ソースコードはgithub.com/Orange-OpenSource/hurlにあります。

repo.hurlを作成します。

GET https://api.github.com/repos/Orange-OpenSource/hurl

HTTP 200
[Asserts]
jsonpath "$.name" == "hurl"
jsonpath "$.stargazers_count" > 1000
Enter fullscreen mode Exit fullscreen mode

テストを実行します。

hurl --test repo.hurl
Enter fullscreen mode Exit fullscreen mode

Hurlはアサーションがすべて成功すると終了コード0、失敗すると非ゼロで終了します。そのため、CIジョブにそのまま組み込めます。

hurl --test tests/*.hurl
Enter fullscreen mode Exit fullscreen mode

レスポンスから値を取り出し、次のリクエストに使うシナリオも作成できます。たとえば、ログインAPIのトークンを後続リクエストに渡す構成です。

POST https://api.example.com/login
Content-Type: application/json

{
  "email": "dev@example.com",
  "password": "{{password}}"
}

HTTP 200
[Captures]
token: jsonpath "$.token"

GET https://api.example.com/me
Authorization: Bearer {{token}}

HTTP 200
Enter fullscreen mode Exit fullscreen mode

最適な用途: Gitで管理する読みやすいHTTP統合テスト。

制約: 完全なコントラクトテストや負荷テスト専用ツールではありません。仕様ファーストのAPI開発では、OpenAPIを信頼できる情報源とし、HurlのようなCLIテストを検証レイヤーとして併用できます。

cloudflared: ローカルサーバーを一時公開する

Webhookのコールバック確認、モバイル実機テスト、外部レビュー用デモでは、ローカルで動いているAPIに公開URLが必要になることがあります。cloudflaredのクイックトンネルを使うと、ローカルポートを一時的なHTTPS URLとして公開できます。

cloudflaredはGoで書かれており、Apache 2.0ライセンスで提供されています。リポジトリはgithub.com/cloudflare/cloudflaredです。

ローカルの3000番ポートを公開するには、次を実行します。

cloudflared tunnel --url http://localhost:3000
Enter fullscreen mode Exit fullscreen mode

実行すると、停止するまで有効な*.trycloudflare.com形式の公開HTTPS URLが表示されます。そのURLをWebhook送信先やモバイルアプリの接続先として指定できます。

npmベースの環境で完結させたい場合は、localtunnel（MIT）も選択肢です。

npx localtunnel --port 3000
Enter fullscreen mode Exit fullscreen mode

最適な用途: アカウント登録なしで行う一時的な公開トンネル。

制約: クイックトンネルのURLはランダムかつ一時的です。固定ドメインや安定したトンネル運用には、Cloudflareアカウントと追加設定が必要です。

git: GUIではなくCLIとして使うバージョン管理

gitはGUIから使われることも多いですが、API仕様、テストファイル、Hurlシナリオ、CI設定を管理する基盤としてCLIが重要です。正確なステージング、rebase、bisect、hookによる自動検証などは、ターミナルから扱うと再現性を確保しやすくなります。

gitはGPLv2ライセンスで、github.com/git/gitで開発されています。

たとえば、コミット前にHurlテストを実行するpre-commit hookを設定できます。

echo 'hurl --test *.hurl' > .git/hooks/pre-commit
chmod +x .git/hooks/pre-commit
Enter fullscreen mode Exit fullscreen mode

チームで共有する場合は、.git/hooksを直接配布するのではなく、hook管理ツールやセットアップスクリプトで導入手順を統一するとよいでしょう。

最適な用途: 仕様、テスト、スクリプト、設定をバージョン管理する基盤。

制約: gitはバージョン管理ツールであり、ホスティングサービスではありません。GitHub、GitLab、Giteaなどのホスティング層は別途選択する必要があります。

正直な余談: Apidogが適合する場所

Apidogはオープンソースではないため、このリストのOSSエントリには含めません。フリーティアのある商用製品であり、curl、jq、Hurl、モックサーバー、ドキュメント生成、環境変数管理などを個別に組み合わせる代わりに、統合されたワークスペースを使いたい場合の選択肢です。

Apidogは、API設計、テスト、モック、ドキュメント作成を一つのワークスペースにまとめます。apidog-cliを使うと、その一部をターミナルから実行できます。

npm install -g apidog-cli
Enter fullscreen mode Exit fullscreen mode

記事で扱ったOSSツールと同様に、CLIの終了コードと構造化されたJSON出力は、スクリプトやCI、AIエージェントとの連携に利用できます。apidog runは成功時に0、失敗時に非ゼロで終了するため、CIの検証ステップに組み込めます。

ロックインを避け、完全なソースアクセスを重視するなら、この記事で紹介したOSSツールの組み合わせが適しています。一方で、複数ツールの接続やパイプライン保守を減らしたいなら、統合プラットフォームを検討できます。CLIルートを試す場合は、インストールガイドで認証と最初のコマンドを確認できます。

選び方

作業内容に応じて選びましょう。多くの場合、1つだけを選ぶのではなく、複数のツールを組み合わせます。

ツール 最適な用途 インストール方法 オープンソース？ 備考
curl ポータブルなリクエスト、スクリプティング プリインストール済み はい（curl/MITスタイル） 多くのシステムですぐ使える
HTTPie 人間に優しいデバッグ pip install httpie はい（BSD-3-Clause） 色付き出力、JSON向け
jq JSONレスポンスの解析 パッケージマネージャー / バイナリ はい（MIT） パイプラインの接着剤
gh GitHub操作の自動化 パッケージマネージャー / バイナリ はい（MIT） GitHub専用
Hurl コミット可能なHTTPテスト 単一バイナリ はい（Apache 2.0） 失敗時は非ゼロで終了
cloudflared 一時的な公開トンネル 単一バイナリ はい（Apache 2.0） クイックトンネルはアカウント不要
git バージョン管理 プリインストール済み はい（GPLv2） 他のツールと成果物の基盤
apidog-cli 統合されたAPIワークフロー npm i -g apidog-cli いいえ（フリーティア） 設計、テスト、モック、ドキュメント

実装の自由度と構成の透明性を重視するなら、単一目的のOSSツールを組み合わせる方法が向いています。セットアップや保守のコストを減らしたいなら、統合プラットフォームが候補になります。包括的なAPI開発プラットフォームとしてのApidogでは、統合アプローチで置き換えられる作業を確認できます。

まとめ

オープンソースCLIの価値は、コードを検証でき、必要に応じて自己ホストやフォークができ、特定ベンダーへのロックインを避けられることにあります。

API・バックエンド開発では、まず次の組み合わせから始めると実用的です。

# HTTPリクエスト
curl -s https://api.example.com/users

# JSONの抽出
curl -s https://api.example.com/users | jq '.[] | .email'

# APIテスト
hurl --test tests/*.hurl

# GitHubリリース情報の取得
gh api repos/owner/repo/releases --jq '.[0].tag_name'
Enter fullscreen mode Exit fullscreen mode

curl、HTTPie、jq、gh、Hurl、cloudflared、gitは、それぞれ異なる役割を持ちます。現在のワークフローで不足している部分から2〜3個導入し、必要に応じて追加してください。

エージェント駆動のワークフローを構築する場合も、ターミナルファーストと構造化JSON出力という考え方は有効です。詳しくは、API開発のためのAIコーディングアシスタントの記事を参照してください。複数ツールの管理を統合したくなった場合は、Apidogをダウンロードし、Apidog CLIを試して、統合ワークフローと比較してみてください。

Top comments (0)