AiderでOpusとSonnetを役割分担する設計実装術
Aider ArchitectモードでClaude Opus 4.7に設計、Sonnet 4.6に実装を任せる役割分担で品質とコストを両立する実践テクニック。
1モデル運用で行き詰まるAIコーディングの課題
AIコーディング支援ツールを日常的に使い始めると、「設計の段取りは得意だけれど細かい差分生成が雑」「逆にコード生成は速いが全体設計が浅い」と感じる場面が増えてきます。 1つのモデルにすべてを任せていると、長いコンテキストの中で計画力と実装力のバランスが崩れ、結果としてレビュー往復が増えたり、無駄な書き直しが発生したりしがちです。
そこで注目したいのが、CLIベースのAIコーディングアシスタント Aider が備える「Architectモード」という機能です。 これは1つのリクエストを「設計・分割を担当するプランナー役モデル」と「実際の差分を生成するエディター役モデル」の2段階に分け、それぞれ別のモデルを割り当てられる仕組みになっています。 本記事では、プランナー役に Claude Opus 4.7、エディター役に Claude Sonnet 4.6 を割り当てる構成を例に、CLI完結のAIコーディングを実用レベルへ引き上げる方法を解説します。
Aider Architectモードの2段階フローの仕組み
Architectモードの肝は、1回のユーザー指示を内部的に2ステップへ分解する点にあります。 第1ステップでは、プランナー役モデルがリポジトリの状況とユーザーの要望を踏まえて、「どのファイルをどう変更すべきか」を自然言語で計画します。 第2ステップでは、その計画を入力としてエディター役モデルが実際のパッチや差分を生成し、Aider がローカルファイルへ適用していきます。
シングルモデル運用と比べた利点は3つあります。 1つ目は、プランナーが俯瞰視点で動くため、無関係なファイルへの巻き込みや影響範囲の見落としが減ることです。 2つ目は、エディターが計画書を起点に局所的なdiff生成へ集中できるため、フォーマットエラーや構文崩れが起こりにくいことです。 3つ目は、推論力の高い高価なモデルを設計だけに使い、コードパッチのような定型的な処理はコスパの良いモデルに任せられるため、品質を維持したまま実行コストを抑えやすいことです。
Anthropic のラインナップでいえば、Opus 系は「複雑な推論・設計」を、Sonnet 系は「速度と品質のバランス」を強みとしています。 これを Aider Architect の2レイヤーに重ねると、両者の強みを自然な形で活かせる構図になります。
実際の現場感としては、シングルモデルで Sonnet クラスを使い続けると、リファクタの全体構想が浅くなりがちで、逆に Opus クラスだけで通すと「単純な文字列置換でも長考する」コスト感の悪さが出やすいという課題があります。 Architectモードはこの2つのトレードオフを綺麗に切り分けてくれるため、AIコーディングを「面で見る作業」と「点で見る作業」に分解する思考法を自然と促してくれる点も副次的な利点です。
Opus 4.7 と Sonnet 4.6 を割り当てる設定例
Architect 役と Editor 役のモデルは、それぞれ専用のフラグから指定できます。
ここでは Anthropic の API キーを環境変数に通したうえで、--architect で2段階モードを有効化し、--model をプランナー役、--editor-model をエディター役として読み替えます。
# Anthropic APIキーを環境変数で渡す
export ANTHROPIC_API_KEY="sk-ant-xxxxxxxxxxxxxxxx"
# Aider をArchitectモードで起動する
# プランナー役: Claude Opus 4.7
# エディター役: Claude Sonnet 4.6
aider \
--architect \
--model anthropic/claude-opus-4-7 \
--editor-model anthropic/claude-sonnet-4-6 \
src/api/users.ts src/types/user.ts
実行後にAiderのインタラクティブプロンプトが立ち上がります。 ここで「ユーザー作成APIに role フィールドを追加し、型定義とテストもまとめて更新してほしい」のように依頼を投げると、まずOpus側が変更計画を返し、続けてSonnet側がパッチを生成して該当ファイルへ適用してくれます。
設定をプロジェクトに固定したい場合は、リポジトリ直下の .aider.conf.yml に書いておくと、チーム全員で同じ役割分担を再現できます。
# .aider.conf.yml の例
architect: true
model: anthropic/claude-opus-4-7
editor-model: anthropic/claude-sonnet-4-6
# 自動コミットせず差分レビューを必須化する運用例
auto-commits: false
dirty-commits: false
auto-commits: false にしておくと、Aiderが提案した差分を一度ステージング状態で止められるため、人間によるレビューを前提にしたフローへ馴染ませやすくなります。
リポジトリマップで複数ファイル横断の変更を進める
Aider にはリポジトリマップという、対象プロジェクトのファイル構造とシンボル情報をモデルへ渡す仕組みが備わっています。 Architectモードと組み合わせると、複数ファイルにまたがる変更（API追加→型定義更新→テスト追加）を1セッションで一貫して進められます。
実用面でのコツは、/add コマンドで対象ファイルを明示的にコンテキストへ加えてから依頼することです。
リポジトリ全体を漠然と渡すと、プランナーが関係ないモジュールまで巻き込んだ計画を出しがちなので、関心のあるディレクトリ・ファイルだけに絞ると精度が上がります。
依頼プロンプトのテンプレートとしては、次の3点を入れておくと役割分担がスムーズです。
- 変更の目的（なぜやるのか）
- 影響を与えてよいファイルの範囲
- 受け入れ条件（テスト・型チェック・既存挙動の維持など）
これらを明示すると、Opus側が出す計画が「何をどこまで変えるか」で具体的になり、Sonnet側のdiff生成も無駄な提案が減っていきます。
Claude Code・Cursor Composer・Copilot Agent との使い分け
Aider Architect は万能ではなく、目的に応じて他ツールと使い分けるのが現実的です。 Claude Code は対話的なプロジェクト探索や、サブエージェント・Hooksまで含めた広範な自動化が得意で、ターミナル中心の開発フロー全体を任せたいときに強みを発揮します。 Cursor Composer は、IDEとシームレスに統合された対話編集が中心で、コードを開きながら横にAIを置きたいユーザーへ向いています。 GitHub Copilot Agent は、Issue起点でブランチ作成からPRまで一気通貫で進めたいときに便利です。
これらに対して Aider Architect が刺さるのは、「CLI完結したい」「差分レビューを必ず人間が行う前提」「計画役と実装役でモデルを分けてコスト最適化したい」というケースです。 PRの内容を厳密に管理したい現場では、Aiderの差分提示と git 連携の素直さが活きてきます。 選定基準は「どこに人間のレビューを置くか」と「IDEに張り付くかCLIで完結するか」の2軸で考えると整理しやすいです。
具体的なシーン別に整理すると、新規プロダクトの素早いプロトタイピングでは Cursor Composer や Bolt 系が向き、既存リポジトリへの安全な追加実装やリファクタでは Aider Architect が向きます。 そして、Issueベースの長時間タスクをまるごと任せたい場合は GitHub Copilot Agent が候補に入る、というすみ分けが現実的です。 チームの開発フローによっては、これらを併用するのが正解で、「PR本体は Aider Architect、レビュー指摘の細かい修正は Cursor」のような分担も十分にあり得ます。
APIキー管理とコストの実運用ポイント
運用面で押さえておきたい注意点をまとめます。
APIキーは、必ず環境変数（ANTHROPIC_API_KEY など）か direnv ・1Password CLI といったシークレット管理ツール経由で扱い、リポジトリには絶対にコミットしないようにしてください。
コスト面では、Architectモードは1リクエストごとにプランナー側とエディター側でそれぞれモデル呼び出しが走るため、シングルモデル運用より単純に呼び出し回数が増えます。
そのぶんOpusに任せる範囲を「設計・分割」へ絞り、エディター側はトークンが膨らみすぎないように /add で対象を限定する運用が効いてきます。
具体的な料金や利用上限はモデル世代ごとに改定されるため、必ず Anthropic 公式と Aider 公式のドキュメントで最新情報を確認してください。
機密コードを扱うリポジトリでは、リポジトリマップの範囲を一部ディレクトリへ限定する、外部送信が許容されるブランチ・モジュールだけで運用する、といったガードレールを社内ガイドラインへ落とし込んでおくと安全です。 コストの可視化という観点では、Aiderの実行ログから入出力トークンの内訳が確認できるので、月初に小さなテストプロジェクトで「典型的なタスク1件あたりのコスト感」を測っておくと予算化しやすくなります。 プランナー側のリクエストが膨張しすぎていないか、エディター側で同じファイルを何度も書き直していないかをログで監視することで、運用が落ち着いてくるはずです。
まとめと次のアクション
Aider Architectモードに Opus 4.7 と Sonnet 4.6 を割り当てる構成は、AIコーディングの「計画」と「実装」を別の脳に任せる発想であり、シングルモデル運用とは別物の安定感があります。
まずは小さな個人リポジトリで --architect --model anthropic/claude-opus-4-7 --editor-model anthropic/claude-sonnet-4-6 を試し、auto-commits: false で差分レビューの感覚を掴むところから始めると、本番リポジトリへの導入もスムーズです。
チームで使う場合は、.aider.conf.yml をリポジトリにコミットして役割分担を共通化しつつ、APIキーとコスト方針だけは個別管理する形がおすすめです。
慣れてきたら、リポジトリマップの絞り込みやプロンプトテンプレートを社内ナレッジへ落とし込み、「設計役Opus・実装役Sonnet」というパターンをチーム標準のひとつに育てていきましょう。 役割分担の発想自体は他のCLIエージェントへも応用が効くので、まずはAider Architectで成功体験を作り、自社の開発文化に合った形でAIコーディング運用を磨き込んでいくのがおすすめです。