5
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

PR: Disnana
Disnana公式サイト
About Promotions
あなたはもう試した？判断特化AI「Jev」で遊ぼう！
@harupython
in

文章を生成しないAI「Jev」はなぜ速い？日本語で12項目をまとめて判定させてみた

5
Posted at

Jevの記事を書こうとして、QiitaとZennのどちらに投稿するか迷いました。

せっかくなので、記事の企画をJev自身に見せて選んでもらうことにしました。結果は Qiita 92%、Zenn 8%。

01-publishing-platform.png

面白かったのは、投稿先だけでなく、技術的な深さや想定読者など12項目をまとめて日本語で質問できたことです。実行画面には 96ms + 212ms と表示されていました。

05-latency.png

返ってくるのは長い説明文ではなく、選択肢と数値です。「こういう判定をコードの途中に挟めるなら、使い道が結構ありそうだな」と感じました。

今回は、この実行結果を見ながら、Jevの使い方と速さの理由を整理してみます。

Jevは何をするAIなのか

Jevは、TypeSafe AIが2026年9月15日に発表したAIモデルです。同社は、こうしたモデルを System One Model と呼んでいます。1

使い方を大まかに言うと、状況を渡して、あらかじめ用意した質問に答えてもらうモデルです。

たとえば、問い合わせの内容を渡して「担当部署はどこか」を選ばせる。障害の報告を渡して「どの程度深刻か」を評価させる。自然言語を読んで判断しますが、返答の文章やコードは生成しません。2

返ってくるのは3種類の判断

型 聞きたいこと 質問の例 返り値
Choice 決めた候補から1つ選ぶ 公開先はQiitaかZennか 選択結果、候補ごとの確率、Confidence
Score 段階を定義して評価する 技術的にどの程度掘り下げる企画か スコア、段階ごとの確率、Confidence
Noul Yes／Noを判断する この企画には実機検証の予定があるか Yesの確率を表す0〜1の値

ChoiceとScoreには、答えだけでなく確率分布も付いてきます。Noulは「Yesの確率」そのものを返す型で、別のConfidenceフィールドはありません。345

今回試したのは、8つのScoreと4つのChoiceです。Noulは使っていません。

この記事の企画を日本語で渡してみる

Playgroundには、StateとQuestionsの入力欄があります。Stateは判断の材料、Questionsは何を判断してほしいかの定義です。67

2026年9月17日に、モデルをjev-latestにして実行しました。

02-playground.png

Stateには記事の内容と目的を入れる

記事のテーマ、書く予定の内容、読んでほしい人をJSONにまとめました。媒体の特徴も、こちらから短い説明として与えています。

Stateの全文
state.json
{
  "article": {
    "topic": "新しいAIモデルJevについて、実際に使用しながら仕組み、性能、LLMとの違い、向いている用途を解説する技術記事",
    "content": [
      "Jevとは何か",
      "Noul、Choice、Scoreの仕組み",
      "一般的なLLMとの違い",
      "高速な理由",
      "公式ベンチマークの確認",
      "実際にJevを使った検証",
      "Discordのスパム判定への利用例",
      "得意な用途と苦手な用途"
    ],
    "purpose": [
      "日本のエンジニアにJevを知ってもらう",
      "ニュースの紹介だけでなく実際の検証結果を載せる",
      "技術的な仕組みまで掘り下げる",
      "検索から継続的に読まれる記事にする",
      "できるだけ多くの技術者に読んでもらう"
    ],
    "target_readers": [
      "AIやLLMに興味のあるエンジニア",
      "バックエンド開発者",
      "AIをソフトウェアに組み込みたい開発者"
    ]
  },
  "platforms": {
    "qiita": "日本の技術者向け情報共有サービス。実装例、検証、技術解説、トラブルシューティングなどの記事が多い。",
    "zenn": "日本のエンジニア向け技術情報共有サービス。技術解説、開発経験、考察、体系的な記事などが投稿されている。"
  }
}

ここで見せているのは、完成した本文ではなく記事の企画です。以降のスコアも「この企画は何を重視しているか」の評価として読んでください。

Questionsでは、候補と評価基準を決める

公開先を選ばせるChoiceは、次のように定義しました。

{
  "publishing_platform": {
    "type": "choice",
    "instructions": "この記事の内容、目的、技術的な深さ、実装や検証の量、想定読者を総合的に考えて、公開先として最も適している媒体を選んでください。",
    "criteria": {
      "qiita": "Qiita。具体的な技術解説、実装例、検証、トラブルシューティングなど、実務や開発に直接役立つ技術記事との相性が良い。",
      "zenn": "Zenn。技術的な深掘り、設計思想、考察、個人の開発経験を含む記事や、体系的な技術解説との相性が良い。"
    }
  }
}

criteriaのキーが選択肢、値がその説明です。qiitaとzenn以外の公開先を自由に書かせるのではなく、この2つから選ばせています。3

一方、技術的な深さはScoreで聞きました。

{
  "technical_depth": {
    "type": "score",
    "instructions": "この記事はどの程度、技術的な深さを重視した内容ですか？",
    "criteria": [
      "概要やニュース紹介が中心",
      "実装や仕組みをある程度掘り下げる",
      "仕組み、実装、検証まで深く掘り下げる"
    ]
  }
}

こちらのcriteriaは配列で、先頭から0、1、2に対応します。「0〜2で採点して」だけでなく、各段階が何を意味するかを日本語で書く形です。4

Choiceのcriteriaはオブジェクト、Scoreのcriteriaは配列です。選択肢と評価段階で、書き方が異なります。

実行時には、これらを含む12問を1つのJSONに入れました。実用性や記事の種類も、一緒に聞いています。

Questionsの全文（Score 8問・Choice 4問）
questions.json
{
  "technical_depth": {
    "type": "score",
    "instructions": "この記事はどの程度、技術的な深さを重視した内容ですか？",
    "criteria": [
      "概要やニュース紹介が中心",
      "実装や仕組みをある程度掘り下げる",
      "仕組み、実装、検証まで深く掘り下げる"
    ]
  },
  "practicality": {
    "type": "score",
    "instructions": "この記事はどの程度、実用的な実装や検証を重視していますか？",
    "criteria": [
      "概念やニュース紹介が中心で、実用的な検証は少ない",
      "概念説明と実用的な検証をどちらも含む",
      "実際の利用例や検証を強く重視する"
    ]
  },
  "analysis_depth": {
    "type": "score",
    "instructions": "この記事はどの程度、技術的な考察や分析を重視していますか？",
    "criteria": [
      "事実や機能の紹介が中心",
      "事実紹介に加えて一定の考察を含む",
      "仕組みや性能の理由まで深く分析する"
    ]
  },
  "implementation_focus": {
    "type": "score",
    "instructions": "この記事はどの程度、実装や具体的な使い方を重視していますか？",
    "criteria": [
      "実装要素はほとんどない",
      "一部に実装例や利用例を含む",
      "実装や利用例が記事の重要な要素になっている"
    ]
  },
  "novelty": {
    "type": "score",
    "instructions": "この記事はどの程度、新しい技術や新しい情報を扱っていますか？",
    "criteria": [
      "広く知られた既存技術が中心",
      "比較的新しい技術や情報を含む",
      "登場したばかりの新しい技術や情報が中心"
    ]
  },
  "search_value": {
    "type": "score",
    "instructions": "この記事はどの程度、検索から継続的に読まれる価値がありますか？",
    "criteria": [
      "一時的なニュース性が中心",
      "一定期間は参考になる",
      "後から検索しても技術資料として参考になりやすい"
    ]
  },
  "beginner_accessibility": {
    "type": "score",
    "instructions": "この記事はどの程度、Jevを知らない読者にも理解しやすい内容ですか？",
    "criteria": [
      "前提知識が多く、詳しい読者向け",
      "ある程度の技術知識があれば理解できる",
      "Jevを知らない読者でも理解しやすい"
    ]
  },
  "engineer_relevance": {
    "type": "score",
    "instructions": "この記事はどの程度、ソフトウェアエンジニアにとって直接役立つ内容ですか？",
    "criteria": [
      "一般的な読み物としての要素が強い",
      "エンジニアにも参考になる",
      "開発や技術選定に直接参考になる"
    ]
  },
  "article_style": {
    "type": "choice",
    "instructions": "この記事の性質として最も近いものを選んでください。",
    "criteria": {
      "technical_news": "新しい技術やサービスを紹介するニュース・速報寄りの記事",
      "technical_explanation": "技術の仕組みや特徴を整理して解説する記事",
      "hands_on": "実際に使った結果や手順を中心にした検証・ハンズオン記事",
      "technical_analysis": "仕組み、性能、設計思想などを深く考察する技術分析記事"
    }
  },
  "primary_value": {
    "type": "choice",
    "instructions": "この記事が読者に提供する主な価値として最も近いものを選んでください。",
    "criteria": {
      "awareness": "新しい技術の存在や概要を知ること",
      "understanding": "技術の仕組みや特徴を理解すること",
      "practical_use": "実際の開発や導入で使える知識を得ること",
      "evaluation": "その技術がどこまで使えるか、長所や制約を判断する材料を得ること"
    }
  },
  "target_reader": {
    "type": "choice",
    "instructions": "この記事の主な想定読者として最も近いものを選んでください。",
    "criteria": {
      "general_engineers": "幅広いソフトウェアエンジニア",
      "ai_engineers": "AIやLLMを扱うエンジニア",
      "backend_engineers": "バックエンドやシステム設計を担当するエンジニア",
      "technology_enthusiasts": "新しい技術やAIに興味がある技術者"
    }
  },
  "publishing_platform": {
    "type": "choice",
    "instructions": "この記事の内容、目的、技術的な深さ、実装や検証の量、想定読者を総合的に考えて、公開先として最も適している媒体を選んでください。",
    "criteria": {
      "qiita": "Qiita。具体的な技術解説、実装例、検証、トラブルシューティングなど、実務や開発に直接役立つ技術記事との相性が良い。",
      "zenn": "Zenn。技術的な深掘り、設計思想、考察、個人の開発経験を含む記事や、体系的な技術解説との相性が良い。"
    }
  }
}

12項目の結果がまとめて返ってきた

Scoreの結果は次のとおりでした。いずれも、こちらが定義した0〜2の範囲です。

質問 スコア Confidence
技術的な深さ 1.97 / 2 96%
実用性・検証の重視 1.93 / 2 90%
技術的な分析 1.98 / 2 98%
実装・使い方の重視 1.84 / 2 76%
新しい技術を扱う度合い 1.94 / 2 91%
検索から後で参照される価値 1.86 / 2 79%
初めてJevを知る人への分かりやすさ 1.00 / 2 81%
エンジニアへの関連性 1.98 / 2 97%

筆者のPlayground実行結果。数値は画面に表示された値です。

全体としては「技術的に掘り下げ、実際に使って評価する企画」と判定されています。一方、分かりやすさは中間でした。Jevを紹介するつもりで書いた企画でも、ある程度の技術知識が必要な内容に見えるようです。

企画に書いた狙いは拾っているように見えます。ただ、本文の品質や実際の検索流入までは、この入力からは分かりません。特に「検索から後で参照される価値」は、企画の傾向を見る参考値として受け取っています。

「1.97」はどこから出てくるのか

技術的な深さの欄を開くと、各段階の確率も確認できます。

03-score-results.png

技術的な深さは、段階0が0%、段階1が3%、段階2が97%でした。Scoreは段階の番号を確率で重み付けした平均なので、表示された割合で計算すると次のようになります。4

0 × 0.00 + 1 × 0.03 + 2 × 0.97 = 1.97

「2を選んだ」という結果よりも、どのくらい2に寄っているかが分かります。画面の割合は丸められているため、別の項目では手計算と表示値が少しずれる場合があります。

記事の種類は、少し割れた

Choiceの結果も見てみます。

04-choice-results.png

公開先はQiitaが92%でしたが、記事の種類はtechnical_analysisが52%、hands_onが35%、technical_explanationが13%でした。この質問のConfidenceは36%です。

今回の企画には、仕組みの分析と実際の使用例の両方が含まれています。そもそも用意した記事分類が重なっているので、どれか1つに絞りにくいと考える方が自然でしょう。

Confidenceは、モデルが別途「自信があります」と申告した値ではありません。 公式ドキュメントでは、返された確率分布の形から計算する統計量と説明されています。1つの候補に確率が集まれば高くなり、複数に分かれれば低くなります。8

公開先のConfidence 84%も、今回の2択に対する回答分布を要約した値です。投稿後の成功率を表しているわけではありません。

媒体の説明も、私が実験用に簡略化して与えたものです。実際の読者数などを比較した結果ではなく、この説明と企画の組み合わせに対する回答になります。説明の書き方を変えて結果を比べるのも、次に試してみたいところです。

12問は順番に考えているわけではない

結果が縦に並ぶので、「記事を採点して、その点数から投稿先を決めた」と見えますが、実際の仕様は異なります。

同じStateに対して、それぞれの質問を独立に評価します。 publishing_platformも、ほかの質問のスコアを経由せず、Stateから直接判断しています。9

今回の12問のうち4問を抜き出した図。

これなら、必要な評価をまとめて聞き、返ってきた後でコード側が使う項目を選べます。

逆に「最初の判定を見てから、次の判定を変えたい」なら、その依存関係は自分で作ります。たとえば、最初の結果を次のStateに入れてもう一度呼ぶか、スコアの重み付けをコードで計算します。

Questionsを増やすことと、推論の段数を増やすことは別です。公式は質問の追加による応答時間の増加を小さいと説明していますが、入力トークンは増えます。追加した質問が無料になるわけではありません。3

なぜ、こんなに速く返せるのか

Jevは、文字列を生成せず、必要な判断の確率を並列に出す方式です。TypeSafeは、独自のモデルアーキテクチャとparallel samplerを採用したと説明しています。1

一般的な自己回帰LLMでは、JSONを返す場合もトークン列を順に生成します。Jevは、その出力をChoiceやScoreなどに絞っています。

出力処理の概略。

たとえば今回なら、12項目分の説明文を書く必要はありません。各項目の答えと確率が欲しいだけです。ソフトウェアが使う出力を最初からそこに絞ることで、逐次生成の待ち時間を減らせる、という説明には納得しやすいものがあります。

発表資料で説明されているのは、この出力方式と学習方針です。層構成などの詳細までは公開されておらず、内部の実装も気になるところです。

今回の時間表示は96ms + 212ms

画面の表示値を足すと308msです。96msと212msの内訳は未確認で、これはPlaygroundの表示値としての記録になります。

平均やばらつきを測ったベンチマークではありませんが、日本語の企画に対する12項目の評価が、この時間表示でまとめて返ってきたのは印象的でした。

普通のLLMにJSONを返させるのとは何が違う？

ここまで読むと、「Structured Outputsで同じようなJSONを返せばよいのでは？」と思うかもしれません。

実際、型付きの出力を得ること自体は、Jevだけの機能ではありません。 たとえばOpenAIのStructured Outputsは、スキーマに合うトークンに生成候補を制限するconstrained decodingを使います。単にプロンプトに「JSONで返して」と書く方法より、出力形式を強く制約できます。10

違うのは、そこから先です。

観点 自己回帰LLMのStructured Outputs Jev
出力の作り方 スキーマに従うトークン列を生成する 型付きの判断と確率を出力する
自由な文章・コード 文字列フィールドなどで扱える 生成しない
確率の扱い 数値を返させるだけで校正されるわけではない 判断の確率を校正する学習を行う
複数の質問 出力JSONなどにまとめて生成できる 同じStateに対して独立・並列に評価する

出力制約はOpenAIの説明、Jevの性質はTypeSafeの仕様に基づきます。1029

Jevを使いたくなるのは、「説明文はいらないので、判定を速く、繰り返し呼びたい」という処理でしょう。逆に、コードの修正案や回答の理由を文章で欲しい場面では、文章を生成できるモデルが必要です。

RLCDでは、何を学習しているのか

TypeSafeは、学習手法を RLCD（Reinforcement Learning for Calibrated Decisions） と呼んでいます。判断と、その判断に対応する確率を返すための学習です。11

ここでいう「校正された確率」は、たとえば80%と予測した事例を多数集めると、実際にもおおむね80%が正解になる、という統計的な対応を指します。

この性質が十分に得られるなら、確率が低いものだけ別のモデルや人に回す、といった設計がしやすくなります。単に選択肢を1つ返すよりも、自動処理に向いていそうです。

今回の投稿先選びのように客観的な正解を決めにくい例では、校正の良し悪しを測れません。業務に使う際は、その用途の正解付きデータで確かめたいところです。

TerraやSonnet 5と同じくらい判断できる？

TypeSafeが公開している、4つのワークフローの比較がこちらです。

06-official-accuracy-cost.png

出典：TypeSafe AI公式発表。Jevの位置に赤枠が付いた図を掲載。

縦軸は精度、横軸は1ワークフロー当たりのコストで、横軸は対数目盛です。菱形がワークフロー、丸がプロンプトで処理した結果です。

図を見ると、Jev、Terra、Sonnet 5の菱形はいずれも精度約68%の位置にあります。一方で、Jevはコストの低い左側に大きく離れています。

ただ、この「精度」の測り方は見ておきたいところです。

比較しているのは4つの業務ワークフロー

評価対象は、セキュリティインシデントへの対応、エージェントの実行ログの確認、請求書処理、顧客対応です。各モデルを同じワークフローで動かし、参照回答に対して評価しています。12

参照回答は人手で付けた唯一の正解ではなく、GPT-6 AstraとClaude Fable 5.1をhigh thinkingで動かした回答の平均です。比較されるモデルは、各社のデフォルトの推論設定を使っています。12

つまり、この4つの判断ワークフローでは近い位置にいる、という結果です。これをモデル全体の能力比較に広げることはできず、そもそもJevはコード生成を対象にしていません。

193.6倍高速、444.6倍安価という数字

公式トップページには、193.6倍高速、444.6倍安価という数字もあります。13

これは上記のワークフロー評価に由来する値です。TypeSafe自身も、実運用で得られる改善の上限寄りだろうと説明しています。また、ワークフローの作成には同社のモデル開発チームが関わっており、バイアスの可能性にも触れています。1

この差が手元の用途でも出るなら、呼び出す回数の多い処理ほど効果がありそうです。同じ入力と出力条件をそろえた比較も、やってみたくなります。

料金は入力100万トークンで0.042ドル

2026年9月17日に確認した公表料金は、入力100万トークン当たり0.042ドル、出力は無料です。131

仮に1回の課金対象入力が1,000トークンなら、計算上は次のようになります。

1回     : 1,000 / 1,000,000 × $0.042 = $0.000042
10万回  : $0.000042 × 100,000       = $4.20

実際の課金対象トークン数は、APIのusageで確認できます。14

「エラー率0%」でも、判断は間違える

もう1つ、公式発表で目を引くのがこのグラフです。

07-official-tool-errors.png

出典：TypeSafe AI公式発表。

Jevの0%は、出力スキーマへの適合を保証する設計に基づく値です。TypeSafeは、Jevのこの値は実測ではないと明記しています。「判断を一度も間違えない」という意味ではありません。1

今回の例なら、qiitaとzennから選ばせたときに、未定義の投稿先や自由文が返ってこないことと、その選択が目的に合っていることは別です。

他社モデル側の数値はOpenRouter由来で、質問条件は統一されていません。モデル同士の単純な順位比較にも注意が必要です。1

同じ入力を繰り返したら？

呼ぶたびに結果が大きく変わらないことも、コードへ組み込むなら気になる性質です。

公式のParallel questionsの検証では、同じ文書への13問を、まとめて聞く場合と1問ずつ聞く場合でそれぞれ5回実行しています。多くの項目で追跡している値が一致する一方、一部のNoulの確率には小さな変動が報告されています。15

かなり安定した結果が得られる場面はあるものの、すべての入力で数値が完全一致する、とまでは言えません。 画面上の丸められた割合が同じことと、APIの値が全桁一致することも別です。

再現性を確かめる際は、StateとQuestionsに加え、使用したモデルと生の回答も保存して比較するのがよさそうです。今回の画面確認から一歩進めて、APIで調べたい点です。

Pythonから呼ぶなら

Playgroundで定義したStateとQuestionsは、そのままAPIの入力に使えます。公式Python SDKは、辞書での質問定義にも対応しています。16

先ほどのJSONをそれぞれstate.jsonとquestions.jsonとして保存し、同じフォルダーに次のコードを置きます。APIキーは環境変数TYPESAFE_API_KEYで渡します。

python -m pip install typesafe-sdk
run_example.py
import json
import os
from pathlib import Path
from time import perf_counter

from typesafe_sdk import TypeSafeClient


def main() -> None:
    if not os.environ.get("TYPESAFE_API_KEY", "").strip():
        raise SystemExit("環境変数 TYPESAFE_API_KEY を設定してください。")

    base = Path(__file__).resolve().parent
    state = json.loads((base / "state.json").read_text(encoding="utf-8"))
    questions = json.loads((base / "questions.json").read_text(encoding="utf-8"))

    with TypeSafeClient(timeout=30.0) as client:
        start = perf_counter()
        response = client.system_one(
            state=state,
            questions=questions,
            model="jev-latest",
        )
        elapsed_ms = (perf_counter() - start) * 1000

    # 通信やSDK処理を含む時間。モデルだけの推論時間ではありません。
    print(f"経過時間: {elapsed_ms:.1f} ms")
    platform = response.choices["publishing_platform"]
    print("公開先:", platform.choice)
    print("確率:", platform.probabilities)
    print("Confidence:", platform.confidence)
    print("usage:", response.usage)


if __name__ == "__main__":
    main()

上のスクリーンショットはPlaygroundでの結果です。このコードは同じ入力をAPIから試し、通信やSDK処理を含む経過時間を手元で測るためのものです。

返り値を受け取った後は、choiceを分岐に使う、scoreを並べ替えに使う、Confidenceが低いものを確認待ちにする、といった普通のコードに戻れます。

問い合わせなら担当部署を選び、判断しにくいものを人へ回す。検索結果なら候補ごとに関連性を評価する。Discord Botなら、機械的に数えられる投稿頻度はコードで集計し、文脈を見ないと決めにくい部分を質問にする、といった使い方を考えています。

ただ、投稿頻度の上限のように明確なルールで決まる部分まで、AIに置き換える必要はないでしょう。既存の処理のうち、自然言語の解釈で困っているところに挟むのが試しやすそうです。

おわりに

今回の実行では、日本語で書いた記事企画から、8つのScoreと4つのChoiceがまとめて返ってきました。画面の時間表示は96ms + 212ms。文章の続きを待つ感覚とは、少し違いました。

個人的に気になっているのは、チャット画面の外で使う場面です。メッセージの分類や検索候補の評価など、1回の判断は小さくても何度も呼ぶ処理では、この出力の作り方が効いてくるのではないでしょうか。

まずは、既存の処理の1か所で試し、誤判定の傾向と実際の待ち時間を見てみたいです。

ちなみに、この記事の公開先は冒頭のとおりQiitaが92%でした。最終的に投稿するのは自分ですが、今回はその提案に乗ることにしました。

引用元

  1. TypeSafe AI, Introducing System One Models & Jev（2026年9月15日）。発表内容、出力方式、料金、公式評価とその条件。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  2. TypeSafe AI, System One。モデルの対象、出力、できないこと。 ↩ ↩2

  3. TypeSafe AI, Choice。質問形式、返り値、候補の定義、複数質問。 ↩ ↩2 ↩3

  4. TypeSafe AI, Score。段階の定義とスコアの計算。 ↩ ↩2 ↩3

  5. TypeSafe AI, Noul。Yesの確率とConfidenceの扱い。 ↩

  6. TypeSafe AI, State。StateとQuestionsの役割。 ↩

  7. TypeSafe AI, Quick start。PlaygroundとAPIの利用方法。 ↩

  8. TypeSafe AI, Confidence。確率分布からの計算と解釈。 ↩

  9. TypeSafe AI, Introduction。質問の独立・並列評価。 ↩ ↩2

  10. OpenAI, Introducing Structured Outputs in the API。スキーマ制約とconstrained decoding。 ↩ ↩2

  11. TypeSafe AI, AI primer。RLCDと確率の校正。 ↩

  12. TypeSafe AI, Workflow evals。4つのワークフローと参照回答の作り方。 ↩ ↩2

  13. TypeSafe AI, 公式サイト。公表されている速度・価格。 ↩ ↩2

  14. TypeSafe AI, API reference。リクエスト、回答、usage、HTTPエラー。 ↩

  15. TypeSafe AI, Parallel questions。バッチ化と反復時の変動に関する公式実験。 ↩

  16. TypeSafe AI, Python SDK／Questions。SDKの導入と辞書形式の質問。 ↩

5
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
5
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?