作り込んだAIスキルを捨てた話——生成AI内製化の限界はどこにあるか
Claude Codeに「統括役・計画役・実行役」の3役を作り込みました。方針を決める役、手順に落とす役、手を動かす役。指示の渡し方まで書き込んで、しばらくうまく動いていました。
ところがモデルが更新されたあと、計画役を挟まなくても同じ仕事が進むようになりました。型がAIを助けるどころか、わざわざ遠回りさせていた。削除しました。
Skillの元になるプロンプトそのものにも、同じことが起きています。なぜ効いていた型が邪魔になるのか、順に書きます。
型が遠回りになった日
3役の型を作った動機は単純です。前のモデルにいきなり作業を投げると、手順が飛びました。先に計画役へ渡して段取りを書かせ、それを実行役に渡すと、抜けが減りました。効果があったので、役割ごとの指示をSkillに固定しました。
新しいモデルは最初から筋の通った手順で動きます。それでもSkillは「まず計画役に渡してから実行役へ」と要求します。
図1：モデルの弱点を補うために作った型は、その弱点が消えた瞬間に遠回りへ変わる。
やめた判断は、性能への不満ではありません。モデルが更新されるたびに指示がまだ有効かを確かめ、書き直し、次の更新でまた確かめる。この往復が、型で節約できる時間を超えました。
なお、この記事で扱う「内製化」はプロンプトやAIスキル、運用手順を自社で作って維持し続ける範囲の話です。モデルやツールを自社開発する話ではありません。
決定打も来ました。公式のサブエージェント機能が同じ役割分担を素直にこなすようになったのです。私たちの型は公式機能に吸収された側でした。
昨日の定石が、今日は400エラーになる
自分たちの設計ミスだったのかとも考えました。ところが各社の公式ドキュメントを読むと、同じことが起きています。
| かつての定石 | いまの扱い |
|---|---|
| 「step by stepで考えて」と指示する | 推論モデルでは不要。内部で推論するため指示は要らない（OpenAI） |
| prefillで応答の冒頭を書いて誘導する | Claude 4.6以降はサポート終了。送ると400エラー（Anthropic） |
budget_tokensで思考量を数値で制御する | 非推奨。Claude 4.7以降は400エラー。モデル自身が思考量を決める方式へ（同上） |
prefillの廃止理由として、Anthropicは「モデルの知能と指示追従が向上し、prefillの用途の多くはもう必要なくなった」と書いています。3つ目のbudget_tokensはAIにどれだけ考えさせるかを人間が数値で調整するパラメータでした。いまはeffortという粗い設定を渡し、細かい配分はモデルが決めます。人間が丁寧にチューニングしていた部分ほど、先に消えました。
もう一つ、同じページのClaude Opus 4.6についての節に、過剰な指示を削るよう促す記述があります。以前のモデルで発動しにくかったツールがこのモデルでは適切に発動しやすくなっており、「念のためこのツールを使え」のような指示は過剰な発動を招く、という趣旨です。
つまり古い指示は、無駄になるだけでは済みません。新しいモデルの邪魔をします。 型で強く縛るほど、進歩の恩恵を受け取りにくくなります。
ここで自分たちの勘違いも書いておきます。「あなたは優秀な編集者です」という前置き。私たちはチャットで毎回書くのをやめていました。指示が具体的なら名乗らせなくても結果は変わらない、という感触があったからです。「ペルソナ設定はもう古い」と思っていました。
半分は当たっていました。役割名を与えるだけで事実問題の正答率が上がるとは限りません。4つのオープンモデル群に162の役割を与えてMMLUの2,410問で検証した研究では、ペルソナなしと比べて全体の性能は改善せず、役割ごとの効果は大きく予測しにくいと報告されています（Personas in System Prompts Do Not Improve Performances of Large Language Models）。「弁護士です」と名乗らせれば法律に強くなる、という期待は持てません。
もう半分は外れでした。Anthropicの現行ドキュメントはいまも役割設定を有効な技法として挙げています。ただし効くと書いてあるのは振る舞いと文体です。「短く」「箇条書きで」「事務的に」といった出力の形を揃える用途では、現役の道具のままです。
つまりペルソナ設定は退場したのではなく、効く方向が限定されていただけでした。上の3つには、それぞれ不要・サポート終了・非推奨という現行の扱いが公式に明記されています。ペルソナ設定にはそうした記述がありません。同じ「もう要らないのでは」という手応えから出発しても、片方は確かめられる話で、片方は私たちの読み違いでした。古びたかどうかを決めるのは実感ではなく、公式の記述と検証結果です。
残すべき指示と、捨てるべき指示
区別そのものは難しくありません。「まず計画役に渡せ」はモデルが賢くなれば消せます。一方、「この用語は業界では別の意味で使う」のような社内の事情はモデルがどれだけ賢くなっても社外からは分かりません。
前者はモデルの弱点を補う指示で、後者はモデルが知りようのない知識です。Skillに書き込む価値があるのは後者だけです。
この判断を毎回するために、知識を2つの軸で仕分けています。
図2：右下だけが投資に値する領域。自社のSkillを1本ずつ置いてみる。
置いてみると発見があります。右下のつもりで書いたものが、実は左上だった。3役の型がまさにそれでした。
判断に迷ったら、書こうとしている一文にこう問います。「次のモデルがこの弱点を克服したら、この指示は意味を失うか」。失うなら、固定せずその都度渡します。
次のモデルが出た日に、誰が捨てるのか
内製化の壁は技術力ではありません。捨て続ける手間です。
Skillが増えるほど、モデル更新日の性格が変わります。新機能を試す日ではなく、古い指示を棚卸しする日になります。私たちは社内でこの日をそう呼ぶようになりました。手元にあるLP量産用のSkillは本体と参照ファイルを合わせて487行あります。この分量を、モデルが変わるたびに読み返して真偽を判定する。作るときの高揚感と、この作業の地味さは釣り合いません。
これは支援業に特有の話ではありません。去年の社内勉強会で配ったプロンプト集、業務マニュアルに貼り付けたAIへの指示文、ツールに登録したままの定型プロンプト。あれも同じ在庫です。最後に中身を読み返したのはいつでしょうか。
公式が代わりに実装できる機能に投資すると、自社に残るのは保守作業だけです。3役の型で起きたのはそれでした。
判断基準として最初に置いたのは「半年後もメンテする覚悟があるか」でした。いまは使っていません。半年が長すぎるからです。エンジニアでなくても実務で普通に使えるようになったのは私たちの感覚で2026年2月ごろ、Opus 4.6が出てきたタイミングでした。この記事を書いている2026年8月まで、まだ半年。「半年メンテする覚悟」を問うのは、このツールの実用史の全長を覚悟しろと言うのに近い。
だから基準を変えました。「次のモデルリリースを跨いで生き残るか」。
そして、限界はここに現れます。次のモデルが出たとき、誰が古い指示を点検して捨てるのか。担当者も時間も決まっていないなら、そのSkillはもう内製できていません。作った時点でこの空白には気づけません。
外注するなら、捨てる仕事まで
手応えのあった型が公式機能に吸収されるまで、1年もかかりませんでした。そこから残った教訓はひとつです。価値があるのはSkillファイルではなく、それを捨て続けられる担当と時間のほうでした。
AI導入の支援先を選ぶなら、納品物がSkillファイルなのか、運用と定着なのかを見てください。
モデル依存の指示を多く含むファイルを納品して終わり、その後の見直しが誰の担当にもなっていない。その納品物は次のモデルが出た日から負債に変わります。聞き方は簡単です。「導入から数ヶ月後、次のモデルが出たタイミングで、また一緒に見直してもらえますか」。
私たち「AI担当くん」はSkillファイルを納品して終わりにしません。次のモデルが出たら、現場で使っている指示を一緒に点検し、不要なものを捨てます。残すのはお客様にしか分からないルールと経緯です。
各社の公式ドキュメントを追い続けるのは本業を持つ会社に現実的ではありません。どの手法が非推奨になり、どのパラメータがエラーになったか。この追跡もこちらで引き受けて、「その指示はもう外していいです」と言える状態を保ちます。
自社でやり切る道もあります。その場合はモデル更新日を誰かの棚卸し業務として職務に書いてください。それができる会社に、外注は要りません。
次のモデルが出た日に、誰が古い指示を捨てるのか。外に頼むなら、そこまで聞いてください。
生成AIの基礎から学びたい方は生成AI学習ガイド、業務での実践を体験したい方は実践ワークショップもあわせてどうぞ。