Skip to main content
Glama

ラジ株ナビ (Radikabunavi) - Japanese stock data from EDINET/TDnet

Server Details

Japanese stocks from EDINET/TDnet filings: fair-value range, 6-axis score, DCF, earnings, screening

Ownership verified
Status
Healthy
Uptime
85.1% over 27 days
OAuth
Works in Glama
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
ChatGPT
–
Claude
–

TDQS

A4.1/5.0

Scored across 22 tools

Disambiguation3/5

Several clusters overlap: get_stock_analysis duplicates the six individual analysis tools, get_edinet_financial_data embeds the same companyForecast payload as get_earnings_forecast, and screen_stocks vs screen_by_framework plus get_large_holdings / get_major_shareholders_history / get_investor_portfolio all touch shareholder data. The descriptions work hard to draw boundaries (explicit 関連ツール sections, unit warnings) so an agent can resolve most cases, but multiple tools still require reading long guidance before choosing.

Naming Consistency4/5

Almost everything is snake_case verb_noun (get_*, list_*, add/remove/update_*, screen_*, search_*), which is predictable. Minor deviations exist: get_watchlist vs list_edinet_stocks for two listing operations, and mixed get_/other prefixes, but nothing chaotic.

Tool Count4/5

22 tools is on the heavy side but the domain (financials, valuation models, disclosures, shareholders, screening, watchlist) genuinely justifies most of them. A few could be folded (screen_by_framework is a preset over screen_stocks; get_stock_analysis partially substitutes for the individual analysis tools), but nothing looks redundant padding.

Completeness4/5

Coverage is broad and lifecycle-complete: search/name resolution, stock lists, financials, three valuation models, scores, industry benchmarks, forecasts, disclosure feeds, large holdings, shareholder history, customer data, screening, and full watchlist CRUD plus issue reporting. The main gap is real-time/market price data — the server only exposes pseudo prices and asks callers to supply currentPrice themselves, which limits price-based workflows.

Available Tools

22 tools
add_to_watchlist監視リストに追加A
Idempotent
Inspect

監視リストに銘柄を追加します。 監視リストの銘柄は、お気に入り(ポートフォリオ。category: favorite)と監視(category: watching)に分かれます。 お気に入り(ポートフォリオ)は、保有などを自分で管理する銘柄で、株数(shares)と取得単価(acquisitionPrice・円)を任意で持てます。株数を入れれば保有(holding: true)として扱います。メモは付けられません。 「ポートフォリオに入れて」「お気に入りに入れて」という依頼は category: favorite にあたります。 監視は、気になる銘柄です。メモを付けられます。分類を省略すると監視になります。 同じ銘柄をお気に入りと監視の両方に入れられます(その場合は分類ごとに別の項目です)。

例: 「トヨタをお気に入りに100株・取得単価2,850円で入れて」は add_to_watchlist({codes: ['7203'], category: 'favorite', shares: 100, acquisitionPrice: 2850})。 株数・取得単価は1銘柄ずつ指定します(codes が1件のときだけ)。

監視のメモ(note)には、その銘柄で何を気にしているかを書いておけます。 登録した銘柄は get_watchlist で、メモ・登録日・前回確認日と一緒に一覧できます。 その観点で何が起きたかは、get_timely_disclosures / get_large_holdings / get_earnings_forecast などで確認できます。

監視の登録上限: 10銘柄(現在のプラン: free)。お気に入り(ポートフォリオ)は件数の上限がありません。 保存容量(1利用者あたり約900KB)を超える分は rejectedStorageFull に入ります。 上限を超える分は rejectedOverLimit、形式が不正なものは rejectedInvalid に入ります (他の銘柄は登録されます)。rejected は両者の合算です。 同じ分類に既に登録済みの銘柄は duplicated に入り、重複登録はされません(もう一方の分類には入れられます)。

銘柄コードは英字入り(140A 等)も指定できます。全角・.T 付きも自動で正規化します。

※ 本データは情報提供を目的とし、投資助言・推奨ではありません。

NameRequiredDescriptionDefault
noteNoメモ(任意。監視だけ。全銘柄に同じメモが付きます)。300文字を超える分は切り詰めて保存します(master プランは無制限)。
codesYes追加する証券コードの配列(例: ["7203", "6758"])
sharesNo株数(任意。category: favorite のときだけ。正の数)
categoryNo分類(任意)。favorite = お気に入り(ポートフォリオ)、watching = 監視。省略時は watching
acquisitionPriceNo取得単価・円(任意。category: favorite のときだけ。正の数)

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

注釈(readOnlyHint=false, idempotentHint=true, destructiveHint=false)を超えて、監視10銘柄上限・プラン依存、約900KBの保存容量、rejectedStorageFull / rejectedOverLimit / rejectedInvalid / duplicated といった拒否バケットの意味、全角や.T付きコードの正規化、重複登録されない挙動まで開示している。idempotentHint=true とも整合的で矛盾はない。

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

目的・分類・例・上限・拒否バケットと情報量は多いが、ほぼ全てが呼び出し判断に資する。ただし拒否バケットの列挙はやや冗長で、末尾の「投資助言ではありません」免責はツール選択に寄与しない定型文。

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

出力スキーマが無い中で、戻り値に現れる rejected / rejectedStorageFull / rejectedOverLimit / rejectedInvalid / duplicated の意味を説明し、上限・正規化・関連ツール(get_watchlist、get_timely_disclosures 等)まで示しており、この複雑さのツールとして過不足がない。

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

スキーマ記述率100%で各パラメータは既に説明済みだが、記述はさらに「shares / acquisitionPrice は codes が1件のときだけ」「株数を入れると holding: true として扱う」「note は監視だけ・全銘柄に同一メモ」といったスキーマにないクロスパラメータ制約と副作用を補っている。

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

冒頭の「監視リストに銘柄を追加します」で動詞+対象を明示し、続けて favorite(ポートフォリオ)と watching(監視)という2つの分類の意味を説明している。get_watchlist / remove_from_watchlist / update_watchlist_note との役割差も文脈から判別できる。

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

「ポートフォリオに入れて」「お気に入りに入れて」→ category: favorite、「分類を省略すると監視」といった利用条件と具体例を提示しており、いつどちらを使うかは明確。ただし remove_from_watchlist や update_watchlist_note を代替手段として明示的には挙げておらず、排他的な when-not はない。

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_dcf_valuationDCF評価A
Read-only
Inspect

銘柄コードを指定して、DCF(ディスカウント・キャッシュフロー)法による理論企業価値の内訳と 感度分析を取得します。6軸スコアの割安度(valuation軸)の主指標(ウェイト50%)として 内部で使われているDCFモデルと完全同一の計算ロジックを、内訳付きで露出したものです。 株主優待は評価に含めません(優待制度がある銘柄には caveats で知らせます)。

【関連ツール】「○○を分析して」のような総合的な分析には get_stock_analysis が便利です(財務・理想株価・6軸スコア・DCF・業種比較・会社予想を1回でまとめて返します。返したセクションの数ぶん、最大6回分の利用回数を使います)。 このツールは、全年度・内訳・注意事項の全文など、個別の深掘りに向いています。 割安/割高を見る材料は get_edinet_financial_data(財務)・get_ideal_price(理想株価レンジ)・get_stock_score(6軸スコア)・get_dcf_valuation(DCF評価)・get_industry_benchmark(業種比較。codes にその銘柄を渡す)に分かれており、1つだけでは判断材料が偏ることがあります。

【FCFの定義差に注意】本ツールの baseFCF は「営業CF−設備投資−リース債務の返済」です(dcfAvailable=false 時の fcfSeries も同じ定義)。 get_edinet_financial_data が返す fcf は「営業CF+投資CF」(簡易FCF)で、別物の指標です。 投資CFには資産売却・M&A・有価証券の取得等が丸ごと乗るため、事業のキャッシュ創出力を 見るDCFでは前者を使います。両者は同じ「FCF」表記でも値が数倍違うことがあります (実例: 9434 ソフトバンクの2026年3月期は簡易FCF 1,229億円に対し営業CF−設備投資 6,485億円)。 どちらの定義の数字かは項目名で区別できます。

モデル概要(ベースシナリオ): WACC 6.5% / 永続成長率 1.0% / 予測期間5年 / ベースFCF=直近最大5年平均FCF(営業CF-設備投資-リース債務の返済)/ 成長率=売上高3年CAGR×0.5を-5%〜+10%にクランプして適用。 理論企業価値(EV) = 予測期間FCFの現在価値合計 + ターミナルバリューの現在価値(連結=子会社の100%を含む事業価値)。 親会社の株主に帰属する価値(equityValueToParent) = (EV + max(netCash, 0)) × parentShare。 netCash は清原式ネットキャッシュ(現金預金 + 有価証券 + 投資有価証券×0.7 − 有利子負債)。正のときだけ足し、 純有利子負債は引かない(baseFCF は多くの会社で利息の支払い後の営業CFから出しているため、引くと負債のコストを二重に数える)。 parentShare は親会社の株主の取り分 = 1 − 直近5期(親会社帰属が黒字かつ非支配帰属が0以上の期)の非支配帰属の合計 ÷(親会社帰属の合計 + 非支配帰属の合計)。 最新期の親会社帰属が赤字・条件を満たす期が3期未満などで利益の比が使えないときは 非支配株主持分 ÷(自己資本 + 非支配株主持分)で除く。 乖離率(%) = (equityValueToParent / 時価総額 - 1) × 100(正=割安、負=割高)。時価総額・株数は親会社の株主の分なので、比べる相手を揃えている。

返却フィールド:

  • base: ベースシナリオ(WACC6.5%・永続成長率1.0%)の内訳 wacc / terminalGrowth / forecastYears / baseFCF / fcfGrowth / pvForecast / terminalValue / pvTerminal / enterpriseValue / equityValueToParent / equityBridge / gapPercent / currentPrice / currentPriceSource / impliedSharePrice

  • base.equityBridge: EV から equityValueToParent への内訳。netCash(最新期の値)/ netCashAdded(足した額 = max(netCash, 0)。 無い年度は null で netCashUnavailable=true)/ equityValueConsolidated(EV + netCashAdded)/ parentShare・nonControllingShare / parentShareBasis(profit=利益の比 / book_parent_loss(当期の親会社帰属が0以下)・book_nci_loss(当期の非支配帰属が赤字)・book_parent_and_nci_loss(両方)・book_no_parent_profit_field・book_no_profit_field・book_insufficient_profit_periods(利益の比を取れる期が3期未満)=持分の比 / no_nci=非支配なし / unavailable_usgaap・unavailable=除けていない)/ fiscalYearEnd

  • currentPrice: 市場の株価ではなく、最新決算期末時点の擬似株価(有報の PER×EPS 等から復元)。 currentPriceAsOf がその決算期末日、currentPriceAgeMonths / currentPriceFreshness が経過月数と鮮度 (fresh≦3ヶ月 / aging≦6 / stale≦12 / obsolete)。株価が大きく動いた銘柄では乖離率を割り引いて読むこと。

  • currentPriceSource: currentPrice の算出根拠。per_eps=通常のPER×EPS / tsr_backsolved=赤字等でPER×EPSが算出不能な年度に限り、有報の株主総利回り(TSR)5年推移表から 逆算したフォールバック(実測誤差: 赤字等で実際に使われた170社・2026-10時点で中央値0.09%・最大3.4%)/ tsr_backsolved_extended=従来のTSR逆算で値が出ない会社に限り、5年前(TSR表の基準年度)の株価も候補に加え、PER×EPS が無い年度の株価をその年度までのTSR逆算値で1段だけ代替した予備経路(バックテスト誤差: 中央値0.15%・p95 1.89%・10%超0.4%) / per_eps_nonconsolidated=上の3つがどれも出ない会社に限り、有報の提出会社(単体)の PER × 単体の EPS(連結が赤字で連結の PER が空欄の会社など。株価は連結・単体で同じ。連結の PER×EPS との一致度は、両方ある会社で中央値0.08%・p99 1.57%。この経路で値が出る12社では期末の終値との差が10社で0.25%以内、5026は+7.29%・9219は+9.87%(原本の単体 PER 自体が期末とは別の日の株価で計算されているため)。同じ有報の当期の最高・最低株価の範囲内のときだけ使う) / user-provided=擬似株価をどちらの方法でも算出できない銘柄で、currentPrice 引数を渡したときだけ、 その株価で時価総額を組んで計算した(currentPriceAsOf・鮮度は null、gapPercent=gapPercentAtCurrentPrice)。

  • sensitivity: WACC{5.5, 6.5, 8.0}% × 永続成長率{0, 1, 2}% の3×3=9パターンの配列。 各要素は wacc / terminalGrowth / isBase / enterpriseValue / equityValueToParent / gapPercent / impliedSharePrice。

  • impliedSharePrice: 1株理論価格 = 現値 × (1 + gapPercent/100) = equityValueToParent ÷(発行済株式数 − 自己株式数)

  • base.fcfGrowthBasis: 成長率の根拠(売上の始点・終点の年度と値、売上3年CAGR%)。fcfGrowth = CAGR×0.5 を −5%〜+10% にクランプ。売上3年CAGR は最新期と3期前で取り、4期が12か月の決算で1年おきに並ばない・ どちらかの売上が取れていないか0以下なら null(成長率0%)

  • base.fcfSeries: baseFCF の平均に使った年度ごとの営業CF・設備投資・リース返済・FCF(検算用)。 設備投資は CF計算書の有形固定資産+無形資産の取得の支出(売却収入は差し引かない)。CF計算書に投資不動産 (賃貸ビル等)の取得の行があればそれも含み、そう分かった年度は capexIncludesInvestmentProperty=true が付く。付かない年度でも、CF計算書の行が「有形固定資産及び投資不動産の取得」のような会社(2120・2811・5411・9158 等)は投資不動産を含む。無形の取得が「無形資産及びその他の資産」「無形固定資産・投資等」の合算行で書かれた会社(2220・5021・9437)は、その合算額を無形として含む。 不動産業など賃貸物件を積み増す会社では、投資不動産の取得の分だけFCFが小さく出る。

  • currentPrice 引数を渡した場合のみ: base と sensitivity の各要素に gapPercentAtCurrentPrice (渡された株価で計算し直した乖離率)、base に providedCurrentPrice / providedCurrentPriceSource("user-provided")。 gapPercent・currentPrice(擬似株価基準)は変更されません。

  • caveats: モデルの限界に関する注意書き(下記参照)

  • modelFit: 不動産業で棚卸資産(販売用不動産)が総資産の30%以上の分譲型のときだけ付く { fit: false, reason: "real_estate_inventory_heavy", inventoryToAssets }。販売用不動産の仕入れが営業CFに入り 5年平均FCFが大きく振れるため、DCFの理論企業価値・gapPercentは参考にならない(値は変えていない)。 その場合は caveats の先頭に強い注意書きが付く。fcfSeries の符号の推移やBPS・PBR等の別の物差しで見ること。

  • modelInputs: 算出の前提となった事実。fcfYield(%) / negativeFCFYears

  • gapSuppressed / gapSuppressedReason: 金融事業が大きい会社のときだけ付く。このとき gapPercent・impliedSharePrice・sensitivity の乖離率(gapPercentAtCurrentPrice を含む)・modelInputs.fcfYield は null。 対象は (1) 金融業(銀行・保険・証券・その他金融)/ (2) 金融事業のセグメント(販売金融・金融サービス・カード等)の 資産が総資産の30%以上(例: 自動車メーカーの販売金融)/ (3) 割賦売掛金・営業貸付金・リース債権が総資産の30%以上。 このDCFは理論企業価値に正のネットキャッシュだけを足して時価総額と比べ、有利子負債を差し引いていないため、貸出の原資として 多額の負債を持ち営業CFに貸出債権の増減が混ざる会社では、乖離率が判断材料になりません。gapSuppressedReason.type が financial_sector / finance_segment / credit_receivables のどれか、message に理由。EV・baseFCF 等の内訳は参考として返します。 この場合、割安/割高の判断には DCF ではなく PBR・ROE・配当利回り等の別の物差しが向いています。

⚠️ このDCFモデルは全銘柄に当てはまるわけではありません。 実測(933銘柄・2026-09-11)でDCF算出成功597件のうち約27%が、 理論株価がBPSの0.3倍未満または3倍超という極端な値になりました。 データの誤りではなく、5年単純平均FCFが投資サイクルを平滑化しきれない というモデル側の限界です。資本集約型の業種で起きやすくなります。

modelInputs.negativeFCFYears が空でないとき、modelInputs.referenceExcludingNegativeFCFYears に 「FCFマイナスの年を除いた平均で同じ式を計算した参考値」(baseFCF・enterpriseValue・impliedSharePrice)を返し、 caveats にも注記します(base の値は変わりません。マイナスの年を除くのが正しいという意味ではありません)。 modelInputs.fcfYield は判定結果ではなく前提の提示ですが、目安になります。 実測の中央値は 過小側0.89% / 正常群4.63% / 過大側7.05% で、 1%未満だと理論株価がBPSを大きく下回る側に振れやすくなります(精度77.8%)。 ただし過大側の判別材料は未検討で、fcfYield が高いことは異常の証拠になりません。

理論株価だけで「割安」「割高」を結論づけるには限界があり、get_ideal_price・get_stock_score と 突き合わせると判断材料の偏りを減らせます。

注意(caveats):

  • 平均FCFベースのため、一過性項目(特別損益等)の影響を受ける場合があります。

  • 低WACCシナリオ(5.5%)はシクリカル株で理論価値が過大に出やすいため、ベース(6.5%)を 無視して高い数字だけを拾うと過大評価になります。

  • 高WACC上限は8.0%までのため、実態WACCが10%超になる成長株・高リスク銘柄では 全シナリオが割安に見えても過信は禁物です。

  • netCash が無い年度(有利子負債が取れない等)は何も足さず、非支配の取り分を除けない会社(米国基準等)は 100%として計算します。その場合と、純有利子負債を引いていない会社(負債の返済負担が重いと理論価値が高めに出る)は caveats に書きます。

  • baseFCF は直近最大5年の単純平均のため、直近2期のFCFが平均を大きく上回っている (成長途上、または一過性の入金等)企業では直近の実力より小さく出ることがあります (本番実測: 直近2期連続でbaseFCFの1.5倍以上になる銘柄はDCF算出可能銘柄の約1割強)。 該当する場合のみ caveats に注記します。

  • marketCap(時価総額)が算出できない銘柄(PER/EPS/発行済株式数のいずれか欠損)はDCF算出不可です。 ただし擬似株価だけが算出できない(赤字で PER なし・TSR逆算も不成立)場合は、currentPrice 引数を渡せば その株価で算出します(currentPriceSource=user-provided)。

  • 最新期の BPS・EPS が過去の年度と桁違いの株数基準で書かれている会社(splits.json に記録の無い株式併合。 上場廃止後のスクイーズアウト等)は、株数の基準が決められず時価総額を組めないため、currentPrice を渡しても dcfAvailable=false・unavailableReason="share_basis_break"・shareBasisBreak・reason を返します。

  • FCF系列が2年未満、または直近平均FCFが負の銘柄はDCF算出不可です。 この場合エラーではなく dcfAvailable=false と fcfSeries(FCF推移)を返します。 算出できたときは dcfAvailable=true を返します(base・scenarios などが入ります)。 reason で「平均は負だが最新期は黒字」か「構造的にFCF不足」かを区別できます。

  • fcfSeries[].missingReason: freeCashFlow が null の年度の理由(営業CF・設備投資の データ欠損)。業種/業態でDCF対象外の銘柄(reason参照)では、その欠損自体が 評価の可否に影響しない旨を末尾に補記します(欠損の事実は変わりません)。

関連ツール: 財務の詳細は get_edinet_financial_data、理想株価は get_ideal_price、 6軸スコアは get_stock_score。

応答の metricLabels は英語キー→日本語指標名の対訳です。利用者向けには日本語名(例: enterpriseValue→「理論企業価値」)のほうが伝わりやすくなります。 データ品質・値の異常・不具合に触れる場合も同様で、フィールド名を示すときは「発行済株式数(sharesOutstanding)」のように日本語を主・英語キーを括弧内にすると読みやすくなります。

応答の watchlistSuggestion は、この銘柄が利用者の監視リストに未登録のときだけ付く欄で、追加できるか(canAdd)・追加用のツール名(addTool)・監視の件数(watchlistCount)と上限(watchlistLimit。null は上限なし)を持ちます。上限に達しているときは canAdd が false で reason が limit-reached です。

※ 本データは情報提供を目的とし、投資助言・推奨ではありません。

NameRequiredDescriptionDefault
codeYes証券コード(例: 7203)
currentPriceNo省略可。利用者自身が確認した現在の株価。本サービスは株価を提供しないため、利用者が別途調べた値を渡してください。渡した場合、その株価で計算し直したgapPercentAtCurrentPrice を base と sensitivity の各要素に追加で返します(既存の gapPercent・currentPrice は決算期末の擬似株価基準のまま変更されません)。擬似株価を算出できない銘柄(赤字で PER なし等)では、この株価で時価総額を組んで DCF を返します(currentPriceSource=user-provided)。

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, the description discloses the model assumptions, FCF definition differences, suppression rules for financial companies, fallback pricing paths, failure modes, and extensive caveats. This is unusually rich behavioral context for a read-only valuation tool and directly helps the agent interpret results correctly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely long and dense, effectively embedding a large portion of an output schema and model documentation into the tool description. It is front-loaded and sectioned, but its size makes it difficult to scan and includes many details that could be moved to structured output documentation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, absence of an output schema, and numerous model-specific edge cases, the description is thorough. It explains return fields, failure conditions, fallback paths, suppression rules, and caveats in enough depth for an agent to interpret and use the tool responsibly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already explains both the code and optional currentPrice parameters in detail. The description reinforces the currentPrice fallback behavior but adds little unique parameter semantics beyond what the schema already states, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with a specific verb and resource: retrieve the breakdown and sensitivity analysis of DCF theoretical enterprise value for a given stock code. It explicitly distinguishes itself from get_stock_analysis and other valuation-related siblings, so an agent can identify its role without guessing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit routing guidance: use get_stock_analysis for broad multi-section analysis, and use this tool for detailed annual breakdowns, caveats, and sensitivity. It also names get_edinet_financial_data, get_ideal_price, and get_stock_score as complementary evidence sources, making when-to-use and alternatives clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_earnings_flash決算速報A
Read-only
Inspect

当日または直近営業日の決算速報(TDnet 決算短信)を注目度順に取得します。 銘柄を指定しない「今日の決算は?」のような質問に答えるためのツールです。

返却は注目度順(決算短信 items と業績予想・配当予想の修正 revisions は同じ 0〜100 の注目度で並べ、両方を合わせた通し順位を attentionRank に入れます)。1 回の件数は limit(省略時 10 件、最大 30 件)、開始位置は offset で指定し、ページ送りで全件を取得できます。 全体の件数(totalCount)と増減益の内訳は全件から集計して返します。続きがあるときは note に次の offset を書きます。 一覧(code なし)の応答には、ページ送りの状態を欄として添えます: hasMore(続きがあるか)・nextOffset(続きの offset。無ければ null)・remaining(残り件数)。 修正(revisions)を返したときは revisionsHasMore・revisionsNextOffset・revisionsRemaining も付きます。 利用者に監視リストがあり、その銘柄がその日に決算を出していれば、1 ページ目(offset=0)の応答に watchlistReportedCodes(決算短信)と watchlistRevisedCodes(予想の修正)として銘柄コードだけを載せます。 一覧(code なし)は 1 件ごとの要約(主要実績と前年比・予想の要点・配当の判定・注目度・warnings)を返します。 全項目(前期実績・B/S・CF・サプライズ判定・推移 recentTrend 5期分)は code を指定すると取得できます。 (includeDetails=true で一覧にも全項目を付けられます。1 件が大きいため 1 回の最大は 5 件です) ※このツールは返した件数ぶん利用回数を使います(0件・1件なら1回)。件数は items・revisions・preliminaryResults の合計です。 本決算・四半期の両方を含みます。 freshness: latestBusinessDay(今日が営業日なら今日、休みなら直前の営業日)・latestAvailableDate(データのある最新日)・returnedDate(この応答の日)・isLatestBusinessDay(returnedDate が latestBusinessDay か)・sourceStatus(latestBusinessDay の取り込みで取り元の開示一覧に見えていた件数 xbrlListTotal・fullListTotal・earningsListed と確認時刻 checkedAt、保存済みの開示一覧の件数 storedListTotal・storedEarningsListed と最新の開示時刻 storedListLastItemAt。その日の取り込みがまだ無ければ null)。さらに、開示一覧が何時の開示まで入っているかとして coveredThrough(入っている最後の開示の時刻 JST。保存と取り元の新しいほう)・listUpdatedAt(一覧を取った時刻)を返します。取り元は平日 15:01 ごろに 15:00 までの分が入り、15:00 より後の分は翌朝までに入るため、この間は status=partial_until_next_morning(15:00 までは入っていて残りは翌朝。故障ではない)と nextExpectedUpdate(時刻は断定しない説明)を返します。更新が止まっているとき(15:00 の分も来ない・翌日の昼になっても埋まらない等)は status=source_stalled(lastItemAt・note 付き)を返します。

【業績予想・配当予想の修正(revisions)】決算短信を出していない会社の、その日の業績予想・配当予想の修正を items とは別の配列 revisions で返します。 items・totalCount・breakdown は決算短信だけの件数・内訳です(revisions は含みません)。revisions の件数は revisionsTotalCount、向きの内訳は revisionsBreakdown。 revisions は revisionsOffset / revisionsLimit(省略時 10 件、最大 30 件、0 で返さない)で items とは独立にページ送りします。 items のページ送り(offset が 1 以上)で revisionsOffset・revisionsLimit をどちらも指定しないときは、revisions を返しません(1 ページ目と同じ修正の重複を避けるため。修正は revisionsOffset で取得してください)。 各修正の attentionScore(score 0〜100・50 が中立と breakdown 内訳。items の注目度と同じ尺度)は、通期(来期)の営業利益の修正率を主に、純利益・売上・配当の修正を加えた点数です(中間期・四半期のみの修正は控えめ、増減まちまちは 50 寄り、据え置き・方向不明・初回の予想の公表は 50)。 revisions は attentionScore の高い順に並べます(同点は上方・下方修正 → 初回の予想の公表 → 据え置き → 増減まちまち → 方向不明、通期 → 中間期・四半期のみ → 配当のみ、営業利益の増減率の大きい順)。 items と revisions を1つの注目度順の一覧にするときの順序は attentionRank(両方を合わせた通し順位。同点は items が先)で決まります。 各修正の direction は修正前後の数字(XBRL)で決めた向き(up/down/mixed/flat/unknown。修正前の値が無い初回の予想の公表は initial で kind=initial_forecast)。 scope.label に対象期(例: 「通期」「中間期のみ(通期の予想はこの開示に含まれない)」「配当のみ」)、metrics に対象期の売上・営業利益・経常利益・純利益・EPS の修正前(previous)・修正後(current)・増減率(changePercent。%)、dividend に1株配当の修正前後が入ります。 中間期だけの修正(通期据え置き)を通期の修正と取り違えないよう、各行に scope(通期・中間期のみ等)が付きます。 XBRL(数字)の無い修正の開示は載りません(get_timely_disclosures で確認できます)。 同じ日に決算短信も出した会社の修正は revisions に入れず、その会社の items の sameDayRevision(label・direction・summary・revisions)に付けます。 REIT・投資法人の修正は items と同じく既定で除外し、includeReits で含めます。 決算短信が0件で修正だけある日も、その日として返します(items は空、revisions に修正)。

【決算速報値(preliminaryResults)】決算短信の前に出る「決算速報値に関するお知らせ」(決算の概数)を、items とは別の配列 preliminaryResults で返します(その日の全件。件数は preliminaryResultsCount)。 各件は label が「決算速報値」で isPreliminary=true。period・fiscalYearEnd(四半期・中間期は累計期間の末日)・fiscalYearEndOfYear(年度の決算期末)・consolidated(連結か個別か)・actual(速報値の売上・営業利益・経常利益・純利益・EPS)・prior(前年同期の実績)・surprise.earnings(前年同期比 changePercent。決算短信と同じ式)を持ちます。 正式な決算短信の前の概数なので、決算短信の値ではありません。同じ期の決算短信が取り込まれた会社は preliminaryResults に出しません(短信が正。items に出ます)。 items・totalCount・breakdown に決算速報値は含みません。

【増減率・配当の欄】surprise.earnings の各項目(売上高・営業利益・経常利益・純利益・EPS)の changePercent は前期比(前年同期比)の増減率(%)。 前期か当期が 0 以下(赤字が絡む)の項目は changePercent が null で、signChange に区分が入る(turnaround=黒字転換・toLoss=赤字転落・lossNarrowed=赤字縮小・lossWidened=赤字拡大・lossContinued=赤字継続・zero=両期とも 0)。 signChange がある営業利益・経常利益・純利益には、前期・当期・増減額の amounts(円)と、会社の大きさに対する目安 scale が付く(売上高・EPS には amounts は付かない。EPS の scale は純利益と同じ)。 scale は basis が netSales なら各期の利益 ÷ 売上高(利益率・%)、売上高のない会社の totalAssets なら当期末の総資産に対する割合(%)。prior・actual は前期・当期の値、changePoints は当期 − 前期(pt)。changePoints の絶対値が 1pt 未満のとき direction は neutral。 changeSource は changePercent の出どころ: tanshin=短信に書かれた増減率、computed=短信に欄がなく金額から計算、not-stated=短信が「-」とした項目で changePercent は null(2026-10-24 より前に保存した値には付かない)。 配当 surprise.dividend の actualVsPrior・forecastVsActual は、特別配当・記念配当を除いた普通配当どうしの向き(increase/decrease/unchanged)。 特別配当のある期があるときは、ordinary に普通配当(actualAnnual・priorAnnual・forecastAnnual)が入り、特別配当を含む年間配当の合計どうしの向きが普通配当どうしと異なるときだけ totalDirection(actualVsPrior・forecastVsActual)に合計の向きが入る。

【warnings について】返却データの warnings 配列には、以下の観点の判定結果が入ります。 status が detected のものは、数字だけでは読み取りにくい注意点(業績の見かけと実態のずれ)です。 (要約では detected のものだけ warnings に入ります。データ不足で判定できなかった観点は warningsUnavailable に パターン名で入り、「該当なし」ではありません。どちらにも無い観点は「該当なし」と判定済みです)

  1. operating_loss_ordinary_profit: 営業赤字なのに経常黒字(本業の不振が営業外で隠れる)

  2. net_loss_positive_ocf: 純損失なのに営業CF黒字(減損等の非現金損失)

  3. inflated_change_rate: 前期が極小のため変化率が誇張されている

  4. dividend_up_despite_loss: 赤字なのに増配(資本の取り崩しの可能性)

  5. improving_but_still_loss: 改善率はプラスだが実額は赤字のまま

【読み方の注意】

  • period が q1/q2/q3 の銘柄の fiscalYearEnd は、その四半期の累計期間の末日です (年度の決算期末日ではありません)。actual と増減率も、その累計の値です。 年度の決算期末日は fiscalYearEndOfYear(例: 3月決算の q2 は fiscalYearEnd=2026-09-30、fiscalYearEndOfYear=2027-03-31)。 一覧(要約)には fiscalYearEndOfYear まで、全項目(code 指定・includeDetails)の q1/q2/q3 の銘柄には、累計期間の末日 quarterlyPeriodEnd(fiscalYearEnd と同じ値)と、取り違えないための説明 fiscalYearEndNote も付けます。 annual(本決算)は fiscalYearEnd と fiscalYearEndOfYear が同じ値です。fiscalYearEnd の値は従来のままで変えていません。

  • breakdown の「赤字転落」は「減益」の内数です(合計が totalCount と一致しないことがあります)。

  • actual.netIncomeBasis が total-incl-discontinued の銘柄は非継続事業があり、netIncome・eps は非継続事業を含む合計、continuingNetIncome・continuingEps は継続事業だけの値(取れなければ null)です。増減益の内訳・warnings・サプライズは、継続事業の値が当期・前期そろう銘柄では継続事業どうしで判定しています。

status が unavailable のものは「該当なし」ではなく「データが無く判定できない」です。 警告が出ていないことは「問題なし」を意味しません(判定できる観点が限られるため)。

推移の詳細は get_edinet_financial_data(全項目。既定は直近2期、10期分は fiscalYear: "all")、 スコアは get_stock_score で確認できます。

※ 本データは情報提供を目的とし、投資助言・推奨ではありません。

NameRequiredDescriptionDefault
codeNo証券コードで1銘柄に絞ります(例: 7203)。英字入り(140A等)も可。
dateNoYYYY-MM-DD。省略時は最新営業日。直近7営業日のみ対応。
limitNo返す件数。省略時 10、最大 30(includeDetails=true のときは最大 5)。
offsetNo注目度順で先頭から読み飛ばす件数(ページ送り用。省略時 0)。
includeReitsNoREIT・投資法人を含めます(決算短信・修正の両方)。既定は除外。
includeDetailsNo全項目(前期実績・財務・サプライズ判定・recentTrend)を付けます。code 指定時の既定は true、一覧の既定は false(要約のみ)。
revisionsLimitNo業績予想・配当予想の修正(revisions)を返す件数。省略時 10、最大 30。0 で修正を返しません。
revisionsOffsetNorevisions の並びで先頭から読み飛ばす件数(ページ送り用。省略時 0)。

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only cover readOnlyHint and openWorldHint; the description goes far beyond them, disclosing usage-based billing per returned item (items + revisions + preliminaryResults), REIT exclusion by default, the rule that later item pages omit revisions unless revisionsOffset is given, the exclusion of companies whose formal tanshin already exists from preliminaryResults, and freshness states such as partial_until_next_morning and source_stalled with their causes. These are exactly the operational facts an agent needs before calling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and the pagination contract are front-loaded, and section headers for revisions, preliminaryResults, warnings, and reading caveats aid scanning. But the text runs to many hundreds of words describing return-field semantics that belong in an output schema, and several points (fiscalYearEnd vs fiscalYearEndOfYear, changeSource, scale/changePoints, dividend ordinary vs total) are restated at length rather than compressed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and a highly complex, multi-array response (items, revisions, preliminaryResults, breakdown, warnings, freshness), the description carries the full burden and does so thoroughly, including edge cases like zero-tanshin days that still return revisions and why breakdown buckets may not sum to totalCount. Almost nothing an agent must know to interpret or page through the result is left unsaid.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline would be 3, but the description adds cross-parameter meaning the schema does not: limit drops to a max of 5 when includeDetails is true, offset is defined relative to attention rank, revisionsLimit=0 suppresses revisions, and offset>=1 without revisionsOffset intentionally returns no revisions. That is real added semantic value beyond the field descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names a specific verb and resource (retrieves TDnet earnings flash for today or the latest business day) and states the ordering (attention rank), plus the user question it answers. It also positions itself against siblings at the end (get_edinet_financial_data for full history, get_stock_score for scores, get_timely_disclosures for disclosures lacking XBRL), so an agent can distinguish it without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a concrete trigger ("what earnings came out today?" with no ticker specified) and routes follow-up needs to specific siblings. It does not, however, explicitly state when NOT to use it versus get_timely_disclosures or get_earnings_forecast, so exclusions are mostly implied by the surrounding detail rather than stated up front.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_earnings_forecast業績予想A
Read-only
Inspect

銘柄コード指定で、TDnet 決算短信から抽出した会社予想(来期業績・配当予想)を取得します。 会社名(companyName)は会社名の索引の現在の社名です。短信に書かれていた名前が異なるときだけ companyNameAsFiled に元の表記を付けます。companyNameIndexAsOf は索引の作成時刻です。 当期実績(速報)、前期実績、来期予想、配当予想、サプライズ判定を含みます。

データソース: TDnet 決算短信 XBRL を日次バッチで自動パース。 カバレッジ: 決算短信を提出した全上場企業(決算発表日翌日に反映)。

取得項目:

  • actual: 当期実績速報(売上・営業利益・経常利益・純利益・EPS・総資産・純資産・CF・ROE・総資産経常利益率など)

  • prior: 前期実績 ※ ordinaryIncome は IFRS・米国基準(accountingStandard が IFRS / USGAAP)の会社では経常利益ではなく税引前利益です。

  • forecast: 来期予想(数値 / レンジ上下限 / 前期比 %) period 省略時、最新の予想年度に点の予想EPS・純利益が無ければ前の年度(終わった期)の予想は返さず、forecastStatus(range=レンジのみ / non_gaap_only=利益の予想は Non-GAAP だけ / cumulative_only=通期の予想は無く累計期間の予想だけ / none=予想なし)と forecastStatusNote を付けます。

  • forecastNonGaap: 通期の利益予想を Non-GAAP でだけ開示する会社(6701 など)の Non-GAAP 営業利益・親会社に帰属する当期利益・EPS と前期比(%)。短信サマリーの予想の表の文字から読んだ値(タグなし。labels は見出しの原文、source は読んだ短信)で、株式分割の調整をしていません。 このとき forecast.operatingIncome / netIncome / eps(IFRS 等の欄)は null のままで、理想株価・スコアの計算には forecastNonGaap を使っていません。

  • forecastCumulative(period 省略時は開示日が最も新しい短信から): 第1・第3四半期累計の業績予想(通期の予想を出さず累計だけを予想する会社。6146 など)。 quarter(q1=第1四半期累計 / q3=第3四半期累計)・periodStart・periodEnd・consolidated・netSales / operatingIncome / ordinaryIncome / netIncome / eps(とレンジ)・ source(tdnetId・disclosedDate。修正開示を重ねたときは revisionTdnetId)。短信の記載値のまま(株式分割の調整をしていません)。上期(第2四半期累計)は forecastH1。

  • dividend: 配当(当期実績、来期予想、中間/期末/年間) 特別配当・記念配当の内訳(決算短信の配当の注記から読み取り。読めない・言及が無いときはフィールド自体が無い): dividend.actualSpecial(actualAnnual のうち)/ priorSpecial(priorAnnual のうち)/ forecastSpecial(forecastAnnual のうち)。 普通配当=actualAnnual − actualSpecial(予想は forecastAnnual − forecastSpecial)。 増配幅を見るときは普通配当どうしで比べてください(特別配当を含む合計どうしだと増配幅を見誤ります)。 フィールドが無いことは「特別配当が無い」ことを保証しません(注記を読めなかった場合も無くなります)。 予想の特別配当の出どころは forecastSpecialSource(予想年間配当があるときだけ): status が stated(短信の注記・修正開示に額の記載あり。 from: tanshin-note / revision-disclosure)、undetermined(修正開示に特別配当が入っているが額を読めない)、 not-stated(短信の注記・取り込んだ修正開示に額の記載が無い。含まれないことの確認ではない)。 予想を四半期短信から採った場合、年度短信の注記に内訳が無くても、四半期短信の注記にある前期の内訳を 同じ年度・同じ年間配当のときに限り actualSpecial に引き継ぎます。 短信から読めない場合は、同じ年度の有価証券報告書(配当に関する注記・経営指標等の注記・配当政策の節・期末配当の注記) から決めた特別配当で補うことがあります(年間配当が actualAnnual と一致するときのみ。補ったときは actualSpecialSource が付きます)。 この額は get_edinet_financial_data の specialDividendPerShare・summary の普通配当・get_ideal_price の配当価値と同じ関数の値です。 有報から一部の回(期末配当など)の特別配当しか分からない年度は、その額で補い actualSpecialSource.completeness が partial になります (年間の特別配当はその額より大きいことがあります)。 前期中に株式分割があり短信が前期の年間配当を「-」と記載している場合、dividend.priorAnnual は有報「剰余金の配当」の 決議から分割後の株数基準にそろえて作った値です(priorAnnualSource が付きます。検算できないときは null のまま)。

  • surprise: 前期実績対比の増減判定(業績・配当)

  • actual / prior の netIncomeBasis が total-incl-discontinued の銘柄は非継続事業があり、netIncome・eps・changeNetIncome は非継続事業を含む連結の合計、continuingNetIncome・continuingEps・changeContinuingNetIncome は継続事業だけの値です(取れなければ null。売上・営業利益・税引前、配当性向、来期予想は会社の開示どおり継続事業ベースのことがあるため、来期予想と比べるときは継続事業の値を使ってください。surprise.earnings の純利益・EPS は basis が continuing なら継続事業どうしの比較です)。

【短信がまだ無いとき】(2026-11-01) 指定した期(q1/q2/q3 など)の短信が無いのは入力の誤りではないため、エラー(isError)にはせず { hasData: false, status, reason, expectedAvailability, availablePeriods, forecast: null } で返します。 status: not_yet_disclosed=まだ開示の目安日より前 / possible_intake_delay=目安日を過ぎているのに無い(取り込みの遅れの可能性。basis に年度末・四半期末・目安日)/ not_available=この銘柄の短信をまだ持っていない / delisted=上場廃止 / not_applicable=ETF・REIT 等。存在しない銘柄コードだけが isError です。

【予想の鮮度について】(2026-09-22) period 省略時は「開示日が最新の決算短信」から通期予想を返します。 通期予想の修正は四半期短信で開示されるため、年度短信だけを見ると 数ヶ月前の古い予想になります(実測: 304社で予想純利益が変わっており、 うち63社は50%超の乖離。開示日差の中央値は86日)。 四半期短信から採った場合は forecastSource に採用した期と開示日を付与します。 このとき actual・prior・surprise・配当の実績/前期・fiscalYearEnd は**年度短信(通期)*のままで、 予想(forecast・forecastH1・dividend.forecast)だけが四半期短信の最新値です。 prior が前年同四半期になったり、surprise が四半期同士の比較になったりはしません。 四半期累計の実績は quarterlyCumulative に別フィールドで入ります。 短信が前年同期比を「-」とした項目(quarterlyCumulative.changeNotStated)は、金額から計算した増減率を quarterlyCumulative.changeComputed(source=computed。短信の記載ではない)に別の欄で返します。 quarterlyCumulative は、最新の予想の年度で開示日が最も新しい四半期短信の累計実績です(period・disclosedDate・tdnetId が出どころ)。 予想 EPS が無いため予想を年度短信から採った場合も返します。予想の短信(forecastSource)と別の短信のことがあります。 ただし年度(通期)の決算短信が保存されていない銘柄(annualActualUnavailable が付く)では、 actual・prior・surprise.earnings・配当の実績/前期・fiscalYearEnd を null で返します(四半期累計を通期実績として返さないため)。 このとき四半期短信の累計期間の末日は quarterlyPeriodEnd、年度の期末日は nextFiscalYearEnd です。 disclosedDate は短信が最初に開示された日です。期中レビューの完了に伴って同じ短信が再開示された場合は reviewCompletion(再開示の日付・tdnetId)を添えます。contentChanged=true のときだけ中身が変わっており、 disclosedDate も再開示の日付です(元の短信は originalDisclosedDate)。

【quarterlyCumulative.bps について】(2026-09-26) 四半期短信のサマリーXBRLには1株純資産(BPS)タグ自体が無いことがあります (本番実測: 四半期短信全体で約80%が欠落。q1 79%・q2 89%・q3 90%)。その場合、 equity ÷ (sharesOutstanding − treasuryShares) から算出した値を bps に補完し、 bpsSource: 'derived' を付与します。 優先株・種類株のある会社では、equity に優先株主帰属分が含まれるため補完値が 過大になることがあります。直近年度の開示済みBPSと比較して比率が0.5〜2.0倍の 範囲を外れる場合は信頼できないため補完しません(bps は null のまま、 bpsSourceNote にその旨を記載)。 ROE / ROA は補完しません。四半期短信の同タグは3/6/9ヶ月の累計利益をそのまま使うため 年率ではなく、通期短信のROE/ROAと単純比較できないためです。

period 引数:

  • 省略時: 開示日が最新の短信から通期予想

  • annual: 年度決算短信を明示指定

  • q1 / q2 / q3: 四半期決算短信

注意:

  • surprise はアナリスト予想(コンセンサス)との比較ではありません。 本サービスはコンセンサスデータを保有していません。 surprise.earnings[].changePercent は「当期実績 vs 前期実績」の増減率(±5%超で positive/negative)、 surprise.dividend は actualVsPrior(当期実績 vs 前期実績)と forecastVsActual(来期予想 vs 当期実績)です。年間配当の合計(特別配当・記念配当を含む)どうしの比較です。 市場予想(コンセンサス)との比較は含まれません。

  • 受注高・受注残などの業種固有の指標は XBRL 標準タグ外のため含まれません。

  • 決算短信の訂正開示: corrections がある場合は訂正を反映済みです(correctedFrom が訂正前の値、 キーは 'actual.cashFlowFromOperations' のようなパス)。correctionNotices がある場合は訂正開示が 出ていますが数値は反映していません(PDF のみの訂正・XBRL を読めなかった等)。correctionNote に要約があります。 予想を四半期短信から採った場合、その短信の訂正は forecastCorrectionNote に載ります。

  • actual / prior に netSalesSource: 'edinet-annual' がある場合、その netSales は短信から読めなかったため、有価証券報告書の同じ決算期の売上で埋めた値です(netSalesSourceDocId が有報の docId。短信の開示値ではありません)。

  • 会社予想が未開示の場合、forecast.netSales 等は null になります。

  • forecastPeriodMonths は来期予想の対象期間(月数)です。通常は 12。 直近の予想が四半期短信(q1/q2/q3)から採用され、かつ直近の確定年度決算が 見つからない等の理由で判定できないときは null になります (null は「変則決算ではない」ことを意味しません。判定不能です)。 四半期短信から採用した予想は、決算期変更等で対象期間が12ヶ月以外になることが あります(四半期短信の通期予想が常に12ヶ月分とは限りません)。

  • 決算期変更による変則決算(12ヶ月以外)の場合、年度短信(annual)採用時は irregularPeriod が付きます。このとき forecast.* は変則期間分の値なので、 前期比・PER・利回りを論じる際は irregularPeriod.forecastAnnualized (年換算値)が比較に使えます。変則決算に気づかず前期と単純比較すると 大幅な減収減益に見えます。

  • forecastPeriodNote が含まれる場合、四半期短信採用時に forecastPeriodMonths が 12以外と判定されています。この場合は年換算していません(四半期短信の通期予想を 書き換えると開示値と食い違うため)。前期比較の際は forecastPeriodMonths を 確認してください。

  • 過去実績の体系的なデータは get_edinet_financial_data(有報ベース。多くの会社で約10年分(上場が浅い会社は短い))にあります。

  • period 省略時の配当予想(dividend.forecast*)は、最新の予想年度で開示日が最も新しい短信から読みます(予想EPSなどの業績予想と別の短信のことがあります)。年間が空欄で期末の予想がある短信は、中間(実績または予想)と期末を分割後の株数に揃えて足した値を forecastAnnual にします。どちらの場合も dividendForecastSource に出所を載せます。

  • dividend.forecastYearPaid(period 省略時): 予想の年度に既に支払った中間配当(四半期短信の実績欄、分割後の株数に揃えた値。{ q1, q2, q3 })。支払済みの四半期は短信で予想の列から実績の列に移るため dividend.forecastQ1〜Q3 には入りません。

  • excludedDividendDecisions(newerDisclosureWarning / newerDisclosureCheck 内)は、「剰余金の配当」 (配当の決定)のうち、採用した短信の期末の次の四半期末より前に出たため短信に載っている実績配当の 決定とみなし、修正の候補から外した開示です(特別配当・方針変更・基準日設定などを含む表題は外しません)。

  • revisionOverlay(period 省略時): 採用した決算短信より後の「業績予想の修正」「配当予想の修正」開示を、 修正開示の前回予想が短信の予想と全項目一致するときだけ予想に重ねています(通期の修正は forecast、 中間期の修正は forecastH1、第1・第3四半期累計の修正は累計の予想(理想株価の forwardTwelveMonth の材料。 period 省略時の forecastCumulative に出ます)、配当は dividend.forecast*。理想株価・get_ideal_price と同じ値)。 applied に重ねた修正(tdnetId・開示日・対象期間・修正前後)、skipped に重ねなかった修正と理由 (previous_mismatch=前回予想が一致しない、current_undetermined=未定への修正、split_driven=分割に伴う修正、 unsupported_target=翌期の修正・期間を決められない四半期累計の修正、after_unapplied_revision=前の修正を重ねられなかった、 already_in_tanshin=短信が既に修正後の値、other_consolidation_basis=短信の累計の予想と連結・個別が違う四半期累計の修正)、 asOfDate に重ねた後の予想の基準日を載せます。 特別配当・記念配当を含む配当の修正も年間の合計は重ねます。本文から金額を読めたときはその金額を dividend.forecastSpecial に入れ、 読めないとき(applied[].specialDividendUnknown)は revisionOverlay.dividendValueBasis に修正前の普通配当(理想株価の配当価値の基礎)を載せます。 disclosedDate は元の短信の開示日のままです。

  • newerDisclosureWarning が含まれる場合、採用した決算短信より後に「配当予想の修正」 「業績予想の修正」等の適時開示が出ていて、forecast/dividend の数値にまだ全部は反映していません (すべてを予想に重ねた開示は外し、reflectedRevisionIds に載せます。一部でも重ねなかった開示は残ります。 重ねなかった理由は revisionOverlay.skipped)。該当開示は get_timely_disclosures で確認できます。possibleSplitDrivenRevision が付いた 開示は株式分割に伴う機械的な配当予想の修正の可能性があり、実質的な増減配とは 限りません。disclosures[].parsedNumbers が付いている場合、その開示のXBRLから 修正前後の数値(previous/current、増減率)を取り込み済みです(無い場合はXBRL未取得 またはパース対象外)。

  • latestRevision が含まれる場合、newerDisclosureWarning で検出した開示(採用した決算短信 より後のもの)のうち、業績修正・配当修正それぞれ最新の修正後の数値です (業績と配当が別開示のことがあるため独立に選んでいます)。latestRevision.earnings は配列で、 連結・個別や対象期間ごとに別開示から選ばれることがあります(同時刻に連結業績修正と 個別業績修正が別開示で出るケース等)。forecast / dividend.forecastAnnual 等の フィールドに重ねなかった修正だけが出ます(重ねた修正は revisionOverlay.applied)。latestRevision の値で forecast 等を置き換えてはいません。この数値は決算短信本体ほど検証されておらず、 XBRLタグの解釈に会社ごとの癖がある(例: 一部企業がOperatingRevenuesタグを 営業利益の意味で使う等)ため、重要な判断には該当開示のPDF本文での確認が必要です。 latestRevision.earnings[].data.priorActual は修正開示の参考欄(前期実績)の会社記載値そのままで、 決算短信と食い違うことがあります。通期のものには priorActualCheck(同じ年度の決算短信との照合結果)を添えます。 status=eps-mismatch は純利益が一致するのに EPS だけ食い違う(修正開示側の記載の食い違い)ことを示し、 前期の EPS は priorActualCheck.comparedWith.eps(決算短信)を使ってください。

  • sameDayRevision が含まれる場合、採用した決算短信と同じ日に業績予想・配当予想の修正開示が出ています。 summary に修正前後の値(修正前の値が取れないときはその旨)を載せ、parsedNumbers に修正前後・増減率の 元の値、revisionDirection に上方/下方の方向を載せます。短信の forecast / dividend がこの修正後の値と 一致するかは判定していません。

  • newerDisclosureCheck は上の検出処理が実際にどこまで確認できたかを示します。 status:no-newer-revision なら保存済み開示データの範囲内(checkedFrom〜checkedTo)で 修正は見つかりませんでした。status:unverifiable なら検証できていません (reason を参照。適時開示キャッシュの保存開始日より前の短信を採用した場合等)。 unverifiable は「修正が無い」ことを意味しません。 status:partially-checked なら、確定した範囲(checkedFrom〜checkedTo)では修正は見つかりませんでしたが、 unconfirmedDates の日は開示一覧がまだ確定していません(やのしんは夕方以降の開示を翌営業日の午後に足すことがあり、 取り直しは営業日の 15:03 と 19:00 JST。翌日以降の取り直しで、取り元の一覧と件数・最後の開示時刻(15:00 より後)まで一致すると確かめられた日は、翌営業日を待たずに確定とします。確かめられるまで未確定)。この日の修正の有無は不明で、 「修正は無い」とは言えません(note 参照)。

  • 四半期短信の原本 XBRL が失われ、取り込んだ日の日次のまとめから作り直したレコードには reconstructedFrom(source: tdnet-daily-summary)と reconstructionNote(予想を採ったときは forecastSource.reconstructionNote)が付きます。 予想の経常利益・増減率・上期予想・配当の内訳は残っていないため null / 未記載です(開示が無かったという意味ではありません)。

  • dataProvenance は、年度短信のレコードの tdnetId が空(年度短信の原本 XBRL が無く、TDnetパイプラインの 通常経路で取り込めていない)ときだけ付き、実績(actual / prior)の出どころを次の4つで示します (provenanceDetail に根拠)。 rebuilt-from-annual: 2026-05-07 に一括生成したレコードの actual / prior を、有報(EDINET)の同じ決算期の 値で作り直し済み(provenanceDetail.rebuiltAt)。 reconstructed-from-annual: 年度短信の原本が無いため、有報から作ったレコード(provenanceDetail.edinetDocId)。 来期予想は有報に無いので forecastSource の短信から採ります。 legacy-bulk-matches-annual: 一括生成のままだが、actual が有報の同じ決算期の値と一致することを確認済み (provenanceDetail.comparedFields)。 legacy-bulk: 一括生成時の値のままで、有報との一致を確認できていない、または食い違う (provenanceDetail.mismatchedFields / uncomparableReason)。 surprise.earnings はパース時と同じ式で読み出し時に再計算していますが、 surprise.earningsNote がある場合は再計算していません(前期の会計基準が 実際と異なる等の理由。reasonを参照)。priorBasisMismatch が含まれる場合、 前期実績(prior)が組み替え後の値ではない可能性があります。 rebuiltPriorBasis(source: ifrs-first-time-adoption)がある場合、当期が IFRS 移行初年度で、prior の損益・B/S・C/F・EPS・BPS は 移行初年度の有報(rebuiltPriorBasis.edinetDocId)に載っている前期の IFRS 組替値です(株数・1株配当は前期の有報の値)。staleAnnual が 含まれる場合、決算期末から長期間経過しており、このレコードが更新されていない 可能性があります。 このレコードの disclosedDate は年度短信の開示日とは限りません(一括生成時点の最新の開示の日付が入っている例がある)。 disclosedDateCheck.status が likely-not-annual-tanshin(決算期末から90日超)なら年度短信の日付ではない可能性が高く、 unverified なら未確認です。actualSource(予想を四半期短信から採った場合)では、likely-not-annual-tanshin のとき disclosedDate を null にし、記録値を recordedDisclosedDate に分けています。actualSource.tdnetId が null なのは 元の短信が特定できないためです(実績の出どころは actualSource.dataProvenance を参照)。

  • period に q1/q2/q3 を明示指定した場合、fiscalYearEnd はその四半期の累計期間の 末日(例: q1なら6/30)であり、年度の決算期末日ではありません。年度の決算期末日は nextFiscalYearEnd を参照してください(fiscalYearEndNote に同内容を付与します)。

【ordinaryIncomeToTotalAssets(総資産経常利益率)について】(2026-10-02) actual / prior / quarterlyCumulative の ordinaryIncomeToTotalAssets は決算短信サマリーの記載値で、 経常利益 ÷ 総資産(原則 期首・期末平均)の % です。IFRS・米国基準は経常利益が無いため税引前利益ベースです (ordinaryIncomeToTotalAssetsBasis: ordinaryIncome=経常利益 / profitBeforeTax=税引前利益)。 get_edinet_financial_data の roa(ROA=純利益 ÷ 期末総資産、有報ベース)とは別の指標なので、 ROA とは別の指標です。純利益ベースの ROA が必要なら netIncome ÷ totalAssets で計算できます。 tdnetId が空の年度短信レコード(dataProvenance あり)はこの値を返しません (保存値が短信の記載値ではなく純利益 ÷ 期末総資産の計算値のため)。

【roe(ROE)の定義について】(2026-10-10) actual / prior の roe は決算短信サマリーの「自己資本当期純利益率」で、純利益 ÷ 期首・期末平均の自己資本の % です (roeBasis: averageEquity)。get_edinet_financial_data の fiscalYears の roe(有報)も同じ定義にそろえています (有報の記載値。roeBasis: reported / averageEquity)。 tdnetId が空の年度短信レコード(dataProvenance あり)は期末ベースの計算値です(roeBasis: periodEndEquity)。 決算期が6か月の REIT は、その期間の率(年換算していない)です。

応答の metricLabels は英語キー→日本語指標名の対訳です。利用者向けには日本語名(例: roe→「ROE(自己資本利益率)」。roeBasis が averageEquity なら「期首・期末平均の自己資本ベース」と添える)のほうが伝わりやすくなります。 データ品質・値の異常・不具合に触れる場合も同様で、フィールド名を示すときは「発行済株式数(sharesOutstanding)」のように日本語を主・英語キーを括弧内にすると読みやすくなります。

splitCheck(分割履歴がある会社のみ): 既定は要約(splits・adjustedFields・conflict)のみ。詳細は includeSplitDetails: true で、1株あたりの値ごとに raw(短信・有報の記載値)・adjusted(使った値)・factor・basis・method と、検算の材料(純利益÷EPSで逆算した株数と分割前の株数の比)を載せます。adjusted が検算と食い違う(conflict: true 等)ときは raw を基に判断してください。

※ 本データは情報提供を目的とし、投資助言・推奨ではありません。

NameRequiredDescriptionDefault
codeYes証券コード(例: 6264 = マルマエ)
periodNo決算期間。**省略時は開示日が最新の短信から通期予想を返します**(通期予想の修正は四半期短信で開示されるため、annual固定だと古い予想になる)。q1/q2/q3 を明示指定するとその期の短信を返します。
includeSplitDetailsNo省略可(既定 false)。true で分割の検算の詳細(splitCheck の items・evidence・howToVerify、splitAdjustment の reason 全文)を返します。既定では splitCheck は要約(splits・adjustedFields・conflict)のみ。検算の食い違い(conflict)があるときは、false でも詳細を返します。数値は変わりません。

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare read-only and closed-world; the description goes far beyond by disclosing the batch-parse data source, next-day reflection lag, non-error `hasData: false` returns with status codes, revision-overlay application rules, correction handling, and explicit caveats that surprise compares against prior-period actuals and not consensus. This is exactly the kind of behavioral context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded and section headers help, but the text runs to many hundreds of lines of niche edge cases — BPS back-fill rates, dataProvenance taxonomy, newerDisclosureCheck timing, sameDayRevision — that crowd out the core call contract. Much of this belongs in reference documentation rather than a tool description an agent must read before every call.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description carries the full burden of explaining the response, and it does: field-by-field semantics, null vs. absent distinctions, per-field basis/source markers, and fallback behavior when a disclosure is missing. Nothing an agent needs to interpret the return shape is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: what `period` omission implies for forecast freshness (with the measured 304-company drift example), and that an explicit q1/q2/q3 makes fiscalYearEnd the quarter-end rather than the fiscal year-end (nextFiscalYearEnd). `includeSplitDetails` is only restated, not enriched, so it is not a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening line states a specific verb and resource: retrieve company forecasts (next-period results and dividend forecasts) extracted from TDnet earnings disclosures by securities code, and enumerates the returned blocks (actual, prior, forecast, dividend, surprise). It also explicitly separates itself from siblings by pointing at get_edinet_financial_data for historical actuals and get_timely_disclosures for revision filings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear operating context: period defaults to the newest-disclosure forecast, annual/q1/q2/q3 are alternatives with stated consequences, and it routes to get_edinet_financial_data for long-run actuals and get_timely_disclosures for revision notices. It never states when to prefer this over the sibling get_earnings_flash (flash results), which is the one obvious overlap left unaddressed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_edinet_financial_data財務データA
Read-only
Inspect

銘柄コードを指定して年次財務データ(EDINET有価証券報告書ベース)を取得します。 会社業績予想(TDnet 決算短信ベース)も同時に返るため、財務面の分析はこのツールで完結します。 有報がまだ無い銘柄(新規上場の直後など)や、指定した fiscalYear(YYYY-MM-DD)のデータが無いときは、エラー(isError)にせず { hasData: false, status, reason, availableFiscalYears } で返します(status: not_available / not_yet_disclosed / possible_intake_delay=取り込みの遅れの可能性 / out_of_coverage / delisted / not_applicable)。 存在しない銘柄コード・形式の違う fiscalYear("2026" など)だけが isError で、指定できる候補を返します。

【関連ツール】「○○を分析して」のような総合的な分析には get_stock_analysis が便利です(財務・理想株価・6軸スコア・DCF・業種比較・会社予想を1回でまとめて返します。返したセクションの数ぶん、最大6回分の利用回数を使います)。 このツールは、全年度・内訳・注意事項の全文など、個別の深掘りに向いています。 割安/割高を見る材料は get_edinet_financial_data(財務)・get_ideal_price(理想株価レンジ)・get_stock_score(6軸スコア)・get_dcf_valuation(DCF評価)・get_industry_benchmark(業種比較。codes にその銘柄を渡す)に分かれており、1つだけでは判断材料が偏ることがあります。

カバレッジ: 全上場企業 約3,700社(プライム/スタンダード/グロース)。有報の財務データは多くの会社で約10年分(上場が浅い会社は短い)。 会計基準: JGAAP / IFRS / USGAAP を自動判定して metadata.accountingStandard に記載。 年度の範囲: metrics も fiscalYear も省略すると、fiscalYears は直近2期(最新期と前期)だけを返します(全年度・全指標は応答が大きすぎるため)。全年度が必要なら fiscalYear: "all"、指標を絞るなら metrics を指定してください(metrics 指定時は全年度)。 グラフ: 複数年度を返すとき(直近2期だけの既定も含む)、chartSeries に年ごとの推移(直近10期。売上・利益 / 1株指標 / ROE など。metrics を絞ったときはその指標だけ)を単位ごとのグループで添えます。推移を伝えるときはグラフ(棒・折れ線)にすると分かりやすいです。 株数の変化: 複数年度を返すとき(metrics 指定時を除く)、shareCountChange に株数の5年・10年変化率(%、自己株式を除く発行済株式数・分割調整後。マイナス=自社株買い・消却で減少、プラス=増資等で増加)と、比べた年度・出せないときの理由を添えます(screen_stocks の shareCountChange5y / 10y と同じ値)。 原典トレーサビリティ: 各年度に docId と edinetFilingUrl(EDINET 提出URL)を含む。 FCFの定義差: 本ツールの fcf は「営業CF+投資CF」(簡易FCF)。get_dcf_valuation の baseFCF は「営業CF−設備投資」で別物の指標であり、同じ「FCF」表記でも値が数倍違うことがある(実例: 9434 の2026年3月期は 1,229億円 対 6,485億円)。投資CFには資産売却・M&A・有価証券の取得等の一過性項目が乗るため、DCFでは後者を使う。利用者に説明する際はどちらの定義かを明示すること。金融業(銀行・証券・保険・その他金融)の fcf・fcfMargin は営業CFに顧客預り金・貸出金・保険料などの増減が入るため意味を持たない(値は返すが事業の稼ぐ力としては解釈しないこと)。 株主還元指標の定義差: totalReturnRatio(総還元性向)の分子はCF計算書の配当金支払額(=その期に実際に支払った現金。期末配当が翌期支払いのため実質「前期末配当+当期中間配当」)、payoutRatio(配当性向)の分子はその期に宣言した1株配当。増配企業では前者が構造的に低く出るため、総還元性向が配当性向を下回っていてもデータ不備ではない(該当時は shareholderReturnNote を付与)。 営業収入(operatingRevenue2)の注意: 小売・流通業等で損益計算書に「売上高」(netSales)とは別の行で「営業収入」(テナント収入・加盟店からの収入・不動産賃貸収入等)を載せる会社があり、JGAAPのみ原本に記載があれば operatingRevenue2 として付与します(0にはせず、無ければ省略)。netSalesIncludesOperatingRevenue2 が true の会社では netSales に operatingRevenue2 が既に含まれているため、netSales に operatingRevenue2 を足さないでください(二重計上になります)。false の会社は netSales が売上高のみのため、決算短信の「営業収益」等と比較する場合はnetSales + operatingRevenue2 を使う必要があります。 営業利益率(operatingMargin)の注意: 銀行・証券・保険等の金融業はP/Lに「営業利益」区分が制度上存在せず、原本XBRLのoperatingIncomeには連結タグが無く持株会社の単体値しか入らない。このツール(annual.json直読み)が返すoperatingMarginは金融業でもこの単体値ベースのままのため、金融業の収益性を見る場合はoperatingMarginではなくordinaryMargin(経常利益率=ordinaryIncome/netSales、連結で正しく取得できる)を使うこと。(get_stock_score・edinet-summary.json・銘柄詳細チャートAPIのoperatingMarginは金融業では既にordinaryMarginベースに補正済み(3経路とも共有ヘルパー applyFinancialMarginBasis を使用)。marginBasisフィールドで算出根拠を確認できる。) 経常利益(ordinaryIncome)・経常利益率(ordinaryMargin)の注意: IFRS・米国基準の会社には経常利益の区分が無く、ordinaryIncome には税引前利益が入っています(metadata.accountingStandard が IFRS / USGAAP の会社。数値の意味は変わらず、表示名のみ「税引前利益」と読み替えてください)。 有利子負債の精度: ibdSource フィールドで計算根拠を明示

  • aggregate_tag: IFRS集約タグ採用(最も信頼性高い、例: トヨタ 38.79兆)

  • mixed: IFRS社別拡張タグ + 構成要素合算

  • banking: JGAAP銀行業ロジック(借入金 + 短期社債)

  • component_sum: 集約タグ非開示時の構成要素合算

  • unknown: USGAAP連結XBRL不開示銘柄(interestBearingDebt は null、オリックス等) 広義 ibd(リース込み)は interestBearingDebtBroad、狭義は interestBearingDebt。

会社業績予想(companyForecast フィールド):

  • get_earnings_forecast(period 省略時)と同じ応答を companyForecast に入れます(同じ関数で作るので値は一致します)。

  • 内容: 来期売上・利益予想、来期配当予想、サプライズ判定。予想(forecast・dividend.forecast*)は最新の会社予想 (年度短信より後の四半期短信で通期予想が更新されていればそちら。採った短信は companyForecast.forecastSource)、 実績・前期・サプライズ・配当の実績/前期は直近の年度短信(通期。companyForecast.actualSource)です。 四半期短信から予想を採ったときは companyForecastPeriod(採用したperiod)と companyForecastNote(注意書き)を付与し、 四半期累計の実績は companyForecast.quarterlyCumulative に分けて返します。

  • 1株あたりの値(EPS・配当)は分割後の株数基準にそろえています(調整の根拠は応答直下の splitAdjustment、 検算材料は companyForecast.splitCheck)。

  • 採用した短信より後の「業績予想の修正」「配当予想の修正」開示は、前回予想が短信と一致するときだけ予想に重ねます (get_earnings_forecast・get_ideal_price と同じ値)。重ねたときは companyForecast.revisionOverlay に、重ねた修正と 重ねなかった修正(理由つき)を載せます。companyForecast.disclosedDate は元の短信の開示日のままです。

  • 決算短信が見つからないときは companyForecast 自体を省略します。

  • 四半期の実績・予想を明示的に指定したい場合は get_earnings_forecast(period 指定)が使えます。

  • companyForecast.actual / prior の ordinaryIncomeToTotalAssets は決算短信の 「総資産経常利益率」(経常利益 ÷ 期首期末平均の総資産。IFRS・米国基準は税引前利益ベース)です。 fiscalYears の roa(ROA=純利益 ÷ 期末総資産)とは別の指標なので、ROA とは別の指標です。

  • fiscalYears の roe は決算短信・有報の「自己資本利益率」と同じ値にそろえています(2026-10-10)。 roeBasis: reported = 有報「主要な経営指標等の推移」の記載値(会社の計算。原則 純利益 ÷ 期首・期末平均の自己資本)/ averageEquity = 純利益 ÷ 期首・期末平均の自己資本で計算した値(記載値の無い年度)/ periodEndEquity = 期首の自己資本が無い年度(上場初年度・データ欠け)と、期首の自己資本が0以下(債務超過)の年度の 純利益 ÷ 期末の自己資本。 companyForecast.actual / prior の roe は決算短信の「自己資本当期純利益率」の記載値で、同じ定義です。

配当の内訳(fiscalYears の各年度):

  • dividendPerShare は特別配当・記念配当を含む年間配当の合計(分割調整後)です。

  • ordinaryDividendPerShare(普通配当)・specialDividendPerShare(特別配当・記念配当)は、有報の配当に関する注記・経営指標等の注記、 配当政策の節、期末配当の注記の順に材料を見て決めた値で、dividendPerShare と同じ株数基準です。 summary・screen_stocks の ordinaryDividendPerShare・get_ideal_price の配当価値・get_earnings_forecast の特別配当の補完と同じ関数の値です。

  • specialDividendSource: note(注記)/ policy(配当政策の節)/ note-year-end(期末配当の注記)/ policy+note-year-end(配当政策の中間分と期末配当の注記の合計)/ none(どの材料にも当期の特別配当・記念配当の額の記載が読めなかった。特別配当 0 として扱い、無いことの確認ではない)/ unreadable(記載はあるが額を読めなかった。特別配当が年間配当以上になる額は読み違いとみなしてこれにする)/ conflict(注記と配当政策の節の額が食い違い、配当政策の節の額を使った)/ no-dividend(無配)。

  • specialDividendCompleteness: full は年間の特別配当がそろっている年度、partial は一部の回(期末だけなど)の額しか分からない年度で、 partial の特別配当は実際の年間の額より小さいことがあります。

  • unreadable の年度(と、配当政策の節に額の無い conflict の年度)は specialDividendPerShare が null、ordinaryDividendPerShare は合計と同じ値です。 conflict の年度は specialDividendConflict に各材料の記載どおりの額(分割調整前)が入ります。 特別配当が年間配当以上と読めた年度は specialDividendSuspect にその額(記載どおり)が入り、差し引いていません。

  • summary の consecutiveDividendGrowthYears(連続増配年数)は ordinaryDividendPerShare で数えた年数です。

構造化データ(数値指標に加えて以下が各年度に含まれます。metrics 未指定なら自動付与、 指定する場合はキー名を含めれば取得可能):

  • segments: 報告セグメント別の売上・営業利益・資産(segmentName / sales / operatingIncome / ordinaryIncome / assets)。ordinaryIncomeはセグメント損益を経常利益で開示する企業のみ付与されます(1911住友林業等)。 各行に segmentNameJa(日本語名。有報の XBRL に会社が付けた名前。無い行は要素名からの機械的な訳)・isTotal(true=合計・調整行。個別セグメントではない)・salesShare(構成比%)・operatingMargin(営業利益率%)・salesYoY / operatingIncomeYoY(前期比%)・salesDisplay / operatingIncomeDisplay("1.70兆円" 形式)を添えます。売上はセグメント間の内部売上を含む場合があり、外部顧客への売上だけの値ではありません(segmentsNote 参照)。segments が無い年度は segmentsStatus に理由があります(single = 単一セグメント / notTagged = 有報にセグメント別の数値のタグが無く取得不可)。

  • amountDisplay: 年度ごとの主要な金額(売上・利益・総資産など)の表示用の文字列("1.70兆円")。値そのものは円単位の数値で返ります。

  • directors: 役員一覧(氏名 / 役職 / 任期 / 保有株式数。生年月日は返しません)

  • directorRemunerationBreakdown: 役員報酬カテゴリ別内訳(取締役 / 社外取締役 / 監査役等の人数・固定・賞与・株式報酬・合計)

  • crossShareholdings: 政策保有株式の銘柄別明細(提出会社の特定投資株式。行番号 / 上場区分 / 銘柄名 / 株数 / 簿価 / 相互保有フラグ)

  • crossShareholdingsDeemed: 提出会社のみなし保有株式の銘柄別明細(crossShareholdings と同じ形)。みなし保有株式は退職給付信託などに拠出し、 議決権の指図権だけを持つ株で、自社の貸借対照表には載りません。bookValue は簿価ではなく期末の時価(×株数)です。 crossShareholdingDeemedMarketValueRowsSum はその行の金額(時価)を足し上げた値(有報に合計の記載は無い)です。 みなし保有株式は crossShareholdingTotalBookValue・crossShareholdingIssuesCount(提出会社の特定投資株式などの合計)には入りません。

  • crossShareholdingsHoldingCompanies: 提出会社以外で投資株式の計上額が最大の会社・次に大きい会社(持株会社の子会社など)の明細。 各行に holder(largestHoldingCompany / secondLargestHoldingCompany)と holdingType(specified=特定投資株式 / deemed=みなし保有株式。deemed の bookValue は時価)が付きます。 その会社の名前・合計は crossShareholdingLargestHoldingCompanyName / TotalBookValue / IssuesCount(次に大きい会社は SecondLargest…)で、 有報の記載値(上場+非上場)です。提出会社の合計(crossShareholdingTotalBookValue・crossShareholdingIssuesCount)には入りません。 持株会社は提出会社の明細が空で、こちらにだけ行があることがあります(例: 1414 は最大保有会社のショーボンド建設の15銘柄)。

  • majorShareholders: 有報「大株主の状況」上位10名(順位 / 名 / 住所 / 株数 / 持株比率)。個人株主の氏名は表示しません(name は「個人株主」と表示し、住所は返しません。順位・株数・持株比率はそのまま)

  • foreignShareholdingRatio / individualShareholdingRatio / institutionalShareholdingRatio: 株主構成比

【重要: 株主構成比の単位】majorShareholders[].shareholdingRatio、および foreignShareholdingRatio / individualShareholdingRatio / institutionalShareholdingRatio は すべて 0-1 表記です(例: 0.128 = 12.8%、0.228 = 22.8%)。 同じレスポンス内の roe / equityRatio / operatingMargin 等の財務指標は % 表記(例: 15.2 = 15.2%) であり、株主構成比のフィールドだけ単位が異なります。

  • get_major_shareholders_history は同名フィールド shareholdingRatio を % 表記(例: 12.8 = 12.8%) で返します。本ツールと get_major_shareholders_history の値をそのまま比較・混在させると 100倍の誤読が発生します(0.128 を「0.128%」と読む等)。

  • institutionalShareholdingRatio は「金融機関(信託銀行・保険会社等)」のみの比率です。 証券会社・事業法人(政策保有株主等)は含まれず、一般的な「機関投資家」より狭い定義です。

  • foreign/individual/institutional の3カテゴリは EDINET原本の株主区分のうち一部のみを 集計したものです(政府・地方公共団体、証券会社、その他法人(事業法人)が非集計)。 3カテゴリの合計は 100%(1.0)になりません(例: トヨタでは合計約78%、残り約22%は 事業法人の政策保有等が該当)。「合計が100%にならない=データ欠損」ではなく仕様です。

有報テキストブロック(定性情報。includeTextBlocks 指定時のみ付与・最新年度または fiscalYear 指定期):

  • 事業等のリスク / 経営者による分析(MD&A) / 経営方針 / コーポレートガバナンス / サステナビリティ / 人的資本 / 研究開発 / 関係会社 / 政策保有株式(本文)/ 経理の状況 等 13 カテゴリ

  • 各カテゴリは plainText(HTMLタグ除去済み)。長文(数KB〜数十KB)になることがあるため opt-in 設計

  • 戻り値には availableTextBlocks フィールドが自動付与され、未取得カテゴリが列挙されます。 定性情報は includeTextBlocks を指定して本ツールを呼ぶと取得できます。 例: includeTextBlocks: ["businessRisk", "managementAnalysis"]

関連ツール: 適時開示は get_timely_disclosures、大量保有は get_large_holdings、 スクリーニングは screen_stocks、複数銘柄一覧は list_edinet_stocks。

earningsQuality: 対象年度(fiscalYear 指定時はその期、省略時は最新期)の特別損益による 一過性の純利益歪みを検出したフィールドです(検出時のみ付与)。 earningsQuality.adjustments: normalizedEps(実力EPS)を作るときに足し引きした項目の内訳(label・source・ preTaxAmount・direction・afterTaxAmount・perShare)。当社の試算で、会社の公表値ではありません。 科目名が保存されていない項目は総称(例: 「特別利益(合計)」「営業CF調整(科目名未保存)」)で出します。

応答の metricLabels は英語キー→日本語指標名の対訳です。利用者向けには日本語名(例: roe→「ROE(自己資本利益率)」)のほうが伝わりやすくなります。 データ品質・値の異常・不具合に触れる場合も同様で、フィールド名を示すときは「発行済株式数(sharesOutstanding)」のように日本語を主・英語キーを括弧内にすると読みやすくなります。

splitCheck(分割履歴がある会社のみ): 既定は要約(splits・adjustedFields・conflict)のみ。詳細は includeSplitDetails: true で、1株あたりの値ごとに raw(短信・有報の記載値)・adjusted(使った値)・factor・basis・method と、検算の材料(純利益÷EPSで逆算した株数と分割前の株数の比)を載せます。adjusted が検算と食い違う(conflict: true 等)ときは raw を基に判断してください。

有価証券報告書の訂正(amendments・correctedFrom。訂正報告書が出た年度のみ。metrics 指定時はキー名を含めれば取得可能):

  • amendments がある年度は、訂正報告書の値を反映済みです。

  • amendments は提出順の訂正の記録です(docId・amendsDocId=訂正対象の原本・disclosedDate・numberOfSubmission・fields=直前の版から値が変わった項目。[] は値の変わらない本文だけの訂正、null は直前の版と比較できなかったことを示します)。

  • correctedFrom は原本(最初の有報)の値で、訂正後と値が違う項目だけを載せます(原本に値が無かった項目は null、{} は値の変わらない訂正)。原本を取得できなかった年度には付きません。

  • correctedFrom の1株あたりの値・株数(eps・dilutedEps・bps・dividendPerShare・dividendInterim・dividendYearEnd・sharesOutstanding・treasuryShares)と配当性向・DOE・配当利回りは、同じ年度の訂正後の値と同じ係数で分割調整済みです。訂正前後の値はそのまま比べられます(splitCheck の raw は訂正後の記載値で、correctedFrom は含みません)。

  • treasuryShares の定義: 有報の「自己株式等」欄の値で、提出会社名義の自己株式だけです。連結子会社(従業員向けの信託・財団等)が保有する自社株は含みません。決算短信・JQuants の自己株式数(連結。子会社保有分を含む)とはその分だけ差が出ます(実例 3659: 有報 34,253,200株・短信 35,753,527株、差は子会社保有の 1,500,327株)。

  • numberOfSubmission の欠番は、途中の訂正が記録に無いことを示します(その回の fields は分かりません)。

応答の watchlistSuggestion は、この銘柄が利用者の監視リストに未登録のときだけ付く欄で、追加できるか(canAdd)・追加用のツール名(addTool)・監視の件数(watchlistCount)と上限(watchlistLimit。null は上限なし)を持ちます。上限に達しているときは canAdd が false で reason が limit-reached です。

※ 本データは情報提供を目的とし、投資助言・推奨ではありません。

NameRequiredDescriptionDefault
codeYes証券コード(例: 7203)
metricsNo取得する指標名の配列(省略時は全指標を返します。fiscalYear も省略すると直近2期だけ返します)。日本語名や略語(例: 「PER」「自己資本比率」)は内部で英語キーに正規化されますが、原則は英語キー推奨。【主要指標の日本語対応】per(PER / priceEarningsRatio), pbr(PBR / priceBookValueRatio), roe(ROE / 自己資本利益率), roa(ROA), equityRatio(自己資本比率), operatingMargin(営業利益率), dividendYield(配当利回り), payoutRatio(配当性向), doe(DOE / 株主資本配当率), fcf(簡易フリーCF=営業CF+投資CF。DCFのbaseFCFとは別定義), ebitda(EBITDA), marketCap(時価総額), netCash(ネットキャッシュ), salesGrowth(売上成長率)。【利用可能な全指標】[P/L] netSales, operatingRevenue2(営業収入。テナント収入・加盟店からの収入・不動産賃貸収入等。JGAAPのみ、原本に無ければ省略), netSalesIncludesOperatingRevenue2(netSalesに既にoperatingRevenue2が含まれているか。true=合計行のため足すと二重計上、false=netSalesは売上高のみで含まない。operatingRevenue2がある年度のみ付与), operatingIncome, ordinaryIncome, netIncome, costOfGoodsSold, grossProfit, sellingGeneralAndAdministrative, incomeBeforeIncomeTaxes, nonOperatingIncome, nonOperatingExpenses, extraordinaryIncome, extraordinaryLoss, incomeTaxes, comprehensiveIncome [B/S] totalAssets, netAssets, equity, retainedEarnings, currentAssets, currentLiabilities, noncurrentAssets, noncurrentLiabilities, totalLiabilities, capitalStock, capitalSurplus, cashAndDeposits, marketableSecurities, investmentSecurities, shortTermBorrowings, currentPortionOfLongTermDebt, longTermDebt, bondsPayable, currentPortionOfBonds, commercialPapers, accountsReceivable, inventories, accountsPayable, propertyPlantAndEquipment, goodwill, intangibleAssets(日本基準はのれんを含む無形固定資産合計、国際会計基準はのれんを含まない。intangibleAssetsIncludesGoodwill=true の年度はのれんを含む), land, buildingsAndStructures, nonControllingInterests, deferredTaxAssets, deferredTaxLiabilities, retirementBenefitLiability, leaseObligations, accumulatedOCI [C/F] cashFlowFromOperations, cashFlowFromInvesting, cashFlowFromFinancing, cashAndEquivalents, capitalExpenditure(設備投資。原則はCF計算書の有形+無形の取得、CF計算書から取れない年度は有報の注記(capexSource=note)。投資不動産の取得を含むと分かった年度は capexIncludesInvestmentProperty=true が付く。付かなくても行名が「有形固定資産及び投資不動産の取得」の会社(2120・2811・5411・9158 等)は投資不動産を含む), depreciationAndAmortization, dividendsPaid, purchaseOfTreasuryShares, proceedsFromDisposalOfTreasuryShares, proceedsFromBorrowings, repaymentOfBorrowings, incomeTaxesPaid [1株] eps, bps, dividendPerShare(特別配当・記念配当を含む合計), ordinaryDividendPerShare(普通配当), specialDividendPerShare(特別配当・記念配当), specialDividendSource, specialDividendCompleteness, dilutedEps [バリュエーション] per, pbr, priceEarningsRatio, priceBookValueRatio, dividendYield [株式] sharesOutstanding, treasuryShares [識別/原典] docId, edinetFilingUrl [その他] numberOfEmployees(連結を作る会社は連結の人数), researchAndDevelopment, interestExpense, accountingStandard [計算指標] roe, roa, operatingMargin, ordinaryMargin(経常利益率。金融業ではoperatingMarginの代わりにこちらを参照), netProfitMargin, grossProfitMargin, equityRatio, currentRatio, payoutRatio, doe, fcf, netCash, interestBearingDebt, interestBearingDebtBroad, ibdSource, debtToEquityRatio, operatingCFMargin, fcfMargin, accrualRatio, dso, dio, dpo, cashConversionCycle, assetTurnover, ebitda, ebitdaMargin, sgaRatio, interestCoverageRatio, rdRatio, capexRatio, salesPerEmployee, operatingIncomePerEmployee, operatingCFToDebt, retainedEarningsRatio, goodwillRatio, effectiveTaxRate, totalShareholderReturn, totalReturnRatio, netDebt, netDebtToEbitda, tangibleEquity, tangibleEquityRatio [構造化データ] segments(セグメント別売上・営業利益・経常利益・資産), directors(役員一覧), directorRemunerationBreakdown(役員報酬カテゴリ別), crossShareholdings(政策保有株式銘柄別明細), crossShareholdingTotalBookValue, crossShareholdingIssuesCount, crossShareholdingsDeemed(提出会社のみなし保有株式の明細。金額は時価), crossShareholdingDeemedMarketValueRowsSum(みなし保有株式の時価の行の足し上げ), crossShareholdingsHoldingCompanies(最大保有会社・次に大きい会社の明細), crossShareholdingLargestHoldingCompanyName, crossShareholdingLargestHoldingCompanyTotalBookValue, crossShareholdingLargestHoldingCompanyIssuesCount, crossShareholdingSecondLargestHoldingCompanyName, crossShareholdingSecondLargestHoldingCompanyTotalBookValue, crossShareholdingSecondLargestHoldingCompanyIssuesCount, majorShareholders(大株主上位10名), foreignShareholdingRatio, individualShareholdingRatio, institutionalShareholdingRatio [従業員の状況(提出会社。2019年3月期以降の有報)] avgAnnualSalary(平均年間給与・円。提出会社(単体)の従業員の平均で、賞与・基準外賃金を含む。連結の従業員の平均ではない), avgAgeYears(平均年齢・歳。提出会社の従業員), avgTenureYears(平均勤続年数・年。提出会社の従業員), numberOfEmployeesNonConsolidated(提出会社(単体)の従業員数・人。臨時従業員を含まない), parentPayrollEstimate(本体の人件費のめやす・円=avgAnnualSalary×numberOfEmployeesNonConsolidated。臨時従業員・法定福利費・退職給付費用・役員報酬は含まず、損益計算書の人件費とは一致しない。avgAnnualSalary を連結の numberOfEmployees と掛けないこと(子会社の人数まで本体の給与水準で数えて膨らむ)。出さない年度は parentPayrollEstimateUnavailableReason:holding_company=持株会社(有報の事業の内容に特定上場会社等と記載。本社部門の人件費で事業の人件費を表さない)/parent_headcount_tiny=提出会社の従業員数が連結の1%未満/no_parent_employees=提出会社の従業員数の合計が有報に無い/holding_status_unknown=持株会社かを未判定), avgAnnualSalaryUnavailable(out_of_range=有報の平均年間給与の数値が150万〜5,000万円の範囲外で、桁の付け間違いとみなして avgAnnualSalary に入れていない。原本の値は avgAnnualSalaryAsFiled)
fiscalYearNo特定の決算期末日(YYYY-MM-DD)を指定。"all" で全年度。省略時は、metrics も省略していれば直近2期(最新期と前期)、metrics を指定していれば全年度
excludeForecastNo会社業績予想(companyForecast)を含めない場合 true。デフォルトは false(含める)。
includeTextBlocksNo指定した有報テキストブロック(plainText)を併せて返します。指定省略時は付与しません(レスポンスサイズ抑制のため)。複数指定可。返却対象は fiscalYear で指定した年度(省略時は最新年度)のみ。利用可能カテゴリ: businessRisk(事業等のリスク), managementAnalysis(経営者による分析・MD&A), managementPolicy(経営方針・経営環境), corporateGovernance(コーポレートガバナンス), compensation(役員の報酬等・本文), relatedParty(関係会社等), subsidiaries(子会社等), segments(セグメント情報・本文), humanCapital(人的資本・多様性), sustainability(サステナビリティ), crossShareholdings(政策保有株式・本文), researchAndDevelopment(研究開発活動), financialNotes(経理の状況・注記)。
includeSplitDetailsNo省略可(既定 false)。true で分割の検算の詳細(splitCheck の items・evidence・howToVerify、splitAdjustment の reason 全文)を返します。既定では splitCheck は要約(splits・adjustedFields・conflict)のみ。検算の食い違い(conflict)があるときは、false でも詳細を返します。数値は変わりません。

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint and openWorldHint annotations, the description discloses extensive behavior: coverage of about 3,700 listed companies, roughly 10 years of data, accounting-standard detection, default fiscal-year truncation, chartSeries and shareCountChange behavior, FCF definition differences, financial-industry margin caveats, dividend definition caveats, amendment handling, and opt-in text blocks. These details prevent common misinterpretations and are not present in the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose and related-tool routing, then organized under clear headings for coverage, accounting standards, dividends, structured data, and amendments. It is very long, but most detail is relevant for a complex financial-data tool; some end-user presentation guidance and repeated caveats could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, six parameters, rich schema, and absence of an output schema, the description is exceptionally complete. It explains return shapes, non-error no-data states, output field semantics, caveats, and alternatives, leaving little an agent would need to infer before calling it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the input schema already documents code, metrics, fiscalYear, excludeForecast, includeTextBlocks, and includeSplitDetails in detail. The description reinforces interactions such as metrics plus fiscalYear determining whether all years are returned, but most of this duplicates the schema rather than adding new parameter meaning, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a specific verb and resource: retrieve annual financial data based on EDINET securities reports by stock code, and it notes that company earnings forecasts are returned simultaneously. It explicitly distinguishes this tool from get_stock_analysis and other valuation tools, so an agent can identify its role without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit routing guidance: use get_stock_analysis for comprehensive analysis, and use this tool for full-year data, breakdowns, and detailed notes. It also describes alternative tools for valuation components and clearly explains when missing data returns a non-error hasData:false response versus when invalid input triggers isError.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_ideal_price理想株価A
Read-only
Inspect

銘柄コードを指定して、ラジ株ナビ独自の理想株価モデル(Mark 3.2 乗算型)を取得します。 株主優待は評価に含めません(優待制度がある銘柄には caveats で知らせます)。

【関連ツール】「○○を分析して」のような総合的な分析には get_stock_analysis が便利です(財務・理想株価・6軸スコア・DCF・業種比較・会社予想を1回でまとめて返します。返したセクションの数ぶん、最大6回分の利用回数を使います)。 このツールは、全年度・内訳・注意事項の全文など、個別の深掘りに向いています。 割安/割高を見る材料は get_edinet_financial_data(財務)・get_ideal_price(理想株価レンジ)・get_stock_score(6軸スコア)・get_dcf_valuation(DCF評価)・get_industry_benchmark(業種比較。codes にその銘柄を渡す)に分かれており、1つだけでは判断材料が偏ることがあります。

モデル概要: 資産価値は下値(low)と超過現金評価に分離 / 事業価値は実効倍率25倍キャップ / 成長価値はgrowth係数連動(最大60%)/ EPSアンカーは会社予想優先 (減益予想は素直に採用・2倍超の増額予想のみ幾何平均で緩和。forward_12m・ttm の12か月 EPS にも同じガード)。 下値 = BPS × 割引評価率(資産価値)、 中央値 = 事業価値 + 超過現金価値(余剰現金のみ、資産のフル加算はしない) + 配当プレミアム (資産価値の7割を下回るときは資産価値の7割まで下支え。資産価値の7割〜資産価値の間なら下支えせず、mid < low になる)、 上値 = 中央値 + 成長価値(事業価値のうち growth 係数に応じた一部、最大60%)。

返却フィールド:

  • low / mid / high: 理想株価レンジ(下値 / 中央値 / 上値)

  • assetValue / businessValue / growthValue / dividendValue: 内訳 (低 = 資産価値)

  • dividendValue(配当プレミアム)= 1株配当 × 8。1株配当は会社予想の年間配当(決算短信の注記・配当予想の修正開示から特別配当・記念配当の額が読めた分は除く。 読めたかどうかは get_earnings_forecast の forecastSpecialSource)、予想を使わないときは最新期の実績の普通配当 (特別配当・記念配当を除いた額。get_edinet_financial_data の ordinaryDividendPerShare・summary の dividendYield3y と同じ値)。

  • growthValueBasis: 成長価値の根拠。直近3期(成長期間2年)の実績のEPS・売上CAGR(epsCagr / salesCagr。始点・終点の年度と値、years=年数、points=期数)の ブレンドで決まります。実績が3期そろわない系列(上場直後で2期しか無い・途中の年度が欠けているなど、成長期間1年以下)は CAGR を測らず (epsCagr / salesCagr は null、理由は epsCagrUnavailableReason / salesCagrUnavailableReason。1年の伸びは参考として理由の文に書きます)、 EPS・売上とも測れなければ成長価値0(insufficientPeriods=true、理由は growthValueUnavailableReason と caveats)。thresholds.minPoints=必要な期数。 ブレンドが4%以下で成長価値0、20%以上で上限。epsCagr の startValue / endValue は一過性損益を除いた試算EPS(一過性が無い年度は公表EPSのまま)で、 始点・終点とも同じ規則です。同じ年度の公表EPSは startReportedEps / endReportedEps、除いたかどうかは startOneOffAdjusted / endOneOffAdjusted。 get_industry_benchmark 等の epsCagr3y(3期前→最新期の3年)とは期間が違います。 会社予想は成長価値に使いません。予想の増減益は epsAnchor(epsSource=forecast)経由で事業価値・中央値に反映済みです (growthValue が0でも「予想の増益が無視されている」わけではありません)。

  • effectiveMultiple: 適用後の実効倍率(業種PER×ROA係数×レバ補正×qg係数。25倍キャップ後の値)

  • rawEffectiveMultiple: キャップ前の実効倍率(業種PER×ROA係数×レバ補正×qg係数の生の積)。 25を超えていれば effectiveMultiple は25にキャップされ businessValue もスケールダウンされています。

  • effectiveMultipleCapped: true の場合、実効倍率が25倍キャップに達しており、 事業価値(businessValue)は収益力(rawEffectiveMultiple)に対して頭打ちになっています。 rawEffectiveMultiple と併せて確認してください。

  • excessCashValue: 超過現金価値(円/株。mid の資産価値相当項)= max(max(netCash,0) × 親会社の取り分 ÷ (発行済株式数−自己株式数) − 差し引く特別配当, 0) × 割引評価率(discount)。 netCash は連結の値で子会社の外部株主(非支配株主)の現金も含むため、親会社の株主の取り分だけを数えます (取り分は get_dcf_valuation の equityBridge.parentShare と同じ決め方: 直近5期の利益の比(条件を満たす期が3期以上のとき)。使えなければ持分の比)。 差し引く特別配当は、期末日の貸借対照表の後に払う特別配当・記念配当(yearEndSpecialDividend と specialDividendAfterBs の合計)。 中間配当に含まれる特別配当は期末より前に払い済みなので差し引きません。 netCash は清原式(現金及び預金+有価証券(流動)+投資有価証券×70%−有利子負債、最新決算期末の有報)。 無借金でも預り金など会社のものではない現金が多い会社(預り金系の負債が netCash 候補値の1/3以上。決済代行・収納代行など)は netCash を出さず、超過現金は 0 になります(excessCashBreakdown.zeroReason に理由)。

  • excessCashBreakdown: excessCashValue の内訳。fiscalYearEnd(netCash・株数を取った決算期末)/ netCash / netCashDefinition / netCashComponents(現金・有価証券・投資有価証券・有利子負債。足し引きが netCash と一致する場合のみ)/ sharesOutstanding・treasuryShares・effectiveShares / parentShare・nonControllingShare・parentShareBasis・parentShareBasisNote(親会社の取り分と決め方)/ excessCashPerShare(取り分を掛けた、特別配当を引く前の円/株)/ specialDividendDeducted(差し引いた特別配当の合計)・specialDividendDeductedBreakdown(latestYearEnd / forecastAfterBalanceSheet)/ discount・equityRatioPct・discountTable / formula / recomputedExcessCashValue・reconciles(内訳から出し直した値と excessCashValue の一致)/ zeroReason(0 のときの理由)。

  • specialDividendAfterBs: 決算期末の後に払う予想の特別配当(短信の配当の注記から読み取り)を、 下値・超過現金から差し引いた場合のみ付く。amount=差し引いた円/株、comparisonPrice= alphaPct・verdict の比較に使った株価(pseudoPrice − amount。pseudoPrice 自体は期末の株価のまま)。

  • yearEndSpecialDividend: 最新決算期の期末配当に含まれる特別配当・記念配当(有報の配当政策に期末分として書かれた額。無ければ配当に関する注記の「基準日が当期に属する配当のうち、配当の効力発生日が翌期となるもの」に書かれた額)を、 下値・超過現金から差し引いた場合のみ付く。期末配当は期末日の貸借対照表の後に払うため BPS・ネットキャッシュに含まれている。 amount=差し引いた円/株(分割調整後)、rawAmount=有報の記載値、fiscalYearEnd、source(dividend-policy=配当政策 / dividend-notes=配当に関する注記)、splitScale。 擬似株価(期末日の終値)は期末配当の権利落ち後の株価なので、alphaPct・verdict の比較株価からは引きません。 有報に期末分の内訳が書かれていない会社では、期末配当に特別配当が含まれていても差し引いていません。

  • pseudoPriceFreshness: 擬似現価の鮮度。fresh(3ヶ月以内) / aging(4〜6) / stale(7〜12) / obsolete(13ヶ月超)。擬似現価は決算発表時点の株価なので、経過が長いほど実株価と 乖離し α値(割安度)が実態とズレます。stale/obsolete では現在の株価と 直接比較してください(実例: 8037 カメイは判定「超割安」だが実株価は中央値超え)。

  • dataBasis: どの時点の値を使ったか。financialsFiscalYearEnd(財務=有報の最新期)/ pseudoPriceFiscalYearEnd / epsAnchorForecastFiscalYearEnd(epsAnchor に使った会社予想の期。予想を使っていなければ null)/ newerAnnualTanshin(有報より新しい年度短信の期末・開示日。有報の提出待ちのあいだだけ入る)/ note。 newerAnnualTanshin があるとき、財務と擬似株価は1期前の有報の値です(短信には期末の株価が無く擬似株価は更新できません)。 shareBasis: 下値の BPS に使った株数・BPS の組(asOf・source=yuho/annual_tanshin/q1〜q3・発行済・自己株・BPS)。 有報の期末より新しい短信があれば、その組を使います(会社予想の EPS と1株の基準をそろえるため)。 擬似株価・超過現金は有報の期末の値なので、有報の期末の株数(shareBasis.fiscalYearEnd)のままです。 shareBasis.latestShareCount: その組の基準日より後の、自己株式の取得結果・消却完了のお知らせで確かめた株数(株数だけ)。 株数が5%以上変わったとき(確かめられなかったときは verified=false)shareBasis.pendingShareChange と caveats で知らせます。 BPS・会社予想の EPS・理想株価の値は割り直していません(新しい株数の短信・有報が届くと置き換わります)。

  • forecastPeriodNotUsed: 会社予想の対象期間が12か月でない(決算期変更の経過期間など)ため、予想を epsAnchor・ 配当プレミアムに使わず実績にしたときだけ付きます(months・短信の予想 EPS・年間配当。年換算していない値)。

  • epsSource: 事業価値に採用したEPSの根拠(forecast=会社予想 / normalized=一過性損益除外の試算実績 / blended=予想と実績の乖離が大きい場合の幾何平均 / actual=生EPS。予想も正規化も無い場合 / ttm=直近12か月EPS。予想も正規化も無く、最新の四半期短信(または有報より先に出た翌期の年度短信)から出せた場合。内訳は ttmEps / forward_12m=通期の会社予想が無く、累計期間の会社予想(第1・第3四半期累計・上期)を12か月に組んだ場合。内訳は forwardTwelveMonth) 優先順位: 通期の会社予想 > forward_12m > ttm > 実績(normalized / actual)。

  • forwardTwelveMonth: epsSource=forward_12m のときのみ。netIncome(12か月の純利益 = 最新期の実績 + 今期の累計予想 − 前期の同じ累計の実績)/ eps(netIncome ÷ shares)/ epsAnchor・guard(通期の会社予想と同じ非対称ガード。blended=実績の2倍超で幾何平均)/ periodStart・periodEnd(12か月の期間)/ forecastMonths(うち予想の月数)/ shares・sharesBasis(ttmEps と同じ)/ sources(latest_fiscal_year_actual・cumulative_forecast・prior_cumulative_actual の各値と出どころの短信)。 四半期の進捗の判定(forecastProgressBehind)はこの値には掛けません。 12か月に入る一過性損益(最新期の normalizedEps と同じ規則の特別損益。前期の同じ累計に入っていた分は引き算で消えるので除かない)は 除いた値が netIncome・eps で、公表の純利益の足し引きは reportedNetIncome・reportedEps、内訳は oneOffAdjustment (status: adjusted / none / fy_normalization_withheld / current_period_unknown・afterTaxOneOff・items)。ttmEps も同じ(reportedTtmNetIncome)。

  • forwardTwelveMonthNotUsed: 累計の会社予想はあるが12か月に組まなかったときの理由(reason: prior_actual_not_found / range_only / no_net_income / not_following_latest_fiscal_year / period_mismatch / latest_fiscal_year_irregular / forecast_period_irregular / non_common_income_unknown / actual_unavailable / one_off_not_allocatable / one_off_prior_period_unknown) と累計の範囲・期間。このとき epsSource は ttm 等のまま(one_off_* は一過性を除いた実績 normalized のまま)。

  • ttmEps: epsSource=ttm のときのみ(全プランで返す)。eps(直近12か月EPS。ガード前)/ latestFiscalYearEps(最新期の実績EPS)/ epsAnchor・guard(通期の会社予想・forwardTwelveMonth と同じ非対称ガード。blended=最新期の実績の2倍超で幾何平均)/ source(quarterly=最新期の純利益+今期の四半期累計−前期の同期累計 / annual_tanshin=有報より先に出た 翌期の年度短信の通期純利益)/ quarterPeriod・periodEnd・disclosedDate(使った短信)/ ttmNetIncome / shares・sharesBasis(recent_period_end=使った短信の期末の発行済−自己株(分割調整後)。期中の増資・自社株買いを反映 / eps_implied=最新期の期中平均株数=純利益÷EPS。有報の純資産÷BPS と期末の発行済−自己株が25%超違う会社(種類株式等)・ 短信に株数が無い会社・期末〜開示日の5日後に分割があり短信が反映済みか判断できない会社 / period_end=最新期末の発行済−自己株)。eps = (ttmNetIncome − nonCommonIncomeDeducted) ÷ shares。 ttmNetIncome は親会社株主に帰属する利益で、その他の資本性金融商品(ハイブリッド資本)や優先株の取り分を含む。 nonCommonIncomeDeducted は短信の「純利益 − EPS×期中平均株式数」から求めた普通株主に帰属しない分で、 使う短信すべてに期中平均株式数があるときだけ差し引く(無い項目は差し引いていない)

  • epsAnchor: 事業価値の基数として実際に採用したEPS値

  • forecastEps: 入力に使われた会社予想EPS(参考値。予想が無ければ null)

  • verdict: 5段階判定(超割安 / 割安 / 適正 / 割高 / 超割高)。擬似現価(pseudoPrice)が 理想株価レンジ(low/mid/high)のどこに位置するかで決まり、alphaPct(中央値との差の%) とは別の物差しです。レンジの帯の幅(high-mid、mid-low)は銘柄ごとに異なるため、 alphaPct が同程度でも verdict が異なることがあります。ただし、上側の幅(high-mid)が狭い・無いとき、 下側の幅が無いとき(mid が low 以下)は、中央値の27%を判定の幅の下限にします(low/mid/high の値は変えません)。 上側の幅が27%より狭い銘柄は上側を27%として、mid が low 以下の銘柄は下側に上側と同じ幅(27%以上)を当てて判定し、 上下とも幅が無い銘柄(mid = high かつ mid ≦ low)は中央値の ±27% を仮の上限・下限にして5段階で判定します (小さな差で「超割高」「超割安」にならず、大きく離れれば「超」が付くようにするため)。 mid が low より上の銘柄の下側は low(資産価値)までの幅をそのまま使い、low を下回れば超割安です。鮮度(pseudoPriceFreshness) による判定の格下げは行っていません(aging/stale/obsoleteでもverdictの決め方自体は同じ)。

  • verdictBasis: pseudoPriceFreshness が aging 以上(決算期末から4ヶ月超)のときのみ、 「何年何月末時点の擬似株価と比較した判定か」を明記します。fresh のときは null。 bpsFloorApplied=true で verdict があるとき(割高・超割高)は、資産価値の7割を基準にした判定である旨も先頭に入ります。

  • verdictBasisType: bpsFloorApplied=true で verdict があるとき(割高・超割高だけ)"asset_floor"。判定は資産価値の7割(下支え)との 比較で決まっており、事業価値ベースの中央値(rawMid)はそれより低いため、利益から見るとさらに割高寄りです(caveats の先頭にも同じ注意書き)。

  • bpsFloorApplied: true の場合、中央値(mid)は事業価値・配当プレミアムではなく 資産価値の7割(下支え。mid = low × 0.7)にクランプされています。事業価値等の合計が資産価値の7割を 下回ったケースで、事業価値の成長性を反映していません。判定が割安・超割安・適正になるときは利益で説明できないため verdict・alphaPct・upperAlphaPct(currentPrice の verdictAtCurrentPrice・alphaPctAtCurrentPrice も同じ規則)を null にし、 verdictUnavailableReason="asset_floor_only" と caveats で理由を返します。割高・超割高は判定を出し、verdictBasisType="asset_floor" が付きます (事業価値ベースの中央値 rawMid は資産価値の7割より低いので、利益から見るとさらに割高寄り)。false でも、事業価値等の合計が資産価値の7割以上・ 資産価値未満の会社は mid < low(理論株価が資産価値より低い)になります。 rawMid(クランプ前の中央値)と併せて確認してください。

  • forecastMayIncludeOneOff: true の場合、epsAnchor は会社予想EPS(epsSource=forecast) または予想と実績(正規化後)の幾何平均(epsSource=blended)で、同じ会社の実績では 一過性損益が検出されている。会社予想に特別利益が含まれていても短信XBRLには 予想側の特別損益タグが無く検出できないため、理論株価が一過性で 膨らんでいる可能性を考慮して読んでください。

  • 今期予想の純利益が予想経常利益を上回り、epsAnchor が会社予想由来(forecast / blended)の会社は、 caveats に「今期予想に一度きりの利益が含まれている可能性」を出します(値・判定は変えません。forecastMayIncludeOneOff より広い目印)。

  • forecastProgressBehind: true の場合、epsAnchor は会社予想EPSだが、 直近四半期(q1/q2/q3のいずれか、採用元短信)の累計営業利益の進捗(通期計画比)が、 一律の目安(25/50/75%)の6割に届かず、前年同期比で減益。さらに前年同期の進捗(前年同期の累計営業利益÷前期の通期)が 取れる会社は、その6割にも届かず差が5ポイント以上のときだけ立てます(期末に偏る会社が例年どおり低い進捗で立たないように)。 前年同期の材料が無い会社は一律の目安だけで判定します。会社予想に対して実績が 逆行している可能性があり、下方修正リスクを考慮して読んでください。

  • rawMid: 下支え前の中央値(参考値)。bpsFloorApplied が true のときのみ mid と異なる値になります(false の場合は mid と同値)。

  • alphaPct: (mid - pseudoPrice) / pseudoPrice × 100 (+ なら擬似現価が理論株価より低い = 割安方向)。 specialDividendAfterBs がある銘柄では pseudoPrice の代わりに specialDividendAfterBs.comparisonPrice (pseudoPrice − 期末後に払う特別配当)で計算します(upperAlphaPct・verdict も同じ)。

  • upperAlphaPct: (high - pseudoPrice) / pseudoPrice × 100

  • pseudoPrice: 最新 actual PER × EPS の擬似現価(リアルタイム株価ではない。生EPSで算出、正規化しない)

  • pseudoPriceSource: pseudoPrice の算出根拠。per_eps=通常のPER×EPS / tsr_backsolved=赤字等でPER×EPSが算出不能な年度に限り、有報の株主総利回り(TSR)5年推移表から 決算時株価を逆算したフォールバック(実測誤差: 赤字等で実際に使われた170社・2026-10時点で中央値0.09%・最大3.4%)/ tsr_backsolved_extended=従来のTSR逆算で値が出ない会社に限り、5年前(TSR表の基準年度)の株価も候補に加え、PER×EPS が無い年度の株価をその年度までのTSR逆算値で1段だけ代替した予備経路(バックテスト誤差: 中央値0.15%・p95 1.89%・10%超0.4%) / per_eps_nonconsolidated=上の3つがどれも出ない会社に限り、有報の提出会社(単体)の PER × 単体の EPS(連結が赤字で連結の PER が空欄の会社など。株価は連結・単体で同じ。連結の PER×EPS との一致度は、両方ある会社で中央値0.08%・p99 1.57%。この経路で値が出る12社では期末の終値との差が10社で0.25%以内、5026は+7.29%・9219は+9.87%(原本の単体 PER 自体が期末とは別の日の株価で計算されているため)。同じ有報の当期の最高・最低株価の範囲内のときだけ使う) / null=算出不能。

  • pseudoPriceTsrOffsetsUsed: pseudoPriceSource が tsr_backsolved / tsr_backsolved_extended のときのみ、 株価の値の算出に使った「何年前の有報か」(1〜4。tsr_backsolved_extended では5=5年前も)の一覧(複数なら中央値)。

  • pseudoPriceTsrChainedOffsets: tsr_backsolved_extended で、PER×EPS が無い年度の株価をその年度までの TSR逆算値で代替した(連鎖した)オフセットの一覧。連鎖を使っていなければ省略。 1つだけのときは、分割をまたがない候補が1つしかなく、分割をまたぐ候補との5%以内の一致で確認した値。

  • pseudoPriceFiscalYearEnd: pseudoPrice の算出根拠となった決算期末日(YYYY-MM-DD)。 決算発表から日数が経つほど、実際の市場株価と pseudoPrice の乖離は拡大しうる。 alphaPct / verdict はこの決算期時点の判定で、決算発表から半年以上経っている場合はα値の信頼性が下がります。

  • currentPrice 引数を渡した場合のみ、以下が追加されます: verdictAtCurrentPrice(currentPriceを理想株価レンジと比較し直した5段階判定)、 alphaPctAtCurrentPrice((mid - currentPrice) / currentPrice × 100)、 currentPriceSource(常に "user-provided")。 verdict / alphaPct(pseudoPrice基準)はcurrentPriceを渡しても変更されません。

  • discount / leverageAdj / roaCoef / qgCoef / quality / growth / roaApprox / jpxPerUsed: 計算過程

  • jpxPerUsed: 事業価値に掛けた業種PER(上限15倍)。名前は互換のため残していますが、JPX の公表値ではなく、ラジ株ナビが有報から計算した業種の加重平均 PER(各社の PER を純利益で重み付けした平均。1社の重みは業種の純利益の2割まで(超えた分は他社に配り直さない)。プライム・スタンダード・グロースの黒字の会社。時価総額は決算期末の株価=有報の PER×EPS から復元)に上限15倍をかけた値です。

  • sectorPerBasis: その業種PERの出どころ。source=own_weighted(上の自前の値)/ market_fallback(対象5社未満の業種・「その他」・表が読めないときに使う予備値。全業種まとめた同じ式の加重平均 PER=ラジ株ナビが有報から計算した全社の値。fallbackPerBasis=market_weighted(計算に使った summary の全社の値)/ snapshot(表が無いときの、過去に測った全社の値)、fallbackReason=予備値にした理由)。raw=上限前の値、companies=対象社数、basisSummaryGeneratedAt=計算に使った summary の時点。weightCapShare=1社の重みの上限(0.2=業種の純利益の2割まで)、weightCapApplied=この業種で上限が効いたか(1社が業種の純利益の2割を超える業種。例: 情報・通信業の 9984)、uncappedPer=上限をかける前の値(時価総額の合計 ÷ 純利益の合計)。

  • earningsQuality: 一過性損益(特別利益・特別損失)の検出結果(検出時のみ含む) earningsQuality.adjustments は normalizedEps を作るときに足し引きした項目の内訳(label・source・preTaxAmount・direction・afterTaxAmount・perShare)。 当社の試算で、会社の公表値ではありません(科目名が保存されていない項目は「特別利益(合計)」など総称)。

  • excludedDividendDecisions(newerDisclosureWarning / newerDisclosureCheck 内)は、「剰余金の配当」 (配当の決定)のうち、採用した短信の期末の次の四半期末より前に出たため短信に載っている実績配当の 決定とみなし、修正の候補から外した開示です(特別配当・方針変更・基準日設定などを含む表題は外しません)。

  • dividendForecastSource が含まれる場合、配当価値の基礎の予想配当を予想EPSと別の決算短信から読んだ(fromOtherDisclosure: true。配当予想は最新の予想年度で開示日が最も新しい短信から読む)か、年間が空欄のため中間(実績または予想)+期末の予想で組んだ(composedFrom に内訳と分割後の値)ことを示します。

  • revisionOverlay が含まれる場合、採用した決算短信より後の「業績予想の修正」「配当予想の修正」開示を 予想に重ねています(修正開示の前回予想が短信の予想と全項目一致するときだけ。通期の修正は予想EPS、 配当の修正は配当価値の基礎の予想配当に入ります。get_earnings_forecast と同じ値)。earnings は予想EPSの短信、 dividend は予想配当の短信について、applied(重ねた修正の tdnetId・開示日・対象期間・修正前後)、 skipped(重ねなかった修正と理由)、asOfDate(重ねた後の予想の基準日)を示します。特別配当・記念配当を含む配当の修正は、 本文から金額を読めたときは forecastSpecial に入れて配当価値から除きます。読めないときも年間の合計は重ね、 配当価値は修正前に確かめられていた普通配当で出し、dividendValueBasis(basis: pre_revision_ordinary・value・reason・修正の tdnetId)に出どころを載せます。

  • newerDisclosureWarning が含まれる場合、採用した決算短信より後に「配当予想の修正」「業績予想の修正」等の 適時開示が出ていて、forecastEps・dividendValue にまだ全部は反映していません(前回予想が短信と一致しない・ 未定への修正・特別配当の金額が読めないなど。理由は revisionOverlay.skipped。一部でも重ねなかった開示は残ります)。 該当開示は get_timely_disclosures で確認できます。 disclosures[].parsedNumbers が付いている場合、その開示のXBRLから修正前後の 数値(previous/current、増減率)を取り込み済みです(数値は決算短信本体ほど検証されていないため、 重要な判断にはPDF本文で裏取りしてください)。 reflectedRevisionIds は、見つかった修正開示のうち、すべてを予想に重ねたので警告から外した開示です。

  • newerDisclosureCheck は上の検出処理が実際にどこまで確認できたかを示します。 status:unverifiable は「修正が無い」ことを意味しません(reason参照)。 status:partially-checked なら、確定した範囲(checkedFrom〜checkedTo)では修正は見つかりませんでしたが、 unconfirmedDates の日は開示一覧がまだ確定していません(やのしんは夕方以降の開示を翌営業日の午後に足すことがあり、 取り直しは営業日の 15:03 と 19:00 JST。翌日以降の取り直しで、取り元の一覧と件数・最後の開示時刻(15:00 より後)まで一致すると確かめられた日は、翌営業日を待たずに確定とします。確かめられるまで未確定)。この日の修正の有無は不明で、 「修正は無い」とは言えません(note 参照)。

  • caveats: モデルの前提・データ制約に関する断り書きの配列(該当するものだけ含む)。 金融業での注意・blended採用時の一過性懸念・変則決算の年換算根拠など、状況に応じて追加されます。

注意:

  • earningsQuality.oneOffDetected が true でも、epsSource が forecast/normalized/blended なら 事業価値のEPSは既に正規化・予想ベースに補正済みです(Mark 3.0 の過大評価を修正)。 epsSource が actual の場合のみ、normalizedEps / normalizedPer を追加で確認してください。

  • pseudoPrice は最新決算時の PER × 生EPS で算出した擬似現価であり、 リアルタイムの市場株価ではありません(決算時株価の復元のため常に生EPSを使用)。

  • BPS / EPS が不足している場合は算出不可(null)となります。

  • 最新期の BPS・EPS が過去の年度と桁違いの株数基準で書かれている会社(splits.json に記録の無い株式併合。 上場廃止後のスクイーズアウト等)は、low / mid / high・pseudoPrice・verdict を null にし、 unavailableReason="share_basis_break" と shareBasisBreak(latestFiscalYearEnd・latestImpliedShares・ comparedFiscalYearEnd・comparedImpliedShares・ratio。株数は純資産÷BPS・純利益÷EPS から逆算)・caveats で理由を返します。

  • verdict / alphaPct は pseudoPrice が取得できない場合は null になります。

  • 金融4業種(銀行業・保険業・証券・商品先物取引業・その他金融業)は、ROA が構造的に低く本モデルが合わないため、 verdict・alphaPct・upperAlphaPct(currentPrice を渡したときの verdictAtCurrentPrice・alphaPctAtCurrentPrice も)を null にし、 verdictUnavailableReason="financial_sector" と caveats で理由を返します。low / mid / high・内訳・pseudoPrice は参考値として返します。 金融業以外でも、金融事業のセグメントの資産、または割賦売掛金・営業貸付金・リース債権が総資産の30%以上の会社(get_dcf_valuation が乖離率を出さない会社と同じ判定)は、 値と判定はそのまま返し、caveats の先頭で「ROA係数が低く出やすく、判定が割高寄りに出ることがある」と断ります。

  • 有報の最新期より新しい年度の決算短信が出ていて有報がまだ提出されていない会社は、比べる擬似株価が最新の確定決算より 1期古いため、verdict・alphaPct・upperAlphaPct を null にし、verdictUnavailableReason="newer_annual_tanshin_pending_yuho" と caveats で理由を返します。currentPrice を渡せば verdictAtCurrentPrice・alphaPctAtCurrentPrice は返します。有報が提出されると判定を再開します。

  • 中央値が下支え(資産価値の7割)で決まっている会社(bpsFloorApplied=true。事業価値等から求めた中央値 rawMid が資産価値の7割未満)で、 判定が割安・超割安・適正になるときは、下支えで押し上げた中央値との比較で利益で説明できないため、verdict・alphaPct・upperAlphaPct を null にし、 verdictUnavailableReason="asset_floor_only" と caveats で理由を返します。low / mid / high・rawMid は参考値です。割高・超割高は判定を出します。 currentPrice を渡したときも同じ規則で、その株価で割高・超割高なら verdictAtCurrentPrice・alphaPctAtCurrentPrice を返し、割安・超割安・適正なら null です。 「資産価値より株価が低いから割安」とは言えない銘柄です。理由は金融業 > asset_floor_only > 有報待ち の順に1つだけ入ります。

  • verdict / alphaPct は決算時点の擬似現価(pseudoPrice)ベースの判定です。

  • 本モデルはラジ株ナビ独自の算出値であり、投資助言・推奨ではありません。

関連ツール: 財務の詳細は get_edinet_financial_data、スコアは get_stock_score。

応答の metricLabels は英語キー→日本語指標名の対訳です。利用者向けには日本語名(例: roe→「ROE(自己資本利益率)」)のほうが伝わりやすくなります。 データ品質・値の異常・不具合に触れる場合も同様で、フィールド名を示すときは「発行済株式数(sharesOutstanding)」のように日本語を主・英語キーを括弧内にすると読みやすくなります。

splitCheck(分割履歴がある会社のみ): 既定は要約(splits・adjustedFields・conflict)のみ。詳細は includeSplitDetails: true で、1株あたりの値ごとに raw(短信・有報の記載値)・adjusted(使った値)・factor・basis・method と、検算の材料(純利益÷EPSで逆算した株数と分割前の株数の比)を載せます。adjusted が検算と食い違う(conflict: true 等)ときは raw を基に判断してください。

応答の watchlistSuggestion は、この銘柄が利用者の監視リストに未登録のときだけ付く欄で、追加できるか(canAdd)・追加用のツール名(addTool)・監視の件数(watchlistCount)と上限(watchlistLimit。null は上限なし)を持ちます。上限に達しているときは canAdd が false で reason が limit-reached です。

※ 本データは情報提供を目的とし、投資助言・推奨ではありません。

NameRequiredDescriptionDefault
codeYes証券コード(例: 7203)
currentPriceNo省略可。利用者自身が確認した現在の株価。本サービスは株価を提供しないため、利用者が別途調べた値を渡してください。渡した場合、その株価を理想株価レンジと比較し直した verdictAtCurrentPrice / alphaPctAtCurrentPrice を追加で返します(既存の verdict / alphaPct は pseudoPrice 基準のまま変更されません)。
includeSplitDetailsNo省略可(既定 false)。true で分割の検算の詳細(splitCheck の items・evidence・howToVerify、splitAdjustment の reason 全文)を返します。既定では splitCheck は要約(splits・adjustedFields・conflict)のみ。検算の食い違い(conflict)があるときは、false でも詳細を返します。数値は変わりません。

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint/openWorldHint=false; the description goes far beyond by disclosing that verdict/alphaPct are nulled for financial sectors, asset-floor-clamped names, and yuho-pending tickers, that pseudoPrice is a fiscal-year-end reconstruction with a freshness rating, and that EPS can be forecast-contaminated. The lack of any note on rate limits, latency, or cost for this specific call is the main gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and sibling routing come first, but they are followed by an enormous field-by-field data dictionary that dwarfs them and makes the routing guidance easy to miss. Much of it is necessary in the absence of an output schema, yet the density and minimal sectioning (one flat bullet list) badly hurt scannability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the full burden and does so exhaustively: every returned field, the fallback chains for pseudoPrice, the EPS source priority order, the null-verdict conditions and their precedence, and the caveats array. An agent can interpret essentially any response value from this text alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and both optional parameters (currentPrice, includeSplitDetails) are already fully documented in the schema, including that existing verdict/alphaPct are unchanged. The description restates splitCheck detail behavior but adds no new parameter semantics, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening states a specific verb and resource: retrieve the proprietary '理想株価' model (Mark 3.2 乗算型) for a given 銘柄コード. It also names the sibling get_stock_analysis as the aggregate alternative and lists the other valuation siblings (get_dcf_valuation, get_stock_score, get_industry_benchmark), so an agent can place it precisely.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit routing guidance: use get_stock_analysis for '○○を分析して'-style requests (noting it consumes up to 6 uses), and use this tool for per-field depth such as all fiscal years, breakdowns, and full caveats. It also warns that one valuation tool alone biases judgment. The guidance is solid but buried inside a very long block, and no guidance is given on when this tool is unnecessary if the aggregate call already covered it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_industry_benchmark業種ベンチマークA
Read-only
Inspect

東証33業種ごとの指標の中央値・四分位(25%/75%)と、指定した会社の業種内の順位・位置を返します。 「この会社の ROE は同業の中でどのあたりか」を1回の呼び出しで知るためのツールです。 銘柄の総合分析(「○○を分析して」)には get_stock_analysis が便利です(業種比較の要点=主要7指標の業種の中央値と順位を含みます)。このツールは、22指標・四分位・複数社の比較まで見るときに向いています。割安/割高の判断材料は get_edinet_financial_data・get_ideal_price・get_stock_score・get_dcf_valuation にもあります。

使い方:

  • codes に銘柄コードを渡す: 各社の所属業種を自動で判定し、その業種の分布と、会社ごとの値・順位・位置を返す。

  • sector に業種名だけを渡す(codes なし): その業種の分布だけを返す(例: 情報・通信業。中黒の全角/半角どちらでも可)。

  • metrics で見る指標を絞れる(省略時は下の全指標)。

対象指標: roe, roa, operatingMargin, salesGrowth, equityRatio, per, pbr, dividendYield, payoutRatio, roic, netProfitMargin, grossProfitMargin, debtToEquityRatio, currentRatio, assetTurnover, doe, operatingIncomeGrowth, netIncomeGrowth, epsGrowth, salesCagr3y, operatingIncomeCagr3y, epsCagr3y(いずれも最新年度の値)。

  • 収益性: roe, roa, roic(投下資本利益率), operatingMargin(営業利益率), netProfitMargin(純利益率), grossProfitMargin(粗利率)

  • 安全性: equityRatio(自己資本比率), debtToEquityRatio(D/Eレシオ), currentRatio(流動比率)

  • 効率: assetTurnover(総資産回転率)

  • 成長: salesGrowth(売上高), operatingIncomeGrowth(営業利益), netIncomeGrowth(純利益), epsGrowth(EPS)。いずれも前期比 salesCagr3y(売上高), operatingIncomeCagr3y(営業利益), epsCagr3y(EPS・分割調整後)。いずれも3年平均成長率(CAGR)=(最新期÷3期前)^(1/3)−1

  • 還元・評価: payoutRatio(配当性向), doe(株主資本配当率), dividendYield(配当利回り), per, pbr 単位は %、per / pbr は倍、assetTurnover は回。

返す内容:

  • sectors[]: 業種ごとの companyCount(業種の会社数)と、指標ごとの n(有効社数)・median(中央値)・p25 / p75(四分位)・min / max。

  • companies[]: 会社ごとに value(その会社の値)・rank(業種内の降順順位。1=業種で最も値が大きい)・of(順位の母数)・ percentile(0-100。業種内で値が小さい側から数えた位置。90なら業種の上位10%の大きさ)・diffFromMedian(中央値との差)。

  • rank / percentile は「値の大きさの順」です。PER・PBR のように低いほうが割安とされる指標でも、 大きいほど rank が小さくなります。良し悪しの判定ではありません(順位がそのまま優劣を表すわけではありません)。

外れ値・欠損の扱い:

  • 中央値・四分位は外れ値に強い順位統計です。極端な値で中央値は動きません(min / max は外れ値も含むため参考値)。

  • 値が取れない(null)会社は母集団から外し、n に含めません。

  • 赤字などで per / pbr が 0 以下・算出不能の会社、配当性向がマイナスの会社は母集団から除外します(ただし指定した会社自身の value は参考として返し、note に理由を付けます)。

  • n が 5 未満の指標は smallSample=true の参考値です。

  • 金融業(銀行業・保険業・証券・商品先物取引業・その他金融業)は営業利益率・売上高成長率・ROIC・純利益率・粗利率・D/Eレシオ・流動比率・総資産回転率・営業利益成長率・売上高と営業利益の3年平均成長率が 業種内でも定義が揃わない(または開示されない)ため計算せず、excludedMetrics に理由を返します。ROE・ROA・自己資本比率・DOE・純利益成長率・EPS成長率などは業種内の比較として有効です。

  • 成長率は前期の値が小さい・赤字だった会社で数千%以上になることがあります(中央値・四分位は影響を受けにくい一方、min / max は参考値)。

  • 3年平均成長率(〜Cagr3y)は3期前と最新期の値がともにプラスの会社だけで計算します(赤字をまたぐ会社・3期前の決算が無い会社・決算期変更で12か月×3にならない会社は null で母集団に入りません)。IFRS 移行をまたぐ場合は移行前の値を IFRS 組替値の比で連結して比べます。

  • D/Eレシオは有利子負債÷自己資本、DOE は一株配当÷一株純資産です。債務超過などでマイナスの会社は母集団から除外します。

  • 業種内にはIFRS・米国基準・日本基準の会社が混在します(営業利益などの定義が会社により異なる)。

  • oneOffSuspected: true の会社は特別損益で純利益が嵩上げされている可能性があり、ROE・PER・配当性向などに影響します。

データの基準:

  • per / pbr / dividendYield は決算時点の擬似株価(有報の XBRL から復元できる値)ベースで、現在の市場株価ではありません。 配当利回りは有報の当期確定実績ベースで、来期の予想ではありません。

  • 業種は東証33業種(summary の sector)。ETF・REIT 等は含みません。

※このツールは codes に指定した銘柄数ぶん利用回数を使います(同じコードの重複は1件にまとめます。最大 10 回。業種だけの指定・1銘柄なら1回)。

応答の metricLabels は英語キー→日本語指標名の対訳です。利用者向けには日本語名(例: roe→「ROE(自己資本利益率)」)のほうが伝わりやすくなります。 データ品質・値の異常・不具合に触れる場合も同様で、フィールド名を示すときは「発行済株式数(sharesOutstanding)」のように日本語を主・英語キーを括弧内にすると読みやすくなります。

※ 本データは情報提供を目的とし、投資助言・推奨ではありません。

NameRequiredDescriptionDefault
codesNo銘柄コードの配列(最大10件。例: ["7203", "6758"])。同じコードは1件にまとめ、件数ぶん利用回数を使います。
sectorNo業種名(例: 電気機器)。codes を指定しない場合のみ使えます。
metricsNo見たい指標の英語キー(省略時は全指標)。使える指標: roe, roa, operatingMargin, salesGrowth, equityRatio, per, pbr, dividendYield, payoutRatio, roic, netProfitMargin, grossProfitMargin, debtToEquityRatio, currentRatio, assetTurnover, doe, operatingIncomeGrowth, netIncomeGrowth, epsGrowth, salesCagr3y, operatingIncomeCagr3y, epsCagr3y

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark it readOnly and closed-world, but the description adds a large amount of context beyond them: usage-count cost (one call per code, max 10, duplicates collapsed), outlier/missing handling, financial-industry metric exclusions, small-sample flags, and the crucial disclosure that PER/PBR/dividendYield are XBRL-derived pseudo prices, not current market prices. This is exactly the behavioral disclosure annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and routing are front-loaded in the first three lines, followed by usage, metric list, return shape, data-quality caveats and pricing basis. It is long, but for a tool with heavy statistical caveats and no output schema nearly every block earns its place; the data-quality section is verbose enough to cost a point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description fully carries the burden: it documents sectors[] and companies[] fields (value, rank, of, percentile, diffFromMedian), the direction of rank/percentile, and the metricLabels translation key. Nothing needed to interpret results correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; however the description genuinely enriches the parameters by explaining that codes auto-detects each company's industry, that sector is only usable without codes, and by enumerating the 22 metric keys with Japanese names, category groupings and units (%, times, turns). This goes beyond the raw schema strings, though it largely mirrors the metric list already in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a precise verb+resource+scope: returns median/quartiles for TSE 33 industries plus a given company's rank/position within its industry. It explicitly differentiates from get_stock_analysis (overall analysis) and names the other valuation siblings, so an agent can place it without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states explicit operating modes (codes for company+industry, sector alone for distribution only), names the alternative get_stock_analysis and the condition that selects it, and routes valuation questions to get_edinet_financial_data / get_ideal_price / get_stock_score / get_dcf_valuation. When-to-use and when-not-to-use are both covered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_investor_portfolio投資家のポートフォリオA
Read-only
Inspect

有価証券報告書『大株主の状況』から構築した投資家→保有銘柄の逆引き検索。 アクティビスト(村上系ファンド・オアシス・エフィッシモ等)は名寄せ済み。 個人株主の氏名は表示しません(個人の投資家は一覧・検索の対象外。銘柄ごとの大株主では「個人株主」と表示)。

isNew=true は前年度の大株主リストに不在(新規登場)。changePt は保有比率の前年差。

【重要: shareholdingRatio の単位】holdings[].shareholdingRatio / prevShareholdingRatio は % 表記です(例: 12.8 = 12.8%)。changePt もポイント差(%表記同士の差分)です。

  • get_edinet_financial_data の majorShareholders[].shareholdingRatio や foreignShareholdingRatio 等は同名に見えても 0-1 表記(例: 0.128 = 12.8%)です。 本ツールの値と get_edinet_financial_data の値は単位が異なります(そのまま比べると100倍ずれます)。

注意: データは各銘柄の最新有報時点のスナップショット(年1回更新)。直近の5%ルール変動は get_large_holdings を使用。 大株主上位10名に載る保有が対象。名前が大株主に無い場合は大量保有報告書(5%ルール)の提出者(法人のみ)からも検索する。

表記(全角/半角スペース・中黒)や外国法人の法人格(エルエルシー・インク・リミテッド・LLC・Inc.・Ltd. 等)の違いだけの提出者は、同じ投資家として1件にまとめて返します (元の提出者名は submitterNames)。「株式会社」「有限会社」の日本法人は、コーポレーション・カンパニー等の有無で別会社になりうるためまとめません。

候補が複数に絞れないときは candidates(名前一覧)に加え、保有銘柄数の多い上位3候補の保有銘柄を candidateDetails で返します。

使用例: 『村上系が持っている銘柄は?』→ name: "村上"

応答の metricLabels は英語キー→日本語指標名の対訳です。利用者向けには日本語名(例: shareholdingRatio→「持株比率」)のほうが伝わりやすくなります。 データ品質・値の異常・不具合に触れる場合も同様で、フィールド名を示すときは「発行済株式数(sharesOutstanding)」のように日本語を主・英語キーを括弧内にすると読みやすくなります。

※ 本データは情報提供を目的とし、投資助言・推奨ではありません。

NameRequiredDescriptionDefault
nameNo投資家名(部分一致)。省略すると保有銘柄数上位の投資家一覧を返します。
limitNo返す件数の上限(デフォルト: 20、最大: 100)

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnlyHint, openWorldHint=false), and the description adds substantial context on top: yearly snapshot freshness, name-normalization/merger behavior (submitterNames, corporate-suffix handling), individual-investor exclusion, and the candidates/candidateDetails fallback when the name is ambiguous. The unit warning (shareholdingRatio is % here vs 0–1 in get_edinet_financial_data) is a genuinely valuable cross-tool gotcha.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded and the body is organized with bolded caveats. It is long, and a few lines (metricLabels Japanese-preferred naming, the advisory disclaimer) are style guidance rather than tool-selection content, but almost every sentence carries operational value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description carries the return-value burden and does so thoroughly: it explains isNew, changePt, shareholdingRatio units, metricLabels, submitterNames and the candidates/candidateDetails shape. An agent has everything needed to call and interpret this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%: both 'name' (partial match, optional) and 'limit' (default 20, max 100) are already documented in the schema. The description adds only an example invocation for 'name' and no detail about 'limit', so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource and scope: a reverse-lookup of investor→held stocks built from the 'major shareholders' section of annual securities reports, with activists pre-aggregated. It also names its boundaries against siblings (get_edinet_financial_data, get_large_holdings, get_major_shareholders_history), so an agent can distinguish it without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states what is in and out of scope (individual shareholders excluded), when the data is stale (yearly snapshot) and which sibling to use instead for recent 5% rule changes (get_large_holdings). It even supplies a concrete example query ('村上'), removing guesswork about invocation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_large_holdings大量保有A
Read-only
Inspect

大量保有報告書(5%ルール)のデータを取得します。 会社名(issuerName)は会社名の索引の現在の社名です。報告書に書かれていた名前が現在の社名と異なるときだけ issuerNameAsFiled に元の表記を付けます(旧社名のままの報告書がある)。companyNameIndexAsOf は索引の作成時刻です。 日付指定で当日のイベント一覧、または銘柄コード指定でその銘柄の大量保有履歴を取得できます。

データソース: EDINET 大量保有報告書(docType 350/370)。 カバレッジ: 2021-06 以降の全提出を日次バッチで取得・名寄せ済み(投資家ベース)。 取得項目: 保有者名(名寄せ後)・銘柄コード・保有比率・変動比率・取得資金・保有目的・提出日。

該当が無いとき(5%超の保有者がいない銘柄・休日・未取り込みの日)はエラー(isError)にせず、{ hasData: false, status, reason, events: [] } で返します。 status: no_filings=提出がもともと無い(休日・報告なし)/ not_yet_disclosed=翌日の朝の取り込み前 / possible_intake_delay=営業日なのに無い(取り込みの遅れの可能性)/ out_of_coverage=取り込み範囲より前 / delisted・not_applicable=上場廃止・ETF/REIT。存在しない銘柄コード・形式の不正な日付だけが isError です。

各イベントは以下を含みます:

  • holdingRatio: 今回の保有比率(%)

  • previousRatio: 変更前の保有比率(%)。新規保有(初回の5%超)では null

  • docId / sourceUrl: EDINET 提出書類の原典リンク

  • filingDate: 提出日 / triggerDate: 報告義務発生日(code 指定時のみ)

code 指定時の既定: 提出日の新しい順に直近 20 件(totalCount は全件数、returnedCount は返した件数)、保有目的(purpose)は先頭 80 文字+「…」(purposeTruncated: true)に短縮します。 全件・全文が必要なときは limit(件数。最大 500)と includeFullPurpose: true を指定してください。date 指定・未指定(直近7日)の一覧は、既定で最大 500 件まで(totalCount は全件数、returnedCount は返した件数)を返し、limit は適用しません。

関連ツール: 投資家ベースのポートフォリオは /investors ページ、 銘柄ベースの保有変動は本ツール(code 指定)、財務データは get_edinet_financial_data。

応答の metricLabels は英語キー→日本語指標名の対訳です。利用者向けには日本語名(例: holdingRatio→「保有比率」)のほうが伝わりやすくなります。 データ品質・値の異常・不具合に触れる場合も同様で、フィールド名を示すときは「発行済株式数(sharesOutstanding)」のように日本語を主・英語キーを括弧内にすると読みやすくなります。

※ 本データは情報提供を目的とし、投資助言・推奨ではありません。

NameRequiredDescriptionDefault
codeNo証券コード(例: 7203)。指定すると銘柄別の大量保有履歴を返します。
dateNo日付(YYYY-MM-DD)。指定するとその日の大量保有イベント一覧を返します。省略時は直近7日分を検索。
limitNo省略可。code 指定時に返すイベント数(提出日の新しい順)。既定 20、最大 500。totalCount は常に全件数。
includeFullPurposeNo省略可(既定 false)。true で保有目的(purpose)を全文で返します。既定は先頭 80 文字+「…」(purposeTruncated: true)。

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the readOnly/openWorld annotations: coverage start (2021-06, daily batch, investor name-matching), the crucial fact that absence of data returns { hasData: false, status, reason, events: [] } rather than an error, the enumerated status values, and that only malformed input produces isError. The only meaningful gap is return-size behavior for a single event list, which is partially covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded and clearly sectioned (purpose, source, coverage, fields, empty-result contract, defaults, related tools). It is long, however, and some trailing material — the metricLabels localization guidance, the Japanese-first field-naming instruction, and the disclaimer — is presentation guidance rather than a property of this tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema, the description fully documents the response envelope (hasData/status/reason/events), the fields of each event (holdingRatio, previousRatio, docId/sourceUrl, filingDate, triggerDate), and the conditions under which each appears. An agent could select and format the call correctly without further information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the baseline is 3; the description raises it by clarifying a subtlety the schema only hints at, namely that limit is ignored and a 500 cap applies in date mode while code mode defaults to 20. It also explains totalCount/returnedCount and the truncation behavior tied to includeFullPurpose, though these largely restate the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: retrieve 大量保有報告書 (5% rule) data from EDINET docType 350/370, with two operating modes (date-based event list vs. code-based history). It also explicitly distinguishes itself from siblings by naming get_investor_portfolio (investor-based) and get_edinet_financial_data (financials).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use which mode (date for a day's events, code for a stock's filing history), what the defaults are in each (20 vs. up-to-500, limit not applied in date mode), and routes to alternatives by name for investor-based portfolios and financials. Exclusions are also spelled out via the status codes for out-of-coverage and delisted cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_main_customers主要な販売先A
Read-only
Inspect

有価証券報告書の「主要な顧客ごとの情報」(連結売上高の10%以上を占める販売先)を返します。1回の呼び出しで次のどちらか一方を指定します。

  1. code を指定: その会社の主要な販売先(顧客名・金額・売上高に占める割合・関連セグメント)。

  2. customer を指定: その販売先に売っている会社の一覧(逆引き)。 customer が証券コード(例: 7203)なら、販売先を上場会社に名寄せした結果を返します(例: 「トヨタ自動車に売っている上場会社」)。 customer が社名の一部(例: アマゾン)なら、上場していない販売先も含めて全社の販売先名を部分一致で探します。

【重要: 開示の範囲】開示対象は売上高の10%以上を占める販売先だけです(会社によっては10%未満も載せます)。 そのため「載っていない」は取引がないことを意味しません。status で区別してください: listed=販売先の記載あり / none=「10%以上の販売先はない」旨の記載 / noBlock=記載なし / text=文章のみ(原本で確認)/ unparsed=読み取り失敗。 全上場企業のうち販売先を表で開示しているのは約4割、「該当なし」が約6割です(2026-10 時点の最新有報)。 逆引きは「社名が完全一致で名寄せできた」ものが対象です。表記違い・子会社宛て・非上場の販売先は証券コード指定の結果に出ません。 customerMatch=group は「○○グループ」宛てで、その会社単体への販売とは限りません。

金額は円(amountYen)。外貨建ての表は円に直さず amountRaw に原文の単位つきで返します。 salesSharePct は金額÷その期の連結売上高で当社が計算した値、ratioPct は有報に記載されていた割合です。 個人の販売先の氏名は表示しません(name は「個人(氏名は表示しません)」)。

関連ツール: 会社の財務は get_edinet_financial_data、大株主は get_major_shareholders_history。

応答の metricLabels は英語キー→日本語指標名の対訳です。利用者向けには日本語名(例: salesSharePct→「売上高に占める割合」)のほうが伝わりやすくなります。 データ品質・値の異常・不具合に触れる場合も同様で、フィールド名を示すときは「発行済株式数(sharesOutstanding)」のように日本語を主・英語キーを括弧内にすると読みやすくなります。

※ 本データは情報提供を目的とし、投資助言・推奨ではありません。

NameRequiredDescriptionDefault
codeNo証券コード(例: 6902)。その会社の主要な販売先を返します。customer とは同時に指定できません。
limitNo逆引きで返す会社数の上限(デフォルト: 30、最大: 100)
customerNo販売先の証券コード(例: 7203)または社名の一部(例: アマゾン)。その販売先に売っている会社を返します。code とは同時に指定できません。

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint and openWorldHint. The description adds substantial, non-obvious behavior: the 10%-threshold disclosure limit, that absence does not mean no transaction, enumerated status values, ~40%/60% coverage statistics, reverse-lookup matching caveats, and name masking for individuals. This is exactly the context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and scope are front-loaded, and most of the length is substantive caveat content. The trailing metricLabels/Japanese-rendering guidance and disclaimer are useful but tangential to tool selection, so it is slightly longer than strictly necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description fully documents the return surface: status values, amountYen/amountRaw, salesSharePct vs ratioPct, customerMatch, and name masking. Nothing an agent needs to interpret results is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description meaningfully extends parameter semantics: customer as a securities code triggers name-matched listed-company results, whereas a name fragment does partial matching including unlisted sellers, and limit governs the reverse lookup. It adds real routing nuance beyond the schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource (有価証券報告書の「主要な顧客ごとの情報」) and the exact filter (連結売上高の10%以上), then distinguishes its two operating modes. It names sibling tools (get_edinet_financial_data, get_major_shareholders_history) so an agent can route without opening other schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use each mode: code returns a company's customers, customer performs a reverse lookup. It further splits customer into code vs name semantics and names the related tools for adjacent needs, leaving little to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_major_shareholders_history大株主の推移A
Read-only
Inspect

銘柄コードを指定して、有価証券報告書「大株主の状況」上位10名の時系列を取得します。 過去最大10年分の決算期末日ごとに、上位株主の持株数・持株比率を返します。

返却値: years 配列。各要素は { fiscalYearEnd, shareholders: [{ rank, name, sharesHeld, shareholdingRatio }] }。

  • shareholdingRatio は % 表記(例: 12.93 = 12.93%)。 ※ get_edinet_financial_data の majorShareholders は 0-1 表記で、本ツールとは単位が異なります。

用途: 安定株主構成の経年変化、信託銀行(インデックス)保有比率の推移、 持株会・取引先など事業上の関係株主の増減トレンド分析。

注意: 有報ベースの決算期末スナップショット。5%ルールの大量保有報告書(変更が早い)とは別データ。 個人株主の氏名は表示しません(name は「個人株主」と表示。順位・持株数・持株比率はそのまま)。

関連ツール: 大量保有報告書は get_large_holdings、最新1期のみで良ければ get_edinet_financial_data の majorShareholders。

応答の metricLabels は英語キー→日本語指標名の対訳です。利用者向けには日本語名(例: shareholdingRatio→「持株比率」)のほうが伝わりやすくなります。 データ品質・値の異常・不具合に触れる場合も同様で、フィールド名を示すときは「発行済株式数(sharesOutstanding)」のように日本語を主・英語キーを括弧内にすると読みやすくなります。

※ 本データは情報提供を目的とし、投資助言・推奨ではありません。

NameRequiredDescriptionDefault
codeYes証券コード(例: 4665)
fiscalYearNo特定の決算期末日(YYYY-MM-DD)に絞り込み。省略時は全年度。

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint/openWorldHint, so the description carries real additional burden and meets it: data source is a fiscal-year-end snapshot from 有報 (not the faster 5% rule filings), individual holders' names are suppressed (name='個人株主'), and there is an explicit unit mismatch versus get_edinet_financial_data's 0-1 ratio. These are exactly the behavioral caveats an agent needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with 返却値/用途/注意/関連ツール headers and the core purpose front-loaded, but it bloats with generic boilerplate about metricLabels and Japanese-vs-English field naming — including an example field (sharesOutstanding) that is not even part of this tool — plus an investment disclaimer. Several sentences do not earn their place for this specific tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description must describe the return shape and does so precisely: a `years` array whose elements are { fiscalYearEnd, shareholders: [{ rank, name, sharesHeld, shareholdingRatio }] }, plus the unit convention for shareholdingRatio. Nothing needed to call or interpret the result is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents `code` and `fiscalYear`. The description reinforces the code's role and the year dimension (全年度 vs 決算期末日絞り込み) but adds no syntax or format detail beyond the schema, making the baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (取得) and resource (有価証券報告書「大株主の状況」上位10名の時系列), with the scope (過去最大10年分の決算期末日ごと) made explicit. It also names the sibling concept it differs from (get_edinet_financial_data の majorShareholders / get_large_holdings), so an agent can distinguish it without opening other schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 用途 section names concrete scenarios (安定株主構成の経年変化, 信託銀行保有比率の推移), and 関連ツール explicitly routes to alternatives: get_large_holdings for 大量保有報告書 and get_edinet_financial_data for the latest single period. When-to-use and when-to-prefer-alternatives are both covered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_stock_analysis銘柄の総合分析A
Read-only
Inspect

1回の呼び出しで銘柄の全体像を返します。「○○を分析して」のような総合的な分析に向いています。 個別の深掘りには各ツール(get_edinet_financial_data・get_ideal_price・get_stock_score・get_dcf_valuation・get_industry_benchmark・get_earnings_forecast)があります。

セクション(sections[]。各セクションに詳しく見るための個別ツール名 detailTool を添えます):

  1. financials: 財務。直近5期の売上・営業利益・経常利益・純利益・EPS・BPS・1株配当・配当性向・ROE・自己資本比率・営業CF・簡易FCF と、一過性損益の注記(earningsQuality。adjustments は normalizedEps を作るときに足し引きした項目の内訳で、当社の試算であり会社の公表値ではない)。推移は chartSeries(単位ごとのグラフ用の系列)でも返す 【グラフ】financials の chartSeries は年ごとの推移(売上・利益 / 1株指標 / ROE)です。グラフ(棒・折れ線)にすると推移が分かりやすくなります。

  2. idealPrice: 理想株価。low / mid / high・verdict・alphaPct・verdictBasis・擬似株価など

  3. stockScore: 6軸スコア(割安度・稼ぐ力・成長性・安全性・還元力・事業独占力)と注記

  4. industryBenchmark: 業種比較。ROE・営業利益率・自己資本比率・PER・PBR・配当利回り・売上成長率の、業種の中央値と業種内の順位

  5. earningsForecast: 会社予想・進捗。今期予想・進捗率(四半期累計÷通期予想)・最新の業績/配当修正の修正前後(決算短信と同じ日に出た修正も含む)

  6. dcf: DCF。乖離率・主要な前提(WACC・永続成長率・ベースFCF・成長率)。算出できない会社は status: "unavailable" とその理由

値は各個別ツールを呼んだときと同じです(同じ処理をそのまま呼んで要約しています)。注意事項(caveats)は文の区切りで先頭だけに縮めています。 理想株価・DCF の先頭の priceDateNote に、判定・乖離率がいつの株価(決算期末の擬似株価)との比較かを書きます(判定はこの時点のものです)。 有報の文章(事業等のリスクなど)・直近の適時開示・大株主や大量保有・主要な販売先は含みません。 総合分析のあと、利用者が「もっと深掘りして」と言えば、それらを個別ツールで追加で調べられます(使えるツールは応答の followUp.deepDiveTools に載せます)。

【利用回数】返したセクションの数だけ使います(1回の呼び出しで最大6回分)。 データを返せなかったセクション(status: "unavailable"。個別ツールのエラーのほか、DCF を算出できない会社のように値が無く理由だけのセクションも含む)は数えません。使った回数は応答の usage に書きます。 今日の残りが足りないときは、残りに収まる数のセクションだけを(上の番号の順に)返してその数だけ使い、返さなかったセクションは usage.withheld に挙げます(取得し直す方法と、回数の多いプランがあることを usage.withheldNote に書きます)。 上場廃止・ETF・REIT・存在しないコードは分析せず、その理由と search_stocks の案内を返します(0回。利用回数は使いません)。

currentPrice に利用者自身が確認した株価を渡すと、理想株価(verdictAtCurrentPrice・alphaPctAtCurrentPrice)・DCF(gapPercentAtCurrentPrice)・6軸スコアをその株価でも判定します(各個別ツールの currentPrice と同じ意味)。 currentPrice を渡さない場合の株価は決算期末時点の擬似株価(有報の PER×EPS 等から復元)で、現在の市場株価ではありません。

応答の watchlistSuggestion は、この銘柄が利用者の監視リストに未登録のときだけ付く欄で、追加できるか(canAdd)・追加用のツール名(addTool)・監視の件数(watchlistCount)と上限(watchlistLimit。null は上限なし)を持ちます。上限に達しているときは canAdd が false で reason が limit-reached です。 followUp は、深掘りに使える個別ツール(deepDiveTools。code 入りの呼び方)と、全部使ったときの最大の利用回数(deepDiveMaxUsage)だけの欄です。

※ 本データは情報提供を目的とし、投資助言・推奨ではありません。

NameRequiredDescriptionDefault
codeYes証券コード(例: 7203、140A。全角や「7203.T」も可)
currentPriceNo利用者自身が確認した現在の株価(円)。渡すと理想株価・DCF・6軸スコアをその株価でも判定します(任意)。

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

アノテーション(readOnlyHint=true / openWorldHint=false)を超えて、消費回数の仕組み(最大6回、unavailable は非計上、残数不足時は usage.withheld に列挙)、priceDateNote による判定基準時点、currentPrice 未指定時は決算期末の擬似株価であること、watchlistSuggestion の付与条件と上限、followUp の内容まで開示している。

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

冒頭で目的を述べ、以降をセクション番号・【】見出しで構造化しており、front-load はできている。ただし financials の項目列挙やグラフ化の助言など、やや冗長な記述も含み、output schema がない事情を考慮しても圧縮余地はある。

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

output schema が無い中で、返却セクションの内容・値の由来(個別ツールと同じ処理)・caveats の扱い・usage/watchlistSuggestion/followUp の各欄の意味まで説明されており、6セクションを束ねる複合ツールとして必要な情報が揃っている。

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

schema の description カバレッジは100%で、code の形式(全角・7203.T 可)はスキーマ側が担う。説明文は currentPrice について、渡すと理想株価・DCF・スコアがその株価でも判定されること、渡さない場合は市場株価ではなく決算期末の擬似株価になることを補足しており、スキーマ以上の解釈を与えている。

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

「1回の呼び出しで銘柄の全体像を返します」と具体的な動作と対象を明示し、さらに6つのセクション(financials / idealPrice / stockScore / industryBenchmark / earningsForecast / dcf)を列挙して返却内容の輪郭を与えている。個別ツール名を明示することで類似ツールとの違いも明確。

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

「総合的な分析に向いています」「個別の深掘りには各ツール(…)があります」と使い分けの条件と代替手段を明示。さらに上場廃止・ETF・REIT・存在しないコードでは分析せず search_stocks を案内する例外や、含まれない情報(有報の文章・適時開示・大株主・販売先)とその深掘り手順まで示している。

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_stock_score6軸スコアA
Read-only
Inspect

銘柄コードを指定して、ラジ株ナビ独自の6軸スコア(0〜100)と理想株価の要約を取得します。 スコアは EDINET 有報の過去最大10期分の財務データ(annual.json)から動的に算出されます。 理想株価の要約・スコアに株主優待は含めません(優待制度がある銘柄には caveats で知らせます)。

【関連ツール】「○○を分析して」のような総合的な分析には get_stock_analysis が便利です(財務・理想株価・6軸スコア・DCF・業種比較・会社予想を1回でまとめて返します。返したセクションの数ぶん、最大6回分の利用回数を使います)。 このツールは、全年度・内訳・注意事項の全文など、個別の深掘りに向いています。 割安/割高を見る材料は get_edinet_financial_data(財務)・get_ideal_price(理想株価レンジ)・get_stock_score(6軸スコア)・get_dcf_valuation(DCF評価)・get_industry_benchmark(業種比較。codes にその銘柄を渡す)に分かれており、1つだけでは判断材料が偏ることがあります。

6軸(各 0〜100、高いほど良い。axes に英語キー、axisLabels に日本語名)。 profitability・moat は構成指標が全て取得不可の場合に限り null(算出不能。誤った数字は返さない)。 valuation は算出できた指標の重み(valuationCoverage)が0.5未満の場合にも null になります (DCF乖離率だけで重み50%を占めるため、時価総額が出せない等で DCF も補助指標も揃わない銘柄で起こりやすい)。 直近の平均FCFが0以下で DCF乖離率が算出できない会社は、DCF乖離率の欄を最も割高側の点(10点)として数えます (平均FCFが0に近づくと乖離率は−100%に近づき同じ点になるため。coverage にも含めます)。valuationNote にその旨が付きます。 ただし不動産業は物件の取得で FCF が負になりやすく収益力を表さないため、平均FCFが負でも10点では埋めず DCF を外します。 時価総額が出せない・FCFの年度が足りない・不動産業で平均FCFが負、などで DCF が欠測でも、残り4指標(EV/EBITDA・PER・PBR・ネットネット、合計重み50%)が 揃っていれば coverage=0.5 ちょうどで算出されます。この場合も valuationNote が付き、DCFを含まない前提で算出されたことを明示します。 safety は材料が欠けた指標を点数に入れず、算出できた指標の重み(safetyCoverage)が0.3未満の場合に null になります (連結に流動・固定の区分が無く Altman Z が算出できず、有利子負債も取得不可の会社など)。 safetyCoverage が1未満なら一部の指標を除いて算出しています。 (growth/shareholderReturn は中立点にフォールバックするため通常nullにならない):

  • valuation(割安度): DCF乖離率 / EV/EBITDA / PER / PBR / ネットネット。 (金融業は PER・PBR だけで評価。valuationCoverage は PER(0.6)・PBR(0.4) のうち算出できた割合) (販売金融・金融サービス等のセグメントや信用供与の資産が総資産の30%以上の会社は、get_dcf_valuation と同じ判定で DCF乖離率を使わず残りの指標で評価。重みの合計が50%未満なら valuation は null。valuationNote に理由)

  • profitability(稼ぐ力): ROE / 営業利益率 / EBITDAマージン / 従業員あたり営業利益 / ROA。

  • growth(成長性): 売上3年CAGR / EPS3年CAGR / PEG / 設備投資比率 / 売上5年CAGR。

  • safety(安全性): 自己資本比率 / Altman Z-score / ND/EBITDA / D/E / 営業CF対有利子負債。 (金融業は自己資本比率のみで評価。無借金の会社の営業CF対有利子負債は返済負担なしとして高評価)

  • shareholderReturn(還元力): 配当利回り / 増配率 / 配当性向 / DOE / 自社株買い / 総還元性向。 (無配企業は自社株買い実績のみで評価)

  • moat(事業独占力): 営業利益率σ / ROEσ / FCFマージンσ / 営業利益率水準 / SGA比率σ。 (金融業は営業CFに預り金・貸出金等の増減が入るため FCFマージンσ を使わず、残りの指標で評価) 最新期の BPS・EPS が過去の年度と桁違いの株数基準で書かれている会社(splits.json に記録の無い株式併合。 上場廃止後のスクイーズアウト等)は、axes の全項目と idealPrice を null にし、axesUnavailableReason・ idealPriceUnavailableReason="share_basis_break"・shareBasisBreak・caveats で理由を返します。

idealPrice(理想株価要約・Mark 3.2):

  • pseudoPriceFreshness: 擬似現価の鮮度。stale/obsolete のとき α値(割安度)は 古い基準で計算されており実態とズレます。現在の株価と直接比較してください。

  • dataBasis: どの時点の値を使ったか。financialsFiscalYearEnd(財務・6軸スコアの材料=有報の最新期)/ pseudoPriceFiscalYearEnd / epsAnchorForecastFiscalYearEnd(epsAnchor に使った会社予想の期)/ newerAnnualTanshin(有報より新しい年度短信の期末・開示日。有報の提出待ちのあいだだけ入る)/ note。 newerAnnualTanshin があるとき、6軸スコア・財務・擬似株価は1期前の有報の値です(短信には期末の株価が無く擬似株価は更新できません)。 shareBasis: 理想株価の下値の BPS に使った株数・BPS の組(有報の期末より新しい短信があればその組)。6軸スコアの時価総額は 擬似株価(有報の期末の株価)と同じ時点の株数(shareBasis.fiscalYearEnd)のままです。 自己株式の取得・消却で株数が5%以上変わったときは shareBasis.pendingShareChange と dataBasis.note で知らせます(値は割り直していません)。

  • forecastPeriodNotUsed: 会社予想の対象期間が12か月でないため、理想株価に予想を使わなかったときだけ付きます(get_ideal_price と同じ)。

  • bpsFloorApplied: true の場合、中央値(mid)は事業価値ではなく下支え(資産価値の7割 = low × 0.7)です。 判定が割安・超割安・適正になるときは、下支えで押し上げた中央値との比較で利益で説明できないため、verdict・alphaPct は null で、 verdictUnavailableReason="asset_floor_only" と caveats で理由を返します(「資産価値より株価が低いから割安」とは言えない銘柄)。 割高・超割高は判定を出し、verdictBasisType="asset_floor" が付きます(verdictBasis と caveats に「資産価値の7割との比較で決まった判定・ 利益から見るとさらに割高寄り」の旨)。currentPrice の verdictAtCurrentPrice・alphaPctAtCurrentPrice も同じ規則です。 rawMid に下支え前の中央値が入ります。本番 summary(2026-10-10)で理想株価のある会社の約22%が該当します。 false でも、事業価値等の合計が資産価値の7割以上・資産価値未満の会社は mid < low になります(約14%)。

  • forecastMayIncludeOneOff: true の場合、会社予想EPS(epsSource=forecast)または 予想と実績(正規化後)の幾何平均(epsSource=blended)を採用していますが 実績側で一過性損益が検出されています。理論株価が膨らんでいる可能性があります。

  • forecastProgressBehind: true の場合、会社予想EPSを採用していますが 直近四半期の累計営業利益の進捗が一律の目安(25/50/75%)の6割に届かず前年同期比で減益、かつ 前年同期の進捗が取れる会社はその6割にも届かず差が5ポイント以上です(例年どおりの季節性では立てません)。 会社予想に対して実績が下振れている=下方修正リスクが高い状態です。

  • effectiveMultipleCapped: true の場合、実効倍率(業種PER×ROA係数×レバ補正×qg係数)が 25倍キャップに達しており、事業価値は収益力に対して頭打ちになっています。 生の倍率(rawEffectiveMultiple)は get_ideal_price で確認できます。 資産価値は下値(low)と超過現金評価に分離 / 事業価値は実効倍率25倍キャップ / 成長価値はgrowth係数連動(最大60%)/ EPSアンカーは会社予想優先 (減益予想は素直に採用・2倍超の増額予想のみ幾何平均で緩和)。

  • low / mid / high: 理想株価レンジ(下値 / 中央値 / 上値)

  • low(下値)は資産価値(BPS×割引評価率)、mid(中央値)は事業価値+超過現金価値+配当プレミアム(資産価値の7割まで下支え)、 high(上値)はmid+成長価値(事業価値のうちgrowth係数に応じた一部、最大60%)

  • growthValueReason: 成長価値の短い根拠。blendedCagrPct(直近3期=成長期間2年のEPS・売上CAGRのブレンド、%)が zeroAtCagrPct 以下で成長価値0 (mid=high)、maxAtCagrPct 以上で上限。period は測った期間。実績が3期そろわない(成長期間1年以下)と CAGR を測らず成長価値0で、 理由は unavailableReason と caveats。6軸の成長性(3年・5年CAGR)とは期間が違います。詳細は get_ideal_price の growthValueBasis。

  • epsSource: 事業価値に採用したEPSの根拠(forecast=会社予想 / normalized=一過性損益除外の試算実績 / blended=予想と実績の乖離が大きい場合の幾何平均 / actual=生EPS / ttm=予想も正規化も無く最新の四半期短信等から出した直近12か月EPS(内訳は ttmEps。直近12か月の純利益を、使った短信の期末の発行済−自己株(分割調整後)で割る。判断できない会社は最新期の期中平均株数=純利益÷EPS。最新期の実績の2倍を超えるときは実績との幾何平均を基数にする=ttmEps.guard=blended、ttmEps.eps はガード前) / forward_12m=通期の会社予想が無く、累計期間の会社予想(第1・第3四半期累計・上期)を12か月に組んだ EPS(内訳は forwardTwelveMonth。 最新期の実績 + 今期の累計予想 − 前期の同じ累計の実績。get_ideal_price と同じ。組まなかった理由は forwardTwelveMonthNotUsed)

  • verdict: 5段階判定(超割安 / 割安 / 適正 / 割高 / 超割高)。擬似現価(pseudoPrice)が 理想株価レンジ(low/mid/high)のどこに位置するかで決まり、alphaPct(中央値との差の%) とは別の物差しです。レンジの帯の幅は銘柄ごとに異なるため、alphaPctが同程度でも verdictが異なることがあります(上側の幅が狭い・無いとき、下側の幅が無いとき(mid が low 以下)は、 中央値の27%を判定の幅の下限にします。上下とも幅が無い銘柄は中央値の ±27% で5段階に判定します)。 鮮度による判定の格下げは行っていません。

  • verdictBasis: pseudoPriceFreshness が aging 以上のときのみ、 「何年何月末時点の擬似株価と比較した判定か」を明記します(fresh のときは null)。

  • alphaPct: (mid - pseudoPrice) / pseudoPrice × 100。specialDividendAfterBs がある銘柄では、 low・excessCash は決算期末の後に払う予想の特別配当(短信の配当の注記から読み取り)を差し引いた 「支払い後」の水準で、alphaPct・verdict は pseudoPrice の代わりに specialDividendAfterBs.comparisonPrice (pseudoPrice − 特別配当)と比べます。currentPrice に権利落ち前の株価を渡す場合は特別配当を引いてから比べてください。 yearEndSpecialDividend がある銘柄では、low・excessCash は最新決算期の期末配当に含まれる特別配当 (有報の配当政策または配当に関する注記に期末分として記載)も差し引いた水準です。擬似株価(期末日の終値)は期末配当の 権利落ち後なので、比較株価からはこの額を引きません。

  • currentPrice 引数を渡した場合のみ idealPrice.verdictAtCurrentPrice / alphaPctAtCurrentPrice / currentPriceSource("user-provided")を追加で返します。 verdict / alphaPct(pseudoPrice基準)は変更されません。

  • 金融4業種(銀行業・保険業・証券・商品先物取引業・その他金融業)は、ROA が構造的に低く理想株価モデルが合わないため、 idealPrice の verdict・alphaPct(verdictAtCurrentPrice・alphaPctAtCurrentPrice も)を null にし、 verdictUnavailableReason="financial_sector" と caveats で理由を返します。low / mid / high は参考値です。

  • 有報の最新期より新しい年度の決算短信が出ていて有報がまだ提出されていない会社は、比べる擬似株価が最新の確定決算より 1期古いため、verdict・alphaPct・upperAlphaPct を null にし、verdictUnavailableReason="newer_annual_tanshin_pending_yuho" と caveats で理由を返します。currentPrice を渡せば verdictAtCurrentPrice・alphaPctAtCurrentPrice は返します。有報が提出されると判定を再開します。

  • verdictUnavailableReason は金融業 > asset_floor_only(上の bpsFloorApplied)> 有報待ち の順に1つだけ入ります。

  • pseudoPrice: 最新 actual PER × 生EPS の擬似現価(リアルタイム株価ではない)

  • pseudoPriceSource: pseudoPrice の算出根拠。per_eps=通常のPER×EPS / tsr_backsolved=赤字等でPER×EPSが算出不能な年度に限り、有報の株主総利回り(TSR)5年推移表から 決算時株価を逆算したフォールバック(実測誤差: 赤字等で実際に使われた170社・2026-10時点で中央値0.09%・最大3.4%)/ tsr_backsolved_extended=従来のTSR逆算で値が出ない会社に限り、5年前(TSR表の基準年度)の株価も候補に加え、PER×EPS が無い年度の株価をその年度までのTSR逆算値で1段だけ代替した予備経路(バックテスト誤差: 中央値0.15%・p95 1.89%・10%超0.4%) / per_eps_nonconsolidated=上の3つがどれも出ない会社に限り、有報の提出会社(単体)の PER × 単体の EPS(連結が赤字で連結の PER が空欄の会社など。株価は連結・単体で同じ。連結の PER×EPS との一致度は、両方ある会社で中央値0.08%・p99 1.57%。この経路で値が出る12社では期末の終値との差が10社で0.25%以内、5026は+7.29%・9219は+9.87%(原本の単体 PER 自体が期末とは別の日の株価で計算されているため)。同じ有報の当期の最高・最低株価の範囲内のときだけ使う)。

  • pseudoPriceFiscalYearEnd: pseudoPrice の基準となった決算期末日(YYYY-MM-DD)

  • BPS / EPS 不足の場合は null。詳細な計算過程は get_ideal_price で確認できます。

注意:

  • 各軸スコアはラジ株ナビ独自の配点ロジックによる相対評価です(業界平均ではなく固定閾値)。

  • データ不足の軸はニュートラル付近の値になることがあります。

  • 事業価値のEPSは 会社予想→一過性損益除外の試算→実績 の優先で採用済み(epsSourceで根拠を明示)。 epsSource が actual の一過性検出時(earningsQuality.oneOffDetected)のみ normalizedEps / normalizedPer を追加で確認してください。

  • earningsQuality.adjustments は normalizedEps を作るときに足し引きした項目の内訳(label・source・preTaxAmount・direction・afterTaxAmount・perShare)。 当社の試算で、会社の公表値ではありません(科目名が保存されていない項目は「特別利益(合計)」など総称)。

  • verdict / alphaPct は決算時点の擬似現価(pseudoPrice)ベースの判定であり、 市場株価との比較ではありません。判定は pseudoPriceFiscalYearEnd(基準となった決算期末日)時点のもので、 決算発表から半年以上経っている場合は判定の信頼性が下がります。

関連ツール: 財務の詳細は get_edinet_financial_data、理想株価の詳細は get_ideal_price。

応答の metricLabels は英語キー→日本語指標名の対訳です。利用者向けには日本語名(例: verdict→「割安度判定」)のほうが伝わりやすくなります(axes の日本語名は axisLabels にあります)。 データ品質・値の異常・不具合に触れる場合も同様で、フィールド名を示すときは「発行済株式数(sharesOutstanding)」のように日本語を主・英語キーを括弧内にすると読みやすくなります。

splitCheck(分割履歴がある会社のみ): 既定は要約(splits・adjustedFields・conflict)のみ。詳細は includeSplitDetails: true で、1株あたりの値ごとに raw(短信・有報の記載値)・adjusted(使った値)・factor・basis・method と、検算の材料(純利益÷EPSで逆算した株数と分割前の株数の比)を載せます。adjusted が検算と食い違う(conflict: true 等)ときは raw を基に判断してください。

応答の watchlistSuggestion は、この銘柄が利用者の監視リストに未登録のときだけ付く欄で、追加できるか(canAdd)・追加用のツール名(addTool)・監視の件数(watchlistCount)と上限(watchlistLimit。null は上限なし)を持ちます。上限に達しているときは canAdd が false で reason が limit-reached です。

※ 本データは情報提供を目的とし、投資助言・推奨ではありません。

NameRequiredDescriptionDefault
codeYes証券コード(例: 4665)
currentPriceNo省略可。利用者自身が確認した現在の株価。本サービスは株価を提供しないため、利用者が別途調べた値を渡してください。渡した場合、idealPrice.verdictAtCurrentPrice / alphaPctAtCurrentPrice を追加で返します(既存の idealPrice.verdict / alphaPct は変更されません)。
includeSplitDetailsNo省略可(既定 false)。true で分割の検算の詳細(splitCheck の items・evidence・howToVerify、splitAdjustment の reason 全文)を返します。既定では splitCheck は要約(splits・adjustedFields・conflict)のみ。検算の食い違い(conflict)があるときは、false でも詳細を返します。数値は変わりません。

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnly/openWorld=false, but the description discloses far more: the score is recomputed dynamically from up to 10 EDINET annual periods, exactly when each axis becomes null (valuationCoverage < 0.5, safetyCoverage < 0.3), that shareholder perks are excluded, financial-sector overrides, share-basis-break behavior, and bpsFloorApplied verdict suppression. It also goes beyond the annotations by disclosing mutation-adjacent behavior (watchlistSuggestion, and that includeSplitDetails=true only adds detail and never changes values). There is no contradiction with readOnlyHint=true.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first two paragraphs are well front-loaded, but the body balloons into a dense wall of nested edge cases (tsr_backsolved_extended error statistics, per-sector weighting rules, share-basis notes) that an agent cannot scan at call time. Much of it documents response semantics rather than what to do to invoke the tool correctly, so the size is not justified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Complexity is high, and with no output schema the description does the heavy lifting: it names axes/axisLabels, most idealPrice fields, caveats, splitCheck, and watchlistSuggestion. It stays short of a full top-level response contract and says nothing about error behavior for a missing or invalid code, so it is strong but not exhaustive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it explains that alphaPct/verdict must be compared against a special-dividend-adjusted price and re-anchors pseudoPrice when a stale basis is in play. It also clarifies that currentPrice never alters the existing verdict/alphaPct, which changes how an agent should use verdictAtCurrentPrice.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names a specific verb and resource: returning the proprietary 6-axis score (0–100) and an ideal-price summary for a given stock code. It is immediately distinguishable from siblings because the description explicitly explains the split between get_stock_analysis (one-shot comprehensive), this tool (per-field depth), and the single-dimension tools (get_edinet_financial_data, get_ideal_price, get_dcf_valuation, get_industry_benchmark).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit routing: for a broad "analyze X" request, use get_stock_analysis and note the cost (up to 6 usage credits), while this tool is for drilling into individual years, breakdowns and caveats. It also warns that judging cheap/expensive from one of the split tools skews the picture, and it points to get_edinet_financial_data / get_ideal_price for deeper detail.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_timely_disclosures適時開示A
Read-only
Inspect

当日または指定日の適時開示(TD-net)一覧を取得します。 code を指定して date を省くと、その銘柄の直近30日分を返します(30日以内が5件未満なら、それより前も含めて最新5件まで。応答の period に期間)。 決算短信・業績修正・配当・自社株買い・M&A・株式分割など全カテゴリを含みます。

データソース: Yanoshin TDnet WebAPI(東証 TDnet ミラー)。 各開示には document_url(PDF直リンク)が含まれます。 note: 過去日付の指定は Yanoshin API が遡及可能な範囲内。当日分は取得元の当日の一覧に、保存済みの当日の開示一覧にしか無い開示を足して返します。 freshness: 一覧が何時の開示まで入っているかを返します。coveredThrough(入っている最後の開示の時刻 JST。保存と取得元の新しいほう)・listUpdatedAt(一覧を取った時刻。当日のみ)。 取得元の一覧は平日 15:01 ごろに 15:00 までの分が入り、15:00 より後の分は翌朝までに入ります。この間は status=partial_until_next_morning(15:00 までは入っていて残りは翌朝。故障ではない)と nextExpectedUpdate(残りが入る見込みの説明。時刻は断定しない)を返します。日をまたいでも 15:00 までのままなど、更新が止まっているときは status=source_stalled(lastItemAt・note 付き)を返します。 個別に追加された開示が取得元の最後より新しいときは、feedCoveredThrough に取得元の最後の時刻を返します。

関連ツール: 銘柄の財務データは get_edinet_financial_data、大量保有は get_large_holdings。

デフォルトは最新200件を返します。特定銘柄の開示を探すときは code、キーワードで探すときは keyword を使ってください。

各開示には categories(カテゴリの配列)が付きます。タイトルから推定したもので、1件が複数のカテゴリを持つことがあります (例: 「業績予想の修正(上方修正)及び配当予想の修正(増配)」→ forecast_up と dividend_up)。 category を指定するとそのカテゴリで絞り込めます(複数指定は OR)。forecast / dividend は上方・下方(増配・減配)も、buyback は ToSTNeT-3 等の相対取引(buyback_tostnet)も含みます。 カテゴリ: earnings=決算(会社の決算短信・決算速報値。決算の開示の延期・45日超え・開示予定日のお知らせは含まない) / fund_earnings=ETF・投信の決算(ETF・ETN の決算短信。銘柄マスタの商品区分で判定。会社の決算ではない) / forecast_up=業績予想の上方修正 / forecast_down=業績予想の下方修正 / forecast=業績予想の修正(方向の記載なし、または項目ごとに方向が割れている/数値未取得) / dividend_up=増配・復配・記念配当 / dividend_down=減配・無配 / dividend=配当の決定・配当予想の修正(方向の記載なし、または数値未取得) / buyback=自社株買い・消却(自己株式・自己投資口の取得) / buyback_tostnet=自社株買い(ToSTNeT-3等の相対取引。市場での買い支えではない) / tob=公開買付け(TOB・MBO) / tob_holder=保有する他社株式の公開買付け(応募・不応募。自社が買い付けられる側ではない) / offering=新株・売出・第三者割当・ストックオプション / treasury_disposal=自己株式の処分(株式報酬・第三者割当・持株会向けなど。放出する側) / stock_compensation=株式報酬・従業員向け株式インセンティブ(譲渡制限付株式・RSU・株式給付信託・ストックオプション) / stock_split=株式分割・株式併合 / medium_term_plan=中期経営計画(策定・修正・見直し・進捗。中長期の経営計画・成長戦略を含む) / executive_change=役員の異動(代表取締役の異動・役員人事・取締役の辞任・執行役員の異動・取締役候補者の選任) / merger=M&A・組織再編(子会社化・株式取得・資本業務提携を含む) / shareholder_benefit=株主優待 / monthly_sales=月次 / large_holding=大量保有 / other=その他 業績予想・配当予想の修正の方向(forecast_up/down、dividend_up/down)は、XBRL から取り込んだ修正前後の数字で決めます(取り込み済みの開示のみ。 数字が無い開示はタイトルの文言で判定)。数字とタイトルの方向が食い違うときは数字を優先し、タイトルの方向を revisionDirection.titleDirection に残します(conflict: true)。 業績の判定は、連結(無ければ個別)の通期の営業利益・経常利益・純利益で行い、全項目が同じ向きなら上方/下方、割れたら方向なし(forecast のまま、revisionDirection.direction=mixed)、 利益が動かず売上だけ動いたときは売上で決めます。配当は通期(無ければ期末)の1株配当で決め、株式分割に伴う機械的な修正の可能性があるものは決めません。 revisionDirection は修正系の開示に付き、direction(up/down/flat/mixed/unknown)と根拠を示します。 categoryCounts に、絞り込み前の全件のカテゴリ別件数を返します。

code を指定した場合のみ、業績予想・配当予想の修正系開示(forecast/dividend系カテゴリ)に parsedNumbers(XBRLから取り込んだ修正前後の数値・増減率)を付加します。 parsedNumbers.earnings[].priorActual は修正開示の参考欄(前期実績)の会社記載値そのままです。参考欄は会社の転記で、 決算短信と食い違うことがあります(3459: 1口当たり当期純利益の欄に分配金の値。6505 の PDF: 前期 EPS の欄に前々期の値)。 通期の前期実績には priorActualCheck を添え、同じ年度の決算短信と照合した結果を status で示します (consistent=一致 / consistent-after-split=決算期末後の株式分割で書き直した値と一致 / eps-mismatch=純利益は一致するのに EPS だけ食い違う =修正開示側の記載の食い違い。前期 EPS は comparedWith.eps(決算短信)が正 / unverifiable=照合できなかった)。 (全件・keyword検索では数値を付けません。銘柄横断の処理コストを避けるため)

※ 本データは情報提供を目的とし、投資助言・推奨ではありません。

NameRequiredDescriptionDefault
codeNo証券コードで絞り込みます(例: 7203)。全角・小文字・末尾の .T は正規化して比較します。
dateNo取得する日付(YYYY-MM-DD)。省略時は当日分を返します。ただし code を指定して省略したときは、その銘柄の直近30日分(少なくとも最新5件)を返します。
limitNo返す件数の上限。デフォルト200、最大2000。
keywordNoタイトルまたは会社名の部分一致で絞り込みます。全角半角・ひらがな/カタカナ・大文字小文字の揺れは吸収されます。
categoryNoカテゴリで絞り込みます(例: "forecast_up" や ["earnings","dividend"])。forecast / dividend は上方・下方を含みます。

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, the description discloses substantial behavior: data source, today-vs-past-date limitations, freshness statuses such as partial_until_next_morning and source_stalled, feedCoveredThrough behavior, default 200 items, and code-only parsedNumbers enrichment. These details materially help an agent understand what the tool returns and when data may be incomplete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core behavior and is logically organized, but it is very long and includes deep XBRL caveats and examples that are useful yet verbose. It is appropriately sized for a complex financial-disclosure tool, but not maximally concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description still explains the important return fields and behaviors: document_url, categories, categoryCounts, freshness, revisionDirection, and code-specific parsedNumbers caveats. An agent has enough information to invoke the tool and interpret major response characteristics correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is already 100%, the description adds significant parameter meaning beyond the schema. It explains the code+date fallback rule, gives detailed semantics for each category value, clarifies OR behavior for multiple categories, and notes that parsedNumbers is attached only when code is specified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: fetch the timely disclosure (TD-net) list for today or a specified date. It also explains the code/date fallback behavior and names adjacent tools (get_edinet_financial_data for financials, get_large_holdings for large holdings), making its scope distinguishable from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear usage guidance: use code to find a specific stock's disclosures and keyword for keyword searches, with related tools named for financial data and large holdings. However, it does not explicitly exclude nearby tools such as get_earnings_flash or state when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_watchlist監視リストを見るA
Read-only
Inspect

監視リストの一覧を取得します。 監視リストの銘柄は、お気に入り(ポートフォリオ。category: favorite)と監視(category: watching)に分かれます。 お気に入り(ポートフォリオ)は、保有などを自分で管理する銘柄で、株数(shares)と取得単価(acquisitionPrice・円)を任意で持てます。株数を入れれば保有(holding: true)として扱います。メモは付けられません。 「ポートフォリオに入れて」「お気に入りに入れて」という依頼は category: favorite にあたります。 監視は、気になる銘柄です。メモを付けられます。分類を省略すると監視になります。 同じ銘柄をお気に入りと監視の両方に入れられます(その場合は分類ごとに別の項目です)。

各銘柄に category・holding(株数1以上なら true)を返し、お気に入りには shares・acquisitionPrice も返します。 保有銘柄だけを見るには holding: true、お気に入り(ポートフォリオ)だけなら category: favorite、監視だけなら category: watching を指定します。 件数は count(今回返した件数)、totalCount(全体)、favoriteCount、watchingCount で返します。limit は監視の件数上限です。

メモ(note)は監視の銘柄にだけあり、その銘柄で何を気にしているかが書かれています。 登録日(addedAt)はメモを書いた時点で、上書きされません。 lastCheckedAt は前回この一覧を取得した時刻です(この時刻の記録だけは今回の取得で更新します。登録内容・メモは変えません)。 この2つの間に何が起きたかは、get_timely_disclosures / get_large_holdings / get_earnings_forecast などで確認できます。

※この一覧取得は登録銘柄数ぶん利用回数を使います(0件・1件なら1回)。絞り込んでも、全体の登録数で数えます。

※ 本データは情報提供を目的とし、投資助言・推奨ではありません。

NameRequiredDescriptionDefault
holdingNo保有で絞り込む(任意)。true = 株数1以上のお気に入り、false = それ以外
categoryNo分類で絞り込む(任意)。favorite = お気に入り(ポートフォリオ)、watching = 監視

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint/openWorldHint annotations, it discloses the rate-cost model (consumes one usage per registered stock, counted by total regardless of filtering) and the side effect that fetching updates lastCheckedAt while leaving registrations and notes untouched. These are non-obvious operational traits an agent could not infer from the annotations alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the one-line purpose, then logically ordered (category model → filters → return fields → note/timestamp semantics → cost → disclaimer). It is long, but for a tool with an implicit two-category domain model most sentences earn their place; minor redundancy appears in the repeated filter-to-intent mapping.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description fully carries the return contract—category, holding, shares, acquisitionPrice, count/totalCount/favoriteCount/watchingCount—plus note/addedAt/lastCheckedAt semantics. Nothing an agent needs to call or interpret the result is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the baseline is 3, but the description adds real semantics the schema lacks: the default when category is omitted (watching), that holding is derived from shares >= 1, and how a stock can appear twice. It does not, however, clarify the limit parameter mentioned in the text but absent from the enumerated schema properties.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("監視リストの一覧を取得します") and immediately defines the two-category model (favorite/watching) that distinguishes this tool from add_to_watchlist, remove_from_watchlist, and update_watchlist_note among its siblings. An agent can identify both what it does and what it is not.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly maps intent to parameters ("保有銘柄だけを見るには holding: true、お気に入りだけなら category: favorite、監視だけなら category: watching") and even maps natural-language requests ("ポートフォリオに入れて") to category values. It also names the follow-up tools (get_timely_disclosures / get_large_holdings / get_earnings_forecast) for the activity between addedAt and lastCheckedAt.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_edinet_stocks対象銘柄の一覧A
Read-only
Inspect

利用可能な銘柄の一覧情報(カバレッジ、データソース、参照ガイドURL)を返します。

対象: 東証プライム / スタンダード / グロースの事業会社 約3,700社。 ETF・REIT・投信・TOKYO PRO MARKET は対象外。

※ 本データは情報提供を目的とし、投資助言・推奨ではありません。

NameRequiredDescriptionDefault

No parameters

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and openWorldHint=false, so safety is covered; the description adds real value beyond that by disclosing the return contents (coverage, data source, reference guide URL), the exact covered universe, and a non-advice disclaimer.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first sentence, followed by scope and exclusions; the compliance disclaimer is boilerplate but justified for financial data. No redundant restatement of the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-value burden and does so by naming the three returned elements plus the scoping caveat. Complete for a zero-parameter reference-listing tool, though it could note pagination or response size for ~3,700 entries.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline is 4. The description usefully clarifies that the output is static reference data (coverage, sources, guide URL) rather than a parameterized query.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('returns a list of available stocks') and pins down scope precisely (~3,700 TSE Prime/Standard/Growth operating companies; ETFs, REITs, funds, TOKYO PRO MARKET excluded). This lets an agent distinguish it from search_stocks/screen_stocks, though no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The inclusion/exclusion scope implies the tool is for enumerating the available universe rather than filtering, but there is no explicit 'use this when…' or reference to search_stocks/screen_stocks as alternatives. Usage is inferable but not stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

remove_from_watchlist監視リストから外すA
DestructiveIdempotent
Inspect

監視リストから削除します。登録されていないコードは notFound に入ります(エラーにはしません)。 category(favorite = お気に入り(ポートフォリオ)、watching = 監視)で、どちらから外すかを指定できます。 省略したときは、その銘柄が片方の分類にしか無ければそちらから外し、両方にあればエラーで category の指定を求めます(何も削除しません)。

※ 本データは情報提供を目的とし、投資助言・推奨ではありません。

NameRequiredDescriptionDefault
codesYes削除する証券コードの配列
categoryNoどちらの分類から外すか(任意)。favorite = お気に入り(ポートフォリオ)、watching = 監視

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (destructiveHint=true, idempotentHint=true), the description discloses important behavior: unregistered codes land in notFound rather than erroring, and the ambiguous-category case fails atomically with '何も削除しません' (nothing deleted). This partial-failure and atomicity context is exactly what a mutation tool needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and category behavior are front-loaded and efficient, but the trailing investment-advice disclaimer is boilerplate that does not help tool selection. Still, the core content is tight and well-ordered.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no output schema and full schema coverage, the description adequately covers side effects, partial-failure handling, and the ambiguous-category branch. It stops short of stating authorization/permission requirements, a minor remaining gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds the default/omitted behavior for category (remove from the single matching classification, or error if in both) which the schema does not express. It meaningfully augments the enum's semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource ('監視リストから削除します' – remove from watchlist), making it immediately distinguishable from add_to_watchlist, get_watchlist, and update_watchlist_note. An agent can select this tool without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explains the conditional use of category: specify it to pick a classification, omit it when the stock is in only one, and it will error requiring category when the stock is in both. This is clear when-to-use guidance, though it does not explicitly name sibling alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

report_issueデータの不具合を報告AInspect

データの誤りに気づいたら、利用者の同意を得たうえで報告します。 報告してよいか、必ず利用者に確認してから呼び出してください。

報告した数値が自動で直ることはありません。運営が原本(有価証券報告書・ 決算短信など)を確認したうえで手動で修正します。

1日あたり10件までです。上限に達すると daily_limit エラーになります。

銘柄コードは英字入り(140A 等)も指定できます。

※ 本データは情報提供を目的とし、投資助言・推奨ではありません。

NameRequiredDescriptionDefault
codeYes対象の証券コード(例: 7203、140A)
fieldNo誤りがある指標・項目名(任意、例: ROE、配当性向)
messageYes誤りの内容(1〜500文字)。何がどう違うと思うかを具体的に書いてください
sourceUrlNo根拠となる情報源のURL(任意、http/https のみ)
fiscalYearNo対象の年度(任意、例: 2025年3月期)

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations (readOnlyHint=false, idempotentHint=false): it discloses that submissions do NOT auto-correct data, that operators manually verify against 有価証券報告書/決算短信, that consent must be obtained, and that a 10-per-day rate limit returns a daily_limit error. These are non-obvious operational facts that annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The consent requirement and the no-auto-correction fact are front-loaded where they matter, and the rate limit is stated compactly. The closing investment-advice disclaimer is boilerplate rather than operational, but it is short and plausibly required.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description still tells the agent everything needed to call correctly and set user expectations: who reviews the report, the consent gate, the daily cap, and the accepted code format. All 5 parameters are covered by the schema, so nothing is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents code, field, message, sourceUrl, and fiscalYear. The description's note that codes may contain letters (140A) duplicates the example already present in the schema, adding no new meaning. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('データの誤りに気づいたら…報告します') with no ambiguity about what is reported or to whom. No sibling tool performs user-submitted error reporting, so there is nothing to confuse it with among the get_*/screen_*/watchlist tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the trigger ('データの誤りに気づいたら') and a hard prerequisite ('必ず利用者に確認してから呼び出してください'). It also names the failure condition the agent will encounter (daily_limit after 10 reports/day), which is exactly the when-not guidance an agent needs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

screen_by_frameworkフレームワークで絞り込みA
Read-only
Inspect

4つの投資フレーム(成長株 / 高配当株 / バリュー株 / 業績回復株)別に、 利用者が示した選定の条件(下の判定基準)を満たす会社の一覧を、最大100社まで返します。 条件に合う会社を機械的に抽出するツールで、どの株を買うべきかには答えません。一覧は推奨ではありません。

利用者が型を指定した(または型が分かる言い方をした)質問の例(自然文 → framework マッピング):

  • 「バリュー株を探して」「割安株を教えて」「割安な銘柄は?」「PERが低い銘柄」 → framework=value

  • 「成長株を探して」「グロース株を教えて」「伸びてる会社」「業績が伸びてる銘柄」 → framework=growth

  • 「高配当株を探して」「配当狙いの銘柄」「インカム株」「利回りが高い銘柄」 → framework=high_dividend

  • 「業績回復株を探して」「ターンアラウンド銘柄」「復活しそうな会社」「最近よくなってる銘柄」 → framework=turnaround

  • 型がはっきりしない漠然とした質問は、このツールの対象として扱わず、 どんな条件(割安・成長・高配当など)で探したいかを利用者に確かめてから使います。

個別銘柄の深掘りには get_edinet_financial_data(財務)・get_ideal_price(理想株価レンジ)・get_stock_score(スコア)があります。 指標を細かく指定したい場合(例: ROE>=20% AND 自己資本比率>=60%)は screen_stocks が向いています。

フレームと判定基準(tier="good")※ 形式: 英語キー(日本語名):

  • growth (成長株): salesGrowth(売上成長率)>=15% AND operatingMargin(営業利益率)>=15% AND roe(ROE)>=15% AND 2年連続増収(consecutiveSalesGrowthYears>=2)

  • high_dividend (高配当株): dividendYield(配当利回り)>=4% AND payoutRatio(配当性向)<=50% AND doe(DOE / 株主資本配当率)>=3% AND equityRatio(自己資本比率)>=40%

  • value (バリュー株): per(PER / priceEarningsRatio)<=10 AND pbr(PBR / priceBookValueRatio)<=1.0 AND roe(ROE)>=10%

  • turnaround (業績回復株): salesGrowth(売上成長率)>=10% AND 営業利益率改善(operatingMargin 前期比)>=5pt

tier="ok" は基準を 1 段階緩和します:

  • growth: salesGrowth(売上成長率)>=5%, operatingMargin(営業利益率)>=8%, roe(ROE)>=8%(連続増収条件なし)

  • high_dividend: dividendYield(配当利回り)>=2.5%, payoutRatio(配当性向)<=70%, doe>=2%, equityRatio(自己資本比率)>=20%

  • value: per(PER)<=15, pbr(PBR)<=1.5, roe(ROE)>=5%

  • turnaround: salesGrowth(売上成長率)>=0%, 営業利益率改善>=2pt

注意: 金融業(銀行・証券・保険・その他金融)は営業CFに預り金等が入るため、FCF利回り等のFCF系指標は出していません(このツールの判定基準には FCF 系は含まれません)。

データソース: 全銘柄の最新 annual.json を集約した edinet-summary.json(日次更新)。 カバレッジ: 東証プライム / スタンダード / グロースの事業会社 約3,700社(名証・札証・福証だけに上場している会社は含まない)。

注意:

  • 会計基準の違い(IFRS/USGAAP)で営業利益率の絶対値は厳密比較不可。

  • 「セグメント成長」「上方修正履歴」「Q1進捗率」は summary に無いため判定対象外です。

  • oneOffSuspected: true の銘柄は特別損益で純利益・EPS・PER・理論株価・スコアが嵩上げされている可能性があります。 特別損益は get_edinet_financial_data で確認できます。

実力の値(basis):

  • 実力の値は、特別損益・事業の売却益・減損などの一過性の損益を除いて試算した値です。一過性の損益が無い会社は公表の値と同じです。

  • 既定(basis 省略・reported)は公表の値で判定します。結果に一過性の損益で公表と実力が違う会社が含まれるときは、 応答の最後に、該当の社数と例(公表→実力)と「実力の値で絞り直しますか?」という問いかけが付きます。

  • basis="normalized" は、判定基準の PER・ROE・配当性向・営業利益率を実力の値(normalizedPer・normalizedRoe・normalizedPayoutRatio・ normalizedOperatingMargin)に置き換えて判定します。しきい値は同じです。結果には公表の値と実力の値を並べ、差の主な理由(normalizedReasons)を添えます。

応答の metricLabels は英語キー→日本語指標名の対訳です。利用者向けには日本語名(例: roe→「ROE(自己資本利益率)」)のほうが伝わりやすくなります。 データ品質・値の異常・不具合に触れる場合も同様で、フィールド名を示すときは「発行済株式数(sharesOutstanding)」のように日本語を主・英語キーを括弧内にすると読みやすくなります。 (出力は { metricLabels, results } 形式。銘柄配列は results に入ります)

※ 返すのは示した条件を満たす会社の一覧であり、投資助言・推奨ではありません。本データは情報提供を目的としています。

NameRequiredDescriptionDefault
tierNo判定基準の厳しさ。good=厳しい基準(例: growthならROE>=15%、valueならPER<=10)/ ok=緩和基準(例: growthならROE>=8%、valueならPER<=15)。デフォルト: good。利用者が基準を緩めた条件(「ゆるめの条件で」など)を求めたときだけ ok を選ぶ。
basisNo判定に使う値。reported=公表の値(有報の記載どおり。既定)/ normalized=実力の値(一過性の損益を除いた試算。PER・ROE・ROA・EPS・配当性向・総還元性向・営業利益率・純利益を normalizedPer などの実力の欄に置き換えて判定し、結果に公表と実力を並べて差の理由を添える)。一過性の損益が無い会社は公表と同じ値。reported の応答の最後に「実力の値で絞り直しますか?」が付いた条件は、normalized で呼び直すと実力の値で判定し直せる。
limitNo返す件数の上限(デフォルト: 30、最大: 100)
marketNo市場で絞り込み(例: プライム)
sectorNo業種で絞り込み(例: 情報・通信業。中黒の全角/半角どちらでも可)
frameworkYes投資フレーム(選定条件の型)。growth=成長株(売上成長・利益率重視)/ high_dividend=高配当株(配当利回り重視)/ value=バリュー株(PER・PBR重視)/ turnaround=業績回復株(利益率改善重視)。自然文の対応: 「成長株/グロース」→growth、「割安株/バリュー/PERが低い」→value、「高配当/インカム/利回り重視」→high_dividend、「業績回復/ターンアラウンド」→turnaround。

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds substantial extra context: data source and refresh cadence (edinet-summary.json, daily), coverage limits (~3,700 TSE Prime/Standard/Growth operating companies, no Nagoya/Sapporo/Fukuoka-only listings), IFRS/USGAAP comparability caveats, the oneOffSuspected disclosure, and exactly how basis=normalized changes judgement plus the follow-up prompt appended to responses.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening paragraph is well front-loaded, but the body repeats content that already lives in the schema (tier thresholds appear in both places) and re-states the 'not investment advice' disclaimer twice plus a redundant output-format note. The density is justified by four frameworks × two tiers, but a third of the text is duplication.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description compensates by describing the { metricLabels, results } response shape, the array location, and how to render metric labels bilingually for users. Combined with coverage limits, accounting-standard caveats, and the basis re-run path, an agent has everything needed to call and present results correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description goes beyond it by spelling out the full threshold table per framework for both good and ok tiers, which the schema only summarizes. It also elaborates the reported-vs-normalized basis behavior (which fields get swapped, thresholds unchanged) and the natural-language→framework mapping for the required parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb+resource (list companies matching one of four investment frameworks, capped at 100) and immediately delimits scope: mechanical extraction only, no buy recommendations. It also distinguishes itself from get_edinet_financial_data, get_ideal_price, get_stock_score and screen_stocks within the first three paragraphs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit routing rules: natural-language phrasing mapped to each framework value, an explicit when-NOT clause (vague questions should be clarified with the user before calling), and named alternatives (screen_stocks for metric-level conditions like ROE>=20% AND equityRatio>=60%, per-stock tools for deep dives). Nothing is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

screen_stocksスクリーニングA
Read-only
Inspect

全上場企業(約3,700社)の財務データからスクリーニングします。条件に合致する銘柄を返します。

使い分け:

  • 「バリュー株を探して」「成長株を探して」「高配当株を探して」「業績回復株を探して」など、 定型の投資フレームで漠然と探したい場合は screen_by_framework が向いています。

  • このツール(screen_stocks)は、指標と数値を細かく組み合わせて指定したい場合に使います。 例: 「ROE>=20% かつ 自己資本比率>=60% かつ PER<=15」など。

カバレッジ: 東証プライム / スタンダード / グロースの事業会社 約3,700社(名証・札証・福証だけに上場している会社は含まない)。 データソース: 全銘柄の最新 annual.json を集約した edinet-summary.json(日次更新)。

利用可能な指標(全一覧): 引数 metric には英語キーを渡してください。 「キー=日本語名(単位)」の形式です。日本語名で指定しても内部で英語キーに正規化されますが、原則は英語キーを渡してください。 本番 summary の数値項目をすべて載せています。この一覧に無い指標は使えません。 [収益性(%)] roe=ROE(自己資本利益率), roa=ROA(総資産利益率), roic=ROIC(投下資本利益率), operatingMargin=営業利益率(金融業は経常利益率で代替。marginBasis参照), netProfitMargin=純利益率, grossProfitMargin=売上総利益率, ebitdaMargin=EBITDAマージン, operatingCFMargin=営業CFマージン, fcfMargin=FCFマージン(簡易FCF=営業CF+投資CF ÷売上高・%。金融業は screen では null), sgaRatio=販管費率(販管費÷売上高・%), rdRatio=研究開発費率(研究開発費÷売上高・%), effectiveTaxRate=実効税率(%) [安全性] equityRatio=自己資本比率, tangibleEquityRatio=有形純資産比率(%), currentRatio=流動比率, debtToEquityRatio=D/Eレシオ, netDebtToEbitda=ネットD/EBITDA倍率, interestCoverageRatio=インタレスト・カバレッジ・レシオ(営業利益÷支払利息・倍), retainedEarningsRatio=利益剰余金比率(利益剰余金÷総資産・%), goodwillRatio=のれん比率(のれん÷総資産・%), netCashRatio=ネットキャッシュ比率(ネットキャッシュ÷時価総額・倍。% ではない), ncToAssets=NC/総資産(ネットキャッシュ÷総資産・%), ncToEquity=NC/自己資本(ネットキャッシュ÷自己資本・%) [還元] payoutRatio=配当性向, doe=DOE(株主資本配当率), totalReturnRatio=総還元性向, totalShareholderReturn=総還元額(配当+自社株買い・円), dividendYield=配当利回り, dividendPerShare=1株配当, ordinaryDividendYield=普通配当の配当利回り, ordinaryDividendPerShare=普通配当(1株配当から特別配当・記念配当を除いた額), specialDividendPerShare=特別配当・記念配当(1株), dividendInterim=1株中間配当(円), dividendYearEnd=1株期末配当(円) [効率・CF] assetTurnover=総資産回転率, cashConversionCycle=CCC(現金化速度), operatingCFToDebt=営業CF対有利子負債, capexRatio=設備投資比率(設備投資÷売上高・%), accrualRatio=アクルーアル比率((純利益−営業CF)÷総資産・%), salesPerEmployee=従業員1人あたり売上高(円), operatingIncomePerEmployee=従業員1人あたり営業利益(円) [割安・バリュエーション] per=PER(株価収益率), pbr=PBR(株価純資産倍率), psr=PSR(株価売上高倍率), evToEbitda=EV/EBITDA, pegRatio=PEGレシオ(PER÷EPS成長率。PER>0かつ成長率>0の会社のみ・倍), ncav=NCAV(流動資産−負債合計・円), ncavRatio=NCAV比率(NCAV÷時価総額・倍。1以上でグレアム基準), fcfYield=簡易FCF利回り(簡易FCF=営業CF+投資CF ÷時価総額・%。金融業は営業CFに預り金等が入るため null。土地・事業・有価証券の売却入金で一時的に跳ねるので、極端に高い会社は投資CFの中身を確認し、oneOffSuspected も見ること), earningsYield=益回り(100÷PER・%), marketEv=EV(時価総額÷親会社の取り分(非支配株主の分を足し戻す)+有利子負債−現金・円。EV/EBITDA×EBITDAからの概算。理論企業価値 enterpriseValue とは別), marketCap=時価総額, eps=EPS(1株利益), bps=BPS(1株純資産), tsrCurrent=TSR(株主総利回り・5年間の累積倍率) [規模・絶対値] netSales=売上高, operatingIncome=営業利益, ordinaryIncome=経常利益(IFRS・米国基準は税引前利益), netIncome=当期純利益, totalAssets=総資産, equity=自己資本, tangibleEquity=有形純資産(円), currentAssets=流動資産(円), totalLiabilities=負債合計(円), investmentSecurities=投資有価証券(円), netCash=ネットキャッシュ, netDebt=ネット有利子負債, interestBearingDebt=有利子負債, ebitda=EBITDA, cashFlowFromOperations=営業キャッシュフロー(円), fcf=簡易フリーキャッシュフロー(営業CF+投資CF) [成長性(%)・連続年数] salesGrowth=売上成長率, operatingIncomeGrowth=営業利益成長率(%), netIncomeGrowth=純利益成長率(%), epsGrowth=EPS成長率, salesCagr3y=売上高の3年平均成長率(CAGR・%), operatingIncomeCagr3y=営業利益の3年平均成長率(CAGR・%), netIncomeCagr3y=純利益の3年平均成長率(CAGR・%), epsCagr3y=EPSの3年平均成長率(CAGR・分割調整後・%), salesPerEmployeeGrowth=従業員1人あたり売上高の成長率(%), operatingIncomePerEmployeeGrowth=従業員1人あたり営業利益の成長率(%), consecutiveSalesGrowthYears=連続増収年数, consecutiveOpGrowthYears=連続増益年数, consecutiveDividendGrowthYears=連続増配年数, totalYears=収録している決算年数 [前期の値] prevNetSales=前期の売上高, prevOperatingIncome=前期の営業利益, prevOrdinaryIncome=前期の経常利益(IFRS・米国基準は税引前利益), prevNetIncome=前期の純利益, prevEps=前期のEPS, prevRoe=前期のROE, prevRoa=前期のROA, prevOperatingMargin=前期の営業利益率, prevEquityRatio=前期の自己資本比率 [株式・株主] sharesOutstanding=発行済株式数, treasuryShares=自己株式数, issuedSharesTotal=発行済株式総数(議決権ベース), shareCountChange5y=株数の5年変化率(自己株式を除く発行済株式数・分割調整後・%。マイナス=自社株買い・消却で減少、プラス=増資・新株予約権等で増加), shareCountChange10y=株数の10年変化率(自己株式を除く発行済株式数・分割調整後・%。マイナス=減少、プラス=増加), foreignShareholdingRatio=外国人持株比率, institutionalShareholdingRatio=機関投資家持株比率, auditFeesTotal=監査報酬合計(円) [独自スコア(0-100)] scoreTotal=総合スコア, scoreValuation=割安度スコア, scoreProfitability=稼ぐ力スコア, scoreGrowth=成長性スコア, scoreSafety=安全性スコア, scoreShareholderReturn=還元力スコア, scoreMoat=事業独占力スコア, scoreValuationCoverage=割安度スコアの算出できた指標の割合(0-1。1未満は一部欠測), scoreSafetyCoverage=安全性スコアの算出できた指標の割合(0-1) [実力(一過性の損益を除いた試算)] normalizedEps=実力EPS(一過性損益を除いた試算), normalizedPer=実力PER(一過性損益を除いた試算), normalizedRoe=実力ROE(一過性損益を除いた試算), normalizedRoa=実力ROA(一過性損益を除いた試算), normalizedPayoutRatio=実力配当性向(一過性損益を除いた試算), normalizedTotalReturnRatio=実力総還元性向(一過性損益を除いた試算), normalizedOperatingMargin=実力営業利益率(一過性損益を除いた試算), normalizedNetIncome=実力純利益(一過性損益を除いた試算) [理想株価モデル] alphaPct=α値(%), upperAlphaPct=上値α値(%), idealPriceLow=理想株価(下値), idealPriceMid=理想株価(中央値), idealPriceHigh=理想株価(上値), pseudoPrice=擬似現在株価, pseudoPriceAgeMonths=擬似株価の基準日からの経過月数, assetValue=資産価値(1株あたり・円), businessValue=事業価値(1株あたり・円), growthValue=成長価値(1株あたり・円), dividendValue=配当価値(1株あたり・円), excessCashValue=超過現金価値(1株あたり・円), epsAnchor=採用EPS(アンカー), forecastEps=予想EPS, effectiveMultiple=実効倍率(キャップ後) ※ 金額は円、%と書いた比率は 15.2=15.2%、「倍」は倍率。foreignShareholdingRatio / institutionalShareholdingRatio だけ 0-1 表記(下記)。 ※ fields に指定するだけで条件にせず値を見ることもできます。verdict(5段階判定)は専用パラメータで指定します。

使用例: 「総合スコア80以上×割安以下」= conditions: [{metric: "scoreTotal", operator: ">=", value: 80}] + verdict: ["超割安", "割安"]

注意:

  • 会計基準が異なる銘柄(IFRS / USGAAP)は数値の比較に留意(特に営業利益・有利子負債)。

  • USGAAP 連結 XBRL 不開示銘柄(オリックス等)は interestBearingDebt = null。

  • 【重要】foreignShareholdingRatio / institutionalShareholdingRatio は 0-1 表記です (例: 22.8% の場合は 0.228 として保存されています)。roe や equityRatio 等の他の指標は % 表記(例: 15.2 = 15.2%)なので単位が異なります。「外国人持株比率30%以上」を条件にする場合、 value: 30 ではなく value: 0.3 を指定してください。value: 30 を指定すると、 エラーにはならず該当銘柄が0件(または比較演算子によっては意図せず全件)になります。

  • institutionalShareholdingRatio は金融機関(信託銀行・保険会社等)のみの比率で、 証券会社・事業法人(政策保有株主)を含まない狭い定義です。

  • 条件に使った指標が null の銘柄は自動的に除外されます(例: 保険業は netSales が null)。

  • 金融業(銀行・証券・保険・その他金融)は営業CFに預り金等が入るため、fcfYield(FCF利回り)・fcf・fcfMargin は null にしています(FCF系の条件・並べ替えで金融業は出ません)。

  • fcfYield(簡易FCF=営業CF+投資CF)は土地・事業・有価証券の売却の入金で一時的に跳ねます。利回りが極端に高い会社(100%超など)は投資CFの中身を確認し、上位を見るときは oneOffSuspected も見てください。

  • shareCountChange5y / shareCountChange10y(株数の5年・10年変化率、%)は、自己株式を除く発行済株式数を株式分割・併合で調整して比べた値です。 マイナス=自社株買い・消却で株数が減った、プラス=増資・新株予約権の行使・株式交換などで増えた(希薄化)。例: 自社株買いで株数を減らしている会社は conditions: [{metric: "shareCountChange5y", operator: "<=", value: -5}]。 5年(10年)前の年度が無い・決算期変更をまたぐ・分割調整できない会社は null(条件に使うと除外)。10年前の年度は自己株式数の記載が無いため、多くの会社で 純資産÷BPS から株数を推定しています。

  • operator「==」は厳密一致のため小数値の指標ではほぼヒットしません。範囲指定は >= と <= を組み合わせてください。

  • ヒット数が limit を超えた場合は結果ヘッダーに総ヒット数が表示されます。切れている場合は offset で続きを取得できます(例: limit=100, offset=100 で101〜200件目)。

  • 単一銘柄の詳細は get_edinet_financial_data、開示は get_timely_disclosures。

  • scores / verdict / alphaPct はラジ株ナビ独自算出値(日次バッチ更新)。

  • 【重要】dividendYield / dividendPerShare は有報の「当期確定実績」ベースです。 来期の会社予想配当ではありません。分母も市場株価ではなく擬似株価(PER×EPS)です。 記念配当・特別配当を含む年度では実績利回りが跳ね上がり、来期予想とは大きく乖離します (例: 7463 アドヴァンは実績100円で利回り10.89%だが、来期予想は40円)。 dividendYield / dividendPerShare / payoutRatio は特別配当・記念配当を含む合計です。特別配当・記念配当を除いた値は ordinaryDividendPerShare(普通配当)・ordinaryDividendYield(普通配当の配当利回り)、除いた額は specialDividendPerShare です (有報の配当に関する注記・配当政策の節・期末配当の注記から決めた値。get_edinet_financial_data の annualSpecialDividend・ get_ideal_price の配当価値と同じ値。特別配当を決められない年度は ordinaryDividendPerShare が合計、specialDividendPerShare が null)。 consecutiveDividendGrowthYears(連続増配年数)は普通配当で数えます。 高配当スクリーニングの結果は実績ベースの値です。個別銘柄の来期予想は get_earnings_forecast または get_edinet_financial_data の companyForecast で確認できます。

  • verdict フィルタは決算時点の擬似現価(pseudoPrice)ベースの理想株価モデル判定であり、 市場株価との比較ではありません。verdict 指定時は各行に pseudoPriceFiscalYearEnd (判定の基準となった決算期末日)を併記します。割安/割高はこの基準日時点の判定です。 verdictBasisType="asset_floor" の行は、理論株価の中央値が下支え(資産価値の7割)に張り付いており、判定(割高・超割高だけ)は 資産価値の7割との比較で決まっています。利益から見るとさらに割高寄りです。下支えの会社で割安・超割安・適正になる会社、 金融4業種、有報より新しい決算短信が出ていて有報待ちの会社は verdict が無い(判定を出していない)ため、verdict フィルタには掛かりません。

  • 【重要】sort.metric に alphaPct(α値)または upperAlphaPct を指定した場合、擬似現価の 鮮度(pseudoPriceFreshness)で並び替えを補正します。stale(決算から7-12ヶ月経過)/ obsolete(13ヶ月超)の銘柄は、α値がどれだけ高くても同ランク内の下位に降格されます (除外はされません。件数・フィルタ結果は変わらず並び順だけが変わります)。 3月決算企業が9月前後にほぼ全社該当する aging(4-6ヶ月)は降格しません。 この場合、各行に pseudoPriceFreshness / pseudoPriceAgeMonths を併記します(順位が低い理由が鮮度のことがあります)。

  • sector(業種)・market(市場)・verdict(5段階判定)は指標ではないので、トップレベルの sector / market / verdict 引数で指定してください。conditions に {metric: "sector", operator: "==", value: "情報・通信業"} のように入れても受け付け、トップレベルの指定として扱います(応答の interpretedAs に記載。トップレベルの指定と食い違うときはエラー)。oneOffSuspected は指標ではなく、conditions には入れられません(除くには excludeFlagged: true)。

  • 応答が大きいとき: compact=true にすると、返す列を code・companyName・条件/並べ替え/fields の指標だけに絞り(業種・市場・決算期・長い注記を省略)、応答を小さくできます。毎日の一覧用途向け。

  • excludeFlagged=true にすると、一過性の疑い(oneOffSuspected)・擬似株価が13ヶ月超古い(obsolete)・配当性向が500%超の銘柄を結果から除き、除いた件数を理由別にヘッダーに表示します(stale は除かない)。

  • oneOffSuspected: true の銘柄は特別損益で純利益・EPS・PER・理論株価・スコアが嵩上げされている可能性があります。 特別損益は get_edinet_financial_data で確認できます。

実力の値([実力] の指標・basis):

  • 実力の値は、特別損益・事業の売却益・減損などの一過性の損益を除いて試算した値です。一過性の損益が無い会社は公表の値と同じです。

  • normalizedEps・normalizedPer・normalizedRoe・normalizedRoa・normalizedPayoutRatio・normalizedTotalReturnRatio・normalizedOperatingMargin・normalizedNetIncome は conditions・sort・fields にそのまま使えます(一過性の損益が無い会社は公表と同じ値。全社で比べられます)。

  • 既定(basis 省略・reported)で、conditions に実力の値がある指標(per・roe・roa・eps・payoutRatio・totalReturnRatio・operatingMargin・netIncome)を 使い、結果に一過性の損益で公表と実力が違う会社が含まれるときは、応答の最後に、該当の社数と例(公表→実力)と「実力の値で絞り直しますか?」という問いかけが付きます。

  • basis="normalized" は、conditions と sort のそれらの指標を実力の欄に置き換えて判定・並べ替えし、結果に公表と実力を並べて差の主な理由(normalizedReasons)を添えます。

応答の metricLabels は英語キー→日本語指標名の対訳です。利用者向けには日本語名(例: roe→「ROE(自己資本利益率)」)のほうが伝わりやすくなります。 データ品質・値の異常・不具合に触れる場合も同様で、フィールド名を示すときは「発行済株式数(sharesOutstanding)」のように日本語を主・英語キーを括弧内にすると読みやすくなります。 (出力は { metricLabels, results } 形式。銘柄配列は results に入ります)

※ 本データは情報提供を目的とし、投資助言・推奨ではありません。

NameRequiredDescriptionDefault
sortNo結果のソート(省略時はROE降順)。metric に alphaPct/upperAlphaPct を指定した場合、擬似現価の鮮度が古い銘柄(stale/obsolete)は同ランク内の下位に自動で降格されます(除外はされません)。
basisNo判定に使う値。reported=公表の値(有報の記載どおり。既定)/ normalized=実力の値(一過性の損益を除いた試算。PER・ROE・ROA・EPS・配当性向・総還元性向・営業利益率・純利益を normalizedPer などの実力の欄に置き換えて判定し、結果に公表と実力を並べて差の理由を添える)。一過性の損益が無い会社は公表と同じ値。reported の応答の最後に「実力の値で絞り直しますか?」が付いた条件は、normalized で呼び直すと実力の値で判定し直せる。
limitNo返す件数の上限(デフォルト: 30、最大: 100)
fieldsNo結果に追加で含めたい指標キーの配列(例: ["roe", "marketCap"])。条件・ソートで使った指標と基本情報は自動で含まれます。最大50件。
marketNo市場で絞り込み(例: プライム)
offsetNoスキップする件数(ページング用。例: limit=100, offset=100 で101〜200件目)
sectorNo業種で絞り込み(例: 情報・通信業。中黒の全角/半角どちらでも可)
compactNotrue で返す列を code・companyName・条件/並べ替え/fields の指標(と必須の鮮度・実績ラベル)だけに絞る。既定 false(従来どおり)。
verdictNo理想株価モデルの5段階判定でフィルタ(複数指定=OR)。例: ["超割安", "割安"]
conditionsYesスクリーニング条件の配列(AND条件。最大20件)
excludeFlaggedNotrue で oneOffSuspected・擬似株価 obsolete・配当性向500%超の銘柄を除外し、件数を理由別にヘッダーで返す。既定 false。

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnly/openWorld annotations it discloses a great deal an agent could not infer: null-metric rows are silently dropped, financials get null FCF metrics, unit traps (foreignShareholdingRatio at 0-1 vs roe at %), '==' will almost never match decimals, limit default 30 / max 100 with offset paging, excludeFlagged removal reasons, compact column trimming, alphaPct sort demotion by pseudoPriceFreshness, and the { metricLabels, results } response shape.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loading is good — purpose, then 使い分け, then coverage — and headers organize the bulk. But the ~150-entry metric catalog plus repeated caveats (fcfYield is explained both in the metric list and again in 注意; special/ordinary dividend handling is restated at length) make it far longer than a caller needs, and parts of the catalog belong in schema/docs rather than the description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 11-parameter screening tool with no output schema, everything an agent needs is present: allowed metrics with units, condition semantics, null/coverage behavior, sort/freshness rules, pagination, and response format. The only gap is leaving return row contents implicit, which the metricLabels note largely covers.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it enumerates the complete metric key vocabulary with units, explains that sector/market/verdict are top-level rather than conditions, that oneOffSuspected is not a valid condition metric, that basis=normalized swaps out per/roe/eps etc., and that dividendYield is trailing actual on a pseudo price rather than forecast.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a specific verb, resource and scope ("全上場企業(約3,700社)の財務データからスクリーニング", returns matching 銘柄). The 使い分け section explicitly contrasts it with screen_by_framework, so an agent can pick the right tool without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use/when-not rules: framework-style vague requests go to screen_by_framework, fine-grained metric+threshold combinations go here, with a concrete example query. It also routes single-stock lookups to get_edinet_financial_data and disclosures to get_timely_disclosures, and forecast checks to get_earnings_forecast.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_stocks銘柄検索A
Read-only
Inspect

会社名・証券コードから銘柄を検索します(ひらがな・カタカナ・全角半角・大文字小文字の揺れを自動吸収)。 旧社名(例: 日本電産→ニデック)・英語名・通称や略称(例: MUFG・SMBC・JR東日本)でも検索でき、各結果の matchedBy にどの名前で一致したか(currentName / formerName / englishName / code / alias)を返します。 証券コードは「7203.T」「7203」「TSE:7203」の形でも受け付けます。 現在上場中の会社に一致が無く、上場廃止の会社に一致があるときは、delistedMatches(社名・コード・最終有報提出日)で案内します。 用途: 『トヨタの銘柄コードは?』のような名前→コード解決。 見つけたコードは get_edinet_financial_data 等の code 引数に渡せます。

※ 本データは情報提供を目的とし、投資助言・推奨ではありません。

NameRequiredDescriptionDefault
limitNo返す件数の上限(デフォルト: 10、最大: 50)
queryYes会社名または証券コード(部分一致可)

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description goes further, disclosing normalization behavior, the delisted-match fallback (delistedMatches with last report date), and the matchedBy return field — real behavioral context. It doesn't cover pagination or rate limits, keeping it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and usage are front-loaded, and the disclaimer is a required element. It is somewhat long with several parenthetical examples, but each sentence carries distinct information (matching scope, return fields, delisted fallback, code formats), so little is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by explaining the matchedBy return field and the delistedMatches structure. Combined with code-format acceptance and the usage example, it is complete enough for an agent to call and interpret the tool, though it doesn't describe limit/pagination semantics.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, giving a baseline of 3. The description adds meaning beyond the schema by enumerating accepted code formats ('7203.T', '7203', 'TSE:7203') and the automatic normalization of character-width/case, which the schema does not express.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: searching stocks by company name or securities code. It distinguishes itself clearly from siblings like screen_stocks and list_edinet_stocks by framing itself as name→code resolution and by detailing the fuzzy-matching scope (former names, English names, aliases).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit use case ('トヨタの銘柄コードは?' → name→code resolution) and points to a downstream consumer (pass the code to get_edinet_financial_data's code argument). It doesn't explicitly say when to prefer it over screen_stocks or list_edinet_stocks, so it stops short of full when/when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_watchlist_note監視リストのメモ・株数・分類を更新A
DestructiveIdempotent
Inspect

監視リストに登録済みの銘柄の、メモ(note)・株数(shares)・取得単価(acquisitionPrice)・分類(category)を書き換えます。 監視リストの銘柄は、お気に入り(ポートフォリオ。category: favorite)と監視(category: watching)に分かれます。 お気に入り(ポートフォリオ)は、保有などを自分で管理する銘柄で、株数(shares)と取得単価(acquisitionPrice・円)を任意で持てます。株数を入れれば保有(holding: true)として扱います。メモは付けられません。 「ポートフォリオに入れて」「お気に入りに入れて」という依頼は category: favorite にあたります。 監視は、気になる銘柄です。メモを付けられます。分類を省略すると監視になります。 同じ銘柄をお気に入りと監視の両方に入れられます(その場合は分類ごとに別の項目です)。 指定した項目だけを変えます。登録日・前回確認日は変わりません(削除して登録し直すと、登録日がリセットされます)。

category(favorite / watching)で、どちらの分類の項目を書き換えるかを指定できます。省略したときは、その銘柄が片方の分類にしか無ければそちらを書き換え、両方にあればエラーで category の指定を求めます。 分類を移す: moveTo: favorite で監視からお気に入り(ポートフォリオ)へ、moveTo: watching でお気に入りから監視へ移します。 移す先に同じ銘柄が既にあるときは移しません。お気に入りから監視へ移すと、株数・取得単価は消えます。監視の件数が上限のときは監視へ移せません。 株数・取得単価: お気に入りにだけ付けられます。null を渡すと消えます。

メモ: 監視の銘柄にだけ付けられます。元のメモは上書きされます。追記するときは、get_watchlist で今のメモを読んでから全文を渡すと、元の内容を残せます。 空文字を渡すと、メモを消します。 メモの上限: 300文字(超えた分は切り詰め、truncated: true)。 登録されていない銘柄は notFound: true で返します(登録はしません。登録は add_to_watchlist)。

※ 本データは情報提供を目的とし、投資助言・推奨ではありません。

NameRequiredDescriptionDefault
codeYes証券コード(例: 7203、140A)
noteNo新しいメモの全文(任意。監視だけ)。空文字でメモを消す
moveToNo分類を移す先(任意)。favorite = お気に入り(ポートフォリオ)、watching = 監視
sharesNo株数(任意。お気に入りだけ。正の数。null で消す)
categoryNo書き換える項目の分類(任意)。favorite = お気に入り(ポートフォリオ)、watching = 監視
acquisitionPriceNo取得単価・円(任意。お気に入りだけ。正の数。null で消す)

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the destructiveHint=true annotation, the description discloses concrete destructive behavior: notes are overwritten wholesale, an empty string erases the note, 300-char overflow is truncated and flagged with truncated: true, and moving favorite→watching silently deletes shares and acquisitionPrice. It also documents the watching-count upper limit blocking a move and the partial-update guarantee (registration/last-check dates unchanged).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The operation is front-loaded in sentence one and the body is organized by concern (categories, moveTo, shares, note, limits, errors). It is long but nearly every sentence carries a distinct rule; minor tightening of the category explanations would be possible.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description still communicates the return signals an agent needs (notFound: true, truncated: true) and covers all six parameters plus the cross-category edge cases. Nothing essential for correct invocation is missing for a mutation tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Even with 100% schema coverage, the description adds meaning the schema cannot: shares/acquisitionPrice are only valid on favorite and null clears them, note is only valid on watching and empty string clears it, and category omission has conditional fallback/error semantics. These are genuine semantic rules, not restatements of the field descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence names a specific verb (書き換えます) and the exact resources it touches (note, shares, acquisitionPrice, category) on an already-registered watchlist stock. It is immediately distinguishable from siblings add_to_watchlist (which registers), get_watchlist (which reads) and remove_from_watchlist.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly routes the agent: unregistered codes return notFound and the description names add_to_watchlist instead; to append a note it tells the agent to read via get_watchlist first and pass the full text. It also states when to use moveTo versus category, and what happens when category is omitted (single match rewritten, ambiguous match errors out).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Changedget_edinet_financial_data1 field changed
      • changedInput schema / properties / metrics / description
        Previous value: -"取得する指標名の配列(省略時は全指標を返します。fiscalYear も省略すると直近2期だけ返します)。日本語名や略語(例: 「PER」「自己資本比率」)は内部で英語キーに正規化されますが、原則は英語キー推奨。【主要指標の日本語対応】per(PER / priceEarningsRatio), pbr(PBR / priceBookValueRatio), roe(ROE / 自己資本利益率), roa(ROA), equityRatio(自己資本比率), operatingMargin(営業利益率), dividendYield(配当利回り), payoutRatio(配当性向), doe(DOE / 株主資本配当率), fcf(簡易フリーCF=営業CF+投資CF。DCFのbaseFCFとは別定義), ebitda(EBITDA), marketCap(時価総額), netCash(ネットキャッシュ), salesGrowth(売上成長率)。【利用可能な全指標】[P/L] netSales, operatingRevenue2(営業収入。テナント収入・加盟店からの収入・不動産賃貸収入等。JGAAPのみ、原本に無ければ省略), netSalesIncludesOperatingRevenue2(netSalesに既にoperatingRevenue2が含まれているか。true=合計行のため足すと二重計上、false=netSalesは売上高のみで含まない。operatingRevenue2がある年度のみ付与), operatingIncome, ordinaryIncome, netIncome, costOfGoodsSold, grossProfit, sellingGeneralAndAdministrative, incomeBeforeIncomeTaxes, nonOperatingIncome, nonOperatingExpenses, extraordinaryIncome, extraordinaryLoss, incomeTaxes, comprehensiveIncome [B/S] totalAssets, netAssets, equity, retainedEarnings, currentAssets, currentLiabilities, noncurrentAssets, noncurrentLiabilities, totalLiabilities, capitalStock, capitalSurplus, cashAndDeposits, marketableSecurities, investmentSecurities, shortTermBorrowings, currentPortionOfLongTermDebt, longTermDebt, bondsPayable, currentPortionOfBonds, commercialPapers, accountsReceivable, inventories, accountsPayable, propertyPlantAndEquipment, goodwill, intangibleAssets(日本基準はのれんを含む無形固定資産合計、国際会計基準はのれんを含まない。intangibleAssetsIncludesGoodwill=true の年度はのれんを含む), land, buildingsAndStructures, nonControllingInterests, deferredTaxAssets, deferredTaxLiabilities, retirementBenefitLiability, leaseObligations, accumulatedOCI [C/F] cashFlowFromOperations, cashFlowFromInvesting, cashFlowFromFinancing, cashAndEquivalents, capitalExpenditure(設備投資。原則はCF計算書の有形+無形の取得、CF計算書から取れない年度は有報の注記(capexSource=note)。投資不動産の取得を含むと分かった年度は capexIncludesInvestmentProperty=true が付く。付かなくても行名が「有形固定資産及び投資不動産の取得」の会社(2120・2811・5411・9158 等)は投資不動産を含む), depreciationAndAmortization, dividendsPaid, purchaseOfTreasuryShares, proceedsFromDisposalOfTreasuryShares, proceedsFromBorrowings, repaymentOfBorrowings, incomeTaxesPaid [1株] eps, bps, dividendPerShare(特別配当・記念配当を含む合計), ordinaryDividendPerShare(普通配当), specialDividendPerShare(特別配当・記念配当), specialDividendSource, specialDividendCompleteness, dilutedEps [バリュエーション] per, pbr, priceEarningsRatio, priceBookValueRatio, dividendYield [株式] sharesOutstanding, treasuryShares [識別/原典] docId, edinetFilingUrl [その他] numberOfEmployees, researchAndDevelopment, interestExpense, accountingStandard [計算指標] roe, roa, operatingMargin, ordinaryMargin(経常利益率。金融業ではoperatingMarginの代わりにこちらを参照), netProfitMargin, grossProfitMargin, equityRatio, currentRatio, payoutRatio, doe, fcf, netCash, interestBearingDebt, interestBearingDebtBroad, ibdSource, debtToEquityRatio, operatingCFMargin, fcfMargin, accrualRatio, dso, dio, dpo, cashConversionCycle, assetTurnover, ebitda, ebitdaMargin, sgaRatio, interestCoverageRatio, rdRatio, capexRatio, salesPerEmployee, operatingIncomePerEmployee, operatingCFToDebt, retainedEarningsRatio, goodwillRatio, effectiveTaxRate, totalShareholderReturn, totalReturnRatio, netDebt, netDebtToEbitda, tangibleEquity, tangibleEquityRatio [構造化データ] segments(セグメント別売上・営業利益・経常利益・資産), directors(役員一覧), directorRemunerationBreakdown(役員報酬カテゴリ別), crossShareholdings(政策保有株式銘柄別明細), crossShareholdingTotalBookValue, crossShareholdingIssuesCount, crossShareholdingsDeemed(提出会社のみなし保有株式の明細。金額は時価), crossShareholdingDeemedMarketValueRowsSum(みなし保有株式の時価の行の足し上げ), crossShareholdingsHoldingCompanies(最大保有会社・次に大きい会社の明細), crossShareholdingLargestHoldingCompanyName, crossShareholdingLargestHoldingCompanyTotalBookValue, crossShareholdingLargestHoldingCompanyIssuesCount, crossShareholdingSecondLargestHoldingCompanyName, crossShareholdingSecondLargestHoldingCompanyTotalBookValue, crossShareholdingSecondLargestHoldingCompanyIssuesCount, majorShareholders(大株主上位10名), foreignShareholdingRatio, individualShareholdingRatio, institutionalShareholdingRatio"New value: +"取得する指標名の配列(省略時は全指標を返します。fiscalYear も省略すると直近2期だけ返します)。日本語名や略語(例: 「PER」「自己資本比率」)は内部で英語キーに正規化されますが、原則は英語キー推奨。【主要指標の日本語対応】per(PER / priceEarningsRatio), pbr(PBR / priceBookValueRatio), roe(ROE / 自己資本利益率), roa(ROA), equityRatio(自己資本比率), operatingMargin(営業利益率), dividendYield(配当利回り), payoutRatio(配当性向), doe(DOE / 株主資本配当率), fcf(簡易フリーCF=営業CF+投資CF。DCFのbaseFCFとは別定義), ebitda(EBITDA), marketCap(時価総額), netCash(ネットキャッシュ), salesGrowth(売上成長率)。【利用可能な全指標】[P/L] netSales, operatingRevenue2(営業収入。テナント収入・加盟店からの収入・不動産賃貸収入等。JGAAPのみ、原本に無ければ省略), netSalesIncludesOperatingRevenue2(netSalesに既にoperatingRevenue2が含まれているか。true=合計行のため足すと二重計上、false=netSalesは売上高のみで含まない。operatingRevenue2がある年度のみ付与), operatingIncome, ordinaryIncome, netIncome, costOfGoodsSold, grossProfit, sellingGeneralAndAdministrative, incomeBeforeIncomeTaxes, nonOperatingIncome, nonOperatingExpenses, extraordinaryIncome, extraordinaryLoss, incomeTaxes, comprehensiveIncome [B/S] totalAssets, netAssets, equity, retainedEarnings, currentAssets, currentLiabilities, noncurrentAssets, noncurrentLiabilities, totalLiabilities, capitalStock, capitalSurplus, cashAndDeposits, marketableSecurities, investmentSecurities, shortTermBorrowings, currentPortionOfLongTermDebt, longTermDebt, bondsPayable, currentPortionOfBonds, commercialPapers, accountsReceivable, inventories, accountsPayable, propertyPlantAndEquipment, goodwill, intangibleAssets(日本基準はのれんを含む無形固定資産合計、国際会計基準はのれんを含まない。intangibleAssetsIncludesGoodwill=true の年度はのれんを含む), land, buildingsAndStructures, nonControllingInterests, deferredTaxAssets, deferredTaxLiabilities, retirementBenefitLiability, leaseObligations, accumulatedOCI [C/F] cashFlowFromOperations, cashFlowFromInvesting, cashFlowFromFinancing, cashAndEquivalents, capitalExpenditure(設備投資。原則はCF計算書の有形+無形の取得、CF計算書から取れない年度は有報の注記(capexSource=note)。投資不動産の取得を含むと分かった年度は capexIncludesInvestmentProperty=true が付く。付かなくても行名が「有形固定資産及び投資不動産の取得」の会社(2120・2811・5411・9158 等)は投資不動産を含む), depreciationAndAmortization, dividendsPaid, purchaseOfTreasuryShares, proceedsFromDisposalOfTreasuryShares, proceedsFromBorrowings, repaymentOfBorrowings, incomeTaxesPaid [1株] eps, bps, dividendPerShare(特別配当・記念配当を含む合計), ordinaryDividendPerShare(普通配当), specialDividendPerShare(特別配当・記念配当), specialDividendSource, specialDividendCompleteness, dilutedEps [バリュエーション] per, pbr, priceEarningsRatio, priceBookValueRatio, dividendYield [株式] sharesOutstanding, treasuryShares [識別/原典] docId, edinetFilingUrl [その他] numberOfEmployees(連結を作る会社は連結の人数), researchAndDevelopment, interestExpense, accountingStandard [計算指標] roe, roa, operatingMargin, ordinaryMargin(経常利益率。金融業ではoperatingMarginの代わりにこちらを参照), netProfitMargin, grossProfitMargin, equityRatio, currentRatio, payoutRatio, doe, fcf, netCash, interestBearingDebt, interestBearingDebtBroad, ibdSource, debtToEquityRatio, operatingCFMargin, fcfMargin, accrualRatio, dso, dio, dpo, cashConversionCycle, assetTurnover, ebitda, ebitdaMargin, sgaRatio, interestCoverageRatio, rdRatio, capexRatio, salesPerEmployee, operatingIncomePerEmployee, operatingCFToDebt, retainedEarningsRatio, goodwillRatio, effectiveTaxRate, totalShareholderReturn, totalReturnRatio, netDebt, netDebtToEbitda, tangibleEquity, tangibleEquityRatio [構造化データ] segments(セグメント別売上・営業利益・経常利益・資産), directors(役員一覧), directorRemunerationBreakdown(役員報酬カテゴリ別), crossShareholdings(政策保有株式銘柄別明細), crossShareholdingTotalBookValue, crossShareholdingIssuesCount, crossShareholdingsDeemed(提出会社のみなし保有株式の明細。金額は時価), crossShareholdingDeemedMarketValueRowsSum(みなし保有株式の時価の行の足し上げ), crossShareholdingsHoldingCompanies(最大保有会社・次に大きい会社の明細), crossShareholdingLargestHoldingCompanyName, crossShareholdingLargestHoldingCompanyTotalBookValue, crossShareholdingLargestHoldingCompanyIssuesCount, crossShareholdingSecondLargestHoldingCompanyName, crossShareholdingSecondLargestHoldingCompanyTotalBookValue, crossShareholdingSecondLargestHoldingCompanyIssuesCount, majorShareholders(大株主上位10名), foreignShareholdingRatio, individualShareholdingRatio, institutionalShareholdingRatio [従業員の状況(提出会社。2019年3月期以降の有報)] avgAnnualSalary(平均年間給与・円。提出会社(単体)の従業員の平均で、賞与・基準外賃金を含む。連結の従業員の平均ではない), avgAgeYears(平均年齢・歳。提出会社の従業員), avgTenureYears(平均勤続年数・年。提出会社の従業員), numberOfEmployeesNonConsolidated(提出会社(単体)の従業員数・人。臨時従業員を含まない), parentPayrollEstimate(本体の人件費のめやす・円=avgAnnualSalary×numberOfEmployeesNonConsolidated。臨時従業員・法定福利費・退職給付費用・役員報酬は含まず、損益計算書の人件費とは一致しない。avgAnnualSalary を連結の numberOfEmployees と掛けないこと(子会社の人数まで本体の給与水準で数えて膨らむ)。出さない年度は parentPayrollEstimateUnavailableReason:holding_company=持株会社(有報の事業の内容に特定上場会社等と記載。本社部門の人件費で事業の人件費を表さない)/parent_headcount_tiny=提出会社の従業員数が連結の1%未満/no_parent_employees=提出会社の従業員数の合計が有報に無い/holding_status_unknown=持株会社かを未判定), avgAnnualSalaryUnavailable(out_of_range=有報の平均年間給与の数値が150万〜5,000万円の範囲外で、桁の付け間違いとみなして avgAnnualSalary に入れていない。原本の値は avgAnnualSalaryAsFiled)"
  2. 1 tool update
    • Changedscreen_stocks1 field changed
      • changedInput schema / properties / conditions / anyOf
        Previous value: -[
        -  {
        -    "type": "string"
        -  },
        -  {
        -    "items": {
        -      "properties": {
        -        "metric": {
        -          "description": "指標の英語キー名(例: roe, operatingMargin, equityRatio, salesGrowth, netCash, fcf, dividendPerShare, dividendYield, payoutRatio, marketCap, evToEbitda, priceEarningsRatio)。日本語名や略語(例: 「自己資本比率」「PER」)は内部で英語キーに正規化されますが、原則は英語キーを推奨。",
        -          "type": "string"
        -        },
        -        "operator": {
        -          "description": "比較演算子",
        -          "enum": [
        -            ">=",
        -            "<=",
        -            ">",
        -            "<",
        -            "=="
        -          ],
        -          "type": "string"
        -        },
        -        "value": {
        -          "description": "比較値",
        -          "type": [
        -            "string",
        -            "number"
        -          ]
        -        }
        -      },
        -      "required": [
        -        "metric",
        -        "operator",
        -        "value"
        -      ],
        -      "type": "object"
        -    },
        -    "type": "array"
        -  }
        -]New value: +[
        +  {
        +    "type": "string"
        +  },
        +  {
        +    "items": {
        +      "properties": {
        +        "metric": {
        +          "description": "指標の英語キー名(例: roe, operatingMargin, equityRatio, salesGrowth, netCash, fcf, dividendPerShare, dividendYield, payoutRatio, marketCap, evToEbitda, priceEarningsRatio)。日本語名や略語(例: 「自己資本比率」「PER」)は内部で英語キーに正規化されますが、原則は英語キーを推奨。",
        +          "type": "string"
        +        },
        +        "operator": {
        +          "description": "比較演算子",
        +          "enum": [
        +            ">=",
        +            "<=",
        +            ">",
        +            "<",
        +            "=="
        +          ],
        +          "type": "string"
        +        },
        +        "value": {
        +          "description": "比較値(数値)。例外として metric が sector / market / verdict のときだけ文字列(演算子は \"==\")で、トップレベルの同名引数として扱われます。",
        +          "type": [
        +            "string",
        +            "number"
        +          ]
        +        }
        +      },
        +      "required": [
        +        "metric",
        +        "operator",
        +        "value"
        +      ],
        +      "type": "object"
        +    },
        +    "type": "array"
        +  }
        +]

Publisher details

Operator
Radikabunavi (ラジ株ナビ) · Publisher source
Operator website
https://radikabunavi.com
Vendor relationship
First-party · Publisher source
Trust center
Not available
Restrictions
Free sign-up (Google or Apple) gives 100 calls/day, with all tools and quarterly data (Q1-Q3) included. Paid plans (from JPY 500/month) raise the daily limit and the watchlist size. No admin approval, regional limit or custom OAuth app is required. · Publisher source

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    C
    maintenance
    Structured financial data for ~3,800 Japanese listed companies from EDINET regulatory filings — financials, major shareholders, segments, executive compensation, and corporate history. Remote MCP over HTTPS with OAuth 2.0, free tier.
    13
    1
    MIT
  • A
    license
    Not graded
    quality
    C
    maintenance
    Provides programmatic access to Japan's EDINET system to search for listed companies and retrieve annual or quarterly financial reports. It parses XBRL filings into structured data, enabling AI assistants to analyze balance sheets, income statements, and cash flows.
    131 PyPI
    19
    Apache 2.0
  • A
    license
    Not graded
    quality
    D
    maintenance
    Enables access and analysis of Japanese corporate financial data (PL/BS/CF) via EDINET API. Supports searching companies, listing reports, and comparing financials through natural language queries.
    1
    MIT
Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources