【お急ぎの方へ：この記事の結論】
- ✅ 今すぐ確認したい：メモ帳の右下を見るだけ！「CRLF」か「LF」か一発で分かります（確認方法へジャンプ）。
- ✅ 変換して保存したい：メモ帳は変換が苦手。VS Codeを使うのがプロの正解です（推奨ツールへジャンプ）。
- ✅ なぜエラーが出るの？：WindowsとLinuxの「改行のルール」が違うからです（歴史的背景へジャンプ）。
- ✅ チーム開発で事故らない：Gitの設定「autocrlf」と「EditorConfig」で自動化しましょう（Git設定へジャンプ）。
※この記事では、プログラミング初心者の方でも迷わないよう、図解レベルの細かさで徹底解説しています。歴史的背景から最新の自動化テクニックまで、目次から気になるところへ飛んでくださいね！
「あれ…？Windowsで作ったプログラムをサーバーに上げたら、一行目でエラーが出て動かない！？」
「Gitでコミットしようとしたら、何も変えてないはずなのに『全行変更』扱いになっちゃった！？」
「Dockerコンテナを立ち上げようとしたら、『exec format error』なんていう見たこともないエラーで落ちる…！」
開発作業中に突然、原因不明のエラーに襲われて、ログを見ても意味不明な記号ばかり…。 納期は迫っているのに、コードを見直してもロジックは完璧。
「なんで！？コードは合ってるはずなのに！」って、モニターに向かって叫びたくなりますよね。
もしかして、徹夜で書いたコードが動かない原因がわからず、焦りながら「windows11 メモ帳 改行コード 変更」「linux スクリプト 動かない windows」なんて検索して、このページに救いを求めて来てくれたんじゃないでしょうか。
「ただテキストを書いただけなのに！」って、PCを問い詰めたくなりますよね。
その「見えないエラー」の原因、実はあなたが書いたコードの内容ではなく、目に見えない「改行コード」という名の幽霊の仕業かもしれません…！😥
わかります、すごーくわかります！
私もエンジニアになりたての頃、Linuxサーバーの設定ファイルをWindowsのメモ帳で編集して、本番サーバーを起動不能にした時のあの冷や汗、今でも忘れられません。あの日、上司に言われた「お前、CRLF混ぜただろ？」という言葉の意味が分からず、トイレで泣きそうになったのを覚えています（笑）。
「コードは正しいのに動かない」「謎の記号『^M』って何？」「git warning: LF will be replaced by CRLF って何！？」なんて、パニックになっちゃいますよね。
でも、大丈夫です！
その焦る気持ち、よーくわかります。でも、あなたのプログラムが間違っているわけじゃありません！
この問題、実はOSごとの「改行のルール」の違いによるもので、Windows 11の進化したメモ帳を使えば、ちゃんと正体を見破ることができるんです。
この記事は、そんな「改行コードの罠」にハマってしまったあなたを救うための、プロ直伝の解決策を網羅した「完全バイブル」です🕵️♀️
Windows 11のメモ帳を使った簡単な確認方法から、なぜそんな違いが生まれたのかという歴史ロマン、そしてプロが現場で使っている「二度と事故らないためのGit設定や自動化テクニック」まで。
文字数は非常に多いですが、私と一緒に、一つずつ順番に確認して、あの厄介なエラーを根絶やしにしましょうね！🥰
第1章：改行コードとは？タイプライターから始まる歴史の旅
具体的な操作に入る前に、「そもそもなんでこんなエラーが起きるの？」っていう原因の全体像を、ざっくり知っておきましょう。 ここを理解していると、今後どんな新しいツールやOSに出会っても、応用が効くようになります。
敵（改行コードの仕様）を知れば、無駄なトラブルを回避して、開発効率が爆上がりしますからね！
1-1. 「改行」に含まれる2つの動作
私たちが普段、Wordやチャットツールで何気なく押している「Enter」キー。 画面上では「次の行の左端に移動する」という一つの動作に見えますが、コンピューターの祖先である「タイプライター」や「テレタイプ端末（TTY）」の時代、これは機械的に全く別の2つの動作の組み合わせでした。
- CR（Carriage Return / 復帰）：印字ヘッド（キャリッジ）を、紙の右端から「左端（行頭）」に戻す動作。
- LF（Line Feed / 改行）：紙送りのローラーを回して、紙を「次の行（下）」へ送る動作。
想像してみてください。 タイプライターで文字を打っていて、右端まで行きました。 そこで、
ガチャン！とレバーを引いてヘッドを左に戻す（これがCR）。
クルッとダイヤルを回して紙を少し上げる（これがLF）。
この2つの動作をして初めて、「次の行の書き出し位置」にセットされるわけです。
1-2. OS戦争：なぜWindowsとUnixで道が分かれたのか？
コンピューターが普及し始めた頃、メモリやストレージは非常に高価でした。 1バイト（文字1つ分）のデータでさえ、節約したい時代です。
ここで、OS（オペレーティングシステム）の設計者たちの意見が分かれました。
- 💻 Windows（MS-DOS）の言い分：
- 「タイプライターの挙動を忠実にシミュレートすべきだ。プリンターに出力した時に、CRがないと行頭に戻らず、階段状に印字されてしまうじゃないか！だから、改行は『CR』と『LF』の2文字（2バイト）セットにするぞ！」
（表記：CRLF /
\r\n/ 0x0D 0x0A） - 🐧 Unix（後のLinux/macOS）の言い分：
- 「いやいや、2文字も使うのは無駄だろ。メモリがもったいない！『LF』だけで『次の行に行く』って意味にすればいい。行頭に戻る動作なんて、ソフトウェア側で勝手に補完してくれればいいんだ！」
（表記：LF /
\n/ 0x0A） - 🍎 旧Mac OS（OS 9以前）の言い分：
- 「我々は『CR』だけで改行を表すことにする！」
（表記：CR /
\r/ 0x0D）※現在のmacOS（OS X以降）はUnixベースになったので、Linuxと同じLFになっています。
こうして、現代まで続く「改行コードの互換性問題」が誕生してしまったのです。
Windows（CRLF）で保存したファイルを、Linux（LF）のサーバーに持って行くと… Linux側は「なんだこの『CR（\r）』って余計なゴミは！？そんなコマンド知らないぞ！」と怒ってエラーを吐き出すわけです。
これが「スクリプトが動かない」原因の正体であり、多くのエンジニアを苦しめる「^M（CRの制御文字表記）」の正体なのです😱
【表1：OSおよび環境ごとの改行コード比較】
| 環境・OS | 改行コード名 | 表記 | 主な特徴・注意点 |
|---|---|---|---|
| Windows | CRLF | \r\n |
メモ帳、Excel、PowerShellの標準。Linuxへ持っていくとエラーの元凶になる！ |
| macOS / Linux | LF | \n |
Webサーバー、Docker、Gitの標準。開発者は基本的にこっちに合わせるべき。 |
| Mac OS (旧) | CR | \r |
Mac OS 9以前。今はほぼ絶滅種ですが、古いデータには残っているかも。 |
基礎知識はこれでバッチリですね！ それでは、この歴史的な背景を踏まえた上で、進化したWindows 11のメモ帳を使って、この厄介者を退治していきましょう！💪
第2章：Windows 11「メモ帳」の驚異的な進化
「え、メモ帳？あんな機能の少ないアプリで大丈夫？」 「開発ならVS Code使えばよくない？」
そう思ったあなた。今のメモ帳を侮ってはいけません！ Windows 11になって、メモ帳（Notepad）は単なるテキストエディタではなく、モダンなアプリへと生まれ変わりました。
かつては「開発者の敵」とまで呼ばれたメモ帳が、どのように我々の味方になったのか。その進化ポイントを見ていきましょう。
2-1. 以前のメモ帳との決定的な違い（豆腐化現象の解消）
Windows 10までの古いメモ帳（特に初期のバージョン）には、致命的な欠点がありました。 Linux形式（LF）のファイルを開くと、改行コードを認識できず、「すべての文章が一行に繋がって表示される」という現象です。改行があるべき場所には、黒い四角形（■）が表示されることもありました。
あれ、本当に絶望しますよね…。「バグだ！」なんて言われてましたが、実は「CRLF以外は改行と認めない！」という頑固な仕様（RichEditコントロールの古い仕様）だったんです。
でも、Windows 11のメモ帳は違います！ 内部エンジンが刷新され、LFのみのファイルでも、賢く「あ、ここで改行ね」と読み取って、綺麗に表示してくれるようになりました✨
2-2. ステータスバーの可視化機能
Windows 11のメモ帳で一番注目してほしいのが、ウィンドウの一番下にある「ステータスバー」です。
ここには、以下の情報がリアルタイムで表示されます。
- カーソルの位置（行数、列数）
- ズーム倍率
- 文字コード（UTF-8, ANSIなど）
- 改行コード（Windows (CRLF) / Unix (LF)）
以前は「フリーソフトを使わないと分からない」と言われていた情報が、標準機能だけで確認できるようになったのです。 もし「そんなバー出てないよ？」という方は、メニューの「表示」をクリックして、「ステータスバー」にチェックを入れてください。ここが今回の作戦本部になります！👮♀️
2-3. タブ機能と自動保存
これまでは複数のファイルを開くと、ウィンドウがデスクトップ中に散らばって大変でしたよね。 最新のメモ帳には、Webブラウザのような「タブ機能」が追加されました！
これを使えば、タブ1で「Linux用の設定ファイル（LF）」を開き、タブ2で「Windows用のマニュアル（CRLF）」を開いて、タブを切り替えながら右下のステータスバーが「LF」→「CRLF」と切り替わるのを確認する…なんてことも簡単にできます。
さらに、保存していない内容も記憶してくれる「セッション復元機能」まで付きました。 うっかり保存せずに閉じても、次回開いたときに内容が残っているんです。これは地味に神機能ですよね！
第3章：実践！Windows 11「メモ帳」で改行コードを確認する方法
それでは、実際に手元のファイルが「安全（LF）」なのか「危険（CRLF）」なのか、確認してみましょう。 手順は驚くほどシンプルですが、この確認をするかしないかで、後のトラブル率が天と地ほど変わります！
手順1：メモ帳でファイルを開く
まず、確認したいテキストファイル（.txt, .html, .php, .py, .sh, .yml など）を、Windows 11のメモ帳で開きます。
ファイルを右クリックして、「プログラムから開く」＞「メモ帳」を選べばOKです！ （※常にメモ帳で開くように設定してしまうと、うっかり編集して壊すリスクがあるので、「プログラムから開く」を使うのがコツです）
手順2：ウィンドウ右下を確認する
メモ帳が開いたら、視線を右下の隅っこに向けてください。
そこに、小さく「Windows (CRLF)」または「Unix (LF)」と書いてありませんか？
これが、そのファイルの「正体」です！
手順3：表示の意味を読み解く（シーン別判定）
表示された内容が良いのか悪いのかは、そのファイルを「何に使うか」によって変わります。
🛑 表示が「Windows (CRLF)」の場合
- OKなケース：自分用のメモ、Windows上で動かすバッチファイル（.bat）、Windowsアプリの設定ファイル。
- NGなケース：Linuxサーバーに上げるファイル、DockerのDockerfile、シェルスクリプト（.sh）、Webサイトのコード（HTML/CSS/JS）、Pythonなどのプログラムコード（チーム開発の場合）。
✅ 表示が「Unix (LF)」の場合
- OKなケース：Web開発全般、Gitで管理するコード、Mac/Linuxユーザーと共有するファイル。
- NGなケース：Windowsの非常に古い業務用アプリに取り込むCSVデータ（CRLFしか受け付けないレガシーシステムがあるため）。
たったこれだけの確認ですが、これで「なんで動かないのー！？」という時間の浪費を9割防げます。
第4章：Windows 11「メモ帳」の限界と、改行コードの変更方法
ここからが本題です。「確認したらCRLFになってた！Linux用にLFに変えたい！」という場合ですよね。
正直にお伝えしますね。 Windows 11のメモ帳は、確認（表示）に関しては優秀になりましたが、「変換（保存）」に関しては、まだちょっとポンコツ（発展途上）です😅
「名前を付けて保存」のダイアログを見ても、「改行コードを選ぶプルダウンメニュー」がないんですよね…。 文字コード（UTF-8 / ANSI）は選べるのに、改行コードだけ選べないんです。
でも、諦めるのはまだ早いです！ ちょっとした工夫（裏技）でコントロールする方法と、素直に使うべきツールをお教えします。
方法A：【裏技】既存のLFファイルを流用する
メモ帳には「開いたファイルの改行コードを維持して保存する」という特性があります。
つまり、
すでに「LF」になっている空のファイル（テンプレート）を用意する。
それをメモ帳で開く。
中身を書き込んで「上書き保存」する。
こうすれば、Windowsのメモ帳でも「LF」のファイルを作成・編集し続けることができます。 少しアナログですが、会社の方針で「勝手にソフトをインストールしてはいけない」という環境では、これが唯一の解決策になることもあります💦
方法B：【非推奨】混在させて保存する？
メモ帳でLFのファイルを開き、一部を修正して保存すると、基本的にはLFが維持されます。 しかし、別の場所からCRLFのテキストをコピー＆ペーストした瞬間に、ファイルの中にLFとCRLFが混在する「キメラ状態」になることがあります。
メモ帳はこれを良しなに保存してくれることもあれば、次回開いたときに勝手にCRLFに統一してしまうこともあります。 この挙動はバージョンによっても微妙に異なるため、「メモ帳でコードをガッツリ編集する」のは避けたほうが無難です。
第5章：メモ帳以外の選択肢：プロが使う確実な変換ツール
「裏技とか怖いし、もっと確実な方法ないの？」 あります！というか、業務レベルでは絶対にこっちを使ってください！
プロのエンジニアは、改行コードを「意識しなくても勝手に揃う」ようにツールを設定しています。 これらを使えば、事故率はほぼゼロになりますよ！
5-1. Visual Studio Code (VS Code) を使う【超推奨！】
現代の開発者なら、ほぼ全員が入れていると言っても過言ではない「VS Code」。Microsoftが作った最強のエディタです。 （メモ帳と同じMicrosoft製ですが、機能差は自転車とジェット機くらいあります笑）
▼変換の手順
ファイルを開く。
ウィンドウの右下のステータスバーにある「CRLF」という文字をクリックする。
画面上にメニューが出るので「LF」を選ぶ。
保存する（Ctrl + S）。
たったこれだけ！2秒で終わります。 視覚的にも分かりやすいし、間違いようがないので、一番のオススメです✨
さらに、設定で「新規ファイルは常にLFで作る」と決めておくこともできます。 （設定画面で files.eol を検索し、\n に設定するだけです！）
5-2. サクラエディタやNotepad++を使う
日本で昔から愛されている「サクラエディタ」や、海外で人気の「Notepad++」も優秀です。
これらのエディタの良いところは、「名前を付けて保存」の画面に明確に「改行コード：LF (UNIX)」という選択肢があることです。 また、ファイルを開いた瞬間に「改行コードが混在しています！統一しますか？」と警告してくれる親切設計のものもあります。
5-3. WSL (Windows Subsystem for Linux) で一括変換【上級者向け】
「黒い画面（ターミナル）？任せとけ！」というカッコいいあなたは、コマンド一発で解決です。 WSL（Linux）上の dos2unix コマンドを使えば、フォルダ内の大量のファイルも一瞬で変換できます。
1つのファイルを変換
dos2unix script.sh
カレントディレクトリの全ファイルを一括変換
find . -type f -print0 | xargs -0 dos2unix
まるで魔法の呪文のようですが、これでCRLFという悪霊がLFに浄化されます。 逆にWindows用にしたいときは unix2dos コマンドを使います。
5-4. PowerShellを使う（ソフト不要）
「会社のPCだからWSLもVS Codeも入れられない…」という縛りプレイ中のあなたへ。 Windows標準のPowerShellでも変換は可能です。
input.txt を読み込んで LF に変換し output.txt に保存
(Get-Content input.txt -Raw).Replace(“rn”, “`n”) | Set-Content output.txt -NoNewline
ちょっとコマンドが長いですが、これをメモしておけば、どんな環境でも戦えます！
第6章：なぜ「LF」にしないといけないの？恐怖のトラブル事例集
「別にCRLFのままでも良くない？最近のLinuxは賢いって聞くし…」 と思ったあなた。その油断が、後でとんでもないトラブルを引き起こすかもしれません！
ここでは、実際に現場で頻発している「改行コード起因のトラブル」を具体的に紹介します。 これを読めば、「LFにしておかなきゃ…！」と背筋が凍るはずです。
【事故1】シェルスクリプトが動かない（Shebang問題）
Linuxを操作するためのスクリプト（.shファイル）を、Windowsのメモ帳で書いたとします。 1行目に #!/bin/bash と書きますよね？これを「Shebang（シバン）」と呼びます。
これがCRLF（\r\n）で保存されていると、Linuxカーネルは行末の \r （CR）を改行ではなく「文字の一部」として認識してしまいます。 つまり、#!/bin/bash ではなく、#!/bin/bash\r という名前のプログラムを探しに行ってしまうのです。
当然、Linux上には bash\r なんて変な名前のコマンドはありません。 結果、「No such file or directory（そんなファイルもディレクトリもないよ！）」と怒られます。
「えっ！？ファイルあるじゃん！ここにあるじゃん！」と叫んでも無駄です。 見えないCRが悪さをしているのですから…。これは初心者が一番泣かされる罠です😭
【事故2】Dockerコンテナが起動しない
最近の開発ではDockerを使うことが増えましたが、ここでも改行コードは牙を剥きます。
Dockerのエントリーポイント（起動時に実行するスクリプト）がCRLFになっていると、コンテナ起動時に exec format error や command not found で落ちてしまいます。 ローカル（Windows）では動くのに、CI/CDパイプラインや本番サーバー（Linux）にデプロイした瞬間だけ落ちる…。
この原因調査に丸3日費やした同僚を見たことがあります。原因はたった1バイトのCRでした。
【事故3】Gitの履歴が汚れる（差分地獄）
Gitでコード管理をしている時、中身（ロジック）は一行も変えていないのに、改行コードが変わっただけで「ファイル全体が書き換わった」と判定されることがあります。
これをそのままコミットすると、GitHub上の差分表示（Diff）が真っ赤になります。 レビュー担当者は「えっ、全行書き直したの！？」と驚き、実際には改行コードが変わっただけだと知って脱力します。
さらに、Windowsの人とMacの人が同じファイルを編集し合うと、「CRLFにするコミット」と「LFに戻すコミット」が交互に発生し、「改行コード戦争」が勃発します。 チームの雰囲気も悪くなるので、絶対に避けたいですね（笑）。
第7章：チーム開発の正解！GitとEditorConfigで自動化する
ここまで読んで、「毎回確認するのは面倒くさい！」と思いましたよね？ その通りです。人間はミスをする生き物。だからこそ、機械にやらせましょう。
チーム開発では、個人の心がけではなく「設定ファイル」で強制的に解決するのがプロの流儀です。
7-1. Gitの自動変換機能（core.autocrlf）
Gitには、OS間の改行コードの違いを吸収してくれる機能があります。 Windowsユーザーは、以下のコマンドを実行しておくのが「お作法」です。
▼設定の意味（推奨設定）
- true：（Windows推奨とされがちですが要注意）コミット時はLFに、チェックアウト（ダウンロード）時はCRLFに自動変換します。→ しかし、最近はDockerやWSLを使うため、Windows上でもLFのまま扱いたいケースが増えています。
- input：（今のオススメ！）コミット時はCRLFをLFに変換しますが、チェックアウト時は変換しません（LFのまま）。→ これならリポジトリの中は常にきれいなLFに保たれ、Windows上でもLFで作業できます。
- false：何もしません。改行コードはそのまま保存されます。→ 全員が意識高くLFを使えるならこれでも良いですが、事故のリスクはあります。
7-2. 最強の魔除け「.gitattributes」
個人の設定（git config）は、強制力がありません。新人が入ってくるたびに設定させるのも大変ですよね。 そこで、リポジトリのルートに .gitattributes というファイルを置いておきます。
全てのテキストファイルを強制的にLFに統一する
text=auto eol=lf
WindowsバッチファイルだけはCRLFを許可する
*.bat text eol=crlf *.cmd text eol=crlf
これを書いてコミットしておけば、誰がどのOSでどんなエディタを使おうが、Gitがコミットを受け取る瞬間に強制的にLFに変換してくれます。 まさに「最強の魔除け」。これさえあれば、もう改行コードで喧嘩することはありません！🛡️
7-3. EditorConfigでエディタの設定を統一
さらに、VS Codeなどのエディタの設定も統一しましょう。 .editorconfig というファイルを置くと、対応しているエディタが勝手に設定を読み込んでくれます。
root = true
[*] end_of_line = lf # ここで改行コードを指定！ charset = utf-8 # 文字コードもUTF-8に！ indent_style = space indent_size = 2
これを置いておけば、Windowsの人がVS Codeでファイルを開いた瞬間、右下の設定が自動的に「LF」に切り替わります。 「メモ帳派」の人には効きませんが、VS Codeを使っているメンバーには絶大な効果があります。
第8章：意外と知らない？「文字コード（BOM）」と改行コードの関係
改行コードの話をしてきましたが、もう一つ、兄弟のようなトラブルメーカーがいます。 それが「文字コード」と「BOM（ボム）」です。
Windows 11のメモ帳を使う上で、ここも避けては通れないポイントなので、最後に少しだけ解説します。
8-1. UTF-8 (BOM付き) の罠
以前のWindowsのメモ帳は、UTF-8で保存すると、ファイルの先頭に「BOM（Byte Order Mark）」という隠しデータを勝手にくっつけていました。 これは「このファイルはUTF-8だよ！」という名札のようなものですが、Linuxの世界ではこれが「余計なゴミデータ」として扱われます。
改行コードをせっかくLFにしたのに、BOMがついているせいで、PHPやPythonのプログラムが動かない…という悲劇もよくあります。
8-2. Windows 11 メモ帳の神対応
安心してください。Windows 11のメモ帳は、デフォルトの保存形式が「UTF-8（BOMなし）」に変更されました！🎉
これにより、メモ帳で保存したファイルがLinuxでトラブルを起こす確率は激減しました。 ただし、「名前を付けて保存」のダイアログで「UTF-8 (BOM付き)」をわざわざ選んでしまうと、また悪夢が始まります。 基本的にはデフォルトのままでOKです。
8-3. Shift-JIS (ANSI) の生き残り
逆に、日本の古い業務システム（銀行や役所のCSVデータなど）では、まだ「Shift-JIS（メモ帳ではANSIと表記）」が使われていることがあります。 これをうっかりUTF-8で保存してしまうと、今度は「文字化け」が発生します。
メモ帳の右下のステータスバーには「ANSI」や「UTF-8」といった情報も出ているので、改行コードと一緒にここもチラッと確認する癖をつけると、あなたは「ミスのない信頼できるエンジニア」になれますよ！👀
まとめ：改行コードを制する者は、開発を制す
ここまで、なんと1万文字近くにわたって「改行コード」について語り尽くしました。 最後までお読みいただき、本当に、本当にお疲れ様でした！🍵
たかが「改行」、されど「改行」。 目に見えないたった1バイトか2バイトの違いが、システム全体を停止させ、チームの人間関係までギスギスさせてしまう。 コンピューターの世界って、本当に繊細で面白いですよね（笑）。
最後に、今回の膨大な情報のポイントを、ギュッと凝縮しておさらいしましょう。
✅ 今日のまとめ：プロへの道チェックリスト
- 基本知識： WindowsはCRLF、Linux/MacはLF。Web/開発系はLFが世界標準！
- メモ帳の役割： Windows 11のメモ帳は「確認用（ビューア）」として超優秀。でも「変換用」としては力不足。
- ツールの活用： 確実な変換・保存には「VS Code」を使うのが現代の常識。
- 自動化の徹底： チーム開発では個人の注意に頼らず、.gitattributes や .editorconfig で強制的にLFに統一する。
- トラブル対応： 「動かない！」と思ったら、まずは右下のステータスバーを見る癖をつける。
これからあなたが、新しいプログラミング言語を学んだり、サーバーを構築したりする時、必ずどこかでこの「改行コード」の問題に直面するはずです。 その時、パニックにならずに、「ああ、CRLFが悪さしてるんでしょ？知ってる知ってる」と余裕の笑みを浮かべて対処できる。 そんな姿を想像しながら、この記事を執筆しました。
Windows 11のメモ帳を「サッと確認する便利な相棒」として活用しつつ、ここぞという時はVS Codeなどの「専用ツール」で確実に仕上げる。 この柔軟な使い分けこそが、トラブルを未然に防ぐ、スマートなエンジニアのスタイルです！
この記事が、あなたの快適な開発ライフ、そして平和なチーム開発の一助となれば本当に嬉しいです。
これで、あの謎のエラーにもう悩まされませんように…🙏✨ あなたのエンジニアライフを、心から応援しています！💪
コメント