「このスクリプト、なんだか重いな……」
サーバーの管理や日々の定型業務を自動化しているとき、ふと時計を見てそう感じたことはありませんか。数万件のログ解析や、大量のファイル操作。実行ボタンを押してから完了するまで、コーヒーを淹れに行くほどの時間がかかっているなら、そこには必ず「ボトルネック」が潜んでいます。
しかし、多くのエンジニアが陥る罠があります。それは、確固たるデータを持たずに「なんとなくこのループが怪しい」と勘に頼ってコードを書き直してしまうことです。数値的な裏付けのない修正は、霧の中を地図なしで歩くようなもの。最悪の場合、苦労して書き直したのに1秒も速くならなかった、という不毛な結果を招きかねません。
この記事では、PowerShellに標準搭載されている魔法の型、Measure-Commandを使いこなし、処理時間を1ミリ秒単位で精密に計測する技術を解説します。
「『たぶん速い』は、エンジニアの怠慢だ。」
この言葉を胸に、あなたのスクリプトの健康状態を可視化し、真の最適化を実現する第一歩を今ここから踏み出しましょう。
2. なぜあなたのスクリプトは遅いのか？「計測」の重要性
あなたの書いたスクリプトが遅いとき、真っ先に疑うべきは「どこで時間が溶けているか」です。実は、100行のコードがあったとしても、全体の処理時間の9割を占めているのは、わずか数行のループ処理だったということは珍しくありません。
勘に頼る最適化が失敗する理由
なぜ、ベテランであっても勘に頼ったチューニングは失敗するのでしょうか。それは、プログラミングの実行速度が「環境」や「データ量」によって非線形に変化するからです。
たとえば、自分のPCで10件のデータを処理したときは最速だった書き方が、本番サーバーで100万件を処理した瞬間に、メモリを食いつぶす最悪のコードに豹変することがあります。比喩で言うなら、体重計に乗らずにダイエットを始めるようなものです。「なんとなく食べる量を減らした」と思っていても、実際には一番太る原因である間食（非効率なループ）に気づかなければ、数字は一向に減りません。
現場のシステム管理者からは、「処理を改善したつもりだったが、実際に測ってみたら前のほうが速かった」という苦い経験の声をよく耳にします。客観的な数値、つまり「エビデンス」がない修正は、単なる自己満足に終わるリスクを常にはらんでいるのです。
ピーター・ドラッカーは「計測できないものは改善できない」と説きました。この原則はIT自動化の世界でも全く同じです。実行時間をミリ秒単位で把握すること。それが、停滞したスクリプトを覚醒させる唯一の道なのです。
3. 基本の「黒魔術」：Measure-Commandの使い方
PowerShellで処理時間を測るために、特別なツールをインストールする必要はありません。標準で用意されているMeasure-Commandというコマンドレットこそが、闇を照らすサーチライトとなります。
1行で解決！ワンライナーの魔法
使い方は驚くほどシンプルです。計測したい処理を{ }（スクリプトブロック）で囲む。これだけです。
Measure-Command { Start-Sleep -s 2 }
このコマンドを実行すると、2秒間待機する処理（Start-Sleep）の時間を正確に測定してくれます。料理に例えるなら、これは「味見」の工程です。隠し味を足す前に、現在の塩分濃度（実行速度）を糖度計や塩分計（Measure-Command）で測り、味の再現性を高める行為に他なりません。
結果の読み方（TotalMillisecondsに注目せよ）
実行すると、DaysやHoursといった項目が並んだリストが出力されます。ここで見るべきはただ一点、TotalMillisecondsです。
Secondsの項目だけを見てしまうと、1秒未満の差が切り捨てられてしまいます。しかし、エンジニアが戦うのは1秒未満の「コンマ数秒」の世界です。0.1秒の突破を積み重ねることが、最終的に数時間の時短を生むのです。
SNSや技術コミュニティでは「Measure-Commandの結果をそのまま見ると情報が多すぎるので、.TotalMillisecondsで絞り込んで表示するのが鉄則」というTipsが広く共有されています。
(Measure-Command { [処理内容] }).TotalMilliseconds
このように記述すれば、純粋な数値だけが返ってくるようになります。ボヤけていた視界が、矯正レンズを通した瞬間に1.5の視界でハッキリ見えるようになる――そんな感覚を味わえるはずです。
4. 【実況】どっちが早いか対決！書き方による速度差を検証
それでは、実際に「どちらの書き方が最速か」を競わせる計測対決を行ってみましょう。今回比較するのは、PowerShellで最も頻繁に使われる「繰り返し処理」の2つの書き方です。
Foreach vs ％（ForEach-Object）の衝撃的な結果
1から10,000までの数字を回す処理で比較します。
- パターンA：foreachキーワード（構文）
- パターンB：ForEach-Object（パイプライン）
エンジニアの間では「あっちのほうが書きやすい」「こっちのほうがPowerShellらしい」と議論が絶えないテーマですが、計測という名の「真実を映す鏡」の前に、主観は通用しません。
実際に私の環境で計測したところ、驚くべき差が出ました。
- foreach構文: 約 5〜10 ミリ秒
- ForEach-Object (パイプライン): 約 150〜200 ミリ秒
なんと、20倍近い速度差が生まれることがあります。パイプライン（%）は、1つずつオブジェクトを渡すオーバーヘッド（準備の手間）が発生するため、単純なループでは「foreach構文」のほうが圧倒的に速いのです。
業界では「パイプラインこそがPowerShellの華」という見方が広がっていますが、こと「速度」に関しては、華奢な見た目に反してパワフルな「foreach構文」がF1のラップタイムのごとく圧倒的なタイムを叩き出します。
このように、一度「計測対決」をさせてしまえば、AIが生成したコードやネットの古い情報を鵜呑みにすることなく、自分の環境における「真の正解」を自ら証明できるようになります。これが、ただの書き手と、プロのエンジニアを分ける決定的な境界線です。
5. 注意点！Measure-Commandで「測れないもの」と対策
非常に便利なMeasure-Commandですが、これには「副作用」とも呼べる大きな注意点があります。これを知らずに使うと、デバッグ中にパニックに陥ることになります。
標準出力が消える罠とその回避策
「とはいえ、Measure-Commandを使ったら画面に何も表示されなくなったんだけど？」
そんな声が聞こえてきそうです。実は、Measure-Commandは正確な時間を測るために、計測対象のコードが出力する「標準出力」をすべて飲み込んで（抑制して）しまう性質があります。
これは、画面に文字を表示する処理自体が負荷となり、純粋な計算時間の邪魔になるのを防ぐための仕様です。しかし、実行中の経過を見たい場合には不便ですよね。
この罠を回避するには、以下の2つのアプローチがあります。
- Write-Hostを使う:
Write-Hostは標準出力ではなく、ホストへ直接書き込むため、Measure-Commandの中でも画面に表示されます。 - Out-Defaultへパイプする: 計測したい処理の中で
... | Out-Defaultを使うことで、無理やり画面に出力させることができます。
ただし、画面表示を増やせば増やすほど、計測結果は「純粋な処理時間」から遠ざかり、遅くなっていきます。F1マシンに重いカメラ機材を載せてラップタイムを測るようなものです。最終的な「勝負のタイム」を測る際は、それらの表示用コードは削ぎ落とすのが、エンジニアとしての誠実な姿勢でしょう。
6. まとめ：計測は「時短」への最短ルート
ここまで、PowerShellにおける計測の魔法Measure-Commandについて解説してきました。
内容を振り返ると、重要なポイントは以下の3点です。
- 「なんとなく」を捨て、
TotalMillisecondsで数値を直視する。 - 書き方に迷ったら「どっちが早いか対決」をさせ、数値で正解を選ぶ。
- 標準出力が抑制される特性を理解し、デバッグと計測を切り分ける。
今日からできる最小のアクションとして、あなたが最近書いた「少し重いな」と感じるスクリプトのどこか一箇所を、Measure-Command { ... } で囲ってみてください。これだけで、ブラックボックスだったコードの中身が、数値という光に照らされて透けて見えるようになります。
コードのダイエットも、まずは体重計に乗ることから始まります。理想的な体型（高速なスクリプト）への道は、現実を知る勇気から始まります。コンマ数秒を削るポイントを特定し、無駄を削ぎ落とした先には、昨日までの自分とは違う「確信」を持ってコードを書くあなたの姿があるはずです。
「コードの健康診断、0.1秒の裏側に真実がある。」
さあ、そのストップウォッチを動かしましょう。あなたのスクリプトには、まだまだ速くなるポテンシャルが眠っています。
コメント