
Hosted by 株式会社ずんだもん技術室AI放送局 · JA

youtube版(スライド付き) 関連リンク Introducing Gemma 4 12B: a unified, encoder-free multimodal model Google DeepMindは、一般的なノートPCなどのローカル環境で軽快に動作する、高性能なマルチモーダルAIモデル「Gemma 4 12B」を発表しました。本モデルは、モバイル向けモデルの「E4B」と、より高度な「26B MoEモデル」のギャップを埋める位置づけとして開発され、メモリ消費を抑えながらも強力な推論能力を備えているのが特徴です。 新人エンジニアの方に向けて、このモデルの革新的なポイントを4つに分けて解説します。 1. 「エンコーダフリー」という新しいアプローチ 従来の画像や音声に対応するAI(マルチモーダルモデル)は、画像用や音声用の独立した「エンコーダ(前処理用AI)」を使ってデータを変換し、メインの言語モデル(LLM)に渡していました。 しかし、Gemma 4 12Bではこのエンコーダを排除した革新的なアーキテクチャを採用しています。 画像(ビジョン)処理: 軽量な埋め込みモジュールのみを使用し、処理の大部分をLLM本体が直接行います。 音声オーディオ処理: エンコーダを完全に無くし、生の音声信号を直接テキストトークンと同じ空間にマッピングして処理します。 このシンプルな構造(Unified Architecture)により、処理の遅延(レイテンシ)とメモリの使用量を劇的に削減することに成功しました。 2. ノートPC(ローカル環境)で動く軽さ モデルのサイズが12B(120億パラメータ)とコンパクトに抑えられているため、16GBのVRAM(ビデオメモリ)やユニファイドメモリを搭載した一般的なPCがあれば、完全にオフラインのローカル環境で動作させることができます。これにより、クラウドのAPIコストを気にせず、手元で手軽にマルチモーダルAIを動かすことができます。 3. 大型モデルに迫る高度な推論力 メモリ消費量は半分以下であるにもかかわらず、ベンチマーク性能は上位モデルである「26B MoE」に迫る実力を持っています。これにより、複雑な「複数ステップの推論」や、自律的に動く「AIエージェント」のワークフローをローカルで実現可能です。また、Multi-Token Prediction(MTP)技術を搭載しており、推論速度も高速化されています。 4. オープンで充実した開発エコシステム ライセンスは「Apache 2.0」で提供され、自由な開発や商用利用が可能です。Hugging Face、Ollama、LM Studio、llama.cppなど、開発者が普段使っている主要なローカル推論ツールやライブラリに最初から対応しています。さらに、AIエージェント構築を支援する公式のスキルライブラリ「Gemma Skills」も同時に公開されています。 Gemma 4 12Bは、特別なGPUサーバーを用意せずとも、手元のPCだけで最先端の「画像・音声・テキスト」を融合したプロダクト開発を始められる、エンジニアにとって非常に魅力的な選択肢です。 引用元: https://blog.google/innovation-and-ai/technology/developers-tools/introducing-gemma-4-12b/ Introducing new capabilities to GPT-Rosalind OpenAIは、ライフサイエンス(生命科学)研究およびエンタープライズ規模の創薬に特化したAIモデル「GPT-Rosalind」のアップデートと新機能を発表しました。本モデルは、GPT-5.5が持つ高度なエージェント機能(自律的なコーディングやツール利用)に、医学化学やゲノミクスといった専門領域の強力な知識を融合させたものです。 本アップデートの主な要点と、技術的な特徴は以下の通りです。 1. 専門ベンチマークにおける高い性能と優れたトークン効率 ライフサイエンス研究の現場に即した複数のベンチマークにおいて、従来のGPT-5.5を上回る精度を達成しつつ、消費するトークン数を大幅に削減(コストパフォーマンスが向上)しています。 LifeSciBench: 科学的根拠の処理、分析、設計、推論など、実際の研究に必要なエンドツーエンドのタスクを評価する新ベンチマーク。本モデルは業界トップクラスの成績を記録。 MedChemBench (医学化学): 創薬プロセスの最適化などを評価。GPT-5.5に比べトークン消費量を7.2%削減しつつ、精度を向上(27.5% vs 25.1%)。 GeneBench (ゲノミクス・定量生物学): 長期的な計画と分析が必要なエージェントタスクを評価。GPT-5.5比でトークン数を31%削減し、21.6%の精度を達成。 LabWorkBench (実験支援): 実際のウェットラボ(実験室)プロトコルにおけるトラブルシューティング能力を測定。トークン数を5.3%削減し、精度は63.2%に向上。 2. ワークフローを実効化するプラグインと可視化ツール 推論を行うだけでなく、開発者や研究者が実際に手を動かして検証できる「実行環境」が強化されました。 2つの新プラグイン: 「Life Sciences Research」および「Life Sciences NGS Analysis(次世代シーケンシング分析)」をCodex(コーディング環境)経由で提供。 データ可視化ビューア: 配列、アライメント、分子構造など、生物学特有のネイティブファイル形式を直接確認・操作できるインタラクティブなビューアをCodex内に実装。 ユースケース: がんの液体生検データから変異を特定し、関連文献の探索や阻害剤の立体構造の確認までを、同一のワークスペース上でシームレスに実行できます。 3. 安全性を重視した展開 高度な生物学的機能の悪用を防ぐため、十分なガバナンスと安全管理体制を持つグローバルな「信頼された組織(例:製薬大手のノボ ノルディスクなど)」を対象に、リサーチプレビューとして限定的にアクセスが提供されます。 本モデルは、AIが単なる知識の要約にとどまらず、専門的なデータ分析や複雑な実験計画を自律的に支援する「実用的な開発・研究パートナー」へと進化していることを示しています。 引用元: https://openai.com/index/introducing-new-capabilities-to-gpt-rosalind Introducing MAI-Thinking-1 Microsoft AI Microsoft AIは、高度な推論能力を持つ新しいAIモデル「MAI-Thinking-1」を発表しました。このモデルは、人間を置き換えるのではなく、人間の自律性を支援する「Humanist Superintelligence(人間中心の超知能)」の実現に向けた重要な一歩として開発されました。 1. モデルの概要と特徴 MAI-Thinking-1は、アクティブパラメータ数35B(350億)、総パラメータ数約1T(1兆)の「スパースMoE(Mixture of Experts:必要な部分だけを活性化させる高効率な仕組み)」を採用した中規模モデルです。他社のAIモデルの出力結果を真似て学習させる「蒸留」を一切行わず、クリーンかつ商業利用可能なライセンス済みデータのみを用いて、ゼロからトレーニングされました。これにより、高い制御性と信頼性を確保しています。 2. 開発を支える「Hill-Climbing Machine」 Microsoftは、モデルを継続的かつ安定的に進化させる開発パイプライン「Hill-Climbing Machine」を導入しました。以下の3つの柱を重視しています。 自立した学習: 模倣(蒸留)による学習は、教師モデルの限界や設計の偏りを受け継いでしまいます。自ら課題を解くことで、真の適応力を養っています。 クリーンなデータ: プレトレーニングからAI生成コンテンツを排除し、データの出所を明確にすることで、モデルの挙動を正確に把握・改善できるようにしています。 自社インフラの最適化: 自社製のアクセラレータから強化学習フレームワークに至るまで、全レイヤーを社内で最適化し、効率的な訓練を可能にしています。 3. エンジニアを強力に支援する高い性能 中規模ながら、以下のような極めて高いパフォーマンスを発揮します。 優れたコーディング支援: ソフトウェア開発のベンチマーク(SWE-Bench Pro)において、より巨大なモデルである「Claude Opus 4.6」と同等の実力を示しました。開発者が実際に行う「コードの読み込み、ファイルの編集、テストの実行、エラーからの復旧」といったマルチステップの作業をエミュレートした環境で訓練されています。 高い数学的・科学的推論力: 数学オリンピックレベルの難問を扱う「AIME」ベンチマークにおいて極めて優秀な成績を収め、推論ループによる知能の一般化が証明されています。 優れたユーザー評価: 人間によるブラインド評価において、「Claude Sonnet 4.6」よりも好ましい回答を出力すると評価されました。 4. 実務への導入しやすさ(エンタープライズ対応) 256kトークン(約600ページの文書に相当)の長い文脈を理解でき、関数呼び出し(Function Calling)や開発者命令にも柔軟に対応します。また、一般的なChat Completions APIと互換性があるため、既存システムへの組み込みも容易です。 安全性を考慮するあまり必要な要求まで拒否してしまう「過剰な拒絶」を防ぐため、利便性と安全性のバランスを強化学習の段階から最適化しています。現在は「Microsoft Foundry」でプライベートプレビューとして提供されています。 引用元: https://microsoft.ai/news/introducing-mai-thinking-1/ 台風で休校になった息子が即座にSwitch2の電源を入れたので諫めたら、「違う」と画面を見せてきた→子どもの間での意外な活用術に、3DS世代が涙 スマホを持たない子どもたちが、Nintendo Switchのアカウント名を変更して「休校やったー」「2時公園」などと記述し、フレンド間で連絡を取り合っている微笑ましいハック。この「限られた機能(制約)を工夫して通信手段に落とし込む」手法は、かつて3DSのコメント欄等で行われていた文化の再来であり、制約の中で新しい価値を生み出す子どもたちの逞しい知恵に、多くの元ゲームキッズが感動しています。 引用元: https://togetter.com/li/2704944 お便り投稿フォーム (株式会社ずんだもんは架空の登場組織です)

youtube版(スライド付き) 関連リンク Rethinking Search as Code Generation ■ 背景と課題:なぜ今、検索の仕組みを見直すのか? 従来のAI向け検索システム(RAGなど)は、AIがクエリを送信し、検索エンジンが処理した固定の結果をAIがコンテキストとして受け取る「一括処理(モノリシック)」な仕組みでした。しかし、AIエージェントが複雑なタスクを自律的にこなす現代において、この方法には限界があります。不要な情報がコンテキストを圧迫してコストが膨らむ、柔軟な検索条件の変更が難しい、何度もやり取りが発生して処理が遅くなる、といった課題が生じていました。 ■ 解決策:「Search as Code (SaC)」の提案 Perplexityが開発した「Search as Code (SaC)」は、検索プロセスそのものをコードで制御する新しいアーキテクチャです。検索エンジンの各機能(情報の取得、順位付け、フィルタリング、並列処理など)を、細分化された「SDK(ソフトウェア開発キット)」の部品としてAIに提供します。AIは、提示されたタスクに合わせて自らPythonコードを生成・実行し、その場で最適な「特製検索パイプライン」を動的に組み立てます。 ■ SaCを支える3つのコアレイヤー モデル(Models):タスクを分解し、SDKを用いて最適な検索手順を実行するPythonコードを生成する司令塔です。 サンドボックス(Sandboxes):生成されたコードを安全かつ確実に実行する環境です。処理中の状態(中間データ)をファイル保存することで、長時間のタスクでも破綻せずに次の処理へ引き継げます。 Agentic Search SDK:検索プロセスをアトミック(最小単位)に制御できるPythonの部品集です。AIモデルが最もコードを書きやすい形になるよう、自動で継続的に最適化されています。 ■ 圧倒的な実績と効果 実際のセキュリティ情報(CVE)の調査タスクにおいて、SaCは精度100%を達成しながら、消費トークン数を従来比で85.1%も削減することに成功しました。また、難関ベンチマーク(WANDR等)において他社の最先端AIシステムを最大2.5倍上回るスコアを記録し、高いコストパフォーマンスを実証しています。 ■ まとめ SaCは、「検索APIをただ呼び出すだけ」の時代から、「検索自体をプログラムとして制御する」時代へのシフトを意味します。AIの柔軟な推論力と、決定論的なコード実行の強みを融合させたこの仕組みは、これからのAIシステム開発における重要な設計パラダイムとなるでしょう。 引用元: https://research.perplexity.ai/articles/rethinking-search-as-code-generation Expanding Project Glasswing 本記事は、AIスタートアップのAnthropic社が推進する、AIを活用したソフトウェアセキュリティ強化プロジェクト「Project Glasswing」の拡大について解説したものです。これからの開発現場やセキュリティ対策のあり方を大きく変える、エンジニア必読のトレンドとなっています。 1. 「Project Glasswing」の概要と実績 Project Glasswingは、世界中の重要なソフトウェアの安全性を確保するための共同取り組みです。初期フェーズでは、約50のパートナー組織がサイバーセキュリティに特化したモデル「Claude Mythos Preview」を利用し、自社のコードベースをスキャンしました。その結果、すでに1万件以上の「深刻(High)」または「致命的(Critical)」なセキュリティ脆弱性が発見されるという大きな成果を上げています。 2. パートナーシップの大幅な拡大 Anthropic社は、この取り組みをさらに約150の新たな組織へと拡大します。対象は15カ国以上に及び、電力、水道、医療、通信、ハードウェアといった社会の重要インフラを担う企業や、世界中の開発者が依存するオープンソースソフトウェア(OSS)のメンテナー(管理者)が含まれます。これらの組織のコードベースが攻撃された場合、1億人以上に影響が及ぶ可能性があるため、事前の防御策が急務となっています。 3. 防御側(エンジニア)の変革と支援策 強力なサイバー能力を持つAIが身近になる未来を見据え、防御側もAIを活用して対策を加速させる必要があります。Anthropic社は単に脆弱性を探すだけでなく、以下の支援を展開しています。 実用ツールの提供: 最新モデル(Claude Opus 4.8など)を用いてコードをスキャンし、修正パッチを提案する製品「Claude Security」をリリースしました。 パッチ適用の高速化: 「Claude Mythos Preview」自体を活用し、脆弱性の発見から修正パッチの自動生成、さらにはメモリ安全な言語へのコード書き換えやリリース前チェックなどを進めています。 4. 今後の展望 最終的なゴールは、AIの力で「すべてのソフトウェアをより安全にすること」です。Anthropic社は、悪用を防ぐ強固なセーフガードを開発した上で、この強力なセキュリティ機能を一般公開することを目指しています。今後もパートナーを増やし、AI時代において「防御側が常に有利に立てる世界」の構築を目指します。 引用元: https://www.anthropic.com/news/expanding-project-glasswing Holo3.1: Fast & Local Computer Use Agents 「Holo3.1」は、PCやスマートフォンなどの画面を認識して人間のように操作(Computer Use)できる、最先端のAIエージェントモデルの最新ファミリーです。前バージョン「Holo3」の成功を受け、本バージョンでは「実運用(プロダクション)」を見据え、対応環境の拡大、他システムとの連携力、そしてローカルデバイスでの実行性能が大幅に強化されました。 新人エンジニアの方向けに、Holo3.1の主な進化ポイントを分かりやすく4つに分けて解説します。 1. モバイルを含むあらゆる環境への適応(マルチ環境対応) 従来のWebブラウザやデスクトップ操作に加え、Androidなどのモバイル環境の自動化が大幅に強化されました。モバイル環境の評価指標である「AndroidWorld」において、最大モデル(35B-A3B)のタスク成功率が67%から79.3%へと大きく向上し、より実用的なモバイル操作が可能になりました。 2. 他システムとのスムーズな連携(関数呼び出しのサポート) 開発者が既存のエージェントフレームワークにHoloを組み込みやすくするため、従来のJSON形式での出力に加え、新しく「Function-calling(関数呼び出し)」プロトコルにネイティブ対応しました。これにより、外部ツールやAPIの呼び出しを伴う高度な自動化システムとの連携が非常にスムーズになります。 3. ローカル環境で「高速・プライベート」に動く量子化対応 本バージョン最大の目玉は、モデルのデータサイズを削減する「量子化」に本格対応した点です。「FP8」「Q4 GGUF」「NVFP4」という軽量化されたモデルが提供されています。 特にNVIDIAの技術を活用した「NVFP4」形式では、AIの賢さ(精度)をほぼ落とすことなく、標準的なBF16形式と比べて最大1.74倍の処理高速化(スループット向上)を達成しています。これにより、一般的なWindowsやMac(Apple Silicon)などのローカルPC、あるいは社内の安全なネットワーク環境だけで、データを外部に送信することなく安全かつ高速にAIエージェントを動かせます。 4. 開発要件に合わせて選べる4つのモデルサイズ 超軽量な「0.8B(極小サイズ)」から、コスト効率に優れた「4B」、速度と性能のバランスが良い「9B」、そして最も賢い「35B-A3B」まで、用途やマシンスペックに合わせて柔軟に使い分けられるラインナップが揃っています。 Holo3.1の登場により、セキュリティの観点からクラウドAIを使えなかった業務でも、ローカルPC上で安全かつ実用的な速度で動作する「自動化AIアシスタント」の開発が一気に現実的になりました。 引用元: https://huggingface.co/blog/Hcompany/holo31 ポルトガルの学会で、参加者に「普段何やってるの?」と訊かれたので「I play YU-GI-OH」と返したら、その後「何だこの学会は」と言いたくなる流れになった話 ポルトガルの学会に参加した投稿者が、周囲から「普段何をやっているのか」と尋ねられ「遊戯王をやっている」と答えたところ、現地のアカデミアたちから「バクラ」や「ネクロバレー」といったディープな遊戯王用語が次々と飛び出し、一気に盛り上がったというユーモラスな体験談です。海外の研究者の間でも日本のホビー文化が深く浸透しており、意外な共通の趣味が国境を越えて親睦を深める強力なツールになることを示しています。 引用元: https://togetter.com/li/2704474 お便り投稿フォーム (株式会社ずんだもんは架空の登場組織です)

youtube版(スライド付き) 関連リンク 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 お便り投稿フォーム (株式会社ずんだもんは架空の登場組織です)
youtube版(スライド付き) 関連リンク 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:春日部つむぎ

youtube版(スライド付き) 関連リンク 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:ずんだもん

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 お便り投稿フォーム (株式会社ずんだもんは架空の登場組織です)

youtube版(スライド付き) 関連リンク 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 お便り投稿フォーム (株式会社ずんだもんは架空の登場組織です)

youtube版(スライド付き) 関連リンク 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 お便り投稿フォーム (株式会社ずんだもんは架空の登場組織です)
関連リンク エージェント向けの 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:春日部つむぎ

youtube版(スライド付き) 関連リンク 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:ずんだもん