PalantirとFujitsuのソブリンAI提携、モデルではなく導入を中心に据える
PalantirとFujitsuは6年にわたる提携を拡大し、ソブリンAIの約束を実際に稼働するエンタープライズシステムへとつなぐ重要な存在として、導入現場のエンジニアを位置付けた。PalantirとFujitsuのソブリンAI提携は、Palantir AIP、Foundry、FujitsuのTakaneモデル、そして顧客が管理する運用環境を対象とする。また、この提携によりFujitsuはGlobal Forward Deployed Engineeringパートナーとなる。
この位置付けは、単なる製品統合以上の意味を持つ。Forward Deployed Engineers、すなわちFDEは、ソフトウェア、データ、運用上の意思決定を結び付けるため、顧客と直接協働する。したがってこの提携は、モデル、コンピューティングシステム、ガバナンス制御と並び、人による実装能力を不可欠なインフラとして扱っている。
Palantirは、モデルを統制されたエンタープライズデータおよびワークフローと接続するソフトウェアレイヤーを提供する。Fujitsuは、日本市場へのアクセス、業界知識、地域のエンジニアリング能力、そしてUvanceサービスのポートフォリオを提供する。中心的な課題は、この労働集約的な組み合わせが、ソブリンAIの魅力を支える制御を損なうことなく拡張できるかどうかである。
PalantirとFujitsuのソブリンAI提携が変えること
更新された合意により、Fujitsuはソフトウェアの顧客および再販事業者から、運用AIシステムの構築を担うデリバリーパートナーへと移行する。
両社は2026年9月10日、関係拡大を発表した。FujitsuはPalantir Technologies Japanと、Palantir AIPおよびPalantir Foundryを対象とする新たな契約を締結した。提携発表では、FujitsuがGlobal FDE Partnerであることも示されている。
Palantir AIPは、大規模言語モデルをエンタープライズデータ、ビジネスロジック、ソフトウェアツールと接続する。Foundryは、データと業務プロセスを共有環境へと整理する。両プラットフォームは、AIを孤立した実証実験から、統制された本番ワークフローへ移行させることを意図している。
Fujitsuはこれらのプラットフォームを、自社のエンタープライズ向け大規模言語モデルであるTakane、およびより広範なUvanceの提供内容と組み合わせる計画だ。Uvanceは、コンサルティング、クラウド、データ、セキュリティ、事業変革サービスから成るFujitsuのポートフォリオである。FujitsuはPalantir導入の経験を持つエンジニアも投入する。
両社は白紙の統合計画から始めるわけではない。Fujitsuが社内変革と日本の顧客プロジェクトでPalantirの技術を使い始めた2020年以降、両社は協働してきた。Fujitsuによるこの2020年の協業の説明では、Palantirは分離されたシステムからの情報を統合する基盤として位置付けられている。
新たな合意は、この関係を二方向に拡張する。第一に、顧客データと業務プロセスを中心に構築されるAIアプリケーションへの重点を強める。第二に、こうしたアプリケーションを日本国外で提供するうえでFujitsuの役割を拡大する。
両社は、契約の財務条件、人員目標、想定顧客数を明らかにしていない。また、Global FDE Partnerという位置付けに、デリバリー認定、地域での責務、または成果要件が伴うかどうかについても詳述していない。
こうした情報の欠如により、パートナーの肩書きだけから導き出せる結論には限界がある。しかし、運用面での方向性は明確だ。Fujitsuは、Palantirのプラットフォームを個別のエンタープライズ環境に適応させられる人材と手法へ投資している。
これは競争単位を変える。提供されるのは、単にFujitsuのモデルを束ねたPalantirソフトウェアではない。モデル、権限、データ、現場の意思決定を、顧客が定義した制御の下で接続することを目的とした統合導入システムである。
このシステムは、エンタープライズAI購買におけるより広範な変化を反映している。大規模組織は、AIが既存のセキュリティ、監査、運用の構造の内側で機能できることを示す証拠をますます必要としている。能力の高いモデルへのアクセスだけでは、こうした実装上の問いには答えられない。
PalantirとFujitsuのソブリンAI提携は、再現可能なエンジニアリング実践を通じてこれらの問いに答えることを目指す。その成否は、Fujitsuがその実践を顧客、業界、法域をまたいで再現できるかにかかっている。
ソブリンAIが運用上の課題になりつつある理由
現在のソブリンAIは、データやコンピューティングインフラの物理的な所在地だけでなく、意思決定とワークフローに対する制御を意味する。
ソブリンAIという用語は、機密情報、モデル、インフラ、運用権限を、定義された組織または国家の管理下に置くシステムを指すことが多い。この定義は、主に情報が保存または処理される場所を扱うデータレジデンシーよりも広い。
企業はデータを一国の内部に保持していても、モデルへのアクセス、ソフトウェア更新、ID制御、ワークフロー実行を外部プロバイダーに依存することがある。こうした依存は、保存が地域の要件を満たしていたとしても、実務上の制御を弱める可能性がある。
PalantirとFujitsuは、主権性を運用環境を軸に位置付けている。両社が提案するアーキテクチャは、モデルを統制されたデータ、アクセス制御、監査記録、業務ワークフローに接続する。顧客は、自社のセキュリティおよび運用要件に合う導入環境を選択できる。
このタイミングは、テクノロジーの購入者にかかる規制面・地政学面の圧力を反映している。政府や重要産業は、モデルの来歴、ソフトウェアのサプライチェーン、国境を越えたアクセス、運用継続性について、より明確な回答を求めている。こうした懸念は、抽象的な政策論争ではなく、調達基準になりつつある。
欧州委員会が提案する主権性フレームワークは、この変化を示している。その保証水準では、インフラの所在地、外国への依存、プロバイダーによる制御、人員要件、ソフトウェアサプライチェーンの透明性が考慮される。
日本にも、運用上の自律性を重視する独自の理由がある。製造業、金融機関、公共部門、インフラ関連組織は、長い運用寿命を持つ機密システムを管理している。その多くは、生成AIを導入するためだけに、確立済みのデータベース、生産ソフトウェア、コンプライアンス手続きを置き換えることはできない。
これにより、PalantirのソブリンAI導入に機会が生まれる。Foundryは既存システムを横断して情報を接続でき、AIPはモデルとのやり取りを権限とレビューのプロセスの背後に置くことができる。Palantirによれば、顧客は商用モデル、オープンモデル、セルフホスト型モデルなどを使い分けることもできる。
Fujitsuは、このソフトウェアを複雑な日本企業に適合させるために必要な地域の関係性と技術知識をもたらす。また、日本企業向けにCohereと共同開発されたTakaneを、選択肢となるモデルレイヤーの一つとして提供する。
ただし、日本のサービス企業と米国のソフトウェアプラットフォームを組み合わせただけで、主権性が自動的に実現するわけではない。購入者は依然として、ライセンス、ソフトウェア依存関係、サポートアクセス、暗号化制御、モデルホスティング、インシデント対応の権限を検討する必要がある。
また、導入後に誰がAIワークフローを変更できるかも定義しなければならない。外部ベンダーだけが障害を調査し、更新を承認し、不可欠な機能を復旧できるシステムは、運用上の主権を持つとは言えない。
このため、FujitsuのエンタープライズAIサービスは今回の合意にとって重要である。地域のエンジニアは、データの流れ、モデルの実行場所、承認を要するアクション、ソフトウェア変更が本番環境に入る方法を、顧客が文書化するのを支援できる。
このアプローチは、ハイパースケールクラウドプロバイダーと従来のシステムインテグレーターに、それぞれ異なる形で圧力をかける。クラウドベンダーは、地域インフラ、マネージドモデル、ガバナンスサービスのポートフォリオを拡大している。インテグレーターはすでに大規模な実装チームと地域の顧客アクセスを有している。
PalantirとFujitsuは、その中間のレイヤーを占めようとしている。両社が販売するのは、工場、サプライチェーン、その他の規制環境における意思決定と、インフラおよびモデルを接続できる運用フレームワークである。
両社の主張は、統制された実行が、モデルへのアクセスだけよりも大きな価値を生むというものだ。より難しい問いは、このフレームワークが顧客に永続的な制御をもたらすのか、それとも新たなプラットフォーム依存を生むのかである。
サプライチェーンの事例が意図された仕組みを示す
この提携を裏付ける最も強い証拠は製造業での導入事例だが、現時点でのすべての実績数値はそれを推進する両社から示されたものである。
Fujitsuによれば、同社はPalantirのプラットフォームを用いて、日本を代表する製造企業向けのサプライチェーン・レジリエンスシステムを実装したという。発表では顧客名が明かされておらず、基準値、契約範囲、算定方法を独立して検証することはできない。
このシステムは、3,000社を超えるサプライヤーと18の工場からのデータを接続したとされる。また、従来は組織上の別々のサイロで運用されていたエンタープライズシステムの情報も統合した。
両社によれば、顧客は1年以内に1,000万ドル超のコスト削減を記録した。また、業務生産性は2倍となり、混乱への対応も迅速化したとしている。
これらの結果は、広範なAIの表現よりも、この提携の背後にある仕組みをよく説明している。サプライチェーンチームは、調達システム、生産記録、サプライヤー報告、在庫ツール、物流データ、スプレッドシートをまたいで業務を行うことが多い。これらのソースを接続する遅れは、運用対応の遅れにつながり得る。
Foundryは、こうした記録を工場、部品、注文、サプライヤー、出荷といった共有ビジネスオブジェクトへマッピングするよう設計されている。Palantirはこの運用上の表現をOntologyと呼ぶ。これはデータを、ユーザーが利用できるアクションおよび意思決定と接続する。
その後、モデルはこの統制された文脈内で情報を分析できる。たとえば、サプライヤーへのエクスポージャーを要約し、影響を受ける生産注文を特定し、対応策を提案できる。周囲のワークフローは、モデルが参照できるデータと、提案されたアクションのうち人間の承認を要するものを決定する。
この構造は、データウェアハウスの隣に配置された汎用チャットボットとは異なる。モデルは、権限が設定されたプロセス内の一つの構成要素となる。システムはデータの来歴、ユーザーアクセス規則、監査履歴、運用記録間の関係を維持しなければならない。
Fujitsuの導入現場エンジニアには、顧客とともにこうした関係を構築することが期待される。正式なプロセス図では見落とされがちな例外も含め、組織が実際に混乱へどう対応するかを理解しなければならない。
ここに、この提携のエンジニアリングモデルの価値と難しさが共存する。エンタープライズ情報には、一貫した定義が付されていることはほとんどない。同じ部品であっても、二つの工場が異なる識別子、計画上の前提、ステータスラベルを使用している可能性がある。
AIシステムが信頼できる運用ガイダンスを生成する前に、エンジニアはこうした違いを解消しなければならない。また、システムがアクションを推奨すべき場面、阻止すべき場面、あるいは判断を人へエスカレーションすべき場面を定める必要がある。
この作業は、ソフトウェアデリバリー、データモデリング、組織分析、チェンジマネジメントを同時に行うことに似ている。この組み合わせは、Palantirが長年にわたり顧客とともに技術チームを組み込んできた理由を説明する。
Palantirの年次報告書では、パートナーシップを、同社のプラットフォームを顧客の業務へ拡張する手段として位置付けている。また、組み込み型の取り組みは、製品開発と顧客理解の重要な源泉でもあると説明している。
Fujitsuは、確立されたサービス人材を通じてこのモデルを拡大できる。同社のエンジニアはすでに日本の企業インフラと業界要件を理解している。Takaneやその他のモデルをPalantirのデータ層およびワークフロー層に接続したい顧客も支援できる。
匿名の製造業事例については、依然として慎重な見方が必要だ。コスト削減は、回避された障害、在庫削減、スタッフの作業時間、調達変更、あるいはその他の前提条件に左右されうる。この発表では、報告された成果を生んだカテゴリーがどれかは明らかにされていない。
「業務生産性を倍増」という表現も定義されていない。この指標は、特定のチーム、タスク、対応サイクル、あるいはより広範な運用単位を指す可能性がある。分母と測定方法がなければ、読者は他の導入事例と比較できない。
したがって、この事例が示すのは普遍的な成果ではなく、実現可能性だ。統合データが複雑なサプライチェーンをどのように支援できるかを示している。しかし、すべてのFujitsu企業AI顧客が同様のコスト削減や生産性向上を実現することを裏付けるものではない。
主な競争は個別最適化された統制と反復可能な規模の間にある
この提携は、主権性を重視する導入をすべて別の標準化クラウドパッケージへと還元することなく、高度にカスタマイズされたエンジニアリングを反復可能なサービスへ転換しなければならない。
PalantirのForward Deployed Engineeringモデルが機能するのは、エンジニアが顧客の業務上の課題に密接に関わり続けるためだ。組織の実際の運営方法に合わせて、データ構造、権限、インターフェース、アプリケーションを調整できる。
しかし、この近接性はスケーリング上の制約にもなる。経験豊富なエンジニアの育成は容易ではなく、顧客環境ごとに異なるレガシーシステムが存在する。規制の厳しい組織では、管轄区域固有の統制、文書化、承認手続きも追加される。
FujitsuのGlobal FDE職は、この制約に直接対応するものだ。Palantirがすべての導入チームを提供する代わりに、Fujitsuは同じ提供アプローチを習得した、より大規模な専門人材プールを構築できる。
このパートナーシップはPalantirの到達範囲を広げる一方、Fujitsuには企業需要が高まるソフトウェアプラットフォームへのアクセスをもたらす。Palantirは、契約活動とAI主権への顧客関心の高まりとともに、第2四半期決算で力強い商業成長を報告した。
それでも、パートナー企業のエンジニアを増やすだけで一貫した実行が保証されるわけではない。現場に展開する業務は、判断力、組織へのアクセス、技術的な深さに依存する。認定プログラムはプラットフォームの概念を教えられるが、何年にもわたる顧客固有の経験を直ちに再現することはできない。
Fujitsuは、どの要素を標準化するかを決める必要がある。再利用可能なコンポーネントには、業界データモデル、アクセス制御テンプレート、モデル評価手順、コネクター、インシデント対応ワークフローなどが含まれうる。
標準化は導入時間を短縮し、エラーを減らす。また、チームや地域をまたぐサポートも容易になる。一方で、標準化を進めすぎれば、顧客が主権性を重視するアーキテクチャを選ぶ理由そのものを損なう可能性がある。
製造業者は、工場固有の運用統制を必要とするかもしれない。銀行では、顧客データ、リスク計算、自動化された顧客対応に対して、それぞれ別個の承認が求められる可能性がある。政府機関では、より強い監査可能性や、モデルまたはインフラ提供者に対する制限が必要になる場合がある。
したがって、この提携はスピードとローカルな統制の間のトレードオフに直面する。各導入が顧客の正確な環境を反映するほど、より多くのエンジニアリング能力を消費する。コンポーネントが均一化されるほど、結果の差別化は薄れる。
従来のシステムインテグレーターも同じ課題に直面しているが、多くは幅広いコンサルティングおよびマネージドサービス組織を出発点とする。Fujitsuの優位性は、こうした能力をPalantir固有の経験や日本の顧客との関係と組み合わせている点にある。
ハイパースケールクラウド企業は別の方向から市場にアプローチする。地域インフラ、IDシステム、マネージドデータベース、モデルカタログ、AI開発サービスを提供する。その規模は、標準化された導入と広範なパートナーネットワークを支えている。
Palantirは、すべてのインフラ層を置き換えようとしているわけではない。同社のプラットフォームは、クラウド環境と顧客管理環境の双方で稼働できる。同社が目指すのは、データ、モデル、意思決定を結ぶ運用ソフトウェア層を担うことだ。
この位置づけにより、PalantirとFujitsuの主権AIパートナーシップは、複数のインフラ選択肢にまたがって意味を持ちうる。同時に、顧客は自社業務の表現、アプリケーションロジック、ガバナンスの仕組みにおいてPalantirへ依存することになる。
AIPが複数のモデル提供者をサポートするなら、モデルの切り替えは比較的容易にとどまる可能性がある。しかし、ワークフローやビジネスオブジェクトをエンコードするプラットフォームの置き換えは、はるかに難しい場合がある。
したがって、買い手はモデル選択とアーキテクチャの可搬性を区別すべきだ。プラットフォームは複数のモデルを提供できる一方、独自のデータ構造、ワークフローロジック、管理ツールを通じて依存関係を生み出す可能性がある。
Fujitsuの存在は、この懸念を解消するものではない。Palantir自身のサービスチームへの運用上の依存を減らす可能性はあるが、基盤プラットフォームは依然として中核にある。
この提携の最も強力な形は、統制を測定可能にすることだ。顧客は、導入場所、管理アクセス、ソフトウェア更新の権限、モデル選択、エクスポートの選択肢、監査範囲、継続計画を文書化できるべきである。
こうした詳細が、Palantirの主権AIが持続可能な企業アーキテクチャとなるのか、それとも従来型の統合作業に付けられた柔軟なラベルにとどまるのかを左右する。
主権性の主張には、より厳格な監査が必要だ
未解決の問いは、プラットフォームにガバナンス機能が含まれているかどうかではなく、実際の障害時に顧客が独立して検証し、統制を維持できるかどうかだ。
この発表は、データ、モデル、インフラ、運用に対する顧客の統制を強調している。また、アクセス制御、監査、管理されたワークフロー、顧客管理の導入環境にも言及している。
これらは関連性のある機能だが、依然として企業側の説明にとどまる。パートナーシップの発表では、独立したセキュリティ評価、アーキテクチャ図、可搬性標準、顧客監査は提示されていない。
主権性は文脈にも依存する。民間の製造業者は、防衛機関なら拒否するような依存関係を受け入れる可能性がある。日本の銀行は定められた統制の下で遠隔のベンダーサポートを許可するかもしれないが、別の機関では地域で認可された人員を求める場合がある。
各顧客は、この広範な主張を検証可能な要件に翻訳しなければならない。これらの要件は、データがどこを移動するのか、誰が復号できるのか、どの管理者がメタデータへアクセスできるのか、ログの可用性をどう維持するのかを対象とすべきだ。
モデルガバナンスはさらに別の層を加える。Takaneは、外部の商用モデルとは異なる統制の下で動作する可能性がある。オープンモデルは導入の柔軟性を高められるが、顧客には依然として安全な推論インフラと更新手順が必要だ。
AIエージェントは接続されたツールを通じて行動を起こせるため、さらなるリスクを生む。権限は、エージェントがアクセスできるレコード、アプリケーション、取引を制限しなければならない。重要な意思決定については、人間によるレビューが実質的なものとして維持される必要がある。
モデルが予測不能な振る舞いをした場合に備え、システムには対応計画も必要だ。チームは、操作を無効化する方法、ワークフローを戻す方法、監査証跡を保全する方法、AIコンポーネントなしで重要な業務を継続する方法を把握しておくべきである。
Palantirの企業提出資料によれば、同社のソフトウェアは詳細な統制と監査記録をサポートしている。しかしPalantirは、不適切な導入がプライバシー、法的、規制上、評判上のリスクを生む可能性があるとも警告している。
この警告が重要なのは、まさにFujitsuのFDE組織が提供するのが導入であるためだ。チームが権限を誤って設定したり、運用上の依存関係を誤解したりすれば、ガバナンス機能はほとんど保護にならない。
したがって、トレーニングと品質管理はFujitsuの投資の中心に位置づけられるべきだ。同社は地域ごとに共通のレビュープラクティスを必要とする一方、地域固有の要件に対応する能力も維持しなければならない。
この提携は、導入の透明性によっても評価されるべきだ。実名の顧客、文書化されたアーキテクチャ、外部評価、正確に定義された成果指標は、パートナー職種の名称より強い証拠を提供する。
匿名のサプライチェーン事例は、有用な規模の指標を示している。しかし、どのモデルが使われたのか、どこで動作したのか、ユーザーがどのように行動を承認したのか、顧客が運用ロジックを移行できたのかは明らかにしていない。
買い手は、Fujitsuの企業AIサービスを当然に主権的なものとみなす前に、直接的な質問をすべきだ。
ID、暗号鍵、管理権限を統制する組織はどこか？
プロンプト、モデル出力、テレメトリー、監査記録はどこを移動するのか？
顧客はモデルを選択、置換、またはセルフホストできるか？
ソフトウェア更新と緊急アクセスを誰が承認するのか？
提供者の障害時にも動作し続けるコンポーネントはどれか？
データモデルとワークフローロジックは利用可能な形式でエクスポートできるか？
パートナー企業のエンジニアはどのように訓練、監督され、案件から外されるのか？
どのパフォーマンスおよびガバナンス上の主張に独立した証拠があるか？
これらの質問は、そのアーキテクチャが主権性のテストに失敗していることを意味するものではない。マーケティング上の概念を調達基準へと変換するものだ。
同様のシステムを評価する組織には、社内のナレッジガバナンスも必要となる。検索可能なAIナレッジベースは、長期にわたる導入の中で、意思決定、ポリシー解釈、導入の証拠をチームが保持する助けになる。
その文書は、ベンダーの保証とは切り離して維持すべきだ。顧客には、アーキテクチャ上の意思決定、受容したリスク、モデル評価、インシデント、運用変更に関する自らの記録が必要である。
少数の導入エンジニアが持つ非公式な知識に頼らず、顧客がシステムを運用・監査できるようになれば、この提携の信頼性は高まる。それが支援付き導入と、持続可能な組織的統制の違いだ。
モデルが拡大するかは三つのシグナルで決まる
次の試金石は、測定可能な顧客導入であり、その後に続くのがエンジニアリング品質と独立して文書化された統制である。
最初のシグナルは、現在の匿名製造業者以外に存在する、実名の本番運用顧客群だ。その導入では、業界、業務ワークフロー、データ規模、モデル構成、測定可能な成果を特定すべきである。
実名の事例は、PalantirとFujitsuの主権AIパートナーシップが一つのサプライチェーンプロジェクトを超えて拡張できるかを示すだろう。金融、政府、医療、インフラにおける導入は、ガバナンス要件に対するより厳しい試験となる。
実名の顧客が不足すれば、この提携のグローバルな主張は弱まる。それは、発表が検証済みの導入より速く組織上のコミットメントを拡大したことを示唆するだろう。
二つ目のシグナルは、FujitsuがForward Deployed Engineeringの実務をスケールできるという証拠だ。有用な指標には、訓練を受けた人員、地域の提供チーム、反復可能な導入期間、再利用可能なコンポーネント、顧客維持率が含まれる。
人員数だけでは答えは出ない。Fujitsuは、追加されたチームが一貫したアーキテクチャとガバナンスを提供できることを示さなければならない。品質上の失敗は、急速な採用拡大より重大となる。
PalantirとFujitsuは、両社のエンジニアがどのように責任を分担するのかも説明すべきだ。顧客は、誰がワークフローを設計し、セキュリティアーキテクチャを承認し、インシデントに対応し、各コンポーネントを支援するのかを知る必要がある。
責任分担が明確であれば、個別最適化された統制モデルは強化される。ソフトウェア提供者、インテグレーター、モデル開発者、インフラ運用者の間で混乱が生じれば、それは弱まる。
3つ目のシグナルは、独立して検証可能なソブリン性の証拠です。顧客のアーキテクチャ開示、認証、第三者評価、ポータビリティに関する文書、運用レジリエンス試験などが含まれます。
この証拠は、データ所在だけにとどまるべきではありません。管理権限、更新権限、ソフトウェア依存関係、監査アクセス、モデルの代替可能性、障害発生時の復旧を検証する必要があります。
詳細な検証フレームワークがあれば、ソブリン性が最前線の業務にまで及ぶという両社の主張はより強固になるでしょう。広範で抽象的な声明に繰り返し依存すれば、この言葉は一般的なプライベートクラウドのマーケティングと区別しにくくなります。
市場全体も反応するでしょう。クラウドプロバイダーは、ソブリン向けの制御機能や地域別サービスを引き続き追加していくはずです。ほかのインテグレーターも、自社の導入能力をモデルプロバイダーやデータプラットフォームと組み合わせていくでしょう。
PalantirとFujitsuは、すべてのレイヤーで勝つ必要はありません。顧客の権限を損なうことなく、より迅速な意思決定を実現できることを、自社の運用モデルで示す必要があります。
エンタープライズの買い手にとって、当面の対応は実務的です。ソブリンAIを製品カテゴリーではなく、アーキテクチャと説明責任の問題として扱ってください。そこに付随するブランドを評価する前に、あらゆる依存関係を可視化しましょう。
データ、モデル、ソフトウェアの変更、ビジネスロジック、復旧プロセスを誰が管理しているのかを問いましょう。そして、実際に稼働している導入環境からの証拠を求めてください。
PalantirとFujitsuによるソブリンAIパートナーシップは、AIと統制された業務を結び付けるための信頼できる仕組みを提示しています。サプライチェーンの事例は、その仕組みが注目を集める理由を示しています。今後の導入では、このアプローチがグローバル規模で提供された場合にも、同様に管理可能であり続けるかを示す必要があります。
