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

By: 株式会社ずんだもん技術室AI放送局
Listen for free

  • Summary

  • AIやテクノロジーのトレンドを届けるPodcast。平日毎朝6時配信。朝の通勤時間や支度中に情報キャッチアップとして聞いてほしいのだ。(MC 月:春日部つむぎ、火水木:ずんだもん、金:お嬢様ずんだもん)
    Show more Show less
Show more Show less
Episodes
  • マジカルラブリー☆つむぎのピュアピュアA.I.放送局 podcast 20250428

    マジカルラブリー☆つむぎのピュアピュア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コードを生成するエージェント...
    Show more Show less
    Less than 1 minute
  • 私立ずんだもん女学園放送部 podcast 20250425

    私立ずんだもん女学園放送部 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エージェントは、単一の応答だけでなく、状況を判断し、複数のツールを使ったり、情報を検索...
    Show more Show less
    Less than 1 minute
  • 株式会社ずんだもん技術室AI放送局 podcast 20250424

    株式会社ずんだもん技術室AI放送局 podcast 20250424
    Apr 23 2025
    関連リンク AI Agent × Cursor で要件整理から実装まで この記事は、AI AgentであるCursorを活用したWebフロントエンド開発の具体的な進め方とノウハウを紹介しています。特に新人エンジニアの方にも分かりやすいように、AIとの協調作業で開発を効率的に進めるためのフローが解説されています。 筆者は、AI Agentを使った開発では、いきなりコーディングを始めるのではなく、「要求から実装用のDocumentを作成する」フェーズと「そのDocumentに基づいて開発する」フェーズを分けて進めることを推奨しています。これは、従来の開発と同様に、事前に要件や方針をしっかり固めることで手戻りを減らし、質の高い開発を目指すためです。 「要求から実装用のDocumentを作成する」フェーズはさらに3つの段階に分かれます。 要求情報から実装要件Docを作成（specification.md）: 様々な形式で与えられた要求（デザインやビジネス要件など）をAI Agentと一緒に整理し、実装に必要な要件を明確にします。AI Agentが不明な点を質問してくれるので、人間が補足することで要件の漏れを防ぎます。実装要件Docから実装方針Docを作成（design-doc.md）: 定義した要件に基づき、どのような技術を使うか、どのように設計するかといった具体的な実装方針をAI Agentと考えます。既存のコードやドキュメントを参照させながら、最適な方針を決定します。実装方針DocからタスクDocを作成（task.md）: 決まった実装方針に従って、開発作業を具体的なタスク単位に分割し、作業順序を計画します。AI Agentがタスクリスト案を作成し、人間がその粒度や順序を調整します。 これらの3つのDocumentを作成する過程で、AI Agentとの対話を通じて不明瞭な部分を解消し、開発の方向性を固めていきます。人間はAI Agentからの提案や質問に対して、状況に合わせて判断や補足を行う役割を担います。記事では、まとまった回答を効率的に入力するために、ChatGPTの音声入力を活用する具体的なTipsも紹介されています。 「実装用Documentから開発する」フェーズでは、作成したタスクDocに基づいて、タスクを一つずつAI Agentに進めてもらいます。AI Agentはタスクの内容を理解し、必要なコードを生成してくれます。生成されたコードを確認し、期待通りであればコミットに進みます。コミットは粒度やスコープを自分でコントロールするために、手動で行うことが推奨されています。 開発が終わったら、作成したDocumentはプルリクエスト（PR）の差分に含まれないように削除コミットを作成します。PR作成時には、Documentの情報を参照させながら、AI Agentにベースとなる説明文を作成してもらうことも可能です。 このフローは、AI Agentを単なるコード生成ツールとして使うのではなく、要求整理や設計方針検討といった上流工程から「協調して」進めることで、開発プロセス全体の効率化と質の向上を目指すアプローチと言えます。ゼロから大規模な要求整理を行う場合は、よりチームでの議論が必要になるなど、まだ模索中の部分もあるとのことです。 この記事で紹介されたフローは、AI Agentを開発にどう活用できるか、具体的な一歩を踏み出すための参考になるでしょう。 引用元: https://zenn.dev/kii/articles/with_ai-agent_on_2504 NVIDIA CEOが石破総理に力説–「AIエージェントの次はフィジカルAI。これは日本にとって本当に重要」 AI分野をリードするNVIDIAのCEO、ジェンスン・フアン氏が日本の石破総理大臣と会談し、AI技術の未来について語りました。 石破総理は、AIを活用した地方創生や、日本がAI開発しやすい環境整備への意欲を示しました。 これに対しフアン氏は、NVIDIAが創業間もない頃から日本のゲーム会社などと協力し、日本の技術力に支えられてきたことに触れました。 フアン氏は、AIの進化を波に例えて説明しました。 第一の波は、コンピューターが文字や画像などを「認識する」段階。 第二の波は、文章や画像を新しく「生成する」段階（これが今の生成AIですね）。 そして、現在進行中の第三の波は、AIが自分で考え、推論して問題を解決する「エージェントAI」の段階です。 そして、フアン氏が特に強調したのが、この次に来る「フィジカルAI」...
    Show more Show less
    Less than 1 minute
adbl_web_global_use_to_activate_webcro768_stickypopup

What listeners say about 株式会社ずんだもん技術室AI放送局

Average customer ratings

Reviews - Please select the tabs below to change the source of reviews.

Audible.com reviews

Amazon reviews
No Reviews are Available