日記

はじめに

Google Chrome には、タブを画面上部ではなく左サイドバーに縦並びで表示する「縦タブ（Vertical Tabs）」機能が実験的に搭載されている。Microsoft Edge では早くから標準機能として提供されており、Chrome でも chrome://flags から有効化できるようになっている。

タブを多数開く人や、ワイドスクリーンモニターを使っている人にとって、縦タブは作業効率を大きく向上させる。本記事では、有効化の手順と使い方を解説する。

縦タブとは

通常の Chrome では、タブは画面上部に横一列で並ぶ。タブの数が増えると一つひとつのタブが狭くなり、タイトルが読めなくなる。20個も開けば、もはやアイコンしか見えない状態になる。

縦タブを有効にすると、この問題が解消される：

• タブが左サイドバーに縦に並ぶため、タブの数が増えてもタイトルが省略されにくい
• タブタイトルが常に文字で表示されるので、目的のタブを素早く見つけられる
• タブバーが上部からなくなる分、縦方向の表示領域が広がる
• サイドバーは折りたたみ可能で、必要なときだけ展開できる

動作環境

• 対応 OS：Mac、Windows、Linux、ChromeOS
• Chrome バージョン：最新版を推奨（実験的フラグのため、バージョンによってはフラグ自体が存在しない場合がある）

設定手順

Step 1：フラグページを開く

Chrome のアドレスバーに以下を入力して Enter を押す。

chrome://flags/#vertical-tabs

「Vertical Tabs」の項目が黄色くハイライトされて表示される。

上のスクリーンショットのように「Vertical Tabs」がハイライトされ、右側のドロップダウンから設定を変更できる。

Step 2：「Enabled」に変更する

「Vertical Tabs」の右側のドロップダウンをクリックし、「Enabled」 を選択する（初期状態は「Default」）。

フラグの説明文には以下のように記載されている：

Enables an option for showing tabs to the side. – Mac, Windows, Linux, ChromeOS

Step 3：Chrome を再起動する

変更後、画面下部に青い「Relaunch」ボタンが表示される。これをクリックすると Chrome が再起動し、縦タブが有効になる。

有効化後の使い方

再起動後、左サイドバーにタブが縦並びで表示されるようになる。

サイドバーの表示切り替え

• ウィンドウ左上に表示されるサイドバーの切り替えアイコンをクリックすると、表示・非表示を切り替えられる
• もしくはタブバー上で右クリック→「タブをサイドに表示」を選択する

サイドバーの折りたたみ

サイドバーが邪魔なときは、左端の矢印ボタンをクリックすると縮小（アイコンのみ表示）できる。再度クリックで展開する。

元に戻す方法

縦タブをやめたい場合は、再度 chrome://flags/#vertical-tabs を開き、ドロップダウンを「Default」に戻して Chrome を再起動する。これで通常の横タブに戻る。

Edge の縦タブとの違い

Microsoft Edge の縦タブは標準機能として完成度が高く、タブグループのネスト表示や自動折りたたみなど細かい設定が揃っている。一方、Chrome の縦タブは実験的機能であるため、以下のような違いがある：

とはいえ、Chrome の縦タブも日常的に使う分には十分実用的である。

まとめ

Chrome の縦タブは chrome://flags/#vertical-tabs から 1 分もかからずに有効化できる。タブを多数開く人や、Edge の縦タブに慣れていて Chrome でも同じ操作感がほしい人にとって、試す価値のある機能である。

実験的フラグであるため、Chrome のアップデートで無効化されることがある。その場合は同じ手順で再度 Enabled に設定すればよい。

アプリをリリースするとき「とりあえず Android から」「会社なので iOS だけ」と決めていないだろうか。世界規模で見ればそれでも成立するが、日本市場ではその判断がユーザーの 40〜60% を最初から捨てている。

上のグラフが示すとおり、日本と世界では iOS/Android のシェアが完全に逆転している。

日本と世界、シェアの逆転

世界のモバイル OS シェアは Android が圧倒的多数を占める。StatCounter のデータ（2025年1月〜2026年3月）では Android 72.1%、iOS 27.6% と約 3:1 の差がある。インド・東南アジア・アフリカ等の低価格 Android 端末の普及が主な要因だ。

一方、日本は iOS 60.7%、Android 39.1%。iOS マジョリティの希少な市場の一つである。

出典: StatCounter Global Stats（Jan 2025 – Mar 2026）/ 米・英は同期間の推計値

なぜ日本は iOS が多いのか

要因自体は根深く、短期間で覆るような変化は起きにくい。しばらくはこの構造が続きそう。

iOS だけ・Android だけ対応の損失試算

仮に日本向けアプリを iOS のみでリリースした場合、Android ユーザー約 39% にリーチできない。逆に Android のみであれば iOS ユーザー約 61% を逃す。

業務系アプリ・BtoB ツール・社内システムでは「社員の一部がアクセスできない」は致命的になる。コンシューマー向けであっても、ストア評価や口コミの分断を招く。

どう動くか

ネイティブ実装を前提にする

両 OS 対応の手段として Flutter や React Native が話題に上がることは多いが、大きなプロジェクトではクロスプラットフォームのコストはかえって増える。各 OS の最新機能への追従、プラットフォーム固有のバグ対応、エンジニア採用という三点だけでも相当な重荷になる。ハリボテでいい期間限定キャンペーンアプリなら選択肢に入るかもしれないが、それ以外では iOS / Android それぞれのネイティブ実装が現実的な王道だ。

iOS 26 対応と Android 16 対応を並行して進める

2026年は両 OS にとって節目の年だ。

• iOS 26: App Store Connect への提出に 2026年4月28日から Xcode 26 + iOS 26 SDK が必須（⚠️ 施行中）
• Android 16: Google Play の targetSdkVersion 強制更新ロードマップで 2026年中に targetSdkVersion 36 への対応が求められる

「iOS 26 対応が終わったら Android」という直列スケジュールでは間に合わない。両プラットフォームのアップデートを並行管理するチームプロセスを作るほうが現実的。

各 OS の対応詳細は別記事で。

• iOS 26 の対応優先順位 → iOS 26 対応を今すぐ終わらせる
• Android 16・17 の対応優先順位 → Android 16 対応とAndroid 17先回り確認

App Store Connect へのアップロードには、2026年4月28日以降 Xcode 26 および iOS 26 SDK でのビルドが必須になる。iOS 26 は 2025年9月にリリース済みで、WWDC25 発表の Liquid Glass デザインや Foundation Models framework を含む大型アップデートだ。続く iOS 27 は WWDC26（2026年6月8〜12日）で発表され、2026年9月リリース予定。この2バージョンを同時に見据えた対応順を書く。

App Store SDK 要件のスケジュール

Apple は毎年、App Store Connect への提出に必要な SDK バージョンを引き上げてくる。

出典: <https://developer.apple.com/news/upcoming-requirements/>

iOS 26 SDK でビルドしないと、アプリアップデートを App Store Connect にアップロードできなくなる。新機能の話ではなく、既存ユーザーへの配信継続のための義務対応。

iOS 26 対応の優先順位

ツールの足場をそろえる

iOS 26 対応でも iOS 27 先行検証でも、最初に詰まるのは OS の API より build 周りのことが多い。足場を先に固める。

Swift 6 モードへの移行で一番よく出るのは CoreData 周りの並行性エラー。NSManagedObject を @MainActor 外から触ると警告が出るようになっているので、context.perform ブロックの中に閉じ込める形で直す。

actor DataProcessor {
    func process(context: NSManagedObjectContext) async {
        await context.perform {
            // CoreData 操作は context.perform 内で
        }
    }
}

iOS 26 で引っかかりやすい動作変更

TLS 最低バージョンの変更

iOS 26 SDK にリンクしたアプリでは URLSession と Network framework の TLS 最低バージョンが 1.0 から 1.2 に変更される。

社内システムや外部 API が古い TLS 設定のままだと、iOS 26 SDK でビルドしたアプリから通信できなくなる。

// 旧 TLS を許容する例（非推奨。やむを得ない場合の一時対処）
let config = URLSessionConfiguration.default
config.tlsMinimumSupportedProtocolVersion = .TLSv10 // 警告が出る
let session = URLSession(configuration: config)

本来は接続先サーバー側を TLS 1.2 以上に直すのが正しい対応。サードパーティ SDK 経由の通信も含めて確認しておくといい。

UIScreen.mainScreen の廃止

以前から非推奨だった UIScreen.mainScreen が iOS 26 SDK で deprecated に昇格した。マルチウィンドウ・iPadOS のシーン対応との互換性のため、画面サイズは UIWindowScene から取得する方式へ移行する。

// Before（非推奨）
let screenWidth = UIScreen.main.bounds.width

// After（推奨）
if let scene = UIApplication.shared.connectedScenes
    .first(where: { $0.activationState == .foregroundActive }) as? UIWindowScene {
    let screenWidth = scene.screen.bounds.width
}

Push to Talk entitlement の変更

com.apple.developer.pushkit.unrestricted-voip.ptt entitlement が iOS 26 SDK では動作しなくなる。iOS 16 以降の Push to Talk framework への移行が必須。

CoreData の iCloud 同期キー削除

NSPersistentStoreUbiquitousContentNameKey など、10年以上前に deprecated になっていた iCloud ubiquitous 同期用キーが iOS 26 SDK でビルドエラーになる。移行先は NSPersistentCloudKitContainer（iOS 13〜）または SwiftData（iOS 17〜）。

Liquid Glass デザインへの適応

標準の UIKit / SwiftUI コンポーネント（ナビゲーションバー、タブバー、シートなど）は自動的に新デザインに適応する。独自描画のカスタム UI は、背景ブラー・グラスエフェクトとの重なりを実機で視覚確認したほうがいい。

iOS 27 先回り確認（WWDC26 は 2026年6月8〜12日）

WWDC26 は 2026年6月8〜12日。例年どおり初日に新 OS が発表されて Beta 1 が公開される。iOS 27 のリリースは 2026年9月の見込み。

iOS 26・27 同時対応のテスト優先度

日本の業務アプリで引っかかりやすいところ

上げる前に見るところ

まず古い API を雑にでも洗うのが早い。

grep -R "UIScreen.mainb|unrestricted-voip.ptt|UbiquitousContentName|UbiquitousContentURL" ./

TLS 周りも同様に引っかけておくと見落としが減る。

grep -R "TLSv10|TLSv11|tlsMinimumSupported|kCFStreamSSLLevel" ./

swagger

API開発で設計したDocment管理として使用できサンプルコードとしてJSONにしてくれて、よしなにPostmanみたいな動きしてくれるやつ

最近現場で使っているところが増えてる

ローカルでサーバー起動（例は３つ、外部APIサーバーが３つある場合などなど）

docker pull swaggerapi/swagger-editor
docker run -d -p 8090:8080 swaggerapi/swagger-editor
docker run -d -p 8091:8080 swaggerapi/swagger-editor
docker run -d -p 8092:8080 swaggerapi/swagger-editor

http://localhost:8090 などをブラウザで開き

ソース管理と一緒にリポジトリ内などにあるyamlファイル内容をコピペでブラウザ左Windowへ貼り付け

get、postなどテストをおこなう

※APIなので多少仕様の理解が必要となる

よく一緒に使われるのが OpenAPI

こちらはAPI設計ファイルとなったyamlファイルを読み込ませることにより指定した言語としてI/O部分のソースコードを自動でジェネレートしてくれるツール、ただし良いところばかりではなく、間違ったソースもジェネレートしてくるから地雷除去が必要な場面に出くわすこと多い