パナソニック約8万人の生成AI定着支援に予算がついた——社内AIが3か月で止まる理由と、効果の数字の読み方

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

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

Share
目次開く
  1. 要点
  2. 「定着」に予算がついたことが、この発表のいちばんの情報
  3. 社内ルールを作っただけでは定着しない
  4. 数字は「誰の母数か」を確かめてから使う
  5. 開発会社・SIerにとって、この事例が意味すること
  6. まとめ

シンシアへのご相談

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

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

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

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

ディスカバリーズが、パナソニック グループ約8万人の生成AI活用の「定着」を、コミュニティ運営と情報発信で支援したという発表が出た。ツールの導入でも、モデルの選定でもなく、使われ続ける状態を作る仕事そのものが商材になっている事例である。この記事では公表された事実を整理したうえで、社内AI活用が止まる理由と、数字の読み方を実務目線で書く。

要点

  • 支援したのはディスカバリーズ (東京)。プロジェクトを主導したのはパナソニック オペレーショナルエクセレンス (PEX、大阪)。導入先はパナソニック グループ。
  • 対象規模は約8万人。AI活用コミュニティへの参加は延べ31,000人。
  • 支援の中身は3つ。Microsoft Teams 上のオンラインコミュニティ運営 (事例・ナレッジの共有)、動画やコラムなどのコンテンツを継続的に作りPDCAを回すこと、隔日のチェックインと週次会議による個別最適化された伴走。
  • 効果として、全利用者の合計で月あたり約29万時間の効率化、1人あたり月約7.5時間の削減が示されている。
  • PEX デジタル戦略本部 イノベーション共創部 エキスパートの小畑久輝氏は「当社や従業員の特性を理解しており、一般的な解決策を当てはめない」という趣旨のコメントを寄せている。
  • 発表は2026年8月20日。

「定着」に予算がついたことが、この発表のいちばんの情報

私がこの発表で注目したのは、削減時間の数字ではなく、定着支援そのものに外部委託の予算がついているという事実のほうだ。

受託開発の現場で見てきた社内AI活用の失敗は、ほぼ同じ形をしている。全社にツールを配り、利用率が最初の1か月だけ跳ね上がり、3か月後には一部の熱心な人しか使っていない。原因はツールの性能ではない。自分の業務にどう当てはめればいいかが分からないまま放置されることにある。

この状態を解くのに必要なのは、モデルの入れ替えでも追加機能でもなく、「自分と同じ職種の人がこう使って楽になった」という具体例が、継続的に目に入ってくる仕組みである。今回の支援内容がコミュニティ運営とコンテンツ制作に寄っているのは、そこを正面から狙っているからだと読んでいる。AI議事録のような単機能でも、定着させるには運用設計が要るという話はAI議事録の導入と運用設計に書いた。

社内ルールを作っただけでは定着しない

社内で生成AIを展開するとき、多くの企業がまず作るのは利用ルールである。入力してよい情報の範囲、禁止用途、承認フロー。これは必要だが、ルールは「使わない理由」は減らすが「使う理由」は作らない

実務で効く順序は、こうだと考えている。

  1. ルールは最小限で早く出す。 完璧なガイドラインを半年かけて作る間、現場は使えない。禁止事項を数行で決めて先に配るほうが速い。
  2. 職種別のユースケースを先に作る。 「生成AIの使い方」ではなく「営業事務の見積書作成での使い方」まで具体化する。ここが抽象的なままだと、読んだ人が自分の業務に翻訳できない。
  3. 成功事例が流通する場所を1つに決める。 今回の事例で Teams のコミュニティを軸にしているように、探しにいかなくても目に入る場所が必要になる。
  4. 効果を業務単位で測る。 全社の生産性ではなく、業務ごとの削減時間で見る。

組織側の再設計まで含めて考える論点は日経225企業の87%がAIエージェントを活用という調査を読んだ記事にも整理している。

数字は「誰の母数か」を確かめてから使う

効果の数字は、自社の投資判断に転記する前に母数を確認したほうがいい。

公表値は、全利用者合計で月約29万時間、1人あたり月約7.5時間である。この2つを素直に割ると、29万 ÷ 7.5 ≒ 約3.9万人になる。対象として示されている約8万人と一致しない。つまり「1人あたり7.5時間」は8万人全員の平均ではなく、実際に使っている人の平均を指している可能性が高い (前提は公表されていないので、断定はできない)。

これは粗探しではなく、実務上とても重要な区別だ。もし利用者が対象の半分弱なら、この事例が示しているのは「AIで全社が月7.5時間浮く」ではなく、「使う人には月7.5時間の効果が出る。残りをどう使う側に引き込むかが定着支援の仕事」という話になる。後者のほうが、支援に予算がついている理由の説明としても筋が通る。

自社で試算するときは、削減時間 × 対象人数 ではなく、削減時間 × 実利用者数 × 定着率の見込み で置く。効果を率ではなく単位あたりで見る考え方はAirbnbが予約1件あたりのサポートコストを削減した事例、評価の設計を先に作る話はLinkedInの自己進化型サポートエージェント論文に書いた。同じパナソニックでも、パナソニック コネクトのSnowflake Cortexによる業務自動化は個別業務の自動化の話で、今回の全社定着支援とは狙いが別である。

開発会社・SIerにとって、この事例が意味すること

同業として読むと、示唆は売り物の定義そのものに関わる。

  • 納品物が「動くシステム」から「使われている状態」に移っている。 今回外部に発注されているのは、開発ではなくコミュニティ運営とコンテンツ制作と伴走だ。開発会社がこの領域を「自社の仕事ではない」と切ると、顧客の予算はそちらに流れていく
  • 隔日チェックイン・週次会議という接触頻度が単価の根拠になる。 これは請負では成立しない形で、準委任の継続契約の世界である。単発の開発案件より収益が読みやすい。契約形態の違いは請負契約と準委任契約の違いに整理している。
  • 「一般的な解決策を当てはめない」が評価されている。 顧客のコメントがそこを指しているのは示唆的で、汎用のAI導入パッケージでは差別化にならないということでもある。業務と組織を理解している側が有利で、これは既存の受託で顧客の業務に入り込んできた開発会社の強みが効く領域だ。
  • 効果測定の設計を引き受けられるか。 月29万時間のような数字を出すには、業務単位で before / after を定義して継続的に集計する仕組みが要る。ここを提案に含められると、定着支援は「効果が説明できる投資」になり、予算が切られにくくなる。

まとめ

この事例から取り出せる教訓は3つある。社内AI活用が止まるのはツールの性能ではなく自分の業務への翻訳が起きないからであること。ルールは使わない理由を減らすだけで、使う理由は職種別のユースケースと事例の流通が作ること。そして効果の数字は母数を確認してから自社に当てはめること。定着に予算がつく時代になった、というのがこの発表の本当のニュースだと私は読んでいる。

出典: ディスカバリーズ、パナソニックグループ約8万人の生成AI活用定着をコミュニティ運営・情報発信で支援 (PR TIMES)

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推進についてのご相談はこちらから

    無料相談を予約する