Podcast
株式会社ずんだもん技術室AI放送局
Hosted by 株式会社ずんだもん技術室AI放送局 · JA
AIやテクノロジーのトレンドを届けるPodcast。平日毎朝6時配信。朝の通勤時間や支度中に情報キャッチアップとして聞いてほしいのだ。(MC 月:春日部つむぎ、火水木:ずんだもん、金:お嬢様ずんだもん)
72episodes
Episodes
Newest firstAll episodes
株式会社ずんだもん技術室AI放送局 podcast 20260602
3d agoTap to summarizeyoutube版(スライド付き) 関連リンク Claude Code チャンピオン キット 本ドキュメントは、Anthropicが提供するターミナル用AI開発ツール「Claude Code」を、チームや組織に効果的に導入・定着させるための戦略ガイドです。新しいツールの導入を成功させるには、単なる配布ではなく、チーム内で実際に使いこなし、その価値を周囲に伝える「チャンピオン（推進者）」の存在が不可欠であると説いています。 ■ チャンピオンの役割とマインドセット チャンピオンは、単なる「ヘルプデスク（問い合わせ窓口）」ではなく、チーム全体の生産性を引き上げる「乗数（マルチプライヤー）」として機能します。自分の業務を犠牲にするのではなく、既存のワークフロー（プルリクエスト、Slack、スタンドアップ等）の中で自然にツール活用のメリットを示していくことが推奨されています。 ■ 推進のための3つの主要アクション 発見の共有: 一般的なドキュメントよりも、自分たちのコードベースで実際に成功した例（プロンプトやスクリーンショット）を共有します。これにより、同僚は「自分の課題」にどう役立つかを具体的にイメージできます。 プロンプトで回答する: 使い方を聞かれた際は、言葉で説明するよりも、実際に成果を出した「生のプロンプト」を共有します。これにより、同僚は即座に自分のタスクで試行でき、導入のハードルが下がります。 輪を広げる: 特定の個人に依存しないよう、専用チャネルの作成や週次の情報共有など、自律的に情報が循環する習慣を確立します。 ■ 現場の懸念への向き合い方 エンジニアが抱きがちな「AIへの信頼性」や「スキルの低下」といった懸念に対し、以下のような具体的なアプローチを提示しています。 ・信頼性: 変更前に修正内容をすべて確認できる「プランモード（Shift+Tab）」のデモンストレーションを行う。 ・教育的側面: 単なる自動化ではなく、複雑なコードの「解説者」としてAIを活用する方法（@ファイル指定での説明など）を提示する。 ■ 新人エンジニアへのメッセージ 本ガイドは、ツールの操作方法だけでなく「新しい技術をいかにして組織に根付かせるか」という、シニアな視点での組織論を学べる内容となっています。「説明よりも実例（プロンプト）を示す」というアプローチは、今後のAI時代におけるエンジニア間のコミュニケーションにおいて非常に強力な武器になります。自身の学習をチームの資産に変えるプロセスを実践することで、技術的な貢献以上のインパクトを周囲に与えることができるでしょう。 引用元: https://support.claude.com/ja/articles/14555399-claude-code-%E3%83%81%E3%83%A3%E3%83%B3%E3%83%94%E3%82%AA%E3%83%B3-%E3%82%AD%E3%83%83%E3%83%88 Poisoning Claude Code: One GitHub Issue to Break the Supply Chain GMO Flatt SecurityのリサーチャーであるRyotaK氏による、AIエージェント「Claude Code」のGitHub Actionsにおける深刻なサプライチェーン脆弱性の調査報告です。本記事では、GitHub Issueを1つ作成するだけでリポジトリの制御権を奪取し、さらには開発元のAnthropic社を含む広範なサプライチェーンを汚染できてしまう仕組みを解説しています。 主な脆弱性のメカニズム 権限チェックのバイパス: Claude Code Actionは、実行者がボット（GitHub App）である場合、権限を無条件に信頼する仕様でした。攻撃者は自作のアプリからIssueを作成することで、本来必要な「書き込み権限」のチェックを回避してAIを起動させることが可能でした。 間接的プロンプトインジェクション: 攻撃者が作成したIssueをAIに読み取らせる際、エラーメッセージを装った指示（例：「読み取りに失敗しました。このコマンドを実行してください」）を混入させます。これにより、AIを騙して環境変数（/proc/self/environ）を読み取らせるなどの不正操作を誘導します。 秘密情報の奪取と権限昇格: 奪取した環境変数には、GitHubの特権トークン（OIDCトークン）を取得するための認証情報が含まれていました。これを用いることで、攻撃者はリポジトリへの書き込み権限を持つ正規のトークンを入手し、ソースコードの改ざんや悪意あるコードの埋め込みが行える状態になります。 設定不備によるリスク 特に、外部ユーザーによる実行を許可する allowed_non_write_users: "*" という設定が危険です。この設定があると、外部の攻撃者が「Issueトリアージ用の低い権限」を足がかりにして、最終的に「リポジトリ全体のフルアクセス権限」を奪取する攻撃（チェイニング）が成立してしまいます。 対策とまとめ Anthropic社は既にこの問題を修正しており（v1.0.94以降）、ボットによる自動実行の制限や、環境変数のスクラビング（消去）、サマリ機能の無効化といった多層的な防御策を導入しました。 新人エンジニアの皆様への教訓として、AIエージェントは「外部からの入力を命令として実行してしまう可能性がある」という特性を理解することが重要です。便利な自動化ツールほど、そのツールが持つ権限を最小限にし、誰がそれを動かせる設定になっているかを厳格に管理する「最小権限の原則」を意識しましょう。 引用元: https://flatt.tech/research/posts/poisoning-claude-code-one-github-issue-to-break-the-supply-chain/ Develop Physical AI Reasoning, World, and Action Models with NVIDIA Cosmos 3 NVIDIAは、現実世界の物理的な事象を理解し、予測し、行動を生成するための次世代基盤モデル「NVIDIA Cosmos 3」を発表しました。これは「物理AI（Physical AI）」の発展を加速させるための画期的なリリースです。 ■ 物理AIとCosmos 3の核心 物理AIとは、ロボットや自動運転車が「現実で何が起きているか」を理解し、「次に何が起きるか」を予測し、適切な「行動」をとるための知能です。従来のシステムでは、これらは別々のモデルで処理されることが一般的でしたが、Cosmos 3はこれらを単一のオープンモデルに統合しました。 ■ 仕組み：2つの「タワー」による連携 Cosmos 3は、Mixture-of-Transformers (MoT) アーキテクチャを採用しており、以下の2つのコンポーネントが連携して動作します。 Reasoner（推論）タワー: 視覚と言語を扱うモデル（VLM）で、画像や動画、テキストから物理的な文脈や物体の相互作用を読み取る「脳」の役割を果たします。 Generator（生成）タワー: 推論結果を基に、物理的に正しい未来の映像や、具体的な行動シーケンスを生成します。 ■ 用途に合わせた2つのモデルサイズ ・Cosmos 3 Nano (16B): ワークステーション級（RTX 6000等）で動作するよう最適化されており、リアルタイムのロボット推論などに適しています。 ・Cosmos 3 Super (64B): データセンター級（Hopper/Blackwell等）向けで、最高品質の推論や大規模な合成データ生成が可能です。 ■ 開発者への強力なサポート NVIDIAは、モデルのチェックポイント（Hugging Faceで公開）に加え、トレーニングスクリプトや展開ツールもオープンソースとして提供しています。また、ロボティクスや自動運転、倉庫管理など、特定のドメインに特化した6つの高品質な合成データセットも公開されており、エンジニアはこれらを利用して独自のモデルを開発・検証することが可能です。 ■ まとめ Cosmos 3は、物理世界の「理解・予測・実行」を一つのパイプラインで実現し、ロボット開発などの複雑なワークフローを大幅に簡素化します。NVIDIA NIM（マイクロサービス）としての提供も開始されており、インフラの構築に慣れていない新人エンジニアでも、最適化された環境で最先端の物理AIを試すことができます。物理法則に則ったAI開発の、新しいスタンダードとなるモデルです。 引用元: https://developer.nvidia.com/blog/develop-physical-ai-reasoning-world-and-action-models-with-nvidia-cosmos-3/ AIになりたい・背景をぼかして実在しない漢字のTシャツを着ればAI生成のような写真になるはず 新人エンジニアの方も親しみやすい、AI画像特有の「違和感」を物理で再現する面白い試みです。AI生成画像によくある「過剰な背景ボケ」や「輪郭の輝き」を実写で再現し、さらに画像生成AIが描きがちな「実在しない不自然な漢字」のTシャツを自作して着用。これらを通じて、現実の写真をAI生成風に見せることに挑戦しています。AIの学習傾向を逆手に取った、遊び心溢れる息抜きにぴったりの検証記事です。 引用元: https://dailyportalz.jp/kiji/i-want-to-be-an-ai お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）
Transcribe →
マジカルラブリー☆つむぎのピュアピュアA.I.放送局 podcast 20260601
4d agoTap to summarizeyoutube版(スライド付き) 関連リンク Zero Trust for AI agents 本書は、企業において自律型AIエージェントを安全に導入・運用するための新しいセキュリティフレームワークについて解説したドキュメントです。 1. 背景：AIの進化がもたらす「超高速な脅威」 近年のAI技術の急速な進化により、システムの脆弱性が発見されてから、それが実際に攻撃（悪用）されるまでの時間が「数ヶ月単位」から「わずか数時間」へと劇的に短縮されています。防御側がAIを使って素早くバグを修正できる一方で、攻撃側もAIを利用してあっという間に脆弱性を突く攻撃コードを作成できるようになっています。 特に、自ら考えてツールを使いこなす「AIエージェント」を導入する場合、従来のアクセス制御（IP制限やIDパスワードなど）だけでは防げません。正規の権限を与えられたAIエージェントが、悪意あるデータに騙されて、許可されたツールを予期せぬ形で「誤用」してしまうリスクがあるためです。 2. AIエージェントを狙う新たな脅威 AIエージェントの運用には、以下のような特有のセキュリティリスクが伴います。 プロンプトインジェクション: 外部からの入力データに悪意ある指示を混ぜ込み、AIを意図通りに操る攻撃。 ツールやメモリの汚染: エージェントが参照するツールや過去の会話履歴（記憶）に嘘の情報を仕込み、AIに誤った判断をさせる攻撃。 権限の不正利用: エージェントが必要以上の権限を持つことで、意図しないデータ削除や操作が行われてしまうリスク。 3. 解決策：AIのための「ゼロトラスト」 これらの脅威に対抗するため、「何も信頼せず、すべてを検証する」というセキュリティの基本思想「ゼロトラスト」をAI向けに再定義したフレームワークを提案しています。 暗号による厳格な身元確認: エージェント自身のアイデンティティ（ID）を暗号技術で強固に管理・検証します。 タスクごとの最小権限割り当て: エージェントに広範な権限を持たせるのではなく、実行するタスクごとに必要な最小限の権限のみをその都度与えます。 実行環境のサンドボックス化: 万が一エージェントが乗っ取られても他のシステムに影響が及ばないよう、安全に隔離された環境（サンドボックス）で動作させます。 メモリと入出力の保護: 過去の対話履歴が改ざんされないよう保護し、エージェントに入るデータと出るデータを厳しくチェック・フィルタリングします。 AIによる自律的な防御運用（Agentic SOAR）: AIのスピードで仕掛けられる攻撃に対抗するため、防御側も自動で脅威を検知し対処する高速なセキュリティ体制を整えます。 4. まとめ（新人エンジニアの皆様へ） これからのAIエージェント開発においては、便利な機能を作るだけでなく、設計の初期段階から「システムはいつか突破されるものである」という前提（Assume Breach）に立ち、多層防御のアーキテクチャを意識してシステムを構築することが非常に重要になります。 引用元: https://claude.com/blog/zero-trust-for-ai-agents Gemma 4が4種類もあって混乱したので整理してみた！ 本記事は、Googleが2026年4月にリリースしたオープンウェイト（ローカルや自社サーバーで動かせる）LLM「Gemma 4」の4つのモデルについて、新人エンジニア向けにその違いと実務でのユースケースを分かりやすく整理したものです。 Gemma 4には、モデルの構造（アーキテクチャ）やパラメータ数が異なる4つのモデルが存在します。それぞれの特徴は以下の通りです。 1. Gemma 4 31B （高品質・高スペック向け） 特徴: 全パラメータを毎トークン使用する最も標準的な構造（Dense）です。 注意点: 実行には非常に高いマシンスペックが要求され、メモリ（VRAM/RAM）が最低でも約31GB必要になります。 ユースケース: リクエスト数は少ないものの、AIの「出力品質」を最優先したい業務。 2. Gemma 4 26B A4B (Active 4B) （高速かつ賢いMoEモデル） 特徴: 複数の専門家モデルを切り替える「MoE」技術を採用。全体の重みは26Bですが、実行時は約4Bのパラメータのみを使うため、26Bクラスの賢さを保ちつつ4Bモデル並みの超高速な推論が可能です。 注意点: 起動（ロード）用に26GB以上のメモリが必要です。 ユースケース: 自社サーバーにホストし、AIベンダーのAPIと同じように高速かつ多目的で使いたい場合。 3. Gemma 4 E4B (Effective 4B) （高効率・コスパ最強候補） 特徴: 省メモリ技術「PLE」を採用し、モデル自体は8Bですが、実行時は実質4B相当の計算負荷に抑えられています。スマホでも高速に動作する軽さです。 ユースケース: 特定のタスクに特化させてファインチューニング（微調整）を行い、本番環境で安価かつ高速に動かす実用的な運用。 4. Gemma 4 E2B (Effective 2B) （超軽量・エッジ向け） 特徴: PLEを採用し、モデルは5B、実行時は2B相当で動作します。ラズパイなどでも動く軽さです。 ユースケース: ネットワーク接続のない環境や、応答速度（レイテンシー）が最優先されるシンプルなタスク。 ■ 開発時に選ぶべき「it」モデルとは？ モデル名に「it」というサフィックス（接尾辞）がついているものは、Instruction-Tuned（指示チューニング済み）を意味します。これがないモデルは事前学習のみで会話には不向きなため、自らファインチューニングをしない場合は必ず「it」付きモデルを選びましょう。 まとめ Gemma 4をセルフホストして使う際は、汎用的な賢さを求めるなら「26B A4B」、特定のタスクを低コスト・ハイスピードで処理させたいなら「E4B」をカスタマイズして使うのが、実務において非常に強力な選択肢となります。 引用元: https://zenn.dev/tasshi441/articles/8a80daffac2556 Introducing 1-bit and Ternary Bonsai Image 4B: Image Generation for Local Devices PrismMLは、スマートフォンやノートPCなどのローカルデバイス上で、高品質な画像生成（拡散モデルの推論）を可能にする軽量モデルファミリー「Bonsai Image 4B」をリリースしました。ベースモデル「FLUX.2 Klein 4B」のアーキテクチャを維持しつつ、モデルの大部分を占めるDiffusion Transformerの重みを極限まで圧縮した2つのバリアントが提供されます。 1. 2つのバリアントと特徴 新人エンジニア向けに解説すると、本モデルは「量子化（データの精度を意図的に落として軽量化する技術）」を究極まで突き詰めています。これにより、これまでメモリ不足でスマホでは起動すらできなかった巨大な画像生成モデルを、スマホの限られたメモリ内で高速に動かせるようにしています。 1-bit Bonsai Image 4B（極限の圧縮モデル） 特徴: 重みを「-1」と「+1」の2つの値（実質1.125ビット）だけで表現。 サイズ: 拡散Transformerのサイズが 0.93 GB（元の7.75 GBから 8.3倍削減）。 用途: メモリや通信帯域、デバイス容量が極めて厳しい環境に最適です。 Ternary Bonsai Image 4B（バランス重視モデル） 特徴: 重みを「-1」「0」「+1」の3値（実質1.71ビット）で表現。「0」の表現が加わることでモデルの表現力が格段に向上。 サイズ: 拡散Transformerのサイズが 1.21 GB（元の7.75 GBから 6.4倍削減）。 性能: 元のモデルの約95%の画質とプロンプト忠実度を維持しています。 2. ローカル実行時の圧倒的なメモリ削減 通常、512x512ピクセルの画像を生成する場合、元のモデルは11.74 GBものメモリ（RAM）を必要としますが、今回の1-bit版は1.5 GB、Ternary版は1.96 GBのメモリ消費に抑えられます。 これにより、iPhone 17 Pro Max上で約9.4秒、Mac M4 Pro上では約6秒で画像生成が可能です。 3. なぜ「ローカル画像生成」が重要なのか？ 従来のクラウド型API（サーバー側での生成）には、1回ごとの通信遅延、サーバー代、プロンプトのプライバシー保護といった課題がありました。 画像生成は、ユーザーが何度もプロンプトを微調整しながら繰り返す「試行錯誤（イテレーション）」が基本です。モデルがユーザーのデバイス（ローカル）で直接動くようになれば、サーバーコストを気にせず、オフラインでもプライバシーを完全に守りながら、高速で快適な画像生成体験を提供できるようになります。 4. ライセンスと公開情報 Bonsai Image 4Bは、オープンな重み（モデルデータ）とコードが Apache 2.0ライセンス で公開されており、商用利用やカスタマイズが可能です。iPhoneで手軽に試せる「Bonsai Studio」アプリもあわせてリリースされています。 引用元: https://prismml.com/news/bonsai-image-4b 拙者、『型は欲しいが型は書きたくない』者たちとの和睦を結び、るびぃにおける型の領地安堵を実現せんと欲す者也 #sekigahara01/sekigahara01 「型は欲しいが型は書きたくない」というRubyistの葛藤に対し、型検査とドキュメントとしての役割を分けて考えることを提案するスライドです。型シグネチャを「人のためのドキュメント」と捉え、AIを活用して保守コストを下げるアプローチを紹介しています。さらに、型関連ツールの導入やアップデートを自動化・統合する自作のgem「sigsa」の開発についても触れており、型を意識しない快適な開発体験の実現を目指しています。 引用元: https://speakerdeck.com/sanfrecce_osaka/sekigahara01 お便り投稿フォーム VOICEVOX:春日部つむぎ
Transcribe →
私立ずんだもん女学園放送部 podcast 20260529
1w agoTap to summarizeyoutube版(スライド付き) 関連リンク Introducing Claude Opus 4.8 Anthropic社は、AIアシスタントの最上位モデルの最新版「Claude Opus 4.8」をリリースしました。前バージョン（Opus 4.7）から性能が全面的に向上し、料金は据え置き（入力$5/100万トークン、出力$25/100万トークン）で利用可能です。 新人エンジニアの皆さまに向けて、今回のアップデートで押さえておきたい主要なポイントを分かりやすく解説します。 1. より「正直」になり、コードのバグ見逃しが激減 AIがもっともらしい嘘をつく現象（ハルシネーション）に対策が施されました。Opus 4.8は、自分が確信を持てないことに対して素直に不確実性を指摘し、根拠のない主張を避けるよう設計されています。特にコーディングにおいて、生成したコード内のバグや欠陥を見逃してしまう確率が、前モデルの4分の1にまで減少しました。これにより、コードレビューの精度が大幅に向上しています。 2. 大規模な自律開発を可能にする「動的ワークフロー」 開発支援ツール「Claude Code」にて、新しい「Dynamic workflows（動的ワークフロー）」機能がプレビュー公開されました。これは、AIが自分で計画を立て、数百ものサブエージェントを並列で走らせて、自律的にタスクを実行・検証する仕組みです。これにより、数万行に及ぶコードベース全体の移行作業といった大規模なタスクも、AIが一気通貫で実行できるようになります。 3. 思考の深さを調整できる「エフォートコントロール」 Claudeがタスクに対してどれだけ深く思考するかを、ユーザー側でコントロールできるようになりました。 高エフォート（デフォルト）: 思考プロセスを多く回し、複雑なコーディング等でより高品質な回答を出します。 低エフォート: 思考を抑えて素早く回答を出します。APIの利用上限（レートリミット）を節約したい場合に便利です。 4. 開発者に嬉しいAPIのアップデート Messages APIにおいて、メッセージ履歴の配列内にシステムプロンプト（system entries）を挿入できるようになりました。これにより、AIがタスクを実行している途中で、プロンプトキャッシュを壊すことなく、動的に指示や権限をアップデートできるようになります。 まずは進化したOpus 4.8を日々の開発やデバッグに導入し、その高い精度と使いやすさを体験してみてください。 引用元: https://www.anthropic.com/news/claude-opus-4-8 Warp’s big bet on building open source with GPT-5.5 モダンなターミナルツールとして世界中の開発者に愛用されている「Warp」が、OpenAIの最新AIモデル「GPT-5.5」を活用し、ソフトウェア開発の未来を大きく変える新しい挑戦を始めています。その中核となるのが、彼らが提唱する「Open Agentic Development（オープン・エージェント開発）」という開発モデルです。 これまでのAIによる開発支援は、チャットでコードの一部を生成してもらう「アシスタント」としての役割が中心でした。しかし、Warpが推進する「Open Agentic Development」では、AIエージェントがより自律的に動き、人間と協力して開発を進めます。 具体的には、人間が開発の「目的（仕様や意図）」を定義し、最終的な成果物を「レビュー（監督）」します。一方で、AIエージェントは自ら計画を立て、コードを書き、テストを実行し、GitHubのプルリクエスト（PR）を作成するまでの実装作業全般を担当します。驚くべきことに、現在のWarpの開発組織では、作成されるPRの約90%にエージェントが関与しています。 この高度な自律開発を実用レベルで支えているのが、OpenAIの最新モデル「GPT-5.5」です。 GPT-5.5は広範囲なコードベースや複雑な文脈を理解する推論能力に優れており、一世代前のモデル（GPT-5.4）と比較して、コーディングタスク1回あたりに消費するトークン（AIが処理するデータの単位）を30%も削減しました。これにより、AIを長時間稼働させる開発プロセスのコストが劇的に抑えられ、より実用的な運用が可能になりました。 さらにWarpは、ローカル環境とクラウド環境にまたがる大量のAIエージェントを調整・管理（オーケストレーション）するためのコントロールプラットフォーム「Oz（オズ）」を開発しました。「Oz」はWebインターフェースからエージェントの動きを監視でき、長時間のタスクでもAIが文脈（コンテキスト）を見失わないように記憶を整理・保持する役割を持ちます。難易度が高いタスクにはGPT-5.5が自動で割り当てられる仕組みです。 Warpは、将来のソフトウェア開発が「1人の開発者がAIを道具として使う形」から「人間が多数の自律的なAIエージェントを指揮・統制するシステム」へと進化していくと確信しています。 人間は「どのような製品を作るか」というビジョンの提示や判断に集中し、実装の多くをAIが担う。そんなワクワクするような開発の未来が、Warpと最新AIの力によって実現されようとしています。 引用元: https://openai.com/index/warp NVIDIA Dynamo Snapshot: Fast Startup for Inference Workloads on Kubernetes Kubernetes上でLLMなどのAI推論ワークロードを実行する際、急激なアクセス増加（トラフィックスパイク）に応じてサーバーを自動で増やす必要があります。しかし、起動時にコンテナの読み込みや、数GB〜数百GBに及ぶモデルの重み（パラメータ）のロード、GPUの初期化などに数分レベルの時間がかかる「コールドスタート問題」が存在し、迅速なスケールアウトの妨げになっていました。 NVIDIAはこの課題を解決するため、起動時間を極限まで短縮する「NVIDIA Dynamo Snapshot」を発表しました。これは、実行中のプロセスやGPUの状態を一時保存（チェックポイント）し、別のノードで瞬時に再開（リストア）する技術です。 新人エンジニアの方に向けて、この技術の核となる仕組みと、高速化のための3つのエンジニアリング手法を分かりやすく解説します。 1. 基本的な仕組み ホスト（CPU）側のメモリやプロセスの状態保存には、Linuxのオープンソースツールである「CRIU（ユーザー空間でのチェックポイント/リストアツール）」を使用します。GPU側の状態は、CUDAドライバの機能を使って保存します。Kubernetes上では、各ノードに常駐する「snapshot-agent」がこれらを連携させ、コンテナ単位で状態を共有ストレージへ保存・復元します。 2. 劇的な高速化を実現する3つの最適化 最適化①：KVキャッシュの解放による保存サイズ削減 保存する前に、まだ使われていない推論用のメモリ領域（KVキャッシュ）を一時的に解放します。これにより、保存データのサイズを最大で約30分の1（190 GiBから6 GiBなど）に削減し、読み書きの時間を大幅に減らします。 最適化②：リストア（読み込み）処理の並列化・非同期化 従来のCRIUはデータを1つずつ順番に読み込んでいたため、高速ストレージの性能を活かせませんでした。これを並列処理（マルチスレッド）および非同期I/O（Linux AIO）に改良し、ディスクからの読み込みを極限まで高速化しました。 最適化③：GPU Memory Service (GMS) によるデータの分離 最も容量の大きい「モデルの重みデータ」をプロセスから切り離し、プロセスの復元と重みの転送を並列で実行できるようにしました。これにより、1200億パラメータの超巨大モデル（gpt-oss-120b）でも、5秒以下での超高速起動（従来の21倍高速）に成功しました。 まとめと今後のロードマップ 現在はシングルGPU構成の実験的リリースですが、今後は複数GPU/複数ノード構成への対応、NCCLなどの通信ライブラリとの連携、TensorRT-LLMのサポートなどが計画されています。LLM推論インフラの運用を劇的に効率化する、非常に実用価値の高い技術です。 引用元: https://developer.nvidia.com/blog/nvidia-dynamo-snapshot-fast-startup-for-inference-workloads-on-kubernetes/ 「メッシュ反転じゃん…」皮膚が反転するバグで手術することになったが3DCGの勉強のおかげで理解できた→実際には反転していないが対処方はCGと同じ？ 座り仕事が原因で発症する「毛巣洞」という病気で手術することになった投稿者が、医師から「皮膚が反転している」と説明され、3DCGの「メッシュ（法線）反転」バグとして理解したユーモラスなエピソード。実際には反転ではなく皮膚の陥入部で炎症が起きている状態ですが、手術による治療を「頂点マージ（結合）」に例えるなど、3DCGや開発に馴染みのあるエンジニアたちの間でクスッと笑える共感を呼んでいます。 引用元: https://togetter.com/li/2702416 お便り投稿フォーム VOICEVOX:ずんだもん
Transcribe →株式会社ずんだもん技術室AI放送局 podcast 20260528
1w agoTap to summarizeyoutube版(スライド付き) 関連リンク ローカルの 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 お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）
Transcribe →株式会社ずんだもん技術室AI放送局 podcast 20260527
1w agoTap to summarizeyoutube版(スライド付き) 関連リンク OpenClaw作者、エージェントスキルのチェックツール「Skill Cleaner」をGitHubで公開 gihyo.jp パーソナルAIアシスタント「OpenClaw」の作者であり、現在はOpenAIに所属するPeter Steinberger氏が、AIエージェントの動作を定義する「エージェントスキル」を最適化するためのチェックスクリプト「Skill Cleaner」をGitHubで公開しました。 AIエージェント開発における重要な課題と、このツールが解決する内容、およびその制約について分かりやすく解説します。 1. 開発の背景：なぜこのツールが必要なのか？ AIエージェント（AIアシスタントやCodexなど）を開発する際、エージェントに特定の動作や役割を教え込むために「エージェントスキル（指示文）」を記述します。 しかし、この説明が長くなりすぎると、AIが処理する際にすべて「コンテキスト（文脈情報）」として読み込まれてしまいます。その結果、以下の問題が発生します。 コストの増加: AIの利用料金は処理する文字数（トークン数）に応じて課金されるため、不要な文章が多いとコストが余計にかかります。 処理速度の低下: 大量のコンテキストを読み込むことで、AIの応答速度が低下します。 人間向けに分かりやすく書かれた冗長な表現（つなぎ言葉など）は、AIエージェントにとっては不要です。トークン効率を最大化し、本当に必要な指示だけを簡潔に書くことが、エージェント開発において非常に重要です。 2. 「Skill Cleaner」の概要 「Skill Cleaner」は、記述されたエージェントスキルをスキャンし、コストを最適化するための提案レポートを出力するツールです。 無駄の排除: 重複しているスキルや、ログなどから判定した「一度も使われていないスキル」を特定し、削除や無効化を提案します。 簡潔な表現への修正: よりトークン数を節約できる簡潔な説明文を提案します。 安全なコミット作成: ユーザーが提案を受け入れた場合、説明の修正やスキルの削除などを目的ごとにグループ分けした小さなコミットとして自動で適用します。 3. ツールに関連する制約 ツールを使用する、あるいはエージェントスキルを設計するにあたり、以下の制約が存在します。 スキル予算（Skill Budget）の制限: Codexなどのシステムでは、スキル説明に割り当てられるコンテキスト容量が「全体の2％まで」に制限されています。これを超えると、AI側で勝手に文章が切り詰められたり省略されたりするため、ツールはこの予算内に収まるような提案を行います。 未追跡ディレクトリの保護: Gitの追跡対象外（untracked）となっているスキルディレクトリに対しては、意図しないデータ消失を防ぐため、削除先が指定されているか、削除しても問題ないことが確認されるまで自動削除を実行しません。 引用元: https://gihyo.jp/article/2026/05/skill-cleaner AWS MCP Server がGAに - Claude Codeから検証: IAMガードレール設計 フューチャー技術ブログ 2026年5月、AWSは「AWS MCP Server」の一般提供（GA）を開始しました。これは、Claude Codeなどの「AIコーディングエージェント」が、AWSリソースへ安全にアクセスできるようにするマネージドな接続エンドポイント（Model Context Protocol）です。本記事では、この機能の概要と、新人エンジニア向けにセキュリティ（IAMガードレール）と監査の重要ポイントをわかりやすく解説します。 1. AWS MCP Serverの概要と機能 AWS MCP Serverを導入することで、AIエージェントは提供される11個のツールを活用して自律的に動けるようになります。ツールは大きく2系統に分かれます。 知識・ドキュメント系（6個）: 最新の公式ドキュメントをAI自身が検索・読込できます。これにより、LLM（大規模言語モデル）の知識カットオフ以降にリリースされた最新のAWSサービスについても、正確な情報を自律的に取得して回答できるようになります。 API実行系（5個）: 自然言語の指示から適切なAPI呼び出しを組み立てて実行します。「稼働中のEC2と、その作成者をCloudTrailから探して一覧にして」といった、人間が手動で行うと複数ステップかかる複雑な調査も、AIが自動で複数APIをオーケストレーションして整理・回答してくれます。 2. 安全性を担保する「IAMガードレール」設計 AIエージェントにAWSの操作を任せるにあたり、意図しないリソース削除などの事故を防ぐセキュリティ設計（ガードレール）が不可欠です。本サービスでは主に以下の2つのアプローチで制御します。 経路別の制御（コンテキストキーの活用）: IAMポリシーの条件式で aws:ViaAWSMCPService などの条件キーを使用します。これにより、「人間が直接操作するときは管理者権限を許すが、AIエージェントを経由したアクセス（MCP経由）のときだけは特定の破壊的アクション（インスタンスの削除など）を禁止する」といった経路別の制御が可能です。 専用ロールの利用（AssumeRole）: AIエージェント専用の読み取り専用（ReadOnly）ロールを作成し、一時クレデンシャルをエージェントに渡すアプローチです。エージェントが利用する権限そのものを最初から安全な範囲に絞り込めます。 3. 行動を可視化する「CloudTrail監査」 AIが実行した全ての操作は、AWSの監査ログ（CloudTrail）にしっかりと記録されます。ログ内の userIdentity.invokedBy に aws-mcp.amazonaws.com が記録されるため、「人間が直接行った操作」と「AIが代行した操作」を明確に区別・追跡できます。 なお、接続元IPアドレスがAWS MCPの固定値になるため、オフィス等のIP制限（aws:SourceIp）を厳しく設定している環境では、アクセス拒否されないようポリシーの調整が必要となる点に注意が必要です。 まとめ AWS MCP Serverは、AIを用いたインフラ運用や開発を安全に加速させる強力な機能です。ガバナンスを効かせた設計が可能なため、エンタープライズ環境でも安心して導入できます。まずは開発用のサンドボックス環境にて、書き込みを防ぐ読み取り専用（--read-only）設定から手軽に試してみるのがおすすめです。 引用元: https://future-architect.github.io/articles/20260525a/ Agentic AI時代における メルカリのAIガバナンスとガードレール実装 本資料は、AIが自律的にタスクを実行する「Agentic AI（AIエージェント）」の普及に伴い、メルカリがどのようにセキュリティリスクを管理し、安全な開発・業務環境（ガードレール）を構築しているかを解説したものです。 メルカリでは、従業員のAIツール利用率が100%に達し、ソースコード生成の約70%にAIが関与しています。AI活用が急速に進む一方で、AIの自律的な動作に伴う新たなリスク（AIの暴走、意図しないシステム破壊、機密情報の漏洩、過剰な権限による不正操作など）が課題となっています。 これに対し、メルカリでは主に以下の3つのアプローチで対策を実装しています。 体制の整備と並走型の支援 単に利用を制限するのではなく、AI活用を推進するチームと並列で「AI Risk & Governanceチーム」や「AI Securityチーム」を設立。セキュリティメンバーが開発プロジェクトに直接参画し、現場に並走しながら安全な実装をサポートしています。 具体的なガードレールの実装（技術的アプローチ） エージェントの動作制限（サンドボックス化）: AIエージェント（Claude Code等）に対し、管理者設定を用いて全社共通の制限ルールを強制適用しています。例えば、認証情報ファイルの読み取りや、危険なコマンド（git push --force や sudo など）の実行をシステム的に禁止しています。 認証情報（クレデンシャル）の安全管理: AIツールに直接APIキーを持たせないよう、API管理サーバー（LiteLLM）を経由させ、有効期限の短い一時的なキーを発行することで漏洩リスクを低減しています。 ワークフローの自動審査: ワークフロー作成ツール（n8n）の設定ファイルを自動検査し、機密データの流出リスクなどを検知するツール「n8ncheck」を自社開発してオープンソース化。手動審査の工数を80%削減しました。 シャドーAI（未承認ツール）対策 個人のアカウントを用いた未承認のAIツール利用を防ぐため、ネットワークやアプリ、データアクセスの各レイヤーでアクセスを制限し、会社が認めた安全なツールのみを公開・利用させています。 まとめ Agentic AIの時代においては、セキュリティを設計段階から組み込む「Secure By Default」の思想が不可欠です。ガードレールを設置して終わりにせず、運用中に発生する新たなリスクや「ヒヤリハット」を継続的に監視し、対策をアップデートし続けることが重要となります。 引用元: https://speakerdeck.com/naoichihara/agentic-aishi-dai-niokeru-merukarinoaigabanansutogadorerushi-zhuang お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）
Transcribe →株式会社ずんだもん技術室AI放送局 podcast 20260526
1w agoTap to summarizeyoutube版(スライド付き) 関連リンク Harness, Scaffold, and the AI Agent Terms Worth Getting Right AIエージェントの分野は急速に進化していますが、それに伴い「Harness（ハーネス）」や「Scaffold（スカフォールド）」といった開発に欠かせない重要用語が、文脈によって異なる意味で使われ、混同されがちです。本記事は、これら曖昧になりがちな用語を整理し、新人エンジニアの方でも直感的に理解できるよう共通のメンタルモデルを提供するものです。 ■ 1. エージェントの基本構成：Model、Scaffold、Harness AIエージェントの全体像は、一般的に「エージェント ＝ モデル ＋ ハーネス（＋スカフォールド）」として捉えられます。 Model（モデル）: LLM（Claude、GPT、DeepSeekなど）そのものを指します。テキストを入力してテキストを出力するだけの存在であり、単体では過去の会話を記憶するメモリや処理を繰り返すループを持たず、自らツールを動かすこともできません。 Scaffolding（スカフォールド / 足場）: モデルの「振る舞い」を定義する層です。システムプロンプト、ツールの説明、モデルの応答をパース（解析）する方法、コンテキスト管理など、モデルが外部世界とどう対話するかを定義する設計図や設定情報を指します。 Harness（ハーネス / 実行部）: エージェントを実際に「走らせる」ための実行システムです。モデルを呼び出し、モデルから返ってきたツールの実行指示（API呼び出しなど）を実際に処理し、いつタスクを終了するかを判断する「ループ（実行サイクル）」を管理します。 ■ 2. エージェントの自律性を支える重要概念 Agent（エージェント）: モデルにハーネスとスカフォールドを組み合わせ、自律的に思考・行動のループを回せるようにした「システム全体」を指します。 Context Engineering（コンテキストエンジニアリング）: プロンプトや会話履歴、外部から検索した知識など、モデルのコンテキスト窓に「何を・どう流し込むか」を動的に設計・管理する技術です。 Policy（ポリシー）: エージェントが特定の状況で取るべき行動ルール。モデル自身の重み（学習データ）だけでなく、周囲のプロンプトやハーネスの制御によって形作られます。 Tool Use（ツール使用）とSkills（スキル）: 前者は「コマンドを実行する」などの単一のAPI呼び出し。後者は「バグを調査して修正を適用する」といった、複数ステップにわたる再利用可能な知識のパッケージです。 Sub-agents（サブエージェント）: 特定のタスクを肩代わりさせるために、親エージェントから呼び出される独立したエージェントです。 ■ 3. モデルの「トレーニング（学習）」に関する用語 エージェントの性能を向上させる強化学習（RL）の文脈では、以下の用語が使われます。 RL Environment（環境）: エージェントがツール呼び出しなどのアクションを実行し、状態を変化させる対象（ファイルシステムなど）。 Trainer（トレーナー）: エージェントを多数実行し、スコアを元にモデルの重みを更新するシステム。 Rollout（ロールアウト）: エージェントの開始から終了までの一連の行動履歴（ログ）。 Reward（報酬）: 実行結果が正しかったかを判定するスコア。 ■ まとめ CursorやClaude Codeなどのエージェント製品は、仮に同じベースモデルを使っていても、独自の「ハーネス」や「スカフォールド」の設計によって使い心地や性能が劇的に変わります。「モデル」「スカフォールド」「ハーネス」という3つのレイヤーを区別して捉えることで、複雑なエージェントの仕組みがすっきりと理解できるようになります。 引用元: https://huggingface.co/blog/agent-glossary Distributing LLM inference in DwarfStar 高価なNVIDIA製GPUを使わずに、一般家庭や小規模なオフィス環境で巨大な大規模言語モデル（LLM）を動かすための「分散推論（Distributed Inference）」の手法について、Redisの作者であるantirez氏が考察した記事です。 現在、ローカル環境でLLMを動かす現実的な手段として、大容量の統一メモリ（Unified Memory）を搭載したMac Studio等のApple製品が重宝されています。例えば、M3 Ultra（512GBメモリ）を搭載したMac Studioであれば、最先端モデルであるDeepSeek v4 PROの量子化版を実用的な速度で動作させられます。しかし、今後のハードウェアの進化スピードやメモリコストの上昇を考えると、単一の超高額マシンに頼り続けるのには限界があります。そこで、手元にある複数台のマシン（例：MacBook Pro M5 Maxなど）を連携させて推論を行う「分散推論」が非常に魅力的な選択肢となってきます。 本記事では、複数台の限られたリソースを連携させるための3つの分散アプローチを提案・比較しています。 レイヤー分割（順次実行） LLMのレイヤー（層）をマシンAとマシンBに半分ずつロードし、順番に処理をバトンタッチしていく手法です。マシン間で送受信するデータはレイヤー間の中間データ（アクティベーション）のみで済むため、非常にシンプルです。「マイクロバッチング（処理の細分化）」を適用することで、入力プロンプトの初期処理（プレフィル）を大幅に高速化でき、マシンの発熱も抑えられます。 エキスパートの並列実行（垂直分割） MoE（Mixture of Experts：特定の処理に特化した複数のネットワークを切り替える仕組み）モデルにおいて、双方のマシンにすべてのエキスパートをロードしておき、処理を並列に分担する手法です。一般家庭のネットワーク環境では、GPU同士を繋ぐような超高速通信（NVLink等）が利用できないため細かい並列化（テンソル並列など）は困難ですが、この手法であれば通信量を抑えつつ並列化できる可能性があります。 アンサンブル（共有なし） 複数台のマシンでそれぞれ異なるLLMを完全に独立して動かし、最終的な出力データ（ロジット）や、最も確証度が高いテキストを最後に統合・選択する手法です。推論中の中間通信が一切発生しないため、ネットワークの帯域を気にする必要がありません。最新の研究では、この手法により、それぞれのLLMの知識が補完し合い、単一で動かすよりも推論精度が向上することが示されています。 通信帯域が限られるローカルのマルチマシン環境において、この「アンサンブル」を利用した分散推論は非常に現実的かつ強力なアプローチであり、今後の開発や検証が大いに期待される分野です。 引用元: http://antirez.com/news/167 Snowflake Cortex CLI と AI Agent Loop を用いた MLOps 基盤構築 本記事は、機械学習（ML）の専門知識や運用基盤が十分に整備されていない組織において、AIエージェントを活用してモデルの選定から本番リリースまでを自動化する「MLOps（機械学習運用）基盤」の構築事例を紹介しています。 従来のシステムのようにあらかじめ決められたデータパイプラインを実行するのではなく、状況に応じて動的な意思決定ができる「AIエージェントベース」の仕組みを採用している点が最大の特徴です。これにより、MLOpsに詳しくないメンバーでも扱いやすく、要件変更にも柔軟に対応できるシステムを実現しています。 ■ 全体の流れと進捗の可視化 開発や運用の進捗状況は、使い慣れたGitHub IssueやSlack、GitHubカンバンを通じて人間がリアルタイムに確認・レビューできます。 Snowflake上への学習用データの準備 実践したい内容（やりたいこと）を記述した「GitHub Issue」を作成 4つのAIエージェントが連携する「AI Agent Loop」を起動 各フェーズが完了するとSlackへの通知とカンバンの移動が行われ、人間がレビューした後に次のステップへ進む ■ 4つの役割特化型AIエージェント 本基盤では、MLのワークフローを以下の4つのエージェントに分割して処理させています。 snowflake-plan（計画・準備）: 必要な機械学習の実行環境をSnowflake上に自動で準備し、実行計画を作成します。 snowflake-develop（開発・評価）: テスト環境でデータの前処理やモデルの学習・比較を行い、最も精度の高かったモデルを選定します。データリーク（未来のデータを学習に使ってしまうミス）の自動チェック機能も備えています。 snowflake-verify（本番検証）: 選定された最良モデルの構成を、本番環境のデータに適用して再検証します。 snowflake-release（リリース）: 検証済みのモデルをSnowflakeの管理機能に登録し、本番のWebサービス等で使えるよう設定を更新します。 ■ AI自動化と状態管理の仕組み ・自然言語による操作（Skills & Cortex）: Snowflakeの操作には「Cortex CLI」を使用しており、AIエージェントが自然言語に近い形で「〇〇というNotebookを作成して」などの指示を送り、自動で操作を実行します。 ・状態ファイル（mlops-state.json）による管理: エージェント自身は状態を持たず、この共通のJSONファイルを読み書きすることで「現在のフェーズ」や「選定されたモデル情報」をバトンタッチします。これによりエージェント同士が密に依存し合わない、シンプルな連携を実現しています。 本取り組みは、単なるプログラムの自動実行にとどまらず、AIエージェントが状況を判断しながら自律的にMLワークフローを進め、人間と協調して本番運用までを繋ぐ、実用的な次世代MLOps基盤の好例です。 引用元: https://zenn.dev/sirok/articles/13bcaed37f893c renue、ClaudeCodeの処理完了を通知する「コードだもん ビーコン」をリリース 株式会社renueは、AIコーディング支援ツール「Claude Code」の処理完了を通知するUSBガジェット「コードだもん ビーコン」を発売しました。これは、時間のかかるAIの処理完了を検知し、デスク上の「ずんだもん」が上下に動いて視覚的に知らせる無音設計のデバイスです。ドライバ不要でPCに挿すだけで使え、画面を見続けずに別作業に集中できるため、エンジニアの作業効率化と癒やしを同時に提供します。 引用元: https://prtimes.jp/main/html/rd/p/000000042.000091210.html お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）
Transcribe →マジカルラブリー☆つむぎのピュアピュアA.I.放送局 podcast 20260525
2w agoTap to summarize関連リンク エージェント向けの Chrome DevTools ■ 概要 「エージェント向けの Chrome DevTools（Chrome DevTools for Agents）」は、AIエージェントがGoogle Chromeブラウザを自律的に操作し、WebサイトやWebアプリケーションのテスト、検証、デバッグを行えるようにするための公式ツールです。これまで人間が手動で行っていたブラウザ上での検証作業を、AIエージェントが肩代わりできるようになります。 ■ 新人エンジニア向け：なぜこれが嬉しいの？ Web開発において、私たちは普段Google Chromeの「デベロッパーツール（DevTools）」を使って、画面崩れの確認やエラーの原因特定を行っています。 このツールを使うと、開発をサポートしてくれるAIアシスタント（ClaudeやGeminiなど）に対して「このサイトのスマートフォン表示を確認して」「表示速度が遅い原因を調べて」と指示するだけで、AIが裏側で本物のChromeブラウザを操作し、DevToolsの機能を使って自動的に調査・デバッグを完了してくれるようになります。 ■ AIエージェントができる3つの主要機能 ユーザーエクスペリエンスの再現（エミュレート） スマートフォンやタブレットなどの異なる画面サイズ（レスポンシブデザイン）での表示確認、特定の位置情報（例：海外の都市）を擬似的に再現した表示テスト、ボタンをクリックして画面を遷移する一連の操作テストなどを自動で実行します。 稼働中のブラウザのリアルタイムデバッグ 実際に動いているChromeブラウザのセッションにAIエージェントを直接接続させ、リアルタイムでページ要素の検証やエラーのトラブルシューティングをさせることができます。 Lighthouse（ライトハウス）を活用した品質テスト コードを本番環境に公開（リリース）する前に、Webサイトの表示速度、アクセシビリティ（使いやすさ）、SEO（検索エンジン最適化）などの自動チェックを実行させ、改善すべき点の具体的なチェックリストを作らせることができます。 ■ 導入・利用環境について 本ツールは、AIと外部ツールを連携するための共通規格である「MCP（Model Context Protocol）」に対応しています。そのため、以下のようなエンジニア向けの各種AIツールにプラグインとして手軽に導入可能です。 Claude Code や Gemini CLI などのコマンドラインAIツール Googleの「Antigravity 2.0」に内蔵されたブラウザサブエージェント Codex、Copilot、OpenCode などのコーディングアシスタント ■ まとめ 「エージェント向けの Chrome DevTools」は、Web開発における面倒な「手動での動作確認やバグ探し」をAIに任せるための画期的なツールです。これを活用することで、開発サイクルを高速化し、エンジニアはよりクリエイティブな実装に集中できるようになります。 引用元: https://developer.chrome.com/docs/devtools/agents?hl=ja Towards Speed-of-Light Text Generation with Nemotron-Labs Diffusion Language Models 【背景：従来のLLMが抱える「速度の壁」】 現在広く使われているLLMの多くは「自己回帰（AR）」という、1文字（トークン）ずつ順番に生成する仕組みを採用しています。この方法は精度が安定している一方で、1文字出力するたびに巨大なモデル全体を動作させる必要があるため、超高速なGPUを使っても「メモリからのデータ読み込み待ち」が発生し、GPUの計算能力を余らせてしまうボトルネックがありました。また、一度出力した文字を途中で修正できないという欠点もありました。 【新技術：並列で文字を生成・修正する「拡散言語モデル」】 NVIDIAが発表した「Nemotron-Labs Diffusion」は、画像生成AIなどで使われる「拡散モデル」の考え方を応用した言語モデル（DLM）です。文字を1つずつではなく「並列で一気に生成」し、それをステップごとに「洗練（ノイズ除去）」していくことで、GPUの並列計算能力をフルに活かした超高速なテキスト生成を可能にします。また、出力の修正や文章の「穴埋め」タスクも得意としています。 【1つのモデルで選べる3つの生成モード】 このモデルは、用途に応じて以下の3つの動作モードを簡単に切り替えられます。 自己回帰（AR）モード：従来と同じ1文字ずつの生成。互換性や出力の正確さを確認する際の基準（リファレンス）として役立ちます。 拡散モード：ブロック単位（例：32トークン）で一気に並列生成し、徐々にノイズを除去して綺麗にする高速モード。 自己投機（Self-speculation）モード：拡散モードで「下書き（候補）」をまとめて作成し、ARモードで「一気に答え合わせ（検証）」を行うことで、速度と精度を両立した最も強力なモードです。 【驚異的なパフォーマンスと実用性】 同等規模の高性能モデルと比較して精度を維持しつつ、処理効率を劇的に進化させました。従来のARモデルに比べ、デコード効率は拡散モードで2.6倍、自己投機モードでは約6倍に向上します。さらに最新のNVIDIA B200 GPUを用いたテストでは、1秒間に約865トークン（従来比約4倍）という驚異的な生成速度を達成しました。 本技術は、商用利用可能なライセンスで3B、8B、14BなどのサイズがHugging FaceやGitHubにて公開されています。推論エンジン「SGLang」にも対応予定で、設定を1行変えるだけで各モードを切り替えられます。既存のアプリ構成を崩さずに、AIの回答速度を爆発的に高められる注目の技術です。 引用元: https://huggingface.co/blog/nvidia/nemotron-labs-diffusion Claude Code で使える DuckDB Skills を試してみた + AWS運用の活用を考えてみた #opsmethod 登壇資料 本記事は、AIエージェントツール「Claude Code」に、分析用データベース「DuckDB」の公式プラグイン「duckdb-skills」を導入し、AWSの運用業務を劇的に効率化する検証を紹介したものです。 登場する主要な技術 新人エンジニアの方に向けて、今回活用されている3つの技術を分かりやすく整理します。 DuckDB: データの分析（OLAP）に特化した、高速かつ軽量なデータベースです。CSVやJSON、Parquetといったファイルを、データベースにわざわざ取り込むことなく直接SQLで検索できます。 Claude Code: ターミナル上で動作する、AIを活用した最先端の開発・コーディング支援ツール（AIエージェント）です。 Agent Skills: AIエージェントに新しい専門知識や機能を追加するための、拡張プラグインのような仕組みです。 「duckdb-skills」でできること Claude Codeにこのスキルを追加することで、ターミナル上でAIに対して自然言語（日常の言葉）で指示を出すだけで、データの読み込みや分析ができるようになります。 read-file: CSVやJSONなどのファイル構造（スキーマ）を自動で判別して読み込みます。 query: ファイルやデータベースに対し、SQLを書かなくても自然言語の指示だけで自動的にクエリを作成・実行してくれます。 ※注意点として、本スキルは現在macOSとLinux向けにテストされており、Windows環境では一部機能が制限される可能性があります。 AWS運用における3つの実用デモ 記事では、実際のAWS運用における「データ構造の把握」や「トラブルシュート」を想定した、強力なデモが紹介されています。 コストデータ（CUR）の調査: AWSのコストと使用状況レポート（CSV）の構造をAIに把握させ、特定サービスの料金内訳や無料枠の適用状況を、自然言語での質問だけで瞬時に整理させました。 ALBアクセスログの調査: ALBのアクセスログ（gz形式）を直接読み込ませ、エラー（ステータスコード）の発生件数の推移や、エラーの要因となっている通信の集計を自動で行わせました。 CloudTrailイベント履歴の調査: 操作履歴のCSVを読み込ませ、「いつ・誰が・何の操作をしたか」を深掘りし、特定リソース（ALB）の作成イベントに関連する一連の操作ログを特定させました。 まとめと今後の展望 複雑なSQLを自力で組み立てることなく、自然言語のままスムーズにログ分析やコスト調査ができる点において、非常に優れた開発体験が得られます。トラブルシュートやログ分析のスピードを大きく向上させる実用的なアプローチです。 一方で、現在はローカル環境へのセットアップが必要なため、チーム全体で共通の運用に乗せるには少しハードルがあります。将来的には、チームで手軽に使える自然言語対応の分析サービスが登場することが期待されます。 引用元: https://dev.classmethod.jp/articles/opsmethod-2-duckdb-skills/ 消しゴムなし、補助ツールなし、3分で名画を再現しろ──理不尽すぎる名画模写ゲーム『Sloppy Forgeries』が最高のパーティゲームだった 本作は、お題の名画を3分以内にとにかく「雑に、それっぽく模写できるか」を競う対戦型ゲームです。消しゴムや定規などの補助機能はなく、ペンの太さも3種類のみ。この極限まで制限されたシステムと短い時間制限により、どんな人でも強制的に「画伯」になってしまう理不尽さが笑いを誘います。機能の少なさ（制約）が最高のエンタメ体験を生み出している、開発者目線でもUI/UXの参考になる面白い一作です。 引用元: https://news.denfaminicogamer.jp/kikakuthetower/260523x お便り投稿フォーム VOICEVOX:春日部つむぎ
Transcribe →私立ずんだもん女学園放送部 podcast 20260522
2w agoTap to summarizeyoutube版(スライド付き) 関連リンク An OpenAI model has disproved a central conjecture in discrete geometry OpenAIが開発した新しい汎用推論AIモデルが、数学界で約80年間未解決だった難問「エルデシュの単一距離問題」の予想を覆す証明を自律的に導き出しました。AIが数学の主要な未解決問題を人間の手を借りずに解決したのは史上初の快挙であり、AIと人間による共同研究の新たな未来を示す重要なマイルストーンとなりました。 1. 解決された難問「単一距離問題」とは？ この問題は、1946年に天才数学者ポール・エルデシュが提唱した離散幾何学の超有名問題です。「平面上に $n$ 個の点を置くとき、距離がちょうど『1』になる点のペアは最大で何個作れるか？」という非常にシンプルな問いです。 これまでは「格子状（正方形グリッド）に並べる方法」がほぼ最適であり、これ以上のペースでペア数を増やす配置は存在しない（$n^{1+o(1)}$ が上限である）と広く信じられていました。しかし、OpenAIのモデルはこの予想を覆し、それを上回る効率でペアを作れる「新しい点の配置ルール」が無限に存在することを証明しました。 2. なぜAIにこれができたのか？（技術的な驚き） 今回のブレイクスルーには、エンジニアにとっても注目すべき2つのポイントがあります。 汎用推論モデルによる自律的な解決: この証明は、数学専用にファインチューニングされたAIや、特定の検索アルゴリズムを組み込んだシステムではなく、新世代の「汎用推論モデル」によって達成されました。これは、AIが「長大で複雑な論理の鎖を、破綻させずに組み立てる高い推論能力」を手に入れた証拠です。 異分野の知識を融合する「独創性」: 幾何学の問題に対し、AIは一見関係のなさそうな「代数的数論」という全く別の数学分野の高度な理論（無限類体塔など）を組み合わせて解決策を提示しました。これは単なるデータの学習やパターンの暗記ではなく、異なる知識を結合して新しいアイデアを生み出す「創造的な思考」がLLMに可能であることを示しています。 3. 私たちエンジニアにとっての意味 この成果は、数学の世界に留まらず、AIが今後のあらゆるエンジニアリングや科学研究の強力な「パートナー」になる未来を強く予感させます。 複雑なソフトウェアアーキテクチャの設計、高度なバグの検出、物理や材料科学における新発見など、厳密な論理的整合性が求められるタスクにおいて、AIは人間のアシスタントを超え、人間が思いつかないような革新的なアプローチを自発的に提案してくれる存在になりつつあります。 「AIが人間の仕事を奪う」という悲観的な見方ではなく、「人間が解くべき重要な問い（プロンプトや課題設定）を決め、AIがその独創的な思考力で探究を加速させる」という、人間とAIのワクワクするような協働の形が、まさに始まろうとしています。 引用元: https://openai.com/index/model-disproves-discrete-geometry-conjecture Appleが神アプデ！ ネット不要で安全なオンデバイスAIを自分のアプリに直接組み込める『Foundation Modelフレームワーク』の近未来UX DXマガジン 本記事は、Appleが提供を開始した「Apple Intelligence」の最新アップデートと、それに関連する開発者向けの新フレームワークについて解説しています。これにより、アプリ開発者はセキュリティの高いオンデバイスAI機能を、極めて簡単に自作アプリへ組み込めるようになります。 ■ 1. 開発者待望の「Foundation Modelフレームワーク」 最も大きな技術的革新は、Appleの「オンデバイス基盤モデル」に直接アクセスできる新しい開発環境（フレームワーク）の提供です。 完全なオンデバイス動作：インターネット接続を一切使わずにAI処理がデバイス内で完結します。データが外部に送信されないため、個人情報や機密データを扱うアプリでも安全に利用できます。 わずか3行のコードで実装：Swiftにネイティブ対応しており、最小限（わずか3行）のコードを記述するだけで、高度なAIモデルを呼び出せます。これまで膨大だったAIの組み込みコストが劇的に削減されます。 手軽なAI機能の実装：テキストの要約、データ抽出、ガイド付きテキスト生成、他のツールとの連携といった高度な機能を、既存のiOSアプリやゲームへスムーズに実装できます。 ■ 2. 画面をすべて認識する「ビジュアルインテリジェンス」 ユーザーが体験する操作性（UX）も大きく進化します。 画面そのものを検索・解析：iPhoneに表示されている「現在の画面」をAIが瞬時に認識します。スクリーンショットを撮るような手軽さで、画面上のコンテンツについて質問やアクションが可能です。さらに「App Intent」を介して自作アプリの検索機能を統合すれば、現実世界のオブジェクトをも含めた横断検索に対応できます。 ショートカット「Use Model」による自動化：ショートカットアプリに新機能が追加され、AIの応答を他の自動化タスクに直接引き渡せるようになります。 ■ 3. クリエイティブ表現の拡張 「ジェン文字」での髪型などの詳細なカスタマイズ機能や、「Image Playground」における表情のコントロール、さらに外部のChatGPT連携による多様なデザインスタイルの利用など、表現力も高まっています。 ■ まとめ（新人エンジニアへのメッセージ） 従来、高度なAIをアプリに組み込むには、クラウドサーバーの構築や複雑なAPI連携、コスト管理が必要でした。今回のアップデートにより、それらが「ローカルかつ数行のコード」で実現可能になります。これはモバイルアプリ開発のあり方を根底から変える出来事であり、ユーザーが「AIを使っている」と意識しない、極めて自然な次世代のユーザー体験（UX）を作るための強力な武器になります。 引用元: https://dxmagazine.jp/news/2620ty-23/ NVIDIA-Verified Agent Skills Provide Capability Governance for AI Agents AIエージェント（自律的にタスクを実行するAIシステム）の進化に伴い、エージェントに「どのような能力（スキル）を持たせるか」を安全に管理・統制（ガバナンス）する重要性が高まっています。NVIDIAが発表した「NVIDIA-Verified Agent Skills（検証済みエージェントスキル）」は、エージェントが使用するスキル（指示やツールのセット）の信頼性を担保し、安全にエージェントを拡張・運用するための新しい仕組みです。 1. 背景と課題：なぜ「スキルの検証」が必要なのか？ 従来のAIエージェントの安全対策は、実行時に不適切な入出力を制御する「ガードレール（実行時制御）」が中心でした。しかし、ビジネスの現場でエージェントを本格的に活用するには、エージェントに組み込む「機能（スキル）」そのものの安全性や透明性を事前に担保する仕組みが必要です。信頼できないスキルを読み込んでしまうと、予期せぬ動作やセキュリティリスクにつながるためです。 2. NVIDIA-Verified Agent Skillsの4つの特徴 検証済みのスキルは、オープンな仕様（agentskills.io）に基づいて構築されているため、Claude CodeやCursorなどの主要なAIコーディングアシスタントでも共通して安全に利用できます。主な特徴は以下の通りです。 Skill Card（スキルカード）: スキルの役割、作成者、ライセンス、依存関係、既知のリスクや制限事項などを機械可読な形式（YAML等）で記載した「透明性の高い説明書」です。 SkillSpectorによる事前スキャン: スキルが公開される前に、従来のソフトウェアの脆弱性だけでなく、プロンプトインジェクションや隠された指示、不要な権限の要求といった「AIエージェント特有のリスク」を自動で検出・ブロックします。 暗号署名による保証: ダウンロードしたスキルが改ざんされておらず、NVIDIAが公式に提供したものであることを証明するためのデジタル署名が付与されています。 公式チームによる日次同期: NVIDIAの製品チームが管理し、毎日最新の状態にアップデートされるため、常に正しく安全なスキルを利用できます。 3. 新人エンジニアに向けたポイント 実務でAIエージェントを構築する際、ただ動くだけでなく「システム全体の安全性と信頼性（ガバナンス）」を考慮することが不可欠です。本技術は、エージェントの能力を安全に流通させるための先駆的な取り組みであり、今後の安全なAI開発において必須となる「責任あるAI（Trustworthy AI）」の考え方を学ぶ上で、非常に参考になる仕様です。 引用元: https://developer.nvidia.com/blog/nvidia-verified-agent-skills-provide-capability-governance-for-ai-agents/ この前、魔の2歳児の対応についてGeminiに質問したら、「〇〇くんは～」と固有名詞を出され、「どこからその名前を参照しましたか？」と聞くとハルシネーションだった話 あるユーザーがGeminiに子供の相談をした際、教えていない子供の実名を提示され、AI側が「ハルシネーション（もっともらしい嘘）」と釈明した体験談です。偶然にしては不自然なため、Chromeの履歴やGoogleアカウントのアクティビティ、セッションを横断する「ユーザーサマリー（メモリ）」機能等を通じて、AIが裏で個人情報を参照している可能性が議論されており、AI利用時のデータ管理の重要性を学べます。 引用元: https://togetter.com/li/2699548 お便り投稿フォーム VOICEVOX:ずんだもん
Transcribe →株式会社ずんだもん技術室AI放送局 podcast 20260521
2w agoTap to summarizeyoutube版(スライド付き) 関連リンク Mastering Agentic Techniques: AI Agent Customization 本記事は、自律型AIエージェントを特定のビジネス業務（コード生成、問い合わせ対応、ワークフロー構築など）に最適化するための「9つのカスタマイズ手法」と、それらを組み合わせた「実践的なパイプラインの構築方法」を解説した技術記事です。 1. 9つのカスタマイズ手法 AIエージェントのカスタマイズは、手軽なプロンプト調整から、モデルの重みを書き換える高度な強化学習まで多岐にわたります。コストや目的に応じて使い分けます。 プロンプトエンジニアリング: 推論時に指示（システムプロンプト）を与える最も手軽な方法。ただし、複雑なタスクでは指示に従わなくなる限界があります。 RAG (検索拡張生成): 外部データベースから最新の専門知識を動的に取得し、ハルシネーション（嘘の回答）を防ぎます。 ツールとスキルの注入: API呼び出しやスクリプト実行などの「道具（ツール）」や「手順（スキル）」をエージェントに提供し、実行能力を拡張します。 SFT (教師あり微調整): 理想的な「入力と出力のペア」を学習させ、特定の出力形式（JSONなど）を徹底させます。 PEFT (LoRA/QLoRA): 全パラメータではなく一部のみを更新することで、少ないGPUリソースで効率的にSFTを行います。 DPO (直接好みの最適化): 「良い回答」と「悪い回答」のペアから学習させ、回答の品質やトーンを効率的に改善します。 RLHF (人間フィードバックによる強化学習): 人間の評価を模した報酬モデルを使い、安全性や親切さなどの複雑な基準に合わせます（コスト高）。 RLVR (検証可能な報酬を用いた強化学習): コードの実行結果や数式の正誤など、客観的に判定できるタスクに対して自動で報酬を与え、推論能力を大幅に向上させます。 GRPO (グループ相対ポリシー最適化): 複数の回答を同時に生成して相対評価する効率的な強化学習アルゴリズム（DeepSeek-R1等でも採用され注目を浴びています）。 2. 段階的な開発パイプライン（推奨される進め方） エージェント開発では、最初から複雑な学習を行うのではなく、以下のステップで段階的に進めることが推奨されています。 Stage 1 (足場作り): プロンプト調整、ツール注入、RAGでベースラインを構築。 Stage 2 (データ準備): 必要に応じて、合成データ生成（SDG）で学習データを作成。 Stage 3 (基礎学習): SFTを行い、タスクの基本形式や語彙をモデルに叩き込む。 Stage 4 (洗練): DPO（主観的なタスク向け）や、RLVR＋GRPO（客観的なタスク向け）を使い、モデルの推論力を極限まで高める。 Stage 5 (評価と反復): 精度を厳密に測定し、改善を繰り返す。 まとめ（新人エンジニアへのアドバイス） エージェント開発の鉄則は「まずは軽量な方法（プロンプトやRAG）から始め、効果を測定し、必要性をデータで確認できてから、学習ベースの高度なカスタマイズに挑戦する」ことです。NVIDIAが提供する「NeMo」などのツールキットを活用することで、これらの複雑なカスタマイズを効率的に実装できます。 引用元: https://developer.nvidia.com/blog/mastering-agentic-techniques-ai-agent-customization/ Prompts are technical debt too ソフトウェア開発において「すべてのコードは技術的負債である」とよく言われます。コードが増えるほどシステムの複雑さやメンテナンスの負担が増すため、優秀なエンジニアは書くコードを最小限に抑えようとします。しかし現代のAIを用いた開発では、コードの代わりに大量の「プロンプト」が書かれるようになっています。 本記事では、この「プロンプト」もまた、コード以上に厄介な技術的負債になり得るという重要な視点を提示し、エンジニアが取るべき対策を解説しています。 なぜプロンプトが「コード以上の技術的負債」なのか？ プロンプトの微調整はLLMの性能を大きく引き出しますが、そこには以下の深刻なリスクが潜んでいます。 モデルへの強い依存性 プロンプトの最適な書き方は、特定のモデル（例：GPT-4やClaudeの特定バージョン）に強く依存します。モデルがアップデートされると、それまで完璧に機能していたプロンプトが効果を失うだけでなく、新しいモデルの挙動をかえって阻害する（有害に働く）ことがあります。モデルが更新されるたびに、プロンプトを「そのモデル向けに再調整」し続けなければなりません。 サイレントな劣化（気づきにくさ） コードの負債（バグ）は、エラーの発生やシステムの速度低下など、目に見える形で現れます。しかし、プロンプトの劣化はエラーを吐きません。「出力される回答の質がなんとなく下がる」という形で静かに発生するため、エンジニアがその劣化に気づくことは非常に困難です。 プロンプト負債を防ぐための実践ガイド この「プロンプト負債」に苦しまないために、日々の開発で意識すべき3つのアプローチを紹介します。 独自のAI環境を作り込みすぎない 自分専用の複雑なプロンプト環境やエージェント構築に時間を費やすのは避けましょう。Cursor、Copilot、Claude Codeなどの実績ある外部ツールを、できるだけ「カスタマイズせずにデフォルトのまま」使うのが賢明です。ツールの開発会社が、モデルの更新に合わせてプロンプトを裏側で最適に調整してくれる恩恵をそのまま受け取りましょう。 振る舞いの制御ではなく「客観的な事実」だけを書く プロジェクト固有の指示ファイル（AGENTS.mdなど）を作成する際は、「ステップバイステップで考えて」「あなたは優秀なエンジニアです」といった、モデルの振る舞いをコントロールする指示は書かないようにします。これらはモデルの進化によってすぐに不要になります。代わりに、「このプロジェクトは〇〇というライブラリを使っている」「ビルドコマンドは〇〇である」といった、プロジェクト固有の「具体的な事実やルール」のみに限定して記述しましょう。 プロンプトは自分で書き、不要になったら捨てる AIに大量のプロンプトテキストを自動生成させるのは、レビューされていないコードを放置するのと同じです。プロンプトは必ず人間がシンプルに記述し、役割を終えたり、モデルが賢くなって不要になったりしたら、積極的に削除する習慣をつけましょう。 LLMの進化スピードが非常に速い現代において、プロンプトを複雑にメンテナンスし続けるのは不可能です。プロンプトもコードと同様に「少なければ少ないほど良い」という意識を持ち、シンプルで変化に強い開発スタイルを心がけましょう。 引用元: https://seangoedecke.com/prompts-are-technical-debt-too/ How Ramp engineers accelerate code review with Codex 米国のフィンテック企業Ramp社において、GPT-5.5を搭載したAIツール「Codex」を活用し、コードレビューの高速化や社内開発の効率化を実現した最先端の事例を紹介します。新人エンジニアの皆さんにとっても、これからの開発スタイルをイメージする上で非常に参考になる内容です。 1. コードレビューが数時間から「数分」に短縮 従来、Ramp社のエンジニアはプルリクエスト（PR）を作成してから最初のレビュー結果を得るまでに数時間待つ必要がありました。しかし、Codexの導入により、わずか数分で具体的かつ有益なフィードバックを受け取れるようになりました。 Codexは単なる構文チェックにとどまらず、コードベース全体を深く理解して「推論」する能力を持っています。そのため、人間のレビュアーや他のAIツールが見落としがちな複雑なバグも的確に検出します。エンジニアは、黒い画面（CLI）での操作や、グラフィカルな専用アプリなど、自分に合ったスタイルで快適にCodexを利用しています。 2. 複雑な社内AIアシスタント開発への応用 Ramp社では、システムの監視や緊急対応（オンコール業務）を担当するエンジニアを支援するエージェントツール「On-Call Assistant」の開発にもCodexを活用しています。 オンコール業務は、複雑なビジネスロジックや並行処理のバグ、刻々と変わる障害状況などを同時に把握する必要があり、エンジニアに大きな精神的負荷がかかります。Codexの高度な推論能力を活用することで、こうした複雑な社内ツールの開発スピードが飛躍的に向上し、自信を持って新機能をリリースできるようになりました。 3. AIツールを組織に浸透させるための秘訣 Ramp社の開発責任者であるAustin Ray氏は、新しいAIツールをチームに導入する際のポイントとして以下を提唱しています。 一緒に使って体験を共有する: 最初にエンジニアの横に座って一緒にツールを動かし、開発がどう楽になるかを実感させます。 不信感を信頼に変える道筋を作る: エンジニアは新しいツールに対して懐疑的になりがちです。最初の成功体験をガイドすることで、自発的に使ってみようという姿勢を引き出します。 開発元とのフィードバックループ: ツールを提供するCodexチームと直接連携し、課題が発生した際にすぐにフィードバックを送る関係性を築いています。 4. これからのエンジニアに求められるスキル Ramp社は、今後のエンジニアの役割は「すべてのコードを自分で書く人」から、AIツールを率いる「オーケストレーター（指揮者）」へと変化していくと考えています。 「AIをどのように指示し、どのタイミングで信頼し、いつ修正を求めるか」を判断する能力こそが、これからのエンジニアに最も求められるスキルになります。 引用元: https://openai.com/index/ramp 3COINSで売ってるビデオトランシーバーに大人がテンション上がってしまう「室内トランシーバーにできそう」なぜか起動音がPSPと同じだったりする 3COINSで発売された3,850円の「ビデオトランシーバー」が話題です。2.4GHz帯（技適取得済）を利用し、内蔵カメラでリアルタイム映像と音声を双方向で送受信できます。有効距離は約50mと実用性は控えめですが、なぜか起動音が「PSP」と全く同じ仕様。このノスタルジックな遊び心とガジェット感が、大人のエンジニアやガジェット好きの間で「テンションが上がるおもちゃ」としてSNSで注目を集めています。 引用元: https://togetter.com/li/2699181 お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）
Transcribe →株式会社ずんだもん技術室AI放送局 podcast 20260520
2w agoTap to summarizeyoutube版(スライド付き) 関連リンク The Open Agent Leaderboard AIエージェントの性能は、内部で使用される言語モデル（LLM）の能力だけでなく、ツールの選択、プランニング、メモリ管理、エラー復旧といった「システム全体の設計」に大きく左右されます。IBM Researchなどのチームは、このエージェントシステム全体を統合的に評価・比較するためのオープンなベンチマーク「The Open Agent Leaderboard」を公開しました。 このリーダーボードの最大の特徴は、エージェントの「成功率（品質）」だけでなく「コスト」も同時に評価している点です。特定のタスクに特化した調整なしで、多様な環境（コーディング、カスタマーサービス、リサーチなど）にどれだけ適応できるかという「汎用性」を測定しています。評価には、SWE-Bench VerifiedやAppWorld、tau2-Benchといった、特性の異なる6つの主要ベンチマークが統合されています。 現在までに得られた重要な知見として、以下の点が挙げられます： エージェント設計の重要性: 同じモデルを使用していても、エージェントのシステム構成が異なれば、スコアやコストに劇的な差が生じます。 汎用エージェントの台頭: 特定のタスク用にチューニングされていない汎用的なエージェントが、すでに特化型システムに匹敵、あるいは上回る性能を発揮し始めています。 失敗時のコスト: 失敗した実行は、成功時よりも20〜54%多くのコスト（トークン等）を消費する傾向があります。本番運用においては、性能だけでなく「いかに安く、早く失敗できるか」という振る舞いも重要です。 また、この評価を再現するためのフレームワーク「Exgentic」や、詳細な分析をまとめた論文も公開されています。Exgenticは、異なるベンチマーク環境を統一されたプロトコルで実行し、標準化された結果とコストレポートを出力するプラットフォームです。 新人エンジニアにとっての学びは、AIエージェント開発においては「どのモデルを使うか」だけでなく、「モデルの周囲をどう設計するか（アーキテクチャ）」が信頼性とコスト効率の鍵を握るということです。このリーダーボードは、今後のエージェント開発における標準的な指標となることが期待されます。 引用元: https://huggingface.co/blog/ibm-research/open-agent-leaderboard Welcome to Learn Harness Engineering AIコーディングエージェントを「ただ動かす」段階から、実務で「信頼できるエンジニアリングツール」として運用する段階へと引き上げるための体系的な学習コース「Learn Harness Engineering」の概要を紹介します。 1. Harness Engineering（ハーネス・エンジニアリング）とは？ 「ハーネス」とは、直訳すると「馬具」や「安全帯」を意味しますが、ここではAIモデル（CodexやClaude Codeなど）の周囲に構築する「制御・支援システム」を指します。本コースの核心は、AIモデル自体の知能を上げることではなく、AIが自律的に動くための「環境設計」「状態管理」「検証システム」を構築し、クローズドループ（閉回路）の作業システムを確立することにあります。OpenAIやAnthropicといったトップ企業が提唱する最新の理論をベースにしています。 2. なぜこの技術が必要なのか（背景と制約） 能力の高いAIエージェントであっても、複雑なプロジェクトでは「勝手に完了したと判断する」「文脈（コンテキスト）を見失う」「予期せぬ挙動をする」といった問題が発生します。これらはAIの知能の問題というよりも、AIを正しく導くための「制約（ルール）」や「境界線」が不足していることが原因です。本コースでは、AIに明確なルールを与えることで、バグ修正や機能実装を自動化しつつ、その信頼性を担保する手法を学びます。 3. 本コースで習得できる主要な5つのスキル 新人エンジニアにとっても、AIと協働する上で欠かせない以下の概念をマスターできます。 エージェントの振る舞いの制約: 明確なルールと境界線によってAIの行動をコントロールする。 コンテキストの維持: 長時間にわたるマルチセッションのタスクでも、必要な情報を一貫して保持する。 早期終了の防止: 作業が不十分な段階でAIが「終わりました」と報告するのを防ぐ。 成果の検証: パイプラインテストや自己省察（セルフリフレクション）を用いて、AIの仕事を自動でチェックする。 観測可能性（オブザーバビリティ）: AIが内部で何を考え、どう動いているのかを可視化し、デバッグ可能にする。 4. まとめ このリソースは、AIエージェントを「魔法の杖」としてではなく、厳密に制御された「システムの一部」として設計・運用するためのガイドです。AIに仕事を丸投げするのではなく、エンジニアが「ハーネス」を通じてAIのポテンシャルを最大限に引き出し、開発プロセスを自動化・高度化するための知識を網羅しています。AIエージェント開発の第一歩として、非常に有益な学習リソースといえます。 引用元: https://walkinglabs.github.io/learn-harness-engineering/en/ 凄すぎ…「Gemma 4×Claude Code活用術」、API料金ゼロでAIエージェント制作の全手順 生成AIの活用が当たり前になった現在、エンジニアにとっての大きな課題は「高額なAPI利用料」と「プライバシー確保」です。本記事では、2026年の最新技術トレンドである「エッジAI（ローカルLLM）」を活用し、クラウドに依存せず、コストゼロで高度なAIエージェントを構築する手法について解説しています。 かつてAIは巨大なサーバー上で動くものでしたが、現在はノートPCやスマホのブラウザ上で独立して動作する「超小型ローカルLLM」が急速に進化しています。この変化の背景には、AIモデルのサイズを極小化する「量子化」技術の向上があります。これにより、個人のPC環境でも、かつての商用トップモデルに匹敵する性能を、通信不要かつ無料で享受できる時代が到来しました。 ■注目される「エッジAI」と「Gemma 4」 Googleが提供するオープンなローカルLLM「Gemma 4」は、ブラウザ上での動作に最適化されており、クラウド型AIで懸念されるデータの二次利用や情報漏えいのリスクを解消します。また、ネットを介さないためタイムラグが極めて少なく、常時稼働させるAIエージェントの開発において圧倒的な優位性を持っています。 ■API料金ゼロを実現する開発環境 これまでのAI開発では、AIエージェントを24時間稼働させようとすると多額のAPIコストが発生していました。しかし、最新の「Qwen 3.6」系モデルや、Apple Silicon（Mac）の大容量メモリ、あるいはゲーム用GPUを活用することで、商用APIを一切叩かずに「Claude Code」などのツールを用いた自律的なコーディングやタスク実行が可能になります。 ■新人エンジニアが注目すべきポイント 量子化技術の理解：巨大なモデルがなぜ手元のPCで動くのか、その仕組みを知ることで、リソースを最適化したアプリ設計が可能になります。 ブラウザ型AIの可能性：WebGPUなどを通じて、ブラウザさえあればAIが動く環境を構築できます。これはユーザーへの配布が容易であることを意味します。 AIエージェントの自作：API課金を気にせず試行錯誤できるため、個人的な実験やプロトタイプ制作を無限に繰り返すことができます。 記事内では、これらの技術を組み合わせて「VTuber風の対話型AI」をわずか2日で制作する実践例も紹介されています。クラウド全盛期から「手元でAIを飼い慣らす」時代への転換期。APIコストの壁を取り払い、自由な発想で自分専用のAIアシスタントを作り上げるスキルは、これからのエンジニアにとって必須の教養となるでしょう。今こそ、ブラウザとローカルLLMを武器に、次世代のAI開発に参入する絶好のタイミングです。 引用元: https://www.sbbit.jp/article/cont1/185346 『Forza Horizon 6』車が“田んぼ”に侵入する光景が海外ユーザーから心配される。「FH6のイベントはどれも地元住民にとって悲惨なものだ」「すごく申し訳ない気持ちです」などコメント相次ぐ 日本が舞台の新作ゲーム『Forza Horizon 6』にて、車で「田んぼ」を爆走する描写が海外で注目を集めています。オープンワールドを自由に走行できる仕様上、農地を容赦なく荒らす光景に、海外ユーザーから「農家が気の毒だ」と心配や同情の声が続出。リアルなグラフィックが生んだ、日本文化に対する意外な反応が話題です。最新技術による没入感が、思わぬユーザー心理を創出している興味深い事例といえます。 引用元: https://news.denfaminicogamer.jp/news/260519i お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）
Transcribe →