はじめに

「Agentic AIの最大の障壁はテクノロジーではなく、オペレーティングモデルだ」――AWSのGenerative AI Innovation Center（GenAIIC）が2026年3月に公開したブログ記事のこの一文が、私たちRagateにとって深く刺さりました。

PoC（概念実証）は作れる。デモも動く。でも本番投入となった瞬間に立ちはだかる壁、それは「誰が、どう動かすのか」という組織的な問いです。AWSは2部構成のブログシリーズ「Agentic AIの運用化」の第2弾で、この問いに対してペルソナ別のアドバイスを提供しています。本記事では、そのエッセンスをRagateのエンジニア視点で噛み砕き、さらにAmazon BedrockとOpenClawを使った実践的なアプローチを加えて解説します。

Agentic AIとは？エンタープライズにおける位置づけ

Agentic AI（エージェンティックAI）とは、単純なチャットボットを超えて、複数のツールを横断しながら自律的にタスクを計画・実行できるAIシステムのことです。AWSの定義では、「必要な監視を最小限に抑えながら、理解・判断・行動できるプロアクティブで自律的なシステム」とされています。

McKinseyの調査によると、2026年時点で75%の企業が少なくとも1つの生成AIアプリケーションを業務利用しており、90%の企業が今後6〜12か月以内にAgentic AIを実装しようとしています。しかしながら、実際に本番環境でスケールアウトできているのは全体の40%にとどまります。

この「PoC止まり」問題の本質は何でしょうか。AWSのGenAIICチームが指摘するように、技術的な課題よりも「人材とプロセス」の課題が50%以上を占めています。つまり、Agentic AIを真に機能させるためには、組織の各役割（ペルソナ）が適切な責任を担う必要があるのです。

ペルソナ別活用ガイド

事業部門オーナー（P&Lオーナー）の役割

事業部門オーナーが最初にやるべきことは、エージェントをKPIに直結させることです。AWSのガイドでは、まずエージェントに「ジョブディスクリプション」を書くことを勧めています。「エージェントはXを受け取り、Yを確認し、Zを実行し、完了したらこのチームに引き継ぐ」という形式です。

弊社では実際に、この考え方をOpenClawのSKILL.mdに適用しています。各スキルファイルには「何を入力として受け取り、何を出力するか」を明記する形式を採用しており、AIエージェントの責任範囲が明確になっています。

事業部門オーナーが特に注目すべきKPI指標は以下のとおりです。

CTO/チーフアーキテクトの役割

CTOが直面する最大のリスクは「成功」です。最初のエージェントがうまく動くと、各チームが独自のスタックを構築し始め、フレームワーク・コネクタ・アクセスモデルがバラバラになった「エージェントの動物園」が生まれます。これはまさに私たちRagateが顧客支援の現場で見てきた課題です。

AWSのガイドはCTOに対し、「10個の優秀だが単発のエージェント」ではなく「100個のエージェントを安全にサポートできるシステム」を目指すべきと説きます。そのための設計原則として以下が挙げられています。

Amazon BedrockのAgentCoreはまさにこれを実現するプラットフォームです。MCP（Model Context Protocol）をネイティブサポートするAgentCore Gatewayにより、ツールの標準化が一気に進みます。

CISOの役割

AWSのガイドで特に印象的だったのが、CISOへのメッセージです。「エージェントを別のアプリケーションとして扱ってはいけない。エージェントは同僚に近い存在だ」という表現は、セキュリティの考え方を根本的に変えるものです。

実用的なアプローチとしてAWSが勧めるのは、人間に適用するのと同じ真剣さでエージェントのアイデンティティを設定することです。各エージェントに独自の認証情報・権限・監査証跡が必要で、実行するサービスアカウントのすべての権限を継承すべきではありません。

Amazon Bedrock AgentCore Identityは、まさにこの課題に対応します。エージェントのInbound（入り口）とOutbound（出口）の両方で認証を管理し、「テナントAのエージェントがテナントBのデータにアクセスできない」ような制御を実現します。

チーフデータオフィサー（CDO）の役割

CDOへのAWSのメッセージは「データを『退屈』にする」という逆説的な表現で示されています。エージェントに機能させるためのデータ基盤として必要なのは、派手なデータレイクではなく「エージェントが同じ質問に対して常に一貫した答えを返せる」データ品質です。

特に重要なのは、データリネージの明確化です。エージェントが下した意思決定が後から追跡できるよう、「なぜそのデータを使ったのか」を説明できる仕組みが必要です。これは後述するコンプライアンス観点とも密接に関連します。

AI/データサイエンスリーダー（CDSO/CAO）の役割

AI/データサイエンスをリードする人がついモデルに注目しがちなのは自然なことです。しかしAWSのガイドが強調するのは「評価システムこそが真のプロダクト」という考え方です。

効果的なAIエージェントの評価システムには、以下の3つの機能が必要です。

AWS Bedrockを使った実装アプローチ

AWSのペルソナ別ガイドを実装に落とし込む際、私たちRagateが注目しているのがAmazon Bedrock AgentCoreです。

AgentCoreは2025年10月に一般提供（GA）が開始されたAIエージェント専用のプラットフォームで、以下のコンポーネントで構成されています。

実際のコード例を見てみましょう。以下はStrands AgentsとBedrockを組み合わせたシンプルなエージェントの実装です。

from strands import Agent, tool
from strands.models import BedrockModel

# ツールの定義
@tool
def get_ticket_status(ticket_id: str) -> dict:
    """チケットIDからステータスを取得します"""
    # 社内システムAPIを呼び出す実装
    return {"id": ticket_id, "status": "open", "priority": "high"}

@tool
def update_ticket(ticket_id: str, status: str, note: str) -> dict:
    """チケットのステータスを更新します"""
    # 社内システムAPIを呼び出す実装
    return {"success": True, "ticket_id": ticket_id}

# Bedrockモデルの設定
model = BedrockModel(
    model_id="us.anthropic.claude-sonnet-4-5",
    region_name="us-east-1"
)

# エージェントの定義（ジョブディスクリプションをsystem_promptで明記）
agent = Agent(
    model=model,
    system_prompt="""あなたはサポートチケット管理エージェントです。
    - 未解決チケットを確認し、優先度に基づいて処理します
    - ステータス更新は必ず理由を記録してください
    - 判断に迷う場合は人間にエスカレーションしてください
    - 完了したらサマリーを報告してください""",
    tools=[get_ticket_status, update_ticket]
)

# エージェントの実行
response = agent("今日の高優先度チケットを確認して処理してください")
print(response)

このコードで重要なのはsystem_promptです。AWSのガイドで強調された「エージェントのジョブディスクリプション」を、system_promptとして明文化しています。責任範囲・判断基準・エスカレーション条件が明記されており、CTOが求める「観察可能性」とCISOが求める「境界の明確化」が同時に実現されています。

また、Amazon Bedrock Agentsのマルチエージェントコラボレーション機能を使えば、複数の専門エージェントをスーパーバイザーエージェントで統合できます。以下のような構成が典型的です。

import boto3

bedrock_client = boto3.client("bedrock-agent", region_name="us-east-1")

# マルチエージェントコラボレーション設定例
response = bedrock_client.create_agent(
    agentName="enterprise-supervisor",
    foundationModel="anthropic.claude-sonnet-4-5",
    instruction="タスクを分析し、適切なサブエージェントに委任してください",
    agentCollaborationSettings={
        "agentCollaborationSettings": [
            {
                "agentAliasArn": "arn:aws:bedrock:us-east-1:123456789:agent-alias/XXXXXXXX/YYYYYYYY",
                "collaborationDescription": "サポートチケットの確認・更新を担当",
                "collaborationName": "ticket-agent"
            }
        ]
    }
)

OpenClawで実現するAgentic AI組織運用

私たちRagateでは、AWSのペルソナ別ガイドで示された組織的なアプローチを、OpenClawという私たちが活用しているAIエージェント基盤で実践しています。

OpenClawのスキル機能は、まさにAWSが勧める「ジョブディスクリプション」の実装形態です。各スキルのSKILL.mdファイルには、エージェントの役割・入力・出力・禁止事項が明文化されており、運用上の境界が常に保たれています。

AWSのペルソナ別ガイドとOpenClawのアーキテクチャの対応関係は以下のとおりです。

特に弊社で重視しているのが「承認フロー」です。microCMSへの記事投稿・X（Twitter）への投稿・外部APIの呼び出しなど、リスクのあるアクションには必ずSlackでの承認フローが走ります。これはAWSガイドでCISOが強調した「実際に機能する停止スイッチ」そのものです。

エージェントが常に自律的に動き、人間が承認するのを待つという構造は、最初は面倒に感じます。しかしこれにより、エージェントの動作が組織の意図と乖離していないかを継続的にチェックできます。これがAWSガイドの言う「定期的な検証へのコミット」であり、本当の意味でのAgentic AI運用の基盤です。

まとめ

AWSの「Agentic AIの運用化 Part 2」が示すペルソナ別ガイダンスを振り返ると、共通するメッセージが見えてきます。それは「役割ごとの責任を明確にし、境界を設け、継続的に評価せよ」という原則です。

私たちRagateがAWSパートナーとして日々お客様と向き合う中で感じるのも、まったく同じことです。優れたAIエージェントシステムを構築したとしても、組織がそれを「どう動かすか」を設計していなければ、PoC止まりになってしまいます。

今回のAWSガイドは、その問いへの実践的な回答を提供しています。事業部門オーナーはKPIに紐づけ、CTOは基盤を設計し、CISOはガードレールを引き、CDOはデータを整備し、AIリーダーは評価システムを構築する。そしてコンプライアンス担当は最初から設計に参加する。

このような組織的な取り組みを、Amazon BedrockやOpenClawといったツールが下支えします。弊社では引き続き、お客様のAgentic AI組織化を技術・運用両面でサポートしていきます。Agentic AIの導入や組織的な運用体制の構築にご関心がある方は、ぜひRagateにお声がけください。