PowerShellコマンド一覧を自分の環境で作る方法｜用途別チートシート付き

※本コンテンツは「記事制作ポリシー」に基づき、正確かつ信頼性の高い情報提供を心がけております。万が一、内容に誤りや誤解を招く表現がございましたら、お手数ですが「お問い合わせ」よりご一報ください。速やかに確認・修正いたします。

PowerShellコマンド一覧の考え方

PowerShellの「コマンド一覧」を探す背景には、大きく二つのニーズがあります。第一に「よく使う定番を用途別にまとめて、すぐ引けるようにしたい」というニーズです。第二に「そもそも自分の環境で何が使えるのかを、漏れなく把握したい」というニーズです。PowerShellは、標準搭載の範囲に加えてモジュールの追加でコマンドが増えるため、Webにある静的な一覧だけでは、環境差を吸収しきれないケースが珍しくありません。

本記事では、暗記を目的とせず、自分の環境から“使えるコマンド”を抽出し、用途別に再整理してチートシート化するという方針で解説いたします。これにより、OSやPowerShellのバージョン、導入済みモジュールの差があっても、手元の一覧が常に基準になります。

コマンドレットとエイリアスの違い

PowerShellで「コマンド」と言うと、実際には複数の種類が混在します。ここを理解しておかないと、Get-Command の結果が多すぎて混乱しやすくなります。まず、代表的な種類を整理いたします。

特に重要なのは、Aliasはあくまで別名という点です。例として ls はLinuxの ls に似た見た目ですが、PowerShellでは多くの場合 Get-ChildItem に割り当てられています。Aliasを多用すると入力は速くなりますが、共有スクリプトや手順書では読み手が迷うこともあります。運用文書やチーム共有を意識する場合は、まずCmdlet名（本体）で覚え、必要に応じてAliasを併用するのが堅実です。

Aliasの実体を確認する基本形は次のとおりです。

さらに、詳細（実体や定義、出所）を確認したい場合は Format-List * を使います。

この「何者かを確認する癖」を持つだけで、未知のコマンドに出会ったときの調査速度が大きく向上します。

動詞-名詞で探せる理由

PowerShellのCmdletは、多くが「動詞-名詞（Verb-Noun）」という命名規則で設計されています。これは単なる見た目の統一ではなく、「探索・学習・推測」を支える仕組みです。

• 動詞（Verb）：何をするか（取得、設定、作成、削除、開始、停止、テストなど）

• 名詞（Noun）：何に対して行うか（Process、Service、Item、Computer、EventLogなど）

たとえば、次のように推測できます。

• 「サービスを取得したい」→ Get-Service

• 「サービスを開始したい」→ Start-Service

• 「サービスを停止したい」→ Stop-Service

• 「新しい項目を作りたい」→ New-Item

• 「項目を削除したい」→ Remove-Item

この規則があるため、すべてのコマンドを暗記する必要はありません。むしろ、運用で求められるのは次の能力です。

1. やりたいことを動詞に置き換える

2. 対象を名詞として表す

3. Get-Command で候補を絞り込む

4. Get-Help で使い方を確認する

この流れが回り始めると、「コマンド一覧」は暗記カードではなく、探索と自己解決のための地図になります。

Get-Commandでコマンド一覧を抽出する手順

静的な一覧を読む前に、まずは自分の環境で「利用可能なコマンド」を抽出できる状態を作ることが重要です。PowerShellは環境差が大きいため、Webの一覧で見つけたコマンドが手元に存在しないことがあります。その差分を埋める最短手段が Get-Command です。

ここでは、一覧の抽出から、絞り込み、保存、再利用までを一気通貫で解説いたします。

種類別に一覧を出す

最初に「全体像」を掴むときは、コマンドの“種類”を絞るのが効果的です。いきなり Get-Command だけを実行すると、結果が膨大になりがちです。

1) すべてのコマンドを表示

この結果には、Cmdlet、Function、Alias、外部コマンドなどが混在します。探索の起点としては有用ですが、学習用途では情報過多になります。

2) Cmdletだけに絞る（推奨）

最初はこの出力を基準にすると、PowerShellの考え方（オブジェクト、パイプライン）に沿った理解が進みます。

3) Aliasだけに絞る

Alias一覧を出すと、Linuxやcmdに似た操作がどれだけAliasとして用意されているかが見えます。加えて、チーム内でAliasを使ってよい範囲（手元作業のみ、共有手順では禁止など）を決める材料にもなります。

4) Functionだけに絞る

関数が多い環境は、モジュールやプロファイルで拡張されている可能性があります。トラブル時に「他の人と挙動が違う」原因の切り分けに役立ちます。

5) 外部コマンド（Application）を確認

外部コマンドはPowerShellの世界観（オブジェクト）ではなく、文字列出力が中心です。混在は悪いことではありませんが、整形・絞り込みの流儀が変わるため、種別を把握しておくと混乱が減ります。

モジュール別に一覧を出す

PowerShellのコマンドは、モジュール単位で提供されることが多く、導入状況によって使えるコマンドが変わります。そのため、「モジュールを軸にした一覧化」が非常に有効です。

1) 利用可能なモジュールを列挙

この結果により、「そもそもモジュールが入っているか」「同名モジュールが複数バージョン存在するか」を確認できます。

2) 特定モジュールのコマンド一覧を表示

標準モジュールだけでも相当数のコマンドがあり、まずはここに慣れるとよいです。

3) “それっぽい名前”で検索する

コマンド名が曖昧でも、ワイルドカード検索で候補が出せます。

4) 動詞で横断検索する（運用で非常に有効）

「停止系」「開始系」「設定系」など、動詞で検索すると、対象違いのコマンドをまとめて発見できます。

この使い方は、コマンド一覧を“読む”のではなく、“掘り出す”ための方法です。

一覧をファイルに保存する

一覧を「その場の表示」で終えると、次回また同じことをやり直すことになります。運用では、保存してこそ一覧です。保存形式としては次の3つが実用的です。

• テキスト：すぐ開ける、軽い、共有が簡単

• CSV：Excelで絞り込み・検索しやすい

• JSON：プログラム処理や再利用に向く（必要に応じて）

1) テキスト保存（まずはこれで十分です）

ポイントは Sort-Object Name で並べ替えることです。辞書としての可読性が上がります。

2) CSV保存（チートシート化に最適です）

• Source：どのモジュール/出所か

• Version：モジュールのバージョン（環境差の説明に有用）

これらを含めておくと、後で「なぜこの環境では使えないのか」を説明しやすくなります。

3) 用途別に抜粋して保存（運用の即戦力になります）

同様に、プロセス、イベント、ネットワークなど用途別に作ると、現場での参照性が上がります。

4) 更新運用（“一覧の鮮度”を保つ）

モジュール追加やPowerShell更新が入ると、一覧は変化します。定期的に再生成できるよう、次のような「更新用ワンライナー」を用意しておくと便利です。

出力先を固定しておくと、都度探す必要がありません。

よく使うPowerShellコマンド一覧

ここでは、運用・調査・日常作業で頻出のコマンドを用途別に整理いたします。目的は「暗記」ではなく、「存在と使いどころを把握し、必要時に一覧から引ける状態にする」ことです。あわせて、出力の見方や、よく使う組み合わせ（Where/Select/Sortなど）も併記いたします。

ファイルとフォルダー操作

PowerShellのファイル操作は「Item（項目）」を中心に設計されています。ファイルもフォルダーも“Item”として扱う点がポイントです。

よくある実用例として、「特定拡張子のファイルを探す」は次のように書けます。

検索結果から、サイズや更新日時など必要な情報を表示したい場合は Select-Object を組み合わせます。

このように「一覧 → 必要列抽出 → 並べ替え → 上位のみ」という型は、運用で頻出です。

検索と絞り込み

PowerShellの真価は、出力が“文字列”ではなく“オブジェクト”である点にあります。つまり、整形や抽出が標準で強い設計です。ここで定番のコマンドを押さえると、どの分野にも応用できます。

例として「ログファイルの合計サイズ」を把握したい場合は次のように書けます。

「特定条件のものだけ抽出」は Where-Object が中心です。

なお、Where-Object の条件式で迷った場合は、まず対象オブジェクトが持つプロパティを確認するのが定石です。

この「Get-Memberで構造を確認してから絞る」という流れを身につけると、未知のコマンドでも応用が利きます。

プロセスとサービス

運用の基本は「状態確認」と「安全な制御」です。特に停止・再起動といった操作は影響範囲が大きいため、対象の特定を丁寧に行う必要があります。

プロセスを停止する場合、名称指定よりID指定の方が安全なケースがあります。

サービスについては、表示名（DisplayName）と内部名（Name）が異なる点が重要です。たとえば「Print Spooler」と表示されるサービスは内部名が Spooler です。停止・起動は内部名で行うのが一般的です。

ネットワークとリモート

ネットワークの切り分けは、疎通、名前解決、経路、ポートの順に確認すると効率的です。PowerShellでは次のコマンドがよく使われます。

例：対象ホストの443ポートが到達可能かを確認します。

例：DNS名が引けるかを確認します。

ここで重要なのは、「疎通がNG」でも、原因がDNSかポートかルーティングかで対処が異なる点です。コマンド一覧を“用途別”に持つと、切り分けの順序も自然に整理できます。

ログとシステム情報

運用では「証跡」と「状態把握」が重要です。特に障害調査では、ログの取得と整形が頻出です。

例：PowerShellのバージョン確認

障害対応で「まず最初にこれを出しておく」という意味で、バージョン情報は非常に重要です。なぜなら、使えるコマンドやモジュールがバージョンにより変わることがあるためです。

Get-Helpで使い方を確認するコツ

コマンド一覧が手元にあっても、「どう使うか」が分からなければ実行に移せません。そこで重要になるのが Get-Help です。PowerShellでは、ヘルプを“自分で引く”ことが標準の学習導線になっています。

ヘルプ活用のコツは、最初から全文を読もうとしないことです。まずは「例（Examples）」で型を掴み、必要に応じて詳細に潜るのが効率的です。

例から逆引きする

最初に見るべきは -Examples です。

次に、より詳しい情報が必要になったら -Full を使います。

運用でよくあるのは、「パラメーターが多すぎてどれを使えばよいか分からない」という状況です。この場合、Examplesを見ると“よくある使い方”が先に提示されるため、最短で目的に到達できます。

また、ヘルプが古い・不足していると感じた場合は、ヘルプ更新（環境やポリシーによって可否があります）を検討します。更新コマンド自体は存在しますが、企業環境では通信制限やプロキシの影響を受けるため、組織ルールに従ってください。

共通パラメーターを理解する

PowerShellの多くのコマンドには、共通して利用できるパラメーターがあります。これを理解すると、未知のコマンドでも安全に試せるようになります。

特に重要な共通パラメーターは次のとおりです。

• -WhatIf：実際には実行せず、実行される操作内容だけを表示します

• -Confirm：実行前に確認を求めます

• -Verbose：詳細な処理ログを表示します

• -ErrorAction：エラー時の動作を制御します（Stop/Continue/SilentlyContinue など）

例：削除前に影響だけ確認する（非常に重要です）

例：詳細ログを出しながら実行する

共通パラメーターは、運用の安全性と調査効率に直結します。コマンド一覧の中でも、特に早期に押さえる価値が高い要素です。

つまずき別トラブルシューティング

コマンド一覧を整えても、実際の現場では「動かない」「見つからない」「権限がない」といった壁にぶつかります。ここでは、頻出のつまずきを“原因→切り分け→対処の方向性”という形で整理いたします。

コマンドが見つからない

この問題は、原因が複数あります。よくある原因と切り分けの順序を示します。

よくある原因

• コマンド名の誤り（スペル、ハイフン、複数形など）

• AliasとCmdletの混同（本体名が別）

• モジュール未導入、または未読み込み

• PowerShellのバージョン差（5.1と7系など）

• そもそもそのOS機能が入っていない（ネットワーク系など）

切り分け手順（推奨）

近い名称で検索する（ワイルドカード）

似た動詞・名詞で探す（動詞-名詞の発想）

モジュールの有無を確認する

Aliasの可能性を確認する

この流れで「存在しない」のか「呼び方が違う」のかを切り分けられます。

スクリプトが実行できない

この問題は、企業環境では特に多く、実行ポリシー、ファイルブロック、権限制限、セキュリティ製品などが絡むことがあります。重要なのは、エラー文面を省略せずに確認することです。ここを飛ばすと、誤った対処で状況が悪化することがあります。

よくある状況

• 「このシステムではスクリプトの実行が無効」などの実行ポリシー関連

• ダウンロードしたファイルがブロックされている

• 署名が必要な環境

• パスや文字コードの問題（日本語パス、UTF-8/Shift-JISなど）

基本方針

• まずエラー全文を確認し、原因カテゴリを特定する

• 組織ルールがある場合は、ルールに従う（独断で緩めない）

• “一時的にその場だけ”試せる方法がないかを検討する

• 変更が必要な場合は、影響範囲（端末全体か、ユーザーだけか）を最小化する

本記事では安全性の観点から、環境依存の設定変更を一律の断定で提示せず、原則と切り分けを中心に解説しております。必要であれば、エラーメッセージと目的（何を実行したいか）を基に、最小影響の対応方針を具体化いたします。

権限不足で失敗する

PowerShellで失敗する原因として非常に多いのが権限です。特に、サービス制御、システム領域への書き込み、レジストリ操作、リモート操作などは、管理者権限や追加設定が必要になることがあります。

典型例

• Stop-Service が拒否される

• システムフォルダーへの Copy-Item が失敗する

• Get-WinEvent の一部ログにアクセスできない

• リモート実行が通らない（WinRM等の前提）

まず取るべき行動

• 参照系（Get-）で情報を集める

• 操作対象を明確化する（ID、Name、Pathなど）

• 影響確認（-WhatIf、ログ出力）を行う

• 必要なら管理者権限で実行するが、組織ルールに従う

「管理者で動かせばよい」という発想だけだと、手順が不透明になりがちです。運用では「なぜ権限が必要なのか」「どの範囲で必要なのか」を説明できる形にしておくことが、品質と監査対応の観点でも重要です。

PowerShellコマンド一覧を運用に活かす

一覧は作って終わりではありません。運用で価値を生むのは、参照性（すぐ引ける）と更新性（変化に追随できる）です。ここでは、一覧を日々の作業に落とし込むための方法を整理いたします。

チートシートの作り方

おすすめは「全量一覧」と「用途別抜粋」を分けることです。

• 全量：環境の真実（ベースライン）

• 用途別：現場で即参照する短い表

1) 全量一覧（commands.csv）を作る

2) 用途別抜粋（ops-favorites.csv）を作る

この用途別抜粋は、実務に合わせてパターンを調整してください。最初から完璧を目指さず、「使ったら追加、使わなければ削除」という運用が最も続きます。

3) すぐ開けるテキスト版も作る

CSVは便利ですが、緊急時にはテキストの方が速い場面があります。両方用意しておくと安心です。

学習の最短ルート

PowerShell学習は、網羅よりも「調べ方の型」を先に固める方が成果が出やすいです。運用担当の方に推奨する最短ルートは次の順序です。

1. Get-Command：候補を見つける

2. Get-Help -Examples：使い方の型を見る

3. Get-Member：出力オブジェクトの構造を知る

4. Where/Select/Sort：整形・抽出で実用にする

5. 保存（Out-File/Export-Csv）：証跡と再利用を作る

例として「イベントログからエラーだけ抽出してCSV化する」など、目的が明確な題材を選ぶと、学習が業務に直結します。ポイントは、コマンドを“覚える”のではなく、“組み合わせる”感覚を身につけることです。

注意点チェックリスト

PowerShellは強力な分、誤操作の影響も大きくなり得ます。特に削除、停止、設定変更などは慎重さが必要です。以下は、変更系コマンドを実行する前の最低限チェックです。

• 対象（パス、サービス名、ID、ホスト名）を具体的に指定しましたか

• 変更系の前に参照系（Get-）で現状を把握しましたか

• 可能であれば -WhatIf で影響を確認しましたか

• 実行ログや出力を保存し、後追いできる状態にしましたか

• 本番環境であれば、実行時間帯・影響範囲・ロールバックを検討しましたか

• 権限が必要な操作かどうかを把握し、組織ルールに従っていますか

このチェックリストを、チートシートの末尾に付けておくと、緊急対応時の事故防止に役立ちます。

よくある質問

Windows PowerShell 5.1とPowerShell 7はどちらを使うべきですか

原則として、要件で判断するのが安全です。既存資産（既存スクリプト、既存モジュール、運用ルール）がWindows PowerShell 5.1前提であれば、無理に移行せず、まずは現状維持＋検証環境でPowerShell 7を試す運用が堅実です。一方、新規の自動化やクロスプラットフォーム運用を視野に入れるならPowerShell 7が選択肢になります。いずれの場合も、まず $PSVersionTable を記録し、実行環境を明示できる状態にすることが重要です。

Get-Commandの結果が多すぎます。絞り込み方法はありますか

次の切り口が効果的です。

• 種別で絞る：-CommandType Cmdlet

• 名前で絞る：-Name "*Service*"

• モジュールで絞る：-Module ModuleName

• 動詞で絞る："Get-*"、"Set-*" など

また、出力を Select-Object で必要最小限にし、CSVに保存してExcel等でフィルタする方法も有効です。

コマンドがないと言われます。モジュールはどう確認しますか

まず Get-Module -ListAvailable でモジュールの存在を確認し、次に Get-Command -Module <ModuleName> でそのモジュールのコマンド一覧を確認します。コマンド名が曖昧なら Get-Command -Name "*Keyword*" で近い候補を探してください。

Get-Helpはどう読むのが早いですか

最初は Get-Help <Cmdlet> -Examples を推奨いたします。具体例が見られるため、最短で動かせます。次に詰まったら -Full でパラメーターの意味や詳細な説明を確認してください。

変更系コマンドが怖いです。安全策はありますか

可能な場合は -WhatIf で事前確認し、必要に応じて -Confirm を併用してください。また、実行結果の記録（Out-File/Export-Csv）を残すことで、後追い調査と説明責任に強くなります。対象の特定（ID指定、パスの明確化）も安全性に直結します。

まとめ

PowerShellのコマンド一覧は、静的な「まとめ」を読むよりも、Get-Commandで自分の環境から抽出して保存し、用途別に再編集することで、はじめて運用で機能します。加えて、Get-Help（特にExamples）で使い方を逆引きする癖をつけることで、暗記に頼らず自己解決できるようになります。

次に取るべき行動は明確です。

1. commands.csv を出力し、環境のベースラインを作る

2. ops-favorites.csv を用途別に作り、現場で引ける一覧にする

3. 変更系は -WhatIf とログ保存で安全に運用する

PowerShellはバージョンやモジュールで差分が出やすい分野ですが、記事のとおり「環境から一覧を生成する」運用を確立しておけば、仕様変更や環境差があっても追随しやすくなります。必要に応じて、本記事の用途別抜粋（patterns）を、貴社の業務（例：AD運用、ファイルサーバ運用、ログ収集、リモート管理）に合わせて最適化してください。