raise：AI エージェント設定プロファイルのアトミック切り替え

名前は同音異義語だ。Raise。Rice-aise。どちらにせよ、認めるまで何ヶ月も静かに週ごとに自分を遅くしていた設定ドリフトの問題を解決したツールだ。

なぜ作ったか

コンサルタントをしている。それは異なるクライアント、異なるコードベース、異なるコンテキストウィンドウ、そして—重要なことに—異なるエージェント設定を意味する。インフラクライアント向けの Claude Code システムプロンプトは彼らの Terraform レイアウト、命名規則、PR プロセスを知る必要がある。プロダクトスタートアップ向けの同じものはまったく違って見える。Gemini CLI は別の設定フォーマットを持っている。Codex は別のものを持っている。OpenCode も別のものを持っている。Pi も別のものを持っている。

ある時点で数えた：4つのアクティブなクライアント案件のための17の AI コーディングツールをまたいでベスポークな設定ファイルを管理していた。プロファイルじゃなく—フラットファイルだ。クライアント間でコンテキストスイッチをする前にそれらを手動で編集していた、つまりルーティンに一つのツールを更新するのを忘れて、間違ったシステムプロンプトでセッションを開始して、実際にいたコンテキストに対して微妙に間違った出力を生成していた。

規律による修正—「もっと注意深くなるだけ」—は複利にならない。ツールによる修正が必要だった。

どう動くか

raise はシングルの Go バイナリだ。名前付きプロファイルのディレクトリを読む、各プロファイルは管理したいツールの設定場所をミラーするディレクトリツリーだ。raise use <profile> を実行すると、設定されたすべてのツールの場所をまたいでアトミックなシンボリックリンクスワップを同時に実行する。

アトミックがキーワードだ。この問題への古いアプローチ—「ファイルをコピーするシェルスクリプトを書く」—には失敗ウィンドウがある。スクリプトが途中でエラーになると、いくつかのツールは新しい設定を持ち、いくつかは古いものを持つハイブリッド状態にある。それはどちらのクリーンな状態よりも悪い。Raise はコピーの代わりにシンボリックリンクを使い、場所ごとに単一の rename(2) システムコールでシンボリックリンクのターゲットをスワップする、これは POSIX ファイルシステムで得られる最もアトミックな方法だ。

クレデンシャル保持は最も考えが必要だった部分だ。API キー、認証トークン、セッションクレデンシャルはシステムプロンプトとツール設定と同じ設定ディレクトリに住んでいる。それらはプロファイルと一緒にローテーションされたくない—マシンごとであって案件ごとじゃない。Raise はツールごとのクレデンシャルマニフェストを持っていて、クレデンシャルに隣接している設定キーまたはファイルセクションを特定してスワップから除外する。プロファイルはプレースホルダー付きのテンプレートを保存する；スワップレイヤーは書き込む前にローカルのクレデンシャルストアからそれらを埋める。

17のツールをサポートするには17の異なる設定規約を監査する必要があった。一部のツールは ~/.config/<tool>/config.json を使う。一部は ~/.toolrc を使う。一部はディレクトリを持ち、一部は単一ファイルを持ち、一部は両方を持ちそれぞれが別の意味を持つ。raise のツールレジストリはこれをツールごとにエンコードする—設定がどこに住んでいるか、フォーマットは何か、どのフィールドがクレデンシャルか。新しいツールの追加はレジストリへの3つの追加とテストフィクスチャだ。

面白いところ

驚いた点：サポートが最も難しかったツールはあまり知られていないものじゃなかった。Claude Code で、これは階層化された設定階層を持っている—グローバル設定、プロジェクト設定、ローカルオーバーライド—そしてどのレイヤーが勝つかについての意味のあるセマンティクス。プロジェクトレイヤーを上書きするプロファイルスワップは、プロジェクト固有の設定がチェックインされているリポジトリを壊す。Raise はレイヤーセマンティクスを認識して、触れるべきレイヤーだけに触れなければならない。

もう一つの驚きは、最初からこのツールを作ることへの抵抗をどれだけ感じたかだった。デベロッパーツールには「もっと規律があるべき」という強い引力がある。その直感は間違っている。規律は本当に判断を必要とするものに向けるもので；設定ファイル管理はそれらの一つじゃない。週に2回以上手作業で何かをやっていて、それが新しいことを何も教えてくれないなら、自動化するべきだ。例外なし。

名前は「エージェント出力の底上げ（floor を raise する）」というプロンプトエンジニアリングのコンセプトについての会話から来た。コンテキストに対して間違ったプロファイルはアクティブに底を下げる。Raise はそれをあるべき場所に保つ。

変えたいこと

クレデンシャルマニフェストは現在手動でメンテナンスされている。既存の設定ファイルを検査し、クレデンシャルの形をした値（API キーパターン、トークンフォーマット、ベアラー文字列）を特定し、自動的にマニフェストを提案するファーストランウィザードが欲しい。情報はそこにある；ただ読み取りパスといくつかのヒューリスティックが必要だ。

raise diff <profile-a> <profile-b> コマンドも欲しい。今はプロファイルディレクトリを自分で目で確認しなければならない。システムプロンプトの変更をツール設定の変更から別々にハイライトする構造化された diff はプロファイル監査をはるかに速くする、特に数週間クライアント案件に触れていなくて何を設定したか正確に覚えていないとき。

プロファイルフォーマットは現在ディレクトリベースで、柔軟だがポータブルじゃない。単一ファイルのプロファイルフォーマット—git リポジトリや gist 経由で共有できる TOML バンドルのようなもの—について考えていた、エージェント設定を実際のプロジェクトと一緒にバージョン管理できるように。それがこれを本当にマルチパーソンにする自然な次のステップだ。