2025年11月14日·1 分
クレイグ・マクラッキーとクラウドネイティブ：プラットフォーム思考が勝つ理由
クレイグ・マクラッキーのクラウドネイティブ普及における役割と、プラットフォーム思考がコンテナを信頼できる本番インフラへと進化させた実務的理由を解説します。
クレイグ・マクラッキーのクラウドネイティブ普及における役割と、プラットフォーム思考がコンテナを信頼できる本番インフラへと進化させた実務的理由を解説します。
チームが苦しむのはコンテナを起動できないからではありません。苦しむのは、それを何百個も安全に運用し、ダウンタイムなく更新し、壊れたときに復旧し、さらに機能を予定通り出し続けなければならないからです。
クレイグ・マクラッキーの「クラウドネイティブ」物語が重要なのは、それが派手なデモの自慢話ではないからです。コンテナが実際の環境で運用可能になるまでの記録です――インシデントが起き、コンプライアンスが存在し、ビジネスが予測可能な納品を必要とする環境です。
「クラウドネイティブ」は「クラウドで動かすこと」ではありません。頻繁にデプロイでき、需要に応じてスケールし、部品が壊れたときに素早く修復できるようにソフトウェアを構築・運用するためのアプローチです。
実際には通常こうなります：
初期のコンテナ採用はしばしば工具箱のようでした：チームはDockerを取り、スクリプトをつなぎ合わせ、オペレーションが追いつくことを願っていました。プラットフォーム思考はそれをひっくり返します。各チームが独自の本番パスを発明する代わりに、共有された「舗装された道（paved roads）」――安全で準拠し観測可能な方法が簡単でもあるプラットフォーム――を構築します。
この変化が「コンテナを動かせる」から「コンテナでビジネスを運用できる」への橋渡しです。
これは結果に責任を持つ人々のためです、単なるアーキテクチャ図ではなく：
あなたの目標がスケールでの確実なデリバリなら、この歴史から実践的な教訓が得られます。
クレイグ・マクラッキーは初期のクラウドネイティブ運動に関連する最も知られた名前の一人です。Kubernetes、Cloud Native Computing Foundation（CNCF）、そしてインフラをチケットや属人的知識の塊ではなく製品として扱うという考えに関する会話でよく参照されます。
正確に言う価値があります。マクラッキーが単独で「クラウドネイティブを発明した」わけではなく、Kubernetesも一人のプロジェクトではありません。KubernetesはGoogleのチームによって作られ、マクラッキーはその初期の努力の一部でした。
人々がしばしば彼に帰するのは、エンジニアリングの概念を業界全体が実際に採用できるものに変える助けをした点です：より強いコミュニティ作り、分かりやすいパッケージング、そして再現可能な運用慣行への推進です。
KubernetesとCNCFの時代を通じて、マクラッキーのメッセージは流行のアーキテクチャよりも、本番を予測可能にすることに重きを置いてきました。つまり：
「舗装された道」「ゴールデンパス」「プラットフォームを製品として扱う」といった表現に心当たりがあるなら、それらは同じ考えを指しています：正しいことを簡単にすることでチームの認知負荷を下げる。
この記事は伝記ではありません。マクラッキーは、コンテナ、オーケストレーション、エコシステム構築というソフトウェア提供を変えた三つの力の交差点にいる参照点として有用です。ここでの教訓は個人の性格についてではなく、プラットフォーム思考が本番でコンテナを動かす鍵になった理由についてです。
コンテナは「クラウドネイティブ」というラベルが一般化する前から魅力的なアイデアでした。日常的には、コンテナはアプリケーションとその依存ファイル・ライブラリを一緒にパッケージ化し、異なるマシンで同じように動くようにする方法です――すべての部品を封入した箱で製品を出荷するようなものです。
初期の多くのチームはコンテナをサイドプロジェクト、デモ、開発者ワークフローで使っていました。新しいサービスを素早く試す、テスト環境を立てる、引き渡し時の「自分の環境では動く」の驚きを避けるのに適していました。
しかし、数個のコンテナから24/7で動く本番システムへ移すのは別物です。ツール自体は存在しましたが、運用に関する話は不完全でした。
よくある問題はすぐに現れました：
コンテナはソフトウェアのポータビリティを高めましたが、ポータビリティだけで信頼性が保証されるわけではありません。チームは一貫したデプロイ慣行、明確なオーナーシップ、運用上のガードレールを必要としました――そうでなければコンテナ化されたアプリは一度動くだけで終わってしまいます。
プラットフォーム思考とは、企業がインフラを単発のプロジェクトとして扱うのをやめ、内部プロダクトとして扱い始める瞬間です。「顧客」は開発者、データチーム、ソフトウェアを出荷するあらゆる人です。プロダクトの目標はサーバーやYAMLの枚数ではなく、アイデアから本番までの道筋を滑らかにすることです。
本物のプラットフォームには明確な約束があります：「これらの道筋で構築・デプロイすれば、信頼性、セキュリティ、予測可能なデリバリが得られる」。その約束はプロダクト習慣を必要とします――ドキュメント、サポート、バージョニング、フィードバックループ。ユーザー体験も意図的である必要があります：妥当なデフォルト、舗装された道、そして本当に必要なときのための脱出口。
標準化は意思決定疲労を取り除き、偶発的な複雑さを防ぎます。チームが同じデプロイパターン、ログ、アクセス制御を共有すれば、問題は再現可能になり、したがって解決可能になります。オンコールの受け渡しは改善され、インシデントは見慣れたものになります。セキュリティレビューは速くなります。なぜならプラットフォームがガードレールを組み込み、各チームに再発明させる必要がなくなるからです。
これは皆を同じ箱に押し込むことではありません。ビジネスを差別化する20%にエネルギーを使えるよう、80%を退屈にすることに合意するという話です。
プラットフォームアプローチが浸透する前、インフラは特殊な知識に依存していることが多く、数人だけがどのサーバーがパッチ済みか、どの設定が安全か、どのスクリプトが「正しいか」を知っていました。プラットフォーム思考はこれをテンプレート、自動プロビジョニング、開発から本番まで一貫した環境といった再現可能なパターンで置き換えます。
うまくやれば、プラットフォームは書類仕事を増やさずにガバナンスを改善します。ポリシーは自動チェックになり、承認は監査可能なワークフローになり、コンプライアンス証跡はチームがデプロイするたびに生成されます――組織は遅くすることなく統制を得ます。
コンテナはアプリをパッケージして出荷するのを簡単にしました。難しいのは出荷後の部分です：どこで動かすか、健康を保つか、トラフィックやインフラが変わったときに適応するか。
そのギャップを埋めたのがKubernetesです。コンテナの塊を、サーバーが故障し、リリースが行われ、需要が急増しても日々運用できるものに変えました。
Kubernetesはよく「コンテナオーケストレーション」と表現されますが、実務的な問題はさらに具体的です：
オーケストレータがないと、チームはこれらの振る舞いをスクリプト化し、例外を手作業で管理し続けることになります――そしてスクリプトが現実に追いつかなくなります。
Kubernetesは「このサービスを3つ動かす」といった望む状態を宣言する一元的なコントロールプレーンの考え方を普及させました。プラットフォームはその意図と現実を継続的に一致させようと働きます。
責任範囲の大きなシフトです：
Kubernetesはコンテナが流行したから出てきたのではありません。大規模なフリートを運用して得た教訓から生まれました：フィードバックループを持つシステムとしてインフラを扱うという運用マインドセットこそが、コンテナを「運用できる」ものにしたのです。
クラウドネイティブは単に新しいツールを導入しただけではなく、ソフトウェア出荷のリズムを変えました。チームは「手作りのサーバーと手動のランブック」からAPI、オートメーション、宣言的設定で駆動されるシステムへ移りました。
クラウドネイティブなセットアップはインフラをプログラム可能とみなします。データベースやロードバランサ、環境が必要なら、手動で待つのではなく望む状態を記述し、オートメーションに作らせます。
重要な変化は宣言的設定です：望む状態を定義すると（「このサービスを3つ動かす、このポートで公開する、メモリをXに制限する」）、プラットフォームがその状態に一致するよう継続的に働きます。これにより変更はレビュー可能で再現可能になり、ロールバックも容易になります。
従来のデリバリは稼働中サーバーのパッチ適用を伴い、時間とともに各マシンが少しずつ異なる「ドリフト」を生み出しました。
クラウドネイティブはイミュータブルデプロイを推進します：アーティファクト（多くはコンテナイメージ）を一度ビルドし、それをデプロイし、変更があるときは既存を修正するのではなく新しいバージョンをデプロイします。自動ロールアウトとヘルスチェックと組み合わせると、ワンオフ修正による「謎の障害」は減ります。
コンテナは多数の小さなサービスを一貫してパッケージ・実行するのを容易にし、マイクロサービスアーキテクチャを促進しました。一方でマイクロサービスは監視、ネットワーキング、バージョン管理、インシデント対応などの運用負荷を増やします。クラウドネイティブはその複雑さを管理するのに役立ちますが、消し去るものではありません。
標準的なデプロイプリミティブやAPIに基づくことでポータビリティは向上しました。しかし「どこでも動く」には依然として作業が必要です。セキュリティ、ストレージ、ネットワーキング、マネージドサービスの違いは重要です。クラウドネイティブはロックインと摩擦を減らすものであって、完全に無くすものではありません。
Kubernetesが広まったのは単に強力だったからだけではありません。中立的な居場所、明確なガバナンス、競合企業が一企業にルールを握られず協力できる場があったからです。
Cloud Native Computing Foundation（CNCF）は共有のガバナンスを作りました：オープンな意思決定、予測可能なプロジェクト手順、公開ロードマップ。これはコアインフラに賭けるチームにとって重要です。ルールが透明で単一ベンダーのビジネスモデルに紐づいていないと、採用のリスクが低く感じられ、貢献もしやすくなります。
CNCFがKubernetesや関連プロジェクトをホストすることで、「人気のあるオープンソースツール」を長期的なプラットフォームへと変えるのに寄与しました。具体的には：
クラウドプロバイダー、スタートアップ、エンタープライズ、独立エンジニアなど多くの貢献者と共に、Kubernetesはネットワーキング、ストレージ、セキュリティ、Day-2運用といった現実世界の方向に速く進化しました。オープンAPIと標準はツールの統合を容易にし、ロックインを減らし、本番利用への信頼を高めました。
CNCFはサービスメッシュ、イングレスコントローラ、CI/CDツール、ポリシーエンジン、可観測性スタックなどのエコシステム爆発を促しました。豊富さは強みですが重複も生みます。
多くのチームにとっては、よくサポートされる小さなコンポーネントを選び、相互運用性を重視し、所有範囲を明確にすることが成功の鍵です。「すべてベスト」のアプローチは保守負担を生むだけのことが多いです。
コンテナとKubernetesは「どうやってソフトを動かすか」の大きな部分を解決しましたが、自動的により難しい問い「実際のユーザーが来たときにどう維持するか」は解決しませんでした。欠けていた層は運用上の信頼性です――明確な期待、共有慣行、正しい振る舞いをデフォルトにするシステムです。
チームは素早く出荷できても、プロダクションベースラインが定義されていなければ一回の誤ったデプロイで混乱が起きます。最低でも必要なのは：
これがないと各サービスが独自のルールを作り、信頼性は運任せになります。
DevOpsやSREは所有、オートメーション、測定された信頼性、インシデントから学ぶ習慣といった重要な習慣を導入しました。しかし習慣だけでは何十ものチームや何百ものサービスにスケールしません。
プラットフォームはそれらの慣行を再現可能にします。SREは目標（SLOなど）とフィードバックループを設定し、プラットフォームはそれを満たす舗装された道を提供します。
信頼できるデリバリには通常、一貫した能力セットが必要です：
良いプラットフォームはこれらのデフォルトをテンプレート、パイプライン、ランタイムポリシーに組み込みます：標準ダッシュボード、共通アラートルール、デプロイガードレール、ロールバック機構。これが信頼性を任意ではなく、ソフトウェアを出荷することで得られる予測可能な成果に変えます。
クラウドネイティブツールは強力ですが、多くのプロダクトチームには「過剰」に感じられることがあります。プラットフォームエンジニアリングはそのギャップを埋めます。使命は単純です：アプリケーションチームが機能を出荷する際にパートタイムのインフラ専門家にならずに済むよう認知負荷を下げること。
良いプラットフォームチームは内部インフラを製品として扱います。明確なユーザー（開発者）、明確な成果（安全で再現可能なデリバリ）、フィードバックループを持ちます。Kubernetesのプリミティブの山を渡す代わりに、意見付きの方式でサービスの構築・デプロイ・運用を提供します。
実践的な視点としては「開発者がアイデアから稼働サービスまで何件ものチケットを開かずに行けるか？」と問うことです。そのワークフローを圧縮するツールはクラウドネイティブプラットフォームの目標に合致します。
ほとんどのプラットフォームはデフォルトで選べる再利用可能な「舗装された道」の集合です：
目的はKubernetesを隠すことではなく、事故的複雑さを防ぐ妥当なデフォルトにパッケージすることです。
この文脈で、Koder.aiはチャット経由で内部ツールやプロダクト機能を素早く立ち上げ、必要に応じてソースコードをエクスポートして正式なプラットフォームに統合するようなチーム向けの「DXアクセラレータ」層として使えます。プラットフォームチームにとっては、そのプランニングモードや組み込みのスナップショット／ロールバックが、本番のワークフローで望む信頼性優先の姿勢を反映できます。
どの舗装された道もトレードオフを伴います：一貫性と安全性は上がりますが、ワンオフの選択肢は減ります。プラットフォームチームは次を提供するのが最良です：
新しいエンジニアのオンボーディングが速い、ベスポークなデプロイスクリプトが減る、スノーフレークなクラスタが減る、インシデント時のオーナーシップが明確になる――といった計測可能な変化が見えればプラットフォームは機能しています。チームが「このサービスの責任者は誰で、どうやって出荷するか」をミーティングなしで答えられるなら、プラットフォームは役目を果たしています。
クラウドネイティブはデリバリを速くし、運用を落ち着かせる力がありますが、チームが何を改善したいのか明確であるときにのみ効果を発揮します。多くの停滞はKubernetesやそのエコシステムを目的にしてしまうことから生じます。
よくある失敗は、短縮リードタイム、インシデント減少、環境の一貫性といった明確な目標なしにKubernetesを採用することです。結果として多くの移行作業が発生しますが目に見える成果は出ません。
成功基準を事前に定めないと、どのツールを選ぶか、どれだけ標準化するか、プラットフォームが「完成」したかどうかが主観的になります。
Kubernetesは基盤であり完全なプラットフォームではありません。チームはサービスメッシュ、複数のイングレスコントローラ、カスタムオペレータ、ポリシーエンジンなどをすぐに追加しがちで、境界や所有権が曖昧になります。
過度のカスタマイズも罠です：独自のYAMLパターン、手作りテンプレート、元の作者しか理解しないワンオフの例外が増えます。複雑さが増し、オンボーディングが遅れ、アップグレードが危険になります。
クラウドネイティブはリソース作成を容易にしますが、放置も容易です。クラスタの増殖、使われない名前空間、過剰プロビジョニングがコストを静かに膨らませます。
セキュリティの落とし穴も同様です：
1〜2のスコープの狭いサービスから始めましょう。早期に標準（ゴールデンパス、承認済みベースイメージ、アップグレードルール）を定義し、プラットフォームの表面積を意図的に制限します。
デプロイ頻度、平均復旧時間、開発者の初回デプロイまでの時間といった成果を測定し、それらを動かさないものは任意扱いにします。
「クラウドネイティブを採用する」ことは一度きりの動作ではありません。成功するチームはマクラッキー時代に結び付けられる同じ核心的な考えに従います：正しい方法を簡単な方法にするプラットフォームを構築すること。
小さく始めて、うまくいったことをコード化します。
新しいワークフローを試すときの有用なパターンは、標準化する前にエンドツーエンドで「ゴールデンパス」体験をプロトタイプすることです。たとえば、チームがKoder.aiを使ってチャット経由で動作するWebアプリ（React）、バックエンド（Go）、DB（PostgreSQL）を素早く生成し、その結果のコードベースをプラットフォームのテンプレートやCI/CD規約の出発点とすることができます。
ツールを追加する前に自問してください：
ツール使用ではなく成果を追跡しましょう：
良い「プラットフォームMVP」のパッケージ例を見たい場合は /blog を参照してください。予算と導入計画については /pricing も参考にできます。
過去十年の大きな教訓はシンプルです：コンテナが「勝った」のは巧妙なパッケージングのせいではなく、プラットフォーム思考がそれらを信頼できるものにしたからです――再現可能なデプロイ、安全なロールアウト、一貫したセキュリティ制御、予測可能な運用。
次の章は単一の画期的なツールの話ではありません。クラウドネイティブを「良い意味で退屈」にすることがテーマです：驚きが少なく、ワンオフ修正が減り、コードから本番までの道筋が滑らかになること。
ポリシーをコード化することがデフォルトになる。 各デプロイを手動でレビューする代わりに、セキュリティ、ネットワーク、コンプライアンスのルールをコード化してガードレールを自動化・監査可能にします。
開発者体験（DX）がプロダクトとして扱われる。 テンプレート、セルフサービス環境、明確なゴールデンパスにより、認知負荷を下げつつ自律性を損なわないことに注力が移ります。
より少ないダッシュボードでシンプルな運用を。 ベストなプラットフォームは複雑さを隠します：意見付きデフォルト、少ない可動部品、組み込まれた信頼性パターン。
チームが機能ではなく成果を追わない限りクラウドネイティブの進展は遅くなります。新しいツールがリードタイムを短くする、インシデント率を下げる、セキュリティ姿勢を改善する、いずれかを説明できないなら優先度は低いでしょう。
現在のデリバリの痛点を評価し、それらをプラットフォームの必要性にマッピングしてください：
これらの答えをプラットフォームのバックログとして扱い、チームが週ごとに感じる成果で成功を測定してください。
クラウドネイティブとは、ソフトウェアを頻繁にデプロイでき、需要が変化したときにスケールでき、そして障害から素早く回復できるように構築・運用するアプローチです。
実際には、コンテナ、オートメーション、小さなサービス群、そして実行中のシステムを観測・保護・ガバナンスする標準的な方法を含むことが多いです。
コンテナはソフトウェアを一貫して出荷する手段を提供しますが、安全なアップグレード、サービスディスカバリ、セキュリティ制御、持続的な可観測性など本番で必要な難問を自動的に解決するわけではありません。
問題は少数のコンテナから数百台が24時間稼働する世界へ移行したときに顕在化します。
「プラットフォーム思考」とは、内部インフラを開発者という**ユーザーを持つ製品（内部プロダクト）**として扱うことを指します。明確な利用者と約束（安全で再現可能なデリバリ）が存在します。
各チームが独自に本番への道筋を作る代わりに、組織は**共通の舗装された道（paved roads／ゴールデンパス）**を整備して、妥当なデフォルトとサポートを提供します。
Kubernetesは「コンテナの山」を日常的に運用できるシステムに変えるためのオペレーショナルレイヤーを提供します：
さらに、意図（desired state）を宣言する共通のコントロールプレーンを導入します。
宣言的設定（declarative configuration）は、手順ではなく望む状態を記述することを意味します。
実務的な利点は：
イミュータブルデプロイは、稼働中のサーバーをパッチする代わりにアーティファクトを一度ビルドしてそれをそのままデプロイするという方針です。
変更が必要なときは新しいバージョンをデプロイし、既存の実行系を直接変更しません。これにより構成ドリフトが減り、障害の再現やロールバックが容易になります。
CNCFはKubernetesや関連プロジェクトに中立的なガバナンスの場を提供し、コアなインフラに賭けるリスクを下げました。
具体的には：
これが採用を加速し、相互運用可能なエコシステムの成長を後押ししました。
プロダクションベースラインとは、信頼性を予測可能にするための最低限の能力と慣行の集合です。主な要素は：
これがないと各サービスが独自ルールを作り信頼性が運任せになります。
プラットフォームエンジニアリングは、クラウドネイティブの基本要素を意見付きのデフォルトとしてパッケージ化し、アプリケーションチームの認知負荷を下げることに注力します：
目的はKubernetesを隠すことではなく、安全な道を最も簡単な道にすることです。
よくある落とし穴：
回避策：1～2サービスから始めて、得られた教訓をプラットフォームMVPに落とし込む。プラットフォームの表面積を意図的に小さく保ち、成果（リードタイム、デプロイ頻度、MTTR、SLO）を測ること。