perf-optimize-workflow

パフォーマンス最適化ワークフロー

強い依存関係（frontmatter）：clarifying-question-discipline（1 ターンにつき質問は 1 つ）、known-issue-research（特定ステージで既知のパフォーマンスパターンをすばやく検索）。いずれかが不足している場合は中止し、次を出力します：npx skills add FuDesign2008/open-skills -g --skill '*' --yes。

実行時の強い依存関係（frontmatter ではなく環境）：ステージ 5～6 の反復ループを実行するループランナー機能。ステージ 5 の開始時に検出します。不足している場合、最適化の実行を停止します（「反復ループ」を参照）。

対象範囲

このワークフローは、パフォーマンス最適化のパラダイム全体を担います。再現可能なベンチマークを構築し、すべての結論を証拠の妥当性チェックに通し、処理チェーン全体に沿ってボトルネックを特定し、各反復で最適化対象を 1 つに絞り、A/B の複数実行統計で検証し、結果をベンチマークログに蓄積します。最適化↔検証サイクルは、環境が提供する反復ループで実行します（利用できない場合は、正直に停止します）。プロジェクトごとの成果物は、ベンチマークログとハーネス、および進化し続けるプロジェクトレベルのスキル 2 つ（原因特定用の code-insight と最適化用の code-optimizer）です。これらのスキルはスタックとプロジェクトの知識を蓄積し、キャンペーンを重ねるごとに改善されます。

このワークフローでは、どの高コストな処理が、どの条件で、どのデバイス上で実行されるのかを特定し、それを測定可能な形で取り除きます。リリースやロールアウトの判断はプロジェクトに属し、このワークフローの対象ではありません。

パラダイムの由来：異なるスタックで実施した 2 つの完全なキャンペーンから抽出したものです（ネイティブ C++ ツールチェーン：ワークロードが 29.4 秒から 6.7 秒に短縮、-77％、出力はバイト単位で同一。大規模な Web リッチテキストエディター：コミット時間 -27％／レンダリング量 -31％／メモリ -34％に加え、複数年にわたるユーザーのカクつきの原因を 4 つの経路で特定）。以下のステージは、両方のキャンペーンがたどった、スタックに依存しない骨格です。

レイヤー構成

レイヤー	配置先	変更のタイミング
パラダイムと証拠に関する規律（このファイル）	SKILL.md	まれ — 振る舞いに関する契約であり、意図的にバージョン管理します
プロジェクトの原因特定／最適化スキル	プロジェクトのエージェントスキルディレクトリ（code-insight、code-optimizer）	キャンペーンごと — コーパスを元に作成し、キャンペーンの教訓を反映して進化させます
スタックコーパス（シードテンプレート＋証拠事例アーカイブ）	reference.md	たまに — スタックごとの章と事例を更新します

パラダイムは長く有効です。プロジェクトスキルはキャンペーンのたびに蓄積されます（スタックとプロジェクトの知識が蓄積される場所です）。コーパスはシードにすぎず、たまに更新する必要があります。時間の経過で古くなる内容は、このファイルに含めないでください。

トリガーの認識

トリガー語（それぞれワークフローを開始します。「トリガー＋コロン＋スペース＋説明」の形式では、指定されたステージから直接開始します。コロンとスペースの句読点は言語に依存しません）：

• **「パフォーマンス分析」／「パフォーマンスの問題」／「カクつき」／「とても遅い」**または英語の同等表現（「performance issue」、「it's slow」、「jank」）→ ステージ 1 から開始
• 「パフォーマンスの証拠」 → ステージ 1：ベンチマークと証拠
• 「パフォーマンスの原因特定」／「パフォーマンスの詳細調査」 → ステージ 2：ボトルネックの特定（「パフォーマンスの詳細調査」はステージ 2 を継続／深掘り）
• 「パフォーマンス仮説」 → ステージ 3：根本原因の仮説立案
• 「パフォーマンスモニタリング」 → ステージ 4：切り替え可能なモニタリングの構築
• 「パフォーマンス最適化」 → ステージ 5：最適化
• 「パフォーマンス検証」 → ステージ 6：A/B 検証
• 「フロントエンドのパフォーマンス」／「フロントエンドのパフォーマンス最適化」／「Electron のパフォーマンス」 → ステージ 1 から開始。プロジェクトの code-insight／code-optimizer スキルが作成され、成熟するまでは、reference.md のフロントエンドコーパスを作業知識として使用します
• 「アーティファクトの調査」／「測定基準の調整」／「デバイスプロファイル」 → 証拠ゲートモード：以下の規律に沿って、疑わしい指標を監査してから判断に用います

分析用に提供されたパフォーマンス関連ログやプロファイルも、ステージ 1 または 2 から開始します。

基本原則

ベンチマークを先に作り、証拠のゲートを通過してから断定し、全体の処理経路に沿って原因を特定し、1 回の反復で対象は 1 つに絞り、A/B のクロス実行で判定し、否定的な結果も記録に残します。

1. データ駆動：測定する前に結論を出してはいけません。再現経路も分析可能なデータもない場合、最初に行うべきことは仮説を立てることではなく、再現経路またはデータを構築することです（ステージ 1）。
2. 証拠によるゲート：意思決定に用いるすべての指標は、まず「証拠の妥当性に関する規律」（以下のセクション）を満たす必要があります。意思決定の根拠として不十分な数値は参考にはできますが、断定の根拠にはできません。
3. 変数は 1 つ、再現可能に：各仮説は、既存のデータまたは最小限の対象を絞った計測によって、はい／いいえで判定できるものにします。各最適化で変更する根本原因の箇所は正確に 1 つとし、その効果を帰属できるようにします。結果は再現可能かつ反証可能でなければなりません。相関関係は因果関係ではありません。
4. 全体の処理経路を上から追う：ユーザーが体感する処理経路（マクロ）からホットスポット（ミクロ）へと進めます。まず遅い箇所（時間／リソースの占有率）を特定し、次に何が、どのような条件でその処理を引き起こすのかを特定します。木を見て森を見ない局所的な分析は避けてください。
5. 本番相当の品質とデバイスプロファイル：合格基準となる数値は本番相当のビルドから取得します。断定の根拠となる結論は、ハイエンドの開発者向けマシンだけでなく、デバイスプロファイルに合わせて調整した実行（CPU スロットリングマトリクス）から導きます。
6. 時期尚早な最適化はしない：測定済みで、ユーザーに影響があり、しきい値を超えている問題だけを最適化します。データのない予防的な最適化は、複雑さを増やすだけです。

• ⚠️ 積極的に確認してください：clarifying-question-discipline に従い、1 回のやり取りにつき質問は 1 つにします。明確になるまで複数回にわたって確認し、回答する前に不明点を解消してください。

ステージの流れ

順方向の流れ：証拠 → 特定 → 仮説立案 →（監視）→ 最適化 → 検証。目標を達成するか、費用対効果が見合わなくなるまで、最適化と検証を繰り返します。

よくあるステージの移行：

• ステージ 1 でデータが不足しており、まず監視を構築する必要がある場合 → ステージ 4 に進み、その後ステージ 1 に戻ります。
• ステージ 2 のデータですでにボトルネックが特定できている場合 → ステージ 3 を飛ばし、ステージ 4 または 5 に進みます。
• ステージ 6 で仮説が否定された場合 → ステージ 2 または 3 に戻ります。最適化が不十分だった場合 → ステージ 5 に戻ります。
• 断続的な問題を捉えるのが難しい場合 → ステージ 4 の長期監視を優先し、再現した時点で戻ります。

---

証拠の妥当性に関する規律

厳格なゲートです。パフォーマンスに関する結論は、以下の確認項目を通過した後にのみ、最適化の判断に利用できます。落とし穴は 4 つに分類されます。測定アーティファクト（環境やツールが数値を歪めている）、品質水準の汚染（数値自体は正しいものの、別の対象を測定している）、デバイスプロファイルの不一致（数値は正しいものの、不満が寄せられていないマシンでのみ発生している）、比較環境の状態の無効性（A/B 判定自体が汚染された環境で行われている）。実際の数値を含む匿名化済みの事例アーカイブ全体は、reference.md のパート 4 を参照してください。 | # | 分野 | 1 行ルール | |---|-----------|---------------| | 1 | 環境によるスロットリングのアーティファクト | 制御されたランタイム（ヘッドレス／オクルージョン状態／バックグラウンド状態）でのフレーム／スケジューリングクラスの指標は、そうでないと証明されるまでは無効です。バックグラウンドでのスロットリングにより、フレームコールバックが桁違いに制限されることがあり、フォーカスのエミュレーションでも解除されません。疑わしい時間帯にエグゼキューターをサンプリングして検出します（アイドル状態が大半を占める ⇒ アーティファクト）。代わりに同一タスク内で測定します（刺激と測定を同じスケジューリング単位にまとめることで、ランタイムがその間に処理を遅らせられないようにします）。 | | 2 | モニターによる自己汚染 | 計測用ビルドは本番環境と数倍異なることがあります（モニターのオーバーヘッド＋未最適化コード）。開発環境の計測値は相対的な A/B 傾向の確認にのみ使用し、最適化の判断には本番環境の計測値を使用します。ランタイムネイティブの指標と食い違う場合は、ランタイムを優先します。 | | 3 | フレームワークカウンターの曖昧さ | フレームワーク内部の統計値は、信頼する前に小規模に監査します（独立したカウントをネイティブ指標と照合します）。規模に矛盾がある場合、アーティファクトなのはカウンターです。カウンターは傾向を示すシグナルであり、断定の根拠にはなりません。 | | 4 | デバイスプロファイルのキャリブレーション | 断定できる結論には、CPU スロットリングのマトリックス（例：1x／8x／20x）×パス×スケールが必要です。スロットリングなしでの「問題なし」という判定は、ローエンドユーザーには当てはまりません。1 つのワークロードでも、セルによって 3 通りの判定が生じることがあります。 | | 5 | 入力イベントの真正性 | 合成入力の負荷ではすべて、観測可能な状態の差分（実際に生じた変化 == 意図した変化）を検証する必要があります。製品の実際の入力パイプラインを迂回する合成キー／スクロールイベントは、ドライバーが成功を報告していても無効です。 | | 6 | 計測トグルのライフサイクル | ロード時に読み取られるトグルは、製品スクリプトの読み込み前に（デバッグプロトコルのプリロード注入機能を使って）注入する必要があります。遅延コールバックで終了する測定区間は環境のスロットリングを引き継ぐため（分野 1）、フェーズの結論には同期区間とネイティブの長時間処理カウンターを使用します。 | | 7 | 単一サンプルからの外挿禁止 | 開発者のマシンのデータはユーザープロファイルではありません。ROI がマイナスという結論には、ユーザープロファイルの証拠（集約テレメトリー／サポートフィードバック／実地データ）が必要です。1 つのアカウントから外挿することはできません。 | | 8 | 究極の対照実験 | プロファイラーでコードのホットスポットが見つからない場合（ランタイム内部処理が支配的な場合）、実際のシーンを純粋な静的コピーに複製し（同じ環境、製品ロジックなし）、同じ条件で同じ負荷を実行します。コピー ≈ 元のシーンなら、全体の負荷はコンテンツの規模 × 環境による物理的なコストであり、最適化の方向性はその基本コストの削減へと移ります。差分が製品コードの占める分です。これはコードレベルで最適化できる上限です。アブレーションに関する注意：「仕組みが存在する ≠ 仕組みが機能する」 | | 9 | 否定的な結果にも痕跡を残す | 汚染されたベンチマークログの行には、無効化の警告（何が、なぜ無効か、正しい計測環境は何か）を記録します。除外記録があれば、後から読む人が行き止まりをたどり直したり、誤った数値を引用したりするのを防げます。 | | 10 | 比較環境の状態の妥当性 | 交互に実行する A/B 比較では、両方の条件が同じ環境を見ることが前提です。コード切り替え後のホットリロード状態（旧モジュールと新モジュールの混在、シングルトンの重複、古い登録情報）は、片方の条件を体系的に汚染します。構造単位（モジュール／シングルトンのトポロジー）に触れる変更では、判定を有効とみなす前に、条件間で環境をリセット（再起動／ハードリフレッシュ）する必要があります。 |

ゲートルール：いずれの指標でも、その落とし穴を扱う分野の問題が解決していない場合、その指標は判断の根拠として使用できません。傾向のみを示す参考情報として提示することはできますが、最適化の選択、優先順位、合否判定を左右してはなりません。

---

ステージ 1：ベンチマークと証拠（性能証拠）

目標

曖昧な「動作が遅い」を、定量化されたベースラインと目標値／レッドラインを備えた、再現可能で標準化され、記録されたワークロードに変えます。1 回限りの手動再現で終わらせてはいけません。ベンチマークハーネスがすでにある場合は実行し、ない場合は最小限のものを構築します。後続のすべてのステージが再現可能な数値に依存するためです。

確認が必要な情報

• 症状：どの操作（クリック／スクロール／入力／開く／IME…）で、どのように「遅い」のか（カクつき／空白／スピナー／応答なし）を、可能な限り定量化します。問題の分析境界（開始点と終了点）を明確にします。
• 利用可能なデータ：既存のログ／プロファイル／計測機能はありますか。ない場合は、どの環境でどの方法を使えばデータを取得できるかを確認します。
• 再現性：常に発生するか、断続的に発生するか。データ量／デバイスクラス／継続時間の要件も確認します。

ベンチマークハーネスの要件（構築する場合）

• シナリオ一覧に基づいて計画した標準化ワークロード：まずプロジェクトのユーザーシナリオ一覧（実際の利用シナリオ全体と、その網羅状況）を作成するか読み込みます。ハーネスと同じ場所（例：SCENARIOS.md）に保存し、次に不足を補うスクリプト化された負荷を計画します（開く × 規模、入力 × 文字数、スクロール × 回数、切り替え、長時間のセッション編集、IME、貼り付けなど）。各負荷は実際の入力経路（規律 5）を通じて実行し、コンテンツの差分で検証できるようにします。
• 長時間セッションでの劣化は独立した問題クラスです：短時間のセッションでは単一操作のコストが明らかになりますが、継続的な編集／ノートの切り替え／履歴の増加では累積的な劣化（メモリの増加、レイテンシ傾向の上昇、Undo 履歴の肥大化）が明らかになります。専用の負荷（セッション／切り替え／履歴クラス）でこれを網羅し、単一実行の数値ではなく、傾向の傾きと変曲点で分析します。
• プローブスクリプトのパターン：繰り返し発生する原因特定の問いはすべて、ハーネス配下の再利用可能なプローブスクリプトとして蓄積します（命名規則は probe-*。プロファイラーのサンプリング、フェーズ分割の計測、カウンター監査、スロットル行列ドライバーなど）。プロジェクトの code-insight のパイプラインステップでは、場当たり的なスクリプトではなくプローブを呼び出します。最初のキャンペーンで初期プローブ一式を用意し、以降のキャンペーンで拡張します。
• 自動キャプチャ：メトリクス収集は一度配線して、毎回再利用します。手動でコピー＆ペーストする方式は避けてください。コンソール／ログの解析と、構造化された JSON アーカイブを推奨します。
• まずベースラインを取得：変更を加える前に最適化前のベースラインを記録します。以降のすべての主張は、ベースラインとの比較に基づくものとします。
• ベンチマークログ：リポジトリのルートに追記専用ファイル（例：BENCHMARK.md）を置き、すべての実行について、日付、コミット、ワークロード、規模、主要メトリクス、注記を記録します。このログがキャンペーンの記録となり、判定、撤回、無効化のすべてをここに残します（ステージ 6）。
• A/B 判定：実行間の統計的な判定機能を構築するか再利用します（ステージ 6 を参照）。「改善したか」を数値 2 つの目視比較で判断してはなりません。

エビデンスゲート（このステージの数値を外部に出す前に）

以降に使用するすべてのメトリクスについて、ファイル内の規律 1（スロットリングによる成果物）、2（モニターによる自己汚染）、5（入力の真正性）、6（トグルのライフサイクル） をクリアしてください。ゲートを通過しなかった数値には「傾向のみ」の印を付けます。

出力

• 利用可能／不足しているデータ。不足している場合は、具体的な取得手順（誰が何を実行し、何を取得するか）。
• 推奨する出力：構造化された問題定義 — 症状（定量値）、再現条件、分析境界、ベースライン、目標しきい値／限界値。
• ベンチマークハーネスの状況：既存／このステージで構築／理由を明記して保留。

---

ステージ 2：ボトルネックの特定（性能定位）

目標

データに見られる異常（誰が、いつ、どれだけの時間／リソースを消費したか）を見つけ、トリガーの連鎖全体を追跡し、主要なセグメントを 1～2 個に絞り込みます。判断を支えるすべての数値について、すでにエビデンスゲートを通過している必要があります。

プロジェクト帰属スキル（code-insight）

スタック／プロジェクト固有の帰属パイプラインは、プロジェクトレベルのスキルとしてこのワークフローが作成し、継続的に改善します。パラダイムファイルは汎用のままです。

• ステージ開始時に確認する：プロジェクトの慣例的なエージェントスキルディレクトリに、プロジェクトの code-insight スキルがあるか確認します。見つかった場合は、このステージのローカライズ作業でそのパイプラインを実行し、対応できなかった不足点を記録します。その不足点が、このキャンペーンで改善する候補です。見つからない場合（初回キャンペーン）は、ステップごとのパイプラインとして作成します。reference.md のパート5にある帰属パイプラインのテンプレート（現在はJSスタック）を基に、この実行で得られたプロジェクトの発見事項（ツールのパス、ワークロードの詳細、既知の落とし穴、ハーネス内の初期 probe-* スクリプト）に合わせて調整します。パート1〜2は、各パイプラインのステップでナレッジの添付資料として使用します。反映する前に、内容を専門家の視点で確認します。手動モードでは作成場所を確認し、自動モードではプロジェクトの慣例に従います。
• 作成したスキルは、プロジェクトにおける継続的な資産です。このワークフローとは独立して、後続のセッションやプロジェクトに参加する他のエージェントから直接呼び出せます。

分析アプローチ

1. 全経路のトポロジー：ユーザー操作から問題の終端まで（コード実行、システムコール、ネットワーク／ストレージ）の経路を、抜けや重複なくセグメントに分けます。各セグメントは個別に計測できる必要があります。
2. 2次元での記録：時間（セグメントごとの所要時間／割合）とリソース（CPU／メモリ／I/O／ネットワーク）を記録します。どちらも省略しません。リソース使用率が70%を超えると、一般的に警告ラインとなり、それを超えると応答時間が非線形に増加します。
3. 初期スクリーニング：時間の割合でセグメントを順位付けします（例：20%超は高コスト）。リソースの異常（飽和、継続的な増加、エラー率）にフラグを立て、低コストかつリソースが正常なものを除外します。

帰属手法（データに応じて選択）

• テキストログ：キーワード／所要時間／エラーコードで絞り込み、抜粋とスタックを確認します。
• プロファイル：幅の広いバー／割合の高い領域から確認し、関数／コンポーネントへ掘り下げます。レンダリングが支配的な場合は、エディター／ウェブアプリを4つに分類します：フレームワークのコミット／スタイルの挿入／レイアウト／ペイント。それぞれ修正方法がまったく異なるため、「レンダリング」をひとまとめにして捉えないでください。
• 強制リフローの読み取り（書き込み→読み取りのパターン。リッチテキストエディターでは、DOM の変更直後に選択範囲の境界を読み取ることが、典型的な最大の原因です）。
• JS のホットスポットがない（(program)／(idle) が支配的）場合は、ディシプリン8の静的コピー対照実験で判断します。コストの原因がプロダクトコードか、DOM規模による物理的コストかを判定できます。この単一の実験で、何年も続いた議論に決着がつくことがあります。
• 既知パターンのクイック検索：known-issue-research のトリガーが発動したら、それを読み込み、詳細な独自分析に入る前に、そのパフォーマンスパターン版を実行します。

エビデンスの判定基準

ディシプリン**3（カウンター監査 — 使用前にフレームワーク内部の統計を監査する）と8（対照実験）**をここで適用します。

出力

• 異常の要約（低速／大容量／高頻度と、その発生箇所）。原因の連鎖「操作 → … → ボトルネック」を一文または図で示します。
• 予備仮説を1〜3個挙げ、それぞれを裏付ける／反証するエビデンスを明記します。中核となるボトルネックセグメントの一覧（1〜2件）とその割合を示します。

---

ステージ3：根本原因を仮説化する（性能仮説）

目標

異常を、一般的なパターンに分類した検証可能かつ反証可能な根本原因の仮説へと整理し、ユーザーへの影響度 × 検証コストで順位付けします。

推論の参考情報

• USEメソッド（リソースのボトルネック）：使用率／飽和／エラー。
• REDメソッド（実行／リクエストのボトルネック）：レート／エラー／所要時間。
• 一般的なパターンの表（応答範囲が広すぎる、更新がバッチ化されていない、高頻度のトリガー、一斉に発生するバックログ、リソースリーク、同期的なブロッキング、重複した計算）：このファイルのパラダイムに汎用的な形式が、reference.md に具体的なフロントエンドでの現れ方が記載されています。

根拠の確認

規律 **7（単一サンプルからの外挿禁止 — 「ユーザーはこれに遭遇しない」にはユーザープロファイルの根拠が必要です）**と、規律 **4（スロットル適用マトリクス — ユーザーが感じるカクつきに関する仮説は、調整済みのセルで検証します）**が適用されます。

出力

• 最も可能性の高い仮説を1～2件。それぞれ、はい／いいえで判定できるもの（「全体が再レンダリングされているか？」は回答できますが、「コードの書き方が悪い」は回答できません）とし、順位を付けます。検証方法（既存データ、またはステージ4で追加する監視ポイント）も示します。

---

ステージ4：切り替え可能な監視機能の構築（性能监控）

目標

既存のデータでは仮説を検証できない場合、クリティカルパス上に切り替え可能で本番環境向けの可観測性を追加します。コードは恒久的に残し、実行時に有効・無効を切り替えます。

設計原則

1. 切り替えで制御（環境変数／設定／フィーチャーフラグ／デバッグスイッチ）：本番環境でオフの場合は、出力もサンプリングもなく、オーバーヘッドは無視できる程度です。オンの場合は、既存のログに沿った構造化出力を行います。
2. 一時的ではなく恒久的：後で削除する計測コードではなく、常設の機能にします。
3. 関連付け可能：安定したタイムスタンプと位置識別子を使用し、既存のログ／プロファイルと同一のタイムラインで結合できるようにします。
4. 必要最小限：位置、タイムスタンプ、仮説を確認または否定するための主要な変数だけを記録し、プロジェクトのログ形式を再利用します。
5. 切り替えのライフサイクル：モジュールの読み込み時に参照される切り替え設定は、ページスクリプトより前に注入します（規律6）。

ポイントの選定

まず直接のトリガーポイント（状態更新／リクエストの実行／再計算の開始点）を選び、次に中間の連鎖ノード（呼び出し順序／頻度）、その後、コストの高い計算の開始点と終了点（呼び出しごとの所要時間／回数）を選びます。

出力

監視ポイントの一覧（ファイル：行または関数、目的、切り替え名）に加え、有効化、再現、記録を行うためのユーザー操作を示します。根本原因をすでに確認できている場合は、ステージ5に進みます。

---

ステージ5：最適化（性能优化）

このステージとステージ6は、反復ループとして実行します（「反復ループ」を参照）。環境ゲートはこのステージの開始時に確認します。

目標

確認済みのボトルネックを解消または軽減する変更を実装します。1回の反復につき、対象とする根本原因は1つとし、影響度に応じた規模にします。

プロジェクトの最適化スキル（code-optimizer）

ライフサイクルは code-insight と同じです。ステージ開始時にプロジェクトの code-optimizer スキルを確認します。見つかった場合は、この対象の最適化パイプラインに従い、不足点を記録します。見つからない場合は、パート5のテンプレート（JS スタック）と今回の実行で得られた知見を基に、手順ごとのパイプラインとして初期化します。初期化するパイプラインには、プロジェクトの code-insight に委譲する詳細な原因特定の手順を必ず含めてください（両者は連携するパイプラインであり、独立したツールではありません）。このスキルには、このプロジェクトで検証済みの最適化パターンと、採用されなかった試みを蓄積し、最適化の取り組みを重ねるたびに、より適切な判断ができるようにします。

原則

• 症状ではなく根本原因を修正する：変更内容はステージ3のパターン（対象範囲を絞る、バッチ化する、スロットルする、キャッシュする、スレッド外に移すなど）に対応させ、漠然と「高速化する」だけにしないでください。
• 技術選定の判断はユーザーに委ねる：新しい依存関係の導入、データ構造の置き換え、割り当て／メモリ戦略の変更を行う場合は、トレードオフ（性能／移植性／保守性）とともに候補を提示し、ユーザーに選んでもらいます。エージェントが一方的に決定してはいけません。
• 1回の反復につき1つの対象：各コミットでは対象を厳密に1つだけ最適化し、レビューや差し戻しがしやすい変更にします。また、ステージ6で効果を明確に特定できるようにします。複数の有望な案がある場合は、別々の反復として順次実施します。
• レイヤーの優先順位（高→低）：ビジネスロジック → アプリケーションコード → フレームワーク／依存関係 → システム／ハードウェア。上位レイヤーを優先し、「変更コストが低く、効果が大きい」手法を選びます。
• 実行時間の割合による優先順位：割合が最も大きい箇所から最適化します。全体の10％未満を占める箇所を100倍に高速化しても、全体への効果はほとんどありません（アムダールの法則）。
• 安定性：意味上の変更を行わず、機能上のバグや新たな性能への副作用を発生させないでください。
• 効果がなければ元に戻す：ステージ6で変更が不採用となった場合は元に戻します（ベンチマークログにはマイナスの結果が残ります）。さらに推測に基づく変更を重ねてはいけません。

出力

変更一覧（ファイル、場所、概要）＋Stage 4 のモニタリングに沿った、Stage 6 の推奨検証シナリオ／メトリクス。

---

Stage 6：A/B 検証（性能検証）

このステージは通常、反復ループ内で実行します（「反復ループ」を参照）。1 回だけの実行が許されるのは、ユーザーが明示的に要求した場合に限られます。

目標

1. 仮説の判定を「はい」または「いいえ」で示します。
2. Stage 5 でコードを変更した場合は、副作用がなく、本番相当の条件で最適化が統計的に機能したことを証明します。証明できない場合は、変更を元に戻します。

エビデンスゲート

このステージで出すすべての判定には、単発の実行も含め、規律 2（本番相当の受け入れ基準）、4（スロットルマトリクスのセルに基づくユーザーのカクつき判定）、9（棄却と無効化の記録）、**10（構造単位を変更した場合、各実験群の間で環境をリセット）**が適用されます。

A/B のクロス実行統計判定

• 前回のコミットのビルドをベースラインとして保持します（コミットハッシュをキーにしたスナップショット）。
• システム負荷によるノイズが両方にほぼ均等にかかるよう、B₁ A₁ B₂ A₂ B₃ A₃（ベースライン、新規、交互）の順に実行します。
• avg_B − avg_A > max(stdev_B, stdev_A) の場合にのみ、改善を受け入れます（受け入れルール。他の箇所でも参照されていますが、記載はここだけです）。単発の実行や N 回の最小値は判定になりません（N 回の最小値はアイドル状態の瞬間を狙い、単発の実行はノイズを狙うためです）。
• 判定の前に、規律 10 を守ります。構造的な変更がある場合は、各実験群の間で環境をリセットします。
• ソースのパラダイムから意図的に逸脱している点（記録済み）：ソースでは、ノイズの範囲内でも「確実に正しい」マイクロ最適化を受け入れます。このワークフローでは、エージェントの実行に厳格な統計的ゲートを適用します。エージェントは「確実に正しい」ことを体系的に過大評価するためです。この例外を復活させるには、静的な同等性の証明とユーザーの確認が必要です。
• 効果がある理由：交互に実行すると同じマシン状態を経験するため、差分は絶対値よりもはるかに安定します。マシンのロックダウン、コアの固定、サービスの停止は必要ありません。

検証チェックリスト

• 仮説の判定：確認済み／反証済み／不確実（不足しているもの、次のモニタリングまたは再分析も記載します）。
• 有効性：同じ再現手順を使い、主要メトリクスの変更前／変更後を示し、合格基準を事前に明記します。
• リグレッション：機能の正しさ（通常／境界／ピーク時）が損なわれていないこと。変換パイプラインの最適化では、出力の同等性チェック（例：バイト単位での一致）が最も強力な方法です。
• 副作用：二次的なパフォーマンス問題がないこと（例：レイテンシは改善したが、メモリ使用量が増加している）。
• 基準：本番相当のビルドによる受け入れ数値（規律 2）。デバイスプロファイルに合わせて調整したセルによるユーザーのカクつき判定（規律 4）。
• 記録：実行結果をベンチマークログに追記します。棄却も含めて記録してください（規律 9：改善なしや成果物の行も理由とともに記録し、他の人が行き止まりを再調査したり、不適切な数値を引用したりしないようにします）。

停止条件

すべての仮説が検証され、目標が達成された場合、または残るボトルネックの費用対効果が低すぎる場合（変更コスト ≫ 効果）。これがキャンペーンレベルでの停止条件です。ラウンドレベルでの終了には、ループのセクションにある停止条件が適用されます。その後、必要に応じて主要メトリクスを継続的なモニタリング／CI ゲートに組み込みます。

---

反復ループ（環境ゲート付き、Stage 5～6 で必須）

最適化（Stage 5）と A/B 検証（Stage 6）は、実環境のループランナー上で動作する反復ループとして実行します。単発で実行してはならず、文章だけでループを独自に作り上げてもいけません。効果が積み重なるのは、ラウンドを継続するからです。手動で 1 回だけ実行すると、最初に目に見えるホットスポットで止まり、このパラダイムの中心的な価値が失われていることに気づけません。

環境ゲート（ステージ 5 の開始時）

環境を調べ、ループ機能があるか確認します。対象となるのは、インストール済みのループランナー（ralph-loop 形式のランナー、/loop、目標駆動型の長時間実行、または各ラウンドのコンテキストを管理しながらエージェントを自動的に次のラウンドへ進める仕組み）です。

• 見つかった場合 → 以下のループ本体をそのランナーに適用し、ループを開始します。ラウンドの進行と継続はランナーが制御します。このワークフローでは、各ラウンドの内容と停止条件を定めます。
• 見つからない場合 → 最適化の実行を停止します。分析ステージの結果（引き続き有効で、提出可能です）を報告し、具体的なブロッカーを明記します。ループランナーをインストールしてから、ステージ 5 から再開してください。手動で一度だけ実行する形に切り替えてはいけません。偽のループを装うより、正直に中止するほうが適切です。

このゲートは環境に対する実行時の強い依存関係です（フロントマター上の依存関係ではありません。ループランナーは環境プラグインであり、インストール可能なスキルではありません）。

ループ本体（各ラウンドで以下を順番に実行）

1. プロファイリング — 今回のラウンドでホットスポットを新たに調査します。前回のリストは古いため、入力として使ってはいけません。
2. 対象を 1 つだけ選択 — ユーザーへの影響度 × 時間占有率が最も高いホットスポットを選び、残りはキューに入れます。
3. 対象を最適化 — 最適化ステージに従って実施します（根本原因に対応づけ、元に戻せるようにします）。
4. A/B 判定 — ステージ 6 の受け入れルールに基づいて採用または差し戻しを決めます。判定前に規律 10 を遵守します（構造単位を変更した場合は、比較する各側の間で環境をリセットします）。不採用の場合は、このラウンドの変更を元に戻します。
5. 正確性ゲート — コミット前にテストスイート全体または出力の同等性を確認します。失敗した状態でコミットしてはいけません。
6. コミット＋スナップショット＋記録 — 1 ラウンドにつき 1 コミットとします。採用したビルドを次のラウンドのベースラインとしてスナップショット化し、コミットハッシュで識別します。採用・不採用を問わず、理由とともにベンチマークログへラウンドを追記します。

停止条件（いずれか 1 つ）

• ゲインがないラウンドが 5 回連続 — 最適化対象が収束しています。
• 目標達成 — ステージ 1 のしきい値またはレッドラインに到達したことを確認できています。
• ROI の枯渇 — 残るボトルネックによるゲインが、変更コストに見合わなくなっています。

停止時には、採用・不採用となったラウンド、ベースラインに対する測定ゲインの合計、ROI の評価を含む残りのボトルネックを要約します。

コンテキストの規律（長いループはコンテキストの肥大化で破綻します）

各ラウンドの結果をベンチマークログに保存し、次の情報だけを引き継ぎます。ラウンドの要約、ベースラインスナップショットへのポインター、停止条件のカウンターです。生のプロファイルと中間データはアーカイブファイルに保持し、必要に応じて取得します。ラウンドをまたいで全データを引き継いではいけません。

スキルの進化（停止のたび、または長いループでは約 5 ラウンドごと）

スキルもコードと同様です。プロジェクトの code-insight / code-optimizer も、このパラダイムから生まれた成果物であり、使用を通じて改善されます。停止条件に達するたびに、次の作業を行います。

• 今回の取り組みで得た検証済みの教訓を 2 つのスキルに取り込みます。有効だった原因特定のパターン、失敗した最適化（却下時のデータを含む）、発見したスタックやプロジェクト固有の落とし穴を反映します。
• ベンチマークログの無効化行と否定的な結果を、主な情報源とします。これらには、スキルが誤っていた点や見落とした点が具体的に記録されています。
• 反映する前に、スタックの専門家の視点（例：言語のセマンティクス／ランタイムとフレームワーク／ハードウェアとプラットフォーム）から更新内容をレビューします。取り組みの途中で得られた教訓が互いに矛盾したり、スキルの既存の内容と食い違ったりする場合は、矛盾を解消してから記述します。
• スキルをその場で更新します。次の取り組みは、より良い状態から始められます。パラダイムが一度の取り組みの中だけでなく、取り組みをまたいで積み重なっていくのはこのためです。

出力の詳細度（状況に応じて調整）

• 問題が単純でデータが豊富な場合：「異常 + 因果関係の連鎖 + 判定」にまとめます。
• 複雑な問題や複数モジュールにまたがる場合：ステージごとに簡潔な出力を示し、重要なコード断片を添付します。
• スタック固有の知識（フレームワークのバージョン、しきい値、パターン、ツールの表）：reference.md の情報を会話の中に自然に取り入れます。スタック固有の内容をこのファイルのパラダイムにハードコードしてはいけません。