春のdotfiles大整理プロジェクト2026
何?
昔はansibleをやろうとした→作業量が多くて挫折した→nixにした→ビルドのメンテナンスが辛すぎて挫折した→ シンプルなシェルスクリプト + symlik の構成に落ち着いていた
2026年、さすがにAgentic Codingが無視できなくなってきた
エーアイさんのためのSandboxを、楽ちんに作りたい
dotfilesが、単なる個人の設定の記録から、気合の入った構成管理に様変わりしつつある
→ 構成管理ツールをちゃんと入れて、CI/CDしたい
（個人）筑波大学を卒業して、就職する→ 仕事のパソコンの設定をしないといけないので、忙しくなる前にまともな環境を作っておきたい コンセプト
エーアイさんを最大限活かすための環境を作ること
環境づくりのためにもエーアイさんにいっぱい働いてもらうこと
nixでやるような厳密な構成管理というよりも、 sandboxとメンテナンス性 を優先する
エーアイが環境を汚す時代なので、さっさと捨てることが前提のライフサイクルを見据える
ホストマシンよりも、VMをfirtst-class targetとして位置付ける
CI/CDをやる
とにかくlintとテスト
やったこと
0. branch を切る develop/major-revision-2026-spring
「dotfiles盆栽にそんなに本気になっても」と思っていたのでこれまではmainに直接pushしていたが、Coding AgentにPRを立ててもらったり、Code Reviewしてもらう前提なら、ちゃんとbranch ruleを決めないとな、と思った
1. Brewfileの整理
brew bundle dump してから、エーアイさん(Gemini/ Claude Sonnet 4.6 via OpenCode) に「見るからにライブラリっぽいやつとか、dependencyとして入っているだけっぽいformulaの行を消して」と指示 code: prompt
@Brewfileを メンテナンスしたい。Brewfileに入っているものが
1. 自分が直接入れたもの
2. dependencyとして入ってきてしまったもの
3. もはやoutdatedであるなどの理由で必要ないもの
のどれかを推定して、1だけがlistされている状態にして。
判断に迷ったら、私に選択を求めること。
2. AGENTS.mdを書く
プロジェクトの趣旨
よくあるタスク
ルール
コメントとかは英語で書いてね、とか
サポートすべき環境 (MacOSとUbuntu/Debianの aarch64とx86_64)
3. 既存dotfilesの掃除
alacrittyに移行したため、高校時代から使っていなかった.hyper.js の設定などの、余計な残存ファイルを削除
量が増える前にできる限り減らしておくことで、コンテキストの浪費とcoding agentのconfuseを防ぐ意図
3. 小さな構成を作る
2025年の(某|忘)年会でazrsh センパイから「mitamaeにした」という話を聞いていて、気になっていたのでmitamaeにした 一応、事前にGemini 3と壁打ちをして、構成管理に何を使うかを考えておいた
ansible = リモートで大量に構成するなら良いが、localhostを設定するにはdependencyが重い (Python)
itamae, chef = RubyやGemを管理せねばならなくて辛い
小さなsetup.sh で、最小限のセットアップと、mitamaeのダウンロードなどを行うようにした
ubuntu を元にしたDockerfileを作り、デバッグしながら進めた
↑ これは結構良かった.
4. Brewfileから、まとめてたくさんのCookbookを作ってもらう (エーアイさん. Claude Code)
いっぱいできてくる
事前に、以下のようなInstructionを作っておいて、ある程度おかしな挙動を抑制しておいたが、それでもこの先で何度もdebugが必要だった
code: AGENTS.mdから抜粋
## Common Tasks
### Creating new role
// TBD
## Adding new package
1. Create @mitamae/cookbooks/<package-name> directory.
2. Create default.rb file in the directory and add the installation logic for the package.
- If the package is available in the system package manager, use package resource to install it.
- If the package is not available in the system package manager, use execute resource to run the installation command (e.g., using curl or wget to download and install the package).
- Make sure to handle platform-specific installation logic if necessary (e.g., different commands for MacOS and Debian-based Linux).
- Take care of multiple platforms. Both aarch64 and x86_64. Both debian/ubundu and macos.
- Use not_if or only_if guards to prevent unnecessary installations if the package is already installed.
- If the package requires associated configuration files, create those inside the file directory of each cookbook.
- Always use uv tool than pip to manage python-based tools.
- Be aware that mItamae is based on mruby. It does **NOT** support full ruby features. (e.g. Use ENV["HOME"] instead of Dir.home )
3. Add the package to the appropriate role(s) in roles/ directory by adding include_recipe statement in the role's default.rb file.
↑この辺の内容は、初めは AGENTS.md に書いておいて、このくらい太ってきたらskillsに切り出すのがいいと思う
5. はじめは、最大のコンテナ pine (松) を完全にビルドできるようにするところから始めた
6. 松のビルドが終わったら、今度はそれより小さいbamboo (竹) を作り、最後に plum (梅) を作った
7. GitHub Actionsも整理した
Apple Siliconのホストマシンで開発していたので、GitHub Actionsでbuildxを動かす事で初めてx86_64での挙動が確認できた
8. 3つのvariantのコンテナイメージが、CIでビルドできてghcr.ioから試せることが確認できたら、こんどはmacOS向けのroleを作った
9. MacOS向けのroleも、CIする
昔なら、ホスト機で実行して「中途半端にエディタが壊れた」というようなことがありえたが、今ながGitHub Actionsで runs-on: macos-latestを使ってまっさらなマシンから再構成するCIを回し放題(Public Repoなら)
うれしい！
10. リファクタリング
パッケージマネージャごとなどで、custom_resources.rb にカスタムリソースを定義することで、ボイラープレートをかなり削減できる
LXCをビルドするGitHub Actionsのworkflowを追加した
orasを使って、tarをOCIコンテナとしてghcr.ioにアップロード → mergeが終わって、バージョン番号がちゃんと管理できるようになれば、GitHub Releasesに置いておくと良いと思う