AIコーディングエージェントについてのほとんどの言説は、それを一人勝ちのレース として組み立てる：Claude Code vs. Codex vs. Cursor vs. Gemini、チャンピオンを 選んで、Hacker Newsのスレッドで守れ。私の日常の現実はそれらを五つローテーション で動かすことだ — Claude Code、Codex CLI、Gemini CLI、PI、そしてOpenCode — それぞれ異なる種類の局所最小値が得意で、個人的な不満から書いたツールを使って アトミックに切り替える。この記事は2026年の真剣な作業でそれが正しいモデルである 理由の主張だ。

一つのエージェントへのコミットの問題

すべてのコーディングエージェントはわずかに異なることが得意だ。違いはベンチマークでは 明らかではない — 与えるタスクの形で実際の作業に現れる：

  • Claude Codeは既存の動作を壊さないことに最も慎重な傾向がある。編集前にファイルを 徹底的に読み、プロジェクトの慣習に近く留まり、深く関わるコードベースで最も信頼 するものだ。
  • Codex CLIはもっともらしいスキャフォルドの生成が速い。正確なアウトプットよりも 速度が重要な場合の、何かの最初のドラフトに行く場所だ。
  • Gemini CLIは別の推論のテクスチャを持ち、別のモデルが15分ループで詰まっていた とき時々突破する。障害モードが異なる、それが要点だ。
  • PIとOpenCodeはまだワークフローでのニッチを見つけている最中だ — 両方とも 他の三つが互換に感じるタスクで、特に上方向に驚かせる瞬間がある。

これらの観察は絶対的ではない。他の誰かのワークフローでは間違っているだろう。 しかし私の作業には本物だ。そしてそれを発見する唯一の方法は、すべてのエージェントを 数ヶ月間実際のタスクで動かすことだった。

設定切り替え問題

五つのエージェントを動かすことは、それぞれが独自のものを持つと気づくまでは無害に 聞こえる：

  • 認証トークンまたはAPIキー。
  • それぞれの風味の設定ファイル（JSON、YAML、TOML、自作）。
  • わずかに異なるパスのルールファイル/スキルファイル/指示ファイル。
  • 「プロジェクトルート」がどこかについての意見。
  • どのシェルプロファイルをソースするかについての意見。

最初は明らかなもの — エージェントごとの条件ブロックを持つ大きなdotfilesセットアップ — を試した。一週間機能した。それから異なるAPIキーが必要な新しいエンゲージメントを 追加し、すべてが「どの環境がどのターミナルでアクティブか」という混乱になった。 五つのエージェントと二つのクライアントを掛け算すると、ソフトウェアを書かないフルタイム の仕事になる。

実際に構築したもの

raiseを構築した — アトミックなシンリンクスワップでエンゲージメントごとの 「AIプロファイル」を切り替えるGoのCLIだ。一つのコマンドで、AIツールの設定セット 全体が切り替わる。現在、主要なコーディングエージェントと汎用アシスタントファミリーに またがる17のAIツールをサポートしている。

設計は意図的に退屈だ：

  • 各プロファイルは~/.raise/profiles/<profile>/下のディレクトリ。
  • 各AIツールには既知の設定パスがある（例：~/.claude/config、 ~/.config/gemini/config.toml）。
  • プロファイルの切り替えは内部でln -sfn — アトミックで、部分的な状態の失敗 モードがない。
  • クレデンシャルはプロファイルツリーの外に置かれ、アクティベーション時に再リンク されるので、プロファイルディレクトリにAPIキーを同期しない。

以上だ。全体はGoの数百行だ。有用な理由は巧妙だからではない — 一つのベンダーに コミットしていないことを前提としない、そのカテゴリで唯一のツールだからだ。私が 見た他のすべての「AI設定マネージャー」はベンダー結合しているか、クレデンシャル保存の 問題をクリーンに扱っていなかった。

すべてのエージェントにまたがる共有スキル

二番目の問題：すべてのコーディングエージェントは独自のルールファイルフォーマットを 持っている（CLAUDE.md、AGENTS.md、.cursorrules等）。五つを独立して維持すれば、 ドリフトする。非同期になる。一つが三ヶ月遅れでチームのコーディング標準になる。

真実の単一ソース — rice-shared-skills — を維持し、各エージェントの ルールファイルはそのソースから正規のスキルをインクルードする薄いラッパーだ。 慣習が変わると一回更新し、すべてのエージェントが次のアクティベーションで変更を 継承する。

共有スキルのアイデアは新しくない。特筆すべきは、機能してからの日常のフリクション の除去量だ。「Claude Codeはこのリポジトリでpnpm 10に切り替えたことを知っているか？」 というバックグラウンドのハムが… 消える。

なぜ二つでも十でもなく五つか

五という数字に教条的ではない。観察であって、処方ではない。一種類の作業だけをするなら、 二つのエージェントでおそらく十分だ。エキゾチックな技術スタックで調査に近い作業をする なら、五つより多くが欲しいかもしれない。

原則は：局所最小値から脱出できるほど十分なエージェントを動かし、切り替えコストが 脱出の利益を超えないほど少なく。 私にとってそれは五つだ。エージェントの地平が 変わるにつれて数も変わるだろう。

これが訓練するメタスキル

複数のエージェントを動かすことで、単一エージェントのユーザーが開発しないことが 多いスキルが訓練される：詰まったときに認識すること。 単一のエージェントが 失敗すると、試し続ける誘惑がある。五つのエージェントがあると、切り替えが十分に 安価で、主張の収益逓減に気づく。その気づきは、最終的には、「一時間一人でデバッグで 詰まった」と「15分で同僚にピングして20秒でアンブロックされた」を区別する同じ シニアエンジニアリングスキルだ。

エージェントは常に良いエンジニアリングプラクティスだった規律のための訓練輪だ。 フリクションが要点だ。

2026年の主張

2026年のAI支援エンジニアリングの速度で勝っているチームは、チャンピオンを選んで 結婚しているのではない。エージェントのフリートを動かし、それらにまたがって共有スキル 層を維持し、ベンダー選択をスワップ可能な商品として扱っている。他の全員は18ヶ月後に ロックインを後悔するだろう単一ツールを最適化している。

五つのエージェント。一つの共有スキル層。アトミックなプロファイル切り替え。それが スタックだ。