はじめに Webアプリケーションの回帰テストを自動化する際、適切なツールの選択は品質保証とチームの生産性に大きく影響します。 プロジェクト背景 KINTOテクノロジーズ（以下、KTC）では、これまでAutify NoCodeWebを活用して回帰テストの自動化を進め、品質保証体制を構築してきました。Autify NoCodeWebのノーコードプラットフォームは、QA専任メンバーが中心となってテスト自動化を迅速に導入する上で非常に有効であり、多くの成果を上げてきました。 しかし、プロジェクトの成長に伴い、新たな課題も見えてきました: より高速なテスト実行が求められるようになった CSVファイルの編集・アップロードなど、複雑なファイル操作を伴うテストシナリオの増加 データ駆動テストによる大量のテストパターンの実行ニーズ エンジニアチームの拡大により、コードベースのテスト資産の管理が可能になった このような背景から、現在のKTCの体制と要件に最適なツールを再検討する必要が生じました。本記事では、これまでお世話になってきたAutify NoCodeWebと、新たな選択肢としてのPlaywrightを、実際の回帰テストシナリオにおいて詳細に比較します。 どちらのツールも優れた特徴を持っており、組織の状況によって最適な選択は異なります。本記事が、皆様のツール選定の一助となれば幸いです。 ツール概要 Playwright 開発元: Microsoft タイプ: オープンソースのE2Eテストフレームワーク 対応言語: JavaScript/TypeScript、Python、.NET、Java 対応ブラウザ: PC：Chromium（Chrome、Edge）、Firefox、WebKit（Safari相当） モバイル：デバイスエミュレーション（Chromium、WebKit） 　※実機のモバイルブラウザ操作は非対応 特徴: コードベースで柔軟性が高く、高速な実行速度 Autify NoCodeWeb 開発元: オーティファイ株式会社（日本企業） タイプ: ノーコードAI搭載テスト自動化プラットフォーム 対応ブラウザ: PC：Chrome、Edge、Firefox、Safari（WebKit） モバイル：iOS、Android 特徴: 操作をレコーディングしてテストシナリオを作成、AI による要素認識と自動修復機能 ツール選択のためのデシジョンフローチャート 自社に最適なツールを選ぶ際の判断フローを視覚化しました。このフローチャートを参考に、組織の状況に応じた選択を行ってください。 graph TD Start[QAチームにプログラミング可能なエンジニアがいる] Start -->|No| AutifyNoCodeWeb1[Autify NoCodeWeb: ノーコードで容易、迅速な導入、AI自動修復] Start -->|Yes| Speed{実行速度を重視?} Speed -->|Yes| Playwright1[Playwright: 高速、柔軟、無料] Speed -->|No| Requirements{要件に応じて選択} Requirements -->|インフラ管理は避けたい| AutifyNoCodeWeb2[Autify NoCodeWeb] Requirements -->|メール連携や頻繁なUI変更がある| AutifyNoCodeWeb2 Requirements -->|コストを優先したい| Playwright2[Playwright] Requirements -->|データ駆動テストや複雑なファイル操作がある| Playwright2 フローチャートの使い方 このデシジョンフローは、以下の優先順位で判断することを推奨しています： チーム構成の確認: まず、開発チームにプログラミング可能なエンジニアがいるかを確認します。エンジニアリソースが限られている場合は、Autify NoCodeWebが最適な選択となります。 実行速度の重視度: エンジニアがいる場合、次に実行速度の重要性を評価します。CI/CDパイプラインでの高速フィードバックが重要な場合、Playwrightが適しています。 詳細要件の評価: 実行速度がそれほど重要でない場合は、具体的なテスト要件に基づいて判断します： graph LR C1[インフラ管理は避けたい] --> AutifyNoCodeWeb[Autify NoCodeWeb] C2[メール連携や頻繁なUI変更がある] --> AutifyNoCodeWeb[Autify NoCodeWeb] C3[コストを優先したい] --> Playwright C4[データ駆動テストや複雑なファイル操作がある] --> Playwright ハイブリッドアプローチの検討: 上記の要件が混在している場合、両ツールを併用するハイブリッドアプローチも有効な選択肢です。 機能別詳細比較 # 比較項目 Playwright Autify NoCodeWeb 1 CSVの編集とアップロード ✅ 可能 ⚠️ 制限あり 2 特定ファイルのダウンロード ✅ 可能 ⚠️ 検証に制限 3 特定ステップのスクリーンショット ✅ 柔軟なカスタマイ즈可能 ✅ 自動取得で便利 4 画面上の文字状態の判断 ✅ 詳細な検証可能 ✅ AI認識で安定 5 データ駆動テストの循環使用 ✅ 可能 ⚠️ 制限あり 6 異なる画面間の切り替え ✅ 完全対応 ✅ 対応 7 外部メール内容の確認 ✅ API連携で対応可能 ✅ 統合機能で便利 8 動的要素のロケート ✅ 高精度な制御 ✅ 高精度な制御 / JS指定 9 画面の比較(VRT) ✅ ピクセル単位の精密比較 ✅ AI支援で大規模変更に対応 10 スクリプトの実装難易度 ⚠️ プログラミングスキル必要 ✅ ノーコードで容易 11 スクリプトの修正難易度 ✅ テキスト編集で迅速 ⚠️ GUI操作が必要 12 スクリプトの実行速度 ✅ 基準速度 (高速) ⚠️ 比較的遅い傾向 1. CSVの編集とアップロード Playwrightの場合: input[type="file"] 要素に対して setInputFiles() メソッドを使用することで、CSVファイルのアップロードが柔軟に実装できます。また、ファイルの動的生成やデータ駆動テストとの組み合わせも可能です。コードベースの利点を活かし、複雑なファイル操作シナリオに対応できます。 Autify NoCodeWebの場合: 基本的なファイルアップロード機能は提供されていますが、複雑なCSV編集を伴うシナリオには制約があります。シンプルなファイルアップロードであれば、ノーコードで簡単に実装できる点は大きなメリットです 2. 特定ファイルのWebページからのダウンロード Playwrightの場合: page.waitForEvent('download') を使用してダウンロードイベントを捕捉し、ファイル名や内容の検証まで完全に制御できます。ダウンロードしたファイルの内容を自動的に検証するシナリオも実装可能です Autify NoCodeWebの場合: ダウンロード操作の記録と実行は可能です。基本的なダウンロード動作の確認には十分対応しており、ノーコードで実装できる利点があります。より詳細なファイル検証が必要な場合は、他の手段との組み合わせを検討する必要があります。 3. 特定ステップのスクリーンショット Playwrightの場合: page.screenshot() や locator.screenshot() を使用して、任意のタイミングで全画面または特定要素のスクリーンショットを取得できます。保存先やファイル名も自由に設定可能で、細かい制御が必要な場合に優れています Autify NoCodeWebの場合: 全てのテストステップで自動的にスクリーンショットが撮影されるため、設定の手間が不要です。テスト失敗時の原因調査が容易になり、特にテスト自動化に不慣れなメンバーでも、確実に証跡を残せる点が優れています。 4. 画面上の文字状態の判断 Playwrightの場合: expect(locator).toHaveText() 、 toContainText() 、 toBeVisible() など、豊富なアサーションメソッドで文字列の存在、内容、表示状態を詳細に検証できます。正規表現による柔軟なパターンマッチングも可能で、複雑な検証ロジックに対応できます。 Autify NoCodeWebの場合: テキストの存在確認や表示状態の検証が可能です。特にAIによる要素認識により、画面デザインが変更されても同じテキスト要素を識別できる点が優れています。HTMLの細かい変更に強く、メンテナンスコストを削減できます 5. データ駆動テストの循環使用 Playwrightの場合: テストデータを配列やCSVファイルから読み込み、 test.describe() やforループを使用して複数のデータセットで同じテストロジックを実行できます。テストの再利用性が非常に高く、大量のテストパターンを効率的に実行できます。 // CSVファイルからデータを読み込む testData = await readCSV('C:\\××××××××\\testData4.csv'); for (const data of testData) { const { password, surname, katakanaSurname, yearOfBirth, monthOfBirth, dayOfBirth, sex, postCode1, postCode2, cellphoneNumber1, cellphoneNumber2, cellphoneNumber3, typeOfHousing, yearsOfResidence, numberOfPeople1, numberOfPeople2, annualIncome, purposeOfUser, licenseNumber, route, fileName, profession, corporateName, positionOfCorporateName, nameOfCorporate, katakanaNameOfCorporate, department, postCodeOfCorporate1, postCodeOfCorporate2, cellphoneNumberOfCorporate1, cellphoneNumberOfCorporate2, cellphoneNumberOfCorporate3, lengthOfWork } = data; Autify NoCodeWebの場合: 個別のテストシナリオを作成することで、複数のパターンに対応できます。ノーコードで各シナリオを管理できるため、プログラミングの知識がなくても運用可能な点がメリットです。ただし、データ量が多い場合はシナリオ数が増加します。 6. 異なる画面間の切り替え Playwrightの場合: 複数タブ、複数ウィンドウ、iframe間の切り替えを完全にサポートしています。 page.context().pages() で全ページを取得したり、 page.waitForEvent('popup') で新しいページを待機することができます。複雑な画面遷移ロジックも実装可能です。 Autify NoCodeWebの場合: 画面遷移やタブ切り替えの操作を記録・実行できます。基本的な画面間の移動には十分対応しており、ノーコードで実装できる利点があります。 7. 外部メール内容の確認（URLのクリックなど） Playwrightの場合: メールテストAPIサービス（例：MailSlurp、Mailinator）と連携してメール内容を取得し、URLを抽出してナビゲーションすることが可能です。柔軟な連携が可能ですが、追加の実装とAPI費用が必要になる場合があります。 Autify NoCodeWebの場合: メール検証機能がプラットフォームに組み込まれており、追加の設定や実装なしでメール内のリンクをクリックしたり、内容を確認したりできます。この統合機能は大きな強みであり、特に非エンジニアのQAメンバーでも簡単に利用できる点が優れています。 8. XPathなどによる頻繁に変動する要素のロケート Playwrightの場合: CSS Selector、XPath、text、roleなど、多様なロケーター戦略をサポートしています。複数のロケーターを組み合わせたり、厳密な条件指定が可能で、動的要素に対しても高い精度で特定できます。 # ENT番号取得 xpath1 = '//*[@id="app"]/div/main/div/div[1]/div[1]/div[2]/div/div[3]/div[1]' display_text1 = (await page.locator(f'xpath={xpath1}').text_content() or '').strip() last1 = display_text1[-5:] shinsa_number = '97016QAP00' + last1 # メールアドレス取得 xpath2 = '//*[@id="app"]/div/main/div/div[1]/div[1]/div[2]/div/div[7]/div[2]' display_text2 = (await page.locator(f'xpath={xpath2}').text_content() or '').strip() # 名前取得 xpath0 = '//*[@id="app"]/div/main/div/div[1]/div[1]/div[2]/div/div[7]/div[1]/a' display_text0 = (await page.locator(f'xpath={xpath0}').text_content() or '').strip() lastname = display_text0[4:] Autify NoCodeWebの場合: AIによる要素認識を採用しており、HTMLが変更されても要素を識別しようとします。この機能は画面の小規模な変更に対して非常に強く、手動でのメンテナンスを大幅に削減できます。特にデザイン調整が頻繁に行われる開発フェーズでは、この自動修復機能が大きな価値を発揮します。複雑な動的要素については、認識精度を確認しながら運用することが推奨されます。 そして、Javascriptによって要素の指定も簡単にできます。 function getEmailInputValue() { var selector = "#__next > main > div > div > div.o-emailPasswordForm > div > div.m-inputField > div:nth-child(1) > div > div.m-inputField__container > div > div > input[type=email]"; var element = document.querySelector(selector); if (!element) { throw new Error("Error: cannot find the element with selector(" + selector + ")."); } return element.value; } // 実行例 console.log(getEmailInputValue()); 9. 画面の比較（ビジュアルリグレッションテスト） Playwrightの場合: toHaveScreenshot() メソッドでピクセルレベルの画面比較が可能です。差分の許容範囲を設定したり、特定領域をマスクしたりできます。細かい視覚的変更の検出に優れており、意図しないUI変更を確実に捉えます Autify NoCodeWebの場合: 画面全体の変更を検出し、AIが変更箇所を識別します。特に大規模なデザイン変更時には、変更点の確認とテストシナリオの更新が比較的容易です。AIによる変更の影響分析機能により、どのテストシナリオを更新すべきかの判断がしやすく、大規模リニューアル時のメンテナンス工数を削減できる点が優れています。 10. スクリプトの実装難易度 Playwrightの場合: JavaScript/TypeScriptなどのプログラミング言語とテストフレームワークの知識が必要です。習得には一定の時間がかかりますが、公式ドキュメントが充実しており、コミュニティも活発です。エンジニアチームが確立されている組織に適しています。 Autify NoCodeWebの場合: ブラウザ操作を記録するだけでテストシナリオが作成できるため、プログラミング経験がない非エンジニアでも容易に使用できます。この実装の容易さは、Autify NoCodeWebの最大の強みの一つです。QA専任メンバーが主体となってテスト自動化を推進できるため、エンジニアリソースが限られている組織や、迅速にテスト自動化を開始したい場合に特に有効です。 11. スクリプトの修正難易度 Playwrightの場合: テキストエディタでスクリプトを直接編集できるため、小規模な修正は数秒で完了します。バージョン管理システム（Git）との親和性も高く、差分確認やロールバックが容易です。複数人での並行開発やコードレビュー文化とも相性が良いです。 Autify NoCodeWebの場合: GUI上で操作を再記録するか、手動で修正する必要があります。ただし、AIによる自動修復機能により、画面の小規模な変更には自動的に対応されるため、実際の修正作業は最小限に抑えられます。この自動修復機能は、メンテナンスコストの削減に大きく貢献します。 12. スクリプトの実行速度 Playwrightの場合: ヘッドレスモードでの実行やネットワークリクエストの最適化により、非常に高速なテスト実行が可能です。並列実行にも標準対応しており、大規模なテストスイートでも短時間で完了します。 Autify NoCodeWebの場合: クラウドベースのプラットフォームであり、ネットワークレイテンシーや処理のオーバーヘッドにより、Playwrightと比較して実行速度が遅くなる傾向があります。ただし、実際の速度差はテストケースの複雑さ、ネットワーク環境、Autify NoCodeWebのサーバー負荷などの要因によって大きく変動する可能性があります。大規模なテストスイートでは実行時間が増加する可能性がありますが、並列実行機能を活用することで全体の実行時間を最適化できます。 :::message 実行速度は環境やテストケースによって大きく異なるため、具体的な数値比較は控えます。各ツールの特性を理解し、実際の使用環境でのパフォーマンスを評価することをお勧めします。 ::: 追加の比較ポイント 📊 要約比較表 項目 Playwright (エンジニア主導) Autify NoCodeWeb (QA・非エンジニア主導) コスト 完全無料 (OSS) サブスクリプション型 (有料) 導入障壁 プログラミングスキルが必要 低い (ノーコードで即時開始) CI/CD 柔軟かつ強力な統合 シンプルなAPI連携 メンテナンス コードベース・Git管理 AIによる自動修復 (Self-healing) 1. コストと導入障壁 Playwright: 完全無料のオープンソース 学習コストは必要だが、長期的なランニングコストはゼロ CI/CD環境への組み込みも容易 エンジニアチームの人件費は考慮が必要 Autify NoCodeWeb: サブスクリプション型の有料サービス 初期導入が簡単で、迅速にテスト自動化を開始できる テストシナリオ数や実行回数に応じた費用体系 インフラ管理コストが不要 エンジニアリソースが限られている場合、トータルコストで優位性がある場合も 2.チーム構成との適合性 Playwrightが適しているチーム: エンジニア主導のQA体制が整っている コードレビュー文化が定着している 複雑なテストロジックや高度なカスタマイズが必要 Git等のバージョン管理システムを活用している Autify NoCodeWebが適しているチーム: QA専任メンバーが中心（プログラミング経験が少ない） エンジニアリソースが限られている 迅速にテスト自動化を開始したい メンテナンスコストを抑えたい（AIによる自動修復活用） ノーコードでテスト資産を管理したい 3. CI/CD統合 Playwright: GitHub Actions、GitLab CI、Jenkins など主要CI/CDツールとの統合が容易 テスト結果のレポート生成、アーティファクト保存が柔軟 並列実行、シャーディングなど高度な実行戦略が可能 開発フローに深く統合できる Autify NoCodeWeb: APIを介したCI/CD統合が可能 独自のテスト実行環境を使用 クラウドベースのため、インフラ管理不要 CI/CD統合の設定がシンプル 4.メンテナンス性と長期運用 Playwright: スクリプトをバージョン管理できる リファクタリングやスクリプトの再利用が容易 コミュニティが活発で、最新のベストプラクティスにアクセスしやすい 長期的なスクリプト資産の管理に優れる Autify NoCodeWeb: AIによる要素の自動認識で、画面変更時のメンテナンス工数を削減 自動修復機能により、軽微な変更への対応が自動化される プラットフォーム上での一元管理が可能 ノーコードのため、担当者の変更による影響が少ない それぞれのツールが特に優れているシーン Playwrightが最適なケース 大量のデータパターンテスト: 同一ロジックで数百〜数千パターンのテストデータを処理する必要がある場合 高頻度の実行: CI/CDパイプラインで1日に何度もテストを実行し、迅速なフィードバックが必要な場合 複雑なファイル操作: CSV編集、複数ファイルの同時アップロード、ダウンロードファイルの内容検証など エンジニア主導のQA: 開発チームとQAチームが密接に連携し、テストスクリプトもコードレビューの対象とする場合 長期的な資産管理: テストスクリプトをソースコードと同様に管理し、継続的に改善していく場合 Autify NoCodeWebが最適なケース 迅速な導入: プログラミング経験のないQAメンバーが、短期間でテスト自動化を開始したい場合 メール連携テスト: 外部メールの検証を含むシナリオが多い場合 頻繁なUI変更: デザイン調整が頻繁に行われる環境で、AI自動修復機能を活用したい場合 インフラ管理の負担軽減: テスト実行環境の構築・管理リソースが限られている場合 ノーコード資産管理: テスト資産をコード化せず、ビジュアルに管理したい場合 大規模リニューアル: 画面全体の大幅な変更時に、AIによる影響分析と効率的な更新が必要な場合 KTCにおける選択理由 KTCでは、これまでAutify NoCodeWebによって品質保証の基盤を築いてきましたが、プロジェクトの成長と共にいろいろな課題が顕在化しました。（上記のプロジェクト背景で述べた課題） これら課題を解決する選択肢として、Playwrightを導入することにしました。ただし、これはAutify NoCodeWebを完全に置き換えるものではありません: Playwrightが担う領域: データ駆動テスト、高速実行が求められるCI/CD統合、複雑なファイル操作を伴うシナリオ Autify NoCodeWebが引き続き価値を発揮する領域: メール連携テスト、ノーコードで管理すべきシナリオ、QA専任メンバーが主導するテスト 両ツールの強みを活かしたハイブリッドアプローチにより、KTCの品質保証体制をさらに強化していく予定です。 まとめ：どちらを選ぶべきか Playwrightの主な強み: 高速な実行速度 柔軟なカスタマイズ性 精密な要素制御とデータ駆動テスト オープンソースでコストゼロ バージョン管理システムとの親和性 Autify NoCodeWebの主な強み: ノーコードで実装が容易 AIによる自動修復でメンテナンスコスト削減 統合されたメール検証機能 非エンジニアでも運用可能 インフラ管理不要 最適な選択は、組織の状況によって異なります: エンジニアリソースが限られ、迅速にテスト自動化を開始したい → Autify NoCodeWeb エンジニアチームが確立され、高度なカスタマイズと高速実行が必要 → Playwright 両方のメリットを活かしたい → ハイブリッドアプローチ どちらのツールも、現代のWebアプリケーション開発において品質を担保するための重要な選択肢です。本記事の比較内容を参考に、自社のチーム構成、スキルセット、プロジェクト要件、予算、長期的な運用計画などを総合的に考慮して、最適なツールを選定してください。 Autifyは世界中で支持されているノーコードテスト自動化プラットフォームであり、特にエンジニアリソースが限られている組織において、品質保証体制を迅速に構築できる優れたソリューションです。KTCも、Autifyのサービスを通じて多くの成果を上げてきました。 今後も、両ツールの進化に注目し、それぞれの強みを最大限に活用していくことが重要です。

はじめに 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 の厳格な型安全性を武器に、より品質が高く安定した デリッシュキッチン をユーザーの皆様にお届けできるよう、改善を続けていきます。

現在、AI がメインフレームアプリケーションのモダナイゼーションを可能にすることについて、大きな期待が寄せられています。企業の取締役会は注目しています。CIO はプランを求められています。AI は COBOL のモダナイゼーションを加速する真のアクセラレーターです。しかし、確かな結果を得るには、ソースコードだけでは提供できない追加のコンテキストが必要です。400 社を超える企業顧客と一緒に仕事をした経験から私たちが学んだことは、メインフレームのモダナイゼーションには 2 つのまったく異なる側面があるということです。前半はリバースエンジニアリングで、既存のシステムが実際に何をするのかを理解します。後半は、新しいアプリケーションを構築するフォワードエンジニアリングです。 メインフレームプロジェクトが生き残るか死ぬかは前半で決まります。一方、コーディングアシスタントが本当に優れているのは後半だけです。明確で検証済みの仕様を提供すれば、モダンなアプリケーションを素早く構築できます。 COBOL のモダナイゼーションを成功させるには、決定論的にリバースエンジニアリングを行い、検証済みで追跡可能な仕様を生成し、それらの仕様をフォワードエンジニアリング用の AI 搭載コーディングアシスタントに流し込むことができるソリューションが必要である、ということを私たちは学びました。モダナイゼーションを成功させるには、リバースエンジニアリングとフォワードエンジニアリングの両方が必要です。 メインフレームのモダナイゼーションを成功させるために必要なこと 対象範囲内の全てを含む完全なコンテキスト メインフレームアプリケーションは大規模です。実に大きい。1 本のプログラムが何万行のこともあり、システム全体で共有しているデータ定義を取り込んだり、他のプログラムを呼び出したり、環境全体にわたる JCL を介してオーケストレーションされている場合があります。現在、AI が一度に処理できるコードの量は限られています。1 本のプログラムを生成 AI に入力しただけでは、そのプログラムから参照されるコピーブック、呼び出されるサブルーチン、共有ファイル、これら全てを結び付ける JCL があっても、関連するコード一式を生成 AI が見に行くことはできません。対象のコードに対して一見妥当に見える出力が生成されますが、不可視だった依存関係は見逃されます。お客様との共同作業では、まず暗黙の依存関係をすべて決定論的に抽出し、対象範囲内で必要なものすべてを特定済の完全なものとして AI に供給することで、この問題を解決します。そうすれば、AI は実際には見えていない関連性を推測で補おうとしなくても良くなり、得意なこと (ビジネスロジックの理解、仕様の生成) に集中できます。 各プラットフォームに固有のコンテキスト 同じ COBOL ソースコードでも、実行するコンパイラおよびランタイムによって動作が異なり、驚くことがあります。数値が四捨五入される仕組み、データがメモリー内にどのように配置されるか、プログラムがミドルウェアと通信する方法。これらはソースコードには書かれていません。これらは、コードをビルドする特定のコンパイラと、デプロイ先の特定のランタイム環境によって決まります。ハードウェアとソフトウェアの組み合わせで何十年にもわたって実行されてきた結果は、別のプラットフォームにコードを移動するだけで単純に再現できるものではありません。AI は、プラットフォーム固有の動作が既に解決済の場合に最も効果を発揮することがわかりました。クリーンで、プラットフォームを意識したインプットを AI に提供すれば、それが実現します。生のソースコードをそのまま生成 AI にインプットすると、一見正しく見えても、元のアウトプットと異なる結果が生成されることがあります。金融システムでは、四捨五入の差は見かけ上の問題ではありません。これは重大な誤差です。 トレーサビリティの基礎 銀行、保険、政府関係者の場合、規制当局からある質問を受けることになります。それは、何も見落としていないことを証明できるか、ということです。ビジネスロジックを抽出し、規制当局が受け入れ可能な文書を生成するには、AI だけでは不十分です。規制遵守のためには、すべてのアウトプットが元のシステムに正式かつ監査可能な形で結び付けられている必要があります。AI によるソースコードの読み取りだけからトレーサビリティが得られないことは、早い段階で学びました。正確で特定の単位にコードを構造化することで、AI に何が入るかを正確に把握し、すべての出力をそのソースまで追跡できるようになります。規制の厳しい業界のお客様にとって、これは多くの場合、プロジェクトが進むか行き詰まるかの分かれ目になります。 AI をどのように設定したことで AWS Transform が成功したか 私たちは、大規模なメインフレームアプリケーションをモダナイズするために AWS Transform を構築しました。アイデアは単純明快です。AI に適切な基盤を提供すれば、お客様はトレーサブルで正確かつ完全な結果を得て、本番環境に持ち込むことができます。AWS Transform は、まずアプリケーションの完全で決定論的なモデルを構築することから始めます。システム全体 (一度に 1 本のプログラムではなく、対象のコード一式) のコード構造、実行時の動作、データ間の関連を、専門的に特化したエージェントが抽出します。これにより、実際のコンパイラのセマンティクスに沿った依存関係グラフを構成し、AI が関与する前に、プログラム間の依存関係、ミドルウェアのやり取り、プラットフォーム固有の動作をキャプチャします。そこから、大規模なプログラム群は、処理可能な単位にグループ化されます。プラットフォーム固有の動作は決定論的に解決されます。AI が効果的に処理できるよう、各グループに上限サイズを設定できます。次に AI がビジネスロジックを自然言語で抽出し、既に抽出済の決定論的なエビデンスと、すべての出力を照らし合わせて検証します。スペック(仕様)は元のコードにマッピングされます。規制当局の「何か見落としはありましたか?」という問いに対して、検証可能な答えがあります。このように明解に言い切ることができるのは、AI の動作に透明性があるためです。AI によるすべての処理単位には、既知のインプットと期待されるアウトプットがあるため、何が戻されるか検証することができます。メインフレームモダナイゼーション市場において、生成 AI でこのようなクローズドループを実現するアプローチは、他にありません。出力されるのは、あらゆるモダンな開発環境に対応する、検証済みでトレーサブルな技術仕様一式です。モダナイゼーションで難しいのは、現在存在しているものを理解することです。それを正確な仕様で把握できれば、AI 搭載の IDE は自信を持って新しいアプリケーションを構築することができます。 エンタープライズトランスフォーメーションのための end-to-end のプラットフォーム 単一のアプリケーションだけをモダナイズする人はいません。AWS のお客様は、何百、何千もの相互に接続されたアプリケーションのポートフォリオに注目していますが、必要としているのは分析の支援だけで無く、それ以外にもあります。AWS Transform は、分析、テスト計画、リファクタリング、reimagine といったライフサイクル全体を自動化します。これら全て。そしてその中でも、アプリケーションが異なれば、モダナイゼーションで辿る経路も異なります。中にはゼロから reimagine されるものもあります。Java へのクリーンで決定論的な変換だけが必要なものもあります。中には、まずワークロードをデータセンターから出すことを優先して、その後でモダナイズする企業もあります。一部はメインフレームに残るものもあります。それらをすべて同じように扱うとプロジェクトが爆発するということを私たちは苦労の末に学びました。ポートフォリオの決定 (どのアプリケーション、どのパス、どの順序) は、テクノロジーと同じくらい重要です。私たちの経験では、これが企業のモダナイゼーションを実際に完了する唯一の方法です。単一のソリューションで全てを解決しようとするアプローチこそが、これらのプロジェクトが失敗する理由です。もう 1 つ見過ごされがちなのは、テストデータです。リアルな本番データとリアルなシナリオがなければ、モダナイズされたアプリケーションが機能することを証明することはできません。チームがコード変換を最後までやり遂げたのに、誰もデータキャプチャを計画していなかったため行き詰まるのを目撃したこともあります。そこで、私たちはテスト計画を作成し、オンプレミスデータのキャプチャと移行先プラットフォームへの取り込みを初日から構築し始めました。最後のクリーンアップ作業ではありません。実際にうまく行った時は、このような感じです。End-to-end の自動化、各アプリケーションに適したパス、検証を視野に入れた機能が組み込まれています。 うまく行う方法 問題は「COBOL のモダナイゼーションに AI を使うべきか」ということではありません。もちろんそうすべきです。規制当局のトレーサビリティや、プラットフォーム固有の動作の適切な処理、アプリケーションポートフォリオ全体の一貫性、数百の相互接続されたプログラムにまで適用を広げることなど、AI をどのように設定して実現するかということが問題なのです。それこそが、私たちが AWS Transform を構築するときに考え出したことです。基礎としての決定論的分析。アクセラレータとしての AI。あらゆるモダナイゼーションパターンをカバーする AWS サービス。 そして、これらの工夫が実際に機能しています。 BMW Group はテスト時間を 75% 短縮し、テスト対象範囲を 60% 拡大したことで、モダナイゼーションのスケジュールを加速させながらリスクを大幅に軽減しました。 Fiserv は、29 か月以上かかったメインフレームモダナイゼーションプロジェクトを、わずか 17 か月で完了しました。 Itau はメインフレームアプリケーションのディスカバリー時間とテスト時間を 90% 以上削減し、チームは以前の手作業よりも 75% 速くアプリケーションをモダナイズできるようになりました。 著者 Dr. Asa Kalavade Asa は AWS Transform をリードし、お客様のインフラストラクチャ、アプリケーション、コードの移行とモダナイゼーションを支援しています。以前は、AWS の go-to-market ツールへの生成 AI 機能を組み込みによるトランスフォーメーションをリードしていました。また、ハイブリッドストレージとデータ転送サービスのマネジメントも担当していました。2016 年に AWS に入社する前、Asa はベンチャーキャピタルによる支援のもと 2 つのスタートアップを設立し、現在もボストンのスタートアップのメンタリングに積極的に取り組んでいます。Asa は、カリフォルニア大学バークレー校で電気工学とコンピューターサイエンスの博士号を取得し、40 件以上の特許を取得しています。 この投稿の翻訳は Mainframe Modernization Specialist Solutions Architect の皆川が担当致しました。原文記事は こちら です。