はじめに
Publickey の記事で、Microsoft が UNIX 系コマンドを Windows に移植した Coreutils for Windows を一般公開したことを知りました。 筆者のメイン環境はこれまで WSL で、PowerShell はあまり積極的には使っていませんでした。
しかし最近は、AI エージェントを使ってコーディング以外の作業も行うようになりました。 資料整理、ローカルファイルの確認、Windows アプリのログ調査など、Windows 側で完結したほうが早い作業が増えています。 そのときに cmd や PowerShell で grep、find、ls、head などを同じ感覚で使えないと、少し手が止まることがあります。
手元の Windows 環境に実際にインストールし、cmd と PowerShell の両方で使ってみたところ、とくに grep と find がそのまま使える体験がかなりよかったです。 一方で、PowerShell のエイリアスや Windows 固有のパス・改行・権限まわりは Linux と同じつもりで使うとハマりそうでした。
本記事では、Coreutils for Windows のインストール手順、cmd / PowerShell で試した使い方、実際に使って便利だった点、導入前に押さえておきたい注意点をまとめます。
Coreutils for Windows とは
Coreutils for Windows は、Microsoft がメンテナンスしている Windows 向けの UNIX 風コマンド群です。 公式リポジトリでは、uutils/coreutils、uutils/findutils、uutils/grep を Windows 向けにまとめたものとして説明されています。
ざっくり言うと、Linux、macOS、WSL でよく使うコマンドを Windows のネイティブなコマンドラインから使えるようにするためのパッケージです。 WSL を起動せずに grep で検索したり、find でファイルを探したり、head や tail で出力を絞ったりできます。
ただし、現時点では公式 README にも preview と明記されています。 Publickey の記事では「一般公開」と紹介されていますが、既存スクリプトへ入れるというよりはまずは手元の作業や小さな自動化で挙動を確認しながら使うのがよさそうです。
なぜ Windows 側に入れるのか
Windows で UNIX 系コマンドを使いたいだけなら、WSL、Git for Windows、MSYS2、Cygwin などの選択肢があります。 筆者も普段の開発作業は WSL 側で済ませることが多く、これまでは Windows 側のコマンドラインで無理に UNIX 系コマンドを使う必要はあまりありませんでした。
それでも Coreutils for Windows を入れてよかったのは、「Windows 側で完結したい作業」が意外とあるためです。 たとえば、Windows アプリのログ、ダウンロードしたファイル、PowerShell で生成した一時ファイル、エクスプローラーから扱っている作業ディレクトリなどは、最初から Windows 側にあります。 その場で grep -R や find . -name を使えると、WSL へ移動したりパスを変換したりする手間がなくなります。
特に AI エージェントへ作業を依頼するときは、対象がコードだけとは限りません。 スクリーンショット、設定ファイル、Windows アプリの出力、ダウンロードフォルダ内の資料など、Windows 側にあるファイルを扱うことがあります。 そのような場面で、Windows ネイティブのシェル上でも慣れた検索コマンドを使えると、エージェントに指示する側の負担も減ります。
インストール
インストールは winget で行えます。
winget install Microsoft.CoreutilsGitHub のリリースページによると、初回リリースには Rust 製の uutils/coreutils、uutils/findutils、新しく書かれた uutils/grep、既存の DOS sort / find 呼び出しを壊さないための shim、PowerShell で glob パターンを扱いやすくする wrapper が含まれています。 単に実行ファイルを置くだけではなく、Windows 既存コマンドとの共存もある程度考えられているのがポイントです。
インストール後は、開いている cmd や PowerShell をいったん閉じてから起動し直します。 PATH の反映前に確認すると、コマンドが見つからないように見えることがあります。
cmd では where で実行ファイルの場所を確認できます。
where grep
where findPowerShell では Get-Command または gcm で確認できます。
Get-Command grep
Get-Command find
# gcm grep
# gcm findgrep は PowerShell の標準エイリアスと衝突しにくいので、そのまま使いやすいです。 一方で ls、cat、cp、rm などは PowerShell 側に既存のエイリアスがあります。 このあたりは後述する注意点として押さえておく必要があります。
cmdで使ってみる
まずは cmd で使ってみます。 grep は、Linux や macOS で使っている感覚にかなり近いです。
grep -R "TODO" .-R はディレクトリを再帰的に検索するためのオプションです。 Windows 側で作業しているプロジェクトやログ置き場でも、WSL に移動せずにそのまま文字列検索できます。 これだけでも「いつもの手癖が Windows 側で通る」感じがありました。
拡張子を絞りたい場合は、--include を使えます。
grep -R --include="*.md" "Coreutils" .PowerShell の Select-String でも同じような検索はできますが、普段から grep を使っていると -R や --include のほうがすぐ書けます。 ちょっとした確認作業では、この慣れの差が大きいです。
find も使えます。
find . -name "*.md"さらに、find と grep を組み合わせると、Markdown ファイルだけを対象に検索できます。
find . -name "*.md" -print | xargs grep "PowerShell"このようなパイプラインは bash / zsh でよく書く形です。 Windows 側で同じ考え方のまま書けるので、ログ調査や小さなメンテナンス作業ではかなり楽になります。 ただし、Windows のユーザーディレクトリやプロジェクトパスには空白が入ることがあります。 xargs に渡す前提のワンライナーでは、対象ディレクトリに空白を含むファイル名がないかを確認しておくと安心です。
注意：Windows にはもともと
findという文字列検索用のコマンドもあります。Coreutils for Windows のリリースノートでは、既存の DOSfind/sort呼び出しが壊れないようにする shim についても触れられています。既存のバッチファイルがある場合は、導入後にどちらのfindが呼ばれているかを確認しておくと安心です。
PowerShellで使ってみる
PowerShell でも grep や find は使えます。
grep -R "TODO" .find . -name "*.md"PowerShell で使っていて一番便利に感じたのは、PowerShell の作業ディレクトリのまま UNIX 系の検索コマンドを混ぜられる点です。 たとえば、PowerShell で環境変数を確認したり、Windows 側のツールを起動したりしながら、検索だけ grep に任せる、という使い方ができます。
$env:Path -split ";" | grep "Coreutils"grep は標準入力から受け取った文字列も検索できるため、PowerShell の出力を軽く絞り込む用途にも使えます。 もちろん PowerShell には Where-Object や Select-String がありますが、単純な文字列フィルタなら grep のほうが短く書ける場面があります。
また、Coreutils for Windows のインストーラーは対話的な PowerShell セッションに PSReadLine 経由で統合され、glob パターンを UNIX 系シェルや cmd に近い感覚で扱えるようにしている、と README に説明されています。 たとえば echo *.txt は複数のファイル名として展開され、echo '*.txt' は文字列として扱われる、という方向の補助です。 ただし、この補助があるからといって PowerShell の構文が bash になるわけではありません。
便利だったコマンド
実際に触っていて、最初にありがたみを感じたのは次のあたりです。
| コマンド | 用途 | よかった点 |
|---|---|---|
grep |
ファイルや標準入力の文字列検索 | bash / zsh の手癖で検索できる |
find |
ファイル名や条件での検索 | Windows 側の作業ディレクトリをそのまま探索できる |
head / tail |
出力の先頭・末尾確認 | ログや長い出力を軽く確認しやすい |
wc |
行数・バイト数の確認 | 記事ファイルやログのサイズ確認がすぐできる |
xargs |
検索結果を後続コマンドへ渡す | 小さなパイプラインを書きやすい |
とくに grep と find は、普段の作業で出番が多いです。 Windows のファイルツリーを調べるだけならエクスプローラーでもできますが、条件を変えながら何度も検索する場合はコマンドラインのほうが速いです。
たとえば、ログファイルだけを拾って、エラー行を探す場合は次のように書けます。
find . -name "*.log" -print | xargs grep "ERROR"Markdown の記事だけを対象に、特定の単語が入っているファイルを探すこともできます。
find . -name "*.md" -print | xargs grep -n "Coreutils"-n を付けると行番号が表示されるため、エディタで該当箇所を開くときに便利です。 このあたりは WSL 上でいつもやっている作業そのままで、Windows 側でも違和感が少なかったです。
注意点
Coreutils for Windows は便利ですが、Linux と完全に同じ環境になるわけではありません。 公式 README に書かれている注意点のうち、実際に使う前に覚えておきたいものをまとめます。
まだpreviewである
公式 README では、このプロジェクトは preview とされています。 また、最初のリリースページでも「バグがあることを想定してほしい」という趣旨の説明があります。
そのため、業務の重要なバッチや既存の自動化にいきなり組み込む場合は、事前に検証したほうがよいです。 手元の調査、個人用スクリプト、小さな補助ツールから使い始めるのが安全だと思います。
PowerShell 7.4以降が必要
公式 README では、PowerShell 7.4 以降が必要とされています。 古い Windows PowerShell 5.1 で同じように使える前提で考えるとハマります。
PowerShell のバージョンは次のように確認できます。
$PSVersionTable.PSVersionWindows 標準の「Windows PowerShell」と、別途インストールした「PowerShell 7」は別物です。 ターミナルのプロファイルやショートカットで、どちらを起動しているかも確認しておくとよいです。
PowerShellのエイリアスと衝突する
PowerShell には、UNIX 系コマンドに似せたエイリアスがいくつか定義されています。 代表的なのは ls、cat、cp、mv、rm、pwd などです。
| 入力 | PowerShell 側の既存エイリアス例 | Coreutils 側を明示したい場合 |
|---|---|---|
ls |
Get-ChildItem |
ls.exe |
cat |
Get-Content |
cat.exe |
cp |
Copy-Item |
cp.exe |
mv |
Move-Item |
mv.exe |
rm |
Remove-Item |
rm.exe |
対話的に使うだけなら、PowerShell のエイリアスでも困らないことがあります。 ただし、Coreutils のオプションを使うつもりで PowerShell のコマンドレットが実行されると、エラーの原因が分かりにくくなります。
スクリプトに書く場合は、grep や find のように衝突しにくいものはそのまま、衝突しやすいものは .exe 付きで書く、というルールにしておくと読みやすいです。
PowerShellのエスケープはbashと同じではない
Coreutils のコマンドが使えても、PowerShell の構文まで bash になるわけではありません。 公式 README でも、PowerShell のエスケープ文字はバックスラッシュではなくバッククォートである点が注意されています。
bash / zsh なら、find で条件をグループ化するときに次のように書けます。
find . \( -name "*.md" -o -name "*.txt" \)PowerShell では、同じ感覚で \( と書くと期待どおりに解釈されません。 PowerShell 側のエスケープを使う必要があります。
find . `( -name "*.md" -o -name "*.txt" `)この点は「コマンドは UNIX 風だが、シェルは PowerShell」という切り分けで考えると理解しやすいです。 grep のような単純なコマンドはそのまま使いやすい一方で、複雑な find 条件や引用符を多用するワンライナーでは、PowerShell の構文を意識する必要があります。
Windows固有の差分がある
Windows では、改行、パス、権限、シンボリックリンクなどが POSIX 系 OS と異なります。 公式 README でも、次のような caveat が挙げられています。
| 項目 | 注意点 |
|---|---|
| 改行コード | Windows のテキストファイルは CRLF が多く、$ による行末マッチや厳密なバイト数に影響することがある |
/dev/null |
Windows では NUL を使う |
| シグナル | SIGHUP、SIGPIPE、SIGUSR などの POSIX シグナルは使えない |
| パス区切り | / と \ の両方を受け付けるが、出力が \ 区切りになる場合がある |
| 権限 | Windows は POSIX のパーミッションビットではなく ACL を使うため、find -perm などは挙動が変わる可能性がある |
| シンボリックリンク | 既存リンクの読み取りはできるが、作成には開発者モードまたは管理者権限が必要 |
たとえば、Linux なら不要な出力を /dev/null に捨てることが多いですが、Windows 側では NUL を使います。
find . -name "*.log" > NULまた、find の出力パスを後続のコマンドに渡すときは、パス区切りが / なのか \ なのかでスクリプトの処理が変わることがあります。 単純な検索では気になりませんが、文字列加工を組み合わせる場合は一度出力を確認してから使うほうが安全です。
すべてのUNIXコマンドが入るわけではない
Coreutils for Windows という名前から、GNU Coreutils の全コマンドがそのまま入ると思うかもしれません。 しかし、公式 README では intentionally dropped として、Windows では提供しないコマンドも列挙されています。
たとえば dd、shred、sync、uname、chmod、chown、chroot、mkfifo、nohup などは、現時点では含まれていません。 POSIX 固有の概念に強く依存するもの、Windows の既存スクリプトを壊す可能性があるもの、Windows では有用性が低いものが外されています。
「Linux と同じ環境を Windows に丸ごと持ってくる」というより、「Windows ネイティブの作業でよく使う UNIX 風コマンドを使いやすくする」ものとして捉えるのがよさそうです。
使いどころ
筆者の感覚では、Coreutils for Windows は次のような場面で便利です。
- Windows 側のディレクトリをその場で検索したい
- WSL を起動するほどではない軽いログ確認をしたい
cmdやPowerShellの作業中にgrep/findの手癖を使いたい- Windows ネイティブのツールと UNIX 風のパイプラインを軽く組み合わせたい
- コーディング以外の資料整理や調査でも、Windows 側で検索作業を完結させたい
逆に、複雑なシェルスクリプトや POSIX 前提の処理をそのまま動かしたい場合は、WSL のほうが向いています。 とくにシグナル、権限、パス、プロセス制御まで含むスクリプトは、Coreutils for Windows だけで吸収しきれるものではありません。
軽い検索や確認は Coreutils for Windows、Linux 前提の処理は WSL、PowerShell のオブジェクト操作が欲しい場面は PowerShell コマンドレット、という使い分けが現実的だと思います。
まとめ
Coreutils for Windows をインストールすると、Windows の cmd や PowerShell から grep、find、head、tail、wc などの UNIX 風コマンドを使えるようになります。 特に bash / zsh でよく使っている grep -R や find . -name を Windows 側の作業ディレクトリでそのまま使えるのは、想像以上によい体験でした。
一方で、PowerShell のエイリアス衝突、PowerShell 独自のエスケープ、Windows の CRLF や NUL、POSIX シグナルや権限の違いなど、Linux と完全に同じ前提で使えない点もあります。 公式リポジトリでも preview とされているため、まずは手元の作業や小さなスクリプトで試し、既存のバッチや業務スクリプトに入れるのはもう少し待ったほうがよさそうです。
今回の作業で改めて感じたのは、WSL をメイン環境にしていても、Windows 側で少しだけ UNIX 風の道具が欲しい場面はかなり多いということです。 特に AI エージェントをコーディング以外の作業にも使うようになると、Windows 側のファイルやログをその場で扱えることの価値が上がります。 WSL を置き換えるものではありませんが、cmd や PowerShell の日常作業に grep と find が加わるだけで、調査や確認の速度はかなり上がります。
コメント