Claude CodeやCodexを使って、業務アプリを作る。こうした開発の可能性は大きいと感じます。これまで費用や時間の制約で形にできなかった、小さな業務上の困りごとにも手が届くからです。

一方で、作れるものが増えたからこそ、「何を作るべきか」は丁寧に考える必要があります。業務ごとに新しいアプリを用意すれば、利用者が覚える操作や、情報を探しに行く場所も増えます。開発者が作りやすくなることと、現場が働きやすくなることは、同じではありません。

当初は、AIで従来型の業務アプリを次々と作る発想そのものが、古くなり始めているのではないかと考えました。ただ、調べた結果、その言い方は強すぎると感じています。

YCは2026年秋の募集テーマで、個人や少人数のチームに合う小さなソフトウェアを、AIで作り、共有しやすくする機会を挙げています。同時に、建設・保守・車両運用などの現場で、人・AI・ロボットの仕事を割り振る新しい業務基盤にも期待を示しています。[1]

これは市場全体の未来を証明するものではありませんが、両者を対立させる必要がないことを示唆しています。専用アプリが役立つ仕事はある。そのうえで、人が入力や転記をしなくても済む部分は、裏側へ移していく。その組み合わせを考える余地が広がっているのだと思います。

Claude CodeやCodexで作る対象も、画面だけに限りません。業務ルール、外部システムとの連携、承認処理、検証の仕組みも開発の対象です。問われるのは、使う開発ツールよりも、利用者にどんな仕事の進め方を提供するかです。

専用画面を作り、人に操作してもらう。
その前提を、一度問い直したい。

ヘッドレス化とは、業務の機能を特定の画面から切り離し、APIなどを通じて別の接点から利用できるようにすることです。Salesforceにも、Apexで書かれた業務ロジックをMCPのツールとしてエージェントに公開する仕組みがあります。[3]

ただ、入口をチャットに置き換えるだけでは、人はまだ文字を打たなければなりません。画面を開き、状況を文章にまとめ、依頼を入力する。その負担も減らせるはずです。音声で意図を伝えることから、業務が始まる世界まで考えたいと思います。

例えば、現場で撮った写真や機器表を送り、「この機器と同等の製品で見積もりを作って」と話しかける。AIが型番や仕様を読み取り、商品マスターと照合して候補を提示する。情報が足りなければ、「どの現場の見積もりですか」と音声で聞き返す。担当者は会話で条件を補い、必要な比較や確認だけを画面で行う。これは、音声・画像・業務システムの連携を整えた場合の設計例です。

目指したいのは、話した内容を、そのまま文字起こしするところで終わらない体験です。「今日の作業はここまで終わった」と伝えれば、報告に必要な項目を整理し、不足する内容を確認したうえで記録する。人が話した意図を、検索、入力、登録といった後続の仕事につなげていきます。

作業の区切りに短く話せば、あとで机に戻って同じ内容を入力し直す手間を減らせる。話しながら考えを整理し、必要なことだけ聞き返してもらえる。キーボード操作や、整った依頼文を書くことを、業務を進めるための条件にしなくてよくなる可能性があります。

文字を打つ手間を減らし、
話すことから、仕事が進む。

入口には、SlackやLINE WORKSのように普段使うツールも選べます。ただし、音声でどこまで操作できるかは、利用する機能や連携の設計によります。現場では音声、机に戻ったら比較表、上司には承認通知。同じ仕事でも、役割や場面に合わせて接点を切り替えられることが大切です。

さらに、毎回話しかける必要もないでしょう。書類の到着や期限の到来をきっかけに、あらかじめ認めた範囲で処理を進め、判断が必要な時だけ人へ戻す。人が必要な時に音声で依頼することと、条件が整った仕事が自動で進むこと。その両方を組み合わせれば、人の意図と、業務上の出来事を起点に仕事が進む体験へ近づけると思います。

この方向は、すでに製品の形になっています。YCの2023年夏のプログラムに参加したHappyRobotは、物流向けに、配送状況の電話確認、到着予定の更新、予約調整、必要書類の回収などをAIが担う仕組みを紹介しています。[4]

注目したいのは、会話をするだけでなく、その結果を後続の仕事につなぐ点です。配送予定が変われば情報を更新し、問題があれば担当者に知らせる。この構成からは、AIの価値を「うまく答えられるか」から「次の工程を進められるか」へ広げる動きが読み取れます。

Sierraも、音声やチャットなどで依頼を受け、CRMや注文管理システムとつないで返品などの手続きを進める製品を提供しています。料金についても、成果に基づくモデルを掲げています。[5]

Basisの会計業務向け製品は、顧客ごとの方針や確認基準を踏まえて処理し、不確かな項目や例外を人の確認へ戻す設計です。[6] ここでは、AIに任せる部分と、会計担当者が判断する部分が組み合わされています。

各社の対象業務は違いますが、共通しているのは、業務の途中にある具体的な作業を引き受けようとしていることです。システムの使い方を案内するだけでなく、条件の整った仕事を実行する。私の仮説を支えるのは、この製品設計の方向です。

中国の企業を見ると、別の実装方法も見えてきます。影刀（Yingdao）は、ERPやブラウザなどの既存画面をRPAが操作し、反復作業を自動化する製品を提供しています。[7] 実在智能（Intelligence Indeed）も、AIとRPAを組み合わせた画面操作を紹介し、DingTalkやFeishuへの組み込みを進めています。[8]

ここで、言葉を分けておきたいと思います。APIを通じて画面から独立した機能を呼び出すことと、AIが既存の画面を操作することは、技術的には異なります。後者では、利用者が触らなくなっても、裏側で画面が使われ続けます。

したがって、これらをすべて「ヘッドレス化の実例」と呼ぶのは正確ではありません。ただし、利用者にとっては、自分で画面を開き、転記し、確認する負担が減るという共通の変化があります。

現実の企業には、APIで連携できるシステムも、画面操作を前提としたシステムもあります。すべてを一度に作り直すより、接続できる部分から機能を切り出し、それ以外は操作代行も検討する。実装を考える際には、それぞれの変更への強さや、失敗時に復旧できるかまで見る必要があります。

今回確認した事例から言えるのは、人による手操作への依存を減らす、複数の道があるということです。米国と中国の優劣や、市場全体の主流を、この事例数だけで決めることはできません。

海外事例には、「画面はなくならない」という根拠もあります。YC出身のCampfireは、AIを組み込んだERPとして会計処理を自動化する一方、台帳や取引まで掘り下げて確認できるダッシュボードも提供しています。[9]

さらに興味深いのが、HappyRobotです。同社はAIによる業務実行に加え、その活動を確認し、例外へ対応するための画面を用意しています。そして、導入時にFDEが顧客向けのアプリを作ることを明記しています。[10]

この事例は、私が考える次の業務アプリケーションの姿に近いものです。日々の作業はAIに任せながら、人は状況を見渡し、必要な判断を下す。画面の役割が、すべての処理を手で進める場所から、比較・監督・承認のための場所へ広がっていくのではないでしょうか。

もちろん、残すべき画面は業務によって違います。一件の作業報告は音声が便利でも、十件の見積もりを比べるなら一覧表の方が分かりやすい。周囲の音や会話できる環境によっては、文字入力を選びたい場面もあります。工程の調整では、会話を何往復もするより、予定を俯瞰できる画面の方が速い場合もあります。

また、顧客情報、商品マスター、取引記録、権限、承認ルール、変更履歴といった業務の基盤は、入口が変わっても必要です。音声やチャットから依頼した場合と、従来の画面から入力した場合で、適用される業務ルールが違ってしまっては困ります。

設計の出発点は、「何をチャットにするか」よりも、「どこで人が迷い、待たされ、同じ作業を繰り返しているか」でしょう。その負担を減らせるなら、音声でも、画像でも、専用画面でもよい。重要なのは、利用者が無理なく、確実に仕事を進められる組み合わせです。

こうした変化が進むほど、「AIを導入できます」「アプリを作れます」という説明だけでは、価値を伝えにくくなると考えています。お客様が知りたいのは、自社のどの仕事が楽になり、どんな成果につながるかだからです。

ただし、今回の調査から「売ることが必ず難しくなる」とまでは言えません。Sierraが掲げる成果に基づく料金モデルは、価値の伝え方が変わり得る一例です。[5] 仕事の完了や改善効果が明確になれば、むしろ説明しやすくなる場面もあるでしょう。

そのために必要なのが、業務と業界への理解です。同じ見積もり作成でも、製品の能力だけを比較すればよいのか、寸法や電源、設置条件まで確認すべきなのかで、作る仕組みは変わります。どの条件なら自動で進められ、どこから先は専門家の判断が必要なのか。これは一般的なAIの知識だけでは決められません。

例えば、現場では「確認に時間がかかる」と言われていても、原因は検索の遅さとは限りません。マスターの情報が古い、担当者によって判断基準が違う、承認者が不在だと止まる。原因が違えば、必要なのは検索機能の改善なのか、データ整備なのか、業務ルールの変更なのかも違ってきます。

効果の測り方も、画面の数やAIの回答件数だけでは不十分です。依頼から完了までの時間、人が介入した回数、差し戻しや修正の割合を、導入前後で比べる。確認作業が増えていないかも含めて見ることで、現場の負担が本当に減ったかを確かめられます。

自動化の対象を選ぶ時は、頻度が高く、判断条件を明確にでき、結果を確かめやすい仕事から始めたいと思います。小さな成功を積み上げながら、任せられる範囲を広げる。その順序を決めること自体に、業務理解の価値があります。

業務を理解するだけでは、仕組みは動きません。その理解を、データの持ち方、検索の方法、実行する処理へ落とし込む技術が必要です。特に、社内文書を検索して回答の根拠にするRAGでは、チャンクとリトリーバーの設計が、AIに渡る情報の質を左右します。

チャンクは、文書を検索・参照しやすい単位に分けた情報のまとまりです。細かく分けすぎると、仕様と注意書きが離れてしまう。大きすぎると、必要な条件が関係のない記述に埋もれる。文章の構造や、参照する単位に合わせて切り分ける必要があります。[11]

Difyの技術文書では、小さな子チャンクで関連箇所を検索し、その親に当たる大きな文脈を取り出す方法も説明されています。[12] たとえば特定の型番の記述を見つけた後に、その製品群に共通する条件まで渡す。検索の細かさと、判断に必要な文脈を両立させる考え方です。

リトリーバーは、依頼に必要な情報を探し出す仕組みです。意味が近い文章を探すだけでなく、型番の正確な一致、製品分類、資料の更新日なども使って候補を絞ります。キーワード検索とベクトル検索を組み合わせ、必要に応じて候補を並べ直す方法もあります。[13][14]

ここでも、業務知識が設計に効きます。型番の末尾が違うだけで電源仕様が変わるなら、「似た型番」を見つけるだけでは不十分です。旧製品の資料を参照してよい場面と、現行品だけを対象にすべき場面も違います。検索の良し悪しを決める基準は、使う業務から作る必要があります。

ただし、チャンクや検索方式を変えれば、必ず精度が上がるわけではありません。実際の依頼と、必要な根拠、期待する結果をそろえ、変更前後を比べることが重要です。正しい情報を検索できなかったのか、見つけた情報の解釈を誤ったのか、登録処理に失敗したのか。問題を分けて見ることで、改善すべき場所が明確になります。

評価には、通常の成功例だけでなく、情報不足、古い資料、似た型番、例外条件も含めたいところです。正解を返すことに加え、分からない時に確認を求められるか。根拠のない候補を、確かなものとして処理しないか。現場で困るケースを先に集めることが、検証の質につながります。

音声を入口にするなら、検証の対象も広がります。例えば、製品名や数字を聞き違えた時に、そのまま検索や登録へ進まないか。「それ」「さっきの写真」が何を指すか曖昧な時に、必要な確認を返せるか。音声の認識だけでなく、会話の文脈と業務データを結び付け、意図を確かめてから処理する設計が必要です。

そして、検索の精度と、業務処理の正確さは別です。金額計算や必須条件の照合は、データベースや明確なルールで処理する。実行前には権限と承認を確認し、再試行しても二重登録を起こさないようにする。途中で失敗した時に、どこまで完了したか分かる記録も必要です。

入口が短い会話になった分だけ、その裏側には丁寧な設計が求められます。利用者の操作が減ることは、システムの責任が軽くなることではありません。正しい根拠を取り出し、許された範囲で実行し、結果を確かめる。その一連の品質を作ることが、エンジニアリングの重要な役割になります。

ここで重要になるのが、FDE（Forward Deployed Engineer）という役割だと考えています。顧客の現場に入り、課題の発見から実装、検証、運用改善までをつなぐエンジニアです。

HappyRobotのFDE求人でも、顧客への導入支援、API連携、機能開発、フィードバックを踏まえた改善が仕事内容として挙げられています。[15] 先ほどの、AIの仕事を確認するための画面を作るという説明と合わせると、FDEが何を担うかが具体的に見えてきます。

現場を知ることで、省ける操作や、残すべき判断が見える。実装してみることで、マスターの不足や業務ルールの曖昧さが分かる。その発見を持ち帰り、業務とシステムの設計を見直す。この往復は、最初に要件を書き切るだけでも、コードを書く速度を上げるだけでも代替しにくい仕事です。

例えば、一種類の見積もり業務から始め、実際の依頼で検索と候補提示を試す。担当者が修正した理由を集め、検索条件やマスター、承認の基準を直す。信頼できる範囲が見えてから、登録処理をつなぐ。現場の判断を検証可能な形へ変えていくことが、実装を前へ進めます。

もちろん、あらゆる導入に外部のFDEが必要だという意味ではありません。社内の業務担当者とエンジニアが協力して担うこともできます。肩書き以上に重要なのは、業務の結果に向き合いながら、技術を変え、また現場で確かめられることです。

さらに、現場ごとの対応で終わらせず、繰り返し現れる連携、評価方法、承認の仕組みを共通化できれば、次の導入にも知見が生きます。個別の業務に深く入りながら、再利用できる仕組みへ戻す。その積み重ねにも価値があると考えています。

今回の調査を通じて、最初の仮説は少し具体的になりました。人が毎回行ってきた操作の一部は、AIや連携の仕組みへ移せる。一方で、判断に必要な画面と、信頼できる業務の基盤は残る。その組み合わせを設計することが、これからの業務アプリケーションづくりでは、より重要になるのだと思います。

アプリを作りやすくなった今だからこそ、使う人にどんな操作を残すのかを丁寧に考えたい。文字を打つ手間まで減らし、話すことから仕事が進み、必要な場面で人が判断する。今回のDreamforceは、そんな業務の姿を改めて考える機会になりました。