詳細の実装より概念的なところを記録しておきたい気持ちです。

Resilient Parsingとは

Resilient Parsingとは「構文エラーがあっても、エラーを収集したり木構造を頑張ってパースする技」だと思いました。

アカデミックな分野ではエラーリカバリという概念？で微妙に違うっぽいです[要出典]。Crafting Interpretersでもpanic modeやsynchronizationみたいに飛ばし読みして復帰する技術はありますが、そこを一歩越えて、壊れた箇所は壊れてるとマークしつつ、木構造は維持するイメージみたいでした。

Resilient Parsingの概念については、matklad氏のResilient LL Parsing Tutorialが主要な参照元になるようです。自分の能力不足でOpusに質問してやっとちょっと意味がわかったかなという感じでした。

matklad氏の記事を読んだ後に、opusの指示のもとoxcのコードベースに近いResilient parsingを実装したのですが、やってることが結構違いました。

ここではその違いについて見ていきたいと思います。

ただ、すでにOpusが書いてくれた解説もあります。

matklad版

Resilient Parsingの例

最初に例です。以下のように不完全な式の定義が並んでいる場合でも、rust-analyzerのようなツールではなるべく壊れていないASTが欲しいです。

fn f1(x: i32,                  // 閉じ忘れ
fn f2(x: i32,, z: i32) {}      // カンマ重複
fn f3() {}

Resilient Parsingで実装すると、以下のような構造にパースされます。

File
  Fn
    'fn'
    'f1'
    ParamList
      '('
      (Param 'x' ':' (TypeExpr 'i32') ',')
      error: expected RParen // RParenがないことを報告している（実際は木のノードではなく別建ての診断リストに積まれる）
  Fn // 一つ前のFnに閉じ忘れがあっても、ちゃんとFn定義としてパースが開始されてる
    'fn'
    'f2'
    ParamList
      '('
      (Param 'x' ':' (TypeExpr 'i32') ',')
      ErrorTree
        error: expected parameter // カンマが重複していても、それ以降の引数もちゃんとパースされる
        ','
      (Param 'z' ':' (TypeExpr 'i32'))
      ')'
    (Block '{' '}')
  Fn
    'fn'
    'f3'
    (ParamList '(' ')')
    (Block '{' '}')

Resilient Parsingはいくつかのアイディアの組み合わせです。

• パースを試みるとき、最低１トークンは消費する（たとえエラー報告でも）

• 平坦なイベント列、ホモジニアスな木、の２段階でパースする

• 再帰下降パーサーはただのネストしたループ構造であり、パース時の処理は三択で表現される

最低１トークンは消費する

ここは強調されていたので重要な気がする。

パーサーあるあるは、無限ループに陥ってしまうことらしいですが、Resilient Parsingは最低１トークンは消費するのでその心配がない、というかそうならないように設計された概念な気がしました。

平坦なイベント列、ホモジニアスな木、の２段階でパースする

平坦なイベント列

まずはイベントの定義。

// イベント列の定義
enum Event {
  Open { kind: TreeKind },
  Close,
  Advance,
}

struct Parser {
  tokens: Vec<Token>,
  pos: usize,
  fuel: Cell<u32>,
  events: Vec<Event>, // これ
}

先ほどの例で言うと、パースする前に平坦なイベント列に変換されます。

ここではわかりやすく階層構造で表現してますが、実体はVecにpushされたトークンの集合です。 Open / Closeでトークンを囲み、現在のトークン（fnや(やxなど）は葉としてAdvanceと色付けされます。

Open(File)
  Open(Fn)                       ← f1
    Advance  fn
    Advance  f1
    Open(ParamList)
      Advance  (
      Open(Param)
        Advance  x
        Advance  :
        Open(TypeExpr)
          Advance  i32
        Close                    // TypeExpr
        Advance  ,
      Close                      // Param
      //── loop: 次は `fn`(=f2) → 回復集合にヒット → break
      //── expect(`)`) : 診断だけ出してイベントなし・前進なし
    Close                        // ParamList   ← `)` を欠いたまま閉じる
    // ── arrow なし / block なし
  Close                          // Fn
  // ...以下略

この構造の何が嬉しいかというと、Vec上のOpenの位置さえわかればあとで簡単に書き換えたり追加したりできるという点です。

matkladの記事中で書かれている例がわかりやすいです。f(1)(2) をパースする場合、Openは(f(1))(2)の左結合でパースしないといけないですが、f(1)まで読んだ時点では(f(1))と自分自身を囲むOpenを作ることはできません。

もし木構造であれば、f(1)(2)まで読み終えてから木構造全体を作り直す必要がありそうです。

平坦なイベント列であれば、「これは左結合だ」と気づいたタイミングで、Vecの特定の位置にOpenを差し込めば、構造として成立します。matkladの実装ではこれをopen_before()というメソッドで行っています（直前のCloseの前にOpenを遡って挿入する）。

また、壊れた構文を発見したときも、トークンを読んでエラーだと気づいたあとにOpen(Error) / Advance / Closeだ、ということがわかります。そのため、読み始めるタイミングではOpen(???)で、最後まで読んでから正解を埋め込めるというのが嬉しいです。

ホモジニアスな木

ホモジニアス（均質）な木とは、すべてのノードが「種類タグ＋子のVec」という構造のことです。子に何が何個来ても同じように扱います。

// ホモジニアス — ノードは1種類だけ:
enum TreeKind {        // 種類は「タグ」でしかない
    File, Fn, ParamList, Param, TypeExpr,
    ExprCall, ExprName, ExprLiteral, ErrorTree, ...
}

enum Child {
    Token(Token),      // 葉（リーフ）
    Tree(Tree),        // 枝
}

struct Tree {
    kind: TreeKind,    // ← 種類はここ。型ではなくデータ
    children: Vec<Child>,
}

この利点は「最低１トークン消費する」を実現しやすい点です。Errorがあっても、ErrorTreeとして素直に表現してトークンを消費することが可能です。

２段階でパースする

２段階でパースすることで、イベント列は単純にVecにpushしていき、イベント列をインプットに木に畳み込むだけ、というシンプルな分業が可能になります。エラーがあっても扱いが簡単です。

どちらの実装も複雑なアルゴリズムも必要ありません。

パース時の処理は三択で表現される

matkladの記事を読んでいてわりと感動したのが、パース時の処理が三択で表現される部分です。

一般的に、パーサ（構文解析）の処理は、次のような入れ子構造のループとして機能します。

loop { // 関数のリストを解析する
  loop { // 関数内のステートメント（文）のリストを解析する
    loop { // 式のリストを解析する
    }
  }
}

• 要素のパースを試みる: 正常系。param や stmt や arg を呼ぶ。

• 予期しないトークンをスキップする: advance_with_error で1個食べて続行(f2 の余分なカンマ)。

• ループを抜けて親に回復を委ねる: break(f2 で fn を見たとき)。

f2を例にとると、以下のようなコードです。

const PARAM_LIST_RECOVERY: &[TokenKind] = &[Arrow, LCurly, FnKeyword];
fn param_list(p: &mut Parser) {
  assert!(p.at(LParen));
  let m = p.open();
  p.expect(LParen);
  while !p.at(RParen) && !p.eof() {
    if p.at(Name) {
      param(p); // 仮引数、型注釈、カンマをセットで消費する
    } else {
      if p.at_any(PARAM_LIST_RECOVERY) { // ① {fn, '{'} を見つけちゃった
        break;
      }
      p.advance_with_error("expected parameter"); // ② トークン消費を続ける
    }
  }
  p.expect(RParen);
  p.close(m, ParamList);
}

1. f2(x: i32,, z: i32)の引数リストをパースするときに、次のfnキーワードなどが出てきてしまったということは、すでに次の関数のパースが始まってしまっていることになります。このままパースすると大半が壊れた木になってしまいます。そのため、いまの関数をパースするloopからはbreakで脱出します

2. 想定外の値があっても、Errorとして消費します

matklad版のまとめ

主要な概念については多分書けた気がします。よくできてて感動しますね。

oxc版

oxc版といっても、Opusがそういっていただけでまだ自分でコードを読んでないので正しいかわかりません。ただ、matkladのResilient Parsingとはだいぶ違うものみたいです。概念に共通点があるだけのようですね。

こちらはtyped ASTを直接組みながら2層のエラーで回復する方式です。実装としては、いままでpanic!で処理していた部分でexpect()して、エラーを突っ込んでいく感じです。例を見てみましょう。

本来は末尾に;が必要な"const x = 5"をパースした場合、以下のようなASTになります。

ParserReturn {
    statements: [
        ConstDeclaration {
            name: "x",
            type_annotation: None,
            init: Number {
                value: 5,
                },
            },
        },
    ],
    errors: [
        ParseError {
            message: "expected ';'",
        },
    ],
    panicked: false,
}

あるいは、不完全な構文"const x = ;"をパースした場合、以下のようなASTになります。

ParserReturn {
    statements: [],
    errors: [
        ParseError {
            message: "unexpected token in expression: Semicolon",
            span: Span {
                start: 10,
                end: 11,
            },
        },
    ],
    panicked: true,
}

この中で出てくるerrorsやpanickedが2層のエラー回復部分です。

errors と panicked

それぞれ役割が違います。

• errors: 回復可能なエラーを発見した場合は、この配列にpushして続行、木は残る

• panicked: 最上位で木構造を捨て、fatal_errorを報告

Dummyでスタックを巻き戻す

fatalが起きたとき、「Expressionを返す関数なのに値が作れない」ため困ります。oxcはResultや?でのエラー伝播を使用せず、Dummy::dummy()を捨て値として返す。これでコードがシンプルになります。

Resilient Parsingなのか？

panickedで木を捨ててしまうので、matkladが言う「Resilient parsing means recovering as much syntactic structure from erroneous code as possible.（レジリエントな構文解析とは、エラーを含むコードから、可能な限り多くの構文構造を復元することを意味します。）」とはちょっと違いそうですね。

errorsに詰めていく部分はresilient的な感じでしょうか。

というか、そもそもoxcではResilientという言葉は使われてないですね（笑）。Opus君、どうなっとんねん（？）

まとめ

Resilient Parsing、おもしろかったです。

matklad氏のResilient Parsingはrust-analyzerが念頭にあるのでなるべく部分木を残す方向ですが、oxcは静的解析時に強制終了してもそんなに困らないんですよね。なので、それぞれ目的に合った実装になっていると言う感じでしょうか。

oxcのコードがちょっとずつ読めるような気がしてきました。次回はアリーナアロケータ（ボスキャラ）を勉強しようと思います。

最終更新: 2026年6月19日

この記事はOpus4.8で生成してます！

こんにちは。6月も半ばですね。梅雨らしい天気が続いていて、洗濯物の行き場に困っています。

さて、去年の暮れに個人ブログを作った話を書いたばかりなのですが、性懲りもなくまた一から作り直しました。今回はFUNSTACK Staticという仕組みに載せ替えています。記事の中身はそのまま移してきたので、見た目だけ知らないうちに変わっていた、という方もいるかもしれません。

なぜまた作り直したのか

前回はNext.js + Fumadocsで、これはこれですごく良かったです。デザインも機能も最初から揃っていて、ほとんど書くことなく立ち上がりました。

ただ、ありものが良くできているぶん、自分で手を動かす余地があまり残っていなくて、「盆栽」として育てるには少し物足りなさもありました。せっかくの個人ブログなので、中身を全部自分で把握できるくらい小さく作って、気が向いたときにいじり倒したい。ちょうどRSC（React Server Components）でSSGする構成や、最近元気なRust製のツールチェーンを一度きちんと触ってみたかったのもあって、勢いで作り直すことにしました。

三日坊主の人間がブログそのものを作り直してしまうのは、たぶん現実逃避の一種です。そういうものですね。

FUNSTACK Staticについて

FUNSTACK Staticはuhyoさんが作られているフレームワークで、React Server Componentsをベースにした静的サイトジェネレータです。ビルド時に全ページをHTMLとして吐き出すので、ランタイムにサーバーがいりません。生成物を静的ホスティングに置くだけで動きます。

嬉しいのは、記事本文やMarkdownの変換をビルド時のサーバー環境だけで描画して、クライアントに送るJavaScriptを最小限にできるところです。インタラクティブにしたい「島」の部分だけがスクリプトになる、という感じですね。

ルーティングはFUNSTACK Routerというのが別であって、こちらはNavigation APIベースになっています。普通のリンクを踏むとクライアント側でぬるっと遷移してくれます。Navigation APIを実戦で使うのは初めてだったので、地味に楽しかったです。

Rust製ツールチェーンが楽しい

今回いちばん遊べたのがこのあたりです。気づけばビルドまわりがRust製だらけになっていました。

• Markdown変換・全文検索: ox-content。Markdownをmdastに変換するのも、全文検索のインデックスを作るのもこれ1つ。検索はCJK対応のBM25ランタイムが吐き出されて、それだけがクライアントに乗ります。

• OG画像生成: takumi-js。記事ごとのOG画像をビルド時に描いてくれます。ヘッドレスブラウザがいらないのが偉い。この記事のOG画像も、サイトと同じトンマナになるように作り直しました。

• シンタックスハイライト: shiki。ビルド時に色をHTMLへ焼き込むので、ハイライタ本体はクライアントに送られません。light/darkのデュアルテーマにCSS変数で追従させています。

Rustそのものを書いているわけではないのですが、こういう速いツールが裏で動いているのを眺めるのは気持ちがいいですね。コンパイラまわりの勉強も続けているので、いつかは中身も読めるようになりたいところです。

TypeScriptはネイティブ版に

型チェックはネイティブ版のTypeScript（tsgo）に一本化しました。tscの代わりにtsgo --noEmitで型を見ています。速いし、せっかくなので新しいものを使ってみたい、という軽い気持ちです。

デザインを「余白」の方に寄せた

前回はありもののデザインに乗っていたぶん、見た目がいかにもテンプレート然としていたのが、実はちょっと気になっていました。今回は温かい紙の地・墨色の本文・くすませた琥珀のアクセントで、本の余白に書き込みをするような落ち着いた雰囲気を目指しました。

ブランドの脇にちょこんと置いている手描き風のアスタリスク（✳）がお気に入りで、記事の区切りやファビコン、OG画像にも使い回しています。落ち着いてはいるけれど、ちょっとだけ遊びがある、くらいの塩梅にできていたら嬉しいです。

ついでに開発まわりも整備した

作り直したついでに、linter/formatterをoxlint / oxfmtに、Git hooksをlefthookに揃えました。push前にフォーマット・lint・型チェック・ビルドが通ることを確認してくれるので、雑にコミットしても後で気づける安心感があります。ファビコンもようやく設定しました。

まとめ

そんなわけで、ブログをFUNSTACK Staticで作り直したという話でした。小さく作れたぶん、これからは気軽にいじれそうで楽しみです。盆栽として、ぼちぼち育てていきます。

例によって三日坊主が顔を出すかもしれませんが、半年に一回でも書ければ御の字、くらいの気持ちでやっていきます。それでは。

最終更新: 2026年6月15日

今回はPratt Parserについてメモをしておきたいと思います。毎回ふんわりと理解して、ふんわり忘れるため…

自分でした実装（というかほとんどClaudeに書いてもらった）としては、typescript版とrust版があります。

ちゃんとした情報を知りたい方は、Simple but Powerful Pratt Parsingを読んでください。この記事以上の情報はここにはありません。

Pratt Parserとは

ざっくり自分の理解を書くと、「再帰下降パーサーで優先順位ごとに関数を分けなくても、結合力（binding power）を使えば loop + 再帰でフラットに構文解析できちゃうよ」ということだと思います。

別に再帰下降パーサーを使わなくなるわけではなく、組み合わせて使うこともあるようです。複数の演算子などがある場合に、結合力を定義してあげればうまくいく、というのが嬉しさっぽいですね。

Pratt Parserについての参考文献

他にもあると思いますが、自分が眺めた参考文献を列挙しておきます。

• matklad - Simple but Powerful Pratt Parsing: とにかくこれを読めばよし

• MoonBit Pearls Vol.01：Implementing a Pratt Parser in MoonBit: 一番最初のブログがこれなんだ〜（小並感）

• Top-Down operator precedence (Pratt) parsing: 比較的短め

以下では、実際に使われています。

• acorn/src/expression.js: Pratt とほぼ同型の優先順位パーサー（operator precedence parser）を使っています

• oxc_parser/src/js/expression.rs: 二項演算子の解析に使っています

なので、再帰下降 ＋ Prattがわかればだいぶ良さそうです。

Pratt Parserについて覚えておきたいこと

rust版を例に、コアのアイディアだけ自分が思い出せるように書いておこうと思います。コードとしては以下です。

a + b * cとa * b + cをそれぞれちゃんとパースできるか、というのが今回見たい例です。（元のコードと違って、三項演算子に関係する部分は削除してます。）

// 結合力の定義
fn infix_bp(&self, tok: &Token) -> Option<(u8, u8)> {
    match tok {
        Token::Ternary => Some((2, 1)),
        Token::Plus => Some((3, 4)),
        Token::Multiply => Some((5, 6)),
        _ => None,
    }
}

// 二項演算子をパースして、式のASTを返す関数
fn parse_expr_bp(&mut self, min_bp: u8) -> Expression {
    // PART 1
    let mut lhs = self.parse_atom();

    // PART 2
    loop {
        // PART 3
        let (lbp, rbp) = match self.infix_bp(self.peek()) {
            Some(bp) => bp,
            None => break,
        };

        // PART 4
        if lbp < min_bp {
            break;
        }

        // PART 5
        let op_tok = self.advance();

        let rhs = self.parse_expr_bp(rbp);
        let op = match op_tok {
            Token::Plus => BinaryOp::Add,
            Token::Multiply => BinaryOp::Multiply,
            other => unreachable!("infix_bp が Some を返したのに対応してない: {other:?}"),
        };
        lhs = Expression::Binary {
            left: Box::new(lhs),
            op,
            right: Box::new(rhs),
        };
    }

    // PART 6
    lhs
}

ざっくり6つのPARTに分かれます。

1. 左辺（left-hand side）にはaなどのatomを代入します。2つ目でbreakになった場合、この値を最後の6つ目で返します。

2. loop部分、breakしない場合、後続のPART 3〜5を繰り返します。

3. peek()して次の演算子を読み、その結合力を受け取ります。もし、結合力を定義していないもの（;など）だったらbreakします。

4. prattの核の部分。左結合力とmin_bpを比べて、lbp < min_bpならbreak、そうでなければ次の5つ目に進みます。min_bpは最初は0で、後述の5つ目で+のときであれば右結合力の4を、*であれば6を渡します。再帰呼び出しされた側では、見つけた演算子の左結合力と渡されたmin_bpの比較で、breakするか次の手順に進むかが決まる！

5. 演算子を消費し、右辺をparse_expr_bp(rbp)で再帰的にパースして、式のASTをlhsに代入する部分。

6. lhsを返す

なので、+ vs * は、以下のような勝敗（？）になります。各オペランドの左右に隣の演算子の結合力を書いて、大きい方がそのオペランドを取り込む、と考えるとわかりやすいです。

a + b * cの場合:

a   +   b   *   c
  3   4
          5   6

bの左右は4(=+のrbp)と5(=*のlbp)。5 > 4で*の勝ち → a + (b * c)

a * b + cの場合:

a   *   b   +   c
  5   6
          3   4

bの左右は6(=*のrbp)と3(=+のlbp)。6 > 3で*の勝ち → (a * b) + c

すごいね！

結合力の流儀

matkladの流儀

matkladでは左右の結合力に差をつけて定義することで結合性を表現していました。+の(3, 4)のように右結合力を大きくすると、a + b + cは左結合で(a + b) + cになります（再帰側のmin_bp = 4に対して次の+の左結合力3が負けてbreakするため）。逆に、三項演算子の(2, 1)のように左結合力を大きくすると右結合になります。一般化すると、

• lbp < rbp → 左結合（普通の算術演算子など）

• lbp > rbp → 右結合（三項演算子、**、代入など）

ただ、この記事を書きながらClaudeに教わったのですが、別の流儀もあるようです。

oxcの流儀

oxcでは、左結合か右結合かを事前に定義しています。

impl Precedence {
    pub fn is_right_associative(self) -> bool {
        matches!(self, Self::Exponentiation | Self::Conditional | Self::Assign)
    }

    pub fn is_left_associative(self) -> bool {
        matches!(
            self,
            Self::Lowest
                | Self::Comma
                | Self::Spread
                | Self::Yield
                | Self::NullishCoalescing
                | Self::LogicalOr
                | Self::LogicalAnd
                | Self::BitwiseOr
                | Self::BitwiseXor
                | Self::BitwiseAnd
                | Self::Equals
                | Self::Compare
                | Self::Shift
                | Self::Add
                | Self::Multiply
                | Self::Prefix
                | Self::Postfix
                | Self::New
                | Self::Call
                | Self::Member
        )
    }
    // ...etc
}

また、優先度はペアではなく、一つの数字で表現されています。

pub enum Precedence {
    Lowest = 0, // matkladでは初期値として 0 を直接代入しているが、oxcは最下位を enum の variant として明示することで型安全にしている
    Comma = 1,
    Spread = 2,
    Yield = 3,
    Assign = 4,
    Conditional = 5,
    NullishCoalescing = 6,
    LogicalOr = 7,
    LogicalAnd = 8,
    BitwiseOr = 9,
    BitwiseXor = 10,
    BitwiseAnd = 11,
    Equals = 12,
    Compare = 13,
    Shift = 14,
    Add = 15,
    Multiply = 16,
    Exponentiation = 17,
    Prefix = 18,
    Postfix = 19,
    New = 20,
    Call = 21,
    Member = 22,
}

上記の左右結合の定義と優先度を組み合わせることで、PART 4のbreakの箇所が以下のようになっています。

let stop = if left_precedence.is_right_associative() {
    left_precedence < min_precedence
} else {
    left_precedence <= min_precedence
};

if stop {
    break;
}

oxcのコメントにある通り、ECMAの仕様から導出した順番として定義したかったようです。

/// Operator Precedence
/// 演算子の優先順位
///
/// The following values are meaningful relative position, not their individual values.
/// 以下の値は、それぞれの数値そのものではなく、相対的な位置関係に意味があります。
///
/// The relative positions are derived from the ECMA Spec by following the grammar bottom up, starting from the "Comma Operator".
/// この相対的な位置関係は、ECMA仕様の文法を「カンマ演算子」を起点にボトムアップで辿ることで導かれています。
///
/// Note: This differs from the operator precedence table
/// <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Operator_Precedence#table>
/// but the relative positions are the same, as both are derived from the ECMA specification.
/// 注: これはMDNの演算子優先順位表とは異なりますが、どちらもECMA仕様から導かれているため、相対的な位置関係は同じです。
///
/// The values are the same as
/// [esbuild](https://github.com/evanw/esbuild/blob/78f89e41d5e8a7088f4820351c6305cc339f8820/internal/js_ast/js_ast.go#L28)
/// この値はesbuildと同じです。

いい話だなあ（？）

まとめ

アルゴリズムとデータ構造に慣れ親しんでない自分からすると、Pratt Parserのようなコードはすぐ意味を見失ってしまうので、記事にしてみました。ついでにoxcの中もちょっとだけ覗けたので良かったですね。有意義な日曜日になりました。

Opus4.8が何でも知ってるので、コンパイラの勉強が捗ります。助かる。コンパイラ周りでまた記事にしたくなったら書こうと思います。それでは。

最終更新: 2026年6月7日

だいたい毎日虚無感に襲われつつ、自分が事前に計画したことをなるべく遂行しようと頑張ったので、GWにやったことを振り返ります。

GWにやったこと

思い出すためにざっくり書き出します。

• NeetCode - Algorithms and Data Structures for Beginners を通しでやる

• Write a Compiler That Understands Types を見つつ実装する

• Simple but Powerful Pratt Parsing を実装する

• acorn の実装を眺める

• Martin Grabmüller - Algorithm W Step by Step を読みつつ実装する

NeetCode - Algorithms and Data Structures for Beginners

やりました。Arrays、Linked Listsあたりから始まって、BSTやグラフの探索、DPなど一通り。もっと難しいトピックはAdvanced Algorithmsのほうに入ってるようですが、NeetCode（というかLeetCode？）のEasyやMediumを解くベースとしては十分な内容でした。

• 動画を見る（優しい英語なので雰囲気で聞き取る）

• 問題を解く

• 半分くらいはわからん、写経する

みたいなサイクル。動画の内容でつまづくことはなかったし、問題も癖がないので学んだことがすぐ活かせてよかったです。回答読むのめんどくさいなーってときも解説動画があって、ぼーっと眺めてれば良いのが助かります。

とはいえ、ちゃんと問題が解けるようになったわけではないので、今後訓練していきたい。復習して3日後くらいに解き直すとよいとClaudeが言っていました。個人的にやりたいのは、その場で解説を読むだけじゃなくて、「読む」→「その場ですぐ白紙に実装できるか再チャレンジ」という流れ。読むだけだと頭に残らない…

想定が25時間と書いてありますが、知ってる概念も多かったので10~15時間くらいでやれたんじゃないかと思います。測ってないけど。

Write a Compiler That Understands Types を見つつ実装する

この講座めっちゃよかった。これのためだけにFrontend Mastersに課金して、見終わったら退会しました。退会するの忘れそうなので。

概要はコンパイラ周りの勉強がしたくてに書いたので割愛しますが、型DBを使ってUnification（単一化）することで、型推論や型チェックができる部分はだいぶ面白かったです。型推論という抽象的なものの実装イメージが湧きました。そういえば、WASMへのCode Generate部分はほぼ記憶ないな。

該当リポジトリには字句解析からCode Generationまで一通り揃ってるので、忘れた頃にまた眺めつつ、自分で実装できるか試したいと思っています。とても貴重な学びでした。

Simple but Powerful Pratt Parsing を実装する

かなり短いコードなのに、パーサーになってすげー！という感動がありました。めっちゃ前に眺めて何も覚えていなかったWrite a JavaScript Parser in Rustにも参考文献として書かれていて、繋がったなーと一人で驚いていました。今回それを理解できたのは素直に嬉しかったです。

メモったスクラップ

acorn の実装を眺める

眺めました。スクラップ。

TokenizerとParser合わせても数千行なので、全然読めました。ただ読むのは退屈で、雑にClaudeに解説してもらって、へえーつって終わりました。

JS syntactic quirksなどに書かれているような曖昧な文法をどうやって対処してるんだろうと思ったのですが、再帰下降だと取り回しがしやすいのか、結構素直に書かれているのは驚きでした。もっと謎のテクニックを使ってるかと思ってましたが、案外読めた。例えば/が除算か正規表現か、(がアロー関数か引数リストか、などなど。

これもいざ自分で実装しろって言われたら全然できなさそうなので、小さいサブセットから始めてやってみたいなあと思っています。やるならTypeScriptのサブセットにしたい気持ちもありますが大変だってClaudeが言ってた。

Martin Grabmüller - Algorithm W Step by Step を読みつつ実装する

Milnerの提案したAlgorithm Wを実装することで、型推論について理解しようという論文です。論文というかほぼコード片が書いてあるだけで、なぜそうなってるかはClaudeに解説してもらわないと何もわかりませんでした。スクラップ。

Write a Compiler That Understands Typesの型推論とほぼ同じようなことをしてるっぽいが、Haskellの抽象度が高いコードで再現されていてすごかったです。モナドトランスフォーマーって何だろうと思ってたので、具体例としてわかりやすかったです。

コードは抽象度が高すぎて雰囲気しかわからなかったのですが、直近で勉強していたことがつながった感じがして面白かったです。Typechecker ZooにはRust実装もあるらしいので、そのうち読みたい。

今後やりたいこと

• TAPL を読む: ClaudeがひたすらTAPLを読めって言ってくるので、そろそろ読もうと思います

• 関数型言語に再入門: 久々に入門し直したくなってきたので、前に物理本で買って売っちゃったラムダノートの『プログラミングHaskell 第2版』を電子版で買い直しました。ちょこちょこ読み進めていきたいです

• NeetCode150: ちまちまやっていきたい。Pythonは本当に楽で助かります。他の言語で勉強しようと思った時は意外と言語機能自体がノイズになって脳みそが回らない、みたいなことが多かったので、何も考えなくて適当に動く感じが気持ちいいです。コンパイラを書くにしても再帰とかバリバリ出てくるし、ビットマスクでの条件分岐の最適化とかacornの中でやってるし、そういうのシュッとわかるとかっこいい

まとめ

最近パソカタできてなかったので、まとまった時間でそれなりにいろいろできて楽しいGWでした。連休が明けても、パソカタ習慣を続けられるように頑張っていきたいです。最終日の明日は何しようかしら。

最終更新: 2026年5月9日

コンパイラってなんかカッコ良さそうだな、というどうでもいいモチベで勉強したいなという気持ちです。何でですかね。やっぱJSエコシステム周辺にいると、TypeScriptやリンターフォーマッターの話題も多いので自然とそういうことに興味が湧いてくるのでしょうか。biomeやoxcなんかにコントリビュートできたらカッコ良さそうですよね。

自分が過去にした近い勉強としては、『コンピュータシステムの理論と実装』を読んだり（第１版で読んだ。そういえば3年前くらいのGWだったかな。）、Crafting Interpretersを読んだり、『型システムのしくみ』を読んだりとか。他にもコンパイラに関する本はたくさん買ってみたけど、まともに読み通せたのはそこらへん。

Crafting Interpretersはやっぱり決定版、という感じがあってtypescriptでtloxを実装したりもした。けど、あんまりバイトコードに興味がわかなくて第II部木の巡回によるインタプリタまでしか読んでない。GCの話題とかもあるらしいので読みたいんだけど、気が向いたらかな。JS界隈では結局、手書きの再帰下降パーサが多いみたいだし、本当に素晴らしい本です。また読み返したい。

GWに向けてやっていたこと

GW時間がありそうなので、それまでにできそうなインプットはしようと思って、会社の行き帰りの電車でUdemyの動画を眺めていた。あと寝る前に『型システムのしくみ』を読み返したりした。

UdemyはDmitry Soshnikovという方の講座がよくて、何本か買ってみた。S式のtoy言語をパースしたり型チェックしたりトランスパイルしたりする。Crafting Interpretersや『型システムのしくみ』あたりをさらっと2時間くらいでやってくれるイメージ。

それ以外で買った講座は、理論を舐めるものが多く、手書きで証明とかする動画もあって、あんまりピンとこずに返金処理した。ちゃんと事前に中身を見た方が良いなと思った。

GW中にやりたいこと

Write a Compiler That Understands Typesを見始めた。Richard FeldmanはZedの人で（そういえば最近v1がリリースされて盛り上がってるな）、Rocという言語も作ってる人らしい。お話がとっても上手で面白い。ElmやRustの講座もあって気になる。Frontend Mastersは初めて課金したけど、書き起こしがちゃんとあるのでGoogle翻訳しながら見れて助かる。講座の終わりの問題も地味に良い。この講座、自分が知りたかったところのど真ん中って感じの内容。大まかには以下のような流れ。サイトで目次も見れるし、コードやスライドはgithubに上がってるので助かる。これ見終わったら課金やめようと思ってたけど、それでも安心かな。

• Introduction: コンパイラの歴史

• Traversing the AST: 構文木をトラバースして、フォーマットする演習があり楽しい

• Bindings & Scope Resolution: 名前解決、名前重複チェックなどの演習がある

• Type Inference: 型推論、型のキーバリューストアをつくって推論できるようにするらしい。いまここ

• Inferring Types: 型推論、関数とか

• Polymorphism & Type Signatures: 多相型、ジェネリクス、型注釈

• Generating WASM: WebAssemblyにCode Generateする、これもいい

ちゃんとトークナイザもパーサーもあるし、普通にリポジトリを読んでるだけでも勉強になりそう。今後も楽しみ。

あとちまちまNeetCodeをやってるので、木とか再帰関数とか出てきてなんか楽しい。コンパイラの良さ。

もうひとつは、Simple but Powerful Pratt Parsingを読んで、自分で実装してみたいなという感じ。雑にトークナイザだけ書いたものがあるので、そこに肉付けしていきたい。

時間があったらCS143眺めたり、TAPLを真面目に読み始めたりしたい。acornやbabelのコードを読んでJSの大変さも知りたいし、とか色々やりたいことはあるけど多分時間が足りない。ぼちぼちやっていきたい。

まとめ

やりたい、というお気持ち表明でしかないけど、GWはマジで何の予定もなくて助かる。ゆったりパソカタをして楽しくなっていきたい。業務でコードを書いてなさすぎるので、趣味でちゃんとコードを書いていきたい。

最終更新: 2026年5月3日

axiosてんやわんや

ことの顛末はAxios CVE-2026-40175: a critical bug that’s… not exploitableに記載されているが、自分はこういう脆弱性についてもアンテナを張っている立場なので、最初重大度が10というとんでもないやつでびっくりした。

脆弱性の中身をみるとプロトタイプ汚染が前提だったり、Xで再現しないというツイートをしている人がいたりで、あれ？と思いつつ、けど重大度が10なので何もしないわけもなくという感じだった。社内の有志により確かに一部の古いバージョンのNodeを除いて再現しないことがわかり、自分も手元で試してまあそうだよね、という感じで一安心でした。

最近axiosは色々あって大変だけどOSSを利用させてもらってるだけなので、メンテナの方には頭が上がりませんな。axiosを新規で採用することはないが、メンテナの方が動いてくれてるうちはレガシーから頑張ってはがさなくてもいいかなと思ってしまう。というか剥がすコストが高すぎて大変。

サプライチェーン攻撃対策を入れたよ

サプライチェーン攻撃から身を守るために最低限設定しておきたいことがすごく良くまとまっていて助かる記事。このブログにもminimumReleaseAgeとかcooldownとか、諸々設定しました。Claudeくんにお願いしたらシュッと設定してくれたので超楽ちん。

去年、Nxのnpmパッケージがサプライチェーン攻撃を受けた件があったときにJxckさんがサプライチェーン攻撃への防御策を書いてくれていたけど、今年は本格的に導入しておかないとまずいぞ、という雰囲気が漂っている。実害が出ているところもありそう。OSSの発展のことを考えるとやめていただきたいですな。

WCAG2.2解説書を読んだ

社内の有識者に解説してもらったのを元に、解説書を一通り読んだ。まだコンポーネント実装やページ実装のプラクティスと有機的に結びついてないので、そこら辺をこれからやっていきたい。自分の理解が追いついていないせいかもしれないけど、世のアクセシビリティ関連の記事や本、WCAGの達成基準とユーザビリティをごちゃ混ぜにして書いてるから逆にわかりにくくなっている気がしてきた。まだスタートラインに立っただけの感想ですが…

『Webアプリケーションアクセシビリティ』やAPGを読み返していきたい、他の企業さんのアクセシビリティガイドラインを読んでいきたい。そんな気持ち。

最近買ったものリスト

半年間くらい私生活がバタバタ（？）していたのが終わったので、しばらく暇で、仕事も穏やかそうなので心機一転色々勉強していきたい。ついでにこのブログにも書いていきたい。

技術関連の本を色々買った。半分は物理で読んだのを買い直した形。型システム入門は思ったよりとっつきやすそうで、そのうちちゃんと読みたいと思いながらパラパラ読んでる。Leanは言語として面白そう。けど数学の概念何もわからん。

• ゼロから始めるLean言語入門

• 型システムのしくみ

• 型システム入門

• ユースケース駆動開発実践ガイド

• 関数型ドメインモデリング

動画講座を色々買った。何度も挫折した自分が、LeetCode150問でデータ構造とアルゴリズムをやっと理解できた話を読んで、確かに本だと挫折し続けてきたから動画にしようかな、と思った。そのことについてちゃっぴーとはなしていたら、コンパイラ周りも動画講座をおすすめされて、ちょうどセールだったのでどかっと買った。買いすぎたかも。けどGWも予定ないし、引きこもってパソカタしたいな。

• NeetCodeのlife time、動画講座見るため

• Building an Interpreter from scratch

• The Complete Course of Compiler Design

• Mastering Compiler Design: Basics to Advanced Techniques

• Programming Language with LLVM

まとめ

今月は脆弱性周りでばたついてた気がする。しばらく何もないことを祈る。

それはそうと、仕事でほぼパソカタしないので、土日とGWでまとめてパソカタしていきたい。勉強したことはブログに書きたい。あと連休はClaude App触ったり、最近のClaude Codeどんな感じかも調べたいな。

仕事で実装タスクがないとどんどんおいていかれている感じがする。別にいいんだけど。AI周りは正直食傷気味なので、自分を強くするムーブをしていきたいですな。

最終更新: 2026年4月19日

Async React

Async Reactの話題をちらほら見ることが多かった。uhyoさんによる記事の影響なのかな。

await UI = await f(await state)の世界観で、より宣言的に考えるという感じっぽい。

なるほどと思いつつ、コンポーネントライブラリやルーター、データフェッチングライブラリなども含めての統合、ということでいまいちピンとくるようなこないような。いままでNext.jsなんかのフレームワークが解決していたところとの境界どうなるんだろう、という気持ちもありつつ、宣言的なのは良いことなので楽しみですな。

業務で複雑なフォーム周りの実装を見ていると、なんだかんだReact-hook-formを使って複雑さと型の部分で苦しんでいたりするので、そこらへんもReact本体でいい感じにしてくれないかな、と思ったりしないこともないです。

自分が雑に眺めたスクラップ

TypeScript 6.0 / 7.0

Announcing TypeScript 6.0の通り、6.0がリリースされました。7.0もあと数ヶ月で出るらしく、そこに向けたオプションの変更や、並行処理するためのお手当などが含まれてる感じですね。あとはes2025周りの取り込み。

悲観的なことを言うと、OxcなんかのRust実装のおかげで、リンター・フォーマッターはめちゃくちゃ高速化されたわけですが、TSがGoによる再実装で10倍速くなるとはいえ、そこがボトルネックになるのは変わらないのかなという気持ち。この変更で何がどれくらい変わるんですかね。その再実装のおかげで型推論周りですごい新機能が実装しやすい、とかあったりするんでしょうか。TSは機能的には十分な気もするのでまあ良いか。

Astro / Solid / Vite / Next.js

Astroは6.0 / 6.1がリリースされ、Solidは2.0betaがリリースされ、Viteは8でRolldownが正式統合され、Next.jsは16.2がリリースされ、と言う感じ。

自分の周りでは、Next.jsは否定的な意見がどんどん増えていて、新規プロダクトはAstro+Reactの組み合わせが多い。Tanstack Startなんかを取り入れている案件もあるくらい。微妙に迷走していたAstroがcloudflareに買われたのはよかった気がする。MPAフレームワークはメディアサイトなどで需要があるし、Next.jsでRSCをゴリゴリに使うにはちょっと腰が重いときに選択肢にしてもすぐにはなくならないな、と言う気持ちになった。Netlifyに買われたGatsbyやShopifyに買われたRemixのことが少し頭をよぎった。

Solidは筋は良さそう（？）なのに流行らないし、相変わらずReact一強感は揺るがない気がしているけど、SolidがAPIを結構変えて新たに思想出してきてるのはいい話な気がする。まあ個人的にはSignalがそんなにいいのか？というのはちょっと疑問だけど、確かにNuxt / Vueの実装を眺めることがあって読んでるとproxyで連動する様は美しいなあと思ったりはした。Nuxtは自分が触った範囲ではメモリ周りで気になることがあったけど、そこはSignalとは関係ないのかな。

Next.jsは目立ったリリースはなくて、AI周りとの統合っていう方向性が多い気がする。PPRやDynamic IO的なものはみんなが求めている方向じゃないんだろうなと言う気がする。leerob氏もCursorに行ってしまった影響も個人的には大きい気がしなくもない。与太話程度に。

後述するadapterの話はいい話だと思うけど、業務ではECSを使ったAWSの構成がほとんどであんまり影響がない。middlewareを復活してもっと自由にしてくれよ、とかエラーハンドリング周りの自由度を上げてくれよ、とかの気持ちがなくはない。コミュニティ的には素晴らしい話だと思う。

そういえばVinextなんてありましたね。

Vite+ / Void / Adapters / OpenNext

Vite+がOSSとしてリリースされた。Void Zero立ち上げ当初、Vite+でマネタイズするという話をチラッと見かけて無理では？と思ってたけどやっぱりそうね。とはいえOxc周りの登場により、急速にフロントエンドツールチェーンが大統一された感じがあり、すごいね。正直vpコマンドを使うかはわからないけど。npmxやe18eなんかの活動もVoid Zero周りの人がやってるのかな？新風吹きまくってて、眺めているだけでも小気味よい。

一方で(V)ite (O)ptimized (I)somorphic (D)eployが発表されてそっちかー、となった。Cloudflareに密結合する形で構成されたホスティングサービス？らしい。Deno deployとかそっちの方向と同じ感じなのかな。けどこれも成功するんだろうか。State of JS 2025のホスティングを眺めていると、Vercelはそれなりに成功してそうって感じだったけど、AWSがやっぱり強いのかなという気持ちでVoidを業務で使うことはないだろうなと遠目に眺めている。今見返すと、NetlifyやCloudflareもシェア結構あるな。

近い話で大きかったのがNext.js Across Platforms: Adapters, OpenNext, and Our Commitmentsだ。もともとAWSでISRしたりするのむずくてVercel一択だったのに対して、NetlifyやOpenNextなんかが頑張った結果が出た感じ。Next.jsはVercelにベンダーロックインされすぎていて批判を浴びてたのもあって動いたって感じかな。RSCになってキャッシュがより複雑になったけどそこらへんにも対応してるんだろうか？何も知らないな。

Cloudflareなんかでいい感じに動くのであればそれはそれで嬉しそう、Amplifyはうーんあんまり使いたくないけど手軽になるなら嬉しそうって感じ。結局Next.jsが今後使われ続けるのかどうかもわからなくなってきてるので、諸々、今後次第かな。OSSという文化の視点では良いことに思えます、たぶん。

Figma MCP

Figma MCPがちょこちょこ使われ始めているのを感じる。それにuse_figmaが生えたのが大きくて、Figma Makeを経由しなくても、デザインとコードを行き来しやすくなった。参考記事はazukiazusa氏のブログあたり。自分は本当に少しだけ触ってみたけど、設定何もしなくてもMCPさえあれば動いてよかった。

個人的にはコードファーストでデザイン不要だ！みたいなことを言ってるのはプロトタイプの世界で、あくまでデザイナーさんの道具はFigmaだろうと思ってるので、結局それは使われる気がしている。ただ、AI周りのツールによってデザイナーさんが楽になるのであれば良いこと。

一方で、Figmaファイルの構造やデザインシステムの重要度が高まっている気がして、MCPを使うにしても整理されてないファイルだと効果は限定的に思える。デザイナーさんとのコミュニケーションをやっていかないといけないなあという気持ち。デザインの質がコーディングの生産性に影響するというのはちょっと難しい問題だ。

デザイナーのためのコンポーネント設計論

デザイナーのためのコンポーネント設計論がめっちゃよかったです。これ無料で読めるの助かる。エンジニアでも陥りがちな間違いや設計方針についてわかりやすく解説されていて助かりますね。今後も繰り返し読みたいと思いました。

デザインファイル自体の重要度も上がっていくこともあり、デザインを作成するフェーズにもっとエンジニアがコミットしていかないといけないと言う気持ちになる。かつアクセシビリティ観点で考えると、デザインや仕様の時点で気をつけたいことが多い。いままでは実装で誤魔化していたような微妙なデザインや仕様がアクセシビリティ観点で問題になることをちょこちょこ見かけるようになりつつある。

アクセシビリティ周り

アクセシビリティ周りは今年一番やりたいことだったのでちまちま進めている。社内の有識者にWCAG2.2の解説書を解説してもらったり、関連記事を読んだりしていてとても勉強になっている。自分も実際にアクセシビリティチェックができるようになっていきたい気持ち。WCAGに準拠するための実装方針やレビュー観点なんかも社内でナレッジを貯めていきたい。

masup9さんがAPG Pattern Exampleを実装されていたり、a11y-specialist-skillsを公開されていたりするので大変助かる。ここら辺も参考にしつつ社内でやらないといけないことを整理していきたい。

ハーネスエンジニアリングとモデルの進歩

最近業務で全然コードを書いていないし、趣味でも何もやる気が起きず映画ばっかり見ているのでAI周りのキャッチアップができていない。ハーネスエンジニアリングがどうの、と言う記事もちらほら見てますけど、hookやpre-commit的な部分でガードしていくのはいいと思いますけど、概念自体はそんなに目新しくないかなという印象で、ちょっと斜に構えて眺めています。

LLMに対するスタンスはnaoyaさんがRebuildで言っていた通り、変に最適化するような工夫をしても半年もすればLLM開発側が吸収してプロダクトに組み込んでしまうし、モデルも乗り換えのハードルがめちゃくちゃ低いのでそんなに焦ってキャッチアップしなくても良いかなと言う気がしています。

唯一今までと違うなーというのは並行開発的なことができる部分な気もするのですが、脳の負荷が高そうなので結局あんまり試せてないですね。業務でやれる機会があったら頑張りたいなあくらいの気持ちで構えています。

OpusもCodexも賢いし、Geminiもそこそこいいし、LLMバブルはどうなっていくんでしょうね。使えなくなるとそれはそれで困るけどって気持ち。CursorのComposer 2.0はKimiベースか何からしいので、そのうちOSSでまともなモデルが出てきて全部無料になったりしないかな。

あとAGI的なものはしばらく出てこなさそうだな、という気持ちも芽生えつつありますが、どうなんでしょうね。現状でも人間よりも賢い気はするのですが、いまのところ知性のようなものは感じない気がしなくもないです。むしろ人間が知性だと思っていたことの大半はただの言語ゲームで、LLMはそのゲームが上手い、というのが真相な気がします。アインシュタインやフォン・ノイマンのような感じにAIはなれるんでしょうか。

まとめ

フロントエンドエコシステム周りも、LLMも、Figmaやその周辺も目まぐるしく進歩はしていて、眺めていて飽きないですね。といっても本当に眺めているだけなので、それはどうなんだという気持ちはしつつ、何もできていないですね。虚無。ブログの盆栽もできてないし、来月は何かしたいです。それではまた。

最終更新: 2026年3月29日

だいたいのブログについてるタグ機能を実装しました。Claude Codeに書いてもらいました。

ちなみに怠惰駆動開発さんがシンプルながらカッコいいブログなので真似させていただきました。

実装要件

以下のような要件で実装しました。

• /tagsでタグ一覧ページ

• /tags/[tag]で各タグのページ（Static Site Generationで生成）

  • /blog?tag=hogeという選択肢もありましたが、Dynamicになるため見送りました

• 記事一覧とタグページを相互にリンク

実装中の課題と気づき

リンク一覧とアクセシビリティ

/blogでタグのリンクを追加すると、キーボード操作でリンクを移動する時にたくさん移動することになって大変だなと思いました。

Next.js blogでも同様の実装ですが、最適な方法は何か気になりました。GitHubのissueページを見ると、listitemで矢印移動が使いやすく実装されていて、なるほどと思いました。

カード UI の入れ子のリンクの問題を解決する Link Area Delegation の提案あたりをちゃんと読めばいいんですが、休日のバイブコーディングなので、また今度。

アクセシビリティを意識しようとするとナニモワカラナイになるのをやめたい。

slug問題と日本語対応

適当に日本語タグで実装してから気がついたのですが、Claude CodeはencodeURIComponentを使って雑にslugにしてました。流石に微妙かなと思ったので、slugifyを入れたのですが、日本語対応してなかったのでtransliterationを入れてみました。

実装してみたら妙に精度いいな、と思ったら勝手にClaude Codeがカスタム辞書を定義してて、騙されるところでした。危ない。

正直transliterationの結果は結構微妙なので、ここは形態素解析していい感じに変換するか、LLM使うかの自前実装したいなと思いました。

Claude Codeのコード品質

やたらasを使ったり、手続きっぽい書き方だったりして微妙なコードでした。Skillsを導入した方がいいかな。気が向いたらやろう。

その他の改善

開発環境の整備

lefthookでpre-push時にformatとbuildを実行することにしてみました。いまはvercelにデプロイしててCIをまともに回してないので代わりです。

コードのリファクタリング

重複するコードを共通化したり細かいリファクタもしました。

そろそろ自動テストが欲しくなってきた気がする。

まとめ

タグ機能の実装を通じて、以下のような気づきがありました。

• アクセシビリティ: リンク一覧のキーボード操作など、UX面での課題

• 国際化対応: 日本語タグのslug生成の難しさ

• コード品質: AI生成コードのレビューの重要性

• 開発体験: lefthookによるローカルCI/CDの整備

タグ機能ひとつとっても、意外と考えることが多いですね。気軽に1時間くらいで実装しようと思ったのですが、なんだかんだ2時間半くらいかかりました。

タグ機能ができたので、雑にエッセイ記事を書いてもいい気がしてきました。

それではまた。

最終更新: 2026年2月11日

発端

自分は普段inoreaderを使って情報収集をしています。そのため、このブログを作ったときも自然とRSSフィードの機能をつけてニヤニヤしていました。

ただ、いくつかの記事を見るうちに、見出しがうまく表示されていないことに気がつきました。原因の詳細は不明なのですが、おそらくHTMLの構造が複雑なので、inoreaderのパーサーが複雑なHTML構造を適切に処理できていないことがわかりました。

以下のようにヘッダータグ内にsvgが含まれる複雑な構造になっています。

<h2 class="flex scroll-m-28 flex-row items-center gap-2" id="tldr">
  <a data-card="" href="#tldr" class="peer">tl;dr</a
  ><svg
    xmlns="http://www.w3.org/2000/svg"
    width="24"
    height="24"
    viewBox="0 0 24 24"
    fill="none"
    stroke="currentColor"
    stroke-width="2"
    stroke-linecap="round"
    stroke-linejoin="round"
    class="lucide lucide-link size-3.5 shrink-0 text-fd-muted-foreground opacity-0 transition-opacity peer-hover:opacity-100"
    aria-hidden="true"
  >
    <path d="M10 13a5 5 0 0 0 7.54.54l3-3a5 5 0 0 0-7.07-7.07l-1.72 1.71"></path>
    <path d="M14 11a5 5 0 0 0-7.54-.54l-3 3a5 5 0 0 0 7.07 7.07l1.71-1.71"></path>
  </svg>
</h2>

修正その①

Claudeと相談した結果、RSS用にクエリパラメータを付与すると良いということなので、その通りに修正しました。実際の修正PR。

// 主要な部分を抜粋
const searchParams = await props.searchParams;

const isRSSView = searchParams?.view === "rss";

const components = isRSSView
  ? {
      h1: "h1",
      h2: "h2",
      h3: "h3",
      h4: "h4",
      h5: "h5",
      h6: "h6",
    }
  : undefined;

// クエリパラメータがある場合は、`getMDXComponents`のヘッダータグを上書き
<Mdx components={getMDXComponents(components)} />;

修正その②

その後にふとした拍子に/blog/[slug]がSSGされていないことに気がつきました。searchParamsを使ってるから当然なのですが、前の修正時には気づかなかったですね。

Route (app)
┌ ○ /
├ ○ /_not-found
├ ○ /about
├ ƒ /api/search
├ ○ /blog
├ ƒ /blog/[slug]
├ ○ /blog/rss.xml
├ ● /docs/[[...slug]]
│ ├ /docs
│ └ /docs/test
├ ○ /icon.png
└ ● /og/blog/[...slug]
  ├ /og/blog/2025-12-30-my-blog/image.webp
  ├ /og/blog/2025-12-31-recap/image.webp
  ├ /og/blog/2026-01-11-og-image/image.webp
  └ [+2 more paths]


○  (Static)   prerendered as static content
●  (SSG)      prerendered as static HTML (uses generateStaticParams)
ƒ  (Dynamic)  server-rendered on demand

なので、クエリパラメータをやめて、/blog/[slug]/rssというパスパラメータにすることにしました。

ビルド時にちゃんとSSGされるようになったので問題ないと思います。

Route (app)
┌ ○ /
├ ○ /_not-found
├ ○ /about
├ ƒ /api/search
├ ○ /blog
├ ● /blog/[slug]
│ ├ /blog/2025-12-30-my-blog
│ ├ /blog/2025-12-31-recap
│ ├ /blog/2026-01-11-og-image
│ └ [+2 more paths]
├ ● /blog/[slug]/rss
│ ├ /blog/2025-12-30-my-blog/rss
│ ├ /blog/2025-12-31-recap/rss
│ ├ /blog/2026-01-11-og-image/rss
│ └ [+2 more paths]
├ ○ /blog/rss.xml
├ ● /docs/[[...slug]]
│ ├ /docs
│ └ /docs/test
├ ○ /icon.png
└ ● /og/blog/[...slug]
  ├ /og/blog/2025-12-30-my-blog/image.webp
  ├ /og/blog/2025-12-31-recap/image.webp
  ├ /og/blog/2026-01-11-og-image/image.webp
  └ [+2 more paths]


○  (Static)   prerendered as static content
●  (SSG)      prerendered as static HTML (uses generateStaticParams)
ƒ  (Dynamic)  server-rendered on demand

まとめ

RSSフィードの対応をしました。

App routerをちゃんと使ったことないので、こういう勘所がないということに気がつきました。

意図しない変更を避けるために、ビルド結果のsnapshotの差分を見たほうがいいかも？とも思いました。こういう気づきがあるので個人開発はいいですね。

最終更新: 2026年2月2日

tl;dr

• エディタ: VSCode + Claude Code / Copilot / Cursor

• ターミナル: ghostty + zsh + Oh My ZSH!

• 言語: TypeScript メイン、Python 少々

• ブラウザ: Arc

• 物理: M3 Air / HHKB雪 / Keychron Q1

エディタ/IDE

個人用はVSCode+Claude CodeのVSCode拡張。

仕事ではVSCode+Copilot Chat（基本Claude Sonnet 4.5、たまにOpus）か、Cursorのどちらかを使ってます。コードを書く仕事はあんまりなくて、コードを読むために使ってる。

全部Vim拡張を入れていて、雰囲気でそれっぽいキーバインドを使ってます。

ターミナル

Hyperを使っていたけどTahoeにしてから起動がもっさりするようになったので、ghosttyに乗り換えました。いまのところサクサクで楽しい。設定はスクラップに書きました。

シェルはzshで、雑にOh My ZSH!を入れている。 テーマはpowerlevel10k/powerlevel10k。

zshプラグインは(git fzf-tab zsh-syntax-highlighting zsh-bat mise)らしい。zsh-batなんて入れてたっけ。

ghqは必須でかなり使う、fzfと組み合わせで使ってます。

dotfilesはやりたいと思いつつ、PC買い直したときはまっさらから何入れよっかなーを考えるのが好きなので使ってないです。chezmoiがいいんだっけ？

Figの補完に頼り切ってたのでAmazon Qになって使えなくなったのがマジでつらかった。ただ、最近VSCodeのデフォルトターミナルに補完が来たのでなんとかなるようになりました。

AIツール

個人で課金してるのはClaude Codeのみ。毎月$20を献金してます。それ以外は課金してない。

CopilotもCursorも使ってるけど、Claude Codeが一番馴染むかも。

ブラウザ

メインブラウザはいまだにArc。

Chromeに戻ろうとしたり、Firefoxにしてみたり、Vivaldi触ったりしたけどいまだにArcから離れられない。

Chromeに垂直タブも画面分割もきたけど、スペース機能が欲しいな。あとCmd+TでランチャーっぽくURL打ったり履歴探したりするのが地味に嬉しいんだけど、これもChromeに入らないかな。

プログラミング言語・ランタイム

TypeScript。最近競プロの勉強をしたくてちょこちょこPython。RustやHaskellやりたいけどなあ。あとLeanとか気になりはする。けどやっぱやりたいのはHaskellなんだろうな。型システムと関数型プログラミングに興味があるので。

開発補助ツール

Gitクライアントは使わず、コマンドを打ってる。

最近はpnpm / miseがあれば事足りる感じがありますね。時々bunを触ってみるくらい。nodeでtsが動くし、denoを触る機会がない。

あとRaycast、全然使いこなせてないのをなんとかしたい。

物理環境

個人はMacbook M3 Airで、会社はまだM1 Pro。周りがM3 Proを使い始めていて羨ましいけど、全然M1 Proで事足りる。

キーボードは会社がKeychron Q1 Knobを相変わらず、家はHHKB雪。Keyball 44は机の肥やしになってる。

最近の変化

そんなに変化ない。仕事でCLIのAIツールが使えれば、neovimあたりに乗り換えて遊びたいんだけど使えないので、結局慣れたIDEを使っている。

カスタムするのめんどくさいのでデフォルトで使いたい派は、おとなしく便利なIDEを使えば良いのかもしれない。

まとめ

我ながら面白みがない。もっと生産性を上げるために探索するべきなのか、と思うこともあるけどとにかくめんどくさがりなので、誰かに教えてもらわないとツールが増えない。

miseはいいかも、と思いつつも使い方をすぐ忘れるのでまだ馴染んでない。voltaが楽すぎた節はある。

AI周りは変化が早いので、こういう記録は面白いのかもしれない。来年が楽しみ！

最終更新: 2026年1月22日

Takumi

Fumadocsのドキュメントに出てきたので、今回はTakumiというライブラリを使ってOG画像を生成してみました。

OG画像生成

OG画像生成といえば、vercelのsatoriと、それをベースにした"next/og"の機能だと思います。自分も過去に動的OG画像生成をしたことがあります。

ただ、satoriのCSSのサポート状況を眺めながら実装するのは地味に骨が折れた記憶があります。いまはどうなんでしょう。

Takumiの特徴

特徴は公式ドキュメントやリポジトリに記載されてるので詳細は割愛しますが、自分が良さそうだなと思ったのは下記です。

• Rustで実装されているため高速（ファイル数が増えるとビルド時間が長くなりがちな場合に有効）

• Tailwind CSS ファースト

実装

Fumadocsのドキュメント通りに実装するだけです。見た目はTakumiのtemplateからコピペしてちょっと整えました。

fontの読み込みについてもドキュメントに書かれていて、今回はNoto Sans JPを指定してます。ただフォントファイルが9.3MBあるため、サブセット化をしたいと思っています。

// import文は割愛

export async function GET(_req: Request, { params }: RouteContext<"/og/blog/[...slug]">) {
  const { slug } = await params;
  const page = blog.getPage(slug.slice(0, -1));
  if (!page) notFound();

  // Load Noto Sans JP font
  const fontPath = path.join(process.cwd(), "public/fonts/NotoSansJP.ttf");
  const fontData = await fs.readFile(fontPath);

  // Load background image directly from filesystem
  const backgroundImagePath = path.join(process.cwd(), "public/og-background-image.webp");
  const backgroundImageData = await fs.readFile(backgroundImagePath);
  const backgroundImageBase64 = `data:image/webp;base64,${backgroundImageData.toString("base64")}`;

  // Format date for display
  const formattedDate = page.data.date
    ? new Date(page.data.date).toLocaleDateString("ja-JP", {
        year: "numeric",
        month: "long",
        day: "numeric",
      })
    : "";

  return new ImageResponse(
    <BlogPost
      title={page.data.title}
      author={page.data.author}
      date={formattedDate}
      // category={""} TODO: カテゴリ実装したら追加
      avatar={"https://avatars.githubusercontent.com/u/69495387"}
      backgroundImage={`url(${backgroundImageBase64})`}
    />,
    {
      width: 1200,
      height: 630,
      format: "webp",
      fonts: [
        {
          name: "Noto Sans JP",
          data: fontData,
          weight: 400,
          style: "normal",
        },
      ],
    },
  );
}

完成

実装で特に苦労することもなく、こんな感じになりました。満足です。

2026/01/17追記

backgroundImageを使っていて、かつ記事数が4つを超えるとビルドが終わらなくなる現象が発生した。 原因の追究は後回しにして、いったんbackgroundImageを使うのをやめた。 Persistent Imagesを適用しようとしたが失敗した。Next.jsの静的ビルド時にfs.readFileでpublicディレクトリを読み込む際のパス解決に問題があるのかもしれない。 最小構成で再現するか調べてみたい。

最終更新: 2026年1月17日

今年の総括としては、かなり楽しく過ごせました。けど体調崩しすぎ😔

仕事

2025年から役割が変わり、案件のリーダーをやりながら、コードを書くというよりはマネジメントやもう少し上のレイヤーから課題を検知して火消しをして回るような仕事をしていました。自分で必要なことを考えて、必要なだけコミットするという働き方ができて個人的には楽しいです。来年もこの調子でやっていきたいと思います。

フロントエンドのチームを強くするにはどうしたらいいか、といったことをぼんやりと考えていて、JSer.infoを読む会を開催したり、自動テストに関する意識調査などをしたりしていました。とはいえ、自分より技術的に優れた若手がたくさんいるので、実は何もしなくてもいいのではないかと思ったり思わなかったりして日々悩み中です。

たぶん自分に自信がないだけなので、精進してまいりたいですね。

また、仕事で特筆すべきはセキュリティ周りでしょうか。Next.jsのmiddlewareに関する脆弱性や、年末にはRSCの特大の脆弱性が発生して社内でバタバタしていました。サプライチェーンアタックやフィッシングなど、今年はかなりセキュリティを意識するタイミングが多く、普段からアップデートできる環境を整えたいと思いつつ、案件によって経緯があるため難しいなと感じていました。来年の課題ですね。

カンファレンス

今年はカンファレンスに参加してみようと思っていて、それを実現できた年でした。オフラインで参加したのは以下のイベントです。普段インターネットで見る凄腕エンジニアたちを間近で見られて、かつ懇親会などではお話もさせていただき、とても楽しかったです。みんな優しくて良い人ばかり。

• フロントエンドチョットデキル 2025

• TSKaigi 2025

• Vue Fes Japan 2025

• TSKaigi Hokuriku 2025

TSKaigi Hokuriku 2025

TSKaigi Hokuriku 2025では、「tsc --init の設計思想の変化とその背景を追う - "教育的"アプローチから実用性重視への転換」で初めて登壇させていただきました。とても緊張しましたが、会社のメンバー大勢で行っていたのでなんとかなった気がします。

uhyoさんの基調講演で恐れ多くも言及いただいたのですが、すみません、そのプロパティについては触れていないです...と震えていました（笑）。

また、カンファレンス終わりにインフルに罹ってしまい、40℃の熱が出たのもいい思い出です（？）

Zennスクラップ

ここでOSSコントリビュートについて書けると良いのですが、まだそういったことはしたことがないので、来年は頑張りたいです。代わりに、興味を持った記事や技術のドキュメントを眺めてはZennスクラップに雑にメモをするということをやっていました。

Zenn 2025 Recapは以下の感じだったそうです。

• 487,694字の執筆

• 89のスクラップ

• 0ページレビュー

• 43 Likes

正直、ドキュメントを眺めるだけでは意味がないなと思ったので来年はあまりやらないと思います。ライブラリなら実際に使ってみたり、コードを読み書きしないと記憶に何も残らないなと感じたので...。

内容は覚えていないのですが、なんとなく面白かった気がするものを列挙してみます。

ECMAScript の仕様を読むためのブログを読む

• V8のブログシリーズで、ECMAの仕様書を読むための基礎知識が解説されているものを読みました

• カバー文法などJSの奥深さがわかって面白かった気がしますが、忘れてしまいました

ウェブアクセシビリティ基盤委員会の資料を眺める

• WAICのサイトや関連資料を一通り眺めました

• 何をしたら良いかはふんわりわかりましたが、WCAG 2.0は読んでいないので来年頑張りたいですね

• 最近アクセシビリティが要件に含まれることが多くなってきたので、かなり切実です

JSON Parsing from Scratch in Haskell を読む

• HaskellでJSONパーサーを書くチュートリアルです

• 結構短くて良い内容でしたが、ApplicativeやAlternativeやMonadが出てきました

• その後、LLMの力を借りてTypeScriptで再実装したりしました

Quiet UIを学ぶ

• カスタム要素で構築されたUIライブラリ

• リッチなUIも多く、実装を読んで勉強になりました

• 残念ながら、現在は公開されていないようです

CSS Wrapped 2025を眺める

• CSSの新機能をまとめたものを眺めました

• Interopが始まってからどんどん新しい機能が増えていて、楽しいですね

• 実際の案件で使う前に自分で触ってみないと発想として出てこないので、来年はそこら辺を素振りしていきたいですね

最近興味があること

React/Next.jsの動向は追っていますが、どちらかというとアクセシビリティやHTML/CSSの最新動向が気になってきています。JavaScriptを使わずにできることが増えるのは良いことですね。実装の際にパッと思いつかないことが多いので、素振りをして自分の引き出しに入れておきたいと思いました。

oxlintやoxfmtも気になっているので来年は何かできたら良いなと思っています。そういえばECMAの仕様を読むためのブログは、Oxcのドキュメントで見つけて読もうと思っていたのですが忘れていました。

人生

今年はやたらと体調を崩した年でした。手元のメモで数えてみたら40日以上は体調不良だったようです。去年から13kg減量に成功したので、それの影響もあるのかと思いつつ、たぶんお酒のせいです。お酒を飲むと風邪をひきます。免疫力を上げていきたい今日この頃です。

年始の1月はほぼ体調が悪く、その後は8月末のアメリカ旅行中〜旅行後のひどい風邪と、11月末のインフルがきつかったですね。

実は今も体調を崩してしまって、帰省の予定をキャンセルして引きこもっています。来年は本当になんとかしたいですね...

また、ライフステージを進めるために課金したりしているので、来年はそこら辺で成果が出ると嬉しいのですが、将来のことを思うとモヤモヤと思考が巡ってしまうのでした。明日はどっちだ。

まとめ

日々楽しく生活できているのですが、もっとコンフォートゾーンを出てOSSに挑戦してみたり、体調を安定させて旅行に行っても元気でいられる体を作りたいなと思っているところです。自分は何かに挑戦するのが苦手で、引きこもってぼーっとYouTubeを見たり本を読んだりしてしまうので、そこから抜け出すように2026年は頑張っていきたいです。

もう2026年になってしまうので、ここら辺で切り上げます。

良いお年を！

最終更新: 2025年12月31日

こんにちは、tsuka-ryuと申します。2025年も残すところあと2日となりました。早いものですね。今年はどんな一年だったでしょうか。

シンプルではありますが、この度、個人ブログを作ってみました。これまでも何度も作ろうと試みてきたのですが、追加したい機能に対して手が追いつかず、Vibe Codingで勢いよく作っても、レビューをしないでマージすると途中で破綻したり、満足いくものが出来ませんでした。

ですが、今回は欲しかった機能は一揃いあるし、かっちょいいシェーダーライブラリも導入してそれっぽくなったので満足してます。今後ぼちぼちブログを書いたり、このブログを盆栽代わりにしていけたら良いなと思っています。

どうぞよろしくお願い致します。

FumadocsとPaper shaders

Fumadocs

このサイトはFumadocsというドキュメンテーションフレームワークをベースにNext.jsで作成しています。作者のFuma Nama氏による美しいデザイン、複数のフレームワークを選択できる柔軟さ、カスタマイズ性の高さ、簡単に追加できる機能の豊富さが特徴です。

あとClerk TOCもかっこよくて、つい見出しを増やしたくなりますね。

ドキュメントもしっかりしているので車輪の再発明を回避しつつ、やりたいことをすぐに実現できました。このブログ自体もデザインがない状態から、2、3日ほどで作成しました。本当にありがたいことですね。

Paper shaders

Paper shadersはFumadocs公式のHero部分で使われていたもので、ultra fast zero-dependency shaders for your designs らしいです。最高ですね。

サイト上で数値をいじいじして、生成されたコンポーネントを貼り付けて最終調整をしたらいい感じになってかなり気に入っています。

ホスティング・インフラ

ホスティングは楽なので一旦Vercelにしていますが、そのうちAWSに載せ替えて、ドメインも取得したいところです。

取り上げたいトピック

個人ブログなので好きなことについてひっそり書きたいです。おおまかに以下のようなトピックが書けたらと思います。

フロントエンドエコシステム関連

• React/Next.js/TypeScriptを中心に、今年注目されたVoid Zero周り、linterやformatterなど

• おもしろいライブラリがあったら遊ぶとか

• HTML/CSS/JSのWeb標準周りの動向

• 記事やpodcastの感想もちらしの裏的に書けたら良いかも

マネージメント、組織論

• 効果的にマネジメントしたいという気持ちなので、その辺りの雑感

• どうやって良い組織を作っていくか

• 読んだ本の感想

その他

• FigmaやLLM関連

• アルゴリズムとデータ構造を勉強したいのでそこらへん

• HaskellやRustにも挑戦したい（願望）

今後の抱負

2024年頃までは業務でコードを書く機会がそれなりにあったのですが、今年に入ってからはあまりコードを書かなくなってきたので若干危機感がありました。2026年もおそらく似たような状態になることが予想されます。

いくつかのカンファレンスに初めて参加したり、登壇させていただいたり、刺激はかなりもらえたんですけどね。

一方で、自分の技術力はまだまだ足りないと感じることが多く、もっとコードを書いてたくさんのことを知りたいと思っています。なので、今後はこのサイトをいじったり、記事を書いたりしてアウトプットする機会を増やしていきたいと考えています。

月一くらいで記事が書けたらいいなあ、くらいな感じでしょうか。 三日坊主がちな人間なのですぐに諦めるかもしれませんが、半年に一回でもいいから書きたいなと思っています。

普段RSSでたくさんの方の個人ブログを読んでいて、なんだか羨ましく感じていたので、自分も似たようなことをしたいだけなんですけどね。

それでは、良いお年を。

最終更新: 2025年12月30日