正規表現・Cron式・YAML、「たぶん合っている」のまま本番に入れていませんか

編集: BrowserTools.jp　2026-09-29

正規表現やCron式、YAMLの設定ファイルは、どれも数行で書けてしまう一方で、書いた本人が読み返しても間違いに気づきにくいという共通点があります。構文エラーなら実行時にすぐ分かりますが、厄介なのは「エラーは出ないのに、意図と違う動きをする」ケースです。

ここでは、本番環境に入れてから気づくことが多い落とし穴と、その前に手元のブラウザで確かめておく方法を整理します。

⚠️ ここで紹介する確認方法は、「意図と違う解釈になっていないか」を見つけるためのものです。実際の動作環境（言語・ライブラリ・サーバー設定）での最終確認の代わりにはならない点に注意してください。

書いた正規表現・Cron式・YAMLを、マッチ箇所・日本語・JSONという別の形に直して確かめてから本番へ入れる流れ

正規表現：同じパターンでも、言語によって結果が変わる

正規表現には、言語やライブラリごとに細かな方言（同じ書き方でも処理系によって意味や対応状況が違うこと）があります。たとえば\dは、JavaScriptでは半角数字の0〜9だけにマッチしますが、Pythonでは標準の設定のまま全角数字にもマッチします。名前付きグループの書き方も、Pythonの(?P<name>...)はJavaScriptではエラーになります。

もう一つよくあるのが改行の扱いです。Windowsで作ったテキストは改行が2文字（CR+LF）になっていることがあり、「1行の末尾」を前提にしたパターンが、別の環境から持ってきたデータでは思ったように動かないことがあります。

パターンの検証には、マッチした箇所をハイライトしながらキャプチャグループの中身まで一覧で確認できる正規表現テストツールが使えます。このツールはブラウザに内蔵されたJavaScriptの正規表現エンジンでそのまま判定するため、フロントエンドやNode.jsで使うパターンならほぼそのまま、それ以外の言語で使う場合は「方言の違いがありうる参考結果」として扱うのが安全です。

Cron式：「何時に動くか」は書いた式だけでは決まらない

Cron式（定期実行のスケジュールを「分時日月曜日」の5つの値で表す書式）は、短いぶん読み違えが起きやすい書式です。特に次の3点は、式そのものは正しくても意図と違う結果になりがちです。

タイムゾーン：Cron式の「9時」が何時を指すかは、それを実行するサーバーやサービスの設定で決まります。クラウドのスケジューラーやCIサービスでは協定世界時（UTC）基準のものが多く、日本時間の9時に動かしたいつもりで0 9 * * *と書くと、実際には日本時間の18時に動くことがあります。
日と曜日の同時指定：多くのCron実装では、「日」と「曜日」の両方に値を入れると、両方を満たす日ではなく、どちらか一方を満たす日に実行されます。「毎月1日が月曜なら」のつもりが、「毎月1日」と「毎週月曜」の両方で動いてしまう典型例です。
存在しない日付：「毎月31日」と指定すると、31日がない月には実行されません。月末処理のつもりなら別の方法を検討する必要があります。

書いたCron式を日本語の「毎週月曜9時」のような表現に戻して読めるCron式変換ツールにかけると、式が実際に何を意味しているかを自然な文章で確認できます。このツールは「第2月曜日」のような複雑な条件や月の指定にはあえて対応しておらず、範囲外の式は誤った解釈で表示する代わりにエラーにしています。日本語に変換できなかった式は、それだけ読み違えやすい式だと考えて、チームでもう一度確認するきっかけにしてください。

YAML：書いた値が、文字列のままとは限らない

Docker ComposeやGitHub Actions、Kubernetesの設定などで使われるYAMLは、引用符を付けなくても値を書けるのが利点ですが、そのぶん値の型（文字列なのか数値なのか真偽値なのか）を処理側が自動で判断します。

version: 1.10と書くと、文字列の「1.10」ではなく数値の1.1として読み込まれます。
zip: 0123456のように先頭が0の値は、処理系によって先頭の0が消えたり、8進数として解釈されたりします。北海道の郵便番号や社員番号などで起きやすいミスです。
noやonといった単語を真偽値（true/false）として扱う処理系もあります。どう解釈されるかは、読み込むプログラムがYAMLのどの版に準拠しているかで変わります。
インデントにタブ文字は使えません。

こうした「見た目では区別がつかない型の違い」を確かめるには、いったんJSONに変換してみるのが手軽です。JSONでは文字列が必ず引用符付きで表示されるため、どの値が数値や真偽値として扱われたかが一目で分かります。YAMLとJSONを貼り付けるだけで相互に変換できるツールなら、アンカー（&）やマージキー（<<:）を使った設定も展開後の形で確認できます。意図と違う型になっていた値は、YAML側で引用符で囲んでおくと確実です。

なお、JSONにはコメントの概念がないため、変換結果にYAMLのコメントは残りません。確認用の変換と、実際に使うファイルは分けて扱ってください。

テストデータ：本番データのコピーで確かめない

設定や正規表現を検証するとき、手元にある本番データをそのままテストに使ってしまうことがあります。しかし、顧客の氏名や住所を含むデータを開発環境や個人のPCに持ち出すこと自体が、情報管理上のリスクになります。

CREATE TABLE文を貼り付けるだけで、列の型や名前に合ったダミーデータを作れるSQLテストデータ生成ツールを使えば、架空の氏名・メールアドレス・住所でINSERT文・CSV・JSONを用意できます。MySQL・PostgreSQL・SQL Server・Oracle・SQLiteなど主要なデータベースに対応し、自動採番の列は値を入れずに除外されます。ただし、OracleでSEQUENCEとTRIGGERを組み合わせた従来方式の採番列はCREATE TABLE文だけでは判別できないため、生成後に手で調整が必要です。

確かめた内容は、手順書に残しておく

最後に、確認した結果は「なぜこの書き方にしたのか」とあわせて記録しておくと、後から設定を変更する人が同じ落とし穴にはまるのを防げます。たとえば「このCron式はUTC基準なので日本時間では18時」「この値は数値化を防ぐため引用符付き」といった一言です。

READMEや運用手順書をMarkdownで書いているなら、Markdownをその場でプレビューしながらHTMLやPDFにできる変換ツールで、エンジニア以外のメンバーにも読みやすい形にして共有できます。ただし、Markdownは表示するサービスによって改行の扱いなど細かな表示が異なることがあるため、最終的に掲載する場所での見え方も一度確認してください。

まとめ：「別の形」に直して読み返す

正規表現はマッチ結果に、Cron式は日本語に、YAMLはJSONに。書いたものを別の形に直して読み返すだけで、「書いた本人には正しく見える」ミスの多くは本番前に見つけられます。