昨年の11月下旬頃だったか、 KickStarter からのメールでこのキーボードの存在を知った。

Go60 - MoErgo

元々4年くらい前に KickStarter でバックして、届いて以来3年弱使っているキーボード Glove80 の開発元 MoErgo が作った新しいキーボードが Go60 だ。

Glove80 という新しいキーボードが届いたので試している

今回も KickStarter で pledge することで先んじて手に入れることができそうだったので、迷わず注文した。 注文を迷わなかったのは、 Glove80 が期待通りに良い製品で、この3年間ほぼ毎日利用している愛用のキーボードだったから。不安なく Go60 に期待することができた。

2025年は、国内でもそれまでと比べてオフィス回帰が進んでおり、自分もオフィスに行くことが増えた一年だった。一時期は Glove80 を持っていっていたが、如何せん嵩張るし、その割にたまの出社となると会議が多く作業時間をあまり取れないため、荷物を減らすために家に置いていくようになっていた。 Glove80 とは違うキーボードをオフィス用に購入して試してみたりもしたが、自分の期待に応えられる品質ではなかったりで、オフィス用キーボードに困っていた。

そんなときに存在を知ったのが Go60 だ。 Go60 は少なくとも Glove80 と比較するとかなりサイズの小さい60%キーボードで、以下のような特徴を持っている。

• 分割キーボード
• ロープロファイル
• 60%
• BLE 対応
• カーソルの操作などに使えるタッチパッド
• 静音スイッチ

これらの特徴は、持ち運び用のキーボードとして自分が求めている条件をかなりクリアしている。

一方で Glove80 とは違ってお椀型ではない。が、これは持ち運びのことを考えると諦めざるを得ないし、60%なのでお椀型にするメリットもフルキーボードと比べると幾分か少ないといえる。

また MoErgo の静音スイッチについては発売当初から気になっていた。 押下圧30gの桜と押下圧45gの梅。 現在販売されている Glove80 ではどちらも選択可能だが、初期の KickStarter 版の Glove80 では選択できず、 KickStarter 版の Glove80 はホットスワップではないため、キースイッチだけ購入して付け替えることもできずにいた。 （かなり悩んだが、流石に円安が続く状況下で Glove80 をもう1つ買うという決断はできずにいた）

Glove80 の頃と比べると、円安の影響でかなり高額になってしまっていたが、金額以外は全てが良い Go60 を入手しない理由がなかったので、なんとかお金を工面した。

MoErgo にとって最初の製品だった Glove80 と違い、 Go60 ではクラウドファウンディングに需要調査の意味合いが少なかったのだろう、 Go60 は KickStarter に情報がでた時点で既に製造の見込みがついており、当初のスケジュール通り年末には集荷され、自分は1月8日に受け取ることができた。

というわけで約3ヶ月使ってみての感想をいくつかの視点からまとめて以下に記す。

テンティング使っている状態。 LED は写真映えのためつけており、普段はオフにしている。

持ち運び

やはりまずは Glove80 でカバーできていなかった持ち運びに関して整理しておきたい。

毎日持ち運べる

Glove80 と比較してサイズの小ささはやはり画期的で、気軽に持ち運べる。 製品には持ち運び用のケースと袋が同梱されており、追加の投資なしに安全に持ち運ぶことができるのは、非常に良い体験だった。

打鍵音がとても静か

静音スイッチを採用しているのだから当然かも知れないが、打鍵音はとても静か。 これが先の「毎日持ち運べる」と相性が良い。 出先（自分の場合は基本的にオフィス）において、周囲を気にすることなく使うことができる。

テンティングキットも持ち運べる

製品には親指側の高さを調整するためのテンティングキットが含まれている。 数段階の高さに調節可能なテンティングキットで、本体とは磁力で接続する形式になっている。 このテンティングキットにも持ち運び用の巾着袋が付属しており、本体と一緒に持ち運ぶことができる。

普段の作業環境での利用

もちろん普段自宅で作業する際にも利用できる。

専用パームレスト

Go60 専用のパームレストがある。 これも磁力でキーボード本体と接続する形式で、さらにはパームレスト用のテンティングキットも付属している。 パームレストありで使用する際にも高さ調節ができるのは非常にありがたい。 （一応パームレスト自体も少し傾きがあって、この角度がちょうどよいという人もいると思う）

さらにこのパームレストの木の部分が良く、個人的には高級感を感じるレベルだ。 しかもパームレストをつけた状態での使い心地が非常に良い。

実はこのパームレストも巾着袋が付属しており、持ち運ぶことができるようになっている。 が、さすがにこれも持ち運ぶと嵩張ってしまって Glove80 を持ち運ぶのと同じ問題が発生してしまうので、自分は基本的にパームレストは自宅用として置きっぱなしにしている。

パームレストなしの運用

もちろん、自宅でもパームレストなしで運用できる。ちょっと環境を変えて作業するときでも部屋間の持ち運びはしやすいし、ラップトップ＋ Go60 という組み合わせもかなり便利だ。

タッチパッド

キーボードだけ持ち運べても、カーソル操作には別でマウスが必要だったり、ラップトップに内蔵されているトラックパッドを使うことになったりする。 Go60 には左右に1つずつタッチパッドがついており、これにカーソル操作やスクロール、クリックなどを割り当てることができる。

カーソル操作については、マウスやラップトップ内臓のトラックパッドと比較して正直性能面では物足りない。無意識にうまく操作するには相当な習熟が必要だと感じている。 ただし、普段はほとんどの操作をキーボードで完結させ、マウスの使用を最低限に抑えることができているユーザーであれば、その最低限を賄うには十分かもしれない。 自分は作業の内容にもよるが、ターミナルに長く引きこもっていられるような作業も少なくないので、そのような状況ではこのタッチパッドを便利に活用できている。

とはいえ、これがあればマウスが不要かというとそんなことはなく、たとえばドラッグアンドドロップをこれで行うのは正直難しい。

カスタマイズ

ホットスワップ

Glove80 のときはホットスワップではなかったため桜や梅といった静音スイッチを試せなかったが、 Go60 はホットスワップに対応している。 現時点ではその恩恵を受ける予定はないが、将来「今使っている桜もいいけど、軽すぎるよりは45gの方が良いかも」となったときにキースイッチを買い足せば本体をそのまま使えるのはありがたい。

キーキャップ

当然キーキャップも付け替えることができる。 とはいえ、個人的にはデフォルトで付属している POM キーキャップがおすすめ。 LED を綺麗に透過する白のキーキャップは Glove80 および Go60 のキーキャップとして最も適切といって差し支えない。

ただ、自分は今回、ベースカラーを黒（正確にはグレー）をしたかったため、 LED を透過できる黒色のキーキャップとして Double-shot PBT/PC の Black with smoky transparent を別途購入した。

ついでに色選択の理由を記しておく。

まず、唯一選択肢がないのがタッチパッドの部分で、ここは黒しかない。 MoErgo 製品の白は個人的にはかなり好きな部類で、 Glove80 の時も白を選択したのだけど、ベースを白にしてしまうと、白の中でタッチパッドの黒がどうしても目立ってしまう。 これを避けるため、ベースをグレーにした。 そうすると今度はベースがグレーでキーキャップが白になる。 これは個人的にはちょっと好みではなかった（ベースがグレーの商品の写真を見て知人は「歯のように見える」と言った）。 キーキャップを黒に変えることを検討したが、普通の黒のキーキャップでは LED を見ることができない。 MoErgo のキーボードはバッテリー残量や Bluetooth の設定を LED で確認できる仕様であるため、 LED は表示したい。 そのため LED 透過用の窓がついたキーキャップを購入した。窓の部分が透明のものとスモーキーのものがあり後者を選択したが、その際には Discord で様々な人が貼ってくれた写真を参考にした。

キーレイアウト

当然キー配列のカスタマイズも重要だ。 カスタマイズの自由度は完璧ではないものの、 MoErgo が公式で提供している Layout Editor が使い勝手が良く便利。 正直なところ、大抵のケースではこの Layout Editor を使うのが正解だと思う。

万が一 Layout Editor で設定できないようなカスタマイズがしたい場合も ZMK での柔軟な設定が可能で、 GitHub 上に Go60 用の config が公開されている。

個人的にちょっと不便なところ

もちろんメリットばかりでもない、というかある人にとってのメリットはある人にとってのデメリットなわけで、自分にとってここがちょっとなあ……と思うところも記載しておく。

z と / の手前にキーがない

自分の分割キーボードにおけるレイアウトは Kinesis Contoured Keyboard だ。 そこからいくつかの製品を経て今に至っているが、 Glove80 でも概ね Kinesis 自体と同じ設定で利用している。 そのため、 z の下に ` が、 / の下に ] があってほしい。 Go60ではこれを再現することができない。

親指キーの区別がつきづらい

この手の分割キーボードでは親指キーが重要だ。 Go60 の親指キーの数は少なくはなく、その点には助けられている。 一方で、自分が今指を置いているキーがどれかが感覚的に分かりづらい。 このため使い始めた頃はかなり操作ミスが発生した。

といいつつ、流石に3ヶ月弱も使っていれば慣れてきており、最近はそんなに困っていない。 この点、 US キーボードと JIS キーボードを切り替えてもそんなに混乱しないし、たまに dvorak やかな入力を使ってもあまり混乱しない自分の特性に寄るところが大きい気がする。 （周りではこれらの切り替えができないという声が大半であり、そのような人たちは慣れるまでにより多くの時間が必要かもしれない）

持ち運び用のケースの色が選べない

付属してくるケースの色が黄色なのだけど、個人的にはキーボード本体の色に合わせたかった。 とはいえ、ケースごと巾着袋に入れて持ち運ぶので正直そんなに強いこだわりはない。 これは不必要な意見かもしれない、と自分でも思う。

パームレストにドッキングした状態。 LED は写真映えのため(ry。

Glove80 と Go60 でどこでも快適に作業できる

正直、このキーボードは自分がキーボードに求めているもののほとんどを満たしてくれる、最高に近い製品だと思っている。

パームレストも含めて考えれば、自宅でも出先でも Go60 ひとつあればよい、という状況にできている。 バッテリーの持ちも非常によく、急に使えなくなって困るという経験もまだしていない。

もし、メインの作業場所が2つになっても Glove80 もあるので今後もこの布陣で十分にやっていけると確信している。 この2つと長く付き合っていくつもりなので、大事に扱っていきたい。

使い始めて5ヶ月弱くらいになる。主に散歩や通勤の際に利用している。

月額料金がそこそこするので、「元が取れているかどうか」は正直よくわからないが、現時点ではあまり気にしていない。全然使わなくなったなーという時が来たら解約すればいいか、くらいのスタンス。

履歴を見てみると、今聴いているものも含めて 18 冊。うち 3 冊は過去に紙や電子書籍で読んだことがある本なので、新たに触れた本は 15 冊。通勤頻度が特別高いわけでもないので、妥当なペースだと思う。

どんなときに聴くか

先にも書いたが、主に散歩や通勤のときに聴いている。
他にも、定期的な通院や人と会う予定があるときなどにも使うことが多い。

基本的には、歩いているときか電車に乗っているときだけ。車に乗っているときには聴かない。
また、気分が乗らないときは散歩や通勤中でも聴かないこともある。

どんな本を聴くか

「これが聴きたくて契約した」という本があったわけではなく、目についた本をスマートフォンにダウンロードして、その中から気分で選んでいる感じ。

経済の本やビジネス書、断捨離系など、興味のある分野に関連しそうな本を選ぶことが多い。

今のところ小説は聴いていないが、シリーズものの小説もラインナップされている。シリーズものは「読破（聴破？）」するのにかなり時間がかかりそうだなと思う。

良かった点

特に歩いているときに暇を持て余さないのが良い。

基本的に歩くのは好きで、近場なら歩いて移動することも多いが、見慣れた景色だと時間を持て余しがち。思索にふけるのも好きだけど、そういう気分じゃないときもあるので、そういう時に本を「聴きながら歩ける」のはありがたい。

一方、通勤などで電車に乗っているときは歩いているときほどのメリットは感じない。混んでいて両手が使えない場面では助かるが、空いていれば紙の本でもいい。

これは今使っているイヤホンのノイズキャンセリング機能が壊れているのも大きい。電車の中だとある程度音量を上げないと聴き取りづらいが、耳のことを考えるとあまり大きな音では聴きたくない。そろそろ買い替えてもいいかもしれない、と思いつつそのまま。

不満な点

Audible を使うようになってから、ちょっと気になる本があったら「 Audible にないかな？」と調べることが増えたが、だいたい無い。
今のところ、このパターンで Audible にあったことが一度もない。

そのため、本当に読みたい本は結局紙か電子書籍で積んでいくことになる。これはこれで消化したいけれど、読むペースより積むペースの方が早いので、 Audible を使うことでこの問題が解決したわけではなかった。

総合的な感想

個人的には Audible は気に入っている。もちろん、そうでなければ続けていない。

「これが聴きたい！」と思った本が Audible にあれば最高だけど、そうでなくても Audible で見つけて聴いた本をきっかけに、新しい本と出会えている実感があるので、十分満足している。

普段の Git の操作は、なるべく使っているエディタや IDE の機能に任せよう、と思いつつ、なんだかんだと込み入ったことをしようとするとターミナルを開いて git コマンドを直接打つことになってしまっている。

最近は同時に扱うリポジトリが増え、さらに複数のブランチを並行して開発を進める、というケースがにわかに増えてきている。これによって最近感じていた課題が、「あの作業はどのブランチでやっていたか」である。特にちょっと小さなコミットを積んですぐ別のブランチに移る、ということをやっていると、それぞれのブランチの名前を部分的に覚えておくことすら煩わしく感じるようになってしまった。

ブランチを切り替えるとき、普段遣いしていたのは以下のようなコマンドである。

git branch | grep -v HEAD | sed -e \'s/* /  /g\' | string trim | fzf-tmux | read -l result; and commandline "git switch $result"; and commandline -f execute

fzf でローカルブランチをリストアップしてその中から選ぶ、というものでシンプルで使い勝手が良い。ただ、普通に git branch しているので、リストがブランチ名の昇順になってしまう。ソート指定で最新コミット順にするという手もあるが、直感的に並ぶかというとそういうわけではない、というかゆいところに手が届かない感じに悩んでいた。

で、ブランチを頻繁に切り替えるときに代用するようになったのが git switch - である。これは直前のブランチに戻るコマンドで、最近の自分のユースケースにかなりマッチしている。時々2つ前のブランチに戻りたいときもあり、そういうときは git switch @{-2} と打ったりしていた。

これを繰り返していると、最近利用した順に並んでいるブランチ名から選択して切り替えたい、と思うようになったので、そういう function を作ってみた。

https://github.com/risou/config/blob/aee46efc0237b961236c727af868126cc8723973/config.fish#L114-L153

最初は git switch @{-n} を 数十回繰り返す、みたいなことをしていたが、当然これだと遅いので、一気に対象を取得しようと git reflog の結果からブランチ切り替えのログを抽出して、ブランチ名のリストを得るという方向に切り替えた。

これによって、「いくつ前のブランチに戻りたいか」がわかっているときはもちろん、少し曖昧なときもリストを見て名前から判別できるようになった。

使い勝手に問題がないかや速度面に問題がないかなどは、これから使っていく中でチューニングしていく予定だが、最近気になっていたことを解消するものを作れたことに満足している。

ここ数年、ウィンドウマネージャとして yabai というツールを使っている。
yabai が本領を発揮するためには System Integrity Protection を無効にする必要があるけれど、プライベートの環境も仕事の環境もなるべく同じに揃えておきたい気持ちがあり、会社から貸与されている Macbook の SIP を無効化しようとは全く思わないため、 SIP を無効化せずに使っている。
ところが MacOS Sequoia にアップデートして以降、少なくとも SIP が有効な環境ではウィンドウを別のスペースに移動させることができなくなった。

これまではスペースを大量に使って、スペースごとに最大でもウィンドウは2つ、といった運用をしてきたけれど、先の問題と作業環境のディスプレイの配置を変えたことが重なって、ウィンドウの管理方法が変わってきた。

最近は同時に使うスペースの数を少し減らして、代わりに1つのスペースに3つ以上のウィンドウがある状態で yabai の zoom-fullscreen を多用している。
また 4K 以上の解像度があると、3つ以上あるウィンドウの中から任意の2つを左右に分割したり、 2x2 の4分割にしたりという運用をすることもある。

zoom-fullscreen は yabai 上で managed (= not floating) なままで使うことができるが、2分割や4分割で使うためには floating にする必要がある。すなわち yabai において managed=off にする必要がある。
（本来的には、そのスペースにウィンドウが2つしかない状態にすることで yabai が勝手に左右に分割してくれる、という状態が望ましいし、4分割においても概ね同様のことが言える）

で floating の ON/OFF を頻繁に切り替えると、ウィンドウのフォーカスを切り替えるときなど、ふとしたときに期待する操作が行えない、ということが発生する。これは floating なウィンドウは yabai に manage されていないことに起因しており、アクティブウィンドウが floating なときに yabai -m window --focus east などが使えないため、他のウィンドウの選択が少々面倒になる。

ということでアクティブウィンドウが floating かどうかをいつでもわかるようにしたい、という動機で yabai, skhd, JankyBorders の設定を色々いじってみた。

具体的には、アクティブウィンドウがどれかをわかりやすくする JankyBorders の色情報を切り替えている。 yabai managed なウィンドウであれば緑に、そうでなければ黄色になるように設定した。

そのウィンドウが floating であるかどうかを判定したいタイミングは、大きくわけて以下の2種類になる。

• アクティブウィンドウの floating ON/OFF を切り替えたとき
• ウィンドウのフォーカスを切り替えたとき

前者については、該当するショートカットを実行したときに borders コマンドを叩くようにしている。
floating の切り替えを行う際はいつも、 toggle floating のショートカットを入力するか、上記の2分割、4分割の状態にするショートカットを入力するため、それらのコマンドに borders コマンドを組み合わせているだけだ。
一例を示すと、以下のような感じ。

alt + shift - f : yabai -m window --toggle float; [ "$(yabai -m query --windows --window | jq -r '.["is-floating"]')" = "false" ] && { borders active_color=0xc000ff80; :; } || borders active_color=0xc0ffff00

https://github.com/risou/config/blob/8b2f46f7dc3b93118e95690e3e1382ced7d9ba3e/.skhdrc#L61

もう1つのケースがフォーカスを切り替えたときで、この場合は yabai の signal で borders コマンドを発火している。

yabai -m signal --add event=window_focused action='[ "$(yabai -m query --windows --window | jq -r ".[\"is-floating\"]")" = "false" ] && { borders active_color=0xc000ff80; :; } || borders active_color=0xc0ffff00'

https://github.com/risou/config/blob/8b2f46f7dc3b93118e95690e3e1382ced7d9ba3e/.yabairc#L95

これで、常に現在アクティブなウィンドウが floating かどうかが目に見えるようになった。

とはいえ、せっかくタイル型のウィンドウマネージャを用いているのに floating を多用するのはもったいないように感じている。

現代においては AeroSpace という非常に魅力的な選択肢もあり、時間に余裕ができたら試してみようか、という気持ちは少しある。
思想としては AeroSpace よりも yabai の方が好みなので、可能であればこのまま yabai を使い続けたいが、さて。

以前は Übersicht で simple-bar というウィジェットツールを使っていた。

このウィジェットを使っていた主な目的としては、 yabai というウィンドウマネージャを使っている中で、どのデスクトップにどのアプリケーションを置いているかなどが可視化されていると嬉しいというのが最も大きい。
このウィジェットツールは Mac の標準のメニューバーを代替することを想定しているものなので、日時に表示はもちろん、個人的には Spotify のステータス表示および再生・停止を行うウィジェットを便利に使ったり、自分でカスタマイズして MeetingBar の表示および次のミーティングへの参加ができるウィジェットを用意して、普段は OS が用意しているメニューバーを必要としない状態にしていた。

が、いくつか問題があって代替を探していた。

主な問題は何かというと、

• 時折、負荷がかかっていそうな気配を感じさせる
  • CPU 使用率が跳ねたり、ファンが全力で稼働している音がしていた
• ローディング状態が続く
  • 各ウィジェットが shell を定期実行してその結果を表示、という挙動をしているのだが、細かく大量にコマンドを実行しているためか、おそらく待ち行列が発生してローディング状態になって何も情報が得られない、という状態に結構なっていた

あたりで、特に後者はメニューバーの代替としての価値をほとんど失ってしまっているので時間を見つけて解消したいと思っていた。

simple-bar の代わりになりそうなものを探して、以下の２つのどちらかをためそうと考えた。

• simple-bar-lite
• SketchyBar

前者は simple-bar の軽量版ということで、導入コストが低そうなのが魅力だった。
が、問題の根本がもし Übersicht なのであれば、 simple-bar-lite を導入しても問題が解消しない可能性があった。

ということで、 SketchyBar を試すことにした。

実は SketchyBar の導入は Übersicht を導入したときにも検討をしていた。のだけど、調べてみたところ結構導入が大変そうだったので、一度見送ったという背景があった。

とはいえ、今回はもう腹をくくってこれを導入しよう、ということで、 Share your setups · FelixKratz/SketchyBar · Discussion #47 · GitHub から様々なセットアップを探して、ひとまずこれにしよう、というものを決めてそれを元に自分用にカスタマイズをした。

まずは、各デスクトップで開いているアプリケーションの表示部分をカスタマイズ。 4K などのモニタを使っているときは良いが、 FullHD のモニタではデスクトップ数が多いと横幅を広く取りすぎるので、アプリケーションがないデスクトップの表示をコンパクトにして、代わりに今アクティブなデスクトップのアプリケーションアイコンを省略しないようにした。

Spotify の表示についても参考にしたものでかなり整っていたが、再生・停止等の操作はポップアップメニュー経由で行う前提になっていたのと、再生していないときには表示領域に何もでなくなってしまうので、アイコンを常時表示にして、アイコンをクリックするだけで再生と停止を行えるようにした。

MeetingBar については自分で実装してワンクリックで次のミーティングのページを開けるようにした。これについては simple-bar 用に自分で用意したスクリプトをそのまま流用できたのでそんなに大変じゃなかった。

SketchyBar を導入して Übersicht を使っていたときの問題は解消したかというと、今のところ解消していそうな気配を感じている。
ファンが唸ることはなくなったし、ローディング状態にもならない。
さらに、 Übersicht から SketchyBar に置き換えたことが直接的な要因かは定かではないが、バッテリーの持ちが大幅に改善した。最近、長時間のオフラインミーティングなどで、途中でバッテリーが尽きてしまう問題を抱えていたが、かなり持つようになったことでこの問題が解決したことは副次的効果としては非常に嬉しかった。

これは Übersicht も同様だが、導入に際してどういう仕組みであるかを理解するまでのコストが高い。一方で、仕組みを理解してしまえばカスタマイズは容易といえる。
ということで、自分のやりたいことができるようになってきたところなので、時間に余裕ができたらもう少しカスタマイズしたいな、と思っている。
とはいえ、どんなカスタマイズをすると便利かの鮮明なイメージはまだ持っていないので、使いながら色々と考えてみようと思う。