【2026年8月最新】Linuxの「su」「sudo」とは？非エンジニアが知るべき権限管理の基本
aikanri-admin
「suコマンドって何？」「sudoと何が違うの？」——IT担当者やエンジニアに任せきりで、こうした言葉を正確に説明できないまま経営判断をしている経営者・管理職の方は少なくありません。
suとsudoは、どちらもLinux（サーバーの基本ソフト）で「権限を一時的に強くして作業する」ためのコマンドです。地味な技術用語に見えますが、実はこの2つの違いを理解しているかどうかで、会社の情報セキュリティ事故のリスクが大きく変わります。
この記事では、プログラミング未経験の方でも理解できるよう、su/sudoの基本から「なぜ権限管理がビジネスリスクに直結するのか」、そしてAIエージェントが業務に入り込む時代にどう権限を管理すべきかまで、弊社（株式会社GENAI）の実運用データを交えて解説します。
代表菅澤
AI鬼管理山崎
01 LINUX BASICS そもそも「su」コマンドとは何か 非エンジニアでもわかる、権限を切り替える仕組み
なぜAI活用の話をするブログで、いきなりLinuxのコマンドを取り上げるのか。不思議に思われたかもしれません。理由はシンプルで、AIエージェントが業務システムやサーバーを操作するようになった今、「誰にどこまでの権限を与えるか」という発想そのものが、人にもAIにも共通して重要になっているからです。まずは基礎から順番に見ていきましょう。
su（Substitute User の略、あるいは Switch User とも呼ばれます）は、Linux（サーバーの多くで使われている基本ソフト）で別のユーザーになりすまして操作するためのコマンドです。ターミナル（黒い画面のコマンド入力ツール）で su とだけ入力すると、通常はroot（ルート）と呼ばれる最上位の管理者アカウントに切り替わります。
📚 用語解説
su コマンド：Linux/UNIX系のOSで、現在ログインしているユーザーから別のユーザー（多くの場合は管理者権限を持つroot）に切り替えるコマンド。切り替え先ユーザーのパスワードを入力して認証する。
📚 用語解説
root権限（スーパーユーザー）：Linuxシステムにおける最上位の管理者権限のこと。ファイルの削除、他ユーザーの追加・削除、システム設定の変更など、あらゆる操作が制限なく行える。会社に例えるなら「金庫の鍵とマスターカードを同時に持っている状態」に近い。
1-1. なぜrootに切り替える必要があるのか
通常、Linuxサーバーには「一般ユーザー」としてログインします。一般ユーザーのままだと、システムの重要な設定ファイルを書き換えたり、他人のファイルを削除したりすることはできません。これは誤操作や不正な操作を防ぐための安全装置です。
しかし、ソフトウェアのインストールやシステムのアップデートなど、管理者にしかできない作業も当然発生します。そのときに一時的に管理者（root）に切り替える手段の1つが su コマンドというわけです。
「suを使える人＝会社のシステムに対して何でもできる人」だと考えてください。エンジニアに開発を委託している場合、この権限を誰が、何人が持っているのかを把握していない経営者は意外と多いです。まずは「うちの会社でrootパスワードを知っているのは誰か」を確認するところから始めてみてください。
1-2. suコマンドの基本的な使い方
実際のコマンドはとてもシンプルです。ターミナルで su と入力してEnterを押すと、rootのパスワードを聞かれます。正しく入力すると、それ以降のコマンドはすべてroot権限で実行されるようになります。
| コマンド | 動作 |
|---|---|
| su | rootユーザーに切り替える（パスワード認証あり） |
| su ユーザー名 | 指定した別ユーザーに切り替える |
| su - | ログインシェルとして切り替える（環境変数も切り替え先のものに変わる） |
| su -c "コマンド" | 1つのコマンドだけをroot権限で実行し、すぐ元の権限に戻る |
| exit | suで切り替えた状態から元のユーザーに戻る |
一度rootに切り替えると、それ以降のコマンドはすべて「取り消せる安全装置なし」で実行されます。削除コマンドを1文字打ち間違えただけで、重要なデータやシステム全体が壊れる事故は現場で実際に起こります。作業が終わったらexitで必ず元の権限に戻ることが鉄則です。
02 SU vs SUDO suとsudoの違いを非エンジニア向けに解説 「誰の権限で」「何を」「どこまで」が根本的に異なる
suとよく混同されるのがsudo（スードゥー）コマンドです。どちらも「管理者権限で操作する」点は共通していますが、セキュリティ管理の観点では別物と考えた方がよいくらい設計思想が異なります。
📚 用語解説
sudo コマンド："superuser do" の略。一般ユーザーが、自分自身のパスワード認証のまま、特定のコマンドだけを管理者権限で実行できる仕組み。実行内容は原則としてログに記録される。
2-1. 認証するパスワードが違う
suは切り替え先（root）のパスワードを入力します。つまりrootパスワードを知っている人なら誰でもrootになれてしまいます。一方sudoは自分自身のパスワードを入力するだけで、管理者としてあらかじめ許可されたコマンドを実行できます。rootのパスワードそのものを共有する必要がありません。
2-2. できることの範囲が違う
suで一度rootに切り替えると、その後はrootとして何でもできてしまいます。対してsudoは、システム管理者がsudoersという設定ファイル（システム設定用ディレクトリの配下に置かれています）で「このユーザーはこのコマンドだけ実行してよい」と細かく制限できます。
📚 用語解説
最小権限の原則（PoLP）：Principle of Least Privilege の略。「業務に必要な最小限の権限だけを与える」というセキュリティの基本原則。必要以上の権限を渡さないことで、誤操作や不正アクセスが起きたときの被害範囲を最小化する考え方。
2-3. 記録（ログ）に残るかどうかが違う
sudoで実行したコマンドは、標準でauth.log（Debian/Ubuntu系）やsecure（RHEL/CentOS系）といったシステムのログファイルに、「誰が」「いつ」「何を実行したか」が記録されます。これに対してsuは、切り替えた事実は記録されるものの、切り替えた後に何をしたかまでは、suの仕組み自体は個別に記録しません。
| 比較軸 | su | sudo |
|---|---|---|
| 認証するパスワード | 切り替え先（root）のパスワード | 自分自身のパスワード |
| 権限の範囲 | 切り替え後は制限なし | コマンド単位で制限可能 |
| 実行者の追跡 | root化した後の操作は追いにくい | コマンドごとにユーザー名でログが残る |
| 退職者対応 | rootパスワードの変更が必要 | sudoersからユーザーを外すだけでよい |
| 向いている用途 | 短時間の緊急作業・個人開発環境 | 複数人が関わる業務システム・本番環境 |
AI鬼管理山崎
2-4. 「su -」と「su」の違い
もう1つよく混同されるのが「su」と「su -」の違いです。単に su と打つと、現在のユーザーの環境変数（作業設定の情報）を引き継いだままrootに切り替わります。一方 su -（ハイフン付き）は、rootにログインし直したのと同じ状態になり、環境変数もroot本来のものに切り替わります。
📚 用語解説
環境変数：OSやアプリケーションが動作するときに参照する「設定値の入れ物」。どのフォルダを基準にコマンドを探すか（PATH）、ホームディレクトリはどこか（HOME）などの情報が含まれる。ユーザーが変わると本来この中身も変わるべきだが、su（ハイフンなし）ではそれが引き継がれてしまう点に注意が必要。
rootとして本来の設定で作業したい場合は、基本的にsu -を使うのが安全です。環境変数が中途半端に混ざった状態で作業すると、意図しないフォルダのファイルを操作してしまうといった事故につながります。
AI鬼管理山崎
03 PRACTICAL USAGE suコマンドの使い方とオプション 実務でどう使われているかを具体例で理解する
ここでは、実際の現場でsuコマンドがどう使われているかを、具体的な場面で見ていきます。エンジニアに開発や運用を委託している経営者・管理職の方も、「委託先が何をしているか」の解像度を上げる目的で読んでみてください。
3-1. サーバーのメンテナンス作業
サーバーのソフトウェアアップデートやログの整理など、定期メンテナンスの場面で管理者権限が必要になります。多くの現場では、こうした作業ログ自体を残すルールを設けており、su -で切り替えたあと、作業内容を記録しながら進めるのが一般的です。
3-2. トラブル発生時の緊急対応
サービス障害やサーバーダウンなど、緊急時には一刻を争います。このようなときにsu -c "コマンド"を使い、必要なコマンドだけをピンポイントでroot権限で実行し、作業範囲を最小限にとどめるという使い方がされます。
3-3. 開発環境と本番環境での使い分け
個人の開発環境（自分しか触らないテスト用のサーバー）であれば、suで手早く作業しても実害は限定的です。しかし本番環境（実際にお客様が使うシステム）では話が別です。誰が・いつ・何を変更したかが追跡できないと、障害発生時の原因究明に何時間もかかる、あるいは特定できないまま終わるということが起こり得ます。
本番環境を複数人でsu運用していると、障害発生時に「誰が最後に何を触ったか」の特定に時間がかかります。弊社が支援先で権限まわりの整理をご相談いただく際も、まず最初に確認するのがこの点です。人数が2人以上いる会社であれば、本番環境は原則sudo運用に切り替えることを推奨します。
04 BUSINESS RISK なぜroot権限の管理がビジネスリスクになるのか 技術の話ではなく、経営とガバナンスの話として捉える
ここからは技術解説を離れて、経営者・管理職として権限管理をどう捉えるべきかを整理します。これは「エンジニアに任せておけばいい話」ではなく、情報セキュリティ・内部統制という経営マターです。
4-1. よくある権限管理の失敗パターン
弊社が中小企業のシステム運用体制を伺う中で、繰り返し見かけるパターンがいくつかあります。技術的な難易度は高くありませんが、放置されがちな盲点です。
📚 用語解説
監査ログ：「誰が」「いつ」「何を」操作したかを記録した履歴データ。障害対応や不正アクセスの調査だけでなく、取引先や監査法人から情報セキュリティ体制を問われた際の説明資料にもなる。sudo運用はこの監査ログと相性がよい。
4-2. 権限管理の甘さが引き起こす実害
権限管理が甘いと、具体的には次のような実害につながります。まず事故発生時の原因究明が長期化すること。誰が何を操作したか分からなければ、復旧の初動が遅れます。次に内部不正への抑止力が働かないこと。「誰の操作か特定できない」状態は、悪意ある操作をした本人にとっても発覚しにくい環境になってしまいます。
さらに近年増えているのが、取引先からのセキュリティ体制チェックです。大手企業と新規で取引を始める際、委託先（つまり自社）のアクセス権限管理の状況を確認する調査票への回答を求められるケースが増えています。ここで「権限の一覧すら把握していない」状態だと、商談自体が止まってしまうこともあります。
一気に全てを変える必要はありません。まずは①現在誰がどんな権限を持っているかを一覧化する、②不要な権限（退職者・終了した契約先など）を洗い出して削除する、③新規発行は原則sudo型（個人単位の限定権限）にする、という3ステップから始めるのが現実的です。
代表菅澤
4-3. 権限管理は「取引先からの信頼」にも直結する
近年、上場企業や大手企業が取引先を選定する際に、情報セキュリティに関するチェックシートへの回答を求めるケースが増えています。その質問項目の多くに「アクセス権限の管理方針」「退職者アカウントの無効化フロー」「操作ログの保管期間」といった、この記事で扱ってきたテーマがそのまま登場します。
つまり、権限管理を整えておくことは「事故を防ぐ」という守りの目的だけでなく、「大手企業との新規取引を獲得しやすくする」という攻めの目的にもつながります。特にBtoBで事業を伸ばしたい中小企業ほど、早い段階でこの体制を整えておく価値があります。
📚 用語解説
多要素認証（MFA）：パスワードに加えて、スマートフォンアプリの確認コードや生体認証など「もう1つの要素」を組み合わせてログインを認証する仕組み。パスワードが漏えいしただけでは不正ログインされにくくなるため、rootやsudo権限を持つアカウントには特に有効。
05 GENAI CASE STUDY 【独自データ】GENAI社内のアクセス権限・AI実行権限の管理方針 Claude Codeを全社運用する会社が、権限をどう設計しているか
弊社（株式会社GENAI）では、Claude Codeを経営・営業・広告・開発・経理・秘書業務まで全社で活用しています。ここでは、人だけでなくAIエージェントにも権限を持たせて業務を回している会社として、実際の運用方針を紹介します。
| 項目 | 内容 |
|---|---|
| 契約プラン | Claude Max 20x（月額$200 / 約30,000円） |
| 利用開始 | 2025年後半〜 |
| 利用部署 | 経営・営業・広告・開発・経理・秘書業務・個人業務まで全社 |
| 権限方針 | 共有パスワードでの一括付与はせず、用途・担当ごとにアカウント/キーを分離 |
弊社では、社内システムやAIツールのアカウントを「共有パスワードで一括付与」しないことを基本方針にしています。理由はここまで説明してきたsu的な運用（誰でも同じ強い権限を持てる状態）のリスクを、社内でも避けたいからです。
| 業務領域 | 主な用途 | 概算削減時間（肌感） |
|---|---|---|
| 営業 | 提案書・見積・顧客別資料の自動生成 | 週20h → 週2h |
| 広告運用 | 週次レポート・CPA分析・配信内容調整 | 週10h → 週1h |
| 経理 | 請求書チェック・経費仕訳・Freee連携 | 月40h → 月5h |
| 秘書業務 | 日報生成・議事録・スケジュール調整 | 日2h → 日15分 |
| 開発 | WordPress/LP制作、スクリプト書き捨て | 都度数時間削減 |
上記は弊社の肌感ベースの数値であり、業種・業態・担当者のスキルによって削減時間は変動します。Claude Code導入によって「何がどこまでできるか」の参考情報としてご覧ください。
5-1. GENAIにおける権限設計の4ステップ
用途ごとに
アカウント/キーを
分離して発行
必要最小限の
権限だけを
付与（PoLP）
操作ログ・履歴を
残す運用に
統一
四半期ごとに
権限を棚卸しし
不要分を削除
この4ステップは、そのまま従来のIT権限管理のセオリー（sudo運用の考え方）と一致します。違うのは、「操作する主体」に人だけでなくAIエージェントも含まれるという点です。次の章では、この「AIに権限を持たせる」という論点を掘り下げます。
AI鬼管理山崎
06 AI AGENT ERA AIエージェント時代の権限管理：Claude Codeの「確認してから実行する」仕組み 人に権限を渡すときと同じ発想が、AIにも必要になっている
ここまでsu/sudoという「人」向けの権限管理の話をしてきましたが、2026年現在、経営者が向き合うべき論点がもう1つ増えています。それが「AIエージェントにどこまでの権限を持たせるか」です。
Claude Codeのようなエージェント型AIは、指示を受けてファイルを操作したり、コマンドを実行したり、外部サービスと連携したりします。これはある意味で、root権限を持った新しいスタッフを社内に迎え入れるようなものです。ここでの権限設計を誤ると、人の権限管理をどれだけ整備していても意味がなくなってしまいます。
6-1. Claude Codeの許可確認（パーミッション）の仕組み
Claude Codeには、ファイルの削除やコマンドの実行など影響の大きい操作を行う前に、必ず利用者に確認を求める仕組みが標準で備わっています。これは、sudoが「本人のパスワードで、コマンド単位に許可・記録する」仕組みと構造的によく似ています。
📚 用語解説
サンドボックス：AIエージェントが操作できる範囲を、あらかじめ限定された安全な領域に閉じ込める仕組み。万が一意図しない操作が発生しても、影響範囲をその領域内にとどめられる。金庫室の外に出さずに作業させるイメージ。
📚 用語解説
許可リスト（allow-list）：「このコマンド・この操作は自動実行してよい」と事前に登録しておくリストのこと。逆に登録されていない操作は、都度人間に確認が求められる。sudoersファイルで許可コマンドを列挙する発想と本質的に同じ。
Claude Codeには確認プロンプトを一括で無効化するオプションも存在しますが、外部からの入力（メール・Webページ・チャット等）を扱うタスクでこれを使うと、rootパスワードを共有した状態のsu運用と同じリスクを抱えることになります。特に社外とのやり取りが絡む業務では、確認を有効にしたまま運用するのが安全です。
この「確認してから実行する」流れを図にすると、次のようになります。sudoがコマンドごとに許可判定するのと同じ発想が、AIエージェントの世界にもそのまま持ち込まれていることが分かります。
利用者が
タスクを依頼
許可リストに
該当するか確認
未登録の操作は
都度承認を要求
承認後に実行し
操作ログを保存
6-2. 「人に権限を渡す」と「AIに権限を渡す」は同じ設計思想で考える
su/sudoの章で紹介した最小権限の原則は、AIエージェントの権限設計にもそのまま当てはまります。「とりあえず全部の権限を渡しておけば楽」という発想は、人に対してもAIに対しても同じリスクを生みます。逆に言えば、権限管理の基礎を理解している経営者ほど、AIエージェント導入時の設計判断を誤りにくいということでもあります。
弊社「AI鬼管理」では、Claude Codeを含むAIエージェントの導入支援において、こうした権限設計・許可リストの組み方まで含めて伴走しています。「便利そうだから使ってみたが、気づいたら何でも自動実行される状態になっていた」という事故を防ぐには、導入初期の設計が重要です。
代表菅澤
07 ACTION CHECKLIST 非エンジニアが今日からできる権限管理チェックリスト 難しい技術知識がなくても、今日から着手できること
最後に、経営者・管理職の立場からすぐに着手できるチェックリストをまとめます。エンジニアではなくても、確認と指示出しはできる項目です。
権限設計やAIエージェント導入のガバナンス整備は、専門知識がないと勘所が分かりにくい領域です。弊社「AI鬼管理」では、こうした権限設計・業務自動化の導入支援を行っています。まずは無料相談で、貴社の現状の権限管理をどう整理すべきか、一緒に確認することも可能です。
AI鬼管理山崎
08 CONCLUSION まとめ ── 権限管理は「人だけ」の話ではなくなった su/sudoの基礎知識が、AI時代のガバナンスにもつながる
この記事では、Linuxのsu/sudoコマンドの基礎知識から、それが会社経営における権限管理・情報セキュリティとどうつながるのか、そしてAIエージェント時代における新しい論点までを整理しました。最後にポイントを振り返ります。
権限管理は、これまで「エンジニアやIT部門に任せる話」だと思われがちでした。しかし、AIエージェントが業務の実行主体として社内に入り込んでくる以上、「誰に・何を・どこまで任せるか」を設計する経営判断そのものになりつつあります。
代表菅澤
権限設計まで含めたAIエージェント導入を、AI鬼管理が一緒に設計します
「便利そうだから」で権限を丸ごと渡す前に、su/sudoの発想と同じ「最小権限」の設計を。
弊社の実運用ノウハウをベースに、個別にAI導入・権限設計のご相談を承ります。
AI鬼管理山崎
ここから先の進め方は、大きく2つあります。
自社で回せるようになりたい方は、AI鬼管理でClaude Code／Codexの使い方から業務設計・社内定着まで伴走を受けながら、社内に仕組みを作る道があります。
覚えるより任せたい方は、AIBPO by AI鬼管理でこの記事のような定型業務を丸ごと預ける道があります。総額はいまの業務コストの50%が目安、月額基本料は0円です。
どちらが合うかは、業務量と社内体制次第です。無料相談・無料適合診断で、貴社の場合はどちらが向くかからご相談いただけます。
NEXT STEP
この記事の内容を、あなたのビジネスで
実践してみませんか？
よくある質問
Q. suとsudoの違いを一言で教えてください。
A. suは「切り替え先（rootなど）のパスワードで認証し、切り替えた後は制限なく操作できる」仕組みです。一方sudoは「自分自身のパスワードで認証し、あらかじめ許可されたコマンドだけをその都度実行し、ログに記録される」仕組みです。複数人が関わる会社のシステムでは、追跡・制限のしやすいsudoの方が安全とされています。
Q. suコマンドを使うと危険と聞きましたが本当ですか？
A. su自体が危険なわけではありません。ただし、切り替え後は制限なくシステムを操作できてしまうため、操作ミスや誤操作の影響範囲が大きくなりやすいのは事実です。個人の開発環境での一時的な利用ならリスクは限定的ですが、複数人が関わる本番環境では、コマンド単位で制限・記録できるsudo運用への切り替えを推奨します。
Q. sudoを設定すれば会社のセキュリティは安心ですか？
A. sudoの導入だけで安心とは言えません。sudoersの設定が緩すぎれば実質su運用と変わらなくなりますし、パスワード管理や退職者アカウントの削除運用が甘ければリスクは残ります。sudo自体は手段であり、「最小権限の原則」に沿った運用ルールを併せて整備することが重要です。
Q. なぜAIエージェントの話が出てくるのですか？Linuxコマンドと何の関係が？
A. AIエージェントは業務システムを操作する新しい「実行主体」であり、人と同様に「どこまでの権限を与えるか」の設計が必要になるためです。su/sudoが体現している「最小権限」「ログ記録」「都度確認」という考え方は、Claude Codeのようなエージェント型AIの権限設計にもそのまま応用できます。
Q. Claude Codeは危険なコマンドを勝手に実行しませんか？
A. ファイルの削除や上書きなど影響の大きい操作は、標準では利用者に確認を求める設計になっています。許可リスト（allow-list）に登録した操作のみ自動実行できる仕組みもあり、sudoの「コマンド単位の許可」と近い発想です。ただし確認機能を一括で無効化する設定もあるため、その運用には注意が必要です。
Q. 非エンジニアの経営者が権限管理を学ぶ必要は本当にありますか？
A. 技術的な操作を自分で行う必要はありませんが、「誰が」「どこまでの」権限を持っているかを把握し、承認する立場としての理解は必要です。取引先からセキュリティ体制を問われる場面も増えており、権限管理の基本方針を説明できることは、今後の経営リスク管理の一部になっています。
Q. 退職した社員のアカウント権限はどう扱えばいいですか？
A. 退職・異動が発生したタイミングで、速やかにアカウントの無効化・権限の削除を行うのが原則です。共有パスワードで権限を渡している場合はパスワード自体の変更が必要になり手間がかかるため、個人単位のsudo運用にしておくと、対象ユーザーをsudoersから外すだけで対応が完結し、運用負荷を大きく下げられます。
Claude Codeで業務自動化を90日で叩き込む
経営者向けの伴走型パーソナルトレーニング
AI鬼管理／AIBPO by AI鬼管理へのお問い合わせ
この記事を読んで気になった方へ。
専門スタッフが、御社に最適な
業務自動化・業務代行プランを無料でご提案します。
- AI業務自動化サービス「AI鬼管理」を運営 — Claude Code を活用し、経営者の業務を「AIエージェントに任せる仕組み」へ転換するパーソナルトレーニングを 伴走構築 で提供。日報・採用・問い合わせ対応・経費精算・議事録・データ集計・営業リスト等の定型業務を、AIに代行させる体制を経営者と一緒に作り込む
- Claude Code 実装ノウハウを 経営者・法人クライアント に直接指導。生成AIを「便利ツール」ではなく 「業務を任せる存在」 として運用する手法を体系化
- 「やらせ切る管理」メソッドの開発者。シンゲキ株式会社（2021年設立・鬼管理専門塾運営）にて累計3,000名以上の学習者を志望校合格に導いた管理メソッドを、AI × 経営者支援 に転用
- 著書『3カ月で志望大学に合格できる鬼管理』(幻冬舎)、『親の過干渉こそ、最強の大学受験対策である。』(講談社)
- メディア出演: REAL VALUE / カンニング竹山のイチバン研究所 / ええじゃないかBiz 他
- 明治大学政治経済学部卒
