このページの本文へ

前へ 1 2 次へ

JAWS DAYS 2025の基調講演 内容は生成AIとの向き合い方

生成AIへの恐れ 使えば払拭できる AWSエバのメッセージは誠実で論理的で力強かった

2025年03月15日 09時00分更新

文● 大谷イビサ 編集●ASCII

  • お気に入り
  • 本文印刷

開発者とのやりとりで感じた生成AIへの「恐れと不安定さ」

 白幡氏の後に再び登壇したバー氏は、生成AIとの付き合い方について持論を披露する。
 バー氏が開発者としてコードを書き始めたときは、メインフレームやミニコンの言語を使っていた。その後、さまざまなプラットフォーム、さまざまな言語でコードを書いてきたが、「いつの時点を切り取ってみても、その時代のハードウェア、ソフトウェアを使って仕事をしている。現在のモノは非常に洗練されており、その時点ではバグも排除された完璧な状態になっている。その一方で新しい技術も出てくる。荒削りだが、開発に使うこともでき、未来を示すモノでもある」とバー氏は語る。

JAWS-UGに長らくコミットしてきたAWS VP チーフエバンジェリストのジェフ・バー氏

 こうした経緯からバー氏が得た教訓は、「過去に敬意を払いつつ、未来に対してオープンでいること」だという。不完全かもしれないが、アーリアダプターとして試行錯誤すれば、それは自らの強みになる。いつか新しいテクノロジーをいち早く仕事に活かすことも可能になる。

 開発者との交流の中で、バー氏が感じたのは「恐れと不透明さ」だ。AIのコーディングツールが登場し、最初は「すごい」と感じるが、次に感じるのは「じゃあ、自分はどうなるんだ?」という感情だという。これに対して、バー氏は「開発者はツールをつねに作り続けてきた。ツールは人をサポートするモノであり、人を置いていくモノではない。人間はまだコントロールを握っている」と持論を語る。

 バー氏は、Amazon BedrockとNova Canvasで生成した開発者のイメージイラストを披露。そのイラストで、開発者が使っているのは金槌だ。「われわれ開発者はモダンなアプリケーションを作ろうとしているのに、ときに古いツールを使うことがある」とバー氏は指摘する。時代にあったツールとは、まさに生成AIだ。

モダンなアプリケーションの開発に古いツールを使っていないか?

 バー氏はハードウェアにおける開発工程に変化について語る。Amazonが「Viturous Sycle」と呼ぶ工程では、つねに次の世代の前提に行なわれる。AWSが設計・開発したGravitonもこの工程を経ており、開発スピードは世代ごとにスピードアップしているという。

 一方で、ソフトウェア開発でも似たようなサイクルが生まれており、コンピューターが進化すると、よりリッチなソフトウェアの開発が実現される。しかも、ソフトウェアは開発のために新しいソフトウェアを生むというプロセスは当初から行なわれており、AIコーディングもこの流れに含まれる。「ここで重要なのはツールが、みなさんをよりパワフルにするということ。ツールはアシスタントであって、置き換えではない」とバー氏は指摘する。

AIはあくまでアシスタントである

 バー氏が会場に聞いたところ、AIコーディングを利用しているのは3割程度。一方で、アセンブリを使うエンジニアもいるし、汎用言語を用いているエンジニアもいるし、量子コンピューターでコードを書いている人もいた。「要はいろいろなスペクトラム(段階)があるということ。どのスペクトラムにいるべきという話ではない。いろいろな形でコンピューターとやりとりして、アプリケーションを構築できるということだ」とバー氏は語る。

生成AIはあくまでツール ソフトウェアはツールで進化してきた

 話は、開発者の定義にまで掘り下げられる。バー氏は「自己もしくはお客さまの要件を満たすコードを作成すること」と開発者の責任を定義する。また、望ましい属性として、「想定通りに動くこと」「リソースを効率的に動かして速く動くこと」「アップデートが容易で保守可能であること」「有料と言える価値を持つこと」を挙げる。

開発者の責任と属性とは?

 その上で開発者はなぜツールを用いるのか? ここで言うツールとは、言語や実行可能なファイル、プログラム、関数、クラスライブラリ、トレーニング、リファレンスマニュアルまで含まれる。「巨人の肩に乗れ」というニュートンの言葉の通り、これらのツールを使えば、開発者は先人たちの蓄積を利活用できる。「2つのツールを組み合わせたり、あるツールに別の世代のツールを重ねあわせることができる。メモリが増え、処理能力が上がれば、コンピューターのパワーもうまく使うことができる。これはソフトウェア開発のユニークな属性だ」(バー氏)。

 過去、アセンブラ、エディタ、コンパイラー、デバッガなど、ツールはさまざまなアプローチで開発を支援してきた。コードを書かず、ビジュアルでソフトウェアを開発するアプローチも何度も試されており、開発ツールを統合した開発環境(IDE)も登場した。「われわれ開発者は、これらのツールを使うことで、自分の仕事がもっとうまくできると感じるはず。あらゆるツールはステップであり、生成AIのコーディングにつながっている。AIコーディングアシスタントを使えば、より楽になることがわかるはず」とバー氏は語る。

 人類は長らくツールを作ることで、課題を解決してきた。そしてそのツールを使って、また新たなツールを作り続けてきた。開発者もその営みの中にいると、バー氏は指摘する。「世界中の開発者がさまざまなソフトウェアをコレクションのように作ってきた。これらの一部、もしくは全部を使ってLLMを作ったとしたらどうだろうか。これらをトレーニングし、ファインチューニングしていく。すべての知識、コード、単一のモデルに取り込み、開発者が利用できたらどれだけ素晴らしいだろう」とバー氏は未来を語る。

人類は課題の数だけツールを作り続けてきた

 バー氏は、「コンパイラーが私の仕事を奪う(Compilers Take My Job)」というコピーが充てられた1960年代のパンチカードのミームを披露。この恐れは、AIに仕事を奪われるのではないかという不安に通じるという。「結局、コンパイラーは誰の仕事も奪わなかった。より多くのアクセスと仕事を与えていった。ソフトウェアやAIに関しても同じだ」(バー氏)。

Compilers Take My Jobのミーム

AIコーディングアシスタントは次のメインストリームへ まずはハンズオン

 開発者向けのAIとして、バー氏はまずAIコーディングアシスタントを披露する。開発者は道具の1つとしてAIコーディングアシスタントを用い、自身の意図からコードまでの作業を迅速化できる。一方で、開発者はAIコーディングアシスタントが現時点では得られない知見や意図、判断を与える必要があるという。

 「AIコーディングアシスタントはまだ初期のモノだが、日進月歩の進化を遂げている」とバー氏は語る。AWSはAmazon Q Deveoperを提供しているが、選択肢は数多い。「さまざまなツールを試してほしい。なぜならこれは今後のメインストリームになるからだ」とバー氏は語る。

 同氏はAmazon Q Developerを用いてスポーツイベント管理システムを構築するデモを披露。フロントエンド、バックエンドの言語やフレームワーク、認証やUI、API、イベント管理、アクセスコントロールなどを指定し、さらに開発者向けのガイドまで作ってもらうプロンプトで記述して、複数のやりとりでリクエストを検証。これに基づいてAIコーディングアシスタントがプロジェクトを設計し、コードやファイル、変更履歴などを生成したら、これを人が検証する。「今まではコードを書くことが仕事だったかもしれないが、これからは監督するのが役割になる」(バー氏)。

AIコーディングアシスタントと形式的な検証

 もう1つの形態が、形式的な検証(Formal Verification)と呼ばれるもの。こちらは幾何学や数学的なアプローチでプログラムの妥当性を検証するAI。複雑なプログラムのプロパティの正しさを厳密に検証し、堅牢でスケーラブルなシステムを実現する。

 概念自体は1980年代から存在しており、近年のテクノロジー進化やコンピューティングパワーの増大で現実味を帯びてきている。バー氏は、CPROVER、Dafny、Kani Rust Verifier、Zelkovaなど自動推論を行なうリーズニングツールも紹介。「まだメインストリームにはなっていないが、3~5年には主流になってくる」と語る。

 最後、バー氏は「継続的に学び続けてほしい」「AIコーディングアシスタントをぜひ試してほしい」「形式的検証やリーズニングツールも学んでほしい」と参加者にリクエスト。「動画を見るだけ、ブログを読むだけではなく、実際にハンズオンで体験してほしい。ハンズオン体験を上回るものはない」と実践を薦めた上で、セッションを終えた。AWSエバからのメッセージを受け取った参加者たちは、それぞれの想いを胸に、各セッションにダイブしていった。

■関連サイト

前へ 1 2 次へ

カテゴリートップへ