AIコーディングツールに、どこで時間を使うべきか

設定の罠

エンジニアはツールの最適化が好きだ。Claude Code のようなAIコーディングツールでは、skills やhooks、プロンプト設定を作り込む文化が広がっている。生産的な気がする — でも本当にそうだろうか？

問いは「設定が役に立つか」ではない。役に立つことはある。問いは「その時間を設定に使うのと、ものを作ることに使うのと、どちらのリターンが大きいか」だ。

Skills と CLAUDE.md の本質的な違い

設定には2つの種類がある。

プロジェクトの事実とルール（CLAUDE.md）：

• ディレクトリ構成
• コミットメッセージの規約
• 命名パターン
• チーム固有のワークフロー

これらは「プロジェクトについて何が真か」を記述している。モデルが変わっても更新は不要で、プロジェクト自体が変わったときだけ更新すればいい。

モデルの振る舞いを制御する指示（skills, hooks）：

• ステップバイステップの推論ガイド
• 出力フォーマットの強制
• モデルの弱点を補う回避策

これらは「モデルをどう操縦するか」を記述している。モデルの能力や癖が変われば壊れる。

Skills の賞味期限が短い理由

手作りの skills の価値は、2つの力によって時間とともに減少する。

1. モデルの進化で再調整が必要になる

今のモデルに合わせたプロンプトは、次のモデルでは不要になるか、むしろ邪魔になる。弱点を補う回避策は、弱点が修正されれば死んだコードになる。メンテナンスコストは継続的で予測できない。

2. プラットフォームに吸収される

多くのユーザーが skills として実装しているパターンは、プラットフォーム側が気づいて製品に組み込んでいく。jQuery → ネイティブ DOM API、webpack プラグイン → ブラウザ標準、と同じサイクルだ。カスタムの解決策は冗長になる。

より良い判断の枠組み

「AIツールをどう設定すべきか」ではなく、こう問う：

1. 繰り返し発生する摩擦か？ 毎週ぶつかる問題なら、軽い解決策（プロンプトテンプレート、CLAUDE.mdのルール）は投資に値する。
2. プロジェクトの事実か、モデルの回避策か？ 事実は安定する。回避策は一時的。投資の重みを変えるべき。
3. この時間はものを作ることに使った方が良くないか？ 設定に使う1時間は、アウトプットに使われなかった1時間だ。AIと一緒にものを出荷する経験 — いつ任せ、いつ介入し、どう改善するかの判断力 — こそが、ツールやモデルが変わっても残る力だ。

本当に複利で効くもの

長期的にAIツールの恩恵を最も受けるエンジニアは、最も洗練された設定を持つ人ではない。AIを使って最も多くのものを出荷した人だ。なぜなら、そこで培われる判断力はツール・モデル・プラットフォームをまたいで通用するから。

設定はメンテナンスコスト。アウトプットは複利。