【2026年8月最新】Linuxのユーザー一覧を確認する方法とは？「誰がアクセスできる状態か」を非エンジニアでも把握する考え方
aikanri-admin「退職した社員のアカウントは、ちゃんと消えているだろうか」「業務委託の担当者に渡したサーバーアクセス権は、今も生きたままになっていないか」——サーバーやクラウドの管理画面を人任せにしている経営者・管理職ほど、こうした不安を漠然と抱えたまま放置しがちです。
この「今、そのサーバーやシステムに誰がアクセスできる状態になっているか」を確認する作業は、Linux（多くのWebサーバーや業務システムの土台になっているOS）の世界では「ユーザー一覧を確認する」という、ごく基本的な操作として扱われています。cat /etc/passwdやwhoといったコマンドを打てば、一覧はすぐに手に入ります。
代表菅澤
AI鬼管理山崎
この記事を最後まで読むと、次の内容が理解できます。
01 WHAT IS USER LIST 「ユーザー一覧を確認する」とは何か・オフィスの入退室権限リストの比喩で理解する サーバーに「入れる状態」になっているアカウントを、一つ残らず洗い出す作業
Linuxでいう「ユーザー一覧を確認する」とは、そのサーバー（コンピュータ）に登録されているアカウント（ユーザー）を、すべて一覧として洗い出す作業のことです。Linuxサーバーは、あらかじめ登録されたアカウントを持つ人（や、プログラムが内部的に使う特別なアカウント）だけがログインしたり操作したりできる仕組みになっています。
📚 用語解説
ユーザーアカウント（Linux）：Linuxサーバーにログイン・操作するための権利を持つ「登録者」のこと。人間が使うアカウントだけでなく、Webサーバーソフトやバックアップ処理など、プログラムが裏側で使う「システムアカウント」も含まれる。1台のサーバーには通常、人間用よりもシステム用アカウントの方が多く登録されている。
この考え方は、オフィスの入退室管理に例えると理解しやすくなります。多くの会社では、社員証や入退室カードを発行するたびに「誰にどの権限のカードを渡したか」を台帳で管理しています。退職者が出れば台帳からカードを削除し、定期的に台帳と実際のカード保持者を突き合わせて「今、誰が入れる状態になっているか」を棚卸しするはずです。
発行台帳を見る
誰にカードを
渡したか一覧化
保持者を突き合わせる
退職者のカードは
回収済みか確認
ないか確認
身に覚えのない
カードはないか
台帳を修正
権限を削除・
見直す
Linuxサーバーの「ユーザー一覧を確認する」作業も、これとまったく同じ発想です。サーバーという“建物”に、誰が“入館証（アカウント）”を持った状態になっているかを一覧で洗い出し、想定外の人物や不要になったアカウントが残っていないかを点検します。競合サイトで紹介されているようなcat /etc/passwdやgetent passwdといったコマンドは、この「台帳を開く」動作に相当します。
代表菅澤
02 WHY IT MATTERS なぜ経営者・管理職がユーザー一覧を気にすべきか 「誰がアクセスできる状態か」を放置すると起きる3つのリスク
「ユーザー一覧の確認なんて、エンジニアやインフラ担当者の仕事では」と思われるかもしれません。しかし、サーバーやシステムへのアクセス権限は、実質的に会社の重要な情報資産への「入館証」そのものです。この管理を現場任せにしたまま放置していると、経営リスクに直結する問題が静かに積み上がっていきます。
2-1. リスク1：退職者・契約終了した業務委託のアカウントが残る
最も典型的なのが、退職した社員や契約が終わった外部業者のアカウントが、削除されないままサーバーに残り続けるケースです。人事側での退職手続きと、サーバー側でのアカウント削除は別の作業であるため、連携が取れていないと簡単に発生します。誰も使っていないはずのアカウントが有効な状態というのは、それ自体がセキュリティ上の穴になります。
2-2. リスク2：不正アクセス・不審なアカウント作成に気づけない
サーバーが外部から侵入された場合、攻撃者は自分専用のアカウントをこっそり作成して、いつでも出入りできるようにする手口をよく使います。定期的にユーザー一覧を確認していなければ、こうした不審なアカウントの存在に何ヶ月も気づけないという事態になりかねません。
2-3. リスク3：監査・棚卸しの根拠資料が用意できない
取引先や監査法人から「御社のシステムには誰がアクセスできますか」と聞かれたとき、その場で正確な一覧を提示できない会社は少なくありません。ユーザー一覧の確認を定期業務として組み込んでおくことは、セキュリティ対策であると同時に、説明責任を果たすための備えでもあります。
📚 用語解説
アクセス権限監査：「誰が、どのシステムに、どこまでアクセスできる状態になっているか」を定期的に洗い出し、不要な権限や想定外のアカウントがないかを点検すること。オフィスの入退室権限点検のサーバー版にあたる。情報セキュリティの基本対策の一つとして、多くのガイドラインで定期実施が推奨されている。
ここまで読むと「結局、コマンドを覚えて自分で確認しないといけないのか」と身構えるかもしれません。しかし実際には、コマンドの構文を一つも暗記する必要はありません。「サーバーに今、誰がアクセスできる状態になっているか調べて」と日本語でClaude Code（後述するAIエージェントツール）に伝えるだけで、必要なコマンドを判断して実行し、結果を報告してもらうことができます。具体的な使い方は11章・12章で詳しく解説します。
AI鬼管理山崎
03 ETC PASSWD /etc/passwd：サーバーに登録された全アカウントの台帳 Linuxサーバーが持つ、すべてのアカウントを記録した最も基本的な名簿ファイル
Linuxサーバーには、/etc/passwdという1つのテキストファイルがあり、ここにサーバー上のすべてのアカウント情報が記録されています。ファイル名に「passwd（パスワード）」と入っていますが、実際にパスワードそのものが書かれているわけではなく、「どんなアカウントが、どんな設定で登録されているか」という台帳だと考えると理解しやすくなります。
/etc/passwdに載っているのはそのサーバーに定義されている、あらゆるアカウントです。人間が使う一般ユーザーのアカウントだけでなく、Webサーバーソフトやメール配送プログラムなどが内部的に使う「システムアカウント」も大量に含まれます。「今この瞬間サーバーを操作している人」を確認したい場合は、後述するwho・wコマンドを使う必要があります。混同すると「アカウントが大量にあるのに誰も使っていない」と誤解してしまうので注意してください。
/etc/passwdの各行は、コロン（:）で区切られた7つの項目で構成されています。
| 項目（列） | 例 | 意味 |
|---|---|---|
| ユーザー名 | kohei | ログイン時に使うアカウント名 |
| パスワード欄 | x | 実際のパスワードは別ファイルにハッシュ化（不可逆な変換）して保管されており、ここは通常「x」の記号だけが入る |
| UID（ユーザーID） | 1000 | アカウントを識別する番号。0はroot（管理者）専用 |
| GID（グループID） | 1000 | そのアカウントが所属するグループの番号 |
| コメント | Kohei Sugasawa | アカウントの説明（氏名など、空欄のことも多い） |
| ホームディレクトリ | /home/kohei | ログイン後の作業起点となる自分専用フォルダの場所 |
| シェル | /bin/bash | ログイン時に起動する操作用プログラム。無効化されたアカウントは/usr/sbin/nologinなどになる |
📚 用語解説
UID / GID：UIDは「User ID」の略で、各アカウントに割り振られる識別番号。GIDは「Group ID」の略で、アカウントが所属するグループの識別番号。名前は変更されてもUID・GIDが同じであれば、Linuxの内部処理上は「同一のアカウント」として扱われる。UID=0は特別な意味を持ち、root（最上位の管理者権限）専用の番号として予約されている。
代表菅澤
04 READING PASSWD catコマンドで/etc/passwdを読む実例 「人間が使うアカウント」だけを見分けるコツ
/etc/passwdの中身を画面に表示するには、ファイルの内容をそのまま表示するcatコマンドを使うのが最もシンプルな方法です。
# /etc/passwd の中身をすべて表示する（一例。実際の出力はサーバーごとに異なる） $ cat /etc/passwd root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin kohei:x:1000:1000:Kohei Sugasawa:/home/kohei:/bin/bash deploy:x:1001:1001:Deploy User:/home/deploy:/bin/bash
この出力を見ると、rootやdaemon、www-dataのような、人間が普段ログインするわけではない「システム用のアカウント」が並んでいることが分かります。実際に社員がログインして使うアカウントは、多くの場合UID（ユーザーID）が1000番以降に割り振られています。
# UIDが1000以上（一般的に「人間用アカウント」とされる範囲）だけを絞り込む例
$ awk -F: '$3 >= 1000 && $3 != 65534 {print $1, $3}' /etc/passwd
kohei 1000
deploy 1001
このように条件を絞り込んで表示すれば、「実際に人間が使っている可能性が高いアカウント」だけを効率よく確認できます。ただし、この1000番という閾値はディストリビューション（Linuxの種類）によって多少異なることがあるため、絶対的な基準ではなく目安として扱ってください。
cat /etc/passwdで全アカウントを一覧表示できる/usr/sbin/nologinがシェル欄にあるアカウントは、ログインできない設定になっている
AI鬼管理山崎
05 GETENT PASSWD getent passwd：組織のディレクトリサービスも含めて確認する /etc/passwdだけでは見えない「外部で管理されているアカウント」まで含めて確認する方法
多くの会社では、Linuxサーバー単体でアカウントを管理するのではなく、LDAPやActive Directoryのような「社員アカウントを一元管理する仕組み（ディレクトリサービス）」と連携させて運用しています。この場合、そのサーバーにログインできるアカウントの一部は/etc/passwdには載っておらず、外部のディレクトリサービス側で管理されています。
📚 用語解説
NSS（Name Service Switch）：Linuxが「ユーザー情報をどこから取得するか」を切り替える仕組み。設定次第で、ローカルの/etc/passwdだけでなく、LDAPやNIS、Active Directoryといった外部のディレクトリサービスに登録された情報も、あたかも1つの名簿のように統合して参照できる。この仕組みを利用してアカウント情報を取得するコマンドがgetentである。
こうした外部連携も含めて、そのサーバーにログインできる可能性のある全アカウントを確認したい場合に使うのがgetent passwdコマンドです。
# NSSの設定に従って、ローカル+外部ディレクトリサービスのアカウントを統合表示する $ getent passwd root:x:0:0:root:/root:/bin/bash kohei:x:1000:1000:Kohei Sugasawa:/home/kohei:/bin/bash ldap-user01:x:20001:20001:LDAP経由のアカウント:/home/ldap-user01:/bin/bash
多くの中小規模のサーバー（LDAPなどの外部連携を組んでいない環境）では、NSSの参照先がローカルの/etc/passwdだけに設定されているため、getent passwdの結果はcat /etc/passwdとほぼ同じになります。違いが出るのは、社内の統合認証基盤（LDAP・Active Directoryなど）と連携している、比較的規模の大きい組織のサーバーです。
getent passwdは「NSSの設定に従って見える範囲」を表示するものであり、設定内容によっては外部ディレクトリサービス側の障害・接続不良で、本来存在するはずのアカウントが一時的に表示されないこともあります。「重要なアカウント点検」を行う際は、可能であればディレクトリサービス側の管理コンソールでも突き合わせて確認するのが安全です。
代表菅澤
06 WHO AND W who・wコマンド：「今まさにログイン中の人」を確認する 登録されているアカウントの数と、現在の利用状況はまったく別の話
/etc/passwdやgetent passwdが「そのサーバーに登録されている全アカウント（台帳）」を確認するものだったのに対し、whoとwコマンドは「今この瞬間、実際にログインしているセッション」だけを表示します。
📚 用語解説
セッション：ユーザーがサーバーに接続してから切断するまでの、一続きの利用状態のこと。同じアカウントで複数の場所から同時に接続すれば、1つのアカウントに対して複数のセッションが存在することもある。who・wコマンドは「アカウント」ではなく、この「今つながっているセッション」の単位で表示する。
# 今ログイン中のユーザーだけを一覧表示する $ who kohei pts/0 2026-08-01 09:12 (203.0.113.10) deploy pts/1 2026-08-01 09:40 (203.0.113.55) # who に加えて「何をしているか」も表示する $ w 09:45:01 up 12 days, 3:20, 2 users, load average: 0.15, 0.10, 0.08 USER TTY FROM LOGIN@ IDLE WHAT kohei pts/0 203.0.113.10 09:12 0.00s vim config.json deploy pts/1 203.0.113.55 09:40 2:15 -bash
この出力から分かるように、whoは「誰が、いつ、どこから接続しているか」、wはそれに加えて「サーバーの負荷状況」と「各セッションが今どんな操作をしているか」まで表示します。/etc/passwdに数十件のアカウントが登録されていても、who・wで表示されるのは今まさに接続中の数件だけ、というのが通常の状態です。
getent passwd
登録済みの
全アカウント台帳
ログイン中とは限らない
大半は普段
接続していない
今この瞬間
接続中のセッション
「利用中の数」は別
両方を見て
初めて全体像
AI鬼管理山崎
07 COMPARISON 「登録アカウント」と「ログイン中の人」の違いを整理する 4つのコマンドを、目的別に一枚の比較表で押さえる
ここまで紹介した/etc/passwd・getent passwd・who・wに加え、過去のログイン履歴を確認するlastコマンドも含めて、目的別に整理しておきます。
📚 用語解説
lastコマンド：過去にサーバーへログインした履歴（誰が、いつ、いつまで接続していたか）を一覧表示するコマンド。who・wが「今この瞬間」の状態しか見せないのに対し、lastは記録が残っている限りの過去分を遡って確認できる。「先月このアカウントは本当に使われていたか」を調べたいときに使う。
| コマンド | 確認できる内容 | 対象の時間軸 | 向いている用途 |
|---|---|---|---|
| cat /etc/passwd | サーバーのローカルに登録されている全アカウント | 現在の設定状態（スナップショット） | そのサーバー単体の登録アカウント一覧の確認 |
| getent passwd | ローカル＋NSS経由で参照可能な外部ディレクトリサービスのアカウントも含めた全体 | 現在の設定状態（スナップショット） | 組織で統合認証基盤を使っている場合の全体確認 |
| who | 今まさにログイン中のセッション（誰が・いつから・どこから） | 現在この瞬間 | 「今、誰がサーバーに入っているか」のリアルタイム確認 |
| w | whoの情報＋各セッションが今している操作・サーバー負荷 | 現在この瞬間 | who以上に詳しく「今何をしているか」まで知りたいとき |
| last | 過去のログイン履歴（誰が・いつ・どのくらい接続していたか） | 過去（記録が残る範囲） | 特定アカウントが実際に使われていたかを遡って確認 |
この記事で最も誤解されやすいポイントです。/etc/passwdやgetent passwdに載っているアカウント数がそのまま「今サーバーを使っている人数」ではありません。逆に、whoやwに表示されないからといって、そのアカウントが不要というわけでもありません（単にログインしていないだけの可能性があります）。「登録されているか」と「今使われているか」は、必ず分けて確認してください。
代表菅澤
08 PRACTICAL PATTERNS 実務でのユーザー一覧確認パターン集 退職者チェック・不審アカウント発見・定期棚卸しの具体例
ここまでの知識を組み合わせると、実務でよくある「アクセス管理の確認作業」の多くをカバーできます。代表的なパターンを紹介します。
8-1. 退職者・契約終了者のアカウントが残っていないかチェックする
# 人間用アカウント（UID1000以降）の一覧を、退職者リストと突き合わせる想定
$ awk -F: '$3 >= 1000 && $3 != 65534 {print $1}' /etc/passwd
kohei
deploy
former-employee-a ← 退職済みのはずの名前が残っていないか確認する
8-2. 直近のログイン履歴で「使われていないアカウント」を洗い出す
# lastlog：全アカウントの最終ログイン日時を一覧表示する（一例） $ lastlog Username Port From Latest root **Never logged in** kohei pts/0 203.0.113.10 Fri Aug 1 09:12:00 +0900 2026 former-employee-a **Never logged in**
8-3. 管理者権限（root相当）を持つアカウントを絞り込む
# UIDが0（root）のアカウント、または管理者グループに所属するアカウントを確認する例
$ awk -F: '$3 == 0 {print $1}' /etc/passwd
root
$ getent group sudo
sudo:x:27:kohei,deploy ← sudo（管理者権限で操作できる）グループの所属者一覧
ユーザー一覧の確認は、問題が起きてから慌てて行うものではなく、月次・四半期などあらかじめ決めたタイミングで定期的に実施することに意味があります。オフィスの入退室カード点検と同じで、平常時からの積み重ねが不正利用の早期発見につながります。
AI鬼管理山崎
09 GENAI CASE DATA 【独自データ】GENAI実運用におけるアクセス権限確認業務の実態 「誰がアクセスできる状態か」の点検に、どれだけの業務時間がかかっていたか
ここでは、弊社（株式会社GENAI）が実際にサーバー・システムのアクセス権限点検にどの程度の業務時間を費やしていたか、社内の実運用データをもとに紹介します。ユーザー一覧の確認そのものはコマンド1つで完了しますが、「その結果をどう解釈し、何を次のアクションにつなげるか」という判断・レポート作成の時間が、見えにくいコストになっているケースが多くあります。
| 項目 | 内容 |
|---|---|
| 利用プラン | Claude Max 20x（月額$200／約30,000円） |
| 利用開始 | 2025年後半〜 |
| 適用範囲 | 経営・営業・広告・開発・経理・秘書業務・個人業務まで全社 |
| アクセス管理関連の主な用途 | サーバーユーザー一覧の定期点検・退職者アカウント確認・権限棚卸しレポート作成 |
弊社では複数のWebサーバーとクラウド上のサービスを運用しており、「このサーバーに今誰がアクセスできる状態か」「先月退職したスタッフのアカウントは削除されているか」といった確認作業が定常的に発生します。以前はこうした確認のたびに、担当者がコマンドを実行し、出力結果を目視で確認し、報告用に整理し直すという手順を踏んでいました。
| 業務領域 | 主な用途 | 概算削減時間（肌感ベース） |
|---|---|---|
| 開発・インフラ（アクセス権限点検） | ユーザー一覧確認・退職者アカウント棚卸し・権限レポート作成 | 都度数時間削減 |
| 広告運用 | 週次レポート・CPA分析・配信内容調整 | 週10h → 週1h |
| 秘書業務 | 日報生成・議事録・スケジュール調整 | 日2h → 日15分 |
上記は弊社の肌感ベースの数値であり、業種・業態・担当者のスキルによって削減時間は変動します。「完全自動化」ではなく、人間のレビュー・最終判断を伴う運用である点にもご留意ください。
特にアクセス権限点検は、本記事で紹介した「登録アカウントの一覧」と「実際の利用状況」を突き合わせる作業がそのまま活きる領域です。ただし実務では、「今回はどのコマンドを組み合わせて、何を基準に“不審”と判断するか」を都度考える作業が、これまでのボトルネックでした。
AI鬼管理山崎
10 COMMON PITFALLS 【独自】非エンジニアがユーザー管理でつまずく3つの罠 つまずきやすいポイントとチェックリスト
ユーザー一覧の確認自体は構文がシンプルですが、非エンジニアの方が独学でアクセス権限管理に触れ始めると、共通してつまずくポイントがあります。ここでは代表的な3つの罠と、その回避方法を整理します。
10-1. 罠1：登録アカウント数を「利用人数」だと誤解する
7章で紹介したとおり、/etc/passwdやgetent passwdに載っているのは登録されている全アカウントであり、そのほとんどはシステムが内部的に使うアカウントです。「サーバーにアカウントが80件もある、大丈夫か」と過剰に不安になったり、逆に「数件しかないから安全」と過小評価したりする前に、まず人間用アカウントとシステム用アカウントを分けて考える必要があります。
10-2. 罠2：who・wの結果だけで「全体の利用状況」を判断してしまう
who・wは今この瞬間のスナップショットにすぎません。深夜や休日に確認して「誰もログインしていない、安全だ」と結論づけるのは早計です。継続的な監視や、lastコマンドによる過去の履歴確認と組み合わせて、初めて実態に近い判断ができます。
10-3. 罠3：見よう見まねでroot権限のコマンドを実行してしまう
ユーザー一覧を確認した結果、「不要なアカウントを削除しよう」「権限を変更しよう」と自己判断でroot権限のコマンドを実行してしまうのは危険です。アカウントの削除や権限変更は、対象を誤ると業務システムが正常に動かなくなる重大な操作です。確認と変更は明確に分け、変更が必要な場合は必ず知見のある担当者やAIツールに相談してから、慎重に進めてください。
混同していないか
判断していないか
分けているか
必ず相談・確認
代表菅澤
ユーザーアカウントの削除やroot権限の付与・剥奪は、対象や条件を一つ間違えるだけで業務システムが停止したり、必要な人がアクセスできなくなったりする、取り返しのつきにくい操作です。「確認」と「変更」は必ず別の作業として扱い、変更を伴う操作の前には、内容を人（または信頼できるAIツール）に一度説明してもらい、影響範囲を理解した上で実行してください。「とりあえずroot権限で実行すれば直る」という発想は避けるべきです。
11 WITH CLAUDE CODE コマンドを覚えなくても、確認したいことを日本語で伝えればClaude Codeが調べて報告する /etc/passwd・getent・who・wを一つひとつ暗記しなくても、目的さえ言えれば調査される
ここまで見てきたとおり、ユーザー一覧の確認そのものはシンプルでも、/etc/passwdとgetent passwdの違い・who/wとlastの時間軸の違い・人間用アカウントとシステムアカウントの見分け方など、正しく状況を把握するには気をつけるべき点が少なくありません。10章で挙げたような「登録数と利用人数の混同」「スナップショットだけでの判断」「確認と変更を分けずに進めてしまう」といった落とし穴を踏まずに、毎回正確な点検を行うのは、コマンド操作に慣れていない人ほどハードルが高いのが実情です。
この「何を確認したいかを整理し、適切なコマンドを組み合わせ、結果を業務の言葉で解釈し、報告する」という一連の作業は、Claude Codeのようなエージェント型AIツールに日本語でそのまま依頼できる領域です。/etc/passwd・getent・who・w・lastといったコマンドや構文を暗記する必要はなく、「このサーバーに今誰がアクセスできる状態か調べて」「先月退職したスタッフのアカウントが残っていないか確認して」という要件をそのまま伝えるだけで、どのコマンドをどう組み合わせるべきかまで含めて調査し、結果を報告してもらえます。
📚 用語解説
Claude Code：Anthropic社が提供するAIエージェントツール。チャット形式で「〇〇を確認して」と指示するだけで、必要なコマンドを判断し、サーバー上で実行し、結果を人間向けの言葉に整理して報告するところまでを自律的に行う。ターミナル版だけでなく、ターミナル操作が不要なデスクトップ版も提供されており、非エンジニアでも日本語の指示だけで調査を任せられる。/etc/passwdとgetentの違いやコマンドの構文を暗記していなくても、目的を伝えるだけで正しい調査結果が得られる。
// Claude Codeへの依頼イメージ（実際はチャットで日本語のまま指示するだけ） // 依頼例： // 「このサーバーに登録されている人間用のアカウントを一覧にして、 // 先月退職した“former-employee-a”というアカウントが // まだ残っているかどうか教えて。もし残っていたら、 // 削除する前に一度確認を取りたい」 // Claude Codeが行う調査イメージ： // 1. /etc/passwd から UID1000以降のアカウントを抽出 // 2. former-employee-a の有無を確認 // 3. lastlog でそのアカウントの最終ログイン日時も確認 // 4. 結果を業務の言葉でまとめて報告 // （例：「former-employee-a は現在も登録されたままです。 // 最終ログインは退職日の3日前で、それ以降のログイン記録はありません。 // 削除してよいか、念のためご確認ください」）
この依頼の中で、「人間用アカウントだけに絞り込むべきか」「lastlogも合わせて確認すべきか」「削除は自分で判断せず確認を挟むべきか」といった、この記事で説明してきた判断がすべて自動的に反映されている点に注目してください。/etc/passwd・getent・who・wの意味を一つひとつ覚えていなくても、目的さえ言語化できれば正確な調査結果にたどり着けます。
「ユーザー一覧を見せて」とだけ伝えるより、「退職者チェックのため」「不審なアクセスがないか確認したいため」など目的も一緒に伝えると、Claude Codeが目的に応じた確認方法（lastlogを合わせて見る、sudoグループも確認するなど）を判断してくれるため、より精度の高い調査結果が得られます。
代表菅澤
12 PRACTICAL WORKFLOW Claude Codeでアクセス権限点検を任せる実践フロー ターミナル操作なし・デスクトップ版で完結する4ステップ
「アクセス権限の点検が大事なのは分かったが、エンジニアじゃないので導入が不安」という方向けに、実際にどのような手順でサーバーのユーザー状況を点検していくのかを整理します。ターミナル（黒い画面）の知識は一切不要です。
日本語で伝える
対象サーバー・
確認の目的
コマンドを実行・調査
/etc/passwd等を
自動で確認
言葉で受け取る
専門用語なしの
レポート
確認のうえ実行
削除・権限変更は
慎重に判断
12-1. Step1：まず1つの目的に絞って具体的に伝える
いきなり「サーバーのセキュリティを全部見直して」のような大きな依頼をするのではなく、「このサーバーに今、誰がアクセスできる状態か教えて」「先月退職したスタッフのアカウントが残っていないか確認して」という1つの具体的な目的から始めるのがコツです。目的が具体的であるほど、精度の高い調査結果がすぐに得られます。
12-2. Step2：出てきた報告を業務の言葉で確認する
Claude Codeはサーバーに接続してコマンドを実行し、結果をそのまま出すのではなく業務の言葉に整理して報告できます。「登録アカウントは全部で何件、そのうち人間用は何件、退職者名簿と照らして残っているのは何件」といった形で受け取り、内容に不明点があればそのまま質問を重ねて構いません。
12-3. Step3：削除・変更が必要な場合は、必ず内容を確認してから実行する
10章で触れたとおり、アカウントの削除や権限変更は取り返しのつきにくい操作です。Claude Codeに「このアカウントを削除して」と依頼する場合も、「なぜ削除してよいと判断できるのか（最終ログイン日時・退職日との整合など）」を確認した上で、慎重に進めてください。少しでも判断に迷う場合は、実行前に社内の関係者にも一声かけることをおすすめします。
12-4. Step4：定期点検として仕組み化する
1回の点検で効果が確認できたら、月次・四半期などの頻度で同じ確認を繰り返すのが次のステップです。「先月と比べてアカウントが増えていないか」「退職者名簿とのズレがないか」を定点観測することで、単発の点検よりも不審な変化に早く気づけるようになります。
AI鬼管理山崎
弊社では、こうした「サーバーに今誰がアクセスできる状態か」というアクセス権限の点検についても、確認の目的整理から実際の調査、報告のとりまとめまでをClaude Codeに任せる形で運用しています。9章で紹介したインフラ領域の削減事例も、こうした地道な点検作業の積み重ねによるものです。
代表菅澤
13 CONCLUSION まとめ ユーザー一覧の確認は「暗記」ではなく「定期的に確認する仕組み」が本質
この記事では、Linuxでユーザー一覧を確認する方法として、/etc/passwd・getent passwd・who・w・lastの違い、経営視点で気にすべき理由、実務での確認パターン、非エンジニアがつまずきやすい罠までを整理しました。最後にポイントを振り返ります。
ユーザー一覧の確認コマンド自体は種類が多いわけではありませんが、/etc/passwdとgetentの違い、who/wとlastの時間軸の違い、そして「確認して終わり」ではなく「変更は慎重に」という姿勢まで含めると、正しく運用するには意外と多くの注意点があります。まずは自社のサーバーやシステムで「今、誰がアクセスできる状態になっているか」を一度確認するところから始めてみてください。
代表菅澤
自社サーバーのアクセス権限点検、Claude Codeで一緒に進めませんか
「退職者のアカウントがちゃんと消えているか不安」「今、誰がサーバーにアクセスできる状態か把握できていない」——弊社AI鬼管理では、Claude Codeを使ったサーバー・システムのアクセス権限点検から、業務自動化の導入までを支援しています。
AI鬼管理山崎
NEXT STEP
この記事の内容を、あなたのビジネスで
実践してみませんか？
よくある質問
Q. Linuxでユーザー一覧を確認する一番シンプルな方法は何ですか？
A. 最もシンプルなのは cat /etc/passwd コマンドです。ただし、この結果にはWebサーバーソフトなどが使うシステムアカウントも大量に含まれるため、実際に人間が使っているアカウントを見分けるには、UID（ユーザーID）が1000番以降のものに絞り込むのが一般的な目安です。ディストリビューションによって閾値が異なる場合があるため、あくまで目安として扱ってください。
Q. /etc/passwdとgetent passwdは何が違いますか？
A. /etc/passwdはそのサーバーのローカルに登録されたアカウントだけを記録したファイルです。一方getent passwdは、NSS（Name Service Switch）の設定に従い、ローカルの情報に加えてLDAPやActive Directoryなど外部のディレクトリサービスに登録されたアカウントも含めて表示します。外部連携をしていない一般的なサーバーでは、両者の結果はほぼ同じになります。
Q. whoコマンドと/etc/passwdの結果が全然違うのはなぜですか？
A. それぞれ確認できる内容が異なるためです。/etc/passwdは「登録されている全アカウント」、whoは「今この瞬間ログイン中のセッション」を表示します。登録アカウントが50件あっても、常時ログインしているのはごく一部というのが通常の状態なので、結果が大きく異なるのは正常な挙動です。
Q. 退職した社員のアカウントが残っているかどうか、どうやって確認しますか？
A. まず cat /etc/passwd や getent passwd で人間用アカウント（UID1000以降が目安）の一覧を確認し、退職者名簿と突き合わせます。さらに lastlog コマンドで最終ログイン日時を確認すると、退職後にログインされた形跡がないかも合わせてチェックできます。該当アカウントが見つかった場合は、削除前に必ず関係者に確認を取ってください。
Q. ユーザー一覧の確認で見つかったアカウントを、自分の判断で削除してもいいですか？
A. 自己判断での削除はおすすめしません。アカウント削除は業務システムの動作に影響する可能性がある操作です。まず最終ログイン日時や用途を確認し、本当に不要と判断できる根拠を揃えた上で、社内の関係者やAIツールに相談しながら慎重に進めてください。「確認」と「削除・変更」は明確に分けて考えるのが安全です。
Q. コマンドやLinuxの知識がなくても、サーバーのアクセス状況を確認できますか？
A. 確認できます。Claude Codeのようなエージェント型AIツールであれば、「このサーバーに今誰がアクセスできる状態か調べて」と日本語で伝えるだけで、/etc/passwd・getent・who・wなど適切なコマンドを判断して実行し、結果を業務の言葉に整理して報告してもらえます。構文を暗記していなくても、確認したい目的を言語化できれば十分です。
Q. Windowsサーバーでも同じような「ユーザー一覧確認」はできますか？
A. Windowsサーバーにも同様の考え方があり、コマンドプロンプトの net user や、コントロールパネルの「ユーザーアカウント」画面から登録アカウントを一覧確認できます。ただし本記事で解説したコマンド（/etc/passwd・getent・who・wなど）はLinux固有のものです。自社のサーバーがLinux系かWindows系かによって、確認方法・コマンドが異なる点に注意してください。
Claude Codeで業務自動化を90日で叩き込む
経営者向けの伴走型パーソナルトレーニング
AI鬼管理へのお問い合わせ
この記事を読んで気になった方へ。
AI鬼管理の専門スタッフが、御社に最適な
業務自動化プランを無料でご提案します。
- AI業務自動化サービス「AI鬼管理」を運営 — Claude Code を活用し、経営者の業務を「AIエージェントに任せる仕組み」へ転換するパーソナルトレーニングを 伴走構築 で提供。日報・採用・問い合わせ対応・経費精算・議事録・データ集計・営業リスト等の定型業務を、AIに代行させる体制を経営者と一緒に作り込む
- Claude Code 実装ノウハウを 経営者・法人クライアント に直接指導。生成AIを「便利ツール」ではなく 「業務を任せる存在」 として運用する手法を体系化
- 「やらせ切る管理」メソッドの開発者。シンゲキ株式会社（2021年設立・鬼管理専門塾運営）にて累計3,000名以上の学習者を志望校合格に導いた管理メソッドを、AI × 経営者支援 に転用
- 著書『3カ月で志望大学に合格できる鬼管理』(幻冬舎)、『親の過干渉こそ、最強の大学受験対策である。』(講談社)
- メディア出演: REAL VALUE / カンニング竹山のイチバン研究所 / ええじゃないかBiz 他
- 明治大学政治経済学部卒
