Askhub
資料請求 お問い合わせ
お問い合わせ

入門

AXが進まない会社で、上と現場を動かして社内合意をつくる方法 〜AX推進入門 第8回〜

松本拓哉

稟議に半年かかる会社で、AXはどう進めるのか

「親会社の許可がないと、社内のメールや文書にAIをつなげない」「稟議を出しても、結論が出るまで半年かかる」。AX（AIトランスフォーメーション。AIを前提に業務や組織を変えること）を任された推進担当は、こうした会社でまず手詰まりを感じるのではないでしょうか。どこから手を付けても、何も動かないように見えるからです。

この記事は、AX推進入門シリーズ（全10回）の第8回です。シリーズの一覧はこちら。

稟議は長くても、最初の材料は1か月ほどでそろう

稟議そのものに時間がかかっても、最初の1業務を作りきって申請の材料にするまでは、筆者が支援してきた経験では1か月ほどです。たとえば筆者の会社では、1週間ごとに新しく作ったものを現場に持っていき、実際に動く画面を見せています。もちろん1週間で完成品になるわけではなく、使ってもらった後の直しは続きます。それでも、データ連携のような手間のかかる作業を後回しにできるPoCなら、1か月で申請の材料はそろいます。だから、稟議が長いからといって着手を遅らせてはいけません。「時間がかかる会社ほど急げ」が原則です。結論まで半年かかる会社では、申請が1日遅れれば、ただでさえ遠い結論の日がさらに遠のきます。

進め方の要は、推進のステップを細かく分け、説得材料をそろえる取り組みを高速で回すことです。一度に大きな承認を取りに行くのではなく、いまのルールで許される範囲で一歩進み、その結果を材料にして次の許可を取りに行きます。こうして一つひとつのハードルを下げていけば、動かないように見える会社でも進められます。諦めないでください。

上と現場を動かすときの原則は「上には実績、現場には納得感」です。ここでの上は、親会社や経営を指します。

グループ会社・規制業界・自治体で、AXが進まない理由

この記事が想定するのは、主に次の3つの会社です。どれも、推進担当一人の努力だけでは動かしにくい事情を抱えています。

  • 親会社がいるグループ会社
  • 金融・医療など、業界の基準や規制がある会社
  • 自治体

グループ会社では、使ってよいツールなどを親会社に決められていることがよくあります。子会社の中で稟議を通しても、親会社の決まりはめったなことでは覆せません。

金融や医療の会社は、業界の基準や規制に準拠し続ける必要があります。これは外から押し付けられた制約というより、その業界でちゃんとした会社、つまり取引先や利用者から信頼される会社で居続けるための条件です。自治体も、国の指針に沿いながら住民の情報を扱う立場にあり、新しいツールの導入には慎重な手続きが要ります。

ただ、どの会社でも問題になるのは、ルールの厳しさそのものより、AXが実際に進まないことです。進まない理由は、次の3つに分けられます。

動かないもの

よくある場面

この記事で扱う節

現場

「ミスが起きたらどうするのか」と、使うのを断られる

現場を動かす

上（親会社・経営）

親会社や経営の承認が下りない

上を動かす

会社の構造

グループ内のツールを必ず使う決まりがある

構造から来る難しさ

業界の規制は、この3つのどれにも関わります。規制のある業界と自治体については、ガイドラインの使い方を別の節で扱います。

説得材料は、PoCで作りきる

よくあるのは、AIを社内のデータやシステムにつなぐには親会社の許可が要る、という状況です。つなぐ先は、Google Workspace や Microsoft 365（メールや文書、表計算などをまとめたクラウドの業務サービス）や、基幹システムです。基幹システムは、会計・販売・在庫など、会社の中心の業務を支えるシステムを指します。

許可を取るには「つないだら何が良くなるか」を示す必要があります。しかし、まだ無いものの効果を空想で語って説得するのは難しいものです。だからPoC（本格導入の前に、小さく作って効果と実現性を確かめる検証）をやり、説得材料を作りきります。作りきるとは、途中で止めず、本番と同じ中身のシステムまで作ることです。

始めるのは、いまのルールの中でできる段階からです。たとえば、経費精算の申請を社内規程と突き合わせ、確認が要るものだけを人に回すAIを作るとします。AIをつなぐ社内のシステムやサービスを環境と呼ぶと、必要な許可が少ない順に次の3段階があります。

  • データもダミーで、社内の環境にもつながない：架空の申請データを作り、AIのサービスに直接アップロードして試す。または、社内のどこともつながっていない検証専用の環境を1つだけ用意し、AIはそこにだけつなぐ
  • 環境にはつながず、データだけ実データを使う：過去の申請データを書き出して使う。氏名や口座番号のような個人情報・機密の項目は、マスキング（伏せ字にして読めなくすること）で伏せる
  • 許可が出たら、本番の環境につなぐ

最初の2つの段階では、システム連携は後回しにします。データはCSV（表の形のデータを受け渡すためのファイル形式）で書き出し、それを読み込ませる形で受け渡します。

経費精算の例で、PoCの段階をデータと環境の組み合わせで3段に積んだ図。1段目は、架空の申請データを使い、AIのサービスに直接上げるか孤立した検証用の環境で試し、社内の環境にはつながない。2段目は、個人情報と機密の項目をマスキングした実データをCSVで渡し、環境にはつながない。3段目は、許可が出たら実データで本番の環境につなぐ。どの段でも、真ん中のAIのシステムは同じものを作りきり、変わるのは入り口と出口だけであることを示している

どの段階でも、システム自体は作りきります。段階ごとに違うのは、AIに渡すデータ（入り口）と、AIをつなぐ環境（出口）だけです。経費精算の例なら、申請を読み込み、規程と照らし、確認が要るものに理由を付けて人に回す、という中身は最初から本番と同じものを作ります。

経験上、PoCは大体の場合これで成果が出ます。本番の環境につながっていなくても、中身を作りきっていれば、AIが申請をどれだけ正しく仕分けられるかは確かめられるからです。

作りきると、2つのものが手に入ります。1つは「本番のデータさえつながれば、これくらいの成果が出る」というROI（投資に対してどれだけ効果が返るか）の数字です。業務の時間を積み上げてROIを出す方法は、第5回（業務フローの作り方と、AI導入のROIの出し方）で扱いました。もう1つは、現場に実際に試してもらえる実物です。ダミーのデータでも、現場の担当者は自分の業務がどう変わるかを画面で確かめられます。

一方で、一般には試す段階で止まる取り組みも少なくありません。IPA（情報処理推進機構）のDX動向2026では、生成AIが部署の業務の流れに組み込まれている企業は11.9%にとどまります。米調査会社ガートナーも2024年、生成AIの取り組みの少なくとも30%がPoCの後に見送られると予測しました。理由の1つは、事業上の価値がはっきりしないことです。だからこそ、ROIの数字と動く実物の2つを、PoCの段階でそろえておきます。

最初の対象は、早く確実に成果が出る小さな業務にします。選ぶときは、第5回で挙げた4つの物差しを使います。量が多いか、判断基準が明文化されているか、データがそろっているか、システムやデータの持ち方を変えずに済むか、です。

取り組む順番は、クイックウィン、横展開、本丸です。クイックウィンは早く確実に出せる小さな成果、横展開は同じやり方をほかの部署や業務へ広げること、本丸は会社として一番変えたい中心の業務を指します。最初の対象は小さくても、狙いは3つあります。現場が認める効果を出すこと、ほかの部署でも同じ手順で使える進め方（型）を作ること、AIを日常の業務で使いこなす現場を作ることです。

現場を動かす：負担は小さく、人参は大きく

前提として、現場は業務を効率化なんてしたくないものです。今のやり方で仕事は回っており、新しいやり方を覚えるだけでも負担になるからです。

推進担当の提案を断るのは、親会社や経営だけではありません。意外にも、現場から断られることのほうが多くあります。個人情報を扱う部署で「ミスや事故が起きたらどうするのか」と言われる、自分の業務が変わることそのものに反発される、といった形です。

ここで「業務効率化なんだから言うことを聞いてほしい」と押しても、うまくいきません。現場を動かす肝は、現場の負担をいかにかけずに進めるかと、人参（現場がすぐ得られる、目に見える得）をどう大きくするかにあります。

現場のやることを増やさない

「業務がこう変わります。これまでやっていなかったことをしてください」と頼んでも、人は動きません。新しい業務は、「途中までは今と全く変わりません」「ここがまるっとなくなるだけです」と説明できる形に作ります。

経費精算の例なら、「申請を受け付けるところまでは今と同じです。規程と1件ずつ突き合わせる作業がまるっとなくなり、AIが確認を求めたものだけを見ればよくなります」と言える形です。

説明の場も同じ考え方で用意します。「ドキュメントを読んでおいてください」と頼んでも、まず読んでもらえません。「30分だけください。準備も宿題もありません」と時間だけをもらい、その場で使い方を説明します。

人参は、負担より常に大きく

あわせて、現場がすぐ喜べる人参を考えて準備します。経費精算の例なら、月末に残業して申請を突き合わせていた時間がなくなる、規程を調べ直す手間がなくなる、といったものです。

そして、現場にかかるコスト（負担）より、人参が常に大きくなるようにします。「常に」とは、最初の30分の説明から、試してもらう期間、本番への切り替えまでの、どの時点でもという意味です。どこか一時点でも負担が人参を上回れば、現場にとってはその時点で損な話になります。

そのうえで、できるだけ早い段階で新しい業務のイメージを湧かせ、ポジティブな印象を持ってもらいます。

聞き取りはやりすぎず、翌週には動く実物を見せる

聞き取りは、少し聞いたらお礼を言って切り上げます。現場の関心が冷めないうちに、翌週には動く実物、つまり実際に操作できる画面を見せに行きます。

資料ではダメで、画面が要ります。画面を見せていると、現場から「ここはこうだね」と声が出て、乗り気が高まり、業務の変わり方が現実味を帯びてきます。

これができるのは、AIを使うと試作の画面を短い期間で作れるようになったからです。社内の推進担当が自分でAIを使って作る場合も、翌週に画面を見せられます。ベンダー（開発・導入を請け負う外部の会社）に頼む場合も、聞き取りから1週間で画面を見せる速さで回すことを、最初に段取りへ入れておきます。

推進担当がノートパソコンの画面で動く試作を見せ、経理の担当者2人が画面を指さしながら笑顔で意見を言っている、明るい会議室の水彩の絵

何を作るかを決める段階から巻き込む

人は、自分が関与していないものを最後に渡されても、従いたくないものです。作り終えてから見せる、途中から呼ぶ、のではなく、何を作るかを決める段階から現場を巻き込みます。第4回（要求定義と要件定義の違い：AI導入で何を作るかの決め方）で扱った要求定義と要件定義の段階です。

「自分たちがいいねと決めた」ものなら、最後のアダプション（新しい業務のやり方を現場に定着させること）でも、現場は協力してくれます。

「ミスが起きたらどうするのか」には、評価で答える

第6回（AIのミスはどこまで許容するか：精度の測り方とリスクの決め方）で扱った評価のうち、答えに使うのは次の3つです。

  • 見落としの数：AIの判定を1件ずつ正解と照らし合わせ、本当は問題があるものをAIが問題なしと判定した件数
  • 最悪の場合の試算：見落としが起きたときの手戻り時間や損害額を、多めに見積もった値
  • ガードレール：AIが実行できる操作に条件を付け、損害に上限を決めてあること

「大丈夫です」と言う代わりに数と上限を示せば、漠然とした不安が、確かめられる問題に変わります。

上を動かす：現場の合意を取ってから、実績と現場の声を持っていく

上（親会社や経営）に持っていくのは、許される範囲で作った最大限の実績と、現場のポジティブな声です。上を説得するうえで、現場の声はとても重要です。推進担当の説明だけでは、実際に使う人がどう受け止めたかが伝わらないからです。

だから順序は、現場の合意が先、上はその後です。現場が「これなら使いたい」と言う状態を作ってから、親会社や経営に上げます。持っていくときは、次のような形になります。

「こういうものを作りました。こういう結果でした。現場からもこういう反応をもらっています。なんとか通したいです」

経費精算の例なら、「規程との突き合わせをAIで行う仕組みを作りました。個人情報を伏せた過去の申請で試すと、確認の時間が月40時間ほど減る見込みです。経理の担当者からも、月末の残業がなくなるならぜひ使いたい、という声が出ています」となります（数字は架空です）。

承認がすんなり通ることは、めったにありません。それでも、きちんと手順を踏めばなんとかなるケースはあります。1回で通らなければ、許される範囲で次の段階の実績を作り、もう一度持っていきます。これを繰り返して、上も現場も、少しずつ動かしていきます。

段階は、PoC、効果検証会、本番運用と並行稼働、ほかの部署や拠点への展開、の順に進みます。効果検証会は、現場が実データでシステムを動かし、かかる時間を確かめる場です。並行稼働は、今のやり方と新しいやり方を並べて動かし、結果を見比べる期間を指します。その先には、改善を自社で回せるようにする内製化があります。

PoC、効果検証会、本番運用と並行稼働、ほかの部署や拠点への展開の4段階を縦に並べ、それぞれの段階で上に持っていくものを右に添えた図。PoCでは動く実物とROIの見込み、効果検証会では現場が測った時間と現場の声、並行稼働では本番での実績、展開ではほかでも使える型と展開先の声を持っていく

上に持っていく予算も、第7回（AI導入の費用相場と予算の取り方、ベンダーの選び方）で見たとおり、この段階に合わせて半期ごとに広げます。

結果を社内に伝え、次の部署へ広げる

上に持っていった実績と現場の声は、ほかの部署へ広げるときにもそのまま使えます。効果検証会の結果や並行稼働の実績を、次に広げたい部署にも見せに行きます。

伝えるときの主語は、推進チームではなく現場です。推進チームが何を作ったかより、経理の担当者が何に助かったかのほうが、隣の部署の人には自分の話として届きます。

どこまで広げられるかは、第3回（AI導入の進め方：7つのステップと、人とAIの分担）で書いたとおり、現場の満足度で決まります。現場が「いいね」となれば一気に広がり、その声がまた次の部署を動かす材料になります。

規制業界・自治体：基準が示されているぶん、むしろ進めやすい

金融・医療・自治体は規制が厳しい分野ですが、そのぶん業界の基準がすでに示されています。これは、ある意味で逆の進みやすさです。基準が無い会社と比べると、その違いが分かります。

基準が無い会社では、ベンダーに「何を準備すればいいですか」と聞くと、「御社が何を許容できるか次第です」と返ってきます。推進担当は、ベンダーと社内の情報システム部門（社内のITの管理とセキュリティを担う部署）の間で、基準をすり合わせ続けることになります。導入に時間がかかる原因の多くは、ここにあります。

規制業界や自治体では、基準をゼロから情報システム部門やベンダーと議論する手間は大きく減ります。情報システム部門も、基本的には「ガイドラインに沿っていればいい」としか言いようがないからです。

2026年11月時点で確かめた、各分野の主な文書は次のとおりです。

分野

文書と版

中身

金融

金融庁「AIディスカッションペーパー」第1.1版（2026年3月）

金融分野でAIを使うときの論点の整理。法令やガイドラインではない

金融

FISC（金融情報システムセンター）「金融機関等コンピュータシステムの安全対策基準・解説書」第14版（2026年3月）

金融機関のシステムの安全対策の基準。第14版でAIの安全対策を改訂

医療

厚生労働省「医療情報システムの安全管理に関するガイドライン」第7.0版（2026年6月）

医療機関の情報システムの安全管理の基準。外部への保存や委託の条件を定める

自治体

総務省「自治体におけるAI活用・導入ガイドブック〈導入手順編〉」第4版（2025年12月）

自治体がAIを導入する手順と事例。第4版で生成AIを追加

国

デジタル庁「行政の進化と革新のための生成AIの調達・利活用に係るガイドライン」第2.0版（2026年6月決定）

政府が生成AIを調達し使うときの基準。自治体には参考として示す

分野によって、生成AIをどこまで名指ししているかには差があります。医療のガイドライン第7.0版には、生成AIを名指しした規定が見当たりません。AIのサービスも、外部への保存や委託についての一般の規定に当てはめて判断することになります。

ただ、ガイドラインを自社のルールに落とす作業は残ります。どのガイドラインも、組織が自分の利用ルールを作ることを前提にしているためです。ここでの落とすとは、どの情報をどのサービスに入れてよいかなどを、自社の利用ルールとして具体的に決めることを指します。たとえば表の総務省のガイドブック第4版は、自治体が作る生成AIの利用ガイドラインのひな形を添えています。デジタル庁のガイドライン第2.0版も、利活用ルールのひな形を用意しています。

上の段は基準が無い会社の流れで、推進担当がベンダーに何を準備すればよいかを聞き、ベンダーは御社次第と返し、情報システム部門に持ち帰ってまたベンダーに戻る往復が続く。下の段は基準がある会社の流れで、業界のガイドラインから自社のルールを決め、ベンダーが満たせるかを確かめ、満たせなければ満たせるベンダーを探して進める

推進担当がガイドラインに沿った基準をベンダーに示せば、あとはそのベンダーが基準を満たせるか、満たせなければ別のベンダーを探すか、の話になります。だから、基準の中でもう進めてしまえばよいのです。

基準をベンダーに渡すとき、分野を超えて共通する論点は次の6つです。

  • 入力したデータを、AIの学習に使わせない
  • 約款同意型のサービス（一般向けの利用規約に同意するだけで使えるサービス）に、機密情報を入れない
  • データの保管場所。日本の法律が及ぶ所に置かれるか
  • ISMAP（政府が使うクラウドサービスの安全性を評価し、登録する制度）に登録されているか
  • 責任分界、つまりどこまでをベンダーが、どこからを自社が責任を持つかを書面にする
  • 監査、つまり決まりどおりに運用されているかを定期的に確かめられるか

自社のルールに落とした結果の一例に、保存と処理で線を分ける引き方があります。データの保存先は国内に限ります。一方、AIが答えを出す処理（推論）は、セキュリティの認証を取得した事業者であれば、国外で行うことも認めます。

ただし、どの業界にも手探りの領域は残ります。たとえば機密性の高いデータの扱いは、自治体でも事例ベースで判断されています。総務省の調査では、生成AIに入力してよいとした情報の範囲が、自治体ごとに大きく分かれていました。総務省のガイドブックは、条件付きで個人情報の入力を認めた自治体の例を、先行事例として載せています。

金融庁のディスカッションペーパーも、一部の規制の当てはめについては「個別具体的な事案に即して実質的に判断」すると書いています。ガイドラインの中でも、攻めるか（使う範囲を積極的に広げるか）守るか（慎重に絞るか）の選択は残ります。

こうした判断が分かれるグレーな所では、他社の事例と、業界で一般的な水準が判断の根拠として効きます。最初にベンダーへ「自分の業界での事例調査」を頼むのは一つの手です。調べた事例は、そのまま情報システム部門や上を説得する材料になります。

構造から来る難しさ：実態を先に作り、形を後から追いつかせた一例

最後は、会社の構造から来る難しさです。ここで書くのは勧める進め方ではありません。実態としてそうやって会社が動く場合もある、という一例として読んでください。

たとえば、グループ内のベンダーが作ったツールを必ず使わなければならない会社があります。グループの中で売上を循環させ、お金を外に流さないための構造です。AIで業務を自動化したくても、そのツールを外す話は、推進担当の稟議では動きません。

このとき、ボトルネック（全体の進みを止めている1か所）を「そこだけ」にする、という動き方があります。そこさえ変われば、これだけの成果が出る、という状態を先に作るのです。セキュリティの許可さえ取れれば、既存のツールを解約しないまま、AIでの自動化を先に進めます。

問い合わせ対応の例で言うと、グループ内のツールをシステムA、AIで自動化する新しい仕組みをシステムBとします。しばらくの間は、同じ問い合わせの記録がAにもBにも入る、一時的なデータの二重管理を許容します。その間は、不整合が起きない設計をし、常にどちらにも戻せるよう正しいデータを保ちます。

実績が出て「Bでこれだけ効率化できている」と言える時点でBへ移し、その実態をもってAを解約しに行きます。解約してから移行するのではなく、移行してから解約するという順序です。解約を先に通そうとすると、まだ無い効果を根拠に構造そのものを動かす話になります。移行を先にすれば、解約の稟議は、すでに出ている実績を根拠にできます。

既存のシステムAから新しいシステムBへの移行を、上から下への時間軸で示した図。最初はAだけを使う。次に、AとBの両方に同じデータが入る二重管理の期間があり、どちらにも戻せるよう正しいデータを保つ。Bで効率化の実績が出たらBへ移し、最後にその実態をもってAを解約する

構造上動かしにくい会社では、実態を先に作り、形を後から追いつかせる順序で物事が動くこともあります。

推進担当が押さえる要点

  • 時間がかかる会社ほど急げ。最初の1業務を作りきり、申請の材料にするまでは1か月ほど
  • PoCは、いまのルールで許される段階から始める。システムは作りきり、変えるのはデータと環境だけ
  • 現場のやることを増やさず、負担より人参が常に大きい形を作る
  • 聞き取りは短く切り上げ、翌週には動く画面を見せに行く
  • 何を作るかを決める段階から現場を巻き込み、現場の合意を取ってから上に持っていく
  • 業界のガイドラインがあるなら、それを基準にベンダーと話す。自社のルールに落とす作業は残る

まとめ：上には実績、現場には納得感

AXが進まない会社でも、最初の1業務を作りきって申請の材料にするまでは1か月ほどです。原則は「時間がかかる会社ほど急げ」です。いまのルールで許される段階のPoCでシステムを作りきり、ROIの数字と動く実物を手に入れます。

現場には、やることを増やさず、負担より常に大きな人参を用意し、何を作るかを決める段階から巻き込んで納得感をつくります。上には、その現場の合意を取ったうえで、許される範囲の実績と現場の声を持っていきます。規制のある業界や自治体では、示されている基準を使ってベンダーと話を進められます。会社の構造から来る難しさについては、新しい仕組みを先に動かして実績を作り、その後で既存のツールを解約した会社の例もあります。

次の第9回（AIで人を減らさずに成果を出す、リソースシフトとリスキリングの考え方）では、AIで浮いた時間をどこへ向けるかを扱います。

シリーズの目次

関連記事

参考資料

Askhubについて

Askhubは、日本の中堅・大企業がAIに業務を任せるための基盤です。業務の型（オントロジー）でAIに許す操作を定め、承認と判断ログで任せる範囲を広げながら、国産の基幹システムまで書き込めるようにします。導入はコンサルタントが伴走します。

この記事の言葉で言えば、Askhubは、PoCで作りきったシステムを、承認と判断ログを付けたまま、データと環境（入り口と出口）を差し替えて本番へつないでいくための基盤にあたります。

※Askhubのサービスに関する記載は、2026年11月時点の情報です。

関連するページ：製品の全体像、伴走支援

社内の合意づくりや、ルールの中で始めるPoCの進め方を相談したい方は、お問い合わせからご連絡ください。

この記事を書いた人

松本拓哉

インターセクト株式会社 代表取締役 CEO

東京大学大学院 工学系研究科 物理工学専攻 博士課程中退。2023年4月、インターセクト株式会社を創業。これまで数十社以上の AX 推進を支援し、自らもコンサルタントとして現場を主導。エンジニアとして AI エージェント基盤「Askhub」の開発にも従事。

この記事の内容について相談する

自社の業務でどう進めるか、相談したい方はこちらのフォームからご連絡ください。1〜2営業日以内に担当者よりご連絡します。

サービス資料をダウンロードする

入門の記事をもっと見る