Googleが示した次のAI資産は、なぜ「プロンプト」ではなく「作業ルール」なのか
AGENTS.md / SKILL.mdが示す、AI活用の勝ち筋の変化
AI活用で一番しんどいのは、毎回うまいプロンプトを考えることではない。
本当にしんどいのは、毎回同じ品質でAIに仕事をさせることだ。
Google I/O 2026まわりの発表を見ていて、自分はそこに答えが出始めたように感じました。
注目したのは、Geminiのベンチマークそのものではありません。
AGENTS.mdやSKILL.mdのような、「AIに仕事の進め方を読ませるファイル」が前面に出てきたことです。
モデルが賢くなるほど、差が出る場所はプロンプトではなく、作業ルール・実行環境・運用設計に移る。
今日はこの話を、GoogleのManaged Agents発表と、自分のnote制作パイプラインの実感をつなげて考えてみます。
この記事でわかること
✅ Google Managed Agentsで何が変わりそうなのか
✅ AGENTS.md / SKILL.mdがなぜ象徴的なのか
✅ Googleはモデル性能競争から降りたのか、それとも主戦場を変えたのか
✅ CodexやClaude Codeと比べた時のGoogleの強みは何か
✅ プロンプト資産と作業ルール資産は何が違うのか
✅ 個人が今から残すべき3つのファイル
🧭 Google発表で気になったのは、モデル名ではなく作業ルールだった
Googleの発表を見ると、つい「Gemini 3.5 Flashはどれくらい賢くなったのか」を見たくなります。
もちろん、そこも重要です。
実際、GoogleはGemini 3.5 Flashについて、エージェントやコーディング、長期タスク向けの性能をかなり強く打ち出しています。
でも今回、自分が一番引っかかったのはそこではありませんでした。
Managed Agentsの説明では、1回のAPI呼び出しで、隔離されたLinux環境上にエージェントを立ち上げ、推論、ツール利用、コード実行、ファイル操作、Web閲覧まで扱える方向が示されています。
そして、そのエージェントに読ませる指示やスキル、データを、AGENTS.mdやSKILL.mdのようなMarkdownファイルとして定義できる。
ここが面白い。
これはもう「賢い返事をするAI」だけの話ではありません。
AIが作業環境を持ち、ルールを読み、状態を持って仕事を進める方向に話が移っています。
🧠 Googleは性能競争から降りたのではなく、主戦場を変え始めた
ここは少し慎重に書きたいところです。
「Googleはモデル性能競争から降りた」と言い切ると、たぶん雑です。
GoogleはGemini 3.5 Flashの性能も、速度も、エージェント適性もちゃんと語っています。
だから正確には、こうだと思っています。
Googleは性能競争から降りたのではなく、性能だけを主役にする競争から降り始めた。
モデルの賢さは、もちろん必要です。
でも、モデルだけが賢くても、現場の仕事は進みません。
必要なのは、そのモデルがどこで動くのか。
どのデータを読めるのか。
どのツールを使えるのか。
どんな判断基準を守るのか。
どこまで自動で進め、どこから人間に返すのか。
つまり、競争の中心が「モデルのIQ」から、「現場で働ける状態にする設計」へ広がっているように見えます。
自分には、これがかなり大きな変化に見えました。
🗂 AGENTS.mdとSKILL.mdが出てきた意味
AGENTS.mdやSKILL.mdという名前を見ても、最初はピンとこない人もいると思います。
ざっくり言うと、こうです。
AGENTS.mdは、AIに読ませるプロジェクトの前提・禁止事項・優先順位
SKILL.mdは、特定の作業をするときの手順・判断基準・チェックリスト
プロンプトは、その場で入力するお願いです。
一方で、AGENTS.mdやSKILL.mdは、AIが毎回読む仕事の型に近い。
この違いは大きいです。
たとえば、毎回チャットでこう説明するのは大変です。
この記事では、読者の痛みから入り、タイトルはSEOだけでなくスキも意識して、画像はサムネと本文図を分けて、公開前にraw tableが残っていないか確認してください。
でも、それがルールファイルに書かれていれば、AIは最初からその前提で動けます。
しかもMarkdownファイルなら、Gitで履歴を残せます。
チームで共有できます。
作業ごとに分けられます。
ひとつの巨大なシステムプロンプトに全部詰め込むのではなく、「この記事を書くときはこのルール」「画像を作るときはこのルール」のように分けられる。
ここに、AI活用の資産性があると思っています。
🤔 では、CodexやClaude Codeと何が違うのか
ここで一度、ちゃんと整理しておきたいです。
AGENTS.mdやSKILL.mdのような発想は、Googleだけのものではありません。
CodexにもAGENTS.mdがあります。
Claude CodeにもCLAUDE.mdがあり、AGENTS.mdを読み込む運用や、スキル・ルール・メモリの考え方があります。
だから、今回のGoogle発表を見て、
それ、CodexやClaudeでもできる話では？
と思う人はたぶん自然です。
自分もそこは同じ感覚でした。
ただ、見ていると各社の強みは少し違います。
Codexの強みは、コード実装をPRに近い形まで持っていくこと。
リポジトリを読み、ファイルを編集し、テストやlintを回し、差分として確認できる。
「このバグ直して」「この機能を追加して」「このUIを実装して」のような、ソフトウェア開発の実作業にかなり寄っています。
つまりCodexは、作業ルールを読んだうえで、コードベースの中で成果物を作るのが強い。
Claude Codeの強みは、文脈を育てながら、ローカルの作業に深く寄り添うこと。
CLAUDE.md、スキル、メモリ、フック、MCPのような周辺機構を組み合わせて、プロジェクトごとの癖や、ユーザーの判断をかなり細かく残せる。
特に、長い文脈を読みながら「このプロジェクトではどう判断するか」を一緒に育てていく感じが強い。
つまりClaude Codeは、人間の作業スタイルや判断基準に寄せていくのが強い。
では、Googleの強みは何か。
自分が今回いちばん気になったのは、AGENTS.mdやSKILL.mdというファイル名そのものではありません。
Googleがそれを、Gemini API、Managed Agents、安全なクラウドサンドボックス、Google AI Studio、企業向けのエージェント基盤に載せようとしていることです。
つまりGoogleは、作業ルールを読むAIを、個人の開発環境の中だけではなく、APIとして呼べる管理されたエージェント基盤にしようとしている。
ここが違いに見えます。
かなり雑に言えば、こうです。
Codex: repoの中で実装して、テストして、PRに近づける
Claude Code: 人間の文脈や判断を育てながら、作業に深く付き合う
Google/Gemini: ルール・スキル・データをまとめて、API/クラウド基盤として動かす
だから、Googleの強みは「AGENTS.md / SKILL.mdを持っていること」ではない。
それをGoogleのインフラとAPIの上に載せようとしていることだと思います。
この見方をすると、Googleはモデル性能だけで勝負しているのではなく、AIをサービスや業務の中に組み込むための土台を作りに来ているように見えます。
📊 プロンプト資産と作業ルール資産は何が違うのか
自分の感覚では、プロンプトは速いです。
思いついた瞬間に試せるし、うまくいけばすぐ結果が出ます。
でも、残りにくい。
別の日に同じ品質で再現しようとすると、「あれ、前はどう頼んだっけ？」となる。
作業ルールは逆です。
最初に作るのは少し面倒です。
でも一度書いておくと、次のAIも、その次のAIも読めます。
記事のタイトル基準。
禁止表現。
レビュー観点。
画像の置き方。
公開前チェック。
これらが残っていると、AIの出力は少しずつ自分の判断に近づいていきます。
神プロンプトを探すより、自分の仕事をAIが再現できる形で残す。
自分は、こっちの方が長く効く気がしています。
🛠 自分のnote制作でも、資産はプロンプトではなくルールになっている
これは、自分のnote制作でもかなり実感しています。
最初のころは、毎回チャットでがんばって説明していました。
「タイトルを強くして」
「もっと読者の痛みに寄せて」
「画像はかわいいだけじゃなく、見出しの意味がわかるものにして」
「公開前に表や画像の数を確認して」
でも、それだと毎回ゆらぎます。
AIは賢いけれど、前回の自分の違和感を勝手に覚えてくれるわけではありません。
だから最近は、強いフィードバックが出たら、なるべくMDに残すようにしています。
たとえば、note制作ではこういうルールが効いています。
タイトルは SEO / suki / monetization のどのレーンか先に決める
冒頭はニュース概要ではなく、読者の困りごとから入る
サムネは惹き優先、本文図は1見出し1論点
raw Markdown tableは公開noteに入れず、PNG化する
公開前に publish_lint で画像数やリンクを確認する
強いユーザーFBは、チャット内で消費せず次回も読めるMDに残す
これらは、単体で見ると地味です。
でも積み上がると、AIが毎回迷いにくくなります。
一回のプロンプトをうまくするより、AIが迷わない道を少しずつ作る。
GoogleのAGENTS.md / SKILL.mdの話を見て、自分の中でこの実感がかなりつながりました。
💡 個人が今から残すべき3つのファイル
では、個人は何を残せばいいのか。
自分なら、まず3つで十分だと思います。
1つ目は、AGENTS.md的なファイル。
ここには、プロジェクトの目的、やってはいけないこと、優先順位を書きます。
たとえば、
誰に向けた記事なのか
何を公開してよくて、何を出しすぎてはいけないのか
文章で大事にするトーン
作業で必ず確認すること
2つ目は、SKILL.md的なファイル。
ここには、よく繰り返す作業の手順を書きます。
記事を書く。
画像を作る。
レビューする。
公開前チェックをする。
こういう作業ごとに、AIへ読ませる手順書を分ける。
3つ目は、lintやレビュー用チェックリストです。
AIに自由に作らせるだけではなく、最後に機械的に確認する場所を作る。
表が残っていないか。
画像が足りているか。
リンクが正しいか。
タイトルと本文の約束がズレていないか。
この3つがあるだけで、AI活用はかなり「その場のお願い」から「育つ仕組み」に変わります。
🧪 テンプレ化するなら、ここから先が価値になる
ここから先は、無料で全部出すか、有料部にするかをまだ迷っています。
でも、もしテンプレとして出すなら、単なる追加説明では弱い。
読者が半日迷わないための成果物にしたいです。
たとえば、
自分用AGENTS.mdの最小テンプレ
自分用SKILL.mdの最小テンプレ
note制作で実際に効いたルール抜粋
失敗しやすい書き方
AIに読ませる前のチェックリスト
こういう形なら、単なるニュース解説ではなく、読者が自分の仕事へ持ち帰れます。
✅ まとめ
Googleの発表を見て、自分は「また新しいモデルが出た」というより、「AIをどう働かせるかの標準化が進んでいる」と感じました。
モデルはこれからも賢くなる。
でも、どのモデルも十分賢くなっていくなら、差が出るのは別の場所です。
どんなルールを読ませるか。
どんな環境で動かすか。
どんなチェックで止めるか。
どんな失敗を次回のMDに残すか。
AI時代の資産は、プロンプト集だけでは足りない。
自分の仕事をAIが再現できる形で残すこと。
たぶん、ここからが本番です。
参考:
