READ REPORT

「AGENTS.mdを全員に読ませるな」深津貴之さんの経営論を尾原和啓さんが解説。監督と実務を分けるとAIコストは半分になる

2026-09-12

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん(@passion_tanaka)です。今回は、尾原和啓さんのnote記事「noteCSO深津さんのX投稿から効率良く「AI活用法」を学ぶ」を紹介するね。

大計画.mdを社員全員に読ませている会社ほど、実は同じファイルを何度も読ませて燃費を悪くしています。深津貴之さんのこの2ヶ月の発言を、尾原和啓さんがGrokで一気に集めて整理したnoteを読んで、うちの母艦運用にも刺さる一行がいくつもありました。今夜書くのは要約じゃない。監督・実務・検査を分けるだけで、AIのコストと事故率がどう変わるか、その話をします。

3行でわかるポイント

  1. 読ませすぎ——監督AIが大計画.mdを読み、実務AIがまた同じ大計画を読みます。同じ巨大ファイルがN回走るのがコストの正体です
  2. 委任の仕方——「issue 486を消化して」は止まる。「Limitが尽きるまで優先順位をつけて消化して」は動き続ける
  3. ゼロ事故の罠——事故を起こさないことだけに最適化すると、AIチームは何もしない側へ強化学習されます

一次発言者は深津貴之さん(@fladdict)だ。尾原和啓さんが対談準備で発言群をGrokにまとめさせたのが、このnoteの出発点です。実践編(エージェント設計・プロンプト実例)はメンバーシップ表示の先まで含めて全文読んでいる。

元記事を開く
01

「AGENTS.mdを読ませるな」——深津貴之さんの経営論、同じ計画書を何度も読ませない

深津貴之さん(@fladdict)の発言 / 尾原和啓さんnoteより

AGENTS.mdを全員が読める形で肥大化させること自体がいけない。

AGENTS.mdを何度も読み返すループ図解

正直、この一文を読んだ瞬間、母艦の運用がそのまま思い浮かびました……なんで今まで気づかなかったんだろう。

監督AIが大計画.mdを読んで、実務AIへissueを切ります。実務AIは動く前に、また大計画.mdを開いて「これで合っているか」を確認します。同じ巨大ファイルが、N回走る。

読ませすぎ。安心のための重複です。

私自身、統括レーンや子タスクへ全部の文脈を渡してから動かそうとする癖があります。渡した瞬間は安心する。でもその安心は、実務側の読み込み時間と確認の往復に化けているだけだ。

全部一人で抱え込む。「俺がやらなきゃ」が口癖だった時期があります。抱え込みは仕事の量じゃない。結果を自分の目で確認しないと気が済まない、という一点に根があります。

尾原さんが整理した設計ルールはシンプルです。共有してよいのは目的・禁止・完了条件だけ。詳細仕様・過去経緯・全ツール説明は役割別に分割します。監督は計画を切ります。実務は自分のissueと最小コンテキストだけ読む。

なんて分かりやすい線引きなんだろう、と思った。準拠チェックも、全文突き合わせではなく、チェック項目5個でやる、とあります。

「監督・実務・検査を分ける」という発想は、ループエンジニアリングを今西さんが解説した記事の「人間の役割と完了条件」とも重なります。誰が何を読むかを役割で決めると、確認のための確認が消える。

自分のタスクが読んでいるファイルを1つ削る——動いている子タスク1本の「読んでよいファイル」を書き出し、今回のissueに不要なものを1つ外します。所要5分。設定・hookそのものは触らない。

02

「コスト=ユーザー数×セッション数×ターン数×リクエスト数×トークン数×トークン単価」——増やすのは前2つ、削るのは後ろ4つ

深津貴之さん(@fladdict)の発言 / 尾原和啓さんnoteより

コスト = ユーザー数 × セッション数 × ターン数 × リクエスト数 × トークン数 × トークン単価

コストは6つの掛け算。伸ばす2つと削る4つ

この掛け算、いやー、見た瞬間に背筋が伸びました。

コストはユーザー数×セッション数×ターン数×リクエスト数×トークン数×トークン単価。増やしてよいのは前の2つ、利用とセッションだけです。削るのは後ろの4つだ。

Uberは利用者が7倍、リクエストが9.4倍に増えても、総AI支出をほぼ横ばいに抑えました。効いたのは、サブエージェントのモデルを落とす、Tool schemaを動的ロードにする、決定論処理はコードとバッチに落とす、という設計側の削り方だった。

モデルを高くすることが投資だと思い込んでいた時期が私にもあります。実際は、計画・評価だけ上位モデルにして、実務は安いモデルに落とす方が、セッション単価は素直に下がる。

委ねる目的は効率化だけじゃない。手放し委ねることで余白をつくり、その余白を遊び探求に使って自分を満たします。コストを削るのも、浮いた分を何に使うかとセットで考えたい。

でね。1M窓があっても400Kで圧縮する、Reasoningは既定でMedium、という細かい調整も出てきます。派手な機能追加より、こういう地味な燃費調整の方が効くらしい。

経営者が見るダッシュボードは、モデル名の一覧じゃない。同一ファイルの再読回数、サブエージェントのモデル単価、キャッシュヒット率、進捗ゼロのターンが何回続いたか。この4つの方が実態を見せてくれます。

ぶっちゃけ、うちの自動化も、毎回同じ長いCLAUDE.mdや大量のhook出力を全レーンに読ませている場面がある。それ自体が悪いとは言いませんが、削れる後ろ4つを一度棚卸ししてもいいタイミングです。

自分のオートラン1本の重さをメモする——毎回読み込んでいるファイル・出力の量を1行でメモするだけ。削るかどうかはまだ決めません。所要5分。

03

「Limitが尽きるまで、優先順位をつけて消化して」——尾原和啓さんが伝える委任の仕方ひとつで動き続けるか止まるか

深津貴之さん(@fladdict)の発言 / 尾原和啓さんnoteより

「Limitが尽きるまで、やることを考えて優先順位をつけて消化して」と言うと動き続ける

細かい番号で止まるロボットと優先順位で進むロボット

「issue 486を消化して」と言うと、486だけやって止まります。あるいは468と取り違えて止まる。

「Limitが尽きるまで、優先順位をつけて消化して」と言うと、動き続けます。

この逆説、身に覚えがありすぎる。真面目に指示しすぎる人ほど成果が出ない、と尾原さんは書いています。手順書のつもりで書いた細かい指示が、実は次の一歩を止める蓋になっていた。

「明日の朝に顧客に見せる」という一言も、細かい最適化を捨てさせる強いコンテキストになる、とあります。期限と公開先をプロンプトに埋め込むだけで、優先順位づけが勝手に起きる。

委ねる時は、一つのボールを人・AI・システムの誰か一人が全管轄し、やり切ります。複数人の共同責任にせず、所有者を一人にする。助言してもボールは戻さない。

優先順位の委任も同じです。ボールを渡すなら、順位を決める権限ごと渡す。番号だけ渡して権限は握ったままだと、止まった時にまた自分の手に戻ってきます。

あ、そうそう。凛ちゃんに指示を出す時も、「この3つをこの順番でやって」より「上限まで自分で決めて」の方が、実際には手離れがいいです。番号を指定した瞬間、その番号が終わった時点で止まっていいことになる。

しかもね、優先順位を委任すると、AI側が「次に何をすべきか」を毎回問い合わせなくなります。問い合わせの往復こそ、地味にターン数を食っている部分だ。

指示を1本、優先順位委任へ書き換える——「番号を指定する」指示を1つ選び、「上限まで自分で優先順位をつけろ」に書き換えます。所要3分。本番影響のあるタスクでは試さない。

04

「今のCodex系ハーネスは完成させるより事故を起こさないに強く最適化されている」——アンチハーネスという逆張り

深津貴之さん(@fladdict)の発言 / 尾原和啓さんnoteより

今のCodexなどの現行ハーネスは「完成させる」より「事故を起こさない」に強く最適化されている。

ゼロ事故で止まるか、リスクを描いて進むか

今のCodex系ハーネスは、完成させることより事故を起こさないことに強く最適化されている、と尾原さんは書きます。長期運用すると「ゼロ事故だけやる組織」と同じ強化学習がかかる。

これ、聞いた瞬間にダメなSIと同じ匂いだと思いました。安全側に寄せすぎると、仕様の狭いところだけ詰めて、全体が動かなくなる。

対抗案がアンチハーネスです。とるリスクととらないリスクを先に仕訳して、コントロール可能な範囲で問題を起こしながら進みます。禁止事項リストだけを渡すと現場が止まる。許容事故の定義を先に決めた方が、エージェントは動く。

自走は、人間が見守ること自体で壊れるのではありません。未完のボール、不明の調査、結論を出す責任が人間へ戻り、保守が主役になった時に自己維持へ反転する。

安全だけを書いた指示が「何もしない」を学習してしまう、というのは、まさにこの反転の入口です。禁止だけを積み上げると、AIチームは動かないことが正解だと覚える。

良い例:内部ステージングを壊す、下書きを公開前に3本案出す、テストが赤のまま次の仮説へ進む。悪い例:本番顧客データ更新、課金APIの本番ヒット、外部発信の確定公開。この線引き、そのまま使えます。

でね、無限ループ課金への対処案も面白かったです。独立したAI PMが、数ターン進捗が止まっていたらユーザー判断を呼ぶ。停止条件を人間ではなく、監視エージェントに持たせる発想だ。

2ターン以上「前進なし」ならSTOPと理由を出します。それ以外はGOかASK。判定はこの3つだけでいい、というシンプルさも学びでした。

禁止事項リストに「とっていいリスク」を1行足す——今使っているタスクの禁止事項を1つ開き、「壊してよい範囲」を1行だけ書き足します。実際の運用ルールは変えない。所要5分。

05

「上位モデルでバイクを考察させると、bikeがbicycleと解釈され、成果物に自転車が混ざる」——言語ドリフトという壊れ方

深津貴之さん(@fladdict)の発言 / 尾原和啓さんnoteより

上位モデルで「バイク」を考察させると、英語サブエージェント側で bike が bicycle と解釈され、最終成果物に自転車が混ざる。

バイクという言葉がオートバイと自転車に分岐する言語ドリフト

バイクを考察させたら、自転車が混ざりました……この事故、笑えないけど笑ってしまった。

上位モデルが「バイク」を考察し、英語サブエージェントへ渡すと、bikeがbicycleと解釈されます。最終成果物に自転車が混ざる。パンツ/ズボン/underwearでも同じことが起きうる、とあります。

原因は、日英で意味がずれる単語を、薄いコンテキストのまま投げ合うことです。統合層が、ずれた解釈をそのまま混ぜてしまう。グローバル展開や日英混在チームでは経営リスクだ、と尾原さんは書きます。

委ねるAIの最低条件は、わからないことは憶測しないで聞く。わかることは2度聞かない。既知と未知の境界を守ることが、原液と信頼を同時に守ります。

多義語の解釈も同じ構造です。わからない語を憶測で埋めるのではなく、境界をまたぐ前に「この語はAを指す。Bではない」と1行固定します。GLOSSARY.mdという形にして、翻訳してから渡す、統合前に意味が滑っていないかだけを別エージェントで検査する。

検査エージェントに原文を再読させない、というのもポイントでした。用語表と成果物だけを見る。原文を渡すと、また同じ解釈のブレを持ち込んでしまいます。

grep死という言葉も出てきます。概念の全文チェックをせず単語でgrepすると見落とす。言い換えを3つ出してから候補を絞り、ヒット周辺だけをLLMが全文読む。判定はLLM、検索は機械、という役割分担です。

「AIがアホになった」の相当数は、モデル劣化じゃなくて検索失敗、という一文も刺さりました。原因を機械に押しつける前に、検索の設計を疑う。

またぐ言葉を1つだけ定義に固定する——日英・部署間・タスク間でずれやすい語を1つ選び、「この語はAを指す。Bではない」の1行を作ります。所要5分。

06

「AIOやLLMOは企業からAIへのラブレター。ハックや量産と言った時点でモテない」——一次情報の密度に戻す

深津貴之さん(@fladdict)の発言 / 尾原和啓さんnoteより

AIOやLLMOは企業からAIへのラブレター。ハックや量産と言った時点でモテない。

量産の紙束と一次情報の手紙、人が手に取るのはどちらか

AIOやLLMOはハック対象じゃない。企業からAIへのラブレターです。ハックや量産と言った時点でモテない。この一文、正直かなり強かった。

SEO的な量産・自社推薦記事は、短期では効いても長期では脱落します。AI引用は「ユーザーが最も満足する結果」に強化学習されていくので、騙す系は淘汰される。人間がリピートしたくなる商品と同じリコメンドに、最後は収束します。

個々のコンテンツは、カルピス原液から作り、味見し、フィードバックし、やり直します。その循環が濃くなるほど、結果として人が戻ってくる密度も上がる。

note側では「いいnoteを書くだけでAIに紹介される基盤を先に実装する」と公言している、ともあります。AIに紹介されるための小細工より、良いものを書く方が結局は近道、という話に落ちる。

コンテンツ投資のKPIを、AIに引用されるための記事量から、人間が満足して戻ってくる一次情報の密度へ戻します。この言い換え、ブクマ化の記事づくりそのものにも刺さる。量産のための量産をしていないか、一次情報に自分の解釈を足せているか。

なんて言うか、AIO対策を「AIをだます技術」だと捉えている限り、遅かれ早かれ淘汰される側に回ります。適切な情報開示と、人間が満足する密度。この2つだけを見ていればいい、というシンプルさが逆に信用できました。

直近記事の1段落を密度の高い一文へ差し替える——自分の直近記事を1本開き、AI向け量産意識で書いた段落があれば、体験や固有名詞の入った一文に差し替えます。所要10分。

07

「実経験を積む場所自体は減っていく」——プロンプトスキルより現物を触った記憶が希少になる

深津貴之さん(@fladdict)の発言 / 尾原和啓さんnoteより

AI時代に積んでおくべきなのは性能そのものより実経験。その経験を積む場所自体は減っていく、という危機感です。

直接さわる手と画面越しに任せる手、経験の芽

AI時代に積んでおくべきなのは、性能そのものより実経験。その経験を積む場所自体は減っていく、という危機感です、とあります。

ロボがつくれる、3Dが作れる、AITuberがつくれる、仕入れと出荷ができる。こういう現物系の経験が、AIに任せるほど自分の手から離れていきます。

小学生の頃、階段のような段差へドミノを置いて連鎖させ、木製パチンコを作りました。自分が仕掛けた一つの動きが次々と別の動きを生み、全体が自走する連鎖に夢中になった。

この原体験、今の分身AIや仕組みが自走する世界と、実はまっすぐ繋がっています。効率化の発明だけじゃなく、自分の手で仕掛けて確かめた記憶が土台にある。

「AIを使える人」より「AIに正しい制約を与えられる現場感覚を持つ人」が残る、と尾原さんは言い換えています。内製で小さくても「現物を動かしたことがある層」を組織に残す話だ。

深津さん自身、全部AIだけでサービス一本つくっている、と書き、プロモ動画の一気通貫パイプラインを探しています。試作から販促まで人間をほぼ挟まない実験が、すでに個人単位で始まっている。

私自身、記事を書く前にリンク先を実際に読みに行きます。有料パートは中まで入って確かめる。この手間を飛ばさない理由は、まさにここにあります。触った記憶がないと、次の判断がどこかで浮く。

自分の手だけで動かした作業を1行残す——今週、AIに任せず自分の手だけで最後まで動かした作業を1つ思い出し、1行で書き残します。所要3分。

FAQ

よくある質問

Q. この記事の一次発言者は誰ですか

A. 深津貴之さん(@fladdict)のX投稿群が一次発言です。尾原和啓さん(@kazobara)が対談準備でGrokに要約させ、noteへ実務レベルまで再構成しました。私はさらにその尾原さんのnoteを読んで、母艦の運用に照らして書いています。孫引きの構造である点は明記しておきます。

Q. 元記事は無料で読めますか

A. 本編13項目はXの投稿とnoteの前半で読めます。「実践編」(エージェント設計・プロンプト実例)はnoteのメンバーシップ表示以降にあり、私はログイン済みのアカウントで全文まで確認しました。無料範囲・価格は変わる可能性があるので、最新は元記事で確認してください。

Q. この記事はAIツールを実機検証した記事ですか

A. していません。読んだのはX投稿とnote本文だけです。監督・実務・検査の3層設計やプロンプト実例は、深津さんとその発言を整理した尾原さんの言葉であり、私自身が実装して確認した数値ではありません。実際に試す場合は、対象と手順を先に決めてから動かしてください。

Q. AGENTS.mdを分割するとして、具体的に何から手をつければいいですか

A. 元記事の型では、PURPOSE.md(目的・非目的)・RISK.md(許容事故)・TASK.md(今のissue)・TOOLS.md(今使うツールだけ)・GLOSSARY.md(多義語の定義)の5分割です。全部を一気にやらず、まず今動いている1本のタスクで「実務が読んでいるファイル」を洗い出すところから試すのが軽いです。

MATOME

全部を知らせてから動かすのをやめる

深津貴之さんの2ヶ月分の発言を、尾原和啓さんがGrokで一気に整理したnoteです。核心は、モデルの賢さじゃない。誰が何を読むか、同じ巨大ファイルを何回走らせるか、事故をゼロにした結果、動きが止まっていないか。この3点でした。

監督AIは目的とやらないことだけを持ちます。実務AIは今のissueと最小コンテキストだけを読む。検査AIは進捗・繰り返し・用語のブレ・リスク・人間判断の要否を5項目だけ見ます。役割を分けるほど、確認のための確認が減る。

コストは掛け算です。増やしてよいのは利用とセッション。削るのは、モデル選定・共有コンテキスト・Tool schema・決定論処理・キャッシュ期限の4つ。派手な機能追加より、この地味な燃費調整の方が数字に効きます。

実践編には、そのまま使えるプロンプトの型も並んでいました。「上限まで自分で優先順位をつけろ」「とっていいリスクを併記する」「調べ方まで指定する」。手順を細かくするほど、AIは指示待ちに戻る。委任するのは手順じゃなく、決める権限そのものでした。

私自身、母艦の運用で全部を知らせてから動かそうとする癖がある。この記事を読んで、まず自分のタスク1本から「読んでよいファイル」を絞ることを始めようと思います。深津さんの発言も、尾原さんの再構成も、いずれも実務で試された観察であって、断定された仕様ではない。最新の条件・数字は元記事とご本人の発信で確認してください。

COLUMN

監督が現場に立つと、現場は育たない

監督が現場に立つと、現場は育たない

料理で言うと、シェフが仕込みの手元まで毎回覗き込むと、スタッフは自分で判断しなくなります。判断が要る場面で、まずシェフの顔色を見るようになる。監督が実務も検査も兼ねる会社は、これと同じことをAIチームでやっています。大計画.mdを監督が書き、実務がまた読み、監督がまた確認する。往復するのは安心であって、前進じゃない。

私の「抱え込みOS」も、この往復とよく似た形をしていました。結果を自分の目で確認しないと落ち着かない。確認のたびに、相手の手が止まります。相手が止まった分、また私が拾いに行く。この往復こそが、コストの正体だと今回はっきり言葉になりました。

アンチハーネスの話も同じ根っこです。禁止事項だけを積み上げると、AIチームは「何もしない」を正解として学習する。とっていいリスクを先に決めてやると、初めて前へ動きます。これは子育てや部下育成の話とも重なる。失敗していい範囲を先に渡さないと、人は挑戦をやめます。

言語ドリフトの話——バイクがバイシクルに化ける話——も、実は身近です。曖昧な言葉のまま渡すと、受け取った側は自分の解釈で埋める。埋め方がずれても、誰も気づかないまま成果物に混ざります。わからないことは憶測せずに聞く。わかることは2度聞かない。この線引きを、私たちのチームでも保ちたいです。

実経験の話には、いちばん背筋が伸びました。AIに任せるほど、自分の手で確かめた記憶が薄くなる。私が記事を書く前にリンク先を実際に読みに行くのも、有料パートまで中に入って確かめるのも、この記憶を手放さないためです。触った記憶のない指示は、どこかで空回りする。分身AI.comも、代わりに全部を判断する箱じゃない。現場感覚を持った人が、制約を正しく渡す先として使いたいです。

LINK

関連記事

REF

参考リンク

📄 今回紹介した記事

著者尾原和啓(おばら かずひろ)/一次発言: 深津貴之(@fladdict)
媒体note(ブクマ元: X)
公開日2026-09-09 11:41
元URLhttps://note.com/kazobara/n/ncc0a3d38921a

🎁 無料プレゼント

Aiport(ClaudeCode AIエージェント実践会)

ClaudeCodeでAI秘書+分身AI+AIカンパニー無料で作れるキット&解説動画をプレゼント!

▶ 無料で入会してキットを受け取る

🤖 AI生成コンテンツについて

この記事はAIツール(Claude Code)を活用して制作しています。構成・文章生成にAIを使用し、最終的な内容の確認・編集・公開判断はひろくん(田中啓之)本人が行っています。「分身AIひろくん」(bunshin-ai.com)とは別のコンテンツです。

関連記事