こんにちは、株式会社TIMEWELLの濱本です。
先週、自社のコラム1,852本を1本ずつAIに読ませて、「この記事は輸出管理の話か」「読んだ人に合う自社サービスはどれか」を判定させました。かかった時間は49秒。費用は、公式の料金表から計算した概算で0.12ドルです。日本円で20円足らず。これまで「全部見直したいけれど、人手が足りないから無理」と言い続けてきた作業でした。
使ったのは、TypeSafe AIが2026年9月15日（米国時間）に発表した「Jev（ジェブ）」です12。発表直後は「文章を書かないAI」「40倍から200倍速い」という切り口で紹介されていましたし、私も最初はそう受け取りました。実際に自分の手元で回してみて、印象が変わりました。効くのは速さではありません。一次選別の費用が、意思決定の対象にならない額まで落ちることです。
要点を先に置きます。
- Jevは文章を書かず、選択肢・点数・真偽のどれかを確率つきで返します。出力が無料なのは、書く工程が無いからです
- 自社の1,852記事で49秒・0.12ドル。1本あたりおよそ0.00007ドルでした（料金表からの概算）
- 費用が消えると「標本を抜いて調べる」「一度やって終わりにする」という前提が要らなくなります
- ただし日本語は、二値で聞けば適合率96.4%、9分類で当てにいくと36%。しきい値は自社データで測ってから決めるものです
- 画像も音声も渡せません。計算と数え上げも苦手です
以下、速度や費用の数字のうち、開発者が自分の条件で示した報告値は「投稿者の説明では」と分けて書きます。当社の数字は自分で回した実測ですが、費用だけは請求額ではなく料金表からの概算です。
一次選別の費用は、桁が変わった
問い合わせが1件届いたとします。人間向けのチャットAIなら「請求に関するご相談のようですね、担当部署にお繋ぎします」と丁寧に返してくれます。ところが裏で動くプログラムが欲しいのは、この文章ではありません。「請求担当へ回す」という判断と、それがどれくらい確かかという数字だけです。文章で返されると、プログラム側で読み解いて分岐に使える形へ変換し直す工程が要ります。Jevはこの工程を最初から省きました。
渡すのは、状況を表すテキストと、答えてほしい質問です。質問は3種類しかありません。選択肢から1つ選ぶ「Choice」、決めた尺度で段階を付ける「Score」、ある文が真である確率を0から1で返す「Noul」。ChoiceとScoreには各選択肢の確率と確信度が付いてきます。1回の呼び出しに種類の違う質問を何十個も混ぜられて3、しかも並列に評価されるので、質問を増やしても待ち時間はほとんど変わりません。
TypeSafe AIはこれを「System One モデル」と名付けました。心理学者ダニエル・カーネマンが「速い直感の思考」と呼んだSystem 1から取った名前で、公式ドキュメントは「返事を書かず、コードを生成せず、推論の説明も生成しない」と定義しています4。創業者のDiogo Almeida氏はOpenAIでChatGPTの元になった研究に関わった人物で、発表投稿では「RLCD」という訓練法で2年かけて作ったと書いています2。返す確率が現実の当たり外れと釣り合うように鍛える手法です1。
ここまでは仕組みの話で、記事の主役はこの先です。書かないから、出力に課金されません。 料金は入力100万トークンあたり0.042ドルで、出力は無料5。つまり、これまで「1件いくら」で積み上がっていた一次選別のコストが、ほぼ入力の長さだけで決まるようになりました。
実際にいくらだったか
数字を並べます。当社の2件は自分で回した実測、残りは公式と開発者の報告です。
| 何を | 件数 | 費用 | 時間 |
|---|---|---|---|
| 自社コラムの分類（当社・3問同時） | 1,852本 | 0.12ドル | 49秒 |
| 自社コラムのCTA判定（当社・5問同時） | 1,852本 | 0.10ドル | 約2分 |
| コード変更の点検（報告値） | 1,000件 | 0.07ドル | 1件あたり約0.5秒 |
| 判例文の再ランク（公式クックブック） | 1,200回 | 0.0645ドル | 記載なし |
当社の2件は、1本あたり2,000文字ほどを渡して、質問を3つから5つ同時に投げたときの数字です。1本あたりおよそ0.00007ドル。1万本かけても1ドルに届きません。
比較として書いておくと、コード変更の点検を作ったPaolo Rosson氏は「1,000件で7セント、大規模モデルなら約14.50ドル」と投稿しています6。本人の条件での比較なので鵜呑みにはできませんが、2桁の差という感覚は当社の実測ともおおむね合います。
費用がこの水準になると、やるかやらないかを費用で決めなくなります。 これが今回いちばん強く感じたことでした。1,852本の棚卸しは、人がやれば1本1分でも31時間です。外注すれば数万円は下りません。だから何年も後回しになっていました。20円なら、思いついたその場で回せます。
AI駆動開発を、実務で使えるところまで
トレンドを追うだけで終わらせないための実践プログラムがWARPです。元大手DX・データ戦略の専門家が、現場で動かすところまで伴走します。
費用が消えると、設計が変わる
安くなると作業が速く終わる、という話ではありません。設計の前提が3つ変わります。
1つ目は、標本をやめられること。 これまでの分析は「全部は見られないから100件抜いて傾向を見る」でした。全件が現実的な費用で回るなら、抜く理由がありません。当社の棚卸しでも、標本40本で見たときは一致率30%で「使えない」と結論しかけました。全件で見ると、外れているのは特定のカテゴリに固まっていて、原因が分類の側にあると分かりました。標本では見えない構造でした。
2つ目は、一度きりをやめられること。 記事を1本足すたびに全件かけ直しても20円です。判定の条件を変えたくなったときも、質問文を書き換えて回し直せばいい。「前回いつやったか分からない棚卸し表」が、毎回作り直せる出力に変わります。
3つ目は、絞ってから聞くのをやめられること。 質問は並列に評価されるので、増やしても待ち時間がほとんど変わりません。「まず緊急度を聞いて、高いものだけ次を聞く」と段階を組む必要がなく、聞きたいことを全部一度に投げて、組み合わせはコード側で決められます。公式の設計ガイドも「コードが決定的な処理を持ち、制御の流れを握る。モデルは常識的な判断や、構造化されていないデータの解釈が必要なところにだけ現れる」と書き、質問は「できる限り明示的で、狭く、具体的で、原子的に」と勧めています7。
この線引き自体は、Jevに限らず社内のAI活用全般の勘所です。自社の現場がどこまで線を引けているかを先に測りたい方は、AIリテラシー診断を使ってみてください。
一次選別を置き換えた20の使い道
ここからは、発表後の数日で公開された実装と、公式のクックブックから20本を選びました。並べ方は「人が読んで仕分けていた仕事」から始めて、「AIに渡す前に捨てる」「画面と現実を相手にする」「速さが要る実験」と進みます。ゲームや運転の試作も見ましたが、業務の判断に読み替えにくいものは今回落としました。
人が読んで仕分けていた仕事
01｜コード変更を14項目で点検する。 Paolo Rosson氏は、プルリクエスト（コードの変更提案）の差分を貼り付け、1回の問い合わせで14の点検項目を確率で受け取る仕組みを作りました。秘密情報の混入、SQLインジェクション、テストの削除といった項目です。投稿者の説明では1件あたり0.00007ドル、回答は半秒。レビューの質が人と同等だと示したものではありませんが、人が見る前の一次選別としては現実的な数字です6。
02｜投稿を61の観点から一気に採点する。 SuperXを運営するRob Hallam氏は、X向けの下書きに61個の質問を一度に投げ、拡散されそうかを採点する仕組みを作りました。投稿者の説明では61問の回答が約1秒、1投稿あたり0.0004ドル。207人のクリエイターの9,481投稿で調整し、2つの投稿のうち拡散したほうを3回に2回当てるとしています8。質問を増やしても時間が変わらない性質を、いちばん素直に使った例でしょう。
03｜ライブコメントを質問・感想・要望に分ける。 日本の開発者こぎそ氏は、配信中に流れてくるコメントを4つに振り分けるデモを作りました。質問だけ司会者の画面に流す、要望だけ後で集計する、という運用がすぐ思い浮かびます。本人も「アプリやワークフローの小さな判断をAIに任せる使い方に向いてそう」と書いています9。
04｜データベースを文章の意味で絞り込む。 Zachi氏は、PostgreSQLというデータベースに「文章で条件を書ける関数」を足しました。WHERE jev(people, 'could work from home') のように書くと、各行を読んで在宅勤務できそうかを判定します。索引も埋め込みも要らず、投稿者の説明では129行を約1秒、0.0009ドル。JevがSQL文を書くのではなく、SQLの中で行ごとに答えている点が肝です10。
05｜表の列名を書いたら、各行を分類する。 nader dabit氏の予測スプレッドシートは、列の見出しに「Urgency（緊急度）」と打つと、各行の内容を読んで段階を付けていきます。投稿者の説明では1行あたり約100ミリ秒。数式が数値を再計算するように、意味を再計算する表というわけです。ただし緊急の基準は職場ごとに違います。列名だけで任せきらず、段階の定義を揃えるところまでが実用化の仕事になります11。
06｜どのボット、どのモデルに任せるかを選ぶ。 Milind S氏は、届いたタスクを読んで、待機中のボットのうち誰を起こすか、そのボットにどのモデルを与えるかを決める「参謀長」役を作りました。安いモデルで済む仕事に高いモデルを使わない判断を、人がしなくて済みます。公式ドキュメントも「モデルのルーティング」を主要な用途に挙げています1213。
07｜「さっきのPDF」で目的のファイルを探す。 同じdabit氏の予測ランチャーは、ファイル名を覚えていなくても「さっきダウンロードしたPDF」と打てば、それに合う候補を上に出します。従来のランチャーは別名や部分一致、使用頻度で並べますが、ここでは打鍵のたびに意図を読み、投稿者の説明では約100ミリ秒で候補が並び替わります14。
08｜話している内容に合わせてスライドを出す。 Rinte氏のデモは、発表者が話した内容に合うスライドを選んで自動表示します。資料を作るのではなく、用意されたページから選ぶだけ。本人は続く投稿で、会話の受け答えは別の音声対話モデルに任せ、判定だけを切り出したと説明しています。判定を対話モデルにやらせると出力が遅くなる、という理由でした15。
AIに渡す前に捨てる
09｜要約する前に、残す履歴を決める。 tamara氏の「instant compaction」は、「2026年にもなって、なぜコンテキストの圧縮はまだ要約プロンプトなのか」という一文から始まります。セッション内のすべてのツール呼び出しを採点させ、関係ないものを落とすことで圧縮を一瞬で終わらせる発想です16。要約は「書く」作業なので時間がかかり、大事な情報が落ちることもあります。残すか捨てるかを先に決めれば、書く量そのものが減る。この転換が、この記事でいちばん応用が利く考え方だと思っています。
10｜コーディング支援AIへ渡すログを選別する。 中国語圏のアカウント梭哈.AIは、上の仕組みを解説する投稿を出しました。長いコードを書いていると、コンテキストがいっぱいになるたびに要約のために数秒から十数秒止まる。その代わりに、溜まった不要なログを採点して捨てる、という説明です。中国語の解説が発表2日で出ていること自体、広がりの速さを示しています17。
11｜検索で拾った候補を並べ直す。 公式のクックブックに、判例文3,565件を対象にした例があります。まず高速な全文検索で上位30件を拾い、次に「この候補は引用された判例か」という真偽の質問を1件ずつ投げ、返ってきた確率の高い順に並べ直す。40件の検索質問で、1位に正解が来る割合が5%から18%、上位10件に入る割合が38%から62%に上がりました。呼び出しは1,200回で0.0645ドル。ただし「上位30件に入らなかった正解は救えない」と公式自身が限界を明記しています18。検索の網は別に要ります。
12｜メモアプリの検索に足す。 Ian Nuttall氏はメモアプリkeep.mdの検索に組み込み、「再ランクが現行の方式より7倍速く、タグ付けは別の小型モデル比で50倍速く失敗なし」と報告しています19。ObsidianのノートにJevの再ランクを任意で足せるjev-searchのような小さな道具も出ています。事例04と09と11が同じ形だと気づいた方は、この記事の要点を掴んでいます。候補を並べ、1つずつ関係あるかを確率で聞き、しきい値で残す。構造は一つです。
画面と現実を相手にする
13｜フライト検索を約7秒で進める。 ブラウザ操作エージェント「Browser Use」の創業者Gregor Zunic氏が、Google Flightsでチューリッヒからロンドンへの便を探させた例です。投稿では7秒、費用0.0039ドル。ページ上のボタンや入力欄を番号付きの一覧にして、どの操作をどの部品にするかを選ばせます。都市名のような文章の入力が要るときだけ、別の小型言語モデルが担当します。購入まで進めるデモではありません20。
14｜画面を文字にして、クリック先を決める。 Milind S氏の構成は、スクリーンショットをどこにも送りません。Macの中で動く小さな画像モデルが画面上の部品を切り出し、端末内のOCRがラベルを読み、その文字列だけを渡します。部品ごとの確率が返り、いちばん高いものをクリックして、また検出をやり直す。投稿者の説明では1判断あたり約90ミリ秒でした21。画像を扱えないモデルに画面を「見せる」方法として、いまのところ最も素直な答えだと思います。
15｜話しかけてブラウザを操作する。 Moritz Kremb氏は、音声の指示をブラウザ操作につなぎました。話すと文字起こしが送られ、操作先の確率が返り、ブラウザがクリックします。投稿者の説明では判断に約300ミリ秒、1回あたり0.0002ドル。音声認識から画面の反応までを全部足した時間ではない点に注意してください22。
16｜Chrome拡張に判断役を組み込む。 RaZaan氏は、Chrome拡張の中に判断役を置き、エージェントがページを見てクリック先や操作を決める仕組みを公開しました。ブラウザに常駐する形なので、社内の申請画面やSaaSの定型操作をその場で肩代わりさせる用途に近いでしょう23。
17｜iOSシミュレータを操作する。 iOS開発者のcamsoft2000氏は、自作のシミュレータ操作ツールに組み込み、リマインダーの追加のような操作をさせました。画面の部品構造を取り出して短くまとめ、次の操作を決め、実行して「続けるか止めるか」をまた聞く繰り返しです。実機の権限や接続条件まで解決した話ではなく、連携部分は本人によればまだ未公開とのことです24。
速さが要る場面の実験
18｜Doomで短い判断を連続させる。 TypeSafe AI自身の発表デモです。ゲームの状態を文字の構造化データにして送り、次の行動を返させる。公式ブログによれば毎秒およそ10回の問い合わせで、費用は1時間あたり約7ドル。入力は画像ではないこと、そして「AIを使わない従来型のDoomボットのほうが上手に遊べる場合がある」ことを、公式自身が書いています1。売り文句のデモに自分で留保を付けているのは、私は好感を持ちました。
19｜即応と計画を別のモデルに分ける。 Wuyang Zhou氏は、JevとOpenAIのGPT-6 Astraを組み合わせてMinecraftを遊ばせました。本人の説明では、ゾンビの襲来のような出来事にはJevが即座に反応し、ゲームをクリアするといった大きな目標はAstraが先を読んで計画する、という分担です25。事例08と同じ構造で、業務に移すなら「一次対応はJev、込み入った判断は大規模モデル」に読み替えられます。
20｜売買判断を注文処理へつなぐ。 Jarrod Watts氏の「jev-trader」は、通貨ペアの価格情報から買いか売りかを答えさせ、取引所に注文を出すボットです。ブロックが約300ミリ秒ごとに作られる環境に合わせて、その間隔で判断と注文を済ませます。公開リポジトリには、秘密鍵を設定しなければ実注文を出さない設定と、Jevの代わりの模擬モデルがあり、既定は模擬モデルです。利益が出ることを示した事例ではありません26。
安いから雑に使ってよい、ではない
ここまで費用の話をしてきたので、逆側を書きます。当社の1,852本は、精度の実測でもありました。正解として使ったのは、記事に元から付いているカテゴリです。
二値の問い、つまり「この記事は輸出管理・経済安全保障・制裁を主題にしているか」を聞いた場合、しきい値0.20で適合率96.4%、再現率87.9%でした。1,547本の対象外のうち、誤って拾ったのは10本だけです。日本語でこの水準なら、業務の一次選別に十分使えます。
一方、9つの分類から1つを選ばせる形式は36%しか一致しませんでした。この差は大きい。原因を追うと、Jevの誤りというより当方の分類の問題でした。寄せ集めの置き場所になっているカテゴリが1つあって、そこに892本が入っていたのです。多値で当てにいくより、二値を並べてしきい値で決めるほうが、精度も解釈も安定します。 これは公式が「質問は狭く、具体的に、原子的に」と書いていることの、実データでの裏付けだと受け取りました。
しきい値も、勘で決めると損をします。既定の0.5で切ると再現率が75%まで落ちました。0.2まで下げても誤検出は1,547本中10本です。外し方にも癖があって、セキュリティ・クリアランスやスパイ防止法のような「輸出管理の周辺」が0.40から0.49に固まっていました。周辺まで拾いたいかどうかで線を引けます。こういうことは、測らないと分かりません。
公式も弱点を隠していません。文字どおりに解釈すること、計算や数え上げが苦手なこと、日付の大小比較が信頼できないこと、無関係な情報が増えると精度が落ちること27。それから、決められた形式で答えることと判断を間違えないことは別です。公式サイトは「ハルシネーションしない」と書いていますが、これは型を外れた出力が出ないという意味で、Hacker NewsでもThe Registerでも「有効だが間違った値は出しうる」という指摘が出ています28。だから確率と確信度が付いてくるわけで、公式は確信度が高ければ自動で進め、中程度なら慎重に、低ければ「動かさず、人に回すか別の仕組みに落とす」という3段階の運用を勧めています29。
費用についても、1つ補足を。安いのは判定そのものだけです。画面を文字にする処理、音声認識、OCR、検索の網。周辺の費用と手間は別に乗ります。画像を直接渡せない以上、画像を扱いたければ必ず前段が要ります4。総額で見る癖をつけてください。
なお、RAGに組み込む場合の設計は、公式のクックブックが具体的です。検索と生成の間に分類の段を置き、拾った文章1つごとに「主題を扱っているか」「答えに使える情報か」「前提と矛盾しないか」「システムを操ろうとしていないか」の4つを聞く構成があります。最後の1つはプロンプトインジェクションの検出で、しきい値を超えたものは生成モデルに渡さずに落とします30。ここでも公式は「これは検査であって、安全の境界ではない」と釘を刺しています。当社のエンタープライズAI「ZEROCK」はGraphRAGを土台にしていますが、その経験から言えば、検索の精度は手法より「何を渡し、何を捨てるか」の設計で決まることが多く、こうした判定役は素直に収まります。基本はRAGの精度を上げる7つの実践テクニックにまとめてあります。
非エンジニアが持ち帰る3つのこと
コードを書かない人が、ここから何を持ち帰るか。3つに絞ります。
1つ目は、「費用が理由でやめた作業」を思い出すことです。 全件の棚卸し、全問い合わせの再分類、全議事録からの宿題の抽出。どれも「やれたらいいけれど人手がない」で止まっているはずです。20円で回ると分かった瞬間に、判断の前提が変わります。まず自分の部署で、費用を理由に見送った一次選別を3つ書き出してみてください。技術の選定より、この棚卸しのほうが先です。
2つ目は、「何でも判断して」ではなく、二値を並べて渡すことです。 当社の実測がそのまま根拠になります。9分類で36%、二値で96%。「緊急度は？」と聞くのではなく、「顧客は人の対応を求めているか」「過去にも同じ問い合わせがあるか」「金額に言及しているか」と分けて聞き、組み合わせはコード側で決める。この分解は、業務を知っている人にしかできない言語化です。技術者に丸投げできない部分がここにあります。
3つ目は、しきい値と止め方を先に決めることです。 どこで切るかは測って決めるもので、既定値のまま使うと静かに取りこぼします。そして、確信度が低いときに人へ回す運用を公式が勧めているのは、判断を自動化する道具だからこそ止める線を先に引け、という意味だと私は読んでいます29。安いことは、雑に使ってよい理由にはなりません。むしろ安いから、測り直す回数を増やせます。
最後に一つ。Jevの発表は、性能競争の話として読むと小さく見えます。文章を書かない、画像も見ない、計算もしない。けれど、同じ能力の値段が下がり続ける2026年の流れの中で見ると、「判断だけを安く返す部品」が別に用意された意味は小さくありません。自律性とコストの二つの曲線で書いたとおり、これからのAI活用は「どのモデルを使うか」より「どう動かし、何を記録し、誰が止めるか」で差がつきます。自社の業務のどこに判断の分岐があり、どこまで任せてどこで人に戻すかを一緒に設計したい方は、WARPの個別相談でお話ししましょう。
参考文献
Footnotes
-
Introducing System One Models and Jev（TypeSafe AI、Diogo Almeida）。System One モデルの定義、応答時間70〜500ms、40〜200倍の主張、入力$0.042/MTok・出力無料、RLCD、Doomデモ（毎秒約10回・約$7/時間・入力は画像ではなく構造化データ・従来型ボットのほうが上手に遊べる場合がある旨）は同記事による（筆者訳）。ページ表示の日付は2026年9月18日（更新日とみられる）で、発表日は脚注2のとおり9月15日 ↩ ↩2 ↩3
-
Diogo Almeida氏の発表投稿（2026年9月15日、米国時間）、TypeSafe AI公式アカウントの投稿（同日）。「ChatGPTを共同発明した後、2年間ステルスでRLCDという新しい訓練法とJevを作った」旨は前者による（筆者訳）。報道はThe Register（2026年9月16日） ↩ ↩2
-
Introduction（TypeSafe AI Docs）。Choice・Score・Noul の3種類、返り値（choice / score / probabilities / confidence、noul は0〜1）、1回の呼び出しで混在可、"No text generation, no parsing." は同ページによる ↩
-
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)."（筆者訳） ↩ ↩2
-
Models（TypeSafe AI Docs、2026年9月19日取得）。現行 jev-1.13.0、入力 $42 / 10億トークン（$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"（筆者訳） ↩
-
Paolo Rosson氏の投稿（9月17日）。1件0.00007ドル・半秒・「1,000件で7セント、大規模モデルなら約14.50ドル」はいずれも本人の報告値 ↩ ↩2
-
How to build with TypeSafe（TypeSafe AI Docs）。原文 "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." および "Ask the most explicit, narrow, specific, atomic questions you can."（筆者訳） ↩
-
Example use cases（TypeSafe AI Docs）。原文 "Replace or supplement embeddings in RAG pipelines with semantic search, scoring, and ranking"、"Use Jev to build a custom router that chooses which LLM receives each prompt"（筆者訳） ↩
-
Re-ranking（TypeSafe AI Cookbooks）。CLERC の判例文3,565件・40クエリ、BM25上位30件を Noul で並べ替え、Top-1 5%→18%、Top-10 38%→62%、1,200回で $0.0645、原文 "It cannot add a passage that fast search did not select."（筆者訳） ↩
-
Ian Nuttall氏の投稿（9月18日）。7倍・50倍はいずれも本人の条件での報告値 ↩
-
Gregor Zunic氏の投稿（9月17日）、公開リポジトリ。公開リポジトリの説明では読み込みと文字入力を含めて7.1秒 ↩
-
Jev 1.13 jaggedness（TypeSafe AI Docs）。文字どおりの解釈、計算・数え上げ・日付比較の弱さ、無関係な情報で精度が落ちる旨、"jev-1.13 is not trained to generate text." は同ページによる ↩
-
Introducing System One Models and Jev（Hacker News、2026年9月）。2026年9月19日時点で1,890ポイント・495コメント。「型は守るが有効で誤った値は出しうる」との指摘、Almeida氏の応答は同スレッドによる。同旨の留保はThe Register（2026年9月16日）にもある ↩
-
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."、しきい値は一つではなく結果の重さで変える旨は同ページによる（筆者訳） ↩ ↩2
-
Classifying RAG passages（TypeSafe AI Cookbooks）。関連性・回答に使えるか・前提との矛盾・システムの操作の4問、しきい値は定数として一元管理、原文 "Nothing here is a security boundary."（筆者訳） ↩
