本記事はロボケン社のデスクトップAIアシスタント「mienaq（ミエナク）」のご紹介記事（PR）です。実装の仕組みに焦点を当てて技術的に解説します。

画面共有中に相手から見えないAIオーバーレイを実現する仕組みを調べてみた

はじめに

オンライン商談やオンライン会議で、相手の発言に対してとっさに気の利いた返しが出てこない、話しながら議事録も取りたいのに手が回らない——こうした経験がある人は多いと思います。対面の商談であれば手元の資料をちらっと見ることもできますが、画面共有をしているオンライン会議では「カンペ」を表示すること自体が難しく、うっかり相手の画面に映り込んでしまうリスクもあります。

この「相手には見えないが自分には見える」という一見矛盾した要件を、OS標準のウィンドウ合成の仕組みを使って実現しているのが、株式会社ロボケンが開発する「mienaq」です。今回はマーケティング的な機能紹介ではなく、なぜこの透過オーバーレイが画面共有のキャプチャに映り込まないのか、なぜ同じ発想がスマホでは原理的に実現できないのかを中心に、実装の仕組みを掘り下げてみます。

「相手に見えない透過オーバーレイ」はどう実現されているか

画面共有ソフトウェアが画面の中身を取得する際、一般的には次の2つの経路のどちらかを通ります。

OSのウィンドウコンポジタ（合成器）が最終的に描画したフレームバッファ全体をキャプチャする
特定のウィンドウ単位でキャプチャ対象を指定し、コンポジタがそのウィンドウの描画結果だけを渡す

macOSではCoreAnimation（およびその上位にあるWindowServer）が、Windowsでは DWM（Desktop Window Manager）が、この「どのウィンドウをどう合成して画面に出すか」を一括管理しています。ポイントは、これらのコンポジタにはウィンドウ単位でキャプチャから除外する属性が用意されているという点です。

macOS: NSWindow の共有種別を .none に設定することで、そのウィンドウはCoreAnimationレベルで「画面共有・録画のキャプチャ対象から除外」されます。ユーザーのディスプレイにはウィンドウが表示されつつ、Zoom/Meet/Teamsなどが呼び出すスクリーンキャプチャAPI（例: ScreenCaptureKit）にはそのレイヤーが渡りません。
Windows: SetWindowDisplayAffinity APIに WDA_EXCLUDEFROMCAPTURE を指定すると、DWMがそのウィンドウをキャプチャ対象コンポジション結果から除外します。物理ディスプレイには描画されますが、DWMが生成する共有用のサーフェスには含まれません。

つまりmienaqのオーバーレイウィンドウは「透過・最前面・クリックスルー可能」な特殊ウィンドウとして生成され、OSのコンポジタに対して「このウィンドウはキャプチャに含めないでください」と申告している状態です。Zoom等のアプリ側は何も特別なことをしておらず、OSが提供するキャプチャAPIを呼んだ結果として、はじめからそのウィンドウの情報を受け取っていません。これは「隠す・偽装する」というよりも「OSの正規の機能を使って除外を申告する」という、比較的クリーンな実装だと言えます。

なぜiOS/Androidでは同じ仕組みが作れないのか

上記の実装が成立する前提は、「同一マシン上で複数のウィンドウをOSのコンポジタが合成し、その合成結果の一部をアプリごとに選択的にキャプチャできる」というデスクトップOS特有のウィンドウイングモデルです。

iOS/Androidでは、こうした「他アプリの画面の上にリアルタイムでオーバーレイを重ね、かつキャプチャからは除外する」という組み合わせをアプリに許可していません。理由は大きく2つあります。

そもそも他アプリの画面をリアルタイムにキャプチャ・重畳描画する仕組み自体が、サンドボックス設計上厳しく制限されている（AndroidのSYSTEM_ALERT_WINDOWのような重畳表示権限はあっても、任意アプリの画面共有ストリームへの介入は想定されていない）
仮にオーバーレイ描画ができても、キャプチャ除外の申告機構（macOSの共有種別やWindowsのWDA_EXCLUDEFROMCAPTUREに相当するAPI）がモバイルOSの一般アプリ向けには提供されていない

つまりこれは実装力の問題ではなく、モバイルOSのセキュリティモデル・サンドボックス設計上の制約です。mienaqがmacOS/Windowsのみ対応でiOS/Androidに非対応なのは、この技術的な壁が理由になっています。

主要機能

リアルタイム文字起こし（日英対応）: 自分と相手の発話を区別して文字起こしし、誰が何を話したかを時系列で保持します。
Auto Coachモード: 相手の発話の合間を検知し、AIが自動で次の一言や質問例をサジェストします。
スライド遷移検知: 画面共有中のスライドが切り替わったことを検知し、文脈に応じてヒントの内容を更新します。
ホットキー即時サジェスト: Cmd+K（macOS）/ F9 でその場で「次の一言」を呼び出せます。
AIエンジン切替: Gemini / Claude をタスクや好みに応じて切り替え可能です。
パニックキー: 緊急時に1キーですべてのオーバーレイUIを非表示にします。

使い方（ステップ）

公式サイトからmacOS/Windows版をダウンロード（クレジットカード登録不要でローカル試用可能）
Gemini / Claude のAPIキーを入力（後述の通りOSのセキュア領域に保存）
文字起こし言語（日本語/英語）を選択
Zoom/Meet/Teams/Webexなどで画面共有を開始
会話が進むとAIヒントがオーバーレイ上に自動表示され、終了後に議事録・要約がローカルに出力される

セキュリティ・プライバシー設計

APIキーはmacOSではKeychain、Windowsでは資格情報マネージャー（Credential Manager）に保存され、OSの暗号化ストレージに委ねる形になっています。アプリ独自の平文保存ではない点は、この手のツールを評価するうえで確認しておきたいポイントです。

また議事録・要約・検知したスライド情報はクラウドへ送信されず、ローカル保存のみとされています。一方でAIによる文字起こし・サジェスト生成そのものはGemini/Deepgram/Anthropic各社のAPIを介したクラウド処理のため、ネットワーク接続は必須です。「AI処理はクラウド、生成物の保存はローカル」という切り分けと理解しておくとよさそうです。

利用場面ごとの倫理的な留意点

mienaqが想定するユースケースはオンライン商談、講座、面接、配信のテレプロンプター代わり、会議の発言支援・議事録作成など幅広いものが挙げられています。このうち、商談・会議支援や配信でのテレプロンプター的な利用は、話者が自分自身の判断で使う支援ツールという性質が強く、実務上大きな問題は生じにくいと考えられます。

一方で、面接や交渉の場面で「相手に開示せずにAIの支援を受けていること」自体は、それが問題になり得るかどうかが利用者側の状況に強く依存します。企業の採用選考では候補者に対して独自の実施要領や倫理規定を定めている場合があり、そうした規定でAIツールの使用が制限・禁止されているケースも考えられます。同様に交渉の場面でも、相手方や所属組織のコンプライアンス上のルールに抵触する可能性があります。この点はツールの機能自体の是非というより、利用者が置かれている状況・所属先の規定・相手との関係性によって判断が分かれる部分なので、使用前に自身の所属組織のポリシーや、対象となる選考・交渉のルールを確認しておくことをおすすめします。

まとめ

mienaqは「あとで読む議事録ツール」ではなく「いま画面上に出るリアルタイム支援」という立ち位置の製品で、その中核にあるのはOSのウィンドウコンポジタ（CoreAnimation/DWM）が持つキャプチャ除外機能でした。特別なハックではなく、OSが公式に用意している仕組みを使っている点が技術的には興味深く、同時にモバイルOSでは同じ仕組みが提供されていないため原理的に非対応になる、という対比も明快でした。実際の利用にあたっては、便利さと引き換えに、場面によっては開示義務や組織のポリシーとの整合性を自分自身で確認する必要がある点も踏まえておきたいところです。

公式サイト: https://mienaq.com/