2026年 AIコーディングエージェント徹底比較 — Claude Code・Cursor・GitHub Copilot・OpenAI Codex・Aider・OpenClaw 実践バイヤーズガイド

プロローグ — フィールドはいくつかの本気のハーネスに収束した

2023年のAIコーディングツール市場はカオスだった。毎週新しいextensionが出て、demoは華やかで、実務で生き残るものはほぼ無かった。2026年春の風景は違う。フィールドは収束した。 本気でプロダクションコードを任せられる「ハーネス(harness)」は、もう数えるほどしかない。

ここで harness という言葉を意図的に使う。比較しているのはモデルではない。Claude、GPT、Geminiはどれも良い。比較しているのは モデルをコードベース・ターミナル・CIに接続するruntime — コンテキストをどう集め、ツールをどう呼び、変更をどう適用し、ガードレールをどこに置くか、だ。同じClaude Opusを使ってもClaude CodeとCursorとAiderはまったく違う体験になる。ハーネスが差を生む。

これはキャリアサバイバル記事ではない。「AIが開発者を置き換えるか」のような問いは扱わない。これは 実務者のバイヤーズガイド だ。6つのツール — Claude Code、Cursor、GitHub Copilot、OpenAI Codex、Aider、OpenClaw — を同じ軸で徹底比較し、どの状況にどのツールが合うかを示し、そして何より 自分のコードベースで検証する方法 を提示する。

なぜこの6つか。基準はシンプルだ。(1) 2026年春現在、実際にメンテされ更新されているか。(2) toyではなくプロダクションコードを任せられる自律性があるか。(3) 異なるワークフローを代表しているか。この3つを満たすツールを選んだ。Windsurf、JetBrains AI、Cline、Antigravity、Kiroのようなツールも本気だが、この6つが「surface x 自律性 x 価格モデル」のdesign spaceをほぼ覆う。6つを理解すれば残りはバリエーションとして読める。

価格・機能の数値は速く変わる。2026年初頭だけで3つのツールが価格モデルを変えた。具体的な数値は「2026年初頭時点」と釘を刺し、6ヶ月後も有効な 意思決定に影響する構造的な違い に集中する。数値は自分で確認すること。だが構造を理解すれば、数値が動いても判断はぶれない。

モデルはcommodityになり、ハーネスがmoatになる。ツールを選ぶとは、モデルではなくワークフローを選ぶことだ。

1章 · 比較軸 — 何を見て選ぶか

ツールを「雰囲気」で選ぶと3ヶ月後に後悔する。次の7軸に分解して見ること。

軸1 · Surface(どこで動くか) CLIか、IDEか、cloudか。これは好みではなくワークフローの決定だ。CLIハーネスはターミナル・Git・CIに自然に付き、scriptでまとめやすい。IDEハーネスはインライン差分・tab補完・debugger統合が強い。cloudハーネスは非同期 — チケットを投げ、別の作業をして、PRを受け取る。

軸2 · 自律性レベル 補完(次行の提案) -> インライン編集(ブロック単位) -> エージェント(マルチファイル、マルチステップ、自分でテスト実行) -> 非同期エージェント(人なしで最後まで)。ツールごとに「デフォルトモード」が違う。Copilotは補完から始まり、Claude CodeとCodexはエージェントから始まった。

軸3 · コンテキスト処理 モデルのコンテキストウィンドウが大きいことと、ハーネスがそれをうまく埋めることは別の話だ。核心の問い。関連ファイルをどう見つけるか(embedding indexか、grepか、両方か)、大きいリポジトリをどう圧縮するか、長いセッションでコンテキストをどう管理するか。2026年初頭時点、一部のハーネスは1Mトークンウィンドウを実験的にサポートする — およそ2.5万〜3万行をchunkingなしで一度に見る。

軸4 · ツール / MCP対応 エージェントはツールが無いと働けない。Bash、ファイル編集、Gitは前提。その上に MCP(Model Context Protocol) 対応の有無が分岐点になる。MCPは外部ツール — DB、issue tracker、ブラウザ、社内API — を標準的な方法で接続するprotocolで、2026年現在、事実上の業界標準になった。MCPに対応すればエコシステム全体を借りて使える。

軸5 · 価格モデル 3つのパターンがある。(a) 定額subscription — 予測可能、ヘビーユーザーに有利。(b) トークン/credit ベース — 使った分だけ払う、ライトユーザーに有利だが変動が大きい。(c) seat ベース — チーム単位。2026年初頭時点、業界全体がトークンベースに移行中で、「月いくら」という答えがますます難しくなった。ヘビーユーザーの実際の月額コストを必ず見積もること。

軸6 · サンドボックスモデル エージェントは rm -rf を打てるか。permission モデルが核心だ。(a) 承認ゲート — 危険なコマンドごとに人がyes/no。(b) サンドボックス — 隔離された環境(container/VM)で実行し差分だけ見せる。(c) フルアクセス — 速いが危険。cloudハーネスは通常(b)、CLIハーネスは(a)と(c)をオプションで与える。

軸7 · エコシステムとガバナンス SSO、監査ログ、チームポリシー、サードパーティ拡張、コミュニティの規模。ソロ開発者には些細だが、50人チームには決定的だ。誰がどのコードにエージェントを走らせたかが追跡できるか、コストをチーム・プロジェクト別に分けられるか、セキュリティチームが承認できるデータ処理ポリシーがあるか。これらに答えが無ければエンタープライズ導入は止まる。

軸の使い方 この7つをチェックリストとして使ってはいけない — 重みを付けること。ソロICなら軸1・2・3・5が重要で軸7はほぼ無意味だ。50人チームのプラットフォームエンジニアなら軸5・6・7が決定的で、軸2の細かい差はノイズだ。同じ表を見ても、役割によって違うツールが1位になる。だから「最高のAIコーディングツール」のようなheadlineは無意味だ — 問いが間違っている。

この7軸を頭に入れ、ツールを1つずつ見ていく。各章は同じフレーム — Surface、強み、自律性・サンドボックス、価格、弱み、一行まとめ — で整理する。フレームを固定することが公平な比較を作る。

2章 · Claude Code — ターミナルネイティブエージェントの基準点

Surface: CLIファースト。ターミナルで動くエージェントで、IDE拡張(VS Codeなど)もあるが、アイデンティティはCLIだ。

何が得意か Claude Codeは「エージェントがデフォルト」のハーネスの基準点だ。ファイルシステム・Git・Bashをツールとして握り、マルチファイルのrefactorと大規模コードベースの探索に強い。2026年初頭時点、Claude Opus 4.6が1Mトークンのコンテキストを処理する — 大きいリポジトリをchunkingなしで丸ごと読むという意味で、「このパターンがどこで壊れるか全部見つけて」のようなタスクで体感差が大きい。

MCPをfirst-class citizenとして扱う。社内DB、issue tracker、ブラウザ自動化を標準protocolで接続する。skill・subagentの概念で大きいタスクを小さい単位に分割し、CLAUDE.md のようなプロジェクトメモリでconventionを注入する。

自律性とサンドボックス 承認ゲートがデフォルト — 危険なコマンドは人が確認する。permissionをあらかじめallowlistに入れてfrictionを減らせる。信頼が積み上がれば緩め、知らないコードベースでは締めること。

価格 2026年初頭時点、Claude Pro subscription(月20ドル程度)にClaude Codeが含まれ、ヘビーユーザー向けのMaxプラン(月100ドル、月200ドル程度)が別にある。使用量が多ければ上位プランが事実上必須だ。

弱み 純粋なインライン編集・tab補完の体験はIDEネイティブなツールより弱い。ターミナルが一次インターフェースなので、GUI debuggerの統合は期待してはいけない。ヘビーに使うとコストが速く上がり上位プランに押し出される — ライトユーザーには過剰な選択になりうる。

いつ使わないか 1日の大半が「1ファイル内で関数をいくつか速く書く」なら、Claude Codeはoverkillだ。そのループはIDEのtab補完の方が速い。Claude Codeの価値はマルチファイル・大規模・探索型の作業から出る — そういう作業が少なければ別のツールが良い。

一行まとめ: マルチファイル作業と大規模リポジトリ探索の品質の基準点。ターミナルワークフローを使う人の最初の候補。

3章 · Cursor — AIネイティブIDEの速さ

Surface: IDE。VS Codeをforkした独立エディタだ。

何が得意か Cursorのアイデンティティは 速さ だ。tab補完(次の編集の予測)が業界で最も滑らかで、マルチファイル編集はAgent/Composerモードで処理する。インラインで見て即座にacceptまたはrejectするループが速い — 「エディタから手を離さない」体験だ。

複数のbackendモデルを選べ、コードベースのembedding indexで関連ファイルを見つける。日常的な編集 — 関数の作成、小さいrefactor、boilerplate — の回転速度が核心の強みだ。

自律性とサンドボックス 補完・インライン編集がsweet spotだが、Agentモードでマルチステップの自律実行もする。ターミナルコマンドの実行は承認ゲートを通る。CLIハーネスほど深いサンドボックス隔離ではない。

価格 2026年初頭時点、個人プランはHobby(無料)、Pro(月20ドル程度)、Pro+(月60ドル程度)、Ultra(月200ドル程度)だ。ただしCursor自身が「Agentを毎日使うと月60〜100ドル分の使用量が普通、power userは200ドル以上」と案内している — 定額のつもりで入って使用量課金に驚くことがあるので注意。

弱み 独立エディタなのでVS Codeを離れる必要がある(慣れていれば利点、そうでなければ難点)。非同期チケット作業には弱い。ヘビーユーザーの実際のコストはsurface priceより高い — これが最もよく聞く不満だ。

いつ使わないか 「issueを投げて席を立つ」非同期ワークフローが主力なら、Cursorは合わない。Cursorの強みは人がエディタの前に座っているときに出る。またコスト変動に耐えにくい環境(予算が厳しいチーム)なら、定額で予測できるツールが良い。

一行まとめ: エディタ内での速さが最優先ならCursor。ただし実使用コストを先に見積もること。

4章 · GitHub Copilot — コスパと統合

Surface: マルチIDE拡張。VS Code、JetBrains、CLIに付く。独立アプリではなく「あなたが既に使っているエディタ」の上に乗る。

何が得意か Copilotは補完から始まり agent mode と coding agent に拡張された。強みは2つ。第一に コスパ — 最も安い本気の選択肢だ。第二に GitHub統合 — issue・PR・Actionsとの結合、そして成熟したエンタープライズlicensing・SSO・ポリシー管理。

coding agentはGitHubのissueを割り当てるとバックグラウンドでブランチを作りPRを上げる非同期ワークフローだ。チームが既にGitHubに住んでいるならfrictionが最も少ない。

自律性とサンドボックス 補完・インラインが依然として核心だが、agent modeでマルチファイル作業、coding agentで非同期作業をする。cloudエージェントは隔離環境で実行し結果をPRで出す。

価格 2026年初頭時点、Free(制限あり)、Pro(月10ドル程度)、Pro+(月39ドル程度)、Business(ユーザー月19ドル程度)、Enterprise(ユーザー月39ドル程度)。ただし2026年6月1日付でリクエストベース課金から使用量ベース課金に移行すると案内されたので、課金構造の変更を念頭に置くこと。

弱み エージェント自律性の「深さ」はClaude CodeやCodexのフルエージェント体験にまだ及ばないという評が多い。マルチIDE拡張なので、最もアグレッシブなエージェントワークフローよりは「エディタの強化」に重心がある。

いつ使わないか 「エージェントが勝手に最後まで」やる最もアグレッシブな自律ワークフローが核心の価値なら、Copilotのエージェントの深さが物足りないかもしれない。またGitHubを使わない組織(GitLab/Bitbucket中心)なら、最大の強みである統合が消える。

一行まとめ: 既にGitHubに住んでいて、コスパとエンタープライズ管理が重要ならCopilot。チームの安全なデフォルト。

5章 · OpenAI Codex — CLIとcloudの両利き

Surface: CLI + cloud + desktop app。オープンソースのCLIツール、ChatGPT subscriptionに紐づくcloudエージェント、そして2026年2月にリリースされたmacOS desktop appまで3つの枝だ。

何が得意か Codexの強みは CLIとcloudを一つの流れにまとめる ことだ。codex cloud コマンドでターミナルを離れずにcloud taskを起動・triageし、active・finishedのtaskをinteractive pickerで見る。taskに --attempts(1〜4)を与えてbest-of-Nの実行をリクエストもできる — 同じtaskを複数回走らせて最良を選ぶ。

2026年初頭時点、GPT-5.4がnative computer-use能力と1Mコンテキストウィンドウの実験サポートを持ち、強化されたtool use・tool searchでエージェントが適切なツールをより効率的に見つける。codex remote-control でheadlessでremote制御可能なapp serverを起動するなど、remoteワークフローも磨かれた。

自律性とサンドボックス エージェントがデフォルト。ローカルCLIは承認ゲートとサンドボックスモードをオプションで与え、cloudは隔離環境で実行し結果を出す。/goal ワークフローでlong-horizonのゴールを作りpause・resume・clearする。

価格 2026年初頭時点、ChatGPT Plus・Pro・Business・Enterprise/EduにCodexが含まれ、期間限定のFree・Goアクセスもある。ただし2026年4月2日付で、大半のPlus・Pro・Business・Enterprise顧客向けのCodex価格がトークンベースのcreditに移行した — 使用量トラッキングが必須だ。

弱み 3つの枝のsurface(CLI/cloud/desktop)は強みであり学習曲線でもある。トークンベースへの移行でコスト予測が難しくなった。OpenAIエコシステムに縛られる。

いつ使わないか モデルvendorに縛られたくないなら、Codexは合わない — OpenAIモデルが前提だ。また単純なインライン編集だけ欲しいのに、CLI・cloud・desktopの3つの枝の概念を全部習得しなければならないなら、学習コストが過剰だ。

一行まとめ: 非同期のcloud作業とターミナル作業を一つのツールで行き来したく、既にChatGPTを使っているならCodex。

6章 · Aider — Gitファースト、モデル中立

Surface: CLI。ターミナルで動くpair programmingツールで、オープンソースだ。

何が得意か Aiderの哲学は Gitファースト だ。すべての変更を意味のある単位でauto-commitする — エージェントが何をしたかが git log で完璧に追跡でき、気に入らなければ git revert 一回だ。これは小さいdetailではなく、信頼モデル全体を変える。

第二の強みは モデル中立 だ。GPT、Claude、Gemini、ローカルモデル — 何でも接続する。architectモード が特に賢い。強い(高い)モデルが「どう解くか」を設計し、安く速いeditorモデルがその設計を具体的なファイル編集に翻訳する。2026年のワークフロー推奨案はGPT-5 architectと安価なeditorの組み合わせで、マルチファイルrefactorで単一モデルよりエラーが測定可能なほど減り、コストは30〜50%低い。

watchモード(コードコメントで指示)、prompt caching、/web と /voice、.aider.conf.yml の設定モデル、polyglot leaderboardなど実務機能が堅い。オープンソースなのでsubscriptionコストが無い — モデルのAPIコストだけ払う。

自律性とサンドボックス インライン編集とauto-commitが核心のループ。大きい自律エージェントよりは「追跡可能なpair programmer」に近い。ガードレールはGitそのもの — すべてがcommitされるのでrevertが簡単だ。

価格 ツール自体は無料(オープンソース)。コストは完全にモデルのAPI使用量。architectモードがコストを大きく下げる。

弱み MCP・サードパーティ拡張のエコシステムは商用ツールより薄い。IDE統合・GUIは無い(CLIがすべて)。最もアグレッシブな非同期エージェントワークフローには弱い。

一行まとめ: Gitの追跡性とモデル選択の自由、そしてコスト管理が最優先ならAider。オープンソースのminimalistの選択。

7章 · OpenClaw — メッセージングインターフェースの自律エージェント

Surface: メッセージングアプリ。Signal、Telegram、Discord、WhatsApp内のchatbotとして動作し、ローカルで動く。オープンソースだ。

何が得意か OpenClawはこのリストで最も毛色の違うツールだ。元々コーディング専用のIDEエージェントではなく 汎用の個人AIエージェント だ — 2025年11月にClawdbotという名前で初公開され、2026年初頭に二度の改名(Moltbot -> OpenClaw)を経た。PSPDFKitのfounderであるPeter Steinbergerが作り、2026年初頭にGitHub starが10万を超えて現象になった。

核心の特徴は self-improvement だ。やりたいタスクのために自分でコードを書いて新しいskillを作り、proactiveな自動化を実装し、ユーザーの好みのlong-term memoryを維持する。coding-agentのskillを通じてコーディング作業もする。外部LLM(Claude、DeepSeek、OpenAI GPTなど)に接続して使う構造なのでモデル中立的だ。

本当の魅力は インターフェース だ。IDEでもターミナルでもなくmessengerに住む — 通勤中にSignalで「昨日のあのバグを直してPRを上げて」と送る、という非同期・ambientなワークフローが可能になる。

自律性とサンドボックス 高い自律性を目指す — 「self-improving」と呼ばれる理由だ。ローカルで動くので、サンドボックス・permission管理はユーザーが自分で設計しなければならない。自律性が高いほど慎重なsetupが必要だ。

価格 オープンソースでローカル実行。ツールコストは無く、接続するLLMのAPIコストだけ払う。

弱み 純粋なコーディングハーネスとしての成熟度はClaude Code・Codex・Cursorに及ばない — 本質が汎用assistantだ。メッセージングインターフェースは速いインラインのコードレビューに不便だ。自律性が高いほどローカルのセキュリティ・permission設計の負担が大きい。2026年初頭時点、ガバナンス構造(非営利財団)がようやく定着しつつある。

一行まとめ: コーディングだけでなく生活全体を自動化するambientエージェントが欲しく、ローカルsetupを自分で管理できるならOpenClaw。最も実験的な選択。

8章 · 巨大比較表

6つのツール、7軸を一目で。すべての数値は2026年初頭時点で、速く変わる。

表だけで選んではいけない。表は候補を絞るためのツールであり、決定は次の2章で行う。

9章 · 意思決定マトリクス — どの状況にどのツール

ツールに「最高」は無い。「この状況に合う」があるだけだ。

状況1 · ソロIC、日常編集中心 エディタから手を離さず関数を書き小さいrefactorを速く回すのが1日の80%なら -> Cursor。ただしヘビーユーザーなら月額コストを先に見積もること。コストを厳しく管理したくターミナルが快適なら -> Aider(architectモード)。

状況2 · ソロIC、大規模refactor・探索中心 「このパターンがどこで壊れるか全部見つけて」「このモジュール全体を新APIにmigrateして」のようなマルチファイル・大規模作業が多いなら -> Claude Code。1Mコンテキストでchunkingなしで見る。Codex CLI も強力な代替だ。

状況3 · 非同期チケット作業 issueを投げて別の作業をしてPRを受け取りたいなら -> GitHub Copilot coding agent(既にGitHubに住んでいるとき)または OpenAI Codex cloud。messengerベースのambientワークフローに惹かれるなら -> OpenClaw。

状況4 · チーム、ガバナンスが重要 SSO、監査ログ、seat管理、ポリシーが必要なら -> GitHub Copilot が最も安全なデフォルト。Claude Codeもチーム適合度が高い。Cursorは可能だがコスト変動を、OpenClawはガバナンスの成熟度を見極めること。

状況5 · コストを1円まで管理 subscriptionなしでモデルのAPIコストだけ、しかもそれをarchitectモードで最小化したいなら -> Aider。OpenClaw もオープンソース・ローカルなのでツールコストはゼロ。

状況6 · モデル選択の自由が必要 特定のvendorに縛られたくなくGPT・Claude・Gemini・ローカルモデルを自由に切り替えたいなら -> Aider または OpenClaw。どちらもモデル中立。

現実的な組み合わせ 2026年のよくあるsetupは単一ツールではなく組み合わせだ — 日常編集はCursorまたはCopilot(IDE)、複雑なマルチファイル作業はClaude CodeまたはCodex(ターミナル)。一つのツールに宗教を持たず、作業タイプに合わせて手を変えること。

10章 · 自分のコードベースで評価する方法

レビュー記事・benchmark・leaderboardは出発点に過ぎない。自分のリポジトリでの性能が、唯一意味のあるデータ だ。次のprotocolで1〜2週間以内に検証すること。

ステップ1 · 代表タスクを5つ選ぶ 実際のbacklogから取ること。demo用のtoy問題ではなく、(a) 小さいバグ修正1つ、(b) 新機能1つ、(c) マルチファイルrefactor1つ、(d) テスト追加1つ、(e) 不慣れなコード領域の理解・説明1つ。この5つがあなたの仕事の分布を代表すべきだ。

ステップ2 · 同じタスクを候補2〜3個で走らせる 9章で候補を2〜3個に絞ったはずだ。同じタスク、同じprompt、同じ開始commitでそれぞれ走らせること。公平な比較はcontrolされた入力から生まれる。

ステップ3 · 定量指標を記録する タスクごとに測定。(a) 初回試行の精度(humanの介入なしで通ったか)、(b) wall-clock時間、(c) トークン/コスト、(d) 人による修正ラウンド数、(e) 最終差分のクリーンさ(不要な変更が混ざったか)。

ステップ4 · 定性シグナルを見る 数値が捉えられないもの。conventionに従うか、ガードレール(テスト・型・検証)を自分で追加するか、詰まったとき正直に詰まったと言うかそれらしい嘘を出すか、コンテキスト処理が滑らかか。

ステップ5 · friction costを計算する 承認ゲートが多すぎて流れが切れるか。少なすぎて不安か。setup・設定・MCP接続にかかった時間は。ツールを毎日使うときの累積frictionは、一度きりの印象より重要だ。

ステップ6 · 決め、3ヶ月後に再評価する このフィールドは速い。「今の最善」が6ヶ月後も最善である保証は無い。四半期ごとに短く再検証すること — 5タスクのprotocolなら半日で済む。

評価記録はシンプルな表で 大げさなツールは要らない。spreadsheet一枚で済む。一つのよくある罠だけ避けること — 第一印象に流されることだ。ツールAが最初のタスクを華麗に終えると、残り4つを甘く採点してしまう。だから 5つ全部走らせてから一括で採点 すること。評価記録の骨格はこれくらいシンプルだ。

タスク  | ツール | 初回通過 | wall (分) | コスト ($) | 修正ラウンド | 差分クリーンさ (1-5) | メモ
T1-bug  | A      | Y        | 4         | 0.12       | 0            | 5                    | conventionに従う
T1-bug  | B      | N        | 9         | 0.21       | 2            | 3                    | 無関係な変更が混入
...

5タスク x 候補3個 = 15行。全部埋めるとパターンが見える — どのツールがどのタイプに強いか。平均だけ見ず、variance も見ること。平均は良いがたまに大きく外すツールは信頼できない。

他人のbenchmarkは他人のコードベースの話だ。半日かけて自分のリポジトリで測れば、6ヶ月の誤ったツール選択を防げる。

エピローグ — チェックリスト・アンチパターン・次回予告

2026年春、AIコーディングエージェントのフィールドは収束した。6つのツールはそれぞれ違うワークフローのために存在し、「最高」は無い。あなたの仕事の分布に合うツールがあるだけだ。

ツール選択チェックリスト(順番通り)

1. 自分の仕事の分布をまず知る — 日常編集 vs 大規模refactor vs 非同期チケット、比率を書く。
2. surfaceを決める — CLI / IDE / cloud / messengerのうちワークフローに合うもの。
3. 必要な自律性レベルを定める — 補完で十分か、フルエージェントが必要か。
4. コンテキスト要求を見る — 大規模リポジトリを丸ごと見る必要のある作業が多いか。
5. MCP・ツールエコシステムの必要性を見極める — 社内ツールを接続しなければならないか。
6. 価格モデルを理解する — 定額 / トークン / seat、そしてヘビーユーザーの実コストを見積もる。
7. サンドボックス・permissionモデルを確認する — チームならガバナンス(SSO・監査ログ)まで。
8. 候補を2〜3個に絞る — 表は絞るツールであり、決定ツールではない。
9. 自分のコードベースで5タスクのprotocolで検証する — 定量+定性。
10. 決め、四半期ごとに半日ずつ再評価する — このフィールドは速い。

アンチパターン(やってはいけない)

• benchmark・leaderboardだけ見て決定 — 他人のコードベースの話だ。自分のリポジトリで測ること。
• surface priceだけ見て定額だと安心 — トークン・使用量ベースに移行中だ。ヘビーユーザーの実コストを見積もること。
• 一つのツールに宗教を持つ — 日常編集とマルチファイル作業は別のツールが良い。組み合わせを使うこと。
• 知らないコードベースにpermissionをフル開放 — 信頼が積み上がる前は承認ゲートを締めること。
• convention注入を省略 — CLAUDE.md や .aider.conf.yml のようなプロジェクトメモリなしで走らせると、エージェントはあなたのstyleを知らない。
• 自律性と追跡性を引き換えにする — 自律性が高いほど、Gitのcommit・差分レビュー・サンドボックスで追跡性を補強すること。
• 一度選んで二度と見ない — 四半期の再評価をスキップすると、6ヶ月後に時代遅れのツールを使っている。
• setup frictionを無視 — 一度きりの印象より、毎日の累積frictionの方が重要だ。

次回予告

次回はツール選択の次のステップ — エージェントワークフローエンジニアリング — を扱う。ツールを選んだら、次はそのツールをうまく使う方法だ。プロジェクトメモリ(CLAUDE.md、rule file)の設計、MCP serverを自分で作って社内ツールを接続すること、subagentで大きい作業を分解すること、そしてエージェントが作ったPRを安全にレビュー・mergeするチームのプロセスまで。ツールは始まりに過ぎず、ワークフローが結果を作る。