ロボティクスこそJevだ｜判断だけを返すAIが入る制御の層

こんにちは、株式会社TIMEWELLの濱本です。

ロボットを動かしたことがある人なら、一度はこの壁にぶつかっていると思います。動き自体は作れる。困るのは「いま、どれをやるか」を決めるところです。

棚の前に立ったアームが、掴むのか、位置を直すのか、人が来たので待つのか。搬送ロボットが、その角を曲がるのか、直進して回り込むのか。動作そのものは既存のプランナと制御器が出せます。けれど「どれを選ぶか」を書こうとすると、条件分岐が増え続けて手に負えなくなる。そこで大規模言語モデルを持ってくると、今度は返事を書くのに数秒かかって、ロボットが固まります。

2026年9月15日（米国時間）に発表されたTypeSafe AIの「Jev（ジェブ）」は、まさにこの層のための部品です¹²。文章を一行も書かず、こちらが決めた選択肢の中から1つを確率つきで返す。それだけをやるモデルです。

先に結論を書きます。

• ロボットの制御は層に分かれていて、サーボは1000Hz前後、VLAは5〜50Hz、タスク計画は1Hz未満。Jevは2〜14Hzの層に入る
• Jevは画像を扱えない。だから知覚は別の仕組みが担当し、Jevには文字にした状態だけを渡す
• 選択肢が有限で、状態を文字にできて、判断を並列に何十個も投げたいとき、この形がいちばん素直に効く
• 出力が無料なので、判断のコストが実質消える。毎秒10回問い合わせても1時間7ドル
• ただし安全機能には使ってはいけない。型を守ることと、正しく答えることは別

Jevとは何をするモデルか

まず基本から書きます。前提のない方でも読めるようにします。

チャットのAIは、質問に対して文章を書いて返します。「この部品を掴むべきですか」と聞けば、「はい、対象物の位置が安定しているため掴むことを推奨します」と丁寧に返ってきます。ところがロボットを動かすプログラムが欲しいのは、この文章ではありません。「掴む」という選択と、それがどれくらい確からしいかの数字だけです。文章で返されると、プログラム側でそれを読み解いて分岐に使える形へ変換し直す工程が要ります。しかも一語ずつ書き足すので時間がかかる。

Jevはこの工程を最初から省いた設計です。渡すのは「状況を表すテキスト」と「答えてほしい質問」。質問は3種類しかありません³。

Choice は、選択肢から1つを選びます。「grasp（掴む）」「reposition（位置を直す）」「wait（待つ）」と並べておくと、どれかを返し、あわせて各選択肢の確率と、答え全体の確信度が付いてきます。

Score は、決めた尺度で段階を付けます。「この置き方の安定度は」に対して、「不安定」「やや不安定」「安定」の3段階を定義しておけば、1.3 のような段階の間の値も返ります。

Noul は、ある文が真である確率を0から1で返します。「対象物が把持範囲に入っている」と書けば、0.87 のような数字が返る。これがいちばん使いでがあります。

そして重要な性質が2つあります。1つ目は、1回の呼び出しに種類の違う質問を何十個も混ぜられて、しかも並列に評価されること³。質問を増やしても待ち時間はほとんど変わりません。2つ目は、出力が無料なこと。入力100万トークンあたり0.042ドルで、出力は課金されません⁴。書く工程がないので、書いた分の料金が発生しないわけです。

TypeSafe AIはこれを「System One モデル」と名付けました。心理学者ダニエル・カーネマンが「速い直感の思考」と呼んだSystem 1から取った名前で、公式ドキュメントは「返事を書かず、コードを生成せず、推論の説明も生成しない」と定義しています⁵。

そして、ロボティクスの話に入る前に押さえておくべき制約が1つ。Jevはテキストしか受け取れません。 公式ドキュメントに「テキスト入力のみ。画像・音声・動画は未対応」と明記されています⁵。これは弱点に見えて、実は設計を素直にします。あとで詳しく書きます。

なお、当社は日本語での実力を自分で測っています。コラム1,852本に対して「この記事は輸出管理を主題にしているか」という真偽の質問を投げたところ、しきい値0.20で適合率96.4%、再現率87.9%でした。一方、9つの分類から1つを選ばせる形式は36%しか当たりません⁶。多値で当てにいくより、真偽を並べたほうが精度も解釈も安定する。 これはロボットの判断を設計するときにもそのまま効いてきます。

ロボットの制御は層に分かれている

ここが本題です。「ロボットにAIを入れる」と一言で言いますが、ロボットの中には周期の違う層が積み重なっていて、層ごとに入れるべきものが違います。

いちばん下がサーボ制御。関節の角度と電流を追い込む層で、産業用ロボットでは1000Hz前後、つまり1ミリ秒に1回回っています。ここは決定論的な制御則の世界で、確率を返すモデルが入る余地はありません。

その上が軌道生成とモーションプランニング。「この姿勢からこの姿勢へ、障害物を避けてどう動くか」を計算する層で、数十Hzから数百Hz。

さらに上が、いま急速に発達しているVLA（Vision-Language-Action）モデルの層です。カメラの画像と言語の指示から、直接ロボットの行動を出します。オープンソースのOpenVLAは推論が3〜5Hzで、A100というGPUを使っても1ステップの行動生成に0.33秒かかります⁷。並列デコードと行動のまとめ出し（アクションチャンキング）で高速化したOpenVLA-OFT+は77.9Hzに達し、Physical Intelligenceのπ0は最大50Hzで動きます⁸⁹。この層はいま、周波数の競争をしている最中です。

そしていちばん上がタスク計画。「棚から部品を取って、検査台に置いて、不良なら赤箱へ」という段取りを決める層で、ここは1Hzを切ります。大規模言語モデルが入り始めているのはこの層です。

Jevが入るのは、VLAとタスク計画の間です。 応答が70〜500ミリ秒¹、つまり2〜14Hz。連続的な動作を作るには遅すぎて、段取り全体を考えるには速すぎる。この中間に、実はいちばん条件分岐が増える層があります。

その層でやっていることを言葉にすると、こうなります。いま見えている状況に対して、用意された行動の中からどれを起動するかを選ぶ。そして、そのまま進めてよいか、人を呼ぶか、止まるかを決める。まさにChoiceとNoulの形です。

なぜロボティクスと相性が良いのか

理由は4つあります。

1つ目。ロボットの行動は、もともと離散です。 文章生成AIが向いているのは「何を書くか」に無限の自由度がある仕事ですが、ロボットが次にやることは、たいてい有限のリストです。掴む、離す、寄る、退く、待つ、人を呼ぶ。この「有限の選択肢から1つ」という形が、Choiceとそのまま一致します。無限の自由度を持つモデルに有限の選択をさせて、返ってきた文章を解析する、という回り道が要りません。

2つ目。ロボットの状態は、もともと数字と記号です。 関節角、力覚センサの値、検出した物体のリストと座標、バッテリ残量、直前に失敗した回数。これらは全部そのまま文字にできます。画像を渡せないという制約が、ここではほとんど効きません。むしろ、画像から文字への変換をどこでやるかを明示的に設計させるぶん、構成が素直になります。

この点は、発表後に公開された実装がよく示しています。Milind S氏の構成は、パソコンの画面を操作させるのに、スクリーンショットをどこにも送りません。端末内の小さな画像モデルが画面上の部品を切り出し、端末内のOCRがラベルを読み、その文字列だけをJevに渡す。返ってきた部品ごとの確率でいちばん高いものをクリックし、また検出をやり直す。投稿者の説明では1判断あたり約90ミリ秒でした¹⁰。ロボットでも構造はまったく同じで、カメラとセンサの出力を知覚のモジュールが「物体リスト」に変え、その文字列を渡します。

3つ目。質問を並列に何十個も投げても、待ち時間が変わらない。 ここがロボットで効きます。1回の判断のたびに、本当は確かめたいことが山ほどあります。対象物は把持範囲にあるか。周囲に人はいるか。直前と同じ失敗を繰り返していないか。掴む姿勢は安定しているか。バッテリは次の動作を完遂できるか。予定の時間を超過していないか。

これを段階的に聞くと、聞くほど遅くなります。Jevは全部を1回に混ぜられて、それでも応答時間がほとんど変わりません。「まず緊急度を判定して、高ければ次を聞く」という設計をやめて、聞きたいことを全部投げ、組み合わせはコード側で決める。公式の設計ガイドも「コードが決定的な処理を持ち、制御の流れを握る。モデルは常識的な判断や、構造化されていないデータの解釈が必要なところにだけ現れる」と書いています¹¹。ロボットの制御を書いてきた人には、これは当たり前の設計原則に聞こえるはずです。

4つ目。確率と確信度が返るので、止める線が引ける。 これがいちばん大きい理由かもしれません。ロボットは間違えると物が壊れ、人が危ない。だから「わからないときに止まる」が設計の中心になります。Jevは選択肢ごとの確率と、答え全体の確信度を返します。公式は確信度が高ければ自動で進め、中程度なら慎重に、低ければ「動かさず、人に回すか、別の仕組みに落とす」という3段階の運用を勧めています¹²。

この3段階は、そのままロボットの運用に写せます。確信度が高ければ通常速度で実行。中程度なら減速して実行し、記録を残す。低ければ停止して人を呼ぶ。判断を自動化する道具だからこそ、止める線を先に引く。 大規模言語モデルの自由記述から「自信がなさそうだ」を読み取るより、数字が返ってくるほうがはるかに扱いやすいはずです。

発表後の実装が示していること

Jevの発表から数日で公開された実装のうち、ロボティクスに読み替えられるものを4つ挙げます。いずれも投稿者の条件での報告値です。

毎秒10回の判断が回る。 TypeSafe AI自身の発表デモは、ゲームDoomの状態を構造化テキストにして送り、次の行動を返させるものでした。公式ブログによれば毎秒およそ10回の問い合わせで、費用は1時間あたり約7ドル。入力は画像ではなく構造化データであること、そして「AIを使わない従来型のボットのほうが上手に遊べる場合がある」ことを、公式が自分で書いています¹³。この留保の付け方は信用できると思いました。毎秒10回というのは、移動ロボットの行動選択には十分な周期です。

330ミリ秒ごとの連続判断が途切れない。 atomic.chatのチームは、ロケットが降り注ぐ盤面で安全なマスを330ミリ秒ごとに選ばせ、26回中25回生き残ったと報告しています¹⁴。1回の判断が単純でも、それを秒間3回、途切れずに続けられるかは別の問題です。監視から回避へつなぐ動きに近い。

即応と計画を別のモデルに分ける。 Wuyang Zhou氏は、JevとOpenAIのGPT-6 Astraを組み合わせてMinecraftを動かしました。本人の説明では、突発的な出来事にはJevが即座に反応し、大きな目標はAstraが先を読んで計画する、という分担です¹⁵。これがロボティクスでの本命の形だと私は考えています。タスク計画は大規模モデル、行動選択はJev、動作生成はVLAか従来の制御。層ごとに違う道具を置く。

毎秒4回で経路を選ぶ。 ブラウザ上の運転シミュレータで、道路の境界や周囲の車、信号の情報を表にして渡し、候補の進路から1つを選ばせる実装がありました。判断は曲がり角や交通のある場面で毎秒最大4回。衝突回避の緊急ブレーキは別の仕組みの担当です¹⁶。実車ではなく、安全性を示したものでもありません。ただし緊急停止を別系統に置いている点は、設計として正しい。

いま、この層に何を置いているか

Jevが入る場所をはっきりさせるために、いま現場がその層に何を置いているかを並べます。だいたい3通りです。

1つ目は、条件分岐で全部書く。 いちばん多い形です。速いし、動きが完全に読めるし、検証もできる。問題は、想定していなかった状況が来たときに何もできないことと、条件が増えるほど誰も触れなくなることです。現場が変わるたびに分岐が増え、3年もすると「このifは誰が入れたか分からないが消すと止まる」という塊になります。

2つ目は、大規模言語モデルを置く。 2024年以降、タスク計画の層には実際に入ってきました。融通は利きますが、行動選択の層に置くと2つの理由で苦しくなります。返事を書くので遅い。そして自由記述で返るので、プログラム側で解析する工程が要り、そこが壊れる。「掴むべきでしょう」と返ってきたときに、これをgraspに変換する処理を誰かが書いて保守することになります。

3つ目は、学習でまるごと置き換える。 VLAの方向です。うまくいけば強いですが、行動選択だけを差し替えたいときにも学習のサイクルが要り、「今日から人が近づいたら待つようにしたい」のような変更に即応できません。

Jevはこの3つの間に入ります。分岐のように速く、言語モデルのように融通が利き、学習を回さずに質問文だけで変えられる。 その代わり、動作は作れないし、画像も見ません。できることを絞ったぶん、置き場所がはっきりしています。

費用の桁を確かめておく

ロボットは止まらずに動き続けるので、1回いくらより「1日いくら」で見ないと判断できません。計算しておきます。

公式のDoomデモが毎秒約10回で1時間あたり約7ドルです¹³。これは判断のたびにゲームの状態を丸ごと送っている場合の数字なので、産業用の用途ではもっと安くなります。行動選択の層は毎秒10回も要らないことが多く、たとえば毎秒2回、1日8時間なら57,600回。1回の状態が500文字程度なら、料金表から計算しておよそ0.3ドルです⁴。1台1日あたり数十円。

これが効くのは、費用を理由に判断を省かなくなることです。「毎回全部確認すると遅くて高いから、3回に1回にしよう」という妥協が要らなくなる。質問を並列に投げても待ち時間が変わらない性質と合わせると、確かめたいことを全部、毎回確かめるという設計が現実的になります。ロボットの安全と品質にとって、これは小さくない変化だと思います。

なお、ここで安くなるのは判断だけです。カメラ、物体検出、OCR、点群処理といった知覚側の計算コストは別に乗ります。総額で見てください。

ロボットに組み込むときの設計図

具体的に書きます。層を4つに分けます。

知覚層。 カメラ、深度センサ、力覚、エンコーダ。ここはJevの管轄外です。物体検出、姿勢推定、OCR、点群処理。出力は構造化テキストにします。たとえばこうです。

対象: ボルトM6 / 位置 (x=0.42, y=-0.11, z=0.08) / 姿勢 傾き12度
把持範囲: 内
周囲の人: 1名 距離1.8m 接近中
直前の試行: 2回失敗（滑り）
バッテリ: 41%
経過: 予定より 38 秒 超過

Jevに渡すのはこの文字列です。画像は渡せませんし、渡す必要もありません。

判断層。 ここがJevです。上の状態に対して、質問を束にして投げます。

action   : Choice「次にどれを実行するか」
           grasp / reposition / wait_for_human / call_operator / abort
stable   : Noul「対象物の姿勢は把持に十分安定している」
human    : Noul「人が作業範囲に入ろうとしている」
repeat   : Noul「直前と同じ原因で失敗を繰り返している」
urgency  : Score「この状況の切迫度」3段階

返ってくるのは選択と確率と確信度です。組み合わせて最終的にどう動くかを決めるのは、Jevではなくコード側です。たとえば「humanが0.6を超えたらactionが何であってもwait」「repeatが0.7を超えたら別の把持戦略に切り替える」。しきい値はコードの定数として1か所に置き、変更はコードレビューを通す。公式のクックブックも、判定のしきい値を定数として一元管理する構成を推奨しています¹¹。

実行層。 選ばれた行動に対応する、既存のモーションプランナと制御器を起動します。ここは従来どおりで、Jevは触りません。

安全層。 これは次の節で書きます。上の3層とは独立に置きます。

この構成の良いところは、Jevを外しても動くことです。判断層を固定のルールに置き換えれば、従来のステートマシンに戻る。入れると賢くなり、外しても壊れない。新しい部品を入れるときの条件として、これは外せないと思っています。

落とし穴を4つ

画像を渡せない。 繰り返しますが、テキストのみです⁵。「カメラの映像を見て判断してくれる」と期待すると設計が崩れます。知覚は必ず前段に置きます。逆に言えば、知覚の出力を文字にできない設計なら、Jevは使えません。

計算と数え上げが苦手。 公式が弱点を公開していて、文字どおりに解釈すること、計算や数え上げが苦手なこと、日付の大小比較が信頼できないこと、無関係な情報が増えると精度が落ちることが明記されています¹⁷。距離の計算、個数の集計、時間の差分は、全部コード側でやってから数字で渡す。「10個あるか数えて」と聞いてはいけません。

型は守るが、正しいとは限らない。 公式サイトは「ハルシネーションしない」と書いていますが、これは型を外れた出力が出ないという意味です。Hacker NewsでもThe Registerでも「有効だが間違った値は出しうる」という指摘が出ています¹⁸。選択肢を守って返せても、選択が正しいとは限らない。だから確率と確信度が付いてくるわけです。

日本語は英語ほど当たらない。 公式ドキュメントが「英語が主要な訓練言語で精度も英語が最も高い。他の言語は扱えるが同等ではなく、自分のコンテンツで試してから使うこと」と書いています⁴。ロボットの状態を日本語で書くなら、自社の実データでしきい値を測ってからにしてください。当社の実測では、真偽の質問なら日本語でも適合率96%に届きましたが、**既定のしきい値0.5は取りこぼしが多く、0.2まで下げてようやく再現率88%**でした⁶。測らないと分かりません。

安全は、独立した系統に置く

ここは強く書きます。Jevを安全機能に使ってはいけません。

非常停止、速度と力の制限、人との距離監視、防護柵とライトカーテンの連動。これらは確率を返すモデルの外側、独立した安全系統で実現するものです。公式のクックブックですら、判定の仕組みについて「これは検査であって、安全の境界ではない」と自分で書いています¹¹。

産業用ロボットの安全規格であるISO 10218は、2025年1月に第1部・第2部が同時に改訂されました。2011年版以来の大きな改訂で、協働ロボットについて別建てだったISO/TS 15066の内容を取り込み、機能安全の要求を明確化し、安全に関わる範囲でのサイバーセキュリティ要求まで入りました。第1部は50ページから95ページに増えています¹⁹。

この流れが意味しているのは、AIを積んだロボットでも、安全の土台は決定論的な仕組みで作るということです。Jevは、その安全系統が確保した動作範囲の内側でしか動かさない。速度を落とす判断をJevにさせてもよいが、速度の上限そのものはJevの外で持つ。人が近づいたときに止める判断をJevにさせてもよいが、最後に止めるのは安全系統。この切り分けを最初に引いておかないと、あとからは引き直せません。

日本の現場に、どう効くか

日本でこの話が効くのは、人手が足りない現場に、判断の分岐が大量に残っているからだと思っています。

完全自動化が難しい工程には、たいてい「毎回ちょっとだけ違う」判断が挟まっています。部品の向きが揃っていない。前の工程のばらつきが残っている。今日は人が多い。こういう分岐を条件分岐で書き切ろうとすると、保守できないコードになります。かといって人を張り付けると、自動化した意味が薄れる。

この「毎回ちょっとだけ違う判断」を、安く、速く、止まれる形で埋める部品が出てきた、というのが今回の発表の意味だと私は読みました。性能競争の話として読むと小さく見えます。文章を書かない、画像も見ない、計算もしない。けれど、フィジカルAIが現場に降りてくる局面では、足りていないのは知覚でも運動でもなく、その間の判断であることが多い。

日本の製造業がフィジカルAIでどう巻き返すかについては、日本のフィジカルAIで別に書きました。あわせて読んでいただけると、この記事の位置づけがはっきりすると思います。Jev自体の使いどころを事例で見たい方は、Jevで一次選別が0.12ドルにに20の実装をまとめています。

自社の現場に判断の分岐がどれだけ残っているか、どこまで機械に任せてどこで人に戻すか。この線引きは技術というより業務設計の仕事です。いまどこまで引けているかを先に測りたい方は、AIリテラシー診断を使ってみてください。

まとめ

ロボットの制御は層に分かれていて、層ごとに入れるべき道具が違います。サーボは決定論的な制御則、動作生成はVLAか従来のプランナ、段取りは大規模言語モデル。そしてその間にある「次にどれをやるか」を選ぶ層に、これまで適した部品がありませんでした。

Jevはそこに収まります。選択肢が有限で、状態を文字にできて、判断を並列に投げたくて、確信度で止まりたい。ロボティクスはこの4つを全部満たします。出力が無料なので、判断のコストは実質消えます。

ただし、画像は渡せない。計算はさせない。そして安全機能には絶対に使わない。この3つを守れるなら、今日から試せる部品です。

TIMEWELLはWARPでAIの導入と人材育成を支援していますが、この領域はAIロボティクスの講座へ発展させていく予定です。現場にロボットを入れる話と、判断をどこまで機械に任せるかの話は、いまや分けて考えられません。自社の工程のどこに判断の分岐があり、どの層にどの道具を置くかを一緒に設計したい方は、WARPの個別相談でお話ししましょう。

参考文献

Footnotes

1. Introducing System One Models and Jev（TypeSafe AI、Diogo Almeida）。System One モデルの定義、応答時間70〜500ms、入力$0.042/100万トークン・出力無料、Doomデモ（毎秒約10回・約$7/時間・入力は画像ではなく構造化データ・従来型ボットのほうが上手に遊べる場合がある旨）は同記事による（筆者訳） ↩ ↩²

2. Diogo Almeida氏の発表投稿（2026年9月15日、米国時間）、TypeSafe AI公式アカウントの投稿（同日）。報道はThe Register（2026年9月16日） ↩

3. Introduction（TypeSafe AI Docs）。Choice・Score・Noul の3種類、返り値（choice / score / probabilities / confidence、noul は0〜1）、1回の呼び出しで混在可、質問は並列に評価される旨は同ページによる ↩ ↩²

4. Models（TypeSafe AI Docs、2026年9月19日取得）。現行 jev-1.13.0、入力 $0.042 / 100万トークン・出力無料、コンテキスト64k、テキスト入力のみ、原文 "English is the primary training language and where accuracy is currently best"、他言語は "handled but not equally well; test on your own content before relying on Jev for a non-English workload"（筆者訳） ↩ ↩² ↩³

5. System One（TypeSafe AI Docs）。原文 "System One models do not write replies, produce code, or generate explanations of their reasoning." および "Jev currently accepts text input only. It evaluates strings, JSON objects, and arrays of text. Images, audio, and video are not supported (yet)."（筆者訳） ↩ ↩² ↩³

6. 当社の実測（2026年9月19日〜20日）。content/columns 配下の日本語コラム1,852本について、1本あたりタイトル・説明・本文冒頭1,600文字を渡し、jev-latest に3問を同時に投げた。所要49秒（並列10）、費用は脚注5の料金表から入力トークン数を見積もった概算で0.12ドル。正解は各記事の frontmatter のカテゴリ。二値の適合率96.4%・再現率87.9%（しきい値0.20）、9分類の一致率36%、既定のしきい値0.5での再現率75.4%はいずれもこの実測による ↩ ↩²

7. OpenVLA（GitHub）、Fine-Tuning Vision-Language-Action Models: Optimizing Speed and Success（arXiv 2502.19645）。OpenVLA の推論が 3〜5Hz、1ステップの行動生成が NVIDIA A100 で 0.33 秒、推奨される制御周波数が 5〜10Hz である旨は同論文による ↩

8. π0: A Vision-Language-Action Flow Model for General Robot Control（Physical Intelligence）、arXiv 2410.24164。最大 50Hz の行動チャンクを扱い、推論時に 50Hz で実行する旨は同論文による ↩

9. OpenVLA-OFT（プロジェクトページ）。並列デコードと行動チャンキングにより 77.9Hz、行動生成が 26 倍速・遅延が 3 分の 1 になった旨は同ページによる ↩

10. Milind S氏の投稿（9月18日）。端末内の画像モデルとOCRで画面を文字にし、1判断あたり約90ミリ秒である旨は本人の報告値 ↩

11. How to build with TypeSafe（TypeSafe AI Docs）、Classifying RAG passages（TypeSafe AI Cookbooks）。原文 "Code handles deterministic work and owns the control flow. The model appears only where the system needs programmable common sense or needs to interpret unstructured data."、しきい値を定数として一元管理する構成、および "Nothing here is a security boundary."（筆者訳） ↩ ↩² ↩³

12. Confidence（TypeSafe AI Docs）。確信度は確率分布から計算される0〜1の値、Noulには付かない、High は自動実行、Medium は慎重に、Low は "Do not act. Route to a human, request clarification, or fall back to a different system."（筆者訳） ↩

13. 脚注1に同じ（Doom デモ）。投稿はDiogo Almeida氏（9月16日） ↩ ↩²

14. atomic.chat の投稿（9月18日）。330ミリ秒ごとの判断、26回中25回生存、費用1セント未満はいずれも本人の報告値 ↩

15. Wuyang Zhou氏の投稿（9月18日） ↩

16. Justin Schroeder氏の投稿（9月17日）、リポジトリ。ブラウザ上の運転シミュレータで、毎秒最大4回の判断、緊急ブレーキは別の仕組みが担当する旨は同リポジトリの説明による。実車ではなく、安全性を示したものではない ↩

17. Jev 1.13 jaggedness（TypeSafe AI Docs）。文字どおりの解釈、計算・数え上げ・日付比較の弱さ、無関係な情報で精度が落ちる旨は同ページによる ↩

18. Introducing System One Models and Jev（Hacker News、2026年9月）。「型は守るが有効で誤った値は出しうる」との指摘は同スレッドによる。同旨の留保はThe Register（2026年9月16日）にもある ↩

19. ISO 10218-1:2025（ISO）、ISO 10218-2:2025（ISO）、Updated ISO 10218 FAQ（Association for Advancing Automation）。2025年1月に第1部・第2部が同時に発行され、2011年版以来の大改訂であること、ISO/TS 15066 の内容を取り込んだこと、機能安全の明確化とサイバーセキュリティ要求の追加、第1部が50ページから95ページに増えたことは同資料による ↩