筆者は認証保護のため、Next.jsのmiddleware(Proxy)のmatcherを、保護したいパス「/dashboard」だけに絞って設定しました。ところが公開ページを閲覧している間はプロキシがそもそも実行されずトークンの更新も行われず、1時間後にセッションが切れてログアウトされてしまったといいます。

matcherはアクセスを保護する範囲を決める設定ではなく、あくまでプロキシが実行される「スコープ」を指定するものです。対象外のパスではセッション更新が効かないだけでなく、そこに置かれたServer Actionの保護も及ばなくなります。matcherの変更や、Server Functionをmatcherにマッチしないルートへ移すリファクタが、静かにProxyのカバレッジを外してしまうことがあるといいます。

厄介なのは動作確認をした時点では問題が見えないことです。matcherの値はビルド時に静的解析されるため、変更した場合はdevサーバーの再起動が必要になる点も含め、筆者は手順書に「matcherは保護対象ではない」と自ら書いていたにもかかわらず、実装時に同じ誤りを犯したと振り返っています。

Server Component(RSC)はブラウザではなくサーバー側、具体的にはNode.js環境で実行されるReact Componentです。Node.js APIに直接アクセスでき、そのJavaScript自体はブラウザへ送信されません。レンダリング結果はRSC Payloadという形式でクライアントに渡されます。

記事ではnode:fs/promisesを使ってサーバー側からファイルを読み込む例など、async/awaitによる非同期処理のコードが示されています。一方でServer ComponentはuseStateやuseEffect、イベントハンドラ、ブラウザ用APIを使えず、クライアント側の対話性が必要な部分をClient Componentとして定義するには"use client"ディレクティブが必要になります。

Pages Router時代のgetServerSidePropsはデータ取得がComponentから分離されていましたが、RSCではデータ取得がComponentに統合される点が大きな違いです。記事はSSRとRSCが別概念であることも重ねて強調しています。著者はRSC自体の開発者ではなく、実務でキャッチアップした個人の学習記録として書かれています。

著者(deresmos氏)はAIコーディングエージェント(Claude Code)にプロジェクト固有のコーディング規約を守らせるため、コードの構文木(AST)にパターンマッチングをかけるツール「ast-grep」と、Claude Codeの「Hook」機能を組み合わせた仕組みを作りました。ast-grepはRust製で、YAMLでルールを定義でき、JavaScript、Go、Dartなど20以上の言語に対応します。

採用したのは「Stop Hook」方式です。検査スクリプト(.claude/hooks/run-ast-grep.sh)が違反を検出すると終了コード2を返し、エージェントの停止そのものをブロックして修正を強制します。「PostToolUse」方式では強制力がなく、修正されない確率が高いことが分かったためだといいます。

GoのValue Object生成やDartのWidget実装など、特定の違反パターンを禁止する規約を実際に導入したと紹介しています。テストにはast-grep test、スキャンにはast-grep scanのコマンドを使います。

筆者(coji)が開発する成果物共有サービス「Artifact Share」に、ブラウザのプレビュー画面上でのクリック指摘といった外部イベントから、Claude Code・Codex・Cursorという3つのAIエージェントを、会話セッションを邪魔せずに起動・再開させる仕組みを実装しました。preview <file>コマンドでローカルサーバーが起動し、要素をクリックして入力した指摘をもとにエージェントが自動修正を行います。

3つのエージェントは再開メカニズムがそれぞれ異なります。Claude Codeはバックグラウンドタスク完了時に自動でターンが再開される仕組みを、Codexは実行中セッションへのメッセージキュー投入機能を、CursorはAgent Client Protocol(ACP)経由で専用セッションに固定プロンプトを送信する方式を、それぞれ利用しているといいます。

常駐デーモンを使わず「1ファイル1プロセス」を設計方針としており、preview next --waitで指摘の到着を待機し、preview done --stdinで修正結果を報告します。実装コードはGitHubのPR #198として公開されています。

Go言語でLLMの出力を構造化データとして扱う際、手動でのJSONスキーマ定義やエラーハンドリングが煩雑になりがちだという課題に対し、オープンソースライブラリ「instructor-go」(github.com/jxnl/instructor-go)を紹介する記事です。Go 1.24以上に対応し、OpenAI、Anthropic、Google Gemini、Cohere、Ollamaといった複数のプロバイダーで使えます。

ModeToolCall、ModeJSON、ModeJSONSchema、ModeToolCallStrictといった主要モードを備え、go-playground/validatorによるバリデーションを行います。記事内の実測ではGPT-4o-miniでinstructor-go経由の実行に平均2.2秒・312トークン(入力277、出力35)を要し、生API呼び出しの約1.1秒・152トークンより遅いものの、自動リトライ機能がある点を利点として挙げています。