# パフォーマンスエンジニアリング ## 定義 パフォーマンスエンジニアリングとは、システムが満たすべき非機能要件(応答時間・スループット・スケーラビリティ・処理可能なトークン数・資源効率・コスト効率・エネルギー効率など)を、ビジネス上の目的と結び付けて継続的に保証するための全体最適の実践である。単なる「遅いところを速くする」個別最適のチューニング作業ではない。国際標準ISO/IEC 25010は、ソフトウェア製品品質を8特性で定義し、その2番目に「性能効率性(Performance Efficiency)」を挙げている(下位特性: 時間挙動・資源効率性・容量満足性)。本書でいうパフォーマンスエンジニアリングは、この性能効率性という品質特性をプロダクトライフサイクル全体で達成するための工学的アプローチであり、実務では「測定→分析→実装→検証」という段階的プロセスを基本とする。(Source: [[@2026__技術評論社__実践的パフォーマンスエンジニアリングによるAI高速化 - Chapter 1 パフォーマンスエンジニアリング概論]]) 生成AI・LLMの台頭以前は、多くのアプリケーションが汎用CPUで十分に速く、パフォーマンスエンジニアリングはHPCや組み込みシステムなど一部領域の「ニッチ技能」とみなされていた。しかしLLMの計算量急増とスケーリング則によるモデル大規模化、ユーザ数の爆発的増加により、数%の性能改善が学習期間短縮・インフラ効率化・顧客体験改善という具体的なビジネス価値に直結するようになり、事業競争力の中核技術に転じた。(Source: [[@2026__技術評論社__実践的パフォーマンスエンジニアリングによるAI高速化 - Chapter 1 パフォーマンスエンジニアリング概論]]) 実践面では「推測するな、計測せよ」を第一原則とし、USEメソッド(Utilization・Saturation・Errors、リソース単体の観測、Brendan Gregg提唱)やREDメソッド(Rate・Errors・Duration、サービスレベルの観測、Tom Wilkie提唱)といった体系的な分析手法を用いて、ベースライン測定→プロファイリング→分析と仮説立案→改善の実装→効果の検証という5段階サイクルを繰り返す。(Source: [[@2026__技術評論社__実践的パフォーマンスエンジニアリングによるAI高速化 - Chapter 1 パフォーマンスエンジニアリング概論]]) ## 横断的知見 - **「ライフサイクルの初期段階で始めるべきだが実務では後回しにされる」という懸念を、抽象度の異なる2冊が独立に共有する**: フィックスターズ(2026)は性能効率性というISO/IEC 25010の品質特性の観点からパフォーマンスエンジニアリングを定義するのに対し、Gregg(2023、ch.1 §1.3)はソフトウェアプロダクトのライフサイクルに沿った11ステップ(目標設定・パフォーマンスモデル作成からプロダクトリリース後のインシデント評価・ツール開発まで)として作業を分解する。抽象度・対象領域(AI高速化 対 汎用システムパフォーマンス)が異なるにもかかわらず、両者は「パフォーマンスエンジニアリングはハードウェア選択・ソフトウェア実装の前、すなわち目標設定とモデル作成の段階で始めるべきだが、実務ではこのステップが省略され問題が発生してから後手に回ることが多い」という同一の懸念を共有する。フィックスターズは事業競争力の観点から、Greggはアーキテクチャ上の決定の手戻りコストの観点から、それぞれ独立にこの結論に至っている。(Source: [[@2026__技術評論社__実践的パフォーマンスエンジニアリングによるAI高速化 - Chapter 1 パフォーマンスエンジニアリング概論]], [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 1 イントロダクション]]) - **専任のパフォーマンスエンジニア職種は、複数チームを横断するホリスティックな視点を担うという点で一致する**: Gregg(2023、ch.1 §1.2)は、パフォーマンスエンジニアという専任職種を置く企業の例としてNetflixのクラウドパフォーマンスチーム([[Netflix]])を挙げ、複雑なパフォーマンス障害の解決にはこのようなホリスティックなアプローチが必要不可欠だと述べる。フィックスターズ(2026)が挙げる「測定→分析→実装→検証」の段階的プロセスも、個別チームの専門領域を超えた全体最適の実践として位置づけられており、両ソースとも「パフォーマンスエンジニアリングは個別最適のチューニングではなく、複数の専門領域を横断する体系的な実践である」という共通認識を持つ。(Source: [[@2026__技術評論社__実践的パフォーマンスエンジニアリングによるAI高速化 - Chapter 1 パフォーマンスエンジニアリング概論]], [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 1 イントロダクション]]) - **「専任職種か全員の責務か」という組織設計上の対立軸に、3つ目の実例が加わる**: Gregg(2023、ch.1 §1.2)はNetflixのクラウドパフォーマンスチームという専任職種の例を挙げるが、`Observability Engineering`第2版第20章のHoneycombは、意図的に「独立した個別リポジトリの知識や専任のパフォーマンスエンジニアリングチームを作らない」ことを選び、既存のオブザーバビリティ駆動開発の文化を土台にパフォーマンスエンジニアリングを全エンジニアの日常業務へ組み込んだ。2024年末には単一のエンジニアではなく半数以上のチームが継続的プロファイリングツール選定に関与するまでに実践が広がったとされる。両者は「ホリスティックな視点が必要」という点では一致しつつ、それを専任チームで担うか全チームに分散させるかで対照的な組織設計を取っており、パフォーマンスエンジニアリングの実践形態が単一の正解を持たないことを示す。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 1 イントロダクション]], [[@2026__OReilly__Observability Engineering 2E - Chapter 20 Performance Engineering with Observability]]) - **「測定→分析→実装→検証」のサイクルは、Honeycombの実例では発見の入口が偶発的である点で補強される**: フィックスターズ(2026)が示す段階的プロセスは目的ドリブンな運用を前提とするが、Honeycomb自身のパフォーマンスエンジニアリングへの参入契機(2021年、ロードバランサログとトレーシングスパンのレイテンシ食い違いという偶発的な観察からpprofフレームグラフでルーター再初期化バグを発見)は、体系だったサイクルの「測定」段階そのものが、既存オブザーバビリティデータの日常的な不整合への気づきから始まりうることを示す実例になっている。すなわちパフォーマンスエンジニアリングの開始点は目的駆動のベンチマークだけでなく、オブザーバビリティ運用の副産物としても生じる。(Source: [[@2026__技術評論社__実践的パフォーマンスエンジニアリングによるAI高速化 - Chapter 1 パフォーマンスエンジニアリング概論]], [[@2026__OReilly__Observability Engineering 2E - Chapter 20 Performance Engineering with Observability]]) - **投資判断の基準として「クラウド費用対人件費の比率」が独立に共有される**: フィックスターズ(2026)はAI処理特有の計算コスト急増を投資根拠とするが、HoneycombはSaaSスタートアップとして粗利率が事業の生存性に直結する点、および相対的に高いクラウド費用を投資根拠として挙げる。ドメイン(AI高速化 対 汎用SaaS)が異なっても、「クラウド費用が人件費に対して大きいときに投資が正当化される」という判断基準は共通しており、2章(本ページ既存知見)で挙げた「複数チーム横断の実践」という共通認識に加えて、投資可否の経済的な閾値についても両ソースが同型の推論を辿っている。(Source: [[@2026__技術評論社__実践的パフォーマンスエンジニアリングによるAI高速化 - Chapter 1 パフォーマンスエンジニアリング概論]], [[@2026__OReilly__Observability Engineering 2E - Chapter 20 Performance Engineering with Observability]]) ## 未解決の問い - USEメソッド・REDメソッドは、本書2章(パフォーマンス計測)でAI処理特有の指標(GPU利用率・MFU・トークンスループット等)とどのように具体的に結びつけられるか。 - 「数%の性能改善が大きな価値を生む」という主張は、本書のビジネス貢献の3事例(Time-to-Market・原価と粗利・顧客体験)以外にどのような定量的裏付けを持つか。 - パフォーマンスエンジニアリングとカオスエンジニアリング・SRE([[カオスエンジニアリング]]、SRE Bookの信頼性工学)は、いずれも本番システムの品質特性を体系的に扱う実践だが、両者の方法論(計測駆動 対 障害注入駆動)の関係はどう整理できるか。 - Gregg(2023、ch.1 §1.5)が挙げる「主観的な性質」「複雑さ」「複数原因の同時発生」というパフォーマンス障害の3つの難しさは、フィックスターズ本のAI処理向けパフォーマンスエンジニアリングの文脈でどのように現れるか(例: GPU使用率のようなAI特有の指標も同様に主観的解釈の余地を持つか)。 ## 関連 - source: [[@2026__技術評論社__実践的パフォーマンスエンジニアリングによるAI高速化 - Chapter 1 パフォーマンスエンジニアリング概論]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 1 イントロダクション]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 20 Performance Engineering with Observability]] - entity: [[実践的パフォーマンスエンジニアリングによるAI高速化]] / [[Brendan Gregg]] / [[Llama3]] / [[BEVFusion]] / [[Netflix]] / [[Honeycomb.io]] - concept: [[フレームグラフ]] / [[継続的プロファイリング]] / [[サーバーレスアーキテクチャ]] ## 出典 - 株式会社フィックスターズ, 『実践的パフォーマンスエンジニアリングによるAI高速化』, 技術評論社, 2026, 第1章. - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 1 イントロダクション]](§1.2〜§1.3、職種と作業のライフサイクル) - [[@2026__OReilly__Observability Engineering 2E - Chapter 20 Performance Engineering with Observability]]("Building a Performance Engineering Practice"、Honeycombの組織実践)