AI の時代におけるプラットフォームエンジニアリングに関するプレゼンテーション

https://www.infoq.com/ は InfoQ のホームページです。

プレゼンテーション

AI 時代のプラットフォームエンジニアリング

プレゼンテーションを見る

再生時間:

01:01:07

/presentations/ai-platform-engineering-roundtable/en/slides/slide-1788861390827.jpg)

概要

パネリストたちは、プラットフォームチームが AI を活用したエンジニアリングをどのようにサポートするかを説明し、どの機能をプラットフォームに統合すべきかを解説します。標準化と開発者の自律性の間のトレードオフについて議論し、AI ツールの管理やセキュリティのガードレール、変化するワークフローへの対応策についても共有しました。

パネリスト紹介

ステファノ・ディ・チェーザレ氏は、ドイツのオンライン銀行 DKB のプラットフォームエクスペリエンスチームに所属するシニアプラットフォームエンジニアです。ダヴィデ・デ・パオリス氏は、Sevdesk でエンジニアリングマネージャーを務めるとともに AWS コミュニティビルダーでもあります。スティーブン・チハク氏は Harness のフィールド CTO です。カミラ・マセド氏はシニアソフトウェアエンジニア兼コンサルタントです。レナート・ロージョ氏は InfoQ のスタッフエディターであり、クラウドの専門家かつ AWS Data Hero です。

開催概要について

InfoQ Live は、現代のソフトウェア実践者であるあなたのために設計されたバーチャルイベントです。変化とイノベーションを推進する素晴らしいスピーカーから学びましょう。

INFOQ EVENTS

プレゼンテーション：AI 時代のプラットフォームエンジニアリング

• 2026 年 9 月 17 日 午後 1 時（EDT） ## PR を超えて：エージェント型ソフトウェアデリバリーの新たなコントロールプレーン 登壇者：Harness の Staff Product Manager、Mohit Suman 氏

• 2026 年 10 月 8 日 正午（EDT） ## AI が開発を加速させる中、CI パイプラインは追いつけるか？ 登壇者：Datadog の Software Delivery 担当 Product Marketing Manager、Eric Metaj 氏および CI/CD Optimization 担当 Product Manager、Rohin Chandra 氏

講演要旨

レナート・ロジオ：本セッションでは、AI の時代におけるプラットフォームエンジニアリングについて議論します。このラウンドテーブル形式の対談では、内部プラットフォームがどのように進化しているか、そして AI が次世代のプラットフォームエンジニアリングにどのような変化をもたらすかを掘り下げます。

私は InfoQ の編集者であるレナート・ロジオです。本日は、異なる分野や背景、国から集まった 4 名の専門家をお迎えし、プラットフォームエンジニアリングの実態とその進化についてそれぞれの経験に基づいたお話を伺います。まずは各パネリストに自己紹介と、ご自身のキャリアの軌跡をご紹介いただきたいと思います。

ダヴィデ・デ・パオリス氏： 私はダヴィデ・デ・パオリスです。現在は Shine でエンジニアリングマネージャーを務めており、以前は sevDesk に在籍していました。現在、AWS 上のインフラチームを率いており、10 名のメンバーを指揮してヨーロッパ全域の 25 チームをサポートしています。

私のキャリアは 20 年以上前に、今では伝説的な「Flash サイト」の開発から始まりました。その後、技術スタックや言語を進化させ、10 年以上前に AWS にたどり着きました。Lambda やサーバーレス技術にはまり、これが今も私の大好きな分野です。その後は主にプラットフォームエンジニアリングチームのテクニカルリードおよびエンジニアリングマネージャーとしてキャリアを積み重ねてきました。

また、AWS コミュニティビルダーとして 5 年目を迎え、ブログ執筆や登壇活動も行っています。ヨーロッパ各地を飛び回り、私が最も熱意を持って語るトピックを発信しています。

ステファノ・ディ・チェザーレ氏： 私はステファノ・ディ・チェザーレです。ドイツの大手オンライン銀行 DKB で働いています。約 500 万人の顧客にサービスを提供しており、インフラプラットフォーム部門で活躍しています。特に「プラットフォーム体験」に注力し、ユーザーがプラットフォームに対して満足感を持てるよう努めています。

その前はアクセンチュアで DevOps コンサルティングに従事し、VMware におけるインフラ自動化にも携わりました。

カミラ・マセド：私の名前はカミラ・マセドです。12 歳の頃からソフトウェア開発を始め、16 歳で仕事に就きました。それから 20 年以上が経ちます。キャリアの前半 10 年ほどは、Java、JBoss、WebLogic、Oracle、Spring、Hibernate といった技術を中心に扱ってきました。ここ 8 年ほどは Kubernetes やクラウドソリューションに取り組んでいます。私の主な関心は、ツールや自動化の開発、Kubernetes そのものの拡張、そしてコミュニティや開発者、特にオペレーター・パートナーの支援方法です。つまり、これらの環境で製品をデリバリーするための Kubernetes ネイティブなソリューションをどう構築するかを、開発者をサポートすることを目指しています。

スティーブン・チハク：私はスティーブン・チハクです。キャリアは 90 年代にスタートしましたから、もう随分と昔のことになります。エンジニアリングに関わるあらゆる役割を経験してきました。過去 15 年間は、規制の厳しい業界や小売、ホスピタリティ分野で、エンジニアチームやプラットフォームチームを率いてきました。最近では Choice Hotels でシニアディレクター（クラウドプラットフォーム）を務め、同社の DevOps、CI/CD、開発者体験、クラウドインフラ全体を統括していました。現在は Harness に Field CTO として合流し、EMEA 地域を担当するためロンドンに拠点を置きます。

AI とプラットフォームエンジニアリングの交差点

レナート・ロージオ: AI はすでに、プラットフォームチームの働き方をどのように変えつつあるのでしょうか？実際の現場での体験や、組織への影響についてお聞かせください。

ダヴィデ・デ・パオリス: 間違いなく、AI はプラットフォームチームが他チームを支援するあり方を変えています。私の経験から、少なくとも3つの領域で大きな恩恵を受けていると感じています。1つ目は戦術的な側面です。多くのタスクは重要ですが緊急ではなく、チームからの絶え間ない要請やロードマップ、OKR の圧力に押されがちです。具体的にはドキュメント作成、ボイラープレートコードの生成、スニペットやモジュールの開発、複数リポジトリにわたる Infrastructure as Code (IaC) の変更などです。図解や一般的な文書化もこれに含まれます。従来はこれらのタスクは後回しにされがちでした。しかし AI を活用すれば、比較的少ない労力で容易に実行できるようになりました。ここが最大のメリットであり、これまで放置されていたことが今では確実に完了するようになっています。

その上に、運用面での効果もあります。

通常、プラットフォームチームは非常に複雑な環境の管理や保守、あるいは理解に追われます。私のチームでは約 100 の AWS アカウントを管理し、Terraform を用いた数百のリポジトリを見渡しています。こうした状況下で、AI を活用して環境の差異を把握し、基準となる状態を見つけ出し、データを統合することで、最終的に取り組むべき優先順位を決定しています。

戦略的な観点から言えば、これはチームへの負担軽減につながります。なぜなら、技術的な課題と組織的・コミュニケーション上の課題が同時に存在するからです。AI や自動化を導入したり、内部向けに MCP サーバーやスキルを提供したりすることで、最初のサポート窓口（ファーストライン）を不要にできます。AI は自社製の MCP サーバーやエージェントを活用するように設定されており、最初の質問に即座に対応したり、本来であれば人間が行うべきコード生成を自動で行ったりします。

レナート・ロージオ氏: 特におっしゃっていた「見過ごされがちな部分」について感銘を受けました。通常、人々が手を付けようとしないバックログのことです。もし私がより伝統的な環境にいるとしたら、金融業界でも同様の傾向が見られるか、あるいは AI がプラットフォームエンジニアリングに与える影響について異なる経験があるのか、とても興味があります。

ステファノ・ディ・チェーザレ： 今、AI の登場で全てが変わると言われていますが、プラットフォームエンジニアリングの本質は変わっていません。重要なのは、AI は単なる新しい自動化のツールに過ぎず、従来のプラットフォームエンジニアリングや DevOps の原則は今も有効だということです。

変化しているのは規模です。人間からのワークロードだけでなく、エージェントからのリクエストにも対応する必要があります。そのため、プラットフォームの意図を明確に保つことが以前以上に重要になっています。どのようなサービスを提供し、それが何をするのかを理解することが求められます。

AI の時代において、明確なスコープ、明確な API、そして各サービスの提供条件を定義することは極めて重要です。

Stephen Cihak: コード生成の速度が向上し、コード作成にかかる時間が短縮されるにつれて、ボトルネックの所在も変化します。以前は週に一度のリリースが主流でしたが、現在は「外側のループ」、つまりデプロイメントのサイクルやスキャン、セキュリティ対策、ガバナンスといったプロセス全体が新たなボトルネックとなっています。

プラットフォームチームには、自己サービス型の迅速なデプロイ体制を各チームへ提供するという、かつてないほどの圧力がかかっています。リーダー層は「AI ツールに投資してコードを生み出しているのだから、なぜそれが本番環境に反映されないのか」「どうすればもっと早く展開できるのか」と問いかけているからです。

このプロセスは人間の手による速度ではなく、機械が動くスピードで運用されなければなりません。多くのプラットフォームが用意した標準的なパス（paved paths）には、依然として手動の承認ゲートが存在し、これがプロセスを著しく遅らせています。機械のスピードで進むことが、プラットフォームエンジニアリング全体に大きな変化をもたらしているのです。

カミラ・マセド: 皆様の発言は非常に興味深いです。ソフトウェアエンジニアとして、ダビデさんの意見に完全に同意します。AI は私たちの働き方を変えており、元に戻ることはもうできません。スティーブンさんが今おっしゃった点も大変面白く、特にリリースの速度について言及されていました。現在では、AI が多くのセキュリティ上の課題を特定するのを支援しています。私たちはより多くの「ペット（注：原文の文脈から「対策」や「取り組み」と解釈される可能性がありますが、文脈上「pet」が誤記または比喩である可能性が高く、ここでは「対応策」や「取り組み」として自然に訳します）」を行う必要があります。オープンソースのメンテナーとして、私たちは常に後手に回っていると感じています。AI を使う人が簡単に何かを見つけられるからです。

私が考える AI の最も素晴らしい点は、非構造化データをどう扱うかという点が変わったことです。これまで、何かを行う前には必ずポリシーが必要でしたし、処理する前にデータは構造化されている必要がありました。しかし、AI は新たな視点をもたらします。ログの解析を助け、デバッグを支援してくれるのです。私にとって、これは人間をサポートするために上に乗せる新しいレイヤーのようなものです。

AI 時代における内部開発プラットフォームへの適応

レナート・ロージオ: 実は、スティーブンがチームや開発者へのプレッシャーについて言及された点に戻りたいと思います。開発者が AI コーディングアシスタントやエージェント、あるいは今週登場した新しいツールを積極的に活用する中で、内部開発プラットフォーム（IDP）はどのような機能を備えるべきでしょうか？また、逆に提供すべきではない機能とは何でしょうか？どこで線を引くのか、チームをどう支援し、プレッシャーをどう軽減すればよいのか、お聞かせください。

スティーブン・チハク: 私たちにとって、内部開発プラットフォームは、新規サービスのオンボーディングやインフラのプロビジョニングを劇的に加速させる強力なワークフローエンジンとして機能します。また、これらのプロセスの自動化にも大きく貢献しています。究極的な目標としては、これが私たちのための堅牢な CMDB（構成管理データベース）となり得る点です。システムに対する評価スコアリングをより高精度に行ったり、開発者に豊富な情報を提供したり、さらに多くの役割を果たしたりすることが可能です。ただし、これはまだ発展途上の目標と言えます。

IDP のワークフローを活用してオンボーディングを支援することで、このプロセスは劇的に加速しますし、最初から標準化が徹底されるようになります。サービス起動時に設定すべきすべての基準や要件は、従来であれば数ヶ月かかったものが、わずか数分で完了できるようになります。時間が経過するにつれ、IDP はこれらのサービスのプロビジョニングや組織管理において、そして開発者の日々のワークフローを支援する上で、ますます重要な役割を果たすことになります。

これを拡張すれば、バックエンドでエージェントを活用できます。あるいはプラットフォームチームがバックエンドのエージェントを活用し、カミラ氏が話していた脆弱性の最新情報をチームに提供し、常に更新を維持するのを支援することも可能です。プラットフォームチームはこれらのエージェントを構築して導入できます。開発者がポータルを開くと、「これらのサービスで 47 の脆弱性を修正しましたので、デプロイしてください」と表示されます。こうした仕組みは、私たちが前進していく中でチームにとって非常に有益なものとなるでしょう。

レナート・ロシオ: あなたも同様の経験がありますか？同じようなプレッシャーを感じていますか？

ダヴィーデ・デ・パオリス: はい。プラットフォームエンジニアリングにおいて、「何を提供し、何を集中管理するか」という線引きとバランスを見つけることは、未だに答えが出ていない永遠の課題です。

レナート・ロシオ: これは AI だけの話ではありません。

Davide de Paolis: はい。私たちが扱う規模において、プラットフォームチームの役割はまず、各チームが抱える課題や摩擦点、そして一貫性の欠如によって生じる累積コストを把握することです。例えば、15 のチームが同様のタスク（パイプラインの構築や Fargate 上へのサービス導入など）を行っている場合、プラットフォームチームはその作業を抽象化し、チームから負担を取り除くことで、メンバーが製品や機能の開発に集中できるようにします。

AI の領域においても、同様に「再利用可能なコンテキスト」を整備する責任があります。多くのチームで類似のタスクが発生しており、コード規約に関する指示文の作成や、PR（プルリクエスト）生成のためのスキル定義、Jira や Linear といったチケット管理システムからの情報取得スキルの実装などが行われています。その後、AI を活用してコードレビューやその他のタスクを完遂しています。

このコンテキストの管理は、プラットフォーム側で行うことも可能です。少なくともプラットフォームチームが、その保存方法や配布方法を統制し、安全かつセキュアな形で実施されていることを検証できます。

ここから2つ目のトピックである「ガードレール」の話に入ります。エージェントが暴走したり、ハルシネーション（幻覚）を起こして過剰な権限を行使したりしないよう、安全に動作させる必要があります。私のチームでは部分的にこの体制が整っていますが、より大規模な組織では必ずしもそうではないかもしれません。

FinOps の観点からは、AI 関連のプラットフォームチームが管理と決定権を持ちます。「どのツールを使うか」「ライセンスをどう管理するか」「トークンを使い果たした場合の超過分（オーバーレイジ）をどう処理するか」などを統括し、ガバナンスを適用します。具体的には、「エージェントが使用できる MCP サーバーはどれか」「ブロックすべきか、特定のサーバーのみを許可すべきか」といった判断を行います。

Renato Losio: 内部プラットフォームに含めるべきものとそうでないものの線引きや、開発者をどうサポートするかについて、何か共有されることはありますか？

カミラ・マセド: 私にとって、AI は根本的な原理を変えるものではありません。あくまで追加されるサービスのひとつに過ぎません。

これまで私が開発者支援のためにツールやソフトウェア、フレームワークを提供し貢献してきたように、常に「共通するニーズは何か」を考え続けています。それは多くの人を助けるためのものか、少数の人のためだけのものかを問うことです。プラットフォームチームも同じ視点を持つべきです。重要なのは、組織全体で共通していること、リスクはどこにあるのか、コストはどうなるのかという点です。

もし組織全体で共通する解決策があるなら、各チームがそれをゼロから作り直す必要はありません。こここそがプラットフォームチームの役割であり、AI 自体に限らず、あらゆるサービスや統合を支援できる場所です。

セキュリティについても同様です。人に対しても AI やエージェントに対しても、管理方法は同じはずです。人間と同じように考える必要があります。最小権限の原則、明確な権限設定、強力なポリシー、そして何よりも厳格な監査体制は、これまで以上に重要になっています。

ステファヌ・ディ・チェーザ： カミラさんの意見に強く同意します。AI 技術の流行に乗って流されるのではなく、ユーザーや開発者が実際に直面しているボトルネックを把握することが重要です。多くの場合、AI が改善するのはコーディング速度だけですが、実際にはコーディング自体がボトルネックになっているケースは多くありません。

私たちが銀行である以上、コンプライアンスやセキュリティは私たち特有の課題であり、真のボトルネックもそこにあると考えています。重要なのは、AI を活用するユーザーがこうした課題をより効果的に扱えるように支援することです。プラットフォームチームの役割の一つとして、コンプライアンスやセキュリティに関する情報を一元化し、エージェントが使いやすくすることも挙げられます。

また、プラットフォームチームにとって新たな挑戦となっているのが、過去の経験との違いです。従来はインフラ関連のトピックを扱い、プラットフォームチームの方が一般の開発者よりも Terraform に精通していることが一般的でした。しかし今では AI の登場により、全員が同じ土俥に立っています。開発者を AI で支援する一方で、開発者もプラットフォームチームも AI を使い始める状況です。

そのため、以前以上に連携して取り組むことが重要になっています。貢献モデルを確立し、常に最善の解決策を最初に提示できるのは私たちだけではないという現実を受け入れる必要があります。開発者が何をしているかを理解し、共に最適な解決策を導き出す協働が求められています。

カミラ・マセド： ステファンの発言に一言添えさせてください。銀行がエージェントを使って意思決定を行おうとしていることに、私は非常に安心しています。なぜなら、ある朝は口座残高を見て「自分は大金持ちだ」と思い、翌日には「貧乏だ」と感じるようなことが起きるからです。AI の判断は確定的ではないのです。セキュリティ、法務、コンプライアンスの観点から、人間が介在する体制を重視している点に私は大いに感謝しています。人間を介さずに自由に意思決定を行うエージェントについては、多くの懸念を抱いています。例えばアンソロピック（Anthropic）を見てみても、そのような事例に関するデータや統計はあまりありません。Opus 5 ベンチマークにおけるコード生成の精度は 25% から 65% の範囲に留まります。私たちは AI が下す判断を完全に信頼することはできないのです。

例：開発者プラットフォーム（社内/オープンソース）

レナート・ロシオ： Spotify の「Backstage」を開発者プラットフォームとして利用していますか？それとも独自のものを作っていますか？Spotify や、一般的なオープンソースソリューション、あるいは他社の製品を利用している方、あるいは自社でゼロから開発した方など、ご経験のある方はいますか？

スティーブン・チハク： 私たちは Harness の IDP（Internal Developer Platform）を使用しています。これは Backstage をベースにしており、Backstage のプラグインをすべて連携させることができます。また、Harness 独自で開発している他の機能も含まれています。この製品はオープンソースであり、今後も進化し続けていくと確信しています。他にも類似の製品は存在しますが、私たちのエコシステムに適合していた点が非常に重要でした。これは「プラットフォームファースト」の考え方に基づいた選択です。

ステファノ・ディ・チェザーレ： 一言補足させてください。IDP（内部開発者プラットフォーム）にも種類があり、その名称が指す範囲は「ポータル」や「プラットフォーム」と様々です。私の見解では、Backstage はポータルの代表例であり、ポータル自体もプラットフォームの一部に過ぎません。プラットフォームの概念は、単なるポータルよりも広範なものです。

先ほどお話しした通り、プラットフォームにはツールの提供だけでなく、ドキュメントなどの情報を一元化する機能も含まれます。ポータルには多くの要素が含まれるかもしれませんが、それだけでプラットフォーム全体を定義できるわけではありません。

開発者プラットフォームにおける AI と人間の側面

レナート・ロージオ： 実は少し違う角度から質問したいのです。先ほど「人間の側面」について言及しましたが、これまでの開発者プラットフォームはあくまで人間の開発者を対象に設計されてきました。

しかし今や、AI ツールを利用する開発者の話だけでなく、人間ではない「エージェント」が直接プラットフォームを消費するケースも出てきています。この変化は、プラットフォームのあり方そのものを変えるのでしょうか？それとも単なるレイヤーの追加で、本質的な変化はないのでしょうか。皆様の見解をお聞かせください。

Stephen Cihak: 私は近い将来、あるいは今すぐにでも、自律的なソフトウェア開発ライフサイクル（SDLC）が必要になると確信しています。そのフローやデプロイパイプラインに組み込まれたガードレールやガバナンスが証拠を生成し、エージェントを適切に制御する仕組みです。これらのフローで使われるエージェントが暴走しないよう、体系的な権限設定が必要です。

これらは単に機械の速度で運用する必要が生じるからだけでなく、サービスと変更のフローが極めて急速になるためでもあります。今週一度だけ開かれる CAB（変更管理委員会）で何を出すかを決めるような従来のやり方では、すべての変化を管理するスピードについていけません。

また近い将来、エージェントが自律的に判断を下す場面も現れるでしょう。バグやエラーが見つかった際、エージェントがそのエラーを受け取り、コードを確認し、修正策を見出すのです。

この仕組みは修正を自動で実施し、プルリクエスト（PR）を送信します。その後、他のエージェントがデプロイプロセスを進め、脆弱性がないことと正しく動作していることを確認します。テストもすべて準備されており、一連のフローは完備されています。

重要なのは、AI が下した判断に関するエビデンスを明確に生成し、監査可能な形で公開する強力なガバナンス体制を整えることです。この自律的なソフトウェア開発ライフサイクル（SDLC）の実現が極めて重要です。

エンジニアではないビジネス担当者や市民開発者（名称は任意で構いません）も、これらのツールを活用して業務効率化のためのシステムやアプリケーションを構築し、デプロイしたがるようになります。彼らが直面する課題の一つとして、インフラ上のリソースに必要な CPU 量がわからないという点があります。そのため、高レベルの自動化が不可欠です。

AI がその判断を下すことで、開発者の負担を減らし、遅延を防ぐことができます。もし AI を活用しなければ、トークン使用に伴う高額なコストに見合うメリットを得られず、結果として生産性が低下してしまうでしょう。

ステファノ・ディ・チェーザレ氏：重要なのは、エージェントが完全に自律しているわけではないという点です。必ずどこかに人間が関与しています。特に開発者の立場では、自分が到達したい目標の意図を持つことが重要です。以前よりも自動化され、自律的な方法でその目標を達成できるようになりますが、最終的に何を達成するかは人間の判断であり、エージェントの判断ではありません。また、エージェントがどの程度自律的であるかについても、これも人間の決断の一部です。結局のところ、プラットフォームは人間のために存在し、それを以前より高速なエージェントを通じて実現しているに過ぎません。規模は変化しますが、意図を決定するのは依然として人間です。

Davide de Paolis: ステファヌ氏とスティーブン氏の発言に共通する点に繋げたいと思います。まず重要なのは「規模」の変化です。以前、プラットフォームが担っていたのは人間ペースでの負荷でしたが、現在は状況が一変しています。

高度な開発者がエージェントオーケストレーションを活用し、複数のチケットに対して仕様駆動型開発を並行して実行できるようになれば、プルリクエストの殺到というボトルネックが発生します。私のチームは GitHub のランナー（パイプラインが動作する環境）を担当しており、こうした負荷に耐えうる体制を整える必要があります。

もう一つ、皮肉な点をお伝えしたいのですが、ステファヌ氏はプラットフォームチームの役割として「ナレッジベースやドキュメントを作成し、社内で共有すること」を挙げていました。最近私が感じるのは、この点における皮肉さです。私たちは昔から、開発者が適切に業務を遂行するために、適切なドキュメントやプロセス、そして明確な仕様が必要だと知っていました。

しかし、エージェントが登場し、それらがハルシネーション（幻覚）を起こしたり文脈を見失ったりするようになった今になって初めて、ドキュメントの改善やナレッジグラフの構築に注力し始めたのです。これは皮肉な話ですが、同時に良い側面でもあります。なぜなら、これからはエージェントと人間の両方を支援するために時間を割けるからです。

レナート・ロシオ氏: パフォーマンスに関する話題は非常に興味深いものです。GitHub を筆頭に、現在では障害が日常の一部となっています。彼らの側に問題があるわけではありませんが、人間が行うこととエージェントが行うことには本質的な違いがあるからです。

カミラ・マセド：その意見に強く賛同します。AI を単なるツールや補助手段として使う限り、根本的な変化は生じません。結局のところ、システムを運用するのは人間であり、システムを理解するのも人間です。ソフトウェアエンジニアとして、最も難しいのはコード生成ではなく、ソフトウェアの構築だと考えています。コードを書くこと自体が難関なのではなく、長期的に持続可能で、他者が理解でき、長く保守できるものを作り上げることが真の課題です。

通常、ある判断が良かったか悪かったかを検証するには、2 年、3 年、あるいは 5 年といった時間がかかります。AI を活用したソリューションやドキュメンテーションについて考える際にも、ソフトウェア全体において新たな課題が生じます。私は、ドキュメントはコード内や API に記述されるべきであり、開発者が見る場所だけでなく、AI もアクセスできる場所に存在すべきだと考えています。

AI は標準化の向上や基準の改善に貢献できますが、ソフトウェアの決定論的な側面を排除するものではありません。むしろ、長年培ってきた基礎概念や考え方をより強化し、支える役割を果たすものだと捉えています。

AI 時代における開発者とプラットフォームエンジニアの役割の変化

レナート・ロージオ： 現在、開発者たちが過去にはプラットフォームエンジニアが行っていたタスクを自ら行うようになっていますか？もしそうだとしたら、インフラやプラットフォーム領域での作業を開発者が増えることに伴い、あなたのプラットフォームエンジニアとしての役割はどのように変化していますか？

ステファノ・ディ・チェーザレ： これは AI に関する一般的なテーマであり、インフラに限った話ではありません。AI は技術的な仕事を行うハードルを全体的に下げました。以前は技術系のロールにはいなかった人々も、AI を使って何かを作り始めるようになりました。そこでプラットフォームエンジニアとしてできる支援とは、私たちが持つ運用の背景知識です。こうした方々の多くは、最初から課題が「作る」ことだけではないことに気づいていません。重要なのは、自分が作ったものを維持する責任を負うことです。AI を使えば物を作るのは非常に簡単です。

最近、私は初めてフロントエンドの開発に関わりました。私が以前にフロントエンドに触れたのは Visual Basic の時代で、今回は AI に助けられました。AI は驚くほど乱暴なことをしていましたが、私のような不器用なフロントエンド開発者でも、「HTML を直接フロントエンドコンポーネントに埋め込むのは良くない」ということがわかりました。専門家がその点をチェックし、「動作はしているが、その後メンテナンスできるものなのか」を見極める必要があるのが、今もなお必要な役割だと思っています。

カミラ・マセド：この質問は非常に興味深いと思います。実際に動くものを作るのと、問題を解決し、長期間にわたって成長し続けるものを作るのでは、その難易度は全く異なります。私たちの業界では、「さあ、すべてを捨ててゼロから始めよう」というチームの姿をよく見かけますね。

開発インフラについてお話しされましたが、ここ数年で Kubernetes の普及とともに DevOps が注目されるようになりました。これは、運用についても知識を持つ開発者のことです。私の関心は、Kubernetes をどのように拡張するか、そして開発者をどう支援するかという点にあります。これは大きな課題です。良い仕事をするためには、インフラの仕組みについて多くのことを学ぶ必要があるからです。また、インフラ出身の方が開発の仕組みを学ぶ必要もあります。

現在では、クラウドや Kubernetes で働くなら、少なくとも基礎となる概念や構成要素について広い理解を持っていることが不可欠です。そうすることで、プロフェッショナルとしてより大きな価値を提供できるようになるからです。

スティーブン・チハク氏：プラットフォームチームが存在する理由について一言触れさせてください。それは、インフラやデプロイメントなど、特定の領域において中央集権化と標準化を図るためです。もしすべての開発者が各自で独自のインフラを構築し始めれば、すぐに統制が効かなくなります。そのため、そのインフラのルール、動作原理、設定方法などをすべてコードとして定義し、全員がそれに従うようにするか、あるいは使用されるインフラに対して強力な監督体制を維持する必要があります。

イノベーションを阻害したくはありません。むしろ開発者にイノベーションを起こしてほしいのです。そのためには、ある程度の自由度を与える必要があります。ここでステファヌ氏が以前触れていた「インナーソース」のモデルが重要になります。新しいインフラの構築や、既存のインフラでは自社の課題解決ができないと感じている開発者が、プラットフォームチームと連携して新たなアプローチを模索する仕組みです。

この標準化は極めて重要です。なぜなら、無秩序なインフラが展開されることで生じる多様なバリエーションや、それに伴う潜在的な問題・リスクを考慮すると、統制の取れた環境こそが必要だからです。

AI がプラットフォーム構築を変える方法

レナート・ロージオ氏：では、AI は実際に、プラットフォームチームによるプラットフォームの構築や維持方法をどう変えているのでしょうか？また、自社のプラットフォーム構築プロセス自体にどのような影響を与えているのでしょうか？

Davide de Paolis: これは最初の質問とも関連しています。私たちは、より速く行動し、自分自身を高め、パフォーマンスを向上させるためのプラットフォームとして AI を活用します。

Renato Losio: 以前は後回しにされていたことを実行することも、その一部です。

Davide de Paolis: はい、先ほどの回答に関連する追加の回答をさせていただきます。開発チームから「なぜ自分たちの Terraform コードを書いたりデプロイしたりできないのか？今は簡単なのではないか」という要望が多数届いているからです。確かにその通りです。私たちが AI に求めているのは、業務を簡素化し、その方向へ一歩踏み出し、開発者のエージェントが正しい行動をとれるようにするスキルや内部 MCP サーバーを提供することで、チームとの距離を縮めることです。

もし開発者が Terraform コードを書きたい場合でも、Claude や Kiro からの回答として Stack Overflow のスニペットやドキュメントからコピーしてくるわけではありません。エージェントは私たちのスキル、つまり Kiro の力を活用します。そして、特定のリポジトリにどのようなモジュールがあり、それらをどう使うべきかという知識を持っています。

これにより、開発者は自分の作業に対してより自信を持てるようになりますし、私たちが望む通りの行動が取られていることも確認できます。これが今後の方向性です。もちろん、何かが起きないようにするためのガバナンスやガードレールが必要です。エージェントが実行できるサンドボックスをプラットフォームが提供しなければなりません。また、特定のステージではリソースが破損したり改ざんされたりしないよう、AWS SCP（サービスコントロールポリシー）の運用などにも取り組む必要があります。

カミラ・マセド：AI の活用において、私が特に素晴らしいと感じる実用的な事例の一つが「サポート」です。先ほど登壇された方々も触れられていましたが、蓄積された知識ベースに基づいて回答を提供する仕組みは非常に有効です。

もう一つのポイントは、プラットフォームやクラウドサーバーなどから発生する膨大なログデータにあります。AI を活用すれば、これらのデータをフィルタリングして問題を特定することが可能になります。

また、エージェントを活用してインシデントを起票することも可能です。ただし、現状のエージェントは問題を一度で完璧に解決するには至っていないのが実情です。開発者がエージェントを使う場合でも、十分な対話が必要であり、良い結果を得るためには多くのやり取りが求められます。

それでも、エージェントは問題の分析や初期対応の支援役として非常に有用です。私たちが課題に取りかかるための足掛かりを提供してくれる存在と言えます。このように、AI を活用する上で「サポート」「ログ分析による問題特定」「インシデント起票と初期支援」という3 つの側面が特に魅力的だと考えています。

AI を活用した標準化、ガバナンス、およびガードレール

レナート・ロシオ: 実は、ダビデ氏が先ほど言及された「ガードレール」や「標準の維持」という点に戻りたいと思います。コスト管理（FinOps）に限らず、新しいモデルや、コード開発を改善するかもしれない最新のツールを採用する際、多くの企業やプロジェクトで共通して直面するのがこの問題です。プラットフォームチームにとっては、そのツールを管理し、コンプライアンスを確認し、データの所在を把握するなど、追加の負担が増えることになります。

貴社では、ガードレールの設定や標準維持についてどのような経験がありますか？特に AI 導入において最も困難だった点はどこでしょうか？以前と比べて状況が変わったのか、それとも同じ課題なのか、お聞かせください。

スティーブン・チハク氏： AI の台頭は、標準化をより強く迫る圧力となっています。その背景には、ツールの非決定的な性質による多様性の増大があります。同じプロンプトを入力しても、14 通りの異なる回答が返ってくるようなケースも珍しくありません。こうした状況下で重要なのは、ガバナンス体制を整え、デプロイ時のチェックや検証プロセスを確立することです。つまり、AI ツールが動作するシステム内にガードレール（安全装置）を設置し、非決定的な挙動を予測可能に管理することが鍵となります。

モデルの応答そのものを完全に制御することは不可能ですが、ルール遵守を担保するためのガードレールを設けることで、運用上のリスクを抑えることができます。さらに、AI 評価機能を追加することで、モデルや回答内容に変化（ドリフト）が生じていないかを継続的に把握できます。

私は、裏側でモデルが静かに変更されている事例も目にしてきました。第三者ベンダーが自社のモデルを微調整しても、その変更について十分な周知を行わないケースがあるためです。もし応答結果を定期的に監視していなければ、予期せぬ出力が発生するリスクがあります。そのため、ガバナンス体制の構築、ガードレールの設置、そして本番環境での評価プロセスは極めて重要なのです。

レナート・ロジオ: 銀行業界においても、ガバナンス（ガードレール）の維持や標準化が非常に重要な役割を果たしていることは間違いありません。AI がこの状況をどう変えたのか、悪化させたのか、それとも単純化したのか気になります。

ステファノ・ディ・チェーザレ: スティーブンの発言に同意します。規模が大きくなるほど、その必要性はより明確になります。重要なのは単にガードレールを設けることだけでなく、エージェントに対して「自社のアーキテクチャとは何か」「どのような原則があるのか」を明確に伝えることです。ある人が「車はガードレールに衝突しながら運転するものではない」と言ったのを思い出します。これは非常に良い比喩だと思います。何が禁止事項なのかだけでなく、「道路の真ん中」がどこにあるのかも明確にする必要があります。プラットフォーム構築においては常に存在していたことですが、今では以前にも増してその重要性が際立っています。

AI とプラットフォームエンジニアリングの未来

レナート・ロジオ: 当然ながら続く質問として、AI が今日の議論の中心であり、プラットフォームエンジニアリングに限らず、開発者体験全体の中核を占めていることは明白です。では数年後にはどうなっているとお考えですか？より高い視点で見たとき、AI は内部プラットフォームをさらに中核的なものにするのでしょうか。つまり、先ほどのガードレールのように、プラットフォーム自体の重要性がさらに高まるのか、あるいはエージェントがこれまでプラットフォームが標準化していた業務を多く引き受けるようになるため、プラットフォームそのものが不要になるのか、どちらだとお考えですか？

Davide de Paolis: 間違いなく、AI はプラットフォームエンジニアリングの業務の一部を奪いますが、職を奪うわけではありません。私たちが毎日行っている作業には「トイル（苦役）」と呼ばれる反復的なタスクが多くあり、これらは AI に任せることができます。こうした作業は消えていくでしょうが、私はそれほど大きな問題はないと考えています。なぜなら、依然として複雑な課題が残るからです。

今後は、プラットフォームやインフラチームに所属する熟練エンジニアが、単なる設定の修正やログの確認ではなく、より複雑で挑戦的な問題を解決するようになります。AWS が最近公開したセキュリティエージェントや DevOps エージェントのような AI エージェントを例にとってもわかりますが、これらの分析ツールや AI による業務軽減は確かに一部の作業を奪います。しかし、プラットフォームチームには、ガバナンスや文脈レイヤーの構築など、新たに追加すべき重要な仕事が残されています。

こうした作業の一部は消えていく一方で、AI エージェントが意図した通りに動作するよう保証する方法といった新たな課題も生まれます。全体的に見れば、これはエンジニアたちが抱えるアイデンティティ・クライシスと似ています。「コードを書く」「インフラの設定を記述する」という役割に自分自身を限定して考えている場合、AI によってその価値が脅かされるかもしれません。しかし、「組織内の課題を解決し、他者を支援する」存在だと捉え直せば、私たちの役割が消えることはありません。

カミラ・マセド： 多くのエンジニアが「AI が私たちの仕事を奪う」と言うので、私は笑ってしまいます。そんなことはないと信じています。コンパイラーが登場した際にも開発者の仕事が奪われたわけではありませんでした。同様に、AI も同じようにはならないでしょう。コンパイラーも複雑さを抽象化しましたが、現実にはテクノロジーに関わる人材はさらに必要とされ、役割や業務の幅も広がっています。AI は進化の一環であり、単なる別の解決策に過ぎません。それはまた新たな抽象化の層です。コードを理解できる人々の必要性は依然としてあります。確かに将来、AI はコード生成が非常に得意になるでしょう。しかし、コードを理解し、保守し、システムを稼働させ続け、実際に問題に対処できる人材は必要不可欠です。AI に関連する新しい職種も生まれ始めています。この新技術に関わる多様な仕事が見えてきています。

レナート・ロシオ： プラットフォームエンジニアリングは、今後5年でどこへ向かうとお考えですか？

Stephen Cihak: 5 年先？それは現在の視点では非常に長いスパンです。この分野の未来を考えると、プラットフォームエンジニアリングにおいては「職そのものの喪失」よりも「業務内容の変容」として捉えるべきだと考えています。世界がさらにその領域へ進出するにつれ、プラットフォームエンジニアリングの重要性は増していくでしょう。

なぜなら、最終的には完全自律的な SDLC（ソフトウェア開発ライフサイクル）を実現する必要があるからです。誰かがアイデアを持ち、それがプロダクション環境で稼働するシステムとして出力されるまでを、プラットフォームが支える役割です。その際、プラットフォームはプロセス全体、そしてその中で意思決定を行うエージェントたちを適切にガバナンスし、統制する上で極めて重要な役割を果たさなければなりません。

特に規制対応の観点では、証拠の生成が不可欠です。AI のスピードで世界が進化する中、人間が追いつくことはできません。そのため、システムがどのように動作したかという証拠を確実に残す必要があります。パイプラインが適切に構造化され、ガバナンスされていることを保証することが求められるのです。

これは、一般道と高速道路の違いを想像するとわかりやすいかもしれません。

高速道路では時速 55〜60 マイルで走れます。なぜなら、そこは狭い 2 車線道ではなく、路肩を外せば溝に転落したり車体が転覆したりする危険があるからです。一方、交通が分離されたフリーウェイでは、より大幅に高速で走行できます。しかし、その速度を支えるためには、より強固で大規模なインフラを整備する必要があります。

人々は、どのような構造（プラットフォーム）が必要かを理解するために時間を費やすことになります。そこへ到達するには多大な労力が必要です。私は、必ず実現できると信じています。もしそのような基盤がなければ、オーストラリアのアウトバックを運転しているようなもので、常に段差や揺れに遭遇し、思うように速く走ることができません。さらに、進行方向さえもわからなくなり、誤った方向へ暴走してしまう恐れがあります。

したがって、マシンスピードで開発を進めるために、自律的な SDLC（ソフトウェア開発ライフサイクル）を構築・管理するプラットフォームチームが存在し、それが構造化され適切にガバナンスされていることが極めて重要です。

内部プラットフォームの成功指標

Renato Losio: プラットフォームエンジニアリングが実際にエンジニアの認知負荷を軽減していることを証明するために、どのような指標を優先しますか？トークン使用量ではないと推測しています。

ステファヌ・ディ・チェーザ： 正直に申し上げますと、私にも確固たる答えはありません。しかし、これが私がプラットフォーム体験の構築に取り組む中で直面する最大の課題です。究極のところ、これは主観的な問題だからです。我々は客観的な指標には長けていますが、本質は「開発者がプラットフォームに対して満足しているか」「プラットフォームを通じて自身の業務に責任を持てるという自信を持っているか」という点に帰着します。

これは定性的な問いかけとして行う必要があります。なぜなら、常にフィードバックを上手に与えてくれる数人の開発者を知っているからです。彼らと協力して進めることができます。しかし最終的に経営陣は、「特定の3人の意見ではなく、全員の声が知りたい」と問うでしょう。現在の我々の課題は、開発者が信頼を持って率直なフィードバックを提供してくれるようにすることです。なぜなら、開発者の間には「プラットフォームチーム＝運用チーム」や「常に『いいえ』と言うチーム」という認識があるからです。

私はこの状況を改善したいと考えています。そして、重要なのは心理的安全性を確保し、開発者が実際に抱えている問題を率直に話せる環境を作ることです。つまり、チームの全員がその声を真剣に受け止める必要があります。たとえ回答が「いいえ」であっても、開発者には「我々は彼らの効率化に関心がある」という信頼を持ってもらうことが不可欠です。現時点で即座に解決できなくても構いません。これは長期的な視点で取り組むべき課題だと私は考えています。

カミラ・マセド： 管理側の担当者がこの点についてどう考えているか、私も非常に興味があります。私のキャリア全体を通じて、開発チームの成果を評価する有効な方法や、本当に優れた速度が出ているかを測る指標は一度も発見できませんでした。多くの手法が存在しますが、どれも決定打となる役割を果たしているようには思えません。私にとって重要なのは機能追加の数ではありません。むしろ、バグ数やインシデント数、新人がチームに合流して AI のハルシネーション（幻覚）を理解し、生成を行うまでに要する時間など、これらのプロセスにかかる期間と、その質をどう改善しているかに焦点を当てています。

レナート・ロジオ： 内部プラットフォームの成功は、どのように測定すればよいのでしょうか？

Davide de Paolis: その点については取り組んでいます。私たちが提供している価値を、上司や経営陣にデータとして示す方法については、まだ模索中の段階です。

先ほど Camila さんがおっしゃったことに同意します。私たちの主な役割は、人々を支援し、彼らがより速く活動できるようにすることです。本当に役立っているかどうかを確認する最もシンプルな方法は、オンボーディングの効率を見ることです。チームが「アイデア」から「本番環境へのリリース」に至るまでにどれくらいの時間がかかるか。セットアップや設定、デプロイにどのような手順が必要で、どのパイプラインを使用しているのか。これらはすべて数値化して測定可能です。

例えば、複数のチームが Kubernetes クラスターや Fargate 上で何かをデプロイするために3週間を要している場合、その作業を排除し、再利用可能なソリューション、つまりすぐに使える完成されたソリューションを提供することで、その時間を1時間に短縮できたとします。これは明らかに、チームの認知負荷と負担を減らすことになります。チームは「どこで」「どのように」動かすかではなく、「何を構築するか」に集中できるようになります。

もう一つの指標は、私たちが受け取るリクエストの数です。これは定量的かつ定性的な評価が可能です。Slack 上のメッセージや、やり取りの回数などが該当します。PR（プルリクエスト）内でやり取りが繰り返されたり、コメントやメッセージで往復が多く見られたりする場合、それはコミュニケーションが明確でないことを意味します。ドキュメントやナレッジに不足がある可能性があります。その点を改善することで、プラットフォームチーム設立前後の DORA メトリクスを代理指標として比較することも可能になります。

Stephen Cihak: 私が繰り返し強調したいのは、Davide が先ほど述べた通り、「正しい行動を取りやすくする」ことです。これを継続的に行えば、認知負荷を低減できます。その測定については、Davide が言及した理想の状態が指標となります。他の皆様のご意見にも全面的に賛同いたします。

トランスクリプト付きの登壇資料 をもっと見る

録画日時:

2026 年 9 月 8 日