Idaho Code

@pipeworx/idaho-code

アイダホ州法（Idaho Code） — 条文番号による現行法文、改正履歴、および公式の章・条の見出しを対象にしたトピック／キーワード検索。legislature.idaho.gov からライブで取得します。

Pipeworx の一部です。AI エージェントを 1881 以上のライブデータソースに接続する MCP ゲートウェイです。これは独立した非公式の統合であり、上流プロバイダーとは提携、承認、公開のいずれの関係もありません。

ツール

• id_statute({citation}) — 条文番号で指定した 1 条の全文（例： "18-4001"、殺人）。公式の見出し、編・章の文脈、およびアイダホ州がほぼすべての条に記載する改正履歴の「History:」行を含みます。
• id_search({query, limit?}) — ライブで提供されている約 20,400 件の条文見出し（およびそれぞれの章の見出し）を対象にしたトピック／キーワード検索です。例は "landlord"、 "concealed weapon permit" です。法文の全文検索ではありません — アイダホ州はキー不要の全文検索 API を公開していません（「データソース」を参照）。

認証

キー不要です。サインアップや利用開始の手続きはありません。

データソース

• https://legislature.idaho.gov/statutesrules/idstat/ — アイダホ州法の編一覧（74 編）。
• https://legislature.idaho.gov/statutesrules/idstat/Title{T}/ — 1 編分の章一覧。各章の公式見出しを含みます。
• https://legislature.idaho.gov/statutesrules/idstat/Title{T}/T{T}CH{C}/ — 1 章分の条文一覧。各条の公式見出しを含みます。
• https://legislature.idaho.gov/statutesrules/idstat/Title{T}/T{T}CH{C}/SECT{T}-{N}/ — 1 条の全文。

4 つとも、WordPress が配信するプレーンな HTML で、キーは不要です。確認できた範囲では、レート制限もありません。

条文番号に章番号は明記されていませんが、計算式で特定できます

アイダホ州では、章番号を書かずに 編番号-条番号（「18-4001」）で条文を引用します。アイダホ州独自の番号付けは厳密な 章番号*100 + 章内の条番号 のブロック方式なので、章を特定できます。この方式は、Title 18 の第 1、5、9、40、83、91 章、および単一章で構成される Titles 4 と 29 の第 1 章でライブ検証済みです。つまり、第 1 章には「18-100」～「18-1xx」、第 40 章には「18-4000」～「18-4099」、第 83 章には「18-8300」～「18-8399」があります。そのため chapter = floor(number / 100) です。id_statute はこの式で直接 URL を組み立てますが、それを鵜呑みにせず、必ず検証します。詳細は src/index.ts のファイルヘッダーにある「検証チェーン」と、引用した条文が存在しないと報告する前に、計算で求めた章の一覧ページを確認する 3 段階のフォールバックを参照してください。誤った章の推測は、found: false として静かに扱うのではなく、明確に調査可能なエラーとして示す必要があります。

正確な 404 — オクラホマ州やテキサス州のように、404 を 200 に見せかけることはありません

ラップトップからの curl と、本番の Cloudflare アカウントにデプロイした使い捨ての wrangler dev --remote Worker の両方からライブ検証済みです（2026-10-07）。どの URL 形式でも、両方の環境で同じステータスとバイト長が返されます。存在しない章や条文には、本物の HTTP 404 が返ります（常に 72,512 バイトの正規の error404 WordPress テンプレートです）。条文が含まれていないのにページの装飾だけが付いた 200 ではありません。以前のオクラホマ州パックのビルドが失敗した原因は、この落とし穴でした（oscn.net は Cloudflare Worker とラップトップに異なる応答を返し、ローカルのスモークテストにはすべて合格していたにもかかわらず、ライブ呼び出しでは毎回 found:false を返しました）。アイダホ州のサイトではそのようなことがないと、両方の方法で確認済みです。

                                            curl (laptop)        wrangler dev --remote (CF edge, prod account)
Title18/T18CH40/SECT18-4001/ (real)        200 / 91,548B         200 / 91,548B
Title18/T18CH40/ (real chapter listing)    200 / 92,122B         200 / 92,122B
Title18/T18CH999/ (bad chapter)            404 / 72,512B         404 / 72,512B
Title18/T18CH40/SECT18-9999/ (gap number)  404 / 72,512B         404 / 72,512B

転送または解析に失敗した場合（404 以外の HTTP エラー、または条文の埋め込み部分を特定できない 200 応答）は、上流のステータスまたは解析失敗の内容を明記したエラーが発生します。found: false として報告されることはありません。found: false が返されるのは、存在しないことを確認済みの条文（直接 URL の推測に対する 404 だけでなく、章自体のライブ一覧で検証済み）のみです。

埋め込み法令の断片

各条ページは、レガシーな Arbortext 生成 HTML エクスポート（独自の <html><head><body>、2010 年代半ばの Arbortext Epic 6.1）を、現在のサイトの WordPress テーマ内にラップしています。法令の本文は、内側の断片にあるトップレベルの <div> ブロックに含まれています。順に、TITLE N 行、タイトル名、CHAPTER C 行、章名、法令本文（1 つ以上の div。複数段落の条では、各サブセクションに <div> が使われます）、次に History: マーカーの div、最後に角括弧で囲まれた改正の引用を含む div が続きます。src/index.ts の parseSectionFragment がこれを抽出します。章と条の両方の見出しレベルを インデックスに含める理由については、scripts/bake-index.mjs のヘッダーに詳しい説明があります。

4 つの機能 — 3 つは利用可能、1 つは利用不可

• 引用による検索 — id_statute。
• トピック／キーワード検索 — 公式の見出しを対象とする id_search（法令本文全体は対象外）。
• 改正／制定履歴 — id_statute の history フィールドに含まれる、アイダホ州独自の「History:」行（例："[18-4001, added 1972, ch. 336, sec. 1, p. 928; am. 1977, ch. 154, sec. 1, p. 390; am. 2002, ch. 330, sec. 1, p. 935.]"）。施行中の条のほぼすべてに記載されています。
• 過去の版（改正前の条文） — 利用不可。legislature.idaho.gov が提供しているのは現行の条文のみです。Session Laws アーカイブ（/statutesrules/sessionlaws/）には、2000 年代までさかのぼる各会期につき 1 冊の PDF が保存されていますが、これらは会期ごとの章番号（例：1 年分をまとめた「Chapters 1 - 162」）で整理されており、法典の引用に使われるタイトル／章番号とは無関係で、条番号でもインデックス化されていません。以前の版を取得するには、history に記載された改正法を探して、各巻を手作業で調べる必要があります。id_statute は、このフィールドを黙って省略するのではなく、すべての応答でその旨を伝えます。

インデックスの再生成

src/id-index-data.ts は、74 のタイトルページと約 1,468 の章一覧ページ（初回に約 20,400 条を取得）から scripts/bake-index.mjs によって生成されます。立法会期後の法典化作業が完了したら、再実行してください。

node scripts/bake-index.mjs > src/id-index-data.ts

引き継がれたタイトル（一部生成）

生成時に出版社のタイトル全体のページを取得できない場合、生成スクリプト（KNOWN_UNAVAILABLE_TITLES）は、該当タイトルが現在も存在するのに削除されてしまわないよう、前回生成時の行を保持します。これらの行に確認日のスタンプが再設定されることはありません。ID_CARRIED_FORWARD には、タイトルごとの最終確認日が記録され、パックのペイロードにもその旨が記載されます。id_search は引き継がれた各行に carried_forward と index_captured_at を設定し、返された行のうち最も古い確認日を data_as_of に設定します（生成日は index_baked_at）。また、carried_forward_note を追加します。このようなタイトル内の条に対する id_statute は、章が存在しないと誤って返す代わりに、同じ注記とともに reason: "publisher_unavailable" を返します。 現在、引き継がれているタイトル：Title 22（最終確認日 2026-10-07）。

クイックスタート

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

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

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

https://gateway.pipeworx.io/idaho-code/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 も、同じゲートウェイと同じ 1881 以上のデータソースに接続します。違いは、どのパックのツールが直接一覧表示されるかだけです。どちらの URL からも、ask_pipeworx を使ってすべてのツールにアクセスできます。

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

curl -X POST https://gateway.pipeworx.io/v1/tools/id_statute \
  -H 'Content-Type: application/json' \
  -d '{"citation":"18-4001"}'

最初の呼び出しにアカウントは必要ありません。ツールの詳細を確認するには、GET https://gateway.pipeworx.io/v1/tools/id_statute を実行します。ツールを検索するには、{"query":"..."} を指定して POST https://gateway.pipeworx.io/v1/tools/search_packs を実行します。

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

このパッケージは、ローカルの stdio MCP サーバーとしても動作します。Pipeworx アカウントも、ゲートウェイとのラウンドトリップも必要ありません。

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

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

npx -y @pipeworx/mcp-idaho-code

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

ask_pipeworx の使用

ツールを直接呼び出す代わりに、平易な英語で質問できます。上記のパックエンドポイントとフルゲートウェイのどちらでも利用できます。

ask_pipeworx({ question: "your question about Idaho Code data" })

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

詳細

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

ライセンス

MIT