InfoQのこの講演は、IntuitでAI基盤を率いるMerrin Kurian氏が、同社のAI変革をどう支えているのかを語る内容です。
題名は「Powering the Future: Building Your GenAI Infrastructure Stack」。直訳すると「未来を動かす、GenAIインフラスタックの作り方」くらいでしょうか。
ここでいうGenAIは、生成AIのこと。さらにその先にあるのがAI agent、つまり「単に答えるだけでなく、状況を理解してツールを使い、作業を進めるAI」です。
最近よく聞く話ですが、実際に本番運用まで持っていくのはかなり大変です。そこを、Intuitがどう片付けているのかがこの講演の見どころです。
個人的には、こういう話は「AIを使っています」では終わらず、どうやって組織と基盤を整えたのかまで踏み込んでいるのが面白いと思います。AI活用の本丸はモデルそのものより、むしろその周辺の設計にあるからです。
Intuitのミッションは、世界中の人々の「prosperity」を後押しすること。
要するに、個人や小規模事業者がもっと稼げて、もっと時間を節約できて、安心してお金の判断ができるようにする会社です。
講演では、Intuitの規模感を示す数字も紹介されています。
数字が大きすぎてピンと来ないですが、要するに「AIを少し試す」会社ではなく、巨大な金融・業務基盤の上でAIを動かしているということです。
ここがかなり重要です。AIは派手ですが、実際に価値を出すのは、こうした既存の業務システムとつながったときです。
講演では、IntuitのAI/エージェントが実際にどう役立っているかも紹介されています。
たとえば：
これはかなりインパクトがあります。AIの価値って、つい「便利そう」「賢そう」で語られがちですが、実際には時間をどれだけ削れるかが強いです。
「1日5分短縮」みたいな話でも、利用者が何百万人もいればとんでもない価値になりますからね。
講演では、QuickBooks Enterprise向けのエージェント例も出ています。
顧客とのメールを読み、会話を理解し、添付ファイルまで見て請求書を作る。
ビジネスオーナーは最後に確認して送るだけ。
これはかなり“仕事っぽい”です。
単なるチャットボットではなく、メール → 理解 → 書類作成 → 人が確認という流れになっている。
ここにAIエージェントの本質があると思います。人間の仕事を全部奪うのではなく、面倒な下ごしらえを引き受けるわけです。
自分のデータをもとに、同業他社と比較し、利益率が低い理由を分析する。
たとえば材料費や人件費が原因だと示し、さらに「次に何をすべきか」まで提案する。
ここで面白いのは、AIが単なる分析表示で終わらず、次のアクション候補まで返すことです。
この一歩先が、いまのGenAIの価値だと思います。
「データを見せる」だけならBIツールでもできますが、「次に何をするべきか」を出せると、仕事の流れが変わります。
ただし、講演でも強調されている通り、AIには人間の知性を足す必要がある。
最終判断は、やはり専門家に相談できる形が大事です。
ここを雑にすると、便利なはずのAIが逆に事故の原因になります。
この講演の中心は、GenOSという基盤です。
正式には Generative AI Operating System。名前は少し大げさですが、実態は「社内のAI機能を広げるための共通プラットフォーム」と考えるとわかりやすいです。
IntuitではこのGenOSを使って、8,000人の開発者にAI機能を広げ、3,500件以上の本番実験を回しているそうです。
ここで重要なのは、AIを“個別プロジェクト”として持つのではなく、共通基盤として配ることです。
これは正直、かなり賢いやり方だと思います。
AI機能を各チームがバラバラに作ると、評価方法もセキュリティも運用もバラバラになります。結果として、後から地獄を見る。
なので、共通の土台を作り、その上で各プロダクトが素早く試せるようにする。これがスケールの王道です。
元記事の説明でも触れられているのが、fixed, flexible, freeというフレームワークです。
ざっくり言うと、
という考え方です。
これはAI基盤にすごく向いている発想だと思います。
なぜなら、AIはまだ変化が激しいからです。全部をガチガチに固定するとイノベーションが止まる。でも、全部自由にすると品質や安全性が崩れる。
その間をうまく設計するための整理軸が、fixed / flexible / free なのだと理解するとわかりやすいです。
講演では、Agent Development: Pilot to Production という流れが語られています。
ここでのポイントは、エージェントをいきなり「全部おまかせ」にしないことです。
最初はworkflow、つまり「決められた手順に沿って動くコードの流れ」から始める。
そこから少しずつAIの判断を増やしていく。
この順番はかなり現実的です。
正直、最近のAI界隈は「agentだ」「自律だ」と言いすぎるところがありますが、実運用ではそんなに簡単じゃないです。
むしろ、まずは再現性のあるワークフローを作って、その一部にAIを差し込むほうが成功しやすい。これは地味ですが、実務では強いです。
講演の中でも、エージェントのcritical failure modes、つまり重要な失敗パターンに触れています。
エージェントは賢そうに見えても、実際には失敗します。しかも、失敗の仕方がちょっと厄介です。
たとえば、
みたいなことが起こり得ます。
このあたりは、生成AIを少し触った人なら「あるある」と感じるはずです。
だからこそ、エージェント開発は「作る」より「どう壊れるかを理解する」ほうが大事になってきます。
講演で特に重要なのが、LLM-as-a-judgeという評価方法です。
これは、別のLLMに「この出力は良いか？」「期待通りか？」を判定させる考え方です。
もちろん、万能ではありません。
LLMがLLMを採点するので、完全な客観性があるわけではない。そこは注意が必要です。
でも、大規模に実験を回すには、かなり有効です。
なぜなら、人間だけで3,500件以上の実験を毎回ちゃんと見るのは無理だからです。
そこで、まずLLMで粗くふるいにかけ、重要なものを人間が見る。
この分業は、現実的でかなり筋がいいと思います。
AIの品質管理って、派手ではないけれど本当に大切です。
私見ですが、今後のAI開発は「どのモデルを使うか」より「どう評価するか」で差がつく場面がどんどん増えるのではないかと思います。
講演では、未来に向けてtool-ready APIを作るべきだという話も出ています。
tool-ready とは、ざっくり言うと「AIエージェントがツールとして使いやすいAPI」のことです。
人間の開発者向けAPIは、ある程度柔軟であればよいことが多いです。
でもエージェント向けになると話が変わります。
AIは曖昧なものをうまく扱える一方で、予測しやすい構造があるほうが強い。だから、
といった設計が重要になります。
これはかなり本質的な話です。
将来、AIがいろんな業務ツールを呼び出すようになると、API設計がそのままAIの使いやすさになります。
つまり、APIは人間だけでなく機械にも親切であるべきなんですね。
この発表を見て感じるのは、AI時代の基盤づくりは「モデルを入れること」ではなく、組織・評価・API・運用を一緒に設計することだという点です。
Intuitの話は、かなり大きな会社の事例ですが、学べることは中小規模のチームにもあります。
このあたりは、どの会社にも効くはずです。
個人的には、AI開発の本当の難しさは「賢いモデルを作ること」より「賢さを業務で安全に使える形にすること」にあると思います。
この講演は、その現実的な答えをかなり具体的に示してくれる内容でした。派手さより地に足がついていて、そこがむしろ信頼できるところです。
参考: Powering the Future: Building Your GenAI Infrastructure Stack
