youtube版(スライド付き) 関連リンクローカルの Claude Code レビューを「すり抜けられない」必須チェックにした話開発プロセスにおけるAIレビューのコスト削減と、レビューの実行漏れ（すり抜け）を防ぐための実践的な「仕組み化」に関する記事です。 1. 背景と課題：AIレビューのコスト問題とローカル運用の盲点ある開発チームでは、毎回CI（クラウド上の自動実行環境）でAI（Claude Code）によるコードレビューを走らせると、APIの従量課金コストが膨らむという課題を抱えていました。そこで、コストを抑えるために、各開発者のローカル環境でpush（コードの送信）直前にレビューを自動実行する運用（Git hookの仕組み）を取り入れました。しかし、ローカル環境での実行は「開発者がツールのセットアップを忘れた」「実行をスキップした」といった場合に外部から検知できず、レビューを通さないままコードが送信されてしまうという運用上の致命的な盲点がありました。 2. 解決策：ローカルの「合格証跡」をGitHubで検証する仕組みこの課題を解決するため、「ローカルでレビューが合格した」という証跡をGitHub側に送り、その証跡がないコードはマージ（統合）できないように制御する仕組みを構築しました。具体的な動作の流れは以下の4ステップです。レビュー結果を機械的に判定できるようにする Claude Codeへの指示（プロンプト）を工夫し、レビュー結果に問題がなければ [REVIEW_RESULT: PASS]、問題があれば [REVIEW_RESULT: FAIL] と、スクリプトで判別しやすいテキストを末尾に出力させます。 git notes を利用した合格証の付与開発者がpushを行う際、ツール（lefthook）を介してローカルでAIレビューが実行されます。結果が「PASS」の場合のみ、git notes（コミットに付箋のようにメモを残せるGitの機能）を使い、コミットに「PASS」というメモを貼り付けてGitHubに送信します。 GitHub Actionsでの検証コードがGitHubに届くと、GitHub Actions（自動ワークフロー）が起動します。送られてきたコミットに「PASS」のメモが付いているかをチェックし、あれば「合格（success）」、なければ「不合格（failure）」というステータスをコミットに付与します。マージのブロック（必須チェック化） GitHubのブランチ保護機能（Branch protection）を使い、「合格ステータス」がないコードは本番ブランチにマージできないようにルール化します。 3. まとめ：新人エンジニアが学びたいポイントこの仕組みの素晴らしい点は、「本来はサーバー側から見えないはずのローカルの作業状況」を、Gitの標準機能を使ってGitHub側から検証できるようにしたアイデアにあります。「ルールを決めて人に守らせる」のではなく、「設定を忘れたら自然とマージできなくなる」という、人のミスを構造的に防ぐ（ポカヨケの）設計思想は、今後の開発プロセス設計において非常に参考になる優れたエンジニアリング事例です。引用元: https://product.plex.co.jp/entry/local-claude-code-review-required-check Claude Codeでデザインのワークフローを変えたら、役割の境界が融けていった話──越境するほど鮮明になる、デザイナーの「核」とは本書は、グッドパッチのUI/UXデザイナーが、AI開発アシスタントである「Claude Code」を活用して自らフロントエンド開発に挑戦し、職種の境界を越えてプロダクトの品質と開発スピードを向上させた実践事例を紹介しています。新人エンジニアにとっても、AI時代のチーム開発のあり方を学ぶ上で非常に参考になる内容です。開発現場でよくある「デザインは決まったのに、エンジニアの工数が足りなくて実装が進まない」という課題に対し、著者はデザイナーでありながら自らコードを書く「越境」を決意しました。その強力なパートナーとなったのが、コマンドラインで動作するAIツール「Claude Code」です。具体的なワークフローは以下の通りです。要件定義の効率化: 会議の文字起こしデータを基に、Claude Codeと対話しながら要件定義書の叩きを自動生成。実装・微調整: 既存コンポーネントの改善や微調整は、Claude Codeを起点にデザイナー自身が実行。 Figmaからの実装: 新規画面は、デザインツール「Figma」のリンクをMCP（Model Context Protocol）経由でClaude Codeに共有し、再現性の高いコードを自動生成。著者は、AIを使いこなすためには「道具に使われないこと」が大切だと言います。Gitの操作やコードの最低限の仕組みを自分で理解した上で、AIの挙動をコントロールするスタンスが重要です。また、AIによって誰もがアウトプットを出しやすくなったからこそ、「デザイン品質を評価する仕組み」が必要になります。プロジェクトでは、ガイドラインやアクセシビリティ基準を満たしているかを自動チェックするカスタムAI（Gem）を開発し、手戻りを減らす工夫を導入しました。この背景には、土台となるデザインシステム（Sparkle Design）が整っているからこそ、AIが迷わず高品質なコードを出力できるという前提があります。このように職種の境界が融けていく中で、著者はAIに代替できない「人間の核」として、以下の3点を挙げています。わずかな違和感に気づき調整する「審美眼」ユーザーの感情や状況といった「一次情報」を自ら取りに行くこと最後に体験の責任を持って意思決定すること技術的なハードルをAIが下げてくれた今、エンジニアとデザイナーが互いの領域に歩み寄り、最高のユーザー体験を共創できる時代が到来しています。引用元: https://goodpatch.com/blog/2026-05-design-workflow EAGLE 3.1: Advancing Speculative Decoding Through Collaboration Between the EAGLE Team, vLLM, and TorchSpec LLM（大規模言語モデル）の推論を高速化する手法として、より軽量な補助モデル（ドラフトモデル）を用いて次のトークンを先読み・予測する「推測デコード（Speculative Decoding）」技術が注目されています。その代表的なアルゴリズムである「EAGLE」シリーズの最新版として、EAGLE開発チーム、vLLM、そしてTorchSpecの共同開発により「EAGLE 3.1」がリリースされました。従来の推測デコードは、制御された特定の実験環境下では高いパフォーマンスを発揮するものの、実務における長文の入力や、チャットテンプレート・システムプロンプトの変更といった「想定外の入力」に対して処理能力が急激に低下する脆弱性がありました。研究チームはこの脆弱性を解析し、予測のステップが深くなるにつれて、ドラフトモデルが重要なトークンから自身の生成したトークンへと徐々に注意を逸らしてしまう「アテンション・ドリフト（Attention Drift）」現象が発生していることを突き止めました。さらに、層を重ねるごとに隠れ状態（hidden-state）の規模が不均一になり、値が肥大化してドラフトモデルの挙動を不安定にさせていることが原因でした。 EAGLE 3.1では、この課題を解決するためにアーキテクチャを改良し、以下の2つの変更を導入しました。各ターゲットの隠れ状態の後に、FC（全結合）正規化（FC normalization）を追加正規化後の隠れ状態を、次のデコードステップへの入力としてフィードバックこの設計により、モデルの処理が再帰的に呼び出される構造となり、システムの安定性が大幅に向上しました。結果として、長文を扱うワークロードにおいて、前バージョンのEAGLE 3と比較して最大2倍の「承認長さ（ドラフトモデルが予測に成功し、実際に採用されたトークンの長さ）」を達成しました。また、EAGLE 3.1はエコシステムとの連携も強化されています。学習用フレームワークである「TorchSpec」がEAGLE 3.1の効率的な学習に対応したほか、推論エンジンである「vLLM」への統合も進んでおり、従来のEAGLE 3のチェックポイントとの後方互換性も維持されています。実際のモデル（Kimi K2.6）を用いた検証では、推測デコードを使用しない場合と比較して最大2.03倍のスループット（処理速度）向上を記録しました。本プロジェクトは、アルゴリズム研究（EAGLE）、学習インフラ（TorchSpec）、推論システム（vLLM）のオープンソースコミュニティが連携し、実用的なLLM推論の効率化を大きく前進させた好例です。引用元: https://vllm.ai/blog/2026-05-26-eagle-3-1 「Live2D」公式の無料オンライン動画エディター「nizima ACTION!! β版」がVOICEVOXに対応。“ずんだもん”のLive2Dモデルも追加 Live2Dは、無料のブラウザ向け動画エディター「nizima ACTION!! β版」をアップデートし、テキスト読み上げ「VOICEVOX」を新搭載しました。これにより「ずんだもん」などの音声合成が可能になり、追加された公式Live2Dモデルと組み合わせることで、テキスト入力から音声生成、リップシンク（口パク）までをブラウザ上で完結できます。手軽にリッチなキャラクター動画を制作できる注目のアップデートです。引用元: https://news.denfaminicogamer.jp/news/2605273h お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）

Ask this episode

“What did the council decide on item 42?” — answered with the speaker and the moment.

Transcript

Related