カテゴリー: 未分類 Page 1 of 18

デッキてこ入れ案(2026/07/18 統率者メモ)

動きに惹かれて購入したこの

デッキ。当初は「これは脱法ブラケット2」と自信を持っていましたが「FF統率者やニンジャタートルズの構築済みの統率者デッキにも負けてしまう」

と言うほかありません。

課題

  • 1ターン中のビッグアクションがない。
    • 20/20のマリットレイジはインパクトがあるものの、追放除去や無力化オーラが荒れる環境です。
  • ザーレルの微妙な殴りづらさ
    • これが結構大きいです。世界のるつぼを内蔵しているとはいえ、2/5飛行のスタッツは戦線向けではありません。何より能力の+1/+1カウンターの置き先が自分だったら相当無双にできるのでしょうが……

そして、何よりも、

こちらのデッキとほぼやりたいことが重なってしまったというのが難点。

統率者の変更

Hearthhull, the Worldseed / 世界播種、ハースハル (1)(黒)(赤)(緑)
伝説のアーティファクト — 宇宙船(Spacecraft)

配備(あなたがコントロールしていてこれでないクリーチャー1体をタップする:それのパワーに等しい個数の蓄積(charge)カウンターをこの宇宙船(Spacecraft)の上に置く。配備はソーサリーとしてのみ行う。8個以上なら、これはアーティファクト・クリーチャーである。)
2+|(1),(T),土地1つを生け贄に捧げる:カード2枚を引く。このターン、追加の土地1つをプレイしてもよい。
8+|飛行、警戒、速攻
あなたが土地1つを生け贄に捧げるたび、各対戦相手はそれぞれ2点のライフを失う。6/7

これにしようとした理由は

  • 土地の一気なサクリファイスで全員のリーサルが狙える。
  • 見事な再生、事件現場の分析者、召喚:タイタンなどでのリカバリー手段を組み込める
  • サワギバデッキでやっているアリストクラッツの土地版ができる

などの複数の理由。まずは、カードの調査から始めます。

準備とブラケット。(統率者メモ 2026/07/10)

ブルーム張ろう統率者デッキ『リスの悪ふざけ』から、ほとんどのパーツを取り去り、「無限ルートが幾重にも存在する」レベルになった筆者の統率者デッキの中で頭一つ抜けて「殺意マシマシ」のデッキ。

以下、デッキリスト。太字はデッキに残っていたもの。見て分かるように、土地とコンボになるもの以外は差し替えています。

🌟 統率者

  • 《リスの将軍、サワギバ/Chatterfang, Squirrel General(BLC)》

🌲 クリーチャー

  • 《大釜の使い魔/Cauldron Familiar(ELD)》
  • 《ズーラポートの殺し屋/Zulaport Cutthroat(BLC)》
  • 《威名のソルジャー、セフィロス/Sephiroth, Fabled SOLDIER(FIN)》
  • 《無情な無頼漢/Ruthless Knave(XLN)》
  • 《実験的な菓子職人/Experimental Confectioner(WOE)》
  • 《悲哀の徘徊者/Woe Strider(BLC)》
  • 《巣穴の魂商人/Warren Soultrader(MH3)》
  • 《無慈悲な略奪者/Pitiless Plunderer(RIX)》
  • 《無情な屍技術師/Ruthless Technomancer(NEC)》
  • 《ヘイゼルの醸造主/Hazel's Brewmaster(BLC)》
  • 《溜め込む親玉/Hoarding Broodlord(MOM)》
  • 《エルフの神秘家/Elvish Mystic(TSR)》
  • 《金のガチョウ/Gilded Goose(BLC)》
  • 《ラノワールのエルフ/Llanowar Elves(_BR)》
  • 《極楽鳥/Birds of Paradise(RVR)》
  • 《森を護る者/Sylvan Safekeeper(MH3)》
  • 《茨越えの餌あさり/Thornvault Forager(BLB)》
  • 《献身のドルイド/Devoted Druid(SHA)》
  • 《裕福な亭主/Prosperous Innkeeper(BLC)》
  • 《小走り樫/Scurry Oak(MH2)》
  • 《不屈の補給兵/Tireless Provisioner(BLC)》
  • 《リスの小走り/Scurry of Squirrels(BLC)》
  • 《ペレグリン・トゥック/Peregrin Took(LTR)》
  • 《秘密を知るもの、トスキ/Toski, Bearer of Secrets(BLC)》
  • 《終わりなき巣網のアラスタ/Arasta of the Endless Web(BLC)》
  • 《永久の証人/Timeless Witness(MH2)》
  • 《深き森の隠遁者/Deep Forest Hermit(BLC)》
  • 《根花のヘイゼル/Hazel of the Rootbloom(BLC)》
  • 《歩行バリスタ/Walking Ballista(AER)》
  • 《アカデミーの整備士/Academy Manufactor(BLC)》
  • 《カルドーサの鍛冶場主/Kuldotha Forgemaster(SOM)》
  • 《マイアの戦闘球/Myr Battlesphere(TDC)》
  • 《悲哀の名誉教授 / Emeritus of Woe》 ★IN!
  • 《墓場の研究者 / Grave Researcher》 ★IN!

⚡ インスタント

  • 《命取りの論争/Deadly Dispute(BLC)》
  • 《切断マジック/Saw in Half(BLC)》
  • 《新緑の命令/Verdant Command(MH2)》
  • 《蓄え放題/Cache Grab(BLB)》
  • 《召喚の調べ/Chord of Calling(M15)》
  • 《暗殺者の戦利品/Assassin's Trophy(ACR)》
  • 《ウィンドグレイスの裁き/Windgrace's Judgment(BLC)》

📜 ソーサリー

  • 《群がり庭の虐殺/Swarmyard Massacre(BLC)》
  • 《根鋳造の弟子入り/Rootcast Apprenticeship(BLC)》
  • 《大渦の脈動/Maelstrom Pulse(BLC)》
  • 《Too Evil to Stay Dead / 死なせておくには邪悪が過ぎる》 ★IN!

🍇 エンチャント

  • 《清掃人の才能/Scavenger's Talent(BLB)》
  • 《アクロゾズの約定/Promise of Aclazotz(LCC)》
  • 《想起の拠点/Bastion of Remembrance(BLC)》
  • 《美食家の才能/Gourmand's Talent(BLC)》
  • 《パンくずの道標/Trail of Crumbs(ELD)》
  • 《殺しのサービス/Killer Service(NCC)》
  • 《イトリモクの成長儀式/Growing Rites of Itlimoc(XLN)》
  • 《似通った生命/Parallel Lives(WOT)》
  • 《陰湿な根/Insidious Roots(MKM)》

⚙️ アーティファクト

  • 《太陽の指輪/Sol Ring(BLC)》
  • 《恐竜の遺伝子/Dino DNA(REX)》
  • 《魔女のかまど/Witch's Oven(ELD)》
  • 《頭蓋骨絞め/Skullclamp(BLC)》
  • 《アシュノッドの供犠台/Ashnod's Altar(4ED)》
  • 《ヌカコーラ自動販売機/Nuka-Cola Vending Machine(PIP)》
  • 《前兆の時計/Clock of Omens(5DN)》
  • 《旗印/Coat of Arms(EXO)》
  • 《囀り吐き/Chitterspitter(BLC)》

🗺️ プレインズウォーカー / バトル

  • 《飢餓の潮流、グリスト/Grist, the Hunger Tide(MH2)》
  • 《イコリアへの侵攻/Invasion of Ikoria(MOM)》

⛰️ 土地

  • 《沼/Swamp》 ×7
  • 《森/Forest》 ×8
  • 《見捨てられたぬかるみ、竹沼/Takenuma, Abandoned Mire(NEO)》
  • 《ゴルガリの腐敗農場/Golgari Rot Farm(RAV)》
  • 《疾病の神殿/Temple of Malady(BLC)》
  • 《森林の墓地/Woodland Cemetery(BLC)》
  • 《黄昏のぬかるみ/Twilight Mire(BLC)》
  • 《ラノワールの荒原/Llanowar Wastes(BLC)》
  • 《緑ばんだ沼/Viridescent Bog(BLC)》
  • 《汚れた森/Tainted Wood(BLC)》
  • 《草むした墓/Overgrown Tomb(RAV)》
  • 《屍花の交錯/Necroblossom Snarl(BLC)》
  • 《風切る泥沼/Hissing Quagmire(OGW)》
  • 《眠らずの小屋/Restless Cottage(WOE)》
  • **《不気味な辺境林/Grim Backwoods(BLC)
  • 《群がりの庭/Swarmyard(BLC)》
  • **《風変わりな果樹園/Exotic Orchard(BLC)
  • 《祖先の道/Path of Ancestry(BLC)》
  • 《統率の塔/Command Tower(BLC)》
  • 《新緑の地下墓地/Verdant Catacombs(ZEN)》
  • 《成長の揺り篭、ヤヴィマヤ/Yavimaya, Cradle of Growth(MH2)》

OUT

  • 骨術師の達人
  • 悪魔の職工 (割と高い金で買いましたが……!)
        - 2つともタイムラグが発生するから
  • 発掘
        - コスト3までしか拾えないため。もっといいカードを見つけた。

IN

悲哀の名誉教授 / Emeritus of Woe (3)(黒)

クリーチャー ─ 吸血鬼(Vampire) 邪術師(Warlock)
このクリーチャーは準備済状態で戦場に出る。(準備済状態である間、あなたはこれの呪文のコピーを唱えてもよい。そうしたら、これを未準備状態にする。)
あなたの終了ステップの開始時に、そのターンに2体以上のクリーチャーが死亡していた場合、このクリーチャーは準備済状態になる。
//準備//
悪魔の教示者 / Demonic Tutor
(1)(黒)
ソーサリー
あなたのライブラリーからカード1枚を探し、そのカードをあなたの手札に加える。その後、ライブラリーを切り直す。
5/4

なんと「悪魔の教示者」内蔵。しかも、2体以上死ぬというのは「毎ターン使えるも同義」です。

墓場の研究者 / Grave Researcher (2)(黒)

クリーチャー ─ トロール(Troll) 邪術師(Warlock)
あなたのアップキープの開始時に、諜報1を行う。その後、あなたの墓地に3枚以上のクリーチャー・カードがあるなら、このクリーチャーは準備済状態になる。(準備済状態である場合、あなたはこれの呪文のコピーを唱えてもよい。そうしたら、これを未準備状態にする。)
//準備//
再活性 / Reanimate
(黒)
ソーサリー
墓地にあるクリーチャー・カード1枚を対象とする。それをあなたのコントロール下で戦場に出す。そのカードのマナ総量に等しい点数のライフを失う。
3/3

同じく「再活性」内蔵。これも「毎ターン使える」としか書かれていません。サワギバで除去したクリーチャーをこちらのものに引き込めます。

Too Evil to Stay Dead / 死なせておくには邪悪が過ぎる (2)(黒)

ソーサリー
チームワーク4(この呪文を唱えるための追加コストとして、あなたがコントロールしている望む数のクリーチャーを、パワーの合計が4以上になるように選んでタップしてもよい。)
あなたの墓地にありマナ総量が4以下であるクリーチャー・カード1枚を対象とする。この呪文がチームワークを用いて唱えられたなら、代わりに、あなたの墓地にあるクリーチャー・カード1枚を対象とする。それを戦場に戻す。

マーベル・スーパーヒーローズからの出演。発掘で手が届かなかった「4」に触ることができ、更にチームワークによって除去された(或いは文字通り真っ二つにした溜め込む親玉を拾えます)

自己申告

そもそもこれは手札の巡りで3キルが発生します。サーチも多め。今回の調整により「ほぼ毎ターン使える悪魔の教示者と再活性」が手に入ったので、ゲームチェンジャーカードを入れなくとも3の上位や4には入れるレベルだと思っています。

調理実験:野菜の水分について

無水カレーなど、野菜の水分を使った料理。これは本当に可能なのだろうかと言うことで疑問が湧きました。

「野菜から出る水分だけで、換装春雨を戻すことは可能か」

そこで実際に試してみます。

用意したもの

  • トマト
  • ズッキーニ
  • キュウリ
  • 乾燥春雨。

そして味付けとして今回は保険を打ちました。「失敗しても誤魔化せるもの」です。

  • カレー粉
  • 鰹節
  • ツナ缶

これであれば失敗しても「やっちまったカレー炒め」にすることが可能。

検証開始

  1. トマトとキュウリをざく切り。水分を出すのが目的なので塩もみはしません。
  2. ズッキーニをくし切りにして別の皿に空ける

そして、小鍋にツナ缶を油ごと入れて、トマトとキュウリを入れて炒めていきます。理論上、これであればしっかりと水分は出てくるはず。

そして10分ほど中火で炒めていた結果

予想以上でした。と言うか予想を超えていました。ズッキーニに春雨を入れてもまだ水分を受け止めています。

そこで予定変更。冷凍庫にあった肉団子を放り込みます。

味付けはカレー粉と他諸々。アドリブでしたが、カレー粉があるのでなんとかなります。

最後に「正気か?」レベルの鰹節をドサッと入れて冷蔵庫で一晩寝かせます。

食べた後のデブリーフィング

食べ終わった後のデブリーフィングです。

  • 味付けはうまくいきました。特に「正気か?」レベルのひとつかみの鰹節が全てをまとめました。
  • 炒められたキュウリの食感も好みです。

良かった点はこの通り。弱点は見た目。カレー粉を入れすぎてしまった。なので、このポテンシャルを活かして別の調味料にしても良かったでしょう。

  • ナンプラー
  • ポン酢
  • 白出汁

など、バリエーションは豊かです。そして、別に何が合うのかを逡巡した結果、いいものがありました。

ニンニク背脂系ラーメン。

相対的に鮮度を上げればいいということでラーメンの具として。

加熱されて出汁をまとったキュウリがニンニク背脂系ラーメンのガツンとした風味を受け止めつつ箸休めになりました。

今回の学び

  • 野菜の水分はこれからも武器になる。
  • これに合う出汁やブイヨンをしばらく試していきたい。
  • 何よりも、この実験によって脳内キッチンのシミュレーション精度が高まった

のはいい点です。

カレーの戦略。

美味しいお店のメニューの狙いを見るのが好きです。

ある日にいただいたカレーの戦略性をこっちで勝手に推理してみます。

見た目は本当に日本の家のカレー。

  • ジャガイモ
  • にんじん
  • タマネギ

違いがあるとすれば福神漬けの代わりに細切り唐辛子。まずは食べてみます。

「肉」

でした。それも普通にお目にかかれないような圧倒的な牛肉の旨味と歯ごたえ、筋の柔らかさがこれでもかと出てきます。

そして飛び込んでくるほくほくのジャガイモとにんじん、ジャガイモの甘みがご飯と一体化。

そして、やや辛のスパイスが刺激し、全てを平らげてくれます。

この店の狙い、推測

ここで、一つ謎が出てきました。なぜこの店は、この牛肉で勝負ができるカレーを

  • おしゃれなカレーポットに入れず
  • 奇をてらわない平皿盛りで
  • 日本のカレーの見た目にしたのか

です。それは、この「圧倒的な牛肉」を強烈に意識させるためではないかという仮説。

どうしたって人はバイアスに捕らわれます。そこで高級店のカレーのスタイルで出てくれば「さすがは高級店」と、比較対象が別のものになります。

しかし、店のカレーが、こちらのように家庭的な見た目ならば、どうしたって「家のカレーとどう違うのか」の確固たる評価軸が出てきます。

その上で「肉が違う。この肉の出し方は自分には難しい」と思わせる戦略。

正直、普段の手作りカレーが一歩下がるような感覚でした。つまりこれは、味の美味しさで勝負するのはもちろん

「あなたの普段食べているカレーとは素材が違います」

をすり込むための擬態、とも取れそうです。実際問題、もう一度このカレーを食べたいという気持ちにあふれていますので。

『メリー・ポピンズ リターンズ』

Cover is not the book / 心が目に見えないように本も
So open it up and take a look / 表紙の美しさに騙されちゃダメ
'Cause under the covers one discovers / 中身読んだらやさしい王様
That the king may be a crook / 詐欺師だとわかるかも

を地で行くカレーでした。

食事と海鮮。

素晴らしい食事を戴きました。

お作り

季節の盛り合わせ。特にしめさばに感動。

豚の角煮

クリアなあく取りと、しっかりと染みこんだ豚肉、とろけるような脂身。

鮎の塩焼き

この焼き色はもちろん、頭も骨もしっかり食べられて詰まらない絶技です。

厚揚げ

一番感動したのは実はこちら。「その場で揚げた」真に出来たての厚揚げ。なので、普通に口にした瞬間に熱々の豆腐が飛び出てきて火傷寸前でした。

なので、その香ばしさが更に薬味とひき立て合います。

ジャガイモの素揚げ

好物だからと挙げてくれました。バターと塩のみという潔さがジャガイモのほくほく感を引き立てます。

稲庭うどんと野菜点

食事の締め。正義の取り合わせという感じ。

手まり寿司

感動したというしめさばのフィードバックをそのまま手まりにするという技術と心配り。

と、実に素晴らしい食事をいただけました。

『IDEA SPHERE』3つのバイアス

『黄色い顔(シャーロック・ホームズの思い出)』の象徴的な言葉。

「ワトソン」ホームズは言った。「もし僕がちょっと自分の能力に自信過剰になっていると気付いたり、事件に対して必要なだけの努力をしていないようだったら、僕の耳元で『ノーベリ』とささやいてもらえないだろうか。そうすれば僕は大いに君に感謝するだろう」

これ、

  • 探偵とは言え失敗する
  • キャラクター造形の中でのウィークポイントを晒すことで更なる魅力を生む(ギャップ萌え)

だと思っていましたが:まさに、これと同じような状況が起きたので自戒3割、言い訳7割でこのテキストを残します。

起きたこと

私が過去に初期設定を案内してアカウントまで譲渡したWordpressサイトに話は遡ります。

そのサイトの持ち主から「急にWebサイトに繋がらなくなった」というヘルプ要請。「アプリには入れるが更新はできない」ということ。

取り急ぎ「情報を集めるだけ集めて伺う」と返して状況確認です。

初動

  • Webブラウザでの挙動

そのサイトのURLを入力。403エラーが出ます。

  • curlでの挙動
curl -I https://hoge.example.com
HTTP/2 403 
server: nginx 
date: Fri, 19 Jun 2026 05:28:52 GMT

間違いなく403エラーです。

更に

  • index.php
  • /wp-login.php
  • /wp-admin

も同様に403エラーになりました。

考えられる可能性と却下していった理由

料金未払い

これはないと考えていました。なぜなら、クレジットカードの自動更新です。洗い替えなどもあるだろうと真っ先に却下。

それ以上に、そのドメインでWHOIS検索したところ2027年まで有効。しかも、そのネームサーバは仮想サーバを向いています。

ドキュメントルートが読めない。

  • ディレクトリのパーミッション
  • 所有者
  • ドキュメントルートの設定

例えばpublic_htmlが何らかの操作で700になってしまうと、nginxが403を返します。

WAF偽陽性による.htaccessの書き換え。

「アプリを起動したら更新ができなくなった」から来る推察。

であれば、WAFによってアクセスが遮断された。偽陽性です。(筆者も散々経験がありますが)

WAFが下手に.htaccessを書き換えることでアクセス制限を喰らった

つまり、更新の時に何かしらの操作ミスがあって一斉に403を返したのではないか。

だとすれば

  • 仮想サーバの管理画面に入る
  • 下手をすればサイトの再構築

あたりも考慮に入れて、その持ち主のところを訪れます。

原因と復旧

訪れるやいなや、

「料金督促メール来てました!」

という連絡。つまり、「私が最初に斬って捨てた」原因だったのです。

この落とし穴は、ドメインとサーバーの契約期間が異なっていたことでした。

  • ドメイン:
    • 数年単位で契約済み
  • サーバー:
    • 単年契約で更新漏れ

その結果、

  • WHOISは正常
  • DNSも正常
  • ドメインも生きている
  • しかしWebサーバーは契約停止状態のため403を返す

という、一見するとWordPress障害にも見える状況が出来上がっていた次第。そして、決済を確認後、

curl hoge.example.com
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="https://hoge.example.com/">here</a>.</p>
</body></html>

が返ってきましたし、サイトも完全復旧です。

真っ先に外した「なぜ支払いが行われなかったか」

これも実に単純でした。

「クレジットカードを紛失して再発行した」

という、極めて人間らしいミスでした。この督促メールも

「大量のメールに紛れて見落としていた」

種が分かってしまえば実に単純。これを忘れて

  • htaccess
  • WAF

などを疑ったのが私の技術バイアスであり真の問題は

「サーバー契約は本当に有効か?」

というチェックが抜けていたことでした。そして、その契約切れと自動更新がオフになって苛理由は

クレジットカード再発行

だったという物理的な問題に抜けていました。

  • 「自動更新の設定」
  • 「決済手段が現在も有効か」

は別問題です。ところが、人間は

自動更新 = 更新される

と無意識に補完してしまいます。

実際には、自動更新は「決済に成功すれば更新される」であって、

  • カード期限切れ
  • カード再発行
  • 利用停止
  • 限度額超過

などで、静かに失敗することがあります。

技術スタックの落とし穴

利用者
↓
WordPress
↓
PHP
↓
Apache/nginx
↓
サーバー契約
↓
DNS
↓
ドメイン契約

という技術的な例で解釈をしていましたが、実際の原因は「サーバー契約」というアプリケーションより一段下の状況だったのです。

デブリーフィングという名の言い訳。

今回の一件で唯一良かったと思ったところは、

この事態を重く受け止め、どういう結果でもいの一番に駆けつけるという「速度は誠意」を見せられたこと。

しかし、問題はそれ以前にあります。

バイアス1:技術バイアス

ここのところ私は

  • Webサーバ周りのチューニング
  • AIクローラーとの戦い
  • セキュリティ

といった技術バイアスに溺れていました。ですから、この問題も同じに違いないという利用可能性ヒューリスティック(Availability Heuristic)に捕らわれていたこと。

これが第一の問題。

バイアス2:心理的バイアス

実写版『カイジ 人生逆転ゲーム』での好きな言葉があります。

「利根川‥‥
 俺がヘビに見えたか‥‥‥?」
 「ああ‥‥‥
  ヘビだろうが‥‥‥‥!」
「そうか‥‥‥
 なら お前こそヘビなんだ‥‥‥‥
 こんなふうな物言わぬ心理戦は
 鏡を見るようなもの‥‥‥
 相手の心を読もうと‥‥
 必死に考えるつもりが‥‥‥
 気がつけば自分だったらどうするかと考えている‥‥‥
 つまり俺がヘビに見えたなら‥‥‥
 お前こそヘビなんだ‥‥‥」

つまり、相手の初歩的な設定漏れや状況の変更という前提を忘れ、技術に溺れていました。これが深刻です。

上記でも述べたように、私は「請求忘れ」という一度は正解に導いていたのに「自動更新設定はしているはず」として、真っ先に切り捨てたこと。しかし、よくよく考えれば

  • カードの有効期限切れ(洗い替えをしていなければ)
  • 今回のカードの再発行
  • 残高不足(支払い能力)

というのは容易に起こりえます。こういう人間的な問題を「そんなことはまずないだろう」とした心理的なバイアス。このカイジの言葉で言うのなら「このサーバで何をしたのか」と鏡を見るように考え込み、自分が起こしがちなミス=相手のミスと考えていたこと。

バイアス3:生存バイアス。

最後に、「今までも解決してきた。だからこれもすぐに解決できる」という生存バイアスです。それこそ、私がメモとして利用しているGrowiのトップページの

Those who survive a long time on the battlefield start to think they are invincible.
I bet you do too, buddy.

"不死身のエースってのは戦場に長く居たものの過信だ"
"お前のことだよ相棒"

という、『ACE COMBAT ZERO』の言葉を真に噛みしめた、が今日の結論ですね。

ビタースイートな結末

と、上記、最初に述べたような言い訳の方が多い失敗談となりましたが、

成功体験が積み重なると、人は「今回もきっと高度な技術的原因だ」という思考になりやすいです。そして、そこが一番の慢心の結果です。

そして今回の真相はカード再発行で自動更新が止まっていた。あまりにも「人間的」でした。

余談、と言うか警句

この出来事が起きた日、夢枕に亡父が立ったのです。生前、父は

いかなる敵にも敬意を払え。その上で全力で叩き潰せ

とよく言っていて、没後10年目に夢枕に立ち

この言葉の真意は、「敬意を払わないとどこかに油断・慢心が生まれる。それが敗因に繋がる」という意味だからな

と但し書きをしました。なので、今回の物言わぬ夢枕は

この言葉を理解しているのか?

を問うものだったかと思います。即ち、この、技術的に物事を解決したため、その本質を見失っているぞという警告の予言めいた出来事だったのかな、と改めて思いました。

Apacheモジュール「mod_alias」解説。

筆者がWebサイトの防衛に、そして過剰にクロールをするボットを他の場所へとご案内するために用いているmod_aliasのご紹介です。

というのも、筆者がこれから述べる対クローラー迎撃システム「Jailhouse Lock」には、このモジュールが必要だからです。

1. mod_aliasとは何か?

mod_aliasは、リクエストされたURLをファイルシステム上の特定の場所にマッピング(転送・代替)したり、別のURLへリダイレクトしたりするための、Apacheの標準モジュールです。(そのため、多くのディストリビューションではインストールと同時に機能が有効化されています)

主な役割は以下の2つです。

  • エイリアス(別名)の設定:
    • ドキュメントルート(公開ディレクトリ)の外側にあるフォルダを、あたかも内側にあるかのようにURLに紐付けます。
  • 単純なリダイレクト:
    • 特定のURLに来たアクセスを、別のURL(別ドメインなど)へ転送します。

代表的なディレクティブ

  • Alias /images /var/www/shared/images (URLの/imagesを特定のフォルダに対応付ける)
  • Redirect permanent /old.html http://example.com/new.html (永続的な301リダイレクト)

2. mod_rewrite との違い

どちらも「URLを操作する」という意味では同じですが、そのアプローチと内部処理の複雑さに大きな違いがあります。

項目mod_aliasmod_rewrite
コンセプト単純なマッピングとリダイレクト強力なURLカスタマイズと書き換え
判定基準単純な前方一致(接頭辞マッチ)正規表現、Cookie、環境変数、時間など
処理速度非常に高速(軽量)やや低速(ルール毎に正規表現エンジンが動く)
設定の難易度簡単(初心者向け)複雑(記述ミスで無限ループが起きやすい)
主な用途フォルダの共通化、単純なサイト引っ越し綺麗に整形されたURL(Smart URL)の実現、複雑な条件分岐

最大の違い:正規表現と条件分岐の有無

mod_aliasは、URLの「先頭が一致しているか」という単純な比較しか行いません。

一方、mod_rewriteは「リクエストがGoogle Chromeから来たら」「平日の昼間なら」「Cookieに特定の文字が含まれていたら」といった、高度な条件分岐(RewriteCond)や、正規表現を使った自由自在なURLの作り替え(RewriteRule)が可能です。

3. mod_aliasが「優れているパターン」

「mod_rewriteがあれば、mod_aliasはいらないのでは?」と思われがちですが、Apache公式も「単純なタスクであれば、mod_rewriteではなくmod_aliasを使うべき」と推奨しています。

mod_aliasを選ぶべき(優れている)具体的なパターンは以下の3つです。

① サーバーのパフォーマンス(速度)を最優先したいとき

mod_rewriteは、リクエストが来るたびに複雑な正規表現エンジンを動かすため、CPUリソースを消費します。

大規模サイトやアクセスが集中する環境で、単なるURLの転送やフォルダの紐付けを行う場合、mod_aliasの方が圧倒的に処理が軽く、サーバーの負荷を抑えられます。

② ドメイン全体の引っ越しや、単純なURL変更(リダイレクト)

サイトのリニューアルで、古いページから新しいページへ1対1で転送したい場合や、古いドメインから新ドメインへ丸ごと転送したい場合は、mod_aliasの Redirect で十分対応できます。

  • サイト全体を新ドメインへリダイレクト(mod_alias)
Redirect permanent / https://new-example.com/

これをmod_rewriteで書くと記述が複雑になり、設定ミスのリスク(無限ループなど)が高まります。

③ 複数サイトで画像やアセット用のフォルダを安全に共有したいとき

例えば、サーバー内の /var/www/common_assets/ というフォルダを、複数のWebサイトで /assets というURLで共通利用したい場合です。

  • 安全かつ高速に共通フォルダをマッピング(mod_alias)
Alias /assets /var/www/common_assets

mod_aliasは設定がシンプルなため、ヒューマンエラーによるセキュリティホールの発生(意図しないシステムファイルの公開など)を防ぎやすいというメリットもあります。

それぞれのイメージ

1. mod_alias のシーケンス(単純・高速)

URLの書き換えは行わず、リクエストされたURLの先頭(接頭辞)だけをチェックして、即座にファイルパスへマッピングするか、リダイレクトを返すシンプルな流れです。

sequenceDiagram autonumber participant Client as クライアント (ブラウザ) participant Core as Apache コア (リクエスト受付) participant Alias as mod_alias participant FS as ファイルシステム Client->>Core: HTTPリクエスト (例: /images/logo.png) Core->>Alias: URLの評価を依頼 Note over Alias: URLの先頭(接頭辞)が<br>設定と一致するか単純比較 Alias-->>Core: マッピング先を返却<br>(例: /var/www/shared/images/logo.png) Core->>FS: 指定されたパスのファイルを読み込み FS-->>Core: ファイルデータ Core-->>Client: HTTP 200 OK (レスポンス返却)

2. mod_rewrite のシーケンス(複雑・高機能)

リクエスト受付後、内部でループ(再エントリー)が発生する可能性や、条件判定(RewriteCond)のステップが挟まるため、柔軟ですが処理の工程が多くなります。

sequenceDiagram autonumber participant Client as クライアント (ブラウザ) participant Core as Apache コア (リクエスト受付) participant Rewrite as mod_rewrite participant FS as ファイルシステム Client->>Core: HTTPリクエスト (例: /user/profile) rect rgb(240, 245, 255) Note over Core, Rewrite: [書き換えループの開始] Core->>Rewrite: URLの評価を依頼 Note over Rewrite: 1. 正規表現でURLパターンをマッチング Note over Rewrite: 2. RewriteCondの条件をチェック<br>(Cookie、ブラウザ、環境変数など) Rewrite->>Rewrite: 3. URLの書き換え処理を実行<br>(例: /index.php?mod=user&act=profile) Rewrite-->>Core: 書き換え後の内部URLを返却 end Core->>Core: 内部リダイレクト(新しいURLで再処理) Core->>FS: 最終的なスクリプトやファイルを呼び出し FS-->>Core: 実行結果・データ Core-->>Client: HTTP 200 OK (レスポンス返却)
  • mod_alias(図1):
    • 判定が「前方一致のみ」の一方通行であるため、ステップ数が少なく、非常に高速に処理が終わります。
  • mod_rewrite(図2):
    • 条件チェックのフェーズ(薄い青枠の部分)が多く、さらに書き換えたURLでApache内部で「もう一度リクエストを処理し直す(内部リダイレクト)」という挙動が発生するため、機能性と引き換えに処理が重くなる構造が見て取れます。

まとめ:使い分けの基準

それぞれの使い分けです。

  1. まずは mod_alias で実現できないか考える。(単なる転送、単なるフォルダの紐付けなど)
  2. 「クエリストリング(?id=123など)を判定したい」「特定のブラウザだけ除外したい」「正規表現でURLを激しく書き換えたい」といった複雑な要件が出てきたとき初めて mod_rewrite を導入する。

どちらが優れているか、否かという問題ではなく、これは速度の問題です。

漫画『MASTERキートン』に以下のやりとりがあります。

「やめておけ」
「…………」
「拳銃の方が、ナイフよりも速いと思っているんだろう。
 だが、拳銃はデリケートな道具だ。
 弾が出ないかもしれないし、
思い通り的に当たるとは限らん。
おまけに拳銃は、
抜き、構え、引き金を引くまでに三動作(スリーアクション)……
 その点ナイフは、一動作(ワンアクション)で終わる。
この距離なら、絶対に俺が勝つ!!
どうする? それでもやってみるかね?」

これは「至近距離でのナイフの有用性」を示したものであり、実際にその通りだという説得力があるものです。(調査結果はこの記事です

つまり、mod_alias は「できることが少ないから速い」のではなく、「役割を絞っているから速い」のです。

mod_aliasはナイフの速度。mod_rewriteは拳銃のような強力さがあります。「適切な距離感」でこれらのツールの利用、併用を行いましょうというお話しです。

卵焼きメモ2026年6月版。

一時的に今まで使っていたスープジャー(汁物)の運用を一時的に止めました。

そんな中で美味しい卵が手に入ったので、また卵焼きの熱が高まりました。

今回着目したのはこちら。

チーズです。そもそもチーズオムレツがスタンダードになるぐらい、チーズと卵の相性は抜群です。

醤油系とも相性がいいのは想像に難くないでしょう。

反面、焼くのにコツがいりますが

しっかりきれいに焼けました。

できあがったのはこちら。一段弁当は「これぞ弁当」な見た目になるのもお気に入りです。

2026年の紫陽花。

最も好きな花の一つである紫陽花。名所を2つほど。

飛鳥山公園

王子公園、飛鳥山。

こちらは電車沿線との無機質な取り合わせが素晴らしいです。

本土寺

千葉北西部の名刹、本土寺。

今度は寺の広い境内を活かした密度が魅力。

曇り空だからこそ似合う花があるから梅雨は楽しみまで見えます。

RHEL9系LinuxにMySQLを導入

RHEL9系ディストリビューション(Rocky Linux 9.7)にMySQLを導入したときのメモです。

そもそもDB(データベース)とは何なのか?

一言で言えば、「特定のルールに従って、整理整頓されたデータの集まり」です。

言うなれば「超高性能な図書館」のようなものです。
閲覧者、借りている人の帳簿を司り、膨大な本から一瞬で目的の1ページを探し出し、同時に何百人もの人が本を借りようとしても混乱が起きないように管理されています。

MySQLなどの「RDBMS」

MySQLは正確には「リレーショナルデータベース管理システム(RDBMS)」と呼ばれます。

  • リレーショナル(関係性): データを「表(テーブル)」の形式で管理し、複数の表を関連付けることができます。
  • 管理システム: データそのものではなく、データを操作・管理するためのソフトウェアのことです。

何を司るのか(役割と機能)

MySQLが担っている主な役割は、大きく分けて以下の4つです。

  • データの格納と検索(CRUD)
    • データの登録(Create)、参照(Read)、更新(Update)、削除(Delete)の4つを、膨大な量の中から高速に行います。
  • 整合性の維持(つじつまを合わせる)
    • 「注文データはあるのに、注文したユーザーのデータがない」といった矛盾(バグの元)が起きないよう、データの整合性を厳しく見張ります。
  • 同時実行の制御(排他制御)
    • 例えば、残り1つの商品を2人が同時にクリックした際、どちらか一方が確実に買えるように調整し、「1つしかないのに2人に売れてしまった」という事故を防ぎます。
  • セキュリティと権限管理
    • 「この人は閲覧だけ」「この人は編集もOK」といった具合に、大切なデータへのアクセスをコントロールします。

なぜ大事なのか(存在理由)

なぜExcelファイルやテキストファイルで管理するのではダメなのでしょうか?

データの爆発に対応するため

テキストファイルだと、100万件のデータから1件を探すのに上から順に読み込む必要があり、時間がかかりすぎます。DBは「インデックス(索引)」という仕組みを持ち、瞬時にデータを見つけ出せます。

データの「信頼性」を保証するため(ACID特性)

銀行振込を想像してみましょう。

  1. Aさんの口座から1万円引く
  2. Bさんの口座に1万円足す

もし「1」の直後にシステムがダウンしたら、1万円が消えてしまいます。

こうならないよう、DBには「トランザクション」という仕組みがあり、「すべて成功するか、すべてなかったことにするか」のどちらかしか認めません。これが社会インフラを支える信頼性の正体です。

複数のプログラムから共有できるため

Linuxサーバー上で動く

  • Webサイト
  • スマホアプリ
  • 管理画面

など、バラバラな入り口から入ってくる要求を、一つの窓口(MySQL)が交通整理して処理してくれます。

まとめ

MySQLは、システムにおける「記憶の番人」です。

  • DBとは: 整理されたデータの基地。
  • 司るもの: データの出し入れ、矛盾の防止、アクセスの交通整理。
  • 大事な理由: 膨大なデータを「速く」「正確に」「安全に」扱うため。

LinuxにDBを入れるということは、そのサーバーに「確かな記憶力」と「厳格な管理能力」を持たせるということに他なりません。

ここまで踏まえ、LinuxにDBを入れていきましょう。

インストールとディレクトリ準備

MySQLサーバーのパッケージを導入し、MySQLサービスが利用するディレクトリの権限をあらかじめ適正化。

  • MySQLサーバのインストール
sudo dnf install -y mysql-server

サービスの起動と初期ログイン

MySQLサービスを有効化し、初期状態でのログインを確認。

  • サービスの有効化と起動
sudo systemctl enable --now mysqld
  • 初期ログイン(MySQL 8.0では初期状態はパスワードなし)
mysql -u root

rootパスワードの確定

ログイン直後にMySQLのroot顕現のパスワードを設定します。

※先ほどのDBの話に戻ります。DBは「システムのデータそのもの」を管理します。先ほどの図書館の例で言うと

  1. 利用者
  2. 所蔵されている本
  3. その本がどこにあるか(貸し出し中か、書架か)
  4. どのようなジャンルか、作者は?

まで全て記録されている状態です。ここで、例えば、悪意ある者が「『ハムレット』の作者は『クリストファー・マーロウ』である」としたい場合、悪意ある者はそのような行為ができてしまいます。

そのため、攻撃者はDBのroot権限を真っ先に奪います。それを防ぐためにも最初にrootパスワードを設定します。

  • rootユーザーに対して新パスワードを適用
ALTER USER 'root'@'localhost' IDENTIFIED BY 'Your_Strong_Password';

パスワードは自分の環境に合わせます。パスワード設定後、そのデータを適切な方法・手段・保管場所に格納してください。

  • 権限設定
FLUSH PRIVILEGES;
  • コンソールから抜ける
EXIT
  • パスワードで入れるかを確認
mysql -u root -p

設定したパスワードでログインできることを確認します。確認後、EXITで抜けます。

セキュリティの堅牢化 (mysql_secure_installation)

対話型スクリプトを用い、商用・本番環境に耐えうるセキュリティ設定を一括で適用します。 以下のように行ってください。

Enter password for user root:

で、先ほどのrootパスワードが聞かれます。

その後、いくつかの確認事項があるのでYで答えます。

設定項目内容理由
Remove anonymous usersYes誰でも接続できる穴を塞ぐため
Disallow root login remotely?Yesローカル管理に限定し攻撃経路を遮断するため
Remove test database and access to it?Yes不要なオブジェクトの排除
Reload privilege tables now?Yes設定内容を有効化するため

Page 1 of 18

Powered by WordPress & Theme by Anders Norén