事業チームのコンテキスト情報をClaudeに蓄積・活用させるプラグインと、それを作るためのプラグインを作った

こんにちは、業務効率化ソリューション部の入井です。

今回は、Claudeのプラグインで、事業チームのコンテキスト情報を蓄積・活用する仕組みと、それをチームごとに生成できるジェネレーターを作ったので紹介します。

AIを業務で使うためのボトルネック

私は業務でSaaS製品のプリセールスを担当しており、特定のお客様向けの提案書を作成する機会が多いです。
その際、効率化のために提案書のドラフト作成をAIに任せようと「A社への提案を考えて」と指示をしても、生成されるのはどの会社にも当てはまるような一般論に基づいた提案で、あまり役には立ちません。

お客様が今どんな課題を抱えていて、過去にどんなやりとりがあって、予算規模がどれくらいで、誰が意思決定者なのか。これらのコンテキスト（文脈情報） がなければ、どれだけ高性能なモデルを使っても実用的な結果を得ることは難しいです。

案件の経緯、チームの業務フロー、製品の料金体系、競合との差分。これらをAIに渡すことができれば、AIは本当に役立ちます。モデルの性能がボトルネックなのではなく、渡すべきコンテキストが整理されていないことが、AIの業務活用における本当の壁だと感じています。

じゃあ、コンテキストを整理して蓄積すれば良いとなりますが、実際は次のような理由でなかなか難しいです。

理由の1つ目は、情報がバラバラな場所に散らばっていることです。
案件の経緯はSlackに、議事録はGoogleドキュメントに、課題管理はBacklogに、予定はカレンダーに。AIにコンテキストを渡そうにも、まず「どこに何があるか」を思い出して、それぞれのツールから情報をかき集めなければなりません。この作業だけで相当な手間がかかります。

2つ目は、蓄積し続けるのが大変すぎることです。
これはAIが登場する以前からナレッジ管理における最大の壁として言われ続けていますが、日々の業務をこなしているとそれだけで余裕がなくなり、なかなかナレッジ記事を書くための時間が捻出できません。重要性はわかっていて、必要な情報が目の前にあっても、なかなかそれを構造化して保管するための習慣を作ることができません。

これらの課題に対する1つの解決策としては、以下の記事で紹介されているようなAIによるコンテキスト情報管理の効率化の仕組みづくりが参考になりました。

https://dev.classmethod.jp/articles/claude-code-daily-workflow/
https://dev.classmethod.jp/articles/ai-driven-gtd-zettelkasten/

今回、これらの記事を参考に、チーム内のコンテキスト情報を上手く蓄積・活用するための仕組みを作れば、チームとしての業務効率化を達成できるのではと考え、Claude Code / Coworkで使えるプラグインを作成してみたので、その内容をご紹介します。

作成したプラグインの概要

今回ご紹介するのは2つのプラグインです。

context-stocker-forge は「プラグインを生成するプラグイン」です。商材名、チーム名、情報の蓄積先ストレージの種類などを指定すると、そのチーム専用のコンテキスト管理プラグインを自動生成します。

zendesk-context-stocker は、forgeによる生成物の一つです。私がプリセールスとして所属するZendesk事業チーム向けに生成して、実際に稼働させているプラグインです。

上記のうち、context-stocker-forgeはGitHubで公開しています。また、Claudeのマーケットプレイスに対応しているので、そちら経由でもClaude環境に導入することができるようになっています。

https://github.com/iridon0920/context-stocker-forge

以降のセクションでは、まずzendesk-context-stockerを例に何ができるのかを具体的にご紹介し、その後でforgeの仕組みに触れてどのように他のチームにも展開できるのかをご説明します。

zendesk-context-stockerでできること

zendesk-context-stockerは、Claude Code（ターミナル）およびClaude DesktopのCoworkモード上で動くプラグインです。どちらの環境でも同じコマンド・スキルが使えます。
その名の通り、Zendesk事業チーム内での活用を前提にしたプラグインとなっています。

このプラグインによりClaudeにチームコンテキスト情報の蓄積と活用の能力を追加します。
コンテキスト情報の保存先はBacklog Wikiに設定しており、ブラウザからも直接閲覧・編集ができます。

Claudeに蓄積を任せる

プラグインの基本的な考え方としては、人間がゼロからナレッジ記事を書くのではなく、Claudeが情報を集めて構造化し、人間は確認・承認するだけというものになります。

SlackやGmail、Backlog、Googleカレンダーなど、日常業務で使っているツールの中に情報はすでにあります。今回作成したClaudeプラグインは、それらを横断的に収集して、チームで使える形に構造化します。
情報の書き込み前に必ず確認フェーズが入り、Claudeが勝手に情報を集めたり、確認なしにデータを上書きすることはないようにしました。

これにより人間による対応工数を減らし、ナレッジ情報の蓄積について現実的に回せる工数に落とし込むことを考えています。

蓄積したコンテキストをClaudeが活用する

情報を溜め込むのは活用するためなので、蓄積したコンテキストをAIがスムーズに業務活用できる仕組みも取り入れています。

たとえば「A社への提案書を作って」と指示すれば、ClaudeはA社の案件コンテキスト（課題、予算、意思決定者、過去の経緯）とチームのガイドラインを参照して、具体的な提案書を生成します。取り扱い製品について質問すれば、蓄積されたナレッジから回答します。日次の活動ログの蓄積をもとに、週次・月次レポートも生成できるようにしています。

案件コンテキスト管理

ここからは具体的なプラグインの使い方をご紹介します。
プラグインは、独自に作成したコマンドを実行することで動作します。

コマンド: /zd-deal-load [顧客名]、/zd-deal-save

/zd-deal-load A社 を実行すると、Backlog WikiからA社のコンテキストを読み込み、案件状況を要約して提示します。これだけで、案件の全体像を把握した状態から作業を始められます。
後述するドキュメント作成コマンドに繋げるのも良いですし、案件の対応方法検討の壁打ちにも活用できます。

案件ページにはBANTCH（Budget, Authority, Need, Timeline, Competitor, Human resources）の営業フレームワークに沿った情報、As-Is/To-Beの分析、意思決定ログなどが構造化されて記録されます。

以下は案件ページの一部のイメージです（内容は完全に架空のもの）。

## 概要
- **顧客**: [A社](案件/既存顧客/A社)
- **案件種別**: 新規
- **目的・ゴール**: コールセンターのチケット管理をZendeskに移行し、初回応答時間を50%短縮
- **ステータス**: 進行中

### Budget（予算）
初年度ライセンス費 + 導入支援費で800万円の予算枠を確保済み。次年度以降の運用費は別途検討中。

### Authority（意思決定者）
最終決裁: 田中部長（カスタマーサポート部）/ 技術選定: 熊谷課長 / 現場推進: 鈴木主任

### Need（ニーズ）
現行の問い合わせ管理はメール+スプレッドシートで運用。月間3,000件の問い合わせに対し、
担当者の割り振りが手動で、初回応答まで平均8時間かかっている。

### Timeline（導入時期）
2026年7月の新体制発足に合わせて稼働開始を希望。4月中に契約締結が必要。

### Competitor（競合状況）
Freshdesk、ServiceNowと比較検討中。Freshdeskは価格面で優位、ServiceNowはITSM統合で優位。

### Human resources（体制）
CS部門15名 + IT部門2名が利用予定。専任の管理者は鈴木主任。

## 意思決定ログ（CM側）
| 日付 | 決定内容 | 理由 | 検討した代替案 |
|------|---------|------|-------------|
| 2026-03-04 | Guide+Gatherを提案（FAQ+コミュニティ） | 問い合わせ30%削減目標にはセルフサービス強化が最短 | Supportのみ→効果限定的 |

## 次のアクション
- [ ] 設定シートのレビュー依頼 — 入井 / 3月14日
- [ ] カスタムフィールド設計の確認MTG — 佐藤 / 3月12日

このように、案件に関わる情報が一箇所に構造化されて蓄積されていきます。

単に案件情報を保存するだけのプロンプトだと、十分に必要な情報の蓄積ができなかったので、コンテキストの記載には3つのルールを設定しています。

• 状態変化はfrom→toを書く —「変更」だけでなく、何がどう変わったかを明記する
• 判断・決定には理由を1文添える — なぜそうしたかが後から追えるようにする
• 固有名詞・数値で書く — 抽象的な表現を避ける

❌ 2026-03-04: コールセンター最適化の方向性変更報告
✅ 2026-03-04: コールセンター最適化: 新規構築→既存システム改善に方針転換（熊谷様メール）

チームメンバーなら誰でも同じコンテキストにアクセスできるので、引き継ぎは「/zd-deal-load A社」で済みます。

このプラグインを使い始める前は、案件の引き継ぎや商談準備のたびにSlack、Backlog、メールを巡回して情報をかき集める必要がありました。
体感で1案件あたり15〜30分かかっていた準備作業が、/zd-deal-load 一発で案件の全体像を把握できるようになり、すぐに次の行動の検討に入れるようになりました。また、案件情報が属人化しにくくなったのも大きな変化だと感じています。

保存時（/zd-deal-save）には、Claudeが会話の中で得られた新しい情報をコンテキストに反映したドラフトを提示します。内容を確認してOKを出すと、Backlog Wikiに保存されます。
Slack、Gmail、Googleカレンダー、Geminiの文字起こしログ、Googleドキュメントの議事録といった外部データソースからの情報をもとに保存することが可能で、これによってコンテキスト保存のための情報をゼロから作成する手間が省けています。

ナレッジベース

コマンド: /zd-knowledge-save、/zd-knowledge-search [キーワード]

Zendeskに関する様々なナレッジ情報を検索・保存します。
チームのナレッジは4つのカテゴリで構造化して管理する運用にしています。

保存されるナレッジページは以下のような形式です。

# ナレッジ/製品・技術仕様/Explore初回応答時間メトリック

## 概要
Zendesk Exploreで初回応答時間を集計する際のメトリック名・計算ロジック・注意点。

## 詳細
### 使用するメトリック
- `First reply time (min)`: エージェントの最初の公開返信までの時間（分）
- 営業時間ベースで計算する場合は `First reply time - business hours (min)` を使用

### 注意点
- 自動返信（トリガ経由）は初回応答にカウントされない
- チケットが再オープンされた場合、初回応答時間は最初のオープン時の値を保持

## 出典・根拠
- [Zendesk公式: Explore metrics](https://support.zendesk.com/...)（確認日: 2026-02-15）
- 社内検証（確認日: 2026-02-20）

/zd-knowledge-searchコマンドに加えてZendesk関連の質問をすると、プラグインが自動でナレッジベースを検索して回答に活用します。たとえば「Exploreでチケットの初回応答時間を集計するには？」と聞けば、上記のようなナレッジから設定手順とメトリック名を引き出して回答します。

ナレッジの保存も、人間がゼロから書くのではなく、Claudeが構造化したドラフトを提示して人間が承認する流れになります。

プリセールス文書・導入支援文書

コマンド: /zd-doc <種別> [顧客名]、/zd-engdoc <種別> [顧客名]

それぞれのドキュメント用のガイドラインと案件コンテキストを組み合わせて、業務ドキュメントを生成します。

ガイドラインはチームで育てつつ、個別ドキュメントの肉付けはAIに任せる形にしています。

ガイドラインページ（ガイドライン/商談準備、ガイドライン/提案書作成 等）にはテンプレートやルールが書かれており、チームの知見が蓄積されていきます。Claudeはそのガイドラインに従いつつ、対象案件のコンテキストから具体的な内容を埋め込んで出力します。
ガイドラインが要求する情報でコンテキストに存在しない項目は ⚠️ 付きで明示し、情報の漏れにも気づきやすくしています。

チームメンバー設定がある場合は、ドキュメント種別に応じた適任レビュアーも自動提案されます。

活動ログとレポート

コマンド: /zd-log daily、/zd-log weekly、/zd-log report

日次の活動を記録し、それを積み上げてレポートを生成します。

活動ログ/
  2026-03/
    2026-03-10        ← 日次ログ
    週次レポート-W11   ← 週次レポート
    月次レポート       ← 月次レポート
  2026/
    QBR-Q1            ← 四半期レポート
    年次レポート       ← 年次レポート

日次ログ（/zd-log daily）の作成時には、Slack、Backlog課題、Googleカレンダー、Gmail、Google Driveから当日の活動を自動収集します。カレンダーの予定にGeminiの文字起こしが添付されていれば、その内容も自動で取得して議論のポイントを要約します。

収集した情報からZendesk事業に関連するもののみをフィルタリングしてログに記録し、ドラフトを提示します。確認後にBacklog Wikiへ保存する流れです。

日次ログの作成は、この仕組みを入れるまではまったくできていませんでしたが、Coworkのスケジュール機能を使って毎日自動的にこのコマンドを実行するようにしてからは、漏れなく日々の活動ログを記録できるようになりました。収集されたドラフトを確認して微修正するだけなので、1回あたり10分もかからず記録できます。

週次レポートや月次レポートは、蓄積されたログやレポートをもとに生成されます。週次レポートは日次ログから、月次レポートは週次レポートから生成されます。
KPI管理やOKR管理とも連動しており、目標に対する進捗もレポートに含められるようにしています。

管理機能

コマンド: /zd-admin <サブコマンド>

プラグインの設定管理と運用保守を担います。

例えば、Slackの重点チャンネル設定を更新すると以後の日次ログ作成時にそのチャンネルを中心に会話履歴を取得します。他のKPIやチームメンバー情報など含め、これらの情報はコンテキスト情報というよりはチーム活動上のパラメータとして管理したほうが扱いやすいと考え、個別のコマンドで設定できるようにしました。

context-stocker-forgeの仕組み

ここまでは、私が所属しているZendeskチームでの活用のためのプラグインの機能をご紹介してきました。

業務効率化ソリューション部では他にもSaaS商材等を扱うチームが複数あり、そこでも同じような仕組みを生成できれば便利と思い、作成したのがcontext-stocker-forgeというジェネレータープラグインとなります。
現時点ではZendeskチームでの運用が先行しており、他チームへの展開はこれからですが、forgeで生成の仕組みを先に作っておくことで、他チームが導入を検討する際のハードルを下げられると考えて今回作成をしてみました。

ウィザードによるプラグイン生成

/forge-generate を実行すると、対話型ウィザードが起動します。5ステップの質問に答えるだけで、チーム専用のプラグインが .plugin ファイルとして出力されます。

Step 1: 基本情報（必須）

チーム名、事業名（商材・サービス名）、コマンドプレフィクス（2-4文字の英小文字）を入力します。たとえばTwilioのリセール事業なら「Twilio」「tw」のように設定します。すると /tw-deal-load、/tw-knowledge-search のようなコマンドが自動生成されます。

Step 2: ストレージ選択（必須）

データの保存先を選びます。現在はBacklog WikiとObsidian Vaultに対応しています。Backlog Wikiの場合はプロジェクトキーを、Obsidian Vaultの場合はベースパスを入力します。

Step 3: 営業フレームワーク選択

案件管理で使用する営業フレームワークを選びます。BANTCH（推奨）、BANT、MEDDIC、カスタムの4種から選択できます。カスタムを選ぶと、独自のフレームワークフィールドを自由に定義できます。

Step 4: データソース選択

Slack、Googleカレンダー、Gmail、Google Drive、Backlogのうち、有効にするデータソースを選びます。チームが使っていないツールはオフにできます。

Step 5: ナレッジカテゴリ設定

ナレッジベースのカテゴリを設定します。デフォルトでは「製品・技術仕様」「業務フロー・ガイドライン」の2カテゴリが用意されていますが、チームの業務に合わせて自由にカスタマイズできます。

これらの設定は .team-config.json に集約されます。設定を変更して再生成したい場合は、このファイルを指定して /forge-generate を実行すれば、ウィザードを最初からやり直す必要はありません。

ストレージの抽象化

このプラグインで扱うデータは基本的にMarkdownのみなので、MarkdownをCRUDできるAPIとそのMCPサーバー（※AIと外部データソースを安全に連携させるための標準規格）があれば、何でもストレージとして活用できます。現在はBacklog WikiとObsidian Vaultに対応していますが、これはストレージアダプタとして抽象化されており、その他のサービスもアダプタを追加することにより拡張できる設計になっています。

ZendeskのプラグインでBacklog Wikiを選んだのは、自チームの環境で一番チーム共有ストレージとして使いやすかっただけで、チームの状況に応じて必要なストレージを選ぶ形で全然問題がないと思っています。

生成されるスキルプロンプトの例

forgeが生成するのは、Claudeへの指示書（スキルプロンプト）です。テンプレートの変数がチーム固有の値に展開され、Claudeの振る舞いを定義するプロンプトが出力されます。以下は案件コンテキスト管理スキル（zd-deal）から抜粋した例です。

ストレージ設定とデータ構造の定義:

| 項目 | 値 |
|------|-----|
| Backlogプロジェクトキー | `TEAM_ZENDESK_XXXXX` |
| ストレージ | Backlog Wiki |
| 顧客ページ | `コンテキスト/{既存顧客|新規顧客}/{顧客名}` |
| 案件ページ | `コンテキスト/{既存顧客|新規顧客}/{顧客名}/{案件名}` |

MCP並列呼び出しの実行手順:

## セッション初期化（重要）

スキルを使う際、まず以下の情報を取得してセッションキャッシュに保持する。
⚡ パフォーマンス最適化: Phase内の複数MCP呼び出しは必ず並列実行すること。

Phase 1（直列・必須）: get_project(projectKey: "TEAM_ZENDESK_XXXXX") でprojectId取得。
Phase 2（すべて並列）: get_wiki_pages でHome・各設定ページのwikiIdを一括取得。
Phase 3（並列）: Phase 2のwikiIdで get_wiki し本文取得・パース・キャッシュ。

書き込み時の確認プロトコル:

## 書き込み確認プロトコル

すべてのデータ書き込み前に必ず以下の手順を実行する。

### 新規作成の場合
1. 書き込む内容の全文を表示する
2. 「この内容で保存してよいですか？」と確認する
3. 承認を得てから add_wiki を実行する
4. 該当INDEXページを更新する

このように、ストレージ固有のAPI名（add_wiki、get_wiki_pages 等）や、プロジェクトキー、パス構造、フィルタリング対象の事業名といった値がすべてテンプレート変数として展開されています。別のチーム向けに生成すれば、これらがそのチーム固有の値に置き換わったスキルプロンプトが出力されます。

今後の展望

自動収集への発展

現在は「半自動」フェーズにいます。人間が指示し、Claudeが実行し、人間が承認する。蓄積のハードルは確実に下がりましたが、指示するという一手間はまだ残っています。

次のステップとしては指示すら不要になる「自動収集」ができればと考えています。たとえばBacklog上でのQAサポートのやりとりから技術ナレッジを自動でピックアップしたりといった仕組みを作ることにより、最終的には日常業務をしているだけで自然とチームの知見が蓄積される状態になると考えています。
最終的には、ナレッジを管理しているという感覚すらない状態が理想です。

ストレージの拡張

前述のとおり、MarkdownのCRUD API + MCPがあるツールなら原理的にストレージとして対応可能です。現在のBacklogとObsidianに加えて、GitHub、Notion等、チームが日常的に使っているツールへの対応を広げていきたいと考えています。

出力フォーマットの拡充

現在の出力はMarkdownベースですが、提案書やレポートはMarp対応でスライドとして出力できるようにしたり、見積書はExcel・スプレッドシート形式で出力できるようにしたいと考えています。
コンテキストとガイドラインから生成した内容を、業務で使うフォーマットでそのまま渡せるようにするのが次の目標です。

個人向け対応

現在はチーム向けの仕組みですが、個人のワークフロー管理にも同じコンテキスト管理の仕組みを展開する構想もあります。

付録: context-stocker-forgeの中身

https://github.com/iridon0920/context-stocker-forge

AIの会話からJSコードを実行してプラグインを生成する

context-stocker-forgeでは、プラグイン生成時の対話フローの中でNode.jsのコードを実行してます。

ウィザードの対話部分はClaudeが担いますが、テンプレートの合成・バリデーション・ZIPパッケージングは forge-engine.js というNode.jsスクリプトが実行します。
Claudeが .team-config.json を生成した後、node forge-engine.js を呼び出し、テンプレートの変数展開からバリデーション、.plugin ファイルの生成まで一気に処理します。

テンプレート処理にブレがあると、生成されたプラグインの挙動が不安定になるためこういう仕組みにしてあります。変数の展開漏れ、条件ブロックの評価ミス、ストレージ固有の操作コマンドの取り違えといったミスが無いように、テンプレート処理はコードに任せ、AIは何を生成するかの設定を集めることに専念する設計にしています。

複数データソースへのMCP並列アクセス

AIの応答時間をできるだけ短くするため、複数のMCPサーバーへの呼び出しが発生する際は並列で実行するようにしています。
たとえば日次ログの作成では、以下のデータソースから当日の活動を収集します。

これらを順番に取得すると待ち時間が積み重なりますが、MCP呼び出しを並列で発行することで時間短縮しています。さらに、結果に依存する後続処理（Gemini文字起こしの取得や大きなドキュメントの要約など）はサブエージェントに委譲して、メインの処理フローをブロックしないようにしています。

このPhase構成と並列化のパターンはスキルのプロンプト内で定義されており、forgeのテンプレートを通じて生成されるすべてのプラグインに組み込まれます。

おわりに

コンテキストがなければAIは使えない。でも、情報はバラバラなツールに散らばっていて、蓄積し続けるコストも高くて続かない。この課題に対して、「Claudeに収集と蓄積を任せる」というアプローチでプラグインを作り、さらにそのプラグインを任意のチーム向けに生成できるジェネレーターを作りました。

まだ半自動のフェーズであり、書き込み時の承認コストなど課題も残っています。
それでも、「書く作業をClaudeに任せて、人間は判断に集中する」というアプローチにより、これまで続けられなかったコンテキスト情報の蓄積が現実的に回るようになりました。

チーム内での運用を重ねながら仕組みをブラッシュアップしていきたいと考えています。
このプラグインや仕組みに興味がある方は、ぜひ試してみてください。フィードバックも歓迎です。