Qwen Code の使い分け：対話で進める仕事とバッチに回す仕事

まず仕事の単位を決める

AI の作業手順を考えるときは、入力、期待する出力、結果を受け入れる根拠を先に決めます。使い慣れた画面でも、仕事の定義が曖昧なままでは判断しづらくなります。仕事を具体的に書けば、どの画面でも結果を確認しやすくなります。

Qwen の 10 月 9 日の更新 ↗では、ブラウザー機能は Mac/Linux に対応し、Windows は未対応とされています。独立した一回の処理はバッチの候補になり、送信前に計画の確認と承認が必要です。

以下は私たちが考えた分類練習です。性能測定は行っておらず、実際のジョブを送信する必要もありません。

方法を選ぶ前の四つの質問

一つ目は、処理中に入力を固定できるかです。変わり続けるデザインの条件や、前の回答を見て次の手順を決める調査には、対話形式が向いています。確定した入力の集まりは、範囲を明確にしてからバッチの候補として検討できます。

二つ目は、何をもって正しい出力とするかです。「この報告を改善して」だけでは、確認する人が判断に迷います。「報告 ID、指定した一覧から一つの分類、その判断を支える原文の一文を返す」なら、確認する対象が具体的になります。創作では、想定読者や草案の選定基準も書いておきます。

三つ目は、項目同士が依存しているかです。複数のファイルが、一つの調査を構成することもあります。別々の依頼に分けると、理解に必要な関係が失われるかもしれません。関連する項目はまとめ、独立した項目は個別に確認します。

四つ目は、いつまでに役立つ回答が必要かです。許容できる最終時刻を書きます。処理量や価格を最適化する前に、待つことが仕事の条件に合うかを確認できます。

十二件の報告で紙上練習をする

架空の短い不具合報告を十二件作ります。それぞれに ID、症状、二行の背景を付けてください。分類は「表示」「操作」「性能」の三つとし、二件は意図的に曖昧にします。期待する出力は、元の ID、分類、判断の根拠となる短い表現、要確認の印を含む小さな記録です。

次の四つの仕事を分類します。

• 固定された十二件の報告を分類する：サンプルの確認を通過すれば、バッチの候補です。
• ときどき二回反応するボタンを調べる：次の観察で診断が変わる可能性があるため、対話形式で進めます。
• 同僚と三つの分類の意味を決める：報告を処理する前に、短い相談を行います。
• 完全に決まった規則でファイル名を変更する：決定的に動く小さなスクリプトも検討します。

それぞれの選択の横に理由を書いてください。AI への依頼を増やしても価値が小さい場合を含め、隠れた前提を見つけるための練習です。

受け入れる根拠を見える形にする

まず三件の架空の報告の出力を確認します。ID が維持されているか、分類が許可した一覧に含まれるか、根拠の表現が本当に入力にあるかを見ます。曖昧な例では、不確実性が明示されているかも確認します。これは確認項目の提案であり、ツールが必ず合格するという意味ではありません。

全件を扱うときは、入力と出力の ID を照合します。欠落、重複、裏付けのない説明は確認待ちにします。修正する項目と理由を記録してください。成功したように見える総数でも、一件の失敗を隠していることがあります。元の入力を保存し、修正版を別に確認すれば、再試行の範囲を説明できます。

限界と次の一歩

仕事の分類だけでは、正確さ、費用の削減、無人での実行は保証できません。アクセスの判断、確認基準、送信や再試行の決定には責任を持つ人が必要です。実際に動かす前に、公式のバッチ処理資料 ↗で現在の設定と送信方法を確認してください。

今日は紙の上で練習を終えてみましょう。なぜ出力を受け入れられるか説明できなければ、件数を増やす前に仕事の定義と確認基準を改善します。