Behind the Craft
新しい AI モデル導入時にシステムプロンプトを 80% 削減する理由
Claude Code チームの Thariq Shihipar とのポッドキャスト・インタビュー。新モデルに対応するときの指示体系の見直し、計画段階での AI との対話、ループと並行処理によるワークフロー効率化を軸に展開。
要点
- 新モデル導入時は指示削減が鍵: モデル性能が向上すれば、硬い制約ルールや具体例は むしろ制約になるため、指示を 80% 削減。アップグレード時に CLAUDE.md や skills の点検が必須
- 計画段階で「未知数を除去」: 建築に入る前に Claude と対話して問題を洗い出し、人間が手作業で検証。事前計画こそが品質を大きく左右する
- /goal は「検証可能なゴール」に限定: 「素晴らしいゲームを作れ」では失敗。「1080p で 30秒のポーランド版動画をレンダリング完了」のような状態が必須
- Slack を中核に複数エージェント並行実行: creator と verifier を分離し、Slack 経由でタスク管理。スケーラビリティと可観測性を両立
- AI の書いたコードから学ぶ姿勢: AI が実装してくれるからこそ、コードを丹念に読んで技術力を高める逆転の学び
編集部の考察
Thariq が新モデル登場時にやっているのは「CLAUDE.md やスキル定義の指示を 80% 削除する」という具体的な作業だ。これは裏を返せば、自社の AI 利用ガイドライン・プロンプトテンプレート・業務マニュアルが「古いモデルの弱点を補うために積み上げた制約」でできている可能性が高い、ということを意味する。新モデルへの切り替えは多くの組織で「対応表の更新」「使用申請の再承認」程度で止まっており、既存ルールそのものを疑う工程がない。自社に置き換えると、決めるべきは「モデルアップグレードのたびに社内ガイドラインを棚卸しする担当者・頻度・トリガー条件」を誰が持つかだ。四半期ごとの利用規程レビューに紐づけるのか、モデルリリースごとに都度レビューするのか、そもそも棚卸しを担う役割（法務・情報システム・現場マネージャーのどこに置くか）が未定義の組織は多い。ここを放置すると、モデル性能は上がっているのに、古い制約ルールが足かせになって ROI が頭打ちになるという逆転現象が起きる。ガバナンスの論点は「ルールを増やすかどうか」ではなく、「ルールを定期的に削る仕組みを持っているか」に移っている。
原文より
“When a better AI model is released, the first thing you should try is to remove instructions. When a new model is released, audit your CLAUDE.md and skills to remove deterministic instructions. Plan with Claude to discover and remove unknowns. Before building his one-shot video workflow, Thariq asked Claude to explain how voice transcription tools like Whisper could fail.”
本記事は原文ニュースレターの独自キュレーション・考察であり、翻訳ではありません。引用部分の著作権は原著者に帰属します。