GMOペパボ株式会社

シンプルな構成で支える、ウェブサイト生成エージェントの品質評価ループ

ロリポップ！AIサイトエージェント
「カフェのサイトを作りたい」などの要望を起点に、チャットでヒアリングを行い、最短10分で公開可能なウェブサイトを自動生成するエージェントです。
https://lolipop.jp/ai/site-agent/

アーキテクチャを選択した背景や意図

ウェブサイト制作のフローは、「ヒアリング → 構成設計 → デザイン選定 → コンテンツ生成」というステップに分解できると判断しました。そこで中核のサイト生成処理は決定論的なワークフローで組み、AIの出力に応じた分岐は要所のみに限定する設計を採っています。定型化できる処理はワークフローで固定し、エージェントに任せる範囲を絞ることで、デバッグと運用の安定性を確保する狙いです。チャットUIと公開サイトはともに Next.js、非同期ワークフローは BullMQ、サイト構成データ(JSON)とAIの入出力ログは MySQL に保存します。

本番運用時の苦労や悩み・工夫した点

最大の運用課題は、ウェブサイトの「良し悪し」を一意に判定できないことでした。LLM 呼び出しが成功して JSON が返っても、その品質が本当にユーザーへ渡せるかは自動テストでは判定できません。出発点として採用したのは、デザイナーによるヒューリスティック評価です。実際に生成されたサイトを目で見てコメント化し、改善要件として開発側へフィードバックするループを回しています。もう一つ工夫した点は、評価対象へのアクセス導線の整備です。改善サイクルの起点は「成果物をすぐ見られること」だと考え、ワークフロー各ステップの入出力ログと最終成果物をすべて MySQL に保持し、リードレプリカ経由で Metabase から社内で参照できるようにしました。最初から本格的なデータウェアハウスを構えず、シンプルな構成で初手の運用負荷を抑えています。評価/改善プロセスの解像度が上がった段階で、適切なデータ基盤への移行を進める想定です。

現在のアーキテクチャの課題と今後の改善予定

直近の改善計画は三段階で考えています。
1つ目はデザイナーの知見とユーザーフィードバックを統合した評価軸の明文化で、デザイナー以外のメンバーでもサイト品質を判定できる状態を目指します。
2つ目は、明文化された評価軸を機械的な処理と LLM-as-a-Judge に展開する自動評価の整備です。
3つ目は、評価結果を入力としてコーディングエージェントが構成JSONやコンテンツを自動修正する、改善ループの自動化です。

◆執筆：西田貴之 @kinosuke01（GMOペパボ株式会社 ロリポップ・ムームードメイン事業部 エンジニアリングリード）

グリーホールディングス株式会社

人間と協働する社内問い合わせ対応AIエージェントの構築と継続的改善

情シス問い合わせ対応Slack Bot「イルカちゃん🐬」
情報システム部宛のSlackでの問い合わせに対し、社内ドキュメントや過去のQAを参照して自動で一次対応を行うAIエージェントです。状況に応じて人間へのエスカレーションを行うほか、SaaS障害検知に特化した別エージェントと連携し、最新のシステム障害情報を加味した高精度な回答を提供します。

アーキテクチャを選択した背景や意図

システムはCloud Run上で「頭脳にあたるAPI」と「Slackからのリクエストを処理するBot（BFF）」の2つに分割して構築しました。APIを疎結合にすることで、高い拡張性と他システムとの柔軟な連携を実現しています。
検索基盤にはVertex AI Searchを採用しました。社内に散在するデータをBigQueryへ集約するデータパイプラインを構築し、データの種別ごとにインデックスを作成しています。これにより、検索対象とする情報源をAIエージェントが指定できるようになっています。

本番運用時の苦労や悩み・工夫した点

最も苦労したのは、既存の安定した問い合わせ対応プロセスを壊さずに「人間とAIの協働」を実現することでした。検証用チャンネルでのテストや夜間のみの稼働から段階的に導入し、人間の担当者が対応を開始した際にはAIが自動で沈黙する機能を取り入れることで、人間へのスムーズな引き継ぎを可能にしました。
また、運用後に 「有益な回答が半数程度しかできていない」という品質の課題 に直面したため、GeminiとBigQueryを用いた「LLM as a Judge」による日次の定量評価基盤を構築しました。ログ分析の結果、検索クエリの粒度に問題があることが判明し、プロンプトで「SaaS製品名などの固有名詞を優先的に抽出する」よう指示を強化し精度改善に繋げています。
AIに親しみやすいキャラクター（ペルソナ）を付与することで、ユーザーの心理的ハードルを下げ、AIの不完全さを許容してもらえるような雰囲気を作るなど、ソフト面での工夫も行いました。

現在のアーキテクチャの課題と今後の改善予定

現在の課題としては、まだ全幅の信頼を置けるほど賢くはないということ、またそれ故、PCのキッティングやライセンスの払い出しといった実際の作業を任せることができないという点があります。
これについては、社内の暗黙知のようなものを上手く与えることができれば解決するかもしれないと考えています。
そこで、人間の対応を前提としないデータ蓄積用のオープンベータ的な「サンドボックスチャンネル」を設置して評価・改善サイクルをさらに加速させたり、AI用に蒸留された軽量で網羅的な社内ナレッジデータベースIrminsul(仮)を確立し、エージェントが閲覧可能にしたりといった施策を進めています。

各施策の詳細や最新の取り組みについては、情報システム部ブログでも発信しています。こちらも是非ご覧ください！
グリーホールディングス株式会社 情報システム部ブログ（note）：https://note.com/gree_it

◆執筆：菅原 優（グリーホールディングス株式会社 情報システム部 AI活用推進チーム エンジニア）

KDDIアジャイル開発センター株式会社

社内ヘルプデスクAIエージェントの運用 ─ マルチエージェントによるコスト最適化と、AI自動評価による品質保証

社内ヘルプデスクAIエージェント「AIこーぽたん」
社内 Confluence にはドキュメントが膨大に蓄積されており、必要な情報を探し当てるのに時間がかかるため、コーポレート部門に問い合わせて確認するケースが頻発していました。この問い合わせ負荷を軽減するために開発したのが「AIこーぽたん」です。Slack から Confluence を自律検索し、休暇申請方法、出張費上限などの情報と参照 URL を返すコーポレート向け AI エージェントで、Slack 上で動作するためやり取り自体が社内の情報共有にもつながります。

アーキテクチャを選択した背景や意図

開発初期は MCP × エージェントを手早く試すため、Mastra でローカル環境から Confluence 検索を試していました。
デプロイ段階で、社内稟議が通しやすく検証を早く開始できる AWS を選択しました。同時期に Amazon Bedrock AgentCore がプレビュー公開され、Gateway や Memory 周辺機能まで揃っていた点で採用し、フレームワークも親和性の高い Strands Agents へ Mastra から乗り換えました。
PoC では単一エージェント構成で Slack から動作する形まで実装しました。

本番運用時の苦労や悩み・工夫した点

本番運用で主に取り組んだのはコストと品質の2軸です。
コスト面では、利用拡大に伴うモデル呼び出しコストの急増を受け、単一モデルで全処理を完結させる構成は持続可能でないと判断しました。そこで、統括役 Orchestrator（Claude Sonnet 4.5）の配下に「Confluence 検索」「Slack 整形」を担う Specialist 2体（Nova 2 Lite）を分割配置し、定型タスクを安価なモデルに委譲するオーケストレーション型マルチエージェント構成へ切り替えました。これにより、品質を保ったまま約55％のコスト削減を実現しています。
品質面では、モデル差し替えやプロンプト変更のたびに目視で Confluence と突き合わせるのが限界となり、Strands Agents Evals SDK で AI に採点させる評価基盤を構築しました。あらかじめ用意した 10〜15 問のテストセットを変更前後で採点し、平均スコアの増減で品質変化を判定します。1 問ごとの採点には多少のブレがあるものの、平均値で見れば全体傾向が安定して読み取れるため、新しいモデルやプロンプトを採用すべきかの見極めを、これまでより大幅に早く決断できるようになりました。

現在のアーキテクチャの課題と今後の改善予定

今後の改善として、有識者の補足回答の再利用に取り組む予定です。Confluence にない情報をスレッドで補足してくれる運用が自然発生しているため、この返信を正解データとして蓄積し、次回以降の回答や評価セットへ活用する仕組みを検討しています。AgentCore Memory の活用も併せて評価する予定です。あわせて、情報不足時にエージェント側から追加情報を求める「逆質問」機能も検討しています。

◆執筆：佐藤明智 @AKITOMO_N4M（KDDIアジャイル開発センター株式会社 ソフトウェアエンジニア）

KINTOテクノロジーズ株式会社

Azure・Go・Langfuse で構築するマルチエージェント型の社内 AI チャット基盤

マルチエージェント型の社内 AI チャット基盤
ブラウザと Slack Assistant API の 2 経路から使える社内 AI チャット基盤です。Anthropic Claude、Azure OpenAI、Vertex AI Gemini に対応し、MCP 経由の社内外サービス連携と、画像生成やコード実行などの自前ツールを備えています。メインエージェントと複数のサブエージェントが役割を分担しています。

アーキテクチャを選択した背景や意図

もともとは LLM プロバイダー対応や ReAct ループも含めて自前で実装していましたが、保守と拡張が重くなり eino (Go 製の AI エージェント基盤) に移行しました。1 つのエージェントに全ツールを集約していたところ、MCP 連携が増えるにつれてシステムプロンプトが圧迫されてきました。Anthropic の Tool Search Tool を参考に BM25 ベースのツール検索を自作した時期もあります。現在は eino の DeepAgents (メインエージェントが計画しサブエージェントに委譲する仕組み) を採用し、ツールをサブエージェントに分散して構造的に解決しています。
eino は既存のバックエンドと同じ Go で書かれており、ワークフロー、ツール統合、MCP 統合といった必要機能が揃っていたため選びました。観測基盤には、社内でセルフホスト運用でき、eino の公式拡張で連携できる Langfuse を採用しています。

本番運用時の苦労や悩み・工夫した点

ツールをサブエージェントに分散しても、単純な質問でツール呼び出しが過剰化して応答遅延やコスト増を招くケースが残りました。成功データが集まっていてもエージェントが「情報は十分」と判断できる材料が乏しく、似た情報を別ソースから取り続けてしまう状態でした。対策として、Anthropic の think tool パターンを参考に、ツール結果を踏まえて次の手を判断する内省用ツールを各サブエージェントに組み込み、失敗時はエラー内容を判別できる構造化 JSON で返す設計にしています。

現在のアーキテクチャの課題と今後の改善予定

これらの対策が効いているかは Langfuse で観測しています。トレース、コスト、トークン消費に加え、過剰呼び出しの再発や内省用ツールの発動頻度を確認しています。一方でエージェント挙動の品質は数値だけで測りにくく、今後は Langfuse のスコアとアノテーション機能を活用し、利用者目線の評価を改善ループに組み込みます。

◆執筆：鳥居 雄仁 @yu_torii（KINTOテクノロジーズ株式会社 KINTO開発部 共通サービス開発G / コーポレートIT部 AIファーストG Senior Web/AI Application Engineer）

株式会社LayerX

Ai Workforce における AIエージェント本番運用を支えるオブザーバビリティの取り組み

エンタープライズ向けAIプラットフォーム 「Ai Workforce」
LayerXの「Ai Workforce」は、文書を中心に回るエンタープライズ業務へAIを組み込むためのプラットフォームです。契約書、提案書、審査資料、社内ナレッジなどを探す、読み解く、確認する、加工する、所定の形式へ反映するといった作業をAIで支援します。

アーキテクチャを選択した背景や意図

Ai Workforceでは、あらかじめ手順が定義されたワークフローと、実行時の状況に応じて処理の進み方が変わるAgentic Workflowの両方を扱っています。Agentic Workflowでは、同じ入口から開始しても、途中で選ばれるツール、参照する情報、判断の順番が実行ごとに変化します。そのため、HTTP statusや通常のアプリケーションログだけでは、AIエージェントがどのように判断し、どこで時間やコストが発生し、どの処理で問題が起きたのかを十分に把握できません。
この課題に対し、Ai WorkforceではWebアプリケーションとしての観測と、AIワークフローとしての観測を接続する設計を採用しています。OpenTelemetryをベースに、APIリクエストから非同期処理までtrace contextを引き継ぎ、Datadog LLM Observabilityへワークフロー、エージェント、タスク、ツール、LLM呼び出しをspanとして送信しています。これにより、APM、Logs、MetricsとLLM Observabilityを同じ基盤上で確認でき、インフラやWebアプリケーションの状態から、AI エージェント内部の処理までを一貫して追跡できます。

本番運用時の苦労や悩み・工夫した点

本番運用では、APIとしては成功していても、参照すべき文書の見落とし、不要なツール呼び出し、LLM呼び出しのレイテンシ増加、token消費やコスト増加といった問題が発生し得ます。以前は複数のログを突き合わせて時系列を復元していましたが、現在はtraceを起点に確認範囲を絞り込めるようになりました。一方で、顧客データには機密情報が含まれるため、入力、出力、ツール引数・結果は送信しない、またはマスキングし、実行構造、処理時間、エラー種別、モデル名、token数などのメタデータを中心に観測しています。

現在のアーキテクチャの課題と今後の改善予定

今後は、traceから得られるメタデータや傾向をもとに問題ケースを検出し、検証環境や評価データセットで再現・評価できる形へつなげていく予定です。運用メトリクスだけでなく、AI品質も継続的に確認できる状態を目指しています。

◆執筆：石田 健太（株式会社LayerX Ai Workforce事業部 開発部 SRE）

株式会社ログラス

本番運用でのチューニングを前提としたAIエージェント設定ポイント

財務分析AIエージェント
ログラスが提供している財務分析AIエージェントは、顧客の財務データを中心とした経営のコンテキスト情報を踏まえて、経営企画の方が日頃の業務で解決したい疑問に素早く回答を行うプロダクトです。

アーキテクチャを選択した背景や意図

本サービスはお客様のクラウド環境にデプロイすることを前提としており、セキュリティ・立ち上げのスピード・運用のしやすさを最優先に技術選定を進めています。アプリケーション層は権限分離と短時間デプロイが両立でき、運用負荷の小さいECS Fargateで統一しました。
当初はAIエージェントが出力するアウトプットに特に制約を設けず、ユーザーからのプロンプトをLLMに自由度高く解釈させて各種データソースへアクセスさせ、出力結果を生成させる方針でした。しかし解釈の余地が広すぎ、同じプロンプトでも結果が大きく変わったり、SQL発行に失敗するなど精度面で大きな課題が顕在化しました。

そこで本AIエージェントが想定する主要なユースケースを決定論的なワークフローとして定義し、各ワークフローを構成する処理ステップをLLMが解決する、決定論と非決定論の組み合わせパターンを採用することで精度を担保しました。各ノードを作り込んでいくにはLangGraphが最も適しており、これを基盤に選定しています。
定性データの検索層にはChromaDBを採用していますが、専用ベクトルDBの有効性検証を兼ねた選定であり、コンテナとして自社運用しやすく、お客様環境にもそのまま持ち込める点を重視しました。LLM呼び出しはAWS Bedrock経由に統一し、機微なプロンプトやコンテキストがお客様VPCの外へ抜けない構成としています。観測基盤にはLangfuseをECS上にセルフホストし、ノード単位のトレースや評価もお客様環境内で完結させています。

本番運用時の苦労や悩み・工夫した点

大きく2つあります。
1つ目はワークフローを複数ステップに分け、複数ノードから成るグラフ構造としたことで、各ノード出力のバリデーションをどう設計するかという視点です。
最終アウトプットは予実分析コメントで、その内容の真偽や十分性を検証した上でユーザーに提示する必要があります。各ノード内で個別に検証する案もありましたが、最終アウトプットに対して検証を行うバリデーション用ノードをグラフ末尾に設けました。
①どのノードまで差し戻したかをデバッグ時に可視化しやすい、②ノードの責務を分離しバリデーションロジックの散逸を防げる、というのが理由です。

2つ目はLLMにSQLを作らせる際に与える情報の設計です。当初はメタデータを付けずにRDBスキーマを読ませSQLを組み立てさせていましたが、存在しないカラムを使いエラーが頻発しました。
各テーブル・カラムにComment情報として格納内容や想定する分析ユースケースを記載したところ、SQL組み立て精度が大きく向上しました。

現在のアーキテクチャの課題と今後の改善予定

LLMのモデル性能とコンテキストウィンドウが向上するにつれ、決定論的ワークフローではなくよりLLMに自由に解釈させられる幅が広がるため、非決定論的な処理に任せる領域をいかに増やせるかという視点でアーキテクチャ全体を継続的に見直すことが、より高品質なアウトプット実現には必要だと感じています。

◆執筆：山崎 倫太郎 @zakky_dimn（株式会社ログラス AIソリューション事業本部 FDE）

NCDC株式会社

Strands Agents と LiteLLM で実現する、柔軟で拡張可能なAIエージェント

BizAIgent

「BizAIgent（ビズエージェント）」は企業向けの業務支援AIアシスタントです。社内ナレッジや業務システムと MCP 経由で連携し、チャット形式でリサーチ・要約・各種業務タスクを遂行します。 https://ncdc.co.jp/service/enterprise-ai-assistant/

アーキテクチャを選択した背景や意図

AIエージェントのコアな部分にAWS製のOSSであるStrands Agentsを採用しました。当初はLangGraphで構築していましたが、ノードと状態管理が肥大化し、機能追加時の保守性の確保や拡張性が課題となりました。そこでStrands Agentsへ移行しエージェントのループ管理をライブラリに委ねました。これによりAgent Skillsなどの新しい概念の機能も安全に素早く取り入れることができました。一方でAWSへのロックインを避けるため、モデル呼び出しはLiteLLMで抽象化しています。これにより、機能とインフラ基盤の両軸で拡張性を確保しています。

本番運用時の苦労や悩み・工夫した点

2層構成のエージェントを採用し、メインエージェントは最終回答の生成に集中する一方、ツール実行はサブエージェントに委譲しています。サブエージェントはクエリの複雑度に応じて軽量モデルに動的に切り替えることで、品質とコストを両立させています。チャット型なので素早く応答を返す必要があるため、サブエージェントには実行時間の上限を設け、上限到達時は収集済み情報をもとに部分回答を返す設計としました。加えて、コンテナのステートレス化、ツール実行進捗のリアルタイム通知、プロンプトキャッシュなど、品質・観測性・コストを支える工夫を多層的に組み込んでいます。

現在のアーキテクチャの課題と今後の改善予定

AIエージェントの製品開発における最大の課題は、そもそもが新しい領域である為どのような機能が顧客の真の価値をもたらすのか、開発者側も顧客側も手探り状態にあることだと感じています。だからこそ、機能を素早く試し不要であれば捨てるを繰り返すことで改善し続ける必要があると考えています。

◆執筆：茨木啓太 @ibaraki_1234（NCDC株式会社 テクノロジーディレクター）

Sansan株式会社

お客様のデータと向き合うAIエージェントで「説明性」をどう担保するか

Sansan AI エージェント

Sansan AI エージェントは、Sansan が整備する企業・組織情報と、お客様が当社サービスに登録・蓄積するデータ、およびお客様が自社で扱う営業情報を掛け合わせ、営業・マーケティング業務を支援する。

アーキテクチャを選択した背景や意図

アーキテクチャの原則は「車輪の再発明をせず、提供価値に集中する」こと。
ここに直結する部分のみ独自実装し、他はマネージドで構成した。
データ層は BigQuery、AI モデルは Gemini を中心に Google Cloud エコシステムを前提とし、エージェント実行基盤はコンテナベース。
Agent Platform Runtime にも期待したが UX が届かないと判断。
セッション・メモリはマネージド、観測性は OpenTelemetry ベース。
また、お客様のセキュリティチェック時に根拠を持って説明できるよう、LLM 処理・セッション情報・テレメトリーなどの粒度でデータと処理の所在を整理し、種別ごとに説明できる構成にしている。

本番運用時の苦労や悩み・工夫した点

説明性（Explainability）
Sansan AI エージェントは、上述の通り Sansan およびお客様のデータを掛け合わせて回答する。
ゆえに応答の「なぜか」を示せるかは品質に直結し、説明性がゆらぐとお客様はサービスを使わなくなる。
我々の想定するお客様は営業部門主導が多く、お客様のデータは加工・キュレーション済みが中心。
ただしこれらのデータには品質のばらつきを含むことがあり、そのままでは安定した説明性を担保することは難しい。
そのため我々はFDE (Forward Deployed Engineer) がデータ品質補正のためのモデリング、エージェントのカスタマイズを重ねて品質を担保している。
この営みを完全に AI に置き換えるのは現状難しく、汎用的な処理だけで一定の品質を提供し続けるのは届かない領域がある。

現在のアーキテクチャの課題と今後の改善予定

前述の説明性を支える FDE の知見をスケーラブルにすることが課題である。
FDE が担うデータ連携・プロンプト調整・AI 改善のフィードバックをナレッジ・アセット化し、AI で代替できる部分を広げる。
データの特性上完全な自動化を目指すのではなく、Human-in-the-Loop ベースで人が介在する範囲を継続的に狭めていく方向で進めている。

◆執筆：中根 洋平（Sansan株式会社 技術本部 CTO室 AI Solution Development）

株式会社TOKIUM

AI経費承認で見えた精度とコストを両立する設計

AI経費承認

TOKIUMはAI経費承認というプロダクトで、経費精算の承認プロセスをAIエージェントで自動化しています。OCRで経費データを読み取り、承認ルールに照らして判定します。

アーキテクチャを選択した背景や意図

LLMを用いた本番運用をしていく中で、LLMで判定させるべきデータとプログラムで判定させるべきデータがあることが分かり、図のようなアーキテクチャになりました。その判断に至った経緯を本記事で共有します。

本番運用時の苦労や悩み・工夫した点

本番運用を開始して初期のころは、精度の壁にぶつかりました。AIエージェントは入力・中間判断・出力が絡むため、判定が想定と異なるケースで原因特定が難しい領域です。我々は初期からAIの入出力と紐づく顧客データが観測できるよう、DatadogのAPMで入出力をトレースする仕組みを実現しました。
問題に遭遇しても、「該当トレースを一本読む作業」に変わり、検証サイクルを大幅に高速化できました。

精度の壁を乗り越えた後、顕在化したのがLLM APIのコストの壁です。全てをLLMに委ねると処理件数に比例してコストが膨らみます。「初期はLLMで素早く価値を出し、知見が溜まったらコードベースのロジックに切り替える」のが我々の戦略です。LLMには文脈解釈や例外判断に集中させ、定型処理はコードに寄せることで、精度とコストを両立しています。

観測可能性による検証サイクルの高速化と、LLMとロジックの双方の特性を理解し、解決したい課題に合わせて適切に組み合わせて利用することが、AIエージェント本番運用の鍵です。

現在のアーキテクチャの課題と今後の改善予定

現在のAI経費承認は、扱える経費種別や承認パターンの範囲を広げていくフェーズにあります。経費精算は企業ごとに承認ルールや特性が大きく異なるため、より多様なケースに対応できるドメイン知識の整備と、それを支えるアーキテクチャの拡張が次の課題です。経理担当者の承認・差戻しといった日々の判断を自然に蓄積し、プロダクトの改善ループに組み込めるように設計していきます。

◆執筆：東優太（株式会社TOKIUM プロダクト本部 横断チーム統括部 ）、村瀬晃（株式会社TOKIUM プロダクト本部 経費精算製品開発部）