sound codexの通知音設定と鳴らないときの原因別確認手順

sound codexで探す通知音はどの機能か

「sound codex」という検索だけでは、作業完了を知らせる音、声で依頼する機能、回答を声で聞く機能のどれを求めているかが分かりません。コードの調査や修正が一区切りついたら別の作業から戻りたい、という目的なら、最初に確認するのは通知です。音声入力を有効にしても、完了時の知らせ方が同じように変わるとは限りません。

OpenAIの通知の公式資料は、通知の操作や届け方が利用する画面によって異なると説明しています。本記事の設定例はCodex CLIの対話画面を対象にします。デスクトップアプリやスマホ側に同じ設定項目がある、という前提では読み進めないでください。どの画面から作業を始めたかを確認することが、設定の取り違えを防ぎます。

通知音と読み上げを分けて選ぶ

通知音は、作業へ注意を戻すための短い合図です。一方、読み上げは返答の内容を声で聞く用途で、音声入力は自分の声を依頼に使う用途です。何を知らせたいかを「作業が終わったら気づく」「承認を待っていたら戻る」のように具体化すると、通知の設定で足りるか判断できます。マイクの許可や音声の種類を変える前に、欲しい合図の役割を決めましょう。

なぜ今、利用する画面まで確かめるのか

公式更新履歴の2026年10月7日分では、iOSでCodexのタスクリンクを直接開く機能や、選択肢を明確にした承認画面が案内されています。これは通知音の新機能の発表ではありません。ただ、PCとスマホを行き来して作業を確認するなら、どこで作業し、どこで知らせを受けたいかを整理する機会になります。以下のCLI設定をスマホにも共通する設定として扱わないことが大切です。

Codex CLIの通知を決める三つの設定

CLIの通知を調べるときは、通知が有効か、どの方式で端末へ知らせるか、どんな状態で知らせるかを分けます。一つの項目だけを変えても、残りの条件で通知が出ない場合があります。たとえば通知対象に完了が含まれていても、画面が選択された状態では通知しない条件なら、目の前で短い依頼を試しただけでは気づけません。

設定名と値は公式設定リファレンスで照合できます。既存の設定ファイルに追記するときは、同じ項目を重ねて記述しないようにします。すでに通知の設定があるなら、その値を記録してから必要な項目だけを変更してください。複数の条件を同時に変えると、どれが結果に効いたかが分からなくなります。

通知対象は完了と承認待ちから考える

tui.notificationsは通知の有効・無効を決め、配列で通知するイベントを絞ることもできます。公式の詳細資料にある例はagent-turn-completeとapproval-requestedです。作業の一区切りだけを知りたいなら前者から試し、途中で判断を求められる場面も見逃したくないなら後者を検討します。どちらも、音によって結果の正しさを保証するものではありません。

通知方式は端末の対応と組み合わせる

tui.notification_methodにはauto、osc9、belが用意されています。公式資料によると、autoはOSC 9を優先し、対応状況に応じてBELへ切り替えます。OSC 9は一部の端末でデスクトップ通知として扱われる信号で、BELはベルの信号です。ただし、ベルが音になるか、表示だけになるか、何も起きないかは端末側の扱いにも左右されます。まずautoで試し、必要がある場合に方式を変えて比べます。

フォーカス条件で通知の出る場面が変わる

tui.notification_conditionの値はunfocusedとalwaysで、公式リファレンス上の既定値はunfocusedです。通常は端末にフォーカスがないときに通知する条件なので、テスト中にずっと端末を選択していると通知が出ない場合があります。alwaysはフォーカスにかかわらず通知する条件です。切り分けの間だけalwaysにして確認し、日常利用では作業中に何度も知らせる必要があるかで選びます。

完了通知を短い依頼で試す手順

通知音を確認するために大きなコード修正を依頼する必要はありません。短い説明を返す依頼なら、結果をすぐ確認でき、通知のためだけに不要な変更を増やさずに済みます。テスト中は通知対象を一つに絞り、完了の合図が出たかを見ます。返答が表示された時刻と、端末が選択されていたかも一緒に記録すると再現しやすくなります。

以下はCLIの対話画面で完了通知を試すための設定例です。普段使っている設定ファイルの該当項目を編集し、既存の[tui]があればその中へ統合します。変更した値が読み込まれた状態で、短い依頼を試してください。書いた直後に、すでに開いている画面へ必ず反映されるとは考えず、確認用の画面を開き直す方法が分かりやすいでしょう。

[tui]
notifications = ["agent-turn-complete"]
notification_method = "auto"
notification_condition = "always"

Step 1: 現在の通知設定を記録する

編集前に、通知対象・方式・条件の値と、使っている端末名を控えます。通知に関する項目が見つからない場合も、「未記入」と記録すれば比較できます。設定ファイル全体を置き換える必要はありません。通知以外の値を触らず、今回変更した部分を後から戻せるようにしておくと、作業への影響を小さくできます。

Step 2: 完了だけを通知する設定で試す

上の例を参考に、完了通知を有効にして条件をalwaysにします。依頼は「このフォルダーの役割を短く説明してください。ファイルは変更しないでください」のような読み取り中心の内容にします。返答が出たら、音、画面上の通知、どちらも出ない、のどれだったかを記録します。音が出なかった場合も、まず返答自体が完了したことを確かめてから次の確認へ進みます。

Step 3: 画面を切り替えた場合と比べる

同じ短い依頼で、端末を選択したままの状態と、別のウィンドウへ移った状態を比べます。alwaysで確認できたらunfocusedへ戻し、画面の選択状態による違いを見ます。ここで通知が出る条件を把握できれば、仕事中に必要な知らせ方を選びやすくなります。何度も設定を変える前に、一回ごとの条件と結果を残しましょう。

Step 4: 必要な通知対象と条件に戻す

テスト後は、完了だけで足りるか、承認待ちも知りたいかを選びます。別の作業中だけ知らせたいならunfocusedを候補にし、常に知らせたいならalwaysを検討します。通知が多すぎると必要な合図を見落とすので、普段の短い会話まで毎回鳴らす必要があるかを考えます。音の確認が終わったら、通常の依頼で邪魔にならないかも一度確かめます。

音が鳴らないときは原因を順番に切り分ける

音が鳴らない現象には、Codexから通知が出ていない場合と、端末へ届いた通知が音として扱われていない場合があります。さらに、音は再生されていても別の出力先へ流れていることがあります。これらを一つの故障として扱うと、関係のない設定を変え続けることになります。最初は返答の完了、通知表示、音の順に観察します。

以下は原因を絞るための実用的な確認順です。すべての端末に同じ設定画面があるという意味ではありません。利用している端末の通知やベルの設定名を調べ、音と表示を分けて確認してください。会社で管理されたPCなら、通知が制限されている可能性もあるため、変更できない設定を無理に回避せず、管理担当者へ確認した方が早い場合があります。

1. Codexの返答が完了していることを確かめ、まだ応答中なら通知テストの判定を保留します。
2. 完了が通知対象に含まれているかと、通知条件を確認し、必要なら短いテストの間だけalwaysで比べます。
3. 設定を変更した画面がその値を読み込んでいるかを確かめ、同じ短い依頼をもう一度試します。
4. 端末の通知やベルの扱いを確認し、音ではなく画面の点滅などになっていないかを見ます。
5. OSとアプリの音量、出力先、通知の抑制状態を確認し、イヤホンなど別の機器へ音が出ていないかを確かめます。
6. autoの結果を記録したうえでbelなど別の方式を一つだけ試し、同じ条件で比較します。

表示は出るが音だけ聞こえない場合

通知が視覚的に出ているなら、通知対象や完了条件の設定だけを変更し続ける必要はありません。端末の音の扱い、OS側の通知音、音声の出力先を順に調べます。端末がベルを視覚表示へ置き換えている場合には、通知は届いていても音は鳴りません。表示が出たことを記録し、音の確認へ範囲を絞ると、Codexの設定と端末の設定を混同せずに済みます。

画面を見ているときだけ通知が出ない場合

別のウィンドウへ移ると通知が出るなら、unfocusedの条件と一致している可能性があります。この場合は、通知が壊れていると決めつける前に設定値を確認します。普段は別の作業中だけ知らせてほしいなら、そのままの方が使いやすいでしょう。常に合図が必要な場面に限ってalwaysを選ぶと、不要な通知を増やさずに目的へ合わせられます。

外部通知を使う前に確認する境界

CLIの画面内通知で足りない場合、公式資料にはnotifyを使って外部のプログラムへ通知を渡す方法もあります。ただしこれは、既定の通知音を選ぶだけの設定とは異なります。まず内蔵の通知で合図が届くか確認し、別の方法が必要な理由を明確にしてから検討してください。端末ごとの音の問題を解消したいだけなら、最初から外部の仕組みを追加する必要はありません。

通知の詳細資料では、notifyが現在対応するイベントはagent-turn-completeとされています。内蔵のtui.notificationsでは承認待ちも対象にできるため、両者を同じものとして置き換えないことが大切です。外部へ渡す情報に利用者の依頼や最後の返答が含まれ得る点も、追加を判断する前に確認します。

完了の合図は作業の合格判定ではない

一回の返答が終わることと、依頼した修正が正しくできたことは別です。完了通知を聞いたら、何が変わったか、何を確認したか、未解決の点が残っていないかを画面で読みます。承認待ちの通知なら、対象となる操作と範囲を確認して判断します。音は注意を戻す入口として使い、内容を見ずに次の操作へ進める根拠にはしないようにしましょう。

通知を増やす前に届かせたい相手を決める

個人の端末で短い合図を鳴らす場合と、共有の画面へ詳しい通知を出す場合では、見せてよい内容が変わります。依頼文や返答に顧客名、未公開の仕様、社内のファイル名が入る作業なら、通知の表示先と表示内容を先に確認します。音だけで気づければ十分なのか、詳しい本文も必要なのかを分け、目的に合った最小限の知らせ方を選びましょう。