株式会社ずんだもん技術室AI放送局

AIやテクノロジーのトレンドを届けるPodcast。平日毎朝6時配信。朝の通勤時間や支度中に情報キャッチアップとして聞いてほしいのだ。

マジカルラブリー☆つむぎのピュアピュアA.I.放送局 podcast 20260608

2026年06月08日

MP3ファイルをダウンロード

内容紹介

E2Eテストを民主化したら、朝には失敗の分析も再実行も修正PRも終わっていた、スマホで動くAI、Gemma 4が量子化対応で1GB未満に。Googleが軽量モデル公開 - すまほん!!、AI slop コードレビュー

出演者

春日部つむぎ
春日部つむぎ

youtube版(スライド付き)

関連リンク

本書は、医療スタートアップ企業がPlaywrightを用いたE2E（エンドツーエンド）テストの運用を、QA（品質保証）チームから各開発チームへ「民主化（自分たちで運用すること）」し、その過程で発生した課題をAI（Claude）を活用して解決した実践的な取り組みを紹介しています。

1. 背景と「民主化」における課題 従来、プロダクトのE2EテストはQAチームが単独で作成・保守を行っていましたが、「テスト失敗時の原因特定に時間がかかる」「開発チームからテスト内容が見えにくい」という課題がありました。そこで、各開発チームが自分たちのテストを自ら運用する方針へ切り替えました。しかし、これによって「どのエラーが誰の担当か分かりにくい」「エラー調査などの運用負荷が各チームに重くのしかかる」という新たな問題が発生しました。

2. AI（Claude）を活用した解決アプローチ 開発者の負担を減らし、本来の目的であるバグ修正に集中してもらうため、AI（Claude）を取り入れた自動化の仕組みを構築しました。

  • 担当の見える化: Slackのエラー通知に担当チームのメンションを追加し、誰が対応すべきかを一目で分かるようにしました。
  • AIによるログの自動分析: 夜間に実行したテスト結果やGitHub ActionsのログをClaudeに渡し、エラー原因が「環境の一時的な問題（Flaky）」か「アプリのバグ」かをAIに判定させ、チームごとに結果を整理してSlackへ通知します。
  • 分析に基づく自動アクションの実行:
    • 環境起因のエラーの場合: AIが自動でテストを「再実行」します。
    • 仕様変更による失敗の場合: AIがコードの修正案を検討し、GitHub上に「修正プルリクエスト（PR）」を自動作成します。
    • アプリのバグの場合: Slackで担当チームへ直接通知します。

3. 導入効果と今後の展望 この取り組みにより、エンジニアは「朝出社してSlackを開くと、テストの失敗分析も、再実行も、修正PRの作成もすべて終わっている」という状態を実現できました。人間はAIが作成したPRをレビューするだけでよくなり、大幅な工数削減に成功しています。 今後は、AIによる分析やPR作成の精度向上、複数チームにまたがる複雑なテストの分類方法などの課題を改善し、さらなる安定運用を目指していくとしています。

引用元: https://zenn.dev/lincwell_inc/articles/e8e288ee35f5b4

Googleは、モバイル端末での動作に特化した軽量なオープンAIモデル「Gemma 4」において、量子化（モデルの軽量化）を前提に設計・訓練された新しいモデルを公開しました。これにより、最小構成である「Gemma 4 E2B」はメモリ使用量を約1GB、テキスト専用の用途であれば1GB未満にまで抑えることに成功しました。

本技術の最大の特徴は、軽量化のアプローチとして「QAT（Quantization-Aware Training：量子化意識訓練）」を採用した点にあります。 新人エンジニアの方向けにわかりやすく説明すると、AIモデルを軽量化するプロセスは「スーツケースへの荷物のパッキング」に例えられます。 従来の一般的な手法である「PTQ（学習後の量子化）」は、完成したモデルを力ずくで押し込んで圧縮するため、情報が壊れて品質が落ちてしまいがちでした。一方、今回の「QAT」は「最初からきれいに畳んで詰め込むことを想定して訓練（学習）を行う」ため、極限まで軽量化してもモデルの品質（賢さ）を高く維持できます。Googleのベンチマークでも、従来のPTQを上回る品質が確認されています。

具体的な効果として、4bit形式（Q4_0）への圧縮により、標準的な形式（BF16）と比較して約75%ものメモリ使用量を削減しています。例えば「26B A4B」というモデルは、Q4_0形式にすることでメモリ要件を約14.4GBに抑えつつ、一回り大きな31Bモデルに近い処理性能を発揮します。さらにモバイル向けの超圧縮では、重要度の低い処理部分を2bitまで大胆に削り、推論の中核を担う重要な層は高精度に保つといった、効率的な使い分けを行っています。

このアップデートは、ローカル環境（オンデバイス）でAIを動かしたいエンジニアにとって極めて重要なニュースです。 これまで高い通信コストやサーバー遅延が課題だったAIアプリ開発において、ユーザーの手元のスマートフォン単体、かつオフラインでも動く「実用的なAIアプリ」を開発する未来が一気に現実味を帯びてきました。次世代のアプリケーション開発における強力な選択肢となるでしょう。

引用元: https://smhn.info/202606-gemma-4-quantized-1gb-google-lightweight-on-device-ai

近年、AIコーディングツールの普及が進む一方で、AIが生成した質の低いコードや、対話の伴わないプルリクエスト（PR）が大量に送られてくる「AI slop（AI製の粗悪なコンテンツ/コード）」問題が、OSSのメンテナを悩ませています。本記事は、Scalaコンパイラの開発に携わる筆者が、AIを使いこなせていないユーザーから届く低品質なPRに直面し、その対応に苦慮している現実を綴ったものです。

筆者が日々コードレビューを行う中で感じている「AI slop PR」の具体的な問題点は以下の通りです。

  1. 対処療法的な低品質コード 根本的な解決ではなく、特定のエラーやクラッシュを局所的に回避するためだけの、その場しのぎの修正が多く見られます。
  2. 当事者意識の欠如 「PRは作ったので、あとはメンテナがどうにかしてください」という、マージ後の責任を考慮しない無責任なスタンスが目立ちます。
  3. AIとの「バケツリレー」によるコミュニケーションの不透明さ レビュアーからの指摘を、PR作成者がそのままAIに丸投げして返答を待つため、レスポンスが遅くなります。また、作成者自身が仕様を理解していないため、透明性の低いAIと会話させられているような状態に陥ります。
  4. 設計の議論を無視していきなりコードを変更する 「なぜこの変更が必要か」「別の方針はどうか」という問いかけに対し、設計の合意形成を無視して、いきなりAIが再生成したコードの変更で返してきます。作成者自身に一貫した意思（設計思想）がないためです。
  5. レビューを重ねるほど方針がブレる 議論の流れ（文脈）を考慮せず、直近のコメントだけをAIに入力しているためか、指摘を重ねるたびにコードの方向性が迷走していきます。

新人エンジニアに向けた学びと心構え AIツールを使って効率的にコードを書くこと自体は、現代の開発において非常に強力な武器になります。しかし、最も重要なのは「AIが書いたコードの意図を自分自身でしっかりと理解し、説明・コントロールできること」です。 信頼されるエンジニアになるためには、以下の姿勢が大切になります。

  • AIの提案を鵜呑みにせず、なぜその実装になるのか、根本原因は何かを自ら考える。
  • コードを書き換える前に、まずレビュアーと「設計方針の合意」を取る（議論を拒まない）。
  • ツールに任せる部分と、自分が責任を持つ部分を明確に区別する。

こうしたAI slop問題への対抗策として、今後は「信頼されたユーザーのみがPRを作成でき、それ以外はまずIssueで議論を必須とする」など、OSS開発のあり方そのものが制限付きのフローへと変わっていく可能性が指摘されています。

引用元: https://tanishiking24.hatenablog.com/entry/2026/06/07/134005

VOICEVOX:春日部つむぎ