昨今AI Agentの進化は凄まじく、ある程度AI Agent任せでもそれなりに良いUIが実装できるようになってきました。一方UX[1]を細かく作り込むには、AI Agentは明確な指示を必要とします。特にローディング体験[2]は細かい指示がなくともAI Agentがある程度よしなに実装してくれますが、筆者の理想とするような作り込みまでしてくれることはありません。これはおそらくモデルやツールの性能的な問題ではなく、プロンプトやルールを通じて行う目標設定の問題が大きいと筆者は考えています。AI Agentは実行に特化したツールであるため、明確な目標設定は人間側の責務であり、今後もしばらくは人間側の責任が大きい部分だと思われます。 この記事ではユーザーストレスを低減するローディング体験をテーマに、筆者が普段意識している原則を4つ紹介します。この記事を通して、より良いローディング体験についての学

はじめに 2026年4月17日（米時間金曜）、Anthropicが Claude Design を research preview として発表 自然言語でプロトタイプ・スライド・モックアップ・LPを作れる、Claude Opus 4.7ベースの新機能 競合は Figma Make / v0 / Lovable / Bolt / Google Stitch / Gamma / Canva 発表前後で Figma -6% / Wix -4.7% / Adobe -2.7% / GoDaddy -3% と市場は結構まじめに反応 「Webデザイナー・フロントエンドの仕事が丸ごと消える」のではなく、「初稿を作る工程」と「単純なUI実装」から先に溶ける、というのが現時点での実際的な読み 普段はClaude CodeやAIツール周りの記事を書くことが多いのですが、今回は界隈としてインパクトが大きかった

はじめに LLMの進化とともに、私たちの開発手法も大きく変わってきた。かつて重要視されたプロンプトエンジニアリングは、今やコンテキストエンジニアリングへと進化を遂げている。 プロンプトの工夫より、文脈の設計。 いま成果を分けるのは「何を渡し、何を渡さないか」ではないだろうか。 最近ではkaraage0703さんがコンテキストエンジニアリングの理論的な整理をまとめた優れた記事を公開している。 本記事では、これとは少し違った角度から、ClaudeCodeでの実践という視点でコンテキストエンジニアリングを掘り下げてみたい。 近年は推論力の向上で、プロンプト技巧の比重は下がった。一方で与える文脈の設計（コンテキストE）は重要度が上がった——本稿はその実務設計を、サブエージェントで具体化する。 プロンプトエンジニアリング：その誕生と役割 LLMの特性が生んだ必然 プロンプトエンジニアリングは、初期の

バイブコーディングの効率化でGit worktreeが話題になっていたけど、コマンドの実行や管理が大変そうだったので、まずは効率化するツールを作りたいと思いました。いつもならシェルスクリプトとかエイリアスで済ませるところですが、バイブコーディングでOSSとして作ってみたら面白そうと思い、この1週間集中して開発しました。 結果、Git worktreeの管理を効率化するCLIツールをリリースすることができました。途中からはドッグフーディングで自らの生産性も向上させて、Claude Codeを20万円分以上使いましたがCLIツールとしてかなりクオリティの高いものを短期間で作ることができました。 作ったツール PhantomというCLIツールを作りました。Git worktreeを簡単に管理できるツールで、docker execみたいにワークツリーの中でコマンドを実行する機能があったり、tmux

そもそもDOMとは？ 仮想DOMについて知るためには、まずDOMについて知っておく必要があります。 以下の動画で、DOMについて100秒で解説しているので、そもそもDOMをよく知らないなぁという人はぜひ確認してみてください！ 仮想DOMとは？ では、本題です。 仮想DOMとは、UIの "仮想" 的な表現をメモリー上に保持して、実際のDOMと同期させるというプログラミング上の概念のことです。 仮想 DOM (virtual DOM; VDOM) は、インメモリに保持された想像上のまたは「仮想の」UI 表現が、ReactDOM のようなライブラリによって「実際の」DOM と同期されるというプログラミング上の概念です reactjs ...と言っても、これだけだとちょっと難しいですよね。 なので、仮想DOMについて解説する前に、まずはDOM操作とレンダリングの関係について先に解説します。 DOM

メモを残す習慣 以前、@gorou_178さんが「1日1ファイル、「調べたこと」「やったこと」を日報として残す」という記事を公開していた。 この記事の中に以下のようなくだりがある。 そこでふと思い出したのが元同僚のメモの取り方。 毎日1ファイル作成して、そのファイルにその日にやったこと（事細かくやった作業、実行したコマンドなども）をメモしていた。メモは年単位で残っておりとても驚いたことを覚えている。 この、「元同僚」というのはきっと私のことである。 私はメモを取ることが結構と好きな方で、メモを残すことがわりと習慣化している。 例を挙げると、普段からこういったことをやっている。 Google Keepに「Podcastに出演してほしいゲスト候補」、「勉強会・カンファレンスの登壇履歴」、「来月購入予定の日用品・雑貨」、「自宅周辺の行ったことないラーメン屋」、「読みたい・気になったマンガ本」とい

先日、location-stateというパッケージについての記事を公開しました。 履歴に基づいて状態を復元できるReact系ライブラリで、現在はNext.jsを重点的にサポートしています。このライブラリの構成はcoreとなる部分とNext.js依存な部分を切り離しscoped packageとし、内部構成もこれに合わせていわゆるmonorepo構成で開発を行なっています。 @location-state/core: coreとなる部分 @location-state/next: Next.js依存な部分 この記事では、monorepoのパッケージ開発を快適にするために実際に採用したツールを紹介していきます。本稿で紹介するツールは以下になります。 pnpm turborepo tsup changesets Renovate pnpm まずパッケージマネージャーですが、個人的に最近はpnpm

この記事は最近リリースしたlocation-stateというライブラリの紹介記事です。 モチベーション Reactのstate管理は、様々な分類が可能です。筆者が過去に書いた記事「スコープとライフタイムで考えるReact State再考」では、stateの分類は大きく以下2つの観点で分類ができると述べました。 スコープによる分類 ライフタイム（=stateの生存期間）による分類 詳しく知りたい方はこの記事を読んでいただきたいのですが、今でもstate管理というと多くの場合スコープによる分類の話が多く、ライフタイムによる分類の話はあまり聞かない気がします。 なぜライフタイム観点が重要か ライフタイムを意識せずに実装した場合に発生するのが、遷移時に状態が破棄され復元されない、つまりブラウザバックでstateが壊れるという問題です。この問題については以下の記事で、Vercelの社長が2014年に

ReactはじめSPAのStateは大きく2種類、Local State・Global Stateの2種類でおおよそのStateの分類が可能であると考えていました。これに対し会社の先輩から意見をもらって、以下2点に気づきました。 Global Stateには大きく、Client StateとServer Stateの2つがある Stateにはライフタイム（生存期間）が存在し、Client Stateにはスコープ的Globalと時間的Globalの2つが含まれている これらを意識すると、自分はStateの実装を結構感覚的にやってしまっていたなと気づいたので、Stateの分類について改めてまとめてみようと思います。Reactで何かしらのStateを実装する時に、本稿の分類が実装の参考になれば幸いです。 スコープによるStateの分類 まずこれまで自分が認識してたスコープにおけるStateの分類

Romeとは 現代のJavascript開発には多くのツールチェーンが必要とされます。Babel,webpack,Jest,ESLint,Prettier,Typescriptなどを組み合わせて開発することが多く、さらにこれらの一部代替選としてesbuild,SWC,Viteなどのツールチェーンの選択肢が存在し、選択肢の多さやその組み合わせの複雑さに苦い思いをしたことがある方も少なくないのではないと思います。 こうした中で、新たに開発が進められているツールチェーン、Romeをご存知でしょうか？ Romeは先に挙げたように複数のツールチェーンを役割ごとに組み合わせて使うのではなく、1つのツールチェーンでこれら全ての役割を担ってしまおうという壮大な計画を持つツールチェーンです。 Romeは2020/03にFacebookより発表されました。現在は法人化され、yarnやBabelの生みの親である

組み込み端末のアプリケーションに Electron を採用し開発・運用を行っています。 継続的な機能追加やトラブルサポートを行いながら 3 年が経過したので、Electron を採用した経緯や結果を経験を交えながら共有したいと思います。 組み込み案件自体が初めてでしたのでその話も入っています。 約 700 台ほど導入されており、なかなか大きな案件での採用と思いますので参考になれば幸いです。 ※Electron の基本的な説明は割愛します。 システムについて 一般的に「受付精算機」などと呼ばれ、店頭に何台か並べて設置して自動で受付・精算を行うシステムです。 ホテルの受付端末のイメージです。ハード的にはセルフレジにも近いです。 筐体自体は他社が用意し、弊社はその上に載せる GUI アプリケーションのみを担当しました。 機能 主な機能として 来店受付・整理券発行 予約チェックイン チェックアウト

【追記】↓100秒テックでイラスト投稿してます！よかったら見てってください！ はじめに 以前書いた記事「Webページがブラウザに表示されるまでに何が起こるのか？」で ブラウザレンダリングについて詳細に知りたいという意見をいただいたので、調べてまとめてみました。 全体図 レンダリングの大まかな流れです。 HTMLのダウンロード サーバから送られてきたHTMLをダウンロードします。 HTMLの解析 サーバから送られてきたHTMLファイルは、「0」と「1」でできたデータになっています。 ブラウザは、サーバから受け取ったデータをそのままHTMLとして解釈することはできないので、自分で扱うことができる形、つまりDOMに変換する必要があります。この作業を 解析 ( Parse ) と言います。 HTMLをダウンロードしたら、すぐにこの解析作業に入ります。作業は以下のようなステップになります。 Byte

この記事は Build your own React を翻訳したものです。 Reactを1から書き直していきます。 実際のReactコードのアーキテクチャに従いますが、最適化機能と必須ではない機能は今回は実装しません。 Step 1: createElement関数 Step 2: render関数 Step 3: 並列モード Step 4: ファイバー Step 5: Render Phase と Commit Phase Step 6: 差分検出 Step 7: 関数コンポーネント Step 8: Hooks Step 0 復習 最初にいくつかの基本的な概念を確認しましょう。 React、JSX、およびDOM要素がどのように機能するかをすでに理解している場合は、この章はスキップしても構いません。 今回は、次のわずか3行のコードをReactアプリの例として使用します。 const ele

Introduction Rustを学び始めたのは多分今年の3月くらい。 なぜ急にRustに興味を持ったのかは後述しますが、半年ほどRustをいじくりまわしてみて、まだまだ学び途中でもRustの素晴らしさを語らずにはいられず、記事を書くことにしました。 Rustは「Cの正当な後継」なんてよく言われますが、WebエンジニアからみてもRustは本当に素晴らしいってことが少しでも伝わればいいなと思います。 RustとTypescript 「なぜRustとTypescript？」って思う方は多いと思うので、順に話していきたいと思います。 2020年のフロントエンドの流行 まず2020年今日時点のフロントエンドについて雑に書くと React・Vueが主流 Typescriptがデファクト、babelなどでトランスパイルは言わずもがな サーバーサイドもNodeで書くならTypescript Jest、