みなさんこんにちは！ヒロポンです！！
今回は C# 業務SE現場でガチで踏みやすいやつ！！の話。
「CSV 取り込みバッチを書いたら 改行コードの違いで全行が1行に化けた」「Shift-JIS の取引先データを読んだら文字化けで ?????? だらけ」「File.ReadAllLines で 1GB のログを読もうとしたら OutOfMemoryException で落ちた」みたいなファイルIO の事故って、業務SEで一回はやらかしますよね？？
俺も2社目くらいの流通系SIer時代に、取引先から来た Shift-JIS の CSV を File.ReadAllText(path)（既定 UTF-8）で読んで、全行 ????? で文字化けした事件をやらかしました。夕方の運用報告で「データが文字化けしてる」って報告で気づいて半日デバッガで追ってハマったやつ。原因は完全にエンコーディング指定漏れで、StreamReader で Encoding.GetEncoding("shift_jis") を渡すパターンに書き換えて解決。
C# でファイルを読む API は3系統 + using の理解が要ります:
StreamReader（クラスベース、エンコーディング指定可、最も柔軟）File.ReadAllLines（一発で全行配列、メモリ食う、小ファイル向き）File.ReadLines（IEnumerableで遅延読み込み、大ファイル向き）using（IDisposable自動解放、StreamReader系で必須）
この記事では VS2019 / .NET Framework 4.7.2 / C# 7.3 環境で、3系統の使い分けと エンコーディング・改行・FileShare・OOM の落とし穴を、コード6本でまとめます。後ろの「現場メモ」で、業務系チームでルール化した時の話も書いてる。
3行で結論:
- 小ファイル（数 KB〜数 MB）→
File.ReadAllLines（コード短い・即配列）- 大ファイル（数十 MB〜GB）→
File.ReadLines+foreach（メモリ節約・ストリーム処理）- エンコーディング指定したい時（Shift-JIS / BOM 付き）→
StreamReader+using+Encoding指定
定石1: StreamReader + using + Encoding 指定
最も柔軟な書き方。エンコーディング指定したい業務系の CSV / 取引先連携データはこれが本命:
// ✅ 定石1: StreamReader + using で Shift-JIS 読み込み
using System.IO;
using System.Text;
var sjis = Encoding.GetEncoding("shift_jis");
using (var sr = new StreamReader(@"C:\input\trade-data.csv", sjis))
{
string line;
while ((line = sr.ReadLine()) != null)
{
// 1行ずつ処理（CSV 分解 → DB INSERT 等）
ProcessOneRow(line);
}
}
// ↑ ブロック終了で sr.Dispose() が finally で確実に呼ばれる
ポイント:
Encoding.GetEncoding("shift_jis")で日本語業務系の典型 CSV に対応usingで IDisposable 自動解放（Close()書き忘れによるロック予防）ReadLine()で1行ずつ読む（メモリ節約）- null 判定でファイル末尾を検出（while ループの定石）
UTF-8 BOM 付きなら Encoding.UTF8、UTF-8 BOM なしなら new UTF8Encoding(false) を渡す。.NET Framework は Shift-JIS 標準対応ですが、.NET Core / .NET 5+ では System.Text.Encoding.CodePages の NuGet 追加が要るので注意っす。
定石2: File.ReadAllLines — 小ファイル向きの一撃
ファイルサイズが小さい（数 KB〜数 MB）場合、コード短く書ける File.ReadAllLines が本命:
// ✅ 定石2: File.ReadAllLines で一発配列化
using System.IO;
using System.Text;
string[] lines = File.ReadAllLines(@"C:\input\config.txt", Encoding.UTF8);
foreach (var line in lines)
{
if (line.StartsWith("#")) continue; // コメント行スキップ
ParseConfig(line);
}
ポイント:
- 1行で全行配列化（コード量最小）
- エンコーディングは第2引数で指定可能
- 改行コード
\r\n/\n/\r全部を行区切りで扱う（業務系で改行混在に強い） - 配列なので
Length/LINQがそのまま効く
ただし欠点として、メモリにファイル全体をロードするので大ファイルだと OutOfMemoryException が飛ぶ。1GB のログを ReadAllLines で読むと、配列 + 文字列オブジェクトのオーバーヘッドで4GB 近いメモリを食う事故が起きます。ん？ファイルサイズ気にするとか面倒じゃない？？って思うかもだけど、サイズが読めるファイルだけで使う判断軸を入れるだけで業務系の OOM 事故はほぼ消えます。
定石3: File.ReadLines — 大ファイルのストリーム読み込み
大ファイル（数十 MB〜GB）の場合、File.ReadLines で IEnumerable<string> を返してもらって遅延読み込みするパターン:
// ✅ 定石3: File.ReadLines で大ファイルをストリーム処理
using System.IO;
using System.Text;
// IEnumerable<string> なので foreach で1行ずつ読む（メモリには1行分しか乗らない）
foreach (var line in File.ReadLines(@"C:\logs\app-2026-05.log", Encoding.UTF8))
{
if (line.Contains("ERROR"))
{
ExtractErrorEntry(line);
}
}
// LINQ 連携も可能（遅延評価で全件メモリに乗らない）
var errorCount = File.ReadLines(@"C:\logs\app-2026-05.log", Encoding.UTF8)
.Count(l => l.Contains("ERROR"));
ポイント:
- 遅延評価で1行ずつ読み込む（10GB ファイルでもメモリ数 MB）
- LINQ メソッドチェーンが効く（
Where/Count/Take等） - 内部で
StreamReaderを使ってる（using不要・自動 Dispose） - 改行コード混在に対応
業務系のログ集計・大量 CSV 取り込み・帳票出力で本命のパターン。前回の記事「DataReader vs DataAdapter」と同じ発想で、メモリに溜め込まずストリーム処理する判断軸っす。
定石4: 性能比較 — Stopwatch + GC.GetTotalMemory
File.ReadAllLines と File.ReadLines の体感差を実測すると、桁違いの違いが見えます:
// ✅ 定石4: 性能比較（10万行 × 約 100MB のログを想定）
const string path = @"C:\logs\big-app.log";
// ReadAllLines 版（メモリに全部ロード）
GC.Collect(); GC.WaitForPendingFinalizers();
long memBefore = GC.GetTotalMemory(true);
var sw1 = Stopwatch.StartNew();
string[] all = File.ReadAllLines(path, Encoding.UTF8);
int errCnt1 = all.Count(l => l.Contains("ERROR"));
sw1.Stop();
long memAfter = GC.GetTotalMemory(false);
Console.WriteLine($"ReadAllLines: {sw1.ElapsedMilliseconds}ms / {(memAfter - memBefore) / 1024 / 1024}MB / {errCnt1}件");
// ReadLines 版（ストリーム読み込み）
GC.Collect(); GC.WaitForPendingFinalizers();
memBefore = GC.GetTotalMemory(true);
var sw2 = Stopwatch.StartNew();
int errCnt2 = File.ReadLines(path, Encoding.UTF8).Count(l => l.Contains("ERROR"));
sw2.Stop();
memAfter = GC.GetTotalMemory(false);
Console.WriteLine($"ReadLines : {sw2.ElapsedMilliseconds}ms / {(memAfter - memBefore) / 1024 / 1024}MB / {errCnt2}件");
俺の手元（VS2019 / .NET Framework 4.7.2 / x64 Release / 100MB ログ・10万行）の体感差は、こんな感じ:
| API | 実行時間 | メモリ消費 |
|---|---|---|
File.ReadAllLines |
約 850ms | 約 350MB |
File.ReadLines |
約 720ms | 約 8MB |
**メモリ消費が桁違い（約44倍）**なのが見える。ReadAllLines は配列 + 文字列オブジェクトのヒープオーバーヘッドが大きいので、100MB のファイルで350MB のメモリを食う。1GB のログだと 4GB 近く食って OutOfMemoryException で落ちるケースもあるので、サイズが読めない業務系のファイル取り込みは ReadLines 寄せが安全っす。
定石5: FileShare で同時アクセスを扱う
ログファイルが別プロセスから書き込み中でも読みたい場合、FileShare.ReadWrite を指定する書き方:
// ✅ 定石5: FileShare.ReadWrite で同時アクセスを許可
using System.IO;
using System.Text;
using (var fs = new FileStream(@"C:\logs\writing.log",
FileMode.Open,
FileAccess.Read,
FileShare.ReadWrite)) // 別プロセスの読み書きも許可
using (var sr = new StreamReader(fs, Encoding.UTF8))
{
string line;
while ((line = sr.ReadLine()) != null)
{
ProcessLogLine(line);
}
}
ポイント:
FileShare.None: 排他（既定）。他プロセスは開けないFileShare.Read: 他プロセスが読みは OK、書きは不可FileShare.ReadWrite: 他プロセスの読み書き両方 OK
業務系の 「ログを書き込み中のままリアルタイム監視したい」 ような用途で効くやつ。ただし、書き込み中の不完全な行が読めるリスクがあるので、業務系では「ログローテーション後に取り込む」設計の方が安全っす。
定石6: エンコーディング判定の実践 — Shift-JIS と BOM 付き UTF-8 の見分け
業務系で取引先から来るファイルは、エンコーディングが何かを送り主に聞くのが本筋ですが、確認できない時は最初の数バイトで判定する手もあります:
// ✅ 定石6: BOM の有無で簡易判定（業務系で雑なエンコーディング判定）
public static Encoding DetectEncoding(string path)
{
var bytes = new byte[4];
using (var fs = new FileStream(path, FileMode.Open, FileAccess.Read))
{
fs.Read(bytes, 0, 4);
}
// UTF-8 BOM (EF BB BF)
if (bytes[0] == 0xEF && bytes[1] == 0xBB && bytes[2] == 0xBF)
return Encoding.UTF8;
// UTF-16 BOM (FF FE / FE FF)
if (bytes[0] == 0xFF && bytes[1] == 0xFE) return Encoding.Unicode;
if (bytes[0] == 0xFE && bytes[1] == 0xFF) return Encoding.BigEndianUnicode;
// BOM なし → 業務系の典型は Shift-JIS（取引先 Excel CSV 出力等）
return Encoding.GetEncoding("shift_jis");
}
// 使う側
var enc = DetectEncoding(@"C:\input\trade.csv");
foreach (var line in File.ReadLines(path, enc))
{
ProcessOneRow(line);
}
これは雑な判定で、BOM なし UTF-8 を Shift-JIS 扱いにする可能性があります。業務系では送り主にエンコーディングを聞く運用が一番安全で、自前判定は最終手段に留めるのが鉄則っす。
ハマりポイント — 実体験ベースの本番事故3点
1. Shift-JIS CSV を UTF-8 で読んで全行文字化け（半日デバッガで追ってハマった）
取引先から来た CSV を File.ReadAllText(path)（既定 UTF-8）で読んで全行 ????? になった事件。夕方の運用報告で気づいて半日デバッガで追ってハマった末に、StreamReader + Encoding.GetEncoding("shift_jis") に書き換えて解決。それ以来、業務系チームで 「取引先 CSV はエンコーディング確認 + StreamReader で Encoding 指定」 をルール化しました。
2. 1GB ログを ReadAllLines で読んで OOM（30分溶かした）
監視ツールで 1GB のアクセスログを File.ReadAllLines で読み込もうとして、OutOfMemoryException で詰まった事件。30分溶かした末に、File.ReadLines + foreach のストリーム処理に書き換えてメモリ 8MB 程度に収まった。それ以来、ログ・CSV など可変サイズのファイルは原則 ReadLines 寄せを業務系チーム規約にしました。
3. using 漏れでファイルロック残留（数日プロファイラで追った）
StreamReader を using で囲わず Close() も呼んでなくて、別プロセスが「他のプロセスが使用中」エラーで詰まる事件。数日プロファイラで追ってようやく気付いた。GC が走るまで OS レベルでファイルハンドルが解放されないので、業務系の連携バッチで間欠的に発生してた。using で囲うパターンに統一して解決。ファイル系 IDisposable は全部 usingを業務系チーム規約に揃えました。
著者の現場メモ — 業務系チームでのファイルIO ルール
流通系SIer時代に、過去コードを grep -rnE "File\.ReadAll|StreamReader|new FileStream" . でひっかけたら、90箇所近く 出てきたんですよね。書き方がバラバラで、File.ReadAllText でエンコーディング指定なし、StreamReader を using なしで使う、File.ReadAllLines で大ファイルを読んで OOM リスクある、全部入り。
んで、後輩と一緒に 3行ルール にまとめた:
- エンコーディング指定したいファイルは
StreamReader+using+Encoding（取引先 CSV / Shift-JIS） - 小ファイル専用で
File.ReadAllLines（サイズが読めない時は禁止） - 大ファイル・サイズ不明は
File.ReadLines+foreach寄せ（メモリ事故予防）
このルール化で、ファイルIO 周りの文字化け / OOM / ロック残留事故が消えた。書き方を1パターンに揃えるだけで保守工数も事故率も両方下がるので、業務系チームには結構おすすめのルールっす。
C# 7.3 + .NET Framework 4.7.2 のレガシー業務系って、ファイルIO API は10年以上変わってないのに、書き方が現場ごとにバラバラなコードベースが本当に多い。書き方のアップデートだけで保守工数が下がる実例だと思ってます。
まとめ
| 状況 | 推奨 API |
|---|---|
| 小ファイル（数 KB〜数 MB）の単発読み込み | File.ReadAllLines |
| 大ファイル（数十 MB〜GB） | File.ReadLines + foreach |
| エンコーディング指定したい | StreamReader + using + Encoding |
| 別プロセス書き込み中の同時アクセス | FileStream + FileShare.ReadWrite |
| エンコーディング判定 | BOM チェック or 送り主に確認 |
| using の役割 | IDisposable 自動解放（ファイルロック予防） |
| 改行コード混在 | 標準 API（ReadAllLines / ReadLines）に任せる |
自前 string.Split('\n') |
禁止（\r 残留で文字化け） |
C# のファイルIO 事故は、「サイズで API を選ぶ」「エンコーディング指定」「using で囲う」 の3点で9割消えます。File.ReadAllText を裸で呼ぶ運用は事故の温床なので、業務系チームではサイズ・エンコーディング・using の3要素を揃えるレビュー観点を入れておくのが安全っす。
よくある質問
Q1. File.ReadAllLines と File.ReadLines はどっちを使うべき？
A. ファイルサイズで分けます。小ファイル（数 KB〜数 MB）なら ReadAllLines（一発で配列、コード短い）、大ファイル（数十 MB〜GB）なら ReadLines（IEnumerable で1行ずつ遅延読み込み、メモリ節約）。1GB のログを ReadAllLines で読むと数 GB のメモリを食って OutOfMemoryException が飛びますが、ReadLines なら数 MB で済みます。サイズ不明な業務系では ReadLines + foreach 寄せが安全です。
Q2. Shift-JIS の CSV を読むと文字化けします、どうすれば？
A. StreamReader にエンコーディングを明示してください。new StreamReader(path, Encoding.GetEncoding("shift_jis")) の形。.NET Framework は既定で Shift-JIS を扱えますが、.NET Core / .NET 5+ では System.Text.Encoding.CodePages パッケージが必要です。BOM 付き UTF-8 ファイルは Encoding.UTF8 で OK ですが、BOM なし UTF-8 を Shift-JIS で読むと派手に文字化けするので、業務系では取り込み前にファイルのエンコーディング確認を運用化するのが鉄則です。
Q3. using を書き忘れたらどうなりますか？
A. ファイルがロックされ続けて、別プロセス・別スレッドからアクセスできなくなります。StreamReader を using で囲わず Close() も呼ばないと、GC が走るまで OS レベルでファイルハンドルが解放されない。業務系で「他のプロセスが使用中」エラーが出る原因の典型です。StreamReader / StreamWriter / FileStream は全部 using で囲うのが鉄則で、CLAUDE.md の例外処理ルールと整合させると保守工数も下がります。
Q4. ファイルを別プロセスが開いている時にも読みたい場合は？
A. FileShare.ReadWrite を指定して FileStream を開き、それを StreamReader でラップします。new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.ReadWrite) の形。ログファイルを別プロセスが書き込んでる最中に取り込みたい時に効きます。ただし、書き込み中の不完全な行が読めるリスクがあるので、業務系ではファイルロックを尊重する設計が無難です。
Q5. 改行コードが \r\n / \n / \r で混在していて行数がズレるのは？
A. File.ReadAllLines / File.ReadLines は3種類の改行コード全部を行区切りとして扱うので、混在していても正しく分割されます。問題が起きるのは string.Split('\n') のように手書きで分割した時で、\r が行末に残って文字化けの原因になります。改行を含むファイルは標準 API（ReadAllLines / ReadLines）に任せるのが安全で、自前 split は避けるのが鉄則です。
ここまでで C# ファイルIO の主要 API・性能・エンコーディング・FileShare は押さえた。using / IDisposable / メモリ性能の隣接トピックも貼っておきます。
関連記事
- C# 例外処理の正解 — try-catch-finally / using / Exception フィルタ (when句) の使い分け —
usingステートメントの本質とIDisposable解放の整理に効く - C# DataReader vs DataAdapter — メモリ消費と性能の使い分け（業務SE 判断軸） — 大量データのストリーム読み込み判断軸として共通する考え方
- C# 文字列結合のパフォーマンス完全比較（+ / Concat / StringBuilder / Format / 補間） — ファイル読み込み後の文字列処理で性能を意識する時に効く
以上！
同じ罠でハマってる業務SE仲間いたら、どんどんシェア待ってるぜ！！
コメント