※本記事は、Richard Seroter氏、Aja Hammerly氏、Ciera Jaspan氏、Addy Osmani氏による「A fireside chat on the evolution of the developer craft」の内容を基に作成されています。本セッションはGoogle I/O 2026のProfessional Developmentトラックの一環として配信されたもので、動画は https://www.youtube.com/watch?v=VTYx7Ex-0bA でご覧いただけます。本記事では、動画の内容を要約しております。なお、本記事の内容は登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご覧いただくことをお勧めいたします。
Richard Seroter氏はGoogle Cloudにてデベロッパーリレーションズを率いる立場にあり、本セッションのモデレーターを務めています。Aja Hammerly氏、Ciera Jaspan氏、Addy Osmani氏はいずれもGoogleの開発者・AIチームに所属しており、コード生成の話題にとどまらず、構文よりもシステムアーキテクチャに重きを置く日々の創造的な働き方の変化や、AIをパートナーとしたデバッグのあり方、そして開発者の仕事の未来について、率直な対話を展開しています。
なお、Google I/O 2026のProfessional Developmentセッション一覧は https://goo.gle/professional-develope... から、Google for Developersのチャンネル登録は https://goo.gle/developers からご覧いただけます。(#GoogleIO)
1. 登壇者紹介とシニアエンジニア像の再定義
1.1 パネル紹介とディスカッションの狙い
Richard Seroter： 本日はお集まりいただきありがとうございます。これまで同じステージに立ったことのない顔ぶれで、楽しい対話をお届けできればと思います。まずAjaは、私がこれまで出会った中でも最も実践的で優秀なエンジニアの一人です。Cieraは、Googleのエンジニアたちが日々どのように働き、どう改善しているかについて非常に興味深い研究をしていて、彼女の洞察にはいつも学ばされています。そしてAddyは、現代のAI開発とは何かという問いに対して、最も創造的かつ思慮深い取り組みをしています。私はと言えば、この場にふさわしいとは思えませんが、皆さんに質問を投げかける役割を担います。今日はフィルターなしで話してもらうようお願いしていますので、ライブ配信ではありますが、思い切り楽しんでいきましょう。まず考えたいのは、今の時代における「シニアエンジニア」とは一体何を指すのかということです。スキルによって定義されるのか、あるいは担当する仕事の範囲によって定義されるのか。エージェントやジュニアエンジニアが存在する今、両者の関係性やキャリアの進み方はどう変わっているのでしょうか。まずAddyから聞かせてください。
1.2 シニアエンジニアの定義はどう変わるか
Addy Osmani： これまでシニアであるということは、他の人が解けない問題を解けるコードを書けることを意味していました。しかし今では、他の人が理解できないコードを理解できることの方が重要になっています。私が重視しているのは、明晰さこそがシニアであることの証だという考え方です。今この瞬間に最も優れた成果を出している人たちは、すでに強いメンタルモデルをテーブルに持ち込んでいる人たちです。つまり、しっかりとしたエンジニアリングの基礎の上にAIの活用を積み上げているのです。
Richard Seroter： なるほど。Cieraは、Googleがエンジニアリングやシニア職への昇進をどう捉えているかを長年見てきましたよね。2026年における「シニアエンジニア」とは何なのか、これまでと違うのか、それとも定義そのものを見直しているのでしょうか。
Ciera Jaspan： シニアエンジニアが持つべき資質の多くは、今日でも変わらないと考えています。彼らは一つの問題をより小さな構成要素に分解できる人たちであり、トレードオフの分析ができる人たちです。たとえば、あるシステムを高いセキュリティを持たせる代わりにパフォーマンスを犠牲にするのか、それとも安全性を落としてでもパフォーマンスを優先するのか。これはビジネスケース次第であり、さまざまな他の要因とのトレードオフに左右されます。ですから、シニアエンジニアは引き続きこうした判断を担う存在だと思います。難しいのは、大学を卒業したばかりの最も若手の人材も含めて、全員がシニアエンジニアである必要が出てきている点です。したがって、いかに彼らを短期間でアップスキルさせるかを考えなければなりません。
Richard Seroter： ここで一つ、その場で思いついた質問をAjaにぶつけてもいいですか。シニアエンジニアの採用基準は、この12か月で変わりましたか。以前は求めていなかったけれど、今は求めているものは何ですか。
Aja Hammerly： 私はこれまでずっと、シニアエンジニアとはビジネスにとって機能する形で難しい技術的問題を解決できる人であり、深夜2時に本番環境の障害を一緒にデバッグしても構わないと思える人だという哲学を持ってきました。加えて、技術を使いこなす能力と技術への強い好奇心、そして最新の状況を追い続けるための技法を持っている人を探すようになりました。誰しもそうだと思いますが、今はまるでロケットに乗って皆で突き進んでいるような感覚です。ですから、AIを使いこなすことに抵抗がなく、実際にAIを活用していて、なおかつ最新の技術動向を追い続ける習慣を自分なりに築いていて、新しい選択肢に対して好奇心を持っている人を求めるようになりました。とはいえ、私にとっての核となる考え方は、シニアエンジニアとは興味深いビジネス上の問題を解決するための知恵とスキルを持つ人だということであり、この部分は変わっていないと思います。
Richard Seroter： Addy、あなたが今シニアエンジニアを採用するとしたら、職務記述書の内容を変えますか。
Addy Osmani： 今までに他の方々が挙げた点に加えて、私は現代における「メンタリングとは何か」について自分なりの視点を持っている人を求めたいと思います。20体のエージェントを立ち上げて、あとはチームの他のメンバーに任せきりにしてしまうような人ではなく、今日のジュニアが明日のシニアになるという意識を持ち、彼らへの投資を惜しまない人であってほしいのです。彼らがレベルアップできるよう、私たちはもっと積極的かつ明確にサポートしていく必要があると感じています。なぜなら、自分が何を知らないのかは、当人にはわからないものだからです。ビジネス上のあらゆる要求、問題領域のあらゆるニーズに応える質の高い解決策とは何かということも、経験がなければわかりません。ですから、これは私が確実に求めるポイントの一つです。
2. 職種の境界の変化とリスキリングの方向性
2.1 「誰がコードを書くか」が揺らぐ現場
Richard Seroter： エンジニアがドキュメントを書いたり、プロダクトの仕事やUIの仕事をしたりと、より幅広い種類の作業を担うようになってきています。誰がコードを書くのかという境界が曖昧になっていく中で、私たちはどう適応すればよいのでしょうか。Cieraは長年Googleの開発のあり方を研究してきましたが、これまで明確だった役割の定義が今まさに変わりつつありますよね。PMがプロトタイプのコードを書いたり、デザイナーが書いたり、私たち全員がそうなったりしたとき、何を変えなければならないのでしょうか。私たちはどう考え方を変える必要があるのでしょうか。
Ciera Jaspan： これは私たちが今まさに研究しているテーマです。変化があまりに速いので、正直なところ研究するのが非常に難しいテーマでもあります。誰もの職務がどう変わっていくのかを理解しようとしているところです。私自身のチームでの逸話をお話しできます。私のチームはソフトウェアエンジニア、UXリサーチャー、データサイエンティストからなる職能横断チームなのですが、ある週、全員でAIの使い方を探ってみようということになりました。週末に集まって振り返ったところ、最も興味深かったのは、ソフトウェアエンジニアがコードを書いていなかったことです。私たちは皆、設計文書を書いたり、ドキュメントを整備したりしていました。そしてUXリサーチャーは皆コードを書いていたのです。つまり、全員がある程度は互いの仕事に手を出したのですが、それはいつも「他人の仕事のジュニアレベル」の部分でした。私たちは皆、他者の仕事についてはジュニアレベルをこなし、自分自身の仕事についてはシニアレベルをこなしていたのです。ですから、これが私の予想する今後の姿ですが、まさに今調査を進めている最中のテーマです。
Richard Seroter： 素晴らしい回答ですね。Ajaはどうでしょうか。あなたのチームには、あらゆる種類の仕事をこなせる、いわば万能ナイフのようなメンバーもいますよね。今、さまざまな人が仕事のさまざまな部分を担えるようになった中で、開発者に対する期待は変わるのでしょうか。「これはもう自分の仕事ではない」と言うようになるのか、それとも「すべてが全員の仕事」になるのでしょうか。
Aja Hammerly： 私たちはまだ、誰もが専門性を持っている段階にあると思います。誰もが深く掘り下げている領域を持っていますし、誰もが知恵を持っている領域を持っています。AIは、以前はできなかったことをできるようにしてくれます。私は「builder(作り手)」という考え方の大きな支持者で、私たちは皆builderであり、それぞれが独自の才能を持ち寄っているのだと思っています。それは以前から真実でした。そしてここが重要なのですが、私たちは皆、それぞれ得意な言語やフレームワーク、スタックの部分を持っています。とはいえ、私のチームだけでなく、Googleの中だけでもなく、コミュニティの人たちと話していても感じることですが、好奇心が強く多様な才能を持つ人たちが、これらのツールで非常に成功を収めています。なぜなら、彼らはUXについて少し知っている、プロダクトデザインについて少し知っている、コーディングについても少しあるいは多く知っているというように、それらの知識を組み合わせることができるからです。AIは、こうしたスキルを新しく興味深い形で組み合わせることを可能にしてくれます。それが開発者にとってどんな変化を意味するのか、私はまだこの旅の途上にあると考えています。
Richard Seroter： Addy、今日の開発者が、他の人たちが何かを作って自分たちに渡してくるようになったとき、苛立たずにいるにはどうすればよいのでしょうか。「放っておいてくれ、自分の仕事は自分でやる」とはいかないわけですよね。既存のエンジニアは、こうした新しい作り手たちの参入をどう捉えるべきでしょうか。
Addy Osmani： 新しい作り手について話すとき、多くの場合それはvibe codingでソリューションを作る人たちのことを指しています。vibe codingは、どれだけ多くの人がものづくりに参加できるかという参入の敷居を大きく下げました。それは実に素晴らしいことです。静的なモックについて話す代わりに、実際に触って遊べるプロトタイプについて話せるようになったのです。これは大きな転換点です。同時に、私が強く感じているのは、アジェンティックエンジニアリング、つまり古典的なコンピュータサイエンスやシステムエンジニアリングのベストプラクティスを、作られたものの品質やセキュリティを担保し、本番環境に耐えうる状態にまで鍛え上げるためにどう組み込むかということは、依然として重要であり続けるということです。作り手の裾野を広げていく一方で、私たちは「とりあえず動くものをワンショットで作ってURLに公開する」ことと、「実際に長く持続し、保守していけるものを作る」こととの違いを、人々に理解してもらう手助けをする必要があると考えています。
2.2 リスキリングすべき領域:ドキュメンテーションとアーキテクチャ思考
Richard Seroter： 何が最後まで残るのかは誰にも予測できない中で、リスキリングやデスキリングについてはどう考えればよいのでしょうか。ソフトウェアエンジニアリングにおいてさえ、新しい仕事をするために忘れなければならないことがたくさんあります。ここにいる方々やオンラインで見ている方々は、自分の時間をどこに投資すべきなのでしょうか。AIが明日にでもこなせるようになる分野に投資して、自分を差別化できなくなるという事態をどう避ければよいのでしょうか。Ciera、まずどこをデスキルすべきだと思いますか。この過程でやめるべきことはあるでしょうか。
Ciera Jaspan： 何をやめるべきかについては、正直あまり確信が持てません。その角度ではあまり考えたことがなかったので。むしろ新しく身につけるべきスキルの方向で答えさせてください。私たちが再投資すべきスキルの一つは、ドキュメンテーションをもっとしっかり行うことだと思います。チームにエージェントを迎え入れるということは、チームの規模を実質的に倍増させ、しかもその全員がジュニアエンジニアであるということを意味します。皆さんのチームの多くも他の業界の多くのチームと同様に、すべての設計判断やプロセスをきちんと書き残してはおらず、ドキュメントの一部は古くなっているかもしれません。しかし、これまでは1年に新人が1人入るかどうかという状況で、しかも彼らは他のチームから移ってきた自分自身のスキルを持っていて、すでにある程度のことを知っていたため、すべてを書き残す必要はありませんでした。ところが今は、文字通りチームの規模が倍以上になり、しかもそのすべてが完全なジュニア人材なのです。ですから、私たちは質の高い社内ドキュメントを書くことに再投資する必要があります。
Richard Seroter： Addy、あなたはこうした新しい働き方、特にアジェンティックエンジニアリングの具体的な実践について多くを書いてきましたよね。デスキリングでも構いませんし、リスキリングやまったく新しいスキルでも構いません。この会場にいる人たちが「これを学ばなければ」と思って会場を後にするべきスキルは何でしょうか。
Addy Osmani： 今この瞬間、私たちはよく人々に「どこまでも好奇心を持ち、どこまでも貪欲であれ」と伝えます。そしてそれが意味するのは、いろいろなことを試すための時間を、1週間の中で意図的に確保する必要があるということです。ジュニアエンジニアと話していようが、エンジニアリング担当のVPと話していようが、誰もが作り、学び、実験し、何がうまくいって何がうまくいかないかを見極めようと時間を捻出しようとしている。こんな時代は業界の中でもこれまでになかったと思います。同時に、多くの開発者から聞くのは、今はスピードへの意識が非常に強くなっているということです。もっと出荷しなければならない、もっとプロダクトを、もっと機能をリリースしなければならない、と。そうなると、その中で本当に仕事を通じて学ぶ余地が残っているのだろうかと人々は疑問に思うわけです。だからこそ、単にLLMにコード生成を任せるだけでなく、それが何を生成したのか、なぜそのような判断をしたのかを理解する時間を実際に取ることが重要だと、意図的に意識する必要があると思います。それによって、開発をしながらも自分の腕を鈍らせずにいられるのです。
Richard Seroter： リスキリングや新しいスキルについて考えるとき、シニアエンジニアにとっても、これから始めるジュニアエンジニアにとっても、危機感を持って取り組むべき領域はどこにあると思いますか。
Aja Hammerly： 危機感を持つべきだと思うのはアーキテクチャです。問題の解き方を知ること、問題の分解の仕方を知ること、何を1つのエージェントにカプセル化すべきで、何が単一のエージェントには荷が重すぎる責任なのかを知ること、そしてそれらのエージェント同士がどう対話すべきかを知ることです。大きな問題があるとき、それを分割するのか。1体のエージェントに1日かけて取り組ませるのか、それとも10体のエージェントに1時間ずつ取り組ませるのか、あるいは24体のエージェントに1時間取り組ませるのか。こうしたアーキテクチャに関する問いは、組織の中でずっと下の階層の従業員にまで及ぶようになりました。今や誰もがこうしたアーキテクチャの問いに向き合っているのです。ですから、こうした問題をきちんと考え抜くこと、アプローチにおけるトレードオフを理解することが重要になります。アルゴリズムという言葉を使ってもいいですが、それ以上のもの、つまりアーキテクチャそのものです。それこそが、誰もが最新の状態にしておくべきものだと思います。なぜなら、私たちは問題に対処するための膨大なツール群を手にしていますが、それでもなお、それらのツールに向けて問題をきちんと組み立てる力が必要だからです。そして、そのツールを使って理にかなった、持続可能な意思決定をしていく必要があります。私にとって、それはまさにAIアーキテクチャ全般に関わることなのです。
3. デスキルすべきもの、ベストプラクティスなき時代の向き合い方
3.1 IDE・プログラミング言語への執着を手放す
Richard Seroter： ここで一つ、皆さんが反論したくなるようなデスキリングの提案をしてもいいですか。Ciera、あなたはきっと同意しないと思いますが。私は、IDEやプログラミング言語への愛着はもう手放すべきだと思っています。VS CodeやIntelliJを自分好みの設定やスペックに1週間かけてチューニングすることがあるかもしれませんが、それはもうそこまで重要ではないと思うのです。使うこと自体は素晴らしいのですが、私たちが異なるサーフェスへと移行していく中で、開発ツールに対してもう少し「奔放」であるべきだと感じています。一つのスタック、一つのプログラミング言語に結婚するように縛られるべきではありません。それは自分を制限することになるからです。とはいえ、ぜひ反論してください。私はツールについてデスキルすべきだと思っているのです、Antigravityだけは別として、あれには全面的にコミットすべきですが。皆さんは開発ツールについてどう感じますか、Aja。
Aja Hammerly： もし先ほどデスキルについて聞かれていたら、構文をデスキルすべきだと答えていたと思います。私はずっとプログラミング言語が好きで、たくさんの言語を使ってきました。昨日もAntigravity CLIをEmacsの中に組み込むためにLispを書いていましたが、それは必要だったからではなく、単に楽しかったからです。今はGoを使っていますが、これは半年前には知らなかった言語です。Goの強みと弱みは概念的に理解していますし、コードを読むこともできますが、おそらく今、自分でまとまった行数のGoのコードを書くことはできないと思います。構文を覚えていないからです。読めるようにはなりましたし、その強み・弱みや背後にある概念も理解しましたが、構文にはあまりこだわっていません。どの週を切り取っても、私はおそらく5つくらいの言語に触れています。異なる問題には異なるツールが向いているからです。だから、その時々で正しいツールを使うようにしています。ADKについても、私は学びましたが、構文は説明できません。それでも常用しています。コード自体は生成させています。
Ciera Jaspan： 私はあなたのデスキリングの問いを少し方向転換させて、私たちに摩擦(friction)を生じさせるものすべてをデスキルすべきだと言いたいと思います。IDEの一部の設定などもそうです。新しいIDEをインストールして、すべての設定を自分好みに変えなければならないとしたら、それは時間の無駄だと感じますし、正直そういう作業は好きではありません。しかし、私たちの日々のワークフローの中には他にも摩擦を生む部分があります。今は、摩擦を感じるポイントを見つけたら、それをAIにやらせることでデスキルしていく良い機会だと思っています。そうした摩擦は、私たちにとって痛みでしかなく、自分自身の生産性の助けにはならないものだからです。
Richard Seroter： いい回答ですね。Addy、開発ツールについてどう感じますか。あなたはほぼすべてのツールを使っていることを認めなくてもいいのですが、5年前も同じように動いていましたか。それとも以前はもっと固定されたスタックを持っていて、今はどんどん乗り換えているのでしょうか。それとも、あなたにとってはずっとそうだったのでしょうか。
Addy Osmani： 少し違う角度から答えさせてください。5年前の業界では、人々が使う技術スタックやフレームワーク、ライブラリに対して、宗教的とも言えるようなこだわりが強くありました。人々は非常に強い意見を持っていて、自分が特定のコミュニティの一員であるかのように感じていました。ある解決策から別の解決策へ乗り換えさせることには、しばしば摩擦や大きな労力が伴っていました。しかし今、私たちが目にしているのは、エージェントがその問題、つまりCieraが指摘した摩擦の問題を気にしなくて済むように手助けしてくれるようになれば、裏側でどのフレームワークを使うかについて費やす時間は減っていくだろうということです。それは興味深いことだと思います。5年前であれば、私たちはおそらくエディタでどんなプラグインや構文の組み合わせを強調すべきかについてまだ議論していたと思いますが、そうしたことはもうずっと重要ではなくなっています。
3.2 ベストプラクティスが定まらない時代の向き合い方
Richard Seroter： 私は最近「ベストプラクティス」という言葉を使いたくありません。誰も何が本当に「ベスト」なのかわかっていないからです。この場にいる誰もが、6か月や12か月前には常識だと思われていたことを振り返って、「今となっては間違っていた」と言えるはずです。たとえば、誰もが夢中になっていたRAG(検索拡張生成)を見てください。今では、コンテキストの設定の仕方やエージェントアーキテクチャのパターンについて、もはや誰も興奮しないような新しい方法が出てきています。これほどの速さで変化している中で、実践やツールとの向き合い方について、私たちは一体何にしがみつけばよいのでしょうか。私たちの責任は何なのでしょうか。開発者は何をすべきだと思いますか。Ciera、企業内でどれだけの開発者が実践に従っているかを追いかけていますよね。実践が安定していないとき、何が起きるのでしょうか。
Ciera Jaspan： 私たちは今、技術採用サイクルの初期段階にいます。研究者としても、ソフトウェアエンジニアとしても、これは個人的に苦しい状況だと感じていますが、同時に必ず通らなければならない段階でもあります。業界全体が今まさにこの領域を探索している最中で、どこに向かっているのか、どんな可能性があるのか、まだ確信が持てていません。だからこそ、あらゆることを試し、何がうまくいって何がうまくいかないかを見極めるべきなのです。数年後には、統合(consolidation)が起き始め、ベストプラクティスが生まれてくると予測しています。そうなれば、研究の側面がより面白くなってくるはずです。ある人が「これがベストプラクティスだ」と提案し、別の人も「これがベストプラクティスだ」と提案する。そこから、実際にどちらが本当にそうなのか、どちらがそうでないのか、どう調整すればよいのかを検証できるようになるからです。ベストプラクティスが確立された後には、それを制度化していくことになります。そしてこの部分こそ、開発ツールが本当に大きく変わっていくところです。私たちはそのベストプラクティスをツールの中にコード化していくことになるでしょう。それが最終的に、生産性全体への大きな押し上げにつながるはずです。しかし、これは技術採用サイクルなのです。私たちの業界はこれを以前にも経験しています。もし本当に面白いものを見たければ、Fortranに関する最初の論文の要旨を見てみてください。構造化プログラミングという考え方は当時、非常に新しく、人々を驚かせるものでした。その要旨は、今日の論文に載せてもおかしくないような内容で、「これを全員が使えば生産性が何百倍にもなるだろう」と書かれていました。それでもなお、あの技術は採用サイクルを経なければなりませんでした。私たちはさまざまなものを試し、あるところで「goto文は本当にひどいアイデアだ、やめよう」と気づいたのです。今回も同じ採用サイクルを経験することになるでしょう。うまくいけば、今回は少し短く済むと思いますし、実際そうなると思います。しかし、数年後には本当にベストプラクティスが見え始めてくるはずです。
Richard Seroter： Addy、これは様子見をして実験を重ねるべきものだと思いますか。もし自分に合ったものを見つけたなら、それをただ続ければよく、Google I/Oで話題になった最新の流行に乗り遅れることに焦りを感じる必要はないのでしょうか。
Addy Osmani： 私たちの業界は、物事を非常に大雑把な筆致で描いてしまう傾向があると思います。どういうことかと言うと、Xを見れば、今週だけで3つの新しいツールや新しいモデルがリリースされた、Ralphループを使う人が出てきた、といった新しく見えるものすべてが目に入ります。しかしそれは、一体誰に向いているものなのでしょうか。それは一人で起業したファウンダー向けなのか、それともチームや大企業向けなのか。両者はまったく異なるワークフローを持っているにもかかわらず、私たちはそのニュアンスを人々に提供できていないことが多いのです。ですから、まだ安定する時間を経ていない、ソーシャルネットワークで共有されているような最先端のアイデアについては、注目すること自体は良いことだと思います。Xのような場所は、最終的に何が定着していくかを見極めるための良い先行指標になり得ます。自分自身で試してみるのは構いませんが、他の人たちがそれを試すのを見届けるまでは、それを職場に持ち込むことに義務感を感じる必要はありません。ただし、あなた自身が一人か三人だけのスタートアップで、リスクを取ることに前向きな場合は話が別です。すべての新しいものに飛びつかなければならないと感じる必要はありませんが、そのノイズがどこから来ているのかには注意を払うべきです。あなたには当てはまらないかもしれないからです。
Richard Seroter： Aja、もしソーシャルメディアを見て「自分はまだ手でコードを書いている、まるで恐竜みたいだ、24時間365日働くエージェントのチームでコードの100%を書くべきなのに、自分は完全に時代遅れだ」と感じている人がいたら、そういう人にどう伝えればいいでしょうか。すべての流行を追いかけなくても大丈夫だ、落ち着いていいのだと。
Aja Hammerly： 誰もが少し落ち着いていいと思います。それが良い出発点になるでしょう。Addyが言った通り、「それは場合による」のです。場合による、というのがソフトウェアエンジニアリングにおける、そして人生の大半における、あらゆる問いへの答えです。ある実践が興味深く思えて、自分が取り組んでいる問題に関連していそうなら、それは素晴らしいことです。私自身、今まさに頭を抱えている問題があり、それにAIを機能させようと試みています。ただ、はっきり言えるのは、RAGはうまくいかないということです。実際に試してみて、うまくいきませんでした。それでいいのです。自分の業界におけるリスク許容度に見合ったペースでこれに取り組むのは、まったく問題ありません。誰もがこうした動向を意識しておくべきだとは思いますが、もしあなたがエンジニアリングマネージャーで、この会場やオンラインで見ているなら、チームのために実験のための時間を確保することを強くお勧めします。それをshow and tellと呼んでもいいですし、私のチームではWork in Progressと呼んでいますが、science fairでも何でも構いません、必要な名前をつけてください。なぜなら、実際に手を動かしてみない限り、こうした新しく話題のものが自分たちに合うかどうかは理解できないからです。実際に時間を取って試してみる必要があります。ですから皆さんにお願いしたいのは、週に2時間を確保して、これらのものを実際に試してみるということです。もし今週試す時間がなくても、それはそれで構いません。そしてこれは何も新しいことではありません。私はこの20年間、たくさんの技術カンファレンスに参加してきましたが、いつも新しいものが出てきます。マイクロサービスを一切使わずにモノリスで運用している企業もたくさんありますし、モノレポを採用している企業もあります。こうしたものはすべて、流行っては廃れ、また流行るということを繰り返してきました。そしてそれが流行ったり廃れたりする理由は、それが一部の人にとっては問題を解決し、別の人にとってはそうではないからです。それでいいのです。自分に合うなら、それは素晴らしいことです。
4. 新しい日々の習慣とキャッチアップの方法
4.1 日々の学習ループの作り方
Richard Seroter： ここからは、皆さん一人ひとりに具体的な質問をしていきたいと思います。今、自分自身で始めた習慣、あるいは他の人にも始めてほしいと思う習慣で、考え方そのものを変えるようなものはありますか。私たちが今やっているのは、単にツールを追加しているだけではなく、新しい習慣を築いているのだと思うのです。Addy、まずあなたから聞かせてください。
Addy Osmani： この採用サイクルの初期には、AIは物事を速く出荷できるから素晴らしいのだ、という話をよくしていました。しかし、日々のワークフローについてはそれが正しい考え方ではないと思っています。私が大事にしているのは「相互増幅(mutual amplification)」という考え方です。つまり、私が毎日エージェントを使うことで、自分自身がより良くなっていき、同時に自分のエージェントもより良くなっていく。そこには、お互いがお互いを増幅させ、一緒に成長していくループがあるべきなのです。具体的には、ツールの側もこの点でどんどん改善されてきていますが、私はその日に得た新しい気づきは何かをきちんと把握するようにしています。それを自分のスキルにどう落とし込むか。学習用のmarkdownファイルなどに書き込んで、自分のエージェントが再利用できるようにするのか。昨日犯した間違いを、明日も同じように繰り返さないためにはどうすればよいのか。これが私がエージェントに対して実践していることの一つです。
Richard Seroter： それはどうやって実践しているのですか。一日の最後の15分を確保しているのか、それとも継続的にやっているのか。どうやってその習慣を身につけたのでしょうか。「それはいい考えだ」と言うのは簡単ですが、実際にやり続けるのは別の話ですよね。
Addy Osmani： そうですね、エージェントのmarkdownファイルや設定の中に、指示を定義しておくことができます。たとえば、「このセッションの終わりに、そこから得られた学びを自動的に整理してほしい」、あるいは「前日には知らなかったことは何だったか、私に問いかけてほしい」といった指示です。ですから、こうした強化学習のループを組み込んでおくことが役立つと思います。
Richard Seroter： それはいいですね。Ciera、あなたはこの舞台に上がる前に、趣味や生産性向上のために作っているエージェントの話をしてくれましたよね。何かしら日々の習慣として、少しずつでも人々が取り入れられて、その意識を切り替えるきっかけになるようなものに気づいたことはありますか。
Ciera Jaspan： 私はAddyとかなり似たことをしています。エージェントを使うとき、そして新しいことをそのエージェントに教えるときには、非常に意図的であるようにしています。すべてのステップにおいて、「では、あなたが今学んだことをすべてmarkdownファイルに更新してください」と伝えるようにしていますし、エージェントが間違いを犯すたびに、なぜその間違いを犯したのかを考えさせて、そのファイルをまた更新させています。最初は少し時間がかかるように感じますが、結果的にはより速い地点にたどり着けるので、そうしています。それから、私は毎日のように最新のツールに飛びつくタイプの人間ではないということも付け加えておきたいと思います。次々と登場する新しいツールをすべて把握することはできません。ですから、「今月はこの新しいツールを学ぶ」あるいは「エージェントを使って、よくあるこの種の問題を解決する」というように、非常に意図的に決めています。そして丸1か月をかけてそれに集中的に取り組み、自分なりのベストプラクティスを見つけたら、それをチームに共有するのです。
Richard Seroter： いいですね。Aja、あなた自身やチームで見てきた日々の習慣について、何か聞かせてください。「木曜日にはこれをやる」という具合に、少しずつ分解していくような話です。
Aja Hammerly： 同僚の一人が、まさにそれをやっていると教えてくれました。しかし私は少し変わったやり方を紹介したいと思います。私が取り入れて、非常に役に立っていると感じているのは、自分がやり取りするAIをすべて「敵対的なメンター(adversarial mentor)」として扱うということです。それがDocsであろうと、Antigravityであろうと、Gemini.google.comであろうと関係ありません。コーディングを終えたら、「私たちは何を見逃した?」「自分は何を見落とした?」「これについて自分が理解していないだろうと思う部分はどこ?」と聞くようにしています。ドキュメントを書いているときも、それが誰宛てであっても、Richard宛てであろうと他の誰か宛てであろうと、「これに対する異論はどんなものが出てきそう?」「どの部分が不明瞭?」「ここからどう改善できる?」と聞くのです。Antigravity 2.0を自分のマシンでベータテストし始めたときに最初に与えた指示の一つは、「自分は学ぶためにここにいる。どうすれば改善できるか教えてほしい」というものでした。セッションを終えるたびに、「何を見逃した?」「何を忘れた?」と聞きます。プッシュする前には必ず、「何が正しくない?」「ここで見栄えが良くない部分はどこ?」と聞くようにしています。それが、私がAIに私自身のために思い出させてほしいと頼んでいることです。そして、「優しくしないでほしい」とも伝えています。時には、優しくしないでくれとわざわざ伝える必要があるからです。このように敵対的なメンターとして設定しておくと、そこには観客がいません。相手はAIですから、もし「お前は馬鹿だ」と言われても、それはただの計算機に言われているだけのことです。おあいこです。それでいいのです。しかし、このおかげで私の仕事の質は劇的に向上しました。なぜなら、スピードに対する意識が少し薄れて、質に対する意識が強まったからです。スピードは後からついてきます。私はほぼすべてのセッションをこの敵対的なやり取りで締めくくるという習慣を身につけたことで、そのセッションから生まれる成果の質が大きく向上しました。最初の数回は、まったく気持ちのいいものではありませんでした。自分が書いたはずのコードについて、AIから「お前は完全に間抜けだ」と言われるのは、最初の数回は本当に奇妙な感覚でした。しかし、質は本当に向上するのです。
4.2 情報収集とキャッチアップのバランス
Richard Seroter： 私が今考えている習慣の一つは、検索することをやめて、もっとプロンプトで考えるようにするという意識の転換です。たとえば、私たちの多くは、検索エンジンに対して「サンディエゴ、休暇、夏」というように、まるで原始人のように単語を打ち込むことに慣れてしまっています。しかし、Googleの検索データを見ていると、人々が句読点をきちんと使った文章を書くようになってきているのがわかります。それは、彼らがプロンプトを書き、考え、コミュニケーションを取ろうとしているからです。この癖はアンラーニングする必要があります。それは新しい習慣です。しかし、こうした検索エンジンはもはや15年前のように単純なものではありません。かなり複雑なことも尋ねられるようになっているので、単なる奇妙なキーワードのハックではなく、一度立ち止まって自分の目的をきちんと言語化する必要があるのです。このカンファレンスだけを見ても、新しいCLIや、あまりにも多くのIDEや開発ツールが登場しています。「5年前の自分のIDEを返してくれ、放っておいてくれ」と感じるほどの疲労感を覚えるのも無理はありません。なぜこんなにも開発ツールやSDKが溢れているのでしょうか。そもそも、この状況にどうやって追いつけばいいのでしょうか。そして、私たちには「本業がある」というプレッシャーもあります。実際、私は本業としてこれに追いつくことにお金をもらっている立場でありながら、正直あまり追いつけていません。ここにいる皆さんの多くも、ソーシャルメディアを眺めるためではなく、何かをするために誰かからお金をもらっている本業を持っているはずです。Ciera、常に前進し続けなければならない一方で本業もあるという状況で、どうバランスを取っていますか。時間をどう配分し、正しい形で集中するにはどうすればよいのでしょうか。
Ciera Jaspan： 今、FOMO(見逃すことへの恐れ)を感じないでいるのは本当に難しいことです。常に新しいものが登場していますから。だからこそ私は、「新しいツールは月に一つだけ学ぶ」というやり方を続けています。それが私の正気を保ってくれています。というのも、私は物事を深く掘り下げるのが好きなタイプだからです。新しく使うツールが決まったら、それを本当にきちんと理解したいですし、それを最も良い形で使いこなせるようにしたいのです。ですから私にとっては、一度に一つのツールだけを選び、それをしっかり学び、その上でそれを自分のローテーションに残すかどうか、あるいは「これは自分には合わなかった」と見切りをつけるかを判断する、というやり方が合っています。何かがうまくいかないとはっきりわかったときには、素早く見切りをつけるようにしていて、そこから別のものに移ります。しかし一度気に入ったものが見つかれば、そこに丸1か月分の時間をかけます。
Richard Seroter： それはいいアドバイスですね。どうやって最新情報を追い続けているのですか。Google社内だけでも、私が把握しているよりも多くのツールが共有されていますよね。口コミを待つのか、それともランダムに探索しているのですか。
Ciera Jaspan： ええ、私はチームメイトと話をしますし、さまざまなニュースレターも追いかけています。多くの場合、チームメイトも似たような種類の問題に取り組んでいるので、彼らが自分に合った別の何かを見つけていることもあります。それが私の情報源になることが多いですね。
Richard Seroter： Aja、あなたはチームに対してどんどん多くのことを求めていますよね。すみません、と言いつつ、あまり悪びれてはいませんが。彼らには通常業務がある上に、こうした最新情報も追いかけなければなりません。あなたはチームを、あるいは自分自身をどう導いているのでしょうか。
Aja Hammerly： いくつかやっていることがあります。まず、先ほども触れたWork in Progressのミーティングです。これは、半分できあがったくらいのAI関連の実験や、AIに関係のない実験を、互いに共有し合う場です。私自身、そこでさまざまな技法や新しいツール、社内ツールについて多くを学んできました。私が個人的に使っているもう一つの手法は、「ねえ、それどうやったの?」と聞くことです。これは10年前、新しい言語やフレームワークなどを学んでいたときに使っていた方法と同じです。誰かがかっこいい何かを見せてくれたら、それに気づいて「どうやったの?」と聞くのです。あるカンファレンスで、講演の中で変わったキーボードショートカットを使ったことがあるのですが、45分のトーク全体の中で、参加者が唯一覚えていたのがそのショートカットだったということもありました。「どうやってあの2つの文字を入れ替えたの? コマンドは何だったの?」と聞かれたので、私も同じように聞くようにしているのです。時間を作ること。先ほど言ったように、私たちは時間を作るように努めています。実際に使う本物のものを作るようにしていますし、たとえ買えるものであっても、自分たちのツールを自作するようにしています。たとえ自分がユーザーであるだけだとしても、自分のツールを自作すること自体がさまざまな機会をもたらしてくれます。そして最後に、賢い人たちとの関係を育むことです。オンラインでフォローしている人であれ、一緒に働いている人であれ、個人的な友人であれ、私はAIの世界で何が起きているかの多くを、常にリンクを送ってくれる少数の人たちから学んでいます。「これ見た?」とか「これ、気に入りそうな論文があるよ」といった具合です。それを聞くと、トレッドミルで聞くのが楽しみになります。もちろんソーシャルメディアもチェックしていますが、それだけではなく、本当に賢い人たちとの関係を持つこと、それがオンラインであれ対面であれ、このパネルにいる人たちも含めて、それが本当に大きな助けになっています。
Richard Seroter： 皆さんはお二人とも、それを実際の仕事の一部にすることの重要性に触れましたね。つまり、仕事とはまったく切り離されたツールや事柄を見ているわけではないと。それによってより馴染みやすくなるのでしょうか。実際に取り組んでいる仕事の一部を解決するものであることが、決定的に重要なのでしょうか。
Aja Hammerly： 今自分が抱えている問題を解決してくれないツールに対しては、モチベーションを保つのが難しいですね。
Richard Seroter： Addy、あなたはどうしていますか。どうやって新鮮さを保ちつつ、同時に本来の仕事もこなしているのでしょうか。
Addy Osmani： 私はこれについて、自分に「イノベーション予算(innovation budget)」を与えるという形で対処しています。私は非常に意図的に、まったく新しいツールを試すための時間は有限だと考えるようにしています。ですから、何を試すかについては非常に厳選していて、それが実際に自分の生産性向上に役立つかどうかをきちんと見極められるだけの時間を確保できるようにしています。もう一つの側面として、今私たちは大きな収束(convergence)を目にしています。複数のエージェントのオーケストレーションや管理を助けようとするコーディングツールを見てみると、今やそのUXは互いに非常によく似てきています。ですから、もし何かを選んで、それがたまたま人気トップ5に入るようなものであれば、そこで築いたパターンや身につけた感覚は、他のツールでも通用する可能性が十分にあります。だからこそ、そのイノベーション予算を使うときには、収束していないものを探すようにしています。誰かが、他の誰もやっていないような新しいやり方でこの問題を解こうとしていないか、ということです。それが私の探しているものです。
Richard Seroter： それは興味深いですね。一方では似たものを見つけようとしていて、一つのエージェントフレームワークを知っていればほぼすべてを知っているようなものだけれど、あなたが探しているのはそうしたものではなく、まったく新しいことに取り組んでいる、いわば「左翼的」なものなのですね。
Addy Osmani： その通りです。
5. コードからプロンプトへ:仕事の質と仕様設計の転換
5.1 「書く」から「意図を伝える」への意識転換
Richard Seroter： 先ほど、私自身が検索からプロンプトへと不器用に移行しようとしている話をしましたが、ここで改めて考えたいのは、開発者全体として「自分はもうコードを書いているのではなく、プロンプトを書いている」「仕様を書いている」ということを、どう捉えるべきかということです。LLMやハーネスの出力を、いわば読み取り専用のコードのように扱い、もし気に入らなければコードそのものではなく、プロンプトやコンテキストの方に戻って修正する。これは奇妙な意識の転換です。Aja、「コードを書く」ことから「コードに変換される意図を書く」ことへの移行、これはほとんどアイデンティティの転換のようなものですよね。私たちはどうやってその移行を進めればよいのでしょうか。
Aja Hammerly： これは100%、アイデンティティの転換です。そしてメンタルモデルの転換でもあります。なぜなら、コードが解決策にたどり着くまでの道筋について、ある程度のコントロールを手放さなければならないからです。だからといって、責任あるエンジニアであることをやめてよいわけではありません。そのコードをレビューしなくてよいわけでもありませんし、そのコードが正しいことを確認するための仕組みを整えなくてよいわけでもありません。ただ、それらはすべて、もともとあなたのプロセスの中に組み込まれているべきものです。私にとってこれが本当に腑に落ちたのは、1年半ほど前に、これが本当に得意な人が作業する様子を見たときでした。その人は、自分が思い描く最終状態を説明していました。というのも、私がコンピュータの世界に入ったのは、かっこいいものを作りたかったからです。おそらく私たちのほとんどがそうだと思います。そしてその後、「では、どうやってかっこいいものを作るのか」を考えるようになりました。構文は何か、言語は何か、フレームワークは何か、依存関係として何を取り込む必要があるのか、といった具合です。ところが、私が見ていたその人は、Googleのエンジニアではなかったのですが、私たちのコード生成ツールで非常に成功を収めていて、「自分はかっこいいものを作るためにここにいる」という原点に立ち戻っていました。そして、自分が思い描いている最終状態を、詳細に説明していたのです。何を作りたいのかを語っていました。人はこれを「スペック駆動開発(spec-driven development)」と呼んでいます。私自身は、あらゆる開発はもともとある程度スペック駆動だったと思っていますが、構文や特定のライブラリから頭を切り離し、自分が解決しようとしている問題そのものに強く集中するように、考え方のレベルを引き上げなければならないというのは事実です。そして、それは一見すると当たり前のことのように思えますが、実際にはとても難しいことなのです。私が何度もこういう経験をしているかと言うと、たとえば昨日もAntigravityで作業していて、「いや、そのやり方でやってほしいわけじゃない」と思ったことがありました。そこで一旦立ち止まって、「なぜAntigravityがあなたのやり方ではなく、私のやり方とは違うアプローチを取っているのか、話し合おう」ということになりました。すると、「ああ、こういう依存関係の事情があって、このバージョンの方が速くなるんだ」ということがわかり、「では、あなたのやり方でいこう」となったのです。しかし、20年間ソフトウェアを書き続けてきた身としては、それはどうもしっくりこない感覚なのです。そして、私たちはこれがいかに難しいかについて、あまり語っていないと思います。人々は、プロンプトというのはただ話しかければうまくいくものだと思いがちです。それは事実ではあるのですが、問題について非常に明確で、かつ正確な説明ができていなければなりません。それは私たちの多くにとって難しいことなのです。
Richard Seroter： もちろんですよね。Ciera、あなたはどう考えていますか。品質という属性についても考えたいのですが。時には、コードを自分で書くことにこだわりたいと感じることもありますよね。それによって信頼できると感じたり、一定の品質基準を保てると感じたりするからです。プロンプトへと移行していく中で、そうした属性についてどう考え方を変えればよいのでしょうか。
Ciera Jaspan： 私はこれが、私たちをプログラマーからエンジニアへと押し上げる強制的な機能(forcing function)になるかもしれないと考えていて、その点が気に入っています。コードは依然としてそこにありますし、私たちはそれが高品質であることを確認し続けなければなりません。しかし、品質というのは個々のコード行だけの問題ではありません。システム全体がどう組み合わさっているかという問題でもあります。そもそも、このシステムはユーザーが抱えている問題を本当に解決しているのか、ということです。これらすべてが品質の側面であり、それは今も非常に重要であり続けています。では何が大きく変わるのかというと、私たちのメンタルモデルは、もはや誰にとっても単なる「コード」だけの話ではなくなるという点です。あなたは本物のエンジニアでなければなりません。プロンプトを書くとき、自分が作ろうとしているものは何なのか、問題をどう分解するのか、どんなトレードオフに取り組むことになるのかを考えなければならないのです。
Richard Seroter： Addy、プロンプトとコード、あなたの頭の中はどちらに向いていますか。
Addy Osmani： この最終状態の話の上に積み上げて考えると、私たちは本当に自分が何を求めているのかをわかっているのか、という問いが浮かんできます。そして、その問いこそが、「完了(done)」とは何か、「良い(good)」とは何かを本当に真剣に考えるための良い強制機能だと思うのです。というのも、「完了」は機能的に正しいということを意味している場合があるからです。しかし、それはフロントエンドやUIが優れて見えるということ、読み込みが速いということ、心地よく使えるということ、アクセシブルであるということ、あるいは経験豊富なエンジニアである私たちの頭の中で技術的に「完了」を意味しうる他の要素を、必ずしも含んでいません。しかし時々、私たちは長い仕様書を書いたつもりになっていても、そこにこうした他の次元がすべて含まれていなければ、私たちはLLMに「では、あなたはどういうつもりだったのか、推測してほしい」と委ねてしまうことになります。過去のセッションから私が意図したことを推測できるか、それとも他に何か考えがあるのか、と。ですから、こうしたことすべてが、私たちが本当に求めているものをより明確にし、それを可能な限り自分の仕様の中にきちんと成文化する助けになっていると思います。
6. 今後への期待とクロージングメッセージ
6.1 これから期待していること
Richard Seroter： 最後にもう少しだけ質問させてください。この後は会場に残りますので、私たちに異論をぶつけに来たり、文句を言いに来たりしていただいても構いません。まず一つ目の質問は、AIによってこれだけ多くのことができるようになった今、皆さんが実際にワクワクしていることは何かということです。もしかしたら、先ほど話した「摩擦点から解放される」という話かもしれません。すでに皆さんの仕事に影響を与えていること、あるいはこれから影響を与えてくれそうだと期待していることを聞かせてください。Aja、あなたが本当にワクワクしていることは何ですか。
Aja Hammerly： 二つ挙げてもいいですか。一つ目は、新しい技術への参入障壁がぐっと低くなったことです。最新情報の追いかけ方についてはこれまでも話してきましたが、実は「追いつく」こと自体も簡単になったのです。以前なら1週間かかっていたような、新しいフレームワークや新しい技術スタックを、今なら30分で試すことができます。学習のための使い古された練習問題ではなく、実際の問題に取り組むことができるのです。これは私にとって本当にワクワクすることです。なぜなら、今まで試す時間がなかった新しいことを、今はたくさん試せているからです。そして二つ目にワクワクしているのは、私の役割に特有のことかもしれませんが、おそらくそうではないと思います。それは、自分にはこんなことはできないと思っていた人と一緒に座る時間を、本当に楽しんでいるということです。多くの場合、その人たちはテック業界にはいるけれども、コードを書く人ではありません。あるいは、自分は絶対にコーダーにはなれないと感じています。そういう人たちが、自分の日々の仕事に役立つ、自分にとって価値があると思えるものを作る手助けをすること。それを日常的にできているということ、これは本当に最高です。誰もがこれを、自分の職場や役割によっては同じようにできるはずだと思います。私は、人々が自分にとって価値のある最初のものを作り上げる瞬間を見るのが大好きなのです。
Richard Seroter： いいですね。Addy、あなたは何にワクワクしていますか。「今、これを違うやり方でできるようになった」あるいは「将来を見据えたときに、これができるようになるとわかっている」というようなことは何でしょうか。
Addy Osmani： 自分のツールと一緒に仕事をすることに、これほど生産性を感じ、これほどワクワクしたことは他に思い出せないくらいです。それと同時に、これまで以上に疲れも感じています。その大きな理由の一つは、今バックグラウンドエージェントや並列エージェントを使えるようになったことです。会場にいる方々の中にも、ここに来ている間に、家でエージェントを走らせて、いろいろなクールなものを作らせている人がいるかもしれません。それはある意味、すごいことだと思います。スマートフォンでもノートパソコンでも、どこにいてもそれができて、蓋を閉じても動き続けている。それは本当にすごいことです。同時に、複数のエージェントを走らせているからといって、自分自身が複数人になれるわけではないという現実にも向き合わなければなりません。私たちの認知的な帯域幅は、同じようには並列化されないのです。ですから、私たちはそのためのパターンを構築していく必要がありますし、自分自身に対して少し忍耐強くなる必要もあると思います。
Richard Seroter： あなたは「オーケストレーションの税(orchestration tax)」について語っていましたよね。20体のエージェントを自分の頭の中だけでうまく管理することはできません。私たちの能力は有限です。それをどう自分の中で管理しているのですか。それとも、自分の限界をただ知っているだけなのでしょうか。ここまでならこなせる、という感覚を。
Addy Osmani： 私がこれをどう乗り切っているかというと、バックグラウンドエージェントに任せても構わないと思える、独立したタスクを定義するようにしています。そして、認知的な帯域幅を必要とする、もう少し注意を要するタスクについては、非常に意図的に自分自身で選び取るようにしています。おそらく複雑さがあるのはそちらの部分だからです。これまでのところ、こうした切り分けによって、私は正気を保ちながら、これをうまく乗り越えられていると感じています。
6.2 明日からできること
Richard Seroter： それでは素晴らしいですね。最後にもう一つだけ、皆さん全員に質問させてください。私たちはここまでいくつかの持ち帰りポイントについて話してきましたが、Ciera、明日、皆さんに何か一つ持ち帰って実践してほしいことがあるとしたら、それは何ですか。「これだけをやってほしい」という一つのことです。それをやれば、きっと明日、皆さんは幸せになれるはずです。結局のところ、それこそが私たちがここに集まっている理由ですから。どうすれば皆さんは明日、幸せになれるでしょうか。
Ciera Jaspan： 私は、Addyが先ほど触れていた「認知的負債(cognitive debt)」という考え方をもう一度取り上げたいと思います。ぜひ皆さんに、Margaret-Anne Storeyが書いた「3つの負債モデル」についての論文を読んでいただきたいのです。彼女はそこで、技術的負債、認知的負債、そして意図の負債(intent debt)について論じています。ぜひ調べて学んでみてください。そして彼女は、AIがこれらすべてをどう加速させるかについても語っています。それは物事を良くする方向にも、同時に悪くする方向にも作用しうるのです。そして私が皆さんにやってほしいのは、その論文を読んで、AIを使ってどうすればこの状況を実際に改善できるのか、技術的負債を減らし、認知的負債や「認知的降伏(cognitive surrender)」を実際に減らしながら、自分自身をそのループの中に留めておくにはどうすればよいのかを考えてみることです。同時に技術的負債の問題にもきちんと対処しながら、です。
Richard Seroter： それはいいですね。Aja、明日、人々が実践すべきことは何でしょうか。
Aja Hammerly： 私は完全に実践的な話をしようと思います。今、皆さんが定期的にこなしているけれど、まったく喜びを感じない作業を一つ思い浮かべてください。そして、私たちが1年前に発表したツールのどれかを使って、その作業にかかる時間を減らせないか試してみてください。私自身、繰り返し作業をするたびに、今でもこのプロセスを続けています。「これは自動化する価値があるだろうか」と。自動化のコストは今、格段に低くなっていますし、自分が楽しめることに時間の大半を使えるようになったことで、私の生活はより良いものになっています。
Richard Seroter： 素晴らしいですね。Addyはどうですか。
Addy Osmani： 自分に思い出させてほしいのは、「忙しく感じること」と「実際に生産的であること」は違うということです。20体のエージェントを走らせて、非常に忙しいと感じることはできます。しかし、それは実際に生産的な仕事を成し遂げていることを意味するわけではありません。ですから、自分の時間をどこに使っているのか、何個のエージェントを並列で走らせようとしているのかについて、非常に意図的であってほしいと思います。
Richard Seroter： いいですね。私からも一つ付け加えるなら、皆さんに喜びをもたらすことをやってみてほしいということです。私は2時間前に、AI Studioの中でAndroidアプリを一つ作りました。それだけで幸せな気分になれたのです。ですから、自分がなぜテクノロジーを愛しているのかを思い出させてくれるようなことを、ぜひ見つけてみてください。というわけで、登壇してくださった皆さんに感謝します。本当に信じられないほど賢く、洞察に満ちた方々でした。私たちは皆、共に学び続けています。好奇心を持ち続け、謙虚であり続け、そして共にこの道を歩んでいきましょう。ありがとうございました。