Every
Opus 5を使いこなす：新モデル時代の指示設計と組織対応
要点
- Opus 5は高い能力を持つが実運用で「扱いにくい」。フローが細切れになりやすく、繰り返し指示が必要になり、従来モデルより管理コストが高い
- ワークフロー改善：冒頭で全指示を与えて放置し、成果物が返ってきたら説明は読まず結果だけ評価する。生の出力ハンドリング能力の向上が効く
- 「プロンプト負債」：旧モデル向けに書かれた skill や agent 指示が新モデルで誤動作する。有効性は試行錯誤が必須
- 故意か結果かは別として、Opus 5 は「エージェント間通信」を前提とした設計に見える。人間向けとは異なるコミュニケーション層を想定している
- AI デモは video game に偏る傾向。視覚的インパクトと技術的要求度の高さが SNS 拡散に有利。ただし実務性との乖離も大きい
編集部の考察
記事が挙げる具体例は、旧モデル向けに書かれた skill や agent 指示が Opus 5 では誤動作し、原因不明のまま「なぜか某 workflow が止まった」という障害として現場に現れるというものだ。著者自身も「有効性は試行錯誤でしか確認できない」と認めている。これを自社に置き換えると、社内に skill・プロンプトテンプレート・agent 定義が何十本と存在する組織ほど、モデル更新のたびに「どれが壊れているか誰も把握していない」状態でリリースを迎えるリスクを抱えていることになる。しかも壊れ方が「エラーで落ちる」のではなく「もっともらしいが質の落ちた出力を返す」ため、発見が遅れやすい。ここで経営が決めるべきは「棚卸しをやるかどうか」ではなく、モデル更新時に誰が・どの範囲の skill を・どのタイミングで再検証する責任を持つのかという運用オーナーシップを、ベンダーのリリースサイクルに合わせて事前に割り当てておくことだ。
原文より
“Skills preserve assumptions about the model they were written for. Try them freely but treat each new model release as a reason to prune.”
本記事は原文ニュースレターの独自キュレーション・考察であり、翻訳ではありません。引用部分の著作権は原著者に帰属します。