TL;DR
- 2026年の Platform Engineering は IDP（Internal Developer Platform）に AI 利用層を組み込むフェーズに入った
- 各チームが個別に LLM を呼ぶと、コスト・ガバナンス・監査の3つが破綻する
- LLM Gateway（中央プロキシ）＋ policy-as-code ＋ コスト配賦を IDP に統合するのが標準パターン
- Platform チームは「AI を使いやすくする」ではなく「AI を安全に使い続けられるレールを敷く」が主任務
- ガードレールを Platform に寄せることで、アプリチームが本質に集中できる
この記事の目的と成功基準
- 目的: AI 利用が組織内で拡大する中で、Platform Engineering が担うべき責務を IDP 設計レベルで整理する
- 想定読者: 社内プラットフォームチーム、SRE、ガバナンスを担う技術リード
- 成功基準: 「Platform Engineering AI」関連クエリでの流入、AIネイティブな開発組織・LLM API料金最適化 への回遊
なぜ Platform 側で AI を扱うのか
Qiita のシステムアーキテクチャトレンド議論 でも指摘されている通り、Platform Engineering は「各開発者が個別にインフラ・CI/CDを設定する」から「専門チームが開発者プラットフォームを提供する」へのシフトを継続している。2026年はこの対象に AI 利用が加わった。
各アプリチームが個別に OpenAI / Anthropic / Google にキーを発行して呼び出す構成は、初期は柔軟だが半年も経つと以下が壊れる：
- コスト: テナント別・機能別の内訳が見えない
- ガバナンス: どのプロンプトが本番で動いているか把握できない
- 監査: PII を含む入出力の追跡が分散して不可能になる
- 障害対応: ベンダー障害時に全社で個別対応が走る
これらは Platform 側に集約することで一気に解決できる。
IDP に組み込む3つの AI コンポーネント
1. LLM Gateway（中央プロキシ）
すべての LLM 呼び出しを通す共通プロキシを設置する。OSS なら LiteLLM、自前なら Cloudflare Workers / Cloud Run などで実装する。
責務：
- マルチプロバイダ抽象化: 単一インターフェースで複数ベンダーに対応
- 認可とレート制限: テナント・アプリ単位での権限制御
- キャッシュ層: prompt cache・semantic cache の集約
- ログ統合: trace / cost / eval を Platform 側に集める
構成例：
[App A] ─┐
[App B] ─┼─→ [LLM Gateway] ─→ [OpenAI / Anthropic / Bedrock]
[App C] ─┘ │
[Audit Log][Cost Meter][Cache]
2. Policy-as-Code
AI 利用のガバナンスを Rego / OPA で表現し、Gateway で適用する。
# 例: PII を含む入力を本番モデルに送らない
deny[msg] {
input.contains_pii == true
input.environment == "production"
not input.consent_acquired
msg := "PII入力は同意取得後のみ許可"
}
ポリシー違反は Gateway で reject し、アプリ側に明示エラーで返す。
3. コスト配賦
テナント・チーム・機能粒度でのコスト計上を Gateway で行う。月次レポートを Platform から各チームに配信し、予算超過時の rate limit を自動適用する。
2026 年エンジニア技術トレンド でも、AI 活用と Platform Engineering は併走するトレンドとして並列で挙げられている。
Platform チームの責務再定義
AI が IDP に組み込まれた時の Platform チームの仕事は「AI を使いやすくする」だけでは足りない。
| 責務 | 内容 |
|---|---|
| レール敷設 | LLM Gateway・ポリシー・cache の運用 |
| ベスト実装の提供 | 推奨プロンプト構造、評価フレーム、テンプレート |
| ガードレール | ガバナンス・コスト・PII 保護を Platform 側で担保 |
| 教育 | アプリチームへの設計レビュー・トレーニング |
「アプリチームが本質に集中できる」状態を作るのが Platform の本懐だ。Gateway・policy・コスト配賦・テンプレートまでセットで揃えると、アプリ側は「何のためにこの LLM 呼び出しを行うか」のドメイン設計に集中できる。
導入ステップ
組織が小〜中規模なら、以下のステップを推奨する。
- Step 1: LiteLLM などの OSS で Gateway を立てる。1チーム1機能で試験運用
- Step 2: ログ集約と cost dashboard を構築。テナント別の見える化
- Step 3: Policy-as-Code を追加。最初は warning のみ、後で enforce
- Step 4: 全アプリチームを Gateway 経由に移行
- Step 5: テンプレート・SDK を Platform から配布
最初から完璧を狙わず、Step 1-2 で実値を見てから Step 3 のポリシーを書くのが安全だ。
アンチパターン
- Gateway を経由しない直アクセスを許す: 抜け道があると監査が成立しない。本番キーは Gateway 経由のみで発行する運用を徹底する
- ポリシーを enforce から始める: いきなり deny で始めるとアプリ開発が止まる。warning → soft enforce → hard enforce の段階導入が現実解
- コスト配賦が遅れる: 月次レポートでなく日次で見せる。「気づいたら100万」を防ぐ
FAQ
Q. LLM Gateway を内製すべきですか？ A. 50〜200エンジニア規模なら LiteLLM などの OSS を採用し、必要部分のみ拡張するのがコスパが良いです。それ以上で要件が独自化すれば内製を検討してください。
Q. Platform チームの人数は何人くらい必要ですか？ A. AI レイヤーだけを担当するなら2〜4人で立ち上げ可能です。既存 IDP 担当が兼務する場合は LLM 専門メンバーを1名以上配置することを推奨します。
Q. アプリチームから「自由に使いたい」と反発はないですか？ A. 初期は出ますが、コスト配賦と障害対応の集約メリットを示すと収まります。テンプレートと SDK で「Gateway 経由の方が早く実装できる」状態を作るのが鍵です。
まとめ
AI が組織に拡がる時、ガバナンスとコストの責務は Platform Engineering に集約するのが2026年の標準パターンだ。LLM Gateway・policy-as-code・コスト配賦を IDP に組み込み、アプリチームが本質に集中できるレールを敷く。Platform の責務は「AI を提供する」ではなく「AI を安全に使い続けられる状態を維持する」ことに移った。
