はじめに

うぐいすソリューションズ Advent Calendar 2025 の1日目の記事です。
わたしはフロントエンドエンジニアをしていて、うぐいすの案件にいくつか業務委託で関わっていました。
余談ですが、今年10月に本業の会社を退職して現在無職です。

表題のとおり、ChatGPTの機能をジェスチャでコントロールするChrome拡張を作りました。
3部構成で、最初は企画、最後は作った後の振り返りを書いています。成果物や開発プロセスを見たい方は中盤の開発編セクションをご覧ください。

デモ動画

はじめに、どのような機能なのか一連の操作を動画にしました。後述するリポジトリがローカルで動かない場合もこちらを見ていただけたらと思います。

Chrome拡張をクリックするとポップアップが立ち上がり、Webカメラの起動・停止ができます。起動するとブラウザ右上にカメラで投影された映像が表示されます。

カメラマスクの有効でカメラ映像に黒色のオーバーレイを表示できます。
動画ではカメラマスクで顔を隠していますが、裏では手を挙げたり親指を立てたりして、ChatGPTのページに遷移して、音声入力の開始・停止を行なっています。
実際、マウスやキーボードを触らずにChatGPTと音声のやり取りをする ところまでできました。

企画編

Chrome拡張を作ろうとしたきっかけ

わたし自身、これまでChrome拡張をつくったことがありません。AntigravityやClaude Code、Codexといったエージェントツールが注目される中、Chrome拡張は 「Chromeブラウザ縛りのやや枯れた技術」 といえます。

ちなみに、Chrome拡張はいつ始まったのか調べてみると2009年の年末頃でした。約16年経っているんですね。

そんなわたしがなぜいまさら拡張機能を作ろうと思ったか。
ChatGPTやClaude、GeminiといったチャットUIでカチカチボタンを押したりテキスト入力するのが煩雑に感じたからです。

直近のアップデートで音声入力の選択肢も増えましたが、それでも前後に画面上のボタンをクリックする工程は依然残り、こうした体験を楽にできないだろうかと思いました。

近年はAIエージェントにコードを書かせることも増えて、エンジニアがプログラムを書く価値とアドバンテージは薄まってきています。AIの活用でサービスは量産され、ソフトウェアとしての価値の減耗やら、開発スピードやAI技術の加速も著しく感じる昨今です。

AIとやりとりできる時代になったのにいまだに画面をポチポチ触る既存体験を面白くできないか 、今後は デジタルから相対的にフィジカルな体験価値が期待される にあたり、こんなことを思いつきました。

マウスやキーボードを介さず、手の動きなどで一部操作を代替できないだろうか

最近はAI関連のTipsや新機能に関する記事が多く、特定の技術領域を調べたり作ったサービスに関する記事が少なくなったと思ったので、ジェスチャ関連で作ってみた系の記事を書こうと思い至りました。

雑記: ジェスチャ操作の表現あれこれ

手などの動きで操作する着想は、珍しくもありません。
2002年に公開された映画「マイノリティ・リポート」では、トム・クルーズが手にトラッキング装置をつけて画面を操作したシーンがありましたし、マーベル作品の代表作「アイアンマン」では、ロバート・ダウニー・Jrがラボのディスプレイに向けて手を動かし、3Dオブジェクトをコントロールしていました。

インターネット界隈でも、過去にはMicrosoftが物体検知や音声認識のできるデバイスKinectを発売しましたし、ユーザの手や指の動きを検知するLeap Motionというコントローラーもありました。

現代では、VRで自身のアバターと連動して操作するという用途でジェスチャを検知する手法が使われていると思われます。コロナ禍前くらいには、顔の表情を検知して遊ぶアプリもありました。

バック・トゥ・ザ・フューチャー、昔話が過ぎてしまいましたが、ジェスチャを使った表現はこれでもかというくらい擦られ続けています。

一方で、現在は人の動きを検出できるライブラリや、ブラウザ自体ができることも増えてきました。今ならデバイスレスかつ簡易的にブラウザ上で画面内を操作できるのではと思い、つくってみることにしました。

機能面で意識したこと

おぼろげにやりたいことが決まり、次に機能面で以下のことを決めました。

ChatGPTの機能をジェスチャで操作する

上述でも触れましたが、AIチャットツールの機能を補助操作する ということを念頭におきました。特に、ChatGPTやGeminiではブラウザで音声入力ができるようになったので、ジェスチャと連動するのは親和性がありそうと考え、ChatGPTを対象にしました。

懸念として、ChatGPTをはじめサービスのUIは、都度アップデートがあり変更されます。今時点のDOM要素で作ってしまうと、UIが変わって動かなくなることが想定されるため、Chrome拡張側にポップアップの設定画面を設けて、DOMセレクタを変更できる ようにしました。

ChatGPTへの遷移にもリーチする

Chrome拡張は、 対象のWebページにいる状態で拡張機能を有効にする のが主な使い方と思います。その場合、

ChatGPTのWebページにアクセス
Chrome拡張を起動
ジェスチャで操作

となり、拡張機能を有効にするのが煩雑に感じました。GPTの画面にいるのだから拡張機能をオンにせず、直接UIをクリックする方がスムーズだろうし、ジェスチャ操作に切り替える有用性も低いでしょう。

そこで、別のWebページにいることを前提に、そこから拡張機能の起動、ジェスチャ操作の流れで、ChatGPTのWebページに遷移する方が体験上良いのかもと考えました。

Chrome拡張を起動
ジェスチャで操作
ChatGPTのWebページにアクセス

のような流れです。この方が後続の音声入力にもジェスチャでコントロールできスムーズにいきそうです。

ジェスチャの種類

Webカメラで投影される以上、検知対象として顔(顔の向き・表情)あるいは手になります。
中でもより動きをつけて調整しやすい手を使ったジェスチャ検知で進めることにしました。

ハンドジェスチャのパターンも多すぎない方が良いだろうと、多くても3つまでと考えました。おそらく手を挙げる・ピースサイン・親指を立てるくらいだろうと思い、どのサインにどのアクションを割り当てるか検討しました。

ひとまず必要となりそうなアクションとしては大きく3つ挙げられそうです。

ChatGPTのWebページに遷移する
音声入力を開始する
音声入力を停止する

手を挙げる感覚

手を挙げてみると、 「学生時代では先生の質問に答えたり、社会人では登壇者に質問する時」 にこの動きをしていたのを思い出しました。この行動は今にして言語化すると、「わたしには思うことがある」 の意思表明であり、それを起点にAIが音声で聞いてくるプロセスが、対話の流れにも似てしっくりくるように感じました。

そのため、ジェスチャとアクションの対応づけとして「手を挙げる = 音声入力を開始する」を紐づけることにしました。もしかしたらChatGPT以外の画面で手を挙げるとそのままページ遷移させても良さそうと考え、同じジェスチャに紐づけました。

音声入力停止は親指立てるアクションでも良いだろうと思い、結果以下の対応になりました。

ジェスチャ	アクション
ChatGPTのWebページに遷移する	(ChatGPT以外のWebページで)手を挙げる
音声入力を開始する	(ChatGPTのWebページで)手を挙げる
音声入力を停止する	親指を立てる

開発編

成果物

できあがったものが以下のリポジトリです。
extension ディレクトリがChrome拡張用で、README.mdに沿ってインストール・ビルドして、Chrome拡張の開発者モードで読み込んで使います。

Chrome Web Storeで公開しないのは、主に以下の理由からです。

実験用のプロトタイプである
AI駆動&理解後追いのため、動作検証や考慮点で抜けてそう。不具合もありそう
後述の振り返り、「外的要因に左右される」という点から

使ったもの

今回、拡張機能を作るにあたりこれらを利用しました。
Claude Code、Codex、Antigravityといったメインの開発用エージェントがあれば壁打ち含め実装面は十分と思います。

在職中は体感6,7割方自分でコードを書いてましたが、今回は全てエージェントにコードを書いてもらいました。

ツール	用途
ChatGPT	拡張機能の実現性やおおよその実装方針を壁打ち
Claude Code	メイン開発。今回はCLIベースで作りました
Cursor	サブ開発 (Claude Codeがusage limitに達したら以降こちらを使用)
Material Symbols	拡張機能のアイコンをここからダウンロードして使いました

技術スタック

MediaPipe

MediaPipe は、画像・映像・音声をリアルタイムで解析できるGoogle製のオープンソース機械学習ライブラリです。
package.jsonには載っていませんが、Chrome拡張のContent Security Policy(CSP)に抵触したため、ライブラリで使うファイルを libs ディレクトリに配置しています。

また、MediaPipeのジェスチャ検知が独立したWebページなら動くのですが、既存ページに埋め込んだカメラ映像ではMediaPipeのWASMファイル読み込みに失敗して検知処理が動きませんでした。それもClaude Codeに対案を出してもらい、Offscreen Documentを使うことで解消されました。

評価編

実際に使ってみていくつか感じた気づきも共有しようと思います。振り返りは大事ですね。

🤔 ジェスチャ体験は1人ないし数人程度

直感的ではあるけど、触っていると 「これをオフィスにいる人たちがことあるごとにこの動きするだろうか...」 と感じました。

確かに、映画マイノリティ・リポートやアイアンマンでも主人公が専ら1人で行っていました。Nintendo Switchのパーティーゲームのように少数で同一の体験共有ならこれもアリですが、大人数かつ目的がバラバラな環境だとこういう動きはシュールだろうなという所感でした(全員でじゃんけん大会するシチュエーションでもない限り)。

このようなジェスチャ体験型を利用する状況としては、多分1人か数人程度だろうと思われます。
それゆえに、その人数規模でできるジェスチャを使った体験設計は他に何があるのか、と難しさを感じました。

🤔 顔を手と誤検知されることがある

何回か使っていると、まれに手を挙げていないにもかかわらず顔を手と認識したようで、手を挙げたと判断されることがありました。

この辺りはMediaPipeのチューニング次第かと思いますが、クリック・タッチに比べてどの程度をもってOKとするかの精度調整が難しいところだなと感じました。また、精度面もOSにインストールするデスクトップ・モバイルアプリの方が期待できるのかもしれません。

🤔 関わっていない技術領域にはコードへの関心が薄れる

わたしはフロントエンド開発業務に携わっていましたが、前述の通りChrome拡張は未経験です。
作り方からどう実装するかをすべてAIに書いてもらうと、前提知識がないこともありコードの詳細まで目が届きにくくなるのを感じました。

最近、AIにコードを書かせたジュニアエンジニアが、レビューで指摘されて「AIがそう書いたから」と言った話を思い出して、ジュニアエンジニアの気持ちもわからなくはないと思いました。
もちろんエンジニアである以上、出力結果には責任もって品質を担保すべきです。一方で、AIによるコード出力が増えると人間がレビューするのは非効率になっていき、それもAIにとって代わられていく状況です。

では最終的に人が確認するものは何か。出力結果が期待される挙動や仕様に沿っているか になるだろうと考えます。これもAIの浸透で領域範囲も変わってくるかもしれませんが、コードが最終的に行うところはそこなので、当面ここは意識するところでしょう。

これは視座を変えて、実装外にいるプロダクトオーナーやプロダクトマネージャー寄りの立ち位置に近いです。今後もエンジニアとしてコードに向き合うとするなら、出力結果や関わる領域に常に理解を向ける ことになると思われます。

ただ、自身が関わってない範囲だから無関心になるかというと一概には言えません。逆にAIの出力結果や経験ないからこそ関心が上がるかもしれません。

🤔 外的要因に左右される

このChrome拡張では、カメラ起動と合わせて遷移先URLからボタン要素のセレクタを設定できるようにしました。既存画面の直近多少の変更はこれでカバーできるでしょうが、今後の破壊的アップデートによって、一連の操作の流れが根本的に変わってしまうと、この拡張機能の仕様では困難になるでしょう。

それもあってChrome Web Storeへの公開はしませんでした。UIの変更は不定期かつ不測的に行われるので、メンテナンス頻度からイタチごっこになりかねないからです。

もしもこのような流動的変更にも対応するとしたら、Chrome拡張使用時にAIがサービス側の操作を解析して、自動で操作の流れを組み込む仕様が必要になりそうです。
が、そこまでやると当初のジェスチャ操作とは別軸になり、ロジックも複雑化しそうになるのでやりませんでした。

他にも、この頃はCometやDiaなどAIブラウザが出てきて、以前はシェアでChrome一強だったのが変わる可能性もあるし、将来的なChrome拡張の仕様変更で一部挙動が使えなくなることもありうるでしょう。

🤔 Webのジェスチャインターフェースはマイノリティ

インターネットが使われておよそ30年近く経ったこともあってか、ユーザのインターフェースは最適化されている のだろうなと触りながら感じました。

GUI操作にはPCだとマウス、スマホやタブレットではタッチ操作が主流になっています。音声入力は後発かつ補助的な操作系ですが、主流にある「手を使った操作」と干渉しないかつ直感性もあり浸透しているのだ と考えます。

対して、手を使ったジェスチャ操作は、デバイスに触れない点では音声と同程度の直感性である一方、マウス・タッチと「手を使った操作」が干渉するため、操作系がごっちゃになってしまいそう と推察します。

なので、既存サービスの一部操作をジェスチャで代替する流れが広まるかというと厳しそうと思いました。こうした事例が浸透しない理由はこの辺りにあるのだろうなと言語化しながら感じました。

もしもユーザがジェスチャ操作に有用性を感じるとしたら、以下のような条件いずれかに該当する場合だろうと考えます。

従来のマウス・タッチ操作がしづらい環境
- 物理的・身体的に手先のコントロールがしづらい状態
アプリケーション・プラットフォーム単位でジェスチャがメインの操作系になる
- VRのようにジェスチャを使う制約・ルールを設ける
複雑な操作のショートカットとして活用
- マウスやタッチの単一作業に比べ、複数工程をジェスチャで一気に行える。既存操作以上の利便性になる
既存のWeb基盤の操作ルールが変わる
- 平面表現から3D・奥行き操作などインターネット表現で前提条件が変わるような場合

課題点はありましたが、やってみた学びはありました！
ChatGPTへ遷移するところからジェスチャを導入するアイディアから、MediaPipeによるジェスチャ検知がうまくいかずOffscreen Documentのアプローチがあることを知ったりと、プロダクトの作り方を考えさせられる内容でした。

また、今回はChatGPTの現行UIに沿った設定項目で設計しましたが、インプットの項目を増やしたりジェスチャとの対応づけを工夫すると、他のサービスでも使えるようなカスタマイズができそうです。

さいごに

実装中の失敗や方針転換は何度もありましたが、イメージに近いものを作ることができました。原理としては、従来のE2Eテストツールのようにスクリプト経由でDOM要素のクリックをしていますが、その発火トリガーにハンドジェスチャを割り当てています。
もしジェスチャを使った操作体験を考えている方にとって参考になったら幸いです。

この記事を改めて見返すと、コードのサンプル全く出てこないことに気づきました。それほどAIによってコードを書く関心ごとが離れていることに少し寂しさを感じます。

それでも当面はエンジニアとして求められるところにはコミットしつつ、将来的に立ち位置を切り替えることも視野に動いていこうと思います。

noteやXもやっているので、よければ見てみてください。

1日目の長々とした内容にお付き合いいただきありがとうございました！

2日目は うぐいすの代表、ぴよさんの記事 です！どうぞお楽しみに！！