Windows 11環境で「pgAdmin 4が起動しない」不具合について、その現象の具体例と、原因・対策を紹介します。

動作環境

• Windows 11 Pro 24H2
• PostgreSQL 17.6
• pgAdmin 4 ：Ver. 9.6　Python Ver. 3.13.6

第1位　「The pgAdmin 4 server could not be contacted」エラー

pgAdmin 4 起動時の現象

起動時にブラウザが開くが、上記エラー「The pgAdmin 4 server could not be contacted」が表示されて操作不能となる

原因

セッションファイルの破損、または前回の異常終了

対策

以下のようにRoamingフォルダ内の「pgAdmin」フォルダを削除する

Remove-Item "$env:APPDATA\pgAdmin" -Recurse -Force

又は、手動で削除

C:\Users\ユーザー名\AppData\Roaming\pgAdmin

再起動後、正常に起動するかどうかを確認する。

amzn.to

Bigme B6、カラー電子書籍リーダー、4GB+64GB 6インチ電子ペーパータ 、Android 14...

レビュー：ストレージ容量が増やせないKindleが不便で購入しました。SDも使えて、持っている本を全部ダウンロードしてオフラインでもいつでも読めるのは便利ですね。PlayBooksでも何冊か買っているので1つの端末で完結するのも便利です。

第2位　PostgreSQLサービスが停止している

pgAdmin 4 起動時の現象

pgAdminは起動するが、データベースに接続できない

原因

PostgreSQLサービスに異常があるため、pgAdminがサービスに接続できない。

対策

PostgreSQLサービスの存在とその状態（起動中か停止中）を確認する

確認方法（例）

# PostgreSQLサービスの存在と状態を確認
Get-Service | Where-Object { $_.Name -like "postgresql*" }

出力例

• サービスは存在しているが、起動していない場合

Status   Name               DisplayName
------   ----               -----------
Stopped  postgresql-x64-17  PostgreSQL 17

サービスが存在しない場合は、何も表示されません。

サービスが起動していない場合

サービスを起動する。
起動例：サービス名はPostgreSQLのバージョンによって異なるので注意

Start-Service -Name "postgresql-x64-17"

PostgreSQLが未インストールの場合

下記のコマンドでインストールするか、公式ダウンロードサイトからインストーラーをダウンロードしてインストールする。

New-Service -Name "postgresql-x64-17" -BinaryPathName "C:\Program Files\PostgreSQL\17\bin\pg_ctl.exe runservice" -DisplayName "PostgreSQL 17" -StartupType Automatic

サービス登録が失敗している場合

以下のようにサービスを登録する（パスは環境に応じて調整）

New-Service -Name "postgresql-x64-17" -BinaryPathName "C:\Program Files\PostgreSQL\17\bin\pg_ctl.exe runservice" -DisplayName "PostgreSQL 17" -StartupType Automatic

amzn.to

Amazon Kindle - 目に優しい、かさばらない、大きな画面で読みやすい

レビュー：初めてのKindleタブレット。サイズ選びに迷いましたが、軽くて持ち運びやすく、寝転んで読むのにも快適です。読書がますます楽しくなりこちらを選んで正解でした。

第3位　プロキシ設定がlocalost通信を妨害している

pgAdmin 4 起動時の現象

• ブラウザは開くが「The pgAdmin 4 server could not be contacted」と表示される
• 真っ白な画面のまま何も表示されない

原因

Windowsのプロキシ設定がlocalhost通信を外部に転送しようとして失敗する。

pgAdmin 4は、起動時にローカルHTTPサーバー（通常 http://127.0.0.1:5050）を立ち上げてUIを表示します。
しかし、Windowsのプロキシ設定が有効になっていると、localhostへの通信がプロキシ経由になり、pgAdminのローカルサーバーに接続できなくなることがあります。

• この問題が起こり易い環境
  • VPN接続中
  • 企業ネットワークでグローバルプロキシが強制されている
  • Windowsの「自動プロキシ検出」が有効になっている

対策

localhost通信をプロキシから除外する

• 環境変数 NO_PROXY を設定する（推奨）
  pgAdminの起動時にこの環境変数が設定されていれば、localhost通信がプロキシを経由せず直接処理されます。

PowerShellで設定（ユーザー環境変数：pgAdmin 4 再起動必要）

[System.Environment]::SetEnvironmentVariable("NO_PROXY", "127.0.0.1,localhost", "User")

コマンドプロンプトで設定（永続化：：pgAdmin 4 再起動必要）

setx NO_PROXY "127.0.0.1,localhost"

amzn.to

【Kindle (2024年発売・2022年発売) 用】Amazon純正 ファブリックカバー (マッチャ)

レビュー：純正の製品かそうでないものを購入するか迷いましたが、結論これで大満足でした。触り心地が良く、ピンクの発色もとても良いです。カバーの開閉で画面がオンオフされるなど機能性も全く問題ありません。女性にプレゼントしましたが、ケースに起因する重量感は特段感じなかったとのこと。ケースに迷っている方はマストバイの商品かと思います。

第4位　管理者権限で起動していない

pgAdmin 4 起動時の現象

起動はするが、設定変更や接続が反映されない。

原因

pgAdminは一部の操作に管理者権限が必要。

対策

ショートカットを右クリック → 「管理者として実行」。

• 常に管理者として実行する方法
  • ショートカットの「プロパティ」
  • 「互換性」タブ
  • 「管理者としてこのプログラムを実行」にチェック

amzn.to

【Android16 タブレット 11インチ 世界初登場】

価格が安いのでさほど期待はしていませんでしたが、画質は悪くないYouTube動画も問題なくみれます。ゲームはやらないので、普段使いなら十分な性能だと思います。また付属品が充実している点も購入ポイントでした。

第5位　pgAdminのバージョンが古い

pgAdmin 4 起動時の現象

Windows 11で起動しない、またはUIが崩れる。

原因

古いバージョンでは互換性に問題がある。

対策

最新版のpgAdmin 4をインストールする。

winget install --id=pgAdmin.pgAdmin4

コマンドの実行で
「入力条件に一致するパッケージが見つかりませんでした」が表示される場合

• 原因１
  リポジトリが不足している

リポジトリの確認とリセット。Powershellで以下のコマンドを実行

winget source list

winget と msstore の両方が表示されない場合は、以下のコマンドでリセットし、再度「winget source list」コマンドで確認。

winget source reset --force

筆者の場合は、「winget と msstore 」の両方が入ってました。

• 原因２
  IDが誤っているか登録されていない。pgAdmin.pgAdmin4というIDが現在のwingetリポジトリに存在しない可能性があるので、正しいIDを以下のコマンドで検索します。

winget search pgAdmin

筆者の環境では、正しいIDは「PostgreSQL.pgAdmin」でした。

正しいIDが分かったので、以下のコマンドでインストールします。

winget install --id=PostgreSQL.pgAdmin

インストール中は、下記のプログレスバーが表示されます。

まとめ

pgAdmin 4の起動トラブルは「環境ファイル」「サービス」「権限」「プロキシ設定」等、多岐にわたります。特にプロキシがlocalhost通信を妨害するケースでは、環境変数 NO_PROXY の設定やWindowsのプロキシ除外設定が有効です。ログファイルやポート状態を確認しながら、再現性のある手順で対処することで、初心者でも安定した起動環境を構築できます。

Visual Studio 2022を使っていると、ある日突然「起動しない」「スタート画面が表示されない」といったトラブルに遭遇することがあります。

本ブログでは、Visual Studio 2022が起動しなくなった場合の対処法を、分かり易く紹介します。

Visual Studio 2022が起動する仕組み

まずトラブルの原因を特定するため、Visual Studio 2022 の起動プロセスを説明します。

1. devenv.exe の起動
   Visual Studio の実行ファイル（devenv.exe ）が起動され、Visual Studio 2022の初期化が始まる。
   
   
2. ライセンスの検証
   「%LOCALAPPDATA%\Microsoft\VSCommon\OnlineLicensing」 にあるキャッシュを参照し、ライセンスの有効性を確認する。
   • %LOCALAPPDATA%
     C:\Users\ユーザ名\AppData\Local　を示す。
     
     
3. 拡張機能の読み込み
   ReSharperなどの拡張機能が順次読み込まれる。SafeModeでは読み込みをスキップ可能。
   
   
4. ユーザー設定の復元
   %APPDATA%\Microsoft\VisualStudio に保存された設定ファイルを読み込み、前回の状態を復元する。
   • C:\Users\ユーザ名\AppData\Roaming　を示す。
     
     
5. ワークロードの初期化
   C#や.NETなど、インストール済みのワークロードに応じて必要なコンポーネントを初期化する。
   
   
6. スタートウィンドウの表示
   最近開いたプロジェクトやテンプレートが表示され、ユーザー操作が可能になる。

amzn.to

改訂新版　Visual Studio パーフェクトガイド

本書は、初めて開発を行う人に向けに最新の「Visual Studio 2022」の活用方法を解説した入門書です。本書を読めば、.NET MAUI／Blazorによるマルチプラットフォーム開発、単体テストフレームワークを用いたソフトウェアテスト、Run To Clickによるデバッグ技法、行ステージングによるソースコード管理など開発に必要なVisual Studioの活用法がわかります。

Visual Studio 2022 が起動しないときにまず行うべき診断

ライセンスキャッシュの確認

%LOCALAPPDATA%\Microsoft\VSCommon\OnlineLicensing　フォルダ内の「default.metadata」 が NULL 埋めされていたら破損。

SafeMode で起動できるか確認する

ファイ名を指定して実行（「ウィンドウズキー＋W」）で、「devenv.exe /SafeMode」コマンドが実行できるか確認する。

拡張機能を読み込まないで起動するので、起動できた場合は拡張機能が原因の可能性が大きい。

起動ログを確認する

「devenv.exe /log」で起動後、ログファイル「%APPDATA%\Microsoft\VisualStudio\Version\ActivityLog.xml」内のエラー内容（例：ライセンス検証失敗、拡張機能クラッシュ）を確認する。

TEMP環境変数の確認

セミコロン付きや無効なパスがあると起動に失敗します。

amzn.to

Visual Studioパーフェクトガイド 単行本

本書はIDEに焦点を当てた書籍です。IDEは豊富な機能が揃っているため、C#を用いてUnityでゲーム開発を行う場合やクロスプラットフォーム開発を行う際,IDE(Visual Studio)を使うのはデファクトスタンダードになっています。本書は新人エンジニアに向けて,豊富な機能が揃ったIDEが裏で何をやっているかをわかりやすく解説した書籍を目指します。

Visual Studio 2022 が起動しない原因と対処方法

ライセンスキャッシュ破損

Visual Studio は、起動時のライセンスを、毎回オンラインで確認するのではなく、以下のフォルダにあるキャッシュファイル default.metadata 等を参照します。

%LOCALAPPDATA%\Microsoft\VSCommon\OnlineLicensing

ライセンスキャッシュが破損した場合の症状

• Visual Studio が起動直後にクラッシュ
• スタート画面が表示されず、プロセスが即終了
• ログに「License validation task failed unexpectedly」などのエラーが記録される

対処方法

以下のようにして、キャッシュのリセットを実行します。

「%LOCALAPPDATA%\Microsoft\VSCommon\OnlineLicensing」のフォルダ名称を　「OnlineLicensing_bkup」等の名称に変更し、Visual Studio を再起動。こうする事で、新しいキャッシュが自動生成される。
※この操作はライセンス情報の再取得を促すもので、ライセンス自体が無効になるわけではありません。

拡張機能の不具合

拡張機能が不具合時の症状

• スプラッシュ画面が表示された直後に強制終了
• スタートウィンドウが表示されず、プロセスが消える

拡張機能の不具合かどうかの確認方法

• SafeModeで起動してみる

devenv.exe /SafeMode

SafeModeでは拡張機能が読み込まれない為、このモードで起動できる場合は拡張機能が原因の可能性が高いと言えます。

• 起動ログを確認する
  「%APPDATA%\Microsoft\VisualStudio\17.0\ActivityLog.xml」に以下のような記述がある場合、拡張機能がクラッシュの原因です

Extension 'ReSharper' failed to load.
Exception: System.NullReferenceException...

対処方法

• SafeModeで起動して、拡張機能を無効化 又は、削除
  • SafeModeで起動（「ファイル名を指定して実行」で、devenv.exe /SafeMode）
  • メニュー → [拡張機能] → [拡張機能の管理]
  • 問題のある拡張機能（例：ReSharper）を「無効化」または「アンインストール」
    
    
• Visual Studio Installer で修復（拡張機能の不整合も含めて再構成される）
  • スタートメニュー → Visual Studio Installer → 対象バージョン → 修復

amzn.to

Kindle Paperwhite (16GB) 7インチディスプレイ

レビュー：読書が楽しくなるガジェット。スマホで読むのとは違います。カラー版もありますが、カラーの書籍って雑誌を除くとそんなにないのでPaperwhiteで十分だと個人的には思います。

アップデート失敗

アップデート失敗は、構成ファイルの破損やネットワーク不具合、インストーラーの不整合などが原因で発生します。

アップデート失敗時の症状

以下の様に、症状は多岐に渡る。

• Visual Studioが起動しない
  • スプラッシュ画面が表示された直後にクラッシュ
  • プロセス（devenv.exe）が一瞬で終了する
    
    
• Visual Studio Installer自体が起動しない
  
  
• SafeModeでも起動しない
  
  
• 特定のワークロードが消えている
  
  
• IntelliSenseが動作しない
  
  
• ツールウィンドウが表示されない
  
  
• 起動ログ（ActivityLog.xml）に下記のような構成エラーが記録される

Package 'Microsoft.VisualStudio.Shell.Connected' failed to load

• Visual Studio Installerでの症状
  • 「修復」ボタンがグレーアウトしている
  • インストール済みの構成が表示されない
  • 「アップデートに失敗しました」などのポップアップが出る

対処方法

• Visual Studio Installer で修復を試す
  • スタートメニューから「Visual Studio Installer」を起動
  • 対象のバージョン（例：Visual Studio 2022）を選択
  • 「修復」ボタンをクリック
  • 修復完了後、再起動して確認
    
    
• Installer自体が起動しない、修復できない場合は、Microsoft公式の「InstallCleanup.exe」ツールを使ってインストール情報を完全に削除します。
  • 管理者権限でコマンドプロンプトを起動
  • 以下のコマンドを実行

"C:\Program Files (x86)\Microsoft Visual Studio\Installer\InstallCleanup.exe" -i 17

※ -i 17 は Visual Studio 2022 のバージョン指定
　クリーンアップ完了後、Visual Studio 2022 を再インストール

• アップデートが「ダウンロードできない」「接続できない」といったネットワーク系のエラーで失敗する場合
  • C:\Windows\System32\drivers\etc\hosts を管理者権限で開く
  • 「93.184.215.201 download.visualstudio.microsoft.com」　を追記
    • 93.184.215.201 は、米国の CDN（コンテンツ配信ネットワーク）やホスティングサービスが使用する IP アドレスのひとつで、特に example.com というテスト用ドメインのホスト先。本来の Microsoft の更新サーバーではなく、接続テストや一時的な回避策として使われることがあるだけで、恒久的な解決策ではありません。
  • コマンドプロンプトで、「ipconfig /flushdns」を実行

TEMP環境変数の誤設定

よくある誤設定

• TEMP=C:\Temp;（末尾にセミコロン）
  • パスが無効と認識され、起動失敗
    
    
• TEMP=（空欄）
  • 一時ファイルが保存できず、クラッシュ
    
    
• TEMP=D:\フォルダ名（存在しないパス）
  • ファイル書き込みエラーで起動不能
    
    
• TEMP がネットワークドライブ
  • アクセス遅延や失敗で起動不能になることも
    

amzn.to

New Amazon Kindle Colorsoft | 16GBストレージ、防水、7インチカラーディスプレイ

booxなどのandroid搭載の電子ペーパー端末と迷いましたが、お風呂で使いたかったので結局はこの商品にしました。電子ペーパーはページ送り時の読み込みが遅いと言う印象がありましたが個人的には全然問題ありませんでした。カラーの発色は淡いですが、こんなもので良いだろうと言う感想です。

まとめ

Visual Studio が突然起動しなくても慌てる必要はありません。C#等のソースはIDEとは別フォルダとして保存されているので、最悪 他のIDE（VSCode）でも使用が可能です。

先ずは起動のプロセスを理解し、起動しなくなった原因を突きとめるために診断を行う事です。そして、その診断に基づいた適切な処置を実行する事で再起動する事が可能となります。

PostgreSQLの非同期レプリケーションで最も多く発生するトラブルが、WALの遅延と肥大化です。

WALの遅延と肥大化とは、プライマリの変更情報がスタンバイ側に反映されるのが遅れ、その結果、反映されないWALが溜まってディスク容量を圧迫する事をいいます。

WALが遅延・肥大化するとどうなる？

スタンバイの同期不能

未だスタンバイに反映されていないWALが削除され、スタンバイの再構築が必要になります。

フェルオーバーが不可能になる

スタンバイが遅延してもプライマリは動作を続ける為、プライマリの状態に追いつけなくなります。よって、プライマリが故障した場合、スタンバイがプライマリとして動作できなくなります。

ディスク容量不足によるPostgreSQLの停止

WALファイルは プライマリ側のpg_wal ディレクトリに蓄積されますが、最終的に書き込み不能となり、PostgeSQLが停止します。

バックアップが失敗する

WALアーカイブが遅延すると、PITR（ポイントインリカバリ）が不可能になります。

• PITR（ポイントインリカバリ）
  ベースバックアップ（物理バックアップ）とWALアーカイブを使用してバックアップ取得時点から任意の時刻までWALを「再生」する機能。障害直前や指定時刻の状態に復元できる。

PostgreSQL徹底入門 第4版 インストールから機能・仕組み、アプリ作り、管理・運用まで | 近藤 雄太, 正野 裕大, 坂井 潔, 鳥越 淳, 笠原 辰仁, 石井 達夫 |本 | 通販 | Amazon

Amazonで近藤 雄太, 正野 裕大, 坂井 潔, 鳥越 淳, 笠原 辰仁, 石井 達夫のPostgreSQL徹底入門 第4版 インストールから機能・仕組み、アプリ作り、管理・運用まで。アマゾンならポイント還元本が多数。近藤 雄太, 正野...

amzn.to

WAL遅延の原因

スタンバイ側のI/O性能不足

HDDや低IOPSのクラウドストレージでは、WALの書き込み・適用が追いつかず replay_lag が発生しやすくなります。特に読み取りクエリと競合する場合、顕著になります。

• IOPS（アイオプス）
  1秒間に何回の「読み込み（Read）」や「書き込み（Write）」操作ができるかの指標
• replay_lag
  スタンバイサーバがプライマリサーバにどれだけ遅れているかを示す指標
  例）00:00:03.456 → 約3.4秒の遅延

ネットワーク帯域の不足・不安定な接続

プライマリ→スタンバイ間のWAL転送が詰まり、write_lag や flush_lag が発生します。VPNやクラウド間通信で多発し易い遅延です。

• write_lag
  プライマリがWALを送信してから、スタンバイがそれを受信してメモリに書き込むまでにかかった時間
• flush_lag
  スタンバイがWALをディスクに書き込むまでにかかった時間

スタンバイのWAL適用処理の遅延

スタンバイでのクエリ実行やバックグラウンドプロセスがWALの適用を妨げたり、CPU競合やメモリ不足により発生する遅延です。

プライマリ側の送信プロセス不足（max_wal_senders）

複数のスタンバイがある場合、送信プロセスが足りずにWAL送信が滞り発生します。

• max_wal_senders
  PostgreSQL の設定パラメータ。WALをスタンバイやバックアップツールに送信するプロセスの最大数を指定する。

wal_keep_size の不足によるWAL早期削除

スタンバイが遅延しているのに、プライマリが未反映のWALを削除してしまいます。

• wal_keep_size
  PostgreSQL の設定パラメータ。プライマリサーバが保持しておくWALファイルのサイズを指定する。

アーカイブ処理の詰まり（archive_command）

アーカイブ先の容量不足やスクリプトエラーによってWALが溜まり、遅延や肥大化が発生します。

• archive_command
  WALを外部に保存（アーカイブ）するためのコマンド。特に PITR（Point-In-Time Recovery）や長期バックアップ、スタンバイ再同期において重要な役割を果たします。

遅延状況の確認方法 と LSN（Log Sequence Number）

• LSN（Log Sequence Number）
  WALファイルの中で「どの位置までWALが処理されたか」を示す表記方法。WALの位置を上下32ビットで、X/Y の様に表記します。
  • X：0 ⇀ WALセグメントの先頭（最初のファイル）
  • Y：16B6C60 ⇀ そのセグメント内のオフセット位置（バイト単位）
    

LSNの進み方（イメージ）

0/00000000 → 0/00001000 → 0/00002000 → ... → 0/16B6C60 → ...

WALが書き込まれるたびに、LSNは進みます。スタンバイが replay_lsn を報告することで、プライマリは「どこまで追いついているか」を把握できます。

• 遅延状況の確認

SELECT
  application_name,
  write_lag,
  flush_lag,
  replay_lag,
  write_lsn,
  flush_lsn,
  replay_lsn
FROM pg_stat_replication;

• write_lag
  プライマリがWALを送信してからスタンバイが受信してメモリに書き込むまでにかかった時間
• flush_lag
  スタンバイがWALをディスクに書き込むまでにかかった時間
• replay_lag
  スタンバイサーバがプライマリサーバにどれだけ遅れているかの時間
• write_lsn
  スタンバイが WALをメモリ上に書き込んだLSN
• flush_lsn
  スタンバイがWALをディスクにフラッシュ（書き込み）LSN
• replay_lsn
  スタンバイがWALを適用し、データベース状態に反映したLSN

［改訂3版］内部構造から学ぶPostgreSQL―設計・運用計画の鉄則 (Software Design plus) | 上原 一樹, 勝俣 智成, 佐伯 昌樹, 原田 登志 |本 | 通販 | Amazon

Amazonで上原 一樹, 勝俣 智成, 佐伯 昌樹, 原田 登志の［改訂3版］内部構造から学ぶPostgreSQL―設計・運用計画の鉄則 (Software Design plus)。アマゾンならポイント還元本が多数。上原 一樹, 勝俣 ...

amzn.to

WAL遅延と肥大化を防ぐ対処法

スタンバイ側 I/O性能の向上

• スタンバイ側のSSDへの移行
  HDDでは flush_lag や replay_lag が顕著に出るため、SSD化は最優先の対処法となります。
• IOPS保証付きインスタンス選定
  クラウド環境では IOPS制限が遅延要因になります。
• スタンバイでのクエリ制限
  読み取り専用用途に限定し、WAL適用を妨げないようにします。
  

ネットワーク帯域の不足・不安定な接続の解消

• 同一AZ配置
  クラウドではプライマリ・スタンバイを同一地域の独立したセンター郡に配置します。
• VPNやファイアウォールの最適化
  パケットロスや遅延の原因を排除します。

スタンバイ WAL適用処理の遅延対策

• スタンバイのhot_standby_feedbackの設定
  設定を on にし、VACUUMとの衝突を防いでWAL適用をスムーズに実行できるようにします。
  • VACUUM
    不要になったデータ（デッドタプル）を物理的に除去し、テーブルのサイズやパフォーマンスを最適化するメンテナンス処理

プライマリ側の送信プロセス不足対策

• プライマリ側の送信プロセス数を増やす
  例）max_wal_senders = 10

wal_keep_size の不足によるWAL早期削除 対策

• プライマリ側でWALを保持できるファイルサイズを増やす
  例）wal_keep_size = ‘512MB’ 　# スタンバイの遅延に応じて調整

アーカイブ処理の詰まり 対策

• アーカイブ先の容量を十分に確保すると共に、容量を監視する
• 強制アーカイブの実施
  WALセグメントが満たされていなくても、定期的にWALファイルをアーカイブ先へ排出します。その結果、pg_wal内のWALを早めに削除でき、肥大化やスタンバイの遅延を抑制できます。

archive_timeout = 60  # 60秒ごとにWALを強制アーカイブ

まとめ

WAL遅延と肥大化は上述したように、適切な監視と対応を実施すれば防ぐ事が可能です。使用していて異常が感じられないからといって、そのままにしておくと、ある日 突然 異常が発生し、業務が停止するばかりでなく、原因の究明と復旧に時間と労力を費やす事となります。又、場合によっては大きな損失を被る事になりまねません。

そうならないためにも、適切な監視を実施して異常を早めに発見し、対策する事が重要です。

PostgreSQLのストリーミングレプリケーションは、データの可用性と冗長性を高める強力な仕組みです。しかし、構築しただけでは安心できません。運用フェーズでは、レプリケーションの状態監視、障害対応、遅延対策など、複数の観点から注意を払う必要があります。

本ブログでは、Windows環境でPostgreSQLのストリーミングレプリケーションを構築済みの方を対象に、運用時の状態監視方法を紹介します。

ストリーミングレプリケーションの構築方法は下記ブログを参照ください。

ストリーミングレプリケーション構築方法

レプリケーションの動作状況の確認

まずは、レプリケーションが正常に動作しているかを定期的に確認することが重要です。

プライマリ動作の確認

以下のSQLで、スタンバイとの接続状況や遅延を確認します。

SELECT pid, client_addr, state, sync_state, write_lag, flush_lag, replay_lag
FROM pg_stat_replication;

• state
  ストリーミングレプリケーションなので、streaming なら正常

• sync_state
  同期レプリケーションなので、sync なら正常

• write_lag
  WALをスタンバイに送信した後、スタンバイがそのWALを書き込むまでにかかった時間。
  正常値は、0～数百ミリ秒。５秒以上ならば、スタンバイのI/O性能低下、ネットワーク障害、WAL送信設定不備などが疑われる。

• flush_lag
  プライマリサーバがWALを送信してから、スタンバイサーバがそのWALを「ディスクにフラッシュ（書き込み確定）」するまでにかかった時間を示す指標。
  正常値は、0～数百ミリ秒。５秒以上は異常と考えられる。

• replay_lag
  スタンバイサーバがプライマリから受信したWALを「実際に適用（replay）」するまでにかかった時間を示す指標。
  正常値は、0～数百ミリ秒。５秒以上は異常と考えられる。

• コマンドの実行例

※write_lag、flush_log、replay_log がNULLなのは、現在新しいWALが生成されていない為。

スタンバイ側動作の確認

スタンバイ側では、WAL受信状況を以下で確認できます。

SELECT status, receive_start_lsn, receive_start_tli, written_lsn, flushed_lsn, latest_end_lsn, latest_end_time FROM pg_stat_wal_receiver;

• status
  ストリーミングレプリケーションなので、streaming なら正常

• receive_start_lsn
  WAL受信開始位置。
  通常運用では頻繁に変化しないため、急な変更があれば再構築や障害の兆候有り。

• receive_start_tli
  受信開始時のタイムラインID。
  フェイルオーバー後にタイムラインが変わるため、プライマリとの整合性確認に使用する。タイムラインが一致していない場合、スタンバイが古い状態である可能性がある。

• written_lsn
  スタンバイがWALを書き込んだ最新位置。
  latest_end_lsn との差が大きいと、WAL受信はしているが書き込みが遅れている可能性あり。

• flushed_lsn
  スタンバイがWALをフラッシュ（ディスクに確定書き込み）した最新位置。
  written_lsn より遅れている場合、フラッシュ処理が滞っている。

• latest_end_lsn
  プライマリが送信した最新のWALの位置。
  written_lsn や flushed_lsn と比較して遅延を把握する。位置。

• latest_end_time
  latest_end_lsn に対応するWALのタイムスタンプ。
  スタンバイが最新WALをどれだけ遅れて受信しているかの目安になる。
  

• コマンドの実行例

また、現在のWAL適用位置は以下で確認できます。

SELECT pg_last_wal_replay_lsn();

PowerShellでの監視例

Windows環境では、PowerShellを使って定期監視スクリプトを作成できます。タスクスケジューラで定期実行すれば、ログ監視や通知にも応用可能です。

• スクリプト例（replication_monitor.ps1）

#スクリプトの実行制限（ポリシー）の確認と変更
Get-ExecutionPolicy
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

# PostgreSQL接続情報
$PGUSER = "postgres"
$PGDATABASE = "postgres"
$PGHOST = "localhost"
$PGPORT = "5432"

# psqlコマンドのパス（環境に応じて変更）
$PSQL = "C:\Program Files\PostgreSQL\17\bin\psql.exe"

# ログファイル出力先
$LOGFILE = "C:\pg_backup\pg_shell_log\replication_monitor.log"

# 日時取得
$timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"

# pg_stat_replicationの取得（プライマリ側のレプリケーション状態の取得）
$replication = & $PSQL -U $PGUSER -d $PGDATABASE -h $PGHOST -p $PGPORT -c "SELECT state, sync_state, write_lag, flush_lag, replay_lag FROM pg_stat_replication;" 2>&1

# pg_stat_wal_receiverの取得（スタンバイ側のWAL受信状態取得）
$receiver = & $PSQL -U $PGUSER -d $PGDATABASE -h $PGHOST -p $PGPORT -c "SELECT status, written_lsn, flushed_lsn, latest_end_lsn FROM pg_stat_wal_receiver;" 2>&1

# ログ出力
Add-Content -Path $LOGFILE -Value "[$timestamp] Replication Status:"
Add-Content -Path $LOGFILE -Value $replication
Add-Content -Path $LOGFILE -Value "[$timestamp] WAL Receiver Status:"
Add-Content -Path $LOGFILE -Value $receiver
Add-Content -Path $LOGFILE -Value "----------------------------------------"

• 実行結果

レプリケーション監視の重要性

レプリケーション監視は、PostgreSQLの高可用性とデータ整合性を維持するために不可欠です。

プライマリとスタンバイ間の遅延（write_lag、flush_lag、replay_lag）や接続状態（state、sync_state）を定期的に確認することで、障害の予兆を早期に検知できます。

遅延が蓄積すれば、スタンバイの昇格時にデータ不整合が生じるリスクがあり、業務停止や復旧困難につながります。監視を自動化し、可視化することで、安定運用と迅速な障害対応が可能になります。

本ブログでは、初心者〜中級者向けにPostgreSQLのレプリケーション構築手順を紹介します。レプリケーションは大きく分けると、

• データベースクラスタを一括して複製する「ストリーミングレプリケーション（物理レプリケーション）」
• テーブル単位やデータベース単位に複製する「ロジカルレプリケーション（論理レプリケーション）」

があります。ここでは「ストリーミングレプリケーション」の構築を中心に紹介します。

PostgreSQLレプリケーションとは？ なぜ必要？

レプリケーションとは、1つのデータベース（プライマリ）から別のデータベース（スタンバイ）へリアルタイムでデータを複製する仕組みです。

複製を作成するメリットは、

• 障害時の迅速な復旧（フェイルオーバー）
  プライマリが故障した場合、複製のスタンバイを使用する
• 読み取り負荷の分散（参照系クエリの負荷分散）
  ユーザーからの多くのクエリ（参照系）スタンバイに分散させる事で、全体として処理能力を高める
• 災害対策（DR）
  スタンバイを遠くの地域に置く事で、災害からのデータ損失のリスクを減少させる

等です。

レプリケーションのアーキテクチャ

ストリーミングでもロジカルでも、基本的な仕組みは「ＷＡＬ」を使用している事です。

「ＷＡＬ」（Write Ahead Log）とは、データベースへの変更内容が全て記録されているログの事で、この「ＷＡＬ」を別のPostgreSQLに転送・リカバリして複製を作成し、レプリケーションを実現しています。

• ①クエリにより「WAL」が生成され、テーブルが更新される。
• ②スタンバイに転送されてきた「WAL」をそのまま「WAL」ファイルに書き込み、「WAL」の内容で、テーブルを更新する。

※プライマリから送られてきた「WAL」をそのまま適用する為、以下の条件が必要となります。

• PostgreSQLのメジャーバージョンが同じであること
  • マスタとスタンバイは同じWALフォーマット・バージョンである必要あり
• ハードウェアやOSのアーキテクチャが同じである事

ストリーミングレプリケーションの特徴

ストリーミングレプリケーションは、WAL（Write-Ahead Logging）ファイルをリアルタイムでスタンバイサーバに転送することで、プライマリとスタンバイ間のデータ同期を実現します。

• 特徴
  • プライマリで生成されたWALファイルを、TCP接続を通じてスタンバイに送信
  • ファイルコピーではなく、ストリーム転送なので即時性が高い
  • スタンバイ側はSELECTのみ可能（書き込み不可）

使用環境

• Windows 11 Pro 24H2
• PostgreSQL 17.6
• プライマリサーバのＩＰ　：192.168.0.80
• スタンバイサーバーのＩＰ：192.168.0.60

ストリーミングレプリケーションの設定

プライマリサーバの設定

postgresql.confの設定

postgresql.confはメイン設定ファイルであり、データベースの動作に関するさまざまなパラメータを定義する重要な役割を担っています

先ずは、postgresql.confをプライマリサーバ用に設定します。

• 基本接続

listen_addresses = '*'　　　　　　　#外部からの全ての接続を許可
port = 5432　　　　　　　　　　　　 #デフォルトの待ち受けポート

• WAL（Write-Ahead Logging）関連設定

wal_level = replica　　　　　　　　#レプリケーション用にreplicaを指定
　　　　　　　　　　　　　　　　　 #ロジカルなら logical を指定
max_wal_senders = 5　　　　　　　　#スタンバイ接続数の上限（必要に応じて設定）
wal_keep_size = '256MB'　　　　　　#WALファイルの保持サイズ。遅延対策に有効。

• 同期レプリケーション設定

synchronous_commit = on                        #同期レプリケーションを明示的に指定
　　　　　　　　　　　　　　　　　　　　　　　 #標準は、on
synchronous_standby_names = 'standby01'　　　　#同期レプリケーションを使用する場合の
　　　　　　　　　　　　　　　　　　　　　　　 #スタンバイ側の名称を指定

• ログ出力設定（トラブルシューティング）

logging_collector = on
log_directory = 'log'
log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log'
log_connections = on
log_disconnections = on

• メモリ・パフォーマンス関連（環境に応じて調整）

shared_buffers = '512MB'　　　　#PostgreSQLが使用するメモリ領域。物理メモリの
                                #25〜40%が目安。
effective_cache_size = '1GB'　　#OS側のキャッシュ見積もり。クエリプランに影響。
work_mem = '4MB'　　　　　　　　#ソートやハッシュ処理に使うメモリ。
                                #複雑なクエリが多い場合は増やす。
maintenance_work_mem = '64MB'   #PostgreSQLが「メンテナンス系の処理」を
                                #行うときに使うメモリの上限

上記の値は必要に応じて設定してください。

pg_hba.confファイルの設定

pg_hba.confは接続認証の制御ファイルで、誰が・どこから・どの方法で接続できるかを定義します。

インストールされたファイルはUNIX用なので、以下の様にWndows用に書き換えます。

# TYPE  DATABASE        USER            ADDRESS                 METHOD
# IPv4 local connections:
host    all             all             127.0.0.1/32         scram-sha-256


# IPv6 local connections:
host    all             all             ::1/128                 scram-sha-256

# Allow replication connections from localhost, by a user with the replication privilege.
host    replication     replicator      192.168.0.60/24         scram-sha-256

• host all all 127.0.0.1/24 scram-sha-256
  すべてのデータベースに対して、全てのユーザーから接続を許可しています。
• host replication replicator 192.168.0.60/24 scram-sha-256
  レプリケーション専用接続で、ID：replicatorで（192.168.0.1～254：スタンバイサーバー）からプライマリサーバ（192.168.0.80）にアクセスを許可しています。

レプリケーション権限を持つユーザーの作成

• 下記コマンドで作成します。

CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 'reppass';

PostgreSQLサービス再起動（PowerShell）

• PostgreSQLが正常に再起動するか確認します。

Restart-Service -Name postgresql-x64-17

スタンバイサーバーの設定

初期同期の実行

pg_basebackupでプライマリからデータを取得し、初期同期を実行します。

• C:\pgsql　フォルダを作成

mkdir C:\pgsql

• 下記コマンドで初期同期を実行

cd "C:\Program Files\PostgreSQL\17\bin"
.\pg_basebackup.exe -h 192.168.0.80 -D "C:\pgsql\standby_data" -U replicator -P -R -W

これから以後のファイル設定は、”C:\pgsql\standby_data”　内のファイルに対して行います。

postgresql.auto.conf の内容追加

postgresql.auto.conf に下記の内容を追加します。application_name はプライマリ側の synchronous_standby_names に一致させると同期レプリケーションが可能となります。

primary_conninfo = 'host=192.168.0.80 port=5432 user=replicator password=reppass application_name=standby01'

standby.signal ファイルの作成（自動作成されていない場合）

内容は無くてもよいが、このファイルが存在することで、PostgreSQLはスタンバイモードで起動します。作成方法は下記コマンドを実行。

New-Item -Path "C:\pgsql\standby_data\standby.signal" -ItemType File

postgresql.conf の調整

postgresql.conf ファイルの内容が、下記のようになるよう調整します。

# 接続関連
listen_addresses = '*'                 # 外部からの接続を許可
port = 5432                            # 通常のPostgreSQLポート

# WAL受信と適用
wal_level = replica                    # WALを受信する最低レベル
hot_standby = on                       # スタンバイでもSELECTなどの読み取りを許可
wal_receiver_status_interval = 1s     # プライマリへの受信状況報告間隔
wal_retrieve_retry_interval = 3s      # WAL取得失敗時の再試行間隔

# ログ出力（トラブル時の診断に必須）
logging_collector = on
log_directory = 'log'
log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log'
log_min_messages = info
log_connections = on
log_disconnections = on

hot_standby = on により、スタンバイでも読み取りクエリが可能になります。

サービスの登録と起動（初回のみ）

• サービスの登録
  スタンバイ側で下記のコマンドを実行して「pgsql-standby」サービスを登録します。 C:\Program Files\PostgreSQL\17\bin にパスを通すか、ディレクトリに移動して実行。

cd "C:\Program Files\PostgreSQL\17\bin"
./pg_ctl register -N "pgsql-standby" -D "C:\pgsql\standby_data"

• サービスの起動
  下記コマンドを実行

Start-Service -Name pgsql-standby

• 動作確認
  下記SELECT文で、trueが返ればスタンバイとして動作中です。

SELECT pg_is_in_recovery();

レプリケーション動作の確認

プライマリ側のテーブルに１件のレコードを追加した場合、スタンバイ側にも同様に追加されるか確認してみます。

• プライマリ側の操作
  articlesテーブルに1件のレコードを追加

• スタンドバイ側の状態
  プライマリ側に追加されたレコードが、スタンドバイ側にも追加され、同期している事が確認できます。

ストリーミングレプリケーションのまとめ

ストリーミングレプリケーションは、基本的にデータベース全体を複製します。レプリケーションの元となるサーバーは１台だけ設定できますが、スタンバイは複数台設定できます。又、スタンバイサーバーで実行できるのは参照系のクエリのみです。

冒頭でも述べましたが、ストリーミングレプリケーションは、PostgreSQLの高可用性を実現する重要な機能です。設定はシンプルですが、細部の確認が成功の鍵。この記事を参考に、安全で再現性の高い構成を作成して下さい。

Webアプリや業務システムで「検索機能」は欠かせません。PostgreSQLは、標準SQLだけでなく強力な全文検索機能を備えており、特にpg_trgm拡張を使うことで、LIKE検索より高速かつ柔軟な検索が可能になります。

使用環境

• Windows 11 Pro 24H2
• PostgreSQL 17.6
• pgAdmin4 9.6
• Chrome 134.0.6998.205

LIKE検索とpg_trgmの違い

LIKE検索

• SQL標準の部分一致検索にしか過ぎない
  • 例：WHERE content LIKE ‘%検索%’
  • %は任意の文字列を表すワイルドカード
• 問題点
  • インデックスが効きにくい（特に先頭に%がある場合）
  • 大量データになると検索が遅くなる

pg_trgm

• 全文検索をする為の拡張機能
  • 文字列を「3文字ずつの断片（トライグラム）」に分解して類似度を計算
  • 例：WHERE content % '検索'（%はpg_trgm演算子）

• 利点
  • 類似検索が可能（完全一致でなくてもヒット）
  • インデックス（GINインデックス）と組み合わせると高速

GINインデックス

• Generalized Inverted Index（汎用反転インデックス¹）
  • pg_trgmと組み合わせることで、トライグラム単位²で高速検索可能

LIKE検索・pg_trgm　どちらを使用すべきか？

• 小規模・簡易検索
  • LIKEで十分
• 大量データ・類似検索・高速化
  • pg_trgm＋GINインデックスが圧倒的に有利

LIKE検索・pg_trgm 比較準備

サンプルテーブルの作成とデータ登録

• 下記サンプルプログラムを作成します。サンプルプログラムの目的は、
  • LIKE検索とpg_trgm検索の違いを体感する
  • GINインデックスの有無による速度差を確認する
  • 類似語や誤字でもヒットするかを試す(下記プログラムの、WHEN i % 3 = 1 THEN ‘PosgrelSQLは高速な検索が可能です。’　では、PostgreSQL を PosgrelSQL にしています。)

-- サンプルプログラム

CREATE TABLE articles (
  id SERIAL PRIMARY KEY,
  title TEXT,
  content TEXT
);

-- 10000件のサンプルデータを生成（実験用）
INSERT INTO articles (title, content)
SELECT
  '記事' || i,
  CASE
    WHEN i % 3 = 0 THEN 'PostgreSQLの全文検索は便利です。'
    WHEN i % 3 = 1 THEN 'PosgrelSQLは高速な検索が可能です。'
    ELSE 'PostgreSQLはオープンソースのRDBMSです。'
  END
FROM generate_series(1, 10000) AS s(i);

SQLでの拡張機能「pg_trgm」の有効化

• psql で以下のSQLを実行

CREATE EXTENSION IF NOT EXISTS pg_trgm;

LIKE検索・pg_trgm検索結果の比較

pgAdmin4 による検索結果の比較

ここでは、初心者向けでもある為、pgAdmin4の「クエリツール」で確認します。

pgAdmin4 のクエリ完了時間 とは

pgAdmin 4がクエリをPostgreSQLに送信し、サーバーが処理して結果を返し、pgAdminがそれを受け取って表示するまでの一連の流れにかかった時間です。（以下の表の合計時間）

サーバー側の実行処理のみの時間や、実行前の準備の時間を知りたい場合

以下のコマンドを使用します。

• LIKE検索

EXPLAIN ANALYZE SELECT * FROM articles WHERE content LIKE '%PostgreSQL%';

• pg_trgm検索

EXPLAIN ANALYZE SELECT * FROM articles WHERE content % 'PostgreSQL';

pgAdmin4 による検索結果

• LIKEの実行確認用SQL

-- 部分一致検索（検索語：PostgreSQL）
SELECT * FROM articles WHERE content LIKE '%PostgreSQL%';

• 実行結果と実行時間
  • 検索件数：6,666件
  • 検索時間：0.170ms

• pg_trgmの実行確認用SQL

-- pg_trgm検索（類似度）
SELECT * FROM articles WHERE content % 'PostgreSQL';

• 実行結果と実行時間
  • 検索件数：10,000件
  • 検索時間：0.197ms
  • 類似文字（ここでは、PosgrelSQL）も検索されている為多少時間がかかっていると思われる。

インデックスの作成とパフォーマンス比較

GINインデックス作成

• 下記のSQLを実行してGINインデックス作成を作成します

CREATE INDEX articles_idx ON articles USING GIN (content gin_trgm_ops);

• インデックスが作成されているか？

• pg_trgm＋GINインデックスの実行結果

PostgreSQL 「フルテキスト検索入門」 まとめ

PostgreSQLでの文字列検索は、LIKE '%文字列%' が基本ですが、インデックスが効かず遅くなりがちです。そこで登場するのが pg_trgm 拡張。曖昧検索を高速化する強力な武器です。

• LIKE検索の課題
  • % で始まる検索はインデックスが使えない
  • 全件走査（Seq Scan）になり、件数が多いと遅い
  • 日本語や長文では特に非効率

• pg_trgmとは？
  • 「トライグラム（3文字単位）」で文字列を分割し、類似度を計算
  • % 演算子で曖昧検索が可能（content % '検索語'）
  • GINインデックスと組み合わせることで爆速化

脚　注

1. GINインデックス（汎用反転インデックス）
   通常のインデックス（BTREEなど）は「行単位」でインデックスを作りますが、反転インデックスは「値 → 行」の逆方向でインデックスを作ります。
   例）
   通常：id → content
   反転：単語 → 含まれる行ID
   つまり、検索語に対応する行を高速に引き出すための構造です。
   ↩︎
2. トライグラム単位
   ・「Tri（3）」＋「gram（文字列単位）」＝3文字の連続部分列
   ・文字列を3文字ずつの断片に分割して、検索語との共通部分の数で類似度を計算
   ↩︎

【Python】仮想環境とは、そもそも何？

Pythonの仮想環境はベースとなるPython環境の上に、プロジェクト毎に独立した専用のsite-packages（プロジェクト専用のディレクトリ）を作成して使用する事を指します。そのため、ベース環境のPython標準ライブラリは共有されますが、プロジェクト毎のsite-packagesの部分は独立しており、異なるパッケージや依存関係をプロジェクト毎に持つことが可能な環境の事をいいます。

【Python】仮想環境を使用するメリット

• プロジェクトごとの依存関係の分離
  各仮想環境が独自のsite-packagesディレクトリを持つため、複数のプロジェクトが異なるバージョンのライブラリを必要とする場合でも干渉せずに管理できます。
  ※site-packages：他の環境やシステム全体とは独立したプロジェクト専用のディレクトリ
  　
  
• システム環境に影響を与えない
  仮想環境内にのみパッケージをインストールできるため、システム全体に影響を与えません。
  
  
• 簡単な移植性
  仮想環境を使用すると、特定の環境構成を維持したままプロジェクトを別の開発者やサーバーに移行できます。同じ環境でプロジェクトが動作するため、移植性が高くなります。
  
  
• 異なるPythonバージョンのサポート
  各仮想環境は異なるPythonバージョンを使用できるため、特定のPythonバージョンに依存するアプリケーションを並行して開発できます。
  
  
• バージョン管理との統合が容易
  仮想環境に必要な依存パッケージをrequirements.txtなどで定義すると、他の開発者が同じ依存関係を簡単に再現でき、Gitなどのバージョン管理と統合が容易になります。
  
  
• 安全性の向上
  仮想環境はシステム全体とは独立しているため、環境ごとに必要なセキュリティパッチや更新を行いやすく、プロジェクトごとにセキュリティ対策が施せます。
  
  

【Python】VSCodeによる仮想環境の作成

ベース環境となるPythonのインストール

Python（Cpython）は下記のプログを参考にしてインストールして下さい。

参考ブログ：Python（CPython）のインストール

VSCodeのインストールと日本語化

VSCodeのインストールと日本語化は下記のブログを参照して下さい。

参照ブログ：Visual Studio Code のインストールと日本語化

VSCode上でのPython環境構築

下図の様に、
①「拡張機能」アイコンをクリックし、
②「検索文字入力欄」に、Python と入力する。
③表示された「Python」の「インストール |∨」記号をクリックし、
④「リリスバージョンのインストール」を選択します。

「Python」が「Python Debugger」と共にインストールされます。

使用するベースPythonの選択

• VS Codeのコマンドパレットを開きます。（Ctrl + Shift + P または Cmd + Shift + P）
• 「Python：インタープリターを選択」を選択します。

• ここでは、先程インストールした「Python 3.13.0」を選択します。

• 表示メニューから、ターミナルを開きます。

• 「Python -V」と入力して、インストールした「Python」のバージョンが表示されれば、VSCodeでPython 3.13.0 が使用できます。

今回の実行環境

• OS
  • Windows 10 Pro 22H2
  • ＯSビルド：19045.5011
• コードエディタ（IDE）
  • Visual Studio Code Ver. 1.94
    ※仮想環境（v_scraping）を作成して実行しています。
• Python：Ver. 3.13.0

Python 仮想環境の作成と起動方法

仮想環境は、VSCodeのターミナルで、下記のvenvコマンドを使用して作成します。

• 先ず、サンプルとなるプロジェクト「01_scraping_01」をVSCodeで開き、ターミナルを表示します。このプロジェクトはスクレイピングを行うプログラムですが、必要なライブラリ「requests」「beautifulsoup4」が未だインストールされていません。又、仮想環境用のsite-packages（プロジェクト専用のディレクトリ）もありません。

import requests
from bs4 import BeautifulSoup

# スクレイピングする対象のURL（例として仮のニュースサイトのURLを指定します）
url = 'https://www.python.org/downloads/'  # 実際のURLを指定する

# 1. RequestsでHTTPリクエストを送信してHTMLを取得
response = requests.get(url)

# ステータスコードを確認（200は成功を意味します）
if response.status_code == 200:
    # 2. Beautiful SoupでHTMLを解析
    release = []
    soup = BeautifulSoup(response.text, 'html.parser')

print()   
for li in soup.find_all('li'):
    if x := li.find('span', class_='release-number'):
        if y := x.find('a'):
            if z := li.find('span', class_='release-date'):
                release.append((y.text, z.text))

release.sort()
for name, date in release:
    print(f'{name:15}{date}')

• コマンドプロンプト
  ベース環境の中には、pip しか入っていません。

PS C:\Python_Sample\01_scraping_01> pip list
Package Version
------- -------
pip     24.2   
PS C:\Python_Sample\01_scraping_01> dir



    ディレクトリ: C:\Python_Sample\01_scraping_01


Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----        2024/11/02     16:30            873 scraip_01.py


PS C:\Python_Sample\01_scraping_01>

仮想環境の作成

• 仮想環境は以下のコマンドで作成します。環境名には、プロジェクトに合った名称をつけます。

python -m venv 環境名

• 下記のコマンドで仮想環境を作成します。

python -m venv v_scraping

そうすると、「v_scraping」フォルダが作成され、フォルダには下記の内容が作成されます。

ディレクトリ: C:\Python_Sample\01_scraping_01


Mode                 LastWriteTime         Length Name                                                                              
----                 -------------         ------ ----
d-----        2024/11/10     12:42                v_scraping
-a----        2024/11/02     16:30            873 scraip_01.py


PS C:\Python_Sample\01_scraping_01> cd v_scraping  
PS C:\Python_Sample\01_scraping_01\v_scraping> dir


    ディレクトリ: C:\Python_Sample\01_scraping_01\v_scraping


Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d-----        2024/11/10     12:42                Include
d-----        2024/11/10     12:42                Lib
d-----        2024/11/10     12:43                Scripts
-a----        2024/11/10     12:42             71 .gitignore
-a----        2024/11/10     12:42            222 pyvenv.cfg

仮想環境の起動

• 仮想環境は以下のコマンドで起動します。

環境名\Scripts\Activate

• 実際に仮想環境を起動してみます。起動すると、コマンドプロンプトの先頭に(環境名)が表示されます。又、仮想環境の中にも、pip しか入っていません。

PS C:\Python_Sample\01_scraping_01> v_scraping\Scripts\Activate
(v_scraping) PS C:\Python_Sample\01_scraping_01> pip list
Package Version
------- -------
pip     24.2
(v_scraping) PS C:\Python_Sample\01_scraping_01> 

• スクレイピングに必要な、Beautiful SoupとRequests ライブラリを仮想環境でインストールします。

(v_scraping) PS C:\Python_Sample\01_scraping_01> pip install beautifulsoup4
Collecting beautifulsoup4
  Downloading beautifulsoup4-4.12.3-py3-none-any.whl.metadata (3.8 kB)
Collecting soupsieve>1.2 (from beautifulsoup4)
  Downloading soupsieve-2.6-py3-none-any.whl.metadata (4.6 kB)
Downloading beautifulsoup4-4.12.3-py3-none-any.whl (147 kB)
Downloading soupsieve-2.6-py3-none-any.whl (36 kB)
Installing collected packages: soupsieve, beautifulsoup4
Successfully installed beautifulsoup4-4.12.3 soupsieve-2.6

[notice] A new release of pip is available: 24.2 -> 24.3.1
[notice] To update, run: python.exe -m pip install --upgrade pip
(v_scraping) PS C:\Python_Sample\01_scraping_01> pip install requests
Collecting requests
Collecting charset-normalizer<4,>=2 (from requests)
  Downloading charset_normalizer-3.4.0-cp313-cp313-win_amd64.whl.metadata (34 kB)
Collecting idna<4,>=2.5 (from requests)
  Downloading idna-3.10-py3-none-any.whl.metadata (10 kB)
Collecting urllib3<3,>=1.21.1 (from requests)
  Downloading urllib3-2.2.3-py3-none-any.whl.metadata (6.5 kB)
Collecting certifi>=2017.4.17 (from requests)
  Downloading certifi-2024.8.30-py3-none-any.whl.metadata (2.2 kB)
Downloading requests-2.32.3-py3-none-any.whl (64 kB)
Downloading certifi-2024.8.30-py3-none-any.whl (167 kB)
Downloading charset_normalizer-3.4.0-cp313-cp313-win_amd64.whl (102 kB)
Downloading idna-3.10-py3-none-any.whl (70 kB)
Downloading urllib3-2.2.3-py3-none-any.whl (126 kB)
Installing collected packages: urllib3, idna, charset-normalizer, certifi, requests
Successfully installed certifi-2024.8.30 charset-normalizer-3.4.0 idna-3.10 requests-2.32.3 urllib3-2.2.3

[notice] A new release of pip is available: 24.2 -> 24.3.1
[notice] To update, run: python.exe -m pip install --upgrade pip
(v_scraping) PS C:\Python_Sample\01_scraping_01> pip list
Package            Version
------------------ ---------
beautifulsoup4     4.12.3
certifi            2024.8.30
charset-normalizer 3.4.0
idna               3.10
pip                24.2
requests           2.32.3
soupsieve          2.6
urllib3            2.2.3
(v_scraping) PS C:\Python_Sample\01_scraping_01> 

• そうすると、Beautiful SoupとRequests 関連のライブラリがインストールされ、仮想環境で使用可能となります。

仮想環境の停止

• 仮想環境を停止するには、deactivate コマンドを使用します。

deactivate

• 実際に仮想環境を停止してみます。

(v_scraping) PS C:\Python_Sample\01_scraping_01> deactivate
PS C:\Python_Sample\01_scraping_01> pip list
Package Version
------- -------
pip     24.2
PS C:\Python_Sample\01_scraping_01> 

• 仮想環境を停止して、インストールしているライブラリを見てみると、ベース環境では pip しかインストールされていません。つまり、仮想環境で構築した環境は独立しており、ベース環境には影響を及ぼさない事が分かります。

更に、仮想環境 v_scraping2を作成してみましょう。

PS C:\Python_Sample\01_scraping_01> python -m venv v_scraping2
PS C:\Python_Sample\01_scraping_01> v_scraping2\Scripts\Activate
(v_scraping2) PS C:\Python_Sample\01_scraping_01> pip list
Package Version
------- -------
pip     24.2   
(v_scraping2) PS C:\Python_Sample\01_scraping_01> 

• v_scraping2 でもライブラリは pip しかインストールされていません。この事より、仮想環境「v_scraping」と「v_scraping2」も、それぞれ影響されない「独立した環境」である事が分かります。

VSCodeでの、Python 仮想環境のまとめ

• 各仮想環境が独自のsite-packagesディレクトリを持つため、複数のプロジェクトが異なるバージョンのライブラリを必要とする場合でも、お互いに影響しないで使用できる。
  
  
• Pythonのベース環境を作成（インストール）し、VSCodeのパレット（Ctrl + Shift + P または Cmd + Shift + P）で、「Python：インタープリターを選択」を選択し、インストールしたPythonと関連付ける。
  
  
• 仮想環境の作成：
  「python -m venv 環境名」コマンド
  
  
• 仮想環境の起動：
  「環境名\Scripts\Activate」コマンド
  
  
• 仮想環境の終了：
  「deactivate」コマンド
  
  

●インストール環境（2024年9月現在）

• Windows 10 Pro 22H2　（19045.4894）
• Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz 3.19 GHz
• 16.0 GB

Anaconda をインストールする目的

• 環境構築の手間を減らしたい
  • Anacondaは、Python や R 言語、Jupyter Notebook など 1000以上のライブラリ が標準でインストールされるため、すぐに開発を始められます。
    ただし、サイズが約４GBと大きく自身の開発に不要なパッケージが含まれることもあります。

Anaconda のインストール

Anaconda インストーラーのダウンロード

下記の公式Webサイトのダウンロードページから、インストーラーをダウンロードしてインスト―ルします。

Anaconda 公式サイト

※以下の画面はGoogleの翻訳機能で日本語に翻訳しています。

画面上部右側の「↓ 無料ダウンロード」をクリック。

次の画面で以下を入力し、「提出する >」ボタンをクリック。又は、「登録をスキップ」する。

• メールアドレス
• サービスに関する連絡の受け取り
  • 同意するならば✔、しない場合は✔しない

下記の画面でWindows版 64bit インストーラーをクリックすると、Windows版の最新インストーラー「Anaconda3-2024.10-1-Windows-x86_64.exe」がダウンロードされます。

インストールの開始

ダウンロードした「Anaconda3-2024.10-1-Windows-x86_64.exe」をダブルクリックしてインストールします。Welcom to Anaconda3 の画面が表示されたら、「NEXT」ボタンをクリックします。

ライセンス契約への同意画面が表示されるので、内容を確認し同意可能だったら、「I Agree」ボタンをクリックします。

自分だけが使用する場合は、「Just Me」、他のユーザーも使用する場合は「All Users」を選択し、「Next」ボタンをクリックします。

インストール先を聞いてくるので、標準フォルダで良ければそのまま、カスタムフォルダにインストールする場合は、カスタムフォルダ名を入力して「Next」ボタンをクリックします。

インストールのオプションを指定します。ここでは以下の2つのオプションをチェックしました。

• Create shortcuts(supported packege only)
• Clear the package cache upon completion.

■オプションの意味

• Create shortcuts(supported packege only)
  Anacondaに含まれるいくつかのアプリケーション（例: Jupyter Notebook、Spyderなど）のショートカットを、スタートメニューに作成するオプションです。
  
  
• Add anaconda3 to my PATH environment variable.
  Anaconda3をPATH環境変数に追加するオプションですが、このオプションは選択しないのが推奨されています。Anacondaには専用の環境管理システム（Conda）があるため、PATHに追加すると他のPython環境と競合する可能性があるためです。
  
  
• Register anaconda3 as my default Python 3.12
  VSCode や PyCharm などの他のプログラムが、Anaconda3 をシステム上の主要な Python 3.12 として自動的に検出できるようにするオプションです。
  
  Anaconda をメインで使いたい場合は✔し、既存の Python 環境を維持したい方は✔しない方が良いでしょう。
  
  
  
• Clear the package cache upon completion.
  Anacondaが一時的に保存したキャッシュファイル（インストール済みのパッケージのコピーやメタデータ）を削除するか否かを指定します。指定すると、ディスクスペースが節約され、クリーンな状態が保たれます。
  
  

インストール進行中の表示です。

インストール完了のメッセ―ジが表示されるので、「Next」ボタンをクリックします。
画像は「Show details」ボタンをクリックした時の表示です。

下記のダイアログボックスには、
「Anacondaのフル装備のJupyter Notebookを使えば、セットアップ不要でクラウドから利用可能になります。無料で始めましょう。」と記入されています。「Next」ボタンをクリックします。

インストール終了のメッセージが表示されます。「Finish」ボタンをクリックしてインストールを終了しますが、「Launch Anaconda Navigator」と「Getting Started with Anaconda Distribution」にチェックが入っているので、ここでは両方ともチェックを外します。必要な場合はチェックを入れて下さい。

Anaconda インストール結果の確認

「スタート」から「Anaconda Prompt」を選択します。

「conda」コマンドで、正しいバージョンやヘルプが表示できればインストールは成功です。

Anaconda インストールまとめ

「Anaconda」は公式ホームページから、インストーラーをダウンロードしてインストールします。
Anaconda 公式サイト

システム開発に必要なライブラリは本体のインストールと同時にインストールされ、すぐに開発が始められます。但し、サイズが約４GBと大きく自身の開発に不要なパッケージが含まれている可能性がある事を認識しておきましょう。

PostgreSQLを使った業務システム開発において、ストアドプロシジャ（PROCEDURE）とストアドファンクション（FUNCTION）は、処理の再利用性や保守性を高める重要な要素です。

本ブログでは、「psql」と「pgAdmin4」を使って、簡単な「本の在庫管理システム」を題材に、両者の違いや使い方を紹介します。

使用環境

• Windows 11 Pro 24H2
• PostgreSQL 17.6
• pgAdmin4 9.6
• Chrome 134.0.6998.205

ストアドファンクション（Stored Function）とは？

ストアドファンクションは、値を返す処理を定義するSQLの関数です。たとえば「在庫数を取得する」「売上を計算する」といった処理を関数として定義し、SELECT文などから呼び出すことができます。

• 特徴
  • RETURNS で戻り値を定義
  • SELECT や PERFORM で呼び出し
  • 単一の値や集計結果を返す用途に最適
• 基本構文

CREATE [OR REPLACE] FUNCTION 関数名(引数 型, ...)
RETURNS 戻り値の型
LANGUAGE plpgsql
AS $$
DECLARE
  -- 変数宣言（任意）
BEGIN
  -- 処理内容
  RETURN 戻り値;
END;
$$;

ストアドプロシジャ（Stored Procedure）とは？

ストアドプロシジャは、複数ステップの処理や副作用を伴う業務ロジックをまとめた手続き型の処理です。たとえば「在庫を更新し、ログを記録する」といった一連の処理を1つのプロシジャにまとめることができます。

• 特徴
  • 戻り値はなし（ただしOUTパラメータは使える）
  • CALL で呼び出し
  • BEGIN, COMMIT, ROLLBACK によるトランザクション制御が可能
  • 複雑な業務処理に適している
• 基本構文

CREATE [OR REPLACE] PROCEDURE プロシジャ名(引数 型, ...)
LANGUAGE plpgsql
AS $$
DECLARE
  -- 変数宣言（任意）
BEGIN
  -- 処理内容（複数ステップ可）
  -- トランザクション制御も可能
END;
$$;

ストアドファンクション・ストアドプロシジャの作成と実行

テーブルの作成

先ず 以下のテーブルを作成します。

• booksテーブル
  在庫数テーブル。在庫数を入力しておき、ストアドファンクションから参照されます。

CREATE TABLE books (
  book_id SERIAL PRIMARY KEY,
  title TEXT NOT NULL,
  stock INT DEFAULT 0
);

• stock_logs
  在庫数の変化を記録するログテーブルです。ストアドプロシジャによって更新されます。

CREATE TABLE stock_logs (
  log_id SERIAL PRIMARY KEY,
  book_id INT REFERENCES books(book_id),
  change INT,
  log_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

ストアドファンクションの作成

在庫数を取得するストアドファンクションを作成します。

記号：$$は、「ドルクオート（dollar-quoting）」と呼ばれる構文で、関数やプロシジャの本体（つまりPL/pgSQLコード）を囲むための区切り記号です。

-- 関数を作成または置き換える（既存の関数があれば上書き）
CREATE OR REPLACE FUNCTION get_stock(book_title TEXT)
-- 戻り値の型を指定（在庫数：整数）
RETURNS INT AS $$
-- 変数宣言部：在庫数を一時的に保持する変数
DECLARE
  current_stock INT;
BEGIN
  -- booksテーブルから、指定されたタイトルの在庫数を取得し、変数に格納
  SELECT stock INTO current_stock
  FROM books
  WHERE title = book_title;
  -- 取得した在庫数を関数の戻り値として返す
  RETURN current_stock;
END;
-- PL/pgSQL言語で記述された関数であることを指定
$$ LANGUAGE plpgsql;

psqlでの作成

psqlに「CREATE FUNCTION…」文を入力して作成。

pgadmin4 での作成

• 「関数」右クリック⇀「作成」⇀「関数」

• 「一般」タブにストアドファンクションの名称を入力

• 「定義」タブで、「返り値の型」「言語」「引数」を以下の様に設定

• 「コード」タブには、「DECLARE」文から「END;」までを作成して入力

• 「オプション」タグの動作属性に、「STABLE」を指定

• 「パラメータ」タグには下記の値を指定
  • client_min_messages
    • クライアント向けにどのレベルのログ情報出力を指定するかのパラメタ
  • debug1
    • 一般的なデバッグ情報（ユーザー向け）

• 「保存」ボタンをクリック
  内容は、上記の指定でpgadmin4 が作成した「get_stock」ストアドファンクション

• 「ストアドファンクション」の詳細については、以下の公式サイトを参照ください。

CREATE FUNCTION（公式ドキュメント）

ストアドプロシジャの作成

在庫数の変化を「stock_logs」テーブルに記録するストアドプロシジャを作成します。

psqlでの作成

psqlに「CREATE PROCEDURE…」文を入力して作成。

pgadmin4 での作成

• 「プロシージャ」右クリック⇀「作成」⇀「プロシージャ」

• 「一般」タブにストアドプロシジャの名称を入力

• 「定義」タブで、「言語」「引数」を以下の様に設定

• 「コード」タブには、「DECLARE」文から「END;」までを作成して入力

• 「パラメータ」タブは「ストアドファンクション」と同様に設定。

• 「SQL」タグで内容を確認し、「保存」ボタンをクリック
  • 内容は、上記の指定でpgadmin4 が作成した「update_stock_and_log」ストアドプロシジャ

• 「ストアドプロシジャ」の詳細については、以下の公式サイトを参照ください。

CREATE PROCEDURE（公式ドキュメント）

ストアドファンクション・ストアドプロシジャの実行

手動実行（psql）して、「ストアドファンクション」及び「ストアドプロシジャ」が正常動作する事を確認します。

【結果】：psql でもadmin4 でも正常動作を確認できました。（当たり前です）

• ストアドファンクション

psql SELECT 関数名(……)

pgadmin4 SELECT 関数名(……)

• ストアドプロシジャ

psql CALL プロシジャ名(…..)

pgAdmin4 CALL プロシジャ名(…..)

有効活用できる場面

ストアドファンクション

• 集計や計算ロジックを共通化したいとき
• SELECT文の中で使用したいとき
• トリガーで呼びたいとき
• トリガーで呼び出したいとき
  • レコードを追加した後での自動処理等

ストアドプロシジャ

• 複数の更新・挿入処理をまとめたいとき
  • 在庫更新＋ログ記録等
• トランザクション制御を含めたいとき
  • BEGIN ... COMMIT を明示的に扱える
• 外部から明示的に呼び出す業務処理
  • バッチ処理やAPI連携のエントリポイントとして

まとめ

本ブログでは以下の事項を紹介しました。

• ストアドファンクションとストアドプロシジャの違い
• ストアドファンクションとストアドプロシジャの主な用途
• psql と、pgadmin4（GUI）による作成方法
• ストアドファンクションとストアドプロシジャの実行方法
• 有効活用できる場面

ストアドファンクションやストアドプロシジャは、データベースの中で処理を共通化できる事、及びトリガーに応じて起動できる点で有効性が高いと考えられます。但し、ストアドプロシジャは、トリガー関数等を使用する必要が有りますが…。

今回、pgadmin4 でも作成しましたが、初心者にとっては最初の理解に役立つと思うが、一度覚えてしまったら手数の多さが気になって使用しなくなるのではないかと思いました。実際、処理の部分は自分で作成するわけで、ＧＵＩのメリットが十分生かされていないと感じた。但し、デバッグできるのは魅力。

TypeScriptは、JavaScriptに型安全性を加えた強力な言語です。最近ではReactやNode.jsなどの開発でも主流となりつつあります。

本ブログでは、初心者でも迷わずVSCodeでTypeScript開発環境を構築できるように、手順をおって紹介します。

TypeScriptとは？　なぜ使用するのか？

TypeScriptは、型定義やクラスベースの構文などを追加することで、保守性・可読性・安全性を向上させます。

例えば、以下のようなコードで型エラーを防ぐことが可能です。

function greet(name: string) {
  return `Hello, ${name}`;
}
greet(42); // エラー：number型はstring型に代入できません

開発環境の準備

VSCodeのインストール

VSCodeのインストールは、以下のブログを参考にして下さい。

VSCodeのインストール

Node.jsのインストール

TypeScriptはNode.js環境で動作します。Node.jsは下記の公式サイトからインストールしてください。

Node.jsの公式サイト

インストール後、ターミナルで以下を確認します。各バージョンが表示されれば正常です。

• npm（エヌピーエム）コマンドは Node Package Manager の略で、Node.jsのためのパッケージ管理ツールです。

node -v   # Node.jsのバージョン確認
npm -v    # npmのバージョン確認

Node.js 環境とは

通常、JavaScriptはブラウザ上でしか動作しません（例：Chromeの開発者ツールなど）。しかし、Node.jsを使用する事で、JavaScriptをPC上で直接実行できるようになります。

PC上で実行する事により、以下が可能となります。

• ブラウザでは制限されていた「ファイル操作」「ネットワーク通信」「プロセス管理」
• サーバーアプリケーションやCLIツール（コマンドラインインタフェースで動作するツール）の開発

// ファイルを読み込む例（Node.js環境）
import { readFileSync } from 'fs';
const data = readFileSync('data.txt', 'utf-8');
console.log(data);

TypeScriptのインストール

本ブログでは、「TypeScript_prj」フォルダを作成し、プロジェクトにTypeScriptを適用させる方式で進めます。

以下のコマンドを実行し、TypeScriptをインストールします。

mkdir TypeScript_prj
cd TypeScript_prj
npm init -y
npm install --save-dev typescript
npx tsc --init

• 補足：グローバル環境にTypeScriptを適用させる場合は以下のコマンドでインストールします。

npm install -g typescript

tsconfig.jsonの基本設定

tsconfig.jsonはTypeScriptコンパイラ（tsc）の動作を制御するための設定ファイルです。これにより、どのファイルをどう変換するか、どんな型チェックを行うか、成果物をどこに出力するかなどを一元管理できます。

• 基本構成
  以下は「ESM対応」「型安全性」「ライブラリ公開」などを意識したTypeScript設計です。

{
  // Visit https://aka.ms/tsconfig to read more about this file
  "compilerOptions": {
    // File Layout
    "rootDir": "./src",
    "outDir": "./dist",

    // Environment Settings
    // See also https://aka.ms/tsconfig/module
    "module": "esnext",
    "target": "esnext",
    "types": [],

    // Other Outputs
    "sourceMap": true,
    "declaration": true,
    "declarationMap": true,

    // Stricter Typechecking Options
    "noUncheckedIndexedAccess": true,
    "exactOptionalPropertyTypes": true,

    // Recommended Options
    "strict": true,
    "jsx": "react-jsx",
    "verbatimModuleSyntax": true,
    "isolatedModules": true,
    "noUncheckedSideEffectImports": true,
    "moduleDetection": "force",
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  }
}

• パラメータの内容

パラメータの詳細については、以下のサイトを参照ください。

• 公式ハンドブック
• 公式 tsconfig オプション一覧

package.json の設定

• 役割
  Node.js／JavaScriptプロジェクトの構成・依存関係・スクリプトを管理する中心ファイル。

{
  "devDependencies": {
    "typescript": "^5.9.2"
  },
  "name": "typescript_prj",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "type": "module"
}

プロジェクトのディレクトリ構成を整える

tsconfig.json の基本設定が完了したら、TypeScriptプロジェクトとしての土台が整った状態です。ここからは、実際にコードを書いて、コンパイル・実行・開発環境を整えるステップに進みます。

・TypeScript_prj内をtsconfig.jsonに合わせて構成します。

TypeScript_prj/
├── src/                ← TypeScriptファイルを置く場所
│   └── index.ts       ← エントリーポイント
├── dist/               ← コンパイル後の出力先（tsconfigで指定済み）
├── tsconfig.json       ← コンパイラ設定ファイル
├── package.json        ← npm管理ファイル
├── package-lock.json   ← npmの依存パッケージと構成を記録する自動生成するファイル
├── .vscode/　　　　　　← （VSCode）でプロジェクトごとの開発環境設定を保存
├── node_modules/　　　 ← npmでインストールしたパッケージを保存

以上で、TypeScript環境の構築は完了です。

サンプルプログラムの動作確認

サンプルプログラムの作成・コンパイル・デバッグ

• サンプルプログラムの作成
  index.ts をsrcディレクトの中に以下の内容で作成します。

// src/index.ts
const greet = (name: string): string => {
  return `こんにちは、${name}さん！`;
};

console.log(greet("太郎"));

• コンパイル
  VSCodeのターミナルで以下のコマンドを実行。今回の設定では、src/ディレクト内の全ての.tsファイルがコンパイルされ、dist/ディレクトに出力されます。

npx tsc

• コンパイルされた、index.js

launch.jsonの設定

• 役割
  Visual Studio Codeで、デバッグの構成を設定するためのファイルで、どのファイルをどう実行するか、どの環境で動かすか、引数や環境変数などを定義します。

// .vscode/launch.json
{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Debug TypeScript",
      "type": "node",
      "request": "launch",
      "program": "${workspaceFolder}/dist/index.js",
      /* "preLaunchTask": "tsc: build - tsconfig.json",　←　自動コンパイルを
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　コメントアウト */
      "outFiles": ["${workspaceFolder}/dist/**/*.js"]
    }
  ]
}

• launch.jsonの作成方法
  • ①デバッグアイコンをクリック
  • ②「launch.json ファイルを作成します。」をクリック
  • ③内容を入力。”program”パラメーターには今回デバッグする.jsの名称が入る。

• デバッグ
  • ①index.js を開いて、ブレークポイントを設定
  • ②「デバッグ開始」をクリック
  • ブレークポイントでブレークし、デバッグ可能となる

「VSCodeでTypeScript開発環境を構築する」　まとめ

ここまで、VSCodeでTypeScriptを使用できる環境の設定方法を紹介してきました。

• TypeScriptは、JavaScriptに型安全性を加えた強力な言語であること
• TypeScriptは、Node.js環境で動作すること
• TypeScriptのインストール方法と、プロジェクトの初期化
• tsconfig.jsonの基本設定
• .tsファイルのコンパイル
• VSCodeにTypeScript環境を構築
• コンパイルした.jsファイルをVSCodでデバッグ

超初心者の方は、インストールや設定ファイルが多くあり、苦労されたかもしれません。基本をしっかりと身に着けたあとは、ReactやVueと組み合わせたTypeScript開発に挑戦してみて下さい。