はじめに
前回はMCP実装の実務として、認証・権限分離・レート制限・監査ログという4つの論点を扱い、書き込み系のツールは特に慎重な段階導入が必要だと整理しました。今回はその「書き込みツール」の具体例として、Scaffolderを掘り下げます。
Scaffolderはもともと、開発者がフォームに入力し、テンプレートからリポジトリやプロジェクトを作成するための、人間向けの機能でした。これがAIエージェントから直接呼び出せる「アクション」として再解釈されつつあります。今回は、この再解釈がBackstage自体でどこまで進んでいるかという現状を簡単に押さえたうえで、人間向けの入力とエージェント向けの呼び出しの間で、バリデーションやガードレールをどう共通化すべきかという設計上の論点を中心に扱います。
Scaffolderの立ち位置の変化
Scaffolderは、もともとソースコード管理システム上でリポジトリをテンプレート化し、組織内で「ゴールデンパス」を標準化するための仕組みとして作られました。RBAC（ロールベースのアクセス制御）を備え、誰がテンプレートを作成・変更・利用できるかを細かく制御できる点が特徴です。
このScaffolderの立ち位置を変えたのが、Actions Registryという仕組みです。v1.43でActions RegistryがScaffolderに導入され、テンプレート作成者が登録済みのアクションをテンプレートのステップとして利用できるようになりました。これにより、これまでプラグインのAPIの中に閉じていた機能が、テンプレート経由でオーケストレーションできるようになっています。
このActions Registryが、そのままMCPツールとしても公開される構成になっている点が重要です。MCPプラグインは登録されたアクションをHTTP経由のMCPツールとして公開する役割を担っており、カタログとScaffolderをプラグインのソースとすることで、MCPサーバーは両方に対するクエリ・操作用のツールを自動的に外部へ公開します。つまり、Scaffolderのテンプレートを「AIエージェントが呼び出せるアクション」として扱う土台は、すでにBackstage本体側に用意されつつあります。
現状の実装と、認証の移行途上
もう少し具体的に見ると、Scaffolder・カタログ・RBACといった既存のバックエンドAPIを、それぞれMCPアクションとしてラップする形でブリッジする構成が取られています。scaffolder-mcp-backendはScaffolderのAPIをテンプレート操作用にブリッジし、rbac-mcp-backendは権限管理用にRBACシステムをブリッジするという形で、既存のバックエンドAPIをMCPアクションでラップするパターンが採用されています。既存のAPIをそのまま活かせる構成になっているのは、実装コストの観点で理にかなっています。
認証面では、当初の課題が徐々に解消されつつある段階です。当初、MCP Actions Backendの認証は静的トークンに限られていましたが、この制約はDynamic Client Registrationの実験的サポートによって解消されつつあり、静的トークンに代わってOAuthフローによる本来のユーザー認証がMCPのやり取りにもたらされるようになってきています。これは前回の記事で扱った「静的トークンからサービスアカウント・OAuthベースの認証への移行」という一般論が、Scaffolderの文脈でも実際に進んでいることを示しています。
ただし、この統合全体はまだ発展途上です。MCP統合は2026年初頭時点で「非常に実験的」と評されており、当初の認証モデルは静的トークンでユーザー単位の識別を持たず、Dynamic Client Registrationも依然として成熟途上にあります。また、Scaffolder固有のMCPツール、たとえばテンプレートのdry-run実行やログ取得といった機能は、コミュニティからの要望として挙がっている段階のものもあり、すべてが実装済みというわけではありません。
設計上の論点：バリデーションとガードレールの共通化
ここからが本題です。Scaffolderのテンプレートには、もともと人間がフォームに入力する前提でバリデーションが組まれています。必須項目のチェック、命名規則のパターンマッチ、選択肢の制限などです。これをAIエージェントが呼び出す場合、同じテンプレートに対して同じバリデーションが適用されるべきなのは当然として、実際にはいくつか固有の論点が出てきます。
入力の出所が変わることへの対応
人間がフォームに入力する場合、その場でエラーが表示され、修正して再送信するというやり取りが自然に発生します。AIエージェントの場合も同様にエラーを返すこと自体は変わりませんが、エージェントは「なぜそのエラーになったか」を人間よりも厳密にパースする必要があります。エラーメッセージが人間の目視確認を前提にした曖昧な文言になっていないか、見直す価値があります。
「実行してよいか」の判断をどこに置くか
人間がテンプレートを実行する場合、RBACによる権限チェックに加えて、担当者自身の判断（このタイミングでこのテンプレートを使ってよいか）が働きます。AIエージェントの場合、この「判断」の部分を明示的なガードレールとして持たせておく必要があります。たとえば、本番環境向けのリソースを作成するテンプレートは、エージェントからの呼び出し時には常に人間の承認を挟む、といった線引きです。これは前回扱った「読み取りツールと書き込みツールの権限分離」の、さらに一段細かい粒度での適用と言えます。
dry-runの活用
コミュニティの要望として挙がっているように、テンプレートを実際に実行する前に、パラメータの妥当性だけを確認するdry-run的な機能は、AIエージェントとの相性が良い仕組みです。エージェントがまず妥当性を確認し、問題なければ本実行に進む、という2段階の呼び出しにしておくことで、誤った実行のリスクを抑えられます。現時点でこの機能がすべて揃っているわけではないため、テンプレート側で擬似的にこれに近い挙動（パラメータチェックのみを行うステップを用意するなど）を用意しておくのも一つの手です。
標準ドキュメントとの接続
前回のTechDocs編で扱ったゴールデンパス・標準ドキュメントは、ここでも関わってきます。AIエージェントがテンプレートを呼び出すだけでなく、「なぜこのテンプレートが今回のケースに適切か」を判断できるようにするには、テンプレートの説明文や関連ドキュメントへのリンクを、エージェントが参照しやすい形で整備しておく必要があります。テンプレートのメタデータと、TechDocsの標準ドキュメントを紐づけておくことで、エージェントは単に「実行できる」だけでなく「なぜ実行すべきか」まで踏まえた提案ができるようになります。
段階導入への当てはめ
前回、MCP実装の段階導入として「開発環境限定→本番読み取り限定→本番書き込み解禁」という3段階のロードマップを提示しました。Scaffolderに当てはめると、次のような形になります。
- 開発環境限定：まずはテンプレートの一覧取得・詳細確認といった読み取り系のツールのみを、開発環境で試す
- 本番・読み取り限定：本番のカタログ・テンプレート情報の参照はエージェントに許可しつつ、実行は許可しない
- 本番・実行解禁（承認フロー付き）：影響が小さいテンプレート（開発用リポジトリの作成など)から実行を解禁し、本番リソースに関わるテンプレートは人間の承認を必須にする
一足飛びに「エージェントがテンプレートを自由に実行できる」状態を目指すのではなく、影響範囲の小さいテンプレートから段階的に解禁していくのが妥当です。
制約・注意点
- 本記事で扱ったActions RegistryやDynamic Client Registrationは、いずれも2026年時点でまだ発展途上の機能です。今後のアップデートで挙動が変わる可能性があります。
- Scaffolder固有のMCPツール(dry-run実行やログ取得など)は、コミュニティの要望段階にとどまっているものもあり、組織によっては自前で補う実装が必要になる場合があります。
- バリデーション・ガードレールの共通化について、本記事では設計上の考え方を整理するにとどめ、具体的なコード実装は扱っていません。
まとめ
- Scaffolderは、Actions RegistryとMCPプラグインを通じて、人間向けのフォーム入力ツールから、AIエージェントが呼び出せるアクションへと立ち位置を広げつつあります。
- 認証は静的トークンからOAuthベースのDynamic Client Registrationへ移行しつつありますが、2026年時点ではまだ実験的な段階です。
- バリデーション・ガードレールは、人間向けの前提をそのまま流用せず、エラーメッセージの扱い、承認フローの明示、dry-runの活用、標準ドキュメントとの接続といった観点で見直す必要があります。
- 導入は影響範囲の小さいテンプレートから段階的に解禁し、本番リソースに関わるテンプレートは人間の承認を必須にするのが安全です。
参考リンク
- Port.io「Backstage Is Dead」（2026年4月・5月）
- vrabbi.cloud「Revolutionizing Developer Platforms with Backstage and MCP」
- Nitin Jain「Turning Backstage into an AI-Ready Platform with MCP」（Medium、2026年3月）
- Backstage GitHub Issue #31755「Provide actions/mcp tools to interact with the scaffolder」
- Spotify for Backstage「MCP in Portal」
注意事項
本ブログに掲載している内容は、私個人の見解であり、
所属する組織の立場や戦略、意見を代表するものではありません。
あくまでエンジニアとしての経験や考えを発信していますので、ご了承ください。