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

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

By 株式会社ずんだもん技術室AI放送局Technology
Download on the App Store

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

  • 株式会社ずんだもん技術室AI放送局 podcast 20260929
    youtube版(スライド付き)
    関連リンク
    • Introducing Claude Sonnet 5.5 on AWS Amazon Web Services
    • 本記事では、Amazon Web Services(AWS)のマネージドサービスであるAmazon BedrockおよびClaude Platform on AWSにおいて、Anthropic社の最新生成AIモデル「Claude Sonnet 5.5」の提供が新たに開始されたことが発表されています。新人エンジニアの方向けに、このアップデートの要点や実務での活用方法を分かりやすく解説します。

      Claude Sonnet 5.5は、明確にスコープが定義されたコーディング作業や知識労働において、従来のモデルよりも高い精度、高速な処理速度、そしてタスクごとの低いコストを実現したモデルです。例えば、バグ修正や機能実装といったタスクにおいて、要件を正確に満たした成果物を素早く出力できます。また、一ページ仕様書、アーキテクチャ図、サマリースライドなどのドキュメントや視覚資料の作成品質も向上しています。

      実務においては、すでに提供されている「Claude Opus 5.5」との使い分けが重要となります。慎重な判断が求められるリリース時のデバッグ、複数プルリクエスト(PR)をまたぐ機能スタックの構築、大規模なコード移行、複雑な財務調査などは「Opus 5.5」に任せます。一方で、アプローチが明確化されておりスピードとコスト効率よく実行したいタスク、例えばアラートの一次対応、常時稼働するエージェントのモニタリング、SQLの自動生成、UI/UXテスト、IDE内での高速なコーディング支援などは「Sonnet 5.5」が最適です。

      Amazon Bedrock経由で利用する最大のメリットは、セキュリティとガバナンスにあります。入力したデータはAWSインフラストラクチャの外部に出ることなく、リージョン内にデータが保持されます(リージョンデータレジデンシー)。また、既存のAWS環境ですでに使われている「AWS IAM(アクセス管理)」「AWS CloudTrail(監査)」「Amazon CloudWatch(モニタリング)」「Amazon Bedrock Guardrails(安全性担保)」といったガバナンス機能と統合されており、利用料金も通常のAWS請求書に一括して計上されます。

      開発者がプログラムから利用する場合、PythonのBoto3ライブラリやAWS CLIを使用して bedrock-runtime エンドポイント経由でAPIを呼び出すことができます。モデルIDには global.anthropic.claude-sonnet-5-5 を指定し、Anthropic Messages APIやInvoke/Converse APIを利用します。なお、Sonnet 5.5ではレスポンスに思考プロセスを表すブロックが含まれる場合があるため、パース処理の際はテキストブロックを正しく選択する実装上の注意が必要です。

      このように、Claude Sonnet 5.5はコストパフォーマンスと実行速度に優れ、日々の開発ワークフローやエージェント開発に組み込みやすいモデルとなっています。AWS環境でセキュアに最新の生成AIを活用したいエンジニアにとって、すぐに試すべき注目のアップデートです。

      引用元: https://aws.amazon.com/blogs/machine-learning/introducing-claude-sonnet-5-5-on-aws/

      • Introducing cf: the agentic CLI for the entire Cloudflare API
      • Cloudflareは、AIエージェントによる利用の急増に対応するため、全Cloudflare APIを網羅した新しいエージェント向けCLI「cf」のオープンベータ版を発表しました。近年、Wranglerの利用におけるエージェントの割合は48%に達しており、人間よりも多くのコマンドを効率的に実行しています。しかし、従来のWranglerは約280操作に限定されており、数千に及ぶCloudflareの全機能を利用するには不十分でした。新CLI「cf」は、新しいAPI生成パイプライン「Forge」を活用し、OpenAPIスキーマから直接コマンドを生成することで、3,000以上の全API操作へのアクセスを可能にしています。

        開発における主な特徴として、まず出力の最適化があげられます。人間向けの人間工学的なunicodeテーブルではなく、コンテキスト消費を最小限に抑える圧縮されたJSONをデフォルトのインターフェースとして採用しています。また、3,000以上のコマンドからエージェントが目的の操作を自律的に見つけられるよう、自然言語で検索可能な「cf cli search」を搭載しています。これにより、エージェントは「–help」実行時に検索インデックスの存在を把握し、文脈に応じた適切なコマンドを自分で発見できます。

        設定ファイルには、型安全性とLSP(Language Server Protocol)の恩恵を受けられるTypeScriptベースの「cloudflare.config.ts」が導入されました。Claude CodeやCodexなどのLSPプラグインと連携し、エージェントが正確に設定の識別や編集を行えるようになります。「bindings」や「triggers」といったヘルパー関数により、環境変数、D1データベース、KV、R2、キューなどのリソースやルーティング定義をプログラムから安全かつ簡潔に記述可能です。さらに、ビルドサーバーにはViteが標準採用され、RustベースのRolldownを活用した高速なビルドやHMR(Hot Module Replacement)による優れたローカル開発体験を提供します。

        既存のWranglerプロジェクトからの移行も考慮されており、「cf migrate」コマンドを実行するだけで自動変換が行われます。Viteベースではないプロジェクト向けには引き続きWranglerへ処理を委譲し、ベータ終了後も18ヶ月間のメンテナンスサポートが提供される予定です。新人エンジニアにとっても、AIエージェントと協調しながら型安全な設定や豊富なAPIを直感的に扱える、次世代のインフラ開発ツールとなっています。

        引用元: https://blog.cloudflare.com/cloudflare-cf-cli-launch/

        • Holo4: powering generalist computer-use agents
        • 本記事では、GUI操作、コード実行、MCP、APIなど多様なインターフェースを横断して自律的にコンピュータを操作する汎用AIエージェントモデル「Holo4」のリリースについて解説しています。新人エンジニアの視点で理解しやすいよう、その特徴と技術的な要点をまとめます。

          Holo4は、27B(密)と35B-A3B(MoE)の2つのサイズで提供されており、ベースとなるQwenモデルから大幅な性能向上の改良が加えられています。従来のAIエージェントは「Webブラウザの画面操作のみ」や「APIの呼び出しのみ」といった単一のインターフェースに特化していることが多く、実際のビジネス業務のようにUIとAPIが混在する複雑なワークフローには対応しづらい課題がありました。これに対しHolo4は、デスクトップ、Web、Android、コードサンドボックス、ビジネスAPIを単一のモデルでシームレスに操作できる点が最大の特徴です。

          デスクトップ操作のベンチマークである「OSWorld 2.0」や、API操作の「AutomationBench」において、Holo4はパラメータ数が大幅に少ないながらも、最高峰のクローズドモデルに匹敵するコストパフォーマンスを発揮します。記事内では、FreeCADを用いた3Dモデリング(エッフェル塔やロゴの作成)や、GodotによるPac-Manゲームの自動生成・無人実行といった具体的なプロフェッショナル向けソフトウェアのタスクにおいて、ベースモデルと比較して効率的に動作する様子が示されています。

          開発アプローチとしては、独自の「Agentic Task Factory」を活用し、ドキュメントやWebサイトのスクリーンショットから約1万件のインタラクティブなタスクや環境を自動生成して教師あり学習および強化学習を行っています。また、数百ステップにわたる長期的なコンテキスト管理を可能にする信頼性の高いメモリ機構や、デスクトップ上のシェル統合など、エージェントの実行ループ(ハーネス)の改良も重ねられました。さらに、NVIDIA Nemotron Coalitionの一環として「Holotron4 Nano」も同時にリリースされており、基盤モデルをエージェント特化型へ効率的に拡張できることが示されています。

          重みデータはHugging Faceで公開され(BF16、FP8、NVFP4、4-bit GGUF)、H Models APIからも利用可能であり、エンジニアがすぐに自身の環境やワークフローに組み込んで試せるようになっています。

          引用元: https://huggingface.co/blog/Hcompany/holo4

          • UIの本に「長押しの機能はユーザが気づきにくいよ」って書いてあって、ふ~んって思いながら部屋の照明のボタン長押ししたら、白からオレンジになった「お前もかよ」
          • UIデザインの本に「長押し機能はユーザーに気づかれにくい」と記載されていたため、著者が自宅の照明スイッチを長押ししたところ、光の色が白からオレンジへ変化したというエピソードです。この体験から、専門書で指摘されるUIの課題が身近なプロダクトにも潜んでいることがユーモラスに共有されています。新人エンジニアにとっても、ユーザーが発見しにくい隠しコマンド的な操作感をUI設計時にどう扱うか、アクセシビリティやインタラクションの観点から考えさせられる話題となっています。

            引用元: https://togetter.com/li/2751548

            • お便り投稿フォーム
            • (株式会社ずんだもんは架空の登場組織です)

              8 min
            • マジカルラブリー☆つむぎのピュアピュアA.I.放送局 podcast 20260928
              youtube版(スライド付き)
              関連リンク
              • 2026年9月25日に発表された新しい Microsoft Copilot についての整理
              • 2026年9月25日、MicrosoftはCopilotの大規模アップデートを発表しました。今回のアップデートの核心は、Copilotが単に「質問に答えるAI」から「仕事を実行するAIプラットフォーム」へと進化する点にあります。新人エンジニアが押さえておくべきポイントとして、主に3つの新機能(Home、Code、Autopilot)と、それらを企業で安全に活用するための共通基盤(Microsoft Managed Runtimeなど)が挙げられます。

                1つ目の「Home」は、Chat、Cowork、Office(Word、Excel、PowerPointの直接作成・編集)を1つに統合した新しい作業の開始地点です。2つ目の「Code」は、自然言語を使ってアプリやダッシュボード、業務ツールといった新しい成果物をAI駆動で開発できるツールです。3つ目の「Autopilot」は、今回の発表で最もインパクトが大きい機能であり、質問を毎回待つのではなく、設定された目標や境界の中で、会議準備や進捗確認などの継続的な業務を自律的に進めるパーソナルAIエージェントです。

                また、これらのAI機能やアプリケーションを企業で安全・確実に運用するため、Microsoftは重要な基盤や仕組みも同時に発表しています。「Microsoft Copilot Managed Runtime」は、認証やセキュリティ、ガバナンス、監視を含めてアプリを安全に実行・管理するための共通基盤を提供します。さらに、「Microsoft IQ」や「Fabric IQ」といったインテリジェンス基盤により、企業の持つ業務データやコンテキストをAIが深く理解できるようになります。

                ライセンス体系についても、日常的な利用向けの「User Subscription License」と、長時間処理やエージェント処理を対象としたクレジットベースの「Usage-Based Billing」が組み合わされる形に進化します。

                このように今回のアップデートは、AIに質問する世界から、AIと一緒に成果物を作り、アプリを開発し、継続的な業務やその実行・管理基盤までをMicrosoft 365環境に統合していくという、大きなパラダイムシフトを示しています。新人エンジニアにとっても、今後は単なるコード生成だけでなく、AIプラットフォーム全体におけるガバナンスやエージェントのライフサイクル管理の視点が重要になってきます。

                引用元: https://qiita.com/yoshioterada/items/7123aef3db7d1ba91fc3

                • グーグル、全アカウント保持者に無料の1080p AI動画生成を開放
                • グーグルはブラウザベースの動画編集ツール「Google Vids」において、有料壁を撤廃し、Googleアカウントを持つすべてのユーザーへフルHD(1080p)のAI動画生成機能を無料で開放しました。本機能は「Gemini Omni 1.1 Flash」モデルをベースとしており、テキストプロンプトや写真、音声、既存映像からの動画変換に対応しています。開発者やエンジニアの視点として注目すべき技術的・仕様的ポイントは以下の通りです。

                  1. 統合された編集機能と品質維持

                    単に動画を生成するだけでなく、シーンを延長する際にキャラクターや照明、設定の一貫性を自動で維持する機能や、低解像度のAIクリップを画質劣化なく1080pへアップスケーリングする機能が追加されました。また、ナレーションのスクリプトは現在24言語に対応しており、今後は100以上の言語をカバーする「Gemini 3.8 Flash-Lite」によるテキスト読み上げ機能の搭載も予定されています。

                  2. AI生成物のトレーサビリティ(SynthID)

                    出力されるすべての動画フレームには、Google DeepMindの透かし技術である「SynthID」が直接埋め込まれます。これにより人間の目には見えない形でAI生成物であることが担保され、専用の「SynthID Detector」ツールによる機械的な検証が可能となっています。セキュリティやガバナンスを考慮するシステム開発において重要な要素です。

                  3. 利用枠(クォータ)の設計

                    無料枠はアカウント種別ごとに異なります。個人のGoogleアカウントでは月6本までの制限がありますが、Google AI ProやWorkspace(Business / Enterprise)では月500秒の動画生成に加え、アバター動画の利用枠が提供されます。教育機関向け(Workspace for Education)では毎日リセットされる2,000秒の枠が用意されており、管理者コントロールによる柔軟な運用管理が可能です。また、Veo 3.1 LiteをはじめとするAPI料金の引き下げや他社動向も含め、モデルコストの急速な低下が裏付けられています。

                  4. エコシステム戦略への移行

                    本機能は、GmailやDrive、YouTubeといった既存のグーグルエコシステムに深く組み込まれて提供されています。インフラと強力な配信力を持つプラットフォームにおいて、単体の生成プロダクトからエコシステム全体への統合が競争優位性の主戦場になりつつあることを示すアップデートです。

                    引用元: https://finance.biggo.jp/news/07c65cc5-d4c3-44a6-a1cd-cf009de26a8d

                    • UNIXパイプにAIを組み込む - sagepipe おそらくはそれさえも平凡な日々
                    • 本記事では、AIエージェントとCLIツールをUNIXパイプで連携させるための新しいツール「sagepipe」が紹介されています。新人エンジニアの皆さんも、シェルスクリプトでデータを処理する際、「AIの出力形式が不安定で後続のプログラムが壊れる」という課題に直面したことがあるかもしれません。sagepipeは、この問題を解決するために標準入出力(stdin/stdout)にJSON Lines(jsonl)を採用し、入力と出力の双方にJSON Schemaを定義・強制できるツールです。

                      具体的な仕組みとして、sagepipeはフロントマッター付きのMarkdownファイルを設定として受け取り、そこにAIのプロバイダー、モデル名、入出力のJSONスキーマ、そして実行プロンプトを記述します。例えば、記事一覧のJSONLデータを読み込み、スキーマに準拠した日本語の要約を生成し、それを次の処理プログラムへと安全に引き渡すといったパイプライン構築が可能です。CopilotやClaude、Codex、さらにはACP(Agent Client Protocol)にも対応しているため、お好みのAI環境で利用できます。

                      エンジニアリングの観点で特に重要なメリットは、AIの「出力の型がブレない安心感」です。sagepipeはスキーマに即したアウトプットを保証し、万が一不正な出力が出た場合でも、内部での検査やリトライ処理によって、後続の決定的なスクリプト(Go言語などで書かれた処理など)が異常系で止まるリスクを防ぎます。「変な出力が出ない」ことが保証されるため、GitHub ActionsなどのCI/CD環境や日常のバッチ処理、定型業務の自動化パイプラインにAIを組み込みやすくなります。

                      インストールはHomebrewやgo installで簡単に行えるため、日々の開発作業やCLIでのデータ処理フローにAIを取り入れたいと考えているエンジニアにとって、非常に実践的で導入しやすいツールとなっています。

                      引用元: https://songmu.jp/riji/entry/2026-09-27-sagepipe.html

                      • ITなんて何も分からない父親に「寺の業務システムを作りたい」と言われたので概念図を書いてもらったら、一発でこれが出てきてすごい
                      • IT未経験の父親が「寺の業務システムを作りたい」と発言し、作成した概念図が非常に優れていたという話題である。

                        この図は、管理したい情報をテーブルに見立ててリレーションを組むという、データベース設計の本質を突いた内容になっていた。
                        システム開発の現場では、顧客の要望が曖昧で「よしなにやってほしい」と言われると手戻りやコスト増大の原因になりやすい。しかし、このように業務に詳しいユーザー自身がやりたいことやデータ構造を可視化できていると、要件定義からデータベース構築、運用提案までのプロセスが極めてスムーズに進む。
                        エンジニアの視点からも、このような理想的な顧客と仕事ができれば開発が円滑に進むという好例として、多くの共感と称賛を集めている。新人エンジニアにとっても、業務理解の重要性と適切な要件整理の価値を学べる話題である。

                        引用元: https://togetter.com/li/2751108

                        • お便り投稿フォーム
                        • VOICEVOX:春日部つむぎ

                          9 min
                        • 私立ずんだもん女学園放送部 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つのコア技術で解決しています。

                              1. AI video co-director(協調的な意思決定)

                                動画全体の方向性を一貫させるため、強化学習の手法である「マルチアームドバンディット(MAB)」アルゴリズムを用いて、新しいストーリー構成の「探索」と、実績のあるクリエイティブ構成の「活用」を最適化します。決定された方針(戦略、構成、映像美)は、絵コンテ・キーフレーム・動画・音声の生成を担当する専門エージェントへ伝達され、最後にマルチモーダルLLMが成果物を評価して次の生成ループにフィードバックします。

                              2. CANVAS(ビジュアルの持続的メモリ)

                                登場人物やシーンの設定情報を構造化して記憶する仕組みです。カメラの視点が別の場所に移動した後に元のシーンに戻るような非連続な場面転換でも、衣服のデザインや空間の立体構造を正確に再現し、ビジュアルのブレを防ぎます。

                              3. A²RD(時間ダイナミクスの制御)

                                数分に及ぶ長尺動画を場面(セグメント)ごとに生成する自己回帰型アーキテクチャです。動画メモリを参照しながら、ストーリーを新しく展開させる「外挿(エクスプロポレーション)」と、既存のデザインを維持する「内挿(インターポレーション)」を動的に切り替えることで、物語の進行と物理的な整合性を両立させます。

                              4. 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は、テキストをそのまま読み込ませるのではなく、ドキュメント全体を「圧縮された画像」として捉えることで、この問題をスマートに解決しています。具体的な処理の流れは以下の通りです。

                                  1. ページ全体の画像化と圧縮(粗スキャン)

                                    入力された文書の各ページを、約192×252ピクセルという非常に解像度の低いサムネイル画像に変換します。この時の1ページあたりの視覚的な情報(視覚トークン数)は、わずか「約48トークン」にまで圧縮されます。

                                  2. 必要なページの特定とツールの呼び出し

                                    モデルはまず、この超軽量なサムネイル画像を使って、ドキュメント全体を俯瞰するようにスキャンします。そして、学習済みの専用ツール「read_page」を呼び出し、ユーザーからの質問に対して「答えが書かれていそうなページ」をピンポイントで特定します。

                                  3. 特定ページのみのテキスト化と回答生成(詳細スキャン)

                                    特定したページのみ、非圧縮のオリジナルテキストを取得して詳細に読み込み、最終的な回答を生成します。

                                    この「全体を粗く見てから、必要な場所だけを細かく見る」というアプローチにより、本来なら約8,000トークンを消費する文書であっても、わずか数百トークンに抑えて処理することが可能になりました。

                                    実践と学習に役立つデモの公開

                                    Hugging Face Spaces上では、実際にこのモデルの挙動を試せる「LensVLM-9Bデモ」も公開されています。長いドキュメントをアップロードして質問を投げかけると、モデルがどのように全体をスキャンし、どのページを選択・展開して答えを導き出したのか、その思考プロセスを視覚的に追うことができます。

                                    技術的な仕様としては、生成処理のレンダリングやプロンプト、ツールのフォーマット、そして「貪欲なデコード(Greedy Decoding)」は公式のリファレンス実装に準拠しており、ZeroGPU(Webブラウザ上でGPUを用いた軽量な推論を実行できる環境)向けに最適化され、Hugging FaceのTransformerライブラリに移植されています。

                                    新人エンジニアに向けた学びのポイント

                                    このニュースは、AIシステムを設計する上で非常に貴重な知見を提示してくれています。

                                    実務でAIを活用したアプリケーションを開発する際、APIの利用コスト削減や、動作速度の高速化は避けて通れない重要な課題です。LensVLM-9Bが示す「低コストで全体をインデックス(把握)し、必要な時にだけ詳細にアクセスする」というアプローチは、RAG(検索拡張生成)などのシステムを構築する上での設計思想としても大いに参考になります。

                                    まずは公開されているデモを触りながら、最先端のモデルがどのように効率化を実現しているのかを体感してみることをおすすめします。

                                    引用元: https://www.macotakara.jp/news/entry-51882.html

                                    • 普通のプリンターやコンビニのコピー機で印刷所で作ったような中綴じ本を作れるブラウザ完結ツールが公開される→めちゃくちゃ助かる人が多そう
                                    • ブラウザ完結で利用できる個人開発ツール「コピー本メーカー」が公開され、SNSで大きな話題を呼んでいます。このツールは、家庭用プリンターやコンビニのコピー機を使って、印刷所で作成したような高品質な「中綴じ本(コピー本)」を作るための面付けデータを簡単に作成できるWebアプリです。

                                      従来、コピー本作成におけるページの並べ替え(面付け)や、印刷時のズレ、余白の調整は非常に手間がかかる作業でした。本ツールは、原稿を縮小することなくトンボ通りに断裁すれば余白なしの正寸本になるよう自動で面付けし、両面印刷のズレを吸収する補正機能も備えています。

                                      ユーザーからは「コピ本界の救世主」と絶賛されており、手軽に高クオリティな本が作れると注目されています。ユーザーの具体的な課題を技術でスマートに解決した、新人エンジニアにとっても非常に参考になる個人開発の好例です。

                                      引用元: https://togetter.com/li/2749852

                                      • お便り投稿フォーム
                                      • VOICEVOX:ずんだもん

                                        8 min
                                      • 株式会社ずんだもん技術室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. ルーティングの大きな壁:「エキスパート崩壊」

                                                            学習の初期段階ではルーターの割り振りがランダムなため、偶然特定のエキスパートに処理が集中することがあります。すると、そのエキスパートだけが学習を進めてより賢くなり、さらにトークンが集まるという「正のフィードバック」が働き、他のエキスパートが全く使われなくなる「エキスパート崩壊(デッドウェイト化)」が発生します。

                                                            4. 崩壊を防ぐ最新のアプローチ

                                                            この偏りを防ぐため、各モデルで様々な工夫が凝らされています。

                                                            • 補助負荷分散損失(Auxiliary Load Balancing Loss): エキスパートの利用率が均等になるよう計算式(損失関数)でペナルティを与える伝統的な方法。ただし、「次のトークンを正確に予測する」という本来の学習目的と干渉するトレードオフがあります。
                                                            • 動的バイアス(Aux-loss-free / DeepSeek-V3): 補助損失をほぼ使わず、混雑しているエキスパートの選択スコアを下げ、空いている場所を上げる「補正バイアス」を学習中に動的に調整します。
                                                            • Quantile Balancing(Kimi K3): エキスパート数が極端に多い場合、バイアスの調整幅を統計的な分布(分位点)から直接算出することで、高速かつ安定して負荷を分散させます。
                                                            • MiMo-V2.6: 強化学習(RL)を行うとルーティングが偏って崩壊する課題に対し、RL後にルーティングパラメータのみを切り戻すことで対処しています。
                                                            • 5. 開発における実務的な注意点

                                                              • GPUメモリの確保: アクティブになるパラメータは一部ですが、動作させるには「全エキスパートを含む総パラメータ」を載せられるだけの莫大なGPUメモリが必要です。動かす際は「量子化」技術の併用が現実解となります。
                                                              • 共有エキスパート: どの文脈でも使われる共通の処理を担う「常時起動のエキスパート」を置く設計もありますが、効果の有無についてはモデル開発企業の間でも意見が分かれています。
                                                              • MoEの仕組みとこれらの課題解決のアプローチを理解しておくことで、最新LLMの技術レポートやモデルカードが非常に読み解きやすくなります。

                                                                引用元: https://iwashi.co/2026/09/23/mixture-of-experts-moe-memo

                                                                • 左手デバイスを買いに行き、店員にオススメを聞いたら「僕が電気屋の店員だということは一旦忘れていただきまして、ひとりの絵描きとしてお話させていただくんですけども」という確定演出に入った
                                                                • 家電量販店でイラスト制作などに使われる「左手デバイス」の購入を検討していた投稿者が、店員におすすめを尋ねた際のエピソードがSNSで大きな話題を呼んでいます。店員は「電気屋の店員であることを一度忘れ、ひとりの絵描きとして話します」と宣言し、売る立場を超えた当事者(オタク)としての熱い目線で親身にアドバイスをしてくれました。

                                                                  この「特定の分野の愛好家が、初心者を前にして自身の熱量を解放する瞬間(確定演出)」に対し、多くのネットユーザーから「SSR店員だ」「大勝利確定」と共感の声が集まっています。スレッド内では、シーシャ屋やカメラ店での同様の熱意ある接客例も挙げられ、立場を超えて実体験に基づくリアルなフィードバックをくれる「プロフェッショナル」の尊さが語られています。物事へのこだわりや技術を愛するエンジニアにとっても、深く共感できる心温まるエピソードです。

                                                                  引用元: https://togetter.com/li/2749204

                                                                  • お便り投稿フォーム
                                                                  • (株式会社ずんだもんは架空の登場組織です)

                                                                    9 min
                                                                  • 私立ずんだもん女学園放送部 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を取得できないため、今回の比較対象は一世代前の「非推論モデル」に限定されました。そのため、この結果だけで「Jevが最新のLLMより全面的に優れている」と結論づけるのは早計です。

                                                                                結論として、Jevの本質的な強みは「既存のLLMで不可能なことを実現した」という点よりも、「『確率を出力する』という実用的なインターフェースを、使いやすいAPIとしてパッケージ化して提供したこと」にあります。

                                                                                現在、一般的なLLMの推論速度やコストも急速に改善しており(例:DeepSeek V4 Flashの初期応答時間は約90ms)、大手AIベンダーが同様のAPIを提供すれば、既存のLLMでも同等のことが可能になる可能性があります。今後、Jevのような専用モデルがどれだけの独自価値を維持し続けられるか、エンジニアとして注目すべきポイントです。

                                                                                引用元: https://zenn.dev/nwn/articles/824026c76116e0

                                                                                • お便り投稿フォーム
                                                                                • VOICEVOX:ずんだもん

                                                                                  7 min
                                                                                • 株式会社ずんだもん技術室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(ルーティン)」を活用し、以下のプロセスを構築しました。

                                                                                              1. 【コード調査】:人間が不具合のIssueを起票して調査依頼ラベルを貼ると、AIがコードベースを自動で調査します。AIは修正方針や実装にあたって確認したい事項をIssueのコメントに書き残します。
                                                                                              2. 【人間の確認(Human in the Loop)】:開発者がAIの提案をレビューし、方針が良ければGOサインを、修正が必要ならフィードバックを返信して、実装依頼ラベルを付与します。
                                                                                              3. 【実装とPR作成】:AIが回答を基にコードを修正し、自身のセルフレビューとテスト項目の作成を行います。その後、修正内容やテスト項目を記載したDraft PRを自動で作成します。
                                                                                              4. 【最終検証】:人間がローカル環境にブランチを取り込んで動作確認を行い、マージします。
                                                                                              5. ■ この仕組みがもたらす5つのメリット

                                                                                                • 人間の時間外にAIを働かせる:夜間にAIが調査を進めておくことで、翌朝人間は回答するだけでよくなり、日中の並行作業を効率化できます。
                                                                                                • 履歴の可視化:Issue上に調査結果や修正方針の決定プロセスがすべて残るため、後からいつでも振り返ることができます。
                                                                                                • ローカル環境が汚れない:すべての処理はクラウド(サンドボックス)環境で行われるため、ローカルPCに不要な変更が入りません。
                                                                                                • 再現性のある挙動:個人のPC環境に依存せず、常に同じ実行環境で安定して動作します。
                                                                                                • 手戻りとコストの削減:実装前に「人間の確認」を挟むことで、AIが誤った方向に暴走するのを防ぎ、不要なAPI利用コストも抑えられます。
                                                                                                • ■ 直面した「AIネイティブ開発」の壁:レビュー負荷の増大

                                                                                                  実際に運用してみて直面した最大の課題は、「人間によるコードレビューの負担が非常に重い」という点でした。
                                                                                                  AIが書いたコードは、文法的に正しくテストも通ります。しかし、システム固有の複雑なビジネスルール(ドメイン知識)に本当に適合しているかを判断するには、結局人間が既存のコードベースを深く読み込み、AIの思考プロセスを逆算して紐解く必要がありました。その結果、コーディング時間が減った一方でレビュー時間が長くなり、効率化の恩恵が一部相殺されてしまうジレンマが生じました。

                                                                                                  ■ 今後の展望:AIとの協働をさらに進化させる

                                                                                                  この課題を乗り越えるため、チームでは以下の取り組みを進めています。

                                                                                                  • プロンプトによる意図の明示:「既存コードの実装パターンを踏襲する」「なぜそのアプローチをとったのかの理由をPRに明記する」ことをAIに徹底させ、レビュワーの負担を減らします。
                                                                                                  • 仕様駆動開発(Spec Driven Development)への応用:Issue上で事前に仕様の合意を形成し、その仕様を基にAIが実装するサイクルを作ることで、ドメイン知識のズレを実装前に防ぎます。
                                                                                                  • AIにコードを書かせることは容易になりましたが、それを実運用に載せて顧客価値に繋げるためには、人間とAIの協働プロセスを泥臭くデザインしていく必要があると著者は伝えています。

                                                                                                    引用元: https://tech-blog.rakus.co.jp/entry/20260916/ai

                                                                                                    • お便り投稿フォーム
                                                                                                    • (株式会社ずんだもんは架空の登場組織です)

                                                                                                      7 min
                                                                                                    • 株式会社ずんだもん技術室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点です。

                                                                                                              1. 圧倒的な高速化と低コスト

                                                                                                                従来のLLMが1文字ずつ生成するのに対し、Jevは「並列サンプリング」という新技術を用いて、1回のクエリで必要なすべての出力を同時に生成します。これにより、応答時間は「70ms〜500ms」と、従来の約40倍〜200倍の超高速化を実現しました。さらに出力にかかるコストは実質無料(FREE)となっています。

                                                                                                              2. ハルシネーションと型エラーの完全な排除

                                                                                                                出力されるデータの構造(スキーマ)を事前に定義しておく設計のため、型エラーが理論上発生しません。これにより、システム開発において「AIの出力フォーマットが崩れてエラーになる」という心配が完全になくなります。

                                                                                                              3. 信頼度の可視化(キャリブレーション)

                                                                                                                Jevは、すべての出力に対して「どれくらい自信があるか」の確率(信頼度)を同時に返します。これは新開発の学習手法「RLCD(意思決定のための強化学習)」によって実現されており、プログラム側で「信頼度が90%以上なら自動実行、それ未満なら人間に確認を促す」といった確実な制御が可能になります。

                                                                                                              4. 豊富なユースケース

                                                                                                                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で処理するのではなく、確定的なプログラムに置き換えるべきでは?」といった、最初の設計(前提)を疑うような抜本的な改善案は出てきません。

                                                                                                                  この原因はLLMの知能不足ではなく、最初に作った設計書に引きずられて探索範囲が狭まる「アンカー効果(Anchoring Bias / Degeneration-of-Thought)」にあります。自己反省を促す指示だけでは、この思考の罠から抜け出すことができません。

                                                                                                                  2. 解決策:外側のシステム(ハーネス)による改善ループの設計

                                                                                                                  AIエージェント自身の自己反省に頼るのではなく、システムの外側(ハーネス)から探索範囲を強制的に広げる仕組みを構築します。これは、深層学習が「データで実行」→「損失を計算」→「重みを更新」というステップを踏むのと同様に、エージェントシステム全体で「実行」→「評価」→「スキル・コードの更新」のループを設計するアプローチです。

                                                                                                                  このループを継続させるために、以下の4つの要素をハーネス上に設計します。

                                                                                                                  • ① Training Data(実行ログからの知識抽出):
                                                                                                                  • 個別具体的なエラーへの対処をそのまま書き加えるのではなく、複数の成功・失敗ログから共通する本質的な課題を抽出します。そして「金額の単位を本文と表のヘッダーの両方から確認する」といった、入力データが変わっても適用できる汎用的な「手順(スキル)」へ一般化して保存します。
                                                                                                                  • ② Optimizer(編集量の制御と検証):
                                                                                                                  • 一回のループにおけるプロンプトやコードの変更量を制限します。また、改善案の作成には使っていない「検証用のタスク」でテストを実行し、本当に精度が向上したと確認できた修正のみを採用します(これを行わないと、特定のデータだけに最適化されて他が動かなくなる過学習が起きます)。
                                                                                                                  • ③ Search Strategy(複数候補による局所最適の回避):
                                                                                                                  • 最高精度の1つの案だけに絞ると探索が偏るため、得意分野の異なる複数の候補(例:条項抽出に強い案、例外処理に強い案)を維持します。また、「LLMを2回しか呼ばない」「特定の処理はコードで行う」といった設計上の制約条件を変えることで、多様なアプローチを探索させます。
                                                                                                                  • ④ Evaluation(評価の品質):
                                                                                                                  • 自己改善ループにおいて「評価の精度」は極めて重要です。評価システムが不正確だと、改善ループを回すほどにエージェントの性能が低下していく現象が報告されています。
                                                                                                                    3. 新人エンジニアに向けたまとめ:人間の本当の役割

                                                                                                                    AIエージェントの自己改善システムにおいて、エンジニア(人間)が果たすべき最も重要な仕事は、プログラムコードを書くこと自体ではなく、「業務上の正しさを定義し、それを評価基準に落とし込むこと」です。

                                                                                                                    「事実や数値、判断が業務ルールと一致しているか(正確性)」「必要な観点が漏れなく含まれているか(完全性)」「文脈に合っているか(適切性)」といった、人間ならではの厳しい評価基準を作って初めて、AIは正しい方向へ自己改善を続けることができます。「評価こそが改善ループの進む方向を決める最大の鍵である」という認識を持ってシステム設計に臨むことが、実践的なAIエージェント開発への近道となります。

                                                                                                                    引用元: https://speakerdeck.com/22mi/how-to-design-self-improvement-for-ai-agents

                                                                                                                    • Gatebox、Animation Inc.とのTGSコラボ展示を発表!AniやAnimatesのAIコンパニオンがGatebox3に登場するショーケースをTGSで特別展示
                                                                                                                    • Gatebox株式会社は、東京ゲームショウ2026(2026年9月17日〜21日)にて、Animation Inc.が提供するAIコンパニオンアプリ「Animates」との特別コラボ展示を行います。

                                                                                                                      本展示では、2027年発売予定の次世代キャラクター召喚ディスプレイ「Gatebox3」の中に、Grokで人気を集めた3Dキャラクター「Ani」などのAIコンパニオンをホログラムのように召喚します。Animatesの強みである、遅延のないリアルタイムな音声会話技術と、Gatebox3による魅力的な3Dキャラクター表現を組み合わせることで、まるで本当にその場に存在しているかのような未来のAI対話体験を実現します。
                                                                                                                      LLMやリアルタイム生成アニメーション、高度なハードウェアによる投影技術の融合がもたらす最新のAIエージェントのインターフェース事例として、エンジニアにとっても大変興味深い展示となっています。

                                                                                                                      引用元: https://prtimes.jp/main/html/rd/p/000000146.000026497.html

                                                                                                                      • お便り投稿フォーム
                                                                                                                      • (株式会社ずんだもんは架空の登場組織です)

                                                                                                                        8 min
                                                                                                                      • 株式会社ずんだもん技術室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点に集約されます。

                                                                                                                            1. 依頼を「評価可能な条件」にし、データセットを育てる

                                                                                                                              AIに対する曖昧な指示のままでは、成果物が正しいかを客観的に評価できません。まずは満たすべき要件を明確な「契約(コントラクト)」として定義します。その上で、AIの挙動を検証するためのテストケース(評価データセット)を整備し、継続的に拡充していくことが重要です。

                                                                                                                            2. 「コードによる判定」と「LLMによる評価」のハイブリッド
                                                                                                                            3. 評価の手法には、プログラムで機械的に判定する「コード評価」と、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% を記録し、ベンチマーク内で 第1位 を獲得。
                                                                                                                                      • 速度(TTFA): 中央値 63ミリ秒(ms) で 第2位。なお、1位(49ms)のモデルは3億(300M)パラメーターの軽量モデルですが、Nari Labsは17億(1.7B)パラメーターの大型モデルでありながら、この超低遅延を達成しています。
                                                                                                                                      • コストパフォーマンス: 利用料金は 100万文字あたり10ドル で、ベンチマーク内で 共同最安値。ElevenLabs(5倍高価)やCartesia(6.5倍高価)を大きく引き離しています。こちらもStandardプラン(100万文字あたり5ドル)が提供されています。
                                                                                                                                      • 4. Nari Labsの技術的優位性

                                                                                                                                        特筆すべきは、同じオープンソースモデル(Qwen3)をベースにしながらも、Nari Labsのエンドポイントが他社のホスティング環境(Basetenや公式のFlashエンドポイントなど)を大幅に凌駕する精度と速度を実現している点です。これは、インフラや推論エンジンの最適化技術におけるNari Labsの優れた技術力を示しています。

                                                                                                                                        5. まとめと次のステップ

                                                                                                                                        Nari Labsは現在、STTおよびTTSモデルの無料パブリックベータを実施中です。まもなく有料の正式版(GA)へと移行しますが、今アカウントを作成すると移行時に20ドル分のクレジットが提供されます。遅延とコストの壁を取り払い、極めて滑らかなリアルタイム音声AIを実現したいエンジニアにとって、必見の技術成果です。

                                                                                                                                        引用元: https://narilabs.com/blog/nari-labs-leads-coval-voice-ai-benchmarks/

                                                                                                                                        • お便り投稿フォーム
                                                                                                                                        • (株式会社ずんだもんは架空の登場組織です)

                                                                                                                                          9 min
                                                                                                                                        • マジカルラブリー☆つむぎのピュアピュア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つのステージ】

                                                                                                                                                    1. Intake(受付):すべての課題をAIに丸投げせず、「本当にAIが着手すべきタスクか」をフィルタリングします。仕様が明確なタスクはAIの成功率が高く、複雑な設計が必要なものは人間が担当するよう仕分けます。
                                                                                                                                                    2. Isolation(環境隔離):AIがファイルを破壊したり、並行して動く他のAIと衝突したりしないよう、Gitの「worktree」機能やDockerコンテナ、クラウド上の使い捨てサンドボックスを用いて、独立したクリーンな開発環境を用意します。
                                                                                                                                                    3. Tools(ツール連携):AIにコンパイラやテスト実行器、さらには「MCP(Model Context Protocol)」を介して社内ツールや外部検索ツール(Firecrawlなど)へのアクセス権を与え、自律的に動けるようにします。
                                                                                                                                                    4. Verification(検証)※最重要:人間の目に触れる前に、ビルド、テスト、静的解析を自動で通します。さらに別のLLMが「変更内容が指示の範囲内か」を評価(ジャッジ)したり、ブラウザで画面のスクリーンショットを撮ってデザイン崩れをビジュアル検証し、結果を自動でPRに添付します。
                                                                                                                                                    5. Merge gate(マージ):最終的な責任は人間が負います。「AIが作成したPRには2人の人間の承認を必須とする」など、明確なマージポリシーを運用します。
                                                                                                                                                    6. 【統計から見る現実と運用のヒント】

                                                                                                                                                      データによると、AIが作成したPRのマージ率は人間のPR(約87%)に比べて約68%と低く、自動テストをパスしたAI製PRの約半分はそのままマージできないという現実があります。また、AIをただ導入するだけでは、コードの重複が増え、システムの不安定さが増すというリスク(DORAレポートより)も指摘されています。
                                                                                                                                                      しかし、ShopifyではPRの約12%をAIが担当するなど、大きな成果も上がっています。AIファクトリが最も輝くのは、新規の機能開発よりも、「古いバージョンのライブラリ移行」や「テストコードの大量作成」といった、機械的で退屈、かつ規模の大きなメンテナンス業務です。

                                                                                                                                                      【新人エンジニアへのメッセージ】

                                                                                                                                                      AIソフトウェアファクトリを構築する第一歩は、高度なAIシステムをいきなり作ることではなく、「まずは検証ゲートを1つ作ること」です。自分のプロジェクトで「AIが作ったコードが、最低限ビルドできるか」を自動チェックする仕組みを作るだけでも、立派なファクトリの始まりです。AIと協調する開発パイプラインの基礎を、ぜひ体験してみてください。

                                                                                                                                                      引用元: https://www.firecrawl.dev/blog/ai-software-factory

                                                                                                                                                      • Qiitaの約7万記事を分析してAIで書かれた記事に見られる特徴の変化を調べた記事が興味深い「こんな変化があるのか」「テキスト分析の勉強になる」
                                                                                                                                                      • Qiitaの約7万件の記事を対象に、生成AI普及の前後でエンジニアの文章がどう変化したかを分析した調査が話題です。分析によると、AIの活用によって記事の文字数が倍近くに増加し、太字や箇条書き、読点が増える傾向が見られました。

                                                                                                                                                        また、語彙の面では「設計」「検証」などの言葉が増えたほか、「〜が効いてくる」「静かに壊れる(英語のsilently breakの直訳)」といったAI特有の表現が頻出しています。一方で、「〜しましょう」のような定番表現はむしろ減少していました。

                                                                                                                                                        全体として、手順の解説から仕組みを説明する文章構造へと変化し、内容が均質化する傾向があります。新人エンジニアが記事を書く際は、AIによる綺麗な整理に頼るだけでなく、自分自身の「実体験」や「失敗談」「独自の判断」を文章に盛り込むことが、他と差別化された価値あるアウトプットを行うために重要となります。

                                                                                                                                                        引用元: https://togetter.com/li/2745057

                                                                                                                                                        • お便り投稿フォーム
                                                                                                                                                        • VOICEVOX:春日部つむぎ

                                                                                                                                                          9 min
                                                                                                                                                        • 私立ずんだもん女学園放送部 podcast 20260911
                                                                                                                                                          youtube版(スライド付き)
                                                                                                                                                          関連リンク
                                                                                                                                                          • Introducing the Agents API
                                                                                                                                                          • OpenAIは、自律型クラウドエージェントを構築・運用するための「Agents API」をパブリックベータ版として発表しました。これは同社のCodexやChatGPT for Workを支える強力な制御機構(ハーネス)と実行基盤(インフラ)を、シンプルなAPIを通じて提供するものです。

                                                                                                                                                            これまで、実用的なエージェントを作るには、長時間のコンテキスト管理、効率的なツール利用、複数エージェントの連携、安全なコード実行環境の整備など、多くの複雑な課題がありました。Agents APIはこれらの共通基盤をOpenAIが提供・保守するため、エンジニアはエージェント独自の「ツール」「知識」「ワークフロー」の実装に集中できます。

                                                                                                                                                            新人エンジニアに向けて、本APIの代表的な特徴を分かりやすく5つに整理します。

                                                                                                                                                            1. シンプルなAPIコールで構築可能

                                                                                                                                                              タスク、モデル、ツール、環境を指定し、1回のAPI呼び出しを行うだけで、本番環境で動作するエージェントを即座に作成できます。

                                                                                                                                                            2. 柔軟な実行環境(サンドボックス)の選択

                                                                                                                                                              エージェントが安全にファイルを扱い、コードを実行するための「サンドボックス環境」を自由に選べます。OpenAIが管理する環境のほか、自社インフラ(VPC内)や、Vercel、Cloudflare、Daytonaなどの外部パートナーの環境とも簡単に連携できます。

                                                                                                                                                            3. 長時間のセッションを支えるコンテキスト自動管理

                                                                                                                                                              エージェントが数時間にわたって動作する際、会話履歴が長くなりコンテキスト制限を超えてしまう問題があります。本APIは、限界に近づくと自動で過去の会話を要約・圧縮(コンパクション)し、重要な情報だけを維持します。開発者が自前で圧縮ロジックを書く必要はありません。

                                                                                                                                                            4. 効率的なツール利用とコスト削減

                                                                                                                                                              必要に応じて適切なツール定義をロードする「Tool Search」により、不要なトークン消費を抑えコストを削減します。また、複数のツールを並列実行し、結果をコードでフィルタリングして必要なデータだけをモデルに戻す「プログラマティックツールコール」にも対応しています。

                                                                                                                                                            5. マルチエージェントによる業務の分担(並列化)

                                                                                                                                                              複雑なタスクを複数の「サブエージェント」に切り分け、並列で作業させることができます。各サブエージェントは割り当てられた仕事に集中し、メインのエージェントがそれらを統括します。開発者が面倒な連携ロジック(オーケストレーション)を構築する必要はありません。

                                                                                                                                                              なお、本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つの仕組みをつなぎ合わせるのが一般的でした。

                                                                                                                                                                1. STT(音声認識):ユーザーの声をテキストにする
                                                                                                                                                                2. LLM(言語モデル):テキストを読み、返答を考える
                                                                                                                                                                3. TTS(音声合成):返答のテキストを声に変換する
                                                                                                                                                                4. この構成は、各ステップの受け渡しで「遅延(レイテンシ)」が発生し、会話のテンポが不自然になりがちでした。また、ユーザーが途中で話しかける「割り込み」の制御が非常に難しいという課題がありました。

                                                                                                                                                                  新登場の「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点です。

                                                                                                                                                                      1. パレート最適を意識した線形コストペナルティの導入
                                                                                                                                                                      2. 複数の推論エフォート(思考の深さ)レベルを単一の強化学習プロセスで同時に学習する手法を確立。成功報酬からエフォートに応じた推論コストを差し引く報酬関数 $R = S - \lambda_e C$ を用い、性能を維持したまま無駄な推論コストを削減する最適なバランスをモデルに学習させました。
                                                                                                                                                                      3. 「長さ重み付け」による学習の安定化
                                                                                                                                                                      4. 強化学習における勾配のばらつき(分散)を抑えるため、出力トークン長を基準値の重み付けに利用する革新的なアプローチを採用。追加の計算コストなしで、学習プロセスの劇的な安定化を実現しました。
                                                                                                                                                                      5. 投機的デコーディングと低精度演算による効率化
                                                                                                                                                                      6. 推論を高速化する「投機的デコーディング」において、変化するメインモデルに追従するドラフトモデルをオンラインで動的学習。また、FP8などの低精度演算や量子化意識学習(QAT)を組み込み、省メモリで高速な処理を実現しています。
                                                                                                                                                                      7. 検証器(Verifier)の強靭化とデータのスケールアップ
                                                                                                                                                                      8. 強化学習用の開発環境を従来の3倍に拡張。モデルが意図しない抜け道で課題をクリアする「報酬ハッキング」を防ぐため、AI自身の出力をフィードバックして検証プログラムを反復的に強化する仕組み(フライホイール)を構築しました。

                                                                                                                                                                        新人エンジニアにとってのSWE-2の魅力と実用性

                                                                                                                                                                        これまでのコーディングアシスタントにありがちだった「簡単なタスクなのに、ソースコードを無駄に探索しすぎて回答が遅い(Overthink)」という問題が劇的に改善されました。コードベースの中から「本当に修正すべき箇所」を賢く見極める能力が向上した結果、最初のコード修正に着手するまでのステップ数が従来の48ステップから18ステップへと半減以下になっています。

                                                                                                                                                                        さらに、実装コードが正しく動くか検証する「テストの網羅性」が向上し、バグやデグレを確実に防ぎます。指示されたアプローチが使えない場合に代替手段を自ら探る粘り強さや、人間の仮説を鵜呑みにせず、実際にコードを動かして自己検証する信頼性も備えています。

                                                                                                                                                                        SWE-2は、すでにAIソフトウェアエンジニア「Devin」のデスクトップアプリやCLI等で利用可能です。開発現場の強力な相棒となる、実用性の高い最新テクノロジーです。

                                                                                                                                                                        引用元: https://cognition.com/blog/swe-2

                                                                                                                                                                        • 元『DJMAX』スタッフによるプニかわ美少女の音ゲー『PLATiNA :: LAB』正式版Steamでリリース!見た目はポップでもキー音あり本格派―ずんだもんDLCもある
                                                                                                                                                                        • 韓国のHIGH-END Gamesは、Steam向けリズムゲーム『PLATiNA :: LAB』の正式版(Ver.1.0)をリリースしました。本作は元『DJMAX』のスタッフが手掛ける本格音楽ゲームで、可愛い美少女キャラクターが登場するポップな外見ながら、キー入力時に音が鳴る「キー音」システムを搭載した硬派な作りが特徴です。

                                                                                                                                                                          正式版では、フルボイスのメインストーリーや100曲以上の楽曲を収録。にじさんじや雀魂といった人気IPとのコラボ曲に加え、期間限定で「ずんだもん」のDLCも配信されています。

                                                                                                                                                                          開発面では、早期アクセス期に寄せられたユーザーフィードバックを忠実に反映。プレイデータ確認機能やランキングシステムの実装、UI刷新、クライアントの最適化や安定性向上など、徹底的なプロダクト改善が行われています。さらに、本編の恒久的な値下げや早期購入者へのDLC無料配布など、ユーザーに寄り添った運用姿勢も魅力です。

                                                                                                                                                                          引用元: https://www.gamespark.jp/article/2026/09/10/172069.html

                                                                                                                                                                          • お便り投稿フォーム
                                                                                                                                                                          • VOICEVOX:ずんだもん

                                                                                                                                                                            10 min

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

                                                                                                                                                                          From the publisher's feed

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