管理者のすべての投稿

Java, ブログ, プログラミング

Java：trimだけじゃない！前後の空白を完全に除去する方法

2025年11月16日管理者コメントする

Javaで文字列の前後の空白を削除したいとき、多くの人がまず trim() を使います。しかし、実務で扱うデータはもっと複雑。
実は trim() では 取り除けない空白 が存在します。

この記事では、

trim() の弱点
完全に空白除去したいときのベストプラクティス
実務（CSV・外部連携・Webアプリ）でのよくある落とし穴

をわかりやすく整理します。

■ trim() は万能ではない：取り除けない空白がある

trim() はあくまで Unicodeの制御文字(0x00–0x20) のみを対象にしています。

▼ trim()で削除できる例

半角スペース " "
タブ \t
改行 \n
復帰 \r

▼ trim()で削除できない代表例

全角スペース（　）
ノーブレークスペース（）
ゼロ幅スペース（\u200B）
特殊なUnicode空白

外部システム連携やExcel由来データで**“見えないゴミ空白”**が混入し、trim()では除去できないケースは非常に多いです。

■ 前後の空白を「完全に」除去する方法

① 正規表現による空白除去（最も汎用的）

▼ ポイント

\s = 制御文字＋一般的な空白
\p{Z} = Unicodeの空白カテゴリ（全角スペースなど）
前後どちらも削除できる

trim() では消えない全角・特殊スペースもまとめて除去できます。

■ ② Apache Commons Langの StringUtils を使う方法（簡単）

Apache Commons Lang が使えるなら、こちらが最も便利。

▼ trim()との違い

全角スペースも削除できる
Unicode空白に幅広く対応

外部システムとの連携が多い業務システムでは定番です。

■ ③ カスタム実装で「ホワイトリスト方式」

どの空白を除去するかを 自分で定義したい場合。

よく問題になる空白だけに絞りたいときに有効です。

■ 比較表：どの方法を使うべき？（実務ベース）

方法	メリット	デメリット	実務での利用度
trim()	標準、軽量、速い	全角スペースに弱い	△
正規表現	完全除去できる	少し処理が重い	◎
Apache StringUtils	記述が最も簡単	ライブラリが必要	◎
カスタムRegex	精密に制御可能	コードの読みにくさ	○

■ 実務で多いトラブル例

● CSVインポート時に項目が一致しない

→ Excel入力データに 全角スペース が混入している
→ trim() では削除されずバリデーションNG

● 外部システムのレスポンス整形で意図せず不一致

→ JSONのフィールドに ノーブレークスペース が入っていた

● Webフォームの入力チェックで正しく弾けない

→ ゼロ幅スペース（\u200B）が悪さをしていた

Javaの文字列処理では 目に見えないUnicode空白 がしばしば問題を起こします。

■ まとめ：trim() だけに頼らないこと！

前後の空白を 100％除去 したいなら、

正規表現（\s + \p{Z}）
StringUtils.trim()

このどちらかが“安全策”です。

業務システム、外部連携、CSV処理など “実データを扱う場面” では trim() だけでは不十分なことが多いため、ぜひ今回の方法を取り入れてみてください。

Oracle, データベース, トラブル対応, ブログ

【Oracle】ORA-03113：通信チャネルEOFエラーの原因と解決手順をわかりやすく解説

2025年11月15日管理者コメントする

■ ORA-03113とは？

ORA-03113: end-of-file on communication channel は、
Oracle クライアントとサーバ間の通信が異常終了したとき に表示される代表的なエラーです。

平たく言うと、

「通信中にいきなり回線が切れた / Oracle が応答しなくなった」
という状態。

接続断・セッション強制終了など、原因は幅広いため、
切り分けのポイントが非常に重要なエラーとなります。

■ ORA-03113 が発生する主な原因

1. Oracle インスタンスがクラッシュ / 強制停止した

もっとも多い原因です。

インスタンスが落ちた
PMON による強制終了
ORA-600 / ORA-7445 など内部エラーと連動
OS側のメモリ不足・カーネル不具合

▼確認ポイント

alert.log に異常が出ていないか
ORA-600 / ORA-7445 が直前に出ていないか
インスタンスが restart されていないか

2. ネットワークの不安定化・切断

クライアントと DB サーバの間のネットワークが瞬断すると発生。

VPN が切れた
ファイアウォールのタイムアウト
回線の瞬断／通信遅延
パケットロス

▼確認ポイント

サーバとの ping 値・遅延
FW・LB のセッションタイムアウト
SSH が同時に切れないか
スイッチ再起動などのネットワークイベント有無

3. タイムアウト設定（SQLNET.ORA / Firewall）の影響

長時間 SQL を実行するバッチで頻発する原因。

SQLNET.EXPIRE_TIME の影響
Firewall / Router のアイドルタイムアウト
Application Server のコネクションプール強制切断

▼対策例

SQLNET.EXPIRE_TIME = 10

1	SQLNET.EXPIRE_TIME = 10

（10分に1回 keepalive を送る設定）

4. クライアントアプリ側の異常終了

Java / Python / C++ などクライアントが強制終了
JDBC / ODP.NET の古いドライバ
途中でプロセスが kill される

▼確認ポイント

クライアントログにエラーがないか
ドライババージョン
JVM の GC が暴走していないか

5. SQL の実行中にサーバリソースが枯渇

大きなバッチ処理中に発生するケース。

PGA/UGA 枯渇
CPU / メモリ枯渇
TEMP 使用量が100%
I/O 遅延

▼確認ポイント

AWR / Statspack の負荷
v$session_wait の値
TEMP の使用量

■ ORA-03113 が出たときの切り分け手順（最速版）

迷ったら まずは Oracle サーバ側のログを先に確認 が鉄則！

【1】alert.log を確認

最初に必ず見る場所。

例：

何かしら痕跡が残っていることが多い。

【2】trace ファイル（*.trc）を確認する

内部エラーの場合はこちらに詳細。

スタックトレース
直前の SQL
ユーザセッション情報

【3】ネットワーク切断の有無を確認

FW のログ
ping のロス率
VPN 稼働状況
SSID や Wi-Fi の不安定性も対象

【4】同時刻に OS イベントが発生していないか

メモリ OOM
ディスクフル
OS 再起動
Kernel Panic

【5】クライアント側のログ確認（アプリ含む）

JVM ログ
アプリログ
ODP.NET / JDBC のエラー

■ よくあるパターン別の対策

● ケース1：長時間SQLで毎回切断される

これは Firewall / LB タイムアウトが犯人 の場合が多い。

▼対処

DBA：SQLNET.EXPIRE_TIME を設定
ネットワーク：タイムアウト延長
アプリ：コネクションプールの keepalive 有効化

● ケース2：大量データ処理バッチで発生

▼対処

TEMP 表領域増設
PGA を増やす
インデックス追加など SQL チューニング

● ケース3：インスタンスが落ちた

▼対処

alert.log の内部エラーを修正
パッチ適用
メモリ/OS リソースの見直し
Oracle Support に SR 起票

■ まとめ（結論）

ORA-03113 は 「通信が突然切れた」ことを示す汎用エラー で、
原因は広いですが、必ず次のどれかに分類できます。

Oracle インスタンスの異常
ネットワークの遮断
タイムアウト設定の問題
クライアントの異常終了
サーバリソース不足

迷ったら alert.log → ネットワーク → クライアント の順に切り分ければ最短で原因にたどり着けます。

Windows, トラブル対応, ブログ

ブルースクリーン（BSOD）が出たときの確認ポイント【Windows 11】

2025年11月15日管理者コメントする

Windows 11 を使っていると、ある日突然現れる「ブルースクリーン（青い画面）」。

正式名称は BSOD（Blue Screen of Death） で、OS が重大なエラーを検出した際に表示されます。

この記事では、BSOD が出たときに必ず確認すべきポイントと、原因追跡の方法、再発防止策を分かりやすく解説します。

1. 最初に確認すべきは「エラーコード」

ブルースクリーンには STOP コードが表示されます。
例：

MEMORY_MANAGEMENT
CRITICAL_PROCESS_DIED
IRQL_NOT_LESS_OR_EQUAL
UNEXPECTED_STORE_EXCEPTION

この STOP コードは、Windows が「どの種類のエラーで落ちたか」を示す主要手掛かりです。

● STOP コードの確認方法

ブルースクリーンの画面写真をスマホで撮影しておくのが確実です。
再起動後、以下でも確認できます：

設定 → システム → 詳細情報 → システムの保護 → システムのプロパティ → 起動と回復
または、イベントビューア（後述）

2. イベントビューアで詳細ログを確認する

Windows は BSOD の詳細をログに記録しています。

● 確認手順

Win + X → イベントビューア
左のツリーから
「Windows ログ」 → 「システム」 を選択
右側のフィルターで「重大」「エラー」を絞り込む

よくある記録：

Kernel-Power 41：予期しないシャットダウン
BugCheck：BSOD 発生のログ
→ エラーコード（BugCheckCode）やパラメータが確認できる

3. ドライバ更新状況を確認する

BSOD の原因として最も多いのは ドライバの不具合です。
特に以下は要注意：

GPU ドライバ（NVIDIA / AMD / Intel）
オーディオドライバ
LAN / Wi-Fi ドライバ
ストレージドライバ（Intel RST など）

● 更新・再インストール手順

デバイスマネージャー → 該当デバイス → ドライバー → 更新
公式サイトから最新版をダウンロードして入れ直すのも有効

4. メモリ（RAM）のテストを行う

メモリ異常は BSOD の典型的な原因。

● Windows メモリ診断

Windows キー →「メモリ診断」検索
「今すぐ再起動して問題を確認する」
診断結果はイベントビューアの MemoryDiagnostics-Results に記録される

メモリ増設後の BSOD は高確率でこれが原因です。

5. ストレージ（SSD/HDD）の状態チェック

SSD の劣化やセクタ不良でも BSOD が発生します。

● チェック方法

**CrystalDiskInfo（無料）**で SSD の健康状態を見る
コマンドプロンプトで

MS DOS

chkdsk /f /r

1

chkdsk /f /r

を実行してファイルシステムの破損を修復

6. Windows Update の不具合を疑う

大型アップデート後に BSOD が出るケースは多いです。

● 対処

累積更新プログラムをアンインストール
「更新プログラムの履歴」 → 「更新プログラムをアンインストール」
または「システムの復元」でロールバック

7. 最近インストールしたアプリを確認する

セキュリティソフトやドライバ関連ツールが BSOD を引き起こすことがあります。

特に注意：

サードパーティ製アンチウイルス
監視ツール（OCCT, HWMonitor 系）
仮想化ソフト（VMware / VirtualBox）

8. 省電力設定/オーバークロックの影響

● 自作PCユーザー向けですが、以下も BSOD 原因になります：

CPU/GPU のオーバークロック
XMP（メモリ OC プロファイル）
高パフォーマンス電源設定との相性

一時的に XMP をオフ、BIOS を初期化すると改善することも。

9. システムファイルの破損チェック

OS の内部ファイルが壊れている場合。

● コマンド例

管理者コマンドプロンプトで：

さらに：

これで OS の破損修復が可能。

10. 再発防止のための最終手段

クリーンブートで原因アプリを切り分ける
セーフモード起動してドライバを削除
Windows の初期化（個人ファイル保持も可能）
SSD / メモリ交換
メーカー修理依頼

まとめ

ブルースクリーン（BSOD）は必ず原因があります。
特に多いのは、

ドライバの不具合
メモリ／ストレージの異常
Windows Update の問題
ソフトウェアの相性

この記事の流れどおりに確認すれば、原因特定のスピードが一気に上がり、無駄な再起動を減らせます。

PowerShell, ブログ, プログラミング

PowerShellで数十万行のCSVを高速処理するベストプラクティス

2025年11月15日管理者コメントする

PowerShellで数十万行以上のCSVを扱うと、
「読み込みが遅い」「メモリが一気に膨れる」「処理が固まったように見える」
といった問題が発生しがちです。

実はこれ、PowerShellのCSV処理の仕組みによる“あるある”で、
正しい書き方をすれば劇的に高速化できます。

この記事では、現場でも使われている 高速処理テクニック・実装例・注意点 をまとめます。

✔ なぜPowerShellはCSV処理が遅くなるのか

PowerShellの Import-Csv は便利ですが…

全行を一度にメモリへ展開する
オブジェクト化のコストが高い
数十万件を超えると数百MB〜GB級のメモリ使用

という特徴があります。

そのため、以下のような書き方は最も遅くなります。

✔ 高速化のポイントは「逐次読み込み」と「Stream処理」

PowerShellで数十万行を高速に処理する場合の最重要ポイントは以下。

💡 高速化の基本

Import-Csv を使わず StreamReader を使う
1行ずつ処理して不要になったデータは捨てる
Select-Object, Where-Object をループで使わない
型変換を最小限にする
出力は StringBuilder にまとめて最後に書き込む

✔ ベストプラクティス①：StreamReaderで逐次処理

最も高速でメモリ効率も良い方法です。

$path = "large.csv"
$out  = "result.csv"

$reader = [System.IO.StreamReader]::new($path)
$writer = [System.IO.StreamWriter]::new($out, $false, [Text.Encoding]::UTF8)

# ヘッダー読み込み
$header = $reader.ReadLine()
$writer.WriteLine($header)

# 1行ずつ高速処理
while (($line = $reader.ReadLine()) -ne $null) {
    $cols = $line.Split(",")
    
    # 例：3列目が100以上の場合だけ出力
    if ([int]$cols[2] -ge 100) {
        $writer.WriteLine($line)
    }
}

$reader.Close()
$writer.Close()

Write-Host "完了"

$path = "large.csv"

$out = "result.csv"

$reader = [System.IO.StreamReader]::new($path)

$writer = [System.IO.StreamWriter]::new($out, $false, [Text.Encoding]::UTF8)

# ヘッダー読み込み

$header = $reader.ReadLine()

$writer.WriteLine($header)

# 1行ずつ高速処理

while (($line = $reader.ReadLine()) -ne $null) {

$cols = $line.Split(",")

# 例：3列目が100以上の場合だけ出力

if ([int]$cols[2] -ge 100) {

$writer.WriteLine($line)

}

$reader.Close()

$writer.Close()

Write-Host "完了"

✔ 特徴

Import-Csv ではなく Split で直接取得 → 超高速
メモリ使用量は常に一定
数百万行でも余裕

✔ ベストプラクティス②：Import-Csv を使う場合の高速化

「やっぱりオブジェクトで扱いたい」という場合はこちら。

✔ 注意点

ForEach-Object -Parallel は PowerShell 7 以降限定
並列化は CPUコア数に依存
メモリ使用量は多め

✔ ベストプラクティス③：Select-Object / Where-Object を避ける

以下は遅くなりがち：

理由：すべての行をオブジェクトとして保持してしまう。

💡 改善

または、最速は StreamReader + Split。

✔ ベストプラクティス④：StringBuilderで出力バッファを作る

行ごとに Add-Content を実行すると激遅になります。

✔ StringBuilderを使う（高速）

✔ ベストプラクティス⑤：PowerShell 7 を使う

PowerShell 5.1 から PowerShell 7 に変えるだけで速度が倍以上になるケースが多いです。

理由

.NET Core ベースで高速化
ForEach-Object が最適化
Parallel 処理対応

✔ 実際の処理速度比較（目安）

手法	100万行の処理	メモリ使用量
Import-Csv → ループ	数十秒〜数分	数百MB〜1GB超
Import-Csv -Parallel	10〜40秒	多め
StreamReader + Split	5〜15秒	数MB

※ PCスペックにより変動。

✔ まとめ：最速は「StreamReader＋Splitによる逐次処理」

PowerShellで数十万行のCSVを高速処理するなら

✔ 最適解

逐次読み込み（ストリーム処理）
行ごとにSplitして必要な列だけ触る
StringBuilderでまとめて出力する
PowerShell 7 ならParallel化も可能

業務バッチで使う場合は、
StreamReader方式が最も安全で高速です。

実際の現場でも「メモリ溢れ対策」「速度改善」で最も採用されています。

Excel, トラブル対応, ブログ

Excelで「数値なのに計算できない」問題の原因一覧

2025年11月15日管理者コメントする

Excelを使っていると、「セルの値は数字のはずなのに計算されない」「SUMに反映されない」「左寄せになる」という現象がよく発生します。
原因のほとんどは 「数値が文字列として扱われている」 ことですが、文字列化の理由は複数あります。

この記事では、実務でよく起きる原因を一覧化し、すぐにチェックできるように整理 しています。

■ 1. セルの書式が「文字列」になっている

もっとも定番の原因がこれです。

「ホーム」→「数値」→「文字列」になっている
左寄せになっている
式で計算されない／SUMに反映されない

修正方法：

セルを選択
書式を「標準」または「数値」に変更
必要であれば F2 → Enter で再確定

■ 2. 先頭に「’」（シングルクォート）が入っている

CSVインポート時やシステム出力データに多いパターンです。

例：
'12345
→ 見た目は数値だが、内部は文字列。

修正方法：

「データ」→「区切り位置」→「完了」で再変換
または SUBSTITUTE で ’ を除去

■ 3. 全角数字が混ざっている（0〜9 が全角）

パッと見で気付きにくい原因の一つです。

例：
１２３４５
→ 全角のため文字列扱い。

判別方法：

左寄せ
書式を変更しても変わらない
LEN で長さが合わない

修正方法：

CLEAN、ASC関数
Power Query の「文字種変換」
全角 → 半角変換ツールを使う

■ 4. 数値の後ろや前にスペースが入っている

特に 末尾スペース（トレailing space） が多いです。

例：

1234␣
␣1234

1 2	1234␣ ␣1234

修正方法：

TRIM（Tab のような特殊スペースは取れない場合あり）
CLEAN
Power Query →「空白の削除」

■ 5. Non-Breaking Space（NBSP / CHAR(160)）が入っている

Web からコピーしたときに混入しがちです。
普通の TRIM では削除されません。

判別方法：
=CODE(MID(A1,1,1)) → 160 が出る

修正方法：

=SUBSTITUTE(A1,CHAR(160),"")

1	=SUBSTITUTE(A1,CHAR(160),"")

■ 6. 数値の途中にカンマ・記号が混ざっている

Excelは 「数値として成立しないフォーマット」 を拒否します。

例：

1,234,567,（末尾カンマ）
1234円
#1234
1234-

修正方法：

SUBSTITUTEで除去
Power Queryで不要文字削除

■ 7. 数値が非常に長く、Excelが自動的に文字列として読み込む

13桁以上の数字（JANコード、社員番号など）は Excel が自動で丸めるため、一部のツールが数字を文字列として出力する ことがあります。

例：
1234567890123

修正方法：

「文字列」として扱いたい → 先頭にシングルクォート
「数値」扱いにしたい → 数値型＋指数表記の調整

■ 8. 数値として認識できない記号が含まれている（見えない制御文字）

コピー元が

PDF
Webサイト
外部業務システム

の場合、不可視文字（制御コード） が混入していることがあります。

修正方法：

CLEAN
SUBSTITUTEで削除
Power Queryの「不要文字削除」

■ 9. 数値の前に「=」が付いている（ただし計算式ではない）

システム出力の一部で、文字列の中に「=1234」のような形式があると、Excelは 文字列扱い します。

修正方法：

SUBSTITUTEで「=」を除去
TEXT関数で変換後に VALUEで数値化

■ 10. セルに「エラー」マークが出ているのに無視している

Excelは親切に
「数値が文字列として保存されています」
という警告を出します。

小さな黄色の三角形＋ビックリマークです。

修正方法：

「数値に変換」をクリック
一括変換も可能（選択範囲）

■ まとめ：原因は複数。まずは「書式」「記号混入」をチェック

Excelで数値が計算されない原因はほとんどが 「文字列化」 によるものですが、その理由は以下に分類できます。

書式の問題（文字列、全角数字、シングルクォート）
文字種の問題（NBSP、制御文字、スペース）
フォーマットの問題（通貨記号、末尾カンマ、単位付き）
インポート時の仕様（CSV・システム出力の文字列化）

記事通りに順番にチェックすれば、ほぼ確実に原因が特定できます。

SQL, ブログ

SQL：VIEWの仕組みを理解する – 仮想テーブルはどう評価される？

2025年11月14日管理者コメントする

SQLのVIEW（ビュー）は、データベースの中に“仮想テーブル”を作る仕組みです。
名前は知っていても、

VIEWは物理的にデータを持つのか？
SELECTすると実際にはどう評価されるのか？
VIEWをネストしたらパフォーマンスはどうなる？

といった点まで正しく理解されているケースは意外と少ないです。

この記事では、VIEWの“実体”と、クエリ実行時の評価タイミング、パフォーマンスへの影響を分かりやすく解説します。

1. VIEW（ビュー）とは？ – 定義文を保存する“仮想テーブル”

VIEWはテーブルのように見えますが、実際にはデータを持っていません。
DBに保存されるのは、以下のような「SQL定義（SELECT文）」だけです。

このv_salesはあたかもテーブルのように扱えますが、中身は 上記SELECT文の“参照” でしかありません。

2. VIEWはいつ“評価”されるのか？ – クエリ実行時に展開される

VIEWの最大の誤解ポイントはここです。
ビューは“保存されたSELECT文”なので、クエリ実行のたびに展開されます。

以下のクエリを実行すると、

実際には DB 内部で次のように変換されます。

つまり、

VIEWが実体化して保存されるわけではない
実行時、その都度“SELECT文の中にインライン展開”される
テーブルアクセスもフィルタもすべて本テーブルに作用する

というのがVIEWの基本動作です。

3. DBはVIEWを最適化してくれる – クエリオプティマイザの働き

多くのRDBMS（Oracle / PostgreSQL / MySQL / SQL Server）は、VIEW展開後のSQLを 単一のクエリとして最適化 します。

例えば、

VIEW内にWHERE status='OK'という条件、外側に日付条件があった場合でも、

オプティマイザが結合・条件式をまとめて最適な実行計画に変換する

というのが一般的です。

そのため、VIEWを使ってもパフォーマンスが極端に悪化するわけではありません。
（※もちろん複雑なVIEWの“ネスト”は別の話なので後述）

4. VIEWをネストするとどうなる？ – 複雑化 → 最適化が困難化

例えば次のようにVIEWを三重にしてしまうと、

内部ではこんな巨大なSQLに展開されます。

オプティマイザは強力ですが、以下のような場合は最適化が限界に達します。

JOINが増えすぎる
CASE式やサブクエリが多すぎる
DISTINCT・GROUP BYが重複している
“VIEWの中でさらにVIEWをJOIN” している

その結果、

不要な全表スキャン
重複GROUP BYで大量のソート
複雑化で実行計画が肥大化

というパフォーマンス低下が起きます。

5. VIEWのメリット

✔ コードの再利用性

複雑なSELECTを1つにまとめて使い回せる。

✔ 可読性の向上

アプリ側のSQLがスッキリする。

✔ 権限管理に使える

特定の列だけ公開するVIEWを作り、ユーザにはVIEWだけ権限付与できる。

6. 気をつけるべきポイント（よくある落とし穴）

❌ VIEWが高速化してくれると思い込む

→ VIEWは基本的には“ただのSQLの保存”。高速化しない。

❌ VIEWを多段に重ねて巨大SQLになっている

→ 実行計画が複雑化しパフォーマンス劣化。

❌ UNION・DISTINCT入りVIEWの多用

→ 展開後に何度もソートが発生する。

❌ VIEW経由にするとインデックスが効かないと思い込む

→ 展開後のSQLにインデックスが適用されるので誤解。

7. MATERIALIZED VIEWとの違い（超重要）

種類	データ保持	更新タイミング	用途
VIEW (通常VIEW)	持たない（常に仮想）	実行時に展開	再利用・権限管理・コード整理
MATERIALIZED VIEW	データを保持（物理表）	リフレッシュ時	高速化（集計 / 重いJOIN結果のキャッシュ）

高速化したい時は VIEWではなく MATERIALIZED VIEW を使うのが正解です。

8. VIEWをどう使うべきか？（ベストプラクティス）

✔ 単純ビューを使う

1〜2テーブルのJOIN、軽いWHERE程度に留める。

✔ 複雑なロジックをVIEWに押し込まない

アプリ側に処理を書くか、ストアドやマテリアライズドビューで対応。

✔ 多段VIEWは避ける

どうしても必要な場合は“1段階に統合して新VIEWを作る”。

✔ パフォーマンス課題が出たら、展開SQLを確認する

実行計画を見ると改善点がすぐわかる。

まとめ：VIEWは“実体のないSELECT文”であり、実行時に展開される

ポイントを整理すると：

VIEWはデータを持たない（仮想テーブル）
DBはVIEW定義を毎回展開し、1つのSQLとして最適化する
単純なVIEWは便利だが、多段ビューはパフォーマンス悪化の原因
高速化目的なら MATERIALIZED VIEW を使うべき

VIEWは便利な反面、仕組みを誤解すると性能劣化の原因にもなります。
“何がどう評価されているのか”を理解した上で、適切に設計しましょう。

Java, ブログ, プログラミング

Java Streamsで文字列リストを加工・整形する便利テクニック

2025年11月14日管理者コメントする

Java 8 以降で利用できる Stream API は、文字列リストの加工・整形に非常に便利です。
filter / map / collect を組み合わせるだけで、複雑な処理もスッキリ書けるようになります。

この記事では、**業務システムで頻出する「文字列リストの加工」**を中心に、すぐに使えるサンプルをまとめています。

✔ よくある文字列リストの処理

業務プログラムの中で、以下のようなケースはよくあります。

空文字・null を除去したい
前後の空白を trim したい
大文字/小文字変換をしたい
任意の条件で絞り込みたい
区切り文字にまとめたい（CSV・ログなど）

こうした処理は Stream API を使うと 1 行で書ける ことが多いです。

1. 空文字・null を除去する

List<String> list = Arrays.asList("A", "", null, "B", "  ", "C");

List<String> result = list.stream()
        .filter(Objects::nonNull)      // null除外
        .map(String::trim)              // trim
        .filter(s -> !s.isEmpty())      // 空文字除外
        .collect(Collectors.toList());

System.out.println(result); // [A, B, C]

List<String> list = Arrays.asList("A", "", null, "B", " ", "C");

List<String> result = list.stream()

.filter(Objects::nonNull) // null除外

.map(String::trim) // trim

.filter(s -> !s.isEmpty()) // 空文字除外

.collect(Collectors.toList());

System.out.println(result); // [A, B, C]

2. 全要素を大文字 or 小文字に変換する

List<String> list = List.of("java", "Spring", "HELLO");

List<String> upper = list.stream()
        .map(String::toUpperCase)
        .collect(Collectors.toList());

List<String> lower = list.stream()
        .map(String::toLowerCase)
        .collect(Collectors.toList());

List<String> list = List.of("java", "Spring", "HELLO");

List<String> upper = list.stream()

.map(String::toUpperCase)

.collect(Collectors.toList());

List<String> lower = list.stream()

.map(String::toLowerCase)

.collect(Collectors.toList());

3. 特定の文字を含む要素だけ抽出する

List<String> list = List.of("apple", "orange", "banana");

List<String> containsA = list.stream()
        .filter(s -> s.contains("a"))
        .collect(Collectors.toList());

// 結果: [apple, orange, banana]

List<String> list = List.of("apple", "orange", "banana");

List<String> containsA = list.stream()

.filter(s -> s.contains("a"))

.collect(Collectors.toList());

// 結果: [apple, orange, banana]

部分一致の他に、
startsWith / endsWith / 正規表現なども活用できます。

4. trim＋フィルタ＋整形をまとめて 1 行で

業務コードで頻発する「整形 → フィルタ → 出力」を 1 行で書く例です。

List<String> raw = List.of("  ABC  ", " 123 ", " xyz ", "", "  ");

List<String> normalized = raw.stream()
        .map(String::trim)
        .filter(s -> !s.isEmpty())
        .map(String::toLowerCase)
        .collect(Collectors.toList());
// -> [abc, 123, xyz]

List<String> raw = List.of(" ABC ", " 123 ", " xyz ", "", " ");

List<String> normalized = raw.stream()

.map(String::trim)

.filter(s -> !s.isEmpty())

.map(String::toLowerCase)

.collect(Collectors.toList());

// -> [abc, 123, xyz]

5. 重複要素を除外する（distinct）

6. 文字列リストを区切り文字で join する（CSV など）

改行やタブ区切りにも応用できます。

7. リスト内の文字列長でソートする（Comparator）

List<String> list = List.of("aaa", "b", "cccc");

List<String> sorted = list.stream()
        .sorted(Comparator.comparingInt(String::length))
        .collect(Collectors.toList());

// -> [b, aaa, cccc]

List<String> list = List.of("aaa", "b", "cccc");

List<String> sorted = list.stream()

.sorted(Comparator.comparingInt(String::length))

.collect(Collectors.toList());

// -> [b, aaa, cccc]

降順にしたい場合：

8. 正規表現で加工する（replaceAll 等）

List<String> phones = List.of("090-1234-5678", "03-9999-8888");

List<String> normalized = phones.stream()
        .map(s -> s.replaceAll("-", "")) // ハイフン除去
        .collect(Collectors.toList());

// -> ["09012345678", "0399998888"]

List<String> phones = List.of("090-1234-5678", "03-9999-8888");

List<String> normalized = phones.stream()

.map(s -> s.replaceAll("-", "")) // ハイフン除去

.collect(Collectors.toList());

// -> ["09012345678", "0399998888"]

9. Stream API を使うメリットまとめ

✔ コードが短く読みやすい

for文で数十行になる処理が、Stream だと数行に。

✔ null などの例外ケースを潰しやすい

filter → map → collect の流れが明確で安全。

✔ 並列処理（parallelStream）にも切り替えやすい

データ量が多い場合に性能改善も期待できる。

まとめ

Stream API を使うと、文字列リストの加工・整形が圧倒的にシンプルになります。

null / 空白除去
大文字・小文字変換
条件フィルタ
重複削除
join で CSV 形式へ変換
ソート

これらは業務アプリで頻出するため、覚えておくとコード品質・保守性が確実に上がります。

Oracle, データベース, トラブル対応, ブログ

ORA-12541の原因と対処法｜「TNS: リスナーがありません。」エラーを最速で解決する方法

2025年11月13日管理者コメントする

Oracle接続時に突然出る ORA-12541: TNS: リスナーがありません。
現場でも頻出するエラーの1つで、接続テストが通らない・アプリがDBに繋がらないなどのトラブルを引き起こします。

この記事では、最速で復旧するためのチェック手順 → 原因の深掘り → 正しい対処法をわかりやすくまとめます。

結論：ほとんどは「リスナーが動いていない or 設定が不一致」

ORA-12541 は、Oracle に接続する際の窓口である Listener（リスナー） が見つからない時に発生します。

主な原因は以下のどれかです。

リスナーサービスが停止している
listener.ora のホスト名／ポート構成が間違っている
tnsnames.ora のHOST/IPが一致していない
ファイアウォールで1521ポートが遮断
サーバIPの変更後に設定未修正（Windows/VM/クラウドで多い）

では最速で治すチェック順を紹介します。

1. 最速で直す！ORA-12541のチェック手順（5ステップ）

① リスナーサービスが停止していないか確認

Windows

サービス → OracleOraDB…TNSListener を確認
停止していたら「開始」を押す。

で状態が確認できます。

Linux

TNS-12541: TNS:no listener が返った場合はリスナーが死んでいます。

② リスナーを再起動する

Windows / Linux 共通

成功すればほとんどのケースはこれで復旧します。

③ listener.ora のHOST/IPが本当に正しいか確認

リスナーが動いていても、設定されているホスト名が正しくないとリスナーは動作しません。

例：ホスト名変更後に listener.ora を更新していないケース

が myserver01 なのに一致していない → ORA-12541

IPアドレス変更後に放置している場合も同じです。

④ tnsnames.ora の接続先HOST/IPが一致しているか

クライアント側の設定が間違っていると当然繋がりません。

→ listener.ora 側と一致しているか要確認。

⑤ ポート（1521）がファイアウォールで塞がれていないか

Windows Firewall
Linux firewalld
クラウド（AWS SecurityGroup、Azure NSG など）

で 1521 が閉じていると ORA-12541 になります。

2. ORA-12541 が発生する代表的な原因まとめ

✔ リスナーが起動していない（最も多い）

DBサーバの再起動後に自動で上がっていない、手動停止したなど。

✔ listener.ora と tnsnames.ora の不整合

HOST名が一致していない
PORTが違う
サービス名（SERVICE_NAME）が間違い

設定変更後の再起動忘れもよくあります。

✔ DNS・ホスト名解決の問題

ホスト名を指定しているが DNS で解決できないケース。
→ IPアドレス直書きで繋がれば DNS が原因。

✔ VM・クラウドのIP変更

Oracle XE や開発環境で特に多い事例。
IPが変わったのに listener.ora を更新していないパターン。

3. 対処法まとめ（状況別）

🔧 ① リスナー停止が原因 → 再起動でOK

🔧 ② listener.ora の設定ミス → 修正 → リスナー再起動

ファイル場所

Windows: C:\oracle\product\...\network\admin\listener.ora
Linux: $ORACLE_HOME/network/admin/listener.ora

🔧 ③ tnsnames.oraが間違い → 修正

接続文字列を見直して、listener.ora と整合性を取る。

🔧 ④ ポート塞ぎ → FWで1521を許可

クラウド環境では SecurityGroup / NSG も要確認。

🔧 ⑤ DNS問題 → HOST をIPに変更する

接続先を一時的にIPにすると原因切り分けになる。

4. 再発防止のためのポイント

サーバ再起動後の リスナー自動起動設定を確認
listener.ora／tnsnames.ora の バックアップ運用
接続情報を IP指定 に統一する（開発環境向け）
FW設定変更の履歴をチームで共有

5. まとめ

ORA-12541「TNS:リスナーがありません。」 は、
リスナーが動いていない or 設定不一致が原因の9割です。

✔ 最速で確認すべきは以下の5つ

lsnrctl status
リスナーサービスの起動確認
listener.ora のHOST/IP
tnsnames.ora の整合性
ポート1521の開放

HULFT, Web開発, ブログ

HULFTの転送速度を理論値で算出する方法：単独転送と間欠転送で何が変わる？

2025年11月13日管理者コメントする

HULFTで大容量ファイルを送信する際、
「単独転送と間欠転送では速度がどれくらい違うのか？」
と気になる場面は多いはずです。

特に、S3送信やネットワーク負荷対策で間欠転送を設定した場合、
「どれだけ転送時間が増えるのか？」を事前に把握しておきたいところです。

本記事では、HULFTの転送処理を理論値（数式）で算出する方法をわかりやすく解説します。

1. HULFT転送の基本：ブロック単位で送られる

HULFTはファイルをそのまま送るのではなく、
一定サイズ（ブロック長）に分割してブロック単位で送信します。

例えばブロック長を 16KB に設定している場合：

1ブロック = 16KB
1MBのファイルなら 1,048,576 ÷ 16,384 ≒ 64ブロック

という計算になります。

この「ブロック数 × ブロックあたりの処理時間」が転送時間に大きく影響します。

2. 単独転送の理論値：最速で送るシンプルな動作

単独転送（=間欠転送なし）は、
ブロックを休まず連続で送っていく動作です。

■ 単独転送の理論値計算式

※実効転送速度（Throughput）はネットワーク・HULFTヘッダなどのオーバーヘッドを含む実測値。

■ 例：500MBのファイルを100Mbpsで送信する場合

理論上は40秒となります。

実際にはHULFTヘッダ分のオーバーヘッドで数秒増える程度。

3. 間欠転送の理論値：休止時間の積み重ねで大幅に遅くなる

間欠転送は、各ブロック送信後に**休止時間（インターバル）**が入ります。

HULFTの設定例：

ブロック長：16KB
ブロック回数：100回
休止時間：30ms

■ 間欠転送の理論計算式

ここが最も重要なポイント。

ブロックが多い場合、休止時間が膨れ上がります。

4. 実例：500MBファイルを間欠転送で送るとどうなる？

★ 前提

ブロック長：16KB
500MB = 32,768ブロック
単独転送時間：40秒（前述）
休止時間：20ms

■ 間欠転送の追加時間

■ 合計転送時間

→ 実際の現場でも「間欠転送は数倍遅くなる」理由はここにある

ブロック数 × 休止時間 → これが爆発的に効いてくるためです。

5. 実効転送速度（Throughput）の簡易算出方法

実測値を1回取るだけで、理論値がもっと正確になります。

■ 実測からの計算式

例えば

100MBのファイル
送信実測15秒
→ 実効速度 = 100MB ÷ 15 = 6.6MB/s（53Mbps）

これを単独転送の基準値にすることで、
間欠転送の予測精度が向上します。

6. 間欠転送の「適切な使いどころ」

間欠転送は遅くなるため万能ではありませんが、
以下の目的では効果的です。

S3/クラウド側で転送速度制限がある場合
受信側の負荷分散が必要な場合
夜間バッチでNW帯域を食いすぎるのを避けたい時
他システムの処理性能に合わせたいケース

速度ではなく安定性や負荷分散を目的に使うのが本来の用途。

7. 間欠転送設定によるエラー（S3Timeout など）について

休止時間を入れると、
1ブロックあたりの処理が遅くなる → 全体が長くなる → タイムアウトに近づく
という問題があります。

特にS3送信では

S3Timeout（約60秒）
NW機器の制限
プロキシのタイムアウト

などに引っかかるケースが多い。

✔ 大容量ファイルほど間欠転送はリスクが高い

500MB・1GB級のファイルではブロック数が膨大になるため、
一気にタイムアウト領域に入ります。

まとめ

項目	単独転送	間欠転送
速度	最速	休止時間分だけ遅い
仕組み	ブロックを連続送信	ブロック送信→休止の繰り返し
理論値算出	単独転送時間のみ	単独転送＋(ブロック数×休止時間)
メリット	最速で送れる	負荷を抑え安定性を上げる
デメリット	帯域を多く使う	極端に遅く、タイムアウトを誘発

HULFT, トラブル対応, ブログ

HULFT「間欠転送あり」と「なし」で何が変わる？S3送信で発生するエラーの原因と対策

2025年11月12日管理者コメントする

💡 はじめに

HULFTでS3（クラウドストレージ）へファイルを送信する際、「間欠転送」という設定があります。
この機能は通信の安定化を目的としたものですが、実際には設定値によって転送が失敗したり、タイムアウトを引き起こすケースもあります。

この記事では、「間欠転送あり」と「間欠転送なし」で何がどう変わるのか、そしてS3送信でエラーが起こる原因と具体的な対策を整理します。

🔹 間欠転送とは？

間欠転送は、大きなファイルを一定サイズごとに区切って、間隔を空けながら送信する仕組みです。

通常転送が「連続的なデータストリーム」なのに対し、間欠転送は次のような動きになります。

この「16KB」は、転送ブロック長（4KB）×ブロック数（4） の場合の動作例です。

🔹 通常転送との違い

項目	通常転送（間欠なし）	間欠転送（あり）
仕組み	ファイルを連続して送信	小分けして間隔ごとに送信
メリット	高速・設定不要	通信の途切れを防げる（S3Timeout対策）
デメリット	長時間通信で切断される可能性あり	設定次第で速度低下・不安定化する
想定環境	LAN・オンプレ間など安定回線	WAN・VPN・S3などクラウド宛て

🔹 なぜS3で間欠転送が重要なのか

S3ストレージオプションは、HULFT内部で HTTP(S)通信 を使用しています。
この通信は、一定時間データの送受信が行われないと「タイムアウト扱い」となり、セッションが切断されます。

そのため、定期的に通信を行う間欠転送を使うことで、S3側が「接続が生きている」と判断しやすくなり、転送が安定します。

⚠ S3送信でエラーになる原因

間欠転送なしで送信してエラーになる場合、間欠転送にすることでエラー解消する場合もあります。

ところが、実際には「間欠転送をONにしたら逆に転送が失敗した」という報告も少なくありません。
主な原因は以下の通りです。

原因	内容	対応策
① 設定値が極端（間隔0msやブロック1など）	通信制御が細かすぎて不安定になる	ブロック長4KB／ブロック数4／間隔20〜30msへ修正
② S3Timeoutが短い	デフォルトの60秒では間欠の待機中に切断される	hulft_s3.confに S3Timeout=120 以上を設定
③ 送信側と受信側の間欠設定が不一致	双方で動作パターンが異なりセッションが破綻	同一設定で統一する
④ ファイルサイズと設定バランスが悪い	大容量（数百MB）で間隔が長いと時間切れ	間隔を短く・ブロックを大きく調整
⑤ ウイルス対策やVPN干渉	小刻み通信が検査対象になり応答が遅延	除外設定または専用ポート経由に変更

🧭 S3送信における安定化の推奨設定

設定項目	推奨値	解説
転送ブロック長	4096 bytes（4KB）	標準的でメモリ効率が良い
転送ブロック数	4	16KB単位で通信制御が安定
転送間隔	20〜30ms	応答を維持しながら速度低下を抑制
S3Timeout	120〜180秒	デフォルト60秒では短すぎる
終了コード（RC）	RC=0が正常、RC=8以上は異常	メッセージではなくRCで結果を判定

この設定であれば、150〜350MBクラスのファイルを3〜9分程度で安定して送信できます。

🧱 間欠転送が逆効果になるケース

LAN内やオンプレ同士など、もともと通信が安定している環境では、間欠転送を入れることで逆にCPU待ちや余計な遅延を生むことがあります。
そのため、以下のように使い分けるのがベストです。

環境	推奨設定
社内LAN・閉域網	間欠転送なし（高速重視）
S3・WAN・VPN	間欠転送あり（安定性重視）

🧩 トラブルシューティングの手順

間欠転送をOFFに戻して再送信
　→ 正常に送信できるか確認して比較ベースを作る。
ONにした状態でログを確認
　→ 通信エラー・再送メッセージなどを確認。
設定を微調整（間隔20→30msなど）
　→ エラー頻度が下がるかを検証。
S3Timeoutを延長
　→ hulft_s3.conf に S3Timeout=180 を追記。
VPN・FW・ウイルス対策干渉をチェック
　→ 小刻み通信の検査を除外する設定を追加。

🧠 まとめ

間欠転送は「S3など不安定回線向けの安定化機能」。
ただし設定値を誤ると、通常転送より不安定になる。
4KB×4ブロック・20〜30ms間隔・S3Timeout120秒以上が実運用で最も安定。
ジョブの成否は**終了コード（RC）**で判定し、メッセージ内容は原因分析に利用する。

■ trim() は万能ではない：取り除けない空白がある

▼ trim()で削除できる例

▼ trim()で削除できない代表例

■ 前後の空白を「完全に」除去する方法

① 正規表現による空白除去（最も汎用的）

▼ ポイント

■ ② Apache Commons Langの StringUtils を使う方法（簡単）

▼ trim()との違い

■ ③ カスタム実装で「ホワイトリスト方式」

■ 比較表：どの方法を使うべき？（実務ベース）

■ 実務で多いトラブル例

● CSVインポート時に項目が一致しない

● 外部システムのレスポンス整形で意図せず不一致

● Webフォームの入力チェックで正しく弾けない

■ まとめ：trim() だけに頼らないこと！

関連記事

■ ORA-03113とは？

■ ORA-03113 が発生する主な原因

1. Oracle インスタンスがクラッシュ / 強制停止した

▼確認ポイント

2. ネットワークの不安定化・切断

▼確認ポイント

3. タイムアウト設定（SQLNET.ORA / Firewall）の影響

▼対策例

4. クライアントアプリ側の異常終了

▼確認ポイント

5. SQL の実行中にサーバリソースが枯渇

▼確認ポイント

■ ORA-03113 が出たときの切り分け手順（最速版）

【1】alert.log を確認

【2】trace ファイル（*.trc）を確認する

【3】ネットワーク切断の有無を確認

【4】同時刻に OS イベントが発生していないか

【5】クライアント側のログ確認（アプリ含む）

■ よくあるパターン別の対策

● ケース1：長時間SQLで毎回切断される

▼対処

● ケース2：大量データ処理バッチで発生

▼対処

● ケース3：インスタンスが落ちた

▼対処

■ まとめ（結論）

関連記事

1. 最初に確認すべきは「エラーコード」

● STOP コードの確認方法

2. イベントビューアで詳細ログを確認する

● 確認手順

3. ドライバ更新状況を確認する

● 更新・再インストール手順

4. メモリ（RAM）のテストを行う

● Windows メモリ診断

5. ストレージ（SSD/HDD）の状態チェック

● チェック方法

6. Windows Update の不具合を疑う

● 対処

7. 最近インストールしたアプリを確認する

8. 省電力設定/オーバークロックの影響

9. システムファイルの破損チェック

● コマンド例

10. 再発防止のための最終手段

まとめ

関連記事

✔ なぜPowerShellはCSV処理が遅くなるのか

✔ 高速化のポイントは「逐次読み込み」と「Stream処理」

💡 高速化の基本

✔ ベストプラクティス①：StreamReaderで逐次処理

✔ 特徴

✔ ベストプラクティス②：Import-Csv を使う場合の高速化

✔ 注意点

✔ ベストプラクティス③：Select-Object / Where-Object を避ける

💡 改善

✔ ベストプラクティス④：StringBuilderで出力バッファを作る

✔ StringBuilderを使う（高速）

✔ ベストプラクティス⑤：PowerShell 7 を使う

理由

✔ 実際の処理速度比較（目安）

✔ まとめ：最速は「StreamReader＋Splitによる逐次処理」

✔ 最適解

関連記事

■ 1. セルの書式が「文字列」になっている

　関連記事

　関連記事

　関連記事

　関連記事

　関連記事

　関連記事

　関連記事