ビジネススクールで受講した「テクノベート・シンキング」の学びを全12回でまとめるシリーズ、その10。
前回はノーコード×AI APIで実際にアプリを作った話を書いた。今回は第5回後半の課題──「自分のビジネス領域でAIがどう使われ、今後何が期待され、何が脅威になるか」を考察した記録。手を動かしてAIアプリを作った直後だからこそ、地に足のついた分析ができたと思う。
現状：生成AIは「使い始めた」段階で止まっている
2025年時点で、IT業界では生成AIが急速に普及しつつある。Microsoft Copilot、ChatGPT、各種OpenAIベースのツール──文書作成、メールの返信、議事録の要約といった知的労働の補助には、すでに多くの人が使い始めている。
しかし、「使い始めている」と「本格活用している」の間には大きな溝がある。
業務データをAIに入力することへのセキュリティ上の制限。社内システムと外部ツール間のコピペ制約。個人情報保護の観点からの利用制限。「使いたいけど使えない」「使えるけど制限付き」という状況が、多くの企業のリアルだ。
FAQ自動応答や営業資料のドラフト生成など、部分的に使われている事例はある。しかし、PoC（概念実証）止まりで本番運用に至っていないケースも多い。「AIを導入しました」とプレスリリースは出すが、現場レベルで本当に使いこなしているかと言えば、まだまだこれからだ。
期待される4つの領域
今後AIが本格的に業務に組み込まれていく領域として、私は4つを挙げた。IT畑で長年やってきた実感に基づく予測だ。
① AIOps──IT運用の自動化と高度化
ログ監視、障害の予兆検知、自動復旧──いわゆるAIOps（AI for IT Operations）の領域だ。膨大なログデータからパターンを学習し、人間の限界を超えた速度で異常を検知する。
具体的なシナリオを考えてみる。深夜3時にサーバーのレスポンスタイムが通常の1.5倍に悪化した。人間のオペレーターならアラートに気づいてから原因を調査し始めるまでに数分かかる。しかしAIOpsなら、レスポンスタイムの微妙な上昇トレンドを障害発生前に検知し、過去の類似パターンから原因を推定し、自動でスケールアウトやフェイルオーバーを実行する──ここまでを秒単位で行える可能性がある。
IT運用に直結する領域だけに、ここは個人的にも一番リアルに想像できる。24時間365日の監視体制を、AIが質的に変えていく未来は確実に来ると思う。
② 開発プロセスへのAI導入
コード生成、バグ修正、テスト自動化。GitHub Copilotに代表されるAIコーディング支援は、すでに多くの開発者が日常的に使っている。しかし今後はもっと上流──設計書の自動生成、テストケースの網羅性チェック、セキュリティ脆弱性の自動検出──にまでAIが入り込んでくるだろう。
さらに注目すべきはAPIエコノミーの拡大だ。前回の「My AI Coach」アプリで体験したように、AppSheet、Zapier、OpenAI APIという既存のサービスを「つなぎ合わせて」新しいアプリケーションを作るスタイルが、プロの開発現場でもますます一般化していく。コードをゼロから書く時代から、APIを組み合わせて価値を生む時代への転換だ。
これは開発者の役割を根本的に変える。「コードが書ける」だけでは足りなくなり、「どのAPIをどう組み合わせれば最も効率的に価値を生めるか」というアーキテクチャ設計力が問われるようになる。
③ 事務業務のエージェント化
スケジュール調整、契約書レビュー、経費処理──こうした定型的な判断業務をAIエージェントが代行するようになる。
たとえば経費精算。現状は「領収書を撮影 → 項目を手入力 → 上長が承認 → 経理が確認」という人手のリレーだ。しかしAIエージェントなら、領収書の画像からOCRで自動読取 → 過去の精算パターンと照合して勘定科目を自動分類 → 規定違反がないかルールベースでチェック → 問題なければ自動承認──ここまでを一気通貫で処理できる可能性がある。
契約書レビューも同様だ。何十ページもある契約書の中から、自社に不利な条項、過去の契約と異なる変更点、法的リスクのある表現をAIが瞬時に抽出してハイライトする。弁護士の目視チェックは最終確認だけで済むようになる。
「定型判断業務」の多くが、人から機械に置き換わる未来はそう遠くない。むしろ、置き換わらないことの方が非効率だという認識が広まるのは時間の問題だ。
④ リコメンドとパーソナライゼーションの汎用化
第3回〜第4回で学んだリコメンドの考え方は、ECサイトや音楽配信に限らず、あらゆるビジネスで「ユーザーごとに最適な提案を出す」仕組みとして一般化していくだろう。
たとえば社内の人材配置。プロジェクトに必要なスキルセットと、社員の過去の実績・評価データ・本人の希望をAIがマッチングし、最適なアサイン候補を提示する。あるいは研修プログラムのパーソナライズ。同じ役職でも、スキルギャップは一人ひとり違う。AIが個人の弱点を分析し、その人に最適な学習コンテンツを推薦する。
前回作った「My AI Coach」もまさにパーソナライゼーションの一例だ。汎用のフィットネスアプリではなく、私の体組成データ、私の目標、私の食の好みに最適化されたアドバイスを出す。この「個別最適」の考え方がビジネスのあらゆる領域に広がっていく。
脅威：IT業界の構造を揺るがす3つの問題
ここまでは「期待」の話だ。しかし、この課題で私が時間をかけたのは、むしろ「脅威」の方だった。期待を語るのは簡単だ。誰でもできる。しかしIT畑にいるからこそ、見えてしまう脅威がある。そこから目を逸らしたくなかった。
脅威①：「人売り・人出し」型ビジネスモデルの崩壊
IT業界には「人売り」「人出し」と呼ばれるビジネスモデルが根強く存在する。エンジニアやオペレーターの稼働時間を売り、その工数に対して対価をもらうモデルだ。月間160時間の稼働 × 単価 = 売上。シンプルで分かりやすく、長年にわたってIT業界の収益構造を支えてきた。
このモデルが成り立つのは、「人がやらなければできない作業」が存在するからだ。しかし、AIエージェントが実用レベルに達したとき、何が起きるか。
資料作成──AIが下書きを作り、人間は最終チェックだけ。要約──会議の録音をAIが自動で要約。翻訳──多言語対応はAIの得意領域。テスト実行──テストケースの生成から実行、結果レポートまでAIが担当。こうした作業に3人月かかっていたものが、AIの月額サブスクリプション数万円で済む世界が来たとき、「人月で売る」ビジネスは根底から揺らぐ。
では何が代わりの収益源になるのか。私は「仕組みの設計力」と「業務理解の深さ」だと考えている。AIが作業をこなせるようになっても、「何をAIにやらせるか」「どういう仕組みでビジネスを回すか」を設計できる人材は、むしろ価値が上がる。前回のAI Coachアプリ開発で実感したのは、ツールを使うこと自体は簡単だが、「どのツールをどうつなげば自分の問題が解決するか」を設計することの方がはるかに難しいということだ。
脅威②：AIによる標準化がもたらす差別化の消失
AIツールは誰でも使える。CopilotもChatGPTも、契約すれば明日から使える。つまり、AIを使って業務効率化すること自体は、もはや差別化にならない。
たとえば、ある企業がAIを使ってシステム障害の対応速度を50%改善したとする。素晴らしい成果だ。しかし競合も同じAIツールを導入すれば、同じ改善が実現できる。AIは「使えること」ではなく「何に使うか」で差がつくのだが、多くの企業はまだ「使えること」を競争優位だと勘違いしている。
真の差別化は、顧客の業務を深く理解した上での構想力と設計力にある。「このお客様の業務フローにはどこにボトルネックがあるか」「そのボトルネックをAIでどう解消すれば、お客様のビジネスにどれだけのインパクトがあるか」──この問いに答えられるのは、技術だけでなくビジネスを理解している人間だけだ。
テクノロジーとビジネスの両方が分かる人材──まさにテクノベート人材が求められる所以がここにある。
脅威③：「工夫してデータを取る」力がない組織は置いていかれる
第3回〜第4回で学んだように、リコメンドもAIも、データがなければ何も始まらない。しかし、ただデータを集めるだけでは足りない。
前回のAI Coachアプリ開発で痛感したのは、「どんなデータを、どういう形式で、どのタイミングで取得するか」の設計が、アプリの品質を決定的に左右するということだ。体組成データを「体重」「体脂肪率」「筋肉量」と個別のカラムに分けて構造化したからこそ、AIは具体的な数値を引用したアドバイスを返せた。もしこれが「体組成データ：良好」のような定性的な記録だったら、AIは何もできない。
ビジネスの現場でも同じことが起きている。顧客対応の記録が自由記述のテキストだけで、対応時間・対応種別・顧客満足度がデータとして取得されていなければ、いくらAIを導入しても分析のしようがない。「データを取る仕組み」の設計ができない組織は、AI時代に取り残される。
具体的に言えば、こういうことだ。営業日報を「今日も頑張りました」ではなく、「訪問件数：3件、提案件数：1件、成約確度：B」という構造化されたデータとして記録する仕組みを作る。カスタマーサポートの問い合わせを「その他」で片付けず、カテゴリ分類のルールを設計して記録する。こうした地味だが本質的なデータ設計を、AIの導入よりも先にやるべきだ。
見逃せないリスク：倫理・ハルシネーション・責任の所在
3つの脅威に加えて、AI活用には避けて通れないリスクもある。
プライバシーと倫理の問題。AIに業務データを投入する際、顧客の個人情報がモデルの学習データに使われないか。取引先の機密情報が漏洩するリスクはないか。法的な整備が追いついていない中、企業は自分たちでガードレールを設計しなければならない。
ハルシネーション（幻覚）のリスク。前回のAI Coach開発中にも、AIが存在しないメニュー項目を自信満々に提示してきた。これがビジネスの意思決定に使われたら、取り返しのつかない判断ミスにつながりかねない。AIの出力を鵜呑みにしない体制、検証できる人材の確保が不可欠だ。
そして責任の所在。AIが作った資料にミスがあった場合、責任は誰が取るのか。AIが提案した施策が失敗した場合、説明責任は誰にあるのか。「AIがやったことだから」は言い訳にならない。最終的な判断と責任は人間が負う──この原則を組織として明確にしておく必要がある。
リーダーの仕事は「脅威を語る」こと
この課題を通じて一番強く感じたのは、期待を語るのは簡単だが、脅威を具体的に語ることの方がはるかに価値があるということだ。
「AIで業務効率が上がります」は誰でも言える。プレゼン資料にAIのキラキラした可能性を並べることは、ChatGPTに聞けば5分でできる。
でも「人売りビジネスが成り立たなくなる」「AIによる標準化で既存の差別化ポイントが無効化される」「データ取得の設計ができない組織は3年後に詰む」──こうした自分ごととしての脅威を言語化できるのは、その業界の現場にいる人間だけだ。
しかも、脅威を語るにはある種の覚悟がいる。自分たちのビジネスモデルが危ういと認めることは、居心地が悪い。でも目を逸らしていたら手遅れになる。不都合な真実を直視し、それを組織に伝え、対策を考える──これこそがリーダーの仕事だと思う。
手を動かしたからこそ見えた景色
前回のAI Coachアプリ開発と、今回のAI脅威分析は、表裏一体の学びだった。
手を動かしてAIアプリを作ったからこそ、AIの「できること」と「できないこと」の境界線が実感として分かる。無料ツールの制約と格闘したからこそ、「AIが万能だ」という幻想に惑わされない。プロンプト設計に苦労したからこそ、「AIを導入すれば全部うまくいく」という楽観論の危うさが分かる。
テクノベート・シンキングの本質は、テクノロジーの可能性を理解しつつ、それが自分のビジネスにどういう構造変化をもたらすかを冷静に分析し、打ち手を考えることにある。期待だけでなく脅威を。可能性だけでなく制約を。その両面を見ることで初めて、地に足のついた戦略が立てられる。
ビジネスリーダーの仕事は、技術の可能性を語ることだけではない。技術がもたらす構造変化を直視し、組織としてどう備えるかを考えること。テクノベート・シンキングの終盤に向けて、この視座が育ってきた実感がある。
次回：最終課題──自分のビジネスの問題をツールで解決する
第6回は最終セッション。「テクノベート・シンキングの問題解決プロセスに則って、フリーツールを活用し、自分のビジネスの問題を解決する施策を立案・実装する」という総仕上げの課題だ。期待と脅威を分析した上で、では具体的に何をするのか。次回はその話を書く。
今回参考にした書籍
