Agentic OS 技術スタックを下から読む 第9回：答える時間を、もっと使う ―― 推論時に計算を足す

前回は、考える力をどう鍛えるかを見た。

ただし、学習で力を身につけたら、それで話が終わるわけではない。学習が終わったモデルでも、答える瞬間にどれだけ計算を使うかで、出てくる答えは変わる。

同じ人でも、即答したときと、紙に書いて考え直したときでは、答えの質が違う。知識や能力が急に増えたわけではない。持っている力の使い方が変わっただけである。

今回見るのは、その話だ。

前回が「能力をどう作るか」だったとすれば、今回は「作った能力を、答える時にどう引き出すか」である。学習の話には戻らない。答える時間に計算を足すと何が起きるのか。その代わりに何を払うのか。そこに絞って見ていく。

一度で答えなくてよい

学習済みのモデルは、ふつう一度の生成で答えを返す。

質問を受け取り、次に出す文字を順に選び、最後まで書き切る。これは速い。安い。対話の手触りもよい。日常的な質問なら、それで十分なことが多い。

けれども、難しい問いでは、その一度が外れることがある。

途中で条件を読み違える。最初に思いついた筋に引っぱられる。大事な例外を見落とす。計算問題なら一段だけ間違える。文章なら、見た目は自然でも、前提と結論がずれている。

このとき問題になるのは、モデルがまったく何も知らないことだけではない。持っている力を、短い一回の生成でうまく引き出せなかったことも問題になる。

そこで、答えを出す段階に工夫を入れる。

一度で答えさせず、何度か試す。出した答えを点検させる。途中の筋道を長めに展開させる。形はいろいろあるが、根は同じである。

答えるために、より多くの計算を使う。

何度も試して、選ぶ

一つ目のやり方は、同じ問いに何度も答えさせ、その中から選ぶことだ。

一回だけ答えさせると、その答えがたまたま外れているかもしれない。だが、同じ問いを何度か投げると、答えにはばらつきが出る。ある回では正しい方向に進み、別の回では途中で外れる。ある答えは結論だけ合っているが、理由が弱い。別の答えは理由の筋が通っている。

そこで、複数の答えを見比べる。

単純な問題なら、最も多く出てきた答えを採るだけでもよい。多くの試行が同じ結論に集まるなら、その結論は一回だけ出たものより信用しやすい。もう少し複雑な問題なら、答え同士の筋の通り方を比べる。前提を落としていないか。矛盾していないか。問いにちゃんと答えているか。

これは、一度の当て勘にすべてを預けないということでもある。

もちろん、魔法ではない。何度試しても、同じ勘違いに落ちることはある。選ぶ側の基準が弱ければ、もっともらしい誤答を選ぶこともある。それでも、一回だけで終わるより、外れを減らせる場面は多い。

代わりに、計算は増える。

五回試せば、おおまかには五回分の生成が必要になる。十回試せば、さらに重くなる。選ぶための処理も要る。答えが少しよくなるとしても、その改善が余分な時間と費用に見合うかは、問いによって違う。

下書きして、直す

二つ目のやり方は、最初の答えを下書きとして扱うことだ。

一度答えを書かせる。そこで終わりにしない。その答えに穴がないかを点検させる。条件を満たしているか。途中で飛躍していないか。結論が問いに対して強すぎないか。必要なら、問題点を直して、もう一度答えを出す。

人が文章を書くときも、最初から完成品になることは少ない。まず粗く書く。読んでみる。余計なところを削る。足りない説明を補う。順番を入れ替える。そうして、少しずつ形を整える。

モデルにも、似たことをさせられる。

最初の答えでは見落としていた条件に、点検の段階で気づくことがある。矛盾した二つの主張を、あとから直せることがある。問いが複数の部分からできている場合、一部に答えていないことを検出できることもある。

このやり方のよいところは、改善の方向が見えやすいことだ。

ただ何度も答えを出すだけでは、毎回の答えが横に並ぶ。下書きして直す方法では、前の答えを材料にして、次の答えを作る。失敗を見つけ、その失敗に手を入れる。うまく働けば、答えは段階的に整っていく。

ただし、これも計算を使う。

下書き、点検、修正を一回ずつ行えば、そのぶん遅くなる。何度も繰り返せば、さらに重くなる。また、点検が必ず正しいとは限らない。直したつもりで、別の問題を入れることもある。人の推敲でも、直しすぎて文章が悪くなることがある。それと同じである。

ただ、長く考えさせる

三つ目は、もっと単純だ。

ただ、長く考えさせる。

即答ではなく、途中の筋道をより丁寧に展開させる。条件を並べる。場合を分ける。計算を一段ずつ進める。結論に飛ばず、そこへ至る道を長めに取る。

簡単な問いでは、あまり差は出ない。

今日の日付を聞かれたときに、長く考えさせても意味は薄い。短い定義を尋ねるだけなら、即答で足りる。むしろ長く考えさせるほど、余計な説明が増えて邪魔になる。

だが、込み入った問いでは、長く考えることが効く場合がある。

条件が多い問題では、短く答えると見落としやすい。複数の手順を踏む問題では、一段飛ばすと後ろが崩れる。文章の構成を考えるときも、先に全体の流れを置いたほうが、結論がぶれにくい。

ここで大事なのは、長く書けば常によい、という話ではないことだ。

長い出力は、それ自体が価値ではない。長く考える価値があるのは、途中の筋道を展開することで間違いが減る場合である。逆に、簡単な問いに長い推論をかけると、遅くなり、読みにくくなり、場合によっては余計な迷いを持ち込む。

つまり、考える時間は薬にもなるが、量を間違えると無駄にもなる。

速さ・コスト・精度の三角

ここまでの三つのやり方には、共通した構造がある。

何度も試して選ぶ。下書きして直す。長く考えさせる。どれも、答える段階で追加の計算を使っている。そして、その計算によって精度を買っている。

ここには、速さ、コスト、精度の三角形がある。

速く答えたいなら、一回で返すのがよい。安く済ませたいときも、同じである。しかし、難しい問いで精度を上げたいなら、追加の試行や点検や長い思考が効くことがある。そのかわり、待ち時間は伸びる。計算資源も使う。

三つを同時に最大にはしにくい。

速く、安く、正確に。どれも欲しい。けれども、現実のシステムでは、問いの重さに応じて配分を決める必要がある。すべての問いに重い推論を回すと、利用者は待たされる。費用も膨らむ。簡単な質問にまで念入りな計算をかけるのは、ほとんどの場合、ただの無駄である。

一方で、精度が重い場面はある。

後で大きな影響を残す判断。取り返しのつきにくい操作。人の安全やお金や信用に関わる決定。こうした場面では、多少遅くても、答える前に余分な計算を使う価値がある。一回で急いで返すより、複数の道を試し、点検し、必要ならやり直したほうがよい。

だから重要なのは、重い推論そのものではない。

どこに重く使うかである。

Agentic OS への含意

この話は、Agentic OS を考えるときにそのまま効いてくる。

エージェントは、そもそも一発で答えを返すだけの存在ではない。タスクを段階に分ける。必要な情報を取りに行く。途中の結果を見て、次に何をするかを決める。失敗したら別の手を試す。最後に答えをまとめる。

これは、答える時間に計算を足す振る舞いそのものだ。

たとえば、ある依頼に対して、まず安く速く方針を立てる。次に必要な箇所だけ詳しく調べる。危ない操作の前には点検を入れる。最後の出力だけは慎重に確認する。こうした設計は、モデルの中身だけでは決まらない。モデルの上に置かれた仕組みが、どの段階でどれだけ考えさせるかを決めている。

ここで、土台で見たコストの話が戻ってくる。

計算は無料ではない。待ち時間も無料ではない。だから、エージェント設計では、考える時間を配る必要がある。すべてを高価で慎重な処理に回せば、システムは重くなる。すべてを安い即答に寄せれば、難しい場面で壊れやすくなる。

安く速い下書きと、高く慎重な最終判断を、どこで分けるか。

何度も試すべき問いはどれか。自分で点検させるべき箇所はどこか。長く考えさせる価値がある場面はどこか。逆に、すぐ返してよい場面はどこか。

この配分が、実用上の品質を大きく左右する。

学習によって能力を作ることは大事である。だが、作った能力を毎回同じ強さで使う必要はない。軽い問いには軽く答える。重い問いには時間をかける。途中で危うさが見えたら、追加で考えさせる。エージェントらしさの一部は、この調整にある。

答える時間に計算を足すことは、単に賢そうに長く考えることではない。

それは、限られた計算をどこに使うかを決める設計の問題である。速さを取るのか。費用を抑えるのか。精度を上げるのか。問いごとに、その釣り合いを変える。

学習が終わったあとにも、まだできることはある。

答える瞬間の計算を増やせば、答えはよくなることがある。ただし、その改善はただではない。だからこそ、Agentic OS では、考える力そのものだけでなく、考える時間の配分が重要になる。

次回は、能力のもう一つの面を見る。モデルが、世界の動きを内側にどれだけ持てるか、という話に入る。