「このツールを入れたいのですが、申請から何日かかりますか」と開発者が聞き、情シスは「何が入るのか教えてください」と返す。どちらも間違ったことは言っていません。それでも話が進まないのは、見ているものが違うからです。
この記事では、公開されているブログの声とMicrosoftなどの公式の資料をもとに、開発用PCの区分、期限つきの権限、申請票、セキュリティソフトの除外の決め方をまとめます。どちらかを悪者にしない形で、そのまま使えるひな形も付けました。
開発者が困っていること、情シスが心配していること
まず、公開されている声を読んで、双方の事情を並べます。
開発者の側は、ツールの導入で止まる場面があります。情シスの立場で書かれたコラムにも、その事情が出てきます。
たとえば、機械制御系のシステムを開発する場合、機械と接続するためのドライバーの追加が逐次発生するため、そのたびに情シスが入力するのは現実的でありません。
出典: Tech Team Journal(paiza)「ユーザーに管理者権限を与える運用はやめるべき?情シスの視点から解説」(2023年6月5日)
通信の面でも困りごとがあります。社内のプロキシが原因で、gitやaptが急に通らなくなったという愚痴記事があります。
こっちとしては何の相談もなしにProxyにそんな機能が追加された段階でパニックですけどね?
出典: Zenn「会社のLinuxで開発する時の一番の敵はProxyだと思う」(2021年4月8日・坦々狸)
この記事は「ただの愚痴記事です」と自分で断っています。それでも、設定を変える前に一言あれば防げた混乱だと読めます。
一方、情シスの側にも事情があります。上のコラムの筆者は、一般権限への切り替えを一度実施した経験を書いています。
問い合わせが集中すると、休む間もなくユーザーの元に伺っていたため、一日の半分が管理者入力の作業で終わってしまうこともあったほどです。
出典: Tech Team Journal(paiza)「ユーザーに管理者権限を与える運用はやめるべき?情シスの視点から解説」(2023年6月5日)
つまり、権限を渡さない運用は、情シスの作業を増やします。人手が足りないと続かず、このコラムの筆者も途中でやめたと書いています。「渡さない」が正しいか、「渡す」が正しいかではなく、どう運用すれば双方が回るかが問題です。
編集部が公開されている声4件を読んで整理すると、次の表のようになります。
| 場面 |
開発者が困ること |
情シスが心配すること |
折り合いの案 |
| ツールの導入 |
申請から導入まで何日も待つ |
何が入るか分からず、更新も追えない |
許可済みの一覧を作り、一覧の中は申請なしにする |
| ドライバーや環境の追加 |
作業のたびに入力を頼むことになる |
常時の管理者権限は、乗っ取られたときの被害が大きい |
期限つきで権限を渡し、記録を残す |
| セキュリティソフト |
ビルドやテストが遅くなる |
除外すると検出できないものが出る |
範囲と理由を決めて除外し、見直す日を決める |
| プロキシや通信 |
証明書の変更などで突然通らなくなる |
通信を確認する仕組みは残したい |
変更の前に告知し、開発用の手順書を用意する |
| PCの性能 |
標準のPCではメモリが足りない |
機種が増えると管理が重くなる |
開発用の機種を数種類に絞って用意する |
| 事故のとき |
原因を調べたいが、権限がない |
誰が何を入れたか追えない |
操作の記録と、台帳への登録を条件にする |
管理者権限は「全員に常時」か「誰にも渡さない」かの二択ではない
Microsoftの開発環境のゼロトラストの解説は、双方の言い分を並べて書いています。
ルートまたは管理者アクセス権を持つ強力でカスタマイズ可能なマシンが必要です。
出典: Microsoft Learn「ゼロ トラストの開発環境をセキュリティで保護する」(2026年3月26日更新)
同じページは、開発者の要求が、コンプライアンスの規制や、監査・制御の必要とぶつかることも書いています。そのうえで、対策として「最小特権」と「Just-In-Timeアクセス」を挙げ、必要な最短の時間だけアクセスを持たせるようにしています。
Just-In-Time(ジャスト・イン・タイム)は、必要になった時点で、必要な間だけ権限を渡す考え方です。ここから、権限の渡し方を3段階で考えられます。
| 段階 |
渡し方 |
向いている人・作業 |
| 1 |
標準ユーザーのまま。許可済みのツールは、情シスが配る |
開発以外の大半の社員 |
| 2 |
必要なときだけ、特定のアプリや作業に限って昇格する |
多くの開発者の日常の作業 |
| 3 |
開発用PCの区分で、ローカル管理者を期限つきで渡す |
ドライバーや仮想環境など、昇格では足りない作業 |
Intuneの権限昇格(EPM)でできること
MicrosoftのIntuneには、Endpoint Privilege Management(EPM)という機能があります。公式の概要には、標準ユーザーのまま、管理者権限が要る作業を行えるようにする機能だと書かれています。
公式のページで確かめた範囲では、次の点が使えます。
- 昇格のしかたに「ユーザーが確認して昇格」「サポートが承認」「自動」「拒否」がある
- ユーザー確認の昇格では、認証や、業務上の理由の入力を求められる
- 「サポートが承認」では、ユーザーが申請し、管理者が承認すると、昇格できるようになる
- 昇格の記録(監査ログ)が残る
- 対象のファイルは、.exe、.msi、.ps1
- 利用には、テナントでのライセンスが必要
自動の昇格については、広い範囲に当てはめるとセキュリティへの影響が大きいと、公式の概要に書かれています。ルールは、信頼できるファイルに絞って作ります。
なお、EPMはWindows向けです。MacやLinuxの開発者には別の手段が要ります。それぞれの仕組みは、この記事では確かめていないので、書きません。
開発用PCは、一般のPCと区分を分ける
編集部の補足です。1つの決まりを全員に当てるのではなく、区分を分けると、双方の言い分が両立しやすくなります。
| 項目 |
一般の業務PC |
開発用PC |
| 権限 |
標準ユーザー |
標準ユーザー。必要な作業は昇格か、期限つき |
| ソフトの導入 |
情シスが配る |
許可済みの一覧は自分で導入。一覧の外は申請 |
| セキュリティソフト |
標準の設定 |
決めた範囲の除外を認める |
| 通信 |
標準のプロキシ |
開発用の手順書と、必要なら専用の経路 |
| 台帳 |
資産台帳 |
資産台帳に「開発用」と、使う人を記載 |
| 見直し |
年1回 |
半年に1回。権限の棚卸しも |
性能の話も、区分を分ける理由になります。一休のブログは、エンジニア向けのPCの上限について、公開されているルールの中でこう書いています(2019年12月時点)。
16GBでは、メモリを多く消費する開発環境では不足する場合があります。
出典: 一休.com Developers Blog「社内に周知しているパソコン購入・パソコン交換のルール」(2019年12月6日)
同じ記事では、必要な人にメモリの多いデスクトップを追加で支給していることと、情シスが「動作が遅い原因」の相談窓口になっていることも書かれています。記事は2019年のものなので、機種や数字は今と違います。ここで参考にしたいのは、一般の社員とエンジニアで標準の機種を分け、上長の承認と相談のうえで例外を認める、というルールの作り方です。
ソフトの申請を早くする型
待ち時間の多くは、申請の中身を聞き返す往復で生まれます。先に次の2つを用意します。
- 許可済みの一覧: 開発でよく使うツール(エディタ、Git、コンテナの実行環境、言語の実行環境など)を、会社として確認して並べる。一覧の中なら、申請なしで入れてよい
- 申請票: 一覧の外のツールだけ、短い項目で受ける
公開されているブログを読むと、ツールの導入に限らず、申請の窓口が見えないことが不満の元になっています。窓口と目安の日数を決めておくだけでも、待つ側の不安は減ります。
申請票のひな形
【ソフト導入の申請】
ソフト名・バージョン:
配布元のURL:
入れたいPC(資産番号):
使う目的(案件名):
使う期間: 期限なし / 〜年月日
管理者権限: 要 / 不要(要のときは理由)
ほかに代わるものを検討したか:
情シスの返事は、4つに決めておくと早くなります。「許可」「許可(条件つき)」「代わりを提案」「不許可(理由つき)」です。目安の日数(例: 2営業日以内)も書いておきます。
セキュリティソフトの除外は、範囲と理由を決める
ビルドが遅いとき、開発者は「ウイルス対策を止めたい」と考えがちです。情シスは「止めたら守れない」と考えます。間にあるのが、除外の範囲を決める方法です。
Dockerの公式ドキュメントは、ウイルス対策ソフトがDockerの使うファイルをスキャンすると、ファイルがロックされてDockerのコマンドが止まることがあると説明しています。対策の1つはデータフォルダを除外することですが、その代償も書かれています。
- Dockerのイメージ、コンテナーの書き込み領域、ボリューム内のウイルスやマルウェアを検出できなくなる
- 除外した場合は、Dockerを止めてデータフォルダをスキャンし、再起動する作業を定期的に行う方法がある
もう1つの選択肢が、Windows 11のDev Driveです。Microsoftの公式ページによると、Microsoft Defenderの性能モードは、指定したDev Driveの上のファイルのスキャンの影響を減らします。ファイルを開く処理のあとにスキャンする(非同期)ので、速くなるかわりに保護は弱くなります。同じページは、フォルダの除外のようにスキャンそのものを止める方法より、保護が強いと説明しています。
条件も書かれています。使えるのはDev Driveの上だけで、リアルタイム保護が有効なこと、Microsoft Defenderが主のウイルス対策であることなどが必要です。別の製品を使っている会社では、そのまま使えません。
除外の決め方のひな形
| 決めること |
例 |
| 何を除外するか |
作業用フォルダ(例: D:\work)と、ビルドツールのプロセス |
| 何を除外しないか |
ダウンロードフォルダ、メールの添付、デスクトップ |
| 誰に認めるか |
開発用PCの登録がある人 |
| 代わりの守り |
除外したフォルダは、週1回など決めて全体をスキャン |
| 見直し |
半年に1回。使っていない除外は消す |
実際の画面の操作は、使っている製品によって違います。製品の公式の手順を、情シスが確かめてから案内してください。
通信の変更は、前もって知らせる
プロキシの話は、開発者の声に多く出てきます。NRIネットコムの社員のブログは、入社3日目にpipでライブラリを入れようとして、プロキシで止まった体験を書いています。コマンドの書き方や環境変数の設定は、その会社の研修で教わる内容でした。
つまり、手順が文書になっていて、教わる場があれば、新しい人もつまずきを早く越えられます。情シスが用意するものは次のとおりです。
- プロキシのアドレスとポートの調べ方
- git、pip、npm、Dockerなど、よく使うツール別の設定の例
- 通信を確認する仕組みで使う証明書の入れ方(使っているときだけ)
- 設定を変えるときの、事前の告知(日付と、影響を受けそうなツール)
先ほどのZennの記事は、プロキシを避ける裏道も書いていますが、会社の決まりに反する方法なので、ここでは取り上げません。裏道が使われる前に、正式な手順を用意するほうが安全です。
話し合いの場を、年に何回か持つ
編集部の補足です。申請票や区分は、作って終わりにすると古くなります。開発部門の代表者と情シスが、四半期に1回、30分ほど集まる場があると、次のことを決められます。
- 許可済みの一覧に足すもの、外すもの
- 除外の見直し
- 期限つきの権限の利用状況(誰が、何のために使ったか)
- 次の機種更新の要望
「困りごとを持ち寄る場」にすると、申請の往復が減ります。情シスエンジニアと開発者がお互いをどう見ているかは、情シスエンジニア vs 非情シスエンジニアでも書きました。
今日からできること
- 開発部門に聞く: 「この3か月で、管理者権限やソフトの申請で止まった作業は何ですか」。件数と待った日数だけでよい
- 開発者が使うツールを10個ほど挙げてもらい、情シスが確認して、許可済みの一覧の最初の版を作る
- 上の申請票を、社内の申請の窓口に置く。返事の目安の日数も決める
- 開発用PCを、資産台帳で「開発用」と分かるようにする。区分を分ける第一歩になる
- 使っているセキュリティソフトの公式の資料で、除外の設定の方法と注意を確かめる。確かめた内容を、除外の決め方の表に当てはめる
権限の話は、「渡す」「渡さない」で言い合うと止まってしまいます。止まっている作業を数え、渡す範囲と期間と記録を決めるところから始めると、双方が話しやすくなります。