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

株式会社ずんだもん技術室AI放送局
  • 0.0(0개의 평가)
  • 과학 기술
  • 매일 업데이트

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

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

    2일 전

    私立ずんだもん女学園放送部 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を安全に運用するための具体的なヒントをたくさん与えてくれています。私たち一人ひとりがセキュリテ

  2. 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で対話履歴を要約してトークンを節約できます。 利用プランによっては、一定時間あた

  3. 4일 전

    株式会社ずんだもん技術室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（ライトニングトーク）のスライドからブログ

  4. 5일 전

    株式会社ずんだもん技術室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活用の現実と今後の展望 現代

  5. 6일 전

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

    関連リンク 最近のClaude Codeの使い方 この記事では、AIを使った開発支援ツール「Claude Code」と、その強力な機能である「Subagent（サブエージェント）」を、開発現場でどう効果的に活用するかについて、具体的なフローを解説しています。新人エンジニアの皆さんも、これらの使い方を覚えることで、開発作業を大きく効率化できるヒントが見つかるでしょう。 1. Claude CodeとSubagentって何？ Claude Codeは、AIがコードの生成や修正、プロジェクトの分析などを手伝ってくれるツールです。Subagentは、このClaude Codeの中に作ることができる、特定のタスクに特化した「小さなAIアシスタント」のようなもの。これを使うと、より複雑な開発プロセスを自動化したり、安定して作業を進めたりすることができます。 2. 既存プロジェクトの調査・改修を効率化！ 初めて触るプロジェクトのコードを理解するのは大変ですよね。Claude Codeを活用すると、その負担を大きく減らせます。 serena MCPの活用: このツールと連携させ、Claude Codeにプロジェクトの構造やコードの依存関係を分析させます。これにより、コード全体を素早く把握できます。 調査結果の自動生成: 「この機能の動きを調べてMarkdown形式でまとめて」と指示するだけで、AIが調査レポートを作成してくれます。このレポートは、後から手動で確認したり、別のAIに再検証させたりすることで、正確性を高められます。 3. 新規開発をSubagentに任せてみる 新しい機能を開発するときも、Subagentが活躍します。 準備: まずは「どんな機能を作るか（仕様概要）」、「どんな技術を使うか（技術詳細）」、「どんな場面で使われるか（ユースケース）」といったドキュメントをしっかり準備します。 タスクの自動実行: これらのドキュメントを基に、Subagentに「このタスクを上から順番に実行して」と指示します。Subagentは、ブランチ作成から、コード実装、テスト・Lint実行、エラー修正、そしてコミット作成までの一連の作業を自動で進めてくれます。 ポイント: エラーが出たときに「エラーを修正しながら何度もやり直してね（iterateして対応）」と指示することが重要です。これにより、Subagentは自己修正しながら目標達成を目指します。 効率的な起動: よく使うSubagentは「/タスク名」のような「スラッシュコマンド」として登録しておくと、ワンコマンドで簡単に起動できて便利です。 4. Subagentを使うと、なぜ開発が楽になるの？ Subagentには、以下のような大きなメリットがあります。 集中できる環境: 特定のタスクに集中するため、以前の会話や作業に引きずられて、AIが間違った行動をするのを防げます。 並行作業の可能性: 独立したタスクであれば、複数のSubagentを同時に動かして、開発をさらにスピードアップできるかもしれません。 品質の安定: 同じ設計書とタスク指示があれば、誰が（どのSubagentが）実行しても、似たような品質の成果物が得られやすくなります。これはチーム開発で特に役立ちます。 Claude CodeとSubagentは、皆さんの開発作業を強力にサポートし、より効率的で質の高い成果を生み出すための頼もしいツールです。ぜひ試してみて、その可能性を感じてください。 引用元: https://zenn.dev/sun_asterisk/articles/7dafd83f1d0454 【エージェントルール】 中長期開発におけるルール設計 この記事では、AIエージェントを活用した中長期的なソフトウェア開発を効率的かつ高品質に進めるための「ルール設計」について解説しています。新人エンジニアの皆さんも、これからの開発現場でAIと協業する機会が増えると思いますので、ぜひ参考にしてみてください。 まず「ルール」とは、GitHub CopilotなどのAIエージェントに、プロジェクト固有の情報を自動で読み込ませるためのカスタム設定ファイルのことです。これにより、毎回同じ指示をプロンプトで繰り返す手間が省け、AIがプロジェクトの文脈を深く理解して、より適切なコードを生成できるようになります。特に、長く続くプロジェクトでは、AIが途中で変なコードを書いたり、過去のコードと整合性が取れなくなったりするのを防ぐために、このルール設計が非常に重要になります。 ルール設計のポイントは以下の4つです。 仕様駆動で進める: AIが勝手に想像でコードを書かないよう、何をどう作るか、仕様を明確に決めてから開発を進めることが大切です。 実装計画書をAIに作らせる: 実装に入る前に、AIに具体的な実装計画書を作ってもらい、開発者と方針をすり合わせることで、後から手直しする手間（手戻り）を減らせます。 実装範囲を明確にする: AIに「どこまで実装すれば良いか」を明確に指示することで、必要以上の機能が勝手に作られるのを防ぎます。 ルールファイルを自動更新させる: ルールは一度作ったら終わりではなく、開発を進める中で得られた新しい知見やフィードバックを元に、AI自身にルールを更新させる仕組みを導入すると効率的です。 実際にルールを導入した開発では、以下のような良い結果が出ています。 既存コードとの整合性向上: プロジェクト内の既存コードやデザインパターンに合わせた、一貫性のあるコードが生成されやすくなりました。 仕様通りの正確な実装: 簡単な指示でも、仕様に沿ったコードが生成され、AIが勝手に余計な機能を追加することが減りました。 AIエージェントとの協業では、ルールの質だけでなく、コード自体の可読性やドキュメンテーションの質もAIの精度に影響します。今後、AIと共に開発を進める上で、プロジェクトに合わせた「ルール設計」は、より安定した開発と高品質な成果物につながる強力な武器となるでしょう。 引用元: https://zenn.dev/sonicmoov/articles/0f9e98f3539d04 GPT-5 プロンプトエンジニアリングガイドを読み解き、より良いコーディング支援を受ける この記事は、OpenAIが公開したGPT-5のプロンプトガイドについて、特にLLM（大規模言語モデル）をコーディング支援やAIエージェントとして活用したい新人エンジニア向けに、要点を分かりやすく解説しています。GPT-5のような高性能AIを最大限に引き出すための実践的なヒントが満載です。 GPT-5は、これまでのモデルより長い指示の理解や正確なタスク実行能力が向上しており、プロンプトの与え方にも新しい工夫が求められます。 GPT-5プロンプトガイドの主なポイント 思考の深さをコントロール: reasoning_effortという設定で、「じっくり考えるか、素早く答えるか」をAIに指示できます。これにより、AIが無駄な思考をせず、効率的かつ適切な結果を出せるようになります。 「70%の確信度で十分」といった早期停止条件や、ツールの利用回数を制限すると、より迅速に結果を得られます。 ツール利用の明確化: AIがどんな目的で、どうツールを使うかをプロンプト内で具体的に示すことで、AIの動作が安定し、利用者が意図を理解しやすくなります。 コーディング支援の最適化: 得意なフレームワーク活用: Next.jsやTailwindなど、AIが得意な特定のフレームワークを活用するよう促すと良いコードが期待できます。 「読みやすさ」を優先: 「賢いコード」よりも「読みやすく、メンテナンスしやすいコード」を書くように指示します。 積極的な提案: AIには、ユーザーが後で修正できる前提で、積極的にコードの改善案を提示させるのが効果的です。 過度な探索指示は不要: GPT-5は元々探索能力が高いため、不必要に「徹底的に情報を集めて」と指示する必要はありません。 指示順守の向上テクニック: 矛盾の排除: プロンプト内の指示に矛盾がないようにすると、AIが迷わずスムーズに処理を進めます。 思考ログの出力: 最終回答の前にAIの思考過程を表示させることで、回答の精度が高まります。 XML形式の区切り: Markdownよりも...のようなXML形式のタグを使うと、AIが指示をより安定して理解しやすくなります。 構造化出力: JSON Schema（Zod, Pydanticなど）を用いて、AIの出力形式を厳密に定義することで、プログラムで扱いやすい結果を得られます。 コーディングエージェントとしての実践的活用例 計画と実装の分離: 大きなタスクは、まずAIに計画を立てさせ、それをレビ

  6. 私立ずんだもん女学園放送部 podcast 20250829

    8월 28일

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

    関連リンク Introduction - Agent Client Protocol 新人エンジニアの皆さん、こんにちは！今回は、これからの開発に欠かせなくなるかもしれない「Agent Client Protocol（ACP）」という新しい技術標準について、分かりやすく説明しますね。 ACPは、皆さんが普段使っているVisual Studio CodeやVimのような「コードエディタ」と、ChatGPTのようにコードを自動で書いたり修正したりする「AIコーディングエージェント」が、スムーズに情報交換するためのルールブックのようなものです。まだ開発途中ですが、これから色々な便利なツールを作る基盤として期待されています。 なぜACPが必要なの？ これまでのAIエージェントとエディタの連携には、いくつかの困った点がありました。 開発の手間が大きい: 新しいAIエージェントが登場するたびに、それぞれのエディタに合わせて専用の連携機能を作る必要がありました。 使える組み合わせが限られる: あるAIエージェントが、特定のエディタでしか使えない、といったことがよくありました。 ツールの選択肢が狭まる: 使いたいAIエージェントのために、あまり好みではないエディタを使わざるを得ない、なんてことも。 これらの問題を解決するために、ACPが提案されました。これは、ちょうどプログラミング言語の「Language Server Protocol（LSP）」が、エディタと各言語の機能（コード補完やエラーチェック）を連携させるのを標準化したのに似ています。ACPがあれば、AIエージェントは一度ACPに対応すれば、どんなエディタでも動くようになりますし、エディタも一度ACPに対応すれば、たくさんのAIエージェントと連携できるようになるんです。これによって、エディタ開発者もAIエージェント開発者も、それぞれ独立して新しい機能を作りやすくなり、私たち開発者はより自由に最適なツールを選べるようになります。 ACPってどんな仕組み？ ACPは、基本的に皆さんがエディタを使っている中で、AIエージェントに手伝ってほしい時に利用することを想定しています。AIエージェントは、エディタの裏側で動き、JSON-RPCという形式で情報をやり取りします。表示される文章などはMarkdown形式を使うので、リッチな表示も可能です。 すでに一部のエディタ（Zed、neovimのプラグイン）やAIエージェント（Gemini）が対応を始めています。ACPが広まることで、AIと協力しながらもっと効率的に開発できる未来が、さらに近づいてくるでしょう！ 引用元: https://agentclientprotocol.com/overview/introduction Building your own CLI Coding Agent with Pydantic-AI この記事は、Pydantic-AIフレームワークとModel Context Protocol (MCP) を活用し、独自のCLIコーディングエージェントを構築する方法を紹介しています。 CLIコーディングエージェントは、ChatGPTのようなチャットボットやCopilotのようなコード補完ツールとは異なり、コードを理解し、テスト実行、ドキュメント検索、さらにはコードベースに直接変更を加えることができる「開発パートナー」のような存在です。著者は、汎用的な市販ツールでは得られない、プロジェクト固有のニーズへの対応や、AIシステムの仕組みを深く理解するために、自作に挑戦しました。 エージェント構築の核となるのは、Model Context Protocol (MCP)です。これは、AIモデルが多様な「ツール」（機能）と標準化された方法で連携するためのオープンなプロトコルで、まるでAIアプリケーションのUSB-Cポートのように機能します。これにより、必要な機能をプラグインのように簡単に追加できます。 構築はAWS Bedrock上のClaudeモデルを基盤にスタートし、以下のように段階的に機能を強化していきました。 テスト実行機能: ユニットテストを自動実行し、失敗を特定して修正を提案。 開発ガイドラインの組み込み: 「実装を修正し、テストは変更しない」といったチームの指針をエージェントに教え込み、望ましい行動を促します。 サンドボックスPython実行: 安全な環境でコードを試行・検証し、複雑な計算の正確性を高めます。 最新情報の参照: 最新のライブラリドキュメントやインターネット検索を通じて、常に最新の情報をエージェントに提供します。 構造化された問題解決: 「Code Reasoning」ツールにより、複雑な問題を論理的に分解し、体系的に解決する能力を付与。 開発環境操作（Desktop Commander）: ファイルの読み書き、コマンド実行、コードの編集など、開発環境で具体的な操作を可能にします。これにより、エージェントはテスト実行からコード修正、再テストまでの一連のデバッグ作業を自律的に行えるようになります。 これらの機能連携により、デバッグ、学習、問題解決、コードレビューといった開発ワークフローは大きく変化します。AIは単なるアシスタントではなく、エラー分析、修正案の提案、検証、ドキュメント参照、コード変更までを一貫して行える「知的パートナー」となるのです。 この経験から、複数の機能を連携させるMCPの重要性、最新情報へのアクセス、構造化された思考、そしてプロジェクトに特化させることの価値が明らかになりました。AIがソフトウェア開発の未来をどのように変えるのか、それを最も深く理解する方法は、自らの手で作り上げてみることだと、この記事は示唆しています。AIは、単にコードを速く書く手助けをするだけでなく、開発者の目標や制約を理解し、共同で問題を解決する真のパートナーへと進化するでしょう。 引用元: https://martinfowler.com/articles/build-own-coding-agent.html Introducing gpt-realtime and Realtime API updates for production voice agents OpenAIが、リアルタイムでの音声対話に特化した新しいAIモデル「gpt-realtime」と、そのための「Realtime API」の機能を一般公開しました。これは、皆さんが普段利用するAIアシスタントや、企業の顧客サポートなどで使われるAI音声エージェントを、より高性能で信頼性の高いものにするための大きな一歩です。 新しいAIモデル「gpt-realtime」のすごい点 この「gpt-realtime」は、音声と音声の間で直接やり取りする「スピーチ・トゥ・スピーチ」という方式で動く、最も進化したモデルです。今までのAI音声システムが「音声を文字に変換→文字で考えて返答→文字を音声に変換」という段階を踏んでいたのに対し、「gpt-realtime」は直接音声で考え、音声で返答します。これにより、以下のようなメリットがあります。 より自然な会話: 人間のような抑揚や感情、速さで話せるようになり、まるで本物の人間と話しているかのような自然な会話ができます。例えば、「優しく、ゆっくり話して」といった細かい指示にも対応します。 高い理解力: 複雑な指示を正確に理解したり、会話中の笑い声のような非言語的なニュアンスも捉えたりできます。また、英語と日本語を混ぜた会話でもスムーズに対応し、電話番号などの数字列の認識精度も向上しました。 賢いツール利用: AIが外部のシステム（データベースや予約システムなど）と連携する「ツール呼び出し」の精度が大幅に向上しました。さらに、ツールが結果を返すまでの間も会話を途切れさせず、スムーズに続けられるようになりました（非同期関数呼び出し）。 新しい声の追加: 「Marin（マリン）」と「Cedar（シダー）」という2つの新しい声が追加され、既存の声もより自然になりました。 Realtime APIの新たな機能でできること このAPIを使うことで、AI音声エージェントはさらに多様なことができるようになります。 画像入力のサポート: 音声だけでなく、写真やスクリーンショットなどの画像もAIに渡せるようになりました。これにより、「この写真に何が写ってる？」といった視覚情報に基づいた会話が可能になります。 電話回線との連携（SIPサポート）: 公衆電話網やビジネスフォンなどの電話システムと直接AIを接続できるようになりました。これにより、AIが電話応対をしたり、電話越しに顧客と会話したりするシステムが簡単に作れます。 外部機能の簡単追加（リモートMCPサーバー対応）: エージェントに新しい機能を追加する際、外部のサーバー（MCPサーバー）のURLを指定するだけで、そのサーバーが提供するツールをすぐに利用できるようになります。 プロンプトの再利用: AIへの指示（プロンプト）を保存して何度も使い回せるようになり、開発効率が上がります。 安

  7. 8월 27일

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

    関連リンク NEC、暗黙知をデータ化し学習・活用することでWeb業務を自動化するエージェント技術「cotomi Act」を開発 NECは、私たちが普段インターネットで行う業務をAIが自動でこなす、新しいエージェント技術「cotomi Act（コトミ アクト）」を開発しました。この技術の大きなポイントは、これまでデータ化が難しかった「暗黙知」をAIが学習し、活用できるようになる点です。暗黙知とは、例えば「この状況では、経験上AよりもBの対応が良い」といった、長年の経験や個人の判断によって培われる、マニュアルには書きにくい知識やノウハウのことです。 この「cotomi Act」の性能は、国際的なAIエージェントのベンチマーク（性能評価テスト）である「WebArena」で実証されました。「WebArena」は、ECサイトでの商品購入や情報検索など、実際のWebサイトでの複雑な操作をAIに指示し、どれだけ正確に実行できるかを評価するものです。この難しいテストで、「cotomi Act」を活用したAIエージェントは、人間の平均成功率（78.2%）を上回る80.4%という世界初の記録を達成しました。これは、AIがまるで人間のように、Web上で様々なタスクを高い精度でこなせるようになったことを示す、非常に画期的な成果です。 「cotomi Act」の特長は主に二つあります。一つ目は、専門家がWebブラウザ上で行った操作（クリックや入力、画面遷移など）の記録から、その裏にある判断基準やノウハウといった暗黙知をAIが自動的に読み取り、データとして活用できる形にすることです。これにより、これまで属人化しがちだった「職人の技」のような知識も、AIが学習できるようになります。二つ目は、そうしてデータ化された暗黙知を、NECが開発した生成AI「cotomi」をはじめとする様々な技術と組み合わせて、AIエージェントの能力を飛躍的に向上させる点です。これにより、AIはユーザーからの少し曖昧な指示に対しても、「業務のコンテキスト（背景や状況）」を深く理解し、適切な情報を見つけたり、必要な手続きを自律的に判断・実行できるようになります。結果として、従来のAIでは難しかった、複雑で専門性の高い業務でも、AIが高精度かつ柔軟に対応できるようになるわけです。 日本では労働人口の減少が進んでおり、企業の生産性向上は喫緊の課題です。この「cotomi Act」は、これまで人の手と経験に頼っていた高度な業務をAIが代行できるようになることで、企業の業務効率化やDX（デジタルトランスフォーメーション）を強力に推進します。NECは、この技術をまず自社で活用し、2026年度中のサービス提供を目指しています。私たち新人エンジニアにとっても、AIが業務の頼れるパートナーとなり、より創造的な仕事に集中できるようになる未来が、すぐそこまで来ていることを感じさせる、大変興味深いニュースと言えるでしょう。 引用元: https://jpn.nec.com/press/202508/20250827_02.html 「推論する生成AI」は事前学習されていない課題を正しく推論することができない（共変量シフトに弱い） 最近の生成AIはまるで人間のように推論しているように見えますが、その能力にはまだ限界があることが最新の研究で明らかになりました。この記事では、「思考の連鎖（Chain of Thought: CoT）推論」と呼ばれる、AIが中間的な思考ステップを示すことで推論を改善する技術について、厳密な実験を通してその実態を探った論文を紹介しています。 この研究の大きな目的は、AIが本当に「ゼロから考えている」のか、それとも「過去に覚えたパターンに当てはめているだけ」なのかを調べることでした。特に、AIがまだ見たことのない問題にどれだけ対応できるか（これを「汎化性能」と言います）に注目しています。 実験では、CoT推論の性能に影響しそうな「問題の種類」「文章の長さ」「問題の形式」という3つの要素を特定し、これらを自由に操作できる「DataAlchemy」という特別なデータセットを用意しました。このデータセットを使って、GPT-2ベースのAIモデルを何種類も学習させ、学習時に与えられたデータ（事前学習データ）とテストで使うデータとの「ずれ」（これを「共変量シフト」と呼びます）が、AIの推論性能にどう影響するかを徹底的に調べました。 その結果、事前学習データとテストデータとの「ずれ」（共変量シフト）が大きくなるほど、AIの推論性能は著しく低下することがはっきりと分かりました。具体的には、学習で使わなかった新しい文字が含まれる問題、文章の長さが極端に異なる問題、推論ステップ数が大きく変わる問題、あるいは問題文に少しノイズ（余計な情報）が加わるだけで、AIは正しく推論できなくなってしまうのです。驚くべきことに、AIモデルを大きくしたり、学習方法を工夫したりしても、この傾向は変わりませんでした。これは、AIが真に推論しているわけではなく、過去に見たデータパターンに強く依存していることを示しています。 この研究は、「推論する生成AI」が行っているのは、論理的な思考というよりも、事前学習データに最適化された「洗練されたパターンマッチング」に過ぎないという結論を導き出しています。つまり、人間のように全く新しい概念を理解し、ゼロから推論する能力はまだ持っていないということです。 新人エンジニアの皆さんがAIを活用する際には、この「AIは学習データにないものには弱い」という特性をしっかり理解しておくことがとても重要です。AIの力を最大限に引き出すためには、単に学習データを増やすだけでなく、実際に使うシーンでAIが直面するかもしれない「未知の問題」や「学習データからずれた状況」を想定し、そこでどれだけ正確に機能するかを評価する視点を持つことが大切だという示唆を与えてくれる記事です。 引用元: https://tjo.hatenablog.com/entry/2025/08/27/173000 How to Improve CUDA Kernel Performance with Shared Memory Register Spilling 新人エンジニアの皆さん、GPUを使ったプログラミング（CUDA）のパフォーマンスを向上させる新しい技術、「Shared Memory Register Spilling」について解説します。特に、AI/LLMのような計算量の多い処理では、GPUの性能を最大限に引き出すことが重要です。 GPU上で動くプログラム「CUDAカーネル」は、処理に必要なデータを「レジスタ」という高速なメモリに一時的に置きます。しかし、レジスタの数には限りがあるため、データが多すぎると、余ったデータは「ローカルメモリ」（GPUの外にある少し遅いグローバルメモリの一部）に「スピル」（追い出し）されてしまいます。この「レジスタスピル」が頻繁に起こると、プログラムの実行速度が大きく低下してしまう問題がありました。 CUDA Toolkit 13.0で導入された「Shared Memory Register Spilling」は、この問題を解決する新機能です。これまでは遅いローカルメモリにスピルされていたデータを、GPUチップ上にある高速な「Shared Memory」に優先的に格納できるようになります。Shared Memoryはローカルメモリよりもはるかに高速にアクセスできるため、スピルが発生してもプログラムの性能低下を抑え、むしろ向上させることが期待できます。 この最適化によって得られる主なメリットは、データへのアクセス遅延（レイテンシ）の大幅な削減と、GPUのL2キャッシュへの負担軽減です。実際のテストでは、プログラムの種類によっては5～10%の性能向上が確認されています。 この機能を利用するには、CUDA 13.0以降の環境で、CUDAカーネルのコードに以下の1行を追加するだけです。 asm volatile(".pragma \"enable_smem_spilling\";"); ただし、利用にはいくつかの注意点があります。特に重要なのは、__launch_bounds__(スレッド数)のように、カーネルが同時に起動するスレッドの最大数を明示的に指定することです。これを怠ると、Shared Memoryの割り当てが最適でなくなり、かえってGPUの並列処理能力が低下し、パフォーマンスが悪化する可能性があるので注意しましょう。 レジスタをたくさん使うCUDAカーネルの性能改善を目指す方にとって、このShared Memory Register Spillingは非常に有効な手段です。ぜひ、ご自身のCUDAプログラムに適用して、その効果を試してみてください。GPUの計算をより速く、効率的に行えるようになるはずです。 引用元: https://developer.nvidia.com/blog/how-to-improve-cuda-kernel-performance-with-shared-memory-register-spilling/ お便り投稿フォーム

  8. 8월 26일

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

    関連リンク “あの頃”の強かったClaude Codeを少しでも取り戻す方法 この記事では、AIエンジニアの間で「性能が落ちた」と話題のClaude Codeの力を取り戻すための具体的な方法が紹介されています。新人エンジニアの方も、高性能なAIアシスタントを使いこなすためのヒントとしてぜひ読んでみてください。 なぜClaude Codeの性能が落ちたように感じるのか？ 大きな理由として、Claude Codeが長い会話の履歴（コンテキスト）を効率的に処理しようとして、過去に参照したファイルの内容やツールの使用ログを自動的に「要約（Micro Compact）」するようになったことが挙げられます。これは、AIの処理コストを減らすためですが、結果としてAIが以前の情報を忘れ、「健忘症」のような振る舞いを引き起こす可能性があります。また、AIが「何を考えているか」を示す思考プロセスが簡略化され、意図しない挙動に気づきにくくなったことも一因と考えられています。 性能を取り戻すための対策 Micro Compactの無効化: 前述のコンテキスト要約機能（Micro Compact）をDISABLE_MICROCOMPACT=1という環境変数設定で停止し、AIが情報を忘れにくくします。 思考の表示をレガシーに戻す: AIの思考過程が見えやすくなるように、DISABLE_INTERLEAVED_THINKING=1で表示方法を元に戻します。これにより、AIがなぜそのように動いたのかを把握しやすくなります。 IDE（開発環境）との統合を避ける: IDEとClaude Codeの連携によって、不必要な情報がコンテキストに送られるのを防ぎます。具体的には、関連する拡張機能をアンインストールし、CLAUDE_CODE_AUTO_CONNECT_IDE=0などの環境変数設定で連携を停止します。これは利便性とのトレードオフになる可能性があります。 オートアップデート・テレメトリーの停止: DISABLE_AUTOUPDATER=1などで自動更新や利用状況の送信（テレメトリー）を止めます。これにより、予期せぬ機能変更や、不要な通信を防ぐことができます。 これらの設定は、~/.claude/settings.jsonファイルにまとめて記述できます。 Claude Codeのバージョンダウン: 最新の機能は使えなくなりますが、最も確実に以前の性能を取り戻す方法として、npm uninstallとnpm installコマンドで過去の安定バージョン（例: 1.0.24）に戻すことが提案されています。 さらに性能を引き出すテクニック serena MCPの導入：特定のモデル（MCP）を追加することで、AIの振る舞いを改善できる場合があります。 MAX_THINKING_TOKENSの増加：AIがより深く考えるためのトークン数を増やし、推論能力を高めます。 関連ファイルを強制的にコンテキストに含める：@relative/path/to/fileのように指定し、AIに必ず読ませたいファイルを明示的に与えます。これにより、コンテキストの消費は早まりますが、正確性が向上します。 大きなファイルを一度に読ませる：Claudeが長いファイルを少しずつ読む癖があるため、CLAUDE.mdなどで一度に全て読ませるよう指示し、全体像を見失わないようにします。 これらの対策を試すことで、Claude Codeをより効果的に活用し、開発作業の効率アップに繋がるかもしれません。 引用元: https://zenn.dev/discus0434/scraps/e0b1a0aa5406eb Block unsafe prompts targeting your LLM endpoints with Firewall for AI 大規模言語モデル（LLM）を使ったアプリケーションが広がる中で、セキュリティの課題も増えています。悪意あるユーザーがLLMに不正な指示（プロンプトインジェクションなど）をすることで、企業の機密情報が漏れたり、AIが誤った情報を学習したり、有害なコンテンツを生成してしまうリスクがあるのです。これは、大事なAIが意図せず悪い役割を演じてしまうようなものです。 この問題に対応するため、Cloudflare（クラウドフレア）は、AIアプリケーション向けのセキュリティサービス「Firewall for AI」に、新たに「不適切なコンテンツモデレーション」機能を追加しました。この機能は、メタ社が開発した「Llama Guard」というAIモデルを利用し、ユーザーがLLMに送るプロンプトの内容をリアルタイムでチェックします。 主な機能とメリットは以下の通りです。 有害プロンプトのブロック: ヘイトスピーチ、暴力的な表現、性的コンテンツなど、様々な不適切なプロンプトをLLMに到達する前に検出・ブロックします。これにより、AIが不適切な応答をするのを防ぎ、ブランドイメージやユーザーの信頼を守ります。 データ漏洩防止と悪用対策: 個人情報（PII）の開示を防ぎ、プロンプトインジェクションによるLLMの予期せぬ動作を抑制します。 簡単な導入と柔軟な対応: アプリケーションのコード変更やインフラ設定は不要で、Cloudflareのエッジネットワークで設定するだけで利用可能です。OpenAIやGoogle Gemini、自社開発モデルなど、特定のLLMに依存せず、あらゆるLLMに対して一貫したセキュリティポリシーを適用できます。 一元管理: 複数のLLMを運用している場合でも、単一の場所でセキュリティルールを定義し、適用できるため、管理が効率化されます。 かつてマイクロソフトのAIチャットボット「Tay」が不適切な入力によって問題発言を繰り返した事例からも、LLMへの入力段階でのフィルタリングの重要性がわかります。 Cloudflareは、高性能なAIインフラ「Workers AI」上でLlama Guard 3モデルを稼働させ、ユーザー体験を損なわない低遅延でのプロンプト分析を実現しています。管理画面では、検出された不適切なプロンプトに対するログ記録やブロックといったルールを柔軟に設定できます。 将来的には、プロンプトインジェクションやAIの脱獄（ジェイルブレイク）といった高度な攻撃の検出機能、さらにはLLMの応答内容をチェックする機能も追加される予定です。LLMを安全かつ信頼性高く利用していく上で、このようなエッジでのセキュリティ対策は、AIアプリケーションの健全な発展に不可欠な基盤となるでしょう。 引用元: https://blog.cloudflare.com/block-unsafe-llm-prompts-with-firewall-for-ai/ ローカル LLM 環境を構築する この記事では、自分のパソコン（ローカル環境）で大規模言語モデル（LLM）を動かすための環境構築方法が、具体的な手順と共に紹介されています。クラウドサービスに頼らずにLLMを動かすことで、費用を抑えたり、プライバシーを守りながら気軽にLLMを試したりできるのが大きなメリットです。最新のAI技術であるLLMを自分の手で動かし、その可能性を体験したい新人エンジニアの方にとって、実践的なガイドとなるでしょう。 環境構築には主に三つのツールを使います。まず「Docker」は、アプリケーションを「コンテナ」という、他の部分から隔離された小さな箱に入れて動かす技術です。これにより、複雑な環境設定の手間を減らし、どんなパソコンでも同じように安定して動かせるようになります。次に「Ollama」は、ローカルでLLMを実行するための強力なツールで、たくさんのLLMモデルの中から好きなものを選んでダウンロードし、手元のPCで実行できます。そして「Open WebUI」は、Ollamaで動かしているLLMとブラウザを通じてチャット形式でやり取りするための、使いやすい画面（GUI）を提供します。 具体的な手順としては、まずDockerをインストールし、もしNVIDIA製の高性能なグラフィックボード（GPU）を使っているなら、「NVIDIA Container Toolkit」を導入することで、LLMの処理速度を大幅に向上させることができます。次に、docker-compose.ymlという設定ファイルを作成し、Dockerを使ってOllamaとOpen WebUIを同時に起動します。このファイルに書かれた内容を実行するだけで、必要なサービスが一気に立ち上がり、環境が整います。 サービスが起動したら、Ollama経由で「gpt-oss」のような好きなLLMモデルをダウンロードしてインストールします。モデルによってはデータサイズが大きいため、ダウンロードには時間がかかる場合があります。モデルの準備ができたら、Webブラウザで指定されたアドレス（通常はhttp://localhost:3000/）にアクセスし、Open WebUIの画面でアカウントを作成します。これで、まるでChatGPTを使うように、自分のローカル環境で動くLLMに質問を投げかけ、その応答を楽しむことができるようになります。ぜひこの手順を参考に、ローカルLLM環境の構築にチャレンジしてみてください。 引用元: https://qiita.com/kkawaharanet/items/b80d7cde49364aa94963 もともと思考力が高い人は生成AIを使い倒すことができるが、批判

모두 보기(191개)

소개

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

정보