Servalに権限付与まで任せる？｜情シスが残す承認の線

「ツールの利用申請が毎日届くが、やっていることは承認者に回して、グループに足して、返事をするだけ」「AIに答えさせるのはいいが、権限を付けるところまでやらせて本当に大丈夫なのか」——情報システムの担当者と、その上長から同時に出てくる声です。前者は手間の悩みで、後者は統制の悩みです。そして、この2つの間に新しい選択肢が出てきました。社内の問い合わせに答えるAIから、依頼を受けて権限の付与まで実行するAIエージェントへ、ヘルプデスクの道具が移り始めています。問いは「AIに実行させるか」ではありません。本当は「どの手順を人が事前に承認し、どこで人が止められるようにしておくか」です。この記事では、AIを前提に作られたヘルプデスクの基盤 Serval を例に、1件の利用申請が受付から期限切れの取り消しまで進む流れを追い、情シスが手放してよい作業と、残す承認の線を整理します。

Serval は、依頼を実行まで受け持つヘルプデスクの基盤

Serval は、社内の依頼を受け付けて処理する基盤を、AIエージェントを中心に作り直した新興企業の製品です。公式サイトは自社を「AIの時代の企業向けサービス管理」と打ち出し、社員からの依頼、入社と退社の手続き、必要なときだけの権限付与を対象に挙げています。主な利用者は情報システム部門ですが、公式サイトには人事や経理の部門向けの使い方も並んでいます。

中心になるのは、社員の依頼に応えるヘルプデスクのエージェントです。公式サイトによれば、このエージェントは依頼の内容を読み解き、管理者が公開した道具を使って依頼を解決すると説明されています。ここでいう道具は、アカウントを作る、グループに足す、端末を締め出しから戻すといった、手順をコードにしたワークフローです。

依頼の受け口は、公式サイトによれば Slack、Teams、メール、ウェブのポータル、電話などです。社員は普段使っているチャットから「このツールを使いたい」と書けば、エージェントがどのアプリのどの権限が要るかを聞き取り、承認者に回し、付与まで進めます。公式ドキュメントは、アクセスの依頼について「依頼・承認・付与・監査・取り消し」の一連を Serval が受け持つと書いています。

どんな会社で、なぜ国内で知られていないか

Serval の公式サイトには、利用者として Perplexity をはじめとする米国のAIや金融の新興企業の事例が並んでいます。ある顧客は、9,000人の依頼の受け口を Teams の1か所にまとめ、従来のサービス管理の道具を置き換えたと語っています。急成長している米国の新興企業が、従来の重いサービス管理の道具の代わりに選んでいる、というのが現在の客層の姿です。

国内でほとんど知られていない理由は、いくつか考えられます。1つは歴史の浅さで、AIを前提にした新しい世代の製品として、まだ公式の文書と英語の報道が中心です。もう1つは言語と拠点で、日本語の画面や日本の拠点を、公式の情報で確かめることはできませんでした。資金調達の額や出資者の顔ぶれは英語の媒体で報じられていますが、公式の情報で確かめられなかったため、この記事では触れません。

国内の情報システム部門では、サービス管理の道具をすでに入れている会社も多いでしょう。公式ドキュメントによれば、Serval は ServiceNow や Jira などの既存の道具とつないで使うこともできるとされています。既存の道具にAIを載せる段階の考え方は別の記事で扱っているので、ここでは「権限付与を実行するエージェント」の線引きに絞ります。

答えるAIから、実行するAIへ

社内の問い合わせをAIで受ける取り組みは、これまで「答える」ことが中心でした。手順書や規程を読ませて、パスワードの変え方や申請の出し方を答えさせる。答えた後の作業は、社員か情シスが自分でやる、という形です。答えるだけのチャットボットの作り方は別の記事にまとめていますが、そこでは権限が要る問い合わせは人に回すのが原則でした。

Serval のような基盤は、この「人に回していた部分」を実行まで受け持ちます。公式サイトによれば、Okta、Entra、グーグルのグループに人を足したり外したり、退社のときに権限を外してライセンスを回収したりする作業をエージェントが進めます。情シスへの依頼のうち、アカウントの発行、権限の付与、ソフトの利用申請といった定型の依頼は、手順が決まっているぶん、実行まで任せやすい種類です。

ただし、実行まで任せるということは、AIの読み違いが社内の権限の誤りとしてそのまま残るということです。答えを間違えれば社員が困るだけですが、権限を間違えれば、見てはいけない情報に誰かが触れられる状態が続きます。だから、実行するAIでは、AIがどの手順を使い、その手順を誰が承認したかが、統制の中心になります。

1件の利用申請を追ってみる

ここからは、1件の依頼を追いながら考えます。営業部の社員が、Slack で「顧客の資料を共有するための外部のファイル共有ツールを使いたい」と書いたとします。この依頼が、受付、承認者の確認、権限の付与、記録、期限が来たときの取り消しへと進む流れを、段ごとに見ていきます。

各段で見るのは3つです。1つ目は、エージェントがその段でやること。2つ目は、エージェントが使う手順を、誰が事前に承認したか。3つ目は、人がその段で止められる場所です。この3つを段ごとに書き出しておくと、どこまでを自動にし、どこに人を残すかが見えてきます。

段	エージェントがやること	事前に承認した人	人が止める場所
受付	依頼を読み解き、アプリと権限の種類と期間を聞き取る	依頼を受けるアプリの一覧とその説明を決めた情シス	一覧にないアプリの依頼は人に回す
承認者の確認	承認の方針に従って、承認者に回す	承認の方針を設定した管理者と、アプリの持ち主	承認者が却下・期間の短縮をする
権限の付与	公開済みの手順で、グループへの追加や役割の付与を行う	手順を公開した管理者	公開されていない手順は使わせない
記録	依頼から取り消しまでを記録に残す	記録の保存と閲覧の範囲を決めた管理者	記録を見る担当が定期的に読む
期限での取り消し	期間が過ぎたら同じ方法で権限を外す	最長期間を決めた管理者とアプリの持ち主	延長の依頼は再び承認に回す

受付：エージェントは「何を頼まれたか」を聞き取る

最初の段は受付です。社員の書いた依頼は、たいていあいまいです。「ファイル共有ツールを使いたい」だけでは、どのツールの、どの権限で、いつまで使うのかが分かりません。公式ドキュメントによれば、Serval のエージェントは会話の中で、どのアプリのどの水準のアクセスが要るかを一緒に絞り込みます。

ここで情シスが事前に決めておくのは、エージェントが受け付けてよいアプリと権限の一覧です。公式ドキュメントでは、社員が依頼できるアプリの一覧（カタログ）を用意する形が説明されています。一覧に載っていないアプリや、一覧の権限より強い権限の依頼は、エージェントが付与まで進めず、人の担当に回す線を引いておきます。

受付の段でもう1つ決めるのが、業務上の理由を求めるかどうかです。公式ドキュメントによれば、承認の方針で業務上の理由の記入を求められ、Serval は書かれた理由が妥当かを、設定した基準に照らして確かめるとされています。ただし、理由の妥当さの判定はAIの読みであって、承認の代わりではないと位置づけておきます。妥当と判定された理由でも、承認者が中身を読む段は残します。

承認者の確認：方針がなければ自動で通る

2つ目の段は、承認者の確認です。公式ドキュメントによれば、承認の方針では、特定の人、グループ（定足数の指定もできる）、依頼者の上長、アプリやリソースや役割の持ち主を承認者に指定できます。承認の段は順に進み、各段で全員の承認が要るか、誰か1人でよいかを決められます。

ここで見落としてはいけない記述があります。公式ドキュメントには、承認の手続きを設定していない場合、依頼と延長は申請どおりの期間で自動的に承認されると書かれています。設定の漏れが、そのまま承認なしの付与につながるということです。アプリを一覧に足すときに、承認の方針を必ず一緒に決める決まりが要ります。

もう1つ確かめておくのが、自分の依頼を自分で承認できるかどうかです。公式ドキュメントでは、承認者ごと、または手続き全体で、自分の依頼の承認を許すか禁じるかを管理者が決められるとされていますが、既定の値は書かれていませんでした。承認者が自分の依頼を承認できない設定にしておくのが基本です。また、決定がないまま期限（既定で30日）を過ぎた依頼は、権限を付けずに終わるとされています。

権限の付与：公開済みの手順だけを使わせる

3つ目の段が、権限の付与です。承認が下りると、エージェントは公開済みの手順を使って、グループへの追加や役割の付与を行います。公式サイトの説明どおり、ヘルプデスクのエージェントが使うのは管理者が公開した道具です。エージェントが自分で新しいやり方を考えて権限を付けるのではない、というのがこの設計の要です。

では、その手順は誰が作り、誰が公開するのか。公式ドキュメントによれば、手順は言葉で書いた内容から Serval がコードを生成して作り、必要ならコードを直接直せます。手順は書かれたとおりに毎回同じように動き、実行する前に承認を求めたり、誰が実行できるかを絞ったりできるとされています。

手順の公開の権限は、役割で分かれています。公式ドキュメントによれば、下書き役は手順を作って直せますが公開も実行もできず、構築役は手順を公開・削除でき、公開前の手順も実行できます。ここから言えるのは、構築役を持つ人の数が、エージェントが使える手順の入口の数になるということです。構築役は情シスの中の少数に絞り、下書きは広く、公開は少数で、という分担にします。

エージェントは誰の資格で権限を付けるのか

権限の付与を実行するには、Serval が Okta や Entra、グーグルの管理の仕組みにつながっている必要があります。社員一人ひとりの資格ではなく、接続のために預けた管理の資格で、エージェントが権限を書き換える形です。つまり、その接続の資格が持つ権限の広さが、エージェントが動かせる範囲の上限になります。

公式ドキュメントの役割の説明によれば、つなぐ先の仕組みや連携するアプリの設定は、チームの管理役が受け持ちます。また、独自の役割を作るときは、自分が持っている操作しか他人に渡せないとされています。ここから決めておきたいのは、接続の設定を変えられる人を管理役のごく少数に絞ることと、接続のために預ける管理の資格を、付与に必要な範囲だけに絞ることです。

たとえば、グループへの追加だけを任せるなら、接続の資格にはグループの管理だけを許し、全体の管理者の権限は渡しません。接続の資格を全体の管理者で作ってしまうと、手順の誤りや手順の書き換えが、そのまま全社の権限の書き換えにつながります。接続の資格の範囲と持ち主、資格を作り直す時期を、情シスの台帳に書いておきます。

手順を作るAI「Catalyst」に任せる範囲

Serval には、手順そのものを作るエージェントもあります。公式ドキュメントでは、Catalyst は管理者向けのエージェントで、手順や技能、ダッシュボードなどを作ったり直したりできると説明されています。2026年8月20日の米国の技術媒体ベンチャービートの報道によれば、Catalyst は同日に一般提供され、既定で有効になり、ヘルプデスクの過去の依頼を分析して、繰り返しの多い依頼の自動化を下書きするとされています。

安心材料は、Catalyst の作った物が下書きから始まることです。公式ドキュメントによれば、下書きは画面の横に表示されて管理者が確かめ、試してから、設定に応じて直接公開するか、確認の依頼に回します。同じ報道は、公開の権利を絞ったり、正式な確認と承認を経てから有効にしたりできると伝えています。この「確認の依頼に回す」設定を使うのが、権限に関わる手順では基本です。

注意点もあります。同じ報道によれば、Catalyst は操作している人の権限を引き継ぎます。構築役を持つ人が Catalyst に頼めば、その人が公開できる手順を Catalyst も作れます。また、報道では、つないだ仕組みを見張って、依頼が出る前に問題を見つけて直し方を提案するエージェントにも触れていますが、その提供の状態は公式の文書で確かめられませんでした。この記事では提供中の機能として扱いません。

もう1つ、公式ドキュメントによれば、Catalyst はダッシュボードを作るときに、Serval の中のデータに加えて、つないだアプリや公開のAPIのデータも扱えるとされています。手順を作る道具であると同時に、つないだ仕組みのデータを読む道具でもあるということです。Catalyst を使える人を構築役と同じ少数に絞り、誰がどの集計を作ったかを記録の上で追えるようにしておきます。

記録：誰が承認し、どの手順で付けたかを残す

4つ目の段は記録です。公式ドキュメントによれば、アクセスの依頼から取り消しまでの一連が記録され、記録は書き出せるとされています。また、手順の実行のたびの記録と、手順の設定の変更の記録も見られます。管理役は監査の記録を見られ、承認の上書きもできると、役割の説明に書かれています。

記録を残すだけでは足りません。誰が、どの頻度で読むかを決めておきます。たとえば、月に1回、エージェント経由で付けた権限の一覧を情シスの責任者が読み、承認者が適切だったか、期限が長すぎないかを確かめます。管理役による承認の上書きは、件数と理由を必ず見ます。上書きが多いなら、方針の設計が現場に合っていない合図です。

記録には、監査への備えという役目もあります。公式ドキュメントによれば、アクセスの見直しの機能は、社員がまだその権限を必要としているかを確かめる仕組みで、SOC 2 や ISO 27001 などの監査で使う証跡にもなるとされています。付けるときの承認と、後からの見直しを同じ記録の上でつなげることで、監査の準備の手間も減らせます。

期限での取り消し：付ける前に外す日を決める

5つ目の段は、期限が来たときの取り消しです。公式ドキュメントによれば、承認の方針で、自動で取り消すまでの最長期間を決められます。期間は無期限か期限つきかを選べ、承認者は依頼された期間を変えられます。期限が来ると、付けたときと同じ方法で権限が外されるとされています。

ここで情シスが決めておくのは、アプリと権限の重さごとの最長期間です。閲覧だけの権限は長めに、外部と共有できる権限や管理の権限は短めに、というように重さで分けます。無期限を選べる設定があるからといって、既定を無期限にしないことが肝心です。

また、使われていない権限を回収する仕組みも公式ドキュメントに説明されています。期限つきの権限と、使われていない権限の回収を組み合わせると、「付けたまま忘れられる権限」を減らせます。延長の依頼は、最初の承認と同じ方針で、もう一度承認者に回すようにしておきます。

入社と退社のまとめた手続きにも、同じ線を引く

ここまでは1件の利用申請を追いましたが、権限の付与は入社と退社のときにまとめて起きます。公式サイトによれば、Serval は人事システムで採用が確定したときに入社の一連の手続き（ジャーニー）を始め、退社のときには権限を外し、ライセンスを回収し、手作業の残りを担当に割り振るとされています。1件ずつの依頼と違い、1回の合図で、数十の権限がまとめて動くのが特徴です。

まとめて動くぶん、1件の申請とは別の確かめ方が要ります。入社の手続きでは、どの部署にどの権限の組み合わせを最初から付けるかを、部署の責任者と情シスで決めた一覧に基づかせます。一覧にない権限は、入社の手続きの中で付けず、配属が決まった後に1件の申請として承認に回します。入社の一括付与を、承認を飛ばす抜け道にしないことが要点です。

合図の元になる人事システムの情報にも注意が要ります。採用の確定や退職日の入力を誤れば、エージェントはその誤りのとおりに権限を付けたり外したりします。人事の入力から実際に権限が動くまでの間に、情シスが一覧を確かめる段を1つ置くか、少なくとも退社の手続きは人事の確定を待ってから動くようにしておきます。入社した人にAIの道具をいつ渡すかという論点は、別の記事で扱っています。

情シスが残す承認の線

ここまでの5つの段を通して見ると、情シスが残すべきものがはっきりします。エージェントに任せてよいのは、受付の聞き取り、承認者への回付、公開済みの手順の実行、記録、期限での取り消しです。人が持つのは、手順の承認（公開）、承認の方針の設計、特権の付与、例外の判断、退職者の扱いです。

特権の付与は、別の線を引きます。システムの管理者の権限や、全社のデータを見られる権限は、承認の方針があっても、エージェント経由の付与の対象から外し、人が手で付ける形に残すほうが安全です。公式サイトは必要なときだけ特権を付ける機能を挙げていますが、特権の付与だけは、AIが受け付けても人が付けるという線を自社で決めておきます。

退職者の扱いも同じです。公式サイトによれば、退社のときに Serval は権限を外し、ライセンスを回収し、残りの手作業を担当に割り振ります。手順そのものは任せてよいのですが、いつ外すか、データをどう引き継ぐかの判断は、人事と上長と情シスが決めます。退職のときに片づけるAIの項目は、別の記事で一覧にしています。

例外の判断も人に残します。夜間の障害対応で一時的に強い権限が要る場合や、取引先の担当者に社内のアプリを一時的に使わせる場合は、方針の想定の外にある依頼です。こうした依頼は、エージェントが受け付けても付与まで進めず、情シスの当番に回す決まりにします。例外として認めた依頼は、理由と期限を記録に残し、月に1回の見直しで、例外が常態になっていないかを確かめます。

エージェントに実行させない依頼

最後に、承認の方針があっても、エージェントに実行させないほうがよい依頼を挙げます。どれも、手順に書ききれない判断が含まれるか、誤ったときの影響が大きい依頼です。

• システムの管理者権限や、全社のデータを見られる権限の付与
• 退職者や休職者のアカウントの扱いを、人事の確定前に変える依頼
• 承認の方針が設定されていないアプリへの権限の付与（自動承認になる）
• 本人以外の権限を変える依頼（上長が部下の分をまとめて頼む場合も、確認を人が行う）
• 電話で受けた、本人確認のできていないアカウントの復旧の依頼
• 一覧にないアプリや、一覧の権限より強い権限の依頼

電話の依頼については、声だけで本人を判断しないという別の論点があります。ヘルプデスクを狙ったなりすましは、別の記事で扱っています。また、AIエージェント自身の身元をどう扱うかも、別の論点として記事にしています。ここでは、本人確認ができない依頼は、エージェントの実行の対象にしないとだけ決めておきます。

小さく始めて、任せる範囲を広げる順番

Serval のような基盤を入れるときは、最初から全部のアプリの権限付与を任せないことです。効き目が見えやすく、誤ったときの影響が小さい依頼から始め、記録を読んで問題がないことを確かめてから広げます。広げる判断の材料は、承認の上書きの件数、承認者の却下の件数、期限の延長の件数、記録を読んで見つかった誤りの件数です。

この順番で大事なのは、広げるたびに、承認の方針と最長期間を見直すことです。対象のアプリが増えると、方針の設定漏れも起きやすくなります。アプリを一覧に足す作業と、方針を設定する作業を、同じ人が同じ日にやる決まりにしておくと、自動承認の抜けを防げます。

導入の判断と、止め方・費用の増え方

導入を判断するときに、情シスの上長が確かめたいのは3つです。1つ目は、定型の依頼がどれだけあるか。アカウントの発行や権限の付与の依頼が多い会社ほど、効き目が出ます。2つ目は、承認の方針を書けるだけの、アプリの持ち主と権限の一覧が整っているか。3つ目は、手順を公開できる人を少数に絞れるかです。

止め方も決めておきます。公式ドキュメントによれば、チームの管理役は、Serval の機能をチームごとに有効・無効にできます。問題が起きたときに、エージェントによる付与を止め、人の手作業に戻す手順と、その判断をする人を決めておきます。止めている間の依頼をどこで受けるかも、あわせて決めます。

料金の体系は公式サイトで公開されておらず、商談で見積もる形です。費用は、使う人の数や依頼の量、つなぐ仕組みの数が増えるほど増える形が考えられます。安全の面では、公式ドキュメントが SOC 2 の第2種の取得と通信・保存の暗号化を挙げていますが、自社でどの手順を許すかまでを保証するものではない点は押さえておきます。

まとめ

Serval は、社員の依頼を受け、管理者が公開した手順を使ってアカウントの発行や権限の付与まで実行するヘルプデスクの基盤です。1件の利用申請は、受付、承認者の確認、権限の付与、記録、期限での取り消しへと進み、どの段にもエージェントが関わります。だからこそ、情シスが持つべきは手順の公開と承認の方針の設計です。承認の方針がなければ自動で承認される点に注意し、構築役を少数に絞り、Catalyst の作った手順は確認の依頼に回してから公開する。受付・定型の手順の実行・記録はAIに任せ、特権の付与・例外・退職者の扱いは人が決める線を、導入の前に書き出してください。

• 製品の機能と提供状況は、Serval の公式サイトと公式ドキュメントを2026年10月22日に確かめた範囲に基づきます。Catalyst の一般提供の日付と既定の有効化、権限の引き継ぎは、2026年8月20日の米国の技術媒体ベンチャービートの報道によるものです
• 資金調達の額と出資者、日本語の画面と日本の拠点、料金の体系は公式の資料で確かめられなかったため、本文では触れていないか、確かめられなかったと書きました

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。