デザインのための Kiro CLI。
Kiro CLI は仕様駆動開発のための Amazon のターミナルエージェントです。プロンプトを、コードを書く前に要件仕様・設計ドキュメント・タスクリストへと変えます。その構造こそデザイン作業が必要とするもの — まず意図、それから構築。Open Design はこれをオープンソースのデザインワークフローに組み込みます。自分の Builder ID やサインイン、自分のファイル、ローカルファーストで。
Open Design は Kiro CLI をローカルファースト・オープンソースのデザインエージェントに変えます。自分の AWS Builder ID やサインイン、自分のファイル、そして厳選されたスキルとデザインシステムのライブラリをまわりに備えます。
Kiro CLI は仕様駆動開発のための Amazon のターミナルエージェントです。際立つのはそのワークフローです。プロンプトからいきなりコードへ飛ぶのではなく、Kiro は要件を仕様に形式化し、設計ドキュメントと順序付けされたタスクリストを生成し、それからようやく実装します。こうしてビルドを述べられた意図に対して責任あるものに保ちます。さらに、ファイル保存のようなイベントで発火するエージェントフック、あなたの基準と規約を毎回の実行に運ぶステアリングファイル、外部ツールのための Model Context Protocol 対応も備えます。Kiro はプレビュー中で、IDE・CLI・Web インターフェースとして利用でき、無料で始められます。本稿は、Kiro CLI を UI・フロントエンド・デザインシステムの作業に使い、Open Design で構造化されたデザインワークフローに組み込むための、実践的でエンドツーエンドのガイドです。
Kiro CLI とは実際に何か、なぜ仕様駆動のワークフローがデザインに適しているか、ゼロからのセットアップ方法、スクリーンショットから UI への流れ、ステアリング・フック・MCP による拡張、Codex・Claude Code・Cursor・Gemini CLI との比較、AI 出力が無個性に見える落とし穴、そして Open Design がそのまわりでオープンでローカルファーストなデザインレイヤーとしてどうそのギャップを埋めるかを扱います。
Kiro CLI とは実際に何か
Kiro は Amazon のエージェント的 AI で、IDE・コマンドラインインターフェース・Web インターフェースとして提供され、仕様駆動開発によってプロトタイプから本番へと導くよう作られています。Kiro CLI はそのエージェントをターミナルに持ち込みます。対話的なチャットセッションを開始し、エージェントを作成・管理し、Model Context Protocol サーバを実行することが、すべてコマンドラインからできます。Kiro はプレビュー中です。
デザイン作業で決定的な性質はそのワークフローです。プロンプトをいきなりコードに変えるのではなく、Kiro はまず仕様 — 要件、設計ドキュメント、順序付けされたタスクリスト — を書き、それに対して実装します。これにより、いかなる UI も作られる前にエージェントの計画が可視化されレビュー可能になります。これはデザイン判断のなされ方 — まず意図、それから実行 — にきれいに対応します。
- 仕様: Kiro はコードを書く前にプロンプトを構造化された仕様 — 要件、設計ドキュメント、個別タスク — に変えるので、計画を最初にレビューできます。
- ステアリング + フック: ステアリングファイルはあなたの基準・規約・推奨ツールを毎回の実行に運びます。エージェントフックはファイル保存のようなイベントで発火し、バックグラウンドタスクを自動で実行します。
- 無料で開始、MCP 対応: Builder ID、Google、GitHub、または組織でサインインして無料で始められます。Kiro CLI は外部コンテキストを取り込む MCP サーバも管理します。
- ベンダー:Amazon(AWS)
- 認証情報:AWS Builder ID、Google、GitHub、または AWS IAM Identity Center を kiro-cli login 経由で(AWS アカウントは不要)
- ステータス:プレビュー中。IDE・CLI・Web インターフェースとして利用可能
なぜ仕様駆動開発がデザインに適するのか
Kiro CLI のデザイン上の強みはそのワークフローから来ます。ただし、どのエージェントも同じく、センスは人が与える必要があります。
- ピクセルより先に意図: Kiro はまず仕様と設計ドキュメントを書くので、エージェントが無個性な実装に踏み込む前に、計画段階でレイアウト・階層・スコープを正せます。
- ステアリングがブランドを運ぶ: ステアリングファイルはあなたのトークン・コンポーネント・規約を毎回の実行でエージェントの目の前に保つので、出力は既定の見た目ではなくブランドに沿って作業します。
- フックがループを強制する: エージェントフックは保存時に自動でチェックを実行できます。エージェントが覚えているのに頼るのではなく、検証やレビューの手順を組み込む場です。
教訓はどのエージェントも教えてくれるものと同じです。Kiro CLI は既定でセンスを持ちません。仕様はビルドを誠実に保ちますが、良いデザインを生むのは制約 — デザインシステム、美的スキル、具体的な参照 — を与えたときだけです。Open Design はまさにそれらの入力をパッケージ化します。だからこそ両者は噛み合います(詳細は後述)。
デザイン作業向けに Kiro CLI をゼロからセットアップする
まっさらなマシンから、UI を構築・検証できる Kiro CLI までの全行程を示します。
# 1. Install Kiro CLI (see kiro.dev/docs/cli for the macOS/Linux/Windows command)
# 2. Authenticate — opens your browser to complete sign-in
kiro-cli login # choose Builder ID, Google, GitHub, or your organization
# 3. Confirm you are signed in
kiro-cli whoami
# 4. Start an interactive session in your project
cd your-project
kiro-cli chat
# 5. Wire MCP servers (optional, e.g. for design handoff)
kiro-cli mcp add ...
- デザインルールを記述する: トークン・プリミティブ・規約をステアリングファイルに入れ、エージェントが毎回の実行で読むようにします。すると出力は無個性な見た目に流れず、ブランドに合致します。
- ブラウザ検証を加える: Playwright かブラウザ MCP サーバを接続し、Kiro に実際のブラウザで描画させ各ブレークポイントで出力を点検させます。ビルドが通ったことだけを確認するのではなく。
スクリーンショットから UI へのワークフロー
Kiro CLI で最も効果の高いデザインループは、参照画像を動作するレスポンシブな UI に変え、一致するまで反復することです。まず仕様に意図を捕捉させ、それに対して構築します。
- 手持ちで最も明瞭な視覚的参照から始め、ヒーロー画像 1 枚だけでなく複数の状態(デスクトップとモバイル、ホバー、空、ロード中)を含めます。
- Kiro にあなたのプロンプトから仕様と設計ドキュメントを書かせ、構築前に計画をレビューします。ここがレイアウトとスコープの問題を早期に捕まえる場所です。
- デザインシステムと規約をステアリングファイルに保ち、トークンと正規のプリミティブの場所を Kiro に伝えます。
- 開発サーバを起動し、Kiro に実際のブラウザで描画させ、ブレークポイントまでリサイズして結果を確認します。
- 単にビルドが通ることを確認するのではなく、実装を参照と照らし合わせて Kiro に反復させます。
対話セッションを開き、書かれる仕様があなたの本当の意図を反映するよう、最初に具体的な制約を与えます:
kiro-cli chat
# in the prompt:
> Here are my references: reference-desktop.png and reference-mobile.png.
Write a spec, then implement this design in React + Vite + Tailwind + TypeScript.
Reuse my existing design-system components and tokens (see my steering files).
Match spacing, layout, and hierarchy; make it responsive.
Render it in the browser and iterate until it matches the references
across breakpoints.タスクは小さく焦点を絞り、良い反復はコミットし、悪い反復は元に戻します(戻したときは Kiro に伝えます)。こうして各パスがクリーンな土台の上に積み重なります。
仕様・ステアリング・フック・MCP
四つの拡張点が Kiro CLI を継続的なデザイン作業に実用的にし、いずれもオープンなデザインワークフローにきれいに対応します。
- 仕様: 要件、設計ドキュメント、順序付けされたタスクリスト — ある機能がどうあるべきかの耐久性ある記録で、ビルドの前と最中にレビューできます。
- ステアリングファイル: エージェントが毎回の実行で読むコンテキスト、コーディング基準、推奨ワークフローやツールを追加します。デザイン規約とトークンの自然な置き場です。
- エージェントフック: ファイル保存のようなイベントで発火し、チェックやドキュメントといったバックグラウンドタスクを実行する自動化 — 検証手順を自動で強制する場です。
- MCP サーバ: Kiro CLI は Model Context Protocol サーバを管理します。外部のデザインコンテキストやツールを取り込む可搬な方法で、Kiro だけでなく複数のエージェントで機能します。
これらは可搬でマルチエージェントな機能であり、プロジェクトごとに作り直すのではなく、まさに Open Design がオーケストレーションするために作られた類のものです。
デザインにおける Kiro 対 Codex 対 Claude Code 対 Cursor 対 Gemini CLI
デザイン作業に唯一の勝者はいません。各エージェントには異なる強みがあり、経験豊富なチームはそれらを重ねて使います。公平にまとめると:
| エージェント | デザイン上の強み | 最適な用途 |
|---|---|---|
| Kiro CLI | 仕様駆動のワークフロー — コードの前に要件・設計ドキュメント・タスクリスト。ステアリングファイルとフックがビルドをブランドに沿わせる | 実装の前に意図とスコープを固める、構造化されレビュー可能なビルド |
| Codex | フロントエンドスキルによる高い視覚的洗練。サンドボックス化された非同期ビルド | 委任型の非同期ビルドと可搬な AGENTS.md ルール |
| Claude Code | 具体的なデザイン判断(hex、余白、書体)とコードベースを理解した UX | フロントエンドの推論と大規模コンテキストのリファクタリング |
| Cursor | ライブプレビューとインライン編集を伴う「作って見る」視覚ループ | IDE 内での密な反復と監視を伴う UI 作業 |
| Gemini CLI | 強力なマルチモーダル画像理解と非常に大きなコンテキスト。無料枠付きのオープンソース | スクリーンショット中心の作業と、デザインシステム全体をコンテキストに保持すること |
コミュニティで繰り返し語られる結論は、センスは人から来るということです。どれもスキル・参照・制約がなければ無個性な美的傾向に流れます。それこそが解くべき本当の問題であり、モデルの形ではなくデザインツールの形をした問題です。
落とし穴と「AI 丸出し」な見た目を避ける方法
AI が生成したデザインへの最も多い不満は、無個性に見えることです。淡いグラデーション、浮遊するパネル、過大に丸めた角、大げさな影、Inter と紫の雰囲気が「AI が作ったと丸わかり」になります。ほかにも、壊れたモバイルレイアウトや指示文が UI コピーに漏れ出すといった問題が報告されています。いずれも Kiro CLI 固有のものではなく、厳選されたデザインコンテキストなしにどのエージェントを走らせても起こることです。仕様はビルドを筋道に沿わせますが、センスは供給しません。
- 美的スキルを加える: 厳選されたデザインスキルは、既定の見た目ではなく本物の方向性へ踏み込むようエージェントに強制します。
- 実際のブラウザで検証する: 各ブレークポイントで描画・自己点検させ — できればフックとして組み込み — モバイルでレイアウトが静かに壊れないようにします。
- トークンと参照を供給する: 本物のデザイントークンと参照スクリーンショットは、出力品質に対する最大の梃子です。
- ルールをステアリングファイルに記述する: 「ヒーローカード禁止、書体は最大 2 種、ブランド優先の階層」のようなルールを、エージェントが毎回読む場所に置きます。
どの対策も、エージェントに厳選されたデザインコンテキストを与えることに帰着する点に注目してください。そのコンテキストをプロジェクトごとに手作業で維持する労苦こそ、Open Design が取り除くものです。
Open Design の中で Kiro CLI を使ってデザインする
Open Design は、上記のワークフローが繰り返し求めるオープンソースのデザインレイヤーです。Kiro CLI をファーストパーティのアダプタとして扱い、厳選されたスキルとデザインシステムのライブラリ、構造化されたレンダリングパイプライン、ローカルのデスクトップ UI で包みます。こうして Kiro を良くするデザインコンテキストが、毎回手作業で組み立てるのではなく初回から備わります。Open Design はローカルファーストなので、組み合わせはシンプルに保たれます。あなたのファイルとサインインはあなたのマシンに留まります。
- Open Design をインストールし、エージェントとして Kiro CLI を選択します。
- 自分の AWS Builder ID やその他のサインインで認証します。認証情報はあなたのマシンに留まり、当方を経由してプロキシされることは決してありません。
- デザインシステムとスキルを選び、一貫したセンスでデッキ・プロトタイプ・ランディングページを生成します。
- すべての成果物と DESIGN.md ファイルは、ホスト型クラウドではなく自分のリポジトリに置かれます。
同じ Kiro CLI エージェント、同じサインイン。そのまわりに本物で可搬なオープンソースのデザインワークフローが加わります。Open Design はローカルファーストで Apache-2.0 なので、作業や認証情報があなたのマシンを離れることはありません。
よくある質問
-
01 Kiro CLI は本当にデザイン作業ができますか?
はい。美的スキル、デザインシステム、本物の参照画像がコンテキストにあれば、Kiro CLI は本番品質のレスポンシブな UI を生み出し、その仕様駆動のワークフローがビルドを述べられた意図に対して責任あるものに保ちます。そのコンテキストがないと無個性な見た目に流れがちで、それこそ Open Design が埋めるギャップです。
-
02 Kiro CLI を使うのに AWS アカウントは必要ですか?
いいえ。Kiro は AWS Builder ID、Google、GitHub、または組織(AWS IAM Identity Center)でサインインでき、使うのに AWS アカウントは不要です。Kiro はプレビュー中で無料で始められます。いずれにせよ Open Design があなたの認証情報をプロキシすることはありません。
-
03 Kiro CLI がとりわけデザインに向いている理由は?
その仕様駆動のワークフローです。Kiro はコードを書く前に要件・設計ドキュメント・タスクリストを書くので、ビルドが固まる前にレイアウトとスコープを正せます。ステアリングファイルがあなたの規約を運び、フックがチェックを強制できますが、センスはあなたが供給するデザインシステム・スキル・参照から来ます。
-
04 フロントエンドのデザインには Kiro CLI と Claude Code のどちらが良いですか?
どちらも強力です。Claude Code は具体的でコードベースを理解したデザイン判断で知られています。Kiro CLI の強みは、ステアリングとフックを伴う仕様駆動でレビュー可能なワークフローです。多くのチームは両方を使います。Open Design ならデザインワークフローを変えずにエージェントを切り替えられます。
-
05 Kiro CLI を外部のデザインツールにどう接続しますか?
Kiro CLI は Model Context Protocol(MCP)サーバを管理します — kiro-cli mcp で追加します。MCP サーバは本物のデザインコンテキストとツールをエージェントに取り込めるので、生成コードは近似ではなくソースに合致します。
-
06 Open Design は Amazon や AWS と提携していますか?
いいえ。Kiro は Amazon(AWS)の製品です。Open Design は独立したオープンソースプロジェクトで、ファーストパーティのアダプタとしてこれをサポートします。Kiro は Amazon の商標です。
-
07 私のファイルと認証情報は安全ですか?
はい。Open Design はローカルファーストで Apache-2.0 です。ファイル・成果物・DESIGN.md は自分のリポジトリに留まり、Kiro のサインインはあなたのエージェントが直接使い、Open Design のサーバを経由することは決してありません。
オープンな流儀で、Kiro CLI とデザインする。
自分の AWS Builder ID やサインインを持ち込み、すべてのファイルをローカルに保ち、すでに使っているエージェントのまわりに厳選されたデザインライブラリを得ましょう。