AI時代、ソースは誰のために書くのか（4/4 品質の守り方編）

 最終回です。これまで、ソースの読み手が人からAIに変わるなら、コードの書き方、技術選定、開発の進め方がどう変わるかを書いてきました。最後に、じゃあ品質はどう守るのか、の話です。

■そもそもの前提

・コンパイラは出力が決定的で、何十年もかけて正しさが検証されてきたから、人は下の層を読まなくなった

・AIはまだそこまでいってない。なのでテストや型、契約がコンパイラの正しさ保証の代わりになって、初めて「人は実装を読まなくていい」状態になる

・障害や性能問題のときに今でもバイトコードやJITの出力、GCログを読みに行くのと同じで、実ソースも「いざという時に人が読む層」としては残る。そのとき大事なのは美しさより、影響範囲が局所的で追いやすいこと

■結局、管理するものは変わらない

・ソースを読まなくなる代わりに、その一つ上にあるコンテキストドキュメント（仕様、設計メモ、AI向けの指示、ADR）が新しい「ソース」になる。アセンブリを読まなくなった代わりに、Javaのソースを厳密に管理するようになったのと同じ

・なので、バージョン管理、レビュー、変更履歴、整合性チェックといった、今までソースにやってきた管理はドキュメント側に全部必要になる。管理の手間がなくなるわけじゃなく、管理対象が一段上がるだけ

・しかもドキュメントはコンパイラもテストも検証してくれない。これまでは「最後はコードが仕様」で逃げられたけど、その逃げ道がなくなる

・古いドキュメントがコンテキストに入っていると、AIはそれを信じて間違ったコードを書く。ドキュメントの腐敗がそのままバグになるので、技術的負債ならぬ「コンテキスト負債」が新しく生まれると思う

・1回目に書いた通りコンテキストドキュメントは階層に分けておく前提なので、そのぶん管理する単位も増える。全体ルールとモジュールごとのメモが食い違っていないかも、管理の対象になる

・対策としては、ドキュメントもソースと同じリポジトリでPRレビューする、実装の変更とドキュメントの更新を同じ差分に入れる、そして書けるものはなるべく型・テスト・interface・ArchUnitのルールに寄せて、ドキュメントには検証できない「なぜ」と「何を守るべきか」だけを残す、あたりかなと

■AIのブレはどう抑えるか

・AIの出力は毎回ブレる。でも一度生成してコミットしたソースは固定される。以降はそれをベースに差分だけを作り続ければ、ブレは差分の範囲に閉じ込められる。決定性をAIに求めるのではなく、バージョン管理で担保する発想

・その上でテストが成熟すれば、それを安全網にしてリファクタや作り直しもできるようになる。契約とテストが残っていれば、実装は丸ごと再生成してもいい。順番は「差分運用で品質を積む → テストが育つ → リファクタや作り直しが可能になる」

・ただし、AIは局所的な修正を積み重ねがちなので、一つ一つは正しくても全体の構造はだんだん崩れる。部分的な情報から作っている以上、全体を見ているのは人だけなので、定期的なリファクタは「できたら嬉しい」ではなく運用に組み込む必要がある

■テストをどう守るか

・テストの成熟度はカバレッジだけだと測れない。通った行がわかるだけで、挙動を縛れているかはわからないから

・そこで使えるのがミューテーションテスト。コードをわざと壊して、テストがちゃんと落ちるかを見る方法で、JavaならPITというツールがある。テストの質の指標としてはカバレッジより信頼できると思う

・AIはテストが落ちると、実装ではなくテスト側を直して通そうとすることがある。テストが仕様書であり安全網である以上、テストの変更は人がレビューする、実装の変更とは別扱いにする、くらいの線引きは要る

・性能やメモリまで守りたいなら、ベンチマークもスイートに入れて劣化を検知できるようにしておく。GCの停止時間やヒープ使用量も、計測して基準を超えたら気づける形にしておくと、構造が崩れてきたときの早期警報になる

■一個だけ気をつけたいこと

今のAIの癖に合わせすぎないこと。コンテキスト長や得意不得意は1年で大きく変わる。JVMもGCも同じくらいの速さで変わっていく。局所的であること、明示的であること、型と契約で意味が語られていること、は読み手の能力が上がっても価値が落ちないので、そこを軸にしておけば長持ちすると思っています。

■シリーズのまとめ

AIで開発が楽になる話というより、重心が移る話だと思っています。

人が書いて読むものは、実装から契約とコンテキストドキュメントへ。

AIに渡すものは、プロジェクト全体から、部分で完結する単位へ。

決めることは、戻せないものは先に、戻せるものは作って見ながら。

品質を守る仕組みは、人の読解力から、型・テスト・ツール・バージョン管理へ。

フレームワークは、手間を減らす道具から、正しさを保証する基盤へ。

チューニングは、勘と経験から、計測と実験へ。

そして人が最後まで手放してはいけないのは、テストとドキュメントの正しさ。

1回目に書いた「局所的に理解・変更・検証できること」という評価軸が、このシリーズ全体の背骨で、継承の利用範囲が狭くなるのはその軸の上にある一つの結果、という位置づけです。

■みんなに聞きたい

・コンテキストドキュメントの管理、実際どうやってる？もう腐り始めてたりしない？

・AIにテストを書き換えられた経験ある？どう防いでる？

・これまでジュニアは他人のコードを読んで判断力を身につけてきた。人が実装を読まなくなったら、テストや契約の良し悪しを判断できる人はどうやって育つんだろう。ここは自分もまだ答えがない

4回分、読んでくれた人ありがとうございました。あくまで今の時点での自分のスタンスなので、反論・ツッコミ大歓迎です。ここから一緒に煮詰めていけたら嬉しいです。

Read More

AI時代、ソースは誰のために書くのか（3/4 開発の進め方編）

 これまでの2回で、コードの書き方と技術スタックの選び方を書きました。ただ、ここまでの話の多くは「AIがなくても言われてきた原則の重みが変わる」話でもあります。今回は、AI開発でしか起きない変化に絞ります。

根っこにあるのは、「書くコストがほぼゼロになって、決めることと確かめることのコストだけが残る」というコスト構造の逆転だと思っています。

■決め方が変わる

作り込みが曖昧さを吸収していた

・これまでは、設計書に書ききれていない細かいことを、作り込みの中でエンジニアが判断して埋めていた。手を動かしながら「この場合はどうするか」を決めて、迷えばお客様に確認する。作り込みが曖昧さを吸収するクッションになっていた

・AIはそのクッションにはならない。曖昧なまま渡すと、聞き返さずにもっともらしく埋めてくる

戻せる決定は、作って見て決める

・ただ、修正や作り直しもAIで速くなるので、全部を先に決めきる必要はないと思う

・画面のレイアウト、文言、内部の処理の分け方みたいに後から戻せるものは、作り直しがほぼタダ。むしろお客様は文章の仕様書より、動くものを見たほうが判断しやすい。何パターンか作って見せて選んでもらうほうが、会議で詰めるより早くて正確

・この領域では、決めるタイミングをむしろ後ろにずらせるようになった

戻せない決定は、先に決める

・一方で、コードの作り直しが速くなってもコストが下がらないものがある。データの持ち方、外部システムとの連携仕様、権限やセキュリティの設計、お金の計算ルール、法律や契約が絡む部分

・こういうものは、コードを書き直すのは一瞬でも、データ移行、相手先との調整、再テスト、利用者への周知が付いてくる。ここは今まで通り、むしろ今まで以上に先に決めておく必要がある

・作る期間が短くなったからといって、ここを決める要件定義や設計の時間まで削るのは危ない

本当に怖いのは「気づけないこと」

・作り直しのコストより怖いのは、AIが黙って埋めた箇所に気づけないこと。人間のエンジニアなら質問してきた箇所が、聞かれないまま、それっぽく動く形で埋まっている。作り直しが速くても、作り直すべきだと気づかなければ意味がないし、気づくのが本番データが入った後だと、戻せない決定に化ける

・なので対策は「全部先に決める」ではなく「AIに勝手に埋めさせない」ほうだと思う。仕様が曖昧なところをAIが判断で埋めたら、必ず一覧にして出させる。そうすると、黙って埋められていた箇所が人への質問に変わる。昔エンジニアが作り込み中にしていた質問を、AIに意図的にさせるイメージ

整理すると

・決める量そのものは減っていない。変わったのは、「戻せない決定は先に」「戻せる決定は作って見ながら」と、決め方を使い分ける必要が出てきたこと

・難しくなったのは、決める量が増えたからではなく、「どれが戻せない決定なのか」を見極める判断が要るようになったから

■モデルが依存関係になる

・コンパイラのバージョンを固定するのと同じで、モデルのバージョンも管理対象になる。モデルが更新されると、同じ指示でも書くコードの癖が変わる

・「どのモデルで生成したか」を記録しておく、モデル更新はライブラリのメジャーアップデートと同じ扱いで検証する、という運用が必要になると思う

■ルールは文章ではなくツールで強制する

・コーディング規約を文章で書いても、AIは守ったり守らなかったりする。でもコンパイラ、リンター、静的解析がエラーとして返したものは、かなりの確率で直してくる。少なくとも自分の体感では、文章のルールよりずっと効く

・Javaには、パッケージやレイヤー間の依存ルールを普通のユニットテストとして書けるArchUnitというライブラリがある。これで「このレイヤーからあのレイヤーは呼ぶな」をテストにして、機械的に止める

・ルールをツールに移せば、そのぶんコンテキストドキュメントに書く量も減らせる。ツールで強制できるルールは腐らないので、次回書く「コンテキスト負債」への一番の対策もここだと思う

■並列開発を前提に分割する

・AIエージェントを複数同時に走らせると、同じファイルを同時に触ってコンフリクトする。定数をまとめた巨大なクラス、全種類を列挙する大きなswitch文、中央の設定ファイルが衝突の温床になる

・人間なら「今そこ触ってるよ」で調整できたけど、エージェントはしない。「同時に別々の作業者が触っても衝突しない」が分割の基準に入ってくる。1回目に書いた「部分で完結する作り」は、ここでも効いてくる

■作ってから比べる

設計判断が議論から実験へ

・書くコストがほぼゼロなので、「A案とB案どっちがいいか会議で議論する」より「両方作って計測して比べる」が現実的になる

・1回目の継承の性能の話も、議論するより両方書いて測ったほうが早い。設計の議論が、机上の推論から実験に寄っていく

・上に書いた「戻せる決定は作って見て決める」と同じ考え方。ただし戻せない決定まで「とりあえず作って比べよう」で進めると、比べ終わる前にデータや連携が乗ってしまうので、そこだけは先に決めておく

GCのチューニングも勘から実験へ

・GCのチューニングは、これまで経験者がログを読み解いて、勘でパラメータを決める職人芸の世界だった

・GCログの解析はAIが得意な作業だし、ヒープサイズやGCの種類を変えた設定を何パターンも用意して、負荷をかけて比べるのも安くなる。勘ではなく実験で決められるようになる

・ただし前回書いた通り、AIは古い時代の設定もよく知っている。たとえばCMSというGCはJDK 14で削除されていて、削除後のJDKでCMSを指定するオプションを付けると、警告が出たうえでデフォルトのGCのまま動き続ける（ここは事実）。つまりAIが古い設定を書いてきても起動は失敗せず、ログを見ないと「思っていたGCで動いていない」ことに気づけない

・なので、試す設定は使っているJDKのバージョンで有効なものか、ログで実際に効いているかまで確認する

■「なぜこう書いたか」が会話の中に消える

・AIとのやりとりで決めた設計判断はチャットの中にしか残らない。人間同士ならレビューや会議で残っていた経緯が、どこにも記録されないまま実装だけが残る

・コミットメッセージやADRに「なぜ」を残すのが今まで以上に大事になる。git logがAIにとっての記憶になる

・GCの設定も同じで、「なぜこのパラメータにしたか」が残っていないと、後で誰も触れない設定になる

■レビューする量が人間の限界を超える

・AIは人間が読み切れない量のコードを書く。全部を人が丁寧に読むのは物理的に無理

・AIに一次レビューさせて、人は契約とテストの変更、影響範囲の大きい差分に集中する役割分担になる

・PRを小さく保つことは、AIに課すべき重要なルールになる

■みんなに聞きたい

・AI前提で、要件定義や設計の進め方って変えた？

・AIが勝手に埋めた箇所、どうやって見つけてる？

・エージェントを並列で回してる人いる？作業はどう分けてる？

・モデルが変わってコードの癖が変わった経験ある？

・GCのチューニング、AIに手伝わせたことある？

・AIとのやりとりで決めたことの記録、どうしてる？

次回は最終回、結局品質をどう守るのか、を書きます。

Read More

AI時代、ソースは誰のために書くのか（2/4 技術スタックの選び方編）

前回は、AI時代の設計の評価軸は「局所的に理解・変更・検証できること」になる、という話を書きました。継承の利用範囲が狭くなるのは、その軸で測った結果の一つ、という整理です。今回は、同じ軸で技術選定を見てみます。

■今回の見方

技術選定には、2つの軸を当ててみます。

・1つ目は、前回と同じ「局所的に理解・変更・検証できるか」

・2つ目は、AI時代に新しく出てきた「AIがその技術をよく知っているか」

前半はフレームワーク、O/Rマッパー、コード生成、独自フレームワークを1つ目の軸で、最後に2つ目の軸の話をします。

■事実として押さえておきたいこと

・Springの@Transactionalは、デフォルトのプロキシモードだと外からプロキシ経由で呼ばれたときだけ効く。同じクラス内のメソッドから呼ぶと、アノテーションが付いていてもトランザクションにならない（公式ドキュメントに明記されている）

・GCの選択肢は整理されてきている。ZGCはJDK 23で世代別モードがデフォルトになり、JDK 24で非世代別モードが削除された。JDK 25ではShenandoahの世代別モードも正式機能になった

■フレームワーク：局所的に理解できるか

フレームワークの機能を2種類に分けて考える

・1つは「書く量を減らすための機能」。ボイラープレート削減、設定より規約、アノテーション1個で済む便利機能など

・もう1つは「正しさを肩代わりする機能」。トランザクション、セキュリティ、コネクション管理、並行処理のように、自前で書くと事故りやすい部分

・AIにとってボイラープレートを書くコストはほぼゼロなので、前者の価値は大きく下がる。でも後者の価値はむしろ上がる。AIが書いた自前のトランザクション管理より、何年も実戦で叩かれたフレームワークのほうが信頼できるから

・なので「フレームワークを捨てる」ではなく、「正しさを肩代わりする部分だけ使い、書く量を減らす部分は明示的なコードに戻す」方向になると思う

避けたいのは「見た目と挙動がずれる」仕組み

・Springのアノテーションによる暗黙の挙動（DI、トランザクション、自動設定など）は、学習データに大量にあるので、AIはかなりよく知っている

・問題は暗黙であることそのものより、そのコードだけ見ても挙動がわからないこと。@Transactionalを同じクラス内から呼ぶと効かない、というのが典型で、コードの見た目は正しいのに挙動が違う。局所的に理解できないので、人間もAIもハマるし、差分を見ても気づけない

・こういうタイプの暗黙の挙動は避ける、が基準になりそう

■O/Rマッパー：局所的に検証できるか

JPAは一番揺り戻しが来そう

・JPA/Hibernateは、N+1、遅延ロード、変更の自動検知、永続化コンテキストみたいな、コードに書かれていない挙動がたくさん動いている

・AIに書かせると、動くけどN+1を量産する、という話はよく聞く。しかも差分にSQLが出てこないので、レビューで局所的に検証できない

・前回の継承の話とつなげると、JPAのエンティティ継承マッピングは、継承とORMの複雑さが掛け算になる部分なので真っ先に避けたい

SQLを明示的に書く方向へ

・AIにとってSQLを書くコストはほぼゼロで、SQLはAIが得意な言語でもある

・なので、SQLを明示的に書くMyBatisや、型安全にSQLを組み立てるjOOQ、Spring JdbcClientみたいな薄い仕組みに寄っていくと思う

・SQLが差分に直接出るので、性能問題もレビューで見えるし、人間もSQLなら読める

コードファーストからスキーマファーストへ

・JPAは「エンティティを書けばスキーマがついてくる」発想だった

・でも人が読むのが契約になるなら、DBのスキーマとマイグレーションこそが契約で、コードはそこから生成されるもの、という逆転が起きる。API設計でOpenAPIの定義を先に書くのと同じ流れ

■コード生成：検証しなくていいものを増やす

・決定的な生成器があるならAIより優先する。OpenAPI GeneratorやjOOQのコード生成、MapStructみたいな「同じ入力から必ず同じ出力を出す生成器」は、まさにコンパイラと同じ性質を持っている

・AIの出力はブレるので毎回確かめる必要があるけど、決定的な生成器の出力は、入力の定義さえ確かめればいい。検証の手間がかかる場所を減らせる

・決定的な生成器で作れる部分はそっちに任せて、AIはその間をつなぐ部分を書く、という棲み分けが一番硬いと思う

■独自フレームワーク：部分だけで理解できるか

独自フレームワークは厳しくなる

・社内共通基盤や独自フレームワークは、品質を揃えるために大きな役割を果たしてきたけど、AIの学習データには当然入っていない。そのフレームワークの仕組みを知らないと、どのモジュールも理解できない。つまり、部分だけでは完結しない

・毎回その説明をコンテキストドキュメントで渡す必要があって、前回書いた「一度に読める量の限界」をそれだけで圧迫する。それでも標準的なSpringの書き方を混ぜてくる

・独自フレームワークの存在意義は「スキルがバラバラな人でも一定の品質で書ける」ことが大きかったと思う。その役目は「標準フレームワーク＋ツールで強制するルール＋コンテキストドキュメント」で置き換えられる

・フレームワークを作っていた側として、ここは正直複雑な気持ち

ロックインは弱くなる

・javaxからjakartaへの移行やSpring Bootのメジャーアップデートは、AIが得意な「大量の機械的な書き換え」そのもの。テストが成熟していれば移行コストは大きく下がる

・「一度選んだら変えられないから全部入りを選ぶ」から「薄いものを選んで、必要になったら変える」がやりやすくなる

■もう一つの軸：AIがよく知っているか

定番で枯れた技術ほど有利になる

・AIは学習データに多い、定番で枯れたライブラリほど正確に使える。出たばかりのライブラリや最新のJava機能は、古い書き方を混ぜたり存在しないAPIを書いたりしがち

・新しい技術を使うなら、その分コンテキストドキュメントを厚くする必要がある

ただし「よく知っている」は「古いことも知っている」でもある

・JVMやGCのように世代交代が速い分野だと、AIは昔の正解も同じくらいよく知っている

・GCは選択肢が整理されて、まずはデフォルトのまま使い、停止時間を極端に短くしたいといった要件があるときだけ選び直す、で十分な場面が増えている。そこにAIが古い時代の設定を持ち込んでくる、というズレが起きやすい（具体例は次回のGCチューニングの話で書きます）

・なので、使っているJDKやライブラリのバージョンは必ずコンテキストに入れておきたい

依存の追加は人が確認する

・AIは存在しないライブラリやバージョンをもっともらしく書いてくることがある。依存の追加は、必ず人が確認する対象にしておきたい

■今回のまとめ

1つ目の軸で見ると、フレームワークもO/Rマッパーも、「人間の手間を減らすための抽象化」から「局所的に理解・検証できる、正しさを保証するための基盤」へと、求められる役割が絞られていくと思っています。

2つ目の軸で見ると、AIがよく知っている技術は有利だけど、よく知っているからこそ古い情報も持ち込む。バージョンと前提をコンテキストで渡すことが大事になります。

■みんなに聞きたい

・JPAとMyBatis/jOOQ、AIに書かせるならどっちが楽だった？

・独自フレームワーク、AI時代にも残す意味はあると思う？

・技術選定で「AIが扱えるか」をもう気にしてたりする？

次回は、AI開発でしか起きない「進め方」の変化について書きます。

Read More

AI時代、ソースは誰のために書くのか（1/4 コードの書き方編）

 これからのコーディングがどう変わるかについて、有識者と軽く議論して論点の頭出しができたので、今後きちんと話していくために、今の時点での自分の考えとスタンスをまとめておきます。4回に分けて書きます。結論ではなくたたき台なので、ツッコミ歓迎です。1回目は「継承ってまだ要る？」を入口に、AI時代の設計で何が評価軸になるのか、という話です。

■自分の仮説

昔はアセンブリを人が書いて読んでいた。コンパイラが信頼できるようになって、人はCやJavaを書くようになり、機械語やバイトコードは「機械が最適化する層」になった。

今それが一段上がって、Javaのソースそのものが「AIが書いて読む層」になりつつあるんじゃないか、と思っています。

ソースが読みにくくていいという話ではなくて、読み手が人からAIに変わるということ。なので、ソースはAIが読みやすいように書かれ、分割され、設計されるべきで、人が読むのは「契約」に移っていく、というイメージです。

「読み手を想定して書け」という昔からの原則は変わらない。変わるのは読み手のほう、という話です。

このシリーズで使う言葉

・契約：仕様、テスト、interface、DBスキーマのように「実装が守るべき約束」をまとめてこう呼びます

・コンテキストドキュメント：AIに渡す仕様書、設計メモ、AI向けの指示書などをまとめてこう呼びます

■設計の評価軸が変わる

先に言っておくと、「AIだから継承が悪い」という話ではありません。

AIは、プロジェクトの一部分だけを読んで、一部分だけを変更する。人はその差分を見てレビューする。この進め方を前提にすると、「変更の影響範囲がコードの上で明示されているか」の価値がぐっと上がる。

なので、AI時代の設計の重要な評価軸は「局所的に理解・変更・検証できること」になると思っています。

継承の利用範囲が狭くなるのは、その軸で測った結果の一つ。以下、この軸を継承に当てはめるところから始めて、他の書き方にも広げていきます。

■この軸で継承を見るとどうなるか

事実として

・継承は昔から「控えめに」と言われてきた。Effective Javaには「継承よりコンポジションを選べ」という項目があり、理由は実装継承（extends）がカプセル化を壊すから。interfaceの実装は対象外

・Go言語は型の継承を持たず、interfaceを満たせば自動的にその型として扱える設計にしている

自分の考え

・継承の一番のメリットは「人間が理解しやすい抽象化」だったと思う。is-aで世界を整理できて、共通処理を親に寄せればコードも短く見える。読み手がAIになると、そのメリットはほぼ消える

・自分がフレームワークを作っていた頃、「読みやすさより速く硬いソースであるべき。読めない人はフレームワークに関わるな」と言われた。その「読める人」の役をAIが担うなら、人間向けの読みやすさより、速さと硬さを優先していい

・しかもAIにとっても継承は扱いにくい。1クラス直すのに親や祖父母クラスまでAIに読ませる必要があって、読ませ忘れると的外れな修正をされる

・レビューの軸も「読みやすいか」から「差分で判断できるか」に変わる。親クラスを1行変えると影響は全サブクラスに及ぶのに、差分には1行しか出てこない。継承はここでも分が悪い

■性能やメモリの面で、継承を残す理由になるか

継承をやめてコンポジションに寄せると、性能やメモリで損をするんじゃないか、という疑問は当然出ると思うので、ここで確認しておきます。

事実として

・HotSpotのJITは、呼び出し箇所に来る型が2種類までならインライン化で速くできるが、3種類以上になると仮想呼び出しになってコストが乗る。ただし極端に遅くなるわけではない

・コンポジションは部品ごとに別オブジェクトになるので、そのぶんヘッダ分のメモリが増える。ただしJDK 25でCompact Object Headersが正式機能になり、オプションで有効化するとヘッダを64bitまで縮められるようになった

・今のJavaのGCは世代別が主流で、「ほとんどのオブジェクトは若くして死ぬ」という前提で、短命なオブジェクトを安く回収するように作られている

自分の考え

・性能・メモリの差は、普通の業務アプリならDBやI/Oの待ちに埋もれる程度。大量のオブジェクトを持つデータ構造やホットループだけ、計測して判断すれば十分だと思う

・GCで見ても、メソッド内で使い捨てる部品オブジェクトが増えるぶんには、世代別GCなら回収コストはほぼ気にしなくていい。効いてくるのは、長生きする部品オブジェクトが大量にある場合で、Old領域が膨らむうえに、GCが辿る参照の数も増える

・なので「部品に分けるとGCが重くなる」ではなく、「長生きするオブジェクトを細かく分けるとGCが重くなる」が正確だと思う。キャッシュや大きなコレクションに載せるデータだけは、分け方を意識したい。Compact Object Headersでヒープ全体が小さくなれば、GCの頻度も下がる方向に効く

・つまり、性能やメモリは継承を残す決定的な理由にはならない

■継承についての結論

・継承そのものが悪いのではなく、「局所的に理解・変更・検証できるか」という軸で測ると、親クラスへの依存が影響範囲を見えにくくする分、不利になる場面が増える

・なので、再利用目的の継承は最小限でいい。影響範囲が明示的なまま使える、フレームワーク利用者向けの拡張ポイントと、sealedでの型の分類くらいが残る

■AIが一度に読める量には限界がある

ここまで「AIが読む」前提で書いてきたけど、AIは全部を一度に読めるわけじゃない。ここは大事な制約なので、別に書いておきます。

事実として

・AIが一度に扱える入力の量（コンテキストウィンドウ）には上限がある

・上限に収まっていても、長く渡せばいいわけではない。2023年の研究では、必要な情報が入力の先頭か末尾にあるときに性能が一番高く、長い入力の中ほどにあると大きく落ちることが報告されている。長い入力を扱える前提のモデルでも同じ傾向だった

自分の考え

・小さいプロジェクトならソースもドキュメントも全部渡せるけど、中規模以上になるとプロジェクト全体をAIに読ませるのは無理。現実には、部分的な情報から一部分のソースを生成することになる

・なので「AIに何を渡すか」を毎回人が手で選ぶのではなく、部分的な情報だけで正しく作れる仕組みを最初から用意しておく必要がある

・1つ目はソースの切り方。モジュールの境界をinterfaceなどの契約で切っておけば、AIはそのモジュールの中身と、隣のモジュールの契約だけ読めば作れる。逆に、親クラスを辿らないと挙動がわからない継承は「部分だけでは完結しない」典型で、前半の話の一番の根拠はここにあると思う

・2つ目はコンテキストドキュメントの切り方。全部を1つの巨大なドキュメントにすると、それ自体が読み切れない。プロジェクト全体の短い共通ルールと、モジュールごとの設計メモ、のように階層に分けて、必要な分だけ渡せる形にしておく

・3つ目は必要な情報を引ける仕組み。どのモジュールがどこに依存していて、どのドキュメントが対応しているかを辿れるようにしておけば、AIが自分で必要な文脈を取りに行ける

・中規模以上の開発では、この「部分で完結させる仕組み」を作ること自体が、アーキテクトの一番大事な仕事になっていくと思う

■同じ軸で見ると変わりそうな書き方

ここからは、「局所的に理解・変更・検証できるか」の軸を、継承以外にも当てはめてみます。

・DRYが緩む。共通化すると、それを呼んでいる側同士が結合する。多少重複しても、局所的で独立して直せるほうが差分で判断しやすい。ただし同じ仕様はテストで縛っておく

・明示的なほうが勝つ。アノテーションを付けるだけで裏側で処理が自動的に差し込まれる仕組み（AOPなど）は、人間がボイラープレートを書くのが面倒だから生まれた面がある。AIにはボイラープレートのコストがほぼゼロで、むしろ「コードに書かれていないところで何かが起きる」ほうが追いにくい

・モジュールの切り方がAIの読み込み単位を基準にするようになる。上に書いた通り、AIは全部を一度に読めないので、Controller・Service・Repositoryみたいに層で横に切るより、機能単位で縦に切って、1つの機能がまとまって読めるほうがいい

・型と契約が強まる。人が実装を読んで確かめない分、sealedやrecordで「ありえない状態を作れない」ようにして、コンパイラに検証を寄せる

・テストが人の読む仕様書になる。実装は人にとって読みやすくなくていいけど、テストこそ人が読みやすく書くべき、という逆転

・コメントは「何をしているか」より「なぜそうしたか・何を守るべきか」を書く。何をしているかはAIがコードから読める

・検索しやすい名前が大事になる。AIは必要な箇所をgrepやシンボル検索で探して読む。短くて文脈依存の名前より、長くても一意に検索できる名前のほうがいい。文字列を組み立ててメソッドを呼ぶリフレクションみたいな、検索に引っかからない呼び出しはAIにとって見えない依存になる

■みんなに聞きたい

・「ソースの読み手が人からAIに変わる」という見立て、どう思う？

・現場で最近 extends 書いた？書いたならどんな場面？

・中規模以上の案件で、AIに渡す情報をどう絞ってる？

・「いや継承はこういう時に必須でしょ」「DRYは譲れない」みたいな反論も大歓迎です

次回は、この評価軸で技術選定を見るとどうなるか、を書きます。

Read More

ChatGPT Business の Premium seat から考える、AIライセンスの「配り方」

少し前の話題だが、OpenAI が 8/10 に ChatGPT Business の Premium seat を発表し、8/25 から正式提供が始まった。コストの話というより、AIを組織にどう配るかという設計の話として読むと面白かったので整理しておく。

何が変わったか

	Standard seat	Premium seat
月額	$25	$125
年契約	$20	$100
使用量	基準	Standard の5倍
5時間制限	あり	なし

その他のポイント：

• 使用量は週次リセット
• 同一ワークスペース内で Standard / Premium を混在できる
• seat が「ユーザーに紐づくもの」から「ワークスペースに容量として買って各人に割り当てるもの」に変わった。あとから付け替え可能

要するに、ユーザー単位の固定ライセンスから、プール型のリソース割当に変わったということ。付け替え可能になった点が地味に効いてくる。

今までの選択肢

ヘビーユーザーに容量を足したい場合、これまでは Enterprise に上げる / 別ワークスペースを立てる / 個人で Plus・Pro を契約してもらう、くらいしかなかった。どれも契約もデータ管理も分断される。OpenAI 側も「別サブスクや作業の分断を招かずに」という訴求をしている。

「何でもできる道具」は誰に効くのか

どの会社にも、AIをあまり使えていない人・そこそこ使える人・使いこなしている人がいる。業務との相性もあるが、それ以上に大きいのはチャット型AIの自由度が高すぎることだと思っている。

我々のような業種以外だと、そもそもきちんと使える人がかなり少ない。白紙の入力欄に何を書けばいいか分からないし、雑に投げて雑な答えが返ってきて「使えない」で終わる。道具が悪いというより、何でもできる道具は、何をさせるか自分で決められる人にしか効かない ということだと思う。

エンジニアが比較的すんなり使えるのは、地頭の問題というより、やらせたいことを仕様として言語化する訓練を日常的にしているからだろう。差は能力ではなく職業上の慣れに近い。

で、一律ライセンスはこの分布に対して、どちらに倒しても損だった。

• 使えてない人に合わせる → 使いこなしてる人が上限で止まる
• 使いこなしてる人に合わせる → 使ってない人の分が丸ごと無駄

100人でざっくり計算すると、全員 Premium seat で月 $12,500。実際に Premium が要るのが20人なら 20 × $125 + 80 × $25 = $4,500 で、6割強の削減になる。

なので値上げというより、今まで「上に合わせるしかない」と諦めて払っていた企業にとっても、「下に合わせるしかない」と導入に踏み切れなかった企業にとっても、コスト最適化の選択肢が増えた話として読んでいる。

難しいのは「誰に渡すか」の判断材料

課題は、Premium seat の割り当てを決める材料が乏しいこと。使用量ログを見ても、価値ある使い方だったのか、単に長いプロンプトを投げただけなのかは分からない。トークン消費量は成果ではない。

なので最初から人で決めず、業務プロセス単位で割り当てて後から付け替える のが現実的かなと思う。seat がワークスペースの容量になったことの恩恵は、まさにここにある。

これは自由度の話とも繋がっていて、「この業務にこの seat」と決めれば、使う側も何をさせればいいかが自ずと定まる。全社にアカウントを配って各自の裁量に任せるより、用途を絞って渡すほうが結局は回るはずだ。

ただしエンジニア組織では話が逆になる

書いておいてなんだが、エンジニアやコンサルタントが大半を占める組織では、seat の出し分けでコストを削る話はあまり刺さらない気がしている。自由度の高い道具を、目的から逆算して使うのが本業みたいな集団だからだ。

というより逆で、全員がヘビーユーザーになるべきなんじゃないかと思っている。

AI利用に濃淡がある組織なら、seat を出し分けて無駄を削るのが正しい。でも開発・コンサル・営業のどの職種でも、AIが効く場面はいくらでもある。「あまり使ってない人」がいるとしたら、それは適正なコスト配分ではなく、単に伸びしろが放置されている状態なんじゃないか。

だとすれば、この発表から読み取るべきは「誰に Premium seat を渡すか」ではなく、全員が Premium seat を使い切るくらいの使い方になっているか のほうかもしれない。

まとめ

• AI利用に濃淡がある組織 → 人ではなく業務プロセス単位で seat を割り当て、使用量ログではなく用途で見直す
• 全員が使いこなす前提の組織 → 出し分けの最適化より、使い切れていない人の伸びしろを見る

とはいえ今はまだAIも黎明期で、私自身も契約するAIサービスをコロコロ変えている状態なので、「これで腰を据えて行こう」と決め打つのも難しい時期ではある。

そういう意味で、これは他業種ならともかく、IT業界に大きなインパクトを与える話とは少し違うかもしれない。ただ、お客様と話ができるように知っておきたい話ではあるなと。

参考

• 発表：Premium seats are coming to ChatGPT Business
• ヘルプ：What is ChatGPT Business

Read More