arch-performance-optimization

Codex 互換性に関する注意：

• Codex では $skill-name を使ってリポジトリのスキルを呼び出します。このミラーコピーでは、従来の Claude の /skill-name 参照を書き換えています。
• タスクトラッカーの必須事項：ワークフローまたはスキルのステップを実行する前に、すべてのステップのタスク追跡を作成または更新し、進捗の変化に合わせて同期を保ってください。
• ユーザーへの質問プロンプトは、Codex でユーザーに直接質問することを意味します。
• Claude 固有のモード切り替え指示が現れた場合は無視してください。
• 厳格な実行契約：ユーザーがスキルを明示的に呼び出した場合は、そのスキルのプロトコルを記載どおりに実行してください。
• サブエージェントの承認：スキルがユーザーによって呼び出された場合、または AI によって検出された場合に、そのプロトコルでサブエージェントが必要とされているなら、そのスキルの有効化によって、そのタスクに必要な spawn_agent サブエージェントの使用が承認されます。
• ユーザーが逸脱を事前に明示的に承認しない限り、プロトコルのステップを省略、並べ替え、統合しないでください。
• ワークフロースキルでは、列挙された子スキルの各ステップを明示的に実行し、ステップごとの証拠を報告してください。
• 必須のステップやツールをこの環境で実行できない場合は、適応する前に停止してユーザーに確認してください。

Codex プロジェクト参照の読み込み（フックなし）

Codex では、Claude のフックによるドキュメント注入は行われません。 コーディング、計画、デバッグ、テスト、レビューを行う際は、このルーティングに従ってプロジェクトのドキュメントを明示的に開いてください。

必ず読むドキュメント：

• docs/project-config.json（プロジェクト固有のパス、コマンド、モジュール、ワークフロー／テストの設定）
• docs/project-reference/docs-index-reference.md（docs/project-reference/* カタログ全体へのルート）
• docs/project-reference/lessons.md（常時適用されるガードレールとアンチパターン）

状況に応じて読むドキュメント：

• バックエンド／CQRS／API／ドメイン／エンティティの変更：backend-patterns-reference.md、domain-entities-reference.md、project-structure-reference.md
• フロントエンド／UI／スタイリング／デザインシステム：frontend-patterns-reference.md、scss-styling-guide.md、design-system/README.md
• 仕様／テストケースの計画、または TC のマッピング：feature-docs-reference.md
• 統合テストの実装／レビュー：integration-test-reference.md
• E2E テストの実装／レビュー：e2e-test-reference.md
• コードレビュー／監査作業：code-review-rules.md と、変更ファイルに応じた上記のドメインドキュメント

すべてのドキュメントを無差別に読まないでください。docs-index-reference.md から始め、タスクに関連するファイルだけを開いてください。

クイックサマリー

目標： データベース、API、ネットワーク、フロントエンドの各レイヤーにおけるパフォーマンスのボトルネックを分析し、解消します。

ワークフロー：

1. ボトルネックの特定 — データベース、API、ネットワーク、フロントエンドの問題として分類します
2. ベースラインの測定 — 変更前のメトリクス（応答時間、クエリ時間、バンドルサイズ）を収集します
3. 最適化 — レイヤー固有の修正（インデックス、キャッシュ、遅延読み込み、OnPush）を適用します
4. 検証 — 再度測定し、デグレードがないことを確認したうえで改善を確認します

主なルール：

• 本番環境では必要な列だけを選択し、すべての結果セットに上限（ページング／上限値）を設けてください。SELECT * や上限のないクエリは絶対に使用しないでください。理由：実データ量の下で上限のない読み取りを行うと、メモリ使用量とレイテンシが急増します
• 必ず非同期 I/O を使用してください。.Result でスレッドをブロックしないでください
• Eager Loading またはバッチフェッチを使用して、N+1 クエリのパターンを解消してください
• バックグラウンドジョブでは、並列実行数に上限を設けてください（maxConcurrent を指定した ParallelAsync）

懐疑的な姿勢を保ってください。批判的思考と順序立てた思考を適用してください。すべての主張には追跡可能な証拠と信頼度の割合が必要です（アイデアは 80% を超える必要があります）。

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

このスキルを使用する場面

• API の応答時間が遅い場合
• データベースクエリの最適化
• フロントエンドのレンダリングに関する問題
• メモリ使用量に関する懸念
• スケーラビリティの計画

事前確認チェックリスト

• パフォーマンスのボトルネックを特定する
• ベースラインのメトリクスを収集する
• 許容可能な閾値を決定する
• 測定方法を計画する

パフォーマンス分析フレームワーク

ステップ 1：ボトルネックの種類を特定する

Performance Issue
├── Database (slow queries, N+1)
├── API (serialization, processing)
├── Network (payload size, latency)
└── Frontend (rendering, bundle size)

ステップ 2：ベースラインを測定する

# API response time
curl -w "@curl-format.txt" -o /dev/null -s "http://api/endpoint"

# Database query time (SQL Server)
SET STATISTICS TIME ON;
SELECT * FROM Table WHERE ...;

# Frontend bundle analysis
npm run build -- --stats-json
npx webpack-bundle-analyzer stats.json

データベースの最適化

⚠️ 必ずお読みください： N+1 の検出、イーガーローディング、プロジェクション、ページング、並列クエリのパターンについては、CLAUDE.md をご確認ください。高度なインデックスおよびクエリの最適化については、database-optimization スキルをご覧ください。

インデックスに関する推奨事項

-- Frequently filtered columns
CREATE INDEX IX_Employee_CompanyId ON Employees(CompanyId);
CREATE INDEX IX_Employee_Status ON Employees(Status);

-- Composite index for common queries
CREATE INDEX IX_Employee_Company_Status
ON Employees(CompanyId, Status)
INCLUDE (FullName, Email);

-- Full-text search index
CREATE FULLTEXT INDEX ON Employees(FullName, Email);

API の最適化

⚠️ 必ずお読みください： 並列タプルクエリおよびレスポンス DTO のパターンについては、CLAUDE.md をご確認ください。

キャッシュ

// Static data caching
private static readonly ConcurrentDictionary<string, LookupData> _cache = new();

public async Task<LookupData> GetLookupAsync(string key)
{
    if (_cache.TryGetValue(key, out var cached))
        return cached;

    var data = await LoadFromDbAsync(key);
    _cache.TryAdd(key, data);
    return data;
}

フロントエンドの最適化

バンドルサイズ

// :x: Import entire library
import _ from 'lodash';

// :white_check_mark: Import specific functions
import { debounce } from 'lodash-es/debounce';

遅延読み込み

// :white_check_mark: Lazy load routes
const routes: Routes = [
    {
        path: 'feature',
        loadChildren: () => import('./feature/feature.module').then(m => m.FeatureModule)
    }
];

変更検知

// :white_check_mark: OnPush for performance
@Component({
  changeDetection: ChangeDetectionStrategy.OnPush
})

// :white_check_mark: Track-by for lists
trackByItem = this.ngForTrackByItemProp<Item>('id');

// Template
@for (item of items; track trackByItem)

仮想スクロール

// For large lists
import { CdkVirtualScrollViewport } from '@angular/cdk/scrolling';

<cdk-virtual-scroll-viewport itemSize="50">
  @for (item of items; track item.id) {
    <div class="item">{{ item.name }}</div>
  }
</cdk-virtual-scroll-viewport>

バックグラウンドジョブの最適化

⚠️ 必ずお読みください： 上限付き並列処理（maxConcurrent を指定した ParallelAsync）およびバッチ処理（UpdateManyAsync）のパターンについては、CLAUDE.md をご確認ください。

パフォーマンスの監視

低速な処理のログ記録

var sw = Stopwatch.StartNew();
var result = await ExecuteOperation();
sw.Stop();

if (sw.ElapsedMilliseconds > 1000)
    Logger.LogWarning("Slow operation: {Ms}ms", sw.ElapsedMilliseconds);

データベースクエリのログ記録

// In DbContext configuration
optionsBuilder.LogTo(
    Console.WriteLine,
    new[] { DbLoggerCategory.Database.Command.Name },
    LogLevel.Information);

パフォーマンスチェックリスト

データベース

• フィルター対象の列にインデックスがある
• リレーションにイーガーローディングを使用している
• 部分的なデータにはプロジェクションを使用している
• データベースレベルでページングしている
• N+1 クエリがない

API

• 可能な場合は並列処理を行っている
• エンティティではなくレスポンス DTO を使用している
• 静的データをキャッシュしている
• リストにページネーションを使用している

フロントエンド

• ルートに遅延読み込みを使用している
• OnPush 変更検知を使用している
• リストに Track-by を使用している
• 大規模なリストに仮想スクロールを使用している
• インポートをツリーシェイキングしている

バックグラウンドジョブ

• 上限付き並列処理
• バッチ操作
• ページ単位の処理
• 適切なスケジュール設定

避けるべきアンチパターン

:x: 本番環境での SELECT *

var all = await context.Table.ToListAsync();

:x: 同期 I/O

var result = asyncOperation.Result;  // Blocks thread

:x: 上限のない結果セット

await repo.GetAllAsync();  // Could be millions

:x: ループ内でのデータベース呼び出しの繰り返し

foreach (var id in ids)
    await repo.GetByIdAsync(id);  // N queries

確認チェックリスト

• ベースラインのメトリクスを記録した
• ボトルネックを特定し、対処した
• 変更をベースラインと比較して測定した
• 新たなパフォーマンス問題が発生していない
• 監視を導入した

関連項目

• arch-security-review
• database-optimization

---

[IMPORTANT] タスク追跡を使って、作業を始める前にすべての作業を小さなタスクに分割してください。各ファイルを読むタスクも含めます。これにより、長いファイルによるコンテキストの喪失を防げます。単純なタスクの場合は、スキップするかどうかを AI が必ずユーザーに確認してください。

• docs/project-reference/domain-entities-reference.md — ドメインエンティティのカタログ、リレーションシップ、サービス間同期（タスクにビジネスエンティティ／モデルが関係する場合に読みます）（関連する場合は直接読み、フックによって会話に挿入されたテキストに依存しないでください）

AI の誤り防止 — あらゆるタスクで避けるべき失敗のパターン：

削除する前に、後続の参照先を確認してください。 コンポーネントを削除すると、ドキュメントやコードに古さが連鎖します。削除する前に、参照しているファイルをすべて洗い出してください。 AI が生成した内容を実際のコードと照合してください。 AI は API、クラス名、メソッドのシグネチャを幻覚することがあります。ドキュメントに記載したり参照したりする前に、必ず grep で存在を確認してください。 編集後は依存関係を最後までたどってください。 定義を変更しても、そこから派生する後続の変数や利用箇所を見落とすことがあります。必ず依存関係を最後までたどってください。 正しさを検証するときは、すべてのコードパスをたどってください。 コードが存在することを確認しても、実行されることを確認したことにはなりません。成功する経路だけでなく、早期終了、エラー分岐、条件によるスキップも必ずたどってください。 デバッグ時は、修正する前に「どちらの責任か」を確認してください。 バグが呼び出し元（誤ったデータ）にあるのか、呼び出し先（誤った処理）にあるのかをたどってください。責任のあるレイヤーで修正し、症状が現れる箇所には決してパッチを当てないでください。 既存の値には意図があると考え、変更する前に理由を確認してください。 定数、上限値、フラグ、パターンを変更する前に、コメントを読み、git blame を確認し、周辺のコードを調べてください。 最初の出力だけでなく、影響を受ける出力をすべて検証してください。 複数のスタックに関わる変更では、出力をすべて検証する必要があります。チェックが 1 つ成功しても、すべてのチェックが成功したことにはなりません。 全体を優先してデバッグし、目の前のことに注意を奪われないでください。 失敗を調査するときは、まず前提条件をすべて列挙してください（設定、環境変数、DB 名、エンドポイント、DI 登録、データの前提条件）。次に、コードレイヤーの仮説を立てる前に、それぞれを証拠と照合してください。 変更は最小限にし、差分テストを適用してください。 バグ修正では、変更した各行がバグに直接結び付いていなければなりません。隣接するコードのスタイルを変更したり、改善したりしないでください。機能強化タスクでは、改善を実装し、その内容を明確に伝えてください。 実装前に曖昧さを明らかにし、黙って解釈を選ばないでください。 依頼に複数の解釈がある場合は、それぞれの作業量の見積もりを提示して確認してください。全レコードを対象とする方法、ファイルベースの方法、より複雑な方法を決めつけないでください。

批判的思考の姿勢 — 批判的思考と段階的思考を適用してください。行動に移すには、すべての主張にたどって確認できる証拠が必要であり、確信度は 80% 超でなければなりません。 幻覚の防止： 推測を事実として述べないでください。すべての主張に情報源を示し、不確実な点は率直に認め、出力に誤りがないか自己確認し、独立した情報源と照合し、自分の確信を疑ってください。証拠のない確信こそ、あらゆる幻覚の根本原因です。

証拠に基づく推論 — 推測は禁止です。すべての主張に証拠が必要です。

1. すべての主張について、file:line、grep の結果、またはフレームワークのドキュメントを引用してください
2. 確信度を明示してください：80% 超ならそのまま行動、60～80% なら先に検証、60% 未満なら推奨しないでください
3. アーキテクチャの変更には、サービス間の検証が必要です
4. 「十分な証拠がありません」は妥当であり、期待される出力です

以下が揃うまで作業はブロックされます： - [ ] 証拠のファイルパス（file:line） - [ ] grep 検索を実施済み - [ ] 類似パターンを 3 件以上確認済み - [ ] 確信度を明示済み

証拠なしで使うことを禁止する表現： "obviously"、"I think"、"should be"、"probably"、"this is because" 不完全な場合は → "Insufficient evidence. Verified: [...]. Not verified: [...]." を出力してください。

• 必ず重要事項に注意を払ってください すべての主張に file:line の証拠を引用してください。行動に移すには確信度 80% 超が必要であり、60% 未満の場合は推奨してはいけません。

必ず注意してください 批判的思考を適用してください。すべての主張には、たどって確認できる証拠が必要であり、行動に移すには確信度 80% 超が必要です。幻覚を防ぎ、推測を事実として述べないでください。

必ず注意してください AI の誤り防止を適用してください。全体を優先したデバッグ、責任のあるレイヤーでの修正、実装前の曖昧さの明示、コンパクション後のファイルの再読を徹底してください。

最後のリマインダー

• 必須・重要・必ず注意 作業を始める前に、タスク追跡を使って作業を小さな ToDo タスクに分割してください
• 必須・重要・必ず注意 新しいコードを作成する前に、コードベースで類似パターンを3つ以上検索してください
• 必須・重要・必ず注意 すべての主張について file:line の根拠を示してください（確信度が80%を超えてから実行してください）
• 必須・重要・必ず注意 作業の品質を確認するため、最後のレビュー用 ToDo タスクを追加してください 必須・重要・必ず注意 作業を始める前に、次のファイルを読んでください。

[TASK-PLANNING] 作業に着手する前に、タスクの範囲を分析し、タスク追跡を使って小さな ToDo タスクとサブタスクに体系的に分割してください。

フックなしプロンプトプロトコルミラー（自動同期）

ソース：.claude/hooks/lib/prompt-injections.cjs + .claude/.ck.json

[WORKFLOW-EXECUTION-PROTOCOL] [BLOCKING] ワークフロー実行プロトコル — 必須・重要・必ず・重大。いかなる理由があっても省略しないでください。

汎用的な移植性の境界： 再利用可能なスキルとプロトコルのテキストはプロジェクトに依存しないものとし、プロジェクト固有の規約は docs/project-config.json と docs/project-reference/ から確認します。共有 AI-SDD は shared/sdd-artifact-contract.md に従って適用します。docs/project-config.json と docs/project-reference/docs-index-reference.md を読み、そこに記載されたプロジェクト参照ドキュメントを開いてください。この共有コンテキストとローカルドキュメントが利用できる場合は、サポートされている任意の AI ツールで実行できます。

1. 検出： プロンプトをワークフローカタログと照合します
2. 分析： 最適なワークフローを見つけ、カスタムのステップの組み合わせのほうが適しているかどうかも評価します
3. 質問（必須形式）： ユーザーがワークフロー／スキルを明示的に呼び出し、ローカルプロトコルでその明示的な呼び出しを確認とみなす場合を除き、次の構成でユーザーに直接質問します。
   • 質問：「どのワークフローを有効にしますか？」
   • オプション1：「[最適なワークフロー] を有効にする（推奨）」
   • オプション2：「カスタムワークフローを有効にする：[ステップ1 → ステップ2 → ...]」（理由を1行で記載）
4. 有効化（確認後）： 標準ワークフローでは $workflow-start <workflowId> を呼び出し、カスタムのステップは手動で順に実行します
5. タスクの作成： すべてのワークフローステップについて、タスク追跡を使ってタスクを作成します
6. 実行： 各ステップを順番に実行します [CRITICAL-THINKING-MINDSET] 批判的思考と順序立てた思考を適用します。すべての主張には追跡可能な証拠が必要です。確信度が80%を超えてから実行してください。 幻覚防止の原則： 推測を事実として提示しないでください。すべての主張について出典を示し、不確実な点は率直に認め、出力に誤りがないか自己確認し、独立して相互参照し、自分の確信にも懐疑的でいてください。根拠のない確信は、あらゆる幻覚の根源です。 AI 注意原則（初頭効果と親近効果）： 長いプロンプト／プロトコルでは、最も重要な3つのルールを冒頭と末尾の両方に配置し、長いコンテキストウィンドウでも指示が守られるようにします。 目標駆動型の実行： まず成功基準を定義し、検証できるまで繰り返します。観測可能なチェックに合格した場合にのみ終了します。 意図を検証するテスト： テストでは、現在の動作をなぞるだけでなく、ビジネスルールや不変条件を保護し、保護対象の意図が破られた場合に失敗するようにしてください。

[LESSON-LEARNED-REMINDER] [BLOCKING] タスク計画と継続的改善 — 必須。省略しないでください。

作業を始める前に、作業を小さなタスクに分けて（タスク追跡を行って）ください。最後のタスクとして「AI のミスと教訓を分析する」を追加してください。

教訓を抽出する — 症状への対処ではなく、根本原因のみ：

1. 症状ではなく、失敗モード（推論や前提の誤り）に名前を付けます。「誤った列挙値を使った」ではなく、「ソースを読まずに API が存在すると仮定した」。
2. 汎用性を確認します。この失敗モードは、3 つ以上の状況やコードベースに当てはまりますか？当てはまらない場合は、もう 1 段階抽象化してください。
3. 普遍的なルールとして記述します。プロジェクト固有の名前、パス、クラスを取り除き、どのコードベースでも役立つ内容にしてください。
4. まとめます。同じ失敗モードに起因する複数のミスは、1 つの教訓にまとめてください。
5. 再発確認：「このリマインダーがなくても、今後のセッションで再発しますか？」いいえの場合は、$learn を省略します。
6. 自動修正確認：「$code-review／$code-simplifier／$security／$lint で検出できますか？」はいの場合は、代わりにレビューのスキルを改善してください。
7. **両方の確認を通過した場合：**ユーザーに $learn の実行を依頼してください。 [TASK-PLANNING] [MANDATORY] ワークフローやスキルの手順を実行する前に、計画したすべての手順についてタスク追跡を作成または更新してください。その後、各手順の開始時と完了時に、タスク追跡の内容を同期してください。