この記事は、ばらつきに関する観察から始まる。チームは大規模言語モデルを導入したが、著者の見立てでは 各エンジニアは自力でやりくりするに任されており、同じモデル、同じ IDE でもまったく異なる結果が生まれている。 示される例は、同じリポジトリで同じタスクに取り組む 2 人のエンジニアである。1 人は先にコンテキストを 整え、何かを依頼する前にリポジトリのコーディングガイドライン、lint ルール、既存のパターンをモデルに 与えて、10 分でマージ可能なものを得る。もう 1 人は「この関数をリファクタリングして」から始め、 チームではそういうやり方はしないと繰り返し伝えることに 1 時間を費やす。著者は、この差はコーディング 能力ではなくツールを制御するノウハウの差であり、その差を個人の感覚に委ねたままにするのは組織レベルの 損失だと強調する。
そこから記事は、コーディングエージェントのプラグインとマーケットプレイスの仕組みは単なる拡張機構では なく、組織の働き方を配布する手段であると論じる。中心的な主張は 実行可能な SSOT（Executable SSOT） ——プラグインとして定義された知識は、人にとってはガイドラインとして、モデルにとってはシステム プロンプトとして読まれるため、プラグインを更新すればチームのエージェントの振る舞いが更新される——と、 最良のケースではなく最も弱いケースを改善する 底上げ（Raising the Floor） である。著者は、これが 実証された成果ではなく方向性であることを繰り返し明言しており、その大部分は仮説であって、チームの ワークフローがマーケットプレイス上で実際にどう進化するかは試してみなければわからない、と述べて 締めくくっている。
要点
- 同じモデルを使うエンジニア間のばらつきは、コーディング能力ではなくツールを制御するノウハウの差と して示され、組織が個人の適性に任せるべきではないものとされる。
- 著者は Claude Code を特に取り上げる。Open Interpreter や OpenCode を優れた先行事例として挙げつつも、 新しいツールを使うという感覚そのものが依然として摩擦を生み、コードをチャットボットに貼り付けるために ブラウザへ移ることはコンテキストスイッチのコストを伴うと論じる。開発者がすでに時間を過ごしている ターミナルの中で自然言語とコードを混在させられることが、設計されたワークフローを抵抗なくチームに 広める要因だと著者は述べる——ただしこれは確定した評価ではなく、現時点で最も摩擦の少ない入り口として 提示されている。
- ウィキやドキュメントのページは人が読むためのものなので書かれた瞬間から古くなり始めるのに対し、 プラグインとして定義された知識は両方の読み手に同時に役立ち、更新された瞬間にエージェントの 振る舞いを変える、と論じられる。
- 著者は、汎用的なオープンソースのプラグイン集は良い出発点ではあるがチームのドメインを知らず、 AI が得意なことと人がレビューすべきことの線引きはチームごとに異なると論じる。
- この仕組み全体は、プラットフォームエンジニアリングの繰り返しとして提示される。共有モジュールは AI ワークフローのプラグインになり、ライブラリの公開はマーケットプレイスへのアップロードになり、 変わるのはモジュールの中身がコードからプロンプトとエージェントロジックになることだけである。 品質保証もそのまま引き継がれるとされ、プラグインは共有モジュールと同じようにレビューされるべき だという。
- マーケットプレイスは、2 つの理由から検索拡張生成（RAG）より好ましいと論じられる。1 つは予測可能性で、 プラグインは開発者が完全に制御できる明示的なテキストであるのに対し、RAG のハイブリッド検索と リランキングはどのようなコンテキストが注入されるかを予見しにくくする。もう 1 つは実験の速さで、 プラグインはデプロイなしにローカルで修正し、ターミナルで検証できる。
- 配布によって得られるものとして 2 つのシナリオが示される。1 つ目では、フックが main ブランチへの コミットの試みを横取りし、エージェントにフィーチャーブランチを作成するよう方向転換させる。著者は これを、ブロックするだけのリンターと対比する——プラグインはチームの規約に向けて振る舞いを修正する のである。2 つ目では、1 つのスラッシュコマンドが最も優れたエンジニアのワークフロー全体——会話に よるコンテキスト収集、Issue の作成、ブランチの作成、人間の承認を得るための計画の作成、実装、 プルリクエストの作成——を担い、どのエンジニアでも同じ品質で実行できるようにする。
- プラグインの知識は、全社的なルールのグローバル層、チームとビジネスの知識のドメイン層、 リポジトリ固有の詳細のローカル層に階層化することが提案される。新しく入った人に全社の文書を一度に すべて渡したりはしない、という類推による。
- より長期的な「データフライホイール」が、明示的に仮説として示される。プラグインを通じて標準化された データが蓄積され、それを使ってドメイン特化モデルをファインチューニングし、既存のワークフローが その評価基準として機能するというものである。著者はその前提条件として、十分に長い収集期間、 品質管理のプロセス、そして組織による継続的な投資を挙げている。
背景
この記事は、同じブログで著者が以前に書いた Software 3.0 時代についての文章の続編として位置づけられて おり、Software 3.0 を改めて説明することなく枠組みとして用いている。その主題である Claude Code プラグインマーケットプレイス で説明される仕組みは、ここでは、それがどう作られて いるかではなく、組織がそれを使って何ができるかというレベルで扱われている。
留保は著者自身によるもので、一度ならず述べられている。記事は、具体的な成功事例というよりは方向性に 近いもの、著者が見ている可能性の共有、そして結論では大部分が仮説であると説明されている。 コメント欄は関連する点について冷ややかで、複数の読者が記事を抽象的あるいは曖昧だと評している。 そのうちの 1 人は記事を一行——エージェント開発にはハーネスと検証ループが必要だ——に要約し、 同じ質問を AI にすれば同じことを言うだろうと述べている。あるコメント投稿者は、記事が扱っていない 実質的な反論を提起している。十分に制御された RAG パイプラインならプラグインと同じくらい予測可能に なりうること、数十のプラグインのうちどれが有効になっているかを追跡すること自体が可視性の問題に なること、そしてそもそも両者は種類の異なるもので、一方は知識検索のツール、もう一方は振る舞いの ルールの定義であること、である。記事はまた、掲載されている画像はすべて生成 AI によって作成された ものだと述べている。