PowerShellの実行履歴を調査｜PSReadLine・イベントログに残る痕跡

PowerShellの実行履歴は、条件が合えば確認できます。しかし、一つの履歴だけで、過去に実行されたすべてのコマンド、処理結果、実際の操作者まで分かるわけではありません。

調査では、PSReadLineの履歴ファイル、PowerShellイベントログ、Windowsのプロセス作成記録、Transcript、さらにファイルシステムやUSB・クラウド等の周辺記録を分けて確認します。

特に企業の不正調査では、

PowerShellが起動された
と
特定コマンドが実行された

さらに、

コマンドが記録された
と
その処理が実際に成功した

を区別することが重要です。

この記事では、情報持ち出し、ファイル削除、不審なコマンド実行等を確認する企業担当者向けに、PowerShellに残る主な痕跡と、その証拠としての限界を整理します。

※Microsoft公式技術資料の確認日：2026年9月21日

PowerShellの実行履歴だけでなく、アプリ実行、ファイル操作、ログオン、USBなどWindows PCに残る証拠全体を確認したい場合は、Windows・PCフォレンジックで、主な調査項目と確認方法をまとめています。

PowerShellの実行履歴はどこまで分かる？

過去のPowerShell操作を確認できる場合があります。ただし、確認できる範囲は、利用したPowerShell・ホスト、ログ設定、保存状態などによって変わります。

Microsoftの公式資料では、PowerShellの履歴には、現在のセッションを対象とする組み込み履歴と、PSReadLineが管理する履歴という異なる仕組みがあることが説明されています。

調査では、大きく次の3段階で考えると整理しやすくなります。

比較的確認しやすいこと

• PowerShellの対話画面から入力されたコマンド文字列
• PowerShellプロセスが起動した痕跡
• ログ設定が有効だった場合のスクリプトやコマンド処理
• 使用されたアカウントやセッションに関する情報

条件が揃えば詳しく確認できること

• 実行されたスクリプトブロック
• コマンドレットやパラメーター
• Transcript等に残った入出力
• 対象ファイルの作成・変更・削除
• コマンドとUSB、クラウド、Web利用等の時間的な関係

一つの履歴だけでは判断できないこと

• コマンドが正常終了したか
• 問題となるファイルが実際に削除・コピーされたか
• データが社外へ持ち出されたか
• アカウント名義人本人が操作したか
• PowerShell利用の目的が不正だったか

したがって、PowerShell履歴は強い手掛かりになり得ますが、「何が記録されたか」と「その記録から何を証明できるか」は別に評価する必要があります。

PowerShellの履歴を調べる主な証拠

PowerShellには、一つの万能な「実行履歴ログ」があるわけではありません。

主な確認対象は次のとおりです。

証拠	主に分かること	主な条件	それだけでは分からないこと
PSReadLine履歴	対話的に入力されたコマンド文字列	PSReadLineと履歴保存が使用されている	正確な実行結果、操作者本人、全PowerShell処理
Event ID 4104	処理されたScript Blockの内容	Script Block Logging等の条件	処理による最終結果、実際の人物
Event ID 4103	Module Loggingによるコマンドレット等の処理情報	対象モジュールのLogging設定等	PowerShell全操作の完全記録
Security Event ID 4688	PowerShell等のプロセス作成	Audit Process Creationが有効	PowerShell内部で後から入力した全コマンド
4688のCommand Line	プロセス起動時の引数	追加のコマンドライン監査設定が有効	対話セッション内の全操作
Transcript	セッションの入力・出力等	Transcriptionが有効	ファイル操作等の最終的な実体を常に保証するものではない

Microsoftは、Script Block Loggingを有効にした場合にEvent ID 4104が記録されることを説明しています。また、Module LoggingではEvent ID 4103が記録され、Microsoftの技術資料ではコマンドレット名や出力等を含む例が示されています。

つまり、

PSReadLineがあるから十分
でも、
4104だけ見れば十分
でもありません。

調査目的に応じて、複数の記録を組み合わせます。

PSReadLineの履歴ファイルから何が分かる？

PSReadLineの履歴からは、PowerShellのコマンドラインで入力されたコマンドを確認できる場合があります。ただし、PowerShellで行われたすべての処理を記録する監査ログではありません。

PowerShellには、

• PowerShell自身が管理する「組み込みのセッション履歴」
• PSReadLineが管理する履歴

という別の仕組みがあります。

組み込み履歴は基本的に現在のセッションが対象で、セッション終了後には残りません。一方、PSReadLineは履歴をファイルへ保存し、別セッションからも利用できる仕組みです。

WindowsでのPSReadLine履歴の既定パスは、Microsoftの現行資料では次の形式です。

%APPDATA%\Microsoft\Windows\PowerShell\PSReadLine\$($Host.Name)_history.txt

一般的なConsoleHostでは、

ConsoleHost_history.txt

となります。

ただし、ファイル名はホストごとに異なります。

Microsoftは、Visual Studio CodeのPowerShell拡張機能では、

Visual Studio Code Host_history.txt

という別の履歴ファイルになる例を示しています。

HistorySaveStyleによって保存方法が変わる

PSReadLineのHistorySaveStyleには、現在の公式資料で次の設定があります。

• SaveIncrementally：各コマンド実行後に保存
• SaveAtExit：PowerShell終了時に追加
• SaveNothing：履歴ファイルを使用しない

既定値はSaveIncrementallyです。HistorySavePathによって保存先自体も変更できます。

したがって、

ConsoleHost_history.txtにない＝そのコマンドは実行されていない

とは判断できません。

機密情報が意図的に保存されない場合もある

PSReadLineは、パスワード、token、secret等を含む可能性があるコマンドについて、機密情報のフィルタリングを試みます。現行の公式資料でも、一部のコマンドラインが履歴ファイルへ書き込まれない仕組みが説明されています。

つまり、履歴の欠落には、

• 保存設定
• 使用ホスト
• PSReadLineの利用状況
• コマンドの実行形態
• 機密情報フィルタリング

など、複数の理由が考えられます。

また、PSReadLine履歴でコマンド文字列が確認できても、その文字列だけを使って、処理成功や正確な実行時刻、実際の操作者まで断定することは避けるべきです。

Event ID 4103・4104から何が分かる？

4103と4104は、同じPowerShell履歴ではありません。記録される条件と内容を分けて確認する必要があります。

Event ID 4104はScript Block Logging

Windows PowerShell 5.1では、Script Block Loggingが有効な場合、処理されたScript Blockの内容がMicrosoft-Windows-PowerShell/OperationalへEvent ID 4104として記録されます。

Script Block Loggingでは、対話的に入力されたものだけでなく、スクリプトや自動処理を含め、PowerShellが処理するScript Blockを記録対象にできます。

これはPSReadLineとの大きな違いです。

ただし、

PowerShellを使えば4104が必ず残る

という意味ではありません。

調査時には、対象期間にScript Block Loggingが有効だったか、ログが保存されているかを確認します。

Event ID 4103はModule Logging

Module Loggingを有効にすると、指定されたPowerShellモジュールについてパイプライン実行イベントを記録できます。

Microsoftは、Module Loggingが未設定の場合、各モジュールのLogPipelineExecutionDetailsによって決まり、既定では$falseであると説明しています。

Microsoftの技術資料では、Module LoggingによるEvent ID 4103に、コマンドレット名や出力等が記録される例も示されています。

したがって4103も、

すべてのPowerShellコマンドを常時記録する万能ログ

ではありません。

PowerShell 7ではログ名も確認する

Windows PowerShell 5.1とPowerShell 7系を混同しないことも重要です。

Windows PowerShell 5.1では主に、

Microsoft-Windows-PowerShell/Operational

を確認します。

一方、現在のPowerShell 7系のMicrosoft資料では、Windows上のイベントログはPowerShellCoreという名前で登録され、Script Block Loggingの4104は、

PowerShellCore/Operational

へ記録されます。

そのため調査では、

• Windows PowerShell 5.1なのか
• PowerShell 7系なのか
• どのログプロバイダーが使われていたか
• 対象期間にLoggingが有効だったか

を確認してからログの有無を評価します。

WindowsのイベントログからPowerShell起動を確認できる？

確認できる場合があります。代表例がSecurityログのEvent ID 4688です。ただし、4688でPowerShellプロセスが確認できることと、PowerShell内部で実行された全コマンドが分かることは別です。

Event ID 4688は、新しいプロセスが作成されたときに生成される監査イベントです。

Microsoftの資料では、4688から、

• Security ID／SID
• アカウント名
• Logon ID
• 新しいプロセス名
• 親となるプロセス
• Process ID

等を確認できます。

例えば対象時刻にpowershell.exeやpwsh.exeのプロセス作成が確認できれば、PowerShell起動を検討する重要な手掛かりになります。

ただし4688自体は、Audit Process Creationが有効な環境で取得する監査記録です。

さらに、プロセス起動時のコマンドライン引数まで4688へ記録するには、

Include command line in process creation events

の設定も必要です。Microsoftは、この設定が無効または未構成の場合、Process Command Line欄は記録されず、既定では空になると説明しています。

つまり、

4688がある
≠
PowerShell内部の全コマンドが分かる

です。

PowerShell起動時に-Commandやスクリプト等が引数として指定され、そのコマンドラインが監査されていれば有力な情報になります。一方、PowerShell起動後に対話的に入力された内容は、4688の起動時コマンドラインだけでは追跡できません。

コマンド履歴があれば、処理が成功したと判断できる？

原則として、コマンド文字列が記録されているだけでは、その処理が正常に完了したとは断定できません。

例えば、あるファイルを削除する内容のコマンドが履歴に残っていたとしても、

• 対象ファイルが存在しなかった
• 権限不足だった
• パスが誤っていた
• エラーで中断した
• 条件分岐によって実行対象にならなかった

といった可能性があります。

同様に、

コピーするコマンドがある
ことと
問題のファイルが実際に目的の場所へコピーされた
ことは別です。

処理成功まで確認したい場合は、目的に応じて次の記録を照合します。

• Transcript等に残る入出力
• 4103等に残る処理情報
• コピー先・削除対象となった実ファイル
• $MFT
• $UsnJrnl
• USB媒体側のファイルシステム
• EDR・DLP
• Web・クラウドサービス側の監査ログ
• ブラウザやアプリ固有ログ

ファイル作成・変更・削除の確認については、MFT・USNジャーナルで何が分かる？Windowsのファイル作成・変更・削除履歴を解析で詳しく説明しています。

コピーについては、Windowsでファイルコピー履歴は分かる？USBへのコピー痕跡と調査方法も参考になります。

コマンドの記録は「実行内容を調べる証拠」であり、目的となった結果そのものの証拠とは限りません。

PowerShell履歴がなければ、実行されていないと言える？

言えません。PowerShell履歴が確認できないことだけを理由に、「PowerShellは使用されていない」と結論付けることはできません。

履歴が確認できない理由としては、例えば次が考えられます。

• PSReadLineを利用していなかった
• HistorySaveStyleがSaveNothingだった
• ConsoleHost以外のホストを利用していた
• 履歴の保存先が変更されていた
• 対話的な入力ではなくスクリプトや自動処理だった
• Script Block LoggingやModule Loggingが対象期間に有効ではなかった
• Windows PowerShellとPowerShell 7で確認すべきログを取り違えている
• イベントログの保持期間を超えた、または上書きされた
• 調査時に取得できたデータの範囲外だった
• PSReadLineの機密情報フィルタリング等により履歴へ保存されなかった

したがって、

履歴がない
という事実と
実行されなかった
という結論の間には、確認すべき条件があります。

逆に、ログが見つからない状態自体が重要な場合もあります。

本来ログを集中管理していた環境なのに対象期間だけ欠落している、EDRやSIEMには別の痕跡がある、といった場合は、その不整合も含めて調査します。

誰がPowerShellを実行したか分かる？

使用されたアカウントを確認できる場合はありますが、それだけで特定社員本人が操作したとは断定できません。

4688等では、SID、アカウント、Logon ID等からプロセスをセッションと関連付けられる場合があります。

しかし企業環境では、

• 共用PC
• 共用アカウント
• 管理者による作業
• タスクスケジューラ
• サービス
• 運用ツールによる自動処理
• EDRや管理製品
• 遠隔操作
• PowerShell Remoting

等も考慮する必要があります。

つまり、

アカウント＝人物

ではありません。

実際の操作者との関係を評価するときは、

• Windowsログオン記録
• Logon ID
• PowerShell実行時刻
• 同時間帯のユーザー操作
• RDPや遠隔操作記録
• EDR
• 入退室や端末割当情報

等を時系列で照合します。

Windowsのログオン記録の読み方については、Windowsのログイン履歴を確認｜イベントログで分かること・限界で詳しく説明しています。

情報持ち出しやファイル削除まで確認するには何を見る？

PowerShell履歴だけで情報持ち出しやファイル削除まで断定するのではなく、「コマンド」「対象ファイル」「コピー先・送信先」「アカウント」を時系列でつなげて確認します。

例えば情報持ち出しが疑われる場合は、次のように段階を分けます。

1．PowerShell側

コピー、圧縮、ダウンロード、アップロード等に関係するコマンドやスクリプトが記録されているかを確認します。

↓

2．対象ファイル側

問題となるファイルについて、作成・変更・改名・削除等の痕跡があるか確認します。

↓

3．コピー先・保存先

USB、別フォルダ、ネットワーク共有等に対応するファイルが存在するかを確認します。

↓

4．外部サービス側

Webやクラウドを利用した疑いがあれば、ブラウザ履歴、クラウド監査ログ、Proxy、EDR等を照合します。

Web利用については、ブラウザ履歴はフォレンジックでどこまで分かる？Chrome・Edgeを調査も参考になります。

↓

5．利用者・セッション

対象時刻にどのアカウント・セッションが利用されていたかを確認します。

このように照合すると、

PowerShellでコピーらしいコマンドが存在した
から
特定社員が機密ファイルを社外へ持ち出した

までを一足飛びに結論付けることを避けられます。

PowerShellはWindows管理で正規に広く利用されるツールです。

PowerShellを使ったという事実そのものは、不正行為を意味しません。

不正調査では、コマンドの内容、対象、時刻、結果、業務上の必要性、周辺証拠を分けて評価します。

調査前にPowerShellや対象PCを操作してもよい？

証拠として調べる可能性がある場合は、履歴を確認するためだけに対象PC上で不用意なPowerShell操作を始めることは避けた方が安全です。

新しい操作によって、

• PowerShellの履歴
• ファイルのアクセス時刻
• イベントログ
• 一時ファイル
• システム状態
• その他のアーティファクト

が更新される場合があります。

特に、

• ログをクリアする
• 初期化する
• OSを再インストールする
• クリーンアップを実行する
• 復旧・解析ソフトを対象PCへ安易にインストールする
• 調査対象PCをそのまま別社員へ再配布する

といった操作は、確認できる証拠へ影響する可能性があります。

まず、

• 何を確認したいのか
• 問題となる期間
• 現在の電源・ログイン状態
• 接続されている機器
• すでに実施した操作
• 会社側に別保存されているEDR・SIEM・クラウドログ

を整理します。

なお、「証拠保全するなら必ず直ちに電源を切る」わけでもありません。

暗号化解除中の端末や揮発性情報を取得する必要がある状況などでは、電源状態の扱いが変わります。

証拠として利用する可能性があるPCについては、デジタルフォレンジックの証拠保全とは？原本・ディスクイメージ・ハッシュ値の意味も確認してください。

まとめ

PowerShellの実行履歴は、PSReadLineだけを見るのではなく、複数の異なる記録を組み合わせて評価することが重要です。

特に覚えておきたいのは次の点です。

• PSReadLineには永続的な履歴ファイルがあるが、PowerShellの全実行を記録する万能ログではない
• ConsoleHost_history.txt以外のホスト別履歴が存在する場合がある
• Event ID 4104はScript Block Loggingの設定条件を確認する
• Event ID 4103はModule Loggingの設定・対象モジュールを確認する
• Windows PowerShell 5.1とPowerShell 7では確認するログプロバイダーが異なる
• Event ID 4688はプロセス作成の記録であり、コマンドラインまで残すには追加設定が必要
• コマンド文字列があることと、その処理が成功したことは別
• PowerShell履歴がないことと、PowerShellが使われていないことは別
• アカウントが分かることと、実際の操作者本人を特定することは別
• コピー・削除・情報持ち出しまで判断するには、ファイル、USB、ブラウザ、クラウド等の周辺証拠との照合が必要

日常的なシステム管理として履歴の有無を確認するだけであれば、自社の情報システム部門で対応できる場合があります。

一方、

• 懲戒、損害賠償、刑事対応等を検討している
• 削除・改変・ログ欠落が疑われる
• USBやクラウドへの情報持ち出しまで確認したい
• 複数の証拠を時系列で照合する必要がある
• 特定人物の操作として評価する必要がある
• 対象PCを証拠として保全したい
• 調査結果を第三者へ説明する必要がある

といった場合は、単に履歴ファイルを開くだけではなく、証拠保全を含むデジタルフォレンジック調査を検討する範囲になります。

重要なのは、PowerShellの履歴を見つけること自体ではありません。

その痕跡が「何を示し、何を示していないのか」を区別することが、PowerShellの実行履歴を証拠として正しく評価する基本です。

参考資料

• Microsoft Learn「about_History」
• Microsoft Learn「about_PSReadLine」
• Microsoft Learn「Set-PSReadLineOption」
• Microsoft Learn「about_Logging」Windows PowerShell 5.1
• Microsoft Learn「about_Logging_Windows」PowerShell 7
• Microsoft Learn「about_Group_Policy_Settings」
• Microsoft Learn「4688(S): A new process has been created」
• Microsoft Learn「コマンド ライン プロセスの監査」
• Microsoft Learn「カスタム スクリプト拡張機能または実行コマンドによって実行されるPowerShellスクリプトをデバッグする」