サポート：開発者用のアグリーティブ CLI

#Aiderとは何か、リポジトリで何をするのか

Aiderは、コマンドラインで動作するオープンソースのプログラミングアシスタントで、ターミナル内でAIとペアプログラミングを行うツールと自ら紹介しています。Gitリポジトリ内でaiderコマンドを実行し、自然言語で変更内容を説明すると、ファイルの変更を提案し、適用したうえでコミットとして記録します。ホスト型モデル（Claude、GPT、DeepSeek）でも、OllamaやLM Studioで提供されるローカルモデルでも動作するため、プロジェクトのコードを一行もマシンの外に出さずに利用できる数少ないコードエージェントの一つです。公式リポジトリのGitHubスター数は49,000を超えています。

単なるチャットと異なる点は三つあります。まず、リポジトリのマップを保持しています。リクエストのたびに、各ファイルのクラス、関数、主要なシグネチャを含むファイル一覧をモデルに送るため、すべてを見せなくても、モデルはどこを探せばよいかが分かります。次に、Gitと統合されており、変更のたびに取り消し可能なコミットが作成されます。最後に、指定したコマンド、つまりリンターやテストを繰り返し実行し、失敗した箇所の修正を試みます。ウェブを探索したりサーバーを起動したりする自律エージェントではなく、会話で操作するコードエディタです。

#Aiderをインストールする

公式の方法で最も手順が少ないのは、aider-installパッケージを使う方法です。このパッケージは、Aiderを専用の独立したPython環境にインストールし、必要に応じて互換性のあるバージョンのPythonをダウンロードします。この方法の前提条件はPython 3.8〜3.13です。macOS、Linux、Windows向けに、uvをベースにした1行のコマンドで実行できるインストーラーもあります。従来のpipxを使う手順も引き続き機能しますが、現在のドキュメントではaider-installが推奨されています。

python -m pip install aider-install
aider-install

# Vérifier
aider --version

次に、プロジェクトのルートディレクトリに移動してください。フォルダがGitリポジトリでない場合、Aiderが作成を提案しますが、自分で初期化しておくほうがよいでしょう。以下で説明する安全策はすべてGitに依存しているためです。

#コンテキストの落とし穴を避けてOllamaに接続する

AiderのOllama向け公式ドキュメントの手順は、四つにまとめられます。変数OLLAMA_API_BASEを設定する（通常のアドレスはhttp://127.0.0.1:11434）、ollama pullでモデルをダウンロードする、サーバーを起動する、そしてモデル名の前にollama_chat/を付けてaiderを実行する、という流れです。プレフィックスには、ollama/ではなくollama_chat/を使うことが明示的に推奨されています。

export OLLAMA_API_BASE=http://127.0.0.1:11434
ollama pull devstral:24b
OLLAMA_CONTEXT_LENGTH=8192 ollama serve

# Dans un autre terminal, à la racine du projet
aider --model ollama_chat/devstral:24b

最も大きな損失につながる落とし穴は、コンテキストウィンドウです。Ollamaのデフォルトのコンテキストは2,000トークンで、コードエージェントには非常に小さいうえ、決定的な問題として、上限を超えた部分が通知なしで破棄されます。そのため、気づかないうちに、ファイルの冒頭しか受け取っていないモデルとやり取りしている可能性があります。Aiderはこの問題を軽減します。デフォルトでは、各リクエストのサイズに回答用の8,000トークンを加えた値に、Ollamaのコンテキストウィンドウを自動で設定します。固定サイズにしたい場合は、メインの設定ファイルではなく、モデル設定用のファイルを使う必要があります。

- name: ollama_chat/devstral:24b
  extra_params:
    num_ctx: 32768

コンテキストにはメモリが必要です。KVキャッシュはコンテキストウィンドウが広がるほど大きくなり、Q4ですでに約14 GBを占める240億パラメータのモデルでは、16 GBのカードに残る余裕はわずかです。コンテキストウィンドウのガイドとKVキャッシュの量子化のガイドで、おおよその規模を確認できます。

#Aiderに使うローカルモデルの選び方

Aider の性能は、それを駆動するモデルの性能に依存します。また、課題は二重です。モデルはコードを推論し、厳格な編集フォーマットを遵守する必要があります。このフォーマットに従わないモデルは、ツールが適用できない変更を生成します。Aider の公開ランキングは、6 つの言語における 225 問の Exercism 演習に基づいており、まさにこの二重の能力を測定しています。ランキングは非常に大規模なホスティングモデルが支配しており、個人用マシンで動作するモデルは、その順位は著しく低くなっています。クラウドレベルの結果を期待する前に、まずランキングを確認してください。

ローカルマシンで使うなら、Mistral AIとAll Hands AIが公開したDevstral 24Bは、妥当な出発点です。コーディングエージェント向けに設計されており、Ollamaライブラリでのサイズは14 GBで、コンテキストウィンドウは128,000トークンとされています。メモリ容量が12 GB以下のGPUでは、より小さなモデルに切り替え、形式の誤りが増えることを受け入れる必要があります。『ローカルLLMでコードを書く最適な選択』ガイドでは現在の候補を比較していますが、本ガイドでは固定のランキングは示しません。順位があまりにも速く変わるためです。

#最初の変更：プロンプトからコミットまで

1. 01
   適切なファイルを追加する

   変更するファイルを指定してaiderを実行してください。たとえば、aider src/api.py src/models.pyとします。追加したファイルがaiderの編集対象となり、リポジトリの残りの部分は、リポジトリマップを通じてaiderが把握します。
2. 02
   変更内容を具体的に説明する

   必要な内容をすべて含めて依頼してください。「GET /users/:idエンドポイントを追加して、ユーザーが存在すればそのユーザーを、存在しなければ404エラーを返すようにして。」曖昧な依頼からは、曖昧な差分が生まれます。
3. 03
   diffを再確認する

   Aiderは変更を表示し、適用します。続行する前に/diffで確認してください。変更を拒否するなら、この時点です。さらに3回依頼した後ではありません。
4. 04
   コミットを確認する

   各編集内容は、その内容を説明するメッセージとともに記録されます。結果がよくない場合は、/undoでAiderが行った最後のコミットを取り消せます。
5. 05
   小さなステップで順に進める

   次に、テスト、エッジケースへの対応、ログ記録を、一度に一つずつ依頼してください。小さなステップに分けることで、コンテキストを短く保ち、差分を読みやすくできます。

#重要なチャットコマンド

Aiderにはスラッシュで始まるコマンドが数十種類ありますが、作業にはそのうちの数個を覚えれば十分です。基本ルールとして、チャットに追加していないファイルは変更できません。ただし、リポジトリマップによって、モデルはほかのファイルが存在することを把握できます。

/add et /drop

チャットにファイルを追加したり、チャットからファイルを取り除いたりします。不要になったファイルを取り除くと、コンテキストに空きができます。これはローカルモデルでは特に重要です。

/read-only

ファイルを参照専用として追加します。モデルはそのファイルを読めますが、編集はできません。規約をまとめたファイルや、インターフェースの契約仕様に便利です。

/ask, /code, /architect

チャットモードを変更します。1つのメッセージだけに適用することも、/chat-modeで継続的に設定することもできます。

/run et /test

/run lance une commande shell et peut en verser la sortie dans le chat ; /test lance la commande de test et ajoute la sortie au chat si elle échoue, ce qui déclenche une correction.

/diff et /undo

/diff montre les changements depuis votre dernier message ; /undo annule le dernier commit s'il a été fait par Aider.

/tokens

現在のコンテキストで使われているトークン数を表示します。ローカルモデルがなぜ「忘れる」のかを理解するために、確認する習慣をつけましょう。

/map

モデルに送信されるリポジトリマップを表示します。

#チャットモード：code、ask、architect

Aiderには4つのチャットモードがあります。デフォルトのcodeモードは、ファイルを変更します。askモードは、コードについて話し合いますが、変更は一切行いません。architectモードでは2つのモデルが連携します。設計を担当するモデルが解決策を提案し、編集を担当するモデルがそれを具体的なファイル変更に落とし込みます。helpモードは、Aider自体に関する質問に答えます。「paired」という名前の中間モードは存在しません。強力なモデルと高速なモデルの組み合わせは、--modelと--editor-modelオプションで設定します。

ドキュメントで推奨されている流れは、/askと/codeを交互に使うことです。askモードで進め方を話し合ってからcodeモードに切り替えると、「go ahead」と伝えるだけで合意した計画を実行できます。これは、1つのモデルで使える、architectモードをよりスムーズにした形です。中規模のローカルモデルでは、これが最もバランスのよい方法になることが多いです。2つのモデルをメモリに読み込まずに済み、計画の主導権も保てます。

アーキテクトモードは、推論能力は高いが編集能力が低いモデルに適しています。1回の代わりに2回のリクエストが発生するため、コードモードが定期的に無効なdiffを生成する場合にのみ有効にしてください。

#Git：作業を守るセーフティネット

アイダーはGitを利用して、どのミスも元に戻せるようにしています。編集のたびに、差分と会話をもとに補助モデル（weak model）が生成した説明的なメッセージを付けて変更をコミットします。メッセージはConventional Commitsの形式に沿っています。未コミットの変更があるファイルを編集する前には、まず既存の変更をコミットするため、ご自身の作業とAIの作業は履歴上で分けて記録されます。アイダーが作成したコミットには、作成者名に「(aider)」が付くので、後から見つけられます。

その結果、小さなコミットが多数作られます。推奨される方法は、専用ブランチでAiderに作業させ、変更内容を確認したうえで、マージ前にコミットをスカッシュしてまとめることです。知っておきたいオプションは2つあります。--no-auto-commits は自動コミットを無効にし、--git-commit-verify はpre-commitフックを再び有効にします。Aiderはデフォルトでは --no-verify を使ってこれらのフックを回避します。チームがこれらのフックを頼りにしている場合、このオプションは大きな違いをもたらします。

git switch -c ai/endpoint-users
aider src/api.py
# ... relire, tester, puis :
git rebase -i main

#作業のループに組み込んでテストを実行する

この設定により、Aiderはコードを生成するだけのツールから、自ら修正するツールになります。--test-cmdと--auto-testを使うと、変更のたびにテストスイートを実行します。コマンドがゼロ以外の終了コードを返した場合は、その出力を読み取り、修正を試みます。リンターも--lint-cmdで同じ仕組みを使えます。また、Aiderはデフォルトで、編集するファイルに対してlintを実行します。

aider --test-cmd "pytest -x -q" --auto-test --lint-cmd "ruff check"

注意点は2つあります。テストコマンドは短時間で完了する必要があります。ローカルモデルでは、各サイクルですでに生成に数十秒かかるためです。また、エラーを表示し、ゼロ以外の終了コードを返す必要があります。そうしないと、Aiderはすべて正常だと判断してしまいます。

#ローカルモデルでうまくいかないことと、その回避方法

編集フォーマットエラー

モデルが返した変更をツールが適用できません。より大きなモデルに切り替えるか、architectモードを試してください。Aiderのドキュメントには、こうしたエラー専用のトラブルシューティングページがあります。

コンテキストの忘却

症状：追加したばかりのファイルをモデルが無視する。考えられる原因：コンテキストウィンドウが小さすぎるか、コンテキストがいっぱいになっている。対処：/tokensで確認し、/dropで不要なファイルをコンテキストから外してから、コンテキストウィンドウを大きくする。

ファイルが長すぎる

数千行に及ぶファイルは、ローカルモデルのコンテキスト容量を使い切ってしまいます。ファイルを分割するか、特定の関数だけを修正するよう依頼してください。

曖昧なリクエスト

「このコードを改善して」という依頼では、予測できない差分が生じます。ファイル、関数、期待する動作を明示してください。

トークン制限エラー

Aiderは、モデルが限界を超えると通知し、変更をより小さくするよう依頼する、ファイルを分割する、モデルを変更するといった対処を提案します。

#Aider とエディタ内のエージェント、どちらを選ぶか

Aiderは、ターミナルで作業し、Gitの履歴をきれいに保ちたい方に向いています。VS Codeで作業を続けたい場合は、Clineで各ステップを確認しながら同等の体験が得られます。より自律的なターミナルエージェントを求める場合は、OpenCodeも選択肢です。選択の基準は、どれも同じであるモデルの品質ではなく、どこで差分を確認したいかです。

• Aider + Ollama : ターミナル内の完全なワークフロー
• コード作成に最適なローカルLLM
• コンテキストウィンドウを理解する
• Cline + Ollama による VS Code 内での利用
• ターミナルで使うOpenCode + Ollama
• コミット前にローカルLLMでコードをレビューする

• 出典：Ollama向けのAiderドキュメント
• 出典：Aiderのチャットモード
• 出典：AiderのGit統合
• 出典：Aiderでのlintとテスト
• 出典：Ollama ライブラリの Devstral