「一発芸」AIからの脱却。AIとITシステムをつなぐSystem Useの可能性

この記事は、松尾研究所 Advent Calendar 2025の記事です。

本記事には筆者の私見が多く含まれます。松尾研究所の公式見解ではありません。

はじめに

はじめまして。株式会社松尾研究所の上林勇太です。

普段は”AIコンサルタント”という肩書きで、企業のみなさまに対して AI 活用の企画・提案を行っています。端的に言ってしまえば、松尾研究所の ”営業” の職です。

捉え方は人それぞれですが、

• お金を払ってでも解決したい課題を企業との対話から見つけ出し
• それを受託開発案件という形に落とし込み
• チームが最大限力を発揮できるようにお膳立てする

ことが、松尾研究所のAIコンサルタントのミッションだと（私は）考えています。
日本企業のAIによる成長の方向性を決めることへの責任と大きなやりがいを日々感じています。

どこかで松尾研のAIコンサルタントのご紹介はするとして、
今回は、そんな私が最近考えている生成AIの社会実装まわりの課題感を、Andrej Karpathy 大先生の言葉をお借りしつつ語っていきます。

ちなみにAIの社会実装については、松尾研究所として「AI トランスフォーメーション：AIによる企業変革のブループリント」も執筆しましたので、ぜひお読みください。

Karpathyの「Software2.0」

まず、前提となる”Software2.0”の概念について触れておきます。既にご存知の方はスキップしてください。

KarpathyのSoftware2.0の解説（by GPT-5.1）

OpenAI創設メンバーの一人であり、TeslaのAI部門を率いたAndrej Karpathy氏は、2017年の論考および近年の発言でソフトウェアの在り方を以下のように述べています。

• 従来のソフトウェア（Software1.0）は、人間が C++ や Python で明示的にコードを書く世界である。
• それに対して、ニューラルネットワーク（Software2.0）では、
  • 「望ましいプログラムの振る舞いに関する目標（データセットや報酬の仕組み）」と
  • 「ニューラルネットワークのアーキテクチャ（コードの“骨組み”）」
    がソースコードそのものになる。
• 学習とは、「データセット → ニューラルネットの重み」へのコンパイル過程であり、その結果として得られるニューラルネットがSoftware2.0の“バイナリ”である、という比喩が示されています。

ポイントは、”人間には書けないレベルの複雑さ”を、ニューラルネットとデータを通じてプログラミングできるようになった、というパラダイムシフトの宣言だということです。

また、AI（Software2.0）に対して、

電気や産業革命のような比喩もあるけど、自分としては”新しいコンピューティングパラダイム”として捉えるのが一番しっくりくる
この新しいプログラミングパラダイムで、注目すべき特徴は”検証可能性”である。タスクや仕事が検証可能であれば、直接的または強化学習によって最適化可能であり、ニューラルネットを訓練して非常にうまく機能させることができる。

という趣旨の発言をしています。

要するに、

• 従来型のシステム（Software1.0）は、指定できるものをプログラム化できる。
• AI・ニューラルネットワーク（Software2.0）は、検証可能なものをプログラム化できる。

と述べています。

AIの社会実装の現在地

我々は今、確かにSoftware2.0の時代にいる

LLM を筆頭に、ニューラルネットという姿でプログラミングされたアプリケーションが、
プロダクト・PoC・社内ツール問わず大量に出てきています。

• 需要予測や不良品検知などの機械学習モデル
• 文章生成、コード補完などの大規模言語モデル
• 画像・動画生成などのマルチモーダルな生成モデル

なるほど、どれも”人間には到底書けない複雑さのプログラム”を、ニューラルネットが代わりに引き受けてくれている、と言えそうです。

でもでも意外と、Software2.0 は、まだ”業務ツール”として十分に浸透していない

一方、少なくともSoftware1.0が世界を食い尽くしたような破壊力では、AI（Software2.0）が社会実装されているとは言えないでしょう。

特に生成AIについては、MITが「95%の生成AI活用は十分な投資対効果を得られていない」と主張するレポート（2025年7月）を発表しており、ビジネス成果を出すことの難しさが徐々に認識されています。

まだまだAI活用で社会が良くなる余地があるはず。それが、AIコンサルとして日々お客さまと会話していて、乗り越えたい・次のステージに社会を進めたい強く感じるポイントです。

ITシステム(1.0)とAI(2.0)をつなぐエンジニアリング

私の解決策の仮説はシンプルで、

AI（Software2.0） 単体の問題というより、
ITシステム（Software1.0） とAI（Software2.0）をつなぐエンジニアリングが足りていない
ということなのではないかと考えています。

AI(Software2.0)が、ITシステム(Software1.0)の“外側”で作られてしまっている

Software1.0の世界は、人間が明示的に扱える複雑さの範囲で、ルールベースなプログラムとして検証可能なシステムを構築する世界です。
ERPやCRMのような業務システムしかり、データベースしかり、企業の業務インフラのかなりの部分は、いまだにというか今後も当面はSoftware1.0でガチガチに固められています。

一方のSoftware2.0の世界は、人間には記述できない複雑さの処理をニューラルネット とデータセットという形でプログラミングしている世界です。

この二つの世界はその構築手段からして分離してしまう構造にあります。必然です。

この、AI(Software2.0)が、ITシステム(Software1.0)の“外側”で作られてしまっていることは、AIの社会実装を阻む大きな問題ではないでしょうか。

PoCで作られる多くのLLMアプリやモデルは、既存の業務システムとは独立した”別アプリ”として立ち上がり、後から既存システムに統合されようとした途端、どこか気まずい居心地の悪さのなかで稼働せざるを得なくなります。
日々のSoftware1.0の網の中から見ると、AIのせっかくの”便利さ”は頭打ちになってしまうのではないか——これが私の問題意識です。

（NotebookLM作成図）PoC ではものすごく賢く見えるのに、本番運用・業務組み込みになると急に腰が重くなるのは、大抵このあたりに理由がある気がしています。

AIとITシステムをつなぐためのSystem Use

飛躍を恐れず踏み込むと、世界は、ITシステムの外側で作られた一発芸のようなAIを求めているわけではない。
むしろ、AIのキラーアプリケーションは ”AI(Software2.0)がITシステム(Software1.0)を操作する”という名もなき業務の自動化ではないかと考えています。

その打開策として重要になるのが、巷で言われる Tool Use^[1]...というか、もう少し直接的な言い方をすれば、System Use（既存業務システムを”LLMが使い倒す”という発想）だと考えています。

AI(Software2.0)を新しいアプリとして横に置くのではなく、既存のITシステム(Software1.0)を“道具として使うエージェント”として設計すること。ここに、AIが本当に社会実装されていくための鍵があるのではないか、というのが本稿での主張です。

求められるAI開発の方向性

こうしたSystem Useを現実にするには、LoRAやFunction callingといった既存のテクニックの応用が重要になるでしょう。

• LoRA などの軽量ファインチューニングは、企業やシステムごとのドメイン知識・状況を、リーズナブルなコストでLLMに馴染ませるために重要です。
• 一方で、既存システムのAPIやDBスキーマを整理し、LLMから叩きやすい粒度のToolとして切り出していく作業は、Function callingの系譜に位置づけられそうです。

単にLLMが触ることができるAPIを用意するという話ではありません。会社にとってのトランザクションの自然な単位を定義し、LLMに任せる”完了可能な仕事”をデザインする必要があります。

さらに、最終的には”一発でちゃんと動くか（pass@1）”も非常に重要になるでしょう。

• トークン効率・レイテンシの観点でも、無駄な試行錯誤は避けたい。
• さらに人間のモニタリングのしやすさを考えると、”1回の試行をちゃんとレビューすればOK”という構造が望ましい。

そう考えると、結局はpass@1の精度をどこまで押し上げられるかが、実務上のボトルネックになってきそうです。

（余談）LLMのpass@1と強化学習について

pass@1の精度とpass@kの精度の差という文脈において、最近のLLMに対する強化学習の議論はとても示唆に富んでいます。大きな方向性として、強化学習により「pass@1の精度を向上させることはできるが、pass@kの精度を効果的に向上させられるとは限らない」ということが言われています。

• 1. 「Does Reinforcement Learning Really Incentivize Reasoning Capacity in LLMs Beyond the Base Model?」
• 2. 「ProRL: Prolonged Reinforcement Learning Expands Reasoning Boundaries in Large Language Models」
     など

個人的には1.の論文のDiscussion 1で述べられている以下の立場に納得しています。

従来の強化学習と大規模言語モデル（LLM）向けの強化学習（RLVR）には、膨大な行動空間と事前学習済み事前分布という大きな違いがあります。
（LLMの強化学習とは違って）AlphaGo ZeroやDQNシリーズ（Silver et al., 2017; Mnih et al., 2015; Yue et al., 2023）のような従来の強化学習は、囲碁やAtariゲームのような環境において、明示的な上限なくポリシーの性能を継続的に向上させることができます。
従来の強化学習とLLM向けのRLVRには、主に2つの違いがあります。
まず、言語モデルの行動空間は、囲碁やAtariゲームよりも指数関数的に大きいです（Ramamurthy et al., 2023）。
強化学習アルゴリズムは、元々これほど広大な行動空間を扱うように設計されていなかったため、ゼロから学習を開始した場合、報酬信号を効果的に探索することはほぼ不可能です。
したがって、2つ目の違いは、LLM向けのRLVRが有用な事前分布を持つ事前学習済みベースモデルから始めるのに対し、Atariや囲碁ゲームにおける従来の強化学習はしばしばゼロから始める点です。
この事前学習済み事前分布が、LLMが妥当な応答を生成するのに役立ち、探索プロセスを大幅に容易にし、ポリシーが正の報酬フィードバックを受け取れるようにします。

破滅的忘却を防ぎつつ効率的な探索を行える強化学習の手法が確立された暁には、ものすごいゲームチェンジが起こるのではないかと、期待しています。

pass@1で成功するような確信的な挙動をさせるためには、おそらく強化学習は効果的なのでしょうね。「やってみせ、言って聞かせて、させてみて、褒めてやらねばLLMは動かじ。」と山本五十六もカリキュラム学習を説いていたそうなので。（ハルシネーション）

妄想：自然に分化する”Software3.0”

ここまでは、既存のSoftware1.0の存在を前提にSoftware2.0を“うまく載せる”という意味での統合の話をしてきました。最後に少しだけ、その先の妄想としての”Software 3.0”に触れておきます。

私が思い描いているSoftware3.0とは、

• 一部はニューラルネットとしてブラックボックスに学習され
• 一部はルールベースな構造として自然に”析出”してくる

という形で、2種類のプログラム表現が最初から一体となって進化していくような世界です。

もし将来、ニューラルネットの内部に、ある種の”ルールベースなサブアーキテクチャ”が自然発生的に形成され、それが人間にとっても読み書き可能な形で取り出せる／編集できるようになれば、それは現在のSoftware1.0／2.0の対立構造を一段超えた、Software3.0だと言えるでしょう。

実務者としては、まずは AIによるSoftware1.0 Useの地道な実装から着実に進めつつ、どこかでこうしたSoftware3.0的な世界にもつながる足場を作っていきたい——そんなことを考えながら、日々企業のみなさまと議論をさせていただいています。

終わりに：松尾研究所として解きたい問い

松尾研究所としては、”すでに解き方が見えている課題”を解決し続けるよりも”Software1.0 と2.0の統合”、”Tool Useと業務システムの融合”、”Software3.0的なアーキテクチャ”のように、まだ解き方が固まっていない難しい問いにこそ取り組むべきだと、私は考えています（再び完全なる私見です）。

そして、AIコンサルタントである私は、そういった難しいが面白い問いを、企業の現場からちゃんと発掘してくることこそが、自分の役割だと思っています。

もしこの記事を読んでくださっている方の中で、

• こんな松尾研究所に依頼したいことがある！！！
• 松尾研究所で働いてみたい！！！

という方がいらっしゃれば、ぜひどこかでお話しできると嬉しいです。

参考文献

1. Software 2.0 (2017)
2. Karpathy氏のつぶやき (2025)
3. Does Reinforcement Learning Really Incentivize Reasoning Capacity in LLMs Beyond the Base Model?

脚注

1. LLMに外部ツール（API・DB・検索・実行環境など）を呼び出させ、文章生成にとどまらないタスク実行能力を拡張する枠組み