ブログ
開発者向けガイドと深掘り解説
開発ワークフロー、データ形式、日々の実装課題を扱う実践的な記事です。手順だけでなく、ツールを使う理由も説明します。
- SSL / TLS / SAN / SNI / ドメイン / HTTPS
SSL 証明書とドメインが一致しない理由：SAN・ワイルドカード・SNI の確認
証明書の名前不一致は、申請ミスだけが原因ではありません。要求したホスト名、SAN、ワイルドカードの範囲、SNI、DNS、CDN、ロードバランサーのどれかで別の証明書を受け取ることがあります。公開経路をたどって誤った証明書を返す入口を見つけます。
記事を読む - SSL / TLS / 証明書チェーン / 中間証明書 / HTTPS
証明書チェーンが不完全なのはなぜ？中間証明書を確認して直す方法
証明書チェーンのエラーは、中間証明書の欠落だけが原因ではありません。公開先が古いチェーン、私設 CA、または期限切れを含むチェーンを返している場合もあります。公開ハンドシェイクと配備内容を照合し、実際の TLS 終端を直す手順を解説します。
記事を読む - メール / ヘッダー / DMARC / セキュリティ / フィッシング
メールヘッダーの読み方（偽装された差出人を見抜く）
ヘッダーはメールがどう届いたかを示す唯一の一次記録です。Authentication-Results を読み、Received を下から追い、なりすましが残す痕跡を見分ける方法。
記事を読む - SSL / TLS / 証明書 / HTTPS / セキュリティ
SSL 証明書が無効になる理由と、順序立てた切り分け方
ブラウザの証明書警告は、証明書ファイルだけの問題とは限りません。有効期限、SAN、信頼チェーン、中間証明書、SNI、TLS、DNS を順に確認して原因を切り分けます。
記事を読む - メール / DMARC / SPF / DKIM / 到達率
p=none から p=reject へ、自社のメールを失わずに進める
DMARC を段階的に導入する手順。まず集約レポートを読み、正規の送信元をすべて洗い出してアライメントを整え、pct 廃止後は t=y をブレーキに使い、最後に強制へ移す。
記事を読む - メール / SPF / DKIM / DMARC / DNS
SPF・DKIM・DMARC はそれぞれ何をしているのか
3 つのレコード、3 つの別々の役割。SPF と DKIM が何を検証するのか、なぜアライメントこそが DMARC の要なのか、そして SPF に通ったのに DMARC で失敗する理由。
記事を読む - chmod / Unix / ファイル権限 / Linux
chmod しても Permission denied のまま？原因を切り分ける
chmod を変更しても Permission denied が消えないとき、原因はファイル自身とは限りません。親ディレクトリ、所有者、マウント、SELinux、ACL、特殊ビットを順に確認する方法を説明します。
記事を読む - chmod / Unix / ファイル権限 / Linux
chmod 644 と 755：ファイルとディレクトリはどう選ぶ？
通常ファイルは 644、ディレクトリや実行ファイルは 755 と言われますが、機械的に当てはめると危険です。再帰 chmod、umask、共有ディレクトリの setgid まで実務目線で整理します。
記事を読む - chmod / Unix / ファイルパーミッション / Linux
chmod 755 とは何か——どんなパーミッションも読めるようになる
755 の三桁は魔法ではなく、「誰が読み・書き・実行できるか」を表すコードだ。755・644・700 を一目で読み、実行ビットがディレクトリでは別の意味になる理由まで押さえる。
記事を読む - Cron / crontab / トラブルシューティング / DevOps
なぜ cron ジョブが動かないのか：気づきにくい失敗の切り分けガイド
「動かなかった」という一言は、まったく別の三つの失敗を覆い隠します。そもそも起動しなかったのか、起動したが最初の一歩で失敗したのか、正常に動いたのに見えていないだけなのか。まずはそれを切り分けます。出発点は cron のログです。
記事を読む - Cron / crontab / スケジューリング / DevOps
Cron スケジュール早見表：毎分・毎時・毎日・毎週・毎月
欲しい間隔はもう分かっている——5 分ごと、平日 9 時、毎月 1 日——あとは一行だけ。よくある要件を、そのままコピーできる cron 式で並べます。直感で書くと外す数例には、正しい書き方も添えます。
記事を読む - Cron / crontab / スケジューリング / DevOps
Cron 式の読み方（そして思ったとおりに動く式の書き方）
Cron は決まった位置に並ぶ五つのフィールドと、四つの記号にすぎない。どんなスケジュールもひと目で読めるようになり、正しく見える式を誤った時刻に動かす二つの罠を避けよう。
記事を読む - ハッシュ / チェックサム / 文字コード / デバッグ
同じファイルなのにハッシュ値が違うのはなぜ？
あるファイルのハッシュを計算し、同僚が同じファイルだと確信しているコピーを計算すると、ダイジェストが一致しない。ハッシュは、同じバイト列に対して必ず同じ結果を返す決定的な仕組みです。だから値が変わったのは、バイトが変わったからです――音もなく、目に見えない形で。この記事では、文字コード、BOM、改行、末尾の改行、テキストとバイナリのモード、構造化データ、詰め直したアーカイブという常連の原因を順に見ていき、最後に両者をそろえ直す正規化の方法まで示します。
記事を読む - ハッシュ / チェックサム / MD5 / SHA-256 / セキュリティ
MD5 と SHA-256、チェックサムにどちらを使うべきか
「MD5 は破られている、使うな」はよく聞く助言で、半分は正しく、だからこそ危険です。チェックサムに MD5 が十分か無謀かは、先に答えるべき一つの問いで決まります。誰かがあなたを欺こうとしているか、です。この記事はチェックサムの二つの仕事を切り分け、それぞれがどのハッシュを必要とするかを示し、なぜ「もっと強いハッシュ」がしばしば誤った対処なのかを説明します。
記事を読む - ハッシュ / チェックサム / 整合性 / デバッグ
チェックサムが一致しないのはなぜ？ハッシュ不一致の調べ方
チェックサムが合わないと警報のように感じます。でもこの警報は一段階しかありません。二つのバイト列が同じではない、それだけです。理由までは教えてくれません。大事なのはハッシュを取り直すことではなく、不一致を三つの原因に絞り込むこと。データが本当に違うのか、二つのハッシュを対等に比べていないのか、あるいは信じている参照値そのものが間違っているのか。この記事はその三つを順に見ていきます。
記事を読む - YAML / 文字列 / パース / 設定ファイル
YAML の複数行文字列：| を使うときと > を使うとき
YAML の複数行の値には、ブロック記号が二つ、縦棒と大なり記号がある。さらに引用符あり・なしの書き方も行をまたげる。改行を保つか畳むかの規則はどれも違い、選び間違えるとスクリプトが一行につぶれる。落とし穴も含め、全体像をまとめる。
記事を読む - YAML / パース / デバッグ / 設定ファイル
YAML はなぜ壊れるのか——大声のエラーと、静かなエラー
同じ朝に二つのチケットが来て、どちらも「YAML が壊れた」と言う。一つは 12 行目の赤い解析エラーで、一分で直る。もう一つはサービスが正常に起動したのに挙動がおかしい——引用符なしの値が、そっと別のものに変わっていた。これは正反対の問題で、危険なのは静かなほうだ。
記事を読む - JSON / YAML / TOML / 設定ファイル
JSON・YAML・TOML、設定ファイルはどれを選ぶべきか
小さな設定ファイルを一つ追加しただけの PR が、レビューで四十件のコメントに膨れ上がる——YAML？ TOML？ いっそ JSON？——そして何も変わらない。この議論は間違った問いで詰まっている。どの形式が一番いいか、ではない。最良など存在せず、どの形式も、最大の長所には見合った短所がついてくる。それが見えれば、選択はずっと単純な二つの問いに収束する。
記事を読む - JSON / jq / CLI
スクリプトを書かずに巨大な JSON ファイルから値を取り出す方法
開くことすらできないほど大きな JSON エクスポートから値をひとつ取り出すために、使い捨てのパーサを書く必要はない。JSON からデータを取り出すのは「クエリ」の問題であり、
記事を読むjq・JSONPath・DuckDB がそれに答える——メモリに収まらないほど大きなファイルまで。 - 基数 / 16 進数 / 2 進数
16 進数・2 進数・10 進数：プログラマーが実際に使う数の読み方
色は
記事を読む#FF5733。ファイルモードはchmod 755。権限チェックはflags & 0x04。定数は0b1010、あるいは0xFF、あるいは255。どれも別々の方言に見えて、実は一つの数が服を着替えただけだ——そして、これらすべてを摩擦でなくするのに要る習熟は見た目より小さい。バイトには 16 進、ビットには 2 進、人には 10 進。 - URL エンコード / エンコード / デバッグ
URL エンコードが壊れるのはなぜ？ パーセントエンコードと + vs %20
記事を読むcaféを URL に入れるとcaféで出てくる。空白はある場所では+、別の場所では%20。値の中の&がクエリを真っ二つに割り、後半が消える。何かが二度エンコードされて%2520を眺めている。どれも別々のバグに見えて、実は一つの考えに二つのひねりだ——パーセントエンコードは URL がそのまま書けないバイトを逃がし、規則は部位で変わり、空白には合法な書き方が二つある。 - Base64 / エンコード / デバッグ
Base64 とは何か、そしてなぜデコードできないのか？
Base64 文字列をデコーダーに貼ると「Invalid character」——あるいはもっと悪いことに、デコードは「成功」して、画面いっぱいの文字化けが返ってくる。たいてい壊れてなどいない。Base64 が何なのかを取り違えているだけだ。暗号でも圧縮でもなく、バイトを可逆に詰め直してテキスト専用の経路を通すもの——そう見えれば、どのデコード失敗も、名前を付けられる短いリストの一項目になる。
記事を読む - タイムスタンプ / ISO 8601 / データベース / 日付と時刻
日時はタイムスタンプで保存すべき？それとも ISO 文字列？
コードレビューが一つの列で止まる。片方は Unix タイムスタンプの整数で保存し、もう片方は ISO 文字列、外部 API は Z で終わるテキストを返してくる。どれが「正しい」のか？議論はほぼいつも整数か文字列かで詰まる——だがそれは、いちばん重要でない、最後に問うべき問いだ。勝敗を決めるのは、その前にあるものだ。
記事を読む - タイムゾーン / 日付と時刻 / 夏時間 / デバッグ
日付が一日ずれるのはなぜ？タイムゾーンとカレンダー日付
誕生日を 5 月 1 日で保存したのに、4 月 30 日と表示される。イベントを 7 月 15 日に入れたのに、カレンダーは 14 日を映す。日次レポートが、真夜中の直前の行を誤った日に数える。原因はほぼ同じだ——カレンダー日付は時間の一点ではなく、バグは「ゾーンのない日付」が「ゾーンのある瞬間」と出会う境界で起きる。
記事を読む - タイムゾーン / UTC / ISO 8601 / 日付と時刻
UTC、GMT、ISO 8601、Unix タイムスタンプの違いは？
UTC、GMT、末尾の Z、+08:00、十桁の数字——まるで同じものかのように使われ、それらを取り違えるところから時間のバグが忍び込みます。これらは「時刻」の変種ではなく、四つの別々の層にあります。基準となる尺度、タイムゾーン、オフセット、そして一つの瞬間を書き留める二つの記法を、それぞれの場所に戻します。
記事を読む - タイムスタンプ / タイムゾーン / JavaScript / デバッグ
Unix タイムスタンプがずれるのはなぜ？秒・ミリ秒・タイムゾーン
時刻がずれて表示されるタイムスタンプは、ほとんどの場合、数値が壊れているのではなく、カテゴリの取り違えです。Unix タイムスタンプは日付ではなく、タイムゾーンも持ちません。ある固定した瞬間から数えた、ただ一つの秒数です。「瞬間」と「その描画のされ方」を切り分ければ、「数十年ずれる」「三時間ずれる」「一日ずれる」はそれぞれ、具体的で突き止められる一つの原因に収束します。
記事を読む - JWT / 認証 / セキュリティ / セッション
短命な token、refresh のローテーション、そして JWT の取り消し方
JWT のよくある使われ方——状態を一切参照せずサーバーがローカルに検証する、自己完結した access token として——こそが、それを簡単には取り消せない理由だ。期限が切れるまで有効で、サーバー側で何をしても変わらない。本稿はそれをどう管理するかを扱う。短い access token の寿命、再利用検知つきの refresh token とローテーション、そして自己完結型トークンを取り消す現実的な選択肢——どれも、あなたが JWT に求めた無状態性との間でのトレードオフを伴う。
記事を読む - JWT / セキュリティ / フロントエンド / 認証
JWT はブラウザのどこに保存すべき？localStorage、cookie、そして XSS/CSRF のトレードオフ
JWT をブラウザのどこに置くかは、しばしば「どれが安全か」という順位づけのように問われるが、順位の問題ではない。localStorage、cookie、メモリは、二つの問い——JavaScript がトークンを読めるか、ブラウザが自動で付けるか——に別々の答えを返し、それがそのまま XSS と CSRF に対応する。本稿は各方式、業界が落ち着いた形、そしてどの保存先を選ぶかより XSS を止めることのほうが重要な理由をたどる。
記事を読む - JWT / セキュリティ / 認証 / デバッグ
私の JWT は安全か？トークン検証はどう回避されるのか
JWT の多くの安全事故は暗号そのものの破綻ではなく、検証器の設定や実装の誤りです。攻撃者が書いたトークンを受け入れる、または検証自体をしないことが原因になります。未検証のトークンに検証方法を左右させないための主な攻撃経路と防御を解説します。
記事を読む - JWT / 認証 / デバッグ / セキュリティ
JWT が無効になるのはなぜ？JSON Web Token のデコードとデバッグ
「invalid token」という 401 は、トークンが壊れていることをほとんど意味しません。あなたとサーバーの間にある、どれか一つの検証が通らなかったのです。デコードの小技を集めるより、JWT とは何かを理解しましょう——署名された平文であり、いつでも読めるが、検証してはじめて信用してよいもの。そう捉えれば、あらゆる失敗が短く順序だったチェックリストに変わります。
記事を読む - 正規表現 / 先読み / JavaScript
消費せずにマッチさせるには？正規表現の先読みと後読み
マッチはしたのに match[0] から欲しかった部分が抜けている——あるいはパスワードチェックで三つの条件を一度にかけたい。どちらも行き着く先は一つの考えです。先読みと後読みは、テキストを検査するけれど消費しない。ゼロ幅アサーションが実際にどう働くか、そしてそれが簡単にしてくれるいくつかの仕事を解説します。
記事を読む - 正規表現 / ReDoS / パフォーマンス / セキュリティ
正規表現がなぜこんなに遅い？破滅的バックトラッキングと ReDoS
短い入力なら快調なのに、少し長い入力でページが固まる正規表現——それはたいてい「遅い」のではなく指数的です。破滅的バックトラッキングを形から見抜き、背後にある ReDoS 攻撃を理解し、パターンを安全に書き換える方法を解説します。
記事を読む - 正規表現 / デバッグ / JavaScript
正規表現がマッチしないのはなぜ？まずエンジンの動きを理解する
「マッチしない」正規表現は、たいてい実はマッチしています——ただ、あなたが思った範囲ではないだけです。小技を暗記するより、エンジンが文字列をどう走査してバックトラックするかを理解しましょう。貪欲・遅延・アンカー・先読み・破滅的バックトラッキングは、すべて同じ仕組みの別の側面です。
記事を読む - JSON / デバッグ / 整形
パースできない JSON を直す方法（残った混乱も片付ける）
パースエラーは、そもそも入力が厳密な JSON ではなかったという合図です。エラーの読み方、壊す 5 つの原因、そして読める形に整えるまでを解説します。
記事を読む - JSON / 差分 / 開発ワークフロー
2 つの JSON ファイルを比較して、本当に変わった部分だけを見る方法
JSON を行単位で比較すると、整形やキー順の違いが本当の変更を隠します。ターミナル、エディター、コード、ブラウザーでの比較方法を整理します。
記事を読む