本記事は 2026 年 11 月 6 日に Kiro ブログで公開された「 How Kiro Auto uses model cascading to match the model to the work 」を翻訳したものです。 TL;DR： Auto は裏側でモデルカスケードを使っています。どのセッションも効率のよい最初のモデルで始まり、独立したチェックがバックグラウンドで作業を確かめ、必要になったときに Auto はセッションをより高性能なモデルに引き継ぎます。DeepSWE v1.1 を使った社内の評価では、カスケードは高性能なモデル単独とほぼ同じ成績を出し、タスクの約 5 件に 4 件は引き継ぎなしで完了しました。 Kiro では、ほとんどの方に Auto での作業をおすすめしています。 モデルのドキュメント にあるとおり、Auto がユーザーに代わってモデルを選び、高い品質の基準を保ちます。有料プランでは、その基準は Claude Opus クラスの品質です。この記事では、Auto がその基準を満たすための方法の 1 つである、モデルカスケードという手法を紹介します。 難しさはセッションが進むにつれて見えてくる Kiro に、不安定な日付パーサーの修正を頼んだとします。最初の手順は決まりきった作業です。ファイルを読み、関数を見つけ、不具合を再現する、失敗するテストを書きます。ところがそのテストで、ほかの 3 つのモジュールにまたがるタイムゾーンの前提が見つかり、小さな修正がリファクタリングに変わります。逆のことも起きます。大きく見えたタスクが、2 行の変更で済むこともあります。 モデルの性能が上がるにつれて、より大きな仕事を任せるようになり、Kiro のセッションは長くなっています。手順の多い長いセッションは、ファイルを読み、コードを編集し、テストを実行し、やり直すといった多くの手順を踏みます。その難しさは、始まった時点では決まっていません。セッションの難しさには形があり、その形は進めてみて初めて見えてきます。図 1 では、同じセッションを 3 通りのやり方で進めています。 図 1: 難しさはセッションが進むにつれて現れるため、最初に 1 回だけ選んだモデルでは、簡単な区間で性能が余るか、難しい区間で力が足りなくなります。カスケードは進めながら調整します（イメージ図）。1 枚目は途中で難しくなるセッション、2 枚目は簡単なままのセッションです。画像の右上のボタンは原文のインタラクティブな図のもので、この記事では 2 つの状態を 2 枚の画像に分けて載せています。 作業を始める前にモデルを選ぶとき、判断の手がかりは依頼の内容しかありません。高性能なモデルを選べば、効率のよいモデルでも同じようにこなせた決まりきった手順も含めて、すべての手順をそのモデルが担います。効率のよいモデルを選べば、決まりきった手順はうまくこなせますが、作業が難しくなると、行ったり来たりを始めたり、すでに終えた作業をやり直したりすることがあります。次に、図 1 の 2 枚目の、簡単なままのセッションを見てください。依頼が同じなので、最初に選ぶモデルは変わりません。カスケードは最後まで最初のモデルのままです。セッションが、そのモデルで扱える以上に難しくならないからです。 Auto のモデルカスケードのしくみ モデルカスケードは、1 回のモデルの選択を、エージェントのセッション全体を通して行う一連の判断に変えます。 効率のよいモデルで始める。 どのセッションも最初のモデルで始まります。最初のモデルは、日常的な幅広い作業をうまくこなす効率のよいモデルです。多くのセッションでは、このモデルが適切な選択で、作業のすべてをこなします。 バックグラウンドで作業を確かめる。 独立したモデルが、セッションの軌跡、つまりここまでに行われた作業を確かめます。チェックは非同期に動くので、セッションがチェックを待つことはありません。また、作業しているモデルが自分の進み具合を採点することもありません。 そのまま続けるか、引き継ぐ。 セッションが着実に進んでいるあいだは、何も変わりません。セッションが効率よく進まなくなった兆し（同じコードを繰り返し調べる、すでに終えた作業をやり直す、など）をチェックが見つけると、Auto はセッションをより高性能なモデルに引き継ぎます。引き継ぎではここまでの作業の要点が受け渡されるので、より高性能なモデルは最初からやり直すのではなく、今の状態のセッションをそのまま引き継ぎます。 必要に応じて繰り返す。 引き継ぎは、セッションが最も高性能なモデルで動くようになるまで繰り返し起こりえます。現時点では、引き継ぎは上の方向にだけ行われます。セッションを効率のよいモデルへ戻すことは、今後のアップデートで検討します。 モデルへのアクセスを管理しているチームでは、引き継ぎ先も Auto が使えるモデルの中から選ばれるので、引き継ぎにも Auto と同じガバナンスの設定が適用されます。管理者がモデルへのアクセスをどう制御するかは、 モデルのガバナンス をご覧ください。 図 2: Auto のモデルカスケードでは、最初のモデルがセッションを始め、独立したチェックがバックグラウンドで作業を確かめます。より高性能なモデルがセッションを引き継ぐのは、その必要がある兆しをチェックが見つけたときだけです。これは考え方を示したイラストで、実際のチェックの動き方を表したものではありません。 担当のエンジニアがチケットに取り組み、その肩越しにレビュアーが作業を見ている場面を考えてみてください。エンジニアは作業を続け、手を止めて自分の進み具合を採点することはありません。それはレビュアーの仕事です。作業が前に進んでいるあいだ、レビュアーは何も言いません。作業が同じところを回り始めたとレビュアーが気づいた時点で、チケットはより腕の立つエンジニアに渡り、そのエンジニアが今の状態から引き継ぎます。 カスケードを既定で動かしても安全なのは、このしくみがあるからです。作業しているモデルは自分の進み具合を採点せず、引き継ぎは最初からやり直すのではなく、すでに終えた作業の上に積み上げます。より高い性能が必要なセッションは途中でその性能を得られ、必要のないセッションは最初のモデルのまま進みます。 測定したこと カスケードを、Datacurve による、手順の多い長いタスクを扱うソフトウェアエンジニアリングのベンチマークである DeepSWE v1.1 で評価しました。タスクはこのベンチマークのために新しく作られたもので、オープンソースのリポジトリを題材にし、人が書いた、動作を確かめるテストで採点されます。そのため、難しさが途中で変わりうる、何段階にもわたるセッションが必要になります。Kiro のエージェントエンジンで 3 つの構成を動かし、それぞれの構成でベンチマーク全体を 3 回ずつ、独立に実行しました。 最初のモデルのみ。 すべてのタスクを、効率のよい最初のモデルで最初から最後まで実行します。 高性能なモデルのみ。 すべてのタスクを、より高性能なモデルで最初から最後まで実行します。 カスケード。 すべてのタスクを最初のモデルで始め、より高性能なモデルへ引き継げる状態にしておきます。 3 つの構成とも、推論（reasoning）の設定は同じです。違いは、どのモデルが作業を担うかだけです。結果は pass@1（1 回の試行で解けたタスクの割合）を、3 回の実行の平均 ± 1 標準偏差で示します。 高性能なモデル単独とほぼ同じ品質 図 3 は 3 つの構成の pass@1 を比べたもので、その下の表に同じ値を載せています。 図 3: DeepSWE v1.1 で、カスケードの pass@1 は 69.37% でした。高性能なモデル単独（70.57%）とほぼ同じで、最初のモデル単独（63.96%）より 5.40 ポイント高い値です。エラーバーは 3 回の実行の ± 1 標準偏差を示します。 構成 pass@1（3 回の実行の平均 ± 1 標準偏差） 最初のモデルのみ 63.96% ± 2.70 高性能なモデルのみ 70.57% ± 2.08 カスケード（最初のモデルで始め、より高性能なモデルを使える） 69.37% ± 1.56 カスケードはタスクの 69.37% を解きました。高性能なモデル単独（70.57%）とほぼ同じで、その差は実行ごとのばらつきの範囲内です。また、最初のモデル単独（63.96%）より 5.40 ポイント高い値です。3 つの構成のうち、実行ごとのばらつきが最も小さかったのもカスケードでした。つまり、すべてのタスクを最初のモデルで始めても、それが品質の足かせにはなりませんでした。 約 5 件に 4 件は引き継ぎなしで完了 図 4 は、カスケードのタスクがどのモデルで終わったかを示しています。 図 4: DeepSWE v1.1 の 3 回の実行を通して、タスクの 80.48% は最初のモデルだけで完了し、19.52%（約 5 件に 1 件）はより高性能なモデルに引き継がれました。 すべての実行を通して、タスクの 80.48% は最初のモデルで完了しました。残りの 19.52%、約 5 件に 1 件は、途中でより高性能なモデルに引き継がれました。 今回の DeepSWE の実行では、引き継がれたタスクには共通点がありました。最初から最後まで正しく仕上げるのが難しい変更だったことです。たとえば、型や API から CLI や設定まで、多くの層に同時に触れる機能や、保存された状態やキャッシュ、処理の順序に左右される振る舞いです。小さく局所的な変更で引き継ぎが必要になることはまれでしたが、大きな変更が必ず引き継ぎを必要としたわけでもありません。分かれ目になったのは、注意深い設計や、コードの複数の部分のあいだで整合性を保つことが、作業のどれだけを占めていたかでした。 引き継ぎが起きたタイミングにも、同じくらいはっきりした傾向がありました。これらのタスクでは、最初のモデルはほぼ必ず、序盤の手順を自力でこなしていました。コードを書き、多くの場合はビルドとテストを通すところまで進めています。引き継ぎは、そのあとの検証と統合の段階で起きる傾向がありました。最初のモデルが、変更したコード全体ですべての要件が満たされていることを示そうとしている段階で、セッションが効率よく進まなくなった兆しをチェックが見つけたのです。こうしたことは、どれも依頼の内容からは分かりませんでした。チェックが見守り続け、セッションが必要とするどの時点でも引き継ぎが起こりうるので、カスケードは作業がいつ難しくなるかを前もって知る必要がありません。 Auto がクレジット倍率 1x のまま複雑な作業を高い品質でこなせるのは、これが理由の 1 つです。ほとんどのセッションは最初のモデルで完了し、より高性能なモデルが引き継ぐのは作業上必要なときだけです。 ベンチマークの数値についての注意 これらの数値は、社内の評価用ベンチマークの、ある特定の実行で得られたものです。本番環境での見込みではなく、お客様ごとの実際のワークロードでの結果は異なります。 引き継ぎの割合はタスク全体の平均です。セッションがどれくらいの頻度で引き継がれるかは作業によるので、個々のセッションでは異なります。引き継ぎはユーザーには見えません。引き継ぎが起きていることを意識しなくても、品質の面での効果を得られます。 DeepSWE の数値は社内のベンチマーク用の実行環境（ハーネス）で測ったもので、公開されている DeepSWE のリーダーボードの公式の設定と同じではありません。そのため、割合を公開のリーダーボードの数値と比べることはできません。 試してみる モデルカスケードは Auto のしくみの一部で、効率の面での利点はすべての Kiro のお客様が利用できます。次にセッションを始めるときは、 Kiro で Auto を選んでください。Auto とモデルの選択のしくみについては、ドキュメントの モデルの概要 をご覧ください。 原文の著者 Vijay Lingam（Applied Science）、Mayank Gupta（Applied Science）、Sudipto Nandi（Engineering）、Neil Kulkarni（Engineering）、Jack Wang（Engineering）、Sai Srinivas Somarouthu（Engineering） 翻訳者について 稲田 大陸 – いなりく AWS Japan で働く Kiro をこよなく愛すソリューションアーキテクト。普段は製造業のお客様を支援しています。その活動の傍ら、最近は AI 駆動開発ライフサイクル (AI-DLC) の日本のお客様への布教活動もしつつ、 Kiro のブログ などを執筆しています。

セーフィーのエンジニアリングオフィスで開発プロセスの改善を担当している横道です。 セーフィーでは2026年から、TechPdM（Technical Product Manager）という役割を正式に導入しました。TechPdMという肩書きは最近よく見かけるようになりましたが、何を担う役割なのかは会社によってかなり違います。 この記事では、セーフィーがなぜTechPdMを置いたのか、TechPdMに何を任せているのかを紹介します。導入してみて見えてきた課題と、いま進めている対策についても書きます。 配信プラットフォーム「Safie（セーフィー）」の複雑さ TechPdMの話に入る前に、

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 .