Qwen をローカル LLM として開発フローに入れた記録

導入した理由

今回入れたのは、Qwen をローカル LLM として手元で動かし、Codex の作業を補助するための環境です。 この記事は構築手順ではなく、開発フローへどう組み込むかを整理します。 作業を丸ごと置き換えるのではなく、Codex が作業範囲を決めたあとに、候補出しや要約を任せる補助役として導入しました。

普段使っているクラウドモデルは、今回の手元モデルよりも最終判断に使いやすい場面があります。 一方で、短い確認や下読みまで毎回クラウドへ投げると、作業の粒度が重くなります。 そこで、手元で動く Qwen は小さな相談相手として使います。 最終的な判断は Codex 側で行う形にしました。

構成

実行基盤は llama.cpp です。 ローカルサーバを 127.0.0.1:8080 で起動し、OpenAI 互換の /v1/chat/completions と /v1/responses を使えるようにしています。

モデルは Qwen 系の GGUF を使っています。 Codex からは Responses API として接続し、必要なときだけ限定したタスクを渡します。 現在の環境ではコンテキスト長も広げ、長めのレビュー材料を受け取れるようにしています。

ただし、長い入力を渡せることと、何でも投げてよいことは別です。 実運用では、入力をできるだけ小さく保ちます。 候補を出す対象のファイルや観点を先に絞り、返してほしい形式も決めてから使います。

任せること

ローカル LLM には、主に次の作業を任せます。

• 選んだファイルの要約
• 実装前の小さな計画案
• コードレビュー候補の洗い出し
• 差分から見えるリスクの列挙
• 読み取り専用コマンドによる狭い範囲の確認

どれも「答えを決める」作業ではなく、判断材料を作るための作業です。 正しいかどうかを決める役割は、Codex 側に残します。

特にコードレビューでは、ローカル LLM の指摘をそのまま採用しません。 該当ファイルを読み直し、実際のコードと合っているかを確認します。 修正案も直接適用せず、必要な部分だけを見直してから実装します。

任せないこと

逆に、次の作業は任せない方針にしました。

• 最終的な正誤判断
• 広いリポジトリ全体の探索
• セキュリティや仕様の断定
• ファイル編集や削除
• 依存関係の追加やサービス再起動

ローカルで動くことは便利ですが、責任の境界が曖昧になると危険です。 そのため、読み取り専用で使う場面を基本にしています。 書き込みや環境変更が必要な場合は、Codex が通常の確認手順で行います。

使ってみて分かったこと

まず、コンテキスト長は重要でした。 短い設定ではレビュー用の材料を受け取れず、入力時点で失敗しました。 設定を広げると長い入力も扱えますが、その分だけ待ち時間は伸びます。

次に、出力形式の指定も重要です。 JSON だけを返してほしい場面でも、Markdown のコードブロックで包まれることがありました。 機械的に使う結果ほど、形式の検証を前提にする必要があります。

もう1つ大事なのは、ローカル LLM を低コストな最終判断役にしないことです。 候補生成は十分に役立ちます。 それでも、事実確認と採用判断は別の工程として残す必要があります。

今後の使い方

今後は、Codex が方針を決め、ローカル LLM が狭い範囲の下読みを手伝う形にします。 たとえば、差分の違和感を 3 件だけ挙げてもらう。 選んだファイルの責務を短くまとめてもらう。 そうした小さな使い方から始めるのが合っています。

この構成は、派手な自動化ではありません。 日々の開発で発生する確認作業を少し軽くするための道具です。 小さく試し、使える場面を観察し、実務の流れに無理なく組み込んでいきます。