コンテンツにスキップ
これは最新の機能を備えた最新リリースですが、長期サポートは提供されません。サポートを継続するには、新しいリリースごとにアップグレードするか、四半期ごとの安定版リリースをご利用ください。

For the complete documentation index, see llms.txt. Markdown versions of all docs pages are available by appending .md to any docs URL.

AI アーティファクトのカタログを構築する

Page as Markdown
カタログの概要と、MCP サーバーとエージェントを公開して、組織全体で検出および再利用できるようにする方法を学びます。
中央レジストリがない場合、エージェント、MCP サーバー、スキル、プロンプトなどの AI アーティファクトは、GitHub リポジトリ、コンテナレジストリ、個々のワークステーションに分散します。アーティファクトはチーム間で重複し、デプロイされたバージョンはソース管理から乖離し、本番環境で何が実行されているのか、誰が作成したのかを示す信頼できる記録がありません。Solo Enterprise for agentregistry は、AI アーティファクトカタログでこの課題を解決します。これは、すべての AI アーティファクトに単一の信頼できるホームを提供し、本番 AI システムに必要な検出、ガバナンス、ライフサイクル制御を備えた、一元化されたバージョン管理ストアです。
カタログは、AI のためのパッケージレジストリと考えることができます。ソフトウェアエンジニアがライブラリを一度公開し、他のユーザーがそれをインポートするのと同じように、AI チームはエージェントと MCP サーバーを一度公開し、他のユーザーが任意のランタイムへデプロイできるようにします。すべてのアーティファクトには、次の機能を備えた正規のホームが用意されます。
  • 検出性: UI、arctl CLI、または REST API から、利用可能なすべてのエージェントと MCP サーバーを参照できます。
  • バージョニング: すべてのアーティファクトは、latest や v1.0.0 などのタグ付きで公開されます。任意のバージョンを個別にデプロイし、問題が発生した場合はロールバックできます。
  • 再利用: 一度公開された MCP サーバー、スキル、またはプラグインは、任意の数のエージェントに接続できます。
  • ガバナンス: アーティファクトをランタイムへデプロイする前にカタログへ登録する必要があるため、レビュー、ポリシー適用、監査可能性のための自然なゲートが作成されます。
Tip
Solo Enterprise for agentregistry を初めて使用する場合は、開始する前に主要な概念とアーキテクチャを確認してください。
このガイドについて

このガイドでは、MCP サーバーとエージェントをスキャフォールド、テスト、公開して AI アーティファクトカタログを構築し、両方を検出可能、バージョン管理済み、任意のランタイムへデプロイ可能な状態にします。
Solo Enterprise for agentregistry は、さまざまな種類のエージェントと MCP サーバーをサポートします。エージェントは、エンドツーエンドでビルドする自己完結型コンテナ (BYO エージェント) にすることも、エージェントハーネス内で実行されるスキルとプラグインの構成 (ハーネスエージェント) にすることもできます。MCP サーバーは、ビルドしてデプロイするパッケージ化されたサーバーにすることも、外部 URL ですでに実行されているリモートサーバーにすることもできます。全体像については、主要な概念を参照してください。
このガイドでは、最も一般的な開発パスである BYO エージェントとパッケージ化された MCP サーバーを扱います。完了すると、チームと共有できる AI カタログができあがります。このカタログには、次のアーティファクトが含まれます。
  • echo、sum、greet ツールを備えた、バージョン管理された Python MCP サーバー。
  • サイコロを振り、素数を確認できる、バージョン管理された Python エージェント。
  • オプションのソースリポジトリ参照を持つスキル。
  • システムプロンプトとして使用するインラインコンテンツを持つプロンプト。
このガイドでは、アーティファクトをランタイムへデプロイする方法は扱いません。このガイドの完了後にカタログアーティファクトをランタイムへデプロイするには、次のステップセクションにあるランタイム別のガイドのいずれかを参照してください。
始める前に

このガイドを完了するには、OIDC プロバイダーで構成された Solo Enterprise for agentregistry の実行中のインストールと、AI アーティファクトカタログの構築を開始するための arctl CLI が必要です。Solo Enterprise for agentregistry をまだセットアップしていない場合は、まず次の手順を完了してください。
  1. ユーザーがレジストリで認証できるように、OIDC プロバイダーをセットアップします。
  2. カタログの構築を開始できるように、Solo Enterprise for agentregistry をインストールし、arctl CLI をインストールします。
  3. 次のコマンドを実行して、ログイン済みであることを確認します。
    arctl user whoami
  4. まだ実施していない場合は、Solo Enterprise for agentregistry サーバーをポート 12121 でポートフォワードします。レジストリはデフォルトでは外部に公開されないため、ローカルマシンから到達するにはポートフォワードが必要です。
    kubectl -n agentregistry-system port-forward svc/agentregistry-enterprise-server 12121:12121
ステップ 1: MCP サーバーを登録する

MCP サーバーを登録すると、サーバーがレジストリカタログに追加され、カタログユーザーが検出したり、エージェント定義から参照したりできるようになります。
このステップでは、既存の MCP サーバーを追加するか独自の MCP サーバーを作成するかに応じて、さまざまな種類の MCP サーバーを登録する方法を説明します。状況に合うタブを選択してください。
リモート MCP サーバーは、Solo Enterprise for agentregistry の外部 URL で実行されます。MCP サーバーをデプロイまたは管理することはなく、Solo Enterprise for agentregistry を使用して再デプロイすることもできません。サーバーをカタログに登録した後、エージェント定義でそのサーバーを参照することで、ランタイム中にエージェントがサーバーのツールへアクセスできるようになります。
  1. リモート MCP サーバーのレジストリカタログエントリを作成します。次の例では、Solo.io ドキュメント MCP サーバーを使用します。
    arctl apply -f - <<EOF
apiVersion: ar.dev/v1alpha1
kind: MCPServer
metadata:
  name: remotemcp
spec:
  description: Remote MCP test server
  remote:
    type: streamable-http
    url: https://search.solo.io/mcp
EOF
    フィールド説明
    metadata.nameサーバーのカタログ名です。
    spec.remote.typeトランスポートタイプです。HTTP ベースの MCP サーバーには streamable-http を使用します。
    spec.remote.url/mcp などのパスを含む、リモート MCP サーバーの完全な URL です。
    出力例:
    ✓ MCPServer/remotemcp (latest) created

  2. リモート MCP サーバーがカタログに登録されたことを確認します。
    arctl get mcp
    出力例:
    NAME        TAG      DESCRIPTION
remotemcp   latest   Remote MCP test server

  3. レジストリ UI でカタログを開き、MCP サーバーが MCP servers に表示されていることを確認します。
チームが Solo Enterprise for agentregistry の外部ですでに MCP サーバーをビルドしており、それをカタログに取り込んで、レジストリ経由で検出およびデプロイできるようにする場合は、このパスを使用します。
検出のためにサーバーの URL のみを保存するリモートサーバー登録とは異なり、既存のサーバーをコンテナイメージまたはソースリポジトリ URL とともに登録すると、カタログユーザー向けの検出機能に加えて、Solo Enterprise for agentregistry が接続済みの任意のデプロイランタイムでサーバーのライフサイクルをデプロイおよび管理できます。
  1. パッケージ化された MCP サーバーの MCP サーバー定義ファイルを作成します。この定義は、レジストリに作成するカタログエントリを記述します。後で Solo Enterprise for agentregistry がサーバーをランタイムへデプロイできるように、ターゲットランタイムに応じてコンテナイメージまたはソースリポジトリのいずれかを指定します。
    • コンテナイメージ (spec.source.package.origin): Solo Enterprise for kagent にデプロイする場合に必要です。MCP サーバーをデプロイすると、レジストリはイメージをプルし、クラスター内で Pod として実行します。
    • ソースリポジトリ URL (spec.source.repository): AWS Bedrock AgentCore など、クラウド管理のエージェントプラットフォームにデプロイする場合に必要です。リポジトリには MCP ソースコードと Dockerfile が含まれている必要があります。デプロイ時に、Solo Enterprise for agentregistry はこれらのファイルを使用して、選択したランタイムで実行できる互換イメージをビルドします。
      Tip
      ソースリポジトリがプライベートの場合、レジストリがアクセスできるようにするには、レジストリクレデンシャルを設定し、リポジトリに credentialsRef を設定する必要があります。詳細については、プライベートリポジトリアクセスを参照してください。
    イメージを使用する MCP サーバー定義の例:
    arctl apply -f - <<EOF
apiVersion: ar.dev/v1alpha1
kind: MCPServer
metadata:
  name: mymcp
spec:
  description: My existing MCP server
  source:
    package:
      origin:
        type: oci
        identifier: localhost:5001/mymcp  
        oci:
          serverName: mymcp
      transport:
        path: /mcp
        port: 3000
        type: http
      launch:
        command: python3
        args:
          - type: positional
            value: src/main.py
          - type: positional
            value: --transport
          - type: positional
            value: http
          - type: positional
            value: --host
          - type: positional
            value: 0.0.0.0
          - type: positional
            value: --port
          - type: positional
            value: "3000"
EOF
    フィールド説明
    metadata.nameサーバーのカタログ名です。この名前はレジストリカタログに表示されます。
    spec.source.package.origin.typeオリジンタイプです。コンテナイメージには oci を使用します。
    spec.source.package.origin.identifierレジストリ、イメージ名、タグを含むコンテナイメージ参照です。
    spec.source.package.origin.oci.serverNameOCI イメージで定義されているサーバー名です。
    spec.source.package.transportサーバーが MCP エンドポイントを公開する方法です。
    spec.source.package.launchサーバーの起動に使用するコマンドと引数です。
    ソースリポジトリを使用する MCP サーバー定義の例:
    arctl apply -f - <<EOF
apiVersion: ar.dev/v1alpha1
kind: MCPServer
metadata:
  name: mymcp
spec:
  description: mymcp MCP server
  source:
    repository:
      url: https://github.com/solo-io/doc-examples
      subfolder: agentregistry/mymcp
EOF
    フィールド説明
    metadata.nameサーバーのカタログ名です。この名前はレジストリカタログに表示されます。
    spec.source.repository.urlMCP ソースコードと Dockerfile を保存する GitHub リポジトリの URL です。
    spec.source.repository.subfolderオプション。MCP サーバーのソースコードがリポジトリルートにない場合の、リポジトリ内のパスです。
  2. サーバーがカタログにあることを確認します。
    arctl get mcp
    出力例:
    NAME    TAG      DESCRIPTION
mymcp   latest   My existing MCP server

  3. レジストリ UI でカタログを開き、MCP サーバーが MCP servers に表示されていることを確認します。
arctl CLI を使用して、ツール付きのサンプル MCP サーバーをすばやくスキャフォールドします。スキャフォールドは、エントリポイント、Dockerfile、ツールディレクトリ、mcp.yaml 定義ファイルを備えた、すぐに実行できるプロジェクトを作成します。これは、後でサーバーをレジストリカタログへ公開するために必要なすべてです。
  1. MCP サーバーのスキャフォールドを作成します。次のコマンドは、mymcp という名前の FastMCP Python サーバーを作成します。このサーバーには、呼び出し元へメッセージを返す echo ツールと、2 つの数値を加算する sum ツールという 2 つのサンプルツールが事前に組み込まれています。
    arctl init mcp mymcp --framework fastmcp --language python \
 --description "Sample MCP server" \
 --image localhost:5001/mymcp:latest
    出力例:
    ✓ Created MCP server: mymcp (framework: fastmcp, language: python)

    スキャフォールドの一部として作成されたファイルを確認します。
    ファイル説明
    mcp.yamlカタログへ公開する MCP サーバー定義です。サーバーのメタデータ、トランスポート設定、イメージの場所を記述します。
    arctl.yamlスキャフォールド中に MCP サーバー設定を構成するために使用したフラグの概要です。
    Dockerfileコンテナ内で MCP サーバーをビルドして実行するための Dockerfile です。
    pyproject.toml依存関係とビルド設定を含む Python プロジェクト構成ファイルです。
    src/main.pyMCP サーバーをブートストラップして起動するエントリポイントです。
    src/core/FastMCP インスタンスと共有ユーティリティを含む、コアサーバーのソースコードです。
    src/tools/各ツールが独自の Python ファイルとして定義されるディレクトリです。スキャフォールドには、src/tools/ ディレクトリにすぐに使用できる 2 つのサンプルツールが含まれています。各ツールは、エージェントが会話中に呼び出せる @mcp.tool() Python 関数です。
    tests/サーバーとツール用に自動生成されたテストです。
  2. スキャフォールドによって作成されたツールを確認します。
    • echo.py: example_echo 関数は message 文字列を受け取り、それを変更せずに返します。ツールの構成で任意のプレフィックスが設定されている場合は、そのプレフィックスを先頭に追加します。プレフィックスは実行時に get_tool_config から読み取られるため、コードを編集せずに動作をカスタマイズできます。
    • sum.py: example_sum 関数は、整数または浮動小数点数として a と b の 2 つの数値を受け取り、その合計を返します。
    cat mymcp/src/tools/echo.py
cat mymcp/src/tools/sum.py
    echo.py ツールの出力例:
    from core.server import mcp
from core.utils import get_tool_config

@mcp.tool(description="Echo a message back to the client.")
def example_echo(message: str) -> str:
   config = get_tool_config("example_echo")
   prefix = config.get("prefix", "")
   return f"{prefix}{message}" if prefix else message

  3. src/tools/ ディレクトリに新しい .py ファイルを作成して、独自のツールを追加できます。各ファイルは、共有 mcp インスタンスを core.server からインポートし、@mcp.tool() でデコレートされた関数を少なくとも 1 つ定義する必要があります。ファイルはサーバー起動時に自動的に検出されるため、登録手順は不要です。
    次のコマンドは、入力として名前を受け取り、Hello, {name}! を返す greeting ツールを作成します。
    cat > mymcp/src/tools/greet.py << 'EOF'
from core.server import mcp

@mcp.tool(description="Return a greeting for the given name.")
def example_greet(name: str) -> str:
   return f"Hello, {name}!"
EOF
  4. スキャフォールドで生成された MCP サーバー定義 (mcp.yaml) ファイルを確認します。
    MCP サーバーをスキャフォールドすると、デフォルトのコンテナイメージの場所とタグ localhost:5001/mymcp:latest が MCP サーバー定義に追加されます。MCP サーバーをレジストリカタログに追加するには、MCP サーバー定義にイメージの場所、または Dockerfile と MCP ソースファイルを指すソースリポジトリ URL のいずれかが必要です。Solo Enterprise for agentregistry は、AWS Bedrock AgentCore などのエージェントプラットフォームへ AI アーティファクトをデプロイするときに、リポジトリ内のファイルを使用してランタイム固有のイメージをビルドします。MCP サーバーを Solo Enterprise for kagent にデプロイする予定の場合は、コンテナイメージを指定する必要があります。詳細については、イメージをビルドするかソースコードを保存するを参照してください。
    cat mymcp/mcp.yaml
    出力例:
    apiVersion: ar.dev/v1alpha1
kind: MCPServer
metadata:
  name: mymcp
spec:
  description: mymcp MCP server
  source:
    package:
      launch:
        args:
        - type: positional
          value: src/main.py
        - type: positional
          value: --transport
        - type: positional
          value: http
        - type: positional
          value: --host
        - type: positional
          value: 0.0.0.0
        - type: positional
          value: --port
        - type: positional
          value: "3000"
        command: python3
      origin:
        identifier: localhost:5001/mymcp:latest
        oci:
          serverName: mymcp
        type: oci
      transport:
        path: /mcp
        port: 3000
        type: http
  title: mymcp

  5. MCP サーバーのコンテナイメージをビルドして、ローカルで実行できるようにします。
    arctl build mymcp
    出力例:
    Building MCP server image: localhost:5001/mymcp:latest
Building Docker image for python project...
...
✓ Successfully built Docker image: localhost:5001/mymcp:latest

    Tip
    --push フラグを使用すると、必要に応じてコンテナイメージをレジストリへプッシュできます。
  6. MCP Inspector を使用して、ローカルマシンで MCP サーバーを実行します。--inspector フラグはサーバーを起動し、MCP Inspector を自動的に開くため、追加のセットアップなしでツールをテストできます。
    arctl run mymcp --inspector
    出力例:
    → fastmcp-python: docker run --rm -p 3000:3000 localhost:5001/mymcp:latest --transport http --host 0.0.0.0 --port 3000
2026-05-14 18:39:46,327 - INFO - Loaded tool module: sum
2026-05-14 18:39:46,329 - INFO - Loaded tool module: echo
2026-05-14 18:39:46,329 - INFO - 📦 Successfully loaded 2 tools
...
INFO     Starting MCP server 'mymcp' with transport 'http' on http://0.0.0.0:3000/mcp

  7. Inspector ツールで MCP サーバーに接続します。
  8. MCP ツールを試します。
    1. Tools タブに移動します。example_sum、example_echo、example_greet ツールが表示されていることを確認します。
    2. example_greet ツールを選択し、name フィールドに me などの任意の名前を入力します。
    3. Execute Tool をクリックし、Hello, me! メッセージが表示されることを確認します。
    4. 他のサンプル MCP ツールのテストを続けます。
    5. MCP Inspector を終了し、ctrl + c を押して実行中の MCP サーバーを停止します。
  9. レジストリカタログに MCP サーバーを公開します。
    arctl apply -f mymcp/mcp.yaml
    出力例:
    ✓ MCPServer/mymcp (latest) created

  10. MCP サーバーがカタログにあることを確認します。
    arctl get mcp
    出力例:
    NAME    TAG      DESCRIPTION
mymcp   latest   mymcp MCP server

  11. レジストリ UI でカタログを開き、MCP サーバーが MCP servers に表示されていることを確認します。
ステップ 2: エージェントを登録する

エージェントを登録すると、レジストリカタログに追加され、カタログユーザーが検出して、接続済みの任意のランタイムへデプロイできるようになります。
このステップでは、独自のエージェントをゼロから開発するか、チームがすでにビルドした既存のエージェントを登録するかに応じて、エージェントを登録する方法を説明します。状況に合うタブを選択してください。
チームが Solo Enterprise for agentregistry の外部ですでにエージェントをビルドしており、それをカタログに取り込んで、レジストリ経由で検出およびデプロイできるようにする場合は、このパスを使用します。
独自のエージェントをゼロから開発する場合とは異なり、既存のエージェントをコンテナイメージまたはソースリポジトリ URL とともに登録すると、カタログユーザー向けの検出機能に加えて、Solo Enterprise for agentregistry が接続済みの任意のデプロイランタイムでエージェントのライフサイクルをデプロイおよび管理できます。
  1. 既存のエージェントのレジストリカタログエントリを作成します。後で Solo Enterprise for agentregistry がエージェントをランタイムへデプロイできるように、ターゲットランタイムに応じてコンテナイメージまたはソースリポジトリのいずれかを指定します。
    • コンテナイメージ (spec.source.image): Solo Enterprise for kagent にデプロイする場合に必要です。エージェントをデプロイすると、レジストリはイメージをプルし、クラスター内で Pod として実行します。
    • ソースリポジトリ URL (spec.source.repository): AWS Bedrock AgentCore など、クラウド管理のエージェントプラットフォームにデプロイする場合に必要です。リポジトリにはエージェントソースコードと Dockerfile が含まれている必要があります。デプロイ時に、Solo Enterprise for agentregistry はこれらのファイルを使用して、選択したランタイムで実行できる互換イメージをビルドします。
      Tip
      ソースリポジトリがプライベートの場合、レジストリがアクセスできるようにするには、レジストリクレデンシャルを設定し、リポジトリに credentialsRef を設定する必要があります。詳細については、プライベートリポジトリアクセスを参照してください。
    イメージを使用するエージェント定義の例:
    arctl apply -f - <<EOF
apiVersion: ar.dev/v1alpha1
kind: Agent
metadata:
  name: myagent
spec:
  description: My existing agent
  source:
    image: localhost:5001/myagent:latest
EOF
    ソースリポジトリを使用するエージェント定義の例:
    arctl apply -f - <<EOF
apiVersion: ar.dev/v1alpha1
kind: Agent
metadata:
  name: myagent
spec:
  description: My existing agent
  source:
    repository:
      url: https://github.com/solo-io/doc-examples
      subfolder: agentregistry/myagent
EOF
    フィールド説明
    metadata.nameエージェントのカタログ名です。この名前はレジストリカタログに表示されます。
    spec.source.repository.urlエージェントソースコードと Dockerfile を保存する GitHub リポジトリの URL です。
    spec.source.repository.subfolderオプション。エージェントソースコードがリポジトリルートにない場合の、リポジトリ内のパスです。
    spec.source.imageレジストリ、イメージ名、タグを含むコンテナイメージ参照です。
    出力例:
    ✓ Agent/myagent (latest) created

  2. エージェントがカタログにあることを確認します。
    arctl get agents
    出力例:
    NAME      TAG      DESCRIPTION
myagent   latest   My existing agent

  3. レジストリ UI でカタログを開き、エージェントが Agents に表示されていることを確認します。
arctl CLI を使用して、サンプルエージェントをすばやくスキャフォールドします。スキャフォールドは、Dockerfile、エージェント定義、エージェントソースコードを備えた、すぐに実行できるエージェントを作成します。これは、後でエージェントをレジストリカタログへ公開するために必要なすべてです。
  1. エージェントのスキャフォールドを作成します。次のコマンドは、デフォルトの LLM プロバイダーとして Gemini を使用する Google ADK ベースのエージェントを作成します。
    arctl init agent myagent --framework adk --language python  --model-provider gemini --model-name gemini-2.5-flash
    出力例:
    ✓ Created agent: myagent (framework: adk, language: python)

🚀 Next steps:
1. Run locally (optional):
   arctl run myagent
2. Publish to the registry:
   arctl apply -f myagent/agent.yaml

    スキャフォールドは次のファイルを作成します。
    ファイル説明
    agent.yamlカタログへ公開するエージェント定義です。エージェントのソースイメージとメタデータを記述します。
    arctl.yamlarctl CLI で指定したエージェントの詳細で、公開時にメタデータラベルを挿入するために使用されます。
    .envLLM プロバイダーの API キーなど、エージェントのローカル環境変数です。
    docker-compose.yamlエージェントをローカルで実行するための Docker Compose ファイルです。
    Dockerfileコンテナ内でエージェントをビルドして実行するための Dockerfile です。
    myagent/エージェントの動作を定義する agent.py を含む、エージェントソースディレクトリです。
    otel-collector-config.yamlエージェント用の OpenTelemetry 構成です。
    pyproject.tomlPython プロジェクトの依存関係ファイルです。
    README.mdはじめにとカスタマイズ手順に関するメモです。
  2. スキャフォールドで生成されたエージェント定義 (agent.yaml) ファイルを確認します。
    エージェントをスキャフォールドすると、デフォルトのコンテナイメージの場所とタグ localhost:5001/myagent:latest がエージェント定義 (agent.yaml) ファイルに追加されます。エージェントをレジストリカタログへ追加するには、エージェント定義にイメージの場所、または Dockerfile とエージェントソースファイルを指す GitHub または GitLab リポジトリ URL のいずれかが必要です。Solo Enterprise for agentregistry は、これらのファイルを使用して、AWS Bedrock AgentCore などのエージェントプラットフォームへ AI アーティファクトをデプロイするときにランタイム固有のイメージをビルドします。
    このチュートリアルでは、デフォルトの localhost:5001/myagent:latest イメージの場所を使用してイメージをビルドします。代わりにプライベートレジストリ、または GitHub や GitLab のリポジトリ URL を使用するには、agent.yaml ファイルの source.image または source.repository フィールドを更新します。詳細については、イメージをビルドするかソースコードを保存するを参照してください。
    cat myagent/agent.yaml
    出力例:
    apiVersion: ar.dev/v1alpha1
kind: Agent
metadata:
  name: myagent
spec:
  description: myagent agent
  source:
    image: localhost:5001/myagent:latest

  3. カタログへ公開する前に、エージェントのコンテナイメージをビルドします。
    arctl build myagent
    出力例:
    Building agent image: localhost:5001/myagent:latest
Building Docker image for python project...
...
✓ Successfully built Docker image: localhost:5001/myagent:latest

    Tip
    --push フラグを使用すると、必要に応じてコンテナイメージをレジストリへプッシュできます。
  4. Gemini LLM プロバイダーの API キーを保存します。このチュートリアルでスキャフォールドするエージェントは、デフォルトで Google ADK と Gemini プロバイダーを使用します。エージェントと対話するには、API キーが必要です。Google AI Studio にログインし、API Keys を選択して API キーを取得または作成できます。
    GOOGLE_API_KEY=your-api-key-here
  5. ローカルマシンでエージェントを起動します。次のコマンドはエージェントを起動し、チャットウィンドウを開きます。
    arctl run myagent
    出力例:
    [+] Running 2/2
 ✔ Container myagent-otel-collector-1  Started
 ✔ Container myagent-myagent-1         Started

  6. エージェントとチャットします。たとえば、何ができるかを尋ねることができます。その後、Enter を押してエージェントの応答を待ちます。ctrl + c キーを使用してエージェントを終了できます。
  7. レジストリカタログにエージェントを公開します。
    arctl apply -f myagent/agent.yaml
    出力例:
    → Injecting labels from arctl.yaml: arctl.dev/framework=adk, arctl.dev/language=python
✓ Agent/myagent (latest) created

  8. エージェントがカタログにあることを確認します。
    arctl get agents
    出力例:
    NAME      TAG      MODE     DESCRIPTION
myagent   latest   source   myagent agent

  9. レジストリ UI でカタログを開き、エージェントと MCP サーバーを含むカタログを確認します。
ステップ 3: スキルを登録する

スキルを公開すると、再利用可能な指示セットまたはスラッシュコマンドがカタログに追加され、どのチームでもそれを検出し、エージェント構成から参照できるようになります。
  1. スキル定義を作成し、レジストリカタログにスキルを追加します。
    arctl apply -f- <<EOF
apiVersion: ar.dev/v1alpha1
kind: Skill
metadata:
  name: myskill
spec:
  title: myskill
  description: myskill skill
  source:
    repository:
      url: https://github.com/solo-io/doc-examples
      subfolder: agentregistry/myskill  # optional
EOF
    Tip
    独自のスキルを作成するには、スキルスキャフォールドを作成する arctl init skill myskill コマンドを使用します。その後、スキャフォールド内のファイルを必要に応じて調整します。
  2. スキルがカタログにあることを確認します。
    arctl get skills
    出力例:
    NAME      TAG      DESCRIPTION
myskill   latest   myskill skill

  3. レジストリ UI でカタログを開き、スキルが Skills に表示されていることを確認します。
ステップ 4: プロンプトを登録する

プロンプトを公開すると、バージョン管理された組織全体のシステムプロンプトまたは指示テンプレートがカタログに追加されます。プラットフォームチームは、安全性ガードレール、エージェントのペルソナガイドライン、承認済みの推論フレームワークなどの標準ベースラインを公開し、開発チームはそれをエージェント構成から参照できます。
  1. プロンプト定義を作成し、レジストリカタログに追加します。プロンプト定義には 2 つの異なるフィールドが含まれます。
    • spec.content: エージェントがランタイムでシステムプロンプトとして使用する実際のプロンプトテキストです。
    • spec.description: arctl get prompts と UI に表示される短いカタログラベルです。プロンプト本文ではなく、プロンプトの用途を説明します。
    arctl apply -f- <<EOF
apiVersion: ar.dev/v1alpha1
kind: Prompt
metadata:
  name: myprompt
spec:
  content: You are a concise technical assistant. Answer only what is asked. Do not add preamble, filler, or suggestions unless explicitly requested. If you are unsure, say so rather than guessing.
  description: Concise technical assistant baseline
EOF
    出力例:
    ✓ Prompt/myprompt (latest) created

  2. プロンプトがカタログにあることを確認します。
    arctl get prompts
    出力例:
    NAME       TAG      DESCRIPTION
myprompt   latest   Concise technical assistant baseline

  3. レジストリ UI でカタログを開き、プロンプトが Prompts に表示されていることを確認します。
これで、バージョン管理された MCP サーバー、エージェント、スキル、プロンプトを含む、機能するカタログができあがりました。すべてのアーティファクトは検出可能で再利用でき、Solo Enterprise for agentregistry がサポートする任意のランタイムへデプロイする準備ができています。
次のステップ

カタログにデータが登録されたので、次に実行したいことに基づいてパスを選択します。
カタログアクセスを管理する

カタログへアーティファクトを公開できるユーザーを制御し、アーティファクトが他のチームに表示される前に承認を要求し、デプロイされたエージェントがランタイムで呼び出せる対象を制限します。

アクセス制御
OIDC 認証を構成し、ユーザーとグループのアクセスポリシーを定義します。

アーティファクトの承認
アーティファクト承認モードを有効にし、UI、API、または Python クライアントを通じて承認キューを管理します。
エージェントを検出する

ディスカバリーランタイムに接続して、レジストリ外でデプロイされたエージェントをカタログ化します。

Azure AI Foundry 上のエージェントを検出する
Azure AI Foundry に接続し、既存のエージェントをレジストリに表示します。

Microsoft Copilot Studio 上のエージェントを検出する
Microsoft Copilot Studio に接続し、既存のエージェントをレジストリに表示します。
ランタイムへデプロイする

デプロイランタイムに接続し、カタログアーティファクトをプッシュして、エージェントが実行され、ツールをユーザーが利用できるようにします。

Solo Enterprise for kagent
Solo Enterprise for kagent を使用して、カタログアーティファクトを Kubernetes クラスターへデプロイします。

AWS Bedrock AgentCore
カタログアーティファクトを AWS Bedrock AgentCore へデプロイします。
agentgateway で MCP サーバーを公開して保護する