AIエージェントの導入|半年のほとんどがAI以外の作業だった

どの業務にAIエージェントを導入するかで、結果が変わります。入居者と直接話す画面にAIを導入したところ、半年のほとんどを画面づくりと、5つのシステムからデータを取る作業に使いました。AIを導入する場所を1箇所だけ動かして、作ったものを捨てた記録です。
ai-agent-dono-gyomu-kara リード図解

部屋を片付けるとき、いつも床から始めます。床が目に見えて広くなるので、進んだ感じがするからです。

ところが、床に出ていたものには、たいてい戻す場所がありません。引き出しの中がもう埋まっているからです。行き場を失ったものは、とりあえず机の上に積み上がります。

半日かけて、床が机になっただけ、ということが何度かありました。(僕はADHDなので、片付けるのが人よりとても苦手で頭のなかが真っ白になります…。)

AIを導入する会社が増えてきました。ただ、入れさえすれば効くわけではなく、どの業務にAIエージェントを導入するかで結果がはっきり分かれます。同じ予算をかけても、半年後に残っているものと、誰も使わなくなるものに割れます。

僕も、AIエージェントを導入する業務の選び方を外しました。いちばん目立つ業務を選び、6か月かけて作ったものを、まるごと捨てています。

先に一行だけ置きます。AIエージェントは、いちばん目立つ業務に導入すると失敗します。 目立つ業務は、すでに人が回していて、例外が多いからです。

今回話すプロジェクトでは、入居者向けアプリの、問い合わせ対応にAIを入れた話です。

大企業と僕の会社の共創事業として、単身者向けの賃貸物件を管理する会社の、入居者向けアプリを立ち上げました。最小限の機能だけを先に作って現場に出す、MVPと呼ばれる作り方です。その管理会社が預かっている部屋は800戸ほど。住んでいるのは学生と単身赴任の方が中心です。

入居者からの連絡は、内容がばらけます。「エアコンが効かないので見てほしい」「更新の書類はいつ届くのか」「上の階の足音が夜うるさい」。設備の話と、契約の話と、近隣の話が、1通の中に混ざって届きます。

この連絡を受けていたのは、管理会社の担当者2名です。届くのは1日に数十件、繁忙期はその倍。定型で返せるものが多いのに、2名は毎回ゼロから返事を書いていました。

だから、この問い合わせ対応にAIを導入することにしました。作ったのは、入居者がアプリから送ってきた連絡に、AIがその場で返事を書く画面です。担当者を通さず、入居者の画面に直接答えが出ます。

いちばん目立つ業務で、いちばん喜ばれるはずでした。

今日は、その選び方がなぜ外れたのか、という話をしていこうと思います。

前置きはさておき、本題に入ります。

① 教科書どおりに、入居者と話す画面にAIを導入した

ai-agent-dono-gyomu-kara 図解 1

どの業務にAIを導入するかは、素直に教科書どおりに決めました。

教科書に載っている、AIを導入する先の選び方は3つあります。手間が減ったと数字で言えるところ。お客さんが直接触るところ。毎日必ず発生していて、止まると誰かが困るところ。この3つで絞ると、候補は入居者アプリのやり取り画面しか残りませんでした。管理会社の担当者2名に聞いても同じで、「まず問い合わせですよね」と即答されています。

その画面が最初に動いたのは、作りはじめてから3週間後です。

試しに「エアコンが効かない」と打ってみます。返ってきたのは、「設置から8年経っているので、まずフィルターの状態を確認させてください。修理の手配を依頼しますか」という文面と、その下に押せるボタンが1つ。押すと、管理会社の担当者が見る一覧に、修理の申請が1件並びます。

動いた画面を担当者2名に見せたときの反応は、いま思うと少し出来すぎでした。1人は「これ、いつから使えますか」と聞いてきています。もう1人は、自分の受け持ちの物件でよく来る質問を、その場で3件打ち込んで試していました。3件とも、それらしい答えが返っています。

教科書が間違っていたわけではありません。 この段階では、失敗した感覚はまったくありませんでした。

② 半年後、書いていたのはAIではなく、画面とデータのつなぎ込みだった

ai-agent-dono-gyomu-kara 図解 2

ところが、入居者と話す画面を作り込んでいるうちに、様子がおかしくなってきました。

画面が動きはじめてからの数か月、僕がやっていたのは2件だけでした。AIの答えを画面にどう並べるかの調整と、入居者との過去のやり取りをどう保存するかの検討です。AIに投げる処理そのものは、最初の数日で書き終わっていました。

作業が画面とデータの側に寄る理由は、入居者に答えるために何が要るかを並べると分かります。「エアコンが効かない」に答えるには、その部屋の設備がいつ入ったか、前回いつ直したか、いま業者がどこまで空いているかが要ります。「更新の書類は」に答えるには、契約の更新日と、その物件のオーナーの意向が要ります。

AIは、賢いだけでは一言も答えられません。 手元にデータが無いからです。

半年で書いたものを、量として数え直しました。

何を書いていたか
入居者と話す画面603行
外のシステムへデータを取りに行く処理(全部ぶん)173行

入居者と話す画面のほうが、3倍以上あります。その173行がつなぎに行く先は5つあって、AIはそのうちの1つでした。残りの4つは、空室と契約の状況、修繕の履歴、更新日、退去時の精算規定を持っているシステムです。

つまり、半年のほとんどを、AIではなく、画面づくりとデータのつなぎ込みに使っていたことになります。

③ 気づいたのは、画面に残った後始末の処理を見たときでした

ai-agent-dono-gyomu-kara 図解 3

行数の差だけなら、まだ「そういうものか」で済んだかもしれません。

引っかかったのは、画面のコードに残っていた後始末の処理です。画面が最初に出すあいさつ文まで、入居者とのやり取りとして保存してしまい、表示のときにだけ除外する、という処理が入っていました。保存してしまったぶんは、もう取り除けません。だから、表示のたびに除外し続けるしかありませんでした。

後始末の処理は、もう1件ありました。古いやり取りから続きを始めようとすると、AIが以前の状況を思い出せません。仕方がないので、古いやり取りを開いたときは「新しく始めてください」と案内する分岐を足していました。

どちらも、AIの賢さとは関係のない話です。データの持ち方を先に決めなかったから出た穴でした。

この2件を直している時間のほうが、AIの答えを良くする時間より長くなっていました。ここで初めて、選んだ場所が悪かったのではないか、と思いはじめました。

④ 原因を1件に絞る

ai-agent-dono-gyomu-kara 図解 4

外した理由として思い当たることは、いくつもあります。設計が甘かったこと、作る順番を間違えたこと、担当者を巻き込むのが遅かったこと。

ただ、原因を絞ると1件でした。

いちばん目立つ業務にAIを導入したこと。

目立つ業務は、すでに人が回している業務です。回っているなら、例外の処理は人の頭の中に溜まっています。「この物件のオーナーのときだけ言い方を変える」「長く住んでいる方には、対応できる日を先に書く」。そういうものが、明文化されないまま動いています。

その業務にAIを導入すると、AIを賢くする前に、溜まった例外を全部コードに書き出す作業が発生します。画面のほうに603行も要ったのは、そのぶんでした。

⑤ 直したのは1箇所だけ

ai-agent-dono-gyomu-kara 図解 5

やったことは、AIを導入する場所を入居者の目に触れない側へ動かすことだけです。

入居者に答えるのをやめて、届いた連絡を仕分けて、担当者向けに要点を3行にまとめるところに移しました。設備の話か、契約の話か、近隣の話か。混ざっている場合はどれが主か。それだけです。

入居者に答えるのは、これまでどおり人がやります。

移した先で書いたコードは、192行で収まりました。画面はありません。担当者は、いつも見ている受信箱を開くだけです。

⑥ あとで知った ── 呼び分けに名前がありました

ai-agent-dono-gyomu-kara 図解 6

しばらくして、対話AIのClaudeを作っている Anthropic が出した、エージェント設計の文書を読み、手が止まりました。

そこでは、AIに仕事をさせる作りが、2つに呼び分けられていました。手順があらかじめ決まっていて、その道筋をコードで並べたものは「ワークフロー」AIが自分で次の一手を決め、道具の使い方まで自分で選ぶものが「エージェント」

エージェントが向くのは、何手かかるか読めない問題だと書かれています。原文は「open-ended problems where it’s difficult or impossible to predict the required number of steps」です。

問い合わせの仕分けは、そうではありませんでした。読んで、分けて、まとめる。手数は最初から決まっています。

さらに、いちばん簡単なやり方をまず探し、必要になったときだけ複雑にしていく、とも書いてありました。原文は「finding the simplest solution possible, and only increasing complexity when needed」です。その先には、エージェントを作らないという結論もありうる、とはっきり書いてあります。原文は「This might mean not building agentic systems at all」。

読みながら、最初に選んだ入居者と話す画面のことを考えていました。あの業務も、返事を書くまでの手数は決まっています。決まっているのに、AIが自分で考えて答える形で作っていました。どの業務を選ぶかを外すと、その業務に合わない作り方を選ぶところまで、まとめて外します。

新しい理屈は、ひとつも要りませんでした。

⑦ 変えてみて、何が良くなって、何を失ったか

ai-agent-dono-gyomu-kara 図解 7

AIを導入する場所を移してから、担当者の手元で変わったことがあります。

1件あたりの返信にかかる時間が、短くなりました。読む前に要点が3行ある状態と、ゼロから読む状態は、別物です。担当者2名のうち1名は、まとめた3行だけを見て、返信は最初から自分の言葉で書いています。 それでも、その担当者が1件に使う時間は減っています。

ただ、代償があります。3件書いておきます。

1件目。「AIを導入した」と言いづらくなりました。 画面がないので、見せられるものがありません。役員に説明するときに、実物を出せないのは地味に効きます。

2件目。間違いに気づきにくくなりました。 入居者に直接出していれば、変な答えはすぐ苦情になります。裏で仕分けているだけだと、間違った分類が静かに混ざります。だから月に一度、分類の結果を人が抜き取って見る手順を足しました。

3件目。元の画面を捨てました。 603行のうち、使い回せたのは通信まわりだけです。半年ぶんの手を、ほぼそのまま捨てています。先にこの順番で始めていれば、払わずに済んだ代償でした。

⑧ 現場で選ぶなら、この3つの問い

ai-agent-dono-gyomu-kara 図解 8

どの業務にAIを導入するかを決めるとき、この共創事業で使っている問いはこれだけです。

問いはいいいえ
手数が読めるか(何段階で終わるか言えるか)AIに任せず、手順をコードで並べるエージェントの出番
人が既に回しているか後回し。例外が頭の中にある先にAIを導入してよい
間違えたら誰かに届くか人を残す任せてよい

3つのうち、いちばん効くのは真ん中です。人が既に回している業務にAIを導入すると、例外を書き出す作業が必ず先に来ます。 その作業量は、AIを導入する前には見えません。

逆に、誰もやっていない業務は狙い目です。届いた連絡の仕分けは、それまで誰もやっていませんでした。担当者は全部読んでから判断していたので、「読む前に分ける」という工程はそもそも存在しませんでした。存在しない工程には、溜まった例外もありません。

この見方は、扱っているものには依存しません。部屋でも、部品でも、予約でも同じです。

⑨ この選び方が効き続ける理由

ai-agent-dono-gyomu-kara 図解 9

モデルが賢くなっても、この順番は変わらないと考えています。

賢さで解けるのは、判断の部分だけだからです。例外がどこにあるかを聞き出す作業も、データの持ち方を決める作業も、賢さでは短くなりません。担当者2名の頭の中にあったものは、人から出すしかありませんでした。

一方で、誰もやっていなかった工程には、頭の中に例外を溜めている人がいません。だから、賢くなるほど先に効くのは「まだ誰もやっていない工程」のほうになります。

このあたりの設計を実際の業務に落とす話は、AIエージェント開発のページに整理しています。どこからAIを導入するか決めかねている工程があれば、こちらからご相談ください。

部屋のほうは、いまも床から始めています。引き出しを先にやるべきだとは分かっているのですが、床のほうが、進んだ感じがするので。

以上です。

▶ この記事のテーマを実務で相談する: AIエージェント開発

You May Also Like

デザイン思考とは?8人に聞いたら全員が同じことを言った

デザイン思考とは、使う人の観察から出発して解決策を組み立てる進め方です。ワークショップで8名に意見を聞いたところ、共通して出たのは「ごちゃごちゃして見える、わかりづらい」でした。ここで画面を整理しに行くと外します。整理すべきは見た目ではなく機能の構造で、そのために先に作るのがファンクションリストでした。横向きで使う場面の行動観察から、進行方向の表現を水平に統一した経緯まで書きます。
View Post

MCPとは?検索画面を作るのをやめてMCP接続にした

MCPとはModel Context Protocolの略で、AIと社内の道具やデータを繋ぐための共通の作法です。社内ナレッジを全社に開くために専用のフロントエンドを作ろうとしていましたが、初期フェーズではそれを見送り、MCP接続を主軸にする設計変更をしました。理由は画面が要らないからではありません。画面を作ると、そこに認証も権限も検索体験も全部くっついてくるからです。残したのはAPIキーの発行とフォルダごとの権限管理だけでした。何を作らないと決めたのかを書きます。
View Post

ファインチューニングとは?その前に分類ではないかを疑う

ファインチューニングとは、学習済みモデルに自社のデータを追加学習させて特定の用途に合わせることです。AIの出力を検査する仕組みを作るとき、最初は生成モデルを賢くしようとしていました。ところが必要だったのは生成ではなく分類でした。Macの16GBで常駐でき、高速に動くエンコーダー型を選び、100件を目視で作ってから6000件へ拡張しました。言い換えや翻訳は100%、抽象化された要約は70〜80%止まります。選定の理由とデータセットの作り方を書きます。
View Post

ローカルLLMとは?大企業が行き着く理由と、届かない見積書

ローカルLLMとは、AIのモデルを外部のクラウドに預けず、自社が管理する環境の中に置いて動かす構成です。大企業がAI導入で止まるのは性能ではなく、社内データが外に出ること。ならば自社で動かせばいい——そう考えて見積もりを取ったら、私たちは止まりました。止めたのはGPUの固定費です。そこから分かったのは、全部を所有する必要はないということでした。100MBのモデルで振り分けだけを自社に持ったら、精度は95%から97%になりました。所有すべき場所を決めるための表を、そのまま置きます。
View Post

プロンプトインジェクションとは?禁止をプロンプトに書かない

プロンプトインジェクションとは、AIへの指示文に別の指示を紛れ込ませて、本来の制約を外させる攻撃です。対策としてまず思いつくのは、システムプロンプトに禁止事項を書き足すことです。私たちもそうしました。そして守られませんでした。プロンプトによる禁止は確率的で、ツール層のフックは決定的です。44行のフックで守る側へ移した実装と、パスの正規化や失敗時に閉じる設計まで、そのまま書きます。
View Post