「コード化できない課題をLLMで解く」　LayerX松本氏が語る、AIエージェント時代のプロダクト開発の在り方、LLMを生かすための前提条件：AIアプリケーション開発の勘所とは

　LayerXは、「すべての経済活動を、デジタル化する」というミッションの下、12年間にわたりAI分野に取り組んできた。同社が提供する「バクラク」は、経費精算や請求書処理などのバックオフィス業務を、機械学習技術を活用して効率化するSaaS（Software as a Service）で、既に1万社を超える企業が導入している。

LayerX 代表取締役CTO 松本勇気氏

　さらにLayerXは、生成AIを活用した新たな業務支援SaaS「Ai Workforce」を開発した。契約書のドラフト作成、レビュー、稟議（りんぎ）書作成、決算書の分析など、企業で日常的に発生する大量の文書処理を、単一のプラットフォーム上で自動化できる点が特徴だ。特に金融業界での導入が進んでおり、融資業務をはじめとする多様な業務を一括で処理、支援している。LLMの特性を最大限に生かし、文書を軸に、包括的な業務支援をするプロダクトだ。

　「チャットUI（ユーザーインタフェース）では、想像以上にプロンプト作成が難しく、期待した効果が出ないケースもあります。多くの企業では、文書を直接扱う業務が圧倒的に多いです。そこでAi Workforceは、文書を『読む、書く、レビューする、共有する』という一連のプロセスにフォーカスしました」（松本氏）

Ai Workforceが担う包括的な業務支援（松本氏の講演資料より）

　LayerXがAi Workforceを開発したのは、LLMによって新たな市場が生まれたことが背景にあるという。具体的には、これまでのSaaSでデジタル化できていた業務は全体の2〜3割程度だったが、残りの7〜8割は、依然として人手による業務のままだった。この残された領域も、LLMを使えばデジタル化できると、松本氏は言う。

LLMの本質的な価値は、言語化による問題解決

　松本氏は、LLMの本質的な価値を、言語を使って問題を解決する特性に見いだしている。従来は、まず人間が業務プロセスを詳細に分析し、それを言語化し、その上でさらに課題を解決するコードとして実装する必要があった。しかし曖昧な入力情報など、プログラミングが難しい領域も多く存在する。そのため、解決できる範囲は限定されがちだった。これが「LLMの登場により状況は一変した」と松本氏。問題を適切に言語化すれば、LLMはその情報を基に評価、推論し、問題解決が可能になる。その結果、従来よりも広範な業務をデジタル化できる。それが松本氏の言う、LLMによる新しい市場だ。

　松本氏は、SaaSの進化を三世代に分けて定義し、LLM以前のプロダクトとの違いを明確にした。

　第一世代は共有データベース型SaaSで、クラウド上に共有データベースを持つことで業務の標準化や可視化を実現したが、自動化の範囲は限定的だった。第二世代はAI統合型SaaSで、OCR（Optical Character Recognition：光学的文字認識）やレコメンドエンジンといった従来の機械学習技術を組み込み、一部業務プロセスの高度な自動化を実現した。しかし、これらは明確なルールのある業務に限られていた。

　これに対し、第三世代のLLM統合型SaaSは、Ai Workforceのように、単一のプロダクトの中で、多様な業務を扱うことができ、人間と同じようなアウトプットを返してくれる。加えて、言語化さえできれば、既存業務フローの変更なしに導入できるのも特徴だ。

　「LLMの登場により、業務プロセスの言語化から既存のプロセスへの統合に至る流れが、従来と比べてスムーズになり、対応できる領域も大きく広がりました。それが、プロダクト開発において、LLMがもたらした最大の変化の一つだと考えています」（松本氏）

LLMの柔軟性がソフトウェア開発を変える（松本氏の講演資料より）

LLMを活用するプロダクト開発の前提条件

　続いて松本氏は、Ai Workforce開発の経験を踏まえ、LLMを活用してプロダクトを開発する際の前提条件を解説した。

　まず、LLMベースのプロダクトの構想を描く際は、現在のLLMの性能やコストにとらわれるべきではないと勧めた。例えば、OpenAIの「GPT-3」は、登場後わずか1年で、同等性能モデルの利用コストが10分の1以下にまで下がった。また東京大学の入試問題をほぼ満点で解けるモデルも登場するなど、ある側面では、既に人間以上の能力を獲得しているともいえる。

　そんな中で、LLMベースのプロダクトを設計するには、LLMの性能の高低ではなく、「サービス側でうまくLLMを活用できているかどうか」という視点が欠かせないと、松本氏は強調する。

　これらの前提に立って、LLMから最大限の価値を引き出すために、松本氏が重視するのは「自社独自のデータの蓄積」「ユーザーとの接点」の2点だ。LLMは基本的に、企業や業種に特化した知識、顧客ごとの具体的な事情は何も知らない。そのためLLMの精度を高めるには、自社独自のデータの蓄積が欠かせない。そしてこれらのデータを集めるためには、ユーザーがLLMに実際に触れる接点を確保することが重要だ。

LLMプロダクト開発の前提条件（松本氏の講演資料より）

　また、LLMを効果的に活用するためには、人間と同様のオンボーディングも必要だ。短いプロンプトだけでは、LLMに精度の高い作業を行わせることはできない。業務の背景、判断基準、使用するツール、ドキュメントのフォーマットなどを丁寧に伝えることで、LLMも自社に合った仕事の仕方を理解し、成果を出せるようになる。

　注意すべき点として松本氏は、「ポイントソリューションに陥らないこと」が重要だと指摘する。特定の用途に特化したツールは多く存在するが、LLMの本質的な強みは、複数の業務や機能を横断的に取り込める点にある。そのため、特定業務のみのポイントソリューションは、将来的により広範な業務プロセスをカバーするLLMベースのソリューションに統合されていく可能性が高い。つまり、特定用途のプロダクトを開発する場合でも、常に業務全体の流れを俯瞰（ふかん）し、周辺にある課題にも対応できるよう視野を広げることが必要だ。こうして、要所要所で業務課題の解決を担うプロダクトは、最終的にLLMベースのAIエージェントにより統合されるのだという。

　「これからプロダクトを設計する際には、個別の機能をエージェントでつないでいく構造を意識する必要があります。小さなプロダクトをLLMやエージェントの力で統合することで、業務プロセス全体を担う包括的なAIソリューションとして完成するのです」（松本氏）

AIエージェントによる統合（松本氏の講演資料より）

　一方で、LLMの性質として、課題の粒度が大き過ぎると、精度が低下してしまうという問題がある。そこで、問題を可能な限り小さく分解し、段階的に自動化するアプローチも欠かせない。「請求書処理を自動化する」という課題なら、OCRによる値抽出、抽出した値の分類、分類に応じた次の処理の構成といった小さな作業に分解し、再統合することが必要になる。

AIエージェント時代のプロダクト設計

　AIエージェントは、AI活用の文脈で今、大きな注目を集めている。松本氏によれば、従来のシステムと、エージェンティック（Agentic）なシステムの違いは、判断主体にあるという。従来のシステムでは、業務プロセスの計画立案、実行手順の設計、評価基準の設定など、判断主体は全て人間が担っていた。一方、エージェント的なシステムでは、LLMが自ら実行計画を考え、外部ツールや他のシステムと連携しながら処理を進め、完了基準への到達をAIエージェント自身が評価する。そして必要に応じて処理内容を振り返って、新たな計画を立て直す。つまり判断主体をLLMに委ね、人間の補助なしに、自律的な目的達成を目指すのがエージェンティックなシステムだ。このようなAIプロダクトの開発を、LayerXでは「自動運転化」と呼んでいる。

　レベル0〜2までは「人間主導の自動化」段階で、AIは支援ツールとしての役割を果たす。レベル0は完全手動、レベル1はOCRなどの簡易AI機能、レベル2はLLMを活用した分類・整理の自動化だが、いずれも人間が業務の主導権を握っている。

　レベル3〜5は「AI主導の自動化」段階で、AIが業務をハンドリングする。レベル3では「報連相をするAI」として、AIが主導しつつ人間に適宜確認を求める。レベル4では定型業務をAIがほぼ完全に自律処理し、レベル5で完全自動化が実現される。

AIエージェントの発展段階（出典元：松本氏の講演資料より）

　もちろん、いきなりレベル5の実現を目指すのも現実的ではない。段階的に「自動運転化」を目指すことで、各段階で必要となるデータや機能、外部システムとの連携要件を明らかにしながら、将来の拡張性や柔軟性を確保した設計が可能になる。LayerXでは、まずレベル3〜4までをどう実現するかを念頭に置いて、プロダクトの設計やロードマップを検討していると、松本氏は言う。

　それでは、エージェンティックなプロダクトは、どのようなアーキテクチャで構成されるのだろうか。松本氏によれば、従来のソフトウェア開発にはなかった以下の5つの要素を統合的に設計する必要があるという。

Agentic Workflow

　決定論的な処理と柔軟な思考を組み合わせたハイブリッドなワークフローを指す。定型処理とLLMによる動的判断を組み合わせたハイブリッドな処理フローが必要になる。

Knowledge

　いわゆるRAG（検索拡張生成）のベースとなる検索基盤。エージェントが社内文書や過去の履歴など多様な情報源にアクセスできる環境を提供する。

Tools

　外部サービスとの連携機能。API、MCP（Model Context Protocol）、A2A（Agent-to-Agent）通信など、エージェントがタスク実行中に必要なツールを動的に呼び出せる設計が重要だ。

Memory

　学習とパーソナライゼーション機能で、過去の経験から学び、個人や企業ごとに最適化された振る舞いを実現する仕組みが必要となる。

Evaluations

　不確定要素が多いLLMの出力を、定量／定性の両面で評価、モニタリングし、品質維持と改善、異常検知、セキュリティ対策などを継続的に取り組む必要がある。

　「エージェンティックなプロダクトでは、従来の局所的な機能追加ではなく、プロダクト全体をLLM前提で再設計する視点が不可欠だ」と松本氏は指摘する。それは「LLMらしいUI/UX（ユーザー体験）とは何か？」を検討し続けることでもある。また、現状のLLMの精度では、依然として人との共同作業は欠かせない。ユーザーがAIを信頼し、違和感なく使えるUI/UXを設計することが、LLMプロダクトを業務に浸透させるカギだとした。

人とAIの共同（出典元：松本氏の講演資料より）

　「LLMによって、解決可能な問題の幅が広がった今、どのようにLLMに適切な情報を渡すのか、どのように課題を分解し、それに応じた体験設計をするのか。これらを丁寧に考えることが、本当に価値のあるLLMプロダクトを作るための第一歩になります」と述べ、松本氏は講演を締めくくった。