Claude Media
ClaudeとCourtListenerを連携する方法 — 米国判例検索と引用チェック
ClaudeClaude連携MCPチュートリアル

ClaudeとCourtListenerを連携する方法 — 米国判例検索と引用チェック

CourtListenerのMCPサーバーをClaudeにつなぐ手順です。ディレクトリ経由とカスタムコネクタの違い、検索・引用解析・アラートのツール、API tokenの扱いをまとめます。

読了目安 約9分

Claude CourtListener連携で何ができるか

CourtListener連携は、米国の裁判例や訴訟記録を集めた無料の法情報サービスCourtListenerを、Claudeの会話から検索するための接続です。運営は非営利団体のFree Law Projectで、接続先のMCPサーバーも同団体がホストしています。

対象になるデータは、連邦・州の裁判所の意見書、PACERの訴訟記録、判事のプロフィール、口頭弁論の音声、引用関係です。ディレクトリの詳細ページでは、判例の検索、引用の抽出と照合、新しい意見書や訴訟の更新を知らせるアラートの設定が紹介されています。

読者として想定されるのは、米国法を調べる弁護士や研究者、ジャーナリスト、日本企業の法務担当です。日本法の調査には使えません。

接続先のURLは https://mcp.courtlistener.com/ です。サインインは必須で、CourtListenerのアカウントを使います。

ほかの法務系コネクタとの違いは、データの出どころにあります。Harveyとの連携はVaultの文書、Juroとの連携は自社の契約データが対象です。CourtListenerは公開されている判例と訴訟記録を引く側にあたります。コネクタ全般の仕組みはClaudeのコネクタ解説にまとめています。

接続前に必要なもの

必要なのは2つです。

  1. CourtListenerの無料アカウント(個人は無料。利用規約に従います)
  2. Streamable HTTPとOAuth 2.0に対応したMCPクライアント

提供元のREADMEは、Claude.ai・Claude Desktop・Claude Code・Cursorで動作を試していると書いています。別途APIトークンを取る必要はありません。OAuthのサインインを通せないクライアントに限って、トークンを渡す方法が用意されています。

接続の入口は2つある

同じサーバーに、2つの経路でつなげます。

経路向く人手順の要点
コネクタのディレクトリ向く人通常のClaude.ai・Desktop利用者手順の要点詳細ページの「Add to Claude」から追加する
カスタムコネクタ向く人ディレクトリを経由したくない人手順の要点名前とURLを手入力する

ディレクトリの詳細ページは、開発元がFree Law Projectで、「Anthropic verified」の表示が付き、追加時期が2026年5月だと示しています。カテゴリはLegalとProductivityです。

カスタムコネクタの手順はREADMEにあります。Claude.aiとClaude Desktopのどちらも、設定のConnectorsから進みます。

手順

カスタムコネクタでCourtListenerを追加する

  1. 1

    Add custom connectorを選ぶ

    SettingsのConnectorsを開き、「Add custom connector」を押します。

  2. 2

    名前とURLを入れる

    Nameに CourtListener、URLに https://mcp.courtlistener.com/ を入力します。

  3. 3

    AddしてConnectを押す

    追加後にConnectを押すと、ブラウザーでサインイン画面が開きます。

  4. 4

    権限を承認する

    CourtListenerのアカウントでサインインし、求められる openid と api の権限を承認します。

承認を終えたら、新しいチャットを開きます。CourtListenerのツールが使える状態になっています。

Claude Codeでつなぐ

Claude Codeでは、1行でHTTPサーバーとして登録できます。

claude mcp add --transport http courtlistener \
  https://mcp.courtlistener.com/

登録しただけではサインインは始まりません。READMEによると、初めてCourtListenerのツールを呼んだときにブラウザーが開き、OAuthの流れが走ります。接続の状態は、セッション内の /mcp で見られます。

認証をコマンドラインから操作したいときは、claude mcp login/logoutの手順が参考になります。

14のツールをどう使い分けるか

ディレクトリの詳細ページには14のツールが並びます。役割で分けると次のとおりです。

ツール

CourtListenerのツールを役割で分ける

  • 探す・取り出す

    search は判例・訴訟記録・判事・口頭弁論を検索します。get_endpoint_item はIDで1件を取り、get_more_results は続きのページを返します。get_counts は件数を取ります。

  • REST APIを直接呼ぶ

    call_endpoint は任意のエンドポイントを呼びます。get_endpoint_schema で絞り込み条件と返却項目を調べ、get_choices で裁判所IDなど長い選択肢の一覧を取ります。

  • 引用を解析する

    extract_citations は文章から引用を抜き出します。analyze_citations は抜き出した事件の引用をデータベースと照合し、resume_citation_analysis は上限を超えた分を続けます。

  • アカウントの状態を変える

    create_search_alert と delete_search_alert は検索アラートの作成と削除です。subscribe_to_docket_alert と unsubscribe_from_docket_alert は訴訟記録の更新通知を購読・解除します。

検索と閲覧のツールは、サインインしていれば使えます。アラート系の4つだけは、CourtListener側のアカウント設定を書き換えます。READMEは、クライアントが実行前に確認を出すべきだとして、出ない場合はCourtListenerのプロフィールのアラート画面で管理するよう案内しています。

一覧の数が資料で食い違う

READMEの「Available tools」節にはもう1つ、get_api_usage が載っています。利用上限の残り、直近14日の日別リクエスト数、会員区分を見るツールです。ディレクトリの14のツールには含まれていません。READMEの表を数えると15になります。

どちらかが誤りとは言い切れません。ディレクトリの一覧が古いだけかもしれず、手元のClaudeに実際に出るツールは、接続後のツール一覧で確かめるのが確実です。get_api_usage が見当たらなくても、接続の不具合とは限りません。

引用チェックで見ておく点

法務で使い道が大きいのは、書面から引用を拾って照合する流れです。READMEの例には「準備書面から引用をすべて抜き出し、まだ有効な法理か教えて」という趣旨のプロンプトが載っています。

extract_citations は、事件の引用に加えて条文、id.、supra、短縮引用も拾います。処理はサーバー内だけで完結し、APIの呼び出しも回数制限もありません。

analyze_citations は、重複を除いた事件の引用をCourtListenerのデータベースと照合します。返るのは正式な事件名、裁判所、日付と、good・bad・ambiguous のいずれかの状態です。1回に照合できるのは約250件までで、超えると job_id が返り、resume_citation_analysis で続きを処理します。

READMEが述べているのは、引用がデータベースにあるかどうかの照合です。判例が後の判決で覆されていないかまでを保証する説明は、READMEの該当箇所にありません。「有効な法理か」の最終判断は、別の法律データベースか専門家の確認と組み合わせて考えるほうが安全です。

Claude Codeで調査の約束事を固定する

判例調査では、モデルが引用をそれらしく補ってしまう失敗が怖い点です。ツールの結果だけを根拠にするよう、プロジェクトの CLAUDE.md に規約を書いておく方法があります。次は一例です。

## 判例調査のルール
- 判例の引用は、CourtListenerのツールで取得した結果だけを根拠にする
- 取得できなかった引用は「未確認」と明記し、事件名を推測で補わない
- 引用ごとに、裁判所・日付・CourtListenerのIDを併記する
- analyze_citationsの状態が ambiguous の引用は、別途人が確認する

検索で返った件数が多いときは、get_more_results で続きを取らせ、件数が必要なら get_counts を使わせます。READMEによると、get_counts は一部のクエリで件数を遅れて計算するためのツールです。

認証の仕組みとAPI tokenの扱い

通常の接続はOAuthで、スコープは openid、api、wiki、email、profile です。サーバーは自分でトークンを発行し、CourtListener側のトークンは暗号化して保持します。READMEは、利用者の認証情報を保存せず、呼び出しのたびにREST APIへ転送すると説明しています。

ブラウザーでOAuthを通せない環境では、プロフィール設定で発行できるAPI tokenを使う方法があります。

  • ヘッダーは Authorization: Token <トークン> の形で送る。Bearer で送ると401になる
  • トークンはアカウントのAPI権限を丸ごと持つ。アラート系ツールも含むので、パスワードと同じ扱いにする
  • ページ送りの状態や引用解析のジョブは、認証方式ごとに別管理になる。OAuthで始めた処理をトークン側で続けることはできない

つまずいたときの切り分け

切り分け

CourtListenerにつながらないときの順序

  1. Qサインイン画面が開いたあと、元の画面に戻ってくるか?
    答えがいいえのとき

    READMEは、動的クライアント登録に対応したクライアントが必要だと述べています。古い版のクライアントは更新します。

    答えがはい
  2. QOAuthのエラーに client_id の文言が出ていないか?
    答えが出ている

    クライアントが古い認証情報を覚えている可能性があります。コネクタを削除して、追加し直します。

    答えがはい

検索が空のときの確認

search はcourtlistener.comの検索と同じエンジンに対応します。同じ語句をWebの検索画面で試すと、クエリの問題かMCPの問題かが分かります。

ツールが認可エラーを返す場合は、セッションの途中でトークンが失効した可能性があります。クライアントが自動更新しなければ、コネクタを切断して接続し直します。サーバーの状態は https://mcp.courtlistener.com/health で見られます。

使う前に知っておくこと

返却は1回あたり最大100件で、既定は20件です。レート制限はCourtListenerのAPI制限に従い、具体的な数値はREADMEに載っていません。

保持される情報にも触れておきます。READMEによると、ページ送りのカーソルと引用解析のジョブはRedisに保存され、1時間操作がないと消えます。ツールの入出力そのものは保存されません。

依頼文に機密性の高い事案の内容を入れる場合は、CourtListenerのプライバシーポリシーと自社の情報管理規程を合わせて見てください。ディレクトリのページ自体も、信頼できる開発元のコネクタだけを使うよう注意を出しています。

まとめ

CourtListener連携の価値は、判例の検索よりも、引用を機械的に拾って照合する部分にあります。ただし照合が示すのはデータベース上の有無で、判例の現在の効力ではありません。

ツール数はディレクトリが14、READMEが15と食い違うので、接続後の一覧を基準にします。アラート系の4つだけがアカウント設定を書き換えるため、実行前の確認が出るクライアントで使うのが無難です。

この記事を共有:XはてブLinkedIn

関連する記事

Claude をもっと見る →