生成AIを使ったバイブコーディングのツールとしてClaude CodeやCodexなどが良く使われる昨今ですが、今回はそうしたツールと少し趣が異なる Aider について、備忘も兼ねて基本的な使い方をまとめたいと思います。
また呼び出す生成AIはOCI 生成AIサービスを使います。
その際、今年始めにリリースされたOpenAI互換のAPIを使ってAiderと連携します。
ちなみに本検証で作るSampleプロダクトですが、Pygame というライブラリを使ってPythonで簡単なブロック崩しゲームを作ります。
目次
Aiderとは
Aiderの特徴は以下3点と理解しています。
① AiderはAIペアプログラミングのツール
AiderはAIとペアプログラミングをする想定で開発されているOSSのコーディングツールです。
Claude CodeやCodexは開発者と同期的にコーディングする機能に加え、AIエージェントにお任せして非同期的に実装する機能も備わっています。
一方でAiderはあくまで開発者と同期的にコーディングを進める前提で開発されているため、エージェントが非同期で自律的に実装していく機能はありません。
その代わり、AIとペアプログラミングする点を重視した機能が豊富に備わっています。
そういった方向性のため、編集内容によってはAIに依頼せず、手動でコードを書くケースも想定されたツールとなっています。
② 連携するエディタ、LLMの自由度が高い
AiderはCLI上で動作し、VimやEmacsなどIDE以外のエディタとの連携を意識した機能が提供されています（Webアプリ版もあります）。
加えて連携するLLMは任意に選択できるため、ローカルのLLMを使って情報を一切外部に出さない運用も可能です。
③ 必ずGitと連携
Aiderはファイルを編集した際に必ずGitへcommitします。
その際のコメントはLLMで自動生成されます。
Gitと必ず連携しているため、編集依頼する直前の状態に戻してやり直す、といった操作が非常に簡単です。
具体的には /undo と実行するだけです。
AIコーディングにおいては、思った実装と異なるためプロンプトを工夫して再依頼したいケースが度々あるため、非常に助かる仕様です。
以上より、次の点に魅力を感じたためAiderを試してみた次第です。
- AIを使った効率化の恩恵を受けつつ、ペアプロという形で開発者側で実装の方向性を制御して成果物の品質を一定に保つ、という考え方に興味があった
- 個人的に慣れ親しんでいるVimとの連携や、任意のLLMとの組み合わせが出来る点も魅力に感じた
- コード編集した際にGitと必ず連携するため、デグレした等の理由で元に戻したいときの手続きが簡単（
/undoと実行するだけ）
Aiderのセットアップ
uvを使ってAiderをインストールします。
インストール (Windows 11)
:: uvインストール
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
:: 仮想環境の作成
uv init pj_name -p 3.13
cd pj_name
uv venv
.venv\Scripts\activate
:: aiderインストール用パッケージを追加
uv add aider-install
:: aiderインストール
aider-install
インストール (Oracle Linux 8)
日本語で使えるよう、OSロケールを設定します。
localectl set-locale LANG=ja_JP.utf8
localectl status
Aider導入
## uvインストール
curl -LsSf https://astral.sh/uv/install.sh | sh
## 仮想環境の作成
uv init pj_name -p 3.13
cd pj_name
uv venv
source .venv/bin/activate
## aiderインストール用パッケージを追加
uv add aider-install
## aiderインストール
aider-install
これでAiderを使えるようになりました。
ただAiderを起動する前にやっておいた方が良い事前作業があるため、そちらを実施します。
Aider設定ファイル作成
プロジェクト用のディレクトリを作成して移動した後、.aider.conf.yml というAider用の設定ファイルを作ります。
vim .aider.conf.yml
YAMLファイルに記載できる設定値については以下をご参照ください。
今回の検証において、私は以下のように設定しました。
## 複数行モードを有効化
multiline: true
## ダークモードを有効化
dark-mode: true
## Aiderが認知していないモデルの利用に対するWarning表示を無効化
show-model-warnings: false
## 利用するモデル名を指定
model: openai/openai.gpt-oss-120b
## デフォルトで編集対象とするファイルを指定
file: app_spec.md
## デフォルトでRead-Onlyで参照するファイルを指定
read: CONVENTIONS.md
## "AI!" や "AI?" といったコメント付加によるAIコーディングのキックを有効化
watch-files: true
## APIベースURLを指定
openai-api-base: your_api_base_url
## APIキーを指定
openai-api-key: your_api_token
ちなみにAPIベースURLやAPIキーについては今回OCI 生成AIサービスのものを指定しますが、それら情報の入手については以下をご参照ください。
また file および read に指定している各mdファイルは後ほど作成します。
Gitリポジトリ作成
Aiderはファイル編集にあたり必ずGitと連携する必要があるため、あらかじめGitリポジトリを作成します。
git init
git config user.name "your user name"
git config user.email "your email address"
プロジェクト内容に応じて .gitignore も作成します。
vim .gitignore
# # Python
# __pycache__/
# *.py[cod]
# *.pyo
# *.pyd
# *.so
#
# # Virtual environment
# .venv/
# venv/
# env/
#
# # Environment variables
# .env
# .aider*
既存コードがある場合、あらかじめリポジトリに追加しておきます。
git add .
git commit -m "initial commit"
以上でAiderを使い始める準備が整いました。
ここから Pygame を使ったブロック崩しゲーム実装を通して、Aiderの基本的な使い方をまとめたいと思います。
Sampleの実装を通したAiderの基本的な使い方
Python仮想環境の準備
今回はゲーム実装のライブラリとして Pygame を使うので、必要なPythonパッケージを導入します。
なお作業環境は Windows 11 を想定しています。
## Python仮想環境を作成
uv init aider_sample -p 3.13
cd aider_sample
uv venv
.venv\Scripts\activate
## Pygame導入
uv add pygame
プロジェクト用のディレクトリを作成して移動します。
mkdir breakout
cd breakout
このプロジェクト用ディレクトリにおいて、先述した「Aider設定ファイル作成」と「Gitリポジトリ作成」の手順を実行します。
ブロック崩しゲームの初期実装
まずは今回作るゲームの仕様書 app_spec.md をMarkdown形式で簡単に作ります。
先述の通り .aider.conf.yml の設定でその仕様書を必ず参照させ、コード編集する際のコンテキストとして利用します。
## ゲーム概要
- ボールを板で跳ね返して積み上げられたブロックを消していく2Dゲーム
- ボールは板や壁、ブロックにあたると逆方向に跳ね返る
- 時間が経過すると共にボールは速度が増していく
- ただしボールの速度には上限を設ける
- 板で跳ね返せず、ボールが板より後ろにいってしまうとゲームオーバー
- ブロックを全て消すことが出来たらゲームクリア
## 実装方針
- ライブラリとしてpygameを利用
- 画像素材や音楽素材は使わずに実装
またコード編集にあたり守ってほしいルールを CONVENTIONS.md に記載し、こちらも同様にコンテキストとして必ず参照させます。
以下に挙げている条項を遵守すること。
- 振る舞いは変えない
- 指定ファイル以外は触らない
- 最適化や整理は行わない
- ファイル削除は禁止
- コメントアウトやTODOは残す
- 途中段階のコードは保持する
ここからAiderを使って実装していきます。
Aiderの基本となる使い方ですが、まず /ask コマンドで実装したい内容を問い合わせ、計画を立ててもらいます。
その内容で問題なければコマンドを指定せず、実装するようAiderに依頼します。
(コマンドを指定しない場合、コード編集をさせる /code コマンドを実行するのと同じ動作になります。)
ということで、まずは /ask を使って計画を立ててもらいます。
問題なさそうなので実装するよう依頼します。
実装するコードを出力した後、それらの保存先となるファイルの作成可否を聞かれます。
Yes を選択してファイル作成＆コードの保存を依頼します。
ちなみに今回はAiderから編集するファイルの提案を受けましたが、開発者側で前もって編集するファイルを指定する方法もあります。
具体的には /add コマンドでファイル名を指定すると、そのファイルに対して編集する動作となります。
このようにAiderはLLMによる編集範囲をコントロールしやすい特徴も持っています。
では作成されたゲームを起動してみます。
python main.py
以下の通り、ちゃんと遊べるシンプルなブロック崩しが出来上がりました。
追加実装
ブロック崩しの初期バージョンに対して、3通りの方法で追加実装を試します。
ask→codeによる編集
まずは先ほどと同様に /ask → 実装依頼 の流れでやってみます。
初期バージョンはブロックの色が単調だったので、色を付けるよう依頼します。
/ask ブロックをパステルカラーにして。各ブロックの色はランダムに決めて。
問題なければコマンド指定なしで実装を進めるよう依頼します。
追加実装されたものが以下になります。
ちゃんと各ブロックに色が付きました。
手動による編集（commitコマンドの活用）
続いて手動で編集する方法です。
これくらいならAIに依頼するより、手動でコード書いた方が早いな、という場面もあるかと思います。
そういったケースも想定されているのがAiderになります。
手動で編集する内容ですが、ゲームオーバーの日本語メッセージが文字化けしているため、日本語対応フォントを指定して正しく表示されるようにします。
以下では手動でコードを編集して最後に /commit コマンドを実行し、LLMが生成したメッセージと共にGitリポジトリに反映しています。
動作確認すると無事に日本語メッセージが表示されるようになりました。
コメントによる編集
最後はコードにコメントを追記してAiderに問い合わせや編集を依頼する方法です。
.aider.conf.yml に watch-files: true と設定している場合、コードに以下のコメントを追記して保存すると、Aiderが対応する動作を実行してくれます。
- コメントとして
xxxを実装する AI?と記載し保存 → xxxの実装方法についてAiderが計画を立案して提示 - コメントとして
xxxを実装する AI!と記載し保存 → xxxを実装するためAiderがファイル編集を開始
以下の例ではゲーム起動したら急にスタートしないよう、スペースキーを押したらゲーム開始する仕様変更を依頼しています。
まず スペースキーを押したらゲーム開始にする AI? と入力して実装の計画を立ててもらい、AI! と変更し実装を依頼しています。
結果、以下の通りスペースキーを押すとゲーム開始する仕様に無事変更されました。
その他Tips
基本的な使い方は以上ですが、いくつかTipsもご紹介します。
Tree-sitterを使ったリポジトリマップによるコンテキスト圧縮とarchitectモード
実装が進めば進むほどコード量が多くなり、コンテキストも増大していきます。
やがて追加実装やバグ修正する際にコンテキストが大きすぎて、編集箇所をLLMが正しく認識できなくなる事態が起き得ます。
そうした問題を防止するため、Aiderではコード全体から重要箇所のみ抽出してコンテキスト参照させる機能が備わっています。
具体的にはGitのリポジトリマップ作成によって上記を実現しています。
またリポジトリマップを作るにあたり、Tree-sitterを使った構文解析を行ってコード内の重要箇所を抽出しています。
今回のリポジトリマップは以下のようになりました。
リポジトリマップの例
multi> /map
Here are summaries of some files present in my git repository.
Do not propose changes to these files, treat them as *read-only*.
If you need to edit any of these files, ask me to *add them to the chat* first.
game\__init__.py
game\constants.py
game\game_loop.py:
⋮
│def _create_bricks() -> list[Brick]:
⋮
│def run_game() -> None:
⋮
game\objects.py:
⋮
│class Paddle:
│ """プレイヤーが操作する板"""
│
│ def __init__(self) -> None:
⋮
│ def set_direction(self, direction: int) -> None:
⋮
│ def update(self, dt: float) -> None:
⋮
│class Ball:
│ """跳ね返るボール"""
│
│ def __init__(self) -> None:
⋮
│ def update(self, dt: float) -> None:
⋮
│ def increase_speed(self, dt: float) -> None:
⋮
│ def collide_with_paddle(self, paddle: pygame.Rect) -> None:
⋮
│class Brick:
│ """ブロック（破壊可能）"""
│
│ def __init__(self, x: int, y: int, color: pygame.Color | None = None) -> None:
⋮
│ def draw(self, surface: pygame.Surface) -> None:
⋮
game\utils.py:
⋮
│def clamp_speed(vel: Vector2, max_speed: float) -> Vector2:
⋮
│def circle_rect_collision(circle_pos: pygame.math.Vector2, radius: int, rect: pygame.Rect) -> bool:
⋮
│def ball_brick_collision(ball_pos: pygame.math.Vector2, radius: int, brick_rect: pygame.Rect) -> bo
⋮
main.py:
⋮
│def main() -> None:
⋮
リポジトリマップについては特に /architect コマンドを利用する際に効果を発揮します。
/architect はコード全体を俯瞰してリファクタリングするようなケースで使います。
また今回利用したLLMは openai.gpt-oss-120b のみですが、architectモードでは以下パラメータの活用により「編集プラン策定」や「コード編集」などでモデルの使い分けが可能です。
- model: 編集の方針や計画を立てる、推論がメインのモデル
- editor-model: コード編集で利用するモデル
- weak-model: commitメッセージやチャット履歴の要約で使う安価なモデル
用途に応じて高価なモデルと安価なモデルを使い分け、コストを最適化するイメージかと思います。
チャット履歴
チャット履歴は .aider.chat.history.md に永続化されます。
セッションを終了しても、上記ファイルを参照すれば過去履歴を見直せます。
加えて、やり取りが長くなりすぎてメモリに不要なコンテキストが残っている状況では、/clear コマンドを実行してチャット履歴をリセットできます。
その他よく使うチャットコマンド
チャットコマンドの一覧は下記マニュアルをご参照ください。
頻繁に使うものとして以下が挙げられるかと思います。
- add
- architect
- ask
- clear
- commit
- diff
- drop
- read-only
- reset
以上、Aiderの基本的な使い方でした。
生成AIの助けがあると個人開発がかなり捗りますね。