セキュリティの分野で活動していると、一度は「BadUSB」というデバイスに魅力を感じるのではないでしょうか。USBメモリのような見た目でありながら、PCに接続するとキーボードとして認識され、事前にプログラムされたキー入力（ペイロード）を自動実行してくれるツールです。特に海外製の安価で高機能なデバイスは、サイバーセキュリティの学習やレッドチーム演習において非常に強力な武器となります。
しかし、我々日本のユーザーがこれらの海外製BadUSBデバイスを使う際には、大きな落とし穴があります。それは「キーボード配列の違い」です。
問題の核心：US配列 vs JIS配列
多くの海外製BadUSBデバイスは、米国の標準的なUS（英語）配列を前提に設計されています。デバイスは「どの物理キーを押したか」というHIDスキャンコード（USB HID Keyboard/Keypad 0x07 の使用コード）をPCへ送りますが、実際にどの文字になるかはOSのキーボードレイアウト設定（日本語／英語 など）が解釈します。
そのため、BadUSBが US配列のつもりで送った操作が、JIS配列に設定されたWindowsやmacOS上では別の文字として入力されることがあります。たとえば代表的な混乱例としては、@ と "、[ と @、\ と ¥、; と :、- と = などです（IMEの状態やOSごとの配列差で結果が変わる場合もあります）。
PowerShellで Invoke-WebRequest のURLを入力したり、コマンドオプションで : や \ を使う場面では、このズレが致命的になり、ペイロードが意図どおり動作しません。
なぜこの問題が起きるのか？
BadUSBは「文字」そのものではなく、**物理キーの位置情報（スキャンコード）**をエミュレートして送信します。OSは受け取ったスキャンコードを、現在アクティブなキーボードレイアウトに従って文字へ変換します。
つまり、US配列前提で作ったペイロードは、JIS配列環境では別の文字に変換されやすい、という構造的な問題です。
対策
対策1：OSのキーボード設定を一時的に変更する
もっとも確実で汎用的です。ペイロード実行前にターゲットOSのキーボードレイアウトを一時的に「英語（米国）」へ切り替え、完了後に日本語へ戻します。
Windows（PowerShell）の例：
# 英語配列に変更
Set-WinUserLanguageList -LanguageList en-US -Force
# ……ペイロード本体……
# 日本語配列に戻す
Set-WinUserLanguageList -LanguageList ja-JP -Force対策2：ペイロードをJIS配列用に調整する
もう一つは、JIS配列で目的の文字になるようスキャンコードの出し方（記号の書き方）を手で調整する方法です。
例として @ を打ちたい場合、US配列での「[ キー相当」を送るとJIS環境で @ になる、といった位置ベースの置き換えで回避できることがあります。
ただし、これはOS・IME状態で挙動が変わるため、短い・単純なペイロード以外ではメンテが大変で、ヒューマンエラーも出やすいです。必ず事前に「サニティチェック用ペイロード」（A–Z, 0–9, 問題になりやすい記号列）で実機検証しましょう。
対策3：JIS配列に対応したデバイス／エンコーダを選ぶ
一部のデバイスや自作BadUSB（Arduino/Pro Micro 等）では、送信するスキャンコードや言語ファイルを切り替える機能があり、JIS配列に合わせた送出が可能です。
例えば、新型のRubber Duckyではエンコーダ側で言語（キーボードレイアウト）を指定できます。Flipper Zero でもレイアウトJSONを差し替える方法が知られています。価格や手間は増えますが、運用ストレスは大幅に減少します。
まとめ
海外製のBadUSBデバイスは非常に魅力的ですが、JIS配列キーボード環境で利用する際は配列差の罠に必ず直面します。
この問題を事前に理解し、エンコーダでレイアウトを指定したり、言語ファイル（ライブラリ）を導入したり、ペイロード冒頭でOSのキーボードレイアウトを切り替えるなどの対策を講じることで、初めてその真価を発揮させられます。
自分はウキウキで USB Nova を手に入れてこの問題にはまりました。
新しいデバイスを手に入れて「動かない！」と慌てる前に、このキーボード配列の罠を思い出してください。