AI人材の罠
アプリのモダナイゼーションにおいて、ビジネスコンテキストがコーディングに勝る理由
Cレベルのエグゼクティブは常にパラドックスに直面しています。世界中で数千万人が利用する高トラフィックインフラストラクチャの安定性を確保しつつ、優位性の維持に必要な猛スピードのイノベーションを続けるという、一見矛盾する目標の両立を求められるのです。これは、私が10年以上にわたって取り組んできた課題です。AI搭載アプリの登場で、この両立の難度は上がる一方です。私はCaliente.mxで複数の製品やプラットフォームに携わり、その葛藤を直接経験してきました。その経験から、大規模展開にあたり何が効果的で、何が壊滅的失敗を引き起こすのかについて、率直な見解を持つに至りました。
2026年Cloudflareアプリイノベーションレポートを読んで、87%の組織が「AI開発をサポートするのに十分な内部スタッフがいる」と回答しているのにまず目が留まりました。そうした自信を誤解する人がいるかもしれません。私の経験では、AI導入の成功は、チームの働き方と彼らが持つ組織知、そしてインフラが迅速で安全な実験をサポートできるかどうかにかかっています。これは「Beyond the App Stack」の番組でも扱われたテーマで、CloudflareのフィールドCTOであるTrey Guinnと、AI能力は単に人員数の問題ではないことを論じています。
ここ数年、AIを導入しようとする企業に共通するパターンが見られます。テクノロジーは素晴らしく、人材も書類上は盤石に見えるのに、結果が出せないのです。それは、AI導入成功の真の障壁は技術でなく戦略だからです。あまりにも多くの企業が、AIを導入するか遅れをとるかのバイナリ思考に陥っています。この考え方がもたらすプレッシャーから、自社のビジネスを知らないAI専門家を雇うか、導入の目的や計 画を明確化しないままツールを社内展開するかのいずれかの対応をとりがちです。どちらのアプローチも、成果は長続きしません。
企業のAIへのアプローチは大きく分けて2通りあります。提供する製品に組み込む基盤製品として導入する方法と、人事や財務などの内部ワークフローを最適化するツールセットとして導入する方法です。製品ファーストのアプローチの方が複雑と思われるかもしれませんが、私はAIを内部に導入する方がリスクが高いと考えています。トレーニングもなくツールを与えられて使えと言われるものの、期待値のズレがあり、各チームの反発が始まります。その結果、導入が停滞するのです。
核となる二項対立：「知識」対「新スキル」
AIの持続的活用を考えるなら、リーダーは導入方法を再検討する必要があります。そして、さらに重要なのが、その変化を牽引する能力を持つのが実は誰なのかをしっかりと見極めることです。
私がCalienteでしてきたように、ゼロからチームを作り上げると、組織知の価値がよくわかります。文書化された知識ではなく、社員が克服するトレードオフや形づくってきたシステム、経験を通して培った直感といった形で活きている知識です。
そうしたコンテキストが、AIの統合では極めて重要です。外部からの採用で専 門知識は得られるかもしれませんが、製品の歴史やアーキテクチャに関する知識がなければ、進捗は遅くなります。
多くの場合、既存チームのスキルアップが結局は早道です。アプリがどのように進化してきたか、ユーザーが何に依存しているか、スタックの柔軟性がどこにあるかを理解している人材だからです。アーキテクチャがモジュール型で低リスクの実験をサポートするものなら、そのコンテキストが競争上の優位性となり、スキルアップが当然の選択となります。
AIへの抵抗を管理
新しいツールの導入、特にAIのように前評判の高いツールの導入時は、社員が「AIに取って代わられるのでは？」と不安になるのも当然です。AIが独立したイニシアチブとして位置づけられたり、日々の業務に関わらない外部人材に任されている場合は、さらに恐怖が膨らみます。その恐怖を和らげる最善の方法は、実際の問題に即して会話を進めることです。Calienteでは、まず問題点の洗い出しから始めます。スピード低下や摩擦の原因を探り、その上で、AIでそれを解決できるかを検討します。
答えがイエスなら、AIによる拡張を考えます。Calienteでは「自動QA」とは言いません。「AI支援型テスト」と言います。新しいイニシアチブを「AIアプリの構築」と位置づけることもありません。「既存のアプリを拡張し、うまく機能している部分は変えずに 、より速く、よりスマートで、より有用なものにすること」という位置づけで話すのです。AIをエンジニアの第2の目として活用し、コードレビュープロセスを強化することで、エンジニアがより高価値の仕事に集中できるようにします。
イノベーションの必要性: 柔軟性欠如の代償
既存のチームで自由に構築したいのであれば、インフラはその選択をサポートするものでなければなりません。AIに関する会話では、AIは野心で動くのではなく、インフラで動くという基本が忘れられる時が必ずあります。
硬直的なオンプレミスシステムを使い続けていると、最高のアイデアですら、遅延、互換性の問題、調達ループが足かせとなって停滞してしまいます。私はそれを実際に経験しました。GPU集約型のワークロードを実行するためにレガシースタックを後付けするのは、面倒なだけでなく、高コストになります。ハードウェアの修正、ドライバーの更新、OSパッチの適用に追われ、実験を始めるどころではなくなります。
見落とされがちなのは、アプリケーションのモダナイゼーションがAIの前提条件だということです。インフラが柔軟であればあるほど、試行錯誤も低コストでできます。環境を迅速に立ち上げれば、何が機能し、何が機能しないかをより早く学ぶことができます。特に、サーバーレスアーキテクチャなら初期費用なしで複数の構成をテストできるため、さっさと実験を実行してデータを取得し、前へ進めます。
そして、この俊敏性には後々のメリットもあります。この分野のハードウェアとソフトウェアは進化が速く、すべてをオンプレミスで管理していると、絶えずアップグレードする羽目になります。サーバーレスやクラウドネイティブのプラットフォームであれば、とにかく後れずついていくのに時間と予算を費すのではなく、進化に合わせて進むことができます。
Calienteでうまくいったのは、AIトライアル向けに構造化されたサンドボックスを作ったことです。それにより実験的な開発を本番リリースと明確に分け、仮説検証期間を短く設定し、拡張に移るための「合格」ラインをあらかじめ定義しました。
私が守っているいくつかの原則：
コア製品の侵害から実験を分離
テストサイクルのタイムボクシングによって注意散漫を防止
AIリードとプロダクトオーナーをペアにして、各アイディアがアプリに実際の影響を与えるよう保証
AIは孤立したものではなく、既存のシステムの中で機能しなければなりません。うまく組み込めば、AIの実験はアプリのイノベーションを加速します。遅らせることはありません。安定性を損なうことなく、よりスマートな機能、より良い自動化、より応答性の高い製品を実現できるのです。
AIインフラストラクチャの3つの必須要素
AIをアプリケーション開発のパイロット段階から先へ進める前に、3つの絶対条件があります：
明確なデータガバナンス。明確に定義されたアクセスルールが重要です。AIがアクセスできるデータは？どんな条件下で？これを決めておかないと、コンプライアンスの問題を起こります。
スケーラブルなコンピューティング。パイロット版は計算能力が低いマシンでも実行できますが、本番ワークロードはそうはいきません。拡張可能なインフラが重要であり、特にGPUワークロードの実行では鍵となります。
強力なモニタリング。AIの運用開始後は、十分な可視性と監視が必要です。これには、ドリフトの追跡、異常の検知と、意図しない結果をエスカレートする前に検出することが含まれます。
これらをきちんと守れば、実験は持続可能になります。AIは機能であって、製品ではありません。私は職務上、AI導入の過程において、構造化された実験、明確な教育、そして盛り上がりよりも透明性を重視する文化がいかに重要かを見てきました。
しかし、インフラだけでは進捗しません。チームの準備も必要です。
真のAIレディネスを示す3つのしるし
アプリイノベーションにおけるAI活用の拡大に向けてエンジニアリングチームの準備が整っているかどうかを考える際、私は3つのことを確認します：
オープンな会話：チームが成功と失敗の両方を安心して共有し、うまくいっていること、うまくいっていないことを正直に話すことができるなら、それは良い兆候です。
基礎の理解：チームは専門家である必要はありませんが、LLMの仕組み、パラメータ数、トークン数といった用語、AIハルシネーションが起きる理由について、少なくとも基礎的な理解は必要です。そうした理解は、より深い理解への興味と意欲を示しています。
境界線の意識：チームは、どのようなデータが安全に共有でき、どのようなコンテンツが再利用可能で、法的または倫理的な境界線がどこにあるかを知っています。
これらは、あるのが望ましいだけでなく、真のAI駆動型アプリイノベーションを構築し、維持する準備が整ったチームであることを示す指標でもあります。
ツールありきの強引なソリューションは駄目
よく目にする落とし穴の一つが、「ソリューションファースト」の考え方です。リーダーがAIツールに魅了され、その導入を正当化するためにユースケースを考案せよとチームに求めるのです。しかし、ツールありきで始めると、ありもしない問題や自社ビジネスに関係のない問題に取り組むことになりがちです。肝心なのは実在する高インパクトの問題の解決であり、そのためにAIが必要かどうかを見極めてはじめて真の前進が始まります。そうすれば焦点を定めて進めます。具体的な目的があるか らこそ、テスト、学習、コース修正を明確性を以て行えるのです。
そこからはイテレーションをいかに速くできるかです。特にライブアプリケーションにAIを融合する際はこれが重要になります。ユースケースを狭く定義し、非本番環境でテストし、インパクトを測定し、フィードバックを集め、改善します。うまくいけば拡張します。うまくいかなくても、有意義な学びがあったことに変わりはありません。リソースを過剰に投入したり、誰も必要としない技術を構築したりすることなく得られた学びです。
技術的障壁ではなく、行動のガードレール
外部に公開されたAIツールをロックダウンすれば短期的リスクを軽減できるかもしれませんが、学びの妨げになります。チームが既に従っている行動基準を強化する方が、アプローチとして適切でしょう。例えば、開発者は既にコード内の秘密情報を墨消ししています。同じ行動基準をAIによるレビューにも適用するのです。ただし、ポリシーだけでは進歩は生まれません。前進に真の勢いをつけるのは、納期の遅れなく安全に実験できるような技術的、文化的システムです。
それはアプリイノベーションから始まります。適切なアーキテクチャは、チームがテストし、実際の問題を解決し、迅速に動ける場を提供します。2026年Cloudflareアプリイノベーションレポートは、まさに私が実地で見てきた通りのことを提言しています。システムが整備できた段階で最も賢明なAI投資は既存チームへの投資であると。
Cloudflareでモダナイゼーションを加速
アプリのモダナイゼーションが単発イニシアチブではなく継続的戦略となり、テクノロジーリーダーは、統制やセキュリティを犠牲にせずスピードアップできるプラットフォームを必要としています。Cloudflareのコネクティビティクラウドは、レガシーシステムのリホスティングから、アジリティのためのリプラットフォーム、全く新しいアプリやAIサービスの構築まで、アプリケーションジャーニーのあらゆる段階をサポートします。アプリ配信、セキュリティ、可観測性、開発のツールを単一のプログラム可能なプラットフォームに統合したCloudflareは、コストを増大させることなく、複雑さの緩和、迅速なリリース、イノベーションの促進を可能にします。
この記事は、テクノロジー関連の意思決定者に影響を及ぼす最新のトレンドとトピックについてお伝えするシリーズの一環です。
このトピックを深く掘りさげてみましょう。
最新のインフラストラクチャがどのようにAIの成功を実現するのか、詳しくは2026年Cloudflareアプリイノベーションレポートをご覧ください。
著者
Lior Gross
Caliente Interactive、CTO
記事の要点
この記事では、以下のことがわかるようになります。
既存チーム対新規採用者：AIアプリ担当の選択
AIの実験によるアプリイノベーションの促進
AIアプリの成功におけるビジネス知識の役割