CLAUDE.md のような指示ファイルや memory は便利だが、「書いてある」だけでは強制できない。この記事の主張はかなりシンプルです。
AI-assisted development（AI支援開発）には、モデルを賢くするだけでは足りない。新しい“統制レイヤー”が必要だ。
これが本題です。
著者は、ソフトウェア開発の大きな変化には、その都度「新しい基盤」が必要になる、と言います。
たとえば、
が必要になった。
そして generative AI の時代には、まだちゃんと名前が付いていないけれど、同じような基盤が必要になっている。
その正体が governance だ、というわけです。
ここ、私はかなり重要だと思いました。
AI開発の話って、つい「どのモデルが強いか」「コンテキスト長はどれくらいか」「どうプロンプトを書くか」に寄りがちです。
でも著者はそこから一段引いて、**“仕組みとして何が足りないのか”** を見ています。これはかなり本質的です。
この記事でいう governance は、ざっくり言うと
AIに勝手なことをさせないためのルール管理層 です。
もう少しかみ砕くと、次のような役割を持ちます。
ここで大事なのは、これは単なる「覚えておく」機能ではない、という点です。
著者は、memory（記憶）ではなく、enforcement（強制） が必要だと言っています。
この違いは地味に見えて、実はめちゃくちゃ大きいです。
たとえば「このルールは守ってね」とAIにお願いするだけなら簡単です。
でも実際には、AIは文脈によって忘れたり、ズレたり、都合よく解釈したりする。
だから “知っている” と “守らせる” は別物 なんですよね。
この記事は単体で完結しているというより、4本の連載の入口 になっています。
著者は「この順番で読んでほしい」と案内しています。
AI支援開発の 7層構造 を説明する記事。
その中で governance は Layer 5、つまり memory と orchestration の間にあるそうです。
しかも、この層を本格的に作っている人はほとんどいない と指摘しています。
この発想は面白いです。
AIツールって、表面だけ見ると「チャットでコードを書かせる便利機能」に見えます。
でも本当は、その裏に複数の層がある。
著者はそこを、インフラ設計のように整理しようとしているわけです。
AIがコードを大量に生成できるようになった結果、人間の code review が追いつかなくなった という話です。
code review は、コードが共有コードベースに入る直前の最後の関門でした。
でもAIが出力する量と速度が上がりすぎて、その関門が機能しづらくなった、と著者は言います。
これはかなりリアルです。
レビューは人間の注意力と時間に依存します。
一方でAIは、24時間でも大量にコードを吐ける。
この非対称さは、たしかに従来の開発フローを壊します。
個人的には、ここがAI導入で一番“現場臭い”問題だと思います。
CLAUDE.md は、Claude系の開発でよく使われる 指示ファイル のようなものです。
「このプロジェクトではこういうルールで動いてね」とモデルに伝える役割があります。
ただし著者は、小規模では有効でも、規模が大きくなると限界が来る と述べています。
理由はシンプルで、
context injection（文脈を入れること）と enforcement（強制）は違う からです。
ファイルにルールを書いてあるだけでは、AIが必ず守るとは限りません。
人間でいうと、「社内ルール集を配りました」だけで全員が完璧に守るわけではないのと同じです。
守る仕組み、チェックする仕組み、逸脱を検知する仕組みが必要になります。
AI coding の分野では、以下の4つが混同されがちだと著者は言います。
この整理はとてもわかりやすいです。
どれも「AIに情報を渡す」ように見えるけれど、役割が違う。
特に governance は、AIの行動を縛る唯一の層 だとされています。
著者が言いたいのは、AI支援開発では
「もっと賢いモデルを使えば解決する」わけではない
ということです。
必要なのは、
だけではありません。
それらに加えて、「ルールを守らせる仕組み」 が必要だ、という話です。
これ、言われてみれば当たり前なんですが、実際のプロダクト設計ではつい忘れがちです。
新しい道具が出ると、人はまず性能に目が行きます。
でも本当にスケールするかどうかは、たいてい裏側の制御で決まるんですよね。
私はこの視点、かなり筋がいいと思います。
記事の最後では、AI支援開発に必要なのは
enforceable architectural memory
つまり、強制可能な設計記憶 だと言っています。
ちょっと難しい言い方ですが、要はこうです。
そんな仕組みが必要だ、ということです。
これは、AI時代の「設計書」の進化版とも言えそうです。
昔の設計書は読むためのものだった。
今後は、読むだけでなく、実際のコード生成や変更に効く設計 が求められるのではないか。
私はそう感じました。
この文章の面白さは、AIコーディングを「便利ツール」ではなく、新しい開発インフラの問題 として捉えているところです。
AI界隈では、どうしても「速くなる」「楽になる」に話が寄ります。
でも、速くなった結果として何が壊れるのか、どこに新しいボトルネックが生まれるのかを見ないと、本当に役立つ仕組みは作れません。
著者はそこを、かなりはっきり言語化しています。
特に、
という流れは、現場の人ほど「たしかに」と思うはずです。
この記事は、AI支援開発の次の論点として
governance layer を提案しています。
要するに、AIにコードを書かせる時代には、
「どう書かせるか」だけでなく
「どう守らせるか」 が重要になる、ということです。
これは派手な話ではないですが、かなり本質的です。
モデルが強くなるほど、むしろ統制の設計は重要になる。
その見方は、今後AI開発に関わる人なら押さえておいて損はないと思います。
参考: Start Here: Why AI-Assisted Development Needs a Governance Layer