2026/01/05 22:52

VSCode から Zed に切り替えました。

RSS: https://news.ycombinator.com/rss

要約▶

日本語訳:

Summary:

著者は Visual Studio Code（VS Code）から Zed に永久に切り替えて、Zed を主な統合開発環境（IDE）として使用しています。 VS Code の頻繁な AI 主導の更新や膨大な設定ファイル、時折起こるクラッシュは効率的な作業を維持できないと感じました。一方で Zed は軽量で高速、長時間安定しており、最小限のセットアップで「楽しい」コーディング体験を提供します。著者は JetBrains IDE のような重量級ツールよりもシンプルさを好み、多数の拡張機能に負担をかけずに言語サーバー（例：Python 用 Basedpyright）を設定できる点を重視しています。Zed の AI 機能はオプションで、主に有料プランで利用可能ですが、現在のワークフローはほぼ変わりません。この移行は、パフォーマンスとミニマリズムが重要な開発者や企業が VS Code や大型 IDE の代替として Zed を検討するきっかけになるでしょう。

Summary Skeleton

What the text is mainly trying to say (main message)
著者は、Zed が軽量で高速、安定しており自分のワークフローにより適しているため、VS Code から Zed に永久的に切り替えました。

Evidence / reasoning (why this is said)
VS Code の頻繁な AI 関連更新は機能トグルを常に行い、

settings.json

が膨大になり、バグや遅延、クラッシュが発生します。対照的に Zed は 2 週間連続で安定して動作し、「楽しい」感覚を与え、設定も最小限です。

Related cases / background (context, past events, surrounding info)
著者は JetBrains IDE のような重いツールより軽量エディタ（Zed）を好み、Python や Go 用に Basedpyright、ty などの言語サーバー設定経験があります。VS Code の拡張機能エコシステムは大きいが、自分のニーズには必須ではないと感じています。

What may happen next (future developments / projections written in the text)
Zed の AI 機能はオプションで、編集予測を提供する有料プランがあります。著者は Zed の最小設定を継続し、必要に応じてより良いサイドバイサイド Git 差分ビューアを追加する可能性があります。

What impacts this could have (users / companies / industry)
軽量で安定した IDE を求める開発者は、同様の理由で Zed を採用するかもしれません。企業はパフォーマンスとミニマリズムが優先される場合に、VS Code や JetBrains ツールの代替として Zed を検討する可能性があります。

本文

多年にわたる VSCode の日常的な使用

数年前から、VSCode は私のデイリーペースで使う IDE でした。Python・Go・C、時折フロントエンド開発など、すべてを扱える万能ツールです。完璧ではありませんでしたが、機能してくれました。設定は最小限に抑えつつ主流のツールを使うのが好きなので、まさに自分に合っていました。しかし最近の VSCode の動向により、代替手段を探す必要に迫られたのです。12 月に Zed へ完全移行し、今では戻るつもりはありません。

VSCode はもうない

VSCode は長年安定していたように感じていました。AI の時代になると状況が変わりました。毎回更新で新しい AI 関連機能が追加され、それをどう無効化するか考える必要があります。

GitHub Copilot を使っていません。私の好きな AI ツールは CLI（最近では Codex）です。Copilot は無効にしたのですが、VSCode がそれを強制し続けました。ある更新で「cmd+I で Copilot 続行」と表示され、編集するたびに目に入ってしまいました。
別の更新では、インラインターミナル提案が追加され、私のシェル提案と衝突してしまいました。
他にも似たような侵襲的機能がいくつかあったと思います。

結果として

settings.json

は「オプトアウト」のリストになってしまいました。まだそれで生きていたものの、最大の問題は VSCode がバグを増やし、動作が遅くなり、頻繁にクラッシュすることでした。Copilot 機能の急速な導入が原因であるのは当然です。

VSCode は依然として素晴らしい IDE だと考えており、メンテナやエクステンションコミュニティには感謝しています。AI 統合へのアプローチが侵襲的ではなく、より思慮深くなることを願い、安定化して「ただ動くだけ」になる日を期待しています。しかし今は他の選択肢を探す時期でした。

JetBrains 系 IDE に移行したくないと分かっていました。強力ですが重い感じがし、使うのも好きではありません。Vim・Emacs そのものやモダンな派生系は全く逆側に位置しており、設定を学び直す時間が取れた退職後でないと実際に活用できるとは思えませんでした。そして Zed は「Rust で書かれた現代的で軽量な IDE」というイメージしか持っていませんでした。試してみる価値はあると思い、手を伸ばしました。

Zed：最初の印象

Zed を起動するとすぐに VSCode と同じように感じました。UI は似ており、デフォルトキー配置もほぼ同じです。最大の UX の違いは、VSCode では左サイドバーに開いているファイル（＝エディタ）が表示されるため、よくナビゲーションに使っていた点です。Zed にはそのようなパネルがなく、推奨される方法は

Cmd+P

でファイル検索を行うことです。VSCode の設定を自動的にインポートする機能もありますが、新鮮な状態から始めたかったので使いませんでした。

設定したのは次の3つだけ：

フォントサイズとテーマ
インライン Git blame の無効化
自動保存の有効化

Zed が VSCode より速く、レスポンスが良いことにすぐ気づきました。以前慣れていた他ツールの遅さも改善されているようで、プログラミングの楽しさを取り戻せたと感じます。

主に Python と時折 Go を使っています。Go は Zed でそのまま動作し、追加設定は不要です。一方 Python はスムーズではなく、半日ほど調整が必要でした。以下に詳細を書き留めておきます。

Zed を Python で動かす

Zed は言語サーバーを利用して自動補完・コードナビゲーション・型チェックなどの機能を提供します。Python 用には複数の言語サーバーがネイティブにサポートされています。Pyright が代表的ですが、これは主に型チェッカーであり、他の言語サーバーの基盤となるだけです。Microsoft は Pyright の上に Pylance を構築していますが、Pylance はオープンソースではないため VSCode 以外では使えません。Zed はデフォルトで Basedpyright を使用します。

最初の問題

Python プロジェクトを Zed で開くと、多数の型チェックエラーがハイライトされました。Basedpyright がより厳格な

typeCheckingMode

（推奨モード）で動作していたためです。私のプロジェクトでは、Pyright を設定時に

typeCheckingMode

を指定しない（デフォルトは standard）ようにしていました。Zed のドキュメントには「Basedpyright は単独で推奨モードをデフォルトとしますが、Zed では標準モードを使うように設定されます」とあります。これは混乱させる説明でした。

settings.json

に明示的に

typeCheckingMode: standard

を書いても効果はありませんでした。結局、

pyproject.toml

に

[tool.pyright]

セクションがあると、Basedpyright は自動で推奨モードを使う仕様になっていることが分かりました。解決策としては、各

pyproject.toml

で

typeCheckingMode = "standard"

を明示的に設定する必要があります。この調整には時間がかかり、GitHub の issue で同様の問題が報告されていたため、一時はバグだと誤解していました。現在ではドキュメント上で意図した挙動として理解できるようになりました。

教訓:

[tool.pyright]

を定義する場合、Pyright のデフォルトに頼らずオプションを明示的に設定してください。

リアルタイム診断

コード編集中に新しい型エラーがファイルに表示されるのは遅延がありました。たとえばあるシンボルを削除したけれども別ファイルでまだ参照されている場合、エラーが即座に反映されませんでした。この問題は

settings.json

で

"disablePullDiagnostics": true

を設定することで解決しました。

{
  "lsp": {
    "basedpyright": {
      "initialization_options": {
        "disablePullDiagnostics": true
      }
    }
  }
}

仮想環境の検出やその他 Python 固有の機能はスムーズに動作しました。最近 beta を発表した ty（Basedpyright の代替）を試すこともありましたが、初期状態からうまく動作していました。ただし CI で Pyright が走るため、ローカルでも同じ型チェッカーを使いたいと考えています。

ruff

と

uv

が普及しているので、今後は開発環境・CI 共に ty に移行する可能性が高いです。

まとめ

Zed は現在私の Python・Go 用 IDE の第一選択肢であり、汎用エディタとしても最優先です。高速で安定し、使い慣れた操作感を保ちつつ豊富な機能が揃っています。拡張エコシステムは VSCode に比べ小規模ですが、私のニーズには十分対応できています。唯一欠けているものは、GitLens のようなサイドバイサイド表示の強力な Git 差分ビューアです。

Zed の AI 機能は積極的に開発されていますが、簡単に無視でき、邪魔になりません。編集予測など有料プランも用意されており、プロジェクトを継続させる良い手段だと感じています。Zed の今後の発展を願っています。

VSCode については、十分に競争力のある代替が登場したことで Microsoft の支配的地位は脅かされているようです。VSCode、覚悟を決めましょう！

私の最小

settings.json

（完全版）

{
  "autosave": "on_focus_change",
  "git": {
    "inline_blame": {
      "enabled": false
    }
  },
  "icon_theme": {
    "mode": "light",
    "light": "Zed (Default)",
    "dark": "Zed (Default)"
  },
  "base_keymap": "VSCode",
  "ui_font_size": 22,
  "buffer_font_size": 18,
  "theme": {
    "mode": "light",
    "light": "One Light",
    "dark": "One Dark"
  },
  "lsp": {
    "basedpyright": {
      "initialization_options": {
        "disablePullDiagnostics": true
      },
      "settings": {
        "basedpyright.analysis": {
          // pyproject.toml に `[tool.pyright]` がある場合は無視される
          "typeCheckingMode": "standard"
        }
      }
    }
  },
  "languages": {
    "Python": {
      "language_servers": ["!ty", "basedpyright", "..."]
    }
  }
}

ご質問・コメント・提案があれば、ぜひ GitHub のディスカッションに参加してください。

もっと知りたい方はフォローしてね：
GitHub | Bluesky | Twitter | LinkedIn

Pelican（Python を活用）で制作されたサイトです。テーマは Smashing Magazine に感謝！

同じ日のほかのニュース

一覧に戻る →

2026/01/06 6:05

ベネズエラで停電が起きた際に、BGP に異常が発生しました。

## Japanese Translation: --- ## Summary ロウオービットセキュリティのニュースレターは、ベネズエラが1月2日に停電した際に発生した疑わしいBGP異常を報告しています（Cloudflare Radar のタイムスタンプ 15:40 UTC）。Cloudflare Radar は CANTV (AS 8048) が自身の ASN を **10 回** 前置していることと、BGP 公開が急増し、その後広告される IP 空間が減少した異常なスパイクを示しています。200.74.224.0/20 ブロックから 8 つのプレフィックスが `…52320 8048 …` の経路で Sparkle（イタリア）と GlobeNet（コロンビア）を通じてリークされました。公開 BGP フィード（ris.ripe.net、bgpdump）は異常な AS‑path 構造を確認しており、Sparkle は RPKI フィルタリングが欠如しているため isbgpsafeyet.com で「unsafe」とリストされており、通常のトラフィックにとってルートが魅力的ではありません。 WHOIS データはリークされたプレフィックスがカラカスの Dayco Telecom に属していることを示しています。逆 DNS ルックアップは、これらの範囲が銀行、ISP、およびメールサーバーなどの重要インフラストラクチャをホストしていることを明らかにします。BGP アクティビティのタイミングは政治的不安と一致し（1月3日に爆発報告およびマドゥロが USS Iwo Jima に登場）、国家レベルでの悪用または意図的なルーティング操作を示唆しています。ニュースレターは、通信事業者、ホスティングプロバイダー、およびセキュリティ企業に対し、ユーザーと重要インフラストラクチャをトラフィックの傍受や劣化から保護するために BGP 検証（例：RPKI）を強化するよう促しています。

2026/01/06 7:10

なぜAIは2025年に就業市場に参加しなかったのでしょう？

## Japanese Translation: この記事は、2025年までにAIエージェント革命が起こるという高い期待が過大であると主張しています。サム・オルトマン、ケビン・ワイル、マーク・ベニオフはすべて急速な採用と「デジタル労働」のブームを予測しましたが、実際のテスト（例：ChatGPTエージェントがドロップダウンメニューをナビゲートするのに14分かかったケース）では、大規模言語モデルは未だ鈍く不安定であることが示されています。ガリ・マーカスやアンドレイ・カルパチといったシリコンバレーの懐疑派もこれらの限界を認めており、カルパチはこの時期を「エージェントの十年」と呼びました。著者は、まだ信頼できるデジタル従業員を構築する方法がわからないことを指摘し、未来の仮想的な利益よりも現在の控えめな能力に焦点を移すべきだと訴えています。2026年には、実際の取り組みとして段階的な統合を推奨し、企業はまず小規模プロジェクトで試験運用するよう促し、政策立案者には仮説ではなく現在直面しているAIリスクに対処するよう呼びかけています。 ## Text to translate (incorporating missing details and avoiding inference):** The article argues that high‑profile predictions of an AI‑agent revolution by 2025 have been overblown. Sam Altman, Kevin Weil, and Mark Benioff all forecasted rapid adoption and a “digital labor” boom, but real‑world tests—such as ChatGPT Agent spending fourteen minutes navigating a drop‑down menu—show that large language models remain clumsy and unreliable. Silicon Valley skeptics like Gary Marcus and Andrej Karpathy acknowledge these limitations; Karpathy even referred to the period as the “Decade of the Agent.” The author notes that we still do not know how to build reliable digital employees, and urges a shift in focus from speculative future gains to the current modest capabilities. In 2026, the piece calls for realistic engagement: incremental integration rather than wholesale automation, encouraging companies to pilot small‑scale projects first and prompting policymakers to address present AI risks instead of hypothetical ones.

2026/01/06 1:47

**Show HN:** *Tailsnitch – Tailscale 用のセキュリティ監査ツール*

## Japanese Translation: **Tailsnitch** は、52項目を7つのカテゴリ（アクセス、認証、ネットワーク、SSH、ログ、デバイス、DNS）に分類した検査で、誤設定や過度に許容的なアクセス制御、ベストプラクティス違反を監査する軽量CLIツールです。ユーザーは `tailsnitch` のようなシンプルなコマンドで実行し、結果を severity（`--severity`）、カテゴリ（`--category`）、特定のチェックID（`--checks`）または tailnet（`--tailnet`）でフィルタリングでき、SOC 2 証拠として JSON または CSV へエクスポートできます。ツールは `tailsnitch --fix` による対話型修復をサポートし、dry‑run、auto‑select、および古いデバイス、保留中の承認、auth keys、タグなどの問題を自動的に修正するオプションがあります。認証は OAuth（推奨）または API キーで行われます；監査モードでは `policy_file:read` と `devices:core:read` のスコープが必要で、修復モードではさらに `auth_keys` と `devices:core` が必要です。インストールは簡単です：GitHub Releases から事前ビルドされたバイナリをダウンロードするか、`go install github.com/Adversis/tailsnitch@latest` を実行するか、ソースコード（`git clone https://github.com/Adversis/tailsnitch.git`）をビルドします。既知のリスクは `.tailsnitch-ignore` ファイルで抑制できます（例：`ACL‑008` や `DEV‑006` のようなエントリー）。このファイルは現在とホームディレクトリに検索され、`--no-ignore` で無効化可能です。 Tailnet‑Lock チェック（`DEV‑010`、`DEV‑012`）にはローカルの Tailscale CLI が必要で、遠隔監査時にはマシンの状態を反映し、`--tailscale-path` を使用して上書きできます。 JSON エクスポートはポストプロセッシング（例：`jq` で失敗や severity の概要を一覧表示）用に設計されており、`--soc2 json` または `--soc2 csv` により SOC 2 証拠の生成もサポートします。最後に、Tailsnitch は CI/CD パイプライン（GitHub Actions など）へ統合でき、重大または高 severity の発見があった場合にビルドを自動的に失敗させることで、チームが継続的にセキュリティポリシーを強制するのに役立ちます。