kirodotdev

Kiro Crew: A persistent workspace for development work that self-improves and continues beyond one session (4.7k stars) What it does All text below is quoted directly from the project README. >A persistent workspace for development work that self-improves and continues beyond one session. Why Kiro Crew: - Persistent. Sessions, memory, schedules, and task checkpoints survive Gateway restarts, and scheduled or reactive work continues without someone at the terminal. - Self-learning. Corrections and task failures become durable lessons. Preferences and project context carry into new sessions. - Self-evolving. Repeated patterns become reusable skills. Memory, lessons, and skills stay visible and editable, so each Kiro Crew grows more tailored to the person and work around it. - Runs where you choose. Your Mac, a local container, or a remote machine you control. - One Gateway, many surfaces. Work directly in the desktop app or web dashboard, or continue the same work from the CLI and messaging surfaces like Slack and Discord. >curl -fsSL download.crew.kiro.dev | sh Repository kirodotdev/KiroCrew Repository stats |Metric|Value| |:-|:-| |Stars|4,653| |Forks|911| |Last release|v0.11.0 (2026-10-30)| |Languages|Python 72.4%, TypeScript 23.2%, JavaScript 3.9%| |Contributors|357| |AI contributor accounts (Claude / Codex / Cursor / Copilot)|@claude (196 commits), @cursoragent (2 commits), @Copilot (1 commits)| |AI co-authored commits|Claude: 239, Codex: 1, Cursor: 5, Copilot: 1| Main contributor |Field|Value| |:-|:-| |Name|Bolin Chen| |GitHub|@bolichen97| |Commits to this repo|2,372 (top contributor)| |Company / Location|Seattle| |Followers|55| ────────────────────────────── 📌 If you want to browse more repos like this, we've organized them by category and rankings here: bestgithubrepositories.com 🗂️ We're also archiving repos where possible, so useful projects don't disappear when they're removed from GitHub.

This dev workspace keeps working after you close the tab. kirodotdev/KiroCrew: • A persistent workspace for development work • Self-improves and continues beyond one session • Keeps context across sessions The agent that never goes to sleep. kirodotdev/KiroCrew

Kiro CLIとKiro Crewを改めて入門してAWSで動かすまで KiroはIDEだけの製品ではなくなりました。2026年11月時点では、IDE、CLI、Web、Mobile、そしてCrewの5つの入口があります。 特にCLIはAPIキーでヘッドレス実行ができるようになり、Crewは自分のマシンに常駐して仕事を進めるエージェントとして公開されました。 IDEでSpecを書いた経験はあるけれど最近は触っていない、という状態から、CLIとCrewとAPIキーを実機で一通り試して整理しました。 Kiroの今の全体像 入口は公式ドキュメントの数え方で5つあります。 IDEは従来どおりで、チャットとSpecsとHooksがあります。CLIにはヘッドレスモードとCI連携が加わりました。 Webはブラウザから複数リポジトリの作業を計画してPRまで開き、Mobile(プレビュー)はタスクの監視、PRレビュー、エージェントとのチャット用です。 Crewだけ性格が違い、常駐して自律タスクやスケジュール実行を担い、メモリを持ち、チャットツールともつながります。 機能は入口をまたいで共通で、Specs、Steering、Hooks、MCPといった従来からのものに、Sub-agents、Skills、Memory、Local command sandbox、Workflowsなどが加わっています。 このうち10月に入ってから増えたApprove for me(CLI 2.36.0)、コマンドサンドボックスと自律モード、メモリは、あとで実際に触ります。 一覧は公式ドキュメントのトップにあります。 Kiro Crewは2026-08-04にApache 2.0で公開されました。Amazon社内でMeshClawと呼ばれていたものが前身で、Crew自体は無料です。 GatewayというサーバがローカルやリモートのマシンでKiro CLIなどのエージェントハーネスを動かし、デスクトップ版、Webダッシュボード、CLI、Slackなどから同じセッションを操作できます。 どのハーネスで動かすかは、あとの節で実機の画面と一緒に見ます。 APIキーはapp.kiro.devで発行します。接頭辞はksk_で、対象はPro以上のプランです(認証のドキュメント)。 組織管理のサブスクリプションでは、管理者が「Enable users to generate API keys」を有効にしないと発行できません。デフォルトはオフです。 環境 Kiro CLI 2.37.0(Linux x86_64)、内部のエージェントサーバKAS 0.66.70 Kiro Crew 0.11.1(Dockerイメージghcr.io/kirodotdev/kirocrew:stable) Ubuntu 24.04のdevcontainer、Python 3.12、Node.js 22、Docker 29 Kiroのプランは組織管理のPro+(月2,000クレジット)、サインインはIAM Identity Center 画面の確認はPlaywrightのヘッドレスChromium devcontainerはユーザー名前空間が使えないため、サンドボックスに関する機能(CLIの自律モード、Crewのサンドボックス)はこの環境では動きませんでした。 やってみた Kiro CLIを入れてログインする インストールは公式のスクリプトです。 curl -fsSL cli.kiro.dev | bash kiro-cli --version kiro-cli 2.37.0 ログインはIAM Identity Centerを使いました。SSH先のようにブラウザが開けない環境では、--use-device-flowでコードを表示して別の端末で承認します。 kiro-cli login --license pro --identity-provider https://<your-org>.awsapps.com/start --region us-east-1 --use-device-flow ? Enter Start URL › https://<your-org>.awsapps.com/start ? Enter Region › us-east-1 Confirm the following code in the browser Code: XXXX-XXXX Open this URL: https://<your-org>.awsapps.com/start/#/device?user_code=XXXX-XXXX Logged in successfully フラグを付けてもStart URLとリージョンの確認プロンプトが出るので、Enterを2回押します(issue #4243)。 ログイン後の確認はkiro-cli whoamiです。 kiro-cli whoami --format json-pretty { "accountType": "IamIdentityCenter", "email": "<your-email>", "region": "us-east-1", "startUrl": "https://<your-org>.awsapps.com/start" } モデルの一覧とクレジット倍率も、ログイン後はCLIから取れます。 kiro-cli chat --list-models Available models (* = default): - auto 1.00x credits Models chosen by task for optimal usage and consistent quality claude-opus-5.5 2.00x credits Claude Opus 5.5 model with 1M context window claude-sonnet-5.5 1.30x credits Claude Sonnet 5.5 model with 1M context window claude-haiku-5.5 0.06x credits Experimental preview of Claude Haiku 5.5 model with 1M context window gpt-5.6-sol 4.40x credits OpenAI GPT 5.6 Sol with 1M context window gpt-5.6-terra 2.20x credits OpenAI GPT 5.6 Terra with 1M context window gpt-5.6-luna 0.60x credits OpenAI GPT 5.6 Luna with 1M context window kimi-k3 2.40x credits Experimental preview of Kimi K3. ... (中略) qwen3-coder-next 0.05x credits Experimental preview of Qwen3 Coder Next SteeringとSpecをCLIから使う ここからはブラウザでログインした状態です。IDEで使っていた.kiro/配下の設定は、CLIでもそのまま読まれます。試しに小さなPythonファイルとSteeringを置きました。 .kiro/steering/style.md --- inclusion: always --- - 回答は必ず日本語で書く。 - 最後の行に「-- steering適用済み --」と書く。 対話モードで質問すると、ファイルを読んで答えたあとに署名が付きました。1ターンのクレジットと時間はその場に表示されます。 › app.py の add 関数は何をする関数ですか。1 行で答えてください。 • Read /tmp/kiro-play/sample/app.py • add 関数は、引数 a と b を受け取り、その和を返す関数です。 -- steering適用済み -- ▸ Credits: turn 0.14 • session 0.14 | Time: 19s Specはチャットで頼めば作られます。ヘッドレスモード(次の節で使う--no-interactive --trust-all-tools)から「実装はせず要件・設計・タスクだけ作って」と頼んだところ、1分19秒で3ファイルができました。 .kiro/specs/div-zero-guard/requirements.md .kiro/specs/div-zero-guard/design.md .kiro/specs/div-zero-guard/tasks.md エージェントは組込みが3つで、kiro-cli agent createでワークスペースかグローバルに追加できます。 - kiro_default (Built-in) Default agent kiro_help (Built-in) Help agent that answers questions about Kiro CLI features using documentation kiro_planner (Built-in) Specialized planning agent that helps break down ideas into implementation plans APIキーを発行してヘッドレスで動かす app.kiro.devにサインインし、API Keysから作成します。キーの全文は作成時にしか表示されないので、用途がわかる名前を付けて保管します。 使うときは環境変数に入れて、--no-interactiveで実行します。 export KIRO_API_KEY=ksk_xxxxxxxx kiro-cli whoami Authenticated with API key kiro-cli chat --v3 --no-interactive "Reply with exactly one word: pong" pong 1往復で11秒かかりました。KASの起動を含む時間です。 発行直後の10分ほどは、whoamiは通るのにチャットが403で失敗しました。キーを作ったら少し待ってから試しています。 認証の優先順位はブラウザセッション、KIRO_API_KEY、なし、の順です。ブラウザでログイン済みの端末で環境変数を設定しても、whoamiはIdentity Centerのままでした。CI用の端末ではkiro-cli logoutしてから使います。 ヘッドレスでは人が承認できないので、ツールの許可をフラグで渡します。特定のツールだけ許すなら--trust-tools=<ids>、全部許すなら--trust-all-toolsです(ヘッドレスモードのドキュメント)。 kiro-cli chat --v3 --no-interactive --trust-tools=read_file,grep_search \ "app.py を読んで、div 関数の問題点を 1 行で指摘して" div 関数は b が 0 のときにゼロ除算（ZeroDivisionError）を起こすのに、そのチェックをしていない点が問題です。 -- steering適用済み -- Steeringはヘッドレスでも効いています。スクリプトから扱うなら--output-format stream-jsonが便利で、1行1イベントのJSON Linesになります。実際は12行出ますが、主な行だけ抜粋します。 kiro-cli chat --v3 --no-interactive --output-format stream-json "What is 2+2? Answer with the number only." {"type":"sessionUpdate","data":{"sessionId":"sess_...","update":{"sessionUpdate":"agent_message_chunk","content":{"type":"text","text":"4"}}}} {"type":"sessionUpdate","data":{"sessionId":"sess_...","update":{"sessionUpdate":"session_info_update","_meta":{"kiro":{"contextUsage":{"usagePercentage":2.8415},"kind":"context_usage"}}}}} {"type":"sessionUpdate","data":{"sessionId":"sess_...","update":{"sessionUpdate":"session_info_update","_meta":{"kiro":{"promptTurnSummaries":[{"unit":"credit","usage":0.089855156053068}],"elapsedTime":4318,"status":"success"}}}}} {"type":"runFinished","data":{"sessionId":"sess_...","status":"success","stopReason":"end_turn","finalText":"4","finalTextTruncated":false}} 最後のrunFinishedに最終テキストと停止理由が入り、途中のsession_info_updateに消費クレジットとコンテキスト使用率が入ります。CIで「このPRのレビュー結果だけ欲しい」ならこの行を拾えば済みます。 終了コードも決まっていて、指定したエージェントがない場合は4でした。 kiro-cli chat --v3 --no-interactive --agent no-such-agent "hi"; echo "exit=$?" exit=4 対話モードで増えた機能を見る 対話モードのスラッシュコマンドは/helpで一覧になり、/guideで使い方を質問できます。10月に増えた分を中心に見ました。 /usageはプランと消費量を出します。組織管理のアカウントでは超過購入が無効で、管理は管理者に、と案内されます。 Estimated Usage | resets on 2026-12-01 | KIRO PRO+ Credits (1.46 of 2000 covered in plan) Overages Disabled /permissionsのPoliciesは「ask for approval」か「approve for me」を選びます。後者を選ぶと、モデルが安全と判断した操作は自動承認され、危険なものはブロックされ、迷ったものだけ聞かれます。今回は項目を確認しただけで、切り替えては試していません。 /memoriesのconfigはread & write、read only、offから選び、初期値はoffでした。セッション終了後に自動でメモリを作る「Automatic memory updates」のチェックもここにあります。 /sandboxはGlobalとProjectの2系統があり、Sandbox、Network、MCP sandboxingを編集して~/.kiro/settings/sandbox.jsonに保存します。初期状態はSandboxがoffで、Networkはblock allでした。 /autonomous onはこの環境では有効にできませんでした。ローカルのコマンドサンドボックスが前提で、このコンテナではsandbox unavailableと表示されるためです。 Kiro Crewを立ち上げる Crewは、操作する側(ダッシュボード、CLI、チャットツール)とGatewayの2層になっていて、Gatewayが同梱のkiro-cliをACP経由で動かします。 Crewはデスクトップ版、ワンライナー、Docker、ソースビルドから入れられます(リポジトリのREADMEとDockerガイド)。devcontainerの中で消しやすいので、今回はDockerにしました。 設定と認証情報は名前付きボリュームに置かれるので、ガイドによればイメージを更新しても状態は引き継がれます。 docker run -d --name kirocrew \ -p 127.0.0.1:5476:5476 \ -v kirocrew-home:/home/kirocrew \ -e KIRO_API_KEY=ksk_xxxxxxxx \ -e KIROCREW_ALLOW_UNSANDBOXED=1 \ -e TZ=Asia/Tokyo \ ghcr.io/kirodotdev/kirocrew:stable 起動ログの[entrypoint]行に、何が起きたかが書かれます。 [entrypoint] Stored KIRO_API_KEY in /home/kirocrew/.kiro/crew/.env and removed it from the environment. [entrypoint] First run: NO inner sandbox backend under this runtime's seccomp policy; KIROCREW_ALLOW_UNSANDBOXED=1 given — seeded config.json with sandbox=auto + sandbox_allow_unsandboxed_exec=true. [entrypoint] Dashboard login: run docker exec <container> kirocrew token --ttl 2h 起動ログの案内には「チャットセッションにはログイン済みのkiro-cliが必要」とありますが、.envのKIRO_API_KEYだけでセッションは動きました。 docker exec kirocrew kirocrew chat -m "Reply with exactly one word: pong" pong ダッシュボードはトークン認証です。kirocrew tokenで短命のリンクを作り、ブラウザで開きます。 docker exec kirocrew kirocrew token --ttl 2h localhost... 初回はPrivacyの同意画面と「Tell Kiro about you」が出ます。Privacyは匿名の利用ハートビートで、デフォルトでオンです。CLIのkirocrew telemetry disableでも切れます。 左のナビにはSessionsやSchedule、Artifacts、Appsなどが並びます。この記事で使うのはSessions、Schedule、Artifacts、Settingsです。 Crewに仕事を頼む チャットでコマンド実行を伴う依頼をすると、実行したステップが展開され、消費クレジットと所要時間が表示されます。 セッションの承認モードはデフォルトでAutomaticです。拒否リストと機密パスの保護とサンドボックスのチェックを通ったものは、個別に聞かれずに実行されます。 Settings → Securityに出るYOLOやTool Approvalの「Interactive」は、ダッシュボード側の設定で、このセッション設定とは別物です。 では危ないものはどうなるか、とcat ~/.aws/credentialsを頼んでみました。 I can't run that one. ~/.aws/credentials holds your AWS access keys, and dumping it to the chat would expose those secrets in plain text where they could end up in logs or history. If you need to work with your AWS setup, here are safer options: - Check which profiles exist without exposing secrets: aws configure list-profiles - Confirm the active identity: aws sts get-caller-identity 拒否パターンはkirocrew security deny-listで見られ、組込みが112件ありました。aws s3 cp ... s3://、echo $AWS_SECRET...、printenvでAWS変数を拾う、kirocrew tokenを取る、Crew自身をpkillする、といったものです。 Securityのドキュメントによれば、この拒否ルールはCrew側のツールゲートで効くため、kiro-cliのエージェント設定を書き換えても弱められないとのことです。 監査ログは署名付きで、kirocrew security verifyで整合性を確認できます。 ✅ HMAC chain intact: 1486 entries verified. Settings → Securityを開くと、いま効いている防御がまとめて見えます。 スケジュールはCLIからも登録できます。 docker exec kirocrew kirocrew cron add --every 300 \ --command "date -u; echo hello-from-crew" --silent demo-date "print the date" Added job: d54d3597 (demo-date) [every 5m] docker exec kirocrew kirocrew cron trigger d54d3597 Triggered job: demo-date (d54d3597) 実行履歴はダッシュボードのSchedule → Executionsと、データホームのcron-history/<job>.jsonlに残ります。 {"run_id": "5eac22813a1c", "job_id": "d54d3597", "trigger": "manual", "duration_ms": 70, "status": "success", "summary": "Sun Nov 1 06:28:27 UTC 2026\nhello-from-crew\n"} --atで1回きりの実行や、--script FILE.py:FUNCでPython関数も登録できますが、今回は使っていません。 Crewのメンバー(担当エージェント)はkirocrew agent createで増やせます。固有のワークスペースとメモリストアが作られます。 docker exec kirocrew kirocrew agent create --name reviewer --display-name "Reviewer" Created agent: reviewer (display name: Reviewer) Workspace: member-reviewer Appsには、Issue Radar(GitHubやGitLabのIssueのトリアージ)など30個が並んでいました。GitHubやSlackとの接続は今回試していません。 エージェントハーネスとサブエージェントごとのバックエンド Crewがエージェントを動かす実行系を「エージェントハーネス(バックエンド)」と呼びます。Settings → Agent Harnessで、新しいセッションがどのハーネスで始まるかを選べます。 手元の0.11.1では、Kiro Agent(KAS)とKiro CLIがInstalled、Claude Code、codex、deepseek、goose、opencode、piがNot installedでした。 足りないバイナリ名(claude-agent-acp、codex-acp、dsh、goose、opencode、pi-acp)も画面に出ます。 各ハーネスには能力カードがあり、Kiro Agentは「Crewのツールがチャットで使える」「Side Chatで読み取り専用ツールが動く」「作業中にメッセージを足せる」など7項目すべてに対応しています。 0.11.0以降は新規インストールのデフォルトがKiro CLIではなくKAS(表示名Kiro Agent)です。組込みのKASエンジンを使う設定を有効にすればkiro-cliのインストールも不要になるそうですが、そこは試していません。 設定ファイルではagent.acp_backendとagent.member_acp_backendがどちらもkasになっています。 v0.10.0(2026-10-25)では、サブエージェントごとにバックエンドを指定できるようになりました。 サブエージェントの起動に使うspawn_runツールへbackendパラメータが増え、タスク単位でハーネスを切り替えられます。 ツールの定義文によると、指定したバックエンドが使えなければデフォルトに置き換えず拒否し、使える一覧を返します。modelはそのバックエンドのモデルIDで渡します。続きを頼むspawn_continueは元と同じバックエンドで動きます。 同じリリースで、バックグラウンド作業とサブエージェントの役割ごとにモデルと推論強度を固定する設定も入りましたが、今回は触っていません。 実際にチャットから「backendをkiro-cliにしてサブエージェントを起動して」と頼んでみました。 kiro-cliという名前は拒否され、この環境で指定できるのはkasとkiroの2つだと返ってきました。 kiroで起動し直すと「1 agent finished」とサブエージェントは完了しましたが、軽量エージェント(kirocrew-lite)が「調べます」と言うだけでコマンドを実行せず、肝心の報告は取れませんでした。 Claude CodeやCodexは入れていないので、本来の使い方であるハーネスの使い分けまでは確認できていません。 クラスメソッドさんの記事では、Claude Codeのサブエージェントを起動してSlackコネクターを使わせる例が紹介されています。 Claude CodeやCodexは入れていないので、公式ドキュメントでハーネスごとの注意だけ確認しました。 Claude Code側で事前承認したツールはCrewの承認を通らないので、拒否ルールと監査が効きません。Codexはagent.sandboxがoffだと起動せず、piはCrewのMCPツールを受け取れません。 ハーネスを切り替えると、Crewの防御が及ぶ範囲も変わります。 業務での使い方を4パターン試す 題材は小さな注文APIのリポジトリで、ブランチにはAPIトークンのハードコード、文字列連結のSQL、合計を平均に変えてしまった退行を仕込んであります。 ログは400行の合成データで、デプロイ直後にDB接続プールが枯渇して503が7分間続き、ロールバックで収まった、という筋書きです。 1. APIキーでPRレビューをCIから回す レビューの観点と出力形式はSteeringで固定します。 .kiro/steering/review.md --- inclusion: always --- - レビューは日本語で書く。 - 指摘は「重大度 / ファイル:行 / 内容 / 修正案」の形で箇条書きにする。重大度は High / Medium / Low。 - 問題がなければ「指摘なし」とだけ書く。 差分をプロンプトに含めて標準入力から渡し、ツールは読み取り系だけ許可します。結果はrunFinishedのfinalTextから取り出します。 { echo "次の差分をセキュリティとバグの観点でレビューしてください。必要なら app/ 配下のファイルを読んで確認してください。" echo; echo '``diff'; git diff main...HEAD; echo '``'; } > review-prompt.txt kiro-cli chat --v3 --no-interactive --trust-tools=read_file,grep_search \ --output-format stream-json < review-prompt.txt \ | jq -r 'select(.type=="runFinished") | .data.finalText' 仕込んだ3つはすべてHighで拾われ、修正コードまで付いてきました。36秒、0.28クレジットです。 GitHub Actionsなら、シークレットに入れたAPIキーをenvで渡して同じコマンドを動かすだけです。公式ドキュメントの例に手元のコマンドを当てはめると、こうなります。 .github/workflows/kiro-review.yml on: [pull_request] jobs: review: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: { fetch-depth: 0 } - run: curl -fsSL cli.kiro.dev | bash - name: Review PR changes env: KIRO_API_KEY: ${{ secrets.KIRO_API_KEY }} run: | { echo "次の差分をセキュリティとバグの観点でレビューしてください。"; echo '```diff' git diff origin/${{ github.base_ref }}...HEAD; echo '```'; } > review-prompt.txt ~/.local/bin/kiro-cli chat --v3 --no-interactive --trust-tools=read_file,grep_search \ --output-format stream-json < review-prompt.txt \ | jq -r 'select(.type=="runFinished") | .data.finalText' > review.md gh pr comment ${{ github.event.pull_request.number }} --body-file review.md env: GH_TOKEN: ${{ github.token }} このワークフロー自体は今回動かしていません。手元で確認したのはコマンドの部分だけです。 2. Crewのスケジュールで朝のダイジェストを作る 平日9時に前日のログを要約するジョブを、エージェント型で登録します。回数が多いのでモデルはHaiku 5.5に固定しました。 docker exec kirocrew kirocrew cron add --cron "0 9 * * MON-FRI" --timezone Asia/Tokyo \ --model claude-haiku-5.5 morning-digest \ "/home/kirocrew/biz/logs/orders-api.log を読んで、直近のエラー件数、発生した時間帯、直前に起きたデプロイなどのイベント、推定原因を日本語で5行以内にまとめてください。" Added job: 451d6caf (morning-digest) [At 9:00 AM JST, Monday through Friday] docker exec kirocrew kirocrew cron trigger 451d6caf エラー45件、02:14から02:21、02:13:40にv2.14.0をデプロイ、02:21:14にロールバック、推定原因はDB接続プールの枯渇、と5行にまとまりました。 Haikuでも4分26秒かかっています。400行のログを読んで数えているためで、結果が届けばよい定期ジョブなら気になりません。 --channelでSlackのチャンネルにも流せますが、今回はダッシュボードで確認しています。 3. Crewのダッシュボードから障害調査を頼む 同じログについて、ダッシュボードのチャットで「エラーが集中した時間帯、内容、直前のイベント、推定原因と対処案を報告して」と頼みました。 最初のコマンドで承認待ちになりました。wcとgrepを&&でつないだ複合コマンドです。先ほどのdate単体のときは自動承認だったので、複合コマンドは人に聞く判定のようです。 実行するコマンドが見えるので、Allow onceで通しました。2回の承認のあと、3ステップで報告が返ってきました。 デプロイから最初のエラーまでの33秒、ロールバックでエラーが止まったこと、プールサイズと新機能のフラグの関係まで、ログにある事実から組み立てられています。 1.04クレジットで6分6秒でした。ステップ数が増えると時間もかかるので、急ぎの調査は手元のCLIで回し、あとから読めばよいものはCrewに任せる、というのが6分待った感想です。 4. 障害報告書をアーティファクトに残す 調査の続きで「社内向けの障害報告書をMarkdownで作成し、アーティファクトとして保存して」と頼むと、Artifactsに文書が保存されました。承認は不要で、55秒、0.67クレジットです。 アーティファクトは版管理されていて、ダッシュボードから開けます。調査のセッションと報告書が同じ場所に残るので、あとから経緯を追うのが楽です。 AWS上に別環境として切り出す devcontainerではサンドボックスが動かなかったので、Crewを自分のAWSアカウントに出してみました。EC2、Fargate、Lambda MicroVMの順に試し、以降この3通りを「レーン」と呼びます。 どれも手元のCrew(ハブ)から操作し、接続はSSMのポートフォワードだけにしました。受信ポートは開けません。 手順はスクリプトにしてkiro-crew-aws-lanesに置きました。EC2のTerraform、Fargateの01から05、MicroVMの01から05、片付けのcleanup.shがあり、この検証環境で土台の作成から起動と応答確認まで通しで動かしています。 EC2ならサンドボックスがそのまま効く まずkirocrew cloud launchを使いました。CloudFormationでインスタンスロール、インスタンス、WaitConditionを作ります。Amazon Linux 2023にkiro-cliとCrewを入れて、ゲートウェイのヘルスチェックが通るまで待つ流れです。 サイズはlightがt4g.xlarge、balancedがm7g.2xlargeで、ほかにpowerがあります。必要なIAMはkirocrew cloud iam-policyが出してくれます。 kirocrew cloud doctor --profile <aws-profile> --region ap-northeast-1 kirocrew cloud launch --profile <aws-profile> --region ap-northeast-1 --size light --idp-region us-east-1 -y 手元がIdentity Centerでサインインしていると、そのまま継承しようとして--idp-regionを要求されます。付けると[1/6]から[6/6]まで進み、途中でインスタンス上のkiro-cli loginのデバイスコードが表示されます。 最後にSSMトンネルでダッシュボードが開きます。停止はcloud stop、削除はcloud destroyです。 cloud launchは手元のサインインを継承するので、APIキーだけで無人で立ち上がる構成をTerraformでも書きました。SSM用のロール、egressだけのセキュリティグループ、IMDSv2のインスタンスで、user-dataがkiro-cliとCrewを入れてkirocrew service installで常駐させます。 APIキーはSSMのSecureStringに置き、インスタンスが起動時に取り出して.envに書きます。 terraform/main.tf(抜粋) resource "aws_instance" "crew" { ami = data.aws_ami.al2023.id instance_type = "m7g.large" iam_instance_profile = aws_iam_instance_profile.instance.name # AmazonSSMManagedInstanceCore vpc_security_group_ids = [aws_security_group.crew.id] # ingress なし metadata_options { http_tokens = "required" } user_data = templatefile("${path.module}/user-data.sh.tftpl", { region = var.region api_key_param = var.kiro_api_key_parameter # SSM SecureString の名前 crew_channel = var.crew_channel }) } 起動後に確かめたかったのは、サンドボックスが本当に効くかです。 $ kirocrew sandbox status ✅ this host does not restrict unprivileged user namespaces $ kirocrew doctor | grep backend backend: ✅ namespace ダッシュボードのSecurity画面でもProcess SandboxがStandardになり、Kiro CLIの--sandbox付きのヘッドレス実行も通りました。devcontainerで止まっていた2つが、素のLinuxではどちらも動きました。 user-dataでひとつ詰まりました。kirocrew service installは内部でsudoを使うので、crewユーザーで実行すると「a terminal is required to read the password」で止まります。 一時的にNOPASSWDのsudoers断片を置いて実行し、終わったら消す、という手順をuser-dataに入れています。 Fargateのタスクで使い捨てのcrewを動かす Fargateは常駐ではなく、タスク1つが1つのcrew(Crewが動かすエージェントの1単位)になる使い捨てワーカです。公式ドキュメントの位置付けはPreviewで、ウィザードもCLIもなく、cloud.jsonを手で書いてAPIで起動します。 kirocrew cloud iam-boundaryで権限境界(crew用とexecution用)を作る 同梱のCloudFormationテンプレートを2つデプロイする。kirocrew-fargate-base.yamlはクラスタとegress専用SGを、kirocrew-fargate-crew.yamlはcrewごとの実行ロール、タスクロール、ロググループを作る Crewコンテナのイメージを自分で作ってECRに置く Crewのサインインで得たIDドキュメントをSecrets Managerに置く cloud.jsonにfargateブロックを書き、POST /api/cloud/launchで起動する イメージは2段です。同梱のDockerfileがベース(Python 3.12とkiro-cli 2.20.2とAWS CLI)で、Dockerfile.crewがベースの上にcrewバンドルを載せる薄い層です。 ベースのビルドにはvendor/にCrewのwheelが1つ必要で、署名付きフィードのwheel_urlから取ります。途中で切れたwheelを置いたらSHA不一致で落ちたので、curl --retry -C -で取り直しました。 crewバンドルはpython -m packaging.build build --crew <name> --out <dir>で作ります。MCPやhooksは「デプロイ側の判断」として落とされ、ペルソナだけのバンドルになります。 認証情報は、APIキーではなくCrewのサインインで得たKasTokenのJSONです。 ハブのPOST /api/kas-login/deviceでIdentity Centerのデバイスフローを始めて承認します。 ハブのvault(認証情報の保管先)に入ったものをkirocrew/crew/<crew>/KIRO_IDENTITYという名前のシークレットに置きました。 ~/.kiro/crew/cloud.json(fargate ブロック) "fargate": { "cluster": "kirocrew-crew-kirocrew", "subnets": ["subnet-…"], "security_groups": ["sg-…"], "image": "<account>.dkr.ecr.ap-northeast-1.amazonaws.com/kirocrew-crew@sha256:<64桁>", "secrets": [["kirocrew/crew/fargate-demo/KIRO_IDENTITY", "arn:aws:secretsmanager:…"]], "cpu_architecture": "X86_64", "assign_public_ip": true, "task_ttl_seconds": 3600, "internal_only": true } ブロックがそろうとGET /api/cloud/provisionersにaws_fargateの行が現れ、confirm_before_launchに「このイメージにこのシークレットを渡す」という文字列が入ります。これをそのままconfirm_recipientとして送り返さないと起動は拒否されます。 curl -X POST "127.0.0.1" -H "Content-Type: application/json" \ -d '{"provider_id":"aws_fargate","profile":"<aws-profile>","region":"ap-northeast-1","size_key":"light","confirm_recipient":"<provisionersの文字列>"}' 最初はEC2と同じつもりでlogin_targetにIdentity Centerを渡しました。 preflightで次のように断られます。 a Fargate crew is credentialed by the API key its container is started with and has no interactive sign-in. Launch with the default Builder ID identity 認証情報はシークレットから渡るので、login_targetを消したら通りました。 起動ジョブは4ステップで、provisionがECSのタスクARNを返し、signinは「Already signed in.」、connectで「Added to Your crews.」になります。タスクは4 vCPUと16GBで、ECS Execが有効でした。 タスクのログを見ると、サンドボックスなしで起動したことが書かれていました。 container.supervisor WARNING no user-namespace sandbox on this host; starting UNSANDBOXED because SMC_INTERNAL_ONLY is set. container.supervisor INFO crew 'fargate-demo' installed: agent=/var/lib/kirocrew/kiro/agents/crew-fargate-demo.json INFO: Uvicorn running on 0.0.0.0 internal_onlyはこのためのフラグです。Fargateが非特権のユーザー名前空間を許さない以上、タスク自体を隔離の単位として扱うことに利用者が同意するためのものです。公式ドキュメントも「自分のcrewだけを動かす前提で、マルチテナントには使わない」と書いています。 起動後はSettings → Remote CrewにFargateのカードが増え、ConnectでSSMのフォワードが張られてCHAT APIのURLが出ます。ハブのcrew-turnはこのレーンに未対応ですので、そのURLに直接投げます。 形式はOpenAIのChat Completionsで、modelにcrew名を入れます。 curl -N -X POST 127.0.0.1 -H "Content-Type: application/json" \ -d '{"model":"fargate-demo","messages":[{"role":"user","content":"Reply with exactly one word: pong"}],"stream":true}' data: {"id": "chatcmpl-…", "object": "chat.completion.chunk", "model": "fargate-demo", "choices": [{"index": 0, "delta": {"role": "assistant", "content": "pongpong"}, "finish_reason": null}]} data: {"id": "chatcmpl-…", "object": "chat.completion.chunk", "model": "fargate-demo", "choices": [{"index": 0, "delta": {}, "finish_reason": "stop"}]} data: [DONE] stream: falseで送った1回目は400秒待っても返らず、stream: trueにしたら数秒で返りました。本文が「pongpong」と二重になっているのも、そのまま載せておきます。 Lambda MicroVMでも同じことができる Fargateと同じ使い捨てワーカを、Lambda MicroVMs(Firecrackerの1VM)で動かすレーンもあります。東京リージョンにも管理イメージal2023-1がありました。 段取りはFargateと似ています。同梱のkirocrew-microvm-base.yamlでKMSキー、レシピ用のS3バケット、ビルドロール、SSMハイブリッドアクティベーション用ロール、実行ロールを作り、cloud.jsonにmicrovmブロックを書きます。 Fargateと違ってイメージは手元でビルドしません。レシピzip(Dockerfile.microvmとwheelとバンドル)をS3に置き、Lambda側でイメージを作ります。 MicroVMでもwheelで詰まりました。デスクトップ用のwheelをそのまま置くとcarries 2992 dashboard asset(s) under kiro_crew/static/ ... over its 67108864-byte ceilingと断られます。 リポジトリのscripts/build_microvm_image_zip.pyはソースのチェックアウトからビルドする前提です。代わりにwheelからkiro_crew/static/を抜いてRECORDを書き換えたもの(100.9MBから41.2MB)を置きました。 起動ジョブは初回のイメージビルドを含めて8分ほどで完了し、provisionがmi-…(SSMのマネージドインスタンスID)を返しました。Lambda側でもイメージがCREATED、MicroVMがRUNNINGになっています。 こちらはゲストの全ルートが認証必須で、SSMで転送したポートへ直接/healthを呼ぶとcontrol_forbiddenです。ハブのcrew-turn経由なら通ります。 curl -X POST "127.0.0.1" -H "Content-Type: application/json" \ -d '{"thread":"verify-1","message":"Reply with exactly one word: pong","stream":false}' {"object": "chat.completion", "model": "fargate-demo", "choices": [{"index": 0, "message": {"role": "assistant", "content": "pong"}, "finish_reason": "stop"}]} 65秒でpongが返りました。VMはデフォルトの1時間が過ぎると消え、会話もVMと一緒になくなります。 サンドボックスをそのまま使いたいならEC2です。短時間の仕事を切り出すだけならFargateかMicroVMで足ります。FargateとMicroVMはまだ手書きの設定とAPI起動だけですので、記事の時点では試す人向けです。 料金 料金ページのプランと月あたりのクレジット(ユーザー単位)は次のとおりです。 プラン 月額 クレジット Free $0 50 Pro $20 1,000 Pro+ $40 2,000 Pro Max $100 5,000 Power $200 10,000 追加クレジットは$0.04です。APIキーの消費もこのクレジットから引かれ、Crew自体は無料です。 クレジットはモデルごとの倍率で消費されます。手元の実測は、autoでヘッドレスの短い質問が0.09、対話モードでファイルを1つ読んで答える質問が0.14、Crewでコマンドを1回実行して答える依頼が0.42でした。 Haiku 5.5は100Kトークンまでなら0.06倍です。定期ジョブのように回数が多いものは--modelで安いモデルを指定すると効きます。コマンド型のスケジュールはそもそもモデルを呼びません。 まとめ Kiroは「IDEでSpecを書く」から、「CLIをCIから呼び、Crewに常駐してもらう」まで範囲が広がりました。 APIキーはヘッドレス専用で、対話はブラウザ認証です。CI用の端末にはキーを置き、手元の端末はログインのままにすれば迷いません。 業務で試した4パターンのうち、PRレビューはCIに組み込める形まで動き、定期ダイジェストと障害調査はCrewに任せられる手応えがありました。 Crewは拒否リストと監査ログが最初から入った状態で届くので、常駐させる前提の作りになっています。ハーネスをClaude CodeやCodexに切り替えると、防御が及ぶ範囲はハーネスごとに変わります。サンドボックスが前提の機能も多く、コンテナ環境では動かないものが残ります。 自律モードとCrewのサンドボックスを本来の形で試すなら、素のLinuxかmacOSを用意するのが近道で、AWSならEC2に出すのが一番簡単でした。

Kiro の初期セットアップ後によく聞かれる設定をまとめる【IT 管理者編】 はじめに こんにちは！AWS でソリューションアーキテクトをしている町田です。 Kiro の導入支援をしていると、利用者の方からの相談と並んで、IT 担当の方から次のような相談を受けます。 「社員の PC にまとめて設定を配りたい」 「利用者が自分で許可しても、組織として止めたいものは止めたい」 「使える MCP サーバーやモデルを、会社で決めたものに絞りたい」 「社用のサインイン方式だけを使わせたい」 本記事では、これらに答える Kiro の設定を説明します。対象は Kiro IDE と Kiro CLI（V3）で、Windows の PC に配る前提です。記事は 2 本に分けました。 記事 対象 内容 利用者編 Kiro を使う方 日本語化、Python、確認のボタン、steering、skills、MCP、モデル IT 管理者編（この記事） 社員の PC に設定を配る IT 担当の方 managed-settings.json、使える MCP やモデルの制限、チームへの配り方 1 章の「やってみる」では、利用者編の 1・2・5 章で許可した操作を、管理者の設定で止めて確かめます。先に利用者編の手順を試しておくと、違いが分かりやすくなります。 ! 個人の見解であり、所属する組織の公式見解ではありません。 本記事の内容は 2026-11-01 時点 の公式ドキュメントに基づきます。Kiro は更新が速いため、最新の公式ドキュメントもあわせて確認してください。 先に結論 組織として止めたい操作は、managed-settings.json の deny と ask に書きます。 利用者の設定より優先されます。allow は書けないので、確認を減らすのは利用者の設定の役目です（1 章）。 managed-settings.json は「うっかり防止」です。 コマンドの禁止は書き方を変えると通り抜け、ローカル管理者の権限がある利用者はファイルを消せます。確実に止めたいことは、PC の管理やネットワークで止めます（1 章）。 managed-settings.json は配る前にテスト端末で 1 回起動します。 壊れているとすべてのツールが止まります（1 章）。 使える MCP サーバーは MCP レジストリで、使えるモデルは承認リストで絞ります。 どちらも Kiro コンソールの設定で、IAM Identity Center などでサインインした利用者に効きます（2・3 章）。 permissions は、作業フォルダに置いてもチームには配れません。 作業フォルダ単位の許可は、フォルダの外に保存されるためです。そろえたいなら PC に配るか、managed-settings.json を使います（4 章）。 章 内容 前提 設定ファイルの置き場所と、グローバルと作業フォルダの両方に置いたときの動き 1. managed-settings.json 端末に組織の決まりを配る 2. MCP レジストリ 使える MCP サーバーを絞る 3. モデルの承認リスト 使えるモデルを絞る 4. チームに配る 何をどこに置けばチームに行き渡るか 前提：設定ファイルの置き場所と読み込まれ方 Kiro の設定には、グローバル（~/.kiro/、自分の全プロジェクト）、プロジェクト（<作業フォルダ>/.kiro/）、エージェント（カスタムエージェントの定義）の 3 つのスコープがあります（Configuration scopes）。 設定 グローバル プロジェクト 同じものが複数あるとき steering ~/.kiro/steering/ .kiro/steering/ 全部読み込む（矛盾したらプロジェクト優先） skills ~/.kiro/skills/ .kiro/skills/ 全部読み込む（同じ名前ならプロジェクト優先） permissions ~/.kiro/settings/permissions.yaml ~/.kiro/workspace-roots/<hash>/permissions.yaml（作業フォルダの外） deny が勝つ MCP ~/.kiro/settings/mcp.json .kiro/settings/mcp.json エージェント > プロジェクト > グローバル カスタムエージェント ~/.kiro/agents/ .kiro/agents/ 同じ名前ならプロジェクト優先 CLI の設定 ~/.kiro/settings/cli.json .kiro/settings/cli.json（モデルごとの既定値など、一部の設定だけ） プロジェクト優先 CLI V3 では、/config でいまのセッションに効いている steering・skills・MCP・エージェント・Powers・Hooks の一覧を確認できます。 /config # 一覧 /config steering # steering だけ ワークスペースの信頼 作業フォルダの .kiro\ に置いた設定は、そのフォルダを信頼するまで読み込まれません（Permissions > Workspace trust）。人からもらったフォルダや、インターネットから取ってきたフォルダに、AI の振る舞いを変える設定が仕込まれているのを防ぐためです。 信頼していないワークスペースでは、Kiro は次のように動きます。 .kiro/ 配下のカスタムエージェント・steering・MCP の設定・skills を読み込まない allow の規則があっても、シェルコマンドと MCP ツールを毎回確認する .kiro/steering や .kiro/skills への書き込みを確認する 信頼したかどうかはフォルダの外に保存されるので、フォルダの中身が自分で自分を信頼させることはできません。 CLI V3 では、フォルダで初めて起動したときに Trust this workspace? の画面が出ます。ただし、--no-interactive で動かすときや、V1 / V2 では、この確認は出ずに作業フォルダの設定が読み込まれます。 グローバルとワークスペースの違い グローバル（~.kiro\）と作業フォルダ（ワークスペース）の両方に同じ種類の設定を置いたとき、どちらが効くかを、公式ドキュメントから読み取ってまとめました。筆者は実機では試していません。 読み飛ばしても、各章の手順はそのままできます。 # 設定の置き方 ドキュメントから読み取れる動き 出典 A グローバルに steering を置く どの作業フォルダでも読み込まれる Steering B グローバルと作業フォルダの両方に、矛盾するルールの steering を置く 上書きではなく両方読み込まれ、矛盾したところは作業フォルダの方が優先される Steering、Configuration C 同じ名前の skill を、グローバルと作業フォルダの両方に置く 作業フォルダの skill が使われる Skills D C の作業フォルダの外で、同じ skill を呼ぶ グローバルの skill が使われる。作業フォルダの skill は、そのフォルダでだけ使われる Skills E 同じ名前の MCP サーバーを、グローバルでは有効、作業フォルダでは無効にする そのフォルダでは無効になる。作業フォルダの設定が優先される MCP configuration F グローバルの permissions で、あるコマンドを確認なしにする どの作業フォルダでも確認なしで実行される（信頼していないフォルダを除く。H を参照） Permissions G 確認ダイアログで Always allow → This workspace を選ぶ そのフォルダでだけ確認が出なくなる。許可は作業フォルダの外（~.kiro\workspace-roots\）に保存される Permissions H 作業フォルダを 信頼せずに 開く 作業フォルダの .kiro\ の steering・skills・MCP・カスタムエージェントは読み込まれない。シェルコマンドと MCP ツールは、グローバルで確認なしにしていても毎回確認される Workspace trust I steering を読み込む設定のないカスタムエージェントを使う steering は自動では読み込まれない Steering 1. managed-settings.json：端末に組織の設定を配る よくある質問：「利用者が勝手に allow を書いても、組織として止めたいものは止めたい」「PC に一括で配りたい」 managed-settings.json は、管理者が端末に置く設定ファイルです。IDE と CLI が同じファイルを読みます（Permission policies、Sign-in controls）。 OS 置き場所 配り方 Windows C:\ProgramData\Kiro\managed-settings.json Intune、Group Policy、SCCM macOS /Library/Application Support/Kiro/managed-settings.json Jamf、Kandji Linux /etc/kiro/managed-settings.json 構成管理ツール いずれも管理者・root 権限がないと書き換えられない場所です。 まずやること：利用者編で許可してきた操作を、管理者の設定で止めてみます。管理者の設定が利用者の設定より優先されることを確かめてから、配る内容を決めます。 やってみる 利用者編で許可したことを、管理者の設定で止めてみる 利用者編では、利用者の設定で、いくつかの操作を許可しました。IT 管理者が managed-settings.json で止めると、それらがどうなるかを確かめます。次の 4 つの決まりだけを書いた managed-settings.json を使います。 利用者編 利用者の設定で許可したこと 管理者の決まり 試す頼み方 こうなれば OK 2 章 drafts フォルダへの保存を、確認なしにした drafts フォルダへの保存を禁止 試し ① 保存できない 1 章（Python を入れる） Kiro が Python の公式ドキュメントを読む 業務で使うドメイン以外の Web の取得を禁止 試し ② ページを読めない 5 章 AWS のドキュメントを調べる MCP MCP のツールは毎回確認 試し ③ 使うたびに確認が出る 1 章 ライブラリのインストール（確認を見て Allow） pip install などのインストールのコマンドを禁止 試し ④ 止まる。ただし、コマンドの書き方によっては通る（下の試し ④） 中身は次のとおりです。 { "rules": [ { "capability": "shell", "match": [ "python -m pip install*", "py -m pip install*", "pip install*" ], "effect": "deny" }, { "capability": "fs_write", "match": [ "/drafts/" ], "effect": "deny" }, { "capability": "web_fetch", "exclude": [ "docs.aws.amazon.com", "*.amazonaws.com", "kiro.dev" ], "effect": "deny" }, { "capability": "mcp", "effect": "ask" } ] } 手順 先に、利用者編の 1・2・5 章の手順で、表の「利用者の設定で許可したこと」が動くことを確かめておきます エクスプローラーのアドレス欄に C:\ProgramData と入力して開きます。Kiro フォルダがなければ作ります メモ帳を開いて上の内容を貼り付け、名前を付けて保存 で、ファイル名を managed-settings.json、ファイルの種類を すべてのファイル、エンコードを UTF-8 にして、いったんデスクトップに保存します。保存したファイルを Kiro フォルダにコピーし、管理者の確認が出たら 続行 を押します。ファイル名は managed-settings.json にしてください。 ほかの名前だと Kiro は読み込みません。書き間違えがあると、Kiro のツールがすべて止まるので、中身は書き換えないでください 置けたかどうかは、PowerShell で次の 2 行を実行して確かめます。1 行目に managed-settings.json が表示され、2 行目でエラーが出なければ OK です Get-ChildItem "$env:ProgramData\Kiro" Get-Content "$env:ProgramData\Kiro\managed-settings.json" -Raw | ConvertFrom-Json Kiro のウィンドウをすべて閉じてから、開き直します Kiro で、利用者編の 2 章でルールを置いた作業フォルダを開き、次の 4 つの文を送ります。前の答えに引きずられないように、1 つ送るごとに新しいチャットを開きます 試し ①：確認なしにした保存が、できなくなるか（利用者編 2 章） drafts フォルダに test.txt というファイルを作って、中に「テスト」とだけ書いて。 利用者編の 2 章で「確認なしで保存してよい」にした drafts フォルダなのに、保存が止められれば成功です。Kiro がコマンドなど別の方法で書こうとしたら、確認のボタンで Deny を押します。 試し ②：Web のページが読めなくなるか（利用者編 1 章の Python を入れる手順） Web 検索は使わずに、次のページを直接読んで、要点を 3 行で教えて。 docs.python.org ツールの欄に Blocked by administration permission policy（管理者の決まりで止められた）と出て、ページを読めなかった理由が返ってくれば成功です。筆者の環境では、Kiro は Web 検索やコマンドで回り道をせず、「制限を外す必要があれば、管理者に相談してください」と答えました。 試し ③：MCP のツールに確認が出るか（利用者編 5 章） AWS Knowledge MCP Server を使って、S3 のバケットの名前の付け方のルールを調べて。 MCP のツールを使うたびに確認のボタンが出れば成功です。利用者編の 5 章で、MCP のツールを確認なしにしていた場合も、確認が出ます。 試し ④：ライブラリのインストールを止められるか（利用者編 1 章） python-pptx を、インストールし直して。すでに入っていても、もう一度入れて。 ツールの欄に Blocked by administration permission policy と出て、インストールが実行されなければ成功です。筆者の環境で 2 回試すと、2 回とも Kiro は python -m pip install ... を実行しようとして、managed-settings.json の禁止の決まりで止められました。Kiro も「組織が決めた制限なので、別の書き方で回り込むことはしていません」と答えています。 ただし、書き方が違うと止まりません。 利用者編の 1 章で python という名前を使えるようにする前に同じことを試したときは、Kiro は python が使えないと分かると、& "<Python の場所>\python.exe" -m pip install ... のように Python の場所を直接書く書き方に切り替えました。このコマンドはどの禁止の決まりにも当たらず、インストールが実行されました。 ! コマンドの禁止で、インストールを止めきるのは難しいと考えてください。 今回止まったのは、Kiro がたまたま禁止した書き方を選んだからです。コマンドの決まりは、コマンドの先頭からの文字列で照らし合わせます。インストールのコマンドは、pip、python -m pip、py -m pip、Python の場所を直接書く形、uv、winget、スクリプトの中に書く形など、書き方がいくらでもあります。禁止する書き方を増やしても、Kiro が動く書き方を探して別の書き方を選ぶと、そのまま通ります。Kiro が禁止をすり抜けようとしたわけではなく、動く書き方を選んだだけでも、こうなります。 インストールを確実に止めたいなら、コマンドの禁止ではなく、PC の管理（ローカル管理者の権限を外す、配るソフトを決める）やネットワーク（pypi.org などへの通信を止める）で止めます（「知っておくとよいこと」の最後）。 Kiro の設定にも、コマンドの書き方に左右されない方法が 1 つあります。Local command sandbox（Kiro IDE 1.3 以降、Kiro CLI 2.31 以降の V3）で networkAccess を DEFAULT_BLOCKED にすると、AI が実行するコマンドから外への通信が止まるので、どの書き方の pip install もダウンロードできなくなります（筆者は実機では試していません）。ただし、sandbox は既定でオフで、設定ファイル（sandbox.json）は利用者が自分で書くものです。利用者は自分でオフにでき、managed-settings.json で sandbox をオンに固定する方法もドキュメントには見当たらないので、組織として止める手段にはなりません。 ! C:\ProgramData\Kiro\managed-settings.json がすでにある PC では、この実験をしないでください。 会社が配っている設定なので、上書きすると会社の決まりが外れます。テスト用の PC で試します。 結果から分かるのは、次の 3 つです。 管理者の決まりは、利用者の設定より優先されます。 Kiro は、いちばん厳しい決まりを採るためです（Permissions）。利用者が「確認なしで進める」にしていても、管理者が「毎回確認」「禁止」にした操作はそのとおりになります コマンドの禁止は、書き方を変えると通り抜けます。 試し ④ のとおり、禁止した書き方なら止まりますが、別の書き方では実行されることがあります。コマンドの禁止は「うっかり防止」と考え、確実に止めたいことは PC の管理やネットワークで止めます 管理者の設定でできるのは、止めることと、確認させることだけです。 管理者の決まりに「確認なしで進める」（allow）は書けません（Permission policies）。確認を減らすのは、利用者の設定（利用者編 2 章）の役目です 片付ける：試し終わったら、C:\ProgramData\Kiro\managed-settings.json を削除して、Kiro を開き直します。残したままだと、drafts への保存、Python の公式ドキュメントの読み込み、pip install で始まるインストールが止まったままになります。 実際に配る内容は、「知っておくとよいこと」の 3 段階のテンプレートから選びます。 知っておくとよいこと（必要になったら読む） managed-settings.json に任せること、任せないこと managed-settings.json は、うっかりや事故を減らすための仕組み と考えます。コマンドの禁止は書き方を変えると通り抜けますし（「やってみる」の結果）、ローカル管理者の権限がある利用者はファイルを消して外せます。確実に止めたいことは、PC の管理やネットワークの側で止めます。 やりたいこと 向いている仕組み 理由 認証情報や機密フォルダを AI に読ませない・書き換えさせない managed-settings.json（fs_read / fs_write の deny） コマンドの書き方ではなく、ファイルの場所で照らし合わせる。ただし、AI がコマンドでファイルを読み書きする場合は、shell の規則で判定される 業務と関係ない Web のページを読ませない managed-settings.json（web_fetch の deny） 「やってみる」の試し ② で止まることを確かめた MCP のツールを使うたびに確認させる managed-settings.json（mcp の ask） すべての MCP に効く 社用のサインイン方式だけにする managed-settings.json（signin_method） サインインの画面で選べる方式を絞れる。ファイルを置いていない PC と Kiro Web には効かない（Sign-in controls） 取り返しのつかないコマンドを止める managed-settings.json（shell の deny） うっかり防止として使う。書き方を変えると通り抜ける ソフトやライブラリのインストールを止める PC の管理、ネットワーク コマンドの禁止はすり抜ける。Local command sandbox で外への通信を止める方法もあるが、利用者がオフにできる（「やってみる」の試し ④、下の「自分の PC に入れたくないとき」） managed-settings.json を消させない 利用者からローカル管理者の権限を外す これがないと、ほかの決まりもまとめて外せてしまう 書けるもの 部分 中身 対応バージョン rules（permissions） deny と ask だけ。allow は書けない — rules（signin_method） 使わせないサインイン方式 IDE 1.2 以降、CLI 2.25.0 以降 settings IAM Identity Center の Start URL とリージョン、外部 IdP の情報、ヘルプページの URL 同上 3 段階のテンプレート 最初から厳しくすると利用者が使いにくさを感じて個人アカウントや別のツールに流れやすいので、① から始めて、運用しながら ② → ③ へ絞る 進め方をお勧めします。 段階 読み取り（fs_read） コマンド（shell） Web サインイン ① まず始める 認証情報のファイルを deny 取り返しのつかないコマンドを deny 制限しない 社用の方式だけ ② 標準 ① に加えて、社内の機密フォルダを deny ① に加えて、外にデータが出るコマンドを ask 業務のドメイン以外を deny 同上 ③ 厳格 ② と同じ すべて ask（① の deny はそのまま） 取得・検索とも deny 同上 ① まず始める（このまま全員に配る） 認証情報のファイルの読み書きと、取り返しのつかない操作だけを止めます。業務を妨げずに事故を防ぐ組み合わせです。 { "rules": [ { "capability": "fs_read", "match": ["/.env", "/.env.", "/.pem", "/*.key", "/.aws/", "/.ssh/"], "effect": "deny" }, { "capability": "fs_write", "match": ["/.env", "/.env.*", "/.aws/", "/.ssh/"], "effect": "deny" }, { "capability": "shell", "match": [ "rm -rf *", "Remove-Item -Recurse", "rmdir /s*", "rd /s*", "del /s*", "git push --force*", "git push -f*", "sudo *" ], "effect": "deny" }, { "capability": "signin_method", "match": ["*"], "exclude": ["idc"], "effect": "deny" } ], "settings": { "idc_start_url": "my-org.awsapps.com", "idc_region": "ap-northeast-1", "signin_help_url": "it.example.com" } } 規則 狙い fs_read / fs_write の deny .env、秘密鍵、AWS の認証情報、SSH の鍵を AI に読ませない・書き換えさせない shell の deny フォルダごとの削除（macOS / Linux の rm -rf、PowerShell の Remove-Item -Recurse、コマンドプロンプトの rmdir /s・rd /s・del /s）、リモートの履歴を壊す強制 push、管理者権限での実行（sudo。Windows 11 の sudo も同じ名前）を止める。* は空白を含む任意の文字列に一致するので、Remove-Item -Recurse は -Recurse がどの位置にあっても当たる。ただし、-r のような短縮形や、rm・ri などの別名で書かれると当たらない signin_method 社用の IAM Identity Center 以外でのサインインを止める。個人の GitHub などで入ると、MCP の統制が効かず、内容がサービス改善に使われる可能性があるため。外部 IdP に直接つないでいる場合は exclude を external_idp にする ② 標準（① の rules に追加する） 機密フォルダの読み取りを止め、外にデータが出る操作は人が確認してから実行します。次の 3 行は、① の rules の [ ] の中に足す部分です。① の最後の規則（signin_method の行）の後ろにカンマを付けてから貼り付けます。このままでは 1 つのファイルとしては読み込めません。 { "capability": "fs_read", "match": ["/confidential/", "/人事/"], "effect": "deny" }, { "capability": "shell", "match": ["git push*", "curl *", "wget *", "aws *"], "effect": "ask" }, { "capability": "web_fetch", "exclude": ["docs.aws.amazon.com", ".amazonaws.com", "kiro.dev", ".github.com"], "effect": "deny" } 機密フォルダの名前（confidential・人事）は、実際のフォルダ構成（共有ドライブのパス、プロジェクト名など）に置き換えます web_fetch の exclude に書いたドメインは、管理者の規則の対象外になり、利用者の設定に従います。業務で使う公式ドキュメントのドメインを入れます mcp を ask にしたい場合もこの段階で足します（{ "capability": "mcp", "effect": "ask" }） ③ 厳格（② の rules に追加する） 機密案件や閉域環境など、AI が勝手に外へ出ることを一切認めない場合の設定です。② と同じく、rules の [ ] の中に足す部分です。 { "capability": "shell", "match": ["*"], "effect": "ask" }, { "capability": "web_fetch", "effect": "deny" }, { "capability": "web_search", "effect": "deny" } すべてのシェルコマンドが確認になります。① で deny にしたコマンドは、deny が ask より強いので deny のままです ② の web_fetch の exclude 付きの規則は残っていても構いませんが、③ の deny が勝つため、すべての Web 取得が止まります ! shell の規則は、コマンドの先頭からの文字列の一致で判定します。;・&&・|・|| でつないだコマンドは分割して判定されます。Kiro IDE 1.4.51 以降と Kiro CLI V3 では、規則と照らし合わせられないほど複雑な bash・PowerShell のコマンドは止められ、AI に書き直しが求められます。cmd.exe のコマンドは確認が出ます（Permissions > Shell command parsing）。それでも、試し ④ のように、別の書き方のコマンドは通ることがあります。外部への持ち出しを確実に止めたいなら、社内の Proxy・FW の許可リストを重ねてください。 配る前のチェックリスト managed-settings.json は、壊れているとすべてのツールが止まります。 配る前にテスト端末で次を確認してください。 UTF-8（BOM なし）で保存した（Windows PowerShell の Out-File は既定で UTF-16 を書くので使わない） JSON として正しい（末尾のカンマやコメントがない） effect に allow が入っていない（1 つでもあるとファイル全体が無効） フィールド名のつづりが正しい（effct のような未知のフィールドがあると全ツールが拒否される） shell・web_fetch・mcp のパターンに ** や ? を使っていない サインイン方式の名前が idc・external_idp・builder_id・google・github・social のどれかになっている（画面の表示名は使えない） Kiro を再起動して、IDE の通知や kiro-cli login の Warning: 行が出ない 標準ユーザーでファイルを保存しようとして、拒否される ! 壊れたときの倒れ方が、規則の種類で逆です。 permissions の規則：壊れていると 全ツールを拒否（安全側） サインイン方式の規則：壊れていると 全方式を許可（利用者を締め出さないため） 同じファイルに両方を書いていると、JSON が壊れたとき「サインインは何でも通るが、ツールは全部止まる」状態になります。 ! managed-settings.json もクライアント側で強制されます。 端末のローカル管理者権限を持つ利用者は、ファイルを消して回避できます。利用者にローカル管理者権限を渡していない環境で使う前提の仕組みです。 managed-settings.json に入らないもの 設定 配り方 自動更新の向き先・停止（IDE は UpdateUrl・UpdateMode、CLI は update.baseUrl など） OS のポリシー（macOS は IDE が dev.kiro.desktop、CLI が dev.kiro.cli ドメイン）。Managed updates steering・skills・利用者の permissions ~/.kiro/ 配下にファイルとして配る（利用者が消せる） モデルの承認リスト・MCP・Web ツール・API キー Kiro コンソール 自分の PC に入れたくないとき：仮想デスクトップで使う Kiro や Python、ライブラリを自分の PC に入れたくない場合は、Amazon WorkSpaces のような仮想デスクトップで Kiro を使う方法があります。Kiro が入れるソフトやライブラリは仮想デスクトップの中に入るので、自分の PC には何も入りません。 仮想デスクトップは管理者が用意して配るので、何が入っているかも管理者がまとめて把握できます。 WorkSpaces にしても、WorkSpaces の中でのインストールは止まりません。 WorkSpaces Personal は、既定で利用者がローカル管理者です。また、利用者編の 1 章のライブラリのように、自分のユーザーフォルダに入れるインストールは、管理者の権限がなくてもできます。WorkSpaces の中で入れられるものも絞りたい場合は、次の 3 つを組み合わせます。 やること 効き方 ローカル管理者の権限を外す（ディレクトリの Local administrator setting） 管理者の権限が要るインストールと、managed-settings.json の削除を防ぐ。変更は、新しく作る WorkSpace と、作り直した WorkSpace に反映される。この設定を使えるのは、AWS Directory Service（AD Connector、AWS Managed Microsoft AD、Simple AD）で管理しているディレクトリだけ（Manage local administrator permissions） 外への通信を絞る（セキュリティグループ、AWS Network Firewall） pypi.org などへの通信を止めるので、ユーザーフォルダへのインストールも、コマンドの書き方に関係なく失敗する。セキュリティグループは、既定ではすべての外向きの通信を許可している（How do I restrict internet access on WorkSpaces Personal?） 必要なものを入れたイメージを配る Kiro、Python、ライブラリを最初から入れておき、利用者には入れさせない（How to secure your Amazon WorkSpaces for external users） 外への通信を絞るときは、Kiro のサインインやモデルの呼び出しに必要な行き先は通します。必要な行き先は、構成を決める前に公式ドキュメントで確認してください pypi.org を止めた環境では、利用者編の 1 章の「PowerPoint・Excel・Word 用のライブラリを入れる」の手順は使えません。Python とライブラリは、管理者がイメージに入れておきます 2. MCP レジストリ：使える MCP サーバーを絞る 管理者は Kiro コンソールで、MCP 自体を無効にするか、許可するサーバーの一覧（MCP レジストリ）を登録できます（Kiro Enterprise > MCP）。 MCP レジストリ URL に入れるもの Kiro コンソールの Settings > Shared settings > MCP Registry URL（日本語の画面では セッティング > 共有設定の詳細 > MCP レジストリ URL - オプション）には、許可するサーバーの一覧を書いた JSON ファイルの URL を 1 つ入れます。サーバーの一覧そのものを欄に書くのではありません。 mcp-registry.example.co.jp JSON ファイルも、それを置く場所も、管理者が自前で用意します。 Kiro は置き場所を用意しません。ドキュメントには、Kiro コンソールに JSON を直接アップロードする方法も書かれていません。置き場所には、次の 2 つの条件があります。 有効な証明書の HTTPS であること（自己署名の証明書は使えません） 利用者の PC から読めること（社内ネットワークの中だけで見える URL でも構いません） ドキュメントには、置き場所の例として Amazon S3・Apache・nginx が挙がっています。社内に条件を満たす Web サーバーがあれば、そこに置けます。ない場合は、AWS 上に S3 と CloudFront を自前で用意して配信します。S3 のバケットは公開せず、CloudFront の Origin Access Control 経由で読ませます。 JSON ファイルの書き方 AWS Knowledge MCP Server だけを許可する例です。書き方は、MCP の公式の登録簿（MCP Registry）の形式の一部です。 { "servers": [ { "server": { "name": "aws-knowledge-mcp-server", "title": "AWS Knowledge", "description": "AWS の公式ドキュメントやブログを検索する", "version": "1.0.0", "remotes": [ { "type": "streamable-http", "url": "knowledge-mcp.global.api.aws" } ] } } ] } 項目 書き方 name ファイルの中で重複しない名前。3〜200 文字の英数字と ._- description 説明。100 文字まで version 1.0.0 のような番号。^1.2.3 のような範囲の書き方は使えない remotes インターネットや社内のサーバーにつなぐ場合。1 件だけ。type は streamable-http か sse packages PC の上でプログラムを動かす場合。1 件だけ。registryType は npm・pypi・oci のどれか。それぞれ npx・uvx・docker で起動するので、利用者の PC にあらかじめ入れておく サーバーを足すときは、servers に 1 件を加えて、同じ URL のファイルを上書きします。Kiro が読み直すので、コンソールの設定を変える必要はありません。 登録するとどう動くか 一覧にないサーバーは、表示されず、起動もしません。 利用者が自分の mcp.json に書いたサーバーも同じです。IDE の MCP パネルには「N servers hidden」とだけ出ます（MCP registry） 利用者は、MCP パネルに出る一覧からサーバーを選んで追加します。 CLI では /mcp add で選びます CLI V3 では、mcp.json の書き方も変わります。 レジストリのサーバーは、"aws-knowledge-mcp-server": { "type": "registry" } のように "type": "registry" と書いた項目だけが起動します。利用者編の 5 章のように url や command を自分で書いた項目は、名前が一覧と同じでも読み飛ばされます（MCP registry > Servers not in the registry） Kiro は、起動したときと 24 時間ごとに一覧を読み直します。 一覧から外したサーバーは、利用者の PC でも止まります 効くのは、IAM Identity Center か API キーでサインインした利用者だけです。 Builder ID やソーシャルログインの利用者には効きません 制限は利用者の PC の側でかけています。 PC の管理者の権限を持つ人は外せます 登録するときに気をつけること JSON ファイルには、トークンなどの秘密を書きません。 URL を知っている人なら読めるファイルにすることが多いためです。利用者は自分の mcp.json で、HTTP ヘッダーや環境変数を足して上書きできるので、トークンはそちらに書いてもらいます URL を登録した時点で、一覧にないサーバーはすべて止まります。 利用者がいま使っているサーバーを先に調べて、一覧に入れておきます 3. モデルの承認リスト：使えるモデルを絞る 管理者は Kiro コンソールの Settings > Shared settings > Model availability（日本語の画面では セッティング > 共有設定の詳細 > モデルの可用性）で Control which models are available to users（ユーザーが利用できるモデルを制御）をオンにし、Manage approved list で承認リストを作ります。組織の既定のモデルも、ここで指定できます（Kiro Enterprise > Models）。押さえておくことは次の 4 つです。 承認リストは プロファイルの共有設定の 1 項目 です。コンソールの画面には、利用者やグループを選ぶ項目はありません（筆者の画面で確認） 承認リストを使うと、新しいモデルは管理者が選んで保存するまで使えません。 新しいモデルが出るとコンソールに通知が届くので、使わせたいものを選んで保存します。承認リストを使わない（オフの）間は、新しいモデルは自動で使えるようになります（Fable 5.1 と Kimi K3 を除く） Auto を許可すると、承認していないモデルに処理が回ることがあります。 承認したモデルだけで処理したいなら、Auto を外して既定のモデルを指定します（Available models） experimental のモデルと Kimi K3 は、出力に対する補償の対象外 です（Kiro Excluded Models） 4. チームに配る：何をどこに置けばよいか 「何をどこに置けばチームに行き渡るか」をまとめます。 設定 作業フォルダごと共有 IT 管理者が ~/.kiro/ に配る managed-settings.json Kiro コンソール steering ◎ プロジェクトの規約 〇 全社の規約（消せる） — — skills ◎ プロジェクトの手順 〇 全社の手順（消せる） — — permissions の allow ✕ 置けない 〇 確認を減らす既定値 ✕ 書けない — permissions の deny / ask ✕ 置けない △ 利用者が消せる ◎ 消せない（ローカル管理者以外） — MCP サーバーの定義 ◎ .kiro/settings/mcp.json 〇 — — 使える MCP の制限 — — — ◎ レジストリ カスタムエージェント ◎ .kiro/agents/ 〇 — — 既定のモデル・effort △ エージェントの model、.kiro/settings/cli.json（CLI のみ） 〇 ~/.kiro/settings/cli.json（CLI のみ） — 〇 組織の既定のモデル 使えるモデルの制限 — — — ◎ 承認リスト サインイン方式 — — ◎ 〇 デバイスフロー（CLI） steering は、次の 2 つの方法で配れます。 方法 対象 置き場所 作業フォルダごと共有する（共有ドライブ、Git など） そのフォルダを使う全員 作業フォルダの .kiro\steering\ IT 管理者が PC に配る 配った先のユーザーの全部の作業 そのユーザーの ~.kiro\steering\（公式に「Team steering」として記載） よくある質問 Q. 利用者ごとに使えるモデルを変えたい Kiro の承認リストは、プロファイルの共有設定の 1 項目です。コンソールの画面には利用者やグループを選ぶ項目がなく、利用者ごとに分ける方法は見当たりません（3 章）。用途ごとの既定はカスタムエージェントの model で決められますが、利用者はモデルを切り替えられます。 Q. Auto を選んだとき、どのモデルが使われたかを知りたい 公式の手段はありません（2026-11-01 時点）。 プロンプトログの項目には、モデル名はありません クレジットは Auto の倍率（1.0 倍）で数えられるので、消費量から推測することもできません 回答ごとにモデルを表示してほしいという要望は、公式の GitHub に Issue として上がっています（kirodotdev/Kiro#8903） 公式に書かれているのは、Auto が振り分ける範囲だけです。Auto は、そのプロファイルで使える Active のモデルに振り分け、experimental（試験提供）のモデルには振り分けません。管理者の承認リストの外のモデルに振り分けることもあります（Available models）。 どのモデルで処理したかを把握したいなら、Auto ではなくモデルを指定して使ってください。 組織として必要なら、管理者が承認リストから Auto を外し、承認済みのモデルを既定にします。こうすれば、管理者のユーザー単位のアクティビティレポートにあるモデルごとのメッセージ数の列が、そのまま「使ったモデル」になります（Viewing per-user activity）。 まとめ 組織として止めたい操作は managed-settings.json の deny と ask に書く。 allow は書けないので、確認を減らすのは利用者の設定に任せる managed-settings.json は「うっかり防止」と考える。 確実に止めたいことは、ローカル管理者の権限を外す、通信を絞るなど、PC の管理やネットワークで止める managed-settings.json は配る前にテスト端末で 1 回起動する。 壊れると全ツールが止まる 使える MCP サーバーはレジストリ、使えるモデルは承認リストで絞る。 Auto を許可すると、承認していないモデルに処理が回ることがある チームでそろえる設定は、置き場所で配り方が変わる。 steering・skills は作業フォルダごと共有するか PC に配り、permissions は PC に配るか managed-settings.json に書く 利用者の方には、利用者編を案内してください。管理者の設定で止めている操作があると「許可したのに動かない」と問い合わせが来ることがあるので、何を止めているかを社内で共有しておくと、問い合わせが減ります。

@bakikaradeniz @awscloud Also kindly share, please report problems at github.com/kirodotdev/KiroCrew/issues. Our updates go there, and you get a notice when a fix ships. That goes for everyone reading. If you notice that we reply issues slowly without proper messages, please let us know and we will fix our process.

俺らで作る最強の Kiro Crew。コントリビュートの手順と AI レビューの仕組み はじめに こんにちは、AWS Japan でソリューションアーキテクトをしているいなりくです。 使っている OSS で困りごとを見つけて、直す PR を出してみたいと思ったものの、どの issue なら手を付けてよいのか、大きな変更をいきなり実装してよいのかが分からず、手が止まったことはないでしょうか。 Kiro Crew は、ダッシュボードや CLI、Slack などのチャットからエージェントに作業を頼み、定期実行やセッションをまたいだ記憶を持たせられる OSS です。GitHub で Apache License 2.0 として公開されていて、外部からの issue と PR を受け付けています。 kirodotdev/KiroCrew 私は 2026 年 10 月に、この Kiro Crew へ修正 PR、機能 PR、設計文書（RFC）の PR を出しました。最初は使っていて見つけた表示の不具合を直すところから始めました。その後、OpenAI の Codex で Computer Use（エージェントがデスクトップのアプリを操作する機能）を使ってみて、エージェントが画面を見ながら何手かまとめて操作する使い勝手が良かったので、同じことを Kiro Crew でもできるようにしたいと考えました。Kiro Crew にも Computer Use はありますが、作りが違うところがあり、その差を埋める PR を出しているところです。 本記事では、リポジトリの CONTRIBUTING.md などに書かれた手順を、そのとき実際に通った順にまとめます。手順で迷ったところや、やり直したところも書きます。手順の細部はリポジトリの文書とスキルにまとまっていて、コーディングエージェントが読んで従えるので、全部を覚える必要はありません。全体の流れをつかむつもりで読んでください。後半では、PR を出したあとに動く Kiro Crew のレビューパイプラインの仕組みを解説し、最後に Codex との差を埋める取り組みの現状を紹介します。 ! 本記事の内容は 2026 年 10 月 26 日時点の main に基づきます。手順やチェックの名前は変わることがあるので、PR を出す前に最新の CONTRIBUTING.md を確認してください。 全体の流れ 図1: Kiro Crew へのコントリビュートの流れ。小さな変更は claim から、設計が要る変更は RFC から始める 分かれ目は issue に付いた tier です。小さな issue は /claim して自分で実装し、設計が要る issue は先に RFC で方向を決めます。どちらの場合も、PR を出した後は CI と AI レビューの指摘に対応しながら、メンテナのレビューを待ちます。 issue を選ぶ 作業は issue から始めます。CONTRIBUTING.md の PR 手順には、すべての PR が tier の付いた issue を本文の独立した行で指すこと、と書かれています。 書き方 意味 Closes #N PR のマージで issue を閉じる Part of #N issue は開いたまま、作業の一部として紐づける issue には、どの部分のコードに関わるかを示す area: ラベル（area: dashboard、area: agents、area: cron など）と、種類を示す bug や enhancement が付いています。触りたい部分の area: で絞り込むと探しやすくなります。 目的の issue がなければ自分で立てます。不具合なら再現手順、バージョン、OS、インストール方法の特徴を書きます。機能の要望なら、設計案より先に「何をしようとして、何に止められたか」を書くよう求められています。そのほうが、要望者が思いつかなかった解き方をメンテナが提案しやすいからです。 tier で、自分で取り組めるかが決まる issue は毎日の triage で tier:T1 から tier:T4 に分類されます。 tier できること T1、T2 /claim して自分で実装できる T3、T4 設計の作業なので claim できない。issue にコメントして参加する 私が最初に出した修正は、Markdown プレビューで /images/... のようなルートからの画像パスが表示されない問題でした。issue は tier:T1 が付き、そのまま修正 PR を出してマージされました。issue を立てたのが 10 月 24 日の 10 時 41 分、PR を出したのが 10 時 56 分、マージされたのが翌 25 日の 13 時 4 分で、PR からマージまでは 1 日ほどでした。 KiroCrew#23631 最初の issue を探す エージェントに「自分で取り組める T1 か T2 の issue を、area: dashboard の中から探して」と頼めば、探すところから任せられます。自分で探すなら、GitHub の issue 検索で次の条件を入れると絞り込めます。 is:issue is:open label:"tier:T1","tier:T2" -label:claimed -label:"claim:outside" -label:parked claimed はメンテナ側の自動修正がすでに進んでいる issue、claim:outside は外部の人が /claim 済みの issue、parked は今の計画に入っていない issue に付くラベルです。ここに area: のラベルを足すと、触りたい部分だけが残ります。 /claim で「自分がやる」と宣言する T1 と T2 の issue は、コメントの 1 行目に /claim と書くと自分の担当になります。担当になると、メンテナ側の自動修正パイプラインがその issue に手を出さなくなります。 コメント 動き /claim 担当者のいない T1、T2 の issue を 7 日間自分の担当にする /claim extend 7 日延ばす（1 回だけ） /unclaim 担当を手放す Closes #N でリンクした PR が開いている間は、担当が続きます。下書き（Draft）の PR でも構いません。 リンクした PR がないと 7 日後に通知が来て、その 3 日後に担当が外れます。 同時に持てる担当は 2 件までです。 返事は毎日 1 回の triage が書くので、届くまで最大 1 日かかります。 私が claim したときは、約 20 分後に KiroCrewCaptain から「11 月 1 日まで自動化はこの issue を稲田さんに任せる」という返事が付きました。 大きな変更は RFC から始める CONTRIBUTING.md と GOVERNANCE.md は、次のような変更を「設計の変更」として、先に RFC を書くよう求めています。 公開しているインターフェースの変更 ほかの部分がそれに合わせて作られることになる変更 後から戻すのが大変な変更 バグ修正は RFC を待たない、とも明記されています。どちらに当たるか分からなければ、issue で聞くよう案内されています。 RFC は、docs/request-for-change/rfc-<topic>.md を 1 つ足すだけの独立した PR として出します。英語で書き、先頭に status や author、確認した時点のコミットなどを持つ front matter を置きます。構成は Summary、Motivation、Goals、Non-goals、Design、Migration plan、Backward compatibility、Security considerations、Alternatives considered、Open questions の順が勧められています。Migration plan は PR 1 本の大きさに分け、テストで確かめられる終了条件を付けます。 status の値は決まっていて、RFC が main に入っても draft のままでは「決まった」ことになりません。 status 意味 draft 提案中。何も作られていない accepted 設計が合意された。まだ作られていない in-progress 実装の PR が開いている partial 一部の段階が main に入った implemented すべての段階が main に入った RFC の中で決め切れない論点は Open questions に並べ、メンテナが答えを書き込んで accepted に変えます。 私が順番を間違えたところ ダッシュボードの Git パネルからブランチを切り替える機能では、最初に順番を間違えました。要望の issue は tier:T3 で、「必要なら RFC で」というコメントが付いていたのに、私は RFC なしで約 70 ファイルの実装 PR を出していました。 その後に手順を読み直し、実装 PR を Draft に戻して RFC を先に出しました。 KiroCrew#23725 RFC にはメンテナから「Hold」のレビューが付き、main とのコンフリクトの解消と、AI の Design Review が付けたメモへの返答を求められました。両方に対応すると、RFC は draft のまま main に入りました。今は Open questions への回答を待っていて、実装は回答が出てから段階ごとの PR に分けて出し直す予定です。設計に時間がかかる変更ほど、先に RFC で合意を取ったほうが、結果として実装の手戻りが少なくなります。 実装して PR を出す worktree で作業する fork したリポジトリで、main から git worktree を切って作業します。メインの clone では作業しないのが決まりです。 git fetch upstream main git worktree add ../kirocrew-wt-my-feature -b feat/my-feature upstream/main コミットの前に通すチェック リポジトリの AGENTS.md に、コミット前に通すチェックがまとまっています。 python3 scripts/check_black_formatting.py && python3 scripts/check_subprocess_encoding.py && isort src/kiro_crew test flake8 src/kiro_crew test && mypy src/kiro_crew python3 scripts/local-gate.py いくつか注意があります。 scripts/local-gate.py は、差分に関係するテストだけを流します。全テストは CI の役割です。 macOS では mypy --platform linux src/kiro_crew で実行します。付けないと、CI で落ちる Linux 向けのエラーを見逃します。 black src/kiro_crew test をそのまま実行すると、整形の例外として登録された多数のファイルまで書き換わります。自分が触ったファイルだけを black --target-version py310 <ファイル> で整形します。 コミットは Conventional Commits で 2 つまで コミットメッセージは <type>: <summary> の形で、type は feat、fix、docs、style、refactor、perf、test、chore、ci、build、revert のどれかです。summary は小文字で始め、72 文字以内に収めます。 1 つの PR は 2 コミットまでです。レビューの指摘は amend か squash で直し、--force-with-lease で push します。 PR を出した後に main が進んで、GitHub の画面に「This branch is out-of-date with the base branch」と出ることがあります。このとき Update branch をそのまま押すと、マージコミットが増えて 2 コミットの上限を超えます。ボタンの横の ▼ から Update with rebase を選ぶか、手元で rebase します。私は一度そのまま押してしまい、rebase して force push し直しました。 PR テンプレートの見出しは全部残す gh pr create --body-file で本文を渡すと、GitHub の PR テンプレートは使われません。.github/PULL_REQUEST_TEMPLATE.md の見出しをすべて残し、冒頭の Goal: の行を埋めた本文を自分で用意します。見出しが欠けていると PR Hygiene のチェックで落ちます。出す前に手元で形式を確かめられます。 out="$(mktemp)"; PR_BODY="$(cat pr-body.md)" GITHUB_OUTPUT="$out" bash .github/scripts/pr-description-check.sh; cat "$out" テンプレートの最初の 3 つの節（Problem / Motivation、Why it matters、Not a goal）は、PR を出した時点で固定され、人に頼まれない限り書き換えません。レビューで範囲外の指摘が来たときは、目的を広げずに返答で答えるか、後回しにします。 Kiro Crew のレビューパイプライン PR を出すと、人のメンテナが読む前に、自動のチェックと複数の AI レビューが順に動きます。全体の詳しい説明は docs/ci/ci-and-reviews.md にあります。ここでは、PR を出す側が知っておくと困らない部分をまとめます。 図2: Kiro Crew のレビューパイプライン。軽いチェックが通ってから、重いテストと AI レビューが進む まず軽いチェック、次に重いテスト 最初に走るのが Fast Gate です。数分で終わる軽いチェックの集まりで、ドキュメントのリンク切れ、コメントの書き方、ハーネス（kiro-cli や Claude Code など、エージェントを動かす実行環境）ごとの扱いの書き方といった、コードを動かさずに分かる規約を確かめます。重いテスト（OS ごとに分割したバックエンドのテスト、フロントエンドのテスト、E2E）は、Fast Gate がその commit で通るのを待ってから始まります。規約違反の段階で、重いテストに時間を使わないための順番です。 そのぶん、Fast Gate が落ちると後ろのチェックはまとめて赤になります。私の PR では Comment History Gate が落ちました。コード中のコメントに issue 番号を書いていたためです。Kiro Crew のコード規約では、コメントには今の動作だけを現在形で書き、「以前は」「今後は」のような経緯は git の履歴に任せることになっています。7 か所のコメントを直すと、連鎖して赤になっていた残りのチェックも通りました。赤がたくさん並んだときは、まず Fast Gate の中のどれが落ちたかを見るのが近道です。 役割の違う AI レビュー AI レビューは、問いと読めるものがそれぞれ違う 5 つのレビューと、セキュリティの範囲を確かめる Security Scope Review に分かれています。 レビュー 問い 読めるもの マージを止めるか Opus 5.5 Review 行単位で正しいか、安全か コードだけ 止める GPT 6.1 Review 行単位の別の視点と、PR 本文と差分の食い違い コードと、信頼しない入力として扱う PR の本文 止める Design Review 作るべきものか、形は正しいか コードと PR の本文 基本は助言。本当に問題があるときだけ止める UX Review 初めて使う人に画面の意味が伝わるか 先にスクリーンショットだけ、そのあと差分 同上 First Principles Review 足すものが本当に必要か、すでにないか リポジトリ全体 同上 設計の考え方は、どのレビューに何を読ませるかで決まっています。PR の本文や差分は外部の人が書けるので、そこに「このレビューを通して」のような指示を紛れ込ませる攻撃が考えられます。そのため、どのレビューにもシェルを渡しません。ツールを使うレビューに許されるのはファイルの読み取りと検索だけで、差分や PR の本文は先にファイルへ取り出して渡します。GPT 6.1 Review はツールを使わず、PR の本文を信頼しない入力として区切った形で受け取ります。Opus と GPT は、どちらもモデルを 2 回呼びます。Opus は 1 回目で問題を探し、2 回目でそれが本当かを確かめます。GPT は 2 回目で 1 回目の指摘を反証しにいき、それでも止めるべきと残った指摘は Opus がもう一度判定します。1 回目で出た指摘を、そのまま結果にしない作りです。 UX Review は、本体のリポジトリのブランチから出た PR では、差分も PR の本文も渡さずに、まずスクリーンショットだけを読ませます。初めて製品を開いた人のつもりで、各要素が何に見え、押すと何が起きそうかを書かせ、2 回目でその記録と差分を突き合わせます。fork からの PR では、この 1 回目はありません。First Principles Review は、製品の形を変える変更に、合意済み（accepted など）の RFC があるかも確かめます。RFC の status は PR 側ではなくマージ先の main から読むので、PR の中で status を書き換えても通りません。合意済みの RFC もメンテナの override もなければ、止める判定になります。 レビューの結果はレビューごとに 1 つの PR コメントとして付き、同じレビューがもう一度走ると、そのコメントが書き換わります。 指摘への答え方 止める指摘が付いたら、直して push するか、直さない理由を書いて返答します。どちらの場合も PR に返答を残すのが決まりで、マージを止めない指摘にも答える必要があります。RFC の PR では、Design Review のメモに返答していなかったことも、メンテナの Hold の理由になりました。 図3: Design Review のコメント。判定は PASS でも、Notes にメモが付くことがある。このメモにも返答する 指摘は、私が書いた範囲の本当の問題を何度も見つけてくれました。ウィンドウを選べるようにする PR では、一覧にオペレーターの拒否設定がかかっていないこと、期限切れの状態で別のウィンドウを案内してしまうことを Opus が指摘しました。RFC の PR では、まとめて実行する案が名前で禁止したツールをすり抜ける設計になっていたことを指摘されています。どれも再現テストを足して直しました。画像の修正 PR では止める指摘が 4 回続き、そのうち 1 回は前の修正で私が持ち込んだ問題でした。 ウィンドウを選べるようにする PR は、直して push するたびに次の指摘が付き、3 回続きました。2 回目には、テストが時計をワーカー全体で差し替えていることを GPT が指摘し、同じ箇所を SAST (Semgrep) のチェックも赤にしていました。3 回目には、Opus と GPT の両方が、モデルに渡す注記のアプリ名に伏せ字の処理がかかっていないことを見つけています。毎回範囲は狭まっていき、指摘の中身もはっきりしていたので、1 つずつ直しました。 一方で、直さなかった指摘もあります。GPT の指摘は、Opus がもう一度「止めるほどの問題か」を判定し、その結果も PR に書かれます。スクロールの扱いについての指摘は 2 回とも重大度が下がっていたので、直さない理由を書いて返答しました。判定の理由がそのまま返答の根拠になります。 図4: GPT 6.1 Review の指摘を Opus 5.5 が判定した部分。F2 は LOW として止めない扱いに下がり、F3 は修正が小さいので止めるのが妥当とされている AI だけでなく、人のレビュアーからもコメントが付きます。RFC の PR には、メンテナではない参加者の方から、設定名を置き換えたときに崩れた文や、索引の行が古いままになっていることの指摘が付きました。AI のレビューと同じように直して、スレッドごとに英語で返答しました。 AI の判定が明らかな誤りのときは、書き込み権限を持つ人が /ai-review override <レビュー名> <commit>: <理由> とコメントすると、その commit に限ってそのレビューを通せます。fork から出している外部の作者には権限がないので、理由を書いたうえでメンテナに頼みます。 fork からの PR fork からの PR には、リポジトリの秘密情報が渡りません。それでも AI レビューを受けられるように、Fast Gate が終わったのをきっかけに、本体の main にあるワークフローが fork の PR をレビューし、同じ名前の結果を付けます。PR 側がレビューの手順を書き換えても、動くのは main の手順です。fork からでも、すべて通れば同じように合格になります。 fork からの PR では、push のたびにメンテナが CI の実行を承認するまで、チェックが動きません。チェックがなかなか始まらないのはそのためで、PR が壊れているわけではありません。直しを小分けに push すると、そのたびに承認を待つことになります。手元で関係するテストとリントを通し、直しは 1 回の push にまとめて出すのがおすすめです。 サンドボックスやコマンドの拒否リスト、秘密情報のマスキングなど、セキュリティに関わる一部のファイルは「sensitive path」として扱われます。fork からの PR がここを触ると、承認があっても通りません。その場合はメンテナが本体のリポジトリのブランチで引き取り、元の作者を Co-authored-by: で記録し、Supersedes #<n> を付けた PR として進めます。触る予定のファイルが sensitive path に当たるかは、.github/scripts/sensitive_change_review.py の一覧で確認できます。 最後に 1 つにまとめて、承認されたらマージ ここまでの結果は PR Readiness という 1 つのチェックにまとめられ、すべて通ると PR に readiness: passed のラベルが付きます。マージの条件は、この PR Readiness と、main に必須のレビューの承認です。AI のレビューが通っただけではマージされず、承認が別に要ります。 私の最初の修正 PR では、readiness: passed が付いたあと、KiroCrewCaptain が承認して自動マージを有効にし、そのままマージされました。承認のコメントには「Tier 1 auto-approve」とあり、コンフリクトがないこと、変更の要求がないこと、セキュリティに関わるパスに触れていないこと、レビューの指摘がないことなど、確かめた条件が並んでいます。T1 の小さな修正は、こうした条件がそろえば早く入ります。 図5: 最初の修正 PR が readiness: passed から承認を経てマージされるまで（GitHub の PR のタイムラインを上から順に 3 か所切り出したもの） AI エージェントと一緒にコントリビュートする 生成 AI やコーディングエージェントは、使ってかまいません。CONTRIBUTING.md の「Using AI Tools」の節には、関わっている人の多くがコーディングエージェントで開発していて、このプロジェクト自体がそうした開発から生まれた、と書かれています。 ! ただし、エージェントに書かせても、PR の作者はあくまで自分です。CONTRIBUTING.md は、PR を出す前に、なぜ動くのかを説明でき、設計を守れて、あとで壊れたときに自分で直せるくらい変更を理解しておくことを求めています。レビュアーに 1 行ずつ説明できないなら、その PR はまだ出す段階ではない、とも書かれています。 そのうえで、エージェントに手伝ってもらう PR がマージされやすくなる点として、次の 3 つが挙がっています。 変更を小さく、1 つのことに絞る 大きな変更は、先に issue で方向を合わせる 送る前に全行を読み、不要な部分を削る 開発の手順そのものは、src/kiro_crew/builtin_skills/kirocrew-dev/ にエージェントが読めるスキルとしてまとまっています。worktree での作業は kirocrew-worktree-dev、PR を出してから CI とレビューに対応するまでは kirocrew-prepare-pr です。エージェントに頼むときは、手順を自分で説明するより、このスキルを読ませるよう案内されています。issue の探し方や切り分け、PR テンプレートの埋め方、コミットの数、CI と AI レビューへの対応といった細部は、エージェントに任せて大丈夫です。任せられないのは、何を作るかを決めることと、出来上がった変更を自分で説明できるようにしておくことの 2 つです。 私は Kiro Crew 自身にこの作業を任せました。実装と PR の作成に加えて、CI と AI レビューを 30 分ごとに確かめる監視ループも Kiro Crew に持たせ、指摘が付いたら直して push し、設計の判断が要るものだけ私に聞くようにしました。それでも、RFC の Open questions のように、メンテナに聞かれたら私が自分の言葉で答える必要がある部分は残ります。そのため RFC の author には inariku, with Kiro Crew と書き、内容は私が説明できる状態にしてから出しました。 英語でのやり取り RFC、PR の本文、レビューへの返答は、どれも英語で書きます。私は英語の下書きをエージェントに書かせ、何を直したか、なぜ直さないかが自分の理解と合っているかを読んで確かめてから投稿しました。返答に書くのは、直した commit、直した内容、足したテストの名前、手元で通したチェックくらいで、長い文章は要りません。英語が得意でなくても、内容を自分で説明できれば十分にやり取りできます。 メンテナとのやり取りは GitHub で MAINTAINERS.md には、プロジェクトについての相談はメンテナに直接連絡せず、GitHub の issue か PR で聞くよう書かれています。同じ疑問を持った次の人が答えを見つけられるようにするためです。PR でメンテナ全員をメンションするのは構わないとされています。GOVERNANCE.md も、変更を受け入れるときも断るときも、その issue や PR の上で理由を書いて決めるとしています。 私は RFC の Open questions への回答を、元の issue でメンテナ 3 人にメンションしてお願いしました。 Codex の Computer Use に近づける はじめにで書いたとおり、私が Computer Use の PR を出し始めたのは、Codex の Computer Use が使いやすかったからです。公開されている資料（OpenAI の Computer Use の API ガイド と Codex のユースケースのページ）と比べると、使い勝手に効く差は画面の見え方と、1 回の呼び出しでできる操作の数でした。 Codex Kiro Crew（2026 年 10 月 26 日時点の main） 画面の見え方 アクセシビリティツリーとスクリーンショット。画像がそのままモデルに渡る アクセシビリティツリー。スクリーンショットはファイルのパスとして渡る 1 回の呼び出しでできる操作 複数。コードを実行する形で、繰り返しや分岐も 1 回で書ける 1 つ Kiro Crew がツリーを主にしているのは、ボタンを番号で指定でき、座標を測らずに確実に押せるからです。この強みは残したまま、画像とまとめての実行を足す設計を RFC #24210 で提案しています。モデルに渡す情報やツールの形が変わるので、実装の前に RFC で合意を取る変更です。これとは別に、同じアプリの複数のウィンドウから操作するものを選べるようにする小さな変更は、issue を claim して #24203 で実装しました。 RFC はまだ合意されていませんが、議論の材料として、スクリーンショットをモデルに渡す部分の試作を Draft PR #24316 で出しました。オペレーターが設定で有効にしたときだけ、computer_get_state の応答にスクリーンショットを画像として添えます。 試作では、モデルが本当に画像を見ているかを確かめました。Preview でランダムな色と形の図形を表示し、ブランチのコードで撮ったスクリーンショットを kiro-cli に渡して、色と形を答えさせました。答えの単語がテキスト側に含まれないことも確かめています。KAS（kiro-cli の v3 エンジンで動くハーネス）では毎回正しい答えが返り、画像を添えないと「NONE」と返りました。v2 エンジンでは、今回の条件では同じ結果を確認できませんでした。そこで試作では、確認できた KAS だけを画像を渡す対象にし、ほかのハーネスは同じ確認を通してから加える形にしています。RFC の記述も、この結果に合わせて直しました。 RFC を追う issue #24212 には、triage で tier:T3 と parked のラベルが付きました。同時に付いたコメントは、「今の計画には入っていないが、ほかの人が見つけられるように開いておく。必要なら 👍 のリアクションを付けてほしい。多く求められているものから見る。設計を提案するなら RFC の手順で」という内容です。この扱いでは、issue は閉じられずに残り、要望の多さを見て優先順位が決まります。設計は RFC の PR で進められるので、私はそのまま RFC の議論を続けています。 出した PR の一覧 2026 年 10 月 26 日 16 時時点で、私が出した PR は次のとおりです。 PR 種類 内容 状態 #23631 fix Markdown プレビューで /images/... の画像が表示されない問題の修正 マージ済み #23725 RFC Git パネルのブランチ切り替え マージ済み（status は draft） #23102 feat ブランチ切り替えの実装 Draft。RFC の決定待ち #24203 feat Computer Use で、アプリのウィンドウを一覧して選べるようにする AI レビューの指摘を直し、再レビュー待ち #24210 RFC Computer Use のスクリーンショットをモデルに渡し、複数の操作を 1 回で実行する 人のレビューの指摘を直し、メンテナの判断待ち #24316 feat #24210 のうち、スクリーンショットをモデルに渡す部分の試作 Draft。RFC の決定待ち #24210 の進み具合は issue #24212 で追っています（tier:T3、parked）。 おわりに Kiro Crew へのコントリビュートは、issue の tier を見るところから始まります。T1、T2 なら /claim して実装し、T3、T4 や公開インターフェースが変わる変更なら RFC で先に設計を合意します。PR を出した後は、Fast Gate と AI レビューの指摘に対応しながらメンテナを待ちます。 手順は細かいですが、ほとんどが CONTRIBUTING.md と AGENTS.md、PR テンプレートに書かれていて、エージェントに読ませればそのとおりに進めてくれます。自分で押さえておくのは、何を作りたいかと、出来上がった変更を自分の言葉で説明できることです。私が手戻りしたのは、どれも書かれていることを読む前に動いた場面でした。エージェントに作業を頼むときは、最初にこの 3 つを読ませてください。 Kiro Crew は外部からの PR を受け付けていて、私のように使ってみて欲しくなった機能を、自分で足していくことができます。ほかのツールで便利だった機能があれば、それが Kiro Crew にあるかを確かめ、なければ issue を立てるか、tier の低い issue を claim するところから始めてみてください。コードを書く時間がなくても、欲しい機能の issue に 👍 のリアクションを付けるだけで、メンテナが優先順位を決める材料になります。大きな機能でも、RFC で設計から相談できます。レビューパイプラインが多くの問題をメンテナより先に見つけてくれるので、初めてでも出しやすいと感じました。 記事の内容に誤りがあれば、コメントで教えてください。

Kiro Crew を Windows にインストールして IAM Identity Center でサインインする はじめに こんにちは！AWS でソリューションアーキテクトをしている町田です。 Kiro Crew は、自分の PC やリモートのマシンで動き続ける、オープンソースの AI エージェントのワークスペースです。セッションをまたいで文脈を覚え、スケジュールしたジョブやバックグラウンドのタスクを、利用者が席を外している間も実行します。私は Slack から Kiro Crew とやり取りすることが非常に多くなりました。 本記事では、Windows に Kiro Crew のデスクトップアプリをインストールし、組織の IAM Identity Center でサインインして、最初のチャットを送るまで を画面つきでまとめます。 ! 個人の見解であり、所属する組織の公式見解ではありません。 本記事の内容は 2026-10-22 時点 の公式ドキュメントと、KiroCrew 0.9.0（Windows 版）の実機の画面に基づきます。Kiro Crew は更新が速いため、最新の公式ドキュメントもあわせて確認してください。 先に結論 ダウンロードは kiro.dev の Crew から。 Windows 版は KiroCrew-Setup.exe（約 560 MB）です インストーラーは既定で「現在のユーザーのみ」にインストールします。 管理者権限（UAC）は不要です 既定のエージェントは Kiro CLI で動くので、サインインが必須です。 デスクトップアプリには Kiro CLI が同梱されていて、初回起動の画面にサインイン用のコマンドが表示されます。インストーラー自体はサインインまでは行いません 組織の SSO（IAM Identity Center）なら --use-device-flow 付きのコマンドを使います。 Start URL とリージョンを入力し、ブラウザでコードを確認して許可します サインイン後は「既存のセットアップのインポート」と「カスタマイズ」を経て、メイン画面が開きます。 どちらもスキップでき、後から変更できます 全体の流れ 手順 やること 画面 1 Kiro Crew をダウンロードする ブラウザ 2 インストーラーを実行する KiroCrew セットアップ 3 Kiro CLI にサインインする Kiro Crew の初回画面、PowerShell、ブラウザ 4 既存のセットアップをインポートする（任意） Kiro Crew 5 外観と自分の役割を設定する（任意） Kiro Crew 6 チャットを送って動作を確認する Kiro Crew 前提 Kiro セットアップ完全ガイド 〜 管理者設定からエンドユーザーの利用開始まで 〜 で事前に IAM Identity Center 作成や Kiro サブスクリプションは作成済み 組織の SSO でサインインする場合は、Kiro のサブスクリプションが割り当てられた IAM Identity Center のユーザーと、次の 2 つの値 IAM Identity Center の Start URL（d-xxxxxxxxxx.awsapps.com の形式） IAM Identity Center の リージョン（本記事では ap-northeast-1） Start URL とリージョンは、Kiro の管理者に確認してください。個人の Builder ID・Google・GitHub でサインインする場合は不要です。 1. Kiro Crew をダウンロードする kiro.dev を開き、Crew の Download Kiro Crew をクリックします。 KiroCrew-Setup.exe（約 560 MB）がダウンロードされます。ダウンロードが終わったら実行します。 ! GitHub の README には、Stable・Insider・Nightly の 3 つのチャネルのダウンロードリンクがあります。特に理由がなければ Stable を選びます。アプリは、インストールしたチャネルのまま自動で更新されます（README > App downloads）。 2. インストーラーを実行する セットアップウィザードが開きます。次へ をクリックします。 インストール先のユーザーを選びます。既定の 現在のユーザーのみにインストールする のまま インストール をクリックします。 選択肢 動き 現在のユーザーのみにインストールする（既定） ユーザーのフォルダにインストールする。管理者権限（UAC）は不要 このコンピューターを使用しているすべてのユーザー用にインストールする Program Files にインストールする。管理者権限が必要 出典：Installing & Testing Kiro Crew on Windows インストールが進みます。 完了画面には、既定の Kiro エージェントには Kiro CLI のインストールと kiro-cli login の実行が必要 と表示されます。KiroCrew を実行 にチェックが入ったまま 完了 をクリックします。 3. Kiro CLI にサインインする Kiro Crew が起動すると、Kiro をセットアップする の画面が開きます。デスクトップアプリに同梱された Kiro CLI はインストール済みなので、残りはサインインだけです。 画面には、サインイン方式ごとに 2 つのコマンドが表示されます。長いパスは、同梱された kiro-cli.exe の場所です。 サインイン方式 コマンドの末尾 個人アカウント（Builder ID・Google・GitHub） login 組織の SSO（IAM Identity Center） login --use-device-flow --license pro 組織の SSO の場合は、下のコマンドの右にあるコピーボタンでコピーし、PowerShell に貼り付けて実行します。パスは環境ごとに違うので、自分の画面に表示されたコマンドをそのまま使います。 powershell.exe -NoProfile -Command "Set-Item Env:KIRO_NO_AUTO_UPDATE 1; & '<インストール先>\KiroCrew\resources\backend-dist\kiro-cli\kiro-cli.exe' login --use-device-flow --license pro" ! 画面の説明にあるとおり、サインインページでは個人用の Builder ID が組織の SSO と並んで表示されます。Builder ID でサインインすると、使えるモデルが少なくなります。 組織で契約している場合は、組織の SSO を選んでください。 Start URL とリージョンを入力する Enter Start URL と表示されたら、IAM Identity Center の Start URL を入力します。 続けて Enter Region にリージョン（本記事では ap-northeast-1）を入力します。ブラウザが開き、ターミナルには確認用のコード（Code: XXXX-XXXX）が表示されます。 ブラウザでサインインして許可する ブラウザで IAM Identity Center のサインイン画面が開きます。ユーザー名を入力して 次へ をクリックします。 パスワードを入力して サインイン をクリックします。MFA を設定している場合は、続けて MFA の画面が出ます。 認証がリクエストされました の画面で、表示されたコードが ターミナルに表示されたコードと一致すること を確認し、確認して続行 をクリックします。一致しない場合や、自分で始めたサインインでない場合は キャンセル します。 Kiro CLI がデータにアクセスすることを許可しますか？ の画面で アクセスを許可 をクリックします。 リクエストが承認されました と表示されたら、ブラウザのタブは閉じて構いません。 ターミナルに Logged in と表示されれば、サインインは完了です。 Kiro Crew の画面に戻り、サインインを再確認 をクリックします。サインインが確認されると、次の画面に進みます。 4. 既存のセットアップをインポートする（任意） Kiro Crew は、同じ PC にある他のエージェントのセットアップを探して、取り込めるものを表示します。取り込める対象は、手順・メモリ・ワークスペース・MCP サーバー・スキル・スケジュール・安全設定です。画面の説明にあるとおり、取り込みはマージのみで、認証情報はそのまま です。 本記事の環境では、Claude Code のセットアップが 51 件見つかりました。取り込むソースにチェックを入れて 続行 をクリックします。取り込まない場合は インポートをスキップ をクリックします。今回は インポートをスキップ をクリックしました。 5. 外観と自分の役割を設定する（任意） 外観を選択 の画面で、モード（System・Light・Dark）と配色テーマを選び、続行 をクリックします。 Kiro について教えてください の画面で、自分の役割と技術的な習熟度を選び、続行 をクリックします。ここで選んだ内容によって、Kiro の説明の仕方（平易な言葉か、技術的な詳細か）が変わります。設定はこの PC に保存され、設定 → チャット からいつでも変更できます。 どちらの画面も、右上の すべてをスキップ で飛ばせます。 6. チャットを送って動作を確認する メイン画面が開きます。下の入力欄にメッセージを入力して送信し、応答が返ってくることを確認します。 入力欄では、次の書き方が使えます（入力欄のプレースホルダーの表示より）。 書き方 用途 /command コマンドを実行する @file ファイルを参照する $skill スキルを呼び出す ! シェルコマンドを実行する 応答の下には、その応答で使ったクレジットと時間が表示されます。左のメニューからは、セッション・スケジュール・アーティファクト・アプリ（発見・ライブラリ・Task Runner）・ターミナル・スマホとの接続・設定を開けます。 つまずきやすい点 インストールしただけではエージェントは動きません。 完了画面の案内どおり、Kiro CLI へのサインインが必要です。初回画面のコマンドを実行した後、サインインを再確認 を押し忘れないようにします コマンドは画面からコピーします。 同梱の kiro-cli.exe のパスは、インストール先やユーザー名で変わります Builder ID と組織の SSO を取り違えない。 サインインページには両方が並びます。組織の契約で使うなら、Start URL を入力する --use-device-flow のコマンドを使います ダウンロード直後に SmartScreen の確認が出ることがあります。 インストーラーは署名されていますが、新しいビルドは SmartScreen の評価が貯まるまで確認が出ることがあります（Windows install guide） アンインストールしてもデータは残ります。 セッション・メモリ・設定がある ~/.kiro/crew は消えません。データも消したい場合は手で削除します（同上） まとめ Kiro Crew の Windows 版は、KiroCrew-Setup.exe を実行するだけでインストールできる。既定は現在のユーザーのみで、管理者権限は不要 既定のエージェントは Kiro CLI で動く。CLI はアプリに同梱されているので、初回画面のコマンドでサインインするだけでよい 組織の SSO は login --use-device-flow --license pro。Start URL とリージョンを入力し、ブラウザでコードを確認して許可する インポートとカスタマイズは任意。後から設定で変えられる

Kiro#7709 なんかメモリリークのエラーが出ているが 解決したくさい？ なんでだ

オープンソースで使えます kirodotdev/KiroCrew #jawsug_tokyo

「court」と出力が実行されないKiroのこのバグ、早く治ってほしいです。 #Kiro Tool calls intermittently fail to execute and are rendered as literal text (prefixed with "course") for long/complex commands #11125 Kiro#11125 t.co