私は悩んでいます。 自称プラットフォームエンジニアとして、AI エージェント時代の Platform Engineering にどう向き合えばよいのか。
普段はプラットフォームを構築する仕事をしています。 自社にプラットフォームを作るでもなく、自社のプラットフォームを提供するでもなく、クライアント組織の課題を解決できるように、開発者が使いやすいように、あるプロダクトを中心としたプラットフォームの導入です。
「自称プラットフォームエンジニア」というのは、別にそんな正式な肩書やロールを持っているわけではないからです。 やっていることと気持ちが一番マッチしているのがこれなので自称してます。
所謂クライアントワークですが、関わっているプラットフォームにも愛着があるし、開発者の負担にならずクライアント組織の課題を解決するプラットフォームにしたいという気持ちで取り組んでいます。 その気持ちに応えるかのように、その環境では Platform Engineering の考えを取り入れています。
逆かもしれません。 Platform Engineering があるから開発者の負担にも意識が向くようになった可能性はあります。 プラットフォームの課題を見つけては解決に勤しむ日々の私にとって、Platform Engineering は仕事を進めるうえでの心の拠り所的なものにもなりつつあります。
そんな中、世間では AI エージェントの話題が絶えず、プラットフォームエンジニアという自分の働き方にも AI エージェントが身近になってきました。 いまではプラットフォーム構築に AI エージェントは手放せないくらいです。
ということは、プラットフォームを利用する開発者も AI エージェントを使って開発しているはずで、プラットフォームの使われ方が変わるのでは？今までの Platform Engineering の認識をアップデートしないといけないのでは？という不安に襲われます。 自分がどう AI エージェントを使いこなせるかは気にしつつ、その先のプラットフォームを利用する開発者も AI エージェントを使いこなす未来まで意識が向いてません。
このままでは「AI エージェント時代だから Platform Engineering やーめた」となると、じゃあ自分はどう生きれば……という状態に陥ってしまいます。 ここまで依存すると手段が目的化しつつあるのを否めませんが。
そんな AI エージェント時代において、プラットフォームエンジニアな自分は今何にどう向き合えばよいのか漠然と悩み、予測もできない未来に不安を感じています。 AI エージェント時代にこのままの Platform Engineering でいいのか。 Platform Engineering は無くなってしまわないのか。
この悩みについて AI と壁打ちしながら考察して自分なりの結論を出したので、内容と気持ちの整理のためにブログにしました。
Platform Engineering の本質
まずは心の拠り所にしている Platform Engineering について、自分がどう考えているかというところから。
オライリーのプラットフォームエンジニアリング本によると、Platform Engineering とは「プラットフォームを開発・運用する技術分野」であり、「システム全体の複雑さを管理してビジネスのレバレッジを実現すること」が目標とあります。 ここでいうレバレッジは、少数のプラットフォームエンジニアで組織全体の業務を削減できるという考え方です。
よく言われるのは「開発者を顧客と見立てて、開発者の認知負荷を下げる形でプラットフォームを提供しよう」ということ。 組織やチームによって異なる開発スタイルや文化があるので、認知負荷を上げないプラットフォームは組織毎にチューニングしていかなければなりません。
開発者の意見を取り入れていないプラットフォームはアンチパターンですし、他の組織で使われているプラットフォームをコピペしてきても使い物になりません。レバレッジの効くプラットフォームは金太郎飴的に提供はできないのです。
プラットフォームに開発者の意見を取り入れるためにも、プラットフォームチームは開発者との対話が必要になります。 対話することもコストになるので、コストを払っても対話していい相手だと開発者から思ってもらえるように信頼関係を築くことが重要です。 そのために日頃から開発チームの中に入ってトイルを削減して信頼を積み重ねるのも一つの手ですが、少人数のプラットフォームチームでは全開発チームに入ってトイル削減はできません。
まずは Platform Engineering の目的に賛同してくれる開発チームのトイルを削減しながら信頼を得て、フィードバックループを回して認知負荷を下げるプラットフォームを構築していくことが大事です。 トイル削減には浮いたボールを拾っていく姿勢が大事ですし、浮いたボールを拾うこと自体が信頼獲得に繋がります。
浮いたボールを拾いまくったらトイルを改善していた話 - ANDPAD Tech Blog
また、Platform Engineering のポイントに「セルフサービス」があります。 機能としては魅力的で使われるプラットフォームを構築できたとしても、利用開始や設定変更にプラットフォームチームに依頼が必要になると、開発者は離れていきます。なにより少人数のプラットフォームチームでこれらの依頼を捌こうとすると他のタスクに手が回らなくなります（実体験）。
開発者自身でプラットフォームを利用できる範囲を「セルフサービス」として提供することで、少人数のプラットフォームエンジニアで複数の開発チームにプラットフォームを提供できるし、プラットフォームチームがボトルネックにならないようにできます。
このセルフサービスを提供するにはプラットフォームの境界設計が重要になります。境界設計は「どこまでをプラットフォームチームで提供し、どこから開発者の自由にさせるか」という設計です。
そういうことで、Platform Engineering の本質は「対話」と「セルフサービスの境界設計」にあると考えています。
Platform for AI Agent
Platform Engineering community で「AI-powered platforms vs platforms for AI: A platform engineer’s guide」という記事が出ています。
AI-powered platforms vs platforms for AI: A platform engineer’s guide
AI-powered Platform は AI を活用してプラットフォーム構築スピードを上げたり、プラットフォームに AI を組み込んで開発者の認知負荷を下げるというものです。 Platform for AI は ML モデルの学習や推論基盤のためのプラットフォーム (GPU・データパイプライン・MLOps) をどう構築すべきかという「Platform for AI Workloads」の話です。
私にとって AI という分野は AI エージェントのほうが身近で、 ML モデル云々は仕事として絡んでいません。 上記の記事では AI-powered Platform と Platform AI Workloads を比較していましたが、私は AI エージェント向けにどんなプラットフォームを提供すべきかという「Platform for AI Agent」の話を考えたほうがよさそうです。
AI エージェントが台頭してきたからといって従来のプラットフォームを捨てて新たに AI エージェント向けのプラットフォームを再構築するなんてことはありません。 一方、プラットフォームの利用者がすぐに開発者から AI エージェントに置き換わるわけではありませんが、プラットフォーム以上に AI エージェントの普及速度は早そうです。
今は過渡期なので開発者と AI エージェントの両方に目を向けなければいけませんし、むしろ開発者が AI エージェントを使おうとしている段階でプラットフォーム側がボトルネックになってしまってはいけません。 従来のプラットフォームを如何に AI エージェント時代に最適化していくかが大事になってきます。
Platform Engineering 的には、開発者と AI エージェントからフィードバックを得るためにどんな対話が必要か、開発者と AI エージェントにどんなセルフサービスを提供していくか、を考えることがプラットフォームエンジニアに求められてきます。
Platform for AI Agent には「AI エージェントが利用するプラットフォーム」だけでなく、「開発者が AI エージェントを動かす環境」としてのプラットフォームの観点もありますが、今回はそちらは考察の対象外としています。
開発者と AI エージェントの認知負荷の違い
従来の Platform Engineering で想定していた顧客が開発者だけでなく、開発者が利用する AI エージェントに広がっていくと、プラットフォームエンジニアは AI エージェントの認知負荷も考慮しなければなりません。
Platform Engineering において取り除くべき開発者の認知負荷は「環境やツールが生む不要な複雑さ」によって発生します。チームトポロジーでは「課題内在性負荷」と「課題外在性負荷」、「学習関連負荷」と表現されていて、「課題外在性負荷」ができる限り削減すべき認知負荷です。この負荷が高まることで人間のワーキングメモリを圧迫して、開発速度や品質の低下に繋がります。
一方、AI エージェントにおける認知負荷とは 「コンテキストウィンドウを圧迫する仕組み」 であると私は捉えています。 AI エージェントの負荷をチームトポロジーのように分類できるかは分かりませんし、仮説止まりではありますが。
OpenAI の ハーネスエンジニアリング：エージェントファーストの世界における Codex の活用 | OpenAI という記事では、AI エージェントの視点から見ると実行中にアクセスできないコンテキストは存在しない情報であり、エンジニアは AI エージェントが有用な仕事をできるよう環境を整えることが仕事になると言っています。 ここでいう「エンジニア」はソフトウェアエンジニアだけでなく、プラットフォームエンジニアも含まれていると考えます。
開発者が AI エージェントの実行環境を整備する際、プラットフォームを利用するためのコンテキストを開発者が用意するのではなく、プラットフォームエンジニアが提供すべきです。 それも、コンテキストを一気に渡すのではなく段階的にコンテキストを開示できる仕組みを作らなければなりません。
AI エージェントにとっては「プラットフォームの使い方」が認知負荷に、開発者にとっての認知負荷は「プラットフォームの使い方」から「プラットフォームの使い方を AI エージェントの実行環境にインプットすること」が認知負荷に変わってきそうです。
また、LayerX さんのエージェントハーネスとAIマネージドサービス｜福島良典 | LayerXによると、AI エージェントが長時間実行されることによって僅かな誤りが積み重なってドリフト問題（終了条件の誤認・品質の自己過信・累積的なズレ）が発生するようです。 AI エージェントのドリフト問題を防ぐには、AI エージェントが自己判断を信頼しすぎないよう、外部から強制的に品質・進行を管理する仕組みを持たせることが重要だと述べられています。
エージェントハーネスとAIマネージドサービス｜福島良典 | LayerX
この「AI エージェントの長時間実行」がドリフト問題だけでなく、コンテキストウィンドウの圧迫、つまり AI エージェントの認知負荷にも繋がっていくと考えます。 今後はさらに AI エージェントのワンアクションが長時間化していくことが想像されますが、Platform Engineering の観点でも長時間実行に耐えうるプラットフォームのコンテキスト開示方法を考慮しなければならないです。
この AI エージェントの長時間実行によるズレを補正したり、コンテキストを段階的に開示したりする工夫を最近みかける「ハーネス」の一部なのだと解釈しました。 ハーネスが指すものを理解することも必要そうですが、全部理解する前に解釈が変わったり、新しい言葉が出てきそうな気もしていて、適度に追うのがいいんじゃないかってのが本音です。
AI エージェントとの対話
プラットフォームを利用する開発者からフィードバックを得るためにはアンケートに回答してもらったり、Slack のコメントを拾ったり、ヒアリングしたり、といくつか方法があります。
一方、AI エージェントから能動的なフィードバックを受けることは難しいです。 プラットフォームエンジニアからフィードバックを拾いに行く必要がありますが、その手段としてオブザーバビリティが使えると考えています。
まだ技術的なところまでは検討できていませんが、目的達成までのステップ数やコンテキスト消費量、エラーリトライ回数などを拾い上げる仕組みをつくることで、AI エージェントのプラットフォーム利用の良し悪しがフィードバックとして得られるはずです。
AI エージェントからどのようなログ・メトリクス・トレースを取得すればプラットフォームの良し悪しが判断できるか、これを見極めることが AI エージェントとの対話になっていくのではないでしょうか。
AI エージェント相手だと信頼関係を構築するためのステップが不要になりますが、開発者との対話は継続できるように信頼関係は維持したほうがいいです。 AI エージェントのオブザーバビリティだけでは拾えないフィードバックを開発者からもらえる可能性はありますし、信頼度はいくら高くても損はしないですからね。
AI エージェント向けのセルフサービス
セルフサービスに焦点を当てると、今までの「どこまでをプラットフォームチームで提供し、どこから開発者の自由にさせるか」というセルフサービスの設計が、AI エージェント時代では「どこまでをプラットフォームチームで提供し、どこから AI エージェントの自由にさせるか」に変わります。 我々が構築したプラットフォームを AI エージェントが使っていくようになるので、その特性にあわせたプラットフォームを設計しなければなりません。
開発者がセルフサービスでできていたことは、プラットフォームの利用者が AI エージェントになることによって広がるかもしれないし、狭まるかもしれません。
セルフサービスの範囲、境界線はプラットフォーム毎の特性や組織のルール、そして開発者の認知負荷を意識しながら決めます。 境界設計の考えは変わらないけど、開発者と AI エージェントで認知負荷の捉え方は違うはずなので、AI エージェントからのプラットフォーム利用が増えてくるとプラットフォームの提供するセルフサービスの境界線は変わりそうですね。
AI エージェント時代で変わるもの、変わらないもの
ここまでにも書いたように、AI エージェント時代ではプラットフォームの利用者が開発者だけでなく AI エージェントも含まれる、というのが変わる点です。
LayerX さんの記事で AI マネージドサービスにおける「決定論的なコードと AI の推論とハーネス」の説明がありました。 これは AI マネージドサービスにおいて「どの処理を AI に推論させ、どの処理をコードで確実に実行させるべきかの判断」ということのようです。
プラットフォーム視点で言い換えると、「決定論的なコード」が今までのプラットフォームで提供していたもので、「ハーネス」が新たにプラットフォームが意識して提供していく部分かと私は考えています。
逆に変わらないものとして、Platform Engineering の目標である「システム全体の複雑さを管理してビジネスのレバレッジを実現すること」があります。 AI エージェント時代になってもシステム全体の複雑さが解消するわけではありませんし、レバレッジを実現することの価値も変わりません。
Platform Engineering はまだしばらくは残り続け、その目的を達成するための手段が AI エージェントの要素を取り入れて変わっていきます。 Platform Engineering の目的を達成する手段が変わっていくことで、プラットフォームエンジニアは開発者だけでなく AI エージェントにも顧客としての意識を向けていかなければならないということです。
結論
書籍や記事を読んで AI と壁打ちをして、「プラットフォームエンジニアの自分は AI エージェント時代にどう向き合うべきか」の答えを以下のように結論付けました。
- Platform Engineering はすぐには無くならないだろう
- プラットフォーム利用者としての AI エージェントの理解を深めるべし
- AI エージェント時代でも開発者との繋がりは保ち、信頼構築を怠るべからず
書いてみて、自分のメンタルを保つための結論ありきの考察だったかもしれません。 でも、自分がやるべきことを考えるためにも必要な過程だったと思います。
また AI エージェント以前に、開発者との対話やフィードバックをもらう仕組みがまだ十分にできていないということに気づきました。 対 AI エージェントの Platform Engineering もこれからやっていかねばですが、今プラットフォームを使ってくれている開発者の方々の声・体験をもっと拾っていかないと Platform Engineering の目的である「ビジネスのレバレッジ」を達成できません。
もう一つ気づいたこととして、Platform Engineering の目的にどこまで近づけているか評価する仕組みが十分ではないということ。 レバレッジがどこまで効いているかの指標を立てておかないと、AI エージェントの要素が増えたときにブレる気がしていますし、評価の仕組みは AI エージェント関係なく必要なことです。
AI エージェント時代でも Platform Engineering は続けないといけないし、まだまだやるべきことがたくさんあります。
悩んで歩みを止めてないで、やるべきことをやって、当たり前のことを当たり前のようにやっていこう。