日本のAI利用率51%超え——「どう使うか」を競う時代に現場PM目線で考えること

AI開発・生成AI活用公開日:2026年6月27日
高畑 拓海
高畑 拓海

株式会社シンシア 開発支援事業部 部長

Share

シンシアへのご相談

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

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

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

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

日本のAI利用率51%超え——「どう使うか」を競う時代に現場PM目線で考えること

日本の生成AI利用率がついに51%を超えた。この数字が示すのは単なるトレンドの加速ではなく、「AIを導入したかどうか」ではなく「どう組織に根付かせたか」が問われる段階への移行だと私は受け止めている。

出典: 日本のAI利用率がついに51%突破:「使わないリスク」が現実になった2026年の企業戦略

要点 (事実のみ)

  • 2026年6月時点で日本の生成AI利用率が51%を突破。一部調査では54.7%という数値も報告されており、2025年初頭の約27%から1年余りで倍増した
  • 50代以上の利用率が前年比+28ポイントと最大の伸びを記録。Windows 11のCopilot+機能やmacOS SequoiaのApple Intelligenceの日本語対応が利用障壁を下げた主因として挙げられている
  • NTTのtsuzumi 2(2025年秋リリース)はビジネス文書処理精度が初代比約40%向上。NECのcotomi v3は導入企業数が前年同期比2.3倍に達した
  • 生成AIの利用デバイス別内訳でスマートフォン(57%)がPC(43%)を初めて上回った
  • McKinsey Japan(2026年3月レポート)によると、生成AIを本格導入した日本企業はホワイトカラー業務の生産性を平均18〜22%向上。従業員100人規模で年間2,000〜3,000万円相当の効率化に相当する
  • リクルートの2026年上半期調査では、20〜30代の転職検討者の34%が「AI活用環境の充実度」を転職先選定の重要基準として挙げた

高畑 拓海の見解

記事の論点には全体的に共感できる。特に「ビジネス利用率と個人利用率の一致」という観察は鋭く、私自身の現場感覚とも重なる。プライベートでAIを使い慣れた人が職場でも使いたがるのは自然であり、「職場ではAIが使えない」という状況が優秀なメンバーへのネガティブシグナルになりつつあるという指摘は、採用・育成に携わる立場として無視できない。

一方で、現場PMとして気になるのは「ツール導入」と「運用定着」の間にある大きな溝だ。記事で紹介されている3つの施策——ChatGPT TeamやCopilotの全社導入、月次の事例共有会、業務別プロンプトテンプレートの整備——はいずれも正しい方向性だが、実務では「ツールを入れたけれど3ヶ月後には誰も使っていない」という状況が頻繁に起きる。原因のほとんどは、推進役が曖昧なまま横展開してしまうことにある。

記事のチェックリストに「AI推進リーダーを任命した」という項目が入っているのは的確だと思うが、もう一歩踏み込むと重要なのは「その推進リーダーが成果を測定する権限と時間を持っているか」だ。兼務で役割だけ渡された担当者は、日常業務に押し流されてしまう。私が案件で経験してきた導入プロジェクトでも、推進者のコミットメントと測定基準の明確化がなければ、どれだけ良いツールも形骸化する。

導入の初期段階では、「全社で使う」より「特定チームで再現性ある成功事例を作る」ほうが現実的な進め方だと感じている。まず小さく動かし、Before/Afterを数字で示し、その成功パターンを他部門に横展開する——この順序を丁寧に踏むことが、組織全体の定着率を上げる近道になる。

(編集レンズ: 現場・運用目線 / チーム再現性目線)

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 で優先ソースに追加

著者について

高畑 拓海のプロフィール写真
高畑 拓海
株式会社シンシア 開発支援事業部 部長

営業出身でエンジニアにキャリアチェンジ。要件定義・実装・PM・チームマネジメント・採用までを横断する。TypeScript / React / Next.js / NestJS / Hono / Ruby on Rails を主力に、現場目線・顧客折衝・チームの再現性・ジュニア育成を重視する。

人気記事

    お問い合わせ

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

    無料相談を予約する