TECH PLAY

ゲーム

イベント

マガジン

技術ブログ

はじめに 私が開発ツールに求めることをZedは満たしていた すぐに開けること コードが追いやすいこと 複数画面を上下左右に開けること ディレクトリがツリーで開けること Git関連機能にアクセスしやすいこと VSCode、Ghostty、Zedを比較する Zedの使用感 Zedの微妙なところ ACP経由のエージェント体験はCLIより遅く感じる ファイルパスクリックで開けない VSCode拡張に依存している人は移行しづらい まとめ はじめに 4月にラクスに入社しました。kazuki kanekoです。 研修を受けつつ、開発環境を立ち上げようとVSCodeをセットアップしていました。 すると、AIエージェント開発課のメンバーから「Zedいいですよ」とおすすめしていただきました。 これが、私がZedを知ったきっかけでした。 今は紆余曲折ありながら、Zedに落ち着いています。 以前はVSCodeを中心に使っていて、困っていたわけではありませんでした。 ただ、Zedを使い始めてから、 「VSCodeの動作って、実はけっこう重かったんだな」 ということに気がつきました。 また、Ghosttyについてもおすすめしていただいていたので、一時期はZedとGhosttyを同時に使っていました。 ただ、今は割とZedだけで完結している状態になってきています。 そこで今回は、VSCode、Ghostty、Zedを使ってきたうえで、なぜ今Zedに落ち着いているのかを書いていきます。 まず、前提としてZedについて整理します。 Zedとは、高速性、コラボレーション、AIとの連携を重視して作られているコードエディタです。 公式サイトでは、Zedは「speed」と「humans and AIとの collaboration」のために作られたミニマルなコードエディタとして説明されています。 macOS、Linux、Windowsで利用でき、Rustで一から書かれていて、複数CPUコアやGPUを活用する設計になっています。 Zedを作っているのは、AtomやTree-sitterに関わってきたチームです。 AtomやElectron、Tree-sitterなどの開発経験の延長線上にあるプロダクトとして、Zedが作られています。 Zedの特徴は、単に「軽いエディタ」というだけではありません。 Rust製で、独自UIフレームワークであるGPUIを使い、GPUを活用するような設計になっています。 Zed 1.0の記事では、AtomのようにWeb技術の上に作るのではなく、GPU上のshaderにデータを渡すような、いわばゲームのような作り方を選んだと説明されています。 ソース: https://zed.dev/ つまりZedは、VSCodeのようなGUIエディタの便利さを持ちつつ、より軽く、より高速に動くことをかなり強く意識して作られたエディタだよ、という感じです。 私が開発ツールに求めることをZedは満たしていた 私が開発ツールに求めるのは、以下の5つ すぐに開けること コードが追いやすいこと 複数画面を上下左右に開けること ディレクトリがツリーで開けること Git関連機能にアクセスしやすいこと 順に説明します。 すぐに開けること まず、すぐに開けることです。 GitHubを見ていて、 「このファイル、エディタでちゃんと見たいな」 と思うことがあります。 そういう時にVSCodeで開くと、体感で5秒から6秒くらいかかることがありました。 もちろん数秒なので、めちゃくちゃ遅いというほどではありません。 ただ、開発中の「ちょっと見たい」場面では、この数秒が地味に気になります。 メモ帳みたいにパッと開いて、すぐ見られたらいいのになと思っていました。 Zedはこの「パッと開ける感じ」がかなり良いです。 エディタを開くまでの心理的な重さが少なくて、ちょっと確認したいときにも気軽に開けます。 この軽さは、毎日使っているとかなり効いてきます。 コードが追いやすいこと 次に、コードが追いやすいことです。 コードを読んでいる時には、いろいろな情報を行き来します。 たとえば、 関数の定義元に移動する 型定義を見る クラスやinterfaceの中身を見る 呼び出し元を確認する ファイルをまたいで処理の流れを追う といったことをよくやります。 このときに、定義元にすぐ移動できたり、型ヒントが見られたり、クラス名などにカーソルを当てたときに関連箇所が薄くマーカーされて見やすかったりすると、かなり助かります。 Zedは、このようなIDEの機能を提供してくれています。VSCodeほど充実してませんが、Ghosttyよりは充実しています。 複数画面を上下左右に開けること 複数画面を上下左右に開けることも重要です。 Ghosttyのようなターミナルは、分割の体験がかなり良いです。 上下左右に画面分割できるので、横3、縦2の6画面みたいな形でも開発できます。 Zedでもエディタを上下左右に分割できます。 そのため、Ghosttyのような画面分割の気持ちよさをZedは提供してくれています。 ディレクトリがツリーで開けること ディレクトリをツリーで開けることも大事です。 私は、ディレクトリ構造を見ながら開発したい派です。 たとえば、 controller service repository domain schema migration test のような構成を見るだけでも、そのプロジェクトがどういう責務分割をしているのかがわかるので、どこを変更すればいいのかなどがわかりやすいです。 ZedにはProject Panelがあり、ディレクトリツリーを見ながら開発できます。 Git関連機能にアクセスしやすいこと Git関連機能にアクセスしやすいことも、自分にとってはかなり重要です。 正直、毎回ターミナルで git status を打ったり、commitをコマンドでやったりするのは少しめんどくさいです。 もちろんCLIでやった方が速い場面もあります。 ただ、変更ファイルを一覧で見たり、diffを確認したり、stageする変更を選んだりする作業は、GUIで見たいことが多いです。 VSCodeのGit Graphみたいな感じで、ブランチや履歴を見たり、変更内容を確認したりできるとかなり楽です。 ZedにはGit PanelやProject Diffがあり、変更ファイルを確認したり、diffを見たり、stage / unstageしたりできます。 日常的なGit操作であれば、かなりZed上で確認できます。 VSCode、Ghostty、Zedを比較する ここで、VSCode、Ghostty、Zedを比較してみます。 ただし、Ghosttyはエディタではなくターミナルエミュレータです。 なので、厳密にはVSCodeやZedと同じ種類のツールではありません。 ここでは、以下の3つの開発スタイルとして比較します。 VSCodeのような全部入りGUIエディタ GhosttyでCLIツールを組み合わせてエディタっぽく使うスタイル Zedのような軽量GUIエディタ 観点 VSCode Ghostty Zed 起動の軽さ 重く感じることがある 軽い 軽い コードジャンプ 強い 工夫が必要 強い ファイルツリー ある 工夫が必要 ある 画面分割 できる かなり強い 強い Git UI かなり強い 工夫が必要 強い AIエージェント 拡張+CLIエージェント CLIエージェント前提 ACP+CLIエージェント 自分の印象 全部入りだけど、不要な機能も多く重い 軽いが、使いこなすのに工夫が必要 軽さと機能のバランスが良い VSCodeでも普通に困らないなと思います。 拡張機能も豊富で、Gitも見やすく、デバッグやリモート開発なども含めると、かなり全部入りの開発環境です。 なので、VSCodeが悪いという話ではありません。 ただ、自分の使い方では、少し重く感じる場面がありました。 Ghostty中心のCLI開発は、軽さと自由度がかなり良いです。 ターミナル分割もしやすく、AIエージェントとの相性が一番いいと思いました。 AIエージェントが作業完了すると通知が飛ぶのがいいですね。 ただ、私の場合は、コードを追うときに 定義ジャンプ、ファイルツリー、Git diffなどを自然に見たい場面が多かったです。 比較すると個人的にはZedは、そのVSCodeとGhosttyの中間かなと思っています。 Zedの使用感 ここからは、実際にZedの画面を開きながら、使用感を共有できればと思います。 Zedを立ち上げると以下のような画面が開きます。 初めは何にもないです。VSCodeは初回から何やらたくさん出てきますよね。 何も無さすぎて、初めは戸惑うのですが、 画面底の帯部分(赤で囲った部分)に配置されているアイコンをクリックすると、ターミナルだったり、ファイルツリーを開くことができます。 VSCodeっぽく使いたい場合は、 ファイル、git関連機能、ターミナル、Copilotみたいな感じで開くとそれっぽく使えます。 やろうと思えば、Ghostty風の配置もできます。 Zedでこの配置をするメリットはあまりないので、それならGhosttyがいいかなとか思いますが、一応できます。 私の配置は以下の様な感じです。 エージェントを並列で使いたいので、ターミナルを3枚、git関連情報を右側で見ながら、ファイルも開きながらという感じで開発しています。 ブログ形式でZedの使用感を伝えるのは、難しいなと思いつつ、画面構成の自由度の高さだったり、Copilot、ファイルツリー、git関連機能など、ほしい機能は最初から入っていて、使いやすそうだなというのが伝われば幸いです! 画像では伝わらないですが、今の画面構成を変更したりする操作がサックサクで動く感じです。 Zedの微妙なところ ここまでZedの良いところを書いてきましたが、もちろん完璧ではありません。 特に、AIエージェントまわりはまだ、CopilotやCLIがいいなと感じることはあります。 ACP経由のエージェント体験はCLIより遅く感じる ZedはACP経由で外部エージェントと連携できます。 これは組み込みのAIエージェント機能に依存しないという点で便利なのですが、自分の体感では、ACP経由のエージェント体験はCLIより少し遅く感じることがあります。 CLIでエージェントを使っていると、入力してすぐ反応が返ってくる感じがあります。 一方で、ZedのACP経由だと、UIを挟むぶんレスポンスの出方が少し遅く感じることがあります。 これは設計上ある程度仕方ないのかもしれません。 ただ、CLIの即応感に慣れていると、ここは少し気になります。 ファイルパスクリックで開けない AIエージェントが生成した文章の中に、 src/foo/bar.ts のようなファイルパスが含まれることがあります。 このとき、そのファイルパスをクリックしてそのままファイルを開けると便利です。 VSCodeだと、このあたりの導線が自然に感じることがあります。 一方で、Zedでは、AIエージェント出力内のファイルパスは、ファイルパスのリンクになっていないので、ただの文字列です。 VSCode拡張に依存している人は移行しづらい これはZedというより、VSCodeから別エディタへ移るとき全般の話でもあります。 VSCodeは拡張機能がかなり強いです。 たとえば、 Git関連 Docker Dev Containers Remote SSH デバッグ 各種言語サポート GitLens Copilot など、エディタというより開発プラットフォームに近いです。 なので、VSCode拡張に強く依存している人が、いきなりZedへ全部移行するのは難しいと思います。 私の場合は、VSCodeのすべてが必要だったわけではありません。 だからZedのバランスが合っていました。 まとめ Zedは完璧なエディタではありません。 VSCodeほど何でも揃っているわけではありません。 GhosttyほどCLI開発体験が良いわけではありません。 ただ、色々なバランスを考えると今の私にはZedがかなり合っているという結論になりました。 軽く開ける。 コードを追いやすい。 ファイルツリーがある。 画面分割できる。 Git機能にアクセスしやすい VSCodeに慣れているが、でも、もう少し軽く使いたいという方 Ghosttyの軽さが好きだが、手軽にコードジャンプやGit UIが使いたい方 Zedいいですよ。
こんにちは!製造業のお客様を中心に技術支援をしているソリューションアーキテクトの伊藤ジャッジです。だんだん梅雨らしい気候になってきましたね。この時期といえば今年も  AWS Summit Japan 2026  です!今年も IoT の展示の出展はもりだくさんで、 こちら のブログに概要を掲載しています。ぜひ遊びに来てください。このブログでは IoT 展示内の ロボットの遠隔テレオペレーションの ブースの展示について紹介します。 背景 2026 年のものづくり白書 には、政府主導の AI ロボティクス戦略がその中にありました。AI で賢くなったロボットが、これまで自動化が難しかった市場を広げる「フィジカル AI 時代」を見据えた戦略の発表となりました。政府主導のロボティクス推進方針が明確になったことはロボットを製造する側にも使う側にも喜ばしいことですが、一方で、AI の学習に必要なデータがなければ、どんなに性能の良いロボットでも、AI を使って期待した動作をしてもらうことができません。また、学習には高品質なデータが必要となります。幸いなことに日本の産業ロボットの製造業における活用は世界でも最高水準です。そのため、産業ロボットの動作データは潤沢に存在します。政府も日本の強みとして、産業用ロボット、部品・素材、高品質な現場データを土台に、「まず社会実装してデータを取り、モデルを改善し、他分野へ横展開」という循環を確立することを勝ち筋として、上述のものづくり白書で提案しています。 データが必要ということは理解できますが、このデータ収集において大きな壁があります。実は、ロボット開発では、センサー・モーター・カメラなど多数のハードウェアを組み合わせる必要があります。しかし今までは、ロボットメーカーごとにインターフェースが異なり、各社それぞれのロボット制御言語を使用してきました。そのため、ロボットを新規導入する際は、あるロボット向けに書いたソフトを別機種に移植することはできず、一から動作、通信制御、またはデータ連携を作り込むことになり、膨大な開発コストがかかっていました。この状態は各種ロボットが連携する将来を見据えたロボットの動作データの収集という観点では、障壁と言えるでしょう。 このサイロ化したロボット開発環境の問題を解決するため、ROS が登場しました。ROS(Robot Operating System)は、上記の課題を解決するオープンソースの共通フレームワークです。標準化された通信の仕組みとツール群を提供し、開発者はハードウェアの違いを意識せずにロボットの機能開発に集中できます。さらに、ROS2 の登場をきっかけに近年では産業用ロボットメーカーも ROS2 のサポートを発表する機会が増えてきました。 デモの内容 デモのタイトルにある「遠隔テレオペレーション」(テレオペ)とは、離れた場所にあるロボットや機械を、人間がリアルタイムに操作する技術です。オペレーターは手元のコントローラーやモニター映像を通じて現場の状況を把握し、ロボットに動作指示を送ります。ロボット側のカメラやセンサーの情報がネットワーク経由でオペレーターに返されることで、あたかも現場にいるかのように作業できます。この技術により危険な環境(災害現場、高所、有害物質のある場所)や、人がすぐに行けない遠隔地での作業を安全に行えています。 このテレオペのデモでは AWS の IoT サービスを利用し、 Web の UI を見ながらゲームコントローラーを操作することで、クラウド経由でロボットを操作します。 このデモで利用している実機のロボットは、世界中の生産現場でも利用されているセイコーエプソン株式会社製の高速・高精度な垂直多関節(6軸)ロボット( CX4-A601S )を利用しています。セイコーエプソン株式会社では自社のロボットに対応した ROS2 パッケージ を公開しており、デモでは ROS2 経由で操作しています。 このデモでは同時にデジタルツインとしての Amazon EC2 上で実行されている NVIDIA Isaac SIM にも情報が送られるため、カメラの映像だけではなく、シミュレーション環境上でもロボットの動作を確認することができます。 セイコーエプソン株式会社の ROS2 パッケージ では実機を利用せず、Rviz (3D 可視化ツール)で動かすモードも用意されているため、シミュレーション環境の中だけで動かすこともできます。それゆえ、ロボットの操作に不慣れな人でも安心して操作することが可能です。 このデモでは操作時のデータを rosbag 形式 (ROS2 上でやり取りされるメッセージを記録し、後で利用できる) に保存することも可能で、作成された rosbag は記録後にクラウドに保存されます。このデータを使うことで、クラウド上のシミュレーション環境で、同じ様に再現することもできます。また、保存された操作データは、Physical AI で利用される VLA(Vision-Language-Action)モデルの模倣学習データとして活用することができます。 今回のデモの全体の構成は下記となっています。 ぜひ、 6 月 25 日、26 日に幕張メッセで開催される AWS Summit に来場いただき、実際にご自身の手でコントローラーを操作 し、Physical AI の時代に必須となるロボット動作データ生成と収集を体験しに来てください! デモは AWS Expo の AWS for Industries Zone に展示しています。 伊藤ジャッジ向子 (Ito, Judge Sakiko) 米国での開発者経験を経て、AWSのサポートに入社し、異動しエンタープライズ事業本部でソリューションアーキテクトとして製造業のお客様をご支援しています。趣味は山登り、クラッシックバレエと愛犬のお世話です。 Muhammad Fikko Fadjrimiratno(ふぃっこ) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 不動産・建設業界のお客様を中心に、AWS 利用をご支援しているソリューションアーキテクトです。好きな領域はロボットとIoTと機械学習であり、最近はロボット分野での生成AIの活用にチャレンジしています。趣味はフライトシミュレーター、冬はスノーボードです。 市川 純 プロトタイピングソリューションアーキテクト AWS では IoT に関連するプロトタイピングを支援する、ソリューション アーキテクトとして、お客様の IoT 関連案件を支援しています。
  みなさんこんにちは! 猫や犬に癒されるより AI bou (相棒) に助けられる日々を送る Solutions Architect の高野です。一昨年、昨年と AWS Summit Japan でご好評いただいた Chaos Kitty が、今年はさらにパワーアップした「対戦モード」を引っさげて 4 回目の登場です!   この記事では、2026 年の AWS Summit Japan の AWS Builders’ Fair で展示される「人間 vs AI 障害対応バトル – Chaos Kitty Challenge」についてご紹介します。今年のテーマは、システム運用保守業務における AI Agent の活用による効率化です。参加者と AI エージェントが同じ障害に同時に挑み、対戦を通じて AI Agent がインシデント対応をどのように効率化するかを体感できる体験型コンテンツとなっています。   AWS Summit Japan 2026 の開催期間は 2026 年 6 月 25 日 (水) と 26 日 (木) の 2 日間で、会場は幕張メッセになります。 本展示は両日ともご体験いただけます。 まだ AWS Summit Japan 2026 に登録してない方は こちらのページ からご登録ください。Chaos Kitty は、AWS Expo の AWS Builders’ Fair の中にあります。 Chaos Kitty とは?   Chaos Kitty は、AWS のアーキテクチャを物理的に表現し、インシデント対応の体験学習ができるソリューションです。Web 3 層アプリケーションに異常を注入し、異常を修正するまでのタイムを競うことで、ゲーム感覚でインシデント対応を学ぶことができます。   2023 年の初登場 以来、 2024 年 、 2025 年 と 3 年連続で AWS Summit Japan に登場し、毎年パワーアップを重ねてきました。昨年は IoT 機器なしで利用可能な Web アプリケーション化や、 AWS Cloud Development Kit (AWS CDK) による Infrastructure as Code (IaC) 化を実施し、 AWS Samples として公開 しています。どなたでもご自身の AWS 環境にデプロイしてお試しいただけます。また、Amazon CloudWatch ダッシュボードや Amazon CloudWatch Application Signals を活用したモニタリングも組み込まれており、インシデント発生時の状況把握を体験いただけます。 新機能紹介: 対戦モード   4 回目となる今回は、 システム運用保守における AI Agent 活用 をテーマに、対戦モードを新たに追加しました。AI Agent がインシデント対応をどのように効率化するかを楽しみながら体感いただけるよう、参加者と AI が同じ障害に同時に挑むゲーム形式にしています。 図 1 : AWS Summit Tokyo 2026 版 Chaos Kitty 外観 図 2 : 障害注入対象の Web 3 層アプリケーション画面 対戦モードの概要   同じ障害が発生した 2 つの環境で、参加者と AI エージェントが同時に対応を開始します。人間の直感と経験 vs AI の分析力と速度 — リアルタイムで両者の対応プロセスが可視化され、どちらが早く正確に障害を解決できるかを競います。AI 時代のインシデント対応の未来を、対戦を通じて体感できるモードです。   日々システムを運用されている皆様であれば、障害発生時にログを追い、メトリクスを確認し、構成変更を洗い出し、根本原因を突き止めるまでの緊張感と難しさをよくご存知かと思います。その一連のプロセスを、AI Agent はどれほどの速さでこなすのか。そして、あなたは AI Agent に勝てるのか。今年は従来の Easy モード、Hard モードに加えて、上級者向けの Extreme モードも追加しています。長年の経験と勘で培ったインシデント対応力を、ぜひ AI にぶつけてみてください。勝っても負けても、AI 時代のシステム運用のあり方を肌で感じていただけるはずです。腕に自信のある方、お待ちしております! 図 3 : 対戦モード初期画面 図 4 : ゲーム中画面 図 5 : 勝敗確定画面 (AI WIN) 図 6 : 結果画面 インシデント調査・分析用 AI Agent に AWS DevOps Agent を採用   対戦モードで参加者と競う AI Agent には、 AWS DevOps Agent を採用しています。   AWS DevOps Agent は、インシデント対応を自動化するフルマネージドサービスです。インシデントが発生すると、Amazon CloudWatch のメトリクス、ログ、トレース、さらにはデプロイ履歴や API 変更履歴など、複数のデータソースを横断的に分析し、根本原因の特定から修復アクションの提案までを自動で行います。人間のオンコールエンジニアが手動で相関分析に費やしていた時間を、数分レベルに短縮できるのが特徴です。   AWS DevOps Agent は API 経由で調査タスクの開始や状態取得ができるため、今回の Chaos Kitty ではアプリケーションから API を呼び出し、対戦モードの画面上に AI Agent の調査プロセスをリアルタイムで表示しています。参加者は、自分が手動で調査を進める横で、AI Agent がどのような手順で原因を特定していくかを目の前で確認できます。   また、AWS DevOps Agent が標準で提供する Web 画面 (DevOps Agent Space) もブースでご覧いただけます。実際の運用で AWS DevOps Agent をどのように活用できるかのイメージを掴んでいただけると思います。 図 7 : AWS DevOps Agent Space の画面 体験を通じて学べること   この対戦モードを通じて、以下のことを体感いただけます。 1. AI Agent がどのようにインシデントを調査・分析するか — AWS DevOps Agent の動作を目の前で確認できます 2. AIOps による迅速化の効果 — 手動対応と AI 支援対応の所要時間の差を実体験で理解できます 3. AI Agent を活用したインシデント対応の実践イメージ — 日々のシステム運用にどう活かせるかのヒントを得られます さいごに   今年の Chaos Kitty は、システム運用保守における AI Agent 活用をテーマに、対戦モードを通じてその効果を楽しみながら体感いただける内容になっています。AI Agent がインシデントをどのように調査・分析するのか、そして日々の運用業務にどう活かせるのか、ぜひブースで実際に体験してみてください。   AI に勝てた方も、負けてしまった方も、AI 時代のシステム運用のあり方について新たな気づきを持ち帰っていただければ幸いです。AWS Summit Japan 2026 の AWS Builders’ Fair で、皆様のご来場をお待ちしております! アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクト 高野 翔史 Chaos Kitty は AWS Japan ソリューションアーキテクトの服部 一成、堀 貴裕、佐々 拓也、津郷 光明、河角 修、黒木 琢央、高野 翔史が中心となって開発しております。

動画

書籍