株式会社ずんだもん技術室AI放送局 podcast 20251223
内容紹介
Figmaやめて、AIとコードでUIを作り始めた話、LLMのCUDAカーネルを自作しよう!、Structured Outputs Create False Confidence BAML Blog、高市首相が小室哲哉、デーモン閣下、こっちのけんとの3名ほかと意見交換会を開いたが絵面がすごい「AIじゃない…だと？」「4人バンドかな」
出演者
youtube版(スライド付き)
関連リンク
AI Shift社のUI/UXデザイナー後藤氏による、Figmaでのデザイン作業をあえて停止し、AIとコードを駆使してUI構築を行う実験的な取り組みの紹介です。AI Shift Advent Calendar 2025の記事であり、AIエージェント（Claude Code等）が台頭する現代における、新しいフロントエンド開発の形を示唆しています。
背景：デザインが開発のボトルネックに
開発チームがAIを導入して実装速度が飛躍的に向上した結果、従来のFigmaによる手作業でのデザインが追いつかず、デザイナーがチーム全体のボトルネックになるという課題が発生しました。筆者は自身の業務を「探索（リサーチ）」「考案（解決策）」「形にする（UI構築）」に分解。最もコストのかかっていた「形にする」作業をAIに任せることで、本来重要なUXデザイン（探索・考案）に時間を全振りすることを目指しました。
解決策：デザインと実装の境界をなくす
「Figmaでのデザイン」と「フロントエンドの実装」が分断されている構造自体を見直し、AIを活用してStorybook上で直接UIを構築する手法を採用しました。これにより、デザイン案を即座にコードとして動かせるようになり、試行錯誤の回数が劇的に増加しました。
AIを使いこなすための「地図」の整備
AIに丸投げするのではなく、精度と再現性を高めるために以下の材料を整えています。
- UXリサーチの共有: ペルソナや価値マップをAIに渡し、判断の評価軸（北極星）を明確にする。
- ドキュメント構造の整理:
docs/配下にプロダクトビジョンやデザインシステムをまとめ、AIと人間が参照する事実を一元化する。 - 厳密なプロンプトテンプレート: コンテキスト、技術・デザイン制約、入出力形式、良い例・悪い例を定義し、AIの迷いをなくす。
- 人間による全体最適: AIが得意な「局所最適（画面単体の作成）」を活かしつつ、人間が「ユーザー体験全体の整合性」を担保する。
新人エンジニアへの示唆
AIは魔法ではなく、「問いが明確であれば、爆速で形にできる増幅器」です。これからの開発では、コードを書く技術だけでなく、「誰の何を解決するためのものか」という背景を言語化し、ドキュメントとして整理する能力が、AIを味方につけるための強力な武器になります。
「デザインと実装を統合する」このアプローチは、エンジニアとデザイナーの垣根を低くし、より本質的な価値提供に集中できる可能性を秘めています。
引用元: https://zenn.dev/aishift/articles/3e211e67e3dc14
本記事は、PyTorchの内部で行われているGPU処理（CUDAカーネル）をGPT-2モデルを題材に自作し、LLMの動作原理を深く理解するための技術解説です。新人エンジニアにとっても、ブラックボックスになりがちな「.to(“cuda”)」の先で何が起きているかを知るための優れた入門ガイドとなっています。
まず、開発の基盤となる技術要素が紹介されています。NVIDIA GPUを制御する「CUDA」、C++とPythonを連携させる「pybind11」、そしてC++版PyTorchである「Libtorch」を組み合わせることで、自作の高速な演算処理をPythonから手軽に呼び出せる環境を構築します。
記事の中核は、LLMを構成する各要素の「スクラッチ実装」です。単に数式を実装するだけでなく、学習に不可欠な「誤差逆伝播（バックプロパゲーション）」を実現するために、順伝播（Forward）と逆伝播（Backward）の両方のカーネルを自作しています。主な実装項目は以下の通りです。
- Linear層: 行列演算（Matmul）やバイアス加算といった基本演算の実装。
- 活性化関数（GELU）: 近似式を用いた高速な計算手法の適用。
- Dropout: CUDAの標準ライブラリ「cuRAND」を用いた乱数制御による過学習抑制。
- Layer Norm（DyT）: 2025年に発表された最新手法「Dynamic Tanh」を採用。実装の容易さと高いパフォーマンスを両立させています。
- Attention機構: トークンIDのベクトル変換（Embedding）から、LLMの肝である「Scaled Dot Product Attention」の計算グラフに基づく実装。
さらに、学習を支えるアルゴリズムとして、予測のズレを評価する「CrossEntropyLoss」や、重みを効率的に更新する最適化手法「AdamW」もCUDAカーネルとして実装されています。
実装の信頼性を担保するため、自作カーネルの計算結果が純正のPyTorchと一致するかをユニットテストで厳密に検証している点も特徴的です。最終的に、これらの部品を組み上げて36MパラメータのGPT-2モデルを構築し、日本語データセットを用いた学習に成功しました。結果として、純正PyTorchと同様の損失（Loss）の推移が確認されており、自作カーネルの正当性が証明されています。
LLMのパフォーマンス改善や独自の最適化を目指すエンジニアにとって、ライブラリの内部構造を理解し、低レイヤからモデルを構築する経験は非常に技術的価値が高いものです。この記事は、その第一歩として、理論と実装の両面から学べる実践的な内容となっています。
引用元: https://zenn.dev/selllous/articles/diy_llm_kernel
LLMを利用したシステム開発において、JSON形式などで結果を返す「構造化出力（Structured Outputs）」は、一見すると非常に便利で信頼できるように見えます。しかし、本記事は「構造化を優先するあまり、回答の品質（精度）が犠牲になっている」という、エンジニアが陥りがちな落とし穴を指摘しています。
1. 「正しさ」よりも「形式」が優先されてしまう
構造化出力API（OpenAIなどのConstrained Decoding）を使用すると、モデルは「指定されたスキーマに適合すること」を最優先します。 例えば、レシートから商品の数量を抽出する際、モデルがテキスト出力なら「0.46」と正しく答えられるケースでも、構造化出力の制約下では強引にスキーマに合わせようとして「1」という誤った数値を返してしまうことがあります。これは、モデルが本来選びたかったトークンが、スキーマ制約によって選択肢から除外されてしまうためです。
2. 例外やエラーを扱いにくくなる
自由なテキスト出力であれば、LLMは「入力画像がレシートではなく象の画像である」といった矛盾を指摘し、処理を拒否することができます。しかし、特定の構造（JSON等）を強制されると、モデルは「象の情報」を無理やり「レシートの枠組み（店名や合計金額など）」に当てはめて出力しようとします。その結果、フォーマットは正しいが無意味なデータが生成され、エラーの検知が困難になります。
3. 推論能力（Chain-of-Thought）の低下
「ステップバイステップで考えて」という指示はLLMの回答精度を上げますが、構造化出力ではこの推論プロセスまでJSONのフィールドに含める必要があります。この時、モデルは「改行のパース」や「クォートのエスケープ」といった、フォーマットを整えるための事務的な作業に知能のリソースを割いてしまい、肝心の推論の質が落ちるという問題が発生します。
結論とエンジニアへの提言
筆者は、構造化出力を安易に過信せず、「LLMには自由に話させ、その出力を後からパースする」というアプローチを推奨しています。
- 自由な出力を許可する: モデルが矛盾を警告したり、計算過程を自由に記述したりできる余白を残す。
- 後段でパースする: 自由な形式の回答から必要な情報を抽出する。
この「スキーマに合わせたパース（Schema-aligned parsing）」を効果的に行うために、筆者らは「BAML」というオープンソースのDSLを開発しています。新人エンジニアの方は、ライブラリの機能に頼り切るのではなく、LLMの挙動（トークン選択の仕組み）を理解した上で、出力の「形式」と「品質」のバランスを考慮した設計を行うことが重要です。
引用元: https://boundaryml.com/blog/structured-outputs-create-false-confidence
高市首相がコンテンツ業界の著名人である小室哲哉氏、デーモン閣下、こっちのけんと氏らと意見交換会を行い、その写真が「AI生成画像のような違和感」だと話題です。あまりに豪華で異色な顔合わせに、ネット上では「4人組バンドの結成か」といった冗談も飛び交っています。現実の光景がAIによるフェイク画像のように見えてしまうという、現代ならではの視覚的ユーモアを感じさせるニュースです。
引用元: https://togetter.com/li/2641578
（株式会社ずんだもんは架空の登場組織です）