AIエージェントの指示を、長いプロンプトでなくObsidianのノートに分けて置く方法

出典: I’m deleting this video in 48 hours

AIに頼むたびに、指示文へ一行ずつ書き足す毎日。気づけば、どこに何を書いたのか、自分でも探せなくなっていませんか？長くするほど安心できるのに、守られている手応えは薄いまま。

Daniel さんは冒頭で、エージェントの原則を探る実験だと切り出します。これからエージェントをどう作るかの考え方で、もとは自分の個人ノートです。何かを売り込む意図はない、とも断ります。

画面に映るのは、Obsidian で組んだエージェントの全体の構造。Obsidian を選んだ理由は、全部を相互にリンクできるからだそうです。

この回に台本はありません。下書きのノートはAIで用意したものの、考えと実践は自分のもの、という断り書きです。人が知恵を持ち寄れば、よりよい仕組みになる、という立場です。

ここ数か月で、スキルを試した人は多いはず。ただ、フォルダにきちんと入れて、よい構造で整えてあれば、スキルは要らなくなってきた、という見立てなんですよね。

Daniel Agrici さん（動画 1:01〜）

skills are not even needed anymore If you have everything properly set and put in a folder, for example following a good structure

私の訳: すべてをきちんと整えて、たとえばよい構造に従ってフォルダに置いてあれば、スキルはもう要らないんです。

このノートでは、エージェントの先頭の欄に、種類、所属、名前、役割、領域、状態、アクション・シーリング、割り当て先、スキルが並びます。名前は Emre。ブログ記事やニュースレターの下書きを作る役です。

以前は、スキルを使うたびにインストールが必要でした。今は要らないそうです。エージェントは参照とリンクを持ち、頼まれた内容に合うスキルだけを呼び出す仕組み。

Daniel Agrici さん（動画 3:11〜）

Because all the skills that the current agents are using it’s not needed to install them It’s moved on first the agent just has a reference and interlinking

私の訳: 今のエージェントが使うスキルは、インストールしなくていいんです。時代は先に進みました。エージェントが持つのは、参照とリンクだけです。

ブログを書くなら、書くためのスキルを引く形。といっても、スキルだけでは足りません。テンプレート、ワークフロー、知識の Brain も要ります。

スキルのノートを1つ開く場面もあります。コピーライティングの例で、成果、使う場面、入力、方法、出力、境界の欄が、それぞれ別のノートにリンクしているんです。

後半で、Daniel さんは核心に入ります。エージェントは1本の長いプロンプトではなく、自分が誰かを保存して、使う部品へリンクする小さなファイルだ、という話です。

Daniel Agrici さん（動画 21:31〜）

an agent is not one long prompt It’s a small file that saves who it is and links to the parts it uses

私の訳: エージェントは、1本の長いプロンプトではありません。自分が誰かを保存して、使う部品へリンクする、小さなファイルです。

チーム全体で共有する物は、1回書いて1か所に置きます。エージェントはコピーを持たず、そこを指すだけ。

この構造なら、Claude でも Codex でも、どのツールかはあまり関係ないそうです。ローカルのモデルを、その作業の専門家に育てるのにも向くそうですよ！

正直、指示文に書き足すほうが早く感じますよね。

で、この章の筋道は、指示文を長くすることではなく、置き場所を整えること。足すより、置く！

私の起動用のファイルは、本体を書かずに、別の3つのファイルを呼び出す行が並んでいます。

1つはAIの人格を定めたファイル。1つは私の入口のファイル。残る1つが、共通の起動入口のファイルです。

共通の起動入口のファイルには、共通スキルの正本は1か所、と書いてあります。複数のAIが、同じ本人情報と既存の資産にたどり着くための索引だ、という説明つき。

私の記事より（CLAUDE.mdの置き場所とルールを決めると、Claude Codeで作ってもファイルが散らからない・3行でわかるポイントの節）

CLAUDE.mdは毎回全部読まれ、長いほど守られにくい。目安は50〜150行です。

起動用のファイルは小さく保ち、本体は参照に任せています。この向きは、動画の小さなファイルと重なります。

長く書く前に、まず自分が誰かを短く。

名前が変わっても、肩書きが変わっても、その人らしさは残りますよね。では、AIのその人らしさは、どこに書いておけば残るんでしょう？

6つの層の最初は Identity。エージェントが誰か、という層です。中身は、名前、役割、そして魂。

役割は、どんな仕事をして、何をしないか。魂のほうを、Daniel さんは声と呼ぶことにしています。

各エージェントには、読み物の README と、声のノートがあります。声のノートには、短く話す、長く話す、悪い言葉やダッシュを使わない、といった指示が並ぶんです。

ブログ担当 Emre の声の例も出てきます。急いでいる読者のために書くこと。温かく、具体的で、静かに力強いこと。人の本当の問いを探して、明快な筋道にまとめること。

Daniel Agrici さん（動画 23:12〜）

The voice and how it talks, so keep these two apart The job can change while the character stays the same

私の訳: 声と話し方。この2つは分けて持ちます。仕事が変わっても、人格は同じままでいられます。

続いて、人間にたとえます。何度仕事を変えても、人格は同じまま。とはいえ、役割も人格も変えられる、とも。結局は文章だから、という理由です。

それでも、これからどんなエージェントでも、同じ人格を保つことが、いちばん大事な部分のひとつ。人格を失えば人間は困る、と Daniel さんは話します。

Daniel Agrici さん（動画 23:43〜）

keeping the same identity for any sort of agents in future I think it’s one of the most important parts

私の訳: これからどんなエージェントでも、同じ人格を保つこと。いちばん大事な部分のひとつだと思います。

役割と声を分けて、仕事が変わっても人格は同じに保つ。あ、これ、AIの話なのに、人の話として読めるんですよね！

私の判断軸は、魂は渡さない、魂は込めるもの、です。委ねるのは、その後の実行と量産。Daniel さんは役割と声を分け、私は魂と実行を分けます。分け方は違っても、変わる物と変わらない物を先に分ける向きは近い、と私は見ています。

みなさんが今使っているAIの役割と声は、どこに書いてありますか？

まずは、変わらない物から！

同じ説明を、あちこちのファイルに写していませんか？書き直すたびに、どれが最新なのか分からなくなる、あの感じ。手順書も指示文も作業のメモも、写した数だけ古い版が増えていきます。

2つ目の層は Mind、知識です。Brain は、1つの分野の深い専門知識で、使うエージェントだけが持つもの。同じ Brain を複数で共有できても、全員に渡すわけではありません。

ブログの Brain を会計担当に渡す必要はない、と Daniel さんは話します。Knowledge は、それ以外の全体の決まりや参考。組織についての知識や、リサーチの結果も入ります。

3つ目の層は Hands、手です。スキルは、手順として書かれた、繰り返せる能力。ツールは、エージェントがつながる外のサービスやデータ。

スキルはネットにたくさんあり、数秒でインストールできます！ただ、それが良い方法かは使うモデルによる、という見立てです。スキルは過去の部品で、今は Markdown を先に置く構造でフォルダに置けばよい、という勧め。

4つ目の層は Method、手順。SOP は、繰り返す手順の扱い方です。セッションの始め方や閉じ方、引き継ぎに何を書くかまで、ここで決める形。

ワークフローは、A から Z までの道のりです。うまくいった仕事は、ワークフローに変えられます。テンプレートは入力と出力の形を決めて、仕事を一貫させ、確かめやすくするもの。

Daniel Agrici さん（動画 28:22〜）

Because workflow does the job Template shows you how exactly that job is supposed to look like

私の訳: ワークフローは仕事をします。テンプレートは、その仕事がどんな形になるはずかを示します。

チームの層に進むと、原則が出てきます。ひとつの事実は、1か所に。リンクして、コピーしない、という決まりです。

Daniel Agrici さん（動画 32:17〜）

principles Link Don’t copy Each fact lives in one place

私の訳: 原則。リンクして、コピーしない。ひとつの事実は、1か所に置く。

コピーを重ねても無駄で、フォルダのパスを渡せばよい、という話です。置き場所の節約になり、重複も出ない作り。古い写しがどこかで見つかることもありません。

Daniel Agrici さん（動画 32:31〜）

So don’t just copy and give it to your agent Just put the path Share with your agent like that

私の訳: だから、コピーしてエージェントに渡すのではなく、パスを置いてください。そうやってエージェントと共有します。

で、ここまでの筋道を一言にすると、足す前に置き場所を決める話なんですよね。

知識も手順も、正本は1か所。エージェントには、そこを指させるだけ！

実は、私の起動用のファイルにも、確認画面の書式の正本は1つで、ここには複製しない、と書いてあります。

共通の起動入口のファイルの冒頭も、同じ書き方。正本の複製や新しい記憶庫ではなく索引だ、と書いてあります。

正本を1か所に決めて、ほかは参照にする作りなんです。

私の記事より（ClaudeとObsidianでセカンドブレインは15分で作れる。でも9ヶ月運用して分かった本当の壁・まとめ：作ることは目的地じゃなく、出発点だったの節）

資産とまとめを分け、AIの言葉と自分の言葉を分け、習慣として根付かせる、という地味な積み重ねが必要でした。

資産とまとめ、AIの言葉と自分の言葉。私の記事は、それぞれを分けて、習慣として根付かせる積み重ねが要った、と結んでいます。

動画は、ひとつの事実を1か所に置く話。分ける物は違っても、置き場所を先に決めて混ぜないところが同じです！

向きは同じだと見ています。散らばった物を集めて、1か所を正本にする向き。リンクで参照する、という言い方は Daniel さんの言葉です。

作る前に、置き場所を1か所に決めておきます！

AIが何をしたのか、後から聞かれて答えられますか？どの順で、何を見て、どう決めたのか。終わった成果物だけでは、途中の道のりまでは見えてきません。

手順書の例として、セッションの始め方、閉じ方、成果物の見直し方、新しいエージェントの迎え方が挙がります。

その中心が、Sessions のフォルダ。成果物、割り当て、決定、引き継ぎ、受信箱、記録、タスクの結果、レビューまで、ひとつのフォルダに置きます！

Daniel Agrici さん（動画 16:25〜）

in sessions here we have artifacts assignments decisions handoffs inbox records task results and review

私の訳: セッションには、成果物、割り当て、決定、引き継ぎ、受信箱、記録、タスクの結果、レビューを置きます。

きっかけは、大手AI企業のツールへの不満です。考えは一時ファイルに隠れて、再開はできても、一歩ずつ何を考えたかは見えない作り。考えは各社の財産、という言い分です。

Daniel さんは、それを恥とは思わない、という立場です。見張り続ける必要もない、という立場。ただ、エージェントがツールを呼んだら、システムに記録します。

Daniel Agrici さん（動画 16:54〜）

we don’t need to monitor exactly what these agents are doing, right? So for that, let’s say if an agent is calling a tool that one needs to be recorded on the system

私の訳: エージェントが何をしているかを、ずっと見張る必要はありません。ただ、エージェントがツールを呼んだら、それはシステムに記録しておく必要があります。

開発者が文章で頼み、はい・いいえのボタンを押すだけになっている、という話も出ます。画面に映るのは、自作のミーム画像。いつも推奨ボタンを押す人でなければ、そうはならない、と笑いを混ぜています。

記録するのは、成果物と割り当てと決定。決定は、エージェントが行動の前にどう決めたか。人間が無意識にしている判断を、エージェントも自動でしている、と言い、その中身を知っているか、と問いかけます。

将来、悪意のあるエージェントが出ることも考えられて、社会への高いリスクになる、という見立てです。ここで話は、人間の側の握り方へ。

だから人間は、全体を握っておく必要がある、というのが Daniel さんの考えです。

Daniel Agrici さん（動画 19:31〜）

I think we as humans, we do need to have the full control for us to be able to view This thinking, their thinking and each and every step if we want to

私の訳: 人間は、見たいと思えば、エージェントの考えも、ひとつひとつの手順も見られるように、全体を握っておく必要があると思います。

考えそのものを、丸ごと取り出すのは無理。ただ、記録を全部与えれば、心理学者のように、エージェントの考えを見分けられる、という話です。

300ページの文書をエージェントが出してきても、全部読む人はいない、という話。人間はエージェントほど速く読めないので、読む勝負はすでに負けている、という見立てです。

見張り続けるのではなく、後から辿れる形で残しておく作り。読むかどうかより先に、辿れることが土台なんですよね。

あ、私の手元にも、案件ごとに状態メモを1枚置いています。使い方の説明には、追記のみ、置換禁止、古い行は消さず状態だけ更新する、と書いてあります。

止まった時に書くのは4点。なぜ止まったか、どこまで終わったか、何が残っているか、私がやることです。

2026年10月27日に数えたら、状態メモは160件を超えていました！

残すことと、全部読むことは、別の話。

探求の途中なら、判断の材料になるプロセスが要ります。ただの作業や文章の文体なら、できあがった結果で判断できます。

人が一段上から見るのは、AIが結論まで出し切った後の判断軸と、守る価値の置き場所。それと、身体に出る違和感です。

読むのは一部、残すのは全部。

AIに任せる仕事が増えるほど、どこまで任せてよいのかを先に決めておきたくなりますよね。その線は、いつ、どこで引いていますか？ この章は、その線を引く層の話です。

5つ目の層は Limits、制限です。エージェントは強すぎるので、砂場のような囲いに入れる、と Daniel さんは話します。置かなければ、周りに混乱を起こす、とも。

次はアクション・シーリング。承認を取らずにしてはいけない範囲のことです。エージェントのノートの欄にもあって、例の Emre は、今は無しになっています。

Daniel Agrici さん（動画 29:02〜）

And action ceiling the most The agent may not do without asking Without an approval A switch for whether it can be called at all And a clear policy for what needs human approval

私の訳: そしてアクション・シーリング。承認なしに、確認もなしには、エージェントがしてはいけないこと。呼び出せるかどうかを決めるスイッチ。人の承認が要ることの、はっきりした方針です。

制限は、エージェントを安心して信頼するための物。話は、そこへ続きます。

Daniel Agrici さん（動画 29:16〜）

So limits are what makes an agent safe to trust

私の訳: つまり、制限があるから、エージェントを安心して信頼できます。

サイトを更新して、とだけ頼んで、うまくいくと期待することはできません。まず教えること。教え終わって、仕事がきちんと済んだと分かれば、そこで信頼が生まれる、という順番です。

Daniel Agrici さん（動画 29:34〜）

You need first to teach it And as soon as it teaches Then you know exactly that wow The work is done I have trust in him Then he can maybe even remove that specific limit

私の訳: まず教える必要があります。教え終わって、仕事がきちんと済んだと分かれば、信頼できます。そうなって初めて、その制限を外してもいいかもしれません。

信頼しないなら、制限を置くこと。人に対しても同じです。承認のゲートも同じで、自動モードで、はい・いいえ、と聞いてくる場面がそれだ、という話です。

承認の話は、別の場面にも出てきます。ブログを勝手に公開せず、まず人に見せ、連絡し、承認を取ってから動く使い方です。エージェントごとに、持つ範囲と、触らない範囲も書いてあります。

制限は、縛るための物というより、信頼を積むための物。信頼が積み上がったら外してもいい、という順番で話が進むんですよね。

で、この話は、制限を外す条件まで先に置いているんです。まず教えて、仕事が済んだと分かってから外すこと。外すまでの道筋が、最初から見えています！

実は私の決まりにも、承認が要る場面が書いてあります。公開、外部への送信、一斉配信、データやファイルの物理削除、課金の本実行。この5つは、最後の実行の直前に、明示の承認が要ります。

先に出した指示は、方針。実行の許可ではない、とも書いてあります。承認の境界そのものを緩めることも、承認が要る項目に入っています。

承認を置くのは、外に出る操作の前だけ。途中の作業は、そのまま進めます。外に出る一手と途中の一手を、分けて持っているんです！

私の記事より（ローカルSEO AIに任せても、公開のボタンは人が押すと決めておく・AIに任せても、下書きは誰が読んで、誰が出すのかの節）

私なら、AIが案を出し切った後で、判断軸と守る価値の置き場所を、人が一段上から確かめます。

動画では、承認が要る範囲を先に決めます。私の記事は、出し切ったあとに一段上から確かめる形。確かめる位置を人の側に置く、という所が重なります！

私は、成果物ごとに最終承認をする人で居続けるより、一段上の視点から、判断軸と育ち方を見ていたいんです。

その時に外さない軸が、偽りがないこと。偽りというのは、事実でないことを、事実のように振る舞うことです。

だから、外に出る一手の前で見るのは、事実でないものが混ざっていないか。途中の成果物を、一つずつ承認にかけることはしません。

承認の位置は、外に出る一手の前。

同じ失敗と、同じ指摘の繰り返し。そこで手が止まってしまうことってありませんか？ この章は、その繰り返しを仕組みで閉じる層と、チームの形の話です。

6つ目の層は Loop。評価としてテストの問いと採点表があり、プロンプト・インジェクションのような攻撃ケースも入ります。出す前に確かめる検証役と学習の仕組みも、この層です。

学習は、失敗を改善したルールに変える仕組み。この層がなければエージェントは良くならない、という話です。

Daniel Agrici さん（動画 30:39〜）

And the learning process that turns mistakes into improved rules Without this layer an agent never gets better

私の訳: 失敗を、改善したルールに変える学習の仕組み。この層がなければ、エージェントは良くなりません。

学びの仕組みは、強化学習の発想です。良い仕事にはクッキーと10点。悪ければ小さな罰で点が引かれる、というたとえです。

実際の動きはこうです。検証役やレビュー担当がミスを見つけたら、学びのノートへ。エージェントは同じミスを繰り返さず、再発しても直し方がそこに残っています。

ここからチームの層です。エージェントが複数いる時の形は4つ。人と話し、簡単な頼みは自分で片づける窓口が1つ。専門のエージェントを選び、仕事の順番を決める調整役が1つ。

引き継ぎの形も1つ。どの割り当ても結果も同じ形なので、どのエージェントもほかのエージェントに仕事を渡せます。すべての役割が取り込む共通の土台も1つで、だから各エージェントのファイルは短く済みます。

原則の例も、いくつか。エージェントが誰かと、何をするかを分けること。共通の決まりはチームの層へ下げること。手順は1回書いて使い回すこと。入力と出力にはテンプレート。力を足す前に、制限を見ること。

そして、作った人以外の誰かと仕事を確かめること。失敗はすべて、ルールか、テストか、テンプレートの変更にする、と続きます。

Daniel Agrici さん（動画 33:10〜）

Check work with someone Other than the author And turn every mistake into a rule A test or a template change

私の訳: 作った人以外の誰かと、仕事を確かめる。そして、失敗はすべて、ルールか、テストか、テンプレートの変更にする。

準備ができたことも、分けて数える考え方。仕事の準備、エージェントの準備、実行する許可は、それぞれ別々の関門です。

原則は必須。Daniel さん自身の原則は真実だ、という言い方です。原則がなければ、人間は今も木の上でバナナを食べる哺乳類のまま。そんな冗談も混ざります。

結びは、エージェントの育つ速さの話。今までにない速さで、怖がる人もいる、という話です。全部を管理しようとしても、うまくいきません。ふさわしい実践とルールをそろえて、同期して暮らすこと。

Daniel Agrici さん（動画 36:05〜）

to live in proper sync With relevant practices and rules In place, and not having one Governing model of the world But having multiple ones, same as Countries, communities, cities

私の訳: ふさわしい実践とルールをそろえて、ちゃんと同期して暮らす。世界にひとつの統治モデルを置くのではなく、国や地域や都市のように、いくつもあるほうがいい。

世界にひとつの統治モデルを置くのではなく、国や地域や都市のように、いくつも持つほう。一人ひとりが自分のハーネスを持つ世界が、いちばん良い、という結びです。

失敗を、仕組みの変更に変える輪。そして、その輪のどこかに置く、作った人以外が確かめる位置。動画の筋道は、この2つでできているんですよね！

私の場合、同じ失敗はルールのファイル1本にまとめます。書く順番は、事故、原因、やること。何が起きて、なぜ起きて、次に何をするかを1枚に残す形。

同じ指摘が繰り返されたルールは、確認画面を出す手前で止める検査にしました。たとえば、作り方を相談する確認画面は、すでに作ってある物を探した跡がないと出せません。

あ、全部を検査にしたわけではなくて、同じ指摘が繰り返されたルールだけ。書いて残す物と、出す前に見る物を、分けて持っている形です。

私の記事より（Claude Codeのスキルとメモリに指摘を残し、エージェントの同じ間違いを防ぐ・自己進化する記憶は、/note と /calibrate で指摘を残すの節）

私なら、注意書きは、毎回読まれる場所へ置きます。

この記事に書いたのは、注意書きは毎回読まれる場所へ置く、という話。

動画では、失敗をルールやテストやテンプレートに変えます。私の記事は、置き場所の話。変える物は違っても、置き場所を決める所は同じです！

書いて終わりにせず、どこに置くかまで決めておくこと。ここが抜けると、書いたルールは読まれないまま残ります。

私は、一つのボールは、人でもAIでも仕組みでも、誰か一人の持ち主が全部を持って、最後までやり切る形にしたいんです！

持ち主が1人なら、失敗を受け止める先も1つ。確かめる役は、その持ち主とは別に置く形。作った人以外が見る、という動画の話とも、この形はつながります。

で、動画の結びの、一人ひとりが自分のハーネスを持つ世界。これは Daniel さんの主張で、私の話と向きは近くても、同じ話ではありません。

失敗は、仕組みを1つ変える合図。

動画の筋道は、自分が誰かを書いた小さなファイルから。役割と声を分け、リンクしてコピーせず、作業を記録し、承認が要る範囲を決め、失敗をルールに変える流れでした。

この動画から私が持ち帰ったのは、5つのこと。置き場所を先に決めること。正本を1か所にして、ほかは参照にすること。全部ではなく、辿れる形で残すこと。外に出る一手を、はっきり決めておくこと。失敗を仕組みの変更に変えること。

私の手元の決まりも、起動用のファイルを小さく保ち、正本を1か所に決め、同じ失敗はルールのファイルに残す形です。向きとしては、動画の話と同じ方を向いています！

AIに仕事を任せる時、みなさんが最初に決めておきたい置き場所は、どこですか？