#000 AIの性能は、意思決定の順序で決まる

AIプロダクトが「遅い」「高い」「品質が出ない」とき、多くのチームは真っ先にモデルを疑います。より大きいモデルへ、より新しいモデルへ、より高いプランへ。

けれど、勝敗を分けるのは「どのモデルを選ぶか」ではなく、どんな順序で意思決定するかでした。答えはモデルの外側（待ち・配置）にあることも、モデルの側にあることもある——ただしモデル側でも、たいていは「もっと大きく」ではなく「もっと絞る（特化）」です。

この4つの原則は、私がAI翻訳アプリ「LYR」を一人で開発しながら、何度も失敗と計測を繰り返して辿り着いたものです。新しい技術の話ではありません。意思決定の順序の話です。あなたのチームがAIの性能に投資しようとしているなら、その前に一度、この順序で診断する価値があります。

まず計測せよ — Measure First
まだ、安く・速くできる — Hunt the Constraint
ユーザー体験の代理指標を、正しく選ぶ — Optimize the Right Proxy for UX
処理を高速化するより、処理自体を減らす — Eliminate, Don’t Accelerate

1. まず計測せよ — Measure First

「AIが遅い/高い」の原因は、たいてい”思い込み”から始まります。私自身、遅さの見立てを何度も外しました。

私はずっと、翻訳が遅い原因を”モデル”だと思い込んでいました。ところが、処理の内訳を初めて分解して測ったとき、真犯人はまったく別のところにいました。もし測らずに速いモデルへ乗り換えていたら、体感はほとんど変わらなかったはずです。

測る対象は、結果だけではありません。“前提”こそ測る。「たぶんここが遅い」の”たぶん”を、投資の前に潰す。そして計測は一度きりではなく、同じコードを2回まわして一致するかから始める——複製したベンチマークは、静かに嘘をつくからです。

→ 予算を投じる前に、まず「どこで時間とお金を使っているか」が見える仕組みをつくる。見えないものは、直せません。

実例: 1行の翻訳が数百トークンもの”思考”を吐き、それが遅さの正体だった（第1回）。／複製したベンチが、同じコードの2回すら一致しなかった（ハーネスの決定性）。

2. まだ、安く・速くできる — Hunt the Constraint

システムには、必ずどこか一つに律速（ボトルネック）があります。だから、安くする余地・速くする余地は、いつも残っています。

遅さやコストの主犯は、モデルの計算そのものではないことが多い。皮肉なことに、処理を軽くするほど、その手前と背後にある「待ち」と「配置」が全体を支配します。そして律速は動く——去年の正解が、今年の間違いになる。だから隔離ベンチの数字は当てにならず、必ず本番の全体像で「今どこが制約か」を測り直す。単体では速いはずのエッジ推論が、本番では逆に遅くなったこともありました。

特化も、この文脈の道具です。 汎用モデルの”税”を外して1つのタスクに絞れば、はるかに小さいモデルが、現役最強級の品質に、より安く・より速く届く。「大きいほど良い」を、安く・速くするために捨てる。

→ 「これ以上は無理」ではなく、「まだ律速を見つけていない」だけ。全体を見て、今の制約を一つずつ潰す。潰せば、次の制約が現れます。

実例: E2Eレイテンシの約9割は、生成ではなく待ち行列と距離だった（第2回）。／推論サーバーを米国から東京へ動かすと約160ms縮んだ（第8回）。／Live字幕に特化した小モデルが、現役27B級と肩を並べた（特化の実例）。

3. ユーザー体験の代理指標を、正しく選ぶ — Optimize the Right Proxy for UX

ゴールは「速いモデル」ではなく「速く感じるプロダクト」です。でも、ユーザー体験そのものは直接は測れません。

だから、体験をよく代理する指標を一つ選ぶ。そして他のあらゆる施策を、その代理指標への寄与度で評価する。ここを外すと、すべてが狂います——代理が的外れなら、どれだけ最適化しても体験は1ミリも動きません（合否だけの採点に最適化して、その定義が拾わない価値を平板に取り残した経験があります＝Goodhart）。そして「指標が動いた」は「効いた」ではない。寄与は必ず対照で測る。安い対照が高価な変更を全軸で上回ったら、その変更は何も足していません。

良い代理指標は、平均を見ません。ユーザーが覚えているのは平均ではなく、一番ひどかった一回だから。最悪の一回の率——tail——こそ、体験の代理に組み込む。平均が同じでも、稀に致命的に壊れる作りは、製品として失格でした。

→ 最適化の狙いどころは、ベンチの数字ではなく「ユーザーが何を感じるか」の代理指標。それを正しく選び、寄与度で語る。

実例: 「十分速い」の締め切りは、コンテンツごとに400〜750msと動いた——単一のベンチ値では両側を外す（第7回）。／その”97%改善”は代理指標が循環していて、私は捨てた（捨てた97%）。／最高の翻訳より、最悪を減らすほうが効いた（床を上げる）。

4. 処理を高速化するより、処理自体を減らす — Eliminate, Don’t Accelerate

いちばん速い処理は、実行しない処理です。いちばん安い処理も、同じです。

最適化を考えるとき、まず探すのは「同じ仕事を、もっと速くやる方法」です。速いGPU、圧縮したモデル、効かせたキャッシュ。けれど高速化で戻ってくるのは、たいてい数割です。その仕事を丸ごと消せたなら、削減率は100%になる。同じ工数を投じるなら、消せるものを先に探すほうが割に合います。

とくに疑うべきは、良かれと思って足した処理です。品質のために足した工程が、実は何も足していないことがある。効いていない処理は、遅くて高いだけの純粋な負債です。ここで前の3原則が効いてきます——分解して測れば「消しても何も失わない処理」が見え、対照を取れば「足したのに効いていない処理」が見える。削除は、計測の当然の帰結です。

もちろん、何でも消せるわけではありません。大事なのは順序です。「この処理は要るか？」を先に、「どう速くするか？」を後に置く。逆にすると、消せたはずの処理を一生懸命に最適化することになります。

→ まず「要るか」を問う。要らないなら消す——消した処理は、速度もコストも100%改善します。要ると分かって初めて、どう速くするかを考える。

実例: 端末上のOCRを速くしたら-51%、呼ぶ回数を減らしたら電力予算が1桁落ちた（Awake Layer）。／1行の翻訳に数百トークンの”思考”。速いモデルを探す代わりに考えるのをやめさせたら、トークン27倍・レイテンシ4倍が1倍に戻った（第1回）。／文脈をどう足しても品質は動かなかった＝その注入は、消してよい処理だった（文脈と容量）。／安い対照が高価な変更を全軸で上回ったなら、その変更は何も足していない（対照を取る）。

新しい技術ではなく、意思決定の順序

この4つは、派手な新技術ではありません。測って、分解して、消して、狙いどころを選ぶという、意思決定の順序です。

面白いのは、これらが机上で組み立てた理論ではないことです。私がLYRを一人で作りながら、失敗と計測を繰り返すなかで、いわば手探りで一つずつ拾い集めたものでした。ところが後から振り返ると、40年前に『ザ・ゴール』が製造業に語ったこと——すべての機械を速くしても、工場全体は速くならない。全体の制約（ボトルネック）こそがシステムの性能を決める（制約理論／TOC）——と、驚くほど符合していました。狙ってTOCを当てはめたわけではありません。現場で個別に踏み抜いた失敗が、たまたま同じ地点に収束していた。工場を流れる「モノ」が、システムを流れる「リクエスト」に変わっても、全体の流れを見て制約を潰すという骨格は変わらないのだと、後から気づかされた——そういう順序です。

AIの性能は、モデルだけでは決まりません。測り方、分解の仕方、投資の順序——その意思決定の積み重ねが、最終的なユーザー体験を決めます。

このサイトでは、その意思決定を支えた実験と失敗、そしてそこから得られた知見を公開していきます。遅さの真犯人をどう突き止めたか。ベンチマークがどう嘘をついたか。私自身がどうボトルネックになっていたか——具体的な過程を、数字と失敗も含めて。

この記録は LYR Performance として公開しています。記事へのご感想・ご指摘はお問い合わせからどうぞ。AIシステム最適化の診断・伴走は、法人化にあわせて開始する予定です。