Closed19
フロントエンドカンファレンス北海道2025 メモ
ピン留めされたアイテム
Taiga Kiyokawa記事にまとめたのでクローズ
Taiga Kiyokawaフロントエンドカンファレンス北海道2025 の個人的なメモ。興味のあるトークだけ。オンライン参加。
イベント概要
- 開催日時：2025年9月6日（土）10:00AM–6:00PM
- イベントハッシュタグ： #frontendo
メモ一覧
- HTMLの品質ってなんだっけ？ -“HTMLクライテリア”の設計と実践
- Designing on The Web
- スクリーンリーダーと仲良くなるためのマークアップ
- LT: エラーとアクセシビリティ
- LT: 「待たせ上手」なスケルトンスクリーン、そのUXの裏側
- AIエージェントによるWebアクセシビリティ試験の自動化 〜Gaudiyが実践するAI活用開発〜
- <UserCard data={クソデカ複雑Object} />問題を考える
- Testing Trophyは叫ばない
- Viteのプラグインを作ると内部をイメージできるようになる
- RSCの時代にReactとフレームワークの境界を探る
- Progressive Web Apps（PWA）は夢を見るか、夢になるか
- ブラウザは「フロントエンド」を何から守っているのか？
- AI時代のUIはどこへ行く？
- すべてのinputに可視ラベルがあれば
- 「手軽で便利」に潜む罠。 Popover API を WCAG 2.2の視点で安全に使うには
- iPhone Eye Tracking機能から学ぶやさしいアクセシビリティ
- おじいちゃんに優しいUIを作ってみた
Taiga KiyokawaHTMLの品質ってなんだっけ？ -“HTMLクライテリア”の設計と実践
- 登壇者：うな @unachang113 さん
- LayerX CRE
- 前職PR TIMESの活動についての発表
- 建前：HTMLの品質に対する共通認識を作る
- 本音のきっかけ：アクセシビリティ対応の土台を作りたい
- ソフトウェア品質の8つの特性にHTMLの品質を担保
- 機能適合性
- 性能効率性
- 互換性
- 信頼性
- セキュリティ
- 保守性
- 移植性
- HTMLだけの話だと狭すぎる…? → 迷走 → アドバイザーに相談
- カテゴリ
- ユーザー体験を支える品質
- UIコンポーネント
- アクセシビリティ
- ライブラリの選定
- 成長できるチーム
- HTMLの仕様理解
- セマンティックなHTMLを書くことの意義
- xxx
- ユーザー体験を支える品質
- Webフロントエンド版DXクライテリアをベースに
- HTML解体新書の輪読会を実施
感想
- 計測して課題を分析、改善に繋げるサイクルを回せているのが良い
- 「アクセシビリティ」と言われるより「HTML」と言われた方がエンジニアはモチベーション高く取り組んでくれそう？分からない
- Webフロントエンド版DXクライテリアは結構幅広く活用できそう、今回はこれをベースにHTML向けに細分化した取り組みのひとつの事例と言えそう
- HTML解体新書とか、フロントエンド系の輪読会やりたい
Taiga KiyokawaDesigning on The Web
- 登壇者：saku @sakupi01 さん
- Cybozu
- HTMLは不明なものを全て無視することで互換性を保っている
- Web Designは未知なるものとコラボレーションをしながらデザインしている
- CHSS
- UA StyleSheet
- User StyleSheet
- CSS
- !importantは詳細度バトルに勝つためではなく、UA/Userのスタイルを守るため
-
Authorはデザインをコントロールできない → CSSは宣言的な言語
- width: auto → コンテンツの幅によって自動的に…
- text-wrap: pretty → なんかいい感じにして
- （裏のルームの発表と並行して視聴していたのであまりメモとれていない...）
感想
- Webデザインの根幹の思想について、そもそもコントローラブルなものではないというのはとても納得
- あくまで我々は我々のコンテンツを閲覧するのにオススメなデザインを「宣言」しているだけに過ぎず、どう閲覧されるのかは制御できないし、しようと思わない方が良い
- フロントエンドエンジニアよりもWebデザインを作るデザイナーにこそ理解してもらいたいけど、このWebの歴史の話そのまま言ってもあまりピンとこないかも？ブラウザの仕組みだとかその辺から説明が必要そう
- 数十分のプレゼンテーションよりも、書籍とかでじっくり読みたい感じの発表だった
Taiga Kiyokawaスクリーンリーダーと仲良くなるためのマークアップ
- 登壇者：ただ @taketada323 さん
- Fusic エンジニア
- アクセシビリティカンファレンス福岡 実行委員
- アクセシビリティ対応の一部として捉えず、セマンティックなHTMLを目指す
- 読み上げられないボタン
- 代替テキスト
- カルーセル
- エラーメッセージ
- lang=”ja”
- トースト：ARIAライブリージョン、Notification API（ユーザー許可が必要）
- それぞれのDOMに役割を持たせる
- アクセシビリティオブジェクトモデルに従って要素を割り当てる
- 意図した順番に読み上げられるように設計する
- （裏のルームの発表と並行して視聴していたのであまりメモとれていない...）
感想
- アクセシビリティ初心者向けにおすすめしたい内容
- HTMLクライテリアの発表でもそうだったけど、あんましアクセシビリティ色強くしない方が聞き入れやすいのかな
- 「アクセシビリティを考えるのはデザイナーの仕事」といった風に自分の仕事であると捉えない偏見があるエンジニアが多い？分からない
- トーストをNotification APIにしてしまおうという発想は初めて聞いて新鮮だった。確かにアリかも。
- それぞれのDOMに役割を持たせる、は良い表現だなと思った。セマンティックなHTMLって要は全ての要素の意味がきちんと説明できることであって、フロントエンドエンジニアはその説明責任があるよなと。
Taiga KiyokawaLT: エラーとアクセシビリティ
- 登壇者：たじまん @schktjm さん
- SmartHR
- ケース1：Submitボタンを押下した後にトーストメッセージを表示
- 時間経過で消える → 2.2.1 不適合、Webコンテンツに制限時間がかけられていないこと
- 入力フォームから離れた位置にある → 3.3.1 エラーの特定に不適合
- flashメッセージをやめよう！
- SmartHRでは2022に非推奨 → 2025年6月に完全削除
- ケース2：入力フォーム → ダイアログが開く → ダイアログにエラーが表示
- エラーは特定できる？ → ダイアログをやめよう！
- ケース2.1：ダイアログをやめて、エラーをフォームの近くに記述
- これでもダメではないが、エラー箇所を辿るのが大変
- → 入力欄のトップにまとめがあると良い
- なんとなくダメそうではなく「何がダメなのか」「誰が困るのか」を具体化する
感想
- FlashMessage（トースト）やめられたの羨ましい〜〜〜〜〜〜〜〜〜〜〜〜〜〜
- 非推奨を宣言した2022年から2025年6月の完全削除までの3年間に想像を絶する苦労があったに違いない...
- うちだと何年かかるんだろう...考えたくもない......
- ダイアログもやめよう！本当にそう
- トップにエラーのサマリがあると嬉しい、は私も過去プロダクトチームにアドバイスした内容だったので「正解」って言われてて安心した
- 私の場合、「なんで」ってところの説明に説得力を持たせられてたかは微妙。こういう利用状況があって、ひとつひとつ辿るのが大変なユーザーがいるんだよということまで言えたら完璧だった。
- 「達成基準に適合しません」と「こういうユーザーが困ります」をセットで説明できるようになりたい
Taiga KiyokawaLT: 「待たせ上手」なスケルトンスクリーン、そのUXの裏側
- 登壇者：朴木 優斗 @dachscafe さん
- チームラボ
- Shimmer 煌めき
- スケルトンは早く感じさせるというかは待ってる感を減らす
- 能動的待機：意識を待ち時間からコンテンツにして負荷を減らす
- 描画後と同じ構造にする
- 馴染みのない場面で使わない
- 数秒から10秒程度が向いている、長すぎる場合はプログレスバーを出す、短すぎるところでもチラつくので良くない
- 待たせ上手
- https://zenn.dev/p/teamlab_fe で資料公開予定
感想
- あの「グラデーションがぐわんぐわんする」スケルトンスクリーンってShimmerって言うんだ！知らなかったので「グラデーションがぐわんぐわんするやつ」って毎回説明していた
- どういう使い方をすると良いのか、どういう場面に適しているのか簡潔で分かりやすかった。弊社のガイドラインにも組み込みたい。
Taiga KiyokawaAIエージェントによるWebアクセシビリティ試験の自動化 〜Gaudiyが実践するAI活用開発〜
- 登壇者：南悠輝 kotori @maminami_minami さん
- スポンサーセッション
- 話すこと
- 自動化手法
- Custom MCPサーバー
- 早急にアクセシビリティ対応が必要に → 早く、正確に、楽したい
- AI以外のツール
- eslint-plugin-jsx-a11y
- polymorphicPropName settings
- as のやつをどのHTML要素と解釈するか
- component settings
- Image → img
- label-has-associated-control
- controlComponents option
- 制御コンポーネントの設定、labelを必須に
- controlComponents option
- polymorphicPropName settings
- Storybook Test runner + axe-playwright
- ハマりポイント：モーダルダイアログだとstorybook-rootにいないことがあるのでチェック対象に含まれるようにする
- @storybook/addon-a11y
- axe DevTools
- eslint-plugin-jsx-a11y
- AIエージェント
- 試験
- レポート
- 最初：Claude Desktop
- Playwright MCP
- ace-coreを無理やり注入する必要があり、断念
- a11yチェック MCP
- 野良のツールのみ
- いい感じには見えるが…
- コンテキスト制限、インタラクション未対応、認証未対応、レスポンシブ確認できない
- Playwright MCP
- Claude Code + Custom MCP Server
- Claude COde: アクセシビリティテストの実行と結果の分析
- Custom MCP
- Playwright
- axe-core
- カスタム評価モジュール
- Playwright MCP: アクセシビリティ問題点の調査
- コンテキスト節約
- axe-coreの生データは肥大化する
- 冗長なHTMLデータは返さない
- 並列化
- 評価モジュール
- WCAG各基準に特化した評価ロジックを実装
- axe-coreだけでは課題、誤検出が多い
- キーボード操作
- AIによるサイクルを回して誤検知の原因を減らしてチェックロジックを実装
- [宣伝] 余熱NIGHT 非公式感想戦<会
感想
- たくさんのツールを破綻なく仕組みとして設計できていそうですごい
- コンテキスト問題はなんか考えなくて済むような方向に進化しないかな〜
- eslint-plugin-jsx-a11y ちゃんと使わなきゃな〜Polymorphic向けの設定とかしんどそう
- Playwrightちゃんと使わなきゃな〜
- axe-coreだけでは不適切な場面で独自評価ロジック実装は、たしかにそうすれば良いのかと納得
- 評価ロジックの実装にもAI使っていく姿勢は確かにそれはそう
- できれば実践した実際の結果とかどう改善に繋がっていったとかの運用サイクルの話も聞きたかった
Taiga Kiyokawa<UserCard data={クソデカ複雑Object} />問題を考える
- 登壇者：どうけ @doke さん
- Studio
- カンファレンスロゴを担当
- 事前収録
- コンポーネントの責務とデータの関連
- コンポーネントの肥大化は「責務」の混在が原因
- 単一のViewは単一のデータ表示を
- ドメインモデルとViewモデルを分ける
- データの加工は事前に行う
- Viewモデル
- 見た目に必要なものだけをPropsで受け取り表示するコンポーネント
- 複雑なViewモデル：フラット vs 構造化
- コンポーネント分割
- バケツリレー
- renderProps
- Contextで分割するのはUIライブラリのようにカプセル化できない限りおすすめしない
- UIデザインとデータ
- フロントエンドのデザインはUIデザインに、設計自体に依存関係がある
- UIデザインの論理に矛盾や複雑性があると、フロントエンドも複雑にならざるを得ない
- 設計時点で話し合おう
感想
- Viewモデルの考え方は確かに導入できると良さそう
- UIライブラリの設計においてはまた違ったアプローチが必要になりそう
- フロントエンドのデザインはUIデザインに依存する。ほんとにそう。UIデザインの構造とフロントエンドの構造の一致はかなり諦めている節はあるので、見直せると良いかも。
- UIデザイナーとしっかり話し合おう。ほんとそう。
Taiga KiyokawaTesting Trophyは叫ばない
- 登壇者：Toms @toms74209200 さん
- （裏の発表が早めに終わったので途中から）
- 関数、UI、E2Eに分けて考える
- 何をテストすべきか：出力、状態、コミュニケーション
- 関数：出力
- UI：状態（GOOD）、コミュニケーション（OK）
- E2E：状態（GOOD）、コミュニケーション（OK）
- テストサイズ
- 関数：Small
- UI: Small, Medium
- E2E: Medium, Large
- 叫ぶアーキテクチャ
- （配信が止まってしまった）
感想
- 断片的にしか視聴できていないので後で資料とかアーカイブとかじっくり見返したい...
- Testing Trophyの新解釈？フロントエンドのテストアーキテクチャの再考のような発表内容だったのかな
- 分類、テスト対象、サイズ、それぞれシンプルで分かりやすそう
Taiga KiyokawaViteのプラグインを作ると内部をイメージできるようになる
- 登壇者：ssssota @ssssotaro さん
- デモ1: 存在しないモジュールをimportしたい on React
- https://stackblitz.com/ で作っていく
- vite.config.ts に作成する
- loadメソッドでexport default
- ViteのPluginでimportはできたが、TSではエラーになる → 型定義ファイルを作成して解決
- デモ2: デフォルトで読み込めないファイルをimportしたい on Svelte
- jsonl を読み込ませる
- transform()で.jsonlファイルをパースする
- resolveId, load, transform
- ライフサイクルフック
- resolveId: そのモジュールならここにあるよ
- load: これ読み込んだらいいよ
- transform: こういうJSコードだと解釈すればいいよ
- UnpluginでWebpack向けに今回の知識が使える
感想
- Plugin作成デモを通して、ViteでJavaScriptを実行するまでに挟まれる処理の解説。すごく分かりやすかった。
- stackblitzってこんな便利なのね。使ったことなかった。
- デモしながら解説しながらをスムーズにこなしててすごかった。アドリブでSvelteで書き出すの相当登壇慣れしてそう。
- よく分からないけどVite PluginでStyle Dictionaryみたいなの自作できそう。Style Dictionaryで足りてるけど。
Taiga KiyokawaRSCの時代にReactとフレームワークの境界を探る
- 登壇者：uhyo @uhyo_ さん
- カオナビ
- RSC
- RSCはReact本体の機能だからこそ複数のフレームワークでサポートされている
- フレームワークはRSCの何をサポートしているのか
- importで繋がったReactプログラムをサーバー側用とクライアント側用に分けて別々でビルドする
- RSC対応の根本はバンドラのプラグインとして実装
- Reactフレームワークの構造
- フレームワークの個性
- バンドラプラグイン
- バンドラの機能
- Reactの機能
-
@vitejs/plugin-rsc
- Wakuも使っているVite公式プラグイン
- ReactはRSC規約を定義し、フレームワークはそれを実装する（Web標準とブラウザの関係性に似ている）
感想
- Reactが思ったよりも民主的なライブラリとして、標準化や規約の策定を意識している方向性なのが分かった。もうWebブラウザにおけるECMAScriptのような関係性や存在感なんだなと。ESにエンジンが必要なのと違ってReactはフレームワークなしでも動くという点がややこしい。
- 本質的にはバンドラのプラグインでサポートしているというのはなるほど
- React本体がより低レイヤー的な、標準化とかそういう振る舞いになっていくことでフレームワークの責務が重すぎるなあ、という印象。メンテナンスが大変そうすぎる
Taiga KiyokawaProgressive Web Apps（PWA）は夢を見るか、夢になるか
- 登壇者：さざんか @sasanqua_dev さん
- 関東の大学生
- 初北海道、初登壇
- PWAの例：Qiita
- ブックマークとの違い
- アイコンの参照元が違う（PWAはManifetsで定義されたもの）
- app_idが指定される
- 独立ウィンドウで立ち上がる
- PWAの仕組み
- マニフェスト
- Web App Manifest を定義するとインストールできる
- サービスワーカー
- Service Workerでキャッシュを利用することでオフラインでも動作する（Network Independent）
- マニフェスト
- キャッシュ戦略いくつか組める
- ベストプラクティスは「キャッシュ更新付きキャッシュ優先」
- 既存のNext.jsプロジェクトにPWAを組み込む
- next-pwaを導入する
- マニフェストを設定する
- _document.tsxを設定する
- 「PWA」としての機能があるわけではなく、従来のWebアプリよりも優れた体験を提供するための手法
- Webだけでクロスプラとフォームアプリケーションが実装できるという夢
感想
- PWAは手軽に実装できるが、やはり問題はプラットフォーマーの利益にならないこととインストールの障壁（App Storeに載せられない）
- それこそEUとかデジタル庁とか公的機関が推進させていってOSネイティブの機能にアクセスできるAPIを生やしていってもらうしかないかも？分からない
- Google Play Storeには載せられるらしいというのは知らなかった。WebアプリのAndroid向け展開はこれで事足りそう？
Taiga Kiyokawaブラウザは「フロントエンド」を何から守っているのか？
- 登壇者：canalun @i_am_canalun さん
- 開発者もユーザーも攻撃が怖い
- ブラウザが守ってくれている、本当なのか？
- ブラウザが守ってくれている「フロントエンド」の攻撃経路
- オリジン完結：悪いページが直接攻撃
- オリジン横断：良いページに間接的に攻撃
- Line of Death：信頼できる/できないの境界線
- LoDだけではUI Spoofingは防げない
- ブラウザ頑張ってる
- UIの重なりを利用した攻撃が多い
- フィンガープリンティング、匿名で識別
- 匿名なら追跡されて良いかというとそうではない、再識別やマイノリティの特定など問題が
- FirefoxのRFP
- とにかく機能を削ぎ落とす
- HSTS Fingerprinting
- httpsのON/OFFでバイナリを形成して識別
- Braveは対策済み（Chromeも？）
- Same Origin Policy
- XS-leaks: 自サイトから他ドメインを攻撃する手段のひとつ
- COOPでWindow取得を防ぐ
- SOPでも意図的に防いでいない部分はある、COOPなどで防ぐ
感想
- 分からん世界すぎた。知らないことの博覧会で面白かった。結局インターネット怖い。
- 最新の自衛手段をもう少し勉強しようと思った。
Taiga KiyokawaAI時代のUIはどこへ行く？
- 登壇者：Yusuke Wada @yusukebe さん
- Cloudflare developer advocate
- Honoの作者
- AIとどうインタラクションしているか
- チャット
- AI時代の前はWebページの閲覧
- Webページ作らなくて良くなるの？
- 本当にチャットでいいのか
- チャットじゃなくてUIも欲しいシチュエーションはある（例：マップでの道順表示）
- Kent C. Dodds氏も同じような考え（今回の発表のベース）
- UIは必要で、やり方が変わってくる
- AIとUIの関係性の分類
-
- UIの中でAIを使う
- 例：スプレッドシート + Gemini
-
- AIがUIを作る
- 例：ChatGPTのグラフ機能
- ClaudeのArtifactsが面白い
- Claudeにアイディアを伝えるだけでアプリ、ゲームが作れる
- コードを見ると、React + Tailwind CSSで作ってる
- ギャラリーに公開できる、API呼び出しのコスト負担はユーザー
-
- AIがUIを受け取る
- MCPからUIを受け取る
- https://mcpui.dev/
-
https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/1146
- サーバーSDKとクライアントSDKを提供
- サーバーSDK
- HTMLを直接送る
- 外部URL（iframeURL）を送る
- クライアントSDK
- UIを描画する
- サーバーSDK
- デモ
- ラーメンAPI https://github.com/yusukebe/ramen-api
- ラーメン屋の一覧を取得、UIで表示、選択すると詳細を表示
- 行き方を地図で描画
- サーバーSDKとクライアントSDKを提供
-
感想
- パターン分けとそれぞれのアプローチの違いの説明が分かりやすかった
- Kent氏フロントエンドテストの人だと思ってたらいつの間にかAIどっぷりの人になっていた
- mcp-ui すごおお
- やっぱ自分で作って試してみないとなあという気になった
Taiga KiyokawaLT: すべてのinputに可視ラベルがあれば
- 登壇者：maiha @mf_dew2 さん
- SmartHR
- なぜ正しくラベルを設定することが大事か
- ユーザーが入力に迷うことを防ぐ：ユーザビリティ
- スクリーンリーダーなどにも情報を伝える：アクセシビリティ
- 誤入力・意図しない情報の入力を防ぐ：セキュリティ
- ラベルがないがちな要素
- 第一位：selectを使ったプルダウンメニュー
- ラベルをつけて改善
- ドロップダウンメニューに置き換える
- 第一位：selectを使ったプルダウンメニュー
- アクセシブルネーム漏れるあるある
- 分割されたinput
- 各インプットに設定する
- なるべく使わない
- 分割されたinput
- 本題！アクセシブルネームめっちゃつけるの難しかったUI
- （時間の関係でスキップ）
感想
- selectがラベルないがちなのは本当にそう
- 分割されたinputにも全部アクセシブルネームが必要、考えるのもコストかかるからなるべくやめようというのは確かに
- ここから本題！がめっちゃ聴きたかった
- スライド読んだ感じは主に分割input系の名前の付け方難しい的な感じだった
- 開始日/終了日に可視ラベル、個別でみたら必要なんだろうけど全体で見たら既にラベルがついているし...分からない
Taiga KiyokawaLT: 「手軽で便利」に潜む罠。 Popover API を WCAG 2.2の視点で安全に使うには
- 登壇者：Taito @taitotnk さん
- メディア企業のウェブエンジニア
- Popover APIのアクセシビリティ考慮できていますか？
- escキーで閉じる
- 表示/非表示をUAに伝える
- フォーカス
- 1.3.2 意味のあるシーケンス
- popoverのトリガーとコンテンツの間に関連しないコンテンツを記述している、これでも動作するが、読み上げ順序がおかしくなるリスク
- 2.4.11 隠されないフォーカス（最低限）
- popover="manual"は自前で閉じる機能を実装する必要がある
- 4.1.2 name, role, value
- popoverは対象のroleに影響しない → 適切なセマンティクスは実装者が考慮する
感想
- Popoverだけで考慮が全て済むわけじゃないのは本当にそう
- Popoverに限らず最近のモダンなAPIとかHTML要素はどこまで担保してくれてどこまでは実装者の責任なのか、実装者はきちんと境界を理解しないといけない
Taiga KiyokawaLT: iPhone Eye Tracking機能から学ぶやさしいアクセシビリティ
- 登壇者：Kaito Fujimura @fujiyamaorange さん
- マネーフォワード
- iOS 18からiPhone Eye Trackingが利用可能に
- AIを使った視線操作のアクセシビリティ機能
- 操作に工夫が必要
- スクロール操作ができない
- スライダーUIも厳しい、アナログ的な操作
- Eye Tracking視点から考える実装
- 要素の間隔を広げる
- スクロール操作に対する工夫
- Eye Trackingの未来
- アクセシビリティに限らず、ヘッドマウント型デバイスの台頭により今後も勢いは止まらない
- 標準化されてほしい
感想
- 知らない世界で面白かった。考慮点自体は細かいポインタ操作が困難な利用状況向けの考慮に近そう
- また新しい操作形態が出てきた！と思ったけど結局モバイルで使いやすいように作るのとあまり変わらないかも？いやでもスクロール操作とかスライダー操作とかはモバイルデバイスが得意な領域なのでまた別の考慮が必要になってきそう
- あるいは今後の標準化や機能拡張の次第ではスクロールとかはいい感じに他の操作と共存できる仕組みになりそう
Taiga KiyokawaLT: おじいちゃんに優しいUIを作ってみた
- 登壇者：しょうた＠なつみかん @nano72mkn さん
- スターフェスティバル
- 視覚能力の低下
- 老眼
- コントラスト感度
- 走査速度
- 運動コントロール
- 手先の器用さ
- 手と目の協調能力
- 認知能力
- 短期記憶（ワーキングメモリ）
- フォントサイズ
- 16px以上（Health Literacy Online基準）
- コントラスト
- タッチ領域
- システムフォントサイズを大きくしていたケース
- 拡大の上限を設定する
- レイアウトを切り替える
感想
- おじいちゃん関係なく使いやすいUIの話だ
- フォントサイズWCAGではっきりしてほしい〜と思ってたけどHLOで定められていることを知らなかった。というかHLO自体知らなかった。今後これ使っていこう。
- あとHLOちゃんと読んでおこう。
- と思ったらシステムフォントを拡大しているケースは確かにおじいちゃんというかシニア向けは特に気をつけたいポイント
- 上限を設けるのはどうなんだろうか、フォントサイズが大きくなりすぎているのが意図せずなのか意図的なのかは利用者によりけりな気もする
- レイアウトを切り替えたりきちんとテストして確認したりしよう、はほんとそう
このスクラップは2日前にクローズされました