CodexでStream Deckのボタンを管理する。日常業務26キーを、会話しながら育ててみた

相談の出発点は、業務でStream Deckをもっと活用できないか、というものだった。検索、メモ、資料を開く、作業用のタイマー。それに加えて、仕事の状態に合わせて表示が変わり、押すと次へ進むような使い方も考えていた。

Macに接続したStream Deckから、Windowsの画面を撮ってMacに持ってきたい。CodexとClaude Codeの利用枠を、手元のボタンで確認したい。文字が小さくて読みづらいので、大きくしたい。文字だけで埋めるより、アイコンも使いたい。

その要望を会話で伝え、実装してもらい、実際の表示を見てまた直す。そうして、日常業務用の26キーと、LLM（Large Language Model）の利用枠を表示する専用の配置ができた。

途中では、ボタンが消えたように見える不具合にも遭遇した。設定を調べると、ボタンは残っていて、表示するプロファイル（Stream Deck）と戻り先の扱いがずれていた。この修正まで含めて、今回の体験だった。

面白かったのは、設定を一度作って終わりにせず、使って気づいたことを、そのまま次の変更につなげられたことだ。

この記事では、完成した配置、二つの外部連携、見やすさの調整、そして失敗からの修正を紹介する。あわせて、Codexにボタン管理を任せるとき、何を会話で決め、何を確かめる必要があるのかを整理したい。

Stream Deckは、キーに機能を割り当てて使うデバイスだ。XLには4段×8列、32個のキーがある。プロファイルにはホットキーやテキスト入力、プラグインの機能などを配置できる。Elgato公式：プロファイルの概要

便利さを想像するのは簡単だ。「あのフォルダを開くボタンが欲しい」「会議メモへすぐ移動したい」「よく使う操作をまとめたい」。

ただ、それを日常で使える配置にするには、機能を選ぶ以外にも仕事がある。

どこに置くか。何という名前にするか。キーの画像をどうするか。ほかのアプリを使っているときに押すとどうなるか。別のページへ行った後、どこへ戻るか。環境を変えたら、どの設定を直す必要があるか。

一つずつは小さな作業でも、積み重なると設定するためのまとまった時間が必要になる。追加したい機能があっても、とりあえず今の配置を使い続ける理由になる。

そこで今回、Codexに任せたのは、ボタンのアイデア出しから、設定ファイル、アイコン、小さなプログラム、動作確認までだった。こちらは「何をしたいか」と「使ってみてどうだったか」を伝える。

もちろん、短い言葉だけですべての仕様が決まるわけではない。たとえば「残りトークンを表示したい」という要望は、後で「CodexとClaude Codeの利用枠の残り％と、リセットまでの時間」に具体化した。この言い換えも、実装に入る前の大事な作業だった。

今回の構成を理解するには、設定を作る場面と、完成したボタンを使う場面を分けると分かりやすい。

設定を作るときは、Codexと会話する。Codexがローカルのファイルを調べ、配置や画像を作り、必要なプラグインやスクリプトを実装する。既存設定をバックアップし、新しい配置をStream Deckアプリへ反映する。

今回使ったのは、Mac上のCodexアプリだ。ローカルの設定ファイルとプログラムを扱える環境で作業した。専用プラグインはStream Deck用として作り、導入する端末と内容を確認してインストールした。

完成後、検索キーを押すときには、登録したショートカットが送られる。会議キーならメモファイルが開く。残量表示は、作成したプラグインが利用状況を読み、画像を書き換える。

毎回のボタン操作をAI（Artificial Intelligence）が解釈しているわけではない。 Codexが作った設定とプログラムが、決められた役割を実行している。

この分担は実務で扱いやすい。文章をまとめるような仕事ではAIの判断が役立つ一方、タイマーの残り時間や、開くフォルダの場所は、決めたとおりに動いてほしい。設定や実装をAIに手伝ってもらうことと、実行のたびにAIへ判断を求めることは、別々に選べる。

Stream Deckの公式SDK（Software Development Kit）には、キーの画像やタイトルを更新する機能がある。静的なショートカットに加え、タイマーや利用枠のような状態表示を作れたのは、この仕組みを使ったためだ。Elgato公式：Keys

最初にまとめたのは、日常業務のページだ。

基本の24キーに、Windows撮影とLLMページへの入口を加え、最終的に26キーを割り当てた。残り6キーは空けてある。

配置の軸は、アプリの名前を一覧にすることより、作業の種類をそろえることに置いた。

ここで、ボタンの名前と実際の動作を正確に合わせておきたい。

「記事」は、制作物のフォルダを開くボタンだ。そのキーだけで記事が生成されるわけではない。「経理」も、手順や記録のあるフォルダを開く。「今日」「会議」「しおり」「終業」は、それぞれのメモファイルを開く。日付ごとに新しいファイルを自動生成する機能までは入れていない。

この程度の入口でも、置き場所を思い出し、フォルダをたどる操作をまとめられる。業務で頻繁に使う資料が決まっているなら、まずはそこからでよい。

「しおり」は、途中で止めた作業の続きを書いておく場所にした。会議や別件で作業が中断したとき、次に何をするつもりだったかを残せる。高機能なタスク管理ツールを追加するほどではない小さな用途も、ボタンにすると手元に置きやすい。

一方、「書式なし貼り付け」や「やり直し」のようなショートカットは、使っているアプリの割り当てに左右される。ボタンがあることと、すべてのアプリで同じ動作になることは同義ではない。普段使うアプリに合わせて確認する必要がある。

AI向けのボタンは、いきなりすべてを自動化しなかった。

「要約」を押すと、結論、重要な事実、次にすることの3点でまとめるための指示文を入力する。「校正」では、意味や事実を変えずに文章を整える指示文を入れる。対象となる文章を添え、送信する操作は自分で行う。

選択中の文章を自動で読む処理も、送信先を選ぶ処理も入っていない。開いている入力欄へ定型の指示文を入れるだけなので、使う際は入力先を確認する。文章をどこまで渡すか、どのAIに依頼するかは、その場で決められる。

自分が毎回少しずつ違う書き方で頼んでいた仕事に、共通の入口を作る。最初のAIボタンとしては、このくらいの範囲でも試す意味があると感じた。

使い続けてから、「要約」一つでは足りず、「顧客向け」「社内共有用」「記事用」に分けたくなるかもしれない。そのときに、指示文と表示名を一緒に見直せるのも、会話で管理する利点だ。

25分の作業タイマーと5分の休憩タイマーも追加した。

同じキーで開始、一時停止、再開を切り替え、停止キーでリセットする。作業と休憩は同時に走らず、別のタイマーを選ぶと切り替わる。キーには残り時間と状態が表示される。

ここで、ボタンの役割が少し変わる。押す前と押した後で見た目が変わり、今どうなっているかを教えてくれる。

実装では、単純に毎秒数字を一つ減らすのではなく、終了予定の時刻から残り時間を計算している。保存した状態から復帰する処理も用意した。終了時はキーに完了を表示する仕様で、音やOS（Operating System）通知は加えていない。

開始、停止、再開、時間切れ、保存状態からの復帰などは、ローカルのテストで確認した。管理画面にも実際のタイマー表示が出ている。ただし、この記事を書くまでに、すべての条件を物理キーで操作し、25分間通して使う試験まで済ませたわけではない。

こうした区別は、実用化を進めるうえで役に立つ。プログラムの状態遷移が合っていることと、手元の道具として気持ちよく使えることは、それぞれ確かめたい。

機能を並べてみると、次の不満が出た。文字が小さくて読みにくい。

説明を丁寧に載せようとするほど、キーの中に文字が増える。管理画面では読めても、机の上の小さなキーを一瞬見て判断するには厳しい。今回は「もっとフォントサイズを大きくしてほしい」「アイコンも使えないか」と伝えて、表示を作り直した。

最終的には、大きなアイコンに短い名前を添える形にした。撮影はカメラ、検索は虫眼鏡、予定はカレンダー、しおりはブックマーク。「今日」「会議」「終業」のように、絵だけでは用途を決めづらいものには、短い言葉を残す。

素材の設計では、144×144のキー画像を基準に、アイコンは約64px、短いラベルはおおむね40pxとした。これは画像内の設計値であり、机上での見え方は実機の表示サイズや見る距離にも左右される。数字が主役のタイマーや利用枠は、名前よりも残り時間や％を大きく見せた。

同時に、ラベルから長い説明を外した。操作の詳しい意味は、ガイドや、押した先のPC（Personal Computer）画面に置く。キーには、探すために必要な情報を残す。

この調整で大事だったのは、最初から正解のアイコンを決められたことではない。実際の表示を見て「これでは読みにくい」と伝えた後、同じ配置に対してまとめて変更をかけられたことだ。

業務用の道具では、機能の数と同じくらい、目で探しやすいことが効いてくる。毎日使うつもりなら、文字の大きさや色の強さも、後回しにせず変更の対象にしたい。

次に作ったのが、LLMの利用枠を表示する専用ページだ。

欲しかった情報は二つある。あと何％使えるか。そして、いつリセットされるか。

たとえば同じ「残り10％」でも、リセットが20分後なのか、数日後なのかで、次の作業をどう進めるかは変わる。残量と時間を並べることで、単に少ない、多いという表示より判断しやすくなる。

ただし、ここで表示するのは、契約上の利用枠に対する残りの割合だ。処理できる正確なトークン数や、API（Application Programming Interface）料金の残高ではない。

ページには、CodexとClaude Codeそれぞれの5時間枠、週間枠を置く構成にした。数字と棒グラフを大きくし、その下に「あと3h20分」「あと1日12h」といった形で時間を出す。更新と戻るも、大きな矢印のアイコンにした。

日常ページには入口だけを置き、詳しい数字は専用ページにまとめた。常に触る操作と、必要なときに確認する情報を分けることで、日常の26キーを動かさずに済む。ページを増やすときも、いつものキーの場所と、戻る操作をそろえておきたい。

Codex側では、ローカルのapp-serverを通じて account/rateLimits/read を呼び出す構成にした。公式資料では、使用率、利用枠の期間、次のリセット時刻を受け取れる。今回のプラグインは、その中のCodexの枠を選んで表示する。OpenAI公式：Codex App Serverの利用枠

実装上は、使用率を残りの割合に変換し、リセット時刻と現在時刻の差を表示する。定期的な読み取りに加え、キーを押して更新を求める処理も入れた。表示のためにモデルへ新しい仕事を依頼する構成にはしていない。

今回のアカウントで実際に取得できたのは、週間枠だった。5時間枠は情報が返らなかったため、「未取得」と表示している。欠けている値を、残り0％や100％に置き換えてはいけない。未取得という表示にも意味がある。

Claude Code側では、公式のstatusLine（Claude Code）機能を使った。そこへ渡される利用枠の情報から、使用率とリセット時刻だけを取り出し、ローカルの小さなファイルへ保存する。Stream Deckのプラグインが、そのファイルを読む。Claude Code公式：statusLineの利用枠表示

今回の実装では、会話本文や認証情報を、この表示用ファイルに保存する必要はない。実際に既存のClaude Codeセッションから情報が届き、5時間枠と週間枠の値が表示され、ファイルが更新されることを確認できた。

注意したいのは、更新ボタンの意味だ。Claude側で行うのは、手元に届いたデータの読み直しである。そのキーを押せば必ずサーバーへ問い合わせ直せる、という意味ではない。Claude Codeから新しい情報が届いていないときは、そのことが分かる表示にする。

未取得、古い値、リセット時刻を過ぎた値を分ける処理も用意した。正確そうな数字が出ているだけでは、確認用の道具としては足りない。どの情報を、いつ受け取って表示しているのかまで含めて、使える表示にしたい。

なお、Claude CodeがstatusLineへ渡す利用枠は、対応バージョン、契約や接続形態、セッションの状態などの条件に依存する。すべての環境で同じ項目が返る前提にはできない。Claude Code公式：利用できるデータ

もう一つ、今回らしい機能がWindowsの画面取得だった。

Stream DeckはMacにつないでいる。一方で、別のWindows端末も使っている。そこで、Mac側のボタンを入口に、Windowsの画面を撮影してMacへ保存する処理を作った。

通信には、すでに接続できていたTailscale経由のSSH（Secure Shell）を使う。新しい撮影用HTTP（Hypertext Transfer Protocol）サーバーを立てる必要はなかった。ここでいう「Tailscale経由のSSH」は、既存のSSH接続をTailscaleのネットワーク越しに使うという意味だ。

処理の流れは、次のようになる。

1. 1Macから、Windowsへ撮影の依頼を送る。
2. 2Windowsのタスクスケジューラで、専用の撮影プログラムを起動する。
3. 3ログイン中の本人の画面をPNGとして保存する。
4. 4Macが画像を受け取り、受け取ったファイルを検証して保存する。

ポイントは、SSHでつながった処理から、そのまま普段のデスクトップを撮ろうとしないことだった。今回確認した環境では、SSHの処理と、普段ログインして画面を使っているセッションが分かれていた。そのため、ログイン中の本人のセッションで撮影プログラムを動かす構成にした。

Windows側のタスクは、本人の通常権限で動かし、定期実行やログイン時実行のトリガーを付けない。撮影を依頼したときだけ起動する。こうした実行ユーザーや権限の指定は、Windowsのタスクスケジューラ（Windows）の仕組みを使っている。Microsoft公式：タスクの実行ユーザーと権限

Macから撮影処理を直接実行するテストでは、2560×1440のPNG（Portable Network Graphics）を取得できた。Windows側のファイルと、Macに届いたファイルのチェック値が一致することも確認した。その処理の起動ファイルを、日常ページの右上にある「Win」キーへ割り当てている。

検証範囲は正確に書いておく。このテストは、物理的なWinキーを押してプレビューが開くところまでを通した試験ではない。撮影処理を直接起動し、転送と保存を確認したものだ。

また、Windowsが起動し、接続でき、本人がログインしてロック解除していることを前提にしている。ロック中の画面を勝手に開く機能ではない。取得した画像は両端末に残り、自動削除はまだ入れていない。

この機能で感じたのは、左手のボタンの行き先は、USB（Universal Serial Bus）でつながっている一台のPCだけに限らないということだ。既存の接続を使い、自分の業務環境に合わせた処理の入口を手元へ置ける。

今回、記事に残しておきたいのが、この失敗だ。

追加したボタンが、画面から消えてしまった。LLMのページから戻ると、元のデフォルトプロファイルになってしまう。

調べると、日常ページの26キーは保存されたままだった。消えていたのは設定ではなく、その配置の表示だった。

原因は、今回作った設定と切り替え処理にあった。日常ページを追加した一方で、普段の表示先として選ばれる既定プロファイルは、元のままになっていた。さらに、追加したプラグインには、起動時に専用プロファイルを自動表示する処理も入れていた。

最初に完成形を見せるための自動表示と、LLMから戻る処理と、もともとの既定設定が、利用者から見て一貫した動きになっていなかった。

Stream Deckでは、ボタンの設定、配置をまとめるプロファイル、現在表示している画面、既定の表示先を、それぞれ考える必要がある。単に「新しい配置を作った」だけで、行き帰りまで決まるわけではない。

修正では、まずプラグインが起動や再接続に合わせて勝手に画面を切り替える処理を外した。LLMへの移動は、明示的にキーを押したときに行う。表示するプロファイルも日常ページにそろえ、アプリを再起動して26キーが表示されることを確認した。

さらに記事用の画面を撮影していると、見落としが一つ見つかった。日常ページが選択されていても、環境設定の「これを自分のデフォルトプロファイルにする」にはチェックが入っていなかった。現在表示している配置と、既定の戻り先は別だったのだ。ここは管理画面からチェックを入れ、設定されたことまで確認した。

公式SDKでも、プラグインが切り替えられるプロファイルには範囲がある。どのプラグインが入口を持ち、どの配置へ移動させるかを、実装時に合わせる必要がある。Elgato公式：プロファイルの組み込みと切り替え

この経験で、物理キーを使う道具の設計では、「何ができるか」と同じくらい、「今どこにいて、どう戻るか」が大切だと分かった。便利な機能を増やしても、いつもの場所にいつものキーがなければ、使う側は戸惑う。

AIが実装を進めてくれるほど、機能は追加しやすい。その分、操作する人から見た一貫性を、最後に確かめる必要がある。

今回の作業では、新しい配置を作るだけでなく、更新前のプロファイルや設定をバックアップした。変更するときには、既存のキーが想定した設定のままかを確認し、違っていれば一律に上書きしないようにした。

これは、AIに任せるから特別に必要になったというより、設定を継続的に変えるようになったことで必要性が増したものだ。

自分で管理画面から修正した内容と、Codexが作った元データが食い違うこともある。古いデータから全体を作り直せば、その場で調整した内容が消える可能性がある。どれを正として更新するのかを決めておく必要がある。

管理したいのは、少なくとも次の四つだ。

新しいプログラムをMacやWindowsへ配置する場面では、その内容を確認してから導入した。会話の流れに合わせて、どの端末へ何を追加するのかを具体的にしておくと、承認する側も判断しやすい。

その一方で、今回の成果物には、個人の環境に合わせた部分も多い。ファイルの場所、インストールされているアプリ、利用しているCLI（Command Line Interface）、SSHの接続先などは、別のPCでそのまま使えるとは限らない。

設定を渡せば誰でも同じ環境が完成する、という段階ではない。再利用するなら、コードに埋め込んだ環境固有のパスや接続先を、設定ファイルへ切り出す作業が次に必要になる。

今回の経験を踏まえると、最初から大量の機能名を並べるより、使う場面と、守りたいことを伝える方が設計しやすい。

たとえば、次のように頼める。

外部連携では、押した後の終わり方まで伝えるとよい。

これらは今回のやり取りを整理した依頼例で、元の会話の逐語録ではない。

要点は、何を自動にするか、どこまでを一回の操作にするか、失敗したら何を表示するかをそろえることだ。

たとえば「返信ボタンが欲しい」だけでは、会話を開くのか、返信案を作るのか、そのまま送信するのかが分からない。「記事ボタン」も同じで、フォルダを開く機能と、原稿を生成する機能と、公開する機能では、意味が大きく違う。

短い名前を付けるのは最後でもよい。まず、そのボタンを押して何が起き、何が終われば成功なのかを決めたい。

今回の実装を進めながら、もう一つ考えていた使い方がある。

SlackやBacklogから、自分が返信すべきもの、自分が判断すべきものを集め、手元のキーに並べる。記事制作であれば、調査、下書き、確認、公開という流れの中で、人の確認が必要になったときに表示を変える。

この構想は、今回紹介した日常ページや実データの利用枠表示とは、進み具合が違う。状態に合わせて表示が変わるデモは作ったが、SlackやBacklog、AIによる原稿生成、実際の入稿・公開先との接続はまだ行っていない。デモで処理した仕事は架空のものだ。

実業務につなぐなら、単に通知を並べればよいわけではない。読んだだけで片づけてよいのか。返信した後も、自分の作業が残るのか。相手待ちに移した項目は、いつ戻すのか。同じ依頼を二重に出さないか。

こうした仕事の状態を整理してから、表示へ結びつけたい。

一方で、利用枠やタイマーの表示を作ったことで、手元のキーが状態を伝える入口になることは、かなり具体的に見えてきた。次の実装では、自分の手番が来た仕事を、その場所へ持ってくることを試したい。

今回の記事は、自分の環境で作り始めた道具の実装記録だ。使い始めた時点の手応えはあるが、長期的な業務改善効果を測定したものではない。

今後は、使わなかったボタン、探したボタン、何度も押したボタンを見ながら、配置を直していくつもりだ。減らすことも、追加と同じくらい大切になる。

32キーを埋めることが目的になると、覚えるものが増える。残している空きには、使い始めてから見つかる仕事を置けばよい。

日常の操作、メモ、タイマー、利用枠の表示、別PCの撮影。今回追加した機能はさまざまだが、共通していたのは、仕事中の小さな要望を、手元の配置へ反映していったことだった。

「もっと見やすく」「この仕事も入口が欲しい」「今の戻り方はおかしい」。そうした言葉から、保存されている設定を確認し、必要な部分を直していく。使い手として気づいたことを、次の変更へ渡しやすくなった。

仕事の流れが変わったら、ボタンも変える。使わない機能は外し、必要な情報を目に入る場所へ置く。

CodexとStream Deckを組み合わせる面白さは、そうした小さな作り替えを続けられるところにある。左手の32キーを、自分の仕事に合わせて少しずつ育てていきたい。

本記事は2026年9月の個人環境での実装記録。Mac接続のStream Deck XL、Codex、Claude Code、Tailscale経由で接続できるWindowsを使用した。掲載した管理画面は執筆時の状態であり、利用枠の数値は撮影時点のもの。外部サービス連携の対応範囲や取得可能な項目は、各製品の仕様・バージョン・契約・環境によって異なる。