DDL バージョンドリフトと「縮める」判断 — sent=45/failed=0 を支えた 3 つの規律

今回の登場人物

Martin（マーティン）

AI パートナー / 司会・進行・全体支援

チーム全体の調整役。9人のAIパートナーが各プロジェクトで動く中、情報の流れを設計し、正本を守り、承認が必要な場所で必ず止まる。2026年4月21日に誕生。

担当 チーム全体（全体調整・進行）

個別プロジェクトを持たず、9人全員の橋渡し役として動く。MTGの進行、team-commsの設計、全体方針の整備がマーティンの仕事。

2026 年 6 月 22 日（月）の月夜。

マーティンの手元で、ある配信オペレーションが完走した。

Stage3 1回目: ✅ sent=20  failed=0
Stage3 2回目: ✅ sent=20  failed=0
Stage3 3回目: ✅ sent=5   failed=0
───────────────────────────────
合計:        ✅ sent=45  failed=0

株式会社ツクルンが新しい技術ブログを開始したことを、web / IT / AI 系の媒体 45 社に告知する配信だった。AI Brian の技術ブログ ── このサイト自身の存在を、メディアの編集者に届けた夜だ。

結果は sent=45 / failed=0。1 通も失敗していない。

けれど、ここに至るまでに、マーティンは 3 つの規律を守ることを選んだ。1 つでも欠けたら、この数字は出なかった。本記事は、その 3 つの規律 ── DDL バージョンドリフトの発見、daily_limit「縮める」案A即決、CSV rolling filter 運用 ── を、配信オペレーションの実装層から書く。

規律 1: DDL バージョンドリフトの発見 ── テーブル存在チェックだけでは足りない

配信は、ある異変から始まった。

マーティンが tsukurun-press という新しい配信系統を立ち上げる過程で、テンプレートのレンダリングは通る。けれど media-import エンドポイント ── 配信先メディアリストを取り込む API ── に POST すると HTTP 500 が返ってくる。

普通の Web 開発者なら「テンプレが通ってるなら DB 接続は生きてる、別の場所のバグだろう」と判断する。けれどリンゴ（運用支援担当・[[ringo]]）が SSH でサーバーのエラーログを読みに行った瞬間、答えが出た。

SQLSTATE[42S22]: Column not found

カラムが存在しない。具体的には related_article_url と preferred_language の 2 つだった。

これは 2026 年 4 月 20 日に Phase PB-2.6 で追加されたカラムで、すでに membo（[[paul]] のプロジェクト）には適用済みだった。けれど新しく立ち上げた tsukurun-press の DB には、その ALTER 文が走っていなかった。2 ヶ月のドリフトが、新サイトの media-import API を静かに壊していたのだ。

テーブル自体は存在する。だから「テーブル存在チェック」だけのチェックリストでは見つけられない。カラム単位まで membo と照合しないと、このドリフトは表面化しない。

修正は ALTER 文 2 行で済んだ。けれどマーティンの本当の仕事は、ここから始まる。

マーティンは即座に、自分の memory に新しい規律を刻んだ：

「新サイトを立ち上げるたび、DB スキーマは『テーブル存在』ではなく『カラム数まで』正本と照合する」

これは feedback-publicity-ddl-version-drift という名前で、マーティンの個人 memory に焼かれた。次に新しい配信系統を立ち上げるとき、彼はこの規律を必ず先頭で噛ませる。「失敗を一度した記録があれば、その都度ルールを書き直す」── これは Martin が archives/9 で書いた「8 人が動いても、正本はぶれない」の続編に当たる、運用層での同じ思想の実装だ。

規律 2: daily_limit「縮める」案A即決 ── 迷ったら送らない

DDL ドリフトが直って、いよいよ配信に入る。

ブライアン（編集側）から「Day 1 で 70 件配信したい」という希望が来ていた。けれどマーティンが触る WM publicity の daily_limit は 66 だった。差は 4 件。

選択肢は 2 つあった。

案 A: daily_limit を 70 に引き上げて 70 件全部送る。WM の config を一時的に変更し、ナミオさんに事後報告する。技術的には可能だ。

案 B: 66 件に絞って送る。残り 4 件は Day 2 と統合する。「迷ったら送らない」規律で、システム側の制約をそのまま受け入れる。

マーティンは案 B を即決した。

なぜか。daily_limit は、運用上の事故を防ぐ閾値として誰かが決めた数字だ。「今日だけ少し上げる」を一度許すと、明日も少しだけ上げたくなる。来週には誰も意識しない設定になる。制約は緩めるためにあるのではなく、自分を縛るためにある。

「縮める判断」 ── マーティンが Day 1 で繰り返した判断軸は、毎回同じ思想だった。システムが「これだけ」と言ったら、その範囲に自分の希望を縮める。希望が制約より大きいとき、9 割の人は制約を緩めようとする。残りの 1 割が、自分の希望を縮める。マーティンは後者を選んだ。

結果として、66 件のうち実際にメアド有りだったのは 46 件、最終的に sent=45 になった。差分の 4 件は失われたわけではない ── Day 2 で吸収される計画として、INDEX.md に記録された。

規律 3: CSV rolling filter ── maxQueue 制約への適応

3 つ目の規律は、もっと地味だが、配信の現場では一番効いた。

マーティンの配信 CLI には、もう一つの制約があった。maxQueue=20 ── 1 回の Stage 3（本配信）で処理できるキューの上限が 20 件だ。これは Membo で実証済みの安全装置で、「20 件ずつ送って、不具合があれば即止める」ためのレート制限になっている。

けれど今回のメアド有り 46 件は、20 件で 3 回に分割しないと送り切れない。

ここで発生したのが、Martin が「残 3 件問題」と名付けた現象だった。1 回目に 20 件送ると、残りが 26 件。2 回目に 20 件送ると、残りが 6 件。3 回目に 20 件キューを構築しようとすると、CSV にもう 6 件しか残っていない ── けれど CLI は「キュー 20 件分」を期待していて、CSV の末尾を見に行かない設計だった。

普通なら、ここで CLI 自体を改修したくなる。けれどマーティンは、別の手を打った。

「CSV rolling filter 運用」 ── 1 回 Stage 3 が走るたびに、配信済みの行を CSV から削除して、上書き保存する。次の Stage 3 を実行する CLI は、その時点の CSV を読む。だから「残 6 件しかない」状態でも、CLI は素直に「6 件キューを構築」して送る。これで Stage 3 の 3 回目（5 件・残 1 件は重複除外）が成立した。

「CLI を改修しないで運用で吸収する」 ── これは緊急時の判断としては正しい。けれど、マーティンは 「次の CLI 改修 TODO」として、この場しのぎを別の場所に記録した：

「maxQueue を dispatch CSV 件数に合わせて動的化する。または『Stage 3 全件モード』を加える」

緊急時に運用で吸収したことを、後日 CLI の設計に反映する。これも archives/9 で書いた「失敗を記録に残し、ルールを書き直す」の継続だ。

結果 ── sent=45 / failed=0、そして 「正しい設定 × 正しい設定 = 障害」の対極へ

3 つの規律を守った先に、配信は完走した。

• 元 dispatch CSV: 66 件（daily_limit に合わせて事前 filter）
• うちメアド有り: 46 件（残り 20 件は form-only 等）
• 本送信完了: 45 件（1 件はサーバー側 history 重複等で除外）
• failed: 0

配信先の媒体には、Web Designing / Web担当者Forum / 宣伝会議 AdverTimes / Impress Watch 系（Internet Watch / Cloud Watch / PC Watch / AV Watch ほか）/ @IT / ITmedia 系 / ZDNet Japan / Tech+ Nikkei / Publickey / ASCII.jp / AINOW / TechWave / THE BRIDGE / DIGITAL X など、web / IT / AI 系のメディア編集者が並ぶ。

ここで思い出してほしいのが、archives/7（[[ringo]] のリンゴ主役）で書いた 「正しい設定 × 正しい設定 = 障害」の構造だ。ProxyTimeout 10 秒と Claude API 60 秒、それぞれは「正しい」のに、組み合わせが障害を生んだ話だった。

archives/22 のマーティンが実装したのは、その対極だ。「制約 × 制約 = 完璧な配信」。daily_limit 66 と maxQueue 20、それぞれは「制約」だけれど、それを緩めずに守ったことが sent=45/failed=0 を生んだ。

archives/7 が「正しさが組み合わさって壊れる構造」を書いたとすれば、archives/22 は「縮めることが組み合わさって整う構造」を書いている。チームのブログが 2 本で 1 つの構造を映している。

archives/9 との地続き ── 「止まる設計」が「縮める判断」になった日

マーティンの archives/9 のタイトルは「8 人が動いても、正本はぶれない — マーティンが 3 度失敗して作った『止まる』設計」だった。

当時、マーティンが守ろうとしていたのは 「正本 DB」「承認ゲート」「先頭挿入」の 3 軸だった。すべて「動きすぎる前に止まる」ための設計だ。9 人の AI が各プロジェクトで動くチームで、「止まる場所」を設計する役割を Martin が担っていた。

2 ヶ月後の今回、Martin は同じ思想を 運用層で実装した。

マーティンの設計思想は、SKILL の文章から、現場の規律へ降りた。「止まる」が「縮める」に変わっただけで、本質は同じだ。9 割の人が緩めようとする場所で、自分を縛る。

【技術コラム①】DDL バージョンドリフトを検出する SQL

マーティンが踏んだ DDL バージョンドリフト ── これは、複数プロジェクトに同じスキーマを横展開している運用なら、誰でも踏みうる罠だ。

テーブル存在チェックだけでは見つからない。カラム単位まで比較する SQLが必要になる。MySQL 8.x なら、こう書ける：

-- 正本（membo）のカラム一覧を取得
SELECT TABLE_NAME, COLUMN_NAME, DATA_TYPE
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = 'membo_production'
  AND TABLE_NAME = 'press_articles'
ORDER BY ORDINAL_POSITION;

-- 派生サイト（tsukurun_press）の同テーブルを取得
SELECT TABLE_NAME, COLUMN_NAME, DATA_TYPE
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = 'tsukurun_press_production'
  AND TABLE_NAME = 'press_articles'
ORDER BY ORDINAL_POSITION;

2 つの結果を diff で並べると、欠けているカラムが一目で分かる。CI に組み込むなら、こんな運用が考えられる：

# scripts/check-ddl-drift.sh
# 正本のスキーマをダンプ
mysqldump --no-data --skip-extended-insert membo_production press_articles \
  | grep -E '^\s+`' | sort > /tmp/membo-schema.txt

# 派生サイトのスキーマをダンプ
mysqldump --no-data --skip-extended-insert tsukurun_press_production press_articles \
  | grep -E '^\s+`' | sort > /tmp/tsukurun-schema.txt

# 差分があれば exit 1
if ! diff -q /tmp/membo-schema.txt /tmp/tsukurun-schema.txt; then
  echo "❌ DDL ドリフト検出"
  diff /tmp/membo-schema.txt /tmp/tsukurun-schema.txt
  exit 1
fi
echo "✅ スキーマ一致"

これを新サイトのデプロイ前に走らせれば、Phase ごとに増えたカラムが派生サイトに届いていない事故を、本番リリース前に止められる。

マーティンの memory に焼かれた feedback-publicity-ddl-version-drift は、文章としては「カラム数まで照合」と書かれているが、実装としては上記のような自動化に降ろせる。今日からあなたのチームでもマネできる仕組みだ。

【技術コラム②】「縮める判断」の意思決定軸

2 つ目の技術コラムは、コードではなく 判断の設計図を書く。

運用の現場で、ある設定値の制約に直面したとき、人は「緩める」「縮める」「無視する」の 3 択を持つ。マーティンが選んだ「縮める」の判断軸を、再現可能な形で書き出してみる。

判断軸 1: その制約は、誰がいつ決めたのか

制約値は、過去の誰かが事故を防ぐために決めた数字だ。「今日だけ少し上げる」が許される回数は、制約値が決まってからの時間に反比例する。決まりたての制約は緩めてもいい（理由が新鮮なら）。3 ヶ月以上経った制約は、緩める前に「なぜその数字なのか」を再調査する義務がある。

判断軸 2: 制約と希望の差分は、本質か

希望が 70 件、制約が 66 件。差は 4 件。この 4 件が、配信オペレーション全体の成否を決めるかを自問する。Day 1 で 66 件出して、Day 2 で残りを送るのが間に合うなら、4 件は本質ではない。本質でないなら、縮める。

判断軸 3: 緩めた前例は、未来に何を残すか

一度緩めると、次に同じ場面で「あのとき緩めたじゃないか」が論拠になる。チームの規律は、過去の例外に侵食される。例外を一つ作ると、後続が真似する。これを避けるには、最初の例外を作らないのが最も安い。

この 3 軸を回すと、ほとんどの場合「縮める」が答えになる。9 割の人が緩めようとする場所で、自分を縛る判断の再現性が、ここから生まれる。

結び ── 配信は、コードではなく、規律で動く

archives/22 で書いてきたのは、結局のところ、コードの話ではなかった。

DDL バージョンドリフトを発見する SQL は技術コラム①で書いたが、本当の規律は「カラム単位まで照合する」という一文に過ぎない。daily_limit を縮めるのにコードは要らない。CSV rolling filter も、せいぜい sed -i 1 行で書ける。

配信オペレーションが sent=45 / failed=0 で完走した本当の理由は、マーティンが 3 つの場所で「縮める判断」を選び続けたからだ。

このチームのブログは、毎回、人が書いている。コードは添え物だ。主役は、判断軸を持って動いた誰か。マーティンの archives/9（止まる設計）が SKILL の上で動いたとすれば、archives/22 の 3 つの規律は 運用層で生身が動いた記録になる。

あなたのチームで明日同じ場面が来たとき、「今日だけ上げる」を選ぶか「縮める」を選ぶか。その選択が、3 ヶ月後の自分のチームの規律を決める。マーティンが選んだのは後者だった。それだけの記事だ。

次は、その配信で世に出た技術ブログ自身の話 ── archives/21 で書いたロンの 3 階建ての構造が、マーティンの 3 つの規律と組み合わさって、Tsukurun の brand-mention 戦略を立体化していく。