youtube版(スライド付き)

関連リンク

E2Eテストを民主化したら、朝には失敗の分析も再実行も修正PRも終わっていた

本書は、医療スタートアップ企業が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

スマホで動くAI、Gemma 4が量子化対応で1GB未満に。Googleが軽量モデル公開 - すまほん!!

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 slop コードレビュー

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

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

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

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

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

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

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

お便り投稿フォーム

VOICEVOX:春日部つむぎ