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

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

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

  1. 3時間前

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

    関連リンク 安定したAIエージェント開発・運用を実現するLangfuse活用方法 AIエージェントの開発や運用は、従来のシステム開発とは異なる難しさがあります。この記事では、LayerX社がAIエージェント開発で直面した3つの課題と、それらを「Langfuse」というツールを使ってどう解決したかを紹介しています。 まず、課題として挙げられたのは以下の3点です。 AIの動きが分かりにくい: AIは「なぜその結果を出したのか」が曖昧になりがちで、問題が起きたときに原因を探すのが大変でした。 AIへの指示（プロンプト）の管理が大変: プロンプトを変更したときに、誰が、いつ、なぜ変えたのかが分からなくなり、管理が属人化する問題がありました。 プロンプト変更の影響が読めない: 少しのプロンプト変更でAI全体の性能に予期せぬ悪影響が出る可能性がありましたが、それを事前に確認する仕組みがありませんでした。 これらの課題を解決するため、LayerX社は「Langfuse」というLLMOpsツールを導入しました。このツールは、プロンプトの管理、実験による性能評価、そしてAIの動きを詳しく見れる（可観測性）機能が充実しており、自分たちのサーバーで運用できる点も決め手になったそうです。 Langfuseを導入したことで、具体的な解決策は以下の通りです。 Trace機能でAIの動きを「見える化」: AIエージェントの処理の流れをステップごとに記録し、入力や出力、LLM（大規模言語モデル）の呼び出しにかかった時間やコストまで、詳細に可視化できるようになりました。これにより、「なぜこうなったのか」を後から簡単に追跡できます。 Prompt Management機能でプロンプトをしっかり管理: AIへの指示文であるプロンプトをバージョン管理し、Gitを使ったコードと同じようにレビューを経て更新するフローを作りました。もしプロンプトに問題が見つかっても、Langfuseの画面からすぐに前のバージョンに戻せる仕組みも用意されています。 Evaluation機能でプロンプト変更の影響を自動テスト: 事前に用意した代表的な入力と、AIが出すべき正しい答えの組み合わせ（Dataset）を使って、プロンプト変更後にAIの性能が落ちていないかを自動でチェックするテスト（リグレッションテスト）を導入しました。これにより、変更による品質低下を防ぐ「安全装置」として機能しています。 今後の課題としては、人間の判断が必要な「文章の自然さ」や「メッセージの適切さ」といった定性的な評価も、Langfuseの「LLM as a Judge」のような機能を使って自動化していくこと、そしてログとAIの動きのトレースを一元的に見られるようにしていくことなどが挙げられています。 AIエージェント開発は新しい分野ですが、Langfuseのようなツールを活用することで、より安定した開発・運用サイクルを築き、お客様に価値を提供し続けていくLayerX社の取り組みは、私たち新人エンジニアにとっても大変参考になりますね。 引用元: https://tech.layerx.co.jp/entry/stable-ai-agent-dev-with-langfuse NVIDIA Rubin CPX Accelerates Inference Performance and Efficiency for 1M+ Token Context Workloads 「NVIDIA Rubin CPX」は、まるで人間の会話のように長い文章を理解し、複雑な処理を行うAI、特に大規模言語モデル（LLM）の推論性能と効率を大幅に高めるための新しいGPU（グラフィック処理装置）です。新人エンジニアの皆さんがAI開発に携わる際、AIが大量の情報を素早く、効率よく処理できるかどうかは非常に重要ですよね。 最近のAIモデルは、まるで人間の脳のように、一度に大量の情報を記憶し、複雑な推論を何ステップもかけて行えるようになってきました。例えば、数百万行のコード全体を理解して的確なアドバイスをくれるコーディングアシスタントや、長い動画の内容を一貫性をもって生成するAIなど、私たちの想像を超える能力を発揮し始めています。しかし、このような「100万トークン（AIが情報を処理する最小単位、単語や文字の塊のようなもの）以上」といった膨大な情報（コンテキスト、AIが状況を理解するために与えられる情報）を扱うには、これまでのコンピューターでは限界がありました。 そこでNVIDIAは、AIの推論処理を「コンテキストフェーズ（入力された情報を分析する段階）」と「生成フェーズ（分析結果に基づいて答えを出す段階）」の2つに分け、それぞれに特化した処理を行う「分離型推論（Disaggregated Inference）」という新しい考え方を提案しています。Rubin CPXはこのうち、特に大量の情報を高速に処理する「コンテキストフェーズ」に特化して設計されました。これにより、AIがより深く、より長い文脈を理解できるようになり、全体の処理速度が飛躍的に向上します。 Rubin CPX GPUは、NVFP4という新しい計算形式で30 PetaFLOPsもの高性能な演算能力を持ち、大容量のGDDR7メモリを搭載しています。これにより、既存のGPUと比較して、特にAIが文脈を理解する上で重要な「アテンション（注目）処理」を約3倍も高速化できます。さらに、NVIDIA Vera CPUとRubin GPUと組み合わせた「Vera Rubin NVL144 CPXラック」という統合システムでは、驚異的な計算能力とメモリ帯域幅を提供し、大規模なAIワークロードのコストを大幅に削減し、投資対効果（ROI）を最大化します。 この新しい技術は、NVIDIAの提唱する「SMARTフレームワーク」に基づき、ハードウェアとソフトウェア（NVIDIA Dynamoなど）が一体となって最高のパフォーマンスを引き出すことを目指しています。Rubin CPXの登場は、ソフトウェア開発や動画生成といった、より高度で複雑なAIアプリケーション開発の可能性を大きく広げることでしょう。これからのAI時代を担う皆さんにとって、NVIDIAの動向は要チェックです！ 引用元: https://developer.nvidia.com/blog/nvidia-rubin-cpx-accelerates-inference-performance-and-efficiency-for-1m-token-context-workloads/ 「ベクトルDB不要」なRAG手法「PageIndex」を解説 こんにちは！新人エンジニアの皆さんも、最近よく聞く「RAG（Retrieval Augmented Generation）」という技術をご存知でしょうか？RAGは、LLM（大規模言語モデル）が、特定の知識ベース（ドキュメントなど）を参照して、より正確な回答を生成するための技術です。今回は、このRAGの新しいアプローチとして注目されている「PageIndex」という手法について、分かりやすく解説します。 従来のRAGでは、多くのドキュメントを「ベクトルデータベース（ベクトルDB）」というものに保存し、質問と意味的に似ている情報を検索してLLMに渡していました。しかし、この方法だと、ドキュメントを細かく区切った「チャンク」と呼ばれる単位で処理するため、文脈（前後のつながり）が失われやすかったり、意味は似ていても質問の意図とは違う情報を取ってきてしまったりすることが課題でした。特に、契約書や金融レポートのような専門用語が多く、複雑な文脈を持つ文書では、この課題が顕著になります。 そこで登場したのが、今回紹介する「PageIndex」です。PageIndexは、なんと「ベクトルDBを使わない」RAG手法なんです。 この手法のキモは、ドキュメントをまるで「目次」のように、階層的なツリー構造に変換することにあります。LLMは、この目次のようなツリー構造を辿りながら、ユーザーの質問に関連する情報を探し出します。人間が本を読むときに、まず目次を見て、そこから関連する章や節を探していくのに似ていますよね。これにより、LLMは文書全体の構造や文脈を理解した上で、必要な情報を見つけ出すことができるようになります。 具体的な手順はシンプルです。 事前準備：元のPDF文書などをOCRで読み込み、階層構造を保ったMarkdown形式に変換します。その後、そのMarkdownから「目次」のようなツリー構造（JSON形式）を構築しておきます。 質問時：ユーザーが質問をすると、LLMがこの構築されたツリー構造を辿って、関連する情報を探索し、回答を生成します。 このPageIndexは、金融レポートの分析に関する質問応答ベンチマーク「FinanceBench」で98.7%という高い正解率を達成しており、その有効性が示されています。また、LLMがどのような経路で情報を探し出したかが明確になるため、検索の透明性が高いというメリットもあります。 ただし、いくつかの限界も存在します。現時点では、複数のドキュメントをまとめて扱うのが苦手だったり（将来的には対応予定）、質問から

  2. 1日前

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

    関連リンク SafetyKit’s blueprint for scaling risk agents with OpenAI’s most capable models 新人エンジニアの皆さん、こんにちは！今回は、OpenAIの最新AIモデル、特にまだ未公開の「GPT-5」が、オンラインの安全を守るためにどのように活用されているかをご紹介します。 「SafetyKit」という会社は、オンラインマーケットプレイスや決済サービス、金融テック企業（フィンテック）が抱える、詐欺や規約違反といった問題に対処するAIエージェントを開発しています。彼らのAIは、テキストだけでなく画像や取引データなど、さまざまな種類の情報（マルチモーダル）を分析し、人間では見逃しやすいような複雑なルール違反（例えば、詐欺画像に隠された電話番号や地域ごとの特別な規制など）を検出します。これにより、ユーザーは安心してサービスを使え、企業は法規制違反のリスクを減らせるだけでなく、人間が不快に感じるようなコンテンツのチェック作業から解放され、より高度な判断業務に集中できるようになります。 SafetyKitは、OpenAIの強力なAIモデルを、タスクの特性に合わせて賢く使い分けています。 GPT-5：複数の情報源（テキスト、画像、UIなど）を横断的に分析し、複雑な状況から隠れたリスクを深く推論して、精密な意思決定を支援します。まるで探偵がさまざまな証拠を合わせて事件を解決するようなイメージです。 GPT-4.1：大量のコンテンツを効率的に処理し、詳細な利用規約（ポリシー）に厳密に沿ったモデレーションを安定して行う役割を担います。 これらのモデルに、AIの精度を高める「強化学習によるファインチューニング」や、自動でオンライン調査を行う「Computer Using Agent (CUA)」といった技術を組み合わせることで、95%以上の高い精度で、すべてのコンテンツを網羅的にレビューできる体制を構築しています。 特に、グレーゾーンで判断が難しい場面ではGPT-5の能力が光ります。例えば、ある商品が特定の地域で販売される際に、法律で定められた注意書きが必要かどうかを判断する場合、GPT-5はポリシーの細かなニュアンスを理解し、記載内容が適切かを精密に評価します。これにより、従来のシンプルなルールでは見分けられないような、複雑で微妙な判断も正確に行えるようになりました。 SafetyKitは、OpenAIが新しいAIモデルをリリースすると、すぐにその性能を検証し、効果があれば自社のシステムに迅速に導入しています。このスピード感が、常に進化する詐欺の手口やリスクに対応し続ける原動力となっています。実際に、彼らが処理するデータ量は短期間で大幅に増加しており、支払リスク、詐欺、不適切なコンテンツ対策など、さまざまな分野でその適用範囲を広げています。 このように、SafetyKitはOpenAIの最先端AI技術を巧みに組み合わせることで、私たちのデジタル生活をより安全で信頼できるものにしています。AIエージェントが、複雑なオンライン環境における「目に見えない守り手」として活躍する、先進的な事例と言えるでしょう。 引用元: https://openai.com/index/safetykit AIAgentにAI最新情報まとめ資料を作ってもらう会【LangGraph&LangSmith】 この記事では、AIエージェントが最新のAI情報を集め、自動でプレゼンテーション資料を作成するPoC（概念実証）について、具体的な実装を通して解説しています。Pythonを使って、LangChain、LangGraph、LangSmithといった主要なAI開発ツールを組み合わせた事例で、新人エンジニアの方でもAIエージェント開発の全体像と各ツールの役割を理解しやすい内容です。 資料作成の自動化フローは、以下のステップで構成されます。 情報収集 (collect_info): Web検索API「Tavily」を使って、AI関連の最新情報を自動で集めます。 アウトライン生成 (make_outline): 収集した情報を基に、スライドの骨子（重要ポイントの箇条書き）を作成します。 目次生成 (make_toc): アウトラインから、スライドの章立て（目次）を生成します。 スライド本文生成 (write_slides): MarpというMarkdownベースのスライド作成ツールを活用し、情報と目次に基づいてスライドの本文を作成します。 自動評価とリトライ (evaluate_slides): 生成されたスライドの品質を自動で評価します。もし品質が低いと判断されれば、より良い資料を作るために目次生成のステップに戻って作り直しを試みます。 保存 & レンダリング (save_and_render): 最終的なスライド（Markdown形式）をPDFなどの形式に変換して保存します。 このPoCで使われている主要なツールは以下の通りです。 LangChain: 大規模言語モデル（LLM）を使ってアプリケーションを開発するためのフレームワークで、LLMを外部ツールやデータベースと連携させ、より賢いAIアプリケーション（AIエージェントやRAGシステム）を作ることを目指します。 LangGraph: LangChainを基盤とし、AIエージェントの複雑な処理の流れを「グラフ（ノードとエッジ）」のように設計・可視化できるフレームワークです。条件分岐や繰り返し処理など、高度な制御が可能になります。 LangSmith: LangChain公式が提供する、LLMアプリケーションの評価・デバッグ・監視プラットフォームです。AIエージェントの動作を詳しく「見える化」し、開発者が問題を発見・修正し、品質を改善するのに役立ちます。 Tavily: AI向けにWebから最新情報を効率的に収集するための検索APIです。LLMが扱いやすい、要約された形式で検索結果を提供します。 Marp: Markdown形式でプレゼンテーションスライドを作成できるオープンソースのフレームワークです。Markdownで書いたシンプルなテキストを、PDFやHTML形式の美しいスライドに簡単に変換できます。 この記事は、これらのツールを連携させることで、AIが自律的に情報を収集し、高品質な資料を自動生成する仕組みを実践的に示しています。特にLangGraphとLangSmithは、複雑なAIエージェントのワークフローを設計し、その挙動を可視化・デバッグする上で非常に強力なツールであることが強調されており、AIエージェント開発に興味がある新人エンジニアにとって、実践的な学びが多い記事と言えるでしょう。 引用元: https://zenn.dev/microsoft/articles/create_doc_by_aiagent Agent Middleware LangChainは、AIエージェント開発をより堅牢で実用的なものにするため、バージョン1.0で「Agent Middleware」という新しい仕組みを導入します。これは、従来のAIエージェントフレームワークが抱えていた、本番環境での信頼性や柔軟性の課題を解決するための重要な改善点です。 これまでのエージェントは、AIモデル、プロンプト、利用するツールの組み合わせで構成され、ユーザーの入力に対してツールを呼び出し、状態を更新しながら目的を達成するというシンプルなループで動作していました。しかし、複雑なタスクや実際のビジネスシーンで利用する際には、AIモデルに入力する情報（コンテキスト）を細かく制御する「コンテキストエンジニアリング」が難しく、エージェントの動作が不安定になったり、期待通りの結果が得られにくかったりするという問題がありました。その結果、多くの開発者は、フレームワークが提供する抽象化では物足りず、独自のコードでエージェントを実装することが多かったのです。 LangChainはこれまでも、このような課題に対応するため、動的にプロンプトを生成したり、モデル呼び出しの前後に処理を挟む「フック」機能を追加したりと、改善を重ねてきました。しかし、これらの機能は多くの個別のパラメータとして提供され、設定が複雑になる上、互いに依存関係があるために管理が難しくなっていました。 そこでLangChain 1.0では、Webサーバーで一般的に使われるミドルウェアの考え方を取り入れました。エージェントの核となる「モデル呼び出し」や「ツール実行」の前後や途中に、開発者が独自の処理を簡単に差し込めるようにするものです。具体的には以下の3つのポイントでエージェントの振る舞いをカスタマイズできます。 before_model: モデルが呼び出される直前に処理を実行し、エージェントの状態を更新したり、次のステップを変更したりできます。 after_model: モデルが結果を返した直後に処理を実行し、同様に状態の更新や次のステップの制御が可能です。 modify_model_request: モデルへのリクエスト内容（使用するツール、プロンプト、メッセージリスト、

  3. 2日前

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

    関連リンク Temporal Knowledge Graphで作る！時間変化するナレッジを扱うAI Agentの世界 AI Agent（AIエージェント）が賢く動くためには、まるで人間が経験や知識を記憶するように、「メモリ」や「ナレッジ」（知識）を持つことが非常に大切です。特に、社内ルールのように時間とともに変化する情報を扱うのは難しい課題でした。この記事では、この課題を解決する「Temporal Knowledge Graph（TKG）」（時間知識グラフ）という最新技術と、その具体的な応用事例について、新人エンジニアにも分かりやすく解説されています。 まず「Knowledge Graph（KG）」（知識グラフ）とは、情報（エンティティ）とその関係性をグラフの形で整理する技術です。これにより、データから複雑な関連性を直感的に理解しやすくなります。最近では、LLM（大規模言語モデル）の進化により、大量の文書から知識グラフを簡単に構築できるようになりました。KGは、単純な事実検索よりも、複数の概念が絡む複雑な推論や深い文脈理解が必要なタスクで特に威力を発揮します。 しかし、従来のKGは時間の変化に対応できません。そこで登場するのが「Temporal Knowledge Graph」（TKG）です。TKGは、情報に「いつ」という時間軸の概念を加えることで、時間とともに変化する情報や動的な変更を扱えるようにした知識グラフです。これにより、AI Agentは新しい情報やユーザーとのやり取りを通じて自律的に学習し、行動を改善していくサイクルを構築できるようになります。 TKGの代表的なフレームワークの一つに「Graphiti」（Zep）があります。Graphitiは、生の入力データ（エピソードサブグラフ）、そこから抽出されたエンティティと関係性（セマンティックエンティティサブグラフ）、さらに高レベルな概念の要約（コミュニティサブグラフ）という3層構造で情報を管理します。LayerXでは、このTKGを活用し、時間変化する申請ルールに対応するAI Agentの概念実証（PoC）を進めています。例えば、自然言語でルール変更を取り込んだり、人間の差し戻しコメントから学習してレビュー精度を高めたり、社内規定の曖昧な部分をAI Agentが自律的に発見・補完するといった、現実世界の課題を解決する機能が検討されています。 TKGを実際に構築する上でのノウハウも共有されています。特に日本語文書からグラフを構築する際は、長い文章を細かく分ける「チャンク化」や、日本語特有の「主語の省略」への対応が重要です。LLMへのプロンプトで、主語を明確にするよう具体的に指示を出す工夫が紹介されています。また、大量のデータを効率的に取り込むための「一括挿入」機能や、テナントごとに情報を分離する「group_id」の活用もポイントです。 構築したTKGやAI Agentの性能を評価することも非常に重要で、グラフの品質指標や、RAG（Retrieval-Augmented Generation）の評価フレームワークである「Ragas」を活用する方法が紹介されています。Temporal Knowledge Graphは、時間変化する動的なナレッジをAI Agentに与えるための強力な基盤であり、今後のサービス開発において競争優位性を生み出す重要な技術として期待されています。 引用元: https://tech.layerx.co.jp/entry/tkg-agent AIコードレビューがチームの”文脈”を読めるようになるまで 〜 レビューの暗黙知を継承する育成コマンド 〜 エムスリーのエンジニアチームでは、開発プロセスにAIコードレビューを導入し、効率とコード品質の向上を目指しています。AIは、変数名のタイポや文法ミス、冗長なコード、セキュリティの脆弱性などを自動で指摘してくれるため、エンジニアはより本質的なロジックや設計といった、考える必要があるレビューに集中できるようになりました。 しかし、AIコードレビューには課題もありました。一般的な指摘は得意ですが、チーム固有の「文脈」や「暗黙知」を理解できない点です。例えば、「プロジェクト全体の設計思想に合っているか」「共通関数を使っているか」「ファイルの置き場所はルールに沿っているか」といった、チームで培われた細かなルールや知見は、AIには判断できませんでした。また、AIに与える指示（プロンプト）の更新も滞りがちで、最新のチームの知見が反映されにくいという問題も抱えていました。 この課題を解決するため、チームは「AIレビュアー育成コマンド」を開発しました。これは、過去に人間が行ったレビューの内容をAIに学習させ、AIのコードレビュー用プロンプトを自動で更新する仕組みです。このコマンドはClaude Codeで利用でき、以下のステップで動作します。 マージリクエストの取得: GitLabから、最近マージされたコード変更（マージリクエスト）の履歴を取得します。 コメントとコードの抽出: 各マージリクエストから、レビューコメントと、そのコメントが指摘しているコードをセットで取り出します。 レビュー観点の要約: AI自身が、取り出したコメント群から「このプロジェクトで重要なレビュー観点（チェックポイント）」を要約し、Markdownファイルとして出力します。 プロンプトの更新: 生成されたMarkdownファイルの内容を元に、既存のAIコードレビュー用プロンプトに新しい知見を追記・更新します。 実装の工夫としては、AIが一度に多くの情報を処理しきれない問題を避けるため、特定の役割を持たせた「サブエージェント」を活用しています。また、AIが勝手に「ありそうなレビュー観点」を想像してしまうことを防ぐため、「実際に誰がどんなコメントをしたか」をAIに明示的に伝えることで、より実践的なレビュー観点を抽出できるように工夫されています。 このコマンドの導入により、プロンプトの更新作業が非常に楽になり、チームの知見を継続的にAIに反映できるようになりました。今後は、「LGTM（了解）」のような不要なコメントの抽出を改善し、最終的にはコマンドの自動実行によって、AIが自律的にチームの文脈を学び、自己成長する「AIレビュアー」を実現することを目指しています。これにより、レビューにかかるコストを削減し、チーム全体の開発体験を向上させることが目標です。 引用元: https://www.m3tech.blog/entry/2025/09/06/110000 Experimenting with local LLMs on macOS この記事は、Macユーザーが自分のパソコンでLLM（大規模言語モデル）を動かす方法と、その魅力や注意点について解説しています。著者はLLMに少し懐疑的ながらも、新しい技術に触れる面白さからローカル環境での利用を推奨しています。 なぜローカルでLLMを動かすのでしょうか？クラウドサービスでも使えますが、ローカル環境にはいくつかの大きなメリットがあります。 技術的な興味と実験: 自分のPCでLLMが動くのは、まるで魔法のようです。エンジニアとして、この技術がどう動くのかを実際に試すのは、とても興味深い体験になります。 データプライバシーの確保: ChatGPTなどのサービスでは、入力したデータが企業に利用される可能性があります。ローカルで動かせば、機密情報が外部に漏れる心配がなく、安心して使えます。 倫理的な懸念: AI企業によっては、データ利用や環境負荷、著作権侵害など、倫理的に問題視される行為があると著者は指摘します。ローカルでオープンなモデルを使えば、そうした懸念を避けられます。 macOSでローカルLLMを動かす方法は主に二つ紹介されています。 llama.cpp: オープンソースのプロジェクトで、様々なプラットフォームに対応しており、Web UIも備えています。自分でコマンドを叩いて、細かく設定をいじりたい人向けです。 LM Studio: こちらはGUIが非常に使いやすく、モデルの検索、ダウンロード、チャット管理など、ほとんどの操作を直感的に行えます。初心者のエンジニアの方には特におすすめです。 モデルを選ぶ際には、いくつかのポイントがあります。 モデルサイズとメモリ: LLMは大量のメモリ（RAM）を消費します。お持ちのMacのRAM容量（例えば16GBなら12GB以下のモデルが目安）に合わせてモデルを選ぶことが重要です。大きすぎるとPCが動かなくなってしまうこともあります。 ランタイム: モデルの種類によって、llama.cppが使うGGUF形式か、Appleが開発したMLXランタイムが使うMLX形式かを選びます。 量子化（Quantization）: モデルの精度を少し下げてファイルサイズを小さくする技術です。通常は「Q4」などのデフォ

  4. 3日前

    マジカルラブリー☆つむぎのピュアピュアA.I.放送局 podcast 20250908

    関連リンク AI エージェントとはそもそも何か？ - 技術背景から Amazon Bedrock AgentCore での実装まで- / AI Agent Unicorn Day 2025 この資料は、AIエージェントの基本的な考え方から、AWSの「Amazon Bedrock AgentCore」を使った具体的な実装方法までを体系的に解説しています。AIエージェントがどういうものか、なぜ今注目されているのか、その技術的な背景から実践的な内容まで、新人エンジニアの方にも分かりやすく説明されています。 まず、AIエージェントとは、大規模言語モデル（LLM）がまるで人間のように、自分で考えて行動し、目標を達成する仕組みのことです。従来のシステムが決められた手順を実行するのに対し、AIエージェントは状況に応じて最適な判断を下し、必要なタスクを自律的に進めることができます。 このAIエージェントが実現できた背景には、LLMの「論理的に考える力（推論能力）」の大きな進化があります。「Chain-of-Thought（CoT）」という技術では、「ステップバイステップで考えよう」と指示するだけで、LLMが複雑な問題を段階的に推論できるようになりました。さらに、「ReAct（Reasoning and Acting）」のように、推論と行動を繰り返すことで、より高度なタスクをこなせるようになっています。WebGPTのように、LLMがインターネット検索などの外部ツールを自律的に使う研究も進んでいます。 また、AIエージェントは、テキストだけでなく画像や音声など、様々な情報から状況を認識する「マルチモーダル」な能力も高めています。これにより、現実世界に近い多様な情報源からフィードバックを得て、より適切な判断を下せるようになります。 AIエージェントを実際の業務で活用するには、エージェント同士や外部のシステムがスムーズに連携することが重要です。そのために、「Model Context Protocol（MCP）」や「Agent2Agent（A2A）」といった共通のルール（プロトコル）が提唱され、異なるエージェント間での協調や情報共有を安全に行えるようになっています。 AWSが提供する「Amazon Bedrock AgentCore」は、これらのAIエージェントを開発し、企業で安全かつ大規模に運用するためのサービスです。AgentCoreは、エージェントの実行環境（Runtime）、記憶（Memory）、認証・認可（Identity）、外部ツールとの連携（Gateway）、ブラウザ操作（Browser Tool）、コード実行（Code Interpreter）、監視（Observability）といった多岐にわたる機能を提供します。これにより、開発者は複雑なインフラを意識することなく、AIエージェントの開発と運用に集中できます。 この資料を通じて、AIエージェントの基本的な仕組みと、それを実用化するためのAWSのサービスについて理解を深め、今後のAI開発のヒントを得られるでしょう。 引用元: https://speakerdeck.com/hariby/ai-agent-unicorn-day-2025 ChatGPT is not an LLM - GPT is Vinci Rufus AI業界では、「ChatGPT」と「LLM（大規模言語モデル）」という言葉が混同されがちです。しかし、これらは根本的に異なる概念であり、この誤解はAIの製品開発や将来の方向性に大きな影響を与えています。新人エンジニアの皆さんも、この違いをしっかり理解することで、AI開発や利用の視点が大きく広がるでしょう。 元々、ChatGPTはOpenAIの「GPT」というLLMの単なるチャットインターフェースでした。しかし、時を経て進化し、今では「AIエージェント」という、もっと複雑なシステムになっています。LLMは、大量のテキストデータからパターンを学習し、次の単語を予測する、いわば「超高性能な文章生成機」です。一度学習が完了すると、新しい情報を自分で学ぶことはなく、過去の会話も記憶しません。そのため、同じ質問をすれば常に同じような答えを返す、ステートレス（状態を持たない）な特徴があります。これは、予測可能でスケーラブルであるという利点がある一方で、複雑な多段階のタスクや、会話の流れを理解して対応するのには限界があります。 一方、現在のChatGPTのような「AIエージェント」は、LLMをその中心的な「脳」の一部として使いつつ、以下のような様々な機能を持ち合わせています。 記憶システム: 過去の会話やユーザーの好みを覚えて、文脈に沿った対応ができます。 ツール連携: ウェブ検索、コード実行、データベース照会、外部API利用など、様々な外部システムと連携し、情報を取得したり操作したりできます。 学習と適応: セッション内やセッション間で、経験から学び、対応を改善できます。 多段階の推論: 複雑な問題を小さなステップに分解し、段階的に解決策を導き出すことができます。 目標指向の行動: 単に質問に答えるだけでなく、具体的な目標に向かって行動し、問題を解決しようとします。 つまり、LLMは言葉を操るコアな能力を提供する部品であり、AIエージェントは、そのLLMに「記憶」「道具（ツール）」「計画性」「目標」などを与え、より賢く、自律的に動けるようにしたシステムなのです。 この違いを理解することは、エンジニアにとって非常に重要です。LLMを直接利用するアプリケーションと、AIエージェントを構築するシステムでは、開発の考え方、必要な技術、ユーザー体験のデザインが全く異なります。 現在のChatGPTは、単なる言語モデルと会話しているのではなく、記憶を持ち、ツールを使いこなし、目標に向かって推論する「インテリジェントエージェント」と協力しているのだと理解しましょう。この認識が、皆さんがAIとどのように向き合い、どんな未来を創造していくかを決める鍵となるでしょう。 引用元: https://www.vincirufus.com/posts/chatgpt-is-not-an-llm/ LLM・Agentを「戦力化」するために——本づくりの背景と、いま伝えたいこと LayerX CTOの松本氏が、AIをビジネスで実用的に活用するためのノウハウをまとめた書籍『生成AI「戦力化」の教科書』を出版します。この記事は、その書籍の目的と内容を解説したものです。 この本は、単なるAIの技術解説書や事例集ではありません。LLM（大規模言語モデル）やAIエージェントを、企業の業務にどうやって「本当に使えるもの」として組み込むか、その具体的な「やり方」に焦点を当てています。新人エンジニアの皆さんも、これを読めば、AIを使って自社の業務を効率化する全体像や、小さく始めるための手順が理解できるようになるでしょう。 記事が提唱する「戦力化」とは、AIをまるで「新人社員」のように企業内で育て、その組織のやり方で成果を出せるようにすることです。多くの人が個人的にはAIの便利さを実感していますが、会社全体でAIを事業の核となる業務に深く組み込めているケースはまだ多くありません。AIは賢く知識も豊富ですが、新人と同じく、会社の固有のルールや業務の進め方は知りません。時には事実と異なることを言ったり（ハルシネーション）、毎回指示しないと同じように動けなかったりする課題があります。だからこそ、人間をオンボーディングするように、AIにも仕事の手順と知識をきちんと教える必要があるのです。 日本の企業が持つ、長年培われた丁寧な業務プロセスは、生成AIの活用と非常に相性が良いと筆者は指摘します。業務の「入口」と「出口」は変えずに、その間の時間のかかる処理やヒューマンエラーが起きやすい部分だけをAIに任せるというアプローチです。例えば、書類作成、データの転記・抽出、内容のレビュー、資料の整理といった「読む・探す・書く・照合する」作業をAIに肩代わりさせることで、業務そのものを大きく変えずに効率化を目指します。 本書で紹介される「AI戦力化」の二本柱は以下の通りです。 ワークフロー: AIに「仕事の仕方」を教えるためのものです。業務を細かくステップに分け、それぞれの入力・出力・品質基準を明確にして手順書のように定義します。 ナレッジベース: AIに「判断の根拠となる社内知識」を与えるためのものです。社内規定、過去の資料、FAQなど、業務判断に必要な“暗黙知”をAIが検索・参照しやすい形に整理します。 これらの基盤が整ってこそ、AIエージェントは真価を発揮します。エージェントは魔法のように何でもこなすわけではありません。ワークフローで定義された目的や使えるツール、参照すべき知識の範囲内で、ナレッジベースを根拠として活用する「小さな実行単位」として機能します。過度な自律

  5. 私立ずんだもん女学園放送部 podcast 20250905

    6日前

    私立ずんだもん女学園放送部 podcast 20250905

    関連リンク Difyで実現するAIヘルプデスク：顧客体験を向上させた構築の裏側 kickflow社が、顧客体験を向上させるため、AIヘルプデスクを構築した事例について紹介されています。このプロジェクトはテクニカルサポートチームが中心となり、非エンジニアでもLLM（大規模言語モデル）を活用した開発に挑戦できることを示しています。 AIヘルプデスクの構築には、オープンソースのLLMアプリケーション開発プラットフォーム「Dify」が使用されました。DifyはGUIベースで直感的にワークフローを構築でき、特にRAG（Retrieval-Augmented Generation）の仕組みを簡単に作れる「ナレッジベース」機能が導入の決め手となりました。これにより、既存のヘルプ記事に加え、過去の問い合わせ履歴もAIの知識として学習させることができました。 AIヘルプデスクはDifyの「チャットフロー」機能で設計されており、以下のステップで動作します。 検索キーワード抽出: ユーザーの質問からLLM（例: Gemini 2.0 Flash Lite）がキーワードを抽出し、検索精度を高めます。 知識検索: 登録されたナレッジから、キーワードと意味の両方で関連性の高い情報を探し出します。 IF/ELSE分岐: 検索結果の有無に応じて、適切な回答生成フローに切り替えます。 回答生成: 検索で得た情報をもとに、別のLLM（例: Claude 4.0 Sonnet）が回答を生成します。 会話履歴の保持: 会話の流れを記憶し、自然な多段階のやり取りを可能にします。 このように、目的や状況に応じて異なるLLMを使い分け、処理を細かく分けることで、回答の精度と応答速度の両方を高めています。 回答精度をさらに向上させるため、主に三つの工夫が施されました。一つ目は、既存のヘルプ記事だけでなく、過去のZendesk問い合わせチケット約150件を個人情報を除去した上でナレッジとして活用した点です。二つ目は、「REST API / Webhook」のような複雑な専門分野の質問に対しては、質問分類器を使って専用のプロンプトで対応するノードに処理を振り分けた点です。三つ目は、実際の問い合わせデータを使って継続的に回答精度を評価し、ヘルプ記事がある質問への正答率を70%から80%以上に向上させた点です。 また、プロンプトエンジニアリングにより、「承認経路を変更してほしい」といった個別対応が必要な質問には回答しないようAIの振る舞いを制御したり、「kickflow」といった表記ゆれを統一したりするなど、細かな応答制御も行われています。 運用面では、ヘルプ記事の更新時や問い合わせ対応がクローズされた時にナレッジが自動で更新される仕組みを構築し、常に最新の情報に基づいた回答ができるようにしました。 リリース後には、ナレッジにない内容に対してハルシネーション（事実に基づかない回答生成）が発生するという課題に直面しましたが、LLMと対話しながらプロンプトを改善することで対応しました。今後は、回答数の増加やサポートへのシームレスな連携など、さらなる機能改善を目指しています。このAIヘルプデスク構築は、テクニカルサポートチームとエンジニアの協力があって初めて実現できた、実用的なAI活用の成功事例と言えるでしょう。 引用元: https://tech.kickflow.co.jp/entry/2025/09/03/123008 gpt-oss-120b を試す！高火力 DOK で始めるコンテナ型GPUクラウド活用 OpenAIから新たに公開された大規模言語モデル（LLM）「gpt-oss-120b」と「gpt-oss-20b」を、さくらインターネットのコンテナ型GPUクラウドサービス「高火力 DOK」で動かす方法を紹介する記事です。新人エンジニアの方にも分かりやすく、その概要を解説します。 まず「gpt-oss」は、OpenAIが公開した「オープンウェイト」のLLMです。これは、モデルの重み（パラメーター）が公開されているため、外部のAPIサービスに頼らず、自分たちのサーバー環境で動かせるのが大きな特徴です。これにより、企業の機密情報を扱うようなクローズドな環境でも、安心してAIを活用できるようになります。記事によると、その性能はOpenAIの他のモデルにも匹敵するとされています。 このgpt-ossを動かすのに使うのが、「高火力 DOK」というサービスです。これは、Dockerイメージ（アプリケーションを動かすためのパッケージ）をクラウド上で簡単に実行できる、GPU（AIの計算に特化した高性能な部品）付きのクラウドサービスです。AI開発において、高性能なGPUを必要な時に使えるのは非常に便利ですね。 さらに、LLMをOpenAI互換のAPIとして提供する「vLLM」というツールと、それをWebブラウザで操作できるUI「Open WebUI」を組み合わせます。記事では、高火力 DOK上でvLLMを使ってgpt-ossモデルを起動し、そのAPIエンドポイントをOpen WebUIに設定することで、まるでChatGPTのようにgpt-ossと対話できる環境を構築する手順が解説されています。 具体的には、高火力 DOKのコントロールパネルから、vLLMのDockerイメージとgpt-ossモデル（mxFP4形式に対応するため、NVIDIA H100 GPUプランを選択）を指定してタスクを作成します。そして、ローカル環境でOpen WebUIをDockerで起動し、先ほど高火力 DOKで立ち上げたgpt-ossのURLを設定すれば、すぐにチャットを開始できるとのことです。 このように、高性能なオープンソースLLMを、セキュリティを確保しつつ自分たちの環境で動かせるようになるのは、AI活用の幅を大きく広げることにつながります。クラウドを活用したLLMの動かし方に興味がある新人エンジニアの方にとって、実践的な第一歩として非常に参考になる内容ですね。 引用元: https://knowledge.sakura.ad.jp/46179/ Detecting Exposed LLM Servers: A Shodan Case Study on Ollama 皆さん、AI技術、特にLLM（大規模言語モデル）の活用が急速に進んでいますね。とても便利になった反面、その裏には「セキュリティ」という大切な課題があります。この記事は、私たちがLLMを安全に使うために知っておくべき、ある深刻な問題とその対策について教えてくれます。 記事の核心は、多くのLLMサーバーがインターネットに「鍵をかけずに」公開されているという衝撃的な事実です。特に、手軽にLLMをローカル環境で動かせる「Ollama」というフレームワークを使ったサーバーに焦点を当てて調査されました。 どんな問題が起きているの？ LLMサーバーが認証なしでインターネットに公開されていると、誰でも勝手にアクセスして、以下のような危険な行為が可能になってしまいます。 不正利用: 悪意のあるユーザーが自由にプロンプトを送り、LLMを悪用したり、情報を抜き取ったりする。 リソースの浪費: サーバーの計算資源を勝手に使われ、意図しない高額な費用が発生する。 システムの乗っ取り: 悪質なモデルをアップロードされたり、設定を改ざんされたりする。 この研究では、「Shodan（ショーダン）」というインターネット上のデバイスを検索するツールと、自作のPythonツールを使って、実際にどれくらいのLLMサーバーが公開されているかを調査しました。その結果、なんと1,100以上のOllamaサーバーが公開されており、そのうち約2割が、実際に認証なしでモデルを動かしていることが判明したのです。また、多くのLLMがOpenAI互換のAPIを使っているため、攻撃の手口が広がりやすい点も指摘されています。 新人エンジニアとしてどう対策するべき？ この結果から、私たちエンジニアがLLMをデプロイする際に絶対に守るべきセキュリティの基本は次の通りです。 認証を必ず設定する: LLMサーバーには、APIキーやID・パスワードなどの認証機能を必ず導入し、許可された人だけがアクセスできるようにしましょう。これはセキュリティの「一番の鍵」です。 ネットワークで守る: 外部からのアクセスを制限するため、ファイアウォールやVPNを使って、LLMサーバーがインターネットから直接見えないようにすることが重要です。 デフォルト設定を変える: デフォルトのポート番号や、サーバーが自動で公開する情報（バナー）を隠すだけでも、攻撃者から見つけられにくくなります。 継続的に監視する: 自分の構築したLLM環境が意図せず公開されていないか、定期的にチェックする仕組みを作りましょう。 LLMは強力なツールですが、セキュリティ対策を怠ると大きなリスクに繋がります。この記事は、LLMを安全に運用するための具体的なヒントをたくさん与えてくれています。私たち一人ひとりがセキュリテ

  6. 9月3日

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

    関連リンク Spec-driven development with AI: Get started with a new open source toolkit GitHubが、AIを活用した新しいソフトウェア開発手法「仕様駆動開発 (Spec-driven development)」を実現するためのオープンソースツールキット「Spec Kit」を公開しました。これは、AIによるコーディングの課題を解決し、開発プロセスをより効率的かつ信頼性の高いものにする画期的なツールです。 これまでのAIを使ったコーディングでは、漠然とした指示でAIがコードを生成するため、「何となく良さそうに見えるけど、期待通りに動かない」といった課題がありました。これはAIの能力不足ではなく、私たち人間がAIを検索エンジンのように使い、曖昧な指示を与えていたことに原因があります。Spec Kitは、AIを「文字通り、忠実なペアプログラマー」として活用するため、明確で具体的な「仕様」を軸に開発を進めます。 Spec Kitが提案する開発プロセスは、以下の4つのフェーズで構成されています。 Specify（仕様化）: まず、開発者が「何を作るのか、なぜ作るのか」という高レベルな目的やユーザー体験をAIに伝えます。AIはそれを受け、技術的な詳細ではなく、ユーザーの旅路や成功の基準に焦点を当てた詳細な「仕様」を生成します。これはプロジェクトの「設計図」のようなものです。 Plan（計画）: 次に、開発者が希望する技術スタック、アーキテクチャ、既存システムとの連携、パフォーマンス要件などの技術的な制約をAIに与えます。AIはこれに基づき、具体的な「技術計画」を立てます。 Tasks（タスク化）: AIは、生成された仕様と計画から、一つ一つが小さく、独立してテスト可能な「タスク」のリストを作成します。これにより、AIは自身の作業を細かく検証しながら進めることができます。 Implement（実装）: 最後に、AIがこれらのタスクを一つずつ実行し、コードを生成します。開発者は、大量のコードを一気にレビューするのではなく、特定の課題を解決する小さな変更を集中してレビューします。 このプロセス全体を通して、開発者の役割は単にAIに指示を出すだけでなく、各フェーズでAIが生成した仕様、計画、タスク、コードを「検証」し、必要に応じて修正・改善することにあります。AIは成果物を作り、開発者はそれが正しいことを保証するのです。 このアプローチの最大の利点は、AIに「何を、どのように、どの順序で構築すべきか」を明確に伝えられる点です。これにより、AIは推測に頼ることなく、開発者の意図に沿った高品質なコードを生成できるようになります。 Spec Kitは、新しいプロジェクトの立ち上げ、既存システムへの機能追加、あるいはレガシーシステムのモダナイゼーションといった様々な場面で強力な支援を提供します。これまでの「コードが真実の源」という考え方から、「意図（仕様）が真実の源」へとシフトすることで、私たちはAIをより効果的に活用し、ソフトウェア開発における人間の創造性を最大限に引き出すことができるでしょう。 引用元: https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/ プロンプトエンジニアリングは死んだ？ 松尾研が徹底解剖「AIエージェントの本質」 AI技術の進化が加速する中で、「プロンプトエンジニアリングはもう必要ないのか？」という問いが投げかけられています。特に、OpenAIやGoogleといった大手AI開発企業が、ユーザーの細かい指示なしにAIが自律的にタスクをこなす「AIエージェント」を次々と発表しており、これが金融や行政など、さまざまな分野で導入され始めています。この流れの中で、これまでのプロンプト設計の考え方が大きく変化しようとしています。 以前は、AIに特定の成果を出させるための「魔法のような」プロンプトを書ける専門家（プロンプトエンジニア）が重宝され、高額な報酬が支払われることもありました。しかし、AIエージェントが賢くなり、ユーザーの意図をより深く理解して行動するようになるにつれて、そのような「魔法使い」の役割は減ってきているように見えます。この状況から、「プロンプトエンジニアリングは死んだ」と考える人もいるかもしれません。 しかし、この記事では、この変化を「死んだ」と捉えるのではなく、「コモディティ化した」と本質を突いた見方をしています。これは、プロンプトエンジニアリングが一部の特別なスキルを持つ人だけのものではなくなり、生成AIを利用するすべての人、特に私たちエンジニアにとって、当たり前の基礎スキルになったことを意味します。 松尾研究所は、単に「こんなプロンプトを使えば良い」という具体的なテクニック集を示すだけではありません。「なぜそのプロンプトがうまく機能するのか？」「どうすれば効果的なプロンプトを作り出せるのか？」といった、その背景にある考え方や原理原則を体系的に解説することを目指しています。 新人エンジニアの皆さんにとって、AIエージェントが普及する時代においても、AIと適切にコミュニケーションをとり、その能力を最大限に引き出すための「対話力」は非常に重要なスキルとなります。プロンプトエンジニアリングは、その対話力を磨くための基礎となる知識であり、表面的な使い方だけでなく、その「なぜ」と「どのように」を理解することで、これからのAIとの協働において、より深く、より本質的にAIを使いこなせるようになるでしょう。 引用元: https://www.sbbit.jp/article/fj/170379 Codex CLIを使いこなすための機能・設定まとめ 皆さん、こんにちは！今回は、OpenAIが提供する新しいCLIツール「Codex CLI」について、新人エンジニアの方にも分かりやすく、その魅力と活用術を解説します。 Codex CLIって何？なぜ話題なの？ Codex CLIは、OpenAIが開発したコマンドラインインターフェース（CLI）形式のAIアシスタントです。今年4月に登場したばかりですが、OpenAIのChatGPT有料プラン（Plus/Pro/Team）に加入していれば、追加料金なしで利用できるようになりました。 また、これまで人気のあった「Claude Code」という類似ツールの性能劣化が指摘される中、多くの開発者がCodex CLIへの移行を検討しています。残念ながら公式ドキュメントがまだ少ないため、今回の記事では、この便利なツールの機能や設定方法をまとめて紹介します。 まずは基本設定から！ インストール：npm install -g @openai/codexか、brew install codexで簡単に導入できます。 日本語対応：~/.codex/AGENTS.mdファイルに「日本語で簡潔かつ丁寧に回答してください」と書くだけで、AIがデフォルトで日本語で応答してくれるようになります。これは「Custom Instructions」として多くのAIツールで共通して使える便利な設定ファイルです。 設定ファイル：~/.codex/config.tomlが主な設定ファイルです。環境変数やコマンドライン引数で設定を一時的に上書きすることも可能です。 これだけは試したい！便利な機能と設定 GPT-5の推論を強化：config.tomlにmodel_reasoning_effort = "high"と設定しましょう。これにより、AIがより深く思考し、質の高い回答を出すようになります。これは特におすすめの設定です！ タスク完了を音で通知：notify = ["bash", "-lc", "afplay /System/Library/Sounds/Ping.aiff"]と設定すれば、AIの応答準備ができたときにMacで音が鳴り、作業効率が上がります。 Web検索を有効に：[tools] web_search = trueと設定すると、AIがWeb検索を使って最新の情報に基づいた回答をしてくれるようになります。 よく使うプロンプトをカスタムコマンドに：~/.codex/prompts/にファイルを作成すれば、/リファクタリングのようにスラッシュコマンドとして、頻繁に使うプロンプトを簡単に呼び出せます。 思考ログの非表示：AIが回答を導き出すまでの思考過程を示す「reasoning」ログが冗長だと感じる場合は、hide_agent_reasoning = trueで非表示にできます。 ファイル内容を参照：プロンプト内で@path/to/fileと書くと、そのファイルの内容をAIに教えて、コードのレビューや修正を依頼できます。 VS Code拡張：CodexのVS Code拡張を使えば、VS Codeで開いているファイルを簡単に参照したり、Codex Cloudにタスクを送信したりできて便利です。 その他知っておきたいこと /newで新しいセッションを開始、/compactで対話履歴を要約してトークンを節約できます。 利用プランによっては、一定時間あた

  7. 9月2日

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

    関連リンク LangChain & LangGraph 1.0 alpha releases 今回は、AI開発の主要フレームワークであるLangChainとLangGraphの1.0アルファ版がリリースされたという、注目すべきニュースをお届けします。このリリースは、AIアプリケーション開発の現場で活躍する、特にこれからAIの世界に飛び込む新人エンジニアの皆さんにとって、非常に重要な進歩となるでしょう。 まず、LangGraphについてです。これは、自律的にタスクをこなすAIシステム、いわゆるAIエージェントを効率的に「オーケストレーション」（複数の要素を組み合わせて協調的に動かすこと）するための低レベルなフレームワークです。複雑なAIエージェントシステムを本番環境で安定稼働させるための、きめ細かい制御や、エラーが起きても処理を続けられる「耐久性のある実行」機能を提供します。また、短期的な記憶や、人間が途中で介入できる仕組みも備わっています。UberやLinkedInといった大手企業でも既に本番環境で活用されており、その堅牢性は実証済みです。今回の1.0リリースでは、既存の機能との互換性を保ちながら、さらに安定性が高められています。 次に、LangChainです。こちらは、より手軽にAIの機能をアプリケーションに組み込むための高レベルなフレームワークです。様々なAIモデル（例えばOpenAIのGPTシリーズなど）との連携を標準化してくれるため、特定のベンダーに縛られずに、素早くAI機能を開発できます。LangChain 1.0では、LLM（大規模言語モデル）が外部ツールを使ってタスクを自動でこなす「エージェント」という概念に、特に焦点を当てています。例えば、LLMにWeb検索ツールを与えて、必要な情報を自動で収集させるといった使い方が可能です。新しいcreate_agent機能は、先ほど紹介したLangGraphの強力な基盤の上に構築されているため、より高度で安定したエージェントの構築が可能になります。もし皆さんが既存のLangChainの機能を使っている場合でも心配はいりません。従来の機能はlangchain-legacyという新しいパッケージで引き続き利用できるよう配慮されています。 そして、LangChainの基盤となるパッケージであるLangChain Coreも1.0に昇格しました。これは、LangChainが多様なAIサービスと連携するための共通の抽象化層を提供しています。今回のアップデートで特に注目すべきは、LLMとのやり取りに使われる「メッセージ」の形式が進化し、テキストだけでなく、画像や動画といった多様な情報を扱える「コンテンツブロック」に対応した点です。これにより、よりリッチで複雑なAIアプリケーションが作れるようになります。 さらに、PythonとJavaScriptの両方に対応した、新しい統一されたドキュメントサイトも公開されました。これにより、学習がさらにしやすくなるでしょう。 今回のアルファリリースを経て、10月下旬には正式な1.0バージョンが登場する予定です。皆さんのフィードバックが、今後の開発に貢献する機会にもなります。AI開発の進化を加速させるこれらのツールが、今後どのように活用されていくのか、非常に楽しみですね！ 引用元: https://blog.langchain.com/langchain-langchain-1-0-alpha-releases/ シングルエージェント vs マルチエージェントを整理してみる AIエージェントの設計において、「シングルエージェント」と「マルチエージェント」という2つの主要な考え方があり、どちらを選ぶべきかという議論が活発になっています。新人エンジニアの皆さんも、これからのAIシステム開発で直面する可能性のある重要なテーマなので、一緒に整理していきましょう。 マルチエージェントとは？ 複数のAIエージェント（自律的に思考・行動するAI）がチームを組んで協力し、一つのタスクをこなすイメージです。 得意なこと: Anthropicの研究のように、複雑な情報をリサーチする「読み込み中心」のタスク（例：論文調査、情報収集）で高い性能を発揮します。複数のAIが並行して情報を集めることで、効率的に進められます。 難しいこと: 複数のAIが協調するため、AI同士の「情報共有（コンテキスト共有）」が難しくなる点が課題です。Cognition AI（Devinの開発元）は「マルチエージェントを作るな」と主張し、例えばFlappy Birdのゲーム開発で、背景担当のAIがマリオ風、鳥担当のAIがリアルな鳥を作るなど、各AIが独自の判断（暗黙の決定）をしてしまい、最終的に一貫性のない成果物になる例を挙げています。人間同士のプロジェクトでも、情報共有が不十分だと認識のズレが生まれるのと似ていますね。また、トークン使用量が増えコストが高くなる傾向もあります。 シングルエージェントとは？ 一つのAIエージェントが、最初から最後まで責任を持ってタスクをこなすイメージです。 得意なこと: コーディングのような「書き込み中心」のタスク（例：コード生成、コンテンツ作成）で、一貫性のある成果物を作りやすいとされています。一つのAIが全ての文脈（コンテキスト）を把握したまま作業を進めるため、矛盾が生じにくく信頼性が高まります。デバッグ（不具合の原因探し）も比較的容易です。 難しいこと: 複雑なタスクになると、AIが一度に扱える情報量（コンテキストウィンドウ）の限界にぶつかる可能性があります。 結局、どう使い分けるの？ LangChainも指摘しているように、どちらが優れているというより、タスクの特性によって最適な選択が変わります。 読み込み中心のタスク（リサーチ、分析）: 複数のAIが情報を集めても矛盾しにくいので、マルチエージェントが有効な場合が多いです。 書き込み中心のタスク（コーディング、コンテンツ作成）: 一貫性が非常に重要なので、シングルエージェントの方が適している場合が多いです。 まとめ AIエージェントの設計は、ソフトウェア開発と同じで、どんな「仕事」をさせたいかによって最適なアーキテクチャを選ぶことが大切です。 タスクの並列化のしやすさ AI間の情報共有の必要性（一貫性がどこまで重要か） 開発コストや運用コスト これらをよく考え、最初はシンプルな構成（シングルエージェント）から始めて、必要に応じてマルチエージェントやハイブリッドなアプローチを検討するのが良いでしょう。「Keep It Simple, Stupid（シンプルに保て）」という原則がここでも重要になります。AIに適切に情報を伝える「コンテキストエンジニアリング」の技術も、これからますます重要になってきます。 引用元: https://zenn.dev/r_kaga/articles/ea7119d22d4d3c Claude Codeを使ってAIにブログ記事執筆を任せてみた ブログ記事を書くのは大変だと感じていませんか？「記事の構成を考えるのが苦手」「なかなか書き始められない」といった課題を抱えているエンジニアは少なくないはずです。この記事では、そんな悩みを解決するために、AIコーディングツール「Claude Code」とAIエージェントを活用して、ブログ記事執筆を効率化する仕組みが紹介されています。 筆者の @modokkin さんは、記事執筆のハードルを下げるために、Claude Codeのスラッシュコマンドと複数のAIエージェントを組み合わせたワークフローを構築しました。 この仕組みの核となるのは、次の3つのエージェントです。 インタビュアーエージェント: ブログ記事のテーマについて、筆者に質問を投げかけます。まるで対話しながら思考を整理するような形で、記事に必要な情報を段階的に引き出してくれます。 ゴーストライターエージェント: インタビュアーが集めた情報と、事前に設定した「スタイルガイド」に基づき、実際に記事の初稿を執筆します。これにより、AIが書いた文章でも、ある程度筆者らしい文体を再現できます。 編集者エージェント: 初稿が完成した後、/review コマンドで呼び出せます。このエージェントは、記事の文体や事実関係（ファクトチェック）をチェックし、より質の高い記事に仕上げるのを手助けしてくれます。 特に重要なのが「スタイルガイド」の存在です。これは、記事の冒頭の挨拶、文体（です・ます調など）、締めくくりの定型文といった、筆者独自の執筆ルールをAIに教えるためのものです。これにより、AIは単に情報をまとめるだけでなく、筆者の個性が反映された記事を作成できるようになります。 実際にこの仕組みを使ってみると、LT（ライトニングトーク）のスライドからブログ

  8. 9月1日

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

    関連リンク なぜAI AgentにSQLを直接触らせず、dbt showを使わせたのか この記事では、AIエージェントに直接SQLを操作させることの課題と、それを解決するためにdbtのdbt showコマンドを組み合わせたデータ調査ワークフローについて解説しています。 まず、複雑なデータパイプラインでは、データの正確性や安全性が非常に重要です。しかし、商品データなどの調査は、専門知識が必要で手順も人によって異なり、時間もかかるという課題がありました。 AIエージェントにデータを調査させる際、直接SQL（データベースを操作する言語）を書かせると、以下のような問題が起こります。 知らないテーブルのフルパスを指定してしまい実行に失敗したり、重い処理でコストが増えたりする。 AIにデータベースの詳しい構造を常に教える必要があり、情報が膨大になる。 誤ってデータを削除・変更するような危険なSQL（DDL）を生成するリスクがある。 これらのリスクから、AIに直接SQLを書かせる運用は難しいと筆者は考えました。 そこで登場するのが「dbt」というツールです。dbtは、SQLを直接書くのではなく、データ変換のロジックを「モデル」という形で管理します。開発者は複雑なデータベースのフルパスを知らなくても、ref('モデル名')のようにシンプルにモデル名を指定するだけでデータを操作できます。AIにもこの「モデル」のレベルで操作させれば、より安全で効率的だと考えました。 解決策として採用されたのが、dbtが持つdbt showコマンドです。これは、dbtのモデル定義に基づいてSELECT文（データを見るだけの操作）を実行できるコマンドです。 dbt showを使うメリットは次の通りです。 安全: SELECT文に限定されるため、データの変更や削除といった副作用がありません。 抽象化を活用: dbtのモデルや依存関係（DAG）をそのまま利用できるため、AIに複雑なデータベース構造を教える必要がなく、渡す情報を最小限に抑えられます。 再現性: dbtのマクロや変数を解決して実行するため、人間が書いたSQLと同じロジックでデータを確認できます。 ただし、dbt show --inlineオプションには、任意のSQLが実行できてしまうという潜在的なセキュリティリスクがあることも判明しました。これに対し、記事では入力されたSQLをサブクエリ（SQLの中の小さなSQL）でラップし、危険なSQLが実行されないようにする「ラッパーコマンド」の暫定的な対策が紹介されています。 実際のワークフローでは、ユーザーが「この商品IDの商品を調べてください」とシンプルに依頼すると、AIエージェントはドキュメント化された手順（最終データから遡って原因を探るなど）に従い、dbt showを使いながらデータ調査を進めます。調査結果はファイルに保存され、後から人間が確認できるため、属人化していた調査が誰でも再現可能な形になりました。 この取り組みにより、AIエージェントを安全かつ最小限のコンテキストで動かすことができ、データ調査の効率と信頼性が大幅に向上しました。将来的には、dbtプロジェクト全体の情報をAIに提供できる「dbt MCP Server」のような技術と連携することで、AIの活用範囲はさらに広がると期待されています。モデルやカラムのドキュメント、テストを充実させることが、AI活用を成功させるための重要な鍵となります。 引用元: https://takimo.tokyo/2604aebf66ad8067a25ccd25e459da97 Memento: Fine-tuning LLM Agents without Fine-tuning LLMs 今回ご紹介する「Memento」は、大規模言語モデル（LLM）を基盤としたAIエージェントの学習方法に、新しい風を吹き込む研究です。これまでのLLMエージェントは、特定のタスクに適応させるために、基盤となるLLM自体を「ファインチューニング」、つまり追加で学習させることが一般的でした。しかし、このファインチューニングは計算コストが非常に高く、時間もかかるため、AIエージェントを継続的に、そして柔軟に賢くしていく上での大きな課題でした。 「Memento」が画期的なのは、この基盤LLMをファインチューニングすることなく、低コストで、しかもリアルタイムにAIエージェントを賢く適応させる点にあります。どのように実現しているかというと、彼らは「メモリベースのオンライン強化学習」という手法を取り入れています。これは、AIエージェントが過去の経験を「エピソード記憶」として蓄え、その記憶を元に行動を決め、さらに環境からのフィードバックを受けて記憶を更新していく、という仕組みです。 具体的には、「Memory-augmented Markov Decision Process (M-MDP)」という枠組みで、過去の経験から適切な知識を選ぶ「ニューラルケース選択ポリシー」を使って、次の行動を導きます。この「記憶」は、環境から得た新しい情報や結果に応じて効率的に書き換えられ、また必要な時に素早く読み出されることで、エージェントは常に最適な行動を選べるようになるのです。まるで、人が新しい経験から学び、知恵を増やしていくように、AIエージェントも自ら進化できるイメージです。 この「Memento」を「Deep Research」という複雑な研究タスクに応用したところ、GAIA検証セットで87.88%のPass@3を達成し、従来の学習ベースの手法よりも優れた性能を示しました。また、学習時には遭遇しなかった新しい種類の問題（分布外のタスク）に対しても、記憶を活用することで大幅な性能向上を見せています。 この研究は、大規模な計算資源を必要とするファインチューニングなしに、AIエージェントが自律的に、かつ継続的に学習し、様々なタスクに適応していく新しい道筋を示しています。新人エンジニアの皆さんにとって、今後AIエージェントがどのように進化していくのかを理解する上で、非常に重要な一歩となるでしょう。将来的には、より汎用性が高く、人間に近い形でスキルを習得していくAIエージェントの開発に繋がる可能性を秘めています。コードもGitHubで公開されているので、興味があればぜひ見てみてください。 引用元: https://arxiv.org/abs/2508.16153 Lessons on building an AI data analyst AIデータアナリストの構築は、単に自然言語をSQLに変換するだけでは不十分です。本記事は、実際のAIデータアナリスト開発経験から得られた、重要な教訓と実践的なアプローチを共有しています。 1. Text-to-SQLの限界と多段階分析の必要性 実際のビジネス上の問いは、単一のSQLでは解決困難な複雑さを持ちます。「分析計画の策定」「SQL実行」「Pythonでのデータ処理」「結果検証」「視覚化」「次の質問提案」といった多段階のワークフローが必要です。AIデータアナリストには、エンドツーエンドの分析能力が求められます。 2. セマンティック層によるビジネス意味の定義 AIデータツールでは、データが持つ「ビジネス上の意味」（例：「売上」の計算方法）を一元的に定義する「セマンティック層」が極めて重要です。これにより、LLM（大規模言語モデル）はビジネスロジックを正確に理解し、適切なデータを選び、コード生成の信頼性を高めます。また、生成されたSQLやPythonコードは実行前に検証され、誤りが早期に検出されます。 FindlyではオープンソースのMalloyを採用し、データ関係性、メトリクス、ディメンションを定義。LLMにはRAG（検索拡張生成）と関数呼び出しを通じて、関連するセマンティックモデルの一部を提供し、推論精度を高めています。 3. 複数エージェントシステムによる複雑な問題解決 複雑なリクエストに対しては、複数のAIエージェントが協力して問題を分解するアプローチが効果的です。エージェントは「分析計画の策定」「精密な情報検索」「SQL/Pythonコードの生成と実行」「結果の検証と説明」といった役割を分担します。これにより、AIの幻覚（事実に基づかない誤った情報生成）を減らし、デバッグを容易にします。 4. RAGシステムをレコメンデーションのように最適化 LLMの性能は入力コンテキスト（与えられる情報）の質に大きく依存するため、効率的で精度の高い情報検索（RAG）が不可欠です。キーワード検索と埋め込み検索で候補を生成し、さらにLLMの指示に従うように調整された「リランカー」で関連情報を厳選します。多段階ランキングで処理を最適化し、LLMに短く質の高いコンテキストを提供することで、正確かつ迅速な回答を引き出します。 5. LLM活用の現実と今後の展望 現代

すべて見る（195）

評価とレビュー

番組について

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

情報