Polaris.AI テックブログ、最新記事公開のお知らせです。今回は、前編で紹介した作り込みが実務で何を変えたのか、そしてモデルの世代交代でその設定がどうなったのかをテーマにした実務記事です。Claude Code 魔改造記の後編にあたりますが、後編だけでも読める構成としています。いちばん価値が出たのは、新規開発でもテストでもなく運用保守でした。ある朝のアクセス障害では、シークレット管理サービスへの 403 Forbidden を手がかりに真因が認証キーの期限切れであることを特定し、復旧手順を提示させたうえで人間が承認して実行、発生から1時間以内に復旧しています。障害の切り分けは勘と経験に依存する職人技でしたが、担当者を選ばず初動に入れる仕組みに近づきました。あわせて、CLAUDE.md に ISMS の要件を記述していることで調査や操作の記録が監査ログとして自然に積み上がること、月次の運用報告書が実ログから自動で組み上がることも紹介しています。もう一つの主題は、積み上げた設定の賞味期限です。2026年8月に Claude Opus 5 へ切り替えたところ、それまで書き足してきた CLAUDE.md の記述の一部が、役に立たなくなるどころか逆効果になっていました。魔改造の少なくない部分が「そのモデルの弱点を埋める指示」だったためです。委譲を促す記述は抑制側へ反転し、検証を指示する記述は削除対象となり、一方で ISMS 由来の人間承認ゲートは据え置きとしました。設定は積み上がる資産ではなく、モデルバージョンに紐づく在庫である。そう捉え直したうえで、各ルールを「モデルが知り得ない前提を伝えているか」「モデルの弱点を埋めているか」で分類する、棚卸しの基準を示しています。顧客の現場データを預かる事業では、「AI で速くなりました」だけでは信頼になりません。不可逆操作は人間が承認する、機微なデータは外部モデルに送らない、操作は監査ログに残る。この統制とセットで初めて、AI 活用は顧客への約束になると考えています。記事の後半では、サブエージェントへの機能の集めすぎ、静的な禁止リストのすり抜け、永続メモリの肥大化といった、うまくいかなかった点もそのまま残しています。AI コーディングエージェントの業務導入を進めている方、すでに設定を積み上げていてモデル更新への対応に悩まれている方、そして AI にどこまで任せ、どこで人間が握り続けるかの設計にご関心のある方（SRE・セキュリティ担当を含む）にご覧いただける内容です。本記事をもって、前後編の完結となります。ぜひご一読ください。▶ 最新記事はこちら（後編）https://zenn.dev/polarisai_blog/articles/72b0214231121f▶ あわせてお読みいただけます（前編）https://zenn.dev/polarisai_blog/articles/4464a734bb53bf今後も Polaris.AI では、AI 技術の最前線や実務ノウハウを継続的に発信してまいります。新着記事のお知らせを受け取っていただけますので、ご関心をお持ちいただけましたら、Zenn にてフォローいただけますと幸いです。▶ Polaris.AI テックブログ トップページhttps://zenn.dev/p/polarisai_blog今後とも Polaris.AI の取り組みにご注目いただければ幸いです