00:00
今回は、ISUCON2026で優勝された川崎さんにお越しいただいて、ちょっと緊急で収録しているんですけど、川崎さん、よろしくお願いします。
よろしくお願いします。
ありがとうございます。まず簡単に自己紹介の方、よろしいでしょうか。
はい、川崎と申します。インターネット上では、kawasyみたいなIDで活動していることが多いです。
今、人間一人の会社でタイピングベースという、ISUCONのチーム名でもあるんですけど、会社をやっていて、
いろいろ個人的な開発や実験をしたり、スタートアップのソフトウェア開発の経営課題を解決するというのをお手伝いをしています。よろしくお願いします。
よろしくお願いします。ありがとうございます。
今回、ちょっと緊急で収録回しているわけなんですけど、大前提ですね、11月2日に深堀FMさんの方で公開された川崎さんの回のエピソード142回目ですかね。
そちらも聞いていただくと、今回のこのお話の解像度が上がるかなと思うので、ぜひ深堀.FMさんの方もお聞きください。
概要欄の方にURL貼るかなと思います。
大体、ざっくり川崎さんがISCO2026でやられたことっていうのは、ざっくり深堀.FMさんの方でも話されているかなとは思うので、
こちらのやるよ図のOSSの方ではですね、より具体的というか、川崎さんの考え方みたいなところを聞いていければなと思っておりますので、今回よろしくお願いします。
お願いします。
まずなんですけど、一番最初にお聞きしたいところからなんですけど、今回のISCOで最初からAIエージェントを自立的に動かすみたいなことを想定して準備されていたのか、それとも途中で方針が変わっていった感じ
なのかっていったら、どっちだったりしますかね。
これはですね、完全自立ありきでですね、まだ準備編のブログを出してないんで、そこの辺ちょっと書こうかなと思ってるんですけど、
土曜日はいつも未就学時の子どもがいるもので、子どもを習いごとに連れて行ったりするというスケジュールになっているので、それはいつも通りやるという前提があったので、完全自立。
AI利用可能っていうのがレギュレーションに書いてあったっていうのを、支援先のスラッグで見かけて、それなら参加できる可能性があるということで作り始めて、うまく動きそうだったので、そのまま最後まで作り切
ったっていう形ですね。
なのでそう、すみません続けちゃうと、今回たまたま運が良くて優勝もできたんですけど、一番重視してたのは止まらずに最後まで自立的に動くっていうところでしたね。細かい工夫が実はいろいろされてしています。
03:00
じゃあ一番最初からもう念頭に置いてたのは自立的に動かして、なおかつ8時間ぐらいですかね、競技時間。
そうですね、朝10時から夕方6時まで。
この8時間どれだけ止まらないかというか、もう絶対に止めないで動き続けるみたいなところを一番重視されてた。
そうですね。
すごい、じゃあ特に途中で方針が変わったとかはないんですね。
そうですね、自立っていう意味では、それは初めからテーマだったので変わってなくて、中のエージェントの作り方、マルチエージェント構成するのかどうかとか、サブエージェントをどうするのかとか、そういう中身は結
構変わっていて、最終的に9月のおしまいに1回全部捨ててるんですよ。
もう真っ新な時間。
3ヶ月あるので。もちろんその場での実験結果を踏まえて新しく作ってるんで、何の役にも立ってないわけではないし、実験の基盤みたいなのもそのまま使ってるんで、蓄積はあるんですけど、当日動かしたエージェントの
ハーネス自体はほぼ捨ててますね。
すごい。当初はアルファエボルブですかね、再実装とか、あと独自のエージェントの方もすでに開発されていたって感じなんですかね。
これはですね、Twitterに書いたやつ、Xに書いたやつだと思うんですけど、これは構想レベルで最終的にはこの辺をやることになるかなと思いながら、序盤を進めていってたんですよね。
ちょっとだけ解説すると、アルファエボルブってディープマインドが2025年に出した論文だと思うんですけど、すごく正確なことを今バッと空で言えないので、興味のある方は調べていただければいいと思うんです
けど、
Googleの中の基盤の改善だったり、行列計算のアルゴリズムの改善で新しいの見つけるとかに役に立ってるんですけど、進化型の、説明が難しいな、探索をやるやり方ですかね。
評価関数で機械的に採点できるやつで使う、みたいな情報ですね。
1個のやつを逐次的に改善し続けるんじゃなくて、遺伝的アルゴリズムとか知ってる人はそれをイメージすると近いと思うんですけど、
複数のバリエーションをノードをいっぱい持っていって、ちょっとずつ進化させたやつをバラバラに評価しながら大量に並列で回してやっていくみたいな、すごく概念的なそういうコンセプトですね。
なので、当初一番最初に想定していたのは、スコームを普通に解くと極素最適化されて、逐次的に山登りしていくと極素最適に陥って、一番いいところに行かないんじゃないか、隣の山に登れないんじゃないか、みたいな
のを少し想定していたので、こういうアフローチがいいかな、みたいな話は思ってたんですが、
06:00
やった結果、たぶん途中までいろいろ実験した結果、この方針は良くないだろうということで、結局取らなかった、みたいな感じですね。
最終的には違う方法に落ち着いたという話ですかね。
そうですね、そうです。
一番最初の想定は、一つの問題にちょっと執着しすぎてしまうんじゃないかっていう懸念があったってことですかね、一番最初。
一つの山に登りきったら、他の山に登れないんじゃないかっていうような懸念点に関しては。
AとBっていう点を取ると一定良くなるんだけど、実はそのAもBもやらなくて全然違うCっていう点を取った方がスコアが上がるっていう。
なるほど。
だからそのAとBをやってると、Cをやっても点がちょっとやっても下がっちゃうから、隣の山に行けないみたいな状況になる。
理解しました。同じ問題の中でいろんな手段があるところで、最初にAとBっていう方法を選んでしまったら、そこを突き進むしかないみたいな動き方をしちゃうんじゃないかという。
ちょっとずつ最適化していった時に、もっと大きいスコアの高い方の山に登れないっていうことが起き得るという想定をしていたので、こういうのを計算して考えていました。
そういう懸念があったが、でも最終的にはクロードコードのベースに落ち着いたかなって。
そうですね。クロードコードVS独自コーディングエージェントみたいな話はまた別の話で、多少安全に動かしたいので、安全にかつ自律的に動かしたいってなった時に、
クロードコードが使えない可能性もあると思ったんですよね、いろんな権限設定の仕組みなりなりで。
なんですけど、とはいえクロードコードはめちゃくちゃよくできてるので、当然普段使いもしてますし。
まずはクロードコードで一通りやってみて、ダメだったら既存のオープンソースのコーディングエージェントベースにするか、
アンソロピックもオープンAIもそれぞれエージェントSDK出してると思うんですけど、それベースで作り直すか、みたいなのは一応フォールバックフランというか、
案として思ってたんですけど、これもクロードコードうまく動いたので、そっちの方にはいかなくて済んだっていう感じですね。
ちなみに何が決め手になりました?もうこれで良さそうって思ったって感じですか?
簡単に言うとそうですね。どっちもさっきのいろんな進化計算型の探索をやらなかったみたいなのと一緒なんですけど、
どっちも結局評価をずっとやってて、評価している過程でちゃんと最後まで走り切るし、
スコアも多分この挙動を見ている限りこっちのやり方をしても伸びないだろうっていう判断をしたのでやらなかったっていう。
全部実験の結果ですね。実験の結果をずっと見続けていたっていうところに由来する判断ですね。
09:00
検証していったら、これクロードコードベースでも全然いいんじゃないかというところに落ち着いたっていうのが結果なの?
そうです。作るの少ない方がいい。
そうですね。任せられるところは任せちゃった方がいいですもんね。もちろん自作せずに。
学習効果みたいな話で言うと、もし次回やることがあるんだったら面白いと思うのでゼロベースで作ってみるっていうのはコーディングエージェント、
イスコントックコーディングエージェント作るのは、今回はクロードコードのユーザーハーネスレイヤーしかいじってないので、
もちろんそれは自由度十分高いんですけど、もう1個下のちゃんとコーディングエージェントのハーネスのレイヤーから作るっていうのはもしかしたら面白いかもしれない。
コーディングエージェントの気持ちを理解するのに役に立つ可能性は結構高いと思っているので、
次回やることがあればそういうのをやるかもしれないなと思っています。
個人の学習的な意味合いで結構いう様相だよねっていうのと、あとはもしかしたらそういった形でコーディングエージェントのハーネス部分を自作すると、
こういったところがよりスコア的に伸びるんじゃないかみたいな目論みとかって現状あったりします?
なんか今回結果的には優勝できてかなりうまく動いてたので、あんまり不満はないんですけど、
それも現状のクロードコードのハーネスプラスモデルの組み合わせプラス僕が上に乗せたユーザーハーネスの組み合わせでたまたまそうだったみたいな話もあると思っていて、
1年後、彼に毎年あるかどうかわからないですけど1年後にもう一回開催されるとした時に、その時の最新のモデルとクロードコードのハーネスとの組み合わせ、
あるいはCodeXとOpenAIの最新のモデルとの組み合わせなどの中で共同化がうまくいかないんだったらやる余地はありますよね。
その時最適かどうかで考えた方がいいよねっていう。
特にいいスコアを出すっていう観点で言うので。
そうですよね、手段はちゃんと選んで、それを検証していくっていうところが一番重要なのかなっていうところですかね。
そうですね、おっしゃる通りかなと思っていて、途中ですごい作ってきたやつ全部捨てたのを評価した結果、何もしない方が良かったっていう。
何もしないはちょっと言い過ぎなんですけど、限りなくスクした方が良かったという結論に至ったっていうところがあります。
検証用のツールみたいなところも詳しく聞いてみたいなと思うんですけど、
一番最初はベンチマークに合わせてCPUとかメモリとか各種AIを測る用のツールは用意されてたって感じなんですかね。
そうですね、たぶんここはまだ全然どこでも話してない。
片栗さんだけに優勝した日の飲み会で、子供が寝てから打ち上げしましょうって言って来てくれたのは片栗さんだけだったんですけど、
二人だったんで、がっつり何をしたかを結構お話しさせていただいたんですけど、そこでしか話してない、本邦初公開の話かもしれない。
12:08
最初に作っていたバージョンのユーザーハーネスの中はコマンドがいっぱい用意されていたんですよ。
メイクファイルにいっぱいコマンドが並んでて、そこからさらにシルスクリプトなりパイソンのスクリプトなりいっぱい立ち上げます、みたいな感じになってました。
デプロイのコマンドがまずは、メイクデプロイみたいなやつがあるわけですよね。
それを実行するとその前後で自動的に全ホストのいろんなメトリクスを取ってくれるような仕込んでありました。
ある種、汎用という言い方が正しいのかわからないんですけど、そこ全部用意してあったんですよね。
原理としてはスラプロクっていうバーチャルファイルシステムあると思うんですけど、
トップとかPSとかそれ系のコマンドも中身としてはあそこ見てるはずなんですけど、
スラプロクの中をいろいろ見て、エージェント向けに10秒単位のサンプリングと1秒単位のサンプリングをいろいろ見た結果をさまって、
テキストで自動的にデプロイが終わってベンチマークを、デプロイとベンチマークがそもそもセットなんだ、
デプロイしてベンチマークして終わったらその結果を返してくれる、
計測した結果、観測した結果も返してくれるみたいなツール群になってたんですよね。
仮説としてはその人間が使う、その時のですよ、その時の仮説としては、
だからいろんな人間向けのオブザバビリティツール、外にいろいろエピロームで流すとか、
ネットデータ入れるとか、ネットデータって今でも流行ってますかね、片杉さんが使ってる人は。
ネットデータ、昔自分も使ってましたけど、今使ってる人どれくらいいるんですか。
あんまりいないですか。10年前は結構いた気がするんですけど、ちょっと最近の事情を知らない。
元々原始的な基本的なツールを使うっていう人もいろいろいたと思うんですけど、
人間が使う前提のツールじゃない方がトークン効率がきっと良いものが作れて、
かつISCONの解像度で1分間の中の動きを見れるようなもの、
だいたい1マークで60秒から70秒みたいな時間が走るので、そういうのがあるときっと良いだろうという予想のもとを組んだんですよね。
組んだというか組んでもらったっていう表現が正しいですけど。
事前にいろんなツール、人間がよく使うようなツールをツールとしてちゃんとクロードコードとか、
その時はクロードコードじゃなかったかもしれないですけど、AIに渡して組んでいたっていう話なんですけど、
でもそれがなくても良かったっていうのはどこら辺で気づかれたんですか?
15:08
ちょっと順序前後しちゃうかもしれないんですけど、
そもそもその時作ったツールはあらゆるメトリクスを取ってるんですよ。
CPU、メモリ、ディスク、Io、ネットワーク、ファイルディスクリプターの数、
昔の問題とかだとファイルディスクリプターが枯渇してなんとかみたいな話とかもあったので。
あとはそれぞれのプロセスですよね。
データベースだったり、AginXだったり、アプリケーションプロセスだったり、
いろいろ取ってくるっていう、どんな問題が来てもある程度対応できるようだし、
あらゆるメトリクスを同時に取るみたいなツールになってたんですけど、
それがダメだって直接思ったわけじゃなくて、
他のものもいろいろまとめて作り込んだハーネスを捨てたタイミング、
正確に言えばいろんな構成を試す中の一環で、
何にもないやつをちょっと動かしてみた時に、
ちょうど終わるタイミングで見ていたら、
その時解いていたいくつかの問題で一番作り込んでいたハーネスよりも
ユーザーハーネスのスコアよりも高いベストスコアを出すケースがあった。
それをよく見ていると、
AdHocに毎回測定ツールを作ってるんですよね、測定スクリプト。
それはその時に一番知りたい情報を取れるようにやっぱり取っていて、
すごい問題が進んでいくと、
序盤はだいたいCPU立足になって、
DBのCPUが詰まってますとか、
アプリケーションのCPUがめっちゃ詰まってますとか、
順番に移してポコポコ叩いていけばいいんですけど、
違うところに移っていったりとか、
アクセスログの全体の統計だけ見てもわからないんだけど、
どういう入力が送られてくるのか、
みたいなところまで含めて、
あとどういうユーザー信頼度でどのエンドポイントがどの順番に叩かれるのか、
みたいなところまで考慮したりとか、
今回の問題だったら、
グローバルなSNSっていう設定の問題だったので、
アジアとヨーロッパとアメリカっていう3マシンがあったんですけど、
それぞれのリージョンのユーザー数の増加がどういうふうに増えていくのか、
10秒1日っていう設定で、
毎日ちょっとずつユーザーが増えていくっていうアプリケーションだったんですよね、
前の日の状況に加えて。
それが増えるのが何に依存してどう増えるんだっけ、
みたいなのを実際のデータを見ながら、
DBのデータも叩きながら測定していくと、
良い最適化ができるっていう構造だったので、
初めに汎用的なのやって、
それだけを使ってくださいみたいにすると、
別に悪くなくって、
90点ぐらいのスコアは全然いくんですけど、
最後の最後のスコア、
18:00
思いもよらないような伸ばし方みたいなのはしてくれなかった、
ということに気づいて、
これもいらないんだと。
これぐらい意図がはっきりしている環境、問題を解くときは、
アドホックなスクリプトを毎回エジェントに勝手に書かせて、
エジェントが勝手にやる方が、
より深くアプリケーション、サーバーの状況、
アプリケーションの状況、データベースの状況を全部知れて、
良い最適化につながるっていうことが分かったっていう感じですね。
事前に用意していたツールで、
ある程度のこと、全般的に知れるみたいなツールを用意していたが、
本当に必要だったのは、
その時々で見るべきところを深く見るツールだったみたいなお話ですかね。
自律的に考えてもらって、勝手にやってもらった方が良かったっていう話ですね。
これもでも基盤モデル、
プラスコーディングエジェントのハーネスの進化によるんだとは思っていて、
1年前だったら多分、
汎用的なツールを渡してあげた方が良かった可能性が高いなと。
ちょっと検証してないので本当に分からないですけどね。
あれですよね、AdHocに作るコストと、
汎用ツールを渡して使ってもらうコストで、
今回というか現時点においては、
特化したツールをAdHocに作ってもらうコストの方が安いし、
なおかつ精度も出たという。
そうですね、性能が良かったということですね。
ちなみに速さ的に言うとどうなんですかね。
特化ツールをAdHocに作るということも、
コストはかかってしまうわけじゃないですか。
そこ込みでも全然作っていった方が良さそうだなって、
事前の検証でなった形ですかね。
そうですね、ツールを書くタイミング自体のコスト時間は、
トークンコストとかかる時間はちゃんと見てないんですけど、
他の要素もいっぱいあるんですけど、
トータルの8時間の間のスコアの上がり方だけで話すと、
一番作り込んだやつ、
このツールのせいだけではないと思うんですけど、
かなりなだらかにゆっくり上がっていくんですよね。
最初の1時間とかベンチマーク、
最初の状態で1回回したぐらいで終わっちゃうんですよ。
用意したツールを渡しているバージョンのスタイル。
マニュアルをしっかり読んだり、
サーバーのソースコードを丁寧に、
私が書いた手順をなぞって手元に持ってきて、
ソースコードだけじゃなくて、
このサーバーのいろんな設定ファイルとかも含めて持ってきて、
デプロイのスクリプトも事前に用意してあったので、
プレイスホルダーを埋めて、
ベンチマークを回すスクリプト、
プレイライトのブラウザのセッションをいじって、
ベンチマークをブラウザから起動する、
21:01
みたいなスクリプトの穴埋め式になっているんで、
穴埋めのところを埋めるとか、
やって再起動の実験を1回して、
1時間くらいかかって何もしないみたいな。
そういう手順を一切書かずに、
勝手にやってもらうと、
今回1時間10分くらいで、
最終スコア60万点だったんだけど、
50万点くらいに達しているんですよね。
最初の1時間くらいで、
すごかったですね。
正確な数字を思い出すと、
当日何をしていたかというフログが、
ちょうどおとといぐらいに出したので、
50万点に達したのが、
11時22分。
最初の2時間くらいですかね。
ほぼ最終スコアに近いところまでいってるっていう感じかな。
もうその時点で、
最終スコアの2位の方には勝ってますよね。
そうかもしれない。
2位の方がたぶん47万とかだった気がした。
そうですね、そういうことになりますね。
ちょっと途中の経過をあまり、
側にいたので見てなかったんで、
わかんないんですけど。
実は最初の1時間半くらいで、
ほぼほぼ固まってたみたいな。
そうなんですよね。
みたいなことも考えると、
ツール作る、事前用意で穴埋めするVS、
毎回作るの単純な比較ではなくて、
全体トータルですけど、
勝手にやらせた方が早い。
今お話聞いていてすごく思ったのが、
人間と同じだなと思っちゃいましたね。
事前にこういうツールを使って、
こういうワークフローで、
この手順でやってくださいねっていうのは、
初心者の方、初心者のエンジニアの方にお願いする上では、
かなり効果的かなと思うんですけど、
もう既に手だれのシニアのエンジニアの方に、
それでお願いするのって逆に時間かかっちゃう、
みたいなのあるじゃないですか。
それと全く同じ構造してるなと思っちゃいましたね。
まあそうなのかもしれないですね。
その辺が1年前のモデルだったらこうだったんじゃないかって言ってる僕の理由と、
一緒かもしれない。
そうですね、例えば黒時計のモデルだったら、
ソネットとか廃棄とかで一回やってみると、
その辺の差はもう一回はっきりするかもしれないですね。
実験の時はやってたんですけど、
ドキドキ、ソネット、
ドキドキっていうのは数回かな。
あんまりやる意義を感じなかったので。
じゃあ本当にもうシニアの方、
シニアのエンジニアのモデルであろう、
オーパス5.5今であれば、
24:04
準備するというよりかは、
できる限り任せて、
その任せる環境作りっていうのに固執した方が、
精度はいいというか、
速く回るし精度もいいしみたいなところがありそうですか。
少なくとも今回は今の性能だと。
ありがとうございます。
すごい人間にも通ずるところだなっていうところが
わかったんですけど、ここからは競技中のお話を
ちょっとだけお聞きできればなと思うんですけど、
競技中はずっと8時間ぐらい
クロードコードが動き続けて
色々作業して、さっきの話だったら1時間半ぐらいで
ほぼ最終スコアぐらいのところまで行った
っていうようなことなんですけど、
この1時間半とかで最終スコアまで行く
みたいなのって想定してました、最初。
でも序盤に上がるっていうのは、
評価実験してても
だいたい最初の4時間ぐらいで上がりきっちゃうので、
それでいうとそんなに
想定外ではなかったかなとは思ってますね。
いつもだいたい同じような
グラフの動き推移ではあります。
じゃあ予想通りだなみたいな感じだったんですか?
そうですね、問題サイズは当然これまでの過去問と比べたら
大きくなるっていうことはもちろん
想定していたので、
多少時間かかるかなと思ったりもしましたけど、
でもほぼ想定通りというか、
自分で対策用に1個問題作ったんですよ、
評価セットの中に1個問題入れたんですよね。
そういうのができるのがAI時代の良いところなんですけど、
過去問だけだと問題のデータ汚染みたいなのがあって、
解き方はある程度知ってたりもするので、
完全に基盤モデルが知らない問題を1個作ってみたんですけど、
当然、
作文される側も
参加者がAIエージェントで参加してくるっていうことは
想定通りだと思うんですけど、
まず単純に問題の量、サイズみたいなのが
でかくするっていうのはあるだろうなと思ってたので、
想定して作った問題は
コードの量も倍ぐらいだし、
データベースのテーブル数も倍ぐらいのサイズがあります、
みたいなやつにしたんですよね。
他にもいろいろ工夫はしたんですけど、
それでやっても大して結論が変わらなかったので、
既存の過去問とグラフの推理みたいなところは
あんまり問題の大きさが10倍になったら
ちょっとまたわかんない、あるいは
昔の問題になったような複数アプリケーションに
細かくめちゃくちゃ分割されてましたみたいなケースだったら
ちょっとわかんないですけど、
いってちょっと大きくしたぐらいじゃ
全然あんまり変わらない、
27:00
全部読み切っちゃうんだなってこと自体は
事前にわかってましたね。
人間も産化するので、
人間が全く産化できない難易度の問題にも
できないじゃないですか、やっぱり出題する。
そうですね、確かに。
本当に人間が不可能なような問題にもならないとも思っていたので、
あんまりそこは気にしていなかったです。
なるほど。ちょっと作文者側というか
イスコン運営側、すごく難しくなりそうだなという気は
今回はむちゃくちゃ難しかったと思うので、
本当に尊敬の念しかないです。
ちゃんと競技として成り立って、
素晴らしいですよね。
最悪破綻する可能性はありますか?
あったかもと思いますけどね、ちゃんと本当に。
実は自分が作ってプライベートイスっていう
イスコンの練習用のやつあるんですけど、
新卒研修とかで使ってるんですけど、
AIが完全に学習しちゃってるんですよね、プライベートイスのソースコード。
なのでもう全部一瞬で最適化できちゃうので、
やるともう数時間経つと
上位陣がもう団子になっちゃって
もう差がつかなくなっちゃうんですよね。
なのでイスコン運営の人たちとも話してるんですけど、
やっぱりそうなるのが一番怖いっていう、
上位陣が団子になってもう全然差がつかなくなるっていうのが
過去問だとすでにそうなることが分かってたので、
これどうしようかみたいな感じでありましたね。
今回に関しては川崎さんがトップ走られて、
ただそれに追従する団子状態にはならなかったっていう形ですもんね、
結果的には。
結果的には今回そうですね。
だから良かったって感じですけど、
ちょっと次回以降どうなるかは分かんないですがっていうのがありますね。
ちょっと話戻して競技中の話できればなと思うんですけど、
クロードコードに8時間走らせているときに
何か確認できるように
お子さんと土曜日普通に過ごされるっていう
大前提のルールがあったかなと思うんですけど川崎さんの。
その中で何か準備していたこととかあったりするんですかね、
何か仕組みみたいな、
知らせる仕組みみたいなところで。
そういう話で言うと、
本当に競技続行不可能になったら人間に
エスカレーションする、通知するっていう仕組み、
簡単なツールだけは一応用意しておいて、
スラックで呼び出してくれる通知情報を入れてくれる。
ただ別に返答を待つわけじゃなくて通知だけする
っていうツールは一応用意して
何かあったら使うっていうのが
インストラクションに入れてました。
評価回してたときもたまに
競技用のホストが
アウトプンメモリーとかで一切SSHで入れなくなる
みたいなタイミングがあって
そういうときが起きるので
用意しておいたっていう感じですね。
競技ホストに入れなくなる問題に関して言うと
秘室インスタンスを外からリブートできるような権限を
30:02
エージェントに渡してしまったので
その後起きても勝手に自分で直してくれるようになったんで
あんまり起きなかったですけど
他のケースだと、これ本番は起きてないんですけど
土曜日だから可能性は低いかなと思いつつ
クロードの障害が起きる可能性があって
そこが一番ボトルネックっていうか
重要な部分ですよね。
止まる可能性で言うと
土曜日はあんまり不安定になることはないですけど
実際評価回してたタイミングとかだと
夜回したりもするんで
ピークタイムなのでアメリカ時間とかで
ちょっと不安定になったりして
止まっている協議をエージェントが止まっている
みたいなことはやっぱりあったので
自動で修復するようにも組んだし
何かあったら通知するようにはしてましたね
現実的には通知が来てもきっと気づいてなかったなとは思ってます
一番最初は電話かかってくるようにしようかなって思ったんですけど
電話かかってきても出たくないなって思ったんで
普通は使わなかったりした
スラックで通知ぐらいが適切かなと
一応通知できるように
エージェント君が悲しくならないように
エスカレーションできるようにはしておいたんですけど
ちなみに当日その通知あったんですか?
なかったです
基本的にはこれまでもそんなに起きたことはなくて
一日インスタンスが
ハングしちゃったみたいなケースが
1回と
さっき言ったクラウドAPIが1回というのと
あとあれか
最初の競技マシンの立て方
本番はクラウドフォーメーションで使って立てるというやり方なんですけど
最初の方に作ってた評価環境は
クラウドフォーメーションで作るんじゃなくて
前から全部ベンチマーク用のホストとポータル用のホストと
競技用のホストを全部事前に立てた状態で
ホストのIPを競技エージェントに渡す
仕組みになってたんですよね
その過程でクラウドフォーメーションにやる
仕組みに変えた後に競技用ホストが上手く立ち上がりません
みたいなことが起きて
通知が来るっていうのは何回かあったかな
そうEIPの上限に引っかかったみたいなやつか
分けてるAWSアカウントも
リスクオンエージェント用に分けて作ったAWSアカウントがあるんですけど
そこの上限が厳しくて
クォーターに引っかかって
評価実験を並列にいっぱい回そうとすると
引っかかってしまったみたいな感じだったと思います
基本的には今の話だと
外部環境での制限だったりとか
そういった失敗で通知が来ることは今までもあったけど
ただ当日はそういう問題が起きなかった
そうですね無事
33:01
お子さんと普段土曜日過ごしている中で
クロードコードを外から監視するみたいなのは
実際あったんですか
リモートコントロールをオンにして
起動するっていうのができるので
今日見ようと思えば見れて
10時2回くらいスクリーンショット撮ったんですよね
5分と15分くらいの
うのしながら撮ってたんですけど
一応起動したこと自体は確かめてます
式同士でコストが立ち上がって
やり始めたっていうところは見てたし
原理的には介入しようと思えばできる
っていう状況にはしてましたけど
その後は外に出ちゃったので
あまり見る余裕はなかったです
実際介入はしなかったってことですね
競技エージェントへの一番最初のプロンプトも
競技エージェントを起動するシェルスクリプトが
送るようになってるんで
一文字も競技エージェントのセッション自体には書いてないですね
リモートコントロールで見たっていうのも
一番最初ちゃんと動き始めたかなっていう確認ぐらいで
その後は特に見てない
まだ家にいたので何かあったら一応なんとかできると思って
一応ちらっと見てみたっていう
じゃあその後は普通に子供と過ごして
特にスマートフォンからリモートコントロール
見ることもなくって感じですね
無事目標がそれだったので達成できてよかったです
スコアはお昼食べた後にブログにも書いたんですけど
一回見る時間があったんで見たら
そのタイミングで1時半ぐらいだったかな
1時だったのでおおっと思った記憶があります
結構いってるなみたいな
想定どおりでしたそれはちなみに
それはそんなに想定どおりではなくて
みんなある程度AI使ってくるのはわかってます
当然使ってくるだろうし
自立型も
10組ぐらいはいるかなっていう想定だったので
結構近い感じでパソコンの前にはいたけど
ほぼほぼ自立でやってたみたいな人も
参加記録見ると何組かいらっしゃる感じがするので
あんまり差はつかないんじゃないかな
っていう風に思ってたんで
ちょっとそれは逆に言うと意外って言った方が
正しい感想かもしれないですね
想定外だったというかどこで差はついたんだろうな
みたいなところですかね
最終的なユーザーハーネス
そんなにすごいいっぱい工夫してないというか
工夫してないはいい過ぎなんですけど
あんまり複雑な構成にしてないんですよね
なんでこれにたどり着く人はいっぱいいるんじゃないか
と思ってたんですよ
途中準備してた段階で10月の真ん中辺とかは
なんで結構最後は運ゲーになるんじゃないかな
っていう気が
36:00
わらつきで上振れた人が勝つゲームになるんじゃないかな
って思ってました
最終サイコロフルみたいな感じで
ランダムに試行していったら
一番いいところ宝箱にありつけた人が
勝つんじゃないか
なんですけど参加記録読む限りだと
みんな複雑なマルチエージェント構成とかを
組んでしまっていて
自分もそういうの組んでたことがあるんで分かるんですけど
性能として最終的なことイスコンに関する性能としては
良くなかったんで
みんな頑張って作りすぎた説がちょっとあります
これあれですね
自律的に動かしていたチームで集まって
どういうユーザーハーネス作ってたのか
ちょっと検証したいですね
話し合いたいくらいですね
結果的に川崎さんはシンプルな方に
落ち着いたかなと思うんですけど
シンプルな方が強いねみたいな傾向が見られたら
完全にそういうことですよね
そうですね
全部見てないんでまだ分かんないんですけど
これどっちの可能性ももちろんあったと思うんですよね
後付けで競技の特性がこうだから
シンプルな方がいいよねみたいなもちろん
言えなくもないと思うんですけど
やってみないと分かんないので
これに関して言うとちゃんと評価をしたから
自分も気付けたっていう気もしています
やはり一番最初の準備時点で評価していって
それが結果的にシンプルな方が点数が高いって気付いて
じゃあこのぐらいのシンプル度にしておこうか
みたいなところが一番決め手だった
振り返るとそういう話になりますね
その判断基準あったりしますか川崎さんの中で
どのぐらいシンプルにしていいか
どこから作り込むかみたいなのあったり
今回言うと9月のおしまいに
家族旅行をしてたんで評価実験をいっぱい回してた時期があるんですよ
いろんな構成サブエージェントの使い方とかも
複数パターンあったりとか
クロードコードのセッションを3つとか4つとか立てて動くとか
コーデックスを呼び出してやるとかいろんなパターンがあって
やってた時にほぼほぼ
一番最初にやったのに近いんですけど
かなり薄いほぼ何にもしない
エージェントスキルとかもほぼ何にもない
エージェントスキルなんもないようなやつで走らせたら
良かったんですよね
最終スコアがどうだったか
思っても見ないようなスコアになったかどうかみたいな
それまで作ってたハーネスでも問題自体はほぼ解き切っていたと思っていたので
ここから先の世界があるとは思ってなかったみたいな
自作の問題も含めて7つレンジマークの評価セットに入れてたんですけど
この問題ここからさらに点が上がるんだみたいなのが分かって
39:02
それはたまたま上振れでもあったと思うんですけど
それを引いた時に
これだったら全部消した方がいいなって思って
消した中から本当に少しずつ慎重に追加していったっていう感じですね
ちょっとずつ新しく
それを追加する時も
序盤の手とかは本当に何も言わなくてよくって
最後の解き切った後とかに気づいたり気づかなかったりする
こればらつきを減らすっていう風に自分は言っているんですけど
終盤本当に最後終盤解き切って
ベンチマーク側が立足になった時
ベンチマーク側のCPUが立足になって並列度が限界になった時に
最後何をしてちょっと絞り出すかみたいな
になった時の手で思いつくやつと思いつかないやつがあって
微妙にスコアに差が出ることがあったので
そういうところを最後教える
毎回ばらつかないように気づけるようにしてあげるっていうのをやってました
何回も問題を回して今回は思いついた今回は思いつかなかった
これ入れといた方がいいっていうのをやるっていう感じでした
最初の初手だったりとかその次やることはもう任せきって
最後の最後ちょっとお掃除じゃないですけど
本当にやるべきことをちょっとだけ教えているみたいな
ユーザーハーネスを組んでるっていう
そういう理解で割と正しい気がしますね
もう本当に薄くてさらに
イスコンの競技性を鑑みて少しだけ最後の準備の準備というか
掃除部分というか最後のシナの部分だけ
用意してあげる方が結果的には良かったし
それが検証していったらそうなってた
そうなってた
ことが分かったっていうことですね現時点で
多分そのイスコンの最初の方って
CPU下げるとかスロークエリア無くすとか
一般的にやられる手法だと思うんですけど
最後の方にやるのってそのベンチマーカーの動き読んで
ちょっと変なことやるみたいな感じになってくるので
多分普通じゃないことやらないといけないんですよね
本当に競技性のところをやらないといけないから
そこはちょっと教えてあげた方がいいんだろうなと今思いましたね
まさにそういう話
一番最初の方は普通に一般的に
ウェブエンジニアがやるべきことインフルエンジニアがやるべきことをやっていて
最終残るのはイスコン特化のところだから
そこだけはクロードコードでさえも
ちょっと対応できない可能性があるので
そこだけ教えますよということですねルールとして
そこはそうですね気づく時もあるんで
全く全然やらないっていうわけじゃないけど
やったりやらなかったりするのはやっぱり
42:02
非決定的な挙動だなと思っていて
できる限りばらつきを減らせるように
実験を回したっていう感じですかね
できる限り決定論的にやりたかったってところですよね
ランダムにならないように
決定的には全然ならないんですけど
それでも少しでも埋められるように
ここまでで結構当日の動きだったりとか
準備の話聞けたかなと思うんですけど
片杉さんあったりしますか質問
当日の流れはだいぶ聞けたんじゃないですかね
大丈夫ですかね
ここからは難しい話になるなとは思いつつ
話していけたらなと思うんですけど
途中であったですね
汎用的なツールを一番最初作っていって
それをAIエージェントに任せて
そしたらスコアは上がるが
でも全てを任せきってしまったほうが良かった
AdHocにツールを作っていったほうが
結果的にスコアは上がったっていうようなところを
ちょっと見ていけたらなと思うんですけど
これって見方変えると
じゃあ今後汎用ツールである
OSSとして汎用ツール作って公開してっていうのが
いらなくなるんじゃないと思っちゃったんですね
この話聞いたら
全部もうAdHocに作れば良くないみたいな
世界線に到達してるのではと思っちゃったんですけど
そういう話していけたらなと思うんですけど
これってなんか今回ISCON特有の話だったりします?
って思ってますかね 田崎さん自身
これすごい難しい質問ですよね
でもまず事実だけで言うと
すでに存在しているコマンドラインツール
使ってもいるんですよね
TOPとかIOSTATとかMPSTAT NSTAT SSなどなど
普通に使っていたし
それを多分補足する形で
自分でも書くみたいな感じだったので
今回の実行結果 当日の実行結果を見る限り
全く何かが役に立たないみたいなことは全然ない
っていうのは少なくとも言えているし
実際この外側の全体の仕組みを作る上で
僕今ハーダーっていうターミナルマルチプレキサー
エージェント時代のTMAXみたいなやつがあって
それを使ってるんですけど
ハーダーのAPIがあって
うまいことできてるところもあるので
何ですかね
一定のビルディングブロック自体の価値はもちろんありますよね
それが昔からあるものだとエージェントが
昔からあったり
世の中に広く知られているやつは
使い方をよく知ってるので
エージェントがよく使ってくれているっていう話はあって
ハーダーとかは別に当然そんな知らないと思うので
45:01
ハーダーが自身がエージェントスキルを自前で
オープンソースとコードと一緒に配っているので
それが入っているから
エージェントの使い方わかってるみたいな
状態になってるんだと思っていて
その境目がどこにあるのかですよね
そうですね
なんかもっとプリミティブなものは
きっと組み合わせて使っていってくれるんでしょうね
これからでもプリミティブなもので
役に立つものがどのくらいあるんだっけみたいな話はまた別
あと新しいものはやっぱりちょっと覚えてもらえないから
さっき言ったようにドキュメントなりエージェントスキルなりを
今最近のメジャーOSSそういう流れになってますけどね
ドキュメントを一緒に配るっていう風になるんですかね
今の話だとあれですかね
小さいツール 汎用的な小さいツールに関しては
今後も使われるだろうし
基盤になってる部分なので
そういったところは今まで通り使われるんだろう
っていうところで
ただ今後そういうツールが
じゃああと領域としてどのくらい残されてるっけっていうのは
また別問題だよねっていうところはありますよね
あとあれだ何に最適化するのかっていう話もあると思ってて
いつかスコアに対して最適化すればいいので
ある種品質ですよね
でもそのシーンによっては
トークンコストを最適化したいシーンもあると思うし
開発の速度を最適化したいっていう
それぞれ若干トレードオフもあるし
その3つバランスいいところで
エージェントの
なんて言ったらいいんですかね
トークンマネジメント的なことをしていくんだと思うんですけど
単純なトークンコスト以上に
ベンチマークとかも
世の中に広まっているようなベンチマークも
この問題あたりのコストみたいなのを見たり
問題あたりのトークン数というより問題あたりのコストとか
コスト系のベンチマークを見てると思うんですけど
そういった観点になった時に
そうだからMCPサーバーよりCLIがいいみたいな
ちょっとこれどれくらい本当なのか
自分では検証してないんで分からないんですけど
そういう話とかもあったと思っていて
コーディングエージェントから使うならCLIの方がいいですみたいな
その路線はもちろんありますよね
良いCLIが
それはどういうものなのかは別として
あったとして
そっちの方がトークンコストは良いので
それは頑張って教える価値がある
頑張って作ってエージェントに使わせる価値があるみたいな
確かに今おっしゃられて
トークンコストの最適化なのか
それともどこに
リスコン特有だったらスコアに最適化するのかとか
そういう最適化部分によって
ツールの使い分けみたいなのは
全然あり得るなと思いましたね
トークンの最適化なんて
新しい分野じゃないですか完全に
今皆さん取り組んでやってると思います各社ね
ですよね
この2,3年で出てきたところだと思うんで
48:01
そういった意味での汎用ツールみたいな側面だったら
全然分野としてありそうなところとして
これも結局評価の話に戻ってくるんだと思うんですよね
雰囲気でCLI使って良くなったって言っても分かんないし
実際それぞれの皆さんが解いてる問題に対して
どうやって評価するんだっけっていう問題に戻ってきます
そうですねやっぱり人間がそれをどうジャッジするかですね
人間だしあとは何を基準に
それをチームとして受け入れるかどうかとか
そういったところなんですかね
あとちょっと違う点として
AdHocに作るっていうツールとかの場合
すごい短期的な目線かなと思うんですよね
その時だけ使えればいいみたいな
本当に使い捨てみたいな感じになるかなと思うんですけど
そうじゃなくて長期的な保守していかないといけない
サービスに対して使うっていう面だと
全然違うかなと思うんですよ目線が
そういった目線で川崎さん今回の件だったり
今までの経験から何かあったりしますかねここら辺で
めちゃくちゃ難しいこと聞いたけど分かってます
あとですね範囲が広いけど長期的なね
いやでも難しいですよね
最近これは個人プロダクト個人開発だからだけど
コードレビューもしてないんですよねほぼ
一応プルリクエスト経由してるけど
それはGitHubを使ってるからっていうだけで
そんなに見てない
人間の目のコードレビューはしていない
大きな方針は見るけど
もう全く見ない時もいっぱいあるっていう状況なので
それでも一定のものはできているなら
全体の設計モジュール設計だったり
細々としたリンターフォーマッターみたいなのを
当然整備してるとかあるからだけど
意外と大きな設計判断とかも
このライブラリをやれてこっちに変えましょうみたいなのって
エージェントスフォームで大量に作業させれば
一瞬で終わっちゃうから
長期的なプロダクトを作っていく上でも
全然もっと違うやり方
それこそソフトウェアファクトリーの
ライトなのかダークなのかみたいな議論で
皆さん各社実験されてるところなので
取り組まれてる皆さんの話も
自分も疑ってみたいなと思ってますけど
あまりやっぱり今回の結果を
一般的に話して当てはめていいかどうかは分からないですけど
あまり人間のワークフローを前提に
しなくていいなっていうのも思ってますけどね
今までの地続きじゃなくて
やっぱりAIエージェントに
最適化する話にしていった方がいいよねっていう
51:00
考え方ですね
AIネイティブって何なんだっけみたいな議論と
一緒だと思うんですけど
最初は多分人間がやってるプロセスの一部を
AIにやらせてみて
ちょっとずつ置き換えて効率化していきました
みたいな話からスタートすると思うんですけど
その延長性上に一番最適なものないって思っていて
全部AIに前提で一回やらせてみて
問題があるところを修正していくっていうアプローチの方が
今回良かったし
実際普段のソフトウェアプロダクトの開発でも
そうなんだろうというふうには自分は思っています
シンプルに任せきった方がいいよねっていう話ですね
それで問題があるところをちゃんと潰していくっていう
アプローチの方がいいかなっていう
ボトムアップにちょっとずつ変えていって
ちょっとずつAIに任せてやっていくって言っても
たどり着けない場所がある
ブレーキスルーしない
最大の性能が出せないというふうに思っていて
それがだから今回の途中で2ヶ月作って
途中で捨てたやつバージョンと
その後に作ったすごい薄いやつとの差で
イスコンのエージェントもそうで
イスコンも2ヶ月作って捨てたやつとか
最初の序盤4フェーズに分かれていて
初動のフェーズではこういうことをやって
探索フェーズではこういうことをやって
収束ではこういうことをやって
探索フェーズでは仮説検証ループを
しっかり記録に文字の記録に残しながら
こういう仮説とこういう仮説
仮説を全部出して
仮説の中から一番最もらしく
一番スコアが上がりそうなやつをやってとか
あと一個一個いっていって
人間だったらこうしろって言ってると思うんですけど
いっていってちゃんと細かくギットコミットして
細かく測定して改善ループを回していきましょう
みたいにやると思うんですけど
それをやらせるとやっぱ遅くなるんですよね
その記録を作らせる過程に
時代にトークンが使われてしまって
そんなことやらなくても勝手に
ドカンと効いておいてくれるので
その辺はやっぱりだから
繰り返しになるんですけど
現実世界に当てはまるわけではないと思うので
あれですけど
ちょっと下はある話だなと思っています
ちょっと似たような構造になってるなっていうところ
最後の話していけたらなと思うんですけど
考えると人間に残った仕事って
どういうところなのかなっていう
ちょっと大きな話になっちゃうかなと思うんですけど
今回のイスコンの話で言うと
そういう環境を整備するみたいな話だったり
あとは評価基準を制定するみたいな話になってくるのかなと思ったんですけど
他とかあとはこういう点もあったりします?
そうですね
まず今回何を人間がやったかというと
今おっしゃっていた評価セットを作って
ベンチマークを回して判断する
これがもっと小さい問題だったら
勝手に回させて
54:00
あとお金を気にしなければ
1回回すと1000円くらいかかるので
もっと並列に回してやっていくみたいなのは
もしかしたらやってないので
実はできたけどできなかったと
僕が言ってるだけっていう可能性もあるんですが
とはいえそれなりに少ない回数で
かつ判断をちゃんとしようと思って
人間が判断して
どの問題を次に解くのかと
その中からその結果を踏まえて何を取り入れるのか
結構人間が判断したっていうのと
あと一番大きいエージェントの構成ですよね
マルチエージェントなのかシングルエージェントなのか
サブエージェントどう使うのか
それとも一番最後にして
すごく薄くするみたいな判断で
それはもしかしたら
単純に評価実験回させただけだったら
これはやったわけじゃないから勘ですけど
エージェントはそっちがいいとは言わなかったと思うので
そこは現時点では残ってますと
これ多分皆さんエージェントスキルを
エージェントに直させていると思うんですけど
それでわかると思うんですけど
すごい全体として矛盾のない
いいエージェントスキルにあんまり
逐一インクリメンタルにエージェントスキルを直させるとならなくて
すごい最初の方に言ってることと
ちょっと矛盾したことを書いてあったり
冗長な例外ルールだけがどんどんどんどん
どこかに過剰書きで突き刺されていったり
同じことを2回言って
直しましたって言ってきたりすると思うんですよね
なんであんまり今の自分の経験上
本当にこれ現時点でっていう話ですけど
あんまりその完全に
評価する環境を与えずに
事実的に判断し直させてもいいことないので
評価ができるようにするっていうのと
評価が重たい問題
今回みたいな評価が時間かかるような問題だと
ちょっとまだわからないですよね
お金かかったり時間かかったりする
なるほど
人間がやるべきはやはり環境の整備と
環境の整備というか
エージェントをどう動かすのか
現時点においてはエージェントをどう動かすと
一番効率が良さそうなのかっていうところを
意思決定するっていうのと
あとは評価環境をちゃんと用意して
評価自体できるような形にするところですね
今はそうです
この2大巨島みたいな
モデルの進化では分からないですけどね
エージェントがエージェントの環境を作るは
今はまだ達していないだろうという
そこが一番でかいと思います
ゲームエージェントだから完全自動でやるのは
まだできない
今はHuman in the Loopで改善しないと
外側の改善ループはHuman in the Loopで
やらないといけなかったっていうのが
今回現時点での状況ですね
これが1年後どうなってるかは分からないですけどね
そこですね
いやそうだなと思いますね僕自身も
今回のイスコアに関しては評価基準が
ばっちり決まってますもんね
スコアというような形で
それが分かりやすく
ちょっと適用できた部分ではありますかね
57:00
特殊な問題ではありつつも
スコアが分かるので最適化しやすい
普通8時間かかるみたいな特性とか
毎年問題は当然違うとか
囲むと絶対傾向が変わってくるみたいな話
共通の部分もあれば違う傾向もあるみたいなので
特殊な要素もありつつ
これでできなかったら
普段の開発ではできないだろうというところもあると思うので
その辺のどこまでできるのか知りたかったみたいなのを
一番最初にちょっと言わせちゃったんですけど
モチベーションの一つではありました
これが実サービスになると別にスコアとかないですもんね
そうですね
それがレスポンス速度なのか
でもそれでも早くてもユーザーに使われなかったら
意味ないよなみたいなそういうのもあったりして
結構複雑 現実世界では複雑なので
ISCONという特殊世界においては
スコアで測れるので
かなりエージェントを鍛え上げるというか
エージェントの環境を作る練習には
かなりなりそうだなと僕個人的には思っているんですけど
川崎さん的にもそうですかね
そうですね もともとAI時代以前のISCONも
教育的効果がすごくあるコンテンツで
先ほど片杉さんもプライベート椅子で
新卒研修とかやってるっておっしゃってましたし
自分の前職でも新人研修で
プライベート椅子使わせていただいたこととかもあるんですけど
やっぱり今でも教育効果ってすごく高くて
まずは実際に人間の手だけでやってみるっていうことも
今でもすごく価値はあると思うし
自律型
ヒューマンのルーフでもいいし
ヒューマンアウトブザルーフでもいいし
その中間でもいいし何でもいいんですけど
エージェントにやらせてみるっていうところの
素材としては
教材としてはすごく価値がやっぱりありますよね
現実空間を
現実世界を模倣する
仮想的なサービスを作って
しかもベンチマークがちゃんとユーザーを模倣して
やってきてくれるしスコアも出してくれるし
っていう世界は
人間が手で
コードとかインフラとかの設定とかを変えつつ
スコアを上げていくっていうのにも有用だし
エージェントを使う上でも有用だしっていうことですね
学習環境としてかなり
他の人が何やったかをちゃんと共有できるから
そこもやっぱり
教材として
学習効果としてやっぱり大きいですよね
振り返りができる
振り返られるし比べられる
仕事だと同じ仕事を別の人が全く同じ仕事やるってないじゃん
そうそうそう
ないですね確かに
けどイスコンだとみんなが同じ問題に取り組むから
あなたはそうやったんですねみたいな話で盛り上がるんですよね
確かに
あそっちの方がいいんだみたいな気づきが確実に得られますもんね
イスコンやってたら
そうなんですよねやっぱり実際の普通の仕事だとないんですよね
1:00:02
そういうのって
ちょっと特殊環境になっちゃいますよねどうしても
そのサービス特有のとかに引きずられるところはあるが
イスコンだと全て統一されているので
そういった学習環境が整えられているという
めちゃくちゃイスコン有用
来年以降も絶対なくては困ってしまう存在なのかなって
ちょっと思ってきたんですけど本当に
結構いい時間になってきたので
ここら辺で締めていけたらなと思うんですけど
なんか片づけさんあったりしますか
そうですね
イスコンは教育コンテンツとしてはすごい価値があるとは
今も思ってるんですけど
今後こういうそもそもプログラミングの考え方とか
あとOSSへの考え方が変わっていく中で
どうなっていくのかなっていうのもありつつ
我々もいろいろ考えないといけないなと思って
あとYalesのOSSってポッドキャストなので
OSSの未来の話もちょっとできたのが嬉しかったです
川崎さんありがとうございました
ありがとうございました
最後に川崎さんメッセージというか
宣伝でもいいんですけど何かあったりしますか
宣伝したいことないんですよね
TwitterXを20年近くやって
今19.5年ぐらいなんですけどアカウント作ってから
死ぬほどこの1週間で増えてびっくりしてるんですけど
よかったらフォローしてくださいっていうぐらいで
ありがとうございます
これをお聞きの皆さん川崎さんのXまだフォローしてない方
いたらフォローしてくださいよろしくお願いします
ということで今回はここまでにしたいなと思います
YalesのOSSでは毎回一つのOSSを取り上げて
それについて片付け点とか技術的なところも深掘りしながら
話をしていく番組になっています
今回みたいな形で緊急中の緊急で
週の途中で撮ってすぐにアップロードして
公開するみたいなことを今回はしているわけなんですけど
そういった形で川崎さんみたいなゲストもお呼びして
話をしていけたらなと思ってますので
ぜひお聞きのプラットフォームでフォローと高評価をお願いします
またこのOSSについても取り上げてほしいとか
あとは自分が作ったOSSだから話したいみたいな
いうものがありましたらコメントとかで教えていただけると
嬉しいのでよろしくお願いします
Xでつぶやく際にはハッシュタグ付けていただけると
見つけやすいのでよろしくお願いします
それでは今回もありがとうございました
川崎さんもありがとうございました
ありがとうございました
