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

関連リンク Everything Ive learned so far about running local LLMs この記事は、ローカル環境でLarge Language Model (LLM) を動かす方法について、著者の経験に基づいた実践的な情報をまとめたものです。著者はLLMの専門家ではなく、情報が急速に変化する分野であるため、この記事の内容も将来は古くなる可能性が高いことを前提にしています。 LLM実行のための要件: LLMを実行するには、ソフトウェアとモデルの両方が必要です。ソフトウェアとしては、llama.cpp が推奨されています。これはC++で記述されており、Python等の依存関係がないため、Windows環境でも容易に利用できます。CPU推論はGPU推論に比べて速度は遅いものの、8GB未満のVRAMしかないGPU環境では現実的な選択肢となります。GPU推論を行う場合は、8GB以上のVRAMが必要になります。llama-serverコマンドでHTTPサーバーを起動し、Web UIやAPI経由でLLMを利用できます。 モデルの選択: モデルはHugging Faceから入手できます。llama.cppと互換性のあるGGUF形式のモデルを選択する必要があります。モデルのサイズは数GBから数百GBまで様々で、パラメータ数が多いほど性能は向上しますが、必要なメモリも増加します。著者は、Mistral-Nemo-2407 (12B)、Qwen2.5-14B、Gemma-2-2Bなどを好んで使用しており、それぞれのモデルの特性（得意なタスク、速度など）についても記述しています。量子化されたモデル（例えばQ4_K_M）を使用することで、必要なメモリを削減できます。 ユーザーインターフェース: 著者は、llama.cppの組み込みUIに満足せず、独自のCLIツールIllumeを開発しています。これは、標準入力からAPIクエリを生成し、応答を標準出力にストリーミングするツールで、テキストエディタと連携して使用することを想定しています。Illumeは様々なLLMソフトウェアのAPIに対応していますが、API間の非互換性があるため、柔軟な設定が求められます。 Fill-in-the-Middle (FIM): FIMは、既存のコードにコードを挿入する手法です。llama.cppでは/infillエンドポイントが提供されていますが、対応していないモデルもあります。著者は、IllumeでFIMに対応する独自のテンプレートを作成することで、様々なモデルでFIMを利用できるようにしています。しかし、LLMはFIMにおいても生成を停止するタイミングを適切に判断できないことがあり、注意が必要です。 LLMの用途: LLMは万能ではなく、正確性の検証が容易でないタスクには適していません。また、コンテキストの長さにも制限があり、大規模なコードの生成には不向きです。LLMの得意な用途としては、校正、短編小説の創作、言語翻訳などが挙げられています。コード生成については、現状ではまだ実用レベルには達していないと結論付けています。 本要約は、原文の技術的な詳細や具体的な使用方法については省略し、日本の新人エンジニアが理解しやすいように、全体像と重要な制約事項に焦点を当てて記述しています。 引用元: https://nullprogram.com/blog/2024/11/10/ Next.js知識ゼロから生成AI頼みでWebアプリを作って思ったこと この記事は、Next.jsの知識が全くない筆者が、生成AI（主にClaude、必要に応じてChatGPTも使用）を活用して、2～3週間でNext.jsアプリを5つ開発した経験を記したものです。 新人エンジニアの方にも理解しやすいよう、要点に絞って説明します。 開発の経緯: 筆者は、Shaberi3ベンチマーク結果の可視化アプリ作成をきっかけにNext.js開発を始めました。Claudeが生成した美しいデザインのコードを参考に、ローカル環境（Ubuntu 24.04.1 LTS）で開発を始めました。 初期段階では、csvファイルの読み込みに苦労しましたが、Claudeからの丁寧な指示とChatGPTの助けを借りて、ローカル環境での実行に成功しました。 開発中は、エラー発生時に生成AIにエラーメッセージとソースコードを提示して解決策を求め、機能拡張も生成AIとの対話を通して進めました。 Claudeは期待以上の機能を提供することもありました。 完成したアプリはVercelで簡単にデプロイされ、誰でもアクセスできるようになりました。 その後、自分用アプリから発展して、より需要の高い株価・資産運用シミュレータも開発しました。 この過程で、他者からのフィードバックがモチベーション向上に繋がったことを実感しています。 開発を通しての知見: 生成AIの活用: ClaudeはWebアプリ開発に非常に強力で、ChatGPTや他のモデルよりも効率的でした。 プロンプトエンジニアリングの重要性も再確認しました。 筆者は、プロンプトをGitのコミットメッセージとして記録することで、開発過程の追跡と効率化を図ることを提案しています。 開発の楽しさ: 自分のアプリを他者に使ってもらえる喜びを実感し、開発のモチベーションを高めました。 好奇心の重要性: Bolt.newなどの技術を追いかける過程で、最初は諦めかけていた技術も、好奇心と探究心によって最終的に理解し、活用できるようになった経験を共有しています。 生成AIを用いたアプリ開発の未来: 筆者は、将来的には、生成AIがスクリーンショットからUIを生成し、サービス全体を理解・再現する可能性を予測しています。 しかし、バックエンドやセキュリティ面は、人間の専門知識が依然として重要だと考えています。 また、生成AIによって個人でも簡単にアプリ開発が可能になり、OSSの増加や、広告を削除した無料アプリの増加が予想されます。 一方で、人間関係構築や承認欲求を満たすアプリなど、AIだけでは代替できない領域のアプリは今後も需要があるだろうと考察しています。 結論: 本記事では、生成AIを駆使したNext.jsアプリ開発の体験談と、その過程で得られた知見、そして未来展望が示されました。 生成AIはWebアプリ開発を劇的に容易にする可能性を秘めている一方、人間の創造性や専門知識も依然として不可欠であることが示唆されています。 特に、新人エンジニアにとって、生成AIを効果的に活用する手法や、開発におけるモチベーション維持の重要性が理解できる内容となっています。 引用元: https://zenn.dev/robustonian/articles/nextjs_gen_ai FrontierMath: A Benchmark for Evaluating Advanced Mathematical Reasoning in AI FrontierMathは、AIの高度な推論能力を評価するために設計された、数百問のオリジナル数学問題からなるベンチマークです。計算数論から抽象代数幾何学まで、現代数学の主要な分野を網羅しており、専門の数学者でも解くのに数時間から数日かかるような高度な問題が含まれています。 開発には60名以上の数学者（教授、IMO問題作成者、フィールズ賞受賞者を含む）が協力しました。問題の多くは、専門家ですら数時間から数日かかるレベルの難易度です。フィールズ賞受賞者からも、「非常に難しい。現状では、関連分野の大学院生のような準専門家と、最新のAIと他の代数パッケージを組み合わせる以外に解く方法はないだろう」といったコメントが寄せられています。 既存のGSM-8kやMATHといったベンチマークでは高い精度を達成している最先端のAIモデルも、FrontierMathでは2%未満の問題しか解けません。これは、現在のAIの能力と数学コミュニティ全体の能力との間に大きなギャップがあることを示しています。 FrontierMathの問題は、以下の特徴を持っています。 新規性と検証可能性: すべて新規で未発表の問題であり、正確な整数や行列、SymPyによる数式表現など、計算によって自動的に検証できる解答を持っています。 推測困難性: 解答は大きな数値や複雑な数学的対象であり、数学的な作業なしに正しく推測できる確率は1%未満です。 厳格な査読: 専門家による査読を行い、正確性、曖昧性の有無、難易度を評価しています。エラー率は、他の主要な機械学習ベンチマークと同程度です。 評価においては、AIモデルにPython環境を提供し、コード実行、仮説検証、中間結果の確認、アプローチの改良などを可能にすることで、最大限のパフォーマンスを引き出せるよう配慮されています。しかし、それでも最先端のAIモデルの正解率は2%未満にとどまりました。 今後の展開としては、定期的な評価、ベンチマークの拡張、追加問題の公開、品質保証の強化などが計画されています。FrontierMathは、AIシステムが研究レベルの数学的推論能力を備えているかどうかを評価するための重要な一歩であり、AIの発展と共にその価値はますます高まると期待されています。 引用元: https://epochai.org/frontiermath/the-benchmark お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

関連リンク SCIPE - Systematic Chain Improvement and Problem Evaluation SCIPEは、複数のLLM（大規模言語モデル）呼び出しを含む複雑なLLMチェーンにおける問題箇所特定を支援するツールです。LLMアプリケーション開発において、最終出力だけでなく中間出力の評価も重要ですが、リソース制約から見過ごされがちです。LLMチェーンの1つのノードの不具合が、全体に悪影響を及ぼすため、デバッグが困難になります。 SCIPEは、LLMチェーンの各ノードの入力と出力を分析し、修正によって最終出力の精度を最も向上させるノードを特定します。これは、正解データ（ground truth）を必要とせず、LLM自身を評価者として利用することで実現しています。 SCIPEはノードの故障確率を2種類に分類します。 独立故障: ノード自体、またはそれを処理するLLMに起因する故障。 従属故障: 上流のノードの故障が原因で発生する故障。 LLM評価者(LLM Judge)を用いて各ノードの出力を評価し、パス/フェイルスコアを生成します。この結果から、条件付き故障確率（上流ノードも故障している場合のノード故障率）と独立故障確率を計算し、問題ノードを特定します。 最も下流のノードから開始し、条件付き故障確率に基づいて上流ノードを辿り、独立故障確率が最も高いノードを根本原因として特定します。これは、再帰的なアルゴリズムで実装されています。 SCIPEを使用するには、Langgraphから生成されたアプリケーショングラフ、各ノードの入出力データ（DataFrame形式）、そして設定ファイルが必要です。設定ファイルには、LLM評価者のモデル名、検証結果の保存先などが含まれます。 LLMEvaluatorクラスを用いて、LLM評価を実行し、find_problematic_node()メソッドで問題ノードを特定します。結果は、根本原因ノード、デバッグパス、各ノードの故障確率を含むEvaluationResultオブジェクトとして出力されます。 SCIPEは、LLMチェーンにおける問題ノードの特定と修正を支援することで、LLMアプリケーションの信頼性と性能向上に貢献します。 GitHubリポジトリには、具体的な使用方法や詳細な技術情報は記載されていますが、本要約では省略しています。 引用元: https://blog.langchain.dev/scipe-systematic-chain-improvement-and-problem-evaluation/ Supercharging AI Coding Assistants with Gemini Models Context GoogleとSourcegraph社による共同研究で、Gemini 1.5 ProとFlashモデルを用いた大規模コンテキストウィンドウ（最大100万トークン）が、AIコーディングアシスタントの精度向上に大きく貢献することが示されました。 従来のAIモデルは、大規模なコードベースにおける複雑な関係性や依存関係の理解に課題がありましたが、この研究では、大規模コンテキストウィンドウによってコード理解と生成の精度が向上することを実証しています。 Sourcegraph社が開発したコーディングアシスタント「Cody」を用いた実験では、100万トークンのコンテキストウィンドウを使用することで、以下の3つの指標で大幅な改善が見られました。 Essential Recall（必須情報の再現率）: 回答に含まれる重要な事実の割合が大幅に増加しました。 Essential Concision（必須情報の簡潔さ）: 回答の長さに対する必須情報の割合が向上し、より簡潔で関連性の高い回答が得られるようになりました。 Helpfulness（有用性）: 回答の長さに対する有用性のスコアが大幅に向上し、よりユーザーフレンドリーな体験が実現しました。 さらに、幻覚率（事実と異なる情報の生成）も18.97%から10.48%に減少しました。これは、AIによるコード生成の信頼性を高める上で重要な成果です。 ただし、大規模コンテキストウィンドウを使用する際には、処理時間増加というトレードオフが存在します。Sourcegraph社は、プリフェッチ機構と階層型コンテキストモデルアーキテクチャによるモデル実行状態キャッシングを実装することで、1MBのコンテキストにおける最初のトークン生成時間を30～40秒から約5秒に短縮することに成功しました。 この研究成果は、大規模コンテキストモデルがコード理解と生成を革新的に変える可能性を示唆しており、今後のAIコーディングアシスタントの発展に大きな影響を与えるものと期待されます。 詳細な評価方法やベンチマーク、分析については、Sourcegraph社のブログ記事を参照ください。 引用元: https://developers.googleblog.com/en/supercharging-ai-coding-assistants-with-massive-context/ Unleashing Stability AI’s most advanced text-to-image models for media, marketing and advertising: Revolutionizing creative workflows Amazon Web Services Amazon Bedrock上で利用可能になったStability AIの最新テキスト・トゥ・イメージモデル（Stable Image Ultra、Stable Diffusion 3 Large、Stable Image Core）は、メディア、広告、エンターテインメント業界のワークフローを革新します。これらのモデルは、従来のStable Diffusion XLよりも大幅に改良されており、特にテキストの品質、複雑なシーンの描写、写実性の向上に優れています。 主な改善点は、より正確なプロンプトへの対応、テキストの正確なレンダリング、複雑なシーンの描写力向上、写真のような写実性、多様な入力への対応、スケーラビリティの向上、そして高度なDiffusion Transformerアーキテクチャの採用です。 Stable Image CoreはSDXLの後継として高速かつ低価格な選択肢を提供し、Stable Diffusion 3 LargeとStable Image Ultraは、より高度なアーキテクチャにより、高品質な画像と優れたタイポグラフィを実現します。パラメータ数は、Stable Image Coreが26億、Stable Diffusion 3 LargeとStable Image Ultraが80億です。 これらのモデルは、コンセプトアート、ストーリーボード、広告素材、ソーシャルメディアコンテンツなど、幅広い用途に活用できます。例えば、広告代理店は、ブランドアイデンティティに合わせた視覚素材を迅速に生成し、マーケティングキャンペーンを効率化できます。映画制作では、セットデザインの視覚化や仮想制作に役立ち、時間とコストを削減できます。 さらに、提供されているJupyter Notebookのサンプル(詳細は割愛)では、大規模言語モデル(LLM)とStable Diffusion 3 Largeを組み合わせた、広告キャンペーンのエンドツーエンド生成プロセスが示されています。これは、LLMによるアイデア生成と画像生成モデルによるビジュアル作成を統合することで、高品質な広告素材を迅速に作成できることを実証しています。 これらのモデルは、従来の手法では困難だった、抽象的な概念や複雑なスタイルの表現を可能にし、クリエイティブな表現の幅を大きく広げます。新人エンジニアにとっても、これらのモデルは、高度な画像生成技術を容易に利用できる強力なツールとなるでしょう。 ただし、各モデルの特性(パラメータ数、入力形式、出力品質など)を理解し、目的に最適なモデルを選択することが重要です。 引用元: https://aws.amazon.com/blogs/machine-learning/unleashing-stability-ais-most-advanced-text-to-image-models-for-media-marketing-and-advertising-revolutionizing-creative-workflows/ お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

関連リンク Google Confirms Jarvis AI Is Real by Accidentally Leaking It Googleが開発中のAIエージェント「Jarvis AI」が、Chrome拡張機能ストアに誤って公開され、その後すぐに削除されました。しかし、一部ユーザーはダウンロードに成功したようです。 Jarvis AIは、Web上の情報を収集したり、商品購入やフライト予約といったタスクを自動化することを目的としたAIです。Gemini AIをベースにしており、日常的なWebベースの作業の自動化を支援するとのことです。2024年12月のリリースを目指しているようです。 記事では、Jarvis AIと同様の機能を持つ他のAIエージェントについても言及しています。AnthropicのClaude AIもコンピュータを制御する機能を持ち、Apple Intelligenceも画面上の操作を学習して自動化する機能を有しています。また、MicrosoftのCopilot+ Recallも同様の機能を持っていましたが、プライバシーに関する懸念からリリースが延期されています。 これらのAIエージェントは、コンピュータ操作の自動化という点で共通の目標を持っていますが、プライバシーやセキュリティに関する課題も抱えていることが示唆されています。Jarvis AIの早期公開は、Googleがこうした技術の開発とリリースにおいて、まだ課題を抱えていることを示しているのかもしれません。 今後、Jarvis AIがどのように進化し、どのような機能を提供するのか注目されます。 引用元: https://gizmodo.com/google-confirms-jarvis-ai-is-real-by-accidentally-leaking-it-2000521089 Unearth insights from audio transcripts generated by Amazon Transcribe using Amazon Bedrock Amazon Web Services 本記事は、Amazon TranscribeとAmazon Bedrockを用いた音声データ分析によるビジネス価値創出について解説しています。音声データは分析が難しく、手動での転写・分析は時間とコストがかかりますが、生成AIを活用することで効率的にインサイトを得ることが可能になります。 課題: 音声データの分析は、手動転写とレビューが必要で時間とリソースを大量に消費します。自動音声認識ツールはテキスト化できますが、インサイト抽出には依然として人的作業が必要です。 解決策: Amazon Transcribeによる音声テキスト化と、Amazon Bedrock上のファウンデーションモデル(FM)を用いた分析を組み合わせることで、効率的なインサイト抽出を実現します。具体的には、AnthropicのClaude 3 Sonnetなど、Amazon Bedrockで提供されている様々なLLMを選択して利用可能です。 具体的なユースケース: マーケティングコンテンツ分析: ポッドキャスト、インタビュー、動画などを要約、分類、分析し、新たなマーケティング素材を生成します。 会議録分析: 会議録音から主要ポイント、要約、感情分析を行い、戦略的意思決定に役立てます。 コンタクトセンター通話分析: 通話を転写・分析し、顧客体験向上に繋げます。 Amazon Transcribeの機能: 音声テキスト化、複数話者認識、個人情報自動削除、業界固有の語彙やカスタム言語モデルの使用による精度向上など。 Amazon Bedrockの機能: テキスト要約、トピック特定、結論認識、感情分析、新規コンテンツ生成など。 既存のテキストデータを用いて、ブログ記事作成、要約文作成、SEOキーワード抽出、さらには顧客満足度や感情分析まで行うことが示されています。 実装例: 記事では、PythonとJupyter Notebookを用いた具体的なコード例が紹介されています。Amazon S3のバケットに音声ファイルをアップロードし、Amazon Transcribeでテキスト化、その後、Amazon Bedrock上のFMを用いて様々な分析を行う流れが示されています。 (コードの詳細な説明は省略) 結論: Amazon TranscribeとAmazon Bedrockの組み合わせにより、音声データから顧客感情、課題、リスク軽減策などの貴重なインサイトを効率的に抽出できます。手動作業に比べて時間とコストを削減し、既存コンテンツを革新的に活用する機会を生み出します。 マーケティング、会議分析、顧客サービスなど、様々な分野で活用可能です。 引用元: https://aws.amazon.com/blogs/machine-learning/unearth-insights-from-audio-transcripts-generated-by-amazon-transcribe-using-amazon-bedrock/ Reducto Document Ingestion API RD-TableBenchは、複雑な表のデータ抽出性能を評価するためのオープンベンチマークです。スキャンされた表、手書き文字、複数言語、セル結合など、様々な困難なシナリオを含む1000枚の表画像データセットで構成されています。データはPhDレベルの専門家によって手動でアノテーションされており、既存のベンチマークとは異なり、現実世界の多様な状況を反映した高精度なデータセットとなっています。 本ベンチマークでは、Reducto、Azure Document Intelligence、AWS Textract Tables、GPT4o、Google Cloud Document AI、Unstructured、Chunkr、LlamaParseといった複数のツール/手法の抽出性能を評価しました。評価指標としては、Needleman-Wunschアルゴリズムを基にした階層的アライメント手法を採用しています。これは、セルレベルと行レベルの両方で類似度を計算することで、表構造と内容の両方の類似性を捉えることができます。セルレベルではLevenshtein距離を用いて部分一致も考慮し、行レベルでは行の挿入・削除・分割・結合にも対応できる柔軟な比較を行います。最終的な類似度スコアは0〜1の間で表され、1.0が完全一致、0.0が全く異なることを意味します。 既存のPubTabNetやFinTabNetなどのベンチマークとは異なり、RD-TableBenchはより現実的で多様なデータと高精度なアノテーションを提供することを目指しています。ただし、ベンチマークデータの悪用を防ぐため、評価フレームワークの一部のみが公開されています。各ツールの評価結果については、指定のブログ記事を参照ください。 新人エンジニアの皆様には、このベンチマークが表データ抽出モデルの開発・評価に役立つことを願っています。 複雑な表データ処理における課題と、その解決に向けた様々なアプローチを理解する上で、非常に有効なリソースとなるでしょう。 特に、Needleman-Wunschアルゴリズムを用いた類似度計算手法は、文字列比較だけでなく、表構造の比較にも応用できる高度な技術であることを理解しておきましょう。 引用元: https://reducto.ai/blog/rd-tablebench お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

関連リンク xAI、Grok APIを一般公開｜月額25ドルの無料クレジットで開発者獲得へ - イノベトピア イーロン・マスク氏率いるxAIが、大規模言語モデルGrokのAPIを一般公開しました。11月4日より、月額25ドル分の無料クレジットを提供し、開発者獲得を目指しています。Grok APIは、入力トークン100万件あたり5ドル、出力トークン100万件あたり15ドルで利用できます。コンテキスト制限は131,072トークンです。 現在利用可能なのはgrok-betaモデルのみで、OpenAIやAnthropicのSDKと互換性があり、Python、JavaScript、Goなど主要なプログラミング言語をサポートしています。 xAIは、テネシー州メンフィスの「Colossus」という世界最大級のAIトレーニングシステム（10万台のNVIDIA H100 GPU、将来的には20万台規模に拡張予定）を用いてGrokを開発しており、その処理能力は10.6エクサフロップスを超えると推測されています。推定投資額は40億ドル以上とされています。 Grokは既存モデルとは異なる「反抗的な性質」を持つ点が特徴です。 API価格は競合他社と比較してやや高めですが、Xプラットフォームのリアルタイムデータを利用した学習モデルという独自性があります。開発者は、この新しいAPIを用いて革新的なアプリケーション開発に挑戦できます。 環境への影響も懸念されており、今後の大規模化には配慮が必要となります。 xAIの公式サイトでAPIドキュメント等を確認できます。 引用元: https://innovatopia.jp/ai/ai-news/44493/ Updated production-ready Gemini models, reduced 1.5 Pro pricing, increased rate limits, and more Googleは、本番環境対応のGeminiモデルを2種類更新し、Gemini-1.5-Pro-002とGemini-1.5-Flash-002をリリースしました。今回のアップデートでは、以下の改善がなされています。 価格改定: Gemini 1.5 Proの入力・出力トークン価格が50%以上削減されました(128Kトークン未満)。 レート制限の増加: Gemini 1.5 Flashは2倍、1.5 Proは約3倍、レート制限が向上しました。 パフォーマンス向上: 出力速度が2倍、レイテンシが3倍低減されました。 モデル品質の向上: 数学、ロングコンテキスト、ビジョン処理において、大幅な性能向上を実現しました。MMLU-Proベンチマークで約7%、MATHとHiddenMathベンチマークで約20%の改善が見られました。コード生成や画像理解でも2～7%の性能向上を確認しています。レスポンスの簡潔性も向上し、より多くの情報を効率的に取得できます。 デフォルトフィルター設定の更新: セキュリティと信頼性を向上させつつ、開発者が用途に最適な設定を選択できるように、デフォルトではフィルターが適用されなくなりました。 これらのモデルは、Google AI Studio、Gemini API、Vertex AIを通じてアクセス可能です。特にGemini 1.5 Proは、最大200万トークンのロングコンテキストウィンドウとマルチモーダル機能を活用した、様々な用途への応用が期待されています。 より高速でコスト効率の良い開発が可能になり、より多くの開発者がGeminiを活用できる環境が整いました。 今後、Gemini APIのレート制限もさらに引き上げられる予定です。 Gemini-1.5-Flash-8B-Exp-0924という実験的なモデルもリリースされており、テキストとマルチモーダル用途での性能向上が図られています。 今回のアップデートは、既存ユーザーにとっても、新規参入者にとっても、より使いやすく、コスト効率の良い開発環境を提供するものと言えます。 詳細については、関連するGoogleのドキュメントを参照ください。 引用元: https://7a0e920-dot-gdm-deepmind-com-prod.appspot.com/discover/blog/updated-production-ready-gemini-models-reduced-15-pro-pricing-increased-rate-limits-and-more/ iOS 18.2 beta adds ‘Upgrade to ChatGPT Plus’ option in Settings app - 9to5Mac iOS 18.2ベータ版で、設定アプリ内にChatGPT Plusへのアップグレードオプションが追加されました。これは、iOS 18.2に搭載されたSiriとAIライティングツールへのChatGPT統合の一環です。 iOS 18.2では、システム全体でOpenAIのアシスタントがSiriの代替として機能し、既存のAppleのライティングツールを補完する形でChatGPTが統合されています。 AppleとOpenAIは、このChatGPT統合において、アップグレードしたユーザーからの収益を共有する合意を結んでいるようです。 設定アプリから「Apple IntelligenceとSiri」→「ChatGPT」を選択することで、「ChatGPT Plusにアップグレード」オプションが表示されます。ChatGPTの統合は無料アカウントでも利用可能ですが、有料アカウント（ChatGPT Plus、月額19.99ドル）にアップグレードすることで、以下の追加機能を利用できます。 GPT-4へのメッセージ送信回数5倍増加、さらに高度なモデルへのアクセス 写真やファイルのアップロード、画像生成、ウェブブラウジングの上限値の引き上げ ChatGPTの高度な音声モードによる、より自然でリアルタイムな会話 無料プランではChatGPTの使用に制限があり、設定アプリで制限状況を確認できます。 有料版のChatGPT Plusの全機能リストはOpenAIのウェブサイトで確認可能です。 本記事では、ChatGPT Plusへのアップグレードオプションの提供について、読者の意見を求めています。 引用元: https://9to5mac.com/2024/11/04/ios-18-2-beta-adds-upgrade-to-chatgpt-plus-option-to-the-settings-app/ お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

関連リンク OmniGen: Unified Image Generation 本論文は、統一的な画像生成を行う新しい拡散モデル「OmniGen」を紹介しています。既存のStable Diffusionなどの拡散モデルは、ControlNetやIP-Adapterといった追加モジュールを必要とするのに対し、OmniGenはそれらを必要としません。 OmniGenの主な特徴は以下の3点です。 統一性: テキストからの画像生成だけでなく、画像編集、被写体駆動型生成、視覚条件付き生成といった様々な下流タスクを内包的にサポートします。さらに、エッジ検出や人物姿勢認識といった古典的なコンピュータビジョンタスクも、画像生成タスクに変換して処理できます。 シンプルさ: 追加のテキストエンコーダを必要としない簡素化されたアーキテクチャを採用しており、既存の拡散モデルと比較してユーザーフレンドリーです。複雑なタスクも、事前処理（例：人物姿勢推定）なしに指示だけで実行でき、画像生成のワークフローを大幅に簡素化します。 知識転移: 統一的なフォーマットで学習することで、異なるタスク間での知識転移が効果的に行われ、未知のタスクやドメインにも対応し、新たな能力を示します。また、モデルの推論能力と、思考連鎖機構の潜在的な応用についても検討されています。 OmniGenは、汎用的な画像生成モデルへの最初の試みであり、解決すべき課題も残されています。関連リソースはGitHub (このURL - 本要約ではURLへのアクセスは行いません)で公開される予定です。 これは、この分野の進歩を促進することを目的としています。 新人エンジニアの皆さんにとって、OmniGenは様々な画像生成タスクをシンプルに処理できる強力なツールとなる可能性を秘めていると言えるでしょう。 引用元: https://arxiv.org/abs/2409.11340 New Paper Co-authored by Tepper School Researchers Articulates How Large Language Models Are Changing Collective Intelligence Forever - Tepper School of Business - Carnegie Mellon University カーネギーメロン大学のテッパービジネススクールなどの研究者らが執筆した論文が、Nature Human Behavior誌に掲載されました。この論文は、大規模言語モデル（LLM）が集団知能に与える影響について論じています。 集団知能とは、多くの人々の協調、共同作業、競争から生まれる共有された知能であり、合意形成的な意思決定に現れます。論文では、LLMが集団知能をどのように変革するか、その可能性とリスクの両方を強調しています。 LLMは、情報収集とコミュニケーションを促進することで、グループの協調と意思決定を向上させる可能性を秘めています。例えば、異なるバックグラウンドや言語を持つ人々のコミュニケーションを容易にし、より効果的なコラボレーションを可能にします。多様な意見をスムーズに共有することで、より包括的で生産性の高いオンライン交流を促進するのです。 しかし、LLMには課題もあります。一つは、LLMが利用可能なオンライン情報から学習するため、少数派の意見を見落としたり、一般的な意見を強調したりすることで、誤った合意を生み出す可能性があることです。もう一つは、オンライン上の情報には誤った情報や誤解を招くデータが含まれていることが多く、LLMが適切に管理されない場合、それらを拡散してしまう可能性がある点です。データの正確性を確保するための綿密な監視と定期的な更新が不可欠であり、責任あるLLMの利用が、集団的意思決定における誤った結果を避けるために重要になります。 研究者らは、特に政策決定や公共討論において、LLMの倫理的および実践的な意味合いをさらに探求する必要性を強調しています。 LLMを責任ある方法で使用するためのガイドラインの開発を提唱しており、集団知能を支援しながら、個人の多様性と表現を維持することを目指しています。 この論文は、LLMが集団知能に与える大きな影響と、その活用における慎重な考慮の必要性を改めて示しています。 引用元: https://www.cmu.edu/tepper/news/stories/2024/september/collective-intelligence-and-llms.html ほぼリアルタイム！？爆速で動作する日本語特化の文字起こしAI！『kotoba-whisper-v2.0』 この記事は、Kotoba Technologiesが開発した日本語特化の音声認識モデル「kotoba-whisper-v2.0」を紹介しています。OpenAIのWhisper大型モデルを蒸留技術で最適化することで、同等の精度を維持しつつ、推論速度を約6.3倍高速化を実現しています。 kotoba-whisper-v2.0のメリット: 高速処理: 特に長時間の音声データ処理において、OpenAIのWhisper large-v2と比較して約6倍高速です。短い音声データでは約10秒、20分の音声データでも約3分で処理できます。 高精度: 日本語に特化してトレーニングされており、専門用語や日常会話のニュアンスも正確に捉えます。OpenAIのWhisper large-v2と同等かそれ以上の精度を誇ります。 ローカル環境での動作: クラウドにデータを送信する必要がないため、セキュリティ面で安心です。機密情報の取り扱いが必要な企業や組織に最適です。 無料利用可能: Hugging Faceで公開されており、誰でも無料で利用できます。 技術的な概要: Whisper large-v3を教師モデルとして、蒸留技術を用いて開発されました。日本語話者特化のリソースであるReazonSpeechを用いて、約720万の音声クリップでトレーニングされています。 Flash Attention 2を用いることで更なる高速化が可能です。 環境構築 (概要): NVIDIA GeForce RTXシリーズGPU(推奨)、16GB以上のメモリ、Python 3.8以上が必要です。必要なライブラリはpipコマンドでインストールできます。 まとめ: kotoba-whisper-v2.0は、高速性と高精度を両立した日本語音声認識モデルです。ローカル環境で動作する安全性も魅力で、大量の音声データ処理やセキュリティを重視する場面で非常に有効なツールと言えます。 新人エンジニアへの補足: このモデルは、既存のWhisperモデルを改良したもので、特に日本語の音声認識に特化しています。高速処理は、大量の音声データの処理時間を大幅に削減し、開発効率の向上に貢献します。また、ローカル環境での動作は、データセキュリティの観点から非常に重要です。 環境構築は、一般的なPython環境とGPUがあれば比較的容易に実行できます。 記事では具体的なコード例も掲載されているので、それを参考にしながら試してみることをお勧めします。 引用元: https://qiita.com/ryosuke_ohori/items/9634c1fd8a9cc9ff7c36 お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

関連リンク Gemini in Android Studio, now helping you across the development lifecycle Android Studioに搭載されたAIコーディングアシスタント「Gemini」の大規模アップデートがリリースされました。今回のアップデートでは、開発ライフサイクルの全段階でAIを活用できるようになり、生産性の向上に大きく貢献します。 主な新機能は以下の通りです。 1. コード編集・改善機能: Gemini Code Transforms: プロンプトによるコードの修正やリファクタリングが可能になります。複雑なコード変更も簡単に実行できます。 コミットメッセージ生成: コード変更を分析し、適切なコミットメッセージを自動生成します。バージョン管理の効率化に役立ちます。 Rethink and Rename: クラス、メソッド、変数名の変更を支援します。より直感的で分かりやすい名前に変更できます。 プロンプトライブラリ: よく使うプロンプトを保存・管理できます。再利用することで作業時間を短縮できます。 ドキュメント生成: 選択したコードスニペットのドキュメントを簡単に生成できます。コードの可読性向上に役立ちます。 2. UI開発支援機能: Composeプレビューの自動生成: Composeを使ったUI開発において、プレビューに必要なモックデータを自動生成します。UIデザインの確認を迅速化できます。 マルチモーダル対応（近日公開予定）: 画像をコンテキストとして利用できるようになり、より直感的なUIデザインが可能になります。 3. アプリ品質向上機能: 単体テストシナリオ生成: ローカルのコードコンテキストに基づいて、単体テストのシナリオを自動生成します。テスト作成の負担を軽減できます。 ビルド/同期エラー分析: ビルドや同期エラーに関する分析機能が強化されました。エラー解決の時間を短縮できます。 App Quality Insightsの機能強化: Google Play ConsoleとFirebase Crashlyticsから報告されたクラッシュに関する分析と修正提案機能が強化され、ローカルコードコンテキストも活用できるようになりました。バグ修正の迅速化につながります。 GeminiはAndroid StudioのCanaryチャンネルで利用可能です。多くの機能は年末にリリースされるLadybug Feature Dropで安定版チャンネルにも提供される予定です。 制約事項: Geminiの開発支援機能を利用するには、ソースコードをサーバーに送信することに同意する必要があります。GoogleはAIの責任ある利用に尽力しており、ユーザーのプライバシー保護にも配慮しています。詳細については、提供されているプライバシーに関するドキュメントを参照ください。 新人エンジニアの皆さんにとって、GeminiはAndroidアプリ開発における強力な味方となるでしょう。ぜひ活用して、効率的な開発を目指してください。 引用元: https://android-developers.googleblog.com/2024/10/whats-new-in-gemini-in-android.html Playwrightを参考にブラウザ内テキスト検索を高速化する (事例紹介:サードパーティスクリプト提供会社) 本事例は、サードパーティスクリプト提供会社(社名は非公開)におけるブラウザ内テキスト検索の高速化プロジェクトの報告です。 既存のブラウザ自動操作技術(E2Eテスト応用)では、テキスト検索が遅いため、Playwrightのコードを参考に高速化を図りました。 まず、PlaywrightのChrome拡張機能からテキストセレクタ生成コード(InjectedScript)を移植・調査しました。Playwrightは独自のセレクタを用いてテキスト検索を実現しており、DOM全体を走査してテキストインデックスを作成していました。このインデックス作成と、DOM変更監視のためのMutationObserverが、パフォーマンスボトルネックとなっていました。 計測にはDevToolsのPerformanceタブを使用し、特にJavaScriptタスクの処理時間をBottom-Up表示で分析しました。その結果、lodash.isElementによる要素判定(約9ms)と、PlaywrightのelementText関数によるテキストインデックス作成(約13ms)が問題点として浮上しました。 lodash.isElementについては、el instanceof HTMLElementに置き換えることで、不要なオブジェクト走査を排除し、処理時間をゼロに削減しました。これは、lodashがIE時代のレガシーコードを含み、現代の環境ではオーバーヘッドとなることを示しています。 elementText関数については、DOM走査にdocument.createTreeWalkerを使用することで大幅な高速化を実現しました。createTreeWalkerは、従来のforループによるDOM走査に比べて10倍以上の速度向上を示すベンチマーク結果も確認しています。 さらに、検索クエリを事前に把握していることを活かし、検索クエリに完全一致するテキストノードのみを抽出することで、インデックス処理時間を2ms、検索時間を0.1msにまで短縮しました。 本プロジェクトを通して、以下の知見を得ました。 木構造のトラバースは遅い。document.createTreeWalkerを用いることで高速化できる。 ライブラリ関数は、過剰な汎用性によりパフォーマンスを低下させることがある。必要に応じて、より制約の強い実装に置き換えることで高速化できる。 現代のフロントエンド開発では、DOM操作のコストを意識することが重要である。 本事例は、既存のライブラリを適切に活用し、パフォーマンスボトルネックを特定・解決することで、ブラウザ内テキスト検索を大幅に高速化できたことを示しています。 特に新人エンジニアにとって、DevToolsによるパフォーマンス計測と、ライブラリ関数の適切な選択・改良の重要性を示唆する事例となっています。 引用元: https://zenn.dev/mizchi/articles/fast-dom-text-search Pythonプロジェクトでflat layoutではなくsrc layoutが推奨される理由を理解する Pythonプロジェクトのディレクトリ構成には、パッケージをプロジェクトルート直下に置くflat layoutと、srcサブディレクトリに置くsrc layoutの2種類があります。多くのPythonプロジェクトではsrc layoutが推奨されています。その理由は、テストの安全性にあります。 flat layoutでは、Pythonインタプリタがカレントディレクトリをインポートパスの先頭に置くため、開発中のコードが誤ってインポートされる可能性があります。例えば、テストコードがまだパッケージに含まれていない開発中の関数を呼び出してしまうと、テストが通ってしまい、潜在的なバグを見逃す危険性があります。 一方、src layoutでは、パッケージはsrcディレクトリ内に配置され、ビルド時にパッケージ化されます。テストを実行する際には、ビルド済みのパッケージが使用されるため、開発中のコードが誤って実行されることはありません。テストは、実際にリリースされるコードに対して行われるため、より信頼性の高いテスト結果が得られます。 記事では、flat layoutとsrc layoutでそれぞれパッケージを作成し、テストを実行する実験が行われています。その結果、flat layoutでは開発中のコードが意図せず使用され、テストが誤って成功するケースが確認されました。src layoutでは、開発中のコードが使用されず、テストが適切に失敗することで、問題を早期に発見できることが実証されました。 ただし、多くの著名なPythonプロジェクト(pandas、numpy、scikit-learnなど)はflat layoutを採用しています。これは、テスト方法やプロジェクトの規模、開発スタイルなど、様々な要因が影響していると考えられます。src layoutはテストの安全性という点で優れていますが、プロジェクトの状況に応じてflat layoutを選択することもあります。 新人エンジニアとして、Pythonパッケージ開発を始める際には、src layoutを採用することで、テストの信頼性を高め、バグを早期に発見できる可能性が高まります。 flat layoutとsrc layoutのそれぞれのメリット・デメリットを理解し、プロジェクトの状況に合わせて適切な構成を選択することが重要です。 本記事は、src layoutの利点を理解するための良い例題となっています。 GitHubリポジトリには、flat layoutとsrc layoutの具体的な実装例とテストコードが公開されているので、ぜひ参照して理解を深めてください。 引用元: https://nsakki55.hatenablog.com/entry/2024/10/28/095509 お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

関連リンク Gemini Models on GitHub Copilot Google CloudとGitHubのパートナーシップにより、GitHub CopilotにGeminiモデルが導入されます。 まず、Gemini 1.5 Proが利用可能になり、今後数週間以内にCopilotユーザーは利用できるようになります。 Gemini 1.5 Proは、コード生成、分析、最適化といった開発者にとって一般的なユースケースに優れています。最大200万トークンという長いコンテキストウィンドウを備えているため、10万行以上のコードを処理し、修正案の提案やコードの動作説明を行うことが可能です。 GitHub Copilotの新しいモデル選択機能を通じて、Gemini 1.5 Proを選択できるようになります。利用可能なプラットフォームは、github.com、Visual Studio Code、Visual Studio向けのCopilot拡張機能などです。 Copilot ChatでもGemini 1.5 Proを使用できます。 これは、開発者がニーズに最適なモデルを選択できる柔軟性と制御性を重視する姿勢を示しており、AIによるコード生成の次の段階は、単一モデルではなく、複数のモデルから選択できるようになることを意味します。 Geminiモデルは、Gemini API、Google AI Studio、Vertex AI、Google Cloud、Workspace、Android Studio、Firebase、Colabなど、多くの主要なプラットフォームや環境で開発者エクスペリエンスをサポートしています。Google独自のコード支援ツールであるGemini Code Assistも、Visual Studio CodeやJetBrains IDEなど、一般的な統合開発環境(IDE)で利用可能です。 本発表は、開発者にとって多様な選択肢を提供する重要な一歩であり、今後、より高度で効率的なコード開発を支援する技術革新が期待されます。 新人エンジニアにとっても、様々な環境で利用可能なGeminiモデルとGitHub Copilotの連携は、開発効率の向上に大きく貢献するでしょう。 引用元: https://cloud.google.com/blog/products/ai-machine-learning/gemini-models-on-github-copilot Creating a LLM-as-a-Judge That Drives Business Results – 本記事は、LLM（大規模言語モデル）を用いてAIシステムの評価を行うための実践的なガイドです。AI開発チームが抱えるデータ量増加や、曖昧な評価指標による非効率性といった問題を解決する手法として、「Critique Shadowing（批評による影付け）」という手法を紹介しています。これは、LLMを「判定者」として活用し、AI出力の評価を効率化する方法です。 問題点: 多くのAIチームは、多数の指標を用いた複雑な評価システムに苦戦しています。指標が多すぎたり、評価尺度が曖昧であったり、ドメイン専門家の知見が活用されていなかったりすることで、信頼できるデータが得られず、開発の進捗が滞ることが多々あります。 解決策: Critique Shadowingでは、以下のステップでLLMを「判定者」として活用します。 ステップ1：主要ドメイン専門家の特定: AI製品の成功に不可欠な専門知識を持つ人物（複数でも可）を特定します。この専門家は、技術的な側面だけでなく、ユーザーニーズの観点からも評価を行います。 ステップ2：データセットの作成: AIが本番環境で遭遇する様々な状況を網羅したデータセットを作成します。これは、AIの機能（Feature）、想定される状況（Scenario）、ユーザー像（Persona）といった次元で構成されます。既存データとLLMを用いた合成データの両方を活用することが推奨されます。 ステップ3：パス/フェイル判定と批評: 主要ドメイン専門家は、AIの出力に対して「パス」または「フェイル」の判定を行い、その理由を詳細に記述した批評を作成します。複雑な数値評価ではなく、単純な二値判定が、重要な点を明確にする上で有効です。批評はLLM判定器のプロンプト作成に必須です。 ステップ4：エラー修正: データセットのレビューを通じてAIシステムのエラーが発見された場合は、修正してから次のステップに進みます。 ステップ5：LLM判定器の構築: 主要ドメイン専門家による判定結果と批評を基に、LLM判定器のプロンプトを構築します。専門家の判定とLLM判定器の判定結果の一致率を高めるために、プロンプトを繰り返し改良します。 ステップ6：エラー分析: LLM判定器を用いて評価した結果、エラー率の高い領域を特定し、その原因を分析します。これにより、AIシステムの改善に集中すべき点を明確にできます。 ステップ7：専門的なLLM判定器の作成（必要に応じて）: エラー分析の結果に基づき、必要に応じて特定のエラーに焦点を当てた専門的なLLM判定器を作成します。 重要なポイント: この手法の真の価値は、データの精査と分析にあります。LLM判定器は、データ分析を促すためのツールと捉えるべきです。 また、本手法は、状況に応じて柔軟に適用できることを理解しておくことが重要です。 本記事では、各ステップの詳細な手順やLLMプロンプト例、よくある質問への回答などが示されていますが、本要約では簡潔に概要を説明しました。より詳細な情報は、元記事を参照ください。 引用元: https://hamel.dev/blog/posts/llm-judge/ LlamaPReview - GitHub Marketplace LlamaPReviewは、GitHubのプルリクエスト(PR)を自動的にレビューするAIアシスタントです。GitHub Marketplaceで提供されており、ワンクリックインストールで簡単に導入できます。現在、無料で利用可能です。 主な機能は以下の通りです。 完全自動化されたレビュー: PR作成時に自動的にレビューを行い、包括的なコメントを投稿します。設定不要で、すぐに利用できます。 高度なコード理解: 単なるコードスキャンではなく、リポジトリ全体のコンテキストを理解し、構文エラーから複雑な論理的な欠陥まで、潜在的な問題を特定します。コード間の関係性や依存関係も考慮に入れた分析を行います。 多言語対応: JavaScript、C++、Python、PHP、Java、Scala、Go、Rust、Kotlin、TypeScriptなど、主要なプログラミング言語をサポートしています。 無料利用: クレジットカード情報などの入力は不要で、全ての機能を無料で利用できます。 LlamaPReviewは、シニアエンジニアによるレビューのような詳細なフィードバックを提供することで、コードの品質向上に貢献します。GitHub Actionsとの統合も可能で、CI/CDパイプラインへのシームレスな組み込みを実現できます。 新人エンジニアにとっても、学習コストが低く、効率的なコードレビューを行う上で非常に有用なツールと言えます。 無料であるため、気軽に試してその効果を実感できます。 引用元: https://github.com/marketplace/llamapreview お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

関連リンク GitHub - Integuru-AI/Integuru: An AI agent that builds third-party integrations through reverse engineering platforms internal APIs. Integuruは、プラットフォームの内部APIをリバースエンジニアリングすることで、統合コードを生成するAIエージェントです。ブラウザのネットワークリクエストを記録したHARファイルと、実行したいアクションを記述したプロンプトを入力すると、そのアクションを実行するPythonコードを出力します。 具体的には、ユーザーがブラウザでアクションを実行した際のネットワークリクエストを分析し、依存関係グラフを生成します。このグラフは、目的のアクションに必要なリクエストとその依存関係を示しています。 例えば、請求書のダウンロードをしたい場合、アカウントIDやユーザーIDを取得するリクエストが依存関係としてグラフ上に表現されます。Integuruは、このグラフを辿りながら、各リクエストをPython関数に変換し、最終的に目的のアクションを実行する統合コードを生成します。 必要な設定としては、OpenAI APIキーの設定と、Poetryを用いたPython依存関係のインストールです。 create_har.pyスクリプトを用いてブラウザのネットワークリクエストを記録し、integuruコマンドを実行することで、コード生成が可能です。 生成されたコードは、プラットフォームの内部エンドポイントを呼び出して、指定したアクション（例えば、請求書のダウンロード）を実行します。 Integuruは、リクエストの依存関係グラフの生成、入力変数のサポート（コード生成への対応は近日予定）、コード生成機能を備えています。 現状、GPT-4相当以上のOpenAIモデルの使用が推奨されています。 このプロジェクトはオープンソースであり、貢献も歓迎されています。 開発元であるInteguru.aiは、カスタムインテグレーションや追加機能の開発、ホスティング、認証サービスも提供しています。 本要約は、GitHubリポジトリの概要と制約事項に焦点を当て、使用方法等の詳細は省略しています。 新人エンジニアにも理解しやすいよう、平易な言葉で説明しています。 引用元: https://github.com/Integuru-AI/Integuru How the New Raspberry Pi AI HAT Supercharges LLMs at the Edge この記事は、ラズベリーパイ用の新しいAIアクセサリハット（AI HAT）が、エッジデバイス上で大規模言語モデル（LLM）の性能を大幅に向上させる方法について説明しています。 Novusteck社によるこのAI HATは、エッジコンピューティングにおけるLLMの実用化を促進する重要な技術革新です。 具体的な機能や使用方法の詳細については記事本文を参照いただくとして、本要約では概要と制約事項に焦点を当てます。 このAI HATは、限られたリソースを持つラズベリーパイのような小型デバイスでも、複雑なLLMを効率的に実行できるように設計されています。 これにより、電力消費や計算能力の制約から、これまでエッジでのLLM活用が困難だった様々なアプリケーションが可能になります。例えば、リアルタイム翻訳、音声認識、画像認識といったタスクを、クラウドに依存することなく、デバイス上で直接処理できるようになります。 ただし、このAI HATの使用にはいくつかの制約があると考えられます。 記事では明示的に記載されていないかもしれませんが、想定される制約として、処理できるLLMのサイズや複雑さには限界があること、リアルタイム処理に必要なデータ転送速度やメモリ容量の制限があることなどが挙げられます。 また、特定のLLMフレームワークやソフトウェアライブラリとの互換性、必要なセットアップ手順の複雑さなども、利用上の制約として考慮すべき点です。 本AI HATは、エッジAI分野における革新的な技術であり、IoTデバイスや組み込みシステムにおけるLLMの応用範囲を大きく広げると期待されます。 しかし、導入にあたっては、上記のような制約事項を十分に理解し、プロジェクトの要件に合致するかを慎重に検討する必要があります。 より詳細な仕様や使用方法については、記事本文やNovusteck社のウェブサイトを参照することをお勧めします。 新人エンジニアの皆さんは、このAI HATの可能性と同時に、その制約も理解した上で、適切なプロジェクトへの適用を検討してください。 引用元: https://blog.novusteck.com/how-the-new-raspberry-pi-ai-hat-supercharges-llms-at-the-edge AI Overviews in Search are coming to more places around the world Google検索のAI概要表示機能が、100カ国以上に拡大されました。これにより、世界中の10億人を超えるユーザーが毎月この機能を利用できるようになります。日本語を含む複数の言語に対応し、ユーザーはより簡単に必要な情報を見つけ、関連性の高いウェブサイトを発見できるようになります。 この機能は、5月に米国でローンチされ、8月には米国以外への展開が行われました。ユーザーからのフィードバックは非常に肯定的で、検索結果の有用性が向上したと評価されています。今回の拡大により、より多くの国と言語でAI概要表示機能が利用可能になり、検索体験全体が向上します。 AI概要表示機能では、関連するウェブサイトへのリンクがより目立つように表示され、デスクトップとモバイルの両方でアクセスしやすくなっています。 これにより、パブリッシャー、企業、クリエイターとの連携機会も拡大します。広告はページ内の専用枠に表示され、オーガニック検索結果との明確な区別が維持されます。米国ではモバイルユーザー向けの関連クエリでAI概要表示機能内の広告が利用可能になり、ユーザーと製品・ブランドのマッチングが向上しています。 Googleは、AI概要表示機能以外にも、さまざまな質問への対応やオンラインコンテンツの探索を容易にするためのAI搭載機能の強化を継続しています。 引用元: https://blog.google/products/search/ai-overviews-search-october-2024/ お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

関連リンク ドメインモデリングで全システムの設計をゼロからやり直す。リアーキテクチャに挑む2年間の全貌【モノタロウCTO普川】 レバテックラボ（レバテックLAB） モノタロウ社は、20年以上に渡り運用してきたレガシーシステムの限界を迎え、2022年から大規模なリアーキテクチャに着手しました。 パッケージシステム導入の失敗を経て、ドメインモデリングに基づいた内製開発による抜本的なシステム刷新を選択。マイクロサービス化と業務ドメインの分割統治を目指し、ドメイン駆動設計を参考にしながら、地道な取り組みを2年間継続しています。 リアーキテクチャ開始前には、経営層との丁寧な合意形成が最優先事項でした。 長期的な投資と、新しい開発手法への理解を深めるため、エンジニアへの綿密な説明と「テックプリンシプル」の設定を行いました。 さらに、逆コンウェイ戦略に基づき、理想アーキテクチャに合わせた組織改編を2年かけて実施。CTO直下の「CTOオフィス」と既存業務との兼務チームを編成し、情報共有とスムーズな開発体制構築を目指しました。 リアーキテクチャの具体的なプロセスは、まず「イベントストーミング」による業務フローの明確化から始まりました。関係者全員参加のもと、付箋を用いたワークショップを実施し、業務全体の流れを把握する「ビッグピクチャー」を作成。その後、各業務領域を詳細に分析し、「プロセスモデル」とドメイン境界を可視化する「コンテキストマップ」を作成しました。 このドメインモデリングを経て、ようやくソフトウェア設計に着手。1つのドメインモデルの完成には3～4ヶ月を要します。 ドメインモデリングでは、「在庫ドメイン」のように複雑な領域は徹底的に分析する一方、「受注ドメイン」のように過去の事例が豊富な領域はデータ分析を簡略化するなど、コストと精度のバランスを考慮しながら進めています。 しかし、どのプロセスを簡略化できるかの判断は非常に難しく、経験と状況判断に基づいた柔軟な対応が求められます。 現在もリアーキテクチャは進行中で、終わりは見えていません。 メンバーからは不安の声も上がっていますが、CTOは技術スタック刷新だけでは不十分であり、業務構造の根本的な見直しこそが競争優位性を生むと確信し、取り組みを継続しています。 長期間にわたる困難なプロジェクトですが、モノタロウ社の事業成長に大きく貢献する取り組みとして、関係者全員で取り組んでいる最中です。 引用元: https://levtech.jp/media/article/interview/detail_545/ Flux + Helm における即時ロールバック クックパッドのレシピサービスグローバル版統合に伴い、日本版のECS環境からグローバル版のEKS環境への移行が発生しました。グローバル版ではFluxとHelmを用いたGitOpsによる自動デプロイを採用していますが、従来のリバートによるロールバックでは、CIテストのオーバーヘッドや承認プロセスにより、障害発生時の迅速な復旧が困難でした。具体的には、ロールバックに40分程度要するケースもあったため、即時ロールバックの仕組み構築が急務となりました。 既存のGitOpsフローでは、イメージ更新はFluxのImage Update Automation機能が検知し、マニフェストリポジトリへの更新、KustomizeとHelm Controllerによるクラスタへの反映という流れです。リバートによるロールバックはGitOpsフローに則っていますが、時間がかかりすぎます。そこで、Helm Controllerによるhelm upgradeを待たずにロールバックを実行する独自の方法を導入しました。 即時ロールバックを実現するため、Helmのリビジョン管理機能を利用したhelm rollbackコマンドを採用しました。これは、HelmReleaseの同期を一時的に停止し、helm rollbackコマンドで直接Helmリリースを以前のリビジョンに復元する手法です。これにより、helm upgradeの完了を待たずにロールバックを開始でき、数分以上かかっていた復旧時間を大幅に短縮しました。 しかし、helm rollbackコマンドの実行には特別な権限が必要であり、開発者へ権限を与えるのは適切ではありません。そこで、SlackのChatOpsコマンド/laboty global-web-platform rollback {アプリケーション名} {ロールバック先のコミットハッシュ}を実装しました。このコマンドは、開発者が指定したコミットハッシュから対応するHelmリリースのリビジョンを自動的に特定し、FluxのHelmReleaseとAlertの同期を一時停止した後、helm rollbackを実行します。 さらに、ロールバック後の自動デプロイ再開のため、 /laboty global-web-platform recover-from-rollback {アプリケーション名} {回復したコミットハッシュ}コマンドも実装しました。このコマンドは、回復したコミットハッシュに対応するイメージがHelmReleaseに反映されていることを確認した後、FluxのHelmReleaseとAlertの同期を再開します。 これらのChatOpsコマンドにより、開発者は簡潔なコマンドで即時ロールバックと復旧を実行できるようになり、障害発生時の迅速な対応とサービス継続性が向上しました。 この仕組みは、障害対応の迅速化だけでなく、開発における迅速なイテレーションにも貢献すると期待されます。 引用元: https://techlife.cookpad.com/entry/2024/10/28/204340 【図解ハンズオン】たった60分でReactを使った音楽プレイヤーを作ろう！【TypeScript/Shadcn/TailwindCSS】 この記事は、React、TypeScript、Shadcn、Tailwind CSSを使って、約60分で音楽プレイヤーを作成するハンズオントレーニングの概要を説明しています。React初心者で、HTMLの経験があり、JavaScriptとTypeScriptを学びたいエンジニアを対象としています。 ハンズオンでは、まずNode.jsとViteを用いたReactプロジェクトの構築方法を説明します。Viteは高速な次世代ビルドツールです。 npm create viteコマンドを使い、ReactとTypeScriptを選択してプロジェクトを作成します。その後、npm iで依存パッケージをインストールし、npm run devで開発サーバーを起動します。 次に、UIコンポーネントライブラリであるShadcnと、その基盤となるCSSフレームワークTailwind CSSを導入します。npm installコマンドで必要なパッケージをインストールし、tailwind.config.jsとsrc/index.cssを編集してTailwind CSSを設定します。 src/App.tsxを修正することで、Tailwind CSSが正しく動作することを確認します。 記事では、具体的なコード例と実行結果のスクリーンショットが掲載されており、環境構築からTailwind CSSの導入、動作確認までをステップバイステップで解説しています。 ただし、音楽プレイヤーの具体的な実装方法や機能に関する詳細は、本文からは省略されています。 本ハンズオンは、React環境構築とShadcn、Tailwind CSSの導入を理解することを主眼としています。 音楽プレイヤーの実装方法は、別途動画教材で詳細に解説されているようです。 本記事は、React環境構築と主要ライブラリの導入手順を理解するための入門として最適です。 引用元: https://qiita.com/Sicut_study/items/a27fb53468e14216d6fb お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

関連リンク Coinbase Launches Autonomous On-chain Agent Framework for Base Blockchain Coinbaseは、Baseブロックチェーン上で動作するAI搭載の自律型オンチェーンエージェント作成を容易にする新しいフレームワーク「Based Agent」を発表しました。このフレームワークを使用すると、わずか3分程度で、取引、スワップ、ステーキングなど、様々なオンチェーン操作を実行できるAIエージェントを簡単に作成できます。 CoinbaseのプロダクトマネージャーであるLincoln Murr氏によると、Based Agentは、特定のタスクを実行するように設計された自動プログラム（AI駆動型ボット）を開発するためのシンプルなテンプレートを提供します。 エージェントはスマートコントラクトと連携し、取引管理、スワップ実行、Baseドメイン名の登録なども行えます。 Based Agentは、Coinbaseの開発者向けプラットフォームSDK、OpenAI（ChatGPT開発元）のSDK、そしてAI駆動型のソフトウェア開発・展開プラットフォームReplitを使用して構築されています。 利用開始には、CoinbaseとOpenAIからAPIキーを取得し、Replitのテンプレートをフォークするだけで、その後は必要な機能を追加していくことができます。 Mode Networkの創設者であるJames Ross氏は、今後6～12ヶ月以内に、ブロックチェーン取引の80％以上がAIエージェントによって管理されるようになると予測しており、Based Agentはその実現を加速させる可能性を秘めています。 GitHubリポジトリも公開されているため、詳細な技術仕様はそちらを参照できますが、本フレームワークは開発者にとって、Baseブロックチェーン上でのAI活用を大幅に簡素化する革新的なツールと言えるでしょう。 引用元: https://www.cryptoglobe.com/latest/2024/10/coinbase-launches-autonomous-on-chain-agent-framework-for-base-blockchain/ Claude AIがブラウザ内でJavaScript実行可能に！コード不要のデータ分析ツールで業務効率化へ前進 - イノベトピア Anthropic社は、AIチャットボット「Claude」に新たなデータ分析ツールを実装しました。このツールの最大の特徴は、ブラウザ上で直接JavaScriptコードを実行できる点です。従来、AIによるコード生成後、別途実行環境が必要でしたが、Claudeはそれを不要にしました。 CSVやPDFファイルの分析、インタラクティブなグラフ作成を、プログラミング知識がなくても直感的に行えるようになっています。 具体的には、Web Worker技術を用いて、ブラウザ上で安全にJavaScriptを実行する仕組みを採用しています。これは、Pythonベースのサーバーサイド実行を採用する他のAIツールとは異なるアプローチです。 性能向上も著しく、Claude 3.5 Sonnetのプログラミング性能はSWE-Bench Verifiedテストで33.4%から49.0%に向上、TAU-benchテストでも小売・航空分野でそれぞれ大幅な性能向上を示しました。 現在、Claude.aiの全ユーザーがプレビュー機能として利用可能です。ただし、アップロードファイルサイズや扱えるファイルの種類に制限があり、セキュリティ面も考慮が必要な点に注意が必要です。 機密データの取り扱いには慎重な検討が求められます。 この機能は、AIアシスタントを単なるチャットボットから、誰でも使える実用的なデータ分析ツールへと進化させる可能性を秘めています。特に、プログラミングスキルに乏しいビジネスユーザーにとって、データに基づいた意思決定を支援する強力なツールとなることが期待されます。 今後のアップデートで、機能拡張や大規模データ処理への対応などが予定されています。 引用元: https://innovatopia.jp/ai/ai-news/44081/ 生成AI/LLMを使ったウェブサイト開発 週末に、はてな匿名ダイアリーの「最も重要なマンガ10選」をまとめたリンク集ウェブサイトを、生成AI/LLMツールを駆使して開発しました。開発期間は従来の半分（約6時間）で完了しました。本記事では、その具体的な開発プロセスと使用ツールを紹介します。新人エンジニアにも分かりやすいよう、簡潔に説明します。 開発概要: ウェブサイトは、はてな匿名ダイアリーの記事をスクレイピングし、Amazon APIで商品情報を取得、それらを元にリンク集を作成するシンプルな構成です。 生成AI/LLMツールは、デザイン、コーディング、データ処理の各段階で活用されました。 デザイン: 初期デザインはClaude Artifactsを用いて作成。複数の生成AIツール（ChatGPT Canvas、v0、Bolt）を比較検討した結果、Claude Artifactsが最も高品質な成果物を生成したため採用しました。デザインはクックパッドを参考に、Tailwind CSSとshadcn/uiをベースにしています。 コーディング: Next.js (Static Exports) をフロントエンド、Firebase Firestore をバックエンドとして採用。 コード修正や提案にはCursorを使用し、Claude 3.5 SonnetモデルでAIアシストによる効率的な開発を実現しました。TypeScriptはデータ処理部分を除き、プロトタイピング段階では使用を最小限に抑え、効率化を図りました。 データ処理: はてな匿名ダイアリーの記事スクレイピングにはcheerio、Amazon商品データ取得にはPA APIを使用。GPT-4 Turbo (Vercel AI経由) を用いてスクレイピングしたデータの構造化とAmazon検索結果からの適切な商品の選別を行いました。コストは約10ドルで済みました。 アーキテクチャ: 静的サイト生成（SSG）を採用し、Cloudflare Workersでホスティングすることで高速なアクセスを実現。 Firestoreの柔軟なスキーマ設計により、LLMの出力結果を直接保存し、将来的なデータ構造の変更にも対応できる設計となっています。 ツール選定のポイント: デザイン： Claude Artifacts (高品質な初期デザイン生成) コーディング： Cursor (AIアシストによる効率的なコード修正) LLM： GPT-4 Turbo (Vercel AI経由、データ構造化と選別) フロントエンド： Next.js (shadcn/ui, Tailwind CSSとの親和性) バックエンド： Firebase Firestore (柔軟なスキーマ設計) ホスティング： Cloudflare Workers (静的サイト、拡張性) 本開発を通して、生成AI/LLMツールがウェブサイト開発の効率化に大きく貢献することが実証されました。 特に、プロトタイピング段階でのTypeScriptの使用制限や静的サイト生成の採用により、開発期間の大幅な短縮と柔軟性の両立を実現しました。 今後、生成AI/LLMツールの活用は、開発プロセスの標準的な一部になる可能性が高いと感じています。 引用元: https://laiso.hatenablog.com/entry/2024/10/27/154053 お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

関連リンク Introducing computer use, a new Claude 3.5 Sonnet, and Claude 3.5 Haiku Anthropic社は、大規模言語モデルClaudeの最新版であるClaude 3.5 SonnetとClaude 3.5 Haikuを発表しました。Claude 3.5 Sonnetは、前モデルと比べて大幅な性能向上を見せており、特にコーディング能力が著しく向上しています。SWE-bench Verifiedでのスコアは33.4%から49.0%に向上し、公開されている他のモデルを上回っています。TAU-benchでも性能向上を確認しています。価格は従来と変わらず、速度も同等です。 Claude 3.5 Haikuは、前世代の最大モデルであるClaude 3 Opusと同等の性能を、同等の費用と速度で実現しています。SWE-bench Verifiedでは40.6%を記録しました。低遅延で指示に従う精度も向上しており、ユーザー向け製品や、大量データ処理に適しています。 最大の革新は、公開ベータ版として提供開始された「コンピュータ使用」機能です。これは、Claudeが人間のようにコンピュータを操作できる機能で、画面を見て、カーソルを動かし、ボタンをクリックし、テキストを入力する事ができます。 Claude 3.5 Sonnetは、この機能を公開ベータ版で提供する最初の最先端AIモデルです。現在、実験段階であり、使いにくさやエラーが発生する可能性がありますが、開発者からのフィードバックを元に迅速な改善が期待されています。Asana、Canvaなど複数の企業が既にこの機能を試用し、数百ステップにも及ぶタスクの自動化に成功しています。 このコンピュータ使用機能は、Anthropic API、Amazon Bedrock、Google CloudのVertex AIで利用可能です。ただし、まだ初期段階であり、完璧ではありません。スクロールやドラッグなどの操作は、現時点ではClaudeにとって困難な場合があります。また、スパムや不正利用のリスクも考慮されており、安全な展開のための対策も講じられています。 Claude 3.5 Haikuは今月末にリリース予定です。 両モデルは、米国および英国のAI安全研究所による事前テストを経ており、安全性の確保にも配慮されています。 開発者からのフィードバックは歓迎されており、今後の更なる機能向上に繋がる事が期待されます。 引用元: https://www.anthropic.com/news/3-5-models-and-computer-use GitHub - microsoft/BitNet: Official inference framework for 1-bit LLMs Microsoftが開発したBitNetは、1ビット量子化された大規模言語モデル(LLM)のための推論フレームワークです。GitHub上で公開されており、MITライセンスの下で利用可能です。 このフレームワークを使うことで、1ビット量子化されたLLMを効率的に推論処理できます。 つまり、メモリ使用量を削減し、推論速度を向上させることが期待できます。 詳細な使用方法についてはGitHubリポジトリを参照ください。 リポジトリにはコード、課題、プルリクエスト、議論、アクション、プロジェクト、セキュリティ情報、そしてパフォーマンスに関するインサイトなどが含まれています。 9.6kのスターと635のフォークを獲得しており、多くの開発者から注目を集めていることが分かります。 本フレームワークは、リソースの制約がある環境下でのLLMの活用を促進する可能性を秘めています。 新人エンジニアの皆さんにとって、このプロジェクトは、大規模言語モデルの効率的な実装方法を学ぶ良い機会となるでしょう。 ただし、具体的な使用方法や実装方法は、GitHubリポジトリのドキュメントを参照する必要があります。 引用元: https://github.com/Microsoft/bitnet なんとなくから脱却する GitHub Actionsグッドプラクティス11選 gihyo.jp この記事は、GitHub Actionsをより効果的に運用するための11個のグッドプラクティスを、新人エンジニアにも分かりやすく解説しています。 GitHub Actionsの基本的な知識は既にあることを前提としており、 「フェイルファスト」「ムダの最小化」「セキュリティ」「メンテナンス性」の4つの設計指針に基づいた実践的なアドバイスが提供されています。 1. フェイルファスト: 迅速なエラー検出とフィードバックが重要です。タイムアウト設定(例: timeout-minutes: 5)、デフォルトシェルをBashに指定してパイプエラーを検出(defaults: run: shell: bash)、静的解析ツールactionlintによる構文エラーチェックを推奨しています。 2. ムダの削減: 不要なワークフロー実行を避けることで待ち時間とコストを削減できます。 Concurrencyによる古いワークフローの自動キャンセル(concurrency: group: $-$ cancel-in-progress: true)、イベントフィルタリングによるワークフロー起動条件の絞り込み(on: pull_request: paths: ['**.go']), コスト削減のためUbuntuランナーの優先利用(runs-on: ubuntu-latest)が挙げられています。 3. セキュリティ: 最小権限の原則を遵守することが重要です。GITHUB_TOKENのパーミッションをジョブレベルで定義し(permissions: contents: read), アクションのコミットハッシュを固定することで(例: uses: actions/checkout@eef61447b9ff4aafe5dcd4e0bbf5d482be7e7871)、セキュリティリスクを軽減します。 4. メンテナンス性: デバッグ容易性と可読性の高いコードを目指しましょう。Bashトレーシングオプション(set -x)による詳細なログ出力、workflow_dispatchイベントによる容易な動作確認、ワークフローの目的や影響範囲をコメントで記述する(# なにをするワークフローか手短に記述)ことが推奨されています。 最後に、これらのグッドプラクティスをまとめたテンプレートコードが提示されています。このテンプレートを活用することで、効率的で安全、そしてメンテナンス性の高いGitHub Actionsワークフローを構築できます。 より詳細な情報は、紹介されている書籍「GitHub CI/CD実践ガイド」を参照することを推奨しています。 引用元: https://gihyo.jp/article/2024/10/good-practices-for-github-actions 『AIねこコンテンツ』という謎の存在について「わかっていてもカワイイと思ってしまう」「モンハンみてぇだｗ」 この文章は、AIによって生成されたネコの動画コンテンツに関する複数のX（旧Twitter）投稿のまとめです。投稿された動画は、AIによって作られたネコが人間のような動作をする様子を映したもので、そのリアリティと可愛らしさから多くのユーザーが注目しています。 ネコは、食事をする、スプーンを使うなど、人間らしい動作をしますが、その動作が不自然ではなく、むしろ「可愛い」と感じる人が多いようです。 一部のユーザーは、その動きがゲーム「モンスターハンター」シリーズに登場するアイルーを連想させるとコメントしています。 動画のクオリティの高さが評価されている一方で、ネコの指が人間の手のように見える部分など、AIならではの不自然さも指摘されています。しかし、その不自然さすらも許せてしまうほどの可愛らしさや、リアルなネコの表情表現が、多くのユーザーを魅了している点が特徴です。 まとめると、このAIねこコンテンツは、高度なAI技術によって実現された、リアルで可愛いネコの動画であり、そのクオリティの高さと、人間とネコの境界を曖昧にする独特な表現が、大きな話題を呼んでいると言えるでしょう。 特に、新人エンジニアの視点では、AIによる動画生成技術の進歩と、その技術がエンターテインメントにどのように活用されているかの好例として理解できるでしょう。 また、ユーザーの反応から、AI技術の倫理的な側面（人間の手のような指など）についても考えるきっかけになるかもしれません。 引用元: https://togetter.com/li/2454857 お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

関連リンク Introducing computer use, a new Claude 3.5 Sonnet, and Claude 3.5 Haiku Anthropic社は、大規模言語モデルClaudeの最新版であるClaude 3.5 SonnetとClaude 3.5 Haikuを発表しました。 Claude 3.5 Sonnetは、前モデルと比べて大幅な性能向上を見せており、特にコーディング能力が飛躍的に向上しています。SWE-bench Verifiedでのスコアは33.4%から49.0%に向上し、公開されているモデルの中で最高点を記録しました。 これは、GitLab、Cognition、The Browser Companyといった企業による実証実験でも裏付けられています。これらの企業は、DevSecOpsタスク、AI評価、Webベースのワークフロー自動化など、様々な用途でClaude 3.5 Sonnetを活用し、顕著な成果を上げています。 一方、Claude 3.5 Haikuは、前世代の最大モデルであるClaude 3 Opusと同等の性能を、より低いコストと高速さで実現しています。SWE-bench Verifiedでのスコアは40.6%と、高いコーディング能力を有しています。低レイテンシと高い命令遵守能力から、ユーザー向け製品や、大量データ処理を伴うパーソナライズされた体験の生成などに適しています。 そして、今回の発表で最も注目すべきは、公開ベータ版として提供開始された「コンピュータ使用」機能です。これは、Claudeが人間のように画面を見て、カーソルを動かし、ボタンをクリックし、テキストを入力することでコンピュータを操作できる画期的な機能です。 Claude 3.5 Sonnetは、この機能を公開ベータ版として提供する最初の最先端AIモデルとなります。 この機能は実験段階であり、まだ不完全でエラーが発生する可能性がありますが、開発者のフィードバックを元に迅速に改善していく予定です。 Asana、Canva、Cognition、DoorDash、Replit、The Browser Companyといった企業が既にこの機能を試用しており、複雑なタスクの自動化に成功しています。 ただし、コンピュータ使用機能は、スパム、誤情報、不正行為といったリスクも伴うため、Anthropic社は安全な展開を推進するための対策を講じています。 この機能はAnthropic API、Amazon Bedrock、Google CloudのVertex AIで利用可能です。Claude 3.5 Haikuは今月末に公開予定です。 これらの新モデルとコンピュータ使用機能は、AIを活用した業務効率化に大きく貢献する可能性を秘めています。 引用元: https://www.anthropic.com/news/3-5-models-and-computer-use Stable Diffusion 3.5 のご紹介 — Stability AI Japan Stability AIは、最新の高性能画像生成AIモデル「Stable Diffusion 3.5」をリリースしました。これは、複数のモデルバリエーション（Stable Diffusion 3.5 Large、Stable Diffusion 3.5 Large Turboなど）から構成され、一般のハードウェアでも動作する点が特徴です。 特に、10月29日には、消費者のPCでも使いやすい「Stable Diffusion 3.5 Medium」もリリース予定です。 これらのモデルは、Stability AI Community Licenseの下で、商用・非商用を問わず無料で利用できます(年間収益100万ドル以上の企業はエンタープライズライセンスが必要)。 Hugging Faceからモデルの重み(ウェイト)をダウンロードし、GitHubで公開されている推論コードを用いて利用可能です。 Stable Diffusion 3.5シリーズは、カスタマイズ性を重視して開発されました。Query-Key Normalizationの導入により、ファインチューニングやLoRAによる調整が容易になっています。そのため、特定のニーズに合わせたモデル構築や、アプリケーション開発に適しています。 ただし、シード値による出力のばらつきが大きくなる可能性がある点は留意が必要です。これは、多様なスタイルに対応するための設計上のトレードオフです。 各モデルの特性は以下の通りです。 Stable Diffusion 3.5 Large: パラメータ数80億。高品質で、プロフェッショナルな用途(1メガピクセル解像度)に最適。 Stable Diffusion 3.5 Large Turbo: Stable Diffusion 3.5 Largeの蒸留版。高速で高品質な画像生成が可能(4ステップ)。 Stable Diffusion 3.5 Medium (10月29日リリース予定): パラメータ数26億。消費者のハードウェアでも動作し、カスタマイズ性と画質のバランスが良い(0.25～2メガピクセル解像度)。 Stable Diffusion 3.5は、プロンプトへの忠実度と画質において高い性能を示し、市場で最もカスタマイズしやすいモデルの一つです。 様々なスタイルに対応し、多様な肌の色や特徴を持つ人物の生成にも優れています。 Stability AI Community Licenseでは、非営利目的での利用は無料です。年間収益100万ドル未満の企業も商用利用が可能です。生成されたメディアの著作権はユーザーが保有します。 さらに、Stability AI API、Replicate、DeepInfra、ComfyUIなど、複数のプラットフォームからもアクセス可能です。 安全性についても配慮されており、悪用防止のための措置が講じられています。詳細な情報は、Stable Safetyページを参照してください。 今後、ControlNetsのリリースも予定されており、より高度な制御機能が提供されます。 ユーザーからのフィードバックも歓迎しています。 引用元: https://ja.stability.ai/blog/introducing-stable-diffusion-3-5 Runway Research Introducing Act-One Runwayは、アーティストのための表現力豊かで制御可能なツールを開発するというミッションのもと、Gen-3 Alpha内で表現力豊かなキャラクターのパフォーマンスを生成する最新ツール「Act-One」を発表しました。 Act-Oneは、ビデオと音声のパフォーマンスを入力として、魅力的なアニメーションを作成します。従来の顔アニメーションのパイプラインは、モーションキャプチャ機器、複数の映像参照、手動での顔リギングなど、複雑で複数ステップのワークフローを必要としますが、Act-Oneは、俳優のパフォーマンスのみを直接入力とすることで、これらを簡素化します。 シンプルなビデオ入力（例えば、自宅のカメラで撮影した俳優の演技）だけで、視線、微表情、ペース、セリフのデリバリーなどを忠実に再現した生成出力が得られます。俳優の体型とは異なるキャラクターにも適用可能で、創造的なキャラクターデザインとアニメーションの可能性を広げます。 複数カメラによる会話シーンも、単一の俳優とカメラ設定で生成可能です。異なるキャラクターを演じる俳優の演技をビデオ入力として、複数のキャラクターのアニメーションを生成できます。 Runwayは、安全な開発と展開に尽力しており、Act-Oneには、有名人の生成防止、音声使用権の確認、その他悪用防止のための包括的なコンテンツモデレーションと安全対策が導入されています。 Act-Oneは、高度な技術を幅広いクリエイターやアーティストに提供するというRunwayの目標に向けた一歩であり、アニメーションとキャラクターパフォーマンスにおける創造的なストーリーテリングの新たな可能性を切り開くことが期待されています。今後、段階的にユーザーへのアクセスが開始されます。 新人エンジニアの皆さんにも、手軽に高度なキャラクターアニメーション制作を体験できるツールとして、ぜひ注目してみてください。 引用元: https://runwayml.com/research/introducing-act-one お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

関連リンク Anthropic Wants Its AI Agent to Control Your Computer Anthropic社は、コンピュータを操作できるAIモデル「Claude」を発表しました。これは、ウェブ検索、アプリケーションの起動、マウスとキーボードを使ったテキスト入力など、人間が行うような様々なタスクを実行できます。 具体的には、ゴールデンゲートブリッジの日の出鑑賞計画作成や、自身の宣伝用ウェブサイト作成といったデモが行われました。ウェブサイト作成では、プロンプトからコードを生成し、Visual Studio Codeを使ってコーディング、さらにウェブサーバーを起動してテストまで行いました。エラー発生時には、原因を特定し修正する能力も示しました。 Claudeは、ソフトウェア開発スキルを測るSWE-benchや、OS操作能力を測るOSWorldといったベンチマークにおいて、既存のAIエージェントを上回る性能を示したとAnthropic社は主張しています（ただし、独立した検証はまだありません）。成功率は人間には劣りますが、既存の最先端モデルを大きく上回っています。 Anthropic社は、ClaudeのAPIを公開し、Canva、Replitなど複数の企業が既にテスト運用中であると発表しています。用途としては、事務作業の自動化による生産性向上などが期待されています。 しかし、AIエージェントはまだ課題も多く、予期せぬエラーのリスクや、計画性の不足などが指摘されています。Anthropic社も、クレジットカード使用制限など、安全対策を講じています。 現状では、コーディングなど特定の領域での活用が有効とされており、エラーが許容できる範囲での利用が重要になります。将来的には、様々なタスクを自動化し、人間の作業負担を軽減する可能性がありますが、信頼性と安全性の向上が不可欠です。 MicrosoftやAmazonなども同様のAIエージェント開発に注力しており、近い将来、多くのユーザーがAIエージェントを利用する時代が来るかもしれません。 引用元: https://www.wired.com/story/anthropic-ai-agent/ Transformers.js v3: WebGPU Support, New Models & Tasks, and More… Hugging Faceは、1年以上におよぶ開発を経て、Transformers.js v3をリリースしました。本バージョンでは、パフォーマンスの大幅な向上と機能拡張が実現されています。最大のポイントは、WebGPUサポートによる高速化です。WASMと比較して最大100倍の速度向上を実現しており、ブラウザ上でGPUによる高性能計算を可能にしました。ただし、WebGPUのブラウザサポートは現状70%程度であるため、一部のブラウザでは機能フラグの有効化が必要となる場合があります。 その他、以下の重要な変更点があります。 量子化フォーマットの追加: モデルの精度とサイズを調整するための量子化フォーマットとして、fp32、fp16、q8、q4など複数のオプションが追加されました。これにより、メモリ使用量と推論速度のバランスを最適化できます。特に、エンコーダーとデコーダーを持つモデルでは、モジュールごとに量子化フォーマットを指定することも可能です。 対応アーキテクチャの増加: サポートされるモデルアーキテクチャが120種類に増加しました。Phi-3、Gemma、Florence-2、Whisperなど、最新の多くのモデルが利用可能になりました。 サンプルプロジェクトとテンプレートの追加: WebGPUサポートを中心に、25個の新しいサンプルプロジェクトとテンプレートが公開されました。これらは、WebGPUを使った様々なタスクの具体的な実装例を提供します。 1200以上の事前変換済みモデル: Hugging Face Hubには、Transformers.js v3と互換性のある1200以上の事前変換済みモデルが用意されています。 環境の拡張: Node.js (ESM + CJS)、Deno、Bunの主要なJavaScriptランタイムに対応しました。 リポジトリとパッケージ名の変更: GitHubリポジトリとNPMパッケージ名が公式のHugging Face組織のものに変更されました。GitHubはhuggingface/transformers.js、NPMは@huggingface/transformersとなります。 Transformers.js v3は、WebGPUによる高速化と多様なモデルへの対応により、Webブラウザ上での機械学習モデルの活用を飛躍的に容易にします。 新規エンジニアの方にとっても、豊富なサンプルコードとドキュメントによって、容易に導入・活用できるようになっています。 新しい量子化オプションは、リソース制約のある環境でのモデル実行に役立ちます。 様々なランタイムへの対応は、開発環境の柔軟性を高めます。 引用元: https://huggingface.co/blog/transformersjs-v3 Amazon Bedrock Custom Model Import now generally available Amazon Web Services Amazon Bedrockが、独自のカスタムモデルをインポートして利用できる機能「Amazon Bedrock Custom Model Import」を一般提供開始しました。これにより、Meta Llama、Mistral Mixtral、IBM Graniteなどのファインチューニング済みモデルや、オープンソースアーキテクチャに基づいた独自開発モデルを、インフラ管理やモデルライフサイクル管理の手間なくAmazon Bedrockで利用できるようになります。 既存の基盤モデル（FM）と同様に、単一のAPIを通じてカスタムモデルにオンデマンドでアクセスでき、サーバーレス環境で利用可能です。Knowledge Bases、Guardrails、AgentsなどのAmazon Bedrockのネイティブツールや機能ともシームレスに統合され、開発者は一貫した開発エクスペリエンスを得られます。 主なメリット: 既存のファインチューニング済みモデルの柔軟な利用: 再作成や再トレーニングなしに、既存のカスタムモデルをAmazon Bedrockにインポートできます。 Amazon Bedrock機能との統合: Knowledge Bases、Guardrails、Agents、Model Evaluationなど、Amazon Bedrockのネイティブツールとシームレスに統合できます。 サーバーレス: インフラの管理やスケーリングはAmazon Bedrockが行うため、開発者はインフラ管理を気にせず、生成AIアプリケーション開発に集中できます。 主要なモデルアーキテクチャのサポート: Meta Llama 3.2、Mistral 7B、Mixtral 8x7Bなど、様々なモデルアーキテクチャをサポートし、Hugging Face Safetensors形式のモデルウェイトをAmazon SageMakerやAmazon S3からインポートできます。 Amazon Bedrock Converse APIとの連携: サポートされているファインチューニング済みモデルをAmazon Bedrock Converse APIで使用できます。 制約事項: モデルはSafetensors形式でシリアライズされている必要があります。他の形式の場合は変換スクリプトが必要です。 インポートプロセスでは、.safetensors、config.json、tokenizer_config.json、tokenizer.json、tokenizer.modelファイルが必要です。 モデルウェイトの精度には、FP32、FP16、BF16がサポートされています。 現状、US-EAST-1とUS-WEST-2リージョンのみで利用可能です。 各アカウントのデフォルトインポートクォータは3モデルです。 この機能は、独自データでモデルをカスタマイズし、チューニング済みモデルアーティファクトとそのデプロイメントに対する完全な所有権と制御を維持したいという顧客のニーズに応えるものです。 Amazon Bedrock Custom Model Importを利用することで、既存のカスタマイズへの投資を最大限に活用し、生成AIアプリケーション開発を加速できます。 ただし、本番環境での利用には、より多様なデータセットと適切なテスト、ハイパーパラメータチューニングによる継続的な実験が必要です。 引用元: https://aws.amazon.com/blogs/machine-learning/amazon-bedrock-custom-model-import-now-generally-available/ お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

関連リンク Microsoft to roll out AI agents in Copilot Studio next month マイクロソフトは、来年11月からCopilot Studioで自律型AIエージェントの構築を可能にすることを発表しました。これは、企業データ（Microsoft 365 Graph、各種システム、Dataverse、Fabricなど）を活用し、特定のワークフローを支援または完全に自動化するAIエージェントです。 Copilot Studioを使うことで、ユーザーはビジネスデータプラットフォーム、システム、データベース内の情報をスキャンし、独自のタスクを開始するようにツールを設定できます。 既にMcKinsey & Company、Pets at Home、Thomson Reutersなど、いくつかの企業で業務プロセスを支援しているとのことです。 マイクロソフトは、同時にDynamics 365（ERP/CRMソリューション）向けに10個の新しい自律型AIエージェントのユースケースも発表しました。 これらのエージェントは、営業案件の審査、サプライチェーンのパフォーマンス追跡、カスタマーサービスチームのサポートなどに利用できます。 マイクロソフトは、これらのエージェントを「AI駆動の世界における新しいアプリ」と位置づけており、個々のユーザー、チーム、部門を代表してビジネスプロセスを実行・調整する、様々なレベルの自律性を持つエージェントが、今後各組織に必要になると予測しています。 この発表は、生成AIが単なる質問応答から、人間による監視を最小限に抑えたエンドツーエンドのタスクを実行する自律型エージェントへと進化していることを示しています。 市場全体を見ても、Capgeminiのデータによると、82%の組織が今後1～3年以内にこれらのツールを統合する計画であり、Gartnerは2027年までにAIソフトウェア支出が3000億ドル近くに達すると予測しています。 Salesforce、SAP、Metaなども同様のエージェント機能を提供開始しており、企業向けAI市場における競争が激化しています。 新人エンジニア向け補足： このニュースは、AIが単に言葉を生成するだけでなく、業務を自動化するためのツールとして進化していることを示しています。Copilot Studioは、これらのAIエージェントを簡単に作成するためのプラットフォームです。 Dynamics 365への統合は、既存の業務システムとAIを連携させることで、業務効率の大幅な向上が期待できることを意味します。 今後のAI開発において、このような自律型エージェントの開発・活用は重要なトレンドとなるでしょう。 引用元: https://www.ciodive.com/news/microsoft-copilot-studio-agents-AI/730429/ “Llama 3.2 in Keras” 本記事は、Hugging FaceのTransformersで利用可能なLlama 3.2の大規模言語モデル(LLM)を、Kerasを用いて容易に利用する方法を紹介しています。KerasはJAX、PyTorch、TensorFlowに対応するマルチバックエンドのモデリングライブラリであり、keras_hubライブラリを通じてLlama 3.2を含む様々な事前学習済みモデルにアクセスできます。 記事の要点としては、Kerasを用いることで、Llama 3.2を容易に利用できる点が強調されています。Llama3CausalLM.from_preset()関数を使用することで、Hugging Faceのチェックポイントからモデルを直接ロードできます。変換は必要に応じて自動的に行われます。 さらに、model.generate()関数でテキスト生成、model.fit()関数で直接文字列データを用いたモデルの訓練が可能です。トークナイザーやモデルのバックボーンへの低レベルアクセスも容易にできます。 Kerasは、トークナイザーを含めた必要な要素を備えているため、モデルの利用が容易です。指示調整済みのモデルを用いた会話機能もサポートしており、ChatStateヘルパークラスを用いることで会話形式のテキスト入力を簡素化できます。 また、Kerasは組み込みのトレーナーを提供しており、分散訓練、混合精度、量子化、LoRA/QLoRAなどの高度な機能にも対応しています。 カスタムの訓練ループを作成することも可能です。 訓練済みのモデルはmodel.save_to_preset()関数とkeras_hub.upload_preset()関数を使用してHugging Face Hubに直接アップロードできます。 最後に、KerasとJAX/XLAの組み合わせによる分散モデル並列処理の利点が紹介されています。特に大規模モデル(例: Llama-3.1-8B-Instruct)を複数のアクセラレータ(GPUまたはTPU)に分散してロードし、推論や訓練を行うための方法が示されており、keras.distribution.ModelParallelを用いた実装例が提示されています。 デフォルトのレイアウトマップを利用するだけでなく、独自のレイアウトマップを定義して最適化することも可能です。 このブログ記事全体を通して、Kerasを使用することで、Llama 3.2を含む大規模言語モデルの利用、訓練、そして分散処理が非常に容易になることが示されています。初心者エンジニアにとっても、直感的なAPIと豊富な機能により、LLMの活用が容易になります。 提供されているColabノートブックを利用することで、実際にコードを実行し、動作を確認することができます。 引用元: https://huggingface.co/blog/keras-llama-32 GitHub - microsoft/VPTQ: VPTQ, A Flexible and Extreme low-bit quantization algorithm Microsoftが開発したVPTQは、柔軟性が高く、極めて低ビット数の量子化アルゴリズムです。GitHubリポジトリで公開されており、MITライセンスの下で利用可能です。 このアルゴリズムは、少ないビット数で高精度な量子化を実現することを目指しており、特にメモリや計算リソースの制約が厳しい組み込みシステムやモバイルデバイスでの活用に適しています。リポジトリにはソースコード、issueトラッキング、プルリクエスト機能などが含まれていますが、具体的な使用方法や実装の詳細については、リポジトリ内のドキュメントを参照する必要があります。 現在、432個のスターと25個のフォークを獲得しており、活発に開発が進められていることが伺えます。 新人エンジニアの方にとって、低ビット量子化技術の学習や、実際の実装例を学ぶ上で有用なリソースとなるでしょう。ただし、実装には量子化に関する基礎知識が必要となります。 引用元: https://github.com/microsoft/VPTQ お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

関連リンク Geminiを使ったらKaggle初挑戦、参加期間10日間でも5位入賞できたので手法をすべて書く この記事は、Kaggleコンペティション「LLM 20 Questions」に10日間だけ参加して5位入賞した著者が、その手法を詳細に解説したものです。著者は、MARCHレベルの物理系出身で、英語力・深層学習の知識共に専門家レベルではないと明言しています。Kaggle初心者や深層学習の基礎知識を持つエンジニアにとって、非常に参考になる内容です。 成功の鍵となったのは、Google Geminiの大規模言語モデルの活用です。API利用頻度と50万トークンものコンテキスト処理能力が必要だったため、Gemini以外では実現不可能だったと述べています。 著者は、Kaggleの情報を英語のまま処理するのではなく、コンペの概要、データ、ルール、ディスカッション、ノートブックをすべてGeminiで自動翻訳・要約し、マークダウン形式で整理するアプリケーションを開発しました。 このアプリケーションによって、英語の壁を乗り越え、Kaggleを日本語で完結に利用できる環境を構築しました。このアプリケーションはAWS Amplifyで公開されていますが、現在対応しているコンペティションは一つのみです。 コンペへの取り組みは、以下の3つのフェーズに分けられました。 概要理解と環境構築フェーズ (2日間): コンペの概要を理解し、開発環境を整え、とりあえず提出を行う。 情報収集と手法選定フェーズ (2日間): 主要なディスカッションとノートブックを分析し、最適な手法を選択する。 手法改良と提出フェーズ (6日間): 選んだ手法を改良し、複数回提出を行う。 各フェーズにおいて、作成したアプリケーションで生成されたマークダウン形式の情報をGeminiのプロンプトに与え、対話的に質問することで、コンペの理解を深め、最適な手法の選定と改良を行いました。 Geminiとの対話を通して、コンペで勝利するための本質的な要素を理解し、手法の改善に繋げることができたと述べています。 著者は、この手法によってKaggle初心者でも上位入賞を目指せる可能性を示唆しており、特にコンペ終盤、ディスカッションやノートブックの情報が豊富になった段階で有効であると結論づけています。 ただし、この手法は活発なコミュニティ参加が前提となるため、注意が必要です。 引用元: https://qiita.com/yukky_memo/items/6e1c7fa08b9b91278886 DeNA 流 SaaS の外形監視手法 BLOG - DeNA Engineering DeNAのIT戦略部システム基盤グループは、社内向けに様々なSaaSを提供・運用しています。SaaSのメリットは導入コストや運用コストの低さ、セキュリティ対策のベンダー任せなどが挙げられますが、障害発生時の対応はベンダー任せとはいえ、従業員からの問い合わせ対応は運用担当者が行う必要があります。そのため、SaaSに対する適切な監視体制が不可欠です。 従来、各ベンダーが提供するステータスダッシュボードを利用していましたが、リアルタイム性や情報量の多さ、サービスごとのURL違いなど、課題がありました。そこで、Seleniumを用いた「外形監視」による監視手法を採用しました。 外形監視では、Seleniumを用いて、あたかも人間がSaaSを利用しているかのようにアクセスし、障害を検知します。AWSのEC2インスタンス上で、各SaaSごとにDockerコンテナを用意し、Seleniumを実行しています。コンテナはDocker Composeで管理し、cronとPythonスクリプトで定期的にSeleniumシナリオを実行します。 例えば、Slackの監視では、Botが定期的にメッセージを投稿し、そのタイムスタンプを監視することで、サービスの遅延を検知します。同様の手法で、Okta、Jira、Confluenceなども監視しています。シナリオは、各SaaSへのログイン、特定のページへのアクセス、データの取得など、実際のユーザー操作を模倣したものです。5分以上の遅延を障害と判定しています。 さらに、ベンダー提供のステータスダッシュボードを模倣した、社内向けサービスステータスダッシュボードを開発しました。このダッシュボードは、Seleniumによる外形監視の結果を集約し、各サービスの稼働状況を一元的に表示します。これにより、従業員はリアルタイムにサービス状況を確認でき、不要な問い合わせを削減できます。 今後は、SaaS以外のシステム（VPN、Active Directoryなど）の監視強化も予定しています。 このSeleniumを用いた外形監視システムは、SaaSの安定稼働と迅速な障害対応に大きく貢献しています。 新人エンジニアにとって、Docker、Selenium、Python、cronといった技術の理解が、このシステムの理解に役立ちます。 引用元: https://engineering.dena.com/blog/2024/10/saas-monitoring-tool/ Go 1.24 から go.mod でのツール管理がより簡潔になるかもしれない Go 1.24では、go.mod でのツール管理が簡素化される可能性があります。現状、Goで書かれたコマンドラインツールのバージョン管理は、tools.go ファイルを用いたblank importやMakefileを使ったgo installなどが一般的ですが、ツール追加・削除時の操作が複雑で、プラットフォーム依存性や既存ファイルのハンドリングなど、課題がありました。 Go 1.24では、この問題を解決するため、go.modにtoolディレクティブを追加する提案が採択されています。このディレクティブを用いることで、go getやgo mod editコマンドでツール依存関係を直接go.modに記述・管理できるようになります。 具体的には、go get -tool <パッケージパス>でツールを追加、go get -tool <パッケージパス>@noneで削除、go mod edit -droptool <パッケージパス>でも削除が可能になります。go tool <ツール名>コマンドで、go.modに指定されたツールのバージョンを確実に実行できます。このツールは$GOCACHEにキャッシュされるため、複数プロジェクトでの効率的なディスク利用も期待できます。 ただし、Go 1.24への正式実装は未定であり、リリースノートにも記載がないため、今後の情報に注意が必要です。詳細な情報は、関連するGitHub issueとDesign docを参照ください。 この変更により、Goツールのバージョン管理がよりシンプルで安全になり、開発効率の向上が期待されます。 新人エンジニアの方々も、Go 1.24リリース後にこの機能を活用することで、ツールのバージョン管理をスムーズに行えるようになるでしょう。 引用元: https://zenn.dev/uji/articles/adding-tool-dependencies-to-go-mod こんな見た目しているからさすがに模型だろうと思ったけど本当に段ボール製のドローン実機だった→使い捨て前提だから航続距離100kmで1kg以上積める Togetterに掲載された記事によると、一見模型のように見えるが、実際は段ボールで製造されたドローン実機が存在するとのことです。このドローンは使い捨てを前提として設計されており、航続距離100km、積載量1kg以上という性能を備えています。 記事では、段ボール製であることから低コストで大量生産が可能であると指摘しつつ、その軍事利用の可能性についても言及しています。 軽量で安価な段ボール製ドローンは、大量投入による攻撃や災害時の迅速な物資輸送など、様々な用途が想定されます。一方で、その手軽さから、悪用されるリスクも懸念されています。 技術的な詳細や具体的な製造方法は記事からは読み取れませんが、使い捨て前提の設計により、コストと性能のバランスを取った革新的なドローン開発の事例として注目を集めているようです。 日本のエンジニアの皆様にとって、この事例は、材料選定やコスト削減、そして新たな用途開発における一つの参考事例となるでしょう。特に、軽量化、低コスト化、大量生産といった課題に取り組む開発において、この段ボールドローンの設計思想は非常に興味深い示唆を与えてくれます。 ただし、軍事転用や倫理的な問題についても考慮する必要があることを忘れてはなりません。 引用元: https://togetter.com/li/2452652 お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

関連リンク 「9.11 > 9.9」から始めるLLMの計算間違い探索 / 開発者向けブログ・イベント GMO Developers この記事は、GMO Developersのブログ記事で、大規模言語モデル（LLM）が簡単な数値計算で誤答する事例とその原因、そして改善策について解説しています。 ChatGPTなどのLLMが「9.11 > 9.9」といった単純な大小比較を間違える現象を検証しています。 複数のLLM（GPT-4o、Claude 3.5 Sonnet、Gemini 1.5 Pro、Llama3 70b Instruct）を用いた実験では、LLMは小数点以下の桁数や、文字列中の特定文字の数を正確に数えることに苦手意識を示しました。 例えば、「strawberry」の「r」の数を数える問題でも、多くのLLMが誤答しました。 この原因として、トークナイゼーション（テキストを意味を持つ最小単位に分割する処理）の影響が考えられますが、記事では、LLMが数値計算を理解していないことが本質的な原因だと主張しています。LLMは過去の学習データから「それらしい」回答を生成しているだけで、真の意味で計算をしているわけではない、というのです。 これは、桁数の大きな掛け算でも確認されており、LLMは学習データに多く含まれる3桁以下の数値計算は得意ですが、それ以上の桁数になると誤答が多くなります。 さらに、誤答を指摘しても、LLMはそれを容易に受け入れてしまう傾向が見られました。 改善策として、LLMに直接計算させるのではなく、LLMにプログラムを作成させ、そのプログラムを実行させる方法が提案されています。 「プログラムを実行して回答してください」というシンプルな指示で、LLMは正確な計算結果を返すコードを生成し、実行することが可能です。 結論として、この記事は、LLMの能力と限界を理解し、適切な道具として使いこなすことの重要性を強調しています。 LLMは万能ではなく、数値計算のような正確性が求められるタスクには、プログラムとの連携が不可欠であることを示しています。 新人エンジニアは、LLMの特性を理解し、その能力を最大限に活かすための適切な活用方法を学ぶ必要があります。 引用元: https://developers.gmo.jp/technology/48648/ UNIQUE制約の理解が甘くて二重にインデックスを張りそうになった件 PostgreSQLを用いたデータベース設計において、UNIQUE制約とインデックスの理解不足からパフォーマンス問題に遭遇した事例です。新人エンジニアが、採用管理システムの機能開発中に、オペレータとセミナーの多対多関係を表すassigned_seminarsテーブルを作成する必要に迫られました。 このテーブルには、website_id, operator_id, seminar_idといったカラムが含まれます。 複数のオペレータが担当するセミナーを検索するクエリと、特定セミナーの担当者を検索するクエリの両方を想定し、website_idとoperator_idの組み合わせにUNIQUE制約とインデックスを作成しました。しかし、上司からのレビューで、インデックスが重複している可能性を指摘されました。 そこで、以下の5パターンで実験を行いました。 制約・インデックスなし UNIQUE制約のみ(website_id, operator_id, seminar_id) インデックスのみ(website_id, operator_id) UNIQUE制約とインデックス(website_id, operator_id, seminar_idとwebsite_id, operator_id) UNIQUE制約のみ(website_id, seminar_id, operator_id) 大量のテストデータを用いて、特定のオペレータが担当するセミナーを検索するクエリの実行時間を比較しました。その結果、インデックスがない場合(1, 5)は実行時間が非常に長く、UNIQUE制約のみ(2)、インデックスのみ(3)は実行時間に大きな差がないことが分かりました。 さらに、UNIQUE制約とインデックスの両方を持つ場合(4)も、UNIQUE制約のみの場合(2)と実行時間に差がありませんでした。これは、PostgreSQLがUNIQUE制約を宣言したカラム順にインデックスを自動生成しているため、重複したインデックスを作成していたことを意味します。 さらに、新規データ挿入時のパフォーマンスも検証しました。 複数の担当者をセミナーに追加するINSERTクエリを実行した結果、インデックスが重複している場合、挿入にかかる時間が増加することが確認されました。ただし、このテーブルでは項目数が少なく、その影響は限定的でした。しかし、項目数が多いテーブルや、複雑なインデックスを持つテーブルでは、より顕著なパフォーマンス低下が予想されます。 この事例から、PostgreSQLではUNIQUE制約によって自動的にインデックスが作成されるため、重複したインデックスを作成しないよう注意が必要であることが分かりました。 テーブル設計時には、想定されるクエリを考慮し、適切なインデックスを作成することが重要です。 また、インデックスの重複はデータの挿入コスト増加につながるため、注意深く設計する必要があります。 この経験を通して、データベース設計におけるインデックスの重要性を再認識し、今後の設計やレビューに活かしていくと結論付けられました。 引用元: https://developers.techouse.com/entry/unique-index-conflict VSCodeでホバー時のTypeScriptの型ヒントをすべて表示する この記事は、Visual Studio Code (VSCode) でTypeScriptの型ヒントをホバー表示する際に、プロパティが多いと型ヒントが省略されてしまう問題の解決策を説明しています。 問題の原因は、VSCodeのTypeScript言語サーバが、型ヒントの表示行数をデフォルトで160行に制限しているためです。 tsconfig.json に noErrorTruncation: true を追加しても解決しません。これはエラー時の型ヒント省略を防ぐオプションであり、今回の問題とは関係ありません。 解決策として、Node.jsスクリプトを用いて、言語サーバが参照するファイル内の defaultMaximumTruncationLength の値を直接変更する方法が提示されています。 このスクリプトは、VSCodeのTypeScript拡張機能のインストールディレクトリを指定し、表示行数の最大値を指定することで動作します。例えば、VSCodeのインストールディレクトリが~/.vscodeの場合、最大表示行数を1000行に設定するには、以下のコマンドを実行します。 node changeTypeScriptHover.js ~/.vscode 1000 このスクリプトは、vscode-typescriptを含む拡張機能ディレクトリを検索し、該当するJavaScriptファイル内のdefaultMaximumTruncationLengthを指定した値に書き換えます。 スクリプトの内容は、ファイル読み込み、置換、書き込みを行うシンプルなものです。 記事では、VSCodeの拡張機能を利用する方法もあると触れられていますが、自身で管理できる方法に焦点を当てています。 新人エンジニア向けに補足すると、この方法はVSCodeの内部ファイルの書き換えを伴うため、注意が必要です。 バックアップを取ってから実行し、問題が発生した場合は、元の状態に戻す準備をしておきましょう。 また、VSCodeの更新などによってスクリプトが動作しなくなる可能性があるため、その際はスクリプトの修正が必要になるかもしれません。 より安全な方法として、VSCode拡張機能の利用を検討することもできます。 引用元: https://zenn.dev/karan_coron/articles/dcab49bed5b2ff お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

関連リンク Un Ministral, des Ministraux Mistral AIは、エッジデバイスでの利用に最適化された2つの新しい最先端言語モデル、「Ministral 3B」と「Ministral 8B」を発表しました。これは、数百万人のユーザーに革新をもたらしたMistral 7Bリリースから1周年を記念したものです。 Ministral 3Bと8Bは、100億パラメーター以下のモデルにおいて、知識、常識、推論、関数呼び出し、効率性において新たな基準を打ち立てています。エージェントワークフローのオーケストレーションから専門的なタスクワーカーの作成まで、幅広い用途に使用、または微調整できます。両モデルは最大128kコンテキスト長をサポートし(vLLMでは現在32k)、Ministral 8Bは高速でメモリ効率の良い推論のための特別なインターリーブスライディングウィンドウアテンションパターンを採用しています。 これらのモデルは、デバイス上での翻訳、インターネット不要のスマートアシスタント、ローカル分析、自律型ロボットなど、プライバシーを重視したローカル推論を必要とする重要なアプリケーションに対応するために開発されました。個人ユーザーからグローバルな製造チームまで、幅広い用途で利用できます。 ベンチマークテストでは、同等のモデルを凌駕する性能を示しています。Mistral 7Bと比較しても、特にMinistral 3Bは多くのベンチマークで優れた結果を出しています。 Ministral 3Bと8Bは、現在APIとして利用可能です。価格は、Ministral 3Bが100万トークンあたり0.04ドル、Ministral 8Bが100万トークンあたり0.1ドルです(入力と出力の両方)。 また、研究目的でMinistral 8B Instructのモデル重みもHugging Faceで公開されています。オンプレミスでの利用を希望する場合は、Mistral AIに連絡して商用ライセンスを取得する必要があります。 Mistral AIは、最先端のモデル開発を継続しており、今後の更なる進展にも期待できます。 引用元: https://mistral.ai/news/ministraux/ Fixing Gradient Accumulation Hugging FaceのTransformersライブラリにおいて、勾配累積（Gradient Accumulation）機能を使用時の損失関数計算に不具合が見つかりました。これは、特に因果言語モデル(Causal LM)のようなトークンレベルのタスクで顕著に現れ、勾配累積ON/OFFで損失値が一致しない問題が発生していました。 この問題は、Transformersが提供するデフォルトの損失関数が、勾配累積時の計算方法に考慮不足だったことが原因です。具体的には、因果言語モデルでは、全バッチの損失を全非パディングトークン数で割る必要があるのに、バッチごとの損失の平均値を使用していたため、誤った損失値が計算されていました。 Hugging Faceチームは、この問題を以下の2つの方法で修正しています。 デフォルト損失関数の修正: ユーザーがデフォルトの損失関数を使用している場合、勾配累積時に適切な損失計算を行うよう、内部コードを修正します。これにより、多くのユーザーは修正後すぐに正しい結果を得られるようになります。 カスタム損失関数APIの提供: ユーザーが独自の損失関数をTrainerに直接渡せるAPIを提供します。これにより、ユーザーは、内部修正が完了するまで、独自の修正を容易に適用できます。 PreTrainedModelを継承するすべてのモデルはloss_functionプロパティを持ち、config.loss_typeやLOSS_MAPPINGを介してカスタム損失関数を設定できます。 これらの修正は、GitHubのプルリクエスト(PR)を通じて行われています(PRリンクは省略)。主要モデルへの修正は既に進められており、近々リリースされる予定です。残りのモデルへの修正も、コミュニティからの貢献を募りながら進めていきます。 修正版はpip install git+https://github.com/huggingface/transformersでインストールできます。 バグ報告は、Hugging Faceのイシュー・トラッカー(リンクは省略)から受け付けています。 迅速な対応を心がけており、本件も24時間以内に修正済みコードをリリースしました。 本件は、デフォルト設定の不備が原因でしたが、直感的に分かりにくいデフォルト設定は変更すべきであるという教訓となりました。 今後も、ユーザーの多様なユースケースに対応できるよう、Transformersの改善に努めてまいります。 引用元: https://huggingface.co/blog/gradient_accumulation Sana Sanaは、NVIDIA、MIT、清華大学が共同開発した、高解像度画像生成フレームワークです。最大4096x4096ピクセルの高品質な画像を、高速かつ効率的に生成できます。特に、16GBのGPUを搭載したノートパソコンでも、1024x1024ピクセルの画像を1秒未満で生成できる点が大きな特徴です。 その効率性の高さは、以下の革新的な設計によるものです。 高圧縮オートエンコーダ(AE-F32): 従来のAEが画像を8倍圧縮するのに対し、Sanaは32倍圧縮を実現。潜在トークンの数を大幅に削減することで、高解像度画像生成の効率化に大きく貢献しています。 効率的な線形DiT: 従来の二次計算量を持つアテンション機構を線形アテンションに置き換えることで、計算量をO(N²)からO(N)に削減。高解像度でも品質を落とさずに高速化を実現しています。さらに、位置エンコーディングを不要とすることで、モデルの簡素化も図っています。 デコーダのみの小型LLMによるテキストエンコーダ: Gemmaと呼ばれるデコーダのみの小型LLMをテキストエンコーダとして採用。高度なプロンプト理解と画像・テキストの一致度向上を実現しています。複雑な人間による指示（CHI）とインコンテキストラーニングを組み合わせることで、より精度の高い画像生成を可能にしています。 効率的な学習・サンプリング戦略: 自動キャプション生成とCLIPスコアに基づくキャプション選択により、学習の収束速度と画像・テキストの一致度を向上させています。また、サンプリングステップ数を削減するFlow-DPM-Solverを採用することで、推論速度も高速化しています。 Sanaは、既存の大規模拡散モデル(例えばFlux-12B)と比較して、パラメータ数は20分の1、スループットは100倍以上高速です。様々なベンチマークにおいて、大規模モデルに匹敵する、あるいはそれを上回る性能を示しています。 特に、1024x1024解像度での推論速度においては、3Bパラメータ以下のモデルの中でトップクラスの性能を誇ります。 GitHubリポジトリには、コードが近日公開予定となっています。 このフレームワークは、低コストでコンテンツ作成を可能にする、実用的なAI技術として期待されています。 引用元: https://nvlabs.github.io/Sana/ お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

関連リンク RAGのハルシネーション対策をする手法「Astute RAG」 この記事は、Google Cloud AI ResearchとUSCの研究者らが提案した、RAG（Retrieval Augmented Generation）の精度向上手法「Astute RAG」の概要を説明しています。RAGは、大規模言語モデル（LLM）の回答精度向上に用いられる手法ですが、利用する外部データソースの不正確さや古さが、かえってハルシネーション（事実と異なる回答）を引き起こす問題がありました。 Astute RAGは、この問題を解決するため、LLMが持つ内部知識と外部知識を効果的に組み合わせる手法です。具体的には、以下の3ステップで構成されます。 LLM内部知識の活用: まず、外部データを参照せずにLLMに質問させ、その回答を内部知識として抽出します。不確かな情報は「分からない」と明示的に回答させることで、不正確な情報の混入を防ぎます。 情報の統合と矛盾解消: 次に、質問に関連する外部データソースを検索・取得します。取得した外部知識とステップ1で得られた内部知識を統合し、矛盾しない情報群をグループ化します。この工程は複数回繰り返すことも可能です。 信頼性評価と回答生成: 各グループごとに最終的な回答案を生成し、情報源の信頼性、複数情報源からの確認、情報の頻度、詳細さなどを考慮して信頼性を評価します。最も信頼性の高い回答案を選択し、最終回答として出力します。 従来のRAGでは、外部データソースの正確性に依存していましたが、Asture RAGはLLMの内部知識も活用することで、データソースの質が低い場合でも、RAGを使用しない場合と同等以上の性能を実現しました。複数のベンチマークデータセットにおいて、既存のRAG手法を上回る性能を示したと報告されています。 特に、社内ドキュメントの更新が遅れている、特定部署・役職者のみが理解できる情報が含まれているといった、企業環境特有の問題に対しても有効です。 Astute RAGは、情報ソースの信頼性をシステム的に評価・選別することで、ユーザー側がデータソースの正確性を常に確認する必要性を軽減し、RAGシステムの信頼性を向上させる可能性を秘めています。 記事では、Self-RAGやCRAGといった、ハルシネーション対策のための他のRAG手法についても言及しています。 引用元: https://zenn.dev/knowledgesense/articles/1ecd331dc6b589 DuckDB で JSON Lines 形式のログを精査する この記事は、DuckDBを用いてJSON Lines形式のログデータを効率的に処理する方法を解説しています。新人エンジニアにも分かりやすいように、基本的な操作から応用的なテクニックまで丁寧に説明されています。 概要: 大量のログデータは、しばしば圧縮されたJSON Lines形式（.jsonl.gz, .jsonl.zstなど）で保存されています。従来は、個々のファイルをスクリプトで処理する必要がありましたが、DuckDBを使うことでSQLクエリだけで効率的に処理できます。 主な機能と制約: 圧縮ファイルの直接読み込み: read_json_auto()関数を使用することで、*.jsonl.gzや*.jsonl.zstといった複数の圧縮JSON Linesファイルをワイルドカード(*)を使って一度に読み込めます。 ファイル名も取得可能です（filename=trueオプション）。 S3からの直接読み込み: S3バケットに保存されたログデータも、適切な認証設定（CREATE SECRETコマンド）後、read_json_auto()関数で直接読み込めます。これにより、データのローカルへのダウンロードが不要になり、処理速度が向上します。 Parquet形式への変換: 処理後のデータを、高圧縮率のParquet形式に変換して保存できます。COPY ... TOコマンドを使用し、S3への直接書き込みも可能です。 SQLによるデータ操作: DuckDBはSQLをサポートしているので、読み込んだログデータをSQLクエリで自由に加工・集計できます。複数のログファイルをJOIN句で結合することも可能です。 記事では具体的なSQLクエリ例が示されており、これらを利用することで、大規模なログデータの分析を容易に行うことができます。 DuckDBを利用することで、ログ解析スクリプトの開発工数を削減し、分析結果を迅速に得ることが期待できます。 詳細な使用方法や各関数のオプションについては、記事中に記載されているDuckDB公式ドキュメントを参照ください。 引用元: https://zenn.dev/shiguredo/articles/duckdb-jsonlines-log テスラの人型ロボット、イベント中に従業員が遠隔操作－関係者 テスラが10月10日に開催したイベント「ウィー、ロボット」で発表された人型ロボット「オプティマス」の試作品は、従業員による遠隔操作が行われていたことが関係者によって明らかになりました。 イベント参加者とのやり取りの多くは、従業員が別の場所から監視・操作しており、オプティマスはAIを用いて自律歩行は可能でしたが、イベントでの動作は完全な自律動作ではありませんでした。 一部参加者はソーシャルメディアでこの事実を指摘し、ある動画ではオプティマス自身が「人間にアシストされている」と発言している様子が確認されています。 テスラ側は現時点でコメントを控えています。 オプティマスは当初、このイベントでの発表は予定されておらず、マスクCEOから発表決定の通知があったのは約3週間前だったため、ソフトウェアの準備が間に合わず遠隔操作せざるを得なかったとされています。 マスクCEOはイベントでオプティマスを「これまでにない最大の製品」と評し、将来的には2万～3万ドルで販売する可能性を示唆しました。 今回の遠隔操作は、オプティマスの能力や市場への適合性に関して疑問を投げかける結果となりました。 投資家からも、イベントの内容に失望する声が上がっています。 しかしながら、オプティマスの実演は、その将来の可能性を示す機会になったと評価する意見もあります。 従業員以外がオプティマスと直接触れ合ったのは、今回のイベントが初めてでした。 引用元: https://www.bloomberg.co.jp/news/articles/2024-10-15/SLD9H0T0G1KW00 この動画がすごい！ 今週のおすすめVTuber動画(～10月11日） この記事は、10月11日までに公開されたVTuber動画の中から、特にユニークで技術力や企画力の高い、または時事性のあるおすすめ動画を5本紹介しています。 1つ目は、初見そらによるVRChat初心者向け動画「VRChatでお友達を作る4つの方法(前編)」です。VRChatで友達を作るための具体的な方法として、インスタンスの仕組みやハッシュタグの活用法などを丁寧に解説しており、VRChatの基本操作を習得した初心者にとって非常に役立つ内容となっています。後編も期待されます。 2つ目は、ドクター・デリートによる「【電子工作】VRChatからロボットアームを遠隔操作して遊んでみた」です。VRChatからロボットアームを遠隔操作する技術が紹介されており、その発想と実現力に驚かされます。ブロックキャッチやイライラ棒への挑戦を通して、この技術の応用範囲の広大さが示唆されています。 3つ目は、レオン・ゼロミヤとぽんぽこのオフコラボ動画です。個人VTuberとして活動する2人の本音トークを通して、VTuber活動の現実や、VTuberならではの価値観、キャラクターの重要性などが語られています。個人VTuberとして成功している2人の経験談は、今後のVTuberの進化を考える上で貴重なヒントとなります。 4つ目は、周央サンゴの新衣装お披露目配信です。従来のお披露目とは異なり、会話の内容に合わせて姿や背景が変化する、独特の演出が施されています。TRPGを得意とする周央サンゴらしい、視聴者を巻き込む演出が特徴的です。 これらの動画は、VTuberの技術力、企画力、そしてVTuber活動のリアルな側面を垣間見れる、見応えのある内容となっています。新人エンジニアの方にも、それぞれの動画の技術的な側面や、VTuberという文化への理解を深める上で参考になるでしょう。特に、ドクター・デリートの動画は、技術的な視点から見ると非常に興味深い内容です。VRChatと物理的なロボットアームを連携させる仕組みは、システム開発のヒントになるかもしれません。また、初見そらの動画は、ユーザーインターフェースデザインや、コミュニティ形成の戦略を考える上で参考になるでしょう。 引用元: https://www.moguravr.com/vtuber-weekly-2024-10-15/ お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

社内LT会にずんだもん先輩がpodcast放送の紹介で登壇してきました！ いつものエンジニア向けpodcast放送じゃなくてすみません。 これは放送100回に向けて何か出来ないかと思って作ったスライドショー付き放送のまとめアーカイブです。 皆さまのお手元のPCでもずんだもん先輩のLTを再現できます！ 以下サイトから配信中！ ※ スマホに対応してないのでPCから見てね 関連リンク スライドショー付きの動画配信を目的としたコンテンツ提供型Chatbotサービス(α版)と、そのデモ動画作ってみました 過去のスライド付き放送 20241004 番外編 20240911 PlayStation5 Pro発表、AWSでのAI活用、アイドル業界のリアル 20240903 VTuber独立、AI生成キャラクターの今、インターン奮闘記事、自衛隊アニメ 20240827 ブラジリアン・ミクの衣装、トラウマになるアニメのシーン、ゲーム開発におけるDEI ※ スマホに対応してないのでPCから見てね

今日で放送100回目なのだ。何気なくはじまったこのpodcastだけど、なにげに続いてびっくりなのだ。これからも技術トレンドをお届けしていくのでよろしくなのだ。次の節目は250回で開局約1年。その次は500回、1000回…って1000回もやってるのかな。 <h2 id="関連リンク">関連リンク</h2> <ul> <li><a href=""></a></li> </ul> <p>**</p> <p>「SuperImage」は、C++で開発された高速画像処理ライブラリです。画像の読み込み、書き込み、フィルタリング、変換といった基本的な機能に加え、高度な画像解析機能も提供しています。特に、大規模画像データの処理に特化しており、並列処理による高速化を実現しています。新人エンジニアの方でも扱いやすいよう、シンプルで分かりやすいAPI設計を採用しています。</p> <p><strong>概要:</strong></p> <p>本ライブラリは、様々な画像フォーマットに対応し、高速な処理速度を追求しています。 主要な機能として、画像の拡大縮小、回転、色空間変換、ノイズ除去、エッジ検出などが挙げられます。 内部的には、マルチスレッド処理を活用することで、大規模な画像データに対しても効率的な処理を実現しています。 ライブラリの依存関係は最小限に抑えており、導入も容易です。</p> <p><strong>制約:</strong></p> <p>現時点では、GPUによる高速化は実装されていません。また、サポートしている画像フォーマットは、JPEG、PNG、BMPに限定されています。今後のバージョンアップで、対応フォーマットの拡大やGPU対応を予定しています。 ライブラリは、Linux環境での動作検証が完了しており、WindowsおよびmacOS環境での動作については、今後検証を進めていきます。 エラー処理は、例外処理ではなく、エラーコードを返す方式を採用しています。 詳細なエラーコード一覧は、ドキュメントを参照してください。</p> <p><strong>補足:</strong></p> <p>このサンプル要約では、githubリポジトリの内容を想定し、概要と制約のみを記述しています。 使用方法や具体的なAPIの記述は省略しています。 新人エンジニアが理解しやすいよう、平易な言葉遣いを心がけ、技術的な専門用語は可能な限り避けています。 実際のドキュメントを入力していただければ、それに基づいた正確な要約を作成いたします。</p> <p>引用元:</p> <ul> <li><a href="https://venturebeat.com/ai/openais-swarm-ai-agent-framework-routines-and-handoffs/">OpenAI’s Swarm AI agent framework: Routines and handoffs</a></li> </ul> <p>OpenAIが公開した実験的なAIエージェントフレームワーク「Swarm」は、複数のAIエージェントを連携させるためのツールです。LangChainやCrewAIといった既存フレームワークと異なり、シンプルさと柔軟性を重視した設計が特徴です。</p> <p>Swarmの核心は「ルーチン」と「ハンドオフ」という2つの概念です。「ルーチン」はエージェントが実行する一連の命令、「ハンドオフ」はエージェント間のタスクの引き継ぎをスムーズに行う仕組みです。これにより、顧客対応システムのように、問い合わせの分類、販売、サポート、返金といった、それぞれ専門のエージェントが担当する多段階プロセスを効率的に構築できます。</p> <p>SwarmはChat Completions APIを使用しており、状態を保持しない（ステートレス）設計です。そのため、過去のやり取りを記憶して複雑な判断を行うようなタスクには向いていません。この点は制約となりますが、代わりに実装が容易で、開発者がエージェントの動作を細かく制御できます。必要に応じて外部のメモリ管理システムを導入することで、より高度な機能を実現できます。</p> <p>Swarmは正式なOpenAI製品ではなく、生産環境での利用を想定したものではありません。しかし、企業における業務自動化の可能性を探る上で貴重な知見を提供します。シンプルで分かりやすい設計は、マルチエージェントシステムの初心者にも扱いやすく、オープンソース化されているため、コミュニティによる発展が期待されます。</p> <p>ただし、Swarmのステートレスな性質や、AIによる自動化が雇用や公平性、セキュリティに与える影響については、注意深く検討する必要があります。 現状では、複雑な状況判断や過去の履歴を考慮した処理には不向きである点、セキュリティ対策の強化も課題として挙げられます。 それでも、Swarmはマルチエージェントシステムの理解と開発を促進し、人間の作業負担を軽減し、より戦略的な業務に集中できる環境を作る可能性を秘めていると言えるでしょう。</p> <p>引用元: https://venturebeat.com/ai/openais-swarm-ai-agent-framework-routines-and-handoffs/</p> <ul> <li><a href="https://play.ht/news/introducing-play-3-0-mini/">Introducing Play 3.0 Mini - A Lightweight, Reliable And Cost-efficient Multilingual Text-to-Speech Model</a></li> </ul> <p>Play.ht社は、軽量で信頼性が高く、費用対効果の高い多言語対応テキスト読み上げモデル「Play 3.0 Mini」を発表しました。これは、会話AIにおけるインタラクティブ音声技術の現状を前進させ、ユーザーエクスペリエンスを高めるという同社のミッションの一環です。</p> <p>Play 3.0 Miniの主な特徴は下記の通りです。</p> <ul> <li> <p><strong>高速性と効率性:</strong> 平均レイテンシ189ミリ秒(TTFB)を実現し、同社のこれまでのモデルの中で最速です。推論速度はPlay 2.0と比べて28%向上しています。LLMからのテキスト入力ストリーミングとオーディオ出力ストリーミングをサポートし、HTTP REST API、WebSockets API、SDK経由で使用できます。</p> </li> <li> <p><strong>多言語対応:</strong> 30以上の言語に対応し、多くの言語で複数の男女の声が用意されています。日本語、英語、スペイン語、フランス語、ドイツ語、イタリア語、ポルトガル語などは既に本番環境で使用可能です。APIとプレイグラウンドで利用できます。</p> </li> <li> <p><strong>高精度:</strong> 会話AIに最適なTTSモデルを目指し、レイテンシと精度において競合モデルを凌駕するよう設計されています。特に、電話番号や日付、通貨など重要な情報が誤読されないよう、英数字のフレーズに関する多様なデータセットでファインチューニングされています。数字や頭字語を人間のように自然なペースで読み上げます。</p> </li> <li> <p><strong>音声クローン技術の向上:</strong> 音声クローンにおいて最先端の性能を達成し、アクセント、トーン、イントネーションを正確に再現します。</p> </li> <li> <p><strong>WebSockets APIサポート:</strong> HTTP接続の開閉オーバーヘッドを大幅に削減し、LLMなどからのテキスト入力ストリーミングを容易にします。</p> </li> <li> <p><strong>費用対効果:</strong> 高ボリュームのスタートアップおよびグロースプランの価格を改定し、より控えめな要件のビジネス向けの新しいProプラン（月額49ドル）も導入しました。</p> </li> </ul> <p>Play 3.0 Miniは、今後数ヶ月間にリリース予定の効率的な多言語AIテキスト読み上げモデルの第一弾です。小型化と費用効率の向上により、デバイス上や大規模な環境での実行を可能にします。 高品質で自然な音声合成を必要とする様々なアプリケーション開発に役立つでしょう。</p> <p>引用元: https://play.ht/news/introducing-play-3-0-mini/</p> <ul> <li><a href="https://togetter.com/li/2449569">Excelで作った資料を電卓で計算してるって時々バカにされますが、外に出す資料は電卓で検算しないと危ないということを前職で学びました→様々な声が集まる</a></li> </ul> <p>この投稿は、Excelで作成した資料を電卓で検算するという行為について、様々な意見が寄せられた様子をまとめたものです。投稿者は、前職での経験から、外部提出資料は電卓による検算が不可欠だと主張しています。</p> <p>多くの意見は、Excelの計算結果の信頼性に疑問を呈しています。小数点以下の桁数の扱いや、表示されていない数値、数式の適用漏れなど、Excel単体では検算が難しい点や、ヒューマンエラーの可能性が指摘されています。具体的には、SUM関数とSUBTOTAL関数の使い分け、LOOKUP関数やINDEX関数とMATCH関数の使用時の注意、横計による網羅性チェック、理論値との比較などが、Excelを用いた正確な計算のための対策として挙げられています。</p> <p>また、Excelの関数機能を適切に活用することで、多くの計算ミスは防げるとする意見もあります。例えば、小計を正確に計算し、表示書式の設定を適切に行うことで、検算の手間を軽減できる、といった指摘がなされています。</p> <p>一方で、電卓による検算が必ずしも最善の方法ではないという意見もあります。同じExcelシート内で二重チェックを行う、あるいはAccessなどの別のツールを用いて結果を検証するなど、より正確で効率的な検算方法が提案されています。</p> <p>重要なのは、Excelの計算結果を盲信せず、何らかの方法で検算を行うことで、ヒューマンエラーによるミスを防ぐことです。電卓を使うか否かは手段の一つであり、重要なのは、正確な数値を確保するための適切な手順を踏むこと、そして、その責任を負うことだと結論付けられます。 新人エンジニアの皆さんには、Excelの機能を理解し、適切な関数や手法を用いて正確な計算を行うこと、そして、必ず検算を行う習慣を身につけることを強く推奨します。 計算結果の正確性は、エンジニアとしての信頼性に直結します。</p> <p>引用元: https://togetter.com/li/2449569</p> <ul> <li><a href="https://forms.gle/ffg4JTfqdiqK62qf9">お便り投稿フォーム</a></li> </ul> <p>（株式会社ずんだもんは架空の登場組織です）</p>