ln-812-optimization-researcher

パス： ファイルパス（references/、../ln-*）は、このスキルディレクトリからの相対パスです。

ln-812-optimization-researcher

タイプ： L3 ワーカー
カテゴリ： 8XX 最適化

プロファイラーが特定したボトルネックについて、競合ベンチマーク、業界標準、解決アプローチを調査します。実行担当者向けに、優先順位を付けた仮説を作成します。

---

概要

項目	詳細
入力	プロファイラーからのパフォーマンスマップ（実測値：ベースライン指標、ステップごとのタイミング、ボトルネック分類、最適化のヒント）
出力	業界ベンチマーク、解決策候補、優先順位を付けた仮説（H1..H7）
パターン	調査優先：競合 → 業界 → ローカルコードベース → 解決策 → 仮説

---

ワークフロー

フェーズ： 競合分析 → ボトルネックに特化した調査 → ローカルコードベースの確認 → 仮説の生成 → 調査レポート

---

フェーズ 1：競合分析

必ず読む： MCP ツールの優先順位チェーンを確認するため、references/research_tool_fallback.md を読み込みます。

目標

この種の操作における「良好」な状態を明らかにします。ユーザーが目標値を指定していない場合は、目標指標を定義します。

調査クエリ

目標	クエリテンプレート	ツール
業界ベンチマーク	"{domain} API response time benchmark {year}"	WebSearch
競合のパフォーマンス	"{competitor_type} {operation} latency"	WebSearch
標準的な期待値	"acceptable response time for {operation_type}"	WebSearch
フレームワーク固有のガイダンス	"{framework} {operation} performance best practices"	Context7 / Ref

出力

フィールド	説明
industry_benchmark	この種の操作で期待されるパフォーマンスの範囲
competitor_approaches	上位システムがどのように解決しているか（2～3 例）
recommended_target	推奨される目標指標（ユーザーが指定していない場合）
target_metrics	指標ごとの定量的な目標（下記参照）
sources	すべての調査結果の URL と日付

目標指標の調査

performance_map.baseline に含まれる各指標について、定量的な目標値を調査します。

指標	クエリテンプレート	ツール
wall_time_ms	"{domain} API response time benchmark {year}"	WebSearch
cpu_time_ms	"{framework} handler CPU time benchmark"	WebSearch
memory_peak_mb	"{domain} API memory usage benchmark {year}"	WebSearch
http_round_trips	"{domain} API call count optimization best practice"	WebSearch
io_bytes	"{domain} file processing throughput benchmark"	WebSearch

出力形式：

target_metrics:
  wall_time_ms:
    value: 500
    source: "industry benchmark: translation APIs p95 200-500ms"
    confidence: HIGH
  http_round_trips:
    value: 2
    source: "best practice: batch API reduces N calls to 1-2"
    confidence: HIGH
  memory_peak_mb:
    value: 128
    source: "similar workload: 64-128MB typical"
    confidence: MEDIUM

信頼度： HIGH = 出典付きのベンチマークが見つかった場合、MEDIUM = ベストプラクティスから導出した場合、LOW = 一般的なガイドラインから推定した場合。プロファイラーのベースラインに含まれる指標のみを記載してください。

---

フェーズ 2：ボトルネックに特化した調査

必ず読む： タイプごとのクエリテンプレートについて、research_query_templates.md を読み込みます。

調査戦略

プロファイラーが特定した主要なボトルネックのタイプに基づきます。

ボトルネックのタイプ	調査の焦点
アーキテクチャ	バッチ処理、パイプライン化、並列処理、DataLoader パターン
I/O-ネットワーク	コネクションプーリング、HTTP/2、多重化、キャッシュ
I/O-DB	クエリ最適化、インデックス、Eager Loading、一括操作
I/O-ファイル	ストリーミング、非同期 I/O、メモリマップファイル
CPU	アルゴリズムの代替案、ベクトル化、計算のキャッシュ、OSS への置き換え
キャッシュ	退避ポリシー、キャッシュキーの設計、無効化戦略、階層型キャッシュ、ウォームアップ
外部	キャッシュ層、サーキットブレーカー、フォールバック戦略、プロバイダーの代替案

調査プロトコル

FOR each top bottleneck (max 3):
  1. Select query templates from research_query_templates.md
  2. Execute research chain: Context7 → Ref → WebSearch (per research_tool_fallback.md)
  3. Collect solution approaches with expected impact
  4. Note technology prerequisites (libraries, infrastructure)

ソリューションの評価

項目	説明
solution	アプローチの名前／説明
source	情報源（URL、ドキュメントのセクション）
expected_impact	推定される改善（例：「N=9 の場合、9 倍削減」）
complexity	低／中／高
prerequisites	必要なもの（ライブラリ、インフラ、API サポート）
feasibility	HIGH / MEDIUM / LOW — 前提条件の利用可能性に基づく

---

フェーズ 3：ローカルコードベースの確認

外部のソリューションを推奨する前に、コードベースにすでにその機能があるか確認します。

確認項目	方法
クライアントクラスのバッチ／一括メソッド	クライアント／サービスクラス内で batch、bulk、multi を検索する
キャッシュのインフラ	redis、memcache、cache、@cached、lru_cache を検索する
接続プールの設定	設定内で pool_size、max_connections、pool を検索する
非同期版	メソッドの接頭辞／接尾辞で async_、aio、Async を検索する
未使用の設定	クライアント／サービスの設定から batch_size、max_connections パラメーターを確認する

実現可能性への影響

判明したこと	影響
バッチ API が存在するが、使用されていない	実現可能性 = HIGH、複雑さ = LOW
キャッシュのインフラは存在するが、この経路向けに設定されていない	実現可能性 = HIGH、複雑さ = LOW-MEDIUM
既存の機能がなく、新しいライブラリが必要	実現可能性 = MEDIUM、複雑さ = MEDIUM-HIGH
インフラの変更が必要	実現可能性 = LOW、複雑さ = HIGH

---

フェーズ 4：仮説の生成（3～7 件）

仮説の情報源（優先順位順）

優先度	情報源
1	ローカルコードベースの確認（未使用の既存機能 — リスクが最も低い）
2	調査結果（業界で実証済みのパターン）
3	プロファイラーによる最適化のヒント

仮説の形式

項目	説明
id	H1、H2、... H7
description	変更内容とその方法
bottleneck_addressed	対応するタイムマップ上のボトルネック（ステップの参照）
expected_impact	推定される改善率または倍率
complexity	低／中／高
risk	低／中／高
files_to_modify	変更が必要なファイルの一覧
dependencies	依存する他の仮説（例：「H2 は H1 が必要」）
conflicts_with	この仮説が成功した場合に不要になる仮説

バイアスチェック（最終決定前に必須）

バイアス	確認項目	例
削除バイアス	「X を削除する」という各仮説について、対になる「X を最適化する」という代替案を生成する	「アラインメントを削除する」→「アラインメント設定も最適化する」
業界バイアス	「業界で X が使われていない」≠「私たちにも X は不要」。確認事項：私たちの製品に必要か？	「CAT ツールではアラインメントを省略するが、私たちのユーザーは品質のために必要としている」
性急な結論	「X は遅い」≠「X は間違っている」。遅さの原因は、アプローチではなく実装の問題かもしれない	アラインメントに 5.9 秒 → アルゴリズムが間違っているのであって、機能自体が間違っているわけではないかもしれない

ルール： 機能を「削除する」すべての仮説には、必ず対になる「機能を最適化する」仮説を用意してください。

修正の階層（必須の順序）

修正レベルに従って仮説を並べます。必ず上位のレベルから試します。

レベル	例	優先度
1. 設定	matching_methods="i"、pool_size=10	最高 — 最初に試す
2. インフラ	キャッシュレイヤーの追加、サービスのスケール
3. フレームワーク	フレームワークの機能を使用する（バッチ API、組み込みキャッシュ）
4. アプリケーションコード	アルゴリズムのリファクタリング、最適化の追加
5. 機能の削除	機能の削除	最低 — 最終手段のみ

危険信号： 優先度が最も高い仮説がレベル 4～5 にある場合は、見直してください。レベル 1～3 のソリューションを見落としていませんか？根本原因に対して「5 つのなぜ」を適用し、検証してください。

順序ルール

次の順に並べます：fix_level ASC, expected_impact DESC, complexity ASC, risk ASC。

競合の検出： H1（バッチ API）が N+1 問題を解決する場合、H3（並列呼び出し）は不要になります。H3.conflicts_with = ["H1"] と設定します。

依存関係の検出： H2（キャッシュの先読み）が H1（バッチ API）を基盤とする場合、H2.dependencies = ["H1"] と設定します。

---

フェーズ 5：調査レポート

レポートの構成

research_result:
  industry_benchmark:
    metric: "response_time"
    expected_range: "200-500ms"
    source: "..."
  recommended_target: 500          # ms — alias for target_metrics.wall_time_ms.value
  target_metrics:                  # per-metric quantitative targets
    wall_time_ms: { value: 500, source: "...", confidence: HIGH }
    http_round_trips: { value: 2, source: "...", confidence: HIGH }
    memory_peak_mb: { value: 128, source: "...", confidence: MEDIUM }
  competitor_analysis:
    - name, approach, metric, source
  solution_candidates:
    - solution, source, expected_impact, complexity, feasibility
  hypotheses:
    - id, description, bottleneck_addressed, expected_impact, complexity, risk,
      files_to_modify, dependencies, conflicts_with
  local_codebase_findings:
    - "Batch API exists: AlignmentClient.batch_align() — accepts up to 50 pairs"
    - "Redis configured but not used for alignment cache"
  research_sources:
    - url, date, relevance

---

プランモード

読み取り専用ワーカー — すべてのフェーズで MCP 調査ツール（Ref、Context7、WebSearch）とコード分析のみを使用します。Skill() 経由でプランモードのまま通常どおり実行します。

---

エラー処理

エラー	復旧方法
すべての調査ツールが失敗する	免責事項「外部ソースによる検証なし」を添えて、組み込み知識を使用します
競合ベンチマークが見つからない	業界ベンチマークを省略し、「ベースラインが見つからないため、一般的なガイドラインを使用」と記載します
仮説を生成できない	空のリストを返します — 次のステップはコーディネーターが決定します
ローカルコードベースの確認で何も見つからない	外部調査の結果のみを使用して続行します

---

参考資料

• research_query_templates.md — ボトルネックの種類ごとのクエリテンプレート
• references/research_tool_fallback.md — MCP 調査ツールの優先順位チェーン

---

実行時サマリーアーティファクト

必須の読み込み： references/coordinator_summary_contract.md を読み込みます

optimization-worker サマリーエンベロープを出力します。

管理モード：

• ln-810 は決定論的な runId と正確な summaryArtifactPath を渡します
• サマリーを指定された summaryArtifactPath に書き込みます

スタンドアロンモード：

• runId と summaryArtifactPath は省略します
• .hex-skills/runtime-artifacts/runs/{run_id}/optimization-worker/ln-812--{identifier}.json に書き込みます

完了の定義

• 競合分析を完了している（業界ベンチマーク、競合他社のアプローチ）
• ベースライン指標ごとに目標指標を調査している（値、ソース、信頼度）
• 目標指標を定義している（ユーザー指定または調査から導出）
• MCP チェーンを通じてボトルネックに特化した解決策を調査している
• ローカルコードベースを確認し、既存の未使用機能を調べている
• 3～7 件の仮説を生成し、期待される影響の大きい順に並べている
• 仮説間の依存関係と競合を特定している
• ソースを含む調査レポートを作成している
• 最適化調査アーティファクトを共有場所に書き込んでいる

---

バージョン： 2.0.0 最終更新日： 2026-03-14