複数チームでKubernetes（コンテナオーケストレーション基盤）を運用していると、障害対応のたびに「これは開発チームの責任か、運用チームの責任か」を確認する場面に出くわします。この記事では、そうした責任境界の曖昧さを技術的に解決しようとするHariKubeというプロジェクトの主張を手がかりに、SLO設計やIaC運用の現場でどう応用できるかを整理します。
HariKubeの開発者は、業界の課題を「技術の不足ではなく、境界の不足」だと表現しています。開発者がインフラの面倒を見て、運用担当がアプリ固有のロジックを直したり、プラットフォームチームが内部プロダクト開発とサポート対応を同時にこなしたりする状況です。DevOps（開発と運用を協調させる文化・手法）という言葉のもとで、実際には責任の境界線が曖昧になっただけ、という指摘は多くの現場で心当たりがあるはずです。
「契約」という考え方の分解
HariKubeが提案するのは、開発者と運用者の間に「機械的に検証可能な契約」を置くという発想です。開発者は「何をしたいか」を宣言し、運用者は「どんな条件下でそれを許可するか」を定義し、プラットフォームがその意図を検証・記録・実体化します。
これは口頭合意やWikiページ、チームごとにバラバラに書かれた連携コードに頼るのではなく、共通の宣言的モデル（望む状態を記述し、システムがそこに近づける方式）で表現される点がポイントです。
SREの文脈に置き換えると、これはSLO（Service Level Objective、サービスが満たすべき品質目標）とエラーバジェット（許容できる障害の余地）の関係に近い構造だと理解できます。SLOは「開発者がどこまでリリース速度を優先してよいか」「運用者がどの時点でリリースを止める権限を持つか」を数値で契約化する仕組みです。口頭で「無理のない範囲で」と伝えるのではなく、可用性99.9%やレイテンシp95が300ms以内といった具体的な閾値で境界を機械可読にする、という発想はHariKubeの主張と重なります。
IaCとの比較で見える境界の実装方法
TerraformやPulumiといったIaC（Infrastructure as Code、インフラをコードで宣言的に管理する手法）は、まさに「宣言的モデルによる責任分界」をすでに部分的に実現しているツールです。
たとえばTerraformでは、開発チームが利用するモジュールの入力変数（variable）と、運用チームが管理するプロバイダー設定やポリシー（Sentinel、OPA/Conftestなどのポリシーエンジン）を分離できます。開発者は「このサイズのインスタンスが欲しい」と宣言し、運用者は「本番環境ではt3.large以上は事前承認が必要」といったガードレールをポリシーとして定義する、という役割分担です。
HariKubeが指摘しているのは、この宣言的モデルの適用範囲がKubernetesの外側、つまり業務ロジックやAIワークロード、サーバーレス関数などにまで及んでいない、という点です。状態管理・検証・認可・整合性モデル・監査可能性・イベント伝播といった要素を、業務プロセスごとに毎回自前で組み立て直している現状への問題提起といえます。
オブザーバビリティと障害対応の仕組み化への影響
責任境界が曖昧なままだと、オブザーバビリティ（システム内部の状態を外部から観測可能にする設計）を整備しても効果が半減します。メトリクス・ログ・トレースを揃えても、「このアラートは誰が一次対応するか」が決まっていなければ、結局Slackでのメンション合戦になりがちです。
障害対応をランブック（対応手順書）やPagerDutyのエスカレーションポリシーで仕組み化する取り組みは、まさに「契約の明文化」の一種です。HariKubeの主張する「機械的に検証可能な契約」は、これをさらに一歩進め、対応範囲そのものをコードや設定として管理し、人手による解釈の余地を減らそうとする方向性だと捉えられます。
コスト最適化の観点でも同様です。誰がリソースのスケールダウン判断を下すか、誰がコスト超過のアラートに責任を持つかが曖昧だと、FinOps（クラウドコストの財務的最適化を組織横断で行う実践）の取り組みは形骸化しやすくなります。責任境界を先に固定し、そのうえでコスト削減の権限と条件を宣言的に定義する順序が重要になります。
読者が今日確認できること
HariKube自体はまだ発展途上のプロジェクトであり、GitHubリポジトリやドキュメントで実装の詳細や対応バージョンを確認する必要があります。導入を検討する前に、まず自分たちの組織の「境界」がどこにあるかを棚卸しすることが実践的な第一歩です。
具体的には、以下の点を見直してみると現状把握につながります。
- SLO文書に「誰がリリースを止める権限を持つか」が明記されているか確認する
- TerraformのCODEOWNERSファイルやモジュール構成が、開発チームと運用チームの責任分界と一致しているか見直す
- ポリシーエンジン（OPA、Sentinel、AWS Config Rulesなど）で強制されているルールが、口頭合意だけの部分と混在していないか棚卸しする
- インシデント対応のエスカレーションフローで、一次対応者の判断範囲が数値や条件で定義されているか確認する
- コスト超過時のアラート先と、実際にスケールダウンを実行できる権限者が一致しているか確認する
これらはHariKubeを導入するかどうかに関わらず、既存のTerraform/Pulumi構成やSLOダッシュボードを点検する材料になります。
まとめ
HariKubeの主張は、Kubernetesのスケーリングやコスト削減という表面的な課題の奥に、「責任境界の不在」という組織的な問題があるという指摘です。
SRE・インフラの実務に引き寄せると、これはSLOのエラーバジェット運用、IaCのポリシー分離、障害対応のエスカレーション設計という、すでに存在する仕組みの延長線上にある課題だと整理できます。
次のアクションとしては、自組織のSLO文書とTerraformのモジュール構成を突き合わせ、「宣言する側」と「承認・検証する側」の境界が実際にコードやポリシーとして表現されているかを確認してみることをおすすめします。曖昧な部分が見つかれば、それがまさに次に手を入れるべき箇所です。