はじめてのバッチファイル作成ガイド：構造・作り方・使い方と注意点をやさしく解説

はじめに

この記事では、Windowsでよく使われる「バッチ（.bat）」を、はじめて作る人向けに、基本構造から作り方、実行方法、つまずきやすい注意点までを一通りまとめます。

バッチは、コマンドプロンプトで実行するコマンドを、あらかじめファイルに書いておき、上から順にまとめて実行できる仕組みです。

毎回同じ手順を繰り返す作業ほど効果が出やすく、ちょっとした自動化でも「手作業のミス」「やり忘れ」「作業時間」を減らせます。

「コマンドをいくつか手で打つのが面倒」「毎回同じ作業を忘れずに実行したい」という場面で、バッチは小さな自動化として役に立ちます。

この記事のゴール（何ができるようになるか）

この記事を読み終えると、メモ帳などのテキストエディタで .bat を作成し、意図どおりに実行できるようになります。

さらに、実行結果をログとして残す、実行方法を固定する、失敗したときに止める、といった「実際に運用するための最低ライン」も押さえます。

また、管理者権限の扱い、文字化け、パス（ファイルの場所）の書き方など、初心者がハマりやすいポイントを自分で切り分けられる状態を目指します。

バッチ（.bat）が役立つ代表シーン3つ

ひとつ目は、ネットワーク情報の確認やログ保存など、同じコマンドを何度も実行する作業です。

結果をファイルに残せるので、後から比較したり、問い合わせ対応に使ったりもしやすくなります。

ふたつ目は、フォルダのコピーやバックアップなど、決まった順番で実行したい作業です。

手順が固定されることで、順番の間違いを防ぎ、同じ品質で繰り返し実行できます。

みっつ目は、チーム内で作業手順を「ファイル1つ」にまとめて、手順漏れを減らしたい場面です。

手順書を読むより、実行するだけで同じ処理ができる状態にすると、引き継ぎや新人対応も楽になります。

注意：職場PC/権限/社内ルール（最初に一言）

業務PCでは、管理者権限の使用やスクリプト配布が規程で制限されていることがあります。

また、バッチは中身を書き換えられる性質があるため、共有の仕方や保管場所によってはセキュリティ上のリスクになります。

不明な場合は、自己判断で権限を上げたり配布したりせず、社内ルールに従ってください。

バッチファイルの基本（定義・構造・用途）

ここでは「バッチとは何か」を短く押さえてから、どういう形で書かれているかを確認します。

バッチは仕組みがシンプルなぶん、つまずいたときの原因も「実行環境」「書き方」「参照している場所（パス）」などに分解できます。

全体像がわかると、エラーの意味や直し方も理解しやすくなり、闇雲に書き換えて悪化させるのを防げます。

バッチファイル（.bat/.cmd）とは（表記統一の宣言）

バッチファイルは、Windowsのコマンドを上から順に実行するためのテキストファイルです。

通常はコマンドプロンプト（cmd.exe）で解釈され、ファイルに書かれた行が順番に処理されます。

つまり、コマンドを「手で1行ずつ打つ」代わりに、「ファイルに並べて一気に実行する」ための仕組みだと考えると理解しやすいです。

この記事では拡張子が .bat のものを「バッチ（.bat）」として説明し、必要に応じて .cmd との違いも触れます。

実務ではログ出力やエラー時の停止、実行する場所の固定などが重要になります。

.bat と .cmd の違い（早見表）

両者はどちらもコマンドを順番に実行する目的では似ており、初心者の範囲では「まずは .bat で作る」で問題ないことが多いです。

ただし環境や互換性の扱いに差があるため、迷ったときの目安を押さえておきます。

日常的な自動化（ログ取得、ファイル操作の補助、簡単な手順の固定化）では、.bat と .cmd の差を意識する場面は多くありません。

迷ったらまずは .bat で動く形を作り、必要に応じて運用ルールに合わせて拡張子を揃えるのが現実的です。

基本構造（コマンドの並び/改行/終了）

バッチの中身は、基本的に「1行に1コマンド」を並べたものです。

上から順に実行され、途中でエラーが起きても、何もしなければそのまま次の行に進むことがあります。

失敗させたくない場面では「エラーなら止める」などの制御を入れておくと安全です。

もう一つのポイントは、「どこを基準に動いているか」です。

バッチは実行した場所によって相対パスの解釈が変わるため、同じ内容でも実行方法が違うだけで動かなくなるケースがあります。

よくある用途例（安全な例中心）

まずは「確認して保存する」系の用途が扱いやすいです。

たとえば、ipconfig の結果をテキストに保存したり、特定フォルダの一覧を出力して記録したりできます。

複数のコマンドを決まった順番で実行するだけでも、手順漏れを防ぐ効果があります。

逆に、削除や上書きが絡む用途は、慣れるまでは避けるか、テスト環境で十分に検証してから使うのがおすすめです。

作成前の準備（つまずき回避）

バッチは「作ること」より「作ったつもりで動かない」事故が多いので、最初に環境面を整えます。

原因がコードの中身ではなく、保存の仕方や実行の仕方にあると、初心者ほど「何が悪いのか分からない」状態になりがちです。

最初にここを押さえておけば、後でつまずいても切り分けが早くなります。

とくに拡張子と文字コードは、初心者のつまずきポイントになりやすいです。

ここが安定すると「動かない」系のトラブルが一気に減ります。

必要なツール（メモ帳/VS Code）

最小構成なら、Windows標準のメモ帳だけで作れます。

まずはメモ帳で「保存→実行→結果確認」の流れを覚えるだけでも十分です。

ただし、行番号表示や文字コードの指定がしやすいエディタ（例：VS Code）を使うと、原因切り分けが楽になります。

エラーの行を特定しやすくなり、保存形式も明示できるため、文字化けや謎の挙動に悩まされにくくなります。

普段から使い慣れているエディタがあるなら、それを使うのが一番です。

拡張子の表示設定（.txt問題を防ぐ）

バッチでよくある事故は「batだと思ったら実は txt だった」というものです。

見た目は同じでも、Windowsは拡張子でファイルの種類を判断するため、拡張子が違うと実行できません。

エクスプローラーで拡張子を表示する設定にしておくと、ファイル名の末尾が正しいかを目で確認できます。

保存時に「ファイル名：sample.bat」と付けても、実体が「sample.bat.txt」になるケースがあるので注意します。

特に、メモ帳で保存するときに「ファイルの種類」が「テキスト文書」になっていると起きやすいので、拡張子を見て確認する癖を付けると安心です。

文字コード（保存形式）とコードページ（表示/実行）の違い

文字コードは「ファイルをどう保存するか」という話です。

コードページは「コマンドプロンプトが文字をどう表示・解釈するか」という実行環境側の話です。

この2つが合っていないと、日本語が文字化けしたり、意図しない記号に見えたりします。

また、文字化けは「日本語コメントが崩れる」だけでなく「日本語のフォルダ名を扱ったときに失敗する」など、動作そのものに影響することもあります。

そのため、初心者のうちは「保存形式は何か」「どの画面（cmd/別の端末）で実行しているか」をセットで意識しておくと、トラブルが起きても原因に当たりを付けやすくなります。

事前確認：セキュリティ警告/ブロックの意味

ダウンロードした .bat には、Windowsが警告を出すことがあります。

それは「未知のファイルが実行される」ことを防ぐ仕組みなので、警告が出たら内容を確認できない限り実行しない判断が安全です。

自分で作ったファイルでも、共有フォルダ経由で配布すると警告が出る場合があるため、運用ルールを決めておくと混乱が減ります。

たとえば「配布元はここ」「実行前に中身を確認する」「ログが出る場所を統一する」など、最低限の取り決めがあるだけで、チーム内の不安や問い合わせが減りやすくなります。

バッチファイルの作り方（最短で1本完成）

ここでは、まず「動くバッチ」を1本作って、成功体験を作ります。

最初から万能な自動化を目指すと、どこで失敗しているか分からなくなりがちです。

まずは「実行できた」「結果が残った」を最優先にして、段階的に育てていきます。

動いたあとに、ログ出力やエラー時停止など、実用に寄せる要素を足していきます。

手順：新規作成→.batで保存→配置→実行（全体像）

手順は「テキストを書く」「拡張子を .bat で保存する」「実行する」の3段階です。

ここで大事なのは、作業をシンプルに固定することです。

たとえば「最初は同じフォルダに置く」「出力先も同じ場所にする」など、変数を減らすと原因切り分けが楽になります。

実行できないときは、ほとんどが「拡張子」「保存場所」「権限」「パスの書き方」のどれかに原因があります。

一度つまずいたら、まずは「本当に .bat になっているか」「自分が今どこで実行しているか」「出力先はどこに指定しているか」を順番に確認するだけで、解決までの近道になります。

サンプル：ipconfig結果をログに保存する

例として、ネットワーク情報を確認する ipconfig の結果を、日時付きファイルとして保存します。

作業の流れをつかむのが目的なので、最初は複雑なことをせず、結果が残る形にします。

たとえば「ipconfig の結果を output.txt に保存する」だけでも、実行→成果確認→再実行のサイクルが作れます。

結果がファイルとして残るので、画面が閉じてしまっても確認できるのが利点です。

次に、保存先を自分で決められるように、出力先フォルダ（例：ログ用フォルダ）を作ってから保存するのが現場向きです。

さらに一歩進めるなら、ログ用フォルダが無い場合は作る、すでにある場合はそのまま使う、という形にしておくと、実行者が準備で迷いにくくなります。

画面表示/ログ出力（echo とリダイレクト）

実行中に何をしているか見えないと、不安になって止めてしまいがちです。

そのため、最初は「いま何をするか」を画面に表示し、同時にログとしてファイルにも残す設計が扱いやすいです。

画面表示は「状況を知るため」、ログは「後で調べるため」と役割が違います。

両方を用意しておくと、実行中の確認と、実行後の振り返りがスムーズになります。

コマンドの結果をファイルに保存する場合は、出力先を間違えると「動いたけどどこにもない」ように見えるので、保存先は固定し、ファイル名も分かりやすくしておきます。

特に、同じファイル名で上書きしてしまうと、前回の結果が消えて比較できなくなります。

日時付きにする、連番にするなど、履歴が残る形にしておくと、トラブル時の情報が増えて助かります。

ログは「いつ」「どのPCで」「何をしたか」が追えるとトラブル調査が楽になるため、日時やPC名を含める考え方が役に立ちます。

パス指定の基本（相対/絶対/引用符）

パスは、ファイルやフォルダの場所を表す文字列です。

相対パスは「バッチを実行した場所」を基準にするため、実行方法が変わると参照先が変わることがあります。

たとえば、同じバッチでも、ダブルクリックと cmd 実行、ショートカット経由では「基準の場所」が違ってしまうケースがあります。

慣れるまでは、意図した基準で動いているかを意識し、必要なら基準を固定する工夫をします。

絶対パスは場所が固定されるため分かりやすい反面、PCごとにユーザー名やドライブが違うと動かないことがあります。

そのため、チーム配布を考えるなら、ユーザーフォルダ配下など、環境差が少ない場所を選ぶか、ショートカット側で条件を揃えるなどの運用でカバーします。

空白を含むフォルダ名（例：Program Files）を扱うときは、引用符で囲むのが基本です。

日本語フォルダ名も同様に、引用符で囲む習慣を付けておくと、後で混乱しにくくなります。

失敗に強くする最小のエラー処理（errorlevel/終了コード）

バッチは、成功したか失敗したかを終了コードで返すコマンドが多いです。

エラーが起きたときに次の処理を続けると、さらに別のエラーが連鎖して原因が見えにくくなります。

まずは「失敗したら止める」「失敗したらメッセージを出す」という最小の方針を入れるだけで、運用の安全性が上がります。

慣れてきたら、どの処理で失敗したのかが分かるように、失敗時のメッセージに処理名や対象（ファイル名・フォルダ名）を含めると、問い合わせや調査の時間を短縮できます。

実行方法（迷わない3ルート）

バッチは実行方法によって、作業ディレクトリや権限が変わることがあります。

同じ .bat でも「どこから起動したか」で、相対パスの基準が変わったり、参照先がズレたりします。

また、実行ルートによっては警告が出やすかったり、出力が見えにくかったりするため、最初に「いつもこの方法で実行する」を決めておくとトラブルが減ります。

ここでは「どれで実行するか」を固定できるように、代表的な3ルートを整理します。

ダブルクリック vs コマンドプロンプト（cmd）実行

ダブルクリック実行は手軽ですが、失敗するとウィンドウが一瞬で閉じて、何が起きたか分からないことがあります。

特に、エラーが発生した行や原因が表示されたとしても、閉じてしまうと読み取れないのが弱点です。

一方、コマンドプロンプト（cmd）から実行すると、出力が残るため、エラーメッセージを読んで原因を追いやすいです。

さらに、cmd から実行すると「どのフォルダを基準にしているか」を意識しやすく、相対パスが原因のミスに気づきやすくなります。

慣れるまでは、基本的に cmd から起動して、結果が見える状態で試すのがおすすめです。

動作が安定してから、ダブルクリックやショートカットに移行すると安全です。

管理者権限での実行（必要な時だけ）

「アクセスが拒否されました」と出る場合、権限不足の可能性があります。

ただし、何でも管理者で実行すると、間違えたときの影響が大きくなるため、必要な場面だけに絞るのが安全です。

管理者実行が必要かどうかは、操作対象がシステム領域か、共有フォルダか、インストール先かなどで変わります。

また、管理者権限が必要な操作と、不要な操作が混ざっていると「とりあえず管理者で実行」が常態化しやすくなります。

可能なら、管理者が必要な処理だけ別バッチに分けるなど、権限を最小にする設計を意識すると事故が減ります。

ショートカットで簡単実行（配布・運用）

運用で便利なのは、ショートカットを作って「作業ディレクトリ」や「引数」を固定する方法です。

ショートカットにしておくと、ダブルクリックでも実行条件を一定にしやすく、手順書として配りやすくなります。

特に、相対パスを使うバッチでは、ショートカット側で作業ディレクトリを固定できると、環境差による失敗が減ります。

ただし、配布する場合は「中身を確認できる人が管理する」「改ざんされない場所で配る」などのルールが重要です。

あわせて、配布先が複数になる場合は、どれが最新版か分かるように管理方法（置き場所・命名・更新手順）を決めておくと混乱しにくくなります。

便利テクニック（基礎中心）

ここでは、バッチを「読みやすく」「保守しやすく」するための基本テクニックに絞って紹介します。

初心者のうちは、書ける文法を増やすよりも「人が読んで安全に直せる形」に寄せたほうが、結果的にミスが減ります。

複雑な文法を増やすより、まずは見通しを良くして、トラブルの原因を追いやすい方向に寄せます。

@echo off と echo の使い分け

バッチは、実行したコマンド自体が画面に表示されるため、初心者ほど画面がノイズで埋まりがちです。

表示を整理するために、最初にコマンド表示を抑え、必要なメッセージだけ表示する設計にすると読みやすくなります。

実行中は「何をしているか」を短いメッセージで区切っておくと、途中で止まったときに、どの段階で失敗したかが分かりやすくなります。

また、表示メッセージは長文にせず、処理の単位（例：準備→実行→後片付け）ごとに揃えると、ログや画面を見返すときに追いやすくなります。

チームで共有する場合は、表示文言の言い回しもなるべく統一しておくと混乱が減ります。

コメント（REM/::）の使い分け（内部向け/実行者向け）

コメントは、バッチが実行するときには無視される説明文です。

内部向けコメントは、なぜその処理をしているか、どこを変更すると影響が出るか、という背景を書くと役に立ちます。

特に、パスや対象フォルダなど「人によって変えたくなる場所」は、どこを触ればよいかが分かるように書いておくと保守が楽です。

実行者向けコメントは、使い方や注意点を「最初に読む場所」にまとめる意識を持つと、問い合わせが減ります。

たとえば、実行前に閉じるべきアプリ、出力先、想定している権限、ログの場所などを先頭に集約しておくと、初見でも安心して実行できます。

変数（set）と引数（%1 %2）入門

同じバッチを何回も使うなら、固定文字列を並べるより、変数にしてまとめたほうが変更に強くなります。

たとえば保存先フォルダやログ名のプレフィックスなどは、先頭に集めておくと、後で読み返したときに意図が分かりやすいです。

「どこを変えれば動作が変わるか」が明確になると、作業者が不用意に本文をいじらずに済み、事故が減ります。

設定値はコメントとセットで書いておくと、さらに親切です。

引数は「実行するときに値を渡す」仕組みで、同じバッチを別のフォルダに対して使い回すときに役立ちます。

まずは「引数が無いときはエラーにする」「引数があるときだけ処理する」という最小の使い方から始めると安全です。

加えて、引数で受け取ったパスは引用符で囲む前提で扱う、などのルールを決めておくと、空白を含むパスでも崩れにくくなります。

条件分岐 IF（存在確認だけ先に）

初心者が最初に覚えると効果が大きいのは、ファイルやフォルダの存在確認です。

存在しないファイルをコピーしようとして失敗すると、そこで止まらずに次の処理に進み、さらに別のエラーが出ることがあります。

そのため「対象が存在するか確認する」「無ければメッセージを出して終了する」という形を先に作っておくと、トラブル対応が楽になります。

存在確認は、削除や上書きのような危険操作の前にも有効です。

対象が想定と違う場所を指していないかを確認してから進むだけで、取り返しの付かない事故を避けやすくなります。

文字化け・日本語・パスの落とし穴

日本語環境では、文字化けとパスの扱いがセットで問題になりやすいです。

特に、バッチのメッセージ表示・ログ出力・ファイル名やフォルダ名の指定が絡むと、一見同じ症状に見えても原因が複数あります。

原因を分けて考えるだけで、対処がかなり楽になります。

文字化けの原因（保存形式/コードページ/フォント）

文字化けは「ファイルの保存形式」と「表示する側の設定」が噛み合っていないときに起きます。

たとえば、保存がUTF-8でも、表示側が別のコードページで解釈すると、記号や文字が崩れて見えます。

また、同じ文字コードでも「画面表示だけが崩れる」「ログだけが崩れる」「日本語のファイル名を扱うときだけ失敗する」など、出方が分かれることがあります。

どこで文字が崩れているのか（画面なのか、出力ファイルなのか、パスの扱いなのか）を先に切り分けると、修正の方向性が明確になります。

フォントによっては見え方が変わることもあるため、最初は「保存形式」「実行環境」「表示」の3点を疑うのが切り分けのコツです。

エディタ側の設定で保存形式が変わっていないか、いつもと違う端末（PowerShellやWindows Terminal）で実行していないかも、合わせて確認します。

chcp の扱いとログの日本語対策

コマンドプロンプトでは、コードページを切り替える設定があり、これが表示に影響します。

ただし、コードページを変えると別の文字が表示できなくなることもあるため、場当たりで切り替えるのではなく、ログの出し方も含めて考えるのが安全です。

実務では、画面表示に日本語が必要なのか、ログファイルに日本語が必要なのかで最適解が変わります。

目的を先に決めてから調整すると、設定がぶれにくくなります。

また、チームで共有するバッチの場合、実行者の環境が一定とは限りません。

画面表示に頼り切らず、ログを残して後から追えるようにしておくと、文字化けが起きたときでも状況が把握しやすくなります。

日本語パス/空白/全角の安全策（引用符ルール）

パスのトラブルで多いのは、空白を含むフォルダ名が途中で切れて解釈されるケースです。

この問題は、パスを引用符で囲むルールを徹底するだけで、かなり防げます。

コマンドの引数としてパスを渡す場所はすべて同じ考え方で、引用符の付け忘れをなくすのがコツです。

日本語パスも同様に、引用符で囲んで「1つの塊」として扱う意識を持つと、意図しない分割が減ります。

さらに、実行方法によって基準となる場所が変わると、相対パスが別の場所を指してしまい、結果として「見つからない」や「文字化けしているように見える」状態になることがあります。

慣れるまでは、出力先や参照先を固定し、ログに「どこを対象にしたか」を残すと、原因が追いやすくなります。

注意点（セキュリティ/配布/運用）

バッチは便利な反面、実行するとPC上で実際の操作（コピー・削除・上書き・送信など）が行われるため、扱い方を間違えると被害が大きくなります。

特に「自動で実行される」という性質上、人の目による最終確認を挟まずに処理が進む点がリスクになります。

ここでは「やらないほうがいい運用」と「最低限の守り方」を、具体例とあわせて整理します。

セキュリティリスク（改ざん/なりすまし/共有）＋具体例

バッチはテキストなので、特別なツールがなくても誰でも内容を書き換えられます。

そのため、意図せず内容が変更されたり、悪意のあるコードが追記されたりしても、見た目だけでは気づきにくいという特徴があります。

たとえば、見た目は同じファイル名でも、内容が「削除」や「外部への送信」に変えられていると、実行した瞬間に被害が起きます。

メールやチャットで受け取った .bat をそのまま実行するのは危険です。

必ず中身をテキストとして開き、「何をしているか」を確認してから実行する習慣を付けます。

共有する場合は、配布元を固定し、保管場所のアクセス権を制御し、最新版の管理者を決めることが基本です。

さらに、更新履歴を簡単にでも記録しておくと、「いつ・誰が・何を変えたか」が追えるため、トラブル時の切り分けが容易になります。

配布・共有時のチェックリスト（署名は不要でも確認は必須）

配布するときは、実行者が中身を確認できるかどうかを基準にします。

実行者が確認できない場合は、少なくとも「何をするバッチか」「対象はどこか」「失敗時にどう止まるか」「ログはどこに出るか」を説明できる状態にします。

可能であれば、以下のような簡易チェックリストを用意します。

• 削除や上書き処理は含まれていないか
• 管理者権限が本当に必要か
• テスト環境で事前に動作確認しているか
• ログ出力が有効になっているか

運用で混乱しやすいのは、複数のコピーが出回り、どれが正しいか分からなくなる状態です。

そのため、配布ルートはシンプルにし、「公式の保存場所」を1か所に決めておくと安全です。

古いバージョンを誤って実行しないよう、ファイル名に日付やバージョン番号を付けるのも有効です。

“危険な操作”を入れる前の確認（削除/上書き/ネットワーク）

削除や上書きは、テストが不十分だと取り返しが付かない事故になりやすいです。

特にワイルドカード（例：*.txt など）を使う場合、想定より広い範囲が対象になることがあるため、事前確認が重要です。

最初は「削除する代わりに別フォルダへ退避する」「上書きする前にバックアップを取る」など、戻せる設計にしておくと安全です。

また、本番用フォルダに対していきなり実行するのではなく、テスト用フォルダを作って同じ構成で試すと、被害を防げます。

ネットワーク共有を扱う場合は、遅延やアクセス権、切断などで失敗しやすいので、想定どおりに動かない前提でログを残すとトラブル対応がしやすくなります。

さらに、ネットワーク先が利用できない場合は処理を中断する、といった安全側の分岐を入れておくと、二次被害を防ぎやすくなります。

よくある質問（FAQ）

最後に、初心者が検索しやすい「詰まり所」をQ&A形式でまとめます。

ポイントは、いきなり直そうとするのではなく「症状→原因候補→確認手順」を順番に潰すことです。

当てはまるものから確認すると、遠回りせずに解決しやすくなります。

ダブルクリックで一瞬で閉じる（見方/止め方）

ダブルクリックで一瞬で閉じる場合、エラーが出た瞬間にウィンドウが閉じている可能性があります。

まずは、コマンドプロンプト（cmd）を開き、そこからバッチを実行して、表示されるメッセージを確認します。

エラーが出る行が分かれば、修正の当たりを付けやすくなります。

それでも追いにくい場合は、処理の区切りごとに「いま何をしているか」を表示して、止まる場所を特定します。

さらに、最後に pause を入れておくと、エラーが出ても画面が閉じず、内容を読めます。

運用前提なら、ログ出力（ファイル保存）を入れておくと、閉じても結果が残るので安心です。

ログには「いつ実行したか」「どこに出力したか」を残せると、後から追いやすくなります。

「ファイルが見つからない」「パスに空白がある」

「見つからない」は、参照している場所が違うか、ファイル名が違うか、権限で見えないかのどれかです。

相対パスを使っている場合、実行した場所が変わるだけで参照先が変わるため、まずは「どこを基準にしているか」を疑います。

ショートカット経由や別フォルダから起動すると、基準がズレて想定外の場所を見に行くことがあります。

切り分けとしては、実行中の場所（作業ディレクトリ）を表示して確認すると早いです。

どのフォルダを見ているかが分かれば、相対パスをやめて絶対パスにする、または作業ディレクトリを固定する、といった対策が取りやすくなります。

空白を含むパスは、引用符で囲むのが基本なので、まず引用符の有無を確認します。

特に、コピー先やログ出力先が「Program Files」配下や「OneDrive – 〜」配下になると、空白が含まれやすいので注意します。

日本語が文字化けする

まずは、バッチファイル自体の保存形式（文字コード）を確認します。

保存形式が変わると、同じ見た目でも中身の解釈が変わり、結果として文字化けにつながります。

次に、実行しているコマンドプロンプト側の表示設定（コードページ）が、意図した表示に合っているかを確認します。

ここが噛み合っていないと、画面表示だけが崩れたり、ログだけが崩れたりします。

画面表示が不要で、ログだけ読めればよい場合は、ログ側の文字コードを揃える方向で設計すると安定しやすいです。

逆に画面で日本語を見たいなら、画面表示とログ出力で「どちらを優先するか」を決めて、ぶれないようにします。

「アクセスが拒否されました」対処

対象のフォルダやファイルに対して、実行しているユーザーに権限が無いと起きます。

システム領域や他ユーザーの領域、共有フォルダなどでは権限が不足しやすいので、まずは保存場所と対象場所を見直します。

たとえば、出力先を自分のユーザーフォルダ配下に変更するだけで解決することもあります。

また、対象ファイルが別のアプリで開かれていてロックされている場合も、似たエラーになります。

コピーや上書きをする処理があるなら、先に対象を閉じる、別名で出力してから置き換える、といった運用で回避できます。

管理者権限での実行は手段の一つですが、必要性を確認してから使い、常用しない運用にすると安全です。

管理者でしか動かない前提にすると、誤操作時の影響も大きくなるため、できるだけ「権限を上げなくても動く設計」を優先します。