「コイツが空から降ってこなければ、だれもラピュタを信じはしなかっただろう」
「君はラピュタを宝島か何かのように考えているのかね？」
「ラピュタはかつて恐るべき科学力で天空から世界を支配した、恐怖の帝国だったのだ」
実例
1. 導入：それは、気軽な「コピペ」から始まった
自作ライブラリのモダン化という輝かしい未来に向けて、私はテキストエディタを開き、AGENTS.mdという名の粘土板に「AIエージェントの行動指針」を刻んでいた。
ふと、「別プロジェクトで試験的に運用していたコーディング規約（プロンプト）が流用できるのでは？」と思いつく。実績のある資産のコピペは、エンジニアリングにおける正義だ。私は軽い気持ちで、月ダウンロード件数26万件（2026年7月現在）を誇る過去の遺産（インドラの矢）を呼び出そうとした。
しかし、クリップボードにコピーする手を、私は完全に止めることになる。
「書き方が、ぜんぜん違うやないかーい！」
2. 第一の予兆：再現性の喪失 ＝ 読めない「黒い石」
愕然とした。
同じ私が、ほんの少し前に書いたはずの指示書なのに、文体も、トーンも、構造も全く互換性がない。プログラミング言語なら、構文（Syntax）が違えばコンパイラ（軍隊）が怒ってくれる。しかし、自然言語という免罪符は「どうとでも書けてしまう」。
これはつまり、AIエージェントに対する指示には「再現性がない」 ということだ。
昨日と今日で違う呪文を唱え、それでも「AIがいい感じに解釈してくれるからヨシ！」と目を瞑る。この時点で、私は自分が「記述言語」ではなく、解読不能なラピュタの『黒い石（碑文）』を弄んでいることに気づき、背筋が寒くなった。
3. 第二の予兆：個人開発という名の、かりそめの平和
「まあ、これは自分のプロダクトだし、私の脳内コンパイラが辻褄を合わせればコントロールの範囲内か……」
そう自分を慰めようとした瞬間、私の脳内に特務機関の男が割り込んできた。
「君は、これをチームで開発したらどうなるか、想像したことがあるかね？」
もし、このリポジトリに複数人のメンテナーが参加したら？Aさんは親切な先輩風、Bさんは箇条書きの軍隊調、Cさんは「英語の方が打率🏏が良い」と英文の「†聖なる言葉†」で追記する。1つのファイルのなかに、複数の人格と派閥が同居する。誰も全貌を把握できない、ただ肥大化していく「🏙️空中都市🌆」の完成である。
4. 結末：自律稼働がもたらす「恐怖の帝国」とガバナンスの崩壊
さらに最悪なシナリオは、AIエージェントに「ライブラリが更新されたら、自動でAGENTS.mdも最新のベストプラクティスにアップデートしてね♥️」と全権（💎飛行石💎）を与えた時に訪れる。
参照元の外部ライブラリがメジャーアップデートされるたびに、エージェントは「これが最新の正義ですぅ❣️」と、ドヤ顔でAGENTS.mdを書き換える。そして、それに合わせたリファクタリングのプルリクを、巨大飛行戦艦「ゴリアテ」の主砲のごとく毎日のようにリポジトリへ撃ち込んでくるのだ。
コミットログを埋め尽くすのは、人間が書いた機能追加ではなく、「AGENTS.md更新」と「AIによる気まぐれなリファクタリング」の山。
もはや誰が開発の手綱を握っているのかわからない。主権（ガバナンス）は人間から完全に失われ、システムは制御不能な「ロボット兵の暴走」へと堕ちる。
「ラピュタのガバナンスは滅びぬ、外部APIの仕様変更で何度でもコミットログを荒らすさ」
5. 結論：私は、静かにエディタを閉じた
行儀の良い生成AIなら、ここで『Markdownのテンプレートを共通化しましょう』と、のんきなソリューションを提案してくるのだろう。
だが、そんな規約自体、自然言語の暴虐の前には無力だ。ルールを破った自然言語を検知するルールを、また自然言語で書くという「無限ループ🔄の竜の巣」に飛び込むだけである。
私はクリップボードの履歴を消去し、そっとキーボードから手を離した。流行りに乗ってAIエージェントの帝国を築き、制御不能になったコミットログを見つめながら「目が、目がぁぁぁ！」と叫ぶことになる未来を、未然に防いだ自分を褒め称えながら、温かいコーヒー☕を飲むことにする。
「どんなに強いAIを持っても、たくさんのかわいそうなエージェントを操っても、物事の本質から離れては生きられないのよ！」
本題
――さて、ここまでは「自然言語による仕様策定」が孕むディストピアな未来予知について語ってきたが、ここからは「では、エンジニアリングとしてこの不確実性にどう立ち向かうべきか」という真面目なガバナンス論について、現実的なアプローチを考察していきたい。
自然言語を使えることの弊害
まず、第一の問題は自然言語で記述可能であるということの問題である。例えば、TypeScriptの配列の型定義に対してArray<string>でなく、string[]を使うようAGENTS.mdに書くとする。
- Array type syntax:
string[]notArray<string>- 配列の型を書くときはArrayではなく[]を使用する（例：
string[]）- 配列の型定義にArrayは使わない
- Do not use
Array<string>, usestring[]
...
同じ事を言っているだけだ。しかし、その時の気分や考え方、言語などによって全然文章が変わってしまう。たった一つの文章でもこれだけ揺らぎが出る。
決められた文章構造がない
単独の文章でもこれだけ揺れ幅がある。しかし、AGENTS.mdは設定ファイルでなくドキュメントである。JSONやYAMLなら「このキーにはこの型」というスキーマ定義（型定義）ができるが、Markdownで自由に書くAGENTS.mdにはそれがない。
冒頭の概要文を例にしても、
# AGENTS.md
You are an expert in TypeScript, Vite, and web application development.
You write maintainable, performant, and accessible code.
と書いてあったり、
# Project Summary
This is web application development project. Using TypeScript with Vite stack.
Your role is write code maintainable, performant, and accessible code.
だったり、
# Web Application Development
## Tech stack
- Vite
- TypeScript
## Your role
- Code Writing.
- Mentainance favor.
- Performant
- Accessible (must write jsdoc)
だったり、はたまた
# Project
This project is developing web application. Your role is write code maintainable, performant, and accessible code.
| Tech stack | Ver. |
| ---------- | ---- |
| Vite | 8 |
| TypeScript | 7 |
のように書かれているかもしれない。
これらの、AGENTS.mdで言わんとしていることは一緒だ。しかし、書き方が違う。パッと思いついただけでもこれだけバリエーションがある。言い換えるとどんな風にも書けてしまう。
自分で書いたにせよ、AIと壁打ちで書いたにせよ、チームで話し合いながら書いたにせよ、章の順番ですらバラバラである。そして、いずれの書き方も文章として間違っていないし、AIも読んでくれるので、余計に問題をややこしくさせている。
自由度が高すぎるため、開発者自身のその日の気分でフォーマットが変わる。これは「型システムのない世界で、全員がグローバル変数を好き勝手に書き換えている」状態と同じである。
ベストプラクティスが変わることがある
Vueを例に取ると、Vue2まではclassとデコレータを用いたOption APIが推奨されていたのが、Vue3以降ではComposable APIで書くことが推奨されるようになった。
これは単なるライブラリの破壊的変更であり、問題としてはさほど大きくない。いいか悪いかは別として、昔からの書き方も許容されているし、最悪、バージョンアップを諦めて新機能を取り入れないという方針で行くのもありだからだ。
しかし、セキュリティが絡むものだと問題はややこしくなる。eslint8からeslint9の破壊的変更の結果、設定を書き直したり、メンテされていないプラグインで非互換が発生するなど、大変なことになったのは記憶に新しい。しかし、それもまだまだ序の口。
最も厄介なのは、知らなかったり、無意識のうちに言語やライブラリの仕様の穴を利用した運用をしていて、そこに脆弱性対処があたり、その機能が使えなくなってしまうパターンである。（古い例だと、PHPが5.2.5から5.3になったとき、問題になった。）
多くの場合、全てがだめになるわけではなく、中途半端に使えているので始末が悪い。こういった問題を事前に防ぐのは、AIでも原理的に不可能である。当然コミット履歴は荒れることになる。
また、AIの世界はドッグイヤーであり。昨日まで「こう書くとトークンが節約できて賢く動く」と言われていた手法（例：特定のプロンプトテクニック）が、LLMのモデルアップデートによって一瞬で過去の遺物になるというリスクもある。
チームワークでのガバナンス崩壊
単独で開発している場合は、全てコントロールの範囲内ですませることが可能だったが、もしチームワークで開発していたらどうなるだろうか？
まず、各々が勝手にAGENTS.mdを更新して文章を整理するようになる。
GitのDiff（差分）を見ても、「てにをは」の修正や表現の微調整ばかりで、「この変更によってエージェントの挙動がどう変わるのか」というコードレビューが100%予測不能になる。結果として、レビュー文化そのものが形骸化し、リポジトリの統治（ガバナンス）が崩壊していく。
先も書いたように、AGENTS.mdは自然言語である以上どうとでも書けてしまう。これまでの自分のAIの研究結果や、Chromeの「Geminiに相談」ボタンでサイトの文章を要約させたときの結果から、割とAIは文脈を読まない傾向が見られた。そればかりか、書いていないワードを捏造することもあった。
これは、命令が意図しない形で認識される可能性があるということだ。
かといって、そのたびにミーティングを開いて合議制でAGENTS.mdを更新するというのも微妙である。それって、AIの意味ないですよね？
じゃあどうすればいいのか？
結局のところAGENTS.mdは仕様書ではなく、あくまでもAIの行動指示書である。もっと粒度を荒くして理想論だけを書くのが正しい運用方法だと思う。そして、実際のコーディングルールなどはeslintなりprettierなりbiomeなりで記載し、それらを守ることを明記する程度にとどめたほうがいいかもしれない。
また、チーム開発の場合は、AGENTS.mdの運用は、専属の担当者一人で行うようにするなどのポリシーを定めるなど工夫が必要かもしれない。「船頭多くして船山に上る」という言葉があるように、複数人でメンテするとどうしても設計が濁るためだ。1
終わりに
AIは銀の弾丸などではない！
自分で、物事の全体構造を把握する力がないと、AIを御しているつもりがAIに使われるようになってしまう。この「AIに使われる」という表現は、一見AIによって人間が使役させられるような古典的なものをイメージしがちであるが、現実的には自動検知した脆弱性報告の滝のようなプルリクが送られてきて、それのレビューや対応方針に追われる状態のことを言う。
人間はその大量のプルリクが本当に正しいか、バグを含んでいないかを、血眼になって1つずつレビューしてマージボタンを押し続ける。「私はAIを顎で使って楽をするためにAGENTS.mdを書いたはずなのに、気づけばAIが吐き出す大量のプルリクの処理（ケツ拭き）に追われる『AIの下請け業者』に成り下がっていたのだ。」
これこそが、AIに主導権を明け渡したリポジトリの末路。私たちはいつでも、ラピュタを操っているつもりが、ラピュタというシステムに生かされる「かわいそうなエージェント」になり得るのだ。
私は、AIを使い始めてから程なくしてハルシネーションに悩まされた。結論から言うと、原因はコード生成AIでないのにコードを書かせたことだが、そもそもの根本原因を分析したときに気づいたのは「AIに何でもさせようとするから失敗する」ということだった。
同じことがAGENTS.mdでも起きている。
粒度が細かすぎて、AIに「完璧に従うべき仕様書」のように扱わせている。
だから、細微なニュアンスの差が積み重なり、ガバナンスが崩壊する。
では、どうするのか？
答えは逆説的だ。AIに「できることを減らす」のだ。
いわゆる、関心の分離（Separation of Concerns） だ。
「人間が決めるべき構造的（architectural）決定権」と「自動化可能な（mechanical）詳細な実装」を明確に分離するということである。
そもそも、AIの世界は日進月歩で進化する世界である。今日の正解が、明日の正解とは限らない。そこで小手先の工夫で効率化を図っても、長期的にトークン消費量削減などの効果が保証されるとは限らない。
良かれと思って詳細まで書かないほうがよい。
「何でもできる」ということは、「自由度が高い」ということではなく、「どうとでもなってしまう」ということである。
では、あなたのリポジトリのAGENTS.mdは、今この瞬間も、中身を検証されず勝手に更新されていないだろうか？
その時間に、あなたが本来やるべき「人間にしかできない決断」は掘り下げられているだろうか？
-
もちろん、個人の性格や価値観、能力などの優劣の問題ではない。 ↩