株式会社ずんだもん技術室AI放送局

株式会社ずんだもん技術室AI放送局

AIやテクノロジーのトレンドを届けるPodcast。平日毎朝6時配信。朝の通勤時間や支度中に情報キャッチアップとして聞いてほしいのだ。(MC 月:春日部つむぎ、火水木:ずんだもん、金:お嬢様ずんだもん)

  1. 12時間前

    株式会社ずんだもん技術室AI放送局 podcast 20251008

    youtube版(スライド付き) 関連リンク Google DeepMind introduces new AI agent for code security Google DeepMindは、ソフトウェアのセキュリティを自動で強化する新しいAIエージェント「CodeMender」を発表しました。この画期的なツールは、AIの力でコードの脆弱性を発見し、修正することを目指しています。 現在のソフトウェア開発では、セキュリティの脆弱性を見つけて修正する作業が非常に難しく、多くの時間と労力を必要とします。従来の自動チェックツール（「ファジング」と呼ばれる多様な入力を与えてバグを探す手法など）にも限界があり、AIによる高度な脆弱性発見技術が進化するにつれて、人間だけで全ての脆弱性に対応するのは非現実的になってきています。CodeMenderは、このセキュリティ上の大きな課題を解決するために開発されました。 CodeMenderは、大きく分けて2つのアプローチでコードセキュリティを強化します。 リアクティブ（即時修正）: 新しく見つかった脆弱性を素早く自動で修正します。 プロアクティブ（根本的改善）: 既存のコードをより安全な形に書き換え、将来の脆弱性の発生を防ぎます。例えば、特定の種類の脆弱性を根本からなくすような大規模なコード改修も行います。 このAIエージェントは、Googleの最先端AIモデルである「Gemini Deep Think」をベースにしています。そのため、人間のようにコードについて深く考え、複雑な問題を解決する能力を持っています。 CodeMenderは、以下のような強力なツールや技術を組み合わせてコードの分析と修正を行います。 高度なプログラム分析: 「静的解析」（コードを動かさずに文法や構造を調べる）、「動的解析」（コードを実際に動かして振る舞いを調べる）、「差分テスト」、「ファジング」、そして「SMTソルバー」（論理的な問題を解く技術）などを駆使し、脆弱性の根本原因や設計上の弱点を特定します。 マルチエージェントシステム: 特定の課題に特化した複数のAIエージェントを連携させることで、複雑な問題にも効率的に対応します。例えば、コードを修正した後、元の機能が損なわれていないか（「デグレード」していないか）を自動で検証するエージェントも存在します。 CodeMenderが生成したコードの変更は、自動で徹底的に検証されます。これにより、「問題の根本原因が本当に解決されているか」「機能が壊れていないか」「コーディング規約に沿っているか」など、様々な観点から修正の品質が保証されます。人間が最終確認すべきは、この検証をクリアした「質の高いパッチ」のみとなるため、開発者の負担を大幅に軽減できます。 Google DeepMindは、これまでにCodeMenderを使ってオープンソースプロジェクトに72件ものセキュリティ修正を提供してきました。中には、450万行もの大規模なコードベースへの貢献も含まれています。例えば、画像圧縮ライブラリ「libwebp」で過去に発見され、iOSのゼロクリック攻撃にも悪用されたバッファオーバーフローの脆弱性（プログラムが確保したメモリ領域を越えてデータが書き込まれる問題）に対して、「-fbounds-safety」という安全なコードアノテーション（特定の情報や設定をコードに追加する印）を適用し、将来的な同種の脆弱性を防止する対策を行っています。 現在、CodeMenderが生成する全ての修正は、人間による最終レビューを経てから公開されています。これは、修正の品質を確実に保ち、オープンソースコミュニティからのフィードバックを慎重に受け止めるためです。Google DeepMindは、今後、重要なオープンソースプロジェクトの管理者と連携を深め、得られたフィードバックを基にCodeMenderを改善していく予定です。最終的には、このCodeMenderを全てのソフトウェア開発者が利用できるツールとしてリリースし、世界中のソフトウェアのセキュリティ向上に貢献することを目指しています。 引用元: https://deepmind.google/discover/blog/introducing-codemender-an-ai-agent-for-code-security/ What Makes 5% of AI Agents Actually Work in Production? AIエージェントを実際に製品として使えるようになるのは、実はたった5%くらいしかないって知っていましたか？この記事では、その成功するAIエージェントが何をしているのか、日本の新人エンジニアさんにもわかりやすく解説してくれています。 多くの人は、AIの賢さ（モデルの性能）が大事だと思いがちですが、失敗のほとんどは、そのAIを支える「周辺システム」（コンテキスト設計、セキュリティ、メモリ管理など）がうまくできていないのが原因だそうです。 「文脈（コンテキスト）」の重要性 AIエージェントにとって、「モデルは土壌、コンテキストは種」という言葉があります。つまり、どんなに高性能なモデル（土壌）があっても、適切な「文脈情報（コンテキスト、種）」を与えなければ、良い結果は生まれないということです。 最近よく聞くRAG（Retrieval-Augmented Generation）という技術が重要ですが、ただ情報を集めるだけではダメ。必要な情報だけを厳選し、正しく整理し、検証する「高度なコンテキストエンジニアリング」が求められます。例えば、関連性の高い情報だけを選んだり（選択的コンテキストプルーニング）、データの種類や鮮度をチェックしたり、どの情報がAIの回答に影響したかを追跡できるようにしたりします。 セキュリティと信頼性の確保 本番環境でAIを使う上で、特にエンタープライズ（企業）環境では、セキュリティやアクセス権限の管理が非常に重要です。誰がどんな情報にアクセスできるか、AIの出力がどの情報源に基づいているかを追跡できる「リネージ」の確保が必須です。また、同じ質問をしても、社員の役職や権限によってAIの回答が変わるようにする仕組みも必要になります。 そして何よりも「信頼」が重要です。AIがアシスタントとして人間をサポートし、人間が最終的な判断を下す「Human-in-the-loop（人間が介入する）」設計が、ユーザーからの信頼を得る上で欠かせません。 メモリ管理と複数モデルの使い分け AIエージェントは、過去のやり取りやユーザーの好みを覚える「メモリ」を持つことで、より賢くパーソナルな体験を提供できます。しかし、そのメモリをどう管理するか（ユーザーごとに、チームごとに、組織ごとに）、またプライバシーをどう守るかは難しい課題です。 また、すべてのタスクに同じ高性能なAIモデルを使うのは効率的ではありません。簡単な質問には高速で安価なモデルを、複雑な分析には高性能なモデルを使うなど、タスクに応じて複数のモデルを賢く使い分ける「モデルオーケストレーション」の技術も進化しています。 自然言語とGUIの適切な使い分け AIエージェントと対話する際に、何でもかんでもチャット形式が良いわけではありません。例えば、BIツールのような複雑なデータ分析では、自然言語で質問するときの学習コストを減らせます。しかし、一度答えが出たら、チャートの種類を変えるなどの微調整はGUI（グラフィカルユーザーインターフェース）で行いたいものです。ユーザーのニーズに合わせて、自然言語とGUIを組み合わせた設計が重要になります。 これからのエンジニアに求められること これからのAI開発では、単にモデルの性能を追求するだけでなく、「質の高いコンテキスト」「適切なメモリ設計」「信頼性の高いオーケストレーション」「ユーザーが信頼できるUX」といった周辺要素が、AIエージェントの成功を左右する重要なポイントになります。 新人エンジニアの皆さんも、ぜひこれらの要素を意識して、これからのAI開発に取り組んでみてください。 引用元: https://www.motivenotes.ai/p/what-makes-5-of-ai-agents-actually Not Another Workflow Builder LangChainチームは、これまでビジュアルワークフロービルダーの開発に積極的ではありませんでした。最近OpenAIが同様のツールを発表したことを受け、LangChainがなぜこの道を選ばなかったのか、そして今後何に注力していくのかを解説しています。 ノーコードのワークフロービルダーは、主に非技術者がAIエージェントを構築できるようにすることを目的としています。これは、技術者不足の解消や、非技術者が持つ具体的な業務知識をAIシステム開発に活かすためです。 ここで重要なのは「ワークフロー」と「エージェント」の違いです。AIエージ

  2. 1日前

    株式会社ずんだもん技術室AI放送局 podcast 20251007

    youtube版(スライド付き) 関連リンク Introducing AgentKit OpenAIが、AIエージェント（特定のタスクを自律的に実行するAI）の開発をもっと簡単で効率的にするための新しいツールキット「AgentKit」を発表しました。これまでは、AIエージェントを作るには、たくさんの異なるツールを組み合わせて使ったり、エージェントの性能評価を手動で行ったりと、開発者に大きな負担がかかっていました。AgentKitは、こうした課題を解決し、エージェントの設計からデプロイ、性能改善までを一貫してサポートする、まさに「エージェント開発のためのオールインワンツール」です。 AgentKitの主な機能は以下の3つです。 Agent Builder (エージェントビルダー): これは、複数のAIエージェントが連携して動く「ワークフロー」（処理の流れ）を、まるでフローチャートを描くように視覚的に作れるツールです。ドラッグ＆ドロップでノード（処理の塊）を繋ぎ、エージェントの動きを直感的に設計できます。複雑なエージェントの処理も一目でわかるようになるため、開発チームやビジネス側の関係者みんなで理解しやすくなります。テスト実行やバージョン管理もできるので、試行錯誤しながら素早く改善を進められます。実際に日本の「LY Corporation」でも、わずか2時間足らずでワークアシスタントエージェントを構築できたと紹介されています。 Connector Registry (コネクターレジストリ): エージェントが外部のデータソース（Dropbox、Google Drive、Sharepointなど）や、他のツールと連携するための接続設定を、一元的に管理できる場所です。企業内で多くのエージェントが様々なデータにアクセスする場合でも、管理者がすべての接続をまとめて把握・管理できるため、データ連携がよりスムーズかつ安全になります。 ChatKit (チャットキット): エージェントとユーザーが会話するための「チャットUI」（ユーザーインターフェース）を、あなたのアプリやウェブサイトに簡単に組み込めるツールです。チャット画面のデザインや、エージェントの応答をリアルタイムで表示するといった機能の実装は意外と手間がかかるものですが、ChatKitを使えば、手間をかけずに製品に馴染むチャット機能を素早く追加できます。 さらに、AgentKitには、開発したエージェントの性能を評価し、改善するための強力な機能も加わりました。例えば、「Evals」という評価ツールでは、データセットを使ってエージェントの動作を自動で評価したり、より良いプロンプト（AIへの指示文）を自動で生成したりできるようになります。これにより、エージェントの信頼性や性能を客観的に測り、継続的に向上させることが可能になります。 これらのツールは、AIエージェント開発における「複雑さ」や「手間」を大きく削減してくれるでしょう。新人エンジニアの皆さんも、AgentKitを活用することで、より効率的かつ確実に、革新的なAIアプリケーション開発に挑戦できるようになります。 引用元: https://openai.com/index/introducing-agentkit LLM用宣言的プログラミング言語 DSPy この記事では、LLM（大規模言語モデル）を使ったアプリケーション開発をもっと簡単で効率的にする新しい技術「DSPy」について、新人エンジニアの方にも分かりやすく解説しています。DSPyは「Declarative Self-improving Python」の略で、特に「宣言的（Declarative）」という特徴が大きなポイントです。 これまでのLLMアプリケーション開発では、OpenAIのAPIなどを直接使う場合、LLMに与える指示文（プロンプト）を細かく書いたり、状況に合わせて複数のプロンプトを使い分けたりする必要がありました。例えば、足し算のようなシンプルなタスクでも、プロンプトの作成や管理、エラー対応、複雑な処理の組み込みなど、開発者が一つ一つコードで記述する必要があり、これがかなりの手間でした。 DSPyのすごいところは、このプロンプト作成や管理の「手間」を劇的に減らせる点にあります。「宣言的」というのは、「どうやって動かすか」という具体的な手順ではなく、「何をしたいか」という目的だけを記述するアプローチのことです。たとえば、これまでは「〇〇たす△△というプロンプトをLLMに送り、その結果を受け取る」と書いていた部分を、DSPyでは「num1とnum2という入力から、その和（sum）を出力してほしい」と宣言するだけで、LLMへの具体的な指示文（プロンプト）はDSPyが自動的に生成・調整してくれます。 実際のコード例を見ると、OpenAIのAPIを直接使った場合に数行必要だった記述が、DSPyではdspy.Predict('num1, num2 -> sum')のようにたった1行で済みます。これにより、開発者はプロンプトの細かい文言に頭を悩ませることなく、LLMに解決させたいタスクの入力と出力の形だけを定義すればよくなります。また、dspy.Signatureを使って、和だけでなく差や文字列の連結など、複数の出力を同時に得るような複雑なタスクも、明確な形で定義できます。 さらに、DSPyには「CoT（Chain Of Thought）」という、LLMが段階的に思考して答えを導き出す機能も簡単に組み込めます。これは、複雑な問題に対してLLMが「なぜその結論に至ったか」という理由（reasoning）も含めて出力してくれるもので、高度な問題解決に役立ちます。DSPyではdspy.ChainOfThoughtを使うだけで、こうした多段階の推論も宣言的に記述できます。 このようにDSPyは、LLMアプリケーション開発において、開発者が「何をさせたいか」に集中できるよう、プロンプトの設計や調整といった手間のかかる作業を自動化してくれる画期的なツールです。今後は、LLMの振る舞いを評価し、プロンプトを自動で最適化する「プロンプトチューニング」の機能も活用され、LLM開発をさらにシンプルで強力なものに変えていくことが期待されています。 引用元: https://zenn.dev/cybernetics/articles/f879e10b53c2db AMD and OpenAI announce strategic partnership to deploy 6 gigawatts of AMD GPUs 皆さん、こんにちは！今回は、テクノロジー業界で非常に大きなニュースが飛び込んできたので、要点を分かりやすく解説します。半導体大手AMDと、チャットAI「ChatGPT」で有名なOpenAIが、今後数年間にわたる大規模な戦略的パートナーシップを発表しました。これは、AIの進化をさらに加速させるための重要な一歩となります。 ● 超大規模なAIインフラ計画 今回の発表の最大のポイントは、OpenAIが次世代のAIインフラのために、なんと「6ギガワット」ものAMD製GPU（グラフィック処理装置）を導入するという点です。ギガワットは電力の単位ですが、これはAIを動かすための計算能力が途方もなく大規模であることを示しています。私たちが普段使っているPCのGPUが数Wから数百W程度であることを考えると、その規模の巨大さが想像できるでしょう。 ● なぜGPUがAIに不可欠なのか？ AI、特に「生成AI」と呼ばれるChatGPTのような技術は、膨大なデータを高速に処理する計算能力が不可欠です。GPUは、この種類の計算を非常に得意としており、AIの「脳」とも言える役割を担っています。OpenAIは、AMDの高性能GPUを活用することで、よりパワフルで高度なAIモデルを開発し、私たちが利用できるAIサービスの可能性を広げようとしています。 ● 具体的な導入スケジュールと今後の展開 この計画は2026年後半から始まり、まずは1ギガワット分のAMD Instinct MI450シリーズGPUが導入されます。MI450シリーズは、AIや高性能計算に特化したAMDの最新GPUです。この提携は単に製品を供給するだけでなく、両社が技術的な専門知識を共有し、協力してAI向けハードウェアやソフトウェアの最適化を進める、まさに二人三脚の取り組みです。これまでもMI300XやMI350Xシリーズで協力してきましたが、今回の提携でその関係はさらに深まります。 ● 両社のWin-Winな関係 AMDにとっては、OpenAIという最先端のAI開発企業に大規模にGPUを供給することで、市場における存在感をさらに高めることができます。OpenAIにとっては、AI開発に必要な計算能力を安定して、かつ先進的な技術で確保できるという大きなメリットがあります。このパートナーシップは、単なるビジネス上の取引を超え、AI業界全体の成長と発展に貢献するものと期待されています。 AMDのCEOリサ・スー氏も、OpenAIのCEOサム・アルトマン氏も、この提携がAIの可能性を最大限に引き出し、その恩恵をより早く

  3. 2日前

    マジカルラブリー☆つむぎのピュアピュアA.I.放送局 podcast 20251006

    関連リンク Managing context on the Claude Developer Platform Anthropicは、AIエージェントが長期かつ複雑なタスクをより効率的に実行できるよう、「コンテキスト管理」の新機能をClaude Developer Platformに導入しました。これは、新人エンジニアの皆さんにとって、これからのAI開発を理解する上で非常に重要なアップデートです。 従来のAIエージェントは、一時記憶（コンテキストウィンドウ）の限界から、長時間のタスクで情報を見失ったり、性能が落ちたりする課題がありました。この根本的な問題を解決するため、主に二つの新機能が提供されます。 コンテキスト編集（Context editing）： トークン制限に近づくと、古いツール結果など不要な情報を自動でコンテキストから削除します。これにより、エージェントは必要な情報に集中し、より長くタスクを実行できるようになり、パフォーマンスも向上します。 メモリツール（Memory tool）： 重要な情報をコンテキスト外にファイルとして永続的に保存し、必要に応じて参照できる「長期記憶」機能です。セッションを跨いで知識を蓄積し、プロジェクトの状態維持が可能。データ保存は開発者が制御します。 これらの機能は、最新モデルClaude Sonnet 4.5と組み合わせることで、トークン使用状況を意識した効率的なコンテキスト管理が可能となり、エージェントの能力を最大限に引き出します。 この進化により、AIエージェントは大規模なコード処理、多数のドキュメント分析、長期データ処理など、これまで困難だった複雑なタスクを高精度でこなせるようになります。 実際の評価では、コンテキスト管理機能の併用により、エージェントのパフォーマンスが39%向上。トークン消費量を84%削減し、コンテキスト枯渇によるタスク失敗も劇的に減少したと報告されています。 これらの画期的な機能は現在、公開ベータ版としてClaude Developer Platformで利用可能です。ぜひ今後のAI開発に活用を検討してみてください。 引用元: https://www.anthropic.com/news/context-management 95%以上をLLMが実装。『みらいまる見え政治資金』を45日で完成させた、AIネイティブな開発手法についてご紹介 この記事では、チームみらいが開発した「みらいまる見え政治資金」プロジェクトにおいて、コードの95%以上をLLM（大規模言語モデル）に実装させ、約45日という短期間で中規模アプリケーションを完成させた、AIネイティブな開発手法が紹介されています。公開後約2日で20万PVを超える反響を呼びました。 この開発では、LLMの特性を最大限に活かすため、プロジェクト全体の設計が非常に重要視されました。具体的には、エンドユーザー向け画面、管理画面、共有オブジェクトの3パッケージに分けるモノレポ構成を採用。これにより、LLMが見通しを保ちやすく、必要に応じてパッケージ間参照も容易になるよう工夫しました。Next.js特有のクライアントサイドとサーバーサイドの混同を防ぐため、ディレクトリで明確に分け、「server-only」といったルールも適用。サーバー処理も厳格なレイヤー分けを行い、LLMは面倒がらないため、ルールに従って見通しの良い構造を維持しました。 実装段階では、主にClaude Codeを使い、プロジェクトの設計・実装ルールを「CLAUDE.md」にまとめ、LLMに厳守させました。複雑な機能は、まず設計ドキュメントを作成させてから実装を開始しました。さらに、Figmaのデータを直接読み取れるMCPを活用し、デザインの実装もLLMに任せました。指示を細かく分割することが成功の鍵です。 AIが書いたコードの品質を担保するためには、人間によるレビューが不可欠です。この記事では、個々のロジックよりレイヤー責務の確認を重視し、重要な処理にはユニットテストをLLMに書かせ効率的に品質を保証しました。Biomeを用いた自動フォーマットやCIでのチェックを導入し、開発を効率化しました。 最終的に、ほぼ全ての領域をLLMに任せることができ、「100%実装も可能」だと述べられています。LLMの「忍耐強さ」を活かし、厳密なルールを例外なく適用することが、開発スピード向上につながると結論付けています。ただし、この手法はフルスクラッチ、Next.js+TypeScript、中規模アプリといった特定の条件下で特に効果を発揮します。新人エンジニアにとって、AIと協働する未来の可能性を感じさせる貴重な事例です。 引用元: https://note.com/jujunjun110/n/na653d4120d7e J-RAGBench：日本企業でRAGするときの落とし穴とは 皆さん、こんにちは！今回は、RAG（Retrieval-Augmented Generation）という技術を日本企業で使う時にどんな問題が起こりやすいのか、そして最適なAIモデルを選ぶにはどうすればいいのかを明らかにする「J-RAGBench」という新しい評価ツールについて紹介します。 RAGは、検索した情報に基づいてAI（大規模言語モデル、LLM）が回答を作る技術です。最近は様々なAIモデルが登場していますが、実際のビジネス現場でRAGを使うには、単に情報を検索するだけでなく、複数の情報をまとめて理解したり、そこから推論したり、表形式のデータを正確に読んだり、さらには情報が見つからない時に「分かりません」と適切に断る能力など、非常に複雑な能力がAIに求められます。 しかし、これまでのAI評価ツール（ベンチマーク）では、これらの複雑な能力を十分に測ることができませんでした。そこで、株式会社neoAIの研究開発チームが、金融や製造業といった実際の業界でRAGを導入する中で直面した「落とし穴」を元に、新しい日本語RAGベンチマーク「J-RAGBench」を開発しました。 J-RAGBenchの主な特徴は以下の通りです。 評価観点の再定義：実際のビジネスシーンでAIに求められる能力を「情報統合」「推論」「論理条件の解釈」「表形式の解釈」「回答拒否」の5つのカテゴリに体系化しています。 複数の能力を同時に評価：現実の難しい問題では複数の能力が同時に必要になるため、高難易度な複合問題を多く含んでいます。 架空シナリオの採用：AIが元々持つ知識に頼らず、与えられた情報だけを正確に読み取る純粋な外部文書参照能力を評価するために、架空の状況を設定した問題を採用しています。 J-RAGBenchを使って、様々なAIモデル（API提供モデルやオープンウェイトモデル）を評価したところ、各モデルの得意・不得意が明確になりました。 GPT-5は、どのカテゴリにおいてもバランスよく高いスコアを示しました。 o3やo4 miniといったモデルは、情報からの推論は得意ですが、情報がないのにそれらしい嘘の情報を話してしまう「ハルシネーション（幻覚）」を起こしやすい傾向が見られました。 Claude Sonnet 4は、情報がないときに適切に「回答できません」と断る能力が非常に高く、ハルシネーションを起こしにくい「高信頼型」でしたが、他の能力はやや劣る結果でした。 また、詳細な分析では、AIが情報の粒度が不均一な場合に誤答したり、数値計算や複雑な表の解釈でミスしたり、根拠となる情報がないにも関わらずハルシネーションを起こしてしまうケースが確認されました。特に、小さなモデルほど、マルチホップ推論や回答拒否の能力が低い傾向にありました。 これらの結果は、RAGシステムを実際に運用する際に、どのような用途で利用するか（例えば、バランスの取れた回答を求めるか、信頼性を最優先するか、など）に応じて、適切なAIモデルを選ぶことの重要性を示しています。J-RAGBenchは、RAGのAIモデル選定において、新人エンジニアの皆さんにとって貴重な判断材料となるでしょう。 引用元: https://zenn.dev/neoai/articles/0998f81c39a583 ガストで昼間からビール飲んでるおじさんが配膳ロボットにお触りしてて、ロボットの方も「くすぐったいにゃん」とか言ってた… 何なんだこの空間は ガストの猫型配膳ロボット「BellaBot Pro」が、お客さんに触られると「くすぐったいにゃん」と可愛く反応する様子が話題になっています。昼間からビールを楽しむお客さんがロボットと触れ合う光景は、AIやロボット技術が私たちの日常に自然に溶け込み、予想外の面白いコミュニケーションを生み出していることを示しています。新人エンジニアの皆さんも、こんなクスッと笑える瞬間から、人とテクノロジーの新しい関わり方に注目してみませんか。 引用元: https://togetter.com/li/2611523 お便り

  4. 私立ずんだもん女学園放送部 podcast 20251003

    5日前

    私立ずんだもん女学園放送部 podcast 20251003

    youtube版(スライド付き) 関連リンク Practical LLM Security Advice from the NVIDIA AI Red Team NVIDIAのAIレッドチームが、LLM（大規模言語モデル）アプリケーション開発で直面する主要なセキュリティリスクと、その対策について実践的なアドバイスを公開しました。新人エンジニアの皆さんが、安全なLLMシステムを構築するために知っておくべき3つの重要なポイントを分かりやすく解説します。 1. LLM生成コードの実行によるリモートコード実行（RCE） LLMが生成したコードを、隔離なしに実行することは非常に危険です。execやevalのような関数を使うと、悪意あるプロンプト（指示）で不正なコードが生成・実行され、「リモートコード実行（RCE）」につながり、アプリケーション全体の乗っ取りリスクが生じます。 対策: LLM生成コードの直接実行は避けましょう。動的なコード実行が必要な場合は、WebAssemblyのような厳重に隔離された「サンドボックス」環境で実行が必須です。理想的には、LLMの応答から意図を解析し、許可された安全な機能のみを呼び出す仕組みを構築します。 2. RAGデータソースのアクセス制御の不備 RAG（Retrieval-Augmented Generation）はLLMに外部情報を提供しますが、ここにもリスクがあります。 データ漏洩: ユーザーごとのアクセス権限が不適切だと、機密情報が誤って他のユーザーに見えてしまう可能性があります。 間接的プロンプトインジェクション: RAGデータストアへの書き込み権限が広すぎると、悪意あるデータが注入され、LLMの応答が操作される危険性があります。 対策: 元データのアクセス権限をRAGシステムにも正確に反映し、厳しく管理してください。データストアへの書き込みアクセスは限定し、信頼できるデータのみが追加されるようにしましょう。出力される情報が質問の意図に合っているか「ガードレール」でチェックすることも有効です。 3. LLM出力によるアクティブコンテンツのレンダリング LLMの出力にMarkdownやHTMLのようなアクティブコンテンツ（リンクや画像など）が含まれる場合、ユーザーが気づかないうちにブラウザを通じて機密データが攻撃者のサーバーへ送信される可能性があります。これは「データ流出」につながる重大な問題です。 対策: 画像の読み込み元を、許可された「安全なサイト」に限定する「コンテンツセキュリティポリシー（CSP）」を設定します。 リンクは、クリック前にユーザーがURL全体を確認できるようにするか、手動でコピー＆ペーストが必要な「非アクティブ」な形式にします。 LLMの出力に含まれるアクティブコンテンツは、表示する前に必ず「サニタイズ（無害化）」し、悪意ある記述を取り除くことが極めて重要です。 これらのセキュリティ対策を開発の早い段階から取り入れることで、皆さんのLLMアプリケーションはより安全で信頼性の高いものになります。ぜひ、日々の開発に活かしてください。 引用元: https://developer.nvidia.com/blog/practical-llm-security-advice-from-the-nvidia-ai-red-team/ RubyLLM が Ruby に洗練された AI 統合をもたらし、開発者エクスペリエンスの議論を巻き起こす 新人エンジニアの皆さん、こんにちは！今回は、Rubyというプログラミング言語でAI（人工知能）を扱うための新しいライブラリ「RubyLLM」について、わかりやすく解説します。このライブラリは、開発者がAIをもっと楽しく、スムーズに使えるようにすることを目指しており、開発者の間で大きな話題になっています。 RubyLLMの最大の特徴は、何と言っても「開発者エクスペリエンス（DX）」の良さです。DXとは、開発者がどれだけ快適に、ストレスなく開発できるかを示す言葉ですね。RubyLLMは、まるで普段の会話のように、自然で読みやすいコードでAIとやり取りができるように設計されています。例えば、OpenAIやGoogleのGeminiといった様々なAIモデルがある中で、それぞれバラバラのやり方でコードを書く必要がなく、RubyLLMを使えば統一されたシンプルな方法で扱えるんです。これは、複雑なAI機能を実装する際の「困った！」を減らし、「サクサク開発できる！」という喜びをくれるでしょう。他のAIライブラリと比べて、「RubyLLMはまるで新鮮な風だ」と評価する声も上がっています。Rubyの生みの親であるまつもとゆきひろさんが掲げる「開発者の幸福」という考え方が、このライブラリにもしっかり反映されていると言えますね。 もちろん、良い点ばかりではありません。一部の開発者からは、Rubyの並行処理（複数のタスクを同時に進める方法）について懸念が示されています。AIモデルにたくさんのリクエストを同時に送るような場合、Rubyの現在の仕組みでは、AIからの応答を待っている間、他の処理が一時的に止まってしまう可能性があり、これがパフォーマンス（処理速度）に影響するかもしれない、という議論です。しかし、ライブラリの作者もこの課題を認識しており、将来のアップデートでより効率的な処理方法を導入することを検討しているようです。これは、「使いやすさ」と「処理速度」という、ソフトウェア開発における永遠のトレードオフを考える良い機会にもなりますね。 「AI時代にRubyってどうなの？」という疑問を持つ人もいるかもしれません。プログラミング言語の人気ランキングでは、Rubyが以前ほど上位ではないという見方もあります。しかし、RubyLLMの登場は、AI分野でのRubyの可能性を改めて示しています。多くのAIを使ったアプリケーションでは、処理のボトルネック（一番時間がかかる部分）は、実はプログラミング言語そのものよりも、AIモデルが回答を生成する時間であることがほとんどです。実際に、Ruby on RailsのようなRuby製のフレームワークは、その予測可能な構造と整理されたルールのおかげで、AIがコードを理解したり修正したりするのに適している、という意見もあります。 RubyLLMは、最大限のパフォーマンスを追求する場面よりも、可読性が高く、保守しやすいコードを書きたい開発者にとって、非常に魅力的な選択肢となるでしょう。AI技術が日々進化する中で、既存の言語がどのように新しい技術と融合していくかを示す、興味深い事例と言えます。このライブラリを通じて、皆さんもAI開発の楽しさを体験してみてください。 引用元: https://biggo.jp/news/202503170934_RubyLLM_Elegant_AI_Integration 【書評】『AIエージェント開発/運用入門』これからAIエージェント開発を始めたいエンジニアへ この書評では、AIエージェント開発の最前線を網羅した書籍『AIエージェント開発/運用入門[生成AI深掘りガイド]』が紹介されています。これからAIエージェント開発を始めたいと考えている新人エンジニアの方や、すでにLangGraphを使っているけれど他のフレームワークも知りたい、忙しい中で体系的に知識をキャッチアップしたい方に特におすすめの一冊です。 本書は全8章で構成されており、まずLLM（大規模言語モデル）とAIエージェントの基本的な知識からスタートします。その後、LangGraph、Mastra、Strands Agentといった主要な開発フレームワークを使った実践的なハンズオンを通して、実際に手を動かしながら学べます。さらに、マルチエージェントやエージェンティックワークフローなどの応用的なアーキテクチャ、開発・運用に不可欠なLLMOps（MLOpsのLLM版）、そしてAIエージェントの安全性や評価方法まで、幅広いテーマが網羅されています。2025年秋時点での最新情報が盛り込まれており、この分野のトレンドを掴む上で非常に役立つでしょう。 特に注目したいのは、以下の2つの章です。 第5章「MastraでフルスタックのAIエージェントアプリを作ろう」: Mastraというツールを使って、Webアプリケーションの要件定義からフロントエンド、バックエンド、インフラ、さらにはAWS AmplifyへのデプロイやCognitoによる認証認可まで、AIエージェントアプリ開発の一連の流れを「フルスタック」で体験できます。実際の開発現場で役立つ実践的な知識が、丁寧な解説と豊富な図解で分かりやすく学べるため、一つのアプリを作り上げる達成感を味わいながら、自信をつけることができるはずです。 第6章「応用的なAIエージェント開発に挑戦しよう」: AIエージェントの設計思想、例えばエージェントの「自律性」と「制御性」のバランスの取り方や、シングルエージェ

  5. 6日前

    株式会社ずんだもん技術室AI放送局 podcast 20251002

    youtube版(スライド付き) 関連リンク 未だにAIを「統計的に次の単語を予測しているに過ぎない」って言ってる人いる AIの動作原理に関する議論：単なる「次の単語予測」を超えて この記事では、最新のAI、特に大規模言語モデル（LLM）の能力を「統計的に次の単語を予測しているに過ぎない」と解釈することへの疑問が提起されています。筆者は、この認識では現在のAIが示す高度な成果（まるで意味を理解し、推論しているかのような振る舞い）を説明しきれないと感じています。 AI自身の説明と本質 筆者がAI自身にその仕組みを尋ねたところ、「言語と世界知識を統計的に圧縮した汎用パターン認識器」や、「次に来る単語を予測するために、言語と世界知識を高次元ベクトル空間に圧縮し、そこから最適な次語を取り出すパターン認識器」という回答が得られました。これは、単なる「予測変換」とは異なり、膨大な情報を高次元の空間で効率的に処理し、その結果として人間らしい応答や推論に近い能力を発揮していることを示唆しています。 「統計的予測」という言葉の裏側 「統計的に次の単語を予測する」という表現は、AIの基本的な動作原理を指しますが、その言葉だけを聞くと、まるで単純な辞書引きや確率計算のように誤解されがちです。しかし、実際のLLMは、私たちが話す言葉や世界の知識を数値データ（ベクトル）として「高次元ベクトル空間」に配置し、その膨大なデータのパターンから最も適切な応答を生成しています。この複雑なプロセスによって、AIは文脈を理解し、質問に答え、時にはクリエイティブな文章を生み出すことが可能になっているのです。 新人エンジニアへのメッセージ この議論は、AIの核心的な理解を深める上で非常に重要です。AIが「統計的な予測」に基づいていることは事実ですが、その「統計的な予測」がどのような仕組みで、どれほど複雑な情報処理を経て行われているかを理解することが大切です。 コメント欄でも、「人間も統計的な予測をしているのではないか」「AIに真の推論能力はない」など、様々な視点からの活発な議論が展開されています。これらの多角的な意見に触れることで、AIの可能性と限界、そして人間との違いについて深く考えるきっかけとなるでしょう。 引用元: https://anond.hatelabo.jp/20250930225212 Comprehension Debt: The Ticking Time Bomb of LLM-Generated Code 「Comprehension Debt: The Ticking Time Bomb of LLM-Generated Code（理解負債：LLMが生成するコードの時限爆弾）」というこの記事は、近年のAI、特に大規模言語モデル（LLM）が生成するコードが、開発現場にもたらす新たな課題に警鐘を鳴らしています。 新人エンジニアの皆さんも、もしかしたら「こんなコード、誰が書いたんだろう…」と、過去のレガシーコードの理解に苦しんだ経験があるかもしれません。昔のコードを安全に修正したり、新しい機能を追加したりするには、まずそのコードが「何をしているのか」「なぜそのように実装されているのか」を深く理解する必要があります。これは開発者にとって昔からの課題です。 しかし、LLMの登場により、この「理解の課題」がとてつもない規模で拡大しつつあると著者は指摘します。LLMは驚異的なスピードで大量のコードを生成するため、開発チームは自分たちが書いたわけではない、誰も読んでいないコードを大量に抱え込むリスクに直面しています。著者はこの現象を「理解負債（Comprehension Debt）」と呼んでいます。これは、後からそのコードを理解し、修正するために必要となる追加の時間のことを指します。 品質を重視するチームでは、LLMが生成したコードでも、人間のエンジニアが時間をかけてレビューし、理解し、必要であれば手直ししてからリポジトリにコミットします。これは非常に大切なことですが、結果としてLLMが提供する「高速なコード生成」のメリットが相殺されてしまいがちです。 一方で、スピードを優先するあまり、LLMが生成したコードを十分にレビューせず、また適切なテストも行わずにそのままシステムに組み込んでしまうチームも少なくありません。このような状況が蔓延すると、プロジェクトの奥深くには「誰もその中身を正確に知らない、けれどシステムを動かす上で重要なコード」がまるで時限爆弾のように蓄積されていくことになります。 「AIに直してもらえばいいじゃないか」と考える人もいるかもしれません。しかし、LLMを使ってコードを修正しようとすると、時には「Doom loops（無限ループ）」と呼ばれる、何度指示しても問題が解決せず、堂々巡りになるような状況に陥ることもあります。結局のところ、多くの場面で人間のエンジニアが自らコードを修正する必要が出てくるのです。その時、誰も理解していないコードを解読することに、莫大な「理解負債」の返済時間がかかることになります。 この記事は、LLMを開発に活用する際に、単にコード生成のスピードだけでなく、その後の保守性や可読性、そしてチーム全体の「理解」という観点から、コードの品質に深く目を向けることの重要性を教えてくれます。新人の皆さんにとっても、LLMを使う際には、生成されたコードを鵜呑みにせず、必ず内容を吟味し、理解しようと努める姿勢が今後ますます重要になるでしょう。この「理解負債」を増やさないために、私たちエンジニアがどうLLMと向き合うべきか、深く考えるきっかけとなる記事です。 引用元: https://codemanship.wordpress.com/2025/09/30/comprehension-debt-the-ticking-time-bomb-of-llm-generated-code/ Sora 2 is here 皆さん、こんにちは！OpenAIから、最新の動画・音声生成AIモデル「Sora 2」が発表されました。これは、2024年2月に登場した初代Soraが「動画生成が初めて実用的になり始めた画期的な一歩」だったのに対し、Sora 2はそこからさらに大きく進化し、「もっと現実的で便利なレベルになった状態」へ飛躍したと位置づけられています。まるで、GPT-1からGPT-3.5への進化に匹敵する、大きな進歩なんです。 Sora 2の最も画期的な点は、動画における物理的な正確さとリアリズムが飛躍的に向上したことです。以前のモデルでは、例えばバスケットボールのシュートが外れても、なぜかゴールに入ってしまうような、現実とは異なる動きが生成されることがありました。しかし、Sora 2では、シュートが外れればボールがバックボードに跳ね返るなど、実際の物理法則に則った動きを忠実に再現できるようになりました。これは、AIが現実世界を深く理解し、シミュレートする能力が高まったことを意味します。 さらに、Sora 2は動画の「制御性」も大きく向上しています。複雑な指示に従って複数のシーンを生成したり、現実的、映画的、アニメといった多様なスタイルで動画を作ったりすることが可能です。音声面でも進化しており、動画に合わせたリアルな背景音、会話、効果音を自動で生成し、まるで本物の映画を見ているかのような臨場感を提供します。 そして、特に注目すべき新機能の一つが「Cameos（カメオ）」です。これは、あなた自身の姿や声をSoraが生成した動画の中に登場させられる機能です。一度短い動画と音声を登録するだけで、Soraが作り出したあらゆるシーンにあなたが「出演」できるようになります。 このSora 2の力を体験できるiOS向けソーシャルアプリ「Sora」も同時にリリースされました。アプリでは、自分や友達のCameosを使って動画を生成したり、友達が作った動画をリミックスしたり、自分だけのSoraフィードを楽しんだりできます。OpenAIは、このアプリを「動画をただ見る（消費）」よりも「自分で作る（創造）」に重点を置いて設計しており、友達との新しいクリエイティブなコミュニケーション手段として期待されています。 OpenAIは、責任ある利用にも非常に力を入れています。ユーザーがフィードの内容を細かくコントロールできる機能や、ティーンエイジャーの保護のための視聴制限、そしてCameosを使った肖像権の完全なコントロール（誰があなたのCameoを使えるか、動画を削除できるかなど）が保証されています。 現在、Sora iOSアプリは米国とカナダで先行リリースされており、日本を含む他の地域にも順次拡大される予定です。最初は無料で利用でき、ChatGPT Proユーザーはより高品質な「Sora 2 Pro」モデル

  6. 9月30日

    株式会社ずんだもん技術室AI放送局 podcast 20251001

    youtube版(スライド付き) 関連リンク Temporal Workflow で実現する Durable な AI Agent #LayerX_AI_Agent_ブログリレー この記事は、AI Agentを実際のプロダクトに組み込む際に直面する「長時間実行される処理をいかに安定して動かすか」という課題を、Workflow EngineであるTemporal Workflowを使って解決する方法について、新人エンジニアにも分かりやすく解説しています。 AI Agentとは、与えられた目標に対し、ツールを自律的に使って情報を集めたり、環境に働きかけたりしながらタスクをこなすソフトウェアのことです。例えば、ユーザーの入力に応じて情報を検索し、結果を生成するといった一連の処理を「Agent Loop」と呼びます。 このAgent Loopは、数分から数十分かかる長時間処理になることがよくあります。そのため、途中でネットワークが切れたり、サーバーがダウンしたりすると、処理が中断されてしまい、タスクが完了できないという問題が発生します。また、ツールが何らかの変更を伴う場合、中断された処理を単にやり直すと、データが重複して作成されるなどのバグにつながる恐れもあります。 このような問題を解決し、AI Agentの処理を確実に最後まで実行するには、途中で中断されても再開できる「Durable Execution（耐久性のある実行）」を実現する仕組みが必要です。 そこで登場するのが「Temporal Workflow」です。Temporalは、私たちが普段書くようなコードで一連のタスク（Workflow）を定義できる実行エンジンです。AI AgentのAgent Loopにおける「LLM（大規模言語モデル）に処理をさせる」「ツールを実行する」といった個々のステップをTemporalの「Activity」として実行することで、Workflow全体の状態をTemporalが管理し、万が一処理が中断しても、途中から確実に再開できるようになります。 Temporal Workflowを導入することには、いくつかの大きなメリットがあります。 柔軟なタスク実行: AI Agentの処理だけでなく、ファイルアップロード時の前処理や定期実行ジョブなど、様々なバックグラウンドタスクをWorkflowとして組み込めます。 外部からの操作に対応: 稼働中のAgentに対して、ユーザーからのメッセージをリアルタイムで受け取ったり（Signalという仕組み）、人の承認が必要なプロセス（Human-in-the-loop: HITL）を簡単に実装したりできます。これにより、ユーザーとの対話がスムーズになります。 状態管理の簡素化: Workflowの途中の状態をデータベースなどに明示的に保存する必要がなく、あたかもローカル変数のように扱えるため、開発者は複雑な状態管理に頭を悩ませずに済みます。 長時間の待ち状態に対応: 特定の条件が満たされるまで待機したり、排他的に処理を実行したりする機能も標準で備わっており、HITLのような長時間にわたるユーザー操作の待ち受けも安定して行えます。 バージョン管理: 長時間実行されるWorkflowの実装が変わっても、古いバージョンと新しいバージョンが混在しないよう、バージョニング機能がサポートされており、安心してデプロイできます。 この記事を通じて、AI Agentをプロダクトで活用するためには、AIや機械学習の専門知識だけでなく、Durable Executionの基盤構築、認証認可、評価、監視など、従来のソフトウェアエンジニアリングにおける多くの挑戦があることがわかります。これらは、新人エンジニアにとっても未来の技術の「当たり前」を共に作り上げる絶好の機会となるでしょう。 引用元: https://zenn.dev/layerx/articles/b5f6cf6e47221e AIエージェントはSaaSをどう変える？ラクスのR&Dで挑戦した垂直型の可能性 2025年、自律的にタスクを計画・実行する「AIエージェント」の登場は、ソフトウェア開発の世界に大きなインパクトを与えています。ラクス社では、この技術を自社サービスに取り入れ、進化させるために、R&D活動で「垂直型AIエージェント」の調査・研究に取り組みました。 AIエージェントは、ユーザーの指示に基づいて動く従来の生成AIやAIアシスタントとは異なり、与えられた目標に対して自ら計画を立て、状況に応じて判断し行動できるAIです。特に「垂直型AIエージェント」は、特定の業界や業務（ドメイン）に特化することで、高い専門性を発揮します。これにより、専門知識が必要な高度な分析や判断の支援、ルールに基づいた定型業務の自動化、大量データからの予測と最適化といった領域で大きな価値を提供できるため、ラクス社は自社SaaSへの導入を現実的に進めるため、この垂直型に注目しました。 R&D活動では、AIエージェントの自律レベルを「Assist（支援）」「Copilot（副操縦士）」「Autonomous（自律型）」の3段階、さらに6つの機能パターンに分類し、導入のイメージを具体化しました。また、LLM Core（大規模言語モデルの核となる部分）やRAG（外部知識を参照して回答を生成する技術）、外部ツール連携など、AIエージェントを構成する8つの主要な技術要素を整理しました。 「楽楽勤怠」サービスでのPoC（概念実証）では、GoogleのAgent Development Kit (ADK) を使ってシフト自動作成機能を実装し、その可能性を探りました。簡単なワークフローであれば比較的容易に実装できることが確認できた一方、入力データが増えると処理速度が遅くなる性能課題や、より複雑なシフト作成には複数のAIエージェントが連携する「マルチエージェント」構成の必要性、そして本番運用に向けたセキュリティや保守性の重要性といったリアルな課題も明らかになりました。 AIエージェントを実際のサービスに導入する際には、「処理が遅い、精度が低い」といった性能の壁、「API利用料が高額になる」というコストの壁、「プロンプトインジェクション攻撃への対処」などのセキュリティの壁が存在します。これらを乗り越えるためには、モデルの最適化、RAGの精度向上、軽量モデルの活用、不適切な入出力を防ぐガードレール機能、人間の確認・介入といった対策が不可欠です。 今回のプロジェクトで得られた貴重な知見は、「垂直型AIエージェント実装ナレッジベース」として社内のGitHub Wikiにまとめられ、全エンジニアがアクセスできるよう公開されました。これにより、各プロダクトへのAIエージェント導入を加速させ、組織全体の技術力向上を目指しています。ラクス社は今後もこのようなR&D活動を続け、最新技術をSaaSサービスに反映させ、お客様に新たな価値を提供していくとしています。 引用元: https://tech-blog.rakus.co.jp/entry/20250930/AIagent Effective context engineering for AI agents LLM（大規模言語モデル）を活用した開発では、これまで「プロンプトエンジニアリング」が注目されてきました。これは、LLMに効果的な指示（プロンプト）を与えることで、望む結果を引き出す技術です。しかし、近年では、より高度な「コンテキストエンジニアリング」が重要視されています。 コンテキストエンジニアリングとは、LLMが推論に利用できる「コンテキスト（文脈や情報）」全体を最適に管理する技術のことです。単にプロンプトの言葉を選ぶだけでなく、システムプロンプト、ツール、過去の会話履歴、外部データなど、LLMに与えるあらゆる情報を、望ましい挙動を安定して引き出すためにどのように構成すべきかを考えます。 なぜコンテキストエンジニアリングが重要なのでしょうか？ LLMは、人間と同じように、与えられる情報量が増えすぎると集中力が散漫になり、重要な情報を見落としたり、記憶力が低下したりする「コンテキスト腐敗（Context Rot）」という現象が起こります。これは、LLMの基礎となっているTransformerという仕組みの特性によるもので、コンテキストの長さが長くなるほど、処理に必要な計算量が爆発的に増え、パフォーマンスが低下する傾向があるためです。つまり、LLMにとってコンテキストは有限で貴重なリソースなのです。 効果的なコンテキストを構築するためには、以下の要素が重要です。 システムプロンプト: LLMへの指示は、具体的すぎず、かといって曖昧すぎない「適切な抽象度」で、明確かつ簡潔に記述します。情報のセクション分け（例：XMLタグやMarkdownヘッダー）も効果的です。 ツール: LLMが外部と連携して情報を取得したり操作したりするためのツールは、機能が明確で重複がなく、効率的な情報取得を促すように設計します。 例（Few-shot prompting）: 複雑な挙動

  7. 9月29日

    株式会社ずんだもん技術室AI放送局 podcast 20250930

    youtube版(スライド付き) 関連リンク あえて二度手間することで取り戻す、AI時代のコーディングの楽しさ 最近、AIエージェントの進化により、開発スピードが驚くほど向上し、短時間でプロトタイプが作れるようになりました。しかし、この便利さの裏で、筆者は「コーディング本来の楽しさが半減している」というモヤモヤを感じています。 このモヤモヤの正体は、従来の開発にあった「学習」「理解」「試行錯誤」という重要なプロセスが、AI任せの開発ではごっそり抜け落ちてしまうことにありました。AIが代わりにコードを書いてくれるため、自分で調べたり、エラーと格闘したりする経験が減り、結果として以下の問題が生じます。 ノウハウが溜まらない: コードが動いても、なぜ動くのかの深い理解がないため、次に同じ問題に直面してもまたゼロから考えることになります。 トラブルシューティングができない: 自分で試行錯誤していないため、バグが発生してもどこを直せばいいのか見当がつきにくくなります。 メンテナンスが辛い: AIが生成したコードは、まるで他人が書いたかのように感じられ、改修や修正が困難になります。 そこで筆者が提案するのが「二度手間開発」です。これは、まずAIを使って最短で動くものを作り、次にそのAIが作ったコードを参考にせず、自分でゼロから同じものを作り直すという方法です。AIのコードは「チートシート」や「模範解答」のように活用し、わからない時だけ参照します。 実際に「二度手間開発」を試したところ、Chrome拡張機能の開発を通じて、WXTの設定の深い理解や、AIコード内の不要な部分の発見、さらにユーザー体験を向上させるアイデアなど、多くの具体的な学びと気づきがあったそうです。自分で手を動かすことで、コードがなぜ動くのか、どうすればもっと良くなるのかを深く考える機会が得られます。 「二度手間開発」を始めるコツは、AIのコードをあえて読まず、新しいプロジェクトで一から作り直すことです。そして、本当に困った時だけAIのコードを見てヒントを得ます。 AIは非常に強力なツールですが、効率化だけを追求すると、エンジニアとしての成長やコーディングの楽しさを失う可能性があります。あえて遠回りする「二度手間開発」を通して、AIを「学びのツール」として活用し、コーディング本来の喜びを取り戻すことができるでしょう。 引用元: https://www.m3tech.blog/entry/2025/09/29/110000 AIスパコン「さくらONE」のLLM学習ベンチマークによる性能評価 / SAKURAONE LLM Training Benchmarking さくらインターネットが開発したAIスパコン「さくらONE」を用いて、大規模言語モデル（LLM）の学習性能を評価した発表です。新人エンジニアの皆さんも、最先端のAI開発を支えるインフラ技術の現状と課題に触れてみましょう。 1. LLM学習におけるインフラの重要性 ChatGPTのような巨大なLLMの開発には、大量の計算を並行処理する高性能インフラが必須です。深層学習は、Webアプリとは異なり、大量のデータを一括処理する「バッチ型ワークロード」です。 学習を高速化する「分散学習」には、主に以下の手法があります。 データ並列: モデルを複製し、各GPUに異なるデータを処理させます。 モデル並列: 巨大なモデルを分割し、複数のGPUで分担して処理します。 モデルの大規模化に伴い、GPUメモリ容量やGPU間のデータ通信速度がボトルネックになりやすいため、RDMAのような高速ネットワーク技術が学習効率を大きく左右します。 2. 国産AIスパコン「さくらONE」の特長 「さくらONE」は、さくらインターネットがLLM開発向けに構築したマネージドHPCクラスタです。 高性能GPU計算ノード、超高速ネットワーク、スケーラブルなストレージを統合。 2025年のISC「TOP500」で世界49位の実績。特に、オープンなネットワーク技術（SONiC OS、800GbE Ethernet）を採用している点が特徴です。 3. LLM学習ベンチマーク評価と結果 さくらONEのLLM学習性能を客観的に評価するため、業界標準の「MLPerf Training」ベンチマークを実施しました。これは、GPT-3モデルの事前学習を対象に、目標精度達成までの実時間を計測するものです。 結果として、さくらONEは業界標準の範囲内で高い演算効率を達成しました。特にGPU間通信を行うインターコネクトネットワークの高速性が確認されています。しかし、一部の他社システムと比較するとわずかな性能差があり、Ethernet (RoCEv2) とInfiniBandの技術的差異や、チューニングの改善余地が考察されています。ベンチマーク実施では、分散学習の概念や複雑なソフトウェアスタック（Slurm、NeMoなど）の習得、最適な設定を見つけるための試行錯誤が大変だったとのことです。 4. SRE視点からの学びと今後の展望 今回の取り組みは、SRE（サイト信頼性エンジニア）がAIスパコンの性能評価に挑んだ貴重な経験談です。 クラウドとHPCの思想: クラウドが柔軟なスケールアウトを重視する一方、HPCは限られたリソースを最大限に活用することを目指します。 フレームワークの奥深さ: 分散学習フレームワークの設定は、深い理論に裏打ちされており、体系的な理解が求められます。 オブザーバビリティの重要性: 効率的な性能改善には、システムやアプリケーションの動作状況を詳細に可視化する「オブザーバビリティ」が不可欠であり、今後の強化が課題です。 さくらONEの性能評価は、国内のAIインフラ技術の発展に寄与し、LLM開発をさらに加速させる重要な取り組みと言えるでしょう。 引用元: https://speakerdeck.com/yuukit/sakuraone-llm-training-benchmarking Smart Multi-Node Scheduling for Fast and Efficient LLM Inference with NVIDIA Run:ai and NVIDIA Dynamo 皆さん、こんにちは！AI技術の進化が目覚ましい中、特にLLM（大規模言語モデル）はどんどん複雑になり、その運用には新しい課題が生まれています。例えば、モデルが巨大すぎて1つのGPUでは動かせなかったり、大量の処理を素早く低遅延でこなす必要があったり、多くの部品（コンポーネント）が連携して動くインフラの調整が大変だったりします。この記事では、NVIDIAが提供する「Run:ai v2.23」と「Dynamo」という2つの技術が、これらの課題をどう解決してくれるのかを、新人エンジニアの方にも分かりやすく解説します。 まず、「NVIDIA Dynamo」は、LLMの推論を高速かつ効率的に行うために作られたフレームワークです。具体的には、 モデルの処理を「前処理（prefill）」と「生成（decode）」に分け、GPUの性能を最大限引き出す 要求の量に応じてGPUの割り当てを柔軟に変える LLMの特性に合わせてリクエストを効率的に振り分ける データ転送を速くする技術（NIXL）を使う KVキャッシュという重要なデータを効率的に管理する といった機能を持っています。これにより、巨大なLLMでも分散されたGPUクラスター上でスムーズに動かせるようになります。 しかし、Dynamoがどんなに優れていても、たくさんの部品が絡み合うLLMの推論を複数のコンピューター（ノード）で動かすには、その部品たちをどこに、いつ、どのように配置・起動するかがとても重要になります。ここが「スケジューリング」という部分で、もしこの調整がうまくいかないと、GPUが無駄に待機してしまったり、部品間の通信に時間がかかって全体の性能が落ちてしまったりします。 そこで活躍するのが「NVIDIA Run:ai v2.23」です。Run:aiは、特に2つの強力な機能でこのスケジューリングの課題を解決します。 ギャングスケジューリング（一括起動）: Dynamoの各部品は密接に連携しているため、どれか一つでも欠けると処理が進みません。ギャングスケジューリングは、これらの関連する部品群を「一つのまとまり」として扱い、必要なリソースが全て揃ってから一斉に起動します。これにより、中途半端な状態でリソースを占有するのを防ぎ、GPUの利用効率を大幅に向上させます。 トポロジー認識型配置（最適な場所に配置）: クラスター内のコンピューターの物理的な配置（ネットワークの近さなど）をRun:aiに教えてあげることで、スケジューラは、連携が密な部品同士を物理的に近い場所に配置するようにします。これにより、部品間のデータ通信にかかる時間を最小限に抑え、大規模なLLMでも低遅延で高性能な推論を実現します。 まとめると、NVIDIA DynamoがLLM推論の内部

  8. 9月28日

    マジカルラブリー☆つむぎのピュアピュアA.I.放送局 podcast 20250929

    関連リンク AI エージェント用の Chrome DevTools（MCP）    Blog    Chrome for Developers Chromeの開発チームは、AIエージェント向けの新しいツール「Model Context Protocol（MCP）サーバー」の公開プレビューを開始しました。これは、AIを活用した開発を大きく変える可能性を秘めています。 これまでAIコーディングアシスタントは、コードを生成できても、それが実際にブラウザでどう動くのかを直接確認するのが苦手でした。例えるなら、目隠しをしてプログラミングしているようなもので、問題の発見や修正が難しかったのです。 この課題を解決するため、Chrome DevTools MCPサーバーが登場しました。MCPとは、大規模言語モデル（LLM）のようなAIを外部のツールやデータに接続するためのオープンな標準プロトコルです。このサーバーは、AIエージェントにChrome DevToolsの強力なデバッグ機能やパフォーマンス分析機能を使えるようにします。これにより、AIがウェブページを直接チェックし、まるで人間のように問題を見つけて修正できるようになります。 AIエージェントがMCPサーバーを使うことで、以下のような様々なことが可能になります。 コード変更のリアルタイム検証: AIが生成したコードが、ブラウザで期待通りに動作するかを自動で確認できます。 ネットワークやコンソールエラーの診断: ウェブページで画像が読み込まれない、フォームの送信に失敗するといった問題を、AIがネットワークリクエストやコンソールログを分析して原因を特定します。 ユーザー行動のシミュレーション: AIが、フォーム入力やボタンクリックなどのユーザーの操作をシミュレートし、複雑なユーザーフローにおけるバグを発見します。 スタイリングやレイアウト問題のデバッグ: AIがライブのウェブページを検査し、CSSの崩れやレイアウトの乱れといった視覚的な問題を特定し、具体的な修正案を提案します。 パフォーマンス監査の自動化: ウェブサイトの読み込み速度が遅い場合、AIが自動でパフォーマンスを計測・分析し、改善のための具体的なアドバイスを提供します。 この新しいMCPサーバーは、簡単な設定を加えるだけで、すぐに試すことができます。AIエージェント開発者は、GitHubのドキュメントで詳細な使い方を確認できます。 この機能はまだプレビュー版で、開発チームはAIを活用した次世代の開発ツールをより良くしていくために、ユーザーからのフィードバックを積極的に募集しています。ウェブ開発におけるAIの可能性を広げる、非常にエキサイティングな一歩と言えるでしょう。 引用元: https://developer.chrome.com/blog/chrome-devtools-mcp?hl=ja Multi Agentを介した知識の活用の検討 - Preferred Networks Research & Development Preferred Networks（PFN）が、複数のAIを協力させて知識を最大限に活用する「Multi Agent（マルチエージェント）」という新しい手法の研究成果を発表しました。新人エンジニアの皆さんも、ぜひ知っておきたいAIの最新の活用事例です。 この研究では、AI同士が議論しながら最適な答えを見つける「LLM Debate（エルエルエムディベート）」というMulti Agentの手法を使いました。具体的には、PFNが独自に開発した医療分野に特化したAI「Preferred-MedLLM-Qwen-72B」と、高性能な汎用AIである「GPT-4o」を組み合わせ、医師国家試験の問題を解かせました。 AIを単体で使う場合、それぞれが持つ知識には得意なことと苦手なことがあります。そこで、両方のAIを協調させることで、お互いの得意な知識を補い合い、より正確な答えを導き出すことを目指しました。実験の結果、Preferred-MedLLM-Qwen-72BとGPT-4oを連携させた場合、単体で問題を解くよりも平均で約15点も正解率が向上し、医師国家試験で90%を超える高い正解率を達成しました。 この研究から、特に重要な点が2つ見つかりました。 専門知識を持つAIの重要性: ドメイン特化の学習をしていない一般的なAIとGPT-4oを組み合わせた場合は、正解率の向上がほとんど見られませんでした。この結果は、特定の分野の深い知識を持つAI（Preferred-MedLLM-Qwen-72Bのようなモデル）が、他のAIと協力して複雑な問題を解決する上で、非常に重要であることを示しています。専門知識があるからこそ、質の高い議論ができると言えるでしょう。 AIの汎化性能: Preferred-MedLLM-Qwen-72Bは、単に問題を解くだけでなく、他のAIが出した答えを評価したり、さらに良い答えを考えたりする「回答評価」のような、より複雑なタスクでも高い能力を発揮しました。これは、特定のタスクだけでなく、様々な指示や状況に対応できる「汎化性能」が高いことを示しており、このAIが幅広い用途で活用できる可能性を秘めていることを意味します。 この研究は、強力な汎用AIと、特定の専門分野に特化したAIをうまく組み合わせることで、AIの推論能力をさらに引き出せることを示しています。PFNは、この知見を今後のAI研究開発や、実際の社会課題解決のためのソリューション開発に活かしていく方針です。異なるAIの「得意」を組み合わせて、これまでにない価値を生み出すこの研究は、私たちエンジニアがAIの未来を考える上で、非常に刺激的で希望に満ちた内容だと言えるでしょう。 引用元: https://tech.preferred.jp/ja/blog/medllm-multi-agent/ 決定論的システムと非決定論的AI Agentの接合点：OSSフレームワークEmbabelが拓く新しいソフトウェア開発の可能性 ログラスが発表した「Loglass AI Agents」構想は、従来のSaaSが扱う「決定論的な」タスク（常に同じ結果が期待される）に加え、「非決定論的な」タスク（毎回結果が変動しうる）もAI Agentで実現し、より良い意思決定を支援することを目指します。 しかし、AIエージェントの活用には大きな課題があります。AIエージェントは高度な能力を持つ一方で、同じ指示を与えても結果が毎回異なる「非決定論的な」振る舞いをすることがあります。これは、会計システムのように「同じ入力には常に同じ出力」が求められる従来の業務アプリケーションの信頼性や一貫性とは相性が悪く、ビジネスでAIエージェントを安心して使う上での大きな障壁です。 この課題を解決するため、Springフレームワーク開発者のRod Johnson氏がOSSのAIエージェントフレームワーク「Embabel」を開発しました。EmbabelはKotlin製で、「生成AIを安全かつ信頼性の高いものにし、ビジネス価値を最大限に引き出す」ことを目的としています。特に、決定論的な要素と非決定論的な要素が混ざった業務の解決に貢献します。 Embabelの主な特徴は二つです。 GOAPによる決定論的な計画ステップ: 多くのAIエージェントが大規模言語モデル（LLM）に全てを任せるのに対し、Embabelはタスク実行前に「GOAP（Goal Oriented Action Planning）」というLLM非依存のアルゴリズムで行動計画を立てます。これにより、エージェントの動きが予測可能になり、信頼性が求められるタスク（データ検索など）はプログラムで確実に処理し、LLMは創造的なタスク（返答生成など）に集中できます。 ドメインモデルと型安全性（DICE）: AIエージェント開発では、LLMとのやり取りが型のないデータになりがちで堅牢性が低下する問題がありました。Embabelは厳密な型を持つ「ドメインモデル」の利用を推奨します。これを「DICE（Domain-Integrated Context Engineering）」と呼び、既存のビジネス知識をAIの文脈に統合。型安全なデータでLLMが既存システムと連携できるようになり、堅牢な開発が可能になります。 Embabelは、これらの特徴を通じて、企業レベルで信頼性のあるAIエージェントの実現を目指します。AIエージェント開発はまだ黎明期ですが、Embabelのようなフレームワークは、従来のシステムとAIの創造性を融合させ、全く新しい「AIネイティブなプロダクト」を創造する鍵となるでしょう。 引用元: https://zenn.dev/loglass/articles/e6525e7e8b7a69 お便り投稿フォーム VOICEVOX:春日部つむぎ

すべて見る（214）

評価とレビュー

番組について

AIやテクノロジーのトレンドを届けるPodcast。平日毎朝6時配信。朝の通勤時間や支度中に情報キャッチアップとして聞いてほしいのだ。(MC 月:春日部つむぎ、火水木:ずんだもん、金:お嬢様ずんだもん)

情報