ダブルクリックで英日反転
Applied Sciences · Engineering
Task-type queries — from "questions" to "requests"
In the age of AI agents, rewriting your query from a one-shot question into a multi-step request (a task) changes what you can observe and optimise for.
The rewrite
- Question: "What credit card do you recommend?"
- Task: "Compare annual fees and reward rates for my trip next month, pick the single best card, and guide me to the application page."
What changes
- Conventional unit: one question, one answer — win = being mentioned.
- Task-type unit: a multi-step task — win = being chosen, used, or bought.
- New measurables: completion rate, lookup path, and which brand was ultimately selected.
Why it matters
- Agents optimise for "the single final option", not "appearing among candidates".
- You can quantify whether a brand survives into the final selection round.
- Implementation is simple: swap out the prompt text.
→ Shift from question-mode to task-mode queries to measure and improve being chosen — not just cited.
応用科学 · エンジニアリング
タスク型クエリ（＝多段階リクエスト）— 「質問」から「依頼」へ
AIエージェント時代のクエリ設計では、一問一答の質問文をそのまま使うのではなく、複数ステップで完結する「タスク（＝依頼）」として書き直すことで、計測対象と最適化の軸が変わる。
書き換えの例
- 従来型（質問）：「おすすめのクレジットカードは？」
- タスク型（依頼）：「来月の海外旅行に向けて年会費とポイント還元率を比較し、最良の1枚を選んで申込ページまで案内してください。」
何が変わるか
- 従来の勝敗基準：回答に「言及された」かどうか。
- タスク型の勝敗基準：最終的に「選ばれ、使われ、購入された」かどうか。
- 新たな計測指標：完遂率・途中で参照されたもの・最終的に選ばれたブランド。
なぜ効くのか
- エージェントは「候補の一つに入る」より「唯一の最終選択肢になる」ことを重視する。
- 自社ブランドが最終選考ラウンドを生き残るかどうかを数値化できる。
- 実装はシンプル：プロンプト（＝AIへの入力文）のテキストを入れ替えるだけ。
→ 「言及される」から「選ばれる」へ——タスク型クエリへの移行が、GEO（生成AIへの最適化）の新しい計測軸を開く。
Applied Sciences · Engineering
Task-type queries — from "questions" to "requests"
In the age of AI agents, rewriting your query from a one-shot question into a multi-step request (a task) changes what you can observe and optimise for.
The rewrite
- Question: "What credit card do you recommend?"
- Task: "Compare annual fees and reward rates for my trip next month, pick the single best card, and guide me to the application page."
What changes
- Conventional unit: one question, one answer — win = being mentioned.
- Task-type unit: a multi-step task — win = being chosen, used, or bought.
- New measurables: completion rate, lookup path, and which brand was ultimately selected.
Why it matters
- Agents optimise for "the single final option", not "appearing among candidates".
- You can quantify whether a brand survives into the final selection round.
- Implementation is simple: swap out the prompt text.
→ Shift from question-mode to task-mode queries to measure and improve being chosen — not just cited.
応用科学 · エンジニアリング
タスク型クエリ（＝多段階リクエスト）— 「質問」から「依頼」へ
AIエージェント時代のクエリ設計では、一問一答の質問文をそのまま使うのではなく、複数ステップで完結する「タスク（＝依頼）」として書き直すことで、計測対象と最適化の軸が変わる。
書き換えの例
- 従来型（質問）：「おすすめのクレジットカードは？」
- タスク型（依頼）：「来月の海外旅行に向けて年会費とポイント還元率を比較し、最良の1枚を選んで申込ページまで案内してください。」
何が変わるか
- 従来の勝敗基準：回答に「言及された」かどうか。
- タスク型の勝敗基準：最終的に「選ばれ、使われ、購入された」かどうか。
- 新たな計測指標：完遂率・途中で参照されたもの・最終的に選ばれたブランド。
なぜ効くのか
- エージェントは「候補の一つに入る」より「唯一の最終選択肢になる」ことを重視する。
- 自社ブランドが最終選考ラウンドを生き残るかどうかを数値化できる。
- 実装はシンプル：プロンプト（＝AIへの入力文）のテキストを入れ替えるだけ。
→ 「言及される」から「選ばれる」へ——タスク型クエリへの移行が、GEO（生成AIへの最適化）の新しい計測軸を開く。
Related notes
- Browser Automation MCP 2026 — Comparing Playwright, chrome-devtools and agent-browser
- A tidy-up of the Claude Agents specifications
- "how does <filepath> work?" — Claude Code's placeholder prompt
- Claude Code's CLAUDE.md hierarchy — which instructions reach how far
- Does Claude Code's Spawn (parallel subagent launch) really run in parallel?
- Claude Mythos and Oceanus — the cutting edge and its "version for everyone"