(株)Qualiteg - LLM - Qualiteg Blog (Page 2)

LLM

日本語対応 LLMランキング2025　～ベンチマーク分析レポート～(12月18日版)

⚠️ この記事よりも新しい記事があります最新のLLMランキング(2026年3月版)記事はこちらです最新(2026年3月版)のLLMランキングを見る → はじめに本レポートは、Nejumi Leaderboard 4のベンチマークデータ（2025/12/18版）に基づいて、日本語対応LLMの性能を総合的に分析したものです。前回は 2025/10/12 版の分析レポートを公開しましたが、たった2か月で劇的な変化がありました！（定期的に最新LLMランキングを更新してまいります。当社のX(旧Twitter)をフォローいただくことで更新情報を受け取り可能です） Nejumi Leaderboard 4は、日本語タスクにおけるLLMの性能を多角的に評価する信頼性の高いベンチマークとして知られています。本分析では、商用APIモデルとオープンモデルの両方を対象に、それぞれの特徴や傾向を詳しく見ていきます。オープンソースモデルについて Weightがオープンなモデルは場合によっては「オープンソースモデル」、「OSSモデル」と呼ば

AIエージェント

AIコーディングエージェント20選！現状と未来への展望【第1回】全体像と基礎

こんにちは！今回は、20種類以上あるまさに百花繚乱なAIコーディングツールを一挙に紹介＆解説していきたいとおもいます！ AIをつかったコーディングはもはや常識となり、日々目まぐるしく新しいツールが登場しています。当社でも自社開発のAIコーディングツールをふくめ複数のツールを活用してソフトウェア開発をすすめていますが、次々とナイスなツールがでてきて興奮しつつも、正直キャッチアップが追いつかない…！という状況です。「結局どれを使えばいいの？」「Claude CodeとCursorって何が違うの？」「オープンソースでも使えるやつあるの？」——そんな疑問を持っている方も多いのではないでしょうか。そこで本シリーズでは、2025年12月時点でのAIコーディングツールを徹底的に整理してみました。商用サービスからオープンソースまで、20以上のツールを比較しながら、それぞれの特徴や使いどころ、そして現時点での限界についても現場視点をいれながら正直にお伝えしていければとおもいます ※「AIコーディングツール」は「コーディングエージェント」といったほうが今風なので記事内ではコーディングエー

LLM

Anthropic Python SDKのcount_tokens機能が0.75.0～正式版に変わりました：移行ガイド

こんにちは！本日は Anthropic Claude API を使用するのに便利な Anthropic Python SDK に関する話題です！ 2週間ほど前にわりと大きな変更がありましたので、解説いたします。はじめに「あれ、client.count_tokens() が動かない...」 Anthropic Python SDKをアップデートしたら、今まで動いていたトークンカウントのコードがエラーになった。そんな経験をされたLLMエンジニアの方も多いのではないでしょうか。当社のBestllamのように、LLM統合サービスを開発していると、実際にユーザーがどれほどのトークンを使用しているのかを正確に把握することは非常に重要になります。利用料金の計算、コンテキストウィンドウの管理、そしてユーザーへの使用量の可視化など、トークンカウント機能はサービスの根幹を支える機能です。そのため、この機能が突然動かなくなると影響は小さくありません。ゆえに本番サービスを提供している場合、pip install で気軽にSDKバージョンを上げてはいけません。さて、Anthropi

LLM

Model Context Protocol完全実装ガイド 2025- 仕様変遷から最新Streamable HTTPまでの全て

こんにちは！現在、LLM業界で破竹の勢いでひろまっているMCPについて、本日はとくに実装面について解説していきたいとおもいます。 MCP、MCPとひとくちにいっていますが、実は短期間でけっこう「標準」とよばれる仕様が変化しておりますので、仕様のバリエーションを順を追って解説しつつ、実際に実装をしていきたいとおもいます。さて、MCPですが、2024年後半、Anthropicが発表したModel Context Protocol（MCP）は、AI分野における重要な転換点となりました。従来、各AIベンダーが独自に実装していたツール呼び出し機能(tool useと呼びます）を標準化し、AIモデルと外部システムの連携を統一的に扱える仕組みを提供しました本記事で、MCPの誕生から現在に至るまでの技術的変遷を詳細に追いながら、2025年時点での最適な実装方法を完全なソースコードと共に解説します。特に、仕様の変化に振り回されがちな実装者の視点から、なぜ現在の形に収束したのか、そして今後どのような実装アプローチを取るべきかを明確にしていきます。第1章 MCPが解決しようとした問題

LLM

日本語対応 LLMランキング2025　～ベンチマーク分析レポート～

はじめに本レポートは、Nejumi Leaderboard 4のベンチマークデータ(2025/10/11版)に基づいて、日本語対応LLMの性能を総合的に分析したものです。 Nejumi Leaderboard 4は、日本語タスクにおけるLLMの性能を多角的に評価する信頼性の高いベンチマークとして知られています。本分析では、総合スコアとコーディングスコアの2つの観点から、商用APIモデルとオープンモデルの両方を対象に、それぞれの特徴や傾向を詳しく見ていきます。オープンソースモデルについて Weightがオープンなモデルは場合によっては「オープンソースモデル」、「OSSモデル」と呼ばれますが、モデルによっては「オープンソース」と呼ぶには不十分な場合があるため本稿では、「オープンソースモデル」ではなく「オープンモデル」と表現しています。ベンチマーク分析について本レポートは、LLM選択の参考情報として、ベンチマークデータから読み取れる傾向や特徴を提示するものです。最終的なモデル選択においては、これらの情報を踏まえつつ、実際の使用環境での検証を行うことをおすすめいたし

LLM

Claude 4.5 APIにおける画像入力のトークン数計算と最適化ガイド

こんにちは！今回は、Claude 4.5 sonnet/haiku、Claude 4.1 OpusをAPIからつかうときの画像のトークン数計算方法について詳しく解説します。画像トークン数の計算方法 Claude 4.5 APIに送信する画像は、テキストと同様にトークンとしてカウントされ、料金計算の基礎となります。画像がAPIのサイズ制限内でリサイズ不要な場合、以下の簡単な計算式でトークン数を推定できます。基本計算式トークン数 = (横幅px × 縦幅px) ÷ 750 この計算式を使用することで、アップロード前にコストを予測し、必要に応じて画像を最適化することが可能になります。例えば、1000×1000ピクセルの画像は約1334トークンを消費し、Claude 4.5の料金体系では、画像1枚あたりのコストを事前に計算できます。1092×1092ピクセル（1.19メガピクセル）の画像であれば約1590トークンとなり、これを基準にバッチ処理のコストも見積もることが可能です。画像サイズの制限と最適化 Claude 4.5 APIには画像サイズに関するいくつかの重要な

LLM

【OpenAI API】Vision対応LLMの画像トークン消費量計算法 2025年最新版

こんにちは！ OpenAIのVision対応(つまり画像も入力できるLLM）モデルは、画像をトークンに変換する際に2つの異なる計算方式を採用しています。最新のGPT-5系列やGPT-4.1系列では、従来のタイル方式とは異なるパッチベース方式が導入されました。この変更により、画像処理の効率性が大幅に向上し、より細かな制御が可能になっています。 2つの計算方式の違い OpenAIは現在、パッチベース方式とタイルベース方式という2つの計算方法を並行して運用しています。パッチベース方式は、GPT-4.1-mini、GPT-4.1-nano、GPT-5-mini、GPT-5-nano、o4-miniといった新世代モデルで採用されています。この方式では画像を32×32ピクセルという非常に小さなパッチに分割します。従来のタイル方式が512×512ピクセルだったことを考えると、約256分の1のサイズで処理することになり、より精密な画像理解が可能になりました。一方、GPT-4o、GPT-4.1、GPT-5、o1、o3などの主力モデルは引き続きタイルベース方式を採用しています。こちらは

LLM

LLM推論基盤プロビジョニング講座　第5回 GPUノード構成から負荷試験までの実践プロセス

こんにちは！これまでのLLM推論基盤プロビジョニング講座では、推論速度の定義、リクエスト数見積もり、メモリ消費量計算、推論エンジン選定について詳しく解説してきました。今回は、残りのステップである「GPUノード構成見積もり」「負荷試験」「トレードオフ検討」について一気に解説し、最後に実際のサーバー構成例をご紹介します。 LLM推論基盤プロビジョニング講座シリーズ記事一覧 * 第1回基本概念と推論速度 * 第2回 LLMサービスのリクエスト数を見積もる * 第3回使用モデルの推論時消費メモリ見積もり * 第4回推論エンジンの選定 * 第5回 GPUノード構成から負荷試験までの実践プロセス * 番外編 KVキャッシュのオフロード戦略とGQA STEP5：GPUノード構成見積もり GPUメモリから考える同時リクエスト処理能力 LLMサービスを構築する際、どのGPUを何台選ぶかは非常に重要な決断です。今回はLlama 8Bモデルを例に、GPUメモリ容量と同時リクエスト処理能力の関係を見ていきましょう。 GPUメモリの使われ方を理解するここは復習

LLM

LLM推論基盤プロビジョニング講座　第4回推論エンジンの選定

こんにちは！前回までの講座では、LLMサービス構築に必要なリクエスト数の見積もりや、使用モデルの推論時消費メモリ計算について詳しく解説してきました。今回は7ステッププロセスの4番目、「推論エンジンの選定」について詳しく掘り下げていきます。 LLM推論基盤プロビジョニング講座シリーズ記事一覧 * 第1回基本概念と推論速度 * 第2回 LLMサービスのリクエスト数を見積もる * 第3回使用モデルの推論時消費メモリ見積もり * 第4回推論エンジンの選定 * 第5回 GPUノード構成から負荷試験までの実践プロセス * 番外編 KVキャッシュのオフロード戦略とGQA 推論エンジンとは何か推論エンジンとは、GPU上でLLMモデルの推論計算（テキスト生成）を効率的に行うために設計された専用のソフトウェアプログラムです。一般的なディープラーニングフレームワーク（PyTorch、TensorFlowなど）でも推論は可能ですが、実運用環境では専用の推論エンジンを使用することで、大幅なパフォーマンス向上とリソース効率化が期待できます。推論エンジンは単なる実行環境ではなく

LLM

LLM推論基盤プロビジョニング講座　第3回使用モデルの推論時消費メモリ見積もり

こんにちは！前回はLLMサービスへのリクエスト数見積もりについて解説しました。今回は7ステッププロセスの3番目、「使用モデルの推論時消費メモリ見積もり」について詳しく掘り下げていきます。 LLM推論基盤プロビジョニング講座シリーズ記事一覧 * 第1回基本概念と推論速度 * 第2回 LLMサービスのリクエスト数を見積もる * 第3回使用モデルの推論時消費メモリ見積もり * 第4回推論エンジンの選定 * 第5回 GPUノード構成から負荷試験までの実践プロセス * 番外編 KVキャッシュのオフロード戦略とGQA GPUメモリがリクエスト処理能力を決定する LLMサービス構築において、GPUが同時に処理できるリクエスト数はGPUメモリの消費量によって制約されます。つまり、利用可能なGPUメモリがどれだけあるかによって、同時に何件のリクエストを処理できるかがほぼ決まります。では、その具体例として、Llama3 8B（80億パラメータ）モデルをNVIDIA RTX A5000（24GB）にロードするケースを考えてみましょう。このGPUには24GBのGPU

LLM

LLM推論基盤プロビジョニング講座　第2回 LLMサービスのリクエスト数を見積もる

こんにちは！今回はLLM推論基盤プロビジョニング講座　第2回です！ LLM推論基盤プロビジョニング講座シリーズ記事一覧 * 第1回基本概念と推論速度 * 第2回 LLMサービスのリクエスト数を見積もる * 第3回使用モデルの推論時消費メモリ見積もり * 第4回推論エンジンの選定 * 第5回 GPUノード構成から負荷試験までの実践プロセス * 番外編 KVキャッシュのオフロード戦略とGQA STEP2 LLMサービスへのリクエスト数見積もりそれでは、早速、LLM推論基盤プロビジョニングの第2ステップである「リクエスト数見積もり」の重要性と方法を解説いたします。 LLMサービスを構築する際に必要となるGPUノード数を適切に見積もるためには、まずサービスに対して想定されるリクエスト数を正確に予測する必要があります。リクエスト数見積もりの基本的な考え方 LLMサービスへの想定リクエスト数から必要なGPUノード数を算出するプロセスは、サービス設計において非常に重要です。過小評価すればサービス品質が低下し、過大評価すれば無駄なコストが発生します。こ

LLM

LLM推論基盤プロビジョニング講座　第1回基本概念と推論速度

こんにちは！本日は LLMサービスの自社構築する際の推論基盤プロビジョニング、GPUプロビジョニングについて数回にわけて解説いたします。はじめに LLMの進化に伴い、ChatGPTやClaudeといったパブリックなLLMの活用は企業においても急速に広がってきました。しかし先進的な企業はこれらの汎用LLMに加えて、「領域特化型」「ドメイン特化型」といった専用LLMの構築へと歩みを進めています。こうした動きの背景には、企業固有の専門知識への対応力強化と情報セキュリティの確保という二つの重要なニーズがあります。一般的なパブリックLLMでは対応できない企業固有の専門知識や機密情報の取り扱いが必要なケースが増えているため、自社LLMの構築や自社サーバーでの運用を検討する企業が急増しています。特に金融、医療、製造、法務といった専門性の高い領域では、業界特化型の独自LLMが競争優位性をもたらすと認識されています。しかし、業界特化型のLLMを自社で運用することは簡単ではありません。自社運用を決断した場合、まず最初に取り組むべきは適切な推論環境の整備です。オンプレミス環境を構築するに

LLM

Gemini 2.5 Pro/Flashにおけるマルチモーダルトークン(画像のトークン数、動画のトークン数など）計算ガイド

こんにちは！本日は、Gemini 2.5 ProおよびGemini 2.5 Flashを使用する際、料金計算やコンテキストウィンドウの管理において、トークン数の正確な把握は非常に重要です。本記事では、画像、動画、音声といったマルチモーダルコンテンツのトークン計算方法について詳しく解説します。基本概念：トークンとは Gemini 2.5シリーズにおいて、1トークンは約4文字に相当し、100トークンは約60-80語（英語）に相当します。すべての入力と出力はトークン単位で処理され、課金もトークン数に基づいて行われます。 Gemini 2.5シリーズのモデルと料金利用可能なモデル * Gemini 2.5 Pro: 高度な推論能力を持つフラグシップモデル * Gemini 2.5 Flash: コスト効率に優れた高速モデル * Gemini 2.5 Flash Image: 画像生成専用モデルコンテキストウィンドウ両モデルとも1,000,000トークンの大規模なコンテキストウィンドウを提供します。

LLM

【解説】Tekken トークナイザーとは何か？〜 Mistral が採用する新世代トークナイザーの特徴

こんにちは！本日は、Tekkenについて解説いたします！皆さま Tekken と聞いて何を思い浮かべますか？格ゲーの鉄拳でしょうか？私は、昔プレイした Age of Empires に登場する鉄剣戦士を思い浮かべました🤗 ちょっと古いかもしれませんが、名作です！さてつかみはこのくらいにして、、 LLMはご存じのとおり驚異的なスピードで進化しています。そんな中でひそかに注目されているのが、トークナイザーの改善です。たとえば、Meta の Llama 系モデルのトークナイザーは Sentence Piece から BPE系へ進化するなど、LLM業界では従来よりも高効率なトークナイズ（テキスト分割）の方法を導入し始めています。そして Mistral AI もまた、新たに「Tekken トークナイザー」という仕組みを採用し、大規模言語モデルの性能を底上げしています。本記事では、Tekken トークナイザーの登場背景や技術的特徴、他のトークナイザーとの違い、さらには Mistral との関係などをわかりやすく解説していきます。 1. Tekken トーク

LLM

日本語対応！Mistral Small v3 解説

こんにちは！ Mistral AIは2025年1月30日、新しい言語モデル「Mistral Small v3」を発表しました。このモデルは、24Bという比較的小規模なパラメータ数ながら、70B以上の大規模モデルに匹敵する性能を実現しています。また日本語対応も謳われており期待の高い小型モデルです！ https://huggingface.co/mistralai/Mistral-Small-24B-Instruct-2501 動画こちら本ブログの解説動画もご覧いただけます😊 きわだってるのは、レイテンシー最適化 Mistral Small 3のめだった特徴は、その処理性能とレイテンシーの絶妙なバランスではないでしょうか。公開されている以下の性能評価のグラフによると、トークンあたり約11ミリ秒という業界最速レベルのレイテンシーを達成しています。これは、Qwen-2.5 32Bの約15ミリ秒やGemma-2 27Bの約14ミリ秒と比較して、明確な優位性を示しています。さらに注目すべきは、GPT-4o Miniと比較しても、より低いレイテンシーで同等以上の性能を実現し

LLM

[vLLM] To use CUDA with multiprocessing, you must use the 'spawn' start method の対処法

WSLで vLLM を使用するとき、 tensor parallel を使って複数枚のGPUで1つのLLMをサーブしようとしたとき以下のようなエラーが発生しがちです RuntimeError: Cannot re-initialize CUDA in forked subprocess. To use CUDA with multiprocessing, you must use the 'spawn' start method 遭遇するシーンとしてはvLLMの起動オプションに以下のようにテンソル並列化オプションを指定したときです。 --tensor-parallel-size 2 つまり、マルチプロセッシングでCUDA使うときは、 "fork"じゃなくて"spawn" 使ってね、というエラーです。これを vLLM に教えるために、以下の2行目のように環境変数を設定してあげるとvLLMが "spawn" を使ってくれるようになります。 export

日本語対応 LLMランキング2025 ～ベンチマーク分析レポート～(12月18日版)

AIコーディングエージェント20選！現状と未来への展望 【第1回】全体像と基礎

Anthropic Python SDKのcount_tokens機能が0.75.0～正式版に変わりました：移行ガイド

Model Context Protocol完全実装ガイド 2025- 仕様変遷から最新Streamable HTTPまでの全て

日本語対応 LLMランキング2025 ～ベンチマーク分析レポート～