Saulius Lazaravičius, Hostinger 製品担当副社長 – インタビューシリーズ

Saulius Lazaravičius, Hostinger の製品担当副社長は、ソフトウェアエンジニアリング、起業、eコマース、製品開発にわたる20年以上のキャリアを持つ経験豊富なテクノロジー・プロダクトリーダーです。ソフトウェアエンジニアとしてキャリアをスタートし、B2B SaaS 企業を共同設立し、ゼロから輸送管理プラットフォームの構築に貢献しました。その後、バルト地域最大級の食料品 eコマースプラットフォームである BARBORA のソフトウェア開発チームを結成・指揮し、NFQ に入社しては横断的なテクノロジーチームとクライアント向け製品開発を統括しました。Lazaravičius は 2022 年に Head of Product として Hostinger に入社し、2024 年に VP of Product に昇格。担当領域はウェブホスティングとマネージド WordPress から、コアインフラ、VPS、ドメイン、ビジネスメール、製品デザイン、プロダクトグロース、そして新興の AI 製品まで幅広く拡大しました。最近の取り組みとしては、Hostinger のメールマーケティングサービスの立ち上げと成長、そしてオープンソース AI エージェント向けマネージドソリューションの導入があります。

Hostinger はリトアニア発のテクノロジー企業で、従来のウェブホスティングプロバイダーから、オンラインビジネスの構築・立ち上げ・成長を支援する AI 主導のプラットフォームへと進化しました。2004 年に設立され、現在は 150 カ国以上で 500 万人以上のユーザーにサービスを提供し、約 900 人の従業員が在籍しています。製品ポートフォリオはウェブ・クラウドホスティング、マネージド WordPress、仮想プライベートサーバー（VPS）、ドメイン、ビジネスメール、eコマース、そして AI 搭載のクリエイションツールに及びます。Hostinger は AI を戦略の中心に据えており、会話型 AI を通じてウェブサイトやウェブアプリケーションを作成・公開できる Hostinger Horizons や、eコマース、カスタマーサポート、マネージド AI エージェント向けの統合 AI 機能などを提供しています。

あなたはソフトウェアエンジニアとしてキャリアを始め、開発チームを立ち上げ、現在はコアインフラ、VPS、ドメイン、プロダクトグロース、オープンソース AI エージェント向けマネージドソリューションまで幅広い Hostinger の製品ポートフォリオを統括しています。このようなキャリアの変遷は、開発者が単にコードを生成させるだけでなく、AI から何を本当に必要としているかという考え方にどのような影響を与えましたか？

私にとってソフトウェア開発で最も興味深いのは、コードを書くことそのものではなく、技術的あるいはユーザーの課題に対して最適な解決策を見つけ、仮説を立て、それを形にし、実際に人々がどのように利用し価値を得るかを見ることです。

過去には、開発者はそのプロセスに伴う反復的な作業に多くの時間を費やしていました。ライブラリやコードスニペットの検索、さまざまなコンポーネントの接続、デバッグ、テスト、そして小さな問題の修正に追われ、解決策が本当に良いかどうかを評価できるまでに時間がかかっていました。

AI はこのバランスを変えます。多くの反復作業が数回のプロンプトで処理できるようになり、開発者は問題の理解、アプローチの検討、プロダクトの意思決定、実ユーザーの行動からの学習といった創造的な部分により多くの時間を割けるようになります。

これが開発者にとって AI が提供できる最大の価値だと考えています。単にコード生成が速くなるだけでなく、必須だが面白みの少ない作業を削減し、開発者が本当に重要な課題解決に時間を費やせるようにすることです。

AI コーディングツールは、アイデアから実装可能なコードへ至る時間を劇的に短縮しました。現在、AI 補助型ソフトウェア開発において、デプロイやインフラ管理が次の大きなボトルネックになると考えますか？

はい、次の主要な摩擦点になると考えています。

AI はアイデアと実装可能なコードの間の時間を大幅に短縮しました。しかし、コードができた後はそれをどこかに配置し、正しく設定し、サービスを接続し、ドメインやセキュリティを管理し、アプリケーションを稼働させ続ける必要があります。これらのステップが依然として複数のダッシュボード、ドキュメントページ、ターミナル、ツール間の切り替えを必要とするなら、ワークフローは再び遅くなります。

開発者はコードから本番環境へのスピードを、アイデアからコードへのスピードと同等に求めています。すでに 19,000 人以上の顧客が Hostinger Connector を試用し、約 1,500 人が日常的に利用しており、1 日あたりおおよそ 30,000〜40,000 件のアクションが実行されています。これはデプロイと運用が AI 補助型開発フローに直接組み込まれつつあることを示す強いシグナルです。

Hostinger は Connector が 1 日あたり 30,000〜40,000 件のアクションを処理している と述べています。実際に開発者は本番環境で AI エージェントに何をさせようとしており、使用パターンで驚いた点はありますか？

開発者は VS Code、Antigravity、Cursor といった既に使用しているツールから直接 Connector を利用しています。この変化は、インフラ関連のアクションを開発フローに取り込むことで、別々のダッシュボードを行き来する必要がなくなる点で重要です。

最も顕著なユースケースはデプロイです。すでに 14,600 件以上のユニークなウェブサイトが MCP を通じてデプロイされており、週次デプロイは過去 1 か月でほぼ 300% 増加しました。

デプロイ以外でも、エージェントは Connector を使ってドメインや DNS の管理、ウェブサイトファイル、サーバーリソース、ファイアウォールルール、SSH キー、eコマースタスク、メールキャンペーン、その他 Hostinger のサービスを操作します。実際には、エージェントがプロジェクトの構築支援から、オンライン化とその周辺サービスの管理までを一貫して行えるということです。

AI エージェントにコードを書かせることと、DNS レコードやファイアウォールルール、SSH キー、サーバー設定を変更させることには大きな違いがあります。エージェントにこのレベルの運用権限を与える際に、どのような新たな安全策が必要になりますか？

最大の違いは、エージェントが単なる提案ではなく、実際にライブシステムに変更を加える点です。そのため、セキュリティとコントロールが格段に重要になります。

つまり、エージェントには明確な権限境界、セキュアなアクセス、実行したアクションの可視性が必要です。ただし、理想的には開発者がその複雑さをすべて管理する必要はありません。

これが Hostinger Connector と当社エージェントプラットフォームのアプローチです。プラットフォームがインフラ、アクセス、セキュリティ層をエージェントの周りで処理するため、開発者はエージェントに何をさせたいかに集中でき、下層の設定や保守に時間を割く必要がなくなります。

「Vibe coding」は、インフラや DevOps の知識が限られた人でもソフトウェア開発に参入できるようにしました。そうしたユーザーがエージェントを通じてアプリケーションをデプロイし始めたとき、基盤となるシステムを十分に理解していない場合、何が起こりますか？

これはユーザー側ではなくプラットフォーム側の責任が増すことを意味します。AI がより多くの人にソフトウェア構築を可能にするなら、すべてのユーザーがインフラの専門家になることは期待できません。

プラットフォームはセキュリティやバックアップ、モニタリング、リソース制限、合理的なデフォルト設定といった複雑さを裏で処理する必要があります。ユーザーは大まかな流れは把握すべきですが、アプリケーションを安全にオンライン化するために深い DevOps 知識は不要です。

AI エージェントでも同様のパターンが見られました。Managed OpenClaw などの製品では、ユーザーが直面した課題はエージェントができることではなく、信頼性のある運用に必要なホスティング、設定、API キー、セキュリティ、保守といったすべての前提条件でした。セットアップ負荷を取り除くことで、技術は格段に身近になりました。

今後、インフラも同様の方向へ進むと考えています。ユーザーは構築したいものに集中でき、プラットフォームがバックグラウンドで安全に運用上の複雑さを処理する形です。

AI エージェントがインフラを信頼性高く操作するためには、依存関係、サーバーリソース、セキュリティポリシー、認証情報、過去の構成変更など、周囲の環境に関するどれだけのコンテキストが必要ですか？

エージェントはタスクだけでなく、そのタスクが実行される環境全体を理解できるだけのコンテキストが必要です。

DNS レコードの変更、サーバーの再起動、バージョンのデプロイといった単純なアクションでも、システムの他の部分に影響を与える可能性があります。そのため、エージェントは「何がデプロイされているか」「何に依存しているか」「利用可能なリソースは何か」「エージェントに付与された権限は何か」「過去に何が起きたか」といった構造化情報にアクセスできる必要があります。

ただし、コンテキストが増えるからといって無制限にアクセスを許可すべきではありません。エージェントはタスクを安全に完了するために本当に必要な情報と権限だけを受け取るべきで、過剰な権限付与は逆効果です。

人間の承認が必須であるべき場面はどこですか？ AI エージェントが自律的に実行できるインフラ操作と、常に明示的な人間の許可が必要な操作のカテゴリはどのように分けるべきだと考えますか？

システムが最初から適切に設定されていれば、AI エージェントはほぼ自律的に動作できると考えています。

すべてを一つのエージェントに任せるのではなく、役割ごとにエージェントを分けることが有効です。あるエージェントはコーディングとデプロイを担当し、別のエージェントは結果のテストを行い、さらに別のエージェントがシステムを監視してアラートを上げ、問題が発生した際にはエスカレーションを行う、といった具合です。

この構成では、個々のアクションすべてに人間が承認する必要はありません。人間の役割はエージェント全体のルール策定、適切な権限設定、エージェント同士の連携監視、そして継続的な改善にあります。

したがって、重要なのは個別のアクションが常に人間承認を要するかどうかではなく、システム全体が適切なチェック、責任分担、エスカレーションパスを備えて設計されているかどうかです。

開発環境がアプリケーションのデプロイ、ドメイン管理、サーバー設定、外部サービス制御のインターフェースになるにつれ、IDE、DevOps プラットフォーム、クラウド管理コンソールの従来の境界はなくなると予想しますか？

境界は大きく曖昧になると予想しますが、すべての専門インターフェースが消えるわけではありません。

現在、開発者は IDE、ホスティングダッシュボード、ドメインパネル、ターミナル、複数の外部サービスを行き来しながら、1 つのアプリケーションを本番に持ち込んでいます。AI エージェントはこれら多くのステップをつなげ、開発者がすでに作業している環境に統合できます。

ダッシュボードやクラウド管理ツールが消えるわけではなく、深い設定や監視が必要な場面では依然として有用です。しかし、日常的なタスクの多くは、次にどのインターフェースを開くかを意識せずに、やりたい作業に集中できるようになるでしょう。

体験は「どのツールがそのタスクを所有しているか」ではなく、「やりたいタスクは何か」へとシフトします。

AI エージェントはインフラ変更を人間よりはるかに高速に行える一方で、機械的な速度でミスを起こすリスクもあります。監査ログ、ロールバック機構、権限境界、継続的モニタリングといった機能は、エージェント開発が成熟するにつれてどれほど重要になると考えますか？

これらの機能はエージェントが運用作業を担うほど必須となります。

AI は人間よりもはるかに速くインフラを変更できるため、うまくいったときは便利ですが、同じ速度でミスが拡散すると被害も大きくなります。そのため、ユーザーは「何が変更されたか」「エージェントにどの権限が付与されたか」「問題が起きた際にどう復旧するか」を把握できる必要があります。

監査ログ、権限境界、モニタリング、ロールバック機構は、こうした自動化を信頼できるものにする鍵です。

エージェントの能力が向上すれば、これらの保護策の質はエージェント自体のインテリジェンスと同等に重要になると考えています。

今後、勝ち残る AI 開発プラットフォームは最優秀のコーディングモデルを備えているかどうか、あるいはエージェントにインフラ、ツール、組織コンテキスト、プロダクションシステムへの安全なアクセスを提供できるかどうかで競争優位が決まると考えますか？

コーディングモデルの品質は依然として重要ですが、それだけでは不十分だと考えています。

モデルがコード生成に優れていても、次に重要になるのは「その後に何が起こるか」です。エージェントはアプリケーションをデプロイできるか？ 正しいサービスに接続し、環境を理解し、安全に変更を加えて、すべてが正常に動作していることを検証できるか？ これらがインフラアクセス、ツール、権限、コンテキストの重要性を高めます。

最も強力な AI 開発プラットフォームは、優れたモデルとコード周辺のシステムへの安全なアクセスを組み合わせたものになるでしょう。真の価値は、単にソフトウェアを書きやすくするだけでなく、アイデアから実装可能な製品へ至るステップを減らすことにあります。

素晴らしいインタビューをありがとうございました。提供されているさまざまなホスティングソリューションについて詳しく知りたい読者の方は、ぜひ Hostinger をご覧ください。