Firefox on ざわらぼ

ダウンロード： 最新のReleases

詳しい導入方法： README（日本語）

操作	導入後の初期設定
`Enter`	改行
`Ctrl+Enter`	送信
IME変換中の`Enter`	変換候補の確定。送信も改行もしない
`/`コマンドやメンション候補表示中の`Enter`	Claude本来の候補選択

サイドバーの「⌨ キー設定」から有効・無効を切り替えたり、送信キーと改行キーをEnter、Ctrl+Enter、Shift+Enter、Alt+Enterの中から選び直したりできます。設定は再起動後も保持されます。

実際の操作感としては、特別な機能が増えたというより、ほかのチャットアプリと同じ感覚で普通に文章を入力できるようになった、というものです。今回ほしかったのはまさにそれなので十分です。

対応環境

項目	2026年10月9日時点の状況
Windows 10 / 11	Claude DesktopのMSIX版向け。Windows実機で検証
検証したClaude	`2.26454.2`、`2.31226.0`（共通ローダー移行後は後者で確認）
Linux	Claude Desktopベータ向けスクリプトあり。実機未確認、CIテストのみ
macOS	未対応
インストール権限	Windowsでは管理者権限不要

Claude本体のclaude.exeやapp.asar、Microsoft Storeアプリのインストール先には手を加えません。

導入方法（Windows）

最新のReleases

zawa356/claude_ctrl-enter

GitHub Repository

github.com

からclaude-ctrl-enter-<バージョン>.zipをダウンロードして展開します。
中にあるinstall.batを実行します。診断情報を確認し、続行を求められたらYを入力します。
Claude Desktopをタスクトレイから完全に終了させます。単にウィンドウを閉じるだけでは不十分な場合があります。
いつものClaudeのアイコンから起動し直します。
左サイドバーのプロフィール欄の上に「⌨ キー設定　有効」と出ているか確認します。

これでEnterは改行、Ctrl+Enterは送信になります。インストール後も専用ランチャーやショートカットは不要です。

Windowsが未署名のbatファイルについて警告する場合があります。内容を確認したうえで実行してください。インストーラーやPowerShellスクリプトもリポジトリで公開しています。

元に戻す： uninstall.batを実行し、Claude Desktopを完全終了して起動し直します。キーだけ一時的に元へ戻したい場合は「キー設定を有効にする」をオフにする方法もあります。

診断： diagnose.batは読み取り専用です。動かないときは、まずこれで導入状況を確認できます。

配布版の導入・更新手順は今後変わる可能性があるため、実際にインストールするときはREADME

を優先してください。

なぜAutoHotkeyではなく、Electronの中に実装したのか

ここから先は技術的な話です。

「Ctrl+Enterを押したら送信するだけ」なら、Windowsのキーリマップで終わるように思えます。自分も最初はそう考えてAutoHotkey v2を使い始めました。

しかし、問題の中心にあったのはCtrl+Enterではなく日本語IMEの変換確定でした。

1. Enterには別の役割がある

日本語入力中のEnterは、状況によって違う意味になります。

変換候補の選択・確定
未確定文字列の確定
変換が終わったあと、通常の入力欄で行う改行
Claudeが割り当てている送信

さらに、句読点や「＠」のような全角記号、候補ウィンドウ、キー入力のタイミングも関係します。

Windows側で単純にEnterを別のキーへ変換すると、IMEが必要としているEnterまで奪ってしまう可能性があります。

なので、まずはWindowsからIMEの変換状態をどこまで取得できるかを調べました。

2. AutoHotkey + UI AutomationでIMEイベントを調べる

AutoHotkey v2とUI Automationを使い、Claude Desktopの入力欄に対して、次のイベントを監視する試作を作りました。

イベント	調査上の意味
`TextEditTextChanged` / `Composition(2)`	IME変換中に観測されたイベント
`TextEditTextChanged` / `Finalized(3)`	確定を検出できるか試すためのイベント
`TextChanged(20015)`	テキストが変更されたことを示すイベント

調査スクリプトはAutoHotkey v2のUIAライブラリを使用したもので、入力キー自体は変更せず、イベントの時刻と種類だけをログに残す診断用でした。変換文字列や入力内容は記録していません。

実際に使用したスクリプトでは、おおむね次のようにハンドラーを登録しています（コードは要点のみ。実行にはAutoHotkey v2とUIA-v2ライブラリ、およびコールバック・後始末の実装が必要です）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


#Requires AutoHotkey v2.0
#Include Lib\UIA.ahk

el := UIA.GetFocusedElement()

; 変換・確定関連の通知を観測
hComp := UIA.CreateTextEditTextChangedEventHandler(OnComposition)
hFinal := UIA.CreateTextEditTextChangedEventHandler(OnComposition)
hText := UIA.CreateAutomationEventHandler(OnTextChanged)

UIA.AddTextEditTextChangedEventHandler(hComp, el, 2, 1)
UIA.AddTextEditTextChangedEventHandler(hFinal, el, 3, 1)
UIA.AddAutomationEventHandler(hText, el, 20015, 1)

ここで期待していたのは「Compositionで変換中へ入り、Finalizedで変換終了が分かる」という素直な状態遷移です。

しかし、実際の通知はそう簡単ではありませんでした。

2-1. 観測できたイベントの順序

2026年10月8日のログから、代表的な部分を抜粋すると次のような形です。

1
2
3
4
5
6
7
8


2719 ms | RAW Composition(2)
2719 ms | STATE=COMPOSING (Composition observed)
2719 ms | RAW TextChanged(20015)
2719 ms | MATCH Composition -> TextChanged
3328 ms | RAW TextChanged(20015)
3328 ms | STATE=PENDING_TEXT
3500 ms | UNMATCHED TextChanged
3500 ms | STATE=IDLE_INFERRED (Unpaired TextChanged (NOT guaranteed))

※ログのSTATE=...は診断スクリプト自身が推定した状態です。Windowsが「IMEは終了した」と保証したものではありません。

CompositionとTextChangedが同時、または十数ミリ秒の差で届く例がありました。一方でTextChangedだけが単独で届く場面もあります。

そこで、CompositionとTextChangedを150ms以内の時間差で照合し、対応しないTextChangedがあったら変換終了を推測する分類器まで作っています。

しかし、これでは「変換終了を確実に検出できた」とは言えません。実際のログでも状態名はIDLE_INFERRED、理由はNOT guaranteedです。

この結果は、AutoHotkeyやUI Automation全般でIME判定が絶対にできない、という証明ではありません。少なくとも今回のイベントと判定方式だけでは、誤送信を防ぐための十分に確実な状態判定にならなかった、という話です。

本来の目的は、キー操作を楽にすることです。判定器のタイミング調整を延々と続けるより、もう少し入力欄に近いところで処理した方がよさそうです。

3. Claude Desktopの中身はElectron

ということで、別の方向から攻めることにしました。

Claude DesktopのUIはElectron上で動いています。つまり、Webページ側のDOMやキーボードイベントにアクセスできれば、WindowsのIME状態を外側から推定するより、入力欄が直接受け取っているイベントに基づいて判断できます。

ただし、公式のClaudeアプリを壊してまでキー操作を直したいわけではありません。

ここでの制約は最初から次のとおりでした。

claude.exeやapp.asarを改変しない
Microsoft Storeの署名付きMSIXを壊さない
いつものアイコンから普通に起動できる
新しい専用ランチャーを使わせない
不要になったら解除できる

この条件を満たす方法を探します。

3-1. `app.asar`を読み取り専用で調べる

最初にWindows側でパッケージ情報を確認しました。

1
2


Get-AppxPackage -Name '*Claude*' |
 Select-Object Name, Version, PackageFamilyName, InstallLocation

調査した2.26454.2では、app/resources/app.asarが存在しました。app.asarはElectronでよく使われるアーカイブ形式です。

本体を変更しないよう、作業用のフォルダーへコピーしてから解析しました。実例として、コピー後の作業フォルダーで次を実行すれば、パッケージ情報を読み出せます。

1
2
3
4


# ここでは作業用フォルダーに app.asar をコピー済みとする
npx --yes @electron/asar extract-file .\app.asar package.json
Get-Content .\package.json -Raw | ConvertFrom-Json |
 Select-Object name, version, main

当時の結果は次のようなものでした。

1
2
3


name version main
---- ------- ----
@ant/desktop 2.26454.2 .vite/build/index.pre.js

npxを使う場合はNode.js/npmが必要です。また、ソースはminifyされた大きなバンドルなので、何かを検索すればすぐ意味が分かるというものでもありません。

起点のindex.pre.jsから呼び出し先を追い、mainView.js、mainWindow.js、各index.chunk-*.jsを調べました。外側のウィンドウとチャット本体が別に構成され、通常のチャットはhttps://claude.aiを読み込むことが分かりました。

この時点で重要なのは、入力欄の送信処理そのものは、MSIXのネイティブ部分を改造しなくても操作できそうだったことです。

3-2. 開発者ツールで入力欄を確認

調査時にはClaudeの「ヘルプ」→「トラブルシューティング」から開発者モードを有効にし、入力欄にフォーカスした状態でCtrl+Alt+Iを押してDevToolsを開きました。

※これは開発時にDOMを調べるための操作です。公開版のインストールに開発者モードを有効化する必要はありません。初期試作と現在の導入要件を混同しないようにします。

コンソールで入力欄を見ると、次のような要素が見つかりました。

1

<div class="tiptap ProseMirror" contenteditable="true" role="textbox">...</div>

説明用に属性を抜粋しています。実際のDOMにはほかにも属性があります。

さらに、次のようなコマンドで確認できます。

1
2
3
4


const el = document.querySelector('.tiptap.ProseMirror[contenteditable="true"]');
console.log('editor:', !!el?.editor);
console.log('hardBreak:', typeof el?.editor?.commands?.setHardBreak);
console.log('view composing:', el?.editor?.view?.composing);

当時の環境ではel.editorが存在し、editor.commands.setHardBreak()を利用できました。

つまり、単にEnterというキーイベントを合成するのではなく、入力エディターの正規の改行コマンドを直接呼び出せるわけです。

3-3. 送信は内部APIよりもボタンを利用する

続いて送信処理も調べました。

Tiptap/ProseMirrorのプラグインやキーマップを見れば内部の送信コマンドも見つかるかと思いましたが、バンドルされた関数や閉じたスコープが多く、確実な呼び出し経路を特定できませんでした。

そこで無理に内部APIを追うのはやめて、Claudeが表示している送信ボタンを利用する方式にしました。

実機で確認したのは次の属性です。

1

<button data-testid="chat-input-send" aria-label="メッセージを送信">...</button>

aria-labelの日本語はローカライズで変わるかもしれませんが、data-testidは当時のDOMで識別に使える値でした。

とはいえ、画面のどこかにある送信ボタンを単純にquerySelector()して押すのは危険です。過去のメッセージ編集欄など、別の入力欄が開いている可能性があります。

現在の実装は、操作対象のエディターに対応する、表示中の送信ボタンが一意に特定できた場合だけクリックします。複数候補があったり、ボタンが無効だったりする場合は送信しません。

この「曖昧だったら送らない」は、誤送信を防ぐツールとして重要な判断でした。

4. キー操作の実装

ここからは現在の実装を見ていきます。主要部分はextension/keys.js

にあります。

4-1. `keydown`をキャプチャ段階で処理する

拡張機能はwindowにkeydownのリスナーを登録し、capture: trueで受け取ります。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// extension/keys.jsの構造を抜粋
const controller = new AbortController();
const options = { capture: true, signal: controller.signal };
const selector = '.tiptap.ProseMirror[contenteditable="true"]';

window.addEventListener('keydown', e => {
 const el = e.target instanceof Element ? e.target.closest(selector) : null;
 if (!el || e.key !== 'Enter') return;

 // ここでIME状態・キー設定・候補メニューを判定する
}, options);

キャプチャ段階で判定することで、Claude本来のEnter送信処理よりも前に介入できます。

なお、キーが入力欄以外にある場合は基本的に何もしません。ダイアログ操作や別のUIにまで干渉するためのツールではないからです。

4-2. IMEの変換中はブラウザー本来の確定操作を残す

特に重要なのが次の判定です。

1
2
3
4
5


// extension/keys.jsより要点を抜粋
if (state.composing || e.isComposing || e.keyCode === 229 || editor?.view?.composing) {
 e.stopImmediatePropagation();
 return;
}

判定には複数の情報を使っています。

判定	役割
`compositionstart` / `compositionend`	入力欄単位でIMEの合成状態を追跡
`event.isComposing`	キーイベント自身が持つ合成中フラグ
`keyCode === 229`	IME処理を示すことがある互換情報
`editor.view.composing`	Tiptap/ProseMirror側の変換状態

変換中はClaude側の送信ハンドラーへの伝播を止めますが、preventDefault()は呼びません。IME自身による候補確定はそのまま動かしたいからです。

加えて、compositionend直後の100ms以内に届いたEnterは抑止する処理もあります。これは変換完了直後のイベントで意図せず改行・送信しないようにするための安全側の対策です。

100msという値があらゆる日本語IMEで最適だと証明したわけではありません。あくまで今回の実装における保護策であり、IMEやバージョンの組み合わせによって追加検証の余地はあります。

4-3. 改行はTiptap、送信は対応するボタン

IME以外の通常のキー入力であれば、設定に応じて処理を分岐します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// 実装から処理の要点を再構成した例
if (action === 'newline') {
 editor.commands.setHardBreak();
} else if (action === 'send') {
 const button = sendButtonFor(el);
 if (!button || button.disabled || button.getAttribute('aria-disabled') === 'true') {
 return;
 }
 button.click();
}

改行にsetHardBreak()を使うため、Webエディターの内部状態を無視したDOM直書きや、合成Enterキーの投げ直しをしなくて済みます。

送信は送信ボタンに任せるので、Claudeの内部送信関数の名前や引数を推測する必要がありません。ただし、今後DOM構造や送信ボタンの識別子が変われば動作しなくなる可能性はあります。

4-4. `/`コマンドの候補選択を壊さない

試作中にもう1つ問題が出ました。

スラッシュコマンドやメンションの候補一覧を出しているときは、Enterが「選択する」という操作に使われます。何も考えずにすべてのEnterを改行にすると、候補を選べません。

公開版では、この点を修正しました。TiptapのSuggestion系プラグインの状態と、実際に表示されているメニューを両方確認し、候補が開いているときの通常EnterはClaudeへ渡すようにしています。

1
2
3
4
5


// extension/keys.js より
const active = editor.state.plugins.some(
 p => /suggestion|mention/i.test(p.key) &&
 p.getState(editor.state)?.active === true
);

実際のコードではこの判定に加えて、[role="menu"],[role="listbox"]の表示状態も確認しています。

このような細部は、最初にEnterを改行にできた時点では見落としがちです。「想定したキーだけ動く」と「普段の文章入力を邪魔せず使える」は、なかなか別物でした。

5. 一時パッチを毎回実行するわけにもいかない

ここまでの挙動は、当初DevToolsのConsoleへJavaScriptを入力する一時的な方法で検証しました。

しかし、ページを読み込み直したら消えてしまいます。毎回コンソールへ貼り付けて使うのでは、さすがに本末転倒です。

そこで、Claude Desktopに通常起動時からWebExtensionを読み込ませる方法を探しました。

5-1. 使わなかった方式

Electronなら何でもできそうですが、今回のClaudeでは使えない、あるいは使いたくない方法がありました。

方法	採用しなかった理由
`app.asar`の直接改造	MSIXの署名・整合性や今後の更新を考えると避けたい。公式アプリを改変したくない
`--remote-debugging-port`等を使う起動	Claude側に関連引数の検査があり、通常起動を拒否する経路を解析で確認。専用ランチャーも必要になる
`NODE_OPTIONS`による起動フック	対象バイナリではElectron fuseによって関連機能が無効
Claudeメニューの「拡張機能をインストール」	MCP/DXT系の仕組みであり、任意のChrome content scriptを読み込む入口とは確認できなかった

重要なのは、Electron一般の機能とこのClaude Desktopで実際に使える機能を混同しないことです。

5-2. `REACT_PROFILE=1`という読み込み経路を発見

app.asar内のJavaScriptを調べていたところ、React DevToolsに関するコードを見つけました。

当時の対象ビルドでは、起動時に次の環境変数を確認しています。

1

REACT_PROFILE=1

この値が設定されていると、メインウィンドウ生成前にloadReactDevTools()が実行され、特定の拡張フォルダーをsession.defaultSession.loadExtension()へ渡す構造でした。

1

%APPDATA%\Claude\extensions\fmkadmapgofadopljbjfkapdkoienihi\

fmkadmapgofadopljbjfkapdkoienihiはReact Developer Toolsの拡張IDとして使われる文字列です。ただし、今回の仕組みではその名前のフォルダーを読み込み先として利用しているだけで、React DevToolsそのものを入れる必要はありません。また、そのフォルダー名と実際に割り当てられるChromium内部の拡張IDが同一であると証明した、という話でもありません。

この経路のポイントは、Claudeの実行ファイルを変更しなくて済むこと。Windowsのユーザー環境変数と、ユーザーデータに置いた拡張だけで済みます。

ただし、これは非公開の実装を利用した方法です。Anthropicが将来この経路を削除・変更すれば、当然使えなくなります。

5-3. MV3拡張にする

最終的な拡張はManifest V3で、2つのcontent scriptを使います。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


{
 "manifest_version": 3,
 "content_scripts": [
 {
 "matches": ["https://claude.ai/*"],
 "js": ["keys.js"],
 "run_at": "document_start",
 "world": "MAIN",
 "all_frames": false
 },
 {
 "matches": ["https://claude.ai/*"],
 "js": ["settings-ui.js"],
 "run_at": "document_start",
 "all_frames": false
 }
 ],
 "permissions": ["storage"]
}

※拡張全体のname、version、descriptionなどは省略しています。完全な定義はextension/manifest.json

を参照してください。

keys.jsはWebページのJavaScriptと同じMAIN worldで動き、TiptapのエディターAPIを呼びます。一方settings-ui.jsは通常の拡張用の実行環境で動き、chrome.storage.localを使って設定を保存します。

両者の設定は、ページルートの属性data-claude-enter-settingsとカスタムイベントclaude-enter-settings-changedで受け渡します。保存済みの設定を読み込むまで、未知の送信キーで誤って送信しないようにするガードもあります。

実装はdocument_startから開始します。試作版のdocument_idleでは起動直後に元のEnter処理が動く余地があったため、公開版で早期読み込みに変更しました。

6. 設定UIもClaudeの画面に置く

キーの割り当てを変えるたびにスクリプトを修正するのは面倒なので、設定UIも作りました。

最初はClaudeの「ファイル」「編集」のようなネイティブメニューへ項目を追加したかったのですが、今回使うWebExtension側から素直に操作できるものではありません。

そこで、左サイドバーのプロフィール欄の上に「⌨ キー設定」を追加しています。

右下へ固定のバッジを表示する試作もありましたが、モデル選択などと重なって邪魔だったので撤去しました。やっぱり、自分用のツールでも普段の画面を邪魔するのは嫌です。

設定画面では次のことができます。

送信・改行キーの変更
有効／無効の切り替え
初期値への復帰
保存済み設定の読み込み、再起動後の復元
想定外の画面構造や送信ボタンの判定失敗を知らせる状態表示

設定画面はShadow DOMを使っており、Claude本体のCSSと衝突しにくいようにしています。また、送信と改行に同じキーを設定しないよう検査しています。

設定UIの実装

zawa356/claude-desktop-webext

を見ると、サイドバーのdata-testid="user-menu-button"などを手掛かりに挿入位置を確認しています。この部分も当然Claudeの画面構造に依存するため、変更されれば追従が必要です。

7. 実機検証とテストの範囲

開発時点では、主にWindowsのClaude Desktopで次を確認しています。

検証項目	結果
IME変換中の確定Enter	変換確定を維持、誤送信なし
全角記号・句読点を含む日本語入力	実機で基本動作を確認
Enterによる改行	動作確認
Ctrl+Enterによる送信	動作確認
別チャットへの移動	設定したキー操作を維持
サイドバーからのキー変更／有効・無効	動作確認
完全終了・通常起動後の設定保持	動作確認
`/`コマンド等の候補選択	初期の問題を修正し、公開版で対応
Linux Desktop	自動試験のみで、実機検証なし

また、Node.js上の模擬環境でキーイベント処理をテストし、Playwrightを使って設定UIの表示や保存の振る舞いも確認しています。公開用インストーラーはPowerShellのテストも整備しました。

ただし、模擬テストが通ったことと、すべてのIME・すべてのClaudeバージョンで正常に動くことは別です。テスト対象外の画面や複数ウィンドウなどでは、想定外の挙動が残る可能性があります。

8. もう1つツールを作ったら、読み込み先が競合した

ここまででCtrl+Enter自体は実用になりました。

ところが、その後にChatとCoworkの分離UIを戻す拡張も開発しました。

そのツールも、同じREACT_PROFILE経由でClaude DesktopにChrome拡張を読み込ませたい。つまり、1つしかないReact DevTools用の拡張枠を取り合うことになります。

せっかく作ったのに、一方をインストールするともう一方が消えるのは困ります。

8-1. 共通ローダーを作る

そこで、別プロジェクトとしてclaude-desktop-webext

lugia19/Claude-WebExtension-Launcher

を作りました。

各ツールは普通のMV3拡張フォルダーをそれぞれ保持し、共通ローダーが1つのManifestにまとめてClaude Desktopへ読ませる構造です。

1
2
3
4
5
6
7
8


claude-ctrl-enter（キー操作） ──┐
 ├─> claude-desktop-webext
claude-split-ui（分離UI） ─────┘ │
 ▼
 1つの生成MV3 manifest
 │
 ▼
 Claude DesktopのReact DevTools読み込み枠

Windowsでの保存先は次のとおりです。

1
2
3
4
5


%LOCALAPPDATA%\ClaudeDesktopWebExt\web-extensions\claude-ctrl-enter\
%LOCALAPPDATA%\ClaudeDesktopWebExt\web-extensions\claude-split-ui\

%APPDATA%\Claude\extensions\fmkadmapgofadopljbjfkapdkoienihi\
 ↑ ローダーが生成する読み込み先

Ctrl+Enterはorder: 50、先に起動時の通信をフックするSplit UIはorder: 10にしています。

ローダーは導入・更新・解除と、バックアップ・ロールバックを担当します。複数拡張のマニフェストや権限を安全に統合できる範囲だけ対応しており、Chrome拡張なら何でも使えるわけではありません。

似た目的でClaude-WebExtension-Launcher

というプロジェクトもありましたが、あちらは改変したClaudeを使う方式です。こちらは公式のMSIX版Claudeをそのまま使うことを優先しました。

8-2. 既存の設定を引き継げるか

Ctrl+Enter 0.4.0から共通ローダーへ移行しています（2026年10月9日の0.4.1は主にドキュメントとローダーのリリース版への更新です）。

WindowsのClaude 2.31226では、旧0.3.0の環境から更新し、保存していたキー設定が残ることを確認しました。さらにSplit UIを同時導入した状態で、分離UI、サイドバーのキー設定、Enter改行、Ctrl+Enter送信がすべて動作しています。

これで普段使いのClaudeに必要な2つの不満を、同時に解消できました。

9. AIを使って開発した感想

今回、コードの実装やテスト、調査メモの整理にはChatGPTなどのAIをかなり使いました。

特に印象的だったのは、一度で正解の実装が出てくるわけではないことです。

AutoHotkeyのIME状態判定では、イベントが取得できているというだけでは十分ではありません。IDLE_INFERREDを「確定している状態」と扱ってしまえば、一番避けたい誤送信につながります。

Electronの調査でも、最初に検索したバンドルで拡張読み込み経路が見つからなかったからといって、存在しないわけではありませんでした。別のchunkまで調べることでloadReactDevTools()が見つかっています。

AIが候補を出し、スクリプトを組み、検証項目を増やす。その結果を実機で確かめて、ダメなら原因を戻って調べる。この繰り返しです。

Ctrl+Enter自体は小さな機能ですが、入力中のIMEを壊さず、誤送信せず、Claude更新時にも戻せるようにするには、意外と検討することがありました。

10. 注意点と今後

本ツールはClaude Desktop内部の非公開の読み込み経路と、Web画面のDOM・エディターAPIに依存しています。

Anthropic公式の機能ではなく、将来の互換性は保証できません。
Claudeの更新でREACT_PROFILEの読み込み経路が使えなくなる可能性があります。
data-testidやTiptapのAPIが変更されればキー操作が動かなくなる可能性があります。
REACT_PROFILEはユーザー環境変数なので、他の開発環境と競合する場合があります。
本物のReact DevToolsや未知の拡張が既存の読み込み先にある場合、インストーラーは上書きせず停止する設計です。
Linux版は配布していますが実機未検証、macOSは未対応です。
未送信のメッセージがある場合は、導入・解除後の再起動前に保存してください。インストーラーはClaudeを強制終了しません。

万一動かなくなった場合に備えて、uninstall.batとdiagnose.batを用意しています。最新状況や既知の制約はGitHub

で確認してください。

まとめ

「ClaudeでもCtrl+Enterで送信したい」。それだけのつもりで始めたのに、AutoHotkeyでIMEイベントを追い、ElectronのASARを調べ、React DevToolsの読み込み経路を見つけ、WebExtensionを作り、最後は複数拡張を共存させる共通ローダーまで作ることになりました。

なかなか遠回りした気もしますが、いまは日本語変換も、普通のEnter改行も、Ctrl+Enter送信も違和感なく使えています。

便利な追加機能というより、マイナスだった使い勝手をゼロに戻すためのツールですね。

とはいえ、毎日使う入力欄に余計なストレスがなくなるのは、やっぱり大事だと思います。

ClaudeのChatとCoworkが統合されて不便なので、分離UIを復活させてみた

Fri, 09 Oct 2026 21:06:57 +0900

ClaudeのChatとCoworkが統合されて不便なので、分離UIを復活させてみた【Firefox・Chrome・Desktop／2026年10月】

この記事はChatGPTなどの生成AIを利用して執筆しています。調査・実装にもAIを利用していますが、実際の画面操作や動作検証は手元の環境で行い、確認できた範囲を区別して記載しています。

2026年10月9日時点の記録です。 Anthropic非公式の実験であり、Claudeのアップデートで動作しなくなる可能性があります。

ClaudeのChatとCowork、いつの間にか統合されましたね。

これ、個人的には結構困っていました。普通に質問したいだけなのにCowork側で作業が始まったり、意図していないファイル整理に話が進んだり。単に文章で回答してくれればいいのに、作業環境を立ち上げて調査を始められると、時間も使用量も余計にかかります。スマートフォンからも作業を継続できるのは便利ですが、必要ないときまでそういうセッションを作ってほしいわけではありません。

ChatはChat、CoworkはCowork。使うかどうかは自分で決めたい。

ということで、統合前の切り替えUIを戻せないか調べていたら、Feature Flagを1つ変更するだけで、分離表示に戻せることが分かりました。拍子抜けするほど簡単でした。……発見した時点では。

その後、Firefoxでの検証からChrome対応、Claude Desktopへの組み込み、別の自作拡張との共存までやったので、今回はその記録です。

まず使い方をまとめ、後半で通信解析・実装方法・実機検証について詳しく書きます。とりあえず動かしたいだけの方は前半だけで十分です。

最初に結論

作成したのは Claude Split UI という非公式の拡張機能です。

統合されていたChat / Coworkの切り替えを、確認済みの環境で分離表示へ戻す
Firefox・ChromeのWeb版、およびWindows版Claude Desktopで基本動作を確認
既存のClaudeアカウントやサブスクリプションはそのまま使用
Claude本体の実行ファイルやapp.asarを書き換えず、無効化・解除できる
Claude Desktopでは別に作成したCtrl+Enter送信ツール

zawa356/claude_ctrl-enter

GitHub Repository

github.com

とも共存可能

GitHub： zawa356/claude-split-ui

ダウンロード： 最新のReleases

日本語README： 導入手順と対応状況

MozillaのNetwork Overrides解説

これは画面の切り替え方を戻すツールです。権限のない機能を有効化するものでも、以前のCoworkのバックエンドや実行環境を完全に復活させるものでもありません。そこは最初に明確にしておきます。

確認した環境

対象	2026年10月9日時点の確認結果
Firefox 157.0.1	一時拡張の導入で分離、削除して再読込すると統合表示に復帰
Chrome	WXT版拡張の手動導入・無効化による分離／復帰を確認
Claude Desktop / Windows 11	Microsoft Store（MSIX）版 `2.31226.0.0` で分離／復帰を確認
Claude Desktop / Linux	配布・CI上の検査はあるが、実機動作は未確認
macOS	今回のDesktop用配布の対象外

すべてのアカウントや将来のバージョンで動くという意味ではありません。

導入方法

Firefoxの場合

Releases

zawa356/claude-split-ui

GitHub Repository

github.com

からclaude-split-ui-<バージョン>-firefox.zipを取得して展開します。
アドレスバーにabout:debugging#/runtime/this-firefoxと入力します。
「一時的なアドオンを読み込む」から、展開したフォルダー内のmanifest.jsonを選択します。
Claude Web

Claude Web

claude.ai

claude.ai

を再読み込みします。

うまくいけば、ChatとCoworkの切り替えが表示されます。

注意： 現在のFirefox版は一時インストールによる開発者向けの配布です。Firefoxを再起動すると一時アドオンは解除されます。AMOで署名された正式なアドオンではありません。

解除するときはabout:debuggingから一時アドオンを削除し、Claudeのページを再読み込みしてください。

Chromeの場合

Releases

zawa356/claude-split-ui

GitHub Repository

github.com

からclaude-split-ui-<バージョン>-chrome.zipを取得し、展開します。
chrome://extensions/を開き、デベロッパーモードを有効にします。
「パッケージ化されていない拡張機能を読み込む」で、manifest.jsonがあるフォルダーを選択します。
Claude Webを再読み込みします。

元に戻す場合は拡張を無効化または削除して再読み込みします。Chrome Web Storeでの配布ではありません。

Claude Desktop（Windows）の場合

Releases

zawa356/claude-split-ui

GitHub Repository

github.com

からclaude-split-ui-<バージョン>-desktop.zipを取得して展開します。
中のinstall.batを実行します。管理者権限は不要です。
Claudeをタスクトレイから完全に終了させ、通常のアイコンから起動し直します。
入力欄の「＋」付近にChat / Coworkの切り替えが出るか確認します。

uninstall.batで解除できます。解除後もClaudeを完全終了・再起動してください。診断はdiagnose.bat、読み込み枠の再生成はrepair.batです。

導入スクリプトの詳細や最新の制約はREADMEを優先してください。特に以前のバージョンから更新する場合は、古い解除スクリプトではなく新しい配布物を使用します。

そもそも、なぜ戻したかったのか

今回の不満は「新しい画面が気に入らない」という見た目だけの話ではありません。

自分の使い方だと、普通のChatは技術的な質問や調べ物、文章の相談をする場所。一方Coworkは、ファイルを扱わせたりPC上で作業させたりする必要があるときに、明示的に利用したい機能です。

この2つが統合されると、ちょっとした質問でもCowork的な作業に移行することがありました。場合によっては頼んでいないファイル整理の話まで進んでしまい、「いや、そこまでしなくていいんだけど……」という状態になります。

Cowork自体が嫌いなわけではありません。実際、必要なときには便利です。ただ、使い分けるための境界がほしい。

それに、たまたま別のClaude Teamアカウントで確認したところ、そちらには従来の分離UIが残っていました。

同じClaudeなのに、アカウントによって画面が違う。だったら旧UIのコードが完全に削除されたわけではなく、機能フラグで表示を切り替えている可能性があるのでは？

ここから調査が始まります。

1. まずFirefoxで通信を調べる

ElectronのDesktopアプリを最初から改造するよりも、Web版をブラウザーの開発者ツールで調べた方が楽です。ということで、Firefoxから始めました。

Firefoxの開発者ツールに慣れていたわけではないので、このあたりはChatGPTに調査を手伝ってもらいながら進めています。

1-1. Network Monitorで起動時の通信を取得

再現したい場合は、次のような手順です。

統合UIになっているアカウントでhttps://claude.ai/newを開きます。
F12で開発者ツールを開き、「ネットワーク」タブへ移動します。
必要に応じてキャッシュを無効化し、通信ログをクリアしてページを再読み込みします。
app_startという文字列を含むリクエストを探します。
レスポンスのJSONと、ページHTMLの起動時スクリプトを確認します。

実際の検証では、次のような同一オリジンのAPIが呼ばれていました。

1
2
3
4


GET https://claude.ai/edge-api/bootstrap/<organization-uuid>/app_start
 ?statsig_hashing_algorithm=djb2
 &growthbook_format=sdk
 &...

ここでの<organization-uuid>は説明用の伏せ字です。実際のアカウントのIDを公開する必要はありません。また、URLに付くパラメーターは将来変更される可能性があります。

最初はHARも取得して内容をAIと一緒に分析しました。ただし、HARにはCookie、認証ヘッダー、各種IDなどが含まれる可能性があります。そのまま公開したり、Issueへ貼ったりするのは避けてください。AIへ渡す場合も、サービスや利用環境の取り扱い条件を確認し、必要な範囲に絞るべきです。

1-2. GrowthBookのFeature Flagを見つける

起動時のJSONを調べると、GrowthBook形式のFeature定義の中に、数値のキー1174351393が見つかりました。

実データから対象部分だけを抜き出して簡略化すると、構造は次のようなものです。これは説明用のサンプルであり、実際のレスポンス全文ではありません。

1
2
3
4
5
6
7
8


{
 "1174351393": {
 "defaultValue": true,
 "rules": [
 { "force": true }
 ]
 }
}

一見すると、defaultValueだけfalseにすればよさそうです。ただし、rulesにはforceという値があります。デフォルトを変更しても、適用中のルールによって別の値が選ばれる可能性があります。

そこでdefaultValueだけでなく、Boolean型のrules[].forceも変更して挙動を見ることにしました。

1-3. Network Overrideで本当に切り替わるか試す

FirefoxのNetwork Monitorには、サーバーのレスポンスをローカルファイルに差し替えるNetwork Overrideがあります。Firefox 137以降で使える機能です。

調査時には次の流れで試しました。

Network Monitorで対象のapp_startリクエストを右クリックします。
Set Network Overrideを選び、レスポンス内容をローカルファイルへ保存します。
そのファイルの対象Featureだけを編集します。
defaultValueとrules[].forceをfalseにして保存します。
ページを再読み込みしてUIを確認します。

Firefoxの操作自体はMozillaのNetwork Overrides解説

firefox-source-docs.mozilla.org

にも記載があります。Overrideはタブ単位で、開発者ツールを閉じれば永続化されません。

対象部分は次の状態にします。

1
2
3
4
5
6
7
8


{
 "1174351393": {
 "defaultValue": false,
 "rules": [
 { "force": false }
 ]
 }
}

もちろん実際は、レスポンス全体を保ったまま対象部分だけ書き換えます。サンプルJSONだけをレスポンスとして返してもClaudeは起動できません。

すると、分離されていた頃のChat / Cowork切り替えが表示されました。

えっ、これだけ？

と思いましたが、偶然の表示崩れではないかを確認する必要があります。

1-4. A/B/A/Bで検証する

同じアカウント・同じブラウザーで値を切り替え、結果を記録しました。

試行	`defaultValue`	`rules[].force`	画面
A：変更前	`true`	`true`	統合UI
B：両方変更	`false`	`false`	分離UI
A相当：ルールを戻す	`false`	`true`	統合UI
B：再度変更	`false`	`false`	分離UI

この結果から、少なくとも当時のアカウントとビルドでは、対象Featureのルール設定がUI切り替えに効いていると判断できます。

ちなみにclassic_mode_availableやshowCoworkTabといった、それらしい名前の値もありました。しかし、それらが今回の表示を決める要因だと立証できたわけではありません。成功した変更はあくまで1174351393のFeature定義に限定しています。

Coworkを選ぶと/cowork/へ移動し、Cowork用の画面やタスク一覧が表示されました。簡単なMarkdownファイル作成も実行できました。ただし、この結果だけで「統合前のCowork実行基盤まで完全に戻った」とは言えません。確認できたのは主にUIの分離です。

2. 一時的な差し替えからWebExtensionへ

Network Overrideでは、開発者ツールを開いてファイルを管理し続ける必要があります。毎回使うものとしてはさすがに面倒です。

そこで、レスポンスをブラウザー内で動的に加工するWebExtensionを作りました。

2-1. なぜ`document_start`なのか

最初に引っかかったのが、差し込むタイミングです。

HTMLを調べると、Claudeはアプリ本体の大きなJavaScriptが起動する前に、インラインスクリプトからbootstrapの取得を始めていました。

概念的には次の構造です。

1
2
3
4
5
6


// Claudeの動作を説明するための擬似コード（原文の転載ではありません）
window.__BOOTSTRAP_PRELOAD__ = {
 promise: fetch('/edge-api/bootstrap/.../app_start', {
 credentials: 'include'
 })
};

DOMContentLoadedを待ってからfetchをフックしても、もう遅い。そこでManifest V3のcontent scriptを、document_startかつMAIN worldで実行します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// apps/browser-extension/entrypoints/claude.content.ts より
export default defineContentScript({
 matches: ['https://claude.ai/*'],
 runAt: 'document_start',
 world: 'MAIN',
 allFrames: false,
 main() {
 installFetchHook(window);
 }
});

普通の拡張機能のcontent scriptは、WebページとJavaScriptの実行環境が分離されています。今回はページ本体が呼ぶwindow.fetchを置き換える必要があるため、同じ実行環境となるMAINを使用しています。

2-2. 何でも書き換えない

ここでやりたかったのは、Claudeの通信を横取りすることではありません。最新の正規レスポンスから、目的のFeatureだけをその場で変更することです。

現在の実装は、おおむね次の手順で動きます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


Claudeのページがfetch()を呼ぶ
 ├─ app_start以外 → 元のfetchをそのまま実行
 └─ 同一オリジンのapp_start
 ↓
 正規のレスポンスを取得
 ↓
 JSONをコピーしてFeature 1174351393を探す
 ├─ 形式が違う／対象なし／取得失敗 → 元のレスポンスを返す
 └─ 対象あり
 ↓
 defaultValue=false
 Boolean型のrules[].force=false
 ↓
 変更したJSONをResponseとして返す

実装の核はpackages/core/src/index.mjs

zawa356/claude-desktop-webext

です。

たとえばFeatureの変更部分は、実際には次のような処理になっています（要点を抜粋）。

1
2
3
4
5
6
7
8
9


const copy = structuredClone(root);
visitDefinitions(copy, definition => {
 definition.defaultValue = false;
 for (const rule of definition.rules) {
 if (rule && typeof rule.force === 'boolean' && rule.force !== false) {
 rule.force = false;
 }
 }
});

visitDefinitions側でも対象キーとデータ型を検査しています。変更対象でない通信・項目はそのまま通し、想定外のJSONなら加工しません。取得した認証情報やレスポンス全文を保存・外部送信する機能も設けていません。

余談ですが、Network Override用に取得した実際のbootstrap JSONを、拡張機能の中へ固定データとして同梱するのは避けています。ユーザーや時点によって異なる設定を巻き込むうえ、認証情報が混ざる危険もあるからです。

2-3. FirefoxからChromeへ

最初にFirefox用のManifest V3によるPoCを作り、拡張を入れる→分離する→外す→統合に戻るというA/B/Aを確認しました。Network Overrideを解除した状態で試験しているので、前段の差し替えが残っていたわけではありません。

その後、WXTを使ってFirefoxとChromeのビルドを共通化。変換処理はpackages/coreに切り出し、ブラウザーごとの拡張から同じ処理を呼び出す形にしました。

単体テストや模擬ブラウザーでの確認に加えて、Firefox・Chromeの両方で実際に拡張を読み込み、分離表示と解除後の復帰を確認しています。

なお、CIが通ったからといってClaude Webとの組み合わせが保証されるわけではありません。この点は実機試験と区別しています。

3. Desktop版にも適用する

さて、ここまで来るとDesktop版でも使いたくなります。

実は、この少し前に別の不満からClaude DesktopのEnterキー動作を変更するツールを開発していました。その過程で、Claude Desktop内部にあるReact DevTools用の拡張読み込み経路を見つけていたのです。

ここが今回のDesktop対応に効きました。

3-1. Web版のClaudeがそのまま載っている

Windows版Claude DesktopはElectron製です。app.asarをコピーして読み取り専用で解析したところ、通常のチャット画面ではhttps://claude.aiを表示する構成が確認できました。

したがって、Claude Desktopのメインプロセスを改造するより、実際のWeb画面へChrome用のcontent scriptを読み込ませる方が変更範囲を小さくできます。

3-2. `REACT_PROFILE=1`とReact DevToolsの読み込み枠

対象ビルドには、起動時にREACT_PROFILE環境変数を確認し、1ならloadReactDevTools()を実行する分岐がありました。

さらに、所定の拡張フォルダーが存在すると、Electronのsession.defaultSession.loadExtension()で読み込む実装になっています。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


ユーザー環境変数 REACT_PROFILE=1
 ↓
Claude Desktopの起動処理
 ↓
React DevTools用の拡張フォルダーを確認
 ↓
%APPDATA%\Claude\extensions\fmkadmapgofadopljbjfkapdkoienihi
 ↓
Electron session.defaultSession.loadExtension()
 ↓
claude.ai のWebContentsへcontent scriptを適用

これはClaudeの非公開の開発用読み込み経路を利用したもので、公式の「任意のChrome拡張機能をインストールする機能」ではありません。React DevToolsのIDは読み込み先のフォルダー名として利用していますが、React DevToolsそのものを同梱しているわけではありません。

また、REACT_PROFILEはユーザー環境変数です。他の用途と競合する場合があるため、既存設定や本物のReact DevToolsがある環境では、インストーラーが勝手に上書きしないようにしています。

3-3. Windows実機でA/B/Aを確認

Windows 11、Claude Desktop 2.31226.0.0（Electron 44.4.3）で検証しました。

状態	結果
元の状態（Ctrl+Enter拡張のみ）	統合UI
Split UIのcontent scriptを追加	分離UI
元の構成に戻す	統合UI

差し替え時には、フックの内部カウンターでintercepted: 1、patched: 1、modifiedRules: 1も確認しています。Ctrl+Enter側の動作は維持されていました。

これでWebとDesktopの両方で、同じ基本処理を利用できると確認できました。

4. ところが、拡張を2つ入れられない

ここで別の問題が発覚します。

ClaudeのReact DevTools用の読み込み先は、実質的に1つの拡張フォルダーです。つまりSplit UIとCtrl+Enterがそれぞれ好き勝手に同じ場所へ書き込むと、後から入れたツールが前のツールを上書きしてしまいます。

かといってClaudeの実行ファイルやapp.asarを書き換える方式にはしたくありません。Microsoft Store版のMSIXは署名や配置の都合もあり、公式アプリを改造して別物を常用するのは避けたかったのです。

そこで作ったのが、3つ目のリポジトリである**claude-desktop-webext

lugia19/Claude-WebExtension-Launcher

**です。

4-1. 共通ローダーの仕組み

各ツールは、自分の拡張だけを個別のフォルダーで保持します。ローダーはそれらのmanifest.jsonを検査し、content_scriptsや必要な権限をまとめた1つの生成マニフェストを作成します。

1
2
3
4
5
6
7
8
9


%LOCALAPPDATA%\ClaudeDesktopWebExt\web-extensions\
 ├─ claude-split-ui\ ← 個別のMV3拡張
 └─ claude-ctrl-enter\ ← 個別のMV3拡張
 ↓ 検証・統合（順序制御）
%APPDATA%\Claude\extensions\fmkadmapgofadopljbjfkapdkoienihi\
 ├─ manifest.json ← ローダーが生成
 └─ ext\... ← 各拡張のスクリプト
 ↓
 Claude Desktop

Split UIは起動直後のfetchを先回りしてフックしなければならないため、実行順を10、Ctrl+Enterを50に設定しています。

スロットのバックアップ、導入・解除時の状態管理、失敗時のロールバックもローダー側で行います。ツール同士が相手のファイルを直接触らずに済むのが大きいところです。

すでに似た目的でClaude-WebExtension-Launcher