Aider + Ollama：ターミナルでコーディングする100% ローカル

#ターミナルでAiderを使う理由

ClineやContinueがVS Code内で動くのに対し、Aiderはターミナルでの作業を前提としています。Gitリポジトリのルートでシェルを使い続けながら、コードにアクセスできる同僚と話すようにモデルと対話します。これはコマンドラインにより近い、異なるワークフローです。普段からtmuxを使い、キーボードから手を離したくない人に好まれます。

Gitに重点を置く

承認された各変更は、Aiderが作成したメッセージとともに、独立したコミットとして記録されます。履歴は読みやすく、任意の変更を単純にgit revertで取り消すことができます。

リポジトリマップの自動作成

Aiderは、リポジトリのマップ（関数のシグネチャ、クラス、構造）を作成し、開いているファイルに加えてモデルに送信します。プロジェクト全体を読み込まなくても、モデルがコンテキストを理解できます。

使うエディタを選ばない

Aiderはディスク上のファイルを変更します。普段使っているエディタを並行して使い続けられます。Aiderはユーザーによる変更を認識し、ユーザーもAiderによる変更を確認できます。

100％ローカルで Ollama です

Ollamaに接続すると、モデルはお使いのGPU上で動作します。コードやプロンプトがそのコンピューターの外に出ることはありません。これは、プロプライエタリなコードやNDAの対象となるコードを扱う場合に大きな違いとなります。

#前提条件とインストール

必要な要素は3つです。Aider用のPython、コード用モデルを読み込んだ状態で稼働しているOllama、そしてgitリポジトリです。Aiderの機能を十分に使うにはgitリポジトリが必要です。コミットを管理するのはAiderです。

1. 01
   Ollamaを確認してください

   Ollama はデフォルトポートで受信する必要があります。ollama list を実行して、応答が正常か確認し、既にインストールされているモデルを確認してください。
2. 02
   Aiderをインストールする

   推奨されるのは、pipxまたは公式インストールスクリプトを使う方法です。Aiderを専用の環境に分離することで、Pythonの依存関係の競合を避けられます。
3. 03
   Gitリポジトリに移動してください

   バージョン管理されているプロジェクトのルートディレクトリでターミナルを開いてください。プロジェクトがまだgitで管理されていない場合は、事前にgit initを実行してください。Aiderが自身の変更をコミットするには、これが必要です。

# Via pipx (isole Aider, n'encombre pas votre Python système)
python -m pip install --user pipx
pipx install aider-chat

# Vérifier l'installation
aider --version

#Ollama向けにAiderを設定する

Aiderは、OpenAI互換エンドポイントを通じてOllamaと通信します。設定する項目は、OllamaのベースURL（環境変数）と使用するモデルの2つです。起動のたびにオプションを入力し直さずに済むよう、プロジェクトのルートディレクトリに.aider.conf.ymlファイルを置くのがすっきりした方法です。全体に適用する設定なら、ホームディレクトリに置きます。

# Indique à Aider où trouver l'API Ollama
export OLLAMA_API_BASE=http://127.0.0.1:11434

# Lancer Aider avec un modèle Ollama (préfixe ollama/)
aider --model ollama/qwen3.5:9b

設定を毎回入力し直さずに済むように、これらの設定を設定ファイルに保存してください。Aiderは、リポジトリのルートまたはホームディレクトリにある.aider.conf.ymlを自動的に読み込みます。

# Modèle principal servi par Ollama (préfixe ollama/ obligatoire)
model: ollama/devstral:24b

# Modèle léger pour les tâches annexes (messages de commit, résumés)
weak-model: ollama/qwen3.5:9b

# Auto-commit des modifications acceptées (comportement par défaut)
auto-commits: true

# Ne pas committer automatiquement les fichiers que VOUS modifiez
dirty-commits: false

- name: ollama/devstral:24b
  extra_params:
    num_ctx: 8192

#VRAM に応じてどのモデルを選ぶか

Aiderは大量のコンテキスト（追加したファイル＋repo-map）を送り、正しい形式のパッチが返されることを期待します。モデルが小さすぎると、Aiderが適用できない壊れたdiffを生成します。コンテキスト用の余裕を残しつつ、グラフィックカードに無理なく読み込める最大のコーディングモデルを選んでください。

#エンドツーエンドワークフロー

以下は、Aiderの起動からコミットまで、変更を行う際の典型的な流れです。この流れに慣れれば、ターミナルを離れることなく次々に変更を加えられます。

1. 01
   リポジトリのルートで Aider を起動してください

   Aider が開始され、設定を読み込み、repo-map を構築し、プロンプトを表示します。現在のモデルと検出されたファイルの数を示します。
2. 02
   /add で関連ファイルを追加してください

   そのタスクで変更する必要があるファイルだけを追加してください。コンテキストに含まれるファイルが少ないほど、モデルの精度を保ちやすくなります。repo-mapによって、モデルはすでにプロジェクトの残りの部分を概観できます。
3. 03
   変更内容をフランス語で説明してください

   自然言語で依頼を入力してください。例えば、「登録フォームにメールアドレスの検証を追加して」。Aiderが検討し、その後パッチを提案します。
4. 04
   提示された diff を再確認してください

   Aiderは変更を適用する前に差分を表示します。確認してください。問題があれば、「いいえ、もっと厳密な正規表現を使ってください」のように返信して、修正を求めてください。
5. 05
   Aiderにコミットを任せてください

   パッチが適用されると、Aider は変更内容を説明するメッセージ付きのコミットを自動的に作成します。Git の履歴は整理された状態に保たれ、すべての変更を追跡できます。
6. 06
   変更を続けるか、取り消す

   次の変更に進んでください。Aiderのコミットが気に入らない場合は、/undoでAiderが作成した最後のコミットを取り消せます。それ以外には手を加えません。

$ aider
Aider v0.x — model: ollama/devstral:24b
Repo-map: 42 fichiers

> /add src/auth/register.py
Added src/auth/register.py to the chat

> Ajoute la validation de l'email dans le formulaire d'inscription

[Aider propose un diff, l'applique, puis :]
Commit a1b2c3d  feat: valider le format de l'email à l'inscription

#日常的に使う主要コマンド

Aiderは、プロンプト内でスラッシュコマンドを使って操作します。少数のコマンドだけで用途の90％をカバーできます。

/add fichier

編集コンテキストに1つ以上のファイルを追加します。Aiderはこれらのファイルに書き込みます。必要最小限に留めてください。

/drop fichier

コンテキストからファイルを取り除きます。タスクを切り替えるときに、余計な情報のないコンテキストで始め直すのに役立ちます。

/architect

計画してからコードを書くモードを有効にします。モデルはまずアプローチを検討し、その後で差分を生成します。単純ではない変更に最適です。

/diff

最後のコミット以降の変更を表示し、続行する前にAiderが変更した内容を確認できます。

/undo

Aiderが作成した直前のコミットを取り消します。変更がうまくいかなかった場合に、すぐに元に戻せる安全策です。

/run commande

シェルコマンド（テスト、リンター）を実行し、その出力をチャットに戻します。これにより、Aiderは実際のエラーに基づいて修正できます。

/ask question

変更もコミットも行わずに、コードについて質問します。作業に取りかかる前に理解するためのコマンドです。

#クラウドと比べたローカルの限界

率直に言うと、8〜16GBのメモリで動くローカルモデルは、最先端のクラウドモデルには及びません。限界を知っておけば、不満を感じる事態を避け、タスクに合ったツールを選びやすくなります。

差分の形式が不正になることがある

小型モデルは時折、Aiderが適用できないパッチを生成することがあります（フォーマットエラー）。モデルサイズを拡大するか、num_ctxを増やすことで、この問題は大きく改善されます。

より短いコンテキスト

クラウドモデルは数十個のファイルを扱えます。ローカルではコンテキストを絞ってください。一度に/addで追加するファイルは少数にとどめ、すべてを読み込む代わりにrepo-mapを活用してください。

マルチファイル推論

一度に多くのファイルに影響を与えるリファクタリングは、ローカル環境の弱点です。複数の小さなタスクに分割するか、/architectに移行して構造を整えることを推奨します。

GPUに依存した速度

応答の遅延は、ご利用のGPUによって異なります。性能が控えめなGPUでは、32Bモデルの動作は遅くなります。応答の速さを優先するなら、適切に調整した7Bまたは14Bモデルのほうが、日常的には快適に使えます。

#よくある質問