Slack で承認、時間で外れる Mac の管理者権限。本番前に、外れない道が3本

社員の Mac に管理者権限（アプリを入れたり、大事な設定を変えたりできる権限）を付けた回数を数えたら、3か月で143回あった。そのうち72回は、何のために付けたのかを依頼のチャンネルでたどれなかった。付けたまま外れていないものも1件あり、20日間そのままだった。

ある会社（約90名）の話だ。前の記事で、この依頼の多くはアプリの配り方と設定の穴で、残るものだけを「承認したら時間限定で付ける」にする、と書いた。配り方の直しと並行して、その残る依頼のための仕組みを作った。社内チャット（Slack）で申請し、承認されると1分以内に権限が付き、選んだ時間が来たら外れる。新しいツールは買っていない。

先に断っておくと、この仕組みはまだ本番では動いていない。テスト用の場所で動かして会社の定例で見せ、形が決まり、承認する人たちの了解を待っている段階だ。それでも今の時点で書くのは、作る途中で一番大事なことが分かったからだ。外す仕組みは、一覧に載っている権限しか外さない。そして、一覧に載らないために、時間が来ても外れない道が3本あった。

前半では、何が起きてどう判断したかを書く。設定の名前や細かい手順は、後半の「担当者向け」にまとめた。

▼作った理由：付けるたびに人が要る。数えたら3か月で143回、半分は理由をたどれなかった

この会社は、社員の Mac を JumpCloud（会社の Mac をまとめて管理する仕組み）で管理している。管理者権限が要るときは Slack で依頼を受け、担当者が JumpCloud の画面で付けていた。

JumpCloud の操作の記録で数えると、直近90日（8/7〜11/5）の付与は143回、対象は28人。多い人は15回だ。月別では8月25回（7日以降）、9月43回、10月63回と増えていた（11月は5日までで12回）。これを依頼のチャンネルと突き合わせて、理由で分けた。日時と人で機械的に対応付けたもので、数字は目安だ。

前の記事で分類した約10件は、チャンネルの履歴のうち手元にあった一部だった。全部を突き合わせると、チャンネルに記録のない分が半分あった。月ごとの増え方にどの理由がどれだけ効いたかまでは、分けていない。

もう1つ、作ったあとの 11/5 に数えて分かったことがある。外すのは手作業ではなかった。前の記事には「手作業で付けて、外して」と書いた。実際は、143回のうち139回は JumpCloud の画面で時間を指定して付けられていて、解除142回のうち136回は操作した人がいない、つまり時間で自動で外れていた。いま見ると、困りごとは「外すこと」より次の3つだ。作り始めた理由は1つ目で、2つ目と3つ目は数えて分かった。

• ▶ 付けるたびに人が要る。担当者が休みの日は止まる。承認も休みの日にできないので、承認を開発部のチームリーダーに割り振る話が出ていた
• ▶ 理由が1か所に残らない。上の72回がそれだ。理由をたどれなければ、何を直せば依頼が減るのかも分からない
• ▶ 期限なしでも付けられる。実際に1件、外れないまま残っていた（「一番の注意」で書く）

「配り方で減らすのが先」という方向は変えていない。ただ、前の記事の「大半」は約10件からの見立てで、全体の半分はまだ理由が分からない。配り方・設定の直しは、セキュリティソフトの自動導入のように進んだものと、案の段階のものがある。それと並行して、残る依頼のためにこの仕組みを作った。

▼できあがった形：Slack で申請し、承認されたら1分以内に付き、時間が来たら外れる（本番前）

使う人から見ると、Slack のフォームとボタンだけだ。

裏側では、Slack はスプレッドシートに行を書くだけで、スプレッドシートに付いている小さなプログラム（Google の GAS）が1分ごとに表を見て、JumpCloud を操作する。Slack・スプレッドシート・JumpCloud は、どれも会社がすでに使っているものだ。

最初は「承認する人が押す → 作業する人が『付与する』を押す」の2段にしていた。11/5 の定例で動かして見せると好評で、「付与する」のボタンをなくし、承認されたら即付与と決まった。作業する人の段が残ると、その人が休みの日にそこで止まる。履歴は表に残るので、あとからたどれる。引き換えに、承認する人の判断がそのまま権限になる。必要になれば2段に戻せるように、作りは残してある。

▼作り直した理由：会社の設定が2つ、想定と違った

会社の設定に合わせて、形を2回変えた。10/29 に最初の形を置いて止まり、11/4 に2回作り直した。どちらも原因は技術ではなく、会社の設定だ。

外から呼び出せなかった。設定は緩めなかった

最初の形は、Slack のボタンを押すと、その場でプログラムを呼び出すものだった。ところがこの会社の Google の設定では、プログラムの公開範囲に「全員」を選べず、会社の外にある Slack からの呼び出しが届かなかった。

設定を緩める手は採らなかった。この選択肢は組織の外との共有の設定に連動すると見ていて、緩めれば影響はこの仕組みだけで済まない。仕組みのために、組織の外との共有を広げない。

代わりに、Slack からプログラムを呼ばない形にした。Slack のワークフロー（フォームとボタンで申請の流れを作る Slack の機能）が表に行を書き、プログラムが1分ごとに表を見に行く。引き換えに失ったものは2つある。その場で付かず最大1分待つこと、「今すぐ外す」のボタンがなくなったことだ。早く外すときは、表の解除予定の時刻を書き換える。

結果として、外から呼び出す入口はなくなった。その代わり、表そのものがスイッチになった。表の状態を書き換えれば権限が付いてしまうので、表を編集できる人は情シスだけに、見られる人も数人に絞る。

ボタンで流れを分けられなかった。承認ボタン1つにした

2回目の形では「承認」「却下」の2つのボタンを置き、押した方で流れを変えるつもりだった。ところがこの機能（分岐）はビジネスプラス以上のプランのもので、この会社のプロプランでは画面に出てこなかった。ワークフロー自体はプロプランでも作れるが、分岐は別だ。

プランはそのままで、ボタンを「承認」1つにした。却下するときは、承認する人がスレッドに理由を書く。押されなければそこで止まり、表は「申請中」のまま残る。失ったのは、却下が表に記録されないことだ。このやり方でよいかは、これから会社側と決める。

▼判断の分かれ目：作るかどうかは標準機能で、形は会社の設定で決まる

作る前に、まず管理ツールの標準機能で足りないかを見る。今回の見本では、この比較をしていない（「まだやっていないこと」に書く）。作ると決めたら、形を決めるのは技術より会社の設定だ。担当者や委託先に次を聞けば、どの形になるかの見当がつく。なお「呼び出せる」と「ビジネスプラス以上」の形は、この会社では試していない。

▼一番の注意：外す仕組みは、一覧に載っている権限しか外さない。載らない道が3本あった

自動で外す仕組みは、「外す一覧」に載っているものを順に外す。載っていなければ、何も起きない。本番を始める前に、一覧に載らない管理者権限を3種類見た。

1本目　人が付けた権限：外れないまま20日残っていた1回

最初の形を置いた 10/29 に、付いたままの管理者権限がないかを調べると、1件見つかった。10/9 に付けたものが、20日後も付いたままだった。付け外しを繰り返していた人の、最後の1回だった。

143回のうち139回は時間指定だった。残っていた1件は、時間を指定せずに付けた分だと推定している。時間の指定がなければ JumpCloud は外さないし、外すことを覚えている仕組みもなかった。これは見つけた時点で、自分の判断で外した。

2本目　仕組みの中：お知らせに失敗したら、外す一覧から落ちた

仕組みにしても、同じ漏れは別の形で出た。11/4 の通しのテスト中のことだ。

権限を付けたあと、プログラムは「付けました」と Slack に投稿する。投稿役のアプリ（ボット）をチャンネルに入れておらず、この投稿が失敗した。プログラムはこれを失敗として扱い、表の状態を「エラー」にした。自動で外すのは、状態が「付与中」の行だけだ。権限は付いているのに、その行は外す一覧から落ちた。

気づいたのは、スプレッドシートに「エラー」と出ていたからだ。当時のコードを読み返すと、失敗を知らせる警告も同じボットが同じチャンネルに出す作りだったので、警告も届かなかったはずだ（コードからの推測）。失敗を知らせる道が、失敗した道と同じだった。テスト中で、対象は自分の Mac だった。本番で表を見る人がいなければ、社員の Mac に権限が付いたまま残る。

その行は、解除予定の時刻などをこちらで書き直して仕組みに外させ、ついでに自動解除が動くかを確かめた。そのうえで作りを直した。「権限を付けた・外した」と「それを知らせた」は別のことだ。知らせる方が失敗しても、状態は変えない。失敗したことは表のメモ欄に残す。

ただ、今の形でも塞ぎ切れていない。知らせが届かなかったとき、気づけるのは表のメモ欄を見たときだけだ。

もう1つ、作りを読み返して気づいたことがある。今の仕組みは、JumpCloud に権限を付けるとき期限を渡していない。外すのは全部プログラムの役目だ。これまで JumpCloud が時間で外していたものを、自前に移した形になる。プログラムや鍵、動かしているアカウントが止まれば、その間に付いている権限はすべて残る。どちらも本番までの宿題だ。

3本目　仕組みの外：JumpCloud が管理していない管理者アカウント

3本のうち、承認制そのものを素通りできてしまうのはこれだ。

一部の端末に、JumpCloud の管理外の管理者アカウントが残っていた。JumpCloud が管理していないので、外す一覧のどこにも載らない。そもそも申請も承認も通らない。承認制と時間限定をいくら丁寧に作っても、そのアカウントで入れば管理者になれる。

だからこの扱いは、承認制を本番にする前に決める。消すか、管理の下に入れてパスワードを変えるかだ。試した自分の Mac にも、こうしたアカウントがあった。仕組みの出来より先に確かめるべきことだった。

▼始める前に決めておくこと：承認する人・時間の上限・誰の名前で動かすか

誰が承認するか：開発部のチームリーダーの持ち回り。作る前に話しておく

定例で、承認は開発部のチームリーダーの持ち回りにする案になった。誰か1人が承認すればよい。休みの日に止まらないためだ。チームリーダー本人の申請は、本人では通らないようにプログラムで止めている。ほかの人が押す。

チームリーダーに共有すると、回答は基本的に OK だった。あわせて、手戻りを避けたいので計画の段階で相談してほしい、と言われた。そのとおりだと思う。今回は動くものを先に作り、定例で見せてから共有した。承認する側になる人には、作る前に話す。

運用を始めるのは、チームリーダーの了解が取れてからになった。セットアップなどで時間がかかる例外は、これまでどおり JumpCloud の画面から手で付けてよい、という話も出ている。全部を仕組みに通す必要はない。ただ、手で付ける分は1本目の道なので、時間の指定は外さない。

何時間まで付けるか：1・2・4・8時間。結論は出ていない

前の記事の設計では1時間だったが、作業時間を選ぶ形にした。管理者権限が付いている間は、ほかのアプリも入れられる。付けた・外した記録は JumpCloud に残るが、その間に何をしたかまで追えるかは確かめていない。長いほど、その間にできることも増える。外れたあとも、付いている間に入れたものや変えた設定は残る。一方で短すぎれば、申請のやり直しが増える。定例では結論が出ていない。

延長の扱いも決める必要がある。付いている間に延長のつもりでもう一度申請すると、「もともと付いている」と判断して止まる作りだ。テストでもこの形で付かなかった例があった（原因は推定）。

誰の名前で動かすか：鍵も表もプログラムも、個人に寄せない

プログラムが JumpCloud を操作するには、外から操作するための鍵（API キー）が要る。今の鍵は、会社の管理者の一人の名前で発行されている。そのため JumpCloud の操作の記録では、この仕組みでの付与と解除が全部その人の操作に見える。誰が承認したかは表の側に残るが、記録が2か所に分かれる。その人のアカウントの状態が変われば、仕組みも止まる。

前の記事で「委託先の個人のアカウントで鍵を作らない」と書いた。委託先の個人にはならなかったが、会社の中の個人の名前にはなった。JumpCloud の公式も、管理者個人に紐づく鍵の代わりに、個人に紐づかないサービスアカウントを勧めている。使えるかを確かめて、本番までに名義を決める。

表とプログラムも、見本の間は自分のアカウント（その会社で発行されたもの）で動かしている。1分ごとの実行は作った人のアカウントで動くので、そのアカウントが止まると、付けることも外すことも止まる。本番では情シス用のアカウントと共有の場所に移す。外部の作業者が個人のアカウントを使わない理由は、別の記事にも書いた。

▼まだやっていないこと

この記事を書いた時点（2026年11月6日）で、次の5つは終わっていない。

• ▶ 本番の開始。チームリーダーの了解を待っている。動かすアカウントを移すことと、社内で必要と言われた確認や登録の手続きが何を指し、誰が担当かを確かめることも残っている
• ▶ Mac の上での確認。管理者でない人の端末で、権限が効くか、外したら効かなくなるかを見る。即付与の形での自動解除とお知らせも確かめる
• ▶ JumpCloud の標準の機能と比べること。Mac のメニューバーから申請して承認を受ける機能と、時間を指定して付ける機能がある。公式の説明では、時間が来ると自動で取り消される。外す役を任せられれば、2本目の道は細くなるはずだ。ただ公式のページには、この申請を承認できるのは今のところ管理者だけとある。開発部のチームリーダーに回す形とは合わないかもしれない。実際に比べてはおらず、必要なプランも確かめていない
• ▶ 配り方の直しと、記録のない72回の用途の確認。アプリ置き場を広げる案と画面共有の設定の案は作ってあり、これから話す。前の記事の設計にあった振り分け（置き場にあるアプリは「置き場から」と返す）も、今の形には入っていない
• ▶ 決まっていないこと。時間の上限、鍵の名義、却下の仕方、管理外の管理者アカウントの扱い

▼まとめ：自分の会社で確かめること

承認して時間で外す仕組みは、会社の設定に合わせれば新しいツールを買わずに作れる。ただ、作れば直す人も要るし、外せるのは一覧に載っている権限だけだ。社員の Mac の管理者権限を外している（または外したい）なら、担当者や委託先と次を確かめておけばいい。

• ▶ 作る前に、管理ツールの標準の機能と比べたか。申請・承認・時間指定がどこまであり、誰が承認できるか
• ▶ 管理者権限を、この3か月で何回付けたか。そのうち何回は、理由をあとからたどれるか
• ▶ いま付いたままの人はいないか。期限なしで付けられる状態になっていないか
• ▶ 管理の仕組みが把握していない管理者アカウントが、社員の Mac に残っていないか。社員に渡す前の初期設定で作った共通のアカウントなどだ。あるなら、そのパスワードを誰が知っているか
• ▶ 作る前に、会社の設定を見たか。Google のプログラムを外から呼び出せるか、Slack のプランで流れを分けられるか
• ▶ 承認する側になる人に、作る前に話したか
• ▶ 外す処理や知らせが失敗したとき、誰がどうやって気づけるか。知らせる道が、失敗した道と同じになっていないか
• ▶ 鍵と、仕組みを動かすアカウントが、誰か個人の名前になっていないか

▼担当者向け：設定と手順の詳細

ここからは、実際に設定する人向け。値はすべてダミーで、実際の ID・URL は書いていない。

前半の言い方と、実際の名前

形の移り変わり（4つ）

1つ目で「全員」を選べなかった理由は、組織の外との共有の設定だと見ている。管理者が「全員」にあたる設定を制限できることは公式にあるが、デプロイの画面に出なくなる条件そのものの公式の記述は見つけていない。

ワークフローの組み方

• ▶ フォーム：アプリ名・何のための作業か（必須）、作業時間（ドロップダウン）
• ▶ スプレッドシートに行を追加：受付キーはフォームの完了時刻、状態は 申請中。接続する Google アカウントは作った人のもの（申請者に接続させない）
• ▶ チャンネルへメッセージ：申請の内容、却下はスレッドに理由を、という案内、ボタン「承認」
• ▶ スプレッドシートの行を更新：受付キーで行を探し、状態を 付与依頼、承認者を「承認」を押した人、申請メッセージのリンクを入れる。GAS はこのリンクのスレッドに結果を返す
• ▶ 受付のメッセージ：1分以内に付与されること、付与と解除はスレッドで知らせること

Google スプレッドシートのステップは、標準では作った人のアカウントで動く（Slack ヘルプ）。だから動かすアカウントが個人名だと、ワークフローも一緒に止まる。

表の状態の移り方

GAS が自動で外すのは「付与中」で解除予定を過ぎた行だけだ。2本目の漏れは、ここから外れたことで起きた。作業者の列は消していない。シートの見出しを変えると setup が別のシートを作り、ワークフローの接続が切れるためだ。値が入っている行だけ作業者を確かめるので、2段にも戻せる。

JumpCloud の API

主に使うのはこの3本だ。付け外しは、付けっぱなしの1件を外したときに 204 が返り、外れたことを確認している。

グループ経由でしか端末に紐づいていない人は、op: add で直接の関連付けを足し、外すときに remove する作りにしたが、試していない。Mac への反映は JumpCloud のエージェントの次の連絡のときで、Mac がオンラインである必要がある。公式のブログでは、時間指定の権限の失効に最大10分かかる場合があり、期限が来ても付いている間のシステムの変更は残るとしている。

時間指定を API で使うなら、アクセスリクエストの API（/api/v2/accessrequests）が公式にある。expiry を付けて作ると、その時刻に自動で取り消される。ページには対象の OS と必要なプランの記載がなく、この見本では試していない。これまでの手作業の時間指定と同じ仕組みかも確かめていない。利用者が Mac のメニューバーから申請する標準の申請機能もあり、申請は承認まで保留され、承認後に本人が開始する形だ。承認の流れのページには、この種の申請を承認できるのは今のところ管理者だけとある。プランの記載はなく、今回は比べていない。

鍵については、公式では新しく作る鍵の既定の期限は90日で、無期限も選べる。今回の鍵は期限なしだった。期限を付けるなら、切れると外す処理も止まることを忘れない。サービスアカウントは、個人の管理者に紐づかない代わりに、作成に Billing ロールの管理者が要るとの記述がある。

Slack のボットと GAS の権限

ボットのスコープは chat:write・users:read・users:read.email の3つ。申請者への DM は、スレッドと二重になるのでやめた。お知らせを出すチャンネルにボットを入れておく。入れ忘れが2本目の原因だ。公式によると、すべての公開チャンネルに投稿できる chat:write.public もあるが、今回はチャンネルに入れる形にした。

GAS の権限は、外部への通信・トリガー・スプレッドシート・メールアドレスの4つ。スクリプト プロパティには JC_API_KEY・SLACK_BOT_TOKEN・REQUEST_CHANNEL・APPROVER_IDS・WORKER_IDS などを置き、値はほかに書かない。

インストール型のトリガーは作った人のアカウントで動く。トリガーの合計実行時間の上限は Google Workspace で1日6時間なので、1分ごとなら1回あたり平均15秒が目安になる（計算上の話で、実測はしていない）。

コードの要点

お知らせの失敗で状態を変えない部分と、外すのに失敗した行を残す部分の考え方だけ、簡略化して載せる。

管理外の管理者アカウントの数え方

JumpCloud のシステムインサイトの users で、管理者（admin）かつ uid が 500 以上のアカウントを出し、JumpCloud の関連付けにあるものを除いた。情報の取得日時に幅があり、古い端末の分が混ざる可能性がある。実際に数え方を変えると数字が少し動いたので、一度の数字で決めつけず、端末ごとに確かめる。

回数の数え方

Directory Insights で遡れるのは90日だ。先に、ユーザーと端末の関連付けの変更（update）を数えたときは、8/1〜10/29 で132回（8月27・9月44・10月61）で、付け外しの回数だと見ていた。後で付与と解除を分けて数え直すと、8/7〜11/5 で付与143回、解除142回だった。前半ではこちらを使った。月別が近いので、先の132回はほぼ人が付けた操作で、「付け外し」という呼び方が違っていたとみている（推定）。143回には、11/4 以降の自分のテストの付与も入っているはずで、数回は動く。理由の分類は、付与の時刻の6時間前〜30分後に、その人が投稿したか、メンションされた投稿を探し、本文の語で振り分けた。読めたのは1つのチャンネルだけで、目安だ。

未検証の点

• ▶ ボタンを押せる人をプロプランで絞れるか。絞れなくても GAS の承認者の一覧で止める
• ▶ ワークフローがシートに「人」を書く形（名前・ID・メールアドレス）。GAS はどの形でも引けるようにしたが、表示名が同じ人がいると取り違える
• ▶ 受付キーが分単位で、同じ分に2件来るとぶつかる。本番前に直す
• ▶ Slack のスプレッドシート連携が、Google 側の連携アプリの承認制で止められないか
• ▶ Mac がオフラインのときに、解除の反映がどう遅れるか
• ▶ コードを読む限り、付与の API を呼んだあとの読み直しで失敗すると「エラー」になり、付いていても外す一覧に載らない。試してはいないが、本番前に塞ぐ
• ▶ 見本を一人で試すための、自分の申請を自分で承認できる設定（ALLOW_SELF_APPROVE）は本番で消す