Claude APIでAiderを無制限に使う

Aiderは、既存のgitリポジトリ上で動作するターミナルベースのAIペアプログラミングツールです。1つのモデルにすべてを任せるのではなく、メインのコーディングモデル、変更を適用するeditor model、設計や方針を考えるarchitect modelのように、役割ごとにモデルを分ける独特の構成を取ります。1回のリファクタリングでも、Aiderは変更案を生成し、editor modelでファイルへ適用し、gitへcommitし、repo mapを更新するため、複数のAPIコールが発生します。このmulti-modelかつmulti-callな使い方は、従量課金よりも定額の無制限APIアクセスと非常に相性がよく、claude api 料金を気にせず反復できる点が大きなメリットです。

AiderのMulti-Callアーキテクチャとトークン消費パターン

Aiderは、ユーザーの依頼をそのまま1回APIに送って、1つの回答を返すだけのツールではありません。各インタラクションでは、まずmain modelが編集指示を生成し、editor modelがそれを解析して実際のファイルに適用します。さらにarchitect modeを有効にしている場合は、その前段階として別モデルによる設計・計画ステップが入ります。加えてAiderはrepository map、つまりコードベース全体の構造を圧縮したコンテキスト情報を保持し、それを各リクエストに含めます。これにより、モデルは明示的にチャットへ追加されていないファイルについても、プロジェクト全体の構成、class、function、import関係をある程度把握できます。

repo mapだけでも、プロジェクトの規模によって10,000〜30,000 tokensを消費することがあります。そして重要なのは、これが単発ではなく、ほぼすべてのリクエストに付随するという点です。そこに、チャットへ明示的に追加したファイル本文、これまでの会話履歴、モデルの応答が加わるため、Aiderでの典型的な1回のやり取りは50,000〜100,000 tokens程度になることも珍しくありません。5〜6往復のリファクタリングセッションなら、合計で50万tokensに到達するのは簡単です。従量課金のClaude APIでは、このトークン量がそのままコスト不安につながります。

architect modeを使うと、1回のやり取りあたりのAPIコール数は実質的に倍になります。まずarchitect modelが高レベルの変更方針を立て、その後main modelが具体的なdiffや編集内容として実装します。複雑な設計変更、責務分離、複数ファイルにまたがるリファクタリングでは結果が安定しやすくなりますが、API使用量は文字通り増えます。従量課金では、料金を抑えるためにarchitect modeをオフにするユーザーも多いでしょう。一方でAI Prime Tech Unlimitedのようなclaude 無制限の環境では、非自明な作業では常時有効にしておくのが自然です。claude api 購入を検討する際も、単価だけでなく、このような実運用での反復回数と複数コール前提のワークフローを考えることが重要です。

ネイティブAnthropic経路で接続する

Aiderは、anthropic/ というmodel prefixを使ってAnthropicモデルをネイティブに扱えます。カスタムbase URLを使う場合は、ANTHROPIC_API_BASE environment variableに https://claudeapikey.dev を設定します。このとき /v1 は付けません。Anthropic SDK側が内部でpathを組み立てるため、root hostだけを指定するのが正しい形式です。ANTHROPIC_API_KEYには、AI Prime Tech Unlimitedで発行したclaude api キーを設定します。claude code api キー設定に慣れている開発者なら、同じようにenv varへキーを入れてCLIから参照させるイメージで理解できます。

Aiderの起動時は、model flagを使って aider --model anthropic/claude-sonnet-4-5 のように指定します。anthropic/ prefixは、AiderにAnthropic SDK経路を使うよう指示します。この経路ではANTHROPIC_API_BASEとANTHROPIC_API_KEYが読み込まれます。注意点として、Aiderには --anthropic-api-base というcommand-line flagはありません。base URLはenvironment variableで指定するか、--set-env flagを使って aider --set-env ANTHROPIC_API_BASE={SITE} --model anthropic/claude-sonnet-4-5 のようにinlineで設定します。

このネイティブAnthropic経路では、streaming、tool use、thinking blocksを含むAnthropic Messages APIの機能をより自然に利用できます。ClaudeモデルをAiderで使う場合、この経路が推奨されます。理由は、Aiderのedit format parsingがAnthropicのresponse structureに最適化されているためです。editor modelやweak modelも同じ経路でClaude系モデルに設定できます。特に複数ファイルの修正や構造化された編集を頻繁に行う場合、翻訳レイヤーを挟まないネイティブ経路のほうが予期しないformat崩れを避けやすくなります。

OpenAI互換経路で接続する

別の選択肢として、OpenAI-compatible pathを使うこともできます。この場合はOPENAI_API_BASEに https://claudeapikey.dev/v1 を設定します。Anthropic経路とは違い、ここでは /v1 suffixが必要です。OPENAI_API_KEYには同じくunlimited keyを設定し、起動時は aider --model openai/claude-sonnet-4-5 のように指定します。openai/ prefixを付けることで、AiderはLiteLLMのOpenAI handler経由でリクエストを送ります。

OpenAI互換経路は、基本的なチャットや編集では十分に動作します。ただし、Anthropic固有の機能を使う場面では制約が出ることがあります。Aiderは内部でLiteLLMを利用し、providerごとのformat変換を行います。このtranslation layerは多くのケースを正しく処理しますが、tool calling、structured edits、複雑なdiff出力のような場面では、ネイティブAnthropic経路のほうが互換性が高くなります。問題が起きたときの切り分けもしやすいため、Claudeを主力モデルとして使うならanthropic/ prefixを第一候補にするのがおすすめです。

経路を混在させることもできます。たとえばmain modelはAnthropic経路のClaudeにし、weak modelだけ別providerにする、といった構成です。重い推論や設計にはClaudeを使い、commit message生成のような軽いタスクには安価なモデルを使う運用は、従量課金では合理的です。しかしclaude 無制限の定額環境では、コスト削減のためにモデルを分ける必要性はかなり薄れます。シンプルにすべてClaudeへ寄せることで、出力品質、formatの一貫性、運用のわかりやすさを優先できます。

Architect Modeとモデル分離

Aiderの /architect commandを使うと、2段階のワークフローが有効になります。まずarchitect modelが変更方針を立て、その後editor modelまたはmain modelが具体的な編集として実装します。計画品質を最大化したい場合は、--architect anthropic/claude-opus-4-6 のように、より強いモデルをarchitectに割り当てます。editor modelは正しいformatのdiffを作る機械的な作業を担当するため、速度重視のモデルを選ぶこともできます。

weak-model settingは、軽量なタスクをどのモデルに任せるかを制御します。具体的には、commit messageの生成、変更内容の要約、その他の非クリティカルな処理です。設定例は --weak-model anthropic/claude-haiku-4-5 です。従量課金のClaude APIでは、weak modelを使うことで高価なモデルへの小さなリクエストを減らし、かなりのコストを節約できます。一方でAI Prime Tech Unlimitedのような無制限プランでは、節約対象は料金ではなく主にlatencyです。Haikuは軽いタスクへの応答が速いため、セッション全体の体感速度を改善できます。

無制限環境でのAider構成例としては、--model anthropic/claude-sonnet-4-5 をmain coding、--architect anthropic/claude-opus-4-6 をplanning、--weak-model anthropic/claude-haiku-4-5 をcommits and summariesに割り当てる形が考えられます。これにより、意思決定が重要な箇所では強いモデルを使い、単純な作業では高速なモデルを使う、というバランスが取れます。claude api 料金を都度気にする必要がないため、品質優先のモデル選択がしやすくなります。唯一のトレードオフは、Opusを使ったarchitect stepでは応答待ち時間が長くなる可能性がある点です。

Repository MapとCONVENTIONS.md

Aiderはrepository mapを自動生成します。これは、リポジトリのfile structure、class hierarchy、function signatureなどを圧縮したビューで、各API requestに含まれます。モデルはこの情報によって、明示的に見せられていないコードの存在を把握し、既存functionの呼び出し、適切なimportの提案、プロジェクト全体のstyleに沿った変更を行いやすくなります。Aiderが単なるチャット型コード生成よりも実リポジトリで強い理由の1つが、このrepo mapによる文脈補完です。

repo mapのサイズはプロジェクト規模に比例します。小さなプロジェクト、たとえば50 files程度なら5,000 tokens前後で済むかもしれません。一方で500 filesを超える大きなmonorepoでは、30,000 tokensに達することもあります。しかもこれは各requestに含まれるため、1回ごとのbaseline token costとして効いてきます。従量課金ではrepo mapの大きさを気にして絞りたくなる場面がありますが、unlimitedではそこを気にする必要がありません。Aiderが必要とする詳細度でrepo mapを保持させることで、より文脈を理解した提案を受けやすくなります。

CONVENTIONS.mdは、Aiderにおけるproject-level instructionsのような役割を持ちます。リポジトリrootに配置すると、その内容がsystem promptへ含まれます。ここにはcoding standards、naming conventions、preferred patterns、testing policy、framework固有のルール、チーム内の設計方針などを書けます。repo mapと同じく、CONVENTIONS.mdの内容も各requestのtoken数を増やします。claude api 購入後に従量課金で使う場合は文字数を削りたくなるかもしれませんが、定額のclaude 無制限環境では、むしろ十分に詳しい規約を書いてモデルの迷いを減らすほうが実用的です。

Git連携とAuto-Commit

Aiderは、各変更をgitへ自動commitできます。commit messageはweak modelによって生成され、AI支援による変更がわかりやすい履歴として残ります。この履歴は後からreviewしたり、cherry-pickしたり、個別にrevertしたりできます。auto-commit機能を使うには、working directoryがgit repositoryであり、通常は未commitの変更がない状態である必要があります。必要に応じて --dirty を使うと、この制約を上書きできます。

各commit messageの生成は、weak modelへの個別のAPI callとして実行されます。小さな変更を何度も行うセッションでは、このような軽量callも積み上がります。従量課金では、細かくcommitするほど余計なコストが気になるかもしれません。しかし無制限環境では、auto-commitを最大頻度で使っても追加料金を心配する必要がありません。変更ごとにcommitしておけば、最も粒度の細かい履歴を残せます。後からsquashすることはできますが、大きな1つのcommitを後から完全に分解するのは困難です。

/undo を使うと、直前の変更とそのcommitをrevertし、依頼内容を言い換えて再試行できます。unlimitedでは、このundo-retry loopに追加コストの心理的負担がありません。変更を試し、結果を確認し、期待と違えばundoし、指示を調整して再度試す。この反復型の開発フローはAiderの得意分野であり、定額APIアクセスと非常に相性が良いです。claude api 料金を気にして試行回数を減らすより、納得できるまで短いサイクルで改善するほうが、最終的なコード品質は上がりやすくなります。

Aider設定のトラブルシューティング

最もよくあるミスは、base URLの形式を経路ごとに取り違えることです。Anthropic経路、つまりanthropic/ prefixを使う場合、ANTHROPIC_API_BASEは /v1 を付けないroot hostでなければなりません。一方、OpenAI経路、つまりopenai/ prefixを使う場合、OPENAI_API_BASEには /v1 を含める必要があります。接続エラー、404、endpoint not foundのような問題が出たら、まずこのbase URL形式を確認してください。

Aiderが model not found エラーを出す場合は、model stringに正しいprefixが含まれているか確認します。Anthropic経路なら anthropic/claude-sonnet-4-5、OpenAI経路なら openai/claude-sonnet-4-5 のように指定します。prefixはLiteLLMにどのSDKまたはhandlerを使うかを伝える役割を持ち、slash以降のmodel IDはgatewayが提供しているモデル名と一致している必要があります。claude api キーが正しくても、prefixやmodel IDが違うと認証ではなくモデル解決で失敗します。

streaming error、partial response、途中で切れた出力などが出る場合は、proxyやfirewallがServer-Sent Eventsに干渉している可能性があります。Aiderはデフォルトでresponseをstreamingします。企業ネットワークや厳しいproxy配下にいる場合は、--no-stream を試してstreamingを無効化し、synchronous requestに切り替えてください。体感latencyは少し増えますが、streaming関連の接続問題を回避できることがあります。claude code api キー設定やenv varが正しいのに不安定な場合は、network layerを疑うのが近道です。

# ネイティブAnthropic経路（推奨）
export ANTHROPIC_API_BASE="https://claudeapikey.dev"
export ANTHROPIC_API_KEY="<your AI Prime Tech Unlimited key>"
aider --model anthropic/claude-sonnet-4-5 \
      --architect anthropic/claude-opus-4-6 \
      --weak-model anthropic/claude-haiku-4-5

# OpenAI互換経路（代替）
# export OPENAI_API_BASE="https://claudeapikey.dev/v1"
# export OPENAI_API_KEY="<your key>"
# aider --model openai/claude-sonnet-4-5

# または --set-env でinline指定:
# aider --set-env ANTHROPIC_API_BASE=https://claudeapikey.dev \
#       --model anthropic/claude-sonnet-4-5

FAQ

Aiderには --anthropic-api-base command-line flagがありますか？
いいえ。AiderはAnthropicのbase URLを ANTHROPIC_API_BASE environment variableから読み込みます。inlineで設定するなら --set-env ANTHROPIC_API_BASE=https://claudeapikey.dev を使い、継続的に使うならshell profileにexportしておくのがおすすめです。

AiderでClaudeモデルを使う場合、anthropic/ と openai/ のどちらのprefixを使うべきですか？
Claudeを使うなら、基本的にはネイティブAnthropic SDK経路である anthropic/ prefixを推奨します。Claudeのtool calling、edit format、streamingとの互換性が高いためです。openai/ prefixでも動作しますが、translation layerが入るため、複雑な編集ではformat issueが起きることがあります。

repo mapとは何ですか？トークン使用量にどう影響しますか？
repo mapは、コードベース構造を圧縮して表現したコンテキストで、各requestに含まれます。プロジェクト規模に応じて1回あたり5,000〜30,000 tokens程度が追加されます。unlimitedではこのoverheadも定額内に収まるため、最良の結果を得るために詳細なまま使うのが実用的です。

無制限プランならarchitect modeを追加コストなしで使えますか？
はい。architect modeはplanとimplementの2段階になるため、1回のやり取りあたりのAPI callとtoken消費が増えます。無制限プランではその利用もカバーされます。非自明なリファクタリングでは、計画ステップによる品質向上のために有効化しておくのがおすすめです。

Aiderがcommit messageごとに別API callを行うのはなぜですか？
Aiderは各auto-commitに対して、weak modelで説明的なcommit messageを生成します。これは軽量なcallであり、unlimitedでは追加料金を気にする必要がありません。その結果、AI支援による変更を追跡しやすい、整理されたgit historyを残せます。