research

research skill の概要

research skill ができること

research skill は、技術・概念・複雑なテーマを理解するための、構造化されたディープリサーチ用ワークフローです。計画と実行を 1 つの曖昧なプロンプトに押し込まず、まず「どう調べるか」を決める段階と、実際に「調査を進める」段階に分けて進めます。1 つのエージェントに、調査方針の判断と調査実行を同時に任せない設計になっており、そこがこの skill を導入する大きな理由です。

どんな人にこの research skill が向いているか

この research skill は、ソフトウェアアーキテクチャ、プロトコル、学術的な概念、未知のシステムなどを、再現性のある形で調べたいユーザーに向いています。特に、調査範囲のコントロール、問いの立て方、本調査に入る前のレビューを重視する場合に有効です。research for Academic Research、技術デューデリジェンス、概念整理のような用途では、この事前の計画ステップが、汎用的な「X について教えて」型のプロンプトよりも価値を発揮しやすくなります。

この skill で片付く本当の仕事

本当に片付けたい仕事は「要約を生成すること」ではありません。やるべきことは、テーマを定義し、必要な文脈を見極め、調査戦略を作り、ユーザー承認で一度止まり、その後に新しい文脈と明確な境界条件で実行することです。これにより、論点のズレ、浅い調査、見当違いの方向へのトークン消費を減らせます。

導入前に確認したいポイント

この skill はリポジトリ構成としては軽量で、実用的なロジックの大半は SKILL.md に集約されています。補助スクリプト、参照ファイル、インストール用メタデータは用意されていないため、実際に機能するかどうかは、あなたのエージェント実行環境が「計画エージェント」「オーケストレーター」「実行エージェント」という想定のマルチエージェントフローを扱えるかにかかっています。ワンショットで即答が欲しい用途なら、この research skill は必要以上に遅く感じる可能性があります。

research skill の使い方

インストール時に見るべき場所と最初に読むファイル

この research install を判断するなら、まず EN/.agents/skills/research/SKILL.md を確認してください。実際のワークフロー、入力要件、オーケストレーションの挙動はそのファイルに書かれています。リポジトリ上の根拠を見る限り、この skill 自体に専用の install コマンドは見当たりません。したがって、利用中のエージェント基盤がサポートする方法で skill を読み込んだうえで、実行環境が次のことを満たせるか確認するのが現実的です。

• /research を呼び出せる
• planning agent を起動できる
• 確認のために一時停止できる
• plan file path を渡して execution agent を起動できる

エージェント間で作業をきれいに受け渡せない環境では、research skill の核となる価値はかなり下がります。

research skill に必要な入力

最低限必要なのはトピックです。ただし、次の情報を足すと結果はかなり安定します。

• 何を判断したいのかという具体的な意思決定
• どの深さまで調べたいか
• 時間、想定読者、前提知識などの制約
• プロジェクト文脈やドメイン情報

弱い入力:
/research OAuth2

より強い入力:
/research Research OAuth2 for a backend team migrating from session auth. Focus on grant types still relevant in 2025, common implementation mistakes, security tradeoffs, and what to recommend for internal APIs vs third-party integrations.

research for Academic Research で使うなら、研究課題、分野、求める厳密さ、出力形式まで入れておくとよいです。
/research Investigate retrieval-augmented generation evaluation methods for academic literature review. Compare offline metrics, human evaluation, and benchmark design. I need a structured brief with terminology, core debates, and a shortlist of methods worth deeper reading.

実務で使いやすい research usage フロー

実践しやすい research usage の流れは次のとおりです。

1. /research を、範囲を絞ったトピックと欲しい成果物つきで実行する。
2. planning agent に文脈を洗い出させ、plan file を作らせる。
3. 実行前に plan をレビューする。ここで、想定読者のズレ、抜けている問い、広すぎるスコープを見つける。
4. plan が意図どおりになってから execution を承認する。
5. 最終ノートは最初の地図として使い、不明確な部分はさらに狭いテーマで follow-up の research を回す。

このレビューゲートこそが、通常のプロンプト運用との実務上の最大の違いです。plan が弱ければ、実行結果もたいてい弱くなります。

うまく呼び出すためのプロンプトの書き方

計画しやすい形でプロンプトを書くのがコツです。

• Topic: 何を調べるのか
• Goal: どんな判断や理解が必要か
• Scope: 含めること・除外すること
• Audience: beginner、practitioner、researcher、leadership
• Output: comparison、briefing、notes、recommendations

例:
/research Topic: consistent hashing. Goal: explain it well enough to choose whether to use it in a distributed cache design. Scope: core mechanism, failure cases, virtual nodes, operational tradeoffs; exclude heavy math proofs. Audience: senior engineers. Output: decision-oriented research notes.

research skill に関する FAQ

調査用途なら普通のプロンプトより良い？

多くの場合は yes です。特に、テーマが広い・曖昧・意思決定に直結する場合に向いています。通常のプロンプトだと、計画、前提、回答生成が 1 回の流れに混ざりがちです。research skill は最初に明示的な plan を作るため、スコープが整いやすく、最終アウトプットも信頼しやすくなります。

research skill を使わないほうがいいのはどんな時？

単純な事実確認、簡単な定義、すでに掘るべき下位質問が明確なタスクなら、使わないほうが早いです。レビュー工程が不要なら、2 段階フローはオーバーヘッドになりえます。サブエージェント連携を安定して扱えないエージェントシステムでも、適性は下がります。

初心者にも向いている？

向いています。ただし、トピック名だけでなく「何を達成したいか」を言語化できることが前提です。Teach me Kubernetes は広すぎます。Help me understand Kubernetes enough to deploy one internal service and avoid common architecture mistakes のほうがずっと適切です。skill は助けになりますが、良いスコープ設定そのものを代替してくれるわけではありません。

Academic Research のワークフローにも合う？

research for Academic Research の文脈では、問いの立て方や論点整理、サブトピック整理の段階で役立ちます。特に、用語の対応付け、主要な論点、周辺テーマの地図作りには向いています。ただし、正式な literature review の方法論、ソース検証、引用管理、分野固有のエビデンス基準の代わりとして扱うべきではありません。そうした工程は、より広いシステム側で別途補う必要があります。

research skill を改善する方法

execution を承認する前に plan を改善する

最も効果が大きい改善ポイントは、最終ノートではなく plan を批評することです。plan を見るときは、次を確認してください。

• 自分が本当に判断したいことに答える構成になっているか
• 背景説明と実際に使う問いが分かれているか
• 広げすぎていないか
• 想定読者や制約が反映されているか

plan が汎用的すぎるなら、execution の前に観点をもっと絞るよう求めるべきです。

より良い research 出力のために入力を強くする

この research skill は、意思決定の文脈を足すと明らかに精度が上がります。特に有効なのは次の情報です。

• すでに分かっていること
• どこで混乱しているか
• 次に必要なアウトカムは何か
• 何をもって「十分」とするか

たとえば compare approaches だけでは弱く、compare approaches for maintainability, migration risk, and operational complexity in a small team のように軸を明示したほうが有用です。

よくある失敗パターンを把握する

典型的な問題は、トピックが広すぎること、想定読者が曖昧なこと、そして「全部サーベイしてほしい」という依頼です。もう 1 つの失敗パターンは、skill がプロジェクト文脈を自動で正しく推測してくれると期待してしまうことです。対象が進行中の codebase、architecture、学習・研究テーマに関係するなら、その文脈は明示してください。構造化された skill ではあっても、意図が欠けている状態までは補完できません。

1 回目のあとに反復する

最初の実行は地図作りだと考えるのが適切です。そのうえで、重要度の高い部分、たとえば争点になっている tradeoff、難しい概念、分岐する意思決定ポイントに対して、2 回目の research guide サイクルを回してください。巨大な 1 リクエストを 1 回投げるより、狭く区切った連続的な調査のほうが、通常は良いアウトプットになります。research skill を単発プロンプトではなく、信頼できるワークフローとして定着させる最善の方法です。