ConnectWise Manage統合をゼロから構築した理由

「動く」統合と、本当に機能する統合

統合には2種類あり、ほとんどのプラットフォームは両者を明確に区別しない。

APIコールをラップするタイプ。 プラットフォームはHTTPツールを提供する:GET /v2/tickets、POST /v2/tickets、PATCH /v2/agreements/{id}。ユーザー(またはユーザーのAI)が正しい呼び出し順序を見つける。認証、ページネーション、レート制限はユーザーの問題だ。APIが「Agreement」のような汎用「レコード」型ではないMSP特有の概念を持っていても、統合は知らないし気にしない。

ドメインの言葉を話すタイプ。 プラットフォームは、ConnectWiseのAgreementが単なるレコードではないことを理解する — それは工数が保留金にカウントされるかT&Mレートで請求されるかを司る課金構造だ。Configurationが単なるCRUDオブジェクトではないことを理解する — それはMSPがトラッキングするクライアント資産のインベントリであり、RMMがそこに情報を流し、トリアージAIがコンテキスト対応の応答を生成するために読む必要がある。チケット工数の一括書き込みが「同じエンドポイントにN回POST」ではないことも理解する — それは再試行時の二重請求を防ぐ単一トランザクション操作だ。

ConnectWise Managedについては、我々は2番目のタイプを構築した。

MSPが実際にConnectWiseで何をしているか

コードを書く前に、14社の小規模MSP(技術者4〜25名)に、典型的な1日にConnectWiseの中で実際に何をしているかをインタビューした。パターンは一貫していた:

1. 受信チケットのトリアージ。 サービスデスクがチケットを読み、優先度を割り当て、正しいボードへルーティングする。必要なこと:チケットを読む、クライアントのConfigurationsを読む(AIがコンテキスト対応のレスポンスを起草できるように)、Agreementを読む(AIがSLAティアを理解できるように)、起草した応答を技術レビュー用に内部ノートとして書き込む。

2. チケットに工数を記録する。 技術者は一日の終わり(または金曜の午後)に工数エントリを書く。一人の技術者が15チケットに対して30〜50件のエントリを持つこともある。タイピングそのものが仕事だ。必要なこと:トランザクション的意味論を持つ工数一括書き込み — 再試行が二重投稿にならないように。

3. 請求可能時間とリテナー時間の突き合わせ。 同じ工数エントリが、T&M Agreementとリテナー Agreementでは意味が異なる。必要なこと:Agreementsを読み、それを使って書き込み時に工数を分類する。

4. Configurationsを同期させ続ける。 RMMやモニタリングツールが絶えずConfigurationの更新を生成する。それらを重複作成やユーザー入力ノートの上書きなしにConnectWiseに取り込むのは、継続的な小さな苛立ちの種だ。必要なこと:「各フィードが独自の重複排除ロジックを持つ」のではなく、統合レイヤーでの重複排除。

5. QBR / クライアントレビューパケットを生成する。 毎月または四半期ごとに、Agreementの詳細、Configurationインベントリ、チケット要約、SLAパフォーマンスを引き出す。必要なこと:AIが要約できるように、上記すべてを構造化された方法で読むこと。

どれも「RESTエンドポイントに汎用CRUDを書く」ではない。すべてが統合によるドメイン概念の理解に依存している。

我々が構築したもの

この統合は以下の一等表面を提供する:

Configurations

ConnectWiseのConfigurationsを、JSONブロブではなく構造化オブジェクトとして読み書きする。RMMがConfiguration更新(ソフトウェアインベントリ、ハードウェア変更、パッチ状況)を送ってくると、統合は:

• 同じクライアント+資産の既存Configurationsに対して重複を排除する
• フィードでカバーされないユーザー入力ノートを保持する
• N回の部分更新ではなく、単一のトランザクション更新を書き込む

AIがチケット応答を起草する際、ConnectWise UIをスクレイピングしたりAPIレスポンスをパースしたりせず、構造化ツール経由で関連するConfigurationsを読める。

Agreements

Agreementsをドメインレベルで読み、推論する。Agreementには以下がある:

• 課金モデル(リテナー、T&M、定額、チケットベース)
• カバレッジ範囲(どのservice board、どのconfigurations、どのwork types)
• SLAティア(応答時間、解決時間)
• レートテーブル(技術者タイプ → 請求レート)

統合はこれらすべてを構造化データとしてAIとオペレーターに公開する。MSPのAIがチケット応答を生成するとき、クライアントが「Gold」SLAか「Bronze」SLAかを把握し、それに合わせて起草する。

チケット工数の一括操作

工数入力に1日30分を失っている技術者にとって、これが本命機能だ。

• 一括書き込み — 一人の技術者の1日分50件の工数を単一操作で送信
• トランザクション — いずれかのエントリが失敗したら、バッチはクリーンにロールバック(半書き状態は残さない)
• 重複排除 — オペレーターがタイムアウトで再試行した場合、2回目の試行は1回目の部分状態を検知して完了させる — 二重投稿ではなく
• AI支援マーキング — AIが書き込んだ工数には可視の[AI-Assisted]プレフィックスが付く。MSPは請求書でクライアントに開示するかを選べるが、監査証跡は常に残る。

レート制限と再試行

ConnectWise Manageにはライセンスティアで異なるクライアント別APIレート制限がある。統合は:

• クライアント別レート制限を「429で再試行」ではなく一等概念として尊重する
• グローバルカウンタではなく、クライアントテナントごとのトークンバケットを使用する
• リクエストペイロードから導出された重複排除キーで冪等な再試行を実装する — ネットワーク瞬断での再試行で2回書き込まれないように

クロスアカウント隔離

統合には、クライアントAにスコープされたアクションがクライアントBのデータを読み書きできないことを(たとえ使用中のAPIキーがより広いアクセスを持っていても)特に検証するクロスアカウントセキュリティテストスイートが付属する。テストスイートはCIの一部であり、あらゆる退行をブロックする。

これが監査人の関心事だ。SOC 2やHIPAAコンプライアンスが懸かっているとき、「テナント隔離が機能することをテスト済み」であるかどうかは、クリーンな監査と指摘事項の分かれ目になる。

AIが見るもの

統合は構造化されたMCPツール経由でJieGouのAIレイヤーに公開されている。チケットトリアージを扱うレシピやワークフローは以下のように動く:

read_configurations(client_tenant: "Acme Corp", filter: { active: true })
  → 構造化されたConfigurationsのリストを返す

read_agreement(client_tenant: "Acme Corp", agreement_id: "AGR-123")
  → 課金モデル + SLAティア付きの構造化されたAgreementを返す

draft_ticket_response(ticket_id: "T-456", context: { configurations, agreement })
  → AIがクライアントの具体コンテキストを理解した応答を生成

submit_for_approval(draft, action: "post_to_ticket_notes")
  → シャドウモード承認キューに入る

[オペレーターがレビューして承認]

write_time_entry(ticket_id, hours, description, billable: from_agreement_rules)
  → 統合経由でトランザクション書き込み

AIはConnectWiseのHTTP APIが存在することを知る必要がない。ドメインアクションを組み立てるだけだ。統合が翻訳する。

構築に要したもの

RESTラッパーよりは多く、ゼロからのPSAよりは少ない。カレンダーベースではConnectWiseのセマンティクスに特化したおおむね2スプリントのエンジニアリング、さらにパイロットMSPがエッジケースを表面化させるのに応じた継続的な改善だ。

代替案 — 汎用APIラッパー — なら1スプリントで済んだ。ハッピーパスでは動いただろう。一括工数、再試行重複排除、Agreementレート参照、テナント隔離検証のケースでは失敗していただろう。

PSA統合の深さが購入基準になるMSPのような業種にとって、1スプリント分の追加統合作業は正しいトレードだ。

次にくるもの

現在のロードマップ上:

• ConnectWise Automate統合 — CWスイートのRMM側;同じガバナンスモデル
• ConnectWise PSAレポーティング — MSPがCWで期待するレポート構造をそのまま、AIがスケジュール生成
• Autotask PSA統合 — もうひとつの主要PSA、同じ一等表面パターン

あなたがConnectWise Manageを使うMSPで、我々のアプローチが合っていそうなら、デモを予約してほしい。ライブ統合ウォークスルーをご案内する。別のPSAを使っていて、あなたのツールでこの深さの統合を望むなら、お知らせください — ロードマップは名指しのMSPに応答する。