🤖
「AIエージェント開発の裏側〜Algomatic社の実践知から学ぶ〜」 レポート
はじめに
2025年4月8日、「AIエージェント開発の裏側〜Algomatic社の実践知から学ぶ〜」というオンラインイベントが開催されました。 近年、LLM（大規模言語モデル）を活用したAIエージェントの取り組みが急速に増え、多くのエンジニアや企業が高い関心を寄せています。しかし、「具体的にどう開発を進め、どのように運用していくのか」については、まだ十分に情報が共有されていないのが現状です。 そこで本イベントでは、採用業務を代行するAIエージェント『リクルタAI』などを開発・運用する株式会社Algomaticの宮脇 峻平さん（@catshun_）をお招きし、“LLMを活用したAIエージェント開発の実践知”を余すところなく語っていただきました。
以下では、講演「AIエージェントの地上戦 〜Algomatic社に聞く開発計画と運用実践」で特に印象的だった内容をまとめてレポートします。参加者の熱量も高く、実際の現場で培われたリアルな知見に大いに刺激を受けたイベントとなりました。
第1章 イベントの概要
背景と目的
本イベントは、LLMを用いた対話システムや自動化、さらには複雑な業務の代行までを視野に入れた「AIエージェント」というテーマにフォーカスする場として企画されました。 AIエージェントにはさまざまな定義がありますが、最近注目を集めるのは「自律的に環境を観測し、行動を実行してタスクを完了させる」というモデルです。ここには、膨大な生成モデルの知識だけでなく、外部のリソース活用や高度な運用設計などが求められ、エンジニアにとってもチャレンジングな領域です。
Algomatic社では、実際に顧客の業務を代行する複数のAIエージェントを開発し、既に運用フェーズへと移行しています。今回は、その“地上戦”とも呼べる試行錯誤のプロセスを紐解き、「現場で何が起きているのか」を深く学ぶ貴重な機会となりました。
タイムテーブル
12:00〜12:03 オープニング・ご挨拶
12:03〜12:43 宮脇さんご講演「AIエージェントの地上戦 〜Algomatic社に聞く開発計画と運用実践」
12:43〜12:55 Q&A
12:55〜 クロージング
参加後のアンケート回答者を対象に、抽選で5名へのプレゼント企画（『やさしく学ぶLLMエージェント』）も実施され、大変盛り上がるイベントとなりました。
第2章 講演「AIエージェントの地上戦」──泥臭い試行錯誤と長期開発の必要性
2-1. エージェントとは何か、なぜ難しいのか
宮脇さんによると、AIエージェントは依然として言葉の定義がバラバラで、「チャットボット的なものからロボティクスまで、どれもエージェントと呼ばれがち」というのが現状だそうです。それゆえに、自社が目指すエージェント像を明確にしなければ、プロジェクトの方向性が曖昧になりやすいとのことでした。
Algomatic社では、採用業務を代行する「リクルタAI」をはじめ、フィールドセールスやインサイドセールスなど様々な業務をサポート・代行するAIエージェントを開発。いずれもチャットUIとLLMを組み合わせただけでなく、「環境を観測し、自律的にタスクを実行し、業務をまるっと任せられる」ことをゴールとしている点が特徴です。
2-2. 「地上戦」ゆえの複雑さ
AIエージェントにまつわる技術的なハードルは多岐にわたります。大きくまとめると、以下のような課題が浮かび上がるとのことです。
LLMの回答品質 文脈やドメイン知識に依存し、曖昧さが残りやすい。ハルシネーション（幻覚出力）のリスクも高い。
タスクの複雑さ ステップ数が増えるほど失敗確率が上昇し、全体のフローが途中で止まってしまう可能性がある。
社会的・倫理的な課題 出力が不適切であった場合の影響が大きく、ガードレール（不適切出力を防ぐ仕組み）や説明責任が求められる。
宮脇さんは「一つの大きな仕組みを作るというより、細かい技術課題を1つ1つ積み上げて解決していくようなイメージだ」と語り、これを“地上戦”と表現していました。
第3章 具体的な開発計画と運用実践
3-1. 小さな課題への丁寧な向き合い
AIエージェント開発では、一気にフルオートを目指すのではなく、「まずは人間が使う段階（アシスタントフェーズ）で業務価値を検証する」ことが重要だそうです。 具体的には以下のようなステップを提案していました。
ドメインエキスパート（現場の人）によるAI活用
まずはLLMや外部リソースをドメイン知識と結びつけながら試行
事業として本当に価値があるかどうかを判断
段階的に自動化レベルを引き上げる
部分的に人力が混ざるハイブリッド状態で運用しながら、徐々に全自動化へ近づく
このような段階的アプローチにより、リスクを制御しつつ早期に価値を届けることが狙いとのことです。
3-2. 改善サイクルの重要性
宮脇さんが繰り返し強調していたのは、インナーループ・ミドルループ・アウターループの3つのサイクルを回すことでした。
インナーループ モデル選択やプロンプト調整などを迅速に試し、ドメインエキスパートとペアリングして品質を上げる段階。
ミドルループ ステージング環境で安全性や動作の検証を行い、必要に応じてガードレールを強化する段階。
アウターループ 実際の運用データを踏まえ、長期的な改善やドメインそのものの変化に対応する段階。
特に「LLMをどう使うか」だけでなく、ガードレール設計やオブザーバビリティの確保といった運用面の工夫を丁寧に行うことが、実際に業務を代行できるレベルに仕上げる鍵だと語りました。
3-3. ガードレールで“予測不能”に備える
LLMはしばしば意図しない出力を行うため、危険なリクエストや誤った情報を出さない仕組み（ガードレール）が欠かせません。宮脇さんの話では、多重防御の観点で以下のような対策を講じているとのことです。
単語・構文・フォーマットのフィルタリング 表層的なチェックだけでなく、エージェントが生成する全てのテキストをモニタし、問題があればシャットダウンする。
LLMを使ったジャッジ（判定） 別のモデルに回答を評価させる仕組みを用い、不適切な出力を防ぐ。
リスク検証（レッドチーミング） 悪意ある攻撃やデータ改変を想定し、システムの脆弱性を洗い出す。
これらを運用段階でも常時モニタし、アラートが上がった場合は迅速に対応策を取る仕組みを整えることで、“万一”のリスクに備えているそうです。
おわりに
「次へ進むための地上戦」
Algomatic社でのAIエージェント開発は、想像以上に地道で細かな改善の連続でした。LLMの進歩によって「対話は劇的に賢く」なったように見えますが、実務で業務を代行させるには、ガードレールを丁寧に設計し、ドメインエキスパートと一緒に“試しながら作る”プロセスを重ねる必要があるのです。
さらに、人がどの段階で介入し、最終責任を持つかという設計も重要だと感じました。完全自動化を急ぐのではなく、段階的にレベルを上げ下げしながら信頼を積み重ねるアプローチこそが、“AIエージェントの地上戦”の真髄だと思います。
全体を踏まえた感想：「泥臭さこそがイノベーションの源」
今回のイベントを通じて改めて感じたのは、AIエージェント開発は決して魔法のように成立するものではないということです。LLMに頼りすぎると「思わぬ出力」に振り回されるリスクが残り、使い勝手や安全性を確保するには相応の“地上戦”が必須でした。 宮脇さんが語ったように、細かな技術課題を根気強く解決し、ドメインの専門家と対話を重ねながら、ガードレールや評価の仕組みを地道に整備していく。その蓄積があるからこそ、初めて「業務をまるっと任せられる」エージェントが生まれるのだと思います。
AI時代の到来で、私たちはLLMの新しさに目を奪われがちですが、実務に耐えるプロダクトをつくるためにはこの“泥臭い”プロセスこそが何よりも価値を生むのでしょう。Algomatic社の事例から学んだ運用設計やガードレールの考え方は、今後あらゆるAIエージェント開発の指針として大いに参考になるはずです。
次のステップとして、私たちもぜひ自社や個人のプロジェクトで、地上戦をいとわずに取り組んでみると、AIエージェントが具体的に業務を支え、社会に価値をもたらす未来を形にできるのではないでしょうか。
Yardでは、テック領域に特化したスポット相談サービスを提供しています。
興味がある方は、初回の無料スポット相談をお申し込みください。
また、資料請求やお問い合わせもお待ちしております。テック領域の知見を獲得し、事業成長を一緒に実現していきましょう。
Read next
Loading recommendations...