最近 AI というものの進化が様々なシーンで日常を変化させていっている。
ソフトウェアエンジニアリングに関わっていると、一年前、いや半年前と比較しても非連続的といっていい変化がもたらされているのを感じる。

当然、当事者たちは日々 AI との向き合い方、活用の仕方について侃々諤々である。
自分自身その渦中に身を置きながらも、いつものようにポジションを表明せず、お得意の「様子を見る」をしていたのだが、最近読んでいた本の中の一節がふと目に留まった。

この本自体は少し前に執筆されたものだが、最近になって改めて文庫として刊行され、おそらくはその際に追加された解説に書かれていた文章だ。

数学においては「直観」と「規則」が、いつも背中合わせの関係にある。直観的に何かを「わかる」ことと、規則に従って記号を正しく「操る」こととは、常にたがいを支え合う関係にある。計算の意味を「わかる」ことができて初めて、筆算の規則を編み出すことができる。だが、ひとたび筆算の手続きを身につけてしまえば、極端な話、たとえ意味を忘れてしまったとしても、正しく数を「操る」ことはできる。かくして、「わかる」と「操る」は互いを支えながら、原理的には切り離すことができるのである。

この洞察が、たとえば計算機の成立を支える。実際、計算機に「わかる」ための意識や心はないが、それでも様々なデータを規則に従い、正確に「操る」ことができる。直観を孕む人間の知能に、どこまで規則の側から迫っていけるかは「人工知能」研究にとって重要な問題である。

── 森田真生「解説」、矢野健太郎『暮しの数学』中公文庫、2020、pp.241-242

数学を「わかる」ことと「操る」ことは相互に関係するものでありながら、切り離すことができる。これは示唆に富んだ一節ではなかろうか。

また、計算機と同じように AI も「わかる」ための意識や心を持っているわけではない。だが、最新のモデルが「操る」コードの品質はかなりよくなってきている。

ここ数年で設計、開発、テストといったソフトウェアエンジニアリングにおける「操る」業務の一部が急激に AI に委譲されていっている。
しかし「操る」ことを AI に委譲したからといって、実現しようとしているビジネスや、構築しようとしているシステム、採用しているアーキテクチャを「わかる」ことを手放せるわけではない。
自分が「わかっている」ことが AI に作業を上手に委譲するために必要なのだ。
わかっていなければ AI に適切に指示することも AI のアウトプットを正確に評価することもできない。

今やこれらの業務の多くを AI に任せているソフトウェアエンジニアもかなりの数になっているだろうし、その一方で自らが手を動かして開発を行わないことに違和感や不安を抱いている人もいるだろう。
しかし、それを委譲することはけっして己の不要性を示すことにはならない。少なくとも現時点では、それによって直ちにソフトウェアエンジニアの仕事が失われるわけではない。
ただし、考えること、ビジネスやシステム、アーキテクチャを理解することまで委譲してしまってはいけない。
そうなったら、その先にはソフトウェアエンジニアとしての衰退しか残っていない。

タイル型ウィンドウマネージャ yashiki の導入

macOS を利用する際は、かなり前からタイル型ウィンドウマネージャを導入している。

最初に導入したのは Amethyst で、もうだいぶ昔のことなので詳細は覚えていないが、何かしらのアプリケーションとの相性の問題があって、あまり長くは使わなかったと記憶している。

その後は macOS でのタイル型ウィンドウマネージャを諦めていた時期もあったが、併用していた Linux ではタイル型ウィンドウマネージャを使っていたこともあり、良いものがあれば、という気持ちは常に持っていた。

ある時、新しい MacBook のセットアップをしたタイミングで yabai というタイル型ウィンドウマネージャを導入して、それ以降は概ねずっと何かしらのタイル型ウィンドウマネージャを使っている。
期間的には yabai を最も長く使っていたが、他のものも試したいという気持ちで AeroSpace に切り替えて使っていた時期もある。
そしてまた今年、新年を迎えたタイミングで新しいタイル型ウィンドウマネージャを試そうという機運になった。

候補は OmniWM と yashiki の2つ。

BarutSRB/OmniWM: MacOS Niri and Hyprland inspired tiling window manager that’s developer signed and notorized (safe for managed enterprise environments). Aiming for parity and extra innovation.

typester/yashiki: macOS tiling window manager

一口にタイル型ウィンドウマネージャといってもいろいろな種類があり、この2つはウィンドウマネージャとしての基本的な考え方が大きく異なっている。
ここではタイル型ウィンドウマネージャの歴史や系譜については触れないが、今回は両方を実際にインストールして試した。
少しの時間ではあるが実際に触ってみて、現在の自分の使い方に合っているのは yashiki だと判断し、今は yashiki を常用している。

自分の基本的な使い方

yashiki がどのようなものかはリポジトリを見に行ってもらうのが速いと思うが、自分の使い方を一部紹介する。

前提として、デフォルトのレイアウトは tatami を採用している。

まずは README に書かれている設定にもあるが macOS の Spaces を再現したいので、 ctrl-1 〜 ctrl-9 でそれぞれ tag N を表示するようにしているが、 tag N はそれぞれ bitmask 2^N-1 を表す。
それぞれの tag にアプリケーションを割り当てており、上記のホットキーでスムーズに切り替えられるようにしている。

yashiki （や yashiki が参考にしている river）が面白いのは tag を bitmask として表現しているところだ。
先にも書いたが、例えば ctrl-3 は tag 3 に切り替えるが、これは bitmask 4(binary: 100)に相当する。
逆に bitmask 3(binary: 011)は tag 1 と tag 2 の和集合であり、これを表示すると tag 1 に割り当てられたウィンドウと tag 2 に割り当てられたウィンドウの両方が表示される。

これを活かすため、自分はさらに ctrl-shift-1 〜 ctrl-shift-9 に 2^N-1 を tag-toggle する設定を追加している。
yashiki tag-toggle コマンドは、指定した bitmask と現在表示している bitmask の XOR をとる。
これによって、たとえば ctrl-2 を押して tag 2 (= bitmask 2) を表示している状態で、 ctrl-shift-5 を押すと bitmask 18 を表示している状態になる。
これはつまり tag 2 (= bitmask 2) と tag 5 (= bitmask 16) を同時に表示している。
tag-toggle コマンドは XOR をとった結果が 0 になる場合は何もしないので、表示する tag がない状態にはならない。

最初に tag N にそれぞれ1つ（ないしは2つくらいまでの）ウィンドウを割り当てて置くことで、1つのウィンドウを画面全体に表示したい場合も、2つのウィンドウを左右に分割したい場合も簡単に切り替えることができる。

また tatami は master-stack 式のレイアウトだが、 master 側（画面の左側）に置くウィンドウの数を増減できるので、 4K ディスプレイなどでウィンドウを 2x2 に配置することも容易にできる。

yashiki を紹介するトークをしてきた

湘.なんか #4 - connpass

先日、「なんか」を話す会に参加してきた。
何を話そうか、というところで最近自分の中でホットな yashiki の話をしてきたという次第。

自分はそれなりにタイル型ウィンドウマネージャを使ってきているけど、がっつり使いこなしているというよりは、浅瀬で基本的な機能だけを使っているという感じなので、他の人がどう使っているかを知りたい。
そのためにもまず、使ってくれる人が増えたらいいなあ、という思いがあったのでちょうどよい場が得られてよかった。

昨年の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 の結果からブランチ切り替えのログを抽出して、ブランチ名のリストを得るという方向に切り替えた。

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

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