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

著者: 株式会社ずんだもん技術室AI放送局
  • サマリー

  • AIやテクノロジーのトレンドを届けるPodcast。平日毎朝6時配信。朝の通勤時間や支度中に情報キャッチアップとして聞いてほしいのだ。(MC 月:春日部つむぎ、火水木:ずんだもん、金:お嬢様ずんだもん)
    続きを読む 一部表示

あらすじ・解説

AIやテクノロジーのトレンドを届けるPodcast。平日毎朝6時配信。朝の通勤時間や支度中に情報キャッチアップとして聞いてほしいのだ。(MC 月:春日部つむぎ、火水木:ずんだもん、金:お嬢様ずんだもん)
エピソード
  • 私立ずんだもん女学園放送部 podcast 20250425
    2025/04/24
    関連リンク 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エージェントは、単一の応答だけでなく、状況を判断し、複数のツールを使ったり、情報を検索...
    続きを読む 一部表示
    1分未満
  • 株式会社ずんだもん技術室AI放送局 podcast 20250424
    2025/04/23
    関連リンク 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」...
    続きを読む 一部表示
    1分未満
  • 株式会社ずんだもん技術室AI放送局 podcast 20250423
    2025/04/22
    関連リンク AIエージェントのおかげでdbt開発の大部分を自動化した話 この記事は、データ分析基盤で使われる「dbt」というツールを使ったデータモデル開発において、AIエージェントを活用して多くの定型作業を自動化した事例を紹介しています。 データを使って分析やレポートを作る際、元データを使いやすい形に加工する作業が必要です。dbtは、この加工(データモデル開発)を効率的に行うための人気ツールですが、開発するデータモデルが増えると、「ファイルの置き場所や名前のルールを守る」「データのチェック(テスト)を書く」「どんなデータか説明するドキュメントを更新する」「分析ツールで使いやすくするための設定(メタデータ定義)をする」といった、定型的な作業がたくさん発生し、開発者の負担になってしまいます。もっとSQLを書くことや分析そのものといった、頭を使う本質的な作業に集中したい、というのがエンジニアの本音です。 この課題を解決するために、筆者らは「Cursor Editor」というAI搭載の開発エディタの「Agent機能」と「Project Rules」を活用しました。 Cursor EditorのAgent機能は、指示を与えるとAIがタスクをステップごとに実行してくれる機能です。Project Rulesは、プロジェクト特有の開発ルール(命名規則、コーディング規約、標準手順など)をAIに教え込むための設定です。 dbtモデル開発には通常、SQLを書く以外にも、ファイルのテンプレート作成、ローカルでの実行確認、メタデータやテストの更新、ドキュメント作成、プルリクエスト作成など、複数のステップがあります。 これらのステップをAIエージェントに任せるために、開発チームはProject Rulesを丁寧に整備しました。具体的には、以下のようなルールを定義しました。 命名規則: BigQueryのテーブルとdbtモデル名の対応関係や、データが加工される段階(層)ごとの名前の付け方。コーディング規約: SQLの書き方や、他のデータモデルを参照する際のルール。開発手順: dbtモデルの加工段階(層)ごとに、ステップ1からステップnまで何をどのように進めるかを細かく定義。使用するコマンドや、エラー発生時の対応方法まで含めました。 Project Rulesを整備し、AIにプロジェクト固有のルールをしっかり教え込んだ結果、AIエージェントはプロジェクトのやり方に沿って正確にタスクを実行できるようになりました。SQLを人間が準備すれば、それ以降の多くの定型作業(テンプレート作成、実行確認、メタデータ・テスト・ドキュメント更新、プルリクエスト作成)をAIが自動で行ってくれるようになり、ほぼ人間が最終確認するだけでGitHubにプルリクエストが作成されるレベルに達したとのことです。 もちろん、AIに任せる上で工夫も必要です。例えば、複雑なタスクは最初にAIに計画だけ立てさせる、AIに必要なルール情報を明示的に伝える、そして絶対に守りたいルールは昔ながらの自動チェックツール(静的解析、自動テスト)で間違いがないか確認する、といった「AIのための安全策(ガードレール)」を設けることが重要だと感じているそうです。 この取り組みにより、開発者はSQLの設計・実装といったクリエイティブな作業に集中できるようになり、社内からは開発効率が向上したという声があがっています。データモデル開発量も増加したという定量的な成果も出ています。 まとめとして、AIエージェントはまだ完璧ではありませんが、プロジェクト固有のルール(Project Rules)を整備し、継続的に改善していくことで、開発プロセスを大幅に自動化し、生産性を向上させることが可能です。AIにどこまで任せるか、人間とAIのより良い役割分担を考えていくことが今後の課題であり楽しみでもある、と筆者は述べています。 引用元: https://zenn.dev/ubie_dev/articles/d97c5ece4660bd 営業AIエージェント「アポドリ」のつくりかた この記事は、営業AIエージェント「アポドリ」を開発する過程で得られた経験や学びを共有するSpeaker Deckの資料に基づいています。新人エンジニアの皆さんにも、AIエージェント開発の現実や考え方を理解してもらうことを目指します。 「アポドリ」は、人の代わりに...
    続きを読む 一部表示
    1分未満

株式会社ずんだもん技術室AI放送局に寄せられたリスナーの声

カスタマーレビュー:以下のタブを選択することで、他のサイトのレビューをご覧になれます。