投稿者: 沼田 勇作

  • AIだけでは進まないDX――生成AIを導入しても会社が変わらない理由

    参考資料

    生成AIを導入した。会議の議事録を要約できるようになった。メールや提案書の下書きが速くなった。社内資料を探す時間も短くなった。

    それでも、会社の仕事の進め方は以前とほとんど変わっていない。部署ごとの表計算ファイルは残り、担当者しか分からない仕事もなくならず、経営判断に必要な数字は毎月人が集め直している。

    このような会社は珍しくありません。生成AIは確かに便利です。しかし、AIを導入したことと、会社を変革したことは同じではありません。

    AI導入は広がった。しかし、企業変革には届いていない

    IPAが2026年7月に公表した「DX動向2026調査のポイント」では、国内企業でAI導入が広がり、多くの企業が効果を実感する一方、その用途と効果は業務の効率化・迅速化が中心で、新たな価値創出やビジネス変革への展開は限定的だと報告されています。

    これは、生成AIに力がないという話ではありません。AIに対して「今の作業を速くしてほしい」と頼めば、AIは今の作業を速くします。しかし、今の業務の目的や構造そのものを問い直さなければ、会社は現在の形のままです。

    紙の文章をAIで読み取る。人が作っていた集計表をAIに作らせる。担当者が探していた情報をAIに探させる。いずれも有益な改善ですが、それだけでは、紙や表計算ファイルを前提に作られた仕事の流れを温存することがあります。

    効率化とDXの違いは、「会社の形」が変わるかどうか

    効率化は、現在の仕事をより速く、安く、正確に行うことです。DXは、デジタル技術を使いながら、会社の業務、組織、顧客への価値提供、意思決定の仕組みまで変えていく取り組みです。

    たとえば、見積書の文章を生成AIに書かせれば作成時間は短くなります。では、見積もりに必要な原価、在庫、作業時間、過去案件の情報は、同じ基準で管理されているでしょうか。値引きを誰が判断し、どこから承認が必要かは決まっているでしょうか。受注後の作業、納品、請求へ情報がつながっているでしょうか。

    この流れまで設計し直し、見積もりで生まれた情報が後工程と経営判断に再利用されるようになれば、単なる文書作成の短縮を超えて、会社の仕事の仕組みが変わります。

    最初に決めるべきは「どのAIを使うか」ではない

    生成AIの導入を検討すると、製品名や機能比較から始めたくなります。しかし、本来先に決めるべきなのは、次のような経営上の問いです。

    • どのような会社に変えたいのか
    • どの業務を、なぜ変えるのか
    • 誰が担当し、誰が判断するのか
    • どの情報を一つの事実として管理するのか
    • 誰に何を見せ、どの操作を許すのか
    • AIに何を任せ、どこから人間が承認するのか
    • 変化の成果を、どの数字で確かめるのか

    これらを整理したものが、生成AI時代のDXに必要な設計図です。詳細なシステム仕様書を最初から作る必要はありません。まずは「現在の仕事がどう流れているか」と「将来はどう流したいか」を、経営者と現場が同じ図を見ながら話せる状態にすることが出発点です。

    設計がないままAIを入れると、現在の混乱が速くなる

    営業の顧客台帳、経理の請求先一覧、現場の案件表に、同じ顧客が別々に登録されている会社を考えてみましょう。部署ごとに名称や住所が違い、どれが最新かも決まっていません。

    この状態でAIに資料作成や顧客対応を任せても、AIは「どの記録が会社として正しいのか」を自動的には決められません。曖昧な指示や食い違うデータを受け取れば、もっともらしい答えで不足を埋めることがあります。

    承認ルールが口頭で決まり、例外対応が担当者の経験に依存し、権限が個人ごとの場当たり的な設定になっている場合も同じです。AIによる自動化を増やすほど、曖昧な業務ルールが広い範囲へ速く伝わります。

    生成AIは、整った仕組みを速く動かすことができます。同時に、整理されていない仕組みまで速く動かしてしまいます。だから、導入速度を競う前に、何を正しい業務としてAIへ渡すのかを決めなければなりません。

    AIは設計者ではなく、設計を実現する強力な手段

    AIは、業務の聞き取り内容を整理し、資料を比較し、データ項目の候補を出し、試作プログラムを作ることができます。人間が考えた設計を検討し、実装し、検証する速度を大きく上げられます。

    一方で、「どの顧客に、どの価値を提供する会社になるのか」「利益と品質のどちらを、どの場面で優先するのか」「事故が起きたとき、誰が責任を持って止めるのか」といった判断は、会社の経営そのものです。AIや外部の開発会社へ丸ごと委ねることはできません。

    外部の専門家やAIは、設計を支援できます。しかし、自社の将来像を決めるのは経営者であり、実際の業務を説明できるのは社内の人です。DXを進めるには、この二者が設計の中心にいなければなりません。

    小さく始めるなら、一つの経営課題から逆算する

    全社の業務を一度に作り直す必要はありません。まずは、経営上の困りごとを一つ選びます。たとえば「案件ごとの利益が月末まで分からない」「担当者が休むと見積もりが止まる」「請求漏れを人の確認で防いでいる」といった課題です。

    次に、その数字や仕事がどの業務で生まれ、誰が記録し、誰が確認し、どの判断を経て次へ進むのかをたどります。そして、重複している情報、意味が揃っていない言葉、人に依存している判断を整理します。

    そのうえで、AIに任せる作業、人が判断する作業、必要なデータ、権限、画面、システムを決めます。この順番なら、AIは目的不明の流行商品ではなく、会社を望む方向へ動かすための手段になります。

    生成AI時代のDXは、設計から始まる

    生成AIの導入は、DXのゴールではありません。業務時間が短くなったことも大切な成果ですが、それだけで会社の競争力や意思決定の仕組みが変わるとは限りません。

    最初に考えるべきことは、「AIで何ができるか」ではなく、「自社をどのような会社に変えたいのか」「そのために、どの業務をどのように変えるのか」です。

    その設計図があって初めて、生成AIは会社を変える力になります。AIだけではDXは進みません。しかし、経営と業務の設計にAIを組み合わせれば、これまで費用や人材の壁で実現できなかった変革を、自社で進められる可能性が生まれます。


    次回予告

    次回は、「生成AI時代になって、古くからあるシステム設計技術が再び注目される理由」を取り上げます。

    AI時代に必要なのは、まったく新しい考え方だけではありません。ユーザー、グループ、権限、実行範囲など、UNIX時代から積み重ねられてきたマルチユーザー設計が、なぜ今あらためて重要になるのかを解説します。

  • (8月20日通信)「動くから安心」は大間違い。あなたのシステムは“二人乗りの原付き”で高速道路を走っていないか?

    【DXの罠】入門教材で作れたシステムを、そのまま会社で使ってはいけない

    「Webアプリの作り方を一通り勉強した」

    「生成AIに聞きながらCRUDもログインも実装できた」

    「実際にブラウザから動いている」

    ここまで来ると、

    「これなら自社の業務システムも作れるのではないか」

    と思いたくなります。

    しかし、ここに生成AI時代の大きな落とし穴があります。

    入門教材で作るシステムと、企業が本番運用する業務システムは、そもそも設計目的が違います。

    入門教材の目的は、

    フレームワークの仕組みを理解すること

    です。

    企業の業務システムの目的は、

    異なる立場・権限・所属を持つ多数の人間が、重要な企業データを安全に扱い続けること

    です。

    この二つを同じ設計で作ってはいけません。


    1.実際の「入門教材」を7つ見てみよう

    ここで、実際に公開されているフレームワーク学習教材を見てみます。

    重要なのは、これらの教材を批判することではありません。

    むしろ、どれも入門教材としては非常によくできています。

    問題は、

    「教材で完成したサンプルアプリの構造=業務システムの正しい構造」

    だと思い込むことです。


    ① MDN ― Express「地域図書館」チュートリアル

    MozillaのMDNには、Node.js+Expressを使って「地域図書館」のWebサイトを作る非常に分かりやすいチュートリアルがあります。

    MDN:Express チュートリアル「地域図書館のウェブサイト」

    内容は、

    • Expressアプリケーションの作成
    • データベース
    • ルーティング
    • ビュー
    • フォーム
    • デプロイ

    などです。

    MDN自身が、このシリーズを終えると**「簡単なExpressアプリケーションを自分で開発するのに十分な知識」**が身につくと説明しています。

    さらに興味深いことに、Express学習モジュールのページでは、今後追加できるテーマとして、

    • セッション
    • ユーザー認証
    • ユーザーの認可と権限
    • Webセキュリティ

    などが別途挙げられています。

    つまり教材自身が、

    「まず簡単なWebアプリを作る」

    ところに学習範囲を絞っているわけです。

    それは入門教材として正しい判断です。

    しかし、その構造をそのまま社員数百人の業務システムへ持っていくのは別問題です。


    ② paiza ― Flask入門

    Pythonの軽量WebフレームワークFlaskにも、非常に分かりやすい日本語入門教材があります。

    paizaラーニング:Webアプリ開発入門 Flask編

    最初のFlask入門では、

    • Webアプリの初歩
    • Hello World
    • ルーティング
    • テンプレート
    • 共通部分の分割
    • ユーザー操作による表示変更

    などを順番に学びます。

    これはまさに、

    「Webフレームワークとは何なのか」

    を体験するための教材です。

    ここで重要なのは、

    この教材で習った作り方が間違っているわけではない

    ことです。

    ただし、

    「本社」

    「支店」

    「店舗」

    「部長」

    「一般社員」

    「取引先」

    「顧客」

    という複雑な関係を持つ業務システムは、最初から別の設計問題として考える必要があります。


    ③ FastAPI ― 公式チュートリアル

    FastAPIには、日本語化された非常に充実した公式チュートリアルがあります。

    FastAPI公式:チュートリアル・ユーザーガイド

    最初は非常にシンプルです。

    FastAPI()を作り、

    パスを定義し、

    リクエストを受け、

    JSONを返す。

    そこから、

    • パスパラメータ
    • クエリパラメータ
    • リクエストボディ
    • バリデーション
    • レスポンスモデル
    • エラー処理

    などを段階的に学びます。

    もちろんFastAPIにはSecurity Toolsもあり、認証・認可を実装できます。

    つまり、

    FastAPIが業務システムに使えないという話ではありません。

    むしろ逆です。

    自由度が高いからこそ、

    「会社・組織・ユーザー・権限・データ境界をどうモデル化するか」

    は、フレームワークの入門教材とは別に設計者が考えなければならないのです。


    ④ Next.js ― App Router入門

    現在のNext.jsにはApp Routerを中心とした学習導線があります。

    日本語で基本構造を確認できるドキュメントはこちらです。

    Next.js 16 日本語ドキュメント:App Router

    ここでは、

    • インストール
    • プロジェクト構造
    • レイアウト
    • ページ
    • ナビゲーション
    • Server Components
    • Client Components

    などを順番に学習できます。

    公式のNext.js Learnには、さらに興味深い題材があります。

    請求書を登録・編集・削除できるダッシュボード

    を作ります。

    ログインページもあり、認証で保護されたページもあります。

    これは非常に良い教材です。

    しかし、ここで経営者が注意すべきなのは、

    「ログイン+請求書CRUDができた」ことと、「企業の会計・販売管理システムとして設計できた」ことは同じではない

    という点です。

    本番の企業では、

    営業担当者はどこまで見えるのか。

    営業部長は何を承認できるのか。

    経理担当者はどこまで変更できるのか。

    支店Aから支店Bの請求情報が見えてよいのか。

    退職者の権限をどこで停止するのか。

    といった、教材とは別の問題が大量に発生します。


    ⑤ paiza ― Laravel入門

    Laravelの入門教材も非常に分かりやすい例です。

    paizaラーニング:Webアプリ開発入門 Laravel編

    ここでは、

    • ルーティング
    • MVC
    • Blade
    • フォーム
    • Eloquent ORM
    • CRUD
    • ログイン
    • アクセス制御

    まで順番に学ぶことができます。

    しかもpaiza自身が、この講座について、

    理解しやすくするため基本的な内容に留め、サンプルや演習課題も小規模にしている

    と説明しています。

    ここは非常に重要です。

    教材が悪いのではありません。

    教材側が「小規模な学習用です」と明示しているのです。

    実際、後半ではログイン・ログアウト・サインアップを追加し、

    自分の投稿だけ編集できるようにする

    ところまで学習します。

    これは認可を学ぶ最初の教材として優れています。

    しかし企業システムでは、

    「自分か他人か」

    だけでは済みません。

    会社、部署、役職、プロジェクト、店舗、担当顧客、承認経路などによって権限が変化します。


    ⑥ Railsチュートリアル ― Railsの教科書

    Ruby on Railsにも、日本語で非常に分かりやすい初心者向け教材があります。

    Railsチュートリアル:Railsの教科書

    教材自身が目的を非常に明確に説明しています。

    題材は、

    写真や文章を投稿できるミニブログアプリ

    です。

    そして、

    「できるだけ簡単なサンプルアプリ」

    を使ってRailsとWebアプリの基礎を説明するとされています。

    内容も、

    • 小さなRailsアプリ
    • CRUD
    • モデル
    • Gem
    • 画像アップロード

    という、非常に分かりやすい構成です。

    これを読んでRailsを学ぶのは正しい。

    しかし、

    ミニブログの設計を、そのまま会社の販売・購買・会計・人事システムへ拡大するのは正しくありません。


    ⑦ Spring Boot ― 入門ガイド

    最後は、企業システムでも広く利用されるSpring Bootです。

    日本語で読めるSpringの入門ガイドがあります。

    Spring:Spring Boot アプリケーションの構築

    このガイド自身が、

    Spring Bootを簡単に体験するためのもの

    と説明しており、約15分で簡単なWebアプリケーションを構築します。

    別のSpring MVC入門でも、

    Webコントローラーを作り、ブラウザにページを表示させるところまでを段階的に学習します。

    もちろんSpringには、その先に非常に強力なSecurityや企業向けの仕組みがあります。

    しかし、

    「15分でSpring Bootアプリが動いた」

    ことと、

    「企業の権限体系を設計できる」

    ことは当然ながら別です。


    2.7つを並べると、共通点が見えてくる

    技術は全部違います。

    JavaScript。

    Python。

    PHP。

    Ruby。

    Java。

    しかし、入門教材には共通した構造があります。

    まず、

    画面を出す。

    次に、

    URLと処理を結びつける。

    そして、

    データベースへ保存する。

    CRUDを作る。

    さらに進んだ教材では、

    ログインを付ける。

    ここまで来ると、非常に「システムらしく」見えます。

    だから危険なのです。


    3.入門教材は「どう動かすか」を教える。業務設計は「誰に何を許すか」から始まる

    初心者向け教材では、

    「このボタンを押したらこの関数を呼ぶ」

    「このURLならこのControllerを動かす」

    「このフォームの値をデータベースへ保存する」

    という順番で学ぶことが多くなります。

    当然です。

    動かなければ学習にならないからです。

    しかし企業の業務システムでは、実装より前に、

    誰が使うのか

    を考えなければなりません。

    例えば、

    • 経営者
    • 本部管理者
    • 部長
    • 店長
    • 一般社員
    • 経理担当者
    • 外部税理士
    • フランチャイズ加盟店
    • 取引先
    • 顧客

    が同じシステムへアクセスするとします。

    ここで最初に考えるべきなのは、

    「画面をどう作るか」ではありません。

    まず、

    誰が、何を、どこまでできるのか

    です。


    4.「ログインを付けた」だけではマルチユーザー設計ではない

    これは特に経営者に知っておいてほしい点です。

    ログインとは基本的に、

    「あなたは誰ですか?」

    を確認する仕組みです。

    しかし企業が必要としているのは、その次です。

    「あなたは何をしてよいですか?」

    さらに、

    「どの会社・部署・店舗・顧客のデータを扱ってよいですか?」

    まで決める必要があります。

    したがって企業システムでは、

    認証

    認可

    組織境界

    レコード境界

    業務上の承認関係

    まで設計する必要があります。

    ログイン画面は、その入口にすぎません。


    5.生成AIが、この勘違いをさらに危険にした

    以前なら、初心者が入門教材から大規模なシステムを作ろうとしても、途中でプログラムが動かなくなりました。

    そこで、

    「何か設計がおかしい」

    と気づく機会がありました。

    ところが生成AIは違います。

    「この人だけ編集可能にして」

    と言えばif文を書いてくれます。

    「部長も編集可能にして」

    と言えば、さらに条件を追加します。

    「管理者も」

    「この店舗だけ例外」

    「このユーザーだけ特別」

    と要求すると、

    AIはかなりのところまで動くコードを作ってしまいます。

    結果、

    一つの業務ルールが、

    画面Aのif。

    画面Bのif。

    APIのif。

    バッチ処理のif。

    帳票処理のif。

    と分散していく。

    それでも当面は動きます。

    ここがAI時代の怖さです。


    6.入門教材のコードを捨てる必要はない。「設計図」にしてはいけない

    ここで誤解してほしくありません。

    入門教材のコードを使うな、という話ではありません。

    ルーティングの書き方。

    ORMの使い方。

    フォーム処理。

    テンプレート。

    API。

    バリデーション。

    これらはそのまま役立ちます。

    しかし、

    入門教材から学ぶべきなのは「部品の使い方」であって、「会社全体の設計図」ではありません。

    ここを間違えると、

    小さなTODOアプリを少しずつ継ぎ足して、

    最後には基幹システムにしてしまうようなことが起きます。

    それは、

    二人乗りの原付きに荷台を足し、座席を足し、タイヤを太くし、最後には大型バスとして高速道路を走らせようとするようなものです。

    途中からどれだけ部品を追加しても、

    最初から多人数を乗せることを考えて作られた車両とは設計思想が違います。


    7.経営者がSEに聞くべき質問は一つ

    プログラムを読めなくても構いません。

    担当者に、こう聞いてみてください。

    「このシステムでは、誰が・どの組織に所属し・どのデータに・どんな操作をしてよいかを、どこで定義していますか?」

    この質問に、

    「この画面ではif文で……」

    「このControllerでは……」

    「ここだけ例外で……」

    という説明が延々と続くのであれば注意が必要です。

    逆に、

    User。

    Group。

    Role。

    Permission。

    Policy。

    Organization。

    Tenant。

    ACL。

    名称は何でも構いません。

    会社の権限体系と業務体系が、

    一つの構造として説明できる

    のであれば、少なくとも設計について考えられています。


    結論――入門教材は正しい。だからこそ、その先が必要になる

    今回紹介した7つの教材は、どれも悪い教材ではありません。

    むしろ、

    初心者にWebフレームワークを理解させるために、意図的に問題を小さくしている教材

    です。

    だからこそ重要なのです。

    入門教材を最後まで終えたとき、

    「業務システムが作れるようになった」

    と考えるのではなく、

    「業務システムを作るための道具を、一通り触れるようになった」

    と考える。

    ここには大きな違いがあります。

    生成AIによって、この「道具を使う能力」は急速にコモディティ化しています。

    その一方で、

    誰が使うのか。

    何を許すのか。

    何を分離するのか。

    どこを共通化するのか。

    変更されたとき、どこまで影響するのか。

    という設計の重要性はむしろ高くなっています。

    入門教材を否定する必要はありません。

    ただ一つ、

    入門教材で作ったサンプルアプリを、そのまま会社の業務システムの設計図にしてはいけない。

    これだけは、生成AI時代のDXにおいて経営者が知っておくべきことではないでしょうか。