2026-05-29 振り返り
今日やったこと
昨日から続いている課題を改善しようとしていたら、今日はウェブ検索をよりうまく組み込めるMCPツールを見つけた。
確認したツールは bing、brave、duckduckgo のブラウザ検索をMCPで提供する web-search-mcp だった。
後でフォークして現在の作業フローに合わせてカスタマイズしようと思う。
Qwen 3.6 使用感
Qwen 3.6 モデルは期待より判断が鈍かった。
qwen-code にある .github パスのワークフローをそのまま sync してプッシュし適用しろと言われたが、実際には .qwen パスに一部のファイルだけをコピーしようとした。これが核心の問題だった。
結局手動でクローンを作成し、.github と .qwen のパスを元と同じに合わせてから作業を進めた。単に「元の構造をそのまま合わせる」だけの問題だったのに、モデルがパスと目的を混同して解釈し、不要な手間が長引いた。
Qwen 自体に対する洞察
Qwen は能力がないモデルというより、能力はあるが制御性が弱いモデルに近い。
情報探索、コード修正、ファイル操作、長時間の作業実行自体はかなり得意だ。問題はユーザーの意図を固定して最後まで維持する力が弱い点だ。特に「そのままコピーして」「修正しないで」「推論しないで」「公式基準だけで」「このパスは触らないで」などの制限条件を作業途中で忘れたり、自己判断で上書きしたりする傾向があった。
つまり Qwen は仕事ができないというより、仕事をしている途中で方向性を独自に再解釈してしまう。
今回の作業の元々の問題は単純だった。
公式 .github をそのままコピー
.qwen 除外
プッシュ
テストしかし、Qwenはこれを別の問題に拡大し続けた。
MCPの問題ですか？
workflow_callの問題ですか？
pushトリガーを追加すべきですか？
.qwen/commandsを作成すべきですか？
stderr JSONの問題ですか？
empty reviewの問題ですか？問題を解決する前に問題を大きくしたものです。エージェント型 LLM ではこの点が致命的です。作業単位が大きくなるほど、元のリクエストではなく自分が作った下位問題の解決に取り掛かり始めます。
ウェブ検索を付けてもこの問題は完全には解決しませんでした。良い流れはまず公式ドキュメントやソースを確認し、構造を把握した上で、ユーザーのリクエストと比較して必要な作業だけを実行することです。しかし Qwen はまず推論し、仮説を立てた後、その仮説を確認する検索を行い、検索結果を再び自分の仮説に当てはめる流れを示しました。
そのためウェブ検索は根拠に基づく作業ツールというより仮説強化ツールのように使われました。検索能力そのものよりも検索結果を扱う姿勢の方が重要であることが確認できました。
失敗状態の解釈も弱かったです。例えば git ls-files .qwen/ の結果が空であれば .qwen は tracked 状態ではないという結論がすぐに出るべきです。ところが git rm -r --cached .qwen/ のようなコマンドを繰り返し実行しました。コマンド実行能力はあるものの、実行結果を見て次の行動を変える状態解釈とループ脱出能力が不安定でした。
また Qwen は「公式どおり」などの保存作業が苦手です。生成や修正には積極的ですが、元本を保存してそのまま同期させる作業では改善し続けようとします。公式にはないが .qwen を作るべきではないか、トリガーがないので追加すべきではないか、push で動かないので直接実行できるようにすべきではないか、といった形で元本構造を壊すことがあります。
そのため Qwen に「公式どおりにコピー」させるよりも、次のように分割して指示する方が安全です。
公式ファイル一覧を出力
自分のファイル一覧を出力
差分 diff を出力
ユーザーが承認したファイルのみコピーQwenに自律権を大きく与えることも危険です。ファイル修正、git add、コミット、プッシュ、ワークフロー修正、テスト自動実行後の追加修正といった権限は、一度誤った判断をするとその判断を実行まで押し進めてしまいます。
したがって、Qwenの役割は作業管理者や最終実行者よりも、候補生成器、ログ要約器、コマンド結果解釈補助に近いものにすべきです。
Qwen = 候補生成器 / ログ要約器 / コマンド結果解釈補助
ユーザーまたはスクリプト = 最終実行者構造化出力も注意が必要です。Qwenが JSON を全く扱えないという意味ではありませんが、複雑なスキーマやワークフローの状態管理を任せると全体の安定性が低下します。Markdown レビュー作成、コード説明、ログ要約、原因候補の整理、修正案の草案作成は問題ありません。一方、正確な JSON スキーマ出力、複雑なワークフロー状態管理、ツール呼び出し順序の管理、GitHub API の操作、ファイルパスの保持、commit/push の判断は不適切です。
結論として Qwen は生成器としては問題ありませんが、オーケストレーターとしては不安定です。
重要なのはこの一文です。
Qwen は賢い生成モデルですが、信頼できるタスクマネージャーや自動化エージェントとして使用するには制御性、状態解釈、指示の保持が弱いです。
実践的な結論は次のとおりです。
Qwenには考えさせることができる。
Qwenに草案を任せることができる。
Qwenに最終リポジトリの操作を任せてはいけない。今後も Qwen を使い続けるなら、運用原則はこのように設定すると良いです。
自主作業禁止
一度に一つの命令
修正前のdiff出力
commit/push禁止
公式原本保存作業は人が承認
LLM出力はMarkdown/textのみ使用ウェブ検索 MCPで感じたこと
ウェブ検索を組み込んだところ、従来のウェブパッチ方式よりも検索性能が確実に向上した。必要な資料を見つける速度と検索範囲が広がり、候補リンクを集めるのに役立った。
ただし、ウェブ検索で得た情報を奇妙に解釈する傾向があった。検索は得意なのに、検索結果をコード作業の文脈に合わせて判断する能力はまだ不安定だった。
そのため、コーディング LLM と検索 LLM を分離する方が良いかもしれないと感じた。検索は検索に強いモデルやツールに任せ、コーディングの判断は別途検証する構造の方が安定しそうだ。
反省
今日の作業中の一部は、実は答えを知っていた単純な問題だった。
.github と .qwen を元と同じように合わせればよいだけのことを、モデルの中間試行に引きずられて問題を複雑に見てしまった。次回はモデルが出した作業結果が要件の構造に合っているかをまず確認し、パス／ファイル単位の同期作業は初期段階で直接 diff で検証すべきだ。
特に「何をコピーしたか」よりも「元と目的地が同じ構造になっているか」を先に確認する習慣が必要である。
作業中断の課題
本日午後2時以降、インターネットが不安定になり、RunPodで稼働していた Qwen サーバーが停止した。その後はモデル呼び出しができず、作業を続けるのが困難だった。
ローカルでの作業や整理は可能だったが、Qwen サーバーを前提とした自動レビュー／検索／検証フローはインターネット状態に大きく依存することを再確認した。
次のアクション
web-search-mcpをフォークして、必要な検索エンジンと出力フォーマットをカスタマイズする。- Qwen がウェブ検索結果を解釈する際に生じるエラーを減らすため、検索結果の要約とコーディング判断のステップを分離する。
.github、.qwenのようにディレクトリ構造の同期が重要な作業は、まずdiff基準で検証する。- Qwen にリポジトリ操作権限をすぐに与えず、コマンドは一度に一つ、diff 確認中心で運用する。
- Qwen の出力はまず Markdown/text の草案として受け取り、JSON スキーマや GitHub API のオーケストレーションはスクリプトまたは人が担当する。
- RunPod Qwen サーバー障害に備えて、フォールバックモデルやローカル確認手順を用意する。