はい、承知いたしました。
Swiftのログ出力に関する詳細な説明を含む約5000語の記事を作成します。以下、記事本文です。

NSLogはもう古い？Swiftのログ出力はos.logとLoggerが新常識

はじめに

iOSやmacOSアプリケーションを開発する上で、「ログ出力」は避けては通れない重要なプロセスです。バグの追跡、パフォーマンスの監視、特定の条件下での動作確認など、ログは開発者を助ける強力な武器となります。かつて、多くのObjective-Cや初期のSwift開発者は、デバッグ情報の出力に NSLog や print 関数を頼ってきました。手軽で直感的に使えるこれらの関数は、長きにわたり開発の現場を支えてきた功労者と言えるでしょう。

しかし、ソフトウェア開発の世界は日進月歩です。アプリケーションが複雑化し、ユーザーのプライバシー保護がかつてないほど重要視される現代において、旧来のログ出力手法は多くの課題を抱えるようになりました。パフォーマンスへの影響、膨大なログの中から目的の情報を見つけ出す困難さ、そして何よりも、意図せず機密情報をログに出力してしまうリスク。これらの問題は、もはや看過できるものではありません。

Appleはこうした課題に応えるため、WWDC 2016でUnified Logging System (ULS) という、全く新しいログ記録の仕組みを導入しました。そして、それをSwiftから快適に利用するためのインターフェースとして os.log、さらにWWDC 2020ではSwiftネイティブの Logger 構造体が発表されました。これらは、単なる NSLog の置き換えではありません。パフォーマンス、セキュリティ、利便性のすべてにおいて、旧来の手法を圧倒する、まさに「新常識」と呼ぶべき存在です。

本記事では、なぜ NSLog や print が「古い」とされるのか、その具体的な理由から説き起こし、Unified Logging Systemの根幹をなす os.log の機能と使い方を詳解します。さらに、現代のSwift開発における決定版とも言える Logger 構造体がいかに優れているかを、豊富なコード例とともに徹底的に掘り下げていきます。この記事を読み終える頃には、あなたはログ出力に対する考え方をアップデートし、よりモダンで、より安全で、より効率的な開発手法を身につけていることでしょう。

第1章: なぜNSLogやprintはもう古いのか？

新しい技術を学ぶ前に、まずはなぜ既存の技術が時代遅れになったのかを理解することが重要です。ここでは、多くの開発者が慣れ親しんだ print と NSLog が抱える具体的な問題点を見ていきましょう。

`print` の限界

Swiftを学び始めた人が最初に出会うであろう print 関数。手軽にコンソールに変数の内容を出力できるため、簡単なデバッグには非常に便利です。

swift let userName = "Alice" let score = 100 print("User: \(userName), Score: \(score)") // 出力: User: Alice, Score: 100

しかし、この手軽さの裏には、本格的なアプリケーション開発において致命的となりうるいくつかの欠点が存在します。

コンテキスト情報の欠如: print の出力には、タイムスタンプ、スレッドID、プロセス名といったコンテキスト情報が一切含まれません。いつ、どこで、どのプロセスから出力されたログなのかが全く分からず、複雑な非同期処理やマルチスレッド環境でのデバッグでは、ログの発生源を特定するのが困難になります。
フィルタリング機能の不在: print の出力は、単なる文字列としてコンソールに流れていくだけです。ログが大量に発生する状況では、Xcodeのコンソールは瞬く間に埋め尽くされ、目的の情報を見つけ出すのは至難の業です。ログレベル（例: INFO, DEBUG, ERROR）の概念もないため、「エラーに関するログだけを表示する」といった絞り込みもできません。
リリースビルドでの混入リスク: デフォルトでは、print 文はデバッグビルドだけでなく、App Storeに提出するリリースビルドにも含まれてしまいます。これはパフォーマンスに僅かながら影響を与えるだけでなく、デバッグ用の情報がユーザーのデバイス上で無駄に出力され続けることになります。もちろん、ビルド設定で print を無効化するテクニックもありますが、標準でそうした仕組みが備わっていないのは大きな欠点です。
パフォーマンス: print は比較的低コストな処理ですが、ループ内で大量に呼び出されたりすると、無視できないオーバーヘッドを生み出す可能性があります。

結論として、print はPlaygroundでの学習や、書いては消すような一時的なデバッグ用途に限定すべきであり、プロダクトコードに含めるべきではありません。

`NSLog` が抱える深刻な問題

print よりも高機能なログ出力として、Objective-C時代から使われてきたのが NSLog です。NSLog は print のいくつかの欠点を補っています。

“`swift
import Foundation

let event = “Login Success”
NSLog(“Event: %@”, event)
// 出力例: 2023-10-27 10:30:00.123 MyApp[12345:67890] Event: Login Success
“`

出力を見るとわかるように、NSLog は自動的にタイムスタンプ、プロセス名、プロセスID、スレッドIDを付与してくれます。これは print にはない大きな利点です。また、その出力はデバイスのシステムログにも書き込まれるため、Xcodeに接続していない状態でも後からコンソールアプリなどで確認できます。

では、なぜその NSLog も「古い」のでしょうか。理由は、より深刻なレベルの問題を複数抱えているからです。

深刻なパフォーマンス問題: NSLog の最大の欠点は、そのパフォーマンスの悪さです。NSLog は呼び出されるたびに、同期的（Synchronous）にファイルディスクリプタへログを書き込みます。これは比較的重いI/O処理であり、特にUIスレッドのような応答性が求められるスレッドで頻繁に呼び出すと、アプリケーションの動作がカクついたり、フリーズしたりする原因にさえなり得ます。かつては「NSLog をループ内で呼び出すな」というのが開発者の間での鉄則でした。
情報過多とフィルタリングの壁: NSLog の出力は、macOSの「コンソール」アプリやデバイスログで確認できますが、ここにはOSや他の無数のアプリケーションが出力するログも混在しています。その膨大なノイズの海の中から、自分のアプリの NSLog 出力だけを探し出すのは非常に困難です。一応、プロセス名でフィルタリングはできますが、それでも使い勝手は良いとは言えません。
Swiftとの親和性の低さ: NSLog はもともとObjective-Cの関数であり、NSString のフォーマット指定子（%@, %d, %fなど）を使用します。これはSwiftの強力な型安全性や、モダンな文字列補間の恩恵を受けられないことを意味します。型の不一致によるコンパイルエラーも発生せず、実行時まで問題に気づきにくいというリスクもあります。
プライバシーへの配慮ゼロ: これが現代において最もクリティカルな問題です。NSLog は、与えられた情報をすべてそのままログに出力します。つまり、ユーザー名、メールアドレス、パスワード、認証トークンといった機密情報を誤ってログに出力してしまった場合、それらが平文でデバイスのログファイルに記録されてしまうのです。これは深刻なプライバシー侵害やセキュリティリスクに直結します。

新時代に求められるロギングとは？

print と NSLog の問題点をまとめると、現代のアプリケーション開発で求められるロギングシステムの要件が浮かび上がってきます。

ハイパフォーマンス: UIをブロックせず、アプリケーションのパフォーマンスに影響を与えないこと。
構造化とフィルタリング: ログが構造化されており、サブシステム、カテゴリ、ログレベルなどで強力にフィルタリング・検索できること。
プライバシー・バイ・デザイン: デフォルトでプライバシーが保護され、開発者が意図した場合にのみ情報が公開される仕組みであること。
Swiftフレンドリー: Swiftの型システムやモダンな構文とシームレスに連携できること。

これらの要件をすべて満たすためにAppleが開発したのが、次章で解説する Unified Logging System なのです。

第2章: Unified Logging System入門 – os.logの登場

NSLog が抱える問題を解決すべく、AppleはWWDC 2016で Unified Logging System (ULS) を発表しました。これはiOS 10、macOS 10.12、tvOS 10、watchOS 3から導入された、Appleプラットフォーム全体のログ記録を根底から刷新するシステムです。そして、このULSを利用するためのC言語スタイルのAPIが os.log ファミリです。

Unified Logging System (ULS) とは？

ULSの核心は、パフォーマンスと効率性の徹底的な追求にあります。その仕組みを簡単に見てみましょう。

遅延評価とインメモリバッファ: ログメッセージは、即座にディスクに書き込まれるわけではありません。まず、非常に高速なインメモリのリングバッファにバイナリ形式で圧縮・格納されます。ディスクへの書き込み（永続化）は、システムがアイドル状態のときや、エラーレベル以上の重要なログが記録されたときなど、最適なタイミングで非同期に行われます。これにより、NSLog のような同期的I/Oによるパフォーマンスの低下を根本的に回避しています。
カーネルレベルでの実装: ULSはアプリケーション層のライブラリではなく、OSの心臓部であるカーネルレベルで深く統合・実装されています。これにより、プロセス間のオーバーヘッドを最小限に抑え、システム全体で非常に効率的なログ収集を実現しています。
動的な制御: ログの収集レベルは、アプリケーションを再起動することなく動的に変更できます。これにより、通常は最小限のログのみを収集しておき、問題が発生した際にだけ詳細なデバッグログを有効にする、といった運用が可能になります。

`os.log` の基本的な使い方

ULSをSwiftから利用するための最初の入り口が os.log APIです。これを使うには、まず os フレームワークをインポートします。

swift import os

`OSLog` オブジェクト：サブシステムとカテゴリ

ULSでログを記録する際、最も重要な概念がサブシステム (Subsystem) と カテゴリ (Category) です。これは、ログを分類し、後でフィルタリングするための「住所」のようなものです。

サブシステム: アプリケーションやシステムの大きなコンポーネントを識別するための文字列です。通常、アプリケーションの Bundle Identifier (com.example.myapp) を指定するのがベストプラクティスです。これにより、システム上の他のログと明確に区別できます。
カテゴリ: サブシステム内の、より小さな機能単位やモジュールを分類するための文字列です。例えば、「Network」、「Database」、「ViewControllers.Profile」のように、ログの発生源を具体的に示す名前を付けます。

これらの情報を使って、OSLog オブジェクトを作成します。このオブジェクトは、ログ出力先の設定情報と考えることができます。

“`swift
// ネットワーク関連のログ設定
let networkLog = OSLog(subsystem: “com.example.myapp”, category: “Networking”)

// ユーザープロファイル画面関連のログ設定
let profileLog = OSLog(subsystem: “com.example.myapp”, category: “ProfileView”)
“`

このように OSLog オブジェクトを機能ごとに作成しておくことで、後述するコンソールアプリでのフィルタリングが非常に容易になります。

ログレベル (`OSLogType`)

ULSでは、ログの重要度を示す5つのレベルが定義されています。これを適切に使い分けることが、効率的なデバッグの鍵となります。

.default: デフォルトのログレベル。一般的な情報メッセージに使用します。このレベルのログは、最初はインメモリバッファにのみ記録されますが、.error や .fault が発生すると、関連する .default ログもディスクに保存されることがあります。
.info: より詳細な情報メッセージに使用します。パフォーマンスへの影響を避けるため、.info レベルのログはデフォルトでは収集されません。コンソールアプリや log コマンドで明示的に有効にする必要があります。デバッグ時にのみ役立つ補助的な情報に適しています。
.debug: 開発者がデバッグ目的でのみ使用するログレベルです。.info と同様、デフォルトでは収集されません。変数の中身や処理の通過点など、一時的な確認に使います。
.error: コードの実行中に発生したエラーや問題点に使用します。このレベルのログは常に収集され、ディスクに永続化されます。
.fault: システム全体に影響を及ぼすような、致命的な障害やバグに使用します。このレベルのログも常に収集され、ディスクに永続化されます。さらに、エラー発生時の追加のデバッグ情報もキャプチャされます。

`os_log` 関数による出力

OSLog オブジェクトとログレベルを準備したら、os_log 関数を使ってログを出力します。

“`swift
import os

let networkLog = OSLog(subsystem: “com.example.myapp”, category: “Networking”)

func fetchData() {
let url = “https://api.example.com/data”

// .defaultレベルで処理の開始をログ
os_log("Start fetching data from %@", log: networkLog, type: .default, url)

// ... ネットワーク処理 ...

let isSuccess = true // 仮
if isSuccess {
    // .infoレベルで成功時の詳細情報をログ
    os_log("Successfully fetched data.", log: networkLog, type: .info)
} else {
    let errorDescription = "Not Found"
    // .errorレベルでエラー情報をログ
    os_log("Failed to fetch data: %@", log: networkLog, type: .error, errorDescription)
}

}
“`

os_log のシグネチャは NSLog に似ており、C言語スタイルのフォーマット指定子（%@, %d など）を使って動的な値を埋め込みます。

プライバシーとマスキング：ULSの真価

os.log、そしてULSが NSLog と一線を画す最大の特長が、プライバシー・バイ・デザインの思想です。ULSでは、ログに出力される動的な値（文字列、数値など）は、デフォルトで <private> という文字列にマスク（墨塗り）されます。

“`swift
let userName = “Alice”
let userID = “user-12345”

// このログをデバイスで直接見ると…
os_log(“User %@ (%@) logged in.”, log: profileLog, type: .default, userName, userID)
// コンソールアプリでの表示: User () logged in.
“`

これは、開発者がうっかりユーザーの個人情報や認証トークンをログに出力してしまっても、それが平文で記録されるのを防ぐための、極めて強力な安全装置です。

では、デバッグ時に値を確認したい場合はどうすればよいのでしょうか？その場合は、フォーマット指定子に {public} という修飾子を付けます。

swift // デバッグ目的でユーザーIDのみを公開する os_log("User %@ (%{public}@) logged in.", log: profileLog, type: .default, userName, userID) // コンソールアプリでの表示: User <private> (user-12345) logged in.

この挙動は非常に重要です。

デバッガ接続時: Xcodeからデバッガをアタッチして実行している間は、マスクは無効になり、すべての値がコンソールに表示されます。これにより、開発中のデバッグ体験は損なわれません。
非デバッガ時（リリース環境など）: デバッガが接続されていない場合、{public} が付与された値のみが表示され、他はすべて <private> となります。

これにより、「開発中は見たい、でもリリース後は隠したい」という要求を、ログ出力のコードレベルで安全に満たすことができるのです。

コンソールアプリと `log` コマンドでの活用

ULSの真価は、macOSに標準で搭載されている「コンソール」アプリと組み合わせることで最大限に発揮されます。コンソールアプリを使えば、収集されたログを強力なUIで分析できます。

デバイスログの表示: iPhoneやiPadをMacに接続すれば、そのデバイスのライブログをストリーミング表示したり、過去のログを取得したりできます。
強力なフィルタリング: os.log で設定したサブシステムとカテゴリを使って、膨大なログの中から自分のアプリのログだけを瞬時に絞り込めます。さらに、ログレベル（Error, Faultなど）やプロセス名、タイムレンジでのフィルタリングも可能です。
保存と共有: フィルタリングしたログを .logarchive という形式で保存し、他の開発者と共有することもできます。

また、ターミナルから log コマンドを使えば、より高度でスクリプタブルなログ操作が可能です。

“`bash

自分のアプリのログをリアルタイムでストリーミング表示

$ log stream –predicate ‘subsystem == “com.example.myapp”‘

Networkingカテゴリのエラーとフォルトだけを表示

$ log stream –predicate ‘subsystem == “com.example.myapp” and category == “Networking”‘ –level error
“`

`os.log` の課題

os.log とULSは画期的なシステムですが、特にSwift開発者にとっては、いくつかの課題が残されていました。

C言語スタイルのAPI: os_log 関数やフォーマット指定子は、明らかにC言語の影響を強く受けており、Swiftのモダンな構文とは馴染みません。
書式指定子の煩雑さ: %@ や %{public}d といった書式指定子を覚える必要があり、タイプミスもしやすいです。Swiftの文字列補間に慣れた開発者には苦痛です。
OSLog オブジェクトの管理: ログを出力するたびに、対応する OSLog オブジェクトを渡す必要があり、コードが冗長になりがちです。

これらの課題を解決し、ULSのパワーをSwiftの世界に完全に解き放つために登場したのが、次章で解説する Logger 構造体です。

第3章: Swiftの新常識 – Logger構造体の導入

WWDC 2020で、AppleはついにSwift開発者が待ち望んでいたものを発表しました。それが OSLog フレームワークに含まれる Logger 構造体です。これは iOS 14 / macOS 11 以降で利用可能な、ULSをSwiftから利用するためのモダンで直感的なAPIです。

Logger は os.log を内部的に利用するラッパーですが、単なるシンタックスシュガーではありません。Swiftの言語機能、特に文字列補間 (String Interpolation) を最大限に活用することで、ログ出力の体験を革命的に向上させました。

`Logger` の基本的な使い方

Logger を使うには、新しい OSLog フレームワークをインポートします。（従来の os ではなく OSLog ですが、os でも利用可能です）

swift import OSLog

Logger インスタンスの作成は OSLog オブジェクトの作成と似ています。サブシステムとカテゴリを指定します。

swift let logger = Logger(subsystem: "com.example.myapp", category: "PurchaseFlow")

そして、ここからが Logger の真骨頂です。ログの出力は、ログレベルに対応したメソッドを呼び出す形で行います。

“`swift
func processPurchase(productID: String) {
logger.info(“Starting purchase process for product ID: (productID)”)

do {
    // ... 購入処理 ...
    try performPurchase()
    logger.notice("Purchase successful for product ID: \(productID)")
} catch {
    // エラーオブジェクトを直接渡せる
    logger.error("Purchase failed: \(error.localizedDescription)")
}

}
“`

os_log と比較して、コードがどれほどクリーンで直感的になったかは一目瞭然です。ログレベルは以下のようなメソッドに対応しています。

Logger メソッド	対応する OSLogType	説明
`trace`	– (Debug相当)	Swift 5.7で追加。非常に詳細なトレース情報。
`debug`	`.debug`	デバッグ情報。デフォルトでは記録されない。
`info`	`.info`	補助的な情報。デフォルトでは記録されない。
`notice`	`.default`	デフォルトレベル。通常運用時の有益な情報。
`warning`	`.error`	潜在的な問題を示す警告。Errorとして記録される。
`error`	`.error`	処理の失敗など、修正が必要なエラー。
`critical`	`.fault`	重大なエラー。Faultとして記録される。
`fault`	`.fault`	アプリケーションやシステムのクラッシュにつながる致命的な障害。

文字列補間の革命：究極の利便性と安全性

Logger が os.log を完全に凌駕する最大の理由が、カスタム文字列補間への対応です。これにより、os.log の煩雑なフォーマット指定子は完全に不要になりました。

プライバシー制御の進化

os.log では {public} 修飾子を使ってプライバシーを制御しましたが、Logger ではこれを文字列補間の中で、よりSwiftらしく、より安全に行えます。

思い出してください。ULSの基本は「デフォルトでプライベート」です。Logger もこの原則に忠実に従います。

“`swift
let user = User(name: “Bob”, email: “[email protected]”)

// このままログ出力すると…
logger.info(“User info: (user.name), (user.email)”)
// コンソールアプリでの表示: User info: , “`

変数はすべて自動的にマスクされます。では、公開したい場合はどうするのか？簡単です。補間する変数に privacy パラメータを追加します。

swift // 名前だけ公開し、メールアドレスはプライベートに保つ logger.info("User name: \(user.name, privacy: .public), email: \(user.email)") // コンソールアプリでの表示: User name: Bob, email: <private>

この構文は非常に優れています。
* 可読性: どの情報が公開されるのかが一目瞭然です。
* 安全性: privacy を指定し忘れても、デフォルトで安全な側（プライベート）に倒れます。
* 柔軟性: 公開したい情報と隠したい情報を、変数単位で細かく制御できます。

さらに、privacy には .public 以外にも高度なオプションが用意されています。

.private(mask: .hash): 値をそのまま記録する代わりに、ハッシュ値を記録します。これにより、個人を特定せずに、同じ値が何回ログに出力されたかを追跡できます。
.private(mask: .none): 型情報だけを記録します（例: String）。

swift // emailをハッシュ化して記録 logger.info("User name: \(user.name, privacy: .public), email hash: \(user.email, privacy: .private(mask: .hash))")

パフォーマンスへの配慮：遅延評価の魔法

「文字列補間はパフォーマンスが悪いのでは？」と心配するかもしれません。通常の文字列補間では、"Hello \(name)" というコードは、その行が実行されるたびに name を含む新しい文字列を生成します。もしログが無効なレベル（例: debug）で呼び出された場合、この文字列生成は無駄なコストになります。

Logger はこの問題をエレガントに解決しています。Logger のメソッドが受け取る文字列は、通常の String ではなく、特殊な OSLogMessage 構造体です。そして、Swiftのコンパイラは logger.debug("...") のようなコードを、OSLogInterpolation という特殊な補間ハンドラを使うように変換します。

このハンドラは、ログメッセージの各部分（リテラル部分と補間された変数）を、文字列として連結する前に、まず構造化されたデータとして保持します。そして、実際にログが記録されるかどうかをULSに問い合わせます。

ログレベルが有効な場合: 初めて構造化データを完全な文字列に変換し、ULSに渡します。
ログレベルが無効な場合（例: debug ログがオフになっている）: 文字列への変換処理は一切行われません。ハンドラは即座に処理を中断し、オーバーヘッドはほぼゼロになります。

つまり、以下のようなコードを書いてもパフォーマンス上の心配は不要です。

swift // この関数は、debugログが有効な時「だけ」呼び出される logger.debug("Current state: \(self.generateComplexDebugDescription())")

generateComplexDebugDescription() という重い処理があったとしても、debug ログが無効な環境（リリースビルドなど）では、この関数が呼び出されること自体がありません。これを遅延評価 (Lazy Evaluation) と呼びます。

この仕組みのおかげで、開発者はパフォーマンスを気にすることなく、コード内に豊富で詳細なデバッグ情報を埋め込むことができるのです。

`Logger` を使った実践的なロギング戦略

Logger をプロジェクトに導入する際の、いくつかのベストプラクティスを紹介します。

`Logger` インスタンスの管理

毎回 Logger(subsystem: ..., category: ...) と書くのは冗長です。Logger インスタンスを効率的に管理する方法はいくつかあります。

1. 静的プロパティとして拡張で定義する

機能ごとにカテゴリを分けた Logger を、extension を使って一箇所にまとめて定義する方法です。

“`swift
import OSLog

extension Logger {
private static var subsystem = Bundle.main.bundleIdentifier!

/// ネットワーク通信に関するログ
static let network = Logger(subsystem: subsystem, category: "Network")

/// データベース操作に関するログ
static let database = Logger(subsystem: subsystem, category: "Database")

/// UI関連のログ
static let ui = Logger(subsystem: subsystem, category: "UI")

}
“`

こうすることで、コードのどこからでもタイプセーフに、意図した Logger を呼び出せます。

swift // 呼び出し例 Logger.network.info("Request sent.") Logger.ui.debug("Button tapped.")

2. DI (Dependency Injection) を利用する

より大規模なアプリケーションや、テスト容易性を重視する場合は、依存性注入（DI）パターンを使って Logger を各クラスに注入するのも良い方法です。

“`swift
class MyViewModel {
private let logger: Logger

init(logger: Logger = Logger(subsystem: "com.example.myapp", category: "MyViewModel")) {
    self.logger = logger
}

func doSomething() {
    logger.info("Doing something...")
}

}
“`

エラーハンドリングとの統合

Swiftの do-try-catch構文と Logger は非常に相性が良いです。catch 節でエラーを捕捉し、その内容をログに出力するのは基本的なエラーハンドリングのパターンです。

swift func saveUserData(_ user: User) { do { try databaseManager.save(user) Logger.database.info("Successfully saved user: \(user.id, privacy: .public)") } catch { // Errorプロトコルに準拠したオブジェクトを直接補間に渡せる // localizedDescriptionはユーザーに見せる可能性のある情報なので、publicにすることが多い Logger.database.error("Failed to save user \(user.id, privacy: .public): \(error.localizedDescription, privacy: .public)") // より詳細なエラー情報を開発者向けにログする Logger.database.debug("Detailed error info: \(String(reflecting: error))") } }

第4章: ログ戦略のまとめとベストプラクティス

ここまで、print から NSLog、そして os.log と Logger へと至るログ出力技術の進化を見てきました。最後に、これらの技術をどのように使い分け、効果的なログ戦略を立てるべきかをまとめます。

`print` vs `NSLog` vs `os.log` vs `Logger` 比較表

機能/項目	`print`	`NSLog`	`os.log` (`os_log`)	`Logger` (iOS 14+)
パフォーマンス	△ (比較的軽量だが同期)	✖ (非常に重い、同期I/O)	◎ (超高速、非同期、遅延評価)	◎ (超高速、非同期、遅延評価)
コンテキスト情報	✖ (なし)	〇 (タイムスタンプ, PIDなど)	◎ (タイムスタンプ, PID, サブシステム, カテゴリ)	◎ (タイムスタンプ, PID, サブシステム, カテゴリ)
フィルタリング	✖ (不可)	△ (プロセス名などで限定的)	◎ (サブシステム, カテゴリ, レベル等で強力)	◎ (サブシステム, カテゴリ, レベル等で強力)
プライバシー保護	✖ (なし、すべて公開)	✖ (なし、すべて公開)	◎ (デフォルトで `<private>`、`{public}`で公開)	◎ (デフォルトでプライベート、`privacy`で制御)
Swiftとの親和性	◎ (ネイティブ)	△ (C言語スタイル, フォーマット指定子)	△ (C言語スタイル, フォーマット指定子)	◎ (Swiftネイティブ, 文字列補間)
ログレベル	✖ (なし)	✖ (なし)	◎ (5段階)	◎ (8段階)
推奨利用シーン	Playground、一時的なデバッグのみ	レガシーコードの保守のみ	iOS 10-13 をサポートするプロジェクト	iOS 14以降をサポートする全プロジェクト
ひとこと	手軽だが機能不足	時代遅れで危険	ULSの力を引き出すがAPIが古い	現代のSwiftロギングの決定版

いつ、何を使うべきか？

上記の比較表を踏まえ、プロジェクトの要件に応じた最適な選択は以下のようになります。

print: Playgroundでのコード片の動作確認や、数行書いてすぐに消すような、ごく一時的なデバッグ用途に限定してください。プロダクトコードとしてコミットしてはいけません。
NSLog: 新規のプロジェクトで採用する理由は一切ありません。Objective-Cで書かれた非常に古いプロジェクトや、NSLog の出力に依存している既存のツールをメンテナンスする場合にのみ、限定的に使用を検討する程度です。
os.log: アプリケーションが iOS 13以前をサポートする必要がある場合の第一選択肢です。ULSのパフォーマンスとプライバシー保護の恩恵を受けられるため、NSLog よりもはるかに優れた選択です。APIの古さは許容する必要があります。
Logger: iOS 14 / macOS 11 以降をメインターゲットとする、すべてのSwiftプロジェクトにおけるデファクトスタンダードです。Swiftらしい直感的な構文、遅延評価による最高のパフォーマンス、そして文字列補間による柔軟かつ安全なプライバシー制御。これらすべてを兼ね備えたLogger を使わない手はありません。

効果的なロギングのためのヒント

最後に、日々の開発で役立つロギングのヒントをいくつか紹介します。

ログレベルを正しく使い分ける: 何でもかんでも .error や .fault でログするのはやめましょう。ログの重要度に応じて .debug, .info, .notice, .error などを適切に使い分けることで、コンソールアプリでのフィルタリングが格段に効果的になります。
サブシステムとカテゴリを設計する: プロジェクトの初期段階で、ログの分類ルールを決めておきましょう。Logger.network, Logger.database のように、機能モジュールごとにカテゴリを分けることで、将来のデバッグ作業が劇的に楽になります。
プライバシーを常に意識する: Logger はデフォルトで安全ですが、油断は禁物です。ログに含めるすべての動的データについて、「これは公開して良い情報か？」と自問自答する癖をつけましょう。個人情報や機密情報は、原則として .public を付けないようにします。
ログは「未来の自分や同僚へのメッセージ」: 「処理失敗」のような曖昧なログではなく、「商品ID: xxxx の在庫更新に失敗。理由: データベース接続タイムアウト」のように、何が (What)・なぜ (Why) 起こったのかが分かる十分なコンテキスト情報を含めましょう。
パフォーマンスクリティカルな場所を理解する: Logger は非常に高速ですが、それでも何百万回も回るようなタイトなループの中でのログ出力は慎重になるべきです。そうした場所では、ログレベルを .debug や .trace に設定し、通常運用時にはログが出力されないようにするのが賢明です。
サードパーティライブラリより純正を優先する: CocoaLumberjackのような高機能なサードパーティ製ロギングライブラリも存在しますが、ULSと Logger はOSレベルで深く統合されており、パフォーマンスとシステム連携の面で圧倒的な優位性を持ちます。特別な理由がない限り、Apple純正のロギングシステムを利用することを強く推奨します。

結論

Swiftにおけるログ出力の世界は、print や NSLog が主流だった時代から、os.log を経て、ついに Logger という完成された形へと大きな進化を遂げました。この進化は、単なるAPIの見た目の変化ではありません。パフォーマンス、セキュリティ（プライバシー）、開発効率という、モダンなアプリケーション開発に不可欠な三つの要素を、かつてない高いレベルで満たすための必然的な進化でした。

NSLog は、そのパフォーマンスの低さとプライバシーへの配慮の欠如から、もはや過去の遺物と言わざるを得ません。一方で、Logger とその背後にあるUnified Logging Systemは、Swiftの言語機能と見事に融合し、開発者に最高のデバッグ体験を提供します。遅延評価によるパフォーマンス、デフォルトで安全なプライバシー制御、そしてサブシステムとカテゴリによる強力な構造化。これらは、もはや現代のiOS/macOS開発者にとっての「常識」です。

もしあなたのプロジェクトがまだ NSLog や print に依存しているなら、今が移行の絶好の機会です。Logger を導入することは、単にログ出力の方法を変えるだけではありません。それは、より高品質で、より安全なアプリケーションを、より効率的に開発・保守するための、未来への投資です。さあ、古い常識を捨て、Logger がもたらすモダンで洗練されたログ出力の世界へ踏み出しましょう。

NSLogはもう古い？Swiftのログ出力はos.logとLoggerが新常識

はじめに

第1章: なぜNSLogやprintはもう古いのか？

print の限界

NSLog が抱える深刻な問題

新時代に求められるロギングとは？

第2章: Unified Logging System入門 – os.logの登場

Unified Logging System (ULS) とは？

os.log の基本的な使い方

OSLog オブジェクト：サブシステムとカテゴリ

ログレベル (OSLogType)

os_log 関数による出力

プライバシーとマスキング：ULSの真価

コンソールアプリと log コマンドでの活用

自分のアプリのログをリアルタイムでストリーミング表示

Networkingカテゴリのエラーとフォルトだけを表示

os.log の課題

第3章: Swiftの新常識 – Logger構造体の導入

Logger の基本的な使い方

文字列補間の革命：究極の利便性と安全性

プライバシー制御の進化

パフォーマンスへの配慮：遅延評価の魔法

Logger を使った実践的なロギング戦略

Logger インスタンスの管理

エラーハンドリングとの統合

第4章: ログ戦略のまとめとベストプラクティス

print vs NSLog vs os.log vs Logger 比較表

いつ、何を使うべきか？

効果的なロギングのためのヒント

結論

コメントする 返信をキャンセル

`print` の限界

`NSLog` が抱える深刻な問題

`os.log` の基本的な使い方

`OSLog` オブジェクト：サブシステムとカテゴリ

ログレベル (`OSLogType`)

`os_log` 関数による出力

コンソールアプリと `log` コマンドでの活用

`os.log` の課題

`Logger` の基本的な使い方

`Logger` を使った実践的なロギング戦略

`Logger` インスタンスの管理

`print` vs `NSLog` vs `os.log` vs `Logger` 比較表

コメントする返信をキャンセル