DEV Community: Klakk 開発チーム

macOSメニューバーアプリの「無効化」でAudioEngineまで止めない理由

Klakk 開発チーム — Thu, 06 Aug 2026 11:26:52 +0000

キー入力に短い効果音を付けるmacOSアプリでは、「無効化」をどこまで停止させるかが設計上の分岐になります。Event Tapだけを止めるのか、AVAudioEngineとPlayer Nodeも止めるのか、準備済みPCMバッファまで破棄するのか。

この記事では、有料MacアプリKlakkの現在の実装を例に、メニューバーから無効化したときに入力監視だけを停止し、Audio Engineを維持している理由と、その代わりに残る境界を整理します。

私はKlakkの開発者本人です。記事末尾に自社製品へのリンクがあります。

無効化で止めたいものを先に分ける

現在のKlakkでは、メニューバーの切り替えが次の3層に影響します。

AppSettings.shared.isKlakkEnabled の永続状態
KeyboardMonitor のEvent TapとRunLoop Source
メニュー表示とAnalyticsイベント

一方、AudioEngine.shared.stop() はこの切り替えから呼びません。

@objc private func toggleKlakk(_ sender: NSMenuItem?) {
    AppSettings.shared.isKlakkEnabled.toggle()
    AnalyticsService.shared.trackKlakkToggle(
        enabled: AppSettings.shared.isKlakkEnabled
    )

    if AppSettings.shared.isKlakkEnabled {
        KeyboardMonitor.shared.startMonitoring()
    } else {
        KeyboardMonitor.shared.stopMonitoring()
    }

    statusItem?.menu = createMenu()
}

ここでの「無効化」は、次のキー入力から新しい音をトリガーしないことを主目的にしています。

Event Tapを無効化するだけでは足りない

KeyboardMonitor.stopMonitoring() は、CGEvent.tapEnable(..., false)だけでは終わりません。

func stopMonitoring() {
    guard isMonitoring else { return }

    if let eventTap {
        CGEvent.tapEnable(tap: eventTap, enable: false)
        CFMachPortInvalidate(eventTap)
    }

    if let runLoopSource {
        CFRunLoopRemoveSource(
            CFRunLoopGetCurrent(),
            runLoopSource,
            .commonModes
        )
    }

    self.eventTap = nil
    self.runLoopSource = nil
    isMonitoring = false

    pressedKeys.removeAll()
    previousModifierFlags = []
}

Event Tapを無効化し、Mach Portをinvalidateし、RunLoop Sourceを外します。さらに、押下中キーと修飾キーの前回状態を破棄します。

最後の二つがないと、再有効化後に「前回のセッションで押されたまま」と判断し、最初のkeyDownを重複扱いする可能性があります。監視セッションを跨いで入力状態を持ち越さないことが重要です。

Audio Engineを維持する理由

KlakkのAudio Engineは、起動後に音声ファイルをPCMバッファへ準備し、固定のAVAudioPlayerNodeプールを使います。無効化のたびにEngine全体を止めて再構築すると、次の有効化で準備コストと失敗点が増えます。

出力デバイスの再確認
Audio Formatの再構築
Player Nodeの再接続
Engine startの失敗処理
最初の一音までの遅延

入力監視を止めれば、新しいキーイベントはAudio Engineへ届きません。そのため、短い一時停止ではEngineと準備済みバッファを維持し、次の再開を軽くしています。

アプリ終了時やAudio Engine自体のクリーンアップでは、別のstop()がProperty Listener、Player Node、Engineを停止します。

func stop() {
    if let listener = defaultDevicePropertyListener {
        AudioObjectRemovePropertyListener(
            AudioObjectID(kAudioObjectSystemObject),
            &address,
            listener,
            nil
        )
        defaultDevicePropertyListener = nil
    }

    for playerNode in playerNodePool {
        playerNode.stop()
    }
    audioEngine.stop()
}

メニューバーの一時無効化と、Audio System全体の終了を同じ操作にしていません。

「即時停止」の境界

この設計で確実に止まるのは、新しいキーイベントによる追加再生です。

一方、無効化した瞬間にすでにPlayer Nodeへscheduleされている短い音は、現在の実装ではその末尾まで再生される可能性があります。KeyboardMonitor.stopMonitoring()はPlayer Nodeへstop()を送らないためです。

したがって、UI文言やテストで「無効化した瞬間に全サンプルがゼロフレームで切れる」とは約束できません。必要要件が厳密なミュートなら、次の選択肢を別に設計する必要があります。

全Player Nodeを停止する
Mixer Volumeを即座に0へ下げる
短いfade-outを入れる
再有効化時にNodeとschedule状態を再同期する

ただし、クリックノイズ、再開遅延、同時実行との競合が増えるため、単純なaudioEngine.stop()だけでは終わりません。

権限の撤回は別のライフサイクル

ユーザーがInput Monitoring権限を取り消した場合は、単なる一時無効化とは違います。現在の実装は定期的に権限を確認し、撤回を検出したら監視を止めます。完全停止用のstopMonitoringCompletely()では権限確認Timerも停止し、wasMonitoringもリセットします。

UI上の「無効」、権限の撤回、アプリ終了を一つのBooleanへ押し込まないほうが、再開条件を説明しやすくなります。

まとめ

短いメニューバーアプリでは、無効化を「すべてのサブシステムを破棄する操作」と考えないほうが扱いやすい場合があります。

入力監視を止めて、新しいトリガーを遮断する
Event TapとRunLoop Sourceを確実に破棄する
押下中キーとModifier状態をリセットする
Audio EngineとPCM準備状態は短い再開のため維持する
再生中サンプルの末尾は残る可能性を仕様境界として扱う
権限撤回とアプリ終了は別の停止経路にする

KlakkはMacから追加の打鍵音を再生するアプリです。実物のキーボードのスイッチ、重さ、打鍵感、物理音は変えません。ASMRや集中しやすさには個人差があり、ADHDを含む症状の診断、治療、改善を目的とした医療製品ではありません。

低遅延の打鍵音をAVAudioPlayerNodeプールで重ねる設計

Klakk 開発チーム — Thu, 06 Aug 2026 08:05:33 +0000

Macでキー入力に合わせて短い効果音を鳴らすとき、毎回ファイルを開いてプレイヤーを作ると、入力のホットパスにI/Oと初期化が入り込みます。この記事では、私が有料macOSアプリKlakkで使っている現在の構成を題材に、事前準備したPCMバッファとAVAudioPlayerNodeの固定プールをどう分けたかを整理します。

1. キー入力より前に音を準備する

再生時に必要なのは、キーコードからすでに変換済みのバッファを引くことだけにします。

private struct PreparedKeySound {
    let buffer: AVAudioPCMBuffer
    let outputGain: Float
}

private var preparedKeySounds: [String: PreparedKeySound] = [:]
private let stateLock = NSLock()

サウンドパックを読み込む段階で、ファイルの読み込み、必要区間の切り出し、出力フォーマットへの変換、先頭の無音除去、音量係数の計算まで済ませます。再生時に変換を始めないことが一番大きな分離です。

辞書の入れ替えは一度組み立ててから短いロック内で行います。

let preparedSounds = try prepareKeySounds(for: soundPack)

stateLock.lock()
currentSoundPack = soundPack
preparedKeySounds = preparedSounds
loggedMissingKeys.removeAll()
stateLock.unlock()

これなら、別のサウンドパックを読み込んでいる途中の半端な辞書を再生側が見ることはありません。

2. Player Nodeを固定数だけ先に接続する

現在の実装では、起動時に10個の AVAudioPlayerNode を作り、同じ mainMixerNode へ接続しています。

private var playerNodePool: [AVAudioPlayerNode] = []
private let maxConcurrentSounds = 10
private var currentNodeIndex = 0

for _ in 0..<maxConcurrentSounds {
    let node = AVAudioPlayerNode()
    audioEngine.attach(node)
    audioEngine.connect(node, to: audioEngine.mainMixerNode, format: nil)
    playerNodePool.append(node)
}

ノードのattach/connectをキー入力のたびに行わず、入力後はラウンドロビンで次のノードを選びます。

let node = playerNodePool[currentNodeIndex]
currentNodeIndex = (currentNodeIndex + 1) % maxConcurrentSounds

node.stop()
node.volume = masterVolume * preparedSound.outputGain * backgroundModeMultiplier
node.scheduleBuffer(preparedSound.buffer, at: nil, options: [])
node.play()

短い音が重なる通常のタイピングでは、一つのノードだけを使うより前の音を切りにくくなります。

3. 固定プールの限界も仕様にする

この方式は無限に音を重ねません。11個目が10個の再生時間内に来れば、ラウンドロビンで戻ったノードを stop() するため、そのノードの古い音は途中で終わります。

これは単純さと上限の明確さを選んだ結果です。改善案としては次の選択肢があります。

再生中でないノードを優先して探す
最も古いノードだけを再利用する
音の長さに応じてプール数を測定で決める
同時発音数、切断数、再生遅延をテストで記録する

また、currentNodeIndex と音量値へ複数キューから同時に触れる設計へ広げるなら、プレイヤー操作だけでなくアプリ側の状態にも直列化が必要です。「AVAudioPlayerNodeを使っているから全状態が安全」とは扱いません。

4. Engine停止時は、その一音を捨てる

出力デバイス変更などでEngineが止まっていたら、現在の実装は再起動を一度だけ要求し、そのキーの音は再生しません。

guard audioEngine.isRunning else {
    restartLock.lock()
    let shouldRestart = !isRestarting
    if shouldRestart { isRestarting = true }
    restartLock.unlock()

    if shouldRestart { restartAudioEngine() }
    return
}

停止中の入力を後からまとめて鳴らすより、次のキーから正常に戻る方が打鍵フィードバックには自然だからです。再起動中フラグをロックで守り、同時に複数の再起動を走らせないことも重要です。

まとめ

低遅延化は「速いAPIを呼ぶ」だけではなく、キー入力後にしないことを決める作業でした。

ファイルI/O、変換、無音除去、ゲイン計算を事前に終える
Player Nodeを固定数だけattach/connectしておく
再生時は辞書参照、音量設定、schedule/playに限定する
プール上限とEngine再起動時の欠落を隠さない

開発者による開示: 私はKlakkの開発者です。Klakkは14種類の打鍵音を切り替えられる有料Macアプリです。ソフトウェアが追加音を再生するもので、実物のキーボードの物理音や打鍵感は変えません。ASMRや集中の感じ方には個人差があり、ADHDを含む症状を改善する医療製品ではありません。

macOSのInput Monitoring判定で、2つのAPIと「実際に動くか」を分けて観察する

Klakk 開発チーム — Thu, 06 Aug 2026 03:58:33 +0000

macOSでグローバルなキーイベントを受け取るアプリを作ると、権限判定を単純な Bool として扱いたくなります。しかし実装と検証を進めるほど、次の3つは分けて考えた方が安全でした。

TCC上で権限がどう見えているか
ユーザーへ権限を要求した直後か
CGEvent.tapCreate が実際に成功し、イベントを受け取れるか

この記事では、macOS向け打鍵音アプリを作る過程で使った診断方法を、製品固有のUIから切り離して整理します。

2つの事前確認API

Listen-onlyのイベント監視では、次の2つを並べて観察できます。

import CoreGraphics
import IOKit.hidsystem

struct InputMonitoringStatus {
    let hid: IOHIDAccessType
    let cgGranted: Bool

    var looksGranted: Bool {
        hid == kIOHIDAccessTypeGranted || cgGranted
    }
}

func readInputMonitoringStatus() -> InputMonitoringStatus {
    InputMonitoringStatus(
        hid: IOHIDCheckAccess(kIOHIDRequestTypeListenEvent),
        cgGranted: CGPreflightListenEventAccess()
    )
}

ここで重要なのは、looksGranted を「監視が必ず動く」という保証にしないことです。これはあくまで事前状態の観察結果です。プロセス、署名、実行パス、権限変更直後の状態などを切り分けるために、2つの値を別々にログへ残します。

ログへ記録するなら、入力内容ではなく次のような診断情報だけで十分です。

bundle_id=com.example.app
hid_status=granted
cg_preflight=true
event_tap_created=true

キーコード、入力文字列、前後のアプリ名まで診断ログへ入れる必要はありません。

権限要求は「確認」と分ける

要求側のAPIは、確認のたびに呼ぶのではなく、初回案内やユーザーが明示的に「権限を開く」を選んだ時だけ呼びます。

func requestInputMonitoring() {
    let hidRequested = IOHIDRequestAccess(kIOHIDRequestTypeListenEvent)
    let cgRequested = CGRequestListenEventAccess()

    let current = readInputMonitoringStatus()
    print("hidRequested=\(hidRequested), cgRequested=\(cgRequested)")
    print("looksGranted=\(current.looksGranted)")
}

要求APIの戻り値だけで次の画面を決めると、ユーザーがシステム設定へ移動して後から許可した場合を扱いにくくなります。要求後は、アプリ側の状態を次のように分けました。

notRequested: まだ案内していない
waitingForUser: システム設定での操作待ち
preflightGranted: 事前確認では許可済み
monitoring: Event Tapが作成され、監視中
revoked: 監視中に権限を失った

最終判定はEvent Tapの生成結果

事前確認が通っていても、Event Tapの作成失敗は別の事実として扱います。

let mask = (1 << CGEventType.keyDown.rawValue)
         | (1 << CGEventType.keyUp.rawValue)
         | (1 << CGEventType.flagsChanged.rawValue)

let tap = CGEvent.tapCreate(
    tap: .cgSessionEventTap,
    place: .headInsertEventTap,
    options: .listenOnly,
    eventsOfInterest: CGEventMask(mask),
    callback: callback,
    userInfo: context
)

guard let tap else {
    // 権限表示だけでなく、署名・実行パス・再起動要否も切り分ける
    return
}

.listenOnly はイベントを書き換えない設計を表せますが、プライバシー説明の代わりにはなりません。アプリが何を処理し、何を保存せず、何を外部送信しないのかは別途明記する必要があります。

権限変更をポーリングする場合

システム設定を開いた後にアプリへ戻ってもらう導線では、短い間隔で状態を再確認する実装が分かりやすいです。ただし、次の境界を決めておきます。

Timerを重複生成しない
監視開始後は要求用Timerを停止する
権限喪失時はEvent TapとRunLoop Sourceを破棄する
復旧時はユーザー設定が有効な場合だけ監視を再開する
アプリ終了時はTimerも明示的に破棄する

「権限がある」と「監視中」を同じフラグにすると、権限喪失後のUIと実体がずれやすくなります。権限状態、Event Tapの生存状態、ユーザーが機能をオンにしているかを別々に持つ方が復旧処理を書きやすくなりました。

まとめ

IOHIDCheckAccess と CGPreflightListenEventAccess は診断のため別々に観察する
要求APIは確認ループから分離し、ユーザー操作に結び付ける
事前確認が通っていても、Event Tap生成結果を最終的な動作判定にする
権限、監視状態、ユーザー設定を別の状態として管理する
入力内容を診断ログやAnalyticsへ混ぜない

この記事は、macOS向け打鍵音アプリ Klakk の開発チームが、実装中に得た知見を一般化してまとめたものです。自社の有料製品へのリンクを含みます。

ブラウザ試聴: https://tryklakk.com/ja/#demo
Mac App Store: https://apps.apple.com/jp/app/id6754638652?pt=127956280&ct=jp-dev-input-permission-20260806&mt=12
プライバシーポリシー: https://tryklakk.com/ja/privacy/

Klakkは物理キーコードと押下・解放状態をローカルで処理し、入力文字列を組み立てたり送信したりしません。ソフトウェアの音を追加する製品であり、物理キーボード自体の音や打鍵感は変えません。