Yuri Gubin、DataArtのCTO – インタビューシリーズ

Yuri Gubin、DataArtのCTOは、DataArtで18年以上勤務し、ソフトウェアアーキテクト、ソリューションアーキテクト、クラウド技術、イノベーション、エグゼクティブリーダーシップといった役割を経て、2026年3月に最高技術責任者に就任したベテランのテクノロジーエグゼクティブ兼ソフトウェアアーキテクトです。彼の仕事は、金融サービス、ヘルスケア、旅行、IoT などの業界における複雑な技術課題の解決に焦点を当てており、特にクラウドコンピューティング、AI、データプラットフォーム、エンタープライズソフトウェアアーキテクチャに専門性を持っています。CTOになる前、Gubin は5年以上にわたり DataArt のチーフイノベーションオフィサーを務め、2021 年からは同社のパートナーボードのメンバーでもあります。また、Forbes Technology Council のプロフェッショナルメンバーとして AI とクラウドコンピューティングの専門グループに参加し、Girls Who Code のテクノロジーアドバイザーとして、アーキテクチャ、データ保護、プラットフォームガバナンス、テクノロジーポリシーに関する助言を行っています。DataArt は現在、彼をニューヨーク拠点の最高技術責任者として掲載しています。

DataArtは、1997 年にニューヨークで設立された、グローバルなソフトウェアエンジニアリングおよびデータ・AI トランスフォーメーション企業です。同社は 20 カ国以上で 6,000 人超の技術専門家を抱え、400 社以上のクライアントに対し、人工知能・機械学習、データ・分析、クラウドトランスフォーメーション、カスタムソフトウェアエンジニアリング、サイバーセキュリティ、レガシーモダナイゼーションなどのサービスを提供しています。DataArt は金融サービス、ヘルスケア・ライフサイエンス、旅行、メディア・エンターテインメント、小売といったセクターで活動し、AWS、Google Cloud、Microsoft Azure、Snowflake、Databricks などのプラットフォームと技術パートナーシップを維持しています。2025 年に同社はデータ・AI 能力への 3 年間で 1 億ドルの投資を発表し、2026 年には AI エージェント、再利用可能なアクセラレータ、ガバナンス、セキュリティ、コンプライアンスをエンタープライズソフトウェア開発に組み込むことを目的とした AI 対応オペレーティングモデル「Artisyn」を開始しました。

DataArtでほぼ20年にわたり、ソフトウェアアーキテクトやソリューションアーキテクトからチーフイノベーションオフィサー、そして現在のCTOへとキャリアを積んできましたが、その経験は本当に変革的な技術と過熱サイクルをどのように見分ける姿勢に影響を与えましたか？また、現在の AI に対する「懐疑的楽観主義」にはどのように反映されていますか？

私たちはこれまでに、クラウドやモバイルの台頭、さまざまな世代の AI、オートメーション、DevOps、SRE など、数多くの波を目にしてきました。その間、私はこれらのテーマについてコーディングやアーキテクチャ設計、クライアントへの助言を行ってきました。私が気付いたのは、技術を使えばほぼ何でも実現でき、技術は非常に強力ですが、肝心なのは細部であり、意味が通り、機能するためには自分が何をしているかを正確に把握する必要があるということです。

クラウド環境がますます高価になること、期待通りに機能しない AI モデル、リリースサイクルの自動化を不十分に実装した事例を目にしてきました。良い判断と悪い判断の両方がもたらす影響も見てきたので、新しいものが登場し、すべての発表や約束、誇大宣伝を読むたびに、私は同じ前提に立ち返ります。技術でほぼ何でも可能ですが、自分が何をしているかを知る必要があります。

技術を深く理解するには、R&D と、特に実際のプロジェクトを通じて学ぶことが重要です。これにより、何が可能で何が不可能か、どこで問題が起こり得るかを学びます。各案件から得た教訓を活かし、同僚や他のアーキテクト、アナリストと議論し、パターンが存在するか、そしてそれらを基に何らかの体系を構築できるかを検討します。最終的にそれが指針となり、自分が良いと考えた判断が実際に良い結果を生むかどうかを確認できるようになります。

これが懐疑的楽観主義の根源です。技術が何を約束しようとも、やはり自分が何をしているかを理解する必要があり、その知識は経験、協働、そして継続的な学習と改善の努力、さらには誇大宣伝の背後にあるある種の体系を構築することから得られます。

エンタープライズ AI は、実験を奨励する段階から、どの実験を本格的に拡大すべきかを判断する段階へと移行しているように見えます。AI のユースケースが広範な導入に適していることを示すシグナルは何ですか？また、企業が拡大しすぎていることを示す警告サインは何でしょうか？

私は、何かをスケールすべきか、あるいは別のアプローチが必要かを判断するために、採用曲線と学習曲線という二つの手法を用います。

AI ユースケースが機能しているかを判断するには、一定期間様子を見て、もたらす価値とユーザーの体験フローを把握する必要があります。そうすれば、特定のチームやワークフローでの即時的な「すごい」感覚だけでなく、上下動を観察できるからです。数週間後に同じユーザーがどうなっているかも確認する必要があります。まだ利用し続けているか？そのユースケースや自動化、AI スキルに満足しているか？それとも、実際には拡大すべきでない一時的な現象に過ぎなかったか？

これらのことのいくつかは時間をかけてしか検証できません。常に最初のパイオニアが存在し、通常は最も技術に精通した人々や非常に好奇心旺盛な人々です。その後、早期採用者に続く層や早期多数派といった他のセグメントでも試す必要があります。そこできちんと実証されれば、はい、スケールさせてそのユースケースを他の部門へ拡大できます。

すべての主要なモデルリリースは、組織内で従業員に最新の機能へのアクセスを即座に提供する圧力を生むことがあります。テクノロジーリーダーは、新しいモデルが単に別の実験とコストの波を生むだけでなく、意味のある改善をもたらすかどうかをどのように評価すべきでしょうか？

ここでもう一度、私の懐疑的な楽観主義を示します。すでにモデルが導入され、数千人が日々AIを使用しており、さまざまなモデルやツールが利用可能であると想定してください。新しいモデルが登場すると、話題性と自然な好奇心から、誰もがそれを試したがることが予想されます。これは良いことですが、その実験が必ずしも特定の結果に向けて導かれたり指向されたりするわけではなく、時には差異を測定できないことさえあります。

規模が大きくなると、これは重要になります。新しいモデルが旧モデルと比較してどのように機能するかを確認するのが、1、2人だけではありません。数千人が時間を費やして実験を行うこともあり、特定のユースケースでは結果がそれほど重要でないこともあります。同時に、何かが非常にうまく機能した場合でも、組織内で何が効果的かという学びが明確に説明されたり、全員に見える形で共有されたりしないことがあります。

そのため、新しいモデルを評価する最初のグループは組織全体ではなく、関係するチームと密に連携するR&Dグループ、そして法務やセキュリティが中心となるべきです。我々はモデルを包括的に評価し、迅速なアセスメントを行った上で、セキュリティ、コンプライアンス、テクノロジーに関するコメントやガイダンスを添えて、より広い対象者に提供します。新しいモデルや大規模なアップデートが常に登場する中で、このモデルと考え方を整えておく必要があります。これは一度きりの作業でも、一回限りの演習でもありません。

DataArtは、テクノロジー、法務、コンプライアンス、情報セキュリティ（InfoSec）などのチームを含む横断的な「AI SWAT」を設立しました。このグループは実務上どのように機能し、新しいAIツールがより広範に使用される前に解決すべきリスクや質問はどのようなものですか？

創設以来、約4〜5か月ごとにこのグループの目的を変えてきたと考えています。優先順位や目標、時にはミッションを変更し、これらの目的の多くはAIに関するものです。人材のスキル向上、市場投入や新機能、パートナーシップ、あるいは組織全体およびADLC全体でAIをより広く活用できるようにすることが含まれます。

具体的なテーマは時間とともに変化し、それは健全だと思います。なぜなら、常に自らの戦略を見直し、前提を検証し、方向転換が必要かどうか、次にチームが取り組むべきテーマは何かを理解する必要があるからです。

このグループはさまざまな部門の代表者で構成されており、その目的の一つは単に全員に情報を共有することです。新たな発表や質問、機会が生じた際には、誰かがそのテーマを定例会議の一つに持ち込むことができます。たとえそれが特定の小さなチームにのみ関係する技術的な質問に見えても、現在ではこうしたテーマが組織の多くの部門に影響を及ぼすことがあります。

そのため、新たなパートナーシップ、ツール、アクセラレータを評価する際には、オープンに議論し、全員が今後の方向性を理解し、質問や監視の機会を持てるようにします。新しいAIツールに関しては、テクノロジーだけで単独に評価できません。セキュリティ、法務、コンプライアンスも、ツールが企業や顧客データをどのように扱うか、どのような制約があるか、スケールして安全に使用できるかを理解する必要があります。

AI SWATチームは、時にはスキル向上などの特定プログラムにも取り組みます。その際、目標を設定し、ロードマップを策定し、各グループのオンボーディング方法を決定します。実際の運用はこのように、人々に情報を提供し、特定プログラムで協働し、取締役会に対して会社全体でAIがどのように進行しているかを可視化することです。

AI支援ソフトウェア開発に対する姿勢は組織によって大きく異なります。ある組織はエージェント開発を積極的にスケールさせている一方で、他の組織は依然としてAI生成コードを禁止しています。この分断を説明する要因は何か、そしてリスクを重視する企業がAIがソフトウェアエンジニアリングでより大きな役割を果たすことに安心できるようになるために何が変わる必要があるのでしょうか？

おそらく、否定する側と肯定する側の違いを生むのは、リスク許容度と曖昧さや不確実性に対する姿勢です。両タイプの組織に共通して役立つのは、継続的な教育、実験、評価です。AIを受け入れ、至る所に組み込んでいる多くの組織でも、成果やインパクトの測定に関する課題は依然として残っています。正直なところ、AIのインパクトをどのように測定し、チームのパフォーマンスをどのように評価するかという質問は、時に突然浮上してくることがあります。まるで誰も以前に考えていなかったかのように。

AIイニシアチブをより包括的に評価し始めると、そのインパクトと実際に提供している価値が理解できるようになり、技術が適切に活用できる領域について、より良い意思決定ができるようになります。AIを導入しないと答える企業でも、技術が何ができるか、現在の位置はどこかを継続的に見直すプロセスが必要です。3年前に下された決定が、誰も前提条件を再検討しないために会社の方針として残り続けることは望ましくありません。

エージェントAIは、個々のチームが独自のエージェントを作成することをますます容易にし、ほぼ同一のタスクを実行するエージェントが多数生まれる可能性があります。実験がエージェントの乱立になるのはどの段階か、所有権、権限、重複、ライフサイクル管理を行うためにどのようなガバナンス層が必要でしょうか？

AIライセンスがすべての開発者に付与され、実験が指針なしに行われる典型的なシナリオを見ると、各自が自分のものを作り、独自の方法で作業を始めます。通常、これによりチームのパフォーマンスが低下し、期待が外れ、品質が遅れ、コストが上昇します。結局のところ、期待通りに機能せず、品質が悪く、費用がかさむのです。これを緩和するには、部門や組織全体の取り組みの一部としてチームでの協力が必要であり、そこにガバナンスが関わってきます。

プロジェクトレベルでは、知識ベースとコンテキスト、そしてAIを使用し始めるユースケースについて合意できます。その後、開発ワークフローの一部となるスキルやエージェントを作成し、全員が再利用できるようにすることで、毎回作り直すのではなく知識とベストプラクティスを蓄積します。このプロジェクトレベルの取り組みは、エンタープライズアーキテクチャ委員会やテクノロジーグループ、CTO、あるいはAI導入を担当するチームなどが統括すべきです。うまく機能するエージェントを再利用し、プロセスを確実にし、組織全体で機能させ、混乱やノイズに陥らないようにしたいものです。

したがって、プロジェクトレベルでの同期的な取り組みが必要であり、場合によってはプログラムレベル、さらに部門や組織全体のレベルでも同様に行うべきだと考えます。

トークン消費と推論コストはパイロット段階では比較的小さいように見えますが、AIシステムが数千人の従業員や自律エージェントに展開されると大きくなります。企業はAIコスト管理をどのように考えるべきでしょうか、またAIワークロード専用のFinOpsに相当するものが出てくると予想しますか？

まず、ほぼ理想的なシナリオは、AIコストが上昇し、一定のプラトーに達した後、時間とともにやや減少し始めることです。これにより、コストを予測・管理でき、AIに実際にどれだけ支出しているかを把握し、意思決定の結果を確認できます。問題となるのは、コストが上下し続ける場合で、これは通常、持続可能性がないことを示します。また、コストが上昇した後に完全に下がる場合は、導入が進んでいない、何かが機能していない、あるいは別の手段が使用されていてそれが見えていない可能性があります。

したがってFinOpsは存在し、AI FinOpsも同様に存在します。手法の中には高度に技術的なものもあれば、かなりシンプルなものもあります。たとえば、常に最も高価なモデルを使用しないように好みのモデルを選択するだけでも、段階的にコスト削減につながります。同時に、コストを節約・管理する方法を知ることは方程式の半分に過ぎません。私が見るFinOpsは、AI取り組みを評価する際に何を測定すべきかを定義する必要があるため、製品やビジネスリーダーも巻き込む discipline（学問領域）と methodology（方法論）です。

ですから、AI FinOpsはAI SWATチームに相当するものが議論すべき良いテーマだと思います。支出額、リターン、コントロール方法、そして機会がどこにあるか、という点です。

多くの企業は、AI導入前にチームの生産性の信頼できるベースラインを確立していないにもかかわらず、AIからのROIを示すよう求められています。AIが実質的なビジネス価値を創出しているかを判断したい場合、組織は実際に何を測定すべきでしょうか？

AIに対する姿勢や現在の状況に関わらず、すでにエージェントを随所で使用しているか、来年からAIを導入しようと考えているかにかかわらず、ベースラインの確立は現代において絶対に必要です。

指標にはいくつかの分類があります。主観的なものもあり、これは開発者や従業員からのフィードバックだけで済む場合があります。人と働く上で、彼らがAIの価値をどのように捉えているかを理解することが重要です。より客観的な指標は、機械的または合成的なメトリクスから始められますが、あまり固執しすぎないように注意を促したいです。たとえばコードコミットやストーリーポイントなどです。これらの指標は作業が行われていることを示しますが、価値やインパクトを本質的に示すわけではありません。

より重要なのは、作業がどれだけ速く、あるいはどれだけうまく提供されたかを説明する指標です。リードタイムやMTTRといったDORA指標や、障害からどれだけ速く回復できるか、プロダクションでバグをどれだけ速く修正できるか、あるいはそれらの指標が時間とともにどのように変化するかを考えてみてください。ある時点の数値だけでは軌道を示すことはできません。最近、当社のアーキテクトの一人が、ソフトウェア開発においては、AI導入が進むにつれて見積もりの信頼性も重要な指標になる可能性があると述べました。これは、取り組みの持続可能性やチームの実際の生産性を示すものです。また、コストも追跡する必要があります。利益だけを語り、達成に要するコストを理解しなければ、全体像は見えてきません。

ソフトウェア開発以外でも、同様の考え方が当てはまります。すべてのワークフローやプロセスには、作業単位と完了の定義があります。請求処理や書類レビュー、顧客対応など、何を提供するのかを定義し、AI導入前にどれだけ時間がかかっていたか、現在はどれだけ速く、どれだけうまくできるのか、そしてそのコストはどれくらいかを測定してください。これにより、ベースラインと指標のフレームワークの両方の出発点が得られます。

DataArtはArtisynなどのイニシアチブを通じて、ソフトウェアデリバリライフサイクル全体にAIを組み込んできました。AIが実装、テスト、ワークフロータスクをますます担う中で、ソフトウェアエンジニアリングのどの部分が人間にとってより価値が高くなり、どのスキルが重要性を失うリスクがあるのでしょうか？

AIを開発に効果的に活用できるのは、良さの定義をまだ覚えている場合に限られます。エージェントを導く専門知識、結果のレビュー、制約設定、ルール定義が必要です。ベストプラクティスや良いアーキテクチャが何かを理解していなければ、何が開発されているのか分からず、この種の専門知識の価値は非常に、非常に大きく上昇しています。

アーキテクチャパターンの理解は重要であり、特定の業界、アプリケーション、ソリューションのクラスに何が適切かを把握することも同様に重要です。現在良いとされるアーキテクチャと、ソリューションがスケールしたときにも有効であるアーキテクチャを知る必要があります。なぜなら、同じアーキテクチャがソリューションやプラットフォームのライフタイム全体で機能し続けるとは限らないからです。

特定のソリューションにとって何が適切かというバランスが人間側の要素です。これはサービスやソフトウェア開発における職人技、センスに相当します。自分が何をしているかを理解し、さらにそれはクライアントや業界の理解からも得られます。

どのスキルが重要性を失うのでしょうか？正直に言うと答えるのは難しいですが、コードをどれだけ速く入力できるかは一つの指標かもしれません。冗談ですが、現在はコードをはるかに速く生成でき、特定のライブラリや言語に関する知識もAIのおかげで格段に早く習得できます。

.NET開発者がJava開発者へと非常に速く転向するのを目にしました。5年か10年前なら、規模でそれを実現するのはほぼ不可能だと言っていたでしょう。今では可能です。優秀なシニア開発者は、技術、アーキテクチャ、ソリューションのベストプラクティス、SDLC、ADLCの理解が何より重要であるため、言語間を移動できるようになります。

企業が数十件のAIパイロットから、独立して行動できる本番システムへと移行する中で、AIエージェントが高額なミスをした際の最終的な責任は、開発者、ビジネスオーナー、モデル提供者、ガバナンスチーム、あるいはそれらの組み合わせのどこにあるべきでしょうか？

私は、非難のない協働と責任の共有という考え方が好きです。組織の全員がベストプラクティス、アーキテクチャフレームワーク、ソリューションに貢献しています。開発者がAIを使ってコードを作成しようが作成しなかろうが、別の開発者がレビューし、チームリーダーが指導し、アーキテクトがアーキテクチャと制約を提供し、ガバナンスチームが予算、タイミング、リリースに関する意思決定に関与します。すべての人が何らかの形で関与しています。

多くの場合、問題が起きるのはプロセスが機能していないためであり、その意味で責任は複数の役割にまたがって共有されています。しかし、単に「責任は共有されている」だけでは不十分です。非難がないと言っても、具体的な責任分担を明確にしなければなりません。

開発者はプルリクエストとして提出したコードに対して責任を負い、その内容を理解する必要があります。アーキテクトは自らが下した決定と、エージェントや開発者に提供したアーキテクチャ上の決定に対して責任を負います。プラットフォームチームは、コードが誰や何によって作成されたかに関わらず、ソリューションの信頼性に対して責任を負います。

したがって責任は存在しますが、チーム、役割、部門ごとに細分化して定義する必要があります。「AIがやった」というだけで分析を止めてはいけません。どのようなコントロール、テスト、監視がその失敗を本番に持ち込ませたのかを問う必要があります。

ユニットテストが不足して不良コードが本番にプッシュされた場合や、監視・レビューが不十分で問題が起きた場合、その責任をAIに転嫁することはできません。また、すべてのバグや障害の原因をモデル提供者やクラウド提供者に単純に帰すこともできません。

素晴らしいインタビューをありがとうございました。詳しく知りたい読者はDataArtをご覧ください。