Mistral AIが「コード実行ツール呼び出し」に関する特許を出願！今後のAI開発への影響は？

Mistral AIが「コードで実装されたツール呼び出し（Code implemented tool calls）」に関する特許を出願したことが話題になっています。LLMが外部ツールを呼び出してコードを実行する仕組みを最適化・制御するための技術と見られており、AIエージェントの進化において非常に重要な一歩となりそうです。今後の動向に注目が集まります。

誰か先行技術になりそうなもの知らない？RPCコールなんてどう考えても斬新なものじゃないだろ。

ソフトウェア工学の世界じゃどこにでもある、一番ありふれたパターンに対する特許だな。

EUの企業が、EUでは基本的に特許が取れないはずのソフトウェア機能を、わざわざアメリカで特許申請してるのが面白いな。

アメリカで似たような特許を武器にされるのを防ぐための防衛策ってのは明らかだろ。

欧州じゃ誰もそんなこと気にしてないしな。

「LLMによる～」っていうのは、くだらない特許のための新しい「コンピュータ上の～」みたいな決まり文句になったのか？

技術的な話はさておき（ネットワーク越しの非同期awaitに見えるし）、興味深いのはなぜMistralがアメリカでこれを特許化したのかってところだな。

単純に、この特許が発明の保護というより、アメリカでビジネスをするためのものだからだ。

アメリカは欧州よりもソフトウェア特許に寛容だしね。米国の特許があれば、すでに多くの特許を抱える企業とやり取りする際に防衛的なレバレッジになったり、クロスライセンスに使えたり、投資家へのアピール材料にもなる。

ある種の滑稽さはあるけど、フランス人は昔からそういう不条理に慣れてるからな。フランスのオープンウェイト企業がわざわざ大西洋を渡ってループ処理を特許で囲い込むのは、コードがすごいからじゃなくて、アメリカ市場ではそのループがビジネス上の貴重な資産になるからってことだろ。

自分もいくつかソフトウェア特許に名前が載ってるけど（正直、消そうとしたけど無理だったんだ）、自信を持って言える。価値のあるソフトウェア特許なんて一つもない。つまり「当業者が容易に思いつく」レベルを超えていて、かつ実際の投資を守れるようなものは存在しない。

ソフトウェア特許は業界の災いだ。特許は本来、コストのかかる研究を守るためのもの。アイデアを出すだけならコストはかからない（医学研究なんかは別だけど）。ソフトウェア特許がやってるのは、競争を阻害する地雷原を作ることだけだよ。

ソフトウェアなら著作権の方がよっぽどマシなツールだ。最高の「実装」をした奴を勝たせればいいんだよ。コストがかかるのは実装、テスト、出荷、保守なんだから。そこを保護すべきだ。

愚痴ってすまない。

Scala[1]のコミュニティではもう数年前から似たようなことに取り組んでて[2]、論文も公開済みだ[3]。Mistralは単にこの成果を盗もうとしてるんじゃないかって疑ってしまうな。

[1] https://martinodersky.substack.com/p/tracked-capabilities-fo...
[2] https://github.com/lampepfl/tacit
[3] https://www.caisconf.org/program/2026/papers/securing-agents...

特許関連の議論での定型句だけど、重要なのは「クレーム（特許請求の範囲）」だから、コメントする前にそこを読むべきだよ。

それにこれはまだ特許出願の段階で、審査すら受けてない。この段階ではクレームは常に広すぎるものだ。特許出願ってそういうものだからね。出願人は（厚かましくも）できるだけ広い「知的領土」を確保しようとする（なぜならタダだから！）けど、特許庁が既存の先行技術と重なる部分を削ってくる。出願人はクレームを狭めていき、当局が「これなら斬新で非自明だ」と認めるまで押し問答が続くんだ。やり取りにはコストと時間がかかるから、出願人も現実的なクレームにするインセンティブが働くわけだ。

交渉は通常、最も広いメインのクレームから始めて、だんだん機能を絞った「従属クレーム」を付け加えていく形になる。これが依存関係ツリーを作るんだ。

審査官は各クレームを個別に判断するから、広いクレームが却下されても、狭いクレームが生き残る可能性がある。それがまだ「未開の領土」を示すことになる。出願人はそこにフォーカスして、独立クレームに昇格させたりするわけだ。

だから、特許出願で面白いのは従属クレームの方だったりする。

今回の件だと、一番のメインのクレームはLLMによるツールコールという概念そのものを指してて、指摘の通りあまりに広すぎて先行技術で蹴られるだろうね。だけど従属クレームは興味深い。

ざっと見たところ、Mistralが斬新だと考えてるのは「ステートレスで再開可能なサンドボックス」のようだね。生成されたコードを「非決定論的な操作」（乱数や日付など）まで実行して、結果が得られたら、そこまでのコードを全部リプレイする仕組みだ。以前の操作結果はキャッシュして再実行時に使うんだ。

この分野の専門家じゃないけど、昔すごく単純なツール呼び出しのLLMハーネスを書いたことがあって、当時は「コードを何回も再実行するなんて無駄で非効率だ」と思ってた。でも仕様書を見ると、複雑な状況下では別の考慮事項があるみたいだから、タイトルやメインのクレームよりもずっと限定的で面白い内容なのかもしれない。

うわお :D Mistralがなぜそうするのかという大きな話は置いといて、そのアイデア自体について言わせてもらうと。
自分も近々自前のハーネスを作るつもりなんだけど、その中核にある原則は、最初から「LLMが試みるすべてのツールコールをパースして、自分で実行する」ことにしてる。多くの場合、Rustのcoreutilsのツールに委譲するか、LSPサーバーを叩くってことだね。

理由はこれ：

• LLMが世界とどう関わるかを最大限に制御できる（サポートする引数/しない引数の絞り込みすらできる）
• 外部との対話が一点に集中するから監視もしやすい
• 少しずつ機能を足していけるし、コードがどう変化して、なぜそう動くのかを根本から理解できる

一番の課題は、LLMがツールコールをして、その結果に対してまた反応させる部分だね。どこまで上手くやれるか楽しみだよ :D

話は戻るけど、「コードで実装されたツールコール」ってのは、結局「ああ、俺のハーネスでもできるよ」っていうレベルの話だよね（必要なものは全部コードで実装済みだし）。