ゲーム
イベント
マガジン
技術ブログ
本記事は「 Kiro CLI 2.0: a new look and feel, headless CI/CD pipelines, and Windows support 」を翻訳したものです。 ターミナルで作業する開発者にとって、ワークフローに合ったツールが必要です。その逆ではありません。だからこそ私たちは Kiro CLI を開発しました。Kiro CLI は、そのまま使えるエージェント型ターミナルで、高品質なコードをより速くリリースできます。ローンチ以来、皆さんから素晴らしい反響をいただきました。気に入った点、改善が必要な点、そして足りない機能について教えていただきました。 私たちはその声に耳を傾け、本日、皆さんからリクエストの多かった 3 つの大きな機能をリリースしました。 ヘッドレスモード : CI/CD パイプラインなどで Kiro CLI をプログラム的に実行し、リリースをより速く行えます。 Windows サポート : お気に入りの Kiro エージェントを、Windows でネイティブに使用できます。 UX リフレッシュ、GA として正式リリース : 摩擦を減らし、より多くのコントロールを提供します。 ヘッドレスモードでデプロイメントをエンドツーエンドで自動化 開発者にはコーディング時の柔軟性が必要です。ターミナルで Kiro CLI を実行するのは簡単で、 kiro-cli と入力するだけです。しかし、自分がいない場所でリモート実行したい場合はどうでしょうか？ ヘッドレスモードがそれを変えます。API キーを生成し、環境変数として設定するだけで、Kiro CLI をプログラム的に実行できます。入力をパイプで渡し、出力をスクリプト化し、Kiro を CI/CD パイプライン、ビルドスクリプト、またはあらゆる自動化ワークフローに直接統合できます。インタラクティブセッションで利用できるすべてのツール、エージェント、機能に、プログラムからアクセスできます。プルリクエストの生成と公開や、トラブルシューティングワークフローの実行など、ローカルでのユーザー入力なしにプロンプトを実行でき、真の自動化を実現します。これにより、デプロイメントを継続的に監視するのではなく、イノベーションに集中できます。 ヘッドレス CLI の具体的な使用例を紹介するブログ記事 もご覧ください。 Windows サポート：あなたの作業環境に合わせて これは個人的にも思い入れがあります。Windows ユーザーとして、ネイティブサポートがなく WSL などの回避策を使わなければならないフラストレーションを理解しています。しかし、もうその必要はありません。Kiro CLI のネイティブ Windows インストーラーが利用可能になったことを、とても嬉しく思います。これにより、Kiro CLI へのアクセスが大きく広がります。 Windows Terminal アプリ内で Kiro エージェントを使用して、複雑なコードベースで機能を構築し、ワークフローを数秒で自動化し、エラーの分析やバグの追跡を正確に行えます。 CLI をインストール して始めましょう： macOS、Linux、または Windows でインストール curl -fsSL https://cli.kiro.dev/install | bash UX リフレッシュ：摩擦を減らし、コントロールを強化 3 月に新しい TUI を実験的にローンチして以来、多くの素晴らしいフィードバックをいただきました。当時はクラシック UX の機能をすべてカバーできていませんでしたが、早期のフィードバックを求めたところ、皆さんが応えてくれました。気に入った点、足りない点、さらに見たい機能を指摘していただきました。それ以降、新しいサブエージェント体験とその進捗を監視する方法、そして新しいタスクリスト（todo リストの強化・更新版）をリリースし、エージェントの動作を簡単に追跡できるようにしました。また、多くの細かい問題も修正しました。 新しいサブエージェント体験とタスクリストの実際の動作を見てみましょう。この例では、サブエージェントを使ってスネークゲームを構築しています。サブエージェントは、親エージェントのコンテキストを保護しながら作業を並列化するためによく使用されます。 サブエージェントのアクティビティを監視するには、 ctrl+g を使用します。各サブエージェントの完全なトレースを確認しながら、すべてのサブエージェントのステータスも確認できます。この場合、デザイナー → 実装者 → レビュアーのフローを順番に実行しているのがわかります。以下はデザイナーが作業中の様子です。 そして、こちらはレビュアーが権限の昇格を要求している様子です。権限の承認は、エージェントモニター（黄色でハイライト表示）とメインオーケストレーター画面の両方で確認できます。 エージェントが作業を進めると、各ステップが完了するたびにタスクリストがリアルタイムで更新されます。この例では明示的にタスクリストの使用を指示しましたが、エージェントは大きなタスクではデフォルトでタスクリストを使用します。 以上のように、Kiro は新しいサブエージェント体験と新しいタスクリスト体験の両方を使ってスネークゲームを構築しました。ぜひ試してみて、サブエージェントとタスクリストがどのように機能するか確認してください。ユースケースが複雑になるほど、タスクリストの価値を実感できるでしょう。Kiro が何を達成したかをすぐに把握できます。 おわりに CLI 2.0 と TUI がデフォルトの体験になりました。何か違和感があれば、 /feedback でお知らせください。皆さんのフィードバックが上記のすべてを形作り、次に来るものも形作ります。また、以前の体験に戻したい場合は、 kiro-cli --classic を実行するだけです。詳細については、 ドキュメント をご確認いただき、 Discord の Kiro コミュニティ に参加して、他のビルダーとつながり、ベストプラクティスを共有し、テクニカルサポートを受け、最新機能の情報を入手してください。コミュニティが皆さんの成功をサポートします。
Webサービスやアプリの開発現場で、「ここにハンバーガーメニューを置こう」といった会話を耳にしたことはないでしょうか。 「ハンバーガー」「ミートボール」「ケバブ」「ワッフル」「弁当箱」。おいしそうなランチのような名前が並んでいますが、これらは今のUIデザインに欠かせない「メニューアイコン」の俗称です。 スマートフォンの狭い画面にパソコンに準じた多くの情報を盛り込むために、これらのアイコンは「要素を隠すための魔法の箱」として多用されています。しかし、これらは便利であると同時に、使い方を間違えるとプロダクトの使い勝手を下げる「劇薬」でもあります。 今回は、それぞれのアイコンの暗黙的ルールと、メニューを隠すことの代償について紐解いていきます。 4つのメニューアイコンと意味 これらのアイコンは、どれも「クリック（タップ）すると何かメニューが開く」という点では同じですが、使われる文脈が異なります。 1. 三本線 名称、呼称: menu、ハンバーガーメニュー、… 役割: グローバルナビゲーション（アプリケーション全体に関わる主要なメニュー） 配置: 主に画面の左上（または右上） どの画面にいてもアクセスできる、プロダクトの根幹となるナビゲーションを隠すために使われます。 アイコンが三本線ではなく、二本線や、四本線の場合もあります。同様の役割で、三本線ではなくサイドバーを表すアイコンが配置されている場合もあります。 例: Google Material Designサイト 例: Anthropic Claude （Web） 2. 横の三点リーダー 名称、呼称: ellipsis horizon、more horizon、overflow menu、水平の三点リーダー、ミートボールメニュー、… 役割: 画面全体や、要素に対する追加のアクション 配置: 画面の右上や、要素の末尾など 文章の最後の「……（続く、省略されている）」と意味合いも形状も同じで、「この行（アイテム）に対して、編集・削除・共有などの操作」（コンテキストメニュー）や、「この画面に関するその他の操作」を示します。 「削除」操作は、誤操作を防ぐために、あえてコンテキストメニューに入れて隠す場合もあります。 例: OpenAI ChatGPT（Web） 例: Apple iOS Safari（Webブラウザー） 3. 縦の三点リーダー 名称、呼称: ellipsis vertical、more vertical、overflow menu、垂直の三点リーダー、ケバブメニュー、… 役割: 「横の三点リーダー」と同様 配置: 「横の三点リーダー」と同様 「縦」に並んだ点が、展開するアクションメニュー（メニューリスト）を想像させる形状です。 Googleのプロダクトにて標準的に利用されています。 「横の三点リーダー」と「縦の三点リーダー」は同様の役割で、同じサービス内で共存、使い分けるケースは少ないです。 例: Google Gemini（Web） 例: Google Chrome（Webブラウザー） 4. 九つの点 名称、呼称: Apps、launcher、launchpad、ワッフルメニュー、弁当箱メニュー、… 役割: 別のアプリケーションや、独立したモジュールへの切り替え 配置: 画面の左上、右上など ハンバーガーメニューがアプリケーション内のグローバルメニューなのに対して、ワッフルメニューは、現在のアプリケーション以外に切り替える（起動する）メニューに使われます。 現在のコンテキストを離れ、全く別の機能群にジャンプするための「ハブ」として機能します。 例: Microsoft 365（Web） 現時点では、これらの「暗黙のルール」が主流となっており、メニューアイコンを選ぶ際には、これらを踏まえるのがユーザーのためにも無難です。 メニューを隠すことの代償 これらのアイコンを使えば、どんなに複雑な機能でも小さなボタンの中に押し込むことができます。画面はスッキリと美しくなり、一見するとデザインが洗練されたように感じます。 しかし、UIデザインにおいて 「隠す」ことには代償 が伴います。 認知心理学の分野やUXデザインにおいては 「発見可能性（Discoverability）」 という言葉が使われます。英語のことわざに “Out of sight, out of mind”（見えなければ、忘れ去られる）とあるように、ユーザーは「画面に見えていない機能」はないものとして扱います。 メニューアイコンの中に機能を隠すということは、以下の2つの認知的負荷をユーザーに強いることになります。 推測の負荷: 「このアイコンを押せば、自分が求めている機能があるはずだ」とユーザー自身に推測させる必要がある。 操作の負荷: 目的の機能にたどり着くまでに、必ず「メニューを開く」という余分な1クリック（タップ）が発生する。 「画面をスッキリさせたい」という開発者側の都合で作られたハンバーガーメニューの奥底に、プロダクトにとって重要な機能（リンク）を隠してしまった結果、ユーザビリティや、ビジネス的な成果の悪化を招くこともあります。 見えるメニューも試す 「隠すことの代償」を軽減する具体策としては、例えばモバイルアプリでは、ボトムナビゲーション（タブバー）（見えるメニュー）に主たる項目を配置しハンバーガーメニュー内（見えないメニュー）にそれ以外の項目を並べることを試すとよいでしょう。 同様に、三点リーダーの場合も何を隠すのか、隠さないのか、よく検討することが大切です。 例: バーガーキング（App） まとめ：アイコンを「ガラクタ箱」にしないために ハンバーガーメニュー、三点リーダーメニュー。これらは限られた画面領域を有効活用するための素晴らしい発明です。しかし、これらを 「画面に収まりきらなかった機能をとりあえず放り込んでおくガラクタ箱」 として使ってはいけません。モバイル用、デスクトップ用ともに。 UIを設計する際、アイコンで隠す前に、まず 「情報設計（IA：Information Architecture）」 から見直す必要があります。 メニューアイコンは「デザインの魔法」ではなく、単に「整理のための引き出し」と捉えたほうがよいでしょう。内容、役割、頻度、数、ラベルなど、項目を論理的に整理することが、使いやすいプロダクトを生み出すための第一歩となります。 余談：「食べ物の呼び名（スラング）」の歴史 「三本線」や「横の三点リーダー」のアイコン自体は古くからありましたが、それらが「食べ物の名前」で呼ばれるようになったのは、スマートフォンが普及して画面の省略化が進んだ2010年代以降のことです。デザイナーたちの「連想ゲーム」で以下のように名付けられていったようです。 ハンバーガー iPhoneの登場後、Facebookなどの人気アプリが画面領域を節約するために「三本線」のアイコンでメニューを隠すUIを採用しました。この時、アイコンが爆発的に普及し、デザイナーや開発者の間で「ハンバーガー」と呼ばれ始め、UIデザインにおける最初にして最大の食べ物スラングとして定着しました。 ワッフル / 弁当箱 Googleが「9つの点」のランチャーを大々的に導入。すでに「ハンバーガー」という食べ物スラングが定着していた界隈で、「じゃあ、あの四角い格子状のやつはワッフルだ」「いや、おかずが詰まったBento Box（弁当箱）だ」と呼ばれるように。 ケバブ AndroidのMaterial Designにて標準化された「縦の3つの点」。「ハンバーガーがあるなら、肉が縦に並んでいるのは『ケバブ』だろう」というジョークが生まれました。 ミートボール ケバブ（縦）という呼び名に対して、昔から使われていた「横の3つの点」を呼び分ける必要が出てきました。「縦が串焼き（ケバブ）なら、お皿に横に転がっている肉団子だから『ミートボール』にしよう」という、後追いの連想ゲーム。 … UI界隈でも、どこまでこれらの俗称が通じるかは不明ですが …。 Photo by Jean-claude Attipoe , Olivier Amyot , Victoria Shes , Najmah Faisal on Unsplash ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 1人がこの投稿は役に立ったと言っています。 The post 「隠すUI」の功罪：それ、ハンバーガーで大丈夫？ first appeared on SIOS Tech Lab .
