Qwen Code の設定

設定の階層

設定は以下の優先順位で適用されます（数字が小さいほど優先度が低く、大きいほど上書きされます）：

設定ファイル

Qwen Code は永続的な設定に JSON 設定ファイルを使用します。これらのファイルには以下の 4 つの配置場所があります：

プロジェクト内の .qwen ディレクトリ

プロジェクト設定ファイルに加えて、プロジェクトの .qwen ディレクトリには、Qwen Code の動作に関連するその他のプロジェクト固有のファイルを含めることができます。例：

• カスタムサンドボックスプロファイル（例：.qwen/sandbox-macos-custom.sb、.qwen/sandbox.Dockerfile）。
• .qwen/skills/ 配下の エージェントスキル（各スキルは SKILL.md を含むディレクトリです）。

設定の移行

Qwen Code は、レガシー設定を新しい形式に自動的に移行します。移行前に旧設定ファイルはバックアップされます。以下の設定は、否定形（disable*）から肯定形（enable*）の命名に変更されました：

disableAutoUpdate と disableUpdateNag の統合ポリシー

両方のレガシー設定が存在し、値が異なる場合、移行は以下のポリシーに従います：disableAutoUpdate または disableUpdateNag のいずれかが true の場合、enableAutoUpdate は false になります：

settings.json で利用可能な設定

設定はカテゴリごとに整理されています。すべての設定は、settings.json ファイル内の対応するトップレベルカテゴリオブジェクト内に配置してください。

general

output

ui

ide

privacy

model

model.generationConfig の例:

{
  "model": {
    "generationConfig": {
      "timeout": 60000,
      "contextWindowSize": 128000,
      "modalities": {
        "image": true
      },
      "enableCacheControl": true,
      "customHeaders": {
        "X-Client-Request-ID": "req-123"
      },
      "extra_body": {
        "enable_thinking": true
      },
      "samplingParams": {
        "temperature": 0.2,
        "top_p": 0.8,
        "max_tokens": 1024
      }
    }
  }
}

max_tokens（適応型出力トークン）:

samplingParams.max_tokens が設定されていない場合、Qwen Code は GPU リソース使用量を最適化するために適応型出力トークン戦略を使用します：

1. リクエストはデフォルトで 8K 出力トークンの制限から開始されます
2. 応答が切り捨てられた場合（モデルが制限に達した場合）、Qwen Code は自動的に 64K トークンで再試行します
3. 部分的な出力は破棄され、再試行からの完全な応答に置き換えられます

これはユーザーに対して透過的です — エスカレーションが発生した場合、再試行インジケーターが一時的に表示されることがあります。応答の 99% が 5K トークン未満であるため、再試行はまれにしか発生しません（リクエストの 1% 未満）。

この動作を上書きするには、設定で samplingParams.max_tokens を設定するか、QWEN_CODE_MAX_OUTPUT_TOKENS 環境変数を使用してください。

contextWindowSize:

選択したモデルのデフォルトのコンテキストウィンドウサイズを上書きします。Qwen Code はモデル名のマッチングに基づいて組み込みのデフォルトと定数のフォールバック値を使用してコンテキストウィンドウを決定します。プロバイダーの実効コンテキスト制限が Qwen Code のデフォルトと異なる場合に、この設定を使用してください。この値はモデルの想定される最大コンテキスト容量を定義するものであり、リクエストごとのトークン制限ではありません。

modalities:

選択したモデルの自動検出された入力モダリティを上書きします。Qwen Code はモデル名のパターンマッチングに基づいて、サポートされているモダリティ（画像、PDF、音声、動画）を自動的に検出します。自動検出が正しくない場合（例：サポートしているが認識されていないモデルで pdf を有効にする場合）に、この設定を使用してください。形式：{ "image": true, "pdf": true, "audio": true, "video": true }。サポートされていないタイプはキーを省略するか false に設定してください。

customHeaders:

すべての API リクエストにカスタム HTTP ヘッダーを追加できます。リクエストのトレース、モニタリング、API ゲートウェイルーティング、またはモデルごとに異なるヘッダーが必要な場合に役立ちます。modelProviders[].generationConfig.customHeaders で customHeaders が定義されている場合はそれが直接使用され、それ以外の場合は model.generationConfig.customHeaders のヘッダーが使用されます。両レベル間でマージは行われません。

extra_body フィールドを使用すると、API に送信されるリクエストボディにカスタムパラメータを追加できます。標準の設定フィールドでカバーされていないプロバイダー固有のオプションに役立ちます。注意：このフィールドは OpenAI 互換プロバイダー（openai、qwen-oauth）でのみサポートされています。Anthropic および Gemini プロバイダーでは無視されます。 modelProviders[].generationConfig.extra_body で extra_body が定義されている場合はそれが直接使用され、それ以外の場合は model.generationConfig.extra_body の値が使用されます。

model.openAILoggingDir の例:

• "~/qwen-logs" - ~/qwen-logs ディレクトリにログを出力
• "./custom-logs" - 現在のディレクトリからの相対パス ./custom-logs にログを出力
• "/tmp/openai-logs" - 絶対パス /tmp/openai-logs にログを出力

fastModel

context

ファイル検索のパフォーマンスに関するトラブルシューティング

ファイル検索（例：@ 補完）でパフォーマンスの問題が発生している場合、特にファイル数が非常に多いプロジェクトでは、推奨順に以下の方法を試してください：

1. .qwenignore を使用する: プロジェクトルートに .qwenignore ファイルを作成し、参照する必要のない大量のファイルを含むディレクトリ（例：ビルド成果物、ログ、node_modules）を除外します。クロールされるファイルの総数を減らすことが、パフォーマンス向上に最も効果的です。
2. ファジー検索を無効にする: ファイルの除外だけでは不十分な場合、settings.json で enableFuzzySearch を false に設定してファジー検索を無効にできます。これにより、より単純で非ファジーなマッチングアルゴリズムが使用され、高速化される場合があります。
3. 再帰的ファイル検索を無効にする: 最後の手段として、enableRecursiveFileSearch を false に設定して再帰的ファイル検索を完全に無効にできます。プロジェクトの再帰的クロールを回避するため、これが最速のオプションになります。ただし、@ 補完を使用する際にファイルのフルパスを入力する必要があります。

tools

permissions

権限システムは、どのツールを実行可能か、確認が必要か、ブロックされるかを細かく制御します。

決定の優先順位（高い順）: deny > ask > allow > (デフォルト/インタラクティブモード)

最初に一致したルールが適用されます。ルールは "ToolName" または "ToolName(specifier)" の形式を使用します。

ツール名のエイリアス（ルール内でいずれも使用可能）:

メタカテゴリ:

一部のルール名は自動的に複数のツールをカバーします：

[!important] Read(/path/**) は 4 つすべての読み取りツール（ファイル読み取り、grep、glob、ディレクトリ一覧）に一致します。 ファイル読み取りのみを制限するには、ReadFile(/path/**) または read_file(/path/**) を使用してください。

ルール構文の例:

パスパターンのプレフィックス:

シェルコマンドのバイパス防止:

Read、Edit、WebFetch の権限ルールは、エージェントが同等のシェルコマンドを実行する場合にも適用されます。例えば、deny に Read(./.env) が含まれている場合、エージェントはシェルコマンドで cat .env を実行してこれをバイパスできません。サポートされるシェルコマンドには cat、grep、curl、wget、cp、mv、rm、chmod など多数が含まれます。不明または安全なコマンド（例：git）はファイル/ネットワークルールの影響を受けません。

レガシー設定からの移行:

設定例:

{
  "permissions": {
    "allow": ["Bash(git *)", "Bash(npm run *)", "Read(//Users/alice/code/**)"],
    "ask": ["Bash(git push *)", "Edit"],
    "deny": ["Bash(rm -rf *)", "Read(.env)", "WebFetch(malicious.com)"]
  }
}

[!tip] インタラクティブ CLI で /permissions を使用すると、settings.json を直接編集せずにルールを表示、追加、削除できます。

mcp

lsp

[!warning] 実験的機能: LSP サポートは現在実験的であり、デフォルトで無効です。--experimental-lsp コマンドラインフラグを使用して有効にしてください。

Language Server Protocol (LSP) は、定義へ移動、参照の検索、診断などのコードインテリジェンス機能を提供します。

LSP サーバーの設定は settings.json ではなく、プロジェクトルートディレクトリの .lsp.json ファイルを通じて行います。設定の詳細と例については、LSP ドキュメント を参照してください。

security

advanced

mcpServers

カスタムツールの検出と使用のために、1 つ以上の Model-Context Protocol (MCP) サーバーへの接続を構成します。Qwen Code は、構成された各 MCP サーバーへの接続を試み、利用可能なツールを検出します。複数の MCP サーバーが同じ名前のツールを公開している場合、競合を避けるためにツール名に構成で定義したサーバーエイリアスがプレフィックスとして付与されます（例：serverAlias__actualToolName）。互換性のため、システムが MCP ツール定義から特定のスキーマプロパティを削除する場合があることに注意してください。command、url、httpUrl の少なくとも 1 つを提供する必要があります。複数が指定されている場合、優先順位は httpUrl、次に url、最後に command の順です。

telemetry

Qwen Code のログ記録とメトリクス収集を構成します。詳細については、テレメトリ を参照してください。

settings.json の例

以下は、v0.3.0 で導入されたネスト構造を持つ settings.json ファイルの例です：

{
  "general": {
    "vimMode": true,
    "preferredEditor": "code"
  },
  "ui": {
    "theme": "GitHub",
    "hideTips": false,
    "customWittyPhrases": [
      "You forget a thousand things every day. Make sure this is one of 'em",
      "Connecting to AGI"
    ]
  },
  "tools": {
    "approvalMode": "yolo",
    "sandbox": "docker",
    "discoveryCommand": "bin/get_tools",
    "callCommand": "bin/call_tool",
    "exclude": ["write_file"]
  },
  "mcpServers": {
    "mainServer": {
      "command": "bin/mcp_server.py"
    },
    "anotherServer": {
      "command": "node",
      "args": ["mcp_server.js", "--verbose"]
    }
  },
  "telemetry": {
    "enabled": true,
    "target": "local",
    "otlpEndpoint": "http://localhost:4317",
    "logPrompts": true
  },
  "privacy": {
    "usageStatisticsEnabled": true
  },
  "model": {
    "name": "qwen3-coder-plus",
    "maxSessionTurns": 10,
    "enableOpenAILogging": false,
    "openAILoggingDir": "~/qwen-logs",
  },
  "context": {
    "fileName": ["CONTEXT.md", "QWEN.md"],
    "includeDirectories": ["path/to/dir1", "~/path/to/dir2", "../path/to/dir3"],
    "loadFromIncludeDirectories": true,
    "fileFiltering": {
      "respectGitIgnore": false
    }
  },
  "advanced": {
    "excludedEnvVars": ["DEBUG", "DEBUG_MODE", "NODE_ENV"]
  }
}

シェル履歴

CLI は実行したシェルコマンドの履歴を保持します。異なるプロジェクト間の競合を避けるため、この履歴はユーザーのホームフォルダ内のプロジェクト固有のディレクトリに保存されます。

• 場所: ~/.qwen/tmp/<project_hash>/shell_history
  • <project_hash> はプロジェクトのルートパスから生成される一意の識別子です。
  • 履歴は shell_history という名前のファイルに保存されます。

環境変数と .env ファイル

環境変数は、特に機密情報（トークンなど）や環境間で変更される可能性のある設定に対して、アプリケーションを構成する一般的な方法です。

Qwen Code は .env ファイルから環境変数を自動的に読み込むことができます。 認証関連の変数（OPENAI_* など）と推奨される .qwen/.env アプローチについては、認証 を参照してください。

環境変数テーブル

コマンドライン引数

CLI 実行時に直接渡される引数は、その特定のセッションに対して他の設定を上書きできます。

コマンドライン引数テーブル