ほとんどのAIコーディングツールはモノリスとして提供されます。大きな1つのシステムプロンプト、1セットの機能、万人向けのワンサイズです。これは一般的なソフトウェアエンジニアリングではうまく機能します。しかし、役割ごと・チームごと・関わり方ごとに変わるドメイン固有のワークフローが必要になった瞬間に、すぐに破綻します。
私は Presidio でプリセールスの仕組みを構築しています――クライアント調査、SOW生成、ミーティングの記録、ディール運用。ソリューションアーキテクトはディールデスクのアナリストとは異なるツールが必要で、さらに毎回すべてをあらゆるセッションに詰め込むとトークンを浪費し、出力の品質も低下してしまうような種類の仕事です。
そこで私は、Claude Code 向けにプラグインマーケットプレイスを作りました。9つのモジュール式プラグインを用意し、それぞれ独立してインストールでき、役割ごとに組み合わせられます。これをチームに展開して分かったことを共有します。
なぜ「1つの大きなワークスペース」ではなくプラグインなのか
元の仕組みはモノリスでした――56のコマンド、14のスキル、36のツールがすべてのセッションに読み込まれます。私は単独のオペレーターとして運用していたため、それで問題ありませんでした。しかし他のコンサルタントに共有しようとした瞬間に、すぐに3つの問題が表面化しました：
コンテキスト汚染。 SOW作業をしているコンサルタントには、ミーティング文字起こしのパイプライン、競合インテリジェンスのフレームワーク、ディール管理コマンドなど、コンテキストウィンドウを占有する不要要素は必要ありません。無関係なトークンが増えるほど、モデルは目の前のタスクへの注意を劣化させます。
オンボーディングの摩擦。 「このリポジトリをクローンして、ドキュメント200行を読み、環境変数18個を設定し、56個のコマンドを覚える」といったことは、導入戦略になりません。人々は必要なものをインストールして、不要なものは無視できるようにする必要があります。
保守の結合。 ミーティングレコーダのバグ修正が、すべてのユーザーに対して、SOWパイプラインにも触れる更新を取り込ませる必要があるべきではありません。ユーザーが忙しいコンサルタントであり、開発者ではない場合、独立したバージョニングが重要になります。
解決策は分解でした。モノリスを、個別にインストール・更新・削除できるプラグインへ分割します。
そこから生まれたアーキテクチャ
fulcrum-plugins/
├── plugins/
│ ├── core/ # 基盤：ペルソナ、認証、OneDrive、共有ルール
│ ├── intel/ # クライアント調査パイプライン
│ ├── meeting/ # サイレント記録＋文字起こし
│ ├── discovery/ # コール準備、適格性確認、機会分析
│ ├── sow/ # SOWドラフティング、レビュー、QA、赤入れ
│ ├── proposal/ # ソリューションデッキとプライシングのワークブック
│ ├── ops/ # 日次ブリーフィング、週次レビュー、コンテキスト切り替え
│ └── engage/ # ディール管理、デリバリーの引き渡し
│
│ └── util/ # フレッシュネス監査、トリアージ、ワークスペース保守
└── shared/ # プラグイン間で使われるフレームワークとテンプレート
└── docs/
各プラグインは、コマンド、スクリプト、ルール、フックを備えた自己完結型のディレクトリです。必須の依存関係は1つ――core で、アイデンティティ、認証、共有ファイルシステムを提供します。それ以外はすべて任意です。
インストールは1コマンドです：/plugin install sow@fulcrum-plugins。アンインストールも同様にクリーンです。プラグイン間のインポートはなく、core が提供する以外の共有状態もありません。
必須バンドルより「推奨セット」を
1つの構成を強制するのではなく、マーケットプレイスでは推奨セットを提供します：
- Minimal（SOWに集中）： core + sow ―― SOW（Statement of Work）だけを書くコンサルタント向け
- ミーティング重視： core + meeting + discovery ―― 1日中クライアントの打ち合わせを回しているコンサルタント向け
- Full presales（プリセールス全部入り）： 9つすべてのプラグイン ―― 私のようにあらゆるフェーズに触れる人向け
これは、人が実際にどう働くかを尊重しています。誰も毎日すべてのツールを使うわけではありません。core + sow だけをインストールするコンサルタントは、より集中して高速な体験を得られます。すべてをインストールする人は、フルのオペレーティングシステムを得ます。どちらも一級市民です。
ネームスペースの隔離は、思っている以上に重要
私が最初にモノリスを分解したとき、すべてのプラグインに /draft、/review、/status のようなコマンドがありました。衝突があちこちで発生します。そこで ネームスペース構文 を導入しました――/sow:draft、/intel:company-intel、/ops:weekly-review。
最初は冗長に感じました。しかしそれは、最も重要な設計判断の1つだと分かりました。ネームスペースには3つの役割があります：
-
曖昧さを排除する。
/draftは、SOWの下書き、提案書の下書き、あるいはメールの下書きのどれを意味しうるかが不明です。/sow:draftなら一意です。 -
発見（ディスカバリー）を可能にする。 新しいユーザーは
/sow:と入力すれば、リストを暗記しなくてもSOWのすべてのコマンドを確認できます。ネームスペースが、そのままドキュメントになります。 -
プラグインの独立性を保つ。 2人のプラグイン作者が、それぞれ独立に
statusコマンドを作ることができます。/engage:statusと/ops:statusは衝突せず共存します。
私はv1.1で、より短いプレフィックスを得るために、すべてのプラグイン名を改名しました――sow-pipeline は sow に、research-intel は intel に、engagement-lifecycle は engage になりました。これらを1日に何十回も打ち込むとき、すべてのキー入力が重要です。
共有できる学び：データベースなしの「組織の記憶」
私が最も誇りに思っている機能は、アプリケーションコードがゼロ行という点です。OneDrive上のフォルダです。
コンサルタントが苦労して学んだこと――SalesforceのフィールドでAMにロックがかかっているもの、クライアントが好むミーティング形式、どこにも記録されていないコンプライアンス要件――そういったものが出てくると、彼らは共有フォルダにマークダウンファイルを投下します：
shared-lessons/jane-doe/2026-04-09-sfdc-stage-lock.md
セッション開始時、フックスクリプトがチーム内のすべてのレッスンファイルを走査し、タイトルで重複を取り除き、キャッシュされたルールとしてレンダリングします。そしてそのルールが、すべてのセッションに読み込まれます。誰かがウィキをメンテナンスしたり、ナレッジ共有のミーティングに参加したり、チケットを起票したりしなくても、チームの集合知は増えていきます。
これらの制約は意図的です――1ファイルにつき1レッスン、クライアント機密データの禁止、帰属（attribution）が必要、日付が必要（古いレッスンは削除されます）。形式はシンプルなので、開発者でない人も貢献できます。この仕組み――Microsoft Teams 経由で同期されるOneDriveフォルダ――は、新しいツールやログインを必要としません。
私が何度も立ち返るのはこのパターンです：すでに人が持っているインフラを使う。 OneDrive、git、マークダウンファイル。カスタムDBでも、新しいSaaSツールでも、API連携でもありません。最良のシステムとは、人々がすでに従っているワークフローに自然に溶け込んでしまうものです。
うまくいかなかったこと
プラグインの依存関係。 当初の設計では、プラグインが相互に依存関係を宣言していました――sow は intel に依存し、engage は discovery に依存する、という具合です。しかし実際には、インストール順の手間が増え、何が読み込まれるのかを理解しにくくなってしまいました。v1.3のアーキテクチャでは、すべてのプラグイン間依存を廃止しました。各プラグインは完全に自己完結しています。もし sow がクライアントのコンテキストを必要とするなら、intel から関数をインポートするのではなく、クライアントのコンテキストファイルを直接読み取ります。
自動プラグイン更新。 元の設計では、セッション開始時に更新を自動で取り込みます。しかし実際には、コマンドのシグネチャが変更されたことで、作業中の途中で人々が壊れてしまいました。そこで修正として、更新を明示的に行うようにしました――準備ができたら /core:update。そして、更新が利用可能なときに分かるステータスラインの表示を設けます。ユーザーはあなたの都合に合わせてではなく、自分のスケジュールで更新します。
きめ細かなバージョニング。 当初は各プラグインを個別にバージョン管理しようと試みました。ですが、9つのプラグインにまたがるバージョン調整に3日かかったため、市場（マーケットプレイス）の単一バージョンに切り替えました。すべてのプラグインが VERSION にある同じバージョンを共有します。マーケットプレイスのレベルでのSemVerであって、プラグイン単位ではありません。考えるのが簡単で、伝えるのも簡単です（「1.3.1に更新して」）、タグ付けもより簡単。
The Adoption Signal
最も示唆的な指標は、インストール数ではありません――人々が選ぶ推奨セットはどれか、です。ユーザーの多くが最小セットをインストールし、その後数週間かけて段階的にプラグインを追加していくなら、あなたは信頼を少しずつ積み上げていけるものを作れていることになります。逆に、初日から全部をインストールして「多すぎて圧倒される」と文句を言われるなら、あなたは余計な手順付きのモノリスを出荷しただけです。
これまでのところ、そのパターンは健全です。新しいコンサルタントは core + sow（職務要件）から始め、最初のクライアントとの通話のあとに discovery を追加し、さらに他者のAIが生成した会議メモを見た後に meeting を追加します。押し付けではなく、引き寄せです。
プラグインアーキテクチャ自体は新しいものではありません。新しいのは、それをAIエージェントのコンテキストに適用すること――モデルの知識、ルール、能力を、静的なシステムプロンプトとしてではなく、組み合わせ可能なモジュールとして扱うことです。必要なツールは現在、Claude Codeのプラグインシステム にあります。難しいのはアーキテクチャではありません。難しいのは、それを分解する規律です。
