俵のメモ帳

メモ帳です。このブログに書き残すコードはパブリックドメインとして扱います。

【ChatGPT】GPT-5.1時代のオレオレ小技

こんにちは。 みなさん、ChatGPTに依存していますか？私は公私ともに依存しています。

僕はChatGPTは4oあたりから本格的に使っていたのですが、GPT-5になって思考能力が格段に上がりましたよね。 だけど、GPT-5では以下のような文章表現が目立ち、ちょっと読みづらかったり鼻につくところがありました。

  • 箇条書きを多用しすぎ
  • 専門用語を当たり前のように使ってくる (言葉づかいがハイコンテキスト)
  • 「目の付けどころが鋭いです」みたいな無条件迎合あいづち

そして2025年11月、GPT-5.1がリリースされ、上記の不満は一気に解消されたように思います。日頃使っている方なら似た感覚を持っているのではと思いますが、「とにかく読みやすくなった。色々聞きやすくなった」と、そう感じているのではと思います。

不思議なもので、話している内容の深さはGPT-5と大差ないけれど、GPT-5.1の言葉の伝え方のおかげでさらに深堀りしたくなったり、色々な切り口で話を聞いてみたくなったりしたと思えるのです。これは、日頃の他者への自身の話し方をも振り返る、面白い機会になったなと感じています。

出力のカスタマイズを全域へ

さて、そんなお気に入りのGPT-5.1版のChatGPTですが、ほとんど非の打ち所がないものの、ちょっとした出力のカスタマイズがしたい点もあります。

私は、全体的にちょっぴり読みやすくなるように以下のような指示を少々加えています:

**生成AIへの出力スタイル要求:**
- 論理的で自然に読み取れる情報の流れを組み立てる。根拠やデータ、結論はそのままに読みやすさを高める。
- 日本語文章中では英語の単語・熟語はカタカナ表記で書くことを優先 (例: 「Churn Rate」ではなく「チャーンレート」と記載 / 「Outcome」ではなく「アウトカム」と記載)
- 英略語に注釈を入れる場合、略語の展開と日本語訳を併記する (例: 『NPS (Net Promoter Score：正味推奨者比率)』)

ただ、通常は上記のような指示はパーソナライズ設定の「カスタム指示」に書き加えておけばいいのですが、「プロジェクト機能」と組み合わせると少し困ることがあります。 それは、プロジェクト内で指定した個別カスタム指示によって、パーソナライズ設定のカスタム指示が打ち消されてしまうというもの。 標準的にすべてのやりとりに反映したいカスタム指示の場合、プロジェクト機能によって無効化されてしまうことがあるので、ちょっと困ります。

そこで、上記のように簡易的かつプロジェクト機能にも反映されてほしいような回答全域にかかる指示は、 「あなたについての詳細」 に書いてしまいましょう。

「あなたについての詳細」設定

これで、全プロジェクトに反映されるようになりました。

Perplexity、生成AIモデル選択で「Max」プランでしか使えないモデルを非表示にする小技

PC便利ワザ

皆さん、 Perplexity 、使ってますか？

僕は $20/month のProプランを使っているのですが、Perplexityにはこれより上の強いプラン、「Max」プランがあるんですよね。で、Pro -> Max へのアップセルを目的として生成AIモデル選択にMaxプランでしか使えないモデルもリストされてしまうんです。Maxに加入する気がないユーザーからすると、これがちょっと鬱陶しい。

ということで、Stylusで非表示にしてしまおうというライフハックです。

反映するCSSは以下です。

/* maxでしか使えないモデルを非表示 */
div[role="menuitem"]:has(div.bg-max) {
    display: none;
}

上記を適用することで、

これが:

こうなります:

Windows 10/11に標準搭載となった「Noto Sans JP」をブラウザで徹底活用する

PC便利ワザ

こんにちはー。
Windows 10/11に「Noto Sans JP」フォントがアップデートで降ってきて、標準搭載される状況となって数ヶ月が経ちました。

参考: Windows 10/11に「Noto」フォントが標準搭載へ ～日中韓のWebブラウジングが改善 - 窓の杜

Webブラウジングでの活用が期待されているようですが、今まで何年もメイリオで戦ってきた日本語環境Windows界隈ですから、移行もかなり緩やかに行われるのではないでしょうか。

そうなると気になるのは、MSゴシック、メイリオ、Noto Sans JPと、覇権を争うかのようにページによって表示が異なる状況になるのではないかという懸念です。これは困る (個人の感想です)。

ということで、ユーザーのブラウザ表示上でだけCSSが変更できるChrome拡張機能、 Stylus を使って、これらのフォント表示を統一してしまおうと思います。

以下の設定をすべてのサイトで有効になるように追加します:

@font-face {
  font-family: "メイリオ";
  src: local("Noto Sans JP");
}
@font-face {
  font-family: "\\30E1\30A4\30EA\30AA";
  src: local("Noto Sans JP");
}
@font-face {
  font-family: "Meiryo";
  src: local("Noto Sans JP");
}
@font-face {
  font-family: "Meiryo UI";
  src: local("Noto Sans JP");
}
@font-face {
  font-family: "MS Pゴシック";
  src: local("Noto Sans JP");
}
@font-face {
  font-family: "MS PGothic";
  src: local("Noto Sans JP");
}
@font-face {
  font-family: "MS ゴシック";
  src: local("Noto Sans JP");
}
@font-face {
  font-family: "MS Gothic";
  src: local("Noto Sans JP");
}
@font-face {
  font-family: "MS UI Gothic";
  src: local("Noto Sans JP");
}

これで、ほぼ全てのWebサイトの日本語文字がNoto Sans JPになりました。めでたしめでたし。

日本語文字がNoto Sans JPに

ブラウザ「Vivaldi」で、Ctrl+Tabが利かないサイトが気になったときの対処

非推奨 PC便利ワザ 不具合調査・対応
Vivaldi ver 7.2 で、ショートカットキーの優先度設定ができるようになったため、こちらに記載する対策はアプリケーション自前で行えるようになりました。よって、本記事の対策は非推奨としました。

Vivaldi、なんかCtrl+Tabが利かない瞬間がある…？

ブラウザの Vivaldi を愛用していると時々遭遇する問題。それが「Ctrl+Tabでタブ切り替えできなくなるWebサイトがある問題」です。

例えば、最近見つけたところだと 寿司打 (2024-10-20 時点) のページで発生します。

原因

「Webサイト側のJavaScriptにて、ショートカットキーで使われているのと同じキーでのkeydownイベントにより event.preventDefault() が呼び出されると、対象ショートカットキーの動作がキャンセルされる」というVivaldiの仕様に起因するようです。

これは、2018年に報告されている keydown イベントのキャンセルでタブとウィンドウの操作を無効化できてしまう | Vivaldi Forum でも触れられています。これだけ昔からこの動作ということは、Vivaldiとしては不具合ではなく適切な仕様という扱いなのでしょうね。

つまりVivaldiでのCtrl+Tabキーが動作しなくなる問題は、JavaScriptでTabキーの押下イベント時に event.preventDefault() を実行し、デフォルト動作をキャンセルしているWebサイトで起こり得ます。

Tabキー動作無効化をWebサイト側で実装する背景としては、何らかの理由でTabキーによる要素のフォーカス移動を抑制したいケースが考えられます。例えば前述の寿司打のようなブラウザゲームの場合、プレイ中にTabキーによるフォーカス移動が発動すると困るでしょうから、そういった理由からTabキー押下イベントを意図的に無効化するのも分かります。

さて、上記を踏まえると、以下のようなHTMLで、Ctrl+Tabが動作しなくなることを再現できます。

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Document</title>
  <script>
    // Tabキーを押した際のイベントをキャンセルする
    window.addEventListener('keydown', function(e) {
      if (e.key === 'Tab') {
        const div = document.createElement('div');
        div.textContent = 'Tab key pressed';
        document.getElementById('pressed').appendChild(div);
        // デフォルトの動作をキャンセル
        e.preventDefault();
      }
    });
  </script>
</head>
<body>
  <div id="pressed"></div>
</body>
</html>

回避策

前述の通り、 event.preventDefault() がWebサイト側で実行されなければ良さそうだと当たりがつきました。なおかつ、「Ctrl+Tabキー、Ctrl+Shift+Tabキーでは event.preventDefault() が発動しないようにして、Tabキー単体やShift+TabではWebサイト側の実装のまま」といった状況にできればよさそうです。ということで、Chrome拡張 Tempermonkey を利用して、これを実現していきます。

Tempermonkeyを利用すると、任意のJavaScriptを適当なサイトで実行することができるので、これを利用してVivaldiのショートカットキーがちゃんと動くようにキー押下イベントを調整します。

(1) TempermonkeyでUserScriptを新規作成

Tempermonkey UserScript新規作成

(2) UserScriptエディターに、以下のJavaScriptを貼り付ける

// ==UserScript==
// @name         fix vivaldi shortcut events
// @namespace    http://tampermonkey.net/
// @version      2025-02-25
// @description  VivaldiのショートカットキーがWebサイトのJavaScriptによってキャンセルされないようにする
// @match        *://*/*
// @grant        none
// ==/UserScript==

(function () {
    'use strict';

    function stopEvent(e) {
        if (e.ctrlKey) {
            if (e.key == "Tab"
                || e.key == "PageUp"
                || e.key == "PageDown"
            ) {
                e.stopImmediatePropagation();
            }
        }
    }

    window.addEventListener('keydown', stopEvent, true);

    document.addEventListener('keydown', stopEvent, true);

    // document.addEventListener の指定だけで十分かも？以下コメントアウトして様子見する
    // document.querySelectorAll('textarea, input').forEach(function (e) {
    //     e.addEventListener('keydown', stopEvent, true);
    // });
})();

(3) Ctrl+Tabの操作がうまくいかないWebサイトで、動作するようになったかを確認する

まとめ

こういったVivaldiの動作そのものは、Webサイト側で定義したキーイベントを阻害しないようにと意識をした仕様と思われますが、Ctrl+Tabのようなブラウザの挙動を最優先したいケースにおいては困りますね…。

地味に不便だったので、回避策が見出だせたのは幸いでした。

【2024/10/18 発売】REALFORCEシリーズ初の70%レイアウト、REALFORCE RC1 (45g) をレビュー

ガジェット

REALFORCEシリーズ初の70%レイアウト、REALFORCE RC1 (45g) を買ってみた

2024/10/18 新発売、「REALFORCEシリーズ初の70%レイアウト」ということで各メディアで取り上げられ、気になっている方も多かったであろう REALFORCE RC1 を勢いで買ってしまいました。財布からの悲鳴は聞き流しつつ、レビューしたいと思います。

REALFORCE RC1

レビュー機スペック

REALFORCE RC1 (型番: C1HK11 / 45g / 英語配列)

詳細は 製品 : REALFORCE / C1HK11 | REALFORCE | 日本製プレミアムキーボードの最高峰 を参照。

評価要約

⭕️GOOD
  • 圧倒的、打鍵感の良さ！
  • 静音キースイッチ採用で「コト、コト、コト…」と静かな打鍵音
  • サイズが小さく、ホームポジションからあまり離れず全てのキーに指が届く
  • 約600gと軽量でBluetoothも最大4台まで設定可。史上初のモバイルREALFORCE
  • 全キー、カスタム可能。設定のオンボード保存ができ、いつでもどこでもカスタムしたREALFORCEを堪能できる
❌️BAD
  • 下から2段目 ("Z" の列) のキー位置が一般的なキーボードより 1/4 キー分、異なっている
  • 右Shiftキーが小さくて違和感あり
  • リチウムイオンバッテリーなので、キーよりもバッテリー寿命の方が先に来そう

GOOD: 打鍵感、打鍵音◎ 静音モデルのHHKBに似た感触

打鍵感、打鍵音がとにかく良い！ REALFORCEを買う最大のモチベーションと言えば、やっぱりここではないでしょうか。

REALFORCEでは、 セブン銀行ATMのテンキーでもお馴染み の「静電容量無接点方式」のキースイッチが用いられ、押した際の指へのフィードバック感が高いのが特徴です。当機種では、この中でもタイピング音が響かない静音タイプが採用されています。「コト、コト、コト」と心地の良い打鍵音を味わうことができます。

当機種では、押下圧が30gと45gから選択することができます。私は押した感触がしっかりと指に伝わってくる45gが好みなので、こちらを購入しました。 「静電容量無接点方式 + 静音タイプ + 押下圧45g + 本体重量500～600g」というと、ちょうど HHKB Professional HYBRID Type-S と同じスペック。 従来のREALFORCEは、本体内に鉄板を組み込んで安定性を確保していましたが、当機種では軽量化のために別の仕組みで安定性を確保したとのことで、HHKBと近しい筐体になっているのではないでしょうか。スペックが似ているのも相まって、打ち心地は非常に似た感触です。

GOOD: REALFORCE史上初、70%サイズのコンパクトレイアウト

私は65%レイアウトのキーボードを好んで使っているのですが、その主な理由は、ホームポジションから各キーへの指の届きやすさです。大抵、このサイズのコンパクトキーボードでは、Home/Endキーなどはファンクションキーとの組み合わせで入力する方式になっており、「ファンクションキー + どこかのキー」という組み合わせで様々なキーが発動します。複数キーを押さなければいけない手間はあるものの、指の移動距離はグッと短くなります。

当機種においても、「Fn + 左矢印 = Home」など、ファンクションキー + 特定キー の組み合わせで様々なキーが動作するようになっています。また、これらのキーの組み合わせは専用ソフト (後述) でカスタマイズが可能です。

参考までに、私は以下のカスタマイズをしました。

  • 左Ctrl/CapsLockキーの入れ替え
  • Esc/` (バッククォート) キーの入れ替え
  • 右CtrlをFnキーに変更

特に「右CtrlをFnキーに変更」は、Fnキー + 矢印キーで動作する Home/End, PageUp/PageDown を右手だけで入力することができるようになって便利なので、おすすめです。

GOOD: 全てのキーがカスタマイズ可能。設定はオンボード保存ができる

専用ソフト REALFORCE CONNECT で、全てのキーをカスタマイズできます。

この手の専用ソフトでのカスタマイズの罠として、「専用ソフトがインストールされている環境でないとカスタマイズが反映されない」「ファンクションキーなど、一部キーは書き換えできない」といったことがありがちです。 しかし当機種ではいずれもクリアしており、フルカスタムしたモバイルREALFORCEを、いつでもどこでも利用することができます。

REALFORCE CONNECT

GOOD: Bluetooth接続が安定している

最近、 QMK/VIA に対応するマイナーな中国メーカーのBluetoothキーボードをいくつか試していたのですが、流石に製品開発の地力の違いが出るのか、Bluetooth接続の安定感に違いを感じます。今のところ、入力遅延は感じません。

BAD: コンパクトにするために犠牲になった一部レイアウト

打ち心地が最高、そして小さく、軽く、フルカスタム可能な当機種ですが、欠点もあります。それは、 コンパクトにするために一部のレイアウトが犠牲になっていることです。

テンキーや独立したHome/Endキーが無い、などの当然なものはさておいて、下から2段目のキーに注目してください。一般的なキーボードと比べると、1/4 キー分、配置位置が異なっています。

入力してみて、私にとっては全然気になりませんでしたが、人によっては気になるところかもしれません。

(2024/10/19 追記) 実は HHKB HYBRID Type-S の日本語配列も同じく 1/4 キー分、ずれているようです。あのHHKBが昔から採用している実績アリということで、そこまで奇抜な配列ではなさそうで安心しました (HHKB自体が割と奇抜ですが…)。

REALFORCE RC1 一部レイアウトにクセあり

その他、いろいろ

Bluetooth接続・切断の動作

Bluetooth接続のキーボードは、省電力仕様ですぐに切断されたり、再接続時のワンテンポの遅れが煩わしい瞬間があったりと、いくつか悩ましい点があります。そして、このあたりの動作具合は説明書や仕様に記載されないので、買ってみないと分からないんですよね。

当機種においては、接続中は30分間切断されることがないため (時間調整可。下図参照)、再接続時のラグに煩わされることはほぼありません。PCをシャットダウンするなどして切断したら、1分でキーボード電源が切れる点も無駄がなくて良いですね。

省電力機能

切断後は本体右側面にある電源ボタンから起動し、スムーズに再接続されます。電源オン時に再接続する対象は直前の履歴が反映されるため、使用頻度が高い接続先にすぐに接続できるようになっています。電源オン後の再接続の感度も良く、2, 3秒ほどで接続されます。

電源オン時の接続動作

タイピングスピードへの影響

タイピングスピードを測るため、 寿司打 で遊んでみました。

よく使っている赤軸メカニカルキーのキーボードで平均キータイプ数 6.5回/秒 前後になることが多いので、あまりスピードに違いはなさそうです。前述のとおり、一部レイアウトにクセがありますが、私にとってはハンデになることはあまり無さそうです。

寿司打

なぜか、Windows 11のスタートでの検索結果画面でNoto Sans JPフォントが適用される

不具合調査・対応

検索結果表示、Noto Sans JPになってる…？

少し前に、以下のようなスタートの検索で入力できない問題があって検索画面を注視していたところ、不思議な現象を発見しました。

tawara-memo.hatenablog.com

確認環境:

  • Windows 11 23H2 (ビルド 22631.4317)

Noto Sans JP をインストールしていると、スタートの検索結果画面の表示が当該フォントになってしまっていました (キャプチャは後述)。

この検索結果表示、裏でEdgeのエンジンが使われているのではないかと想像しており、もしその通りだとすれば、Chrome/Edge ver 128で適用された以下の影響を受けていそうだと睨んでいます。

なお、Noto Sans JPをアンインストールすると、いつもの表示 (メイリオ？) に戻りました。

表示比較

Noto Sans JPインストール済み状態での検索結果画面:

Noto Sans JPインストール済み状態での検索結果画面

Noto Sans JPアンインストール後の検索結果画面:

Noto Sans JPアンインストール後の検索結果画面

「Yu Gothic UI」フォントの鍵括弧、繋げるとブラウザ表示で重なる問題を調べてみた

不具合調査・対応

Yu Gothic UIに text-spacing-trim を適用するとバグる を読んでいて、気になってしまったので、実際にYu Gothic UIのファイルの中身を開いて調べてみました。

発生している問題

Yu Gothic UIは、Windows 10からプリインストールされているUI表示用フォントです。

手元の環境で確認したところ、Windows 11 23H2 (ビルド 22631.4317) 時点では、「Yu Gothic UI Version 1.93」がインストールされていました。

このフォントをChrome系ブラウザで利用すると、鍵括弧表示が崩れる場合があります。具体的には、 「abc」「abc」 のように、閉じ括弧・開き括弧が隣接するケースです。 」「 の部分ですね。この際に、閉じ括弧と開き括弧の表示が重なってしまいます。

閉じと開きの鍵括弧が重なる

最近ではWindows版Teamsクライアントでも同様の表示になっており、なんだかなぁって思っています。

回避策

Yu Gothic UIが使われているWebサイトでこのような問題が起きて困っている方は、 Stylus で text-spacing-trim: space-all; を指定すると良いです。※Stylusの使い方は割愛

Teamsクライアントのように内部的にWebアプリを利用しているタイプのツールでは、残念ながら回避策がありません…。

原因

HTMLを書いたことのある方はご存知かと思いますが、ブラウザで表示する場合にはデフォルトでいくつかのCSSが適用されます。例えば <h1>見出し</h1> などと書くと、文字サイズが大きいスタイルが適用される、とかですね。

このデフォルトCSSの内、 text-spacing-trim プロパティの挙動とYu Gothic UIの相性の悪さによって前述の問題が起きるようです。

text-spacing-trim - MDN によると、このプロパティは中国語/日本語/韓国語 (CJK) における文章識別の改善を目的としたものだそうです。挙動としては、 「」（）【】、。 など、約物といわれる記号類の表示位置、表示幅をいい感じに調整することで見やすくする、といったものです。

ブラウザデフォルト値として normal が設定されるようですが、このデフォルト値の時点で表示位置・幅が変わるようですね。 normal では、 」「 のように連なった場合の2文字目 (この場合は 「) の表示位置・幅を変化させる、といった挙動になります。

ここで text-spacing-trim: normal; の時、どのように文字幅が変わるのか詳しく見てみましょう。

下図は、Yu Gothic UIの元になっている「游ゴシック」を使い、 text-spacing-trim のプロパティ値を変えて表示の比較をしたものです。括弧の部分に背景色のCSSを適用し、幅がどのように扱われているかを可視化しています。隣接している 「 や （ の幅が狭くなっているのが見て取れます。

text-spacing-trim 表示比較

ちなみに前述のページによると、 text-spacing-trim はChromeでバージョン123から対応、Firefoxでは現在未対応のようです (2024/10/12 時点。同時点でChromeの最新バージョンは129)。割と導入されてから新しいプロパティであり、かつ前述の通りデフォルト値 normal でも表示が変わることから、多くのWebサイトで意図せず約物の表示具合が変わってしまう可能性があるのではないでしょうか。

Yu Gothic UI 特有の問題？

CJK punctuation kerning: the CSS text-spacing-trim property - Chrome Platform Status によると、text-spacing-trim プロパティは、フォント内に設定されている「halt」という設定によって表示位置や表示幅が変わるようです。

Yu Gothic UIの設定値を Fontforge で覗いてみると、確かに「halt」の設定がされていることが分かります。

Yu Gothic UIにはhaltが設定されている

このhalt情報によって、約物が隣接したときの text-spacing-trim での表示位置・表示幅の調整量が決められるとのこと。問題は、Yu Gothic UIにおいて、halt情報での調整量が鍵括弧の表示幅「1024」と同じ大きさになってしまっているところにありそうです。

上記のhalt情報だと、「元が1024幅の文字に対して、表示位置を左に1024ずらし、表示幅も1024減らす」という調整になるので、 「 は下図のような調整になります。

haltによる表示位置、表示幅の変更

上図のような調整がされるために、本来の表示幅がゼロになり、かつ表示位置もゼロ位置より左側に突き出してしまい、左側の文字 (閉じ鍵括弧) に右側の文字 (開き鍵括弧) が重なってしまっていると思われます。

text-spacing-trim: normal; が適用されたYu Gothic UIの鍵括弧

まとめ

Yu Gothic UI、元になっている游ゴシックから鍵括弧の幅が変更されて半角の1024になっていますが、これが悪影響を及ぼしているように思います。そもそも「halt」というのは「全角の記号を半角表示にしようとした際の調整情報」であるので、今回の鍵括弧のように既に半角幅のグリフでは不要なはずなのですが、制作で半角化した際に見落としてしまったのでしょう…。

Yu Gothic UIの鍵括弧記号のhalt情報を削除するか、鍵括弧記号を全角にするか、そのあたりの対処をすれば解消するとは思いますが、OS標準フォントということで、もしかしたら、そう簡単に差し替えられない事情などあるのかもしれません。

でも、text-spacing-trim のブラウザデフォルト値の挙動も微妙な気がしますね。Webサイト制作者が意図せず文字の表示幅が変わる (部分的に halt が適用状態になる) のって、どうなんだろうなー。

(2024-10-16 追記) Chromeのフォーラム経由でMicrosoftには伝わっているようです。
[text-spacing-trim] Glyph collides if the font is "Yu Gothic UI"

(2024-11-02 追記) 上記フォーラムの10月24日のMicrosoftメンバーのコメントによると、フォントメーカーによる修正は終わった模様。あとはWindows Updateに載せるタイミングの調整段階に入っているようです。