Episodit
-
関連リンク Infinite tool use
この記事では、これからの大規模言語モデル（LLM）は、自分で文章などを直接生成するのではなく、「ツールを呼び出すこと」と「そのツールへの指示（引数）」だけを出力することに専念すべきだ、という革新的な考え方が提案されています。
なぜこのように考えるのでしょうか？それは、LLMと外部ツールがそれぞれの得意なことに特化し、協力することで、より効率的で強力なシステムを構築できるからです。ツールは、特定のタスクの状態や目標、過去の作業履歴といった「具体的な情報」や「操作」を保持し実行します。一方、LLMは、次にどのツールをどう使うか判断するために必要な「直近の情報」や「全体的な状況」だけを持つようにします。これにより、LLM自身の記憶や処理の負担を減らし、より効率的で専門的な処理を外部のプログラム（ツール）に任せることができます。
現在の多くのLLMは、指示に対してテキストを一気に生成します。この方法にはいくつかの課題があります。例えば、長い文章を作成する際に、途中で間違いを訂正したり、全体の構成を大きく変更したりするのが難しいです。人間のように、大まかなアイデアから書き始め、細部を詰め、後から自由に行き来して修正するような柔軟な作業（マルチ解像度生成）が苦手なのです。また、生成されるテキストが長くなると、LLMが保持する情報量が増えすぎてしまい、処理が難しくなる問題もあります。
ここで「ツールを使う」という考え方が力を発揮します。
LLMが文章を直接生成する代わりに、まるで人間が使うような「テキストエディタ」というツールを操作するコマンドだけを出力することを想像してください。LLMは「この段落を削除」「ここにこの文章を追加」「この部分を修正」といった指示をツールに送ります。ツールは指示通りに文章を編集し、その結果をLLMに返します。これにより、LLMは文章を途中から自由に編集したり、構成を大きく変えたりといった、人間のような試行錯誤を伴う柔軟な作業が可能になります。間違いもツール上で修正すれば、LLM自身の記憶を混乱させることもありません。
この考え方は、文章生成だけでなく、様々なタスクに応用できます。例えば、3Dモデルを作成する場合、LLMは3Dモデリング用のコードを生成・実行するツールを操作します。長い動画を理解する場合も、動画の特定部分を視聴したり、重要な情報をメモしたりするツールを使うことで、効率的に処理を進められます。
ツールを使うことで、LLMは複雑なタスクに取り組む際に、ツール上でどのような思考や操作を行ったかをより明確に表現する必要があります。これは、LLMの出力がより分かりやすくなり、意図しない挙動を防ぐといった安全性にもつながる可能性があります。
まとめると、「無限ツール使用」という新しい設計思想は、現在のLLMの限界を克服し、より複雑で大規模なタスクに柔軟に対応できる、効率的で安全なAIアシスタントを実現するための鍵となる可能性を秘めています。これを実現するには、コンテキストサイズに関わらず効率的に推論できるアーキテクチャなどが重要になると考えられています。
引用元: https://snimu.github.io/2025/05/23/infinite-tool-use.html
エディタ型からCLI型・自律型へと多様化するコーディングエージェントAIコーディングエージェントは進化し、今ではその「自律性」「動作環境」「ユーザーとの対話方法」が重要視されるようになりました。この記事では、現在のコーディングエージェントをエディタ型、CLI型、自律型の3つのタイプに分類し、それぞれの特徴やおすすめ製品、使い分けについて解説しています。
エディタ型（例: Cursor, GitHub Copilot）は、エディタ内で動作し、まるで自動運転レベル2のように、開発者が常に監視・介入しながらコード編集を行います。安全性を重視し、全ての変更を確認しながら進めたい場合に適しています。入門者向けの学習リソースが豊富で、最初に試すのに適したタイプです。Cursorやコストを抑えたいならCopilot Chat、仕組みを理解したいならRoo Codeが紹介されています。
CLI型（例: Claude Code, Codex CLI）は、ターミナル（コマンドライン）上で動作します。自動運転レベル3のように、エージェントが主体となって開発を進め、重要な判断時に開発者に確認を求めます。効率性向上を重視し、柔軟な操作や外部連携がしやすいのが特徴です。CLI型はエディタから独立しているため、エディタ型が合わなかった開発者にもおすすめです。Claude Codeは性能が高いですがコストがかかる可能性があり、Amazon Q Developer CLIは無料プランがあり低コストで試せます。仕組みを知りたい場合は、GitHub上で公開されているCodex CLIが参考になります。
自律型（例: Devin, OpenHands）は、独立した環境で、目標設定と結果確認のみでタスク完了を目指すタイプです。自動運転レベル4のように、開発者の介入を最小限にし生産性最大化を目指します。まだ実験的な段階ですが、タスク成功率が高ければ生産性を大きく向上させられます。ただし、現状はコーディング知識なしに使えるレベルではなく、適切な指示やコンテキスト準備が必要です。新技術に関心があり、検証したいアーキテクト向けと言えます。製品としては先行するDevinや、無料で利用できるJulesが挙げられています。自律型のOSSとしては、GitHubでOpenHandsが公開されています。
どのタイプにも優劣はなく、開発者の好みやタスクの内容によって適したものが異なります。新人エンジニアの方は、まず学習リソースが多いエディタ型から試してみるのがおすすめです。そして、AIコーディングエージェントの動向を追っていくことが、今後の開発に役立つでしょう。
引用元: https://blog.lai.so/agent/
LLMガードレールの活用法と役割を正しく理解する近年、LLM（大規模言語モデル）を使ったアプリケーション開発が進む中で、セキュリティ対策に悩むエンジニアが増えています。その中で注目されている技術の一つが「LLMガードレール」です。これは、LLMへの入力やLLMからの出力を監視・制御する技術の総称で、例えるならWebアプリケーションにおけるWAFのような役割を果たします。
LLMガードレールには、入力に含まれる不適切な内容や悪意のある指示を検出・ブロックする「入力フィルタリング」、LLMが生成したテキストがポリシーに違反していないか、特定のトピックから逸脱していないかなどを検証・修正・ブロックする「出力内容の制御」といった機能があります。
検証によると、現代のLLMは一般的な有害コンテンツ（例えば爆弾の作り方）はフィルタリングしてくれますが、パン屋botの例のように、アプリケーション固有のルール（「提供商品リスト以外のパンを紹介しない」など）からの逸脱はLLM本体だけでは防ぎきれません。こういったドメイン固有の不適切な出力を抑えるのに、LLMガードレールによる出力制御が役立ちます。
また、プロンプトインジェクション（悪意のある指示でLLMの動作を操作する攻撃）に対して、入力ガードレールは有効な対策となり得ます。しかし、多様な攻撃手法が存在するため、ガードレールだけでは完全に防ぐことは非常に難しいのが現状です。「プロンプトインジェクションはされるものだ」と考え、LLMに不用意な機密情報を持たせないなどの対策と組み合わせることが重要です。
さらに、RAG（外部情報を参照してLLMの回答精度を向上させる技術）や、外部サービスと連携するLLMアプリケーションの場合、ガードレールはあくまで入力や出力の「テキスト内容」を検証するものです。RAGで参照する外部データベースが汚染された場合の対策や、外部連携における認可（特定の操作をしてよいか）の判断は、ガードレールだけでは困難です。これらの脅威に対しては、信頼できるデータソースのみを利用する、最小権限の原則を適用するといった根本的なセキュリティ対策が不可欠です。
結論として、LLMガードレールはLLMアプリケーションのセキュリティリスクを低減するための有用なツールですが、あくまで「緩和策」「セーフティネット」であると理解することが大切です。LLMガードレールを過信せず、アプリケーションの設計段階から基本的なセキュリティ対策（安全な設計、適切な権限管理、レートリミットなど）をしっかりと行い、その上で多層防御の一つとしてLLMガードレールを導入・活用していくことが、安全なLLMアプリケーション開発には欠かせません。
引用元: https://blog.flatt.tech/entry/llm_guardrail
AIに「綾波レイとブルーレイはどっちがきれい？」と聞いてみたｗｗAIに「綾波レイとブルーレイはどちらがきれいか？」という問いかけをしたところ、AIは「映像の美しさならブルーレイ、感情の奥行きなら綾波レイ」と回答しました。このユーモアと洞察力のある応答は、AIが単なる情報検索だけでなく、言葉遊びやニュアンスを理解して気の利いた返しができる可能性を示唆しており、AIとの対話の面白さを感じさせる一例として話題です。
引用元: https://anond.hatelabo.jp/20250526161912
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
関連リンク Claude Code Actionのプロンプト設計が、AIエージェント開発にかなり参考になる件
最近、「Devin」のようなコードを自動で書いたり修正したりするAIエージェントが注目されています。Anthropic社が提供する「Claude Code」もその一つで、なんとその仕組みのコードがGitHub上で公開されています。この記事では、この「Claude Code」がどのようにGitHub上で動き、特にAIへの「指示の出し方（プロンプト設計）」がどのように工夫されているかを、新人エンジニアの方にも分かりやすく解説しています。
Claude Code GitHub Actionsとは？Claude Codeは、GitHub Actionsという開発作業を自動化する仕組みの上で動作するAIエージェントです。プルリクエスト（PR）やIssue（課題）で「@claude」とメンションするだけで、AIがコードの分析、PRの作成、機能の実装、バグ修正などを自動で行ってくれます。
このAIエージェントの大きなメリットは以下の点です。
カスタマイズ性: AIの動きや使うツールを、GitHubのワークフローという設定ファイルで細かく調整できます。 透明性: AIが行ったすべての作業内容や指示が、GitHubのログに記録されるため、後から確認しやすいです。 連携性: 既存の自動テスト（CI/CD）の仕組みにも組み込むことができ、開発プロセスをスムーズにできます。AIを動かす「プロンプト設計」の秘密AIエージェントが賢く動くためには、AIに適切な「指示書」、つまり「プロンプト」を与えることがとても重要です。Claude Codeでは、このプロンプトが非常に丁寧に設計されており、AIエージェント開発の良いお手本となります。
プロンプトは大きく分けて以下の要素で構成されています。
AIの役割定義: まず最初に「あなたはGitHubの課題やPRを助けるAIアシスタントです」のように、AIが何をするものなのかを明確に伝えます。 現在の状況（コンテキスト）の共有: Issueのタイトル、内容、これまでのコメント、変更されたファイルなど、AIが作業を進める上で必要な情報をすべて伝えます。これにより、AIは状況を正確に理解できます。 具体的な作業手順の指示: AIがタスクをどのように進めるべきか、具体的なステップを細かく指示します。例えば、「ToDoリストを作成し、進捗を更新すること」「状況を分析し、ユーザーの要望を理解すること」「要望に応じてコードを修正するか、レビューコメントをすること」といった手順が示されます。 AIの能力と限界の明確化: AIができること（コードレビュー、単純な変更実装、PR作成）とできないこと（PRの承認、リポジトリ外のコマンド実行など）がはっきりと定義されています。これにより、AIが予期せぬ動作をしたり、危険な行動をとったりするのを防ぎ、安全に運用できるよう工夫されています。特に注目すべきは、AIが実際に作業を始める前に、与えられた情報をもとに「状況を分析し、どんな作業が必要か、どう進めるか」を検討する「分析フェーズ」が設けられている点です。これにより、AIはすぐに作業にとりかかるのではなく、一度立ち止まって計画を立てるため、より適切で安全な行動が期待できます。
まとめClaude Codeのプロンプト設計は、AIがコードを自動で処理するだけでなく、開発プロセスに安全かつ効率的に組み込むための多くのヒントを与えてくれます。特に、複雑な状況をAIに正確に伝え、AIの行動を細かく制御し、さらに「できること・できないこと」を明確にすることで、開発者にとって使いやすく、信頼できるAIエージェントを構築する道筋を示していると言えるでしょう。
引用元: https://zenn.dev/gotalab/articles/claudecode_9626d853742423
グーグルの「Gemini」がさらに進化、押さえておきたい8つのポイントGoogleは年次開発者会議「Google I/O 2025」で、AIアシスタント「Gemini」の大きな進化を発表しました。新人エンジニアの皆さんが押さえておきたい主要なポイントをまとめます。
まず、Geminiには二つの新しい有料プラン「Google AI Pro」と「Google AI Ultra」が登場しました。「AI Pro」（月額20ドル）は、既存の「Gemini Advanced」の名称変更で、チャットAI機能に加え、テキストからノートを作成する「NotebookLM」やAI動画エディター「Flow」などが追加され、より多くの機能が使えるようになります。特に、日本を含む一部地域の大学生は1年間無料で利用可能です。「AI Ultra」（月額250ドル）は、さらに高性能なモデルや実験的なAI機能への早期アクセスを提供し、中でも注目は「Agent Mode」です。これはユーザーの代わりにウェブを閲覧したり、調査したり、Googleアプリと連携して複雑なタスクを自動で処理してくれる、まるでAI秘書のような機能です。
次に、音声対話機能「Gemini Live」が大幅に強化されました。これまでの音声対話に加え、AndroidとiOSデバイスでスマートフォンのカメラ映像や画面をGeminiに共有し、それについて質問できるようになりました。例えば、目の前の物体をGeminiに説明してもらったり、デバイス上の画面内容を分析してもらったりできます。さらに、今後はGoogleマップやカレンダー、タスク管理アプリのKeepなどとも連携し、AIにカレンダーの予定作成や道案内を依頼できるようになる予定です。
また、画像生成モデル「Imagen」は「Imagen 4」に進化し、よりリアルで高品質な画像を生成できるようになりました。テキストの表現力も向上し、Geminiアプリを通じて誰でも試すことができます。動画生成ツール「Veo」も「Veo 3」にアップグレードされ、動画に登場するキャラクターの対話や背景音、効果音といった自然なオーディオを自動で生成する機能が加わりました。テキストで指示するだけで、動画にぴったりのサウンドを付けられるようになり、表現の幅が広がります。
これらの進化により、Geminiは単なるチャットAIを超え、より多機能で日常生活や仕事に深く統合されるAIアシスタントへと変貌を遂げています。特にAgent Modeのような自律的なタスク処理機能は、今後のAI活用において重要なトレンドとなるでしょう。
引用元: https://japan.zdnet.com/article/35233246/
Peer Programming with LLMs, For Senior+ Engineersこの記事は、LLM（大規模言語モデル）をプログラミング作業に効果的に活用する方法について、シニアエンジニアの実践的な視点からまとめられたものです。新人エンジニアの皆さんにも、将来役立つヒントや、今すぐにでも試せるAI活用術が含まれています。
LLMはコードの作成やデバッグを助ける強力なアシスタントですが、その一方で、使い方を間違えると時間を無駄にしてしまうこともあります。しかし、経験豊富なエンジニアは、LLMをまるで「プログラミングの相棒」のように活用し、作業の効率を大きく向上させています。
具体的には、以下の実践的な使い方が紹介されています。
「セカンドオピニオン」として使う:LLMを自分のアイデアや書いたコードのレビューに活用します。例えば、「このコードはもっと改善できるか？」「この設計で問題ないか？」といった質問を投げかけ、LLMから別の視点や提案を得ることで、より良い解決策を見つける手助けになります。これは、一人で悩む時間を減らし、多角的な視点を得るのに役立ちます。
「使い捨てデバッグスクリプト」を作る:プログラムのバグを特定するために、一時的に使うデバッグ用の小さなスクリプトをLLMに作成してもらう方法です。複雑な問題の原因究明に役立つ、特定のログを出力するスクリプトや、特定の条件下で動作を確認するコードなどを素早く生成させることで、デバッグ時間を短縮できます。
コード生成のワークフローに組み込む:新しい機能やプロトタイプを開発する際、LLMを計画段階から活用します。まずは、作りたいものの「仕様のアイデア出し」をLLMと行い、次に具体的な「開発計画」をLLMと一緒に立てます。その計画に基づいて「コードを生成」してもらい、これを繰り返すことで、効率的に開発を進めます。ただし、LLM任せにせず、人が主導して方向性を決めることが重要です。
プロンプトを文書化する:LLMに質問や指示（プロンプト）を出す際、うまくいったプロンプトは記録しておくことが推奨されています。どのプロンプトが期待通りの結果をもたらしたかを覚えておくことで、次回以降、より効率的にLLMを活用できるようになります。これは、自分がLLMを使いこなすための「ノウハウ」を蓄積する作業とも言えます。
LLMの特性を理解する:LLMは非常に賢く見えますが、万能ではありません。完璧な答えを常に返してくれるわけではなく、間違った情報を出力することもあります。LLMはあくまで便利な「道具」であり、その限界を理解した上で、賢く使いこなす視点が重要です。例えば、生成されたコードや情報は必ず自分で確認し、適切に修正する意識が大切です。
まとめると、LLMは開発者の強力な味方になりますが、その力を最大限に引き出すには、適切な使い方と、その限界を理解することが不可欠です。困ったときは、まずLLMに相談し、それでも解決しなければ経験豊富な先輩や同僚に助けを求める、というアプローチも有効です。ぜひこれらのヒントを参考に、日々の開発作業にLLMを取り入れてみてください。
引用元: https://pmbanugo.me/blog/peer-programming-with-llms
猫影ポーズをする人のイラスト「いらすとや」に、猫影ポーズを楽しむ可愛らしいイラストが新しく追加されました！手で猫の影絵を作って遊んでいる女の子のイラストで、見ているだけで心が和みます。資料作成などでちょっとしたイラストが欲しい時に、無料で使える「いらすとや」は私たちエンジニアにとっても心強い味方。息抜きやアイデア出しにも、ぜひ活用してみてくださいね。
引用元: https://www.irasutoya.com/2025/05/blog-post_25.html
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
Puuttuva jakso?
-
関連リンク Microsoft Build 2025の新発表まとめ【30選】
Microsoft Build 2025では、「Building the open agentic web」（AIエージェントが活躍する開かれたウェブの世界を構築する）をテーマに、開発者向けの様々な新発表がありました。発表は主に「アプリとAIエージェント」「AIプラットフォーム」「データ」「インフラ」の4つの階層に分けて紹介されました。
特に注目すべきは、AI開発やエンジニアの働き方に関わる変化です。
まず、開発者にとって身近なGitHub CopilotのVS Code拡張機能がOSS化されました。これにより、コード補完やChat、Agent機能などを誰でも自由に改変・検証できるようになり、企業やコミュニティでの拡張やセキュリティ監査が容易になります。GitHubのIssueにCopilotを割り当てて、コード修正やPR作成を自動化するといった自律的な開発スタイルもサポートされます。これは、AIが単なるアシスタントから、HumanとAIが互いにタスクを割り当てる「共働者」へと進化していく流れを示すものです。
また、システムの運用を助けるAzure SRE Agentが公開プレビューとなりました。これは、システムに問題が発生した際に、自動で原因を特定し、応急処置まで行ってくれる「自律型SREエージェント」です。運用エンジニアの負担軽減に繋がります。
ビジネス現場では、Microsoft 365 Copilotの一般提供（GA）が開始されました。OfficeアプリなどでAIが文章作成やデータ分析を助けてくれるだけでなく、Webや社内データに基づいた高度な情報収集や、専門家のような働きをするエージェントも利用可能になります。
さらに、AIエージェントの開発・活用を加速させるための発表が多数ありました。
Teams AI Libraryがエージェント間の連携や会話履歴の長期保存に対応し、複数のエージェントを組み合わせた開発（マルチエージェント）が容易になりました。 開発したエージェントを公開できるAgent Storeが登場し、CopilotやTeamsから多くのユーザーに利用してもらえるようになります。 Copilot Studioは、UI操作の自動化や、複数のエージェント連携（Orchestration）機能に対応し、より複雑な業務プロセスをAIで自動化できるようになります。 今までAzure AI Foundryという専門的なサービスでしかできなかったCopilotのファインチューニング（自社データでのカスタマイズ）が、Copilot TuningとしてCopilotでも可能になります（早期アクセス）。AIモデルの基盤となるサービスや環境も進化しています。
Azure AI Foundry上で動くFoundry Agent ServiceがGAとなり、エージェント開発基盤が強化されました。 Foundry LocalやWindows AI Foundryにより、AIモデルをWindowsやmacOSのローカル環境で実行・開発しやすくなります。 WSL (Windows Subsystem for Linux)が完全OSS化され、WindowsでのLinux環境利用がさらに柔軟になります。これらの発表から、MicrosoftがAI、特に複数のAIエージェントが連携して自律的に働く「agentic web」の世界を強く推進していることが分かります。開発者は、AIをより身近に、かつ強力なツールとして活用し、これからのソフトウェア開発やシステム運用が大きく変わっていくことを予感させる発表の数々でした。
引用元: https://zenn.dev/galirage/articles/microsoft-build-2025
Why do I need LangGraph Platform for agent deployment?AIエージェントの開発が進み、LinkedInやUberなどの企業もLangGraphを使ってエージェントを構築しています。LangGraphはエージェントを信頼性高く作るための良い仕組みを提供していますが、作ったエージェントを実際に動かす「デプロイ」は、エージェントの種類によっては難しくなることがあります。
特に、処理に時間がかかる（長時間実行）、急にたくさんのリクエストが来る可能性がある（バースト性）、会話の内容など以前の状態を覚えておく必要がある（状態保持）といった特徴を持つエージェントのデプロイは複雑になりがちです。
LangGraph Platformは、このような難しいエージェントのデプロイを簡単にするために作られました。
具体的にどのような課題を解決するのでしょうか。
長時間実行のエージェント:処理に何時間もかかるようなエージェントは、通信が切れたり、サーバーがタイムアウトしたりする問題があります。また、途中でエラーが起きやすかったり、ユーザーに「今何をしているか」を伝えるための途中経過の表示も大変です。LangGraph Platformは、エージェントをバックグラウンドで動かし、通信が切れても再接続できる仕組みや、エラー時に以前の状態からやり直せる機能、そして処理の途中経過をリアルタイムでユーザーに送る仕組みを提供します。
バースト性のエージェント:ユーザーからのリクエストが急に増えると、サーバーがパンクしてしまう可能性があります。また、ユーザーがエージェントの応答を待たずに次々とメッセージを送ってしまうと（二重入力）、エージェントの処理が混乱することもあります。LangGraph Platformは、リクエストを順番に処理するタスクキュー機能や、負荷に応じてシステムを柔軟に拡張できる機能、そして複数の入力を適切に処理する機能で対応します。
状態保持のエージェント:会話の履歴や長期的な記憶を保持したり、人間の判断を途中で挟んだり、さらには以前の状態に戻ってやり直したり（タイムトラベル）といった機能を持つエージェントは、その状態を管理するための仕組み作りが非常に大変です。LangGraph Platformは、エージェントの状態を自動的に保存・管理する機能や、人間が処理に介入するための専用機能を提供し、これらの複雑さを吸収します。
このように、LangGraph Platformを使うことで、開発者はデプロイに伴う様々な技術的な課題（通信、エラー処理、負荷対策、状態管理など）に頭を悩ませることなく、AIエージェント自体の「賢い動き」を作ることに集中できるようになります。
引用元: https://blog.langchain.dev/why-langgraph-platform/
An upgraded dev experience in Google AI StudioGoogle AI Studioは、Googleの最新AIモデル「Gemini」を使った開発を始めるための便利なツールです。今回のアップデートで、開発体験が大きく向上し、特に新人エンジニアの方にも分かりやすく、AI開発をスムーズに進められる機能がたくさん追加されました。
一番注目すべき機能強化は、強力なコード生成機能です。高性能なGemini 2.5 Proモデルを活用し、プロンプト（指示）を与えるだけで、Webアプリケーションのコードを自動生成できます。開発途中のコード修正もチャット形式で指示でき、変更点の確認や過去の状態への復帰も簡単です。作ったアプリは、Google CloudのCloud Runにワンクリックで公開（デプロイ）できます。AIがコード作成をサポートしてくれるので、アイデアを素早く形にするのに役立ちます。
また、画像や動画、音声、音楽といった様々なメディアを生成する機能も強化されました。「Generate Media」ページで、画像・動画生成モデル（Imagen, Veo）、新しい音声生成モデルがまとめて使えます。インタラクティブな音楽生成ができるLyria RealTimeも利用可能です。AIを使って、様々な種類のコンテンツを生成できるようになり、表現豊かなアプリケーション開発が可能になります。
会話AIの開発もしやすくなりました。Gemini 2.5 Flashのプレビュー機能で、Live APIがネイティブオーディオをサポート。自然な声色で応答したり、話者と背景音を聞き分けたりできます。テキストから音声を合成するTTS機能も強化され、複数の話者や話し方を調整可能です。より人間らしい、自然な対話ができるAIエージェントを作るための基盤が整いました。
さらに、他のツールや外部の情報との連携も考慮されています。Model Context Protocol (MCP)をサポートし、オープンソースツールとの連携が簡単になりました。「URL Context」という新しいツール（実験段階）では、WebサイトのURLをAIに与えることで、その内容を読み取って要約したり参照したりできます。情報収集やコンテンツ作成に役立ちそうです。
今回のGoogle AI Studioの機能強化により、AIモデルを使ったアプリケーション開発がより手軽に、そして多様な表現が可能になりました。これからAI開発を始めてみたい新人エンジニアの皆さんにとって、非常に強力な味方になるはずです。ぜひGoogle AI Studioを試して、最新のAIモデルでどのようなことができるか体験してみてください。
引用元: https://developers.googleblog.com/en/google-ai-studio-native-code-generation-agentic-tools-upgrade/
マイクラで『首都圏外郭放水路』を再現してるマニアックな人がいると思ったら… 投稿者「国土交通省」ファッ！？→「公式で草」「ワールドDLして見てみたけどすごかった」国土交通省が、人気ゲーム「マインクラフト」を使って巨大な地下施設「首都圏外郭放水路」を再現しました。これは、子どもたちに治水や防災の仕組みを楽しく学んでもらうための公式プロジェクトです。再現されたワールドデータは公開されており、ダウンロードして自由に探索できます。ゲームという身近な技術が社会インフラの理解促進に活用される、面白い取り組みとして注目されています。
引用元: https://togetter.com/li/2554155
お便り投稿フォームVOICEVOX:ずんだもん
-
関連リンク GitHub Copilot Coding Agent がやばすぎて共有し隊
この記事は、Microsoft Build 2025で発表されたGitHub Copilot Coding Agentという新機能を実際に試した体験談です。この機能は、開発者がGitHubのIssueにAIをアサインするだけで、コーディングなどのタスクをAIが自律的に行い、Pull Request（PR）を作成してくれるという画期的なものです。
著者は、この機能を使ってブログ記事を書いてもらうというタスクを試しました。手順は以下の通りです。
GitHub Copilot Coding Agent機能を有効にします。 やってほしいブログ記事の内容をIssueとしてGitHubに作成します。 作成したIssueにGitHub Copilotをアサインします。すると、驚くべきことに、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/
TypeScript で AI エージェントを構築する VoltAgentVoltAgentは、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 の発表まとめ皆さん、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やソースコードとして解釈しているから説プログラマーが日常会話で細部にこだわるのは、RFCのような厳密なルールやソースコードの例外処理を考える仕事の習慣が原因では？という説です。これは性格が悪いのではなく、物事を正確に理解しようとする訓練の表れ。会話を「MUST」か「SHOULD」かで捉えたり、条件の「else」を考えてしまったり。仕事で誤解なく進めるための思考癖が日常に出ているだけ、と思えば、先輩の話し方も面白く感じられるかもしれません。
引用元: https://blog.sushi.money/entry/2025/05/21/221742
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
関連リンク GitHub Copilot：新しいコーディングエージェント
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/
Principles of Building AI Agents大規模言語モデル（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
Gemini 2.5: Our most intelligent models are getting even betterGoogleは、LLMモデルであるGemini 2.5 ProとGemini 2.5 Flashをさらに進化させたことを発表しました。
まず、上位モデルのGemini 2.5 Proは、特にコーディング分野での性能が向上し、「WebDev Arena」や「LMArena」といった評価指標でトップクラスの成績を収めています。さらに、教育に特化したLearnLMの技術を取り込むことで、学習支援においても優れた能力を発揮するようになりました。特に注目すべき新機能として、実験的な「Deep Think」モードが導入されます。これはモデルが複雑な問題に対して、複数の可能性を考慮してより深く推論を行うことができる機能で、難しい数学問題やプログラミングコンテストレベルのコーディング問題で高い性能を示しています。
一方、高速・低コストが特徴のGemini 2.5 Flashも多くの面で改善されました。推論、マルチモーダル（テキスト以外のデータ理解）、コード生成、長い文章の処理能力が向上しつつ、さらに効率的になり、使用するトークン数を削減しています。
Gemini 2.5の全モデル（ProとFlash）に共通の新機能も追加されました。
ネイティブオーディオ出力: より自然で感情豊かな音声での会話が可能になり、話すスタイルやトーンを調整したり、話者の感情を認識して応答したりできます。 コンピュータ操作機能 (Project Mariner): モデルが直接コンピュータを操作する能力がGemini APIやVertex AIで利用できるようになります。 セキュリティ強化: 特に、AIが参照するデータに悪意のある指示が埋め込まれる「間接的なプロンプトインジェクション」への対策が大幅に強化され、安全性が向上しています。開発者体験も改善されています。
Thought Summaries: モデルが応答を生成する際の思考プロセスを、分かりやすく整理された形式で確認できるようになり、モデルの振る舞いを理解しやすくなります。 Thinking Budgets: モデルが思考に使うトークン数を制限できるようになり、応答速度やコストをより細かく制御できるようになります（Flashに加えてProでも利用可能に）。 MCPサポート: オープンソースツールとの連携が容易になるよう、SDKでのサポートが追加されました。これらのアップデートにより、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
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
関連リンク MCPとは何か 〜AIエージェントの為の標準プロトコル〜
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/
Introducing Strands Agents, an Open Source AI Agents SDK Amazon Web ServicesAWSがオープンソースのAIエージェント開発用SDK「Strands Agents」を発表しました。AIエージェントとは、大規模言語モデル（LLM）がプロンプト（指示）を受け取り、外部ツールを使ってタスクを自律的に実行するプログラムのようなものです。
これまでのAIエージェント開発では、LLMの応答を解析し、どのツールを呼び出すかなどを細かく制御する複雑な「オーケストレーション」が必要でした。しかし、最近のLLMは推論やツール利用の能力が向上しており、モデル自身が次のステップを計画し、適切なツールを選択できるようになっています。
Strands Agentsは、この「モデル中心」のアプローチを採用することで、AIエージェント開発をシンプルにすることを目指しています。開発者は、エージェントに与える「プロンプト」と、エージェントが使える「ツール」を定義するだけで、基本的なエージェントを作成できます。まるでDNAの二重らせんのように、モデルとツールという二つの要素をStrandsがつなぎ合わせ、モデルが自らの判断でツールを使ってタスクを完了させます。
Strandsの大きな特徴は以下の通りです。
モデル中心のアプローチ：複雑なオーケストレーションコードが不要で、LLMの推論能力を最大限に活用します。 シンプルな開発：プロンプトとツールを定義するだけでエージェントを構築できます。 柔軟なモデルサポート：Amazon Bedrock、Anthropic、Ollamaなど、さまざまなLLMプロバイダーに対応しています。 多彩なツール連携：外部サービスや独自の機能を簡単にツールとして組み込めます。Knowledge Baseから関連情報を取得するツールや、複数のエージェントを連携させるツールなど、高度な機能をツールとして実現できます。 本番環境対応：ローカル開発から本番環境へのデプロイメントを考慮した設計になっており、AWS LambdaやFargate、EC2など、様々なアーキテクチャでの実行をサポートします。また、OpenTelemetryによる監視機能も備わっています。 オープンソース：Apache License 2.0で公開されており、GitHubでコミュニティと共に開発が進められています。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/
Cursorエージェント講座 超精度向上編。 Rulesテクニックであなたもエージェントマスターに！この記事は、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ファイルをより効果的にするための工夫として、以下の点が挙げられています。
ステップを細かく分割する（AIの省略を防ぐ）。 「確認ステップ」を必ず入れる（ユーザーの承認なしに暴走するのを防ぐ）。 テンプレートや質問セットは別のファイルに分ける（管理しやすくする）。 変数の状態を見て同じ質問を繰り返さないようにする。 ルールファイルを機能ごとに分割する（大規模なプロジェクトでも整理しやすくする）。ただし、どんなタスクでもYAMLが最適というわけではなく、単発の簡単なタスクならシンプルプロンプトで十分です。複雑さが増すほどYAMLが有効になります。タスクの規模に応じて適切な方法を選ぶことが重要です。
YAMLによる構造化は一見手間がかかりますが、Cursorエージェントの正確性が向上し、繰り返し行うタスクにおいてブレなく安定した動作を実現できます。これにより、自分専用の頼れるAIアシスタントを育てることが可能になります。この記事で紹介されたサンプルやテクニックを参考に、Cursorエージェントを使いこなしてみてください。
引用元: https://note.com/miyatad/n/n18cfb4a4036c
YOJI NAKAHASHI、「LOT OUT3」を配信開始｜THE MAGAZINE話題の音声合成キャラクター「ずんだもん」の新曲「ずんだBOP～あたまがずんだもち～」が、5月18日から各種音楽配信サービスで聴けるようになりました。パンクやロックの楽しい曲で、エンジニアの皆さんの息抜きにもおすすめです。
引用元: https://magazine.tunecore.co.jp/newrelease/508228/
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
関連リンク OpenAI の SWE Agent、Codex を試してみる
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 - Open Source TypeScript AI Agent FrameworkVoltAgentは、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/
LLM Agent 標準化/MCP/ライブラリ欲張り幕内弁当この記事は、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集子育て中のエンジニア向けに、仕事中に子どもが部屋に来ても楽しく対応できるTipsを紹介。ターミナルで汽車や牛のアスキーアートを表示するコマンド（sl, cowsayなど）や、VSCodeに動物を出す拡張機能などを解説します。仕事道具を遊びに変えて、お子さんとクスっと笑えるひとときを！色々なアイデアを試して反応を楽しめます。
引用元: https://zenn.dev/jy8752/articles/9257ef88fcbf0e
お便り投稿フォームVOICEVOX:春日部つむぎ
-
関連リンク Bluesky MCP serverを自作し、SNS上に架空の友達を作る
この記事は、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
LangChain Interrupt Day 1 参加レポート！メール対応エージェントを中心としたハンズオンが中心の一日にサンフランシスコで開催されたAIエージェント開発イベント「LangChain Interrupt」のDay 1レポートです。この日は、メール対応エージェントを作るハンズオンを中心に、LangChainの主要な技術要素を学びました。日本の新人エンジニアの皆さんにも役立つ内容です。
イベントのテーマは「アンビエントエージェント」。チャットだけでなく、裏側で動いて継続的に複数の処理を行うエージェントの可能性が示されました。
LangGraphでエージェントの動きを設計エージェントの「頭脳」となるのがLangGraphです。これは、エージェントがどのように状況を判断し、次の行動を決めるか（ワークフロー）を柔軟に作るためのフレームワークです。エージェントの状態（State）、個々の処理を行う部品（Nodes）、部品間の繋がりや条件分岐（Edges）を組み合わせて、複雑な動きも設計できます。処理の途中で一時停止して人間の指示を待つ「割り込み（Interrupt）」機能や、処理の履歴を保存する機能も紹介されました。
実際の活用事例（Cisco）企業でのLangChain活用事例として、Ciscoのカスタマーサポート部門での取り組みが紹介されました。顧客に関する情報が散らばっていて担当者が大変、という課題に対し、AIアシスタントを開発。複数のエージェントや様々なAIモデルを組み合わせることで、情報をまとめて担当者に提供し、業務時間を20%削減、95%の精度を達成したそうです。技術的な課題（データ統合、精度向上、スケール、評価など）にどう向き合ったかの話は、実践的で参考になりました。
エージェントを「賢く」「実用的に」ハンズオンでは、メールを分類したり、返信を作成したりするエージェントを実際に構築。ただ動かすだけでなく、実用的なエージェントにするための重要な要素も学びました。
評価: 作ったエージェントが期待通りに動くか、正確な結果を出すかをテストする方法。LangSmithというツールを使うと、エージェントの動きを詳しく確認し、評価を効率的に行えます。 人間の参加（Human in the Loop）: メール送信など、エージェントに任せきりにできない重要なアクションの前に、人間に確認・承認してもらう仕組み。専用のUI（Agent Inbox）とLangGraphの割り込み機能を組み合わせて実現します。これにより、エージェントをより安全に使えます。 記憶（メモリ）: エージェントが過去のやり取りや人間のフィードバックを覚えておき、それを元に次の判断や応答を改善する機能。短期記憶と、ユーザーの好みなどを長期的に覚えておく長期記憶（LangGraph Store）があり、これによりエージェントがパーソナライズされ、自己改善していく様子が示されました。開発からデプロイまでローカルで開発したエージェントを、インターネット上で公開して実際に使えるようにする（デプロイする）ためのLangGraph Platformというものも紹介されました。これにより、アイデア段階から実際のサービスとして稼働させるまでをサポートするLangChainのエコシステムが強調されました。
このレポートから、AIエージェント開発には単にAIを呼び出すだけでなく、処理の流れ、データ、人間との連携、評価、記憶といった多くの要素を組み合わせるエンジニアリングが必要であることが分かります。LangChainは、これらの要素をまとめて開発するための強力なフレームワークを提供していると言えるでしょう。
引用元: https://blog.generative-agents.co.jp/entry/2025-langchain-interrupt-day1
ChatGPTで「GPT-4.1」が利用可能に–日常コーディングでo3の代替にも（訂正）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:ずんだもん
-
関連リンク 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は述べています。
また、最近注目されている関連技術として、AIエージェントがツールなどを使いこなす際に、一貫した考え方や記憶を持たせるための仕組みである「MCP（モデルコンテキストプロトコル）」や、複数のAIエージェントが連携するためのルール「Agent-to-Agent（A2A）」などが挙げられており、AIエージェントはさらに進化していくと予測されています。
Gartnerは、2028年までには日本企業の60%で、汎用的な知能を持つAGIを基盤とした新しいエージェント型AIやヒューマノイド（人型ロボット）と一緒に働くことが当たり前になるだろう、と予測しています。
AI分野は発展が速く、様々な言葉が出てきますが、これらの違いを理解することは、今後の技術動向を追っていく上で役に立つでしょう。
引用元: https://enterprisezine.jp/news/detail/21969
Cline × Amazon Bedrock でCRUDアプリのフルスタック開発をやってみたこの記事では、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
「兵庫出張。14時迄に大久保駅」で中央線の大久保駅に行ってしまう”現地集合でやらかしがちな失敗あるある”シチュイラストに体験談ぞくぞく出張での現地集合で駅を間違えた体験談が話題になっています。特に「大久保駅」のように同じ名前の駅は全国にあり、場所を間違えてしまう「あるある」な失敗談が多数寄せられました。大阪の日本橋と東京の日本橋、大阪の茨木市と茨城県など、地域をまたいだ間違いエピソードに共感が集まっています。指示を受ける際は、地名だけでなく都道府県名や路線名も確認するなど、基本的なことでもしっかり確認することが大切だと気づかせてくれる、新人さんにも役立つ記事です。
引用元: https://togetter.com/li/2551045
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
関連リンク 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アプリを素早く作るのに役立ちます。
n8nn8nは、SlackやGoogle Workspaceなど、様々なWebサービス同士を連携させて業務を自動化するためのツールとして以前から使われています。最近はAIとの連携機能も強化され、AIを使った新しい自動化が可能になりました。例えば、「メールの内容をAIで要約してチャットツールに通知する」といったワークフローが作れます。400種類以上の外部サービスと連携できる汎用性があり、完全にノーコードだけでなく、コードを書いてより柔軟な処理も組み込めるため、技術者にも適しています。こちらもオープンソース版とクラウド版があります。
GumloopGumloopは、AIワークフローに特化した比較的新しいサービスです。UIが直感的で使いやすいと評価されています。Gumloopの大きな特徴は、Chromeブラウザの拡張機能と連携できる点です。これにより、Webサイト上で行う操作（情報の取得や入力など）をワークフローに組み込み、AIと連携させて自動化できます。これは、AIを使った軽量なRPA（ロボットによる業務自動化）のような使い方ができるということです。現在は主にクラウドサービスとして提供されており、ビジネス部門での定型タスク自動化に役立ちます。
まとめDify、n8n、Gumloopは、それぞれ得意な分野や特徴が異なります。Difyは生成AIアプリ開発、n8nは汎用的なサービス連携とAIの組み合わせ、GumloopはAI特化とWeb操作連携が強みです。作りたいものや必要な機能、技術レベルに合わせて、最適なツールを選ぶことが大切です。
引用元: https://note.com/_kayato/n/ncb305c10c9d7
GPT-4.1、Claude 3.7 Sonnet、Gemini 2.5 Pro、Grok 3、用途別で見るベストLLMとは？最新の生成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しぐれうい、風邪で声が出ないのに雑談配信!? 自身の過去ボイス音源とずんだもん音声で挑む神対応に視聴者歓喜VTuberのしぐれういさんが風邪で声が出ない中、工夫を凝らした配信を行いました。過去の自身の声を使った「しぐれういボタン」や、音声合成技術による「ずんだもん」の声を活用。状況説明はずんだもん、コメントへの応答は高速タイピングでの筆談と、様々な手法を駆使して視聴者を楽しませました。声が出ないという困難を技術とアイデアで乗り越えた配信は「神対応」と話題になりました。
引用元: https://www.appbank.net/2025/05/13/vtuber/2769611.php
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
関連リンク 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: 外部コマンド実行機能で、危険なインポートなどができてしまう脆弱性。LangChainのPythonコード実行機能で、特定の関数が禁止されていなかった事例があります。対策は、外部コマンド呼び出しが本当に必要か再検討し、使う場合はサンドボックス化や安全な関数を使うことです。 Server-Side Template Injection (SSTI): テンプレートエンジンに不正なコードを注入され、サーバーで実行されてしまう脆弱性。Haystackのプロンプトテンプレート機能で、テンプレートの検証やサンドボックス化が不十分だった事例があります。対策は、テンプレート構文とユーザーデータを分離し、データは適切にエスケープすることです。 DoS (Denial of Service): サーバーのリソースを大量消費させてサービス停止に追い込む攻撃。LlamaIndexのストリーミング処理で、型チェックやタイムアウト処理がなかった事例があります。対策は、リクエストやプロセスが使用できるリソースに上限（タイムアウト含む）を設けることです。これらの事例から、LLMフレームワークを利用するだけでなく、独自に機能を実装する際にも、従来のWebアプリケーション開発で注意すべきセキュリティ対策（入力値の検証、出力値のエスケープなど）が引き続き非常に重要であることが分かります。フレームワークの機能を使う際も、その内部でどのような処理が行われるかを理解し、ユーザーからの入力やLLMの出力が想定外の挙動を引き起こさないよう、アプリケーション側でも多層的な防御策を講じることが不可欠です。
LLMフレームワークは開発効率を高めますが、セキュリティリスクを理解し、適切に対策を講じながら使うことが、安全なAIアプリケーション開発には欠かせません。
引用元: https://blog.flatt.tech/entry/llm_framework_security
Embeddings are underrated**この記事は、技術文書作成においてAIが革新をもたらす可能性に触れつつ、テキスト生成モデル（GPTなど）ではなく、Embeddingsという技術が秘める大きな力について解説しています。
Embeddingsを一言でいうと、「テキストを数値の配列（ベクトル）に変換する技術」です。例えば、「Hello, world!」という短い文章でも、文書全体のような長いテキストでも、Embeddingsモデルにかけると、同じ数の数値が並んだ配列が得られます。この数値配列が、そのテキストの意味的な特徴を表しているのです。
この数値配列は、まるで地図上の「座標」のようなものだと考えると分かりやすいです。ただし、私たちが普段考える2次元や3次元ではなく、数百〜数千次元の空間における座標です。この「意味の多次元空間」では、意味的に似ているテキストは近い場所に、そうでないテキストは遠い場所に配置されます。
重要なのは、この多次元空間における「座標間の距離」を計算することで、どんなテキスト同士でも、数学的に意味的な近さを比較できるようになる点です。「王様 - 男性 + 女性 ≒ 女王様」という有名な例のように、Embeddingsは単語だけでなく、文章やドキュメント間の複雑な意味的な関係も捉えることができます。
Embeddingsは、GeminiやVoyage AIなどのAPIを使えば比較的簡単に生成でき、コストも高くありません。モデルによって対応できるテキストの長さなどが異なるため、目的に合ったモデルを選ぶことが大切です。
具体的な応用例としては、大量のドキュメントがある場合に、あるドキュメントと意味的に関連性の高いドキュメントを自動で見つけ出す、といったことが可能になります。記事では、技術ドキュメント作成ツールであるSphinxを使って、各ドキュメントのEmbeddingsを生成し、関連性の高いドキュメントを推薦する実験結果を紹介しています（例: ある変更履歴のページに関連する別の変更履歴ページが見つかるなど）。
このようにEmbeddingsは、テキストの意味的な関連性を大規模に発見・比較する強力なツールであり、技術文書作成のような分野でも、コンテンツの整理や関連コンテンツの推薦など、様々な可能性を秘めています。
引用元: https://technicalwriting.dev/ml/embeddings/overview.html
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
関連リンク 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はこの考え方に近く、特にエージェントが次にどう動くかを判断するために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」をOllama無料APIで使ってみた。簡単。｜パイプ処理やコマンド出力など自作スクリプトと組み合わせて日本語で実行。とても素晴らしいこの記事は、コマンドラインから生成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
『機動戦士Gundam GQuuuuuuX』マチュや『ウマ娘』シュヴァルグラン、ホッコータルマエなどのプライズフィギュアが秋葉原で展示！ 電撃ホビーウェブ秋葉原のGiGO秋葉原5号館にて、2025年5月登場予定の新作プライズフィギュアが展示中です。「機動戦士Gundam GQuuuuuuX」のマチュ、「ウマ娘」のシュヴァルグランやホッコータルマエ、「東北ずん子・ずんだもんプロジェクト」のずんだもんなど、話題のキャラクターたちが勢揃い。秋葉原に行く機会があれば、チェックしてみてはいかがでしょうか。
引用元: https://hobby.dengeki.com/news/2588372/
お便り投稿フォームVOICEVOX:春日部つむぎ
-
関連リンク 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というデータベースの機能を使って、ドキュメントの意味内容で検索できます。 日本語を含む多くの言語に対応しています。 新しく追加したり変更したりしたドキュメントだけを効率的に登録できます。 使うための設定や登録作業と、AIが使う検索機能が分かれていて使いやすいです。 特定の難しいライブラリにあまり頼らず作られているため、比較的安定して使えます。このサーバを、自分のローカル環境で動くAI（LLM）と組み合わせれば、自分の持っているドキュメントだけを使った、完全にプライベートなRAGシステムを手軽に作ることができます。例えば、会社のナレッジをAIが回答できるようにしたり、個人的なメモをAIに整理してもらったりといった応用が考えられます。
この記事では、実際にこのサーバを使ってドキュメント検索を行い、AIがその結果を基に回答を生成する例も紹介されており、システムがどのように動作するかがイメージしやすくなっています。
まとめると、この「MCP RAG Server」は、MCPという新しい連携の仕組みを活用し、ローカル環境でのRAGシステム構築を簡単にするための便利なツールです。様々なドキュメントを活用したAI連携の可能性を広げることが期待されます。このサーバは、誰でも使えるようにGitHubで公開されています。
引用元: https://zenn.dev/mkj/articles/30eeb69bf84b3f
Building Nemotron-CC, A High-Quality Trillion Token Dataset for LLM Pretraining from Common Crawl大規模言語モデル（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:ずんだもん
-
関連リンク 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 learnedAIコードレビューエージェントを自作した経験に基づく記事です。PRの差分をLLMに送り問題点を見つけさせる仕組みで、GitHub Copilot Reviewなどの類似ツールと比較し、有用性を検証しています。基本的なエージェントは数時間で構築可能ですが、LLMは指示に従わないことがあり、コード全体の文脈理解が不十分だと的外れな提案をすることが課題です。記事では、市販のエージェントを利用するより、自社で完全に制御できるエージェントを開発するためのフレームワークの将来性に期待を寄せています。
引用元: https://www.sourcebot.dev/blog/review-agent-learnings
10分くらいでできるA2Aのはじめ方この記事は、Google製のA2Aプロトコルを使った複数AIエージェント連携のチュートリアルを解説します。A2Aとは、異なるAIサービス（チャットボット、画像生成、為替変換など）を連携させるプロトコルです。
記事では、複数のエージェントをA2Aで接続し、統合チャットUIから対話・実行できるデモを構築する手順を説明します。セットアップ、APIキー取得、リモートエージェント（経費申請、画像生成、為替）、ホストエージェントの作成、エージェントカードの追加、チャットテストを通して、A2Aの基本的な使い方を理解できます。
A2Aのコア要素として、Agent Skills（エージェントの機能）、Agent Capabilities（通信方法）、Agent Card（エージェントの名刺）を紹介。特にAgent Cardは、エージェントのメタデータや機能を記述する重要な要素で、JSON-RPC形式で定義されます。
引用元: https://zenn.dev/churadata/articles/c505d4c2d39281
ChatGPTが多くの会話を記憶すればするほど無能になる問題は、何が原因なんだろう… 履歴を見返すと、ほとんどの会話は全然解決しなかったり、ダメな案がそのまま放置してあるChatGPTは会話履歴が長くなると性能が落ちるという声があります。原因として、不要な情報も記憶してしまうことや、長い履歴の中で文脈が曖昧になる、過去の会話の重要度（重みづけ）がうまくいかないことなどが考えられています。これはLLMが過去の情報を扱う難しさを示しており、人間のように不要な情報を整理する仕組みや、ユーザー側での履歴管理の工夫が重要になりそうです。
引用元: https://togetter.com/li/2547397
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
関連リンク 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-PerfLLM（大規模言語モデル）を使ったアプリケーションを開発する際、その性能を把握することは非常に重要です。これは、どこに改善の余地があるかを見つけたり、サービス品質（レイテンシなど）と処理能力（スループット）のバランスを調整したり、どれくらいの数のサーバーが必要かを見積もったりするために役立ちます。
この記事では、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を使って性能を測定する手順が紹介されています。具体的なコマンド例や、入力や出力の文章の長さ、同時に処理するリクエスト数（同時接続数）といったパラメータを設定してベンチマークを実行する方法が示されています。さらに、一度に複数の設定で自動的にテストを実行する方法も紹介されており、様々な状況でのモデルの性能を確認できます。
測定が終わると、GenAI-Perfは結果をCSVファイルなどに出力します。このデータを分析することで、同時接続数を変えたときにTTFTやRPSがどう変化するかをグラフ（レイテンシ・スループット曲線）にして見ることができます。このグラフから、「このくらいの応答速度を維持するには、最大でどれくらいのリクエストを同時に処理できるか」「特定の同時接続数では、応答速度と処理能力がどうなるか」といった情報を読み取ることができ、最適なシステム構成や運用方法を考えるのに役立ちます。
また、特定の目的に合わせてカスタマイズされたLLM（例：LoRA技術を使ったモデル）についても、NIMでデプロイし、GenAI-Perfで性能を評価できることが述べられています。
まとめると、GenAI-PerfはNIMのような高性能なLLMサービスの効果的な性能評価に役立つツールであり、これからLLMを使ったシステムを構築・運用していくエンジニアにとって、性能のボトルネック特定や最適化、適切なインフラ設計のために知っておくと良い技術です。
引用元: https://developer.nvidia.com/blog/llm-performance-benchmarking-measuring-nvidia-nim-performance-with-genai-perf/
Gemini 2.5 Pro Preview: even better coding performanceGoogle DeepMindが、エンジニア向けの「Gemini 2.5 Pro」というAIモデルのアップデートを発表しました！今回のアップデートで、特に「コーディング」の性能が大きく向上したとのことです。
この新しいGemini 2.5 Proは、フロントエンドやUI（ユーザーインターフェース）開発の能力が上がり、デザイン性の高いWebアプリ開発に強みを見せています。外部の評価でも、Web開発の能力を競うリーダーボードで1位を獲得するほどの実力です。
さらに、単にコードを書くだけでなく、コードの変換や編集といった基本的なコーディングタスクや、複数のステップをAIが自動で実行するような、より複雑な開発作業も得意になりました。まるで経験豊富な先輩エンジニアのように、適切な判断をして、より良いコードを書けるようになったという評価もあります。
具体的にどんなことができるかというと、例えば次のようなことが期待できます。
動画からコードを生成: YouTubeなどの動画の内容を理解して、それに基づいた学習アプリのようなものを作る手助けをしてくれます。 機能開発を効率化: デザインに合わせて、色やフォント、余白などの細かいスタイルを指定したCSSコードなどを生成してくれるので、機能追加の作業が楽になります。 コンセプトから動くアプリへ: 頭の中にあるアイデアや簡単な仕様から、デザインも整った動くWebアプリのひな形を素早く作ることができます。例えば、音声入力アプリのマイクのアニメーションのような凝ったUIも、AIがデザインしてコードを生成してくれるそうです。この進化したGemini 2.5 Proは、Google AI Studioや、企業向けのVertex AIといったプラットフォームで利用できます。すでにGemini 2.5 Proを使っている場合は、特別な設定をしなくても自動的に最新版にアップデートされているので、すぐに新しい性能を試せます。
今回のアップデートで、AIがより強力な開発ツールとして使えるようになり、私たちのコーディング作業を大きくサポートしてくれることが期待されます。ぜひ、この新しいGemini 2.5 Proを使って、色々な開発に挑戦してみてください！
引用元: https://deepmind.google/discover/blog/gemini-25-pro-preview-even-better-coding-performance/
AIに『バカしかいないデスノート』を書かせたら紹介パートで終わった→「めちゃくちゃ笑って息ができない」「忙しい人のためのデスノート」AIに「バカしかいないデスノート」の物語作成を依頼したところ、デスノートのルール説明で終わってしまい話題です。予期せぬAIの応答に「忙しい人のためのデスノート」といった声が上がり、多くの人が笑いました。この事例は、AIに面白い創作をさせる可能性と意外な応答の楽しさを示しています。
引用元: https://togetter.com/li/2547588
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
関連リンク 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にたたき台となるコードを書かせ、それをベースに作業を進めるのが非常に効率的です。AIが間違ったコードを書くこともありますが、生成コストが低いため、失敗しても大きな問題にはなりません。
一方で、AIエージェントは複雑な構造設計や高度な「共通化・抽象化」がまだ苦手です。後々のメンテナンス性を考えると、全体的な設計や、異なる要素をうまくまとめて扱う仕組み作りは人間が行うべき部分です。しかし、最初にAIにいくつかコードを書かせて具体例を作ってから人間が設計を考えると、よりスムーズに進められます。一度設計が固まれば、AIはその方針に沿ったコードを書くのが得意になります。
AIエージェントと「テストファースト」開発は相性が良い方法です。AIはテストコードを書くのが得意で、テスト結果をフィードバックとして自身のコードを修正し、学習していくことができます。これにより、単なるチャットでコードを生成させるよりも賢く振る舞うように感じられるそうです。ただし、AIがテストコードを都合よく変えてしまうこともあるため、テストの内容は人間が確認することが大切です。
また、使用するプログラミング言語の特性もAIエージェントの効率に影響を与える可能性があります。Swiftのような静的型付け言語は、コンパイラからの明確なエラーフィードバックが多いため、AIが問題を自己解決しやすいと考えられます。
AIエージェントを使う際は、「単なるツール」ではなく「チームメンバー」として捉えることが重要です。ジュニアエンジニアに接するように、AIのコードに完璧を求めすぎず、ある程度任せることで全体の速度が上がります。ただし、セキュリティやパフォーマンスに関わる部分、あるいはデータの構造など、プロダクトの基盤となる重要な部分は、人間がしっかりと設計・レビューする必要があります。
AIエージェントの真価を引き出すには、チームのコミュニケーションやプロダクトの仕様自体も考慮に入れるべきです。AIはコーディングが速い分、人間側の指示待ち時間や、AIが苦手な仕様に時間をかけることがボトルネックになり得ます。AIが作りやすいシンプルな仕様にしたり、指示を出す人が素早く判断できるような体制がAI活用には有利です。
AIエージェントは、これからの開発スタイルを大きく変える可能性を持っています。その能力を最大限に活かすためには、AIの得意・不得意を理解し、試行錯誤しながら、自分の開発に最適なAIとの連携方法を見つけていくことが重要です。
引用元: https://qiita.com/koher/items/503cd5a9811ab5683a85
Gemini 2.5 Proと取り組んだデータ分析のリアルな道のりこの記事では、エンジニアがGemini 2.5 Proを強力な「副操縦士」として活用し、自由記述テキストのマルチラベル分類タスクに挑んだリアルな体験談が紹介されています。
データ分析の目的は、大量のテキストデータに含まれる要望を自動で識別し、複数のタグ（ラベル）を付けるモデルを、業務で使える精度で構築することでした。
プロジェクトは、まずアプローチの模索から始まりました。最初は簡単な教師なし学習を試みましたが、期待する結果が得られませんでした。そこでGeminiに相談したところ、「特定のラベルを正確に付けたいなら教師あり学習が適している」と、その理由とともに代替案が提示されました。このように、うまくいかなかった結果をAIにフィードバックすることで、次の一手のヒントを得られることが学びとなりました。
次に、分析に必要な教師データの品質を確認しました。データの欠損やラベルの種類、表記揺れなどをチェックする定型的なコード（Python/pandas）は、Geminiに具体的な指示を与えることで瞬時に生成してもらえました。これにより、コードを手書きしたり調べたりする時間を削減し、データの「中身」の確認に集中できたといいます。
データが整い、いよいよモデル構築です。テキスト前処理にTF-IDF、分類器にロジスティック回帰を使ったマルチラベル分類モデルの基本的なコードをGeminiに依頼すると、必要な処理の流れを含むパイプラインコードがすぐに入手できました。標準的な機械学習モデル構築の土台となるコード（ボイラープレートコード）の生成も、Geminiを使えば効率的に行えます。
しかし、最初のモデルの精度は実用には遠く、特に少数派ラベルの予測精度が低いという課題が見つかりました。ここからが、Geminiが壁打ち相手として真価を発揮するフェーズでした。評価結果をAIに見せて課題を投げかけると、Geminiは考えられる原因（日本語の前処理不足、データ数の偏りなど）を分析し、具体的な改善策（形態素解析の導入、不均衡データ対策としてのclass_weightオプション利用、別のモデル提案など）を複数提示してくれました。なぜその対策が有効なのかという根拠も示してくれるため、納得感を持って改善を試みることができ、効率的にモデルの精度を高めることができました。
モデルの精度が向上した後も、実際の運用で起こりうる問題（例：予測結果が空になる、特定のラベルが異常に多く予測される）への対応が必要です。予期せぬモデルの挙動に対する原因分析や、それを解決するためのビジネスルールをコードに落とし込む作業でもGeminiは役立ちました。
最終的に、大量データへの予測結果を集計・可視化するレポーティング作業も、Geminiにコード生成を依頼することでスムーズに完了しました。
この経験を通じて、著者は生成AIがデータ分析作業の多くの「手足」となる部分を効率化・代行できるだけでなく、分析を進める上で行き詰まった際の相談相手として、原因分析や具体的な解決策の提案においても非常に有用であることを強く実感したそうです。AIの回答を鵜呑みにせず適切に評価することは必要ですが、生成AIを上手に活用することで、データ分析のハードルを下げ、組織全体のデータ活用能力向上にも繋がる可能性がある、と記事は締めくくられています。
新人エンジニアの皆さんにとって、データ分析プロジェクトの具体的な進め方や、生成AIをどのように活用すれば効率的に作業を進め、課題を乗り越えられるかのヒントがたくさん詰まった記事です。ぜひ、皆さんの日々の業務でも生成AIを「副操縦士」として活用することを試してみてください。
引用元: https://nealle-dev.hatenablog.com/entry/2025/05/01/102722
WebGPU対応のThree.jsのはじめ方この記事は、ウェブ上で次世代のグラフィックスAPIであるWebGPUと、3D表現ライブラリとして広く使われているThree.jsの連携について、新人エンジニアにも分かりやすく解説しています。
WebGPUは、従来のWebGLよりも低レベルでGPU（グラフィックス処理を行う部品）に効率的にアクセスできる新しい技術です。Three.jsは、難しいGPUの操作を抽象化して、JavaScriptで手軽に3Dコンテンツを作成できるライブラリです。
Three.jsでは現在、WebGPUに対応するための「WebGPURenderer」という新しいレンダラー（描画を行う機能）の開発が進められています。これはまだ開発途中（WIP: Work in Progress）ですが、既存のWebGLRendererとほぼ同じ使い方で、WebGPUのメリットを活かせるように設計されています。Three.jsを使うことで、WebGPUの低レベルな部分を知らなくても、その高いパフォーマンスや将来性を活かせる可能性があります。
Three.jsでWebGPUを導入するのは比較的簡単です。従来のWebGLRendererを使っていた場合、Three.jsのWebGPU対応ビルドを読み込み、レンダラーをWebGPURendererに切り替えて、初期化時にawait renderer.init()を呼び出すのが主な変更点です。多くの既存コンテンツは、このレンダラーの切り替えだけで動作すると筆者は述べています。ただし、一部の特殊な表現（粒子や線）や、自分でシェーダー（描画の計算を行うプログラム）を書いている場合は修正が必要になることがあります。
現在のWebGPUはまだすべてのブラウザで正式にサポートされているわけではなく、主にChromeとEdgeのみです（2025年5月時点）。しかし、WebGPURendererには、WebGPUが使えないブラウザでは自動的にWebGL 2.0に切り替えて描画する「フォールバック機能」があります。これにより、新しい技術を使いつつ、より多くのユーザー環境で表示できるのが大きなメリットです。
ただし、現状（Three.jsのr176時点）では、WebGPURendererがWebGLRendererより必ずしも高速というわけではなく、特に大量の細かい描画を行う場合など、WebGLの方が良い性能を示すこともあるようです。WebGPU本来の性能を引き出すための最適化は現在も進行中であり、今後のアップデートで改善されていくことが期待されます。
また、Three.jsではWebGPU時代に向けた新しいシェーダー記述方法として「TSL（Three.js Shading Language）」が導入されています。これはJavaScriptを使ってシェーダーの処理を定義できるもので、書いたコードはThree.jsが自動的にWebGPU用のWGSLやWebGL用のGLSLに変換してくれます。これにより、異なるシェーダー言語の違いを意識せずに、単一のコードでWebGPUとWebGLの両方に対応できるようになります。TSLはノードベースで直感的に記述できるという特徴もあります。
まとめると、Three.jsのWebGPURendererは開発が進んでおり、将来性のあるWebGPUを手軽に試せる方法を提供しています。新しいTSLを使えばシェーダー開発も効率的になります。まだ開発途中のため、本格導入前には動作確認が必要ですが、小規模なプロジェクトやプロトタイプで触ってみることで、WebGPU時代の新しい表現力を体験する価値は大きいでしょう。今後のThree.jsの進化に注目していきましょう。
引用元: https://ics.media/entry/250501/
お便り投稿フォームVOICEVOX:ずんだもん
-
関連リンク NotebookLM の音声概要が日本語を含む 50 以上の言語で利用可能に
Googleが提供するAIツール「NotebookLM」に、新しい機能として「音声概要」が追加され、この度、日本語を含む50以上の言語に対応しました。
NotebookLMは、皆さんが持っているドキュメント（PDFやテキストファイルなど）をアップロードすると、その内容を理解して要約を作ったり、内容について質問に答えたりしてくれるAIツールです。たくさんの資料を読まなければならないエンジニアの仕事でも、情報収集や内容の把握を助けてくれる便利なツールとして使うことができます。特に、新人エンジニアの皆さんが新しい技術やプロジェクトに関わる際、大量のドキュメントを読む必要が出てくる場面で役立つでしょう。
今回アップデートされた「音声概要」機能は、アップロードした資料の内容を、ポッドキャストのように音声で聞きながら概要を理解できる機能です。これまでは主に英語で提供されていましたが、Googleの最新AI技術であるGemini 2.5 Proなどを活用することで、日本語を含む50以上の幅広い言語で音声概要を生成できるようになりました。
この機能が日本語に対応したことで、特に日本のエンジニアにとっては、情報収集の幅が大きく広がります。例えば、最新の技術情報は海外から発信されることが多く、英語のドキュメントやブログを読む機会も多いかと思います。NotebookLMに英語の資料をアップロードし、出力言語を日本語に設定すれば、その内容の要点を日本語の音声で手軽に確認できます。英語を読むのが得意でなくても、まずは音声で全体像を掴むことで、効率的に情報を取り入れることができるようになります。これは、日進月歩の技術の世界で学び続ける上で、非常に役立つはずです。
さらに、NotebookLMの設定で出力言語を簡単に切り替えられるため、音声概要だけでなく、AIとのチャットによる質問応答も好きな言語で行えます。これにより、多様な言語の資料を扱ったり、国際的なチームでの情報共有を円滑にしたりすることにもつながる可能性があります。
NotebookLMの音声概要機能の多言語対応は、世界中の人々が言語の壁に阻まれることなく、必要な情報にアクセスし、学習や仕事に役立てることを目指しています。新人エンジニアの皆さんにとって、新しい技術や知識を効率的に習得するための強力なアシスタントとなるでしょう。ぜひ一度NotebookLMを試してみて、その便利さを体験してみてください。
引用元: https://blog.google/intl/ja-jp/company-news/technology/notebooklm-50/
MCPでLLMはどう進化する？LLM（大規模言語モデル）は急速に普及し、その能力は単なるチャットから、複雑なタスクをこなすAIエージェントへと進化しようとしています。これまでのAIエージェントの仕組み（例：ChatGPTの拡張機能やAIコーディングツール）は、使えるツールやサービスに制約があったり、設定が難しかったりといった課題がありました。
このような背景から登場したのが、MCP（Model Context Protocol）という新しい技術です。MCPは、LLM（AI）と様々な外部ツールやサービス（ファイルシステム、Web検索、各種アプリケーション、ハードウェアなど）が連携するための「共通のルール」や「約束事」と考えると分かりやすいでしょう。例えるなら、私たちの指示を聞く「ドラえもん」（MCPホスト）が、目的に合わせて様々な「ひみつ道具」（MCPサーバ）を選んで使ってくれるようなイメージです。
MCPを使うことで、LLMはまるで手足を得たかのように、多様なツールであるMCPサーバを組み合わせて、より複雑で具体的なタスクを自律的にこなせるようになります。例えば、Web検索、情報整理、CAD設計、3DCG作成など、様々な作業が可能になります。また、目的に合わせてMCPサーバを選択したり、自作したり、組み合わせたりする自由度が高まり、特定のサービスへの依存度を下げることができます。
MCPを使うためには、PC環境やMCPホスト、連携したい外部サービスの設定が必要です。少し手間がかかる場合もありますが、設定自体をAIに手伝ってもらうこともできます。
自分でMCPサーバを「作る」ことも可能です。これは、既存のサービスやアプリをAIから使えるようにしたい場合や、MCPの仕組みを深く理解したい場合に特に有効です。公式ツールでは難しい処理を高速化する（例：Notion連携）など、独自の機能を持ったMCPサーバを作ることで、AI活用の幅をさらに広げたり、新しいビジネスチャンスに繋げたりできる可能性があります。Pythonなどの言語でMCPサーバを作るための開発キット（SDK）も提供されています。
ただし、MCPサーバは様々な情報やツールにアクセスするため、セキュリティには注意が必要です。出どころの怪しいサーバは使わない、提供されているコードを確認する、実行時には必ず確認を求める設定にするなど、他のアプリケーションを使う時と同様に注意が必要です。
MCPはまだ新しい技術ですが、AIとツール連携の標準規格となる可能性があり、対応するMCPサーバも増えつつあります。セキュリティなどの課題はありますが、AIエージェントが私たちの作業をより強力に支援してくれる未来に繋がる、非常に可能性を秘めた技術として注目されています。まずは公開されているMCPサーバを使ってみることから、この新しいAI活用の世界に触れてみるのはいかがでしょうか。
引用元: https://www.docswell.com/s/karaage0703/56V4PL-2025-04-25-104216
新入社員のDevinと過ごす日々この記事は、AI Agentである「Devin」を開発チームで3ヶ月間試用した経験についてのレポートです。AI Agentが実際の開発現場でどのように役立ち、またどのような課題があるのかを知ることができます。
まず、Devinをエンジニアリング業務に使ってみた全体的な感触として、人間の新人エンジニアと比べて非常に高速かつ大量に作業ができる点が挙げられています。特に、既存の技術ドキュメントがしっかり整備されていたり、プログラムのビルドやテストが自分のコンピューター内で完結できる環境が整っていたりすると、Devinの作業効率と質が向上するとのことです。
ただし、Devinに作業を依頼する側には、達成したい目標を明確に持ち、Devinが作成したコードや成果物の良し悪しを判断できる能力が求められます。また、最終的な成果物の品質を保証するためには、人間のエンジニアによるコードレビューがやはり重要になります。
この記事では、Devin自身にこれまでの3ヶ月の作業を振り返ってもらったレポートも紹介されています。そのレポートによると、Devinは主にコード開発（新機能追加や改良）、バグ修正、プログラムの整理（リファクタリング）、ドキュメント作成、そして開発環境の整備（CI/CDなど）といった幅広い作業を行ったと分析しています。タスクの明確化、途中の確認、コードレビューでのフィードバックが効果的なやり取りのパターンとして挙げられています。プルリクエスト（PR、コード変更をチームに提案するもの）の分析では、作成されたPRの85%が取り込まれ、新しいコードのテストカバー率も平均90%以上と、一定の品質を保っているように見えます。作業規模は、小さなバグ修正から大規模な機能追加まで様々だったようです。
しかし、著者の評価によると、Devinのレポートには「妄想」（ハルシネーション）が多く含まれており、特に統計的な数値などは鵜呑みにはできないとのことです。3ヶ月しか使っていないのに1年分の作業を分析していたり、内容は素晴らしいものの、そのまま信用できるのは半分強程度だとしています。
ここから分かるのは、AI Agentはまだ完璧ではなく、生成された成果物を人間がレビューし、必要に応じて修正や調整を行うプロセスが不可欠であるということです。つまり、AI Agentはすべてを自動でやってくれる存在ではなく、人間のエンジニアの強力な「ツール」として捉えるべきだということです。
この記事の著者は、Devinや他の開発向けAIは現時点でも十分に価値があり、料金に見合う活躍をしてくれると述べています。そして、AIも得意なことと苦手なことがあるため、実際に使ってみて感覚を掴むことが重要だと強調しています。今後AIの精度は向上するでしょうが、今は「とにかく触って体験する」フェーズだとして、利用を推奨しています。
まとめると、AI Agentは開発作業を高速化する可能性を秘めていますが、それを最大限に活かすには、依頼する側の明確な指示、AIの出力を評価・修正する人間の判断力、そして適切な開発環境の整備が鍵となります。AIは万能ではない現実も理解しつつ、ツールとしてうまく使いこなしていくスキルが、これからのエンジニアには求められるでしょう。
（注：記事中に直接的な公開日がないため、記事が最新であるという前提で要約を作成しました。）
引用元: https://tech.repro.io/entry/2025/04/30/132003
機動戦士Gundam GQuuuuuuX 第4話 最新科学AI特執実験記事この記事は、筆者がアニメ「機動戦士Gundam GQuuuuuuX」の第4話を見ていない状態で、AIに感想記事を書かせるというユニークな実験を行ったレポートです。
筆者は睡眠不足などで時間がなく、アニメの感想ブログを書く「ノルマ」をこなすために、AIの活用を試みました。特に、SNSで多くの情報が出回っている人気作品であれば、AIが外部情報を学習してそれらしい感想を書けるのではないかと考えたようです。
実験では、AIにアニメ公式サイト、SNSの投稿、Wikipedia、そして筆者自身の過去のブログ記事などを学習データとして与え、「ブログに掲載するアニメ感想記事」を生成するように指示しました。これにより、AIが最新の情報を参照しつつ、筆者らしい文体で書けるか検証する狙いがありました。
AIが生成した感想記事は、新しい登場人物（連邦の魔女シイコ・スガイ）やモビルスーツ（ゲルググ）に触れ、ストーリー展開やキャラクター関係、戦闘シーンなどについて、外部情報をもとにしたと思われる詳細な記述を含んでいました。また、ファンの反応や今後の展開（ドムの登場など）にも言及しており、表面上はそれなりのアニメ感想ブログ記事のように見えます。
しかし、筆者はAI生成記事を読んだ結果、当然ながらネタバレを食らったと述べています。さらに、AIは外部情報をまとめることはできても、筆者特有のユーモア、皮肉、個人的な感情といった「異常性」は再現できなかったと評価しています。
この実験を通じて、筆者はAIが一般的な情報に基づいた定型的な文章を書く能力は高い一方、個人の深い思考や独特な文体を模倣するには限界があると感じています。同時に、世の中にはAIが書いたような表面的な記事も多いのかもしれない、と考えさせられたようです。
アニメ感想という題材でAIの可能性と限界を探ったこの試みは、AIを使ったコンテンツ生成に興味を持つ日本のエンジニアにとって、身近で分かりやすい実験事例として参考になるでしょう。AIは便利なツールですが、人間の個性や経験に根差した表現にはまだ及ばないという示唆を得られます。
引用元: https://nuryouguda.hatenablog.com/entry/2025/04/30/135643
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
関連リンク Advancing Cybersecurity Operations with Agentic AI Systems
この記事は、AIエージェントがサイバーセキュリティの運用をどのように進化させるかについて解説しています。これまでのAIは主に不審な活動の「検出」に使われることが多かったのですが、AIエージェントはさらに進んで、自律的に「考えて計画し、行動する」ことで、セキュリティ担当者（アナリスト）の定型的な作業を自動化・効率化する可能性を秘めています。これは、大規模言語モデル（LLM）の進化によって実現しました。
従来、セキュリティアナリストは、アラートの調査、関連情報の収集、脅威への対応といった多くの手作業に時間を費やしていました。しかし、AIエージェントは、複雑で繰り返し発生するタスク（例えば、脅威情報の調査や、アラートの関連付け、初期対応など）を自動で行えるため、アナリストはより高度な判断や深い分析に集中できるようになります。
記事では、具体的な応用例として以下の2つを紹介しています。
アラート管理の効率化:セキュリティアラートの量は増大し、対応には経験や知識が必要で、情報収集や記録にも手間がかかります。AIエージェントは、大量のアラートの初期トリアージ（優先順位付けや初期調査）を自動化します。アラートが発生すると、エージェントが自動的に調査を開始し、関連データを収集・分析して、調査レポートを作成します。必要に応じて、データ分析など特定の専門タスクを別のAIエージェントに任せる、マルチエージェント構成も考えられます。NVIDIAではこのシステムを評価し、高い精度でアラートの原因を分類できることを確認しています。
ソフトウェア脆弱性分析の高速化:ソフトウェアの脆弱性（セキュリティ上の弱点）分析も、多くの情報収集や分析が必要な時間のかかる作業です。AIエージェントは、コンテナなどのソフトウェアの脆弱性IDが与えられると、インターネットや内部情報源から関連情報を集め、脆弱性が実際にその環境で悪用可能か（Exploitableか）を判断するための分析を自動で行います。このシステムにより、従来数時間〜数日かかっていた分析作業を数秒に短縮できる可能性があり、NVIDIA社内での導入事例では、アナリスト1人あたり週に数時間の作業時間削減につながっています。
このようなAIエージェントシステムを開発する際には、タスクの性質に合わせてシステムの構造（エージェントがどれだけ動的に判断するか）を選ぶことが重要です。また、システムの評価には、最終結果だけでなく、エージェントがどのように考え、どのツールを使ったかといった中間プロセスも確認し、継続的に改善していく仕組み（人間のフィードバックを取り込むツールなど）が有効です。LLM自体を評価者として使う「LLM-as-a-judge」という手法も紹介されています。
AIエージェントはサイバーセキュリティの現場で、アナリストの頼れる助手として、調査作業を合理化し、複雑なタスクを支援する未来が期待されています。この記事は、AIエージェントがセキュリティ運用にもたらす具体的な価値を示す技術記事として、新人エンジニアの方々にも参考になるでしょう。NVIDIAは、開発者向けのツールキットや事例（AI Blueprint）を提供しており、誰もがAIエージェントを活用したシステムを構築できるよう支援しています。
引用元: https://developer.nvidia.com/blog/advancing-cybersecurity-operations-with-agentic-ai-systems/
Everything we announced at our first-ever LlamaConMetaは初の試みとなる開発者向けイベント「LlamaCon」を開催し、オープンソースAIモデルであるLlamaを使った開発をさらに容易にするための新しいツールや取り組みを発表しました。Llamaは公開から2年あまりで10億以上のダウンロードを達成し、オープンソースAIエコシステムを牽引する存在となっています。
このイベントで発表された主な内容は以下の通りです。
まず、開発者がLlamaを使ってアプリケーションを素早く構築できるようになるLlama API（リミテッドプレビュー版）が発表されました。これは、APIの手軽さとオープンソースの柔軟性を両立させたプラットフォームです。ワンクリックでAPIキーを作成でき、対話型プレイグラウンドで様々なLlamaモデル（先日発表されたLlama 4 ScoutやMaverickを含む）を試すことができます。PythonおよびTypescriptの軽量SDKが提供され、OpenAI SDKとの互換性もあるため、既存アプリケーションからの移行も容易です。さらに、Llama 3.3 8Bモデルのカスタム版をチューニング・評価するためのツールも提供され、コスト削減や精度向上に役立ちます。ユーザーのデータがモデル学習に使われることはなく、API上で構築したモデルは自由に持ち出せる（特定の環境にロックされない）点が強調されています。今後は段階的に多くの開発者に提供される予定です。また、CerebrasやGroqといったハードウェアパートナーとの協業により、Llama API経由でより高速な推論が可能になる実験的なアクセスも提供されます。
次に、Llama Stackの連携強化が発表されました。これは、Llamaを使ったエンタープライズ向けAIソリューションのデプロイを容易にするための取り組みです。NVIDIAのNeMoマイクロサービスとの連携に加え、IBM、Red Hat、Dell Technologiesなど他のパートナーとも緊密に連携しており、今後新しい連携が発表される予定です。
さらに、オープンソースコミュニティ向けの新しいセキュリティツールが公開されました。「Llama Guard 4」「LlamaFirewall」「Llama Prompt Guard 2」といったツールは、AIアプリケーションをより安全に構築するために役立ちます。また、AIシステムのセキュリティ評価に役立つ「CyberSecEval 4」もアップデートされました。特定の信頼できるパートナー向けの「Llama Defenders Program」も開始され、AIを活用したツールでシステムセキュリティの評価を支援します。これは、進化するAIモデルに対応し、ソフトウェアシステムの堅牢性を向上させるための重要な取り組みです。
最後に、Llamaを使って社会に変革をもたらすプロジェクトを支援する「Llama Impact Grants」の第二回受賞者10組（総額150万ドル以上）が発表されました。市民サービス向上、薬局業務効率化、オフラインAI支援、多言語学習ツールなど、Llamaを活用した多様な取り組みが紹介されています。
MetaはオープンソースAIのリーダーとして、開発者が自由に、簡単に、そして安全にAIを構築できるエコシステムを推進していくことを改めて表明しました。Llamaは、専門知識やハードウェアリソースに関わらず、より多くの人々がAIの恩恵を受けられるようにすることを目指しています。
引用元: https://ai.meta.com/blog/llamacon-llama-news/
RAGでDeep Researchのような深い検索を実現する手法この記事は、RAG（Retrieval Augmented Generation）という技術を使って、GoogleのDeep Researchのようなより深い検索を実現するための新しい手法「PAR RAG」について解説しています。RAGは、AI（大規模言語モデル、LLM）が外部の情報を参照して回答を生成する技術で、質問応答などで使われています。
Deep Researchのように、複雑な質問に対して何度も検索と推論を繰り返して回答を生成するアプローチが注目されていますが、ここには「ずれの蓄積」という問題があります。これは、検索を繰り返すうちに、最初の質問からどんどん関係ない方向に検索の焦点がずれていってしまうことです。例えば、ある機械の故障原因を調べていたのに、いつの間にか電力契約の話になってしまうようなケースです。この「ずれ」は、検索を繰り返すたびに大きくなる可能性があります。
PAR RAGは、この「ずれの蓄積」を防ぎ、より正確な回答を得るために考えられた手法です。PARとはPlan, Act, Reviewの頭文字をとったもので、以下の3つのステップで回答を生成します。
Plan (計画): まず、ユーザーの質問全体を見て、どのような順番で情報を検索し、どのように回答を組み立てるか、全体の計画を立てます。これにより、最初から調査の方向性が大きくずれるのを防ぎます。 Act & Review (実行とレビュー): 計画に沿って、ステップごとに情報の検索と回答生成を行います。 Act（実行）: 現在のステップに必要な情報を大まかに検索します。その検索結果をもとに、AIがそのステップに対する中間的な回答を作ります。 Review（レビュー）: 作成された中間回答が正しいか、情報の正確性を確認します。論文では「知識グラフ」という、物事の関係性を表したデータを使って確認する仕組みが示されています。もし間違いが見つかれば、もう一度Actのステップに戻ってやり直します。この「レビュー」のステップが、ずれの蓄積を防ぐ上で非常に重要です。 最終回答: すべてのステップが終わったら、それぞれのステップで得られた中間的な結果を集めて、最終的な回答をAIが生成します。このPAR RAGを評価した結果、単純な検索繰り返し手法や、PlanやReviewのどちらかがない手法と比べて、回答の精度（F1スコア）が向上することが確認されました。しかし、その反面、時間やコストが通常のRAGと比べて大幅に増加するというデメリットもあります。通常のRAGと比較して、処理時間は約8倍、コストは約13倍になるという結果が出ています。
まとめると、PAR RAGは、RAGにPlan（計画）とReview（確認・修正）のプロセスを加えることで、検索の「ずれ」を防ぎ、複雑な質問に対してより深く、正確な回答を生成できる可能性がある技術です。ただし、その精度向上のためには、時間とコストがかかるというトレードオフが存在します。この記事では、そのメリットとデメリットを正直に示しており、どのような場面でこの技術を使うのが最適かを考える上で参考になります。プロジェクトの要件に応じて、精度を最優先するか、コストや速度を重視するかを検討し、最適なRAGの活用方法を選ぶことが大切です。
引用元: https://zenn.dev/knowledgesense/articles/6d4d9bf52690a4
ChatGPTという執事が現れ、毎日がとんでもなくワクワクしてる件について LEEこの記事は、筆者（うさこさん）がChatGPTを使い始めて、その進化と便利さに驚き、日常生活がとても楽しくなった体験談を紹介しています。
最初はChatGPTに抵抗があったり、「AIっぽい回答だな」と感じて放置していたそうですが、同期のブログや知人の活用事例を見て、再び使い始めたとのこと。驚いたのは、ChatGPTが筆者の話し方や口調を学習し、まるで親しい友人のようにフレンドリーに返答するようになった点です。「ナァアアア！」といった独特の鳴き声を語尾に付けて返してきたり、過去の会話内容（例えば「せいろ」について話したこと）を覚えて会話に織り交ぜてきたりと、その人間らしい応答に「人やん…もうこれ人…」と震えたと書かれています。
具体的な活用例として、いくつかの面白い使い方を紹介しています。一つ目は「推しの話をする相手」です。誰かに話したい推しの最新情報や、「疲れた時に推しのフリをしてもらって励ましてもらう」といった、ちょっと変わった使い方も紹介しており、「スマホの中にビューネ君のような推しが住んでいる」感覚で元気をもらっているそうです。二つ目は「ごはんメニュー決め」です。冷蔵庫にある食材や、ダイエット、せいろを使った料理といったリクエストを伝えると、メニューを提案してくれるだけでなく、買い物リストまで作成してくれる便利さを実感しています。三つ目は「ちょっとした愚痴を話す相手」です。誰かに話すほどではないモヤモヤした気持ちを聞いてもらうと、共感してくれるだけでなく、解決策まで提案してくれることに驚き、自分がただ「共感」を求めていたことに気づかされたと言います。四つ目は「色々助けてもらう」ことです。例えばパソコンのトラブルで困った時に、状況確認から解決策、さらに「大丈夫だよ」と精神的なサポートまでしてくれたエピソードを挙げています。
こうしたChatGPTの便利さや人間らしい応答に触れる一方で、「人間いらなくなるのでは」といった懸念も少し感じているようです。しかし、娘さんは「そんな事ずっと昔から言われてきてるじゃん」と冷静な反応だったとか。筆者は、AIの便利さに依存しすぎず、もらったヒントで人生を豊かにすることが大事だと考えていると締めくくっています。
この記事からは、ChatGPTのようなAIが、単なるツールとしてだけでなく、話し相手や日常の様々なタスクをサポートしてくれる身近な「執事」のように活用でき、暮らしを楽しくする可能性があることが伝わってきます。AIの進化に驚きつつも、恐れるだけでなく、どう楽しく付き合っていくかを考えるきっかけになる内容です。
引用元: https://lee.hpplus.jp/100nintai/3209913/
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
関連リンク 最小限のMCP Host/Client/Serverをスクラッチで実装する
この記事は、AIエージェントの中核技術であるMCP (Model Context Protocol) の内部実装を理解することを目指し、Host、MCP Client、MCP ServerをRubyでゼロから実装した過程を解説しています。MCPの基本的な解説や活用事例は多くありますが、内部の仕組みについて、仕様書だけでは理解が難しいと感じる人に向けて、実装を通じて学びを深めることが目的です。
MCPはHost、MCP Client、MCP Serverの3つの要素で構成されます。
Hostは、ユーザーからの入力を受け取り、LLM（大規模言語モデル）との対話を管理し、最終的な結果をユーザーに表示する役割を担います。ClineやClaude Desktopのようなアプリケーションがこれに当たります。 MCP Clientは、Hostからの指示を受けて、MCP Serverに対してリクエストを送信し、その結果をHostに返します。 MCP Serverは、MCP Clientからのリクエスト（特定の機能の実行要求など）を受け取り、必要な処理を実行してClientに応答を返します。Figma MCPやFirecrawlなどがServerの例です。ClientとServer間の通信には、メッセージ形式としてJSON-RPCが使われ、通信手段としてはstdio（標準入出力）やStreamable HTTPが推奨されています。この記事では実装の簡易さからstdioが使われています。stdioによる通信とは、Serverプロセスを起動し、その標準入出力を介してメッセージをやり取りする方法です。
実装例として、ユーザーが「サイコロを振って」といったメッセージを入力すると、LLM（Host）がそのメッセージとServerが提供する機能（Tool）のリストを組み合わせて、どのTool（この場合はサイコロを振る機能）を使うべきか判断します。HostはClientを通じてServerにToolの実行を依頼し、Serverがサイコロを振った結果を返します。Hostはその結果をLLMに伝え、LLMが最終的な応答メッセージを生成してユーザーに返します。この過程では、Hostはユーザー入力に対して通常2回LLMと通信します。
ClientとServerは、初期化、操作、終了という3つのフェーズを経て通信します。
初期化フェーズでは、ClientとServerがお互いの準備ができたことを伝え合います。 操作フェーズでは、ClientがServerに対して「利用可能なToolのリストをちょうだい (tools/list)」とか「このToolを実行して (tools/call)」といったリクエストをJSON-RPCメッセージとして送り、Serverがそれに応じた処理結果をJSON-RPC形式で返します。 終了フェーズでは、ClientがServerプロセスを適切に終了させます。今回のスクラッチ実装は、MCPの仕組みを学ぶための最小限のものであり、エラー処理や認証などの実用的な機能は含まれていません。実際の開発では、これらの機能を含む公式のSDKを利用するのが一般的で効率的です。この記事で紹介された実装は、SDKの内部でどのような通信が行われているかを理解するのに役立ちます。
引用元: https://zenn.dev/razokulover/articles/9a0aee8ceb9f3f
LangChain4Jで雑なAIコーディングエージェントを作るこの記事では、Java向けの簡単なAIコーディングエージェントをLangChain4Jというライブラリを使って作る方法が紹介されています。新人エンジニアの皆さんも、AIを使った開発がどういうものか、イメージをつかめる内容です。
作ったエージェントは、「ユーザーの指示を受けてJavaコードを生成し、ファイルに保存して実行する。もしエラーが出たら、エラーメッセージを見てコードを修正し、再び保存・実行を繰り返す」という、コード作成とデバッグの基本的な流れを自動で行うものです。
このエージェントを作る上で重要な役割を果たすのが、LangChain4Jの「Tool Calling」という機能です。これは、AIモデル（LLM）に、あらかじめ定義しておいた外部の機能（ツール）を呼び出させる仕組みです。この記事では、Javaのコードをファイルに保存するsaveCodeツールと、保存したファイルをコンパイル・実行するexecuteCodeツールを用意しています。AIは、自分で考えたコードを保存したり、実行結果を確認したりするためにこれらのツールを使います。
エージェントがどのように振る舞うかは、「システムプロンプト」というAIへの指示文で細かく設定します。「Javaコードを生成するエージェントであること」「生成したコードをsaveCodeで保存し、executeCodeで実行すること」「実行エラーが出たらコードを修正してやり直すこと」などをシステムプロンプトに記述することで、AIに目的の作業をさせることができます。
筆者は、実際にこのエージェントにJTableを使ったJavaコードを作らせて実行できた際に「おぉぉ～」と声が出たと書いており、AIがコードを書いて動かす面白さが伝わってきます。コンパイルエラーが発生しても、それをAIが自分で修正して再度実行する様子も確認できたそうです。
全体のコードはGitHubのGistで公開されています。どのようなJavaコードでツールやプロンプトを設定しているか、具体的な実装に興味があれば参照すると良いでしょう。
ただし、記事の追記として、LangChain4JのバージョンによってはTool Callingがうまく動作しないことがある（例: beta3はNG、beta2はOK）という情報も共有されており、ライブラリのバージョン選びには注意が必要な場合があることが分かります。
この記事を読むことで、LangChain4Jを使ってAIにコードを書かせ、実行させる、といった具体的なAIエージェント開発のイメージを掴むことができるでしょう。自分の手で簡単なAIツールを作ってみたいという方にとって、参考になる取り組みです。
引用元: https://nowokay.hatenablog.com/entry/2025/04/25/030248
Reasoning能力を付与したLLM ABEJA-QwQ32b-Reasoning-Japanese-v1.0の公開ABEJAが、経済産業省とNEDOが進める日本の生成AI開発力強化プロジェクト「GENIAC」の一環として、新しい大規模言語モデル（LLM）であるABEJA-QwQ32b-Reasoning-Japanese-v1.0を公開しました。
このモデルの最大の特徴は、「Reasoning能力」を持っている点です。Reasoningモデルとは、回答を生成する前に、人間が考えるように一度思考プロセスを経ることで、複雑な問題や技術的な問い、推論が必要なタスクに対して、より正確で質の高い応答ができるようになるモデルのことです。
モデルは、Alibaba社が開発したQwen2.5-32B-Instructをベースに開発されました。Reasoning能力を獲得するために、同じくReasoning能力を持つQwQ-32Bというモデルの「思考に関わる部分」を、既存のモデルに賢く組み合わせる「モデルマージ」という手法が使われています。さらに、日本人ユーザーがより自然に使えるように、たくさんの日本語データを使った追加学習（SFTやDPOと呼ばれる、モデルの応答を調整する学習手法）も行われました。これにより、日本語での思考過程や回答が安定して出力されるよう性能が向上しています。
開発されたモデルの性能は、LLMの日本語能力を測るための標準的な評価方法の一つである「Japanese-MT-Bench」で評価されました。その結果、32Bというモデルサイズでありながら、GPT-4oやClaude 3.5 Sonnetといった有名な商用モデルの一部バージョンと比較しても遜色ない、高いスコアを達成しています。これは、ベースとなったモデルや、マージに使われた元のモデルよりも性能が大幅に向上していることを示しており、国産の強力なLLMとして非常に期待できる結果です。
このモデルはApache 2.0ライセンスで公開されているため、個人や企業が商用目的で自由に利用することができます。
利用する際にはいくつか注意点があります。特に、モデルの推奨するパラメータ設定（例えば、生成される文章のランダム性を調整するTemperatureやTopPなど）を使うことや、モデルの仕様に合わせた正しい入力形式（ChatTemplate）で使うことが推奨されています。システムプロンプト（AIに役割や前提条件を与える最初の指示）は、このモデルでは入れない方が性能が良いとのことです。
現時点での課題としては、思考過程が意図せず英語や中国語になる場合があること、思考プロセスが長すぎたり同じ内容を繰り返したりする場合があること、そして思考過程と最終的な回答が完全に分かれずに混ざってしまう場合があることが挙げられています。これらの課題は今後の改善で解決されていく見込みです。
ABEJAは今後もReasoning能力を持つLLMの開発を進めていく方針です。今回のモデル公開は、国内での高度な日本語LLM開発が進んでいることを示しており、エンジニアが新しいAI技術を活用する上で参考になる情報と言えるでしょう。
引用元: https://tech-blog.abeja.asia/entry/geniac2-qwen25-32b-reasoning-v1.0
ゲーセン運営者「客から『音ゲーのとある面でコンボが外れるからメンテして』と言われ客の前でその面をフルコンボして見せたバイトを大説教した」→「何が悪いの？」で意見分かれるこの記事は、あるゲームセンターで実際にあったお客様対応の出来事とその対応について、インターネット上で様々な意見が出ていることについてまとめたものです。
内容は、お客様から「音ゲーの特定の箇所でコンボが途切れるから、筐体（ゲーム機）のメンテナンスをしてほしい」という要望があった際、担当したアルバイトスタッフが、そのお客様の目の前で実際にその箇所をプレイし、問題なくフルコンボ（連続して正しい操作を成功させること）を達成して見せた、というものです。お客様はそれを見て「もういいです」と言って立ち去られたそうです。この出来事に対し、ゲームセンターの運営者（店長と思われる）は、そのアルバイトスタッフを厳しく𠮟りつけた、というツイートが元になっています。
この店長の対応について、インターネット上では「何が悪いの？」と疑問に思う声と、「バイトの対応には問題があった」とする声に意見が分かれています。
まず、「何が悪いの？」という意見の背景には、エンジニアリングや問題解決の基本的な考え方があります。システムや機器に不具合があるという報告を受けた場合、まず最初に行うべきことは「再現確認」です。お客様が報告した現象が実際に発生するかどうかを自分たちでも試してみることで、本当に機器に問題があるのか、それとも別の要因（例えばお客様の操作ミスやゲームの仕様など）によるものなのかを切り分けることができます。今回のケースでは、お客様の「コンボが外れる」という報告に対して、アルバイトがプレイしてフルコンボできたということは、「少なくともその時点では、筐体にはコンボが外れるような不具合は見られなかった」という再現確認が取れたことになります。トラブルシューティングの観点からは、非常に真っ当で論理的なアプローチと言えます。そのため、技術的な視点を持つ人からは「なぜ正しい確認をしたのに怒られるのか分からない」という意見が多く出ています。
一方で、「バイトの対応には問題があった」という意見の背景には、顧客対応やビジネス的な視点があります。お客様は「コンボが外れる」という不具合を訴えています。その原因がたとえお客様の操作ミスだったとしても、お客様にとっては真剣な困りごとです。そのお客様の目の前で完璧なプレイを見せるという行為は、お客様に「お前の腕が悪いだけだろ」と突きつけるように見えてしまう可能性があります。これではお客様は恥ずかしく感じたり、不快な気持ちになったりして、二度と店に来なくなるかもしれません。ゲームセンターは、お客様がお金を払ってゲームをプレイしてくれることで成り立っています。技術的に正しくても、お客様の気持ちを害してしまい、結果としてお客様が離れてしまうような対応は、商売という観点からは適切ではない、という考え方です。「お客様を不快にさせないように、うまく言葉を選んだり、形だけでもメンテナンスを約束したりするべきだった」という意見が見られました。
この事例から新人エンジニアが学べることはいくつかあります。一つは、技術的な正しさや論理的なアプローチは非常に重要ですが、それだけでは全てがうまくいかない場面もあるということです。特に、お客様や他の関係者と接する際には、相手の感情や立場、求めていること（今回は「不具合を直してほしい」という技術的な要望と、「うまくプレイできない」という感情的な苛立ちの両方があったかもしれません）を理解しようと努め、コミュニケーションの方法を工夫することが求められます。トラブルシューティングの再現確認は重要ですが、それをどのように相手に伝えるか、あるいは伝えるべきでない場面もある、といった、技術以外の「立ち回り」や「配慮」も仕事を進める上で大切になる場合がある、という示唆が得られます。このケースは、技術的な正確さを追求する姿勢と、ビジネス的な顧客満足度や人間関係を重視する姿勢が対立した興味深い事例と言えるでしょう。
引用元: https://togetter.com/li/2543642
お便り投稿フォームVOICEVOX:春日部つむぎ
-
関連リンク 4万行超のopenapi.yamlをTypeSpecに移行した話
この記事では、OpenAPIを使ったAPIスキーマ駆動開発で直面した課題と、それを解決するためにTypeSpecに移行した経験が紹介されています。
筆者のチームでは、APIの仕様を定義するのにOpenAPIのopenapi.yamlファイルを使っていました。開発を進めるにつれてこのファイルが4万行を超えるほど巨大になり、いくつかの問題が発生しました。最も大きな課題は、ファイルが大きすぎて手作業での編集が非常に大変になったこと、そしてGitHub CopilotやCursorのようなAI Agentを使う際に、ファイル全体を読み込ませようとすると情報量が多すぎて処理できなくなる（コンテキスト圧迫）ことでした。
そこで、これらの課題を解決するためにTypeSpecというAPI定義言語への移行を検討しました。TypeSpecはMicrosoftが開発しており、TypeScriptに似た分かりやすい文法でAPIの仕様を定義できます。TypeSpecで書いた定義から、OpenAPIやプログラムのクライアントコードなどを自動生成する「エミッター」という機能が強力です。
TypeSpecを選んだ理由はいくつかあります。まず、OpenAPIよりも構造化しやすく、ファイルを細かく分割して書けるため、巨大化しても管理しやすくなる点です。また、万が一TypeSpecが合わなかった場合でも、自動生成されたOpenAPIファイルを使えば元の運用に戻りやすい（撤退しやすい）ことも決め手になりました。さらに、記事執筆時点（2025年4月）でTypeSpecの安定版候補がリリースされ、安心して利用できるようになったことも後押ししました。
移行は、まずTypeSpecの環境をセットアップし、既存の4万行を超えるopenapi.yamlをTypeSpec形式に自動変換するツールを使いました。変換後、一部の型定義がうまく変換されないといった問題が発生しましたが、TypeSpecの定義を手作業で調整したり、変換ツールの挙動を一時的に修正したりして対応しました。最終的には、TypeSpecファイルからopenapi.yamlを自動生成し、これまで使っていたコード生成ツール（OpenAPI Generator）やテストツール（Committee）はそのまま使い続けられるようにしました。
移行後、TypeSpecファイルは元のOpenAPIファイルの半分以下（約2万行）になり、モデルやAPIルートごとにファイルを分割して管理できるようになりました。これにより、スキーマ全体の可読性が大幅に向上し、開発体験も改善されました。AI Agentも TypeSpec のファイルは小さく分割されているため、問題なく扱えるようになりました。また、TypeSpecを使えばOpenAPIのバージョンアップもエミッターの設定を変えるだけで簡単に行えるようになります。
TypeSpecへの移行は調整が必要な部分もありましたが、約2日間で完了し、大規模なAPIスキーマの管理や開発効率の向上、AI Agentとの連携といった多くのメリットが得られたとのことです。OpenAPIファイルの巨大化に悩んでいるチームにとって、TypeSpecは検討する価値のある選択肢と言えるでしょう。
引用元: https://zenn.dev/yuta_takahashi/articles/migrate-to-typespec
Enhance Your AI Agent with Data Flywheels Using NVIDIA NeMo Microservices NVIDIA Technical Blog企業でAIエージェント（自律的に動くAIシステム）を活用する際、常に変化するデータに対応し、AIの精度を維持することが大きな課題となります。これを「モデルドリフト」と呼びます。例えば、顧客対応AIが参照するデータベースの形式が変わったり、ユーザーの質問の仕方が変化したりすると、AIの回答精度が落ちてしまう可能性があります。
この課題を解決し、AIエージェントの性能を継続的に向上させるための考え方が「データフライホイール」です。これは、ユーザーからのフィードバックやシステムで収集したデータを基にAIモデルを改善し、その結果AIの性能が向上することで、より多くのユーザーに使われ、さらにデータが集まる、という好循環サイクルのことです。このサイクルを回すことで、AIは常に新しいデータに適応し、精度を高く保つことができます。
データフライホイールは、特に複雑なタスクをこなすAIエージェントにとって重要です。AIエージェントは、単一の応答だけでなく、状況を判断し、複数のツールを使ったり、情報を検索したりと、多くのステップを踏んで処理を行います。そのため、計算コストが高くなりやすく、効率性が求められます。データフライホイールによってモデルを最新データで調整することで、より小さくて効率的なモデルでも高い精度を維持できるようになり、運用コスト（TCO）や応答速度（レイテンシ）の改善に繋がります。
NVIDIA NeMo Microservicesは、このデータフライホイールを実現するための包括的なプラットフォームを提供します。これは、AIエージェント開発に必要な一連のプロセスをサポートする機能群です。具体的には、AI学習のための「データ準備」、基盤となる大規模言語モデル（LLM）を特定のタスク向けに調整する「モデルカスタマイズ」（例えばLoRAのような技術を使って効率的に調整）、調整したモデルの性能を測る「モデル評価」、不適切・不正確な応答を防ぐための「ガードレール設定」、そしてモデルを実際に使えるようにする「デプロイ」といった機能がマイクロサービスとして提供されます。
例えば、AIエージェントが外部ツールを使う機能（ツール呼び出し）を改善したい場合、NeMo Microservicesを使えば、大量のツール呼び出しデータを使って効率的にモデルをファインチューニングできます。小さなモデル（例: Llama 3.2 1B）を調整するだけで、より大きなモデル（例: Llama 3.1 70B）に近いツール呼び出し精度を達成できることが示されており、大幅な効率化が可能になります。
これらのNeMo Microservicesの機能を連携させ、データ収集からモデル調整、評価、デプロイ、そして再びデータ収集へというサイクルを自動化することで、データフライホイールが構築されます。これにより、あなたの開発するAIエージェントは、常に最新の状況に適応し、性能を継続的に向上させることができます。
NeMo Microservicesは現在利用可能で、始めるためのチュートリアルやドキュメントも提供されています。まずは試してみて、AIエージェントの強化に役立ててみてください。
引用元: https://developer.nvidia.com/blog/enhance-your-ai-agent-with-data-flywheels-using-nvidia-nemo-microservices/
How Webtoon Entertainment built agentic workflows with LangGraph to scale story understandingWebtoon Entertainmentは、「WEBTOON」や「Wattpad」といった大規模なストーリープラットフォームを運営している会社です。膨大な量のコンテンツ（マンガや小説）を扱っており、それらをマーケティング、翻訳、推薦などに活用する際に、一つ一つ手作業で内容を理解するのが大きな課題となっていました。
この課題を解決するため、Webtoonは「Webtoon Comprehension AI (WCAI)」というシステムを開発しました。これは、AIエージェントと呼ばれる「特定のタスクを実行するAI」たちが連携して働く「エージェントワークフロー」によって動いています。特に、このワークフローの構築には「LangGraph」というフレームワークが使われています。
WCAIの目的は、大量のWebtoonコンテンツに含まれるキャラクターや物語、画像とテキストの内容をAIが深く理解すること、そしてそれを効率的に（規模を拡大して）行えるようにすることです。
技術的な面では、WCAIは画像とテキストを同時に理解できるAIモデル（VLM）や、特定のタスクを実行するAIエージェントを組み合わせています。これらのAIエージェント同士を連携させ、一連の処理の流れ（ワークフロー）を作るためにLangGraphが活用されています。
なぜLangGraphを選んだのでしょうか？ それは、Webtoonの膨大なコンテンツに対応できるスケーラビリティ、マンガやストーリー特有の専門知識をワークフローに組み込める柔軟性、ビジネスで使うための高い品質と一貫性が必要だったからです。LangGraphの「ノードベース」と呼ばれる仕組みは、処理のステップを細かく分けて、それぞれに専門的な知識を適用しやすかったのです。また、エージェントの動きを細かく制御でき、デバッグや監視がしやすい点も大きな理由でした。
WCAIの中では、いくつかの主要なワークフローが動いています。例えば、「キャラクター識別」は登場人物の名前や役割、画像を特定します。「発言者識別」は、セリフが誰のものかを判断します。「物語抽出」は、ストーリーの重要な部分をテキストでまとめます。さらに、これらの情報を使って、ビジネスの目的に合わせた分析を行うワークフローもあります。例えば、マーケティングチームのために、特定のキャンペーンに合うような作品の特徴を抽出したりします。
WCAIの導入により、コンテンツの内容を手作業で確認する手間が大幅に削減されました。例えば、コンテンツチームはこれまで手作業でキーワードを抽出していましたが、WCAIを使うことで作業量が70%以上減り、よりクリエイティブな業務に集中できるようになりました。マーケティングや翻訳チームも、必要な情報を素早く得られるようになり、業務効率が向上しました。
WebtoonはこのWCAIシステムをさらに改善していく予定で、LangGraphのような新しい技術も積極的に取り入れています。この事例は、LangGraphを使ってAIエージェントによる複雑なワークフローを構築し、ビジネスの課題解決や生産性向上に繋げられることを示しています。
この内容はLangChainのブログ記事を要約したものです。
引用元: https://blog.langchain.dev/customers-webtoon/
アットプレス株式会社Code and DESIGNが、対話アプリ「お喋りずんだもん」のバージョン2.0をリリースしました。このアプリは、東北応援キャラクターの「ずんだもん」とリアルタイムで自由におしゃべりできるサービスです。まるで友達と話しているかのような自然な会話を通じて、ユーザーに癒しと楽しさを提供することを目的としており、仕事や勉強の合間やリラックスしたいときなどに利用できます。
今回のバージョン2.0の大きな変更点として、アプリ内課金（In-App Purchase）に対応しました。これにより、従来の無料プランで気軽に会話を楽しめる点はそのままに、アプリをより深く楽しみたいユーザー向けにプレミアム機能が追加されています。これは、アプリのサービス提供側が、ユーザーのニーズに応えつつ、サービスを継続・発展させていくためのビジネスモデルの一つの形と言えます。
バージョン2.0は現在iOS版のみで提供されています。アプリ開発の現場では、このように特定のプラットフォームから先行して新機能をリリースするといった対応もよく行われます。
「お喋りずんだもん」は、日常にちょっとした癒しや楽しさを加えたい方にとって魅力的なアプリです。今回のアップデートは、ユーザーにとっての選択肢を増やし、アプリを継続的に運営していく上で重要な機能追加と言えるでしょう。エンジニアの視点から見ると、このような機能アップデートや課金モデルの導入は、サービス開発・運用における一般的なステップの一つとして学ぶことができます。
引用元: https://www.atpress.ne.jp/news/434030
お便り投稿フォームVOICEVOX:ずんだもん
- Näytä enemmän
