こんにちは、Lena です。数ヶ月前、あるエージェントがコードベースを処理しているのを見ていたとき、それはただ…止まりませんでした。一時停止も、確認もなし。頼んでいない3つのファイルを書き換えた後、さらに4つのファイルにも同じことができると親切に提案してきました。コード自体は間違っていたわけではありません。でも、私が必要としていた形では正しくなかった。

そのとき、これらのエージェントが実際にどう制約されているのかに注目し始めました。エージェントが何かをできるかどうかではなく、何をすべきかをどう伝えるか。そしてもっと重要なのは、まず聞かずには絶対にすべきでないことをどう伝えるか、ということです。

これが、エージェントワークフローにおける「超能力（superpowers）」という言葉の本当の意味です。少し誤解を招く言葉だと思います。超能力とは、生の処理能力のことではありません。その能力がどう使われるかを形づくること — 一貫して、再現可能な形で、エージェントが実行するすべてのセッションにわたって。それが本当の超能力です。

エージェントワークフローにおける「超能力」の本当の意味

機能ではなく — 行動制約システム

「超能力」という言葉が機能を指して使われるのをよく見かけます。コード実行、ウェブ検索、ツールアクセス。 それも一つの読み方です。しかし、実際にエージェントを本番環境で運用している人たちの会話を聞いていると、話題はほとんど常に別のことに向かっています。

それは制約システムです。

問題は「このエージェントは何ができるか？」ではありません。問題は「望んでいなかったことをエージェントがやるのを止めつつ、望んでいたことはやらせるにはどうすればいいか？」です。これはガバナンスの問題です。そしてガバナンスには、一貫して適用されるルールが必要です — プロンプトに貼り付けて従ってくれることを祈るようなリマインダーではなく。

エージェントにはツールだけでなくルールが必要な理由

かなり早い段階で気づいたことがあります。行動制約のないエージェントは悪いわけではなく、予測不能なのです。半分の確率で正しい答えを出し、残りの半分でまったく予想外のことをします — モデルが壊れているからではなく、行動をあなたの基準に固定するものが何もないからです。

ツールはエージェントにリーチを与えます。制約はエージェントに方向を与えます。

ほとんどのチームはこの違いに偶然たどり着きます。ツールを追加し、エージェントを走らせ、エージェントが自分で決めた何かに驚き、それからルールを書き始める。失敗のパターンが、制約があるべきだったものを教えてくれるのです。

主要ツールにおける超能力の仕組み

Claude Code — skills、CLAUDE.md、パーミッションスコーピング

Claude Code は、この問題に対して最も構造化されたアプローチを持っていると思います。中核のメカニズムは SKILL.md ファイル です — YAML フロントマターを持つ Markdown ファイルで、指示、スクリプト、参考資料を、関連するときに Claude が動的にロードできる形にバンドルしたものです。

この設計で本当に興味深いのは、Anthropic が「progressive disclosure（段階的開示）」と呼んでいるものです。セッション開始時、Claude はインストールされた各 skill の名前と説明だけをロードします — 全文ではありません。完全な指示がロードされるのは、Claude がそのスキルが現在のタスクに関連すると判断したときだけです。公式の agent skills ドキュメントが説明しているように、skill は新入社員向けのオンボーディングガイドのようなもので、エージェントは必要な章だけを読みます。

CLAUDE.md もあります — プロジェクトルートに置かれ、セッション全体を通じて常に指示を保持する永続ファイルです。skill とは違い、常に存在しています。ベースラインの契約書と考えてください。アーキテクチャの決定事項、ファイル規約、エージェントに推測やスキップを絶対にさせたくないこと、それらを記述する場所です。

パーミッションスコーピングはツールレベルで機能します。 skill の YAML フロントマターで allowed-tools を定義することで、その skill が呼び出せる bash コマンド、ファイル操作、API を制限できます。この詳細を完全に理解するのには時間がかかりました。エージェントが何を知っているかだけの話ではありません。エージェントが何にアクセスを許可されているか、という話です。

まだ完全に確信が持てないことが一つあります。セッションが長くなり、コンテキストウィンドウが圧縮され始めたとき、これらの制約がどの程度維持されるのか。Claude Code のドキュメントによると、自動圧縮は呼び出された skill を引き継ぎますが、一つのセッションで多くの skill をロードすると、古いものが削除される可能性があります。これに関連するかもしれない行動のドリフトに気づいたことがあります。考えすぎかもしれませんが、ランダムとは感じません。

Cursor — rules、.cursorrules、MDC フォーマット

Cursor はレイヤー型のアプローチを取っています。3つの階層があります。User Rules（グローバル、すべてに適用）、Project Rules（バージョン管理対象、.cursor/rules/ に配置）、そしてプロジェクトルートにある旧来の .cursorrules ファイルです。.cursorrules フォーマットは2026年初頭時点でもまだ動作しますが、Cursor の公式ドキュメントは廃止予定であることを明確にしています — 推奨される移行先は、スコーピングと制御を改善した .mdc プロジェクトルールシステムです。

MDC フォーマットは、.cursorrules にはないメタデータ層を追加します。ルールを alwaysApply に設定したり、特定のファイル glob に紐づけたり、エージェントが関連性を判断したときにだけロードされるようにしたりできます。最後のオプション — エージェントが要求するルール — は、見た目以上に興味深いものです。ルールシステムがコンテキストに応じて動作できることを意味します。フロントエンドのルールはバックエンドのファイルではロードされず、決済サービスの制約が無関係なモジュールに漏れ出すこともありません。

実際に時間をかけて使ってみて分かったことがあります。最も効果的なルールは、具体的で命令形のものであり、曖昧で理想的なものではありません。「すべての新規ファイルに TypeScript を使用」は機能します。「クリーンで保守しやすいコードを書く」は何の効果もありません。何が欲しいか — あるいは明確に欲しくないものは何か — を正確に記述すればするほど、エージェントはより一貫して従います。

Cursor には AGENTS.md もあります。フルのメタデータオーバーヘッドを必要としないプロジェクト向けの、プレーンな Markdown の代替手段です。よりシンプルで、柔軟性は少し劣ります。

Codex CLI — AGENTS.md とレイヤー型指示ディスカバリー

OpenAI の Codex CLI には、理解する価値のあるクリーンな指示階層があります。セッション開始時、Codex はドキュメントが「instruction chain（指示チェーン）」と呼ぶものを構築します — グローバルの ~/.codex/AGENTS.md から読み取り、プロジェクトルートから現在のディレクトリまで走査しながら、途中にある AGENTS.md ファイルをすべて拾い上げます。現在のディレクトリに近いファイルが、先に読まれたガイダンスを上書きします。

Codex のカスタム指示ドキュメントによると、任意のレベルに AGENTS.override.md ファイルを置くことで、上書きの意図を明示的にすることもできます。モノレポや要件が大きく異なるサービスを持つチーム — たとえば決済チームとアナリティクスチーム — にとって、これは共有のベースラインルールとサービス固有の制約を持ちつつ、互いに意図せず漏れ出すことがないことを意味します。

Codex は最近、同じ SKILL.md パターンも採用しました。Codex の skills ドキュメントには、同じ段階的開示のアプローチが記述されています。skill のメタデータが先にロードされ、完全な指示は skill が呼び出されたときにだけロードされます。異なるプロバイダー間でも、エコシステムは共通のデザイン言語に収斂しつつあります。

厳格な承認と狭いサンドボックス権限がデフォルトとして正しい — 影響範囲を理解している特定のワークフローに対してのみ緩和すべきです。

パターン：GitFlow + TDD + コードレビューの自動化

brainstorming → writing-plans → executing-plans

これは私が何度も立ち返るワークフローパターンです。構造は、エージェントタスクを異なるフェーズに分割し、各フェーズを異なる skill が管理するというものです。

brainstorming の skill は問題空間を開き、選択肢を生成し、エッジケースを洗い出します。コードは書きません。次に planning の skill が引き継ぎます — 構造化されたプラン、触るべきファイル、先に書くべきテスト。プランが存在して初めて、executing の skill が実際の変更を開始します。

これは GitFlow + TDD + コードレビューの構造を映しています — ただし、エージェントが3つの役割すべてを担い、それぞれで異なる行動プロファイルを持ちます。brainstorming の skill は推測できます。executing の skill は承認済みプランに従うよう制約されます。

なぜこれが失敗を減らすのか。各フェーズの成功基準がより狭いからです。「brainstorming」中のエージェントは、うっかり本番コードを書いたりしません。「executing」中のエージェントは、実装の途中でアーキテクチャを再設計したりしません。

このパターンを使い始めたのは、あるエージェントがリファクタリングで40分間堂々巡りするのを見た後でした。自分の決定を何度も再評価し続けていたからです。フェーズを分離してもエージェントが賢くなったわけではありません。プロセスがより安定したのです。

制約 vs ガバナンス

ローカルな行動ルール vs ネットワークレベルの能力ライフサイクル

ずっと気になっているギャップがあります。正直、まだどう解釈すべきか分かりません。

上で説明した制約システムはすべてセッションスコープです。ローカルなものです — ファイルに存在し、セッション開始時にロードされ、セッション終了時にリセットされます。既知のコードベース、既知のチーム、既知の一連の基準に対する行動を定義するのには優れています。

しかし、別の種類の問題は解決しません。エージェントのライフサイクル全体にわたって、行動はどうなるのか？ 3ヶ月前に有効だった制約が、基盤モデルが改善された後もまだ適用されるかどうかをどう知るのか？コードベースを共有していないエージェント間で、検証済みの行動パターンをどう伝播するのか？

ファイルベースの制約には、これらの問いに対する答えがありません。そもそもそのために設計されたものではないのです。ここで重要になるのは、単なるルールではなくガバナンスです。ローカルの制約は第一歩です。しかしガバナンスとは、制約がまだ機能しているかを追跡し、一度に一つのプロジェクトではなく、エージェントのネットワーク全体に更新を伝播するメカニズムを持つことです。

実際にそれがどういう形になるのか、まだ考えている最中です。

制約だけでは足りないとき

制約はエージェントにどう振る舞うかを伝えます。しかし、事後的にエージェントが正しく振る舞ったかどうかは伝えてくれません。これらは別の問題です。

最もよく見る失敗パターンは、ルールを無視するエージェントではありません。ルールを完璧に守るエージェントです — ただし、そのルールが書かれたのとは違うコンテキストで。ルールは正しかった。ルールが新しい状況をカバーしていなかっただけです。

限界とトレードオフ

制約のドリフト — 陳腐化するルール

ルールは陳腐化します。6ヶ月前に完璧だったルールが、今はわずかにずれているかもしれません — モデルのデフォルトが変わった、コードベースが変わった、ルールが参照していた基準がアップストリームで更新された、といった理由で。

ルールファイルは自己管理しません。 Claude Code、Cursor、Codex の制約システムには共通の盲点があります。ルールが古くなったことを検知するメカニズムがないのです。ただ静かに、期待通りに機能しなくなります。Cursor のドキュメントやさまざまな実践者は、定期的なルール監査を推奨しています — ルールが壊れやすいからではなく、ルールを取り巻く環境が変わり続けるからです。

永続性がない — 制約はセッションごとにリセットされる

何度も立ち返る問題です。

すべてのセッションはクリーンな状態から始まります。CLAUDE.md は再読み込みされます。AGENTS.md は再読み込みされます。skill は再発見されます。エージェントには、前回何がうまくいったか、微妙な失敗パターンがどこにあるか、3週間のデバッグで何を学んだか、その記憶がありません。

その学びをルールファイルにエンコードすることはできます — そしてそうすべきです。しかし、エンコードは手作業です。制約システムは学習しません。 あなたが学び、学んだことを書き留め、そして制約システムがそれを反映する。そういう仕組みです。

これは本質的な制限です。現在のアーキテクチャの範囲内で解決可能かどうか分かりません。しかし、明確にしておく価値はあります。

FAQ

AI エージェントワークフローにおける superpowers とは何ですか？

機能のことではありません — 制約システムのことです。エージェントがすべてのセッションにわたって従う、一貫した行動ルール、パーミッションスコープ、フェーズ固有の指示を定義する能力です。
Claude Code で行動制約を設定するにはどうすればよいですか？

SKILL.md ファイル（YAML フロントマター + Markdown の指示、.claude/skills/ に格納）と、常時指示用の CLAUDE.md ファイルを使います。ツールレベルのパーミッションは allowed-tools フィールドで指定します。Anthropic 公式 skills の GitHub リポジトリに実例があります。
.cursorrules と CLAUDE.md の違いは何ですか？

それぞれ異なるツール用です。.cursorrules（.cursor/rules/*.mdc への移行が推奨され、廃止予定）は Cursor のフォーマットです。CLAUDE.md は Claude Code の永続指示ファイルです。どちらもセッション中に常時ルールを保持しますが、スコーピングのメカニズムが異なります。
エージェントの制約はセッション間で永続化できますか？

ネイティブにはできません。ルールファイルはセッション開始時に再読み込みされます。エージェントには前のセッションの記憶がありません。学んだ行動をルールファイルに手動でエンコードすることはできます — それが正しいアプローチです — しかし、制約システム自体が経験を蓄積することはありません。
brainstorming-writing-executing の skill パターンとは何ですか？

異なる skill が異なるフェーズを管理するワークフローです。brainstorming はコードを書かずに問題空間を開きます。planning は構造化された提案を作成します。executing は承認済みプランに基づいて実装します。各フェーズの成功基準がより狭いため、ループや実装途中のアーキテクチャ変更を減らすことができます。

この領域がどう進化するか、おそらく見続けることになるでしょう。制約システムはより洗練されてきており、SKILL.md を共有フォーマットとするクロスツールの収斂はもっと詳しく追いたいところです。しかし、セッションスコープの制限は、現在のツールのどれもが持ち上げる方法を見つけられていない天井のように感じます。何かがここで起きている — でもまだ、全体像は見えていません。

AI エージェントの「超能力」：本当に機能する行動制約とは