プラットフォームエンジニアリング入門：AI連携IDPのPoCで得た知見と学び

はじめに

はじめまして！
株式会社メンバーズ デブオプスリードカンパニーの新城です。

デブオプスリードカンパニーでは、毎週金曜の午後は、メンバーそれぞれがラボに所属して研究開発を行うDevOpsLabという取り組みを行っています。
私は今年6月に入社し、現在はPlatform Engineering Labに参画してキャッチアップや技術検証を行っています。Platform Engineering Labでは、プラットフォームエンジニアリングのアプローチについて、研究・実践・対外発信する活動をしています。

本記事では、入社からの4ヶ月間で私が学んだプラットフォームエンジニアリングの基礎知識と、実際に手を動かして得られた知見や学びをまとめていきます。

プラットフォームエンジニアリングとは

クラウド、コンテナ、IaC、CI/CD、監視、シークレット管理、権限設計。システム開発で向き合う技術領域は広がり続けています。
その結果、開発者の認知負荷と対応工数は増え、本来注力すべき価値創出に使える時間が減っています。
この広がった領域を引き受け、開発チームが価値創出に集中できるようにする。そのための共通基盤を設計・構築・運用する取り組みをプラットフォームエンジニアリング、開発者に向けた共通基盤そのものをIDP(Internal Developer Platform)と呼びます。

具体的なイメージ

新しいサービスを立ち上げ、開発をスタートするとなった時、実際に必要となるものをいくつか挙げてみます。

• ソースコードを管理するリポジトリ
• デプロイ先の環境構築
• CI/CDの設定
• コンテナレジストリ
• 監視やログの設定
• シークレット管理先
• 適切な権限設定 など

これらを開発プロジェクトごとに毎回組み上げるのではなく、あらかじめ構築の手順を用意しておき、必要な時に払い出せるようにする。これがプラットフォームの提供する機能です。

IDPが備えるべき性質

作るものを決めるには、何を満たしていれば良いプラットフォームと言えるのかを知る必要があります。この記事では、CNCFが公開しているPlatforms White Paperを基準として参照します。

CNCFとは

CNCF(Cloud Native Computing Foundation) は、クラウドネイティブ領域のオープンソースプロジェクトをホストしている団体です。その中の Platforms Working Group が、プラットフォームの定義と備えるべき性質をまとめたものが、この白書です。
※これは標準規格ではありません。プラットフォームエンジニアリングには標準を定める団体はないため、CNCFが整理したベストプラクティスという位置付けで参照しています。

Platforms White Paperでは、Attributes of platforms(プラットフォームが備えるべき性質)として以下を挙げています。「内容」列は私の解釈で要約しています。

PoCを作る

ここまでがプラットフォームエンジニアリングの整理です。
この考え方への理解をより深めるため、ラボ活動の中でPoCを作成しました。ここからは、実際に作ったものを紹介します。

AIから使えるIDP

Attributes of platformsの「User experience」では、インターフェースの例としてGUI/API/CLIが挙げられています。ただ、近年のAIの台頭を踏まえると、今後はAIエージェントが利用しやすいインターフェースを提供するべきだと考え、今回はIDPをMCPサーバとして作成することにしました。

※MCP(Model Context Protocol)は、AIアプリケーションを外部システムに接続するための共通規格です。本記事ではMCPの規格にしたがってAIに機能を提供するものを「MCPサーバ」、提供されている機能を「MCPツール」と記載しています。

作る機能

今回は、GitHubのリポジトリを作成する機能をPoCの対象として選びました。AIに「GitHubにリポジトリを作成して」と伝えることでリポジトリが作成できるようになるイメージです。

本来目指したいのは、「⚪︎⚪︎言語でWebアプリケーションを作りたい」と伝えると、依存パッケージの定義やCI/CDの設定などが全て用意された状態のリポジトリが払い出される状態です。今期はまず小さなゴールとして「GitHubリポジトリ作成」を置き、その先は今後の課題としています。

実装の方針

PythonでMCPサーバを実装し、GitHub APIを直接呼ぶ形としました。実装する上で特に検討したのは、権限の持たせ方とAIに勝手に実行させない仕組みの2点です。

権限の持たせ方

API実行にあたって、IDPが強い権限を持つのではなく、指示を出した人の権限の範囲で動く形を取る必要があります。IDPが専用の強い権限を持つと、誰が指示しても同じ権限で動いてしまうため、非常に危険です。

今回は私しか実行しないので、暫定的に私のアカウントでPAT(Personal Access Token)を発行し、それを使って動くような実装としています。GitHubの権限は、個別の操作ごとではなく「リポジトリそのものを管理する権限」といった分類単位で設定します。付与したのは、リポジトリの作成に必要な Administration(Read and write)です。この分類には作成も削除も含まれるため、PATの設定だけで「作成はできるが削除はできない」状態にすることはできません。

本来は複数のユーザーが使うことを想定して、指示したユーザーに応じて権限を切り替える仕組みが必要となります。この仕組みがないと、Aさんの指示がBさんの権限で実行される、というようなことが起こってしまいます。これは今後の課題としています。

AIに勝手に実行させない仕組み

AIがツールを呼び出せる以上、与えた権限の範囲内での操作は実行できてしまいます。リポジトリの情報を参照したいだけなのにAIが指示を誤解してしまい、リポジトリを削除してしまうことも起きかねません。このような意図しない操作を防止するために、読み取り以外の操作には必ず人間の承認が必要となるガードレールを作成しました。

承認はMCPツールとして公開しておらず、実行には承認時に発行されるトークンが必要となります。AIは自分で承認を得ることも、承認を飛ばして実行することもできません。

1. 計画 : 何が作られるかを返す。この時点ではGitHubに一切問い合わせない。
2. 承認 : 人間による計画の確認、承認。
3. 実行 : 承認された計画のみを実行。

動かしてみる

実際にClaude Codeから作成したMCPツールを呼び出して動かしてみます。
まずは、リポジトリ作成を依頼します。すると、AIは計画として作成先のOrganization、リポジトリ名などを提示します。この時点ではまだ何も作られていません。

次に、人間が計画の内容を確認し、問題なければ承認処理を行います。現状、承認の操作は直接承認処理のpythonコードを実行する形となっています。これをSlackでボタン押すだけで承認できるようにしたり、もっと操作しやすい形にするのも今後の課題です。
承認操作を実行すると、承認トークンが払い出されます。

払い出されたトークンを再度Claude Codeに伝えることで、リポジトリ作成をMCPツールとして実行可能になります。

GitHub上に、指示したとおりのリポジトリが作成されました。

PoCがAttributes of platformsをどこまで満たせたか

今回のPoCが、Attributes of platforms のどこまでを満たせたのかを整理しました。
1は実際に使ってもらう段階に進まないと評価できないため、引き続き取り組むべき直近の課題は2, 3, 7となりそうです。

まとめ

今期の活動を通して、プラットフォームエンジニアリングが何を解決しようとしているのかが見えてきました。開発チームが向き合う技術領域が広がり続け、手に負えなくなってきた部分を共通基盤として切り出し、開発チームが本来の価値創出に注力できるようにすること、これが起点にある考え方であると学びました。
また、PoC作成にあたり、IDPを従来のGUIの形式ではなく、AIに特化したインターフェースにしたことで、AIの自律性に起因したリスクを防ぐ仕組みが必要になりました。
人間が操作する前提のGUIでは、その役割を人間自身が担っていたためです。提供するインターフェースによって、Attributes of platformsで挙げられている属性をどう実装するか、深く検討する必要があると感じました。

今後の展望

今後は、今期詰めきれなかった以下をメインに実装を進める予定です。

• 承認操作のUI整備
• 依存パッケージの定義やCI/CDの設定などが全て用意された状態のリポジトリ払い出し
• 不特定多数のユーザー権限がセッションごとに適切に切り替わる仕組み

設計・実装を進めれば、また新しい課題が出てくるはずです。Attributes of platforms に沿うにはどう設計すべきか、何が足りないのか。今回のように一つひとつ照らし合わせながら検討することで、理解を深めていきたいと思います。

最後までお読みいただき、ありがとうございました！プラットフォームエンジニアリングをこれから学ぶ方の参考になれば幸いです。