ツールを減らし、判断を増やす：AIニュースの取捨選択術

本当の問題は情報ではない

毎朝、メールボックスには新しいモデル、新しいMCPサーバー、「すべてを変える」新しいエージェントが届く。ニュースレターは溜まり、リンクも増え続ける。すべてを読むのは不可能だ。すべてを試すのはもっと悪い。

やがて気づいた。希少な資源は情報ではなく、判断だった。何を取り入れ、何を見送り、何を外すのか。

私は毎日、複数のコーディングエージェント（Claude Code、Copilot CLI）を自分のツール群（チケット、タスク、メール、NAS）につないで仕事をしている。この環境は常に変化する。役に立つ状態を保つには、情報収集のプログラムではなく、シンプルなフィルターが必要だった。

失敗の2つのパターン

1つ目は、取り入れすぎること。残したツールはすべて恒久的な管理対象になる。ずれていく設定、更新が必要なトークン、最悪のタイミングでデバッグすべきものがまた1つ増える。コストは毎月かかる。メリットは、多くの場合一度きりだ。

2つ目は、何も取り入れないこと。すると環境は静かに劣化していく。固定したモデルIDはベンダーによって廃止され、デフォルト値は当初の意図と合わなくなり、それでも何のエラーも出ない。

どちらの失敗も高くつく。2つ目のほうがたちが悪い。目に見えないからだ。

「より良い」とは何か

ツールを評価する前に、何を求めているのかを知っておく必要がある。以下が私の基準で、優先度の高い順に並べている。2つの基準がぶつかったときは、上位の基準が勝つ。

1. 正確さ。間違えるのが速くなったエージェントは、良くなったとは言えない。
2. セキュリティとプライバシー。何がマシンの外に出て、誰に渡るのか。
3. トークン単価ではなく、完了したタスクあたりのコスト。3回やり直しが必要な安いモデルは、安くない。
4. 可逆性。元に戻すのにどれくらいかかるか。
5. 複雑さ。可動部品、設定、シークレットの数。
6. 速度。重要ではあるが、6つの中で最も優先度が低い。

ベンダーの発表を見てほしい。語られているのは主にコストと速度だ。それはまさに、ここで最も重要度の低い2つの基準である。

4つの問いによるフィルター

入ってくるものはすべて同じフィルターを通す。リンクでも、ツールでも、モデルでも、ワークフローのアイデアでも。最初の「いいえ」で止める。そしてデフォルトの答えは「いいえ」だ。証明する責任は新しいもの側にある。

1. 具体的な痛みはあるか？実際のインシデント、繰り返す摩擦、失われた1時間。「面白そう」はブックマークに値するが、変更には値しない。
2. 何かを置き換えるのか、それとも上乗せになるのか？置き換えなら対等なスタートだ。上乗せなら、それを永遠に抱え続けるコストを上回らなければならない。
3. 1時間以内に元に戻せるか？取り消しに移行作業が必要なら、それはもう試行ではない。コミットメントだ。
4. 1回のセッションで試せるか？評価自体がプロジェクトになるなら、それはチケットにする。仕分けの途中で始めることはしない。

フィルターを通らなかったものも捨てはしない。リーディングリストに入れるか、チケットにする。ただ、今日は何も変えないというだけだ。

すべての証拠が同じ重みではない

4つの問いは変わらない。しかし求める証拠のレベルは、変更の種類によって異なる。

• モデルの切り替え（次のバージョンへの移行）：要求水準は低い。価格と提供状況を確認する。1行で元に戻せる。
• プロンプトやスキルの変更：要求水準は中程度。作り物の例ではなく、実際のタスクでのビフォー・アフター。
• ワークフローの変更：要求水準は中程度。エンドツーエンドで一度通しで実行し、二度と議論しなくて済むようにルールを書き残す。
• ツール、MCPサーバー、依存関係の追加：要求水準は高い。既存の何でもカバーできない痛みと、撤去計画が必要。

積み上がっていくのは、この最後のカテゴリーだ。あるツールが生んだ問題を回避するために別のツールを足す。一つひとつの判断は単体では妥当に見えても、これこそが環境を劣化させる最もよくあるパターンだ。

誰も気づかなかった2つの障害

9月、自分の起動スクリプトを読み返していて、2つのバグを見つけた。どちらもエラーは出していなかった。

1つ目：私のClaude Codeランチャーは、デフォルトで「opusplan」モードを使っていた。意図は「最良のモデルを使う」だった。実際には、Opusはプランニングモードでしか動いておらず、それ以外はすべてより小さなモデルが処理していた。何か月もの間。私はこの値を「opus」エイリアスに置き換えた。今では、新しいバージョンが出るたびに何もしなくても追従する。

2つ目：Copilot CLIのランチャーは、ベンダーがすでに廃止したモデルIDを指していた。デフォルト値は死んでいたのだ。IDを1つずつ試して、ようやく気づいた。

教訓は「モデル名をもっと頻繁に確認しよう」ではない。有効期限のない固定値は、期限が来るのを待っているバグだということだ。

外すことも仕事のうち

導入には注目が集まる。撤去にはほとんど集まらない。しかし、壊れる原因が潜んでいるのはそこだ。

私のルール：固定したバージョン番号より、最新版に追従するエイリアスを優先する。エイリアスが存在しない場合は、固定値を定期的にテストする。固定するのは、再現性が本当に必要な場所だけだ。

これはドキュメントにも当てはまる。コンテキストファイルに書いたバージョン番号は次のアップデートで間違いになり、誰も再確認しない。ツール名を書き、そのバージョンを確認する方法を示すほうがいい。

そして、固定値が1か所だけに存在することはまれだ。メモリ用のMCPサーバーを外した日、私はきちんとアーカイブした…が、インストールガイドにはまだ載っていた。それ以来、ツールの撤去はリポジトリ全体でその名前を検索するところから始め、すべての参照を修正してから「完了」と言うようにしている。

私が避けている落とし穴

• ベンチマークを追いかけること。ベンチマークが測っているのは他人のワークロードだ。自分のタスクで測っていないなら、改善とは呼ばない。
• すでに入っているツールを学ぶのを避けるために、ツールを乗り換えること。
• エイリアスがあるのに、反射的にバージョンを固定すること。
• 撤去計画なしに導入すること。「どうやって元に戻すのか」に答えがないなら、それは試行ではない。
• すでに下した判断を毎月蒸し返すこと。記録された判断は、新しい証拠が出るまで有効だ。

新しい儀式は増やさない

このフィルターのために会議やダッシュボードを増やすことはない。すでに回っている仕組みに組み込むだけだ。メールとタスクの仕分けはもともと入ってくるものを分類している。AIニュースはそのカテゴリーが1つ増えただけだ。パッケージとコンテナの定期監査では、古くなったモデルやツールも確認するようにした。

四半期に一度、あるいはモデルの新世代が出るたびに、短いレビューを行う。固定しているIDをすべてテストし、最近の変更が基準の優先順位を守っていたかを確認し、関連する未解決チケットをクローズするか絞り込む。

AIエージェント環境の継続的改善は、結局のところ、どんなシステムの継続的改善とも変わらない。難しいのは足すことではない。「いいえ」と言えること、そして外すことを忘れないことだ。