Agentic Codingの進化
はい、趣味でOSSをやっている者だなんですが、今回なんとtwadaさんをお迎えして、お話を聞いていこうと思います。よろしくお願いします。
じゃあ、ちょっと今回いきなりなんか前置きなく始めちゃおうと思うんですけど、twadaさん、じゃあ自己紹介を改めて軽くしていただいていいでしょうか。
はい、よろしくお願いします。お招きいただいてありがとうございます。twadaと言います。wadapactと言います、名前は。
インターネット上だとtwadaさんと呼ばれています。仕事としてはコンサルタント、いわゆる技術顧問業とか、個人開発とか住宅開発とかOSSの開発とかをやっていますという感じです。よろしくお願いします。
はい、よろしくお願いします。そうですね、最近はということで、いろんなところでAgentic Codingとか、あとSQLアンチパターンとかそういったところのお話をされているのを聞いて、
まあちょっとぜひ1回お話、改めてお話したいなと思って、はい、お呼び立てした次第でございます。
じゃあまず前半はそうですね、多分そのファインディーさんでの講演もあった、そのAI時代のソフトウェア開発を考えるみたいな、そういったところについてお話ししていこうかなと思うんですけど、
そう、なんかもう最近twadaさんことある発表で、もうその2025年世界はVive Codingの熱に包まれたみたいなことを書いているんですけど、
多分もうtwadaさん自体もかなり熱狂しているっていうことが伺えるセリフだなと思ってるんですけど、最近なんかこのあたりどういうふうに付き合ってるかみたいなのってお話しいただいていいですか。
はい、Vive CodingとかAgentic Codingというやつですね、要するにAIエージェントにコードを書いてもらうやり方って言えばいいんですかね。
もう去年の末ぐらいからだいぶ進化が始まって、今年の2月にVive Codingという言葉が生まれて、
Vive Codingだけじゃなくてもうちょっとソフトエンジニアリングの要素を織り混ぜて、それをAgentic Codingと呼ぼうとか、
あるいはAgentic Engineeringと呼ぼうみたいな感じで、いくつか名前が模索されているところなんですけど、要するにクロードコードとか、
あるいはジェミニとかカーソルとかそういったのを使いながら、人間がメインでコードを書くんじゃなくてAIがメインでコードを書くというやり方でソフトウェアを開発していくというやり方が
だいぶビッグウェーブを作っていて、気がついたらみんなやってるみたいな状態になったのが6月とかそのくらいですかね。
私自身も4月ぐらいから本格的に触り始めて、こいつは結構すごいなぁというので、毎日触ってるみたいな状態が続いていましたという感じです。
そうですよね。結構脳を焼かれているみたいな、そういう状態だったりするのかなと思いますし。
別のファインディさんの30分のイベント、1時間の、たぶん水志さんとかもいらっしゃったようなイベントでも、クロードコードに命令をしてから寝たみたいなことをおっしゃってて、
いや、そこまでやっぱり言ってて、いやすごいなっていうのを思いました。僕はまだそこまで使いこなしていなくて、まだ結構恐る恐る対話の中でやってることが多いっていう感じなんですよね。
そこに至るまでにどういう変化、変遷をたどっていったかみたいなのって思い出すことできます?
えっとですね、僕自身もクロードコードとかに仕事任せて寝るみたいのは、どちらかというと研究としてやってるというか、
これからソフトウェア開発ってどういう姿になっていくんだろうっていうのをいろいろ試してみようという過程で、
じゃあやってみるかというような形で始めてみたというような形です。
AIと協業していく上でどのような協業のパターンがあるのかなとか、どのような協業のモードがあるのかなっていうのをちょっと模索している、いろんな方を模索している時期があって、
その中でAIへの協業のモード、僕は基本的なモードとして伴奏と委託っていう2つのモードを講演の中で定義してみたんですけど、
その委託というAIに任せるというやり方の一つ象徴的な姿として、
AIに仕事を依頼して寝て起きたらできてるかなっていうのをやってみようというのでやってみたというのがそのエピソードですね。
最初は僕もAI、ChatGPTと一緒に仕事をする時のようなコピー&ペーストプログラミングの一種としてエージェントとの協業っていうのを始めたんですけれども、
それがいつしか対話の中から、特にクロードコードというAIエージェントが出てきてからが変化が大きいんですけれども、
CLI、コマンドラインインターフェースというのは対話を通じて割と自律的に動いてくれる。
特にクロードが出てきてから瞑想をするという率が減ったんですよね。
何か帰ってこない、何か仕事をしたままあさっての方向に行ってしまって帰ってこないじゃなくて、
途中で何かおかしいなと思って帰ってこれる、方向修正ができるというような性質があるなということを発見して、
これはここまで自分で方向修正する力があるのであれば、一晩中走るとかもできるんじゃないかなみたいな感じで試してみるまでに至るという感じで、
だんだんだんだんなので、最初はおそるおそる対話でやってたんですけど、だんだんだんだん委託モードも試してみられるようになったという感じです。
そう、やっぱ最初は結構おそるおそるですよね。何されるかわかんないしみたいなところもあるから。
AIとの協業と変化
でもだんだんと、やっぱりその、これもティーワダさん何らかの文脈でおっしゃってましたけど、やっぱ定額になったっていうのは大きくて、
そういう意味でなんか結構気軽に失敗させられるとか試行錯誤できるみたいなところの気軽さが上がったことでちょっとこれも試してみよう、あれも試してみようみたいなことができるようになったっていうのはありますよね。
これ本当にそうで、クロードコードも最初は定額制じゃなかったんですよね。なのでAPI課金で、
で、1セッションごとになんかこのセッションは1ドルかかりましたみたいな感じになってうーみたいな感じの感覚だったんですけど、
クロードのMAXプランというのがクロードコードを重量課金ではなくて定額制にしますよというプライシングになったんですよね。
そうするとやっぱりインセンティブ設計が全然違うというか、これまで重量課金制だとやっぱりなるべくお金の消費を少なくするように、
なるべく手戻りなしで試行錯誤もなしで一発で正解にたどり着くようなプロンプトを編み出したいみたいな感じの心理状態になっていたんですけれども、
定額制の場合はもうどうせいくら試行錯誤しても同じ額を払ってるので、ダメだったらダメだったらやり直せばいいやとか、ダメだったらそれは捨てちゃってもう1回試せばいいやみたいな感じで、
まあ、陶器的プログラミングができるようになったガチャみたいな、よく言い合いをされてますけど、そういうのが試せるようになった。
まあ、良い表現すると試行錯誤を積極的に行えるようになったっていうのは大きい変化だなと思います。
そうですね、フィードバックサイクルみたいなものを複数同時に早く回せるっていうのはすごくいいところだなっていうのは思いますね。
ただ結構ガチャって言われる通り、実は多分ここの数ヶ月って、元々企業家とかそっちの方が一時期多分AIとかに対してかなり盛り上がってた時代から、
今ソフトウェアエンジニアの方が結構盛り上がってる状況なんじゃないかっていうふうに思っていて、
結構その冷静に眺めていたエンジニアが、今いつの間にか熱狂してるみたいなのがあると思うんですよね。
で、多分それを支えてるのって、なんかその生産性が爆上がりしたみたいなところもあるけど、
実はやっぱ中毒性の高さみたいなところにやられてるっていうところは、多分自覚した方がいいんじゃないかなっていうのは結構思ったりしてるんですよね。
ケントベックさんも先月いらっしゃってた時にアディクションっていうことを使ってましたし、同時にファンみたいな楽しいよねみたいなことも言ってて、
やっぱそういうなんていうかエージェンティックコーディングみたいなのがすごく中毒性が高くて、やっぱ楽しいっていうところが実は大事なところだなっていうのを思ってるし、
だからそういう意味では、逆にそれによって実は効率が落ちてるかもしれないとか、そういったところも含めて、
なんか冷静に判断しつつも、なんかその熱狂の渦に飛び込むみたいなことをやるのが大事なのかなっていうのをちょっと思ったりしています。
僕も全く同意で、特にやっぱり触り始めて最初の数週間とかは多分夢中になると思うんですよね。すごいなこれって感じになるし、思ったよりコードがかける。
あるいは思ったより、何て言うんですかね、対話がはかどるという感覚に多分驚くと思いますし、
結果的にいわゆるコードの出力量っていうか、各量っていうのはものすごい量になるし、何より腰が重くて取り組んでいなかったものにガンガン取り組めるようになるみたいな感覚はやっぱり特別なものなので、
夢中になるのもわかるという感じだと思います。
そうですね、一歩目が早くなるみたいなのすごくありますよね。なんかタスクとかもまず壁打ちから始めて、じゃあこれでやってみようかみたいな方針もうまく決められるし、
なんかちょっと後回しにしてたものも、とりあえずなんか対話を始めちゃえばなんとなくこう、ものが編み上がるみたいなこともあるので、ちょっとそこは驚きですよね。
あと、やっぱり中毒性の高さを後押しするものとして、やっぱりそのガチャ性みたいな、結構インプットを与えて正解が返ってくることもあるし、そうじゃないこともあるみたいなのもあると思うんですけど、結構その、
ある意味時にはストレスフルな意思疎通みたいなのをエージェントとAIとすることによって、それがなんか攻略できたみたいな、うまくいって攻略できたみたいな、その緊張と緩和みたいな、
そういうゲーム性だったりとか、あと時にはやっぱその無双状態みたいなのを味わえる時もあるので、もうこれ完全によくできたゲームだなっていうのを思うんですよね。
確かに、そうだな、そうですよね、プログラミングを確立のゲーム、あるいは攻略性のあるゲームみたいな感じの感覚にしたっていうところは、
ありますよね、確かになんか、この言い方なら通じるんだみたいな、何かキーワードを発見した時の感じとか、あるいはその簡単なお手本を見せたらその後、
1から100へAIのパワーでガンガンコードを書いていく様とか、そういったところやっぱりゲーム性があるなぁというのもよくわかります。
だから結構もう、ある意味ゲームとして楽しいから、効率実は落ちてるかもしれないけど、でもまあそれでも多分使うことにかなり意味があって、どんどん慣れていって、
そういう習熟度を上げていくっていうところにもすごく意味があるよなっていうのは思ったりしています。
OSS開発の課題
はい、じゃあちょっと次の話題に移っていこうと思うんですけど、
T和田さんはOSS開発者としての側面もあるみたいなことを以前深堀FMでもお話しされてましたけど、その上でやっぱりエージェンティックコーディングみたいなものをそこで活用してるみたいな話がされてたと思いますし、
僕もOSS最近も結構書いているので、そこでかなりAI支援を活用することが増えてきたんですけれども、
じゃあなんかOSSだからこそ、結構そのナイーブな問題、難しい問題っていうのが出てきたなっていうのを感じたりしているところなので、その辺の話をかなり深掘りしたいなと思って今日はちょっとこう主題の一つとしてお呼びしています。
この辺なんか、そうですね、まず結構これは難しい問題なんですけど、ライセンス問題とかあるじゃないですか。
なんかそのAIに結構書いてもらったコードのライセンスどうすればいいんだみたいな話とか、なんかこの辺はかなり難しい議論になってるなぁと思うんですけど、この辺ってなんかご意見とか知見とかあったりされますか。
これって現在進行形の難しい問題ですよね。ライセンス、そもそも著作権者が誰かって話もそうだし、そのAIが書いたコードの学習元のコードのライセンスはどうなんだという話もあるので、
結構大きいオープンソフトウェアのコントリビューションルールにAIによるコントリビューションを禁止するみたいなところも出てきてますよね。
例えば、どこでしたっけ、Red HatのOSSとかだったと思うんですけれども、これプルリクエストみたいなのを投げるときに、まあAIで作っていいな、そのなんていうか、まあ保証は原理的には難しいと思うんですけど、
そのコントリビューターに対して、AIで書いていないということを約束してもらうというような動きも出てきていて、これって一つは大きい理由はやはりライセンスの話で、
AIが書いたコードの学習元のライセンス自体が結構不明なので、OSSのライセンスは組み合わせが悪いやつ、混ぜてはいけないやつというのはいくつかあるわけで、
それは良い悪いの話ではなく、互換性のないものというのがあるので、そこに対して保証ができないというのをやはりリスクに感じていて、
AIによるコントリビューションを、非常に大きいかつ社会的責任を伴うOSSに関してはコントリビューションを避ける、AIによるコントリビューションは避けられる傾向にあるというのは最近出てきているなと思います
コードのコントロールと認識
そうですよね。そこがやっぱりかなり難しいし、僕としても自分のOSSをエージェントに書かせていることもあるんですけど、グレーな部分もあるよなっていうのを感じていて、
そうですね。それこそ、僕も以前の仕事であったんですけど、GPLv2とApacheライセンスみたいなものが互換性がないので、利用できないみたいな、そういったこともあったので、
やっぱりその学習元のところに自分が宣言しているライセンスと、コンフリクトするライセンスが含まれている可能性があるから、どうしてもそこは許容できない可能性があるっていう、これはかなり難しい話ですよね。
なので、T和田さんが深掘りでお話しされてた話でいうと、やっぱり自分の中での趣味OSSではなくて、多くの人に使われているような、それこそパワーアサートみたいなOSSの場合は、本番の行動みたいなものは全部T和田さんが書かれていて、
テストコードだったりドキュメントはAIに書かせているみたいなことも結構あるみたいな、そういう話をされてて。それってライセンス問題にも関わる話として捉えてたのかなって思ったんですけど、これはどういう背景でそういうことをされてるんですか。
いい質問だなと思って、あまりそれやってたときはライセンス問題はそこまでグレーゾーンなので、そこまでディスクを感じていたわけでは実はなかったんですけど、テストコードとプロダクトコードでは、やっぱりちょっと温度感が違うところがあるんですよね。
なので、利用者の方に使っていただくのはプロダクトコードの方なので、プロダクトコード自身は100%自分が書いたコードであるという状態をキープしたいなという話と、あとはライセンスよりもどちらかというと自分のコントロールとか確信の度合いっていうのが大きくてですね。
AIと一緒にコードを書いたり、あるいはAIにコードを書いてもらったりすると、やっぱり細部のところの把握がやっぱりできてないっていう感覚があるんですよね。細かいところを自分が実は認識できてないという感覚があって、これは僕の他のプロダクト、OSSのプロダクトの中でも、
僕以外の人が明らかに使ってそうな気配があるプロダクトと、明らかに僕しか使ってなさそうなやつっていうのがあって、その後者の方は割とAIにプロダクトコードも含めて書いてもらうっていうのを試してるんですね。
試した結果、新しい機能みたいなのが短い時間でドバッとできたりして、こいつはすごいぞって気持ちになるんだけど、こいつはすごいぞって気持ちと同時に、プロダクトコードを見てみると自分が書いたコードじゃないので、これいつ書いたんだっけとか、これどういう意図があるんだっけみたいな細部があやふやというのが出てきてしまうんですよね、良くも悪くも。
これはだから僕が隅々までコードレビューすればそんなことはないと思うんですけど、AIと一緒にコードワイワイ書いてるときってやっぱりノリで進んでしまうみたいなところがあるので、結果としてメインラインにマージされたけど自分があんまり細部把握してないコードみたいなのが増えてしまいがちになると。
そうすると説明責任みたいなのが果たせなくなるし、何より自信が持てなくなっちゃうんですよね。このプロダクトを使ってくださいって言いたいときに、実は細部は自分はもう把握していないというのが自分でわかってしまっている状態で人に進められるかっていうと、僕自身はあんまり進められないので、
大事なプロダクトに関しては隅々まで自分で把握している状態っていうのを維持したいというような感じなんですね。というので、どちらかというとライセンス問題も頭の端にはあるにはあるんですけど、どちらかというと自分が隅々まで認識している。
AIとのコラボレーションの結果
設計を認識している。実装も認識しているというようなコードを他の人に使ってもらいたいというような思いが強かったかなと思います。
なるほどなるほど、そういう形なんですね。確かに僕としても、ちょっと前に今はまだ生成AIに自分の文章を書かせたくないっていうブログエントリーを書いたんですけど、自分が伝えたい思いとかがあるものについては生成AIが書くよりも自分が書いたほうが多分反応とかをある程度想像しながら書けるし、
自分が書いた作品的な部分もあるからそういう思いもあるんだけど、ただ文章によってももうちょっとちゃんとしたモーラ的なドキュメントとかそういったものとかだったら、むしろAIとかにバンバン書かせちゃっていいなっていうふうに思うようになってて、コードもやっぱりそういう自分で書きたい部分とAIに書いてもらっていいなっていう部分っていうのはやっぱあるよなっていうのは僕も思いますね。
あと多分、コードレビューみたいなところが別おざなりになるっていうか、そういう話はあると思っていて、おざなりになるっていうか別にもうある程度普段の多分人間同士のコードレビューでもある程度信頼ベースで、いちいち細部まで見るみたいなコードレビューをするかっていうと、それはする人もいるんでしょうけど、なんか僕もあんまりしないみたいなのもあるし、
そのあたりで、やっぱそのAIに書かせたコードみたいなものが結構漏れが出ちゃうみたいなのはやっぱあるよなっていうのは思っているのと、あと多分これその将棋ソフトとかそういったのと似た話があって、将棋ソフトとかそういうのが叩き出してくる形成逆転手みたいなのを、僕ら人間がプロ棋士でも全然見抜けないみたいな、
そういう話が多分昔はあったりしたと思うんですけど、多分そういう僕らのセオリーと違うコードを何気に編み出してくることっていうのがあって、そこでなんかその違和感みたいなものを感じることもあれば、なんとなくもうそれに気づかずに受け入れちゃってて、後から見るとあれこれなんでこんなこと書いてるんだろうみたいに思うことって結構あったりしますよね。
ありますありますあります。それがすごくあって、なんかさも動きそうに見えるコードとかさも正しそうに見えるコードなんですけど、よくよく考えてみるとこれあれなんでこうしてるんだっけとか前提が違うなとか、そういった違和感を覚えるコードっていうのはやっぱり細かいところだと出てくるので、
そういうのにいかに敏感になるかとかいうところはやっぱり大事なんですけど、なのでなんか疲れてくるとレビューの目がざるになってしまうので、結構人間の認知資源みたいなものがAIと一緒にコーディングしていくときは大事になるなというふうには思いますし、
AIに実装してもらうとき、イタックモードで実装してもらうときはリアルタイムにそういうなんか変だなっていうのを見るのがもうできないので、もう指示として細かくコミットしてもらって、後から観察するみたいな、細かくコミットしてもらって非同期で仕事してもらってプレリクエストまで作ってもらうみたいな感じで、
そのプレリクエストのレビュー自体を人間のほうがみっちり行うし、ディフがでかくなっちゃうとやっぱり人間のものを見つけることができなくなってしまうので、コミットを細かくやってもらうことで、どちらかというと一つ一つのコミット、人間の脳に収まるサイズでのレビューっていうのを繰り返すみたいなのをちょっといろいろ試しているところです。
おだしょー そうですよね。人間の認知能力が限界になるみたいなところが、もともとそういうのあったと思うんですけど、それをもうより自覚させられる局面が増えてきてるっていうのは感じますね。
もともと、組織にせよ世の中にせよ変化させていくときに、やっぱその人間のある程度認知能力のアベレージだったりとか、そのあたりのある程度認知能力がそんな高くない人に合わせていくみたいなのもあると思うんですけど、AIはもう平等に人間を認知能力がない側に薙ぎ倒した感じがあって、
だからそこに付き合いすぎるとみんなが消耗するみたいな感じはすごくあるよなって思っています。たまになんかすごく、自分では書かないけど、いいコードみたいなのを書いてくることがあって、いいコードっていうか。
最近の僕のOSSの開発でも、マークダウンをパースするときに、もともと行頭から3つ配分が連続してたらページ区切りですよっていうのを実装だったんですけど、それをやろうとすると、
単純に全部をスプリットとかで分ければいいと思いきや、よくある話で3つの配分ってコードブロックの中に出てくることもあるし、あとはH2要素の過線として使われることもあるから、3つの配分が必ずしもHRであるとは限らないっていうのがあって。
で、これ結構悩ましい問題だなっていうのを考えたときに、どうやってやろうかって思ったら、なんかエージェントが出してきた回が、その3つの配分が出てきたら、それを全文から消してしまって、
それで改めてヘッディングの数を数えて、それが減ったら、それが本当のヘッディングだったっていう、そういうコードを書いてきたんですよ。すごい効率悪いんですけど、いろいろそれを受け入れざるを得ない理由もあり、受け入れることにしたんですけど、なるほど、そういう解法できたかみたいなのを思って、それはちょっと面白かったですね。
確かにそれは面白いですね。なかなかその発想はなかったっていうコードを出してくるって瞬間っていうのが時々あって、面白いですよね。確かに僕もあったな。
なんか、そんな手で来るのみたいな感じの、そんな手で来るのっていうのが面白い喜びであるときはあって、なんか不快なとき、だからそれはダメだよみたいな感じのときもあれば、全然思ってもいなかったけど、それも悪くないねというような手を出してくることもあって、校舎の方はやっぱり割と知的な喜びみたいなのがあったりして面白いですね。
そうですよね。まだ多分AIがこれからもっと成熟するだろうし、僕らの使いこなしレベルも上がってくると思うんですけど、まだやっぱりかなり自分たちで手書きをしないといけないところは多いなっていう印象はありますよね。
僕もこの7月はケイイチローデックっていうマークダウンからGoogleプレゼンテーションを生成してくれるっていう、そういうOSSにめちゃくちゃコントリビュートしてて、なんかカウントしたら7月に9000行ぐらいコントリビュートしてたんですよね。
でもこれはもうAIの力がなければ書けなかったコード量だなっていうのを思っていますし、このプロジェクトはもう最初から結構クロードコードが書いたコードが入ってたから、じゃあ別に使ってもいいかっていう感じで結構使ったんですよ。
コーディングにおけるAIの影響
そうしたら結構いろいろ面白かったのと、あと、ただやっぱり機能追加とかパフォーマンスチューニングとかをしていく中で、そもそもの設計が力技だったりするところとか無理やり解決してるところみたいなのを、実は結構きれいに直していかないといけないところがかなりあるっていうことに気づき、
そういったところとかは、かなり自分でやらないとやった方がまだ早いなっていう感じにはなっちゃいましたね。特に最後の方とかパフォーマンスチューニングしてて、スライド生成の速度を30倍ぐらいにしたんですけど、
その辺はかなり細部を詰めていくような、コードを書き分けて整理して順番を入れ替えてみたいな、そういったところだったので、そこはかなり僕の手でしかできないっていうのと、逆にでもGitHub Copilotとか逆に僕の人を組んでくれるからいい感じのコードを出してくれて、
結構またタブをポチポチするコーディング体験をまた思い出すみたいなことをやっていました。
ありますね、それは。なので、粗くガッと量を書くのは、例えばクロードコードみたいなエージェントでやって、最終的にプレリクエストとかあるフィーチャーの後半に行くと、人間による手直しのコミットっていうのがいくつか入るパターンが多いんですけど、
それは人間が手でやるんですけど、もはやゼロから手で書いたりしないんですよね。コパイロットオンにしてやっていくので、人間とGitHub Copilotの思考の同期性っていうのは、エージェントより高いって言うんですかね。
自分の手足の延長のように動いてくれるので、最初はコンソールでクロードコードでガーッとコードを書いて、細部の手直しのところはVSコードを立ち上げて、GitHub Copilotをオンにして、細かいところを整えていくみたいな、これよくある協業のパターンだなと思います。
おだしょー そうか、そう。思考の同期性が高いっていうのは本当おっしゃる通りだなっていうのは思いました。なるほど。ありがとうございます。じゃあもう一つ、ティーワダさん持ってきてくださった話題ですけど、AIの登場でメンテナーとコントリビューターの関係を支えていた信頼が崩れつつあるのではないか。これはどういうお話ですか。
先ほどの大きめの大規模OSSに対するAIにアシストされたプルリクエストのコントリビューションが避けられているみたいな背景にも関係してくるんですけど、AIが書いてきたコード、エージェントと一緒に書いたコードってだいぶ見た目がちゃんとしているので、コードの見た目ですね。
なので、しっかりしてそうに見えるんですけど、でも結果しっかりしていないみたいなプルリクエストもあったりするんですけど、それを見分けるコストっていうのが特にコントリビューターの多いOSSであればあるほどコストが上がり続けているという問題があって、
エージェントのアシストによって様々な人がコードを書けるようになったり、あるいはこれまで例えばイシューを報告するのみだった人がイシュー報告するだけじゃなくてプルリクエストを送ることができるようになったりみたいな形で、一見するとすごく良いことのように思えるし、良いことであるという側面もあるんですけど、
OSSのメンテナーとかプロジェクトの方にしてみると、これまではパッチとかプルリクエストをプロジェクトに送ってくる人は対象の問題を理解していて、
対象の問題に対する解決策というのを自分で考えて、自分でコードの差分として提案してくることができる、その能力を備えているという暗黙の了解の下に成り立っていたんですよね。
だから、きちんとこういったプルリクエストの本文とかコミットログとかコミットそのものをきちんと書ける人はそれなりの実力を備えていて、対象の問題を理解していてというような前提に立っていたんですけど、
最近その辺りのプルリクエストの見た目であるとか、英文そのものであるとか、それの説明の詳細さであるとか、そういったものでAIを使っていくらでも増やせるようになったんですよね。
あるいはそれなりの見た目になるようになったので、そうすると受け入れ側がこれって本当に問題解決になっているのかなとか、これは受け入れて良い差分なんだろうか、プルリクエストとかパッチなんだろうかというのを見分けるのがすごく難しくなっちゃったんですよね。
難しくなっちゃった上に、さらにライセンス問題の何らかの不安があるってなると、やはり大手のOSSはAIによるコントリビューションを避けたくなるっていう心情も分かるなというところですし、
メンテナー側からすると、そのでかいプルリクエストを自分たちで再度理解してメンテナンスしていきたい行動にできるかというと結構それもコストがかかるので、割と嬉しいところもあれば嬉しくないところもあるんですよね。
だからOSSの作者によってはプルリクエストを閉じちゃってる人もいますよね。なんか一周のみ開けていて、問題を報告してほしいと。それに対する解決は自分でやるというタイプの人もいたりするので、そういうのも分かるなって感じなんですけど。
とにかく一番は対象の問題を理解していて問題解決能力があるということをある程度プルリクエストの中身とか、あるいは解決策の筋の良さとかそういったところで判断していたっていうところが判断しにくくなって、
みんなある程度その平均点以上の解決をしてくるようになったけど、細部が怪しいみたいな細部が怪しいっていうのを見抜くコストが高すぎる問題っていうのが発生してきているなというふうに思います。特に大きいOSSは大変そうですね、それ見ていると。
いや大変そうですよね、その辺り。確かにそういうプルリクエストを送れるコストが下がったので、逆にただどうしてもプルリクエスト取り込むところはどうしても人力になりがちなので、ってなってしまうし、そこはちゃんと行動オーナーが責任持ってやったほうがいいと思うので、だからこそそこの負担が増えてしまうっていうのはありそうですよね。
メンテナーの課題
なんか僕も、だから結構今月ケイイチローデックにめっちゃプルリクエスト送ってたんですけど、ちょっと結構しっかりケイイチローさんがさばいてくださるのでありがたいなと思いつつ、若干大丈夫かなって心配してるのもありましたし、やっぱり一個一個のプルリクの流度を小さくしたり、逆にその変更行数が行動量が減るようなプルリクエストを心がけて送るみたいなのはやったりはしていました。
やっぱカールの話とかもありますよね。セキュリティスキャナーみたいなものでスキャンしたやつをもうなんていうか、みんなが一周上げてくるから、そういう爆撃みたいな大変だみたいなのがあるので、とりあえずそういうツールを使って問題報告してくる人はどんどん増えてるっていう問題がすごくありそうですよね。
でもこれもどうすればいいんですかね。それこそ僕もプルリクエストとかいただいたときは、その人のプロフィールとかを見に行って、なんとなくどういう貢献した人なのかなとか、どういう感じの人なのかなっていうのを見に行ったりして、その上でこの人は結構信頼できそうなみたいなのを判断しちゃったりするんですけど、そういう動きがより加速してしまう可能性もありますよね。
そう、僕もOSSにプルリクエストをもらうことっていうのもそれなりにあるんですけど、何ていうか初めてプルリクエストを送ってくる人がどういう人かってやっぱりプロフィールページ見に行きますよね。
プロフィールページ見に行って、最近のコミットはどんなコミットかなとか、他にどんなプロジェクトにコントリビューションしてるだろうかとか、どのくらいプルリクエストはアクセプトされてるかなとか、やっぱり見に行くし、ある程度そういった何らかの信頼、特に、例えばケイチュロさんとソンムさんの間にはもう信頼関係があるから、
ソンムさんのプルリクだったら、このくらいの濃度でレビューしてアクセプトしようみたいな感じになると思うんですけど、これが不特定多数の人のコントリビューションを受けるとか、あるいは初めての人のコントリビューションを受けるだとやっぱり、どうしてもメンテナーのほうは、コードオーナーのほうは、やっぱり実力を見に行くというところはあるし、
それは最終的なコードをメンテナンスしていかなきゃいけないのはメンテナーのほうなので、それは仕方ないと思います。
そうですね。だから逆にそういうこれまでの信頼がある分、有利だなっていうふうに僕自身思う部分もあるし、逆にじゃあこれからそういう信頼がない人とか、これまでに実績がない人が実績を積み上げるのが結構難しくなってきてるんじゃないかなっていうのはちょっと感じていて。
ただ最近、僕がOSSに来たプルリクエストをちょっとしばらく放置しちゃってたんですけど、そしたら僕の知り合い付でこのプルリクエスト見てくれないみたいなのが来て、これも結局信頼の話になっちゃうんですけど、その上で見て結構よかったからちゃんとマージしたみたいなことがあって、
その方はOSSコントリビュート初めてだったのですごく喜んでましたみたいな、そういったことを教えてくださって、そういう初めてのコントリビュート後押しできてよかったなって思ったんですけど、やっぱりそういったところにも結構ちゃんと自覚的に他人の人の信頼とかそういったものを引き上げていくことをやらないと、そういう既得権益者たちだけが得をするモデルになっちゃうなっていうのを思ったりするんですよね。
おだしょー わかります、本当にそうですね。
たしかにな、そういうOSSが、難しいですね。絶対使わないと、そのクリエイティビティ生産性の部分で差をつけられちゃうし、嘘ついて使った人の方が有利になるみたいな状況になるのが一番嫌なわけじゃないですか。
縛れば縛るほど実はそういったことが起きやすくなってしまうので、そうならないようにしたいなっていうのは思いますよね。なんかそのあたりって、今回持ってきてくださったエントリーの話でもそうですし、なんか思ってることとかってありますか。
結構大変になっちゃったなと思ってて、なんか下駄を吐けるようになってしまったので、その人の問題解決能力というか問題の認識能力とそれに対する解決の筋の良さみたいなものっていうのを測りがたくなっちゃったので、
今はなのでその信頼が得にくい時代になってしまったなと思っていて、ただこれ過渡期かもしれない、わかんないですよね。今はなので人間側が見抜けないので、これもうわからんみたいな感じになっちゃってるところはあると思いますし、
さっきの人捨てにコントリビューション、初めてコントリビューションする人の後押しをできたっていうのはいい話だなと思ってて、やっぱりみんな一番最初はコントリビューターとしては初めてだと思いますし、わからないところも結構あると思うんですよね。
そういうのをもっと仕組みが支援してくれればいいんですよね。なんかGitHubとかがこの人のコントリビューション初めてですみたいなのをもう少しマークつけてもらうとか、なんかその背景となるレビューする側の人に何かそういったメタデータみたいなのがもうちょっと渡るようになったり、
今後のOSSとAIの関係
あるいはこのプルリクエストがどのくらいAIが書いたらしき差分であるかどうかっていうのはもう少し判断できるようになったりすると、もう少し判断しやすくなるかなとは思います。
最近で言えばそのドキュメントに関して、ドキュメントをAIが書いたかどうかって、なんだかんだ言って見抜けるようになってきてるじゃないですか。なんかマークダウンを書かせてるんだけど、マークダウンの箇条書きのところが太文字になってたりとか、あるいは絵文字が使われてたりすると、これAIが書いたなってなんかわかっちゃうみたいなところがあると思うんですよね。
で、わかっちゃうと、じゃあAIにアシストされたっていう前提でこのサーブ見てみようとか、そういう感じにもなるとは思うんですよね。
人間が書いてきたものか、AIが書いてきたものかっていうのの見分けがつかないからこそ偽人暗記になっちゃってるのが今の状況で、これが別にAIが書くのが悪いのではなくて、
AIが書いてきてるんだったらそれを前提としたレビューをすればいいし、人間が書いてきたんだったらそれを前提としたレビューをすればいいので、今、過渡期としての問題はその見分けがつきにくいからコストがかかってしまうっていうのが問題で、
それによってその信頼関係も生じにくくなっちゃってるっていうのがやっぱり、今現在起きてる問題だなと思いますし、これもうちょっとしたらだから状況改善するかもしれないし、改善しないかもしれないですけど、ちょっとこの辺また見守っていくしかないですねっていうのがあると思います。
人間はどうせ慣れていくだろうから、それはどう変化していくのか楽しみに見守り続けるのがいいのかなっていうのは思いますね。ただ、OSSの信頼モデルが崩れてきてるっていうのは、もともとAIの前から悪意が入り込むみたいなサプラチェーンアタックとかそういうのが起きてるみたいなのがあると思ってて、そこも絡めるとやっぱりより難しい話になるなと思いますし、
やっぱりそうすると逆にその初めてのコントリビューションの人とかをまず疑うところから見始めてしまうみたいなのはあったりしますよね。
ありますね。そうですよね。だからサプラチェーンアタックとかって、どうやって信頼を得てコミットビットを得るかみたいなゲームになっていた時期ありますよね。
なんかずっと細かいバグフィックスとか、ドキュメンテーションの修正とか、イシューの取り味とかをずっとやってコツコツやってて、信頼を得てコミットビットを得て、ある時、
フォールを仕込むみたいなのがあったりすると、これ人間の側には防御不可能だよねみたいな感じの事件いくつかありましたよね。だから確かにおっしゃるとおりで、AIが出てくる前からこの信頼の崩壊みたいのは始まってましたね、そうですね。
そうなんですよね。だからここやっぱ難しいし、本当にもともと僕の考えからすると、ある意味勝ち取った信頼を無にするようなことってキャリアの終わりを示すからそんなことやらないでしょうって思ってたけど、やる人がいるからどうすればいいのかなっていうのはやっぱ思っちゃいますよね。
でもこういう、そうだな、確かにOSSじゃないや、AI使ってる、どこに使ってるかどうかみたいなところの透明性の担保みたいなの結構大事な気がしていて、それこそ僕も最近採用の話とかでAIをどう使うかみたいな話もあったんですけど、
AIでスカウトを蘇生乱造するのは絶対ダメだし、結構AIをどこに使ってるかみたいなところをちゃんと表明していくことで、多分候補者からの信頼を勝ち取れるんじゃないかみたいなところはあるので、やっぱどこでどう使ってますみたいな透明性をやっぱ示していくことは大事なんだろうなっていうのを思いました。
じゃあ前半はそんなとこですかね。じゃあ前半は一旦これぐらいで区切ります。ありがとうございます。
ありがとうございました。
