AIネイティブな会社ってなんだろうね ～生成AIを使って業務を言語化し真のBPRが可能になっている会社では？～
AIネイティブな会社って、AIツールやAIエージェントをばんばん作って社員に配る会社ではないよな、と思って自分の考えを整理してみました。
いろんな人のいろんな思惑が混ざるのでLLM活用って意味不明なことになってるんですが、一個ずつひも解くと答えが見えてくるような気がしますね。
結論としては生成AIじゃないところが重要という哲学的な話になってしまいました。しかも前提条件として胆力と覚悟がいるとのこと。
5年後くらいに真理が出ていそうな気もするので、答え合わせできる日を楽しみに待っていたいと思います。
総務省の令和8年版情報通信白書によれば、業務で生成AIを使う日本企業は86.4%に達しました。一方で「業務変革の組織的取組がない」企業は日本27.0%、米国1.4%、ドイツ4.9%、中国2.6%。導入は追いついたのに、変革の段階だけ日本が桁違いに残っています。
この乖離は、ツールやリテラシーの不足で説明されがちです。しかし導入率86%が示す通り、ツールは既に入っています。全社導入もガイドラインも研修も、エージェント作成ツールも揃っています。
買える部品が揃っているのに変革が起きないなら、欠けているのは買える部品ではない、と考えるのが自然です。この記事は、その部品——そもそも売り物にならない部品——の設計図です。
前提：AIネイティブカンパニーは「配る会社」ではない
部品の話に入る前に、土俵を定義します。AIネイティブカンパニーとは、優れたAIアプリを社員に配る会社ではなく、社員が自分でAIエージェントを作れる土台を運用する会社です。どの会社も同じ基盤モデルを使い、データ基盤の整備も一巡すれば、中央が作った標準エージェントの性能は他社と差がつきません。差がつく変数は一つだけ、自分の業務を構造化してエージェントに落とせるかという個人の仕様化能力です。
仕様化とは何か。「議事録を要約して」は誰でも言えます。しかし「月次の増減分析をやらせる」には、どのデータをどの順で見るのか、前年比と予算比のどちらを先に立てるのか、どの金額差から先は人の判断を仰ぐのか、を言語化しなければなりません。自分の業務を工程に分解して初めてエージェントに渡せる。この壁は自然言語で指示できるようになっても消えません。Excelの時代、マクロを書ける人は課にひとりかふたりでした。構文の壁が消えた今、同じ場所に仕様化の壁が立っているだけです。
だとすると組織設計の目的は「全員の底上げ」ではなく、仕様化できる少数の生産量を最大化し、その成果物を残りの全員に配ることになります。
役割は三つに分かれます。ただしこれは序列ではなく、職能の分担です。
使い手。 多数派です。
仕組みを理解する必要はなく、配備された公式エージェントを使うだけでいい。「全員AI武装」とは全員が武器を作ることではなく、作られたものが全員に配備されることです。
使い手に要るのはAIリテラシーではなく、自分の業務の正しい答えを知っていることです。この事業部の粗利率が3ポイント動いたらおかしい、この取引先の売上が月初に立つはずがない——そう気づける相場観は、担当者なら配備の前から持っています。だから配備は本人の業務領域に限る。これが使い手側の唯一のルールです。
作り手。 手を挙げた少数です。
広い権限と上位モデルを渡す代わりに成果物の提出を義務づけます。入口は知識試験ではなく実技審査、いわば社内免許です。プロンプトの書き方を筆記で問うのではなく、ダミーデータでも自業務でもいいので、実際に動くエージェントを提出させて判定します。
責任は「道具」ではなく「部下」のモデルで設計します。承認されたスコープの中でエージェントが間違ったマスタを参照して誤った集計を配ってしまったなら、それは組織が吸収する事故です。承認していない書き込みを勝手にやらせたなら、本人の逸脱です。この線を引かずに全責任を個人に負わせると、合理的な社員は権限を返上して自衛し、制度の切れ味が死にます。
土台。 会社が持つのはここです。
最上位モデルを出し惜しみしない推論環境、基幹から片方向コピーしたデータレイクとMCP接続口、権限の委任、そして分離です。
委任の実装は「操作の重さ」で層別します。エージェントを本人とは別のIDとして登録し、本人権限の部分集合を時限付きで貸す。データを読んでレポートを作るのは素通し、仕訳を投入したりマスタを書き換えたりするのは都度承認。
分離とは、機密データへのアクセス・信頼できないコンテンツへの曝露・外部通信の三つを同一エージェントに同居させないことです。この三つの組み合わせはSimon Willisonがlethal trifectaとして定式化したもので、三つが揃うと仕込まれた指示で機密データを外に運び出させることができます。賢いモデルほど仕込まれた指示にも忠実に従うので、これはモデルの進化で消える問題ではなく恒久ルールとして扱うべきだ、と私は見ています。
社員食堂に例えるなら、会社が持つのは厨房と食材の調達網、料理人は社内から募り、大多数は配膳されたメニューを食べる。
食べる人は調理法を知らなくていいが、自分がいつも食べているものの味は知っているので、腐った料理は吐き出せる、という絵です。
欠けている部品：回収装置
さて、ここまでの部品は、実はどれも買えます。導入と研修は昔から売っていますし、非エンジニアがエージェントを組めるツールも各社が外販しています。
それでも変革が起きないのは、作り手の層と使い手の層をつなぐ部品が欠けているからです。作り手の成果物を標準化して全員に配備し、配備への反応を回収して次に回す仕組み。私はこれを回収装置と呼んでいます。
この装置の設計で、実務上いちばん重要な観測から書きます。配備の失敗は、不満ではなく沈黙として現れます。 現場に合わないツールは反発されません。静かに無視されるだけです。
分析コメントを自動で返すツールを配ったのに、現場の月次業務の実態は分析ではなく内訳の作成で、ツールが業務フローに入る場所がそもそもなかった——こういう失敗は、苦情としてではなく、ログイン数がただ伸びないという形で判明します。デモを見せれば「凄いですね」と言われ、困りごとを聞けば「特にありません」と返ってくる。
この沈黙は想像力の欠如ではありません。業務の実態には、文書にない暗黙の手順や、場合によっては誤りが含まれています。それを推進側に開示することは、使い手にとって支援の受け入れではなく査定の受け入れに見える。だから合理的に黙ります。
ヒアリングが機能しないのも同じ理由で、しかもヒアリングには悪意のない嘘が混ざります。
このインセンティブ構造を反転させる入力は、一つしかありません。配備した後に出てくる「うちの業務はこうじゃない」という不満です。不満は、訂正すれば自分が楽になるという見返りを持つ、唯一の自然な開示です。だから回収装置にとって、不満が来ることは障害ではなく接続成功の証拠であり、本当の死因は沈黙のほうです。
入口の実務もここから決まります。提案を募るのではなく、完成品を先に配って差分を言わせる。順序は常に配備が先、不満が後です。
不満を受けたら、要望の共通性を入口で予測しません。「うちの部署は出荷ベースではなく検収ベースで見たい」という要望が来たら、それが他部署に共通するかを会議で議論するのではなく、まず「枝」として検収ベース版を作ってしまう。他部署が使い始めたら「幹」に昇格させ、誰も使わなければ消す。判定を予測から観測に置き換え、合議による事前判定を消します。
入口で即座に弾くのは、数字の意味・キー・履歴の一貫性に触る要望だけです。表示や手順や粒度は無害ですが、「この費目はうちでは販管費ではなく原価に入れて見せてほしい」のような意味の読み替えは、裏帳簿の入口だからです。
そして枝が消えても、業務を標準に寄せろという圧力はかけません。枝が削除された部署に「なぜ標準のやり方で回らないのか説明してほしい」と言った瞬間、その窓口には二度と不満が来なくなります。
窓口が機能する条件は申告の無罰性で、計測器が検察を兼ねてはいけない。枝の生死データは業務標準化の判断材料として経営側に渡しますが、判断と執行はそちらの仕事です。この分離は最初に明文で宣言しておく必要があります。「そのデータで指導もやってくれ」という善意の圧力は、必ず来るからです。
この装置が回ると、ループは二本回ります。
一本目はエージェント改善のループ。二本目は、不満を仕様化する過程で、誰の文書にもなかった業務の実態が初めて形式知になるループです。
長期的な価値は二本目のほうが大きいと考えています。日本企業の業務が測定不能なのは暗黙知に埋まっているからですが、それを「文書化せよ」という号令で掘り出すことは誰にもできませんでした。不満駆動の回収装置は、掘り出す動機を初めて使い手の側に置く仕組みです。しかもこうして生まれる形式知は、かつてのBPRが残した業務フロー図と違って腐りません。仕様がそのまま稼働物なので、現実とずれれば不具合として現れ、直され続けるからです。
業務の言語化に動機があり、言語化されたものが腐らず、標準は合議の予測ではなく枝の生死という観測で決まる。業務プロセスの再設計という三十年前からある目標に、ようやく通行可能な道が付いた、と言ってもいいと思います。
なぜこの部品は売り物にならないのか
回収装置が欠けている部品だとして、なぜ誰も売っていないのか。
売れないからです。
三層をベンダーの目で見直すと、導入・研修・ガイドラインは工数と単価で見積もれ、エージェント作成ツールはライセンスとして売れます。
しかし作り手は業務知識を持つ社内人材しかなれないので外販できず、免許制の運用、事故を吸収する責任設計、不満窓口の維持は、売り切りになじみません。回収装置は買って据え付ける納品物ではなく、回し続ける運用だからです。これは部品の性質です。日本のベンダーが売っていないだけでなく、米国のベンダーも売っていません。
では米国はどうやって埋めているのか。買っていません。内製です。
米国はIT人材の6割超が事業会社の側にいて、市販されていない部品を社内で組める。日本は7割がベンダー側にいるので、市場に無いものは組織にも無いままになる。導入率86%と組織的取組27%の乖離の正体は、ベンダーの品揃えの差でも買い手の怠慢でもなく、市販不能な部品を内製できる人材がどちら側にいるか、という一点だと私は読んでいます。
裏を返せば、ここは外注で埋まらないぶん、内製できた会社だけの差別化要因として残るということです。
これは処方箋ではない
最後に、この設計図が要求するものを正直に書きます。
手を挙げる作り手の存在。
最上位モデルを出し惜しみしない経営の胆力。
スコープ内の事故を吸収する覚悟。
設計図はこれらの前提を消費するだけで、作ってはくれません。
胆力とは何か。具体的にはこういう場面です。作り手にトークン上限なしで最上位モデルを渡すと、月のAPI費用が一人あたり数万円になる。経理から「使いすぎでは」と照会が来る。
ここで「まずは安いモデルで様子を見よう」と絞った瞬間、この設計は死にます。作り手の道具が個人で契約できる環境より鈍った時点で、優秀な作り手ほど自腹の環境に流出するか、会社では何も作らず沈黙するかのどちらかに行くからです。
システム開発の見積もりには数千万円の稟議を通す会社が、社員の推論環境の月数万円を渋る。このねじれを飲み込めるかどうかが、胆力の中身です。
覚悟とは何か。こちらも場面で書きます。
作り手が承認済みのスコープで組んだ集計エージェントが、締め切り前の仮の数字を確定値として引いてしまい、誤った着地見込みの載った資料が会議まで上がってしまう。発覚したとき、必ず出てくるのは「誰が作ったんだ」という声です。
ここで作った本人に始末書を書かせた瞬間、この設計は死にます。見ているのは本人ではなく、周りの作り手候補の全員だからです。翌月から誰も手を挙げなくなり、既に挙げていた人も権限を静かに返し始める。部下が承認された手順の中で間違えたとき、責任を取るのは上司であって、部下の給料から損害を引くわけではありません。同じことです。
承認したスコープの中の事故は組織の費用として飲み、直すのは人ではなく仕組みの側——締め前データを引けない関門を足す、のほうです。事故の直後に犯人探しを一度我慢できるかどうかが、覚悟の中身です。
とはいえ、必要なのは大きな変革プログラムではありません。前提を飲める会社が、どこか一部門からでも回収装置を回し始めれば足ります。最後の部品は買えないので、作るしかない。その最初の設計図として、この記事を置いておきます。
（補足）ファクトチェック
本文はLLMとの会話をもとに再構成したものです。公開前に、修正前の原稿をLLM（Claude Fable 5）に読み込ませ、Web検索によるファクトチェックを実施しました。以下はその結果の要約で、本文には修正を反映済みです。
なお、LLMによるファクトチェックなので、これ自体も完全ではない点はご留意ください。
検証済み（正確だった主要ファクト）
総務省「令和8年版情報通信白書」（2026年7月24日公表）の数値。何らかの業務で生成AIを利用している日本企業は86.4%（2024年度調査は55.2%）。業務変革について「組織的な取組はない」と回答した割合は日本27.0%、米国1.4%、ドイツ4.9%、中国2.6%（総務省公表資料・解説記事で確認）
IT人材の所属先の日米差。IPAの2023年3月公表の比較で、日本はIT人材の73.6%がIT企業に所属（2020年、2015年は72.0%）。米国は64.9%が非IT企業に所属（2021年）。本文の「米国は6割超が事業会社側」「日本は7割がベンダー側」はこの数値に基づく（IPA発表・日経xTECH報道で確認）
Simon Willisonの「lethal trifecta」の定義。2025年6月16日の同氏のブログで、機密データへのアクセス・信頼できないコンテンツへの曝露・外部通信の三つの組み合わせとして定式化されていること（原文で確認）
修正した箇所
① Willison氏への帰属範囲
修正前：「Simon Willisonがlethal trifectaとして定式化した通り、賢いモデルほど仕込まれた指示にも忠実になるため、モデルの進化では解決しない恒久ルールです」と記述していた。
修正後：同氏が述べているのは三つの組み合わせの定義と「LLMはコンテンツ中の指示に従ってしまう」「確実に防ぐ方法はまだ分かっていない」という点まで。「賢いモデルほど忠実になる」「モデルの進化では解決しない恒久ルール」は同氏の主張ではなく本記事側の判断なので、帰属を定義までに限定し、それ以降を筆者の見解として書き分けた。論旨は変わらない。
補足事項
白書の86.4%は、活用方針を「わからない」と答えた企業を除いて集計された数値。本文は白書の見出し数値をそのまま用いている
IT人材の所属先データは日本2020年・米国2021年の調査に基づく。本文は現在形で書いているが、確認できた範囲ではこれが最新の日米比較
