Court Listener

CourtListener — 米国判例法

Free Law Project の CourtListener に収録された米国の裁判所意見書：3,361 の裁判所にわたる 830 万件の意見書を収録し、1761 年までさかのぼります。米国判例法のデータベースとしては、無料で利用できるものの中で最大規模の、構造化されたデータベースです。

Pipeworx の一部です。AI エージェントを 1,875 以上の稼働中のデータソースに接続する MCP ゲートウェイです。独立した非公式の連携であり、上流プロバイダーとは提携・公認・公開関係にありません。

その大部分は州法です。意外に思われるかもしれませんが、重要なのはまさにその点です。

	意見書数	割合
州（最高裁、控訴裁、第一審裁判所）	6,219,869	71%
連邦（SCOTUS 498,145 件を含む）	2,440,856	28%
準州、軍事、部族	86,691	1%

連邦控訴裁判所の判例法は、ほかの場所でも簡単に見つかります。州の意見書 600 万件を集約し、検索できる形で提供している場所はありません。

認証

事件の検索と意見書の本文には不要です。キーも登録もレート制限もありません。

search_opinions と search_dockets は上流サービスでトピックを検索するため、CourtListener のスロットリングの対象です。Free Law Project の無料トークンを使うと解除できます。

find_case_patents は、特許メタデータを付与するために USPTO Open Data Portal のプラットフォームキー（patents パックと同じもの）を任意で使用します。キーの設定がなくても主張されている特許番号は返されますが、タイトルと日付は含まれません。

ツール

ツール	使用する場面
find_case	事件名が分かっている場合（「Roe v. Wade」や「Sullivan」だけでも可）
lookup_citation	判例集の引用表記が分かっている場合（「410 U.S. 113」など）
list_case_opinions	事件が分かっていて、多数意見、同意意見、反対意見を確認したい場合
get_opinion	意見書 ID が分かっていて、全文を取得したい場合
search_opinions	事件名、裁判官、または分類から事件を検索する場合（ミラーを優先。特定の court コードを指定するとライブ検索）
search_dockets	上流サービスで事件記録を検索する場合
list_docket_filings	docket_id が分かっていて、事件記録一覧（提出された書類と提出時期）を確認したい場合
get_docket_filing	document_id が分かっていて、その提出書類と PDF を取得したい場合
search_court_filings	意見書ではなく、申立書、準備書面、命令などの提出書類の本文を検索したい場合
find_case_patents	特許事件から、主張されている特許番号（USPTO メタデータ付き）と被告を 1 回の呼び出しで取得したい場合

訴訟書類を取得する手順は search_dockets → list_docket_filings → get_docket_filing です。すべての提出書類ツールは docket_id をキーとしており、 それを生成するのは search_dockets だけです。PACER の事件番号では解決できません。

find_case_patents — 特許訴訟の相互参照

RECAP のドケット（Free Law Project / CourtListener）を特許メタデータ（米国特許商標庁、Open Data Portal）と照合します。case_name（必要に応じて court も指定）または、search_dockets ですでに判明している docket_id を渡します。

{"case_name": "TurboCode LLC v. Quectel Wireless Solutions", "court": "txed"}

ドケット、事件の表題から読み取った原告と被告、さらにドケット自体の提出書類テキストに記載されたすべての特許番号を返します。各番号には、見つかった提出書類と、その直前にあった正確な表記（例："United States Patent No."）が付随します。USPTO プラットフォームキーが設定されている場合（patents パックで使用するものと同じ PLATFORM_USPTO_KEY）、各番号にタイトル、ステータス、登録日、最初の発明者が付加されます。キーがない場合も番号は返され、理由は metadata_unavailable_reason に示されます。

意図的に範囲を絞った相互参照です。PACER の文書を購入することはありません。 特許番号は、RECAP がすでにインデックス化しているテキストのみから取得します。書記官自身によるドケット記載内容（例：証拠書類が "United States Patent No. 6,813,742" として提出されていれば、購入なしでその記載を直接読み取れます）と、他の誰かがすでに PACER から購入した文書のテキスト抜粋が対象です。未購入の訴状 PDF の中だけで主張されている特許は見つかりません。その場合、応答にはスキャンした提出書類の数と、pdf_available の文書を取得しなかったことが示され、網羅性があるとは主張しません。

抽出は意図的に慎重に行います。特許番号として扱うのは、原文で「Patent」という語の直後に「No./Nos./Number(s)」が続く場合のみです。近くにある提出手数料、受領番号、PageID、添付書類のインデックスなどが、単に数値の近くにある数値というだけで一致することはありません。被告は、CourtListener がインデックス化した事件の表題（認証済みの PACER 当事者一覧ではありません）から取得し、";" または " and " のみで分割します。企業名の接尾辞（「Co., Ltd」、「Inc.,」など）には通常カンマが含まれるため、単一の被告名を分断してしまう裸のカンマでは決して分割しません。「et al.」のある表題は、黙って除外するのではなく、defendants_truncated: true として報告します。

判決意見と提出書類は、それぞれ異なる問いに答えます。判決意見は裁判所が判断したこと、提出書類は当事者が提出したことを示します。

search_opinions は、ミラー経由でもライブ経由でも同じ cases 形式を返します。また、最も引用された事件には、主な判決意見の冒頭部分、判断を示す文言、クエリとの一致箇所を含む excerpt がインラインで含まれるため、「裁判所は何を判断したのか」を検索結果だけで確認できます。全文は get_opinion で取得できます。

通常の手順は find_case → list_case_opinions → get_opinion です。find_case と lookup_citation の結果は引用数の順に並べ替えられます。同じ名称の事件が複数ある場合、後の裁判所が実際に引用している事件が、問い合わせの対象であることがほとんどだからです。「roe wade」では、1973 年の最高裁判決（引用 5,581 件）が、1970 年の地方裁判所の事件（53 件）より上位に返されます。

省略形やコピー＆ペーストされた事件名

名前の照合は、すべてのトークンに一致する必要があります。そのため、コーパスに存在しないトークンが 1 つでもあると、検索全体が失敗します。以前はそのため、コーパスに「Bell Atlantic Corp.」と保存されているのに「atl」が「atlant」に語幹変換されず、Bell Atl. Corp. v. Twombly に対して find_case が何も返さないことがありました。また、引用のひな型まで付いたブリーフからコピーした名前（TABLE OF AUTHORITIES Bowers v. Hardwick）でも、何も返されませんでした。

指定された名前で一致が見つからない場合、find_case は Bluebook の略記、引用のひな型、企業名の接尾辞を削除して、もう一度だけ検索します（展開や推測は行いません。AND 検索では、トークンを削除すると一致範囲が広がるだけです）。この方法で見つかった結果には、次のラベルが付けられます。

{ "matched": "relaxed", "matched_query": "Bell v Twombly", "note": "…" }

matched: "relaxed" の結果は、乱雑な引用に対する最善努力での解決として扱い、返された case_name が意図した事件かどうか確認してください。完全一致の場合、このフィールドは付きません。また、最初の検索で一致する名前なら、クエリは正確に 1 回だけ実行されます。

対応範囲

キー不要： 意見書の全文、事件名、提出日、裁判官、判例としての効力、 引用件数、判例集の引用情報。

上流サービスを使用、リクエスト数制限あり： 全文の トピック 検索と、3つすべての提出書類ツール。 トピックから事件を探す場合、事件名や引用情報から探す場合には起こらない形で 失敗することがあります。

RECAP の提出書類（PACER 文書）— キー不要、検索のみで利用可能。 約970万件の 文書があります。利用できると思われる REST エンドポイントの /recap-documents/ と /docket-entries/ は、どちらも 「認証情報が提供されていません」 と応答します。 /search/?type=rd はトークン不要で、提出書類ツールが使用する経路です。範囲指定は q フィールドのクエリ（q=docket_id:71886217）で行います。パラメーターとして ?docket_id= を渡しても黙って無視され、エラーではなく、全6,170万件の文書 コーパスが返されます。

ユーザーに伝えておくべき注意事項

• PDF がない提出書類も、実際に提出された書類です。 PACER で誰かが料金を支払って PDF を取得するまで PDF は存在しないため、RECAP が保持するドケットの テキスト は、 文書よりもはるかに多くの記録をカバーしています。各提出書類には pdf_available が 設定されています。一般的なドケットでは、ほとんどの項目がメタデータのみです。 PDF がない場合は「まだ誰もこれを購入していない」と解釈してください。「これは提出 されていない」という意味ではありません。
• 提出書類ツールは、限られたリクエスト枠を消費します。 ツールは CourtListener の /search/ にアクセスします。トークンなしの場合、リクエスト数は1日あたり約125件 に制限されます。これは、意見書ミラーが回避を目的としているのと同じ制限です。 RECAP にはミラーがありません。上限に達した場合、ツールは空のドケットを返さず、 上限に達したことを明示します。意見書ツールには影響しません。
• 最新性。 応答には snapshot_date が含まれます。それ以降に提出された意見書は、 上流検索に回されます。
• コーパスの14.2%は、スキャンされた巻の OCR であり、それに応じた読み取り結果に なります。応答には extracted_by_ocr が設定されるため、文字化けがスキャンに起因する ものであり、こちらの処理に起因するものではないことを確認できます。
• date_created は提出日ではありません。 記録が CourtListener に登録された日付です。 1946年の意見書でも、2020年と表示されることがあります。クラスターから結合される date_filed が、裁判所が実際に判断を下した日付です。
• 引用件数は CourtListener のコーパス内での数値であり、重要性を普遍的に示す指標 ではありません。

帰属表示

データは CourtListener / Free Law Project によるもので、Public Domain Mark のもとで 公開されています。Free Law Project がコーパスに資金を提供し、維持管理しています。 このパックがお役に立った場合は、寄付先はこちらです：https://free.law/donate/

find_case_patents の特許メタデータは、米国特許商標庁の Open Data Portal によるものです。 米国政府の著作物であり、パブリックドメインです。

クイックスタート

MCP クライアント（Claude Desktop、Cursor、Windsurf など）に追加します：

{
  "mcpServers": {
    "court-listener": {
      "url": "https://gateway.pipeworx.io/court-listener/mcp"
    }
  }
}

このエンドポイントが実際に提供するもの

https://gateway.pipeworx.io/court-listener/mcp の tools/list は、上の表にあるツールに 加えて、共有 Pipeworx メタツール（ask_pipeworx、discover_tools、search_within、 remember／recall など、ゲートウェイ全体で利用できるツール一式）を返します。 そのため、表示されるツール数はこの表より多くなります。現在、単一パックのエンドポイント には、このパック独自のツールに加えて、およそ30個の共有ツールが表示されます。接続の initialize 応答には正確な適用範囲が記載されており、その日の状況を確認するうえで 最も信頼できる情報です。

これは意図的な仕様であり、偶然の多重化ではありません。メタツールを使うと、パックの 適用範囲外の質問にも、全カタログを横断してルーティングする ask_pipeworx を通じて 回答できます。そのため、2つ目の MCP サーバーを追加する必要はありません。現時点では、 メタツールなしでパックのエンドポイントをマウントする方法はありません。追加のスキーマ によるコンテキスト消費が、ルーティングの利点を上回る場合は、複数のパックエンドポイント ではなく、フルゲートウェイに一度接続してください。

または、Pipeworx のフルゲートウェイに接続すると、このパックだけでなく、すべてのパックの ツールが直接一覧表示されます：

{
  "mcpServers": {
    "pipeworx": {
      "url": "https://gateway.pipeworx.io/mcp"
    }
  }
}

どちらの URL も同じゲートウェイと、同じ1875以上のデータソースに接続します。違いは、 どのパックのツールが直接一覧表示されるかだけです。どちらからでも ask_pipeworx を使って、すべてのツールにアクセスできます。

MCP クライアントがない場合は、HTTP 経由で呼び出せます

curl -X POST https://gateway.pipeworx.io/v1/tools/search_opinions \
  -H 'Content-Type: application/json' \
  -d '{"query":"Air France v. Saks"}'

最初の呼び出しにアカウントは不要です。任意のツールを確認するには、GET https://gateway.pipeworx.io/v1/tools/search_opinions を実行します。ツールを探すには、{"query":"..."} を指定して POST https://gateway.pipeworx.io/v1/tools/search_packs を実行します。

スタンドアロン（ゲートウェイアカウント不要）

このパッケージは、ローカルの stdio MCP サーバーとしても実行できます。Pipeworx アカウントもゲートウェイを経由する必要もありません。

{
  "mcpServers": {
    "court-listener": {
      "command": "npx",
      "args": ["-y", "@pipeworx/mcp-court-listener"]
    }
  }
}

または、直接実行して起動を確認できます。

npx -y @pipeworx/mcp-court-listener

stdin/stdout 経由で MCP を使用し、このパックのツールのみについて initialize／tools/list／tools/call に応答します。上記のゲートウェイ接続で追加される共有メタツールは含まれません。同じソース、同じツールを使用し、ask_pipeworx によるルーティングはありません。

ask_pipeworx を使用する

ツールを直接呼び出す代わりに、自然な英語で質問できます。これは、上記のパックエンドポイントとゲートウェイ全体の両方で機能します。

ask_pipeworx({ question: "your question about Court Listener data" })

ゲートウェイが適切なツールを選び、引数を自動的に入力します。

詳細

• ドキュメントとガイド
• pipeworx.io

ライセンス

MIT