Diary over Finite Fields

515ひかるの日記と雑文

最近考えていること 2026年2月

AIとコーディング、近況

仕事でClaude Codeをガリガリ使っている。最近、会社の人がSDD(Spec-Driven Development)をやりやすくするSkillを定義してくれたりしていて、開発が楽になった。

Claude Opus 4.6を使っていると、レスポンスはとても遅い。しかし、あまりに的外れな調査はしない。待ち時間が無駄と思うことは減った。ただ、あまりにレスポンスが遅いので簡単なSQLがほしいときとか、コードベースの議論に入る前の壁打ちには僕はGoogle Geminiを使っている。

AIによるコーディングに対して、僕はあまり感情が動かなくなった。これにいいとも悪いとも思わなくなってきている。そういうものだ。2023年10月に僕は産業革命になぞらえて、ソフトウェア開発はパブリッククラウドによる工場化とAIによる機械化の波から逃れられないと書いた

特に予言めいて書いたわけではないが、2年半ほど前に思っていたことと現在の景色はそんなに変わらない。自分の目に見える範囲でも、採用数を減らす話や、あるいは今までエンジニアではなかった人が開発を担うということが起き始めている。むしろやっと僕が言っていた通りになり始めたなという感覚さえある。

そしてこれからも、この動きは続いていくだろう。それまでに、個人として他のソフトウェアエンジニアとどう差別化するか。どのようなMOATを築くのか。

職業ソフトウェアエンジニアを本気でやり続けたいのであれば、この難しい問いに答えを探す努力をしないといけない。困難な時代だなと思うばかりだ。

AIと人間の認識差分をどうやって減らすか

このところ自分のAI活用の仕方の見直しをしている。

今までの自分のやり方はスケールしない(ほかの人に真似ができない)感覚があった。

僕自身の悪い癖というか。とにかくチーム開発とか組織としての生産性をどう高めるかということに対してアイデアが少ない。これはインプットが少ないということで、単に努力不足だと思っている。

そんな自分をメタ認知はしているので、この最近は他人の提案した方法をとにかく自分も試すということをやっている。自分で思いつけないなら、せめて他人の提案は受け入れようということだ。

そこで会社の人が提案したやり方を真似してみたのだが、それがなんととてもやりやすい。

どんな方法かというと、端的に書けば開発を仕様書作成・実装計画策定・実装の3ステップにわける。AIに要件を伝えて仕様書をまず作成してもらい、それをレビューする。レビューが通ったら、実装計画を策定する。ここで詳細設計が定まるので、その詳細設計も詰めたらあとはAIに実装してもらう。そういう内容だ。

おそらく、突飛なことは何もしていない。その人もなんらかのベストプラクティスを真似ているのだと思う。

この方式の良いところは、枠組みさえ作ってしまえば真似るのが容易だと言うことだと思う。

プロンプトそのものより、AIに守らせる原理・原則が大事だ。例えば、このワークフローでは実装計画にないことを実装してはいけないとしている。こうすることで、仕様書 -> 実装計画 -> 実装の単方向な依存関係ができる。仕様にない実装を追加するときは仕様書に修正をいれないといけないし、実装計画が不十分だとわかったら、実装計画書を修正しないといけない。

といってもドキュメントを書くのはAIなので、あまりそこで苦労はしていない。

おまけに、AIにコードレビューをさせるときもこのドキュメントは使われる。AIはコードレビューをするときにPRの差分を見るので、そこに仕様書があればレビューにも活用がなされる。仕様通りに実装されているか、仕様と実装に矛盾があった場合はコメントをつけるといったことが自動でできる。

総じて、仕様書を書き、仕様書から逸脱した行為をしない契約を結ぶことで、人間とAIの認識差分を減らす効用があると思う。

結局のところ、AIの動きは早いのでもはや実装することがボトルネックになることはない。じゃあボトルネックはなにかというと、人間とAIの認識差分を埋める時間だと思う。そもそも、人間側で期待通りの成果物をAIに言語化して伝えることができていれば手戻りはない。伝えられないから手戻りが起きるのだ。

僕はいままで、なにかを伝えたときのAIの第1挙動や調べるファイル、表示される思考過程からAIに必要な情報を都度都度足して開発をしていた。これは非常にラリーが多くなるのと、AIが何を知らないかに対する想像力が求められるので言語化しづらい技だなと自分で思っていた。

しかし、あらゆる期待を仕様書に明示する方法では、認識差分はあったとして仕様書に必ず現れる。そこに人間とAIの認識差分が必ず可視化されるため、実装を始める前に仕様書をレビューすれば良いとなる。

これにより、自分の実現したいことがよりやりやすい形で実現できるようになったので非常に良いなと思っている。今後も仕事やチームで使うときは認識差分は明示させる方法を考えたほうが良いと思っている。

インプットが浅い

Xを見なくなり、とにかく情報に触れる機会が減った。そこで最近は雑誌に手を出してみている。

僕はなぜかFODプレミアムに入っていて、FODのプレミアムでは雑誌が読める。そこで雑誌の読み放題で開いたり、シンプルに本屋で立ち読みしたりしている。

世の中にはこんなに雑誌があるのかと結構驚いている。本屋には20年以上通っているけど、雑誌コーナーに立ち寄った経験はほとんどなかった。

最近はPenの攻殻機動隊の特集を読んでいる

インプットの総量は確実に減っている感覚がある。

自分は別にYouTubeも開くし世間からすごく離れたいという欲求もない。だから実は日経新聞を紙面ビューワーでざーっと眺めていたりもする。

だが一時期より、学術書を読んでものごとの理解を深めるとかの営みの時間は減ったと思う。とにかく最近のインプットが浅い。衆院選の演説とかも頑張って回ったけど、前回の参院選のときのようななにかを感じることができなかった。

行動しても自分に得られるものが浅く、そのせいでアウトプットもしょうもないものになっている気がする。

ただ、悲観することもたぶんないと考えている。新しいインプットは、探そうと思って探せるものでもない。