00:00:00[音楽]
00:00:21皆さん、こんにちは。
00:00:22まず最初に、ちょっとした告白から始めようと思います。
00:00:26実は私、自分がリリースしたコードを完全には理解していませんでした。
00:00:29生成して、テストして、デプロイしたものの、どう動いているか説明できなかったんです。
00:00:33ですが、きっと皆さんも同じ経験があるはずです。
00:00:37[笑い]
00:00:40自分たちが理解していないコードをリリースしていると認めたところで、
00:00:41なぜそうなってしまったのか、その経緯を辿ってみましょう。
00:00:44まず歴史を振り返ると、歴史は繰り返す傾向があることがわかります。
00:00:46次に、私たちはある「罠」に陥っています。
00:00:50それは、「簡単（イージー）」と「単純（シンプル）」を混同していることです。
00:00:52最後に、解決策はありますが、それには思考を外部に丸投げしないことが求められます。
00:00:55私はここ数年、NetflixでAIツールの導入を推進してきました。
00:01:00断言しますが、開発の加速は紛れもない事実です。
00:01:05かつて数日かかっていたバックログの項目が、今では数時間で終わります。
00:01:07何年も放置されていた大規模なリファクタリングも、ようやく完了しつつあります。
00:01:10しかし、問題があります。
00:01:15大規模な本番システムは、常に予期せぬ形で故障するものです。
00:01:16最近のCloudflareの事例を見れば明らかでしょう。
00:01:19デバッグする際には、そのコードを理解していなければなりません。
00:01:21ところが今は、凄まじいスピードと量でコードが生成されています。
00:01:23私たちの理解が追いつかなくなっているのです。
00:01:28私自身もそうでした。
00:01:29大量のコードを生成し、それを見て「さっぱりわからん」と思ったことがあります。
00:01:34でもテストは通ったし、動いているからリリースしてしまった。
00:01:39ただ、これは今に始まったことではありません。
00:01:41どの世代のソフトウェアエンジニアも、いずれ壁にぶつかってきました。
00:01:44ソフトウェアの複雑さが、管理能力を超えてしまう瞬間です。
00:01:48「ソフトウェア危機」に直面しているのは、私たちが初めてではありません。
00:01:50ただ、これほど無限の規模でコードが生成される状況で直面するのは初めてです。
00:01:52では、事の始まりまで少し遡ってみましょう。
00:01:561960年代後半から70年代前半にかけて、優秀なコンピューター科学者たちが集まりました。
00:01:58彼らは「今、ソフトウェア危機の中にいる」と宣言したのです。
00:02:03ソフトウェアへの膨大な需要があるのに、供給が追いついていないと。
00:02:06プロジェクトには時間がかかりすぎ、進捗は非常に遅い。
00:02:11「私たちはうまくやれていない」という危機感でした。
00:02:15そこでダイクストラは、非常に優れた言葉を残しました。
00:02:16（長い引用を要約すると）彼はこう言いました。
00:02:20「コンピューターが非力だった頃、プログラミングは些細な問題だった。
00:02:23しかし、巨大なコンピューターが登場した今、プログラミングは巨大な問題になった」。
00:02:26ハードウェアの性能が1000倍になるにつれ、
00:02:31社会が求めるソフトウェアの規模も比例して大きくなったと彼は説明しました。
00:02:34そして、その膨大なソフトウェアをどう支えるかという課題が、
00:02:37私たちプログラマーに突きつけられたのです。
00:02:41このサイクルは繰り返されています。
00:02:4370年代には、より大規模なシステムを書くためにC言語が登場しました。
00:02:4780年代にはPCが普及し、誰もがソフトウェアを書けるようになりました。
00:02:5090年代にはオブジェクト指向プログラミングが登場しました。
00:02:53Javaのおかげで、複雑すぎる継承階層という地獄も生まれましたが。
00:02:562000年代にはアジャイルが登場し、スプリントや
00:03:00スクラムマスターの指示に従うようになり、ウォーターフォールは姿を消しました。
00:03:032010年代にはクラウド、モバイル、DevOpsが登場し、
00:03:06ソフトウェアが文字通り世界を飲み込みました。
00:03:09そして今日、AI、Copilot、Cursor、Claude、Geminiなどがあります。
00:03:10説明するのと同じ速さでコードを生成できるようになったのです。
00:03:17パターンは続いていますが、規模は今や「無限」へと変化しました。
00:03:19『人月の神話』の著者として知られるフレッド・ブルックスは、
00:03:231986年に『銀の弾丸などない』という論文を書きました。
00:03:29その中で彼は、ソフトウェアの生産性を劇的に向上させるような
00:03:32単一のイノベーションは存在しないと主張しました。
00:03:36なぜか？
00:03:38プログラミングの本質的な難しさは、コーディング作業や文法、
00:03:40タイピング、定型文（ボイラープレート）を書くことではないからです。
00:03:44実際の問題を理解し、解決策を設計することこそが難しいのです。
00:03:45どんなツールも、その根本的な困難を排除することはできません。
00:03:49これまでのツールや技術は、作業そのものを楽にするためのものでした。
00:03:52しかし、核心的な課題である「何を構築すべきか、どう動くべきか」の
00:03:55理解は、依然として難しいままです。
00:03:57問題が「作業」にないのなら、なぜ私たちは作業の最適化ばかり続けるのでしょうか？
00:04:00なぜ経験豊富なエンジニアまでが、理解できないコードを抱えることになるのか。
00:04:06その答えは、私たちが混同しがちな「単純（シンプル）」と「簡単（イージー）」という言葉にあります。
00:04:09私たちはこれらを同じ意味で使いがちですが、
00:04:14実際には全く異なる意味を持っています。
00:04:16昨日のディナーで私がClojure好きであることがバレてしまったので、
00:04:18この話は避けて通れません。
00:04:21Clojureの生みの親であるリッチ・ヒッキーは、
00:04:232011年の「Simple Made Easy」という講演でこれを説明しました。
00:04:25彼は「シンプル」を、絡まりがなく、一つの糸であることと定義しました。
00:04:29各パーツが一つのことを行い、他と絡み合っていない状態です。
00:04:33一方で「イージー」は、近くにあり、手が届くことと定義しました。
00:04:36努力せずに手に入れられるもの。
00:04:39コピー、ペースト、リリースです。
00:04:41シンプルは「構造」に関すること。
00:04:43イージーは「近さ（利便性）」に関することです。
00:04:45願うだけで何かをシンプルにすることはできません。
00:04:48シンプルさには、思考と設計、そして「もつれ」を解く作業が必要です。
00:04:51しかし、何かをより「簡単」にすることはいつでも可能です。
00:04:54ただ近くに置けばいいのですから。
00:04:56パッケージをインストールする、AIで生成する、Stack Overflowからコピーする。
00:04:57簡単な道を選ぶのは人間の本性です。
00:05:03私たちはそうプログラミングされています。
00:05:06Stack Overflowからコピーするのは、そこにあるから簡単なのです。
00:05:07魔法のようにすべてを処理してくれるフレームワークも、インストールするだけ。
00:05:10しかし、「簡単」は「シンプル」を意味しません。
00:05:14簡単とは、システムに素早く追加できるということです。
00:05:15シンプルとは、自分が行った作業を理解できるということです。
00:05:18簡単さを選ぶたびに、私たちは「今のスピード」と引き換えに「将来の複雑さ」を選択しています。
00:05:20正直なところ、以前はこのトレードオフが成立していました。
00:05:24コードベースに蓄積される複雑さは十分に緩やかだったので、
00:05:27必要に応じてリファクタリングや再構築ができました。
00:05:31AIはこのバランスを破壊したと私は考えています。
00:05:34AIは究極の「簡単ボタン」だからです。
00:05:36簡単な道があまりにも摩擦ゼロになったため、
00:05:37シンプルな道など検討すらされなくなりました。
00:05:38コードが瞬時に現れるなら、なぜ設計を考える必要があるのでしょうか？
00:05:41実際にどうやってこれが起こるかお見せしましょう。
00:05:44単純なタスクが、愛すべき対話型インターフェースを通じて、
00:05:47いかに複雑な混沌へと進化していくか。
00:05:50これは作り話の例ですが、アプリに認証機能を追加したいとします。
00:05:52「認証を追加して」と言うと、綺麗な auth.js ファイルが生成されます。
00:05:55何度か調整を重ね、5回目くらいのやり取りで形になります。
00:05:57次に「OAuthも追加して」と言うと、auth.js と OAuth.js が出来上がります。
00:06:01さらに繰り返すと、セッションが壊れたり、
00:06:02あちこちで競合が発生したりし始めます。
00:06:0420回目くらいのやり取りになる頃には、もはや対話ではありません。
00:06:07自分ですら追加した制約をすべて覚えていないような、
00:06:11極めて複雑なコンテキストを管理している状態になります。
00:06:12放棄されたアプローチの死んだコード。
00:06:15無理やり動くように修正されたテスト。
00:06:183つの異なる解決策の断片が混在しています。
00:06:20新しい指示のたびに、元の設計パターンが上書きされていきます。
00:06:22「ここで認証を動かして」と言えば、そうなります。
00:06:25「このエラーを直して」と言えば、そうなります。
00:06:28悪い設計判断に対する抵抗は全くありません。
00:06:31コードは最新の要求を満たすために形を変え続けるだけです。
00:06:33一回一回のやり取りで、シンプルさより簡単さを選んでいるのです。
00:06:35そして「簡単」は常に「複雑さ」を意味します。
00:06:38頭ではわかっていても、道がこれほどまでに平坦だと、つい進んでしまいます。
00:06:40そして複雑さは、手遅れになるまで積み重なっていきます。
00:06:43AIは「簡単」を論理的な極限まで高めてくれます。
00:06:46欲しいものを決めれば、瞬時にコードが手に入る。
00:06:50しかし、そこには危険が潜んでいます。
00:06:52生成されたコードは、コードベース内のあらゆるパターンを均等に扱います。
00:06:58AIエージェントがコードを分析する際、すべての行が「守るべきパターン」になります。
00:07:0047行目の認証チェック、これも一つのパターン。
00:07:02私が2019年に追加した、GraphQLのように振る舞う奇妙なgRPCコードも、
00:07:06やはり一つのパターンとして認識されます。
00:07:10技術的負債は「負債」として認識されず、単なる「既存のコード」になります。
00:07:13ここでの真の問題は「複雑さ」です。
00:07:18この言葉を何度も使っていますが、まだ定義していませんでしたね。
00:07:19一番わかりやすい考え方は、シンプルさの対義語であるということです。
00:07:22それは単に「もつれ合っている」という意味です。
00:07:25複雑な状態では、すべてが他のすべてに接触しています。
00:07:29一箇所を変えれば、他に10箇所の影響が出るのです。
00:07:31さて、フレッド・ブルックスの論文に話を戻しましょう。
00:07:33彼はあらゆるシステムに2つの主要な複雑さがあることを指摘しました。
00:07:36一つは「本質的複雑さ」です。これは解決しようとしている
00:07:41問題そのものに付随する、根本的な困難さです。
00:07:43ユーザーが支払いをする、注文を履行するといったこと。
00:07:47そのソフトウェアが存在する理由そのものが持つ複雑さです。
00:07:51もう一つは「偶発的複雑さ」です。
00:07:53これまでに追加してきた回避策、防御的なコード、
00:07:56フレームワーク、かつては合理的だった抽象化など。
00:08:00コードを動かすために積み上げた、あらゆる付随物です。
00:08:03実際のコードベースでは、これら2つが至る所に存在します。
00:08:06そしてそれらは密接に絡み合っているため、分離するには
00:08:09文脈、歴史、そして経験が必要になります。
00:08:11しかし、AIの出力にはそのような区別はありません。
00:08:16そのため、あらゆるパターンが温存され続けてしまいます。
00:08:19Netflixで実際に行っている作業を例に挙げましょう。
00:08:205年ほど前に書いた古い認可コードと、
00:08:24新しい中央集権的な認証システムの間に、抽象化レイヤーを置いていました。
00:08:26アプリ全体を書き直す時間がなかったので、
00:08:32とりあえず「シム（接ぎ木）」を挟み込んだ形です。
00:08:35今、AIを使えるようになったので、このコードを新しいシステムを
00:08:41直接使うようにリファクタリングするのは、簡単な依頼に見えますよね？
00:08:42ところが、そうはいきません。古いコードは独自の認可パターンと
00:08:44あまりにも密接に結びついていたのです。
00:08:47権限チェックがビジネスロジックに織り込まれ、
00:08:50ロールの仮定がデータモデルに焼き付けられ、認証呼び出しが数百のファイルに散らばっていました。
00:08:56AIエージェントがリファクタリングを始めても、数ファイル進んだところで
00:08:59解けない依存関係にぶつかり、制御不能に陥って諦めてしまいます。
00:09:03あるいはさらに悪いことに、古いシステムのロジックを無理やり維持しながら、
00:09:07新しいシステムでそれを再現しようとします。これは全く良くありません。
00:09:10AIには「境界線」が見えなかったのです。
00:09:16どこまでがビジネスロジックで、どこからが認証ロジックなのか識別できません。
00:09:19すべてがあまりにも絡み合っていたため、完璧な情報があっても、
00:09:23AIはクリーンな道筋を見つけることができませんでした。
00:09:26「偶発的複雑さ」がこれほど絡み合ってしまうと、
00:09:30AIは改善の助けにはあまりなりません。
00:09:33むしろ上にさらなる層を重ねるだけだと感じました。
00:09:35私たちはその違いを見分けることができます。少なくとも、立ち止まって考える時間があれば。
00:09:38どのパターンが本質的で、
00:09:40どれが単に数年前の誰かの場当たり的な解決策なのかを知っています。
00:09:45AIが推論できない文脈を持っていますが、
00:09:47それは作業前にその区別をつける時間を取った場合に限られます。
00:09:50では、具体的にどうすればいいのでしょうか？
00:09:53巨大なコードベースを前にして、
00:09:56どうやって偶発的な複雑さと本質的な複雑さを分ければいいのか。
00:10:01私がNetflixで扱っているコードベースには約100万行のJavaがあり、
00:10:04メインサービスは最後に見計らった時は500万トークンほどありました。
00:10:07どんなコンテキストウィンドウも、それを丸ごと入れることはできません。
00:10:10そこで最初はこう考えました。
00:10:13「コードベースの大部分をコンテキストにコピーすれば、
00:10:17パターンが浮かび上がり、何が起きているか理解してくれるのではないか」と。
00:10:19しかし、先ほどの認証リファクタリングと同様に、
00:10:23出力はそれ自体の複雑さの中に埋もれてしまいました。
00:10:24そのため、別の方法を取らざるを得ませんでした。
00:10:26何を含めるかを選択する必要がありました。設計書、アーキテクチャ図、主要なインターフェースなどです。
00:10:29AIの出力は、それ自体の複雑さに埋もれてしまいました。
00:10:31そのため、私は別のやり方をせざるを得ませんでした。
00:10:34デザインドキュメント、アーキテクチャ、図、
00:10:37主要なインターフェースなど、含めるべきものを取捨選択したのです。
00:10:39コンポーネントがどう相互作用すべきか、どのパターンに従うべきか、
00:10:42要件を書き出すのに時間をかけました。
00:10:43そう、私は「仕様書」を書いていたのです。
00:10:45500万トークンのコードが、2,000語の仕様書になりました。
00:10:49さらに一歩進んで、その仕様書から
00:10:52実行すべきコードの正確なステップを作成しました。
00:10:55曖昧な指示ではなく、正確な一連の操作手順です。
00:10:58これにより、はるかにクリーンで理解しやすいコードが生成されました。
00:11:02まず定義を行い、その実行計画を立てたのです。
00:11:05これを私は以前から「コンテキスト圧縮」と呼んでいます。
00:11:11皆さんは「コンテキスト・エンジニアリング」や「仕様駆動開発」など、
00:11:13好きなように呼んで構いません。
00:11:15名前はどうでもいいのです。
00:11:16重要なのは、思考と計画が仕事の大部分を占めるようになることです。
00:11:20では、これが実際にどのように機能するか説明しましょう。
00:11:22まずステップ1、フェーズ1は「リサーチ」です。
00:11:26最初にあらゆる情報を投入します。
00:11:28アーキテクチャ図、ドキュメント、Slackのスレッドなどです。
00:11:31これまで何度も言ってきたことですが、
00:11:32変更に関連するコンテキストを、
00:11:35できるだけ多く持ち込むことが重要です。
00:11:36そしてAIエージェントを使ってコードベースを分析し、
00:11:39コンポーネントと依存関係をマッピングさせます。
00:11:42これは一度で終わるプロセスではありません。
00:11:43私はよく「キャッシュはどうなってる？」「失敗時の処理は？」と
00:11:46問いを投げかけます。
00:11:47分析が間違っていれば修正し、
00:11:49コンテキストが不足していれば提供します。
00:11:51反復するたびに分析の精度が上がっていきます。
00:11:55ここでの成果物は、1つのリサーチ・ドキュメントです。
00:11:57現状、何がどこに接続されており、
00:11:59変更がどこに影響するかが記されています。
00:12:01何時間もの調査が、数分で読める内容に圧縮されます。
00:12:03今朝デックスも言及していましたが、ここでの人間による確認が極めて重要です。
00:12:09分析結果を現実と照らし合わせて検証する、
00:12:12プロセス全体の中で最もレバレッジの効く瞬間です。
00:12:15ここでミスを見つければ、後の大惨事を防げます。
00:12:17次はフェーズ2です。
00:12:20検証済みのリサーチ結果を手にしたら、
00:12:22詳細な実装計画を作成します。実際のコード構造、
00:12:25関数シグネチャ、型定義、データフローなどです。
00:12:28どの開発者でも真似できるレベルのものにします。
00:12:30私はこれを「塗り絵」のようなものだと考えています。
00:12:32新人エンジニアに渡して「これ通りにやって」と言えるレベルです。
00:12:35一行ずつ書き写せば、そのまま動くはずのものです。
00:12:38このステップで、重要なアーキテクチャ上の決定の多くを下します。
00:12:43複雑なロジックが正しいか、
00:12:45ビジネス要件がベストプラクティスに従っているか確認します。
00:12:50サービスの境界線、クリーンな分離がなされ、
00:12:52不必要な結合が防げているかを確認します。
00:12:54私たちは経験があるからこそ、問題が起きる前に察知できます。
00:12:57AIにその選択肢はありません。
00:12:59AIはあらゆるパターンを要件として扱ってしまいます。
00:13:01このステップの真の魅力は、レビューの速さです。
00:13:05数分で計画を検証し、何が構築されるかを正確に把握できます。
00:13:10コード生成のスピードについていくためには、
00:13:13自分たちが何をしているかを同等の速さで理解する必要があります。
00:13:18最後は実装です。明確な計画と
00:13:22裏付けとなるリサーチがあれば、このフェーズは非常に単純です。
00:13:26そして、それこそが狙いなのです。
00:13:28AIに従うべき明確な仕様があれば、コンテキストはクリーンで
00:13:31焦点が絞られた状態を維持できます。
00:13:32長い対話による「複雑さの連鎖」を防ぐことができるのです。
00:13:3650回もやり取りしてコードを継ぎ足す代わりに、
00:13:38検証済みの3つの集中した出力だけで済みます。
00:13:41途中で方針を捨てたり、パターンが衝突したり、
00:13:44no espera, de hecho son momentos que dejan código muerto por todas partes.
00:13:48この手法の最大の利点は、あらかじめ思考と重労働を終えているため、
00:13:52バックグラウンド・エージェントに多くの作業を任せられることです。
00:13:56AIに実装を始めさせ、自分は別の仕事に取り掛かり、
00:13:59後でレビューに戻るということが可能です。
00:14:01レビューも短時間で済みます。計画通りかを確認するだけでよく、
00:14:04勝手なコードが書かれていないかを解読する必要がないからです。
00:14:07ここで重要なのは、AIに思考を代行させるのではなく、
00:14:12私たちが理解を保ちながら、
00:14:15機械的な作業を加速させるためにAIを使うということです。
00:14:17リサーチは速く、計画は徹底され、実装はクリーンになります。
00:14:21しかし、思考、統合、そして判断は、私たちの手に残ります。
00:14:26さて、先ほどAIでは対処できなかったと言った認証機能のリファクタリングですが、
00:14:34実は今、それに取り組んでおり、
00:14:37順調に進んでいます。
00:14:39ただ、それは優れたプロンプトを見つけたからではありません。
00:14:42リサーチ、計画、実装というサイクルにすら
00:14:45すぐには入れなかったのです。
00:14:46私たちはまず、手作業で変更を行う必要がありました。
00:14:49AIを使わず、コードを読み、依存関係を理解し、
00:14:52実際に変更を加えて何が壊れるかを確認したのです。
00:14:53正直、その手作業での移行は苦痛でしたが、極めて重要でした。
00:14:59隠れた制約や、維持すべき不変条件、認証変更で
00:15:02どのサービスが壊れるかが明らかになったからです。
00:15:05コード分析だけでは決して表面化しなかったことばかりです。
00:15:09そして、その手作業で行ったプルリクエストをリサーチ・プロセスに投入し、
00:15:14今後のあらゆる調査の「種」として利用させました。
00:15:19そうすることで、AIは「正しい移行」がどういうものかを理解できたのです。
00:15:23エンティティごとに微妙に異なるため、
00:15:27「これについてはどうすべきか？」と繰り返し問いかける必要がありました。
00:15:29暗号化されているものもあれば、そうでないものもあります。
00:15:32何度も反復しながら、その都度コンテキストを追加しました。
00:15:35そうしてようやく、一発で通る可能性のある計画を生成できたのです。
00:15:41「可能性」と言ったのは、今でも検証と調整を続け、
00:15:45エッジケースを発見している最中だからです。
00:15:47この3フェーズ・アプローチは魔法ではありません。
00:15:55最初に手作業で移行を行ったからこそ機能しているのです。
00:15:57プロセスに組み込む前に、自らの力で理解を勝ち取る必要がありました。
00:16:01「銀の弾丸」など存在しないと今でも思っています。
00:16:02優れたプロンプトやモデル、優れた仕様書を書くことすら解決策ではありません。
00:16:06システムを深く理解し、安全に変更を加えられるようにする、
00:16:09その泥臭い作業が必要なのです。
00:16:11では、なぜそこまでするのでしょうか？
00:16:15うまくいくまでAIと試行錯誤すればいいのではないか？
00:16:18いずれモデルが強化されれば、勝手にうまくいくはずだ、と。
00:16:21しかし、私にとって「動けばいい」では不十分なのです。
00:16:24「テストに通るコード」と「本番環境で生き残るコード」は違います。
00:16:27今日機能するシステムと、
00:16:28将来、他の誰かが変更できるシステムもまた別物です。
00:16:31真の問題は「知識のギャップ」にあります。
00:16:34AIが数秒で数千行のコードを生成するとき、
00:16:38それを理解するのに数時間、複雑なら数日かかるかもしれません。
00:16:41あまりに複雑なら、一生理解できないかもしれません。
00:16:45これは、まだ多くの人が語っていない重要なことです。
00:16:48生成スピードに合わせるために思考をスキップするたびに、
00:16:52私たちは理解できないコードを増やしているだけではありません。
00:16:56問題に気づく能力そのものを失っているのです。
00:16:58「これは複雑になりすぎている」と感じる直感は、
00:17:00自分のシステムを理解していなければ衰退してしまいます。
00:17:03パターン認識は経験から生まれます。
00:17:09私が危険なアーキテクチャに気づけるのは、
00:17:11深夜3時までその問題に対処した経験があるからです。
00:17:12よりシンプルな解決策を求めるのは、
00:17:16他人が書いた複雑なコードの保守に苦労したことがあるからです。
00:17:17AIは言われたものを生成するだけです。
00:17:21過去の失敗から得た教訓をコードに込めてはくれません。
00:17:233フェーズ・アプローチはこの溝を埋めるものです。
00:17:25理解を成果物に凝縮し、生成スピードでレビューできるようにします。
00:17:29これなしでは、理解できる速さを超えて
00:17:33ただ複雑さが積み上がっていくだけです。
00:17:37AIはコードの書き方を根底から変えますが、正直なところ、
00:17:39ソフトウェアがなぜ失敗するのかという根本的な理由は変えられません。
00:17:44どの世代もそれぞれの「ソフトウェア危機」に直面してきました。
00:17:47ダイクストラの世代はソフトウェア工学という規律を作ることで立ち向かい、
00:17:50私たちは今、無限のコード生成という危機に直面しています。
00:17:54解決策は、新しいツールや手法ではありません。
00:17:56ソフトウェア開発とは人間による営みであるという、
00:18:01普遍的な真理を思い出すことです。
00:18:05難しいのは、コードを打ち込むことではありません。
00:18:06そもそも何を入力すべきかを知ることなのです。
00:18:09今後、活躍する開発者は、単に多くのコードを生成する人ではありません。
00:18:13自分が何を作っているかを理解し、システムの継ぎ目を見抜き、
00:18:15間違った問題を解いていることに気づける人です。
00:18:18それは依然として、私たち人間にしかできないことです。
00:18:19これからも、私たちだけの役割であり続けるでしょう。
00:18:20最後に1つ問いを投げかけて終わりたいと思います。
00:18:21問いは「AIを使うかどうか」ではありません。
00:18:25それはもう決まりきったことであり、
00:18:26避けては通れない道です。
00:18:28本当の問いは、AIがコードの大部分を書くようになったとき、
00:18:30「私たちは依然として、自分たちのシステムを理解しているだろうか」ということです。
00:18:33ありがとうございました。
00:18:35（拍手）
00:18:39（音楽）