FDEが届ける「ニンベンのついた自働化」 ― AI Agent時代の新しい協業の形
こんにちは！KINTOテクノロジーズ（以下、KTC）のAIファーストグループで、生成AIの社内活用推進を担当している和田です。普段は生成AIを使った業務価値の創出から、社内の教育研修、技術の手の内化まで、「AIを現場に届ける」仕事をしています。
今回お話ししたいのは、AI Agent（AIエージェント） というトレンドです。KTCのようなテックカンパニーの内側で何が起きているのか。そして、ITやAIの知識を持つ我々と、業務の知識を持つ方々（それは時によってメーカーの設計技術者さんだったり、販売店の営業さんだったりします）との「協業の形」がどう変わろうとしているのか。「ニンベンのついた自働化」というキーワードを軸に、お伝えしていきます。
1. はじめに ― なぜ今「エージェント」なのか
生成AIの進化を振り返ると、大きく3つのフェーズがあったと考えています。
| 時期 | フェーズ | 特徴 |
|---|---|---|
| 2022〜2023年 | チャットAI | 1問1答。「質問すれば答えてくれる」体験が広がる |
| 2024年 | RAG全盛期 | RAG（Retrieval-Augmented Generation：社内データ等を検索しながら回答を生成する手法）で「自社の情報を知っているAI」が登場 |
| 2025年〜 | AI Agent | AIが自ら考え、ツールを使い、複数ステップの仕事をこなす |
Agentを実現するOSSの老舗であるLangChainをはじめ、エージェントという概念自体は2023年頃にはすでに存在していました。しかし当時は、LLMそのものの"地頭"がまだ追いついていませんでした。指示を正しく理解できない、途中で迷子になる、ツールの使い方を間違える ― そんな状態を覚えている方もいると思います。
ここ1〜2年でLLM（Large Language Model：大規模言語モデル）の精度が飛躍的に向上したことで、ようやくエージェントが「実用に耐える」レベルになってきました。これは毎日エージェントを使い、自身の業務を常に効率化し続けてきた私の実感です。
2026年の今、多くの企業がエージェント技術を「PoCから社会実装へ」と動き始めています。試すフェーズは終わり、業務に組み込むフェーズに入りつつある。だからこそ、「どう組み込むか」の設計思想が問われています。
2. 目指す姿 ― 「ニンベンのついた自働化」とはどんな状態か
KTCが所属するトヨタグループでは昔から「自働化」という概念が大切にされています。「動」ではなく「働」。機械が異常を検知したら自ら止まり、不良を後工程に流さない。問題を顕在化させ、人が原因を究明し対処できる状態をつくる。人を機械の番人にせず、本来人間にしかできない判断や改善に集中させる。自動化の中に「人の知恵」を埋め込む思想です。
・・・とはいうものの、AIエージェントの時代における「ニンベンのついた自働化」とは、一体どんな状態でしょうか？
私はこう定義しています。
人間の役割が明確になっている
エージェントが作業している間、人はより創造的・判断的な仕事に集中できている。たとえば、エージェントがログ分析をしている間に、人間は対応方針の意思決定に集中する、といった状態です。
エージェントの「持ち物」が事前に整っている
必要な権限、参照すべきデータ、判断基準 ― これらを人間が先回りして渡している。エージェントに手待ちをさせない環境設計です。
「やってはいけないこと」の境界線が設計されている
例えば「データの参照はOK、削除はNG」「提案はするが、最終承認は必ず人間」といったガードレールが明確に引かれている。
業務を知る人がフロー全体をデザインしている
技術者だけでは、業務の「行間」は読めません。何年・何十年と積み上げてきたドメイン知識を持つ人が、AIとの協業設計に参加している状態です。
この4つが揃ったとき、AIは「勝手に動く怖いもの」ではなく、「信頼して任せられるチームメイト」になる。それが「ニンベンのついた自働化」の姿だと考えています。
3. 進め方の指針 ― PoCを現場に届けるための3ステップ
「エージェント、作ってみたけど現場に浸透しない」
これは本当によく起きる現象です。理由はシンプルで、技術的に動くものを作ることと、それが業務に根付くことは、まったく別の話 だからです。
私がエージェント開発の中で踏む3つのステップを紹介します。
ステップ1：課題を「正しく」見つける
ここでの「正しく」とは、AIで解くべき課題かどうかを見極めるという意味です。
何年もかけて磨き上げられてきた課題解決の型は、道具が変わっても色褪せません。トヨタグループが大切にする問題解決のアプローチ ― 「現状把握」「真因追求」は、AI活用の文脈でもそのまま有効です。
ただし、一つ重要な判断軸が加わります。「全てをAIでやろうとしない」 ということ。
たとえば、月に数回しか発生しない作業を自動化しても、構築・運用コストに見合わないことがあります。逆に、毎日30分かかる定型作業は、多少精度が荒くてもエージェント化する価値がある。費用対効果とスケール感を冷静に見極めることが、このステップの肝です。
ステップ2：試す・作り込む
AIエージェントの構造は、実はシンプルです。大きく2つの要素で成り立っています。
- プロンプト：エージェントへの「指示書」。あなたの役割はこれで、こういう手順で仕事をしてください、という設計図です。非エンジニアの方は「新人に渡す業務マニュアル」をイメージしていただくとわかりやすいかもしれません。
- ツール：エージェントが使える「道具箱」。ウェブ検索、社内データの参照、計算、メール送信など、LLM単体では苦手なことを補う機能群です。
・・・ただし、「シンプルな構造 = 簡単に完成する」ではありません。
プロンプトの書き方ひとつで、エージェントの振る舞いは劇的に変わります。ツールの選び方、渡すデータの粒度、エラー時のフォールバック設計。この作り込みの工程に、全体の工数の大半がかかると言っても過言ではありません。
ステップ3：業務フローに「組み込む」
ここが最も重要で、かつ最も見落とされやすいステップです。
完成したエージェントを業務フローのどこに置くか。誰が使うか。既存のツールとどう共存させるか。例外が起きたときに誰がフォローするか。
これらの問いに答えられるのは、ドメインの知識を持つ人だけ です。
ここで言う「ドメイン知識」とは、特定の業務ノウハウだけを指しているわけではありません。業務フローを再設計するための価値判断基準、組織の意思決定経路や力学、そして現場の肌感覚 ― これらすべてを含む、長年の経験から培われた知の総体です。
たとえば自動車・モビリティの領域で考えると、その重要性がよくわかります。
現場の業務ノウハウ
整備士が持つ「この車種のこの年式は、ここが壊れやすい」という経験則。販売店の営業が持つ「この地域では◯月に需要が伸びる」という季節感覚。こうした知識は、個別業務に深く根ざしています。
価値判断と優先順位の基準
「納車までのリードタイムを短縮するよりも、お客様への中間報告の頻度を上げるほうが満足度に効く」「この検査工程は品質上絶対に省略できないが、書類作成の順序は変えられる」。業務フローを再設計するとき、何を守り何を変えてよいかを判断できるのは、その業務の「重み」を知っている人だけです。
組織の事情と意思決定の経路
「この変更はA部門だけでは通らない、B部門の部長の合意が要る」「この申請は制度上オンラインで完結するが、実質は事前の根回しが必要」。どんなに優れたエージェントを作っても、組織の中で動かせなければ意味がない。その道筋を知っているのも、ドメインの力です。
これらの知識は構造化されていません。業務マニュアルにも社内ドキュメントにも、ましてやLLMの学習データにも十分には載っていない。だからこそ、エージェントを開発する技術者だけでは業務フローの設計はできないし、業務を知る「人」が設計に参加する必要があるのです。
具体的な場面で言えば、「この申請は月末に集中するから、そのタイミングでエージェントが下書きを用意しておいてくれると助かる」「この承認フローは部長の口頭確認が実質必要だから、エージェントの自動承認は外したほうがいい」 ― こうした判断は、何年も現場で業務を回してきた人にしかできません。
だからこそ、ステップ3は技術者と業務担当者の「共同作業」になります。ここに「ニンベンのついた自働化」の真価があると考えています。
4. よくある落とし穴 ― 「動くけど根付かない」を避けるために
セクション3で「正しい進め方」を紹介しましたが、現場では逆のパターン ― つまり、やってしまいがちな失敗 ― も数多く見てきました。エージェントが「技術的には動いているのに、業務に根付かない」とき、原因はたいてい次の3つのどれかに行き着きます。
落とし穴1：「全部AIで」と決めつけてしまう
エージェントの可能性に惹かれるあまり、「AIに丸投げ」してしまうケースです。
一見すると大胆で魅力的に聞こえます。しかし、業務フローの中には「人の判断が入ることで価値が生まれている」工程が必ずあります。たとえば、クレーム対応における熟練オペレーターの声色の判断や、契約書レビューでのベテラン法務担当の「この条項は先方の意図と違う気がする」という直感。データ上は自動化できそうに見えても、その判断こそが顧客との信頼関係を支えている。こうした工程をAIに丸ごと置き換えると、効率は上がっても、守るべきものが静かに失われていきます。
ステップ1の「AIで解くべき課題かどうかの見極め」が甘いと、ここにはまります。
落とし穴2：ドメインエキスパート不在のまま業務フローを設計する
エンジニアだけで「こう組み込めば効率的だろう」と業務フローを設計してしまうケース。技術的には合理的でも、現場の実態と噛み合わない、机上の空論で設計が進行してしまいます。
セクション3で挙げた「組織の事情と意思決定の経路」。これを知っているのは、何年もその業務を回してきた人だけです。エンジニアがどれほど優れていても、この層の知識は外から取得できません。
落とし穴3：「作って渡す」で終わりにしてしまう
「エージェント、完成しました。マニュアルも書きました。あとはよろしくお願いします」。
この引き渡し方は、ほぼ確実に定着しません。エージェントは従来のシステムとは違い、使い方や問いかけ方によって振る舞いが変わります。現場の人が「こう聞けばこう返る」という感覚を掴むまでには、作った人と一緒に使ってみる期間が要ります。
もうひとつ見落とされがちなのが、UI/UXの設計 です。エージェントと聞くと、つい「チャットUI」を思い浮かべがちですが、チャットはあくまで暫定的なインターフェースにすぎません。現場の人が本当に求めているのは「チャットで何でも聞ける」体験ではなく、「いつもの業務の流れの中で、自然にAIの力が効いている」体験です。それはボタンひとつで起動するワークフローかもしれないし、既存ツールの中に溶け込んだ提案機能かもしれない。チャットUIで得たフィードバックを手がかりに、ユーザーが本当に求める体験を作り込んでいく ― この工程を「渡して終わり」にすると、永遠にチャットの域を出られません。
使っていく中で「ここはもう少しこうしてほしい」というフィードバックが生まれる。そのフィードバックをその場で反映できる ― この即応性が、エージェントが業務に馴染むかどうかの分岐点になります。
これらの落とし穴に共通するのは、技術と業務の間に「翻訳者」がいない ということです。
エージェントにせよ何にせよ、使ってもらってなんぼ です。どれだけ精緻に作り込んでも、現場で使われなければ価値はありません。そして「使われる」ためには、技術的な完成度よりも、業務への馴染み方のほうがはるかに重要です。エンジニアとドメインエキスパートが同じ机で一緒に考える体制さえあれば、これらの失敗の多くは防げます。
次のセクションでは、その「一緒に考える」を実現するための協業モデルについてお話しします。
5. 今後の展望 ― Forward Deployed Engineer（FDE）という協業の形
最後に、「ニンベンのついた自働化」を現場に届けるための、IT企業との新しい協業モデルについてお話しします。
Forward Deployed Engineer（FDE） とは、エンジニア自身が顧客の現場に入り込み、課題のヒアリングから実装・運用定着まで一気通貫で担う職種です。
起源は米国の Palantir Technologies が確立した FDSE（Forward Deployed Software Engineer） とされています。名前の由来は軍事用語の「Forward Deployed（前線展開）」で、「製品を納品するだけでは使われない、エンジニアが現場に入って初めて価値が生まれる」という哲学から生まれました。
従来のIT企業では、エンジニアは社内でシステムを開発し、営業・PM・カスタマーサクセスを介して顧客と接するのが一般的です。FDEはこの構造を変え、エンジニアが顧客と直接対話しながら、要件定義・実装・定着支援までをすべて担います。コンサルタントと異なるのは「自ら手を動かす」点です。
具体的には、作れるエンジニア自身が、課題を持っている現場に直接入り込んで、一緒に考える。プロトタイプを一緒に触りながら、同じ机で議論する。セクション4で挙げた「作って渡す」で終わりにしてしまうという落とし穴の裏返しとも言えます。作って渡すのではなく、作りながら一緒に使う。その距離感が、エージェントの定着を左右します。
| 役割 | 担うこと |
|---|---|
| FDE（IT側） | 技術的な複雑さを引き受ける。AIの限界と可能性を正直に伝える。「これはできます、これは今は難しいです」を明確にする。 |
| ドメインエキスパート（業務側） | 業務の文脈を提供する。「このデータならここから取れる」「この件は誰に聞けばいい」「この申請は私が通します」という現場の力を発揮する。 |
この2つが掛け合わさったとき、初めて「ニンベンのついた自働化」が現場に根付く。私はそう信じています。
KTCは、この「FDEとドメインエキスパートの共創」を、自分たちの現場で実践し続けていきます。困りごとを見つけ、試し、形にして、届ける。そのサイクルの中で得た知見を、こうした場で発信していくことが、私にできる貢献のひとつだと考えています。
ここまで読んでいただき、ありがとうございました！
「AIエージェント」という言葉が少し身近になり、「うちの現場でも何かできそうだな」と感じていただけたなら、この記事を書いた甲斐があります。
ぜひ一緒に、「ニンベンのついた自働化」を実装していきましょう。
