AI時代のソフトウェア開発と認知負債
はい、ということで、今緊急でポッドキャストをしてるんですけど、初の2回目登場ということで、夏休みに入られるという企画があったので、t-wadaさんをお呼びしております。よろしくお願いします。
よろしくお願いします。
はい、ということで、t-wadaさん、改めて自己紹介をお願いしてもいいでしょうか。
はい、自己紹介です。2回目ということなんですけど、
t-wadaです。本名はwadatactといいます。インターネット上ではt-wadaさんと呼ばれています。
技術顧問業をやったり、プログラマーをやったり、オープンソースソフトウェアの開発をやったり、講演をしたり、みたいな感じで仕事をしていますという感じです。よろしくお願いします。
はい、よろしくお願いします。いや、そうですよね、でもなんか最近引っ張りだこで、もうなんか新しい演目ができてしまったから、できてしまったというか、なんか忙しそうだなっていうのと、なのでOSS活動とかできてらっしゃるのかな、みたいなところが気になるんですが、そのあたりいかがでしょうか。
あんまりできてないっていうのが正直なところだなっていうのと、あとまあOSS開発の世界も結構なんていうか仕様目が変わってしまったというか、よくも悪くもAIの影響で結構変わっちゃったところがあるので、パブリックのOSSは細々と続けていて、
あとまだパブリックにしてないんですけどプライベートでいろいろ、つまりGitHubのプライベートリポジトリの状態で作ってるやつっていうのが結構あって、まあなんかものになったらオープン、パブリックにするしみたいな感じで、開発自体は結構やってるんですけどという感じです。
お、そうなんですね。そうですね、やっぱまだそのOSS開発者も入れ方受け止め方がまだばらつきがあるので、そのあたり結構なんかハレーションが起きやすいというか、その取扱いを間違えるとその辺難しいところはまだ継続的に続いてるなっていうところはありますよね。
はい、ということで、結構最近T和田さんはAI時代、エージェント時代なのかわかんないですけど、そういったもののソフトウェア開発のあり方を考えるみたいな講演を結構いろんなところでされていて、つい最近もファインディさんのイベントで結構、こうなんていうか、ここ1年のまとめ総括みたいなのを発表されてましたね。
そうですね、基本はここ2年ぐらいずっとプログラミングの世界がすっかり変わってしまって、しかもどんどんどんどん変わっていってるので、それを追いかけるというか、まとめながら追いかけるみたいな感じで講演を続けています。
先日、7月の末ぐらいにファインディさんのAI DevX Conferenceというカンファレンスで終わりの基調講演、クロージングキーノートでしゃべったんですけど、このカンファレンスって去年までは開発生産性カンファレンスという名前でやってて、去年のクロージングキーノートも僕が務めさせていただいたんですね。
で、その時に上演を行った、AI時代のソフトウェア開発を考えるみたいなタイトルの講演っていうのをずっと改訂しながら続けていて、1年後最新版みたいな感じでクロージングキーノートを行って資料を公開したみたいなのが、ちょうどもう1週間前ぐらいですかね、ちょうど今で言うとぐらいという感じです。
はい、そうですね。かなりそういう意味ではもう最新版という形の内容が書かれていますが、なんか大きく去年、この1年の差分で言うと何が大きいかみたいなのって、いくつかこの内容で書かれていることって何がありますか。
そうですよね。で、大きかったのは、あの、初演の時は去年の7月だったので、去年の7月ってまだコーディングエージェントって結構書くコード自体は怪しいものもまだまだ多くて、どちらかっていうとその品質はそこまで高くないコードを高速に大量にばらまくみたいな動き方をしていたことが多くて、なんかコピープログラマーみたいな動きをしていて、
なので開発は偉く早いけど内部品質の劣化も早いなみたいな感じだったのが去年の初夏ぐらいの感じでしたので、あっという間にいわゆる保守性が劣化していくぞみたいな感じで警鐘を鳴らしながら講演するみたいな感じだったんですけど、
それがコーディングエージェントの能力というのが、2025年の11月に各社のコーディングエージェント能力が向上した結果、技術的不細というか、もうちょっと正確に言うと保守性に優れないコードというのが出にくくなったんですよね。
簡単に言うとコーディングエージェントの各コードのレベルが上がって、なんかコピープログラマーがひたすらコードをばらまくみたいな動き方をしなくなったというのがやっぱり結構大きかったかなと思ってます。
それとほぼ同時に、去年の夏ぐらいのコーディングエージェントって割と二人三脚で、プロンプとも常にやりとりしながら、つまり人間とAIが割と頻度高くやりとりしながら開発していくみたいな姿だったんですけど、
これも去年の11月から、それこそ今年の3月ぐらいにかけて、どんどん最初に決めたことを自分で判断して、人間にあんまり確認を取らずに、自力でモリモリと進められるようにコーディングエージェントが進化してきたので、
結果的にはロングランニングな感じになったというか、最初に指示出して、次に人間の指示を仰ぐのが45分後とか、そんな感じになっているので、やっぱりずいぶんそこは変わったなと思ってます。
その結果何が起こったかというと、コードの保守性自体は問題にならなくなってきたんですけど、人間の理解が置き去りになるというのがだんだん問題になってきていて、認知不細という名前もついてきているんですけど、
最初に例えばプランモードとかでガッツリ議論して、あとはじゃあこんな方針でやってみてくれたまえみたいな感じでコーディングエージェントでコードを書くすると、コーディングエージェントは自力でどんどんどんどんコードを書いて、1時間後ぐらいにコードが出来上がっていると、
コードレビューというのをみっちりやらない場合は人間結局動いてそうだからまあいいかみたいな感じになっていくんですよね。その設計判断の過程にある大事な瞬間にもあんまり実は立ち会わなかったりするので、
例えばプランモードなどでガッツリ計画を立てたとしても、聞いてくださってる皆さんも経験あると思うんですけど、コードって書き始めてみて初めてわかることとか、計画は立てたけど計画通りにやってみたら計画通りにいかないこととかはまだまだある。
これはコーディングエージェントの能力が低いからじゃなくて、プログラミングっていうのはそういうものなんですけど、そういった時にそれまでのコーディングエージェントってこれ思ったのと違うんですけどどうしますかっていうので人間に聞きにくるみたいな動きをしていたんですけど、
最近のコーディングエージェントってそれも含めて割と自力で何とかして考えて乗りこなして先に進もうとするので、そうすると人間にとって大事な設計のフィードバックの瞬間ってAIが良かれと思って潰してしまうみたいな感じで、
自力で考えて頑張って先に進むみたいな感じになっちゃうので、そうすると出来上がったものを見て、あれなんでこんなことになってんだっけみたいなところとかを割とちゃんと確認しないといけないんですけど、動作確認とあとはその概要の設計のみで良しとするみたいな感じでレビューを通してしまうと、
なんか動いているし当初の計画の通りになってるように思うんだけど実際はそうではないけどまあ動いてるは動いてるみたいな感じのものが積み上がっていって、結果的に人間の頭の中のそのメンタルモデルと実際のコードってジリジリとずれていくんですけどそれに全然気づかないみたいなことが起こったりして、気づくともうなんか割と中身把握できてないみたいな感じになっちゃう。
これはコーディングエージェントとかLLMの能力が上がった結果、破綻しなくなってきたので、いよいよ破綻しないけど中身は分かっていない、人間の方は中身が分かっていないみたいな時代にすっかり入ってきたなっていうのがここ数ヶ月という感じです。
本当そうですよね。それこそ僕がマネジメントしてる時とかもう本当に優秀なエンジニアが書いてくるコードとか理解できないっていうか、まあ多分大丈夫でしょっていうのと別にそこまで細部まで理解する必要ないよねっていうのも相まってもうコードレビューとかもしなくなるしみたいなのがあって、
それと似たようなことが結構エージェントに対しても起きてきてるなっていうところとかがありつつも、多分なんか思う点としては、まずそういう意味でリンターとかそういったものをちゃんと適用するとか、逆に人間だったらここはノークリティック的な、
そういうヒントを書いてリンターを回避するマジック文句をつけるみたいなことが結構あったと思うんだけども、AIにやらせるときはそういった例外を背したほうが変なワークアラウンドを書き連ねなくて済むなっていうのは最近ちょっと思ってるところなんですけど、
ただ逆に結構オーバーエンジニアリングしがちっていう問題がまだあると思っていて、とにかく問題が起きたときにコードを書き足すことでやっぱり解決しちゃおうとするっていう部分がすごくあるので、それでコード量が増えちゃうっていうのが問題になることもあって、
そこは減らしたほうがいいんじゃないかなっていうふうに思うこともあるし、ただそれって割と人間向けの割り切り的な考え方で、ちゃんとやるんだったらさっきのリンターの話みたいに、もう例外なくきっちり書かせたほうがいいのではないかみたいなところで、今そういったとこで僕は悩ましさを感じている部分ではありますね。
それはめちゃめちゃよくわかるところで、僕もこの間ツイートしたんですけど、なんでそんなことになってるのみたいな割と大げさな問題に対して、この解決策って不当に大げさだなみたいなことを目撃することが、コーディングエージェントの仕事を見てると目撃することがあって、
で、なんでここまで大がかりのやり方が必要なんだっけとか、なぜ、今ソームさんおっしゃったように、なぜ足すことで解決しようとするのっていうのは、これそもそもそもそもだよって、そもそもこれっていらないんじゃないのとか、こういう考え方をしたほうがいいんじゃないのみたいな感じで割り込むとか介入するという瞬間はやっぱり未だにあって、
これは設計判断のバランス的なところで言うと、なんかそうですよね、まだ妥協が下手というか、その何だろう妥当な範囲での手の抜き方とかが上手く教えないとコーディングエージェントはできないなとか、
これってやっぱりだから価値判断とかも含めてもうちょっと明文化して教えてやれば上手くなってくるというところもあると思うんですけど、どうしてもベテランシニアエンジニアは一種の新体値みたいな、なんか経験からくる新体値みたいな感じで、
このソリューションに対して、この問題に対してこの解決策っていうのはちょっと大げさすぎるなとか、後で過言を残しそうとか、そういったところでブレーキを踏むんですけど、それがなかなか伝えにくい。これはジュニアエンジニアに伝えにくいのと同様にAIにもなかなか伝えにくいみたいな感じはありますね。
そうですね。なんかやっぱり仕様とか、利用者の側の使い方で調整すればいいことをすべてのパターンを網羅的に解決しようとしちゃうみたいなところはあるし、結構GPT 5.6とかが、ソルとかがそういう傾向が強いなっていう感じはしていますね。
たぶんなんかそういう、いろんなことに気が回るようになった分、いろんなことをちゃんと解決しようとしちゃうみたいな。それって結構エンジニアとして成長するときもあったじゃないですか。割といろんなところが、ちょっとした行動を書くだけなのに気になって、ついつい膨れちゃうみたいなことが、エージェントでも起きてるなっていうのは感じますね。
そうですね。なんかこの話もありつつも、でも理解不細の話をもうちょっと伺おうかなっていうふうに思うんですけど、なんかやっぱり理解不細が問題になってきたみたいなところを、なんかもうちょっと伺っていいですかね。
認知負債の深刻化と開発生産性の変化
そうですね。その理解不細とか認知不細とか、名前としてはいくつかパターン、プレーはあるんですけど、要するに人間の頭の中のメンタルモデルのずれ、人間の理解が置き去りになっているっていうのが、今やっぱりどんどん問題になってきています。
ちょっと前まではさっき言ったように行動の保守性が問題だったんだけど、今は人間の理解のずれの方が問題であるという話ですね。で、何でかっていうと、この認知不細とか理解不細ってやつは見えないのがとにかく手ごわいんですよね。
で、これまでってコードって良くも悪くも、人間が理解してないとコードって書けなかったんですよね。コーディングエージェントが出てくる前の時代は、人間が書いたコードはその人間の理解を良くも悪くも反映してました。
だから理解が浅い人のコードは理解が浅い感じだし、それはドメインに対する理解もあれば、言語とか技術に対する理解もあるんですけど、とにもかくにも理解をしていないとコードを書けなかったから、結果的に出てきたコードを見て、コードを書いた人っていうのが対象の世界とか技術に対してどのくらい理解ができているかというのの動機が取れていたし、レビューもできたんですよね。
これは、だからこそ理解を育てていくっていう方向に育てることもできるし、レビューも機能するという感じです。つまりコーディングエージェントが出てくる前までは、コードを書く速度とかコードの中身と人間の理解との間の動機が取れていたので、結果的に出てきたコードとかあるいはドキュメントを見れば対象の人間というのがどのくらい内容を理解しているかっていうのを判別ができたと。
なんですけど、コーディングエージェントが出てきてここ2年ぐらいで、理解しなくてもコードが出てくるようになっちゃったんですよね。なので、人間側はさっぱり理解はしてないけど、コードはすごくそれっぽいコードが、しかもすごい速いスピードで出てくるというような感じになっちゃいました。
結果的になので、分かってコードを書いているのか、つまり分かって指示を出しているのかって話にもつながるんですけど、指示を出した人間の方が問題を理解しているのかとか対象の構造を理解しているのかっていうのが、出てきたコードからは測れなくなってしまって、結果的に品質保証という観点でいうと、このコードをどこまで信じればいいのかとか、そういうのが分からなくなってきてしまった。
ということはつまり、全部疑ってかからなければならない。品質保証の観点でいうと、全部疑ってかからなければならないという話になるので、結果的にはそのAIストップ問題と同じように、生成する方はコストが低くなり、検証する方はどんどんどんどんコストが高くなるというような構造になっちゃったんですね。
これまでは検証する方、レビューする方は出てきたコードの、正直出てきたコードの見た目というのは中身とある程度相関があって、分かっている人のコードはそれなりの見た目をしているし、分かってない人のコードはやっぱりそういう見た目をしているみたいな形だったんですけど、
そういった見た目とか、あるいは構造のきれいさとか分量とかでは、中身を測れなくなってしまったというのがやっぱりでかいんですね。そうすると、人間の理解のズレというのを測るメトリックスが今のところないので、
本当に分かっているのかな、分かっていないのかなとか、この判断は適切に行われていそうだろうかとか、そのあたりっていうのもやろうと思ったら全部疑ってかからなければならなくなってしまったと。
これが、生成と検証のコストのバランスが大きく崩れてしまったということで、認知不採として問題になってきています。
それらの理解を置き去りにすれば進捗を上げられるようになっちゃったっていうのがだいぶまずくって、これまで開発生産性のメトリックスって、例えばドーラの4キースとか5キースとかあったんですけど、
これまでは開発している組織の能力というのを、それらのメトリックスというのがある程度表していたんですけど、
今やコーディングエージェントをガンガン回せば、開発生産性の特に開発のスループットのメトリックスとかはどんどん上げられるようになってしまったので、
リードタイムどんどん短くできるし、デプロイ頻度を高められるよみたいな感じになっちゃったので、
結果、開発生産性のメトリックスっていうのが、ハックできるようになってしまったという感じです。
そうすると、これまでエンジニアの個人評価というやつは、
大体、より早く、より多く機能を作った人が評価が高いみたいな感じになりがちでした、どうしても。
そういう、より早く、より多くの機能を作るエンジニアの評価が高いという個人評価のところと、
また企業レベルでいうと、競合他社に対して、より早く、より多い機能を出すことによって競争優位を得たいっていう企業レベルの価値観と共犯関係になっちゃうんですよね。
組織は、例えば事業は、より早く、より多く機能を作って競争優位を得たい。
個人は、より早く、より多く機能を作る行動を書くことによって個人評価を上げたいっていうところが、その理解を置き去りに、犠牲に捧げることによって、
共犯関係が成り立ってしまうという構造が出来上がっていて、危ない、危ういというふうに思っています。
はい、ありがとうございます。そうですよね、そう。なんか、理解を置き去りにすると危ういだろうなっていう感じはするんですけど、
なんで危ういですかねっていう、それでちゃんと継続的にデプロイできていて失敗率も低いんだったらそれでいいんじゃないのっていう話もあるわけじゃないですか。
そうですよね、そう。なので、一見それでいいように見えるんですよね。
何事もなければ、それでそのまま進むでも構わないんですけど、人間の理解が置き去りになると、どこがまずいかというと、
結果的にじわじわとまずくなっていくというふうに言われています。
何でかっていうと、その理解が伴わないと、結果的に判断力にだんだんボディーブローのように効いてくるからです。
新しい機能を追加するときに、どのような場所にどのような機能を追加するべきか、どういう順番で機能を追加していく方がいいか、
ここに対してやりすぎになるソリューションはどういうものか、あるいはやらなさすぎはどういうものか、みたいなところですとか、
あるいはある不具合が出てきたときに、その不具合の原因というものがどこに起因しているかっていうのを、
AIに頼ればなんとかなるかもしれないけど、もう少し絞り込みを早くしていくためには、人間側がシステムに対する、
世間に対する理解が深い方がいいですし、顧客に対する理解とかシステムに対する理解もそうなんですけど、
結局人間が持っているメンタルモデル、このシステムはこういう思想で、こういう要件に対してこのような設計がなされている。
だからこういうコードになっているはずだという理解と、実際にはそういうコードにはなっていないというのの乖離が大きくなると、
結果的にその見積もりの精度だとか、問題解決の速度とか精度とか、そういったものにじわじわじわじわ効いてくるんですね。
それが続くとどうなるかというと、結果的には品質のメトリックスというところがじわじわと下がっていくという形で現れてくるだろうというふうに言われていて、
実際に今、速度のメトリックスっていうのは引き続き増加傾向にあるんですけど、品質のメトリックスっていうのがじわじわと悪化傾向に、
世界中でなっているっていうのはそのあたり、割といろんなものを置き去りにして先に進んでいるっていうところの現れかなと思っています。
そうですよね。だから品質とか価値みたいなものをどういうふうに計測っていうか、そこの人間にとっての使いやすさとか価値みたいなところのハンドルを手放さないようにしないと、
そこを動かすことがどんどん難しくなっちゃうみたいなのは絶対ありますよね。
あと、やっぱりシステムエラーできてないかもしれないけど、人間にとって実はお客様にとって使いづらいものになってるみたいなこととかは絶対起きてきちゃうっていうのはあるだろうなと思うし、
やっぱりそういう理解不細みたいなところで言うと、最近だってやっとレビューがボトルネックになっちゃうから、そのあたりについて言われがちなんだけど、
結局そこがボトルネックが解消、仮にされたとしても、お客様の方が認知不細が高くなってついてこれなくなるっていうことが起きちゃうよねっていうのは絶対思ってるんですよね。
それは明らかにあって、例えばエンジニアの方の認知不細の問題みたいなのも、例えば解決されて、より理解を置き去りにせずスピード早く開発できるようになったとしても、
そうするとシステムの方はどんどん新しい機能が日々増え続けるみたいな感じになって、それが例えばどのようなタイプのシステムをどのようなお客様に提供しているかによっても結構違いはありますけど、
機能がただひたすら増え続けるとか変わり続けるみたいなシステムを望む人ってそんなに多くはないんですよね。ので、実はボトルネックって別にシステム開発の側にはそんなになくって、
それよりも顧客の獲得であるとか、顧客の方の理解であるとか利用の促進であるとか、そっちの方がずっとボトルネックなので、だからそこ頑張ってもねみたいなところはあるんですよね。
で、例えばクロードコードとかエージェンティックコーディングで日々開発されて日々機能が増え続けてますけど、じゃあその利用者たる我々がクロードコードやつぎ早に機能が追加され続け変更され続けることが嬉しいかっていうと、別にそこまで早くなくていいよねというか、
そこまで早く出てこられても追いつくのも大変になってしまうし、コロコロ変わられてもみたいなところがあるので、早ければいいっていうものではないんですよねっていうのは明らかにあると思います。
そうですよね。なんかその点でやっぱ思うことは2点ぐらいあって、一つはやっぱりゲーム会社とかってもともとデバッグツールとかそういったものをめちゃくちゃ作り込んでその検証スピードとかを上げてたっていうか、そこも肝だったわけだと思うし今もそうしてると思うんですけど、
多分なんかそういったところを普通の一般的なシステム開発とかでもそこの作り込みみたいなところをやっぱりもっとちゃんとやったほうがいいし、それこそそういったところもAIに一緒に作ってもらうであるとか、あとやっぱデプロイした後、リリースした後にちゃんとお客様が正しく使ってるかどうかみたいなところもちゃんと検証してダメだったらもう戻すなり改善するみたいな。
どうしてもリリースしてエラーが出てなかったら終わりみたいな、結局そのフォーメトリー、フォーキーズとかもそういう視点の指標でしかないので、その後ちゃんと価値を出してるかっていうところとか、検証しやすさのためにちゃんともっとプログラムを書いたりするAIを使うっていうのをやらないとダメなんだろうなっていうのは思いますね。
まったく同意ですね。
あともう一つあるのは、コーディングエージェントみたいなものが特にそうなんですけど、やっぱり百得ナイフを作りやすくなってるし、コーディングエージェント自体が百得ナイフ化してきてるっていうのはすごくありますよねっていうのがあって。
例えば、最近のコーディングエージェントって必要だから音声入力機構とか、あとサンドボックス機構みたいなのを持ってると思うんですけど、それって本来というか、ある意味疎結合なソフトウェア設計をするなら、音声入力っていうものは別にエージェント自体が内包する必要はなくて、
音声入力の入力がエージェントに渡ってくればいいじゃんっていう話だったりとか、サンドボックス機構もまずサンドボックスが立ち上がり、その中でエージェントが動けばいいじゃんっていう感じだけど、結局エージェントもそういうのを持っちゃうみたいなのがあって。
でもエージェントが提供するサンドボックス機構って本当に私になるんだっけみたいな、そういう、やっぱり百得ナイフ化しやすいなっていうのも感じてますね。
めっちゃわかるという感じですね、本当に。どんどんどんどんそうなっていくし、エンジニアにとってのスーパーアプリみたいな感じになっていきますよね。
そうですね、スーパーアプリみたいな。
Stacked Pull RequestとAI時代の開発ツール
はい、じゃあこの発表の話はこれぐらいにして、どうせ似たような話はいくらでもする気がするんですけど、ちょっとGitHubの話をT和田さんから出してくださってるんで、ちょっとその話をしますか。
はい、ぜひという感じなんで、これはどっちかというと僕が聞きたい話っていうか、ソムさんにこそ聞きたい話みたいな感じだけど、今日かな、昨日か。
収録しているちょうど最近GitHubのスタックとプルリクエストってやつが、これがGA、違う、パブリックプレビューか、になったので、これから多分使っていくって感じになると思うんですけど、
これって何ですかっていうところと、何がどう嬉しいんですかみたいなところを、むしろ僕がソムさんに聞きたいみたいな感じで話題を持ってきました。
はい、ありがとうございます。そうですね、ちょうど今日ですね、日本的には多分今日の深夜ぐらいに来て、おおってなった機能なんですけど、
僕もあんまり追いかけてはなかったんですが、テクニカルプレビュー、プライベートプレビューみたいなのが少し前からあって、パブリックプレビューになってご利用いただけるようになったっていうやつで、
これは長年欲しかったやつだと思っていて、プルリクエストをスタックできます、積むことができますっていうやつになりますと。
例えば、ある一連の機能開発をしているときに、一番のプルリクエスト、一段落したので一番のプルリクエストを出しました。
ただ、一応プルリクエスト出してレビューは出したんだけど、そのブランチからまたブランチを切って別の作業をしたいってことはあると思うんですよね。
そこで作業を継続しながら、上流のブランチのレビューを待つ、さらにそれをブランチしてみたいな、ブランチからブランチを切ってみたいなことがあると思うんですね。
そのときにやり方としてはいくつかあって、例えば1,2,3っていうふうにブランチしていったときに、1をマージして、2をマージして、3をマージしてみたいな、そういう形でやるパターンと、
全部まとめて最後にガバッとマージしちゃうっていうパターンがあると思うんですね。
で、そのときに、今まであった、まず順番にマージしていくスタイルだと、一応レビューしてもらったら、ちょっといくつか素敵事項が出てきて、それをちょっと修正して、
そうすると、2番の修正とまた別の世界線ができて困るみたいなのがあるわけですよね。これまでは、1番のプルリクエストがめでたくマージされたとして、じゃあ2番のプルリクエストは、
まず改めてリベースしてベースを向け直してみたいなのが必要だったんですけど、スタックにしとくとその辺を自動でやってくれるので、1番のプルリクエストをマージしたら、2番のプルリクエストはちゃんと1番の最新状態をリベースした状態で、ちゃんと向き先もメインブランチに向けてくれるみたいな、そういったことをしてくれるっていうのがまず一つ。
あとは、1番、2番、3番みたいに分かれていったときに、最終的に3番を2番にマージして、2番を1番にマージして、1番をメインにマージしてみたいな、それでまとめて全部一気にメインに反映するみたいなことがあったと思うんですけど、
それをまとめてマージするっていうモデルでも、3をマージするってやると、それを全部メインに持ってくるっていう、そういったこともできるようになったっていう、そういう形ですね。
なので、一つのプルリクエストを分割して見たいっていうときもあると思うので、結構地味に嬉しい。これまですごい手作業で何度もマージしたりリベースしたり、コンフリクト解消したりみたいなのもあったんですけど、そういったことが自動的にやってくれるし、
たぶんコンフリクトとかしたときも、今ある程度コパイロットがマージ解消してくれるみたいな感じのはずですね。
なるほどなぁ。確かにコパイロットが後ろにいるからこそ、実現に近づいた機能でもあるって感じですかね。これまでコツコツ割と人間が頑張ってリベースしてついていく、リベースしてついていくみたいな感じでやっていた運用を自動的にできるようになったってところがやっぱりでかいのかなぁ。
嬉しい。なのでちょっといろいろこれから使っていくのかなぁと思いながらニュースリリースを見てたっていう感じです。
そうですね。なんか普通にこう、なんだろう、昔の開発だったら嬉しかっただろうなっていう気はなんかしているんですけど、してるし便利だなぁと思うんですけど、逆に今もう綺麗にコミットを作るとか、なんか差分を小さく保つみたいなことをそんなにやらなくなりつつあるので、
もう結局一個のプルリクエストとかにバンバンコーディングエンジンとか差分を放り込んで、それをバッてマージするってなりがちだから、これがどこまで嬉しいかどうかっていうのは正直わかんないけど、でもずっと欲しかった機能だなと思ってはいますね。
なるほどなぁ。なんか待ち望んでいたけど、時代はもうそれを先に行っていくみたいな感じは、確かにまぁ、例えば2年前とかだったらめちゃくちゃ嬉しいですよね、この機能。
すごい嬉しいですね。やっぱりその普通にチーム開発してるときにそのレビュー待ちの時間にやることがないみたいになっちゃうと困るんで、レビューは出したけどそこからまだ作業続けるみたいなのめちゃくちゃあったんで、
そうすると、それで結局差異が出たときに解消するのとかすごいめんどくさかったけど、これはすごい便利っていう感じではありますよね。
なるほどなぁ。これ聞けてよかったです。聞けてよかったし、確かにそうなんですよね、プルリクエストという形式自体、これから先も使っていくのかどうなのかみたいなところも結構人によって意見が分かれたりしているし、
なんかコミットの綺麗さとかプルリクエストの流度とかも割となんかもうあんまり考えないみたいな人もいるし、僕は割と人間とAI足並みを揃えるというか、割と合わせる派なんですけど、
そのなんかこまめにコミットさせるし、コミットをリベースさせるしみたいな感じなんですけど、結構やっぱりもうだいぶ、もうそんなん時代遅れだよみたいなこと言う人もいますよね。
そうですね、その辺やっぱり難しいなーっていうのは思いますね、はい。まあでも僕もちょっと綺麗にしたいなって思うし、やっぱコミット綺麗にまとまってそこにある程度綺麗なコミットメッセージ入ってる方が
後でも意図がやっぱり、意図を残しやすいなっていうのは思いますね。やっぱりコミットとかプルリクエストに意図をちゃんと残しとかないと後で人間がやっぱり理解していなくなっちゃうっていうのはありますよね。
まあでもそうなんですよ、なんか今年マイクロソフトビルドに行かれてたじゃないですか、なんか宮川さんのリビルドにTワダさんが出られて、ああそうなんだってなりましたっていうのと、やっぱり僕がGitHub入ってすごい思ったこととしては、
結構Azure系とかマイクロソフト系のコミュニティと、そのAWS、Google系のコミュニティっていうか、その辺のコミュニティすごくかなり断絶って言うとあれですけど、すごい世界線が分かれてるなっていうのと、僕もなんか全然知らなかったみたいなのがたくさんあって。
で、こっちはMSのほうはAzureとかそういうCシャープVSコードみたいなところって、そこはちゃんと実はコミュニティがちゃんとあったんだなみたいな、そういうのを感じているところです。
そうですよね。いや、わかりますっていう感じなんですけど、僕もそうですし、宮川さんもそうだし、ソンムさんもそうなんですけど、どっちかっていうとOSSでランプスタックで、ウェブ系でみたいな感じで育ってきて。
で、そこで例えばマイクロソフトのビールドとかに行くと、やっぱりカルチャーが違うところもあれば混ざっているところもあるみたいな、その意味だとマイクロソフトってもはやGitHubもそうだし、VSコードもそうだし、NPMもそうだし、タイプスクリプションもそうだしみたいな感じで、
もはやすっかりその馴染み深いものなんですけど、でもやっぱりなんかコミュニティ、人としての重なりがまだまだ少なかったりとか、文化的な重なりがまだまだ少なかったりみたいな感じがあるので、その意味でそのなんだろう、
とざまとしてマイクロソフトビールドにサンフランシスコに行ってみて、やっぱり結構面白かったなと思う体験をしました。
それは良かったですね。やっぱりGitHubコパイロットみたいなものが、みんなエディタ上でいい感じに保管をしてくれるっていうプリミティブな先を予測するLLMのユースケースとして出てきたものなんですけど、
みんなそこでなんか理解が、認識が止まってて、その後やっぱクロードコードとかが出てきてきたから、やっぱクロードコードすげえって、僕も去年なってたんですごくわかるんですけど、っていうのはあって、でもそのコパイロットもVSコード内で動くみたいなのがメインだったんですけど、
最近はCLIとかも出てきて、全然その遜色なく使えるんですけど、あんまりそれが知られてないなっていうところは思うところなんですよね。それこそさっき1年前の話をしてたんですけど、今から1年前って7月、8月で、多分クロードコードが去年の4月とかに出てきて、
マックスプランも6月ぐらいに出たのから、それでもうすごい、これはもう革命だみたいに思ってて、僕ら思ってたし、去年もその話したわけじゃないですか。その後に、9月にGitHubもVSコード上でエージェンティックに動くモードはあったんですけど、独自のTUIとしてCLIが出てきたのって9月なんですよね。
だから5ヶ月後ぐらいなんですけど、その後めちゃくちゃなスピードで開発がキャッチアップして、今、全然遜色ないレベルで使えると僕は思っているんですけど、もうそこの5ヶ月で決定的なかなり認知の差とかが生まれてしまってて、結構恐ろしい時代だなって思ったりしてます。
そのプランの価格改定の話とかも多分あんまり、ちょっと前にあったんですけど、理解されてる人って少なくて、実はあれって、コパイロットってエンタープライズ向けのプランってめちゃくちゃ安く使えてたっていうのがあるんですよ。
1回のエージェントとのターンに対していくらですっていう、そういう課金モデルだったので、そのターンを引き延ばせば引き延ばすほどお得っていう、しかもそれって全然安く使えるっていう状態だったのが、それだとちょっと成り立たないから普通にそのターン内のトークン消費量に対してご請求させてくださいっていう話なんですけど、
だからそうすると、もともとすごい安かったからすごくお金がかかるようになっちゃったし、でもそれって別に他のエンタープライズの他社、他ベンダーさんのエンタープライズのモデル料金と変わんないんですよねっていうのがあって、
そういうちょっと本当にコパイロット個々の点でかなり送料取っちゃってるなって、性能的にはもうかなり問題ないし、あと例えば普通に、モデルは独自のモデルがあんまり提供してない分、別にオーパスとGPT両方使えるみたいなのがあるんで、すごい僕としては便利に使ってるっていうのがありますね。
ソムさん、マイクロソフトビルド、サンフランシスコのビルドに行って、ビルドで大きくGitHubとかコパイロットって観点で大きくフィーチャーされてたのって、GitHubコパイロットアップってアプリなんですけど、あれ自身はどんな感じですかっていうか、
僕は時々使うみたいな、やっぱりメインの軸足はクロードコードとかクロードデスクトップなんですけど、GitHubとの統合の、当たり前だけどGitHubとの親和性って観点で考えると、GitHubコパイロットアップのほうがずっと親和性が高くて、当たり前ですけど高くて、
だからGitHubを開発のワークフローの中心に据えてやっていくイシューとかプルリクエストとエージェンティックなコーディングっていうのを一つのアプリの中に統合した体験を作るとか、そういう観点でいうと、GitHubコパイロットアップよくできちゃうなと思いながら見てるって感じなんですけど、そのあたりって感覚としては合ってますか
おだしょー 合ってますね。というのと、これも僕がどこまで話すかって話はあるんですけど、多分、でも後追いになっちゃってる部分ってすごくあると思うんですよね。もともとクロードコードがCLI出してきて、ターミナルでの環境めちゃくちゃいいぞみたいなものがあって、そのコパイロットもCLI出しました。
で、あとその後やっぱコーデックスとかがアプリを出してきて、デスクトップアプリを出してきて、やっぱあの辺ってそのチャットGPT由来のすごいユーザー体験の良さみたいなのがやっぱり盛り込まれてると思うんですよね。で、そういったところでやっぱりアプリも出さないとっていう話もあって、多分GitHubアップも出てきたっていう感じにはなってて、結局でもGitHubアップも裏ではエンジンとしてはGitHub CLI、コパイロットCLI使ってたりはするので、
割とそういう関係にはなってるっていうところで。だから基本的にはやってることは一緒で、いろんなサーフェスを提供することが大事に最近はなってきてるっていうのがあるなって思ってますし、多分エンジニアに限らずいろんな人が使えるようにっていうところを、特に多分マイクロソフトなんかは目指してるんだろうなっていうのは感じますね。
結局、コアなエージェント機能とかLLMモデルみたいなところって、もちろん進化は続いてるんですけど、そこで差異を出すってよりかは結構サーフェスで差異を出すっていうか競争してるっていうフェーズに最近なってるなっていうのは思いますね。
そうだと思います。
はい。いや、なんかまだまだ話したいことはありそうで、時間的には45分ぐらい話して、後半のほうが長くなっちゃいそうなんですが、切りもいいので一旦この辺りで切りますかね。はい、ということで前半はこれぐらいで切ります。ありがとうございました。
ありがとうございました。
