AIに意図を正しく伝える、公式の設定作法

AIに仕事を任せれば、説明した分だけ返ってくる。そう考えて使い始めたものの、同じような依頼のたびに前提を一から書き直し、それでも出力が毎回ぶれる——。AI活用が「時短」のはずが、いつの間にか説明の手間に追われている、という声を、支援の現場でよく耳にします。

その原因の多くは、モデルの性能ではありません。精度の高い出力を得る鍵は、AIに意図をどれだけ正しく、効率的に伝えられるかにあります。そして意図を伝えるには、公式が示す設定の作法にならうのが近道です。本記事では、note・rule・skill という3つの置き場で意図を外部化し、AIが文脈を汲み取って自律的に動けるようにする方法を、考え方から具体的な設定まで整理します。

同じAIなのに、なぜ成果に差が出るのか

差を生んでいるのは、多くの場合モデルの賢さではなく、AIに渡している文脈（コンテキスト）の設計です。

まず前提として、AIは会話が変われば前回のやり取りを覚えていません。毎回まっさらな状態から、渡された情報だけを頼りに推測します。だからこそ、成果を出す人はAIに背景を十分に渡し、そうでない場合はその場限りの指示だけで動かしている——この差が、出力の安定度に表れます。

やっかいなのは、「たくさん書けばよい」わけでもないことです。近年の研究では、コンテキストは有限の資源であり、情報を詰め込むほどモデルが本当に見るべき点に注意を割けなくなる（想起精度が落ちる）ことが指摘されています。つまり、毎回書き直す消耗と、長大な前提を丸ごと渡す非効率は、どちらも同じ根を持っています。

当社でも、複数の事業プロジェクトでAIを日常的に開発・運用へ用いています。そこで繰り返し実感するのは、成果が安定するかどうかは、モデルの新しさよりも「前提をどれだけ整えて、適切な場所に置いて渡しているか」で決まる、ということです。

目指すべきは「たくさん渡す」ことではなく、必要十分な情報を、必要なときに、正しい場所へ置くことです。

文脈は「3つの置き場」に外部化する

毎回プロンプトに書くのをやめ、文脈を性質ごとに置き場へ分けて外部化すると、AIの出力は安定していきます。

ポイントは、文脈をひとまとめにしないことです。渡したい情報には「事実の記録」「守らせたい約束事」「作業の手順」という異なる性質があります。人の記憶が、事実を覚える宣言的な記憶と、身体で覚える手続き的な記憶に分かれているのと同じ発想です。当社では、この3つを note・rule・skill と呼んで整理しています。

3つの置き場は、AIの実行を支えると同時に、日々の作業から得た学びを受け取って育っていきます。全体像は次のとおりです。

この3つを分けるだけで、「毎回説明する」状態から「一度書けば効き続ける」状態へと重心が移ります。あわせて、これまで担当者の頭の中にあったノウハウが共有できる形で外に残るため、組織としての再現性も高まります。

note ― 状態と決定を「外」に記録する

note は、事実・状況・決定といった「モデルが忘れてよい情報」を、AIの外に残しておく置き場です。

覚えておくことをAIに期待するのではなく、忘れてよい形にして外に出しておく。プロジェクトの前提や「なぜこの方針にしたのか」という判断の理由を記録に残せば、次の依頼でも同じ土台の上で考えさせられます。ここで残すのは会話の要点や決定であり、細部まで抱え込む必要はありません。

すべてを常に読み込ませる必要もありません。先進的なエージェント（自律的に作業を進めるAI）の設計では、最初から全データを抱えず、ありかを指す軽い手がかり（ファイルの場所や検索条件）だけを持ち、必要になった時点で取りに行く「段階的な開示」が有効とされています。note も、要点は常に、詳細は必要時に、と使い分けると軽く保てます。

たとえば、あるプロジェクトの note には「対象ユーザーは業務担当者で専門知識は前提にしない」「表記は『です・ます』」「過去に検討して見送った案とその理由」などを書いておきます。こうした前提は、毎回のプロンプトに書くには長すぎ、しかし外すと出力がぶれる。だからこそ、会話の外に置いておくべき情報です。逆に、一度きりしか使わない些末な指定は note に入れません。「次も同じ前提で考えてほしい」と思ったものだけを残す、という基準で足していくと、note は軽いまま役に立ち続けます。

モデルは忘れる、けれど記録は忘れない。

rule ― 守らせたい前提を常設する

rule は、出力の型や守るべき制約、やってはいけないことを、依頼のたびに毎回自動で効かせる置き場です。

note が「参照する情報」なのに対し、rule は「常に効いている約束事」です。文体や書式、使ってはいけない表現、必ず踏むべき手順といった前提を一度定義しておけば、毎回指定し直す必要がなくなります。特に「やること」と「やってはいけないこと」を別々に、はっきり並べて書くと、AIの遵守度は目に見えて上がります。

ただし、常に効かせる情報だけに、増やしすぎると逆効果です。前述のとおり注意は有限なので、rule は「最小限の、効き目の大きいものだけ」に絞ります。実際に使う中で「また同じ指摘をしている」と気づいたら、そのつど一行足していく——この育て方が現実的です。

rule に書くのは、たとえば「専門用語は初出で一度だけ説明する」「誇張した言い切りは避ける」「社外に出せない固有名詞は伏せる」といった、毎回守ってほしい約束事です。ポイントは、抽象的な心構えではなく、守れたかどうかを判定できる具体的な形で書くこと。「読みやすく」ではなく「一文は60字以内を目安に」と書けば、AIも人も同じ基準で確認できます。守らせたい線引きが明確なほど、rule は効きます。

skill ― やり方を手順にして再利用する

skill は、繰り返す作業の「やり方」を手順として保存し、必要なときに呼び出す置き場です。

定型のレポート作成や、決まった観点でのチェックなど、段取りが決まっている作業は、その手順そのものを部品にできます。曖昧な指示よりも、目的・前提・手順・完了の確認方法・やり直しの条件を構造立てて書いたほうが、AIは一度で正しく動く確率が上がります。手作業で確認すべき箇所や承認が要る箇所を明示しておけば、AIが先走って実行してしまう事故も防げます。

構造化には少し手間がかかりますが、割に合う場面ははっきりしています。「繰り返し使う」「間違えると影響が大きい」「出力を後工程で使う」——この条件がそろう作業ほど、手順を部品化する価値が大きくなります。逆に、単発の相談や短い指示にまで構造を持ち込むと、かえって重くなります。

たとえば「週次レポートを作る」という作業なら、skill には「どのデータを見るか」「どの順で集計するか」「どの観点でコメントを書くか」「最後に何を確認するか」を手順として書いておきます。次にレポートを作るときは、ゼロから指示を組み立てるのではなく、その skill を呼び出して「今週分で」と伝えるだけ。段取りが部品になっていれば、担当者が代わっても同じ品質で仕上がります。手順を一度言語化しておくことは、AIのためだけでなく、チームで仕事を引き継ぐための資産にもなります。

同じ段取りを3回説明したら、それはプロンプトではなく skill に書くサインです。

実装編：実際の設定に落とす ― Claude Code の .claude/ を例に

ここまでは考え方の話でした。この3つの置き場は、代表的なAI開発ツールである Claude Code の設定構造に、ほぼそのまま対応します。

ここからの2つの節は、実際に手を動かす担当者向けの具体編です。設定の細部に踏み込むため、考え方だけ押さえたい場合は「3つを『育てる』自己改善ループ」まで読み飛ばしても、記事の本筋は追えます。

Claude Code は、プロジェクト直下の CLAUDE.md と .claude/ フォルダ、そしてホーム配下の ~/.claude/（~ は、PCの利用者ごとに用意される基点のフォルダを指します）を読み込みます。プロジェクトの .claude/ はチームで共有できるよう git（ファイルの変更履歴を記録し、チームで共有する仕組み）で管理し、~/.claude/ は全プロジェクトに効く個人設定として使い分けます。note・rule・skill は、この中の次の要素に対応します。

全体像はおおよそ次の構造です。

プロジェクト/
├─ CLAUDE.md              … 規約(rule)＋要点の記録(note)。毎回読み込まれる
└─ .claude/
   ├─ rules/*.md          … rule を分割して整理
   ├─ skills/<名前>/SKILL.md … skill（先頭の説明文＝description をもとに自動で呼び出される）
   ├─ commands/*.md       … 手動で呼び出す定型（/名前）
   ├─ memory/MEMORY.md    … auto memory（AIが自動で追記＝note）
   └─ settings.json       … 権限・フック（決まった操作時に自動で走る処理）・モデル等の設定
~/.claude/                … 個人設定（全プロジェクト共通）

とくに auto memory は、note の「モデルは忘れる、記録は忘れない」を仕組みにしたものです。AIが作業中の訂正や好みから「次に活かせること」を自分で書き留め、次のセッションで読み直します。人が明示的に書かなくても、記録が育っていく設計です。

実装編：SKILL のベストプラクティス

skill を部品として効かせる鍵は、本文の中身よりも、先頭に置く「説明（description）」の質にあります。

Agent Skills では、SKILL.md というファイルの冒頭に、name（名前）と description（説明）を書きます。AIはまずこの説明だけを読み、「今回の作業にこのスキルを使うべきか」を判断します。関係があると判断したときにはじめて本文を読み込む——この段階的な開示（Progressive Disclosure）が、注意予算を無駄遣いしない仕組みになっています。

実務で効くコツは、いくつかに集約できます。

• 説明は「何をする」＋「いつ使う」をセットで、三人称で書く。「〜できます」ではなく「〜を処理し、〜のときに使う」と具体的に書くと、AIが正しく呼び出せます。
• 1スキルは1つの役割に絞る。あれもこれも詰め込むと、いつ呼ぶべきかが曖昧になります。
• 本文は簡潔に保ち、詳細は別ファイルに逃がす。目安として本文はおおむね500行以内にし、長い手順や資料は参照ファイルに分けて必要時だけ読ませます。
• 名前は動作が分かる形にする（たとえば「レポートを作る」なら report-generation のように）。

スキルが呼ばれるかどうかは、本文ではなく「説明文」で決まります。

3つを「育てる」自己改善ループを回す

置き場は作って終わりではなく、日々の作業から得た学びを還元することで、精度が上がっていきます。

やり方はシンプルです。うまくいった型は rule やテンプレートとして残す。失敗した型は「やってはいけないこと」として残す。繰り返す段取りは skill にまとめる。こうした小さな還元を続けると、AI環境は使うほど自分たちの仕事に馴染んでいきます。実際、この振り返りを習慣にできたチームとそうでないチームでは、数か月のうちに安定性の差がはっきり出てきます。

当社自身も、社内のAI運用でこの外部化と還元を標準にしています。指示を記録・規約・手順の3つに分けて残し、うまくいった型や失敗した型をそのつど反映していくと、使い込むほど出力が安定し、担当者が入れ替わっても品質が揃うようになりました。特別なツールがなくても、共有ドキュメントに「決定の記録」「守る約束事」「作業の手順」を分けて置くだけで、同じ効果が得られます。

還元は意識しないと後回しになります。作業の区切りごとに「今回の学びで、次に残すべきものは何か」を一度だけ問う——この問いを仕組みにしておくと、置き場は自然に育ちます。あわせて、うまくいった判断は「なぜうまくいったか」の根拠とセットで残すと、後から再利用したときに効きます。

還元先を仕分けるコツは、学びの性質で判断することです。「こういう場合はこう書くと良い」という型は rule へ。「この段取りで進めるとうまくいく」という手順は skill へ。「この案は過去に検討して見送った」という事実や決定は note へ。同じ失敗を二度繰り返さないために、うまくいかなかったパターンを「やってはいけないこと」として rule に残すのも有効です。こうして学びを正しい置き場へ流し込んでいくと、環境は使うほど自分たちの仕事の形に近づいていきます。

太らせない設計 ― 常設する情報に上限を設ける

育てる環境で見落とされがちなのが、「増やす」ことより「絞る」ことの重要性です。

常に読み込ませる情報は、多いほど処理のコストが上がり、要点がぼやけます。実際、Claude Code の auto memory も、毎回読み込まれるのは先頭のおよそ200行（または25KB）までと決められており、それ以上は起動時には読まれません。増やし放題にせず、古い記述を統合・整理し、重要度の低いものを削っていく——人が申し送りメモを定期的に書き直すのと同じ運用が要ります。

「常に効かせるもの（rule と、note の要点）」は小さく保ち、「必要なときだけ取り出すもの（note の詳細や過去の記録）」は外に厚く貯める。この二層で考えると、環境は軽さと厚みを両立できます。

落とし穴 ― 「AIがそう言うので」に注意する

繰り返しを仕組みにするほど作業は速くなりますが、速さには固有のリスクも伴います。

ひとつは、AIに任せた生成物を自分で理解しなくなる「理解の負債」です。もうひとつは、判断基準を持つことをやめ、出力をそのまま受け入れてしまう状態——「AIがそう言うので」が口癖になり始めたら、注意のサインです。仕組みはあくまで、人が判断を下すための土台であって、判断そのものを肩代わりするものではありません。

同じ仕組みでも、判断力を保ったまま使えば思考を助ける解毒剤になり、思考から逃げるために使えば劣化を速める促進剤になります。当社が支援の現場で大切にしているのも、AIに「実行」や「効率」は任せても、事業にとって何が正解かの「意思決定」は手放さない、という線引きです。

まとめ ― 繰り返しを「資産」に変える

繰り返す作業を note・rule・skill に外部化することは、単なる時短ではなく、属人化した知識をチームの資産に変える取り組みです。

プロンプトは書いたそばから消えていきますが、置き場に残した文脈は、次の作業でも、別のメンバーの作業でも効き続けます。AIをうまく使えるかどうかは、モデルの新しさというより、こうした「育てる環境」を持ち、絞りながら育て続けられるかで決まっていきます。

始め方は難しくありません。まずは note を数行、書くことから始める。プロジェクトの前提や、毎回説明している背景を一度書き出すだけで、出力の安定は目に見えて変わります。慣れてきたら、繰り返す約束事を rule に、繰り返す段取りを skill に移していく。完璧な体系を最初から作る必要はなく、日々の作業の中で少しずつ育てれば十分です。小さく始めて、使いながら整える——この積み重ねが、いつのまにか「自分たちだけのAI環境」になっていきます。

当社では、AIの活用を単発のプロンプト設計で終わらせず、事業の成果から逆算して「育てる仕組み」として設計し、運用の定着まで伴走しています。自社のどの繰り返し業務から外部化すればよいか、進め方に迷われた際は、お問い合わせください。

参考・引用元

• Anthropic「Effective context engineering for AI agents」 https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• Anthropic「Agent Skills / Skill authoring best practices」 https://docs.claude.com/en/docs/agents-and-tools/agent-skills/best-practices
• Anthropic「Claude Code — How Claude remembers your project（メモリ）」 https://code.claude.com/docs/en/memory
• lumichy「Hermes Agentの記憶システムを完全図解」（Zenn） https://zenn.dev/lumichy/articles/hermes-agent-memory-system-2026
• Acrosstudio／シンウフム「もうプロンプトを書くな──Loop Engineering」（Zenn） https://zenn.dev/acrosstudioblog/articles/38509c0473683a
• Daichi Ito「Claudeと対話しながらIT作業手順書プロンプトの標準フォーマットを設計した話」（Zenn） https://zenn.dev/itsdaichi/articles/f2afb9878e04e5

※本文は上記の公開情報および当社の運用知見をもとに再構成したものです。設定名・仕様は執筆時点のものです。