メカニカルキーのチャタリングを改善するには

マウスではチャタリングに遭遇することは何度もあり、その時々でマウスの寿命だなあと感じるものですが、キーボードでも発生するとはぜんぜん意識していませんでした

気が付けば半年前くらいからやたらとミスタイプが増えていることが気になり、我ながらとうとう加齢が原因かあ?などとも思ったりしたわけなのですがw

ためしに常時繋がっている有線のキーボードではなく、無線接続のキーボードを使っているときにはそんなことが全くない。と、いうことは、ひょっとして有線接続のキーボードになにか原因があるのでは?と疑いはじめたわけです。

・チャタチングは特定のキー?

疑惑のキーボードはLogicoolのメカニカルキーボード G512です(シリーズの詳細名は忘れた)

はじめてのメカニカルキーなので、まずは程度の良いものを安く中古で仕入れ気に入って使っていたわけなのですが、そういえばメカニカルですものね接点が

耐久性はある程度考慮されているはずですが、原理的にメカニカルな接点があるわけなので使えば使うほど消耗します。これは当然のお話です。

ただ、チャタリングが発生しはじめたからといってすべてのキーが不調というわけはありません。使用頻度の高いものから消耗が激しくなります

使用者の入力のクセも出るでしょうけれど、私の場合には母音に相当するキーがわりと弱っている気がする。

買い換えも考えたのだけれどなかなか気持ちをくすぐられるようなキーボードが見当たらないので修理なりなんなりの対策を考えることに。

・どこに対策する?

対策と言ってもキースイッチの交換からソフト処理までいろいろあるとは思うけれど、まず120~130個あるキースイッチのうちどれが不調なのかはまず調べておかないと効率が悪い。

どうしたものかとCopilotさんに相談したら、さくさくっとタスクバーに常駐するチャタリング記録のコードを書いてくれた。ほぼそのまま動くから恐ろしい。

※調べてみたらチャタリングキャンセラーの「ccchattttter」とほぼ同じ機能のものを作ってくれていたらしい。素直にそっちを使えばよかった。

2週間ほどチャタリングのログを取ってみると「O」とか「:」とか「B」とか「→」といったキーで顕著に発生していることが浮き彫りに。

ここで手始めにソフト対策として、ccchattttterに入れ替えてみることにした。

しかし・・・たしかに若干は落ち着いたものの処理しきれないチャタが出てくる。バネが弱ってキーアップするときに微妙に跳ねてしまっているような雰囲気もある。

キーキャップを取り外したキースイッチ部分

・キースイッチの交換は

ソフト処理では成果が上がり切らないので手を加えることを検討に入るとして、最近の高級なキーボードになるとキースイッチそのものを基板から引き抜いて交換できるようになっているのだとか。

だけれど、私のG512はそんな器用な造りではなく基板にスイッチがはんだ付けされているタイプ。はんだを外すのって案外めんどくさいのでできれば避けたい。

スイッチそのものの交換は最終手段として、その前になにか試せることはないかなと考えているとあるものが目に留まりました。

・KURE5-56シリーズ登場

はい、接点復活剤です。

KUREのシリーズは実は多彩なラインアップがあって、最もメジャーな潤滑用の「5-56」のほか、電気製品に使っても大丈夫な「コンタクトスプレー」、ば鍵穴(キーシリンダー)に使っても大丈夫な「ドライファストルブ」なんてのもあります。

※電子機器にも優しいものもあるらしいです

KURE CRCシリーズ

基本的に精密機器に潤滑油の5-56なんて使おうものなら後が大変なことになりますが、コンタクトスプレーをわずかに使うくらいであれば良いかな?と安直に。

作業そのものは手慣れたもので、キートップを垂直にもぎ取り、むき出しになったメカニカルなキースイッチの接点がありそうな側に照準をあわせてわずかに「シュッ」

それでも周囲には飛び散りますから細めの綿棒やティッシュ&つまようじですぐに拭き取りましょう。いっぱいかけてしまうと余計に壊すことになりかねないので注意!

吹きかけたら、あとはひたすらスイッチを押しては離し、押しては離しの繰り返し。100往復くらいが目安。

・チャタリングが直った!

正直いって、その程度で改善できたら安上がりで良いなーという程度だったのですが、意外にもこれがちゃんと効果がありました

動作の怪しかったキー5つほどに対策をしてみたわけなのですが、それ以降チャタリングのログにも載らないようになりましたし、実際に調子よく入力できている。

キャンセラーを立ち上げていなくてもミスタイプが激減していることからも効果を実感できているわけで、これは即効性があって良い対策。

分解してしまう前に少しでも効果があればラッキーだなと思ってたのがけっこうなヒットでした


安心安全安価なSDカードデータ復元・HDDデータ復元は
長年の信頼と実績の『株式会社パソコントラブル救助隊』へ。
https://hqsecure.net/

xrdpとmacOSの組み合わせでキーボード判定

xrdpの環境にmacOS端末でログインすると結構な確率でキーボード判定がおかしくなりませんか?

macOSでRDPするにはMicrosoft謹製のwindows.appを使うわけなのですが、どうもxrdpに送られてくるキーボードレイアウトの情報がおかしい、というか無いに等しい。

これがWindows機ならばある程度の種類を送ってきてくれるので、それに適したレイアウトで操作できるわけなのですが、Windows.appから送られてくる情報は常に0x00000000。

キーマップは0x00000411.tomlをコピーして0x00000000.tomlを作ってしまうことで誤魔化しは効くものの、どういうわけかusキー・日本語キーの判定は接続するたびに違っていたりで、少なくとも私の個人持ちのMacBookではUSキー判定されたり日本語キー判定されたり。

接続自体はスムーズなのに、いざ「@」や「¥」を入力しようとすると違うレイアウトになっていることに気づいて接続し直す羽目になるのがどうも憂鬱。

・というわけでもう作っちゃえ

というわけで、GUIで設定変更できるツールをさくさくっと。

ついでに接続してきた端末名や解像度と設定内容を記録しておいて、自動実行でも設定できるように。

[ keyboard-switcher.sh ]

#!/bin/bash

# --- 実行モード判定 ---
AUTO_MODE=false

if [[ "$1" == "--auto" ]]; then
    AUTO_MODE=true
fi

# --- 設定保存先・識別情報取得 ---
CONFIG_DIR="$HOME/.config/keyboard_layouts"
AUTOSTART_DIR="$HOME/.config/autostart"
AUTOSTART_FILE="$AUTOSTART_DIR/keyboard-switcher.desktop"

mkdir -p "$CONFIG_DIR"
mkdir -p "$AUTOSTART_DIR"

resolution=$(xdpyinfo | grep dimensions | awk '{print $2}')
hostname=$(xprop -root | grep Xdpy | cut -d\" -f2 | cut -d@ -f2)

[[ -z "$resolution" ]] && resolution="unknown_resolution"
[[ -z "$hostname" ]] && hostname="unknown_host"

safe_id=$(echo "${hostname}_${resolution}" | tr -cs '[:alnum:]_-' '_')
CONFIG_FILE="$CONFIG_DIR/${safe_id}.conf"

# --- 現在のキーボードレイアウトを取得 ---
current_layout=$(setxkbmap -query | grep layout | awk '{print $2}')

# --- 自動モード: GUIなしで適用する ---
if $AUTO_MODE; then
    if [[ -f "$CONFIG_FILE" ]]; then
        saved_layout=$(cat "$CONFIG_FILE")
        if [[ "$saved_layout" == "us" || "$saved_layout" == "jp" ]]; then
            setxkbmap "$saved_layout"
            echo "[INFO] 自動実行: '${saved_layout}' を適用しました (${safe_id})"
            exit 0
        fi
    fi
    echo "[INFO] 自動実行: 設定が見つからなかったため変更なし"
    exit 0
fi

# --- 手動実行: GUIで選択 ---
us_selected=FALSE
jp_selected=FALSE

if [[ -f "$CONFIG_FILE" ]]; then
    saved_layout=$(cat "$CONFIG_FILE")
    if [[ "$saved_layout" == "us" ]]; then
        us_selected=TRUE
    elif [[ "$saved_layout" == "jp" ]]; then
        jp_selected=TRUE
    fi
else
    if [[ "$current_layout" == "jp" ]]; then
        jp_selected=TRUE
    else
        us_selected=TRUE
    fi
fi

layout=$(zenity --list \
    --title="キーボードレイアウトの選択" \
    --text="使用するキーボードレイアウトを選んでください\n(端末: ${hostname}, 解像度: ${resolution})" \
    --radiolist \
    --column="選択" --column="レイアウト" \
    $us_selected "us (英語)" \
    $jp_selected "jp (日本語)" \
    FALSE "削除(設定をリセット)")

# --- ユーザーが削除を選択した場合 ---
if [[ "$layout" == "削除(設定をリセット)" ]]; then
    zenity --question --title="設定削除" --text="自動実行設定とキーボード設定を削除しますか?"
    if [[ $? -eq 0 ]]; then
        rm -f "$AUTOSTART_FILE"
        rm -rf "$CONFIG_DIR"
        zenity --info --text="削除が完了しました。"
        echo "[INFO] 削除が完了しました。"
    else
        echo "[INFO] 削除をキャンセルしました。"
    fi
    exit 0
fi

# --- キーボードレイアウトの適用 ---
if [[ "$layout" == "us (英語)" ]]; then
    setxkbmap us
    echo "us" > "$CONFIG_FILE"
elif [[ "$layout" == "jp (日本語)" ]]; then
    setxkbmap jp
    echo "jp" > "$CONFIG_FILE"
else
    zenity --info --text="レイアウトが選択されませんでした。"
    exit 1
fi

# --- 自動起動用のデスクトップエントリーを作成 ---
cat <<EOF > "$AUTOSTART_FILE"
[Desktop Entry]
Type=Application
Exec=$HOME/path/to/keyboard-switcher.sh --auto
Hidden=false
NoDisplay=false
X-GNOME-Autostart-enabled=true
EOF

zenity --info --text="設定内容を保存し自動実行を設定しました (${AUTOSTART_FILE})"
echo "[INFO] 設定内容を保存し自動実行を設定しました (${AUTOSTART_FILE})"

と、こんな感じで。

配置はどこでも良いけれど、実行するためには chmod +x keyboard-switcher.sh を忘れずに。

・こまかいところ

仕様的には

・自動実行時+保存情報あり:保存された情報で設定して静かに終了
・自動実行時+保存情報なし:なにもせず静かに終了
・手動実行時+保存情報あり:GUIを開き保存された情報を表示
・手動実行時+保存情報なし:GUIを開く

と言う感じで、保存情報は

~/.config/keyboard_layouts/ 以下に「ホスト名_解像度.conf」の設定ファイルを作って記憶。

ただ、実際に動かしてみるとhost名が取得できなくて unknown_host_1440x900_.confみたいな形になってしまいましたが、実用上支障なしということで。

書き忘れるところだった。
自動実行時というのをどう判定するねん、という点は –auto というオプションを付けることで判断します。

・せっかく作ったならメニューへ

せっかくGUIなツールなのに起動がいちいちCLIではもったいないので、デスクトップエントリーに以下のように追加。

[ /usr/share/applications/keyboard-switcher.desktop ]

[Desktop Entry]
Name=キーボードレイアウト切替
Exec=/usr/local/bin/keyboard-switcher.sh ←ここは環境にあわせてフルpathを!
Type=Application
Terminal=false
Icon=input-keyboard
Categories=Settings;Utility;

これでちょっと楽ができるかな?


安心安全安価なSDカードデータ復元・HDDデータ復元は
長年の信頼と実績の『株式会社パソコントラブル救助隊』へ。
https://hqsecure.net/

MacBookAir(M4)買っちゃった

なにやらニュースサイトを見ていると目に留まったのがAppleの新製品の記事。

どうやら数時間前にMacbookAir(M4)が発表されたらしく、読んだ勢いで発注してました。

13インチMacBookAir(M4)

■発売は3月12日

正確にはまだ予約受付の段階なんですが、昨年のM3バージョンからお値段据置きらしいので深く考えることなくぽちっと。

一応わたし、現役の大学生でもあるわけなので割引を最大限に受けちゃいます。

Apple Store 教育割引 – 学生・教職員価格 – 教育 – Apple(日本)

平時でもAppleの学割ストアはお得価格なんですが、さらにこの新学期の時期というのはさらに22,000円分のギフトカードも付いてきます

Appleギフトで22,000円・・・うーん、AirPodsの足しになるかな。

支払いも「ペイディあと払いプランApple専用」というものが利用でき、金利0%の36回払いという負担の軽さ(通常だと24回払いになりますよね)

そのほかにもAppleCare+が20%オフとか特典が豊富なんで、学生の方は使わないとむしろ損だと思う。

Apple学生ストア

■学生の身分確認

さすがにAppleStoreは上手に作られていて、予約注文の導線から必要なカスタマイズを済ませて素直に先へ先へと進むだけで、学生であることの確認と支払い方法(分割含め)へと迷うことなく進むようになっています。

学生であることの確認は、自分のメールアドレス(学校のドメインのもの)での確認か、または学生証での確認という形になります。

学生と確認されれば次は支払い方法の選択。これもクレジットカード決済などの選択肢のほか「金利0%36回分割」を選ぶと画面上にQRコードが表示され、ペイディアプリのインストールと登録という流れになります。

本人確認は運転免許証かマイナンバーカード、そしてよくある顔の確認です。ちょっと認証操作中は他人に見られたくないですよねあれ。

本人確認と支払い審査はわたしの場合は数分ほどで結果が返ってきました。平日なら25時くらいまでなら迅速に対応してくれる様子です。

■長年愛用の12インチMacBookは

さて、久々の新機種購入でちょっとテンション上がってしまいましたがここらで落ち着きましょう。

今現在のわたしの愛機はMakBook(12inch)の2017年モデルだから、もう7~8年は使ってますね。

1kgを切る軽量薄型ボディと大容量のバッテリーが特徴のとても持ち歩きやすくて気に入ってたんですが、、、12インチはその後ディスコンになり今に至るまで後継機は存在せず。

ときどきタッチパッドが反応しなくなったりバッテリーも修理推奨と表示されているなど、かなりガタガタになってしまっているわけですが、購入前に懸念した「USBがType-C 1ポートだけでしかも充電もそこから!」という劣化が激しそうなポイントは、実はぜんぜん問題なかったという、、、現実に使ってみないとわからないものですね。

重たい作業をしなければ今でも普通に使えちゃうんですが。

とにかくこれで、長いあいだ見て見ぬふりをしていた今どきの話題にもようやくついていくことができる環境が整いそうです。


安心安全安価なSDカードデータ復元・HDDデータ復元は
長年の信頼と実績の『株式会社パソコントラブル救助隊』へ。
https://hqsecure.net/

LINE Notifyの代替手段を考える

LINE Notifyが2025年3月31日に終了してしまうということなので代替え手段を考えないといけなくなってしまいました。

無料で使えるし手軽で便利だったのになあ。

■案内されている手段は?

サービス終了に伴ってLINEから代替え提案されているのがMessaging APIを使う手段。

これは月間200通までは無料だけれど、それ以上になると月額5,000円〜という有料サービスになりますね。200通あれば用途を限定さえすれば事足りるような気もしますが、有料も視野にいれないといけないのであれば他の手段とも比較しておきたくなります。

■とりあえずMessaging APIは

LINE公式アイコン

ひとまず提案されている通り、第一の選択肢と考えることになります。
もちろんLINE公式アカウントを持っているというのが前提になります。

必要最小限の手順としては、

・アクセストークンを取得
・通知するユーザーIDを取得
POST送信

自分が管理しているアカウント宛てであれば、アクセストークンユーザーIDもコンソール画面上で確認できるのでかなり手軽に実験できますね。
あとはcurlで直接たたいても良いですし、pythonで書いたとしたら以下の通り。

import requests

# LINE Messaging APIの設定
LINE_CHANNEL_ACCESS_TOKEN = "チャネルアクセストークン"
USER_ID = "LINEユーザーID"  # 自分のLINEユーザーID
MSG_SEND_LIMIT = 200        #送信上限数
MSG_SEND_WARN  = 150        #警告開始数
MSG_SEND_COUNT = 0

def send_message(user_id, message_text):
    # 送信数確認API
    url = 'https://api.line.me/v2/bot/message/quota/consumption'
    headers = {
        'Authorization': f'Bearer {LINE_CHANNEL_ACCESS_TOKEN}'
    }
    response = requests.get(url, headers=headers)
    if response.status_code == 200:
        data = response.json()
        MSG_SEND_COUNT = int(data['totalUsage'])
        print(f"Total message usage: {data['totalUsage']}")
        # 個別送信pushAPI
        if MSG_SEND_COUNT < MSG_SEND_LIMIT:
            url = "https://api.line.me/v2/bot/message/push"
            headers = {
                "Content-Type": "application/json",
                "Authorization": f"Bearer {LINE_CHANNEL_ACCESS_TOKEN}"
            }
            payload = {
                "to": user_id,
                "messages": [{"type": "text", "text": message_text}]
            }
            if MSG_SEND_COUNT >= MSG_SEND_WARN:
                payload["messages"].append({"type": "text", "text": f"現在の送信数:{MSG_SEND_COUNT}通\n送信制限まで残り:{MSG_SEND_LIMIT-MSG_SEND_COUNT}通"})
            response = requests.post(url, headers=headers, json=payload)
            if response.status_code == 200:
                print("通知送信成功!")
            else:
                print(f"エラー発生: {response.status_code}, {response.text}")
        else:
            print(f"送信上限に到達しました:{MSG_SEND_LIMIT}通")
    else:
        print(f"送信数確認エラー: {response.status_code} - {response.text}")

# 実行部分
if __name__ == "__main__":
    message = "これはテスト通知です!"
    send_message(USER_ID, message)

もし自分(管理者)以外のユーザーへ通知したい場合にはユーザーIDを取得する必要があるので、Webhookを準備して送信するといったひと手間がかかります。
Webhookを設定した場合、初期値では無制限にどこからでもアクセスできるようになっているので、念のためにLINE DevelopersのコンソールからIPアドレス制限を掛けておいたほうが良いでしょう。

LINE公式は受信の通知も常に受け取っているので、どちらかといえば公式から発信というよりは公式アカウントへと通知できるほうがありがたいのですけれどねぇ。

■Discordへの送信

discordアイコン

わりとユーザー層が偏りそうな気もしますが、私も最近になってようやくdiscordに触れはじめたのでこちらに通知しちゃうという手もありそうです。

流れとしては、

・通知用チャンネルを作成(既存でもOK)
・チャンネルの設定アイコンをクリック
・「連携サービス」を表示
・「ウェブフック」を選択
・「新しいウェブフック」を選択
・出来上がったウェブフックURLをコピー

と、すべてアプリ画面上で完結してしまうのでとても楽ちん。

動作テストも

・curl -H “Content-Type: application/json” -d ‘{“content”: “これはテスト通知だ!”}’ https://discord.com/api/webhooks/<WEBHOOK_ID>/<WEBHOOK_TOKEN>

とするだけで良いので簡単ですね。

ただ、こちらは逆に通知が多くて抑制しちゃっているのもあって、やはり必要な通知を見逃してしまうおそれが払拭できないかな・・・

■Teamsへのチャット送信の場合

Teamsアイコン

Microsoftにどっぷりと浸かっている方であればTeamsのアカウントあてにチャット送信するという手もありそうですね。

Teamsに慣れてるかたならWorkflow(PowerAutomate?)でさくさくっと作ってしまえるのか、あるいはGraphAPIを活用してできそうです。

手順としては、

・Azure EntraIDでアプリ登録

アプリの登録 – Microsoft Azure

※適当な名前で構わないのですがあとで修正するのは大変かもしれない


・アプリのAPI権限を設定

「アプリ名」の中から「APIのアクセス許可」を選び「+アクセス許可の追加」

「Microsoft Graph」から「委任されたアクセス許可」を選び
Chat.ReadWriteとChatMessage.Sendを追加

そして、既定のディレクトリに管理者の同意を与えることを忘れずに。
場合によっては「アプリの所有者」にも追加登録が必要かも。

・クライアントシークレットの生成

「証明書とシークレット」の中から「新しいクライアントシークレット」

説明と有効期限(メニューからは最長2年)を設定し、シークレットを生成します。生成されたシークレットのIDではなく値の側をメモしておきます。

・アクセストークンを取得

つぎはコマンド操作で、

curl -X POST -H “Content-Type: application/x-www-form-urlencoded” -d “client_id=<アプリケーションID>&scope=https://graph.microsoft.com/.default&client_secret=<クライアントシークレット>&grant_type=client_credentials” https://login.microsoftonline.com/<テナントID>/oauth2/v2.0/token

とすることでアクセストークンが返ってきますが、とても長い文字列です。

・チャットIDを取得

通知先になるチャットのIDを取得する必要もありますが、なんかこんな便利そうなページもあるのですね。

Graph Explorer | Try Microsoft Graph APIs – Microsoft Graph

アクセス権限の都合で弾かれる場合には右上のアイコン下あたりの「Consent to permissions」から必要なアクセス権をConsentしましょう。


・POST送信

前準備がいろいろと面倒ですがいよいよ通知文の送信です。

curl -X POST -H “Authorization: Bearer <アクセストークン>” -H “Content-Type: application/json” -d ‘{“body”: {“content”: “これは通知テストです!”}}’ https://graph.microsoft.com/v1.0/chats/<チャットID>/messages

ただ、Teamsは自社契約ではなく他社契約になっているので実験はできずなのですが・・・

■自前で通知アプリを作るか

自前でアプリを作る方であれば、通知を受け取るだけのアプリを作っちゃうという手もありそうです。

ただ、むかーしむかしにiOSとAndroidの両方に対応するNotificationを持ったアプリを運用していたときに思ったのですが「OSのアップデートでメンテコストがかかりすぎる!」という問題がありますよね。

いまどきならすでに解決されているのかもしれませんが、そもそもそれを回避したいのが大きな理由でLINE Notifyを導入したというのを忘れそうになっていました。

というわけでこちらは論外でしたね。

手軽さから言えばDiscord、でも日常使いのシーンから考えるとLINE Messaging APIに落ち着いてしまうのかな。


安心安全安価なSDカードデータ復元・HDDデータ復元は
長年の信頼と実績の『株式会社パソコントラブル救助隊』へ。
https://hqsecure.net/

IPv4とIPv6で速度の違いは?

数年前ならいざ知らず、いまどきもうIPv6かIPv4かなんてことは一般ユーザーは意識する必要もなくなってきているとはおもいますが。

さて、ウチの固定ネットワークのプロバイダはIPv4とIPv6を同時に使用できます(むしろ当然)

一般的にはIPv4 over IPv6となっていて快適なのでしょうけれど、どういうわけか諸事情がありウチではIPv4とIPv6が別々に流れております。

■むしろ良い?

それによってメリットが無いわけでもないのですが、こと「通信速度」だけを見た場合にはやはりIPv4では不利なことがあります。

前提として以下しつこく書きますが日常使いではまったく問題にならないのですよ。

ただ、たとえば特殊事情(固定IPアドレスが欲しいとか、特定のプロトコルを通したい場合)はIPv4をPPPoEで通しておかないといけないなんていうプロバイダ事情があるので致し方ない。

■速度差がわかりやすい

さてそんな事情は横においといて本題。

同じ接続相手先でもIPv4の場合とIPv6の場合で顕著に速度差がでる時間帯があります。個人的に調査したなかでは概ね21〜00時くらいまでの範囲。

この時間帯にWEBサイトを見てまわっていると時々遅いなーと体感することがあるんです。でもGoogleなんかのスピードテストを実行してもぜんぜん遅い数値は出ないから不思議に思っていたのです。

知識としてはPPPoEのIPv4とIPoEのIPv6だったらIPv6のほうが断然有利なのは頭に入っているものの、体感するほどの差は出ないだろうとたかを括ってました。

■サーバー設定変更に乗っかり計測

そんな折、ちょうどデータセンターに置かれている自社サーバーの設定を変更する必要が出てきたのでその作業のついでに速度差のデータも取ってしまおうという事に。

対象サーバーの契約上はIPv6/IPv4それぞれの固定IPアドレスは払い出されているものの、古い古い運用を引きずっていたためIPv6はOS側で無効化していたのですね。

実質IPv4でしか接続できない運用体制だったサーバーにIPv6の設定を追加するだけ。

そのまえにまずは計測相手となるサーバーにLibrespeedを導入(Gitから展開するだけで良いので楽ですね)。クライアントからの計測ができる体制にしました。

動作テストとしてIPv4のままで速度計測を実施。
そのあとサーバーの設定見直しをかけIPv6を使用できるように修正。

IPv6接続でも速度計測ができることを確認します。

平日01時の速度差

※混雑の済んだこの時点でも2倍近い速度差はあるっちゃああるのですが

そして、IPv4とIPv6の切り替えが簡単にできるようにして待機させ、翌日の夜の速度差が激しくなる時間帯に計測することとします。

同じクライアントから同じサーバーへと接続することになるので条件差が少なく、単純にIPv4で接続するかIPv6で接続するかの違いだけと考えることができます、よね。

■予想以上の結果に

IPv4で速度が落ち込む時間帯というのは平日21~00時とだいたい3時間くらいありますし、念のためにIPv4計測→IPv6計測→IPv4計測→IPv6計測として突発事情ではないことも確認済み。

もともとクライアント側が細い回線を使っているためか、極端に落ち込む時間帯以外はIPv4でもIPv6でもそんなに体感差はなかったのですが(たしかに倍ほどの差は数値として現れていますけれども)、測ってみるとずいぶんと大きな差になりました。

(1)速度低下が出始める21時の計測

平日21時の速度差

おもにDownloadの値で比べることになりますが、IPv6: 76Mbit/sに対し IPv4: 4.2Mbit/sとずいぶんな低下っぷり。WEBサイトを閲覧しても時々もっさりと感じられます。

(2)速度低下が顕著な23時の計測

平日23時の速度差

結果としては一目瞭然ですがDownloadの値に注目するとIPv6: 93Mbit/sに対してIPv4: 2.5Mbit/sと97%ダウン
元の回線が細いとは言え、IPv6接続時と比較して3%ほどの速度しか出ていないという結果になっているのが驚き。

どうりでWEBサイトを見てまわっていてもやたらと遅いなと思うのは気のせいだけではなかったようです。

PPPoEだからオーバーヘッドが大きい?とか、プロバイダ側がIPv4のルーティングに力を入れないから?とか事情はあれこれ想像してしまいますが、利用者側から見えるわけでもないですしそこを追求したとて何もできない(IPv4 over IPv6だとそれほど顕著に速度低下しないのだろうけれどなぁ・・・)

ともかく、回線そのものの速度が低下していなくっても通す通信がIPv4だと遅くなることだけは明らかなようです。サーバーを立てる側もIPv6が使えるなら積極的に使ったほうが利用者に優しいということが言えそうですね


安心安全安価なSDカードデータ復元・HDDデータ復元は
長年の信頼と実績の『株式会社パソコントラブル救助隊』へ。
https://hqsecure.net/