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

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

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

  1. 2日前

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

    youtube版(スライド付き) 関連リンク Introducing Gemini 3.8 Live with Live Avatar Google DeepMindから、リアルタイムの視覚的プレゼンス（アバター）を備えた「Gemini 3.8 Live with Live Avatar」が発表されました。これは、従来のリアルタイム音声対話モデルに、低遅延なストリーミングビデオ生成技術をネイティブに融合させた、新しいマルチモーダルAI技術です。 新人エンジニアの方に向けて、この技術が持つ主要な特徴と技術的なポイントを分かりやすく解説します。 1. リアルタイムで自然な「マルチモーダル」対話 これまでのAIアシスタントは音声やテキストのみのやり取りが主流でしたが、本機能は「話す、聞く、見る、表情を作る」を同時に行います。入力された音声と映像をリアルタイムに処理しながら、正確なリップシンク（唇の動きの同期）や豊かな表情、自然な会話の間（ターンテーキング）を再現し、生身の人間と話しているかのような体験をユーザーに提供します。 2. 非同期ツール実行による「会話を止めない」バックグラウンド処理 エンジニアとして特に注目したい機能が「非同期ツール実行（Asynchronous Tool Calling）」です。 例えば、AIがホテルのチェックイン手続きやデータの取得（ツールの実行）を裏側で行っている間も、画面上のアバターは会話を途切れさせることなくユーザーと対話を続けられます。処理の待ち時間（レイテンシ）が発生しても、ユーザーを退屈させない滑らかなUX（ユーザー体験）をシステム側で簡単に設計できるようになります。 3. 97言語に対応するシームレスな多言語同期 グローバルなサービス展開にも対応しており、97もの言語をサポートしています。会話の途中で突然異なる言語に切り替わっても、映像の品質を落とすことなく、その言語の適切な発音に合わせてリップシンクや表情がシームレスに変化します。 4. 1枚の画像からブランド専用のアバターを作成 多様なプリセットアバターが提供されているだけでなく、開発者は1枚の高品質な参照画像を用意するだけで、そのキャラクターの見た目やブランドの雰囲気を保ったまま、滑らかに動く独自のカスタムアバターを作成できます（※現在はエンタープライズ向けの限定公開）。 5. 安全性を担保する電子透かし「SynthID」 AI生成コンテンツの信頼性を確保するため、セキュリティ面にも配慮されています。生成されるすべての音声および映像出力には、人間の目や耳には感知できない電子透かし「SynthID」が埋め込まれています。これにより、AIが作成したコンテンツであることをシステム的に識別可能にし、なりすましや偽情報の拡散を防ぎます。 まとめ 「Gemini 3.8 Live with Live Avatar」は、裏側の複雑なAPI処理と、フロントエンドのリアルタイムな対話・映像生成を高度に同期させた、まさに「次世代のAIエージェント」を開発するための強力なツールです。Gemini Enterpriseで利用可能となっており、APIドキュメントも公開されているため、未来の対話型アプリケーション開発に向けてぜひチェックしておきたい技術です。 引用元: https://deepmind.google/blog/introducing-gemini-38-live-with-live-avatar/ Automating coherent long-form video generation 近年、動画生成AIは高品質な映像を即座に生成できるようになりました。しかし、それらを組み合わせて「ストーリーに矛盾のない一本の長尺動画」を作ることは依然として困難です。従来の自動生成システムでは、カットを切り替えるたびにキャラクターの服装や背景が微妙に変わってしまう「意味的ドリフト」や、前半の小さな生成エラーが後半の破綻を招く「カスケード失敗」が頻発し、人間による膨大な手作業での修正が必要でした。 Google Researchはこの課題を解決するため、GeminiやVeoなどの高性能なAIモデルを統制し、複数カットにわたる視覚的一貫性を自律的に維持する「マルチエージェント・フレームワーク」を開発しました。本技術は、長尺動画生成を「全体最適化」と「世界状態（キャラクターや環境の設定）の追跡」のシステム開発問題として捉え、以下の4つのコア技術で解決しています。 AI video co-director（協調的な意思決定） 動画全体の方向性を一貫させるため、強化学習の手法である「マルチアームドバンディット（MAB）」アルゴリズムを用いて、新しいストーリー構成の「探索」と、実績のあるクリエイティブ構成の「活用」を最適化します。決定された方針（戦略、構成、映像美）は、絵コンテ・キーフレーム・動画・音声の生成を担当する専門エージェントへ伝達され、最後にマルチモーダルLLMが成果物を評価して次の生成ループにフィードバックします。 CANVAS（ビジュアルの持続的メモリ） 登場人物やシーンの設定情報を構造化して記憶する仕組みです。カメラの視点が別の場所に移動した後に元のシーンに戻るような非連続な場面転換でも、衣服のデザインや空間の立体構造を正確に再現し、ビジュアルのブレを防ぎます。 A²RD（時間ダイナミクスの制御） 数分に及ぶ長尺動画を場面（セグメント）ごとに生成する自己回帰型アーキテクチャです。動画メモリを参照しながら、ストーリーを新しく展開させる「外挿（エクスプロポレーション）」と、既存のデザインを維持する「内挿（インターポレーション）」を動的に切り替えることで、物語の進行と物理的な整合性を両立させます。 VQQA（自動フィードバックによる品質改善） 生成された動画の描画ミス（不要なオブジェクトの混入や設定の矛盾）を自律的に検出し、修正する仕組みです。VLM（視覚言語モデル）が動画に対して自律的に質問を投げ、得られた不備のフィードバック（自然言語）をもとに、テキストプロンプトを自動調整して再生成します。画素を直接いじるのではなく、プロンプトを洗練させる「ブラックボックス最適化」により、自然な修正を実現しています。 成果と展望 本フレームワークは、一貫性を評価する3つの過酷なベンチマーク試験において、従来手法を大きく上回る一貫性を実証しました。この技術は、クリエイターや開発者を「映像の一貫性を保つための泥臭い調整作業」から解放し、本質的なストーリーの創造や演出に集中できる未来をもたらします。 引用元: https://research.google/blog/coherent-long-form-video-generation/ Apple、Qwen3.5-9BベースのLLMモデル「LensVLM-9B」を公開 NEWS Mac OTAKARA Appleは、Hugging Faceにてオープンソースの新しいビジョンと言語を扱うモデル（VLM）「LensVLM-9B」を公開しました。このモデルは、高い性能で知られるオープンモデル「Qwen3.5-9B」をベースに、Appleが特定のタスク向けにファインチューニング（微調整）を施したものです。 本モデルの最大の特徴は、複数ページにわたる「長大な文書」を処理する際、消費するトークン数を劇的に削減する、画期的なアプローチを採用している点にあります。 従来の課題とLensVLM-9Bの解決アプローチ 一般的なLLMで長大なPDFやドキュメントを読み込ませて質問に答えさせようとする場合、すべてのテキストをトークン（AIが処理する文字や単語の最小単位）に変換して入力する必要があります。これには膨大な計算リソースが必要となり、コストの増加や処理速度の低下、さらにはモデルが一度に処理できる制限（コンテキスト窓）を超えてしまうという課題がありました。 LensVLM-9Bは、テキストをそのまま読み込ませるのではなく、ドキュメント全体を「圧縮された画像」として捉えることで、この問題をスマートに解決しています。具体的な処理の流れは以下の通りです。 ページ全体の画像化と圧縮（粗スキャン） 入力された文書の各ページを、約192×252ピクセルという非常に解像度の低いサムネイル画像に変換します。この時の1ページあたりの視覚的な情報（視覚トークン数）は、わずか「約48トークン」にまで圧縮されます。 必要なページの特定とツールの呼び出し モデルはまず、この超軽量なサムネイル画像を使って、ドキュメント全体を俯瞰するようにスキャンします。そして、学習済みの専用ツール「read_page」を呼び出し、ユーザーからの質問に対して「答えが書かれていそうなページ」をピンポイントで特定します。 特定ページのみのテキスト化と回答生成（詳細スキャン） 特定したページの

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

  2. 3日前

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

    youtube版(スライド付き) 関連リンク Introducing GPT-6 Sol and Luna 米OpenAIは、GPT-6ファミリーの新たなラインナップとして、高いコストパフォーマンスを誇る新モデル「GPT-6 Sol」および「GPT-6 Luna」を発表しました。今月上旬に発表された最上位モデル「GPT-6 Astra」の高度な知能と安全性を継承しつつ、推論インフラやキャッシュ技術の改善により、大幅な高速化と低コスト化を実現しています。 本要約では、システム開発に携わるエンジニア（特にAIを活用したサービス開発を学び始めた新人エンジニア）に向けて、これら新モデルの特徴と実務におけるメリットを分かりやすく解説します。 1. API価格の劇的な引き下げ（50%オフ） 新モデルの最大のインパクトは、API利用料金の大幅な引き下げです。前世代モデル（GPT-5.6 Sol / Luna）と比較して、API価格が50%削減されました（価格は100万トークンあたり）。 GPT-6 Sol: 入力 $2 / 出力 $10 GPT-6 Luna: 入力 $0.10 / 出力 $0.50 これにより、予算を抑えながら大規模なAIエージェントを運用したり、日常的な開発タスクを自動化したりすることが現実的になりました。 2. 競合を圧倒するコストパフォーマンスと実務性能 各種ベンチマークにおいて、他社の最上位モデルと同等以上の性能を、圧倒的な低コストで発揮します。 業務自動化（Professional work）: 複数アプリをまたぐビジネスワークフローのテスト（AutomationBench）において、GPT-6 Solは他社の最上位モデル「Claude Opus 5」を上回るスコアを、わずか9%（約11分の1）のコストで達成しました。 事実信頼性（Factuality）: 誤回答（ハルシネーション）を発生させやすいシナリオにおいて、GPT-6 Solの誤り率は前モデルの約半分に減少。最上位Astraに迫る信頼性を低コストで提供します。 コーディング支援: 開発プロセスを自動化するコーディングエージェントの運用には膨大なトークン消費が伴いますが、GPT-6 Sol/Lunaは実用的な開発能力（DeepSWE v1.1）を、競合モデルの最大96%オフという極小のコストで実現します。 PC操作自動化（Computer use）: OS（画面）の自動操作テスト（OSWorld 2.0）でも、SolはClaude Opus 5と同等水準の作業を約80%低いコストで実行可能です。 3. エンジニアに嬉しい「分かりやすい対話スタイル」 技術的な対話において、無駄な専門用語や不要な細かい説明を省き、より明確で簡潔な回答を出力するよう改善されました。要点を外さずに短いテキストで返答するため、開発中の疑問解決やコードレビュー時のコミュニケーション効率が向上します。 4. 開発コストを抑える「プロンプトキャッシュ」の進化 アプリケーションを構築する上で非常に重要な「プロンプトキャッシュ（Prompt Caching）」機能が強化されました。 キャッシュヒット率の向上: 会話の文脈情報（コンテキスト）を再利用する際のヒット率が向上し、キャッシュされた入力トークンは90%割引で高速処理されます。 柔軟な制御: 会話の途中で思考の深さ（Reasoning effort）を変更したり、ツールの有効・無効を切り替えたりしてもキャッシュが途切れなくなりました。また、キャッシュのブレークポイントを明示的に指定できるようになり、開発者がキャッシュの挙動をコントロールできます。 GitHub Copilotではこの改善により、処理が必要なプロンプトトークンが50%以上削減され、応答速度が向上しています。 5. 利用方法 本日より、ChatGPT Plus、Pro、Business、Enterprise、およびEduユーザー向けに、ChatGPT WorkやCodex内で順次展開されます。APIでは gpt-6-sol、gpt-6-luna の識別子で即座に利用可能です。 引用元: https://openai.com/index/introducing-gpt-6-sol-and-luna Gemini 3.8 text-to-speech says hello Googleが発表した最新の音声合成（Text-to-Speech: TTS）モデル「Gemini 3.8 Flash TTS」および「Gemini 3.8 Flash-Lite TTS」について解説します。本モデルは、従来の機械的な音声読み上げの枠を超え、まるで人間のような豊かな感情表現や細やかな「演技指導」を可能にする画期的なAI技術です。 1. 用途に合わせた2つの新モデル 開発者のニーズに合わせて、以下の2つのモデルが提供されています。 Gemini 3.8 Flash TTS: 高度なクリエイティブ表現やキャラクター設計向け。自然言語のプロンプトを使ってゼロから新しい声を生成でき、ゲームのキャラクター、オーディオブック、ポッドキャストの制作に最適です。 Gemini 3.8 Flash-Lite TTS: 大量処理と低コストを両立したスケール向けモデル。Webサービスでの多言語吹き替えや、自動で応答する「対話型音声エージェント」の構築に最適化されています。 2. 驚くほど自由なカスタマイズ機能 これまでは用意されたプリセットから声を選ぶのが主流でしたが、今回のモデルでは無限のバリエーションを作成できます。 プロンプトによる音声作成: 「地域特有の訛りを持つナレーター」といった言葉の指示だけで、100以上の言語に対応したオリジナル音声を生成できます。 ボイスレプリケーション: わずか30秒の音声サンプルから、一貫性のある複製品を生成します。 2,000以上の即戦力ライブラリ: すぐに使える高品質な音声も多数用意されています。 3. 細かな「演技指導」を可能にする演出機能 テキストをただ読み上げるだけでなく、台本（スクリプト）に沿って細部をコントロールできます。 感情と状況の調整: 囁き声など、シーンに応じたトーンを設定でき、長時間の生成でも声の質がブレません。 自然な「相槌」や「感情表現」: 台本に （笑い）や （ため息）などの非言語指示、または |mhm|（ふむふむ）といった相槌を挿入し、人間らしい会話の「間（ま）」を表現できます。 2人による自然な対話: 1つの台本から、2人のキャラクターによる掛け合いをシームレスに生成します。 4. 信頼性と安全性を考慮した設計 高度な音声生成には「なりすまし」のリスクが伴いますが、本モデルは安全対策も徹底しています。 SynthIDによる電子透かし: 生成音声には人間の耳に聞こえない電子透かしが埋め込まれ、AI生成物であることを後から検出可能です。 音声複製の同意確認: 声を複製する際は、本人による音声同意確認を求める厳格なガードレールが設けられています。 5. 開発者が今すぐ始めるには 開発者は、Webツール「Google AI Studio」の音声生成プレイグラウンドで、プロンプトによる音声設計や2人対話の編集をすぐに試せます。また、Gemini APIを利用して、Agora、LiveKit、Vercelなどの外部ツールと連携し、独自の音声インターフェースを簡単にサービスへデプロイ可能です。 インタラクティブなAIアプリケーションや、表現豊かな音声機能を開発したいエンジニアにとって、今チェックすべき強力な最新技術です。 引用元: https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-8-text-to-speech/ Mixture of Experts 基礎技術メモ 近年、DeepSeekやKimiなどの最先端LLMで標準的に採用されている技術「Mixture of Experts（MoE）」の基礎知識と、最新の発展形について分かりやすく解説します。 1. MoEの直感的な理解と導入の動機 MoEは、モデルのパラメータ数を増やして賢くしつつも、実質的な計算コスト（推論時の処理負荷）を低く抑えるためのアーキテクチャです。 よくある誤解として「数学担当、英語担当のように専門分野ごとにネットワークが綺麗に分かれている」と思われがちですが、実際には「トークン（文字や単語の単位）ごとに、処理を担当するサブコンポーネント（エキスパート）が動的に切り替わる構造（スパースな活性化）」を指します。 2. MoEの構造とルーティングの仕組み 通常のTransformerモデルにおける「FFN（Feed Forward Network）」という全結合層を、複数の「エキスパート」と呼ばれるネットワークに置き換えます。 入力されたトークンをどのエキスパートに送るかは「ルーター」が判定します。現在主流の方式は「Token choice」で、各トークンが自身に最適な上位K個（Top-K）のエキスパートを選択して処理を割り振ります。 3. ルーティングの大きな壁：「エキスパート崩壊」 学習の初期段階ではルーターの割り振りがランダムなため、偶然特定のエキスパートに処理が集中することがあります。すると、そのエキスパートだけが学習を進めてより賢くなり、さらにトークンが集まるという「正のフィードバック」が働き、他のエキスパートが全く使われなくなる「エキスパー

  3. 9月17日

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

    youtube版(スライド付き) 関連リンク Introducing Astra for Law 米OpenAI社は、最新のフラグシップAIモデル「GPT-6 Astra」をベースに、法律事務所やリーガルテック企業向けに最適化された新しい基盤ソリューション「Astra for Law」を発表しました。法律実務に必要な専門設定、データ、ツールを統合しており、API（モデル名: gpt-6-astra-law）などを介して高度な法律ワークフローを構築できます。 以下に、日本のエンジニアに向けて、技術的な要点とアーキテクチャの魅力を分かりやすく解説します。 1. ドメイン特化型検索インデックスによる高度なRAG Astra for Lawの最大の特徴は、2億3000万以上のURLに及ぶ米国の判例、法令、裁判所規則などのデータを網羅した「法的検索インデックス」を標準搭載している点です。 信頼性の高い一次ソースへ直接アクセスして推論を行うため、ハルシネーション（嘘の出力）を抑えた正確な回答が可能です。業界標準ベンチマーク「Vals AI’s Legal Research Bench」の評価では、通常のGPT-6 AstraによるWeb検索（正解率38.7%）に対し、Astra for Lawは「54.0%」の正解率を記録し、約40%もの性能向上を達成しました。判例の網羅性や、適切な引用箇所の抽出能力も大幅に向上しています。 2. リーガルグレードのセキュリティとデータガバナンス 極めて厳格な機密保持が求められる法務分野に対応するため、セキュリティ設計が徹底されています。「Trusted Access Program」では、API利用時における「Zero Data Retention (ZDR: データ不保持)」が保証されます。さらに、ChatGPT Enterprise利用時のデータは、OpenAI側での人間によるレビュー対象からデフォルトで除外されます。倫理的な障壁（Ethical Walls）やアクセス権限の制御など、エンタープライズ開発で必須となるセキュリティ要件を高いレベルでクリアしています。 3. 独自ナレッジの統合とカスタム開発 法律事務所が持つ独自の過去データ、交渉用のプレイブック、ノウハウをChatGPT EnterpriseやAPIに統合し、自社専用のAIツールを開発できます。 すでに先行事例として、契約書からリスクを検知して自動で修正案を作成するシステムや、M&Aにおけるデューデリジェンス（企業調査）を支援するシステムなどが共同開発されています。 4. 既存ツールと繋がる豊富なエコシステム iManageやClioといった法務専用ツールと連携する「26種類のパートナープラグイン」が提供されます。また、法律実務で必須となるMicrosoft Word上で直接動作する「ChatGPT for Word」もリリースされ、ユーザーの既存ワークフローを邪魔しない優れたUXが設計されています。 まとめ：新人エンジニアに向けた学びのポイント Astra for Lawは、汎用LLM（GPT-6 Astra）に「専門ドメインのRAG」「厳格なデータプライバシー設計」「外部ツールとのシームレスなAPI連携」を組み合わせることで、専門業務に耐えうるシステムへと昇華させた素晴らしい実例です。最先端AIを特定業界（ドメイン）に適応させるための設計パターンとして、非常に学びの多いアーキテクチャと言えます。 引用元: https://openai.com/index/astra-for-law Migrating the GitHub Copilot runtime to Rust, using Copilot GitHub Copilotの中核である「エージェントランタイム」を、従来のTypeScript（Node.js/V8）からRustへ完全に書き換えた事例を紹介します。本プロジェクトは、Copilot自身（AIエージェント）を駆使し、実質的に1人の開発者がわずか数ヶ月で完了させました。チームで1〜2年は要する規模の移行を、安全かつ劇的に高速化させたアプローチと教訓は、新人エンジニアにとって非常に有益です。 1. なぜRustへ移行したのか？ 元のTypeScript版は、他言語（C#、Go、Pythonなど）のアプリから利用する際、不要なNode.js環境の起動や、約100MB以上のメモリ消費、プロセス間通信の発生がボトルネックでした。 これを解決するため、依存関係を極小化し、他言語から「C ABI（C言語互換のインターフェース規格）」を介して直接同一プロセス内で軽量・高速に実行できる（インプロセス化）言語として、Rustが選定されました。 2. 開発を止めない「インプレース移行戦略」 一度に全てを差し替えるのではなく、コンポーネント単位で段階的に移植する「インプレース方式」を採用しました。 段階的な統合: napi-rsを使い、一時的にTypeScriptとRustが通信できる仕組みを構築。コンポーネントを1つRust化するたびに古いコードを順次削除しました。 常にリリース可能: この手法により、移行期間中もmainブランチは常に正常動作し、本番リリースを止めずに合計135回のアップデートを安全にユーザーへ届けました。 3. AIエージェントの生産性とコスト AIは128件のプルリクエストを通じて、約83万行のRustコードを記述しました。 APIトークン費用は約12万ドル（約1,800万円）でしたが、過去の文脈を再利用する「プロンプトキャッシュ」のヒット率を96.22%に維持したため、費用を劇的に抑えられました。開発者自身の稼働時間は、並行作業を含めて実質3週間程度でした。 4. 移行から得られたエンジニアリングの教訓 「コンパイルが通れば正しい」は迷信: Rustの厳格なコンパイラは型不一致などの単純なミスを即座に検知しましたが、型解釈のズレ（整数であるべきIDを実数f64でシリアライズしてしまい、受信側でパースエラーになる等）による仕様上のバグはすり抜けました。 E2E（エンドツーエンド）テストこそが命: 動作の正しさを最終的に担保したのは、コードの挙動を外側からテストするE2Eテストでした。AIエージェントが自ら都合よくテストコードを書き換えないよう「保護する」ことが極めて重要です。 まず愚直に翻訳し、設計変更は後にする: 移植と「最適化・リファクタリング」を同時に行うと、バグ発生時の原因特定が極めて難しくなります。 5. 移行がもたらした劇的な成果 処理速度: 起動・接続・1往復の処理時間が5.25秒から292ミリ秒へと18倍高速化。 メモリ削減: 同時10クライアント実行時のメモリ消費が、1,383MBから126MBへ91%削減。 結論 開発者の役割は、コードを自分で書く作業から「問題の定義、設計の境界、テストによるガードレールの設置、成果のレビュー」という高レベルな意思決定へとシフトしました。これからのAI協働時代を生きるエンジニアにとって、本質を示す道標となる事例です。 引用元: https://github.blog/ai-and-ml/generative-ai/migrating-the-github-copilot-runtime-to-rust-using-copilot/ TypeSafeのJevを正しく驚く、それってLLMでできませんか？ 近年注目を集めるTypeSafe AIの「Jev」は、一般的なLLMのように文章を生成するのではなく、ソフトウェアが直接利用できる「判断」と「確率」を高速に返す特化型モデルです。本記事では、「Jevの機能は既存のLLMでも再現できるのではないか？」という疑問を出発点に、具体的な検証を通じてJevの真の実力と技術的な位置づけを解説しています。 まず、Jevの強みである「高速なJSON出力」についてです。通常、LLMにJSONを出力させると、1トークンずつ順番に文字を生成（自己回帰生成）するため時間がかかります。しかし、回答の選択肢（例：true/false、承認/却下など）が予め決まっている場合、必ずしもすべての文字列を生成させる必要はありません。 賢い代替案として、「回答候補に対応する最初の1トークンの出力確率（logit）」だけをモデルから取得し、最終的なJSONはプログラム側で組み立てる手法があります。さらに、共通のプロンプト部分を「KV Cache（過去の計算結果のキャッシュ）」で再利用しつつ、複数の質問をバッチ推論で同時に処理すれば、出力待ち時間を劇的に削減できます。実際に軽量モデル「Gemma3 270M」を用いてこの手法を検証したところ、通常のJSON出力に比べて77倍という圧倒的な高速化を達成しました。 次に、リアルタイム性が求められる「ゲーム（マリオ）のプレイ」での検証です。Jevは100ms前後という短い時間で判断を下せるため、ゲームのリアルタイム制御が可能です。検証の結果、Jevは比較対象のLLMよりも優れたプレイ結果を残しました。 ただし、これには技術的な前提条件があります。前述の「1トークン目の確率（logit）を見る」手法を実行するには、API経由でlogitを取得できるモデルが必要です。現在主流の高性能な「推論モデル」の多くはAPIでlogitを取得できないため、今回の比較対象は一世代前の「非推論モデル」に限定されました

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

  4. 9月16日

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

    youtube版(スライド付き) 関連リンク Claude Codeで開発期間を2.5か月から1か月に縮めた「ハーネス」の設計手法 本書は、SmartHRのプロダクトエンジニアがAIコーディングツール「Claude Code」を駆使し、新規機能の開発期間を当初の見積もりである2.5か月から1か月にまで短縮した実践的な設計手法「ハーネス」について解説したものです。AIを開発パートナーとして迎えるにあたり、手戻りを防ぎつつ成果を最大化するための具体的なアプローチが、新人エンジニアにも分かりやすく解説されています。 1. ハーネスが必要とされた背景 大規模な開発でAIエージェントをそのまま使い続けると、会話履歴の蓄積によって「コンテキスト（AIが一度に記憶・処理できる情報量）の枯渇」や「APIコストの急増」が発生します。また、既存システムへ悪影響（デグレ）を与えるリスクや、仕様の認識違いによる終盤での手戻りも大きな課題でした。これらを防ぐため、AIの作業環境をあらかじめ定義し、制御する仕組みとして「ハーネス（手順、状態JSON、完了判定スクリプトの3点セット）」が構築されました。 2. 協調動作を実現する4つの登場人物 ハーネス内では、役割を明確に分担させることでノイズとコンテキストの肥大化を防いでいます。 オーケストレータ（メインセッション）: 進行役。フェーズの遷移や全体管理を行い、自身では実装コードを書きません。 実装エージェント: 細分化した1タスクごとに都度「新規セッション」として起動し、実装とコミットを行います。タスクごとにセッションをリセットすることで、過去の不要な履歴を引きずらず、常に高い精度を維持します。 レビュアー: 「仕様突合」「並行性」「認可」「完結性」の4つの異なる観点を持つAI。タスクごとではなく、全タスク完了後に1回だけ並列起動させることで、無駄なトークン消費を抑えつつ、タスクをまたぐ欠陥を検出します。 機械検査（シェルスクリプト）: AIモデルを使わず、テストがgreen（成功）か、許可されたファイルパス以外の変更がないかなど、12項目を機械的に厳密に判定します。AIの自己申告に頼らない客観的なデグレ防止柵です。 3. 開発を成功に導く具体的な工夫 テスト駆動開発（TDD）のルール化: 実装エージェントにはTDDを強制します。「テストを成功させる」という曖昧さのないゴールを提示することで、存在しない関数を作るなどのハルシネーション（AIの嘘）を即座にエラーで弾き、AI自身の自律的な修正を促します。 仕様（spec）と規律（rules）の分離: 作るべき機能を書いた「仕様ドキュメント」と、守るべき「規律（開発ルール）」を分けます。規律ファイルには適用範囲（パス）を指定することで、関係ないファイルを触るセッションには規律が読み込まれないようにし、コンテキスト量を節約します。 状態の外部化: 進行状況は軽量なJSONファイルに保存し、セッション切り替え時の引き継ぎに用います。確定した仕様はドキュメント側へ随時書き戻し、JSONファイルを肥大化させない工夫が施されています。 4. まとめ AIエージェントを用いた開発において重要なのは、「AIモデルの優秀さ」に依存するのではなく、「AIが迷わず、安全に働ける周辺環境（ハーネス）をいかに設計するか」です。タスクを極小化し、セッションをクリーンに保ち、テストとスクリプトで品質を担保するこの手法は、これからのAI共同開発における強力な指針となります。 引用元: https://tech.smarthr.jp/entry/2026/09/16/110205 障害対応で Claude Code に調査を任せてみたら便利だった話 本書は、本番環境のデータベース（Aurora PostgreSQL）で発生した障害において、AIエージェントツール「Claude Code」を原因調査やインシデントレポート作成に導入し、対応を大幅に効率化した実体験を紹介する記事です。新人エンジニアにとっても、AIを「実務のアシスタント」としてインフラ運用にどう組み込むべきか、非常に学びの多い実践例となっています。 1. インシデントの状況 本番環境のDBで、writerインスタンスの内部プロセスが異常終了するインシデントが発生しました。自動フェイルオーバーでDB自体は即時復旧したものの、実行中だったバッチ処理が中断し、ロックを握ったままの状態になったため、手動での解除対応が必要になりました。 2. Claude Codeによる「超高速」な状況把握 通常、障害発生時はAWSの管理画面にログインし、手動でログやメトリクスを確認します。しかし今回は、Claude Codeに「再起動があったようなので状況を把握できますか」とだけ指示しました。具体的なクラスタ名や時刻を伝えなかったにもかかわらず、Claude Codeは自律的に以下のAWS CLIコマンドを組み合わせて調査を行いました。 aws rds describe-db-clusters や describe-events（構成・履歴確認） aws cloudtrail lookup-events（人為的操作の有無の確認） aws cloudwatch get-metric-statistics（CPUや接続数の調査） これにより、調査開始からわずか10〜15分で状況を把握し、Slackに共有できました。さらに、原因特定の決め手となる「FATAL: Aurora Runtime process unexpectedly exited」というエラーログも自動で見つけ出しました。 3. タイムラインとレポート作成の自動化 インシデント後に作成する「レポート」において、AWSのシステムログとSlack上の「人間の動き」を時系列に突き合わせる作業は時間と手間がかかります。 著者は、SlackのURLとレポート用テンプレートをClaude Codeに提示。Claude CodeはSlack MCP（外部ツール連携機能）経由でチャンネル履歴を取得し、AWSのイベント履歴と突き合わせて、秒単位の正確なタイムラインを自動生成しました。さらに、エラー内容を元にAWSドキュメントを検索し、「アプリの負荷ではなくAWS基盤側の問題である」という結論や、今後の監視改善の提案まで作成しました。 4. 安全面への配慮 AIにインフラ操作を任せるにあたり、誤操作を防ぐ権限管理が重要です。今回は「Read Only（参照専用）」のIAM権限を利用し、本番環境に破壊的変更が起きないよう安全性を担保しました。 5. まとめ 「情報の収集・整理はAIに任せ、判断や個別対応（アプリ側の影響特定、ロック解除、顧客連絡など）は人間が行う」という役割分担が極めて有効です。新人エンジニアの皆さんも、コマンドの検索やドキュメント作成をAIにサポートしてもらうことで、本質的な問題解決やシステム理解に集中し、より素早く成長できる環境を作ることができます。 引用元: https://developer.feedforce.jp/entry/2026/09/15/122838 Claude Code Routinesを用いてIssueを自動で解消する仕組みを展開した話 本記事は、株式会社ラクスの若手バックエンドエンジニアが、AIコーディングアシスタント「Claude Code」を用いて、GitHub上の不具合や改善要望（Issue）の調査からプルリクエスト（PR）の作成までを半自動化する仕組みを構築し、チームへ導入した実践事例を紹介しています。 ■ 構築した自動解消フローの全貌 定型的なタスクを自動実行できるClaude Codeの機能「Routines（ルーティン）」を活用し、以下のプロセスを構築しました。 【コード調査】：人間が不具合のIssueを起票して調査依頼ラベルを貼ると、AIがコードベースを自動で調査します。AIは修正方針や実装にあたって確認したい事項をIssueのコメントに書き残します。 【人間の確認（Human in the Loop）】：開発者がAIの提案をレビューし、方針が良ければGOサインを、修正が必要ならフィードバックを返信して、実装依頼ラベルを付与します。 【実装とPR作成】：AIが回答を基にコードを修正し、自身のセルフレビューとテスト項目の作成を行います。その後、修正内容やテスト項目を記載したDraft PRを自動で作成します。 【最終検証】：人間がローカル環境にブランチを取り込んで動作確認を行い、マージします。 ■ この仕組みがもたらす5つのメリット 人間の時間外にAIを働かせる：夜間にAIが調査を進めておくことで、翌朝人間は回答するだけでよくなり、日中の並行作業を効率化できます。 履歴の可視化：Issue上に調査結果や修正方針の決定プロセスがすべて残るため、後からいつでも振り返ることができます。 ローカル環境が汚れない：すべての処理はクラウド（サンドボックス）環境で行われるため、ローカルPCに不要な変更が入りません。 再現性のある挙動：個人のPC環

  5. 9月15日

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

    youtube版(スライド付き) 関連リンク Introducing Gemini 3.8 Live and 3.8 Live Extended Thinking Googleは2026年9月15日、リアルタイムの音声対話に特化した最新のAIモデル「Gemini 3.8 Live」および「Gemini 3.8 Live Extended Thinking」を発表しました。これらのモデルは、開発者が実用に耐える高度な音声エージェント（ボイスAI）を迅速に構築できるように設計されています。 1. 2つの新しいモデルとその特徴 用途に合わせて以下の2つのモデルが提供されます。 Gemini 3.8 Live（スケール・コスト重視） コスト効率とスケーラビリティ（拡張性）に優れたモデルです。日常的な会話知能に加え、スムーズな対話応答、さらにカメラなどを通じたリアルタイムの「視覚入力（Visual Grounding）」の処理を両立しています。 Gemini 3.8 Live Extended Thinking（複雑な思考・推論重視） 高度なタスク実行に向けたモデルです。対話を行いながら同時に「並行してマルチステップの思考（推論）」を行う能力を備えており、より複雑な業務プロセスの自動化に適しています。 2. 新人エンジニアが押さえるべき、進化した技術的注目ポイント これまでの音声AIと異なり、より「人間らしく、実用的なシステム連携」ができる点が特徴です。具体的には以下の技術が組み込まれています。 割り込みや「つなぎ言葉」によるスムーズな対話： バックグラウンドで重い処理を行う際、モデルは「ちょっと確認しますね」といった自発的なつなぎ言葉（Early Verbal Cues）を挟んだり、現在の進捗を音声で実況（Live Progress Narration）したりします。これにより、ユーザーを不安にさせる「沈黙」を防ぎます。 対話中のツール連携（Tool Calling）： ユーザーと会話を継続しながら、裏側でAPIを実行したりシステムツールを動かしたりできます。処理が終わるのを待つ間も、会話が途切れることはありません。 97言語の自動検知と移行： 会話の途中で言語が英語から日本語、あるいは別の言語へと切り替わっても、システムが自動でそれを検知してシームレスに応答を続けます。 音声品質のベンチマークでトップを記録： 音声対話の品質を評価する外部ベンチマーク（Speech to Speech Quality Index）で首位を獲得しており、既存の競合モデルと比較しても圧倒的な応答品質とコストパフォーマンスを証明しています。 3. 開発者コミュニティへの影響とエコシステム 新人エンジニアにとって特に嬉しいのは、開発のハードルを下げるエコシステムの存在です。 音声ストリーミングやリアルタイム通信の低レイテンシ制御は、インフラ設計において非常に難易度が高い領域です。しかし、今回の発表に合わせて「Agora」「LangChain」「LiveKit」「Vercel」といった主要な開発プラットフォームやSDKが「Gemini Live API」への対応を表明しました。 これにより、インフラ層の複雑なリアルタイム配信処理はこれらのプラットフォームに任せ、アプリケーション開発者は「どのような体験をユーザーに提供するか」というUXやロジックの設計に集中することができます。 4. 安全性への配慮：SynthID 生成されたすべての音声には、人間の耳には知覚できない電子透かし「SynthID」が直接埋め込まれます。これにより、AIによる偽音声の悪用を防ぎ、安全なプロダクト運用を支援します。 5. 提供開始時期 両モデルは発表日当日（2026年9月15日）より提供が開始されています。開発者は「Gemini API」およびブラウザ上で手軽にテストできる「Google AI Studio」からすぐに触り始めることができます。音声エージェントの開発に挑戦したいエンジニアは、まずAI Studioでそのリアルタイムな挙動を体験してみることをおすすめします。 引用元: https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-8-live-gemini-3-8-live-extended-thinking/ Introducing System One Models and Jev - TypeSafe AI Blog OpenAIでChatGPTの基礎研究に携わったDiogo Almeida氏が立ち上げたTypeSafe AI社は、ソフトウェアの自動化に特化した新しいAIモデル「Jev」と、それを支える「System One Model」という新たなアーキテクチャを発表しました。 従来のLLM（大規模言語モデル）は、人間のようなチャットや文章生成といった、遅く論理的に思考する「システム2」的な処理には非常に優秀です。しかし、これらは「1トークン（文字の塊）ずつ順番に出力する」という仕組みであるため、応答に数秒から数分かかり、システムへの組み込みにおいて大きなボトルネックとなっていました。また、存在しない情報を事実のように出力する「ハルシネーション（嘘）」や、プログラムが処理できない不適切なデータ形式を出力する「型エラー」が発生するリスクがあり、100%の信頼性が求められるソフトウェアの自動化プロセスには不向きでした。 こうした課題を解決するために開発されたのが「Jev」です。JevはこれまでのLLMとは異なり、思い切って「自由な文字列（テキスト）の生成」を諦め、プログラムが直接扱える「構造化データ（型安全な値）」の出力に特化しています。 Jevの主な特徴は以下の4点です。 圧倒的な高速化と低コスト 従来のLLMが1文字ずつ生成するのに対し、Jevは「並列サンプリング」という新技術を用いて、1回のクエリで必要なすべての出力を同時に生成します。これにより、応答時間は「70ms〜500ms」と、従来の約40倍〜200倍の超高速化を実現しました。さらに出力にかかるコストは実質無料（FREE）となっています。 ハルシネーションと型エラーの完全な排除 出力されるデータの構造（スキーマ）を事前に定義しておく設計のため、型エラーが理論上発生しません。これにより、システム開発において「AIの出力フォーマットが崩れてエラーになる」という心配が完全になくなります。 信頼度の可視化（キャリブレーション） Jevは、すべての出力に対して「どれくらい自信があるか」の確率（信頼度）を同時に返します。これは新開発の学習手法「RLCD（意思決定のための強化学習）」によって実現されており、プログラム側で「信頼度が90%以上なら自動実行、それ未満なら人間に確認を促す」といった確実な制御が可能になります。 豊富なユースケース Jevは、プログラム内の複雑な「if文（条件分岐）」の代わりとして機能します。例えば、大量のデータの分類・ルーティングや、リアルタイムな処理、他のLLMの出力が安全かどうかの検証（ガードレール）などに最適です。デモでは、高速な判断が求められるゲーム「Doom」のリアルタイム操作や、ハルシネーションのない選択が求められる「Wikipediaのリンク遷移ゲーム（Wikiracing）」での活用が示されています。 Jevという名前は、石炭の利用効率向上によって逆に需要が爆発的に増加した現象（ジェボンズのパラドックス）に由来しています。自由なテキスト生成をあきらめることで、ソフトウェアが本当に必要とする「超高速・高信頼・価格破壊」な意思決定の自動化を実現した、画期的な新世代のAIモデルです。 引用元: https://typesafe.ai/blog/introducing-system-one-models-and-jev AIエージェントの自己改善をどう設計するか / How to Design Self-Improvement for AI Agents AI技術の発展に伴い、人間が手作業で行っていたシステム構築や改善を「AIエージェント（特定の目的を持って自律的に動くAIシステム）」自身に実行させる「自己改善ループ」の試みが進んでいます。しかし、AIエージェントを単純に自律動作させるだけでは、ある段階で精度向上が頭打ちになるという課題に直面します。本資料は、この「自己改善の停滞」の原因を紐解き、深層学習の仕組みをヒントにした、持続可能で強力なAIエージェントの自己改善システム（ハーネス）の設計論をわかりやすく解説しています。 1. なぜAIエージェントの自己改善は「停滞」するのか？ 人間がチューニングすれば精度98〜99%に達するタスクであっても、AIエージェントに自己改善を任せると、精度90%程度で改善が止まってしまう現象が起きます。 この時、AIエージェントが出す改善策は「プロンプトに個別条件を1行追加する」「出力結果をプログラムで部分置換する」といった微修正にとどまります。「そもそも全体の処理順を変えるべきでは？」「LLMで処理するのではなく、確定的なプログラムに置き換えるべきでは？」といった、最初の設計（前提）を疑うような抜本的な改善

  6. 9月14日

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

    youtube版(スライド付き) 関連リンク Apples Siri AI Can Be Swapped Out for Claude, ChatGPT, Code Shows Appleの次期OSである「iOS 27」および「macOS Golden Gate」の内部コード（プライベートフレームワーク）から、音声アシスタント「Siri」の裏側で動くAIモデルを、ChatGPTやClaudeといったサードパーティ製の外部LLM（大規模言語モデル）に深く統合・差し替えられる仕組みが実装されていることが、開発者の解析によって明らかになりました。 この統合は非常に高度なレベルで設計されており、主に以下の2つのアプローチ（プロトコル）が確認されています。 1. 部分的なタスクの委譲：「Model Delegation（モデルデリゲーション）」 これは、特定の質問や高度な処理を、外部AIへ「拡張機能（Extension）」として委譲する仕組みです。 例えば、ユーザーがSiriに「Claudeに頼んでリマインダーを設定して」と指示すると、Claudeがその自然言語の意図（インテント）を解釈します。タスクの実行自体はSiri（OS側）に差し戻され、Siriが標準の「リマインダー」アプリを操作して登録を完了させます。また、従来のSiriでは単体で処理できなかった「CSVファイルの作成」といった複雑なタスクを、Siriのチャット画面内でClaudeが肩代わりして実行し、結果を返すことも可能になります。 2. コアエンジンの完全な置き換え：「Model Manager Services（モデルマネージャーサービス）」 もう一つは、Siriのサーバー側モデルそのものを、GPT-5.6といった外部の高性能モデルへ完全に置き換える、より強力な仕組みです。 このシナリオでは、外部LLMがAppleの「Siriプランナー」のプロンプトや、OSを操作するための「ツール定義」を直接受け取ります。これにより、外部LLMはデバイス内の個人データ（連絡先やメールなど）にアクセスし、システムアクション（メールの検索・要約、メッセージアプリでの送信など）の実行計画を組み立てて命令を下すことができます。最終的な回答は、Siri自身のUIと合成音声を用いて、ユーザーへシームレスに提示されます。 ■ 新人エンジニアに向けた技術的な解説と背景 この機能が生まれた背景には、欧州連合（EU）の「デジタル市場法（DMA）」の存在があります。この法律は、Appleに対してiOSの基盤機能をサードパーティに公平に開放することを義務付けており、Siriもその対象となっています。 技術的な観点で見ると、この仕組みは「OSと外部LLMの高度な連携アーキテクチャ」の素晴らしい実例です。 一般的なアプリ開発におけるAPI連携（テキストの送受信）にとどまらず、OS側が「プランナープロンプト」や「ツール定義（いわゆるFunction Callingの枠組み）」を外部LLMへ動的に提供し、安全にデバイス操作を行わせるという設計は、これからのAIエージェント開発において非常に参考になるパターンです。 現時点ではこれらの機能は開発中であり、一般ユーザーやサードパーティ開発者向けに広く開放されているわけではありません。しかし、Appleが将来的な「マルチモデルの相互運用性」を前提にOSの再設計を進めていることを示す、非常にエキサイティングな最新動向です。 引用元: https://www.macrumors.com/2026/09/14/siri-can-be-swapped-out-for-chatgpt-claude/ AIエージェントの評価と品質保証 — 「動く」を「信頼できる」に変える検収の技術 近年、生成AIやAIエージェント（LLMを活用して自律的にタスクを実行するシステム）を実務に導入する動きが活発化しています。しかし、AIの出力は確率的に変動するため、「1回動いたから大丈夫」というこれまでのソフトウェアテストの常識が通用しません。本書は、AIエージェントが作成したコードや成果物を、何を根拠に受け入れ（検収）し、改善し、モデルやプロンプトを更新すべきかという「品質保証（QA）」の技術を体系的にまとめた実践書です。 本書が提示する、AIエージェントを「信頼できる」システムに変えるためのキーコンセプトは以下の4点に集約されます。 依頼を「評価可能な条件」にし、データセットを育てる AIに対する曖昧な指示のままでは、成果物が正しいかを客観的に評価できません。まずは満たすべき要件を明確な「契約（コントラクト）」として定義します。その上で、AIの挙動を検証するためのテストケース（評価データセット）を整備し、継続的に拡充していくことが重要です。 「コードによる判定」と「LLMによる評価」のハイブリッド 評価の手法には、プログラムで機械的に判定する「コード評価」と、LLM自体に成否を判定させる「LLM評価」の2つがあります。 コード評価: 実行スピードが速く、結果がブレないため、極力この自動テストの範囲を増やすことが基本です。 LLM評価: 表現の揺らぎやデザイン、複雑な文章のニュアンスなど、コードでの自動判定が難しい定性的な部分に適用します。ただし、評価を行うLLM（評価器）自体の信頼性も検証する必要があります。 「1回の成功」から「繰り返せる成功」へ（複数試行と継続評価） AIエージェントは同じ入力に対しても、時によって異なる動きをします。そのため、評価は1回だけでなく、複数回（例えば1つの課題に対して6回など）試行して合格率（成功率）を算出します。さらに、使用するLLMのモデル変更やプロンプトの調整を行った際に、過去にできていたことができなくなる「デグレ（品質低下）」を防ぐため、CI/CDなどの仕組みを用いて継続的に自動評価を行うパイプラインの構築を推奨しています。 評価パイプラインの構築と検収の実践 本書では、これら一連のプロセス（評価、複数試行、LLM評価、デグレ検証）をTypeScriptで実装した共通のアプリケーションを通じて学びます。実際のコード例やテンプレート、実行記録が豊富に用意されており、評価パイプラインを一本の動くシステムとして体感できるよう設計されています。 新人エンジニアへのメッセージ AIを用いた開発では、「AIが作ったからブラックボックスでテストできない」と諦めるのではなく、「実測できている範囲」と「未検証の範囲」を明確に切り分ける姿勢が重要になります。本書を通じて、不確実性の高いAI出力をコントロールし、本番に耐えうる品質を保証するための「一歩進んだテストエンジニアリング」の手法を身につけることができます。これからAIを活用したプロダクト開発に関わるすべての人にとって、非常に心強い道標となる一冊です。 引用元: https://zenn.dev/hampen2929/books/ai-agent-evaluation-guide Nari Labs Leads Coval’s Voice AI Benchmarks 本記事は、Nari Labsが開発した音声AIモデルが、業界の主要な評価プラットフォーム「Coval」のベンチマークにおいて、処理速度（レイテンシ）、認識・合成の正確性、そしてコスト効率のすべてで世界トップクラスの性能（パレートフロンティア）を達成したことを報告するものです。 音声対話AIの開発において、応答の速さと正確性はユーザー体験を決定づける最重要ファクターです。本要約では、新人エンジニアの方にも理解しやすいよう、評価指標の解説を交えながら具体的な成果を説明します。 1. 音声AIを評価する重要指標 音声対話システムを評価する際、本ベンチマークでは以下の指標が重視されます。 TTFS (Time-to-Final-Segment): 音声認識（STT）で、ユーザーが話し終えてから最終的なテキストが出力されるまでの遅延時間。 TTFA (Time-to-First-Audio): 音声合成（TTS）で、テキストが入力されてから最初の音が出力されるまでの遅延時間。 WER (Word Error Rate): 単語誤り率。値が低いほど、テキスト化や音声出力が正確であることを示します。 2. 音声認識（STT）における成果 Nari Labsの「Qwen3-ASR Fast」モデルは、音声認識（STT）において驚異的な成果を収めました。 速度（TTFS）: 中央値 44ミリ秒（ms） で、すべての公開モデルの中で 第1位。 正確性（WER）: 3.6% を記録し、トップのAssemblyAI（3.5%）に迫る 第2位。 コストパフォーマンス: 利用料金は 1時間あたり0.12ドル。これは競合のAssemblyAI（約3.75倍高価）やDeepgram Nova 3（約2.4倍高価）と比較して圧倒的に安価です。さらに安価なStandardプラン（1時間あたり0.06ドル）も用意されています。 3. 音声合成（TTS）における成果 音声合成（TTS）の「Qwen3-TTS Fast」モデルでも、業界最高水準の性能を実証しました。 正確性（WER）: 3.8% を記録し

  7. 9月13日

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

    youtube版(スライド付き) 関連リンク Perplexity trusts GPT-6 Astra with end-to-end systems 本記事は、AIを活用した対話型検索エンジンを提供するスタートアップ企業「Perplexity（パープレキシティ）」が、OpenAIの最新モデル「GPT-6 Astra」を開発・運用プロセスに導入した事例を紹介しています。同社の共同創業者兼最高戦略責任者（CSO）であるジョニー・ホー（Johnny Ho）氏の視点を通じ、最新のAIモデルがシステム開発の現場、特に本番環境の運用や品質管理（テスト）において、どのように信頼され、活用されているのかが具体的に描かれています。 新人エンジニアの皆さんにとって、AIによるコーディング支援は身近な存在になりつつあるかと思いますが、本事例ではそれをさらに一歩進め、システム全体の運用やテストを「自律的にAIに任せる」レベルに達している点が大きな特徴です。 具体的な要点は以下の3点に集約されます。 1. コード生成能力の向上がもたらす、コア機能の進化 Perplexityは、膨大な情報を処理して正確な回答を返す検索エンジンを開発しています。ホー氏によると、AIモデルの「コードを記述する能力」が向上するたびに、Perplexityの検索エンジン自体の性能も向上するという相乗効果があります。モデルがより優れたプログラムを自ら書けるようになることで、Webや社内情報をより効率的に探索し、ユーザーに対して非常に簡潔かつ正確な要約を生成できるようになるためです。 2. 本番環境（プロダクション）における自律的な運用と高い信頼性 従来のAIモデルでは、生成されたコードやシステムへの変更に対して、人間が頻繁にチェック（レビュー）を行う必要がありました。しかし、GPT-6 Astraの導入によりその信頼性は飛躍的に向上しました。Perplexityでは、システム間でのコミュニケーション文章の作成、実際のシステムコードの書き換え、さらには稼働中の本番システム（プロダクション環境）の監視に至るまで、一連のエンドツーエンド（E2E）の処理をモデルに委託しています。人間がチェックする頻度は以前のモデルに比べて劇的に減少しており、システム運用において非常に高い信頼を獲得しています。 3. 「AIにテストプログラムを書かせる」効率的な開発手法 開発現場において、テスト工程はシステムの品質を担保するために極めて重要ですが、手動でのテストやテストコードの作成には多くの時間がかかります。Perplexityでは、この課題を解決するためにGPT-6 Astraを活用しています。 具体的な手法として、テストしたいアプリケーションの周囲に、モデルを使って簡易的なテスト用のプログラム（シミュレーター）を自動構築させています。GPT-6 Astraは、他の外部APIやコネクタといった連携サービスが返すような「リアルなレスポンス（応答データ）」を本物そっくりに模倣して生成できます。これにより、擬似的な連携環境を作り出し、システムが最初から最後まで正しく動作するかどうか（ワークフロー全体のテスト）を自動で検証することを可能にしています。 まとめ 本事例は、AIが単にプログラミングの「下書き」をする存在から、システム全体のテストや本番運用の「信頼できるパートナー」へと進化していることを示しています。新人エンジニアの皆さんも、日々のコーディングだけでなく、システム全体の設計やテストの自動化といった「開発プロセス全体」において、どのようにAIを組み込み協働していくかという視点を持つことが、これからのキャリアにおいて非常に重要になっていくでしょう。 引用元: https://openai.com/index/perplexity-improving-accuracy-with-astra Rethinking skills and prompts for GPT-6 Astra OpenAI Developers AIを活用したコーディングエージェントの技術は急速に進化しています。特に最新の「GPT-6 Astra」のような高性能なモデルが登場したことで、これまでのモデル（CodexやGPT-5.6 Solなど）で必要だった「手厚い指示（プロンプト）」や「過剰な制約」は不要になり、むしろ開発の妨げになるケースが増えています。本記事では、新人エンジニアの方に向けて、GPT-6 Astraの能力を最大限に引き出すためのプロンプト設計とエージェント定義（SkillsやAGENTS.md）の新しいベストプラクティスを分かりやすく解説します。 1. 「Skills（スキル記述）」のスマートな設計 プロジェクトでよく使われるSkills（特定のワークフローを指示するMarkdownファイルなど）は、モデルが処理しやすいように整理する必要があります。 説明は極力短く、具体的にする: スキルの説明が長すぎたり、数が多すぎたりすると、モデルのコンテキスト（記憶領域）を圧迫し、適切なスキルを選べなくなります。「いつ使うべきか」をピンポイントで記述しましょう（例：「データベース関連の作業で常に使う」ではなく「マイグレーションの作成・変更時のみ使う」とする）。 段階的な開示（Progressive Disclosure）: すべての指示を一つのファイルに詰め込まず、ルート文書は最小限の案内に留め、詳細なドキュメントやスクリプトは必要に応じてモデルに読み込ませるように階層化します。 過剰な手順書の廃止: GPT-6 Astraはニュアンスや曖昧さを高度に理解できるため、細かすぎる手順（レシピ）を強制すると、かえって最適な解決策を妨げてしまいます。 2. 「AGENTS.md」の最適化 リポジトリ全体に適用される設定ファイル（AGENTS.md）も、見直しが必要です。 不要なファイル読み込みを減らす: タイポの修正のような簡単な作業に対して、「編集前に必ず仕様書を読み込む」といった過剰な指示は、コンテキストの浪費と処理速度の低下を招きます。必要なドキュメントは、特定のタスク（例：スキーマ変更時など）に関連付けて、必要な時にだけ読ませるようにします。 自律的なテスト実行を信頼する: 旧モデルのように「テストを実行してチェックすること」と毎回細かく指示しなくても、Astraは自律的にこれを行います。 安全な範囲での自律性の許可: Astraは非常に賢く安全性を重視するため、慎重になりすぎて作業を途中で止めてしまうことがあります。そのため、「ローカルテスト環境は安全なので、承認なしでテストを実行し、エラーを修正して進めてよい」といった、前進するための許可を明示的に与えるプロンプトが効果的です。 3. 境界線の見直しと「完了」の定義 以前のモデルの暴走を防ぐために設定していた「〜する前に必ず確認すること」という強い制約は、Astraにおいては作業を停滞させる原因になります。 また、Astraは最初の実装が終わると、すぐにユーザーに確認を求めて立ち止まりがちです。そのため、「どこまで作業を進めてほしいか（例：実装、動作確認、エラー修正まで一気に行う）」という「タスクの完了定義」をはじめに明確に伝えることが重要です。 まとめ 新しいモデルを使う際は、過去の古いプロンプトを整理する「大掃除」が必要です。この記事の内容をもとに、GPT-6 Astra自身に「私のプロンプトや設定ファイルを監査（オーディット）して」と依頼してみることから始めてみましょう！ 引用元: https://developers.openai.com/blog/rethinking-skills-and-prompts-for-gpt-6-astra How to Build an AI Software Factory: Agents That Open, Review, and Merge PRs 【AIソフトウェアファクトリとは】 AIソフトウェアファクトリ（AI Software Factory）とは、自律的なコーディングAIエージェントの力を最大限に引き出し、開発チームがその成果を安全かつ効率的に取り込むための「自動化された開発パイプライン」のことです。 個人がローカルPCでAIエージェントを動かすだけでは、人間がレビューしきれないほどの大量のプルリクエスト（PR）が生成され、チームのレビュー能力がパンクしてしまいます。この「レビューのボトルネック」を解消するため、StripeやSpotify、Shopifyなどの先進企業は、エージェントの周囲に5つのステージ（関門）を構築しています。 【ファクトリを構成する5つのステージ】 Intake（受付）：すべての課題をAIに丸投げせず、「本当にAIが着手すべきタスクか」をフィルタリングします。仕様が明確なタスクはAIの成功率が高く、複雑な設計が必要なものは人間が担当するよう仕分けます。 Isolation（環境隔離）：AIがファイルを破壊したり、並行して動く他のAIと衝突したりしないよう、Gitの「worktree」機能やDockerコンテナ、ク

  8. 9月10日

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

    youtube版(スライド付き) 関連リンク Introducing the Agents API OpenAIは、自律型クラウドエージェントを構築・運用するための「Agents API」をパブリックベータ版として発表しました。これは同社のCodexやChatGPT for Workを支える強力な制御機構（ハーネス）と実行基盤（インフラ）を、シンプルなAPIを通じて提供するものです。 これまで、実用的なエージェントを作るには、長時間のコンテキスト管理、効率的なツール利用、複数エージェントの連携、安全なコード実行環境の整備など、多くの複雑な課題がありました。Agents APIはこれらの共通基盤をOpenAIが提供・保守するため、エンジニアはエージェント独自の「ツール」「知識」「ワークフロー」の実装に集中できます。 新人エンジニアに向けて、本APIの代表的な特徴を分かりやすく5つに整理します。 シンプルなAPIコールで構築可能 タスク、モデル、ツール、環境を指定し、1回のAPI呼び出しを行うだけで、本番環境で動作するエージェントを即座に作成できます。 柔軟な実行環境（サンドボックス）の選択 エージェントが安全にファイルを扱い、コードを実行するための「サンドボックス環境」を自由に選べます。OpenAIが管理する環境のほか、自社インフラ（VPC内）や、Vercel、Cloudflare、Daytonaなどの外部パートナーの環境とも簡単に連携できます。 長時間のセッションを支えるコンテキスト自動管理 エージェントが数時間にわたって動作する際、会話履歴が長くなりコンテキスト制限を超えてしまう問題があります。本APIは、限界に近づくと自動で過去の会話を要約・圧縮（コンパクション）し、重要な情報だけを維持します。開発者が自前で圧縮ロジックを書く必要はありません。 効率的なツール利用とコスト削減 必要に応じて適切なツール定義をロードする「Tool Search」により、不要なトークン消費を抑えコストを削減します。また、複数のツールを並列実行し、結果をコードでフィルタリングして必要なデータだけをモデルに戻す「プログラマティックツールコール」にも対応しています。 マルチエージェントによる業務の分担（並列化） 複雑なタスクを複数の「サブエージェント」に切り分け、並列で作業させることができます。各サブエージェントは割り当てられた仕事に集中し、メインのエージェントがそれらを統括します。開発者が面倒な連携ロジック（オーケストレーション）を構築する必要はありません。 なお、本APIの核となる制御ロジックはオープンソース（GitHub）として公開されているため、内部の仕組みを学びたいエンジニアにとっても透明性が高い仕様となっています。料金はAPIの追加手数料なしの、使ったトークンとツール分のみの従量課金です。 エージェント開発における最大の難所である「インフラと制御」を丸ごと解決してくれる、新人からベテランまで必見の強力な開発基盤です。 引用元: https://openai.com/index/introducing-the-agents-api Build more natural voice experiences with GPT‑Live‑1 in the API OpenAIは、アプリや業務フロー向けに、自然な会話ができる革新的な音声モデル「GPT-Live-1」のAPI提供を開始しました。本記事では、このモデルの特徴や仕組みを、新人エンジニアの方にも分かりやすく解説します。 1. 従来の音声システムとの決定的な違い これまで音声対話AIを作る場合、以下の3つの仕組みをつなぎ合わせるのが一般的でした。 STT（音声認識）：ユーザーの声をテキストにする LLM（言語モデル）：テキストを読み、返答を考える TTS（音声合成）：返答のテキストを声に変換する この構成は、各ステップの受け渡しで「遅延（レイテンシ）」が発生し、会話のテンポが不自然になりがちでした。また、ユーザーが途中で話しかける「割り込み」の制御が非常に難しいという課題がありました。 新登場の「GPT-Live-1」は、聞き取りと発話を「単一のモデル」で同時に処理（全二重：Full-Duplex）します。これにより遅延が劇的に減り、人間同士のような自然なキャッチボールが可能になります。 2. 開発者が知っておくべき「5つの強み」 スムーズな割り込み対応：AIが話している途中にユーザーが質問を変えても、自然に検知して対応します。従来システムと比べ、割り込みによる会話の破綻を約80%削減しました。 役割の委譲（Delegation）：リアルタイムな音声のやり取りは「GPT-Live-1」が担当し、裏側での深い思考や外部ツールの呼び出し（Tool Calling）は、バックエンドの別モデル（GPT-6 Astraなど）に任せることができます。 話し方のカスタマイズ：システムプロンプトを調整するだけで、AIのトーン、話すスピード、会話のスタイル（丁寧、親しみやすいなど）を自由に変更できます。 ノイズや沈黙の処理：街中の雑音を無視したり、ユーザーが考えている最中の「沈黙」を賢く判断したりできるため、騒がしい場所でもスムーズに会話が続けられます。 電話（テレフォニー）サポート：電話回線を通じた双方向の会話にも対応しており、飲食店の予約や顧客対応エージェントの構築に適しています。 3. 柔軟で合理的なシステム設計 開発者は、ユーザーの窓口となるフロントエンドに「GPT-Live-1」を配置し、バックエンドに控えるAIモデルを自由に組み合わせることができます。 例えば、予約の受付や確認といった定型的なタスクには軽量で低コストなモデル（Lunaなど）を繋ぎ、複雑なトラブル対応には高度な思考力を持つモデル（Astraなど）を繋ぐ、といった設計が可能です。これにより、応答スピードと開発コストの最適なバランスを実現できます。 4. 価格と提供状況 GPT-Live-1の音声レイヤーは、1分あたり0.05ドルで提供されます。すでにAPIで利用可能となっており、企業の信頼性の高いAIエージェント構築を支援する「OpenAI Presence」でも活用されています。 これからの音声AI開発は、単に「テキストを音声化する」フェーズから、「リアルタイムに状況を汲み取って対話する」フェーズへと進化します。この新しいアーキテクチャを理解し、ぜひ次世代の音声アプリケーション開発に挑戦してみてください。 引用元: https://openai.com/index/introducing-gpt-live-1-in-the-api Introducing SWE-2: Pushing the Pareto Frontier Cognition社は、性能と推論コストのトレードオフ（パレートフロンティア）を極限まで高めた最先端のコーディングAIモデル「SWE-2」を発表しました。SWE-2は、従来のSWE-1.7や競合モデル（Grok 4.6、GPT-6 Astraなど）と比較して、圧倒的な低コストでありながら同等以上の高い実用性を発揮します。FrontierCode 1.1 Mainベンチマークにおいて、Fable 5.1に迫る50.0%のスコアを「64%安いコスト」で達成しました。 ベースには2.8兆（2.8T）パラメータを持つ「Kimi K3」を採用し、高度な強化学習（RL）を施しています。技術的なブレイクスルーは主に以下の4点です。 パレート最適を意識した線形コストペナルティの導入 複数の推論エフォート（思考の深さ）レベルを単一の強化学習プロセスで同時に学習する手法を確立。成功報酬からエフォートに応じた推論コストを差し引く報酬関数 $R = S - \lambda_e C$ を用い、性能を維持したまま無駄な推論コストを削減する最適なバランスをモデルに学習させました。 「長さ重み付け」による学習の安定化 強化学習における勾配のばらつき（分散）を抑えるため、出力トークン長を基準値の重み付けに利用する革新的なアプローチを採用。追加の計算コストなしで、学習プロセスの劇的な安定化を実現しました。 投機的デコーディングと低精度演算による効率化 推論を高速化する「投機的デコーディング」において、変化するメインモデルに追従するドラフトモデルをオンラインで動的学習。また、FP8などの低精度演算や量子化意識学習（QAT）を組み込み、省メモリで高速な処理を実現しています。 検証器（Verifier）の強靭化とデータのスケールアップ 強化学習用の開発環境を従来の3倍に拡張。モデルが意図しない抜け道で課題をクリアする「報酬ハッキング」を防ぐため、AI自身の出力をフィードバックして検証プログラムを反復的に強化する仕組み（フライホイール）を構築しました。 新人エンジニアにとってのSWE-2の魅力と実用性 これまでのコーディングアシスタントにありがちだった「簡単な

    私立ずんだもん女学園放送部 podcast 20260911
すべて見る（89）

評価とレビュー

5
5段階評価中
3件の評価

番組について

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

情報

その他のおすすめ