【12/30更新】この投稿は、私が所属するKDDIテクノロジーで行っているアドベントカレンダーの最終日12月25日(クリスマス)の記事となります。他の記事はこちらです。
今年の私のアドベントカレンダーは 「NotebookLMで60ページ超の登壇スライド作成してみた」も投稿しております。またこちらの方法で作成したのがこのエントリーのスライドですので、併せてご覧いただけると幸いです(全スライドをスライド形式にしたものは最下段に掲載しています)。
本エントリーは、2025年12月5日にOkinawa Open Daysの基調講演「開発が変わる！ミライが変わる!生成AIのイマ ～消えるアプリ、なくなるプログラマー、かわる学び」として登壇した内容を公開するとともに、その内容の解説記事となります。なお、登壇の前半は、昨年のQiitaアドカレ最終日に投稿した「生成AIアプリの進化について考えてみる その3「ポストスマートフォンと属人機」 をベースにしていましたので、その続きからの紹介となります。
なお、本エントリーは嶋個人の見解と妄想に基づくものであり、所属組織の公式見解ではありません。ご了承ください。
目次
- 誰のためのインターネット
- なくなるアプリ (12/26 update)
- なくなるプログラマー (12/27 update)
- かわる学び (12/27 update)
はじめに
インターネットが「人のためのもの」ではなく、「AIのためのものに」に変わりつつある、と言って信じてもらえますでしょうか?
そして、スマートフォンからアプリが無くなり、そのためプログラマーもなくなり、よって技術の学び方も変わっていく、という将来を想像できますでしょうか?
そんな未来への大きな変化が起きている「イマ」を皆様と共有したいと思います。
言葉は煽っているものの、実は今と変わらないので大丈夫です、という安心エントリーです。
誰の為のインターネット
インターネットが生成AIにより変わりつつあります。
インターネットが「人のためのもの」ではなく「AIのためのものに」になりつつあります。AIエージェントがアプリケーションのように動作する「エージェンティックWeb」という言葉も生まれています。その状況を紹介させて頂きます。
インターネットの登場からしばらくしてWebが普及し、Webはインターネットの情報を「人が閲覧」するアプリケーションとして、広く普及しました。その中でも検索というサービスは、情報生活の中で最も多く利用されるキラーコンテンツです。
また利用者だけでなく、インターネット上のビジネスを行う人にとっても、検索というサービスは重要な役割を担っています。ビジネスを成功させるには、できるだけ多くの方に自身のサービスを知ってもらい、そして、気に入ってもらう必要があります。そのために、自身のWebサイトの閲覧数を増やすことが一つの手段となります。
これがビジネスの成功を左右するほどとなった今、検索サイトの上位に表示されるようなWebサイトづくりを行うSEO(Search Engine Optimization)対策が広く行われています。上位に表示されるためには、人にわかりやすいWebサイトとなっているか、複数のサイトで情報が正しいかどうか(コンテンツパリティー)、他のサイトからどれだけ注目されているか(PageRank)、等々の基準に合致することが必要です。そしてこの基準はWeb検索が「人が閲覧すること」を前提に作られているのです。
ところが最近は「ゼロクリック問題」という問題が発生しています。
それは、旧来の「Web検索」に代わって、広くインターネットで提供されている「AI検索」のサービスが引き起こした問題です。従来の代表的な検索エンジンはインターネットをクローリング(巡回)し、Webの情報を集めてインデックス化してデータベースにしています。利用者がWeb検索としてこのデータベースを検索すると、Webサイト名やURLリンク等を抽出(クエリー)し、画面に表示します。利用者はそのURLリンクをクリックすることで、Webサイトを閲覧することとなり、内容が確認できるようになります。
一方、AI検索は、そのクローリングした情報を参考にして、回答を生成AI(ここではLLM)に作成させて表示します。もはやその作成した文章にユーザーの求める答えが含まれてしまっているため、利用者はその内容で満足してしまい、その先のサイトをクリックしなくなります。これがゼロクリック問題です。
具体的には、Google検索を行うと、検索結果の上部に出ている「AIによる概要」表示がその実体です(図中の青枠の中)。
なぜ問題かというと、Web提供者としては自身のWebサイトに訪問してもらわないとビジネスにならないためです。
AI検索が普及してしまった後の世界では、従来どおりの「人間に見られるための最適化(SEO)」は意味をなさなくなり、AIにどれだけ自身の情報を含んだ形で推論させるかどうかが重要になってきます。「AIに見られるための最適化(AEO、LLMO、GEO等)」が必要になります。それらの対応策としてのAEO、LLMO、GEOなどの議論は始まったばかりで、現在様々なチャレンジが行われているところです。(効果についてもまだ議論されている最中であり、AIに見られるための最適化もGoogleは従来の基準を踏襲するという話もあるようで、導入は慎重に。ここでLLMO等を推奨しているわけではありません)
Webはもはや「誰」のためにあるのか分からなくなってきました。
Webサイトのコンテンツは、人に見られるよりも、AIボットに参照してもらうことに注力して、より多くの情報をLLMに含んでもらうためのものに変わるでしょう。つまり、Webサイトは人間が「見る」場所から、AIが学習するための「情報置き場」となりつつあります。
Webサイトは人間にとっての見栄え(視覚デザイン)よりも、ボットにとっての見栄え(構造化)などが大切となり、その先にあるのは「WebはAI検索のための巨大なデータストレージ空間」という考え方につながってきます。
また最近は、生成AIサービスや、AIエージェント間で連携を可能にする通信プロトコルである「MCP(Model Context Protocol)」が注目されています。これはエージェントが語りだす新しい「ことば」のようなものです(実際はプロトコルですが)。どのようなサービスやエージェントからでも、集めたデータが参照できるようになると、ますますWebはエージェントを動作させるための「ストレージ」としての色が強くなります。
もう一つショッキングな事実として、2023年にImpervaから出された報告にある「インターネットの中を流れるデータの48.6%は、人間でなく機械(ボット)が発したものである」というものがあります。そしてこの翌年には50%を超えて、事実上インターネットを利用するのは人間でなく、ボットが主役となっています。
コンテンツも2026年には90%がAI生成により生成されたものとなるという予測も出されており、ますますインターネットの主体が、人間からAIによるものに移っていきます。
AIエージェントは、人間の指示に基づき、複数のサービスやAPIを横断して、目的を自律的に達成するソフトウェアです。このAIエージェントの実行環境について考えてみます。
PCの場合は、ストレージはハードディスク、処理演算はCPU、それらを抽象化した実行環境上OSで「ソフトウェア」がアプリケーションとして動作します。一方、自律的に動作を行うAIエージェントは、MCPを介することで、Webをストレージとし、GPU上で動作するLLMを処理演算装置(CPU)として動作し、まさにAIエージェントは生成AI実行環境上の「アプリケーション」として振る舞うようにも見えてきます。
このように現在生成AIの影響を受けて、インターネットも、Webも、ともに新しい進化中(様相の変化中)です。このような生成AIにより変わるWebの姿は「エージェントのWeb(エージェンティックWeb)」と呼ばれ始めています。人間が使うだけのWebから、AIエージェントがWebを使い、より新しいインターネットの形が定義されていく未来があるのではないでしょうか。
なくなるアプリ
生成AIの進化により、将来スマートフォンから、現在の「アプリ」というソフトウェアの単位が無くなってしまう未来があるかもしれないという、私の妄想パートです。
みなさんのスマートフォンを操作するときは、必ずアプリを起動して操作を行います。しかし、待ち受けやランチャーに並ぶアプリのアイコンの数が多すぎて、なかなか目的のアプリが見つからず、操作ができずに困った経験が一度や二度はあるのではないでしょうか。
この課題解決を生成AIを活用してできないものか、端末の属人性(昨年のアドカレ参照) として、ヒトが考える(悩む)部分を生成AIが巻き取り、人に寄り添った動作ができるようにならないのか、これが私の考える課題設定です。
これが解決できれば、目的に応じてアイコンを選択しなくてはならないという「アプリ中心」の体験から、解き放たれる可能性があると考えます。もちろん、まだ妄想ですが。
アプリごとに入り口を選択するのではなく、生成AIにより準備される「唯一の入り口」からスマートフォンの利用を開始し、そのあとの(従来人がアプリとして使い分けていた)機能は、スマートフォン側で自動的に取捨選択され、必要な機能の画面が表示されて、動作するような世界観です。
この「スマートフォン側で自動的に選択」することで、本来人間が考えることを生成AI側で巻き取り、ヒトに寄り添う動作を実現します。まさに属人機であり、これを行うのがAIエージェントであると考えます。
これにより、理論上はアプリの切り替えという概念すら無くなります。やはり、まだ妄想ですが。
しかし、妄想だと思っていたこの世界観に対して、少しずつ技術が追いついてきました。
その一つが、毎年Googleが開発者向けに開催している年次開発イベント「Google I/O」で、今年発表された「Gemini Diffusion」という生成AIのモデルです。このモデルは、画像生成で用いられているDiffusionモデルを自然言語/プログラムの生成に応用したものです。
これは従来のLLMに比べて、推論速度(トークン生成速度)が段違いに高速です。公開されたデモストレーションだと、HTMLとCSSの一画面の生成が、瞬きする程度(100msec程度?)の間に、まさに「あっ」という間に生成しています。実際試しても、生成だけならばそれに近い速度で実現できています。
すると、従来のアプリのように「画面は事前に作成しておき、必要な時に作り置きの画面を表示する」のではなく、「利用者の操作で、必要になったタイミングで「即時アプリ生成」が行なわれ、適切な画面を表示させる」という事もできそうになってきたと期待してしまいます。
このように、リクエストがあった時に逐次生成しながら実行するスタイルに、勝手に名付けてみました。Just-in-Time Application Generation (JAG)です。私の造語ですので、軽くあしらってください。
JIT(Just-in-Time)というと、プログラムを事前にコンパイルすることなく、実行時に必要な部分を都度実行可能なバイナリーにしながら処理を進める昔ながらの仕組みです。ここでは必要となったアプリの機能を、都度表示可能な画面を即時生成しつつ処理を進めていくことと想定し、このJITと組み合わせてJAG(JIT-AG)という言葉を使わせてもらいました。
そして次に問題になるのが、(表示のソースコードが自動生成されるのは良いとして)どのような機能と内容を画面に表示するべきか、という点になります。
上記の図中では「京都旅行の計画を立てて、友達と共有したい」という指示の場合、上は地図に候補ホテルが表示され、下にカレンダーが表示し、そこで決定したものは後ろでSNS機能が待機していて共有できるような機能が準備されている、といったような動作の例の図を描いています。つまり、この状況(Just Time)で利用者が必要となるであろう機能(function)として、必要なカレンダー機能とマップ機能が動的に選択されて、画面のレイアウトも生成AIが構成して表示しているのです。当然、そのようなことができるソフトウェアはこの世に存在しません。しかし、作らせ方は想像できます。生成される画面の要素は 利用者のナラティブ体験をもとに生成されることとなります。
生成AIのサービス開発の一角では「ナラティブ体験」というキーワードが使われます。さまざまな解釈がありますが、ここでは「人に寄り添い、深いパーソナライズに基づいて紡ぎ出される個人の物語」と解釈します。つまり、生成AIサービスを利用する際に、サービス構築する際に作成されたあらかじめ用意されたユーザーストーリーに沿った使い方を強いるのではなく、あたかも自分がそのタイミング、その環境で行いたい事が、自分から自発的に物語(ストーリー)として紡ぎ出されて、その物語どおり(ここでは)システム側が寄り添うように動作してくるような環境を意味します。これにより、個人に肯定的な行動変容を促すことをナラティブ体験と呼びます。
(2024年Qiitaアドカレ 生成AIアプリの進化について考えてみる その3「ポストスマートフォンと属人機」より一部修正 )
これを実現するためには、ユーザーが体験してきた「文脈(コンテキスト)」が重要となります。まさに最近生成AI業界で叫ばれている「コンテキストエンジニアリング」そのものです。
図らずも、アプリケーションとして動作するAIエージェントはMCPにより連携され、現在各AIサービスで実装が広がって話題絶頂のAgent Skillsを用いてアプリ単位の動作するための機能(スキル)が自動選択され、動作するような世界観も作り上げられそうです。
またGoogleは Function Gemma というモデルが先々週の12/8に公開されました。これはスマートフォン上でオフライン動作する、機能呼び出し(function calling)専用のモデルです。つまり端末の様々な情報をベースに、動作させるべき機能を自動選択(function calling)できる専用のモデルであり、skillsとともにJAGを実現するための基本技術となりえます。着実に世の中がそちらに動き出しているのではないかという片鱗を各所に感じます。
妄想も少しずつ最新の技術で、もう少し形のはっきりした妄想に変わりつつあります。そして新しい技術に刺激され、より新しい期待を生みます。それこそが、また妄想なのですが。
このような時代には開発者は「コード」を作るのではなく「コンテキスト」を作り出す役割となるでしょう。
従来のソフトウェア開発では、開発者は事前にユーザーストーリーから実現したいものを定義し、それを実現するソフトウェアの仕様書を作成していました。このユーザーストーリーは、多くのカスタマージャーニー(利用者の行動の洗い出し)から、多くの人が最大の価値を得られるようなストーリーを作り出します。なぜならば、ここに続くソースコードから機能と仕様を実装する従来のソフトウェア設計だと、万人に同じ画面を表示して提供するしかありません。多くの人の多くの場面で使いやすくする必要があるからです。その反面、特定な場面の特殊な状況では使いにくくなっており(切り捨てるカスタマージャーニーの苦しみは企画者の共通課題であり、実は付加価値創出活動である)、特定な文脈、特殊なコンテキストでの対応はあきらめざるを得ないのです。つまり、アプリやサービスの提供側が想定したユーザーストーリーを利用者に「押し付けている」構造となっているのです。
これが生成AI時代には、利用者の意図を文脈から読み取り、それに合わせた物語を作り出すようにAIエージェントが動作し、「利用者側から紡ぎだされるユーザーストーリー」が、そのまま利用者のナラティブな体験につなげます。まさに利用者側の紡ぎだされるストーリーに、サービスやアプリ側が寄り添うこととなります。まさに人に寄り添う属人性のあるサービスとなります。
生成AI時代の開発において、アプリを作る事は、ナラティブな体験そのものをデザインする事となるでしょう。開発の役割が変わりそうです。まだ妄想の世界ですが。
このようにアプリが消えても開発者は消えません。生成AI時代になってより一層感じることは、一人で開発できる範囲がとてつもなく広がった、という事です。従来は何チームも束ねて開発しなくてはならないソフトウェアでも、ある程度要件を緩めれば一人で開発できるような時代になりつつあるという事です。
それに伴って、単にソフトウェアを作るだけの価値は低くなるでしょう。その作り出したものが、どれだけ利用されるか、ビジネスとして意味があるものになっているのか、人の役に立っているのか、そういうものが大切となります。開発者は一人でできる範囲を広げていき、ビジネスや開発の所掌を自ら拡張できる人が必要とされ、今後はコードを書く人から価値を創造する人へと進化していくことが予想されています。そして、自身もそうなりたいと考えており、そういう未来に期待しています。
参考までに。このようなアプリケーションが無くなる世界観の妄想は、私がゼロから考えたものではなく、8年もの前にOpenAI創設メンバーの一人Andrej KarpathyによりSoftware2.0として提唱されていたものです。この話自体も今年のインターロップのパネルディスカッションにて、パネラーの登壇者に教えてもらったものです。
ここまでの「アプリが消える日」について、内容を一枚シートへまとめました。
ちなみに、アイコンメニューに代わる、生成AI時代の唯一のスマートフォンへの入り口は、どのようなものになるのでしょうか。まだそれはわかりません。少なくとも、現状の生成AIへの入り口として主流になっている「チャットボックス」ではないことは確かです。
アバターが表示され、そのバーチャルヒューマンと対話するようなインターフェイスを実現しようとする取り組みも、多くの方々が現在チャレンジしています。XRグラスで空間に溶け込むような入り口を検討している方々もいます。あくまでもアイコンメニューにこだわりつつ、そこから生成AIの入り口を検討している方々もいます。まだ未知の可能性でいっぱいです。
余談ですが、本スライドシートの多くは生成AIツールのNotebookLMを利用しています。上記は青い四角形で塗りつぶしていますが、「未来の究極のインターフェイス」というお題を出したところNotebookLMは、スマートフォンの上にドラえ●ん(らしきロボット)の画像を描いてきました。沖縄の登壇でもさすがにその部分はまずいので墨にして掲示しました。
なくなるプログラマー
生成AI時代は、プログラマーがなくなるのでしょうか。ここでは生成AI時代のソフトウェア開発スタイルを整理して、今後起こるであろう未来を予想してみます。
昨今はバイブコーディングといわれるような、ざっくりと言葉で指示するだけで、アプリが作れる時代になりつつあります。
例えば図にあるように、「沖縄の美しいビーチを表示するシンプルな地図アプリを作成して」と指示するだけで、マップにビーチの場所をプロットしたようなアプリケーションが、人の介入なく作成できてしまうのです(失敗も多くありますが)。気に入らなければ指示を変えたり追加して、生成を繰り返します。このような開発スタイルをバイブコーディングと呼びます。
生成AIを活用した開発をする場合は、大きく二つの開発手法が存在します。一つは「AI支援開発」と言われCopilot(副操縦士)といわれるもの、もう一つは「AI駆動開発」と言われ、AIが主体的に開発するものです。
このあたりの言葉の定義は、まだ出てきたばかりの言葉であるため厳密には定まっていません。世の中では、様々な文脈で、微妙に異なる意味として利用されています。本記事では、以降の記事で誤解を生まないために、言葉を定義したものとして進めさせてもらいます。またこの二つの言葉は二律背反になるものでもなく、AI支援開発寄りのAI駆動開発なども、あたりまえに存在しているため、この辺りは緩く考えてください。
AI支援開発は開発者がコーディングの主体であり、GitHub Copilotの初期から搭載されている機能などが代表的なものとなります。
AI駆動開発は、人間が自然言語で仕様を伝えると、AIエージェントが自律的に分解して、計画実行修正を行い、最終的にコードが生成される世界です。人の介入は必要最低限にすることができます。
また、このAI駆動開発は、再び二つのアプローチ(開発スタイル)に分かれます。ひとつはバイブコーディング、もう一つはエージェンティックコーディングです。「なくなるプログラマー」章の冒頭で紹介した沖縄アプリのように、一言作りたいアプリを言うだけで、実行できるアプリを人の介入なしに、最後まで作り上げてしまうのがバイブコーディングです。これはソフトウェア開発を、プログラマーだけから誰でも作れるように民主化した手法であるともいえますが、課題も多数あります。
完全に人の介入なしにバイブコーディングをしようとすると、期待するものが出てくるまで何度も何度も繰り返し生成させることとなります。まさに、トークン利用料を対価(または課金)とした、ひたすら回し続ける「ガチャ」のような様相となります。また動かないものが出てくることも多くあります。このような苦難に耐えられる、プロトタイピングやアイデア検証などで有効であるとされています。ただし、ちゃんとしたソフトウェア(この言葉の定義もあいまいですが)を開発するには課題があります。
エージェンティックコーディングというスタイルは、自然言語で入力してソフトウェアを出力させる部分はバイブコーディングと同じです。しかし、より出力の成功率が高くなるように、AIエージェントが設計計画を立て、開発しやすいように機能分割を行い、それらの機能のテストを実施して不具合が無くなるように、自律的に開発を進めるというものです。
AIエージェントが行っていることは、ソフトウェアプロセスのベストプラクティスそのものであり、このAIエージェントの動作を、どれだけ高められるかどうかが、AI駆動開発で成功する道であると考えています。
バイブコーディングのガチャの場合は、ハズレの(失敗した)場合も、その経験は生かさずに、再びゼロからチャレンジしなおします。そのため、いつまでたっても同じ失敗を繰り返し、改善のしようもなく、機能実装の成功確率も変わりません。しかも、実装機能数が大きくなるにしたがって、消費するトークン量も大きくなります。実装完了が運任せだと、一体いくら開発費をかければ、完成するのか不明となってしまいます。それでは仕事になりません。
逆にエージェンティックコーディングならば、失敗したところは知見としてAIエージェントの開発プロセスに入れることで次回の改善につなげます。すると、成功確率があがり、最終的には消費トークン数が少ないソフトウェア開発ができるようになります。
生成AI時代の開発における真の勝負は「どれだけ少ないトークン数で品質の高いアプリが作れるか」になってきます。ただ作れるだけではダメなのです。低コストで、品質が高いものが必要なのです。
・・・あれ? いままでのソフトウェア開発と何も変わっていませんよね。
しっかりとソフトウェア開発するには、エージェンティックコーディングが適しています。
もちろん、エージェンティックコーディングもAIエージェントがポンコツだと、結果もポンコツになってしまいます。そのため、AIエージェントにプロセスを教え、ルールを定義していく(rule.mdやmanifestなどの共通開発ルールなどの定義)ことが、もっとも効率よくソフトウェアを作るための手段の一つとなります。
もちろん、バイブコーディングよりエージェンティックコーディングが必ず良いというわけではありません。エージェンティックコーディングのAIエージェントが目的の生成物に対して、過剰なルールを定義したり、必要ないドキュメントを大量に生成させる設定になっていると、トークンを不必要に消費してしまいます。そのため、適切なプロジェクトに適切にAIエージェントを動かせることが必要となります。(先週KDDIグループのテックカンファレンスKGDCにて弊社のメンバーから仕様駆動開発のエージェンティックコーディングの「ダメだよ」という点について発表があり、以降表現に気を付けるようにしています。日々勉強)
それでは、どのようにルールを定義すれば良いのでしょうか?
まず参考になるのは、ド定番の「ソフトウェアの開発プロセス」そのものです。そういう意味では、これまで我々が行ってきた従来のソフトウェア開発と変わっていません。その開発のルールに従って動くのが、人間であるのか、AIエージェントのサブタスクであるのかの違いです。
Xで話題になっていた逸話があります。「開発担当者曰く、プロンプトやルールで指示をいくら行っても無視し、すぐに指示以外の動作を行い言う事を聞かない。これは生成AI時代の新しい最大の課題だ」「マネージャー曰く、指示通り開発者が動かないのは昔から何も変わっていない、新しくもないのだが」というパロディーのような話です。担当者さんの気持ち、とても分かります。だけど、まさになにも変わっていません。
では、プログラマーの仕事はどう変わるか?
プログラマーはなくなりません。ただし役割は変わるでしょう。
これまでプログラムコードを書いていた人は、生成AIでコードが生成されるようになると、プログラムを作らせるための適切なプロンプトを用意するために、作成要件を正確に定義する役割に代わります。
またプログラムの評価とデバッグしていた人は、AIが生成したものが正しいものかどうかを評価・検証して保証していく役割に代わるでしょう。
そして、PMなどの役割を担い、サービスやアプリケーションを実装し、正しく動くようにしていた人は、その実装物のビジネス価値を達成させるための役割に代わるでしょう。
むろん生成AIの進化が進むと、上記内容ですらヒトで行わなくてはならない範囲が小さくなるでしょうから、より開発者は広い所掌をこなす開発者へと進化していく(せねばならなくなる)と感じています。
最終的に大切なことは「アウトプットが、どうであるか」だと思っています。生成AIを使った開発も、バイブやエージェンティックといったスタイルも、すべてはアウトプットを得るための手段でしかありません。アウトプットした物が、品質が担保されているかどうか、そしてそれを作った人が責任を持てるかどうか、それが大切になります。そして責任は人間しか持てませんので、その人間が責任を持てるように、手段を適切に選択して、必要な介入(Human-in-the-Loop)を行っていく必要があります。
もう少し言わせてください。実は生成AI時代に大切なものは「気合」ではないかと思っています(根性論ですいません)。なぜかインターロップの今年のセッションや、沖縄のセッションの時も同じ言葉で、大きく反響いただいてしまいました。つまり、エージェンティックコーディングでも、バイブコーディングでも、成果物が出てこなければアウトプットはゼロです。結局、ヒトが成果物としてアウトプットを作り上げるまで、心を折らさずに、最後まで何度も挑戦し、改善し、成功をつかみ取るという行動やスキルが、この生成AI時代で一番必要なんだと感じています。
バイブコーディングでもいいんです。最後まで作り切って品質とコストがあっていれば。
・・・実はこれも、これまでのソフトウェア開発でも変わらない行動ですよね。
今後生まれるであろう新たな専門職を妄想してみます。
後段でも言及しますが、生成AIによるソフトウェア開発が進むと、ソースコードを注意深く確認して、発生しうる障害を予見できるような技術者の育成が難しくなる(コストがかかる)と感じています。逆に言うと、そういう技術を持つ人達の業界希少性の価値が上がっていく可能性があるという事です。
「生成AIでソフトウェアを作成したが、どうしても動作できるアウトプットができなく、しかし自社にソースまで介入して改善できるメンバーがいない」という場合が将来像として想定できます。そういう困った人々が駆け込む「駆け込み寺」のようなサービスも出現する可能性があるのではないかと想像しています。
また、トークン削減コンサルタントなどは、AI駆動開発がレッドオーシャンになった日には確実に必要とされる職種だと思われます。同じ成果物でもプロセスの違いで、消費されるトークン量は、かなりの差になることが予想されます。
本論と少しずれるネタで恐縮ですが、先ほど言及した「生成AIのソースコード生成できることにより、若手のプログラマーが自らプログラムを書く経験の機会が失われていく」という妄想を、もう少し掘り下げてみたいと思います。
若手プログラマが育たなくなることは、これまでソフトウェア開発の知見で仕事していたベテラン開発者の希少価値が上がってくることとなります。年齢を重ねることで知見は持っているけど、流石に商用開発をするには体力や気力が持たないという方々は多いのではないでしょうか。しかし、生成AIの成果物が妥当なのか、正しいものなのか、という点を確認するタスクならば、十分できる可能性があるのではないでしょうか。
実は私が参加しているコンソーシアムであるMCPCの懇親会が11月にあり、年配の方も多く集まる場にて、定年後の人たちを集めてこのような会社を作ろうという取り組みの話を伺うことができました。あながち妄想でもない事も確信してしまいました。
少し遊び心で、失礼な物言いをお詫びしながら言わしてもらうと「老兵は死なず、AIで転生し無双する」です。最近のアニメ風に言えば「ロートル開発者が生成AIで転生し、ソフトウェア開発を無双する」というタイトルです。あくまでも妄想です。
本資料を用いて登壇させていただいた「Okinawa Open Days」のイベント開催期間は、あいにく米国ラスベガスにて行われていたAWSの開発者イベント「re:Invent」の日程ともろかぶりとなっておりました。海外のAWSでは、エージェンティックコーディングの一つである仕様駆動開発のツール「Kiro」のアップデートが大きく紹介されていたようです。当日はその話も少し紹介させてもらいました。なおKiroの語源は、日本語の「岐路」なのだそうです。ちょっとしたネタの紹介まで。
かわる学び
生成AIによる開発が変わるように、それらを習得するための「学び」の方法も変わろうとしています。
生成AIの学びだけでなく、これまでのITプロフェッショナル/エキスパート、そしてそれらを教える教育者、そして技術リーダーなど、多くの人にとって関係するものだと感じています。その事例を含めて紹介させてもらいます。
スキルを習得する方法は数多くありますが、定番の確立された学習手法として、まずは座学を中心とした手法で知識を習得し、それを実践トレーニングし、かつ現場で活かす経験をさせる、というものです。少なくとも定番の手法で「スキル活用するまでに習得できた」となるには、この方法が現実的とされています。
しかし習得までに時間がかかってしまい、集中力が続かず途中で断念しがちです。
しかし昨今、生成AIを活用して、新しいスキル獲得の事例を見聞きしたので紹介させてください。
私が講義に行っている中央大学の担当教授の学生さんが出版された書籍「#100日チャレンジ 毎日連続100本アプリを作ったら人生が変わった」です。著者の大塚さんが、学生時代にChatGPTとともにアプリ開発の学習を行い、その後活躍されている事例となります。先生から教わるよりも、自身でのルール(毎日1アプリ開発)を決めて、ChatGPTから多くを繰り返し学びながら、自己学習していくストーリーがここにあります。
KDDIテクノロジーは石川県金沢市にもオフィスがあり、各種開発を行っています。現地のイベントとして、学生団体のWeCodeさん主催のエンジニアイベントに参加させていただいた時のことです。ある参加していた小学生がChatGPTを使ってWebアプリをバリバリ組んでおり、高校生顔負けに活躍しているのを垣間見てしまいました。聞いてみると、プログラムの習得もChatGPTで行ったとのこと。これは将来の若年層の学び方が変わりそうであることを強く感じました。特に地方でこれが起こっていた事にも大きな衝撃を受けました。効率よく学ぶためには、先生と仲間は大切なポイントですが、生成AIを使って自身で学べる事例がここにありました。
AI時代の学び方は、理論から実践をするのでなく、実践から理論を学ぶ方向に変化します。
AI時代では、まずはAIとともに実践を試します。そこでの失敗や成功の体験から、必要な知識を抽出・理解するのです。つまり、知識と実践が同時進行するため、自身が得た知識を、目の前で即時に確認できます。つまり、学んだことがすぐに実践できるため、学習の動機(モチベーション)も継続しやすくなる仕組みです。
もちろん失敗するには「失敗しても大丈夫な環境」が必要です。そのような環境をサンドボックスと呼びます。そういう意味では、生成AIは、無限に試行錯誤できるサンドボックスであり、失敗のコストを下げて、誰もが実践を通じて学べる環境が提供されているとも言えます(無限失敗の試行が許されないようなクラウド環境の場合には、プロジェクトとは別の練習環境を払い出して、生成AIとともに試行しやすい環境を提供するのも良い方法です。自社で対応して学ぶ機会を増やす良い結果が出ています)。
脱線ついでですが、バイブコーディングは教育にうまく取り入れると学習の効率が上がります。実は開発を学ぶ前に、バイブコーディングで開発の体験をしてもらいます。この取り組みで、開発の全体が少し俯瞰できたあたりに、学習を始めてもらいます。そうすると知識の吸収も早くなることを体感しています。(個別事例ではありますが)
従来は「教え、学ばせる」から、人間の能力を「自身がAIで拡張する」ような、生成AIを実践のパートナーとしたスキル習得が中心となるように感じています。求められるのは、生成AIを使いこなし、自らの能力を拡張する力なのだと感じています。
今後は、このような「学び方」を変えることから始まり、人材育成を行う基盤自体もアップデートし続ける必要がありそうです。
現在、私は大学2か所でソフトウェア工学系の非常勤講師をしています。学生と話すときに、ある失望感を感じていることに気づきます。
- プログラムの実習などの課題では、生成AIに任せたほうがよっぽど良い結果が出てくる。世の中では将来プログラミングは生成AIに置き換えられてしまうとも言われている。
- 自身が勉強しているプログラムコーディングは、将来就職した時期に役立つスキルなのだろうか。
- もしかすると、追いついていない大学のカリキュラムのせいで、自身の貴重な「今の時間」を無駄にしてしまっているのではないだろうか。不安だ。
ざっとこんなところでしょうか。しかし、学生には失望は間違いであり、実は今の状況はチャンスだと説いています。
先ほども言及しましたが、将来生成AIがコーディングの多くを担うようになるのは間違いないでしょう。だからと言って、それはスキルが世の中から必要なくなる事と同意ではありません。コーディングのスキルでソフトウェアの構造を理解したり、修正したり、また生成AIにトークン消費が最小化となるようなプロセスを定義したり、プログラムの知識を用いて、さまざまな事を行う必要があるのです。
むしろ言いたいのは、「今」プログラムを学習して、仕事でプログラムを活用する機会がある人は、チャンスであるという事です。
今後「プログラムを書く機会」が消失することで、スキルを習得したり向上させる機会が少なくなってしまいます。すると、今後これらのスキルを保有する人たちが少なくなり、スキルの希少性があがる可能性があります。
むしろ今プログラムを学習して、生成AIにプログラミングが奪われる前に自身でコーディングするスキルを身に着けた人は、プログラムがわかる最後の世代となり、前述の「生成AI駆け込み寺」のように、世界のシステムを維持する最後の砦として、もっとも重宝される若い世代となりうる可能性があります。
企業において、仕事でコードを書く経験ができるのは、今が最後のチャンスかもしれません。書くことを強いられることで、得られる基礎体力や思考プロセスは、今後生成AIに置き換わった時代には、そう簡単には習得できるものでは無くなるでしょう。それこそ、突出した興味か、長い時間が必要となります。
なので、会社でプログラムを学びながら現在プログラム書いている方は、とても貴重な時間を過ごされているとも言えるのです。あきらめないでぜひ習得を続けてもらいたいと切望します。
「失望か、好機か?」については、各々で判断するしかありませんが、私からは「好機である」という言葉を贈りたいと思います。
しかし、プログラムだけ学べば良いという時代でもなくなっているので、広く興味を持って多くの技術を経験することが必要である点も、将来に向けてのコメントとして添えています。
現在の取り組み
株式会社KDDIテクノロジーでは、生成AIやクラウドを用いた開発や、AndroidやiOSのアプリの開発まで、新しい技術を扱う仲間を、積極的に募集しています。ともに開発やPMの仕事をしてみませんか?
興味ある方は是非こちらの採用ページからご相談ください。お待ちしています。
→ https://recruit.kddi-tech.com/
登壇のスライド形式の全編
こちらの資料の表紙から予備スライドまですべて含んだ資料は下記の通り公開しています。