AI を業務で使い始めると、同じ補足を毎回プロンプトに書いている自分に気づく瞬間があります。「TypeScript で答えてください」「英語で返さないでください」「コードはコピペで動く形で」と毎回打ち直し、それでも翌日にはまた同じことを指示している、という状態です。プロンプトの言い回しを工夫しても根本が直らないのは、技法ではなく構造の問題が残っているからです。
ChatGPT を使い倒している方でも、Custom Instructions が空欄のままになっているケースは少なくありません。Claude Code を導入したエンジニアでも、CLAUDE.md・.claude/settings.json・.claude/skills/ を整備せず、毎ターンの会話プロンプトだけで運用していることがあります。指示は本来、プロンプト以外にも複数の置き場所があり、置き場所を間違えると毎回同じ補足を書く羽目になります。
本記事では AI への指示を「プロンプト術」として扱わず、ファイル固定・コマンド呼び出し・UI 設定・会話プロンプトという 4 層に整理します。Claude Code を主役にして、ChatGPT と OpenAI Agents SDK で同じ 4 層がどう実装されているかを横断比較し、最後に「常に守らせたいなら層 1」「再現したい操作なら層 2」「禁止したいツールなら層 3」という置き場所判定軸まで落とします。
想定読者は、AI を業務で使っているが毎回同じ補足を書いている状態に詰まっているエンジニア・個人事業者です。プロンプトを工夫し続けて疲弊する前に、上位の指示層を一度設計しておけば、層 4 の会話で書くべき量は劇的に減ります。
この記事を読み終えると、自分の業務で「どの指示をどこに置けばいいか」を判断する地図が手に入ります。
プロンプトを工夫しているのに同じ指示を毎回書いている人へ
プロンプトの言い回しを工夫しても、AI が同じ補足を毎回必要としている状況は、技法ではなく構造の問題です。本章では、プロンプト一発で解決しようとして詰まる読者像と、その背後にある「上位の指示層が設計されていない」という構造を切り分けます。
「AI に効くプロンプト」を覚えても解けない構造
プロンプトのテンプレや「魔法の一言」は、その場のターンを良くするだけで、同じ依頼を翌日に投げるとまた一から書くことになります。なぜ一発技で解けないのかを構造側から見ていきます。
AI ツールはセッションが切れると会話履歴を引き継ぎません。これは LLM の仕組み上、毎ターンのメッセージ全文を毎回モデルに渡し直すためです。「以前お伝えしたとおり」「先ほどの規約に従って」と書いても、新しいセッションでは何の効力もありません。
プロンプトテクニックは、その 1 ターン内で AI の出力を狙った方向に向けるための道具です。永続化はプロンプトテクニックの役割ではなく、別の層の責務です。プロンプト工夫だけで戦っていると、永続化されるべき指示まで毎ターンの会話に書き続けることになり、結果として「同じ補足を毎回書く」状態が固定化します。
上位の指示層を設計していないから起きていること
CLAUDE.md・Custom Instructions・settings.json を空欄のまま運用すると、AI が「あなたのプロジェクト規約」を知らないまま毎ターン会話を始めます。空欄が何を引き起こすかを 3 点で並べます。
1 つ目は、毎ターンの補足プロンプトが必要になることです。プロジェクトで使うフレームワーク・コーディング規約・出力フォーマットが上位層に固定されていないため、新しいセッションを開くたびに最初から伝えることになります。
2 つ目は、危険な操作が誤って実行されることです。Claude Code の .claude/settings.json で permissions.deny を空のままにしていると、本番ブランチへの破壊的なコマンドも「CLAUDE.md で禁止と書いてあるはず」という前提だけで止めようとすることになります。これは仕組み上止まりません。
3 つ目は、同じワークフローを毎回手動で説明することです。「ブログを下書きしてください」「レビューしてください」のような反復作業を、毎回プロンプトに手順を書き起こして渡している状態は、層 2 のコマンド呼び出しが未整備な典型サインです。
「指示層」という言葉について
「指示層」は本記事独自の整理軸で、公式ドキュメントには出てきません。ファイル固定・コマンド・UI 設定・会話プロンプトを横断して扱うために置いた言葉として、本稿で使います。
AI ツールごとに「Custom Instructions」「CLAUDE.md」「Agent(instructions=…)」と呼び方は違いますが、機能としては「セッション開始時に毎回ロードされる永続的な行動指示」という同じ層にあります。本記事ではこの整理軸で 3 ツールを横断します。
そもそも AI への指示を「プロンプトだけではない」と捉えるためには、AI の使い方を 3 種類に分けて見直すと整理しやすいと思います。サブスク型・API 型・ローカル LLM の使い分けについては ChatGPT月額・APIとローカルLLM、何が違うのか：AIの使い方は3種類ある で扱っているので、AI ツール選定の前提として併せて参照してください。
AI への指示は 4 層に分かれる
主要な AI ツールの「指示の入り口」は、ロードタイミングとスコープで 4 つに整理できます。本章では各層の代表例とどのタイミングで AI に効くかを並べ、後の章で各ツールに当てはめる土台を作ります。
層 1: ファイルに固定する指示
セッション開始時に毎回ロードされる永続的な行動指示の層です。Claude Code の CLAUDE.md、ChatGPT の Custom Instructions、OpenAI Agents SDK の instructions= が並びます。
層 1 の特徴は「毎回自動で適用される」「人間が書く」「固定」という 3 点です。スコープは Claude Code であれば配置場所 (プロジェクト / ユーザー全体 / ローカル / 組織 managed) で決まり、ChatGPT であれば全会話に対して、Agents SDK であればその Agent インスタンスに対して適用されます。
層 2: コマンドとして呼び出す指示
呼び出し時だけ全文がロードされる「再利用可能なワークフロー」の層です。Claude Code の skills、OpenAI Agents SDK の tools が該当します。
層 2 の特徴は「呼び出し時にのみ全文ロードされる」「説明文 (description) は常時コンテキストに残る」点です。常時ロードされる層 1 とは違い、必要な時だけ全量を引き込めるため、コンテキスト消費を抑えながら手順を再現できます。Claude Code であれば .claude/skills/<name>/SKILL.md を /<name> で呼び出します。
層 3: UI で設定する指示
設定画面や設定ファイルから固定する「動作の振る舞い・制約」の層です。Claude Code の .claude/settings.json や ChatGPT の Projects instructions が該当します。
層 3 の特徴は「ツール許可や禁止のような振る舞いを制御する」点で、文章の行動指示というより設定値に近い性質を持ちます。Claude Code の permissions.deny はこの層の代表例で、ツール呼び出しそのものをブロックできます。
層 4: 会話で渡す指示
そのターンだけ有効な動的指示の層です。チャット入力で渡すプロンプトがこれにあたり、上位 3 層の設計度合いによって果たす役割が変わります。
層 4 は本来「そのターン固有の差分」だけを書く場所です。上位 3 層が整っていれば、層 4 は「今日はこのファイルを読んでください」「この出力を JSON に直してください」のような短い差分指示で済みます。上位層が空のままだと、層 4 で全部書くことになります。
Claude Code の指示層を 7 つに分解する
Claude Code は 4 層を最も明示的に分離しているツールで、用途ごとに 7 つの実装場所が用意されています。本章では公式ドキュメントの記述に沿って、それぞれの役割と注意点を順に見ていきます。
本ボールトの cc-wiki も、これら 7 つの実装場所をすべて使い分けて運用している事例の 1 つです。CLAUDE.md にセッション開始時の必須動作と禁止事項を、.claude/skills/ に /ingest などの再利用可能ワークフローを、.claude/settings.json にツール許可制御を、.claude/rules/ にファイルタイプ別の条件付きルールを、それぞれ役割分担で配置しています。「指示層がちゃんと設計されている運用例」のご参考事例として、各層の役割を読み解く際の参照点にしてください。
CLAUDE.md (ファイル固定の主担当)
層 1 の中核となる Markdown ファイルです。配置場所でスコープが決まり、ユーザーメッセージとしてコンテキストに注入されるためシステムプロンプトではない点が重要です。
# Claude Code の CLAUDE.md スコープ階層 (2026-05 時点) # 優先順位: managed > CLI 引数 > local > project > user # Managed (組織) /Library/Application Support/ClaudeCode/CLAUDE.md # Project (チーム共有) ./CLAUDE.md ./.claude/CLAUDE.md # User (個人全プロジェクト) ~/.claude/CLAUDE.md # Local (個人・現プロジェクト限定、gitignore 推奨) ./CLAUDE.local.md
公式記述では CLAUDE.md は「ユーザーメッセージとして注入される文脈」とされており、システムプロンプトではないため必ず守られる保証はありません。推奨サイズは 200 行以内で、それを超えたら .claude/rules/<name>.md に分割するのが公式の対応策です。
skills と agents (コマンド呼び出し)
.claude/skills/<name>/SKILL.md で定義したワークフローを /<name> で呼び出す仕組みと、独立コンテキストで動かす .claude/agents/<name>.md を、層 2 の実装として並べます。
.claude/
├── skills/
│ └── blog-draft/
│ └── SKILL.md # /blog-draft で呼び出すワークフロー
└── agents/
└── blog-writer.md # 独立コンテキストで動くサブエージェント
skills は呼び出し時にのみ全文がロードされ、説明文 (description) のみ常時コンテキストに残ります。agents は親エージェントとは独立したコンテキストで動き、親には summary だけを返します。両者は同じ層 2 の道具ですが、コンテキスト隔離するかどうかで使い分けます。
settings.json と rules (UI 設定とパス条件ロード)
.claude/settings.json でツールの許可・禁止を制御し、.claude/rules/<name>.md の paths: でファイル種別に応じた条件付きルールを当てる、層 3 の二段構えを整理します。
{
"permissions": {
"allow": ["Bash(git status)", "Bash(npm run *)"],
"deny": ["Bash(rm -rf *)", "Bash(git push --force*)"]
}
}
permissions.deny は、層 3 の中でも特に重要な「ツールレベルで強制される唯一の指示」です。CLAUDE.md に「rm -rf は使わないでください」と書いてもツール呼び出し自体はブロックされません。本気で止めたい操作はここに置きます。
.claude/rules/<name>.md は paths: frontmatter で「特定のファイルパターンを開いた時だけロード」という条件付きの層 1 として動きます。paths: 指定なしの rules は CLAUDE.md と同じタイミングで毎回ロードされる挙動になります。
built-in commands と bundled skills の違い
/compact のような CLI ハードコード型と、/simplify のようにスキルとして実装された bundled skill は同じ / 始まりですが内部構造が違います。混同しやすい点を切り分けます。
/compact などの built-in commands は Claude Code の CLI 内にハードコードされた機能で、ユーザーがファイルとして編集できる実体を持ちません。一方 /simplify などの bundled skills は、Claude Code が同梱しているスキル実装で、SKILL.md に相当する定義が中身として存在します。
ユーザーが新規にコマンドを追加したい場合の道は、bundled skills と同じ形式で .claude/skills/<name>/SKILL.md を書くことです。built-in commands を増やすことはできません。混同すると「/<my-command> を作りたいのに built-in commands を探してしまう」という遠回りが起きます。
ChatGPT・OpenAI Agents SDK で同じ 4 層を見つける
同じ 4 層は ChatGPT や OpenAI Agents SDK にも形を変えて存在します。本章では Claude Code を基準として、それぞれのツールでどの層がどう実装されているかを比較していきます。
ChatGPT: Custom Instructions と Projects
Settings → Customize ChatGPT で設定する Custom Instructions が層 1、Projects 単位の instructions が層 3 に近い位置を担います。優先関係と公式情報の取り扱いに注意点があります。
Custom Instructions は「About You」「Response Style」の 2 フィールド構成で、2026-05 時点の確認情報として各 1500 文字までという制限が二次情報側で言及されています。全プランで利用可能で、設定すれば全会話に自動適用される点が層 1 の特徴と合致します。文字数や仕様の最終確認は公式記述では取り切れていないため、本記事では限定表現にとどめます。
Projects は、チャット・ファイル・instructions を 1 箇所に集約するワークスペースです。Project 内のチャットでは Projects instructions が Custom Instructions を上書きする、と複数の二次情報が伝えていますが、help.openai.com に直接アクセスして公式記述で確定するところまでは取れていません。「2026-05 時点ではこのように扱われている」という限定の上で運用するのが安全です。
ChatGPT には Claude Code の skills に相当する「層 2 のコマンド呼び出し」が標準では存在しません。GPTs はやや近い性質を持ちますが別系統として整理されます。
OpenAI Agents SDK: instructions= と tools
Python 製の Agents SDK では、Agent(instructions=...) が層 1、tools が層 2、tool_choice などのパラメータが層 3 に対応します。コード 1 行で完結する点が他ツールとの違いです。
from agents import Agent, Runner, function_tool
@function_tool
def get_weather(city: str) -> str:
return f"The weather in {city} is sunny."
agent = Agent(
name="WeatherBot",
instructions="You answer weather questions in concise English.",
tools=[get_weather],
)
result = Runner.run_sync(agent, "What's the weather in Tokyo?")
print(result.final_output)
Agent(instructions=...) はシステムプロンプトとして機能する旨が SDK ドキュメントに記載されていますが、OpenAI API の system role に渡るのか developer role に渡るのかの内部実装は 2026-05 時点では公式記述では確定していません。実装側で API レベルの動作に依存する設計をする場合は、実機検証を併せる必要があります。
tools は層 2 の実装そのもので、@function_tool デコレータで任意の Python 関数をツール化できます。tool_choice などのパラメータはツール呼び出しの強制・抑制を制御する層 3 的なパラメータです。CLAUDE.md のような別ファイルを持たず、Python コード内に閉じる点が Claude Code・ChatGPT との差として現れます。
同じ 4 層が違う形で実装されている
3 ツール横断で並べると、4 層構造自体は共通で、ツールごとに「どの層がどれだけ明示的に分離されているか」の差として現れていることが見えてきます。
Claude Code は 7 つの実装場所として層を明示的に分離しています。ChatGPT は層 1 (Custom Instructions) と層 3 (Projects instructions) を分けて持ちますが、層 2 のコマンド呼び出しに相当する標準機能がありません。OpenAI Agents SDK は 4 層をすべて持ちますが、Python コード内に閉じるため Git でのファイル分離管理は別途設計する必要があります。
「自分が使っているツールには層 2 がない」「層 3 が UI で隠れていて見つけにくい」といったツール固有の癖を把握しておくと、足りない層を補う代替設計に進めます。
指示の置き場所を決める判断軸
4 層が並んだだけでは「どこに何を書けばいいか」は決まりません。本章では用途別に「これは層 X に置く」という判断軸を 4 パターンに整理し、実装の入口を渡します。
本ボールトの cc-wiki + CLAUDE.md + /ingest skill の構成も、この判断軸に沿って指示を分配したご参考事例です。「常に守ってほしい運用ルール」を CLAUDE.md (層 1) に、「raw からの取り込み手順」を /ingest skill (層 2) に、「ツール許可」を .claude/settings.json (層 3) に置き、「そのターン固有の差分」だけが層 4 のプロンプトに残るように設計しています。
「常に守ってほしいルール」は層 1 へ
プロジェクト規約や口調・出力形式の固定は層 1 (CLAUDE.md / Custom Instructions / Agents SDK instructions=) に置きます。ただし強制力ではなく文脈である点を踏まえる必要があります。
「コードはコピペで動く形式で出してください」「日本語で返答してください」のような出力ルールは層 1 に置くのが定石です。Claude Code であれば ./CLAUDE.md、ChatGPT であれば Custom Instructions、Agents SDK であれば Agent(instructions=...) のいずれかが受け皿になります。
注意点は、層 1 は強制ではない点です。Claude Code の CLAUDE.md は公式記述では「システムプロンプトではなくユーザーメッセージとして注入される文脈」とされており、必ず守られる保証はありません。守らせたい度合いが「強制」レベルなら層 3 (permissions.deny) との併用が必要です。
「再現したい操作」は層 2 へ
「同じ手順を呼ぶたびに実行したい」は層 2 (skills / Agents SDK tools) の出番です。Claude Code であれば .claude/skills/<name>/SKILL.md が実装場所になります。
ブログの下書きを書く・PR レビューをする・既存記事を監査する、といった「複数ステップの反復作業」は、毎回プロンプトで手順を書くのではなく skill にします。.claude/skills/<name>/SKILL.md に手順を固定すれば、/<name> を呼ぶだけで同じワークフローを発火できます。
OpenAI Agents SDK では @function_tool で Python 関数を tools 化することが層 2 の実装に対応します。「外部 API を叩く」「DB を読む」のような決定論的な処理は tools に置き、instructions= 側には書きません。
「禁止したいツール」は層 3 へ (permissions.deny)
危険な操作の禁止は層 3 の permissions.deny でしか強制できません。CLAUDE.md に「使うな」と書くだけではツール自体は呼べてしまう点を切り分けます。
{
"permissions": {
"deny": [
"Bash(rm -rf /*)",
"Bash(git push --force*)",
"Bash(git reset --hard*)"
]
}
}
本番ブランチへの強制プッシュ、ファイルシステム破壊、認証情報の漏洩につながるコマンドは、ここに書いて初めてツール呼び出しがブロックされます。「CLAUDE.md にも書いてあるし大丈夫」という二重化は、強制力という観点では二重化になっていない点に注意します。
ChatGPT には permissions.deny 相当の機能が標準では存在しないため、「ChatGPT に同じ強制を期待する」設計自体がそもそも成立しないことも、合わせて意識しておきます。
「今回だけの差分」は層 4 へ
そのターン固有の追加要件はプロンプトに残し、上位 3 層に書くべきではない点を確認します。上位層が整っているほど、層 4 で書くべき量は減ります。
「今日はこのファイルだけを読んでください」「この PR の差分だけを見てください」「出力をいったん JSON 形式に直してください」のような、その回限りの差分は層 4 のプロンプトに置きます。これらを CLAUDE.md に書き込むと、関係ない別のセッションでも毎回ロードされて邪魔になります。
上位 3 層が整備されているほど、層 4 のプロンプトは短くなります。逆に「層 4 のプロンプトがいつも長い」「同じ指示を毎回プロンプトに書いている」と感じる場合は、上位層に上げるべき指示が混ざっているサインです。
指示層が設計されていないと起きること (4 項目セルフ診断)
「プロンプトが悪い」と感じる現場で、上位層のどこが未整備かは観察可能です。本章では 4 つの典型症状を挙げ、それぞれがどの層の空欄に対応するかを並べます。
同じ補足プロンプトを毎回書いている (層 1 未整備)
「あなたは TypeScript エンジニアです」「英語で返さないでください」など同じ補足を毎回書いている場合、層 1 (CLAUDE.md / Custom Instructions) の未整備が疑われます。
これは最も多い未整備パターンです。Claude Code を導入して便利に使っているのに ./CLAUDE.md が空、ChatGPT を 1 年以上使っているのに Customize ChatGPT が空、という状態がここに該当します。毎回 2〜3 行の補足を打ち直しているなら、その分は層 1 に上げられます。
入口は、毎日の会話で同じ文字列を打っている自分の癖を 1 週間メモに取ることです。重複している文字列は層 1 の素材として、CLAUDE.md か Custom Instructions に書き写します。
CLAUDE.md だけで危険コマンドを禁止しようとしている (層 3 未整備)
「rm -rf は使うな」と CLAUDE.md に書いただけでは実行を止められません。permissions.deny の設定が抜けているケースに該当します。
この未整備は、起きてからでは遅い種類の未整備です。CLAUDE.md の禁止記述は文脈であり、文脈は破られることがあります。本番への破壊操作・認証ファイルへの書き込み・履歴の書き換えなど、「事故が起きると取り返しがつかない」操作は層 3 の .claude/settings.json で permissions.deny に登録します。
層 3 の設定は 1 度書けば全セッションに効きます。導入コストは低く、効果は大きい未整備の代表です。
skill が 1 つもない / Custom Instructions が空欄 (層 2・層 1 未整備)
同じ作業を AI に何度もお願いしているのに skill 化していない、ChatGPT で長く運用しているのに Custom Instructions が空欄、というのは層 2・層 1 の未整備サインです。
.claude/skills/ が空のまま運用していると、ブログ下書き・PR レビュー・既存記事監査などの反復作業を毎ターン手順から書き直すことになります。「3 回以上やった作業」を基準に、skill 化対象として候補に上げると判断しやすいです。
ChatGPT の Custom Instructions についても同じ目線で、「会話の冒頭に書く定型文があるか」を 1 週間観察すれば、層 1 に上げるべき素材が可視化されます。
層 4 のプロンプト工夫だけで戦っている (全体未整備)
上位 3 層がほぼ空欄で、毎ターンのプロンプトに依存している状態は全層未整備の段階です。打ち手の優先順位を整理する出口に進みます。
この状態は、AI 活用で生産性差が開いていく分岐点でもあります。プロンプト工夫だけで戦っているエンジニアと、上位層を設計してから層 4 を最小化しているエンジニアの差は、時間が経つほど開きます。AI を使うほど差が広がる構造については AIで速くなるエンジニア・遅くなるエンジニア｜作業種別ごとの効率差 で扱っているので、自分のポジションを確認する材料として参照してください。
打ち手の優先順位としては、「今すぐ事故を防ぐ層 3 (permissions.deny) → 毎日の補足を消す層 1 (CLAUDE.md / Custom Instructions) → 反復作業を固定する層 2 (skills)」の順が現実的です。層 4 の工夫は、上位 3 層が整ってからの仕上げに位置づけられます。
まとめ
本記事では、AI への指示を 4 層に整理し、Claude Code・ChatGPT・OpenAI Agents SDK で同じ構造を見つけ、置き場所の判断軸とセルフ診断を扱いました。最後に、実務に落とすときの順序と次に読むべき記事を案内します。
実装の優先順位としては、まず層 3 (permissions.deny) で事故を止め、次に層 1 (CLAUDE.md / Custom Instructions) で毎ターンの補足を消し、最後に層 2 (skills / tools) で反復作業を固定する、という順番が現実的です。層 4 のプロンプトは「そのターン固有の差分だけ」になっていれば、上位 3 層の設計はおおむね成立しています。
「指示層を自分の業務に設計したいが、どこから手をつけるか整理したい」とお考えの方は、Beエンジニアのお問い合わせフォームよりご相談ください。業務内容と現状の AI 利用パターンをお伺いし、層 1〜層 3 のどこから着手すれば最短で効果が出るかを一緒に整理させていただきます。
次に読む記事
指示層が設計できると、次は「AI に何を見せて判断させるか」という知識参照側の話に進めます。CLAUDE.md と同じ Markdown 基盤で AI に過去の判断を引き継がせる仕組みについては、次の記事で扱います。
