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

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/

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が、独自のカスタムモデルをインポートして利用できる機能「Amazon Bedrock Custom Model Import」を一般提供開始しました。これにより、Meta Llama、Mistral Mixtral、IBM Graniteなどのファインチューニング済みモデルや、オープンソースアーキテクチャに基づいた独自開発モデルを、インフラ管理やモデルライフサイクル管理の手間なくAmazon Bedrockで利用できるようになります。

既存の基盤モデル（FM）と同様に、単一のAPIを通じてカスタムモデルにオンデマンドでアクセスでき、サーバーレス環境で利用可能です。Knowledge Bases、Guardrails、AgentsなどのAmazon Bedrockのネイティブツールや機能ともシームレスに統合され、開発者は一貫した開発エクスペリエンスを得られます。

主なメリット:

制約事項:

この機能は、独自データでモデルをカスタマイズし、チューニング済みモデルアーティファクトとそのデプロイメントに対する完全な所有権と制御を維持したいという顧客のニーズに応えるものです。 Amazon Bedrock Custom Model Importを利用することで、既存のカスタマイズへの投資を最大限に活用し、生成AIアプリケーション開発を加速できます。 ただし、本番環境での利用には、より多様なデータセットと適切なテスト、ハイパーパラメータチューニングによる継続的な実験が必要です。

引用元: https://aws.amazon.com/blogs/machine-learning/amazon-bedrock-custom-model-import-now-generally-available/

（株式会社ずんだもんは架空の登場組織です）

マイクロソフトは、来年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/

本記事は、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

Microsoftが開発したVPTQは、柔軟性が高く、極めて低ビット数の量子化アルゴリズムです。GitHubリポジトリで公開されており、MITライセンスの下で利用可能です。 このアルゴリズムは、少ないビット数で高精度な量子化を実現することを目指しており、特にメモリや計算リソースの制約が厳しい組み込みシステムやモバイルデバイスでの活用に適しています。リポジトリにはソースコード、issueトラッキング、プルリクエスト機能などが含まれていますが、具体的な使用方法や実装の詳細については、リポジトリ内のドキュメントを参照する必要があります。 現在、432個のスターと25個のフォークを獲得しており、活発に開発が進められていることが伺えます。 新人エンジニアの方にとって、低ビット量子化技術の学習や、実際の実装例を学ぶ上で有用なリソースとなるでしょう。ただし、実装には量子化に関する基礎知識が必要となります。

引用元: https://github.com/microsoft/VPTQ

（株式会社ずんだもんは架空の登場組織です）

この記事は、Kaggleコンペティション「LLM 20 Questions」に10日間だけ参加して5位入賞した著者が、その手法を詳細に解説したものです。著者は、MARCHレベルの物理系出身で、英語力・深層学習の知識共に専門家レベルではないと明言しています。Kaggle初心者や深層学習の基礎知識を持つエンジニアにとって、非常に参考になる内容です。

成功の鍵となったのは、Google Geminiの大規模言語モデルの活用です。API利用頻度と50万トークンものコンテキスト処理能力が必要だったため、Gemini以外では実現不可能だったと述べています。

著者は、Kaggleの情報を英語のまま処理するのではなく、コンペの概要、データ、ルール、ディスカッション、ノートブックをすべてGeminiで自動翻訳・要約し、マークダウン形式で整理するアプリケーションを開発しました。 このアプリケーションによって、英語の壁を乗り越え、Kaggleを日本語で完結に利用できる環境を構築しました。このアプリケーションはAWS Amplifyで公開されていますが、現在対応しているコンペティションは一つのみです。

コンペへの取り組みは、以下の3つのフェーズに分けられました。

各フェーズにおいて、作成したアプリケーションで生成されたマークダウン形式の情報をGeminiのプロンプトに与え、対話的に質問することで、コンペの理解を深め、最適な手法の選定と改良を行いました。 Geminiとの対話を通して、コンペで勝利するための本質的な要素を理解し、手法の改善に繋げることができたと述べています。

著者は、この手法によってKaggle初心者でも上位入賞を目指せる可能性を示唆しており、特にコンペ終盤、ディスカッションやノートブックの情報が豊富になった段階で有効であると結論づけています。 ただし、この手法は活発なコミュニティ参加が前提となるため、注意が必要です。

引用元: https://qiita.com/yukky_memo/items/6e1c7fa08b9b91278886

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で書かれたコマンドラインツールのバージョン管理は、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

Togetterに掲載された記事によると、一見模型のように見えるが、実際は段ボールで製造されたドローン実機が存在するとのことです。このドローンは使い捨てを前提として設計されており、航続距離100km、積載量1kg以上という性能を備えています。

記事では、段ボール製であることから低コストで大量生産が可能であると指摘しつつ、その軍事利用の可能性についても言及しています。 軽量で安価な段ボール製ドローンは、大量投入による攻撃や災害時の迅速な物資輸送など、様々な用途が想定されます。一方で、その手軽さから、悪用されるリスクも懸念されています。

技術的な詳細や具体的な製造方法は記事からは読み取れませんが、使い捨て前提の設計により、コストと性能のバランスを取った革新的なドローン開発の事例として注目を集めているようです。 日本のエンジニアの皆様にとって、この事例は、材料選定やコスト削減、そして新たな用途開発における一つの参考事例となるでしょう。特に、軽量化、低コスト化、大量生産といった課題に取り組む開発において、この段ボールドローンの設計思想は非常に興味深い示唆を与えてくれます。 ただし、軍事転用や倫理的な問題についても考慮する必要があることを忘れてはなりません。

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

（株式会社ずんだもんは架空の登場組織です）

この記事は、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/

PostgreSQLを用いたデータベース設計において、UNIQUE制約とインデックスの理解不足からパフォーマンス問題に遭遇した事例です。新人エンジニアが、採用管理システムの機能開発中に、オペレータとセミナーの多対多関係を表すassigned_seminarsテーブルを作成する必要に迫られました。 このテーブルには、website_id, operator_id, seminar_idといったカラムが含まれます。

複数のオペレータが担当するセミナーを検索するクエリと、特定セミナーの担当者を検索するクエリの両方を想定し、website_idとoperator_idの組み合わせにUNIQUE制約とインデックスを作成しました。しかし、上司からのレビューで、インデックスが重複している可能性を指摘されました。

そこで、以下の5パターンで実験を行いました。

大量のテストデータを用いて、特定のオペレータが担当するセミナーを検索するクエリの実行時間を比較しました。その結果、インデックスがない場合(1, 5)は実行時間が非常に長く、UNIQUE制約のみ(2)、インデックスのみ(3)は実行時間に大きな差がないことが分かりました。 さらに、UNIQUE制約とインデックスの両方を持つ場合(4)も、UNIQUE制約のみの場合(2)と実行時間に差がありませんでした。これは、PostgreSQLがUNIQUE制約を宣言したカラム順にインデックスを自動生成しているため、重複したインデックスを作成していたことを意味します。

さらに、新規データ挿入時のパフォーマンスも検証しました。 複数の担当者をセミナーに追加するINSERTクエリを実行した結果、インデックスが重複している場合、挿入にかかる時間が増加することが確認されました。ただし、このテーブルでは項目数が少なく、その影響は限定的でした。しかし、項目数が多いテーブルや、複雑なインデックスを持つテーブルでは、より顕著なパフォーマンス低下が予想されます。

この事例から、PostgreSQLではUNIQUE制約によって自動的にインデックスが作成されるため、重複したインデックスを作成しないよう注意が必要であることが分かりました。 テーブル設計時には、想定されるクエリを考慮し、適切なインデックスを作成することが重要です。 また、インデックスの重複はデータの挿入コスト増加につながるため、注意深く設計する必要があります。 この経験を通して、データベース設計におけるインデックスの重要性を再認識し、今後の設計やレビューに活かしていくと結論付けられました。

引用元: https://developers.techouse.com/entry/unique-index-conflict

この記事は、Visual Studio Code (VSCode) でTypeScriptの型ヒントをホバー表示する際に、プロパティが多いと型ヒントが省略されてしまう問題の解決策を説明しています。

問題の原因は、VSCodeのTypeScript言語サーバが、型ヒントの表示行数をデフォルトで160行に制限しているためです。 tsconfig.json に noErrorTruncation: true を追加しても解決しません。これはエラー時の型ヒント省略を防ぐオプションであり、今回の問題とは関係ありません。

解決策として、Node.jsスクリプトを用いて、言語サーバが参照するファイル内の defaultMaximumTruncationLength の値を直接変更する方法が提示されています。 このスクリプトは、VSCodeのTypeScript拡張機能のインストールディレクトリを指定し、表示行数の最大値を指定することで動作します。例えば、VSCodeのインストールディレクトリが~/.vscodeの場合、最大表示行数を1000行に設定するには、以下のコマンドを実行します。

このスクリプトは、vscode-typescriptを含む拡張機能ディレクトリを検索し、該当するJavaScriptファイル内のdefaultMaximumTruncationLengthを指定した値に書き換えます。 スクリプトの内容は、ファイル読み込み、置換、書き込みを行うシンプルなものです。 記事では、VSCodeの拡張機能を利用する方法もあると触れられていますが、自身で管理できる方法に焦点を当てています。

新人エンジニア向けに補足すると、この方法はVSCodeの内部ファイルの書き換えを伴うため、注意が必要です。 バックアップを取ってから実行し、問題が発生した場合は、元の状態に戻す準備をしておきましょう。 また、VSCodeの更新などによってスクリプトが動作しなくなる可能性があるため、その際はスクリプトの修正が必要になるかもしれません。 より安全な方法として、VSCode拡張機能の利用を検討することもできます。

引用元: https://zenn.dev/karan_coron/articles/dcab49bed5b2ff

（株式会社ずんだもんは架空の登場組織です）

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/

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は、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/

（株式会社ずんだもんは架空の登場組織です）

この記事は、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形式のログデータを効率的に処理する方法を解説しています。新人エンジニアにも分かりやすいように、基本的な操作から応用的なテクニックまで丁寧に説明されています。

概要:

大量のログデータは、しばしば圧縮された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

この記事は、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放送じゃなくてすみません。

皆さまのお手元のPCでもずんだもん先輩のLTを再現できます！

スライドショー付きの動画配信を目的としたコンテンツ提供型Chatbotサービス(α版)と、そのデモ動画作ってみました

20241004 番外編

※ スマホに対応してないのでPCから見てね

**

「SuperImage」は、C++で開発された高速画像処理ライブラリです。画像の読み込み、書き込み、フィルタリング、変換といった基本的な機能に加え、高度な画像解析機能も提供しています。特に、大規模画像データの処理に特化しており、並列処理による高速化を実現しています。新人エンジニアの方でも扱いやすいよう、シンプルで分かりやすいAPI設計を採用しています。

概要:

本ライブラリは、様々な画像フォーマットに対応し、高速な処理速度を追求しています。 主要な機能として、画像の拡大縮小、回転、色空間変換、ノイズ除去、エッジ検出などが挙げられます。 内部的には、マルチスレッド処理を活用することで、大規模な画像データに対しても効率的な処理を実現しています。 ライブラリの依存関係は最小限に抑えており、導入も容易です。

制約:

現時点では、GPUによる高速化は実装されていません。また、サポートしている画像フォーマットは、JPEG、PNG、BMPに限定されています。今後のバージョンアップで、対応フォーマットの拡大やGPU対応を予定しています。 ライブラリは、Linux環境での動作検証が完了しており、WindowsおよびmacOS環境での動作については、今後検証を進めていきます。 エラー処理は、例外処理ではなく、エラーコードを返す方式を採用しています。 詳細なエラーコード一覧は、ドキュメントを参照してください。

補足:

このサンプル要約では、githubリポジトリの内容を想定し、概要と制約のみを記述しています。 使用方法や具体的なAPIの記述は省略しています。 新人エンジニアが理解しやすいよう、平易な言葉遣いを心がけ、技術的な専門用語は可能な限り避けています。 実際のドキュメントを入力していただければ、それに基づいた正確な要約を作成いたします。

引用元:

OpenAIが公開した実験的なAIエージェントフレームワーク「Swarm」は、複数のAIエージェントを連携させるためのツールです。LangChainやCrewAIといった既存フレームワークと異なり、シンプルさと柔軟性を重視した設計が特徴です。

Swarmの核心は「ルーチン」と「ハンドオフ」という2つの概念です。「ルーチン」はエージェントが実行する一連の命令、「ハンドオフ」はエージェント間のタスクの引き継ぎをスムーズに行う仕組みです。これにより、顧客対応システムのように、問い合わせの分類、販売、サポート、返金といった、それぞれ専門のエージェントが担当する多段階プロセスを効率的に構築できます。

SwarmはChat Completions APIを使用しており、状態を保持しない（ステートレス）設計です。そのため、過去のやり取りを記憶して複雑な判断を行うようなタスクには向いていません。この点は制約となりますが、代わりに実装が容易で、開発者がエージェントの動作を細かく制御できます。必要に応じて外部のメモリ管理システムを導入することで、より高度な機能を実現できます。

Swarmは正式なOpenAI製品ではなく、生産環境での利用を想定したものではありません。しかし、企業における業務自動化の可能性を探る上で貴重な知見を提供します。シンプルで分かりやすい設計は、マルチエージェントシステムの初心者にも扱いやすく、オープンソース化されているため、コミュニティによる発展が期待されます。

ただし、Swarmのステートレスな性質や、AIによる自動化が雇用や公平性、セキュリティに与える影響については、注意深く検討する必要があります。 現状では、複雑な状況判断や過去の履歴を考慮した処理には不向きである点、セキュリティ対策の強化も課題として挙げられます。 それでも、Swarmはマルチエージェントシステムの理解と開発を促進し、人間の作業負担を軽減し、より戦略的な業務に集中できる環境を作る可能性を秘めていると言えるでしょう。

引用元: https://venturebeat.com/ai/openais-swarm-ai-agent-framework-routines-and-handoffs/

Play.ht社は、軽量で信頼性が高く、費用対効果の高い多言語対応テキスト読み上げモデル「Play 3.0 Mini」を発表しました。これは、会話AIにおけるインタラクティブ音声技術の現状を前進させ、ユーザーエクスペリエンスを高めるという同社のミッションの一環です。

Play 3.0 Miniの主な特徴は下記の通りです。

高速性と効率性: 平均レイテンシ189ミリ秒(TTFB)を実現し、同社のこれまでのモデルの中で最速です。推論速度はPlay 2.0と比べて28%向上しています。LLMからのテキスト入力ストリーミングとオーディオ出力ストリーミングをサポートし、HTTP REST API、WebSockets API、SDK経由で使用できます。

多言語対応: 30以上の言語に対応し、多くの言語で複数の男女の声が用意されています。日本語、英語、スペイン語、フランス語、ドイツ語、イタリア語、ポルトガル語などは既に本番環境で使用可能です。APIとプレイグラウンドで利用できます。

高精度: 会話AIに最適なTTSモデルを目指し、レイテンシと精度において競合モデルを凌駕するよう設計されています。特に、電話番号や日付、通貨など重要な情報が誤読されないよう、英数字のフレーズに関する多様なデータセットでファインチューニングされています。数字や頭字語を人間のように自然なペースで読み上げます。

音声クローン技術の向上: 音声クローンにおいて最先端の性能を達成し、アクセント、トーン、イントネーションを正確に再現します。

WebSockets APIサポート: HTTP接続の開閉オーバーヘッドを大幅に削減し、LLMなどからのテキスト入力ストリーミングを容易にします。

費用対効果: 高ボリュームのスタートアップおよびグロースプランの価格を改定し、より控えめな要件のビジネス向けの新しいProプラン（月額49ドル）も導入しました。

Play 3.0 Miniは、今後数ヶ月間にリリース予定の効率的な多言語AIテキスト読み上げモデルの第一弾です。小型化と費用効率の向上により、デバイス上や大規模な環境での実行を可能にします。 高品質で自然な音声合成を必要とする様々なアプリケーション開発に役立つでしょう。

引用元: https://play.ht/news/introducing-play-3-0-mini/

この投稿は、Excelで作成した資料を電卓で検算するという行為について、様々な意見が寄せられた様子をまとめたものです。投稿者は、前職での経験から、外部提出資料は電卓による検算が不可欠だと主張しています。

多くの意見は、Excelの計算結果の信頼性に疑問を呈しています。小数点以下の桁数の扱いや、表示されていない数値、数式の適用漏れなど、Excel単体では検算が難しい点や、ヒューマンエラーの可能性が指摘されています。具体的には、SUM関数とSUBTOTAL関数の使い分け、LOOKUP関数やINDEX関数とMATCH関数の使用時の注意、横計による網羅性チェック、理論値との比較などが、Excelを用いた正確な計算のための対策として挙げられています。

また、Excelの関数機能を適切に活用することで、多くの計算ミスは防げるとする意見もあります。例えば、小計を正確に計算し、表示書式の設定を適切に行うことで、検算の手間を軽減できる、といった指摘がなされています。

一方で、電卓による検算が必ずしも最善の方法ではないという意見もあります。同じExcelシート内で二重チェックを行う、あるいはAccessなどの別のツールを用いて結果を検証するなど、より正確で効率的な検算方法が提案されています。

重要なのは、Excelの計算結果を盲信せず、何らかの方法で検算を行うことで、ヒューマンエラーによるミスを防ぐことです。電卓を使うか否かは手段の一つであり、重要なのは、正確な数値を確保するための適切な手順を踏むこと、そして、その責任を負うことだと結論付けられます。 新人エンジニアの皆さんには、Excelの機能を理解し、適切な関数や手法を用いて正確な計算を行うこと、そして、必ず検算を行う習慣を身につけることを強く推奨します。 計算結果の正確性は、エンジニアとしての信頼性に直結します。

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

（株式会社ずんだもんは架空の登場組織です）

Googleは、最先端のオープンLLMファミリーに最新モデルGemma 2を追加リリースしました。Hugging Faceエコシステムとの最適な統合を確保するため、Googleと協力しています。Hugging Face Hubで、4つのオープンウェイトモデル（ベースモデル2つとファインチューニング済みモデル2つ）を利用できます。

Gemma 2は、90億パラメータと270億パラメータの2つのサイズで、ベース（事前学習済み）とインストラクションチューニング済みのバージョンが提供されます。Geminiをベースとし、コンテキスト長は8000トークンです。270億パラメータモデルは13兆トークン、90億パラメータモデルは8兆トークンのウェブデータ（主に英語）、コード、数学データで学習されました。データ量は前バージョンより約2倍です。

Gemma 2の技術的進歩は、以下の4点です。

スライディングウィンドウアテンション: メモリと計算時間を削減するため、層ごとに交互にスライディングウィンドウアテンションと完全二次アテンションを使用します。

ロジットソフトキャッピング: ロジットの過剰な増加を防ぎ、トレーニングの安定性を向上させます。

知識蒸留: より大規模な教師モデルを利用して、小型モデル（90億パラメータモデル）を学習します。

モデルマージング: 複数のLLMを単一のモデルに統合する技術（Warpを使用）

Gemma 2はGoogle Cloud TPUでJAXとML Pathwaysを使用してトレーニングされました。インストラクションチューニング済みのモデルは、対話アプリケーション向けに最適化されており、合成データと人間が生成したプロンプト応答ペアを組み合わせたデータで学習されました。

評価では、いくつかのベンチマークにおいて、他のオープンLLMと比較して高い性能を示しました。Hugging Face Transformers v4.42.0以降で利用でき、8ビットまたは4ビットモードでメモリ消費量を削減できます。Google CloudやHugging Face Inference Endpointsとの統合も提供されます。また、Hugging Face TRLを用いたファインチューニングも容易です。ライセンスは再配布、ファインチューニング、商用利用、派生作品の作成を許可する許容的なライセンスです。

本要約は、新人エンジニアが理解しやすいよう、技術的な詳細を避け、概要と主要な特徴に絞って記述しています。詳細な使用方法や技術的な説明については、原文を参照ください。

引用元: https://huggingface.co/blog/gemma2

LegalOn Technologiesの検索・推薦チームが、社内プロダクトマネージャー(PdM)向けに作成した「検索推薦システム入門」資料が公開されました。この資料は、先日開催された入門講座の内容をまとめたものです。

資料では、検索推薦システムの基本的な概念や仕組みについて、PdMが理解しやすいように解説しています。複雑な技術的な詳細は避け、PdMが製品開発や戦略立案に役立つ知識を習得できるよう、要点に絞った構成になっています。 具体的にどのような内容が含まれているかは本文からは分かりませんが、PdMが検索推薦システムを効果的に活用するための基礎知識を網羅していると考えられます。

この資料によって、PdMは検索推薦システムの機能や可能性を理解し、自社プロダクトにおける適切な活用方法を検討できるようになるでしょう。結果として、ユーザー体験の向上やプロダクトの改善に繋がる効果が期待できます。 新人エンジニアにとっても、検索推薦システムの概要を把握し、PdMとの円滑なコミュニケーションを図る上で役立つ資料となるでしょう。 資料の具体的な内容や使用方法については、公開された資料をご確認ください。

引用元: https://tech.legalforce.co.jp/entry/introduction-to-search-and-recommender-systems-for-pdm

ラウンドワンとVTuberグループ「ホロライブ」のコラボレーションキャンペーンが、2024年10月11日(金)から2025年1月13日(月)まで開催されます。

今回のコラボでは、白上フブキ、猫又おかゆ、一伊那尓栖、がうる・ぐら、IRyS、フワワ・アビスガード、モココ・アビスガードの7名のホロライブ所属ライバーが、描き下ろしイラストで登場します。 イラストは、カラオケマイクやボウリングの球を持った、ラウンドワンを楽しんでいる様子が描かれています。

キャンペーンは、日本国内の全ラウンドワン店舗に加え、アメリカ合衆国にあるラウンドワン店舗でも実施されます。具体的なキャンペーン内容は、ラウンドワンの公式サイトと公式Xアカウントで確認できます。

簡単に言うと、人気VTuberグループ「ホロライブ」のメンバーがデザインされたグッズやキャンペーンが、全国（そしてアメリカの一部）のラウンドワンで約3ヶ月間展開されるということです。ボウリングやカラオケを楽しめるラウンドワンで、ホロライブの世界観を体験できる機会となります。 詳細なキャンペーン内容については、公式サイトをご確認ください。

引用元: https://www.inside-games.jp/article/2024/10/11/160337.html

（株式会社ずんだもんは架空の登場組織です）

アレン人工知能研究所（Ai2）が、720億パラメーターのオープンソース・マルチモーダル言語モデル「Molmo」を発表しました。これは、GPT-4oを含む、大規模言語モデルと肩を並べる、もしくは凌駕する性能を持つとされています。

注目すべき点は、Molmoが従来の大規模モデルとは異なり、厳選された高品質なデータセットで訓練されている点です。具体的には、60万枚の画像と、それらに対する人間の詳細な音声説明（AIでテキスト化）を用いることで、膨大なデータと計算リソースを必要とする従来の手法に比べて、効率的に高性能なモデルを実現しました。 この高品質なデータと効率的な訓練方法が、GPT-4o超えの性能につながった要因です。

Molmoは複数のモデルから構成され、最も大規模なモデルは720億パラメーターですが、70億パラメーターの小型モデルも高い性能を示します。 また、画像内の特定の要素を「指し示す」機能も備えています。これは、画像認識だけでなく、ユーザーインターフェースとのより高度なインタラクションを可能にする重要な機能です。

Ai2はMolmoをオープンソースとして公開しており（一部モデルを除く）、開発者による様々なアプリケーション開発や、モデル自体の改良を促進することを目指しています。 これは、高価な独自開発モデルではなく、オープンソースモデルでも最先端の性能が実現可能であることを示す事例として、注目されています。 Ai2は、オープンソースアプローチによるAI開発の効率性と持続可能性を強調しています。

引用元: https://www.technologyreview.jp/s/346844/a-tiny-new-open-source-ai-model-performs-as-well-as-powerful-big-ones/

カナダのウォータールー大学数学専攻のHudZah氏は、ハードウェアや回路設計の経験がないにも関わらず、わずか4週間で自宅の寝室に核融合装置を自作し、プラズマ生成に成功しました。

この快挙は、生成AI「Claude 3.5 Sonnet」と友人たちの協力を得て実現しました。Claude 3.5 Sonnetの「Projects」機能を使い、PDFなどの資料をAIに学習させ、設計や部品選定、回路設計などの課題を解決しました。部品はMcMaster-Carrから調達しました。

装置は、Olivia Li氏のニューヨークでの静電核融合炉製作プロジェクトを参考に、静電場を用いて重水素イオンを加速・衝突させ、核融合を起こす仕組みです。高真空環境を維持するためにMKS Instruments製の真空計「MKS 901P」を使用し、真空漏れ対策に苦労しました。最終的に25ミクロン（約3.3Pa）の低圧まで到達しました。

高電圧電源にはネオンサイン変圧器（NST）を使用し、12kVのNSTを入手後、プラズマ生成に成功しました。マルチメーターがなかったため、Arduinoを用いて回路の導通確認を行いました。

HudZah氏は、今後はプラズマ制御と核融合反応の実現を目指しています。この事例は、AIを活用した革新的な試みと、限られた時間と資源の中で不可能を可能にする創意工夫を示す、非常に興味深いものです。新人エンジニアにとって、AIの活用や問題解決能力の重要性、そして困難な課題にも諦めずに挑戦する姿勢を示す良い事例と言えるでしょう。

引用元: https://engineer.fabcross.jp/archeive/241009_nuclear-fusor.html

リクルートの不動産情報サイト『SUUMO』は、基盤となる仮想化ソフトウェアのサポート期限切れ（EOSL）、「2027年問題」に直面しました。特に、賃貸・新築マンションなど複数の事業領域で利用される12万件以上のジョブからなる大規模な横断バッチシステムの移行は、非常に困難な課題でした。

本記事では、このプロジェクトを率いた花島氏と松野氏へのインタビューを通して、その取り組みが詳細に紹介されています。 難しさは、膨大なジョブ数、古くて担当者不明のシステム、そして多くのステークホルダーの存在にありました。

プロジェクト成功の鍵は、以下の3点です。

徹底した事前検証とリスク管理: 通常開発とは異なり、要件定義の前段階で性能テストを実施。リスクをゼロにするのではなく、リスクを前提にコントロールすることで、影響範囲を限定しました。 さらに、関係者不明なバッチのオーナー特定にも取り組みました。

分割移行と柔軟な対応: リスク軽減のため、横断バッチを分割して段階的に移行。各フェーズでの振り返りを重視し、課題を迅速に改善することで、全体スケジュールへの影響を最小限に抑えました。 また、優先順位を明確化し、ステークホルダーとの合意形成を図ることで、計画変更にも柔軟に対応しました。プロジェクトと各領域の二元体制を構築し、情報共有を密にすることで、効率的な開発と品質管理を実現しました。

積極的な改善と「ゼロをプラス」への転換: 単なるシステム移行ではなく、CI/CDツールの標準化や不要機能の削除など、保守運用性の向上にも取り組みました。EOSL対応を「マイナスをゼロにする」保守的な作業ではなく、「ゼロをプラスにする」攻めのプロジェクトとして推進することで、事業貢献につなげました。 定期的なロングミーティングで関係者間の共通認識を徹底し、言葉の定義から丁寧にすり合わせることで、認識のずれによるトラブルを防ぎました。

このプロジェクトは、大規模システムのEOSL対応におけるベストプラクティスを示しており、日本のエンジニア、特に新人エンジニアにとって貴重な学びとなるでしょう。 特に、リスク管理、段階的移行、ステークホルダーとのコミュニケーション、そして継続的な改善の重要性が強調されています。 大規模プロジェクトにおける課題解決のヒントとして、ぜひ参考にしてください。

引用元: https://hatenanews.com/articles/2024/10/09/103000

（株式会社ずんだもんは架空の登場組織です）