4
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

IDP(Internal Developer Portal)に関わる者として、現状と今後のIDPの立ち位置を体系的に整理する目的で本記事をまとめました。

本記事の読者は、Backstageなど社内開発者ポータルの運用・検討に関わるプラットフォームエンジニア、および「AI時代にIDPへ投資する意味があるのか」を判断したいテックリード・意思決定者を想定しています。

はじめに

結論から言うと、IDP(Internal Developer Portal)を人間が画面として「開く」頻度は今後確実に減っていきます。しかし、それが提供している組織固有のコンテキスト、アーキテクチャ標準、ガードレールとしての役割はなくなりません。むしろ、AIエージェントが開発プロセスの主体になっていく過程で、この役割の重要性は増していくと考えられます。

本記事では、「AIがコードを書く時代にIDPをわざわざ作る意味はあるのか」という問いに対して、Backstageコミュニティやベンダー、Backstage自体の議論を材料にしながら、「何が失われ、何が残るのか」「今後どう作り替えていくべきか」を整理します。実装レベルの具体的なカタログ設計(新しいカタログ種別の詳細な使い方や、GitHub連携の実装パターンなど)は、本記事の焦点をぼかさないために別記事に譲り、ここでは概念・潮流の整理に絞ります。

背景:なぜ「IDPは不要になる」という声が出てくるのか

これまでIDPは、開発者が自分のサービスの状態を確認したり、テンプレートからプロジェクトを立ち上げたり、ドキュメントを探したりするための「人間向けのUI」として使われてきました。ところが、AIコーディングエージェントがJiraのチケットを拾い、該当リポジトリを見つけ、コミット履歴を読み、修正PRを作って担当者にレビュー依頼まで出すというワークフローが実際に動き始めています。UIを操作する主体が人間からAIへ移りつつあるわけです。

この流れの中で、2026年にはAIが数分でUIを作れるようになり、Backstageのようなポータルのフロントエンド自体が不要になるという主張も出てきました。「ポータルを開いてクリックする」という体験そのものが、AIエージェントに代替されていくという見立てです。この主張は一定の説得力を持っていますが、ここで見落とされがちなのが、IDPが提供している価値のうち、UI以外の部分です。

論点整理:ポータルの2つの側面

IDPが提供している価値は、大きく2つの側面に分けて考えることができます。

  1. UIとしての側面:画面、ナビゲーション、クリック操作といった「人間が直接触れる部分」
  2. 組織固有コンテキスト・標準・ガードレールとしての側面:サービスカタログのデータモデル、オーナーシップ情報、命名規則、セキュリティポリシー、レビュー基準といった「組織のルールと知識そのもの」

「AIがUIを作れるからIDPは不要になる」という主張は、主に1の側面に着目したものです。しかし、AIエージェントが自律的に動くようになるほど、2の側面、つまり「このサービスは誰が持っているのか」「どの標準に従うべきか」「どこまでは自動でやってよく、どこから人間の確認が必要か」といった情報の重要性は増していきます。エージェントが正しく動くためには、この情報をどこかから読み取る必要があるからです。

業界の動きから見る役割の変化

この2の側面について、実際にどのような議論や実装が進んでいるかを見ていきます。

コミュニティ側の主張:カタログを「コンテキストレイク」に

Backstageの今後の方向性を論じる中で、カタログのエンティティモデルとメタデータグラフをBackstageの最も価値ある資産と位置づけ、それをガードレールと監査ログ付きのリアルタイムAPIとして人間とAIエージェントの両方に提供し、MCPを実験的なプラグインではなく一級のインターフェースにすべきだという提案がなされています。つまり、ポータルという「見る場所」から、人とエージェントが共有する「コンテキストの基盤」への転換です。

Backstage創設側の主張:標準の重要性はむしろ増す

一方で、Backstageを生み出したSpotify側の見方は少し異なります。KubeCon 2026での発言として、AI時代には開発者がより多くのコンテキストを理解する必要があり、エージェントが増えるほど組織としての標準やガイドラインを明確にしておく必要性が高まるという趣旨が語られています。また、Backstageが蓄積してきた構造化された知識をMCP経由でAIエージェントに公開する仕組みが、開発者の付随作業を大きく削減した実績も紹介されており、ポータルが持つ「構造化された組織知識」がAI活用の土台になっていることがわかります。

Backstage本体の議論:AIエージェント向けの新しいカタログ種別

さらに具体的な動きとして、Backstage本体のリポジトリでは、AIコーディングエージェントが利用するルールやスキルといったコンテキストファイルを、既存のソフトウェアカタログと同じガバナンス・検索の仕組みで一元管理するための新しいカタログ種別を追加する提案が議論されています。背景にあるのは、ツールごとにルールやスキルの形式・置き場所がバラバラで、どのスキルが存在し、誰が保守しているのかを組織として把握できていないという課題です。これはまさに、従来カタログがサービスやAPIに対してやってきたことを、AIエージェント向けの知識資産に対しても行おうという試みです。

実装レベルの動き

実装面でも同様の方向性が見えます。Backstageに MCP サーバーを組み込み、AIアシスタントがカタログやScaffolderテンプレートを直接参照できるようにした事例では、エージェントへの書き込み権限を本番環境ではなく開発環境に限定し、認証範囲やレート制限、監査ログの設計を慎重に検討する必要があったことが報告されています。国内でも、BackstageとAI関連プラグインを組み合わせてPlatform Engineeringを推進する事例が紹介されており、AI活用機能とAIリソース管理機能の両方をBackstage側に組み込むことで、ポータルを再定義しようとする取り組みが進んでいます。

個人開発規模でも、AIエージェントと組みながらプラットフォームエンジニアリング的な観点(IDP的な仕組み)でリポジトリを育てる事例が出てきており、組織の規模を問わず「標準とガードレールをどう持つか」という論点自体は広がりつつあると言えそうです。

では、今後どうしていくべきか

ここまでの材料を踏まえると、IDPを今後作っていく・運用していく上での方向性は、次のように整理できます。

カタログを「人間が見るためのUI」から「人とAIエージェントが共に参照するコンテキスト源」として設計し直す
サービスの所有者情報、依存関係、production readiness、命名規則やセキュリティポリシーといった情報を、人間が画面で読む前提のデータではなく、エージェントがAPIやMCP経由で機械的に参照できる形で整備していく必要があります。

アクセス範囲とガードレールを中央集権的に管理する
エージェントには許可されたデータのみへのアクセスを与えるべきであり、これはセキュリティやコンプライアンスの観点だけでなく、コンテキストウィンドウを絞ってハルシネーションを減らす観点からも重要だという指摘があります。また、複数チームがそれぞれ異なる権限・ツールでバラバラにエージェントを構築すると、統制の取れた「エージェント運用」ではなく「エージェントの乱立」になってしまうという懸念も共有されています。ガードレールやチェックポイントを各エージェントの実装に個別に埋め込むのではなく、ポータル側で一元的に定義する発想がここでも重要になります。

MCPのような接続手段を「実験的な付加機能」ではなく前提として設計する
AIエージェントがカタログの情報を読み書きする経路は、今後標準的な利用パターンになっていくと考えられます。エージェント向けのインターフェースを後付けのプラグインとして扱うのではなく、最初から設計に組み込んでおく方が、後々の手戻りは少なくなりそうです。

人間向けUIの価値を「なくなるもの」として扱わない
これまで見てきた通り、AI活用が進む組織ほど、標準やガイドラインを人間が理解し、設計し、合意形成する場としてのポータルの価値がむしろ意識されています。UIを開く頻度が減ることと、UIの背後にある仕組み・情報設計の重要性が下がることは、別の話だと捉えるのが妥当だと思います。

制約・注意点

ここまでの議論には、いくつか留保が必要です。

  • MCP統合自体が2026年初頭時点でもまだ「非常に実験的」な段階にあるという指摘があり、ここで紹介した方向性がそのまま定着するとは限りません。
  • 実装事例でも、本番環境への適用は見送り、開発環境限定で運用しながら認証・監査の設計を詰めている段階にとどまるケースが見られます。
  • 組織のAIエージェント活用の成熟度によって、ポータルに何を求めるかの温度差は大きく、本記事で挙げた方向性がすべての組織にそのまま当てはまるわけではありません。
  • 本記事は潮流・概念レベルの整理に絞っており、新しいカタログ種別を実際にどう設計・運用するかといった実装の詳細は扱っていません。この点は別記事で改めて取り上げる予定です。

まとめ

  • IDPを人間が「開く」頻度は今後減っていきますが、組織固有のコンテキスト・アーキテクチャ標準・ガードレールとしての役割は失われません。
  • コミュニティ側は「カタログをコンテキストレイクとして再定義し、AIエージェントに一級のインターフェースとして開放すべき」という方向を、Backstage創設側は「AI時代こそ標準やガイドラインの重要性が増す」という方向を主張しており、視点は異なりますが「組織知識の構造化」が価値の中心であるという点では一致しています。
  • 今後IDPを作る・育てる意味は、UIとしての利便性ではなく、人とAIエージェントの双方が信頼して参照できるコンテキスト・ガバナンス基盤としての価値にシフトしていくと考えられます。

参考リンク

注意事項​

 本ブログに掲載している内容は、私個人の見解であり、​
 所属する組織の立場や戦略、意見を代表するものではありません。​
 あくまでエンジニアとしての経験や考えを発信していますので、ご了承ください。​

4
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?