すべてのiPhoneにはsysdiagnoseと呼ばれる「ブラックボックス」が存在します。これは、不具合が発生した際にAppleのエンジニアが真っ先に確認するシステム診断アーカイブです。音量ボタン2つとサイドボタンを約1秒間同時に押すと、iOSはバックグラウンドで静かにこの記録を作成します。圧縮された状態でも数百メガバイトの容量があり、ioreg、smcDiagnose、taskinfo、クラッシュレポート、バッテリーの化学的データなどが詰め込まれています。

最大の難点は、元々一般ユーザーが見ることを想定していないという点です。展開すると数千のファイルと数万行のプレーンテキストになります。あなたが必要とする情報は、IODeviceTree.txtの10,000行目や、IOService.txtのNVMeコントローラーノードの中に埋もれています。経験豊富な開発者であっても、その情報を見つけるまでに10分はかかります。

Device Status⁺は、このテキストの壁を読みやすいカード形式の画面に変換します。これは完全にオンデバイスで行われ、1バイトのデータも外部にアップロードされません。このガイドでは、sysdiagnoseの取得からカードの読み取りまで、診断ログアナライザー（Diagnostic Log Analyzer）の仕組みと、この処理によって電話がフリーズしない理由を解説します。

Device Status⁺とは？

Device Status⁺は、Space-Time Transformation Technology Co., Ltd.が提供する無料のシステム監視アプリです。iOS 17.0以降が必要で、iPhone、iPad、Mac（Mシリーズ）、Apple Vision Pro、Apple Watchで動作します。リアルタイムのCPU、メモリ、ストレージ、バッテリー、ネットワークのダッシュボードに加えて、sysdiagnoseアーカイブ専用の診断ログアナライザー（Diagnostic Log Analyzer）と、日常のバッテリー分析用のバッテリーログアナライザー（Battery Log Analyzer）（詳細は別ガイドを参照）を備えています。

以下で説明する処理はすべてローカルで実行されます。インポート画面には次のように明記されています。「すべての処理はオンデバイスで行われます。データは一切アップロードされません。」

sysdiagnoseとは正確には何か？

sysdiagnoseは、システム全体の特定時点でのスナップショットです。ハードウェアのボタン組み合わせによってトリガーされ、次のものを収集します。

• ioregデバイスツリーダンプ（IODeviceTree.txt、IOService.txt）
• SMC（System Management Controller）の読み取り値とsmcDiagnose
• taskinfoプロセススナップショット
• 統合されたクラッシュレポート（.ips）
• バッテリー化学情報のplistとNANDウェアスナップショット
• ネットワーク、Wi-Fi、Bluetoothの状態

結果として生成されるsysdiagnose_YYYY.MM.DD-...tar.gzは、展開するとPAX拡張ヘッダーを含む2,400以上のエントリになることがあります。メモリリソースが限られたiPhoneにおいて、「すべてをメモリに読み込んでから展開する」という単純なアプローチは、OOM（メモリ不足）を引き起こしてアプリをクラッシュさせてしまいます。そのため、このアナライザーはそのようなアプローチをとっていません。

ステップ1：sysdiagnoseを取得する

最も難しいのは分析ではありません。ファイルを取得することです。Device Status⁺には、操作のすべてを画面付きで案内するガイド（LogCollectionGuideView）が組み込まれています。

1. 両方の音量ボタンとサイドボタンを約1秒間長押しし、触覚フィードバック（バイブレーション）のあとに離します。これでsysdiagnoseの取得がトリガーされます。
2. 通常通りスマートフォンを使用し、収集が完了するまで約10分間待ちます。
3. 「設定」→「プライバシーとセキュリティ」→「解析と改善」→「解析データ」を開き、sysdiagnoseと検索します。
4. そのファイルを開き、「共有」→「ファイル」に保存を選択します。その後、Device Status⁺に戻り、「+」をタップしてインポートします。

「エントリを見つける」という手順を瞬時に完了させるため、ガイドには2つのワンタップショートカットが用意されています。ショートカットをインストールする（iCloudリンク）方法と、ShortcutsのURLスキーム経由で「解析と改善」画面に直接ジャンプする方法です。

ステップ2：メモリクラッシュなしでインポート

ここでエンジニアリングの真価が発揮されます。SysdiagnoseArchiveExtractorは2段階のストリーミングパイプラインを実行し、800 MBのアーカイブをわずか数キロバイトのバッファメモリで処理します。

ステージ1 — gunzip。 gzip対応デコードのためにinflateInit2(16 + MAX_WBITS)を指定したzlibを使用し、入力ファイルをmmap（要求に応じてページングされ、メモリに常駐しない）で読み込みます。そして64 KBのブロック単位で一時的な.tarファイルに出力を書き出します。ピーク時のメモリ使用量はそのバッファ分だけです。

ステージ2 — untar。 手書きのステートマシンがUSTAR / GNU / PAXヘッダーをエントリごとに解析し、ディスクに書き出します。GNUのロングファイルネーム（Lタイプ）、エントリごとの、およびグローバルなPAX拡張ヘッダー（x / g）、およびbase-256のサイズフィールドをサポートしています。アーカイブ全体をメモリ上に保持することは決してありません。

堅牢性に関する以下の詳細も同様に重要です。

• ディスク容量の事前チェック。 gunzip後に.tarの正確なサイズが判明した時点で、処理を続行する前に「tarファイル＋安全マージン」の空き容量がvolumeAvailableCapacityにあるかどうかを確認します。途中で失敗した展開ファイルがストレージを圧迫することはありません。
• パスの安全性。 isSafeRelativePathにより、絶対パス、埋め込まれた\0（ヌル文字）、および..によるディレクトリトラバーサルを拒否します。サンドボックス外への書き込みは一切発生しません。
• 整合性チェック。 CRCやISIZEの検証はzlibに委ねられており、切り詰められたり破損したりしたgzipは、無言のフリーズではなく、読み可能なエラー（inflateFailed / truncatedArchive）として報告されます。
• 一時.tarの確実な削除。 処理の成否に関わらずdeferによって確実に削除されるため、数百メガバイトのゴミファイルが残ることはありません。

展開中、UIには「gzipを展開中（N MB展開済み）」と「Nファイル抽出済み」を区別するプログレスオーバーレイが表示され、処理が間違いなく進行していることを実感できます。

共有拡張機能（Share Extension）によるワンタップインポート

「ファイル」アプリを経由する手順を完全に省くこともできます。sharelog拡張機能は、「解析データ」リストから直接sysdiagnose_*.tar.gzを認識します。重要なのは、この拡張機能自体は解析を行わないということです。sysdiagnoseを展開するには拡張機能のメモリ予算は小さすぎます。この機能はファイルをApp Groupコンテナ（ShareInbox/）にコピーし、保留中のシグナルをApp GroupのUserDefaultsに書き込み、devicestatusのURLスキーマ経由でホストアプリを起動するだけです。その後、メモリを多く消費する展開処理をホストアプリが実行します。そのため、ユーザーにはワンタップで完了したように感じられます。

ステップ3：デバイスの概要を読む

SysdiagnoseOverviewParserは、以下の3つのソースからデバイスの識別情報を組み立てます。

• remotectl_dumpstate.txtの最初のProperties: {…}ブロック → モデル、OS、シリアル番号、UDID、ChipID、SoCプラットフォーム、リージョンコードなど。
• ioreg/IOService.txtの"product-name" → 製品のマーケティング名（例：iPhone 17）。ProductTypeから名前を推測するフォールバック機能も内蔵しています。
• ルートフォルダ名 → 取得タイムスタンプ（+0800のオフセットとローカルタイム形式の両方をサポート）。

各フィールドは、生のキーと分かりやすいラベルの両方（例：ChipID / 33104）を保持しているため、表示されたカードと元のログ行を照合することができます。

ステップ4：7つのカテゴリを探索する

これがこのプロダクトの核心的な設計判断です。生テキストのダンプは行わず、各ファイルから抽出された主要な指標のみをカードとして表示します。 SysdiagnoseCategoryConfigは数千のファイルを重複のない7つのカテゴリに分類し、専用の抽出処理を用意されたファイルのみをリストアップします。これが、アプリのバッジ番号が実際に表示されるカードの数と正確に一致する理由です。タップしても何も表示されないといったことはありません。

内部の専門家しか抽出しないような詳細

• バッテリー化学情報（ACAM）。 com.apple.batteryintelligence.batteryalgorithms-OnDeviceACAM-state.plistを解析し、3つのカードにまとめます。
  • バッテリー識別情報 — セルのシリアル番号、純正かどうか、充電電圧の制限。
  • 活性物質 — 活性物質の維持率（QLi / Qn / Qp：リチウムイオン / 負極 / 正極のうち、利用可能な割合）。
  • 劣化と抵抗 — SEI成長、亀裂 / 相変化による損失、電極抵抗。 これらは、通常はAppleの社内ツールにしか存在しないミクロレベルのバッテリー健康指標です。
• ストレージハードウェア（NVMe + NAND）。 IOService.txt内のNVMeコントローラーノードから、セルタイプ（SLC / MLC / TLC / QLC）、ページサイズ、ファームウェアバージョン、読み書きの操作とエラー情報を抽出します。また、ASPSnapshots/asptool_snapshot.logからは、NANDの起動 / 電源サイクル回数、寿命の総読み書き量、ウェアレベリング、およびバンド分布を抽出します。つまり、お使いのNANDセルのタイプ、これまでにどれだけ書き込まれたか、そしてどれくらいの寿命が残っているかがわかります。
• チップ識別。 IODeviceTreeのchip-idはリトルエンディアンの16進数ですが、抽出エンジンがそれをエンジニアに馴染みのある「T番号」（例：T8130）に変換し、解読困難な16進数を読みやすいシリコンのコードネームとして表示します。

知っておく価値のある抽出テクニック

• 大きなファイルはプレビュー制限を回避。 taskinfo、IODeviceTree.txt、IOService.txt、asptool_snapshot.logは4,000行というプレビュー上限をはるかに超えています。抽出エンジンは解析前にファイル全体を読み込むため、電力消費ランキング、チップノード、NVMeコントローラー、NAND健康状態の見落としがありません。
• 複数ファイルの統合。 日々のバッテリーサイクルCSV（BDC_Daily_*.csv）は、最新の値を表示する1つの「バッテリーサイクル数」カードに統合されます。また、個別の.ipsクラッシュファイルも1つの統合された「クラッシュレポート」カードにまとめられます。
• ファイル間の相関分析。 サイクル数は、SMCの現在のB0CT値とBDC履歴の両方から読み取られ、比較されます。

履歴と永続化

インポートされた各データはApplication Support/SysdiagnoseCases/<serial_timestamp>に保存され、メタデータはSysdiagnoseHistoryStoreで管理されます。同じアーカイブを再インポートすると、既存の展開データが再利用されます（caseIdによって重複排除されます）。リスト画面ではスワイプによる削除や全削除が可能で、再び開くときも瞬時に表示されます。これは、抽出処理を再実行することなく、概要の解析のみを行っているためです。

アプリに組み込まれた3つの約束

1. 完全なオフライン・オンデバイス動作。 展開から抽出に至るまで、ネットワークリクエストは一切発生しません。
2. パフォーマンスよりも可読性を優先。 すべての解析の最終形は生テキストではなくカードです。照合用に元のフィールドは保持されますが、デフォルトでは非表示になっています。
3. 本番環境レベルの堅牢性：
   • ディレクトリトラバーサル保護、ディスク容量の事前チェック、tarヘッダーの検証、一時ファイルの確実なクリーンアップ。
   • ファイルレンダリングのガードレール： SysdiagnoseFileContentはテキストを512 KB / 4,000行に、CSVを1,000行に制限します。また、抽出エンジンはフォールバックとしてファイル全体を読み込むため、単一のファイルによってメモリがクラッシュすることは絶対にありません。
   • 人間が読める形式へのエラー変換（inflateFailedを「アーカイブが破損しているか、ダウンロードが不完全です」というメッセージに変換など）。
   • 起動方法の差異によるパス互換性（新しい相対パスと、従来のサンドボックス絶対パスの両方を処理）。

最後に

診断ログアナライザー（Diagnostic Log Analyzer）は、sysdiagnoseに含まれる2,000以上のファイルをすべて表示しようとはしません。ユーザーが実際に知りたい疑問—私のデバイスはどのようなハードウェアで動いているのか？バッテリーは健康か？ストレージはどれだけ劣化しているか？なぜ最近クラッシュしたのか？—に答え、整理された共有可能で検証可能な回答を提供します。

取得手順はガイドされており、インポートはワンタップで行われ、展開処理がメモリを枯渇させることはなく、画面にはカードのみが表示されます。毎日のバッテリー健康状態の推移といった長期的なモニタリングについては、バッテリーログアナライザーガイドを参照してください。