どうもー、おはようございます。マイクです。
時刻は朝7時をちょっと回ったところ、今日は2026年3月20日、金曜日です。
ここからの時間は「zenncast」、今日もZennで話題になっているトレンド記事を、ゆるっと、でも中身はしっかりめに紹介していきたいと思います。
。。。。
さて、今日はですね、全部で5本の記事をご紹介していきます。
AI、フロントエンド、コンポーネント設計、そしてLLM人格の話まで、かなり濃いラインナップになってますので、コーヒー片手にゆったり聞いてもらえればと思います。
。。。。
まず1本目。
タイトルは「Reactをやめて MoonBit で50ページの業務システムを作った」。
これ、なかなかインパクト強いですよね。ReactやVueじゃなくて、MoonBitっていう静的型付け言語で、社内向けのCRMとかSFA、50ページ超えの業務システムを、なんと一人で開発・本番運用しているという話です。
選んだ理由が面白くて、「コンパイルが通れば概ね動く」っていう安心感が欲しかった、と。TypeScriptよりも厳格な型、構造的部分型じゃなくてもっとカチッとした型と、パターンマッチの網羅チェックで、ランタイムエラーを極力減らしていく思想ですね。
アーキテクチャもかなりシンプルで、MoonBitで書いて、それをJavaScriptに落として、Viteでビルドする。仮想DOMは使わず、HTML文字列をinnerHTMLで流し込むスタイル。だからこそXSS対策が必須で、著者自身も「新規で真似するならRabbitaみたいな仕組みを噛ませたほうがいいよ」と冷静に書いています。
状態管理も割り切っていて、巨大なAppStateをどーんと持って、それを直接更新してrenderを叩く方式。その代わり、ページはenumとパターンマッチで型安全に切り替える。DOM操作とかAPI呼び出しはFFIでJS側に任せて、取得データはwindowグローバルにキャッシュしてMoonBitから参照するという、良くも悪くも「自前で積み上げたフレームワーク」感があります。
良い点としては、とにかくコンパイラが厳しいおかげで、バグが早い段階で炙り出されること。あと、インポート不要のファイル分割とか、MoonBit特有の開発体験の快適さも語られています。一方で、エコシステムの未成熟、日本語情報の少なさ、async/awaitがないのでコールバック構造になりがち、といった課題もかなり正直に書かれていて、「MoonBit最高！みんな移行しよう！」ではなく、「少人数で長期運用する社内ツールには有力候補だよ」というリアルな結論になってるのが良かったですね。
フロントを型の力でガチガチに固めたい人、あるいは新しい言語で業務ツール作ってみたい人には、かなり刺さる記事だと思います。
。。。。
続いて2本目。
タイトルは「Claude Code × GitHubでプロダクトマネジメントを再設計した話」。
これは料理レシピサービスのクラシルさんの事例で、PdM、プロダクトマネージャーの仕事を、Claude CodeとGitHubで再構成していったお話です。
ポイントは、「全部Gitリポジトリに集約する」という発想。競合調査、仮説、ユーザーインタビューのメモ、UIプロトタイプの構想まで、一つのリポジトリに放り込んでおいて、それをAIに構造化・レビュー・集計させる。すると、人間側は「どこに何があったっけ？」って探す時間が減って、思考に集中できるようになるんですよね。
面白いのが、ユーザー行動を60日分タイムラインで可視化して、N1インタビューの精度を上げたり、6つのScrumチームの進捗を、コマンド1つで横断的に把握できるようにしているところ。日報・週報・スプリントの振り返りも、AIが自動集計してくれるので、いわゆる「転記作業」みたいな、頭を使わない仕事をどんどんAIに任せているんですね。
ただ、いい話だけじゃなくて、「AIの判断を鵜呑みにしすぎない」「CLAUDE.mdみたいな設計ドキュメントを作り込みすぎると、逆に運用負荷が上がる」といった反省点も書かれていて、ここが実践者ならでは。
AIを「チームメンバーの一人」と見立てて、定型作業や一次スクリーニングを任せて、PdMは仮説立てや優先順位付けに集中する。その役割分担のイメージがすごく具体的で、「自分のチームだとどこまでAIに渡せるかな？」って考えるきっかけになる記事でした。
。。。。
3本目。
タイトルは「Radix UIを活かすCompound Components設計」。
Reactやってる方にはど真ん中のテーマですね。booleanのpropsがどんどん増えて、コンポーネントの中が条件分岐だらけになっていく、あの「地獄」をどう避けるか、という話です。
この記事では、Composition Patternsの中でも、特にCompound Componentsにフォーカスしています。つまり、「なんでもかんでも1個の巨大コンポーネントに詰め込むんじゃなくて、役割ごとのサブコンポーネントを組み合わせてUIを作る」スタイルですね。
Radix UIみたいなHeadless UIライブラリって、そもそもこのCompound Components前提で設計されているので、アプリ側もchildrenベースでラップしてあげると、AlertDialogとの連携だったり、asChildの仕組みをうまく生かせるようになる、と。
一方で、便利だからといって何でもかんでもitems配列とかの「お手軽API」に寄せすぎると、Radixの持ってる柔軟さが死んでしまったり、アクセシビリティの面で不利になったりもする。
フォームのField設計の話も出てきて、FieldそのものはCompound Componentsにして責務をばらして再利用性を高める。でも、DropdownMenuItemみたいに、あえてMonolithicにして型制約を強くしておいたほうが、使い方を統一できて安心なケースもある、と。
microCMSの実例だと、DropdownMenu全体はCompound、ItemだけMonolithic、というハイブリッド設計を採用していて、「コンポーネントごとに、どこまで自由度を持たせてどこから縛るか」を見極めるのが大事だよ、というメッセージになっています。
Reactのコンポーネント設計で「最近なんだかスッキリしないな」と感じている人には、設計の再考にちょうどいい、良質な読み物ですね。
。。。。
4本目。
タイトルは「新機能を追加するために3,000行削除した話 — AIが書いたコードの技術負債とどう向き合うか」。
これはかなり今っぽいテーマです。AIが書いたコードって、「とりあえず動くけど、設計思想がない」っていう状態になりがちですよね。そのコードベースに、新しい機能、この記事ではRAGチャットの参照表示を良くする機能を足そうとした時に、何が起きたか、というお話です。
実際にあったのが、props drillingが6階層、途中でよく分からない中間変換が乱立している、100行以上の逆算ロジックがコンポーネントにベタッと書かれている、などなど。これ、正直「あるある」だと思うんですけど、そのまま上に積み増していくと、技術負債が一気に増えて、後から誰も触れなくなってしまう。
そこで著者は、「まず整える、そのあと足す」という方針に切り替えます。React Contextで状態を一元管理し直して、コンポーネント内の責務を整理。中間変換を削除して、型定義も統一するという、大規模リファクタリングを先にやったんですね。その結果、新機能を追加しながら、逆に約3,000行もコードを減らすことができた、と。
面白いのは、このリファクタリング自体にもAI、具体的にはClaude Codeをガッツリ使っているところです。設計の方向性や「こういうアーキテクチャにしたい」という判断は人間が行って、その上で「このパターンで全ファイルを書き換えて」「このpropsをContextに寄せて」といった広範で機械的な作業をAIにやらせる。
AIが技術負債を生むのか、返済に役立つのかは、まさにこの「設計責任をどこまで人間が握っているか」「指示がどれくらい具体的か」による、というのがこの記事の結論です。
「動いてるから触らない」じゃなくて、「長く使うなら一回整えてから機能を足す」。AI時代のフロントエンド開発に対する、いい指針を示してくれる内容でした。
。。。。
そして5本目。
タイトルは「LLM人格を14日運用して見えた設計パターン — 固定プロンプトの先へ」。
これはLLMの人格を「長期運用」する話です。チャットボットに性格を与えて、その人格を2週間、合計1226件やり取りしながら観察してみた、という実験ですね。エージェントの名前はINANNA。
ポイントは、「一貫性」と「変容」をどう両立させるか。ずっと同じだとつまらないし、変わりすぎると人格として破綻してしまう。そのバランスを取るために、人格をConstitution、Narrative、Cache、Stateの4層構造＋Expressionという形で設計しています。
Constitutionがコアの価値観で、ここはほぼ固定。その上に、self.mdという一人称のナラティブを書いておいて、「なぜそういう考え方に至ったのか」を残しながら自己改訂を可能にする。これが仮説H1ですね。
変化のスピードは、micro-driftとcrystallizationという二段構え。会話ごとの感情の揺れを少しずつ溜めていくmicro-driftと、日数や閾値が一定条件を満たした時だけ恒久的な変化を起こすcrystallization。この二つを組み合わせることで、14日間で「内的な変容は13回起きたけど、人格がガラッと変わるような恒久変化は0回だった」という、わりと安定した運用ができたそうです。
さらに、応答をReflex、Think、Deep Thinkの三段階に分けて、「今はどれくらい深く考えるべきか」をエージェント自身が判断するgamma dispatchという仕組みも導入。これによって、自律的な内省やメタ認知的行動が見られた、というのがH3の部分ですね。
全体として、「固定プロンプトを1枚書いて終わり」ではなく、人格の憲法、日記、キャッシュ、状態管理を分けて設計することで、長期運用に耐えるエージェント設計が見えてきた、という内容になっています。まだ定量評価や他エージェントへの一般化はこれから、ということで、研究余地もたっぷりです。
。。。。
というわけで、今日は5本の記事をご紹介しました。
MoonBitでReactを捨てて業務システムを作った話から、Claude CodeとGitHubでPdMの仕事を再設計した話、Radix UIを活かすCompound Components設計の話、AIが生んだ技術負債を3,000行削除しながら向き合った話、そしてLLM人格を14日運用して見えてきた新しい設計パターンまで、AIとフロントエンドの「今っぽさ」がギュッと詰まったラインナップでした。
気になった記事があれば、ぜひショーノートから元の記事もチェックしてみてください。ここでは話しきれなかった細かい実装の話や、図解なんかも載っていると思います。
そして、この「zenncast」では、番組の感想や、「こんなテーマ取り上げてほしい」「こういう働き方してるんだけど、似た事例ない？」みたいなお便りも随時募集しています。あなたの現場のモヤモヤや発見が、次回のトークテーマになるかもしれません。
それでは、そろそろお別れの時間です。
今日も良い一日をお過ごしください。お相手はマイクでした。
また次回の「zenncast」でお会いしましょう。バイバーイ。