はじめに Gson について Gson の課題 1. Null 安全が破壊されるリスク 2. デフォルト引数が無視される Kotlin Serialization について 具体的な修正内容 1. Data Class の書き換え 2. Retrofit の Converter の置き換え まとめと今後の課題 はじめに こんにちは、株式会社エブリーで Android アプリ開発を担当している岡田です。 弊社が提供する デリッシュキッチン の Android アプリでは、アプリの堅牢性向上とモダンな開発体験のための選択として、JSON パーサーを従来の Gson から Kotlin Serialization への移行を検討しています。 今回は弊社で行なっているイベント「挑戦WEEK」にて、Gson から Kotlin Serialization への移行を、Android のコードベース変更に限定して挑戦してみました。こちらについて、少しお話しさせていただければと思います。 弊社の挑戦WEEKの取り組みについては以下の記事をご覧ください！ tech.every.tv Gson について Android アプリの開発において、API との通信で受け取った JSON をデータクラスに変換する「JSON パース」は避けては通れない実装です。 デリッシュキッチン の Android アプリでは、長らく JSON パーサーとして Google 製の「Gson」を利用してきました。Gson は非常に歴史が長く、Android アプリ開発の黎明期からデファクトスタンダードとして広く使われており、Retrofit などのネットワークライブラリとも標準で連携しやすいという特徴があります。 長年アプリの通信基盤を支えてくれた Gson ですが、プロジェクトのフル Kotlin 化が進み、よりモダンな言語仕様を活用していく中で、実は Android アプリを開発する上でいくつかの大きな課題を抱えるようになっていました。 Gson の課題 Java 時代には非常に優秀だった Gson ですが、Kotlin で構成された現代のアプリにおいては、Kotlin の強みである言語仕様とコンフリクトを起こすケースが目立つようになってきました。 1. Null 安全が破壊されるリスク Gson は内部でリフレクション（ sun.misc.Unsafe など）を用いてインスタンスを生成します。そのため、Kotlin のデータクラスでプロパティを「非 Null（ String など）」で定義していても、サーバーから返ってくる JSON 側にそのキーが存在しない場合、Gson は強制的に null を代入してしまいます。 これにより、Kotlin コンパイラが保証しているはずの「Null 安全」がランタイムで破壊され、アプリの思わぬところで NullPointerException を引き起こす原因となっていました。 2. デフォルト引数が無視される Kotlin のデータクラスでは val isPremium: Boolean = false のようにデフォルト引数を設定できます。しかし、Gson はコンストラクタを経由せずにインスタンスを生成することがあるため、JSON に該当のキーが含まれていない場合、このデフォルト値が適用されません。結果として、意図しない型の初期値（ Int なら 0 、参照型なら null ）が入ってしまうという問題がありました。 これらの挙動は、開発者が意図しない「不正な状態を持ったインスタンス」がアプリ内を回遊することを意味しており、結果として予期せぬクラッシュの温床になり得ます。 Kotlin Serialization について 最終的に、これらの課題を根本から解決するために、Kotlin 公式が提供しているシリアライズライブラリ「Kotlin Serialization（ kotlinx.serialization ）」へ移行を検討しています。 Kotlin Serialization は、コンパイル時にシリアライズ・デシリアライズのためのコードを自動生成する仕組みを持っています。実行時に重いリフレクションを行わないため、非常にモダンで Kotlin ライクな設計となっています。 このライブラリへ切り替えることで、以下のような大きな恩恵を受けることができます。 厳格な Null 安全の保証 非 Null として定義したプロパティに対して JSON に値が存在しない場合、強制的に Null を入れるのではなく、パース時に明確に例外（ SerializationException ）を投げてくれます。これにより、不正なデータによる後続処理でのクラッシュを防ぐことができます。 デフォルト値の完全なサポート JSON にキーが存在しない場合、Kotlin 側で定義したデフォルト引数が正しく適用されます。 パフォーマンス向上とアプリサイズ削減 リフレクションに依存しないため、パース速度が向上します。また、ProGuard/R8 による最適化とも相性が良く、アプリのバイナリサイズの削減にも繋がります。 具体的な修正内容 実際に Gson から Kotlin Serialization へ移行するにあたり、行った具体的な修正内容をご紹介します。 1. Data Class の書き換え Gson の @SerializedName アノテーションを、Kotlin Serialization の @SerialName に変更し、クラスに @Serializable アノテーションを付与します。 【従来の Gson での実装】 data class UserResponse( @SerializedName ( "id" ) val id: Long , @SerializedName ( "user_name" ) val userName: String , @SerializedName ( "profile_image_url" ) val profileImageUrl: String ? ) 【新しい Kotlin Serialization での実装】 @Serializable data class UserResponse( @SerialName ( "id" ) val id: Long , @SerialName ( "user_name" ) val userName: String , // サーバーからキーが送られてこない可能性がある場合はデフォルト値を設定 @SerialName ( "profile_image_url" ) val profileImageUrl: String ? = null , @SerialName ( "is_premium" ) val isPremium: Boolean = false ) 2. Retrofit の Converter の置き換え API 通信に Retrofit を使用しているため、Gson の ConverterFactory を Kotlin Serialization 用のものへ差し替えました。 この際、サーバーからのレスポンスにおいて、アプリ側で定義していない未知のキーが含まれていてもパースエラーにならないよう、 ignoreUnknownKeys = true を設定しています。 // Json パーサーの設定 val json = Json { ignoreUnknownKeys = true // 未知のキーを無視する coerceInputValues = true // null が来た場合にデフォルト値があればフォールバックする } val contentType = "application/json" .toMediaType() val retrofit = Retrofit.Builder() .baseUrl( "https://api.example.com/" ) // GsonConverterFactory.create() からの置き換え .addConverterFactory(json.asConverterFactory(contentType)) .build() 主にこれらの修正を、API レスポンスを受け取る全てのデータクラスと Retrofit クライアントに対して適用し、段階的に移行を進めました。 また他にも com.google.gson.internal.bind.util.ISO8601Utils を利用している箇所や、 JsonUtil という Android アプリ側で Json を扱う際に使用するクラスの修正など、細かい修正も行いました。 総差分ファイル数はおよそ 500 ファイルと、大規模な改修になりました。 まとめと今後の課題 今回の改修で JSON パーサーを Kotlin Serialization に移行したことにより、Kotlin の言語仕様に沿った厳格な型安全性が担保されます。Android のコードベース上での堅牢性は大きく向上しました。 しかし、ライブラリが「厳格」になったからこそ直面する新たな課題もあります。 それは、 サーバーからのレスポンス仕様（スキーマ）の正確な把握 です。 Gson の時代は「JSON にキーがなくても、とりあえず Null を入れてクラッシュさせない」という緩さがありました。しかしこれからは、非 Null プロパティのキーが JSON に存在しなければ、即座にパース失敗となってしまいます。 これを防ぐためには、以下のような対応をサービス全体で意識していく必要があります。 サーバーレスポンスで Null が返る、またはキーが省略される可能性のあるフィールドには、適切な Nullable 定義やデフォルト値を設定する クラッシュログを監視し、パースエラーが発生した場合は迅速にデータクラスの定義をチューニングする サーバーサイドのエンジニアと密に連携し、API 仕様書とクライアント実装の乖離をなくす デリッシュキッチンは歴史のあるサービスですから、型安全に API レスポンスをパースするには、この辺りの見直しは避けて通れません。 時間と根気がいる作業にはなりますが、徐々にでも整備できればと思います。 もしまだ Gson を利用している方で、「データクラスの Null 安全が担保できずに困っている」「原因不明の NullPointerException に悩まされている」と感じているなら、一度 JSON パーサーの移行を検討してみてはいかがでしょうか。 今後も、Kotlin の厳格な型安全性を武器に、より品質が高く安定した デリッシュキッチン をユーザーの皆様にお届けできるよう、改善を続けていきます。

こんにちは。Yahoo!オークションでAndroidアプリの開発を担当している高松です。2025年11月1日（土）に開催されたKotlin Fest 2025にて、LINEヤフー株式会社は「ことりプラ...

本記事は「 Open weight models are here: more choice, more speed, less cost 」を翻訳したものです。 当初から、私たちは Kiro を最高の AI コーディング体験を提供できるように構築してきました。それは、現在の最先端コーディングモデルを搭載し、高品質な出力を中心にすべてを構築することを意味していました。6 ヶ月前、私たちは Auto を導入しました。これは、フロンティアモデルと特化型モデルを組み合わせ、インテント検出、キャッシング、その他の最適化技術を重ねることで、パフォーマンス、効率性、出力品質に優れたバランスを提供するエージェントモードです。本日、Kiro にオープンウェイトモデルを追加し、IDE と CLI の両方で利用可能になりました。 速度、品質、コスト効率の優れた組み合わせ 私たちはオープンウェイト分野を注意深く見守ってきましたが、その進歩は目覚ましいものがあります。1 年前であればプロプライエタリなオプションに大きく遅れをとっていたであろうモデルが、今では多くの開発タスクにおいて真に競争力のある結果を提供しています。高速で、コスト効率が良く、そして改善を続けています。多くの方々がこれらのモデルを独自に試し、直接サポートするよう私たちに要望を寄せてくださいました。その声をお聞きしました。 オープンウェイトモデルは、作業方法においてより多くの選択肢を提供します。すべてのタスクが最も重いモデルを必要とするわけではありません。クイックイテレーション、ボイラープレート生成、単純なリファクタリングには、生の推論能力よりも速度と低コストが必要です。他のタスクは、強力なエージェント機能や特化した言語サポートを必要とします。さまざまなモデルを持つことで、仕事に合わせてツールを選択できます。 モデル 本日から利用可能になるモデルと、それぞれが優れている分野をご紹介します。 DeepSeek v3.2 (0.25x クレジット) — スパース Mixture-of-Experts アーキテクチャに基づいて構築された DeepSeek v3.2 は、タスクごとに必要なパラメータのみをアクティブ化します。エマルチステップのツール呼び出し、長いセッション全体での状態維持、複雑な推論チェーンなど、エージェントワークフローに優れています。初期コード生成には優れていますが、複雑なデバッグやコードレビューの品質には課題がある場合があります。エージェントを構築している場合や、複雑なデバッグセッションに取り組んでいる場合は、これが強力な選択肢です。 MiniMax 2.1 (0.15x クレジット) — このモデルは多言語プログラミングで際立っています。Rust、Java、Go、C++、Kotlin、TypeScript、JavaScript などで優れた結果を提供します。また、Web、Android、iOS の UI 生成機能も特に優れています。開発者は、フロンティアモデルと比較して複雑なリファクタリングタスクに苦労する可能性があることに気づいています。チームが複数の言語で作業している場合や、フロントエンド開発が多い場合は、MiniMax 2.1 を試す価値があります。 Qwen3 Coder Next (0.05x クレジット) — トークンあたりわずか 3B パラメータをアクティブ化する 80B スパース MoE モデルである Qwen3 Coder Next は、コーディングエージェント向けに特別に構築されています。SWE-Bench Verified で 70% 以上のスコアを獲得し、256K コンテキストをサポートし、エラー検出、リカバリ、ツール呼び出しにおいて強力な機能を持っています。コミュニティは、より一貫した結果を得るために慎重な設定が必要な互換性と統合の課題をいくつか指摘しています。長いエージェントコーディングセッションを確実に処理する効率的なモデルが必要な場合、特に CLI では、Qwen3 を試してみてください。 IDE と CLI で試してみてください すべてのモデルは、 IDE モデルセレクター と Kiro CLI で実験的サポートとして現在利用可能で、Google、GitHub、AWS BuilderID でログインする無料ユーザーと有料ユーザーの両方が利用できます。推論は AWS US East (N. Virginia) リージョンで実行されます。モデルを切り替えたり、Auto と組み合わせたり、特定のプロジェクトタイプのデフォルトを設定したりできます。いつものように、実験して これらがどのように機能しているかお知らせください 。どのモデルが共感を呼び、どのようなギャップが残っているかに細心の注意を払っています。次にサポートしてほしいモデルがある場合は、 お知らせください 。