【クラウドネイティブ会議】AI時代のPlatform Engineeringはどう変わるのか――開発速度と品質を両立するGuardrails設計

AI Codingの普及により、ソフトウェア開発では、変更を生み出す主体が人間からAgentへと広がりつつある。開発速度が高まる一方で、人間の認知範囲を超える変更をどう安全に受け止めるかが問われている。クラウドネイティブ会議で、株式会社リクルートのソフトウェアエンジニアである菅沼孝二氏は「AI時代のPlatform Engineering 攻めと守りの開発手法を両立するガードレール設計のプラクティス」と題し、AI時代のPlatform Engineeringに求められる役割を語った。

Platform Engineeringは、利用者の生産性をスケールさせる仕組み

登壇したリクルート ソフトウェアエンジニアの菅沼孝二氏はまず、Platform Engineeringの役割を整理した。菅沼氏にとってPlatformとは、「利用者の生産性をスケールさせる仕組み」である。ここでいう生産性は、個々の利用者の創出力と、組織横断の規模の掛け算で捉えられる。

そのための中核となるアプローチが、認知負荷の削減、標準化と自動化、そして境界設計である。利用者が価値創出に集中できる状態をつくり、反復作業や手戻りを排除し、何を見せ、何を見せないかを設計する。これがPlatform Engineeringの基本的な役割だという。

リクルートでは、この10年にわたり、データアプリケーション開発向けのInternal Developer Platformを運営してきた。利用者数の増加に対してプラットフォームエンジニアの工数がボトルネックになる一方、利用者側でも、認知負荷によって個々の創出力が制約されていた。

これに対し、同社が中心に据えたのがGolden Pathsであった。開発体験の改善やセルフサービス化により、利用者の自律性を高め、プラットフォームエンジニアへの依存を減らす。同時に、抽象化レイヤーや標準化によって認知負荷を下げ、利用者が本来の開発に集中できる状態をつくってきた。「人間主体時代の生産性律速は、Golden Pathsを中心とした取り組みで一定程度解決してきたと考えています」と菅沼氏は語った。

我々の10年の取り組み─Golden Pathsを中心とした生産性のスケール

人間が変更主体だった時代には、Golden Pathsによって生産性を高めることができていた。しかしAI Codingの登場により、変更を起こす主体にAgentが加わりつつある。

AI時代には、変更生成量が人間の認知範囲を超える

Agentが変更主体に加わることで、Platform Engineeringが向き合う前提も変わる。人間は認知容量や物理的時間によって律速される。一方Agentは並列、高頻度、大規模、持続的に動くことができる。Golden Pathsを整備した組織であれば、Agentの登場により、利用者組織全体の生産性はさらに拡大し得る。

だが、同時に新しい問題も立ち上がる。AI時代には、Agentによって変更生成量が桁違いに拡張する。人間の認知範囲もAI補助である程度広がる可能性はあるが、生成量の拡大ペースには追いつかない。結果として、変更生成量と人間の認知範囲との間に構造的なギャップが生まれる。

利用者の主体が、人間からAgentに拡張されつつある

菅沼氏は、変更プロセスの圧縮や喪失にも言及した。人間時代には、実装前のチーム内議論を通じて、変更内容に関する暗黙の認知が形成されていた。ところがAI時代には、Agentとの対話によって個人に閉じた形で変更が生成される。その結果、レビュアーはレビュー段階で「初対面の変更」を大量に処理することになる。

AI時代の問題は、単にコードが増えることではない。変更生成量が人間の認知範囲を構造的に超え、さらに変更に至る文脈まで見えにくくなることにある。

認知範囲を超える変更に備え、Guardrailsを拡張・深化する

この構造変化により、既存のGuardrailsにも限界が生じる。菅沼氏によれば、従来のGuardrailsは、生成物が人間による認知範囲内にあるという前提のもとで設計されてきた。人間がレビューし、議論し、理解できる範囲に変更が収まっているのであれば、既存のレビューや承認、テストでも一定の品質担保が可能だった。

しかしAI時代には、変更生成量が認知範囲を超える。Agentが大量のプルリクエストを生成し、人間がレビューしきれないまま、ハルシネーションやわずかなバグを見逃して本番へ反映してしまう可能性が高まる。菅沼氏は、こうした事象の発生頻度や確率が構造的に上昇すると指摘した。

そのため、Guardrailsの役割範囲をより広く、設計の深さをより深く拡張する必要がある。Guardrailsは、単に開発速度を抑えるためのルールではない。AIが生み出す量と速度を前提に、それを安全に受け止めるためのPlatformの中核機能として設計し直す必要がある。「ガードレールの役割範囲と深さの大幅な拡張が、AI時代のPlatformにおける中核機能になると捉えています」と菅沼氏は語った。

AI時代のPlatform中核機能─Guardrailsの拡張・深化

AI時代のPlatform Engineeringでは、開発速度を抑え込むのではなく、速度を受け止めるためにGuardrailsの役割範囲と設計の深さを広げることが求められる。

3つの柱で、攻めと守りを両立するPlatformを育てる

では、具体的にどのようなGuardrailsが必要なのか。菅沼氏は実践プラクティスとして、3つのGuardrails Pillar（柱）を紹介した。Pillar 1はRepo・CI/CD、Pillar 2はTest、そしてPillar 3がObservabilityである。

Pillar 1のRepo・CI/CDでは、変更の影響範囲に応じて設計を変える。アプリケーション層の変更は単一サービスに閉じる一方、高頻度かつ大量に発生する。ここに重い承認を強制すれば、AI活用による速度を活かせない。一方、基盤層の変更は影響が広範囲に波及する可能性がある。そこでリポジトリを物理的に分離し、CI/CDで厳格性の置き場所を変える。局所変更は軽量に流し、広域変更は厳格に検証するのである。

Pillar 2はTestである。AIが生成する変更は大量かつ高速であり、レビューの密度は下がりやすい。また、AIが書いたコードが資産として蓄積されれば、誰も完全には把握していない領域が増えていく。そこで菅沼氏は、Shift LeftとShift Rightを組み合わせる考え方を示した。静的解析、単体テスト、結合テスト、性能テストなどで早期に欠陥を検出しつつ、カナリアリリース、A/Bテスト、シンセティックテストなどで本番環境に近い挙動を観測する。

Pillar 3はObservabilityである。AIが生成した変更では、副作用が量と因果の両面で人間の認知範囲を超える。そこでインフラ、ミドルウェア、アプリケーション、データまでを縦に見るFull-stack Observabilityと、データ収集から処理、配信、利用までを横に追うEnd-to-End Observabilityを組み合わせる。これにより、AIによる変更がどこに、どのような副作用を起こしたのかを早期に検知し、原因特定につなげる。

ただしGuardrailsは銀の弾丸ではない。菅沼氏は、基盤のリアーキテクチャにともなうアプリケーション移管時の障害事例も紹介した。AIを活用して移管を進めた際、特定のAPIアプリケーションで、レスポンスボディが空になる事象が発生した。エラーは出ておらず、移管対象のアプリケーションも多かったため、当時は正常に完了したと誤認してしまったという。

テストでは想定範囲内のリクエストには応答できていたが、想定範囲外のリクエストで問題が発生した。Observabilityでも、エラーレート、レイテンシ、RPS、CPU、メモリなどは監視していたが、レスポンスボディのバイトサイズ変化は対象外だった。この経験から、菅沼氏はGuardrailsを完璧なものとして盲信するのではなく、障害から学び、Platform as a Productの思想で継続的に改善する重要性を強調した。

継続的改善を支えるのはPlatform as a Product思想

最後に菅沼氏は、AI時代に変わるものと、変わらないものを整理した。変わるのは、変更主体が人間中心から人間とAgentの協働へ広がること、人間が認知すべき対象が認知範囲を超える領域へ広がること、そしてPlatformの中核機能としてGuardrailsの重みが増すことである。一方で、利用者が価値創出に集中できる状態を組織横断でスケールさせるという目的、境界を設計するという構造、人間が担う意思決定やコンテキスト解釈、最終責任は変わらない。

そのうえで菅沼氏は、最後に3つの問いを示した。変えていくべきものを認識できているか。変わらないもの、そして変えてはいけないものを言語化できているか。そしてその両立の仕組みをどのように実現できるか、という問いである。

菅沼氏は、これらの問いが、参加者自身の組織や運営するPlatformにおいて、AI時代のPlatform Engineeringをどのように考えるべきかを見直すきっかけになれば幸いだと語り、セッションを締めくくった。AI時代のPlatform Engineeringでは、Agentの速度を止めるのではなく、その速度を価値に変えるための仕組みを、継続的に育てていくことが求められている。