2024年をそろそろ振り返ろうかと思いまして、ポエムってみました。
妄想ポエムです。
自分の頭の中を整理してみました。
システム構成の変遷
システム構成の変遷を自分の中で整理しました。
新しい形態が常に優れているというわけではなく、技術の進化で新しい形態が出てきたと理解しています。どの形態もなくなることはないと思います。
第一形態
最もシンプルな形態
シンプルにハードウェア＝インフラ、ソフトウェア＝アプリとなる構成です。間を取り持つのはWindowsやmacOS、LinuxなどのOSです。
１セットのハードウェアのセットの上に、複数のソフトウェアを動かすことも可能です。
第二形態
仮想化技術の登場
仮想化技術の登場で、１セットのハードウェア上に複数のOSが動くようになりました。仮想化部分はソフトウェアで実現されているので、単純なハードとソフトという区分けではなくなります。
OSの上で動作するソフトウェア層にもミドルウェアが登場します。ミドルウェアとは、RedHatのサイトで以下のように説明されています。
ミドルウェアは、オペレーティングシステムをアプリケーション、データ、ユーザーに接続するソフトウェアレイヤーです。シングルサインオン (SSO) やアプリケーション・プログラミング・インタフェース (API) 管理などの一般的なサービスと機能を提供します。開発者はミドルウェアを利用して、アプリケーション・コンポーネント間の一貫性のある単純化された統合を実現できます。これによって開発者は、レガシーシステムを含むさまざまなエンドポイントや環境に接続するのに時間を費やすことなく、アプリケーションのコア機能を構築できるようになります。
ApacheやNginx、Tomcatなどがミドルウェアに相当すると理解しています。インフラエンジニアが「Nginxのインストールしておくねー。設定はアプリ側が出してくれたらやっとくよー。」的なやり取りがある印象なので境界はミドルウェアに設定しました。
AWSをはじめとするクラウドが登場しましたが形態としては第二形態として分類しました。
構成は変わらず、仮想化層までをAWSが面倒を見てくれます。OSから上の層はお客様が管理してねという責任共有モデルの考え方です。
第三形態
AWS Lambdaの登場は革新的でした。（Lambdaは今年が10周年だそうです🎉参考）
ミドルウェア層までをAWSが面倒を見てくれるので、ソフトウェアを用意するだけで実行することができます。
AWSのサービスは組み合わせて使える「ビルディングブロック」として設計されているため、必要なサービスを組み合わせてシステム構築できるようになりました。さらに詳細なカスタマイズが必要な部分でLambdaを呼び出せるようになっている事が多く、本当に必要最低限のソフトウェア開発だけでシステムが構築できるようになりました。
この恩恵として、インフラが得意ではないアプリエンジニアだけでシステム構築が現実的になりました。
AWSは「付加価値を生まない重労働（Undifferentiated Heavy Lifting）からの解放」と表現しています。
参考：https://aws.amazon.com/blogs/aws/we_build_muck_s/
参考：https://aws.amazon.com/jp/blogs/startup/muilab_2022casestudy/
参考：https://envader.plus/article/298
第四形態
前置きが長くなりましたが、ここでいよいよ生成AIの登場です。ソフトウェア部分を生成AI（プロンプト）で行います。
生成AIにコード生成をさせたり、IDE上でアシストしてもらうようなものとは別モノを想定しています。動作するソフトウェアの一部がプロンプトで実現されているものをイメージしています。
「生成AIの登場でプログラマーが職を失う」とかそういうことを言うつもりは全くありませんが、ソフトウェアの構成要素のうちの「他社との差別化要素」をプロンプト指示で行う形態が出てくると考えています。
そう思ったきっかけが Bedrockナレッジベース と Bedrockエージェント です。
Bedrockナレッジベース
Bedrockナレッジベースは、生成AIを使ったRAGの仕組みを実現するためのサーバーレスサービスです。ベクトルストアの構築やドキュメントの取り込みを設定だけで行うことができ、とっても簡単に使うことができます。
RAGの精度向上の手法は世の中的にまだまだ発展途上て、新しい手法が続々と登場します。現状はここが腕の見せ所になるので、ソフトウェア開発の出番ではあるのですが、見てください、Bedrockナレッジベースのバージョンアップ履歴。
11/23以降で15件もバージョンアップがあります。re:Invent期間だからというのもありますが、かなりのペースで更新されており、今後の更新も期待できます。
「今日中に最高精度が欲しいんだ」ということでないのであれば、Bedrockナレッジベース自体の精度向上に追随するようなスタイルでも良いのではないでしょうか。
他に独自性を出せる部分として残るのが、「プロンプト」 です。
どんなロールを与えるのか、ドキュメントが存在しない場合にどう振る舞うのかなどは、プロンプトで調整を行います。Bedrockナレッジベース自体は汎用性の高いRAGシステムですが、 プロンプト次第で他社との差別化が図れる と思います。
もちろんUIは開発が必要で差別化も可能ですが、「ChatGPTみたいな画面」みたいに汎用性のあるチャット画面を提供するのであれば、もはやUIに差別化要素は少ないと思います。
Bedrockエージェント
BedrockエージェントはAIエージェントを構築するためにサーバーレスサービスです。Bedrockナレッジベースと違い、エージェントが呼び出すツール（アクショングループ）をLambdaで実装する必要があるため、現状はまだ従来型のソフトウェア開発が必要です。
AWSがエージェントの動作を理解するためのワークショップを公開しています。
このワークショップの内容を確認していて感じたことが、「一見するとよくわからないコードがたくさんある」「コードの中にプロンプトがある」ということを感じました。
この、「よくわからないコードを書く」という部分は先述の 「付加価値を生まない重労働（Undifferentiated Heavy Lifting）」 なのでは？と感じました。ということは、今後のBedrockエージェントのバージョンアップで標準機能として盛り込まれるかもしれない、と期待しています。
エージェントの動作を制御しているのは結局 「プロンプト」 なので、Bedrockナレッジベース同様、 最終的な差別化はプロンプトで行う ことになります。
Lambdaで実装するアクショングループについても、汎用的な「Web検索をする」「天気を取得する」「専門のアルゴリズムで計算する」のようなものは、いずれ「アクショングループマーケットプレース（仮）」のようなもので提供されるのでは？と期待しています。こうなると、完全自社独自のものだけがプログラム開発の対象になると思います。
プロンプトは別次元のプログラミング言語
プロンプトはJavaやPythonなどの高級言語とは異なる 別次元のプログラミング言語 と捉えていいのではないでしょうか。
高級言語は「人間にとってわかりやすい表現で記述し、コンパイラやインタープリタを使って機械語に変換し、機会に命令をする言語」です。この定義でいくと、プロンプトも「人間にとってわかりやすい表現」なので、高級言語の一種と分類してもいいかもしれません。
ただ、プロンプトにはこれまでの高級言語にある以下のものが（明確には）ありません。
- 型
- 変数
- 制御構文
- 関数
- 引数
この点が、「別次元」と表現した意図です。はじめは「次世代」としていたのですが、プログラミング言語としては無いものが多すぎるので、別物と捉えることにしました。
「別次元」の特徴があるがゆえに、プログラミング言語としての仕様が定まっていません。そのため、テクニックを紹介する書籍や実行例を沢山集めた書籍はありますが、Python入門書のような書籍が存在しません。
これまでプログラミングを学んだことがあったとしても知識や経験がプロンプトというプログラミング言語には活かすことができません。そのため、これまでプログラミングをやったことがある人もない人も、等しく同じスタートラインに立っています。これはピンチでもありチャンスでもあります。
「おれは一生Javaプログラマーとしてやっていくんだ」というのもいいですが、プロンプトもできる方が潰しがききそうと思いませんか？
「今自分にできる能力で役に立つ」のも大事ですが、「自分が今できるかに限らず最良の手法を学び、取り入れ、役に立つ」のほうが私は好きです。
内製開発
さて、最近は内製開発がホットです。
第四形態の図を再掲します。
あなたは、どこからどこまでを内製化するおつもりですか？
流石にマザーボードにCPUを差し込むところから内製化しようと考えている人はいないと思いますが、「ソフトウェア開発は全部自社でやるんだ」と考えはいないでしょうか？
私は、内製と外注の境界線は「付加価値を生まない重労働（Undifferentiated Heavy Lifting）」 を念頭に置いて検討するといいのではと考えています。あなたが注力すべきは「付加価値部分」です。そして今後、 「付加価値部分」が「プロンプト」によって実現される世界 が来るのではと考えています。
プロンプトで差別化する部分は内製で行いプロンプト以外の重労働は外注する、そんな分担どうですか？
また、外注される側としても、当然プロンプトについての知識は必要です。顧客の関心事はプロンプトなので、どうアーキテクチャを組むのか、どこが差別化ポイントでどうプロンプトを取り込むのかがわかっている必要があります。プロンプト力があるPM/PLのみが顧客から信頼を勝ち取れる世の中になるかもしれません。
まとめ
- プロンプトで差別化する「第四形態」のシステムが今後増えてくるのではないか
- プロンプトについてはみんなスタートライン。遅かれ早かれ習得する必要のあるスキルなので、始めるなら今
- 内製する立場の人も、外注される立場の人も、プロンプト学びましょう