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

この記事は、Microsoft Build 2025で発表されたGitHub Copilot Coding Agentという新機能を実際に試した体験談です。この機能は、開発者がGitHubのIssueにAIをアサインするだけで、コーディングなどのタスクをAIが自律的に行い、Pull Request（PR）を作成してくれるという画期的なものです。

著者は、この機能を使ってブログ記事を書いてもらうというタスクを試しました。手順は以下の通りです。

すると、驚くべきことに、CopilotはすぐにIssueを理解し、リポジトリの構造を把握した上で、ブログ記事の執筆（ファイルの作成と編集）を始めました。数分後には、ブログ記事の内容を含む新しいPRが自動で作成されていました。

作成されたPRを著者がレビューし、「Copilotが書いたものであることを示す」「日付を修正する」「細かい表現を直す」といったコメントを残すと、Copilotはそれらのコメントを理解し、数分で修正済みのPRを自動で作成し直しました。まるで人間とやり取りしているかのように、レビューコメントに対して適切な対応をしてくれたのです。

この体験を通じて、著者はGitHub Copilot Coding Agentの「やばさ」を実感しました。Issueを作成してCopilotをアサインし、レビューと指示を少し与えるだけで、タスクの実行からPR作成、さらにレビューコメントへの対応まで、開発の一連の流れをAIがほぼ自動でこなせるようになったからです。

特に、検証作業などの際に、その結果をブログやドキュメントとしてまとめる作業は手間がかかりますが、このAgent機能を使えば、検証そのものに集中しつつ、記録を残す作業をAIに任せられる可能性を感じています。

最新のAI技術、特にAI Agentが、実際の開発現場でどのように活用され、私たちの働き方を効率化していくのかを示す非常に実践的な事例と言えるでしょう。新人エンジニアの皆さんにとっても、AIと協力して開発を進める未来を想像するきっかけになれば幸いです。

引用元: http://www.kentsu.website/ja/posts/2025/copilot_coding/

VoltAgentは、TypeScriptを使ってAIエージェントを作るための便利なツールキットです。新人エンジニアの皆さんも、これを使えばAIを活用したアプリケーション開発に挑戦しやすくなります。

このツールキットの大きな特徴は、作ったAIエージェントの動きを見たり、問題がないか調べたりするための「VoltAgent Console」というツールがセットで提供されている点です。これを使うと、エージェントが今どんな状態なのかリアルタイムで確認したり、どのように処理が進んでいるのかをグラフで見て理解したりできます。開発中に「あれ？思った通りに動かないぞ？」という時に原因を探りやすくなります。

AIエージェントの基本的な構成要素は「Agent」というクラスです。このAgentクラスに、名前や役割、使うAIモデルなどを設定して、エージェントを定義します。VoltAgentは、OpenAIやGoogle Geminiなど、いろいろなAIモデルを使えるようにするための仕組み（プロバイダー）を提供しているので、モデルごとの細かい違いを気にせず開発を進められます。

また、AIの「知識不足」や「リアルタイム情報の弱さ」を補うために、「ツール」という仕組みを使ってエージェントの能力を拡張できます。例えば、最新の天気予報を取得するツールを作ってAIに連携させれば、「明日の天気は？」という質問にも正確に答えられるようになります。複数のツールをまとめて「Toolkit」として管理することも可能です。さらに、「Model Context Protocol (MCP)」という業界標準の仕組みにも対応しているので、ブラウザ操作やカレンダー連携など、外部の様々なサービスとAIエージェントを連携させるのも比較的容易です。

複雑なAIエージェントを作る時には、「サブエージェント」という考え方が役立ちます。これは、全体を管理する「スーパーバイザーエージェント」の下に、情報収集担当、文章生成担当、編集担当、といった形で役割を分担した専門エージェントを配置する仕組みです。これにより、大きなタスクを小さなタスクに分けて、開発や管理がしやすくなります。

AIエージェントは、通常、過去の会話を覚えていませんが、VoltAgentには「メモリ」機能があり、会話履歴を保存して、ユーザーとのやり取りを記憶させることができます。これにより、より自然でパーソナルな会話が可能になります。

開発したエージェントが期待通りに動いているか確認したり、問題発生時に原因を特定したりするために、「オブザーバビリティ（可観測性）」も重要です。VoltAgent Consoleを使えば、エージェントの実行ステップを追跡（トレース）して、各ステップでの入力や出力を確認できます。

このようにVoltAgentは、AIエージェントの開発に必要な基本的な要素から、監視・デバッグ、外部連携、複雑な構造の構築、記憶、追跡といった、幅広い機能を提供しており、TypeScriptでのAIアプリケーション開発を効率的に進めるための強力なツールキットと言えます。

引用元: https://azukiazusa.dev/blog/typescript-ai-agent-voltagent

皆さん、Google I/O 2025でたくさんの新しい技術やサービスが発表されました！特にAI分野の進化が目覚ましく、開発者にとっても非常に刺激的な内容でした。

今回の発表の中心は、やはりGoogleのAIモデル「Gemini」の進化です。主要モデルであるGemini 2.5 ProとFlashがアップデートされ、より賢く、効率的になりました。Gemini 2.5 Proでは「Deep Think」という新しい機能が試験的に導入され、より複雑な問題を深く考えて解けるようになったそうです。また、Gemini APIではテキストだけでなく、音声で応答を生成する機能も追加され、より多様な使い方ができるようになりました。

開発者向けのツールも充実しました。コーディング支援AI「Gemini Code Assist」が正式リリースされ、VS CodeやJetBrainsなどの主要な開発環境で利用できるようになりました。さらに、自律的にコードを作成したりバグを修正したりできるコーディングエージェント「Jules」が全世界向けに公開ベータとなりました。試用期間は無料とのことなので、ぜひ触ってみると良いかもしれません。

他にも、GoogleはAIを活用した様々な新しいサービスを発表しています。ウェブサイトの内容を深く掘り下げて教えてくれるAI検索ツール「AI Mode」や、自然言語の指示や画像から高品質な映像を生成できる「Flow」、医療分野に特化したオープンなマルチモーダルAIモデル「MedGemma」などが紹介されました。また、モバイル端末上でのAI実行を効率化するランタイム「LiteRT」や、自然言語や画像からUIデザインとフロントエンドコードを生成する「Stitch」といった、開発を助けるツールも登場しています。

AI生成コンテンツの信頼性を高める取り組みとして、「SynthID Detector」という、AIが作ったテキストや画像、音声、動画に埋め込まれた透かしを検出する技術も発表されています。

これらの発表の多くは、まだ米国限定であったり、一部機能のみの公開であったりしますが、AI技術が私たちの開発や日々の生活をどのように変えていくのか、その可能性を感じさせる内容ばかりでした。特にAIエージェントの開発や、Geminiの様々な応用に関心がある新人エンジニアの皆さんは、ぜひこれらの情報を追いかけてみてください。

引用元: https://zenn.dev/schroneko/articles/google-io-2025

プログラマーが日常会話で細部にこだわるのは、RFCのような厳密なルールやソースコードの例外処理を考える仕事の習慣が原因では？という説です。これは性格が悪いのではなく、物事を正確に理解しようとする訓練の表れ。会話を「MUST」か「SHOULD」かで捉えたり、条件の「else」を考えてしまったり。仕事で誤解なく進めるための思考癖が日常に出ているだけ、と思えば、先輩の話し方も面白く感じられるかもしれません。

引用元: https://blog.sushi.money/entry/2025/05/21/221742

（株式会社ずんだもんは架空の登場組織です）

GitHub Copilotに、開発タスクを自動でこなす新しい機能「コーディングエージェント」が登場しました。これは、GitHubに直接組み込まれたAIアシスタントのようなもので、特定の開発作業を任せることができます。

使い方は簡単です。GitHubのIssue（課題や要望などを管理するもの）に、このCopilotコーディングエージェントを割り当てるだけ。すると、エージェントはバックグラウンドで作業を開始します。具体的には、GitHub Actionsという仕組みを使って一時的な開発環境を作り、コードの分析や変更を行います。

エージェントが行った作業は、自動的にドラフトのプルリクエストとして提出されます。プルリクエストとは、コードの変更内容をチームメンバーに確認してもらうための機能です。ここが重要なポイントで、エージェントが勝手にコードを最終的に確定させるのではなく、必ず人間（あなたやチームメンバー）が変更内容を確認し、承認してからコードが取り込まれる仕組みになっています。既存のセキュリティルールもそのまま適用されるため、安心して使えます。

このエージェントは、機能追加やバグ修正、テストコードの作成、コードの整理（リファクタリング）、ドキュメントの改善など、比較的シンプルから中程度の複雑さのタスクを得意としています。

この機能の最大のメリットは、開発者が時間のかかる単調な作業をエージェントに任せられる点です。これにより、あなたはより創造的で、頭を使う必要のある難しい作業に集中できるようになります。ちょうど、自分専用のAIアシスタントが、コードを書く準備や簡単な修正を手伝ってくれるようなイメージです。

エージェントは、Issueの内容だけでなく、リポジトリのこれまでの変更履歴や議論、さらには画像（バグのスクリーンショットなど）も解析して作業を進めることができます。作業の進捗やエージェントがどう考えたかのログも確認できます。

このコーディングエージェントは、GitHub Copilot EnterpriseおよびCopilot Pro+の契約者が利用できます。

GitHub Copilotは、この新しいエージェント機能も含め、開発者がコードを書く際の集中力（フロー状態）を維持し、面倒な作業を減らし、開発をもっと楽しく、効率的にすることを目指しています。

これにより、日々のコーディング作業がどのように変わっていくか、ぜひ試してみてください。

引用元: https://github.blog/jp/2025-05-20-github-copilot-meet-the-new-coding-agent/

大規模言語モデル（LLM）の急速な進化により、「Agent（エージェント）」と呼ばれる新しいタイプのAIアプリケーションが注目されています。この「Principles of Building AI Agents」という書籍は、AI Agentをどう作っていくか、その基本原則を分かりやすく解説したものです。Web開発の経験豊富なベテランが、誇張や流行語を避け、本質的な内容に焦点を当てて書かれています。

この本を読むことで、AI Agent構築の全体像や、必要な技術要素の基礎を学ぶことができます。

まず、AI Agentがどのように構成されているか、その主要な「部品（building blocks）」について解説されています。これには、Agentに様々な機能を提供する「プロバイダー」、Agentの賢さの元となる「モデル（LLMなど）」、Agentに具体的な指示を与える「プロンプト」、Agentが外部のサービスやデータを利用するための「ツール（API連携など）」、そしてAgentが過去のやり取りや情報を覚えておくための「メモリ（短期記憶や長期記憶）」などが含まれます。これらの要素を適切に組み合わせることで、Agentはより高度で人間のような振る舞いをできるようになります。

次に、Agentに複雑な目標を達成させるための考え方として、「Agent的なワークフロー」によるタスクの分解方法が紹介されています。大きなタスクを細かなステップに分け、各ステップでAgentが思考し、行動を選択していくような流れを作ることで、より難しい課題にも対応できるようになります。

さらに、Agentが最新の情報や、学習データには含まれていない特定の知識（例えば、会社の内部資料や専門分野のデータ）を利用できるようにする重要な技術として、「RAG（Retrieval-Augmented Generation：検索拡張生成）」が解説されています。RAGを使うと、Agentは質問やタスクに関連する情報を外部の知識ベースから検索し、その検索結果を参考に回答を生成したり、次の行動を決定したりすることができます。これにより、Agentはより正確で、文脈に即した情報を提供できるようになります。

この書籍は、AI Agent開発の基礎となる構成要素や考え方を、実践的な視点から分かりやすく解説しており、これからAI Agent開発にチャレンジしたいと考えている新人エンジニアにとって、良い指針となるでしょう。

引用元: https://mastra.ai/book

Googleは、LLMモデルであるGemini 2.5 ProとGemini 2.5 Flashをさらに進化させたことを発表しました。

まず、上位モデルのGemini 2.5 Proは、特にコーディング分野での性能が向上し、「WebDev Arena」や「LMArena」といった評価指標でトップクラスの成績を収めています。さらに、教育に特化したLearnLMの技術を取り込むことで、学習支援においても優れた能力を発揮するようになりました。

一方、高速・低コストが特徴のGemini 2.5 Flashも多くの面で改善されました。推論、マルチモーダル（テキスト以外のデータ理解）、コード生成、長い文章の処理能力が向上しつつ、さらに効率的になり、使用するトークン数を削減しています。

Gemini 2.5の全モデル（ProとFlash）に共通の新機能も追加されました。

開発者体験も改善されています。

これらのアップデートにより、Gemini 2.5モデルはより高性能に、より安全に、そして開発者にとってより使いやすいものとなっています。Gemini 2.5 Flashのアップデート版は既にプレビューとして利用可能で、Proと共に順次正式リリースされる予定です。

引用元: https://blog.google/technology/google-deepmind/google-gemini-updates-io-2025/

ガストなどで働く猫型配膳ロボット「ベラボット」は、人手不足解消や効率化のために導入されました。しかし驚くべきことに、単純作業をロボットが担うことで従業員の負担が減り、より接客に集中できるようになった結果、多様な人材の採用が増えるという意外な効果が生まれました。テクノロジーは、現場の働きやすさを向上させ、採用にもプラスの影響を与える可能性がある好事例と言えます。

引用元: https://toyokeizai.net/articles/-/877785?display=b

（株式会社ずんだもんは架空の登場組織です）

AI（大規模言語モデル、LLM）の進化は目覚ましく、最近では指示を受けて作業するだけでなく、自律的に様々なツールを使って一連の仕事をこなす「AIエージェント」が注目されています。

これまで、AIエージェントに外部のツール（例えばファイル操作やWebサービスのAPI）を使わせるには、連携したいツールごとに個別のプログラムを作る必要がありました。これはたくさんのツールを使おうとすると、とても大変でコストがかかる作業でした。

そこで登場したのが「MCP（Model Context Protocol）」です。これは、AIモデルと外部のツールやサービスを連携させるための「共通の決まりごと（標準プロトコル）」です。例えるなら、パソコンと様々な周辺機器をつなぐ「USB-Cポート」のようなものです。

MCPが普及すると、ツール側がMCPに沿った「MCPサーバー」を用意すれば、AIエージェントを作る人は、どのAIモデル（ChatGPTやClaudeなど）やどの開発環境（CursorやVS Codeなど）を使っても、同じやり方でそのツールを使えるようになります。これにより、AIエージェントの開発が効率化され、作った連携機能も再利用しやすくなります。

MCPの仕組みは、AIアプリや開発環境である「MCPホスト」、ホスト内で動いてツールと連携する指示を出す「MCPクライアント」、そして実際のツール操作を行う「MCPサーバー」という役割分担になっています。MCPによって、AIエージェントは外部の「ツール（アクション実行）」、「リソース（データ取得）」、「プロンプト（定型指示）」などの機能を使えるようになります。

現在、CursorやClaude Desktop、n8nなど様々なAI関連ツールがMCPをサポートし始めており、GitHubやSlackなどのMCPサーバーも増えてきています。

ただし、インターネット上で公開されているMCPサーバーの中には、悪意のあるプログラムが混じっている可能性もゼロではありません。特に、知らない人が作ったサーバーを使う場合は注意が必要です。安全に使うためには、公式や信頼できる開発元のものを選ぶ、多くの開発者が参加しているものを使う、そして可能であればAIにコードの安全性をチェックしてもらうなどの対策が大切です。

MCPはまだ新しい技術ですが、AIエージェントが外部と連携する方法を標準化することで、今後のAIによる自動化や新しいAIアプリケーション開発を大きく加速させる可能性を秘めています。Googleが提唱するA2A（Agent to Agent）のように、AIエージェント同士が連携する仕組みも出てきており、今後の動向に注目です。

引用元: https://blog.cloudnative.co.jp/27994/

AWSがオープンソースのAIエージェント開発用SDK「Strands Agents」を発表しました。AIエージェントとは、大規模言語モデル（LLM）がプロンプト（指示）を受け取り、外部ツールを使ってタスクを自律的に実行するプログラムのようなものです。

これまでのAIエージェント開発では、LLMの応答を解析し、どのツールを呼び出すかなどを細かく制御する複雑な「オーケストレーション」が必要でした。しかし、最近のLLMは推論やツール利用の能力が向上しており、モデル自身が次のステップを計画し、適切なツールを選択できるようになっています。

Strands Agentsは、この「モデル中心」のアプローチを採用することで、AIエージェント開発をシンプルにすることを目指しています。開発者は、エージェントに与える「プロンプト」と、エージェントが使える「ツール」を定義するだけで、基本的なエージェントを作成できます。まるでDNAの二重らせんのように、モデルとツールという二つの要素をStrandsがつなぎ合わせ、モデルが自らの判断でツールを使ってタスクを完了させます。

Strandsの大きな特徴は以下の通りです。

AWS社内でもAmazon Q Developerをはじめ、複数のチームでStrandsを使ったAIエージェントが本番稼働しており、開発期間の短縮に貢献しているとのことです。

クラウドでAIエージェントの開発を始めてみたい日本のエンジニアにとって、Strands Agentsは強力な選択肢となりそうです。オープンソースなので、ぜひGitHubでコードを触ってみることから始めてみてはいかがでしょうか。

引用元: https://aws.amazon.com/blogs/opensource/introducing-strands-agents-an-open-source-ai-agents-sdk/

この記事は、AIエージェントツール「Cursor」のRules機能を活用して、エージェントの精度を向上させる方法を、特に新人エンジニア向けに分かりやすく解説しています。

CursorエージェントのRules機能では、エージェントの動作ルールを定義できます。前回は簡単な使い方を紹介しましたが、今回はさらに高精度にするためのテクニックとして、「YAML形式」でのルール記述が紹介されています。

YAMLは「YAML Ain’t Markup Language」の略で、AIが理解しやすいように構造的に書くためのフォーマットです。改行やインデント（字下げ）で階層を表現し、人間が読みやすいのが特徴です。MDCというCursorが利用するファイル形式でもYAMLは有効です。

なぜYAMLが必要かというと、AIは自然言語での指示だけでは解釈がブレやすく、特に複数のステップや条件分岐がある場合に、質問の順序を変えたり、ユーザーの確認を待たずに進めたりといった「誤読」が起こりやすいからです。一方、YAMLでステップごとにアクションや条件を明確に定義することで、AIは曖昧な解釈をせず、安定して一貫した動作を再現できます。例えば、夕食準備の例で、シンプル指示とYAML形式を比較し、YAMLの方が質問や確認の順序が安定することを示しています。

RulesファイルをゼロからYAML形式で作成する手順の概要が解説されています。まずエージェントに何をしてほしいか自然言語で明確にし、次にトリガーワードと大まかなステップをリスト化します。その後、必要な質問セットや、AIが生成するファイルのテンプレートを定義します。そして、各ステップに具体的なアクションや条件を書き込んで詳細化します。この手順は夕食準備エージェントを例に進められ、GitHubでサンプルリポジトリが公開されており、クローンして試すことができます。

Ruleファイルをより効果的にするための工夫として、以下の点が挙げられています。

ただし、どんなタスクでもYAMLが最適というわけではなく、単発の簡単なタスクならシンプルプロンプトで十分です。複雑さが増すほどYAMLが有効になります。タスクの規模に応じて適切な方法を選ぶことが重要です。

YAMLによる構造化は一見手間がかかりますが、Cursorエージェントの正確性が向上し、繰り返し行うタスクにおいてブレなく安定した動作を実現できます。これにより、自分専用の頼れるAIアシスタントを育てることが可能になります。この記事で紹介されたサンプルやテクニックを参考に、Cursorエージェントを使いこなしてみてください。

引用元: https://note.com/miyatad/n/n18cfb4a4036c

話題の音声合成キャラクター「ずんだもん」の新曲「ずんだBOP～あたまがずんだもち～」が、5月18日から各種音楽配信サービスで聴けるようになりました。パンクやロックの楽しい曲で、エンジニアの皆さんの息抜きにもおすすめです。

引用元: https://magazine.tunecore.co.jp/newrelease/508228/

（株式会社ずんだもんは架空の登場組織です）

OpenAIが、ソフトウェア開発のタスクを自動化する新しいAIエージェント「Codex」のリサーチプレビューを公開しました。これは、プログラムを書いたり、デバッグしたりといったエンジニアの作業をAIが手伝ってくれるツールです。

Codexはクラウド上で動作し、安全な仮想環境（サンドボックス）の中でタスクを実行します。複数の作業を同時に進めることも可能です。現在はChatGPTのPro、Team、Enterpriseプランで利用でき、今後PlusやEduプランにも対応予定とのことです。

Codexには主に「codex-1」と、軽量版の「codex-mini-latest」というモデルがあります。タスクの完了には1分から30分程度かかり、AIがどのような手順で作業しているかをリアルタイムで見ることができます。

セキュリティにも配慮されており、悪意のあるコードの作成や不正な指示は拒否されます。また、タスク実行中は外部インターネットへのアクセスが無効になるよう設計されています。

CodexはGitHubとの連携機能も持ち、Web UIから直接プルリクエストを作成することも可能です。

筆者は実際にChatGPT Proを契約してCodexを試しており、Web UI版では簡単な指示でテトリスを完成させるなど、その便利さに期待を感じています。複数のタスクを並行で実行させたり、外出中にスマホから作業指示を出したりといった使い方の可能性にも触れています。

一方で、コマンドラインから使う「Codex CLI」と軽量モデル「codex-mini-latest」を試した際は、エラーが発生したり、応答が遅いと感じる場面もあったようです。Codex CLIではChatGPTアカウントでのサインインが可能になり、特定の有料プラン契約者はAPIクレジットがもらえるキャンペーンも実施されています（ただし有効期限や条件あり）。しかし、筆者はCodex CLIの軽量モデルについては現時点では少し課題があると感じているようです。

全体として、筆者はCodex本体（特にWeb UI版）には今後の可能性を感じており、引き続き使っていきたいと考えているようです。多様なAIサービスを展開するOpenAIの強みも改めて評価しています。

引用元: https://zenn.dev/schroneko/articles/introducing-codex

VoltAgentは、TypeScriptを使ってAI Agentを開発するためのオープンソースフレームワークです。AI Agentとは、AI（人工知能）に特定のタスクを自動で実行させるためのプログラムのようなものです。VoltAgentを利用することで、プログラミングの知識がなくても使えるノーコードツールの機能的な限界を超えたり、AI Agentをゼロから手作りする際に発生する大きな開発コストや複雑さを軽減できます。エンジニアは、自分のコードでAI Agentの振る舞いを完全に制御し、ビジネス要件に合わせて柔軟にカスタマイズ、そして様々なシステムと連携させることができます。開発者の使いやすさ（Developer Experience, DevEx）も重視されており、快適に開発を進められます。

このフレームワークの主な特徴をいくつかご紹介します。まず、「ツール呼び出し（Tool calling）」機能です。これにより、開発したAI Agentが外部のAPIやデータベース、他のサービスなどと連携し、情報を取得したり、特定の操作を実行したりといった具体的なアクションを取ることが可能になります。次に、「Unified API」機能は、OpenAIやその他の様々なAIモデルプロバイダーを、同じ統一された方法でコードから利用できるようにするものです。これにより、特定のAIモデルに依存せず、状況に応じて最適なモデルを選んだり切り替えたりすることが容易になります。

さらに、「動的プロンプト（Dynamic Prompting）」機能を使うと、AI Agentへの指示文であるプロンプトを柔軟に管理し、テストや調整を繰り返しながらAIの応答性能を改善していくことができます。「永続メモリ（Persistent Memory）」機能は、AI Agentが過去のユーザーとのやり取りや取得した情報を記憶しておき、会話の文脈を理解したり、以前の状況を踏まえた応答を生成したりするのに役立ちます。

VoltAgentは、これらの機能に加えて、40種類以上の外部アプリやサービスとの連携を容易にする仕組みを提供しています。また、「Observability（可観測性）」機能が充実しており、開発したAI Agentがどのように動作しているか、デバッグ情報や実行ログなどを詳細に確認できます。これにより、問題が発生した場合の原因特定や、AI Agentの挙動改善が効率的に行えます。デプロイ機能も用意されており、開発したAgentをすぐに利用開始できます。

これらの強力な機能を備えたVoltAgentは、個人開発から企業での大規模な利用（エンタープライズレベル）まで対応できる、堅牢で信頼性の高いAI Agentを構築するための包括的なツールキットと言えます。TypeScriptの経験がある新人エンジニアにとっては、AI Agentという新しい分野に挑戦し、その開発・運用プロセスを実践的に学ぶための優れたスタート地点となるでしょう。

引用元: https://voltagent.dev/

この記事は、2025年が「Agent元年」と呼ばれ、AI（人工知能）が私たちの代わりに様々な作業を行う「LLM Agent」の開発が急速に進んでいる中で、注目すべき3つの技術を紹介しています。まるで「幕の内弁当」のように、Agent開発に必要な様々な要素が詰まった情報源となっています。

特に大切なのは、Anthropicの「MCP」、OpenAIの「Agent SDK」、Googleの「A2A Protocol」という技術です。これらはAgentシステムを作る上で、それぞれ異なる役割を持っています。

まず「MCP (Model Component Protocol)」は、LLMがインターネット上のサービスやデータベースなどの「外部の道具（ツール）」を安全に使うための「共通のお約束事（プロトコル）」です。これがあれば、色々なツールがLLMから使いやすくなり、セキュリティも高まります。

次に「OpenAI Agent SDK」は、LLMを使ってAgentを簡単に作るための「開発キット」です。Agentに「何をすべきか」を指示したり、他のAgentに仕事を「お願いしたり（Handoffs）」、間違った指示がないか「チェックしたり（Guardrails）」する機能があります。Agentがどう動いたかを追跡できる機能（Tracing）も便利です。

そして「A2A Protocol (Agent2Agent)」は、異なる会社や仕組みで作られた複数のAgent同士が「お互いに理解し合って」コミュニケーションを取るための「共通の言葉」です。MCPがAgentとツールの連携を助けるのに対し、A2AはAgent同士が協力して、もっと複雑なタスクをこなせるようにするためのものです。

これらの技術が登場したことで、Agent開発のルールが整理され、Agent同士やAgentとツールがスムーズに連携できるようになることが期待されています。これにより、私たちはもっと便利で賢いAI Agentを使えるようになるかもしれません。Agent開発を始める新人エンジニアにとって、これらの技術の存在とそれぞれの役割を知っておくことは、これからの開発を理解する上でとても役立つでしょう。

引用元: https://zenn.dev/cha9ro/articles/2025_intro_to_agent_and_mcp

子育て中のエンジニア向けに、仕事中に子どもが部屋に来ても楽しく対応できるTipsを紹介。ターミナルで汽車や牛のアスキーアートを表示するコマンド（sl, cowsayなど）や、VSCodeに動物を出す拡張機能などを解説します。仕事道具を遊びに変えて、お子さんとクスっと笑えるひとときを！色々なアイデアを試して反応を楽しめます。

引用元: https://zenn.dev/jy8752/articles/9257ef88fcbf0e

VOICEVOX:春日部つむぎ

この記事は、AIエージェントとModel Context Protocol (MCP) を活用して、SNSであるBluesky上にまるで人間のような「架空の友達」を作成し運用する技術的な実験について紹介しています。投稿者は、AIがSNS上で人間と区別がつかなくなるのかを検証することを目指しました。

実験では、AIエージェントとしてOpenAI Agents SDKを使用し、BlueskyのAT Protocolと連携させるためのMCPサーバーをRust言語で自作しました。これは、既存のMCPサーバーでは必要な機能（ユーザーへの通知取得など）が不足していたため、また自作することでGitHub Actionsなどから扱いやすいバイナリを生成できるメリットがあったためです。Blueskyとの通信には、筆者が開発しているATriumというライブラリが使われています。

AIエージェントに個性を持たせるため、詳細なプロフィールを持つ二種類の架空の人格（ソフトウェアエンジニアとプリキュア好きのギャル）を作成しました。これらの人格情報に基づいて、AIエージェント自身にSNSアカウントの名前や自己紹介を考えさせ、定期的な投稿や他のユーザーからの返信への応答を行わせました。投稿内容や返信するかどうかの判断も、AIがその人格になりきって行うように指示されています。

この実験から得られた重要な知見として、LLMは自然な文章生成やある程度の判断はできるものの、「AをしてからBを行う」「特定の条件を満たした場合のみ行う」といった、順序や条件分岐を含む複雑な処理を正確に実行させるのが難しい点が挙げられています。例えば、「自分への未返信メンションにだけ返信する」という指示をLLMに任せると、過去のメンションにも誤って返信してしまう可能性がありました。これを解決するため、MCPサーバー側に「未返信のメンションだけを抽出してAIに渡す」といった専用の処理を実装し、LLMはその結果を使って投稿を生成するようにしました。このように、LLMに任せる部分と、プログラム側で厳密に制御する部分を切り分ける設計の重要性が示されています。

現在運用中のAIアカウントは、それぞれの個性を反映した投稿をしていますが、まだ人間らしさに欠ける部分もあります。今後は、外部の最新情報を取り込んだり、過去の発言との一貫性を高める工夫（例：「日記」を事前生成する）、知識の偏りをなくすための外部知識ソース（RAGなど）の活用などが課題として挙げられています。

この取り組みは、AIエージェントの応用可能性を示唆しており、LLMの進化がSNS上のコミュニケーションにどのような影響を与えるか、興味深い一歩となるでしょう。

引用元: https://memo.sugyan.com/entry/2025/05/15/090000

サンフランシスコで開催されたAIエージェント開発イベント「LangChain Interrupt」のDay 1レポートです。この日は、メール対応エージェントを作るハンズオンを中心に、LangChainの主要な技術要素を学びました。日本の新人エンジニアの皆さんにも役立つ内容です。

イベントのテーマは「アンビエントエージェント」。チャットだけでなく、裏側で動いて継続的に複数の処理を行うエージェントの可能性が示されました。

LangGraphでエージェントの動きを設計

実際の活用事例（Cisco）

エージェントを「賢く」「実用的に」

開発からデプロイまで

このレポートから、AIエージェント開発には単にAIを呼び出すだけでなく、処理の流れ、データ、人間との連携、評価、記憶といった多くの要素を組み合わせるエンジニアリングが必要であることが分かります。LangChainは、これらの要素をまとめて開発するための強力なフレームワークを提供していると言えるでしょう。

引用元: https://blog.generative-agents.co.jp/entry/2025-langchain-interrupt-day1

ChatGPTを使うエンジニアの皆さんに、嬉しいニュースです！OpenAIの新しいAIモデル「GPT-4.1」が、ChatGPTで使えるようになりました。

現在、ChatGPTの有料プランであるPlus、Pro、Teamのユーザーは、この新しい「GPT-4.1」を利用できます。まだEnterpriseやEducationのプランを使っている方は、これから数週間のうちに使えるようになる予定です。

この「GPT-4.1」モデルは、特にエンジニアの仕事に役立つ特徴を持っています。例えば、プログラムのコードを書くのを手伝ってくれたり、私たちがAIにお願いしたこと（指示）をより正確に理解してくれたりする能力が向上しているそうです。しかも、以前のモデルよりも速く応答してくれるとのこと。

OpenAIでは、このGPT-4.1モデルを、日常的なコーディング作業にとても適していると考えているようです。具体的には、以前から使われている「OpenAI o3」や「o4-mini」といったモデルの代わりに使っても、十分、あるいはそれ以上に便利だとおすすめしています。コードのアイデア出しや、簡単なスクリプト作成、エラーの原因究明など、毎日の開発業務でAIを頼ることが多い方には、ぜひ試してみてほしいモデルと言えそうです。

記事には、最初はGPT-4.1の説明にAPI版の情報が混ざっていたという訂正がありましたが、現在はChatGPTで利用できるモデルとしての情報が正確に記載されています。

新しい技術に触れることは、エンジニアとして成長する上でとても大切です。ぜひChatGPTで「GPT-4.1」を試して、日々の開発にどう活かせるか試してみてください。使いやすさや性能の向上を実感できるかもしれませんよ。

引用元: https://japan.cnet.com/article/35232979/

ホロライブの角巻わためさんが、同じくホロライブの大空スバルさんが見守る中、ホラーゲームに挑戦しました。始まる前は余裕を見せていましたが、ゲームが始まると次々に悲鳴を上げてしまう展開に。その様子を見ていた大空スバルさんは「最高っすわ」と大爆笑。無事にクリアしたわためさんも、最後に「怖い！」と素直な感想を叫び、見ている側も楽しめる配信だったことが伝わります。

引用元: https://news.goo.ne.jp/article/crankin/entertainment/crankin-16670203.html

VOICEVOX:ずんだもん

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/

IT分野の調査会社であるGartnerが、「AIエージェント」と「エージェント型AI」という二つの言葉について、その違いが分かりにくくなっている現状を踏まえ、それぞれの定義とAIの進化における位置づけについて見解を発表しました。

Gartnerはこれらの言葉を次のように定義しています。

簡単に言うと、AIの進化の段階で考えると理解しやすいかもしれません。例えば、チャットボットは限定された応答、RPAは定型作業の自動化が得意です。これに対し、AIエージェントはもう少し自分で判断して簡単なタスクの一部をこなせます。さらに進化した「エージェント型AI」は、より高度な知能と機能を持ち、複雑な目標を自律的に達成するために行動できる、言わば「AIの代理人」のような存在です。

AIは、単なる自動化から、人間の代理として行動するより高度なエージェント型へと進化しつつあるとGartnerは述べています。

また、最近注目されている関連技術として、AIエージェントがツールなどを使いこなす際に、一貫した考え方や記憶を持たせるための仕組みである「MCP（モデルコンテキストプロトコル）」や、複数のAIエージェントが連携するためのルール「Agent-to-Agent（A2A）」などが挙げられており、AIエージェントはさらに進化していくと予測されています。

Gartnerは、2028年までには日本企業の60%で、汎用的な知能を持つAGIを基盤とした新しいエージェント型AIやヒューマノイド（人型ロボット）と一緒に働くことが当たり前になるだろう、と予測しています。

AI分野は発展が速く、様々な言葉が出てきますが、これらの違いを理解することは、今後の技術動向を追っていく上で役に立つでしょう。

引用元: https://enterprisezine.jp/news/detail/21969

この記事では、VS Codeの拡張機能であるAIエージェント「Cline」と、AWSの生成AIサービス「Amazon Bedrock」を組み合わせて、データベース操作（CRUD：データ作成・読み込み・更新・削除）ができるWebアプリケーションを開発した経験が紹介されています。

Clineは、指示に基づいてコードを書くだけでなく、必要なファイルを自動で作ったり、ライブラリをインストールしたり、プログラムを動かして動作確認やエラー修正まで行うことができる便利なツールです。様々な生成AIモデルを選んで使うことができます。

Bedrockは、AWSが提供する安全性の高い生成AIサービスで、企業のデータがモデルの学習に使われないという大きなメリットがあります。また、複数のAIモデルを簡単に切り替えて試せるのも特徴です。ビジネスの現場でClineを使うことを考えると、セキュリティがしっかりしているBedrockはとても相性が良い選択肢です。

筆者は、この組み合わせで簡単なTODOアプリを開発してみました。「PostgreSQLというデータベースを使い、それをDockerという技術で動かす」「Web画面（フロントエンド）はReact、裏側の処理（バックエンド）はPythonのFastAPIで作る」といった具体的な指示をClineに与えました。

実際にやってみると、AIに開発を任せる上でいくつか工夫が必要だと分かりました。例えば、Windows環境でClineがLinuxコマンドを使えるようにする設定をしたり、コードを書く前の準備（使うためのツールのインストールなど）は人間が先に済ませておいた方が、AIがスムーズに開発を進められるようです。また、簡単なコードだけでなく、Webアプリ全体のような少し複雑なものを作る場合は、高性能なAIモデル（この記事ではClaude 3.7 Sonnet）を使うと、エラーが少なく効率的に進められるという発見がありました。

結果として、Clineは指示通りにフォルダを作り、データベースを用意し、画面と裏側のプログラムを書いて、アプリを動かすところまで自動で行ってくれました。生成されたコードも、人間が書くような構造になっていました。この開発にかかった費用は約5.2ドルで、人件費に比べると大幅に安く済ませることができました。

このように、ClineのようなAIエージェントとBedrockのようなセキュアなAIサービスを組み合わせることで、AIが開発のかなりの部分をサポートしてくれることを体験できます。AIにどこまで任せるか、人間がどこを担当するかを見極めることが、効率的に開発を進めるポイントになりそうです。

引用元: https://acro-engineer.hatenablog.com/entry/2025/05/14/120000

出張での現地集合で駅を間違えた体験談が話題になっています。特に「大久保駅」のように同じ名前の駅は全国にあり、場所を間違えてしまう「あるある」な失敗談が多数寄せられました。大阪の日本橋と東京の日本橋、大阪の茨木市と茨城県など、地域をまたいだ間違いエピソードに共感が集まっています。指示を受ける際は、地名だけでなく都道府県名や路線名も確認するなど、基本的なことでもしっかり確認することが大切だと気づかせてくれる、新人さんにも役立つ記事です。

引用元: https://togetter.com/li/2551045

（株式会社ずんだもんは架空の登場組織です）

大規模言語モデル（LLM）はテキスト生成などで高い能力を持ちますが、単体では最新情報や非公開データを知らなかったり、現実世界でアクションを起こせなかったりする制約があります。これらの「知識の壁」「実行の壁」「能力の壁」を超えるために、LLMは外部サービス（APIなど）と連携する必要があります。MCPやAIエージェントでは、このような外部連携が不可欠です。

しかし、LLMが外部と連携できるようになると、新たなセキュリティリスクが生まれます。開発者の皆さんは、このリスクを理解し対策することが重要です。

記事では、具体的な機能例として「URL指定による情報取得機能」と「Gitホスティングサービス連携機能」を取り上げ、潜むリスクを解説しています。

例えば「URL指定による情報取得機能」では、指定されたURLから情報を取得するために外部へ通信します。ここで、悪意のあるURLを指定されると、サーバー内部のリソースに不正アクセスされる「SSRF」という危険性があります。また、ユーザーからの指示や外部の情報に埋め込まれた悪意のあるテキスト（プロンプトインジェクション）によって、LLMが意図せず機密情報を含むリクエストを生成してしまうリスクも考えられます。

「Gitホスティングサービス連携機能」のように、LLMが外部サービスで実際に操作を行う機能では、「過剰な代理行為」に注意が必要です。LLMに必要以上の権限を与えていると、ユーザーの曖昧な指示や、外部の情報に仕掛けられた偽の指示によって、意図しない広範囲な操作（リポジトリの削除など）を実行してしまう可能性があります。また、LLMが扱うプライベートな情報（コードやIssue内容など）が、LLMの「コンテキストウィンドウ」を通じて外部に漏洩するリスクもあります。

これらのリスクに対して、記事では以下の対策を挙げています。

外部連携するLLMアプリケーションを開発する際は、これらのセキュリティ観点をしっかり考慮し、安全な設計を心がけましょう。

引用元: https://blog.flatt.tech/entry/llm_ext_collab_security

この記事では、AIを使った様々な作業を自動化する「AIワークフローサービス」の中から、特に注目されているDify、n8n、Gumloopの3つを比較して紹介しています。これらのツールを使うと、プログラミングの専門知識が少なくても、AIや他のサービスを組み合わせて複雑な自動化の仕組み（ワークフロー）を簡単に作れるようになります。

日本で特に人気があるのがDifyです。その理由は、UIやドキュメントが日本語でしっかり整備されているため、日本のユーザーが使い始めやすい点にあります。Difyは、主にチャットボットや、企業のデータを使った質疑応答システム（RAG）のような、生成AIを使ったアプリケーションの開発に特化しています。オープンソース版とクラウド版が提供されており、企業が社内向けのAIアプリを素早く作るのに役立ちます。

n8nは、SlackやGoogle Workspaceなど、様々なWebサービス同士を連携させて業務を自動化するためのツールとして以前から使われています。最近はAIとの連携機能も強化され、AIを使った新しい自動化が可能になりました。例えば、「メールの内容をAIで要約してチャットツールに通知する」といったワークフローが作れます。400種類以上の外部サービスと連携できる汎用性があり、完全にノーコードだけでなく、コードを書いてより柔軟な処理も組み込めるため、技術者にも適しています。こちらもオープンソース版とクラウド版があります。

Gumloopは、AIワークフローに特化した比較的新しいサービスです。UIが直感的で使いやすいと評価されています。Gumloopの大きな特徴は、Chromeブラウザの拡張機能と連携できる点です。これにより、Webサイト上で行う操作（情報の取得や入力など）をワークフローに組み込み、AIと連携させて自動化できます。これは、AIを使った軽量なRPA（ロボットによる業務自動化）のような使い方ができるということです。現在は主にクラウドサービスとして提供されており、ビジネス部門での定型タスク自動化に役立ちます。

Dify、n8n、Gumloopは、それぞれ得意な分野や特徴が異なります。Difyは生成AIアプリ開発、n8nは汎用的なサービス連携とAIの組み合わせ、GumloopはAI特化とWeb操作連携が強みです。作りたいものや必要な機能、技術レベルに合わせて、最適なツールを選ぶことが大切です。

引用元: https://note.com/_kayato/n/ncb305c10c9d7

最新の生成AI市場では、OpenAIの「GPT-4.1」、Anthropicの「Claude 3.7 Sonnet」、Googleの「Gemini 2.5 Pro」、xAIの「Grok 3」という主要な大規模言語モデル（LLM）が競争を繰り広げています。この記事では、これらのLLMがそれぞれどのような特徴を持ち、どのような用途に適しているかを比較しています。新人エンジニアの皆さんが、今後LLMを業務で活用したり、どのモデルを選ぶかの参考にしたりする際に役立つ情報がまとめられています。

まず、チャットボットとしての性能では、GoogleのGemini 2.5 Proが人間の評価で最も高いスコアを獲得しており、自然な対話が得意なため、一般消費者向けのカスタマーサポートなどに期待されています。OpenAIのGPT-4.1は、複数のやり取りが続く会話の質が向上し、過去の発言をうまく踏まえた応答ができるようになりました。これにより、複雑な問い合わせが多い金融や医療分野でのサポートで力を発揮すると考えられます。AnthropicのClaude 3.7 Sonnetは、一度に非常に多くの文章（約15万単語）を読み込める能力（コンテキストウィンドウが広いと言います）が特徴です。そのため、分厚いマニュアルやたくさんの情報を参照しながら回答する必要がある技術サポートなどで強みを発揮します。xAIのGrok 3は、もともと高い会話能力で知られており、特に若い世代向けのカジュアルな対話や、状況に合わせて柔軟な話し方ができる点が特徴です。また、これらのLLMは、ユーザーの感情を読み取って、AIだけでは難しいと判断した場合に人間の担当者へ引き継ぐ、といった高度な使い方もできるようになっています。

次に、プログラムコードを書いたり修正したりするコーディング支援としての性能です。この分野で特に優れていると評価されているのがClaude 3.7 Sonnetです。コードの問題を見つけて修正するテストで高い正解率を示しており、特に大規模なプログラムコードを扱う開発に適しています。実際の開発者からも「実践で使える質の高いコードを生成できる」と評価されています。OpenAIのGPT-4.1もコーディング性能が大幅に向上しており、特に既存コードの変更や修正作業を効率化するのに役立ちます。GoogleのGemini 2.5 Proは、自動化ツールと組み合わせることで、複数のプログラムファイルにまたがるような複雑なコーディングタスクで高い能力を発揮し、Webアプリケーション開発の支援などに期待できます。Grok 3は、「思考モード」というじっくり考えてエラーを修正したり別の方法を探したりする機能を使うことで、複雑なプログラミング課題で高いスコアを出しています。

このように、最新のLLMはそれぞれに得意なことや特徴があり、どのような目的で使いたいかによって最適なモデルが異なります。この記事を参考に、皆さんの業務や開発に合ったLLM選びをしてみてください。

引用元: https://www.sbbit.jp/article/cont1/163498

VTuberのしぐれういさんが風邪で声が出ない中、工夫を凝らした配信を行いました。過去の自身の声を使った「しぐれういボタン」や、音声合成技術による「ずんだもん」の声を活用。状況説明はずんだもん、コメントへの応答は高速タイピングでの筆談と、様々な手法を駆使して視聴者を楽しませました。声が出ないという困難を技術とアイデアで乗り越えた配信は「神対応」と話題になりました。

引用元: https://www.appbank.net/2025/05/13/vtuber/2769611.php

（株式会社ずんだもんは架空の登場組織です）

大規模言語モデル（LLM）の多くは、テキストを処理する際に、文章を「トークン」と呼ばれる単語や文字のまとまりに区切ります。この論文では、そういった事前準備としての「トークン化」を行わず、テキストの最小単位である「バイト」レベルで直接処理する新しい技術、「Byte Latent Transformer (BLT)」が提案されています。

BLTのポイントは、バイト列を固定長のトークンとして扱うのではなく、「パッチ」という単位で扱うことです。このパッチのサイズが特徴的で、データの内容に応じて自動的に長さを変えます。例えば、次に続くバイトが簡単に予測できるような、パターン化された情報が多い部分ではパッチを長くし、予測が難しい複雑な情報が多い部分ではパッチを短くするといった具合です。これは、次に予測すべきバイトの「予測しにくさ」を示す情報エントロピーに基づいて行われます。

このようにパッチのサイズを動的に変えることで、モデルは計算リソースを効率的に割り当てることができ、結果として推論（モデルを使って新しいテキストなどを生成する処理）の効率が向上します。また、特定のトークンセットに縛られないため、より多様なデータに対応しやすくなる（頑健性が高まる）と考えられます。

研究では、最大80億パラメータを持つBLTモデルを膨大なデータ（4兆バイト）で学習させ、その有効性を検証しました。実験から、トークン化なしで生バイトから学習できること、そして同じ計算コストで比較した場合、従来のトークンベースのモデルよりも性能を効率的に向上させられる（スケーリング性能が良い）ことが示されました。

この技術は、従来のLLMの仕組みに一石を投じるものであり、将来的にテキストだけでなく、バイト列で表現可能なあらゆる種類のデータ（プログラムコード、もしかすると画像や音声など）を効率的に扱えるようになる可能性を秘めています。LLMの基盤技術の進化として注目に値する研究です。

引用元: https://arxiv.org/abs/2412.09871

この記事は、近年普及しているLLM（大規模言語モデル）を使ったアプリケーション開発を効率化する「LLMフレームワーク」に潜むセキュリティリスクと対策について、新人エンジニア向けに分かりやすく解説しています。

LangChainやLlamaIndexといったLLMフレームワークは非常に便利ですが、その機能の裏には新たなセキュリティリスクが生まれています。特に注意すべき点は二つあります。一つは、フレームワークが提供する「実験的な機能」や「非推奨のオプション」を安易に使うことです。例えば、LangChainにはLLMにPythonコードを実行させる機能や、危険なリクエストを許可するオプションがあり、これらを不用意に使うと、攻撃者にサーバー上で任意のコードを実行されてしまう（RCE：Remote Code Execution）脆弱性につながる可能性があります。この教訓として、実験的な機能や非推奨オプションは、本当に必要か設計段階でよく考え、可能な限り使わないことが重要です。

もう一つは、LLMフレームワークそのものの実装に潜む脆弱性です。記事では、LangChain, Haystack, LlamaIndexなどの実際の脆弱性事例を挙げて解説しています。

これらの事例から、LLMフレームワークを利用するだけでなく、独自に機能を実装する際にも、従来のWebアプリケーション開発で注意すべきセキュリティ対策（入力値の検証、出力値のエスケープなど）が引き続き非常に重要であることが分かります。フレームワークの機能を使う際も、その内部でどのような処理が行われるかを理解し、ユーザーからの入力やLLMの出力が想定外の挙動を引き起こさないよう、アプリケーション側でも多層的な防御策を講じることが不可欠です。

LLMフレームワークは開発効率を高めますが、セキュリティリスクを理解し、適切に対策を講じながら使うことが、安全なAIアプリケーション開発には欠かせません。

引用元: https://blog.flatt.tech/entry/llm_framework_security

**

Embeddingsを一言でいうと、「テキストを数値の配列（ベクトル）に変換する技術」です。例えば、「Hello, world!」という短い文章でも、文書全体のような長いテキストでも、Embeddingsモデルにかけると、同じ数の数値が並んだ配列が得られます。この数値配列が、そのテキストの意味的な特徴を表しているのです。

この数値配列は、まるで地図上の「座標」のようなものだと考えると分かりやすいです。ただし、私たちが普段考える2次元や3次元ではなく、数百〜数千次元の空間における座標です。この「意味の多次元空間」では、意味的に似ているテキストは近い場所に、そうでないテキストは遠い場所に配置されます。

重要なのは、この多次元空間における「座標間の距離」を計算することで、どんなテキスト同士でも、数学的に意味的な近さを比較できるようになる点です。「王様 - 男性 + 女性 ≒ 女王様」という有名な例のように、Embeddingsは単語だけでなく、文章やドキュメント間の複雑な意味的な関係も捉えることができます。

Embeddingsは、GeminiやVoyage AIなどのAPIを使えば比較的簡単に生成でき、コストも高くありません。モデルによって対応できるテキストの長さなどが異なるため、目的に合ったモデルを選ぶことが大切です。

具体的な応用例としては、大量のドキュメントがある場合に、あるドキュメントと意味的に関連性の高いドキュメントを自動で見つけ出す、といったことが可能になります。記事では、技術ドキュメント作成ツールであるSphinxを使って、各ドキュメントのEmbeddingsを生成し、関連性の高いドキュメントを推薦する実験結果を紹介しています（例: ある変更履歴のページに関連する別の変更履歴ページが見つかるなど）。

このようにEmbeddingsは、テキストの意味的な関連性を大規模に発見・比較する強力なツールであり、技術文書作成のような分野でも、コンテンツの整理や関連コンテンツの推薦など、様々な可能性を秘めています。

引用元: https://technicalwriting.dev/ml/embeddings/overview.html

（株式会社ずんだもんは架空の登場組織です）

**

MCPは、特に大規模言語モデル（LLM）が、外部にある様々な情報源（ファイル、データベース、Web APIなど）や、特定の機能を持つツールにアクセスするための標準規格です。LLMにすべての知識を持たせるのではなく、必要な情報を外部から取得したり、ツールを呼び出したりできるようになります。これは、AIエージェントが外部の世界と繋がり、具体的なタスクを実行するための「道具箱へのアクセス方法」を定義するようなものです。Anthropicが中心となって提案しています。

ACPは、ローカル環境やエッジデバイス内で動作するAIエージェント同士が、低遅延でリアルタイムに通信し、協調するためのプロトコルです。クラウドサービスへの依存を減らし、ネットワークが不安定だったり、プライバシーが重要だったりする環境（例えば工場内のロボット連携やオンデバイスAI）での利用を想定しています。エージェントは自分の能力を公開し、他のエージェントとイベント駆動型で情報を交換します。同じ場所で働くエージェントたちの「内線電話」のようなイメージです。BeeAIとIBMが提案しました。

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

この記事は、OpenAIやLangChainなどの考え方を元に、AIエージェントの設計思想を比較検討したものです。AIエージェント開発には、「Big Model」と「Big Workflows」という二つの考え方があることが分かります。

「Big Model」は、高性能な大規模言語モデル（LLM）の能力を最大限に活かし、多くの判断や処理をモデルに任せるアプローチです。モデルの進化が速いので、シンプルな構成で早く始められるのが利点です。OpenAIはまず「シングルエージェント」という最も簡単な構成（LLMがツールを使ってタスクをこなす）から始めて、複雑になったら複数のエージェントを組み合わせる「マルチエージェント」に拡張していくことを推奨しています。

一方、「Big Workflows」は、処理の流れ（ワークフロー）をしっかりと設計し、各ステップを明確に定義するアプローチです。LangChainはこの考え方に近く、特にエージェントが次にどう動くかを判断するためにLLMに渡す「情報（コンテキスト）」を正確に制御・確認できることの重要性を強調しています。処理が見える化されていると、問題が起きたときに原因を特定しやすく、信頼性の高いシステムを作りやすいという考えです。

どちらのアプローチも一長一短あり、記事ではこれらは対立するものではなく、同じ「エージェントシステム」の異なる側面だと述べています。現実的には、PoC（Proof of Concept：技術検証）段階ではシンプルな「Big Model」寄りのアプローチで素早く試すのが有効であり、実際に運用する段階では信頼性や保守性の観点から「Big Workflows」のように処理を構造化したり、見える化したりすることが重要になると考えられます。

また、AIエージェントを開発するフレームワークを選ぶ際は、「簡単に始められるか（Low Floor）」と「複雑な要求にも対応できる拡張性があるか（High Ceiling）」の両方が重要だと指摘されています。つまり、最初は扱いやすいツールで始めつつも、将来的に複雑な処理が必要になったときに、内部の動きを細かく調整したり、人間が介入できる仕組み（Human-in-the-Loop）を組み込んだりできる柔軟な設計が大切です。

結論として、モデルの進化が速い現代では、「Big Model」と「Big Workflows」の良いところを取り入れ、状況に応じて設計を変えたり、モデルを別のものに差し替えたりできる「柔軟性」が、AIエージェント開発における重要なポイントであるとこの記事は示唆しています。

引用元: https://zenn.dev/r_kaga/articles/89e4659ca691bc

この記事は、コマンドラインから生成AIを手軽に使うためのツール「LLM」と、ローカルでLLMを動かすための環境「Ollama」を組み合わせる方法を紹介しています。

「LLM」は、コマンドライン上で様々なAIモデルと対話できる汎用ツールです。Ollama以外にも多くのAPIに対応しており、無料のプラグインが豊富に用意されています。この記事では、インストールが比較的簡単な「llm-ollama」プラグインを使った手順が紹介されています。

まず、ローカル環境にOllamaをインストールし、使いたいLLMモデル（例: llama3.2）をダウンロードします。次に、pipxというツールを使って「LLM」本体とそのOllamaプラグインをインストールします。

使い方は簡単で、Ollamaでモデルを起動しておけば、別のターミナルからllm -m [モデル名] '質問内容'という形式でAIに質問できます。-mオプションを付けないとデフォルトでOpenAIなどに接続されるので注意が必要です。

この組み合わせの面白い応用例がいくつか紹介されています。例えば、日本語で「Linuxでストレージを表示」のように質問して、対応するLinuxコマンドを出力させたり、Linuxコマンドの実行結果（uname -aやdf -h、tcpdump、dmesgの出力など）をパイプで「LLM」に渡して、その内容を日本語で解説させたり、RPG風のストーリーや犬猫の会話に変換させたりといった、ユニークな使い方も可能です。

さらに、シェルスクリプトと組み合わせて、日本語の指示でAIがLinuxコマンドを生成・実行するオリジナルのAIアシスタントのようなものを作成する例も示されており、コマンドラインツールとAIを連携させることで可能性が広がることを示唆しています。古いPCでは処理が重くなる場合もあるようですが、既存のコマンドライン操作とAIを組み合わせることで、開発や日々の作業に新しい発想を取り入れられることが伝わる内容です。

引用元: https://posfie.com/@kapper1224/p/d42qhQX

秋葉原のGiGO秋葉原5号館にて、2025年5月登場予定の新作プライズフィギュアが展示中です。「機動戦士Gundam GQuuuuuuX」のマチュ、「ウマ娘」のシュヴァルグランやホッコータルマエ、「東北ずん子・ずんだもんプロジェクト」のずんだもんなど、話題のキャラクターたちが勢揃い。秋葉原に行く機会があれば、チェックしてみてはいかがでしょうか。

引用元: https://hobby.dengeki.com/news/2588372/

VOICEVOX:春日部つむぎ

この記事は、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

この記事は、最近注目されている「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」の主な特徴は以下の通りです。

このサーバを、自分のローカル環境で動くAI（LLM）と組み合わせれば、自分の持っているドキュメントだけを使った、完全にプライベートなRAGシステムを手軽に作ることができます。例えば、会社のナレッジをAIが回答できるようにしたり、個人的なメモをAIに整理してもらったりといった応用が考えられます。

この記事では、実際にこのサーバを使ってドキュメント検索を行い、AIがその結果を基に回答を生成する例も紹介されており、システムがどのように動作するかがイメージしやすくなっています。

まとめると、この「MCP RAG Server」は、MCPという新しい連携の仕組みを活用し、ローカル環境でのRAGシステム構築を簡単にするための便利なツールです。様々なドキュメントを活用したAI連携の可能性を広げることが期待されます。このサーバは、誰でも使えるようにGitHubで公開されています。

引用元: https://zenn.dev/mkj/articles/30eeb69bf84b3f

大規模言語モデル（LLM）の性能向上には、質の高い学習データセットが欠かせません。しかし、Web上の大量のデータ（Common Crawlなど）から高品質なデータを選び出すのは難しく、多くのデータが捨てられてしまうため、データ量と品質の両立が課題でした。特に、LLMに高度な推論能力を習得させるには、より洗練されたデータが必要です。

NVIDIAは、この課題を解決するために、高品質な学習データセット「Nemotron-CC」を構築する新しいパイプラインを開発しました。そして今回、このパイプラインがNVIDIAのデータキュレーションツール「NeMo Curator」に統合され、GitHubで利用可能になったことが発表されました。

このNemotron-CCパイプラインの最大の特長は、単に不要なデータを取り除くだけでなく、捨てられがちな低品質データからも有用な情報を取り出したり、既存の高品質データから新しいテキストを生成したりする「合成データ生成」技術を組み合わせている点です。これにより、データセットの量と質を同時に高めることができます。記事によると、元データから最大2兆トークンもの高品質な合成データを生成できるそうです。

パイプラインは大きく3つのステップで構成されます。まず、Webページからテキストを抽出して整理し、重複した内容を削除します。この処理にはNVIDIAのGPUを活用した高速化技術（RAPIDSライブラリなど）が使われており、非常に効率的です。次に、複数のAIモデルを使ってテキストの品質を評価し、データの質によって分類します。そして最後に、この品質評価結果をもとに、AI（LLM）を使って新しい合成データを生成します。低品質データからは有用な情報を抜き出してリライトし、高品質データからは要約や質問応答ペアなど、多様な形式のデータを生み出します。

このパイプラインで構築されたデータセットを使って最新のLLM（Llama 3.1）を学習させた結果、従来のデータセットで学習した場合と比べて、LLMの推論能力を示すMMLUという評価指標でスコアが大きく向上したことが報告されています。これは、高品質なデータセットがLLMの性能に直接貢献することを示しています。

NeMo Curatorにこのパイプラインが統合されたことで、エンジニアは複雑なデータキュレーション処理を効率的に行えるようになります。これは、これからLLMの開発や活用に取り組む新人エンジニアにとって、高性能なモデルを作るための基盤となるデータセットの重要性を理解し、実際に構築するための強力なツールとなるでしょう。この技術は、LLMの事前学習だけでなく、特定のタスクに特化させるためのファインチューニング用のデータセット作成にも応用できます。

引用元: https://developer.nvidia.com/blog/building-nemotron-cc-a-high-quality-trillion-token-dataset-for-llm-pretraining-from-common-crawl-using-nvidia-nemo-curator/

VOICEVOX:ずんだもん