日レセAPIの全体像をソースコードから把握する ── ORCAの公開ソースを読む(全137エンドポイント対応表付き)

前回の記事では、ORCA(日医標準レセプトソフト)がレセコンであること、そして20年以上ソースコードが公開され続けていることを整理しました。

今回はそのソースコードを実際に読みます。テーマは日レセAPIの全体像を一次情報から把握すること。公式のAPI仕様書を上から読むのではなく、

1. サーバー側に実在する全エンドポイントをソースから数え上げ、
2. 1本のAPIを実装からレスポンスXMLの形まで追い、
3. 公式ドキュメントと突き合わせて差分を検証し、
4. バージョン間diffでAPIの変化を実測する

という順番でやってみます。記事末尾に、この調査で得られた全137エンドポイントの対応表(URL・COBOLプログラム・機能)を付けました。

本記事の調査対象は、公式公開されている日レセ本体 5.2系ソース(2026年7月1日公開スナップショット) で、比較対象として5.1系(同日公開) も使います。記述はすべてこの2つの版に基づき、再現に必要なコマンドを本文に示します。

目次

1. まず結論
2. 前提 ── ソースの入手とバージョン固定
3. APIディスパッチの仕組み ── URLはlddefで決まる
4. 発見:APIは「画面業務のAPI版」である ── bindとbindapi
5. 1本のAPIを最後まで追う ── patientgetv2の解剖
6. 全エンドポイントを数える ── grep一発の調査手順
7. 公式一覧と突き合わせる ── 一覧にないAPIの例
8. 未文書化APIの仕様をソースから導出する ── findv3の実例
9. 版間diffでAPIの変化を実測する ── 5.1系 vs 5.2系
10. 未文書化APIとの付き合い方 ── 「文書化」は保証ではない
11. 深追いするときの実務メモ
12. まとめ
13. 付録:全137エンドポイント対応表(5.2系・2026年7月版)
14. 参考資料

1. まず結論

• 日レセAPIのURLとサーバー側プログラムの対応は、ソースの lddef/*.ld(LD定義ファイル)に宣言的に書かれている。COBOLを読まなくても、テキストのgrepだけでAPIの全体像を列挙できる。
• 5.2系スナップショットでは、27個のLD定義に合計137個のエンドポイントがbindapiで束ねられている。公式サイトのAPI仕様一覧ページに掲載されているのは約50件で、ソース側にはその2倍以上のエンドポイントが実在する。
• XMLリクエスト・レスポンスの構造はrecord/*.dbに宣言されており、XMLタグ名は定義の項目名がそのまま使われる。つまり未文書化APIでも、lddef→cobol→recordと辿れば仕様を導出できる。
• 5.1系との版間diffを取ると、エンドポイントは9件追加・削除0件。追加分はオンライン資格確認(マイナ保険証)関連に集中しており、「APIは制度対応で増える。既存のものは(少なくともこの2系列間では)消えていない」ことが実測できる。
• 未文書化のAPIは「使ってはいけないAPI」ではない。ORCAはオープンソースであり、ソースそのものを一次仕様として扱える。問題は約束の有無ではなく「変更を自分で検知する運用を持てるか」で、その判断の枠組みを第10章で整理する。

2. 前提 ── ソースの入手とバージョン固定

ソースは公式の技術情報ページからtarボール(zip)でダウンロードできます。毎月1日に前月1日時点のスナップショットへ更新されるため、調査結果は必ず版とセットで記録するのが鉄則です。この記事では次の版を使っています。

• 入手元: https://ftp.orca.med.or.jp/pub/src/jma-receipt.r_5_2_branch.zip(比較用にr_5_1_branch.zipも)
• 取得日: 2026-07-17(いずれも2026年7月1日時点のスナップショット)
• 5.2系のVERSIONファイル: 5.2.0

展開すると約8,200ファイル・237MBで、この記事で使うのは主に次の3ディレクトリです。

3. APIディスパッチの仕組み ── URLはlddefで決まる

日レセAPIのURLは /api01rv2/patientgetv2 のように「モジュール名/エンドポイント名」の2段構成です。この対応はlddef/のLD定義ファイルにそのまま現れます。

lddef/api01rv2.ld の冒頭を見てみます。

name	api01rv2;

bindapi	"patientgetv2"	"OpenCOBOL"	"ORAPI012R1V2";
bindapi	"acceptlstv2"	"OpenCOBOL"	"ORAPI011R1V2";
bindapi	"appointlstv2"	"OpenCOBOL"	"ORAPI014R1V2";
...

読み方は素直で、LD名がURLの第1セグメント、bindapiの第1引数が第2セグメント、第3引数が処理を担当するCOBOLプログラム名です。つまり /api01rv2/patientgetv2 へのリクエストは、ORAPI012R1V2 というCOBOLプログラムに渡ります。

flowchart LR
    C["連携システム<br/>電子カルテなど"] -->|"GET /api01rv2/patientgetv2?id=患者番号"| M["日レセサーバー<br/>MONTSUQI"]
    M -->|"lddef/api01rv2.ld<br/>bindapi定義を参照"| P["ORAPI012R1V2.CBL<br/>患者基本情報取得"]
    P --> D[("PostgreSQL")]
    P -->|"XMLレスポンス"| C

LD定義にはこのほか、レスポンスの組み立てに使うXMLレコード群(db "xml2" { ... })や、押さえておくと便利な設定(配列サイズなど)も宣言されています。LDファイルは「そのモジュールが扱う画面・API・データ構造の目次」として読めます。

4. 発見:APIは「画面業務のAPI版」である ── bindとbindapi

LD定義を眺めていると、すぐに気づくことがあります。同じファイルにbind(画面)とbindapi(API)が同居しているのです。患者照会モジュールlddef/orca13.ldを見てみます。

name	orca13;

bind	"Q01"		"OpenCOBOL"	"ORCGQ01";     ← 患者照会の対話画面
bind	"Q02"		"OpenCOBOL"	"ORCGQ02";
...
bindapi "findv3"    "OpenCOBOL"	"ORCGQAPI01";  ← そのAPI版
bindapi "findinfv3" "OpenCOBOL"	"ORCGQAPI02";
bindapi "foundv3"   "OpenCOBOL"	"ORCGQAPI03";

Q01〜は医事スタッフが操作する患者照会画面のプログラム、findv3〜はそれと同じモジュールに属するAPIです。プログラム名もORCGQ01(画面)に対してORCGQAPI01(API)と、画面系の名前にAPIを挟んだ形になっています。

つまり日レセAPIは、独立したAPIサーバーとして設計されたものではなく、対話画面と同じ業務プログラム基盤の上に「画面の代わりにXMLで会話する入口」を業務モジュールごとに追加していったものです。この構造が分かると、次の2つが自然に理解できます。

• URLの第1セグメント(orca13、orca42…)が画面の業務番号に由来していて、APIとしては一見無意味な数字に見える理由
• 「画面でできる業務にはAPI版が存在するかもしれない」という探し方が成立する理由──未文書化APIを探すというのは、実はこの「画面業務のAPI版」を列挙する作業に近い

5. 1本のAPIを最後まで追う ── patientgetv2の解剖

全体像を数える前に、1本のAPIを実装からレスポンスの形まで追ってみます。題材は最も基本的な患者基本情報取得 /api01rv2/patientgetv2 です。

(1) ディスパッチ: lddef/api01rv2.ld の bindapi "patientgetv2" → ORAPI012R1V2。実体は cobol/api01rv2/ORAPI012R1V2.CBL(2,163行)。COBOLソースは原則としてLD名と同じディレクトリに置かれるので、lddefが読めれば実装ファイルはほぼ機械的に特定できます(例外もあり、たとえばorca51のAPI群の実体はcobol/orca52/にあります。確実なのはプログラム名でのfind)。

(2) プログラムヘッダ: 冒頭に「コンポーネント名 : 患者基本情報取得(version2対応)」とあり、続く修正履歴には2013年の地域連携ID対応から、2022年の電子処方箋対応、2024年の「保険証による資格有効性返却対応」まで、この1本のAPIが受けてきた制度改定が年表として並んでいます。API仕様書の「更新履歴」より詳細です。

(3) 何を読んでいるか: WORKING-STORAGE SECTIONのCOPY句(取り込む共通定義)を見ると、このAPIが触るデータが分かります。抜粋すると:

COPY "CPPTINF.INC".          *> 患者基本情報(tbl_ptinf)
COPY "CPPTNUM.INC".          *> 患者番号
COPY "CPJYURRK.INC".         *> 受療履歴
COPY "CPPTCARE-HKNINF.INC".  *> 介護保険情報
COPY "CPPTMYNUMBER.INC".     *> 患者個人番号
COPY "CPONSHI-KAKU.INC".     *> オンライン資格確認結果
COPY "CPPATIENTXMLV2RES.INC" *> レスポンス編集用

患者1人を返すだけのAPIが、介護保険・マイナンバー・オンライン資格確認まで30本近い定義を取り込んでいます。「患者基本情報」の意味が制度とともに膨らみ続けてきたことの物証です。

(4) レスポンスの形: レスポンスXMLの構造は record/xml_patientinfov2res.db に宣言されています。

xml_patientinfov2res {
    patientinfores {
        Api_Result          varchar(2);
        Patient_Information {
            Patient_ID          varchar(20);
            WholeName           varchar(100);
            WholeName_inKana    varchar(100);
            BirthDate           varchar(10);
            Sex                 varchar(1);
            Home_Address_Information {
                Address_ZipCode varchar(07);
                ...

日レセAPIを使ったことがある方なら見覚えがあるはずです。APIレスポンスのXMLタグ名(Patient_ID、WholeName…)は、このrecord定義の項目名がそのまま使われています。 つまり公式のXML仕様書に書かれている項目表の「原本」がここにある、ということです。項目のサイズ(桁数)まで書かれているので、連携側のバリデーション設計の一次情報としても使えます。

この (1)→(4) が、日レセAPI 1本の解剖手順のテンプレートです。lddefでプログラムを特定し、ヘッダで機能と歴史を掴み、COPY句で触るデータを把握し、recordでメッセージ構造を確定する──COBOL本体のロジックを読み込まなくても、ここまでで実務に必要な情報の大半が揃います。

6. 全エンドポイントを数える ── grep一発の調査手順

仕組みが分かれば、全体の列挙は機械作業です。

# エンドポイント → COBOLプログラムの対応を全列挙
grep -H '^[[:space:]]*bindapi' lddef/*.ld

# モジュール別の件数
for f in lddef/*.ld; do
  n=$(grep -c '^[[:space:]]*bindapi' "$f"); [ "$n" -gt 0 ] && echo "$f: $n"
done

# 各エンドポイントの機能名をCOBOLヘッダから機械抽出
# (ソースはEUC-JPなのでiconvを挟む。プログラムの置き場所は
#  LD名と一致しない例外があるためfindで特定する)
for ld in lddef/*.ld; do
  mod=$(basename "$ld" .ld)
  grep '^[[:space:]]*bindapi' "$ld" | sed 's/"//g; s/;//' \
  | while read -r _ ep _ prog; do
      cbl=$(find cobol -name "$prog.CBL" | head -1)
      comp=$(iconv -f EUC-JP -t UTF-8 "$cbl" 2>/dev/null \
             | grep -m1 'コンポーネント名' \
             | sed 's/.*コンポーネント名[[:space:]]*[:：][[:space:]]*//')
      printf '%s\t%s\t%s\t%s\n' "$mod" "$ep" "$prog" "$comp"
    done
done

この版での集計結果は次のとおりです(全137件の個票は付録に掲載)。

読み取り系(api01rv2)に約4割が集まる一方、更新系は業務モジュール単位(患者=orca12、受付=orca11、診療行為=api21…)で分かれています。第4章の「画面業務のAPI版」という構造が、この分布にもそのまま現れています。

もうひとつ注目したいのはsessionモジュールのsession_start(ログイン認証)やorca00のprint(印刷)のような、業務APIというより基盤機能のAPIが混ざっていることです。公式仕様書の一覧をどれだけ眺めても、この層の存在には気づけません。

7. 公式一覧と突き合わせる ── 一覧にないAPIの例

次に、公式サイトの「日医標準レセプトソフトAPI仕様」一覧ページに掲載されているAPI(約50件)と、ソースから抽出した137件を突き合わせます。すると、一覧ページに載っていないエンドポイントがソース側に多数実在することがわかります。機能領域ごとに例を挙げます(機能名はいずれもCOBOLヘッダの「コンポーネント名」から確認したものです)。

つまり、受付や患者情報のような日常連携だけでなく、月次のレセプト業務(作成→点検→レセ電データ出力→請求管理)を外部から駆動できるAPI群が実装として存在するわけです。電子カルテ連携しか知らないと見えない層です。

ここで大事な注意が2つあります。

1. 「一覧にない=未文書化」と即断しない。 たとえば帳票データ取得(formdatagetv2)のようにPushAPI側のドキュメントで文書化されているAPIもあり、一覧ページは全APIの網羅を保証していません。個別のドキュメントページやサイト内検索まで確認した上で「文書が見つからない」と言うべきです(上の表はその確認をした結果ですが、それでも「公開された文書が存在しない」ことの完全な証明にはなりません)。
2. サードパーティの実装も突き合わせ材料になる。 日レセAPIをRubyから使うorca-apiライブラリのようなOSSは、実務で使われてきたエンドポイントのカタログとして参考になります。

8. 未文書化APIの仕様をソースから導出する ── findv3の実例

「一覧にないAPIが在る」ことが分かっても、リクエストの形が分からなければ調査もできません。ここで第5章のテンプレートが効きます。findv3(患者照会)でやってみます。

リクエスト構造は record/xml_findv3req.db にあります(抜粋)。

xml_findv3req {
  findv3req {
    Request_Number               varchar(2);
    Patient_Information {
      BirthDate    { First varchar(10); Last varchar(10); };
      Sex                        varchar(1);
      LastVisit_Date { First varchar(10); Last varchar(10); };
      Doctor_Code                varchar(05);
      Department_Code            varchar(2);
      Death_Class                varchar(1);
      Patient_ID   { First varchar(20); Last varchar(20); };
      TestPatient_Class          varchar(1);
      WholeName                  varchar(100)[5];
      ...

定義を読むだけで、これが生年月日範囲・性別・最終来院日範囲・担当医・診療科・死亡区分・患者番号範囲・氏名(複数指定可)などを組み合わせられる、かなり高機能な患者検索APIだと分かります。公式一覧に載っている患者検索系API(patientlst1v2〜)は患者番号範囲や氏名など単機能の検索が中心なので、画面の患者照会と同等の複合条件検索ができるこのAPIは、機能面でははっきり上位互換です。

レスポンス構造も同様に record/xml_findv3res.db にあり、対応するCOBOL(ORCGQAPI01.CBL)を読めば細かい挙動(件数上限や並び順など)も確認できます。「未文書化API」は、ソースが公開されているORCAにおいては「自分でドキュメントを起こせるAPI」なのです。

こうして導出した仕様を、本番でどこまで信頼して使うか──それが次章のテーマです。

9. 版間diffでAPIの変化を実測する ── 5.1系 vs 5.2系

未文書化APIのリスクを議論する前に、「APIはどれくらい変わるものなのか」を実測しておきます。同日公開の5.1系スナップショットとbindapi定義をdiffした結果:

追加された9件の内訳は、オンライン資格確認関連が6件(onlinequa10・onlinequa11・onlinequaapp1〜3・onlineaidlstreq1)、患者メモ登録(patientmemomodv2)、入力コード一括返却(inputcodelstv3)、入力・診療コード情報取得(medicationgetv2)の計9件です。制度対応(マイナ保険証まわり)がAPIの増設として現れていることがはっきり見えます。

この観察から言えるのは次の2点です。

• エンドポイントの「面」は安定している(この2系列間で削除ゼロ)。恐れるべきは消滅より、個々のAPIの項目追加・挙動変更(第5章で見た修正履歴のような変化)。
• ソースが毎月公開されるため、この種の変更検知は自動化できる。連携システムを保守しているなら、月次スナップショットのlddefとrecordをdiffするだけで、来月のバージョンアップで何が変わるかの早期警戒網になる。これはソース公開ならではの、他のレセコンでは得がたい保守手段です。

10. 未文書化APIとの付き合い方 ── 「文書化」は保証ではない

まず前提を正しておきます。日医オープンソース使用許諾契約は第2章第5条で、支障なく動作することや瑕疵の不存在などについて、プログラム全体を無保証としています。これは文書化されたAPIにも等しく適用されます。互換性についても、文書化APIを「変えない」と約束する明文の規定が公式文書にあるわけではなく、実際、第5章で見たとおり、文書化APIの代表であるpatientgetv2ですら制度対応のたびに項目が追加され続けてきました。

つまり「文書化/未文書化」の違いは保証の有無ではありません。実質的な差は、突き詰めると次の2点だけです。

1. 変更が公式ドキュメントの更新として現れやすいか(未文書化APIの変更は、ソースを読まない限り見えない)
2. サポート事業者との会話の土俵に乗りやすいか

そしてORCAは、ソースが毎月公開されています。1点目の差はソースのdiff監視で埋められます。ソースこそが一次仕様であり、文書はその抄訳にすぎない──オープンソースに対する正しい態度はこちらです。文書とソースが食い違ったとき、実際に動くのはソースの方です。

その上で、レセプト請求という金銭に直結するシステムを扱う以上、文書化されているかどうかに関わらず、本番フローに組み込むAPIには次の運用をセットにすべきです。

ひとつ運用上の注意があります。公開スナップショットは前月1日時点の内容なので、パッケージの更新を先に本番へ当ててしまうと、対応するソースを読めるのは適用後になります。この監視を早期警戒として機能させるには、対応するソースの公開と検証を待ってからバージョンアップする、という順序に倒す必要があります。

逆に言えば、この運用を持てない体制は、文書化APIだけを使っていても安全ではありません。無保証のオープンソースを業務の基幹に据えるというのは、そういうことです。

11. 深追いするときの実務メモ

個々のAPIをソースで深追いする段階の、細かいつまずきポイントです。

• 文字コードはEUC-JP。 COBOLソースやコメントはEUC-JPなので、iconv -f EUC-JP -t UTF-8 を通してから読む。ライセンス文書(doc/license.html)はISO-2022-JP。grepもiconvを挟まないと日本語キーワードでヒットしない。
• プログラム名の規約を覚えると速い。 API系はORAPI+業務番号+R(参照)/S(更新)+版(V2/V3)が基本形で、画面系のAPI版はORCG〜API〜。COBOLソースは原則cobol/<LD名>/配下だが例外がある(orca51のAPI実体はcobol/orca52/)ので、迷ったらプログラム名でfindする。
• 入口はGET系とPOST+XML系の2種類。 LD定義のdb "xml2"ブロックにリクエスト用レコード(〜req)が無いAPI(例: patientgetv2)はGETパラメータ型、有るものはPOST+XML型と見当がつく。最終確認はCOBOL側の入力処理で。
• データ項目の意味はrecord/+公式テーブル定義書の突き合わせで。 レスポンス項目の「原本」はrecord/*.db、DB側の意味は公式公開のテーブル定義書。両方を並べると確度が上がる。なお一部の定義にはWebORCA用の.db.weborca版が併存し、配列上限などが異なる(例: xml_acceptlstv2resは1,000件→1,500件)。WebORCA連携の設計ではそちらを確認する。
• 動作確認は検証環境で。 公式のお試しサーバーや、コミュニティのDocker環境を使えば、実機のレセコンに触れずにAPIを叩いて確認できる。本番機での「試し打ち」は禁物。

12. まとめ

• 日レセAPIの全体像はlddef/*.ldのbindapi定義に集約されており、grepだけで137エンドポイント(5.2系・2026年7月版)を列挙できる。
• 日レセAPIの正体は「画面業務のAPI版」。bind(画面)とbindapi(API)が同じLD定義に同居し、URLのモジュール名は画面の業務番号に由来する。
• 1本のAPIは lddef(ディスパッチ)→COBOLヘッダ(機能・歴史)→COPY句(触るデータ)→record/*.db(XML構造の原本)の順で解剖できる。XMLタグ名はrecord定義の項目名そのもの。
• 公式一覧(約50件)とソース(137件)の差分には、レセプト作成・レセ電データ作成・データチェックといった月次業務を駆動できるAPI群が含まれる。ただし「一覧にない=未文書化」とは即断せず、一件ずつ検証する。
• 5.1系とのdiff実測では追加9件(オン資関連が中心)・削除0件。月次スナップショットのdiffは、連携保守の早期警戒網として使える。
• 使用許諾契約は文書化APIも含めて無保証を明言しており、「文書化=安全」ではない。ソースこそが一次仕様。文書化/未文書化を問わず、本番で使うなら版固定・月次diff監視・回帰確認・自前ドキュメントの整備をセットにする。

仕様書から入るのではなくソースから入る、という今回の順番は、ORCAに限らず「ドキュメントが実装に追いついていない長寿の業務システム」全般で使える調査手法です。幸いORCAはソースが公開されているので、この手法を合法的に、しかも毎月最新の状態で実践できます。

13. 付録:全137エンドポイント対応表(5.2系・2026年7月版)

lddef/*.ldのbindapi定義から機械抽出した全エンドポイントです。機能名は各COBOLプログラムのヘッダの「コンポーネント名」欄をそのまま転記しています(表記ゆれ・全角括弧等も原文ママ)。この表は2026年7月1日時点の5.2系スナップショットの事実の記録であり、各エンドポイントの利用可否・サポート状況を示すものではありません。

14. 参考資料

• 技術情報 - 日医標準レセプトソフト - ORCA Project(ソースコード公開)
• 日医標準レセプトソフトAPI仕様 - ORCA Project
• 日医標準レセプトソフトAPI - ORCA Project
• orca-api: 日医標準レセプトソフトAPIのRubyライブラリ(GitHub)
• 日レセ本体 5.2系・5.1系ソースコード(いずれも2026年7月公開スナップショット) lddef/api01rv2.ld / lddef/orca13.ld / cobol/api01rv2/ORAPI012R1V2.CBL / record/xml_patientinfov2res.db / record/xml_findv3req.db ほか ── 本文中の実測値・引用はすべてこのスナップショットに基づく

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

日レセAPIのエンドポイントは全部でいくつありますか？

公式サイトのAPI仕様一覧ページには約50件が掲載されていますが、公開ソースコード(5.2系・2026年7月スナップショット)のLD定義ファイルを数えると、bindapiで束ねられたエンドポイントは137件あります。差分の中には帳票系のように別ページで文書化されているものも含まれるため「一覧にない=未文書化」と即断はできませんが、ソース側を数えることでAPIの全体像を一次情報として把握できます。本記事に全137件の対応表を載せています。

公式ドキュメントにないAPIを本番で使ってもいいですか？

使えます。ORCAはソースコードが公開されており、実装そのものを一次仕様として確認できるからです。そもそも使用許諾契約は文書化APIを含むプログラム全体について無保証を明言しているので、「文書化されていれば安全」という前提の方が誤りです。文書化との実質的な差は「変更が公式ドキュメントに現れやすいか」と「サポート事業者との会話の土俵に乗りやすいか」の2点で、前者は月次公開ソースのdiff監視で埋められますが、後者(未文書化APIはサポート対象になりにくいこと)は残ります。本番で使うなら、版の固定、diff監視、検証環境での回帰確認、自前ドキュメントの整備、サポート事業者への構成共有をセットにしてください。これは文書化APIを使う場合でも本来同じです。

APIのリクエストやレスポンスの形式もソースから分かりますか？

分かります。日レセのXMLリクエスト・レスポンスの構造はrecord/ディレクトリの定義ファイル(例: record/xml_patientinfov2res.db)に宣言的に書かれており、XMLのタグ名はこの定義の項目名がそのまま使われます。未文書化のAPIでも、LD定義から担当プログラムを特定し、対応するrecord定義を読めば、リクエスト・レスポンスの全項目を導出できます。

COBOLが読めなくても調査できますか？

エンドポイントの全体像を把握するだけならCOBOLの読解はほぼ不要です。LD定義ファイル(lddef/*.ld)とデータ構造定義(record/*.db)はテキストで、URLとプログラムとXML構造の対応が宣言的に書かれています。個々のAPIの内部挙動を深追いする段階で初めてCOBOLを読むことになりますが、プログラムヘッダのコメント(日本語)と修正履歴だけでも多くの情報が得られます。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。