🤖
AIコーディングツール Aiderの使いかた

2025/05/07に公開
English ver

 最初にAIエージェントのDevinや、統合開発環境のAIツールであるWindsurfやCursorなどがある中で、根強く (身の回りではN=3くらい) 使われているツールとしてAiderがあります。

この記事は、Aiderの利点や実際の使いかたを知ってもらうことで、数あるAI開発環境の選択肢の1つとして入れてもらえることを期待して作成しました。

当初、この記事自体をAiderで作成しようと試みましたが、あまりうまくいきませんでした。

そのため、音声入力した内容をAIでマークダウン形式に構造化し、そのテキストを全面的に手動で修正したものです。

 Aiderとは
 概要ポール・ゴルティエ氏が作成したAIペアプログラミングツールです。

ペアプログラミングツールとあえて表現しているのには理由があります。

AiderのDiscordチャンネルにおいて、Aiderをエージェントとして使いたいという質問やコメントが多数寄せられていますが、ポール・ゴルティエ氏は一貫して「AiderはAIペアプログラミングツールである」と回答しています。

ペアプログラミングツールであるということは、ドライバーとパートナーが存在し、パートナーは常にドライバーの行動を見守る形になります。これは、AIエージェントがタスクを進め、人間が最後にまとめてチェックする構造とは異なります。あくまでもリアルタイムに作業を見守りながら共同作業するペアプログラミングツールであるという点が重要です。

実装内容をチェックしつつ品質を高め、途中で細かく気づいた点をコメントすることで、高いコード品質を実現できます。

 DevinやWindsurfなどの他のツールとの違いDevinやWindsurfなどのエージェント志向のツールは、基本的に指示を出すとタスクが完了するまでAIが処理を続けます。

一方、Aiderは、ChatGPTのようなチャットツールと同様に、一度指示を出すとAIが一つの処理を実行の繰り返しによって開発を進めます。

この特徴には良し悪しがあります。エージェントのように大量のタスクを一度にこなせないという弱点がある一方で、処理の精度を高められるという利点があります。

筆者は、DevinもWindsurfも利用しており、それぞれの特性に応じて使い分けています。

こちらについては、どこかで現在の考えを整理した記事を書いてみたいと考えています。

 Aiderを使うメリット
 コンテキストの精密なコントロールがしやすいこれがAider最大のメリットだと考えています。

DevinやWindsurf、Claude Codeなどのツールは、コンテキストの追加には手間がかかります。ファイルを開いたり、アットマーク（@）アノテーションでインクリメンタルサーチを使って、一つ一つファイルを読み込むことは可能ですが、時間がかかります。

特に、複数のファイルをコンテキストとして使いたい場合、毎回この作業を行うか、プロンプトに内容をコピー＆ペーストする必要があり、非常に面倒です。
また、筆者が知る限り、RooCode以外では、特定のコンテキストを読み込み専用にし、特定のファイルのみを編集対象とするような、コンテキストモードの使い分けが困難です。

AI開発ツールを使っていると、意図しないファイルが勝手に編集されてしまう経験はあるかと思いますが、Aiderでは、この問題が解決できます。

 CLIツールであるため、他のツールとの連携がしやすいAiderはCLIツールであるため、シェルスクリプトと組み合わせたり、Aiderのコマンドをワンライナーで実行したりするなど、柔軟に利用できます。

この特徴を活かし、筆者はaider.vim というVimプラグインを作成して便利に使っていますが、詳細は以下の記事を参照してください。
https://zenn.dev/takets/articles/how-to-use-aider-vim

 金銭面のコストが安いこの記事を読むかたであれば、WindsurfやCursorを使っていて気がついたらLLMの利用制限を超過してしまったり、Devinであっという間にクレジット（ACU）を使い果たし、費用がかさんでしまった経験がある方もいるかもしれません。筆者もそうでした。今もそうです。

Aiderは、必要な処理にのみLLMを使用するため、コストを大幅に抑えられます。少なくとも、2～3時間で数十ドルが消えるような事態は避けられます。

Devinは、高度な処理を行うため高コストになるのは理解できますが、そうはいっても、石油王ならぬ身にとってコストの問題は重要です。

 Aider作者の使いかた
 前提使い方を説明する前提として、よく使われるAiderコマンドを整理します。

 /ask
Aiderにプロンプトで指示を送信できますが、ファイルを編集しない特殊なモードです。

作者が推奨する使い方は、まずこの/askモードで必要なコンテキストをすべてセットし、その後で編集に入るというものです。

 /add
Aiderに、コンテキストとして編集対象のファイルを追加できます。このコマンドを使うことで、意図しないファイルが編集されるのを防げます。

 /read-only
/addコマンドとは逆に、読み込み専用のコンテキストとしてファイルを追加できます。/addと使い分けることで、ファイルの誤編集を防げます。

 /architect
このコマンドは、Aiderがコードの修正方針を提案し、ユーザーはその提案に基づいて実装を進めるかを選択できます。

これは、エージェントツールが提案を行い、ユーザーが承認するかどうかを判断する機能に似ています。

本来の/architectコマンドの主な用途は、推論用LLMとコード編集用LLMを使い分けることですが、筆者は前述のような使い方をしています。多くの場合、これで問題ありません。

よりコードの精度を向上させたい場合は、/askコマンドと、実装のみを行う/codeコマンドを組み合わせる方が品質は向上します。これはポール・ゴルティエ氏が推奨するやり方です。

 概要基本的には、必要となるファイルをコンテキストとして全て読み込み、編集対象のファイルのみを/addで編集可能にします。

次に、/askコマンドで実装したい内容のコンテキストをプロンプトで登録し、最後に/codeコマンドで実装を行います。

このプロセスを繰り返します。

 なにがいいのか？必要なコンテキストのみを登録するため、意図しないコードが出力されるリスクを低減できます。

また、必要最小限の出力に留まるため、LLMのAPI利用料金の節約にも繋がります。

 筆者の使いかた
 感じた課題筆者は、ポール・ゴルティエ氏の使い方を踏襲しつつも、一部気になる点がありました。

/askコマンドでコンテキストを追加する際、その質問内容の再利用性が低いことです。

特に業務システム開発では、類似のコンテキストを毎回読み込ませる必要があり、これが非常に面倒でした。一度きりのコードを書くのであれば、ポール・ゴルティエ氏の方法で問題ないでしょう。

 計画書の作成基本的にはAider作者の推奨する開発プロセスと同様ですが、一部変更を加えています。
ポール・ゴルティエ氏のやり方との違いは、計画書をMarkdownで作成する点です。

筆者はこの計画書に、目的、必要なコンテキスト、そして実装内容をマークダウンのチェックボックス形式で詳細に記述します。

これにより、実質的に/askコマンドの内容を記述していることになり、さらにこのドキュメントを類似機能の開発時に再利用できるという利点があります。
以下は架空の業務システム開発時の計画書となります（実際はもっと細かく書いていますが、長くなるため端折っています）
# title: ユーザ情報APIの作成
### 概要
- ユーザ情報APIを作成する

### 必須のルール
- 必ず ./CONVENTION.md を参照し、ルールを守ること
  - 特にドキュメントルールのphpdoc仕様は厳守すること

### 開発のゴール
-  userController.phpの実装が完了している
-  userUseCase.phpの実装が完了している
-  ユニットテストが全件成功している

### 生成AIの学習用コンテキスト
#### UnitTest: userTest
- TDDで開発するするため、最初にテストを作成する
- ユニットテストを作成する参考ファイルは `/path/to/userControllerTest.php` です
  - use DatabaseTransactionsを使う
  - テスト用データを作成する

#### Model: 必要となるモデルクラス
/path/to/Eloquentsディレクトリ下のモデルクラスを参照する
- UserModel.php
- XxxModel.php

#### Screenshot: path/to/file
- /path/to/xxx.png
<!-- Aiderは /pasteコマンドで、画像をコンテキストに追加することができるため、適宜 -->

### Process
#### process1: 必要となるファイルを作成する

ファイル作成時、クラス・メソッド・クラスプロパティ・定数にはphpdocを記載すること
phpdocの規約は、CONVENTION.md#ドキュメントルールを参照すること

- [ ]  /path/to/UserController.phpを作成する
  - [ ]  @ref /path/to/YyyController.phpを参考にする
- [ ]  /path/to/UserUseCase.phpを作成する
  - [ ]  get()メソッドを作成する
    - [ ]  EloquentのUserModelを使う
    - [ ]  取得後、ユーザ名だけを抽出する

#### process2: フォローアップ
##### sub1: UserController.phpのリファクタリング
- [ ]  コードのリファクタリングを行う

##### sub2: コードの補正
- [ ]  コンテキスト対象のファイルのphpdocを更新する
  - [ ]  @paramに最新のメソッドの引数を反映する
  - [ ]  @returnに最新のメソッドの戻り値を反映する
- [ ]  @throwsに最新のメソッドの例外を反映する

 実行まず、計画書を/addコマンドで読み込ませ、次いで必要なコンテキストファイルを読み込み専用（read-only）で追加します。

最後に、編集対象のファイルを/addコマンドで読み込ませます。

これらの準備が整ったら、「計画書の『Process』セクションにある項目（例: process1のsub2）を実行してください」といった指示を出します。

Aiderがコードの出力を終えたら、内容を確認し、問題がなければ「マークダウンの該当タスクにチェックを入れてください」と指示することで、完了したタスクのチェックボックスが自動的に更新されます。
以下は、筆者が実際に使用している処理実行用プロンプトと、チェックボックス更新用プロンプトの例です。
# 実行
{process
以下の処理を、1番から順番に実行してください。
処理ごとに実施した内容をログとして具体的にどのような編集をした内容も出力してください

1. 確認のため、dev_plan.mdのprocess1 sub1の作業内容すべてを、表示してください
2. dev_plan.mdのprocess1 sub1を、チェックリストの上から順番に実施してください
3. すでに実装済みだった場合は、『なにもしなかった』ことを教えてください

process}

# チェックボックスの更新
/code {process
target: dev_plan.md
以下の処理を、1番から順番に実行してください。
処理ごとに実施した内容をログとして具体的にどのような編集をした内容も出力してください

1. dev_plan.mdのprocess1 sub1において、実装が完了しているものは、チェックリストをONにすることだけを実行してください。
チェックをONにする根拠を教えてください。
2. dev_plan.mdの更新だけをしてください。他のファイルの編集を禁止します。

process}

 フォローアップここまで読まれた方は、計画書に漏れがあり追加作業が必要になった場合にどう対処するのか、疑問に思われるかもしれません。

この場合、計画書の実装項目に新たなチェックボックスを追加し、「チェックされていない項目を実装してください」と指示するか、あるいは計画書の『Process』セクションの最後に『フォローアップ』という項目を設け、そこに予定外・想定外のタスクを記述し、Aiderに実行させるという方法を取っています。

 最後に紹介した方法を用いることで、筆者は満足のいくコードを生成できています。

計画書を作成するアプローチは、おそらくDevinやWindsurfといった他のツールでも応用できると思います（筆者は、計画書が必要な実装ではAIエージェントツールを使わない方針のため）。

このやり方が、皆さんの何かの参考になれば幸いです。

 参考Aider - AI Pair Programming in Your Terminal
Aider-AI/aider: aider is AI pair programming in your terminal
Aider作者が実際に使っている動画
AIコーディングツール Aiderの使いかた

最初に

Aiderとは

概要

DevinやWindsurfなどの他のツールとの違い

Aiderを使うメリット

コンテキストの精密なコントロールがしやすい

CLIツールであるため、他のツールとの連携がしやすい

金銭面のコストが安い

Aider作者の使いかた

前提

`/ask`

`/add`

`/read-only`

`/architect`

概要

なにがいいのか？

筆者の使いかた

感じた課題

計画書の作成

実行

フォローアップ

最後に

参考

Discussion
