Rust の複雑な API をテストするには、LLM と「設計図」の組み合わせが効く

Petri ネットって何？『設計図』と言われても、プログラミングの図面とはどう違うの？

Petri ネットは、単なるプログラムの流れ図じゃなくて、「資源がどう移動するか」を描く仕組みなんです。 通常のフローチャートなら、「AをしたらBへ」という矢印の流れだけを追います。でも Petri ネットは、そこに「いま何個の資源がどこにあるのか」という「状態」を同時に追跡する。たとえば、同時実行の世界では、「メモリ領域の所有権がどの処理に握られているのか」「この操作をするには前提条件として何が満たされているのか」を可視化する必要があります。Petri ネット上の丸いノードが「状態」で、矢印が「処理」で、その間を「トークン」という粒が移動する。トークンの位置と個数が、いま何が許可されているかを表す。 つまり普通の図面は「人間が読むための流れ」を描きますが、Petri ネットは「コンピュータが検査できる法則」を描く感じです。そこに LLM を繋ぐと、機械的に「法的に正しいテストシナリオ」だけを生成させられるようになるわけで、そこが裏技的に賢い仕掛けなのかもしれません。

Rust の API テストが難しいって話だけど、これって開発者なら誰もが困ってることなの？それとも大規模なプロジェクト特有の悩み？

複数処理の複雑さって、スケールの問題というより「並行性を持つライブラリ設計」の問題なんですよね。小規模でも起きる。 たとえば、Rust で共有リソースを扱うライブラリを書いたら、すぐに「この順序で呼ぶなら大丈夫だけど、別の順序だと壊れる」みたいな暗黙の制約が生まれます。ロック機構、所有権の移動、初期化と後始末。こういった依存関係は、テストする側が全パターン手で網羅しようとすると、指数関数的に増えていく。 ただ、困る度合いは開発者によってバラバラです。CGI スクリプトレベルの小さな実装なら気にしないし、オープンソースライブラリ化して他人に使われるものなら重大。社内ツールか外部公開かで、テストへの投資判断が変わる。 実は、この論文が面白いのは、そこなんです。「形式検証のような厳密さは要らないけど、LLM だけだと危ない」という中層の開発チームが増えた。ちょっと上質なテストが欲しいけど、専門家を雇う予算はない、みたいな。ペトリネットを一度描けば、あとは半自動で複雑なシナリオが出てくるという提案は、そういう現実的な困り方に応えているように見えます。

なぜ今この方法が提案されたの？それまで『LLM で十分』か『形式検証するしかない』かの二択だったの？

LLM が普及する前は、「形式検証するしかない」で事足りていたんですよ。並行処理のテストなんて元々難しいから、品質が必要な部分は専門家の手作業か形式手法で対応する。それが常識でした。 ところが ChatGPT あたりから、LLM が「それなりに使える」レベルになった。経営層や開発チームも「AI でテスト自動化できるのでは」と期待し始める。実際、簡単なテストなら LLM でさっと書ける。だから形式検証の手間をかける動機が薄れてきた。 でも蓋を開けると、Rust みたいに並行処理が複雑なドメインでは、LLM だけでは穴だらけのテストになる。API のルール違反に気づかない。かといって、形式検証に戻るのも、今さら感がある。 そこで出てきたのが「ハイブリッド案」。Petri ネットという軽めの設計図で、LLM の「速さ」と「柔軟性」を活かしながら、形式手法の「正確さ」をほんの少し混ぜる。LLM 一本槍の時代から、ちょっと賢くなった第二世代のアプローチだと言えそうです。要するに、LLM の限界が見えてきたからこそ、この提案がいま意味を持つようになったのかもしれません。

これって要するに『人間が大枠を決めて、AI に細部を任せる』という分業の話？そういうやり方、他の分野でも増えてるってことなの？

大枠と細部の分業という見立ては合ってるんですが、もう一段階深い仕組みがあるんです。 人間が単に「大枠」を決めてるのではなく、「AI が暴走しないための制約」を数学的に埋め込んでる点が肝。ペトリネットは設計図というより「ルールの言語化」に近い。LLM に「テスト書いて」と言うだけだと好き放題やるけど、「この状態遷移図を満たすシナリオだけで」と条件を渡すと、AI は勝手にそこからはみ出せなくなる。つまり人間の判断領域が明確に保全されてる。 これは確かに増えてますね。設計とコード生成の組み合わせ、医療診断の専門家指標と AI の提案、建築の構造計算と生成デザイン。ただ「人間が決めて AI が実行」という素朴な分業ではなく、「人間が境界を引いて、その中で AI が働く」という形になってる。AI の得意な領域と人間の責任領域が、明確に分けられてるのが特徴に見えます。 単なる役割分担というより、AI の自由度を設計の時点で制御する思想の広がりなのかもしれません。

形式検証の専門家の仕事が減っちゃうのでは？それとも逆に、こういう『AI + 設計図』の仕組みを作る専門家が必要になるってことなの？

職人的な検証者がいなくなるのではなく、その人たちの仕事が「上流へシフト」するように見えます。 昔は、設計図を引いて、そこから手作業でテストケースを書く。その一連の流れ全体が検証専門家の仕事でした。いま提案されているのは、設計図の品質が全てを左右する世界。ペトリネットで API の状態遷移を正しく記述できるかが勝敗を分ける。そうなると、形式検証の専門知識は「テストコード生成」から「設計図の正確性」へシフトしていくのかもしれません。 つまり、自動化で減るのは「定型的な書き出し作業」。逆に増えるのは「こういう仕組みをどう導入するか」「ペトリネットで何を表現すべきか」という設計段階の思考。専門家が手作業を減らして気軽になった分、より複雑な API や、より厳密な検証が必要な領域へ目が向くようになるのかもしれません。つまり、仕事の粒度が変わって、規模は変わらないということなんじゃないかと。