Rewstが正しく解いている部分
まずは正当な評価から始めよう。Rewstは現実の問題を解いている。Rewst(およびLiongardや類似ツール)が登場する前、MSPがテナント横断でPowerShellを自動化する選択肢は二つしかなかった:各クライアントテナントに個別にログインしてローカルでスクリプトを実行するか、サービスアカウントとスケジューラで自前のオーケストレーションを構築するか。どちらもスケールしない。
Rewstは「1つのコントロールプレーンからN個のクライアントテナントに対してPowerShellを実行する」というパターンを製品化した。これは得意な領域だ。採用したMSPは、ユーザープロビジョニング、ライセンス割り当て、グループ管理、メールボックス設定といった繰り返しの作業で、週に確かな時間を節約している。
Rewstが悪い製品だと主張しているわけではない。主張しているのは、設計の軸が間違っているということだ。
スクリプトファースト・アーキテクチャが外しているもの
PowerShellスクリプトは実行成果物だ。コードを読み、実行し、出力を得る。
しかしユーザーをGlobal Adminグループに追加するスクリプトは、単なるコードではない。それは監査人が2年後に再構築したくなる認可イベントだ。ユーザーのパスワードをリセットしてバックアップアドレスにメール送信するスクリプトも、単なるコードではない — コンプライアンスイベントであり、潜在的には法的保全イベントであり、間違ったアドレスが選ばれればクライアント信用イベントにもなり得る。
スクリプトファーストの自動化プラットフォームは、スクリプトを主要な成果物として扱い、ガバナンスは後付けのメタデータとして扱う。実行ログは存在する。承認ワークフローも存在する。リダクション機能もある。しかしそれらはMSPの運用レイヤーの上に重ねられたものであって、最初から組み込まれているわけではない。
実務で何が起こるか:
- 承認レイヤーがワークフロー単位であり、アクション単位ではない。 ワークフローがいったん動き出すと、その中の個々のアクションはアクションごとのレビューなしに実行される。既知の安全イベントでの一括パスワードリセットならそれでいい。分岐のひとつが間違っていたら、そうはいかない。
- ログ内の機密出力はMSPの問題になる。 サービスアカウントのトークン、ワンタイム復旧コード、生成されたパスワード — PowerShellがそれらをstdoutに出せば、実行ログに残る。リダクションはクリーンアップ工程であって、パイプラインの一等機能ではない。
- 監査のストーリーが実行中心であり、変更中心ではない。 「この日、このクライアントテナントに対してどのPowerShellが走ったか」は答えられる。「午後3:47にユーザーXの権限変更を誰が承認したか」は、答えられることもあれば、答えられないこともある — なぜなら承認は個別のイベントではなく、ワークフロー構成の暗黙の結果である可能性があるからだ。
これらは仮定の話ではない。これらこそ、自動化スクリプトの上に運用を築いているMSPに対して、SOC 2レビュアー、CMMCアセッサー、HIPAA監査人が問う具体的な監査質問だ。
ガバナンス・ファースト:何が変わるのか
JieGouの自動化レイヤーは異なる前提から出発する:クライアントテナントはガバナンスの境界であり、その境界をまたぐすべてのアクションはレビュー可能なイベントである。
その帰結は:
-
アクション単位の承認であり、ワークフロー単位ではない。 「CEOのパスワードをリセットして復旧アドレスにメールする」というジョブは、単一のレビュー可能イベントだ。承認者は承認前に、レンダリングされたPowerShell、対象テナント、そのアクションの影響範囲を確認する。ワークフロー単位の承認(Rewst/Liongardモデル)は、レビューポイントと構成ポイントを混同する — 「このワークフローは問題なさそうだ」と一度承認すれば、その分岐はすべて発火する。
-
シャドウモードはワークフローの一バリエーションではなく、一等階層だ。 すべてのアクションはシャドウモードで実行できる:PowerShellは準備され、入力は解決され、出力はMicrosoft Graph / Exchangeなどを呼び出すことなくシミュレートされる。MSPオペレーターは、何が起きたであろうかを正確にレビューする。その後初めて本番に昇格させる。
-
出力リダクションはランナーパイプラインに組み込まれている。 PowerShellランナーはstdout/stderrを捕捉し、リダクション処理(トークン状、パスワード状、その他機密様の文字列を除去)を通してから、リダクションされたバージョンだけを監査ログに保存する。オペレーターがUIで見るのもリダクション済みバージョンだ。生の出力は決して永続化されない。
-
AI生成のアクションも同じパイプラインを通る。 これがアーキテクチャ上の意味ある差異だ。AIドラフトが準備されるとき — それがPowerShellスニペットであれ、チケット応答であれ、工数入力であれ — 人間発起のアクションと同じ承認キューに入る。MSPオペレーターは「AIがやったこと」と「スクリプトがやったこと」を別々にガバナンスする必要がない。キューは一つだ。
-
緊急オーバーライドは監査され、文書化される。 ときには障害が待ってくれない。OwnerとAdminのロールは理由を添えて保留中の承認をオーバーライドできる。オーバーライドのアクション、理由、承認者の身元、元のリクエストはすべて保持される。オーバーライドは緊急用であり、ショートカットではない。
一対一比較の姿
PowerShell Automation機能ページで機能別の比較を公開している。最も重要な行をまとめると:
アクション単位の承認。 Rewst:ワークフロー単位のみ;フローが走り出せば個々のアクションはアクションレビューなしに発火する。 JieGou:個別アクション単位 — レンダリングされたPowerShellを見ながら各変更を承認または却下する。
ワークフローを単一アクションの分岐で設計すれば、この二つは同じだと詭弁は可能だ。確かに。しかしクライアント20社規模のMSPでは、ワークフローはそこまで整然としたままではいられず、スケールとともに大きなワークフローを構成する圧力が増す。アクション単位の承認は、レビュー対象の粒度を正しい場所に保つ。
それでもRewstが正解のとき
すべてのMSPにJieGouが正解だというつもりはない。Rewstの方が適している場合:
- すでにRewstで自動化ライブラリを標準化しているし、チームに1年分のマッスルメモリがある。乗り換えコストは現実的だ。
- MSPの価値提案が「積極的に自動化する、ガバナンスは二次的関心事」。 それは擁護可能なポジショニングだ。JieGouは、ガバナンスを一等市民として扱いたいMSP向けだ。
- 我々が出荷していない特定のRewstネイティブ統合が必要。 一般的なMSP統合(ConnectWise Manage、Microsoft Graph、Exchange、Intune、Azure AD)はカバーしているが、Rewstには一部ニッチでより深いカタログがある。
市場がどこへ向かっていると見ているか
MSPチャネルは「AI for MSPs」の会話に入ってから18ヶ月になる。2つのことが動いた:
-
コンプライアンス購入者(SOC 2証跡をMSA条項に持つMSP)はガバナンス・ネイティブな自動化を求めている。 「ガバナンスを後から付け足す」ではない。MSP運用のために買ったプラットフォームが、そのまま監査人の質問に答えるプラットフォームであること — 同じ監査ログ、同じ承認トレイル、同じリダクション。
-
AI支援アクションとスクリプトアクションは、運用上の意味でもはや別物ではない。 MSPのAIレイヤーがチケット応答をドラフトし、MSPの自動化レイヤーがチケットの工数エントリを書き込み、両者が同じクライアントテナントを通るのなら、それらは一つのパイプラインであるべきだ。調整が必要な二つのパイプラインではなく。
JieGouはこの2つの市場シフトに向けて構築されている。Rewstは違う — 設計上そうなっている。だからといってRewstが間違いなわけではない。異なるMSPのための異なる製品である、ということだ。
その異なるMSPがあなたなら、Rewstを使い続けるべきであり、この記事の残りはあなた向けではない。
もしあなたがガバナンス・ネイティブ、AIネイティブ、監査ネイティブな運用を求めるMSPなら — エンドツーエンドで動くパイプラインをぜひお見せしたい。デモを予約するか、運用漏れ監査を受けるで、現在のギャップがどれだけの代償を払わせているかを確認してほしい。