一時期、僕の個人開発プロダクト内で、Claude Code が頻繁に「実装列車」という言葉を使っていた。

実装列車。

なんだそれ。

最初はそういう用語があるのかと思った。日本語では見たことがないけれど、英語圏では Implementation Train とかなんとか、そんな言葉が流行っているのかもしれない。

しかし、どうも違う。

過去のドキュメントを辿ってみると、ある日の Claude Code が、何かを列車に例えていた。それがドキュメントのどこかに残ったらしい。

そして別の日、別のセッションがそれを拾った。

さらに別のセッションが、別の場所で使った。

そうしていつの間にか、僕のプロジェクトでは「実装列車」という謎の用語が使われるようになっていた。

誰もそんな用語を決めていない。

少なくとも、僕は決めていない。

AI が書いたものを AI が読む

最近、AI を用いたループ開発をしている。

Issue を AI に書いてもらう。ドキュメントも書いてもらう。実装もしてもらう。テストも書いてもらう。

そうしていると、以前の記事にも書いたように、ドキュメントや PR がだんだん人間には読めなくなってくる。

何しろ量が多い。

この問題への対策として、例えば tanteki のような、AI が生成する冗長な文章、いわゆる AI slop を抑制するためのスキルやツールも出てきている。

それはそれでわかる。

でも、僕にはなんとなく違和感がある。

そんなものを使わなくても、最初からうまく書いてもらえるなら、それに越したことはない。

じゃあ、何が間違っているんだろう。

そんなことを考えているときに、Artificial intelligence sustains higher strategic tension than humans in chess という論文を見つけた。

チェスにおいて、AI は人間よりも高い strategic tension を維持する、という話である。

これを見ていて、なんとなくわかったことがある。

そもそも、今のコメントやドキュメントや PR は、誰が読むんだろう。

AI である。

人間に読みやすくする必要はあるのか

人間は、長期的なコンテキストをそこそこ不正確に、大量に扱える。

「あの辺で、こんな話をした気がする」

「たしか、こういう理由だったはず」

そんな感じで、昔のことをなんとなく覚えている。

一方で AI は、メモリ空間が許す限り、かなりの量のコンテキストを一つのセッション内で扱える。

もちろん限界はある。

ただ、少なくとも僕よりは大量のドキュメントを読んでくれる。

すると、AI が書いたドキュメントを人間向けに短くすることが、本当に正しいのかよくわからなくなってきた。

次にそれを読むのも AI だからだ。

人間には冗長に見える情報でも、次の AI にとっては必要なコンテキストかもしれない。

人間には複雑すぎる構造でも、AI はそのまま扱えるかもしれない。

そう考えると、AI によるループ開発では、人間が読みやすいことと AI が扱いやすいことが、少しずつズレていくのかもしれない。

そして、人間が読まなくなったところで、先ほどの「実装列車」が出てくる。

「そんな仕様にしたっけ？」

「実装列車」なら、まあ笑い話で済む。

謎用語が一個増えただけである。

ところが、似たようなことは仕様でもたまに起きる。

僕が、

「こんな機能にしたい」

と言う。

すると AI が、

「しかし、過去にそれはしないと明示していますよ？」

と反論してくる。

そうだっけ？

調べてみる。

確かに書いてある。

しかし、さらに調べてみると、その判断をしたのは僕ではない。

過去のあるセッションで、当時の AI が仕様の足りない部分を補い、その判断をドキュメントに書いていた。

次のセッションから見れば、それはもう AI の判断ではない。

ドキュメントに書かれた既存仕様である。

だから、それに従う。

さらに、その仕様を前提として実装する。

その実装を別の AI が見れば、今度は「既存実装ではこうなっている」という根拠になる。

こうして、最初はどこかのセッションが補っただけの判断が、いつの間にかプロジェクトのルールになっていく。

誰も見ていないところ

機能なら、まだ気づける。

僕が「そんな仕様にしたっけ？」と思えるからだ。

問題は、僕が普段見ていないところである。

DB にどうアクセスするのか。

何をテストすべきなのか。

何をログに出すのか。

そんな細かなところまで、僕は逐一確認していない。

AI が何らかの方法を選ぶ。

それをドキュメントに書く。

次の AI が読む。

その AI は、それをこのプロジェクトのやり方として使う。

さらに別の場所へ書く。

そうやって、過去のどこかで AI が補った手法が、いろいろな場所へ増えていく。

しかも、さらにややこしいことがある。

セッションごとに読んでいるドキュメントが違う。

あるセッションは A というドキュメントを読む。

別のセッションは B を読む。

もし A と B に矛盾があっても、両方を読まなければ気づかない。

AI が気づかない。

AI いわんや人間をや。

これは何なんだろう

そんなわけで、AI を使ったループ開発を続けていると、少し変なことが起きる。

AI が判断する。

AI がそれを文書化する。

次の AI が、その文書を既存のルールとして読む。

そしてまた判断する。

それがコードやテストやドキュメントに残る。

人間は、その全部を読んでいるわけではない。

少なくとも僕は読んでいない。

それでもプロダクトは動いている。

テストも通る。

そして、僕の知らないところで「実装列車」が走り始める。

今のところ、僕はひとりで個人開発をしている。

仕様を決める人間も僕ひとりである。

それでもこのザマだ。

では、複数人のチームで、それぞれが AI を使って開発するようになったら、これは何が起きちゃうんだい？

よくわからない。

あと、これ、何か名前が付いているんですかね。

AI slop とも少し違う気がする。

単なるドキュメントの陳腐化とも違う。

AI が作ったものを次の AI が事実として受け取り、それをもとにまた何かを作り、それが少しずつプロジェクトの「そういうもの」になっていく。

僕は名前を思いつかなかった。

誰か、耳障りの良い用語を作ってください。