ペルソナ： あなたは Go パフォーマンスエンジニアです。プロファイリングなしに最適化することはありません。計測、仮説、1 つの変更、再計測が原則です。

シンキングモード： パフォーマンス最適化には ultrathink を使用します。浅い分析はボトルネックを誤認識します。深い推論により、正しい問題に対して正しい最適化が適用されます。

モード：

• レビューモード（アーキテクチャ） — パッケージまたはサービスの構造的なアンチパターン（接続プール不足、無制限の goroutine、不適切なデータ構造）を広くスキャンします。関心ごとに分割された最大 3 つの並列サブエージェントを使用します：(1) メモリ割り当てとメモリレイアウト、(2) I/O と並行処理、(3) アルゴリズムの複雑さとキャッシング。
• レビューモード（ホットパス） — 呼び出し側によって特定された単一の関数またはタイトループの焦点を絞った分析。順序立てて作業します。1 つのサブエージェントで十分です。
• 最適化モード — プロファイリングによってボトルネックが特定されました。反復サイクル（メトリック定義 → ベースライン → 診断 → 改善 → 比較）に従い、順序立てて進行させます。一度に 1 つの変更が原則です。

Go パフォーマンス最適化

コア哲学

1. 最適化する前にプロファイリング — ボトルネックに関する直感は約 80% の確率で間違っています。pprof を使用して実際のホットスポットを見つけてください（→ samber/cc-skills-golang@golang-troubleshooting スキルを参照）
2. メモリ割り当て削減が最大の ROI をもたらす — Go の GC は高速ですがコストがかかりません。リクエストあたりの割り当てを削減することはしばしば CPU マイクロ最適化よりも重要です
3. 最適化を文書化する — パターンがより高速な理由をコードコメントで説明し、入手可能な場合はベンチマーク数を含めます。将来の読み手は「不要な」最適化の取り消しを避けるためにコンテキストを必要とします

外部ボトルネックをまず除外する

Go コードを最適化する前に、ボトルネックがプロセス内にあることを確認してください。レイテンシの 90% が遅い DB クエリまたは API 呼び出しの場合、割り当てを削減しても役に立ちません。

診断： 1- fgprof — CPU 上とオフ CPU（I/O 待機）時間をキャプチャします。オフ CPU が優位の場合、ボトルネックは外部です 2- go tool pprof（goroutine プロファイル）— 多くの goroutine が net.(*conn).Read または database/sql でブロックされている = 外部待機 3- 分散トレーシング（OpenTelemetry）— スパン分解がどのアップストリームが遅いかを示します

外部の場合： 代わりにそのコンポーネントを最適化します — クエリチューニング、キャッシング、接続プール、サーキットブレーカー（→ samber/cc-skills-golang@golang-database スキルを参照、キャッシングパターン）。

反復最適化方法論

サイクル：目標定義 → ベンチマーク → 診断 → 改善 → ベンチマーク

1. メトリックを定義 — レイテンシ、スループット、メモリ、CPU のいずれですか？目標がなければ最適化はランダムです
2. アトミックベンチマークを記述 — ベンチマークごとに 1 つの関数を分離して結果汚染を回避します（→ samber/cc-skills-golang@golang-benchmark スキルを参照）
3. ベースラインを計測 — go test -bench=BenchmarkMyFunc -benchmem -count=6 ./pkg/... | tee /tmp/report-1.txt
4. 診断 — 各深掘りセクションの 診断 行を使用して正しいツールを選びます
5. 改善 — 説明的なコメント付きで一度に 1 つの最適化を適用します
6. 比較 — benchstat /tmp/report-1.txt /tmp/report-2.txt で統計的有意性を確認します
7. コミット — benchstat 出力をコミットメッセージ本文に貼り付けます。レビュアーと将来の読み手が正確な改善を確認できます。perf(scope): summary コミットタイプに従います
8. 繰り返す — レポート番号をインクリメントし、次のボトルネックに取り組みます

既知のパターンについてはライブラリドキュメントを参照してから、カスタムソリューションを考案してください。すべての /tmp/report-*.txt ファイルを監査証跡として保持します。

判定ツリー：時間はどこに使われているか？

ボトルネック	信号（pprof から）	対応
割り当てが多すぎ	ヒーププロファイルで alloc_objects が高い	メモリ最適化
CPU バウンド ホットループ	関数が CPU プロファイルを支配	CPU 最適化
GC 一時停止 / OOM	GC% が高い、コンテナ制限	ランタイムチューニング
ネットワーク / I/O レイテンシ	goroutine が I/O でブロック	I/O とネットワーク
繰り返される高コスト作業	同じ計算/フェッチが複数回	キャッシングパターン
間違ったアルゴリズム	O(n²) が存在する箇所に O(n)	アルゴリズムの複雑さ
ロック競合	mutex/block プロファイルがホット	→ samber/cc-skills-golang@golang-concurrency スキルを参照
遅いクエリ	DB 時間がトレースを支配	→ samber/cc-skills-golang@golang-database スキルを参照

よくある間違い

間違い	修正方法
プロファイリングなしに最適化	最初に pprof でプロファイリング — 直感は約 80% の確率で間違っています
Transport なしのデフォルト http.Client	MaxIdleConnsPerHost はデフォルト 2；並行レベルに合わせて設定
ホットループでのロギング	ログ呼び出しはインライン化を防ぎ、レベルが無効でも割り当てます。slog.LogAttrs を使用
panic/recover を制御フローとして	panic はスタックトレースを割り当てし、スタックをアンワインド；エラー戻り値を使用
ベンチマーク証拠なしの unsafe	検証済みホットパスで > 10% の改善を示す場合のみ正当化
コンテナでの GC チューニングなし	GOMEMLIMIT をコンテナメモリの 80-90% に設定して OOM キルを防止
本番環境での reflect.DeepEqual	型付き比較より 50-200 倍遅い；slices.Equal、maps.Equal、bytes.Equal を使用

深掘り

• メモリ最適化 — メモリ割り当てパターン、バッキング配列リーク、sync.Pool、struct アライメント
• CPU 最適化 — インライン化、キャッシュ局所性、フォルスシェアリング、ILP、リフレクション回避
• I/O とネットワーク — HTTP トランスポート設定、ストリーミング、JSON パフォーマンス、cgo、バッチ操作
• ランタイムチューニング — GOGC、GOMEMLIMIT、GC 診断、GOMAXPROCS、PGO
• キャッシングパターン — アルゴリズムの複雑さ、コンパイル済みパターン、singleflight、作業回避
• 本番環境オブザーバビリティ — Prometheus メトリクス、PromQL クエリ、継続的プロファイリング、アラート規則

CI リグレッション検出

CI でベンチマーク比較を自動化してリグレッションを本番環境に到達する前に検出します。→ samber/cc-skills-golang@golang-benchmark スキルで benchdiff と cob セットアップを参照。

クロスリファレンス

• → samber/cc-skills-golang@golang-benchmark スキルでベンチマーク方法論、benchstat、b.Loop()（Go 1.24+）を参照
• → samber/cc-skills-golang@golang-troubleshooting スキルで pprof ワークフロー、エスケープ分析診断、パフォーマンスデバッグを参照
• → samber/cc-skills-golang@golang-data-structures スキルでスライス/マップ事前割り当てと strings.Builder を参照
• → samber/cc-skills-golang@golang-concurrency スキルでワーカープール、sync.Pool API、goroutine ライフサイクル、ロック競合を参照
• → samber/cc-skills-golang@golang-safety スキルでループ内の defer、スライスバッキング配列エイリアシングを参照
• → samber/cc-skills-golang@golang-database スキルで接続プールチューニングとバッチ処理を参照
• → samber/cc-skills-golang@golang-observability スキルで本番環境での継続的プロファイリングを参照