Prelintとは?料金・使い方・できることを実際に使って調べてみた動いた
この日に実際に動かした結果です。内容の誤りに気づかれた場合はお問い合わせください。確認のうえ訂正します。
掲載した画面は Prelint のものです。手順の説明に必要な範囲を引用しています。
使う前に分かること
| 登録 | 必要(必須の連携:GitHub) |
|---|---|
| クレジットカード | 要求されなかった 同じものの一覧 |
| 無料で使える範囲 | 登録すると $10 分のクレジットが入る。 くわしく |
| 日本から | 使えた |
| 日本語UI | なし(画面は英語) |
| 確認日 | 2026-09-26(この日に実際に動かした) |
AIにコードを書かせると、ちゃんと動いてテストも通るのに、仕様書に書いてある内容と違うものができあがることがあります。支払いの期限を30日と決めてあるのに60日で作ってしまう、会員だけに見せるはずのページを誰でも見られるようにしてしまう、といったずれです。コードのバグを探すレビューツールは多いですが、仕様書と合っているかまでは見てくれません。
Prelint は、その「仕様書と合っているか」を見るレビューのサービスです。GitHub のリポジトリに入れておくと、プルリクエストが開くたびに、リポジトリの中の仕様書を読んで、仕様と食い違う変更にコメントを付けます。
今回は、小さなタスク管理アプリと日本語の仕様書を非公開のリポジトリに置き、プルリクエストを6本出しました。仕様と食い違う変更が5本、仕様どおりの変更が1本です。どれに何を言うかを見ています。
会議の文字起こしや Notion から決定事項を取り込む機能、AIエージェントから決定事項を問い合わせる MCP サーバーもありますが、今回はリポジトリの仕様書だけで試しています。
GitHubでPrelintに登録する
app.prelint.com を開くと、ログインの画面が出ます。入口は Google・GitHub・メールアドレスの3つです。

プルリクエストを読ませるにはどのみち GitHub を繋ぐので、「Continue with GitHub」で入りました。
入るとすぐに初期設定が始まります。最初の画面は、もうコードがあるか、これから作るかの2択です。リポジトリがあるので「I have existing code」を選びます。

GitHub App を入れて、リポジトリを1つだけ選ぶ
次の画面で「Install GitHub App」を押すと、GitHub の側の画面に移ります。

GitHub の画面では、Prelint をどのリポジトリに入れるかを選びます。最初は「All repositories」(全部のリポジトリ)に印が付いているので、「Only select repositories」に切り替えて、試すリポジトリだけを選びました。許可の中身は、コード・プルリクエスト・チェックなどの読み書きです。プルリクエストにコメントを書き込むためです。

「Install」を押すと Prelint に戻り、最初のプロジェクトに入れるリポジトリを選ぶ画面になります。いま入れたリポジトリに最初から印が付いていて、その下の「Index documentation from the selected repos」(リポジトリの中の文書を読み込む)にも印が付いています。ここが、仕様書を読ませるための設定です。そのまま「Create project」を押しました。

次は、レビューをいつ走らせるかの選択です。

「Automatic」はプルリクエストが開いた時とコミットが足された時に自動で走り、「Tag only」はプルリクエストに @prelint とコメントした時だけ走ります。Automatic の説明には、レビュー1回ごとにクレジットを1つ使うこと、横に付く「判断のレビュー」は無料であることが書いてあります。最初から選ばれている Automatic のままにしました。
最後の画面は、お知らせメールを受け取るかどうかです。どちらも印を付けずに「Complete setup」を押すと、ダッシュボードに着きます。ダッシュボードのグラフは、レビューを1回も走らせていない間はぼかした見本が表示されていて、自分のデータではありません。
仕様書を置いて、読み込まれたか確かめる
今回用意したのは、小さなチームで使うタスク管理のWebアプリです。画面で自分の名前を入れて、やることを追加し、完了の印を付けたり、タイトルを直したり、消したりできます。タスクはそれぞれの持ち主のもので、ほかの人のタスクは見えません。中身は、Node.js と Express で書いたサーバーのファイル(server.js)と、画面のファイル(public/index.html)の2つだけです。
このアプリの決まりごとを、リポジトリの docs/spec.md に日本語で書いておきました。形式は決まっておらず、ふつうの Markdown で読み込まれます。中身はこういう書き方で、今回の実験に効くのは太字の所です。
## 一覧
- 自分のタスクだけを出す
- **未完了のタスクを先に、完了したタスクを後ろに**並べる。それぞれの中では新しい順
- **一度に出すのは最大20件**
## 編集
- 編集できるのはタイトルだけ
- **編集できるのは持ち主だけ**
- **完了したタスクはタイトルを編集できない**。直したい時は、いったん未完了に戻す
## 削除
- **削除できるのは持ち主だけ**。ほかの人のタスクは消せない
## このバージョンで作らないもの
- タスクの共有・担当者の割り当て
- 通知(メール・プッシュ)
- タグ・ラベル
ほかに、タイトルは100文字以内、検索は次のバージョンで追加する、といったことも書いてあります。
読み込まれたかどうかは、左の「Brain」から見られます。「Sources」でリポジトリを開くと、spec.md と README.md の横に「tracking」(読み込む対象)と出ていました。

「Browse」に戻ると、仕様書が一文ずつの決定事項に分けられて並んでいました。全部で19件です。日本語の仕様書から、英語の文に直して取り出されています。「削除できるのは持ち主だけ」や「一覧は最大20件」、「作らないもの」の3つも、それぞれ1件の決定事項になっていました。

19件のうち18件は最初から決定済みの扱いで、「仕様は docs/spec.md にある」という1件だけが確認待ちになっていました。これは README から取り出されたものです。確認待ちのものには「Accept」(採用)と「Reject」(却下)のボタンが付きます。
仕様と食い違うプルリクエストを出してみる
ここからがレビューです。仕様書と食い違う変更を種類別に5本、仕様どおりの変更を1本、それぞれ別のプルリクエストにして出しました。どれもコミットは1つです。説明文は、ふつうの開発で書くような理由にしてあります(「タスクが多い人から、一覧に全部出てこないと言われたので」など)。「仕様を変えます」とは書いていません。
| 変えたこと | 仕様書では | |
|---|---|---|
| ① | 一覧に出す件数を50件に増やす | 最大20件 |
| ② | タイトルを200文字まで入れられるようにする | 100文字以内 |
| ③ | 持ち主以外でも削除できるようにする | 削除できるのは持ち主だけ |
| ④ | 完了したタスクもタイトルを直せるようにする | 完了したら編集できない |
| ⑤ | タスクをCSVで書き出すボタンを付ける | どこにも書いていない |
| ⑥ | 一覧で未完了のタスクを先に並べる | 仕様どおり |
①のプルリクエストを開いてから、Prelint のコメントが付くまで1分かかりませんでした。コメントは、プルリクエストを開くときに書いた説明文のすぐ下に、こんな形で付きます(画面は③のものです)。

①で、変更した行に付いたコメントはこれです。
The spec explicitly fixes the task list maximum at 20 items per request (`一度に出すのは最大20件`). Changing `LIST_LIMIT` from 20 to 50 directly contradicts this settled product constraint.
仕様書の日本語の一文をそのまま引いて、20件と決めてあるものを50件にしている、と言っています。コメントは英語です。
コメントは2種類付きます。1つは変更した行に付く指摘で、重さは「Caution」か「Warning」で示されます。クレジットを使うのはこちらです。もう1つは「Decision review」(判断のレビュー)という長めのコメントで、このプルリクエストが決めていることを箇条書きにして、1つずつ賛成・反対を付けます。最後に「Ship it」(出してよい)や「Discuss first」(先に話し合う)のような結論が付きます。
③(持ち主以外でも削除できる)の画面がわかりやすいので、載せておきます(上に載せた画面の下の部分です)。こちらが行への指摘で、持ち主を確かめる処理が消された行に、赤い指摘が付いています。

指摘の中身は、誰でもほかの人のタスクを消せるようになる、仕様書でも決定事項の一覧でも「消せるのは持ち主だけ」と決まっている、説明文の理由(辞めた人のタスクを片付けたい)はその例外として決まっていない、というものです。
次が判断のレビューで、その結論は「Reconsider」(考え直す)でした。理由の中には、タスクの番号は連番なので、番号を順に試せばほかの人のタスクを全部消せてしまう、という指摘も入っていました。

6本の結果を表で見比べる
| 変えたこと | 行への指摘 | 判断のレビューの結論 | |
|---|---|---|---|
| ① | 50件に増やす | Caution:最大20件と食い違う | Discuss first |
| ② | 200文字まで | Caution:100文字以内と食い違う | Discuss first |
| ③ | 誰でも削除できる | Caution:持ち主だけと食い違う | Reconsider |
| ④ | 完了後も編集できる | Caution:完了したら編集できないと食い違う | Discuss first |
| ⑤ | CSVで書き出す | Warning:仕様書にない機能 | Ship with changes |
| ⑥ | 未完了を先に並べる | なし(承認) | Ship it |
仕様と食い違う①〜⑤は、5本とも指摘されました。①〜④の指摘には、どれも仕様書の日本語の一文が引かれています。仕様どおりの⑥には指摘が付かず、Prelint がプルリクエストを承認(Approve)しました。

指摘そのものに間違いは見当たりませんでしたが、読むときに気をつけたい所が2つありました。
行への指摘と判断のレビューで、言うことが揃わないことがある
⑤では、2種類のコメントの結論が異なっていました。なので、行への指摘だけでなく、判断のレビューも読む必要があります。
⑤の私の説明文は「週報に貼るために、CSVで書き出すボタンを付けます」です。行への指摘は Warning で、CSV で書き出す機能は仕様書のどこにも書いていない、仕様書は一覧・作成・編集・切り替え・削除のできることを全部挙げていて、次のバージョンの予定(検索)にも作らないものにも入っていない、というものです。

ところが判断のレビューでは、6つ目の「CSV で書き出す機能を新しく足す」に「Agree」(賛成)が付いていました。結論は「Ship with changes」(直してから出す)で、直してほしい理由は、書き出したファイルの並び順が一覧と違うことと、名前を入れずにボタンを押すと何も起きないことの2つです。仕様書にない機能だという話は、結論に入っていません。このように、行への指摘と判断のレビューで異なる内容を示すことがあるため、両方を読む必要があります。

仕様と関係ない所にも意見が付く
判断のレビューには、仕様との食い違い以外の意見も入ります。どれも行への指摘にはならないので、プルリクエストを止めるほどのものではありませんが、読む量は増えます。
- ①では「50件にしても、51件目からは見えないのは同じ」として、件数を増やすより次のページを見られるようにする案を表にして並べていました
- ②では、画面の「編集」で出る入力欄に文字数の上限がかかっていない、と指摘していました。これは本当で、ただし上限を超えたタイトルはサーバーの側で断られます
- ⑥では、未完了が20件を超えると完了したタスクが一覧に出てこなくなる、という心配を1つ書いたうえで承認しています
課金
ここは実際に払っていません。画面と料金ページの表記です。
Prelint には月額のプランはなく、レビュー1回ごとにクレジットを使う形です。
| 項目 | 料金 |
|---|---|
| 非公開リポジトリのレビュー | 1回 $1 |
| 公開リポジトリのレビュー | 無料 |
| 判断のレビュー(Decision review) | 無料 |
| 登録したときにもらえるクレジット | $10 分 |
同じプルリクエストにコミットを足すと、そのたびにもう1回レビューが走り、$1 かかります。失敗したレビューや、途中で取り消されたレビューは無料です。
レビューが1回終わるごとに $1 ずつ減り、今回の残りは $3 になりました。

気をつけたいのは、その下の「Auto-recharge」(自動の買い足し)です。最初から入っていて、残りが $10 を切ったら $50 分を買い足す設定になっています。今回はカードを登録していないので、何も起きていません。カードを登録するなら、先にこのスイッチと金額を確かめてください。クレジットは $10 から買えます。
ほかの人を紹介して、その人が最初のレビューを走らせると、双方に $20 分のクレジットが入るという仕組みもあるみたいです。
まとめ
日本語で書いた仕様書を置くだけで、数字・入力の上限・権限・状態の食い違いを5本とも仕様書の一文を引いて指摘し、仕様どおりの変更は通しました。
今回の検証はそれぞれ比較的わかりやすい内容であったため、複雑なプロジェクトの場合の正確性は検証できていませんが、AIにコードを書かせていて、仕様書をリポジトリに置いているチームには、プルリクエストの最後の確認として導入を考えてみてもいいかもしれません。個人や規模の小さいチームであれば、そこまで恩恵は受けないと思いますが、仕様がnotionやリポジトリ内の仕様書など、バラバラに散らばっているチームは管理を任せると楽になりそうです。
非公開リポジトリでは1回 $1 かかるので、プルリクエストが多いなら「Tag only」にして、決まりごとに触る変更だけ @prelint で呼ぶのが向いています。