2026.05.01

「サイト公開」の裏側をPLCエンジニア目線で読み解く——Markdown執筆からデプロイまでの全工程

全工程の対応表

まず全体像を見てください。

以降、各工程を順番に掘り下げます。

GX Works2を起動してラダー図を書く、あの作業です。

エンジニアリング端末（PC）の上で、制御ロジックを記述・修正する。この段階ではまだ実機には何も起きていません。ファイルはローカルにあるだけで、PLCはひとつ前のプログラムで動き続けています。

Webの世界でも同じです。Markdownで記事を書いている間、サイトは何も変わっていません。テキストエディタの中にだけ、新しいコンテンツが存在しています。

Markdownとは、## で見出しを作り、**太字** で強調するといった、シンプルな記法でドキュメントを書くための書式です。HTMLを直接書く必要がなく、文章の構造だけに集中できます。

Webサイトには大きく2種類あります。この違いを知っておくと、なぜHugoを選んだのかが腑に落ちます。

動的サイト（WordPressなど） は、アクセスのたびにサーバー側でページを生成して返します。PLCプログラムに例えると、入力信号を読んでそのつど出力を演算する——通常のシーケンス制御の動作です。条件次第で出力が変わるため柔軟ですが、サーバーに処理負荷がかかり、維持費も発生します。

静的サイト（Hugo） は、あらかじめ完成したHTMLファイルをそのまま返すだけです。有接点リレーで組んだ回路に例えると分かりやすい。配線が決まれば毎回同じ動作をする。演算も判断もしない。その分、表示が速く・壊れにくく・維持費がかからない。

ブログのように「毎回同じページを表示するだけでいい」用途なら、静的サイトで十分です。むしろその方が優れています。

ラダー図やST言語で書かれたプログラムは、人間には読みやすくてもPLCのCPUはそのままでは実行できません。GX Works2がコンパイルして、CPUが解釈できるバイナリ命令に変換します。

Hugoの役割はこれと同じです。

Markdownで書かれたファイルは、ブラウザがそのまま表示することができません。Hugoがhugo --minifyコマンド一発で**HTMLファイルに一括変換（ビルド）**します。この変換によって、ブラウザが読める形式のファイル群がpublic/フォルダに生成されます。

コンパイルが完了して初めて「書き込める状態」になる——その感覚と完全に一致します。

PLCのプログラムを修正したとき、エンジニアリングツールのプロジェクトファイルを構成管理サーバーに保存しますね。「誰が・いつ・どこを変えたか」を記録しておくための、バックアップ兼マスター保管庫です。

GitHubはこれに相当します。

git pushというコマンドを実行すると、ローカルのファイル変更履歴がGitHub上のリポジトリ（プロジェクトの保管場所）に転送・登録されます。変更前の状態はすべて履歴として残るため、誤って記事を壊しても以前のバージョンに戻すことができます。

PLCプロジェクトのバックアップと違うのは、変更の差分が行単位で記録される点です。「3行目を書き換えた」「この段落を追加した」という単位で、いつでも見返すことができます。

GitHubへのPushを検知して、Cloudflare Pagesが自動的に動き出します。

「管理サーバーの更新を検知して、現場のPLCに自動で一括書き込みを実行する」——まさにこの動作です。手動でトリガーを引く必要はありません。Pushした瞬間に連携が走り、数分以内に世界中のCloudflareサーバーへ最新ファイルが配信されます。

ここで重要なのは、この更新フローが**「オフラインエディット→コンパイル→一括書き込み」という手順を自動で保証している**点です。

PLCの現場でオンラインエディットを多用するとリスクがあります。変更履歴が残りにくく、コンパイルを経ない直接書き換えはヒューマンエラーの温床になります。

このWebのデプロイフローにはその心配がありません。Markdownを書く→Hugoでビルドする→GitHubにPushする→Cloudflareが反映する、という順序が崩れる余地がなく、安全な一括更新ラインとして自動化されています。

PLCへの書き込みが完了し、ラインがRUN状態になりました。HMIや上位のSCADAシステムから、いつでも最新のロジックで動く設備を監視・操作できる状態です。

Webも同じです。デプロイが完了した瞬間から、世界中のどこからでもブラウザで記事にアクセスできるようになります。URLを知っている人全員が「閲覧者（オペレーター）」として、最新のコンテンツを参照できる状態になります。