こんにちは、 電通 総研 XI本部 サイバーセキュリティテクノロ ジー センターの櫻井です。 本記事では 代表的な クラウド サービスプロバイダ（以降、CSPと略）である AWS ( Amazon Web Services )、 Microsoft Azure、 Google Cloudの最上位アーキテクト資格に関する比較を紹介します。 なお、本記事でご紹介する資格の情報は2026年1月時点のものとなります。 アーキテクト資格の種類 筆者の経歴 チャレンジのおススメ順 各CSP最上位資格で共通で問われる内容 各CSP最上位資格の特色 まとめ 最後に アーキテクト資格の種類 各CSP資格群はFoundational、Associate、Professiona(Expert)lの3段階に分かれており、受験者の対象と試験の大枠としては以下を想定しています。 Foundational 対象： クラウド 初心者やIT未経験者。また、基礎知識を理解したい営業・ マーケティング ・プロジェクトマネジメントサイドの担当者 試験の大枠： クラウド 自体の理解、大枠のサービス概要、 クラウド 利用料計算の理解 Associate 対象：ソリューション設計に1年以上の実務経験のあるITエンジニア 試験の大枠：設計に用いるソリューションの基本理解 Professional(Expert) 対象：ソリューション設計に理解のある、実務経験のあるITエンジニア 試験の大枠：設計時のソリューションベストプラクティスの理解、適切なサービス組み合わせの理解 それぞれの資格群の名称(略称)に関しては以下の表のとおりです。 Grade AWS Azure Google Foundational Cloud Practitioner(CLF) Azure Fundamentals(AZ-900) Cloud Digital Leader(CDL) Associate Solutions Architect Associate(SAA) Azure Administrator(AZ-104) Associate CloudEngineer(ACE) Professional(Expert) Solutions Architect Professional(SAP) Azure SolutionsArchitect Expert(AZ-305) Professional Cloud Architect (PCA) 以降は、Professional、Expert資格にフォーカスして説明を行います。 筆者の経歴 （テンプレにはなりますが、）オンプレ＆ クラウド 、ネットワーク＆セキュリティのごちゃまぜエンジニアです。担務領域に関しては特にこだわりなくなんとなく興味を持った資格は取得してます。(※ My credly ) 電通 総研ではサイバーセキュリティテクノロ ジー センターで主にセキュリティサービス設計、運用やマルチ クラウド のセキュリティ設計レビューに従事しています。 また、筆者の各CSPの経験歴としては以下となります。 AWS 7年程度、メインは クラウド インフラ設計ガッツリです。オンプレ接続のために用いる クラウド リソース管理や運用/監視、リソースデプロイの自動化がメインタスクでした。 電通 総研に入社後はアプリまで含めた AWS 全般のセキュリティ設計レビューを行っています。 Microsoft Azure 5年程度、メインは クラウド マイグレーション に関わるインフラ設計、ID（ Microsoft Entra）の設計・運用でした。 電通 総研に入社後は Microsoft defender for cloudをはじめとしたセキュリティサービスの調査や社内向けサービス設計に従事しています。 Google Cloud 3年程度、以前はBigQueryやApp Engineを触っていた程度です。 電通 総研に入社後は Google Cloudログサービスの調査・検証の実施、Firebaseを利用したWebサイト構築のセキュリティ設計レビューにも参加しています。 チャレンジのおススメ順 最初に、３種すべてを取得するならばの前提で筆者の考える難易度を記載します。各試験で問われる範囲と出題形式、傾向、学習コンテンツを踏まえて、以下の順が望ましいと考えています。 Google Cloud(Professional Cloud Architect) AWS (Solutions Architect Professional) Microsoft Azure(Azure Solutions Architect Expert) はい、見事に筆者のチャレンジ順とは逆です。 単一CSPでガッツリ設計をやっている方は専門の分野を突き詰めるのが望ましいのであまり難易度比較に意味はありませんが、基本は下に行くほど難しい試験である（事前準備が必要である）と筆者は考えています。 各CSP最上位資格で共通で問われる内容 最上位資格の試験について、共通で必要とされる内容を簡単に整理します。 対象CSPのサービス全般に対する理解①　対象のサービス種類（試験に含まれるサービスの範囲） CSPの試験ガイドで具体的に対象と記載されているサービスについてすべてが対象となります。 例として、 AWS (Solutions Architect Professional)であれば 試験ガイド の「範囲内の AWS のサービスと機能」となっているサービスはすべて対象です。 各試験によってどこまでを対象とするかは異なりますが、ITサービス構築のために クラウド インフラを利用するだけではなじみのないAIやデータ分析のサービスも含まれますので、普段利用していないサービスでも用途等は理解しておく必要があります。 対象CSPのサービス全般に対する理解②　サービスの単位 「 AWS における VPC はリージョナルサービスである」、「 Google Cloudにおける VPC はグロー バルサ ービスである」という比較に代表されるように クラウド 設計におけるサービスがどこまでの範囲で展開可能かを明確に覚えておきましょう。 対象としているCSPにフォーカスしてきちんと学習しましょう。実務目線でも設計や提案の際に理解できていないと致命的です。 例えば、複数リージョンに渡る負荷分散の設計方法は各CSP毎に大きく異なる等ですね。 （この場合、グローバルロードバランシングの種類をちゃんと理解しているか？になります） 設計の理解①　設定パラメータ 利用ケースが多いサービス（コンピュート、コンテナ、アプリケーション統合）については細かい設定が問われる問題が出題されます。この点に関しては明確に実務経験があった方が望ましいといえます。 対象サービスのパラメータを設定するのに、どういった方法があるのかも含めて押さえておくとよいです。 1.「環境を作りなおす必要があるのか？」もしくは「既存の環境のままで設定変更が可能か？」 2.「マネジメントコンソールから設定できるか？」もしくは「 API や CLI からのみ設定できるのか？」 設計の理解②　ソリューションの選定、ソリューションの組み合わせ比較 出題内容としては、具体的なソリューションを一意に特定するケースに加えて、必要な要件に対して複数のソリューションの組み合わせを比較した上で最も適したものを選択するケースも存在します。 いわゆるベストプラクティスを選択する必要がありますので、 AWS の場合は Black Belt の様な公式のソリューションガイドを参考に学習するとよいです。 筆者の経験でも、顧客の特殊要件を踏まえ意図的にベストプラクティスを選択しなかった経験もありますし、当時と比較して新しいサービスがリリースされている可能性もありますので、最低限は確認しましょう。 各CSP最上位資格の特色 それぞれの試験の概要と筆者の試験自体に関する印象、筆者の主観的分析を紹介します。 AWS Solutions Architect Professional(SAP) 問題数：75問、時間：180分 試験後の印象 とにかく問題数が多い。そして問題文、選択肢の文章が比較的長いので持続的な集中力を求められる。 AWS のProfessional、Security分野の試験では共通している点かと思います。 主観的分析 AWS に関してはCSPがリリースしているサービスの種類が他の2社と比べて多いです。（200個以上） 時間をかけて理解する必要があり、初学者は数に圧倒されると思います。 問題そのものは取り組みやすいですが、文章量の理解に時間を要するため練習問題等で慣れておく必要があります。 SAPを含め、 AWS 資格のコンテンツは数多く存在するためこの点は学習者にプラスです。 Azure Solutions Architect Expert(AZ-305) 問題数： 不定 （概ね50問前後）、時間：120分 試験後の印象 設計の組み合わせやサービスの詳細など細かい部分まで回答を求められる。（理由は後述） 試験への慣れが必要。３パートに分かれており、２パートは選択を終了したら戻ることができない。 本試験はダイレクトに「 クラウド インフラ設計」の理解を求められる。 Microsoft Webページ の記載の通り、複数系統に分かれているためです。 主観的分析 CSP３種試験の中では難易度は最も高いと思います。 設計にフォーカスしているため、サービス単体を理解しているだけではNGなケースが多いです。 Microsoft AzureのAssociate以上の試験に関しては Microsoft Learn でコンテンツを検索しながら回答が可能です。 その点に起因するかはわかりませんが、事前の学習では手が回らないような調べないとほぼ回答できないような細かいサービス詳細に関する問題も一部出題されます。（この要件を満たすライセンスの種類は？というような問題） 購入した問題集の設問で構わないのでこんな感じで検索したら出てきそうというのを Microsoft Learnで事前に確認しておくとよいです。関係のないコンテンツも検索結果に含まれてしまい、思いのほか抽出が難しいです。 40問程度の大問パート以外にシナリオ問題とケース問題で合計3パート以上で構成され、パート間で戻ることはできないため、時間配分を間違わないようにしましょう。（筆者はAZ-305以外の試験で勘違いし、ドボンしています） 市販の学習用コンテンツは最低限は存在します。 Microsoft Azureは Microsoft Learn以外にも公式の トレーニングコース が充実しているため、集中的に学習したいものは登録しましょう。 開催日程が決まっていますが、 Microsoft Virtual Training Days で無料で受講できるハンズオンや講習も存在するので確認しましょう。 Google Cloud Professional Cloud Architect(PCA) 問題数： 不定 （50問以上、60問未満）、時間：120分 試験後の印象 一定以上の知識は必要だが、複雑な問題はあまり出題されない。 サービスの種類と設計をバランスよく理解しておくことが求められる。 数問で構成されるケース問題が複数出題される。全く関係ない導入文も含まれるので選択をミスらないようにしましょう。 試験中に問題言語を英語に切り替えられない。筆者だけかもしれませんが、細かいオプション説明を英字で確認しようと切り替えても日本語のままでした。 主観的分析 個人的な忖度ではないですが、試験自体は一番取り組みやすいと感じました。試験時間と問題文、文章量がマッチしていると思います。 ACEとは別にProfessionalとなっているので簡単ではないですが、適度な難易度の問題が適量出題されるイメージです。 難点は学習コンテンツが少ないことかと思います。PCAに限っては市販の書籍は見当たりませんでした。 Udemyのコンテンツで日本語対応のもの（※１、※２）がありますのでこちらをお勧めします。 筆者の感覚では既にACEを取得済みであれば、Udemyのコンテンツを繰り返すだけでも合格することは十分可能だと思います。（自信がない方はラボ演習をしましょう） 所属する会社によって変わりますが、 Google Cloudに関する招待制ト レーニン グプログラムも存在します。無料でラボコンテンツが一定期間利用できるプログラムです。 ※１ https://www.udemy.com/course/google-cloud-professional-cloud-architectpca/ ※２ https://www.udemy.com/course/google-cloud-professional-cloud-architect-i/ まとめ 以上を踏まえて、それぞれの試験を試験自体の難易度（筆者の感覚）、試験への慣れの必要性、学習コンテンツの豊富さで整理したいと思います。（勉強時間は各個人によるので含めません） 評価観点 AWS (SAP) Azure(AZ-305) Google (PCA) 試験自体の難易度（筆者感覚） 普通 (サービスの数は多いが基本的なサービス組み合わせ、設計等を理解できていれば問題なし。) 難しい (ひとえに難しい。細かいところまで出題される。) 比較的取り組みやすい (サービスの種類を覚え、組み合わせや設計が理解できていれば問題なし。) 試験への慣れの必要性 ある程度必要 (問題数、文章量への慣れが必要。) 慣れが必要 (最終的にExpertとなるためにはAZ-104の合格も併せて必要なので先に受験し訓練しましょう。) ほぼ不要 (初チャレンジでもケース問題の切り替えに注意すれば問題はないと思います。) 学習コンテンツの豊富さ 豊富 (ググっても、 Amazon で検索しても、Udemyでも大量にあります。むしろ精査が難しいレベル。) 普通 (発売されているものは少ないですが、良書が多いので一度は目を通しましょう。) 少ない (市販書籍がないのでUdemy等を活用しましょう。) 表からチャレンジ順の理由がご理解いただけたかと思いますが、AZ-305に関しては、事前に準備しないといけないもの（知識も当然だが、問題形式や回答方法の予習）が多く、3種横並びで見た場合で最初にチャレンジするのは難易度が高いという評価です。ただ、 クラウド インフラ設計という点からは逸脱している内容ではないので、学んでおくことでプラスになる内容であると思います。 最後に 読了いただきありがとうございました。 筆者は事前の積み重ねもあって3種のArchitect最上位資格を約半年間で取得できました。しかし、エンジニア（もしくは コンサルタント ）としてのゴールは資格を取得することではありません。 基本は クラウド への理解を深めるためにCSPの提供するラボ等を活用し、じっくり学習することをお勧めします。 今後も クラウド 、セキュリティに関する投稿を行っていきますのでよろしくお願いします。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @sakurai.ryo レビュー： @kobayashi.hinami （ Shodo で執筆されました ）

Flutter3.38アップグレードにおけるiOSとAndroidの影響範囲 背景 Flutter3.38アップグレードの手順 パッケージのバージョン依存関係調整 依存関係の解消によって副次的問題が発生 1. Dart SDK バージョン 2. Ferryエコシステム（GraphQLクライアント） 3. Freezed（コード生成） 4. Firebase（iOS 13対応のため2.x系を使用） 5. その他の重要な更新 6. Isar Plus（データベース）モデル修正 解決した依存関係の競合 競合1: isar_db_generator 競合2: intl バージョン 競合3: source_gen バージョン 競合4: build バージョン 競合5: gql_exec バージョン 競合6: ferry バージョン 競合7: web パッケージ（iOS 13対応のための調整） 競合8: Firebase iOS 15要件 参考リンク 既存コードの改修作業 1. isar_plus 移行に伴うimport文の変更 2. isar_plus 移行に伴うPodfileの変更 3. NDKバージョンの明示的指定 4. Android app の namespace（AGP 8.x 必須） 5. サブプロジェクトへの namespace 注入 6. BuildConfig の有効化 7. Freezed 3.x マイグレーション（全モデルに abstract 修飾子） 8. retrofit / ParseErrorLogger 対応 9. Android 旧埋め込み (PluginRegistry.Registrar) 削除対応 10. iOS CocoaPods更新 Flutter バージョン別 カート追加時パフォーマンス比較レポート 比較サマリー 結論 主な改善要因（推測） 今後の検討 まとめ 1. テスト 2. iOS 11-12ユーザーへの対応検討 最後に 　こんにちは、開発本部 開発２部 RetailHUB NetSuperグループに所属するホーク🦅アイ👁️です。 背景 　現在提供しているネットスーパーアプリはFlutter＋Dartで実装しております。一方で、昨年2025年11月1日までに対応が必要であったGoogleからの メモリの16KBページサイズをサポートせよ という通知を延長申請して2026年5月31日まで対応を保留にしていました。2026年2月現在、この延長期限も近づいてきていることを理由にFlutterのバージョンを3.38系にアップグレードすることになりました( こちら の公式ブログにも3.38から標準対応したとあります)。 Flutter3.38アップグレードの手順 　通常、Flutterのバージョンをアップグレードする際の流れとしては、以下の2点を気にする必要があり実際にそのプロセスを踏まないといけないことも少なからずあります。 パッケージ依存関係の解消 既存ソースコードで改修 　今回、対象のソースコードで利用しているFlutterバージョンは3.24.1と古めのバージョンであるためバージョン差分が大きく、2点とも対応が発生しました。以下にその2点の対応について詳細を記していきます。 パッケージのバージョン依存関係調整 　目的はあくまでAndroidアプリの16KBページサイズに対応することなのでAndroidアプリのビルドをまず意識した以下のバージョンを調整しました。 Flutter,Dartのバージョンを上げる Flutter3.38.9、Dart3.10.8にしました DevTools 2.51.1 Gradleのバージョンを上げる 8.7にしました AGPのバージョンを上げる 8.5.1にしました Kotlinのバージョンを上げる 2.0.21にしました NDKバージョンを明示指定 29.0.14206865にしました その他利用ライブラリの対応バージョンをtrial and errorで上げる 現状のバージョンのままでビルドしてみてエラーが出たら上げるを繰り返しました 依存関係の解消によって副次的問題が発生 　今回、Androidアプリのためにアップグレードをするので必要なライブラリパッケージも必要最低限のものだけを最小限でアップグレードすることを心がけたのですが、意図せずiPhoneアプリ側の方にも影響を及ぼしてしまうことが判明しました。具体的には以下のことが発生しました。 iOSの最小メジャーバージョン番号が12から13以上に引き上げ 　直接的な引き上げ条件は、 Flutter公式 によれば、swiftコードを利用する場合とありますがFlutter3.38自体がそれに該当するということ( 参考ページ )でした。というわけで、必然的にFlutter3.38にしないといけない場合はiOS最小対応バージョンも13以上になるということでした。 　最終的には以下に挙げるバージョン対応で一旦、すべての依存関係の競合を解決し、 pub get 、コード生成、iOS CocoaPodsインストールがすべて成功しました。 1. Dart SDK バージョン 変更 : >=3.7.0 <4.0.0 → >=3.8.0 <4.0.0 理由 : json_serializable と freezed の最新版が要求 2. Ferryエコシステム（GraphQLクライアント） パッケージ 最終バージョン 理由 ferry ^0.16.1 ferry_generator 0.12.0+3との互換性 ferry_generator ^0.12.0+3 build 4.0対応 build_runner ^2.10.3 build 4.0対応 gql_code_builder_serializers ^0.1.0 ferry_generator 0.12.0+で必須 gql_exec ^1.0.0 ferry_generator依存関係 gql_http_link ^1.0.0 gql_execとの互換性 gql_transform_link ^1.0.0 gql_execとの互換性 3. Freezed（コード生成） パッケージ 最終バージョン 理由 freezed ^3.2.5 build 4.0対応 freezed_annotation ^3.0.0 freezed 3.x対応 4. Firebase（iOS 13対応のため2.x系を使用） パッケージ 最終バージョン 理由 firebase_core ^2.32.0 iOS 13サポート（3.x+はiOS 13必須） firebase_analytics ^10.10.7 firebase_core 2.x互換 firebase_crashlytics ^3.5.7 firebase_core 2.x互換 firebase_messaging ^14.7.10 firebase_core 2.x互換 & webパッケージ互換 firebase_remote_config ^4.4.7 firebase_core 2.x互換 firebase_app_installations ^0.2.5+7 firebase_core 2.x互換 Firebase iOS SDK : 10.25.0（iOS 13+をサポート） 5. その他の重要な更新 パッケージ 最終バージョン 理由 intl ^0.20.2 flutter_localizations要求 retrofit_generator ^10.2.1 source_gen 4.0対応 json_annotation ^4.9.0 json_serializable要求（dependenciesに追加） 6. Isar Plus（データベース）モデル修正 isar_plus v4のAPI変更に対応： 変更後（isar_plus v4スタイル）: @collection class EventLog { EventLog({required this .id}); final int id; // Auto-increment id (isar_plus v4) late String data; } 主な変更点: @Collection() （大文字）→ @collection （小文字） Id id = Isar.autoIncrement → final int id とコンストラクタで受け取る 実際のauto-increment IDは isar.collection.autoIncrement() で生成 解決した依存関係の競合 競合1: isar_db_generator 問題 : isar_db_generator パッケージが存在しない 解決 : isar_db は元の isar_generator を使用することを確認 競合2: intl バージョン 問題 : flutter_localizations が intl 0.20.2 を要求 解決 : intl を ^0.20.2 に更新 競合3: source_gen バージョン 問題 : isar_plus が source_gen ^4.0.2 を要求、 retrofit_generator ^8.1.0 が source_gen ^1.3.0 を要求 解決 : retrofit_generator を ^10.2.1 に更新（source_gen 4.0対応版） 競合4: build バージョン 問題 : build_runner >=2.9.0 が build ^4.0.0 を要求、 freezed ^2.x が build ^2.3.1 を要求 解決 : freezed を ^3.2.5 に更新（build 4.0対応版） 競合5: gql_exec バージョン 問題 : gql_transform_link が古い gql_exec を要求、 ferry_generator 0.12.0+3 が gql_exec ^1.0.0 を要求 解決 : gql_exec 、 gql_http_link 、 gql_transform_link をすべて1.x系に更新 競合6: ferry バージョン 問題 : ferry ^0.14.2+1 が ferry_exec ^0.3.1 を要求、 ferry_generator 0.12.0+3 が ferry_exec ^0.7.0 を要求 解決 : ferry を ^0.16.1 に更新 競合7: web パッケージ（iOS 13対応のための調整） 問題 : isar_plus が web ^1.1.0 を要求、Firebase 4.x系が web ^0.5.1 を要求 解決 : Firebaseパッケージを2.x系にダウングレード（iOS 13サポートのため） 競合8: Firebase iOS 15要件 問題 : Firebase 4.x系（firebase_core 4.0+）はiOS 15を最小要件とする 解決 : Firebase 2.x系（firebase_core 2.32.0）を使用してiOS 13をサポート 参考リンク isar_plus v4 ドキュメント ferry_generator changelog freezed 3.0 migration Firebase Flutter changelog firebase_core 3.0.0 breaking changes 既存コードの改修作業 　前述にある依存パッケージライブラリをアップグレードすることで破壊的変更が発生してしまった全箇所をエラーがなくなるまで対応していくという作業も相当数発生しました。 1. isar_plus 移行に伴うimport文の変更 　 package:isar/isar.dart → package:isar_plus/isar_plus.dart に変更 2. isar_plus 移行に伴うPodfileの変更 ios/Podfile で isar_flutter_libs → isar_plus_flutter_libs に変更 3. NDKバージョンの明示的指定 追加 : ndkVersion "29.0.14206865" （安定版最新。r28+ で 16KB アライメント対応のため r29 を使用） ファイル : app/build.gradle 理由 : NDK r28以上で16KBアライメントがデフォルト対応。固定していた 28.0.12674087 ではなく、安定版最新 29.0.14206865 を推奨 4. Android app の namespace（AGP 8.x 必須） 追加 : namespace "tv.every.fresh" ファイル : app/build.gradle 理由 : AGP 8.x ではモジュールに namespace の指定が必須。未指定だと「Namespace not specified」でビルド失敗する。 5. サブプロジェクトへの namespace 注入 追加 : Android library プラグインで namespace 未指定のサブプロジェクトに、 AndroidManifest.xml の package を namespace として設定 ファイル : build.gradle （root） 理由 : AGP 8.x では全モジュールに namespace 必須。古いパッケージは namespace 未指定のため「Namespace not specified」でビルド失敗する。pub cache は編集しないため、root の subprojects.plugins.withId("com.android.library") で manifest の package を注入する。 6. BuildConfig の有効化 追加 : 全 Android サブプロジェクトで buildFeatures.buildConfig true ファイル : build.gradle （root） 理由 : AGP 8.x では BuildConfig がデフォルト無効。custom BuildConfig を使うパッケージがあったため「defaultConfig contains custom BuildConfig fields, but the feature is disabled」でビルド失敗する。root の subprojects.afterEvaluate で全モジュールに有効化する。 7. Freezed 3.x マイグレーション（全モデルに abstract 修飾子） 対象 : @freezed を付けた全てのモデルクラス 対応 : Freezed 3.0 マイグレーションガイドに従い、 全てのクラス定義に abstract 修飾子を追加 変更例 : // 変更前 @freezed class Shop with _$Shop {...} // 変更後 @freezed abstract class Shop with _$Shop {...} 理由 : Dart 3.10 コンパイラ下で non_abstract_class_inherits_abstract_member エラーを解消するため。Freezed 3.x の生成コード（mixin の抽象メンバー）と互換させるには、公開クラスを abstract class にすることが必要。 実施方法 : 上記のとおり、該当する全モデルファイルで class → abstract class に手動で置換。 検証 : 本対応後に iOSビルド成功し、iOS Simulator(26.2)でアプリ起動を確認済。 8. retrofit / ParseErrorLogger 対応 対象 : retrofit パッケージをimportしているREST APIを実装したdartファイル(ex. rest_api.dart) 現象 : 旧 retrofit 4.1.0 + retrofit_generator 10.2.1 で生成したコードが型 ParseErrorLogger を参照するが、 package:retrofit/http.dart のみの import では参照できずコンパイルエラーになる 対応 : retrofit : ^4.1.0 → ^4.9.2 に更新（Dart 3.8 対応バージョン、ParseErrorLogger は package:retrofit/retrofit.dart で提供） rest_api.dart : import 'package:retrofit/retrofit.dart'; を追加し、生成コード（part ファイル）から ParseErrorLogger を参照可能にする。 package:retrofit/http.dart は retrofit.dart に含まれるため削除可 結果 : build_runner 再生成後も手動修正不要でビルド可能 9. Android 旧埋め込み (PluginRegistry.Registrar) 削除対応 Flutter 3.38 では v1 Android 埋め込み API（ PluginRegistry.Registrar / registerWith ）が削除されている。以下のパッケージを更新済み。 path_provider : ^2.1.3 → ^2.1.5 （path_provider_android 2.2.5+ を要求し、v1 削除済み） shared_preferences : ^2.2.3 → ^2.3.4 （shared_preferences_android 2.2.3+ で v1 削除済み） url_launcher_android : ^6.0.38 → >=6.3.3 <6.3.27 （6.3.3 で v1 削除。6.3.27+ は androidx.browser 1.9.0 が AGP 8.9.1 を要求するため 6.3.26 以下に制限） compileSdkVersion : 34 → 36（path_provider_android 等が SDK 36 を要求。 app/build.gradle ） 10. iOS CocoaPods更新 iOS最小デプロイメントターゲットをiOS 13.0にFixしました。 platform :ios , ' 13.0 ' config.build_settings[ ' IPHONEOS_DEPLOYMENT_TARGET ' ] = ' 13.0 ' Flutter バージョン別 カート追加時パフォーマンス比較レポート 　新しいバージョンになったのでそれだけでどれだけ既存アプリのパフォーマンスにも影響を及ぼしたか気になったのでFlutter DevToolsでプロファイリングしてTimeline Eventsを3.24.1と3.38.9でベンチマーク比較してみました。 　以下は、 同じカート追加アクション で取得したDevToolsの計測データを用い、 Flutter 3.24.1 と Flutter 3.38.9 のパフォーマンスを比較したレポートです。 項目 Flutter 3.24.1 Flutter 3.38.9 総フレーム数 96 107 比較サマリー 指標 Flutter 3.24.1 Flutter 3.38.9 差分 傾向 平均FPS 19.8 fps 48.3 fps +28.5 fps ✅ 大幅改善 平均フレーム時間 50.47 ms 20.71 ms -29.76 ms ✅ 約59%短縮 平均ビルド時間 7.23 ms 1.25 ms -5.98 ms ✅ 約83%短縮 平均ラスター時間 26.86 ms 15.32 ms -11.54 ms ✅ 約43%短縮 平均Vsyncオーバーヘッド 5.96 ms 1.46 ms -4.50 ms ✅ 約75%短縮 最大フレーム時間 274.89 ms 85.51 ms -189.38 ms ✅ 約69%短縮 最大ビルド時間 115.16 ms 18.66 ms -96.50 ms ✅ 約84%短縮 最大ラスター時間 145.56 ms 41.46 ms -104.10 ms ✅ 約72%短縮 Janky率 100.0% 88.8% -11.2pt ✅ 改善 重度Jank率 (>33ms) 38.5% 4.7% -33.8pt ✅ 大幅改善 結論 Flutter 3.38.9 は 3.24.1 と比較して、カート追加時のパフォーマンスが全体的に大きく改善しています。 平均FPSが 19.8 → 48.3 と約2.4倍になり、体感の滑らかさが向上しています。 ビルド時間・ラスター時間・Vsyncオーバーヘッドのいずれも短縮。 最大フレーム時間は 274.89ms → 85.51ms（約69%短縮） と、改善が確認できます。 重度Jank率は 38.5% → 4.7% と約1/8に減少。 主な改善要因（推測） Flutterエンジン・Skiaの最適化 ビルドパイプラインの効率化（ビルド時間の大幅短縮） Vsyncまわりのオーバーヘッド低減 今後の検討 3.38.9 時点でも Janky率 88.8%、平均FPS 48.3 であり、60fps目標にはまだ余裕があります。 ラスターが主なボトルネックのため、画像最適化・RepaintBoundary・Clip削減などの施策を続けると、さらに改善の余地があります。 まとめ 　本ブログでは、Android15以降でサポートされている16KBページサイズに対応するためFlutterのバージョンを3.38系にアップグレードすると既存アプリにどのような影響を及ぼすことになるかについてお話ししました。 　一旦は、両OSともビルドが成功してアプリ起動までは確認が取れたのでこれから5月31日まであまり日がないですが以下のようなThe next stepsに基づいて進めていく予定であることをお知らせして結びとさせていただきます。 1. テスト 単体テストの実行 統合テストの実行 手動テスト（特にデータベース操作とGraphQL操作） 2. iOS 11-12ユーザーへの対応検討 アプリストアで古いバージョンを継続提供 ユーザーへの事前通知 段階的な移行計画 最後に エブリーでは、ともに働く仲間を募集しています。 テックブログを読んで少しでもエブリーに興味を持っていただけた方は、ぜひ一度カジュアル面談にお越しください！ corp.every.tv

G-gen の高宮です。Google 公式の技術ドキュメントを検索するための Developer Knowledge API を、Gemini CLI から MCP サーバー経由で使用した検証結果を紹介します。 はじめに Developer Knowledge API とは MCP サーバーで使用可能なツール 注意事項 事前準備 Google Cloud の設定 Gemini CLI の設定 search_documents での検索 質問の投入 検索と回答の流れ get_document での検索 質問の投入 検索と回答の流れ AI 開発におけるドキュメント参照 はじめに Developer Knowledge API とは Developer Knowledge API は、Google Cloud 製品や Google 製品（Android、Firebase など）の公式ドキュメントを検索するための API です。この API を使用すると、独自のアプリケーションやワークフローに、Google のナレッジベースを統合できます。 また当 API では、Google から リモート MCP サーバー （Developer Knowledge MCP server）も提供されており、ローカル環境の CLI ツールや IDE から、自然言語で Google の公式ドキュメントを検索して取得することができます。また、エージェンティックな開発の中で、AI が正確な API 仕様等をもとに開発を進めるためにも寄与します。 参考 : Developer Knowledge API 参考 : Connect to the Developer Knowledge MCP server Google Cloud MCP Servers では、Compute Engine や BigQuery、Google Maps などのための MCP サーバーが提供されています。詳細は以下の記事を参照してください。 blog.g-gen.co.jp blog.g-gen.co.jp MCP サーバーで使用可能なツール Developer Knowledge MCP server で使用可能なツールは以下のとおりです。 ツール名 説明 batch_get_documents search_documents で取得した結果から、複数のドキュメントの全ての内容を取得します。 get_document search_documents で取得した結果から、単一のドキュメントの全ての内容を取得します。 search_documents 入力したクエリに関連する Google の公式ドキュメントを検索します。検索結果で、 get_document または batch_get_documents を使用することで、ドキュメントの全ての内容を取得します。 参考 : MCP Reference: developerknowledge.googleapis.com 注意事項 Developer Knowledge API は、2026年2月現在、Public Preview です。当記事で解説する内容は一般提供（GA）の際に変更される可能性があることを予めご了承ください。 Preview 版のサービスや機能を使うに当たっての注意点は、以下の記事も参考にしてください。 blog.g-gen.co.jp 事前準備 Google Cloud の設定 使用する Google Cloud プロジェクトで以下の API を有効化します。 Developer Knowledge API gcloud services enable developerknowledge.googleapis.com 同じプロジェクトで、API キーを作成し、Developer Knowledge API 呼び出し時のみに使用できるように API キーを制限し保護します。 gcloud services api-keys create --display-name =" Developer Knowledge API Key " ※ Developer Knowledge API を有効化してすぐの場合は、「Select APIs」リストに表示されないことがあります。 以下のコマンドで Developer Knowledge MCP server を有効化します。 gcloud beta services mcp enable developerknowledge.googleapis.com 以下のメッセージが返却されたら、Developer Knowledge MCP server が有効化されます。 The MCP endpoint for service developerknowledge.googleapis.com has been enabled for the resource projects/プロジェクト名. ※ gcloud コマンドの実行中にエラーが発生した場合は、 gcloud components update beta コマンドでコンポーネントのアップデート後に再試行してください。 Gemini CLI の設定 作成した API キーを表示します。 Gemini CLI の構成ファイル（ .gemini/settings.json ）に MCP サーバーの設定を追加します。 { " mcpServers ": { " google-developer-knowledge ": { " httpUrl ": " https://developerknowledge.googleapis.com/mcp ", " headers ": { " X-Goog-Api-Key ": " 作成した API キー " } } } } MCP サーバーに接続できていれば、構成ファイルに記述した MCP サーバーと、使用できるツールの一覧が表示されます。 # Gemini CLI を起動 $ gemini # > /mcp Configured MCP servers: 🟢 google-developer-knowledge - Ready ( 3 tools ) Tools: - batch_get_documents - get_document - search_documents search_documents での検索 質問の投入 Gemini CLI に対して、以下のようなクエリを自然言語で投入します。 Google Cloud の API を有効化する Terraform のソースコードを Google の公式ドキュメントから検索してください。 入力したクエリに対して、Developer Knowledge MCP server の search_documents ツールを使用するか確認されます。 3. Allow all server tools for this session を選択すると、現在のセッション内では、Developer Knowledge MCP server の全てのツールの使用が許可されます。 検索と回答の流れ 入力した自然言語のクエリが、MCP サーバーへリクエストを送信するために JSON 形式に変換されます。 {"query":"Terraform enable Google Cloud API"} MCP サーバーから返却されたレスポンスに複数のドキュメントが格納されています。 レスポンスの JSON の構造は以下のとおりです。 { " results ": [ { " parent ":" 参照しているドキュメントのリソース名 ", " id ":" ドキュメント内のチャンク ID ", " content ":" チャンクしたドキュメントの内容 " } , ... } 取得した内容を元に、回答が生成されます。 get_document での検索 質問の投入 さらに詳細な情報が必要な場合は、以下のようなクエリを自然言語で投入します。 関連度の一番高いドキュメントを使用して、より詳細な情報を検索してください。 検索と回答の流れ 入力した自然言語のクエリに従って、 search_documents の検索結果から、関連度の高いドキュメントを判断し、MCP サーバーへリクエストを送信するために JSON 形式に変換します。 {"name":"documents/docs.cloud.google.com/docs/terraform/understanding-apis-and-terraform"} MCP サーバーから返却されたレスポンスに単一のドキュメントの詳細情報が格納されています。 レスポンスの JSON の構造は以下のとおりです。 { " name ":" 参照しているドキュメントのリソース名 ", " uri ":" 参照しているドキュメントの URI ", " content ":" Markdown 形式のドキュメントの内容 ", " description ":" ドキュメントの説明 " } 取得した内容を元に、より詳細な回答が生成されます。 AI 開発におけるドキュメント参照 例えば、以下のようなプロンプトを Gemini CLI に与えます。 組織 g-gen.co.jp の組織直下にある Google Cloud プロジェクトの一覧を取得する Python プログラムを記述して。 Google Cloud の Resource Manager API の情報を、公式ドキュメントから調べて確認してからプログラムの開発を始めて。 Gemini CLI は、必要なドキュメントを検索・取得して、コンテキストとして使いつつ、プログラムを記述します。 エージェンティックな開発の中で、適宜 Developer Knowledge MCP server を参照することで、開発の精度が向上することが期待できます。 また、必要なときには Developer Knowledge MCP server を参照するよう、 GEMINI.md などのコンテキストファイルに予めルールを記述することで、プロンプトで毎回記述する必要がなくなります。 参考 : Provide context with GEMINI.md files - Gemini CLI 参考 : Use the Gemini Code Assist agent mode - Gemini for Google Cloud 高宮 怜 (記事一覧) クラウドソリューション部クラウドエクスプローラ課 2025年6月より、G-genにジョイン。前職は四国のSIerで電力、製造業系のお客様に対して、PM／APエンジニアとして、要件定義から運用保守まで全工程を担当。現在はGoogle Cloudを学びながら、フルスタックエンジニアを目指してクラウドエンジニアとしてのスキルを習得中。 Follow @Ggen_RTakamiya