「システムはLLMが前提に」――LayerX CTO松本氏が語る、生成AIがシステムにもたらす変化 「AIエージェントがSaaSを操作する時代」に危機感を募らせる理由：「システムを人に合わせる」が、生成AIで実現できるように

生成AIの進化は、ビジネスと同義となっているシステムの在り方をどう変化させていくのか。ブログやコミュニティー活動を通じて「システムはLLMが前提に」と情報発信しているLayerX CTOの松本勇気氏に、話を聞いた。

[齋藤公二, 石川俊明，＠IT]

　ソフトウェアエンジニアがコードアシスタントAI（人工知能）を活用することは、もはや当たり前になりつつあるといっても過言ではない。2023年に登場した「ChatGPT」以降、エンジニア個人だけではなく、スタートアップや大企業でも生成AIを活用する取り組みが広まりつつある。

　この2年で生成AI技術が目まぐるしく進化する中で、「LLM（大規模言語モデル）をシステムに組み込むことが当たり前になる」と、複数のエンジニア向けイベントで提言してきたのが、LayerXでCTO（最高技術責任者）を務め、同社のAI・LLM事業部も管掌する松本勇気氏だ。

　LLMをシステムに組み込むことは、企業のビジネスにどのような価値をもたらすのか。LLMを組み込んだシステムの開発は、従来のシステム開発と何が違うのか？　ITエンジニアが注意すべきポイントはあるのか。松本氏に話を聞いた（※編注：2025年1月上旬に取材を実施）。

生成AIの衝撃は、幅広くどんな問題でもターゲットにできること

──2024年はOpenAIから新しいAIモデル「o1」「o3」の発表もありました。生成AIの進化をどう見ていますか。

LayerX CTO 松本勇気氏

　o1、o3は「リーズニングモデル」、理由付けをすることで1つの課題に長く取り組めるモデルであることが気になっています。これまでの生成AIは、1つの質問に回答するという対話はできていて、その性能に関しては人間との差が分からないくらいに進化していました。一方、数学のように仮説に仮説を重ねて証明するようなプロセスは得意ではありませんでした。

　OpenAIのo1やo3といったリーズニングモデルはそれを可能にする進化です。1つのトピックについて長く考え込み結論を導き出せるモデルの登場と進化は、2025年の重要テーマになると考えています。

　リーズニングモデルが進化すれば、生成AIが外の道具、つまりWebブラウザやソフトウェアを扱うのもうまくなっていきます。これは昨今注目されている「AIエージェント」の進化にもつながります。1つのトピックをAIが考え、深掘りできること自体、非常にビックリしていますね。

──松本さんご自身は、生成AIを業務で使っていますか？

　OpenAIに障害が起きるたび、呼吸ができなくなるくらいの感覚で使い込んでいます。ブログの執筆にしても、コーディングにしても、日常の生産活動にべったり入り込んでいます。OpenAIの「o1 PRO」が出てからは経営会議で意思決定する際にも有用なので使っています。使い方としては「論理のあら探し」です。機械の良いところはどこまでやっても疲れないこと。ひたすら網羅的に物事を考えてくれます。網羅的に考えさせることで穴を見つける。「私はこう考えてこう動こうと思っているのだけど……」と問いかけて「それに対してなら、こんな観点もあります」と答えさせる。これがありがたいですね。

──新たな気付きを得るのですね。

　そうですね。矛盾だけでなく、一般社会の動向、法規制など、ある程度意識して意見をくれます。生成AIが法律の理解を誤っていても、「アクションを取る際には、法律を確認しなければいけない」と気付きを得られるだけでも大きいです。

「システム開発はLLMが前提になる」　その理由

──松本さんは過去に登壇されているイベントの講演やブログ記事などを通じて「システム開発はLLMが前提になる」とおっしゃっています。なぜ、LLMが前提になるのでしょうか。

　従来のソフトウェアはできることの幅が狭かったんです。一定の型のあるデータを与えないと機械はその意味を解釈できず、処理できない。これまでは機械学習を使うことで、もう少しファジーなデータ、例えば、請求書OCRのように、さまざまな型を処理することはできました。そうした中で登場した生成AIは、本当に幅広く、どのような問題であってもターゲットに加えられるようになったことが衝撃でした。文章、音声、動画、画像など、これまでのようにモデルを新たに用意せずに解釈し処理できる。ソフトウェアの使える範囲が大きく広がったんです。

──例えばどのようなことが可能になるのですか。

　LayerXが提供する「Ai Workforce」で提供できた成果として、1つのプラットフォームでナレッジマネジメントのようなことができる点もそうです。営業資料を分類してタグ付けして要約して読みやすくし、営業担当者のパフォーマンスを上げることができる。一方、英語や中国語の決算書を読み込んで、まとまった経営分析のための資料を作るといったこともできる。以前だったらそれぞれ目的に応じてツールとして作り込む必要がありました。

　LLMに柔軟性があるからこそ、全く違う価値を1つのツール、プラットフォームで提供できる。LLMが非構造化データを扱えることで、できるようになった価値提供は幅広く、「これをソフトウェアに組み込まずして、他に面白いフロンティアはあるのか？」と、そんなふうに感じています。

──型を作らずに、型を意識しなくても、成果を得られるようになった、と。

　従来はAPIを作るか人間が頑張って型に合わせて入力するしかありませんでした。生成AIによって、人が機械に合わせる世界から、機械が人に合わせる世界になったと感じます。

　これまでソフトウェアベンダーは「頑張って業務をSaaSに合わせましょう」と言ってきました。ただ、それだけではデジタル化はなかなか進みませんでした。パッケージを人に合わせてきた歴史を逆転させて、人をソフトウェアに合わせることで効率化しようとしましたが、それができた企業も多くはありませんでした。

　そして今、生成AIにより再び逆転して、ソフトウェアが人や業務に合わせる時代に戻ってきたのです。以前と違うのは、人がソフトウェアを作り変えて人に合わせるのではなく、生成AIが、ソフトウェアを人に合わせられるようになったこと。これが大きな変化です。

──既にそうしたことを実現できているプロダクトはあるのでしょうか。

　まだプロダクトとして提供できている会社はそれほど多くないと思います。AIエージェントがキーワードになったことで、多くの会社が気付き、おそらく2025年から増えていくと思います。

　ただ、エージェントはあくまでキーワードであり、エージェントであることを意識し過ぎると失敗するとも感じています。これは、クラウド、ディープラーニング、ブロックチェーン、Web3といったキーワードとも重なります。忘れてはいけないのは、お客さまの価値につながるよう、使いこなすことですね。

これまでと全く異なるパラダイムの中でのプロダクトづくりが求められる

──LLMを活用すると、顧客が求める要件にあったシステム開発もしやすくなるのでしょうか。

　そうです。LLM自体が実現できる業務の幅広さに加えて、リーズニングによってLLMがどう動くかを自分たちで決められるようになることが大きい。1つの課題に対するポイントソリューションではなく、その周辺にふわっと広がっていける幅の広いソリューションを作れるところがLLMの面白さです。

　私の感覚では、既存のソリューションは業務の3割程度しかカバーできていないと感じています。ソリューションを入れても、7割は人がやっている。生成AIはその7割を全てターゲットに収めることができると考えています。

──一方、生成AIには「精度の問題」や「ハルシネーション（幻覚）」などの問題があることも指摘されていますが。

　その問題を指摘している人は、LLMを使ってプロダクトを作っている人ではないのかもしれません。そもそも精度要件はタスク次第で全く違います。6割の精度でもうれしい場合もあれば、9割でもダメなものもあります。LLMに限らず、機械学習はミスをするものです。精度の問題は、「予測のエラーをどう扱うか」という古典的な機械学習の問題にすぎません。

　その中でプロダクトとして価値をどう作るかは、お客さまが達成したい目標、タスクにより決まります。つまり、お客さまと対話しながら決めていくことが大切です。しっかりと対話できれば、精度やハルシネーションといった問題を恐れる必要は全くありません。

──LLMをシステムに組み込んでいくことが当たり前になっていくと、SaaS事業者やパッケージベンダーの立ち位置は変わるのでしょうか。

　生成AIは道具を使う道具です。従来のポイントソリューションは呼び出されるAPIの1つになりかねません。最近、ブラウザをAIエージェントが操作してタスクを処理することまで可能になりつつあります。

　もしかしたらこれまでフロントに立っていたソリューションも、将来的には、生成AIに呼び出される裏方のソリューションに変わっていくかもしれません。裏方に回るということは、リプレースされやすくなるということを意味します。

　裏方に回ることで価値を失うリスクがあるベンダーの場合、いま“脱皮”しておかないと、事業継続が危ぶまれる事態になりかねません。それは、われわれLayerXも同じであり、生成AI技術には期待する部分がある一方で、危機感も募らせています。

──総合すると、プロダクトづくりの考え方自体が変わる可能性すらあるということですね。

　生成AIはワークフォース（労働力）であり、いま新たな労働力の誕生を目の当たりにしていると感じます。これまでのポイントソリューションとは市場規模も全く違いますし、これまでと全く異なるパラダイムの中でのプロダクトづくりが求められます。私自身は「どの領域を見てもチャンスしかない！」と楽しんでいます。

　今後ますます、ITエンジニアの専門家、プロフェッショナルの役割は重要になっていくでしょう。プロとしての価値を最大化して、これまで市場にできなかった残りの7割の領域をデジタル化、自動化していくことにとてもワクワクしています。

人間の仕事の仕方を生成AIに教えるイメージで、要件定義をしていく

──より具体的に、システム開発の手法や仕組みはどう変わるのでしょうか。

　これまで機械学習に取り組んできた人たちにとって、新しいことはありません。ただ、モデルの性質変化や、モデルが正しく動いているかどうかの検証は、一般的なソフトウェアよりもデジタルに決まらないところがあります。例えば、モデルのバージョンが変われば、うまくタスクに対応できないということが起きる可能性もあります。

　これはユニットテストだけだと、検証できません。そのため、精度検証をどう組み込むかなど、検討が必要になってくるかもしれません。変更の検知や修正を日常の開発プロセスに組み込んでおく必要もあるでしょう。そのためにはモニタリングの仕組みや、ユーザーの声を拾う仕組み、KPI（重要業績評価指標）設定なども必要になります。事前にLLMの評価ツールを組み込むことも必要でしょう。

──他に、注意点はありますか。

　インプットとアウトプットが確率的なものになります。100％同じ回答を返してくれるわけではないし、「JSONの型で返して」とプロンプトで指示しても守られないこともあります。そうしたエラーをあらかじめ見込んで再実行するインタフェースやエラーをたどりやすくする仕組みも必要かもしれません。

　ただし、これは既存のワークフローエンジンと考え方は大きく変わりません。生成AIをシステム開発に組み込んでいくとしても、基本的には、何か特殊な考えが必要になるわけではないと思います。

──これまでのソフトウェア開発のサイクルでいうと、変化はないのでしょうか。例えば「要件定義」の部分で変化は起きるのでしょうか。

　生成AIはできる業務の幅が広いので、どこまで要件の幅に対応できるかをイメージしながらプロンプトで要件を定義することが重要ですね。0か1かを選ばせるのではなく、もう少し抽象化したらどのようなアウトプットを出せるのかを考える。人間の仕事の仕方を生成AIに教えてあげるイメージです。

　例えば「取材して記事を書く」というタスクの場合、タスクを細分化すると「企画出し」「質問内容の作成」「ソースの確認や取材活動」「原稿作成」「レビュー」「リリース」などがあると思います。それら一つ一つのプロセスを解決するエンジンを考えるのではなく、「記事を書く」こと自体を全て生成AIで任せるならどのようなプロンプトにするとよいかを考えていきます。

　その場合、必要になるデータやコンテキストもこれまでと変わります。どうすればプロンプトに必要なデータやコンテキストを収集するのか、考えることが必要になります。

生成AIにこだわらないこともポイント

──これから、ITエンジニアは生成AIとどう向き合っていけばよいのでしょうか。

　まずは「触ろうぜ」ということです。性質がこれまでと違うものなので、普段からプロンプトを触ってみて「こうした傾向があるのだな」ということを知る。その上で、精度の評価や必要なコンテキストは何かを感覚でつかんでおく。

　ソフトウェアに必要な機能は、今、現場で活躍しているITエンジニアがいちばん理解しているでしょう。ITエンジニアは、ソフトウェアのことをよく分かっていて、プロンプトエンジニアリングとも相性が良い。ソフトウェアエンジニアが生成AIを学びつつ、自分たちのシステムに生成AIを組み込み、事業戦略まで入っていければいいと思っています。

──なるほど。そうした取り組みを進めていく中で、気を付けるべき点はありますか。

　小さな機能を作って満足してしまうことでしょうか。例えば、「LLMを活用してタグ付けして分類できるようになった」としても、それは過去の埋め込み表現でできた可能性もあります。

　つくったことに素晴らしさはあっても、プロダクトの強みにはつながりにくい。LLMで本当のインパクトにつながることを見定めていくことが重要です。

　一方で、何でもLLMで解決すると考えてしまうのも気を付けたいですね。「1＋1＝」を解くのに、AIエージェントに数百円払って回答させるといったことはよく起こります。「ハンマーを持ったら何でもクギに見える」ような事態は避けたい。全てをAIに任せるのではなく、いつでも既存の手法を選べるという柔軟さを持つことも重要です。

──従来のシステムアーキテクチャに変更は必要ですか。

　基本的には従来と変わりません。LayerXでも生成AIの取り組みを進めるために、システムアーキテクチャを変更したことはありません。Amazon Web Services（AWS）やMicrosoft Azureを活用しており、基本的なアーキテクチャを踏襲したシンプルな構成で作り続けています。

　LLMをシステムに組み込む場合も、普通のWebサービスにAPIコールが1本生えているだけと考えればいいと思っています。ただし、自社でモデルを管理したい場合は、GPUの整備やモデルのデプロイ先の検討、リソース共有の方法などインフラの手間も増えます。

　個人的には、自社モデルではなく、性能、コスト、将来的な進化などを考えて、大手のモデルを使うのが望ましいと考えています。

「コーディングの機会は減少」でも、ITエンジニアの仕事がなくなるわけではない

──これから、開発者や運用者の役割はどう変化するのでしょうか。

　「世界の最先端の方たちは答えを出し終わっているのではないか」という感覚があります。例えば、Salesforceのマーク・ベニオフ氏は、この1年、生成AIに振り切って戦略を考えていたそうです。生成AIで自分たちを作り替えようとしているというわけです。

　生成AIの進化により、ITエンジニアがコードを書くシーンが減っていくことは確かでしょう。1社当たり、1プロジェクト当たりに必要なエンジニアの数も減るかもしれません。

　ただ、ITエンジニアの仕事がなくなることはありませんし、AIに良いコードを書くよう指示したり、微調整したり、最終判断したりする役割は必要です。「最終的にはITエンジニアにしか分からない」という部分はまだたくさんあります。生成AIに対しての責任を取るという意味でも、専門家の知見が求められます。

　一方で、AIがコーディングするようになると、ITエンジニアをこれからどう育成していくかは課題になります。そこは私もまだ答えを持っていません。生成AI時代のエンジニアの在り方は、今後も課題になると思います。

――ありがとうございました。最後に、読者にメッセージをお願いできますか。

　ITエンジニアは自分をクビにする、自分の仕事を機械に奪わせるのが好きです。業界慣習として仕事を抽象化していくことが面白さにつながっています。今後、開発スタイルはAIフレンドリーな方向にどんどん変わっていくでしょう。

　生成AI技術に関しても、今後は安く、使いやすいモデルがどんどん開発、リリースされていくため、1人で作れるものの幅も広がっていくでしょう。ただ、2025年1月時点で、生成AIは「動くもの」は作れますが「使いやすいもの」は作れません。使いやすいものを作るには、言語化できないアーティスティックな技術も必要です。

　生成AIの登場によるソフトウェアエンジニアリングの変化を楽しみつつ、日々の仕事をまい進していきましょう。

特集サイト「4AI by ＠IT」スタート

　「4AI by ＠IT」は、ITエンジニアが、AIシステムを「作る」「動かす」「守る」「生かす」ため（for AI）の学びと課題解決を支援する情報サイトです。インフラの構築から開発・テスト、セキュリティやガバナンスに至るまで、ビジネスで実用されるAIシステムのためにエンジニアが必要とする情報を分かりやすく提供していきます。