本記事は 2026 年 3 月 12 日に公開された Ryan Yanchuleff, Kartik Rao, Arnab Satpati による “ Enterprise governance: control your MCP servers and models ” を翻訳したものです。 AI コーディングツールを評価するエンタープライズのセキュリティおよびコンプライアンスチームは、一貫して 2 つの機能を優先しています。MCP サーバー接続の一元管理と、組織全体で使用される AI モデルのガバナンスです。 どちらも、企業が新しいカテゴリの開発者ツールに対してどう向き合うかを表しています。MCP サーバーはデータベース、ドキュメント、API、内部ツールに接続することで IDE を拡張し、実際の生産性向上をもたらします。AI モデルは定期的にリリースされ、それぞれデータ処理の特性と推論リージョンが異なります。エンタープライズ規模では、組織は開発環境の他の部分と同様に、これらに対してもポリシー主導の管理を期待しています。 コンプライアンス要件が高い組織にとって、これらの管理機能は広範な導入の前提条件となることが多いです。セキュリティチームは、MCP サーバーへのアクセスが組織のポリシーに沿っていること、そしてモデルの使用が承認された範囲内に収まっていることを、エンジニアリングチーム全体へのロールアウトを承認する前に確認する必要があります。 本日、Kiro に 2 つの新しいエンタープライズガバナンス機能を提供します。管理者が承認済み MCP サーバーを許可リストで管理できる MCP サーバーレジストリと、組織が開発者が使用できるモデルを定義できるモデルガバナンス管理です。Kiro はこれらのポリシーを IDE と CLI の両方で確定的に適用します。 問題: ガードレールのない MCP MCP は AI コーディングツールが外部システムに接続するための標準的な方法となっています。Kiro はローンチ以来 MCP をサポートしており、まず ローカルサーバー 、次に リモートサーバー に対応しました。開発者は MCP サーバーを使用して、Kiro をドキュメントシステム、データベース、チケットツール、クラウドインフラなどに接続しています。 MCP の導入が組織全体に拡大するにつれ、エンタープライズのセキュリティチームは開発環境内の他の統合ポイントに適用するのと同じ一元的な監視を求めるようになります。何百人もの開発者が MCP を通じて外部システムに接続している場合、管理者はパッケージレジストリ、CI/CD プラグイン、API アクセスを管理するのと同じように、使用が承認されているサーバーを定義して適用する方法が必要です。 これはエンタープライズのお客様から最も一貫して寄せられたリクエストの 1 つでした。個々の開発者の裁量に任せるのではなく、ポリシーを通じて MCP サーバーへのアクセスを管理する方法を管理者に提供してほしいというものです。組織は、セキュリティチームが求めるガバナンス体制を維持しながら、MCP の導入を迅速に進めたいと考えていました。 仕組み: MCP レジストリ Kiro の MCP ガバナンスは管理者に 2 つの管理機能を提供します。MCP を無効にする MCP のオン/オフトグルと、管理者が Kiro 用の承認済み MCP サーバーの JSON 許可リストを設定できる MCP レジストリです。どちらの管理機能も、エンタープライズユーザー向けに作成される Kiro プロファイル の一部であり、そのアカウントのすべてのサブスクライバーに対してアカウントレベルで設定できます。 レジストリ自体は JSON ファイルで、Amazon S3、nginx、内部 Web サーバーなど任意の HTTPS エンドポイントに作成してホストします。Kiro 管理コンソールのプロファイルに URL を追加すると、Kiro が確定的な方法で残りの処理を行います。すべての Kiro クライアントは起動時にレジストリを取得し、24 時間ごとに再同期します。ローカルにインストールされた MCP サーバーがレジストリに存在しなくなった場合、Kiro はそれを終了させ、開発者が再追加できないようにします。レジストリがサーバーの新しいバージョンを指定している場合、Kiro はそのサーバーを更新後のバージョンで自動的に再起動します。 開発者が Kiro CLI で /mcp add を実行すると、レジストリのサーバーのみが表示されます。レジストリで定義されたサーバーパラメーター（URL、パッケージ識別子、ランタイム引数）は読み取り専用です。開発者は独自の環境変数（認証キーやローカルパス用）と HTTP ヘッダーを追加できますが、リストにないサーバーには接続できません。 レジストリはリモートとローカルの両方の MCP サーバーをサポートしています。 リモートサーバー : streamable-http または sse トランスポートで接続し、エンドポイント URL と HTTP ヘッダーを設定可能です。 ローカルサーバー : npm、PyPI、OCI レジストリのパッケージとして定義され、 stdio トランスポートで動作します。Kiro は npx 、 uvx 、または docker を使用してダウンロードおよび実行します。適切なパッケージランナーが開発者のマシンにインストールされている必要があります。 MCP レジストリオープン標準に基づく構築 Kiro のレジストリファイル形式は、 MCP レジストリ標準 の一部を採用しました。これは MCP サーバーの検出と配布のためのオープンソース仕様で、MCP プロジェクト（元々は Anthropic が作成し、現在はオープン標準として管理されています）によって維持されています。これにより、MCP ガバナンスへの投資が特定のサービスプロバイダーに縛られることはありません。レジストリ仕様は、MCP サーバーのカタログ化、バージョン管理、検出方法の標準化されたデータモデルを定義しています。 Kiro のレジストリ定義は、JSON 形式の仕様から サーバースキーマ の一部に従っています。各サーバーエントリには、名前（ファイル内で一意）、説明、バージョン（セマンティックバージョニング推奨）、および remotes 配列（HTTP ベースのサーバー用）または packages 配列（ローカル stdio サーバー用）のいずれかが含まれます。簡略化した例を以下に示します。 { "servers": [ { "server": { "name": "my-remote-server", "description": "My server description", "version": "1.0.0", "remotes": [ { "type": "streamable-http", "url": "https://acme.com/my-server" } ] } }, { "server": { "name": "my-local-server", "description": "My server description", "version": "1.0.0", "packages": [ { "registryType": "npm", "identifier": "@acme/my-server", "transport": { "type": "stdio" } } ] } } ] } 完全な JSON スキーマと属性リファレンスについては、 Kiro MCP ガバナンスドキュメント を参照してください。 モデルガバナンス: 開発者が使用できるモデルを管理する Kiro は オープンウェイトモデル や Anthropic の最新モデル（ Opus 4.6 や Sonnet 4.6 など）のような新しいモデルオプションを追加し続けています。選択肢が増えることは開発者にとって良いことです。しかし、モデル承認プロセスを持つ企業にとって、新しいモデルが登場するたびに、誰かが使用できるようになる前に回答が必要なコンプライアンス上の問題が生じます。 本日、Kiro エンタープライズのお客様向けにモデルガバナンスも提供します。Kiro の管理者は、未承認のモデルを無効にすることで、開発者が利用できるモデルを制限できるようになりました。 明確にしておくと、これは「独自モデルの持ち込み」ではありません。モデルガバナンスは Kiro にモデルを追加するものではありません。すでに利用可能なリストからモデルを削除するものです。組織がまだモデルを承認していない場合、レビュープロセスが完了するまで開発者にオプションとして表示されないよう無効にできます。 なぜこれが重要なのか エンタープライズのモデル承認プロセスには正当な理由があります。モデルによってトレーニングデータの出所、ライセンス条件、データ処理の特性が異なります。新しいモデルを使用する前に法的レビューを必要とする組織もあります。数週間かかる技術評価プロセスを持つ組織もあります。 モデルガバナンスがなければ、Kiro が新しいモデルをリリースするたびに、組織内のすべての開発者がすぐに利用できるようになります。管理者は承認プロセスを適用する方法がなく、IDE でモデルを選択する前に開発者がポリシードキュメントを確認することに頼ることになります。それでは組織規模には対応できません。 データレジデンシーと実験的モデル これは特にデータレジデンシー要件を持つお客様にとって重要です。Kiro の一般提供モデルはリージョナルなクロスリージョン推論を使用しており、データは選択した地域（米国またはヨーロッパ）内に留まります。しかし、 実験的サポート でリリースされた新しいモデルはグローバルなクロスリージョン推論を使用する場合があり、リクエストが選択した地域外の AWS リージョンで処理される可能性があります。 データレジデンシー要件が高い組織にとって、この区別は重要です。グローバルに推論をルーティングする実験的モデルは、モデル自体が技術的に優れていても、コンプライアンス義務と互換性がない場合があります。 モデルガバナンスは管理者にこれを処理するための簡単な方法を提供します。データレジデンシー要件に対してレビューが完了するまで実験的モデルを無効にします。モデルが実験的段階からリージョナル推論を備えた一般提供段階に移行したら、有効にします。開発者は Kiro のタイムラインではなく、組織のタイムラインで新しいモデルにアクセスできます。 仕組み 管理者は AWS マネジメントコンソールの Kiro 管理設定を通じてモデルの可用性を設定します。インターフェースには Kiro がサポートするすべてのモデルと、その現在のステータス（GA または実験的）および推論スコープが表示されます。管理者はモデルのオン/オフを切り替えられます。無効にされたモデルは、IDE と CLI の両方で組織内のどの開発者のモデルセレクターにも表示されません。 Kiro が新しいモデルをリリースすると、管理者は準備が整うまで簡単にオフにできます。開発者は組織が承認したモデルのみを見ることができます。 今すぐ始めましょう MCP ガバナンスとモデルガバナンスは、 AWS IAM Identity Center 、 Okta、または Microsoft Entra ID を通じて認証する Kiro エンタープライズのお客様向けに、Kiro IDE 0.11.28 または Kiro CLI 1.23 以降で利用可能です。 Kiro 管理設定コンソール で MCP レジストリとモデルポリシーを設定してください。 翻訳は Solutions Architect の吉村 が担当いたしました。

はじめに こんにちは、サイオステクノロジーの小野です。 Kubernetesを利用する中で、yamlファイルの差分を確認することがよくあります。 差分確認コマンドと言えばdiffコマンドが一般的ですが、yamlファイルは行単位ではなく設定単位で比較を行いたいケースが多いので、diffコマンドを使うのが難しいです。 そんな時に役立つdyffというツールをご紹介します。 dyffとは dyffはテキストの「行」ではなく「データ構造（意味）」に基づいてYAMLやJSONファイルを比較するコマンドラインツールです。 dyffは以下の特徴があります。 キーの順序を無視して比較 人間が読みやすい出力形式 ツール連携 dyffインストール方法 dyffのインストール方法について詳しくは 公式のリポジトリ を参照してください。 バイナリファイルを用いてインストールする場合、以下のように実行します。 $ curl -LO https://github.com/homeport/dyff/releases/download/<バージョン>/dyff_<インストール環境>.tar.gz $ tar -xvzf dyff_<インストール環境>.tar.gz $ sudo chmod +x dyff $ sudo mv dyff /usr/local/bin/ Macをお使いの場合はHomebrewでインストールが可能です。 $ brew install homeport/tap/dyff LinuxやMacにdyffの最新バージョンを手軽にインストールしたい場合は以下のスクリプトを使うことが可能です。 $ curl --silent --location https://git.io/JYfAY | bash dyff使い方 例として以下の2つのyamlファイルを比較します。 # deployment-A.yaml apiVersion: apps/v1 kind: Deployment metadata: name: frontend-app namespace: production labels: app: frontend spec: replicas: 2 selector: matchLabels: app: frontend template: metadata: labels: app: frontend spec: containers: - name: nginx-container image: nginx:1.24.0 ports: - containerPort: 80 env: - name: ENVIRONMENT value: "prod" # deployment-B.yaml apiVersion: apps/v1 kind: Deployment metadata: name: frontend-app namespace: production labels: app: frontend team: ui-dev # ラベルが追加されている spec: replicas: 3 # レプリカ数が増えている selector: matchLabels: app: frontend template: metadata: labels: app: frontend team: ui-dev # ラベルが追加されている spec: containers: - name: nginx-container image: nginx:1.25.0 # イメージがバージョンアップしている env: # 環境変数設定とポート設定の記載が入れ替わっている - name: ENVIRONMENT value: "prod" ports: - containerPort: 80 ちなみにdiffコマンドを使って上記のyamlを比較すると以下のようになります。diffでは、ぱっと見でどんな設定差分があるのかわかりません。また、環境変数設定とポート設定の記載が入れ替わっただけだと設定的には差分がないですが、diffは行単位で差分比較するので、差分として出力されてしまいます。 $ diff deployment-A.yaml deployment-B.yaml 7a8 > team: ui-dev 9c10 < replicas: 2 --- > replicas: 3 16a18 > team: ui-dev 20,23c22,23 < image: nginx:1.24.0 < ports: < - containerPort: 80 < env: --- > image: nginx:1.25.0 > env: 25a26,27 > ports: > - containerPort: 80 使い方① yamlファイルの比較 dyffは以下のコマンドを実行することで、yamlファイルAからyamlファイルBはどのように差分があるのかを出力します。dyffはyamlファイルのどこが変更されたか、設定単位で確認することが可能です。したがって、一目で差分を確認することができます。また、記載が変更されても設定が変更されていなければ出力されないようになっています。 $ dyff between deployment-A.yaml deployment-B.yaml _ __ __ _| |_ _ / _|/ _| between deployment-A.yaml / _' | | | | |_| |_ and deployment-B.yaml | (_| | |_| | _| _| \__,_|\__, |_| |_| returned four differences |___/ metadata.labels + one map entry added: team: ui-dev spec.replicas ± value change - 2 + 3 spec.template.metadata.labels + one map entry added: team: ui-dev spec.template.spec.containers.nginx-container.image ± value change - nginx:1.24.0 + nginx:1.25.0 dyffのロゴが鬱陶しい場合はオプションで消すことも可能です。 $ dyff between -b deployment-A.yaml deployment-B.yaml metadata.labels + one map entry added: team: ui-dev spec.replicas ± value change - 2 + 3 spec.template.metadata.labels + one map entry added: team: ui-dev spec.template.spec.containers.nginx-container.image ± value change - nginx:1.24.0 + nginx:1.25.0 使い方②Kubernetesクラスターにデプロイされているリソースと yamlファイルの比較 Kubernetesにデプロイされているリソースとyamlファイルを比較する際に、以下のコマンドを実行することが良くあります。しかし、こちらもdiffコマンドと同様に行単位での比較を行っているため、どこの設定が変更されたのかわかりづらいです。 # deployment-A.yamlがデプロイされているKubernetesクラスターに対して、以下のコマンドを実行 $ kubectl diff -f deployment-B.yaml diff -u -N /tmp/LIVE-2041829305/apps.v1.Deployment.production.frontend-app /tmp/MERGED-4236462828/apps.v1.Deployment.production.frontend-app --- /tmp/LIVE-2041829305/apps.v1.Deployment.production.frontend-app 2026-03-26 18:24:38.226501887 +0900 +++ /tmp/MERGED-4236462828/apps.v1.Deployment.production.frontend-app 2026-03-26 18:24:38.227501925 +0900 @@ -6,16 +6,17 @@ kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{},"labels":{"app":"frontend"},"name":"frontend-app","namespace":"production"},"spec":{"replicas":2,"selector":{"matchLabels":{"app":"frontend"}},"template":{"metadata":{"labels":{"app":"frontend"}},"spec":{"containers":[{"env":[{"name":"ENVIRONMENT","value":"prod"}],"image":"nginx:1.24.0","name":"nginx-container","ports":[{"containerPort":80}]}]}}}} creationTimestamp: "2026-03-26T09:22:34Z" - generation: 1 + generation: 2 labels: app: frontend + team: ui-dev name: frontend-app namespace: production resourceVersion: "3430046" uid: 9602c096-6931-4278-ba8d-8dbaf9fd2faa spec: progressDeadlineSeconds: 600 - replicas: 2 + replicas: 3 revisionHistoryLimit: 10 selector: matchLabels: @@ -30,12 +31,13 @@ creationTimestamp: null labels: app: frontend + team: ui-dev spec: containers: - env: - name: ENVIRONMENT value: prod - image: nginx:1.24.0 + image: nginx:1.25.0 imagePullPolicy: IfNotPresent name: nginx-container ports: kubectl v1.20以降ではdyffを組み込んで、差分比較することが可能です。デフォルトのkubectl diffよりかなり見やすく設定差分を確認することができます。 $ export KUBECTL_EXTERNAL_DIFF="dyff between --omit-header --set-exit-code" $ kubectl diff -f deployment-B.yaml metadata.generation ± value change - 1 + 2 metadata.labels + one map entry added: team: ui-dev spec.replicas ± value change - 2 + 3 spec.template.metadata.labels + one map entry added: team: ui-dev spec.template.spec.containers.nginx-container.image ± value change - nginx:1.24.0 + nginx:1.25.0 –omit-headerのオプションは上記の-bオプションと同じでロゴを表示しないようにします。–set-exit-codeのオプションは差分が存在した場合は終了コード 1、差分がない場合は 0 を返すようにします。これによって、CI/CDなどの差分確認スクリプトの中に組み込んでも、差分があるかどうかを判定できるようになります。 使い方③Gitリポジトリ内の比較 Gitの過去のコミットを比較する際に、以下のコマンドを使います。Gitでよく見るコミット差分比較の出力です。 $ git log -u commit *** Author: *** Date: *** yamlの更新 diff -git a/deployment.yaml b/deployment.yaml *** @@ -5,8 +5,9 @@ namespace: production labels: app: frontend + team: ui-dev spec: - replicas: 2 + replicas: 3 selector: matchLabels: app: frontend @@ -14,12 +15,13 @@ metadata: labels: app: frontend + team: ui-dev spec: containers: - name: nginx-container - image: nginx:1.24.0 - ports: - - containerPort: 80 - env: + image: nginx:1.25.0 + env: - name: ENVIRONMENT value: "prod" + ports: + - containerPort: 80 Gitのコミット差分比較機能に対してもdyffを組み込むことが可能です。yamlのみですが、見やすく設定差分を確認することができます。 $ git config --local diff.dyff.command 'dyff_between() { dyff --color on between --omit-header "$2" "$5"; }; dyff_between' echo '*.yaml diff=dyff' >> .gitattributes $ git log --ext-diff -u commit *** Author: *** Date: *** yamlの更新 diff -git a/deployment.yaml b/deployment.yaml *** metadata.labels + one map entry added: team: ui-dev spec.replicas ± value change - 2 + 3 spec.template.metadata.labels + one map entry added: team: ui-dev spec.template.spec.containers.nginx-container.image ± value change - nginx:1.24.0 + nginx:1.25.0 –ext-diffオプションをつけることで、dyffの差分が確認できます。オプションを外せば従来の差分比較もできるので、使い分けたい方は上記の設定にして、オプションをつけるのがめんどくさい方はGitのエイリアスに登録してもよいかもしれません。 おわりに yamlの比較の確認がしやすいdyffの紹介をしました。Kubernetesの運用の中で、yamlの設定差分の見落としは危険です。しかし、ServiceやDeploymentといった単純な単体リソースの比較であればdiffでもなんとなく差分比較できますが、HelmアプリケーションのValuesといった数百、数千行あるような設定ファイルをdiffで比較するのはかなりの苦行だと思います。ぜひともdyffをインストールして、その苦行から解放されてください。 参考 dyff公式リポジトリ： https://github.com/homeport/dyff ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post YAMLの変更点を見落とさない！diffより強力なYAML差分確認ツール『dyff』のすすめ first appeared on SIOS Tech Lab .

こんにちは。SCSKの石田です。 本記事より、次世代APIプラットフォームとして世界中で注目を集めている「Kong API Gateway」についてのブログを開始したいと思います。初めてブログを投稿するため、至らない点もありますがご容赦ください。 昨今のエンタープライズシステムにおいて、クラウドネイティブ化やマイクロサービス化が進む中、システム同士をつなぐ「API」の数は爆発的に増加しています。第1回目となる今回は、なぜ今エンタープライズ企業においてAPIマネジメントが重要視されているのか、そして「Kong API Gateway」がどのようにその課題を解決するのか、概要を説明します。   爆発的に増加するAPIトラフィックと新たな課題 エンタープライズにおけるAPIマネジメントの重要性を語る上で外せないのが、APIトラフィックの圧倒的な増加です。 近年の複数のグローバル調査データ（ ※1 ）によると、現在の Webトラフィック全体の約70%以上がAPI経由の通信 であると報告されています。さらに特筆すべきは、AI技術の普及に伴う変化です。Postman社の「2025 State of the API Report」等によれば、 AI主導のAPI呼び出し（マシン間通信）が前年比で40%以上も急増 しており、APIは単なるアプリケーションの連携口から「AIエージェントの実行レイヤー」へと進化しつつあります。 ※1 参考： Postman「2025 State of the API Report」 、 The State of API Security in 2024 | Resource Library 等の各調査レポートより このように、人間が操作する端末からの通信だけでなく、システムやAIによる自動化された大量のリクエストが飛び交う中、各システム（社内システム、SaaS、パブリッククラウド上のサービスなど）が個別にAPIを公開・管理したままでは、以下のような課題に直面します。 セキュリティのガバナンス低下： 認証・認可の仕組み（OIDCやmTLSなど）が各システムでバラバラになり、脆弱性の温床になる。 トラフィック制御の複雑化： AI等によるリクエストの急増や攻撃から、バックエンドシステムを保護する仕組みが統合されていない。 運用負荷の増大： どのAPIが、誰に（どのシステムに）、どれくらい利用されているのかを一元的に把握できない。 これらの課題を解決し、増え続けるすべてのAPIトラフィックを安全かつ効率的に統合管理する仕組みこそが「APIマネジメント」であり、その入り口となるのがAPIゲートウェイです。   Kong API Gatewayとは？その特徴と強み Kong API Gatewayは、世界で最も利用されているオープンソースベースのAPIゲートウェイの一つです。エンタープライズ環境でKongが選ばれるのには、大きく3つの理由があります。 1. 圧倒的なパフォーマンスと軽量さ NGINXをベースに構築された軽量なアーキテクチャにより、極めて低いレイテンシで大量のAPIリクエストを処理できます。第三者評価機関であるGigaOm社のAPIマネジメントベンチマーク調査（ ※2 ）においても、他の製品と比較して圧倒的な高スループット（1ノードあたり毎秒5万件以上のトランザクション）と、サブミリ秒（1ミリ秒以下）の低レイテンシを記録し、その卓越したパフォーマンスが実証されています。AWSなどのクラウド環境やコンテナ環境との親和性が非常に高く、モダンなインフラ上でも軽快に動作します。 ※2 参考： GigaOm「API and Microservices Management Benchmark」 より 2. 豊富なプラグインエコシステム Kongの最大の魅力は、APIのルーティング機能だけでなく、高度な要件を「プラグイン」として簡単に追加できる点です。例えば、トラフィック制御（レート制限）、高度な認証・認可（OIDC、OAuth2.0、SAML、OPA連携）、ログ転送などを、バックエンドのコードを改修することなくAPIゲートウェイ層で一元的に実装・自動化できます。Kongにて一元的にこれらの機能を集めることで、API開発者の負荷を下げることができます。また、プラグインはノーコード・ローコードで実装できる点も強みです。 3. あらゆる環境に対応する柔軟性 Kongはコンテナとして動作するため、オンプレミス、マルチクラウド、ハイブリッドなど、どこにでもデプロイ可能です。SaaS型の管理基盤である「Kong Konnect」を利用すれば、グローバルに分散したAPIゲートウェイ群を単一のコントロールプレーンで統合管理することも可能です。   SCSKとKongのパートナーシップ 私たちSCSKは、Kong Inc.の公式パートナーとして、商用版Kongにおけるライセンスの提供からシステム構築・導入支援まで、エンタープライズ企業様向けのサービスを展開しています。 多数のAPIが乱立する大規模環境への導入や、既存のレガシーシステムからモダンアーキテクチャへの移行に伴うAPI基盤の刷新など、お客様の課題に合わせた最適な構成をご提案可能です。「自社のAPI管理に課題を感じている」「Kongの導入を検討したい」といったご相談があれば、ぜひお気軽に「kong-sales@scsk.jp」までお問い合わせください。   まとめ・今後の連載について 今回は第1回のため、APIトラフィック増加の背景とAPIマネジメントの重要性、そしてKong API Gatewayの概要についてご紹介しました。APIを安全かつ効率的に公開・管理することが、これからの開発スピードを左右する重要な要素となります。 次回以降は、Kongの基本的なAPIのルーティングや、プラグインの具体的な「やってみた」、さらに今や欠かせない「Kong AI Gateway」の紹介まで、エンジニア目線でより詳細な技術情報をお届けしていく予定です。 次回もぜひご期待ください！