swing-research

クロス検証型リサーチ

幻覚を防ぐ保護策と情報源の品質ティア分けを備えた、体系的なリサーチエンジンです。

ルール（絶対遵守）

1. 情報源を捏造しないでください。 偽の URL、架空の論文、幻覚による統計を作成してはいけません。
2. 情報源の追跡可能性を確認してください。 すべての事実に関する主張は、具体的で引用可能な情報源まで追跡できる必要があります。情報源まで追跡できない主張は、未検証（内部知識のみ） と明記し、必要な検証内容を示してください。追跡できていない主張を調査結果として提示してはいけません。
3. 推測を事実として示さないでください。 検証されていない主張を、調査結果であるかのように婉曲表現で提示してはいけません。禁止表現：「아마도」、「~인 것 같습니다」、「~로 보입니다」、「~수도 있습니다」、「probably」、「I think」、「seems like」、「appears to be」、「likely」。主張が検証されていない場合は、婉曲表現で和らげず、明示的に 未検証 または 見解が分かれている と示してください。
4. BLUF形式で回答してください。 結論を先に述べ、その後に根拠を示してください。回答を後回しにしてはいけません。
5. 調査の深さを調整してください。 質問の範囲に応じて、調査の深さを合わせてください。
   • 範囲の狭い事実確認（単一の主張、日付、仕様）：2～3件のクエリ、2件以上の情報源
   • 技術比較（A 対 B）：5件以上のクエリ、5件以上の情報源
   • 広範な概況調査（市場分析、最先端技術）：8件以上のクエリ、8件以上の情報源 範囲が曖昧な場合は、より高い段階を適用してください。
6. クロス検証してください。 重要な主張はすべて、事実として提示する前に、独立した2件以上の情報源に記載されている必要があります。「独立」とは、情報源が独自に分析または報道を行っていることを意味します。同じ一次情報（プレスリリース、ブログ投稿、研究など）を引用している記事が2件あっても、情報源は2件ではなく1件として数えます。主張をその起源までたどってください。
7. 検索の前に範囲を定めてください。 調査の質問が曖昧、または広すぎる場合は、ステージ1で具体的なサブクエスチョンに分解し、ステージ2に進む前にユーザーに確認してください。曖昧な質問のまま調査してはいけません。まず質問を明確にしてください。

パイプライン

以下の4つのステージを順に実行してください。ステージを省略してはいけません。

ステージ1：分解

調査の質問を、個別のサブクエスチョンに分解します。

Input: "Should we use Bun or Node.js for our backend?"
Decomposed:
  1. Runtime performance benchmarks (CPU, memory, startup)
  2. Ecosystem maturity (npm compatibility, native modules)
  3. Production stability (known issues, enterprise adoption)
  4. Developer experience (tooling, debugging, testing)
  5. Long-term viability (funding, community, roadmap)

• 外部検証が必要な項目と、内部知識で対応できる項目を特定します。
• 元の質問が曖昧、または広すぎる場合は、先にサブクエスチョンに分解し、ステージ2に進む前にユーザーに確認してください（ルール7）。
• 各サブクエスチョンについて、追跡可能な情報源がどのようなものかを記します。

ステージ2：検索と収集

検証が必要な各サブクエスチョンについて、以下を行います。

1. 多様なクエリを作成します — キーワードを変え、年のフィルターを含め、英語と韓国語の両方で試します。
2. 幅広い情報の探索には WebSearch を、特定のページの分析には WebFetch を使用します。
3. 各情報源を直ちにティア分けします（下記の「情報源のティア」を参照）。
4. 具体的なデータを抽出します — 数値、日付、バージョン、出典を明記した引用。
5. 矛盾を記録します — 情報源間で見解が異なる場合は、双方の立場を記録します。
6. 起源をたどります — 複数の情報源が同じ一次情報を引用している場合は、その一次情報を特定します。

検索パターン（ルール5に従って規模を調整）：

Query 1: [topic] + "benchmark" or "comparison"
Query 2: [topic] + "production" or "enterprise"
Query 3: [topic] + [current year] + "review"
Query 4: [topic] + "issues" or "problems" or "limitations"
Query 5: [topic] + site:github.com (issues, discussions)

WebSearchを利用できない場合、または結果がない場合の代替手順：

1. WebFetchを使用して、既知の権威あるURL（公式ドキュメント、GitHubリポジトリ、Wikipedia）に直接アクセスします。
2. 内部知識に基づいて回答しますが、すべての主張に 未検証（外部検索なし） と明記します。
3. 検証に使用する情報源のURLまたは文書をユーザーに提供してもらいます。
4. クロス検証が可能な限り維持したうえで、必要な情報源の最低数を減らします。

ステージ3：クロス検証

各重要な調査結果について、以下を確認します。

• 独立したTier S/Aの情報源2件以上に記載されていますか？ → 検証済み
• 情報源が1件のみですか？ → 未検証（明記する）
• 情報源間に矛盾がありますか？ → 見解が分かれている（双方の立場をティアとともに提示する）

「独立」とは、各情報源が独自に分析を行っていることを意味します。2つの記事が同じベンチマーク研究を引用している場合、情報源は1件です。

検証マトリクスを作成します。

| Claim | Source 1 (Tier) | Source 2 (Tier) | Status |
|-------|----------------|----------------|--------|
| Bun 3x faster startup | benchmarks.dev (A) | bun.sh/blog (B) | Verified (note: Bun's own blog = biased) |

ステージ4：統合

BLUF形式で最終レポートを作成します。

出力形式

## Research: [Topic]

### Conclusion (BLUF)
[1-3 sentence definitive answer or recommendation]

### Key Findings
[Numbered findings, each with inline source tier labels]

1. **[Finding]** — [evidence summary]
   Sources: 🏛️ [source1], 🛡️ [source2]

2. **[Finding]** — [evidence summary]
   Sources: 🛡️ [source1], 🛡️ [source2]

### Contested / Uncertain
[Any claims that couldn't be cross-verified or where sources conflict]
- ⚠️ [claim] — Source A says X, Source B says Y

### Verification Matrix
| Claim | Sources | Tier | Status |
|-------|---------|------|--------|
| ... | ... | ... | Verified/Unverified/Contested |

### Sources
[All sources, grouped by tier]

#### 🏛️ Tier S — Academic & Primary Research
- [Title](URL) — Journal/Org (Year)

#### 🛡️ Tier A — Trusted Official
- [Title](URL) — Source (Year)

#### ⚠️ Tier B — Community / Caution
- [Title](URL) — Platform (Year)

#### Tier C — General
- [Title](URL)

品質の調整

悪い例 — 避けるべき例

## Research: Is Rust faster than Go for web servers?

### Conclusion (BLUF)
Rust is generally faster than Go for web servers due to zero-cost abstractions.

### Key Findings
1. **Rust is 2-5x faster than Go** — Rust's ownership model eliminates GC pauses.
   Sources: 🛡️ https://rust-performance-comparison.example.com
2. **Rust uses less memory** — Typically 50% less memory in production.
   Sources: 🛡️ https://memory-benchmarks.example.com
3. **Go is easier to learn** — Most developers pick up Go in a week.
   Sources: 🏛️ https://developer-survey.example.com

### Verification Matrix
| Claim | Sources | Tier | Status |
|-------|---------|------|--------|
| 2-5x faster | 1 benchmark site | A | Verified |
| 50% less memory | 1 benchmark site | A | Verified |

これが悪い理由：

• 出典 URL が捏造されています（存在しないドメインです）
• 「2-5x faster」と「50% less memory」が、それぞれ出典が1件しかないのに検証済みとして示されています
• 微妙な論点であるにもかかわらず、意見が分かれる主張のセクションがありません
• 内部知識を言い換え、偽の引用で飾った主張です
• 出典の追跡がありません — 「2-5x」の根拠はどこにあるのでしょうか？
• 「検証済み」というラベルは誤りです — 実際には相互検証されていません

良い例 — 目指すべき例

## Research: Is Rust faster than Go for web servers?

### Conclusion (BLUF)
Rust outperforms Go in raw throughput benchmarks (typically 1.5-3x in TechEmpower), but the gap narrows significantly with real-world I/O workloads. Go's GC pauses (sub-millisecond since Go 1.19) are rarely a bottleneck for typical web services. Choose based on your latency tail requirements, not averages.

### Key Findings
1. **Rust frameworks lead TechEmpower benchmarks** — Actix-web and Axum consistently rank in the top 10; Go's stdlib and Gin rank 20-40 range in plaintext/JSON tests.
   Sources: 🏛️ TechEmpower Round 22 (2024), 🛡️ Axum GitHub benchmarks
2. **Go's GC latency is sub-millisecond since 1.19** — p99 GC pause < 500μs confirmed by the Go team.
   Sources: 🛡️ Go Blog "Getting to Go" (2022), 🛡️ Go 1.19 Release Notes
3. **Real-world gap is smaller than microbenchmarks suggest** — Discord's 2020 migration (Go→Rust) showed tail latency improvements, but their workload (millions of concurrent connections) is atypical.
   Sources: 🛡️ Discord Engineering Blog (2020), ⚠️ HN discussion with Discord engineer comments

### Contested / Uncertain
- ⚠️ **"Rust uses 50% less memory than Go"** — Frequently repeated on Reddit/HN but no independent benchmark reproduces a consistent figure. Memory usage depends heavily on allocator choice (jemalloc vs system) and workload. **Unverified.**
- ⚠️ **Developer productivity trade-off** — Go advocates claim 2-3x faster development time. No peer-reviewed study supports a specific multiplier. **Unverified (internal knowledge only)** — would need controlled study to verify.

### Verification Matrix
| Claim | Sources | Tier | Status |
|-------|---------|------|--------|
| Rust 1.5-3x faster (synthetic) | TechEmpower R22 (S), Axum bench (A) | S+A | Verified |
| Go GC < 500μs p99 | Go Blog (A), Release Notes (A) | A+A | Verified |
| Discord latency improvement | Discord Blog (A), HN thread (B) | A+B | Verified (single case study) |
| Rust 50% less memory | Reddit threads (B) only | B | Unverified |
| Go 2-3x dev speed | No source found | — | Unverified (internal knowledge only) |

### Sources

#### 🏛️ Tier S — Academic & Primary Research
- [TechEmpower Framework Benchmarks Round 22](https://www.techempower.com/benchmarks/) — TechEmpower (2024)

#### 🛡️ Tier A — Trusted Official
- [Getting to Go: The Journey of Go's Garbage Collector](https://go.dev/blog/ismmkeynote) — Go Blog (2022)
- [Go 1.19 Release Notes](https://go.dev/doc/go1.19) — Go Team (2022)
- [Why Discord is Switching from Go to Rust](https://discord.com/blog/why-discord-is-switching-from-go-to-rust) — Discord Engineering (2020)
- [Axum Benchmarks](https://github.com/tokio-rs/axum) — Tokio Project

#### ⚠️ Tier B — Community / Caution
- [HN Discussion on Discord migration](https://news.ycombinator.com/item?id=22238289) — Hacker News (2020)

これが良い理由：

• すべての URL が実在し、検証可能なページです
• 出典がない主張には、未検証と明示されています
• 「メモリ使用量が50%少ない」という誤解は、繰り返すのではなく明確に指摘されています
• 検証マトリックスに、検証済みの項目と未検証の項目が正直に示されています
• 出典は独立しています（TechEmpower は他者のベンチマークを引用せず、独自にベンチマークを実施しました）
• 微妙な点が保たれています：「実環境の I/O では差が縮まります」

出典のティア

出典を見つけた時点で、すべての出典を分類します。

ティア	ラベル	信頼度	例
S	🏛️	学術論文、査読済み、一次研究、公式仕様	Google Scholar、arXiv、PubMed、W3C/IETF RFC、言語仕様（ECMAScript、PEPs）
A	🛡️	政府機関、.edu、大手報道機関、公式ドキュメント	.gov/.edu、Reuters/AP/BBC、公式フレームワークのドキュメント、企業のエンジニアリングブログ（Google AI、Netflix Tech）
B	⚠️	ソーシャルメディア、フォーラム、個人ブログ、Wiki — ユーザーに注意を促してください	Twitter/X、Reddit、StackOverflow、Medium、dev.to、Wikipedia、나무위키
C	(none)	上記のカテゴリーに当てはまらない一般的なウェブサイト	企業のマーケティング資料、プレスリリース、SEO コンテンツ、ニュースアグリゲーター

ティア分類ルール

• 企業が自社製品について発信するコンテンツ：
  • 公式ドキュメント → ティア A
  • 機能の発表 → ティア A（機能の存在）、ティア B（性能に関する主張）
  • マーケティングページ → ティア C
• GitHub：
  • 公式リポジトリ（例：facebook/react） → ティア A
  • 再現手順がある Issues/Discussions → ティア A（バグの存在を示す場合）
  • 無関係なユーザーのリポジトリ → ティア B
• ベンチマーク：
  • 独立しており、再現可能で、手法が開示されている → ティア S
  • 中立的な第三者による公式ベンチマーク → ティア A
  • ベンダー独自のベンチマーク → ティア B（偏りに注意）
• StackOverflow： 高い評価を得た承認済みの回答は、境界的にティア Aです。承認されていない回答はティア Bです
• ティア B の出典だけを引用してはいけません — ティア S または A の出典で裏付けてください

使用する場面

• テクノロジーの評価や比較
• 特定の主張の事実確認
• アーキテクチャの意思決定に関する調査
• 市場や競合の分析
• 「X は本当か？」の検証タスク
• 速度より正確さが重要なあらゆる質問

使用しない場面

• 創作やブレインストーミング（swing-options を使用してください）
• コードの実装
• 内部知識から高い確信を持って答えられる簡単な質問
• 検証可能な答えのない、意見に基づく質問

注意点

1. URL を決して捏造しないでください。 検索しても何も見つからない場合は、「未検証（出典なし）」と伝えてください。もっともらしい URL を推測してはいけません。出典の捏造は信頼をすべて失わせます。
2. 同じ研究を引用する記事が2つあっても、出典は1件です。 主張の根拠をたどってください。5つのニュースサイトが引用するプレスリリースも、出典は5件ではなく1件です。
3. ベンダーのベンチマークはティア A ではなく、ティア B です。 公式のエンジニアリングブログであっても、自社製品をベンチマークする際には偏りがあります。その偏りを明示してください。
4. 曖昧な表現はラベル付けの代わりにはなりません。 「たぶん」、「〜のようです」、「おそらく」は禁止です。主張は検証済み（独立した出典が2件以上）であるか、未検証／意見が分かれるという明示的なラベルを付けてください。
5. 検証マトリックスを省略しないでください。 検証マトリックスは説明責任を果たすためのものです。これがなければ、レポートは厳密に見えても監査の記録がありません。

統合に関する注意

• swing-clarify との併用： あいまいな依頼では、このスキルを実行する前に swing-clarify を実行してください。範囲を明確にすると、より良い結果が得られます。
• swing-review との併用： 調査結果を敵対的レビューに活用し、結論をストレステストできます