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

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

イメージをビルドする

Page as Markdown

各デプロイプラットフォーム向けにエージェントの Docker イメージをビルドします。

レジストリユーザーがエージェントにアクセスし、接続済み環境にデプロイできるように、エージェントを Solo Enterprise for agentregistry カタログに追加する前に、エージェントの Docker イメージをビルドしてコンテナレジストリにプッシュする必要があります。ビルド手順は、エージェントをデプロイする予定のランタイムによって異なります。

デプロイターゲットプロバイダーの例ビルド手順
Kubernetes 内の AI ランタイムSolo Enterprise for kagentDocker イメージをビルドし、クラスターがプルできるコンテナレジストリにプッシュします。
エージェント型クラウドプラットフォームAWS Bedrock AgentCoreDocker イメージをビルドし、Amazon ECR にプッシュして、agent-proxy レイヤーでラップします。

Docker イメージをビルドする

Solo Enterprise for agentregistry は、arctl CLI を使用してローカルマシン上でエージェントの Docker コンテナイメージをビルドし、コンテナレジストリにプッシュします。後でエージェントを Solo Enterprise for agentregistry カタログに追加するときに、イメージリポジトリとタグを含むコンテナイメージの場所への参照を作成します。これにより、Solo Enterprise for agentregistry はイメージを取得し、デプロイ時にエージェントを起動できます。

ビルド手順は、ほとんどのデプロイターゲットで同じです。AWS Bedrock AgentCore には 2 つの追加要件があります。イメージは linux/arm64 プラットフォームをターゲットにして Amazon ECR にプッシュする必要があり、さらに agent-proxy レイヤーでラップする必要があります。agent-proxy は、ランタイムに管理対象ゲートウェイがアタッチされていない場合でもエージェントのトラフィックをキャプチャしてログに記録します。管理対象ゲートウェイがアタッチされている場合は、そのトラフィックをゲートウェイ経由でもルーティングするため、エージェントは MCP サーバーと通信でき、ランタイム認可を設定できます。

Docker イメージをビルドするには、次のオプションから選択できます。

  • ローカルでイメージをビルドする。このオプションは、ローカルのテストセットアップなど、ローカルマシン上でのみエージェントイメージをビルドする場合を想定しています。イメージはコンテナレジストリにプッシュされません。Solo Enterprise for agentregistry でエージェントイメージのカタログエントリを作成することはできますが、イメージをクラスターに手動でロードしない限り、Kubernetes クラスターにデプロイすることはできません。
  • ビルドしてプッシュする: このプロセスでは、ローカルマシンでエージェントイメージをビルドしてコンテナレジストリにプッシュできます。このオプションを使用するには、使用するコンテナレジストリにログインしており、agent.yaml ファイルに正しいコンテナレジストリとイメージタグの詳細が含まれている必要があります。
  1. ローカルマシンでエージェントを作成して実行します。

  2. agent.yaml ファイルでエージェントに設定されたイメージの場所とタグを確認します。

    デフォルトでは、agentregistry はコンテナレジストリとして localhost:5001、イメージタグとして latest を使用します。たとえば localhost:5001/myagent:latest です。agentregistry を使用してコンテナレジストリにイメージをプッシュする場合は、使用するレジストリとイメージタグでこのファイルを更新してください。コンテナレジストリにプッシュせずにローカルでのみイメージをビルドする場合、この更新は不要です。

    cat myagent/agent.yaml

    出力例:

    apiVersion: ar.dev/v1alpha1
    kind: Agent
    metadata:
      name: myagent
    spec:
      source:
         image: localhost:5001/myagent:latest
      modelProvider: gemini
      modelName: gemini-2.5-flash
      description: myagent agent
    
  3. ローカルマシンでエージェントイメージをビルドします。次のコマンドは、myagent スキャフォールドに含まれる Dockerfile でイメージをビルドし、agent.yaml ファイルで指定されたコンテナレジストリとバージョン情報でタグ付けします。エージェントの作成と実行ガイドの手順に従った場合は、localhost:5001/myagent:latest が使用されます。

    arctl build myagent

    出力例:

    Building agent image: localhost:5001/myagent:latest
    ✓ Successfully built Docker image: localhost:5001/myagent:latest
    

    Tip

    Solo Enterprise for agentregistry を使用してイメージをコンテナレジストリにプッシュする場合は、--push オプションを含めます。また、--platform オプションを使用して、linux/amd64 などイメージをビルドするプラットフォームを設定できます。DockerHub の場合は docker login を使用するなど、先にコンテナレジストリにログインしておく必要があります。詳しくは arctl build コマンドを参照してください。

  4. イメージがビルドされていることを確認します。

    docker images | grep myagent

    出力例:

    localhost:5001/myagent latest  f7ba3e98adaa   11 minutes ago     2.93GB
    
  5. イメージをコンテナレジストリにプッシュしなかった場合は、Docker イメージをクラスターにロードします。この手順は、kind などのローカルテストセットアップで、後でエージェントのデプロイをテストするために必要です。クラスターがプルできるコンテナイメージレジストリにイメージをプッシュした場合、この手順は不要です。

    kind load docker-image localhost:5001/myagent:latest --name <cluster-name>

AWS Bedrock AgentCore でエージェントを実行するには、イメージを agent-proxy レイヤーでラップする必要があります。agent-proxy レイヤーは、オブザーバビリティと監査のために、エージェントのすべてのアウトバウンドトラフィックをインターセプトし、送信元、宛先、バイト数をログに記録します。AgentCore ランタイムをセットアップするときに管理対象ゲートウェイを作成した場合、agent-proxy レイヤーはさらにすべてのアウトバウンドトラフィックをゲートウェイ経由に再ルーティングし、ゲートウェイがランタイム認可ポリシーを適用し、エージェントと AgentCore にデプロイされている MCP サーバー間の通信を仲介できるようにします。

エージェントイメージを agent-proxy レイヤーでラップするには、arctl wrap-agent-image コマンドを使用します。ラップの対象になるには、Dockerfile が次の要件を満たしている必要があります。

  • Dockerfile では実際の ENTRYPOINT または CMD を設定する必要があります。イメージの起動コマンドは、agent-proxy レイヤー経由で起動するように書き換えられます。Dockerfile に起動コマンドが設定されていない場合、イメージのラップは失敗します。
  • Dockerfile で root 以外の USER を設定する場合、そのユーザーはイメージ自身の /etc/passwd ファイルと /etc/group ファイルから解決できる必要があります。agent-proxy レイヤーはエージェントを起動するときにこのユーザーを保持し、ID を解決できない場合は起動に失敗します。
  • エージェントは、AWS Bedrock AgentCore がリクエストを転送するポートでリッスンする必要があります。A2A プロトコルでは 9000、エージェント定義で spec.source.protocol が HTTP に設定されている場合は 8080 です。agent-proxy レイヤーは各インバウンドリクエストをこの同じポート上のエージェントに転送します。

AWS Bedrock AgentCore は、AgentCore ランタイムと同じ AWS アカウントおよびリージョン内のプライベート Amazon ECR リポジトリからプルする linux/arm64 イメージだけを実行します。そのため、ラップ済みイメージを Amazon ECR リポジトリにプッシュする必要があります。

  1. ローカルマシンでエージェントを作成して実行します。

  2. エージェントイメージ用のプライベート Amazon ECR リポジトリがまだない場合は作成します。詳細については、AWS ドキュメントのプライベートリポジトリの作成を参照してください。

    aws ecr create-repository \
      --repository-name myagent \
      --region <region>

    出力例:

    {
      "repository": {
        "repositoryUri": "123456789012.dkr.ecr.us-east-1.amazonaws.com/myagent",
        ...
      }
    }
    
  3. Docker を ECR レジストリに認証します。

    aws ecr get-login-password --region <region> \
      | docker login --username AWS --password-stdin <account-id>.dkr.ecr.<region>.amazonaws.com
  4. linux/arm64 イメージをビルドし、先ほど取得した AWS ECR リポジトリ URI にプッシュします。Dockerfile が前述の要件を満たしていることを確認してください。このステップで作成するイメージは、エージェントのベースイメージになります。後でこのイメージの上に agent-proxy を重ね、ラップ済みイメージも同じリポジトリにプッシュします。

    Note

    AgentCore は、この後のステップで作成するラップ済みイメージからエージェントを起動します。このステップで作成するベースイメージからは起動しません。ベースイメージは任意のコンテナレジストリに保存できます。ただし、このガイドでは、ベースイメージをラップ済みイメージと同じリポジトリに保存することを前提とします。

    arctl build myagent \
      --image 123456789012.dkr.ecr.us-east-1.amazonaws.com/myagent:latest \
      --platform linux/arm64 \
      --push

    出力例:

    Building agent image: 123456789012.dkr.ecr.us-east-1.amazonaws.com/myagent:latest
    ✓ Successfully built Docker image: 123456789012.dkr.ecr.us-east-1.amazonaws.com/myagent:latest
    ✓ Pushed image: 123456789012.dkr.ecr.us-east-1.amazonaws.com/myagent:latest
    
  5. プッシュ済みのベースイメージを agent-proxy レイヤーでラップし、別のタグを付けて同じリポジトリにプッシュします。AWS Bedrock AgentCore は、エージェントランタイムをデプロイするときにラップ済みイメージだけをプルします。

    arctl wrap-agent-image \
      --image 123456789012.dkr.ecr.us-east-1.amazonaws.com/myagent:latest \
      --tag 123456789012.dkr.ecr.us-east-1.amazonaws.com/myagent:wrapped \
      --platform linux/arm64 \
      --push
    設定説明
    --imageラップするエージェントイメージです。
    --tagラップ済みイメージに割り当てる参照です。ラップ前のイメージも利用可能なままにするため、新しいタグを使用します。
    --platformベースイメージのプラットフォームです。AWS Bedrock AgentCore では linux/arm64 を使用します。
    --push--tag オプションで定義したリポジトリに、ラップ済みイメージを直接プッシュします。
  6. agent.yaml ファイル内のエージェント定義で、spec.source.image フィールドを 123456789012.dkr.ecr.us-east-1.amazonaws.com/myagent:wrapped などのラップ済みイメージタグに更新します。

ソースコードを保存する

Agent リソースには、エージェントの Dockerfile とソースコードを格納する GitHub または GitLab リポジトリへの spec.source.repository 参照も含めることができます。

spec:
  source:
    image: 123456789012.dkr.ecr.us-east-1.amazonaws.com/myagent:wrapped
    repository:
      url: https://github.com/myorg/agent.git
      credentialsRef:
        name: git-credentials
フィールド説明
urlエージェントの Dockerfile とソースコードを格納する GitHub または GitLab リポジトリの URL です。
branch読み取るブランチです。省略すると、リポジトリのデフォルトブランチが使用されます。
commit固定する特定のコミットです。省略すると、branch の最新コミットが使用されます。
subfolderエージェントの Dockerfile とソースコードがリポジトリのルートにない場合のパスです。
credentialsRef.nameプライベートリポジトリの場合にのみ必須です。GitHub または GitLab の認証情報を保持する Secret の名前です。

Note

プライベートリポジトリを参照する場合は、GitHub または GitLab の認証情報を設定し、リポジトリに credentialsRef を設定する必要があります。詳細については、プライベートリポジトリアクセスを参照してください。

Important

AWS Bedrock AgentCore では、前述のとおり、ビルドしてラップした Docker イメージを spec.source.image に設定します。spec.source.image が Amazon ECR リポジトリに解決されない場合、AWS Bedrock AgentCore は代わりに spec.source.repository からイメージをビルドして実行します。このイメージには agent-proxy レイヤーが含まれていません。エージェントのトラフィックを管理対象ゲートウェイ経由でルーティングできないため、ランタイム認可やエージェントと MCP サーバー間のルーティングに影響します。

次の手順