AIを「個人の武器」から「組織の強み」に変えるために必要なこと—報酬関数の話
なぜソフトウェア開発だけがAIに突出して変革されたのか。その鍵は「報酬関数」にある。業務にAIを定着させるための考え方を、講演内容をもとに整理する。
こんにちは！株式会社YTAL（ワイタル）代表の岡崎（Okazaki Yuta）です。
昨年、北郷（Hongo Yutaro）と二人で会社をつくりました。Yuta、Taro、AI、Labの頭文字から名付けた会社です。何をしている会社かというと、生成AIを業務に定着させるお手伝い—企業がAIを「導入した」で終わらせず、「使いこなしている」状態に持っていくための仕事をしています。
2月に「AIをビジネスに活かす」というテーマで二度ほど講師をさせてもらいました。 そのとき、ある受講者の方に言われた一言が印象に残っています。
「AIの話はいろいろ聞いてきたけど、自分の業務で何をすればいいかが初めて見えた気がする」
世の中にAIツールの情報はあふれています。しかしツールの使い方はすぐ陳腐化する。「会社として、組織として、自分たちはどう向き合えばいいの？」の部分が意外と語られていないのかもしれません。
今日は、その講演で話した核心の部分を書いてみます。
プログラミングの世界で起きている、異常なこと
まず、数字の話をさせてください。ソフトウェア開発の世界では今、こういうことが起きています。
- 開発者のAI利用率は80%（Stack Overflow Survey）
- 世界中で書かれるコードのうち、AI生成に関わった比率は42%（SonarSource）
- GitHub Copilotの利用者数は2,000万人超（TechCrunch）
- AIコードエディタのCursorは、製品ローンチから約2年で年間経常収益5億ドル超を達成（Yahoo Finance）
ほんの数年で、プログラミングという職種はAIに侵食されました。
でも、ここで立ち止まって考えてほしいのは、「なぜプログラミングなのか？」ということです。営業でもない、製造でもない、経理でもない。なぜソフトウェア開発だけが、こんなにも突出してAIに変革されているのか。
この問いの答えが、今日伝えたいことの入り口です。
「報酬関数」—AIが上達できる条件
元Tesla AI責任者でOpenAI創設メンバーのAndrej Karpathyが、2025年11月に興味深いことを書いています。
従来のプログラミングの時代（彼の言うSoftware 1.0）では、「手順を書けるもの」が自動化の対象でした。タイピングや簿記のように、やり方を手順書にできるものは機械に置き換えられた。
AI時代（Software 2.0）では、自動化の対象が変わった。「正解を検証できるもの」が自動化される。やり方は知らなくてもいい。答えが合っているかどうかを判定できれば、AIは自力で上達できる。
これを理解するのに、「マークシートと小論文の違い」の比喩がわかりやすいかもしれません。
マークシートなら、機械が一瞬で採点できる。答えが合っているか間違っているか、迷いようがない。並列処理もお手の物。だから何万回でも繰り返し解いて、間違えたところを修正して、また解ける。このフィードバックループが速いから、上達する。
一方、小論文はどうか。人間が1枚ずつ読んで、「この論旨は妥当か」「この構成で説得力があるか」を判断しなければならない。採点者が忙しければ返却は来週。このペースでは、何百回も書き直して上達するなんて不可能です。
コーディングの世界には「テスト」というマークシートがあります。コードを書いて、テストを走らせれば、一瞬で「合格」か「不合格」かが返ってくる。AIはこのループを何万回でも回せる。だから爆発的に上達した。
報酬関数（Reward Function）とは何か
このマークシートのような仕組みを、報酬関数（Reward Function）と呼びます。何が正解で、何が不正解かを、機械的に判定できる仕組みのことです。
報酬関数があるタスクでは、人間を介さずにAIが自力で賢くなる。これは比喩ではなく、AIの訓練手法そのものの話です。
ビジネスの世界には報酬関数がない
ここで、ビジネスの世界を振り返ってみましょう。
企画書を書いて、上司に見せる。返ってくるのは「うーん、もう少し…」。フィードバックまで数日、下手すると数週間。そもそも「良い企画書とは何か」の基準が曖昧。100回書き直すことも、正解を機械的に判定することもできない。
つまり、ビジネスの多くの業務には報酬関数がない。評価を自動で回す仕組みが整っていない。だからAIを導入しても、人間が任せられるような自律的な挙動の獲得が難しいのだと思います。
これが、例えば「AIプロジェクトの95%が本番運用に至らない」という数字の背景の一つかもしれません（MIT, 2025）。
これはAIが十分に賢くないからではなく、人間側が「業務を型化できているか」「業務を回した時の評価が確立されているか」「それをAIが回せる形で報酬関数化できているか」の問題です。
「型化、評価、そして報酬化」
では、報酬関数をどうやって作るのか。
私たちがワークショップでやっているのは、何はともあれ、業務の「型化」です。どんな業務でも、まず4つの要素に分解してみる。
- 入力: 何を受け取るか（例: 顧客からの見積依頼）
- 処理: 何をするか（例: 過去実績を参照して見積書を作成）
- 出力: 何を返すか（例: 見積書を顧客に送付）
- 副作用: 他に何が起きるか（例: 対応履歴の記録）
これだけで、曖昧だった業務の輪郭がくっきりする。そして、その出力に対して「良い結果とは何か」を数値で定義する。「見積の正確性」とか、「応答速度」とか。内的な質や、外的な質などにも分けられるでしょう。
「なんとなく良い」を「数字で測れる」に変える。これが報酬関数の定義であり、これ自体がAI導入以前に、業務改革の文脈で語れるものです。それがAIエージェントの潮流で待ったなしになった、と考えていただければ間違いないです。
AI本番運用を阻む、3つの壁
業務でのAI本格運用に至るまでには、3つの壁があると普段お話しています。
1つ目の壁：データの整備
AIに「食べさせるデータ」がそもそも揃っていない。業務データがExcel、メール、チャット、紙に散在している。過去の「良い事例」が個人のPCに眠っている。
2つ目の壁：ガードレール
AIを走らせるにしても、「何をやってはいけないか」の境界線がない。機密情報の漏洩、不適切な出力、ハルシネーション—これらに対するガードレールがなければ、本番環境では怖くて使えない。
3つ目の壁：「型化・評価・報酬化」不足
「良い結果とは何か」が未定義だと、デモで1回うまくいっても意味がない。100回中何回正しいのか？ それを測る仕組みがなければ、改善ループは回らない。
弊社YTALはすべての支援を行っていますが、最も根本的なのが3つ目だと考えています。なぜなら、報酬関数（評価）が定義できれば、データ基盤の整備もガードレールの設計も、そこから逆算できるからです。
私たちがYTALでやっていること
ここで少し自分たちの話をさせてください。
-
私は10年以上ソフトウェアエンジニアを本業として活動してきました。ベルリンのスタートアップを経て、ShopifyでSenior Product Engineerとして（世界で一番大きな？）モノリスの機能開発やSRE業務をやっていました。
-
共同創業者のTaroは、AmazonでSenior Product Managerとして事業を見ていました。二人とも、グローバルなテック企業の現場で、技術で事業がスケールする様子を目の当たりにしてきました。
なぜ会社をつくったのか。生成AIを業務に活かすには、このディープなエンジニアの経験こそが大切なピースだと思ったからです。 エンジニアがAIを使いこなすマネージャー化し、マネージャーやビジネスパーソンがAIを自然言語で導入するエンジニア化する未来がもう目の前にあります。このときに、「導入した」と「使いこなしている」の間にある溝を埋めるのが、私たちの仕事です。
特にこういったケースでお声がけいただくことが多いです。
- 社内に開発チームがあるけれど、彼らにはトップラインの成長や新規事業に専念してほしい—その代わり、YTALには「バックオフィスや業務効率化、ビジネス部門のAI化」の領域に入ってほしい、というケース。
- 従来の開発ベンダーさんに人月計算で外注していたが、AI時代でもっと開発が柔軟にできるはずという思いがある。合わせて、内製化チームのように、機動的に開発を動かしていきたいというケース。
どちらのケースでも、私たちがやっていることの本質は変わりません。今まで人ありきであった業務を棚卸して、構造化して、AIが活躍できるシステムもしくは業務変革を提供しています。
もし、この記事で書いたことに興味を持っていただけたら、ぜひご連絡ください。「うちの業務だとどうなるんだろう」「報酬関数の定義ってうちでもできるのかな」—雑談だけで終わっても全く構いません。
日本全体で、AIの社会実装を盛り上げていきたく、その一助になれたら幸いです。