ln-811-algorithm-optimizer

パス： ファイルパス（shared/、references/、../ln-*）は、skills リポジトリのルートからの相対パスです。CWD に見つからない場合は、この SKILL.md ディレクトリを探し、1 階層上をリポジトリのルートとして使用してください。

ln-811-algorithm-optimizer

タイプ： L3 ワーカー カテゴリ： 8XX 最適化 親： ln-810-performance-optimization-coordinator

自動リサーチループを通じて対象関数のパフォーマンスを最適化します。ベースラインのベンチマークを確立し、ベストプラクティスを調査し、3～7 個の仮説を生成して、それぞれを適用し、保持／破棄を検証します。

---

概要

項目	詳細
入力	target_file + target_function（または ln-650 の監査結果）
出力	ベンチマークで効果を実証した最適化済み関数、最適化レポート
パターン	自動リサーチ：変更 → ベンチマーク → 保持（≥10％）／破棄

---

ワークフロー

フェーズ： 事前確認 → ベースライン → 調査 → 仮説の生成 → 最適化ループ → レポート

---

フェーズ 0：事前確認

確認項目	必須	見つからない場合の対応
対象ファイルが存在する	はい	最適化をブロック
対象関数を特定できる	はい	最適化をブロック
テスト基盤	はい	最適化をブロック（ci_tool_detection.md を参照）
対象関数のテストカバレッジ	はい	ブロック — カバレッジがなければ安全網がありません
Git のクリーンな状態	はい	ブロック（元に戻すためにクリーンなベースラインが必要）
ベンチマーク基盤	いいえ	ベンチマークを生成（references を参照）

必ず読み込む： shared/references/ci_tool_detection.md を読み込みます。Benchmarks + Test Frameworks セクションを使用してください。

カバレッジの検証

最適化を開始する前に、対象関数にテストカバレッジがあることを確認します。

手順	対応
1	テストファイルで対象関数名、または対象モジュールからのインポートを検索する
2	対象を参照するテストが 1 件以上ある場合 → 続行
3	対象を参照するテストが 0 件の場合 → 「no test coverage for {function}」としてブロック

テストカバレッジがなければ、ベンチマークの改善は意味がありません。最適化された関数が誤った結果をより速く返す可能性があります。

ワークツリーとブランチの分離

必ず読み込む： shared/references/git_worktree_fallback.md を読み込みます。ln-811 の行を使用してください。

すべての作業（編集、ベンチマーク、KEEP コミット）はワークツリー内で行います。メインのワークツリーは決して変更しないでください。

---

フェーズ 1：ベースラインの確立

手順 1.1：ベンチマークを検出または生成する

状況	対応
既存のベンチマークが見つかった	そのまま使用
ベンチマークが存在しない	最小限のベンチマークを生成（benchmark_generation.md を参照）

手順 1.2：ベースラインを実行する

パラメーター	値
実行回数	5
指標	実行時間の中央値
ウォームアップ	1 回実行し、結果を破棄
出力	baseline_median、baseline_p95

ベースラインの結果を保存します。すべての改善はこの結果を基準に測定します。

---

フェーズ 2：ベストプラクティスの調査

必ず読み込む： MCP ツールチェーンについて shared/references/research_tool_fallback.md を読み込みます。

調査戦略

優先度	ツール	クエリテンプレート
1	mcp__context7__query-docs	"{language} {algorithm_type} optimization techniques"
2	mcp__Ref__ref_search_documentation	"{language} {function_name} performance best practices"
3	WebSearch	"{algorithm_type} optimization {language} benchmark {current_year}"

調査結果

対象関数に適用できる最適化手法を収集します。各手法について、次の点を記録します。

• 名前と説明
• 期待される改善のカテゴリ（アルゴリズム計算量、メモリ、キャッシュ、並列処理）
• 適用条件（データサイズ、構造、言語機能）

---

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

仮説の情報源

必ず読み込む： カテゴリのチェックリストとして optimization_categories.md を読み込みます。

情報源	優先度
調査結果（フェーズ 2）	1
最適化カテゴリのチェックリスト	2
コード分析（対象に含まれるアンチパターン）	3

仮説の形式

フィールド	説明
id	H1、H2、... H7
category	optimization_categories.md に記載
description	変更内容
expected_impact	改善率の推定値（%）
risk	低／中／高
dependencies	この仮説が依存する他の仮説

順序

次の順に並べ替えます：expected_impact DESC, risk ASC。依存関係のない独立した仮説を先にします。

---

フェーズ 4：最適化ループ（採用／却下）

仮説ごとのサイクル

FOR each hypothesis (H1..H7):
  1. APPLY: Edit target function (surgical change, function body only)
  2. VERIFY: Run tests
     IF tests FAIL (assertion) → DISCARD (revert) → next hypothesis
     IF tests CRASH (runtime error, OOM, import error):
       IF fixable (typo, missing import) → fix & re-run ONCE
       IF fundamental (design flaw, incompatible API) → DISCARD + log "crash: {reason}"
  3. BENCHMARK: Run 5 times, take median
  4. COMPARE: improvement = (baseline - new) / baseline * 100
     IF improvement >= 10% → KEEP:
       git add {target_file}
       git commit -m "perf(H{N}): {description} (+{improvement}%)"
       new baseline = new median
     IF improvement < 10%  → DISCARD (revert edit)
  5. LOG: Record result to experiment log + report

安全ルール

ルール	説明
範囲	対象関数の本体のみ。シグネチャの変更は禁止
依存関係	新しいパッケージのインストールは禁止
元に戻す	却下時は git checkout -- {target_file} を実行
時間制限	すべての仮説を合わせて合計 30 分
複合	各採用案を次の仮説の新しいベースラインにする
追跡可能性	採用案ごとに、仮説 ID をメッセージに含めて個別の git コミットを作成
分離	すべての作業を分離された worktree で行い、メイン worktree は決して変更しない

採用／却下の判断

条件	判断	対応
テスト失敗	却下	元に戻し、理由を記録
改善率 ≥ 10%	採用	ベースラインを更新
改善率 10～20% だが複雑さが増す	レビュー	「わずかな改善＋複雑化」として記録し、却下を優先
改善率 < 10%	却下	元に戻し、「改善が不十分」として記録
速度低下	却下	元に戻し、低下量を記録

シンプルさの基準（autorresearch に準拠）： 改善がわずか（10～20%）で、変更によってコードの複雑さが大幅に増す場合（行数が 50% 以上増加、深くネストしたロジック、読みにくい構文など）は、却下を優先します。パフォーマンスがほぼ同等なら、よりシンプルなコードを選びます。

---

フェーズ 5：結果の報告

レポートのスキーマ

フィールド	説明
target	ファイルパス＋関数名
baseline	元のベンチマーク中央値
final	採用した最適化をすべて適用した後の最終中央値
total_improvement	改善率
hypotheses_tested	テストした仮説の合計数
hypotheses_kept	採用した最適化の数
hypotheses_discarded	却下した数＋理由
optimizations[]	採用した各項目：id、category、description、improvement%

実験ログ

{project_root}/.optimization/ln-811-log.tsv に書き込みます：

列	説明
timestamp	ISO 8601
hypothesis_id	H1..H7
category	optimization_categories.md に記載
description	変更内容
baseline_ms	この仮説を試す前のベースライン中央値
result_ms	変更後の新しい中央値
improvement_pct	変化率
status	keep / discard / crash
commit	Git コミットハッシュ（採用した場合）

既存のファイルがある場合は追記します（複数回の実行にわたる追跡が可能になります）。

クリーンアップ

対応	条件
生成されたベンチマークを削除	ベンチマークが自動生成され、採用した最適化がない場合
生成されたベンチマークを保持	最適化を 1 つでも採用した場合（改善の証拠）

---

設定

Options:
  # Target
  target_file: ""
  target_function: ""

  # Benchmark
  benchmark_runs: 5
  improvement_threshold: 10    # percent
  warmup_runs: 1

  # Hypotheses
  max_hypotheses: 7
  min_hypotheses: 3

  # Safety
  time_budget_minutes: 30
  allow_new_deps: false
  scope: "function_body"       # function_body | module

  # Verification
  run_tests: true
  run_lint: false

---

エラー処理

エラー	原因	解決策
ベンチマークフレームワークがない	ci_tool_detection.md にスタックの記載がない	インラインベンチマークを生成
すべての仮説を却下	有効な最適化が見つからない	「改善が見つかりませんでした」と報告
ベンチマークのノイズが大きすぎる	計測時間が一定しない	実行回数を 10 回に増やし、p50 を使用
テストの不安定化	テストが非決定的	1 回再実行し、再び不安定になった場合は仮説をスキップ

---

参考資料

• benchmark_generation.md
• optimization_categories.md
• shared/references/ci_tool_detection.md（ベンチマークのセクション）
• shared/references/research_tool_fallback.md

---

完了の定義

• 最適化の前に、対象関数のテストカバレッジを確認する
• 対象関数を特定し、ベースラインのベンチマークを確立する（5 回実行し、中央値を採用）
• MCP ツールチェーン（Context7/Ref/WebSearch）を通じて調査を完了する
• 仮説を 3～7 件立て、期待される効果の大きい順に並べる
• 各仮説を検証する：適用 → テスト → ベンチマーク → 採用／破棄
• 採用した最適化はそれぞれ、仮説 ID を付けた別個の git コミットにする
• 採用した最適化を積み重ねる（それぞれが新たなベースラインになる）
• 複雑さが増す一方で効果が小さい（10～20%）場合は、シンプルさの基準に照らして検討する
• 採用した最適化をすべて適用した後、テストに合格する
• 実験ログを .optimization/ln-811-log.tsv に記録する
• ベースライン、最終値、改善率、仮説ごとの結果を含むレポートを返す
• 最適化を何も採用しなかった場合は、生成したベンチマークを削除する
• すべての変更を独立したブランチにまとめ、リモートにプッシュする

---

バージョン： 1.0.0 最終更新日： 2026-03-08