本記事ではCognito Managed Loginについての紹介を行います。 Amazon Cognito Managed Loginとは AWSが提供するAmazon Cognitoの認証画面です。 Cognitoを用いた認証システムに必要な操作が一通り実装されており、マネジメントコンソールから確認できるURLにアクセスすれば認証画面を作成せずともCognitoの認証を使用することができます。 Cognitoに外部IdP（GoogleやAppleなど）を追加すれば、Managed Login画面からも外部IdP認証を行うことができるようになります。 画像を見ていただくとわかる通りデフォルトデザインとは思えないほどデザインがしっかりしています。     Hosted UIとの違い Hosted UIはManaged Loginが実装される前から存在しているAWS提供のCognito認証画面です。 Managed Loginは機能、デザインともにHosted UIから大きくアップデートされています。 今から使用するならManaged Login一択でよいかと思います。 Hosted UIからの変更点は以下の通りです。 デフォルトデザイン面で大幅なアップデート マネジメントコンソールからノーコードで画面デザインの変更が可能になった パスキー、パスワードレス等の認証フローにも対応可能になった   ノーコードでの画面デザインの変更 Managed Loginはマネジメントコンソールからノーコードでデザインを変更することができます。 以下は変更できる内容の一部です。 ページ背景（画像挿入または背景色の設定） フォーム（入力部分）の位置変更 ロゴ挿入 ボタンの形、色の変更 ヘッター、フッターの追加 以下簡単に設定を変更してみました。   Managed Loginのメリット Managed Loginのメリットは以下の通りです。 〇認証画面の作成が不要になる 画面設計だけでなくAPIでの認証フロー実装も不要で認証機能を利用できます。 サインアップ、サインイン、パスワード変更など認証機能を実装しようとすると複数画面、複数機能の実装が必要になります。 それぞれ別種のAPIを1~3個ほど呼び出す必要があり認証フローを成立させるだけでもそこそこの作りこみを要求されますが、それらをすべて省略することができます。 〇ブラウザにセッションが残る 実はManaged Loginはセッション管理もしてくれます。 そのため、コード実装いらずでOkta等より低コストにSSOを実装することができます。   Managed Loginのデメリット Managed Loginのデメリットは以下の通りです。 〇画面デザインの変更に制限がある 画面デザインの変更はAWSが提供するコンポーネントでしかできないため複雑なデザイン等は難しいです。 簡単な文章の追加やボックス内に表示される文字列の変更ができないため、ぱっと見の印象を変える以上の変更はできないくらいの塩梅になります。 サイドバーの追加やリンクの埋め込み等もできないため、デザインにこだわる場合は独自に認証画面を実装する必要があります。 〇認証フローを制御できない AWSが提供するデフォルト画面遷移にしか対応しておりません。 独自認証フローを追加するためカスタム認証トリガー等を設定していてもManaged Loginでは利用できません。   まとめ Managed LoginはAWSが提供するCognitoの認証画面です。 自前で認証画面を用意せずとも認証システムをアプリに組み込むことができます。 最低限の認証しか要求されない場合や個人レベルの認証システムとしては十二分に機能します。

こんにちは。SCSK渡辺(大)です。 2026年4月22日にプレビューリリースされた Amazon Bedrock AgentCore Managed Harness （以下、AgentCore Harness）を、AWSマネジメントコンソールで触ってみました。 私と同じく「AIエージェントを動かす基盤」と言われてもピンとこない方向けに、コンソール操作の流れに沿って「何が作られるのか」「料金はどうなるのか」等の整理をしてみました。   AgentCore Harnessをひとことで言うと 「モデル・指示文・ツールを指定するだけで、コードを書かずにAIエージェントが動く仕組み」です。 通常、AIエージェントを作るには「モデルを呼ぶ→ツールを使うか判断→ツール実行→結果をモデルに戻す→また判断…」というループ処理を自分で実装する必要があります。AgentCore Harnessはこのループ処理をAWSが全部やってくれるので、開発者はコンソールでの設定やJSON定義だけで済みます。 AWS公式ブログ でも以下のように説明されています（筆者要約）。 エージェントを動かすには、フレームワーク選定、オーケストレーションコードの実装、ツール接続、認証設定など、多くのインフラ作業が必要でした。 そのため、殆どのチームがエージェントのロジックではなくインフラに何日も費やしていました。 AgentCore Harnessはこれらを設定に置き換え、数分でエージェントをテストできるようにします。 AgentCore harness overview - Amazon Bedrock AgentCore Every agent has an orchestration layer: the loop that calls the model, decides which tool to invoke, passes results back... docs.aws.amazon.com 勘違いしやすいサービスとの比較 「AIエージェント」に関連するAWSサービスが複数あるため、混乱しやすいです。 Claude Code 、Kiro との比較 Claude CodeやKiroもエージェント的に動作しますが、AgentCore Harnessとは役割が全く異なります。 Claude Code、Kiro ：開発者の作業を効率化するツール AgentCore Harness ：エンドユーザー向けエージェントの実行基盤   Claude Code、Kiro AgentCore Harness 目的 開発者自身の作業を効率化する エンドユーザー向けのエージェントを本番運用する 使う人 開発者・開発チーム 作ったアプリのエンドユーザー 動く場所 ローカルPC / クラウド（※） AWSクラウド（マイクロVM） エンドユーザーへの提供 想定されていない API経由で提供可能 マルチテナント 非対応（開発者向けツール） 対応（セッション分離・IAM/OAuth認証） ※Claude Codeは基本ローカル実行ですが、「Claude Code on the web」や「 Routines 」（Anthropicクラウド上でのスケジュール実行、2026年4月リサーチプレビュー）も提供されています。 Kiroも「 Kiro Autonomous Agent 」が発表されています。 Bedrock Agents 、AgentCore Runtime との比較 AWSサービスの中にはエージェント関連のサービスが複数あります。 その中から抜粋して比較しました。 Bedrock Agents ：Bedrockの世界で完結する従来型のエージェント。Knowledge BaseやGuardrailsとの統合が強み AgentCore Runtime ：自分でコードを書いて自由にエージェントを構築する実行環境 AgentCore Harness ：設定だけでエージェントを動かせる仕組み。マルチモデル対応で、MCP等の標準プロトコルを使う。Runtimeとは別のアプローチであり、Runtimeで作ったコードをHarnessに変換する機能はない   Bedrock Agents AgentCore Runtime AgentCore Harness 正式名称 Amazon Bedrock Agents Amazon Bedrock AgentCore Runtime Amazon Bedrock AgentCore Managed Harness ステータス GA GA プレビュー コード記述 不要（設定ベース） 必要（自分でループを実装） 不要（設定ベース） モデル Bedrockモデルのみ 任意（制限なし） Bedrock / OpenAI / Gemini ツール接続 Action Groups（Lambda / OpenAPI）、Knowledge Base 任意（自分で実装） MCP / Gateway / Browser / Code Interpreter フレームワーク AWS独自 LangChain / LlamaIndex / Strands等 自由 Strands Agents（AWS製OSS） 実行環境 AWSマネージド（詳細非公開） マイクロVM マイクロVM シェル/ファイル操作 不可 可能 可能（デフォルトで有効） 自由度 中（設定範囲内） 高（何でもできる） 中（設定範囲内） 向いている人 Bedrock中心で手軽に作りたい 独自ロジックが必要 マルチモデルで手軽に作りたい   なぜAgentCore Harnessはエンドユーザーに提供できるのか 比較表で「エンドユーザーへの提供が可能」と書きましたが、なぜそう言えるのかを補足します。 Kiro/Claude Codeは開発者が自分のターミナルやIDEで使うツールなので、「自分のアプリのユーザーに使わせる」仕組みがそもそもありません。 一方、AgentCore Harnessには以下のような「サービスとして提供するための仕組み」が組み込まれています。 例えば「社内のカスタマーサポート用AIチャットボット」を作る場合、自分のWebアプリから invoke_harness APIを呼び出し、ユーザーごとにセッションIDとactorIdを割り当てれば、各ユーザーが独立してエージェントと会話できるサービスが作れます。 仕組み 何ができるか invoke_harness API 自分のアプリのバックエンド（Webサーバーやモバイルアプリ）からエージェントをAPI経由で呼び出せる。 つまり、自分のアプリの画面からエージェントと会話する機能を作れる。 セッション分離 セッションごとにマイクロVMが割り当てられる。 つまり、ユーザーAとユーザーBの会話が混ざらない IAM / OAuth認証 エンドユーザーのJWTトークンを受け取って認証できる。 つまり、「誰がアクセスしているか」を識別できる。 actorIdによるメモリ分離 ユーザーごとにメモリ（会話履歴・学習内容）を分離できる。 つまり、Aさんの好みとBさんの好みが混ざらない。 サーバーレスなスケーリング 同時に何千セッションでも自動でスケールする。   料金について 先に気になる料金を整理します。 AgentCore料金ページ によると、AgentCore Harness自体に追加料金はかかりません。 課金されるのは裏側で使われるAgentCoreの各機能（Runtime、ツール等）の従量課金です。 料金は全リージョン共通で、リージョン別の価格差はありません（2026年4月時点）。 プレビュー期間中も上記の従量課金は発生します。 試した後はセッションを終了し、不要なHarnessは削除してください。 課金対象 料金 備考 Managed Harness自体 無料 設定・管理に追加料金なし Runtime（CPU） $0.0895 / vCPU時間 実際にCPUを消費した時間のみ。I/O待ち（モデル応答待ち等）は無料 Runtime（メモリ） $0.00945 / GB時間 ピークメモリ使用量ベース。最低128MB Browser / Code Interpreter Runtimeと同じ単価 ツールを使った場合のみ Memory 長期短期記憶: $0.25/1000イベント 長期メモリストレージ: $0.75/1000レコード/月 長期記憶検索: $0.50/1000検索 メモリを有効にした場合のみ Observability CloudWatch料金に準拠 トレース・ログ・メトリクスは自動収集 モデル利用料 各モデルの料金 Bedrock / OpenAI / Gemini の利用料は別途   前提条件 東京リージョン（ap-northeast-1）は現時点で非対応です。 そのため、本記事ではus-east-1（バージニア北部）を使用します。 項目 内容 リージョン us-east-1 / us-west-2 / eu-central-1 / ap-southeast-2 のいずれか Bedrockモデルアクセス 使用するモデル（デフォルト: Claude Sonnet 4.6）のアクセスを有効化済み IAM権限 AgentCore関連の操作権限（AdministratorAccessがあれば問題なし）   ステップ1: コンソールでHarnessを作成する 1-1. AgentCoreコンソールを開く リージョンをus-east-1に切り替えます。 検索バーで「Agentcore」と入力し、 Amazon Bedrock AgentCore のコンソールを開きます。 左側のサイドバーに「Harness」というメニューが追加されています。   1-2. Quick create harnessで作成する Harnessのページを開くと「Quick create harness」ボタンがあります。 これを押すと「Quick create harness」か「Advanced create harness」のどちらかを選択できます。 「Quick create harness」を押した場合、推奨設定でHarnessが自動作成されます。 しばらく待つと（約1〜2分）、プレイグラウンド画面にリダイレクトされます。   「Quick create harness」を押すと、裏側で以下のリソースが自動作成されます。 リソース 内容 Harness本体 エージェントの設定（モデル・プロンプト・ツール）を保持するリソース AgentCore Runtime エージェントが実際に動くサーバーレス実行環境（FirecrackerマイクロVM） IAM実行ロール AmazonBedrockAgentCoreHarnessDefaultServiceRole-xxxxx という名前で自動作成される Bedrockモデル呼び出し、CloudWatchログ出力等の権限を持つ   IAM実行ロールの信頼ポリシーは以下のようになっていました。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "bedrock-agentcore.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "[AWSID]" }, "ArnLike": { "aws:SourceArn": "arn:aws:bedrock-agentcore:us-east-1:[AWSID]:*" } } } ] } このロールには、Bedrockモデル呼び出し、CloudWatchログ・メトリクス出力、X-Rayトレース、Browser/Code Interpreterの操作権限などが含まれます。 「Quick create harness」ではこれらが AmazonBedrockAgentCoreHarnessDefaultServiceRole-xxxxx という名前のロールとして自動作成されるため、 手動でのIAMロール作成は不要 です。 ステップ2: プレイグラウンドで会話してみる プレイグラウンドで、さっそくエージェントと会話できます。 テキスト入力欄にメッセージを入力して送信するだけです。まずはシンプルな質問を試してみましょう。 こんにちは！あなたは何ができますか？ この時点ではツールを追加していないので、モデルの知識だけで回答します。次のステップでツールを追加してみましょう。   ステップ3: ツールを追加する Harnessにはツールを追加できます。ツールを追加すると、エージェントが「考えるだけ」でなく「行動できる」ようになります。 追加できるツールの種類 公式ドキュメント によると、下表に加えて shell （bashコマンド実行）と file_operations （ファイル操作）がデフォルトで全セッションに含まれています。 ツール できること Gateway APIやLambda関数への接続（事前にGatewayリソースの作成が必要） Browser Webサイトの閲覧・操作（ナビゲーション、フォーム入力、スクリーンショット取得など） Code Interpreter Python / JavaScript / TypeScript のコード実行（計算、データ分析、グラフ作成など） Remote MCP Server 外部のMCPサーバーへの接続（URLを指定） Custom functions クライアント側で実行するカスタム関数の定義（人間による承認フローや社内API呼び出し等） ブラウザツールを追加してみる プレイグラウンド画面またはHarnessの設定画面から、ツールの追加ができます。 今回は「AgentCore Browser Tool」を追加してみます。   追加後、ブラウザを使う質問をしてみましょう。 エージェントがブラウザツールを使ってWebページにアクセスし、内容を要約してくれるはずです。 ブラウザツールを使用して、https://aws.amazon.com/bedrock/agentcore/ の概要を教えて   AgentCore Browserのドキュメント によると、ブラウザはコンテナ化された環境で動作し、セッションごとに分離されます。 セッション終了時にリセットされるエフェメラル（一時的）な設計で、セキュリティ面も考慮されています。   ステップ４: 設定を確認・編集する Harnessの詳細確認画面および編集画面では、以下のセクションを確認・編集できます。 セクション 概要 Harness details ARN、IAMロール、ステータス等の基本情報 View invocation code プログラムからの呼び出しサンプルコード Model and system prompt 使用モデルとシステムプロンプトの設定 Memory セッションを跨いだ会話履歴の保持設定 Tools エージェントが使用できるツールの管理 Skills エージェントに専門知識を持たせるスキルファイルの設定 Advanced configurations ツール制限、ネットワーク、トランケーション、実行制限、ライフサイクル Inbound Auth 認証方式（IAM / OAuth）の設定 Observability メトリクス表示、ログ配信、トレースの設定（確認画面のみ） Permissions Harnessが使用するIAMサービスロールの設定（編集画面のみ） Harness details 項目 内容 Harness ARN Harnessの一意な識別子。boto3等からの呼び出しに使用 IAM Role Harnessが使用する実行ロール Status READY / CREATING / FAILED など View invocation code このHarnessをプログラムから呼び出すためのサンプルコードを表示できます。 Model and system prompt 項目 内容 provider Bedrock / OpenAI / Gemini（デフォルト: Bedrock） Model 使用するモデル（デフォルト: global.anthropic.claude-sonnet-4-6） System prompt エージェントへの指示文（デフォルト: You are a helpful assistant.） Memory AgentCore Memoryを接続すると、セッションを跨いで会話履歴を保持できます。 未設定の場合、各呼び出しは前の会話を覚えていない状態で始まります。 項目 内容 Memory 接続するAgentCore Memoryリソースを選択。 事前にMemoryリソースの作成が必要 Actor ID メモリの検索対象を特定のユーザーやエンティティに絞るための識別子。 複数ユーザーが同じMemoryを共有する場合に、ユーザーごとの記憶を分離できる Number of messages セッション開始時にメモリから取得する過去メッセージの件数。 多いほどコンテキストが豊富になるが、トークン消費も増える Tools 追加したツールの一覧が表示されます。ここからツールの追加・削除もできます。 Skills エージェントに専門知識を持たせるスキルファイルを設定できます。 スキルはHarnessのファイルシステムにマウントされたファイルやスクリプトのバンドルで、実行時にエージェントが参照します。 Advanced configurations 公式ドキュメント によると、以下のコスト制御パラメータが設定できます。 パラメータ 内容 デフォルト値 Allowed tools エージェントが使用できるツールの制限。省略すると全ツールが許可される。 shell や file_operations 等のビルトインツールもここで制限可能 All tools (*) Network Harnessセッションのネットワークモード。 VPCを選択するとプライベートリソース（DB、内部API等）にアクセス可能 PUBLIC Truncation Strategy コンテキストがモデルの上限を超えた場合の切り詰め方式。 sliding_window は直近のメッセージを保持、 summarization は要約して圧縮 sliding_window Max iterations 1回の呼び出しあたりの推論・行動ループの最大回数 75 Timeout duration 1回の呼び出しのタイムアウト 1 hour Max tokens 1回の呼び出しあたりのトークン上限 なし Idle session timeout アイドル状態のマイクロVMが維持される時間 15 minutes Max lifetime マイクロVMセッションの最大生存時間 8 hours コスト管理のため、テスト時はMax iterationsやTimeout durationを小さめに設定しておくと安心です。 エージェントが暴走して大量のトークンを消費するのを防げます。 Inbound Auth デフォルトではIAM認証が設定されています。 OAuth（JWT）認証に変更することも可能です。 Observability トレース・ログ・メトリクスが自動収集されます。ランタイムセッション数、ランタイムエラー率、vCPU消費量、メモリ消費量などのメトリクスが表示されます。 ログの配信とトレース（確認画面のみ） 項目 内容 ログ配信 CloudWatch Logsへのログ配信先を設定 Tracing CloudWatchへのトレース配信を有効化。 パフォーマンスのボトルネック特定やエラーのトラブルシュートに使用 Permissions（編集画面のみ） Harnessが使用するIAMサービスロールを設定します。 「新規作成」または「既存ロールの選択」が可能です。 「Quick create harness」で作成した場合は AmazonBedrockAgentCoreHarnessDefaultServiceRole-xxxxx が自動選択されています。     ステップ５:クリーンアップ テストが終わったら、不要なリソースを削除しましょう。 Harnessを削除すると、裏側で管理されていたRuntimeリソースも一緒に削除されます。 Harnessを選択　⇒　「Delete」を実行 「Quick create harness」で自動作成された AmazonBedrockAgentCoreHarnessDefaultServiceRole-xxxxx は、Harness削除後も残る場合があります。不要であればIAMコンソールから手動で削除してください。   まとめ AgentCore Harnessは「モデル・指示文・ツールを指定するだけでAIエージェントが動く」サービス Quick createなら数クリック・数分で作成完了 Harness自体に追加料金はなく、裏側のRuntime等の従量課金のみ（I/O待ちは無料） 作成後はプレイグラウンドですぐに会話でき、ツール追加やプロンプト変更もコンソールで完結 KiroやClaude Codeとは役割が異なる テスト後はHarnessを削除すれば裏側のRuntimeリソースも消える（IAMロールは手動確認を推奨） 当記事において不備がございましたらご連絡いただけますと幸いです。

1. はじめに 突然ですが、VS Codeの拡張機能を作ったことはあるでしょうか。 今まで私は、何か難しそうだという理由から、全く作ろうと考えていませんでしたが、生成AIの進歩によってお手軽に作れることを知って、最近いくつか試しに作っています。 今回は、「VS Code の Webview でどこまで動くのか？」 という疑問から、VS Code 拡張機能の描画性能について着目し、ごく簡単にではありますが、Web ブラウザの場合との比較検証をテトリスを動かすことで実施してみました。 また、VS Code標準のUIではなく、描画の自由度がより高いWebview[1]を使うことにしました。