Back to Article index

役割を分けて、安全に使う。現在の開発環境

セキュリティ、役割分担、ミニマルさを軸に見直した、現在の開発環境とツール選びの考え方を紹介します。

Published
2026年7月15日
Read in English

最近、開発環境を大きく見直したので、現在の構成と、その背景にある考え方をまとめておきます。

開発環境について

環境を整えるうえで意識したのは、主に次の3点です。

  1. セキュリティに気を配る
  2. アプリの切り替えを、コンテキストの切り替えにする
  3. できるだけミニマルに保つ

自分はマルチタスクがあまり得意ではないため、用途ごとに使うアプリを分けています。 「アプリを切り替える」という操作そのものが、頭を別の作業へ切り替えるきっかけになるような構成です。 ここでいう「ミニマル」は、単純にアプリの数を減らすという意味ではありません。それぞれの役割を明確にし、設定やプラグインを必要以上に増やさないことを意識しています。 最近のツールはデフォルト設定の完成度が高いものも多いので、基本的には大きくカスタマイズせず、そのまま使っています。

Applications

Zed

エディタはVS CodeからZedへ乗り換えました。 もともとエディタに強いこだわりがあったわけではなく、VS Codeに大きな不満があったわけでもありません。開発環境を見直すタイミングでZedを試してみたところ、そのまま定着しました。 現在はプラグインや設定をほとんど追加せず、デフォルトに近い状態で運用しています。

Ghostty

ターミナルはmacOS標準のターミナルからGhosttyへ乗り換えました。 こちらも細かなカスタマイズはせず、基本的にはデフォルト設定のまま使っています。

SnippetsLab

コードスニペットや開発中のメモを記録するために使っています。 これまでObsidianやNotionなど、さまざまなツールを行き来してきましたが、現在はSnippetsLabに落ち着いています。 多分、しばらくはこのままです。

1Password

パスワードに加えて、環境変数やAWSクレデンシャルの管理にも使っています。 特に、プロジェクトで使用する.envを平文で保存しなくて済むようにしている点が便利です。 設定は、だいたい次の手順で行っています。

  1. 1Passwordのデスクトップアプリにサインインし、Developer機能を有効にする
  2. Developer > EnvironmentsからEnvironmentを作成する
  3. 必要な環境変数をEnvironmentへ登録する
  4. EnvironmentのDestinationsを開き、Local .env fileを選択する
  5. 対象プロジェクトの.envを保存先として指定し、マウントする

シェルから環境変数を利用したい場合は、対象プロジェクトのmise.tomlで.envを読み込むようにしています。 秘密情報をプロジェクト内へ平文で保存する必要がなくなり、環境ごとの値も1Password側で管理できるため、現在はこの方法に落ち着いています。

Hardware

会社から支給されている14インチMacBook Pro（2023）を使用しています。 MacBook Proのキーボードをそのまま使うこともあれば、HHKB Type-SとMagic Trackpadを組み合わせることもあります。 Magic TrackpadはバッテリーがかなりへたっているうえにLightning端子のモデルなので、どこかのタイミングで買い替えたいと思っています。

AI Agents

開発環境の中にAI Agentが自然に入る時代になったと感じています。 現在はCodexとClaude Codeを使っています。 基本的には標準の状態で十分だと思っていますが、フロントエンド領域には補いたい知識がいくつかあるため、関連するスキルを追加しています。

ユーザースコープで共通して使うスキルは、GitHub CLI経由でインストールしています。

for agent in codex claude-code; do
  gh skill install anthropics/skills frontend-design --agent "$agent" --scope user
  gh skill install ibelick/ui-skills fixing-accessibility --agent "$agent" --scope user
  gh skill install ibelick/ui-skills fixing-metadata --agent "$agent" --scope user
  gh skill install ibelick/ui-skills fixing-motion-performance --agent "$agent" --scope user
  gh skill install microsoft/playwright-cli playwright-cli --agent "$agent" --scope user
done

それ以外にも、プロジェクトの構成や用途に応じて、次のようなスキルを追加しています。

  • ibelick/ui-skills baseline-ui
  • vercel-labs/agent-skills react-best-practices
  • supabase/agent-skills supabase-postgres-best-practices
  • vercel-labs/skills find-skills

スキルを増やしすぎると管理が難しくなるため、すべてを最初から入れるのではなく、必要になったものだけを追加する方針です。

また、外部のスキルを導入する際は、提供元やリポジトリの内容を確認してから使うようにしています。

Tools Management

CLIツールやランタイムの管理には、Homebrewとmiseを使っています。

役割は、だいたい次のように分けています。

  • Homebrew：GUIアプリやmiseなどの導入
  • mise：言語ランタイムやCLIツールのバージョン管理
  • dotfiles：各種設定ファイルの管理

npmについては、利用するレジストリを明示的に指定しています。

$ npm config get registry
https://npm.flatt.tech/

npmパッケージを取り巻くセキュリティ上の問題を踏まえ、パッケージの取得元を管理するための対策として設定しています。

dotfiles

いつの時代になっても、dotfilesはいいものです。 現在の環境では、まずHomebrewを導入し、次にmiseをセットアップします。その後、dotfilesで管理している各種設定ファイルを所定の場所へリンクすれば、基本的な環境構築は完了します。

大まかな流れは次のとおりです。

Homebrew
  ↓
mise
  ↓
各種設定ファイルをリンク

可能な限り手作業を減らしつつ、あとから見返したときにも構成を把握できる状態を目指しています。

まとめ

今回の見直しでは、次のことを重視しました。

  • ツールごとの役割を明確にする
  • アプリの切り替えを、コンテキストの切り替えに利用する
  • 設定やプラグインを必要以上に増やさない
  • 秘密情報を平文で保存しない
  • AI Agentや外部スキルを安全に利用する
  • dotfilesから環境を再現できるようにする

ツールの数をただ減らすのではなく、それぞれの役割を分けたうえで、設定を増やさず、安全に使えることを意識しています。 しばらくは、この構成で運用していくつもりです。