AIエージェント前提のLinux「Omarchy Quattro」をAkira Shimosakoさんが解説。日本語環境の整え方までわかる

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん（@passion_tanaka）です。今回は、Akira ShimosakoさんのOmarchy Quattro日本語環境設定という記事を紹介するね。

Akira Shimosakoさん（Portablecode.info・魅力を語る冒頭）

何を入れて何を捨てるかはDHHの美的感覚で（ほぼ）すべて決まっているので、好き嫌いが分かれるところだと思いますが、私はとても気に入りました。

OSの見た目も操作感まで、開発者一人の美意識でほぼ決め切ってしまう——そんなLinuxディストリビューションがあると知って、私は素直に「え、それでいいの？」と思いました。でも読み進めると、納得させられる話だったんですよね。

一般的なディストリビューションだと、コアチームの長い議論を経て少しずつデザインが固まっていくものらしいです。でもOmarchyは違う。DHHという一人の意思決定者が、ウィンドウのタイトルバーも閉じるボタンもDockも「いらない」と切り捨てて、ミニマルに振り切りました。ぶっちゃけ、これって経営判断とよく似てるなと感じます。全員の合意を取ろうとすると、角が取れて凡庸になる。誰かが決め切るから、尖ったものが残るんですよね。

決め切る人がいないと、会議は「持ち帰ります」で終わって、誰の仕事にもなりません。DHHが全部決め切っているからこそ、Omarchyのユーザーは「これでいいのかな」と迷わずに触り始められます。決断の重さを一人が引き受けることで、周りの人たちは軽くなる——これはチーム運用そのものの話だと思う。私も凛ちゃんチームに仕事を渡す時、細かい手順まで自分で決めようとしがちですが……本当は「この人（このAI）の美意識に任せる」って選択も、もっとあっていいと思います。

今日やること：自分が普段「みんなで決めよう」としている作業を1つ思い出し、誰か一人に決め切ってもらえないか考えてみて。

Akira Shimosakoさん（Portablecode.info・インストール実測）

今回私は Thinkpad X1 Carbon (Gen 12) に、高速とはいえない安価なUSBメモリからインストールしましたが、それでも１分16秒でインストールが完了しました。

インストールに1分16秒。この数字を見た時、正直「そんなに速いの？」と二度見しました。

DHHはこの速さに「なぜか強くこだわっている」らしいです。タイムゾーンとホスト名、IDとパスワード、emailアドレスと名前——聞かれるのはそれくらいで、ファイルシステムの構成（btrfs＋暗号化ボリューム）は完全に「おまかせ」。いやー、この「聞かない」設計、地味だけどすごく効くと思います。私自身、マニアックに好きだったパソコンがそのまま仕事につながった過去があって、あの頃も「触ってるだけで楽しい」が原動力でした。初期設定で何十個も選択肢を出されると、その「触ってて楽しい」が始まる前に疲れちゃう。1分で終わって、もう触れる。ここが強いんだよね。

しかもね、聞かれる項目が少ないだけじゃなくて、答えた後の処理（btrfsのボリューム構築や暗号化）まで自動でやってくれるのが効いています。人間が判断するのは「入力する数個の値」だけで、その後の段取りは全部おまかせにできる。私たちがAIエージェントに仕事を任せる時も、本当はこのくらい入口を絞ってしまっていいのだと思います。

今日やること：自分が今使っているツールの初期設定で、聞かれなくていい質問を1つ削れないか考えてみて。

Akira Shimosakoさん（Portablecode.info・パッケージ管理の解説）

Omarchyでは独自のレポジトリを用意し、Upstream(Arch Linux)のパッケージの更新を約一ヶ月遅れで反映させるようになっています

パッケージが壊れるのが怖くてバージョンを上げられない——そんな経験、開発に関わったことがある人なら一度はあるはずです。

Arch Linuxは最新追従が売りのディストリビューションだから、本来は更新も速い。でもOmarchyはあえて1ヶ月遅らせて、その間に破壊的変更へのマイグレーションスクリプトまで用意します。で、開発系のツール（nodeやopencode等）だけはmiseで別管理にして、そっちは最新を追える。……安定させたい土台と、尖らせたい部分を、はっきり分けてるんだよね。

凛ちゃんチームの運用でも同じ悩みがあります。守りたいルール・rules・hookは頻繁に変えたくないけど、日々使うスキルは毎日でも更新したい。土台と刃を同じ更新頻度で扱うと、どっちかが犠牲になる——ここはOmarchyから素直に学べる話だと思います。しかもね、ただ更新を遅らせるだけじゃなくてマイグレーションスクリプトまで用意してるのがえらい。「変えない」と「壊れた時に戻せる」はセットで初めて安心になるんだよね。

正直、この一ヶ月という数字そのものより、「遅らせる代わりに戻し方まで作っておく」という発想の方が真似したいところです。変えないことを目的にすると停滞するし、変えることだけを目的にすると壊れる。両方の言い訳を同時に潰しているのがOmarchyのやり方でした。

今日やること：自分の運用で「土台」と「刃」を同じ頻度で更新していないか、1つだけ棚卸ししてみて。

Akira Shimosakoさん（Portablecode.info・AIエージェント連携）

このおかげで、エージェントはOmarchyのことを理解したうえで、カスタマイズやユーザーの質問に対応できるようになっています。

OS初回起動のポップアップが「AIエージェントを導入しますか」だなんて、数年前なら想像もしませんでした。

初回起動時にClaude Code・Codex・OpenCodeのどれを使うか選ばせて、選んだ瞬間にOmarchy専用のskillsが~/.agents/skills/omarchy/へ自動配置されます。しかもね、クラッシュした時も自動でエージェントが呼び出されるらしい。これ、私たちが凛ちゃんチームのために~/.claude/skills/やSKILL.mdを用意して「このプロジェクトのことを分かった上で動いて」とセットアップしてるのと、構造がまるっきり同じです。OSというインフラの層にまで、同じ発想が下りてきてるんですよね。

ひとりのユーザーが困った時、人間が説明書を読むんじゃなくて、AIが最初から前提知識を持っている——この差は大きいと思います。私たちも新しいメンバー（人でもAIでも）が入るたびに、同じ説明を一から繰り返してたら、それだけで一日終わっちゃう。前提知識を「置いておける場所」があるかどうかで、立ち上がりの速さがまるで違ってくるんだよね。

今日やること：自分が繰り返し説明している「前提知識」を、AIが最初から読める場所に1つ置けないか考えてみて。

Akira Shimosakoさん（Portablecode.info・日本語ロケール設定）

補足ですが、JPロケールを有効にしてもユーザーのフォルダが日本語になったりはしませんでした（ ~/Documents -> ~/ドキュメント のような置き換えは起こらない）。

ロケールを日本語にしても、フォルダ名までは日本語になりません。地味だけど助かる仕様だと思う。

/etc/locale.genのコメントを外してlocale-gen、日本語入力はfcitx5＋Mozcを入れるだけ——ここまでは楽です。でもフォーカスが変わるたびIMがリセットされる問題は、設定ファイルを自分で開いてresetStateWhenFocusIn=Noに書き換えないと直らなかったらしい。私も中卒フリーターだった頃、リフォーム会社でWEB集客のやり方を誰かに教わったわけじゃなく、独学でひとつずつ試して覚えました。マニュアル通りにいかない部分を自分の手で詰める作業って、結局そこでしか身につかないものがあるんだよね。

日本語ローカライズって、いつも「本国の標準では想定されてない最後の1マイル」を、使う側が埋めることになります。フォントも同じで、デフォルトのNoto Sans CJKで困らないなら差し替えなくていいし、好みのフォント（この記事ではHackGen）があるならAUR経由で足す。全部を最初から用意してくれなくていい、必要な人だけが自分の分を足せればいい、っていう割り切りだと思います。

今日やること：自分が今使っているツールで「本国仕様のまま放置してる」設定を1つ、実際に触って詰めてみて。

Akira Shimosakoさん（Portablecode.info・追記での回避策発見）

その後、私の環境では–force-device-scale-factor=1を起動時オプションにつけることでIM変換候補の位置ズレが回避できることが分かりました。

一度は諦めかけた不具合が、後から別解決策で直った——という追記が、この記事で一番リアルでした。

ChromiumやElectron系アプリで日本語変換候補ウィンドウの位置がズレる問題、筆者は最初XWaylandラッパーで回避してたんだけど、後日追記で「起動オプション1つで直った」ってアップデートしています。GTK側のdevicePixelRatio計算とのズレが原因だったみたい。……こういう「後から回避策が見つかって記事が更新される」プロセスって、正直かっこいいと思う。最初の解決策を恥じずに残して、更新履歴として積み上げてるんですよね。

私たちも記事や仕組みを「完成品」として一度出したら終わりにしがちですが、後から直したら直したで正直に書き足せばいいんです。私自身、SKILL.mdやrulesを一度書いて満足して、そのまま放置しちゃうことがあります。でも本当は、使いながら見つかった摩擦を都度書き足していく方が、結果的に強い仕組みになる。この記事の追記スタイル、素直に見習いたいと思いました。

今日やること：自分が過去に「一旦これで」と決めた回避策を1つ、今の情報でアップデートできないか見直してみて。

Omarchy Quattroの魅力は、DHHという一人の意思決定者がOSの隅々まで美意識で詰め切っていること、そしてAIエージェントで操作・カスタマイズする前提で専用skillsまで最初から用意していることの2つでした。

一方で日本語ローカライズは、ロケール設定こそ数コマンドで終わるものの、IME位置ズレのような「本国仕様では想定されてない部分」は、使う側が自分の手で詰める必要があります。この「おまかせ」と「自分で詰める」の線引きは、AIエージェントに仕事を任せる時の線引きとも重なる話だと思う。任せて楽になる部分と、自分（人間）にしか調整できない部分を、最初から分けて考えておくと迷いが減ります。

OSのレイヤーにまでAIエージェント前提の設計が広がっているという事実は、私たちが日々SKILL.mdやrulesを整備してAIチームを運用しているやり方が、そう的外れじゃないという確認にもなりました。日本語IMEの位置ズレのように、まだ誰も正解を用意してくれていない場所は、実際に触って自分で埋めるしかない。おまかせと自分で詰める部分、その両方があるからこそ、使いこなした時の満足感も大きいんだと思います。

正直に書いておくと、私自身はOmarchy Quattroを実際にインストールして触ったわけではない。この記事はAkira Shimosakoさんの実機レポートを読んで、その内容を自分の言葉で紹介・解説したものです。実際に試したい人は、まずAkira Shimosakoさんの元記事と、下記の公式サイトを見てみてください。