Day 067 — 2026-10-07 | マクロ① macro_rules! ⑫ 実在クレートのマクロを読む：bitflags・rust-fsm・statig を ADR-063 と「アクションをどこに置くか」で照合する（扉を rust-fsm の形に移すと状態 4→6・入力 5→7・RecordFailure が消える／bitflags_match! の腕の return は関数から抜けない）

📚 背景知識（読んでから問題へ）

Day 059〜066 で自作した fsm! は、世界で使われている実物と比べてどの位置にいるのか。今日はそれを確かめる日です。照合の物差しは2本です。

1. Day 063 の ADR-063（マクロを追加してよい基準） — 関数・型で書けない次の4つの場合だけマクロにする。

①呼び出し元の制御フローを変え、かつ ? で書けない ②引数の評価を遅らせ、かつクロージャで書けない ③stringify!/line! などソース情報が要る ④struct・impl・enum などの item を生成する

1. Day 066 の「アクション（副作用）をどこに置くか」 — (c-1) &'static [Act] で返す（採用）／(c-2) Vec で返す／(c-4) コールバックで渡す／(b) 返さない。加えて Day 065 の「ガードの中で文脈を書き換える」（Cell）

読む相手は3つです。選んだ理由は、bitflags は macro_rules! だけで item を大量に生成する定番クレート（このマシンのローカルのレジストリにも 1.3.2・2.13.1・2.13.2 の3版が入っており、他のクレートの依存として引き込まれている）で、rust-fsm と statig は fsm! と同じ「状態機械の表を書く」問題を別の作り方で解いているからです。

今日の問題は「読む」ことが中心ですが、読んだ主張のうち手元で確かめられるものは実行して確かめました（Part 3・Part 4）。

📝 問題

Part 1: ADR-063 で仕分ける

次の4つのマクロは、ADR-063 の基準 ①〜④ のどれでマクロであることを正当化できますか。複数当てはまるなら全部挙げてください。また、macro_rules! か proc-macro かを答え、proc-macro なら「なぜ macro_rules! で書かなかったのか」を一次資料の文から推測してください。

Part 2: アクションはどこにあるか

rust-fsm の中核の型はこうです（rust-fsm/src/lib.rs から引用、今回取得）。

📋 コピーpub trait StateMachineImpl {
    type Input;
    type State;
    type Output;
    const INITIAL_STATE: Self::State;
    fn transition(state: &Self::State, input: &Self::Input) -> Option<Self::State>;
    fn output(state: &Self::State, input: &Self::Input) -> Option<Self::Output>;
}

statig の状態ハンドラはこうです（README.md から引用）。

📋 コピー#[state]
fn led_on(context: &mut Context, event: &Event) -> Outcome<State> {
    context.do_something();
    Handled
}

問い:

1. rust-fsm・statig・XState v5（Day 066 で読んだ transition() が [nextState, actions] を返す）・Day 066 の fsm! の4つを、「判断と実行が分かれているか」「1回の遷移で出せるアクションの数」「ガードが文脈を読めるか」の3列で表にしてください
2. statig の形で Day 065 の不具合 B2（失敗回数を2回数える）は起こりえますか。型で止まりますか

Part 3: 扉を rust-fsm の形に移す（予想してから確かめる）

Day 066 の扉（状態4・事象5・文脈 failures/code_ok/is_admin）を、上の StateMachineImpl の形（transition と output は状態と入力しか見ない）に移すとします。実行する前に予想してください。

1. 状態はいくつ、入力はいくつになるか。failures と code_ok() と is_admin はそれぞれどこへ行くか
2. Day 066 のアクション RecordFailure・ResetFailures・SoundAlarm のうち、残るものはどれか
3. Day 066 の S5（「失敗3回の状態で正しい番号を入れても警報」）は、移した後どう書けるか
4. 締め出しの回数を 3 から 10 に変えたら、状態の数と行数はどう変わるか

Part 4: 実物のマクロの書き方を予想する

1. bitflags! は旗の名前を $Flag:ident ではなく const $Flag:tt = $value:expr; で受けています（src/lib.rs 484 行目）。なぜ ident ではだめなのか。ident にしたら何が出るか予想してください
2. bitflags_match! は展開を (|| { ... })() というクロージャで包んでいます（ソースのコメント: "Expand to a closure so we can use return"）。次の関数の early(Perm::R) は何を返すか予想してください

📋 コピーpub fn early(p: Perm) -> i32 {
    let v: i32 = bitflags_match!(p, {
        Perm::R => { return 1; },
        _ => 2,
    });
    v * 100
}

Part 5: 判断を記録する

「自作の fsm! を使い続けるか、rust-fsm か statig に乗り換えるか」の ADR を 10 行以内で書いてください。採らなかった案の却下理由と、前提が変わったら判断がどう変わるかを必ず含めること。

💡 ヒント

📋 コピー#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum S { Locked0, Locked1, Locked2, Closed, Open, Alarm }
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum I { UnlockOk, UnlockNg, Lock, Push, Pull, ResetAdmin, ResetUser }
// transition(&S, &I) -> Option<S> と output(&S, &I) -> Option<O> を match で書く

✅ 模範解答

Part 1 の答え

読み取ること:

• 4つとも ADR-063 のどれかで説明でき、「短く書けるから」だけのものは無い。 自作の fsm! も ④（enum 3つと impl を生成）で、同じ位置にいます
• M3 が macro_rules! でない理由は README の文からは断定できません。推測（未検証）: Closed(Unsuccessful) => Open [SetupTimer] と HalfOpen => { Successful => Closed, ... } の2つの書き方を混ぜられる構文や、全行から状態名を重複なく集めて enum を作る処理は、macro_rules! では Day 059 の数え上げ・重複除去と同じ苦労になります。自作の fsm! が state Door { .. } と状態を先に宣言させるのは、この重複除去を避けるための選択でした（Day 064）
• M2 は Day 061 の持ち越し「$s:expr で定数パスを受ける if x == $s 連鎖版」の、実物の実装例です。bitflags は連鎖の順序が意味を持つことをドキュメントに明記しています: "Patterns are evaluated in the order they appear in the macro."

Part 2 の答え

2 の答え: 起こりえて、型では止まりません。 statig のハンドラは &mut Context を受けるので、「判定の前に数える」と「判定の後に数える」を同じハンドラの中で2回書けば2回数えます。ただし Day 065 と違う点が2つあります。

• statig のハンドラは普通の Rust の関数で、ガードは match と if で書きます。Day 065 の B2 は「| で並べた腕でガードが2回評価される」というマクロが作った match の性質から来ていましたが、statig では1つの事象につきハンドラが1回呼ばれるだけなので、その経路は無い（README の構造からの推論。statig を動かしての確認はしていない）
• &mut がシグネチャに見えているので、レビューで「この関数は文脈を書き換える」と分かる。Day 065 の &Ctx + Cell は、シグネチャが「読むだけ」と嘘をついていた

statig が判断と実行を分けないのは欠陥ではなく、選択です。 statig は README で "Compatible with #![no_std], state machines are defined in ROM and no heap memory allocations." と書くとおり組み込みを主な対象にしています。組み込みでは「その場でピンを叩く」方が自然で、アクションを値にして返す層は余分になりやすい。逆に、Day 066 の S8（720 通りで on() が純粋）のような全数検査は、statig の形では文脈のスナップショットを比べる必要があり、手間が増えます。

Part 3 の答え（実測、rustc 1.96.0、edition 2024、Apple M1）

確認に使ったコード（rustc --edition 2024 --test mealy.rs && ./mealy --nocapture。rust-fsm 本体は入れず、StateMachineImpl と consume を一次資料と同じ形で手書きした）:

📋 コピー// rust-fsm 0.8 の StateMachineImpl と consume を写した最小版（クレートは入れず、同じ形で手書き）
pub trait StateMachineImpl {
    type Input; type State; type Output;
    const INITIAL_STATE: Self::State;
    fn transition(state: &Self::State, input: &Self::Input) -> Option<Self::State>;
    fn output(state: &Self::State, input: &Self::Input) -> Option<Self::Output>;
}
#[derive(Debug, PartialEq, Eq)] pub struct TransitionImpossibleError;
pub struct StateMachine<T: StateMachineImpl> { state: T::State }
impl<T: StateMachineImpl> StateMachine<T> {
    pub fn new() -> Self { Self { state: T::INITIAL_STATE } }
    pub fn from_state(state: T::State) -> Self { Self { state } }
    pub fn state(&self) -> &T::State { &self.state }
    pub fn consume(&mut self, input: &T::Input) -> Result<Option<T::Output>, TransitionImpossibleError> {
        if let Some(state) = T::transition(&self.state, input) {
            let output = T::output(&self.state, input);
            self.state = state;
            Ok(output)
        } else { Err(TransitionImpossibleError) }
    }
}

// Day 066 の扉を、文脈なし（transition/output は state と input しか見ない）で書き直す
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum S { Locked0, Locked1, Locked2, Closed, Open, Alarm }       // 失敗回数を状態名に埋める
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum I { UnlockOk, UnlockNg, Lock, Push, Pull, ResetAdmin, ResetUser } // 照合・権限は呼び出し側で判定して入力に埋める
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum O { SoundAlarm }                                             // 数えるアクションは不要になる
pub struct Door;
impl StateMachineImpl for Door {
    type Input = I; type State = S; type Output = O;
    const INITIAL_STATE: S = S::Locked0;
    fn transition(s: &S, i: &I) -> Option<S> {
        use {I::*, S::*};
        Some(match (s, i) {
            (Locked0 | Locked1 | Locked2, UnlockOk) => Closed,
            (Locked0, UnlockNg) => Locked1,
            (Locked1, UnlockNg) => Locked2,
            (Locked2, UnlockNg) => Alarm,
            (Closed, Lock) => Locked0,
            (Closed, Push) => Open,
            (Open, Pull) => Closed,
            (Alarm, ResetAdmin) => Locked0,
            _ => return None,
        })
    }
    fn output(s: &S, i: &I) -> Option<O> {
        match (s, i) { (S::Locked2, I::UnlockNg) => Some(O::SoundAlarm), _ => None }
    }
}

#[cfg(test)]
mod tests {
    use super::*;
    #[test] fn s4_third_failure_alarms() {
        let mut m = StateMachine::<Door>::new();
        let r: Vec<_> = (0..3).map(|_| { let o = m.consume(&I::UnlockNg); (*m.state(), o) }).collect();
        assert_eq!(r, vec![(S::Locked1, Ok(None)), (S::Locked2, Ok(None)), (S::Alarm, Ok(Some(O::SoundAlarm)))]);
    }
    #[test] fn s5_alarm_state_rejects_unlock() {
        // 「失敗3回で Locked のまま」は表せない。Alarm 中の UnlockOk は遷移不能
        let mut m = StateMachine::<Door>::from_state(S::Alarm);
        assert_eq!(m.consume(&I::UnlockOk), Err(TransitionImpossibleError));
    }
    #[test] fn s7_only_admin_resets() {
        let mut m = StateMachine::<Door>::from_state(S::Alarm);
        assert!(m.consume(&I::ResetUser).is_err());
        assert_eq!(m.consume(&I::ResetAdmin), Ok(None));
        assert_eq!(*m.state(), S::Locked0);
    }
    #[test] fn sizes() {
        println!("size_of State={} Output={} consume戻り値={}", std::mem::size_of::<S>(), std::mem::size_of::<O>(),
            std::mem::size_of::<Result<Option<O>, TransitionImpossibleError>>());
    }
    #[test] fn table_shape() {
        let ss = [S::Locked0,S::Locked1,S::Locked2,S::Closed,S::Open,S::Alarm];
        let is = [I::UnlockOk,I::UnlockNg,I::Lock,I::Push,I::Pull,I::ResetAdmin,I::ResetUser];
        let mut ok = 0; for s in ss { for i in is { if Door::transition(&s,&i).is_some() { ok += 1; } } }
        println!("組み合わせ {} 通り中 遷移あり {}", ss.len()*is.len(), ok);
    }
}
fn main() {}

出力（実測）:

📋 コピーrunning 5 tests
size_of State=1 Output=0 consume戻り値=1
組み合わせ 42 通り中 遷移あり 10
test tests::s4_third_failure_alarms ... ok
test tests::s5_alarm_state_rejects_unlock ... ok
test tests::s7_only_admin_resets ... ok
test tests::sizes ... ok
test tests::table_shape ... ok
test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

読み取ること:

• 文脈を持たない状態機械では、文脈は状態か入力へ押し出される。 表は 4×5=20 通り（Day 066）から 6×7=42 通りに広がり、そのうち遷移があるのは 10（実測）
• その代わり、「起きてはいけない組み合わせ」が型から消えます。 Day 066 では Ctx::new(Some("1234"), 3, false) と Door::Locked の組（失敗3回なのに締め出されていない）を作れたので、S5 という仕様テストが必要でした。rust-fsm の形ではその組が書けません。「不正な状態を表せないようにする」（make illegal states unrepresentable）の典型です
• Output が1種類だけの enum は大きさ 0 バイト、consume の戻り値 Result<Option<O>, _> は 1 バイト（実測）。Day 066 の Result<Step, Rejected> は 24 バイトでした。アクションが固定の1個なら、列（ポインタ＋長さ 16 バイト）を持つ必要が無いからです
• 代償は回数の上限が型に焼き込まれること。上限を設定ファイルで変えたい・ユーザーごとに変えたいなら、この形は使えません。また、回数を DB に保存したい（監査）なら、消えたはずの RecordFailure 相当の出力が結局また要ります

Part 4 の答え（実測）

1 — _ は ident に合わず、呼び出し側でエラーになります。

同じファイルの by_tt!{ A = 1; _ = 2; }（$f:tt）は通りました。bitflags が tt を使うのは、ドキュメントの "If the identifier is _, then the flag is unnamed. Unnamed flags don't appear in the generated API, but affect how bits are truncated." を実現するためです。const _ = !0; は「名前は要らないが、すべてのビットを既知として扱う」宣言です。

代償: tt は何でも1トークン受けるので、const 1 = 2; のような誤りもマクロの入口では弾けず、展開後の const 宣言で初めてエラーになります（Day 062 の「受け口が広いほどエラーが遠くなる」と同じ。bitflags でこの誤りを入れたときのエラー文は未確認）。

2 — early(Perm::R) は 100 を返します。1 ではありません。

📋 コピーearly(R)=100 early(W)=200

return 1; は bitflags_match! が作ったクロージャから抜けて、クロージャの値が 1 になり、v * 100 が実行されます。コンパイラは警告を1つ出しますが、内容は「到達しない式」で、「その return は関数から抜けない」とは言いません。

（cargo new --lib bf に bitflags = "=2.13.2" を足し、cargo test --offline で実測。size_of::<Perm>() は 1 バイト）

これは ADR-063 の ① 「呼び出し元の制御フローを変える」が両刃であることの実例です。bitflags はクロージャで包むことで「腕の値を return で返せる」ようにしましたが、その代わり腕の中の return の意味が、普通の match と変わりました。マクロの外から見ると match のような見た目なので、match の感覚で return を書くと読み違えます。

Part 5 の答え（例）

📋 コピーADR-067 扉の状態機械に自作 fsm! を使い続けるか
決定: 自作 fsm! を使い続ける。文脈を読むガード（failures・code_ok・is_admin）と、1遷移で複数のアクション（RecordFailure→SoundAlarm）が仕様にあるため。
採らなかった案:
  rust-fsm: transition/output が文脈を見ない。状態 4→6・入力 5→7・表 20→42 通り（実測）、上限を状態名に焼き込む。出力は 0〜1 個。
  statig: ハンドラが &mut Context で判断と実行を同じ場所で行う。Day 066 の S8（720 通りで on() が純粋）を型で保てない。
  手書きの match（マクロなし）: Day 064 の表と同じ行数で書けるが、enum 3つ・Rejected の定型を毎回書く（ADR-063 ④ の理由が残る）。
前提が変わったら: 回数の上限が固定で、不正な組み合わせを型で消したいなら rust-fsm の形へ。
  入れ子の状態（Alarm の中に「鳴動中／消音中」）や entry/exit アクションが要るなら statig へ（自作で入れ子を作らない）。
  値を持つアクション（監査ログ）が要るなら、どれを選んでも Vec かコールバックが要る（Day 066 (c-2)(c-4)）。
測れていないこと: rust-fsm・statig 本体のビルドと実行（今日は trait の形を写した手書き版のみ）、コンパイル時間。

🪜 Step-by-Step 解説

Step 1: 「何を生成しているか」で ADR-063 に当てる

マクロを読むときは、まず展開結果が item か式かを見ます。bitflags!・state_machine!・#[state_machine] は struct・enum・impl を生成するので ④。関数では struct を外へ出せないので、マクロ（か build.rs のコード生成）しか手段がありません。bitflags_match! は式を生成するので ④ ではなく、match で書けない「等値比較の連鎖」と、return を受け止めるための制御フローの変更（①）が理由です。

Step 2: macro_rules! か proc-macro か

bitflags がこれだけ多くの機能（serde・arbitrary・bytemuck 連携を含む、src/external.rs に __impl_external_bitflags_* マクロ群）を macro_rules! で書き切っているのは、依存を増やさないこと（bitflags は多数のクレートの下に入る土台）を優先しているからだと読めます（推測。一次資料の明言は未確認）。

Step 3: シグネチャから「判断と実行」を読む

ドキュメントを全部読まなくても、中核の関数の型を4行読めば設計の立場が分かる。Rust の &/&mut の区別が、ドキュメントの代わりをしています。

Step 4: 文脈を状態に押し込むとどうなるか

rust-fsm は rust-fsm/src/lib.rs のドキュメントで、作れるものを "A Mealy machine by providing all entities listed above." と説明しています。ミーリ機械（出力が状態と入力で決まる有限状態機械）は、有限であることが前提です。失敗回数のような数え上げは、有限の範囲（0〜2）に限れば状態に展開できます。展開すると不正な組み合わせが消える一方、上限が型に焼き込まれます。Day 066 の Ctx は、UML ステートマシンでいう「拡張状態」（extended state、状態の外に持つ変数）にあたります。

Step 5: マクロの中のクロージャは制御フローを変える

bitflags_match! の (|| { ... })() は、腕の値を return で返す実装のための道具です。利用者が腕の中に書いた return・?・break は、すべてクロージャの境界で止まります（? と break は今日は試していない。return のみ実測）。自作マクロでクロージャを使うときは、利用者のコードをクロージャの中に入れていないかを確認する、が今日の教訓です。

🧭 設計思想・なぜこう書くのか

3つのクレートは、同じ「状態機械を Rust で書く」問題に対して、Rust の型システムのどこに重みを置くかが違います。

• rust-fsm は「有限であること」に重みを置き、文脈を持たないことで、不正な状態を型から消す
• statig は「組み込みで速く、確保なしで」に重みを置き、&mut Context で直接書き換える。純粋さより、その場で実行する素直さを選ぶ
• 自作の fsm!（Day 066） は「判断の純粋さ」に重みを置き、&Ctx と &'static [Act] でそれを型に写す

どれもゼロコスト（確保なし）で、どれも &/&mut で立場をシグネチャに表しています。違うのは何を型で保証し、何をテストに残すかです。rust-fsm は S5 を型で保証し、Day 066 は S8 を型で保証しました。両方を型で保証する形は、今日読んだ範囲には無く、これがトレードオフの本体です。

迷った他案と採らなかった理由（今日の問題の作り方について）

前提が変わったら: クレートを取得してよい環境（Mac mini、ネットワーク可）で、rust-fsm と statig を実際に入れて、cargo expand で展開結果を自作 fsm! と並べるなら (B) に移ります。

🚨 コンパイルエラーが出た場合

今日はデバッグ問題ではありませんが、Part 4 で出た2つを残します。

🔀 他言語との比較

Rust の2列と XState の列は今日取得した一次資料の範囲です。Go・Java の列と Spring Statemachine は今日は確認しておらず、記憶に基づく要旨です。

🏭 実務での使いどころ

• ライブラリを選ぶとき、中核の関数のシグネチャを先に読む。 README の宣伝文より、fn transition(&State, &Input) の1行の方が「文脈を持てない」ことを正確に教えます。今日の Part 2 の表は、そのまま選定会議の比較表になります
• プロトコルの実装（TCP の状態・TLS のハンドシェイク・サーキットブレーカー）は rust-fsm の形が合う。 状態が有限で、文脈は少なく、不正な遷移を型で消したい。rust-fsm の README の例がサーキットブレーカー（Closed(Unsuccessful) => Open [SetupTimer]）なのはそのためです
• 組み込みのファームウェアは statig の形が合う。 その場でピンを叩き、確保しない。入れ子の状態で共通の処理を親に寄せられる
• 業務ワークフロー（承認・決済）は Day 066 の形が合う。 回数・金額・権限などの文脈が多く、判断を DB なしで全数テストしたい
• マクロをレビューするとき: 利用者のコードがクロージャの中に入っていないか（Part 4-2）、tt で受けていてエラーが遠くなっていないか（Part 4-1）を見る

⚠️ よくある誤解・ミス

🔗 一次資料（参照日: 2026-10-07。今回取得して、引用部分を照合済み）

• bitflags 2.13.2 のソース（ローカル ~/.cargo/registry/src/index.crates.io-*/bitflags-2.13.2/src/lib.rs、直接読んだ）
  • 484 行目: const $Flag:tt = $value:expr;
  • "If the identifier is _, then the flag is unnamed. Unnamed flags don't appear in the generated API, but affect how bits are truncated."
  • "The macro expands to a series of if statements, checking equality between the input expression and each pattern." / "Patterns are evaluated in the order they appear in the macro."
  • // Expand to a closure so we can use return``
• rust-fsm README: https://github.com/eugene-babichenko/rust-fsm/blob/master/README.md
  • "Using the DSL will require to connect an additional crate rust-fsm-dsl (this is due to limitation of the procedural macros system)."
  • DSL の例 Closed(Unsuccessful) => Open [SetupTimer],
• rust-fsm lib.rs: https://github.com/eugene-babichenko/rust-fsm/blob/master/rust-fsm/src/lib.rs
  • StateMachineImpl の定義、consume の定義（Part 2・Part 3 に引用）、"A Mealy machine by providing all entities listed above."
• rust-fsm-dsl lib.rs: https://github.com/eugene-babichenko/rust-fsm/blob/master/rust-fsm-dsl/src/lib.rs
  • #[proc_macro] pub fn state_machine(tokens: TokenStream) -> TokenStream、syn・quote を使用、impl StateMachineImpl for Impl を生成
• statig README: https://github.com/mdeloof/statig/blob/main/README.md
  • the #[state_machine] macro "simply parses the underlying impl block and derives some code based on its content."
  • "Compatible with #![no_std], state machines are defined in ROM and no heap memory allocations."
  • fn led_on(context: &mut Context, event: &Event) -> Outcome<State>

📌 今日扱わなかった範囲（次回以降）

3 問の自己点検

1. 同じ指示を AI に出せば数時間で出るか — 3つのクレートの紹介文は出る。ただし、扉を rust-fsm の形に移すと状態 4→6・入力 5→7・表 42 通り中 10 遷移・RecordFailure が消えて S5 が型に吸収されること、bitflags_match! の腕の return で early(R) が 100 を返し警告の文面からは気づけないこと、_ が ident に合わない実際のエラー文は、手元でビルドして得た結果
2. AI に指示するだけでは出ない部分 — Day 063 の ADR-063 と Day 066 の (c-1)〜(b) という、この連載で自分が作った物差しで実物を測ったこと。そして「rust-fsm は S5 を型で守り、Day 066 は S8 を型で守る。両方を守る形は読んだ範囲に無い」というトレードオフの特定
3. 世界の実物と比べて何割か — statig の README が挙げる機能（入れ子の状態・entry/exit・文脈・no_std・非同期など）のうち扱ったのは文脈とアクションの置き場所の2つ。rust-fsm の中核（StateMachineImpl の4項目＋consume）は全部扱った。bitflags のマクロ 26 個のうち読んだのは bitflags!・bitflags_match!・__bitflags_match の3つ

➡️ 次のステップ

• 発展: 入れ子の状態（Alarm の中に「鳴動中／消音中」）を、自作 fsm! で表すとどうなるかを設計する。statig の superstate と比べて、自作で作るべきでない線を決める（設計・アーキテクチャ）
• 次回予告: マクロ① の残り期間（〜10/24）で、Day 066 の発展「値を持つアクション（監査ログ）を (c-2) Vec と (c-4) コールバックで比べる」設計問題、または入れ子の状態の設計問題

🎯 自己評価（解いた後に記入）

Part 3・Part 4 の予想と実際（状態の数、early(R) の値）

自分の回答

気づき・メモ