Entry No.017← 記事一覧へ

道具に役割を持たせる。2026年の開発環境

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

Published
2026年7月15日
Read in English

エディタをVS CodeからZedへ、ターミナルをmacOS標準からOttyへ替えました。あわせてプロジェクトの .env を平文で置くのをやめ、AIエージェントを環境の一部として組み込み直しています。現在の構成と、その背景にある考えをまとめておきます。

開発環境について

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

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

自分は、マルチタスクが得意ではありません。そこで用途ごとにアプリを分け、アプリを切り替えるという小さな操作を、頭が次の仕事へ移る合図にしています。

ここでいう「ミニマル」は、数を減らすことだけではありません。役割を明確にし、設定やプラグインを必要以上に増やさないこと。最近のツールは初期設定でもよくできているので、まずはそのまま使います。

アプリケーション

Zed

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

Otty

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

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側で管理できるため、現在はこの方法に落ち着いています。

AWSクレデンシャルには、1PasswordのAWS Shell Pluginを使っています。

Use 1Password to securely authenticate the AWS CLI - 1Password DeveloperSign in to the AWS CLI with your fingerprint, Apple Watch, or other system authentication. No more plaintext API keys or credentials in your home directory.1password.dev

AWS CLIのコマンドであれば、実行時に1Passwordからクレデンシャルを受け取れます。npx cdkのようにAWS CLI以外のツールから、AssumeRoleを設定したプロファイルを使いたい場合は、AWS CLIが解決した一時クレデンシャルを現在のシェルへ書き出します。

eval "$(op plugin run -- aws configure export-credentials --profile 37108 --format env)"
npx cdk deploy

この例では、1PasswordがAWS CLIへ元のクレデンシャルを渡し、AWS CLIが37108プロファイルの設定に従ってロールを引き受けます。aws configure export-credentialsは、解決後のAWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、AWS_SESSION_TOKENをexport文として出力し、evalがそれを現在のシェルへ反映します。その後に実行するCDKは、標準のAWS環境変数から同じ一時クレデンシャルを利用できます。

長期クレデンシャルをプロジェクト内のファイルへ保存する必要はありませんが、書き出した値はそのシェルに残り、AssumeRoleセッションの有効期限が切れるまで利用できます。期限が切れた場合は、同じコマンドをもう一度実行します。リージョンはこのコマンドでは書き出されないため、必要に応じてCDK側の設定やAWS_DEFAULT_REGIONで指定します。

ハードウェア

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

AIエージェント

AIエージェントは、すでに開発環境の一部です。 現在はCodexとClaude Codeを使っています。 ユーザースコープには、役割が明確なスキルと、それらをつなぐ自作のgreetingを入れています。greeting自体は処理を抱えず、次の順番で既存のスキルを呼び出します。

  1. grill-with-docs：対話を通じて仕様を整理し、用語や設計判断を文書に残す
  2. to-spec：整理した要件を、検証可能な仕様として固定する
  3. to-tickets：仕様を、単独で確認できる実装チケットへ分割する
  4. implement：依存関係が解決したチケットを1件ずつ実装する

to-specでは、機能要件だけでなく、正常系、異常系、境界値、非機能要件も確認します。アクセシビリティ、レスポンシブ対応、ローディングや成功・失敗のフィードバック、エラーの分類、ボタンの非活性、多重送信の防止も、この段階で受け入れ条件へ含めます。

実装チケットには、ユニットテスト、コンポーネントテスト、End-to-End（E2E）テストを含めます。エラーハンドリングは共通の境界へ集約し、各画面で独自のエラー形式を増やしません。テストやアクセシビリティを最後の仕上げにせず、ユーザーが確認できる縦方向の変更としてチケットごとに完成させます。

ユーザーインターフェースを実装する前には、ui-ux-pro-max、frontend-design、high-end-visual-designで方針を確認します。実装後はweb-design-guidelinesとwriting-guidelinesで、操作性、アクセシビリティ、表示文言を監査します。ユーザーに見える変更がないチケットでも、適用できる項目がないか確認してから非該当と判断します。

このフローとは別に、ponytailで動作する最小限の解決策を選び、過剰な設計を避けます。必要なスキルはGitHub CLIのgh skillで管理し、CodexとClaude Codeへ同じGitHub上のソースからインストールしています。自作スキルのリポジトリ名は例示です。

for agent in codex claude-code; do
  gh skill install mattpocock/skills engineering/grill-with-docs --agent "$agent" --scope user
  gh skill install mattpocock/skills engineering/to-spec --agent "$agent" --scope user
  gh skill install mattpocock/skills engineering/to-tickets --agent "$agent" --scope user
  gh skill install mattpocock/skills engineering/implement --agent "$agent" --scope user
  gh skill install mattpocock/skills productivity/grilling --agent "$agent" --scope user
  gh skill install mattpocock/skills engineering/domain-modeling --agent "$agent" --scope user
  gh skill install mattpocock/skills engineering/setup-matt-pocock-skills --agent "$agent" --scope user
  gh skill install mattpocock/skills engineering/tdd --agent "$agent" --scope user
  gh skill install mattpocock/skills engineering/code-review --agent "$agent" --scope user
  gh skill install vercel-labs/agent-skills web-design-guidelines --agent "$agent" --scope user
  gh skill install anthropics/skills frontend-design --agent "$agent" --scope user
  gh skill install leonxlnx/taste-skill skills/soft-skill --agent "$agent" --scope user
  gh skill install vercel-labs/agent-skills writing-guidelines --agent "$agent" --scope user
  gh skill install nextlevelbuilder/ui-ux-pro-max-skill .claude/skills/ui-ux-pro-max --allow-hidden-dirs --agent "$agent" --scope user
  gh skill install your_account/dotfiles skills/greeting --agent "$agent" --scope user
  gh skill install DietrichGebert/ponytail ponytail --agent "$agent" --scope user
done

インストール状態の確認と更新には、次のコマンドを使います。

gh skill list --agent codex --scope user
gh skill list --agent claude-code --scope user
gh skill update --all

特定のプロジェクトだけで必要なスキルは、グローバルに増やさず、プロジェクトスコープへインストールします。 また、npx skillsとは管理情報に互換性がないためgh skillだけを使い、スキルの追加や更新後はCodexとClaude Codeを再起動します。gh skillは現在プレビュー機能のため、コマンドや管理形式が変わる可能性はあります。 外部のスキルを導入する際は、提供元やリポジトリの内容も確認してから使うようにしています。

ツール管理

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

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

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

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

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

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

dotfiles

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

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

まとめ

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