再現

MySQL 8.4.8、mysqldef v3.11.3 で確認しました。

schema.sql:

CREATE TABLE tasks (
  id BIGINT NOT NULL AUTO_INCREMENT,
  priority VARCHAR(50) NOT NULL,
  PRIMARY KEY (id),
  CONSTRAINT chk_tasks_priority
    CHECK (priority IN ('normal'))
);

これを mysqldef で適用したあと、もう一度同じ schema.sql で実行すると、毎回 ALTER が出続けます。

ALTER TABLE `tasks` DROP CHECK `chk_tasks_priority`;
ALTER TABLE `tasks` ADD CONSTRAINT `chk_tasks_priority` CHECK (priority in ('normal'));

何度実行しても収束せず、CIで「diff なし」を期待していると常に落ちる、という状態になります。

SHOW CREATE TABLE してみる

差分を出されている DB 側の状態が気になり、 SHOW CREATE TABLE で実体を確認してみました。

CREATE TABLE `tasks` (
  ...
  CONSTRAINT `chk_tasks_priority` CHECK ((`priority` = _utf8mb4'normal'))
)

schema.sql に書いた IN ('normal') が、 DB 側では = 'normal' になっています。

原因：MySQL は CHECK 式を正規化して保存する

調べてみると、 MySQL 8 は CHECK 制約の式をパースしたあと、正規化した形で保存するようです。1要素の IN (...) は等価な = に書き換えられます。

sqldef は schema.sql の状態と DB の現状を比較して差分の DDL を生成します。今回のケースでは、

• schema.sql 側: IN ('normal')
• DB 側: = 'normal'

が一致しないと判定され、毎回 DROP → ADD の ALTER が生成されます。ADD 後に DB 側がまた = に正規化されるので、いくら適用しても収束しません。

回避策

CHECK 制約を書くときに、要素数で書き分けます。

-- 1要素なら =
CHECK (priority = 'normal')

-- 2要素以上なら IN
CHECK (priority IN ('normal', 'high'))

= 'normal' で書けば DB 側の表現と一致し、 mysqldef は Nothing is modified を返して冪等になります。

2要素以上の IN (...) は MySQL も内部表現を IN のまま保存するため、こちらも冪等です。

さいごに

宣言型のスキーマ管理ツールは「目標 = 現状」の同値判定が肝です。その判定は DB エンジン側の式の正規化に左右されるため、 schema.sql に書いた SQL がそのまま DB に保存される保証はありません。

何かおかしいなと思ったら SHOW CREATE TABLE で実体を確認する、というのを安全装置として覚えておこうと思いました。

移行先の構成

Hono と BullMQ を組み合わせ、TypeScript で実装しています。 BullMQ の Job Scheduler で cron スケジュール実行、Hono で Webhook の受け付けを行っています。

前回の記事と同様に Synology NAS 上で動かしており、app コンテナと Redis コンテナを Docker Compose で立ち上げています。

現在動いているワークフローは、

• 毎日12時にRSSフィードから新着記事の情報を取得し、AI要約とリンクを通知
• 毎日7時に天気予報を取得・加工し、AIによる外干しプラを付加して通知
• 睡眠トラッキングアプリ（Sleep as Android）のイベントを Webhook で受け取り、寝室の照明（SwitchBot）の自動制御や通知

などがあります。 いずれも、n8n ワークフローからの移行です。

なぜ移行したか

AIコーディングツールの進化で「コードを書く」コストが劇的に下がったためです。

元記事では以下のように書いていました。

コード生成（プロンプトを組み立て、コードを生成させ、動作を検証し、実行環境を整えてデプロイする）する方法よりも早く目的の処理を実現できました。

2024年9月時点ではこれが実感でした。
しかし2026年2月現在、Claude Code に簡潔な依頼を投げるだけで、公式ライブラリを探してドキュメントを読み、実装、テスト、デプロイ、資料更新までを一貫してやってくれるようになりました。
「コードを書く」側のコストが大きく下がったことで、n8n を使う動機が薄れました。

組み込みノードの難しさ

n8n は500を超える組み込みの integrations を持っており、そのおかげでローコードで様々なワークフローを実現できます。

ただ、実際に使ったのはそのうちのごくわずかでした。 また、Claude API をはじめ未対応のサービスも多く、対応していてもメジャーではない機能や新しく追加されたばかりの機能には対応が追いついていません。 特にAI関連サービスは変化が速いため、組み込みノードの恩恵を受けにくい領域でした。

そうなると、各社の API を調べ、Edit ノードや Code ノードを組み合わせて HTTP Request ノードで API を直接叩き、レスポンスを再び基本的なノードで加工し…、という流れになりがちで、フローの構築に時間と手間がかかります。
それよりは、サービス公式のライブラリを入れてコードで書いた方がずっと早い、と感じるようになりました。

GUI ワークフローと AI の相性

GUI ベースのワークフロー構築やデバッグは、AI に任せにくいと感じました。
n8n-mcp のような試みもありますが、普通の TypeScript を書かせて、普通にテストして、というサイクルの方が楽でスムーズでした。

n8n の Code ノード内にコードを書くこともできますが、実ファイルのコードならテストも書けますし、差分管理もしやすいです。

「妻でも編集できる」のその後

n8n 導入時は、コーディングが不慣れな妻でも GUI でワークフローを編集できることがメリットの1つでした。

しかし今や、妻も Claude Code を使って開発するようになりました。
AI も、人も、成長しました。

チューニング

Redis コンテナをデフォルト設定のまま起動したところ、ほぼ待機状態のシステムにしてはそれなりの CPU 使用率がありました。
Redis の hz パラメータ（バックグラウンドタスクの実行頻度）を 1 に設定したところ、app コンテナと同程度の低い水準に落ち着きました。

以下の画像は、左半分が before で、停止、再起動（スパイク部分）を経て、after でCPU使用率の低下を確認するまでの様子です。

メモリ使用量は n8n の約350MBに対し、新構成では50MB以下になりました。

さいごに

n8n は視覚的なわかりやすさや実行履歴の管理など、優れた点が多いツールです。
しかし今では、個人的な「動けば十分」なワークフローの作成・メンテナンス程度なら、AIに全て任せられるようになりGUIのワークフローエディタは不要になりました。

元記事の最後では

n8nを超えるとしたら、もっとAIが活用されるようになるのかなと思います。 フローの構築や編集も、人力ではなくAIに任せられるようになると嬉しいですね。

と書いていましたが、その通りになりました。

2027年末あたりには、全て AI Agent に置き換わっているかもしれません。

2026-02-01: Camelidae

問題文に FLAG がありました。

2026-02-02: Substance

tar.gz の中には、2つの大きい数が書かれた output.txt と、chal.py が入っていました。 chal.py に登場するメソッドを見ておきます。

• int.from_bytes: bytesを受け取り整数表現を返す
• random.randint(a, b): 範囲 [a, b] の整数をランダムに返す

chal.py は flag * a * b * c と flag * d * e * f （a～fは2～2026のランダムな整数）を出力するようです。
実際は A * flag と B * flag と考えてよいでしょう。

とりあえず、最大公約数から N * flag （N = gcd(A, B)）を求めてみると、 31748696846809458845893315116545812553950394766538362807608704739811018 でした。
このまま .to_bytes(32) しても正しくdecodeできないため、 N > 1 と推測できます。
2で1回、3で2回割ってから .to_bytes(32) すると正しくdecodeできるようになり、FLAGが得られました。

2026-02-03: read-a-binary

配布ファイルはバイナリファイル1つでした。
リバースエンジニアリングの問題のようです。

$ ./read-a-binary 
Input > abc
Incorrect...

バイナリ解析は初心者なので、AIに聞きながら進めることにします。
まずバイナリ内の文字列を抽出する方法を聞いてみると、 strings を提案されました。
strings read-a-binary | less で

• Correct! The flag is %s
• Incorrect...

などの文字列が含まれていましたが、 Alpaca… は見つかりませんでした。

もう一つの提案、 xxd を眺めてみると…

.........H.E.H..
H..f...H........
......0...A..1..
.l..2...p..3...a
..4...c..5...a..
6...{..7...D..8.
..e..9...c..:...
…

A l p a c a … が見えました。7 bytes おきに FLAG が分割されているようです。
ということで、文字列結合して s[::7] で、やたら長い FLAG を入手できました。

ところで… FLAG によると、デコンパイラを使うとよかったようです。なるほど…

2026-02-04: Magic Engine

nginx の default.conf によると、このサーバーは複数の hostname を兼任しており、hostname admin.alpaca.secret の / が FLAG を返してくれるようです。

curl -H "Host: admin.alpaca.secret" （対象サーバー）

で、FLAG を入手できました。

2026-02-05: RRe_Time_Limiter

flag を 349以下の各素数で割ったときの余りから、flagを割り出す問題です。

「2 で割ったときの余りが 1 になる数」は、1, 3, 5, … です。
この数列を昇順で見つつ、「3 で割ったときの余りが 2」も満たすところで止まれば、2条件を満たす数（ここでは 5）が得られます。
次は 5 + (2*3)n の数列を昇順に… と全ての条件を満たす数を得られるまで操作を続けることで、FLAGを得られます。

primes = [2, 3, 5, …]
outs = [1, 2, 0, …] 

c = 1
ans = 0

while primes:
    p = primes.pop()
    o = outs.pop()
    while ans % p != o:
        ans += c
    c *= p

print(ans.to_bytes(43))

2026-02-06: The World

サーバー側の時刻と100nsレベルで一致する入力を送ることでクリアできるようです。
大量のリクエストを送れば…とも考えましたが、入力を色々試す中でサニタイズが甘いことに気が付きました。 FLAG と入力し、エラーメッセージから FLAG を得られました。

2026-02-07: misdirection

strings でバイナリを読むと、ダミーのフラグと、reverseされた真のフラグがありました。

2026-02-08: Compressor

テキストを送ると、 FLAG + input を zlib.compress した際のサイズが返されます。
様々な入力を与えて、「うまく圧縮される」文字列が見つかった場合、それが FLAG と共通する部分を多く持つと推測できます。

フラグは Alpaca{ で始まることがわかっているので、 known + 1文字 を総当りし、最も圧縮された1文字を結合し新たな known として次の1文字を総当り…していけば特定できそうと思いました。

しかし、やってみると同率一位の候補が多数出現して詰まってしまいました。
試行錯誤した結果、 (known + 1文字) * 4 を入力とすることで20文字程度を当て、複数候補が現れたところでrepeatをやめることで最後まで特定できました。

2026-02-09: Plz Login

ログイン画面が表示され、username: admin で正しいパスワードを入れると FLAG が表示されるという問題です。

username/password の一致判定部分が怪しいかと思いましたが突破口が見つからず。
curlで様々なリクエストを試行していたところで「0文字のusernameを渡すと username[0] で IndexError が発生し、トレースが表示される」ことを発見し、トレースにif文の判定ロジックが含まれていたため、そこで password が判明しました。

例: curl -X POST http://localhost:3000/login -d "username=&password="

あとは通常のログイン画面に “admin” と判明したpasswordを入力するだけです。

debug=True で実行されていたことが根本原因でした。

2026-02-10: Alpaca-Llama Ranch

セグフォを起こせば、シェルを起動できるようです。

unsigned alpaca, llama （種類別の合計数）と、それぞれ各個体のID情報を格納する配列（長さ0x40）に対して入力できますが、 alpaca+llama > 0x40 のバリデーションがあります。

ここで、 alpaca, llama 単体でのバリデーションが無いことに注目すると、オーバーフローを狙えそうです。
結果として alpaca+llama <= 0x40 となるように 4294967295, 2 などを選び、あとは書き込みまくることでシェルを起動し、フラグを入手できました。

2026-02-11: destructuring

複雑な構造の要求に合うJSONを渡せば FLAG を貰えます。

ソースコード内のフォーマット部分を文字列として、以下のような文字列置換をすることで正しいJSONを生成することができました。

import re

def transform(s: str) -> str:
    s = s.replace('_', '')
    s = re.sub(r'([a-zA-Z]):', r'"\1":', s)
    s = s.replace('[,', '[0,')
    s = s.replace(' ,', '0,')
    s = s.replace(', ]', ',0]')
    s = s.replace(' ', '')
    return s

なお、当初は読みやすくスペースを入れたり使わないvalueには null を入れたりしていたのですが、今回は nc で手動入力していた関係で入力が長すぎると（おそらく 4096 bytes）入力がカットされてしまったため、密なJSONとなるよう調整しました。

2026-02-12: AAAAAAAAEEEEEEEESSSSSSSS

FLAG の各1文字を8連続に引き伸ばし、それをランダムな鍵で MODE_ECB でAES暗号化した値が返されます。 また、インタラクティブな仕組みがあり、任意の入力値を同じ鍵で暗号化した値も返されます。

MODE_ECB （ブロック長 16 bytes）であること、1文字が8連続（8 bytes）になっていることを考えると、2文字の組み合わせ（約3000通り）とその暗号化hexの対応を導けば、元の FLAG がわかります。

これを実行するスクリプトを用意し実行することで、FLAG を入手できました。

2026-02-13: nc magic

（実は最初に解いた問題のため、初歩的な部分から書いています。）

タイトルや問題文の netcat / nc を調べると、TCP/UDPの接続を手軽に扱えるコマンドラインツールとのことでした。ポートスキャンやリッスンも対応、便利…。

tar.gz に含まれるファイルを読むと、ネットワーク越しに server.py に入出力できるようです。 server.py は print されたランダムな hex string をその場で渡すだけで FLAG をくれるようですが、実際にやってみるとうまく行きませんでした。
server.py の内容をよく読むと

if sys.stdin.buffer.readline() == secret.encode():

となっており、単にコピペして渡すだけでは改行が問題となるようです。
実際にソースコードの secret の末尾に "\n" を追加してみると、手入力でも FLAG が返ってくることを確認できます。

整理すると、受け取ったテキストに含まれるコードを、末尾に改行を含めずに送信する必要があるということになります。

Ruby で実現できそうだったので、

docker run --rm -it --network host ruby irb で

require 'socket'

HOST = '127.0.0.1' # ターゲットによって変える
PORT = 1337 # ターゲットによって変える

s = TCPSocket.new(HOST, PORT)
line = s.gets
secret = line.split[3]
s.write(secret)
s.close_write
s.read

を実行し、FLAG を取れることを確認できました。

irb(main):012> s.read
irb(main):013> 
=> "Alpaca{REDACTED}\n"

同様の手順で本番サーバーから FLAG を入手すると、クリアです。

2026-02-14: simple ROP

win 関数を適切な引数とともに呼び出せば FLAG を入手できるようです。

gets という見慣れない関数が出てきたので調べると、脆弱な実装になりやすいため廃止されたとのことでした。なるほど。
-fno-stack-protector も調べ、オーバーフローによるリターンアドレスの書き換えを防止する（書き換えられたことを検知する）仕組みであることを理解しました。なるほどなるほど。
様々な改善や仕組みで守られているんだなぁ…。

今回はこれらのおかげで簡単にリターンアドレスの書き換えができます。

また、「ROP gadgets」として rdi, rsi, rdx のセットが用意されているので、これらで引数の値をセットしてから win を呼べばよさそうです。

buffer + RBP を埋め、値をセットしつつ最後に win を呼ぶような入力をすることで、FLAG を入手できました。

2026-02-15: You are being redirected

リダイレクト機能を持つ web サービスと、そこへブラウザ（puppeteer）でアクセスする bot サービスがあり、bot のアクセス時のクッキーを奪取するという問題でした。

リダイレクト処理の流れを追ってみると

1. URLパラメータの to の値を抽出する
2. その toLowerCase() が “data”, “javascript”, “blob” のいずれも含んでいないことをチェック
3. new URL(dest, base) で URL オブジェクトを作る
4. window.location.replace(url.href);

となっていました。
クッキーの内容を外部に投げるようなXSSを実行できれば良さそうです。

URL parser の仕様を調べていくと、The basic URL parser はTAB文字を除去するようでした。
これを利用し、java(tab)script:（クッキーを取得し用意した外部サーバーに送るスクリプト） を実行させることで、FLAGを入手できました。

バリデーションの考慮漏れ（というかJSの知らない挙動）、怖い。

さいごに

Daily AlpacaHack、楽しいし勉強になるし最高ですね。

この記事は、GMOペパボ エンジニア Advent Calendar 2025 🎄会場 の11日目です。

gem_rbs_collection とは

gem_rbs_collection は、RBSを同梱していないgemのための型定義を集めた、コミュニティ管理のリポジトリです。

rbs collection init
rbs collection install

で簡単に導入でき、steepなどの型チェッカーと組み合わせて利用できます。

作成したPR

これまで合計3つのPRを出しました。

PR #871: GraphQL::ExecutionError#initialize の型定義追加

graphql: Add types for GraphQL::ExecutionError#initialize #871

初めてのPRです。 graphql-ruby gemの GraphQL::ExecutionError#initialize メソッドは ast_node 、 options 、 extensions などの引数を受け取れますが、そもそもメソッドの型定義がなかったためにこれらの引数を渡すと型エラーが発生する状態でした。

test.rb:61:62: [error] Unexpected keyword argument
│ Diagnostic ID: Ruby::UnexpectedKeywordArgument
│
└       raise GraphQL::ExecutionError.new("Test error message", ast_node: nil, extensions: { "code" => "TEST_ERROR" })
                                                                ~~~~~~~~

test.rb:61:77: [error] Unexpected keyword argument
│ Diagnostic ID: Ruby::UnexpectedKeywordArgument
│
└       raise GraphQL::ExecutionError.new("Test error message", ast_node: nil, extensions: { "code" => "TEST_ERROR" })
                                                                               ~~~~~~~~~~

（これはテストコードをもとに当時の状況を再現したものです）

• gem の api-doc https://graphql-ruby.org/api-doc/1.12.0/GraphQL/ExecutionError.html#initialize-instance_method
• gem のソースコード https://github.com/rmosolgo/graphql-ruby/blob/v1.12.0/lib/graphql/execution_error.rb

などを確認しつつ、以下のような型定義を追加しました。

+ def initialize: (String message, ?ast_node: untyped, ?extensions: Hash[untyped, untyped]?) -> void

通常の開発であれば単体テストなどで動作を保証できますが、型定義ファイル自体はそもそも実行するものではないため実行時の挙動に基づいたテストはできません。
代わりに gem_rbs_collection では、まずそのgemを利用した際のコードを用意し、それを型定義ファイルに基づいた型検査がpassすることをテストします。

テストとして用意した実際のコードが以下です。

def error_field
  raise GraphQL::ExecutionError.new("Test error message", ast_node: nil, extensions: { "code" => "TEST_ERROR" })
end

このコードをテストに追加すると型検査が落ちるようになるので、型定義を修正し、再び型検査が通るようになることを確認しました。つまり、TDDのサイクルで進められます。

ちなみにgem_rbs_collectionはレビュー無しでもマージできる運用になっていますが、初めてで心配だったので念のためレビューを依頼し、approveを頂いてからマージしました。元々はこのPRに options 引数も含めていたのですが、レビューにて deprecated であることを指摘頂き修正しました。（ありがとうございました！）

PR #887: RQRCode::QRCode#initialize の型定義修正

rqrcode: Fix type definition for RQRCode::QRCode#initialize #887

rqrcode gemの RQRCode::QRCode#initialize はgemのREADMEにもあるようにオプションを受け取れますが、これが型検査にてエラーとなっていました。

test.rb:6:45: [error] Unexpected keyword argument
│ Diagnostic ID: Ruby::UnexpectedKeywordArgument
│
└ qr = RQRCode::QRCode.new("https://kyan.com", level: :h)
                                               ~~~~~

gem の実装に合わせた型定義に修正しました。

- def initialize: (String) -> void
+ def initialize: (String, *untyped) -> void

PR #933: GraphQL::Schema::Resolver.null メソッド署名の追加

graphql: Add GraphQL::Schema::Resolver.null method signature #933

graphql-ruby gemの GraphQL::Schema::Resolver.null クラスメソッドの型定義がなかったため、追加しました。

test.rb:76:4: [error] Type `singleton(::Mutations::Ping)` does not have method `null`
│ Diagnostic ID: Ruby::NoMethod
│
└     null true
      ~~~~

+ def self.null: (?bool allow_null) -> untyped

注意すべき点

gem_rbs_collection では、gem ごとに対象とするバージョンが定められています。
PRを作り始める前に、そのメソッドや引数が追加・変更されたバージョンと、型定義の対象バージョンをチェックしておくとよいでしょう。

おわりに

gem側の型エラーはその場でパッチを用意して暫定対応することもできますが、以前 RubyKaigi 2022 の発表 Types teaches success, what will we do? で流れを聞いていたので、この機会にコントリビュートしてみることにしました。

実際にやってみると、ハードルは思ったより低かったです。型定義の不足や誤りを見つけたら、暫定対応だけでなくコントリビュートも選択肢に入れてみてください。

2025/12/01～2025/12/03 の3問の内容が含まれます。

この記事は、GMOペパボ エンジニア Advent Calendar 2025 🎄会場 の9日目です。

Day1: AlpacaHack 2100

https://alpacahack.com/daily/challenges/alpacahack-2100

フラグは Daily AlpacaHack の 2100年1月 のカレンダーにあるパカ

とのことです（親切なアルパカだ）。

カレンダーのUIを見てみると、「前の月」「次の月」ボタンのみがあります。素直に2100年まで進めるには、およそ12回*74年分の「次の月」ボタンを押す必要があり、なかなか大変そうです。
とりあえず数回「次の月」ボタンを押してみると、URLのクエリパラメータが変化することに気づきました。

?month=2026-01
?month=2026-02
?month=2026-03
…

ということは、ここを直接 ?month=2100-01 に書き換えれば良さそうです。
実際にアクセスし、無事FLAGを入手できました。

感想や気づき

フロントのパラメータは信用するな、という基本的なセキュリティの教訓を改めて思い出しました。
この件は単にカレンダーの表示月なので問題は無さそうですが、パラメータを操作されても機密性が保たれるように設計することが重要ですね。

（2100年の運営さんは、どうするんだろう…）

Day2: a fact of CTF

https://alpacahack.com/daily/challenges/a-fact-of-CTF

問題を開くと tar.gz ファイルが置いてありました。適当にubuntuコンテナを立ち上げて展開してみると、 chall.py, output.txt の2つのファイルが出てきました。
chall.py は、環境変数 FLAG を決まった手続きで変換して標準出力するスクリプトのようです。
output.txt には 0x から始まる16進数の文字列が書かれていました。この内容は、特定の FLAG を chall.py に渡した際の出力結果ではないかと推測しました。

chall.py の決まった手続きとは、具体的には「昇順でn番目の素数 ** n番目の文字のコードポイント の総積を求め、16進数表現に変換」のようです。確かに output.txt の末尾は0がいくつか連続していて、 2 * 5 が含まれていそうな雰囲気です。
ということは、素因数分解して「昇順でn番目の素数がいくつ含まれるか」から、n番目の文字のコードポイントを逆算できそうです。
（ここで改めて問題を見ると Crypto とあり、暗号解読系の問題のようでした。なるほど。）

シンプルな処理なので、久しぶりにAIサポート無しの温かみのある手打ちコーディングをしてみました。使い捨てコードなので、動けばヨシ！

primes = [2]

for i in range(3, 300):
    if any(i % prime == 0 for prime in primes):
        continue
    primes.append(i)

with open('output.txt') as f:
    txt = f.read()

num = int(txt, 16)

decoded = []

for prime in primes:
    counter = 0
    while num % prime == 0:
        num //= prime
        counter += 1
    if counter != 0:
        decoded.append(chr(counter))

print(*decoded, sep='')

これを実行し、FLAGを入手できました。

感想や気づき

競プロのおかげで素数にビビらずに済みました。推理・暗号解読ゲームのような感覚で楽しく解けました。
逆操作で容易に復号できる暗号では手順が流出すると一気に解読されてしまうことを改めて認識しました。

Day3: Emojify

https://alpacahack.com/daily/challenges/emojify

tar.gz ファイルとIPv4のURLがありました。tar.gz の中には、Dockerfile、compose.yaml、frontend/backend/secret ディレクトリが入っていました。3つのサービスをdocker composeで立ち上げる構成のようです。
立ち上げて / にアクセスすると、以下のような画面が表示されました。

各要素について詳しく見ていきます。

• frontend は、/ に対し index.html を、 /api に対しては waf メソッド（怪しすぎる）を通した上で backend に問い合わせてレスポンスを返すようです。
• backend は、受け取ったパラメータを node-emoji に問い合わせて返すのみのシンプルなAPIサーバーです。node-emoji が見当たらない…と思ったら、package.json の依存関係にあり、 https://www.npmjs.com/package/node-emoji のようでした。
• secret は /flag エンドポイントを持つサーバーです。おそらく、機密情報を持つ内部サーバーのような設定でしょう。

通常のアクセスでは frontend と backend しか登場しないので、どちらかから secret にアクセスさせる必要があります。backend には隙が無さそうだったので、frontend から secret へのアクセスを目指すことにしました。

手始めに http://localhost:3000/api?path=/emoji/pizza を叩いてみると、🍕が返ってきました。
frontend は waf メソッドを通した後に new URL(path, "http://backend:3000") によってURLを生成しているようです。今回は path = "/emoji/pizza" なので、http://backend:3000/emoji/pizza というURLが組み立てられたことになります。

node v25.2.1 の new URL(input[, base]) のドキュメントを見てみると、

If input is relative, then base is required. If input is absolute, the base is ignored.

とありました。つまり、 path に絶対URLを渡せば、 base は無視され、任意のURLにアクセスさせることができそうです。
しかし、 http://localhost:3000/api?path=http://secret:1337/flag を叩いてみると、Invalid 1 というレスポンスが返ってきました。

waf メソッドは

• path がstring以外なら、 Invalid types 例外
• path が / から始まっていないなら、 Invalid 1 例外
• path に emoji が含まれていないなら、 Invalid 2 例外

というチェックを行っていました。
整理すると、「new URL(path, "http://backend:3000") を http://secret:1337/flag とするために path に絶対URLを渡したいが、path は / で始まる必要がある」という状況です。

URLの仕様でこれを実現できそうなものを探すため https://developer.mozilla.org/ja/docs/Learn_web_development/Howto/Web_mechanics/What_is_a_URL を見てみると、絶対パスではありませんがスキーム相対URL （例: //example.com/path）というものがあることがわかりました。これは、絶対URLからプロトコルのみを取り除いた形式です。

手元で new URL("//secret:1337/flag", "http://backend:3000") を試すと http://secret:1337/flag となり、狙い通りに動作することが確認できました。

これを利用し、emoji を含むというチェックの対策も入れたURL http://localhost:3000/api?path=//secret:1337/flag?emoji を叩いてみると、Alpaca{REDACTED} という secret にセットされたダミーのFLAGが返ってきました。

あとはこれを提供されるサーバー用にして叩くだけです。

感想や気づき

分類としてはサーバーサイドリクエストフォージェリとなりそうですね。
一見問題なさそうな入力値検証でも、仕様の見落としによってあっさりと突破され漏洩してしまうことを体感できました。

今回のケースであれば、

• /emoji/ までは固定し、以降を動的に組み立てる
• アクセス可能なホスト名やIPアドレスを許可リストで管理する
• secret のアクセス元を限定、あるいは認証する

などしていれば、同じ攻撃は成立しなかったでしょう。
防御は多層的に行うことが重要だと改めて感じました。

まとめ

初心者向けとはいえ、パラメータ操作、暗号解読、Web（SSRF）と幅広いジャンルを体験でき、普段の開発でも意識すべきセキュリティの観点を学び直す良い機会になりました。
何より、謎解き感覚で楽しく取り組めたのが良かったです。引き続き挑戦していきます。

Fisher–Yates shuffle アルゴリズム

Fisher–Yates shuffle は
「i を N-1, N-2, …, 1 まで変化させながら、0 以上 i 以下の整数をランダムに選択し(この整数を j とする) i 番目と j 番目の要素を入れ替える操作を繰り返す」というアルゴリズム…
と言われても、この説明だけではイメージが湧きにくいと思います。

JavaScript で実装すると以下のようになりますが、

function shuffle(array) {
    // i を N-1, N-2, ..., 1 までループ
    for (let i = array.length - 1; i > 0; i--) {
        // 0 以上 i 以下の整数をランダムに選択し（この整数を j とする）
        const j = Math.floor(Math.random() * (i + 1));
        // i 番目と j 番目の要素を入れ替える
        [array[i], array[j]] = [array[j], array[i]];
    }
    return array;
}

• もっとシンプルに、乱数を紐づけてソートではダメなの？
• たった1回のループで本当にシャッフルできているの？

など、気になります。

乱数を紐づけてソートする方法との比較

例えば以下の配列の要素をシャッフルしたいとします。

[1, 2, 3, 4, 5]

この配列の各要素に乱数を紐づけて

[[1, 0.83],
 [2, 0.37],
 [3, 0.45],
 [4, 0.13],
 [5, 0.52]]

乱数の方でソートし

[[4, 0.13],
 [2, 0.37],
 [3, 0.45],
 [5, 0.52],
 [1, 0.83]]

最後に乱数を削除すれば

[4, 2, 3, 5, 1]

シャッフルされた配列が得られます。

単純明快な手法ですし、ソート処理もメジャーな言語ならサポートされているので実装も楽そうです。
これでよさそうな気がしますが、実は改善できる点があります。

シャッフルに必要となるリソースを比較する

同じ結果を得られるなら、メモリ使用量が少ない方が嬉しいでしょう。

乱数を紐づけてソートする方法では、紐づけた乱数の分のメモリが追加で必要になります。
一方、Fisher–Yates アルゴリズムの場合、もとの配列の中で入れ替え処理を行うため、追加のメモリはほとんど必要ありません。

また、同じ結果を得られるなら、計算時間は短い方が嬉しいです。

少数のシャッフルなら方法によらず瞬時に計算が終わるので、ここではシャッフル対象の配列はある程度大きいものとして、対象の配列の長さ N が大きくなると計算時間がどのような伸び方をするかを比較してみます。
（例えば N が2倍、3倍、4倍…になったとき、計算時間も2倍、3倍、4倍…で済む実装と、4倍、9倍、16倍…のように膨れ上がっていく実装の2択なら、前者を選びたいですよね。）
乱数を紐づけてソートする方法では、基本的に伸び方は N*log(N) と表現されます。N が2倍、3倍、4倍…になったとき、計算時間は2倍、3倍、4倍…よりも大きくなってしまうということです。
一方、Fisher–Yates の伸び方は N と表現されます。つまり、2倍、3倍、4倍…で済むのです。
（詳細は時間計算量について調べてみてください）

Fisher–Yates shuffle は、メモリ使用量の面でも計算時間の面でも優れていることがわかります。

正しくシャッフルできているのか

いくら効率が良くても、例えば 「最初に前の方にあった要素が前に来やすい」というような偏りがあると困ります。
偏りをなくすにはどうすればよいでしょうか。

シャッフルの基本

「元の配列をどう並べ替えるか？」と考えると難しくなってしまいますが、シャッフルで実現したいことは最終的にランダムな順序にすることであり、最初の順序は気にする必要がありません。

そこで、

1. 一旦、元の配列の要素を1つの大きな袋に入れてしまう
2. 袋からランダムに1つ取り出し、最後尾に追加する という操作を繰り返す

と考えてみましょう。

初期状態の並び順に無関係で、シャッフル後の順序も偏りがないシャッフル方法ができました。
これと同じことをコードで実現すればよいのです。

function shuffle(array) {
    // まずは袋に入れる
    const bag = array.slice();
    const shuffled = [];

    while (bag.length > 0) {
        // 袋からランダムの1つ取り出し
        const randomIndex = Math.floor(Math.random() * bag.length);
        const selectedElement = bag.splice(randomIndex, 1)[0];
        // 取り出した要素を最後尾に追加する
        shuffled.push(selectedElement);
    }
    return shuffled;
}

in-place での実装

上記の実装では、シャッフルされた配列を新しく作成しています。
配列を新規作成しないような実装に変更するにはどうすればよいでしょうか。

もう一度、先程のシャッフルのイメージを思い出してみましょう。

ここで、袋の中身の順序は無関係という性質を利用し、配列のうち未シャッフル部分を袋として利用しましょう。
つまり、「袋から取り出し、最後尾に追加する」を「袋を1つ分縮小させる。この時、はみ出た要素が最後尾に追加されたことにする」と考えます。
このとき、「ランダムに1つ取り出す」は「ランダムに1つ選び、はみ出ることになる位置に移動させてから、袋を縮小させる」となります。

これを、実装しやすいように前後反転すると、最初の Fisher–Yates shuffle の実装になります。

GraphQLとの出会い

2024年9月に、EC事業部からSUZURI事業部へ異動しました。 SUZURIではGraphQLが採用されており、これまで聞いたことしかなかったGraphQLを初めて使うことになりました。
これまでほぼRESTで生きてきたので、なかなか衝撃的でした。「クライアントが好き勝手に複雑な構造のクエリを要求して、ちゃんとその構造の通りに、一発でデータを返してくれる…？そんなことある…？」となりました。

実際に学び、触れていく中で、そのシンプルで無駄のない仕組みに惹かれていきました。 また、競技プログラミングなどでグラフ関連のアルゴリズムを学んでいた経験があったため、データをグラフとして扱う考え方も面白く感じたポイントでした。

GraphQLのおもしろポイント

RESTはリソースとそれらの操作という考え方ですが、GraphQLではクライアントが必要なデータのみを指定して取得できる仕組みを提供しています。本当に必要な情報を過不足なく取得できるのは、通信の効率性という面で大きな利点といえるでしょう。
また、リソースをグラフとして捉えるアプローチは、GraphQLのスキーマにモデル間の関係をそのまま活かせる点が魅力です。ActiveRecordを使用しているプロジェクトでは、既存のモデリングを自然な形でAPIに反映できます。

開発時の注意点

アクセスが制限されるリソースに対して適切な制限を適用することが重要です。 もちろんこれはGraphQLに限ったことではありませんが、GraphQLでは入口を塞いでも回り道でアクセスされてしまうことに注意が必要です。
例えば、ルートの user フィールドにのみアクセス制限を適用している場合、

query {
    user {
        address
    }
}

のようなクエリには認証エラーを返せますが、

query {
    post {
        author {
            address
        }
    }
}

のように間接的にアクセスすると、個人情報を取得できてしまうかもしれません。
（これについては、GraphQL RubyのAuthorizationのドキュメントでより詳しくRESTとGraphQLの違いが説明されています。）

入口ではなく、リソースそのものにアクセス制限を適用することで、このような問題を防げます。 GraphQL Rubyなら、authorized? などが利用できます。

パフォーマンス面では、（これもGraphQLに限ったことではありませんが）N+1に注意する必要があります。 DataLoaderなど、効率化するための仕組みを活用しましょう。

学習方法とおすすめリソース

同僚におすすめされた「初めてのGraphQL ―Webサービスを作って学ぶ新世代API」（O’Reilly Japan）が参考になりました。 背景・歴史（第一章）やグラフ理論（第二章）などから始まっていて、GraphQLの本質的な部分から理解を深めることができ、「なぜGraphQLなのか」という根本的な疑問に答えてくれる内容でした。

GraphQL公式サイトのLearnセクションもコンパクトにまとまっていて、とても参考になります。 インタラクティブに試せるサンプルも用意されているので、実際に触って感覚を掴みたい方におすすめです。 ベストプラクティスについてもまとめられています。

最後に

GraphQLは「必要な情報を過不足なく取得する」という考え方を実現した、シンプルながら強力なアプローチです。適切に使いこなすことで、クライアントの要求に柔軟に応えつつ効率的な通信を実現できるでしょう。
また今回は触れませんでしたが、データの更新もGraphQLで行えますし、subscriptionを使えばリアルタイム向けの機能も実現できるところも面白いです。

ただし、アクセス制御やパフォーマンスなど、実装時に注意すべきポイントもあります。これらに適切に対応することで、GraphQLの利点を最大限に活かすことができるでしょう。

まだGraphQLを使ったことがない方、ぜひ一度触ってみてください。