Edinet

edinet — 日本企業の開示書類（EDINET、金融庁）

ステータス：2026-09-16 に BYOK で公開・リリース済み（fleet #1942/#1928）。キー不要の企業検索は認証情報なしですべての呼び出し元が利用できます。2 つの提出書類一覧ツールでは、呼び出し元自身の EDINET Subscription-Key を _apiKey として指定します。プラットフォームキーではなくこの方式でリリースした理由については、以下の「認証」をご覧ください。

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

EDINET は日本の EDGAR です。有価証券報告書、四半期報告書、半期報告書、臨時報告書、大量保有報告書、公開買付け、およびその基盤となる XBRL／PDF／CSV 書類を扱います。

ツール

ツール	キー？	機能
edinet_search_filers	不要	金融庁の公式 EDINET コード一覧（提出者約 11,400 社）から、日本企業を EDINET コードと証券コードに解決します。日本語名、英語名、かな、EDINET コード、ティッカーで検索します。
edinet_list_filings	必要	1 日に提出されたすべての書類を取得します。提出者、書類の種類、XBRL のみで絞り込むこともできます。
edinet_company_filings	必要	1 社の提出書類を最長 31 日の期間で、新しい順に取得します。
edinet_financials	必要	企業の有価証券報告書から、主要な年次数値（売上高、営業利益、親会社の所有者に帰属する純利益、総資産、純資産）を、会計期間、会計基準（J-GAAP／IFRS／US GAAP）、提出書類 ID、利益率とともに取得します。

単位、期間、基準（edinet_financials）

• 各数値には、提出書類でタグ付けされたとおりの currency と unit_id が付与され、通貨単位そのままの値で示されます（提出書類における千円・百万円単位の表示上の丸めは、構造化データには含まれません）。換算やスケーリングは行いません。
• 単位が通貨コードでない値、またはテキストが単純な数値でない値は、value: null、unit_status: "unresolved" として返され、提出書類に記載されたテキストが value_as_filed に入ります。
• 年次報告書のみを読み込み、当年度の数値のみを対象とするため、各値は period_start から period_end までの通期の数値です。四半期報告書と半期報告書（累計値）は読み込みません。
• 連結数値を優先し、単体の数値は明示された代替値としてのみ表示します。年次報告書または構造化データがない場合は、空のリストではなく found:false を返します。
• 2026-10-25 時点で実環境では未検証： fleet に Subscription-Key が存在しないため（「認証」を参照）、このツールは合成フィクスチャのみでテスト済みです。実際のキーで初回呼び出しを行う際は、既知の提出書類と照合してください。

2 つのアクセスルール

1. コード一覧はキー不要です。 https://disclosure2dl.edinet-fsa.go.jp/searchdocument/codelist/Edinetcode.zip は金融庁から認証情報なしで提供されます。約 570 KB の ZIP で、Shift_JIS の CSV が 1 つ含まれています。このパックは ZIP を解凍し（DecompressionStream('deflate-raw')）、デコードします（TextDecoder('shift_jis')）。どちらも workerd でサポートされていることを、2026-09-13 にローカルの wrangler dev で確認済みです。 このリポジトリで従来の日本語エンコーディングをデコードするパックはほかにないため、知っておくと役立ちます。
2. API v2 には無料の Subscription-Key が必要です。 呼び出し元が _apiKey として指定します。上流には Subscription-Key クエリパラメーターとして送信されます。

Auth

BYO key. edinet_search_filers needs none. edinet_list_filings and edinet_company_filings require an EDINET API v2 Subscription-Key, which the caller supplies as _apiKey; without one they refuse with the words "requires an API key", so the gateway books the refusal as a gate rather than as a defect of ours.

Pipeworx holds no platform key for EDINET, and that is a decision, not an oversight (fleet #1942, 2026-09-16). Bruce registered an EDINET account — the account exists — but the FSA's own key-issuance page rendered blank on their side, so the account could not yield a key. Rather than hold a finished pack behind a third party's outage, the pack shipped BYOK.

Anyone re-checking this: the thing to look at is the key page behind a logged-in EDINET account, not the pre-auth URL — …/api/auth/index.aspx?mode=1 302s to Azure B2C and answers normally whether or not the page behind the login works, so probing it unauthenticated tells you nothing either way.

If a key is obtained, platformKeyEnv: 'PLATFORM_EDINET_KEY' goes in the manifest in the same change that lands wrangler secret put — declaring it early un-sinks routing and points Japanese-filings questions at tools that can only refuse (the fda-inspections precedent, #617).

Traps

• There is no company-search endpoint. The API lists filings BY DATE and nothing else (documents.json?date=YYYY-MM-DD&type=2). "Toyota's filings" is therefore a walk of the daily lists — one upstream request per day, which is why edinet_company_filings caps its range at 31 days. Resolve the company first with the keyless edinet_search_filers.
• The securities code has five digits. Toyota is 72030 in EDINET and 7203 on the exchange. Both tools accept either and return both (sec_code / ticker).
• Shift_JIS, not UTF-8. Decoding the code list as UTF-8 yields mojibake for every Japanese name, silently — the ASCII columns still parse.
• Individual filers. ~3,200 of the ~11,400 rows are natural persons (大量保有報告書 filers, 提出者種別 starting 個人). Their 所在地 is a home address, so the pack drops location for those rows and keeps it for organisations.
• Annual reports cluster. Most listed Japanese companies close 31 March and file in late June; an empty two-week window is usually the calendar, not a bug.

Why there is no platform key (history)

EDINET API v2 registration is not 法人番号-gated (that was the worry carried over from NTA houjin-bangou — see fleet #1928). It is an Azure AD B2C self-service signup whose form asks for exactly four things:

email · emailed verification code · password · CAPTCHA

Field IDs read live off the signup page, 2026-09-13: email, emailVerificationCode, newPassword, reenterPassword, captchaEntered / challengeString / captchaControlChallengeCode ("ボットを倒すお手伝いをします"). No organisation, no corporate number, no Japanese address — a US individual can register.

The CAPTCHA made registration a human step, so it went to Bruce. He did it — and then EDINET's key-issuance page came back blank (2026-09-16). The pack was promoted BYOK at that point rather than waiting on a vendor website.

What is still outstanding, for whoever picks this up when the page recovers:

1. wrangler secret put PLATFORM_EDINET_KEY on the gateway.
2. Add platformKeyEnv: 'PLATFORM_EDINET_KEY' to the edinet entry in workers/gateway/src/pack-manifest.json, in that same change.
3. Replace the two keyed tool-examples.json entries with calls that actually returned rows. As shipped, edinet:edinet_list_filings and edinet:edinet_company_filings carry argument shapes taken from the FSA's own spec (ESE140206, EDINET API仕様書 Version 2) and from a real EDINET code we resolved live (E02144 = Toyota) — but the calls themselves have never completed, because we have never held a key. Treat those two examples as unverified until someone runs them.

検証済みライブ（キー不要の部分のみ）

2026-09-13、昇格済みパックに対して2026-09-16に再実行：

edinet_search_filers({query:"Toyota", limit:3})   → 6 matches of 11,389 filers
  E02144  7203  トヨタ自動車株式会社 / TOYOTA MOTOR CORPORATION
  E02505  8015  豊田通商株式会社   / TOYOTA TSUSHO CORPORATION
  E00540  3116  トヨタ紡織株式会社 / TOYOTA BOSHOKU CORPORATION
edinet_search_filers({query:"トヨタ自動車"})       → 1 match  (E02144)
edinet_search_filers({query:"7203"})               → 1 match  (E02144)
edinet_search_filers({query:"E02144"})             → 1 match  (E02144)
edinet_search_filers({query:"Mitsubishi UFJ", listed_only:true})
                                                   → E03606 / 8306

edinet_list_filings と edinet_company_filings はキーなしでは拒否し、「requires an API key」という語句を返します。そのため、ゲートウェイはこの拒否をエラーではなくゲートとして記録します。

クイックスタート

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

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

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

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

これは意図的な仕様であり、偶然の多重化ではありません。メタツールを使うことで、このパックでは対応できない質問にも、カタログ全体を横断してルーティングする ask_pipeworx を介して回答できます。別の MCP サーバーを追加する必要はありません。現在、これらのメタツールを含めずにパックのエンドポイントをマウントする方法はありません。追加スキーマによるコンテキスト消費がルーティングの利便性に見合わない場合は、複数のパックエンドポイントではなく、フルゲートウェイに一度だけ接続してください。

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

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

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

MCP クライアントがなくても、HTTP 経由で呼び出せます

curl -X POST https://gateway.pipeworx.io/v1/tools/edinet_search_filers \
  -H 'Content-Type: application/json' \
  -d '{"query":"Toyota"}'

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

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

このパッケージは、ローカルの stdio MCP サーバーとしても実行できます。Pipeworx アカウントも、ゲートウェイへの往復通信も不要です：

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

または、起動を確認するために直接実行します：

npx -y @pipeworx/mcp-edinet

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

ask_pipeworx の使用

ツールを直接呼び出す代わりに、自然な英語で質問できます。これは上記のパックエンドポイントでも、フルゲートウェイでも利用できます：

ask_pipeworx({ question: "your question about Edinet data" })

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

詳細情報

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

ライセンス

MIT