Skip to main content
Glama

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

決算速報

get_earnings_flash
Read-only

当日または直近営業日の決算速報(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 で確認できます。

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

Input Schema

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)。

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / includeReits / description
      Previous value: -"REIT・投資法人を含めます。既定は除外。"New value: +"REIT・投資法人を含めます(決算短信・修正の両方)。既定は除外。"
    • addedInput schema / properties / revisionsLimit
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "maximum": 9007199254740991,
      +      "minimum": 0,
      +      "type": "integer"
      +    }
      +  ],
      +  "description": "業績予想・配当予想の修正(revisions)を返す件数。省略時 10、最大 30。0 で修正を返しません。"
      +}
    • addedInput schema / properties / revisionsOffset
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "maximum": 9007199254740991,
      +      "minimum": 0,
      +      "type": "integer"
      +    }
      +  ],
      +  "description": "revisions の並びで先頭から読み飛ばす件数(ページ送り用。省略時 0)。"
      +}
  2. Changed2 schema fields changed
    • changedInput schema / properties / limit / description
      Previous value: -"返す件数。上限 3。"New value: +"返す件数。省略時 10、最大 30(includeDetails=true のときは最大 5)。"
    • addedInput schema / properties / offset
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "maximum": 9007199254740991,
      +      "minimum": 0,
      +      "type": "integer"
      +    }
      +  ],
      +  "description": "注目度順で先頭から読み飛ばす件数(ページ送り用。省略時 0)。"
      +}
  3. First observed

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources