Amazon Quick DesktopからACP連携でKiro CLIにタスクを実行させてみた
はじめに
Amazon Quick Desktopは、デスクトップ上で動作するAI仕事アシスタントです。チャットUIから自然言語で指示を出し、コーディングやドキュメント作成、各種サービスとの連携を統合的に管理できます。
一方、Kiro CLIはAWSが提供するAIエージェントで、ACP（Agent Client Protocol）に対応しています。ターミナルからヘッドレスで動作し、ファイル操作やコマンド実行、コード生成を自律的に行います。
本記事では、Amazon Quick Desktop（以下、Quick）からKiro CLIにACP経由でタスクを実行させる方法を検証しました。
- ローカルKiro CLIの設定と動作確認（タスク実行、マルチターン対話、セキュリティ）
- SSH経由リモート接続の試行（失敗→原因特定→成功）
ACP（Agent Client Protocol）とは
ACPは、AIエージェントとクライアント（エディタやデスクトップアプリ）間の通信を標準化するプロトコルです。LSP（Language Server Protocol）がエディタと言語サーバーの通信を標準化したのと同じ発想で、AIエージェントとの対話を標準化します。
主な特徴は以下のとおりです。
- stdin/stdout上のJSON-RPC 2.0で通信する
- エディタやクライアントにロックインされない
- セッションベースのエージェント対話（タスクの開始・継続・完了）を管理する
Quickでは、Coding Agentsとして Kiro、Claude Code、Codex、GitHub Copilot、Gemini CLI、Cursor などを登録できます。
環境
| 項目 | 値 |
|---|---|
| ローカル | macOS Tahoe 26.5.1 (Build 25F80) |
| OpenSSH | 10.2p1 (LibreSSL 3.3.6) |
| Amazon Quick Desktop | v0.811.0 |
| Kiro CLI | v2.6.0 |
| モデル | Claude Opus 4.6 |
| リモート | Fedora Linux Asahi Remix 43 Server Edition (Apple Silicon) |
ローカルKiro CLIの設定手順
ローカルのKiro CLIをACP経由で接続する設定は3ステップで完了します。
Settings → Capabilities → MCP タブを開く
Quickの Settings → Capabilities → MCP タブを開きます。MCP タブにはMCP Serversの設定もありますが、Kiro CLIの登録先はページ下部の「CODING AGENTS」セクションです。
Add Agent でKiroを追加
「+ Add Agent」をクリックすると、Add Coding Agent Skill ダイアログが表示されます。Kiro がプリセットとして表示されるので、選択するだけで登録できます。
登録完了
Kiro が Enabled 状態で登録されました。
設定値は以下のとおりです。
| 項目 | 値 |
|---|---|
| Name | Kiro |
| Command | /Users/your-user/.local/bin/kiro-cli |
| Arguments | acp |
プリセット選択時にCommandとArgumentsは自動設定されます。
Coding Agent Skills の仕組み
Kiro を登録すると、Quick に「Coding Agent Skills」がビルトインスキルとして自動ロードされます。内部的には Send Message To Acp Agent ツールを使ってACPエージェントと通信します。
動作確認
タスク実行
Quickのチャットで自然言語で指示を出すだけで、Kiroがタスクを実行します。
- 「Kiroに○○を頼んで」
- 「use Kiro to ...」
マルチターン対話
同じタスクとして継続して指示する限り、Kiroは会話のコンテキストを保持します。「さっきの結果をもとにREADMEを更新して」のように、前の指示を踏まえた継続的なやり取りが可能です。内部的には task_name によって継続タスクとして管理されています。
ノンブロッキング並列実行
今回の検証では、長時間タスクの実行中もQuickのチャットは通常どおり使えました。実際にローカルKiroとリモートKiroに同時にタスクを実行させ、それぞれ独立して完了することも確認しています。
セキュリティ確認
ACP経由でのタスク実行時のセキュリティ動作を確認しました。
承認ダイアログ
Kiroが危険性のあるコマンド（sudo など）を実行しようとすると、QuickのUI上に承認ダイアログが表示されます。人間が「Allow」を押さない限り実行されません。
今回の環境でのsudo実行結果
今回の環境では、仮に承認してもOS側のパスワード要求が追加のガードレールとして機能しました。実際に sudo ls -la /root/ を試したところ、以下のエラーでブロックされました。
sudo: a terminal is required to read the password;
either use the -S option to read from standard input or configure an askpass helper
sudo: a password is required
承認判断のAI委任は確認できず
今回の検証では、承認判断をQuick AIに委任する方法は見つかりませんでした。承認ダイアログは人間の判断を介在させる設計のようです。
SSH経由リモート接続（失敗→成功）
動機
SSH経由でリモートマシン上のKiro CLIに接続できれば、以下のメリットがあります。
- リモートのIAMロールを利用でき、ローカルに認証情報を置かずに済む
- 開発環境を隔離でき、パッケージ追加・更新による依存汚染やバージョン不整合の影響をリモート側に閉じ込められる
- Quickの統合管理（記録・並列管理）をリモート作業にも適用できる
前提条件
SSH経由のACP接続では、stdin/stdoutが通信に使われるため、以下が事前に整っている必要があります。
- SSH鍵認証などで非対話ログインできること
- 初回のhost key確認が済んでいること
- リモート側にKiro CLIがインストール・認証済みであること
- SSHログイン時に余計な標準出力（バナー、motd等）が出ないこと
事前にSSH経由でACPの疎通ができることを確認しました。JSON-RPCの initialize リクエストを送ると、Kiro CLI Agent v2.6.0 が正常に応答しています。
(printf '{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"protocolVersion":1,"clientCapabilities":{},"clientInfo":{"name":"test","version":"0.1.0"}}}\n'; sleep 5) | ssh 192.0.2.10 /home/your-user/.local/bin/kiro-cli acp
{"jsonrpc":"2.0","result":{"protocolVersion":1,"agentCapabilities":{"loadSession":true,"promptCapabilities":{"image":true,"audio":false,"embeddedContext":false},"mcpCapabilities":{"http":true,"sse":false},"sessionCapabilities":{},"auth":{}},"authMethods":[],"agentInfo":{"name":"Kiro CLI Agent","title":"Kiro CLI Agent","version":"2.6.0"}},"id":0}
最初の試行 → 失敗
リモートKiroを登録しましたが、MCP統合として認識されてしまいタスク実行に失敗しました。
| 項目 | 値 |
|---|---|
| Name | Kiro Remote |
| Command | /usr/bin/ssh |
| Arguments | 192.0.2.10 /home/your-user/.local/bin/kiro-cli acp |
設定画面のテスト接続ボタンを押すと、Kiro CLI Agent v2.6.0 が応答し、ジョークまで返してきました。疎通は成功です。
しかし、実際にタスクを実行させようとすると以下のエラーが表示されました。
Skill 'user_mcp' is registered but its tools failed to load
(the integration may not have started).
-T オプションの追加やアプリの再起動を試しましたが、改善しませんでした。
原因分析
Quickのアプリログ（~/Library/Logs/quickwork/）を、ローカルKiro経由で調査しました。これ自体がACP連携の実用例です。
ログには以下の記録が残っていました。
[UserMCP] No enabled servers in config
このメッセージから、実際のタスク実行時にはACPエージェントとして起動されておらず、MCP統合側の処理経路に入っていたことがわかりました。原因をまとめると以下のとおりです。
- MCP統合として扱われると、Quickは対象をMCPサーバーとして扱い、
tools/listメソッドでツール一覧の取得を期待する kiro-cli acpはMCPではなくACPプロトコルで通信するため、tools/listには応答しない- テスト接続では初期化段階の応答が返るため成功しているように見えるが、実際のタスク実行時にはMCPとして
tools/listなどの呼び出しが行われ、ACPエージェントであるkiro-cli acpとは噛み合わない
解決 → Coding Agents に再登録
「CODING AGENTS」セクションに「Custom ACP agent」として再登録しました。
| 項目 | 値 |
|---|---|
| Name | Kiro Remote |
| Command | /usr/bin/ssh |
| Arguments | -T 192.0.2.10 /home/your-user/.local/bin/kiro-cli acp |
テスト接続を実行すると、Kiro CLI Agent v2.6.0 が正常に応答しました。
実際のタスク実行も成功し、リモートマシン上のファイル読み取りまで動作確認できました。Kiro CLIのネイティブツール（glob, read）がSSH越しに正常動作しています。
ローカルとリモートの環境情報取得による検証
ローカルKiroとリモートKiroそれぞれに uname -a を実行させ、接続先が異なることを確認しました。
QuickのチャットUIから同じ操作で、異なる環境でタスクを実行できています。
成功のポイント
SSH経由リモート接続を動かすためのポイントは以下の3点です。
- 登録先を「MCP Servers」ではなく「Coding Agents」にする
-T（pty無効化）を付ける。余計なエスケープシーケンスの混入を防ぐ- ACPプロトコルとMCPプロトコルの違いを理解する
まとめ
QuickとKiro CLIのACP連携は、Settings画面から3ステップで設定できます。自然言語でタスクを実行でき、マルチターン対話やノンブロッキングな並列実行も確認できました。会話・作業履歴の一元管理やログ調査の依頼など、CLIを直接操作するのとは異なる利点があります。
SSH経由のリモート接続では、登録先の違いで失敗する落とし穴がありました。テスト接続が成功するため原因の特定が難しいですが、kiro-cli acp はACPプロトコルで通信するため、「Coding Agents」に登録する必要があります。登録先を正しくすれば、SSH越しでもKiro CLIのネイティブツールが正常に動作しました。
