2026年8月21日、日本語CRM「Knottle」をChatGPTのPlugin Directoryに公開した。
Knottleは、ひとり社長・フリーランス・少人数事業者向けに、顧客・担当者・案件・タスク・活動履歴・見積・請求などを一元管理する日本語CRMだ。
一般的な大規模営業組織向けSFAを小さくしたものではなく、経営者自身が顧客対応から案件管理、見積、請求まで行う働き方を前提に作っている。
さらにMCP（Model Context Protocol）に対応しており、ChatGPTやClaudeなどの対応クライアントから、普段Knottleで管理しているCRM情報を参照・操作できる。
以前からClaudeからMCP経由で接続できるようにしていたが、今回Plugin Directoryに公開されたことで、同じMCPサーバーをChatGPT側からも利用できるようになった。
最初は「ChatGPTとClaudeで何ができるかの違い」を中心に書こうと思っていた。
ただ、実装を改めて確認してみると、Knottle側ではChatGPT用とClaude用で別々のMCPを用意しているわけではない。
1つのMCPサーバーが42個のツールを公開し、ChatGPTやClaudeなどのMCPクライアントがそこへ接続する構成になっている。
この記事では、
- Plugin Directory公開で接続方法がどう変わったか
- OAuth / PKCE / Dynamic Client Registrationをどう組んでいるか
- 42個のMCPツールをどう分類しているか
- ChatGPTとClaudeでサーバー側の実装をどう共通化しているか
- ChatGPT / Claudeから実際にどこまで操作できることを確認したか
を、Knottle側の実装・各サービスの仕様・実際に確認した動作を分けながら書く。
検証時点
この記事の内容は2026年8月22日時点。
Knottle側については実装コードを確認し、MCPツール数、ツール属性、OAuthまわりの実装を確認している。
Claudeについては、claude.aiのカスタムコネクタからKnottleへ接続し、読み取り系ツールを実際に実行した。
ChatGPTについても、Plugin Directory公開後にKnottleへ接続し、MCP経由でCRM情報を参照・操作できることを確認している。
Knottle側ではChatGPT用とClaude用でMCPサーバーを分けておらず、どちらのクライアントに対しても同じ42個のMCPツールを公開している。
ただし、
ChatGPT / Claudeそれぞれについて、42個すべてのツールを1つずつ最後まで実行する網羅テストを完了したわけではない。
そのためこの記事では、
Knottle側の実装
各サービスの仕様
実際に確認した動作
を分けて書く。
特に、
「MCPサーバー側で42ツールを公開している」
ことと、
「特定のMCPクライアントで42ツールすべての実行を個別に検証済み」
であることは別の話として扱う。
Plugin Directoryに公開すると何が変わるのか
KnottleをPlugin Directoryへ公開する以前、ChatGPTからKnottleのMCPサーバーへ直接接続する場合は、Developer Modeを利用してMCPサーバーを手動で追加する経路が中心だった。
Plugin Directoryへの公開後は、ユーザーがKnottleのMCPサーバーURLを自分で入力しなくても、Plugin DirectoryからKnottleを見つけて接続できる。
OpenAIでは2026年7月9日に、それまでのApp DirectoryをPlugin Directoryへ移行している。
現在のPluginは、単純な「外部サービスとの接続」だけを指すものではない。
PluginにはApp、Skill、App Templateなどを含めることができ、その中でAppが外部データや外部アクションとの接続を担当する構成になっている。
Knottleの場合は、MCPサーバーへ接続するAppを含むPluginとして公開している。
OpenAIの現行ドキュメントでは、Plugin DirectoryはChatGPT WebとDesktopから利用できる。
Directory自体はChatGPTの各プランから参照できるが、実際にPluginをインストール・実行できるかどうかは、
- ChatGPTのプラン
- Workspace設定
- ユーザーのRole
- 利用しているSurface
- 地域
- Pluginに含まれるAppのCapability
などによって変わる。
そのため、「Plusなら必ず使える」「Freeでは使えない」といった形ではこの記事では断定しない。
Knottle側ではChatGPT用とClaude用を分けていない
ここは今回改めて実装を確認して、個人的にも重要だった部分だ。
Knottleには、
- ChatGPT専用MCPサーバー
- Claude専用MCPサーバー
が存在するわけではない。
どちらも同じMCPサーバーへ接続する。
概念的にはこうなる。
┌─ ChatGPT
│
Knottle MCP Server ├─ Claude.ai
│
└─ その他のMCPクライアント
Knottle側では、接続してきたクライアントがChatGPTなのかClaudeなのかによって、公開するツールを切り替えていない。
サーバーは同じ42個のMCPツールを公開する。
そのため、仮にChatGPTとClaudeで実際のツール実行方法、確認UI、実行前確認などに差が出たとしても、少なくとも現在のKnottleのサーバー実装上は、
「Claudeにはwrite toolを返してChatGPTには返さない」
といった出し分けはしていない。
MCPサーバーが提供するCapabilityと、各クライアントがそれをどう扱うかは分けて考える必要がある。
OAuth接続をどう実装しているか
MCPサーバー自体を作るより、Plugin Directoryや外部MCPクライアントから自然に接続できる認証まわりの方が、意外と考えることが多かった。
Knottleでは現在、以下の構成にしている。
- OAuth 2.0
- PKCE
- Dynamic Client Registration
- public client
- OAuth Authorization Server Metadata
- OAuth Protected Resource Metadata
OAuth 2.0 + PKCE
認可コードフローにはPKCEを利用している。
code challenge methodはS256のみを許可しており、plainは受け付けない。
code_challenge_method = S256
MCPクライアント側で生成したcode_verifierからcode_challengeを作成し、Authorization Endpointへ渡す。
Authorization Codeを取得した後、Token Endpointでcode_verifierを使って検証する。
Dynamic Client Registration
KnottleではDynamic Client Registrationにも対応している。
RFC 7591で定義されている仕組みで、MCPクライアントが接続時に自身をOAuth Clientとして登録できる。
そのため、Knottle側で、
「ChatGPT用のclient_idを事前に発行する」
「Claude用のclient_idを管理画面へ手作業で登録する」
といった作業を前提にしていない。
クライアントが登録エンドポイントを利用して、自分自身を登録できる。
client_secretを発行しない
登録されるクライアントはpublic clientとして扱っている。
そのため、
token_endpoint_auth_method: none
を返し、client secretは発行しない。
認証の安全性をclient secretに依存させるのではなく、Authorization Code + PKCEで処理する。
2つのwell-knownメタデータ
OAuthサーバーには次の2つのメタデータエンドポイントを用意している。
/.well-known/oauth-authorization-server
Authorization Server Metadata。
RFC 8414で定義されているもので、
- Authorization Endpoint
- Token Endpoint
- Registration Endpoint
- 対応するPKCE方式
など、OAuth Authorization Serverの情報をクライアントへ伝える。
もう1つが、
/.well-known/oauth-protected-resource
Protected Resource Metadata。
こちらはRFC 9728で定義されており、MCPサーバーという保護対象リソースが、どのAuthorization Serverを利用するのかをクライアントへ知らせる。
未認証アクセスからOAuth開始まで
認証が必要なMCPリクエストへ認証なしでアクセスされた場合、Knottleは401 Unauthorizedを返す。
その際、WWW-Authenticateヘッダにresource_metadataの場所を含める。
イメージとしては、
MCP Client
│
│ MCP request
▼
Knottle MCP Server
│
│ 401 Unauthorized
│ WWW-Authenticate:
│ resource_metadata="..."
▼
Protected Resource Metadata
│
▼
Authorization Server Metadata
│
▼
OAuth Authorization
という流れになる。
クライアントはProtected Resource MetadataからAuthorization Serverを確認し、そのAuthorization Server MetadataからAuthorization EndpointやToken Endpointなどを取得する。
これによって、MCPクライアントごとにOAuth URLなどを手入力させる構成にしなくても、必要な認証情報をたどれるようにしている。
この一連の仕組みについては、claude.aiからKnottleへ接続した際に実際にOAuth認証が成立することを確認している。
ChatGPTからもKnottleへの接続・認証が成立し、MCP経由でCRMを参照・操作できることを確認している。
ただし、ChatGPTクライアント内部のOAuth discovery処理がClaudeと完全に同一の順序・内部実装になっていることまで検証した、という意味ではない。
MCPサーバーには42個のツールを実装している
現在のKnottle MCPサーバーには、合計42個のツールがある。
対象領域は、
- 顧客
- 担当者
- 案件
- 見積
- 請求
- タスク
- 活動履歴
- 書類
など。
単純なCRMの検索だけではなく、実際の業務処理までMCP経由で扱うことを前提に設計している。
42ツールは、実装上4つの種類に分かれている。
| 区分 | 内容 | 数 |
|---|---|---|
| 読み取り専用 | 検索・一覧・単体取得・PDF取得など | 15 |
| 通常の書き込み | 顧客・案件・見積・タスクなどの作成・更新、活動記録 | 14 |
| 破壊的操作 | 削除、受注確定、帳票発行、入金記録、それらの取消 | 12 |
| 外部書き込み | 添付ファイルの外部ストレージ保存 | 1 |
| 合計 | 42 |
「破壊的」は削除だけではない
MCP toolの分類で少し悩んだのがここだった。
「destructive」という名前だけを見ると、データ削除だけを想像しやすい。
ただKnottleでは、
- 見積書の発行
- 請求書の発行
- 受注確定
- 入金記録
- それらの取消
なども破壊的操作側に分類している。
理由は、単純なデータ更新と比べて業務上の影響が大きいからだ。
例えば、
顧客名を修正する
のと、
請求書を正式発行する
では、同じ「write」でも意味がかなり違う。
後者は業務上の状態を確定させる操作なので、通常のcreate/updateとは分離している。
MCPのannotationを操作制御に使う
各ツールには操作の性質に応じてreadOnlyやdestructiveなどのヒントを持たせている。
つまり42個を全部、
実行できるMCP tool
としてフラットに扱うのではなく、
読むだけなのか
通常の更新なのか
業務状態を大きく変える操作なのか
外部への書き込みなのか
をサーバー側でも区別する。
特にAIからCRMを操作させる場合、検索と請求書発行が同じ感覚で実行される設計にはしたくなかった。
請求書発行後は内容をロックする
Knottleでは請求書を発行すると、その請求書の金額や明細をそのまま編集できなくする。
これは電子帳簿保存法への対応を考慮し、電子的な取引記録の真実性を保つために採っている実装方針の1つだ。
ここは表現に注意が必要で、
「電子帳簿保存法が特定フィールドのロック実装を直接要求している」
という意味ではない。
Knottle側の設計として、
発行済みの帳票を後から直接書き換えられる状態にしない
ようにしている。
状態を戻す必要がある場合も、単純にデータを書き換えるのではなく、業務状態を順番に取り消していく。
現在の依存関係では例えば、
入金記録の取消
↓
受注の解除
↓
請求書の発行取消
↓
見積書の発行取消
という順番で状態を戻す。
こうした操作も、通常のupdateとは分離して破壊的操作として扱っている。
Claudeではread系を実際に動かした
サーバーの実装だけ確認して終わると、本当にMCPクライアントから利用できるのか分からない。
そこで2026年8月21日に、claude.aiのカスタムコネクタからKnottleへ接続してread系ツールを実際に実行した。
確認したのは、
- 取引先一覧
- 案件一覧
- 保存先ステータス
など。
いずれもKnottle MCP経由で正常にレスポンスを取得できた。
書き込み系についてもClaude側へtoolとして公開されていることは確認している。
ただし、本番CRMの顧客や帳票へ副作用を出さないため、今回の記事作成時点では、
見積を新規作成する
請求書を発行する
顧客を削除する
といった処理を含め、42個すべてを最後まで実行する総当たりテストは行っていない。
そのため、
「Claudeでは42ツールすべての実行に成功した」
とは書かない。
確認できているのは、
read系は実際に動作した
write系toolもクライアントへ公開されている
というところまでだ。
ChatGPTからもKnottleを操作できる
今回Plugin Directoryへ公開した後、ChatGPTからKnottleへ接続し、MCP経由でCRMを参照・操作できることを確認した。
Knottle側ではChatGPT用の専用APIや専用MCPサーバーを用意しているわけではない。
Claudeと同じMCPサーバーへ接続し、サーバー側からは同じ42個のツールが公開される。
構成としては、
ChatGPT
│
▼
Knottle MCP Server
│
├─ 顧客
├─ 担当者
├─ 案件
├─ 見積
├─ 請求
├─ タスク
├─ 活動履歴
└─ 書類
となる。
ChatGPTからKnottleのCRM情報を参照するだけでなく、MCP toolを通じてCRMの操作を行うこともできる。
一方で、今回確認したことと、まだ確認していないことは分けておきたい。
確認できているのは、
- ChatGPTからKnottleへ接続できる
- OAuth認証が成立する
- KnottleのMCP toolsをChatGPTから利用できる
- CRM情報の参照・操作ができる
- Knottle側ではChatGPTにも同じ42ツールを公開している
という点。
ただし、
42個すべてのツールについて、一つずつ最後まで実行する網羅テストを完了したわけではない。
そのため、
「ChatGPTからKnottleを操作できる」
とは言えるが、
「ChatGPTで42ツールすべての実行を個別に検証済み」
とはこの記事では書かない。
この区別は、MCPサーバー側のCapabilityと、各MCPクライアント上で実際に確認した動作を混同しないためにも重要だと思っている。
MCPサーバー側でAI製品を意識しすぎない
今回実装を見直していて、個人的に一番重要だと思ったのはここだった。
最初から、
Claude用CRM API
ChatGPT用CRM API
を別々に作るのではなく、
Knottleの業務機能
↓
Knottle MCP Server
↓
各MCP Client
という形にしている。
AIサービスごとの差分はクライアント側へ寄せ、CRM側は業務ルールを一箇所に持つ。
例えば、
- 請求書発行後は直接変更できない
- 業務状態に応じて取消順序がある
- readとwriteを区別する
- 重要操作をdestructiveとして扱う
といったルールは、ChatGPT用でもClaude用でも変わらない。
MCPを単なる「AIからAPIを呼ぶためのラッパー」としてではなく、
CRM側の業務ルールをAIクライアントへ公開する共通インターフェース
として使う構成にしている。
まとめ
今回、KnottleをChatGPT Plugin Directoryへ公開した。
実装を改めて整理すると、構成はかなりシンプルだった。
Knottle
│
├─ CRM / 業務ロジック
│
└─ MCP Server
│
├─ 42 MCP tools
│
├─ OAuth 2.0
├─ PKCE (S256)
├─ Dynamic Client Registration
├─ Authorization Server Metadata
└─ Protected Resource Metadata
│
├─ ChatGPT
├─ Claude.ai
└─ その他のMCP Clients
ポイントをまとめると、
- Knottleは、ひとり社長・フリーランス・少人数事業者向けの日本語CRM
- 顧客・担当者・案件・タスク・活動履歴・見積・請求などを一元管理できる
- ChatGPT用とClaude用でMCPサーバーを分けていない
- 1つのMCPサーバーから42ツールを公開している
- 42ツールは読み取り15、通常書き込み14、破壊的操作12、外部書き込み1
- OAuth 2.0 + PKCE(S256)で認証する
- Dynamic Client Registrationに対応し、事前のclient secret発行を前提にしない
- OAuthメタデータをwell-knownで公開する
- Claudeではread系ツールの実動作を確認済み
- Claudeではwrite系toolの公開も確認済みだが、42ツールすべての網羅実行テストは行っていない
- ChatGPTからもKnottleへ接続し、MCP経由でCRMを参照・操作できることを確認済み
- ChatGPTについても42ツールすべてを個別に網羅実行したわけではない
- Knottle側ではChatGPT / Claudeによって公開ツールを出し分けず、同じ42ツールを公開している
Plugin Directoryへの公開自体ももちろん大きかったが、個人的には、
特定のAIサービス向けにCRMを作るのではなく、MCPを境界にして業務ロジックを共通化できる
という点の方が面白いと感じている。
ChatGPTでもClaudeでも、AI側にCRMをコピーするのではなく、Knottleで普段管理している同じ顧客・案件・見積・請求データへMCPを通じてアクセスする。
MCPクライアントが増えても、CRM側の業務ルールをクライアントごとに作り直す必要はない。
今後はChatGPT / Claudeそれぞれで、write系やdestructive系を含む個別ツールの検証結果についても、必要に応じて追記していく予定だ。
参考
- OpenAI「Plugins in ChatGPT and Codex」
- OpenAI「Apps in ChatGPT」
- RFC 7591 — OAuth 2.0 Dynamic Client Registration Protocol
- RFC 8414 — OAuth 2.0 Authorization Server Metadata
- RFC 9728 — OAuth 2.0 Protected Resource Metadata
KnottleのAI連携ページ
https://knottle.amjt.jp/ai-crm
Knottle
https://knottle.amjt.jp/
Freeプランはクレジットカード登録なしで利用できる。