Aider 使い方｜ターミナルで動かす設定とGit連携

Aiderは、ターミナルで動くOSSのAIペアプログラミングツールであり、普段のシェルにaiderコマンドを打つだけでローカルのGitリポジトリと会話しながらコードを直接編集できます。
VS CodeやCursorのようなIDE内蔵AIとは入口が違い、いつもの環境を乗り換えずにAIを足せる手軽さが、このツールの理解の起点になるでしょう。

実際、既存のNode/Pythonリポジトリで初導入したときは、最初に全ファイルを/addしてしまって応答が遅く、トークン代も跳ね上がりました。
必要な数ファイルだけに絞ると、精度も速度もすぐに落ち着きます。

Aiderの強みは、無料OSSであること、Claude・GPT・Gemini・ローカルモデルまで同じ操作感で切り替えられること、そして編集のたびにGitへ自動コミットされることにあります。
GitHubスター4万2000超の支持に加え、同一タスクでClaude Code比約4分の1のトークン消費という効率の良さもあり、導入のしやすさと実務での扱いやすさを両立した設計です。

インストールはpip、pipx、uvのいずれかで数手順、APIキーも.envに置けば以後はaiderだけで起動できます。
/undoで戻せる安心感、.aiderignoreやArchitectモードで大規模リポジトリのコストと精度を調整できる使いこなしまで含めて、難しそうという先入観を越えやすいのがAiderです。

Aiderでできること：ターミナル常駐のGitネイティブAIペアプログラミング

Aiderは、ターミナルの中で完結しながらローカルのGitリポジトリを直接編集できる、Python製の対話型AIペアプログラマーです。
IDEを開かずに普段のターミナルへaiderと打ち込むだけで始められるので、既存のエディタやショートカットを崩さずAIだけを足せます。
しかも編集結果はGitの履歴として残るため、会話の流れと変更の証跡がつながりやすいのが強みです。

ターミナルで完結する『対話型』ペアプログラミングという立ち位置

Aiderの入口が軽いのは、CLIとして設計されているからです。
ファイルを/addで渡し、日本語で依頼すると、その場で差分を作ってコミットまで進む。
エディタを乗り換えずに済むため、IDEのAI補完に慣れた状態で触っても、ワークフローの断絶がほとんどありません。
初めて動かしたときに「AIだけを足せる」と感じるのは、この馴染み方の自然さにあります。

基本の流れも明快です。
code・ask・architect・helpの4つのモードを切り替えつつ、/add、/drop、/model、/tokens、/clear、/undo、/runで対話を進めます。
編集のたびにGitへ反映されるので、どこで何を変えたかを追いやすい。
巻き戻しもできるため、試行錯誤の途中でも怖さが少ないでしょう。

Cursor（IDE型）・Claude Code（エージェント型）との違い

同じAI開発補助でも、立ち位置はかなり違います。
CursorはIDE統合の補完型で、エディタの中で提案を受けながら作業を進める体験が中心です。
Claude CodeはAIが自律的に駆動し、人はレビュー側に回るエージェント型で、任せられる範囲が広いぶん、進行の主導権はAIに寄りやすい。
Aiderはその中間で、あなたが対話で指示し、提案を承認しながら進める協調型です。
コントロールしやすさが欲しい人には、この距離感が合います。

Git連携の深さも見逃せません。
Aiderはauto-commitsがデフォルト有効で、編集ごとにConventional Commits形式で1コミットを積み上げます。
会話の断片ではなく、Git履歴そのものが作業ログになるわけです。
レビュー重視ならauto-commits: falseにもできますし、/undoで戻せるので、試した結果を安全に扱えます。
AIDER_COMMIT_LANGUAGEで日本語コミットに寄せられる点も、日々の運用では地味に効きます。

無料OSS＋モデル非依存という2つの強み

AiderはGitHubスター4万2000超の無料OSSで、本体利用に費用はかかりません。
実際に必要なのは接続するLLMのAPIトークン代だけで、使い方を覚えるほどコスト構造の素直さが見えてきます。
同一タスクでClaude Codeの約4分の1、つまり4.2分の1のトークン消費という比較もあり、コスト意識の高い個人開発者にはかなり扱いやすい選択肢です。
しかもrepo mapと.aiderignoreで渡す文脈を絞れるため、無駄なトークンを抱え込みにくい。

モデル非依存であることも、単なる対応表の広さ以上の価値があります。
Claude、GPT-5、Gemini 3 Pro、Grok-4、DeepSeekに加え、Ollama経由のローカルモデルまで、同じ操作感のまま差し替えられる。
無料だから試し始めたあとに、Claudeからローカルモデルへ切り替えても手触りが変わらなかった経験が、その設計思想の強さをはっきり示します。
ベンダーロックインを避けたいなら、ここはかなり魅力的です。

運用面では.aider.conf.ymlを軸に設定を積み上げると整理しやすくなります。
ホーム、リポジトリルート、カレントの順に読み込まれて後勝ちになるため、共通設定と案件ごとの調整を分けやすい。
約2万5000トークンを超えると精度が落ちやすいので、必要なファイルだけを渡して会話するのがAiderらしい使い方です。
身軽さと制御性、その両方を取りにいけるのがこのツールの面白さでしょう。

インストールと初期設定：pipx・uv・APIキーの通し方

Aiderの初期設定は、インストール手段を用途で分けてしまうと迷いにくいです。
いちばん手早いのは python -m pip install aider-install の2手順で入り、環境をきれいに保ちたいなら pipx install aider-chat、導入速度を優先するなら uv tool install --python python3.12 aider-chat@latest が扱いやすいでしょう。
最初に直接 pip で入れてプロジェクトの依存と衝突しかけた経験があり、後から pipx に切り替えたら隔離が効いてトラブルが消えました。
だからこそ、プロジェクトのvirtualenvを汚したくない場面では pipx が定番になります。

3つのインストール方式（pipx・uv・aider-install）の使い分け

最も簡単なのは python -m pip install aider-install を実行し、そのあと aider-install を叩く流れです。
セットアップの手数が少なく、まず動く状態まで最短で持っていけます。
対して pipx install aider-chat は、Aiderを自分専用の隔離領域に置けるのが利点で、既存プロジェクトの依存関係に触れません。
複数案件を並行して触るなら、この分離は効きます。

uv tool install --python python3.12 aider-chat@latest は、導入の速さを取りたいときに向いています。
Python 3.12 を明示して最新の aider-chat@latest を入れるので、環境を揃えやすい構成です。
更新は python -m pip install -U aider-chat で進められ、Aiderはモデル対応や不具合修正が活発なので、入れっぱなしにせず上げていく運用が合います。
ポイントは、何を優先するかを先に決めることです。

APIキーを環境変数・.envで通す

起動時に aider --model sonnet --api-key anthropic=<キー> の形で渡せば、すぐ試せます。
ただ、毎回そのまま打つ運用は長く続きませんし、シェル履歴に残るのも落ち着かない。
実際にコマンドへ直書きしてヒヤッとしたあと、.env に逃がして .gitignore 管理へ切り替えると、見通しが一気に良くなりました。
AIDER_ 接頭辞の環境変数か .env に置いておけば、起動のたびに入力しなくて済みます。

.env をプロジェクト直下に置くなら、同時に .gitignore に入れて漏洩を防ぎましょう。
ここを雑にすると、Aiderの便利さよりも秘密情報の扱いが気になります。
鍵はコマンドではなく環境側に寄せる、これが実務的です。

リポジトリに入って最初のaider起動まで

最初の一歩は、作業したいリポジトリのルートへ cd することです。
AiderはGitリポジトリを前提に動くため、まだ git init していないなら先に初期化しておく必要があります。
Gitの履歴に編集が積み上がる設計だから、ここが整っているかどうかで使い勝手が変わります。
起動後は会話しながらコードを直し、そのままコミットまで進む流れになるので、初手で土台をそろえておきましょう。

初回起動では、まず aider --model sonnet --api-key anthropic=<キー> で立ち上げれば十分です。
慣れてきたらキーは環境変数へ寄せ、必要に応じてモデル名だけ差し替える形にすると扱いやすいでしょう。
隔離はpipx、速度はuv、手軽さはaider-install。
用途を切り分けて選ぶのがおすすめです。

基本操作の流れ：ファイル追加から自然言語指示、自動コミットまで

起動後の基本操作は、編集したいファイルを /add で会話に載せ、自然言語でやりたい変更を伝えるところから始まります。
Aider はその指示を受けてコードを直接編集し、変更を即コミットするので、やり取りは「追加して、頼んで、反映される」という短い往復で回ります。
最初の数回でこの流れに乗ると、手作業で差分を追うよりも会話の延長で修正が進む感覚がつかめるでしょう。

/addでファイルを渡し、自然言語（日本語OK）で指示する

基本のサイクルは驚くほど単純です。
/add で編集対象のファイルだけをチャットに追加し、「この関数にエラーハンドリングを足して」「この処理を日本語のコメントつきで整理して」といった自然言語で依頼すると、Aider が内容を読み取り、実際にファイルを書き換えて即コミットします。
最初に数ファイルだけを渡して日本語で一言添えたとき、会話の流れのままコードが変わっていき、そのままコミットまで済む手触りは新鮮です。
手順を覚えるというより、編集相手を置き換える感覚に近いでしょう。

ただし、/add は多ければよいわけではありません。
編集に必要なファイルだけを入れるのが鉄則で、関係のないファイルまで抱え込むと、モデルは文脈を追いにくくなり、トークンの消費も増えます。
何を直したいのかがはっきりしているほど、指示も短く、反映も速くなります。
迷ったら、まずは最小限で始めてみてください。

code・ask・architect・helpの4モードの切り替え

起動時のデフォルトは code モードで、これはその名の通り、依頼に応じてAiderがコードを直接編集する設定です。
質問ではなく修正まで進めたい場面では最も自然で、普段の作業はこのまま進めれば足ります。
ただ、相談だけしたいときまで code のままだと、質問のつもりが実際にファイルを書き換えられてしまうことがあります。
そこで ask モードに切り替えると、変更せずに質問だけ投げられるため、調査や方針確認を落ち着いて進めやすくなります。

architect モードは、設計を先に固めてから編集に入るための切り替えです。
大きめの変更や複数ファイルにまたがる修正では、いきなり実装へ飛び込まず、構成を分けて考えたほうが安全になる場面があります。
help モードはAider自体の使い方を確認したいときの入口で、/chat-mode か起動フラグで4種を切り替えられます。
用途ごとにモードを分けるだけで、誤編集の不安は減るはずです。

覚えておくべき対話コマンド

日常的に効くのは、/add、/drop、/read-only、/model、/tokens、/clear、/undo、/run、/git、/ls、/help、/exit です。
/drop で不要になったファイルを外し、/read-only で参照だけに回すと、会話の対象を整理しやすくなります。
/model でモデルを変え、/tokens で使用量を見れば、重くなりすぎる前に調整できます。
/clear は履歴を切り直したいとき、/undo は直前コミットを戻したいときに頼りになります。

/run はコマンド実行結果を会話へ取り込むためのものです。
テスト結果やコマンドの出力をそのまま文脈に載せられるので、手元で確認した内容を説明し直す手間が減ります。
/git と /ls で状態を見て、/help で操作を再確認し、最後は /exit で終了する。
覚える量は多く見えても、実際によく触るのは数個です。
まずは /add と /undo を軸に回し、必要に応じて周辺コマンドを足していくと扱いやすいでしょう。

Git連携の仕組みと安全な運用：自動コミット・取り消し・コミット言語

Aiderでは編集がGit履歴にそのまま積み上がるため、何をどこまで変えたかが後から追いやすくなります。
auto-commits はデフォルトで有効で、1回の編集が1コミットになるので、作業の途中経過が会話ログのように残るのが強みです。
しかもコミットメッセージは Conventional Commits 形式で自動生成されるため、手で文言を考えなくても意味のある粒度で履歴を整理できます。

『編集＝1コミット』でGit履歴が会話ログになる

AiderはGitと一体で動くので、編集を重ねるほど履歴そのものが対話の記録になります。
auto-commits が True の状態では、コードや文章を1回直すたびに1コミットが切られ、どの提案がどこに反映されたのかを後からたどりやすい。
ふつうの手作業だと「いつ、何の意図で直したか」が曖昧になりがちですが、この方式なら変更単位が自然に小さく保たれる。
レビューする側にとっても、巨大な差分を読む負担が減るのがありがたいところです。

コミットメッセージが Conventional Commits 形式で自動生成される点も見逃せません。
feat: や fix: のような型に乗るので、履歴を流し読みしただけでも変更の種類が把握しやすくなります。
毎回メッセージを考える手間が消えるぶん、内容の確認に注意を向けられる。
積み上がる履歴がそのまま整理された作業ログになるのは、Aiderらしい設計だと言えるでしょう。

/undoでの巻き戻しと自動コミットの無効化

AIに任せた変更が的外れだったとき、/undo で直前のAiderコミットを取り消せます。
実際、余計な修正が入った場面でも一発で直前コミットごと消えて事なきを得たことがあり、そこから自動コミットへの警戒が安心に変わった。
壊れた差分を手で探して戻す必要がないので、試行錯誤の心理的な負担が小さい。
自動で切られるから怖いのではなく、すぐ戻せるから気軽に試せる、という関係になるわけです。

ただし、常に自動コミットが最適とは限りません。
レビューを挟みたいリポジトリでは auto-commits: false にして、自分でコミットを切る運用のほうが向く場面があります。
変更をまとめて確認してから記録したいチームでは、この切り替えが効いてきます。
dirty-commits と自動コミット無効化の選択肢があることで、個人の試行錯誤とチームのレビュー運用を同じ仕組みで扱えるのです。

コミットメッセージの言語とコミッター名の設定

英語のコミットメッセージがずらりと並ぶと、履歴を追うだけで少し疲れます。
そこで AIDER_COMMIT_LANGUAGE を使って日本語に切り替えると、あとから見返したときの見通しが一気によくなる。
特に日々の修正が多いプロジェクトでは、内容を母語で読めるだけで判断の速さが変わります。
履歴を「読む」作業が楽になるのは、運用上効く改善です。

さらに、コミッター名にaiderと明記する設定も既定で有効なので、人間の変更とAIの変更を区別しやすくなります。
誰がどこを触ったのかを曖昧にしない設計は、あとで責任範囲を確認したい場面で頼りになる。
日本語化とコミッター表記を合わせて整えておくと、Git履歴は単なる保存先ではなく、レビューしやすい運用基盤になります。
見返すたびに助かる仕組みです。

.aider.conf.ymlとモデル選択：Architectモードで精度を上げる

.aider.conf.ymlに設定を集約すると、毎回モデル名やフラグを打たなくても、意図した起動条件を再現できるようになります。
ホームディレクトリ、Gitリポジトリのルート、カレントの順に読み込まれ、後から読まれた設定が優先されるため、個人の好みとプロジェクト共通の標準をきれいに分けられるのが利点です。
リポジトリ直下に置けば、その案件だけのデフォルトが固定されます。

.aider.conf.ymlの置き場所と優先順位

読み込み順を押さえておくと整理しやすいです。
ホームディレクトリで自分用の初期値を持ち、Gitリポジトリのルートでチーム共通の設定を上書きし、必要ならカレントでさらに局所的に調整する流れになります。
後に読まれたものが優先されるので、上位の設定に対して下位で例外を差し込めるわけです。
毎回オプションを並べる運用は手間が積み重なりますが、設定ファイルに逃がせば起動のたびに迷いが減ります。

設定ファイルには model、auto-commits、commit-language などを書いておけます。
ここをリポジトリ単位のデフォルトとして固定しておくと、同じ作業をする人の挙動が揃い、コミット言語や自動コミットの扱いまで含めて運用の差が小さくなります。
個人の好みはホーム側、プロジェクト共通はリポジトリ側、という置き分けが素直です。
実際に一度まとめてしまうと、aider と打つだけで理想の設定で立ち上がる快適さがはっきりします。

モデルの選択と切り替え

推奨の組み合わせは、GPT-5をarchitect、安価なeditorを実装役にする形か、Claude Opusをarchitect、Sonnetをeditorにする形です。
どちらも考える側と書く側を分ける発想は同じで、重い判断は上位のモデルに寄せ、細かな差分は軽いモデルに任せる構図になります。
--auto-accept-architect を使えば段階ごとの確認を省略でき、--reasoning-effort medium は計画側の妥当な初期値です。
迷いなく始めたいなら、まずこの組み合わせから試してみてください。

Architectモードで計画役と編集役を分ける

Architectモードの効き目は、単に高性能なモデルを使うことではありません。
変更全体の計画を強い推論モデルが担い、実際の差分作成を速い編集モデルに切り分けることで、判断の粗さと実装の粗さを別々に抑えられる点にあります。
特に大きなリファクタでは、設計の整合性を見ながら細部を直す必要があるため、同じモデルに全部やらせるより事故が減ります。
実際にこの分担に切り替えると、差分の破綻が目に見えて少なくなります。

段階確認を減らしたい場面では --auto-accept-architect が効きます。
計画ごとに止まりすぎると流れが切れるので、確認の負担を減らしながら進められるのは実務向きです。
計画側の初期値として --reasoning-effort medium を置いておくと、過剰に重くも軽くもないところから始められます。
設定ファイルでこの流れを固定しておけば、毎回の起動が同じ質になり、複雑な変更でも再現しやすい運用になるでしょう。

トークンコスト最適化とトラブル対処：repo mapと.aiderignore

repo mapはAiderがリポジトリ構造を要約してモデルに渡す仕組みで、追加していないファイルの文脈まで見ながら編集できるのが利点です。
ただし既定の --map-tokens 1k は大規模リポジトリでは膨らみやすく、最初にここを絞れるかどうかで体感コストが変わります。
ノイズを減らし、会話履歴も整理すれば、編集精度はずっと安定するでしょう。

repo mapと--map-tokensでコンテキストを絞る

repo mapは、いま開いていないファイルまで含めて「このリポジトリはどういう構造か」をモデルに渡すための地図です。
だからこそ、関連ファイルが少ない作業でも全体像を踏まえた編集ができる反面、何も考えずに広い範囲を載せると地図だけでトークンを食い、本文に回る余裕が削られます。
--map-tokens 1k を基準にしておくと、まずは地図の肥大を抑えながら必要な文脈だけを残せます。

大きめのリポジトリを触っていると、請求額が想定より跳ねて驚くことがあります。
実際にビルド生成物までrepo mapに載っていたとき、編集前の段階で無駄なトークンを消費していたのが分かり、そこを切るだけでコストの見通しが立ちやすくなりました。
地図は便利ですが、広ければ広いほど良いわけではありません。

.aiderignoreでトークンを最大80%削減する

.aiderignore は .gitignore と同じ書式で置けるため、自動生成物やベンダーディレクトリをrepo mapから外すのに向いています。
ここで外れるのはあくまでAiderが見る文脈であり、gitの追跡には影響しません。
だから安全に試せますし、まずはビルド成果物、依存物、生成済みの資産をまとめて除外するのがおすすめです。

この設定が効く理由は単純で、編集の判断に要らないファイルほどモデルの注意を散らすからです。
ノイズが減れば、必要なソースコードや設定差分にトークンを回しやすくなります。
大規模リポジトリではトークンを最大80%削減できることがあり、実務では「まず疑うべき初手」になります。

コンテキスト肥大・編集失敗のトラブル対処

コンテキストが約2万5000トークンを超えると、多くのモデルは指示に従いにくくなります。
応答が急に的外れになったときは、内容そのものより、履歴とファイルの詰め込みすぎを疑うべきです。
まず /tokens で使用量を確認し、不要なファイルは /drop で外し、会話が長引いているなら /clear で履歴を切りましょう。

編集が失敗する、差分がうまく当たらない、そんな場面では追加ファイルを絞るのが近道です。
必要ならモデルも変え、いったん /clear で状態をリセットすると、さっきまで通らなかった修正が通ることがあります。
さらに /run に git diff を渡せば直近の変更をチャットに取り込めるので、何が変わったかを確認しながら手戻りを減らせます。
整理してから直す。
これが効きます。