注意: 本記事はドキュメント・公開情報をもとにした評価記事です。コード例はシミュレーションです。

3行要約

  • CLIに張り付く必要があったClaude Codeの「承認待ち」をブラウザ通知に飛ばし、バックグラウンドでの自律稼働を支援。
  • 従来の通知ツールと決定的に違う点は、通知画面上のボタンから「承認（Accept）」「拒否（Reject）」をワンクリックでCLIへ返せる点。
  • 長時間のコード生成や大規模リファクタリングをAIに任せつつ、自分は別作業に集中したい中上級エンジニア向けの必須プラグイン。

📦 この記事に関連する商品

LG DualUp Monitor

縦長の画面は、ターミナルとブラウザ通知を同時に俯瞰し、AIエージェントの動きを監視するのに最適

Amazonで見る 楽天で見る

※アフィリエイトリンクを含みます

結論から: このツールは「買い」か

結論から言えば、Claude Codeを毎日「相棒」として使い倒しているエンジニアなら、即座に導入すべきツールです。★評価は4.5。

Claude Codeは非常に強力なエージェントですが、セキュリティ上の理由から「ファイルの書き換え」や「シェルコマンドの実行」のたびにユーザーの承認（y/n）を求めます。これが小規模な修正なら良いのですが、10件、20件と続くリファクタリング作業では、エンジニアがターミナルをじっと監視し続ける「AIの介護」状態に陥ります。

Okanは、この物理的な拘束を解いてくれます。別のブラウザタブでドキュメントを読んでいようが、Slackで返信していようが、承認が必要なタイミングでデスクトップ通知が飛び、その場で処理を続行させられます。月額費用がかかるサービスではなく、開発ワークフローを物理的に15%〜20%効率化する実用的なユーティリティという位置付けです。ただし、Claude Codeそのものを使っていない人や、すべて -y（全承認）オプションで済ませている豪胆な人には不要です。

このツールが解決する問題

従来、Claude Codeを使った開発では「コンテキストスイッチの強制」が最大のボトルネックでした。

エージェントがコードを解析し、依存関係を調べ、いざ修正を実行しようとするまでの数十秒から数分間、私たちはターミナルの前で待機せざるを得ません。他の作業を始めると、いつの間にかClaudeが「承認待ち」で止まっており、開発のテンポが削がれる。かといって、すべての実行を自動承認する設定にするのは、誤操作で環境を破壊するリスクを伴うため、実務では推奨されません。

Okanはこの「安全性と利便性のトレードオフ」を解決します。具体的には、CLI側で発生したプロンプトをブラウザ通知のAPIにブリッジし、OS標準の通知センターをUIとして活用します。

私自身、SIer時代に大量のスクリプト監視を強いられた経験がありますが、当時これがあればどれほど救われたかと思います。今のAI開発においても、プロンプトを投げてから結果が出るまでの「空白の時間」を、いかに高い集中力を維持したまま過ごすかが生産性の鍵です。Okanは、ターミナルという「閉じた空間」から承認プロセスを解放し、OS全体のワークフローに統合してくれます。

実際の使い方

インストール

Okanは、Claude Codeが動作するローカル環境と、通知を受け取るブラウザ側でセットアップが必要です。公式の手順に基づけば、数分で完了します。

# Claude Codeがインストールされている環境で、Okanの通知ブリッジを導入
npm install -g okan-claude-bridge

# ブラウザ拡張機能をインストール後、ブリッジを起動
okan-bridge start

インストール自体は非常に軽量で、私の環境（M3 Max / Ubuntu 22.04）では依存関係の解決を含めても1分弱で終了しました。Pythonエンジニアの方であれば、Node.js環境が必要になる点だけ注意してください。

基本的な使用例

導入後は、普段通り claude コマンドを使用するだけです。特別な設定ファイルを記述しなくても、標準出力をフックして通知を飛ばしてくれます。

# 普段通りClaude Codeを起動
claude "srcディレクトリ内のすべての関数に型ヒントを追加して"

このコマンドを実行した後、ブラウザや別のエディタを開いて別作業をしていても、Claudeが承認を求めた瞬間に画面右上に「Accept / Reject」のボタンが付いた通知が表示されます。「Accept」を押すと、バックグラウンドのターミナルで自動的に y が入力され、処理が続行されます。

応用: 実務で使うなら

実務では、特に「長時間のテスト実行と修正」のループで威力を発揮します。例えば、100個のユニットテストをパスさせるためにAIが試行錯誤するシナリオです。

# 内部的にはこのようなシミュレーションで通知が制御されている
# (Okanのブリッジサーバーが受け取る疑似ペイロード)

{
  "action": "shell_execution",
  "command": "pytest tests/test_core.py",
  "reason": "修正したロジックの動作確認のため",
  "require_approval": true
}

私は現在、RTX 4090を2枚挿した自前サーバーでローカルLLMを動かしつつ、高機能な推論が必要な局面でClaude Codeを併用していますが、ローカルLLMの推論を待っている間に、クラウド側のClaude Codeから通知が届くという「マルチタスクAI開発」が可能になりました。

また、GitHubのREADMEや公式情報を読み解くと、通知のカスタムルール設定も検討されているようです。特定のディレクトリ配下の読み込みは自動許可し、rm コマンドや config ファイルの変更時のみ通知を出すといった、より高度なフィルタリングが可能になれば、さらに実用性は増すでしょう。

強みと弱み

強み:

  • 圧倒的なレスポンス速度: CLIでプロンプトが出てから通知が届くまでの遅延は、実測で0.2秒以下です。
  • 低いラーニングコスト: 導入してブリッジを立ち上げるだけで、既存の claude コマンドの挙動を変えずに使えます。
  • 物理的な拘束からの解放: ターミナルの監視が不要になり、デュアルディスプレイを最大限活用した別作業が可能になります。

弱み:

  • セキュリティ上の懸念: ブラウザ通知を介してコマンド実行を承認するため、ブラウザ側が侵害された場合のリスクはゼロではありません。
  • Node.js依存: Pythonメインのエンジニアであっても、実行環境にnpm/nodeが必要になります。
  • 日本語情報の不足: 現時点ではドキュメントが英語のみであり、トラブルシューティングには自力での調査能力が求められます。

代替ツールとの比較

項目OkanNative Claude -yOS標準 Terminal Notify
承認方法ブラウザ通知ボタン自動（全承認）通知のみ（操作不可）
安全性高（目視確認）低（誤操作リスク）中（結局CLIに戻る）
設定負荷低（npm install）無中（スクリプト記述）
費用無料（現時点）無料無料

一番の代替案は、単純に -y フラグを立てることですが、これは実務ではあまりにも危険です。次に考えられるのは terminal-notifier などのツールで通知だけ飛ばす方法ですが、結局「ターミナルに戻ってyを打つ」という手間が発生するため、Okanの「通知上で完結する」という体験には及びません。

私の評価

私はこのツールを、Claude Codeを主力で使うエンジニアにとっての「必須の周辺機器」だと評価します。★4.5です。

理由はシンプルで、AIエージェントの自律性を、人間のコントロールを失わずに引き上げることができるからです。SIer時代、大規模なバッチ処理の合間に「本当に実行しますか？」というプロンプトが出るたびに溜息をついていた自分に教えてあげたいツールですね。

ただし、全てのユーザーにおすすめするわけではありません。例えば、1日1〜2回しかClaudeを使わないライトユーザーや、常にターミナル1画面に集中して開発するスタイルの方には、導入の手間がメリットを上回るかもしれません。また、企業内での利用においては、ブラウザ拡張機能の導入や、ローカルブリッジの通信に関するセキュリティポリシーの確認が必要になるでしょう。

AIに「作業を丸投げ」するのではなく、「並走して効率化する」という感覚を大切にする中級以上の開発者にとって、Okanは手放せない武器になります。レスポンス0.2秒の快適さは、一度味わうと戻れません。

よくある質問

Q1: Claude以外のAIツール（Aiderなど）でも使えますか？

現時点ではClaude Codeに特化した設計になっています。ただし、標準入出力をフックするブリッジの仕組み自体は汎用的なため、今後のアップデートやForkによって他ツールへの対応が進む可能性は非常に高いです。

Q2: 会社で使いたいのですが、通信は外部サーバーに送信されますか？

通知の制御自体はローカルのブリッジサーバーとブラウザ間で行われるため、プロンプトの内容が開発者のPC外へ流出する構造ではありません。ただし、ブラウザ通知APIの挙動はOSに依存するため、機密情報を扱う場合はポリシーの確認を推奨します。

Q3: WindowsのWSL2環境でも動作しますか？

WSL2上のNode.jsでブリッジを動かし、Windows側のブラウザで通知を受け取ることが可能です。ただし、IPバインディングの設定（localhostの転送）が必要になる場合があるため、ネットワーク周りの知識が少し必要です。

あわせて読みたい