半年前まで、私のコーディング用CLIはClaude Codeの一択でした。
いまはその隣に、Alibaba公式のQwen Code CLIを常駐させています。全部を置き換えたわけではありません。ただ、日次で回している作業のうち2種類が、あちらに移りました。
本記事は自宅の RTX 4070 でローカル Qwen 3.6 を動かしながらQwen Code CLIとClaude Codeを機能マトリクスで比較した内容の再構成です。実測ラボの新規数字は入っていません。根拠は、私が書いた Zenn Book「RTX 4070でQwen 35Bを2.8倍速くする」第10章の Qwen Code 解説と、QwenLM 公式ドキュメント、Anthropic Claude Code 公式ドキュメント から拾えるものだけで組んでいます。
私が過去に書いた Qwen 35B コーディングエージェント / 4070標準7問 / Qwen3 Coder+gpt-oss / Claude Code Max 8ヶ月コスト分解 / Claude Code・Cursor・Codex 3ツール使い分け とは別軸の記事です。Qwen3 Coderは Alibaba のコーディング特化モデル、Qwen Code CLIは Alibaba のコーディング特化CLIツール。名前は似ていますが、片方はモデル、もう片方は道具です。
Qwen Code CLIとは何か、そして何ではないか
Qwen Code CLIは Alibaba がオープンソースで公開しているコーディング特化のCLIエージェントです。Apache-2.0 ライセンスで、リポジトリは QwenLM/qwen-code。
CLIとしての位置付けはClaude CodeやGoogle Gemini CLI、OpenAI Codex CLIと同じ列です。ヘッドレスモード、承認モード、サンドボックス、MCP、サブエージェント、IDE統合を全部内包した「1本で自走まで面倒を見る」タイプのツール。
| 項目 | 内容 |
|---|---|
| 開発元 | Alibaba (QwenLM) |
| ライセンス | Apache-2.0 |
| 接続先 | Qwen 3 Coder(公式ホスト) / OpenAI互換エンドポイント |
| ローカル接続 |
llama-server などのOpenAI互換サーバへ |
| 課金 | OSS本体は無料、公式ホスト側の無料枠は2026-04-15 で廃止 |
| 公式ドキュメント | https://qwenlm.github.io/qwen-code-docs/ |
Qwen Code CLI 自体は特定のモデルに縛られない設計です。Alibaba のホスト経由で Qwen 3 Coder を叩いてもいいし、自宅のGPUで動かした Qwen 3.5 / 3.6 の llama-server にOpenAI互換で繋いでもいい。私は後者を採っています。ローカルなら何回叩いても無料です。
Qwen Code CLI と Qwen3 Coder は別物です。前者は道具、後者はモデル。混同されがちですが、CLI側は他モデル(gpt-oss、Qwen 3.5、Qwen 3.6など)を裏に据えられます。
「Claudeの隣」というのは物理配置ではなく担当配置の話
私の作業画面ではターミナルを2枚並べていて、左が Claude Code、右が Qwen Code。同じリポジトリで、同じディレクトリで、両方に見せています。
同じ画面に並べたのは、比較記事を書くためではありません。片方が向く仕事と、もう片方が向く仕事が、たぶん違うだろうと予感していたからです。置いてみて、実際そうでした。
日次で回している作業のなかで、Qwen Code CLIに固定で振り分けたのは以下の2種類です。
置き換わった仕事1: 一発生成のスケルトン作り
たとえば「hello.py を作って、Hello from Qwen Code と表示するだけ」のような、要件が1行で言い切れるスケルトン。Zenn Book 第10章では、この用途に qwen -p (ヘッドレス実行) を使うのが Qwen Code の第一手として紹介されています。
qwen -p "hello.pyを作って。Hello from Qwen Codeと表示するだけ"
これを Claude Code に振っていた頃は、対話画面が開き、Plan を確認するためのやり取りが挟まり、たまに周辺ファイルまで見に行ってから編集に入っていました。丁寧ではあるのですが、要件が1行のときには丁寧すぎる。
Qwen Code CLI の -p は対話画面を開かず1回だけ実行して結果を返します。標準入力からも受けます。
cat spec.md | qwen -p "この仕様でテストを書いて"
「1発叩いて出力を受け取ってスクリプトで拾う」というunix的な使い方に、Claude Code よりも寄せて作ってある印象です。--output-format json や --output-format stream-json を指定すれば、結果を機械的にパースできます。
| 項目 | Book第10章から |
|---|---|
| ヘッドレス実行 |
qwen -p "…" または --prompt
|
| 標準入力 |
cat spec.md | qwen -p "…" の形式 |
| 出力形式 |
text(既定) / json / stream-json
|
| 再試行 |
QWEN_CODE_UNATTENDED_RETRY=1 で指数バックオフ |
cron から回してもいいですし、make から呼び出してもいい。「対話で相手を選ぶまでもない、単発の生成」を Qwen Code CLI に集中させました。
置き換わった仕事2: Auto-Editモードでのファイル書き換えループ
もう1種類は、ローカル Qwen 3.6 に承認モードを緩めて任せる、書き換えのループです。
Qwen Code CLI の承認モードは、公式ドキュメントで現在5段階が用意されています。Book第10章では執筆時点の4段階(Plan / Default / Auto-Edit / YOLO)で説明していますが、公式では Auto Mode | Qwen Code Docs が挟まって5段階に増えています。
| モード | 挙動 |
|---|---|
| Plan | 読み取りと計画のみ、書き込みなし |
| Ask Permissions(旧Default) | 操作のたびに人が承認 |
| Auto-Edit | ファイル編集は自動、それ以外は確認 |
| Auto | LLM分類器が「安全」と見た操作を通す。Auto-EditとYOLOの中間 |
| YOLO | 全部自動承認 |
Book第10章で私が推したのはAuto-Editでした。理由は単純で、ローカルの35B級モデルの判断にシェル実行まで委ねるのは、いまの賢さでは早いと感じているからです。書き込みは許すが、任意コマンド実行は握らせない。第8章の claw-code で採った方針(読み書きは許すが任意実行はさせない)と、同じ落としどころです。
この線引きの前提に立てば、複数ファイルにまたがるフォーマット整形、rename、テスト雛形の追加、コメント整理といった書き換えのループが、Qwen Code CLIにきれいに乗ります。Claude Code の Plan Mode を使うほどの計画性はいらない仕事です。ローカルモデルに、書き込みだけ許した状態で30分放っておく。ちょうどよい省エネです。
Claude Code側に残した仕事は、なぜ残ったのか
私は Claude Code を捨てていません。むしろ「重い判断が要る仕事」は全部 Claude Code に集めた結果、住み分けが進みました。
残した仕事はざっとこんな並びです。
- 設計判断が絡む実装: 「このモジュール、責務が2つ混じっているように見えるので切り出し方を提案してください」型
- 横断リファクタ: リポジトリ全体を読み解いた上での提案が必要な作業
- エージェント指揮: サブエージェントを走らせて、その結果を統合するようなオーケストレーション
-
セキュリティレビュー: 依存関係のCVE検討、シークレット漏洩の疑いの精査、
.envの設計相談 - ドキュメンテーション: 章立てから練り直す長文の技術記事、Book の下書き
Claude Code は 2026-09時点で60本超のビルトインスラッシュコマンドとSkills統合、Sub-agents、Hooksを持っています。手数の厚さで測ると Qwen Code CLI と Claude Code はまだ差があります。逆に言えば、この差を必要としない仕事なら、Qwen Code CLI で足りるということでもあります。
機能マトリクスで並べたときの見え方
Book第10章と公式ドキュメント2種を突き合わせて作った、2026-09時点の機能マトリクスです。
| 観点 | Qwen Code CLI | Claude Code |
|---|---|---|
| 接続先 | Qwen 3 Coder / OpenAI互換 | Anthropic API / Bedrock / Vertex |
| ローカルモデル | OpenAI互換で llama-server 等に接続可 | 直接接続なし |
| 承認モード | 5段階(Plan / Default / Auto-Edit / Auto / YOLO) | Default / Auto-Accept Edits / Plan / Autoの4段階系 |
| ヘッドレス |
-p / --prompt / stdin |
claude -p "…" あり |
| 出力形式 | text / json / stream-json | text / json / stream-json |
| MCP | 対応 | 対応 |
| Sub-agents | 対応(SubAgents / Fork) | 対応(Task tool) |
| カスタムコマンド | Skills | Slash Command + Skills |
| ライセンス | Apache-2.0 | プロプライエタリ(API課金) |
| 課金 | OSS本体無料、ホスト従量 | プランごとの月額 or API従量 |
| IDE統合 | VS Code Companion | VS Code / JetBrains |
私が Qwen Code CLI に移した2種類の仕事は、この表の左半分だけで完結する仕事でした。ローカル接続、ヘッドレス、Auto-Editの3枚があれば足りる用途です。逆に Claude Code に残っている仕事は、右半分(Anthropic モデルの推論力 + サブエージェント連携 + ビルトインコマンド群)を必要とする仕事です。
「置き換わらなかった」仕事たち
Qwen Code CLI に振ってみて、これは無理だなと思って戻した仕事もあります。
文脈が重い
Zenn Book 第10章の末尾に書いたのですが、Qwen Code CLI はシステムプロンプトとツール定義だけで、最初の一発で約19,000トークンを使います。あいさつ代わりに 19,000 トークン。名乗るだけで一仕事です。だから llama-server を -c 32768 で起動するのが最低ラインでした。
Claude Code は Anthropic 側の Prompt Caching やコンテキスト圧縮の実装が入っている分、この重さを意識せずに済みます。Qwen Code CLI の場合、KVキャッシュの量子化(私は -ctv q4_0 -ctk q4_0 にしています)や、llama-server 側の --cache-reuse の使い方が、実用性能に効いてきます。
高度な推論を分割して回すループ
「まずコードベースを読み込んで、影響範囲をマッピングし、その上で提案を返す」型の作業は、ローカル35Bモデルより Anthropic の Opus / Sonnet に振った方が、結果的に速く終わります。ローカルの35Bは1周が長い上に、判断がぶれることがある。Qwen Code CLI 自体の設計は悪くないので、モデル側を Qwen 3 Coder のホスト経由に切り替えれば話は変わるはずですが、ローカル固定で回している以上は、この用途は Claude Code の担当にしました。
エージェント指揮
Sub-agents を Qwen Code CLI にもたせて、複数エージェントの結果を統合させる、といった指揮系統は、まだ組んでいません。理屈上は可能ですが、モデル側の指示追従精度に依存するので、Opus クラスのモデルを内部で使うのが現状は無難だと判断しました。
Auto-Editを選ぶときの落とし穴
ここまでの整理は Book 第10章の焼き直しに近いのですが、実際に「隣に置いて」使ってみて追加で気づいたことも書いておきます。
Auto-Edit は便利ですが、Qwen Code CLI 側の「ワークスペース」の解釈が結構ゆるいです。ホームディレクトリで起動して Auto-Edit にすると、意図せず親ディレクトリを書き換えられるリスクがあります。私は必ずプロジェクトのルートに cd してから qwen を叩く運用にしました。あるいは、--sandbox を有効化して仮想ファイルシステム越しに動かすのも手です。
もう一点。Auto-Edit は Shift+Tab (Windows は Tab) で切り替えられます。cycle 順は plan → default → auto-edit → auto → yolo → plan。手癖で Shift+Tab を連打すると YOLO まで一気に行ってしまうので、モード表示(⏵⏵ accept edits on)は常に画面下端で確認するようにしています。
いまのところの結論
Qwen Code CLI と Claude Code は、担当の違うツールです。
- 単発の生成、Auto-Edit で任せる書き換えループ、ローカル運用 → Qwen Code CLI
- 設計判断、横断リファクタ、エージェント指揮、セキュリティレビュー、長文執筆 → Claude Code
同じ画面に並べて2ヶ月ほど使ってみて、この住み分けが安定してきました。単発の生成と Auto-Edit の書き換えループを2本抜き出して、そこだけ Qwen Code CLI に渡す。それが私の落としどころです。
ローカルGPUを持っている読者なら、試しに llama-server を立てて Qwen Code CLI を隣に置いてみるのを勧めます。無料で回せる範囲が、想像より広いです。
本記事の元になった Zenn Book「RTX 4070でQwen 35Bを2.8倍速くする」の第10章では、llama-server の起動フラグ、承認モードの選び方、-p の使い方をコード例つきで解説しています。ローカルLLMをCLIエージェント配下で本気で動かしたい方は、この章と第3章(コンテキスト管理)、第8章(claw-code の設計方針)を通しで読むと、この記事の背景がすべて拾えます。
次の一歩
Claude Code の周辺運用(CLAUDE.md、Skills、Sub-agents、Hooks)を体系立てて追いたい方には、次に読む本として 実践Claude Code — コンテキストエンジニアリングで開発が変わる をどうぞ。全19章、CLAUDE.md 設計、マルチツール連携、セキュリティ、チーム開発、非エンジニアの活用まで通しで押さえる本です。Qwen Code CLI と組み合わせる想定でも、多くの章がそのまま使えます。
参考
- QwenLM/qwen-code — Qwen Code CLI 本体のリポジトリ
- Qwen Code Docs — 承認モード、Auto Mode、設定
- Claude Code Overview | Anthropic — Claude Code の公式ドキュメント
まとめ
- Qwen Code CLI は Alibaba オープンソースのコーディング特化CLIエージェント。モデル非依存で、ローカル
llama-serverにも接続できる - Claude Code の隣に置いた結果、「単発の生成」と「Auto-Edit の書き換えループ」の 2 種類が Qwen Code CLI に移った
- 承認モードは Plan / Ask Permissions(旧Default) / Auto-Edit / Auto / YOLO の5段階(Shift+Tabでこの順にサイクル)。ローカル運用なら Auto-Edit が落としどころ
- 設計判断、横断リファクタ、エージェント指揮、セキュリティレビュー、長文執筆は Claude Code に残った
- Qwen Code CLI と Claude Code は、担当の違うツール