はじめに

プラットフォームエンジニアリング1G Managerの橋本です。チームの名前の通り、私達はクラウドインフラ（AWS）やCI/CDパイプライン、Observability、クラウドセキュリティを軸としてタイミーのサービスプラットフォームを開発者へ提供しています。

昨今、AI Coding Agentの発展は目覚ましく、弊社でもCursorやDevinなどを日常的に利用して開発が行われています。そんな中、AIとPlatformEngineering（PFE）の交差によって、よりビジネスに資するPFEの推進ができるのではないかと"妄想"しました。その青写真や取り組む方向性について記事にします。

まずPFEや開発者との関わりを整理

jacopenさんの以下の登壇スライドが分かりやすいため、本記事に関わるポイントを抜粋します。

speakerdeck.com

背景：DevOpsと認知負荷の増大

クラウドの登場とDevOpsにより、開発とデリバリーの継続的な実施を目指すアプローチが広まった。DevOpsのプロセスにセキュリティ対策を組み込むDevSecOpsも登場
扱う技術スタックの激増により開発者の認知負荷が非常に高くなった（特にこの10年）
これをやり切れる人材は少なく「真のDevOps」（開発者がフルサイクルでデプロイ・実行を行う）の実現は多くの組織で現実的ではない

そこでPFE

開発者体験と生産性を向上させるために、セルフサービスで利用できるツールチェーンとワークフローを設計・構築する分野
本質は、開発者体験と開発生産性を高める取り組み
PFEの始め方は、開発フローの「ペイン」（辛いところ）を洗い出し言語化し、必要な対応を行うこと
例えば、セルフサービス化やInternal Developer Portal/Platform（IDP）構築などがある（が、これが必須でもないと資料では言及されています）

開発者との関わり方

Team Topologiesの整理で、ビジネス価値に一気通貫で関わるStream-aligned team（ストリームアラインド・チーム）と、その道のプロであるPlatform teamなどが定義されている
チーム間のインタラクションモードとして以下があり関わりの濃淡で捉えている
- Collaboration (Embedded)
  - ゴールを共有して一緒に動く（ガッツリ関わる）
- Facilitating (Enabling)
  - 障害を取り除くためにその道のプロとして支援する（中程度の関わり）
- X-as-a-Service (XaaS)
  - ツールを提供する（関わりが最も薄い）
Platform Teamは、まずCollaborationから始めるのが良い。Stream-aligned Teamと1:1で協力し、必要なものを理解して作ることで、誰得なものを作り込むことを防ぐ
Collaborationで得た知見をもとに、より多くのチームを助けられるXaaSモード（プラットフォーム提供）を構築していく。ここでIDPの要素が出てくる

我々PFEチームの現状・課題

先の認識をもとに私達の組織の現状認識や課題感について書きます。

PFE1Gの立ち位置と現状

我々が所属するプラットフォームエンジニアリング部では、開発ライフサイクルの各所でドメイン知識を持ったチームやメンバーにより支援を行っています。（以下の図の 開発プラットフォーム Tribe ）

私達1Gはその中でもサービス実行環境であるAWS基盤全般、リリースツール(CI/CD)や運用(observabilityやAWSに関わるOps)の一部に責務を持ち、開発生産性に寄与するための業務を担っています。実態としてインフラチーム + SREチームの混合というイメージです。

なお、PFEの文脈で出てくるセルフサービスやIDPの提供はしていません。これらの仕組みがなくても価値提供の大きなボトルネックやブロッカーになる状況が観測されていなかったためです。

しかし、将来的に我々自身がボトルネックとなりうる懸念がありました。

懸念とは？

提供サービスの整理

主な領域に切り出した場合、以下のような整理になり、AWSという大きな領域以外はおおよそXaaS的なサービス提供ができており、関わりが薄い状態で開発者体験や生産性に寄与できている状態と考えています。

領域	提供方法	提供詳細
AWS	いろいろ(後述)	-
Observability	Datadog 関連記事1, 関連記事2	ダッシュボード化など XaaS的な提供ができていそう
CI/CD	GitHub Actions 関連記事3	CI/CDパイプライン XaaS的な提供ができていそう

AWS周りを分解

AWS環境はTerraform/IaCによる管理をしています。GitHub上でコード管理されており、おおよそのCODEOWNERは1Gになっています。開発者は必要な変更があればPullRequestを作成し、1Gのエンジニアが問題ないことを確認してmergeができます。これは、XaaS的な提供と言えそうです。

ベースラインの運用は先の通りXaaS化がなされています。しかし、必要となるAWSに関する知識、設計難易度やドメイン知識に応じてTeam Topologiesでいう、FacilitatingやCollaborationが必要となるケースがあります。なお、用語的にイメージしやすいFacilitating → Enabling、Collaboration → Embedded として以降は表記します。

なお、例としてバケット追加にXaaS or Enablingと書いていますが、ほぼ依頼をもらって我々が作業を行うことがほとんどです。頻度があまりなく、対して要件によって必要なパラメータが変わるため、Terraform Module化や詳細な手順書を書いていたとしても、結局聞いて我々が考えて設定した方が提供が早く認知負荷も低かったためです。

要件	難易度・範囲	例	Team Topologiesのモード
実装済へ軽微なもの	簡略的・限定的	既存のバケットpolicy変更	XaaS
明確な要件/定型化可能なもの	繰り返し・限定的	バケット追加	XaaS or Enabling もしくは依頼作業型
新しいAWS機能の利用開始	新規・不確定	AWS 〇〇を新規構築	Enabling or Embedded
新サービス/サブシステム構築	新規・広範囲	-	Embedded

現状は問題ない？

先の整理が現状ですが、今時点は大きな問題は起きていません。

しかし、将来への課題感がありました。Embeddedのチームへの負荷の高さです。XaaS, Enabling, Embeddedのチーム間の距離感や工数感をイメージにした画像を示します。この絵のようにEmbeddedはほぼ対象チームに人を派遣する形になり、比例して工数的にも他パターンよりも大きくなる傾向があります。Embeddedは、例として新しいサブシステム構築プロジェクトが発生した場合にチームから人を送り込むようなものになります。数ヶ月にわたってヘッドカウントが減ることになり、チームの計画に影響があります。

もちろん、組織全体のビジネス達成観点ではプラスなので間違っていませんが、Embeddedが継続的に発生したり、複数発生した場合はチームが機能不全に陥るリスクがあります。結果、組織全体へ悪影響や我々がボトルネックになるリスクが発生しうると考えました。

XaaSやEnablingへの移行が鍵ではあるが

リスク回避のアプローチはPFEの考えに沿えば、XaaS化やEnablingによって関わり（≒ 工数）を減らし開発者生産性向上を目指すことです。しかし、先に述べたバケット追加が依頼作業型になるように、現実としてはインフラ領域のドメイン知識は多岐にわたるため簡略化・手順化することが困難なケースが多くあります。仮にenablingパターンで進めたとしても、あれこれお手伝いをしているうちにEmbeddedになってしまうことが想像されました。

Embeddedでチームが劣化してしまうかも

Embeddedが多発すると、チームへの負担が増すと述べました。例えば、1人から2人、瞬間的には3人がサブシステム構築プロジェクトに関わることがあります。こうなると、チーム（だいたい1pizza的な人数で構成しています）の半数が出払ってしまうことにもなり、定常的な業務遂行が劣後してしまいます。

サブシステム構築が1つだけであれば「暫く待てば皆戻って来る」という期待が持てますが、2つ以上並走した時点で詰みになります。まだ2以上の並走プロジェクトはありません。しかし、弊社の今後の事業成長・加速に応じて発生する可能性があります。

こうなると、PFEチームがスケールできない = 事業開発への遅延となってしまいます。

このリスクを如何に回避できるか？を考えていた中でAI Coding Agentの急激な成長を見てできることがありそうだと思い至ったこと。これが本ブログの趣旨になります（やっと本題です）

今までのお話をまとめると

以下のようになります

新システム開発のようなEmbeddedでなければならない（XaaSやEnablingでは限界がある）ケースがある
理想はEnablingではあるものの、インフラ領域自体のドメインが巨大であり一朝一夕で開発者が自走できるものではない
結局、巨大なドメイン知識に対応しうる人材が張り付く（Embedded）する必要があり、このスケーラビリティが事業成長のボトルネックになりうる

AI Coding Agent x PFEの青写真

AI Coding Agent技術の現状と可能性

我々はIaC/TerraformによりAWS環境を扱うことが多いため、AI Coding Agentのコード生成についてはHCLの記述性に着目することが多いです。

AIのHCL記述力は急速に改善されています。以前はHCLを扱うのが苦手で、古いAWSプロバイダー仕様や新しく出たサービス定義に対応できないケースが多発していました。ウェブなどの情報からでは正しい一次情報をAIがピックアップできないからだと思われます。

しかし、Terraform MCP ServerやAWS MCP Serversによって正しい一次情報へアクセスした上で生成するようになるなど、以前のような課題は解決されつつあります。

これら改善により、CursorやDevinなどのAI Coding Agentを活用して、開発者が直接AWS基盤に変更や追加を加えることが現実的になってきました。とはいえギャップが大きいのも事実です。

理想のかたち：AI Enablingの実現

宣言的なインフラ変更の実現

現状では「terraformのリソース○○に○○なパラメータで追加して」のようなかなり明示的・指示的なプロンプトになりがちです。しかし理想は「○○な要件でバケットがほしい。追加して」といった宣言的な自然言語での要求を実現することです。

また、「〇〇な要件では〇〇への考慮が必要なので、以下の質問に答えてくれますか？」といったAIからの打ち返しを通じて、特にセキュリティ的なガードレールが満たされる実装まで開発者とAIの対話によってなされることが理想です。

最終形としてこれが達成されれば、簡単な自然言語によるAWS基盤の変更がXaaS的に提供できそうです。また、変更適用までは難しくてもAWS基盤に関する壁打ち相手としてAIが提案をしてくれ、気にすべき点を開発者が適切に認知できるようになればEnablingとして機能していると言えそうです。

余談ですが

我々のチームではDevinに対してIaCの変更を依頼することが多くあります。一例として以下の画像のような、とても指示的な依頼になってしまいがちであったります。

これをできる限り宣言的に行えるようにすること、AWSやTerrafromリソースに対して知識がなくても依頼できるようにすることが目指すかたちだと言えます。

EnablingモードのAI化イメージ

例として、開発者が「○○な用途で○○したいけれどどうしたらいい？」といった質問を、従来PFEエンジニアに問い合わせていた内容をAIに対して行い、適切な回答を得られるようになります。

副次的効果として、PFEチームのエンジニア自身も当然AIに質問できるので、PFEエンジニア間のドメイン知識のばらつき解消やSPOF防止（Aの領域はXさんしかしらない。Bの領域はYさんしかしらない）が期待できます。

現実的な課題：コードの外側のコンテキスト

事業要件とコードのギャップ

AWS基盤はほぼコード化されていますが、コード化されていること＝事業要件ではないケースが存在します。

例えば、S3バケットのセキュリティ要件は、保存するデータが個人情報かどうか、グローバル公開するかどうかなど、事業要件によって変わります。また、IAM Roleなども組織体制や運用要件によって大きく変わります。しかし、コードにはそこまでの要件が細かく記述されていることは少ないのではないでしょうか。IAM Roleであれば、どのRoleが付与されているかと追加・変更理由ぐらいまではコメントにあっても、なぜこのRoleが存在するのか、どのような使われ方をするのかについては別のドキュメント・手順書にコンテキストがあるのではないかと思います。

つまり、コードの外側に事業や運用に関わるコンテキストが存在することが多いと考えています。

解決アプローチ：コンテキスト注入とドキュメント化

必要なドキュメント化

コードの外側にあるコンテキストをAIに理解してもらうため、例えば以下のようなドキュメント化が必要になりそうです。

サービス仕様のドキュメント化

アプリケーションの仕様
ユビキタス言語などのローカル言語定義
- Devinを賢くする秘訣は「ユビキタス言語」にあり？ NotionとTerraformで実現する半自動ナレッジ更新術
実行に関わる運用ルール・実装方法・GitHubコメントの書き方などのナレッジ
- 気づけばDevinのナレッジが山積みに。Terraformで片づけてみた

技術仕様に応じたAWSリソースのドキュメント化

コードの外側にある情報（人間が補足する情報）
- 例えば、特定のIAM Roleに付与された権限の文脈や運用ドキュメントとのリンクなど

AIによるEmbeddedモード連発からの脱却

上記が達成されれば、現状Embeddedモードで人が大きく関わっている新規サブシステム構築プロジェクトでも、XaaSやEnablingのような薄い関わりで遂行できると期待されます。開発者とPFEの関わり方・分担は以下のようなイメージになれば良いと考えています。

開発者の作業フロー

Devin, CursorなどのAI Coding Agentに並走してもらい、作りたいサービスのTerraformコードを生成
インフラ構築を実行

PFEチームの関わり方

コードや変更の正しさ・ガードレールが必要かなどレビューで関わる
誤りや複雑性・危険な操作の予兆を発見した場合は訂正・ガードレールの規し修正事項をドキュメントに反映する
新しい設計などコンテキストに存在しないものがあれば一時的なEmbeddedモードで並走

PFEの役割

先の絵を見るとHCLの記述やIaC・クラウドインフラのメンテナンスはAIによって行われることがより効率的であるという未来が見えます。その時、我々PFEは何を責務とすべきなのでしょうか。

絵を見ると、コード外のコンテキスト・ドキュメントを充実させることにあるかもしれません。大まかなイメージではありますが

日々の開発・運用・ビジネス変化を観測・メトリクス/KPIの計測から問題を発見する
問題を解決するための議論・必要に応じてルールメイキングを行う
解決策・ルールをドキュメントに反映してAIが正しい出力をできるようにする

言うなれば、ビジネスを観測し経験などに基づいて課題抽出を正しく行ったり、目まぐるしく変わる優先順位を整理して、AIに"気持ちよく"仕事をしてもらうために必要な情報やルールメイキングをドキュメントに反映したり、"お願い"することが仕事になるかもしれません。なんだか、エンジニアリングマネージャーっぽいですね。

この話のまとめ

新システム開発のようなEmbeddedモードでなければならないケースが連発するとPFEのスケーリングが事業ボトルネックになるリスクがある
リソースが限られるのでEmbeddedの連発は不可能。しかしながら、AIによってEnabling + 最小限のEmbeddedで事業のスケーリングに対応できるプラットフォームエンジニアリングができるのではないか、と、現在は"妄想"段階
コードに表現されていない様々な要件をAIに与える必要があり、ドキュメント化や入力方法を工夫してAI Coding Agentに正しい出力をしてもらうことが鍵になりそう。AIに気持ちよく仕事をしてもらう工夫をすることに労力を費やすことになるかもしれない。

最後に

既に弊社の他の方々がブログに取り組みを書いているように、先の取り組みが始まりつつある状態です。また、AI Coding Agent界隈の変化が激しく1〜2週間でも目まぐるしく注目の話題が生まれてくる状況にあります。（2025年6月現在）

変化によってやり方が全く変わる可能性がありますが、2〜3ヶ月後にはある程度の目処が見えてくるのではないかと思います。過去半年のAI Coding Agentの発達を思えば、今年中にはさらに大きな発展をしている期待感もあります。

不確実なことが多い取り組みではありますが、もし達成できればPFEがビジネス上のボトルネックになるリスクを回避できる、少ない人数で最大のアウトカムを得るチャンスだと思うので、力を入れて取り組んでいきたいと思います。

長い文章になりましたが、最後まで読んでいただいてありがとうございました。

Timee Product Team Blog

タイミー開発者ブログ

AI x PlatformEngineeringへの取り組み(立志編)