airはGo開発の変更検知と再起動を担うライブリロードCLI
Go アプリのライブ リロード。従来の build.bin フィールドは非推奨であり、将来のリリースでは削除される予定なので、今後はエントリポイント フォームの使用をお勧めします。
ひと目でわかる
- これは何？
- Goプロジェクトを監視し、変更時に再ビルドと再起動を行うツールで、設定ファイル、ウォッチルール、開発用プロキシを備えます。
- 誰に向いている？
- Goアプリをローカル開発で頻繁に再起動するチームに向いており、本番のデプロイや可用性を担保する仕組みを求める用途には向きません。最初にair.tomlの監視対象、ビルド失敗時の動作、tmpの扱い、プロキシのHTML条件を確認し、実際の編集、削除、構文エラー、生成ファイル変更で再現性を確かめます。
- 商用利用できる？
- 条件付きでできます。GPL-3.0 はコピーレフトのライセンスで、これを含むソフトウェアを配布する場合、そのソフトウェアのソースコードを同じライセンスで公開する必要があります。配布せず社内で使うだけなら、この義務は生じません。
- 今もメンテナンスされている？
- されています。最後のコミットは 20 日前です。
- 何の言語で書かれている？
- 主に Go です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月14日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
開発時の変更ループ
airはGoアプリのファイル変更を検知し、バイナリを再ビルドして再起動します。READMEは、現在のディレクトリの.air.tomlを優先し、なければ既定値を使い、必要に応じて設定ファイルを生成する流れを示します。目的は開発中のフィードバック短縮であり、実行中サービスの無停止更新や本番デプロイを説明するツールではありません。
インストール経路と版の固定
READMEはgo install、go get -tool、install.sh、Homebrew、Scoop、mise、Docker/Podmanなど複数の導入経路を案内します。Go 1.25以上を要求する開発手順も記載されています。複数の方法を混ぜると実行されるairの場所が曖昧になるため、CIと開発者端末で使う経路を決め、air -vとPATHを記録します。
entrypointへの移行
設定ではbuildコマンドと起動引数を指定できます。旧来のbuild.binは非推奨で、将来削除されるため、READMEはbuild.entrypointを推奨しています。entrypointは文字列または配列で書けます。既存設定を更新する場合は、同じバイナリ名、引数、作業ディレクトリで起動するかを確認し、旧フィールドへの依存を残さないようにします。
ウォッチルールとプロキシ
[[build.rules]]では、特定のファイル変更時に再ビルドの代わりにコマンドを実行できます。includeマッチャー、exclude_regex、ミリ秒単位のdelayを使う設計です。proxy_portからapp_portへ転送する開発用プロキシは、再ビルド成功後にHTMLの</body>直前へリロード用スクリプトを入れます。HTMLにそのタグがなければ動かず、監視対象外の静的ファイル変更でも再読込されません。
コンテナ内での開発
公式Dockerイメージとしてcosmtrek/airが示され、作業ディレクトリ、プロジェクトのバインドマウント、ポートの指定例があります。イメージを使わず、Goでairを導入するDockerfileとCompose例もREADMEにあります。ホストとコンテナのパス、生成されるtmp、ファイルイベントの伝達、アプリポートとproxy_portを分けて確認すると、環境差による誤判定を避けられます。
ライセンスと判断
GPL-3.0のため、改変版を配布する場合の条件をLICENSEで確認します。評価では、Goファイルを編集してビルドと再起動が一度だけ起きること、構文エラー後にプロセスがどうなるか、entrypointの引数が保持されること、proxyが</body>のあるHTMLだけを書き換えることをログで確認します。これらが必要な開発フローなら採用理由になります。
検証用のGoアプリに、通常のソース変更、生成ファイル変更、除外パターンに一致する変更、ビルドエラーを順に入れます。各操作でairが何回ビルドし、tmpのバイナリをどの引数で起動し、失敗後に旧プロセスをどう扱うかをログで確認します。build.entrypointへ移行した設定と旧build.binの設定を並べ、同じコマンドラインになることを確かめます。ウォッチルールではincludeとexclude_regex、delayを一つずつ変え、フロントエンド生成コマンドが不要なGoビルドを起こさないかを見ます。proxy_portの確認では</body>のあるHTMLとないHTMLを用意し、注入条件と静的ファイル変更時の挙動を分けて記録します。
airの再起動は開発体験を改善しますが、プロセスの状態を保持する機能ではありません。編集中にデータベース接続や一時ファイルが残るアプリで、再起動が重複処理やロックを生まないかを確認します。ビルド失敗時に直前のバイナリを実行し続けるのか、停止するのかをプロジェクトの設定とログで確かめます。複数の開発者が同じCompose環境を使う場合は、マウントしたファイルの所有者とイベント通知をそろえます。ライブリロードが不要なテストや本番イメージにはairを含めず、開発用依存関係として境界を明確にします。
開発者ごとに異なるair.tomlを放置すると、変更検知と起動引数の差が不具合に見えます。設定をプロジェクトへ置く場合は、Go版、air版、tmpの除外、ポートをレビュー対象に含めます。
airの検証では、再起動したアプリの状態を開発用データだけで確認します。設定変更をレビューに残し、ライブリロードの挙動を本番運用の更新手順へ流用しません。
導入前には、対象版のリリースと実行環境を記録します。入力と出力を固定した小さな試験を作り、成功だけでなく失敗時の状態も保存します。設定ファイルの既定値を確認し、変更した値を一覧にします。権限は必要な範囲に絞り、管理者操作と通常利用を分けます。ログには時刻、版、対象、結果を残します。外部サービスを使う場合は通信先と認証の境界を確認します。更新時は同じ試験を再実行し、以前の結果との差を見ます。素材にない性能や安全性を数値として補いません。READMEの機能説明と実際の動作が異なる場合は、動作を優先して原因を調べます。
編集部の結論
Goアプリをローカル開発で頻繁に再起動するチームに向いており、本番のデプロイや可用性を担保する仕組みを求める用途には向きません。最初にair.tomlの監視対象、ビルド失敗時の動作、tmpの扱い、プロキシのHTML条件を確認し、実際の編集、削除、構文エラー、生成ファイル変更で再現性を確かめます。
コミュニティノート