管理者 のすべての投稿

PowerShellのバージョンはどこで確認できる?コマンド一覧と違いを解説

PowerShellでは、環境によって利用できるコマンドや機能が異なるため、自分のPowerShellが何バージョンなのかを正確に把握することは非常に重要です。
特に、**Windows PowerShell(5.1)PowerShell 7(PowerShell Core)**は内部構造が異なるため、確認方法を知らないと混乱しがちです。

この記事では、

  • PowerShellのバージョン確認方法の一覧

  • Windows PowerShell と PowerShell 7 の違い

  • どの方法で確認するのがベストか
    をわかりやすく解説します。


✅ まず結論:最も確実なバージョン確認方法

PowerShellのバージョンを確認する最も確実なコマンドは以下です。

実行すると、メジャーバージョンやクライアント情報が一覧で表示されます。


1. PowerShellのバージョン確認方法(コマンド一覧)

ここでは、実務で必ず使うコマンドを重要度順に解説します。


$PSVersionTable(基本&最重要)

表示される主な項目:

項目説明
PSVersionPowerShellのメジャー/マイナーバージョン
PSEditionDesktop(Windows PowerShell) / Core(PowerShell 6/7)
GitCommitIdPowerShell Core でのビルド情報
OS実行しているOS情報
PlatformWin32NT / Unix

もっとも正確な情報が得られ、Windows PowerShell と PowerShell 7 の判別も可能です。


Get-Host を使う方法(ホストアプリ情報)

Get-Host

HostVersion の欄にバージョンが出ます。

ただし、PowerShell ISE や Visual Studio Code など ホストアプリによって値が変わる場合があるため、バージョン判定としては不正確 です。

基本的には $PSVersionTable の方が推奨。


$Host.Version の省略形

Get-Host のバージョンだけを直接取り出す書き方です。
こちらもあくまで ホストアプリのバージョンなので注意。


■ PowerShell 7 以上限定:pwsh -v

PowerShell 7 を使用している場合のみ利用できます。

Windows PowerShell(5.1)では動作しません。


■ コンソールのタイトルバーで確認(GUI的な方法)

PowerShellを起動したとき、タイトルバーに次のような表示が出る場合があります。

  • Windows PowerShell 5.1

  • PowerShell 7.4.0

ただし環境によって表示が異なるため、確実ではない方法です。


2. Windows PowerShell(5.1)と PowerShell 7 の違い

PowerShellのバージョン確認が重要な理由は、5.1 と 7 系で仕様が大きく異なるためです。


【比較表】Windows PowerShell と PowerShell 7 の主な違い

項目Windows PowerShell 5.1PowerShell 7.x
実行ファイルpowershell.exepwsh.exe
基盤.NET Framework.NET 6/7(Core)
対応OSWindowsのみWindows / macOS / Linux
コマンドの互換性高い一部非互換あり
モジュール古いWindows専用モジュールが多い新世代のPowerShell向け

特に、

  • HULFTのスクリプト

  • ActiveDirectoryモジュール

  • Windows専用モジュール

などを扱う場合は、5.1でないと動かないケースが多いため注意が必要です。


3. どの確認方法を使えばいい?(実務向けまとめ)

目的推奨コマンド
バージョンの正確な取得$PSVersionTable
Core か Desktop か判断$PSVersionTable.PSEdition
PowerShell 7 かだけを確認pwsh -v(PowerShell 7の場合)
ホスト環境の確認Get-Host

4. よくある質問(FAQ)


■ Q. 自分のPCに PowerShell 5.1 と 7 が両方入っているのは普通?

はい、普通です。
Windows標準は5.1で、最新版の7は別途インストールされます。


■ Q. どちらを使うべき?

  • Windows管理タスクが多い
     → Windows PowerShell(5.1)

  • クロスプラットフォーム / 最新のPowerShellを使いたい
     → PowerShell 7


■ Q. PowerShellのバージョンアップはどうする?

PowerShell 7 は winget でアップデート可能。


まとめ

PowerShellのバージョン確認は、環境差異によるトラブルを避けるための最重要ポイントです。

🔍 今日覚えておくべき3つ:

  1. 基本は $PSVersionTable を使う

  2. PowerShell 5.1 と 7 では機能が大きく異なる

  3. 用途に応じて使うバージョンを選ぶ

この知識があれば、スクリプト実行時の「動かない…なぜ?」を大幅に減らせます。

【Oracle】ORA-01013:ユーザーによる処理中断エラーの原因と対処法まとめ

ORA-01013(user requested cancel of current operation) は、
OracleでSQL実行中に処理が強制的に中断された場合に発生するエラーです。

エラーメッセージだけ見ると「ユーザーがキャンセルした」と書かれているため、
本当にユーザー操作なのか?アプリ側なのか?タイムアウトなのか?
原因切り分けで迷うケースが非常に多いエラーの一つです。

この記事では、実務でよく遭遇する原因から、確実に再発防止するための対処法までをわかりやすくまとめます。


ORA-01013とは何か?

Oracleの公式エラーメッセージは以下の通りです。

直訳すると「ユーザーが現在の処理をキャンセルした」という意味ですが、
実際にはユーザー自身がキャンセル操作をしていない場合も多く、
アプリケーションのタイムアウトやセッション切断などでも発生します。


✔ よくある原因まとめ(実務で多い順)

1. アプリケーション側のタイムアウト(最も多い)

  • Webアプリ・バッチ・APIがタイムアウトを設定しており、SQLが完了前に切られる

  • Javaなら JDBCのQueryTimeout、Webアプリなら APサーバのタイムアウト

  • 接続プール(HikariCP / UCP など)のタイムアウト設定

→ アプリが先に処理を中断 → Oracle側がORA-01013を返す


2. ツール側操作による中断(DBeaver / SQL Developer など)

  • ユーザーが「停止」ボタンを押す

  • SQLの実行画面を閉じる

  • ツール側で内部的にキャンセルが走る場合もある


3. ネットワーク切断・セッション切れ

  • VPNの瞬断

  • APサーバ〜DB間のコネクションが短時間切断

  • F/W・LB のアイドルタイムアウト

→ セッションが切れる → Oracleがユーザーキャンセル扱いになる


4. プロファイルでのリソース制限(CPU_PER_CALLなど)

DB側のプロファイル設定で

  • CPU時間の上限(CPU_PER_CALL)

  • IDLE_TIME(アイドル時間)
    などが上限を超えると、Oracleがセッションを終了しORA-01013となる場合があります。


5. 長時間処理の実行中にバッチが落ちた・APが強制終了した

アプリ側が異常終了することで、結果的にキャンセルが発生します。


✔ 原因別の対処法まとめ

▼ 1. アプリ側タイムアウトが原因の場合

アプリ設定を確認します。

Java(JDBC)の例:

HikariCP:

対処ポイント

  • タイムアウト値を適切に引き上げる

  • 重いSQLを見直す(インデックス・実行計画)

  • バッチ処理なら分割実行を検討


▼ 2. SQLツールが原因の場合

  • 停止ボタンを誤って押してないか

  • 大量データを返すクエリを実行してないか

  • ツールのメモリ不足・内部エラーを疑う

DBeaverの設定でフェッチ行数制限を緩和すると改善されることもあります。


▼ 3. ネットワーク切断が原因の場合

  • APサーバとDBの間にVPNやFWが挟まっていないか

  • アイデルタイムアウト設定の見直し

  • 回線品質のログを確認(Ping監視など)

ネットワークの瞬断は意外と多く、企業ネットワークだと特に発生しやすいポイントです。


▼ 4. プロファイル(リソース制限)が原因の場合

以下のプロファイルを確認します。

制限が厳しすぎる場合は緩和します。


▼ 5. 長時間SQLが原因の場合(インデックス・実行計画の見直し)

  • インデックス劣化

  • 統計情報の古さ

  • 不必要な全表走査

  • JOIN順序

SQLが遅すぎてアプリタイムアウト → ORA-01013 に繋がる典型パターンです。


✔ 再発を確実に防ぐためのチェックリスト

  • アプリのタイムアウト設定は妥当か?

  • ネットワークに瞬断がないか?

  • バッチ・ETL処理が重すぎないか?

  • 実行計画を確認したか?索引は効いているか?

  • プロファイル制限が厳しすぎないか?

  • SQLツールの操作ミスはないか?


まとめ

ORA-01013は「ユーザーがキャンセルした」だけではなく、
アプリ側のタイムアウトやネットワークの瞬断など、多くの原因で発生します。

特に実務では

① SQLが重すぎてアプリ側タイムアウト → ORA-01013

というパターンが多いため、
SQL改善+アプリ設定の見直しが最も効果的です。

SQL:DELETEが異常に遅い原因と対処法まとめ|大量データで固まる時のチェックポイント

大量データを扱うシステムでは、
「DELETE文が異常に遅い」「1000件削除するだけで何分もかかる」
という現象は珍しくありません。

実際、筆者の環境でも

  • 1500万件のテーブル

  • DELETE 1件 = 約1.2秒

  • DELETE 100件 = 約2分

  • DELETE 1000件 = 約20分

という、明らかに正常とは言えない状態に遭遇しました。

この記事では、
SQL(特にOracle)で DELETEが異常に遅くなる原因と対処法
現場目線でわかりやすくまとめます。


1. DELETEが遅い原因は「処理そのものが重い」から

SELECTは一瞬で返るのに、DELETEだけ異様に遅い。
これは DELETE内部の処理コストが非常に重い ためです。

DELETEが行うことは主に以下:

  1. 対象行の削除(表領域から除去)

  2. インデックスから該当エントリの削除

  3. Undoログの生成

  4. Redoログの生成

  5. ロック管理

  6. トリガー処理(あれば)

このどれか、あるいは複数が詰まると
DELETEは1件ずつ遅くなり、数百件〜数千件だと“永遠に終わらない”状態になります。


2. DELETEが異常に遅いときの主な原因

2-1. インデックスの断片化・肥大化(最も多い)

大量INSERT / DELETE / UPDATE を繰り返したテーブルは
インデックスが “B-tree破損状態” になります。

症状:

  • DELETE 1件 = 1秒以上

  • 100件DELETEでも数分

  • SELECTは速い(インデックス検索は生きている)

これはインデックス劣化の典型。

→ インデックス再構築で劇的に改善することがあります。


2-2. Undo / Redo の処理が追いつかない

大量DELETEを連続してキャンセルすると

  • Undoセグメント肥大

  • Redoログ切替待ち

  • I/Oスラッシング

  • Undo segment extension 待ち

などが発生し、DELETEが異常に遅くなります。


2-3. 外部キー参照(子テーブル)が存在する

DELETEのたびに

  • 子テーブルを参照

  • 存在チェック

  • 参照整合性確認

を行うため、対象行が多いと極端に遅くなります。

※子テーブルを先に削除済なら影響なし。


2-4. トリガーが動いている

DELETEトリガーがあると
行ごとに処理が実行されるため、100行DELETEで100回 トリガーが動きます。

トリガー内でINSERT/UPDATEが走っていると、一気に重くなります。


2-5. テーブルやインデックスの断片化

特に1500万件級の大規模テーブルでは
断片化やI/O劣化によって DELETE が遅くなります。


2-6. ロックではない(SELECT が速ければ別原因)

「DELETEが遅い=ロック」と思われがちですが、
SELECTが瞬時に返るならロックではないことが多いです。

DELETE固有の処理が遅い証拠です。


3. DELETEが遅いときのチェックポイント(すぐ実行できる)

✔ ① SELECT COUNT は速い?

→ 速いならロックではない。

✔ ② 1件DELETEの時間を計測

→ 1秒以上かかるならインデックス劣化 or Undo詰まり。

✔ ③ インデックス数は多すぎない?

✔ ④ トリガーが無いか?

✔ ⑤ 子テーブルの外部キーは?

これだけでも原因の大半は特定できます。


4. 対策まとめ(実務で使える)

4-1. インデックス再構築(効果大)

DBA権限が必要ですが、再構築すると劇的に速くなります。


4-2. 統計情報の更新


4-3. 子テーブルを先に削除 or 一時的に外部キー無効化


4-4. トリガーの見直し / 一時無効化


4-5. DELETEを小分け(100件単位)で実行

大量DELETEは一度にやるのではなく
100件 or 1000件ごとに分割してCOMMITする方が安全。

※筆者環境では
100件DELETE = 約2分
1000件DELETE = 約20分
でした。


4-6. 一番速いのは「論理削除」

物理削除できないなら DELETE_FLG を立てる方法が最も安全。

これは DELETE より圧倒的に軽いです。


4-7. 本当に大量削除するなら「CTAS」が最強

残すデータだけ別テーブルにコピーして入れ替える方法。

DELETEより何倍も速いです。


5. まとめ

DELETEは単純なSQLに見えますが、
内部的には

  • インデックス更新

  • Undo/Redo 生成

  • ロック管理

  • 外部キー参照

  • トリガー処理

など多くの処理が絡むため
大量データでは極端に遅くなることがあります。

特に大規模テーブル(1000万件以上)だと
1件 DELETE でも1秒以上かかることが普通にあります。

もし DELETE が遅くて固まる場合は、

  1. SELECT が速いか確認

  2. 1件DELETEの時間を計測

  3. インデックス・Undo/Redo・トリガーを疑う

  4. 小分けDELETE or 論理削除に切り替える

  5. 必要に応じてDBAにインデックス再構築を依頼

といったステップで原因を切り分けると
安全で確実に改善できます。

【NordVPNが接続できない】原因と解決方法まとめ|Windows / iPhone / Android対応

NordVPNはアクセス速度が速く、セキュリティ面でも非常に優秀なVPNサービスです。しかし、まれに「接続できない」「接続はされているのに通信できない」というトラブルが発生することがあります。

本記事では Windows / iPhone / Android のデバイス別に、NordVPNが接続できないときの原因と対処方法をわかりやすくまとめています。
初心者でもすぐ試せる手順を中心に掲載しているので、ぜひ順番に確認してみてください。


1. よくある原因まとめ(全デバイス共通)

まずは、デバイスに関係なく起こりやすい原因をまとめます。

✔ インターネット回線が不安定

Wi-Fiが不安定、ONU/ルーターの不調、モバイル回線の接続性低下など。

✔ NordVPNアプリのバージョンが古い

更新していないアプリは接続エラーを引き起こしやすい。

✔ ログイン情報の不整合

サーバ側と認証がズレて接続拒否になるケース。

✔ 接続先サーバーの障害

特定の国・地域のサーバーだけ接続しにくい場合も。

✔ ファイアウォールやセキュリティソフトによる遮断

Windows Defender / Norton / ESET など。

✔ プロトコル(NordLynx / OpenVPN)の不一致

環境によって接続できないプロトコルがある。

まずはこれらを1つずつ切り分けていきます。


2. 【Windows編】NordVPNが接続できないときの対処法

Windowsで接続できない場合は、次の順で確認すると解決しやすいです。


2-1. NordVPNアプリを再起動する

タスクトレイ → NordVPN を右クリック → 「Quit」→ 再起動
キャッシュの不整合が解消します。


2-2. PCを再起動する

一時的なネットワーク障害がクリアされます。


2-3. 別サーバーに接続する

日本サーバーが混雑している場合あり。

  • Japan #54

  • Singapore #23

  • USA(West Coast)

など、近場〜中距離サーバーを順に試すと成功率が上がります。


2-4. プロトコルを変更する

  1. NordVPNアプリ右上 → Settings

  2. Connection → VPN Protocol

  3. NordLynx / OpenVPN(TCP/UDP) を切り替える

NordLynx → OpenVPN UDP に変更すると改善することが多いです。


2-5. Windows Defender ファイアウォール例外を追加

手順

  1. コントロールパネル

  2. 「Windows Defender ファイアウォール」

  3. 「アプリまたは機能を許可する」

  4. NordVPN.exe にチェックを入れる

企業ネットワークの場合、管理者側でVPN接続を制御しているケースがあります。


2-6. TAPアダプターを再インストール(OpenVPN使用時)

  1. デバイスマネージャー

  2. 「ネットワークアダプター」

  3. TAP-NordVPN Windows Adapter を削除

  4. NordVPNを再インストール

破損したアダプタが原因の場合に有効。


3. 【iPhone編】NordVPNが接続できないときの対処法

iOSでは以下がよくある原因です。


3-1. Wi-Fiを一度OFF→ON

ネットワーク再取得で改善するケースが多い。


3-2. 低電力モードをOFFにする

低電力モード中はVPN接続が不安定になることがあります。

設定 → バッテリー → 低電力モードをOFF


3-3. VPN構成プロファイルを削除して再作成

  1. 設定

  2. 一般

  3. VPNとデバイス管理

  4. NordVPNプロファイルを削除

  5. アプリを開くと再作成される

これが最も効果的な場合が多いです。


3-4. 別サーバーに接続する

iPhoneは特に「混雑サーバー」に弱い傾向あり。


3-5. iOSを最新版にアップデート

古いiOSだとVPNモジュールに不具合が出ることがある。


4. 【Android編】NordVPNが接続できないときの対処法

Androidは端末メーカーの最適化が影響する場合があります。


4-1. アプリのキャッシュをクリア

設定 → アプリ → NordVPN → ストレージ → キャッシュ削除


4-2. バッテリー最適化をOFF

Samsung / Xiaomi / Pixel などで多い症状。

  1. 設定

  2. アプリ

  3. NordVPN

  4. バッテリー

  5. 最適化しない


4-3. 分割トンネリング設定をOFF

アプリによってVPN抜けする設定が混在している可能性あり。


4-4. プロトコルを変更(特にOpenVPN → NordLynx)

AndroidはNordLynxが最安定。


5. 回線側の問題を疑うべきケース

VPNに繋がらないとき、実は回線側の障害が原因のこともあります。


✔ ルーターの負荷

再起動で解決することが多い。

✔ Wi-Fi 2.4GHz→5GHzに変更

混雑周波数帯だとVPN接続が落ちやすい。

✔ プロバイダのIPv6(DS-Lite / IPoE)が干渉

特定環境でVPNが接続しづらい場合あり。

✔ 公共Wi-FiでのVPN制限

ホテル、社内ネットワーク、飲食店などではVPN遮断が行われていることがある。


6. 最終手段:NordVPNアプリの再インストール

ここまで試してダメなら、アプリの再インストールが最も確実です。

  • Windows → 設定 → アプリ → NordVPN → アンインストール

  • iPhone / Android → アプリ削除 → 再インストール

多くのユーザーはこれで復旧します。


7. どうしても解消しない場合

✔ NordVPN側のサーバー障害

公式ステータス:https://nordvpn.com/ja/status/

✔ アカウント側のエラー

ログアウト → 再ログインを実施。

✔ 企業ネットワークによるVPNブロック

この場合、”Obfuscated servers(難読化サーバ)” を使うと突破できることも。


まとめ

NordVPNが接続できないときは、以下の順で確認すると最速で解決できます。

  1. アプリ再起動

  2. 別サーバーに接続

  3. プロトコル変更(NordLynx / OpenVPN)

  4. ファイアウォール設定

  5. 回線側の問題を確認

  6. プロファイル削除(iPhone)

  7. 再インストール

原因が特定できなくても、上記の手順を順番に試すことでほとんどのケースは解消できます。

SQL:半角 全角 変換 SQLだけで行う方法(Oracle / SQL Server / PostgreSQL)

SQLで半角 全角 変換 SQL を実行したい場面は、顧客データの正規化・文字種統一・基幹システム間のデータ連携などで非常に多く発生します。
カタカナ・英数字・記号などは半角/全角の表記ゆれが多く、SQLだけで統一できるとバッチ処理やETLの品質が向上します。

本記事では、Oracle・SQL Server・PostgreSQL・MySQLといった主要DBMSごとに
SQLだけで行う半角⇔全角変換の方法(半角 全角 変換 SQL) をまとめてわかりやすく解説します。


🟦 1. 半角 全角 変換 SQL が必要になる理由

半角/全角の違いは以下の問題を引き起こします。

  • 同じ文字でも別文字として扱われ、一致検索・JOINが失敗する

  • 顧客名・住所・カナ項目で表記ゆれが大量発生

  • 帳票やCSV出力の品質が揺れる

SQLで半角 全角 変換 SQL を実行して正規化 しておくと、後続処理が安定し、システム全体のデータ品質が高まります。


🟦 2. Oracleでの半角 全角 変換 SQL(CONVERT / TRANSLATE)

Oracleには完全な変換専用関数がありませんが、
CONVERTTRANSLATE の組み合わせで実現できます。


■ 2-1. 半角 → 全角(カナ)

Oracle独自の US7ASCII → JA16SJIS を使う裏技です。

※ 半角カナ → 全角カナに有効(英数字は別途処理)


■ 2-2. 半角 → 全角(英数字)


■ 2-3. 全角 → 半角

Oracleは全角→半角カナが標準で無いため、TRANSLATEでマッピングする必要があります。


🟩 3. SQL Serverでの半角 全角 変換 SQL(TRANSLATE)

SQL Server 2017以降は TRANSLATE が使用可能で、Oracleより簡単です。


■ 3-1. 半角 → 全角


■ 3-2. 全角 → 半角


🟧 4. PostgreSQLでの半角 全角 変換 SQL(translate関数)

PostgreSQLも Oracle / SQL Server と同様に translate() を使用します。


■ 4-1. 半角 → 全角


■ 4-2. 全角 → 半角


🟥 5. MySQLでの半角 全角 変換 SQL(REPLACE)

MySQLは専用関数がないため、REPLACE を多段適用します。


■ 5-1. 半角 → 全角(数字の例)

全変換を行う場合は、ストアド関数化が実務的です。


🟪 6. 実務で使える半角 全角 変換 SQL:関数化例(Oracle)


■ 半角 → 全角


■ 全角 → 半角


🧩 7. 半角 全角 変換 SQL を行う際の注意点

① 濁点・半濁点が合成文字として扱われる

例:パ = ハ + ゚

② DB文字コードで変換結果が異なる

Oracle(AL32UTF8 / JA16SJIS)では特に差が出やすい。

③ カナ変換はDBMSによって不得意

全角↔半角カナは、Oracleの CONVERT 技など固有の知識が必要。


✔ 結論:SQLだけで半角⇔全角変換は可能(ただしDB依存)

DBMS半角→全角全角→半角
OracleCONVERT + TRANSLATETRANSLATE(要マッピング)
SQL ServerTRANSLATETRANSLATE
PostgreSQLtranslate()translate()
MySQLREPLACEREPLACE

総じて SQLだけで半角 全角 変換 SQL を実現できる ものの、
DBMSごとに得意・不得意があるため、場面に応じて使い分けることが重要です。

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

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%除去 したいなら、

  1. 正規表現(\s + \p{Z})

  2. StringUtils.trim()

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

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

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

■ 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 のコネクションプール強制切断

▼対策例

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

  1. Oracle インスタンスの異常

  2. ネットワークの遮断

  3. タイムアウト設定の問題

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

  5. サーバリソース不足

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

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

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 の詳細をログに記録しています。

● 確認手順

  1. Win + X → イベントビューア

  2. 左のツリーから
    「Windows ログ」 → 「システム」 を選択

  3. 右側のフィルターで「重大」「エラー」を絞り込む

よくある記録:

  • Kernel-Power 41:予期しないシャットダウン

  • BugCheck:BSOD 発生のログ
    → エラーコード(BugCheckCode)やパラメータが確認できる


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

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

  • GPU ドライバ(NVIDIA / AMD / Intel)

  • オーディオドライバ

  • LAN / Wi-Fi ドライバ

  • ストレージドライバ(Intel RST など)

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

  • デバイスマネージャー → 該当デバイス → ドライバー → 更新

  • 公式サイトから最新版をダウンロードして入れ直すのも有効


4. メモリ(RAM)のテストを行う

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

● Windows メモリ診断

  1. Windows キー →「メモリ診断」検索

  2. 「今すぐ再起動して問題を確認する」

  3. 診断結果はイベントビューアの MemoryDiagnostics-Results に記録される

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


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

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

● チェック方法

  • **CrystalDiskInfo(無料)**で SSD の健康状態を見る

  • コマンドプロンプトで

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


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で数十万行のCSVを高速処理するベストプラクティス

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

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

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


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

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

  • 全行を一度にメモリへ展開する

  • オブジェクト化のコストが高い

  • 数十万件を超えると数百MB〜GB級のメモリ使用

という特徴があります。

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


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

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

💡 高速化の基本

  1. Import-Csv を使わず StreamReader を使う

  2. 1行ずつ処理して不要になったデータは捨てる

  3. Select-Object, Where-Object をループで使わない

  4. 型変換を最小限にする

  5. 出力は StringBuilder にまとめて最後に書き込む


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

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

✔ 特徴

  • Import-Csv ではなく Split で直接取得 → 超高速

  • メモリ使用量は常に一定

  • 数百万行でも余裕


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

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

✔ 注意点

  • ForEach-Object -ParallelPowerShell 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 -Parallel10〜40秒多め
StreamReader + Split5〜15秒数MB

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


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

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

✔ 最適解

  1. 逐次読み込み(ストリーム処理)

  2. 行ごとにSplitして必要な列だけ触る

  3. StringBuilderでまとめて出力する

  4. PowerShell 7 ならParallel化も可能

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

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

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

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

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


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

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

  • 「ホーム」→「数値」→「文字列」になっている

  • 左寄せになっている

  • 式で計算されない/SUMに反映されない

修正方法:

  1. セルを選択

  2. 書式を「標準」または「数値」に変更

  3. 必要であれば F2 → Enter で再確定


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

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

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

修正方法:

  • 「データ」→「区切り位置」→「完了」で再変換

  • または SUBSTITUTE で を除去


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

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

例:
12345
→ 全角のため文字列扱い。

判別方法:

  • 左寄せ

  • 書式を変更しても変わらない

  • LEN で長さが合わない

修正方法:

  • CLEAN、ASC関数

  • Power Query の「文字種変換」

  • 全角 → 半角変換ツールを使う


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

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

例:

修正方法:

  • TRIM(Tab のような特殊スペースは取れない場合あり)

  • CLEAN

  • Power Query →「空白の削除」


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

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

判別方法:
=CODE(MID(A1,1,1)) → 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・システム出力の文字列化)

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