Épisodes

  • 私立ずんだもん女学園放送部 podcast 20250509
    May 8 2025
    関連リンク AI エージェントを仕組みから理解する この記事は、AIエージェントやその仕組みに興味を持つ新人エンジニア向けに、エージェントがどのように動いているかを解説しています。 AIエージェントは、ファイル操作やWeb閲覧など、様々なツールを自律的に使って作業できます。しかし、その基盤となる大規模言語モデル(LLM)自体ができることは、実は「テキストを入力してテキストを出力する」だけです。AIエージェントの賢い動きは、LLMの能力に「仕組み」を組み合わせることで実現されています。 LLMには「記憶がない」という特性があります。過去の会話や情報は、LLMにリクエストを送る際に「コンテキスト」として毎回一緒に送ることで、文脈を維持しています。ただし、コンテキストには長さの制限があるため、必要な情報だけを選んで渡すことが重要です。 また、LLMは単独では外部のファイルやインターネットにアクセスできません。そこで、AIエージェントは「実行したいコマンド」をLLMにテキストで出力させ、その出力をプログラムが受け取って実際のツール(ファイル操作など)を実行する仕組みを使います。これは「Tool use」や「Function calling」と呼ばれ、AIエージェントの基本技術です。 さらに、様々なツールと効率的に連携するために、「MCP」という通信プロトコルが使われることがあります。これは、ツールの定義や実行を共通の形式で行うためのものです。 実際のAIエージェント(Roo Codeなど)は、LLMへの指示(システムプロンプト)と、これまでのやり取り(会話履歴)をコンテキストとして送ることで動作します。会話履歴には、ユーザーの入力だけでなく、エディタから取得した情報(例えば、ツール実行の結果や、コードのエラー情報)も含まれます。特にエラー情報をLLMにフィードバックすることで、エージェントがエラーを認識し、自動で修正できるようになります。 AIエージェントは、このようにLLMの基本能力を様々な仕組みで補い、拡張することで実現されています。過去わずか2年でLLMの性能(コスト、扱える情報量、速度)は劇的に向上しており、これが現在のAIエージェントの実用化を可能にしました。AIエージェントの仕組みを理解することは、現在の技術動向を追い、今後どのように進化していくかを考える上で役立ちます。 引用元: https://zenn.dev/dinii/articles/ai-agent-demystified ローカルRAGを手軽に構築できるMCPサーバーを作りました この記事は、最近注目されている「Model Context Protocol(MCP)」という技術と、LLM(大規模言語モデル)の応用技術である「Retrieval-Augmented Generation(RAG)」を組み合わせて、自分のローカル環境で使えるRAGシステムを簡単に構築するためのサーバを作った、という開発の紹介です。 RAGとは、あらかじめ用意したドキュメント(文章や資料など)の中から、AIが回答を作るのに役立つ情報を見つけ出し、その情報をAIに渡して回答を生成させる技術のことです。これにより、AIは学習データにはない、例えば社内資料のような特定の情報に基づいて、より正確で専門的な回答ができるようになります。 今回作成された「MCP RAG Server」は、このRAGを実現するための機能の一部である「ドキュメント検索」を担当するサーバです。AI(MCPホスト)からの問い合わせに対して、登録されたドキュメントの中から関連する情報を探し出し、その結果をAIに返します。このサーバはインターネット上のAIサービス(OpenAIなど)を使わないため、情報が外部に漏れる心配がなく、完全に自分のパソコンやネットワークの中で安全に利用できます。 このサーバを作るきっかけは、AIを使ったプログラミングツールなどで、自分のプロジェクトのコードやドキュメントをAIに賢く扱わせたい時に、手軽にドキュメント検索機能を使えるようにしたかったからです。 「MCP RAG Server」の主な特徴は以下の通りです。 いろいろな種類のドキュメント(文章、プレゼン資料、PDFなど)を扱えます。PostgreSQLというデータベースの機能を使って、ドキュメントの意味内容で検索できます。日本語を含む多くの言語に対応しています。新しく追加...
    Voir plus Voir moins
    Moins d'une minute
  • 株式会社ずんだもん技術室AI放送局 podcast 20250508
    May 7 2025
    関連リンク AIエージェントCline、freeeはどうやって全社導入した? freeeでは、GitHub Copilotなどに加え、特に開発スタイルを変える可能性を秘めたAIエージェント「Cline」の全社導入を進めています。この記事では、freeeがどのようにAIツールの本格導入に取り組み、どのような課題を乗り越えたのかが解説されています。 AIツールの導入は、従来のツールと異なり、セキュリティリスクやコスト管理など特有の難しさがあります。freeeではこれに対応するため、二つの仕組みを導入しました。一つは「AI特区制度」で、安全なサンドボックス環境などで一部のチームが限定的にツールを試すことで、現場での利用感や課題を素早く洗い出します。もう一つは「AI駆動開発チーム」で、特区で見つかった課題への対処や、全社導入のための基盤開発、ガイドライン策定、導入効果の測定などを担う専門チームです。 この体制のもと、freeeではまずAI特区でツールを検証し、うまくいきそうなものについて、特区で得た知見をもとに全社展開のためのガイドラインやセキュリティ基盤を整備し、その後全社へ展開・運用するという流れで進めています。 Clineの導入においては、主に三つの壁に直面しました。 一つ目は「セキュリティ」です。社内コードが学習に使われたり、機密情報が流出したり、危険なコマンドが実行されたりするリスクです。これに対しては、学習にデータが使われないAmazon Bedrockを採用し、さらに社内基盤に独自プロキシを立てて、機密情報のマスキングや危険なコマンドのブロックを行いました。 二つ目は「コスト」です。AIツールの多くは利用量に応じた課金で、コスト予測が難しい点が課題です。freeeでは、Amazon Bedrockにタグ付けしたり、プロキシでリクエストログを詳細に計測したりすることで、どのツールにどれだけコストがかかっているかをリアルタイムで監視・可視化し、利用状況や費用対効果を把握できるようにしました。 三つ目は「AIリテラシー」です。ツールは使い方で効果が大きく変わる上、誤った使い方をするとセキュリティリスクにもつながります。対策として、安全な利用を促す共通ルールの策定や、セキュリティリスクのある機能の利用制限、さらには既存のセキュリティ対策と組み合わせた多層的な防御を行っています。 freeeは今回のCline導入を通じて、AIツール導入にはリスクと効果を天秤にかけた判断や、システム的・組織的な専用対策が不可欠であること、またツールごとの特性に合わせた対策が重要であることを学びました。Clineは既に多くの開発者に利用されており、今後はより詳細な効果検証や、AIツール前提の開発フローへのシフトを目指していくとのことです。 この記事は、freeeがAIエージェントの全社導入にどう取り組み、技術的な課題や組織的な課題にどう向き合ったかを知る上で、非常に参考になる事例と言えるでしょう。 引用元: https://developers.freee.co.jp/entry/ai-cline-rolling-out I built an AI code review agent in a few hours, heres what I learned AIコードレビューエージェントを自作した経験に基づく記事です。PRの差分をLLMに送り問題点を見つけさせる仕組みで、GitHub Copilot Reviewなどの類似ツールと比較し、有用性を検証しています。基本的なエージェントは数時間で構築可能ですが、LLMは指示に従わないことがあり、コード全体の文脈理解が不十分だと的外れな提案をすることが課題です。記事では、市販のエージェントを利用するより、自社で完全に制御できるエージェントを開発するためのフレームワークの将来性に期待を寄せています。 引用元: https://www.sourcebot.dev/blog/review-agent-learnings 10分くらいでできるA2Aのはじめ方 この記事は、Google製のA2Aプロトコルを使った複数AIエージェント連携のチュートリアルを解説します。A2Aとは、異なるAIサービス(チャットボット、画像生成、為替変換など)を連携させるプロトコルです。 記事では、複数のエージェントをA2Aで接続し、統合チャットUIから対話・実行できるデモを構築する手順を説明します。セットアップ、APIキー取得、リモートエージェント(経費申請、画像生成、為替)、...
    Voir plus Voir moins
    Moins d'une minute
  • 株式会社ずんだもん技術室AI放送局 podcast 20250507
    May 6 2025
    関連リンク DoomArena: A framework for Testing AI Agents Against Evolving Security Threats この論文は、「AIエージェント」と呼ばれる、私たちの代わりに様々な作業を自動で行ってくれるプログラムのセキュリティをしっかり評価するための新しい仕組み「DoomArena」について紹介しています。AIエージェントはこれから色々な場所で活躍が期待されていますが、もし悪意のある攻撃に弱かったら困りますよね。そこで、どんな脅威に対してどのくらい強いのかをテストすることがとても重要になります。 DoomArenaは、このセキュリティテストをもっとやりやすくするために、以下の3つの考え方で作られています。 プラグイン可能: Webサイトを操作するエージェントや、他のツールを呼び出して使うエージェントなど、現在ある様々なエージェントの実行環境に簡単に追加して使えます。設定可能: どんな部分を攻撃対象にするか、どのような脅威を想定するか(例えば、悪いユーザーが操作する場合か、エージェントが使っている環境自体が悪い場合かなど)を細かく設定できます。モジュール式: 攻撃手法自体と、その攻撃をどの環境で実行するかを分けられるので、一度作った攻撃を色々な種類のエージェントや環境に対して試すことができます。 DoomArenaを使うことで、新しい種類の脅威にも対応しやすくなったり、これまでに考えられていた様々な攻撃手法を組み合わせて、より厳しく、きめ細かいセキュリティテストができるようになります。また、エージェントが持つ様々な弱点(脆弱性)と、本来の性能とのバランス(トレードオフ)を分析することも可能です。 このフレームワークを使って、現在最新のAIエージェントをテストしたところ、いくつか面白いことがわかりました。 最新のエージェントでも、想定する脅威の種類(悪意のあるユーザーによるものか、環境によるものかなど)によって、どのくらい脆弱かが異なり、全ての脅威に対して完璧に強いエージェントは見つかりませんでした。複数の攻撃を同時に仕掛けると、個別の攻撃よりもずっと効果的になる場合が多いです。特定のルール(ガードレール)で動きを制限するような簡単な防御策は効果が薄い傾向がありましたが、高性能な最新のAIモデル(LLM)を使った防御策はより有効なようです。 このDoomArenaフレームワークは公開されており、AIエージェントの開発者やセキュリティに関心のあるエンジニアが利用できるようになっています。AIエージェントをより安全に開発していく上で役立つツールと言えるでしょう。 引用元: https://arxiv.org/abs/2504.14064 LLM Performance Benchmarking: Measuring NVIDIA NIM Performance with GenAI-Perf LLM(大規模言語モデル)を使ったアプリケーションを開発する際、その性能を把握することは非常に重要です。これは、どこに改善の余地があるかを見つけたり、サービス品質(レイテンシなど)と処理能力(スループット)のバランスを調整したり、どれくらいの数のサーバーが必要かを見積もったりするために役立ちます。 この記事では、LLMの性能を測るためのツール「NVIDIA GenAI-Perf」と、NVIDIAが提供するLLM推論サービス「NVIDIA NIM」を組み合わせてMetaのLlama 3モデルの性能を評価する方法が解説されています。 GenAI-Perfは、LLMサービスの応答性能をクライアント側から測定できるツールです。具体的には、最初の単語が表示されるまでの時間(Time to First Token: TTFT)、単語が出てくる間隔(Inter-token latency: ITL)、1秒あたりの単語数(Tokens per second: TPS)、1秒あたりのリクエスト数(Requests per second: RPS)といった重要な指標を測ることができます。GenAI-Perfは業界標準となっているOpenAI APIの仕様に準拠した多くのLLMサービスに対応しています。 NVIDIA NIMは、LLMを素早く簡単に、そして高性能に動かすためのソフトウェアパッケージです。高性能なLLM(例えばLlama 3)をOpenAI API互換の形式で提供できるのが特徴です。 記事では、実際にNIMを使ってLlama 3モデルを起動し、次にGenAI-Perfを使って性能を測定する手順が紹介されています。具体的なコマンド例や、入力や出力の文章の長さ、同時に処理するリクエスト数(同時接続数)...
    Voir plus Voir moins
    Moins d'une minute
  • 私立ずんだもん女学園放送部 podcast 20250502
    May 1 2025
    関連リンク ClineとDDDと私 この記事は、「AIちょっと苦手おじさん」だった筆者が、AIエージェント「Cline」を使い始めた経験と、開発現場での具体的な活用方法について紹介しています。特に、DDD(ドメイン駆動設計)などの考え方を取り入れた保守性の高いコードベースが、AI活用にいかに重要であるかを強調しています。 筆者は、VSCode拡張機能のClineを、GitHub Copilot経由でClaude 3.5 Sonnetモデルと組み合わせて使用しています。最初はタスクの指示の粒度や効率的な進め方に悩みましたが、試行錯誤の結果、効果的な使い方が見えてきました。 AIに開発タスクを任せる上で、なぜ保守性の高いコードが重要なのでしょうか。それは、AIが正確なアウトプットを出すために必要な「コンテキスト情報」を小さく抑えることができるからです。複雑な全体像を知らなくても、特定の小さな部分だけを理解すれば作業できるようなコード(「コンテキストの局所化」)は、AIにとっても扱いやすいのです。DDDやクリーンアーキテクチャは、関心事を分離し、このコンテキストを局所化するのに役立ちます。 また、AIは自然言語で学習しているため、クラス名やメソッド名から振る舞いが予想しやすい、いわゆる「自然言語としての可読性が高い」コードは、AIにとっても理解しやすく、期待通りのコードを生成する可能性が高まります。現時点では、「AIフレンドリーなコード」は「人間が読みやすいコード」とほぼ同じだと言えるでしょう。 具体的なタスク分担の例として、新規機能開発におけるバックエンド(SpringBoot/Kotlin)とフロントエンド(React/TypeScript)でのClineの活用が紹介されています。 バックエンドでは、 UseCase(アプリケーションロジック)のユニットテスト実装Controller(UI層とUseCaseの連携)の実装Repository(ドメイン層とインフラ層の連携)の実装 といった、定型的な作業やモック設定が面倒な部分をClineに任せています。特に、DDDにおけるレイヤードアーキテクチャによって関心事が分離されていることが、AIに任せやすいタスクの切り出しに繋がっています。 フロントエンドでは、 デザインシステムに基づいたコンポーネントライブラリの実装アプリケーション固有の個別コンポーネント(API連携やフォーム処理など)の実装 などに活用しています。React/TypeScriptはVSCodeとの連携やAIモデルの学習量の多さから、より良いコード生成が期待できるようです。 Clineを効果的に使うためのTIPSとして、以下の点が挙げられています。 参考にしたい既存コードをVSCodeで開いておく(AIが参照しやすくなる)Plan(計画)段階でAIの応答を確認し、指示を調整してからAct(実行)する.clinerulesファイルにプロジェクト共通のルールを記述しておくClineとのやり取りを記録・共有する(振り返りやナレッジ共有のため)Clineに「キャラ付け」して楽しく使う まとめとして、DDDのようなレイヤードアーキテクチャによる関心事の分離は、AIが必要とするコンテキストを減らし、効率的なタスク分担を可能にすることが筆者の経験から分かったそうです。AIの進化にも期待しつつ、今後も人間が理解しやすい「ヒューマンリーダブルなコードベース」を維持していくことの重要性を改めて認識しています。新人エンジニアの皆さんも、こういったAIツールを使いこなし、開発をより効率的で楽しいものにしていきましょう。 引用元: https://tech.codmon.com/entry/2025/05/01/132700 AIエージェントを使って実際にアプリ開発→リリースした経験・知見を共有する この記事では、AIエージェント「Claude Code」を使ってiOSアプリ「電光石火」を実際に開発・リリースした経験から得られた知見が共有されています。AIによるコーディングツールは増えていますが、プロダクトとして完成させた例はまだ少ないため、実践的な情報として参考になります。 著者が感じたAIエージェントの最大のメリットは、開発速度の向上です。体感で通常の3〜5倍速く開発できたとのこと。簡単な指示で動くコードをすぐに生成できるため、ゼロから考えるよりも、まずAIにたたき台となるコードを書かせ、それをベースに作業を進めるのが非常に...
    Voir plus Voir moins
    Moins d'une minute
  • 株式会社ずんだもん技術室AI放送局 podcast 20250501
    Apr 30 2025
    関連リンク 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サーバを「作る」ことも可能です。これは、...
    Voir plus Voir moins
    Moins d'une minute
  • 株式会社ずんだもん技術室AI放送局 podcast 20250430
    Apr 29 2025
    関連リンク 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 LlamaCon Metaは初の試みとなる開発者向けイベント「LlamaCon」を開催し、オープンソースAIモデルであるLlamaを使った開発をさらに容易にするための新しいツールや取り組みを発表しました。Llamaは公開から2年あまりで10億以上のダウンロードを達成し、オープンソースAIエコシステムを牽引する存在となっています。 このイベントで発表された主な内容は以下の通りです。 まず、開発者がLlamaを使ってアプリケーションを素早く構築できるようになるLlama API(リミテッドプレビュー版)が発表されました。これは、APIの手軽さとオープンソースの柔軟性を両立させたプラットフォームです。ワンクリックでAPI...
    Voir plus Voir moins
    Moins d'une minute
  • マジカルラブリー☆つむぎのピュアピュアA.I.放送局 podcast 20250428
    Apr 27 2025
    関連リンク 最小限の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コードを生成するエージェント...
    Voir plus Voir moins
    Moins d'une minute
  • 私立ずんだもん女学園放送部 podcast 20250425
    Apr 24 2025
    関連リンク 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エージェントは、単一の応答だけでなく、状況を判断し、複数のツールを使ったり、情報を検索...
    Voir plus Voir moins
    Moins d'une minute