Episodes

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

    株式会社ずんだもん技術室AI放送局 podcast 20250515
    May 14 2025
    関連リンク AlphaEvolve: A Gemini-powered coding agent for designing advanced algorithms Google DeepMindが、Geminiという強力なAIモデルを活用した新しいAIエージェント「AlphaEvolve」を発表しました。このAlphaEvolveは、コンピューターのアルゴリズムを自動で設計したり、より効率的なものに進化させたりすることを目指したシステムです。 AlphaEvolveの仕組みは、Geminiの持つ創造性を活かして様々なアルゴリズムのアイデア（コード）をたくさん生成し、それらを自動で評価・検証することで、より良いものを選んでさらに改良していく、というプロセスを繰り返します。まるで生物が進化するように、最適なアルゴリズムを探し出すイメージです。 この技術はすでに様々な実用的な成果を上げています。例えば、Googleが持つ大規模なデータセンターの運用効率を向上させるアルゴリズムを発見し、計算リソースをより有効に使えるようになりました。また、AIの処理に特化したGoogle独自の半導体（TPU）の設計の一部を支援したり、Gemini自身のAIモデルの学習や推論のスピードを速くするコードを生成したりもしています。特に、AIの計算で重要な部分（カーネルと呼ばれます）の最適化において、専門家が何週間もかけていた作業を、AlphaEvolveが数日で改善策を見つけ出すといった効率化が実現しています。 さらに、AlphaEvolveは数学の未解決問題にも挑戦し、成果を出しています。コンピューターサイエンスの基礎である行列乗算の新しい高速アルゴリズムを発見したり、幾何学の難問で新記録を樹立したりといった研究レベルでの進歩も達成しています。 AlphaEvolveは、アルゴリズムとして記述でき、かつ自動でその良さを評価できる問題であれば、幅広い分野に応用できる可能性があります。今後は、材料科学や創薬といった分野への活用も期待されています。Googleは、この技術を一部の学術研究者向けに先行公開することを検討しており、将来的にさらに多くの人が使えるようにすることも視野に入れているようです。 AlphaEvolveは、AIがコードを生成するだけでなく、複雑な問題を解決するためにアルゴリズムそのものを進化させる、という新たな可能性を示しており、今後の技術開発に大きな影響を与えるかもしれません。 引用元: https://deepmind.google/discover/blog/alphaevolve-a-gemini-powered-coding-agent-for-designing-advanced-algorithms/ Gartner、「AIエージェント」と「エージェント型AI」の違いに混乱が生じていると見解を発表 IT分野の調査会社であるGartnerが、「AIエージェント」と「エージェント型AI」という二つの言葉について、その違いが分かりにくくなっている現状を踏まえ、それぞれの定義とAIの進化における位置づけについて見解を発表しました。 Gartnerはこれらの言葉を次のように定義しています。 AIエージェント: デジタルや現実の世界で、状況を把握（知覚）し、次に何をすべきか判断（意思決定）して行動を起こす（アクション）、自律的またはある程度自分で動けるソフトウェアです。特定の目的達成のためにAI技術を使います。エージェント型AI: こちらは、特定の組織（会社など）の代わりに働くことを目指し、自律的に判断して行動する権限を与えられたソフトウェアです。目標を達成するために、AI技術だけでなく、「記憶（過去の情報）」、「計画（手順を考える）」、「センシング（状況把握）」、「ツール利用（外部ツールを使う）」、「ガードレール（安全装置）」といったより多くの機能を使って、複雑なタスクを目的達成に向けて遂行します。 簡単に言うと、AIの進化の段階で考えると理解しやすいかもしれません。例えば、チャットボットは限定された応答、RPAは定型作業の自動化が得意です。これに対し、AIエージェントはもう少し自分で判断して簡単なタスクの一部をこなせます。さらに進化した「エージェント型AI」は、より高度な知能と機能を持ち、複雑な目標を自律的に達成するために行動できる、言わば「AIの代理人」のような存在です。 AIは、単なる自動化から、人間の代理として行動するより高度なエージェント型へと進化しつつあるとGartnerは述べています。 また、最近注目...
    Show More Show Less
    Less than 1 minute
  • 株式会社ずんだもん技術室AI放送局 podcast 20250514

    株式会社ずんだもん技術室AI放送局 podcast 20250514
    May 13 2025
    関連リンク MCPやAIエージェントに必須の「LLMの外部通信・連携」におけるセキュリティ観点 大規模言語モデル（LLM）はテキスト生成などで高い能力を持ちますが、単体では最新情報や非公開データを知らなかったり、現実世界でアクションを起こせなかったりする制約があります。これらの「知識の壁」「実行の壁」「能力の壁」を超えるために、LLMは外部サービス（APIなど）と連携する必要があります。MCPやAIエージェントでは、このような外部連携が不可欠です。 しかし、LLMが外部と連携できるようになると、新たなセキュリティリスクが生まれます。開発者の皆さんは、このリスクを理解し対策することが重要です。 記事では、具体的な機能例として「URL指定による情報取得機能」と「Gitホスティングサービス連携機能」を取り上げ、潜むリスクを解説しています。 例えば「URL指定による情報取得機能」では、指定されたURLから情報を取得するために外部へ通信します。ここで、悪意のあるURLを指定されると、サーバー内部のリソースに不正アクセスされる「SSRF」という危険性があります。また、ユーザーからの指示や外部の情報に埋め込まれた悪意のあるテキスト（プロンプトインジェクション）によって、LLMが意図せず機密情報を含むリクエストを生成してしまうリスクも考えられます。 「Gitホスティングサービス連携機能」のように、LLMが外部サービスで実際に操作を行う機能では、「過剰な代理行為」に注意が必要です。LLMに必要以上の権限を与えていると、ユーザーの曖昧な指示や、外部の情報に仕掛けられた偽の指示によって、意図しない広範囲な操作（リポジトリの削除など）を実行してしまう可能性があります。また、LLMが扱うプライベートな情報（コードやIssue内容など）が、LLMの「コンテキストウィンドウ」を通じて外部に漏洩するリスクもあります。 これらのリスクに対して、記事では以下の対策を挙げています。 最小権限の原則: LLMが利用する外部連携ツールの権限は、必要最低限に絞る。認証情報の分離: 外部サービスへの認証情報は、LLMのコンテキストから完全に分離し、安全な場所に管理する。コンテキストウィンドウの分離: LLMのコンテキストウィンドウには、漏洩しても問題ない情報や、そのタスクに必須の情報のみを含めるように設計する。入出力の境界での防御: LLMへの入力や出力に対して、不適切な内容がないかチェックする機能（ガードレールなど）を設ける。 外部連携するLLMアプリケーションを開発する際は、これらのセキュリティ観点をしっかり考慮し、安全な設計を心がけましょう。 引用元: https://blog.flatt.tech/entry/llm_ext_collab_security AIワークフローサービス比較メモ（Dify / n8n / Gumloop） この記事では、AIを使った様々な作業を自動化する「AIワークフローサービス」の中から、特に注目されているDify、n8n、Gumloopの3つを比較して紹介しています。これらのツールを使うと、プログラミングの専門知識が少なくても、AIや他のサービスを組み合わせて複雑な自動化の仕組み（ワークフロー）を簡単に作れるようになります。 Dify 日本で特に人気があるのがDifyです。その理由は、UIやドキュメントが日本語でしっかり整備されているため、日本のユーザーが使い始めやすい点にあります。Difyは、主にチャットボットや、企業のデータを使った質疑応答システム（RAG）のような、生成AIを使ったアプリケーションの開発に特化しています。オープンソース版とクラウド版が提供されており、企業が社内向けのAIアプリを素早く作るのに役立ちます。 n8n n8nは、SlackやGoogle Workspaceなど、様々なWebサービス同士を連携させて業務を自動化するためのツールとして以前から使われています。最近はAIとの連携機能も強化され、AIを使った新しい自動化が可能になりました。例えば、「メールの内容をAIで要約してチャットツールに通知する」といったワークフローが作れます。400種類以上の外部サービスと連携できる汎用性があり、完全にノーコードだけでなく、コードを書いてより柔軟な処理も組み込めるため、技術者にも適しています。こちらも...
    Show More Show Less
    Less than 1 minute
  • 株式会社ずんだもん技術室AI放送局 podcast 20250513

    株式会社ずんだもん技術室AI放送局 podcast 20250513
    May 12 2025
    関連リンク Byte Latent Transformer: Patches Scale Better Than Tokens 大規模言語モデル（LLM）の多くは、テキストを処理する際に、文章を「トークン」と呼ばれる単語や文字のまとまりに区切ります。この論文では、そういった事前準備としての「トークン化」を行わず、テキストの最小単位である「バイト」レベルで直接処理する新しい技術、「Byte Latent Transformer (BLT)」が提案されています。 BLTのポイントは、バイト列を固定長のトークンとして扱うのではなく、「パッチ」という単位で扱うことです。このパッチのサイズが特徴的で、データの内容に応じて自動的に長さを変えます。例えば、次に続くバイトが簡単に予測できるような、パターン化された情報が多い部分ではパッチを長くし、予測が難しい複雑な情報が多い部分ではパッチを短くするといった具合です。これは、次に予測すべきバイトの「予測しにくさ」を示す情報エントロピーに基づいて行われます。 このようにパッチのサイズを動的に変えることで、モデルは計算リソースを効率的に割り当てることができ、結果として推論（モデルを使って新しいテキストなどを生成する処理）の効率が向上します。また、特定のトークンセットに縛られないため、より多様なデータに対応しやすくなる（頑健性が高まる）と考えられます。 研究では、最大80億パラメータを持つBLTモデルを膨大なデータ（4兆バイト）で学習させ、その有効性を検証しました。実験から、トークン化なしで生バイトから学習できること、そして同じ計算コストで比較した場合、従来のトークンベースのモデルよりも性能を効率的に向上させられる（スケーリング性能が良い）ことが示されました。 この技術は、従来のLLMの仕組みに一石を投じるものであり、将来的にテキストだけでなく、バイト列で表現可能なあらゆる種類のデータ（プログラムコード、もしかすると画像や音声など）を効率的に扱えるようになる可能性を秘めています。LLMの基盤技術の進化として注目に値する研究です。 引用元: https://arxiv.org/abs/2412.09871 LLMフレームワークのセキュリティリスク - LangChain, Haystack, LlamaIndex等の脆弱性事例に学ぶ この記事は、近年普及しているLLM（大規模言語モデル）を使ったアプリケーション開発を効率化する「LLMフレームワーク」に潜むセキュリティリスクと対策について、新人エンジニア向けに分かりやすく解説しています。 LangChainやLlamaIndexといったLLMフレームワークは非常に便利ですが、その機能の裏には新たなセキュリティリスクが生まれています。特に注意すべき点は二つあります。一つは、フレームワークが提供する「実験的な機能」や「非推奨のオプション」を安易に使うことです。例えば、LangChainにはLLMにPythonコードを実行させる機能や、危険なリクエストを許可するオプションがあり、これらを不用意に使うと、攻撃者にサーバー上で任意のコードを実行されてしまう（RCE：Remote Code Execution）脆弱性につながる可能性があります。この教訓として、実験的な機能や非推奨オプションは、本当に必要か設計段階でよく考え、可能な限り使わないことが重要です。 もう一つは、LLMフレームワークそのものの実装に潜む脆弱性です。記事では、LangChain, Haystack, LlamaIndexなどの実際の脆弱性事例を挙げて解説しています。 SSRF (Server Side Request Forgery): 外部から指定されたURLにサーバーがリクエストを送信してしまう脆弱性。LangChainのWebクロール機能で、URLの検証が不十分だった事例があります。対策は、外部URLは許可リスト方式で厳しくチェックすることです。Path Traversal: 外部入力値を使ってサーバー上のファイルに不正にアクセスされてしまう脆弱性。LangChainjsのファイル読み込み機能で、パス名の検証が漏れていた事例があります。対策は、パス指定には「../」のような特殊文字を制限することです。SQL Injection: 外部入力値で意図しないSQLを実行されてしまう脆弱性。LangChainのSQL操作機能で、LLMが生成したSQLの検証が不十分だった事例があります。対策は、Prompt Injectionを防ぎ、LLMに与える権限を最小限にし、入力値をしっかり検証することです。RCE: 外部...
    Show More Show Less
    Less than 1 minute
  • マジカルラブリー☆つむぎのピュアピュアA.I.放送局 podcast 20250512

    マジカルラブリー☆つむぎのピュアピュアA.I.放送局 podcast 20250512
    May 11 2025
    関連リンク What Every AI Engineer Should Know About A2A, MCP & ACP ** AIエージェント技術が進むにつれて、エージェント単体ではなく、複数のエージェントが互いに連携したり、外部のデータやツールを使ったりすることが増えてきます。これを実現するために、「通信プロトコル」という共通のルールが必要になります。この記事では、現在注目されている3つの主要なプロトコル、MCP、ACP、A2Aについて、新人エンジニア向けに分かりやすく解説します。 MCP (Model Context Protocol) MCPは、特に大規模言語モデル（LLM）が、外部にある様々な情報源（ファイル、データベース、Web APIなど）や、特定の機能を持つツールにアクセスするための標準規格です。LLMにすべての知識を持たせるのではなく、必要な情報を外部から取得したり、ツールを呼び出したりできるようになります。これは、AIエージェントが外部の世界と繋がり、具体的なタスクを実行するための「道具箱へのアクセス方法」を定義するようなものです。Anthropicが中心となって提案しています。 ACP (Agent Communication Protocol) ACPは、ローカル環境やエッジデバイス内で動作するAIエージェント同士が、低遅延でリアルタイムに通信し、協調するためのプロトコルです。クラウドサービスへの依存を減らし、ネットワークが不安定だったり、プライバシーが重要だったりする環境（例えば工場内のロボット連携やオンデバイスAI）での利用を想定しています。エージェントは自分の能力を公開し、他のエージェントとイベント駆動型で情報を交換します。同じ場所で働くエージェントたちの「内線電話」のようなイメージです。BeeAIとIBMが提案しました。 A2A (Agent-to-Agent Protocol) A2Aは、Googleが提案するプロトコルで、異なる企業やシステムで開発されたAIエージェントが、インターネットなどのネットワークを介して互いに発見し、安全に通信し、タスクを依頼し合うための標準です。エージェントは「Agent Card」という情報カードを公開し、互いの能力や接続方法を知ることができます。これにより、様々な場所で動くエージェントが連携して、より大きな目標を達成できるようになります。これは、世界中の異なる専門家がインターネットで繋がってプロジェクトを進めるための「グローバルなビジネスルール」のようなものです。 まとめ：プロトコル間の関係 これらのプロトコルは、それぞれ異なる得意分野を持っています。A2Aは「エージェント同士」の広域連携、MCPは「AIと外部リソース・ツール」の連携、ACPは「ローカルなエージェント同士」の密な連携を担います。A2AとMCPは組み合わせて使われることが多く、エージェント間の連携（A2A）でタスクを依頼されたエージェントが、外部のデータやツール（MCP）を使ってタスクを実行する、といった形が考えられます。 AIエージェント開発にこれから関わるにあたり、これらのプロトコルがどのような課題を解決しようとしているのか、それぞれの役割は何なのかを知っておくことは、今後の技術トレンドを理解する上で非常に役立つでしょう。 文字数: 785 引用元: https://medium.com/@elisowski/what-every-ai-engineer-should-know-about-a2a-mcp-acp-8335a210a742 📝 AIエージェントの設計論：「Big Model」と「Big Workflows」 この記事は、OpenAIやLangChainなどの考え方を元に、AIエージェントの設計思想を比較検討したものです。AIエージェント開発には、「Big Model」と「Big Workflows」という二つの考え方があることが分かります。 「Big Model」は、高性能な大規模言語モデル（LLM）の能力を最大限に活かし、多くの判断や処理をモデルに任せるアプローチです。モデルの進化が速いので、シンプルな構成で早く始められるのが利点です。OpenAIはまず「シングルエージェント」という最も簡単な構成（LLMがツールを使ってタスクをこなす）から始めて、複雑になったら複数のエージェントを組み合わせる「マルチエージェント」に拡張していくことを推奨しています。 一方、「Big Workflows」は、処理の流れ（ワークフロー）をしっかりと設計し、各ステップを明確に定義するアプローチです。LangChainはこの考え方に近く、特にエージェントが次...
    Show More Show Less
    Less than 1 minute
  • 私立ずんだもん女学園放送部 podcast 20250509

    私立ずんだもん女学園放送部 podcast 20250509
    May 8 2025
    関連リンク AI エージェントを仕組みから理解する この記事は、AIエージェントやその仕組みに興味を持つ新人エンジニア向けに、エージェントがどのように動いているかを解説しています。 AIエージェントは、ファイル操作やWeb閲覧など、様々なツールを自律的に使って作業できます。しかし、その基盤となる大規模言語モデル（LLM）自体ができることは、実は「テキストを入力してテキストを出力する」だけです。AIエージェントの賢い動きは、LLMの能力に「仕組み」を組み合わせることで実現されています。 LLMには「記憶がない」という特性があります。過去の会話や情報は、LLMにリクエストを送る際に「コンテキスト」として毎回一緒に送ることで、文脈を維持しています。ただし、コンテキストには長さの制限があるため、必要な情報だけを選んで渡すことが重要です。 また、LLMは単独では外部のファイルやインターネットにアクセスできません。そこで、AIエージェントは「実行したいコマンド」をLLMにテキストで出力させ、その出力をプログラムが受け取って実際のツール（ファイル操作など）を実行する仕組みを使います。これは「Tool use」や「Function calling」と呼ばれ、AIエージェントの基本技術です。 さらに、様々なツールと効率的に連携するために、「MCP」という通信プロトコルが使われることがあります。これは、ツールの定義や実行を共通の形式で行うためのものです。 実際のAIエージェント（Roo Codeなど）は、LLMへの指示（システムプロンプト）と、これまでのやり取り（会話履歴）をコンテキストとして送ることで動作します。会話履歴には、ユーザーの入力だけでなく、エディタから取得した情報（例えば、ツール実行の結果や、コードのエラー情報）も含まれます。特にエラー情報をLLMにフィードバックすることで、エージェントがエラーを認識し、自動で修正できるようになります。 AIエージェントは、このようにLLMの基本能力を様々な仕組みで補い、拡張することで実現されています。過去わずか2年でLLMの性能（コスト、扱える情報量、速度）は劇的に向上しており、これが現在のAIエージェントの実用化を可能にしました。AIエージェントの仕組みを理解することは、現在の技術動向を追い、今後どのように進化していくかを考える上で役立ちます。 引用元: https://zenn.dev/dinii/articles/ai-agent-demystified ローカルRAGを手軽に構築できるMCPサーバーを作りました この記事は、最近注目されている「Model Context Protocol（MCP）」という技術と、LLM（大規模言語モデル）の応用技術である「Retrieval-Augmented Generation（RAG）」を組み合わせて、自分のローカル環境で使えるRAGシステムを簡単に構築するためのサーバを作った、という開発の紹介です。 RAGとは、あらかじめ用意したドキュメント（文章や資料など）の中から、AIが回答を作るのに役立つ情報を見つけ出し、その情報をAIに渡して回答を生成させる技術のことです。これにより、AIは学習データにはない、例えば社内資料のような特定の情報に基づいて、より正確で専門的な回答ができるようになります。 今回作成された「MCP RAG Server」は、このRAGを実現するための機能の一部である「ドキュメント検索」を担当するサーバです。AI（MCPホスト）からの問い合わせに対して、登録されたドキュメントの中から関連する情報を探し出し、その結果をAIに返します。このサーバはインターネット上のAIサービス（OpenAIなど）を使わないため、情報が外部に漏れる心配がなく、完全に自分のパソコンやネットワークの中で安全に利用できます。 このサーバを作るきっかけは、AIを使ったプログラミングツールなどで、自分のプロジェクトのコードやドキュメントをAIに賢く扱わせたい時に、手軽にドキュメント検索機能を使えるようにしたかったからです。 「MCP RAG Server」の主な特徴は以下の通りです。 いろいろな種類のドキュメント（文章、プレゼン資料、PDFなど）を扱えます。PostgreSQLというデータベースの機能を使って、ドキュメントの意味内容で検索できます。日本語を含む多くの言語に対応しています。新しく追加...
    Show More Show Less
    Less than 1 minute
  • 株式会社ずんだもん技術室AI放送局 podcast 20250508

    株式会社ずんだもん技術室AI放送局 podcast 20250508
    May 7 2025
    関連リンク AIエージェントCline、freeeはどうやって全社導入した？ freeeでは、GitHub Copilotなどに加え、特に開発スタイルを変える可能性を秘めたAIエージェント「Cline」の全社導入を進めています。この記事では、freeeがどのようにAIツールの本格導入に取り組み、どのような課題を乗り越えたのかが解説されています。 AIツールの導入は、従来のツールと異なり、セキュリティリスクやコスト管理など特有の難しさがあります。freeeではこれに対応するため、二つの仕組みを導入しました。一つは「AI特区制度」で、安全なサンドボックス環境などで一部のチームが限定的にツールを試すことで、現場での利用感や課題を素早く洗い出します。もう一つは「AI駆動開発チーム」で、特区で見つかった課題への対処や、全社導入のための基盤開発、ガイドライン策定、導入効果の測定などを担う専門チームです。 この体制のもと、freeeではまずAI特区でツールを検証し、うまくいきそうなものについて、特区で得た知見をもとに全社展開のためのガイドラインやセキュリティ基盤を整備し、その後全社へ展開・運用するという流れで進めています。 Clineの導入においては、主に三つの壁に直面しました。 一つ目は「セキュリティ」です。社内コードが学習に使われたり、機密情報が流出したり、危険なコマンドが実行されたりするリスクです。これに対しては、学習にデータが使われないAmazon Bedrockを採用し、さらに社内基盤に独自プロキシを立てて、機密情報のマスキングや危険なコマンドのブロックを行いました。 二つ目は「コスト」です。AIツールの多くは利用量に応じた課金で、コスト予測が難しい点が課題です。freeeでは、Amazon Bedrockにタグ付けしたり、プロキシでリクエストログを詳細に計測したりすることで、どのツールにどれだけコストがかかっているかをリアルタイムで監視・可視化し、利用状況や費用対効果を把握できるようにしました。 三つ目は「AIリテラシー」です。ツールは使い方で効果が大きく変わる上、誤った使い方をするとセキュリティリスクにもつながります。対策として、安全な利用を促す共通ルールの策定や、セキュリティリスクのある機能の利用制限、さらには既存のセキュリティ対策と組み合わせた多層的な防御を行っています。 freeeは今回のCline導入を通じて、AIツール導入にはリスクと効果を天秤にかけた判断や、システム的・組織的な専用対策が不可欠であること、またツールごとの特性に合わせた対策が重要であることを学びました。Clineは既に多くの開発者に利用されており、今後はより詳細な効果検証や、AIツール前提の開発フローへのシフトを目指していくとのことです。 この記事は、freeeがAIエージェントの全社導入にどう取り組み、技術的な課題や組織的な課題にどう向き合ったかを知る上で、非常に参考になる事例と言えるでしょう。 引用元: https://developers.freee.co.jp/entry/ai-cline-rolling-out I built an AI code review agent in a few hours, heres what I learned AIコードレビューエージェントを自作した経験に基づく記事です。PRの差分をLLMに送り問題点を見つけさせる仕組みで、GitHub Copilot Reviewなどの類似ツールと比較し、有用性を検証しています。基本的なエージェントは数時間で構築可能ですが、LLMは指示に従わないことがあり、コード全体の文脈理解が不十分だと的外れな提案をすることが課題です。記事では、市販のエージェントを利用するより、自社で完全に制御できるエージェントを開発するためのフレームワークの将来性に期待を寄せています。 引用元: https://www.sourcebot.dev/blog/review-agent-learnings 10分くらいでできるA2Aのはじめ方 この記事は、Google製のA2Aプロトコルを使った複数AIエージェント連携のチュートリアルを解説します。A2Aとは、異なるAIサービス（チャットボット、画像生成、為替変換など）を連携させるプロトコルです。 記事では、複数のエージェントをA2Aで接続し、統合チャットUIから対話・実行できるデモを構築する手順を説明します。セットアップ、APIキー取得、リモートエージェント（経費申請、画像生成、為替）、...
    Show More Show Less
    Less than 1 minute
  • 株式会社ずんだもん技術室AI放送局 podcast 20250507

    株式会社ずんだもん技術室AI放送局 podcast 20250507
    May 6 2025
    関連リンク DoomArena: A framework for Testing AI Agents Against Evolving Security Threats この論文は、「AIエージェント」と呼ばれる、私たちの代わりに様々な作業を自動で行ってくれるプログラムのセキュリティをしっかり評価するための新しい仕組み「DoomArena」について紹介しています。AIエージェントはこれから色々な場所で活躍が期待されていますが、もし悪意のある攻撃に弱かったら困りますよね。そこで、どんな脅威に対してどのくらい強いのかをテストすることがとても重要になります。 DoomArenaは、このセキュリティテストをもっとやりやすくするために、以下の3つの考え方で作られています。 プラグイン可能: Webサイトを操作するエージェントや、他のツールを呼び出して使うエージェントなど、現在ある様々なエージェントの実行環境に簡単に追加して使えます。設定可能: どんな部分を攻撃対象にするか、どのような脅威を想定するか（例えば、悪いユーザーが操作する場合か、エージェントが使っている環境自体が悪い場合かなど）を細かく設定できます。モジュール式: 攻撃手法自体と、その攻撃をどの環境で実行するかを分けられるので、一度作った攻撃を色々な種類のエージェントや環境に対して試すことができます。 DoomArenaを使うことで、新しい種類の脅威にも対応しやすくなったり、これまでに考えられていた様々な攻撃手法を組み合わせて、より厳しく、きめ細かいセキュリティテストができるようになります。また、エージェントが持つ様々な弱点（脆弱性）と、本来の性能とのバランス（トレードオフ）を分析することも可能です。 このフレームワークを使って、現在最新のAIエージェントをテストしたところ、いくつか面白いことがわかりました。 最新のエージェントでも、想定する脅威の種類（悪意のあるユーザーによるものか、環境によるものかなど）によって、どのくらい脆弱かが異なり、全ての脅威に対して完璧に強いエージェントは見つかりませんでした。複数の攻撃を同時に仕掛けると、個別の攻撃よりもずっと効果的になる場合が多いです。特定のルール（ガードレール）で動きを制限するような簡単な防御策は効果が薄い傾向がありましたが、高性能な最新のAIモデル（LLM）を使った防御策はより有効なようです。 このDoomArenaフレームワークは公開されており、AIエージェントの開発者やセキュリティに関心のあるエンジニアが利用できるようになっています。AIエージェントをより安全に開発していく上で役立つツールと言えるでしょう。 引用元: https://arxiv.org/abs/2504.14064 LLM Performance Benchmarking: Measuring NVIDIA NIM Performance with GenAI-Perf LLM（大規模言語モデル）を使ったアプリケーションを開発する際、その性能を把握することは非常に重要です。これは、どこに改善の余地があるかを見つけたり、サービス品質（レイテンシなど）と処理能力（スループット）のバランスを調整したり、どれくらいの数のサーバーが必要かを見積もったりするために役立ちます。 この記事では、LLMの性能を測るためのツール「NVIDIA GenAI-Perf」と、NVIDIAが提供するLLM推論サービス「NVIDIA NIM」を組み合わせてMetaのLlama 3モデルの性能を評価する方法が解説されています。 GenAI-Perfは、LLMサービスの応答性能をクライアント側から測定できるツールです。具体的には、最初の単語が表示されるまでの時間（Time to First Token: TTFT）、単語が出てくる間隔（Inter-token latency: ITL）、1秒あたりの単語数（Tokens per second: TPS）、1秒あたりのリクエスト数（Requests per second: RPS）といった重要な指標を測ることができます。GenAI-Perfは業界標準となっているOpenAI APIの仕様に準拠した多くのLLMサービスに対応しています。 NVIDIA NIMは、LLMを素早く簡単に、そして高性能に動かすためのソフトウェアパッケージです。高性能なLLM（例えばLlama 3）をOpenAI API互換の形式で提供できるのが特徴です。 記事では、実際にNIMを使ってLlama 3モデルを起動し、次にGenAI-Perfを使って性能を測定する手順が紹介されています。具体的なコマンド例や、入力や出力の文章の長さ、同時に処理するリクエスト数（同時接続数）...
    Show More Show Less
    Less than 1 minute
  • 私立ずんだもん女学園放送部 podcast 20250502

    私立ずんだもん女学園放送部 podcast 20250502
    May 1 2025
    関連リンク ClineとDDDと私 この記事は、「AIちょっと苦手おじさん」だった筆者が、AIエージェント「Cline」を使い始めた経験と、開発現場での具体的な活用方法について紹介しています。特に、DDD（ドメイン駆動設計）などの考え方を取り入れた保守性の高いコードベースが、AI活用にいかに重要であるかを強調しています。 筆者は、VSCode拡張機能のClineを、GitHub Copilot経由でClaude 3.5 Sonnetモデルと組み合わせて使用しています。最初はタスクの指示の粒度や効率的な進め方に悩みましたが、試行錯誤の結果、効果的な使い方が見えてきました。 AIに開発タスクを任せる上で、なぜ保守性の高いコードが重要なのでしょうか。それは、AIが正確なアウトプットを出すために必要な「コンテキスト情報」を小さく抑えることができるからです。複雑な全体像を知らなくても、特定の小さな部分だけを理解すれば作業できるようなコード（「コンテキストの局所化」）は、AIにとっても扱いやすいのです。DDDやクリーンアーキテクチャは、関心事を分離し、このコンテキストを局所化するのに役立ちます。 また、AIは自然言語で学習しているため、クラス名やメソッド名から振る舞いが予想しやすい、いわゆる「自然言語としての可読性が高い」コードは、AIにとっても理解しやすく、期待通りのコードを生成する可能性が高まります。現時点では、「AIフレンドリーなコード」は「人間が読みやすいコード」とほぼ同じだと言えるでしょう。 具体的なタスク分担の例として、新規機能開発におけるバックエンド（SpringBoot/Kotlin）とフロントエンド（React/TypeScript）でのClineの活用が紹介されています。 バックエンドでは、 UseCase（アプリケーションロジック）のユニットテスト実装Controller（UI層とUseCaseの連携）の実装Repository（ドメイン層とインフラ層の連携）の実装 といった、定型的な作業やモック設定が面倒な部分をClineに任せています。特に、DDDにおけるレイヤードアーキテクチャによって関心事が分離されていることが、AIに任せやすいタスクの切り出しに繋がっています。 フロントエンドでは、 デザインシステムに基づいたコンポーネントライブラリの実装アプリケーション固有の個別コンポーネント（API連携やフォーム処理など）の実装 などに活用しています。React/TypeScriptはVSCodeとの連携やAIモデルの学習量の多さから、より良いコード生成が期待できるようです。 Clineを効果的に使うためのTIPSとして、以下の点が挙げられています。 参考にしたい既存コードをVSCodeで開いておく（AIが参照しやすくなる）Plan（計画）段階でAIの応答を確認し、指示を調整してからAct（実行）する.clinerulesファイルにプロジェクト共通のルールを記述しておくClineとのやり取りを記録・共有する（振り返りやナレッジ共有のため）Clineに「キャラ付け」して楽しく使う まとめとして、DDDのようなレイヤードアーキテクチャによる関心事の分離は、AIが必要とするコンテキストを減らし、効率的なタスク分担を可能にすることが筆者の経験から分かったそうです。AIの進化にも期待しつつ、今後も人間が理解しやすい「ヒューマンリーダブルなコードベース」を維持していくことの重要性を改めて認識しています。新人エンジニアの皆さんも、こういったAIツールを使いこなし、開発をより効率的で楽しいものにしていきましょう。 引用元: https://tech.codmon.com/entry/2025/05/01/132700 AIエージェントを使って実際にアプリ開発→リリースした経験・知見を共有する この記事では、AIエージェント「Claude Code」を使ってiOSアプリ「電光石火」を実際に開発・リリースした経験から得られた知見が共有されています。AIによるコーディングツールは増えていますが、プロダクトとして完成させた例はまだ少ないため、実践的な情報として参考になります。 著者が感じたAIエージェントの最大のメリットは、開発速度の向上です。体感で通常の3〜5倍速く開発できたとのこと。簡単な指示で動くコードをすぐに生成できるため、ゼロから考えるよりも、まずAIにたたき台となるコードを書かせ、それをベースに作業を進めるのが非常に...
    Show More Show Less
    Less than 1 minute