最近の高性能 AI モデルへの指示は、なぜ簡潔にするとよいのか？ 

こんにちは、ゼノクリース合同会社の齋藤です。このコラム記事では、企業の AI 活用や AI の最新情報について紹介しています。 

9 月 1 日に Claude Fable 5.1 が、続いて 9 月 3 日に GPT-6 Astra が登場しました。新モデルを試す際は、性能だけでなく、公式のプロンプトガイドにも注目してみてください。「以前のモデル向けに書いた指示が、今は邪魔になる」という、具体的な例が紹介されています。 

Anthropic は、どんな指示を削ったのか 

Anthropic は 7 月 24 日の Claude 5 世代向けのコンテキスト設計に関する記事で、Opus 5・Fable 5 向けの Claude Code のシステムプロンプトを 80% 超削減しても、コーディング評価では測定可能な性能低下がなかったと報告しました。 

実際の書き換え内容を見てみると、以前はコード内のコメントを原則禁止し、書く場合も短い 1 行までに制限していました。 

変更後は、周囲のコードに合わせてコメントの量や命名などを揃える方針にしています。また、常設していたコードレビューや検証の手順は、必要なときに読み込む Skills へ移しました。 

前者のコメントの例で言えば、コメントを増やしすぎた過去の失敗を防ぐ指示が、複雑な処理にも説明を書かせないという制約になってしまいます。 

私としては、エンジニア歴が浅い時に作ったシステムのコーディング規約などを後から見直すと直したほうが良い箇所が出てくるのと同じように、モデル更新時にも、過去のモデル向けに作ったルールを点検する必要があると考えています。 

Astra が止まるときは、読んだ指示を調べる 

OpenAI の Astra 向けガイドでも、Skills や AGENTS.md などの指示に敏感になっており、その中の曖昧な指示・矛盾した指示によって、モデルが作業を止める場合があると説明されています。 

指示をよく守り、様々な手段で目的の遂行に向かって突き進めるようになった分、古い指示の影響も受けやすいのです。 

AI 自身に、その時の作業を停止した原因になった SKILL.md のファイルと該当する指示を出してもらい、明記された要件なのか、明記されていないがそう解釈しただけなのかを区別させるプロンプトも紹介されています。 

例えば、修正を依頼したのに確認待ちで止まる場合、「もっと自律的に動いて」と追加する前に、読み込んだファイルに「コードを変更する前に必ず許可を取る」と残っていないかを調べる。止まった理由が指示の衝突なら、新しい指示を出す前に元の適用条件を整理するということです。 

一方で、削ってはいけない「検索の条件」もある 

Fable 5.1 の公式ガイドには、逆の注意もあります。 

effort（推論の深さ）が最も低い「low」の場合、Fable 5 より検索・取得ツールを呼ぶ頻度が下がり、記憶に基づいて答えやすいとされており、該当する処理だけ effort を上げるか、検証を促す指示を加える方法が示されています。 

この点は、社内情報を検索して回答する RAG でも見逃せません。例えば「出張の宿泊費上限」を聞かれたとき、現行の社内規程を検索していなければ、業務で使える回答ではありません。 

注意深くモデルに指示をするなら、以下のようなルール設定も必要になるかもしれません。 

社内規程・金額・申請期限について答える際は、現行の社内資料を検索する。文書名・改訂日・該当箇所を示し、確認できなければ推測で埋めない。 

まとめ 

細かい話を書いてきましたが、一言で表すと「モデルの不得意を補っていた指示は見直す、自社の業務条件と根拠の確認は残す」という区別で考えると良いと思います。 

私も開発に携わっている GMOプライム・ストラテジーの GMO AI RAG は、社内文書に基づく回答ができるよう、さまざまな工夫を取り入れています。 

GMOプライム・ストラテジーでは、こうした企業の AI 基盤づくりから運用までを支援するサービスを提供しています。ぜひご活用いただき、AI 活用のきっかけにしてみてください。 

• GMO AI RAG（社内文書に基づいて AI が回答する法人向け RAG。MCP サーバーで Claude 等の AI エージェントと連携） 

• 法人向け RAG「GMO AI RAG」提供開始（既存ストレージとの連携などを含む主な特長）