AnthropicのClaude Code向け「Mods」で、開発者はエージェント自体を書き換え可能に

Anthropicは、Claude Code向けに「Mods」と呼ぶ機能を導入した。アイデアは簡潔だ。コーディングエージェントの動作を変える小さなTypeScript関数を、モデルに組み込むのではなくツール側に読み込む。

小さなリリースだが、意味は大きい。コーディングエージェントの動作は、設定するものではなく、自分で書くものになる。

なぜ関数は設定に勝るのか

現在のエージェントのカスタマイズの多くは、設定を通じて行われる。temperature、ツールの権限、システムプロンプト、許可されたコマンドのリスト。これらのつまみには共通の限界がある。自然言語で好みを記述し、モデルがそれに従うことを期待するだけだ。モデルが別の解釈のほうが役立つと判断すれば、設定は負ける。

modはコードだ。実行され、値を返し、その出力は決定的である。これにより制御の性質が変わる。エージェントに特定のディレクトリへ絶対に触れてほしくないなら、適切な場所に置いたmodが、丁寧に頼む代わりにそれを強制できる。レビューに届く前のすべてのdiffに特定の変換を適用したいなら、modは「ほとんどの場合」ではなく毎回それを実行できる。

トレードオフはいつもどおりだ。コードは設定よりも強力で、もろい。バグが入りうるし、保守も必要だ。利点は、強制執行の仕組みが自分のリポジトリ内に、バージョン管理下で、統治対象のコードの隣に置かれることにある。

競争の主戦場はカスタマイズ層へ移った

コーディングエージェント市場を眺めると、重心は移っている。基盤となるモデルは収斂しつつある。今日、モデルを選ぶ開発者が議論しているのはベンチマーク性能の数ポイントであり、何年も続く決定の根拠としては弱い。実際に重要な違いは、モデルの周囲の層にある。自分のリポジトリをどう扱うか、自分の慣習をどう尊重するか、自分のプロセスをどれだけ吸収できるか、だ。

Modsが信頼について語ること

このリリースには、もっと静かな読み方もある。開発者にエージェントの動作を書き換える手段を与えることは、ベンダーがあらゆるワークフローを先読みできないことの告白でもある。コーディングエージェントは何千もの異なるコードベースの中で動き、それぞれに独自の履歴、独自の慣習、危険な変更の独自の定義がある。その幅に触れて生き残るデフォルト設定は存在しない。

だから正直な一手は、継ぎ目を露出させることだ。自分のコードベースを知るチームが、自分のルールをコードで強制し、その結果に責任を負えるようにする。設定ページにチェックボックスをもう一つ追加し、すべてのケースをカバーしているふりをするより、成熟した姿勢である。

また、責任の所在を微妙に移す。悪い操作をブロックするmodは顧客のmodだ。バグがあってその操作を通してしまえば、結果は顧客のものになる。これは機能への不満というより、あらゆる逃げ道の性質であり、エンタープライズが好む運用の仕方でもある。彼らは境界をベンダーに委ねて発言権を失うより、自分で境界を制御し、それに説明責任を負うほうを選ぶ。

Build対Buyの境界線が再び動く

長年、開発者ツールでは自作するか購入するかが問われてきた。コーディングエージェントはその線を押し動かしてきた。Modsはそれをさらに、しかも特定の方向へ押す。モデルは購入品のままだ。その周囲のポリシーは、数十行のTypeScriptで自作するものになる。

これは健全な分離だ。チームは必要な動作を得るために自前のモデルを訓練すべきではないし、変えられない動作に縛られるべきでもない。軽量なカスタマイズ面がその両極端の間に位置し、コーディングエージェントの実用的価値の多くは最終的にそこで決まるだろう。

拡張性は、ツールが自らの成功を生き延びる方法である

開発者ツールには、少し立ち止まって考える価値のあるパターンがある。modsはまさにそれに当てはまる。ツールは意見とともに登場し、支持者を獲得し、その支持者が意見を超えて成長すると壁にぶつかる。最初に採用したユーザーはデフォルトに満足していた。後から来るユーザーは、デフォルトが想像もしなかった要件を抱え、自分で形を変えられる何かへ去っていく。

その瞬間を生き延びるツールは、継ぎ目を露出させる。コミュニティがツール自身の言語で動作を拡張できるようにし、その拡張がエコシステムの圧力の一部になる。エディタならプラグインを書かせ、ビルドシステムならタスクを書かせる。modsを書かせるコーディングエージェントも同じ動きであり、しかも壁にぶつかる前にそれをやっている。これはベンダーがこの映画をすでに見たことがある証拠だ。

この継ぎ目は、設定ページには作れないフィードバックループも生む。チームがmodsを公開し始めれば、ベンダーは人々が繰り返し求めている動作を把握し、それをデフォルトとして出荷し始められる。カスタマイズ面は研究チャネルになり、コミュニティが発見作業を無償で行う。これが拡張性の静かな配当であり、通常は単一のmodよりも価値が高い。

次にどこへ向かうのか

明らかな次の一歩は共有だ。リポジトリにあるmodsはすでにポータブルである。公開レジストリ、一般的なワークフロー向けのコミュニティルール群、ライブラリを引き込むように十分にテストされたmodを取り込む方法。それらはすべて、出荷されたものからすぐ近くにあり、ツールをプラグインフォルダ付きのアプリから、マーケットプレイスを備えたプラットフォームへと変える。

その方向には、いまやおなじみのリスクがある。共有されたmodは、あなたの認証情報とソースを保持するツールの中で動く信頼できないコードである。エージェントセキュリティの分野はこの一年、信頼できそうに見える小さな自動化が、いかに攻撃経路になるかを記録してきた。modsのレジストリは、発見の問題を解く前に信頼の問題を解かねばならない。それを最重要課題として扱うベンダーこそ、開発者が頼る存在になる。

リリース自体は、チェンジログの数段落にすぎない。それが指し示す方向はもっと大きい。コーディングエージェントはプラットフォームになりつつあり、自分のルールをコードにエンコードし、それをバージョン管理下に置くことでそう扱うチームは、設定の中から適切なチェックボックスをまだ探し回っているチームよりも、今後数年間でより多くを得るだろう。

ただし、名指ししておく価値のある限界もある。すべてのチームに、modを書いて保守したい人がいるわけではない。ごく少数の開発者しか触らないカスタマイズ面は、それ以外の全員にとって大きな変化にはならない。modsの価値は、健全で共有され、よく保守されたmodの集合が生まれるかどうかにかかっている。プラグインエコシステムが、ソースを一度も開かない人々にとってエディタをより有用にするのと同じように。それが実現するまでは、modsは強い意見を持つチーム向けの強力な機能だ。そして結局のところ、それはすでにコーディングエージェントを本番運用しているチームのほとんどに当てはまる。