> ## Documentation Index
> Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# システムステータス

> ネットワーク、取引所、ブリッジが正常に動いているかを確認する方法。誰かの公表を待たずに自分で検証できることも含みます。

<Note>
  公開のステータスページは[2026年9月20日のパブリックテストネット](/ja/protocol/roadmap/milestones)と同時に公開します。それまでは、以下の確認方法がネットワークの状況を知る正式な手段です。公開後も正式な手段であり続けます。報告ではなくチェーンそのものを読むからです。
</Note>

<h2 id="check-the-chain-directly">
  チェーンを直接確認する
</h2>

最も信頼できる情報は、誰かが保守しているページではありません。チェーンそのものであり、リクエスト1回で答えが返ります。

ノードのRPCルートは、ネットワークの現在の状態を返します。

```json theme={null}
{
  "chain_id": 2,
  "node_role": "validator",
  "block_height": "1540443",
  "ledger_version": "5046975",
  "epoch": "125",
  "oldest_ledger_version": "0"
}
```

数秒あけて2回呼び出してください。**`block_height`が進んでいれば、ネットワークはブロックを生成しています**。[マッチング、クリアリング、強制決済はすべてブロック実行の内部で走る](/ja/protocol/architecture/kernel)ため、ブロックを生成しているネットワークとは、マッチングし、クリアリングし、強制決済している取引所そのものです。チェーンが動いている一方で停止しうるような、別立ての取引所プロセスは存在しません。

これは運用上の主張ではなく、構造上の性質です。マッチングエンジンがチェーンの横のサービスとして動く取引所では、「チェーンは正常だ」と「取引ができる」は本当に別の問いです。ここでは同じ問いです。

エンドポイントは[現在のネットワーク](/ja/protocol/architecture/network-status)に掲載しています。

<h2 id="what-can-actually-be-degraded">
  実際に劣化しうるもの
</h2>

独立して障害を起こし*うる*ものはあります。それぞれ観測できる形で壊れるので、名前で把握しておく価値があります。

| 構成要素                                                | 症状                        | それでも動くもの                   |
| --------------------------------------------------- | ------------------------- | -------------------------- |
| **[インデクサー](/ja/protocol/architecture/indexer)**     | 履歴クエリやストリームが遅延・停止する       | 取引。注文の送信と実行はインデクサーに依存しない   |
| **[オラクル](/ja/protocol/architecture/oracle)**        | あるマーケットのインデックス価格が更新されなくなる | 板。そのマーケットのマーク価格と資金調達率は劣化する |
| **[ブリッジ](/ja/protocol/architecture/bridge)**        | 入金または出金が止まる               | すでに保有している残高での取引            |
| **[プログラムサービス](/ja/protocol/architecture/programs)** | 手数料ティアが更新されなくなる           | 取引。適用中の料率のまま継続する           |
| **Webフロントエンド**                                      | サイトに接続できない                | すべて。APIを通じて利用できる           |

この共通点には名前をつける価値があります。**取引の経路は、これらのいずれにも依存していません**。それぞれは、チェーンがすでに受理した入力として実行の上流にあるか、チェーンがコミットした内容の読み手として下流にあります。どちらの位置からも、ブロックを止めることはできません。

統合する側にとっての帰結は、「インデクサーが遅れている」と「注文が執行されなかった」が無関係な診断だということです。これらを1つの兆候として扱えば、見当違いの場所を探すことになります。

<h2 id="checking-your-own-view">
  自分の側の状態を確認する
</h2>

そのRPCレスポンスの2つのフィールドが、ふだんサポートに寄せられる質問に答えます。

**`chain_id`は、どのネットワークに接続しているかを示します**。残高がまったく見えないクライアントは、障害に遭っているよりも、誤ったネットワークを向いていることのほうがはるかに多いです。

**`oldest_ledger_version`は、そのノードがどこまで遡って履歴を保持しているかを示します**。強く剪定されたノードは、現在の状態は正しく返しながら、履歴クエリにはまったく答えられません。データの消失のように見えますが、そうではありません。[ステート同期](/ja/protocol/architecture/state/sync)を参照してください。

<h2 id="what-the-status-page-will-cover">
  ステータスページで扱う内容
</h2>

パブリックテストネットと同時に公開したあとは、次の内容を掲載します。

* **構成要素ごとのステータス**。上記の各構成要素を、1つの指標にまとめず個別に報告する
* **計画メンテナンス**。実施時間帯と想定される影響を添えて事前に告知する
* **障害の履歴**。解消時に消さず、残す
* **障害発生中の逐次更新**

実行、資金、建っているポジションに影響する障害は[プロトコル変更履歴](/ja/protocol/roadmap/changelog)にも記録します。恒久的な記録が、ステータスページだけに存在することのないようにするためです。

<h2 id="reporting-a-problem">
  問題を報告する
</h2>

何かがおかしく見えて、なおチェーンがブロックを生成している場合、原因は特定の構成要素か、自分の統合にある可能性が高くなります。何をしていたか、エンドポイント、あればトランザクションハッシュまたは注文ID、ブロック高またはタイムスタンプを記載してください。

送り先は`contact@intention.xyz`です。脆弱性の疑いがある場合は、代わりに[バグバウンティ](/ja/protocol/security/bug-bounty)の手続きを使ってください。件名に**Security**と記載すると、通常のメールより優先して振り分けられます。

<h2 id="where-to-go-next">
  次に読む
</h2>

<CardGroup cols={2}>
  <Card title="現在のネットワーク" href="/ja/protocol/architecture/network-status">
    チェーンの識別情報、稼働中のエンドポイント、想定しておくべきことです。
  </Card>

  <Card title="プロトコル変更履歴" href="/ja/protocol/roadmap/changelog">
    リリースと障害の、日付付きの記録です。
  </Card>

  <Card title="サポートへの問い合わせ" href="/ja/help/contact">
    チームへの連絡方法です。
  </Card>

  <Card title="開発者" href="/ja/developers/overview">
    APIと、緩やかに機能低下する統合の作り方です。
  </Card>
</CardGroup>