Stream Deck+でWordPressのブロック挿入を試したら200msの遅延で安定した

2026年8月23日

いまさらながら、Stream Deck+にWordPressのブロック挿入の機能を割り当ててみました。Stream Deck+のボタンにWordPressのスラッシュコマンドやショートカットを登録し、見出し、画像、リストなどを呼び出す方法は以前から紹介されており、難しいこともないだろうと考えていたが、現在使っているWordPressで実際に試してみると、ブロック挿入の動作が安定しないという問題にぶつかった。
本記事では、ChatGPT-5.6 Solに相談しその問題を解決したのでその経緯を紹介する。

注）本記事の内容は正確性を保証するものではない。

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

直面した問題

現在使っているWordPressで実際に試してみると、Stream Deckへスラッシュコマンドを登録したブロックが正常にブロックに変換されないという問題に直面した。
例えば、リストブロックのスラッシュコマンド「/li」をStream Deckのボタンに登録し、そのボタンを押しても、「/li」と表示されるだけで、下図のようなリストブロックに変換されないという現象が見られた。ただし、ボタンの押し方によっては正常に変換される場合もあった。

そこから原因をAIの力を借りて調べていくうちに、文字列を送った直後にEnterを送るのではなく、少し待った方が安定することが分かった。

そして最終的には、200ms待ってからReturnを送るという設定に落ち着いた。

本記事では、単に「Stream DeckからWordPressのブロックを挿入する方法」を紹介するのではなく、以前からある方法を現在の環境で実際に試したらうまく動かなかったため、どの程度の遅延を入れれば安定するのかを何度も検証したのでその経緯をまとめたものである。

今回試した環境

今回の実機環境は次のとおり。

Stream Deck+
Stream Deck 7.4.2
macOS
Google Chrome
WordPress 7.1
SWELL 2.17.1
SWELL CHILD使用

SWELLには新しいバージョンへの更新表示が出ていたが、検証途中で環境を変えたくなかったため、2.17.1のまま確認した。

WordPress×Stream Deckの基本的な使い方

Stream DeckをWordPressの記事作成に利用する方法としては、以前から、

見出し
リスト
画像
引用
吹き出し
WordPressやテーマ独自のブロック

などを、Stream Deckのボタンから呼び出す使い方が紹介されており、WordPressのブロックエディターでは、

/○○

と入力するとブロック候補を検索できるので、Stream Deckからこの文字列を入力し、続けてEnterを送れば、物理ボタンを押すだけでブロックを挿入することができるようになっている。

また、複数の処理を続けて実行する際には、処理速度を合わせるために途中に遅延を入れる方法も行われていた。

基本的には、この仕組みを使うが、現在のWordPress環境では、単純に文字列とEnterを続けて送るだけでは安定しないことが分かった。

まずテキスト入力の方法（クリップボードからペースト）を試した

Stream Deckのアプリで、Stream Deckのボタンに「テキスト」として下記の設定を行って動作を試した。下記の設定では、「/li」の文字列の入力の後に「Enter」が自動的に入力されるようになる。また、クリップボードから、「/li」の文字列がまとめて入力される。

複数回、このボタンを押したところ、下図のように、正常にブロックに変換されることもあるが、失敗することが多いという状況だった。

Gutenbergが候補を準備するよりEnterの方が速いことが原因の可能性があった

Stream Deck側では、

/que を入力
↓
すぐEnter

と処理されるが、AIによると、WordPress側では、下記の処理が必要とのことだった。

/que を受け取る
↓
ブロックを検索
↓
候補を表示
↓
候補を選択できる状態になる

Stream Deck側のEnterが、Gutenberg側で候補を確定できる状態になるより早く届いているからである可能性があった。
そこで、「文字列入力とEnterの間に時間を空ける」という方法を試すことにした。

「入力をシミュレート」のモードを試したが失敗

下図のように、テキストモードを、「入力をシミュレート」に切り替えて試してみた。

AIによれば、文字列を一括で入力せず、本当にキーボードで入力しているように1文字ずつ送れば、WordPress側にも処理する時間ができる可能性があるとのことでした。
結果は下図の通り、「クリップボードからペースト」のモードの場合とは違う現象が見られたが、正常にブロックに変換されるが多くは失敗するいう状況は変わらなかった。

Multi Actionで「Text→Delay→Enter」に変更

次に試したのがMulti Action。下図のように、テキスト入力（/li）、遅延（仮設定として200msを設定）、ホットキー（中身はEnter）の順に処理ブロックを並べて試した。テキスト入力では、テキストの後にEnterが自動的に入力されないようにした。
その結果、複数回、連続してボタンを押しても正常にリストブロックに変換されるようになった。

この結果から、ブロック化に失敗するのは、下図の理由によるものと思われた。

100ms、200ms、300ms、500msの遅延時間を試すことになった

遅延時間200msは仮の設定値だったので、安定してブロック化を発生させるための最適な遅延時間を探る必要があったが、AIの提案により、複数の設定値（100ms、200ms、300ms、500ms）を試すことになった。
検証結果は下表の通りであり、いずれの場合もブロック化に成功したが、設定値前後の余裕を考慮して200msを設定値とすることになった。

遅延時間（Delay）	結果
100ms	8回/8回成功
200ms	3回/3回成功
300ms	3回/3回成功
500ms	3回/3回成功

今回の調査では、遅延時間を200msに設定したが、これは、使用するパソコン機種やソフトウェアのバージョンなどによって変わる可能性があることに注意。使用環境が変われば変更しなければいけない可能性もある。

AIからは、正常にブロック化するか、例えば5回試し、そのスクリーンショットを撮って報告するように指示された。しかも、その処理を、「ふきだし」、「メモ」、「リスト」など、20個程度の各ブロックについて行ったので、非常に手間がかかり、この処理だけで、Codexの7日枠の制限に引っかかるのではないかと心配するほどだった。

Multi Actionには、もともと、「遅延」の処理ブロックがあり、連続する処理が速すぎる場合に、PC側の処理速度へ合わせるために待ち時間を入れるためのものとして説明されているが、今回は、処理速度を調整するためではなく、WordPressのブロック候補が確実に準備されるための余裕を与えるという目的で使用することになった。

メインページの８ボタンを設定

安定する方式が決まったので、WordPress用のボタンを同じ遅延時間で下図の８個を設定した。


ふきだし	メモ	区切り	画像
見出し	リスト	関連記事	SWELL＋

見出しはH2・H3・H4を別ページにした

見出しについては、上図の「見出し」ボタンを押すと、下図の別ページに飛ぶように構成し、そのページで、H2・H3・H4の見出し用のボタンを設定した。

スラッシュコマンドとして、どのような文字を入れると、見出しブロックに変換されるか試したところ、変換候補の第一候補となっていれば、Enterを押すことによって見出しブロックに変換されるようだった。変換候補の第一候補となり、より確実に変換されるように、「/H2、/H3、/H4」を設定した。

H2、H3、H4はいずれも正常にブロック化され、例えば、/H2は下図のように変換された。

SWELLのブロックは「SWELL＋」へまとめた

SWELL用ブロックも別ページにまとめ、下図のように設定した。

それぞれのボタンには下表の文字を設定した。

機能	マルチアクションのテキスト処理ブロックに設定する文字
キャプション	`/cap`
関連記事	`/rel`
ステップ	`/ste`
FAQ	`/fa`
SWELLボタン	`/swellボ`
ブログパーツ	`/blogp`

「引用」はあえてボタンに設定しなかった

引用ブロックに変換される文字を調査した。
下図に示す通り、「/quo」でも「/引用」でも第一候補になっているので、続いてEnterを入力することによって引用ブロックに変換できたが、複数の候補が表示され一意に決まらない状態だった。第一候補を自動的に選ぶだけなら現在は動くが、候補順が将来変われば、別のブロックが挿入される可能性があったので、引用ブロックはボタンに設定しなかった。

Stream Deck+のダイヤルにはUndo・Redo・保存

また、Stream Deck+を使っているので、ダイヤルもWordPress編集に利用することにし、ダイヤルの1つ（以降、「ダイヤル1」）に下図の設定を行い、「Undo」、「Redo」、「保存」の機能を設定した。

操作	機能	設定する文字（Macの場合）
左回転	Undo	⌘Z
右回転	Redo	⇧⌘Z
押す	保存	⌘S

UndoとRedoの機能を繰り返し確認していたところ、予想外の現象が見られた。（原因の詳細は不明）

「DIAL1」という文字をキーボードから入力し、ダイヤル1を反時計周りに1ノッチ回すと「DIAL」となり、さらに1ノッチ左に回すと、「DIAL」の文字が消えてしまった。「DIA」となると思っていたので、予想外の結果となった。続いて、ダイヤル1を時計周りに1ノッチ回し、「Redo」を実行すると、「DIAL」の文字が現れ、さらに「Redo」を実行すると、「DIAL1」となった。キーボードから1文字ずつ入力して再度確認したが同様の現象が発生した。
この現象についてChatGPT-5,6 Solに聞いたところ、下記の回答があったので、異常な動作とも言えないようだったので、何も対策していない。

「DIAL1」が2回のUndoを必要とした件も問題ではありません。1ノッチでWordPressのUndo履歴を1件だけ処理できているので、むしろダイヤルの動作は正確です。ここを無理に「1回で全部戻す」ように変更する必要はありません。

また、下記のように回答された。（詳細不明）

実際には、WordPress側が、「文字入力」と「ブロック変換」を別々のUndo履歴として持っているためで、1ノッチでUndo履歴1件を正しく処理しています。

⌘SでもChromeの保存画面は出なかった

ChatGPT-5.6 solからは、⌘S（保存）を実行した場合に、「保存済み」と表示されることと、ブラウザの保存ダイアログは出ないことを確認するように指示があった。
ChatGPT-5.6 solによれば、Chromeで⌘Sを押すと、「Webページ保存のショートカット」として使われることがあるため、「⌘S」の実行が、「WordPress側の保存」として処理されるかどうかを確認するためとのことだっった。

Mac実機で確認したところ、下図の表示が現れ、ブラウザの保存ダイアログは表示されなかったので、「WordPress側の保存」として処理されていることが確認できた。

ダイヤルにページ移動は設定できなかった

別のダイヤルに、ページ移動の機能を設定しようとしたが、ボタンには下図の「前のページ」「次のページ」「ページ移動」の処理ブロックがあるが、ダイヤルには、その処理ブロックが、利用できる処理ブロックの候補として現れず、現時点でダイヤルにはページ移動の標準機能がなく、設定できないことが分かった。

ChatGPT-5.6 Solによれば、外部プラグインを導入するという方法もあるとのことだったが、Stream Deck+にはタッチバーがあり、左右へスワイプすればページ移動できるので、外部プラグインは導入しないことにした。

今回行ったこと自体は高度な技術を用いたものではなく、WordPressのスラッシュ入力をStream Deckへ登録する使い方は以前からあり、Multi Actionに遅延（Delay）の処理ブロックも用意されているので、遅延も一般的な機能だが、今回違ったのは、現在のWordPress環境で実際にやってみたら、昔ながらの単純なText＋Enterでは動かなかったところから始まったことだった。今回は、Codexから、手間のかかる検証を指示され、その指示の一部に疑問を持ち、特に500msまで検証する必要があるのかを検証途中でCodexに質問したところ、ChatGPT-5.6 Solが作成した実装指示書にそう書いてあるからと、実装指示書の該当箇所が示され、Codex自身が理由を直接考察することは無かった。