こんにちは、株式会社AJA の SSP Division でソフトウェアエンジニアをしている石上敬祐 ...

こんにちは。タイミーでPlatform Engineeringグループのマネージャーを務めている橋本です。先日Architecture Conference 2025で「AI × Platform Engineeringでスケーラブルな組織を作るには」というテーマで発表する機会がありました。本記事では、その内容をもとにブログ記事として詳細にお話できる部分も交えてお伝えします。 登壇内容詳細は以下リンクのspeakerdeckも見ていただけると嬉しいです 😊 speakerdeck.com とはいえ長いので、以下に登壇内容をサマライズしたグラフィックレコーディング風の一枚絵（feat. Google Nano Banana Pro）も掲載します。 登壇内容のサマリー サマライズしすぎると解像度が粗くなってしまうので（& サマライズに少し誤りが含まれるため 😢）文章で補足をさせてください。 成長するプロダクトと組織が直面する課題 他の会社組織でも見られることかもしれませんが、プロダクトの成長に伴い、機能の増加や依存関係の複雑化、ガバナンス要求の増加などが発生し、開発者の認知負荷が高まります。 タイミーにおけるPlatform Engineering（PFE）チームの役割は、こうした認知負荷をオフロードし、開発者が価値提供に集中できるスケーラブルな基盤を提供することです。しかし、ここに大きなジレンマがありました。 PFE × スケーラブルのジレンマ 現在、PFEメンバーは開発組織全体の約5%程度で、開発者と20倍近い人数差があります。開発者を手厚く支援しようとするとPFE自体がボトルネックになってしまいますが、かといって人を増やすのも簡単ではない。いわば「がっつり支援したいけれど、やりすぎるとパンクしてしまう」というジレンマです。 特定チームに深く入り込む「Embedded」型の支援は手厚いですがコストが高く、リソースが枯渇しやすい。一方、ツールや基盤を提供する「XaaS」型はスケーラブルですが、個別具体のコンテキストに対応しにくいという限界がありました。この一例として、弊社、古屋の ブログ記事 に書かれており、以下のようなお話です。 第一段階は私が作った本人でもあることから期待通りになることはすんなり確認できましたが、第二段階ではやはり S3 に関する知識が十分にない状態ではいくらサンプルコードがあっても書くのは難しいと改めてわかりました。 さて、現状はXaaS化を強力に推進しなければチームリソースが枯渇して回らなくなる、というところまでには至っていません。しかし将来、プロダクトや組織のスケーラビリティにPFEのスケーラビリティが追いつけなくなることが想定されます。 AIで突破する：新しい支援モデルの構想 そこで現在進めているのが、「このジレンマ、AIでなんとかならないか？」というアプローチです。とはいえ、この考え自体はあまり目新しさはないかもしれません。 具体的には、DevinのようなAIエージェントをチームの一員として機能させます。以下の絵が全体的なイメージです。なお、Devinを必ずしも使う必要はなく、CursorやClaude CodeなどのCoding AgentとコードのCloneによっても代替可能です。ここでは、ChatOpsな体験が良いこともあり、Devinを採用しています。 そして、左右で仕組みのカタマリが異なり、以下の絵のようになります。 右側：AIが調査・ドキュメント化 現在のリソース設定（As-Is）をAIが出力する仕組みです。ここでの”AI調査”はKiro CLI（Q Developerと呼ばれていたプロダクト）を中心に実現されます。なお 詳細は後述します。 AIはプロンプトに従ってAWS Resource Explorerなどを通じて、実際のクラウドリソースの設定状況（As-Is）を調査し、ドキュメントを生成します。 左側：人間が補足を記述 右側で生成されたドキュメントを元に「なぜこの設定なのか」というコンテキスト（Design Addendum）をPFEエンジニアが書き加えるフェーズです。ここで最大のポイントは、「設定値（As-Is）」だけでは不十分だということです。 「なぜその設定になっているのか（Why）」という背景情報は、設定ファイルの外側 にしかありません。 ドキュメント化のループと回答フロー 以下のようなループが回るイメージです。 AIが調査・ドキュメント化 人間が補足（Addendum）を記述 1 - 2を繰り返すループ AIが統合: これらを統合して、AIが開発者の質問に答える 開発者がAIに質問を投げかけると、Devinを通じてGitHub上の「As-Isの設定ドキュメント」と「Whyの補足情報」が統合されて回答されます。 例えば、開発者が「本番環境の〇〇という名前のS3バケット、なんでPublic Accessブロックされてるの？」と聞いた時に、AIが「それは〇〇というセキュリティ要件のためです」と即答できるようになります。また、ここまで背景を理解していれば、IaCコードの自動生成もスムーズになるため、柔軟な要件定義と実装出力（IaCコードを生成するなど）をAIが行うことも可能になるのではないかと考えています。 細かな実装について ここで、登壇で細かくお話できなかった以下の図の赤い点線枠内にフォーカスを当ててお話しします。 詳細なフロー図は以下になります。 Kiro CLI（Q Developer）は必要か？ 今までの流れで「Kiro CLIを使うの？terraform/HCL + Coding Agent + MCPでもできるのでは？」と思われた方もいるかと思います。このブログ執筆時点では、Kiro CLIの方が適していました。AWSの設定確認をAIが行う上で必須となる awscli等の知識をKiro CLIは事前学習済みである ことがスムーズな仕組みに繋がっています。その他のCoding Agentを用いた場合でも AWS Knowledge MCP Server やInternet上の情報等を使うことによって同様の動きにはなるのですが、 オーバーヘッド・試行錯誤が多発する 点が無視できない（図で言う"いろいろ大変"な）部分でした。 なぜAWS Resource Explorerを使うの？ Resource Explorerの詳細については、弊社、佐藤の ブログ記事 をご覧ください。AIにAWSリソースを調査させる場合、問題になるのはどのリソースが作成されているかという前提知識がないことです。正攻法でいくのであればAWSの全サービスに対してCrawling（list API）をしていくことになりますが、オーバーヘッドが大きく、regionも加わると対象は膨大です。Resource Explorerが管理するリソースは、ユーザー（我々）が作成したリソースがほとんどであり、Index化されたリソース情報を容易にリストで取得できることが利点です。Resource Explorerは各リソースの情報は持たず、あくまでどんなリソースがどのARNで作成されているかを得るためのIndexとして使っています。 SQLite（sqlite3）は何のために？ 当初実装時は、AIにプロンプトを通じてResource Explorerを参照させていました。ただ、APIの返却上限が1,000件のリミットがあったり、ページネーションの挙動などが間に挟まっていると取得挙動が安定せず、あるタイミングで実行した場合には5,000件のリソース取得が期待されるのに、次は3,800件しか取れていないなど、件数が毎回変わる不安定さが見られました。 そこで、ローカルキャッシュとしてSQLiteを使い、ツールで定型的にResource Explorerから取得しsqlite3にデータを保持する仕組みとしました。AIはスキーマやデータ構造をコンテキストとして渡した上で対象をグループ（S3、IAM、RDSなど）化してSQLで取得し、調査をさせることが容易になりました。（もちろん、これらのツールもAIに生成・メンテナンスさせます） いろいろお膳立てをして満を持してAIが 上記のように、アレコレとお膳立てをしてAIが処理しやすい前捌きをしながら、ドキュメント化をさせる機構を作り上げています（まだ絶賛作っている最中で、試行錯誤のタイミングです）。今年の夏頃から徐々に作ったり試行錯誤をしていますが、AIの進化（Q Developerの登場）やAIが取り扱えるコンテキスト量の増加（Claude Sonnet4.5の1Mなど）などの外部環境により改善が一気に進むことを目の当たりにしています。CodingAgent / AI Modelの進化と一緒に暫くは改善・改良を進めていくことになりそうです。 AI時代の新しいPlatform Engineering この仕組みによって、これまで「コストが高いから乱発できない」としていた「Embedded（埋め込み型支援）」を、AIが肩代わりしてくれることが期待されます。AIがドメイン知識やインフラの現状を把握していれば、極端ですが24時間365日、各チームに「Embedded」し続けることができるのです。 これにより期待できる効果は以下のようなものであり、開発者に対する支援だけではなく、PFEチーム内の知識共有やマネージャー・監査部門による確認なども、より気軽に・低コストにできる未来があるかもしれません。 確認・学習コストの低下: 開発者がAI経由で「Why」を学べる 知識共有の加速: PFE内の知識がAIに集約され、担当交代やスケーリングが容易になる 監査・統制: 設定意図が明確になり、監査にも活用できる まとめ Platform Engineeringは開発者の認知負荷を下げるためにありますが、PFEチーム自体がボトルネックになりがちです。この「人のスケーラビリティ」の限界を、「AI支援によって突破する」。これこそが、AI時代の新しいPlatform Engineeringの形になるかもしれないと考えています。 AIを活用することで、これまでコスト面で難しかった「手厚い支援」を擬似的に実現し、開発者がフルサイクルに活躍できる環境を作る。タイミーでは、こうした新しいチャレンジに一緒に取り組んでくれる仲間を絶賛募集中です！ プロダクト採用サイトTOP カジュアル面談申込はこちら

こんにちは！ インフラ・SREチームマネージャーのよしたくです。 こちらは株式会社ココナラ Advent Calendar 2025 3日目の記事です。 はじめに 「Terraformのディレクトリ構成、どうするのが正解？」 これは全SREが一度は通る道であり、そして未だに議論が絶えないテーマではないでしょうか。 ココナラでも、組織の拡大やフェーズの変化に合わせて、IaC（Infrastructure as Code）の管理方法を何度も変化させてきました。 本記事では、ココナラにおけるTerraformコード管理がどのような変遷を辿ってきたのか、その歴史をかんたんに紹介したいと思いま