何が発表されたか
Servalは、企業内の業務自動化を構築するための管理者向けAIエージェント「Catalyst」を木曜日に一般提供（GA）します。特徴的なのは、オプトインではなくデフォルトで有効化する点です。Catalystは同社のAIネイティブなサービスマネジメント基盤の上に乗る「スーパーエージェント」として位置づけられ、チケット履歴、標準作業手順書（SOP）、自然言語の指示を読み取り、繰り返し発生している業務を特定して、ワークフロー・ヘルプデスクのスキル・フォーム・アクセスポリシー・オンボーディング／オフボーディングの一連の流れ・ダッシュボードまでを下書きします。
SOPやスプレッドシートをアップロードして「この手順を実行可能なシステムにして」と頼む、という使い方が想定されています。デモでは、パスワードリセットのワークフローを作る依頼に対し、Catalystが接続済みのOkta、Google Workspace、Microsoft Entraを検出し、実際に処理を行うTypeScriptコードを生成しました。生成物はコードで裏打ちされており、承認ステップの追加や実行権限の制限もかけられます。
なぜ重要か：「聞かれてから動く」を捨てにいっている
今回の本質は自動生成そのものではなく、起点の移動です。共同創業者兼CEOのJake Stauch氏は「今日のAIエージェントの多くは、従業員が質問するかチケットを出すのを待っている。私たちは、従業員がリクエストを出す前に動くAIが未来だと考えている」と述べています。
Catalystが作るバックグラウンドエージェントは、接続システムをスケジュール実行で巡回し、シグナルを相関させて修正案を下書きします。Serval提供の顧客事例では、2拠点にまたがるネットワーク障害について、スイッチのテレメトリ、DHCPデータ、過去チケットを突き合わせ、ハードウェア故障と無線干渉を除外したうえで設定ドリフトに原因を特定し、管理者が承認するための修復ワークフローを生成した、とされています。これは「チケット削減」ではなく「チケットが発生する前の除去」であり、情報システム部門のKPIの置き方そのものを揺らします。
競合はすでに同じ方向に集まっている
この領域はServalの独走ではありません。ServiceNowのBuild Agentは自然言語からアプリケーション・フロー・スクリプト・プラットフォームメタデータを生成し、AI Agent Advisorはインスタンスのレコードを分析して自動化候補を洗い出します。AtlassianのRovoは平易な英語の要件からJiraの「これが起きたらこうする」型の自動化フローを生成し、FreshworksはFreddy AI Agent Studioで30種類を超えるワークフローテンプレートを提供しています。
Servalが差別化として主張するのは、モデルそのものではなくモデルを取り囲むハーネスです。同社は自社基盤モデルを持たず「フロンティアラボ」のモデルを使い、評価（eval）を継続的に回して用途ごとに適したモデルを選ぶモデル非依存の姿勢を取ります。2026年5月のSequoia Capitalとのインタビューで、Stauch氏はエンドユーザー対応とツール呼び出しにはOpenAIのGPT系、コード生成にはAnthropicのSonnetとOpusが最良の結果を出したと語っています。新モデルが出るたびに全ワークロードを自動で移すのではなく、evalで判断するという運用です。企業側が自前のOpenAI／Anthropic APIキーや互換エンドポイントを設定することもできます。
ガバナンスとデータの線引き
Stauch氏は、レガシーなITSM導入がカスタムテーブル・ビジネスルール・ワークフロー・製品固有のノウハウを溜め込み、一見単純な自動化の変更さえ高くつくと指摘します。裏を返せば、AIによる生成が速いほど統制が問われます。
Catalystは操作するユーザーの権限を継承し、そのユーザーのチームワークスペースの範囲に留まります。作られたものはすべて下書きから始まり、公開権限の制限や正式なレビュー・承認の必須化も設定できます。データ面では、Master Services Agreementで顧客が「Customer Materials」（レコード、ドキュメント、ワークフロー、プロンプト、入力、設定）と生成された出力の権利を保持すると定められ、同社は顧客の素材・入力・出力を自社や第三者のAIモデルの学習・ファインチューニング・改善に使わないとしています。
ただし、Stauch氏の「顧客データに触れていない」という表現は、所有権と配置形態についての主張として読むべきです。Data Processing AddendumはServalを処理者と位置づけ、サービス運用・サポート対応・障害診断・プラットフォーム保護のための処理を認めており、認可されたサブプロセッサーが関与し得ます。境界は2層あります——Catalystレベル（ユーザーとワークスペースの権限内）と、プラットフォームレベル（Servalとサブプロセッサーによる処理）です。配置形態は、ク��ウドSaaS、オンプレミス、自社VPCから選べます。自己ホストは、顧客所有のAWSアカウント内にServalが運用するシングルテナント構成（ServalはAWSアカウントへの永続的なIAMアクセスを持たないとされます）と、任意のクラウドまたはオンプレのKubernetesクラスタでの自己管理構成の2択です。
導入効果として同社が挙げるのは自社ケーススタディの数値です。経費・金融テクノロジー企業のRampは、Catalystによりワークフロー構築が50%高速化し、IT、財務、ファシリティ、人事、タレント、法務、事業運営など約10チームへServalの利用を広げたと述べています。
💼 事業会社視点：これは自社にどう効くか
日本企業の情シス・コーポレート部門にとって、この動きは「ヘルプデスクの内製自動化」から「自動化の企画そのものの外注化」への移行を意味します。Catalystは自動化対象が決まる前にヘルプデスクのデータを分析し、繰り返しの申請カテゴリに対して自動化案を下書きして管理者レビューに回します。つまり、稟議の前段にある「どこを自動化すべきか」の棚卸しが、これまで年単位のプロジェクトだった企業ほど圧縮されます。RampがITだけでなく財務・法務・ファシリティを含む約10チームへ広げた事実は、この種のツールが情シス予算内に収まらず、全社のバックオフィス予算に染み出すことを示しています。役員は「ITSMツールの更改」ではなく「間接部門の業務設計の変更」として稟議を読むべきです。
打ち手は三つあります。第一に、ServiceNowやJira Service Managementを使う企業は、Build AgentやRovoの自然言語フロー生成を既存契約内で試し、Servalのような新興を含めた比較の土俵に上げること。カスタムテーブルとビジネスルールを積み上げた既存ITSMほど移行コストが高い一方、放置すれば自動化のたびに費用が積み増す構造は変わりません。第二に、SIerや受託開発事業者は影響が直撃します。社内自動化スクリプトやワークフロー実装は「ソフトウェアエンジニアリングとは別物のコード」であり、まさにここが生成対象です。TypeScriptを生成してOkta・Google Workspace・Entraを叩く領域の人月単価は下がる前提で、承認設計・権限設計・監査対応といったハーネス側に単価の置き場を移す必要があります。第三に、ガバナンス設計を先に決めること。生成物が下書きで始まり公開権限を絞れる仕様は、日本企業の内部統制と相性が良い一方、「デフォルト有効」で入ってくる以上、誰が公開権限を持つかを導入前に決めていないと、統制されていない自動化が静かに増えます。データ面では自社VPCやオンプレのKubernetes配置が選べるため、金融・医療など持ち出し制約の強い業種でも検討の入口には立てます。ただしプラットフォームレベルではサブプロセッサーが関与し得る点を、法務レビューの論点として最初から挙げておくべきです。