AIプログラミングは、まだ自らのSpring Bootを待っている
AIプログラミングは、「モデルはコードを書けるか」という段階をすでに越えた。しかし、「チームはどうすれば安定してデリバリーできるか」という段階は、まだ越えていない。
Prompt、Context、Memory、Tool、MCP、Sandbox、Workflow、Eval。部品は着実にそろいつつある。本当に欠けているのは、広く受け入れられた標準経路だ。人は目標をどう記述するのか。Agentは何を見て、何を変更できるのか。中断したタスクをどう再開するのか。どんな証拠があれば結果をマージしてよいのか。
これはSpring Boot以前のJava Webに似ている。必要な能力はあり、アプリケーションも動く。それでも各チームは、起動、構成、デプロイを毎回自分たちで解いていた。AIプログラミングが待っている「Spring Boot」も、モデルが強くなるだけでは自然に生まれない。
フレームワークの価値は、繰り返される判断を減らすことにある
TomcatはWebアプリケーションをどこで動かすかに答え、Springはオブジェクトをどう構成するかに答えた。Spring Bootはさらに、依存関係の選択、一般的な設定、実行環境を一組のデフォルトにまとめた。Railsはもっと直接的に、ディレクトリ、命名、接続方法の規約によって、プロジェクトごとに議論する自由を置き換えた。
これらのフレームワークは、繰り返される判断を減らすことで価値を生み、コード量の減少はその結果としてもたらされた。長年の実践を概念、構造、デフォルトに圧縮しながら、必要なときには下のレイヤーへ降りられる入口を残した。新人はまず成功率の高い道に沿ってアプリケーションを作り、問題に直面してからコンテナ、トランザクション、ネットワークを順に理解できる。
AIプログラミングには、まさにこの圧縮がない。SDKはモデルを呼び出せる。Agentはツールを使える。それでもチームは、Contextの構成、権限の境界、状態の復旧、検収基準を自分たちで発明し続けている。似た部品はあっても、共通の開発モデルがない。
次のツリーは、すでに存在する能力の分布を示している。枝葉は茂っているが、それらを結ぶエンジニアリング上の契約はまだ薄い。
本当に欠けているのは、フィードバック・アーキテクチャだ
「タスクを完了できるか」だけを見れば、現在のAgentはすでにかなり実用的だ。しかしソフトウェアのデリバリーには、別の問いもある。なぜこの変更を行ったのか。どの制約を検査したのか。テストは何をカバーしたのか。失敗はどのレイヤーで起きたのか。事故の後に復旧できるのか。
だからAIプログラミングのフレームワークは、単なるAgentオーケストレーターでは足りない。曖昧な依頼を検査可能な閉じたループへ変える、フィードバック・アーキテクチャに近いものが必要だ。目標は実行可能なSpecificationになり、Contextには明確な出所があり、ツールは最小権限に従う。Runtimeはタスクの状態を保存し、テストとEvalは検収の証拠を示す。最終的な変更は、人の責任までたどれる。
Agentが明確な制約のもとで検収可能なソフトウェアを生み出し、失敗箇所を特定でき、過程を追跡できるようにする。
これが成熟すれば、開発者がPromptを手作業でつないだり、Agent Loopを保守したりする機会は減るだろう。Spring Bootの利用者がServletコンテナを毎日組み立てないのと同じだ。一般的な選択は規約になり、複雑な状態はRuntimeに委ねられ、例外的な状況だけで人が下のレイヤーへ降りる。
このフィードバック・アーキテクチャには、見落とされがちな利用者もいる。プログラミングを学んでいる人だ。
新人に足りないのはフィードバックだ
かつてJuniorは、Bug修正、CRUD、テストから始めた。タスクは難しくなくても、現実の結果を絶えず見せてくれた。なぜテストが失敗したのか。トランザクションはどこで壊れたのか。APIはどう誤用されたのか。本番のロールバックにはどんな意味があるのか。エンジニアリング上の判断力は、こうした短いフィードバックの中で育った。
Agentはその仕事を引き受けつつある。新人は数分で完成した機能を得られる一方、どの判断が妥当で、どのリスクがまだ表面化していないだけなのかを判断できない。Agentが書いたコードをレビューさせるだけでも解決しない。レビューには、新人がまだ身につけていない判断力そのものが必要だからだ。
新しい学習経路は、より高い抽象化レイヤーから始め、意図的に下へ掘り進む必要がある。Agentに実際の機能を完成させた後、一つのリクエストを追跡し、トランザクション境界を調べ、権限の選択を説明する。失敗したら、目標の誤解、Contextの不足、ツールの制限、コードのBugを区別する。フレームワークはこうした境界を見えるようにし、完成したコードとともに追跡可能な過程を残すべきだ。
デリバリーに必要な可観測性、検証、復旧は、そのまま学習に必要なフィードバックにもなる。教育専用のレイヤーを別に設ける必要はない。優れた中間層は、チームと新人の両方に役立つ。
私たちはまだ、それを何と呼ぶか知らない
Spring Bootのように実行環境、依存関係、デフォルト設定を結びつけるものかもしれない。Railsのように明確な規約で選択肢を減らすものかもしれない。従来のコードフレームワークの形を取らない可能性もある。組織する対象は目標、状態、権限、検収であり、コードは成果物の一つにすぎないからだ。
この類比には限界もある。モデルの出力には不確実性があり、Agentはツールを呼び出して外部の世界を変更できる。そのため検証、隔離、権限は、従来のWebフレームワークより前段に置かなければならない。フレームワークが経験をどう凝縮するかは学べても、その答えをそのまま移すことはできない。
モデルは変わり続け、現在の操作テクニックも古くなる。それでもSpecification、Runtime、Eval、権限、復旧は繰り返し現れる。ある工程を人が何度も手作業で補い、同じ失敗が複数のチームで繰り返されるなら、そこには適切な抽象化が欠けている可能性が高い。
この抽象化が生まれれば、チームはタスク状態、権限、検収方法を毎回発明せずに済み、新人も同じ証拠をたどってデリバリーの成否を理解できる。それまでは、AIプログラミングにはますます強力なAgentがあっても、標準となる開発経路がないままだ。