AI 開発の道具を選ぶ基準を「毎日触るか」「時間が縮むか」の 2 つに絞り、手元の Mac と案件の開発環境を組み直しました。

結果として残ったのは、キーリピートの設定やタブを閉じる習慣といった地味なものと、環境ごと配ってしまう仕組みでした。この記事では、何が残って何を落としたのか、そしてなぜその順番なのかを書きます。

何に困っていたか

道具の話の前に、詰まっていた 3 つを先に出します。選んだ理由が残っていないと真似ができないからです。

1 つ目は、環境構築が終わってからが進まないことです。案件ごとのセットアップが完了すれば速度が出るという前提で動いていましたが、そこが間違いでした。セットアップの完了と、業務が回り始めることは別の話でした。

2 つ目は、ツールを入れただけで終わることです。新しいメンバーが入ったときや案件のオンボーディングのときに説明はするのですが、入れたあと使われずに終わるケースが続きました。

3 つ目は、全員の前提がそろわないことです。同じリポジトリを見ていても、ドメイン知識の事前インプットが人によって欠けます。結果として判断が自分に寄り、タスクが 1 人に集中しました。

一軍の選抜基準は 2 つだけ

判断軸は「毎日触るか」と「時間が縮むか」の 2 つだけにしています。基準が 3 つ以上あると、もう選べなくなるからです。

毎日触るかを見るのは、週 1 回しか思い出さないものは忘れるからです。導入時に覚えた作法が、次に使うときには残っていません。時間が縮むかを見るのは、導入とセットアップに時間がかかるものを弾くためです。効果が出るまでに学習コストを払い続ける道具は、一軍から外します。

新しいツールは知った時点ですぐ試して、この 2 つで残すか落とすかを決めています。この基準で選ぶと、派手なものはあまり残りません。

ローカル PC 編

一日でいちばん長く触るのは、案件のコードではなく手元の Mac でした。ここから直します。

キーリピートとストレージ

AI に指示を出す時代でも、最初の一文字を打つのは人間です。1 日で最も回数を踏む操作はキー入力なので、Mac のシステム環境設定でキーのリピート速度と認識までの時間を最速側に振り切っています。1 回の待ちは一瞬ですが、回数が多いので体感でいちばん引っかかります。

ペアプロやモブプロで他の人の画面を見ていると、この設定が既定のままなせいでタイピングが遅いケースに出会います。PC のセットアップは各自で、という運用だと手が付きにくい場所です。

ストレージも同じ扱いにしています。支給されている PC は 245GB で、一時期は 200GB 近くまで埋まっていました。手で調べるのが面倒だったので Claude Code に調査させたところ、いちばん容量を食っていたのは Chrome のキャッシュと履歴でした。中身を確認してから消す判断をしています。動作が重いと感じたときに毎回この調査をやらせられるので、手元の速さと軽さは先に確保しておく価値があります。

入口をターミナル 1 本に絞る

Claude Code はローカルの Mac に入れて、入口をターミナル 1 本に絞っています。入口を増やすと設定も作法も分散するので、あえて増やしません。ターミナルは長く使っている iTerm2 です。AI エージェント向けのターミナルもいくつか出ていますが、ここは慣れの効果が大きいので乗り換えていません。

日本語入力は Google 日本語入力にしています。変換や補完で止まる回数が減るからです。ここは一番よく通る道なので、冒険せずに実績のあるものを置いています。

Claude Desktop と Claude in Chrome

Claude Code とは別に Claude Desktop も入れていて、役割を分けています。同じ AI でも置き場所が違えば守備範囲が変わります。

最近よく使っているのは Claude Desktop と Claude in Chrome の組み合わせです。どちらのブラウザプロファイルを使うかを指示すると、Claude in Chrome がそのプロファイルでブラウザを操作します。Google ドライブの資料をローカルへ落とさずに読ませる、GitHub のリポジトリを調べて原因を分析させる、デプロイ済みの開発環境に対して画面のテストを指示する、といった使い方をしています。

VS Code を開かない経路

案件が複数あるので、開発環境には GitHub Codespaces と Devcontainer を使っています。IDE は VS Code ですが、ブラウザ版だとポートフォワーディングで詰まることがあるので、デスクトップ版から Codespaces に接続する形にしています。拡張機能は 4 つだけに絞っています。

そのうえで、GitHub CLI をローカルに入れておくと Codespaces へ SSH 接続できます。コードやファイルを目で見る必要がないタスクなら、VS Code を開かずにターミナルから Codespaces 内の Claude Code を起動して指示を出すだけで終わります。ターミナルは何枚でも開けるので、複数案件のタスクを 1 画面で並べて進行状況を見られます。

gh は自分の移動手段として使っていて、AI エージェントには叩かせていません。人間が握っている数少ない場所です。

画面のことは画面で渡す

画面についての指示は、文章より画像のほうが正確に伝わります。Skitch でスクリーンショットを切り取り、枠と矢印と文字を足して渡しています。

用途は 2 つです。1 つは AI に「この画面のこのコンポーネントを直してほしい」と伝えるとき、もう 1 つはお客様に説明するときの強調です。文章で場所を説明するより、矢印 1 本のほうが速く済みます。

タブと Slack の配置

Chrome のタブは、以前は 20 枚も 30 枚も開いたままにしていました。ただ、開けば開くほど見返さなくなります。読む価値があるならブックマークに移し、見返すつもりがないなら閉じる、に切り替えました。大量に開いていると、どれが何だったかを毎回探すことになり、そこで集中が切れます。

Slack は設定ではなく配置の話です。画面の左側に固定して、視界に入る位置から動かしていません。以前は見るたびにウィンドウを探していて、その探す動作そのものが集中を切っていました。レスポンスの速さを優先したいので、ここには AI を挟んでいません。

開発環境編

ここからは個人の工夫ではなく、チーム全員に配る話に変わります。個人の設定はどれだけ磨いても本人にしか効かないので、配布物の形にしないとチームの速度にはなりません。

Devcontainer に環境ごと配る

案件の開発環境は Codespaces と Devcontainer で組んでいます。手順書を配ると読まれませんし、読まれても環境はそろいません。そこで設計図ごとリポジトリに置く形にしました。

構成は 4 層です。

人間が README を読む前提ではなく、AI に「このリポジトリはどうなっているか」を聞く前提で組んでいます。AI が作業しやすい形と、人間が触る範囲を薄くする形が、だいたい同じ方向を向きます。

mise で全員のバージョンを固定する

以前は Devcontainer Features で AWS CLI や GitHub CLI、Python、Node を入れていました。ただ、使いたいものを毎回探す手間があり、Features 側が更新されるたびに Codespaces のリビルドが必要になります。タスクランナーは Makefile だったので、そこも含めてもう少し単純にできないかと探して見つけたのが mise です。

mise.toml に必要なツールとバージョンを書いておき、mise install で一括導入します。

[tools]
python = "3.12"
node = "22"
"npm:pnpm" = "latest"
awscli = "latest"
gh = "latest"
[tasks.gh-login]
run = "gh auth login --hostname github.com --git-protocol https --web"

Devcontainer Features に無いものや、Devcontainer 内で独自にインストールしていたものも、この 1 ファイルに寄せられます。タスクランナーも兼ねるので、mise run gh-login のような形で定型作業をまとめられます。

バージョンの一括更新もコマンドで済みます。

mise outdated
mise upgrade --bump

mise outdated でどれだけ差が出ているかを先に確認してから上げられるので、更新の判断がしやすくなりました。この移行で Devcontainer のリビルド時間と、構築後の確認にかかる時間が短くなっています。「自分の手元では動く」という言葉も、この 1 ファイルでほぼ消えました。

AI エージェント 4 本の役割分担

エージェントは 4 本入れています。欲張りではなく、得意が違うので同じ仕事を 4 回やらせても意味がないからです。主軸は Claude Code で、場合によって GitHub Copilot や Codex を使い分けます。

この構成はテンプレートリポジトリにしてあるので、新しい案件はそこから生成すれば最初から 4 本使える状態で始まります。案件ごとに毎回入れ直す作業をなくすためです。

ハーネス基盤

エージェントを 4 本並べても、人間が 4 本に指示を出すなら負荷は減りません。指示を出す人が一番のボトルネックになります。

そこで、人間が相手にするのは AI 秘書 1 つだけにしました。AI 秘書は CLAUDE.md の定義とスキル、カスタムエージェントとして用意していて、そこから PM エージェント、開発エージェント、デザインエージェント、セキュリティエージェントに並列で指示を振ります。各エージェントは、担当領域に対応するスキルを読み込んでから実装に入ります。

オントロジーで用語をそろえる

冒頭の困りごとの 3 つ目、全員の前提がそろわない問題はここで片付けます。

用語集を人が更新し続けるのは無理でした。用語集は作った日がいちばん新しい状態になりがちです。そこでオントロジーのスキルを用意して、Pull Request や設計の作業のなかで出てきた新しい語と既存の語の関係をグラフとして育てるようにしました。社内のスキルマーケットプレイスに置いてあるので、リポジトリ側から呼び出して使えます。

AI 秘書から各エージェントまで同じ語で話せる状態を先に作っておくと、指示の解釈がぶれにくくなります。ハルシネーションを完全になくせるわけではありませんが、前提となる語の関係が渡っている分、期待した方向に寄せやすくなります。

Skills で手順を配る

困りごとの 2 つ目、入れただけで終わる問題はここで片付きます。配るべきだったのはツールではなく手順でした。

毎回同じ作業をしているもの、時間が縮むものをスキルとして定義して、リポジトリごと配っています。ツールの名前を伝えるだけだと使われませんが、手順が呼び出せる形で入っていれば使われます。

あわせて、役割ごとのカスタムエージェントと Hooks で作法を強制しています。AI に毎回同じ注意をしていることに気づいたのがきっかけです。注意は口ではなく仕組みでやるほうが確実です。

Lefthook で人のレビュー前に止める

レビューで指摘したくないことは、レビューまで来させないようにしています。人間が見るべきなのは設計の是非だけです。

コミットとプッシュの前に Lefthook で次を走らせています。

• AWS のクレデンシャルや API キーがハードコードされていないかの検査
• コミット単位での変更履歴（チェンジログ）の生成
• フォーマットと lint
• ast-grep による構造の検査

ast-grep は構文木に対してパターンを書けるので、文字列の grep では拾いにくい書き方の逸脱を検出できます。AI にとっても扱いやすいツールです。同じ指摘を 3 回書いた時点で、それは仕組み側の仕事になります。

効くのは下の層から

全体を並べると、下の層ほど地味で、下の層ほど毎日効きます。

上から入れたくなりますが、効くのは下からでした。ハーネス基盤を組んでも、キーリピートが既定のままなら毎日の待ちは残ります。

まとめ

• 一軍に残るのは、地味で毎日触るものだけです
• 個人の工夫は、配布物に変えて初めてチームに効きます
• 仕組み化は手元の設定ではなく、ハーネス基盤の側でやります

今日からいちばん真似しやすいのは、キーリピートの設定と、自分で調べる前に AI に投げる習慣の 2 つです。どちらも導入コストがほぼゼロで、毎日効きます。

なお、ここで書いた配布の型をチームに定着させる支援は AIDD インハウス、実践形式で一通り体験する形は AIDD キャンプ で扱っています。お気軽に KDDIアイレットへお問い合わせください！