要約
- ここでは、企業が管理する Canonical および Ubuntu のクラウド、OpenStack、セキュリティ、サポート、管理対象インフラ、法的規約、Ubuntu Pro、および公開製品コミュニケーション用のページを通じて、Canonical Group Limited の評価を行っています。
- 本記事は、以前の Ubuntu Pro に関する記事とは異なるものです。Ubuntu と OpenStack をめぐるクラウド運用モデルや、バイヤーがオープンソース中心のプラットフォームを採用する際に残るデューデリジェンスのコスト（diligence cost）に焦点を当てています。
- 今回の情報源セットは、公開されている製品仕様やバイヤー側の疑問に関する議論を裏付けるものですが、顧客への導入実績、売上、人員規模、認証、稼働率、セキュリティ実績、プライベートインフラ、または施設の所有権を証明するものではありません。
ディレクトリリンク：Canonical Group Limited
Ubuntu は単なるサーバー上のイメージではない
Ubuntu は、クラウドワークロードの下にあるおなじみの Linux レイヤーとして、調達時の議論によく登場します。その簡略化した見方は便利ですが、実際の運用上の意思決定を覆い隠してしまいます。サーバーイメージ、クラウドディストリビューション、OpenStack 環境、および管理対象インフラ（managed infrastructure）の契約は、すべて管理スタックの異なる部分に位置しています。Canonical の公開ページ（https://canonical.com/およびhttps://ubuntu.com/）では、Ubuntu とそれに関連するエンタープライズインフラを中心に組織を位置づけていますが、より詳細なページ（https://ubuntu.com/cloudおよびhttps://ubuntu.com/openstack）を見ると、問題がオペレーティングシステムだけにとどまらない理由が分かります。
バイヤーにとって実質的な問いは、プラットフォームの選定後に責任がどこへ移行するかということです。Ubuntu をベースイメージとして使用する場合、アーキテクチャ、パッチ適用のタイミング、要塞化（hardening）、監視、インシデント対応は引き続き顧客側の責任となります。もし組織が Ubuntu のエコシステムに紐づいた OpenStack や管理対象インフラを採用する場合、その依存関係はより広範囲に及びます。クラウドのコントロールプレーン、アップグレードの頻度、期待されるサポート、セキュリティツールとの連携、および将来の選択肢を狭めることなく環境を運用するチームの能力にまで影響を与える可能性があります。
だからこそ、公開されている証拠が企業管理下のものであっても、Canonical はクラウドサービスへの依存関係に関する議論において考慮すべき対象となるのです。可視化されている製品仕様やインターフェースは、デューデリジェンスの問いを組み立てるのに十分なサービスおよび製品の境界を説明しています。ただし、それらはバイヤー側による検証の必要性をなくすものではありません。
管理対象インフラは労務費を変えるが、判断の必要性はなくならない
https://ubuntu.com/managedにある管理対象インフラのページが重要である理由は、議論の焦点をソフトウェアの可用性から運用の労力へと移すためです。管理対象サービス（managed service）は、顧客が直接実行しなければならないタスクの数を減らすことができます。一方で、顧客のアーキテクチャが、プロバイダーのプロセス、引き継ぎモデル、サポート言語、およびアップグレードの規律に対して、より依存するようになる可能性もあります。
このトレードオフはクラウド調達において重要です。通常、組織は単にベンダーのロゴを変えて同じワークロードを実行するためだけに管理対象インフラを購入するわけではありません。クラウドやプラットフォームのレイヤーにおいて、人材の確保、パッチ適用、一貫した運用を行うのが難しいために購入するのです。リスクとしては、社内の労務費を節約した分が、将来の選択肢（optionality）の減少、より慎重なベンダー調整、あるいは変更が急務な場合の制御権の低下といった形で現れる可能性がある点です。
Canonical の公開サポートページ（https://ubuntu.com/support）およびセキュリティページ（https://ubuntu.com/security）は、デューデリジェンスの対象範囲を定義するのに役立ちます。これらは、バイヤーが契約固有の確約を求める前に確認できる公開資料を示しています。しかし、公開ページからは、顧客の実際のレスポンス時間、エスカレーション履歴、本番環境の変更品質、またはサービスの適合性を確認することはできません。真剣に導入を検討するバイヤーは、どの職務が社内に残り、どの職務が Canonical に移行し、どの職務が遅延の発生しやすいチーム間の境界に位置するのかを、引き続きマッピングする必要があります。
OpenStack は、独立性を哲学的な問題からより運用上の問題へと変える
OpenStack は、ハイパースケールクラウドへの依存に対する解決策として議論されることがよくあります。Canonical の OpenStack ページは、この記事に具体的な視点を与えています。組織が OpenStack を重視するのは、クラウドインフラ、設置場所、コスト、連携、あるいはガバナンスに対する制御権を強化したいためです。その熱意は本物ですが、それは同時に新たな運用上の負担を生み出します。
プライベートクラウドや自社管理のクラウドインフラは、構成要素がオープンソースであるからといって自動的に動くわけではありません。運用チームは依然として、アップグレード、アイデンティティ、ストレージ、ネットワーキング、テレメトリ、容量計画（キャパシティプランニング）、セキュリティ境界、およびサービス復旧を管理する必要があります。そのスタックを取り囲むプロバイダーを利用することで導入の障壁は下がるかもしれませんが、バイヤーはクラウドのどの部分を誰が運用しているのかを正確に理解しなければなりません。
ここで、単なる「オープン対プロプライエタリ」の比較よりも、「ソフトウェアライフサイクルとベンダーロックイン」という視点を用いる方が適切になります。ロックインは単なるライセンス条項だけではありません。運用手順書（ランブック）、サポート経路、イメージの選択、自動化スクリプト、パッケージングの決定、スタッフのスキルといった「運用の慣習」のセットである場合もあります。もし企業が Canonical による Ubuntu クラウドや OpenStack へのアプローチを深く標準化した場合、基礎となるソフトウェアがポータブルに見えても、将来の移行コストは運用の中に埋め込まれることになるでしょう。
セキュリティページは一つの問いに答え、別の問いを生む
Ubuntu のセキュリティページ（https://ubuntu.com/security）は、バイヤーにとって公開情報から確認を始めるのに適した場所です。セキュリティ仕様は、ベンダーがメンテナンス、脆弱性対応、およびエンタープライズ向けの保証を読者にどう理解させたいかを示しているため、有用な情報です。サポートおよび Pro のページ（https://ubuntu.com/supportおよびhttps://ubuntu.com/pro）はさらに別のレイヤーを加えます。なぜなら、セキュリティとは単に機能の羅列だけではないからです。それは、スケジュールであり、契約であり、監視プロセスであり、組織の慣習そのものです。
これらの公開ページの限界を理解することも同様に重要です。これらのページは、特定の顧客環境が安全であることを証明するものではありません。すべてのアップデートが予定通りに適用されていることを証明するわけでもありません。インシデントが適切に処理されるか、インテグレーションがスムーズに行われるか、または顧客側のスタッフが共同責任（shared-responsibility）の境界を理解しているかを証明することもありません。したがって、本記事では、セキュリティに関する資料を本番環境における成果の測定指標としてではなく、公開されているデューデリジェンスの対象範囲を示す証拠として扱います。
より強固なバイヤー向け資料（ファイル）を作成するには、公開資料を、契約書の文言、社内のパッチ適用メトリクス、エクスポージャー（脆弱性露出）のインベントリ、アプリケーションの互換性テスト、特権アクセス管理、および復旧手順と比較する必要があります。Canonical の公開ドキュメントはこれらの問いを導くガイドにはなりますが、特定のデプロイメントにおけるすべての問いに直接答えてくれるわけではありません。
法的規約およびサポートの仕様も製品の一部である
ソフトウェアインフラのバイヤーは、製品ページと法的規約やサポートのページを切り離して考えがちですが、その切り離しにはリスクが伴います。公開されている法的規約のページ（https://ubuntu.com/legal）とサポートページ（https://ubuntu.com/support）は、顧客が何を信頼してよいか、何が公に文書化されているか、およびマーケティング文句以外の部分でバイヤーが交渉または検証すべき箇所はどこかを定義するのに役立つため、運用仕様（operating surface）の一部といえます。
クラウドやプラットフォームへの依存関係においては、目立つ機能リストよりもこの点の方が重要です。ワークロードは、製品の約束と運用上の責任との間の複雑なギャップで破綻します。イメージのアップデートは誰が行うのか？互換性のテストは誰が行うのか？サービスの監視は誰が行うのか？プラットフォームを変更する権限は誰にあるのか？脆弱性の対応期間は誰が処理するのか？サポートパスが変更された場合、移行費用は誰が負担するのか？公開ページはベンダーが提示しているトピックを示してくれますが、拘束力のある答えは通常、契約書、サービス定義書、および顧客自身のアーキテクチャ上の決定の中に存在します。
これが、本記事が法的実体としての Canonical Group Limited について裏付けのない主張を避けている理由でもあります。ディレクトリのスラッグは BTW の調査対象を示しており、Canonical と Ubuntu のページは公開されている技術仕様（technology surface）を提供しています。それら自体は、地域のスタッフ数、売上、施設の所有権、顧客数、プライベートデプロイ、または運用パフォーマンスを証明するものではありません。
オープンソースは一つの障壁を下げる一方で、デューデリジェンスの基準を引き上げる
Ubuntu のよく知られた魅力は、採用の障壁を下げる点にあります。チームはこれをテストし、広く運用し、大規模なエコシステムを通じてスキルを構築できます。クラウドインフラにおいて、そのオープン性は戦略的な強みとなり得ます。バイヤーが単一のプロプライエタリなスタックに依存するのを防ぎ、エンジニアに広範な運用知識の基盤を提供することができます。
しかし、オープンであることは、無償の保証と同義ではありません。バイヤーは引き続き、パッチ適用の規律、自動化の品質、バックアップ計画、オブザーバビリティ（可観測性）、アイデンティティ管理、および変更レビューを維持しなければなりません。もし組織が管理対象インフラやサポートを追加する場合、プロバイダーとの関係をガバナンス（統治）する必要もあります。OpenStack を運用する場合、独立するという目的が、その独立性を運用するために必要なスキル、プロセス、および予算と一致しているかどうかを理解しなければなりません。
それこそが、Canonical の公開クラウド仕様の背後にある運用コストです。コストはお金だけではありません。最初のインストール後、プラットフォームを可読な状態に維持する作業です。スタックのどの部分が標準化され、どの部分がカスタマイズされ、どの部分が顧客が直接制御できないベンダーのプロセスに依存しているかを把握する作業なのです。
以前の Ubuntu Pro の視点がクラウドの問題を埋もれさせてはならない
BTW はすでに Ubuntu Pro の観点から Canonical についての記事を掲載しています。その以前の視点は、フリート（システム群）のメンテナンスや、Linux システムを長期にわたってサポートし続けることの経済性に関するものでした。今回の記事は、ある意味では意図的に焦点を絞っており、別の意味ではより広範な内容を扱っています。焦点を絞っているというのは、Canonical について一般的なビジネス上の主張をしていないためです。広範であるというのは、クラウドインフラが、Ubuntu、OpenStack、サポート、セキュリティ、管理対象サービス、法的規約といった各仕様を、一つの「運用上の問い」へと統合しているためです。
この違いは、コンテンツの重複を管理する上で重要です。サーバーフリートに Ubuntu Pro を検討しているバイヤーは、アップデートの範囲やメンテナンスの経済性に焦点を当てるかもしれません。一方で、Ubuntu クラウド、OpenStack、または管理対象インフラを検討しているバイヤーは、プラットフォームがどのように運用されるか、変更時の説明責任（accountability）は誰が負うのか、およびアプローチが深く組み込まれた場合にどのように終了（脱却）オプションを維持するかを問い直さなければなりません。
両方の問いにおいて、同じ企業管理下の情報源グループが関わってくる可能性があります。しかし、これらを同じ記事として扱うべきではありません。クラウドに関する問いは、導入済みシステムの長期的なメンテナンス対象範囲に関するものだけでなく、インフラ全体にわたる運用管理権とライフサイクルロックインに関するものだからです。
より強固な証拠ファイルに含まれるべき内容
現在の情報源セットは、Canonical の公開クラウド、OpenStack、サポート、セキュリティ、管理対象インフラ、法的規約、および製品仕様を説明するのに十分な強度を持っています。より強固な証拠ファイルとするには、顧客固有 of 導入実績、測定された稼働率、サポート対応データ、契約条件、独立したセキュリティ評価、方法論を伴う移行ケーススタディ、公開インシデントの事後分析（ポストモーテム）、認証の詳細、および Canonical が運用する業務と顧客が運用する業務の明確な切り分けなどを追加する必要があります。
そのような証拠が揃うまでは、この記事は情報源に基づいた記述にとどまるべきです。「Canonical と Ubuntu の公開ページが、クラウドおよびインフラの運用仕様を明らかにしている」と言うことはできます。「OpenStack や管理対象インフラが、制御権、労働力、ロックインに関するデューデリジェンス上の問いを生み出している」と言うこともできます。しかし、「Canonical が特定の顧客成果をもたらす」、「特定のサービスレベルを満たす」、「特定の施設を所有している」、「名前の挙がっているデプロイメントを稼働させている」、あるいは「他プロバイダーよりも優れているか劣っている」と言うことはできません。
この抑制は、弱さではありません。これこそが、テクノロジー企業を有益に調査・報道する意義なのです。公開記録は、クラウド依存関係分析においてなぜ Canonical が重要なのかを示すには十分ですが、バイヤー自身によるアーキテクチャ、セキュリティ、および契約の検証の代わりとなるには不十分です。
画像の範囲と帰属
アイキャッチ画像は、一般的な編集上のインフラの背景としてのみ使用されている、実際の公開情報源からのサーバー室の写真です。これは、Canonical Group Limited、Canonical のスタッフ、Ubuntu システム、顧客の機器、Canonical の施設、セキュリティインシデント、管理対象サービスのデプロイ状況、または現在の運用状態を示すものではありません。本記事の主張は、画像からではなく、引用された Canonical および Ubuntu のページに基づいています。