深掘り モデル側とソフト側の当事者が、同じ週に自分に不利な同じ話をした。「勝つのはオープンソースの道具だ。モデルがいちばん上手に使えるから」——だが勝敗を決める場所は、訓練ではなく実行にあるのかもしれない · 2026年9月8日
深掘りレポート第 31 回をお届けします。今回は、OpenAI と Box の幹部が同じ週に語った一つの機械論を、実際に測った論文二本の側から読み直します。
この機械論は「モデルがあなたのソフトを使えるかどうか」が訓練の時点で決まると仮定している。ところが、この件を実際に測った論文は目下二本しかなく、その二本はどちらも、決まるのは実行の時点だと答えている。そしてその答えは、処方箋をまるごと書き換える。
九月五日、OpenAI の研究担当副社長 Jerry Tworek がこう書いた。オープンソースの思いがけない利点は、モデルを訓練する会社があなたのソフトを無料で持ち帰り、「その操作の仕方」を学習できることだ。そして Blender は 3D アセット制作という品目で「勝ったばかりかもしれない」。理由は使いやすさではなく、モデルのほうが上手に使えるからだ。原文はこうである。「The unexpected benefit of open source is that it allows model training companies to train on using your software (and optimizing it) for free. Blender may have just won as a 3D asset creation software because the models will be better at using it than any proprietary ones」(@MillionInt、2026-09-05)。翌日、Box の CEO である Aaron Levie(Box が売っているのはプロプライエタリな企業向けソフトだ)が、同じ機械論のソフト側の版を出した。エージェントがソフトの大半を書き、エージェントは主にオープンソースで訓練され、だからエージェントはオープンソースの道具をいちばん得意とする。これを何周か回せば、オープンソースが既定になる。「If agents produce the vast majority of software in the future, and they're most trained on open source software, they will inevitably do their best work with those tools. If you cycle this enough times, it means that open source effectively becomes the dominant software in the future」(@levie、2026-09-06)。
一人はモデルの側に、もう一人はプロプライエタリなソフトの側に立ち、二人とも自分に不利なことを言っている。これで、この話を軽く見るためのいちばんよくある理由が消える。二人は自社のナラティブに道を敷いているのではない。
本稿の結論はこうだ。この機械論は形としては正しい。だが決定権を置く場所を間違えている。 発言した二人も、二人の推論をなぞる人たちも、「モデルがあなたのソフトを使えるかどうか」は事前訓練の時点で決まると仮定している。あなたのものがコーパスに入ればモデルは学び、入らなければ学ばない。この仮定を測った人は、これまで一人もいなかった。今年、二本の論文が測った。答えはこうだ。モデルが最初に書いた操作コードは、三割近くが動かない。だが動かなかったその三割を、ソフトが吐き出したエラーメッセージの原文ごと投げ返し、最大二回まで書き直させると、実行できる比率は 70.2% から 97.4% へ上がる。再訓練もコーパスの追加もない。効いたのは一片のエラーメッセージだけだ。
言い換えると、「モデルはオープンソースの道具のほうが上手に使える」という話のうち、訓練で本当に買えている部分は、二回の再試行でその大半を置き換えられる。そして再試行ができるかどうかは、ライセンス条項とは無関係な一点で決まる。エージェントがあなたのソフトを実際に動かし、人の言葉で書かれたエラーを読めるかどうかだ。
本稿は六段で進む。
① まずこの論争が何を争っているのかを整理する。本紙の内部にある、向きが逆で、読者に一度も出していない読みも含めて。
② 「モデルのほうが上手に使える」を、逆方向に動く二つの能力に分ける。本稿の要となる切り分けだ。
③ その堀の幅はすでに測られている。単位は「再試行の回数」である。
④ プロプライエタリ勢はとうに動いている。だが買ったのは別のものであり、そのことを誰も語っていない。
⑤ ごく安上がりなのに、世界の誰も走らせていない対照実験がある。
⑥ 本稿の判断、そして何が起きたら本紙の誤りと認めるか。
九月七日の夕刊に載せた同じ条目に対して、本稿は何を足したか。二つあり、どちらも指させる。
第一に、本紙がこの判断のために書いた検証条件を自分で攻めた。それは問うべきものを問うていなかった。 夕刊の原文はこうだ。「6 か月以内に、主流のプロプライエタリ・アプリケーション企業が初めて自社の操作軌跡コーパスかエージェント用ツール骨格を公開し、それを開発者向け施策ではなく配布戦略として語れば、道具の側が硬い証拠を得る」。調べてみた。Maya と 3ds Max を持つ Autodesk は、2026 年 4 月に Revit 公式 MCP サーバーの技術プレビューを出している。Figma は 2025 年 6 月、Microsoft は 2025 年 5 月に、これをプロトコル層そのものに仕立てた。Revit は Autodesk の建築・エンジニアリング向け BIM ソフトで、Blender が属する 3D アセット制作とは別の品目にあたる。本稿での役どころは「プロプライエタリ企業がエージェント向け操作インターフェースを出した」一例であって、Autodesk が Blender に応じたという話ではない。ただしこの三件が出したのはいずれも MCP の操作インターフェースで、原文が名指しした操作軌跡コーパスでもエージェント用ツール骨格でもない。原文の二つ目の条件、すなわち企業がそれを開発者向け施策ではなく配布戦略として語ったかどうかは、本稿では分けて数えていない。つまりこの観察点の問題は、すでに覆されたことではなく、書き方に判別力がなかったことにある。送り出されるものの型を指定していなかった。さらに重要なのは、これをどちらの側の証拠にも使えないことだ。プロプライエタリ企業が送り出したものと、オープンソースの道具が送り出したものは同じものではないのに、分けて数えた人がいない。
第二に、何が起きたら本紙の誤りと認めるかを書き切った。しかもその一点は本紙自身では消せない。 上の 70.2% から 97.4% という値は Blender で測られたもので、Blender の操作コードはもともと訓練コーパスに大量にある。だから「再試行が効く」のは、モデルが最初から七、八割は分かっていて、最後の一押しが足りなかっただけ、という可能性が残る。この二つの説明を分けるには、モデルがほとんど読んだことのないソフトで同じ実験を走らせる必要がある。走らせた人はいない。だから本稿の判断は仮説の段階に置き、確定した結論には格上げしない。理由はソースの不足ではなく、その対照群が存在しないことにある。
まず機械論を明確にしておく。飛ばされやすい中間段階が一つあるからだ。あわせて先に一点を押さえておく。Blender は無料でオープンソースの 3D ソフトであり、Maya、3ds Max、Revit は Autodesk の有償ライセンスが要るプロプライエタリなソフトだ。
AI に「木の椅子の 3D モデルを作って」と頼んだとき、AI は無から 3D ファイルを生やすわけではない。今いちばん効く方法はこうだ。AI がコードを一片書き、そのコードが人間の使う専門ソフトを操作し、そのソフトが椅子を作る。この流れ自体が、ひとつの判断の転回点になっている。マルチモーダル研究者の Lucas Beyer は 2026 年 7 月 25 日に公の場で、二年前ならこの道が勝つとは「絶対に」予想しなかったと書いた。「Did i think, two years ago, that multimodal language models using blender would be the best way to generate 3D assets? ABSOLUTELY NOT, yet here we are.」(@giffmana、2026-07-25)。Beyer は SigLIP の共著者で、DeepMind を経て現在は OpenAI に所属する。Tworek と同じ OpenAI にいるので、この一件は本稿の主要な根拠から独立した証拠には数えない。
すると問いはこうなる。モデルが書くそのコードは、どのソフトを操作するのか。モデルは、そのソフトで命令がどう書かれ、引数が何と呼ばれるかを知っていなければならない。それをどこで学ぶのか。もっとも直感的な答えは、そのソフトについてネット上にある公開テキスト、つまりチュートリアル、ソースコード、フォーラム、スクリプトの例からだ。
これが Tworek の一文の機械論にあたる。公開されて観測できるものだけが、訓練分布に入れる。 あなたのソフトがログインしないと操作できないなら、モデルはその操作記録を読んだことがなく、当然使えない。Blender は何もかも外に出しているから、モデルはとりわけ上手に使える。そして仕事がエージェントに任されるとき、「モデルがどれをとくに上手に使えるか」は「どれが選ばれるか」と同じ意味になる。道具を選ぶのは、もう利用者ではないからだ。利用者は今も金を払う側だが、手を動かして道具を選ぶ側ではなくなった。そのソフトをすでに買った顧客が、自分のエージェントに自分のファイルを読ませ、操作させる。ここでいうエージェントとは、自分でコードを書き、動かし、実行結果を見て、自分でもう一度直せる AI システムのことで、人が操作するものではない。
ここで一つ断っておく。本紙の内部には向きが逆の読みが一つあり、読者には一度も出していないし、本紙の判断にも格上げしていない。 その読みは、同じ機械論をモデル企業の採集戦略として読む。研究所が競って自社のエージェント用ツールをオープンソースにするのは、利用者を奪うためではなく、外部の利用者に訓練データを作らせるためだ。受益者はモデルの側にいて、利用者は無償で材料を供給している。同じ物理的事実に、正反対の価値の帰属が二つある。
本稿はどちらが勝つかを宣言しない。本稿が言いたいのは、両方が同じ未検証の仮定の上に建っていることだ。どちらの読みも、「モデルがあなたの道具を使えるかどうか」が決まる瞬間を訓練の瞬間だと前提している。その前提が成り立たないなら、両側の賃料の配分問題は、どちらも問い直しになる。
逸話は、異なる複数の事柄をひとまとめに絡めやすい。ほどかないと見えてこない。だから最初の一歩はほどくことだ。
「モデルは Blender のほうが上手に使える」は、まったく別の二つの能力に分けられる。
| この項目が問うこと | 平たく言えば | |
|---|---|---|
| 道具の習熟 | モデルがそのソフトで命令をどう書き、引数を何と呼ぶかを知っているか | そのソフトの言葉を話せるか |
| 領域の能力 | モデルが良い椅子の構造がどうあるべきかを知っているか | 椅子を分かっているか |
分けることが重要なのは、発言した二人の主張が第一の項目だけに落ちるからだ。Tworek が言ったのは「モデルのほうが上手に使える」(better at using it)であって、「モデルのほうが 3D を分かっている」ではない。オープンソースが買っているのは、モデルがあなたの命令セットを認識することであって、モデルの審美眼が上がることではない。
そして今年六月、この二つを別々に測った論文が出た。3DCodeBench は、マルチモーダルモデルが「手続き型 3D モデラー」を務められるかを評価するベンチマークで、テキストか画像を与え、コードを書かせ、ソフトに実行させて 3D オブジェクトを出す。著者陣には Google の研究者が含まれ、2026 年 5 月 31 日に投稿され、12 のフロンティアモデルを 212 のオブジェクトカテゴリで測った。
二つの発見が、上の二項目にちょうど落ち、しかも向きが逆だった。
つまり、Blender の事例では、モデルは確かに Blender の言葉を上手に話せる。だが作った椅子はやはりばらばらだ。「モデルは Blender をいちばん上手に使えるから、Blender が 3D 制作で勝った」という推論は、第二の項目で支えを失う。あるソフトを操作できることと、それで使い物になるものを作れることは別の話で、オープンソースに関係するのは前者だけだ。
これだけでも「Blender は勝ったばかりかもしれない」という一文は大きく絞られる。だが機械論を本当にひっくり返すのは次の節だ。
「モデルがあなたの命令セットを認識する」ことがオープンソースの買ったものだとして、それはどれほどの値打ちがあるのか。
この問いは以前なら立てられなかった。誰も測っていなかったからだ。3DCodeBench が測った。しかも測り方が意外なほど清潔である。
まずモデルに一発で答えさせ、書いたコードのうち実際に Blender で動く比率を記録する(論文はこれを executability、実行可能率と呼ぶ)。次に、動かなかったものに対して、とても単純なことをする。元の課題、モデルが前回書いたコード、ソフトが吐いたエラーメッセージの原文を、そのまままとめて投げ返し、もう一度書かせる。再試行は最大二回まで。
この再試行がどれほど素朴かは、はっきり書いておく必要がある。本稿全体の鍵だからだ。
「Each retry is a fresh API call — not a chat continuation — whose user message contains the original task, the previous attempt's full Python code, and the truncated stderr/traceback」
再試行のたびにまっさらな呼び出しをやり直す。会話の続きではない。モデルはさっき何が起きたかを覚えておらず、受け取るのは課題と、前回のコードと、切り詰められたエラーメッセージだけだ。この過程に人は一切介在しない。モデルは描画された画像を見ることもなく、このために再訓練されたこともない。機械が吐いたエラーの文字列、それだけである。
結果はこうだ。
「Aggregate executability across all 11×2=22 cells increases from 0.702 (single-turn) to 0.974 (multi-turn), representing a +27.2 pp improvement」
実行可能率は 70.2% から 97.4% になった。この集計値は 22 のセルにまたがり、うちモデル数は 11 で、前述の受験モデル 12 より一つ少ない。どれが欠け、なぜ欠けたのかは、本紙では確かめられていない。最上位の数モデルは複数回の後、そのまま 100% の天井に達した。
この値を機械論に戻して置いてみる。「オープンソースはモデルに、あなたのソフトの操作をただで学ばせる」で買えているのは、モデルが一発で正しく書ける確率だ。そして一発で外した三割近くは、エージェントがコードを実際に一度走らせ、エラーメッセージを一行受け取り、あと一、二回試せるなら、九割以上が埋め戻る。
同じ方向を指す独立の値がもう一つある。今年一月、バークレー、CMU、マックス・プランクの研究者グループが提案した VIGA は「コードを書く—描画する—点検する—直す」という反復の枠組みで、論文自身が training-free(訓練不要)と明記している。そして自前で提案した BlenderBench において、一発回答のベースラインに対して大幅な改善を示した。二本の論文、別々のチーム、別々の課題で、構造的な結論は一つに重なる。モデルに実行結果を見せる、あの反復が、本来なら訓練で買うはずのものの大きな部分を置き換えている。
これが重要なのは、決定権を、あなたがほとんど制御できない時点から、完全に制御できる時点へ移すからだ。
これが本稿の主張する転回にあたる。そしてこの転回は、次の節にある、誰も語っていない一件をちょうど説明する。
先に触れたとおり、夕刊の判断には「6 か月以内に、主流のプロプライエタリ・アプリケーション企業が初めて自社の操作軌跡コーパスかエージェント用ツール骨格を公開し、それを開発者向け施策ではなく配布戦略として語れば、道具の側が硬い証拠を得る」と書いてあった。すでに起きた公開は一社どころではない。ただし送り出されたのはいずれも MCP の操作インターフェースで、原文が名指しした二つのものではない。
| 誰が | いつ | 何を出したか |
|---|---|---|
| Microsoft | 2025 年 5 月 | Build で「オープンな agentic web」を掲げ、MCP をプロトコル層に採用し、NLWeb を推した。NLWeb は Microsoft の仕様で、ウェブサイトの各エンドポイントを既定で MCP サーバーにするもの。公式は「agentic web の HTML」と形容する |
| Figma | 2025 年 6 月 | Dev Mode MCP サーバーのベータ。エージェントがデザインファイルのデータを取れるようにする |
| Autodesk | 2026 年 4 月 | Revit 2027 の公式 MCP サーバー技術プレビュー |
ここでいう MCP を先に説明しておく。この節の鍵だからだ。MCP は 2024 年末に現れ、のちに業界全体が採用したプロトコルで、外部の AI アシスタントが標準の作法でソフトを読み取り、操作できるようにする。面白いのは、その出自が大戦略でも何でもなかったことだ。Anthropic のエンジニア二人が、デスクトップ版とエディタのあいだでコピー・アンド・ペーストを繰り返すのに耐えかね、一か月半で作った。2026 年には、公開ディレクトリに登録された MCP サーバーが 2 万近くに達している。
したがって「プロプライエタリ企業が金を払って参入するかを見守る」という問いの答えはこうだ。彼らは一年以上前に参入している。Autodesk 自身も含めて。この一件を単独で見ると、「道具の側が賃料を取る」という側を支持しているように見える。ライセンス課金で稼ぐ Autodesk までもが、モデルに自社のものを使わせようと急いでいるのだから。
だが Autodesk の一件をほどいてみると、話はまったく違う。Autodesk の Revit MCP サーバーは、
言い換えれば、Autodesk が買ったのは「モデルに Revit の操作を学ばせる」ことではなく、「すでに金を払った顧客のエージェントが自分のファイルを読める」ことだ。この二つは商業的には天と地ほど違うのに、いまの議論はこれを一つに混ぜている。
この三つを分けて並べたのが、本稿が出したい表になる。
| この項目は何か | 誰に払えるか | Blender | Revit(BIM、3D アセット制作ではない) | |
|---|---|---|---|---|
| 訓練分布に入れる | あなたの操作法が公開ネットに大量にあり、モデルが事前訓練で読める | ものを外にさらした者だけ | ある | ない |
| 公開ベンチマークに入れる | どの研究者でも、無料で、大量に、並列であなたのソフトをテスト環境として動かせる | 席数課金をしない者だけ | ある | ない |
| エージェントが操作できる | 機械可読なインターフェースがあり、エージェントが命令を出して結果を受け取れる | 誰でも。金で買える | ある | 一部(読み取り専用、ライセンス縛り。Autodesk 社員の実名発言による。公式ページは本紙が直接取得できていない) |
第三列は金で買えるもので、業界全体がすでに買った。上の二列はそうではない。
そして第二列こそ、本稿がもっとも過小評価されていると考える項目だ。ここが別の一件を決めるからだ。誰もがモデルの良し悪しを比べるのに使う、あのテストに誰が現れるか。この点は一節を割く値打ちがある。
進行中 ?
上の図が描いているのは、エージェント実行層そのものの競争だ。「ツールと端末をまたいで用事を済ませる」司令官を誰が務めるか。本稿が補うのは、この図の一段下にある層になる。司令官の手がどの道具に届くのか、そしてその範囲は何で決まるのか。図の分岐は誰が実行層を持つかを問い、本稿は実行層が誰に届くかを問う。
「モデルはオープンソースの道具のほうが上手に使える」を証明するのに要る実験は、じつは単純だ。同じ一組の 3D モデリング課題を用意し、一方はモデルに Blender を、もう一方は Maya を操作させ、成功率を比べる。
この実験を走らせた人はいない。
走らせない理由は、できないからではない。本紙が目下の主なエージェント操作系ベンチマークを当たったところ、実にきれいな形が出た。
「we instantiate ... on Blender 5.0 as a representative platform ... but the formulation is software-agnostic」
Blender を選んだのは測って優れていたからではなく、どれか一つを選ぶ必要があったからだ。どちらが正しいかを見分けられる対照実験は、彼らには走らせる能力があり、ただ走らせなかった。
ここで、上の主張を弱める反例を正直に書いておく。実在するからだ。プロプライエタリなソフトがベンチマークに入れないわけではない。 Microsoft 自身の Windows Agent Arena は本物の Windows の上で走る。ハルビン工業大学が今年四月に出した WindowsWorld は 17 のデスクトップアプリを対象にし、そこには Word、Excel、PowerPoint、Acrobat という有償のプロプライエタリなソフトが含まれる。課題は全部で 181、現時点で最良のモデルの成功率はおよそ 20.44% だ。
だから「プロプライエタリなソフトは評価に入れない」という文は誤りで、そうは書けない。ただし同じ一覧が示す形はもっと精確だ。それらのテストが対象にしたプロプライエタリなソフトはオフィスソフトであり、含めた画像編集ツールは GIMP とペイントで、Photoshop ではない。3D については Blender で、Maya ではない。つまり、専門性が高く、席数あたり高額なライセンスで売られる制作・エンジニアリング系のソフトほど、公開評価に現れない。Maya の公開価格は年 2,010 米ドルで、評価は何千回もの試行を並列で走らせる。ここで明記しておくが、次の一文は本節の論理から推したものであって、測られた現象ではない。Photoshop に代表される高額の専門制作ソフトは、構造上 Autodesk と同じ立場にある。エージェントが GIMP のほうを上手に使えるのは、GIMP が優れているからではなく、評価に入れるからだ。ライセンスでエージェントの生態系を門の外に置く側は、長期的には評価と最適化の反復に側面から迂回される。オープンソースに正面から打ち負かされるのではない。
この一件は自分で自分に餌をやる。公開テストであなたを測る人がいなければ、「モデルは何をいちばん上手に使えるか」の比較表のどれにもあなたは現れない。そしてモデル企業がエージェント能力を改善するとき、彼らはこうした公開テストに沿って最適化する。これは確かにオープンソースに有利な正のフィードバックだ。ただし注意してほしい。回っているのは評価と最適化の反復であって、Tworek の語る事前訓練コーパスではない。結論は同じでも、機械論が違う。機械論が違えば、解き方も違う。
本誌の見立て:
あるソフトがエージェントに選ばれるかどうかを決めるのは、ソースコードが公開されているかではなく、エージェントがそれを動かせるか、そして機械可読なエラーを一行読めるかである。前者は事前訓練の時点で決まり、遅く、プロプライエタリなソフトにとっては代償が不可能なほど高い。後者は実行の時点で決まり、金で買え、業界全体が一年以上前に買った。目下この件を測った唯一の値によれば、前者で買える優位の大部分は、二回の再試行で埋め戻せる。
この判断に沿えば、「自社製品はエージェントに操作されうるか」は、プロプライエタリなソフトの経営層にとって、オープンソース化するかどうかの問いではなくなる。その問いの答えは常に「しない」なので、偽の問いだ。本当に問うべきは、具体的な三つである。
1. エージェントはあなたのものを動かせるか。 マウスでクリックしなくてよい、機械可読なインターフェースがあるか。この項目には業界に既製の答え(MCP)があり、同業の大半はもうやっている。
2. 壁にぶつかったとき、人の言葉で書かれたエラーを受け取れるか。 これが本稿でもっとも直感に反する点だ。あなたのエラーメッセージの品質は、いまや流通資産である。あの 70.2% から 97.4% は、まるごとこれに懸かっている。「Error: invalid operation」を返す API と、「引数 radius は正の数が必要です。渡された値は -1 です」を返す API は、エージェントにとってまったく別の製品だ。
3. あなたのものを、無料で、並列に、テスト環境として動かせるか。 この項目がいちばん高くつき、いちばん思いつく人が少ない。他人がモデルの良し悪しを測るあの比較に、あなたが現れるかどうかを決める。検討に値する形はオープンソース化ではなく、研究と評価のための、無償で、並列に動かせる、画面なしの実行層だ。
この判断を覆す条件:
この四つのうち、時間の窓を持つのは 3 番目だけである。1、2、4 番目は事象で発火する。見張るべきは誰かがあの実験を走らせたかどうかで、日付ではない。
1. もっとも脆い一点で、しかも本紙自身では消せない。 あの 70.2%→97.4% は Blender で測られ、Blender の操作コードは訓練コーパスに大量にある。だから「再試行が差を埋めた」のは、モデルが最初から七、八割は分かっていたからにすぎない可能性がある。モデルがほとんど読んだことのないソフトで同じ再試行実験を走らせ、実行可能率が跳ね上がらなかったなら、本稿の中核主張は崩れる。訓練分布こそが本当の関門であり、再試行はその現れにすぎなかったことになる。この実験を走らせた人はいない。この対照が出るまで、本稿は仮説の段階にとどめ、格上げしない。
2. 誰かが Blender と Maya の同題対照を実際に走らせ、モデルの再試行回数を統制したうえでなお、オープンソースの側に明確な優位が残るなら、Tworek の元の版は欠けていたあの値を手に入れ、本稿は退く。この対照は現時点で存在せず、本稿のこの条は値を待つ状態で止まる。
3. 今後 2 四半期のうちに、プロプライエタリ企業のエージェント向けインターフェースが読み取り専用から書き込み可へ移り、しかも有償ライセンスの後ろに縛られなくなるなら、つまり訓練分布に入るために課金の関門を本当に捨て始めるなら、彼ら自身が訓練分布こそ急所だと考えていることになり、「彼らが買ったのは別のものだ」という本稿の読みは誤りになる。この 2 四半期という窓は本紙が自分で置いたもので、発言した二人はどちらも期限を示していない。
4. 逆向きに、汎用の GUI 操作能力が成熟し、モデルが特定のソフトの予備知識なしに任意のプログラムを操作できるようになれば、「公開されて観測できる」は入場条件でなくなり、この論争の両側が同時に失効する。この道は現時点で成熟からほど遠い。今年四月の、17 のデスクトップアプリを対象にしたあのテストで、最良のモデルの成功率はおよそ 20.44% だ。
最後の一文は、いちばん飛ばされやすい場所に残す。この論争全体(本紙の内部にある、公表していない逆向きの読みも含めて)は、「モデルが何を使えるようになるか」は遠くで、他人の訓練クラスターのなかで、あなたが関われないときに決まる、と前提している。目下の唯一の測定は、その大きな部分が、あなたのソフトがあの一行のエラーメッセージを吐く瞬間に決まると言っている。その一行を書いたのは、あなただ。
本記事は日本語版・英語版・中国語版と同一の調査と判断にもとづいて書かれており、すべての主張は一次資料へのリンクを備えています。
自社の製品が返すエラーメッセージを、エージェントの目で読み直したことはありますか。「invalid operation」の一行がいくつ残っているか、数えてみた結果をぜひお聞かせください。次回の材料になります。