こんにちは。技術広報グループのBambooこと竹中（X： @shell_in_bamboo ）です。 2026年10月に、社内のアクセシビリティ啓発イベント「アクセシビリティースプーン」の第2回が開催されました。主催は、Accessibility Advocateとして社内にアクセシビリティの文化を作る仕事をしている辻さん（著者ページ： 辻勝利 、X： @KatsutoshiTsuji ）です。今回のテーマは「私とアクセシビリティ」。6人の社員が、それぞれ自分とアクセシビリティの間にいまどれくらいの距離があるのかを話しました。私も参加者の1人として、オンラインで当日のセッションを聞いていました。 内容が盛りだくさんなので、前編と後編の2回に分けてお届けします。前編となる今回は、セッション1〜3の3本を紹介します。 アクセシビリティースプーンとは アクセシビリティースプーンは、辻さんが2026年2月に始めた社内の勉強会です。 名前には、「難しそうなこと」から「めんどくさそうなこと」まで、ティースプーンでゆっくりかき混ぜながら、みんなで一緒に味わっていける会にしたい、という思いが込められています。 第1回は導入編として、室町オフィスとオンラインで開催しました。第2回となる今回は、拠点を問わず参加できるよう完全オンライン形式で試してみました。 今回はKINTOテクノロジーズだけではなく、グループ会社のKINTOやWoven by Toyotaからもご参加いただきました。 「詳しい人の発表会」にはしない 今回のアクセシビリティースプーンで辻さんが決めていたのは、アクセシビリティに詳しい人の発表を集めた会にはしない、ということでした。 「アクセシビリティの話をしてほしい」と声をかけると、「自分はまだ詳しくないので」と一歩引かれてしまうことがよくあるそうです。しかし、アクセシビリティは専門家だけのものではありません。調べ始めたばかりの人、日々の業務で向き合っている人、ガイドラインに長く関わってきた人、家族が直面している課題を身近で見てきた人。それぞれの「距離」から見えている景色を持ち寄って、聞いている人にも「自分ならどのあたりだろう」と考えるきっかけにしてほしい、とのことでした。 セッションの紹介（前編：セッション1〜3） セッション1：アクセシビリティ初心者がアクセシビリティについて調べてみた（太田さん） トップバッターは、アクセシビリティについて「全然知らない」立場から話してくれた太田さんです。 きっかけは、社外のイベントで「アクセシビリティのKTCさんですか」と声をかけられたことだったそうです。それまで太田さんにとってのアクセシビリティは、iPhoneの設定画面にある「文字サイズの変更」や「背面タップ」のような便利機能という認識でした。 太田さんがJIS X 8341-1やW3Cの資料で調べてみると、アクセシビリティは「年齢・障害・利用環境の違いにかかわらず、誰もが使える度合い」のことでした。小さな文字が見えにくい、けがで片手しか使えない、騒がしくて音が聞こえない、回線が遅い。どれも、使える人の範囲をどこまで広げられるかという話です。 そこから本業であるセキュリティの軸で調べてみると、意外な接点が見えてきます。CAPTCHAや多要素認証は、ロボットによる攻撃を防ぐうえで重要な仕組みです。一方で、CAPTCHAは目の見えない人には難しく、制限時間内にコードを入力する多要素認証も、使いづらいと感じる人は少なくありません。 警告やエラーの画面も、専門用語ばかりだと何をすればよいか伝わりません。障害のある人も、慌てている人も、こうした仕組みの前で止まってしまう、という指摘でした。 セキュリティの世界にも「誰もその仕組みから締め出されないようにする」という考え方があり、当事者からのフィードバックを受けてパスキーなどの改善が重ねられているそうです。 使いにくい仕組みは抜け道を生むので、セキュリティの基準も使いやすさを求めています。米国の認証ガイドラインNIST SP 800-63Bは、パスワード欄への貼り付けを許可し、パスワード管理ツールを使えるようにすることを挙げています。WCAG 2.2の達成基準3.3.8も、記憶や書き写しだけに頼る認証を避けるよう求めています。覚えなくてよく、書き写さなくてよいパスキーは、安全で使いやすい仕組みです。安全と使いやすさは、片方を取れば片方を捨てる関係ではなかった、というのが太田さんの発見でした。 「自分の本業の中にも、調べてみると意外とアクセシビリティに関わる部分があった。皆さんの業務にもきっとあるはず」という締めのお言葉が最高でした！「全然知らない」とか本当か！？(笑)というぐらい良い発表でした。ご自身の専門領域と結び付けるとこんなにも為になるんだな～と。 セッション2：テックブログのアクセシビリティ改善活動（谷さん） 2本目は、フロントエンドエンジニアで技術広報も兼務している谷さん（著者ページ： high-g 、X： @high_g_engineer ）による、このテックブログのアクセシビリティ改善の話です。 谷さんは、2026年6月時点のテックブログをスクリーンリーダーで読み上げた音声を流してくれました。適切な見出しがないため見出しジャンプで読み進められない。著者情報が何度も読み上げられ、なかなか記事にたどり着けない。サイドバーの検索ボックスの存在にも気づけない。谷さんいわく「あんまり読ませる気がないテックブログ」でした。 改修後は、記事一覧と各記事に適切な見出しが付き、辞書を索引で引くような感覚で記事を探せるようになりました。著者情報ではなく記事タイトルが読み上げられるので、余計な読み上げも減っています。 見出しから記事ページにすぐ移れるようになり、サイドバーの検索ボックスにも気づけるようになっています。 この改善には、辻さんもスクリーンリーダーの利用者として関わっています。谷さんが最初に、WCAGを参照させてAIに対応させたものを見せたところ、辻さんの答えは「いくつか気になるところがありますね。」でした。そこから、辻さんがどんな情報を必要としていて、どう操作しているのかを一緒に確かめながら進め、「まずは見出しの整理からやればいい」というところにたどり着いたそうです。 谷さんは、仕様や書籍を網羅的に理解して基準を満たすことを目的にする前に、目の前の当事者を想像し、その人に向けて情報を整理するところから始めるのが大事だと話していました。そして、自分でもスクリーンリーダーを日常的に立ち上げ、当事者に「情報量は適切ですか」と聞くことを繰り返す。この往復こそが、今の形につながったのだと思います。 「AIで手軽にものづくりができる今だからこそ、これまで以上にユーザーに寄り添った優しいものづくりをしていこう」というメッセージで締めくくられました。もうね、ちょっと泣きそうでしたよね。AI時代にエンジニアはどうなるべきか、という大きな問いの答えを見た気がしましたよ（大げさ）。こうやって、アクセシビリティの領域においても当たり前に「一緒に作る」ということが行われるようにしていきたいと思いました。 セッション3：アクセシビリティガイドラインの『色々』と読み方 —— WCAG・ISO・JISからHIG・MDまで（守谷さん） 3本目は、Engineering Officeで辻さんと同じチームの守谷さん（著者ページ： emim 、X： @emim ）です。守谷さんは、 ウェブアクセシビリティ基盤委員会（WAIC） の元委員でもあります。 1つ前の谷さんの発表（基準に準拠することばかり追い求めるのではなく実際のユーザーの声を聴く大切さ）とは真逆？の「基準を知ることの重要性」を発表してくださいました。これは意見の食い違いから乱闘になるか！？（ならんよ） こういった多様な意見が聞けるのがたまらんと思いながら聴き入った私です。 前半は、W3CのWCAGがISO/IEC 40500となり、それをJIS X 8341-3が取り込むという関係の整理でした。WCAG 2.0は2008年に勧告され、JISになったのは2016年です。この時差のため、日本で参照されているJISは、スマートフォン関連や認知関連の項目が追加されたWCAG 2.1・2.2の内容をまだ含んでいません。最新の内容を知りたいときは WCAG 2.2（WAICの日本語訳） を見てほしい、というのが守谷さんからのメッセージでした。 達成基準の数は、WCAG 2.0の61項目から、2.1で17項目、2.2で9項目増えています。2.2では1項目が廃止されました。 後半は「WCAGはなぜ難しいのか」と「どう読めばよいのか」です。 翻訳の表記ルール による言い回しの難しさや、HTMLに限らずPDFなどにも当てはまるよう抽象的に書かれていることが、難しさの理由として挙げられました。そのうえで、各達成基準からリンクされている解説書（Understanding）を使って、次の3ステップで読み解く方法が紹介されました。 意図 を読み、なぜその基準があるのかを理解する 事例 を読み、どうなっていれば達成できるのかを知る テクニック を読み、どう実装すればよいのかを知る ネイティブアプリのエンジニアに向けては、Appleの Human Interface Guidelines （HIG）や Material Design （MD）とWCAGの関係も紹介されました。まずプラットフォームに依存しないWCAGで基礎を押さえ、Dynamic TypeやVoiceOverのようなプラットフォーム固有のことはHIGやMDで確認する、という使い分けです。 HIGもMDも早い段階からアクセシビリティの考え方を取り入れていて、どちらもWCAGに基づいていることを明記しています。 AIでガイドラインを読むことについては、「アクセシビリティは特に、世間で流行っている実装方法を安易に答えがち」と注意を促し、WCAGやHIG、MDをきちんと参照させる聞き方を勧めていました。英語の原文がそもそも難しく、日本語になるとさらに難しくなる。それでも、解説書を味方にすれば一歩ずつ読み進められる、と背中を押してくれるセッションでした。 守谷さんは本当に知見が深く、アクセシビリティ素人の私には学ぶことしかないのですが、今回も神回でした。きっちりと基本を押さえつつ、AIを使ったり応用したりしていきたいですね。 守谷さんのスライドで紹介されていた参考情報も載せておきます。 デザイナーが難解なガイドライン（WCAG）を乗り越える方法（提案） デザイナー✕エンジニアでhow to learn WCAG チャットで生まれた対話 セッションの最中から、Teamsのチャットにはたくさんの質問や感想が書き込まれました。時間の都合で口頭の質疑応答はできませんでしたが、チャットではセッション同士をつなぐような対話が自然に生まれていました。前編の3本に関するものを紹介します。 「セキュリティとアクセシビリティは、数年の差で似た流れをたどっている」という見方 WCAGを読むべきかについて、「読むに越したことはない。ただ、挫折しては本末転倒なので、当事者に寄り添った対応から始めて、そのあと仕様書で理解を深めるのがよい」という意見 正確に伝えようとすると言葉が難しくなり、抽象度を上げると正確さが失われる、というガイドラインのジレンマ セッションを聞いている最中にチャットで盛り上がれるのは、オンラインでやる魅力の1つだと感じました。 前編を振り返って 三者三様の発表内容をご紹介しました。 アクセシビリティ初心者でも、自身の専門領域と紐づけて調べると色々な発見があること 基準を満たすことだけに傾倒せず、ユーザーの声を聴くこと ガイドラインの読み方や活用の仕方 私自身、このような学びを得て、とても美味しい紅茶を飲んで満たされたような気分。。まさにアクセシビリティースプーン！ と、うまいこと会のタイトルに紐づけたところで後編に続きます！後編では、 台湾で開催されたアクセシビリティのカンファレンスで見たものとは Agent時代のアクセシビリティ 色覚多様性の話 という3本のセッションをご紹介します。お楽しみに！

はじめに プロダクト開発支援課フロントエンド推進チームの安彦です。 プロダクト開発支援課は2026年10月に発足したばかりの組織です。私たちのチームが顧客としているのは、プロダクトの先にいるエンドユーザーだけではありません。社内でプロダクトを作っている開発者もまた、私たちが価値を届けるべき顧客として捉えています。 現在、社内の複数のプロダクトで共通して使えるデザインシステム「 Libero（リベロ） 」を構築しています。 ラクスには、用途もブランドも異なる複数のプロダクトが存在します。開発者がそれぞれの現場で迷わず安全にLiberoを使えるようにするためには、最初に「 Liberoが何を持ち、何を持たないか 」を決める必要がありました。 この記事では、Liberoの設計において決めたことを、次の問いに沿ってお伝えします。 はじめに 複数プロダクト向けに、何を持たないか 見た目と振る舞いを、何を根拠に決めたか 画像だけでは表現しきれない領域 UI品質を担保する「5つの層」 値を根拠から逆算し、CIで品質を担保する プロダクトからLiberoへ、何を渡せるか デザインガイドラインと接点の関係 AIが組んだUIの品質を、誰が担保するか おわりに ※Liberoのコードやドキュメントを社外公開する予定はありません。設計のケーススタディとしてこの記事がお役に立てば嬉しいです。 複数プロダクト向けに、何を持たないか Liberoは、プロダクトのドメインやブランドを持ちません。 ドメインの知識 *1 はプロダクトごとに異なり、変わり続けるので、Liberoが追従し続けることは困難です。また、ブランド *2 についても、複数ある中でのどれか1つの表現をLiberoの既定値にしてしまうと、他のプロダクトにとっては不要なスタイルを打ち消す余計な作業が発生してしまいます。 「全社横断のデザインガイドラインを先に作らないのか？」と疑問を持たれるかもしれませんが、Liberoではそのアプローチをとりませんでした。各プロダクトでガイドラインの整備状況や目指す表現が異なるからです。 そのためLiberoは、あとからどのガイドラインが注入されても受け入れられる基盤を先に作りました。APIにはドメインの言葉を持ち込まず、提供するコンポーネントの既定の見た目や振る舞いにも、特定のブランド表現を入れていません。 このように持たないものを明確に決めた上で、デザイントークンを起点に、44のコンポーネントを提供しています。 Liberoのコンポーネントの既定の見た目。特定のプロダクトのブランド表現を持たない 見た目と振る舞いを、何を根拠に決めたか 既定にドメインもブランドも入れない分、見た目と振る舞いの値には別の根拠が必要です。Liberoでは、エンジニアが画面を組むときに毎回決めているものを整理することから始めました。 画像だけでは表現しきれない領域 画面を組むとき、画像という静的な形式だけでは、どうしても表現しきれない領域があります。 状態: hover、押している途中、送信中、エラー、空データ、長い文字列、文字サイズの拡大 操作: キーボードだけで操作できるか、スクリーンリーダーに何が読み上げられるか 更新: 使っているライブラリを更新したあとの見た目 これらが仕様として明記されない場合、実装するフロントエンドエンジニアの個人の判断に委ねられます。機能開発のスピードが優先される現場では、UIの細かな品質までを受け入れ基準に定める余裕がないことも少なくありません。個人の判断に委ねられ、気づかれなかった実装は、次に誰かがそのコードに触れるまで残り続けます。 UI品質を担保する「5つの層」 そこでLiberoは、個人の判断に委ねられていたUI品質を、層に分けて整理しました。 UIは単一の面ではなく、土台から順に依存しながら積み上がる多層的な構造をしています。最下層にはブラウザやOS、支援技術といった変えられない実行環境があり、最上層にはプロダクト固有の判断が乗ります。 Liberoは、この両者の間に位置する5つの層を自身の責務と定めました。層ごとに何を満たせば品質が守られるかを定義し、すべてのコンポーネントに適用しています。 セマンティックHTML: 用途に合ったHTML要素とroleで組み立てる アクセシビリティ: キーボードで操作でき、支援技術に名前・役割・状態を伝える 状態表現: hover・focus・disabled・処理中などの状態を見た目で示す テーマ: 色や形をトークンとして持ち、値をまとめて差し替えられる フレームワーク対応: UIフレームワーク・CSSライブラリの更新に追従する 最上層のプロダクト固有の判断（情報設計、画面の構成、文言、操作後の処理）は、引き続き各プロダクトが持ちます。Liberoが間にある5つの層を引き受けるのは、プロダクト側がこのドメイン固有の判断に集中できるようにするためです。 値を根拠から逆算し、CIで品質を担保する Liberoが引き受ける層の品質は、感覚ではなく明確な根拠と自動化によって担保しています。具体的には、次の2つの観点を満たすように既定の振る舞いを決めています。 Web標準: ブラウザ標準の振る舞いを上書きせず、 Baseline のWidely availableに含まれる機能で作る アクセシビリティ: WCAG 2.2 AA の達成基準を満たす この2つの観点はCIで検査しています。Web標準はWidely availableを外れる機能を使っていないかをlintで、アクセシビリティは違反がないかを axe-core で確かめます。 見た目の値も同様に根拠から逆算します。色はコントラスト比から候補を絞り、角丸は要素の高さとの比から決定します。値そのものではなく導き方を決めているため、将来値を変える必要が出た際も、同じ導き方で安全に決め直すことができます。 プロダクトからLiberoへ、何を渡せるか Liberoは既定値のままでも、UI基盤として品質が保たれ、そのまま問題なく機能するように作られています。 しかし、実際のプロダクトに組み込む現場からは「プロダクト固有のブランドカラーやスタイルをコンポーネントに適用したい」といった需要が生まれます。そこでLiberoでは、影響範囲をコントロール可能な状態に保ちながら、各プロダクトのドメインやブランドを安全に受け入れる経路として、明示的に以下の3つのみを接点として開放しています。 props: コンポーネントに、variant・状態・表示する文言を値として渡す theme: 色や形の役割（primaryなど）に、ブランド表現の値を渡す events: ユーザー操作の発生をプロダクト側へ通知し、その後の処理を委ねる この3つは、変えても影響範囲が予測できる経路です。 開く範囲を絞っている最大の理由は、前節で述べた品質と振る舞いの一貫性を無秩序に壊さないためです。また、依存の向きをプロダクトからLiberoへの一方向に制限することで、ライブラリ更新時の予期せぬレイアウト崩れを防ぎ、保守の負担をLibero内で完結させる目的もあります。 デザインガイドラインと接点の関係 各プロダクトのブランド表現は、横断のデザインガイドラインとして先に定めてからコンポーネントに落とす流れが一般的ですが、冒頭で触れたとおり、Liberoはこの順で作っていません。 すでにガイドラインが存在するプロダクトは、その固有の表現をthemeの値として差し替えます。例えばprimaryの役割に値を渡せば、ボタンやリンクなど同じ役割の要素が、まとめてブランドカラーに置き換わります。一方、ガイドラインが整備中のプロダクトは、まずLiberoの既定に乗り、固有の表現が増えてきたタイミングでガイドラインとして育てていくことができます。特定のブランド表現を持たないプレーンな基盤にしたのは、この両方の状況を単一の接点で受け止めるためです。 プロダクトは値を渡し、どの部分にどの役割を当てるかはLiberoが固定する もし提供している接点の範囲で既定から外れる値を入れる場合や、接点だけでは表現できない要件が出た場合は、Web標準やアクセシビリティとの整合性が崩れるリスクが生じます。その際は、Liberoの利用を強制するのではなく、なぜこの制約になっているのかという根拠を共有し、トレードオフを一緒に評価した上でプロダクト側に判断を委ねる対話を重視しています。 基準を下回る上書きをしたくなったときの判断の分岐 AIが組んだUIの品質を、誰が担保するか ここまでは、フロントエンドエンジニアが画面を組む前提で書いてきました。しかし現在では、AIによってUIの生成が容易になり、フロントエンドエンジニア以外がコードに手を入れたり、プロトタイプを作ったりする場面が増えています。生成された画面は一見すると見た目が整っています。しかし、focusの制御が漏れていないか、選択状態が色だけで示されていないか、disabledのときに何が起きるかといった見えない層の品質まで、生成段階で担保できているケースは多くありません。ここで見過ごされたものは、直す工数として現れます。 画面を作る費用が下がった分、コードを保守し続ける負担の比重は上がります。だからこそ、コードを書く人が増えるAI時代において接点を絞る意味がより大きくなります。 Liberoの提供する3つの接点（props・theme・events）だけを通って組まれた画面であれば、人が書いてもAIが書いても、その下にある5つの層は、同じ品質の水準が保たれます。非エンジニアがAIで作ったプロトタイプであっても、接点だけで組まれていれば、フロントエンドエンジニアは画面の構成や文言の確認に集中し、安心してそのまま実装に進めることができるのです。 おわりに デザインシステムやガイドラインのような共通の基盤は、揃えるための強制力を持ちます。しかし一方で、その強制力がプロダクトの開発スピードを落としたり、何を自分たちで決めてよいのか迷わせてしまう場面もあります。私自身も、前身となるデザインシステムの実装と利用の両方に携わる中で、同じ難しさを感じていました。このもどかしい経験を振り返ってみると、問題は強制力そのものではなく、「なぜその形なのか」「どこまで変えてよいのか」が辿れず、現場の判断が止まってしまうことでした。Liberoの設計には、当時の自分たち自身の反省が活かされています。 UIは作って終わりではなく、技術の変遷に伴って求められる品質の水準も変わり続けます。Liberoが責務の境界を明確にし、根拠を開示しているのは、強制力を最小限に留めつつ、各プロダクトがこの変化へ追従しやすくするための基盤でもあるからです。 判断をプロダクト側に残す分、各プロダクトとの対話は欠かせません。導入の検討段階から使い始めたあとまで、プロダクトで見つかる課題を持ち寄ってもらい、一緒に決めていきます。Liberoだけでは完成しないからこそ、プロダクトと育てていくシステムでありたいと思っています。 複数のプロダクトに向けて基盤を作ろうとしている方はもちろん、日々の開発でエンジニアが毎回決めているものに名前を付け、その責務を捉え直すきっかけになれば嬉しいです。 *1 : 特有のデータ構造、業務フロー、文言など *2 : テーマカラーやタイポグラフィ

AI開発時代のWeb技術スタックを考えてみた   PSSLの佐々木です。 これまで業務アプリは、深く考えずに「とりあえずReact + FastAPI」のようなSPA+APIの構成で実装してきました。 ただ最近はClaude CodeなどのAIがコードの大半を書いてくれます。Reactを選んでいた理由は「JSを書くのがつらい」でしたが、AIが書くなら技術者側の理由で技術選定をするのではなく、作るものに応じた最適なものを選定すべきだろうと思いました。 この記事では、AI開発時代のWeb技術スタックについて海外・国内の記事やベンチマークを調べ、「どんな時に何を選ぶべきか」を私の意見も含めて整理します。 ReactやNextを選択していた理由 まずは振り返りです。昔はDjangoやPlay、Springなどのサーバー側レンダリング + jQueryで画面を作っていましたが、これがとにかくつらかったです。 サーバー側レンダリング + jQueryのつらさ 状態がDOMの中にしかない（「いま何が選択されているか」をDOMから読む） HTMLとJSの結びつきがセレクタ頼み（ $('.btn') が別の画面の同名クラスにも当たる） Ajaxで差し替えた要素にイベントが付かない、または二重に付く 変数も関数もグローバルで、どのページで何が動くか追えない 初期表示はテンプレート、更新後はJSの文字列組み立て、という二重実装 型もモジュールもなく、壊れたことに実行するまで気づけない 「予期せぬところでJSが発火する」の正体はこれです。つらかったのは書く量ではなく、 構造を与える仕組みがなかった からですね。 Reactが解決してくれたこと 宣言的UI（状態を変えれば表示が追従する） コンポーネントという境界（影響範囲が読める） 初期表示と更新が同じコード モジュールとTypeScriptの型 豊富なUIライブラリ jQueryのつらさへの直接の回答だったので、移行したのは合理的だったと思います。 React / Next + API分離のつらさ ただ、Reactに移行してすべて解決したかというとそうでもなく、 サーバーとクライアントを分断した代償 が生まれました。 真実が2か所になる（本物はDBなのに、クライアントがコピーを持つ） サーバーがブラウザに指示できない（リダイレクト、認証切れ、完了後の遷移をクライアントで自前実装） あらゆる通信に「読み込み中・エラー・空」の3状態がつく（画面が一瞬白くなる、ちらつく） バリデーション、型、権限チェックをフロントとバックの両方に持つ useEffectの依存配列、サーバー/クライアントコンポーネントの境界、キャッシュなどフレームワーク固有の難しさ デプロイが2系統になり、CORSやトークンの受け渡しが必要 まとめるとこうです。 構成 解決したこと 代償 サーバー側レンダリング + jQuery サーバーが真実で、制御が単純 ブラウザ側のコードに構造がない React / Next + API ブラウザ側のコードに構造がある 真実が分断され、同期と制御が複雑 とほほ。どちらも一長一短です。 仮説：AI時代ならサーバー側レンダリングに戻せるはず どちらもつらいなら、AI時代はサーバー側に戻すのが正解だと考えました。 Reactを選んだ理由は「JSを書くのがつらい」だった。AIがそれを解消するなら、DjangoやRailsのサーバー側レンダリングに戻し、ロジックをAPIとして再利用できる形にしておいたほうが、ブラウザの制御がしやすくて合理的なはずだ。 この仮説がどこまで正しいのか、海外・国内のブログ、ベンチマーク、各社のテックブログを調べてみました。 調査結果 結論から言うと、仮説は「方向」は合っていて、「理由」が間違っていました。 先に注意点です。同じ業務アプリを「サーバー駆動」と「SPA + API」で作り、AIの成功率を比べた中立の実測は見つかりませんでした。以下は間接的な実測と体験談からの判断です。 合っていたこと サーバー側に寄せるとブラウザ制御は単純になる htmxは HX-Redirect などのレスポンスヘッダで、サーバーからブラウザに直接指示できる（ htmx reference ） InertiaやTurboも、サーバーのリダイレクトにそのまま従う（ Inertia: The Protocol ） 境界を減らすとAIの成功率が上がる 変更が1ファイルなら成功率17.7%、4ファイルなら6.9%（ SWE-PolyBench 、Claude 3.5 Sonnet時代の数字） LayerXはフロントとバックのリポジトリを統合し、API追加が1つのPRで完結するようになったと報告（ LayerXの登壇資料 ） ロジックは再利用できる形にしておく ただし「APIを先に作る」ではなく「サービス層に集める」（ HackSoft Django Styleguide ） HTMLビューもJSON APIもMCPツールも、サービス層を呼ぶ薄い皮として後から足せる 間違っていたこと 「AIがJSを書いてくれるから戻せる」は理由にならない AIが解消するのは書く手間だけで、構造は与えてくれない AIが最も無難に書けるのは依然React（AIアプリビルダーの既定もReact + Tailwind） htmxの hx-target もファイルをまたぐ文字列の約束事で、jQueryのセレクタ問題と同じ落とし穴がある テンプレートは検証が弱い Djangoテンプレートは、変数が存在するかどうかを静的に検査できない（ django-language-server ） 型チェックを編集のたびに回すとAIの成功率が約80%から84%に上がるという報告があり、テンプレートはこの恩恵を受けにくい（ Pyrefly ） 白フラッシュは素のMPAに戻すとむしろ増える ページ間のView TransitionsはChrome 126以降とSafari 18.2以降で使えるが、Firefoxは未対応（ web-features explorer ） hx-boost やTurbo Driveのような仕組みが別途必要 つまり最適解は「サーバー側レンダリングに戻る」ではなく、 サーバーを唯一の真実にして、1機能がまたぐ境界（リポジトリ・言語・スキーマ層）を減らす ことでした。 主要な構成の種類 調べた結果、業務アプリの構成は大きく4つに分けられます。 1. サーバー駆動（Django / Rails / Laravel + htmx / Hotwire / Livewire） 例： Django + htmx、Rails + Hotwire、Laravel + Livewire 特徴： サーバーがHTMLを返し、振る舞いはHTML属性に宣言的に書く リダイレクトや認証切れをサーバーが直接指示できる クライアントのステート管理がほぼ不要 1リポジトリ1言語で、CORSも別ビルドも不要 Railsのベンチマークでは最良モデルが21タスクの92%を解決（ Rails Foundation ） こんな時に選ぶべき： 一覧・検索・フォーム・承認フローが中心の業務アプリ リッチな画面が数枚で済む 少人数でフルスタックに開発したい 注意点： ドラッグ&ドロップ、楽観的更新、条件分岐の多い動的フォーム、オフライン、共同編集は苦手 テンプレートは型検査が効かないので、レンダリングテストとE2Eで補う htmx 4.0は2026年8月公開で破壊的変更あり。AIの知識は2.x中心と考えられるので、当面は2.x固定が無難（ htmx 4.0.0 ） AIがフレームワークの既存APIを使った割合は8〜35%どまり。規約はリンタとレビューで強制する 2. Inertia型モノリス 例： Laravel + Inertia + React 特徴： ルーティング・認証・検証はサーバー、描画だけReact API層もGraphQLもクライアント側のデータ取得層も消える Reactのコンポーネント資産と型は残せる v3（2026年3月）で楽観的更新に対応（ Laravel News ） こんな時に選ぶべき： リッチな画面が多いが、API分離のつらさは解消したい チームがすでにReactに慣れている バックエンドにLaravelを選べる 注意点： 一級の統合を確認できたのはLaravelだけ Django向けの類似ライブラリ（django-bridge）は0.x系で、採用実績を確認できず 非公式アダプタではAIが動くコードを出せなかったという体験談あり 3. フルスタックTypeScript 例： Next.js（App Router）、TanStack Start 特徴： 言語が1つで、エンドツーエンドの型が効く 学習データが最も多く、UIの見栄えも良い サーバー/クライアントの境界は消えず、コンポーネント境界とキャッシュに移るだけ こんな時に選ぶべき： 公開サイトでSEOや初期表示速度が重要 UIの質が競争力になるプロダクト チーム全員がTypeScript 注意点： 変化が速い。Next.js 16のAPIではAIの合格率が53%で、ドキュメント索引を渡して100%（ Vercel ） 2025年12月にRSCでCVSS 10.0の脆弱性（React2Shell）が公開された（ UpGuard ） 認証の内側だけで動く業務アプリにSSRはほぼ不要 4. SPA + 型付きAPI 例： Vite + React + FastAPI（OpenAPIからクライアント生成） 特徴： リッチな画面を制約なく作れる OpenAPIからクライアントを生成すれば、契約のずれがビルドエラーになる（ FastAPI docs ） 同じAPIをモバイルアプリからも使える こんな時に選ぶべき： グリッド編集やドラッグ&ドロップが主要機能を占める オフライン動作やリアルタイム共同編集が要件にある ネイティブアプリとAPIを共有する 注意点： リダイレクトや認証切れをクライアントで扱い続ける構造は残る フロントとバックは1つのリポジトリにまとめる GraphQLは「DBモデル・スキーマ・TypeScript型」の3層を揃える負担があり、社内アプリでは維持する根拠が弱い（私の判断です） 実用的な選択フローチャート ステップ1: 「最も難しい画面」を確認 グリッド編集、ドラッグ&ドロップ、項目同士が複雑に連動するフォームがどのくらいあるかを数えます。ここが最大の分岐点です。 ほぼない、または数枚 → サーバー駆動（難しい画面だけReactの島にする） 主要機能を占める → Inertia型 または SPA + 型付きAPI ステップ2: 要件を確認 オフライン動作、リアルタイム共同編集、ネイティブアプリとのAPI共有がある → SPA + 型付きAPI 公開サイトでSEOが重要 → フルスタックTypeScript どれもない → サーバー駆動 または Inertia型 ステップ3: チームの資産を確認 Pythonの資産を活かしたい → Django + htmx Reactの資産を活かしたく、Laravelに移れる → Laravel + Inertia + React ReactもPythonも捨てたくない → Vite + React + FastAPI（Next.jsは外す） 私の場合はPythonバックエンドで、フォームと一覧が中心の業務アプリが多いです。なので新規は Django + サービス層 + htmx 2.x、難しい画面だけReactの島 が第一候補になります。 既存のNext.js + FastAPIを一括で書き直す必要はありません。次の順で段階的に進めるのが現実的です。 フロントとバックを1つのリポジトリにまとめる ロジックをサービス関数に寄せる 新規エンドポイントからGraphQLをやめ、OpenAPIのクライアント生成に切り替える リダイレクトや認証切れで困っているCRUD画面から、1画面ずつサーバー描画に置き換える まとめ AIはコードを書くコストを下げましたが、理解と検証のコストは下げていません。なので構成を選ぶ基準は「書きやすさ」から、「1つの変更が何か所に波及し、その正しさを機械がどこまで確かめられるか」に移ります。 各構成の選択基準： サーバー駆動（Django + htmx など）: フォームと一覧が中心で、境界を最小にしたい時 Inertia型モノリス: リッチな画面が多く、API分離のつらさも解消したい時 フルスタックTypeScript: 公開サイトやUIの質が競争力になる時 SPA + 型付きAPI: リッチな画面が主役、またはオフラインやネイティブアプリ対応が必要な時 本記事を執筆したことで実装するプロダクトに最適化した技術スタックを選べるようになったかと思います。 ではまた ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post とりあえずReact/Next.jsを選ぶのをやめたい｜AI時代のWebアプリ技術選定 first appeared on SIOS Tech Lab .