適応症（治療対象となる病気）、作用メカニズム（効く仕組み）、または治療標的（薬が狙う対象）について、誰がどの医薬品を開発しているかを把握します。開発段階、企業、または作用メカニズムごとにまとめて表示します。 **次のような場合に使用:** - 競合状況に関する質問（「非小細胞肺がんの開発状況を整理して」「TL1Aに取り組んでいる他社は？」「Xの競合相手は誰か」など） **注記:** このスキルは医薬品開発プログラム中心です。病気そのものについて調べたい場合は「適応症・疾患研究」を、資金の流れを知りたい場合は「資金調達状況」を使用してください。
Map who is developing what for an indication, mechanism, or target, grouped by phase, company, or mechanism. Use for competitive questions, for example 'map the NSCLC landscape', 'who else is working on TL1A', 'what is the competition for X'. This is drug-program-centric: use indication-research when the question is about the disease itself, and funding-landscape when it is about capital flow.
このワークフローは、複数の基本的な処理を組み合わせて、再利用可能なパイプライン情報パッケージを作成します。
パイプラインビュー（どの医薬品候補が開発段階にあり、どの段階にあり、どのような作用メカニズムを持つか）は医薬品開発プログラムを中心とした見方をします。同じ分野の資金流動の観点（最近の資金調達、総調達額、投資家構成、契約頻度）については、代わりに「funding-landscape」に案内してください。これら2つの層は独立しており、完全な競合分析には通常両方が必要です。
enumerate-entities（情報源を列挙する）profile-entity（個別情報を詳細化する）synthesize-evidence（根拠を統合する）trace-events（出来事を追跡する）benchmark-assets（資産を比較評価する）synthesize-evidence -- パイプラインの問題にカタログデータを超えた個別の評価基準が含まれる場合（例：「経口投与製剤はどれか」「KRAS G12C を特異的に標的とするはどれか」）；個別の根拠を絞り込むのではなく、評価前に対象を絞るvalidate-target -- パイプラインで遺伝子標的の検証度や特異性でプログラムをランク付けする場合構造化されたパッケージを返します。以下の要素を含めることができます：
パイプラインテーブルや候補リストの場合は、2段階に分けます：
read_document、research_entity、もしくは他のドキュメント・読込方法で確認した候補医薬品ごとの詳細ではなく、パイプラインの構成（段階別件数、メカニズム別件数、開発企業別件数）が必要な場合は、aggregate_records(entity_type="drug", ...)を使用します。これはresearch_landscape（候補リストを返す）を補完して、1回の呼び出しでグラフ作成可能な分布を提供します。
query="active drugs in {indication} grouped by phase"query="active drugs in {indication} grouped by mechanism, top 25"query="active drugs in {indication} grouped by company, top 25"（注：companiesは多対多で展開済み、共同開発される医薬品は所有会社ごとに1回カウント）aggregate_recordsは件数層用であり、根拠層用ではありません。引用されたすべての統計値は、確認済み中核層に組み込まれる前に、ドキュメントまたは治験識別子に支えられている必要があります。
このワークフローは以下の3段階パターンに従う必要があります：
列挙: 構造化されたMCPツールでベースラインのパイプライン全体像を把握します。集計図（段階分布、メカニズムの混雑度、企業集中度）については、個別候補の列挙前にaggregate_recordsで全体像を取得します。
補強: search_documents、read_document、出来事・ドキュメント確認でベースラインを拡張します。
整合性確認: 最終的な候補セットと主要な主張を確認してからパッケージを返します。
research_landscapeと関連する構造化ツールは適切な出発点ですが、マスターパイプライン分析の唯一の真実ソースではありません。ドキュメント検索を使用して以下の情報を発見してください：
research_landscape、search_entities、fetch_related、またはエンティティプロフィールのみでパイプラインを確定しないread_document、research_entity、または他の読込・取得方法で確認しない限り、確認済み中核層に昇格させないsearch_entitiesとresearch_landscapeからの主要な医薬品ごとの事実を、search_documentsプラスread_documentまたはresearch_entityで確認してから、根拠に基づく主張として扱うApproved/Filed）に対して確認し、区別が回答を左右する場合はFDA申請に対してsearch_documentsプラスread_documentで確認するresearch-assistantサブエージェントと並行して医薬品ごとの根拠を収集し、1プログラムにつき1つの作業ストリームで実施してから、テーブル構築前に返却された主張セットを整合させるmatch_entityを使用し、search_entitiesはより広い基準ベースの発見に予約するmatch_entityを呼び出す場合、元のエンティティ名をnameに保ち、スポンサー・企業・曖昧さ回避テキストをcontextに置くresearch_landscapeを呼び出す場合、元の適応症名をindicationに保ち、補足的な曖昧さ回避テキストをcontextに置くresearch_landscapeまたは関連する構造化列挙が小さすぎると見える場合、確定前に2次的なsearch_entitiesパスと広範なsearch_documents補強を実行するsearch_documentsプラスread_documentにピボットするThis workflow coordinates primitives to produce a reusable pipeline intelligence package.
The pipeline view is drug-program-centric (which assets are in development, at what phase, with what mechanism). For the capital-flow view of the same space (recent rounds, total raised, investor mix, deal cadence), route to funding-landscape instead. The two layers are independent and a complete competitive picture often needs both.
enumerate-entitiesprofile-entitysynthesize-evidencetrace-eventsbenchmark-assetssynthesize-evidence -- when the pipeline question includes per-row evaluation criteria beyond catalog metadata (e.g., "which of these have an oral formulation", "which target KRAS G12C specifically"); narrow the set before evaluating rather than thinning the evidence per rowvalidate-target -- when the pipeline view ranks programs by target genetic validation or specificityReturn a structured package that can include:
For pipeline tables or asset lists, use two tiers:
read_document, research_entity, or another document/read path.For the shape of the pipeline (counts by phase, by mechanism, by sponsor) rather than per-asset detail, use aggregate_records(entity_type="drug", ...). This complements research_landscape (which returns the asset list) by giving a chart-ready distribution in a single call.
query="active drugs in {indication} grouped by phase"query="active drugs in {indication} grouped by mechanism, top 25"query="active drugs in {indication} grouped by company, top 25" (note: companies is M2M-exploded; co-developed assets count once per owning company)aggregate_records is for the count layer, not the evidence layer. Any quoted statistic still needs a document or trial identifier behind it before it goes into the core confirmed tier.
This workflow should follow a three-step pattern:
aggregate_records to get the picture before enumerating individual assets.search_documents, read_document, and event/document checksresearch_landscape and related structured tools are the right starting point, but they are not the full truth source for a master pipeline analysis. Use document search to surface:
research_landscape, search_entities, fetch_related, or entity profilesread_document, research_entity, or another read/fetch pathsearch_entities and research_landscape with search_documents plus read_document or research_entity before treating them as evidence-backed claimsApproved/Filed) and, where the distinction carries the answer, against an FDA filing via search_documents plus read_documentresearch-assistant sub-agent, one workstream per program, then reconcile the returned claim sets before building the tablematch_entity; reserve search_entities for broader criteria-based discovery.match_entity, keep the raw entity name in name and put sponsor/company/disambiguating text in context.research_landscape, keep the raw indication name in indication and put extra disambiguating text in context.research_landscape or related structured enumeration looks too small, run a secondary search_entities pass and broad search_documents augmentation before finalizing.search_documents plus read_document.原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。