はじめに こんにちは、株式会社タイミーでプロダクトAIエンジニアとして働いている貝出です。直近は、タイミーの求人内容などのコンテンツモデレーションにLLMを利用した、システム開発や性能改善を行っています。 2026年3月9日（月）〜3月13日（金）に開催された「言語処理学会第32回年次大会（NLP2026）」に、今年は初めて現地参加しました。大会2日目は記録的な大雪に見舞われ、会場にたどり着くだけでひと苦労でしたが、それでも現地ならではの熱気は格別で、ポスター発表や他社エンジニアとの立ち話など、オンラインでは得られない学びが随所にありました。 NLP2026では多くの発表がありましたが、本記事ではLLMの評価・品質保証・安全性に関する発表に絞って紹介します。単に発表内容を紹介するだけでなく、実際のプロダクト開発や評価データ設計にどう接続できるかという観点で読み解きます。研究と実務をつなぐ視点として、評価設計やベンチマーク整備のヒントになれば幸いです。 大会2日目の大雪 言語処理学会年次大会について 会場内看板 anlp.jp 言語処理学会年次大会は 言語処理学会 が主催する学術会議であり、国内における言語処理の研究成果発表の場として最大規模のイベントです。 今年で第32回を迎え、発表件数は797件、最終日までの参加者数は2,316人と過去最大を記録しました。年々規模が拡大しており、NLP分野への関心の高さが伺えます。LLMの登場により一時は「研究することがなくなるのでは？」という懸念もあり、2023年には「 ChatGPTで自然言語処理は終わるのか 」というテーマでパネルディスカッションが行われたこともありました。しかしその懸念に反して、近年は「安全にLLMをどう使うか」「LLMの挙動をどう解釈するか」といった観点の研究が増えてきており、まだまだ研究題材は尽きない印象です。 なお、発表論文は言語処理学会のWebページで公開されているため、当日参加できなかった方でも閲覧可能です。 私自身も今回、社会人大学院での研究内容をもとに ポスター発表 を行いました。多くの方と議論でき、大変刺激になりました。合計90分間、ポスターの前で参加者に説明したり質問に答えたりと、途中で酸欠になりそうなほど白熱したセッションでしたが、ありがたいことにスポンサー賞としてレトリバ賞をいただくことができ、とても良い思い出になりました。 興味深かった発表 普段の業務では、「LLMを活用してビジネス課題をいかに解決するか」という問いと同時に、「LLMの出力をどう評価するか」「そのための評価データをどう設計するか」といった問題にも日々向き合っています。今回は、こうしたLLMの評価・品質保証・安全性というテーマを軸に、特に業務課題と関連の深かった4件の発表を取り上げます。 チュートリアル３：信頼できるAIへのソフトウェア工学からのアプローチ：「品質」技術の動向と課題 発表内容 本チュートリアルでは、ソフトウェア工学の観点から「信頼できるAI」の品質保証技術について解説されました。 まず、品質は「複数の特性から構成され、様々なニーズや要求を満たすこと」と定義されると説明されていました。また、品質には、対象システム自体に対して測るもの（例: レイテンシなど）と、実際にシステムを利用する段階で計測可能なもの（例: 顧客満足度など）の2種類が存在するとのことでしたした。そのうえで、価値やリスクはシステム全体で評価されるべきであり、AI部品ごとに適切に評価することの重要性が強調されていました。 AIの品質保証に関するガイドラインとしては、AIQMやQA4AIなどが紹介されました。これらのガイドラインでは、「AIパフォーマンス」「リスク回避性」「公平性」といった機械学習に特有の品質や、それを評価するための「被覆性（事例パターンが網羅的に含まれているか）」や「均一性（実際の母集団の分布に近いか）」などのデータセットにおける品質の重要性も整理されていました。 一方で、LLMの普及に伴い、入出力が非定型になってタスクの境界が曖昧になっています。また、正解が一意に決めづらくなったことで、評価・改善の難易度と工数が増大しているという現場課題も指摘されていました。LLMの手軽さからシステム開発自体は進めやすくなった反面、活動の重心は「開発」から「評価・改善」へと移行しています。しかし、「開発」と違って「評価・改善」では、工数換算をする意識が低くなりがちです。そのため、評価・改善の継続的サイクルを定着させることが困難だという課題が挙げられていました。 また、モデル評価の文脈としてソフトウェア工学における「自動テスト生成」の手法が紹介されました。代表的なものの一つが、テスト生成を最適化問題に帰着させてメタヒューリスティックに解く Search-Based Testing（探索的テスト） です。たとえば自動運転の分野では、この手法を用いることで事故が起きやすい弱点領域を探索したり、モデルの性能限界の境界を可視化したりすることが可能になっています。 最後に、言語モデルが今後ロボットや自動運転など物理世界にも応用されていく中で、よりリスクベースの評価が必要になるという展望が示されました。 感想 「開発」から「評価・改善」にエンジニアの工数の主なタスクが移り変わっているというところも、たしかになと思わずうなずいてしまいました。今後は「モデル開発」よりも、どう評価するか、どうデータセットを作るのかにML/AIエンジニアの重心が移るのかもしれません。 また、Search-Based Testingは初めて聞いたのですが、LLM審査のコンテキストに当てはめると、微妙な偽陽性・偽陰性を生む「境界線にある言い回し」を自動探索し、モデルやプロンプトの弱点を事前に洗い出す、といった使い方ができそうだと感じました。 [ B2-1 ] chakoshi Fine: 多層防御に基づくLLM向けガードレールの設計と実装および評価 発表内容 本研究は、生成AIの安全な業務利用のためのガードレール構築に関するものです。前年のNLP2025で発表された chakoshi の発展系にあたります。 chakoshi では単一モデルに複数の役割を担わせていたため、あるリスクの検知精度を伸ばそうとすると別の精度が低下しやすいという構造的な制約が課題でした。本研究ではこの課題に対し、リスクごとに特化した5つの独立した防御機構を段階的かつ選択的に適用する多層アーキテクチャ chakoshi Fine を提案しています。複数のコンポーネントに分割したパイプライン構造にすることで、単一モデルでの全体最適化を避け、各ポリシーが専門性を高めつつ相互に弱点を補完する設計になっています。この結果、既存の商用ガードレールサービスと比較して高い検知精度を達成していました。 さらに、擬似業務タスクを通じて実際の業務を想定した有用性評価も行われています。ガードレール導入の有無が人間のタスク正答率や平均所要時間に統計的な差を与えなかったという結果が示されており、過剰検知によるユーザー体験の悪化や業務効率の低下を防ぎつつ、パスワード漏洩のような不正な入出力に対しては、98%の確率で遮断できていました。 感想 ガードレールを利用する際は、どうしても使用感が気になります。本研究が、検知精度だけでなく処理速度や「ユーザー体験を損なわないか」という点まで踏み込んで評価してくれているのは、実務側としてありがたいです。また、4B程度の軽量なLLMでもガードレールのスコープによっては、ある程度検知精度が担保できるという点も個人的には発見でした。 [ Q4-3 ] LegalRikai: Open Benchmark - 法務ドメインの日本語ベンチマーク 発表内容 本研究は、実際の法務業務のワークフローを模した、法務ドメインにおける新たな日本語ベンチマーク LegalRikai を提案しています。 このデータセットは、弁護士の監修のもとで人手による精緻なアノテーションが行われており、高コストではあるものの高品質な内容となっています。法令改正の要約や指示に基づく契約書編集など、実際の法務業務を模した4つの複雑なタスクから構成されており、法務文書特有の長文インプットに対して構造化された出力を求める設計になっています。 評価においては、単一の指標ではなく、指示の遵守度・契約書全体の構造の一貫性・不要な変更の有無など、実務に即した複数の観点から評価する尺度が採用されています。正解データの作成から評価に至るまで専門家が深く関与しているため、データ数は各タスク25件と少数ながら厳選された内容です。さらに、評価者間の一致度（Cohen の κ スコア）を計測することで、アノテーションの妥当性やガイドラインの信頼性を担保しており、LLMの法務実務における実力を正確に測るための堅牢な基盤を提供しています。データセットは公開されており、論文内のリンクから参照可能です。 感想 「専門ドメインのベンチマークをどう設計するか」という観点で非常に参考になる研究でした。特に、評価観点を実務の複数軸に分解している設計や、少数でも質を担保するためにアノテーターの一致度を計測している点は、評価データを整備する際にも応用できそうです。「データ数は少なくても、専門家による厳密な設計で品質を担保する」というアプローチは、社内の評価データ構築においても積極的に取り入れたい考え方です。 [ B8-13 ] 医療系対話AIにおける評価基準の策定と自動評価手法の比較検証 発表内容 本研究は、日本の医療事情に即した独自の評価データセットを構築し、医療系対話AIにおける「LLM-as-a-Judge」を用いた3つの自動評価手法を比較検証したものです。具体的には以下の3手法が比較されました。 総合評点方式 ：詳細なガイドラインに基づき1〜10点でスコア化 総合評点方式（簡易版） ：評価の観点のみを提示 項目別評価方式（チェックリスト形式） ：具体的な評価項目に対してTrue/False判定を行い加重スコア化 実験の結果、モデル間の全体的な性能差を識別する能力においては、意外にも詳細な指示を与えない「総合評点方式（簡易版）」が最も優れていることが分かりました。一方で、個別の会話に対する評価の「一貫性」や、医学的に危険な回答を確実に除外するといった「説明可能性・安全性」の観点では、「項目別評価方式」が最も優れていることが示されています。目的（モデル全体の性能比較か、個別回答の厳密な品質保証か）に応じて適切な評価アプローチを使い分ける重要性が裏付けられた研究です。 感想 「簡易版のほうがモデル間の性能差を検出しやすい」という結果は、直感に反していて面白かったです。評価指標によっては、どの形式の評価にするかを実施前に比較しておくといいのかもしれません。 「項目別評価のルーブリック設計には専門家のコストがかかる」という点は、スポンサーブースで他社のエンジニアと話していたときにも、全く同じ悩みとして挙がっていました。「評価の精度を上げたいが、設計コストをどこまでかけられるか」というトレードオフは、ドメインを問わず共通の課題なのだと改めて実感しました。スモールスタートする場合は「まず簡易版で全体傾向を把握し、問題が疑われる領域だけ項目別で深掘りする」という使い分けが現実的かもしれません。 おわりに 今回取り上げた4つの発表は、主に評価、評価データ、そして安全性に関するものでした。LLMの能力が飛躍的に向上した今、「人間の期待通りに生成できているのか」「安全にLLMを利用できているのか」という問いへの関心はますます高まっており、研究も着実に進んでいる印象です。 NLP2026では今回紹介しきれなかった魅力的な研究も数多くあり、この領域の裾野の広がりを実感しました。タイミーを安心・安全なプラットフォームとして維持するためのLLM活用について、多くの示唆を持ち帰ることができた大会でした。 We’re hiring! 現在、タイミーでは、データサイエンスやエンジニアリングの分野で、共に成長し、革新を推し進めてくれる新たなチームメンバーを積極的に探しています！ product-recruit.timee.co.jp また、気軽な雰囲気での カジュアル面談 も随時行っておりますので、ぜひお気軽にエントリーしてください。↓ hrmos.co hrmos.co hrmos.co

本記事は、2026年1月12日に公開された ” Building Intelligent Network Operations Agent with Amazon Bedrock AgentCore ” を翻訳したものです。 深夜2時、バージニア北部 リージョン にてお客様のトランザクション処理が失敗したというアラートが、あなたのスマートフォンに届きました。Amazon Web Services (AWS)上で画像処理プラットフォームを管理するネットワーク運用者のあなたは、複雑なアーキテクチャのトラブルシューティングを迫られます。このネットワークは、複数の Amazon Virtual Private Cloud (Amazon VPC) が AWS Transit Gateway で相互接続されており、その上で多数のマイクロサービスが実行されています。根本原因の可能性は多岐にわたり、セキュリティグループの設定ミスからNetwork Access Control List (NACL) の問題、 AWS Network Firewall ルールが正当なトラフィックをブロックしているかもしれません。このようなシナリオは現在のクラウド環境においてますます一般的になっており、複雑なネットワークトポロジが復旧時間を長引かせる要因となっています。 今日のAWSユーザーが運用する環境は、複数のAWSリージョンにわたる数百ものVPCを含むことが珍しくありません。それぞれのVPCには独自のセキュリティ設定、Network Firewallポリシー、Transit Gatewayを介した複雑なルーティングが組み込まれています。接続障害が発生すると、運用チームは通常、 VPCフローログ 、 Amazon CloudWatch メトリクス、 AWS Reachability Analyzer の検出結果、アプリケーションログなど、膨大なデータソースを横断して調査しなければなりません。その結果、トラブルシューティングが長期化し、解決に向けたアプローチも担当者によってばらつきがちです。本記事では、 Amazon Bedrock AgentCore のAI機能をAWSのネットワーキングサービスと統合し、高度なネットワーク運用エージェントを構築する方法を解説します。セキュリティや運用水準を満たしながら、診断と修復を自動化する手法を探ります。 エージェントの構成要素 レゴブロックを組み合わせて複雑な構造を作るのと同様に、エージェントベースのソリューションも複数のモジュール化されたコンポーネントを組み合わせて構築されます。各モジュールには特定の役割があり、それらを適切に組み合わせることで、組織のニーズに合わせて適応・拡張できる、堅牢で柔軟なネットワーク運用システムが構築されます。図1に、このようなエージェントに必要な構成要素を示します。 図1: ネットワーク運用エージェントの構成要素 Interface＆Integration ブロックは、ユーザーとシステムを繋ぐ主要な接点として機能します。自然言語処理やマルチモーダル入力をサポートすると同時に、AWSサービスとのシームレスな連携を可能にします。具体的には、自然言語のクエリを構造化コマンドに変換し、 AWS SDKによる直接的なAPI連携 、 AWS Lambda 統合、 モデルコンテキストプロトコル(MCP)サーバーベースの統合 機能を介してサービス間接続を管理します。 Security＆Operations ブロックは、 Amazon Bedrock AgentCore Identity 、 AWS Identity and Access Management (IAM) ロール、 Prompt Engineering 、 Amazon Bedrock AgentCore Policies を用いて包括的な保護を実装します。同時に、 Amazon CloudWatch を通じて、モニタリング、アラート、自動修復を管理します。このブロックは、安全な運用とプロアクティブな問題検出を保証します。認証と認可からコンテンツフィルタリング、監査ログに至るまで、多層的なセキュリティコントロールを実装することで機能します。 Intelligence ブロックは、 Amazon Nova 、 Claude Sonnet 4 、 Llama などの 基盤モデル(FM) を利用した認知エンジンとして機能します。これには、高度なChain-of-Thought(思考の連鎖)プロンプティングと ReAct(Reason+Act)機能が組み込まれています。このブロックは、複雑なネットワーク運用に求められる、中核となる推論や意思決定能力を提供するために必要です。大規模言語モデル(LLM)機能とプランニング・コンポーネントを組み合わせ、短期的な運用のコンテキストと長期的に学習されたパターンの両方を維持しながら、複雑なタスクを管理可能なステップにまで細分化することができます。 Orchestration ブロックは、 Strands 、 LangGraph 、 CrewAI などのフレームワークを用いて、ワークフロー実行を調整し、異なるコンポーネント間の相互接続を管理します。このコンポーネントにより、複雑な多段ステップの処理を可能にしながら、様々なコンポーネント間をスムーズに連携できます。複数のエージェントが連携する必要がある場合は、タスクの分解、並列処理、エージェント間通信を管理することで実現します。 Memory ブロックは、エージェントの作業メモリとして機能し、短期的なセッションのコンテキストと、長期的に学習されたパターンの両方を保持します。これは、パーソナライズされ、かつ状況をくみ取った対話を実現するために必要です。 Agent Core Memory を利用した短期的・長期的なメモリ戦略を使い分けることで、複数のセッションにわたって関連する文脈を維持しながら、会話履歴やユーザーの好みを保存できます。これらの機能は、十分な情報に基づいた意思決定と、個々のユーザーに最適化された対話を行うために極めて重要です。 Deployment ブロックは、AgentCoreランタイムを介することで、組織のニーズに最適な実装アプローチを選択できます。フルマネージド型のインフラストラクチャや、カスタム実装ができる柔軟な基盤を提供します。 Evaluation ブロックは、パフォーマンスを評価するためのAI駆動型テスト フレームワーク を提供します。このブロックは内部的にLLMエージェント( evaluator) を実装しており、独自のエージェント( target) との会話をオーケストレーションして会話中の応答を評価します。このブロックは、様々なシナリオをシミュレートし、エージェントの応答を期待値と比較することで、品質を維持し、一貫した動作を保証します。 これらのビルティングブロックは、それぞれが独立しながらも、相互に連携できるように設計されています。まずは基本のブロックから始めて不可欠な機能を構築し、ニーズの拡大に合わせてより高度な要素を追加していくことが可能です。実装を成功させる鍵は、単に適切なブロックを揃えることだけではなく、それらをいかに組み合わせるかにあります。モジュールを選択・統合する際は、組織固有のニーズ、技術力、そして将来の成長計画を考慮して下さい。まずは最も差し迫った課題を解決するために必要最小限の要素から着手し、チームがシステムに慣れるにつれて、段階的に高度なモジュールを追加していくのが良いでしょう。重要なのは、各モジュール間のインターフェースをクリーンに保ちつつ、それらがシームレスに連携できるようにすることです。 ネットワーク運用エージェントの実装：理論から実践へ 本セクションでは、これまで述べてきた理論上の構成要素が、実際のシナリオを通じてどのように具体的な実装へ落とし込まれるかを説明します。対象シナリオは、図2に示す通り、バージニア北部リージョンでホストされている画像処理アプリケーションに影響を及ぼす、重大なネットワーク接続障害のトラブルシューティングです。 ExampleCorp の画像処理アプリケーション 図2: ExampleCorpの画像処理アプリケーション Amazon Route 53がDNSリクエストを処理します。画像処理アプリケーションのフロントエンドには、Application Load Balancer(ALB)を介してアクセスします。ALBは、バックエンドアプリケーションとして機能するサーバーレスのLambda関数にトラフィックを分散します。 Lambda関数は、ユーザーのリクエストに基づいてS3バケットから画像を取得し、レンダリングを行います。サーバーレスなアーキテクチャのため、手動によるスケーリングなしで、並列の画像レンダリング処理が可能です。 専用のDBサブネットに配置されたAmazon RDSには、利用データやプラットフォーム分析結果が保存されます。このデータベースは、プラットフォーム全体で画像がどのようにアクセスされ、利用されているかを追跡します。 レポートサーバーは、利用レポートやパフォーマンスメトリクスを生成します。適切なサブネットを経由したルーティングによりRDS内データに安全にアクセスし、基幹業務に影響を与えることなくプラットフォーム分析を行います。 ネットワーク構成にはVPC による分離を採用し、アプリケーションコンポーネントとレポートコンポーネントを切り離しています。AWS Transit GatewayがVPC 間のセキュアな通信を可能にし、専用サブネット(App、Reporting、DB)によって各サービス間に明確なセキュリティ境界を確立しています。 Amazon Bedrock AgentCore Runtimeによるトラブルシューティングの自動化 ワークフローは、図3に示す以下のステップに従います。 図3: Amazon Bedrock AgentCoreベースのアプローチ チャットクライアントはAmazon Cognito を介して認証され、ユーザーはJWTトークンを添えて質問を送信します。 AgentCoreランタイムはトークンを検証し、Claude 4.0 Sonnetモデルを活用して会話を処理します。 AgentCore Gatewayは、MCPプロトコルを通じてツールへの安全なアクセスを提供します。 AWS Lambda Targetは、適切な認証のもとでAWSサービスの操作を実行します。 AgentCore Identityは、ワークロードの認証とトークン交換を担います。 AgentCore Observabilityは、包括的なモニタリング、メトリクス、およびログ記録機能を提供します。 Amazon AgentCoreを使用したネットワーク接続トラブルシューティングのユースケースを実装するための詳細なデプロイ手順は、 sample-building-network-ops-agent-with-amazon-bedrock-agentcore にて公開されています。 まとめ Amazon Bedrockを搭載したインテリジェントなネットワーク運用エージェントの導入は、クラウドインフラストラクチャ管理への革新的なアプローチであり、大きなビジネス価値をもたらします。平均復旧時間 (MTTR)を数時間から数分に短縮し、24時間365日体制の自律診断を可能にすることで、運用コストを抑えつつビジネスを継続できます。 モジュール式のビルディングブロックを実装することで、組織がいかにAIを活用してネットワーク運用とインシデント解決を効率化できるかを示しました。これらのエージェントはAWSサービスと統合されており、Claude Sonnet 4などのFMを使用して複雑なネットワークシナリオを理解して診断を自動化し、堅牢なセキュリティ制御を維持しつつ状況に応じた推奨事項を提供します。 しかし、AIエージェントが常に最適なソリューションであるとは限りません。AIエージェントは、文脈の理解や自然言語での対話を必要とするような、複雑で多段階な操作には優れていますが、より日常的な運用タスクには従来のサーバーレスAPIベースのシステムの方が適している場合があります。例えば、セキュリティグループの定期的な更新や明確な入出力を持つスケジュールされたバックアップ操作は、直接のAPI呼び出しにより効率的に処理できるため、エージェントインフラストラクチャを使う場合のオーバーヘッドを回避できます。高度なトラブルシューティングシナリオにはエージェントを使用し、日常的な運用にはサーバーレス機能を維持するといったハイブリッドアプローチを採用することが、多くの組織の成功に繋がっています。 AIの機能は進化を続けていますが、導入を成功させるためには現実の状況に合わせる必要があります。まずはエージェントの機能が真に活かせる、具体的で価値の高いユースケースから始め、運用ニーズや複雑さに応じて段階的に拡張して下さい。このようなバランスの取れたアプローチを取ることで、組織はより回復力のある効率的なネットワーク運用を構築でき、チームはビジネス価値を高める戦略的な取り組みに集中できるようになります。 準備はいいですか？ 次にできることは以下の通りです： Amazon Bedrock AgentCore のドキュメント を確認する AWS GitHub リポジトリ でユースケースをチェックする Amazon Bedrock AgentCore や Strands Agents のワークショップで実践的に学ぶ （訳者注：リンク先システムの仕様が変更されています。 Builder Center のWorkshopsメニューより、キーワード検索にてご利用ください） 翻訳はSolutions Architectの田中が担当しました。原文は こちら です。

記事を開いていただきありがとうございます。 今回は「遊び方を教えてくれるAIチャットボット開発」をテーマに「用例」と「システム構成」を簡単にご紹介させていただきます。 開発したAIチャットボットの紹介 ワンピースカードゲームでは、お客様に向けてルールを公開していましたが、網羅的にルールを記載しているため、お客様が確認したいルールを探すのが難しいという状況でした。 今回のチャットボットではRAGという仕組みを使い、AIチャットボットがユーザーからの入力に合せて適切にルールを回答するということを実現しました。 例えば、ワンピースカードゲームには「起動メイン」という効果があるのですが、自然