MENU
シニアが日々の課題をAIを使って解決しようとするサイト
  1. ホーム
  2. Codex / Claude Code
  3. CodexとClaude CodeからStream Deckを操作する――公式MCPでComputer Useを置き換える実験

CodexとClaude CodeからStream Deckを操作する――公式MCPでComputer Useを置き換える実験

Codex / Claude Code Stream Deck ＡＩ

AIがMacの画面を見て、アプリを開き、ボタンをクリックする。そんな操作（Computer Useを用いる処理）ができるようになると、次に気になるのは「毎回、同じ手順をAIに一つずつ操作させる必要があるのか」という点である。最近はAIの能力もさらに向上し、このようなComputer Useの作業も早くなっていると思われるが、ユーザーが、AIが操作している画面とは別の画面をアクティブにしたりすると、AIの処理に支障が出ることもあったように思われるので、Computer Useの処理の安定性という点の課題も依然あるように思う。また、Computer Useは、「消費トークン量が多い処理」という話も聞く。さらに、MacOSの制限によりComputer Useの処理がエラーとなり、ユーザーに手動操作を依頼する場面もあったように思われる。

このような問題を解決するための手段として思いついたのが、定型操作を登録できるStream Deckの公式MCPの機能で、Computer Useの処理を部分的に肩代わりすることができるのではないかということである。つまり、公式MCPの機能を使って、「MCP Deck」の仮想ボタンに作業を登録しておき、AIにそのボタン操作をさせることによって目的の処理を行うという方法である。「MCP Deck」の仮想ボタンの登録はユーザーで行えるが、Stream Deckのサードパーティ製のMCPを利用してAIに登録させるという方法もある。

ただし、Computer Useでは可能だか、仮想ボタンによる方法では不可能な処理もありそうなので、仮想ボタンでの実行可否をその都度検証して、Opsidianにデータベース化しておけば、仮想ボタンによる処理を再利用できる可能性もある。

この発想をCodexとClaude Codeに評価してもらい、Mac上で段階的な実験を行った。最初に、両方からElgato公式MCPを通じて「試験フォルダを開く」を実行できることを確認した。続いて、Finderの保存フォルダとObsidianの原案ノートを開く複合操作を、Computer Useによる直接操作と比較した。

複合操作の2回ずつの比較では、公式MCP経由が完了確認までの時間を平均54.35%短縮し、経路固有の動的トークン量の代理値を67.93%減らしました。ただし、2回ずつの少数試験であり、Computer Use側の再試行も結果に含まれます。どの作業でも同じ割合で改善する、という意味ではありません。

この記事では、発想の評価、設定、単純操作と複合操作の比較、アクションデータベースを使った置き換え候補の検討までを整理した。検証期間は2026年9月6日から9月8日の期間で実施した。

注）本記事の内容は正確性を保証するものではありません。

（2026年9月9日 追記）YouTube動画を追加しました。　https://youtu.be/fi3iTNPS13s

目次

AIが判断し、決まった操作をStream Deckに任せる

今回の原案には、二つの期待がありました。

一つは、画面認識やクリックではうまくいかない処理を、登録済みアクションで実行できる可能性です。もう一つは、AIが細かな操作を繰り返す回数を減らし、時間や利用トークンを抑えられる可能性です。

例えば「執筆の準備をして」と依頼したとき、作業フォルダやエディターを開く部分には、決まった手順があります。AIには今回必要な準備を判断してもらい、固定された操作は既存の処理に任せる。この役割分担ができれば、Stream Deckの設定を人とAIで活用できる。

もっとも、フォルダを一つ開くだけなら、自分でボタンを押す方が手軽なこともあるが、今回のフォルダ操作は、効率の良い使い道を示すためではなく、AIから登録済みアクションを呼べるかを確かめる試験として選んだ。

CodexとClaude Codeの評価を比較する

Obsidianにブログのねたとして、下記の構想（下記「原案」に記載の内容）を書き込み、CodexとClaude Codeにそれを評価させ、そのノートの「AI評価欄」にそれぞれの評価を書き込んでもらった。その後、可能ボタンの効果の検証結果も追記した。

ノート「ChatGPTにStream Deckを使わせる」に書き込んだ構想「原案」
Codexが記入した評価（抜粋）
Claude Codeが記入した評価（抜粋）
同じノートに追記した「ユーザー判断」

以下は試験前の2つのAIの評価を比較した表である。最初にCodexに評価を記入してもらい、その後に、Claude Codeに記入してもらったので、Claude Codeの記載内容には、「Codexの意見に同意」という記載も含まれていた。

比較項目Codexの評価Claude Codeの評価共通点・相違点
発想の有効性AIが判断し、定型操作をStream Deckに任せる分担は合理的既存のボタンやスクリプトをAIから使う拡張として妥当小規模試験に進む価値があるという点で一致
適した処理アプリや作業URLを開くなどの繰り返し操作手順が固定され、エラー分岐が少ない操作定型処理を対象にする点で一致。Claude Codeは条件をより限定
期待する効果画面認識やクリックの回数を減らせる可能性既存の定型処理を再利用できる可能性操作回数の削減と既存資産の活用という異なる側面を強調
トークン・時間削減は仮説。判断と結果確認にも負担がある同意。ツール発見や説明文の読み込みも含めるべき全工程で比較する必要がある点で一致
設定と実行コミュニティ製MCPによる設定編集と、公式MCPによる実行を区別その区別を強調し、設定側には既存実績があると報告別機能として扱う点で一致
評価時点の根拠資料調査とアプリ情報が中心。実行は未検証資料調査、接続済みツールの確認、過去の運用記憶根拠の範囲が異なる
失敗の原因前面アプリやカーソル位置に依存する操作の弱点は残るスクリプトや連携先自体の不具合は、呼び出し方を変えても直らないStream Deck経由でも信頼性は自動的には高まらない
完了確認ツールの成功応答と作業完了を分ける同意し、承認待ちやタイムアウトの扱いも重視結果確認の必要性で一致
設定変更のリスクバックアップと試験用の範囲限定が必要設定書き換えに伴うアプリ終了・再起動が、既存ボタンの利用に影響すると指摘設定保全と運用中断の両面から補完
最初の試験手動設定した少数アクションを公式MCPから実行設定自動化より、未実証の実行側を先に確認公式MCPと1アクションから始める点で一致
承認の仕組み操作の影響に応じた確認や制限を設ける既存のMQTT／Home Assistant承認基盤の再利用を提案一般的な要件と環境に即した案の違い。再利用は今回未検証

両者の間に大きな意見の対立はなかった。Codexが検証方法と安全性を広く整理し、Claude Codeが既存環境の具体的な事情を補足した形となった。

Claude Codeの評価には、シェル操作が承認待ちフックで300秒後にタイムアウトした事例もありました。ただし、これはシェル操作の承認経路の事例なので、今回の公式MCPにも同じフックが適用されると決めつけることはできず、実際にどの操作がどの確認を通るかを区別する必要があるとのことだった。

「設定を作る」と「登録済みアクションを実行する」は別

今回、特に整理が必要だったのは、Stream Deck向けMCPという名前だけでは役割を判断できない点でした。

仕組み今回整理した役割この試験での扱い
コミュニティ製のstreamdeck-mcpプロファイルやボタン設定の作成・編集既存登録を保持。今回の試験ボタンの作成には使わない
Elgato公式MCP登録されたアクションの取得・実行などAIからの実行経路として使用

原案の中心は「AIにボタン設定を書いてもらう」ことではなく、「AIが既存の処理を呼べるようにする」ことなので、今回は、設定はユーザーが公式UIで行い、実行だけをAIに任せた。

その後、コミュニティ製 streamdeck-mcp についても独立クライアントから接続可否を確認しておいた。
プロファイルやページの読み書き、アイコン作成、アクション作成、Stream Deckアプリ再起動など、7つの設定用ツールを取得できた。create_actionでは、保存フォルダとObsidianノートを開くシェルスクリプトとOpenアクション定義を生成し、ファイル、実行属性、シェル構文を確認した。

ただし、生成した定義をMCP Deckへ配置したわけではなく、生成スクリプトも実行していない。設定用MCPが「設定材料を生成できる」ことの確認であり、「MCP Deckへ自動配置して実行できた」という実績ではない。また、ページ書き換えはStream Deckアプリの終了・再起動を伴いうるため、既存ボタンを使用中の環境では慎重に扱う必要がある。

MCPはAIと外部のツールをつなぐ仕組みだが、今回使った接続はローカルのstdioで、AI側が公式MCPサーバーのプロセスと通信するものである。公式サーバーの実装や配布情報はElgato MCP Serverのリポジトリで確認できた。

Codex または Claude Code
          ↓ ローカルstdio接続
Elgato公式MCPサーバー
          ↓
Stream Deckの登録済みアクション
          ↓
試験内容：「Finderで試験フォルダを開く」

物理ボタンを画面上で探してクリックするのではなく、登録済みアクションのIDを指定して実行する構成です。

Elgato公式MCP「MCP Deck」を有効にする
「MCP Deck」に設定したマルチアクション
マルチアクションのコンテンツ例

試験条件を決める

ユーザー判断は「実施する」。ただし最初から複数のアプリや外部サービスを動かさず、結果を確認しやすい処理に絞りました。

項目今回の条件
実行環境macOS上のCodex、Claude Code CLI
Stream Deck7.5.1
公式MCPパッケージ@elgato/mcp-server 0.1.7
Node.js検証時は20.8.0
アクションシステムの「開く」
タイトル試験フォルダを開く
対象StreamDeck-MCP-Testという専用フォルダ
フォルダの中身確認用のREADME.txt
成功条件アクションが成功し、Finderに正しい対象が表示される

これらは動作記録であり、今後の推奨バージョンを示すものではありません。

作業前にはStream Deckのプロファイルをバックアップしました。今回は883ファイルについてコピー前後のSHA-256が一致することを確認しています。既存のボタン設定を巻き込まず、試験対象を一つに限定するための準備です。

Stream Deck側で試験アクションを登録する

Stream Deckの設定で「General」の「Enable MCP Deck」を有効にし、MCP用の「MCP Actions」にアクションを配置します。通常使っている他のプロファイルのボタンが、この操作によってすべてAIに公開されるわけではありません。説明を追加する入口は、アクションを選択したときの「AI」ボタンです。Elgato公式設定ガイド

今回の登録内容は次のとおりです。

  1. 専用フォルダ「StreamDeck-MCP-Test」を用意し、確認用のREADME.txtを入れる。
  2. MCP用のデバイス・プロファイルを選ぶ。
  3. 空きキーにシステムの「開く」を配置する。
  4. 「App／ファイル」に試験フォルダを指定する。
  5. タイトルを「試験フォルダを開く」にする。
  6. 「AI」ボタンから、用途を説明する文を登録する。

説明文には、次の内容を入れました。

Stream Deck MCPの接続試験に使う専用フォルダをFinderで開きます。ファイルの変更・削除はしません。

この設定では、マルチアクションの説明を説明入力欄に入力するという指示をCodexから受けたが、通常のアクション設定欄を見ても説明入力欄が見当たらなかった。説明は「タイトル」や「App／ファイル」と並んだ欄ではなく、右上の青い「AI」ボタンから入力するとのことだった。

上図右上の青い「AI」ボタンをクリックすると、説明入力欄が現れる

一方、後日取得したインストール済みアクション全体の list_actions カタログでは、353件すべてのアクションの説明欄（ description_md ）は空だったので、その説明欄の内容を流用することはできないことが確認された。

説明は、AIが対象を選ぶための情報の一部として利用するので、実際のアクションが何をするかという情報を収集する必要があることが確認できた。

CodexとClaude Codeに公式MCPを登録する

今回の環境では、公式MCPを作業ディレクトリ内にインストールし、Node.jsとサーバーの絶対パスを登録した。
以下は実際の設定形式を、読者の環境に合わせられるように置き換えた例。/absolute/path/はそのままでは動作しない。

Codexの~/.codex/config.tomlには、次の項目を追加した。

[mcp_servers.elgato_official]
command = "/absolute/path/to/node"
args = ["/absolute/path/to/node_modules/@elgato/mcp-server/bin/index.js"]

Claude Codeには、次の形式でユーザースコープの登録を追加した。

claude mcp add --scope user --transport stdio elgato_official -- \
  /absolute/path/to/node \
  /absolute/path/to/node_modules/@elgato/mcp-server/bin/index.js

今回のサーバーは、例えば次のように専用ディレクトリへインストールする形式で行った。これは記事用に保存先を一般化した例で、読者のMacで実行確認したものではない。

mkdir -p "$PWD/elgato-mcp-runtime"
npm install --prefix "$PWD/elgato-mcp-runtime" @elgato/mcp-server@0.1.7
command -v node

最後のコマンドで表示されるNode.jsの絶対パスと、インストール先のnode_modules/@elgato/mcp-server/bin/index.jsの絶対パスを使った。登録後もそのディレクトリを移動・削除すると接続できなくなるため、保存場所は維持した。また、既存のMCP設定を丸ごと置き換えないことも重要。

Codexでは設定を追加した直後、実行中のタスクに公式MCPのツールがまだ現れていなかったが、アプリを終了して再起動した後、同じタスクでツールを取得できた。この環境では、設定ファイルに記載されていることと、現在の会話がそのツールを使えることは別だった。

接続確認からアクション実行へ

接続後は、次の順番で確認した。

手順呼び出すツール確認すること
1bridge_statusStream Deckが接続されているか
2streamdeck__get_executable_actions試験アクションのタイトル、ID、説明が一致するか
3streamdeck__execute_action確認したIDのアクションを1回実行する
4Finderの画面確認対象フォルダとREADME.txtが表示されているか

Stream Deckに接続でき、試験ボタンを登録する前は実行可能なアクション一覧が空であることが確認できた。接続自体と、呼び出せるアクションの登録は、別々に確認すると状況を理解しやすくなる。

実行を依頼する文は、例えば次のようになる。

Elgato公式MCPで、登録済みの「試験フォルダを開く」を1回実行し、結果を確認してください。

今回、Codexではこのタスクに読み込まれた公式MCPのツールを直接使用した。Claude Codeでは契約アカウントでのログインを確認してからCLIを起動し、試験用の公式MCPだけを指定して実行した。対象のタイトルとIDが一致する場合だけ実行するようにし、呼出履歴でも1回の実行を確認した。

このMCP接続のためのモデルAPIキーは追加していない。ただし、AIに判断・実行を依頼する分は各サービスの利用枠を消費する。「ローカル接続」は、AIの推論までMac内で完結するという意味ではない。

試験結果：両方から実行できた

検証は、まず単独のMCPクライアントで経路を確認し、その後、CodexとClaude Codeから実行する順で行った。

試験結果確認範囲
単独MCPクライアントから3回実行3回とも成功、再試行なし毎回、試験ウインドウを閉じてから実行し、Finderの対象を確認
Codexから直接実行成功公式MCPの成功応答とFinderの対象表示を確認
Claude Code CLIから実行成功実際のツール呼出履歴、成功応答、Finder表示を確認

12〜36msという数字で分かること

単独MCPクライアントで測った応答時間は、次のとおりだった。

回MCP呼び出しから応答まで応答
123msstatus: ok
212msstatus: ok
336msstatus: ok

この数字には、AIが依頼を解釈する時間、ツールの説明を読む時間、承認の待ち時間、Finderの画面を確認する時間を含まない。フォルダが表示されるまでの描画時間を測った数字でもない。

そのため、「作業全体が数十ミリ秒で終わる」「AIの画面操作より速い」とは結論づけられなかった。今回分かったのは、試験条件の下で、MCPの呼び出しに成功応答が返ったということだった。

単純なフォルダ操作では、時間短縮を確認できなかった

最初の効果比較では、「指定フォルダを開き、中のREADME.txtが見えることを確認する」という単純な処理を使いました。Finderを直接操作する方法と、公式MCPの登録済みアクションを呼ぶ方法を、それぞれ3回比較しました。

指標Computer UseによるFinder操作公式MCP経由
成功3/33/3
平均時間19.197秒25.831秒
中央値17.102秒24.794秒
実行・確認の操作数／回52
再試行00

公式MCPは操作数を減らしましたが、平均では6.634秒長くなりました。この測定にはモデルとツールの往復が含まれ、両方式の計測境界も完全には対称ではなかった。したがって、Stream Deck自体が遅いという結論ではなく、「フォルダを一つ開く程度では、導入負担を回収できる時間短縮を確認できなかった」という評価となった。

この結果から、固定処理をまとめる効果が出やすい処理として次の試験を対象にした。

複合操作で、保存フォルダと原案ノートをまとめて開く

次の試験では、MCP Deckにマルチアクションを登録した。処理内容は次の二つ。

  1. Finderで記事の保存フォルダ outputs を開く。
  2. Obsidianで保管庫 ssd_vault の「ブログネタ/ChatGPTにStream Deckを使わせる」を開く。

直接操作では、Finderの「フォルダへ移動」とObsidianのクイックスイッチャーをComputer Useで操作した。
公式MCP側では、登録済みマルチアクションを1回呼び出した。

完了条件は、MCPの応答だけではなく、Finderのウインドウ名が outputs であり、Obsidianのウインドウ名が対象ノートと一致することを、両方式とも同じ画面情報で確認した。毎回、FinderをDesktop、Obsidianを別ノートへ戻してから計測していた。開始状態へ戻す時間は測定外とした。

最初の比較では、Obsidianの画面情報と画像が一致せず、有効な開始状態を保証できなかったので、その試行は測定値から除外した。画面操作接続を再初期化した追試で、2組の有効な比較を取得した。

方式1回目2回目平均成功
Computer Useによる直接操作40.160秒46.657秒43.409秒2/2
公式MCPのマルチアクション20.334秒19.298秒19.816秒2/2

この処理では、公式MCPが平均23.593秒、54.35%短くなった。公式MCP本体を待った時間は平均7.886秒で、表の時間には、その前後のAIとツールの往復、最後の画面確認も含まれる。

Computer Use側では、2回ともObsidianのクイックスイッチャーを最初に開く操作が反映されず、画面情報を取り直して1回再試行した。この失敗も、AIが実際に完了へ到達するまでの負担として計測に含めている。公式MCP側に再試行はなかった。

動的トークン量は約68%減った

トークンは、会話全体の使用量と、今回の経路で新たに発生した量を分けた。Codexの実行記録にある各モデル処理の last_token_usage から、次の値を経路固有の「動的交換量の代理値」とした。

非キャッシュ入力トークン + 出力トークン

非キャッシュ入力にはツール結果のほか、少量の実行制御情報が含まれ、出力にはツール指示のほか、少量の判断文が含まれる。そのため、ツールJSONだけを取り出した厳密値ではなく、経路別の上限に近い実測代理値である。

方式1回目2回目平均Computer Use比
Computer Use2,5262,4102,468基準
公式MCP84374079267.93%減

モデルとツールの往復回数は、Computer Useが各6回、公式MCPが各2回だった。登録済みIDを指定する1回の実行と、1回の完了確認にまとめられたことが削減の主因だった。

Stream Deckのアクションデータベースを作る

次に検討したのは、Computer Useを含む作業やSkillから、MCP Deckへ置き換えられる部分を探す方法だった。
その前準備として、Obsidianの 30_Resources/Stream Deck に、Stream Deckの標準・サードパーティ製プラグインとアクションのデータベースを作った。ただし、作成したのは一般的な項目を設定したデータベースであり、AIが参照するのに適した項目を追加設定する必要があるかどうかは、別途、AIと相談しながら検討することにした。

アクションには、「説明」の記載があるものもあった

公式MCPの list_actions で取得したカタログは353件、77,528文字、2,828行ありました。全件をそのままAIへ読ませると、置き換えで減らした量以上のトークンを消費しかねません。そこで、データベースは1アクション1ノートにし、必要な候補だけを検索して読む構成にしました。

2026年9月8日に、Claude Codeが公式MCPのカタログとデータベースを突き合わせました。データベースは321件でしたが、MCP側にありDB側にないものが45件見つかりました。主な欠落は、Computer Useの置き換えに直結しやすい本体組み込みアクション34件です。「Webサイト」「アプリケーションを開く」「開く」「ホットキー」「テキスト」「マルチメディア」「遅延」などが含まれていました。

欠落分を追加した結果、データベースはアクション366件、プラグイン63件になりました。一方で、DBにはあるもののMCPカタログに現れないアクションが13件ありました。さらに、scriptdeckの7件にはUUIDの大文字・小文字の表記差がありました。このため、UUIDの突合は小文字化して行う必要があります。

集合件数意味
公式MCPのインストール済みアクションカタログ353list_actionsに現れた候補
更新後のObsidianデータベース366検索用の記録。MCPに現れない13件も含む
MCP Deck上で現在実行可能なアクション1get_executable_actionsに現れ、AIが実際に呼べるもの

ここで重要なのは、データベースに載っていること、公式MCPのカタログに載っていること、MCP Deckから実行できることは、それぞれ別だという点です。

「MCP Deck上で現在実行可能なアクションが1件」というのは、試験用にユーザーがマルチアクション1件を設定した状態であることを示しており、MCP Deck上で現在できるアクションは1つしかないという意味ではない。

カタログに載っていても、そのままAI向けには使えない

list_actions が返した353件は、すべて ai_ready: false、settings_schema: {}、description_md: "" でした。取得できるのは、主に名称、ツールチップ、UUIDです。引数、副作用、前提条件、完了確認方法、再実行してよいかといった情報は、自動的には揃いません。

これらを366件すべてに手作業で追記する必要はありません。
まずMCP Deckへ配置する少数のアクションだけに、AIが判断するための情報を用意する。

AI向けに記録する項目内容
用途どの依頼で使うか
対象開くアプリ、URL、ファイルなど
前提条件前面アプリや選択状態への依存
副作用変更、送信、公開、削除の有無
完了条件実行後に何を確認するか
再実行可否途中失敗後に繰り返してよいか

データベース全体は候補検索用に保ち、AIのコンテキストへ丸ごと載せません。
実行に使う数件だけを詳しくする方が、管理の手間とトークン消費を抑えられます。

現状のデータベースには、導入済みかどうかは記録されていますが、「公式MCPのカタログに現れるか」と「MCP Deckへ配置済みか」を区別する項目がなかった。次のプロパティ追加が提案されていますが、2026年9月8日時点では未実装だった。

追加候補のプロパティ用途
MCP露出list_actionsに現れるかをtrue／falseで記録する
MCPDeck配置get_executable_actionsに現れるかをtrue／falseで記録する
置き換え候補高・中・低・対象外で優先度を記録する

これらがあれば、「置き換え候補が高く、まだMCP Deckへ配置されていないもの」を一覧にできる。
DB整備そのものを目的にせず、次に配置して試す数件を選ぶために使います。

Computer Useを置き換える候補

今回追加した本体組み込みアクションのうち、Computer Useの作業へ対応しやすいものは次のとおりです。

アクションComputer Useでの相当作業最初の評価
WebサイトURLを開く低リスクで候補にしやすい
アプリケーションを開くアプリを起動する低リスクで候補にしやすい
開くファイルやURLを開く対象パスを固定できる場合に有効
ホットキーキーを送る前面アプリへの依存が残る
テキスト文字を入力する入力先とカーソル位置への依存が残る
マルチメディア再生・停止など状態確認方法が必要
遅延描画待ち固定待ちが本当に必要か検討する

APIを直接呼び、APIで結果まで確認できる処理は、Stream Deckを経由する必要はない。
MCP Deckへ置き換える価値が高いのは、GUIしか窓口がない処理や、複数の固定操作をまとめる処理である。

また、アクションカタログから候補を見つけただけでは実行できない。置き換え先をMCP Deckの32キーへ配置し、get_executable_actionsに現れることを確認する工程が必要。今回の検討時点で実行可能であることを確認したのは、登録済みマルチアクション1件だけである。

置き換えの手順は、実行可能な集合から始める

当初案では、Computer Use版のSkillを先に作り、366件のデータベースから置き換え候補を探す流れを考えていました。
しかし、多くの候補が実行段階で空振りする可能性が高かった。

実際には、次の順序が適しています。

  1. Computer Useで繰り返している作業と、その完了条件を一つ選ぶ。
  2. APIで直接処理・確認できるなら、まずAPIを候補にする。
  3. get_executable_actionsで、現在MCP Deckから呼べるものを調べる。
  4. 該当アクションがなければ、データベースから低リスクの候補を検索し、MCP Deckへ配置する。
  5. 用途、副作用、前提条件、完了確認、再実行可否を、配置したアクションだけに記録する。
  6. Computer Use部分以外を同じにした二つの手順で、時間、成功率、再試行、動的トークン量を比較する。
  7. 改善が確認できた処理だけを正式なSkillや日常手順へ採用する。

効果を評価するときの注意点

今回の結果から、登録済み複合操作がComputer Useより速く、動的トークン量も少なくなる例を確認できた。
しかし、次の条件付きでの結果であることも確認できた。

  • 複合操作は各方式2回の少数試験で、統計的な優位性や長期の成功率を示していない。
  • Computer Use側ではObsidian操作の再試行が発生しており、この不安定さが差に含まれる。
  • 単一フォルダ試験では、公式MCPの方が平均で遅かった。処理をまとめれば必ず速くなるわけではない。
  • アクションの設定、MCP Deckへの配置、データベース整備といった初期負担は、日常実行の測定時間に含まれない。
  • execute_actionの成功応答は、登録済みアクションを発火したことを示す。下流の処理完了は別途確認する。
  • マルチアクションの危険度は名前だけでは分からず、内部のホットキー、スクリプト、送信処理などに依存する。
  • 作成したAI自身の主観だけで「速くなった」と評価せず、時間、成功、再試行を機械的に記録する。

比較回数を増やす場合は、平均だけでなく最悪時間、失敗内容、前面アプリが違う状態、Stream Deckアプリが動いていない状態も記録する必要がある。成功条件は、MCP Deck経由の成功率がComputer Useを下回らず、時間か再試行回数のどちらかが改善すること。

今回の結論

CodexとClaude Codeから、Elgato公式MCPを使ってStream Deckの登録済みアクションを呼べることは確認できた。
さらに、保存フォルダとObsidianノートを開く複合操作では、Computer Useに比べて完了確認までの時間と動的トークン量の両方が減ることも確認できた。

同時に、単純なフォルダ操作では時間短縮を確認できず、353件のカタログを丸ごと読ませる方法は大きなトークン負担になることも分かった。効果を生むのは、Stream Deckを使うこと自体ではなく、繰り返す固定処理を少数のアクションへまとめ、必要な候補だけを検索し、実行後の確認を一度で済ませる設計によるものだった。

Obsidianのアクションデータベースは、置き換え候補を探す基盤になった。今後は、低リスクで利用頻度の高い操作を数件ずつMCP Deckへ追加し、同じ成功条件で比較して、改善を確認できた処理だけを残すことが、時間とトークンを減らしながら安定性を高める現実的な進め方である。

実際に使えるアクションは元々限られているので、ユーザー実機のOSの制限を受けずにそれらを実際に使用できるか、使用するメリットはあるかなどを個別に検証する必要があることが分かった。

Codex / Claude Code Stream Deck ＡＩ
Claude Code Codex computer use MCP Obsidian skill streamdeck-mcp スキル
目次