投稿日:

この記事では、ここ最近見つけた面白いサービスやホームページについて書いていく。

サービス編

なんでもメモ、デライト (Delite)

まず初めに紹介するのがなんでもメモ、デライト (Delite)だ。どことなくレトロな雰囲気が楽しいサービスだ。

「デライトは、なんでも記憶できる魔法のメモ帳です。」とあるサービスで、ぱっと見はマイクロブログ的になっているが、投稿はすべて公開され、メディアのアップロード添付はできず、文章だけを投稿できるSNSだ。

このサービスでは投稿は「輪郭」と呼ばれ、輪郭は、花のように1輪、2輪……と「輪」で数えるとある。トップページにも「3,117,820輪の記憶が描き出されています。」とあり、投稿を「輪」という単位で計数していることがわかる。

また輪郭にはタイトルと本文を付与でき、タイトルは「知名」といい、これはハッシュタグとして機能するようになっている。本文は「描写」と呼ばれている。投稿すると投稿番号が附番されるが、これも「知番」という名前になっており、独自の世界観が熟成されていることがわかる。他にも独特の要素が色々あるので、気になった人は是非、使い方を見てみてほしい。

アカウント登録は利用者番号とパスワードのみで行うことができ、メールアドレスが不要であることも独特だ。要するに忘れたら戻れないが、アカウントの価値に重きを置いていないことも伺える。初期のころのMisskeyもそうだったが、あちらはメールアドレスが今では必須に近い運用だろう。

中身としてははてなキーワードの現代版といった感じで、「知名」を「引き込み」という、RTやリブログに近い仕組みで引用し、新しい輪郭を作ることで輪郭同士を知名で連携し、全ての情報をハッシュタグでリレーしていくような感じの世界が広がっている。

Wikipediaで何かの記事を見て関連記事を眺めていくみたいなことが無限にできる感じだ。中身はそこまで濃くなく、全体的にはてなキーワード的だと思う。

つまりこれは懐かしい感じのUIや雰囲気の中に、やや中二病じみた世界観を生み出し、中身としてははてなキーワード的なマイクロブログだといえると思う。

ちゃんと広告が貼ってあったり、ダークモードも実装されているのは今風だと思うし、広告が少なく、そこまで邪魔でもないのは利用に際し、快適だと感じる。

rururu

rururuはソーシャルフィードリーダーだ。個人的にソーシャルフィードリーダーという概念をここで初めて知ったので新しい概念に感じている。

これは自分の購読しているフィードを公開したり、読んだ記事に足跡をつけたり、その痕跡を友達にも見せられるサービスだという。

アルゴリズムで作られたおすすめ投稿がタイムラインに並ぶ昨今のSNSへのカウンターとして、拡散を意図しないブログサービスや個人サイトなどでしずかに情報発信をする人が増えています。そこで便利なのがフィードリーダー。フィードリーダーは自分が登録したサイトの更新情報だけが流れてくるので、自動レコメンドに煩わされることなく個人発信の最新情報をキャッチできます。

サービスの説明には、このようにあり、こちらもデライト同様に中々独創的なサービスだと感じる。

実は私も過去に似たようなものを考えたことがあり、それが具現化されていたのもあり、非常に面白いサービスだと感じた。

現在はまだベータサービス中で、本格運用はされていないようだが、申請すればベータアカウントが登録されるらしい。

個人的にはrururuという楽しそうなサービス名や、肉球のアイコンが気に入っているし、このブログもフィード登録されている事についても、嬉しく思っている。

ピクリエ

ピクリエはオンライン同人誌即売会ができるサービスだ。ここまでに紹介した個人運営系のサービスとは毛色が違い、お金が発生するやつで、会社法人が運営しているサービスである。運営企業はなんとメガネの町、鯖江にあるらしい。

ただ会社の住所や運営形態を見る感じ、自営業者ではあるように思う。

システム自体は名古屋にある株式会社GMWという企業が開発したpictSQUAREというものを使用しているらしい。なんと特許をとっているらしく、ピクリエはこの特許利用を許諾されている唯一の例らしい。

中身としてはRPGツクール的な画面の中で即売会イベントを行い、サークル側は指定のブースに立ち、ユーザーは会場を巡回し、ブースを回覧していくといった感じの内容だ。ただ、即売会とは言うもののピクリエ自体には販売機能がないため、ブースではBOOTHや通販サイトなどのリンクを張り、ブース内ではやってきた同好者と話をしたり、サンプル本が見れるリンクを見せて読んでもらったり、というのが軸になるようだ。

費用としてはイベントの企画者がシステム利用料をピクリエに払うほか、ユーザー側もイベンターに対して支援金を払うことができるようで、これはエールと呼ばれ、支援金の一部(15%)はマージンとしてピクリエの収益となるそうだ。他にサークルから参加費を撮ることができるが、これは主催者に送金されるものらしい。恐らく主催者はサークルから集金したお金をシステム利用料に転嫁することが多いのだろう。

エールはあまり期待できないだろうから、ピクリエは基本的にイベントのシステム利用料を収益源としていることが伺える。24時間のイベントだと1サークル当たりのシステム利用料が550円だそうだ。

3月3日~3月29日では780サークルの参加が確認できたことから、ピクリエとしては429,000円の収入がある。結構渋い。ちなみに29イベントあり、サークル参加の平均は26.89サークルだった。

ホームページ編

neocitiesのホームページたち

特定のホームページを指すわけではないがneocitiesのホームページは昔のホームページとは異なるものの、GIFがキラキラいごいごしていて、どこか懐かしい風景が見れる。

全てがすべてそうというわけでもないが、100%healthneo's HEAVENWURLD ଘ(ˊ_ˋ)caramelpuddinzなどはその一例といえるだろうし、英語圏のホームページでもWebリングや日本のアニメ的画像が用いられているのは興味深い。

I'M FANTASIZING ALL THE TIMEというホームページも英語圏のように見えるのだが、何故かD4DJの笹子・ジェニファー・由香を熱く推したページが存在している。結構マイナーな作品だと思うのに、一体どこで知ったのか謎である。海外でも配信はされてたらしい

1990~2000年代の懐かしホームページとカオスのような空間を楽しみたい人にはneocitiesホームページ巡りはうってつけだ。気が付いたら時間が溶けていること間違いなしである。

ドギマギふんたぢ~

急にゆるいタイトルが出てきたが、ドギマギふんたぢ~というホームページでは、管理人のえのきのこさんが可愛らしいドット絵をはじめとしたイラストを展示されていて、非常に和む。

ホームページのタイトルがGIFでくるくるゆらゆらしていたり、全体的に手作り感というか、めちゃくちゃ手書きで手作りのデザインがとても素敵だ。

思えば、昔はこんな感じのゆるーい絵師さんのホームページをよく見ていた気がするし、怒涛のごとく流れ、消費してしまいがちなpixivやTwitterなどのSNSで絵を見るよりもゆったりと見れて、記憶に残りやすく、その分、感動もあるように感じる。

カウンターをクリックすると何やら胡散臭い所に繋がり、胡散臭さしかないのもいい。なんか埼玉の会社がやってるアクセスカウンターらしい。恐らく無料カウンターを多くのサイトに乗せてもらうことで被リンクを増やし、自社のSEOを上げようとしているのだろう。

ヤチヨの部屋 - Yachiyo's Room

ヤチヨって誰だよ!となるのが次に紹介する、ヤチヨの部屋 - Yachiyo's Roomだ。

恐ろしいことにタイムスタンプがすべて2003年で、お絵描き掲示板は動かないのに掲示板の風体をしてるし、タイムスタンプに対して絵柄が新しすぎるw

絵茶には定型文のチャットが流れ続ける中、自分も入力して流せるギミック付きで面白い。

絵茶はクレジットからして既存システムを使いまわしているようだが、ゲーム置き場には本格的なゲームもあり、ちゃんとプレイできる内容になっていて、ドット絵もかわいいのに、こちらにはクレジットがないのが驚きだ。

またフレームを使ってそうで、流石に使っていなかったり、ベースのHTMLが韓国語なのをブラウザの言語設定か何かを見て日本語表示になるようになっているのも面白い。

タイムスタンプの違和感や、取りされなかったハングルの痕跡など、全体的に嘘くさくて不気味なところはあるが、作りこみが素晴らしく、ぎゃらり~に至っては恐らく管理人氏のイラストだろうか?文字の部分は丁寧に各言語に直されているので、非常に素敵だ。特に「メンダコだよ…たぶん?」の可愛さや「シーラカンス!」の力強さ?が好きだ。

ちなみにこのホームページはフェイクが多いように感じるが、アクセスカウンターはどうも本物らしく、またWeb拍手もちゃんと書き込むことができて、これまた面白い。

作者は絶対面白い人だと思うので、一度どんな人なのかSNSか何かで見てみたいところである。多分一人で作ってないと思う。

🌐Web 1.0 同盟

🌐Web 1.0 同盟は、なんと最新の技術で作られたWebリングである。ホームページにあるGoogle Formから申請すると登録することができる。

JSを貼り付けることでバナーを表示するのだが、どうやら参照するスクリプト内に登録ホームページの情報が列挙されていて、それを読み込むことで動いているようだ。github.ioのリソースだけで動かすことができ、この手のものにしてはバックエンドが不要というのがユニークだ。しかも実装技術にはOnionring.jsという海外製のものを使っているというのも面白い。Webリングって海外にもあるの!?でも、neocitiesにはあるからあるのかもしれない…?

バナーデザインもWeb1.0っぽく、ホームページのデザインもそれっぽいのがいい。実装や記法はモダンだが、見た目はレガシーというのに趣を感じる。

私も発見してすぐに申請を出し加盟しており、トップページにバナーを貼っている

あとがき

しかし、デライトもrururuも、アクセス解析にあったリファラで存在を知ったのだが、こういう経験をするとMatomoを入れて本当に良かったなと思える。何故なら私はGAを使っていた時は、まともにデータを見ていなかったからだ。Matomoは常に私に発見と感動を与えてくれる。非常に素晴らしいアクセス解析だと感じる。

昨今は個人ホームページブームが復権してきているのか、こういったものが増えていて個人的にはとても楽しい。これぞインターネットって感じがする。そう、令和初頭のインターネットの在り方の一つなのかもしれない。

個人ホームページ周りの隆盛については、以前書いたミンゲイインターネットの紹介でも触れているし、この手の記事はBlueskyの例の記事を読んだ感想と、古今のインターネットへの想いや、古のサイト探究~駄文同盟のID上位100サイトを巡り、今までのネット人生や自サイトの過去を振り返ってみるでも触れている。

私にとって個人ホームページこそが全てのインターネットの始まりで、Webみたいなところがあるので、こういう風潮はとても良いと感じているし、昨今の中央集権型のインターネットよりは、個人ホームページや、雑多なサービスに分散された疎なインターネットのほうが、余計な諍いも減り、平和になるだろうとも思っている。

更新日:
投稿日:

私は30年ほどWindowsをメインで使っていて、LinuxではXfceを使っており、モバイルはAndroidを利用しているが、急遽仕事でmacを使わざるを得ない事態になり、非常に不便だったので、その不便さと、多少でも緩和できる方法を書いていく。

使用したマシンはM4 Macbook Proで、OSはSequoia 15.2で、比較対象はWindows 11だ。

macを使っていて不便に感じたこと

ウィンドウの切り替えが困難

Windowsであれば、Alt+TabやWin+Tab、タスクバーからマウスで切り替えなど、ウィンドウの切り替えは造作もないが、macではこれが非常に大変だった。

まずAlt+TabやWin+Tabに相当する機能はOS標準では存在せず、AltTabといったサードパーティソフトが必要だ。

タスクバーからマウスで切り替える操作についてはDockから似たような操作ができるが、同じアプリケーションのウィンドウが二つある場合、右クリックしてメニューを出し、選択する必要がある上、どれが何なのかが解りづらい。

またDockが画面の縦幅を占有するので邪魔なので隠してしまうと、Dockを再表示させるのも時間がかかり、この操作には非常に実用性がない。

macを使っている人にどうしているか聞いてみたところ、ウィンドウの数だけ仮想デスクトップを作って、Magic Trackpadでスワイプして切り替えているとのことだった。

要するに複数のウィンドウを切り替えて並行で操作しながら作業するという運用には向いていないようだった。

余談だがWindows 11のAlt+Tab操作はウィンドウが切り替えられないことがしばしばあり、私はマウスで切り替えることが多いのだが、macの隠れるDockを使ったウィンドウ切り替えはあまりにも非効率的で、到底承服できなかった。きっと4Kモニタのように画面に余裕のある状態での利用が想定されているのだろう。

マルチディスプレイ環境でウィンドウをモニタの境界線上に亘って表示できない

Windowsであれば画像のように画面の境界を越えてウィンドウを表示することは標準で可能だが、macで同じことをするとどちらか片方にしか表示されず、もう片方のモニタからはウィンドウが消えてしまう。

恐らくmacではモニタの境界を越えた状態でウィンドウを表示することを想定していないか、そこで切るのが正しいという考えがあるのだろう。

なお、Xfceでもモニタの境界に亘って表示させることは標準で可能だ。

私は作業を一時中断して退避させるなどの目的でモニタの境界上にウィンドウを配置することがしばしばあり、この特性には不便を感じている。

ウィンドウの整列ができない

Windowsであれば画面端にウィンドウを持っていくと左右二分割や、画面四分割などウィンドウを整列し、ウィンドウの境界をドラッグするとリサイズもきれいにできるが、macにその機能はなさそうだった。

タスクバーがない

macにはタスクバーがなく、Dockのみがある。Windowsのタスクバーとの違いは、起動していないアプリケーションも並んでいることだ。

Windowsのタスクバーはピン止めをすべて外すことで、起動しているアプリケーションだけにできるため、作業に集中できるがmacのDockは余計なアイコンが多くあり目が余計に滑って不便に感じた。別にmacのDockも余計なものは消せるのだが、スタートメニューが存在しないし、そもそもDockはタスクバーではないし、Finderやドロワー、ごみ箱をここから消すのは、アクセス手段が失われる懸念もあり、やれていなかった。

アプリケーションメニューがウィンドウ上に存在しない

macではアプリケーションのメニューは画面最上部のバーに固定で出ている。この関係でマウスでメニューを操作しようとするとウィンドウの位置やサイズによってはカーソルの移動距離が長く手間であるし、直感的でないと感じた。

私はこれを作業効率の観点から好ましく思っておらず、Linuxのデスクトップ環境でもGNOMEを避けている。

恐らくmacでは一画面に一ウィンドウを最大化状態で保持して操作するのが前提の哲学としてあるのかもしれない。

時計が画面右上にある

首が疲れるので右下にあってほしい。macユーザーは首を持ち上げるのが、苦ではないのかもしれない。

キーボードの互換性がない

CtrlやAltがmacに存在しないことは知っていたが、他にも違いがあった。

例えばHomeやEndについてはアプリケーションによって振る舞いが異なっていた。Windowsであれば標準ではスクロールバーを一番上や下に持っていったりCtrlキーとのコンビネーションでファイルの先頭や一番下に移動させることが一般的だが、macでは恐らくアプリケーションごとに異なる振る舞いを示し、統一した振る舞いはなさそうだ。

何より先頭や末尾に移動する機能がないのは面倒だった。

これはKarabiner-Elementsを導入することで多少はマシになるが、多少マシになる程度だ。何故ならKarabiner-Elementsはアプリケーション単位にキーバインドを設定しないとまともに機能しないからだ。利用するすべてのアプリケーションのキーバインドを設定するというのは気の遠くなるような作業で、事実上役に立たないといっても過言ではないだろう。

他にもVSCodeのターミナルでCtrl+CやCtrl+Zが効かないなど、枚挙に暇がなく、遭遇するたびに一々調べるのも大変なので、今のところはターミナルを殺すことで対処している。

ログイン時にキーボードレイアウトがランダムに変わる

スリープから復帰したときにキーボードレイアウトがUSになっていたりABCになっていたりQWERTZになっていたりした。

なぜ不規則に変わるのかは一切把握できていないが、このせいでログイン時にパスワードの入力を誤ることが多く、非常にストレスになっている。

ログイン時に本体と外部のキーボードの配列が恐らく異なる

ログイン時にどちらか片方のキーボードでしかパスワードが正しく入力できないことがあるため、恐らく個別にキーレイアウトが設定されている。

前項のランダム変化と合わさり、一体何の意図があってこうしているのかさっぱり理解できない。ユーザーが自分の意思で個別に変更しているのならわかるが、一般的に複数のキーボードを繋ぎ、すべてのレイアウトをバラバラにしたいケースは、そう多くないと思う。

ログイン画面のパスワードマスクが外せない

前の項に付随する内容だが、パスワードマスクが外せないので変なレイアウトになっていた時にキーボードと入力内容を対比して、それに応じて打鍵するキーを修正するといった操作ができない。

ログイン画面でキーボードレイアウトの変更メニューが通知バナーに隠される

ログイン画面の右上にキーボードレイアウトの変更メニューがあるが、通知がたまっているとこれが隠れて見えなくなる。こうなると半分エスパーで操作する必要があり、かなり辛い。このUI設計した人の思想を私には理解できそうにない。

通知バナーが邪魔

macでは画面上に無限に通知バナーが溜まり、これを削除するには一つ一つ丁寧に小さなバツボタンを押していくしかない。Slackの通知などで画面からはみ出てバナーがあると、ひたすら押し続ける必要がある。まるで何かの修行をしている気分だ。

Windowsの場合は画面を一列丸ごと通知バナーが埋めることはないし、タスクバーの時計をクリックしたらバナーはすべて消え、通知一覧に移動する。そして通知一覧から読み直すこともできる。

またmacでは通知は標準で消えないようにみえるが、Windowsでは通知は時間経過で消えるのが一般的で、常に画面を占有することはない。

私は仕事をしている中でmacを使っている人が通知を見逃すことが多いのをしばしば聞くのだが、邪魔くさくて消してたら見過ごしたとか、そういうことが多いのではないかと考えている。

Windowsを使っていて通知を見逃すというのは個人的に通知バナーをミスクリックして消したくらいしか経験がないが、macを使っていると通知バナーが画面の外に流れて消えたり、画面を占有するのもあり、見逃すことが増えたと感じる。

参考までにClaude Opus 4.6に聞いて見たところ、macOSの通知には「バナー」スタイルと「アラート」スタイルがあり、バナーに設定すれば数秒で自動的に消えること、また通知センターではグループ単位での一括削除も可能であることだったが、そこを気にしないといけない時点で個人的にはどうかと思った。少なくともWindowsでは気にする必要のない部分だ。

スクショを自動でクリップボードに飛ばしてくれない

スクショを撮ったら毎回画面右下に小さなスクリーンショット画像が出るので、これをクリックして出てくるメニューでクリップボードに飛ばすか、ファイルに落とすかを選択しないといけない。すごく面倒くさい。

そもそも毎回画面右下に小さなスクリーンショット画像が出ることに気が付くまでに時間を要した。

UbuntuであればGNOMEでもクリップボードに飛ばされたと思うし、Xfceでも標準ではクリックボードに行くので、違和感は感じない部分だ。

スタートメニューがない

macにはスタートメニューがなく、GNOMEやAndroidなどにもあるアプリドロワーがあるのみである。全画面占有する割に巨大なアイコンが並び、情報量が少なく、アプリケーションを探すのが極めて面倒くさい。

またピン止めも恐らくできないので、使い勝手が悪い。

IMEの挙動が難しい

標準のIMEが非常に使えないのでGoogle IMEを入れて、標準を殺してみるものの、時折標準のIMEに復帰している気配がしており、難しさを感じることがある。

あとIMEの切り替えをKarabiner-Elementsを使って全角半角キーで実現しているのだが、この動作にも違和感があり、困難を覚えがちだ。

キャレットの移動が遅い

エディタやブラウザのURLバー、Slackの入力欄など、どこであってもキャラットの移動速度が驚くほど遅い。非常にガタガタしながらキャレットが移動するのを眺めていると何とも言えない気持ちになる。

かつてメモリがしょぼいWindows XPで重いワードを開いた時はこんな感じだったかもしれないが、なかなかない光景だ。ましてや使っているのがM4 Mac Proであるから、余計にそう思う。

8000x8000くらいのJPEGをSlack上で拡大してドラッグするとすごいガタつく

M4 Mac ProはApple M4 Proを搭載しており、非常にスペックが高いはずである。しかし、高々8000x8000くらいのJPEGをSlack上で拡大してドラッグするだけで非常にガタガタとカクついた。

参考までにDell Latitude 5430でCPUがIntel Core i7-1255U、メモリが32GBのWindows 11環境では、これは起きなかった。

先ほどのキャレットの件といい、macはグラフィック処理が苦手なのかもしれない。

ウィンドウの最小化、拡大縮小、閉じるボタンが非常に小さく、Windowsの逆にある

押させる気がないんじゃないかと思うほど小さく、大変使いづらかった。またWindowsと比べた時、左右逆にあるのも不便に感じた。

記憶があやふやだが、GNOMEではWindowsと同じく右側にあり、サイズも押しやすかった気はする。

都度都度、管理者権限を要求される

例えばAltTabなどのアップデートがあった時、毎回管理者権限を要求されるのがうっとおしいし、Rancher Desktopも毎回管理者権限を要求してくるのでうっとおしい。

ウィンドウの管理がしづらいのと相成って、これらの権限要求ダイアログが、アプリケーションウィンドウとセットでOS起動時に重なって出てくると、とても面倒くさいと感じる。

Finderで隠しファイルを見るのが手間

Command+Shift+.の同時押しで隠しファイルが出せるが、手間である。

以下のコマンドを流せば恒久的に表示できるが、GUIで設定できないのは不親切に思う。

defaults write com.apple.finder AppleShowAllFiles -bool true
killall Finder

フォルダを開いた時のアイコンの並びがぐちゃぐちゃ

Finderでフォルダにファイルなどをドラッグしたときに、ドラッグした位置に保存されるため、非常にぐちゃぐちゃになる。

常に均等整列することも可能らしいが、少なくとも標準ではそうなっていない。

OSを落とすのがめんどくさい

OSを落とそうとしたときにアプリケーションが生きていると、一々都度都度落とすように言われるのが非常に面倒くさい。

Windowsなら強制終了ボタン的なのを一度押せば全スルー出来るし、そもそも基本出ない印象だが、macではアプリケーション毎にこれが出てきて、ボタンを押し落とし、また出てきて落としとか、面倒なので終了メニューを何度も出して連打して落としたりしている。面倒くさい。

Homebrewはmacの標準パッケージマネージャではない

mac関連の記事でアプリケーションの導入に出てくるHomebrew(brew)だが、なんと標準ではなく、サードパーティである。

これまでAltTabやKarabiner-Elementsといったサードパーティが出てきたが、またサードパーティだ。MicrosoftがサードパーティーソフトウェアをOSに取り入れているのと比べるとAppleの動きはまるで対照的だと感じる。

きっちりしてそうな様相に反して、アプリケーションが全く入っていない

macは標準でzshをシェルとしており、ターミナルもついていて、お金を払って買うものだし、きっと充実した環境があるだろうと思えば、全くなかった。

びっくりするほど何も入っていないので、入れてやる必要があった。

確か一番最初にこんな感じで入れたと思うが、他にもPerlとか色々入れたほうがより便利になるだろう。

brew install coreutils
brew install diffutils
brew install ed
brew install findutils
brew install gawk
brew install gnu-sed
brew install gnu-tar
brew install grep
brew install gzip

ACアダプタの整流器とコンセントプラグが合体している

これはOSとしてのmacとは関係ないことだが、macはハードウェアとソフトウェアが不可分であるところもあるので書く。

M4 Mac Proでは写真のようにコンセントプラグに大きな整流器が合体していた。

これは他のコンセントに干渉する上、自重で脱落しやすく、個人的には好ましく思っていない。写真では干渉を避けるためにコーナータップを生やして回避している。

macの操作感を少しでもWindowsに寄せるTips

Alt+Tabの実現

AltTabを入れる。

矩形スクショをWindowsのように撮れるようにする

Command+Shift+4で任意の場所に矩形を作り、スクリーンショットを撮れる。

クリップボードに送るには、スクリーンショットを撮影すると右下にサムネイルが出るので、そこをクリックして操作するのでひと手間かかる。

Win+Shift+Sで起動させるにはKarabiner-ElementsのComplex Modificationsに以下の設定を書けば実現できる。

{
    "description": "Right Command + Shift + S to Command + Shift + 4 (Screenshot Tool)",
    "manipulators": [
        {
            "from": {
                "key_code": "s",
                "modifiers": { "mandatory": ["left_command", "shift"] }
            },
            "to": [
                {
                    "key_code": "4",
                    "modifiers": ["left_command", "left_shift"]
                }
            ],
            "type": "basic"
        }
    ]
},

JISキーボードの全角/半角キーをIMEのON/OFF切り替えキーに変換

Win+Shift+Sで起動させるにはKarabiner-ElementsのComplex Modificationsに以下の設定を書く。

{
    "description": "JISキーボードの全角/半角キーをIMEのON/OFF切り替えキーに変換",
    "manipulators": [
        {
            "conditions": [
                {
                    "input_sources": [{ "language": "en" }],
                    "type": "input_source_if"
                }
            ],
            "from": { "key_code": "grave_accent_and_tilde" },
            "to": [{ "key_code": "japanese_kana" }],
            "type": "basic"
        },
        {
            "conditions": [
                {
                    "input_sources": [{ "language": "ja" }],
                    "type": "input_source_if"
                }
            ],
            "from": { "key_code": "grave_accent_and_tilde" },
            "to": [{ "key_code": "japanese_eisuu" }],
            "type": "basic"
        }
    ]
},

VSCodeでCtrl+@を押したときにターミナルが出るようにする

Karabiner-ElementsのComplex Modificationsに以下の設定を書く。

{
    "description": "VS Codeが前面にあるとき、左Control+@をターミナルトグルとして機能させる",
    "manipulators": [
        {
            "conditions": [
                {
                    "bundle_identifiers": [
                        "^com\\.microsoft\\.VSCode$"
                    ],
                    "type": "frontmost_application_if"
                }
            ],
            "from": {
                "key_code": "open_bracket",
                "modifiers": { "mandatory": ["left_command"] }
            },
            "to": [
                {
                    "key_code": "j",
                    "modifiers": ["left_command"]
                }
            ],
            "type": "basic"
        }
    ]
},

OCR機能

スクショ撮影→右下のサムネイルクリック→拡大画像ウィンドウを表示で、画像中の文字列をドラッグすると文字を取れるようになっている。

そこまで多用したわけではないが、精度は実用上問題なさそうに感じた。

Windowsのように画面を拡張したマルチモニタにする

システム設定→ディスプレイ

メインディスプレイを切り替え、内蔵ディスプレイはそれのミラーリングにする(OFF にはできない)

またこの時に「ディスプレイのミラーリング中または共有中に通知を許可」をONにしておくと、外部モニタで通知が見れるようになる。OFFの場合、本体モニタ側に通知が出る。

Dockを隠す

システム設定→デスクトップとDockを開き、適当に縮小して自動的に非表示になるように設定。アニメーション系の邪魔なものもOFFにしておく。

ユーザーディレクトリを開く

Finderでデスクトップを表示し、アドレスバー的な部分を右クリックすると出てくる。

面倒なのでサイドバーにD&Dしてピン留めしておくと良い。

英字の先頭を大文字にしない

システム設定→キーボードを開きテキスト入力セクションにある「入力ソース」の「編集」を開き、すべての入力ソースで「文頭を自動的に大文字にする」をOFFにする。

IMEをWindows風にする

システム設定→キーボードを開きテキスト入力セクションにある「入力ソース」の「編集」を開き、各入力ソースでWindows風のキー操作にチェックを入れる。

UIの隙間を狭める

UIにマージンがやたら多いので埋める。

システム設定→ディスプレイ→スペースを拡大を選択。

あとがき

同僚にも幾らか聞いたのだが、なんかみんな力業でやっているようで、あまり参考にならなかった。ひょっとするとmacにはWindowsの様な定型的なお作法がないのかもしれない。わからない。

他にもいくつかの会社でmacの操作方法について聞ける機会を得たものの、Windows利用経験がない人だと「その操作をする発想がなかった」レベルの話をされて、割と戸惑うので、恐らくmacではWindowsと思想そのものが根底から違うのだと思う。

少なくとも私はmacの思想に相容れられないほどにWindowsを使い込みすぎており、30年来の利用によりWindows操作に特化しすぎているため、macに習熟するのは無理があるなと思った。

LinuxやAndroidは違和感なく使えるが、iOS(iPhone)やmacは操作に難儀し、文字入力さえ満足にできない次元なので、恐らくAppleの哲学に対して、私の相性が根本的に良くないのだと思う。

更新日:
投稿日:

Edgeのバージョンが145.0.3800.70になったらダウンロード履歴からファイルをD&Dできなくなり、とても不便だったのでEdgeのバージョンを145.0.3800.65にロールバックして固定することにした。

その時にやったことを残しておく。

やったこと

手順を間違えるとEdgeをアンインストールする羽目になるので絶対に前後させてはいけない。もしも前後させるとEdgeの設定全部やり直しになる。

事前に拡張機能も含め、Edgeの全設定のバックアップをしておくとよいだろう。具体的にはプロファイルフォルダを丸ごとどっかにバックアップしておくとよいと思われる。

具体的には%USERPROFILE%\AppData\Local\Microsoft\Edge\User DataDefaultとかProfile 1みたいなフォルダに設定が格納されているので、これをバックアップしてやればよい筈だが、検証はしていない。

1. Edgeのアップデートができないようにファイアーウォールを構成するで阻止する

次のコマンドを管理者権限のコマンドプロンプトに流す

netsh advfirewall firewall add rule name="Disable Edge Updates" dir=out action=block program="C:\Program Files (x86)\Microsoft\EdgeUpdate\MicrosoftEdgeUpdate.exe"

2. 古いバージョンのEdgeを入手してインストールする

  1. ビジネス向け Microsoft Edge のダウンロードとデプロイの画面中ほどにある「古いバージョンの Edge をお探しですか?」から、ロールバックしたいバージョンを選択し、ダウンロードする
  2. ダウンロードしたインストーラーに対し、次のコマンドを管理者権限のコマンドプロンプトに流す
    msiexec /I MicrosoftEdgeEnterpriseX64.msi ALLOWDOWNGRADE=1
    

トラブルシューティング

手順を間違えてしまいEdgeを最新化してしまった

次のコマンドを管理者権限のコマンドプロンプトに流せば再インストールできるようになるはずだが、Edgeそのものもアインインストールされてしまい設定がすべて吹き飛ぶ可能性がある。特に拡張機能の複雑な設定が吹き飛ぶと致命的なので絶対にバックアップしておこう。

msiexec /x MicrosoftEdgeEnterpriseX64.msi

あとがき

Microsoft公式のEdge の更新制御には、レジストリのHKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\EdgeUpdateにREG_DWORD値としてUpdateDefaultを追加し、値として0を設定することでアップデートされなくなるとあったが、私の場合これは機能しなかった。

恐らくEdgeのアップデートを止める唯一の方法はアップデーターを殺すことである。

Edge の更新の流れについてを読む限り、Windows UpdateでEdgeが更新されることは基本的にないらしいので、安心できる。

当たり前だがこのまま放置していると、セキュリティ面や履歴の同期の仕様変更による機能不全などで、そのうち使えなくなる日が来そうなので、その時はまた考えたい。

2026-03-01追記

Microsoft Edge の既知の問題 | Microsoft Learnによると、ダウンロード履歴からファイルをD&Dできないのはバグらしいので、そのうち治るかも?

更新日:
投稿日:

前の記事value-domain-dns-utilを作り、かつてのvalue-domain-dns-cert-register (vddcr)を焼き直したことを書いたが、あれからいくらか直し、学びも得たので、その記録として残す。

なお、今回行った調査によりvalue-domain-dns-utilのvd-dcr.plでは、複数ドメイン指定(-d hoge.example.com -d fuga.example.com)や、ワイルドカードドメイン指定(-d example.com -d *.example.com)が動作することを確認している。

certbotがauth-hookに渡す環境変数

ドメインを一つだけ指定したとき

--manual-auth-hookに指定したスクリプトが一回だけ走る。

入力

sudo certbot certonly --manual -n --preferred-challenges dns --agree-tos -m postmaster@example.com --manual-auth-hook "/path/to/script" -d hoge.example.com

環境変数

変数名
CERTBOT_DOMAIN hoge.example.com
CERTBOT_VALIDATION xxxxx
CERTBOT_ALL_DOMAINS hoge.example.com

ドメインを複数指定したとき

指定した回数分、--manual-auth-hookに指定したスクリプトが走る。

入力

sudo certbot certonly --manual -n --preferred-challenges dns --agree-tos -m postmaster@example.com --manual-auth-hook "/path/to/script" -d hoge.example.com -d fuga.example.com

環境変数

走行一回目

変数名
CERTBOT_DOMAIN hoge.example.com
CERTBOT_VALIDATION xxxxx
CERTBOT_ALL_DOMAINS hoge.example.com,fuga.example.com

走行二回目

変数名
CERTBOT_DOMAIN hoge.example.com
CERTBOT_VALIDATION yyyyy
CERTBOT_ALL_DOMAINS hoge.example.com,fuga.example.com

ワイルドカードドメインを指定したとき

ドメインを複数指定したときと似た挙動をするが、CERTBOT_DOMAINは二回とも同じものが入り、CERTBOT_ALL_DOMAINSも同じドメインが二個入り、CERTBOT_VALIDATIONだけ異なる値になる。

入力

sudo certbot certonly --manual -n --preferred-challenges dns --agree-tos -m postmaster@example.com --manual-auth-hook "/path/to/script" -d example.com -d *.example.com

環境変数

走行一回目

変数名
CERTBOT_DOMAIN example.com
CERTBOT_VALIDATION xxxxx
CERTBOT_ALL_DOMAINS example.com,example.com

走行二回目

変数名
CERTBOT_DOMAIN example.com
CERTBOT_VALIDATION yyyyy
CERTBOT_ALL_DOMAINS example.com,example.com

TXTレコードに永続性は不要で、証明書を作るときにだけあればよいということが分かった

私は長らくDNSレコードにtxt _acme-challenge.bts "gfj9Xq...Rg85nM"のような値が存在し続けることに意味があると考えていたが、実際にはそうではなかった。

Challenge Types - Let's EncryptのDNS-01 challengeの仕様には次のようにある。

原文

After Let’s Encrypt gives your ACME client a token, your client will create a TXT record derived from that token and your account key, and put that record at _acme-challenge.<YOUR_DOMAIN>. Then Let’s Encrypt will query the DNS system for that record. If it finds a match, you can proceed to issue a certificate!

日本語訳

Let’s EncryptがACMEクライアントにトークンを渡すと、クライアントはそのトークンとアカウントキーから派生したTXTレコードを作成し、_acme-challenge.<YOUR_DOMAIN>に格納します。その後、Let's EncryptはDNSシステムにそのレコードを照会します。一致するレコードが見つかった場合、証明書の発行に進むことができます。

つまり、DNS-01 challengeにおけるTXTレコードはドメインの所有権を確認するための一時的な検証値に過ぎず、証明書の発行が完了すれば不要になる。

この仕様を知ったことで、ワイルドカードドメイン指定時の懸念が解消された。ワイルドカードでは_acme-challenge.example.comに対して--manual-auth-hookに指定したスクリプトが二度走り、そのままでは二回目で一回目のTXTレコードが上書きされるが、永続する必要がないなら問題にならない。

以前はワイルドカードドメインに対してTXTレコードを二個維持する必要があると考え、「_acme-challengeのTXTレコードがDNS上に二行以上あればワイルドカード用とみなして全削除してから追加、二行未満なら単純に追加」という判別ロジックを検討していた。

しかしこの方法では、前回のレコードが一行だけ残っている場合に破綻する。ワイルドカード指定では--manual-auth-hookに指定したスクリプトが二回走るので、次のようなことが起きる。

  1. 一回目:既存レコードは一行(前回の残り)なので「二行未満→追加」が選ばれ、計二行になる
  2. 二回目:既存レコードが二行になったため「二行以上→全削除して追加」が選ばれ、一回目で登録したばかりのレコードごと消えてしまう

このように既存レコード数という外部状態に依存した判別では、初期状態の違いによって正しく動かないケースが生じ、運用でカバーせざるを得なかった。

だが、TXTレコードに永続性は不要で、証明書を作るときにだけあればよいということが分かり、結果としてレコードを永続させる必要がないと分かったことで、このような判別ロジック自体が不要になった。

これによって例外処理をするスクリプトの作成も、それを動かすための運用も考慮しなくてよくなり、vd-dcr.plはシンプルな状態に保てるということが分かったので、とても良かったし、何よりcertbotへの理解が深まったのもよかった。

余談だがCertbotの振る舞いはRFC 8555に定められており、Automatic Certificate Management Environment (ACME)、つまり自動証明書管理環境とされているようだ。有志による日本語訳も存在し、日本語で読むこともできる

DNS-01 challengeの運用負荷を減らす、新しいDNS-PERSIST-01という方式の登場について

DNS-01 challengeについて調べる中で、DNS-PERSIST-01という新しいACMEチャレンジタイプの存在を知った。これはDNS-01の代替ではなく、DNS-01と併存する別の選択肢として提案されているものだ。

これはまだドラフトだが、今後導入される予定のDNSを利用した証明書の発行方式で、Let's Encryptでは2026年Q2に本番導入が予定されている。

DNS-PERSIST-01の利点は一度DNSに検証文字列を書けば、以降はDNSレコードを触らなくてよいというものである。DNSのAPIを都度叩かなくてよいため、運用面で非常に便利だといえる。当然、セキュリティ面では劣化がある。

欠点はACMEアカウント鍵が漏洩すると、第三者に証明書を発行されるリスクがあることだ。DNS-01 challengeでは更新の都度、ランダムな検証文字列を設定して検証するのでこの問題は起きない。

要するにDNSレコードを弄らない代わりに鍵を使う方式と、DNSレコードを弄る代わりに盗まれる物がない方式の二つになるということだ。

DNS-PERSIST-01でもセキュリティのために、ACMEアカウント鍵に有効期限を設けられるようだが、それだと本末転倒にも思う。勿論、そういうケースが役に立つ場合もあるだろうが、運用は大変そうだ。

nginxからApache2のバーチャルホストにいい感じにリバプロする方法の続きで、nginxからApache2にリバースプロキシされた時にクライアントのIPを拾う設定の方法について。

確認環境

Env Ver
OS Ubuntu 24.04.3 LTS
nginx 1.26.1
Apache2 2.4.58

やりたいこと

Apache2で動いているCGIのREMOTE_ADDRからクライアントIPを取れるようにする。

nginxからApache2のバーチャルホストにいい感じにリバプロする方法ではApache2側でREMOTE_ADDRを取得しようとするとnginxのIPになってしまうため、これを回避する方法。

前提条件

  1. nginxからApache2へのリバースプロキシをする時に、真のクライアントIPをX-Real-IPヘッダーに入れていること。
    proxy_set_header X-Real-IP $remote_addr;
    
  2. nginxとApacheが動いているマシンが同じ
  3. IPv6を使っている

やること

# remoteipモジュールの有効化
sudo a2enmod remoteip
# ::1からのHTTPリクエストを信頼しX-Real-IPをREMOTE_ADDRとして解釈する
cat <<'EOF' | sudo tee /etc/apache2/conf-available/remoteip.conf
RemoteIPHeader X-Real-IP
RemoteIPInternalProxy ::1
EOF
# 設定の有効化
sudo a2enconf remoteip
# 設定の反映
sudo systemctl restart apache2

意味合いの解説

sudo a2enmod remoteip

remoteipモジュールの有効化をしている。

逆はa2dismodで無効化出来るっぽい。

RemoteIPHeader <header-field>

ここで指定したHTTPヘッダーをクライアントのIPアドレス(useragent IP address)として扱うようにする。

例えばRemoteIPHeader X-Forwarded-ForとすればX-Forwarded-ForをクライアントIPとして扱える。

この設定だけだと問答無用で信頼してしまうため、本来と異なる経路で攻撃を受けた時に偽装されたヘッダをクライアントIPとして解釈するリスクがある。そのため、次項の設定も行う。

参考:mod_remoteip - Apache HTTP Server Version 2.4

RemoteIPInternalProxy <proxy-ip|proxy-ip/subnet|hostname ...>

RemoteIPHeader単品では前段のnginxを無視してApache2へ直にアクセスされたときに偽のX-Real-IPなどが来ていると、偽のIPが取れてしまうので、これを回避する仕組み。

RemoteIPInternalProxy ::1のように指定することで、そのIPから来たRemoteIPHeaderを信頼する。異なるIPからリクエストが来た場合は、RemoteIPHeaderを無視して、そのクライアントのIPが設定される。

RemoteIPTrustedProxyでも同じことができるのだが、違いはよくわかっていない。一応内部用と外部用で分かれているらしいが、RemoteIPTrustedProxy ::1でも期待通り機能したので謎。

公式ドキュメントではIPv4アドレスが指定されているので、恐らくIPv4でも行けると思うが確認していない。

参考:mod_remoteip - Apache HTTP Server Version 2.4

sudo a2enconf remoteip

作成した設定の有効化を行う。これを行っていない場合、設定は反映されない。

やっていることは/etc/apache2/conf-available/にある設定ファイルのシンボリックリンクを/etc/apache2/conf-enabled/に張っているだけだと思われる。

標準では/etc/apache2/apache2.confIncludeOptional conf-enabled/*.confを指定しているため、これで設定が読み込まれるようになる。

逆はa2disconfで無効化できる。

あとがき

ここまで書いたところで/etc/apache2/sites-available//etc/apache2/sites-enabled/の違いに気が付いた。これも多分有効無効を切り替えるもので、sites-enabled側に設定を直書きするのは誤っているのだろう、きっと。