生成AI導入の「二歩進んで一歩下がる」現象を打破する方法
- Seo Seungchul
- 3 日前
- 読了時間: 8分
シリーズ: 知新察来
◆今回のピックアップ記事： Burt Jacobsen et al. "Overcoming two issues that are sinking gen AI programs" （McKinsey & Company, 2025年6月6日）
多くの企業が生成AIの導入に取り組んでいますが、順調に見えた計画が途中で頓挫したり、期待した成果が得られなかったりするケースが頻発しています。マッキンゼーが2年間にわたって150社以上の生成AIプログラムを支援した結果見えてきたのは、二つの致命的な課題でした。
一つは「イノベーションの失敗」。コンプライアンス対応や重複する作業に追われ、本来の価値創造に集中できない状況です。もう一つは「スケールの失敗」。試作品から本格運用への移行で、セキュリティやコストの懸念に阻まれてしまうという問題です。
これらの課題を乗り越えるカギは、「プラットフォーム思考」にありそうです。スピードと安全性を両立させる統合的なアプローチとは、どのようなものなのでしょうか。
なぜ多くの生成AIプロジェクトが挫折するのか
富良野：この記事を読んでいて思ったんですが、生成AIって本当に「二歩進んで一歩下がる」という感じですよね。僕もいくつかの企業でコンサルティングをしていて、最初は期待値が高いのに、だんだんトーンダウンしていく現場をよく見ます。
Phrona：そうですね。特に興味深いのは、技術的な問題というより、組織の構造的な問題が大きく影響しているという点です。記事では、開発チームが本来の「イノベーション時間」の30〜50%をコンプライアンス対応に費やしているとありますが、これって相当なロスですよね。
富良野：ああ、それは深刻だ。つまり、エンジニアが半分近くの時間を、本来やりたい問題解決ではなく、社内の承認プロセスや規制対応に使っているということでしょう？それじゃあモチベーションも下がるし、競争力も失われてしまう。
Phrona：しかも、その承認を出すコンプライアンス部門も手一杯で、結果的に待ち時間がどんどん長くなる。悪循環ですよね。私が気になったのは、この問題が個別のアプリケーションレベルではなく、プログラム全体を止めてしまうケースがあるということです。
富良野：なるほど。一つの失敗が組織全体の生成AI取り組みにブレーキをかけてしまう。経営陣がリスクを過大評価して、プログラム自体をシャットダウンしてしまうと。
Phrona：そこが興味深いところで、記事では「スピードか安全性か」という二者択一の発想自体が間違いだと指摘していますね。両方を実現する方法があるという視点が新鮮でした。
プラットフォーム思考という解決策
富良野：その解決策として提示されているのが「プラットフォーム」の考え方ですが、これは従来のIT基盤とは少し違うアプローチですよね。単なるインフラではなく、検証済みのサービスや資産を統合した仕組みという感じでしょうか。
Phrona：そうですね。三つの核となる要素が面白いと思います。セルフサービスポータル、オープンアーキテクチャ、そして自動化されたガードレール。それぞれが有機的に連携して、開発者が安心して素早く作業できる環境を作っているというか。
富良野：セルフサービスポータルの発想は、いわば「民主化」ですよね。何百ものチームが簡単に、かつ安全に生成AIツールにアクセスできる。でも、野放しではなく、あらかじめ承認済みの機能だけを使えるようにしている。
Phrona：ポイントは「数分で」開発を始められるという部分だと思います。従来なら週単位、月単位でかかっていた環境構築が、劇的に短縮される。記事では、ある石油ガス会社で6週間かかっていた作業が1日以下になったという例も紹介されていますね。
富良野：それは確かにゲームチェンジャーだ。でも、スピードアップと同時に品質や安全性も担保しなければならない。そこで重要になるのが、二番目の要素である「オープンアーキテクチャ」なんでしょうね。
Phrona：「再利用の最大化」というキーワードが印象的でした。車輪の再発明を避けて、共通のライブラリやサービスを活用する。でも興味深いのは、単一のプロバイダーに依存するのではなく、ベスト・イン・クラスの機能を組み合わせるアプローチを推奨している点です。
富良野：それは賢明だと思います。技術の進歩が早い分野では、特定のベンダーに縛られるリスクが高い。むしろ、いろいろなサービスを柔軟に組み合わせられる仕組みの方が、長期的には強い。
自動化されたガードレールの仕組み
Phrona：三番目の「自動化されたガードレール」が一番技術的に興味深い部分かもしれません。AIゲートウェイという概念で、すべてのLLMへのアクセスを管理している。
富良野：これは一種の「関所」みたいなものですね。すべてのリクエストがここを通ることで、アクセス制御やコスト管理、そして問題のあるプロンプトや回答の検出ができる。個人情報の漏洩防止やハルシネーション（幻覚）の検出も自動で行う。
Phrona：面白いのは、柔軟性も同時に保っているという点です。例えば、HR部門のツールが機能するために個人情報へのアクセスが必要な場合は、そのツールだけ一時的にフィルターを無効にできる。一律の制限ではなく、文脈に応じた調整が可能になっている。
富良野：それは現実的な設計だと思います。セキュリティを重視しすぎて使い勝手が悪くなったら、結局回避策を探すようになってしまう。むしろ、透明性のある形で例外処理ができる方が、全体的なガバナンスは効いてくる。
Phrona：記事では承認プロセスが90%短縮されるという数字も出ていましたね。レビューチームが、個別のアプリケーションではなく、共通のサービスを検証すればいいから、効率が大幅に向上するという理屈です。
富良野：それは組織論的にも重要な変化ですね。従来は個別案件ごとにゼロベースで審査していたのが、プラットフォームレベルで一度検証してしまえば、その上で動くアプリケーションは信頼できるという前提で進められる。
プラットフォーム思考がもたらす組織変化
Phrona：この仕組みを見ていると、単なる技術的な解決策を超えて、組織の働き方自体を変える可能性を感じます。開発者が本来の創造的な作業に集中できるようになる一方で、リスク管理やコンプライアンスの品質も向上する。
富良野：そうですね。よくある「トレードオフ」の発想から脱却している。スピードを重視すれば安全性が犠牲になり、安全性を重視すればスピードが落ちるという従来の図式ではなく、両方を同時に実現する仕組みを構築している。
Phrona：ただ、記事でも「discipline and time」が必要だと正直に書かれています。このプラットフォームを構築するには、相当な規律と時間が必要だと。でも、数個のソリューションを展開した段階で投資回収ができるとも言っています。
富良野：初期投資の回収が早いというのは魅力的ですが、それ以上に重要なのは、組織全体の学習能力や適応力が向上することかもしれません。一度このプラットフォームができれば、新しい技術やサービスを取り込むことも容易になる。
Phrona：そうすると、生成AIだけでなく、今後登場する新しい技術にも同じアプローチが応用できそうですね。技術の変化に振り回されるのではなく、変化を前提とした組織の仕組みを作るという発想です。
富良野：まさにそうです。個別の技術への対応策ではなく、技術変化に対する組織の「体質改善」と言えるかもしれません。長期的には、これが競争優位の源泉になるのでしょうね。
ポイント整理
生成AIプログラムの二大課題
多くの企業が「イノベーションの失敗」（開発時間の30-50%がコンプライアンス対応に消費）と「スケールの失敗」（試作から本格運用への移行で挫折）に直面している
プラットフォーム思考による解決
スピードと安全性の二者択一ではなく、統合的なプラットフォームによって両方を実現する新しいアプローチ
三つの核となる要素
セルフサービスポータル（開発者の自律的アクセス）、オープンアーキテクチャ（再利用可能なサービス構成）、自動化ガードレール（リアルタイムリスク管理）が有機的に連携
劇的な効率化事例
環境構築時間を6週間から1日未満に短縮、承認プロセスを90%削減などの具体的成果
組織変化の本質
個別技術への場当たり的対応から、技術変化を前提とした組織の構造的変革への転換
キーワード解説
【生成AI（Generative AI）】
テキスト、画像、音声などのコンテンツを自動生成する人工知能技術
【LLM（Large Language Model）】
大規模言語モデル。膨大なテキストデータで訓練された自然言語処理AI
【ハルシネーション】
AIが事実ではない情報を生成してしまう現象
【RAG（Retrieval-Augmented Generation）】
外部情報を参照して回答の精度を向上させる生成AI手法
【AIゲートウェイ】
AIサービスへのアクセスを一元管理し、セキュリティとガバナンスを担保するシステム
【インフラストラクチャー・アズ・コード】
インフラ構成をコードとして管理し、自動化と標準化を実現する手法
【オープンアーキテクチャ】
異なるサービスや技術を柔軟に組み合わせられるシステム設計思想