本日、 Amazon Bedrock と Claude Platform on AWS で Claude Fable 5 が利用可能になったことをお知らせいたします。Claude Fable 5 は、Mythos レベルの機能をすべてのお客様が利用できるようにするとともに、より広く安全に使用できるように設計された強力な保護手段を備えています。Fable 5 は、テストされたほぼすべてのベンチマークで最先端であり、ソフトウェアエンジニアリング、ナレッジワークタスク、ビジョンにおいて並外れたパフォーマンスを発揮し、野心的で長期にわたる作業向けに構築されています。 Claude Fable 5 on Bedrock を使用すると、既存の AWS 環境内で構築し、推論ワークロードをスケールできます。また、Claude Platform on AWS を通じて Claude Fable 5 を使用することも可能です。これにより、Anthropic のネイティブプラットフォームエクスペリエンスが得られます。 Anthropic によると、Claude Fable 5 は、AI モデルで達成できることの段階的な変化を表しています。このモデルの利点は次のとおりです。 長時間の非同期実行 – Claude Fable 5 は、以前のモデルでは維持できなかった複雑なタスクを処理し、コーディングやナレッジワークのタスクを介入なしに長期間実行します。 高度なビジョン機能 – Claude Fable 5 は、ファイルや PDF にネストされた図、チャート、表を理解します。これにより、財務、法務、分析、建築、ゲームにおけるリサーチや文書を多用する作業が可能になります。コーディングでは、モデルは忠実度の高い設計を実装し、ビジョンを使用してそのアウトプットを目標と照らし合わせます。 積極的な自己検証 – 本モデルは学習内容に基づいてスキルを自己更新し、独自のハーネスと評価を開発します。 Claude Fable 5 には、誤用のリスクが高い特定の領域でのパフォーマンスを制限する保護手段が含まれています。サイバーセキュリティ、生物学、化学、健康に関連する有害なプロンプトは、代わりに Opus 4.8 からの応答を受け取るようにフォールバックします。Anthropic はより強力な保護手段を開発することで、Claude Fable 5 の最先端機能のほぼすべてへのアクセスを拡大することができます。制限のない同一モデルが Claude Mythos 5 であり、精査された少数のお客様のみが利用できます。 動作中の Claude Fable 5 モデル Claude Fable 5 は Amazon Bedrock と Claude Platform on AWS の両方でご使用いただけます。この投稿では、Amazon Bedrock へのアクセス方法と使用方法に関するガイダンスをご紹介します。Claude Platform on AWS に関するガイダンスについては、 ドキュメント にアクセスして詳細をご確認ください。 Amazon Bedrock の使用を開始するには、 Anthropic Messages API を使用してプログラムでのみモデルにアクセスし、Anthropic SDK を介して bedrock-runtime エンドポイントまたは bedrock-mantle エンドポイントを呼び出します。 AWS コマンドラインインターフェイス (AWS CLI) と AWS SDK を介して bedrock-runtime の Invoke API と Converse API のみ引き続き使用できます。 コンソールのサポートは近日開始予定です。 Claude Fable 5 モデルにアクセスするには、モデルを呼び出す前に Data Retention API を使用し、 provider_data_share を設定してデータ共有を有効にする必要があります。リリース時には、この設定用のコンソールユーザーインターフェイスはありません。 curl -X PUT https://bedrock-mantle.us-east-1.api.aws/v1/data_retention \ -H "x-api-key: <your-bedrock-api-key>" \ -H "Content-Type: application/json" \ -d '{ "mode": "provider_data_share" }' bedrock-runtime エンジンを使用している場合は、以下のサンプルスクリプトを実行してください。 curl -X PUT https://bedrock.us-east-1.amazonaws.com/data-retention \ -H "Authorization: Bearer <your_bearer_token>" \ -H "Content-Type: application/json" \ -d '{ "mode": "provider_data_share" }' このモードでは、Amazon Bedrock は推論データをモデルプロバイダーの要件に従って保持し、共有できます。Anthropic では、30 日間のインプットとアウトプットの保持と、人間によるレビューが必要です。詳細については、「 Amazon Bedrock の乱用検知 」をご覧ください。 まずは Anthropic SDK for Python から、 bedrock-mantle エンドポイントで Messages API を使ってみましょう。Anthropic SDK をインストールします。 pip install anthropic Claude Fable 5 モデルを呼び出すための Python コードのサンプルは次のとおりです。 import anthropic client = anthropic.Anthropic( base_url="https://bedrock-mantle.us-east-1.api.aws/anthropic", api_key= <your-bedrock-api-key> ) message = client.messages.create( model="anthropic.claude-fable-5", max_tokens=4096, messages=[ { "role": "user", "content": "Design a distributed architecture on AWS in Python that should support 100k requests per second across multiple geographic regions", }, ], ) print(message.content[0].text) 詳細については、複数のユースケースとさまざまなプログラミング言語に対応した Anthropic Messages API のコード例 と ノートブックの例 をご覧ください。 Bedrock コンソー ルで Claude Fable 5 を使用できるようになりました。 Playground で Claude Fable 5 を選択してテストします。 bedrock-mantle におけるコンソールサポートは近日中に実装予定です。 また、Claude Fable 5 を bedrock-runtime エンドポイントの Invoke API と Converse APIと併用することもできます。AWS SDK for Python (Boto3) を使用して Converse API を呼び出し、統一されたマルチモデルエクスペリエンスを実現する例を次に示します。 import boto3 bedrock_runtime = boto3.client("bedrock-runtime", region_name="us-east-1") response = bedrock_runtime.converse( modelId="global.anthropic.claude-fable-5", messages=[ { "role": "user", "content": [ { "text": "Design a distributed architecture on AWS in Python that should support 100k requests per second across multiple geographic regions." } ] } ], inferenceConfig={ "maxTokens": 4096 } ) print(response["output"]["message"]["content"][0]["text"]) 詳細については、AWS SDK を使用して Amazon Bedrock ランタイムを使用する方法を示す コード例 をご覧ください。 知っておくべきこと 役立つと思われる重要な技術的詳細をいくつかご紹介します。 モデルアクセス – Claude Fable 5 へのアクセスは、すべての AWS アカウントに徐々に拡張されます。アカウントにまだアクセスできない場合は、Bedrock の使用状況にもよりますが、すぐに有効になります。このモデルにすぐにアクセスしたい場合は、通常の AWS サポートにお問い合わせください。 価格設定 – 有害なプロンプトが Fable 5 ではなく Opus 4.8 にルーティングされた場合、支払うのは Opus の料金のみです。会話の途中でリクエストがブロックされた場合、最初のトークンは Fable レートで請求され、その後のトークンはOpus レートで請求されます。詳細については、「 Amazon Bedrock の料金 」ページにアクセスしてください。 データ保持 – 同等かそれ以上の機能レベルを持つBedrock の Fable 5、Mythos 5、および将来のモデルでは、Anthropic は Mythos クラスモデルのすべてのトラフィックを 30 日間保存する必要があります。データを一定期間保持することで、Anthropic は、1 回のやりとりでは見えない悪用のパターンを検出できます。データ保持を選択すると、データは AWS のデータとセキュリティの境界から外れます。 Claude Mythos 5 on Bedrock (限定プレビュー) – 脆弱性の発見、ドラッグデザイン、バイオディフェンススクリーニングなど、サイバーセキュリティとライフサイエンスに関する Anthropic の最も有能なモデルも使用できます。これらのドメインは二重使用であるため、現在アクセスは制限されています。詳細については、 モデルカードのドキュメント をご覧ください。 今すぐご利用いただけます Anthropic の Claude Fable 5 モデルは、本日から、米国東部 (バージニア北部) および欧州 (ストックホルム) リージョンの Amazon Bedrock でご利用いただけます。今後のアップデートについては、 リージョンの全リスト をご確認ください。Claude Fable 5 は、北米、南米、欧州、アジアパシフィックリージョンの Claude Platform on AWS でもご利用いただけます。 Claude Platform on AWS の Amazon Bedrock API を使用して Claude Fable 5 をお試しいただき、 AWS re:Post for Amazon Bedrock に、または AWS サポートの通常の連絡先を通じて、ぜひフィードバックをお寄せください。 – Channy 原文は こちら です。

2026年6月10日未明（日本時間）、Anthropicが新モデル Claude Fable 5 を発表しました。（ 原文 ） Fable 5は、悪用リスクへの懸念から限定組織のみに提供されている上位モデル Mythosと中身が同じ で、違いは一部の危険領域タスクに制限がかかる点だけです。 発表の要点＋背景をまとめました。 概要 Fable 5 は、最上位モデルであるMythosを一般向けに安全化して公開したモデルです。 ポイントは3つです。 性能 :ほぼすべてのベンチマークで最高水準。タスクが長く複雑なほど他モデルとの差が開く。 安全設計 :サイバーセキュリティ・生物化学・蒸留などの高リスク領域だけ、Fableに代わって下位モデルが応答。発動は全セッションの5%未満で、 残り95%超は実質Mythos と同じ。 課金 : 本日から従量課金APIで利用可。サブスク勢は6/22まで無料利用可能、6/23以降は従量課金のみでの提供。余裕ができ次第、サブスク提供に復帰を目指す ざっくり、Mythosのこれまでの経緯 「Mythos」は、現状Claudeで最高性能モデルである、Opusの上に位置する最上位ティアの呼び名です。 その第1弾モデルとして2026年4月に登場したのが「Claude Mythos Preview」でした。 話題になったのは、性能の高さもさることながら、 サイバーセキュリティ能力が高すぎた ためです。 あらゆる主要OS・ブラウザの脆弱性を見つけてしまうほどで、悪用されれば重要インフラへの攻撃に使われかねない、という懸念から、一般公開されませんでした。 代わりにAnthropicは「Project Glasswing」という枠組みを立ち上げ、サイバー防衛側の組織や重要インフラ事業者など、限られた相手にだけMythosをPreview提供してきました。 「いずれ安全に提供できる体制が整えば一般公開したい」とは表明していたものの、これまでは触れられる人がごく一部に限られていた、というのがこれまでの状況です。 そして今回、その「安全に出せる体制」が整ったとして登場したのが Fable 5(= セーフガード付きの一般公開版)という経緯です。 Mythosはどれだけすごいのか まずは能力面です。同じ基盤モデルである Mythos 5 / Fable 5 が示した成果を見ると、世代の差を感じます。 ベンチマーク （画像: Anthropic公式発表より） どの領域でも大きく向上しています。   ソフトウェアエンジニアリング Stripeが、5,000万行に及ぶRubyコードベース全体の移行を1日で完了させたと報告。 手作業ならチーム全体で2ヶ月以上かかる規模で、 トークン効率も従来より改善 。 文書・分析業務 金融系のシニアレベル推論ベンチ(Hebbia Finance Benchmark)で全モデル中最高スコア。 文書ベース推論、図表の読み取り、問題解決で大きく改善。 画像理解 ビジョン系タスクでもトップの成績で、スクリーンショットだけからWebアプリのソースコードを再構築可能。 従来モデルが手こずった「ポケットモンスターファイヤーレッド」を、最小限の画面のみ構成でクリア。 メモリ・長文脈 数百万トークンにわたり集中を維持し、自分のメモを使って出力を改善。 デッキ構築ゲーム『Slay the Spire』では、ファイルベースの記憶を与えるとOpus 4.8の3倍の性能向上が見られました。 科学研究 創薬:タンパク質設計プロセスを約10倍に加速。人間の補助なしで熟練オペレーターに匹敵・凌駕し、14の標的中9つで有望な候補を発見。 分子生物学:新規かつ説得力のある科学的仮説を一貫して生成できる初のモデル。盲検比較で、科学者がOpusクラスより約80%の確率でMythosの仮説を支持。ある仮説は独立した研究で裏付けられた。 ゲノミクス:1週間超のほぼ自律的な作業で、138種・数百万細胞のデータを扱い、Science誌掲載モデルを100分の1のサイズで上回るMLモデルを設計・訓練。 「使える道具」というより「自律的に研究を進める存在」に近づいている、という点が従来との大きな違いです。 Fable と Mythos の違い Fable 5 と Mythos 5 は同じ基盤モデル です。違いはセーフガードの有無に尽きます。 Claude Fable 5 Claude Mythos 5 中身 同一の基盤モデル 同一の基盤モデル セーフガード あり(高リスク領域はOpus 4.8が代わりに応答) サイバー領域のセーフガードを解除 対象 一般ユーザー(誰でも) Glasswingパートナー等、審査を通った少数のみ 位置づけ 一般公開向けに安全化したMythos 世界最強のサイバー能力を持つフル性能版   Fableのセーフガードの仕組み 危険な使われ方を検知する専用の判定システムが、サイバーセキュリティ・生物化学・蒸留に関する要求を見つけると、Fable本体ではなく次点のOpus 4.8が代わりに応答します。（切り替わった場合はユーザーに通知されます） 安全優先で保守的に調整しているため、無害な要求を誤って捕捉することもありますが、Opus 4.8への切り替えが起きるのは平均で全セッションの5%未満です。 残り95%超のセッションでは切り替えが一切なく、その場合 Fable の性能は実質 Mythos 5 と同等になります。 3領域がカバーされる理由は、サイバーが脆弱性の発見・悪用を容易にしうること、生物化学がデュアルユース(防御にも攻撃にも使える)であること、蒸留が権威主義国での競合モデル訓練への流用を防ぐため、とされています。   ちなみに、これを執筆中にもFableを利用していたんですが、内容として特定文字列が含まれているせいか、勝手に下モデルに落とされました… 課金体系・利用方法 価格は 入力 $10 / 出力 $50(いずれも100万トークンあたり) です。Mythos Previewの半額以下になりました。APIでは claude-fable-5 を指定して利用します。 提供形態はプランによって異なるので注意が必要です。 API・従量課金型Enterprise 本日から完全に利用できます。 サブスクリプション(Pro / Max / Team / シートベースEnterprise) 段階的なロールアウトとなります。 〜6月22日 :追加費用なしで利用可。 6月23日〜 :対象プランからFable 5を外す。以降の利用には 使用クレジット(従量課金)が必要 。容量に余裕があれば無料期間を延長する可能性あり。 その後 : 十分な容量が確保でき次第、サブスクの標準機能として復帰させる方針。 できるだけ早く実施したいとのこと。 データ保持ポリシーの変更 新型攻撃の防御と誤検知の削減のため、Mythosクラス以上のモデルを企業利用(API経由など)する場合、 入力と出力がAnthropic側に30日間保存される ことが必須になります。 これはAnthropicのAPIを直接使う場合だけでなく、AWSやGoogle Cloudなど他社経由で利用する場合も同様です。 ただし、実際に影響を受けるのは、これまで「ゼロデータ保持(ZDR)」契約でデータを一切保存させない設定にしていた組織だけで、 個人プランや通常のTeam/Enterpriseプランはもともと標準の保持ポリシーで運用されているため、扱いは今まで通りで変更はありません 。 また、保存されたデータがモデルの訓練に使われることはなく、用途は安全対策に限定されます。人間によるアクセスも悪用の疑いがある場合などに限られ、すべて記録されたうえで、ほとんどの場合30日後に自動削除されます。   その他 今回の発表は、いくつかの動きと時期が重なっている点も押さえておくと理解が深まります。 ひとつは、Anthropicが公開市場への上場(IPO)準備を進めているとされるタイミングと重なっていること。 もうひとつは、同社が直前に「主要なAIラボは、フロンティアAI開発のスピードに協調してブレーキをかけるべき」と呼びかけおり、AIが人間の介入なしに自分自身を改良し続ける状態(RSI:再帰的自己改善)への懸念も表明しています。 つまり「これだけ強力なモデルを安全装置付きで世に出す」という今回の判断には、性能面のアピールだけでなく、そうした安全への姿勢を示す意味合いも重なっている、という見方ができます。 まとめ ついに、開発会社がこれ以上の開発は危ないと警鐘をならすほどのmythos級モデルが公開になりました。 性能面ではコーディングから科学研究まで明確な世代差があり、一方で利用にあたっては 6/23以降の課金切り替え と 30日データ保持の義務化 という運用上の変更点を押さえておきたいところです。 まずは6/22までの無料期間で、前に試してできなかったことや、より高度なタスクを試してみるのが良さそうです。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【要点まとめ】ついに来た!最強AI、Mythosクラスが一般公開 ― Claude Fable 5 / Mythos 5 first appeared on SIOS Tech Lab .

はじめまして。エンタープライズ第二本部 プラットフォームエンジニアリング部 2年目の菊池祥汰です。業務ではAIサポートセンターとして 生成AI / LLM 活用案件やdJグループ内の生成AI利活用推進などを行っており、プライベートでも積極的にAI課金をして試しているAIフリークです。 この記事は、社内に幾多ある勉強会のひとつである『25卒技術会』での発表内容をもとに執筆されています。 『25卒技術会』では隔週火曜日に会議室に集まり、ブックリーディングと自由テーマ発表の2軸で各々の学びを共有し合っています。このたび、外部向けの施策として自由テーマ発表から不定期でテックブログを書いていく運びとなりました。ちなみに、この会の主催者はテックブログ常連でもある同期の大岡叡さんです。今後、下記の技術会メンバーからも記事の投稿がある予定ですので、お楽しみに。 大岡 叡 ／菊池 祥汰 ／ 伊藤 真幸 ／ 植木 信輔 ／ 上原 辰徳 ／ 今橋 輝 ／ 渡邉 真太郎 ／ 段下 幸太郎 自律駆動する部下は実現するか — OpenClaw という予兆 ローカル LLM の 3 つの強み 目指す世界 — 24 時間 365 日 動く株式エージェント ローカル LLMの現在地を探る 道具立て — Ollama / Gemma 4 ベースライン — 単純な線形回帰による数学的解決 実験 結果と考察 — Gemma 4 vs Gemini 現在地の見立てと展望 おわりに 2026/06/04追記 自律駆動する部下は実現するか — OpenClaw という予兆 2026 年の年明けから、 OpenClaw （旧 MoltBot） と呼ばれる能動的な AI エージェントが話題になっています。 OpenClaw は、特定のディレクトリに操作権限を与えると、AI が「次に何をすべきか」を自分で考えながら、24 時間 365 日、自律的に動き続けるタイプのエージェントです。人間が一手ずつ指示するのではなく、目的だけ渡せば手段を自分で組み立てていきます。 目的を渡せば、AI が「次にすべきこと」を自分で考え、実行し、結果を見て改善する。これが 24 時間 365 日回り続ける AI の操作をいちいち承認する操作も不要。AIの成果物を確認しレビューする 人間という最大のボトルネックを排し 、AI を本当に「 自律駆動する部下 」のように位置づけられる可能性が見えてきました。こうした動きは、すでに一人歩きを始めており、AI エージェントだけが集う SNS「 Moltbook 」なども話題を呼んでいます。Reddit のように投稿やコミュニティが並ぶのに、書き込むのはすべて AI エージェントで、人間は観察者としてしか入れません。サービス開始から数日で150万を超えるエージェントが集まり、その中では AI 同士が共同体や、ときに宗教めいたものまで自発的に作り始めたと 報じられ ています。 AIはチャットボットとして人間に律速されるフェーズを脱し、エージェント駆動する時代へとのシフトが始まりつつあります。 その一方で、大きなリスクがあります。それが API コスト です。AI を長時間・高頻度で回すほど、ランニングコストは跳ね上がっていきます。これは特に金融系のユースケースでROIを測定する際に重くのしかかってきます。 必然的に、 ローカル LLM が選択肢に上ってきます。通常私たちが利用している ChatGPT や Claude（本記事ではまとめてクラウド LLM と呼びます）は、各社のサーバ上の計算資源（メモリや GPU など）を使って動いています。便利な反面、入力は社外に送られ、使うほど従量課金が積み上がっていく。これを自分の手元のマシンだけで完結させようというのが、ローカル LLM の発想です。 ローカル LLM の 3 つの強み 私がローカル LLM の価値として最も強く押し出したいのは、次の 3 点です。 データが外部に出ていかない（セキュア） — クラウド API は入力がすべて外部に送信されます。機密情報や個人データ、API キーを扱う場合、ともすれば致命的になりえます。ローカルなら、扱うデータは自分の環境から出ません。 完全自律で回しても API コストが爆発しない — 長時間・高頻度で動かすほどクラウド API の従量課金は膨らみます。最近は各種AIベンダーも投資を回収するフェーズに入ってきており、円安も加わってクラウドAPIのコスト体系はかなり向かい風です。ローカルLLMなら、追加コストは電気代だけ。円安の煽りを受けにくいだけでも儲けものです。 買い切った GPU を遊ばせない — これは減価償却的な観点ですね。ゲーム用に買った GPU をAPI 利用料の節約という観点で使い回すことができれば、買い切りの出費を長く活かし続けられます。 ローカル LLM の 3 つの強み。（1）データが外に出ない （2)API コストが爆発しない （3）買い切った GPU を遊ばせない 目指す世界 — 24 時間 365 日 動く株式エージェント さて、この自律駆動エージェントの終着点を、私は24 時間 365 日、世界中のニュース・企業のプレスリリース・今朝の報告書を監視し続け、 株の自動売買を行うエージェント だと見ています。短期投資は分刻み・秒刻みで状況が動くので、「いま買いか、買いでないか」を常に判断させたい＋低コストで回しっぱなしにしたいという需要があります。ローカル LLM の優位性は明確です。 加えて、セキュリティ面でも、ローカル LLMを用いれば自身のポートフォリオや API キーが外部に流出するリスクを、限りなくゼロに近づけられます。金融データを扱う以上、セキュリティは最優先事項です。ローカル LLM の性質と、このタスクの要件は強く噛み合います。 最も重要なのが ランニングコスト です。API 料金が発生すると、コストに見合うリターンを得なければならず、強気（ハイリスクハイリターン）な投資を余儀なくされてしまいます。これは運用手数料の高い投資信託を保有しているときの感覚に近く、最も忌避すべき条件です。だからこそ、追加コストを電気代だけに抑えられ、なおかつまともな回答精度が得られるのであれば、ローカル LLMは非常に合理的なブレインとなりうるでしょう —— まともな回答精度が得られるのであれば、ですが。 一方で、現実にそういった話はなかなか聞きません。なぜなのでしょう。前置きが長くなりましたが、今回の記事ではここに切り込んでいこうと思います。 ローカル LLMの現在地を探る 投資エージェントをいきなり走らせるのは無理があります。買いと判断した銘柄が上がったか下がったか、その答え合わせには数か月かかりますし、コーディングも大規模になってしまいます。 そこで本記事は、ローカル LLM の現在地を知るための実験として、 物件のスペックから賃料を予測する という擬似的な経済価値判断タスクを解きます。無数の物件スペック情報から適正な価格を予測し、その予測価格と実際の価格を照合して、コスパの良い物件を検出する。スペックから想定される賃料より実際の賃料が安ければ、それはコスパが良い物件とみなし、ユーザーに提案するというものです。 両者の構造を並べると、次のように対応します。 ステップ 物件コスパ判定（題材） 株式自動売買（本命） 外部データ ローカルにキャッシュした物件情報 株価 API・ニュース・朝の報告書 LLM の価値判断 スペックから適正賃料を予測 情報から買い/売り/様子見を判断 指標化 コスパスコア（実価÷予測） 投資シグナル 正解突合 即時 数日〜数か月後 株価予測は検証に長い期間が必要です。一方、この物件タスクは、構築と答え合わせのサイクルが短く、実装も容易です。ローカル LLM の現在地を知る、という目的にはこちらが合っていました。 道具立て — Ollama / Gemma 4 ローカル LLM 基盤には Ollama を用いました。Ollama はよく「Docker for LLM」と呼ばれます。実際、開発者は元 Docker のエンジニアで、 ollama pull でモデルを取得し ollama run <model> で対話を始める操作感は Docker そっくりです。 起動すると、 localhost:11434 に REST API サーバーが立ちます。OpenAI / Anthropic 互換のエンドポイントを備えているため、既存コードの接続先を差し替えるだけでローカルモデルに切り替えられます。 モデルは Gemma 4 を用いました。Google が 2026 年 4 月に公開した オープンウェイトのモデル で、Gemini と同じ研究基盤から生まれた、画像も扱えるマルチモーダルモデルです。 Gemma 4 の特徴として MoE（Mixture of Experts、混合エキスパート） の採用があります。今回の主役 26B は、総パラメータが約 26B ありながら、推論時に実際に使うのは約 3.8 B だけです。すなわち、大型モデルの賢さを、より軽い計算量で出せるというわけです。 もうひとつの個性が、 量子化 との相性です。Gemma 4 は、いずれ圧縮されることを見越して学習する QAT（Quantization-Aware Training、量子化を考慮した訓練）を採っています。おかげで、重みの精度を 16 bit から 4 bit へ落としても品質の劣化が小さく、必要メモリを 4 分の 1 ほどに圧縮できます。本記事でローカルに落とした 4-bit 量子化版（ gemma4:26b ）も、この仕組みの上に成り立っています。 Ollama で扱える主なサイズは、次のとおりです。 Ollama タグ 構成 パラメータ（推論時 / 総） サイズ（4-bit） コンテキスト 位置づけ gemma4:e2b 軽量 2.3B / 5.1B 7.2 GB 128K 最小・スマホ等の省メモリハード向け（本実験では未使用） gemma4:e4b （= latest ） 軽量 4.5B / 8B 9.6 GB 128K 軽量・まず試した gemma4:26b MoE 3.8B / 25.2B 18 GB 256K 中型・今回の主役 gemma4:31b Dense 30.7B / 30.7B 20 GB 256K 最大・最高性能 整理すると、Ollama と Gemma 4 の関係は次の図のようになります。Ollama がローカル LLM の実行基盤、Gemma 4 がその上で動くモデル本体です。 Ollama は実行環境、Gemma 4 はその上で動くモデル。クラウドに送らず、すべてローカル PC 内で完結する 題材アプリ「大田区コスパ物件ハンター」は、Claude Code を使った Vibe Coding で作り、UI は Streamlit でさっと組みました。物件データは各サイトの利用規約に配慮し、あらかじめローカルに保存しておいたキャッシュ（CSV）を入力として扱います。これを読み込み、各物件の相場家賃を LLM に予測させ、実賃料 ÷ 予測でコスパスコアを出すだけのアプリです。スコアが低いほど割安で、0.85 を下回った物件を「お買い得」としてユーザに提案します。 Streamlit で実装したアプリケーションUI。結果はローカル実行した gemma4:26b （直列）のもの。30 件の処理に約 10.9 時間を要した ベースライン — 単純な線形回帰による数学的解決 LLM を並べて競わせても、「どれもそれなりに賢い」で終わってしまうと考え、賃料を専有面積と駅からの徒歩分数の 2 変数だけで説明するシンプルな線形回帰モデルを用意し、ベースラインとすることで、各 LLM の推論能力を定量的に評価しました。 評価用の 30 件とは別に訓練用サンプル 200 件を用意し、最小二乗法で式を一本だけ当てはめました。 賃料(万円) ≒ 0.1898 × 専有面積(㎡) − 0.2021 × 徒歩(分) + 11.26 間取りも築年数も使わない非常にシンプルな式での実装です。訓練 200 件と評価 30 件は 1 件も重なっておらず（out-of-sample）、LLM 側も同じ 30 件を学習していないので、比較はフェアです。 精度は MAE（平均絶対誤差）・MAPE（平均絶対誤差率）・バイアス（誤差の符号付き平均。予測が高めか低めかの偏り）の 3 つで測り、コストはローカルを電気代換算（350 W × 31 円/kWh）、API をトークン単価に統一して記録しました。 そして LLM 側にも、同じ土俵に立ってもらいます。各物件について実際に投げているプロンプトは、次の全文です。素朴に「相場を教えて」と尋ねるのではなく、データから導いたアンカー（基準値と補正係数）を持たせ、例にならって 5 ステップの計算過程（Few-shot + Chain-of-Thought）を踏ませる作りにしています。 あなたは東京都大田区の賃貸相場に詳しい不動産アナリストです。 以下の推論例(例1〜例3)と同じ形式で step1→step5 を順に計算し、最後に賃料を算出してください。 アンカーは大田区2DK/2LDK 117件の訓練データから多重回帰で抽出した実データ係数です。 # 推定アンカー (基準: 中位駅×2LDK×3-5階建×築10-20年×徒歩10分 → 0.33 万円/㎡) ## 駅tier - 上位 (大森・大森町・蒲田・京急蒲田・洗足池): ×1.10 - 中位 (馬込・西馬込・池上・武蔵新田・千鳥町・梅屋敷・大岡山 等): ×1.00 - 下位 (雑色・矢口渡・平和島・下丸子・石川台・田園調布): ×0.90 ## 間取り - 2LDK: ×1.00 / 2DK: ×0.95 ## 階建 - 1-2階建(木造想定): ×0.88 / 3-5階建: ×1.00 / 6階建以上(RC想定): ×1.17 ## 築年 - 築0-10年: ×1.12 / 築10-20年: ×1.00 / 築20-30年: ×0.95 / 築30年+: ×0.92 ## 徒歩 - 徒歩10分基準で ±1分あたり ∓1% (例: 徒歩6分 → +4%、徒歩14分 → -4%) # 推論例(この5stepフォーマットを必ず踏襲) ## 例1: 蒲田駅 徒歩6分 / 2LDK 55㎡ / 築8年 / 8階建 step1 駅tier = 0.33×1.10 = 0.363 (蒲田=上位) step2 間取り = ×1.00 = 0.363 (2LDK) step3 階建 = ×1.17 = 0.425 (8階建 → RC想定) step4 築年 = ×1.12 = 0.476 (築8年 → 築0-10年) step5 徒歩 = ×1.04 = 0.495 (徒歩6分 → +4%) 賃料 = 0.495 × 55 = 27.2万円 推定家賃: 27.2万円 ## 例2: 池上駅 徒歩10分 / 2DK 42㎡ / 築22年 / 7階建 step1 駅tier = 0.33×1.00 = 0.330 (池上=中位) step2 間取り = ×0.95 = 0.314 (2DK) step3 階建 = ×1.17 = 0.367 (7階建 → RC想定) step4 築年 = ×0.95 = 0.349 (築22年 → 築20-30年) step5 徒歩 = ×1.00 = 0.349 (徒歩10分 → 基準) 賃料 = 0.349 × 42 = 14.7万円 推定家賃: 14.7万円 ## 例3: 雑色駅 徒歩14分 / 2DK 40㎡ / 築32年 / 2階建 step1 駅tier = 0.33×0.90 = 0.297 (雑色=下位) step2 間取り = ×0.95 = 0.282 (2DK) step3 階建 = ×0.88 = 0.248 (2階建 → 木造想定) step4 築年 = ×0.92 = 0.228 (築32年 → 築30年+) step5 徒歩 = ×0.96 = 0.219 (徒歩14分 → -4%) 賃料 = 0.219 × 40 = 8.8万円 推定家賃: 8.8万円 # 推定対象物件 - 間取り: {間取り} - 専有面積: {専有面積(㎡)}㎡ - 最寄り駅: {最寄り駅} {徒歩N分} - 築年数: {築N年} - 階建: {階建} 上記5stepを順番に計算し、**最終行に厳密に** `推定家賃: <数値>万円` (小数1桁) の形式で1値だけ出力してください。 ※ プロンプト冒頭のアンカー（基準 0.33 万円/㎡ と各補正係数）は、線形回帰ベースラインの訓練に使った 200 件と同種の サンプルに多重回帰をかけ、統計的に抽出した実データ係数です。つまり、ベースラインと同じ訓練データの知識を LLM 側にも与えたうえで勝負させています。 実験 検証環境は以下のとおりです。 OS: Windows 11 Home / CPU: Intel Core i7 14700KF / RAM: 32 GB / GPU: GeForce RTX 5060 Ti（VRAM 16 GB） Python: 3.13 / 主要ライブラリ: ollama pandas streamlit 評価データ: ローカルにキャッシュした大田区 2DK/2LDK の物件情報 30 件（全実験で固定） 最初は、VRAM 16 GB に余裕で収まる軽量モデル gemma4:e4b （9.6 GB）から試したのですが、賃料予測の手前の簡単な質問でつまづきました。試しに「大田区で有名な駅を 1 つ教えて」と聞いてみたところ、 gemma4:e4b は自信満々にこう答えました。 大田区で特に有名な駅の一つは、大田駅（おおたえき）です。 （中略）東急大井町線などが乗り入れており、大田区の主要な交通結節点の一つとなっています。 その他、エリアの特性によっては、新大田駅なども利用される大きな駅です。 「大田駅」も「新大田駅」も、実在しません。しかも、その架空の駅に「東急大井町線が乗り入れる交通結節点」というもっともらしい乗り入れ情報まで添えています。典型的なハルシネーションですね。地名すらこの調子では、複雑なスペックから経済価値を判断させるのは到底無理だということで、軽量モデルは早々に候補から外れました。 同じ質問を、ひとつ上の gemma4:26b に投げると、答えが変わります。 大田区で最も有名な駅といえば、蒲田駅（かまたえき）です。 大田区の最大のターミナル駅であり、JR、京急、東急といった複数の路線が乗り入れる交通の要所です。 概ね意図どおりの回答が得られました。 最低限の精度を求めるには、 26b が要るようです。 gemma4:26b は「蒲田駅」と正答。乗り入れ路線も正確な回答になっている。 ところが、 gemma4:26b を手元の RTX 5060 Ti で動かそうとして、最初の壁にぶつかります。 gemma4:26b は 4-bit 量子化でも約 17 GB あり、VRAM 16 GB にわずかに収まりません。Ollama は収まらない分（約 35 %）を RAM 側に退避させ、その部分を CPU で計算します。結果、GPU と CPU を行き来する構成になり、計算時間が大幅に増えてしまいました。 ここで重要なのは、 VRAM 不足が線形の劣化ではなく崖 だということです。 理由は、LLM の推論がメモリ帯域に律速されるからです。推論の中身は、膨大な重みをメモリから読み出して計算する処理の繰り返しで、ボトルネックは計算量よりも読み出しの速さにあります。GPU の VRAM はこの読み出しが桁違いに速い一方、CPU 側へ退避した層は、それよりずっと帯域の狭いシステム RAM を経由します。 約 17GB のモデルが 16GB の VRAM に収まらず、Ollamaによって自動的にモデルの 約 35% が RAM/CPU へ退避する結果に。処理速度は VRAM 容量を超えた瞬間に崖のように急落する 私の PC のスペックはごくごく一般的なゲーミング用ですので、 ローカル LLM を前提とした十分な VRAM を積んだ GPU でないとまともな推論能力は得られない というのが 2026 年 6 月時点の現在地となりそうです。 が、さすがにこの結果では終われないので、急遽 Google AI Studio から Gemma 4 の API を叩く形に切り替えました。これにより、Google 側が用意した計算資源を借りて、Gemma 4の26Bと31Bという大きめのモデルを（無料で）動かすことができます。一旦手元のハードの制約を外し、モデルそのものの実力を見にいきました。 結果と考察 — Gemma 4 vs Gemini 評価 30 件での実測をまとめます。ベースライン（線形回帰）は MAE 2.826 / MAPE 19.62 % / バイアス +0.092 でした。 モデル 実行環境 時間 コスト MAE MAPE バイアス 線形回帰ベースライン — — — 2.826 19.62% +0.092 Gemini 2.5 Flash-Lite API・並列×8 10.6 秒 2.10 円 3.177 17.42% −2.203 Gemini 2.5 Flash-Lite API・直列 64.9 秒 2.15 円 3.127 17.28% −2.167 Gemini 3.5 Flash API・並列×4 93.6 秒 29.61 円 3.157 17.11% −2.283 Gemini 3.5 Flash API・直列 約 5.3 分 28.97 円 3.340 18.24% −2.367 Gemma 4 31B Dense AI Studio・直列 約 27 分 0 円 3.317 18.25% −2.39 Gemma 4 26B a4b AI Studio・直列 約 1.4 時間 0 円 3.213 17.58% −2.24 Gemma 4 26B ローカル・直列 約 10.9 時間 118.21 円 11.566 71.14% −6.604 同じ 30 件でも、実行環境によって所要時間は大きな差になる。最速のクラウド並列と最遅のローカル直列の開きは、約 3,700 倍 比較対象とするクラウドLLMは、 Google 系列のモデルでそろえました 。先述の通り、Gemma 4 は Gemini と同じ研究基盤から生まれたモデルなので、ある程度公平な比較と言えるでしょう。選んだのは次の 2 つです。 Gemini 2.5 Flash-Lite （軽量クラウドモデル） — Gemma 4 とベンチマーク帯がほど近く、「同じくらいの賢さなら、ローカルとクラウドのどちらが割に合うか」というコスト対効果と、ローカルの代替になりうるかを見る役です。 Gemini 3.5 Flash （最新ハイエンド） — つい先日、2026 年 5 月 19 日の Google I/O 2026 で GA になったばかり。「コストをかけて上位モデルにすれば、差は埋まるのか」という上限を確認する役です。世代の 3.1 Pro 比で大半のベンチマークを上回りながら、 価格は約 25 % 安く、出力は約 4 倍速い とされています。並列4件になっているのは1分あたりのレート制限がGemini 2.5 Flash Liteよりも厳しいため。 考察を 3 点 挙げます。 まず、 Ollamaローカル実行は、実行時間もコストも突出して重い。 同じ 30 件に対して、Gemini 2.5 Flash-Lite は並列で 10.6 秒・約 2 円。ローカルの 26B は約 10.9 時間・118.21 円。速度で約 3,700 倍、コストで約 60 倍の差です。VRAM溢れが発生するような欲張りなモデル選定を行った場合、という枕詞はつきますが、「追加コストは電気代だけだから安い」という直感には反する結果となりました。 一方で、これは「VRAM に収まらなかったとき」の数字でもあります。仮に RTX 4090（VRAM 24 GB）のように、 gemma4:26b （約 17 GB）がまるごと載る GPU だったらどうでしょう。ここでは、AI Studio 版の 26B と同じ約 1.4 時間で終わると仮定して、電気代を試算します。 計算式は 消費電力(kW) × 時間(h) × 31 円/kWh （東京電力 従量電灯B 第2段階）です。時間を 1.4 時間に固定し、消費電力の前提だけを 3 通り変えてみると、以下の表のようになります。 消費電力（PC 全体の目安） 計算式 30 件の電気代 350 W（本実験のローカル機と同じ前提） 0.35 × 1.4 × 31 約 15 円 450 W（RTX 4090 の TDP＝GPU 単体ピーク） 0.45 × 1.4 × 31 約 20 円 600 W（4090 を積んだ PC 全体の高負荷時） 0.60 × 1.4 × 31 約 26 円 RAM 退避したケースに対して、4 分の 1 以下にとどまります。しかも 1.4 時間はクラウド側の所要時間で、フル GPU ならさらに速く・安くなる可能性が高い。とはいえ、Gemini 2.5 Flash-Lite が 2.1 円に収まることを鑑みると、 「ローカル LLM は電気代だけだから安い＝APIコストをGPU投資によって回収できる」という神話は完全に否定された と言えるでしょう。 同じ 30 件を Gemini 2.5 Flash-Lite の並列実行で処理した結果。所要時間は 10.6 秒 ふたつ目。 どの LLM も、面積と徒歩だけの線形回帰（MAE 2.826）に、MAE で勝てていません。 何十億ものパラメータを持つ最新モデルが、2 変数のごく単純な式に及びませんでした。 一方で、指標MAPEを変えると景色は反転します。率で見る MAPE では、LLM 群はそろって 17 % 台に収まり、ベースラインの 19.62 % を下回りました。 平均誤差では負け、率で見れば勝っている。 MAE は高額物件の絶対誤差に引っ張られ、MAPE は安い物件の外れも対等に扱います。どちらの物差しを採るかで、勝者がそのまま入れ替わるわけです。これは、「どの指標で測るか」を決めることが、結論そのものを決めてしまう、という実務的な教訓ですね。 MAE で負けた理由はおそらく、賃料というタスクがそもそも面積に対してほぼ線形で、「避けられない複雑さ」が低いからでしょう。タスクが単純なとき、単純なモデルが分散の大半を説明してしまいます。そこに LLM を持ち込むと、かえってノイズを上乗せする結果に終わってしまいます。 最後に、 最新・高価なモデルほど効く、とは限らないことが浮き彫りになりました。 Gemini 3.5 Flash は、Gemini 2.5 Flash-Lite 比約 14 倍のコスト（約 30 円）をかけて、精度はほぼ横ばいでした。少なくともこの物件タスクでは、価格に見合う上積みは得られなかった、ということです。 肝心の良コスパ物件判定ですが、コスパスコア（実賃料 ÷ 予測相場）が 0.85 を下回る物件を「お買い得」として抽出したところ、安定して動いたモデルはどれもほぼ同じ顔ぶれを拾いました。筆頭は JR 京浜東北線・蒲田駅 徒歩 4 分の 2DK（実賃料 8.5 万円／予測相場 11.2 万円＝スコア約 0.76）で、これに鵜の木・パレスフロラシオンの 2DK が続き、お買い得はおおむね 3 件前後でした。もちろん今回取り扱った物件のスペックは限定的ですので詳細を吟味する必要はありますが、第一層の捌きとしては十分に絞り込めているのではないでしょうか。引っ越しを検討している同僚に試してもらってFBをもらっていけば、案外実用的なアプリとして運用できるかもしれません。 現在地の見立てと展望 実験を踏まえ、ローカル LLM の現在地の見立てを述べます。 現時点での結論として、実用的なのは Google AI Studio から Gemma 4 を叩く 形でしょう。学習利用という枷こそあれど、無料で使え、Google 側の計算資源を用いて大きめのモデルも問題なく動きます。少なくとも、家庭用 GPU で 17 GB 級のモデルと格闘するよりは、ずっと現実的な選択肢でしょう。ただし、 この無料枠がいつまで続くかは分かりません 。AI企業は投資を回収するフェーズに入っており、利益にならない計算資源をどこまで無料で使わせてもらえるかは完全にGoogle側の経営判断に委ねられています。 次点は Gemini 2.5 Flash Lite などの軽量・高速モデル を用いる ことでしょう（この記事の執筆中に EOL が発表されてしまいましたが……移行先は Gemini 3.1 flash Lite ですかね）。Gemma 4 は、Gemini 2.5 Flash-Lite のような軽量・高速なクラウドLLMと比べて、推論力では一段劣る印象でした。費用対効果を考えると、軽量なクラウドLLMは安くてリターンの大きい投資であると考えます。少なくとも私ならこの選択肢を選ぶでしょう。 繰り返しになりますが、今回の検証はローカルLLMの「現在地を探る」ことを目的としています。ビッグテックによるLLMの開発競争は、さながら米露の宇宙開発の様相。ローカルLLMについても、量子化や知識蒸留技術の進歩によって（なんならムーアの法則的な計算資源面の改良にも期待しつつ）、さらなる軽量化・ベンチマークスコア向上が期待されます。特に今回題材に挙げた Gemma 4 については Gooole がかなり意欲的に開発を進めているので、今後とも注視していきたいです 今後の課題としては、本命のタスクである株式投資エージェントによるベンチマークでしょうか。今回、最新の Gemini 3.5 Flash も同じ土俵で回しましたが、賃貸予測タスクでは割高なだけで、明確な上積みはありませんでした。ただ、3.5 Flash の本領は、エージェントや金融まわりの複雑なタスクにあるとされています（金融エージェント向けのベンチマーク（ Finance Agent v2 ）では、前世代の Gemini 3.1 Pro を大きく上回ったと報告されています）。だとすれば、その差が出るのは今回のような単純な題材ではなく、株式投資エージェントのような複雑な経済価値判断を要するシーンのはずです。時間を見つけて本来の戦場できちんと測っていきたいです。 おわりに 24 時間 365 日稼働し続ける「眠らない部下」には、電気代という無視できない額の請求書がついてまわります。1 kWh あたり 31 円のこの国で GPU を本気で減価償却しきろうと考えたとき、行き着く先はソーラーパネルを導入することしかないかもしれませんね。 データを手元に、計算を手元に、最後は電力まで手元に。ローカル化の旅は、案外その先まで続いているのかも……。 2026/06/04追記 なんて話をしていたら、Googleが「Gemma 4 12B」をリリースしましたね。今回のモデルは VRAM 16 GBで動く というところがプッシュされているようです。AI開発戦争は秒進分歩。ローカルLLMの 「本当の現在地」 については、ぜひ皆さんのほうで検証いただけますと助かります。 なんて間の悪い！！ 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @kikuchi.s レビュー： @miyazawa.hibiki （ Shodo で執筆されました ）