PR・取材協力：株式会社homula・Activated Trigger株式会社
[Interview]AIの専門家と、プロジェクトを進める人。両方がそろうと、AI導入は前に進む
AIエージェントの実行基盤「agens」を開発する homula と、コンサルティングファーム出身のコンサルタントを紹介する Activated Trigger。日本生命グループの投資先どうしの2社が、AI導入を前に進めるために何が要るのかを話した。
株式会社homula 取締役
側原 圭太
Activated Trigger株式会社 代表取締役
澤 万純
[Interview]
この記事のサマリー
- 01AI導入が止まるのは、AIの精度よりも、業務として回す仕組みと進め方が決まっていないため。
- 02homula は、ゴールを渡すとAIが計画して実行する「agens」と、決まった流れを繰り返す n8n を、業務ごとに使い分ける。
- 03AIの専門家と、プロジェクトを進める人が段階ごとに役割を分けると、社内の合意と定着が進む。
AIエージェントで業務を自動化したい会社が増えています。一方で「試してみたが、現場に定着しなかった」という声も聞きます。 AIエージェントの実行基盤「agens（エージェンス）」を開発し、導入の支援も数多く手がける homula。コンサルティングファーム出身のコンサルタントを企業に紹介している Activated Trigger。2社はどちらも、日本生命グループのベンチャーキャピタルから出資を受けています。立場の違う2社が、AI導入を前に進めるために何が要るのかを話しました。
01
同じ投資家を持つ2社が、なぜ話すのか
澤（Activated Trigger）
最初に、2社の関係からお話しします。homula さんと当社は、どちらも日本生命グループのニッセイキャピタルから出資を受けています。同じ投資家の投資先どうし、という間柄です。事業はまったく違いますが、お客様から聞く悩みは重なっています。
側原（homula）
そうですね。私たちは2019年の創業で、いまはAIエージェントで企業の事務業務を自動化し、運用が定着するまで支援しています。お客様は、AIを入れたい会社です。澤さんの所のお客様も、最近はAIの相談が多いと聞きました。
澤（Activated Trigger）
はい。当社は「PERSONA」というサービスで、コンサルティングファーム出身のフリーのコンサルタントを企業に紹介しています。以前は、戦略の立案や業務改革の相談が中心でした。ここ1〜2年は「AIを入れたいので、進められる人を紹介してほしい」という相談が目立って増えています。
側原（homula）
私たちは技術の側から、澤さんは人の側から、同じ課題を見ているわけですね。
澤（Activated Trigger）
そう思います。今日は、両方の側から見えていることを突き合わせてみたいです。
02
AI導入は、どこで止まるのか
澤（Activated Trigger）
当社に来る相談では、ツールはもう選んであることが多いです。それでも進んでいない。側原さんの所には、どんな状態の会社が相談に来ますか。
側原（homula）
いちばん多いのは「試した段階では動いたのに、本番に進めない」という状態です。たとえば請求書の処理です。AIに請求書を読ませて、内容を取り出す所まではすぐにできます。ところが本番では、発注の記録と金額が合わない請求書が届きます。取引先の名前が登録と少し違うこともあります。そういう例外をどう扱うかが決まっていないと、結局は人が全部を見直すことになります。
澤（Activated Trigger）
AIの精度の問題ではない、ということですか。
側原（homula）
精度よりも、業務として回す仕組みの問題です。処理が途中で止まったときに再開できるか。やり直したときに二重に登録されないか。誰が何を承認したのかを後から確かめられるか。どれもAIのモデルの外側で決まります。
澤（Activated Trigger）
相談に来る会社は、その論点に気づいていますか。
側原（homula）
気づいていないことが多いです。チャットのAIは、聞けば答えてくれます。その体験から入ると「答えの質」に目が行きます。業務を任せる段階では、問うべきことが「任せた仕事が終わっているか」に変わります。AIが「完了しました」と返しても、それは完了の証拠になりません。
澤（Activated Trigger）
事務の仕事は、これまでもRPAや外部への委託で効率化されてきました。それでも人の手に残っているのは、なぜでしょうか。
側原（homula）
決まった手順の中に「ちょっとした判断」が挟まっているからです。事務業務の約6割はこのタイプだと見ています。RPAでは「例外のときだけ人がやる」つもりが、例外かどうかの切り分けを人が張り付いて見ることになりがちです。外部への委託では、人が入れ替わるたびに品質が揺れて、業務のノウハウが社外に溜まっていきます。
「問うべきことは「答えを返せるか」から「任せた仕事が終わっているか」に変わりました。」
側原（homula）
03
homula は、AIのどこまでを扱っているのか
澤（Activated Trigger）
homula さんは、扱えるAIの幅が広いですね。自社の製品もあれば、ほかのツールも使いこなしています。全体像を教えてください。
側原（homula）
自社の製品としては agens を開発しています。あとで詳しくお話しします。それとは別に、n8n の導入支援をしています。n8n は公式のクリエイターとしてテンプレートも公開しています。
澤（Activated Trigger）
ほかにはどんな領域がありますか。
側原（homula）
社内のシステムとAIをつなぐMCPの活用支援があります。業務の知識をAIに持たせる Agent Skills の開発もしています。請求書などの書類を読むAI、音声で応対するAI、開発者向けのAIコーディングエージェントの導入も扱います。AIの利用にかかる費用を下げる設計や、AIに任せる範囲を決めるガバナンスの設計も、相談の多い領域です。
澤（Activated Trigger）
それだけ幅があると、どれを使うかの判断が大事になります。たとえば n8n と agens は、どう使い分けるのですか。
側原（homula）
n8n は、あらかじめ決めた流れを、きっかけに応じて繰り返すのに向いています。「このフォームに入力があったら、この表に書いて、この人に知らせる」といった、手順が決まっている業務です。agens は、ゴールを渡すとAIが自分で計画を立てて実行します。手順が毎回少しずつ違う業務や、途中で判断が要る業務に向いています。
澤（Activated Trigger）
どちらか一方、ということではないのですね。
側原（homula）
組み合わせます。決まった部分は決まった流れで正確に動かし、判断が要る箇所だけAIに考えさせる。その切り分けを業務ごとに設計するのが、私たちの仕事の中心です。使うAIのモデルも1社に決めていません。お客様の環境や社内の決まりに合わせて選びます。
澤（Activated Trigger）
1つの製品を売りたい会社だと、その製品に寄せた提案になりがちです。
側原（homula）
道具から入ると、たいていうまくいきません。業務を見てから、合うものを選びます。製造、金融、物流、製薬といった業界でご一緒してきたので、「この業務ならこの組み方」という引き出しは増えました。
homula が扱っている主な領域
- 自社の製品：AIエージェントの実行基盤「agens」
- 決まった流れの自動化：n8n の導入と、社内で作れるようにする支援
- 社内のシステムとの接続：MCP の活用支援
- 業務の知識をAIに持たせる：Agent Skills の開発
- 個別の業務：請求書などの書類を読むAI、音声で応対するAI
- 開発の現場：AIコーディングエージェントの導入
- 土台の設計：AIに任せる範囲を決めるガバナンスの設計、費用を下げる設計
04
agens は何をする基盤なのか
澤（Activated Trigger）
では agens について詳しく聞かせてください。ひとことで言うと、何をするものですか。
側原（homula）
会社の道具とアカウントをAIに安全に渡して、実務を最後までやらせるための基盤です。チャットで仕事を頼むと、AIが必要な道具を使って実行します。使い手に見える部分は4つあります。仕事を頼むAIエージェント、決まった流れを動かすAIワークフロー、業務用の画面をその場で作るAI LiveApp、数字を聞いて分析する Agentic BI です。
澤（Activated Trigger）
チャットのAIに「この作業をやって」と頼むのと、何が違うのでしょうか。
側原（homula）
違いは、その4つを下で支えている土台にあります。土台は4つの役割を持っています。仕事を完了までやり切らせること。会社の道具につなぐこと。隔離した環境で実行すること。組織として統制すること。この4つです。
澤（Activated Trigger）
1つずつ教えてください。まず「完了までやり切らせる」とは。
側原（homula）
AIエージェントは、考える、道具を使う、結果を見る、という動きを繰り返して仕事を進めます。放っておくと、同じことを延々と繰り返したり、費用を使いすぎたりします。agens では、繰り返しの回数、かける時間、使う費用に上限を持たせます。上限に達したら止まります。
澤（Activated Trigger）
止まったあとは、最初からやり直しですか。
側原（homula）
いいえ。進み具合を保存してから止まります。障害が起きたときも、再起動したときも同じです。止まった所から再開できます。自律型のAIでは、途中で止まる、失敗する、再開する、というのは当たり前に起きます。止まらずに走り切ることより、止まっても失わずに完了へ戻ってこられることを前提に作っています。
澤（Activated Trigger）
人に答えを返して終わるAIとは、作りの前提が違うのですね。
側原（homula）
そうです。対話型のAIは「答えを返して終わる」ことを前提に組まれています。業務を任せるAIは、数分から数時間かけて動きます。その間に何かが起きても、仕事を失わない作りが要ります。
05
請求書の処理を例に、agens の動きを追う
澤（Activated Trigger）
具体的な業務で、動きを追ってみたいです。さきほどの請求書の処理だと、どう動きますか。
側原（homula）
まず、届いた請求書を読み取ります。次に、発注の記録や取引先の登録と照らします。金額、数量、取引先が合っていれば、会計のシステムに登録する内容の下書きを作ります。ここまではAIが自分で進めます。
澤（Activated Trigger）
合わなかった場合は。
側原（homula）
そこで判断が分かれます。端数の処理の違いのように、決まりで説明がつくものは、決まりに沿って処理します。説明がつかないものは、AIが勝手に埋めません。処理を止めて、どこが合わないのかを添えて、担当の方に渡します。
澤（Activated Trigger）
登録や支払いの操作は、どの時点で行われますか。
側原（homula）
承認されたあとです。支払い、送信、登録のように外に影響が出る操作は、承認された分しか実行しません。誰がいつ承認して、いつ実行されたかは記録に残ります。
澤（Activated Trigger）
月末に「全部終わったのか」を確かめるのも、経理の方には負担です。
側原（homula）
そこは件数で確かめられるようにしています。処理が済んだ件数、確認中の件数、対象外にした件数を足すと、必ず最初に受け取った件数に一致します。一致しない限り「完了」とは言いません。二重払いや二重の登録は、注意ではなく仕組みで止めます。
澤（Activated Trigger）
事務の現場で怖いのは、遅いことよりも間違うことですからね。
側原（homula）
おっしゃるとおりです。速いだけの自動化は要りません。事故が起きない自動化を目指しています。
請求書の処理での、AIと人の分担
- AIが自分で進める：読み取り、発注の記録との照合、登録内容の下書き
- AIが止まって人に渡す：説明のつかない金額の違い、登録と合わない取引先
- 人が行う：例外の判断、登録や支払いの承認
- 仕組みが担う：二重の登録の防止、承認と実行の記録、件数の一致の確認
06
会社の道具を、安全に渡す
澤（Activated Trigger）
土台の2つ目の「会社の道具につなぐ」について。AIに社内のシステムを触らせることに、抵抗がある会社は多いです。
側原（homula）
そこがいちばん聞かれる所です。agens には、社内外のツールとつなぐ窓口があります。国内でよく使われている業務ソフトにもつながります。kintone、freee、マネーフォワード クラウド、SmartHR、クラウドサインなどです。
澤（Activated Trigger）
つなぐときの、パスワードや鍵の扱いはどうなっていますか。
側原（homula）
AIには、パスワードや鍵そのものを持たせません。接続の情報は基盤の側で管理します。AIは「この道具を使いたい」と頼むだけで、中身は見えません。請求書をダウンロードするために複数のサイトへログインする業務でも、パスワードを外部にもAIにも渡さずに動かせます。
澤（Activated Trigger）
3つ目の「隔離した環境」は、どういう意味ですか。
側原（homula）
AIがファイルを扱ったりプログラムを動かしたりする場所を、ほかから切り離しています。AIが想定外の動きをしても、影響がその中にとどまります。扱えるフォルダーやファイルの範囲も決められます。
澤（Activated Trigger）
情報システムの部門が心配する点を、先回りして潰してあるわけですね。
側原（homula）
企業のAI導入で最初の壁になるのは、技術よりも、セキュリティと社内の承認です。そこを通れない仕組みは、どれだけ賢くても使われません。
07
承認と記録で、任せられる範囲を広げる
澤（Activated Trigger）
土台の4つ目の「組織として統制する」について。日本の会社には、稟議や決裁の仕組みがあります。AIに業務を任せることと、どう両立させるのですか。
側原（homula）
AIが自分で実行してよい操作と、人の承認が要る操作の境目を、先に決めます。基本の考え方は「読み取りは自分で実行、書き込みは承認が必要」です。送信、更新、削除のような影響の大きい操作は、実行の前に人の確認を挟めます。
澤（Activated Trigger）
その決まりは、AIへの指示文に書いておくのですか。
側原（homula）
指示文には頼りません。指示文で伝えた決まりは、確率的にしか守られないからです。お金に関わる操作や、取り消せない操作の歯止めを、指示文だけにしてはいけないと考えています。agens では、承認が要るかどうかをプログラムの側で持ちます。AIの出力によって、その歯止めを迂回することはできません。
澤（Activated Trigger）
後から「何が起きたか」を確かめることはできますか。
側原（homula）
できます。誰が、いつ、何をAIにやらせたかを記録します。記録は後から書き換えられない形で残します。承認した人、対象、結果を一覧で見られます。操作できる範囲は、役割ごとの権限で分けます。
澤（Activated Trigger）
AIが誤ってファイルを消してしまった、というような事故には備えがありますか。
側原（homula）
2つあります。1つは、AIが消したファイルを30日以内なら元に戻せることです。もう1つは、異常な大量の操作を検知して、AIの操作を自動で止めることです。たとえば短い時間に大量の削除が続いたら、そこで止めます。
澤（Activated Trigger）
「間違えないAI」を目指すのではないのですね。
側原（homula）
AIは間違えることがある、という前提で設計しています。目指しているのは「怪しいときに必ず止まる」ことです。金額や宛先のように間違えてはいけない項目は、AIが確信を持てなければ処理を止めて人に渡します。勝手に推測して埋めることはしません。
「「間違えない」ではなく「怪しいときに必ず止まる」。それが私たちの品質の考え方です。」
側原（homula）
08
データの置き場所と、費用
澤（Activated Trigger）
「データを社外に出せない」という理由で、AIの導入を見送っている会社もあります。
側原（homula）
日本の会社がAIの導入でつまずく最大の壁は、機能よりもその制約だと感じています。agens は、クラウドで使う形のほかに、お客様の環境の中にすべてを置く形に対応しています。自社のサーバー、国内のクラウド、インターネットにつながない閉じたネットワークのどれでも動かせます。
澤（Activated Trigger）
AIのモデルはどうなりますか。外部のAIを呼ぶなら、結局データは外に出ますよね。
側原（homula）
モデルも選べます。お客様がすでに契約しているものをそのまま使えますし、社内で動かすモデルに切り替えることもできます。その構成なら、データを外に出さずにAIを動かせます。主要なモデルには一通り対応していて、切り替えは設定で済みます。特定の1社に縛られません。
澤（Activated Trigger）
費用の面はどうでしょう。AIを業務で大量に使うと、利用料が膨らむと聞きます。
側原（homula）
違いを生むのは、AIの単価よりも「AIに考えさせる回数」です。毎回AIに一から考えさせると、件数に比例して費用が増えます。決まった手順にできる部分は、手順として固定します。AIは、判断が要る所にだけ使います。そうすると費用が下がり、見通しも立ちます。
澤（Activated Trigger）
すべてを固定できるわけではないですよね。
側原（homula）
はい。ゼロにはなりません。固定できるのは、決まりにできる繰り返しの処理です。そこは正直にお伝えしています。
09
仕事をこなしながら、手順が会社に残る
澤（Activated Trigger）
agens を使い続けると、会社には何が残るのでしょうか。
側原（homula）
そこが、いちばん伝えたい所です。agens は、頼まれた仕事をこなしながら、その手順を残します。残る形は3つあります。繰り返し動かせるワークフロー、業務用の画面を持つアプリ、ほかの仕事にも使い回せるスキルです。
澤（Activated Trigger）
1回きりで終わらない、ということですね。
側原（homula）
最初はチャットで頼んだ仕事が、次からは決まった流れとして動きます。うまくいったやり方が、個人の頭の中ではなく会社の資産として溜まっていきます。担当の方が替わっても、業務は止まりません。
澤（Activated Trigger）
homula さんが支援に入った場合、納めるものは何になりますか。
側原（homula）
設計した内容が、そのままお客様の環境の設定として残ります。報告書を納めて終わり、にはしません。支援の成果が、そのまま動く仕組みになっている。そういう作りにしています。
澤（Activated Trigger）
コンサルティングの世界では、分厚い報告書を納めて、実行は別の会社、ということがよくあります。その継ぎ目で止まるプロジェクトを、何度も見てきました。
側原（homula）
作ることと、動かし続けることを分けないほうがよいと考えています。
10
それでも、プロジェクトを進める人が要る
澤（Activated Trigger）
ここまで聞くと、技術の面はかなりそろっています。それでも足りないものはありますか。
側原（homula）
あります。お客様の社内で、プロジェクトを前に進める役です。さきほどの「承認の境目を先に決める」が分かりやすい例です。どの操作に誰の承認を挟むかは、技術では決まりません。経理、現場、情報システム、法務、それぞれに言い分があります。それを整理して、合意を取って、期日までに決め切る人が必要です。
澤（Activated Trigger）
当社が紹介しているのは、まさにその役を担える人です。コンサルティングファームで、業務の整理や、部門をまたぐプロジェクトの進行を経験してきたコンサルタントです。
側原（homula）
具体的には、どんな動きをされるのですか。
澤（Activated Trigger）
最初にやるのは、業務の棚卸しです。いまの業務を書き出して、どこに時間がかかっているか、どこで例外が起きているかを数で押さえます。そのうえで、どの業務から始めるかの順番を決めます。効果が大きく、関係者が少なく、失敗しても影響が小さい業務から入るのが定石です。
側原（homula）
その順番づけは、私たちだけではやりにくい所です。お客様の社内の事情が分からないと決められません。
澤（Activated Trigger）
次に、成果を何で測るかを決めます。処理にかかる時間なのか、ミスの件数なのか、人が見直す割合なのか。始める前に決めておかないと、終わったあとに「効果があったのか」で揉めます。それから、会議の設計です。誰に、どの順で、何を決めてもらうか。経営に上げる資料も作ります。
側原（homula）
その経験がある方が入ると、進み方が明らかに違います。対象の業務の切り出しが早い。社内で揉めやすい論点を、先に片付けてくれる。私たちはAIの設計と実装に集中できます。
澤（Activated Trigger）
逆に、コンサルタントの側にも弱い所があります。業務の整理はできても、「いまのAIで、どこまで任せられるのか」の勘どころは、実際に作っている人にしか分かりません。できないことを前提に計画を組んでしまうと、あとで全部やり直しになります。そこを homula さんが持っている。
側原（homula）
お互いに足りない所が、ちょうど反対側にあるわけですね。
コンサルティングファーム出身のコンサルタントが担うこと
- 業務の棚卸し：いまの業務を書き出し、時間のかかる所と例外の起きる所を数で押さえる
- 順番づけ：効果・関係者の数・失敗したときの影響から、始める業務を決める
- 成果の測り方：始める前に、何の数字で効果を見るかを決める
- 合意づくり：承認の境目など、部門の間で意見が分かれる論点を整理して決め切る
- 経営への説明：投資の判断に要る資料を作り、進み具合を報告する
11
うまくいかない導入に、共通していること
澤（Activated Trigger）
うまくいかなかった導入には、共通点がありますか。当社に相談が来るのは、一度つまずいたあと、ということも多いです。
側原（homula）
大きく2つあります。1つは「試しただけで終わる」形です。小さく試して動いたのに、本番の業務に載せる段階で止まります。原因は、AIの精度よりも、止まったときの再開や、承認、記録といった、業務として成り立たせる仕組みが決まっていないことです。
澤（Activated Trigger）
もう1つは。
側原（homula）
「作った会社に頼り切りになる」形です。動いてはいるけれど、中身を分かっている人が社内にいない。少し業務が変わっただけで、また外に頼むことになります。
澤（Activated Trigger）
人の側から見ても、同じ2つが見えます。試しただけで終わる会社は、試す前に「何が確かめられたら次に進むか」を決めていません。頼り切りになる会社は、社内に担当を置かずに始めています。
側原（homula）
進め方の問題なのですね。
澤（Activated Trigger）
そうです。もう1つ加えると、最初から全社で始めようとする会社も苦労します。関係者が多すぎて、決めることが決まりません。
側原（homula）
私たちも同じ考えです。一気に全社へ広げるのではなく、段階的に進めるのが現実的です。まず1つの部門で運用の実績を作ります。経営、法務、情報システムの部門の信頼を得てから、ほかの部門へ広げます。
12
一緒に進めると、何が変わるのか
澤（Activated Trigger）
進め方としては、どう組むのがよいでしょうか。
側原（homula）
段階ごとに役割を分けるのがよいと思います。最初の整理の段階では、コンサルタントの方が業務の棚卸しと順番づけを進めます。その横で、私たちが実際のサンプルを使って動くものをお見せします。早い段階で「動くもの」と「進め方」の両方がそろうと、社内の合意が取りやすくなります。
澤（Activated Trigger）
作る段階ではどうですか。
側原（homula）
私たちが設計と実装を進めます。コンサルタントの方には、承認の境目や例外の扱いについて、社内の合意を取っていただきます。試しに動かす段階では、実際の業務と並べて走らせます。この間、業務は止めません。出てきた例外を一緒に見て、決まりを足していきます。
澤（Activated Trigger）
本番に入ったあとは、運用を社内に根づかせる仕事が残ります。
側原（homula）
そこは人の仕事が大きいです。私たちは「homula なしでは回らない」状態を目指していません。お客様のチームが自分で回せる状態まで持っていきたい。1つの部門で実績を作って、ほかの部門へ広げていく。その旗を振れる人が社内にいるかどうかで、広がる速さが変わります。
段階ごとの役割の分け方
- 整理する段階：コンサルタントが業務の棚卸しと順番づけ。homula が実際のサンプルで動くものを見せる
- 作る段階：homula が設計と実装。コンサルタントが承認の境目と例外の扱いの合意を取る
- 試す段階：実際の業務と並べて動かす。出てきた例外を両者で見て、決まりを足す
- 広げる段階：1つの部門の実績をもとに、コンサルタントが社内の展開を進める。homula は自分たちで回せる状態への移行を支える
澤（Activated Trigger）
AIの専門家と、プロジェクトを進める人。片方だけでも進みますが、両方がそろうと速さが変わります。同じ投資家の投資先どうしというご縁もあります。当社としても、AIの案件にはこの組み合わせで入っていきたいと考えています。
側原（homula）
私たちも、進め方に強い方と組めるのは心強いです。これからも一緒に進めていきましょう。
澤（Activated Trigger）
よろしくお願いします。
