はじめに 株式会社エブリーでデリッシュキッチンのiOSアプリの開発をしている成田です。 iOS 26から、Appleの新しいデザイン言語である「Liquid Glass」が導入されました。 2026年4月の現時点では設定のフラグによって適用を回避できますが、次のXcodeのメジャーアップデートではこのフラグの廃止が見込まれています。 また、2027年春頃には新しいメジャーバージョンのXcodeでのビルドが必須になると考えられ、対応は避けられない状況です。 こうした背景から、すでにLiquid Glassへの対応を進めているiOSアプリ開発者の方も多いのではないでしょうか。 デリッシュキッチンでも現在ユーザーへのリリースを目指して対応を進めています。 本記事では、以下のような流れでデリッシュキッチンにおけるLiquid Glass対応への取り組みについて紹介したいと思います。Liquid Glassの概要については他の記事でも多く紹介されているので本記事ではできるだけ割愛します。 Liquid Glass対応の進め方 大まかな対応箇所 デリッシュキッチンにおける課題 AppleのLiquid Glassワークショップへの参加 Liquid Glass対応の進め方 キックオフと開発の流れ 今年の1月にPdMとデザイナー、エンジニアが集まりキックオフを行ってプロジェクトがスタートしました。 まず最初に、アプリのプロジェクト設定のオプトアウトフラグ UIDesignRequiresCompatibility を外した状態のアプリを社内に配布し、Liquid Glassがそのまま適用された状態で各画面をデザイナーに確認してもらいました。Appleの標準アプリや他のメジャーなアプリのUIも参考にしながら、対応が必要な箇所の洗い出しと優先度付け、そして大まかな工数見積もりを行いました。 また、対応方針については単にデザイン観点だけで決めるのではなく、技術的な実現可否や実装コストも踏まえながら、エンジニアとデザイナーで議論を重ねて整理していきました。デザインと実装の両面から検討することで、現実的かつ一貫性のある方針を定められていると感じます。 さらに、初期段階では一定期間を設けて集中的に実装を進めることで、実際の対応にどの程度の工数がかかるのかを把握することもでき、おおよそのベロシティ感を掴むことができました。 なお、参考事例としてAppleが紹介している デザイン事例集 も、実際にどのようにLiquid Glassがプロダクトに取り入れられているかを把握するうえで非常に参考になりました。 専任を置かず全員で対応する このプロジェクトでは、iOSチーム内に専任を置かず、各プロジェクトごとに分担して対応を進めています。 専任を設けると知見が特定のメンバーに偏り、今後の機能開発においてプロジェクトごとに実装のばらつきが生じる可能性があるためです。Liquid Glassのようなデザイン言語の変化は一部の対応にとどまらず、プロダクト全体に継続的に影響していくものだと考えています。 また、UIはデザイナーだけで完結するものではなく、エンジニアと連携しながら作り上げていくものです。こうした背景もあり、プロダクトに関わるiOSエンジニア全員で取り組む形で進めています。 独自フラグでコードを先行リリース 現在対応を進めているコードは、まだユーザー向けには公開せず、以下のような独自のフィーチャーフラグを設けることで、コード自体は順次リリースしつつ、ユーザーにはLiquid Glassが適用されない状態を保ったままにしています。 public enum LiquidGlassAvailability { /// Liquid Glass デザインが有効かどうかを返す。 /// iOS 26 以降かつ UIDesignRequiresCompatibility が設定されていない（または false）場合に true。 public static let isEnabled : Bool = { guard #available(iOS 26.0 , * ) else { return false } // UIDesignRequiresCompatibility が true の場合は互換モードなので Liquid Glass 無効 if let requiresCompatibility = Bundle.main.object(forInfoDictionaryKey : "UIDesignRequiresCompatibility" ) as? Bool , requiresCompatibility { return false } return true }() } このような進め方にしているのは、変更をため込むことでGitHub上のPRが滞留し、コンフリクトが発生しやすくなるのを防ぐためです。対応が完了した箇所から順次マージしていくことで、開発の流れをスムーズに保っています。 ユーザー向けの初回リリース時にはプロジェクト設定のオプトアウトフラグを取り除き、Liquid Glassが適用された状態で提供する予定です。また、リリース後も優先度に応じて段階的に適用範囲を広げていく方針です。 初回リリースに向けた大まかな対応箇所 ユーザーへの初回のリリースに向けて、優先度が高いのは以下の内容です。 ナビゲーションバー・タブバー周りの対応 最も優先度が高く、Liquid Glassの効果が大きい箇所がナビゲーションバーとタブバー周りです。Liquid Glassではこれらのバーが透過されることでコンテンツへの没入感が高まりますが、デリッシュキッチンでは元々これらのバーに対して背景色やボタンのスタイルなどを独自にカスタマイズしていました。Liquid Glassに対応するにあたり、これらの独自設定を取り除いていく作業が必要になりました。 レイアウトの修正 独自設定を削除していくと、画面によってコンテンツのレイアウトが崩れるケースが発生しました。Liquid Glassではナビゲーションバーやタブバーの背面にまでコンテンツが広がるレイアウトが前提となりますが、一部の画面ではそのような構造になっていなかったためです。各画面ごとにレイアウトを見直し、コンテンツがバーの裏側まで自然に潜り込むよう修正する作業も対応範囲に含まれています。 その他の表示崩れの修正 ここでは書ききれないので紹介を省きますが、上記の対応に加え、Liquid Glassの適用によって生じる細かな表示崩れについても最低限の修正を行ったうえでユーザーに向けた初回のリリースを行う予定です。 デリッシュキッチンにおける課題 ここでは、Liquid Glass対応を進める上でのデリッシュキッチンにおける課題をいくつかピックアップして紹介します。 ナビゲーションバー直下のカスタムViewの扱い デリッシュキッチンには、ナビゲーションバーの直下にタブやカスタムViewが配置されている画面がいくつかあります。単純にナビゲーションバーを透過にするだけでは、その下に続くカスタムViewとの境界が不自然になってしまい、コンテンツの表示領域も狭まってしまいます。これはLiquid Glassが目指すコンテンツへの没入感という思想に反してしまいます。 これらのカスタムViewをコンテンツ領域の中にどう自然に溶け込ませるか、デザインと実装の両面から検討する必要があり、現在取り組んでいる課題の一つです。 幅広い環境での検証体制 デリッシュキッチンはユーザー数も多く、現在は最新から3つのメジャーバージョンのiOSをサポートしています。Liquid GlassはiOS 26以降でのみ適用されますが、それ以前のOSでもレイアウト崩れが発生しないよう、すべてのサポートバージョンで表示を確認する必要があります。そのため、単一の環境での検証にとどまらず、複数バージョンをまたいだ確認が求められる点が大きな負担となっています。 また、弊社には専任のQAチームがないため、動作検証はPdM・デザイナー・エンジニアが協力して行っています。Liquid Glass対応のように影響範囲が広い変更では、確認すべき画面やパターンも多岐にわたるため、検証の抜け漏れを防ぎつつ、いかに効率的に進めていくかが課題となっています。 並行開発による手戻りリスク また、もう一つの課題として、通常の機能開発との並行進行があります。 現在のプロダクトでは複数のプロジェクトが並行して開発を進めており、Liquid Glass対応と並行して進行しています。そのため、新規機能の開発時にLiquid Glassの考慮が十分に行われないケースも発生しがちです。 その結果、後からデザインの調整や実装の修正が必要になり、手戻りが発生してしまう可能性があります。こうした手戻りをいかに防ぎ、現状の開発の中にLiquid Glass対応を組み込んでいくかも重要な課題となっています。 AppleのLiquid Glassワークショップへの参加 Liquid Glass対応の一環として、Appleが時折に開催しているワークショップに会社で参加する機会をいただき、3月にエンジニアとデザイナー数名で参加してきました。 ワークショップは、まずLiquid Glassの概要や設計思想、もたらす効果について一通り説明いただくところから始まり、その後はAppleのデザインのエバンジェリストの方と直接やり取りできる時間が設けられており、デリッシュキッチンにおける対応方針について質問やディスカッションを行いました。 自社アプリの課題を持ち込み、その場でフィードバックをもらえる形式だったため、抽象的なガイドラインだけではイメージしづらかった部分についても、具体的な方向性を確認することができました。 せっかくなので、ワークショップに参加して特に印象に残っている学びをいくつか紹介します。 ナビゲーションバーやタブバーで特色を出さない ナビゲーションバーやタブバーといった操作周りのUIで個性を出すのではなく、コンテンツでプロダクトの特色を表現することが重要であるという考え方が印象に残りました。 透過させることが目的ではない Liquid Glassは単に透過やブラーを適用すること自体が目的ではなく、コンテンツへのフォーカスを高めるための手段であるという話がありました。見た目だけをなぞるのではなく、どういう意図で使うかが重要だと感じました。 システムとの一貫性を保つ OS全体の表現と調和することが重要で、過度に独自のスタイルを持ち込むと違和感につながるという点も印象的でした。標準の振る舞いを尊重することが結果的に良い体験につながると感じました。 おわりに 本記事では、デリッシュキッチンにおけるLiquid Glass対応の取り組み状況についてご紹介しました。 同じようにLiquid Glassへの対応を進めている方にとって、少しでも参考になれば幸いです。 デリッシュキッチンのLiquid Glass対応のリリースもぜひ楽しみにしていてください！

AI に使わせるための CLI を設計した話 — cmdbuild-cli の開発 こんにちは。自称ソフトウェアエンジニアの橋本(@hassaku_63)です。 今回は、社内で運用している構成管理ツールである "CMDBuild" の CLI cmdbuild-cli を自作した話を書きます。ツールの機能紹介というよりは、AI に使われることを意識した設計の話です。

2026 年4 月 14 日、 AWS Interconnect – マルチクラウド の一般提供についてお知らせします。これは、 Amazon Virtual Private Cloud (Amazon VPC) を他のクラウドプロバイダーの VPC に直接接続するマネージドプライベート接続サービスです。また、 AWS Interconnect – ラストマイル もご紹介します。これは、既存のネットワークプロバイダーを通じて、ブランチオフィス、データセンター、遠隔地から AWS への高速でプライベートな接続を簡単に確立できる新機能です。 専門サービスの利用、データレジデンシーの要件への対応、さまざまなプロバイダーで標準化されたチームのサポートなど、複数のクラウドプロバイダー全体でワークロードを実行する大企業が増えています。これまで、これらの環境を確実かつ安全に接続するには、VPN トンネルの管理、コロケーション施設との連携、サードパーティのネットワークファブリックの設定など、大幅な調整が必要でした。その結果、ネットワーキングチームは、ビジネスにとって重要なアプリケーションに集中するのではなく、差別化されていない面倒な作業に時間を費やすことになります。 AWS Interconnect はこれらの課題に対する答えです。これは、AWS への接続を簡素化するマネージド接続サービスです。Interconnect を使用すると、ハイブリッドおよびマルチクラウド環境全体で、専用帯域幅を使用して AWS との間でプライベートな高速ネットワーク接続を確立できます。場所、パートナー、またはクラウドプロバイダー、優先リージョン、および帯域幅要件を選択することで、AWS コンソールを通じて数回クリックするだけで、回復力のあるエンドツーエンドの接続を簡単に設定できます。これにより、パートナーを見つける手間が省け、手動でネットワークを設定する複雑さがなくなります。 2 つの機能を備えています。1 つは AWS と他のクラウドプロバイダー間のマルチクラウド接続、もう 1 つは AWS とオンプレミスのプライベートネットワーク間のラストマイル接続です。どちらの機能も同じ原則に基づいて構築されています。つまり、チームからインフラストラクチャの複雑さを排除する、完全に管理されたターンキーエクスペリエンスです。 AWS Interconnect – マルチクラウド AWS Interconnect – マルチクラウドを使用すると、お客様の AWS 環境と他のクラウドプロバイダーとの間で、プライベートでマネージド型のレイヤー 3 接続が可能になります。最初は Google Cloud からで、Microsoft Azure は 2026 年後半にリリースされる予定です。トラフィックはすべて AWS グローバルバックボーンとパートナークラウドのプライベートネットワーク上をフローするため、パブリックインターネットを経由することはありません。つまり、物理インフラストラクチャを自分で管理しなくても、予測可能なレイテンシー、一貫したスループット、およびインターネット輻輳からの隔離が可能になります。 セキュリティはデフォルトで組み込まれています。すべての接続では、相互接続施設にある AWS ルーターとパートナークラウドプロバイダーのルーター間の物理リンク上で IEEE 802.1AE MACsec 暗号化が使用されます。これらを個別に設定する必要はありません。各クラウドプロバイダーは独自のバックボーンで個別に暗号化を管理しているため、特定のデプロイの暗号化ドキュメントをレビューして、コンプライアンス要件を満たしていることを確認する必要があることに注意してください。耐障害性も組み込まれています。各接続は、少なくとも 2 つの物理施設に分散された複数の論理リンクにまたがっているため、1 つのデバイスまたは建物に障害が発生しても接続が中断されることはありません。 モニタリングについては、AWS Interconnect – マルチクラウドは Amazon CloudWatch と統合されています。各接続には Network Synthetic Monitor が付属しており、ラウンドトリップの遅延やパケットロスを追跡したり、キャパシティプランニングをサポートする帯域幅使用率メトリクスを追跡したりできます。 AWS は基礎となる仕様を Apache 2.0 ライセンスの下で GitHub に公開しており 、あらゆるクラウドサービスプロバイダーにAWS Interconnect – マルチクラウドとのコラボレーションの機会を提供しています。AWS Interconnect パートナーになるには、クラウドプロバイダーは技術仕様を実装し、耐障害性基準、サポートコミットメント、サービスレベル契約などの AWS 運用要件を満たしている必要があります。 仕組み 接続のプロビジョニングには数分かかります。私は、AWS Direct Connect コンソールから接続を作成します。私は、AWS Interconnect セクションから始めて、プロバイダーとして Google Cloud を選択します。私は、私のソースリージョンと送信先リージョンを選択します。私は、帯域幅を指定し、私の Google Cloud プロジェクト ID を指定します。AWS はアクティベーションキーを生成し、私はこれを Google Cloud 側で使用して接続を完了します。ルートは両方向に自動的に伝達され、私のワークロードはすぐにデータの交換を開始できます。 このデモでは、私は単一の VPC から始めて、それを Google クラウド VPC に接続します。私は、Direct Connect ゲートウェイを使用します。これは最もシンプルな方法です。1 つの接続、1 つのアタッチメントであり、両側のワークロードが数分で相互に通信を開始できます。 ステップ 1: AWS マネジメントコンソール で相互接続をリクエストします。 私は、 AWS Direct Connect 、 AWS Interconnect に移動し、[ 作成 ] を選択します。私はまず、接続したいクラウドプロバイダーを選択します。この例では、Google Cloud です。 私は、次に AWS リージョン ( eu-central-1 ) と Google Cloud リージョン ( europe-west3 ) を選択します。 ステップ 3 で、私は「 説明 」を入力し、 帯域幅 、アタッチする Direct Connect ゲートウェイ 、 Google Cloud プロジェクト の ID を選択します。 リクエストをレビューして確認すると、コンソールからアクティベーションキーが渡されます。私は、そのキーを使用して、Google クラウド側でリクエストを検証します。 ステップ 2: Google Cloud Platform (GCP) アカウントでトランスポートリソースと VPC ピアリングリソースを作成します。 私にはアクティベーションキーがあり、GCP 側でプロセスを続けることに注意してください。この記事の執筆時点では、ウェブベースのコンソールは使用できませんでした。代わりに GCP コマンドライン (CLI) を使用することを選択しました。私は、 europe-west3 リージョンの GCP VPC サブネットの CIDR 範囲に注目します。次に、私はターミナルを開いて、次のように入力します。 gcloud network-connectivity transports create aws-news-blog \ --region=europe-west3 \ --activation-key=${ACTIVATION_KEY} \ --network=default \ --advertised-routes=10.156.0.0/20 Create request issued for: [aws-news-blog] ... peeringNetwork: projects/oxxxp-tp/global/networks/transport-9xxxf-vpc ... state: PENDING_CONFIG updateTime: '2026-03-19T09:30:51.103979219Z' コマンドが完了するまでに数分かかります。コマンドが返されたら、私は GCP VPC と作成した新しいトランスポートとの間にピアリングを作成します。私は、これを GCP コンソールまたは gcloud コマンドラインで実行できます。前のコマンドではターミナルを使用していたので、そのコマンドラインを続行しました: gcloud compute networks peerings create aws-news-blog \ --network=default \ --peer-network=projects/oxxxp-tp/global/networks/transport-9xxxf-vpc \ --import-custom-routes \ --export-custom-routes ネットワーク名は私の GCP VPC の名前です。ピアネットワークは前のコマンドの出力に表示されます。 完了したら、私は GCP コンソールでピアリングを確認できます。 AWS Interconnect コンソールで、私はステータスが 利用可能 であることを確認します。 AWS Direct Connect コンソールの [ Direct Connect ゲートウェイ ] に、新しいインターコネクトへのアタッチメントが表示されます。 ステップ 3: 新しいゲートウェイを AWS 側で関連付ける 私は、[ ゲートウェイの関連付け ] と [ ゲートウェイを関連付ける ] を選択して、このデモを開始する前に作成した仮想プライベートゲートウェイ (VGW) をアタッチします (インターコネクトと同じ AWS リージョンの VGW を使用する場合は注意してください)。 GCP 側でネットワークルーティングを設定する必要はありません。AWS では、最後のステップがあります。VPC ルートテーブル でルートエントリを追加して、すべてのトラフィックを Virtual Gateway 経由で GCP IP アドレス範囲に送信します。 ネットワークのセットアップが完了したら。私は、2 つのコンピューティングインスタンスを起動します。1 つは AWS 上で、もう 1 つは GCP 上です。 AWS 上で、私はセキュリティグループが TCP:8080 で受信トラフィックを受け入れることを確認しました。私は、マシンに接続し、最小限のウェブサーバーを起動します: python3 -c \ "from http.server import HTTPServer, BaseHTTPRequestHandler class H(BaseHTTPRequestHandler): def do_GET(self): self.send_response(200);self.end_headers() self.wfile.write(b'Hello AWS World!\n\n') HTTPServer(('',8080),H).serve_forever()" GCP 側で、私はマシンへの SSH セッションを開き、プライベート IP アドレスで AWS ウェブサーバーを呼び出します。 Et voilà! 私には 2 つのネットワーク間にプライベートネットワークルートがあり、すべてが 2 つのクラウドサービスプロバイダーによって管理されています。 知っておくべきこと 覚えておくべき設定オプションがいくつかあります: ネットワークを接続するときは、両側の IP アドレス範囲に注意してください。GCP と AWS VPC の範囲は重複できません。このデモでは、AWS 上のデフォルト範囲は 172.31.0.0/16 で、GCP 上のデフォルトは 10.156.0.0/20 でした。私は、これらのデフォルト値で続行できました。 IPV4、IPV6、またはその両方を両側に設定できます。両側で同じオプションを選択する必要があります。 最大転送単位 (MTU) は両方の VPC で同じである必要があります。AWS VPC と GCP VPC のデフォルト値はそうではありません。MTU は、ネットワークインターフェイスがフラグメンテーションなしで送信できる最大パケットサイズ (バイト単位) です。ピアリングされている VPC 間の MTU サイズが一致しないと、パケットのドロップやフラグメンテーションが発生し、サイレントデータ損失、スループットの低下、インターコネクト全体での接続切断につながります。 詳細については、 GCP Partner Cross Cloud Interconnect と、 AWS Interconnect ユーザーガイド を参照してください。 参照アーキテクチャ デプロイが拡大し、1 つのリージョンに複数の VPC がある場合、AWS Transit Gateway は、1 つのインターコネクトアタッチメントを通じてそれらすべてを接続する一元的なルーティングハブを提供します。クラウドの境界を越えるものを検査する必要がある場合は、環境間でトラフィックをセグメント化し、一貫したルーティングポリシーを適用し、AWS Network Firewall を統合できます。 また、複数の AWS リージョンと複数の Google Cloud 環境全体で分散しているワークロードを使用し、グローバル規模で運用している場合、AWS Cloud WAN は同じモデルを世界中に拡張します。一元化されたポリシー管理と、運用しているすべての場所で一貫して適用されるセグメントベースのルーティングにより、ネットワーク内のどのリージョンでも世界中のあらゆる Interconnect アタッチメントにアクセスできます。 私の同僚の Alexandra と Santiago は、これらの参照アーキテクチャをブログ投稿で文書化しています:「 AWS Interconnect – マルチクラウドで回復力がありスケーラブルなマルチクラウド接続アーキテクチャを構築する 」。 AWS Interconnect – ラストマイル AWS Interconnect – ラストマイルは、AWS Interconnect – マルチクラウドと同じアーキテクチャと設計に基づいており、参加しているネットワークプロバイダーのラストマイルインフラストラクチャを通じて、 AWS マネジメントコンソール から直接、オンプレミスまたはリモートロケーションを AWS に接続できます。 オンボーディングプロセスは AWS Interconnect – マルチクラウドを反映しています。プロバイダーを選択し、認証し、接続エンドポイントと帯域幅を指定します。AWS は、お客様がプロバイダーコンソールで提供するアクティベーションキーを生成して、設定を完了します。AWS Interconnect – ラストマイルでは、2 つの物理的な場所全体で 4 つの冗長接続が自動的にプロビジョニングされ、BGP ルーティングが設定され、MACsec 暗号化と Jumbo Frames がデフォルトでアクティブ化されます。その結果、ネットワーキングコンポーネントを手動で設定しなくても、ベストプラクティスに沿った AWS への回復力のあるプライベート接続が実現します。 AWS Interconnect – ラストマイルは 1 Gbps から 100 Gbps までの帯域幅をサポートし、再プロビジョニングせずにコンソールから帯域幅を調整できます。このサービスには、Direct Connect ポートの最大 99.99% の可用性 SLA が含まれており、接続状態を監視するための CloudWatch Network Synthetic Monitor がバンドルされています。AWS Interconnect – マルチクラウドと同様に、AWS Interconnect – ラストマイルは Direct Connect ゲートウェイにアタッチされ、仮想プライベートゲートウェイ、トランジットゲートウェイ、またはAWS Cloud WAN デプロイに接続されます。詳細については、 AWS Interconnect ユーザーガイド を参照してください。 Lumen Technologies の SVP Product である、Scott Yow 氏は次のように書いています: AWS Interconnect – ラストマイルを Lumen ファイバーネットワークおよび Cloud Interconnect と組み合わせることで、クラウドの採用を遅らせることが多いラストマイルの複雑さを簡素化し、お客様にとってより迅速で回復力のある AWS へのパスを実現します。 料金と利用可能なリージョン AWS Interconnect – マルチクラウドと AWS Interconnect – ラストマイルの料金は、お客様がリクエストしたキャパシティの定額時間料金に基づいており、時間単位で請求されます。ワークロードのニーズに合った帯域幅階層を選択できます。 AWS Interconnect – マルチクラウドの料金はリージョンのペアによって異なります。米国東部 (バージニア北部) と Google Cloud 北バージニア間の接続は、米国東部 (バージニア北部) とより遠いリージョン間の接続とは料金が異なります。AWS Cloud WAN を使用する場合、グローバルな Any-to-Any ルーティングモデルでは、トラフィックが複数のリージョンを通過できるため、デプロイの総コストに影響します。接続のサイズを決定する前に、 AWS Interconnect の料金ページ でリージョンペア別およびキャパシティ階層別のフルレートカードを確認することをお勧めします。 AWS Interconnect – マルチクラウドは現在、米国東部 (バージニア北部) から Google Cloud 北バージニア、米国西部 (北カリフォルニア) から Google Cloud ロサンゼルス、米国西部 (オレゴン) から Google Cloud オレゴン、欧州 (ロンドン) から Google Cloud ロンドン、欧州 (フランクフルト) から Google Cloud フランクフルトの 5 つのリージョンペアでご利用いただけます。Microsoft Azure のサポートは 2026 年後半に開始される予定です。 AWS Interconnect – ラストマイルが米国東部 (バージニア北部) でリリースされ、Lumen が最初のパートナーとなります。AT&T や Megaport など、その他のパートナーも進行中で、リージョンも追加される予定です。 AWS Interconnect の使用を開始するには、 AWS Direct Connect コンソール にアクセスし、ナビゲーションメニューから AWS Interconnect を選択します。 お客様の環境で AWS Interconnect がどのように使用されているかをぜひお聞かせください。以下にコメントを残すか、 AWS re:Post コミュニティ を通じてお問い合わせください。 – seb 原文は こちら です。