カテゴリー: AI

日本語を扱う業務に生成AIを使えるか。判断の材料が公開情報だけでは足りなかったため、社内サーバーで4つのモデルを同一条件で測定しました。設問240問・翻訳1万件・計算150問、のべ42,670件の回答を採点した結果をまとめます。

検証の狙い

日本語性能を比べた公開情報は数多くあります。ただし多くは英語ベンチマークの和訳か、総合スコア1本での比較です。それでは敬語の使い分け、助数詞の正しさ、指示どおりの文字数に収める力といった、実務で真っ先に問われる部分が見えません。

そこで設問を自作し、同じ素材・同じ採点基準・同じ実行環境で4モデルを測りました。以下はすべて自社の実測値です。

測定の設計

種別	手法	規模	採点
日本語能力	12カテゴリ×20問を1〜10点で絶対評価（2軸）	1,920件	大規模モデルによる採点
翻訳精度	日→英翻訳を1〜10点で絶対評価	40,000件	大規模モデルによる採点
計算能力	日本語で出題し正解と自動照合	750件	プログラム
応答速度	サーバー側のナノ秒計測（単独常駐・3回の中央値）	4モデル	—

設問240問の内訳は敬語・自然さ・作文・語彙・説明・要約・気遣い・表記校正・助数詞・文体変換・読解・論理の12カテゴリです。うち表記校正・助数詞・文体変換・読解・論理の5カテゴリは今回の検証のために新設しました。

実行環境はローカルの推論サーバー1台で、4モデルとも同じ量子化（4bit）で動かしています。外部のクラウドAPIは通していません。

結果1 ─ 日本語の質と回答の質

2つの軸で別々に測りました。「日本語の質」は文法・語彙表記・敬語・流暢さを見る軸で、出力のばらつきを排除する設定で実行しています。「回答の質」は指示遵守・正確さ・有用性・簡潔さを見る軸で、実際のチャット画面と同じ設定です。

モデル	日本語の質	回答の質	敬語
gemma4:31b	7.42	7.38	7.05〜7.20
gemma4:12b	7.32	6.71	6.00〜7.10
qwen3.6:27b	7.09	6.28	5.40〜5.65
qwen3.6:35b	6.86	5.89	5.15〜5.45

順位は両軸で完全に一致しました。そのうえで差の開き方が違います。首位と最下位の差は日本語の質で0.56点にとどまるのに対し、回答の質では1.49点まで開きます。文章として整っているかより、指示にどこまで従えるかで実力差が出るという結果です。

カテゴリ別で最も差がついたのが敬語で、1.6点。低いモデルには謙譲語と尊敬語の取り違えを指摘しても直せない例が目立ちました。低スコアが集中したのは敬語・語彙・助数詞の3カテゴリで、いずれも今回追加した領域です。設問を増やしていなければ「4モデルともほぼ同等」で終わっていました。

結果2 ─ 破綻率という指標

平均点だけでは業務での使いやすさが測れません。そこで1〜3点、つまり日本語として成立していない回答が全体の何割かを別に数えました。

モデル	破綻率（回答の質）	体感
gemma4:31b	2.5%	40回に1回
gemma4:12b	10.0%	10回に1回
qwen3.6:27b	15.8%	6回に1回
qwen3.6:35b	20.0%	5回に1回

破綻の主な形は同一句の反復ループでした。実際に出た例を挙げます。

• 文章を3割短くする指示に対し「ご多忙のところ恐縮ではございますが」を20回以上反復
• 語句の意味を尋ねた設問で「うがる（ugaru）＝」を無限に反復
• 「『歩く』は『歩いたり』ではなく『歩いたり』でも」という自己矛盾した文の反復

平均点で0.5点の差は資料の上では小さく見えます。しかし破綻率が2.5%と20.0%では、使う側の印象がまったく別物になります。導入判断では平均点より破綻率を見るべきというのが、今回いちばん実務に効いた発見でした。

結果3 ─ 翻訳・計算・速度

モデル	翻訳（10点満点）	翻訳の失格率	計算の正答率	生成速度
gemma4:31b	9.82	0.20%	99.3%	10.5 トークン/秒
gemma4:12b	9.60	0.21%	98.7%	25.1 トークン/秒
qwen3.6:27b	9.70	1.02%	96.0%	11.9 トークン/秒
qwen3.6:35b	9.46	1.20%	96.7%	74.0 トークン/秒

「失格」は翻訳になっていない回答を指します。原文の指示に答えてしまった回答などが該当します。1万件規模で測ると95%信頼区間が0.03程度まで狭まり、この順位が偶然でないと確認できました。

検証で分かった3つのこと

1. 翻訳の上手さは日本語能力の代理指標にならない

翻訳スコアの順位と日本語回答品質の順位を並べると、2位と3位が入れ替わります。翻訳が上手いモデルを選んでも、日本語で書かせたときの順位を再現できません。手軽に測れる翻訳スコアで日本語力を代用する判断には根拠がない、という結果です。

2. 採点者を替えると順位が入れ替わる

検証の途中で採点役のモデルを差し替えたところ、同じ設問のまま順位が逆転しました。設問を18問から240問へ増やしたことで動いたのは0.10点分で、逆転の主因は採点者の交代でした。

AIが採点する形式のベンチマークを読むときは、スコアの数字より「誰が採点したか」を先に確認する必要があります。自社で測る場合も、採点者を固定しないまま前後比較をすると結論が壊れます。

3. 速度と日本語能力の逆相関

最も速いモデルが日本語で最下位、最も遅いモデルが日本語で1位でした。4モデルの中に品質と速度の両方で上位に立つものはありません。用途ごとにどちらを取るかの判断が要ります。

なお速度差の主因はパラメータ数ではなく構造の違いにあります。最速のモデルは必要な部分だけを使う構造のため、公称の規模が最大でも実際に読み出す量が最も少なくなります。「大きいモデルほど遅い」という見立ては、この種の構造には当てはまりません。

まとめ

• 日本語能力を測るなら平均点より破綻率を見る。2.5%と20.0%では使用感が別物になる
• 敬語・助数詞・表記校正は差がはっきり出る領域で、汎用ベンチではほぼ測れていない
• 翻訳スコアは日本語能力の代わりにならない
• AI採点のベンチマークは採点者で順位が動く。数字の前に測り方を確認する

ハバス合同会社では、日本語を扱う業務に生成AIを組み込む際の検証をこのように自社で行っています。公開されているスコアをそのまま使うのではなく、業務で問われる形に設問を作り直して測ることを重視しています。検証の設計や結果についてのご相談はお問い合わせページよりご連絡ください。

測定日: 2026年8月／実行環境: ローカル推論サーバー1台、4bit量子化、外部APIへの送信なし

先月、自社がAIにいくら使ったか即答できますか。

生成AIを業務に入れた会社が、次にぶつかるのがこの問いです。便利になった実感はある。請求書も届いている。けれど「誰が」「何に」使った分なのかが分からない。

米国のテック番組「TBPN」の2026年7月16日の回（配信アーカイブ／2時間4分）に、Rampの共同CEO Eric Glyman氏が出演していました。

Rampは米国の法人向けフィンテックです。法人カードを軸に、請求書払い・経費精算・会計連携をひとつにまとめたサービスで、日本でいえば法人カードと経費精算システムが一体になったものにあたります。同じ回には、ベンチャーキャピタルBenchmarkのEverett Randle氏も出演していました。数字が具体的で、日本の中小企業にもそのまま効く話だったので整理します。

数か月で21倍──トークン支出はここまで動いている

Rampは米国の法人支出の約1%を扱っており、顧客企業の支出動向が統計としてそのまま見えます。Glyman氏が挙げた数字がこちらです。

• Ramp顧客のトークン支出は直近の数か月で21倍
• Ramp自身も、2026年5月にはAI関連の支出が人件費の約10%に到達
• ある企業では1週間で150万ドルの請求が届いた

規模の違いはあれ、増え方の傾向は日本の会社でも変わりません。数年前は「誤差の範囲」だった費目が、気づくと人件費と並べて語る対象になっている、という構図です。

「減らそう」ではなく「もっと有効に使いたい」

意外だったのが、顧客の反応です。

「使うのをやめよう」という声は出てこない。むしろ「必要なところにもっと使いたい」と言われる。

つまりこれは経費削減の話ではありません。投じた分が何を生んだのかを説明できるようにする、という話です。実際Rampでも、プロダクトのリリースは以前より速くなり、効率も上がっていると述べています。

問題は金額そのものではなく、中身が見えないことでした。請求はまとめて月末に届く。しかも財務担当は、その金額を開発に、営業に、と部門ごとに割り振らなければならない。ところがその作業を助ける仕組みが、まだどこにも用意されていなかったわけです。

見せるだけで支出が下がる

対策として紹介されていたのが、法人カードの運用で先に確立していた考え方です。

うっかり社内ルールの対象外の支払いをしてしまったとき、何も知らせなければ本人は気づかないまま使い続けます。ところがその場で一度「この支払いは経費で落ちません」と知らせるだけで、ルール外の支出は目に見えて減る。Glyman氏はこう言い添えています。「人は本来、正しくありたいと思っている」。

同じことがAIでも起きていました。使用量を本人に見せると、こういう反応が出るそうです。

天気を調べるのに100ドル使っていたとは気づかなかった。

最上位モデルで天気を調べる。笑い話のようですが、社内の誰かは必ずやっています。制限をかける前に、まず本人に見せる。それだけで効率化が進む、という指摘でした。

高いモデルと安いモデルの使い分け

もうひとつ実務的だったのが、モデルの振り分けの話です。Rampのデータでは、平均的な企業はトークン支出の59%を最上位モデルに使っているとのこと。ここに手を入れる余地があります。

原則はシンプルです。タスクの複雑さに応じて振り分ける。Glyman氏の言い方が分かりやすいので引用します。

会計の処理に、がんを治したり量子物理を解いたりできるモデルを使う必要はない。

試行錯誤の段階では最上位モデルを使い、毎日・毎週繰り返す定型処理が固まってきたら軽量モデルに寄せる。用途が絞れているなら、そこに特化させてしまう。この順番です。

ただし逆のケースもある、とGlyman氏は釘を刺していました。安いモデルのほうが高くつくことがあるのです。1回あたりの単価は安くても、そのぶん深く考える必要があり、処理を何度も呼び出す。結果として合計額が上回る。賢い人が暗算で済ませるところを、そうでない人が筆算を繰り返すようなものだ、という喩えでした。

単価表だけを見て決めず、自社の業務で実際に測る。ここは当社がローカルLLMの比較検証でも痛感しているところです。

「安い時代」は終わりつつある

背景として、Randle氏が2年前に書いた一節が紹介されていました。「Uberが街中どこへでも3ドルで乗れた頃のような、今のAIの安さを当たり前だと思わないほうがいい」。

各社が競争のために価格を抑えていた時期は、確かに安かった。しかし推論を重ねるモデルが主流になり、さらに裏で複数のエージェントが動くようになったことで、消費量そのものが跳ね上がっています。Randle氏は、各社が身銭を切って支えてきた安さは少しずつ薄れていると見ています。

一方で、真逆の考え方も紹介されていました。「トークン費が人件費を超えてほしい」という立場です。競合が安いモデルで済ませているうちに、自社は最上位の知能を使う。それ自体を競争優位にする、という発想です。

どちらが正しいかではなく、自社がどちらの立場を取るのかを決めておく。それが今年の分かれ目になりそうです。

今からできること

規模の大小に関わらず、明日から着手できるのは次の3つだと考えています。

1. まず可視化する。誰が・何に・いくら使っているかを、月末の請求書ではなくその日のうちに見られる状態にする。
2. 本人に見せる。上限で縛る前に、使った量をその人自身に見せる。それだけで無駄は減ります。
3. 用途で振り分ける。探索は上位モデル、定型処理は軽量モデル。そして単価表ではなく自社の業務で測る。

社外に出せないデータを扱うなら、ローカルLLMという選択肢もここに加わります。トークン単価が積み上がらないため、定型処理を大量にさばく用途では投資回収の計算が変わってきます。

まとめ──請求書ではなく「何を生んだか」で語る

AIの費用対効果を聞かれて、多くの会社はまだ請求金額しか答えられません。それは高いか安いかの話にしかならず、判断材料になりません。

いくら使い、その結果どの仕事が速くなったのか。ここまで説明できて初めて、増やす・減らすの判断ができます。生成AIを一通り試した会社にとって、次の一手はここだと思います。

当社でもAIワークステーションやローカルLLMの検証を進めており、社内利用の可視化についてもご相談を承っています。

出典：TBPN「TML Inkling, California Forever? TSMC Capex, Tokenomics, Roblox」（2026年7月16日ライブ配信）。引用部分は当社による要約・翻訳です。

AIで誰もが何でもできるようになった今、「で、自分の仕事は何なのか」と手が止まっていませんか。

PMがコードを書き、デザイナーが要件をまとめ、エンジニアが企画を考える。役割の線引きが曖昧になるほど、自分の専門性が要らなくなったように感じる場面が増えています。

この問いに、1億3,000万人が使うサービスを預かる立場から答えている人がいます。Netflixの最高製品技術責任者Elizabeth Stone氏です。ポッドキャスト「Lenny’s Podcast」の回（Why Netflix is betting on systems thinkers—not specialists—in the AI era／2026年7月19日公開・72分）で語られた内容から、日本の中小企業にも効く部分を抜き出して整理しました。

結論──Netflixが増やしているのは「専門家」ではない

同社が採用を増やしているのは、事業全体を見渡して「共通して必要になる仕組みは何か」を見極められる人です。氏はこれを「システム思考ができる人」と呼びます。

逆に減っているのは狭く深い専門特化です。5〜10年前と比べてスペシャリストは減り、複数の分野に対応できる人が増えた、と明言しています。バックエンドもフロントエンドも行き来でき、必要なら素早く学べる。その姿勢が前提になったということです。

ただし例外があります。動画のエンコードや再生システムのように「世界に数人しか仕組みを本当に理解していない」領域では、今も専門の実務家が必要になる。ここは残る、と切り分けています。

システム思考の鍛え方──まず一歩引いて考える

抽象的に聞こえる言葉ですが、氏が挙げた鍛え方は拍子抜けするほど具体的です。

目の前の問題に取りかかる前に、一歩引いて考える。この問題を解くとき、自分は周りについて何を当たり前だと思っているのか、と。

新機能を作れと言われたら、ひと呼吸置いて「そもそも解こうとしている顧客の課題は何か」「この作り方は他の用途にも広がるか」を問う。それだけです。

大事なのはそこに続く但し書きのほうかもしれません。何もかもを一から問い直す必要はない、と釘を刺しています。会社全体の戦略や競合との位置づけまで考え込まなくていい。自分の担当範囲について、ひとつ視野を広げるだけでいい。しかも問い直しに時間をかけすぎてはいけないとも言っています。手が止まってしまうからです。

もうひとつ、実務的な言い換えも紹介されていました。「自分の仕事のやり方のなかに、上司の仕事を助けるものはないか」と考えること。視点が自然にひとつ上がります。

職能は消えない──得意分野は残り、線引きだけが曖昧になる

では専門性は無価値になるのか。ここははっきり否定しています。

• データ担当：このデータは信頼できるか、解釈は正しいか
• 企画担当：解くべき問題の「何」を正しく捉えられているか
• 開発担当：どう作るか。拡張性と品質、後で何が問題になるか

AIツールのおかげで、一人が扱える範囲は確かに広がった。それでも、出来上がったものの良し悪しを見極める目は置き換えられていない、という整理です。氏はむしろ「優れたエンジニアリングも、優れたデータサイエンスも、優れた創造性も、依然として希少だ」と繰り返しています。

AI活用の目標を等級表に細かく書かない

評価制度の話も示唆に富んでいました。Netflixは「AIフルエンシー（AIを使いこなせること）」を職種別・等級別には定義していないそうです。全社共通の目標として、全員に同じものを掲げているだけだといいます。

理由は単純で、技術の進み方が速すぎるから。中身が「四半期どころか月単位、下手をすれば日単位で変わる」ため、細かく書き下すと運用が追いつきません。

そのうえで、譲れない条件は明快です。技術のための技術ではなく、役に立つところで使い、その判断を適切に下せること。そして新しいものを試すことに前向きであること。これは経営層にも同じように求める、と述べています。

うまくいかないときほど手順を増やさない

個人的にいちばん耳が痛かったのがこの一節です。

うまくいかないたびに手順を増やしてきたが、手間が増えただけで成果は良くならなかった。

誰かが失敗すると、再発防止の手順を1本増やしたくなる。人間として自然な反応ですが、制約を増やせば問題が単純になるという発想は実際には逆に働くことが多い。氏はこれを「大企業がやりがちなことをあえてやらない」姿勢だと表現し、その落ち着かなさを受け入れること自体が文化なのだ、と言い切っています。

代わりに置いているのは犯人探しをしない振り返りです。優秀な人ほど「どうすれば再発を防げるか」を自分ごととして考える。統制ではなく信頼で回す、という判断です。

中小規模の会社こそ取り入れやすい3点

Netflixの規模の話として片づけるにはもったいない内容でした。むしろ少人数の組織ほど効くと感じた点を3つ挙げます。

1. 一人が複数の役割を持つ組織と相性がいい。対応範囲の広い人を増やすという方針は、そもそも分業できない規模の会社が先にたどり着いていた形です。
2. AI活用の目標は職種別に細かく決めない。全社共通の目標として掲げるほうが、少人数では運用しやすく、古びにくい。
3. 失敗のたびにルールを増やさない。手順書が積み上がるほど、少人数の機動力は削られます。

まとめ──「一歩引く」を習慣にする

AIが道具として広がるほど、価値の重心は「どの問題を解くか」を決める側に移ります。とはいえ、必要なのは大げさな戦略論ではありません。

目の前の作業に取りかかる前に、一歩引いて前提を疑う。ただし長居はしない。それを習慣にできるかどうか、という話でした。当社でもローカルLLMやAIエージェントの検証を進めていますが、モデルの性能比較だけで終わらせず「どこに何を置くか」まで含めて設計する。その姿勢をあらためて言葉にしてもらった感覚があります。

出典：Lenny’s Podcast「Why Netflix is betting on systems thinkers—not specialists—in the AI era | Elizabeth Stone (CPTO)」（2026年7月19日公開）。引用部分は当社による要約・翻訳です。

生成AIは、もはや仕事に欠かせない相棒です。けれど便利さに比例して、別の感情も育っていないでしょうか。「このデータ、外に出していいのか」「ここまで依存して、もし止まったら」――そんな引っかかりです。

当社が社内マシン『GX10』に自前のローカルLLMを立てたのは、流行りに乗ったからではありません。明確な“目的”があったからです。

本記事は構築手順書ではなく、「なぜローカルなのか」という目的と、AI（Claude Code）を相棒に組み上げる中で見えてきたことを、現場の言葉でお伝えします。

なぜローカルなのか──「守りたいもの」と「止めたくないもの」

ローカルLLMを立てる理由は、突き詰めると3つに集約されました。

目的	解決したい不安
データ主権	機密文書や顧客情報を、社外のAIに渡したくない
可用性	提供側の都合（仕様変更・規制・障害）で、ある日業務が止まるのを避けたい
自由度	使うほど増えるAPI課金や制限を気にせず、用途に合わせて自由に使い倒したい

クラウドAIの“賢さ”には及ばなくても、「外に出さず、止まらず、気兼ねなく使える」AIには独自の価値があります。これがエッジAIの本質です。

何に使うのか──“そこそこ賢いAI”を社内で使い倒す

目的が定まると、用途も具体化します。実際にGX10で動かしているのは、Googleの『Gemma』とAlibabaの『Qwen』。社内文書の要約、PDFの読み取り、音声の文字起こし、社内向けの質問応答といった“地味だが効く”業務が対象です。

ポイントは「1つの万能AIを選ばない」こと。速さ重視ならGemma、正確さ重視ならQwen、と目的ごとにモデルを使い分ける。これはローカルだからこそできる贅沢です。

作って実感した、AIと組む3つのコツ──任せきりでは進まない

今回の構築は、AI（Claude Code）と対話しながら進めました。コマンドや設定をAIに相談し、提案を実機で試す、という進め方です。効率は劇的に上がりましたが、“AIに任せきり”では進まない場面も多くありました。そこで身についたコツが3つあります。

• ① 環境の前提を、最初に渡す。 「最新GPU搭載機で」「OSはこれ」と前提を伝えないと、AIは一般的な（＝この環境では的外れな）手順を返します。聞き方が曖昧だと、答えも曖昧になります。
• ② エラーは“全文”を渡す。 こちらで要約して渡すと原因がぼやけ、AIも迷走します。ログをそのまま見せるのが、解決への最短ルートでした。
• ③ 提案は鵜呑みにせず、実機で検証する。 もっともらしい回答が必ずしも正解とは限りません。動かして確かめる一手間が、結局いちばん速いのです。

失敗が教えてくれたこと──最新ハードの“宿命”と、AIの限界

つまずき：最新すぎて、AIも知らなかった
GX10のGPUは世代が新しく、AIの学習データにもまだ載っていないほど。音声合成の起動エラーは、AIの“一般論”では解けませんでした。最終的にはエラーログを一緒に読み解き、原因（GPU向けコード生成の非対応）を切り分けて回避。「最新ハードは速いが、ソフトの対応待ちがある」という宿命を、身をもって学びました。

ここに、AIと組む時代の本質があります。AIは“調べ物と手数”を高速化する最強の相棒。しかし未知の領域の“最後の切り分け”は、人間の仕事として残る。だからこそ、AIを使いこなす人材の価値はむしろ上がっています。

まとめ──ローカルAIは「目的」から逆算する

ローカルLLMは、手順をなぞれば誰でも立てられます。けれど大事なのは、その手前の「なぜ立てるのか」です。

• データ主権・可用性・自由度――守りたいものから逆算して設計する
• モデルは1つに絞らず、目的で使い分ける
• 構築はAIと組めば加速する。ただし前提とログを渡し、最後は人が検証する

「便利だけど、ちょっと不安」――そのモヤモヤは、社内に“自前のAI”を持つことで、かなり晴れます。御社の「守りたいもの」は何でしょうか。そこから、ローカルAIの設計は始まります。