ALT FlutterKaigi 2026 の登壇セッション一覧スライド。見出しは「FlutterKaigi 2026 登壇セッション」、右上に「10.29 – 30 Platinum Sponsor」。リード文は「株式会社アサインは FlutterKaigi 2026 に協賛し、メンバー4名が登壇します」。以下の4件を上から順に記載。1件目、Day 1 10月29日(木) 11:40–12:10、JTCCホール、「複数ドメインを一つのアプリに統合するFlutterの設計と運用」白井翔大。2件目、Day 1 10月29日(木) 13:25–13:35、Cupertino／ビギナーズLT、「そのデザイントークン、Flutterでも同じ見た目になりますか？」中水優輝。3件目、Day 1 10月29日(木) 16:25–16:35、Cupertino／ビギナーズLT、「React Native経験者がFlutterを30日間触って驚いたこと」齋藤稜太。4件目、Day 2 10月30日(金) 13:15–13:25、Cupertino／LT、「企画からFlutter実装まで、1つの機能を一貫して開発したプロセスと成果物」栗田滉之。下部に会場名「浜松町コンベンションホール」。

ALT 連載のまとめスライド。①〜⑨の誤解と答えを3×3のカードで並べたマップ。POSTの分類軸はsafeと冪等、リトライは失敗と結果不明の区別から、4xx / 5xxは再試行の手がかり、200は転送の成功まで、404は見つけられないだけ、キャッシュは再利用と再検証の設計、Cookieは送信条件の集合、CORSはブラウザがユーザーを守る仕組み、TLSの保証は経路まで。下段に一次資料の案内（RFC 9110 / 9111 / 6265 / 8446、Fetch Standard）。進捗バーは全10回すべてが赤で完結を示す。

ALT TLSの保証範囲を詳解するスライド。上段はTLSの目的（通信する二者間に安全なチャネルを提供し、相手認証、機密性、完全性を提供する、RFC 8446 §1）と保証の外側（XSSが成立するとスクリプトがオリジンの権限で実行される、OWASP Top 10)の対比。中段は経路のトンネル図で、左右の端（ブラウザの中のクライアント、サーバの中のアプリケーション）にはそれぞれXSSやCSRF、インジェクションや認可不備が「TLSの守備範囲の外」ラベル付きで残り、中央のトンネルだけが「TLSが守るのはここだけ（機密性、完全性、相手認証）」で、証明書検証が正しく働くことが前提と付記。その下に錠前アイコンの注記で、意味は「通信路が暗号化されている」までで「このサイトは信頼できる」ではない。下段は「HSTS、CookieのSecure / HttpOnly / SameSite、トークンの置き場所」という端の防御の設計指針。全10回のうち9回目を示す進捗バー。

ALT CORSの定義を詳解するスライド。上段は同一オリジンポリシー（オリジンはスキーム、ホスト、ポートの三つ組で、異なるオリジンの読み取りを既定で分離する、RFC 6454 / HTML Standard）とCORSプロトコル（レスポンスをオリジンを越えて共有してよいかを示すヘッダ群、Fetch Standard）の定義引用。中段は2レーンの経路図で、上のレーン「ブラウザの中」では悪意あるページ（evil.example）がログイン済みのapi.exampleを読もうとするとブラウザが遮り（越えるにはサーバの同意ACAOが要る）、守られるのはユーザーのセッション。単純でないリクエストはOPTIONS（preflight）で事前に伺う。下のレーン「ブラウザの外」ではcurlや任意のクライアントが同じリクエストを直接送っても遮るものが無く（赤破線で強調）、サーバの防御にはならない。その下に「CORS errorの直し方はサーバのヘッダ」という注記。下段は「サーバを守るのは認証と認可、そしてCSRF対策の仕事」という設計指針。全10回のうち8回目を示す進捗バー。

ALT Cookieの送信条件を詳解するスライド。上段は送信条件（リクエスト先のホストがDomainに、パスがPathにマッチし、Secure付きなら安全なチャネルに限られる、RFC 6265 §5.4）とSameSite（Strictはクロスサイトに送らず、Laxはトップレベルナビゲーションかつ安全なメソッドに限る、RFC 6265bis）の定義引用。中段は照合のゲート図で、保存済みCookieがDomain、Path、Secure、SameSiteの4つの照合を順に通過し、すべて通過したときだけCookieヘッダに載る流れ。各ゲートに落ちる例（host-onlyでサブドメインに送られない、Path=/adminは/に載らない、SecureはHTTPに送られない、明示Laxは他サイトからのPOSTに付かない）を併記し、その下に「どれか一つでも落ちればそのリクエストには載らないが、Cookieは保存されたまま残る」という赤のNG注記。下段は「DevToolsのApplicationパネルは保存の有無、Networkパネルは送信の有無」というデバッグ指針。全10回のうち7回目を示す進捗バー。

ALT RFC 9111のキャッシュ定義を詳解するスライド。上段は新鮮性（経過時間が新鮮性寿命を超えないレスポンスはサーバへ問い合わせずに再利用できる、§4.2。明示期限が無ければヒューリスティック期限の割り当てがありうる）と再検証（古いレスポンスは条件付きリクエストで検証し、変更がなければ304で本体転送を省く、§4.3）の定義引用。中段はレスポンス受領からの時間軸で、新鮮性寿命を境に左がfresh（問い合わせず再利用、リクエスト自体が飛ばずサーバのログにも出ない）、右がstale（ETag / Last-Modifiedの条件付きリクエストで検証してから再利用、変更が無ければ304）。その下に「消せば直る」が効かない理由2つで、CDNや共有キャッシュには消去が届かない、ファイル名が同じままだと更新を識別できない（赤枠強調）。下段は「静的アセットはハッシュ付きファイル名+immutable、HTMLはno-cache」という設計の定石。全10回のうち6回目を示す進捗バー。

ALT 404と410の定義を詳解するスライド。上段は404 Not Found（現在の表現を見つけられなかったか存在を開示する意思がないことを示し、一時的か恒久的かは示さない、RFC 9110 §15.5.5）と410 Gone（アクセスがもはや利用できず恒久的である可能性が高い、§15.5.11）の定義引用。中段は到達順のステップ図で、STEP 1が名前解決の層（DNSのNXDOMAIN、ステータスコードは存在しない）、解決できたらSTEP 2の接続の層（TCP / TLSの接続失敗、これも404ではない）、つながったらSTEP 3のHTTPの層（404 / 410がここで初めて登場、赤枠強調）と矢印でつながる。下段は「curl -v で名前解決、接続、TLS、ステータスの順に切り分けられる」というデバッグ指針。全10回のうち5回目を示す進捗バー。

ALT 200 OKの守備範囲を詳解するスライド。上段はステータスコードの定義（リクエストの結果とレスポンスのセマンティクスを表す3桁の整数コード、RFC 9110 §15）と200 OKの定義（リクエストが成功したことを示し、内容はメソッドに依存する、§15.3.1）の引用。中段は守備範囲を示す2分割バーで、左のグレー領域が「200が語る範囲：リクエストが成功した」、右の赤破線領域が「語らない範囲：業務の成否」。その下に境界のずれの実例3つで、GraphQLは実行エラーでも200を返す設計、202 Acceptedは受け付けただけで完了を約束しない、200+エラーボディは語らない範囲の失敗を語る範囲に埋めた形で、契約が無いと監視やリトライをすり抜ける（赤枠強調）。下段は「対応をAPIの契約として明文化し、監視が5xxを数えるだけで異常に気づけるかで点検する」という設計指針。全10回のうち4回目を示す進捗バー。

ALT RFC 9110のエラークラス定義を詳解するスライド。上段は4xx（クライアント側に誤りがあったとみられることを示し、サーバはエラー状況の説明を送るべき、§15.5）と5xx（サーバが自身の誤りか実行不能を認識していることを示す、§15.6）の定義引用。中段は「受け取ったコード、コードが語ること、再試行の判断」の3列対応表で、400 / 403 / 404 / 422は入力や権限の誤りなので直して再送、429 / 503は過負荷や一時停止なのでRetry-Afterを尊重し無ければバックオフで待って再送、500 / 502 / 504はサーバ側の失敗で、処理がどこまで進んだかはコードだけでは決まらないため冪等性で判断（赤で強調）。下段は「4xxを成立させるのはAPI側の説明責任で、標準はProblem Details（RFC 9457）」という設計指針。全10回のうち3回目を示す進捗バー。

ALT RFC 9110 §9.2.2を詳解するスライド。上段は「自動再送の根拠」（冪等なメソッドは通信障害でレスポンスを読めない場合に自動的に繰り返せる）と「自動再送の禁止」（冪等と知る手段がない限り非冪等メソッドを自動再送すべきでない）の定義引用。中段はリトライ判断の決定木で、タイムアウトや通信断から始まり、「メソッドは冪等？」がYESならそのまま自動再送、NOなら「冪等だと知る手段か、未適用と検知する手段は？」に進み、Idempotency-Keyのような鍵があればYESで冪等化して再送（サーバが1回分と扱う契約が前提）、NOなら自動再送せずユーザーに確認を返す（赤枠強調）。下段は「タイムアウトは失敗ではなく結果を知らない状態」という注記。全10回のうち2回目を示す進捗バー。

ALT RFC 9110のメソッド定義を詳解するスライド。上段はsafe（§9.2.1、読み取り専用でクライアントが状態変化を要求も期待もしない）とidempotent（§9.2.2、同一リクエストを複数回送っても意図される効果が1回と同じ）の定義引用と補足。中段はsafe×idempotentの2軸マトリクス表で、safeかつ冪等のセルにGET / HEAD / OPTIONS / TRACE、非safeで冪等のセルにPUT / DELETE、非safeで非冪等のセルにPOST / CONNECT（赤枠強調）。safeかつ非冪等のセルは「safeなメソッドはすべて冪等でもあるため仕様上存在しない」と斜線で示す。下段はPOSTの定義（§9.3.3、対象リソース自身のセマンティクスに従った処理の依頼）と、リトライの安全はIdempotency-Keyなどアプリ側で設計するという含意。最下部に全10回のうち1回目を示す進捗バー。

ALT 状態管理ライブラリ比較の図。3カラムでRiverpod(宣言的な依存グラフ、汎用で中〜大規模向き)、Bloc(イベント駆動で状態遷移を明示、追跡とログ)、signals(細粒度リアクティブで最小再描画)を同格のデザインで並べる。銀の弾丸はなく、機能でなく設計思想で選ぶと注記。下部に全10回の連載マップがあり、最終回の10回目「選定」がハイライトされている。

ALT 単方向データフローとMVVMの図。左にView→操作→ViewModel/Notifier(状態と表示ロジックを持つ)→state更新→再描画のフロー、右にView(Widget)、ViewModel(Riverpod Notifierで実装、共有ストアにもなる)、Repositoryのレイヤー対応。書き換えはNotifier経由に一本化＝単方向と注記し、下部にMVVMは本来双方向バインディングを含む考え方でFlutterでは単方向で組むMVVMが定石という補足バー。全10回の連載マップがあり、現在地の9回目「単方向フロー」がハイライトされている。

ALT 状態の2分類の図。左はEphemeral State(局所状態、setStateで十分、例はタブindex・アニメ進行・フォーム入力途中)、右はApp State(共有状態、Riverpod等で管理、例はログインユーザー・カート・設定)。判断軸は「他の画面が知る必要があるか」。下部に全10回の連載マップがあり、現在地の8回目「状態の2分類」がハイライトされている。

ALT Riverpod実装の3ステップの図。①定義は@riverpodのNotifierコード例(build()で初期状態、stateで更新)とcounterProviderが自動生成される注記、build()は同期の例でFutureを返せば非同期(AsyncNotifier相当)になる補足つき。②使うはref.watch(購読・再ビルド)、ref.read(一度だけ読む・操作)、ref.listen(副作用)の早見表で、watchする相手は①で自動生成されたcounterProvider。③調整はProvider側の設定としてautoDispose(未使用の状態を自動破棄)とfamily(引数つきで生成)。providerがproviderをwatchすると依存グラフが自動で組まれると注記。下部に全10回の連載マップがあり、現在地の7回目「Riverpod実装」がハイライトされている。

ALT Riverpodの設計思想を示す対比表。左列にProviderの弱点(BuildContext依存/ProviderNotFoundが実行時/同じ型を複数持てない/テスト差し替えが面倒)、右列にRiverpodの解決(contextなしでアクセス/NotFoundがそもそも起きない/Provider自体を識別子に/overrideで注入)。下部に全10回の連載マップがあり、現在地の6回目「Riverpod思想」がハイライトされている。