支付宝の政務AIアシスタント「晓政」が累計1億回サービス突破——行政DXの実装モデルとして何を示すか

AI開発・生成AI活用公開日:2026年6月15日最終更新日:2026年8月2日
徐 聖博
徐 聖博

株式会社シンシア 代表取締役社長

Share
目次開く
  1. 支付宝の政務AIアシスタント「晓政」が累計1億回サービス突破——行政DXの実装モデルとして何を示すか
  2. 既存システムを作り替えずに体験だけ変える構成
  3. 日本で同じ構成を作るときの制約
  4. よくある質問

シンシアへのご相談

自社のAI活用・開発体制について相談する

AIをどこまで内製するか、どの業務から着手するか、体制をどう組むか。開発会社・SIer・事業会社の開発部門の方からのご相談を無料で承っています。同じ問題を自社でも解いている立場としてお話しします。

AI活用の進め方を相談する

まだ検討段階の方は 質問だけでもOK(電話番号は任意)

支付宝の政務AIアシスタント「晓政」が累計1億回サービス突破——行政DXの実装モデルとして何を示すか

中国のスーパーアプリ・支付宝(Alipay)が展開する政務AIアシスタント「晓政(シャオジェン)」が、サービス開始からわずか約9ヶ月で累計1億回の利用を突破した。規模感もさることながら、「人が検索する棚卸し型」から「AIが能動的に案内して対話で完結する型」への転換が、行政DXの一つの到達形として注目に値する。

出典: 支付宝政务AI助手"晓政"服务突破1亿次

要点 (事実のみ)

  • 2025年9月に支付宝が正式リリースした政務AIアシスタント「晓政」が、2026年6月12日時点で累計サービス回数1億回を突破
  • 対応行政事務は16,000件、導入先は70以上の省庁・省級政務機関
  • 対応領域は住宅積立金(公積金)・社会保険・公安・不動産など高頻度の民生分野
  • 「即問即查・一句話辞事(一言で手続き完了)」「智能浮層引导」「AI補助入力」「辺辺問(画面認識・主動回答)」などの機能を実装
  • 支付宝デジタル民生事業部責任者の李毅強氏は「1億回のサービスは1億回の『足を運ばずに済んだ』民生利便だ」とコメント

徐 聖博の見解

率直に言うと、このニュースで私が最も着目するのは「数字の大きさ」ではなく、「1億回のうち実際に手続きが完結した件数」と「どのUIパターンで完結率が変わるか」という運用粒度のデータが一切開示されていない点だ。9ヶ月で1億回という数字は、日本の行政DX関係者が聞けば驚く規模だが、支付宝のMAUが数億人規模であることを踏まえると、1人あたりの接触回数はまだ低い。「サービス回数」の定義次第で、会話セッション数なのか、個別のAPI呼び出し数なのかによっても評価がまったく変わる。

それを差し引いても、「人が検索する棚卸し型」から「対話で完結する型」への転換という設計思想は、私がXincereで受託開発や業務自動化エージェントの提案をするうえでも参照に値する。特に「AI補助入力(フォーム自動補完)」と「辺辺問(画面認識・主動回答)」の組み合わせは、長大なフォームと多段階ステップが残存する日本の行政システムにそのままニーズが存在する。

日本の行政DX文脈で言えば、マイナポータルやぴったりサービスはまだ「人が探す棚卸し型」の段階にある。この「晓政」モデルが示すのは、既存の行政システムをフルリプレイスしなくても、対話レイヤーを乗せることで体験だけを先に変えられるという実装アーキテクチャだ。受託側としては「既存バックエンドはそのままに、AIチャットボット+RPA的な操作自動化で体験刷新」という提案が最も現実的な入り口になると見ている。ただし、日本では個人情報保護・本人確認・行政手続法上の制約がより厳格なため、同じ構成をそのまま持ち込めるかは慎重に検討が必要だ。

(編集レンズ: 発注側 / 中小企業 / 開発実務への含意 + 実装・運用視点)

既存システムを作り替えずに体験だけ変える構成

この事例から日本の企業が持ち帰れる最大の示唆は、行政DXそのものではなく、バックエンドを刷新せずに対話レイヤーだけを先に乗せるという構成の取り方である。基幹システムを刷新できない事情を抱えた企業にとって、現実的な選択肢になる。

構成としては次の3層に分かれる。

  1. 対話レイヤー(新規開発)— ユーザーの質問を受け、必要な情報を集め、手続きの入口まで案内する
  2. 接続レイヤー(新規開発)— 既存システムのAPI、無ければ画面操作やDB参照で橋渡しする
  3. 既存システム(改修しない)— 業務ロジックとデータはそのまま

この構成の利点は、失敗したときに捨てられることにある。対話レイヤーが業務に合わなければ、その層だけ作り直せばよい。基幹に手を入れていないので、事業が止まらない。逆に、いきなり基幹を刷新すると、体験を変えるまでに数年かかり、その間の効果検証ができない。

接続レイヤーの作り方は案件ごとに変わる。APIが無い場合の選択肢はAIエージェントが仮想デスクトップを操作する時代で整理した。基幹刷新そのものを検討する場合はシステム刷新の進め方を参照してほしい。

日本で同じ構成を作るときの制約

そのまま持ち込めない部分は正直に押さえておきたい。

  • 本人確認と権限: 手続きを完結させるには本人確認が要る。対話レイヤーが「案内まで」なのか「実行まで」なのかで、必要な設計が大きく変わる
  • 個人情報の取り扱い: 対話ログに個人情報が含まれる前提で、保管場所・期間・アクセス権限を設計する必要がある
  • 回答の正確性の担保: 制度や料金を誤って案内した場合の責任をどう設計するか。参照した根拠(規程のどの条項か)を必ず提示する構成にしておくと、検証可能になる

3点目は、社内向けのナレッジ検索でも同じ論点になる。根拠となる文書を提示できる構成にしておくかどうかで、運用のしやすさが変わる(社内RAG構築とは?費用の内訳と失敗しない進め方)。

よくある質問

Q. 既存システムを改修せずにAIを乗せることは本当に可能か。

A. 可能だが、「どこまでを対話レイヤーでやるか」の線引き次第である。案内と情報提供までなら比較的容易で、データの更新や手続きの実行まで含めると、権限・監査・整合性の設計が必要になり難易度が跳ね上がる。まず案内までで始めて、効果を確認してから実行系に広げるのが現実的だ。

Q. 何から着手すればよいか。

A. 問い合わせの多い上位10問を数えるところから。対話レイヤーの価値は、頻度の高い問いをどれだけ吸収できるかで決まる。頻度を測らずに作ると、誰も聞かない質問に答えるシステムができる。

Share

シンシアへのご相談

自社のAI活用・開発体制について相談する

AIをどこまで内製するか、どの業務から着手するか、体制をどう組むか。開発会社・SIer・事業会社の開発部門の方からのご相談を無料で承っています。同じ問題を自社でも解いている立場としてお話しします。

AI活用の進め方を相談する

まだ検討段階の方は 質問だけでもOK(電話番号は任意)

徐 聖博のプロフィール写真

この記事の書き手に直接相談する

徐 聖博株式会社シンシア 代表取締役社長

記事の内容について、より具体的に自社のケースで聞きたいことがあれば、徐 聖博を指名してご相談いただけます。営業担当ではなく、 実際に手を動かしている本人が回答します。

シンシアの開発事例

株式会社Atsumell様|サービスを止めずにデータ基盤を刷新したBPマッチングプラットフォームの開発事例

**約11ヶ月・のべ4名のリレーで、機能開発を止めることなく基盤の刷新を完了しました。** 参画時期の重なりは最大2〜3名で、メンバーは1ヶ月の短期集中から5ヶ月の継続稼働までさまざまです。それでも積み上げが効いたのは、**先に入ったメンバーが構造を残していたから**でした。2025年7月に導入された Repository 層の上で、半年後に別のメンバーが移行作業を進めています。認可条件はコード上の仕様コメントとして、スナップショット方式はアーキテクチャドキュメントとして残り、いずれも「引き継いだ人が読んで分かる」形になっています。 この期間に手掛けた業務機能は、協力会社のラベル分類機能、パートナー企業管理画面、CSV による一括招待とデータ出力、案件辞退フロー、ステータス変更通知メールなど多岐にわたります。基盤刷新と機能開発は、どちらかを止めて行ったものではありません。 > 大規模な基盤刷新は「一度止めて作り直す」以外にも方法があります。呼び出し側を壊さない層を挟み、テーブル単位で少しずつ移し、移行と改善を混ぜない。この3つを守れば、リリースを止めずに土台は入れ替えられます。事業を止められないプロダクトほど、この進め方の価値が出ます。 ### この事例からの示唆 **稼働中のサービスでも基盤は入れ替えられる。** 前提は、呼び出し側の契約(戻り値の形)を保つ中間層を挟むこと、移行単位をテーブルや画面まで小さく割ること、そして移行と機能改善を同じコミットに混ぜないことの3点です。この3つが崩れると、不具合が出たときに原因が移行なのか改善なのか切り分けられなくなり、結果として一度止めるしかなくなります。 **メンバーが入れ替わる前提の体制では、成果物より「残る構造」が価値になる。** 短期参画のエンジニアを増やしても積み上がらないプロジェクトは、設計判断が個人の記憶に閉じていることが原因であるケースが多いです。この事例では、認可条件をコード上の仕様コメントとして、データ設計をアーキテクチャドキュメントとして残す運用を徹底しました。開発体制の失敗パターンについては[システム開発の失敗から立て直す方法](https://blog.xincere.jp/articles/system-development-failure-patterns)でも整理しています。 **要件が固まりきらない領域ほど、データ設計で制約を表現する。** 「協力会社が人材情報を編集したら応募内容が変わってしまう」といった問題は、運用ルールやUIの注意書きでは再発します。スキーマとトリガーで表現すれば、アプリ側の実装漏れがあっても壊れません。要件を仕様に落とす工程そのものについては[要件定義の進め方](https://blog.xincere.jp/articles/requirements-definition-process)を参照してください。 ### よくある質問 **Q. 稼働中のサービスを止めずに基盤刷新はできますか。** A. できます。この事例では約11ヶ月にわたり、機能リリースを継続しながらデータアクセス基盤の移行と主キー変更まで実施しました。ただし「一斉に切り替える」やり方では現実的に困難で、呼び出し側を壊さない中間層を用意して段階移行する設計が前提になります。 **Q. 途中でメンバーが入れ替わる体制でも品質は保てますか。** A. 設計判断がドキュメントとコードに残っていれば保てます。この事例では参画時期の重なりが最大2〜3名、1ヶ月だけの参画者もいる体制で、前任の導入した層の上に後任が半年後の移行作業を積み上げています。 **Q. どのくらいの規模・期間の支援ですか。** A. 約11ヶ月、のべ4名(同時稼働は最大2〜3名)です。プロジェクトの規模や費用感の考え方は[システム開発とは](https://blog.xincere.jp/articles/what-is-system-development)で解説しています。 ### 関連する支援領域 - [システム刷新の進め方|検討・計画から移行までの方法](https://blog.xincere.jp/articles/core-system-renewal-guide) — 稼働中システムを止めずに刷新する判断基準 - [業務システム開発の要件定義とは?進め方・手順を7ステップで解説](https://blog.xincere.jp/articles/business-system-development-requirements-definition-steps) — 要件を仕様に落とす工程 - [システム開発の失敗から立て直す方法](https://blog.xincere.jp/articles/system-development-failure-patterns) — 体制・引き継ぎで詰まったときの選択肢 同じように「稼働を止められないプロダクトの基盤を作り替えたい」という課題をお持ちでしたら、[開発のご相談](https://blog.xincere.jp/contacts)からお問い合わせください。現状のコードとデータ構造を確認したうえで、段階移行の設計からご一緒します。

株式会社Atsumellの事例を読む →

この記事が役に立ったら、Google で優先表示を

Google 検索の「優先するソース」に blog.xincere.jp を追加すると、シンシアの新着記事がトップニュースなどで見つけやすくなります。

Google で優先ソースに追加

著者について

徐 聖博のプロフィール写真
徐 聖博
株式会社シンシア 代表取締役社長

株式会社シンシア(Xincere, Inc.)代表取締役。中国生まれ・3歳から日本で育ち、日本語・中国語・英語を操るトリリンガル。大学院でコンピュータサイエンス(進化型ニューラルネットワーク)を研究し、GREE・メドレー・カウンティア・Indeed Japan などで検索エンジン開発やスタートアップの立ち上げ・グロースを経験。2020年に「人の価値をテクノロジーで最大化する」という想いでシンシアを創業した。エンジニア歴15年以上、代表でありながらほぼ毎日コードを書く現役エンジニアとして、基幹システム開発からAIエージェント活用まで顧客の事業成長に並走している。創業に込めた思いはnoteの創業ストーリーに綴っている。

人気記事

    お問い合わせ

    システム開発やAI推進についてのご相談はこちらから

    無料相談を予約する