Kaigi on Rails 2024
day 1
スポンサーLT
DeNA
秒間100万req
GMO
minneのShoryuken活用
ActiveJobのインタフェースで使える
クラシル
9年目
Rails Engineを活用
AWS Bedrock API
基調講演
Rails way, or the highway
anycable
ruby-next
test-prof
action_policy
Rails commiter 10周年
The Rails 4 Wayという本がある
Rails wayはRailsアプリケーションを構築する哲学
rails new するだけで手に入る
Rails 8
ゼロからイチへの最適化
「イチ」を超えることの課題
アプリケーションが成長すると素朴なMVCモデルでは無理が出てくる
怪獣 on Rails
Railsは構造を与えてくれる
Rails wayは道しるべ
Railsを他のものと混ぜるのではなく拡張する
フレームワーク作者の考え方を持つ
レイヤードアーキテクチャの原則が参照できる
介入より抽出
関心事と複雑さのレベルを分離する
Queryパターンっていうのが使われていたらしい
学習機会をなめらかに保ちつつ、学習する機会も残しておく
実例
フォームをウィザードにする
ステップの状態をcontrollerに持たせる?
Rails wayじゃなくなる
Form object
ステートマシン
すべての抽象化にはベースクラスが必要
scaffoldしたコードに似ていく
フレームワークと戦わない
Railsの仕組みを理解してモデルを上手に育てる - モデルを見つける、モデルを分割する良いタイミング -
モデルの見つけかた
設計例
メインとなるテーブル名を出す
「誰が・何が」
「誰を・何を」
イベント型モデル
行為を記録するモデル
モデルの名前に「〜する」をつけると行為になるもの
例
order
shipment
payment
入荷処理でのイベント型モデルの例
Stock
BankAccount
イベント型モデル Arrival
できるだけRails wayに乗っていきたい
PORO
Plain Old Ruby Object
何も継承していないただのクラス
責務がしっくりくるモデルが作れないとき
テーブルに保存しなくてよいとき
POROにルールをつくる
理想
チームメンバー全員 (このあと入ってくる人も含む) が同じ場所を指す
迷うことを減らす
「クラス名には返すオブジェクトの名前を名詞でつける」
POROの例
ECサービスのカート
POROとしてのCartクラス
将来データを記録したくなったらモデルに変更してもよい
Service層はおすすめしない
Railsは密結合志向
代わりに
イベント型モデルを探す
POROを導入する
ビジネスロジックをモデルとServiceのどちらへ書くか迷いやすい
モデルを分割する良いタイミング
fat model
コード行数だけで判断すると失敗する
「太っている」とは?
そのまま書き続けるとしんどくなる
そのタイミングで良い分割方法がある
バリデーションを条件分岐したくなったとき
モデルのバリデーションはDB用とフォーム用があり、validatesメソッドが共用されている
DBと違う検証がしたくなることがある
そこでFormObject
時間経過とともに良い設計が変わってくる
つくりかた
ActiveModel::Model
ActiveModel::Attributes
Rails 7.0以降はActiveModel::API
どっち使ったらいいの?
transfer_attributes
モデルと同じ書き味にする
推し活としてのrails new
お面をかぶっている状態なら撮影OK
マシュマロを介した匿名コミュニケーション
Railsアプリケーション
機械学習部分はPython
マシュマロの仕様変更
匿名ユーザーの間に差ができる
他サービスも検討したが却下
自分が作れるやん、という気づき
最低限の機能だけ作る
構想から完成まで5日
LettersController
Admin::LettersController
ユーザー管理を作らない
BASIC認証でやる
仲間集め
Discord
アスキーアートで炙り出し
SaaS
MOGOKはもう
ロリポップ！マネージドクラウド
監視してない
バックアップしてない
さまざまな方向から要望
目安箱を作る
無理をしない
作ったはいいものの人が集まらないサービスもある
休日に同人誌を書くのと休日にコードを書くのは同じ
Sidekiqで実現する長時間非同期処理の中断と再開
(2024/10/25 14:40 途中からききはじめた)
長時間非同期処理において中断・再開処理は必須
中断処理から
ジョブの進捗を保存しながら処理を進行
Redisに保存する
Sidekiqの設定ファイルにイベントハンドリングを設定
Sidekiqの停止を検知したら例外を送出
再開処理
進捗管理の方式が2つ
ID番号保持形式
行番号保持形式
主にCSVインポート
行ごとに複数のエラーが発生する可能性がある
エラーメッセージにZADDでスコアをつける
実行時間が短い & ファイル容量が小さい
中断のみで十分
実行時間が長い & ファイル容量が大きい
数時間レベル
デプロイに影響が出る
大きい一時ファイルをどこに保存するか
オブジェクトストレージ
中断・再開処理のテスト
and_wrap_original を利用して中断を再現
Sidekiq Iteration
Sidekiq公式に中断・再開がサポートされた
2024/10/20 時点でbeta
コールバック
cXML という電子商取引のトランザクションを支えるプロトコルと向きあっている話
電子商取引に関するシステム間連携のプロトコル
購買システム
多様な取引先からの購買業務を一元管理
複数のECサイトと連携する
commerce eXtensible Markup Language
パンチアウト連携
ECの機能を使いながら購買の情報を連携
チェックイン
BuyerCookieをもとにユーザーを特定
リファレンスが600ページ
実際に発生した問題と学び
各接続先で異なるcXMLの仕様が異なる
Extrinsic
連携先と仕様の認識をすり合わせる
物理的な制約
配送先の文字数
伝票
連携のシナリオテスト
そもそもcXMLの仕様すべて対応できているわけではない
同一商品を複数個注文した内の一部キャンセル
ConfirmationStatusはいつも1つ、じゃない
仕様上は複数回使えるがgemが想定していなかった
cxml-rubyのパース結果
外部イベントのロギングにより再現と原因の究明ができた
Hotwire or React? 〜Reactの録画機能をHotwireに置き換えて得られた知見〜
Rails + Reactで部分的にSPA
この規模のサービスにReactは本当に必要か?
Reactをやめるのは怖い
Turboのイメージ
Stimulusの情報があまりない
録画機能を置き換えてみる
Stimulus
Turboと相性がよいJavaScriptフレームワーク
JavaScriptをいっぱい書くことになりそう
プロポーザルを出した当時の結論
苦がなかった理由は?
Reactに関する知識が必要ない
StimulusコントローラーにJavaScriptのロジックが集中している
Turboに寄せるといい?
Web紙芝居
Turboで作るところとStimulusを活かすところ
全てのコードをcontrollerに書いていたときよりもJSのコードが少なくなった
CRUD操作が主体 + 補助的なJSがある ぐらいならHotwireでいいだろう
複雑なインタラクションがあるならReactがいい
ユーザーが長時間滞在するページの実装方針にまだまだ議論の余地がありそう
実装をCRUDに集約できそうか
day 2
都市伝説バスターズ「WebアプリのボトルネックはDBだから言語の性能は関係ない」
2024/10/26 10:18 途中から
言語の性能は関係ある!!
リクエストが100% I/Oなら言語間の差は小さい
I/O比率を調整する
Railsのデフォルトのスレッド数が5→3になった
I/O比率が80%もあることはそうないだろう
Rubyではスレッド数が多ければよいというものではない
GVL
仮説を立てて検証したい
I/O比率を見る
CPUを使う処理を減らす
JSON.parse
mysql2
libmysqlclientがCPUを使っている
Trilogyに置き換えたら10%速くなった
Rack::Session
Cookieのデシリアライズ
いろいろなレイヤで計測したらよい
GVL wailtを直接計測して最適化したらよいのでは?
AutoPumaTuner
頓挫
M:N threadsを実用的に使ってみたい
Cache to Your Advantage: フラグメントキャッシュの基本と応用
フラグメントキャッシュとは
ページの一部をキャッシュする
キャッシュの失効を手で行うのは困難
キーベースのキャッシュ失効
キャッシュキーにupdated_atを含める
キャッシュキーに変わりうるものを含める
フラグメントキャッシュをページ全体に適用する
ActionCacheとほぼ同じ
session, cookieに依存したものをキャッシュ内で参照してはいけない
CSRFトークンを使わないCSRF対策
キャッシュできない部分をTurbo framesで通す
推し活のハイトラフィックに立ち向かうRailsとアーキテクチャ
ライブイベント向けOEM型モバイルオーダーアプリ
マルチテナント
内製向けローコード
負荷対策
事例がなかなか公開しづらい
WebView
シンプル・モノリシックなRailsアプリ
CDNに5万rps、アプリケーションに8,000rps
決済に660rps
スロークエリにならないように
最初からキャッシュ前提
DBレベルのボトルネック
外部APIのレートリミット
ALBのスケーリングが間に合わない
特定条件だけ遅いときはアプリケーションログを見る
先着販売の事例
在庫確保
行ロックを導入する
正確になる
数百rpsのワークロードではロック待ちが頻発
同じデータを同時に書き換えないような構造に変更する
1行1在庫
FOR UPDATE SKIP LOCKED
ロックされている行を読み飛ばす
足りなかったら在庫不足
Solid Queueでも活用されている
行数が肥大化する
用がなくなったら消す
200万在庫をさばいた実績あり
外部ペイメントプロバイダ
レートリミットが20-30rps程度
オーソリを取ってから在庫確保
在庫が復活すると苦情が出る
売上確定時にレートリミットでロールバック
誰も買えない
正しく諦める
決済システムの限界よりもリクエストを受け付けないようにする
レートリミットを導入
CDN/WAFも検討したが
条件制御が単純
高い
Redisでやっていく
DBへのアクセスを減らすことにも
負荷試験で外部APIをモックするときはレートリミット時の挙動も考慮する
入門『状態』
オブジェクトにまつわる状態を起点とする
電球の例
電気がついているかどうか
明るさ
変化を繰り返すと追いづらくなる
変化の幅が大きいと考慮点が多くある
状態のつらさを抑えていく
再代入させない
状態を少なくシンプルに保つ
Railsでの状態のいなし方
用途が迷子になったcontrollerインスタンス変数
Sidekiq vs Solid Queue
バックグラウンドワーカー
リトライできる
RailsではActiveJob
ActiveJobアダプター
Sidekiqを直接使うほうがいいのでは、という説
Solid Queue
Rails 8.0のデフォルトバックグランドワーカー
バックグラウンドワーカーに求める前提が分かっていれば悩まなくなる
Rails向けバックグランウンドワーカーの歴史
ActiveJob以前
BackgrounDRb
2006-
dRuby
Delayed::Job
2008-
Shopify由来
MySQLをバックエンドにしたときの性能低下問題
Resque
2009-
Redis
Sidekiq
2012-
Resueと比べてメモリ効率がよい
商用版がある
Active Job
2014-
バックグラウンドワーカー処理への共通インタフェースができた
他のRailsコンポーネントから非同期処理を扱えるようになった
Sidekiqを直接使う説について
ActiveJobのアダプタとして使うとライブラリの機能を完全には使えないケースがある
Batches機能
重複している機能がある
リトライの仕組みがActiveJobにもSidekiqがある
仕様を理解していないとハマる
GoodJob
2020-
PostgreSQL
ActiveJobのアダプタ前提
Cron, Batch, 同時実行制御
advisory lock
pg_try_advisotry_lock
Solid Queue
2023-
ActiveRecord
ActiveJobのアダプタ前提
Solid Queue誕生のきっかけ
HEYにおけるResqueの不満
HEYのユースケースを満たすためにgemを自作・拡張
Solid Trifecta
RedisをやめてDBへ
ディスク性能が向上している
RAMよりディスクのほうが安い
One Person Framework
SKIP LOCKED
シンプルなクエリ
ロック問題を解決できる
バックグランウンドワーカの選定
Sidekiqの特殊な事情
仕事で使うならProを使う必要があるだろう
$995/year
信頼性を高めるための機能
実際にはEnterpriseを推奨
$229/month
cronなど
ストレージ
Solid Queueはジョブ専用のDBを持つが相乗りできる
大量のジョブを扱うサービスであればSidekiqに優位性がある
Solid Queueで2000万job/dayはいける
HEYでやってる
Sidekiqだと2万job/sの実績あり
Redis互換のDragonflyも利用可能
インタフェース
Sidekiqを直接使う説
Solid QueueはActiveJob前提なので迷わない
機能
Solid QueueはHEYが求める機能を持っている
SidekiqにあってSolid Queueにない機能
Batch
複数のジョブをバッチという単位でまとめる
バッチのジョブ全体が終わったことをきっかけに発火するコールバック
Rate Limiting
同時実行制限
Encryption
Redisに渡すデータの一部を自動的に暗号化・復号する
Web UIで見えるとまずい情報を見えないように
SidekiqからSolid Queueに移行したほうがいいか?
移行のメリットとコストを比較して決めましょう
小規模なサービスでRedisの運用コストを減らすとかはあるかも
新規で作るときは?
ジョブをあまり使わないならSolid Queueでよい
ジョブをたくさん使うならSidekiq
Sidekiq特有の機能の中で便利なものがあるかを探して決める
サービスが育ったあとの移行?
ginza.rb
Importmapを使ったJavaScriptの読み込みとブラウザアドオンの影響
Webpackerがdeprecatedになったので移行する
js-bundling-rails
Webpackとかを使う
そもそもImport mapsとは
import時のパス・URL解決
ビルド不要になる
いままではバンドリングが必要だった
importmap-rails
config/importmap.rbに書く
module preloadしてくれる
なぜRails 7からデフォルトになったのか
Babelでのトランスパイルが不要になった
HTTP2
1つのJSファイルにまとめなくてよい
Webpackerからの移行
Webpackのままjs-bundling-railsを使うか?
Webpackは遅い
importmap-railsを使うか?
ビルドツールがいらないかどうか
TypeScript使ってなかった
Vue.jsはStimulusに移行する方針で決まった
No buildが最速
しばらくしてサーバーサイドに奇妙なエラー
Turbo stream形式で来るべきリクエストがHTML形式になっている
Turboが動いていない?
エラートラッキングサービスに通知なし
最新のブラウザで起こっている
アドオンか?
Adblockを入れるとエラーになる
エラートラッキングサービスへの通知JSが遮断される
フィルターリストの中に入ってた
EasyPrivacy
ブラウザでいろいろやるのでユーザー環境の影響を受けやすくなった
vendorディレクトリにダウンロードする
importmap-rails v2でデフォルトの挙動になった
SprocketsかPropshaftでフィンガープリントをつける
ひきつづき外部CDNも使っている
1つのエントリポイントに機能がまとまっていない場合がある
importmap-railsでは依存ファイルを持ってこれない
Adblockにブロックされるかもしれない
主要な機能のTurbo Streamリクエストに形式チェックを入れる
nodelessにできていない
ESLint
Playwright
Data Migration on Rails
広義のdata migration
理想追求のために生み出されているツール群
データマイグレーションの部分にピースがあいているのでは
Railsコミュニティにおける data migration
狭義のdata migrationを指すことが多い
schema migrationとは別物
スキーマ変更に伴いデータを埋める
問題のリカバリ
課題
オペミス
長時間のdata migrationによる障害
学習コスト
Rails wayがない
アプローチいくつか
SQLによる直接データ操作
モデルのcallback, validationが実行されない
権限管理
SaaSや専用ツール
raiils console, rails runner
対話的
クラスを介してupdate
なんでもできてしまう
db:migrateと同時に実行
既存のデプロイフローに乗れる
実行ログが残る
schem migrationとdata migrationのライフサイクルのミスマッチ
特定の環境だけで実行したい
テーブル定義が変わると壊れる
GitLabの事例
rake task, ruby script
テスト書ける
rails runnerでもほぼ同等のことができる
専用gem
様々なアプローチが生まれては消えた
data-migrate
2011-2024
data_migrator
2011-2019
migration_data
2014-2020
rails-data-migrations
2016-2024
active-data-migrations
imigrate
datafix
rails_data_fix
seed_migration
seed_migrator
nondesctructive_migration
nonschema_migrations
強いて選ぶならdata-migrateかな〜
Railsのinternal APIへの依存に注意
maintenance_tasks
ダッシュボード
ジョブの一時停止・再開が可能
社内外でアンケートを取った
2020
2024
依然としてrake taskが優位
Rails consoleやdb:migrateが減った
Rails discussionでアンケート
国内とほぼ同じ傾向
Rails本体では?
Basecampではruby scriptを実行している
Rails 8では rails g script コマンドが使える
Rails Guide
7.1以前と7.2以降で路線が変わった
なるべくデータの変更とスキーマの変更は切り分けましょう、という路線
maintenance_staksが推薦されている
data migrationを安全かつ予測可能な方法でロールバックすることは困難
アプローチ選定のポイント
トレードオフがある
チーム・プロジェクト固有の変数
ノックアウトファクター
seedを含めるかどうか
seedは羃等にしておくとよい
羃等
ロールバック可能かどうか
どういう実践をしたか
データ不整合を生まない・オペミスを避けることを優先
rake taskを書いてレビューを必須とする
ワンショットなジョブを実行する
Apache Airflowをセルフホスト
Goのアプリケーション側は更に複雑なルールがある
実行管理のしにくさ
個人的にmaintenance_tasksを検討中
SQSのvisibility timeoutの制約
データマイグレーションのみSolid Queueにするとか?
30万人が利用するチャットをFirebase Realtime DatabaseからActionCableへ移行する方法
メッセージの一斉送信がユーザー数増加に伴い遅延してしまうという問題があった
patoのチャット機能
創業当時 (2017) からFirebaseを利用
us-central1
当時はこれしか選択できなかった
ボトルネックと技術選定
リージョン
どうしてもレイテンシが発生する
1,000req/sという制約
Firebase Realtime Databaseの制約
並列化に限度がある
FCMでプッシュ通知を送る
MySQLやFirebasre Realtime Databaseへの書き込みを待ってから送る
firebase-ruby
メンテナンスが行われていない
代替案の検討
Firestore
書き込みスケーラビリティが良い
料金が高い
Cloud Pub/Sub
再送
ストレージ料金
Action Cable
実装が楽
インフラメンテ
料金が高くなるのはよくない
ベンダーロックを避けたい
大規模なチャットサービスでのAction Cable採用事例を作りたい
リリースまでのロードマップ
データ移行
よくわからないKeyがめちゃくちゃ生えてる
BigQueryに移すことで必要なデータだけ残せた
ダウンタイムなしで移行したい
talksテーブルそのものの移行ではなく、talk_optionsテーブルを作って移行する
flipper gemを利用
ActionCableのコネクションが30秒で切れてしまう
連続でメッセージを送るとデータがロストしてしまう!!
タイムアウトを伸ばせばいい?
コストがかかる
再接続時に足りないデータを再送することで解決
ギフト機能
チャット機能の一部
即時決済
メッセージ送信側はコネクションのことを気にしたくない
送信者はAction Cable経由ではなくPOSTリクエストで対応
同時接続の安定化
Threadの方がメモリ効率がいい
スレッドを増やして同時接続数を増やした
ビジネスメンバーから好評
残された課題
INSERT時にRETURNINGが使えない
LAST_INSERT_ID
トランザクション張ってないと使えない
ActionCableのスタンドアロン化
サイロ化した金融システムを、packwerk を利用して無事故でリファクタリングした話
Coincheck
バックエンド部分の現状と課題
サービス開始から10年
複雑でモノリシックなコードになっている
ユーザーステータスに応じた取引可否の判定が必要
条件がとても複雑
判定箇所が40箇所以上ある
「認可ロジックの散在」
サービス横串の仕様が分かりづらい
認可ロジックの集約・インタフェースの統一
どう集約するべきか
インシデントは金融庁報告につながる
アーキテクチャをなるべく大きく変更せず集約したい
モジュラーモノリス
packwerk
Railsアプリケーションのモジュラーモノリス化を支援するツール
静的解析
パブリックアクセス領域の設定
コード移動のみでモジュール化が実現できる
package.ymlが置かれたディレクトリ配下を1つのパッケージと認識
今回は依存を許容する
packwerk-extensions
packwerkで検知する違反を拡充させるgem
認可ロジックへの直接参照を制限する目的で有効化
packs-rails
パッケージ化したコード類をzeitwerkのオートロードパスに自動で乗せる
認可ロジックを集約した認可パッケージを作る
直接参照されたくない認可ロジック自体は非パブリックなクラスに集約
CIで違反検知
導入後の評価
既存動作に極力影響を与えない設計にメリットがある
内部で何をやっているのか掘り下げる
モジュラーモノリス構造・パッケージ化を安全・低コストに試せる
packwerkで防ぎきれない観点
モノリス側で再び同じようなロジックを作成されることを機械的に防げない
全体認知の徹底
カスタムcop検知で監視する
今後の展望
機能のパッケージ化を進めていく
仕様の明確化・ドメインロジックの複雑度低下ができた
Type on Rails: Railsアプリケーションの安全性と開発体験を型で革新する
型システム導入の動機
もっと気持ちよくRailsを書きたい
nil考慮漏れなど
実行しないと問題が機械的にわからない
RBI, Sorbet, Tapioca
型定義がファイル内に書ける
Tapiocaについて
Sorbetの導入手順
エラーの修正がたいへん
公式ドキュメントのError Referenceを見て直していく
モデル数200以下なら慣れれば2〜3日ぐらい?
Strictness level
最初はtrueかfalseがおすすめ
値レベルの検査から
ランタイムの型エラーは例外にしない
今まで動いていたコードが動かなくなってしまうのは避ける
call_validation_error_handler
Sentryに通知するのみ
LSP
CIでチェック
型システムを活かした設計・実装
型は内側からつけていくのがよい
lib/, app/lib
Model
Service, FormObject
Controller
よく使われるメソッド・自明ではないメソッドから型をつける
untypedを減らす
パターンマッチングを使う
例外の代わりにResult型を使う
Tapioca DSL Compiler
Railsで使うようなものは大体網羅されている
かなり柔軟に型がつけられる
enumに型をつける
Result型
mangrove gemを作った
便利な型を定義する
スポンサーLT
TwoGate
学生旅費支援プログラム
Shopifyを活用している
X Mile
自宅のワンルームからスタート
ノンデスク産業
ロジポケ
YOUTRUST
rails statsでコードとテストの比率が見れる
テストが手元で6分で走りきる
CQSを採用
KAIZEN Day
自社テックカンファレンス
基調講演
全体性、修復、そして楽しむこと
飛び込みバイト
「RailsによるアジャイルWebアプリケーション開発」
当時はWeb開発でない開発をやっていた
つらかった
Web2.0
えにしテック
ソフトウェアを設計する際に大事だと考えていること
全体が機能するように設計する
アプリケーションを綺麗に作れたらそれで完成、ではない
運用に伴う困りごと
いいアプリケーションができてもユーザーに信頼してもらい使ってもらえないといけない
システムとして見る、という視点
ソフトウェアアーキテクチャの探求
解答はまだない
アプリケーション開発者がシステムを意識して作れるようにする
システムコンポーネントを知る
アプリケーション開発をしているとシステムを単純化して見てしまいがち
物事の正確な観察が必要
なんでもアプリケーションだけで解きたくなる
設計のパターンを知る
Webシステムのよくある質問と解決策
現実世界の問題を1つずつ解いていくことの積み重ね
最初から構造があるわけではない
自分のアプリケーションを取りまく要素について勉強していくところから
変化に向けて設計する
設計の開始時点はもっとも何も分かっていないタイミング
不確実性
前提が分かりきっていない中でも設計を進めていかなければならない
オプションを手に入れる
「将来的な選択肢を買う権利」のオプション
オプション取引
振る舞いを変更する準備
環境が不安定であればあるほどオプションの価値が高まる
オプションのための設計とは?
何にでも対応できるような構造やしくみを作る?
それ以外の選択肢を捨てていることになる
シンプルに作る
選択肢を広げようとするのではなく、狭めないように作る
標準の道具・標準の方法で、必要十分に作る
解きたい問題を標準的に作ることで十分対応していける
Railsはオプションのための設計をサポートしてくれるフレームワーク
omakase
本当に必要になるまで複雑な仕組みを避けられる
Railsの思想に乗る
標準のやり方を維持するのがまた難しい
将来の変更に向けた設計が破られてしまう
「時を超えた建設の道」24章
ここでの「修復」
「元の状態に戻す」ではなく「変わった後の全体と再度調和させる」
Railsは変わっていってるけど手触りは変わらない
Webの標準が変わっていくので、それに合わせて適応していく
修復が必要な箇所に気づくには?
単にバグがあるから直しましたではない
Process Feel
複雑なシステムの状態を直感的に理解する
Process Feelを養うには?
複雑性によるオペレータの認知負荷をいかに減らせるか
概念圧縮
システムの複雑性による開発者の認知負荷をいかに減らせるか
The One Person Framework
Railsの上手な使い方を学んでいく
何も複雑なことをせずに、淡々と整理していく
難しいことを楽しそうにやっている
エネルギー
クロージング
プロポーザルの倍率は5倍
オフライン参加 692人
去年の1.5倍
2025
JP TOWER Hall & Conference
東京駅直結