経理のAI活用は「初審の置き換え」から——製薬大手・正大天晴の「AIは組織の再設計」を作る側から読む

AI開発・生成AI活用公開日:2026年9月13日
徐 聖博
徐 聖博

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

Share
目次開く
  1. 元記事の要点 (事実のみ)
  2. AIは「判断の代行」ではなく「人が見る範囲を絞る」装置として入っている
  3. AIで経理の仕事はなくなるのか
  4. 開発会社にとって重いのは「2人で1案件」のほうだ
  5. 日本企業がそのまま真似しにくい点
  6. 徐 聖博の見解
  7. 関連記事

シンシアへのご相談

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

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

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

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

経理のAI活用は、どこから始めて、組織をどう変えるのか。本稿は、中国の製薬大手・正大天晴 (Chia Tai Tianqing) で生産供給領域のスマート化を率いる陳爾冬氏のインタビュー (電子工程専輯掲載) を題材に、受託開発とAIエージェント事業をやっている立場から、作る側としてどう読むか開発会社の経営に何が効くかを整理する。

元記事の要点 (事実のみ)

  • 陳氏は、医薬業界のスマート製造は世界トップのライトハウス工場と比べて「2世代ほど遅れている」と述べ、理由としてGMPによる制約と、業務形態上デジタル化への要求が強くなかったことを挙げた。
  • 財務審査では、経費精算や購買の支払いの初審をAIで完全に置き換えた。複審は人が担当している。以前は精算に何日もかかり、取引先への支払いは30日〜60日待ちだったが、結果がすぐ出るようになったという。
  • 「供給チェーン大脳」により、200品目以上の今後3か月の工場需要を毎月手計算していた作業が不要になり、人が確認するのはシステムが自動で重点指定した約10品目だけになった。残りはAIが監視し、リスクを検知すると理由と対策案を添えて通知する。
  • 数字化チーム自体も、PM・UI・フロントエンド/バックエンド・テスト・データ・運用という長い分業から、「プロダクト寄りと技術寄りの2人で1案件」のエンドツーエンド体制に変わった。チーム人員は30〜40%程度減ったが、業務側はむしろ納品が速くなったと感じているという。
  • 同社はGMP領域はオンプレミスで最も厳格に、それ以外はクラウドに置くハイブリッドクラウドを採り、社内にモデルゲートウェイを構築して部署・業務ごとのモデル呼び出しのコストと安定性、セキュリティポリシーを管理している。

AIは「判断の代行」ではなく「人が見る範囲を絞る」装置として入っている

私がこの記事で一番面白いと思ったのは、財務と供給チェーンという性格の違う2つの事例が、設計としては同じ形をしていることだ。

財務は「1円もずれてはいけない」領域だ。そこでAIが担っているのは初審で、最終判断は人の複審に残っている。供給チェーンでも、AIは200品目の需要を「決めて」いるわけではない。人が確認すべき10品目を選び出し、残りを監視して、異常があれば理由つきで知らせている。どちらも、AIの役割は人が見るべき対象を絞り込むことであって、判断そのものを渡してはいない。

作る側から見ると、この形は要件定義の重心を変える。モデルの精度をどこまで上げるかより、「どの条件なら人に回すか」「人に回さなかったものの誤りに、いつ・誰が気づけるか」を先に決めないと、本番に載せられない。受託でAI案件の要件を詰めていくと、最後まで揉めるのはたいていモデルではなくこの線引きだ。正大天晴の事例は、その線引きを先に決めた会社がどう動いているかを具体的に見せている。

AIで経理の仕事はなくなるのか

元記事の範囲で言えるのは、「なくなった」のは初審の作業であって、経理という機能ではない、ということだ。陳氏は、財務チームは人員の範囲を縮めた一方で、業務部門と組んで資金の使い方やコスト管理を支援する側に資源を回したと述べている。

ただし、私はこれを「だから安心だ」とは読まない。陳氏自身が、特定の部署を3〜6か月の短期で見れば「かなり乱暴な」コスト削減に見えるし、個々の社員がそれを避けるのは難しいと認めている。作業は確実に減り、残る仕事は性質が変わる。経理でAIを入れる側は、削る作業と、空いた人に何をしてもらうかを同時に設計しないと、「人を減らしただけ」になる。

開発会社にとって重いのは「2人で1案件」のほうだ

SIerや開発会社の経営者として読むなら、財務や供給チェーンより、数字化チームの再編の話のほうが重い。

PM・UI・フロントエンド/バックエンド・テスト・データ・運用という長い分業は、受託開発が工程ごとに人月で見積もってきた構造そのものだ。発注側の内製チームが「2人で1案件を端から端まで」に移り、人員を減らしても納品が速くなったと感じているなら、同じ分業を外から人月で売る提案は通りにくくなる。これは発注者の予算が減るという話ではなく、発注者が買いたい単位が変わるという話だ。

私の見立てでは、ここで開発会社が取れる道は2つある。1つは、発注側の少人数チームに入り込み、業務定義から実装までを一緒に持つ、いわゆるFDE (Forward Deployed Engineer) 型の関わり方。もう1つは、正大天晴でいう「中後台」、つまりデータ基盤・AI基盤・エージェントのオーケストレーションのような共通基盤を請け負うことだ。工程の一部だけを人数で埋めるやり方は、どちらにも入らない。

なお、人員30〜40%減という数字はインタビューでの本人の説明で、第三者が検証したものではない。何を分母に数えたのか (外注要員を含むのか、配置転換を含むのか) も記事からは分からない。規模感の参考にとどめ、自社の計画値にそのまま使わないほうがいい。

日本企業がそのまま真似しにくい点

2つある。1つは、陳氏自身が「数字化は智能化に先行しなければならない」と言っていることだ。供給チェーン大脳が作れたのは、先に供給チェーンのデジタル化が進んでいてデータがあったからで、紙とExcelで回っている業務にいきなりAIを載せても同じ結果にはならない。もう1つは、トップが戦略としてAIを掲げ、社内で繰り返し発信している前提があることだ。陳氏はAI導入の本当の難しさは技術ではなく組織にあると述べており、この前提が無い会社で「2人1案件」だけを真似すると、単なる人員削減として受け止められるリスクが高い。

徐 聖博の見解

私は、この記事を「AIで人が減った話」ではなく、AIを入れる前に「人が何を見るか」を決め直した話として読んだ。財務の初審、供給チェーンの重点品目の抽出、モデルゲートウェイによる利用管理のどれも、AIの能力より、人と仕組みの境界線の引き方が成果を決めている。研究をやっていた頃から、精度の数字だけで手法の良し悪しを語るのは危ういと思ってきたが、業務でも同じで、効いているのはモデルの外側の設計だ。

開発会社としての学びは、発注側の組織が変わるスピードに、自社の売り方が追いつけるかどうかだと考えている。工程分業の人月モデルを守るより、少人数で業務定義から持つ体制か、共通基盤を持つ体制のどちらに寄せるかを先に決めるべき時期に来ている。

関連記事


出典: 对话正大天晴陈尔冬:医药数字化深水区,AI不是降本增效,而是"组织重塑" (電子工程専輯)

Share

シンシアへのご相談

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

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

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

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

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

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

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

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

シンシアの開発事例

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

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

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

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

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

Google で優先ソースに追加

著者について

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

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

人気記事

    お問い合わせ

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

    無料相談を予約する