Xで共有されていたThariq氏の投稿をきっかけに、Claude公式ブログ「The new rules of context engineering for Claude 5 generation models」を確認しました。記事の中心は、Claude Codeの新しいモデル向けにシステムプロンプトを大幅に簡素化した結果、評価を落とさずに動かせたという話です。
ここで重要なのは、「良いプロンプトを書く」だけではありません。AIが見る情報は、ユーザーの一言だけでなく、システムプロンプト、Skills、CLAUDE.md、記憶、参照ファイル、ツール説明などから組み上がります。つまり、AI活用の品質は、指示文そのものよりも、文脈の置き方で変わります。
この記事では、Claude公式ブログの内容をもとに、中小企業や制作現場がAIエージェントを使うとき、指示書・社内ルール・記憶・参照資料をどう整理すればよいかを実務目線でまとめます。
この記事を読むとわかること
- check_circleContext Engineeringとは何か
- check_circleClaude公式ブログが示した「昔の正解」と「今の正解」の違い
- check_circleCLAUDE.md、Skills、記憶、参照資料をどう分けるか
- check_circle中小企業がAIエージェントの精度を安定させる整理手順
向き：Claude CodeやAIエージェントを業務で使い始めた方、毎回プロンプトが長くなって困っている方
向かない：Claude 5系モデルのベンチマークだけを知りたい方。今回は運用設計の話です。
Context Engineeringとは、AIに渡す情報の置き方を設計すること
Claude公式ブログでは、ユーザーが入力するプロンプトは、Claudeが見る文脈の一部にすぎないと説明しています。実際には、システムプロンプト、Skills、CLAUDE.md、memory、参照ファイル、ツール定義などが組み合わさって、AIの判断材料になります。
この全体を設計する考え方が、Context Engineeringです。中小企業の業務に置き換えると、「AIに毎回長文でお願いする」のではなく、「常に守る方針」「必要なときだけ読む手順」「実物の参考資料」「人に戻す条件」を分けて置くことです。
| 要素 | 役割 | 業務での例 |
|---|---|---|
| System prompt | AIの基本姿勢と製品上の役割 | 安全方針、禁止操作、承認ゲート |
| CLAUDE.md | リポジトリの目的と注意点 | buildコマンド、公開手順、よくある落とし穴 |
| Skills | 必要なときだけ読む専門手順 | 記事作成、検証、請求書処理、SEO確認 |
| Memory | 継続的に効く好みや環境情報 | 担当者の文体、社内の承認ルール |
| References | 判断の根拠になる具体物 | HTML見本、テスト、仕様書、過去の良い成果物 |
ルールを増やすほど、AIは賢くなるとは限らない
Claude公式ブログで目を引くのは、Claude Codeのシステムプロンプトを80%以上削っても、コーディング評価で測定可能な低下がなかったという記述です。これは「プロンプトは短ければよい」という単純な話ではなく、古いルールが新しいモデルの判断を邪魔することがある、という示唆です。
たとえば、「コメントを書くな」「ドキュメントを作るな」といった強いルールは、ある場面では安全策になります。一方で、複雑な仕様や保守性が重要な場面では逆効果になります。公式記事では、新しいモデルには周辺コードのコメント密度、命名、書き方に合わせるよう伝える方向へ変えたと説明しています。
実務での置き換え
「絶対にこうしろ」を増やす前に、「周囲のルールを読んで合わせる」「迷ったら人に確認する」「公開や削除は承認を取る」のように、判断の向きと停止条件を渡す方が安定する場面があります。
昔の正解と、今の設計の違い
公式ブログは、過去に有効だったContext Engineeringの習慣が、今では「神話」になっているものがあると整理しています。中小企業のAI運用でも、そのまま使える考え方です。
| 以前の考え方 | 今の考え方 | 会社での意味 |
|---|---|---|
| 細かいルールを大量に渡す | AIに判断させる余地を残す | 目的、基準、承認条件を明確にする |
| 例をたくさん見せる | 使いやすい入力欄やツールを作る | 依頼フォーム、選択肢、状態管理を整える |
| 全部を最初に読ませる | 必要な時にだけ読ませる | 用途別Skillsや参照フォルダへ分ける |
| 同じ注意を何度も書く | 説明の置き場所を一つにする | プロンプト、ツール説明、社内資料の重複を減らす |
| 簡単な文章仕様だけ渡す | 実物に近い参照を渡す | HTML見本、テスト、良い成果物、評価表を使う |
CLAUDE.mdは、百科事典ではなく「迷いやすい場所の地図」にする
公式ブログでは、CLAUDE.mdは軽く保ち、リポジトリの目的と、AIがファイルを見ただけではわからない落とし穴に絞ることが勧められています。これは社内マニュアルにも近い話です。
AIはファイル構成やpackage.jsonのような見ればわかる情報を読めます。そこに「このリポジトリにはsrcがあります」と書くより、「このサイトはbuild後に生成物が更新される」「公開はmain pushで走る」「未承認の記事はpushしない」のような、見ただけでは事故りやすい情報を書く方が役に立ちます。
CLAUDE.mdに残したい情報
- ・公開、削除、送信など副作用のある操作の承認条件
- ・build/test/deployで必ず通すコマンド
- ・過去に事故った落とし穴と回避策
- ・生成物と手書きファイルの区別
- ・プロジェクト固有の表記、デザイン、禁止表現
Skillsは「全部入り」ではなく、用途別の小さな手順にする
公式ブログでは、Skillsを軽量なガイドとして扱い、長いものは複数ファイルへ分けることも勧めています。これは、AIに一冊の分厚いマニュアルを渡すより、必要なタイミングで必要なページを開かせる設計です。
たとえば、ブログ作成、SEO確認、公開前チェック、請求書確認、顧客返信文の作成を、すべて一つの巨大なプロンプトに入れると衝突します。用途別に分け、AIが必要になった時だけ読む方が、文脈が濁りにくくなります。
分けた方がよいもの
- ・記事作成フロー
- ・公開前検証
- ・顧客報告文の文体
- ・セキュリティ確認
- ・経理・契約まわりの確認
一つに混ぜると起きること
- ・関係ないルールまで毎回読む
- ・古い注意と新しい注意が衝突する
- ・モデルが確認に時間を使いすぎる
- ・どのルールが効いたか追いづらい
- ・人が更新するのを嫌になる
例よりも、インターフェースを整える
公式ブログは、以前はツール利用の具体例を見せることが有効だった一方、新しいモデルでは例が探索範囲を狭めることがあると説明しています。代わりに、ツールやファイルの設計そのものを表現力のあるものにする、という考え方です。
業務では、これは「AIに長い依頼例を渡す」より「入力フォームを整える」に近いです。依頼種別、公開範囲、承認者、締切、素材URL、NG事項を項目として渡せば、AIは迷いにくくなります。
依頼種別: ブログ下書き / 公開 / 修正 / 調査のみ
公開範囲: 下書きまで / 本番公開まで / 報告まで
承認条件: Yukiの明示承認後のみpush
素材URL: X投稿、公式ブログ、既存LP
NG事項: 未確認の価格断定、秘密情報の保存、画像の自動生成人間が毎回文章で補足していた前提を、選択肢や項目にするだけでも、AIエージェントの安定性は上がります。
導入手順：まずは今の指示書を削るところから
Context Engineeringは、新しいツールを買う前に始められます。まずは、AIに渡している指示を棚卸しし、重複・古いルール・常時不要な手順を分けるだけで十分です。
- 今AIに渡している長い指示を一つに集める。
チャット定型文、社内メモ、CLAUDE.md、Notion、スプレッドシートなどを確認します。 - 常に必要なものと、必要時だけ読むものに分ける。
公開承認や秘密情報ルールは常時、記事作成や経理確認は用途別にします。 - 重複している注意を一つに寄せる。
同じルールが別の表現で3箇所にあると、AIも人も更新漏れを起こします。 - 良い成果物を参照資料として保存する。
文章だけの説明より、実際のHTML、チェック表、テスト、過去の良い報告文の方が伝わります。 - 最後に承認ゲートを確認する。
公開、送信、削除、決済、顧客連絡は、人間に戻す条件を明確にします。
注意点：削ることと、放任することは違う
システムプロンプトを削れるという話は、AIに何でも自由にさせるという意味ではありません。むしろ、削るべきは重複、古い制約、場面に合わない細則です。残すべきは、会社の価値判断、セキュリティ、顧客情報、公開承認、責任範囲です。
中小企業でAIエージェントを使うなら、「AIに考えさせる余白」と「人に戻す境界」を同時に設計する必要があります。ここを分けずにルールだけ増やすと、AIは遅くなり、人は直す量が増え、結局使われなくなります。
削らずに残すべきルール
- ・秘密情報、個人情報、顧客情報の扱い
- ・本番公開、送信、削除、課金操作の承認条件
- ・法務、医療、金融など専門判断が必要な領域
- ・ブランドとして避ける表現や断定
- ・失敗時に人へ戻す条件
まとめ：AIへの指示は、長さより配置で決まる
- ・Claude公式ブログは、AIが見る文脈全体を設計するContext Engineeringの重要性を示しています。
- ・Anthropicは、新しいモデル向けにClaude Codeのシステムプロンプトを大幅に簡素化したと説明しています。
- ・大量のルールを常時読ませるより、常時ルール、用途別Skills、記憶、参照資料へ分ける方が運用しやすくなります。
- ・CLAUDE.mdは百科事典ではなく、AIが迷いやすい落とし穴の地図として使うのが現実的です。
- ・削るべきは重複や古い細則であり、セキュリティや公開承認の境界はむしろ明確に残すべきです。
AIエージェントの精度を上げるために、毎回プロンプトを足していく必要はありません。むしろ、どの情報を常に見せ、どの情報を必要なときだけ読ませ、どこで人に戻すのか。その整理ができている会社ほど、AIを「試す」段階から「任せて回す」段階へ進みやすくなります。
参考リンク
- 公式: The new rules of context engineering for Claude 5 generation models（Claude / 2026年7月24日）
- 投稿: Thariq氏のX投稿（X / 2026年7月24日）
- 関連記事: Claude Codeの検証ループとは？｜手作業チェックをSkills化してAIに修正まで回させる考え方
AIエージェントの指示書を、業務に合わせて整理しませんか
i-Styleでは、AI導入の相談だけでなく、プロンプト、社内ルール、承認フロー、チェック手順をAIエージェントが使いやすい形に整理する支援も行っています。まずは、今使っている指示書や業務フローの棚卸しから相談できます。
お問い合わせページへarrow_forward問い合わせ前に、i-Styleサポートデスクbotでも相談できます
「自社のAI指示書をどう分けるべきか」「CLAUDE.mdやSkillsのような仕組みを業務に置き換えるなら何から始めるべきか」など、軽い確認はサポートデスクbotでも相談できます。
i-Styleサポートデスクbotで聞くarrow_forward