AIについて考えていること（2025年9月）
当時の記録を残す、不定期AI雑記2025年9月号です。noteならば適当なこと書ける。
仕様駆動開発の実践
前から言われていることでもあるが、真面目に仕様駆動開発してみて、つくづくAI開発における自身の知識・経験、そして設計の重要性を実感することになった。
というかそのことを試したかった面もあり、あえてちゃんと使ったことないスタックばかり選定して開発してみた。Python、Cloud Composer、CloudRunとか。
知識がないので、仕様設計のフェーズでしっかり確認をしながら時間かけてAIと仕様を話し合ってみることとした。その結果、、、作ってるうちに割と違うアーキテクチャになり、何度も作り直すことになってしまって大変だった。
AIの示す設計の問題や自分の確認不足に気づけず、ある程度AIががりがり実装した段階で確認すると問題に気づいてしまう。「それってどういう意味？こういう構成は取れないの？」と質問すると、「その構成もありです！」と言いながら理由を付与してくるが、あとになって「現実的には良くない」ことがわかったりする。自分に知識がないから、「あり」と「良い」の差をちゃんと見破ることが難しい。
人間の側が「仕様駆動開発」以前だったということだろう。やはり人間に能力があることを前提にしている。労力は外注できるが、能力は外注できない。設計なんて尚更。
とはいえそもそも、こうやって全く無知なところから「失敗してみる勉強」を、（適当に他のことしながらとかで）AIに実装させているだけでできていることはもちろん本当にすごく便利。AI駆動開発のメリットは依頼して失敗してもラフに却下できること、という話は本当にそう。
いまのところのAIに委ねる線引き感
あと実務的には、コーディングエージェントが単体テストを書くのもっと上手かったらな・・・と思うことが多々ある。しかしまあ「単体テストが十全に書ける」というのは、「仕様を十全に理解している」ということであって、そりゃあ難しいはずだとも思う。
t_wadaさんも（今はどうかはわからないけど）単体テストは自分で書くと言っていたと記憶している。いまのところ、実運用を伴う一定の規模感のプロダクトならば、アーキテクチャ設計と（少なくとも根幹となる仕様の）単体テストコード実装は自分でやった方がうまくいくのではないかという印象を持っている。
ごくごく当然のこととして、実装が容易になればなるほどアーキテクトの重要性が高まる。もう少し細かく言えば、アジャイル的な「実装と設計が渾然一体」から「設計は実装の前フェーズ」というウォーターフォール圧が強くなるはず。それが仕様駆動開発という話の本質的な意味なのではと想像する。
ベストプラクティスを提示する仕事のこと
AWSのようなサービスだと、ベストプラクティスがドキュメントによくまとまっている。公式MCPの威力もあって、AIにベストプラクティスのアーキテクチャを聞くと結構まともなものを返してくれてすごい。すごいのだが、すごすぎて、ある種の仕事って一体なんなんだろう、という気持ちになった。
コンサルティングみたいな業務は、レガシーに対して外からベストプラクティスを強く主張することも仕事だったりすると思うし、それは重要だとは思う。のだが、しかしこうやってあまりに簡単にAIがベストプラクティスを提示する世界で、その仕事の価値って何なのだろうと考えてしまう。ないとは言ってない。それが技術者なのかはよくわからない。
まあとはいえ、AWSみたいな「設計が必要だが、公式からベストプラクティスが積極的に提示される」ってのも特殊な対象な気もしてはいる。しかし、AWSは情報が多い分、マシなだけということかもしれない。
それはそれとして
コンサルの喋り方と今のAIの喋り方はすごい似ていると思っている。特に相手の言葉を絶対に否定しないところ。相手の言葉が変であったとしてもよしなに引き受けようとするし、否定的なことを言わない縛りルール故に相手の言葉の読解を誤ったりする。
ほんと似ててやばいと思う。そしてAIはとても人間的な応答をするなとも思う。一方で、そうしたAIには、そうした人間のコミュニケーションには一体何が欠けていると考えるべきか、思いを馳せたりする。
書き忘れてたので追記
普通に考えて、AI時代、大企業に入って要件定義とか事業ドメインとか学んだほうがいいよね、というのがベタな戦略に思える。思えるけど「そういうのやっぱやりたくない！」って思ってしまう結果としてフリーランスであるようなエンジニアの1人として、じゃあどういう戦略を取ると良いのだろう、みたいなことばかり考えている。ビッグウェーブが予想できたとして、それに一緒に乗るかどうかは別に戦略的に正しいとは限らないのだから。