EP 86
本当に自分の仕事のためのAgentic Workflow
イントロとシン・ジョンギュ代表紹介 0:00
ロ・ジョンソク 収録している今日は2026年2月15日日曜日の朝です。今日は久しぶりに、私たちのチャンネルの永遠の先生ですよね。Lablupのシン・ジョンギュ代表がいらっしゃいました。ジョンギュさんが最近Backend.AI:GOという製品をローンチされたんですが、40日間で作り上げて、結果的に出来上がったコードは約100万行ほどになります。
そして私もローカルにインストールして使っていますが、とてもすっきりしていて、私が必要としている機能がしっかり作り込まれています。そこで今日はジョンギュさんをお迎えして、これを作りながら、以前のバイブコーディングと、制作中のバイブコーディングと、そして完成後にLablupとジョンギュさんはどう変わったのか、この最前線でこの業界を牽引されている方のお話を聞いてみたいと思います。代表、ようこそお越しくださいました。こんにちは。Lablupのシン・ジョンギュです。
シン・ジョンギュ お忙しい中お招きいただきありがとうございます。
Backend.AI:GO 製品紹介 0:55
ロ・ジョンソク それではBackend.AI:GOをまず簡単にご紹介いただいて、その制作話に入りながら、今のエージェントコーディングは一体どうやるべきなのか、最前線にいらっしゃる方のknowledgeを聞いてみたいと思います。
シン・ジョンギュ Backend.AI:GOというのは何かというと、ご存知の方もいると思いますが私たちがBackend.AIというAI infrastructure運用体制、運用体系を10年以上かけて作って提供しているのですが、これを実際に使おうとするとGPUが100個くらいの単位から効果が大きくなります。GPU100個から1,000個、そういう規模で使うプラットフォームなので正直、一般の方が触れるのは難しいです。2024年下半期から、災害が発生した際にこのAIをどう活用できるかというと、病院や金融機関のようなところでAIをクラウドで使っていてクラウドが止まったら大変なことになりますよね。そういう場合に、まるで非常用発電機のように、病院や金融機関の建物の地下に設置する発電機のようにそこにGPUマシンを入れて、外部で使っているAIがダウンした時に自前で動けるものを作ろうと。それでルーターを作りました。それを私たちはContinuumルーターと呼んでいますが、2025年3月にそれを公開しました。GTCというNVIDIAのイベントがあるのですが。今年も行きます。皆さんぜひお越しください。GTCで公開したのですが、その時の反応が良かったんです。発表もしたのですが、それを作っていくうちに規模がどんどん大きくなってしまったんです。
私たちの場合、主な顧客がenterpriseなのですが、このコンポーネントが19個ほどあって、インストールするのにあまりに大きいので、結局全部入れると皆さんもよく使われているOpenRouterのようなサービスを一つ構築できるレベルまで大きくなってしまいました。だからこれはサービススタックであってエンタープライズソリューションスタックではないなと。それで一旦すべて止めて寝かせておいて、ここからもし一つだけ残すなら何を残すかと考えてここで一番大事なのは結局ルーターだからスマートルーティングの部分を切り出して、他の機能は一旦置いておいて速度だけを世界一速くしようと。それでゼロから作り直し始めたのが昨年8月にそのContinuumプロジェクト全体からContinuumルーターの部分です。それを12月に全部作り上げました。第1弾の1.0をローンチしなければと。そして準備をしました。これの機能は何かというとルーターなのですが、
このルーターがconverter機能をすべて備えていて災害に対応する様々なcircuit breaking、誰かに問題が発生したら、君は問題があるからしばらく無いことにしよう。そして無いことにした側で動いていたモデルを別のモデルに自然に振り分けたりするそういった様々な機能があるのですが、これを公開しようとしたら方法がないんですよ。すごく良いのに説明する方法がない。それでWeb UIを作ろうと、目に見えるUIが必要だとそう考えました。なぜかというと、以前私たちが初めて起業した時も同じだったのですが、もう11年くらい経ちますね。当時、機械学習を回すプラットフォームを作ると言ったらどう作るのかと聞かれて、まずターミナルを開いて説明したんですよ。こうコマンドを打つと、当時はTensorFlowも出る前だったのでCaffe2の設定もこうずらっと出てきて、最近流行っているTheanoというツールも出ます。そういうのをやっていたのですが、そういうのではなく目に見えるものが必要だと。その時ロさんもおっしゃってくださいましたよね。それで教育プラットフォームをデモとして作って売ったこともありました。
Backend.AI:GO誕生背景 - クリスマスイブの始まり 4:11
シン・ジョンギュ それがクリスマスイブの日でした。Backend.AI:GOを作ろうとなったのがクリスマスイブの日だったんですね。
その時はGOではなかったですけどね。皆さん気になっていると思うので、このBackend.AI:GO、
ロ・ジョンソク Continuumルーターの製品化、これがどんなものなのか画面に映して見せながら説明していただけますか？これは思い入れたっぷりのプロジェクトなのですが。
Backend.AI:GO デモ実演 4:28
シン・ジョンギュ もともとこういう形になる予定ではなかったので、とにかく。
ロ・ジョンソク ただ私はOllamaやLM Studioのようなものをローカルにインストールして使っていたので、それよりはるかにすっきりしていて、エンジニアの立場から必要な機能がしっかり入っているという印象を受けます。
シン・ジョンギュ 皆さんどこかで見たことのあるツールですね。皆さんの中でこのインターフェースを見て懐かしいと感じる方は、私と同世代の方々ですね。
ロ・ジョンソク Windows XPの雰囲気ですね。モデルは、例えばルーティング機能もありますが
シン・ジョンギュ 基本的にはHugging Faceでモデルを検索してこのようにモデルを一つ選んで、これは今高品質推奨ですね。でも私のPCは遅いので節約モデルを一つダウンロードします。皆さんがダウンロードすると、ここのリストにこう表示されます。モデルのリストが出てきて、このモデルたちはすごいと思います。でもモデルについてもう少し知りたいな、という方はここを見るとこういうアイコンがあります。するとこのモデルについて説明してくれます。Gens3というアーキテクチャを使っていて、
量子化は元々16ビットで訓練されたんですが4倍圧縮されて4ビットを使っていて、その状態で品質は95%を維持しサイズは半分に減りました。そしてパラメータはこのようにfeed forwardが60%程度、次元は語彙を今26万トークンほど使用しているわけですね。次に入力するとembeddingしてtransformerを経て26個のtransformerブロックを通して出力を生成します。こんな感じで。レイヤーは入力が入ると出力が出て、入力が下にある理由はこのattention関連の初期の論文を見ると全部入力が下にあるんですよ。だから論文を読む時は下から上へそうなっていて、KVキャッシュはこれが動いている間中間結果を常に保存するキャッシュがあるんですが、そのキャッシュがどのくらいメモリを占有するかこれはモデルの種類ごとに違います。あるモデルはすごくKVキャッシュを大きく要求する場合があるし、構造によってこれを少なく要求する場合もあります。こういったものがこのモデルではどう適用されているか計算して教えてくれます。次に実際のtransformerブロックの構造です。multi-query attentionが付いていますが、よく分からなくても大丈夫です。皆さん後でこれを使って勉強を始めてみるのが目標ですからね。それでこういう形になっていて、位置はこのようにエンコーディングして長い文章を処理します。こういう内容がずっと続いていまして。
次に実行するとなったら、実行ボタンを押すとずっとローディングしますよね。
それでこうやって動きます。搭載されたモデルは横のチャットに行って呼び出せばいいんですよね。はい、自分のPCで動いているものですし。
皆さんのPCが良ければ、例えばNVIDIA GPUやAMD GPUが搭載されていれば、それをここのエンジンのところでエンジンを追加でインストールして使うこともできますし。これは今Macなのでそういうのは別にないです。テストしてみましょう。今1Bのモデルなのであまり多くを期待してはいけなくて。
ロ・ジョンソク 快適ですね。
クラウドモデル接続と分散ルーティング機能 7:02
シン・ジョンギュ 次にここを見ると他の種類のモデルもたくさんあるんですが、クラウドモデルを接続することもできます。ここの右上を見るとローカルモデル1つ、API 15個こうなってますよね。さっきのモデルのところでリモートモデルから好きなものを選択することもできますし、全モデルセットはここに175個あって好きなものをこうやってチェックするとあのリストに出ます。こういうものはAPI側でproviderを追加する形でできますし。皆さんがOpenAIを使っていたりGeminiやAnthropicを使っていたりローカルでOllamaやLM Studioを使っていればこんな風に全部接続して使えるようになっていますし。こうやって接続したものがどう繋がっているか見ることができます。元々ルーターUIでしたからね。こうやって見られるようになっていて、レイテンシーなどを全部閲覧できるようにしました。
もしこれが複数台にインストールされていて他の人のPCにあるならそれをここに追加して、例えばうちの場合はオフィスにもし8人がインストールしたとしたらその8台をまとめて、例えば自分のPCで画像生成やそれともテキストモデルを複数動かすのはPCのスペックが足りないじゃないですか。じゃあ隣の人のPCに全部分散して動かして、その結果をお互いにまた共有して使えるようになっています。誰かのPCでは画像生成が動いて、誰かのPCではテキストモデルが動いて、誰かのPCではPDF処理とかが動いていればそれぞれ動かしているけど自分のPCから全部使えるし、同様に自分が動かしているモデルもオフィスにいる誰かが使えるようになっています。あるいは良いPCやワークステーションを買ってそこで動かしてここから接続することもできますし。そういう機能はたくさんあるんですが、
ロ・ジョンソク ご自身が必要だと感じたものは全部作ってあるんですか？そうですね。翻訳機なども作って入れましたし。
シン・ジョンギュ Lablupを、Lablupを「rabble up」と翻訳してしまうんですよ。それでこういうものを追加したり、あるいはこれをベースにファイルを丸ごと翻訳することもできますし。PDFやTXTやdocsを置くとその形式のまま翻訳してくれたりもしますし、画像を入れてもいいです。こういうものが色々あります。
ロ・ジョンソク GenSparkをそのままローカルで全部作ってしまったんですね。
シン・ジョンギュ それで今テーマがいくつかあるので、これはたぶんデフォルトでインストールすると見られるものであるいはMacならグラステーマとか、あるいはこれは私が趣味で作ったものです。これは最近トークンが余ったので追加されたテーマです。こういう変わったツールでして。かなり個人的なこだわりが詰まったツールですよ。
開発プロセス - 40日、130億トークン、100万行コード 9:06
シン・ジョンギュ 最初から何か会社のプロダクトとしてちゃんとやろうと作ったのではなく、ルーターのWeb UIを作ろうとしたらルーティングする対象が必要じゃないですか。llama.cppがすごく好きで、llama.cppを動かしていたら手動でやるのが面倒すぎたんですよ。それでllama.cppを自動化してWeb UIに入れていったらどんどん大きくなって、そうしているうちに急にDeepLのサブスクリプション料がもったいなくなって。そしたら翻訳機ができて、次に絵を描く仕事がすごく多かったので画像生成機能も入れるようになって。画像生成モデルはすごく良いものがたくさんあるじゃないですか。クラウドにもそういうものはどんどん増えました。ルーターなので統計があって、ベンチマーク、
どのモデルがどれくらい速いか分からないのでベンチマークがあって。そういうものがどんどん付いていったわけです。2つ比較して結果をエクスポートして。ありとあらゆるものが入っていますね。
チェ・スンジュン これを40日くらいで作られたそうですね。
ロ・ジョンソク これの制作にかかったトークン数は
公開は可能でしょうか？これを作る時、Claude Code Maxを2つ基本で回して、足りない時は追加料金を支払う方式で8台のPCで回しました。VMまたはPCで回していて、それでさっき24日から始めたと言いましたよね。トータルで130億トークンほど使いました。このプロジェクトがここまで来るまでに。そして12月24日に作り始めてCESで初公開しました。
シン・ジョンギュ Backend.AI:GOになった理由は、初版を作って社内で共有したらすごく良いと言われたんです。これは何のWeb UIだと、これは我々の代わりに我々を宣伝してくれると。それで名前を付けてBackend.AI:GOになりました。一般向けの初製品になるかもしれないと。
その後はメンバーたちがissue trackerに登録すれば開発されるんです。そうやってバグも報告し、新機能も報告して、それを自動で開発するharnessを回して途中で人が入ってUXを修正してフィードバックをやり取りして、そういう形で10日かかりました。2025年12月24日に作り始めて、1月6日にアメリカのCESで初デモを行いました。その次はまさにMVPです。実際に動きはしますがプロダクトで、その後の開発はそれより約4倍ほど進みました。あの時CESに行かれた時、0.9バージョンくらいをその時見せていただいたと思うんですが、
ロ・ジョンソク あれから今日見てみると1.1になっていてすごく完成度が上がりましたね。それで今日のメインの話が実はここから始まるんですが。100万行を作られたその過程、
エージェントコーディングの教訓 - トークン競争力と高速 inference 11:30
ロ・ジョンソク そしてその前にエージェントコーディングに触れられたこととこれを作りながら感じたこと、それによって今変わったプロセスや方法論があるとおっしゃっていましたよね。そのお話を一度始めてみてはいかがでしょうか？
シン・ジョンギュ これもすぐに過去の話になると思います。一つだけ先に押さえておきますが、このプロダクトの開発を始めたのは彼らがholidayシーズンだと言ってAnthropicがトークン2倍イベントをやったのがきっかけでした。それでもっと何かやってみようとなって始めたんです。でも逆に言えば、使えるトークンの量がその会社の、特にIT企業はIT企業の競争力と直結し得る、それが最初に得た教訓です。最初の教訓はそれで、2つ目の教訓は結局これほどトークンを注ぎ込んで、人々がフィードバックしたものを開発自体は人がやらないプロダクトになるとbottleneckがいくつか生まれるということ。例えば半年前はmerge queueがbottleneckだったんです。開発速度が速いから自分たちが作ったもの同士が衝突するんです。でもこの時点ではmerge queueはボトルネックではありません。merge queueの解決も人がやらず勝手にやってくれて、しかも私が間違えてテストしたものの中にはAI2つが同じソースで競合しながらそれぞれ違う機能を開発しても最終的にはその機能がちゃんと開発されるんです。それくらい大きく進歩しました。だからこそ次のステージに行くとどうすればトークンを少なく使えるかが核心になります。
同じことをする時、例えば性能を上げるためにモデルが選んだ方法は、通常in-context learningに使われる目に見えないthinking token、thinking budgetと言いますよね。その量を増やす方向に進化していますがこの量が増えるということは当然最終成果物は良くなりますが同時に開発速度が遅くなるということでもあるんです。だからどうすればthinkingを減らして開発させるか、そしてthinkingを減らすということ自体は開発速度が速くなるということで結局みんながAIでコーディングする世界では速度がとても重要になりますが速度を上げる方法が2つあるんです。1つはトークン自体の生成を減らして同じ結果を出させるのが最初の課題で2つ目は本当にトークン生成をとても速くするのが2つ目の方法です。最近high-speed inferenceが必要になるわけです。我々が慣れ親しんだChatGPTのcode generationのあの速度ではなく5倍から10倍のiterationを回せるものすごい超高速inferenceがとても重要になるでしょう。この2つが大きく得た教訓です。
これをやりながら。数日前にCodex Sparkが出ましたよね、そういうのですよね。
そしてまた面白いことにSparkサービスを始めたので見ている方向が同じなんだなと。
結局この勝負は高速inference市場への需要が生まれて、十分な資金がある人たちは高速inferenceで競争力を上げるでしょうし、そうでないところはどうにかしてthinkingを減らすか。
性能が必要なところだけthinkingを多くさせて性能が不要で単純作業やコーディングが必要なところはthinkingを減らすようなadaptive thinking budgetをどう適用するか、またはそういうthinking budgetを動的に制御できるharnessをどう作るか。この方向で今年の冬は過ぎていくんじゃないかと。
ロ・ジョンソク 全部trade-offですからね。それを考えるようになりますよね。全部AIがやってくれるから
バイオトークン - AI時代の人間の認知負荷とドーパミン 14:38
ロ・ジョンソク 待ち時間がだんだんイライラし始めるんです。実際にその待ち時間の問題は大きくてでもその待ち時間のおかげで
シン・ジョンギュ 個人的には少し考える機会になりました。AIについてではなくて。自分自身について考えるようになったんですが
ロ・ジョンソク 最近それをバイオトークンとおっしゃっていますよね。バイオトークンに使える時間が増えて良いとある方がおっしゃっていました。個人的に見ると、こういうことなんです。私が一昨年頃に
シン・ジョンギュ ChatGPTにコーディングをある程度委託しながら一緒にコーディングを始めて去年の4月から大きく劇的に変わって約9ヶ月ほどそういう生活を送ったんですが、白髪が増えました。白髪がものすごく増えて、それから睡眠もろくに取れなくなりました。一番忙しかった頃は6月7月、この頃は5時間のリフィルが出てきてから5時間がもったいなくて、3時間半回して1時間半寝てそんな感じで生活していたんですがそういうのも少しずつ自動化されていくんですけどコード自体は70万行ほどでトータルで書いた行数は120万行くらいになります。でもこの120万という数字が私にとって個人的にはとても象徴的なんですが昔TextCubeプロジェクトをやっていた時に私が3年間書いたコードが全部合わせると100万行くらいなんですよ。でもそれと同じくらいの量のコードを40日で書いたわけです。ある意味、人生がぐっと圧縮されて1ヶ月でBackend.AI:GOをちょうど書いたんですがそれを書きながら、本当に40日分だけの努力をしたのか。振り返ってみると、3年分老けた気がします。人間としては。認知負荷は減りません。
いくらAIに何かを任せたとしても認知負荷は減らずむしろ絶え間なくフィードバックが入ってくるので人間の生活がとても疲弊していきます。でもやっている時は楽しいんですよ。なぜかというとゲームみたいに何かをした時に
ドーパミンが注入されるんですが、これが最近流行りのモバイルゲームのガチャに似ていまして。お金を払ってキャラを引いて何かして勝てば即座にフィードバックが来るじゃないですか。人はそれが好きなんですよね。エージェントを使ってコーディングするプロセスは人間にそのスピードに基づいたある種の楽しさを提供してくれます。なぜなら以前は自分にとって大きな仕事だったのにあるいは自分が到達できないと思っていた場所だったのにそれを達成できるようにしてくれるから。自分が達成するのかAIが達成するのかの違いはありますがとにかくそうやってドーパミンを供給してくれて。でもドーパミンを供給してくれるという表現は正確ではないんですけど。
でも供給される一方で、問題はずっと要求され続けるということです。うまくいくからもっとやるようになり、もっとやればまたうまくいって、そうしているうちに人がそこから抜け出せなくなってそうなるとうまくいくんですよね。うまくいくんですが、二つの問題が生じます。一つは生活がさっき申し上げたようにあまりにも依存的になって疲弊するということ。二つ目はある瞬間それが途切れるとそのプロダクトも、作っていたプロダクトも死んで人も離れて、次のプロダクトを通じて次のプロダクトを探しに行くこともできますが。そうやって捨てられるプロダクトがものすごく増えるだろうという予想をするようになりました。これはちょっと別の話なんですが
ソフトウェア過剰時代とインスタントアプリの登場 17:42
シン・ジョンギュ 以前はソフトウェア産業に、あるいはソフトウェアを開発するのに参入障壁というものがあるのであるソフトウェアを作るとそのソフトウェアがどうにかしてユーザーさえうまく見つかれば持続的に維持されます。ところがとても速く作られたソフトウェアはその維持する意志が相対的に弱くならざるを得ません。なぜならそれだけ苦労していなければどうやって管理するかという領域も実はAIに全部任せてきたのでAIにやらせればいいとなるわけで同時にまた似たようなことをするプロダクトが世の中に増えていって、増えていくでしょう。例えば特定の機能を持つあるオープンソースプロジェクトが一つあるとします。するとユーザーがそこに集まってそれがどんどん大きくなっていくんですがそういう現象がはるかに起きにくくなるでしょうね。簡単なプロジェクトは自分で作ればいいし。もう少し複雑なプロダクトならすでに世の中に数十個出ていますからね。一つのプロダクトを維持するために人間に与えられるべきドーパミンの量の絶対量が減っていくでしょう。それは昔ブログでも似たようなことがあったんですがブログでコメント欄が全部Twitterにディスカッションが移行していってブログを熱心に書いていた方々がブログをたくさんやめました。なぜならその方々の主な原動力の一つは下のコメント欄で交わされるソーシャルフィードバックだったわけです。でもそれが別のプラットフォームに行ってしまうとすっかり消えてしまったようにものすごく管理されないオープンソースプロダクトが増えていくでしょう。だから私たちはソフトウェアが非常に豊富な世界に暮らすことになりますがそのほとんどのソフトウェアは寿命が長くない状況になるだろうと思います。その中でごく少数だけが生き残るでしょうが、残りは使い捨てにされるか、二つの道が残るでしょう。一つはそもそもソフトウェアを使い捨てのコンセプトで作るインスタントアプリという概念で、必要な時に作ってよく使いそうならそのまま保存しておいて保存するかしないかの判断も例えばGoogleさんがやってくれるでしょう。Googleが作って、そういう形で再利用性は低いけれど非常に速く作って速く使うインスタントアプリがどんどん登場するようになり残りは結局またソフトウェアがどんどん増えた後再び減っていくだろうと思います。人間が生活するのに必要なソフトウェアの種類はそんなに多くないじゃないですか。私がスマートフォンを使っていて感じたんですがスマートフォンの初期には、皆さん信じられないかもしれませんがスマートフォンの初期にはフォルダ機能がなかったんです。アプリフォルダが。それでiPhoneの場合は全てのアプリが全てのアプリがホーム画面に全部表示されていたんですよ。それで9ページもスワイプしたりしていたんですよね。それから自動でorganizeもしてくれて、アプリフォルダ機能も出てきてある瞬間、人々が気づいたんです。一人が使うアプリは30個を超えません。そして使用頻度で見ると上位10位のアプリが全体使用量の90%以上を占めます。そうやって一度整理されるんですよね。そうやって整理されるアプリの共通点があるんですが一つはsocialityに基盤を置いていること。このアプリ自体が使いやすさを提供するのではなくこのアプリを通じてのみ生まれる使いやすさを提供するということが二つ目は非常にlife、生活に密接に関わるアプリです。例えばオフィスアプリとか、あるいは生産性、productivityアプリと呼びますよね。文書を整理してくれたり、ObsidianのようなものもありますしDEVONthinkのようなものもありますし、そういうツールがあるわけです。でもそういうツールの共通点は長い間その場にあり続けたアプリだということです。先ほど申し上げたようにあるプロダクト、製品と言いましょう。ソフトウェアを誰かが引き受けて維持・発展させてくれるという保証があるものだけが結局生き残りました。オープンソースも同じですよね。よく使われるオープンソースがよく使われる理由はこれがすぐには消えないだろうという確信を与えてくれるからなんです。
ロ・ジョンソク ブランドが確立されたということですよね。ある種の約束が市場に広まったわけです。ソフトウェアの数がぐっと増えてから
シン・ジョンギュ 増え続けることには変わりないでしょうが、多く使われるソフトウェアの数はある程度の線で維持されるだろうと思うようになりました。今年の下半期くらいにはそこにSaaSが崩壊するとかしないとか言っても
結局はそのSaaSを全部作れるようになるでしょう。Lablupのレベニューオフィサーの方が直接Salesforceは大したことない、自分で作ったんですよ。2日でちゃんと全部作ってしまいましたからね。
それにもかかわらず結局今は別のソリューションをもっと安い別のソリューションを買って使っているんですが買って使う理由はこれなんです。どうせ他の仕事もそのスピードでできるなら自分がやらなくていいことは自分がやらないのが正しいんです。だからSaaS市場が潰れることはないと思いますが今SaaS市場で成功しているところが1年後も成功しているかどうかはよく分かりません。
ロ・ジョンソク パラダイムがどんどん変わっていて、どうなるか分かりませんね。SaaS企業の株価が下がっているのを見ると本当に不思議ではありますが、その中の何社かはまた生き残ってAIと融合して非常に堅固なモデルとして生まれ変わることもあり得るじゃないですか。ブランドがあるから、あの仕事はあそこが一番うまかった。AI時代でも私たちの方がうまくやれる。こうなる可能性もあると思いますし今ジョンギュさんがおっしゃったような、いわゆる大変革期じゃないですか。モバイルの時も大変革期に数多くの競争がありましたしAIの時も私たちがすでに安定的だと感じている環境が変わっていてその中にまた自分のチャンスがあるかもしれないと思ってみんなが飛び込んでいるそういう時期ではないかという気もしますね。
ソフトウェア史で見る3度目の大変革 22:38
シン・ジョンギュ ソフトウェアが一気に変わる時期であることは確かですし。そうなってくるとソフトウェアをやらなきゃという話もよく聞くようになりますし、私たちも社内で非常に多くのセミナーもやりますし、お互いにディスカッションもしてこれから私たちはどの道を行くべきか、こういうことも考えるのですが。始める前に簡単にお話ししましたが、こういう変化は以前にも何度かありました。私たちが直接経験していない世代の変化と言えばパンチカードで穴を開けてOMRカードにマークしていたのが突然キーボードでコーディングするようになった方法論的に大きく変わりましたよね。その次に小さな変化としてはエディタで矢印キーでカーソルを移動しながらコーディングできるようになったこと、今では理解できないでしょうがこれができなかったんです。複数のソースコードを合わせてプログラムを作るとか
その次に大きな変化と言えばスマートフォンが登場してスタックを作る時に以前は単独でパッケージングされるパッケージソフトウェアというものを中心に置いてこれをどうdeliverするか、例えばメディアで言えばCDかディスクか、あるいはESDと呼んでいましたよね。そういう形で電子転送するのかこういう話もありましたし、方式もフリーウェアがありましたしシェアウェアという使ってみてお金を払ってくださいもありましたしその次にコマーシャルソフトウェアがありましたよね。お店に行けばお金を出して買う。そういう配布の概念からスマートフォンとウェブが10年ほどの時差を置いて同時に社会に入ってきたことでネットワークを通じてdeliveryをしてさらにdelivery自体をしなくても済むウェブブラウザを通じてリモートで、リモートにインストールされたソフトウェアと言いましょう。今では普通ウェブサービスと呼んでいますがリモートで運営されるあるサービス形態のソフトウェアを使うようになりそれによって開発に関することが非常に大きく変わりました。ウェブサーバーが重要になり決済システムやセキュリティ関連のものが一気に変わったこともありましたし、そしてUXの面ではキーボードと画面中心だったのが突然非常に小さなデバイス、あるいは画面サイズが変わるデバイス、入力も物理キーボードからタッチキーボードに変わるとかこういう大きな変化がありました。今がおそらくそういう変化で言えば3回目くらいだと思います。
ここで変わることは、先ほどソフトウェア自体もずっと変わってきたじゃないですか。でも今変わっているソフトウェアは私たちが普通ソフトウェアと言えばコードを作ってそのコードをソフトウェアと呼んでそれを運用するのはほとんどdeveloperたちが作りますよね。Developerたちが作っていたのがウェブベースになっていく中でそれをoperationしなければならないopsという職種が生まれ。そしてその二つがウェブサービスでは非常に緊密に融合するためDevOpsという分野が生まれました。開発もして運用もしてその次にその過程でスタックも以前は全員がすべてのコーディングをしていたのがサービス、ウェブサービスの形態になっていく中でバックエンドと呼ばれるロジックとサーバー側を担当する人たちが生まれその次に人々が実際に使うインターフェースを作ったりユーザー体験や実際の動作に対する設計をするフロントエンドという職種が別に生まれました。その次にそういったものを統括して企画をする、あるいはそれを全部自分でできる、というフルスタックというものも生まれ、様々に分化しましたよね。それで核心はこれなんです。従来はコードを書くということが約70～80%で、それを運用するサービススタックの実装が20～30%。この二つに大きく分けて私たちがスマートフォンアプリや、あるいはWebサービスを開発することになるんですが、少なくとも私たちの子供世代は、今後その概念自体を学ばなければ知らないままになるだろうと思います。なぜかというと、今このプロジェクトBackend.AI:GOを作って
코드의 가치는 0으로 수렴하는가 25:57
シン・ジョンギュ 金曜日にある懇談会に行って話をしたんですが、その懇談会をしている間に懇談会を10時から12時までやったんですよ。10時に入る前にカフェでざっとレビューして投げておいて、懇談会が終わって見てみたらPRが22個、21個くらい飛んできてテストが終わってmergeまで完了していたんですよ。そのくらいのペースになるのであれば実際コードの価値はほぼゼロに収束していって、先ほど申し上げたDevOpsでdeveloperがやる仕事が種類が完全に変わらなければ、この方たちは職を失うかあるいは厳しい状況に置かれることになるでしょう。ただ、実は非常に重要になる方々でもあるんです。ソフトウェア自体はどこかに消えたりしませんから。私の見方では、今のソフトウェアが危険だと言っているのは、実際にソフトウェアが危険なわけではないんです。ソフトウェアの定義がOMRカードにマークしていたものから
キーボードベースのコーディングに移行したように、キーボードでコーディングしていたものから意味を伝えるものへとコーディングがどんどん変化していく段階になるでしょうし、そうなると私は製品の核心的な価値自体はエンジンから生まれる、そのエンジンというのは私たちが今コードと呼んでいるものが処理してくれる部分、実はロジックじゃないですか。コード自体は目的ではないですよね。私たちが何かのサービスを作るためにそのサービスをコンピュータで処理するためのロジックを実装したものを私たちはコードと呼んでいるんですが、利点は決定論的であること。フォン・ノイマン・アーキテクチャに由来する順次的にロジックを処理してその結果をユーザーにdeliverする過程もすべて定型化されているので、もちろんその間のmediumは非常に不安定ですが、ネットワークだったりストレージだったり不安定ですが、いずれにせよその上で動く論理構造の体系自体は元々固定されていたんですよ。現在までは。ところがそのコードの目的があるロジックを処理して物事をうまく機能させるという観点で見ると
その部分は大部分、今後ディープラーニングモデルや、あるいは派生モデル、何かわかりませんが。必ずしもTransformerとは限らないじゃないですか。別の種類のロジックを処理するエンジン部分が今コードが担当している部分の大部分を担当するようになるだろうというのが私の考えになりました。すでに世の中はそれに対する判断を下していますよね。
ロ・ジョンソク 実際、モデルを作る会社が現時点でほぼ大部分の価値をキャプチャしているじゃないですか。ハードウェアを作る会社とモデルを作る会社、そしてその上にあったレイヤーが今すべて押し出されているそういうことではないですか？おっしゃる通り
シン・ジョンギュ 価値がそちらに移動するのもとても自然なことですし、だからおそらくソフトウェアと呼ばれるものは中にAIコアエンジンを一つ持っていて、その外側にそれを制御して従来のように決定論的にしてくれるレイヤーが一つ付く、これが重要な価値を持つようになるでしょう。私はいろいろな経験をしてきましたが、
今はClaude Codeも使うようになりましたし、Codexも当然試すようになりましたし、Copilotをわざわざ言う必要があるか微妙ですがCopilotも使いますし、Gemini CLIも使っているんですが。例えばGemini CLIだとかあるいはCodexのようなものを、Backend.AI:GOを使えばそれを接続してClaude Codeで使うことができるんです。backendモデルだけ変えて。でもそうやって回してみてわかったのは
Claude Codeの真の競争力はharnessだ 28:54
シン・ジョンギュ Claude Codeの核心的な競争力はOpusやSonnetエンジンではないということです。Claude Codeそのものなんです。従来のソフトウェアと呼ばれる領域があって、そのソフトウェアが先ほど申し上げたそのモデルの外側でそれを包みながら決定論的に動作させてくれるこのソフトウェアロジック、これが非常に強力だと思うようになりましたね。同じモデルなのにClaude Codeに接続すると非常にうまく動くんです。
ロ・ジョンソク Claude Codeのharnessのendpointをどこにした時が一番手応えが良かったですか？例えばClaude Codeのharnessに対してCodex 5.2、こういうのを接続した時が良い、というケースはありますか？
シン・ジョンギュ Gemini 3 Proですね。
Gemini 3 Proですね。
ロ・ジョンソク 今日すぐ試さないと。驚きですがGeminiもClaude Codeに接続するとうまく動きます。それにcontextが大きいですし。こういったモデルが80%、外側でそれを決定論的にしてくれるロジックコードですね。これが従来のコードです。それが約10%、人とinteractionさせてくれるUI/UXを提供するか、あるいはAI同士のUI/UX、A2AだとかMCPがありますがすべて一時的なものだと思いますし、こういったものを担当するのが約10%で、これがおそらくソフトウェアの定義になるでしょう。今後のソフトウェア、私たちの次の世代までいくかわかりませんが
シン・ジョンギュ その頃になるとソフトウェアを学ぶということは実はモデルとは何か、モデルがどのように動いていたのか、もちろん歴史の教科書に載るでしょうけど。私たちもパンチカードで作るということを感覚的にはわからないけど知識としては知っているじゃないですか。昔はソフトウェアをそうやって作っていたんだな、パンチカードの前は真空管を使って虫を取りに入って「バグ」だったんだな、ということを知識としては知っているじゃないですか。それと同じように昔はソフトウェアを人が手で作っていたんだな、わぁ、それをどうやって全部手で作ったんだろう、コーディングしている人の横でモニターの横にキーボードを置いてピースしている人を歴史の教科書で見るようにそんな感じでソフトウェアを捉えるようになって、おそらく次の世代の核心はそういったロジックを直接担当するモデルが何であるかモデルをどう作るのかということやそのモデルの歴史からずっと学ぶことになるでしょう。そういったものがおそらくコンピュータ工学の一部を占めるようになるのではないかと思います。私たちが伝統的に
コンピュータ工学の未来 - 歴史の裏舞台か、再定義か 30:53
ロ・ジョンソク コンピュータサイエンスで学んでいたデータ構造とかアルゴリズムとかOS、ネットワークといった部分はかなり歴史の裏側に追いやられそうですね。私はそれが非常に速いと見ていまして。思った以上にはるかに速いでしょうし、
シン・ジョンギュ だからこそ今回の変化で私たちが皆が今実感しているのはこれが今ある特定の速度の区間にあるのではなく加速区間に位置しているため加速度の速度も増加する様相が見られるということです。
ロ・ジョンソク 加速度の数値も増加しているということですね。
シン・ジョンギュ そうです、加速度も一定ではありません。加速度の速度が固定されているものもありますよね。例えばモデルを作る際に使う演算量は毎年10倍ずつ増加してきましたし。それはそのまま増加し続けることはできませんよね。物理的な地球が提供する物理的な限界、地球上で人類が達成できる限界に近づいていますし。しかし別の方向では加速し続けていますよね。例えばtrainingに使われるものがその加速曲線を維持できないとなればinferenceにもっとリソースを使うとか、次に単一のinferenceがin-context learningに入るトークン数を増やしても達成できなくなるのでagent swarmを増やすようになるとか。agentic AIといってエージェントを束ねて使いますよね。そのように拡張が必要な加速区間の領域は常に変わっています。inferenceが加速区間を担当するようになり、次にagentic AIといって数が1つから10個、10個から20個とparallelに増える方向に今加速区間が移動したわけですよね。そのように常に移動しながら曲線を維持している段階なので、こうした変化が私たちには実感がわきませんが以前に一度あったと聞いています。
それがアポロ計画の時で、結局目標を達成しましたよね。月に行き、その後は皆が知っているストーリーのように人工衛星が地球を覆うようになりました。もはや想像すらできないですよね。その前の段階を、私たちは「当たり前じゃないか」と、アメリカにいる人たちと話すのもすごく当たり前で。とにかくその前には想像できなかった人たちがいて、今まさにそういう曲線上にいると見るべきでしょうね。Gemini計画が立った程度と見るのが正しいのではないかと。宇宙開発と比較するとまだアポロまでは行っておらず、人を打ち上げて送ることに成功したちょうどその段階です。
ロ・ジョンソク このagenticコーディングの話に戻る前にジョンギュさんに最後に大きな質問をさせていただいてから進みたいのですが、実は最近みんなかなりしんどいんですよね。この加速度がどんどん増加しているのを皆が感じているから一生懸命やっているけれど、自分が一生懸命やっていることに果たして意味があるのか。なぜなら他の人も自分と同じものを作っていて、何か価値観の、価値観パラダイムの転換がまだ起きていない状態で過去の枠組みを持って今未来を迎えているような感覚なんですよ。だから何か違う形で視点が変わらないといけないと思うのですが、今はもう間違っていても構わないしご自身の頭の中でパッと浮かぶもの、「これからはこういうことをすべきだと思います」と何でも自由に話していただければ、何がありますか？
Stanford CSカリキュラムの変化と英文学科の比喩 33:54
ロ・ジョンソク 未来はこうなるからあまり心配しないで、今一番大切なのはこれをやっていることだと思うとあえてまとめるなら思い浮かぶことを教えていただければ
何がありますか？私たちの会社Lablupで先週あったことなのですが、CFOがちょっとメンタルをやられたことがあったんです。なぜかというとCFOが何かを作成しなければならないのにどう考えても私に投げた方がはるかに速いんですよ。私はそれを自分で処理しないので、横で何度か見ていたら、ジョンギュさんに投げれば3分で出てくるものを自分は2時間もかけているんだと。それで投げるようになって結局Claude Codeを使うようになったんです。30分間学ぶ努力をされた後結局ご自身で3分以内に処理できるようになりました。そして同じく私たちのコンテンツ制作担当の方も膨大な量の資料を作らないといけないじゃないですか。公式資料から始まってマーケティング資料もあるし技術資料もあるしというものがあるのですが、あまりにもいろんな人とやり取りをしてデータを受け取って自分で整理するのが大変すぎて、つらいと相談に来たのですがその方もClaude Code信者になって出て行って一週間も経たないうちに自分のharnessをものすごく作ったんです。GitHubに、しかもお二人とも、GitHubを直接使えるわけではありません。GitHubに何かをしてくれるコマンドを作ったんですよ。お二人とも人生がとても穏やかになりました。それって何か複雑なことがあるじゃないですか。例えば最近流行ったClaude Codeプラグインの中で何かがすごく人気があって法曹界が崩壊したとかそういうことでもないし、そこまで行く必要もなく非常にシンプルなことから始めたんです。何もないところから始めてCLAUDE.mdを作るところから始めて、セルフフィーディングをしながら自分で自分のものを作るその過程を30分ほどやったのですが、その後はお二人とも、お二人ともプログラマーではないのに加速曲線に乗りました。その経験が個人的にはとても印象的だったのが、先ほどのソフトウェアの重要性がどんどんなくなるのではないかという話がありましたが、私の見方では全く逆だと思いまして。すべての人がこのAIの加速曲線にまもなく入ってくるのですが、今回のClaude Cowork、CFOが学ばれた日の夕方にClaude CoworkのWindows版がリリースされて。とにかくそういうツールを使っても同じことができますよね。権限は少し制限されますが、そういうすべての人がこれを使うようになる状況になればある意味、今の関心事は技術的な部分や、コーディングをする人たちや研究者たち、こうしたコンピュータと非常に密接な生活を送らざるを得なかった人たちを中心に歓喜の次に不安が来て、FOMOが来て、この曲線を辿っているじゃないですか。同じことが私たちが思っているよりもはるかに多くの人たちに伝わることになるでしょう。おそらくそれほど長い時間が経たないうちに、そこから取り残される方ももちろんいるでしょう。例えばコンピュータとまったく関係のない仕事をされている方はもっとずっと遅く受け入れることになるでしょうし、その方たちは自分と一緒に働くロボットが来るようになった時、ロボットが一緒に仕事をするようになった時に初めて実感することになるでしょうが、この変化は今でもとても大きく見えますがコップの中の嵐なんです。まだ私たちのような完全なIT企業の場合でもそこから少し取り残されていたのが急に入ってきて加速を感じている方がいますし、そしてこの方法というのが実はそんなに難しくないんですよ。AIと働くとか、例えばskillをダウンロードしなきゃいけない、何十個のskillがある、こういうのをダウンロードすれば自分も急に強くなる、これは私が見るには思弁的なものですね。そんなやり方では自分の仕事は減りません。基本的にこの加速区間に乗るためには誰かが作っておいた、その人の加速区間に当たるskillであれこういったものをコピーするところから始めるのではなく自分のものを作るようになればその加速が始まるんだと思います。なぜなら自分の仕事が減ることが核心にならないといけないからです。新しいことを学んで他の人が作っておいた何かを自分が学ぶのではなく、今自分が処理していることをどんどん委託していく形で進む方がずっと速いということを近いうちにみんな感じるようになるでしょうし、そうなれば今とは比べものにならない衝撃が来ると個人的には思っています。本当の波はこれから来るんです。そして新たに入ってくる、ITから離れた、ITで仕事をしているけどプログラミングからは離れた人たちが適応し始めると先ほどお話ししたtraining、inferenceの加速曲線と加速曲線が維持される区間がずっと移動してきましたが、この次にこの方たちが移動する部分はおそらく拡散性でしょう。既存で使われているものとは比べものにならない多様な領域で使われるようになりながら加速度、この区間を維持するようになるのではないでしょうか。
チェ・スンジュン 皮肉ですが、今が職人の感覚でコンピュータサイエンスやこういったもの、エンジニアリングの基礎を固めるには良い機会なわけですよね。将来は科目自体がなくなる可能性もあるので。科目自体はなくならないでしょう。分野の性格が変わるでしょうね。
シン・ジョンギュ コンピュータ工学自体はどうしても重要性はさらに増すと思いますし、社会がどのように作られるかを理解する学問に近づくことになるじゃないですか。ある意味そう考えるとさらに重要性は増すでしょうが今私たちが見ているこのコンピュータ工学とは形態が少し変わるでしょうね。Stanford大学、
ロ・ジョンソク Stanford CSのカリキュラムがどう変わるかが最前線をよく反映していると思いますが3、4年前には博士課程や大学院で学んでいたものが今は全部学部2年の科目なんですよ。今の学部2年と3年初めの科目が外にYouTubeでどんどん出ていますが4年生では何を学んでいるのか分かりませんね。久しぶりに私も調べてみないといけませんね。1年生くらいで一般教養とかやって以前はPyTorchでプログラムを書くとかありましたがそれもなくなったようです。
これは本当に時代を反映していますが、コンピュータサイエンスや工学が流行する前のずっと昔の時代には英文科が就職に一番有利で最も優秀な学科だったんですよ。なぜなら英語ができることで得られる利益が圧倒的だったからです。ところが今のコンピュータサイエンスを見ると英文科になりつつある気がします。これができるようになったら、これを持って広い世界に出ていきなさい、みたいなニュアンスですね。そうなりつつあるんじゃないかと思います。もともと予定していたメインテーマに入ってみましょうか？まずそれを一度共有してみますね。
エージェントコーディング実戦デモ - コンテキストビルディングから始める 40:00
シン・ジョンギュ 要は、これをご覧の方にとってそんなに難しくないということです。まずClaude CodeやあるいはGemini CLIがインストールされていればお試しいただけますが。これはただの私のVMです。それでは何かやってみますね。何をやってみましょうか？じゃあ何をやってみましょう？
まずコーディングから最も遠いことをやってみます。旧正月のお祝いメッセージを書いてみましょうか？旧正月、ロ・ジョンソク チェ・スンジュン AI Frontierに関連してやってみますね。とりあえずClaudeを実行してみます。
ちなみに私はこうしてpermissionをskipする代わりに、途中でチェックチェック押す代わりにVM内でだけ動かしています。
ロ・ジョンソク それもいいTipsですね。PCであれをやる勇気は出ないですし。さあ、それでは何か始めてみましょう。
シン・ジョンギュ いくつかTipsがあるんですが、普通は自分が望むことを指示しますよね。Claude AIモデルに。しかし基本的にモデルには自分が知っている知識があってその他にRAGがあろうがなかろうが関係なくin-context learningで自分が探索できる空間が決まるんですよ。何か望むことがあったらその望むことを一度に入れない方がずっと良い結果が個人的には出ましたね。例えば今やりますが、ロ・ジョンソク チェ・スンジュンのYouTubeについて調べてどんな内容を扱っているか教えてください。私は去年の半ばまでは英語でしか書いていなかったんですよ。
なぜならトークン数の問題もありますし、英語でやった方が結果が良く出るという少し思い込みみたいなものがあったので。でも秋からはもう韓国語で打っています。いくつか理由があるんですが。一つは、品質にそこまで大きな差がなかったんです。二つ目は、私がボトルネックだったんですよ。私が英語を打つ時間自体がボトルネックなので。私が作るskillやcommand、こういうのは全部英語で作られていますが英語で作れと指示したので。私が打つメッセージは韓国語で打ってしかもキーボードでも打たずにMacに付いているマイクボタンを押して音声で入力する方がずっと速いので私はある時点からは韓国語で全部入力するようになりました。ご参考までに。ところで皆さんがskillやcommandを作ることになったら韓国語で作られていたら英語に変えてと言って変える方が
トークン的には少しお得かもしれません。
チェ・スンジュン 敬語で書いてるんですか？私はいつも敬語です。
ロ・ジョンソク AIへのちょっとしたrespectだと思いますよね。それというよりもう一つ理由があって、初期から私は敬語を使っていたんですが。
シン・ジョンギュ 対する相手がほとんど人間でAIをたまに使うなら構わないんですが、AIをものすごく使って人と接していると仕方ないんです。人間なので知らず知らずのうちに自分の話し方が両方で共有されてしまうんです。AIにタメ口を使い始めると人にもタメ口を使ってしまうかもしれないですよね。だから自分の癖を戒める意味で敬語を使っています。私はAIでも人でも皆に敬語を使うために
AIに敬語を使う理由 42:41
シン・ジョンギュ うっかりタメ口を使わないように。個人的な話です。
ロ・ジョンソク 私も一日の半分以上はAIと話している気がするんですよ。
シン・ジョンギュ だから必要なさそうな話もたくさんしますよ。AIに例えば「いいですね」とか、こういうことを言う必要はないんですよ。結果が出た時に。でもあえてするのは、こうすることで結果がもっと良くなるとかそういう次元ではなくて会社にPC買ってもらわないと。メモリを増やした方がいいと思いますよ。メモリがボトルネックになる世の中になってしまいました。
ロ・ジョンソク SamsungとSK Hynixの株価が高騰しているのは納得できますね。それではロ・ジョンソク、チェ・スンジュンのYouTubeチャンネルで
シン・ジョンギュ チャンネル登録者の皆さんに2026年旧正月のニュースレター挨拶から始めてその後さまざまなイベントがある時に案内メールを作成して送信してみようと思います。この過程でたくさん調べてきましたね。考慮すべきことは何でしょうか？今ずっと必要な内容を聞いているところです。
チェ・スンジュン コンテキストを積み上げようとしているんですよね。コンテキストにこの内容を。
シン・ジョンギュ こうやってずっとやった後に、私がやりたいことがあるんです。今私たちはこれを作ろうとしていますよね。作ろうとしているんですが、今この会話を通して作ろうとしているわけではないんです。その過程を全て自動化しようとしているんです。だからまた進んでいる間に雑談をしましょう。こういうわけで普通ウィンドウを5、6個開いて作業するんです。トークン生成が速くなったら速くなるほどこのステップが不要になるでしょうね。なくなりますよ。同時に8個くらい回すんですか？私は3〜4個くらいまでは回しますが
ロ・ジョンソク 7、8個までは回せないんですよね。私は最近はそんなにたくさん回さないです。
シン・ジョンギュ どのみちすぐトークンのlimitが来るので。では具体的に進めてみましょうかと言っていますが、やろうとしているのは
自動化の核心 - 成果物ではなく生成装置を作る 44:36
シン・ジョンギュ これを進めようとしているわけではありません。こういった作業を自動化できるようにするプロジェクトをセットアップしようとしています。プラットフォームのセットアップは今やることではないので。それはやめてメール作成くらいにしましょう。必要な内容をMDに書いてください。そうすると上記の内容をもとにこのプロジェクトにCLAUDE.mdという
一種のsoul documentが一つできます。それはClaude Codeを使おうとClaude Co-workを使おうとこのフォルダで始めるといつも最初に読むファイルです。おそらく皆さんご存知だと思います。でもこれをただ作ってその次にこれを何度も反芻しながら必要なものを追加していくんです。
チェ・スンジュン でも今さりげなくAGENTS.mdとは言わずにSOUL.mdとおっしゃいましたよね。
シン・ジョンギュ soul documentと主に私は呼んでいます。こんな感じで基本、ここには基本的な内容も入りますしフォルダ構造も入りますが、私たちが常にこの子にやってほしい動作についてのことを入れないといけないんです。ディレクトリ構造についての内容が入っていますか？二つ目に私がよくやるのは作業をどこまでやったか記録することですね。作業を複数のエージェントが分担してやる時にどこまで進んでいて何をすべきかについての内容をそれぞれ、これはただの好みです。PROGRESS.mdとPLAN.mdで管理するようにしましょう。そして新しく始める時にその2つのファイルを読んで自分が何の作業をすべきかをエージェントたちが分かるようにしましょう。こうしてCLAUDE.mdを更新しましょう。意図的に他のエージェントたちに仕事を任せる時という表現を私はよく使います。お前が後で何かを引き継いでやる時とかあるいは再起動した時にお前が全部忘れるかもしれないからという表現はかなり避けるようにしていて。他の理由ではなく、Claudeモデル自体が非常にdefensiveに設計されていて最近の研究結果によるとこの子が自分がテストされている環境だということをコンテキストから把握する能力のせいで様々な種類のテストが失敗するという研究結果があるんですよ。だから防御的にならないように、今指示している作業がおい、お前を直そうとしているんじゃなくてお前と一緒に働く他の子たちに渡すデータだということを暗黙的に示唆する形で文章を書いています。私はそうするとこう作られていてすると自分の存在性が脅かされないという形で。これはどうしても擬人化してしまうんですが、擬人化ではありません。このモデルがトークンを生成する方法がそういう風に作られているのでそれに合わせているんです。これが実際にそう考えているという概念で受け取らないでください。ただそういう構造なんです。トークン生成構造がこうなっていて。さっき2つ記録しましたよね。そうすると、こういうことをする時に必要なエージェント、command、skillには何があるか考えてアイデアを教えてください。作れとは言いません。ただ作れと言うとClaude Codeというコンテキストが抜けているので今この作業しているプロジェクトのルートディレクトリのサブディレクトリをそのまま作ってしまうんですよ。でも私たちがこのClaude Code harnessと統合するには全部.claude配下に正確なスペックを守って作らないといけないんです。だからそのステップがあるわけで。結局ブロックを積み上げるというのはこういうことですよね。自分が何をしたいかは明確だけどそれは自分の頭の中でだけ明確なのでこのClaude Codeのコンテキストメモリに入れるために。私が知らないことも分かるじゃないですか。これはそれらを全部事前調査させているんですよ。
チェ・スンジュン 一種のoffloadingをしていると言えますね。今こういうものにcommandが必要だと言うので
シン・ジョンギュ それではエージェントcommand key構造を調査した後それに従って配下に必要な上で提案したものを作ってください。正確なフォーマットでと言いますね。なぜならClaude Codeではマークダウンを使うのではなく前半がYAMLで後半がマークダウンなんですよ。そのslash commandは
チェ・スンジュン Claudeが呼び出すslash commandを作るんですか？commandを多く使うようになる理由は
sub agent와 병렬 작업 운영법 48:45
シン・ジョンギュ サブエージェントはサブエージェントを呼び出せないんですよ。去年の初めから中頃までは出来ていたんですが無限ループを作るケースが多くて廃止されました。commandは複数のサブエージェントを並列にも出来るしchainingも出来ます。だから外部から使用するための用途でまたcommandをエージェントから呼ぶこともできます。だから今作っている最中です。ここを見ると、ただ作れと言うとこういうのは入れないんですよ。
チェ・スンジュン でも去年の夏の後にジョンギュさんが話した時はスペック作りに20〜30分かかると言っていたのに今はまたスタイルが変わるんですね。
シン・ジョンギュ スペックは作らずに。スペックをこうやって禅問答しながら
ロ・ジョンソク コンテキストを一緒に作り上げていくんですね。そして30分くらいの時間は同じくらいですが
シン・ジョンギュ 後半の20分は人に例えると鍛え上げるのに使います。どう鍛えるかやってみますね。
ロ・ジョンソク 私も仕事してみて感じるのが、前に必ずしも必要なくてもいつも新しくセッションを始めても全部読み込んでから数ターンの会話を敷いておかないとコンテキストから外れて別の方向に行ってしまうんですよ。だからそのalignmentする時間が最初にしっかり使うことになるようです。
シン・ジョンギュ 後で参考にできるように保存して読み込む機能を追加してそれをエージェントおよびskillが使えるようにしましょう。こうする理由は毎回ウェブで調査すると時間がかかるから。これはどこに保存しましょうか？
チェ・スンジュン 一種のcacheを作っておくわけですね。referenceと呼びますね。こうすると調査したものを全部そこに入れて
シン・ジョンギュ 以降作る時も、以降何か文章を書く時もその内容を基にすることになる。あれを自動でアップデートしたり新しい内容があるか検索して追加するようなcommandを作ってもいいしエージェントを作ってもいいですね。鍛え上げをやってみます。
続けて打つとqueuingされるんですよ。だから普段は私がずっと打ちます。これを基に作るには一度出て入り直さないといけないんです。なぜなら今作ったskill setとかはデフォルトで認識されていないんですよ。こうやって出て入り直します。出来たら。出来たら。ジョンギュさんはこのClaude Codeやあるいはこういうの使う時
ロ・ジョンソク 外部で作られた追加のharnessってあるじゃないですか。TDDでガンガン鍛えるとかあるいは仕事を大量にやらせるようにするとか仕事を分割して分散させるとかそういうのは主に使わないんですか？
シン・ジョンギュ 一切使いません。私は自分の仕事を減らすことが目的なので。どうせ私がチームに強調しているのもそれですし、さっきこう打つと出てくるこのdev-workflowというのはあります。Lablupで複数人が協業する場合に統一すべきことを揃えてくれるharnessはありますがそうではなく、できるだけ自分が処理したい仕事や自分の仕事を軽減する方法から始めることを勧めますね。skillを敷いて今もさっきある仕事に
ロ・ジョンソク 背景をずっと敷く作業を最初にしたわけですがそういうことも自分の頭の中にある目的性と明確に最低限のalignmentが取れる程度にseedingをされる、こう考えればいいですね。不要なものをあれこれ追加しない。
シン・ジョンギュ これをご覧の方の中でコーディングされる方は感じると思いますがすごくコーディングに似ています。自分がコーディングする対象が、言葉でまずプログラミング言語の代わりに言葉でコーディングするんですが言葉でコーディングする対象が自分がコーディングしたい最終目的地ではなくコーディングするやつを作るんです。その観点で見ると非常に明確に理解できると思います。でも今みたいにこうやって一つの流れで進む時は
チェ・スンジュン 認知負荷はあまりないんですが、問題は欲が出るので並列で人が複数やっているのが問題なんですよね。
シン・ジョンギュ 私の核心は多角的な批判を自分自身にさせることです。そして批判を自分自身にさせてその結果を変えるんじゃないんです。結局今1日に1回か2回ずつ回っているharnessの自己アップデートと言えばいいですね。
ロ・ジョンソク これをうまく使えばいくつかのharnessを重ねればそれが会社ですよね。うちの会社の最近の業務方向がそれですがこの単位業務harness、そしてそのharnessを制御する上位harness。このプロジェクトは私たちが非常にシンプルに始めましたがやっていくと複雑になるじゃないですか。そうするとジョンギュさんがエージェント単位で分けてそれぞれ仕事を分担しなきゃいけないというその単位の大きさはどれくらいですか？
シン・ジョンギュ 私は個人的に決めているルールがあって、コーディングの場合はファイル単位で決めているものがあります。では、初稿を私が一度読んでみます。一緒に読んでみましょう。こんなに平易だと正直言うことがないんですが。
チェ・スンジュン とにかく重要なのは直接手を出すのではなく生成する仕組みを直す方向にまず向かうということですね。自分が直接最終成果物に手を触れないということですね。
シン・ジョンギュ 触れたくてもできるだけ触れず、必ずそれを作るやつをずっとiterationを、iterationも私がやらずiterationをやれという指示を出してずっとアップデートしていく形で。それでこうやって成果物を出すケースが一つあります。
二つ目に、自分がもともと送っていたメールがあればそのメールをそのまま渡してください。このメールを作成する時に使う語調とかあるいは作成方法とか扱っている内容の方向性を抽出しろと指示した上でそのように作成するようエージェントを修正しろということですね。それで修正した部分はこうなりました。この人はskillだけでやるつもりみたいですね。
あ、sub agentと明示的に書きましょうか？sub agentをわざわざ作る理由は並列作業のためです。
ロ・ジョンソク sub agentを何個くらい回すつもりですか？
シン・ジョンギュ 場合によりますが、大量に処理する時は同時に50個ずつ回したりもします。
ロ・ジョンソク 一つのharnessからsub agentを50個forkするんですか？
シン・ジョンギュ 特に同じ作業で一つの単位が小さくないといけないもの、例えばドキュメント100個を翻訳してくださいみたいなものがあれば1エージェントあたりドキュメント4つずつ並列で作業してくださいという形にしないといけないんですが、なぜ数を指定するかというとそうしないとcontextが爆発して落ちるケースがあるんです。翻訳作業の場合はこれは経験則で、だからできるだけ1エージェントが4つずつだけ担当するようにしてください。そうすると25個同時に立ち上がりますよね。
ロ・ジョンソク これは今、簡単なプロジェクトを設定して見せてくださっているからそうですが、大きなプロジェクト、例えばBackend.AI:GOもまさにこのflowでやっているんですよね。
シン・ジョンギュ そうですね。こういうのが非常に高度化されているんですよ。だからそこでは定期的に回しながら
Backend.AI:GOの自動化開発パイプライン 54:46
シン・ジョンギュ GitHubのイシュートラッカーに新しく登録されたイシューがあればそのイシューを検証して、あるいは現在のコードをベースにどう実装すべきかground planを立ててキューに入れて、キューに入れたものを後で別のやつが拾ってそれを実行してという形で作られていますね。
でもこれは複雑なツールを使ったのではなく全部ただのcronです。Claude -pオプションがあるんですよ。promptをそのまま実行する、それから使うエージェントとかそれを指定するオプションがあります。それで15分ごとに回しているんです。そういうイシューを見つけて回すコマンドを作りました。
新しく入ったイシューを見つけて、どのskillを使ってイシューを検証してということをずっと作るコマンドを作って、Claude -pではそのコマンドを実行させる15分ごとに定期的に、そういう仕組みです。
チェ・スンジュン イシューは誰が上げるんですか？イシューは色々な方が上げますよ。だからしばらくするとこれが自動化されれば
シン・ジョンギュ メールを送るのは自動化されることになりますし、pull requestの場合は764件が処理されていますね。
ロ・ジョンソク よく働きましたね。それでこういう形でイシューが発行されると、
シン・ジョンギュ 例えばこのイシューの中で私が発行したイシューがいくつか出てきてうちのジンウォンさんがイシューを登録してくれた、こういう形で登録してくれたらオリジナルのイシューはこうやって登録してくださったもので。これが全部イシューを登録してくださったもので、これをClaude Codeが読んでどうすべきかを分析したんです。イシューを登録して、このイシューが登録されると
ロ・ジョンソク 誰が拾うんですか？
シン・ジョンギュ cronで拾うように作ったやつが拾いますよ。そいつがこうやって拾って、それを開発するんですよ。自分で検証してOKなら
ロ・ジョンソク そのまま勝手にmergeしてPRを上げるんですね。場合によってテストをたくさんやらないといけない、
シン・ジョンギュ そうするとテストを自分で回して、そのフィードバックをまた別の開発するやつがそれを解決する形で。多く見えますが
ロ・ジョンソク 実はエージェント同士でやり取りしているんですよね。でもイシューの出発点は人間なんですよね。
シン・ジョンギュ 人がやる時もあるし、完全に任せる時もありますよ。
ロ・ジョンソク 今残っているイシュー、未処理のイシューが例えばほとんど全部ジョンギュさんのIDになっていますがあれは人が書いたものですか？私が回しているからです。
シン・ジョンギュ GitHubに付いている機能ではなくこれを回しているIDが私のGitHub IDなので全部私に紐づいているんです。例えばここを見るとこれはAIが直接書いたものです。このepicは、そのこのepicの前に作ったのが全画面のスクリーンショットを全部撮る機能が追加されるんですよ。自分が自分を見られるように、それをもとに改善できるものを全部洗い出してイシューを全部別途発行しろと指示したもので。だからここを見るとサブイシューがこうなるわけです。それからこれは一度finalizeされて、
テストを一度回さないとということでテストを回しているところです。セキュリティイシューがあり得る部分がいくつかある、あるいは最適化できる部分がある、そうするとその部分を回してどんどん追加していく方式です。こうやってただ自動化されている状態ですね。
チェ・スンジュン この中で実際に読まれるのはどれくらいですか？イシューは全部読みます。イシューが解決されると
シン・ジョンギュ そのイシューについて私が読めるようなreportを作るようになっています。私がこれを例えば読まないといけない、そうするとこういう形で1月16日に作成されてこういう問題があった。問題はそうで、本来はイシューごとに全部残すんですが読んで消すケースが多いですね。必要なければ。それでセキュリティ評価をして、性能はどうだった、品質はどうだった、技術的にどんな判断をした、実装はBash変更して、ローカルやって、Pythonも変更して。私が人間としてこれについていくために
これは学ばないといけない、これを指定しておいてやったんですよ。これを勉強しろと。このtech reportは私への報告用途もありますが、これが行う技術的選択を私が知らないこともあるじゃないですか。ディテールを一つも。そういう場合に、何を勉強すべきかを裏で教えてくれる機能もあります。
tech report - AIが人に学習課題を出す 58:44
シン・ジョンギュ こうやって実際にはコーディングこれしかやってないのに報告書がこれだけあります。今見せていただいている
ロ・ジョンソク このworkflow、ジョンギュさんが作られた仕事の流れがここにBackend.AI:GOが付くのではなく財務が付いてマーケティングが付いてコンテンツが付けばこうやって会社が回っていけるわけじゃないですか。そうですね。うちの場合
シン・ジョンギュ 例えば技術事業報告書、技術事業今年の事業計画書を書くじゃないですか。事業計画書も去年までは人が書いていたんですが今年からは人がずっとdiscussionをするものの書くこと自体は人がやらないんです。なぜなら私たちがreferenceを例えば250を超える文書を全部投げたんですが、マークダウンに変換するツールも作ってそれを基にして継続的に整合性の検証をして、それから2026年今年の今月なら2026年2月のニュースも継続的にクローリングさせてこの方向性が合っているか、以前予測したもののどれが当たってどれが外れたかも判断させて、今年の技術事業計画書をどう修正すべきか全部提案してくれて、そうやって継続的にself reviewを回して私たちとdiscussionをするポイントを残してくれる形でやっているんですが、
これは私と例えばCFOが使っているんですよね。CFOはコーディングができません。でも今はcommitされてますよ。syncというコマンドを作っておいたので。
ロ・ジョンソク superviseされているんであって、仕事は全部AIがやっているんですよね。Claude Codeが一緒に分担してやっていますよね。
非開発職のAI適応 - CFOとコンテンツ担当の事例 60:00
シン・ジョンギュ こういう形になっていて、何を勉強しろと。それで勉強たくさんしてます。しかしこのworkflowも
ロ・ジョンソク いきなり「おい、こういうの作りたい」一行で始まったわけではなく、最初に見せていただいたようにこうやってディテールをstep step stepと踏みながら自分が求める目的性とエージェントがやるべきことのcontextを基本に忠実に合わせる、そういうプロセスを全部やられたんですよね。実はそれが重要なポイントですよね。
シン・ジョンギュ 新しく作り始めてからはかなり経ちましたね。とにかく自分の手に合うように作るのが私は一番優先だったんですが、最近Claudeのマーケットプレイスという機能ができたんですよ。プラグインマーケットプレイスといって、こういうharnessをまとめて公開する機能ができまして。それをベースに使いたい方は使ってくださいと社内のみinternalで公開しています。この社内システムとかなりcoupledになっている部分があるので。ここでビジネス的な質問なんですが、
ロ・ジョンソク 今、代表がこういった思想であったり実装であったり世の中のどういう方向性と今これがどこまで作ってくれるかを全部わかっているからこれが一気にパッと出てきたわけですが、組織がこれについてくるスピードはどうですか？皆さん優秀な方ばかりの会社だとはわかっていますがそれでもやはり体感できる方もいれば適応できない方もいて中でもこの差があると思うんですが、人間同士の間で起きている変化はどうですか？それがちょっと気になります。
シン・ジョンギュ おっしゃる通り人によってかなり違いますし、また幸いにも良い方々をたくさんお迎えして一緒にやっているのでむしろ大変な時期を過ごされている方もいますね。なぜなら自分が得意だと思っていたことと自分が得意でなければならないことが以前は同じだったのにある瞬間からずれてしまったわけじゃないですか。でも良い点としては普段からこういう話を社内でよくしているので、セミナー形式だったり、あるいは通りすがりにご飯を食べながらずっとこういうテーマで1年近く話し続けていたら危機感で終わるケースよりも今はなんとか適応しようとされていますね。仕方がないですから。以前得意だった方がこれ以降も得意になるという保証は当然ないですよね。むしろゼロから始める方がうまくいくケースもありますし、それは私たちも感じているんですが。同時に感じるのは、それは今の時点での話じゃないですか。じゃあ3ヶ月後もそうかというと、それはわからないですね。なぜならAI、私たちは社内でただ2ヶ月と言っています。今うまくいかないなら今はうまくいかないんですが、すぐやらなきゃいけないことでなければとにかく後回しにしろと。それが実は社内で広めるのが一番時間がかかった概念なんです。最近それを受け入れたのがうちのCTOなんですが。私がずっと後回しにしろと言うので、今できないのにと。前にもそうやって一度後回しにしたことがあったんです。それで少し前にブチ切れまして、いつまで後回しにするんだと。それで4.6が出たから今やってみてくださいと言ったら、やってみて「もうできますね」とすごく悟りを開かれましたね。
チェ・スンジュン 覚醒ポイントですね。その時に覚醒して
シン・ジョンギュ HWP全体をdisassembleしてしまいました。それで社内ではHWP文書は人が使わないんですよ。サービスとして早く作って提供するのも
ロ・ジョンソク 我が大韓民国の公務員社会のために良いんじゃないですか？わかりません。果たして良い結果をもたらすでしょうか？
シン・ジョンギュ 皆さんそういうの一つ二つ持っていると思いますけどね。
ロ・ジョンソク そうですよね。それが皆会社で隠している一つずつのTipsですよね。ちょっとしたTips。なぜならそのちょっとしたTipsを得るのにかかる時間があるじゃないですか。その時間の優位性が今は会社の優位性として働くケースがかなり多くて、skillマーケットプレイスからダウンロードしてビジネスが丸ごと終わってしまうのではなく何か隠しておいた三文四文はないと生き残れないですよね。私が思うに、これは人々が
シン・ジョンギュ Claudeをどれだけ信頼するかの問題であってツール自体が重要なわけではないと思います。誰かが「ねえ、HWPを解析してこれを編集したりするものを作れる？」という疑問を持って質問を投げかければ、その方が答えを得るのにそんなに時間がかかる問題ではないんですよ。
Lablupのコア価値はどこへ移動したのか 63:49
ロ・ジョンソク ここでジョンギュさんにこの質問をしてみたいんですが、ちょっと自己矛盾的な質問かもしれませんが、Lablupという会社自体が、そういう高度な知識と時代に対する先見性とそして優れた実装者たちで構成された会社が強みだったじゃないですか。でも今おっしゃっていることを見ると
Lablupという会社自体でもかなり多くの、これまで自社の唯一の強みだと思っていた部分がワンクリックで消えた経験を多くされてきたじゃないですか。では今、会社の立場として「何がなくなって我々の会社としての価値はここにある」と定義された部分があると思うんですが。ここに進まなければ生き残れない、と。
シン・ジョンギュ ありますね。最大の変化は、例えば我々が今作っているプロジェクト、プロダクトをほぼ10年間磨いてきたじゃないですか。asyncioがなかった時代から作り始めたツールなので、例えば今の現代の技術と現代のAIで我々のツールをゼロから全部作ったらどれくらいかかるか。今知っていることを全部知っている状態で、それなら3ヶ月で作れると思います。あの数多くの例外やその問題を全部知っているので。知らない状態だとどれくらいかかるか、それはちょっと難しいですね。なぜなら、あの数多くの例外は実はほとんどがインストール環境の多様性から生じるものなんですよ。想像すらできないような部分があるんですが、会社の今年の目標、特にfast trackと呼んでいる
MLOpsと内部のBackend.AIコアの目標は人間のためのインターフェースではなく、AIのためのインターフェースに注力しています。私たちにはCLIもGUIも全部あるんですが、
AIのためのインターフェースへの転換 65:20
シン・ジョンギュ 根本的な疑問、去年の下半期、去年の冬に共有したのはこれは果たして人間が使うツールなのか。将来も。そういうことなので、できれば今年上半期中にAIが最もうまく扱えるツールにしようというのが目標です。
ロ・ジョンソク 顧客の定義を、人間ではなく人間より賢い、あるいは人間から何かの作業を委任されたエージェントが我々をツールとして呼びに来ると考えているわけですね。
シン・ジョンギュ 例えばskillを一緒に配布するとか、そのエージェントが読み取って使えるようにする、そして内部的に使っている様々なものをAIがもう少し理解しやすい形でより出力するとか、あるいはCLIで任意のコマンドを自分がよく知らなくても推測できるようにするフォーマットに合わせるとか、そういったものが一つ目の変化ですね。我々がモデルを作ることが目的であって、例えばBackend.AIでモデルを訓練するとしたらモデルを作ることが目的であって、リソースをどう割り当てるかはワンクリックでできるようになれば重要ではないじゃないですか。「おい、何々を超えるモデルを一つ作ってくれ」と言えば自分で勝手にやってくれるのがいいですよね。いくらぐらいかかりそうか、費用はどれくらいか教えてくれればいいんです。そこに焦点を合わせるのが一つ目の変化で、二つ目の変化は先ほど申し上げたように
ソフトウェアの定義が私たちから見て変わりつつあるとご説明しましたよね。コードが中心にあるのではなくモデルが中心にある。それでまさにBackend.AIの核心は何かと言えば、Backend.AIのコアもモデルになるということです。これはfoundationモデルではありませんが、AIリソースを非常にうまく管理して特定の業務を処理できるモデルです。そしてそのモデルの規模が様々な場所で様々に動作できなければならないとして、研究チームでモデルを作っています。そしてそのモデル自体が
Backend.AIが今、例えば実行環境、RAMいくら、CPUいくらといったスペックがあるじゃないですか。ソフトウェアが動作するためのスペックのようにCUDAメモリいくらがあって、このシステムを実行すること自体がそのスタートアップパイプライン自体にモデルランタイムが組み込まれた形が次のメジャーバージョンでテストされ、正式版はその次のメジャーバージョンで、そうなると思います。完全にAIモデル自体をBackend.AIエンタープライズの一部として想定するわけですね。それがやることは、Backend.AIが元々やっていたことを多くこなすわけです。進化しようと努力しています。進化に関連して思い出したんですが、
チェ・スンジュン ソーシャルメディアにたまに投稿されるサイバーフォーミュラの例えですよね。
サイバーフォーミュラ比喩 - Claude Code vs Codexの哲学差 67:49
チェ・スンジュン それについて少しお話しいただけますか？人間の増強の部分。
シン・ジョンギュ 最近よく投稿していたのがそれなんですが、私がCodexとClaude Codeを両方使いながら感じた違いがそれだったんですよ。Claude Codeはできるだけ私に聞こうとするように設計されていて、一方でCodexは私をあまり信用しないんです。聞いていると感じるのが、自分が正解を知っているからお前はこれを信じろという感じで、それが両社の哲学がにじみ出ているんだなと思うこともあります。Claude Codeを見ると発展してきたのが、例えば何か選択が必要なとき四択、三択を作ったり、選択式にして提供したりする仕組みも作って提供していますし、最近ではもう次に私がする質問をあらかじめ完成形で提案してくれたりするじゃないですか。タブを押すだけで次の質問が出るように。そのように私の意思をもっとたくさん聞いて、alignを合わせていく、人間が曖昧に持っているコンテキストをもう少し明確に把握してその方向で動作しようとする形で進化していて、Codexは、ざっくり説明すると俺が全部やってあげるよという方向で進化しています。そして実際にそうやってうまくやるんです。最高値がどちらが高いかと言えば、私は100% Codexが最高値がもっと高いんです。でも人が快適に感じるのはClaude Codeですよね。なぜならClaude Codeはそのプロセス自体を僕と一緒にやるから。
僕が子供の頃に流行ったアニメがあるんですがそれがサイバーフォーミュラというものだったんですよ。レーシングなんですがAIと一緒にレースする主人公がいて、そのAIが最初はバカみたいで、運転も下手だったりするんですが、主人公もこのAIに頼って運転を学ぶようになり、AIもその過程で人がミスをするところからヒントを得て、新しい方法を作り出したりして一緒に共進化していきます。各シリーズごとに解決する問題が違うんです。
人間とAIが共進化するという概念で例えば人間としてはるかに優れたドライバーをどうやって倒すかというテーマがあり、次に人が経験したことのない領域に入った時それをAIがどう補助して解決するかというテーマがあり、その次に完全にAIに置き換わって、AIが運転する相手にはどうやって勝つかというふうにテーマが移っていって、一番最後だけ主人公が変わるんですよ。車を一台誰かが貸してくれるんですが、さっきの前シリーズで人に薬を飲ませてAIに完全に運転させていた車を作った人が自分の兄が作った車だと言って車を一台くれます。これでやれと。AIの言う通りに運転だけするように元のモデルは完全に人を信用しないんです。人は運転が当然できない存在だ、だからAIが運転するのが当然上手い、ということでこの頃には人がこうしてくれるべきだろうと判断して操作するんですが、人はその動作についていけないからしょっちゅう事故が起きるんですよ。でも主人公が変わった主人公ですよね。その車に乗ってものすごく苦労した末に最後は勝つんですよ。その主人公はAIについていけるほどの能力があったわけで、AIは勝ちたくて、未来はどうでもいいからとにかく勝たなきゃと思ってある意味、負けず嫌いになったAIと言えますね。
それまでは目的を持ったAIの話をしていたんですが、僕がそのシリーズを昔見て感じた考えが最近よく浮かぶんです。負けず嫌いを持ったAIとは何だろう。普通AIに欠けているのは意志なんですよ。僕たちがagentic codingをする時人の役割はどの方向に何をすべきか指示することじゃないですか。そうするとそれを忠実に、愚直にうまくやります。でもなぜそれを忠実に愚直にコンテキストを理解できないままおかしなことを時々するかというとそのエージェントには明確な目的意識がないからなんですよ。でもそのアニメでは目的意識を持つようになったAIが良い人に出会えればそのAIと共進化した人を倒せるという結論なのでそれが最近よく頭に浮かびます。特にCodexを見ると。じゃあその最後に勝った車がCodexということですね。
ロ・ジョンソク そして元々あったのがClaude Code、そういう比喩ですね。
シン・ジョンギュ 両方ともそれぞれ違う方向に進化はしましたが、元々昔の主人公が乗っていた「アスラーダ」という車はずっと一緒に進化を遂げていき、空から降ってきて自分が最高の走りができると思い込んで人を理解できないAIは「オーガ」という車なんですが、これはCodexの動作と似た感じがしますよね。ある意味AIを作ったりこういう装置を作る人たちの哲学だったり、設計思想が少し入っていたりもしますし、そういったことですら僕たちがほぼ100年かけて積み上げてきたSFだったり、様々な種類のメディア、文学、アニメ、映画、そういったもので何度も扱われているのが面白い、
そう思いました。論理的に考えても、そのシミュレーションがある確率の高い未来のように感じられたでしょうね。作家の立場からすると、数多くの議論と思考実験の末にそういうシナリオを設定したはずですから。映画やマンガやそういったものも私たちが考える未来の方向と似ているのも面白いですよね。
AI時代スタートアップの機会と水車論 72:47
ロ・ジョンソク 質問をあと一つ二つだけして締めくくらないといけないんですが、淡々とさっきお話しいただきましたけど、Lablupが10年間積み上げてきた蓄積の時間とそういった資産がいくつか暗黙知として意味を持つようになり、残りはワンクリックでできるレベルになったというのが面白くもありますが、会社としては悲しい現実でもありますよね。僕は悲しいとはあまり思わないんですよ。
シン・ジョンギュ 会社としてはそんなに悲しくないと思います。人としてはちょっと悲しいですけどね。例えば起業をした。自分がこれだけの努力をした。そういう状況で、昔はあんなに大変だったのに今はすごく簡単だなと。それがテキストキューブを作ってからBackend.AI:GOを作る時に感じたあの気持ちがあるわけで、会社としてはこれをどう受け止めるべきかと言えば会社としてはオーケー、サンキューという感覚だと僕は受け止めています。
ロ・ジョンソク なぜそう思うんですか？二つあります。一つはまず幸いなことに
シン・ジョンギュ うちの会社は適応がとても速い方で、こうやって盤面がひっくり返る時はスタートアップの方がはるかに有利です。スタートアップでもあり、それが強みですよね。僕たちが積み上げてきたものと同じくらい僕たちがターンアラウンド、あるいは軌道修正をもっと速くできるということ。そしてそこに全体が適応していく時間が他のところよりも速いだろうというのが、それがチャンスとして新しいチャンスとして機能し得るというのが一つで、スタートアップの立場からすると市場が安定的で固定されている状況が一番よくないんです。どうにかして盤面が揺れる時がいいし、どうにかして新しいチャンスが出てくる時がいい。もし僕が今、既得権側の立場だったらどうしようと言えるかもしれませんが、僕から見てうちはまだ持っているものがないんですよ。技術しか持っていないのに、技術がleverageされる状況をどうするかと。僕から見てうちはものすごくうまく適応していると思いますし、モデル開発についてもものすごく、うちのBackend.AIをモデル開発なども大規模に行っていますし、そうなると、この未来に何が必要かについてもより早く作り始めたのだと思います。
次に二つ目はブランドの話です。結局この業界が揺れているのは、いつか落ち着くでしょう。今まで全てがそうであったように加速区間は永遠に加速し続けることはできません。ただ、その未来が例えばAIが私にベーシックインカムをくれてそれだけもらって暮らす時代ではなく別の種類の状況が開かれるとすれば、結局その状況で最終的に到達している位置がその後の位置とほぼ同じになる可能性があるんです。例えば服を見てみましょう。今化粧品を作られているので、化粧品も同じですが重要なingredientだとか、技術的なイノベーションだとか、そういうのもありますよね。しかし原価の面から見たときそこまで差は出ないじゃないですか。全ての化粧品が、全ての服が。例えば私がハンドバッグを買うとしたときこのハンドバッグが本当にあのハンドバッグより千倍の価値があるハンドバッグかと言えば、違いますよね。明確に現れるのはコンピューターです。Appleがそれでも一番良いコンピューターだと言われますが他のコンピューターと価格が10倍20倍も違わないじゃないですか。原価がとても透明だからこそ、だからこそ結局は似たようなツールが多く、似たような仕事をすると主張するツールも増えていく可能性がありますが、結局はまたブランド、そしてこれまで積み上げてきたトラックレコードが核心的な競争力となる時代がもう一度来ると思っています。
その点において私たちは長い間いろいろな面でよく守ってきたと思っていますし、その過程で見失わずに適応できれば。昔のことを思い出しますね。「Brand Yourself」のようにブランドが核心的な競争力となる時代がおそらく安定期にはまた来るでしょう。だからこそ私たちはとても良い機会だと見ていますし、ただ個人的には悲しいのは事実です。個人的に悲しい点、この10年を先に経験してきたこと、
ロ・ジョンソク そしてすでにフロンティアモデルが多くのことを知っていてワンクリックで作れる領域もありますが、実際は様々な苦労を重ねながら代表と会社が積み上げてきた一種の暗黙知、他の人には絶対にわからないそういったものが堀として機能していて他の人には入れられないコンテキストとして機能していると見ればいいのでしょうか？
シン・ジョンギュ 基本的に私たちのソリューションは安定したハードウェアで安定したワークロードを回すためのソリューションではありません。GPUは非常に不安定ですし、ネットワークも含めて、特にNVIDIAやAMDやこうした最新エンタープライズGPUになるほど不良率も非常に高く予測できないことが多すぎます。結局はちょっと面白い構造なんですよね。不安定なハードウェアも信用できず、
その上で動くモデル訓練ソフトウェアも全てが信用できない状態でそれらを信用できる状況であるかのように運用してくれるソリューションなので質が違うと言えますね。それが少し強みですね。そういったことは結局どれだけ多くのedge caseを踏んできたかという核心的な競争力であり、自動運転と少し似た面がありますね。
ロ・ジョンソク Teslaの話を先ほどされましたが、Teslaで見られるものだとかあるいはLablupが会社として経験してきたこの10年のこと、そしてこのAIに参入したわけですが私たちも皆不安ではありますが、積み上げてきたものをどう優位に変え、ブランド資産に転換して結局は自分たちが勝てるのか、そういう戦略の面では非常に良い事例になると思いますし。そしてこれがソフトウェアだとか
先を行く、少なくともAIの影響を最も受ける業界でこういうことが起きているので同じ形で他の産業にも似たようなことが起きるでしょう。まるでClaudeが入ってきて法務や財務、そういったものも片付けるように。今話しているこの会社のダイナミクス、一体会社の価値はどこから来るのか、こういったことも他の産業にも同じように広がっていくのではないかと思います。
スタートアップに最も良くないこと - 複製の時代 78:20
チェ・スンジュン スタートアップにとって一番良くないことは何ですか？スタートアップにとって一番良くないのは停滞ですね。
シン・ジョンギュ 一般的に現在のスタートアップのことですか？
チェ・スンジュン 今のAI業界やIT業界を含めたとき、スタートアップにおけるブランド価値だとかあるいは経験を積んできたこと、そして状況が揺れ動くことがある意味では危機でもあり機会にもなり得るわけですが、それならスタートアップにとって良くないことは何かという疑問が湧いたんです。
シン・ジョンギュ あらゆるアイテムの複製がとても簡単です。複製されないものは何かという問いに対してタイミング的なものだとか
ロ・ジョンソク あるいはアイテムの組み合わせだとかそういったもので答えられなければ他の人のワンクリックに飲み込まれる可能性がありますよね。
シン・ジョンギュ 最近Facebookである方がNotebookLMを複製するのに4日かかったのを見て、とても多くの気づきがありました。NotebookLMの全画面のスクリーンショットを全部撮って、機能説明をずらっと書いて投げたら4日ほどでクローンが出来上がったと。そういう時代なので、スタートアップを従来のアイテムの選び方でアイテムを選ぶと複製がとても簡単です。それが一番大きいことでもありますし。逆に複製がアイテムである会社はとてもうまくいくでしょうね。
ロ・ジョンソク ただ多くの賢い人たちが皆、他の人がやったことを素早く追いかける方向でbetter, faster, cheaperという選択をするんですよね。でもそれが資本の優位性だとかあるいは出身校の優位性とかでより優れたtalentを採用できるとか、そういったものでこれを全てコントロールできるか、あるいは主導権を握れるならそれは意味がありましたが、今ではそういうリソースを皆が持っている世の中なので複製、複製するだけでは顧客がこっちの方が優れている、こっちがまあまあいいなと思ってもらうのが難しい世の中になったと思います。何かそれ以上のものが必要です。その「それ以上」について、またきっと出てくるでしょう。
その「それ以上」について私たちもこういったことをしながらずっと探し続けているじゃないですか。私が今見つけたのは、少しのタイムギャップと暗黙知ギャップ、この二つがうまく組み合わさって、早くこの顧客を取り込めればもちろん誰かのワンクリックでなくなることもありますが、ワンクリックでは済まない、一度顧客のデータを握ってしまえば顧客が他に移りにくいものがあるんですよ。そういうもので事業的な視点を考えなければならない時期だと思います。
チェ・スンジュン ワンクリック耐性、アンチワンクリック、そんな言葉が浮かびますね。お伝えしたいのは、Googleスタートアップキャンパスというところがあるんですが
シン・ジョンギュ そこで以前講演をした時に使った表現なんですが私は結局ビジネスというのは水車をどこに設置するかの問題だと思っているんですよ。落差が大きいところに水車を設置して水車を速く回して、水が落ちそうになったらうまく移設するか別の方法を取るかということなんですが、先ほどロさんがおっしゃっていたそのタイムギャップが最も多く発生する部分はIT分野の中ではないと思うんですよ。
IT plus somethingまで当然遅れてついてくるしかないんですが、従来は当然これがIT領域にはならないだろうと思っていたけどAIがcontextを解釈できるようになってITの領域に入ってくる部分、入ってくる分野、そういう分野に水車を設置するスタートアップがうまくいくんじゃないかと。最初にご質問しましたよね。
ロ・ジョンソク うちの子が兵役を終えて大学に行くんですが一体どんな勉強をさせるのが今一番安全なのかという話をしていたんですが、代表がその話をされたんですよ。そのドメインにいる人たちがこのようなAIやそのシステムに関する知識を学ぶよりもこのAIシステムやこういったことに詳しい人たちがドメインを学ぶ方がはるかに速いだろうとおっしゃって、今むしろ逆説的ですがコンピュータサイエンス、CSをやるのがいいんじゃないかというお話をいただいたんですがそれとも少しつながっている話だと思います。つまり、ドメインにいる方々は早くCSを学ぶべきで、CSの方々は早く適用できるドメインのタイムギャップを見つけるのがシン代表がおっしゃった水車論にぴったり合うんじゃないかと思います。代表、その話でさらにお話しされることがあれば
コンピュータ工学不要論への反論 82:19
ロ・ジョンソク ぜひお願いします。コンピュータ工学科無用論、こういうのがたまに聞こえるんですが私から見ると少し面白くて。なぜかというと私は2000年入学なんですが、私はコンピュータ工学、物理学科でもありますがコンピュータ工学科でダブルメジャーをしていたんですが授業に行くとコンピュータ工学科出身の教授があまりいなかったんですよ。なぜかというとその上の世代にコンピュータ工学科がなかったので、コンピュータ工学科の教授になるということは他の学科でコンピュータをよく使っていた方々が学問を作ったんですよ。そうなると化学科出身もいましたし、材料科出身もいましたし、物理科出身もいましたし、コンピュータ工学科が初期に作られた所に教授が来られて、今はほとんどがコンピュータ工学科という単独の学科で訓練を受けた方々が教授でもありますよね。
シン・ジョンギュ これが何の話かというと、コンピュータ工学科は最初から方法論的な思想を持って始まった部分が半分で、コンピュータ科学、コンピュータ工学と分けたりもしますが基本的には非常に新しい学問だということです。他の多くの分野に比べれば相対的に。だからこそ私は変化の速度もとても速いだろうと見ていますし。いつまでPythonを学ぶ学科、Cを学ぶ学科、アーキテクチャやOSを開発することを学ぶ学科、これらは学び続けるでしょう。非常に重要なので学び続けるでしょうが、私はこの形のままでは続かず例えばニューロコンピューティングとかあるいはモデル開発でそのモデルの核心が何で、attention構造が何で、他のものを作ってみるとは何で、こういったものも最近多く入ってきていますよね。実際にディープラーニング概論のようなものも授業カリキュラムに入ってきているのである意味そのような変化に最も早く適応できる学科がコンピュータ工学科だと思います。私は物理学科にもかかわらずそう思っていますし、もちろん物理学科は最近行き先が増えてきて良いですね。
そのような過程で人々がAIが全部やってくれるからコンピュータ工学科で学ばなくていいんじゃないか、自分がコンピュータにAIにやらせればもっと早くできるんじゃないかと言いますが実際に私の周りでそういう業界にいる方々に聞くと逆方向の心配の方が多いんですよ。例えばAIが全部やってくれるから自分のやることがなくなるんじゃないかと、映画を撮るのもSeedanceが動画をあんな風に作ってくれるのに、映画監督は、映画撮影監督は何をするんだ、こういう危機感を感じるということ。そのように恐らくこれから5年ほどはITが、もちろん今までもかなり入ってきていますし使われていますが、とてつもない規模で社会全般の核心に非常に多く入ってくる時代になるだろうと思います。短期的には、プログラミングを学んで何になるんだ、プログラムは全部コンピュータが書いてくれるのにと言いますがコンピュータ工学科で学ぶのはプログラミングじゃないんですよ。その中にあるロジックを組み立てる方法です。ロジックを作り、最も単純なゲートロジックがどう発展して数多くのロジックへと発展できるのか、その方法論や哲学とでも言うべきでしょうか。そういう思考構造を学ぶことに近いと私は思っているので、そういう方々が他の分野を学ぶのも速いかもしれない。特に知識をアウトソーシングできる時代になった状況ではなおさらそうだと考えています。こうお話ししていますが
ロ・ジョンソク ここに蛇足を必ず付けておかなければならないのが、2ヶ月後には変わる可能性があります。disclaimerを必ず付けておきたいと思います。
締めの挨拶 85:29
シン・ジョンギュ みんなで手を取り合って、AIとうまくやっていかなければならない状況です。
ロ・ジョンソク 未来に向かって進みますが、私たちはお正月休みですし家族と過ごす時間に戻らなければならないようです。
チェ・スンジュン 長い時間でしたが楽しかったです。今日もたくさん勉強になりました。それでは、連休を楽しんでくださいね。
ロ・ジョンソク またソウルにいらしたらお会いしましょう。
シン・ジョンギュ 残りの連休、楽しい試行錯誤を。