AIエージェント時代の権限管理が、いまアツい
こんにちは。LayerXで「Ai Workforce」というプロダクトのプロダクトマネージャーをしているinaoです。 Ai Workforceは、組織の中でAI Agentを活用するためのプラットフォームです。 getaiworkforce.com おかげさまで、我々の組織もお客様もユースケースも拡大を続けていて、AI Agentとその周辺機能を日々企画・開発しています。そのなかで、最近とくに議論が長引くテーマがあります。 権限管理です。 社内Slackで権限の話を始めると、毎回スレッドが伸びます。私もさまざまな方と意見交換するたびに新しい視点が得られ、とても面白い領域だと感じています。（そういう意味で、社内的にいまアツい、です） 視点が増え、論点が分岐し、さらにスレッドが伸びる。なぜこんなに難しいのか。そして、なぜ「いま」これを考える意味があるのか。この記事では、権限管理を 過去（これまでの前提）／現在（各社の動向と現場の論点）／未来（向かう先） の時間軸で整理してみたいと思います。 最初にお断りしておくと、Ai Workforceは「さまざまな業務を支援・遂行するためのAI Agentプラットフォーム」という位置づけです。そのため本稿も、特定の理想形に絞らず、「さまざま」を扱うための権限管理について、雑多に考えを広げています。その前提で読んでいただけると幸いです。 なぜ権限管理がエージェントの肝になるのか 個人のAIと組織のAI 組織の中にAIを配置し、安全かつ効率的に運用する。人とAIがコラボレーションする。そう考えたとき、設計の肝になるのは「どの権限を、誰に、どこまで、どうやって渡すか」です。 ここが決まらないと、エージェントは安心して仕事を任せられる同僚にはなれません。逆に縛りすぎれば、できることが少なく、柔軟性の低いものになってしまいます。 面白いのは、議論すると人によって意見が様々であることです。理由はおそらく2つあります。 想定しているユースケースは人によって違う。 個人の生産性ツールとしてAIを使う文脈と、組織の共通リソースとして業務を自動化する文脈とでは、最適な権限のかたちはまるで変わります。 個人利用のClaudeやChatGPTに求められることと、組織の中のAgentに求められることも違ってきます。 権限への立ち位置が違う。 業務を設計する人と、業務で扱うリソースを設計する人とでは、「⚪︎⚪︎権限」に対するスタンスが異なります。 しかも、いまだ世の中に存在しないもので、人間にはとてもわかりづらい権限について想像しながら話しているため、人によって思い描く理想像もずれていきます。この課題を完全に解消できるかは怪しいですが、整理することで、議論の足場くらいは作れるはずです。 過去：主に人間を中心に設計されてきた権限管理 これまでのソフトウェアの権限管理は、システム間の連携のようなアクセス制御やルールもありますが、概ね一貫して「人間」を中心に設計されてきました。代表的なものを並べてみます。 RBAC（Role-Based Access Control）：アクセスの主体は人間のユーザーで、権限をロールやグループに束ねる。 ABAC（Attribute-Based Access Control）：主体（ユーザー／システム）に加えて、対象リソースの属性とポリシーでアクセス可否を決める。 ACL（アクセスコントロールリスト）：「誰が見られる／編集できる」をフォルダ・ファイル単位で管理する（Google Drive、SharePoint、Boxなど）。 認可（OAuthなど）：アプリがユーザーの代わりに何かするとき、フローを通じて「ユーザーの許可」をもらいアクセストークンを取得する。リソース側からは、ユーザー本人の行動かアプリの行動かをほぼ区別できない。 これらの世界には、共通する暗黙の前提がありました。 行為者は人間か、または人間の意図を忠実に転送するだけのプログラムである。 ボタンを押したのは人であり、アプリはその意図を運んでいるに過ぎない。だから「誰がやったか」は実質的にユーザー本人と等しく、監査ログにユーザー情報が紐づけば十分。 つまり、意図の出どころは常に人間という点です。 現在：エージェントは「自律的な行為者」になった エージェントによって、何が変わったのでしょうか。 一言でいえば、意図を「転送」するのではなく、文脈から意図やアクションを「生成」するようになったことだと考えています。 人間が「この資料をまとめて」と頼むと、エージェントはどの情報を参照し、どう判断し、どんな成果物を作り、どのアクションを実行するかを、自分で決めていきます。たった一回のクリックの後ろで、数十の判断とアクションが連鎖する。ここで、従来の前提が静かに崩れ始めます。 課題1：主体をユーザーのままにすると、「誰がやったか」区別がつかない リソース側（内部データや外部システム）は、「ユーザー本人が操作したのか」「エージェントが自律的に動いたのか」を見分けられません。監査ログ上は同じに見えるため、事故が起きたときに「誰が」やったのかを後から辿れなくなります。 また、ユーザーの権限を継承してエージェントが情報にアクセスしてしまうと、情報セキュリティ上に外部に送ってはいけない情報が外部システムとしてのエージェントに渡されてしまったり、エージェントを通してさらに外に送信されてしまうおそれがあります。 課題2：エージェント固有の権限で動かすと、「できること」がブラックボックス化する エージェントにサービスアカウントを与えてその権限で動かすと、ユーザーの権限とエージェントの権限が乖離します。それで良い場面もありますが、ユーザー本人には許されないことを、エージェント経由で実行できてしまう、ということも起こりえます。 エージェントからアクセスできる範囲やできることがユーザーから見て分かりづらくなってしまったり、ガバナンスが適切に効かせられているかどうか分かりづらくなってしまうかもしれません。 課題3：人への依頼と、エージェントへの依頼は「責任の所在」が違う 「AさんがBさんに作業を依頼する」のと、「AさんがエージェントA′に依頼する」のは違います。Bさんには本人の判断と責任がありますが、エージェントA′が何をどこまでできるのかを、Aさんが正確に把握しているとは限りません。把握できていないことが、トラブルや業務の停滞につながりかねません。 各社のプロダクトはどう設計しているか エンタープライズ向けにAIエージェントを提供する各社も、同じ課題に向き合っているはずです。公開情報をもとにざっくり調べたところ（※すぐ触れる環境がなかったため厳密さは欠きます）、大きく2つに分かれそうでした。 実行ユーザーの権限を継承するタイプ 例：SalesforceのAgentforceのEmployee Agent。 エージェント自体に独立した権限モデルを持たず、実行ユーザーの権限をベースに動く。基本的にはユーザーに許可を求める仕組み。 エージェントを第一級のアイデンティティとして扱うタイプ 例：Google Cloudの「Agent Identity」、Microsoftの「Entra Agent ID」「Agent 365」。 エージェントそのものに身元と権限を持たせる。 どちらが良いではなく、それぞれの体験、汎用性を踏まえて設計されているように見えます。 また、各社のプロダクト以外にも、OAuthやMCPを中心に標準化の動向や議論もあるようです。（ここは話が広がりすぎるので、また別の機会に） いま現場で起きている論点 世の中の動きと同じことが、社内でも論点として立ち上がってきます。 （以下はあくまで社内で出ている論点の一例で、権限管理の一般的な論点を網羅したものではないのでご注意ください） 1. 代行か、依頼か 1つ目は、エージェントが「誰の権限で」「どこまで自分で判断して」動くかという軸です。業務の任せ方には2種類あります。 業務の代行：自分の仕事をそのまま肩代わりしてもらう。エージェントは裁量を持たず、ユーザーの権限の範囲で動く。例：「自分の提案書を仕上げてほしい」 業務の依頼：任された側にも裁量がある。エージェント自身の権限と判断で動く。例：「組織内の情報整理を定期的に行ってほしい」 例えば、「エージェントは自分の権限で動いてくれた方がアクセス範囲やできることが明確」である、という意見もありますし、一方で「誰が実行しても同じ結果が得られるようにエージェントごとに権限が管理が理想」という意見もあります。 ユースケースによってどちらも妥当そうに見えます。どちらをやるにしても一つのプロダクトの中でどう表現し、どう実現できるのか、はまだぼんやりしています。 なお、代行だからといって「ユーザーの全権限をそのままエージェントに渡してよい」わけではありません。本人なら許される操作でも、エージェント経由だと意図しない結果になることがあります（機密情報や受領資料を外部に送信してしまったら、目も当てられません）。代行であっても「どの権限を、どの操作に限って貸すか」の絞り込みは必要です。 2. そのエージェントは「誰のもの」か 2つ目は、論点1とは別の軸で、**そのエージェントが「誰に紐づくアイデンティティなのか」**という話です。 個人に紐づくエージェント：自分の業務のために使うエージェント。誰に許可を取ればよいかが明確で、説明責任もその人に集約されるため、シンプルで安心しやすい。一方で、異動や退職のたびに引き継ぎが発生します。 組織に紐づくエージェント（脱属人化）：チーム全体に向けて働く、共通リソースとしてのエージェント。特定個人がいなくなっても残せますが、「誰が責任を持ち、誰が許可を出すのか」を明確にする必要がある。 1つ目の代行・依頼と、この2つ目の誰のものか、は2軸として独立しているかもしれないと考えています。「代行か依頼か（権限の出どころ）」と「個人か組織か（アイデンティティの所在）」は、同じ話に見えますが、たとえば組織に属するエージェントが、実行時には指示者の権限を借りて代行するといった組み合わせも成り立ちます。混同せず別々の話として設計したほうが、選べる形が広がりそうです。 3. リソースをどう安全に分けて扱うか 3つ目は、エージェントが触れるリソースの範囲をどう引くかです。 エージェントを特定のプロジェクト資料やアクションに限定すると、安全性は高まりますが、その範囲でしか動けず、汎用性や、応用力は下がります。 一方で、プロジェクトを横断・俯瞰したい場面も当然あります。 目的によってエージェントが触れる範囲を限定したくなります。 リソース範囲ごとにエージェントをそれぞれ用意する形になるかもしれませんし、用途に応じたスコープを柔軟に構成できると良いのかもしれません。また、用途に応じたエージェントを実行できる主体も異なる形にする必要があるかもしれません。 これらはどれも「最終的には全部必要」という話に着地するかもしれません。 さまざまなユースケースをカバーしたい我々のようなプロダクトでは、汎用性とカスタマイズ性を両立しながら、作り手もユーザーも安心・安全に使いこなせる権限モデルを確立する必要があると考えています。 未来？：権限管理はどこへ向かうのか 足元の課題を解くのはもちろんですが、もう少し先を妄想してみたいと思います。 権限は「リソースの列挙」から「意図・条件の記述」へ 「どのファイル」「どのフォルダ」と一つずつ指定するのではなく、「機密区分が高くないもの」「この案件に関するもの」のように、条件や意味で権限を切り分ける 方向に進むかもしれません。エージェントは大量かつ多様なリソースを必要とするため、人間が一つずつACLを設定する運用はいずれ破綻してしまいそうです。クエリのようなスコープや、属性ベースのポリシーが中心になっていくのではないでしょうか。 権限は連鎖し、その連鎖は検証可能になる 人→エージェント→別のエージェント→外部API、というように多段の依頼や権限委譲が当たり前になりつつあります。各ホップでトークンが渡され、最終的に「誰の意図で、どのエージェントが、何をしたか」を正確に辿れる状態が求められます。複雑な流れであってもアカウンタビリティが保てること自体が、権限設計の要件になっていくはずです。 エージェントは「管理されるアイデンティティ」になる 人が会社に入社・退社する際、アカウント発行、PCセットアップ、アカウント削除、PCリセットといった手続きがあります。同じように、エージェントにも作成・更新・廃棄のライフサイクルが必要になりそうです。「いま組織にどんなエージェントがいて、何ができ、最後にいつ何をしたか」を把握できる状態が、ガバナンスの前提になっていくでしょう。 組織の中で働くエージェントが本当の意味で安心・安全になるには、さまざまな工夫が必要であると思います。 さいごに ここまで、権限管理を「過去／現在／未来」の時間軸で整理してきました。 いまこの論点を考える意味は、エージェントが便利な新機能ではなく、組織の中で意思決定とアクションを連続的に生み出す「新しい行為者」になりつつあるからだと思っています。だからこそ、単に強い／弱い権限を付けるのではなく、次の3つをプロダクトと運用の両面で設計していく必要があります。 誰のために動いたのか どの範囲まで委ねたのか 何をしたのかを、後から説明できるのか 完璧な解はまだ見えていません。それでも、Ai Workforceなりの、「さまざま」な業務に耐える権限モデルを探っていきたいと思います。 さいごのさいごに Ai Workforceでは、プロダクトマネージャーやエンジニアを募集しています。 ご興味のある方は、ぜひカジュアル面談からお気軽にご応募ください！ jobs.layerx.co.jp
- 生成AI
- セキュリティ
- ガバナンス
AIに全力投資するLayerXでインターンしたら、実装が早すぎて設計の重要性に気づいた話
※本記事は、2026年5月までLayerXのAi Workforce事業部でSWEインターンとして活躍してくれたkawachan（かわちゃん）さんによる執筆です。本人のインターン期間終了に伴い、LayerX の koichi（こいち）が代理で投稿いたします。最先端のAI協業の現場で得られたリアルな学びを、ぜひご覧ください！ はじめに こんにちは、kawachan（かわちゃん）です。昨年の12月から、LayerXのAi Workforce事業部SWE（Software Engineer）チームでインターンをしています。 この記事では、Ai Workforce事業部への応募を検討されている方や、当事業部に興味をお持ちの方に向けて、私たちがどのようにAIを活用し、協業しながら開発を進めているのか、インターン生としての実体験を交えてご紹介します。 私の業務内容 当事業部では、FDE（Forward Deployment Engineer）やプロダクトチームのメンバーから寄せられた意見や要望が、チケットとして起票されます。 インターン生もそのチケットの中から主体的に案件を担当し、設計、実装、テストまで一気通貫で行います。私は主に、Ai Workforceの既存機能の改善や、新バージョンに向けた新規機能の開発を担当させていただきました。 AIとの協業体制 Ai Workforce事業部SWEチームでは、AIを単なる補助ツールとしてではなく、強力な開発パートナーとして位置づけています。ここでは、具体的な取り組みをいくつか紹介し、チームの魅力をお伝えします。 1. 圧倒的なAIコーディングツールへの投資 LayerXでは「Bet AI」の行動指針の通り、CursorやClaude Codeといった最新のAIコーディングツールへの投資を惜しみません。私自身、週2日の勤務であるにもかかわらず、潤沢なAI利用環境を提供していただき、その投資の大きさに驚きました。 開発現場では、AIと壁打ちをしながら案件のドメイン知識を高速にキャッチアップし、まずはプロトタイプ（叩き台）を作成してチームへ共有します。認識のズレがあればその場で即座に修正していく、という高速なサイクルが確立されています。 これによりリリース速度が飛躍的に向上し、FDEを介してお客様のフィードバックが迅速に開発チームに届くため、さらなる改善へとつながる非常に良いサイクルが生まれています。AIを用いた高速な実装力は、これからの時代の必須スキルだと身をもって実感しました。 2. AIの活用を前提としたコーディング環境（rulesの運用） AIにただコードを書かせると、チームのコーディング規約や設計方針を無視した実装になりがちで、結果としてレビュワーの負担が増えてしまいます。 この課題に対し、当事業部ではコードのドメイン知識や共通ルールをrulesというディレクトリに集約しています。AIの活用をはじめから前提として開発環境を整備している点が非常に合理的です。 AIは常にこのrulesを参照するため、チームの共通認識に沿った納得感のある実装方針を出力してくれます。また、開発メンバーは誰でも自由にrulesへ知見を追加・更新できるため、AIは常に最新のコンテキストに基づいた精度の高いコーディングを行ってくれます。 3. プルリクエスト（PR）の自動レビュー 開発の中で特に興味深かったのが、GitHubとGreptileやDevinなどのAIツールを連携させた、プルリクエストの自動レビューの仕組みです。 タスクによっては修正が500行を超える大規模なものもあり、人間によるレビュー負担が大きい場合がありました。そのような際、まずはAIが網羅的にレビューを行って細かなバグや規約の課題を潰します。これにより、人間のレビュワーはドメインロジックの妥当性やアーキテクチャの議論など、より本質的なレビューに集中できるようになりました。 4. QAガイドおよびStory Testの自動生成 開発フローは、チケット起票 → 実装 → QA（品質保証）メンバーによる検証 → 本番リリース、という順で進みます。 私が参画して1ヶ月ほど経った頃、QAメンバーに提出するための「QAガイド」をAIが自動生成する機能が導入されました。 これにより、開発者のドキュメント作成負担やQAメンバーの確認コストが軽減されただけでなく、開発者が「QAメンバーがどのような観点で検証を行っているのか」をより深く理解するきっかけになりました。結果として開発とQAの距離が縮まり、気軽に相談し合える文化がさらに強固になっています。AIには、部署間のギャップを埋め、チームの心理的距離を近づける効果もあるのだと実感しました。 インターンを通じて得た2つの大きな学び 1. 「どう作るか」より「何を作るか」の重要性 インターンを通じて最も強く感じたのは、開発現場において「これは本当に必要な機能なのか？」という本質的な議論が、技術的な実装方針の相談よりも圧倒的に多いことです。 AIの進化により、機能を作るコストは劇的に下がりました。だからこそ、「なぜ作るのか」「誰が求めているのか」「今本当に作るべきか」を深く熟考する重要性が増しています。 最近担当したタスクでも、まさにこのことを実感する出来事がありました。あるワークフロー作成機能において、「DSL（ドメイン固有言語）で定義するオブジェクト型のデフォルト値に対し、バリデーション（入力チェック）を強化する」という要件がありました。 しかし、SWEチームの社員の方々と相談し、実際の顧客のユースケースを深く検討する中で、「エラーを出してユーザーに修正を促す（バリデーションの強化）」よりも、「システム側でデフォルト値を自動補完する」方が、顧客の真の課題解決に繋がるのではないか、という議論に発展しました。 このように、言われたものをそのまま作るのではなく、「何を作り、何を解決したいのか」をチーム全体で常に問い直しています。ただがむしゃらにコードを量産するだけでは、使われない機能が増え、プロダクトの認知負荷やメンテナンスコストを高めるだけになってしまいます。FDEやビジネスサイドのメンバーと密に連携し、顧客の真の課題を捉え続けることが、今後のSWEにとって最も重要な役割になると確信しました。 2. 「AI前提の開発」における設計の難しさと、エンジニアの新しい役割 LayerXは日本でもトップクラスにAIを活用している企業ですが、それでも「AI前提の開発」は発展途上であり、新たな課題も見えてきました。 実装スピードが加速した分、設計が疎かになると技術負債が蓄積する速度も比例して早くなります。私自身、数週間前に実装した機能が開発のスピード感に追いつけず、すぐに負債化してしまう経験をしました。 AIが負債を残さず、いつでも切り離しや変更が容易なコードを書くためには、どのような設計やアーキテクチャが必要になるのでしょうか。従来のDDD（ドメイン駆動設計）などに代わる、AI時代に適した新しいアーキテクチャパターンが、今後このチームの試行錯誤の中から生まれていくのではないかとワクワクしています！ おわりに LayerXのAi Workforce事業部は、AIの可能性を最大限に引き出し、これまでにないスピード感で社会に価値を届けている非常にエキサイティングな組織です。 「AIが普及していく社会で、エンジニアとしてどう生き残るべきか」という不安を抱えている学生の皆さんにこそ、ぜひこの最先端の開発環境を体験していただきたいです。LayerXでのSWEインターンへの挑戦を、心からおすすめします。
- 生成AI
- ソフトウェア設計
- GitHub
- 生産性向上
マルチモーダル知識グラフ「RAG-Anything」を用いた複雑な実世界ドキュメントの理解
※本記事は、2026年5月までLayerXのAi Workforce事業部でR&Dインターンとして活躍してくれた kemotoさんによる執筆です。本人のインターン期間終了に伴い、LayerX の koichi（こいち）が代理で投稿いたします。最先端のAI協業の現場で得られたリアルな学びを、ぜひご覧ください！ -- こんにちは。LayerX AiWorkforce 事業部 R&D チームでインターンしております竹本（@kemotohuman）です。 当事業部では、エンタープライズのお客さま向けに『Ai Workforce』というプロダクトを提供しています。Ai Workforce では、エンタープライズの業務に用いる複雑なドキュメントを「AIの力でいかに正確に処理・分析するか」というテーマに日々向き合っています。 しかし、実務で扱われるドキュメントの解析は一筋縄ではいきません。複雑なグラフや図表、緻密なレイアウトが施されたPDF資料を最新のAIに読み込ませ、「この内容を正確に分析してほしい」と依頼したとき、期待外れの回答にガッカリした経験はないでしょうか。現在のLLM（大規模言語モデル）技術は飛躍的に進化しましたが、依然として「実世界のドキュメント」を真に理解しているとは言い難いのが現状です。 今回は、このような課題を解決するために提案されたフレームワーク「RAG-Anything」について、そのアプローチと仕組み、そして実務への応用可能性を解説します。 元論文：https://arxiv.org/abs/2510.12323 GitHub：https://github.com/hkuds/rag-anything 一般的な情報抽出が抱える課題 複雑なビジネスドキュメントからAIを用いて情報を抽出する際、従来の一般的なシステム（テキストベースのRAGなど）では、主に3つの構造的な壁に直面します。 1. 視覚的・マルチモーダルな情報の欠落 一般的にドキュメントをAIに処理させる場合、まずは一度「テキストデータに変換（文字起こし）」してからLLMに入力するアプローチが広く使われています。しかし、この方法ではグラフの推移やフロー図のように、「視覚的な理解が必要な要素」から情報を正確に抽出することが極めて困難になります。 テキストデータへの変換が情報抽出に悪影響を及ぼす例 ページ全体をそのまま画像としてマルチモーダルLLMに入力するという手段もありますが、レイアウトが緻密で複雑なドキュメントほどノイズが増えてしまい、ピンポイントでの情報抽出において精度が出ないというジレンマを抱えています。 2. 散在する情報や多段階推論への弱さ 回答の根拠となる記述がドキュメント内の1箇所にまとまっていれば良いのですが、根拠が複数かつ離れたページに散在している場合、一般的なアプローチでは抽出の難易度が急激に上がります。 ドキュメント全体の内容を俯瞰し、離れた位置にある複数の要素を整理しながら、多段階で答えを導き出すような高度なタスクにおいて、ナイーブな処理の場合LLMの純粋な処理能力（モデルの賢さ）まかせになってしまい、システム側での制御が難しいという弱点があります。 3. 回答根拠の不透明さとハルシネーション 実務でAIを活用する上で、「AIの回答が、ドキュメントのどの部分に基づいているか」をユーザーに明示することは、信頼性の観点から不可欠です。一般的な情報抽出では「LLMに回答と同時に参照元のテキストも出力させる」という手法がよく取られます。 この場合、LLMがプロンプトの指示を途中で省略してしまったり、実際にはドキュメントにないテキストを出力してしまうハルシネーションのリスクが常に伴います。また、「根拠を正確に出力する」という余分なタスクをモデルに強いることで、本来の情報抽出性能そのものが低下してしまう懸念も存在します。 このように、従来のやり方では「視覚情報の欠落」「散在する情報の整理」「根拠の不透明さ」という3つの壁にぶつかってしまいます。 これらの課題、特に「散在する情報の整理」や「複雑な関係性の欠落」を根本から解決するためのアプローチとして、近年大きな注目を集めているのが「知識グラフ（Knowledge Graph）」の活用です。 次のセクションでは、まずこの知識グラフとLLMを融合させることで何が可能になるのかを詳しく説明します。 知識グラフとLLMの融合 前セクションで触れた「情報の散在」や「複雑な関係性の欠落」といった従来のRAGの限界を突破するための鍵となるのが、「知識グラフ（Knowledge Graph）」とLLMの融合です 。 1. 知識グラフとは？ 知識グラフとは、実世界に存在する人・場所・組織・概念などの「エンティティ」と、それらの間にある「エッジ（関係性）」を用いて、情報をネットワーク構造で記述したものです 。 知識グラフの例（はじめての知識グラフ構築ガイド より抜粋して作成） 例えば上の例だと、「KarlとFredは友達（FRIEND）同士で、2人とも東京（Tokyo）に住んでいる（LIVES_IN）」という情報を、それぞれの人物や場所をノード（丸）で表し、それらの関係を矢印（エッジ）で繋いで構造化して表現しています。 こうしたデータはNeo4jなどの専用のグラフデータベースで管理され、Cypherなどのクエリ言語を使って操作されます。 知識グラフは情報同士の複雑なつながりや暗黙的な関係性を明示的かつ正確に表現できる一方で、データの構築や運用のハードルが高い点が長年の課題でした。 2. LLMとの統合 近年のLLM（大規模言語モデル）の発展は、知識グラフの構築や活用のあり方にも大きな変化をもたらしています。 まず大きな変化として挙げられるのが、LLMによって知識グラフの構築が圧倒的に容易になった点です。従来、テキストからエンティティやエッジを抽出してグラフデータを構築するには、固有表現認識（NER）をはじめとする複雑な自然言語処理の技術をいくつも組み合わせる必要があり、開発や運用のハードルが非常に高いものでした。しかし現在では、LLMに対してプロンプトで「この文章から要素と関係性を抽出して」と指示するだけで、柔軟かつ制御しやすい形でデータをパースできるようになり、構築のコストが大幅に下がっています 。 一方で、こうして構築した知識グラフを、今度はLLMのコンテキストとして与えて活用するアプローチも進化しています。これが、近年検索拡張生成の発展形として注目されている「GraphRAG」です 。LLMに構造化された知識グラフを組み合わせることで、従来のテキストを細切れにして検索するだけの方法では解けなかった、ドキュメント内の離れた情報を跨いで整理するような、高度で複雑な多段階推論が可能になります 。 3. 従来のRAGとGraphRAGの違い Naive RAGとGraphRAGの比較（「**When to use Graphs in RAG: A Comprehensive Analysis for Graph Retrieval-Augmented Generation**」 より抜粋して作成） ドキュメントの検索において、一般的なテキストベースの従来のRAG（Naive RAG）と、知識グラフを活用したGraphRAGには決定的なアプローチの差があります 。 Naive RAGの限界 ：ドキュメントを一定の長さでチャンク化し、質問文とのベクトルの類似度（セマンティック検索）で関連箇所を探します 。しかし、この方法では情報同士の暗黙的な関係性が削ぎ落とされてしまい、適切な回答を導き出せないケースが多発します。 GraphRAGの強み：ドキュメント内の要素をインデックス化する際、あらかじめ要素間の関係性をネットワーク構造として保持します 。そのため、質問に対して関連するグラフ構造を辿る検索を行うことができ、離れたページに散在している情報や暗黙的な関係性も取りこぼさずに網羅して抽出することができます 。 このように、LLMにドキュメントの構造や関係性を教え込むアプローチとして、GraphRAGは極めて強力なソリューションです 。 しかし、一般的なGraphRAGは依然としてテキストデータをベースにグラフを構築するものが大半です。PDF資料にあるような「グラフや図表、複雑なレイアウトそのものが持つ視覚的な意味」までを知識グラフに融合させることは、容易ではありません。 RAG-Anything RAG-Anythingは、テキスト、画像、表、数式といった異なるモダリティ（データの種類）の情報を、すべて「相互に繋がりを持つ知識エンティティ」として再定義し、包括的に検索・生成を行うオールインワンのマルチモーダルRAGフレームワークです。 RAG-Anythingの概要 1. インデックスの作成 RAG-Anythingにおけるマルチモーダルなインデックス作成（元論文より抜粋） まず、入力されたPDF資料を高度なレイアウト解析パーサー（オープンソースの「MinerU」など）を用いて、テキスト、画像、表、数式などのコンポーネントに分離・抽出します。 このとき、単にデータを細切れ（チャンク化）にするのではなく、「図とそのキャプション」「数式とその定義文」「表とその説明テキスト」といった、ドキュメント内で密接に関わっている周囲の文脈を保持したまま、知識単位に分解するのが大きな特徴です。 次に、分解された知識単位から、役割の異なる2つの独立した知識グラフを並行して構築します。 クロスモーダル知識グラフ（Cross-Modal Knowledge Graph）画像や表、数式などの非テキスト情報をVLM（視覚言語モデル）に入力し、検索用の「詳細な説明文」と、グラフ用の「エンティティ要約」の2つのテキスト表現を出力させます。これらを起点（アンカー）として、周囲のテキストチャンクと「belongs_to（〜に属する）」などのエッジ（矢印）で結び、ビジュアル要素をドキュメントの文脈構造の中に正しく位置づけます。 テキストベース知識グラフ（Text-based Knowledge Graph）ドキュメント内の純粋なテキスト部分に対しては、従来のGraphRAGの手法を用い、固有表現抽出や関係性抽出を行って文字ベースの知識ネットワークを構築します。 こうしてできた2つのグラフを、同一の概念や単語のマッチングによって1つの包括的な知識グラフへと融合させます。同時に、高速なセマンティック検索を可能にするため、すべてのノードや関係性を高次元のベクトルに変換したベクトルデータベースも裏側で構築されます。 2. クロスモーダル検索と回答生成 RAG-Anythingにおける情報検索と回答生成の流れ ユーザーから質問（クエリ）が投げかけられると、RAG-Anythingはまずクエリを分析し、文中に「図」「グラフ」「表」といった、特定のモダリティを指し示す語彙が含まれているかを識別します。 その上で、以下の2つの経路を組み合わせたハイブリッド検索を実行します。 構造的ナビゲーション（Structural Knowledge Navigation）：融合された知識グラフを探索し、キーワードが直接ヒットした要素だけでなく、グラフの繋がりを辿ることで、離れたページに散在している「暗黙的な関係性」を持つ関連要素まで取りこぼさずに抽出します。 意味的類似度マッチング（Semantic Similarity Matching）：クエリのベクトルを用いて、ベクトルデータベースから意味の近いチャンクやエンティティをピンポイントで検索します。 こうして両方の経路から集められた候補は、グラフ構造上の重要度、ベクトルの類似度、クエリから推測されたモダリティの優先度などを統合したスコアリングによって再ランキングされ、本当に必要なコンテキストだけが厳選されます。 従来の検索システムであれば、検索にヒットした「テキストによる説明」だけをLLMに渡して終わりでした。しかしRAG-Anythingは、検索結果に画像や図表由来のノードが含まれていた場合、元のドキュメントから該当する「生の画像データ」をピンポイントで取得します。 そして、厳選された構造化されたテキストコンテキストと、取得された生の画像の両方をVLMに同時に入力し、最終的な回答を生成します。これにより、テキストの文脈理解と、画像そのものが持つ生の情報を掛け合わせて回答を生成できます。回答の根拠となる図表が元データに直接ひも付くため、「どの視覚情報に基づいた回答なのか」を追跡しやすくなり、根拠なき出力（ハルシネーション）の混入を検知・抑制しやすいという利点があります。 3. 精度評価 RAG-Anythingの有効性を検証するため、論文ではマルチモーダルなドキュメントQAのベンチマークである「DocBench」および「MMLongBench」を用いた性能評価が行われています 。比較対象として、ネイティブマルチモーダルLLMへの直接入力（GPT-4o-mini）や、テキスト中心のGraphRAG手法（LightRAG）、画像要素のみをグラフ化する手法（MMGraphRAG）などが選定されました 。 （DocBenchデータセット による精度評価結果（元論文より抜粋） 実験の結果、RAG-Anything は各種ベースラインと比較して、特にドキュメントのページ数が多くなる長文コンテキストにおいて良好なパフォーマンスを示す傾向が確認されています 。例えば DocBenchデータセットにおける100ページを超える長大なドキュメントの検証では、DocBench の正答率〔Accuracy, %〕で MMGraphRAG に対して13ポイント以上の精度向上が見られました。また、MMLongBenchにおいても同様の傾向が見られ、情報が複数ページに分散している状況での優位性が示されています 。 さらに、どのコンポーネントが精度向上に寄与しているかを分析するアブレーション研究も行われており、RAG-Anything における性能のコアは、単なるリランカー等の工夫ではなく、デュアルグラフの構築によってドキュメント内の構造や要素間の関係性を保持できている点にあることが示唆されています 。 実際に使
- 生成AI
- LLM
- RAG
Coding AgentとはじめるMySQLパフォーマンスチューニング
こんにちは！バクラク申請・経費精算のエンジニアリングマネージャーをやっています、@ar_tamaです。 今回は、私たちのプロダクトで最近行ったバックエンドのパフォーマンスチューニング（スロークエリの改善）について書いてみたいと思います。比較的地味なトピックではありますが、Coding Agentをフル活用したエピソードとして、主にMySQLをバックエンドに持つアプリケーションの性能問題に直面している方の助けになれば幸いです。 発端：データ量や分布の変化で実行計画が変わった 私たちは、プロダクトごとに内部SLO（サービスレベル目標）を定めてモニタリングし、基準値を割ったらアクションすることを習慣づけています。 SLOというと大きな障害や可用性の話を想像されるかもしれませんが、特にバクラクのような業務システムでは、毎日繰り返し使う操作の遅さがそのまま利用者（お客様）の生産性低下に直結してしまうため、観測対象に主要エンドポイントの応答時間も追加しています。 今回その基準に違反したのは、複数のテーブルをJOINしてSELECTする処理のあるエンドポイントでした。これまでも必要に応じて、クエリをチューニングしたり、インデックスやインデックスヒントを追加したり、ミドルウェアを立てたり……と対策をさまざま取ってきた箇所です。今度は一体何が……？と調べたところ、たくさんのお客様にお使いいただきデータ量や分布（偏り）に変化が生じたことで、実行計画が意図どおり選ばれなくなったことが分かりました。 やったこと：AIと実行計画を眺める 対象のクエリが見えてきたので、実際に発行されているSQLとパラメータを取得し、Coding Agentと一緒にEXPLAINとEXPLAIN ANALYZEを確認しました。世は大AI時代ですが、主なやることは昔と変わりませんね。 EXPLAINは、MySQLがそのSQLをどう実行しようとしているかを見るためのものです。JOINの順序、使われるインデックス、推定行数などを確認できます。MySQLの公式ドキュメントでも、インデックスを追加すべき箇所やJOINの処理順を確認するための手段として説明されています。 一方で、EXPLAINはあくまで推定です。実際にどのくらい時間がかかったのか、どのステップでどれくらい行を読んだのかを見るには、EXPLAIN ANALYZEが役に立ちます。実際にステートメントを実行するので実行環境には注意が必要ですが、推定と実測のズレによってより精緻に改善することができます。 実際のSELECT文で双方を確認してみたところ、先述のデータ量・分布の変化によって、効かせたいはずのインデックスが選択されていなかったり、頻出のソート条件に合う複合インデックスがなくテンポラリソートが起きていたりと、大小様々な問題が発見されました。その中でも今回特に取り上げたいのは以下です。 JOINの起点が期待と違い、サブテーブルに持たせている種別の絞り込みから始まっていた その後、メインテーブル側で数万件規模の候補行を読み、除外条件を1行ずつ評価していた → クエリの責務を分け、サブテーブルの絞り込み→結果を使ってメインテーブルの絞り込み、と2回クエリを発行 以前のパフォーマンス改善対応（NOT IN＋サブクエリでフィルタ）が、むしろ大きな集合を作るような実行計画に変化していた → サブクエリではなく、 カラム NOT IN (...) とクエリ自体を書き換えることで対応 1についてはEXPLAINの目視でもすぐに分かるところでしたが、2についてはEXPLAIN結果を分析したCoding Agentからの指摘で初めて気づきました。 以前の対応時は、たしかに除外対象をサブクエリとして扱うほうが効率的だったはずなのですが、現時点でのデータ分布ではそのサブクエリを作るために大きなスキャンが発生しており、インデックスを辿りながら直接条件を評価する方が速くできそう、という見立てが出されたのです。 同僚からその部分の実装意図を聞いていたこともあり、はじめは「いやいやそんな〜まさか〜」と半信半疑でしたが、修正版を試してみたところ劇的に計画が改善されました。余計なコンテキストを持たないほうが強いこともある……🥲 なお、今回はGORMを使ってクエリを発行している部分が修正の対象だったため、実際のクエリの書き換えにあたり、同僚であるponさんのgormgoldenが大変頼りになりました。アプリケーションコード上では良さそうに見えても、出力されたクエリが大事故…ということもときには生じ得るため、このようにBefore/Afterの確認を行いやすい状態にしておくことも大事ですね。 github.com 結果として、対象クエリ群のほぼ全てで改善が叶い、ベストケースでは50倍以上もの高速化が叶いました。やったぜ！ デプロイ後にアラート対象のクエリが激減した様子 Coding Agentと人間との役割分担 今回のようなクエリチューニング作業においては、Coding Agentの網羅性と手の速さがとても頼りになります。クエリ改善で振る舞いが変わってしまうことのリスクとテストの重要性は前述の通りですが、分析・複数の改善案出し・検証・実装にいたるまで、積極的にAgentに任せながら改善を進めたおかげで、従来の改善活動よりもずっと早く修正が叶いました。 振る舞いの担保についても、以下のようなソースを参照して破綻しないことを確認してもらいました。 ヘルプサイトや仕様書 対応するクライアント（フロントエンド）の実装 これにより人の目だけでは拾いにくい検証観点も補え、動作確認も楽に行えました。 ただし、Agentは放っておくと限界までチューニングしようとしてしまいます。改善提案の中には、修正後のクエリが複雑になりすぎてメンテナンス性を損ねたり、修正量の割に改善効果が限定的だったりするものもありました。そのため計画時、または修正を走らせた後でも、「どの程度改善される見込みか」を確認しながら改善を採用する・しないの判断を行いました。 ほかにも、過去経緯などのコードや仕様に立ち現れないコンテキストを補完したり、ハルシネーションにツッコミを入れたり、計測と修正のサイクルを回すためにステップを分けたりなど、人間の仕事も思いの外残りました。とはいえ、今回の改善を回す過程で補完した文脈はドキュメントに残しましたし、モデルの進化も著しいため、次回以降はどんどん手がかからなくなっていくことが予想されます。 おわりに 今後の展望としては、今回の一連の流れを元に、SLO違反を検知→スロークエリをEXPLAINして原因を特定→修正・検証までを実行するSkillなどを作れると、改善のサイクルがより速く・多く回せそうです。 人間が本当に必要な判断に集中できるよう、またAI Agentたちにより多くの業務を任せられるよう、引き続き事業成長を支えるための改善活動を（も）進めていきます。 LayerXでは、AIと共に爆速で価値を生む・守る仲間を大大大募集しています！ご興味を持っていただけたらぜひこちらからご応募ください。 open.talentio.com 本職はマネージャーなので、AI時代のマネジメントどうなる〜？みたいな話も大好物です。カジュアル面談のお誘いもお気軽にどうぞ！ jobs.layerx.co.jp
- MySQL
- 生成AI
- パフォーマンス
- Go
JSAI2026（第40回人工知能学会全国大会）にプラチナスポンサーとして協賛します
こんにちは、バクラク事業部で機械学習エンジニアをしている伊藤です。 LayerXは、JSAI2026（第40回人工知能学会全国大会）にプラチナスポンサーとして協賛します。LayerXがJSAIに参加するのは昨年に引き続き4回目となり、本大会でも企業ブース展示、インダストリアルセッションでの発表を予定しております。 イベント概要 当社の参加内容 インダストリアルセッション 企業展示 学生向けランチ懇親会 協賛の背景 さいごに LayerXにおけるAI・機械学習関連の記事 イベント概要 JSAI（人工知能学会全国大会）は、人工知能学会 が年に1度開催する、人工知能および関連分野の研究発表や交流の場です。全国のアカデミアや企業からAIの研究・開発に従事している人々が集い、研究発表と活発な議論がなされる場です。LayerXからはバクラク事業部・Ai Workforce事業部を含む数名のメンバーで現地会場に参加させていただきます。 項目 内容 開催期間 2026年6月8日（月）〜6月12日（金） 開催場所 Gメッセ群馬＋オンライン（ハイブリッド開催） 主催 一般社団法人 人工知能学会 公式サイト JSAI2026 当社の参加内容 インダストリアルセッション 大会初日である6月8日のインダストリアルセッション1にて、Ai Workforce事業部の平澤より「LayerXにおけるセキュリティ管理の現在地と次の一手」というタイトルで発表させていただきます。LayerXが展開するAi Workforceの事例を通じて、セキュリティ管理の現在地と、開発スピードとの両立を目指す今後のセキュリティ戦略についてお話しします。是非ともご聴講ください。 タイトル: LayerXにおけるセキュリティ管理の現在地と次の一手 発表者: 平澤 寅庄（株式会社LayerX） セッション: [1B4-IND-1] インダストリアルセッション1 日時: 2026年6月8日（月）16:40〜16:55 会場: B会場（展示ホール仮設1） プログラムリンク: 1B4-IND-1-05 | JSAI2026 登壇情報 企業展示 JSAI2026の企業展示では、ブースE77にて展示を行います。LayerXが目指す「業務の完全自動運転」や、日頃の開発・研究開発の取り組み、インターンシップなどについて紹介させていただきます。少しでも興味を持っていただけた方はぜひ気軽にお立ち寄りください！ JSAI2026 企業展示配置図 学生向けランチ懇親会 JSAI2026に現地参加されている学生の方限定で、ランチ懇親会を開催予定です。現役のLayerXメンバーと、実際のAI Agent開発やサマーインターンなど、さまざまなトピックについてカジュアルに話せる場にできればと考えております。 ご希望の方は、以下の参加フォームより申し込みをお願いします！ 参加対象: JSAI2026に参加している学生の方 開催日時: 2026年6月9日（火）12:15〜13:15 参加フォーム（connpass） 2026年6月10日（水）12:45〜13:45 参加フォーム（connpass） 2026年6月11日（木）12:15〜13:15 参加フォーム（connpass） 参加費: 無料 協賛の背景 LayerXでは、広くAI・機械学習技術を活用しつつ、"業務の完全自動運転"を実現すべく複数の事業を推進しています。バクラク事業部では、あらゆるバックオフィス業務が「気づいたら終わっている」体験を届けるため、「バクラク」で提供されるAIエージェント群を開発、運用しています。Ai Workforce事業部では、エンタープライズ企業が業務ごと・組織ごとに合わせた形で、AIエージェントを「毎日の仕事」に組み込むための汎用AIプラットフォーム「Ai Workforce」を開発、提供しています。 また、我々LayerXの掲げる行動指針である「Bet AI」や「徳」の観点から、アカデミアやOSSコントリビューターの成果から一方的に恩恵を受けるだけでなく、アカデミアや技術コミュニティへの貢献を継続して行っていきたいと考えています。 LayerX行動指針 その上で、国内でも最大級の規模でアカデミアや企業の学生、研究者、開発者など様々な背景の方が集まり、幅広いトピックについて研究発表、議論、交流がなされるJSAIへと貢献することは、同様に様々な背景のメンバーが集まって幅広い技術領域における開発を進めるLayerXにとっても、そして社会の発展にとっても大変有益なことであると考えており、今回プラチナスポンサーとしてJSAI2026に協賛させていただくこととしました。 さいごに LayerXとしてJSAIに参加するのは昨年に引き続き4度目となります。昨年のJSAI2025に参加した際にも、企業ブースや懇親会、セッション聴講を通じて非常に充実した時間を過ごさせていただきました。本大会でも、是非たくさんの方と交流できればと思っております。参加者の皆様と群馬・オンラインでお会いできるのを楽しみにしております。よろしくお願いいたします！ LayerXにおけるAI・機械学習関連の記事 bakuraku.jp speakerdeck.com speakerdeck.com speakerdeck.com
- 生成AI
- セキュリティ
AIエージェントに1年分のニュースを読ませて4,500件の長期記憶を作って見えた課題
はじめに LayerX Ai Workforce事業部でApplied R&D をしているtyoyoです。 AI Agentの長期記憶に関して様々な手法が提案されていますが、そのどれもが実際に長期間で運用されたことはほとんどないはずです。なぜなら、それらが台頭したのが最近だからです。 個人的に長期記憶についての肌感覚がなかったので、実験として「1年分のAIニュースの長期記憶」を作ってみることにしました。 最大6並列で約20時間、607回のセッション、4,552個のmemoryファイル ー 動かしてみないと分からない「長期記憶の課題」にぶつかるため、今回はこういった規模でシミュレーションを行いました。 Claude Codeを参考にした簡易的な長期記憶システムの作成 基本的にはClaude CodeのMemoryを参考に、以下のような frontmatter（ファイル先頭のメタデータ記述部分）つきのMarkdownファイルを1つの単位とします。これらが memory/ ディレクトリ以下に大量に配置されるシンプルな構成です。 memoryファイルの具体例 --- date: 2024-08-14 description: "GartnerによるPoC後に見送られる生成AIプロジェクトが30%に達するという2025年末予測、生成AIのROI・短期投資回収困難・データ品質・コスト問題、企業の生成AIPoC失敗率統計を調べている時。" sources: - https://atmarkit.itmedia.co.jp/ait/articles/2408/14/news067.html related: - 2024-08-07-gartner-ai-investment-business-fit-failure-4-reasons.md --- # Gartner：生成AIプロジェクトの30%が2025年末までにPoC後に見送りになると予測（2024年8月） Gartnerは2024年8月、生成AIプロジェクトの30%が2025年末までに概念実証（PoC）後に見送られると予測した。IT Mediaが同日付で報じた。 バイスプレジデントアナリストのリタ・サラム氏は、「生成AIの2023年の過熱ぶりを経て、経営幹部は投資に対するリターンを急いで求めているが、組織は価値を証明し実現することに苦戦している」と述べた。見送りの主な背景として、$500万〜$2000万規模のコスト、短期的なROIが出にくい構造、データ品質の問題が挙げられている。CFOは将来の間接的価値のために投資することに抵抗感を持ちやすいとされ、長期コミットより短期成果を優先する傾向がある。 一方で早期導入企業はビジネス改善を報告しており、Gartnerの2023年9〜11月に822人のビジネスリーダーを対象とした調査では、平均売上高15.8%増加・コスト15.2%削減・生産性22.6%向上という自己報告値が示されている。ただしサラム氏は「ビジネス価値の推定は容易でなく、企業・ユースケース・役割・人材によって大きく異なる」と留保している。 この記憶は、生成AIのPoC後廃棄率・ROI困難・コスト構造に関するGartnerの定量予測として位置づける。楽観的な効果数字と廃棄リスクの両方を持つ点が特徴。 生成AIプロジェクトの投資判断・経営説得・リスク評価の文脈でGartnerの見解を参照したい時に見るとよい。 記憶の追加については、qmem-add というSkillを作り、そこに保存すべきものや保存形式などの指示を記載しました。 記憶呼び出しは、qmem-search というSkillを作り、そこに4つのアクセス手段を提示しました。 tobi/qmd を用いた検索（BM25（キーワードベースのランキングアルゴリズム）, ベクトル） description + ファイル名 の一覧を提示する qmem-ls コマンドによる、SKILL.md風遅延読み込み frontmatterのrelated によるグラフ辿り grep などを用いたキーワードマッチ またHook を用いたリマインダーによる自動的な記憶呼び出しも作成しました。各ユーザーからのpromptとツールの呼び出し結果をクエリとし、BM25検索で一定の閾値を超えた場合に <qmem> {filename}: {description} </qmem> のようにAgentに記憶が提示されます。 Dreaming（記憶のライフサイクル管理）としては qmem-maintain Skillを作り、20セッションに1回 Agent自身に記憶の重複削除・古い記憶の更新・related フィールドを用いた記憶の関連付けを行いました。 Agentに1日で1年分のニュースを読ませる データとしては LayerX AI・LLM Newsletter を60号分（2024年1月-2025年2月まで）使用しました。各Newsletterは平均2万文字、リンクとしては111個と大きなファイルです。Agentは10分割されたNewsletterファイルを読み込み、それぞれのニュースについて記憶を追加するように指示を受けます。 Claude Codeのデフォルト設定を使用し、モデルはSonnet 4.6 (200k) を利用しました。 Dreaming以外は6並列でまわし、およそ20時間程度かかりました。合計で607回のセッションが実行されました。まれにプロセスが固まってしまうため、Claude Codeの /loop を使い実験を監視・再開させていました。またそのClaude Code自体がレートリミットで落ちてしまうことがあったため、codexbar cli を用いてレートリミットがリセットされるタイミングで監視を蘇生させていました。実験はClaude Code Maxプランを用いて行いましたが、API換算だと合計で$407 かかっている計算です。 1年分の記憶をもつAgent 結果として4,552個のmemoryファイルが生成されました。これらの記憶をもつAI Agentに 「RAG の評価設計を相談したい。retriever / reranker / generator のどこから手を付けるべきか?」 と質問をしてみると、 ...記憶によると（2024-08-19-aws-ragchecker-claim-level-rag-evaluation-framework.md）、 Amazon/AWS が 2024年8月に公開した RAGChecker は 「Retriever モジュールと Generator モジュールのそれぞれに対して独立した診断メトリクスを持つ」設計で、 個々の claim レベルで評価を行うことで「どのモジュールに問題があるかを切り分けられる」とされています。 8 つの RAG システムを評価した論文で、GitHub（amazon-science/RAGChecker）でオープンソース公開されています。... のように、過去に読んだ記事をもとにした回答ができています。 Dreamingプロセスの分析 記憶のライフサイクル管理、Dreamingは計18回実行され、450件のファイルを更新・245件のファイルを削除しました。更新では主に記憶同士の関連付け（relatedフィールドの更新）、削除では主に重複した内容の削除（技術ブログとそれを題材にしたSNS投稿など）が行われていました。 またClaude自身が誤ったフォーマットでmemoryファイルを記述してしまい、それをDreamingプロセスで直しているケースも見受けられました。例えばファイル名だけを記述するように指示していたがファイルパスごと記述してしまったり、日付を書くように指定してたものの 2024-08 のように月までしか書いていなかったケースも有りました。これらを防ぐには、長期記憶のシステムにもハーネスのような可能な限りLLMではなくプログラムで守る仕組みが必要です。 個人的に残念だったのは、関連ノードのグラフがほとんど育たなかったことです。全ファイル中 related フィールドをもつのはわずか11.3%で、残りはほぼ孤立していました。もちろん全てのmemoryファイル自体に関連があるわけではありませんが、定性的に確認していても関連しているのにrelated ではないものが見受けられました。relatedを追加するかどうかのpromptは、もっと積極的にrelatedを追加せよ、と書くべきだったかもしれません。 またDreamingのプロセスは「新規追加されたmemoryファイルは全文読み込み、それ以外はfile名とdescriptionのカタログのみ読み込み」を行ってから関連記憶の紐づけを行っていたのですが、4,552ファイルの段階でこのカタログだけで200k contextの228% を占めてしまっていました。DreamingにおいてAgentに自身の記憶を修正させるのは強力ですが、その分扱えるmemoryファイルの数は有限で、「何を忘れるか」の設計も重要そうです。あるいはAgentを使わない埋め込みベースのライフサイクル管理や、階層的なデータ構造なども考えられます。 まとめ 実際に長期記憶の作成をシミュレーションしてみて感じたのは、動かしてみないと見えてこないことがたくさんあるということです。 構想段階では「どのベクトル検索ライブラリを使おうかな」「どんなデータ構造にしようかな」ということを考えていましたが、実際には「何を記憶するか」「いつ繋ぐか」などの細かいプロンプトの影響が大きかったです。またmemoryは容易に膨れ上がるので、「忘れさせる」という戦略をとるか、「スケールするようにする」という戦略の2軸があるように思いました。 この記事で紹介したR&Dチームの詳細はこちらです。 open.talentio.com
- 生成AI
- LLM
Microsoft Foundry Hosted Agent と Claude Agent SDK を使ったサンドボックス検証
こんにちは、LayerX Ai Workforce事業部でSWEをしているosukeです。 Webサービスの裏側など不特定多数のユーザーが操作する環境でAIエージェントを動作させるためにまず必要になるのがサンドボックス技術です。エージェントは自律的に柔軟な挙動をする反面、それらをセキュリティ的に閉じ込める必要が出てきます。 本記事では、Azure内で閉じる構成として、Claude CodeをSubprocessとして動かせるClaude Agent SDKとMicrosoft Foundry Hosted Agentというエージェントサンドボックス基盤を軸に構成の検討をしていきます。 AI エージェントにおけるサンドボックスの重要性 不特定多数のユーザーが触る環境で AI エージェントをサンドボックスで守るために、具体的には次のような要件が同時に求められます。 各ユーザーのチャット内容や添付ファイル・実行結果が、別のユーザーから見えないこと LLM が意図せず (あるいはプロンプトインジェクション的に悪意ある形で) 触ったコマンドが、ホストや他テナントのリソースに到達しないこと ファイル書き込み・ネットワーク通信・サブプロセス起動の副作用を、用途に応じて制限できること これらの個別の攻撃パターンを一つひとつ deny ルールで塞いでいくアプローチは、新しい variation が出てくるたびに穴が開きます。アドホックな個別対応は、時間とともに漏れが生じることを前提にすべきです。セキュリティは「包括的に、構造的に、多層に」組まないと持たない、というのが AI Agent の sandbox を設計するうえでの基本的な発想となります。 Hosted Agent の sandboxing Hosted Agent は、session 単位で microVM を立て、Azure VM 同士と同じ強度の境界で隔離する仕組みです。これを実機で確認するため、2 つの session で /proc/sys/kernel/random/boot_id を比較してみると、boot_id が完全に異なる、つまり session ごとに別の microVM を立てていることが実機で確認できます。 $ cat /proc/sys/kernel/random/boot_id # session A 8b86efce-0bb0-43af-b96b-72d78dfcad60 # session B bd14205a-5eb2-4145-8d0a-ac9ed6fa932d 同じ session で 2 回呼ぶと同じ boot_id が返るので、microVM の寿命が session 単位であることも確認できます。 Built-in ツール (Read / Write / Glob 等) はこの境界で防御 Claude Agent SDK の Read / Write / Edit / Glob / Grep は Agent プロセス内で完結する処理なので、microVM の filesystem に閉じています。cwd をプロジェクトディレクトリに制限し、Agent SDK の add_dirs=[] で cwd の外側を既定で読めないように制限すれば、別 session のファイルが見えてしまうことは構造的に発生しません。 問題は Bash です。Bash を allow にした瞬間、microVM 境界だけでは塞げない経路が多く出てきます。エージェントが Bash を手にすることで本来の自律的な動きが備わる一方でセキュリティ的な考慮点が大幅に広がります。 例えば、外部サービス（Model など）にアクセスするための Token など機微情報がファイルシステム上に存在しているとそれを守る必要があります。あるいは、あらゆる手段で外に抜けようとする内部通信や外部通信を防ぐ必要があります。 Hosted Agent においては Bash 実行における脅威を保護するためにもう一つレイヤを入れる必要があります。 Bash 経由の脅威を個別対応で塞ぐことはできる、しかし 同一 microVM 内で Bash が起こせる脅威に対しては、それぞれにアドホックな対応を積み重ねていけば、原理的には個別に塞ぐことができます。具体的なイメージは以下の通りです。 機微情報抽出 (Bash から token 等を読まれて外部クラウドの権限を奪取される) → 読み出しコマンドを deny rule で塞ぐ + OS の uid 分離で file permission を活用して読み取り権限自体を落とす sibling process の env 漏洩 (/proc/<別 pid>/environ 経由で同 container 内の他プロセスの secret を吸われる) → Bash subprocess の uid を分離する + container に渡す env を最小化する。同一 micro VM 内なので脅威は限定的ではある。 persistence pivot (.bashrc / CLAUDE.md を書き換えて次回起動時の hook に悪意あるコードを仕込まれる) → 設定ファイル群を read-only マウントにする + 起動時に読み込まれる設定ファイルの読み込み自体を無効化する。同一 micro VM 内なので脅威は限定的ではある。 TLS Inspection 回避経由の exfil (allowlist 許可ドメインへの SNI 偽装や DNS exfil で secret を外に持ち出される) → Firewall allowlist を最小化 + DNS 経由で wildcard 的に到達先を広げられないよう制御する アドホック対応は漏れやすい 冒頭の通り、これを「アドホックな個別対応の積み重ね」として運用しようとすると、いくつもの構造的問題が出てきます。 1: 個々の対応の境界がそもそも狭い。たとえば前述の permissions.deny の Read rule は cat / head / tail / sed のような「読み出し専用ツール」には適用されますが、ファイルを間接的に開ける任意のサブプロセス（スクリプト言語の標準ライブラリ、テキスト処理ツール、bash builtin のリダイレクト等）には適用されません。例えば Python が同梱されていれば、 python3 -c "print(open('/run/secrets/example-token').read())" のような形で deny rule を構造的に素通りできます。回避経路はこのカテゴリ全体にわたるため、コマンド単位の deny を積み上げても閉じません。 2: 新しい脅威カテゴリが見つかるたびに穴が開く。Python 経由の file read が回避経路だと分かった時に Python 対策を足す、というイタチごっこになる。 3: 監査説明性が低い。お客様のセキュリティレビューや社内監査で「どんな攻撃から守られているか」を説明するときに、個別ルールの組み合わせよりも、「OS 層の namespace で構造的に切ってあります」と言える方が説明性も再現性も高い。 要するに、AI Agent の sandbox を本気で組むなら、個別 deny rule の積み上げではなく、構造的・包括的・多層的な防御を OS / VM 境界で組むのが筋 です。 Bash sandbox のパターン比較 それを踏まえて、LLM に Bash を渡すための実装パターンを 4 つ並べました。ここでは、Hosted Agent を基盤として、Azure 内に閉じた構成にできる技術選定に絞っています。Hosted Agent は microVM 境界を提供する基盤として有用ですが、その上で Bash を sandbox 化するレイヤがもう一つ必要になります。 パターン 隔離レイヤ 実行体 (1) Hosted Agent 上で素の Bash + 個別アドホック対応 なし (個別 deny の積み上げ) container 内の実 bash (2) just-bash (Vercel) JS interpreter 層 (Node.js プロセス内) TS 製の bash 互換 interpreter (3) Azure Container Apps Dynamic Sessions で safe-bash MCP tool 別 microVM 層 (Cloud Hypervisor) 別 microVM 内の実 bash (4) Claude Code 公式 sandbox OS 層 (Linux: bubblewrap / macOS: Seatbelt) 同 container 内の実 bash を namespace で jail (1) については前節で議論した通り「アドホック対応の積み上げは漏れる前提」なので本命からは外しています。(2) と (3) も検討候補にはなりましたが、いずれも本検証では本命から外したので、まず先に短く触れます。 (2) just-bash Vercel の just-bash は TypeScript で書かれた bash 互換 interpreter + in-memory virtual filesystem で、child_process を import すらせず実 process を spawn しないというユニークな設計です。「実 bash を渡さないことで攻撃面そのものを狭める」という思想自体は綺麗ですが、ただ 2026 年 5 月時点では README にも明記の通り Beta Software で、リリース履歴もまだ若く、信頼境界に持ち込むには実績が十分とは言えない段階と考えます。 (3) Azure Container Apps Dynamic Sessions: 強い分離・重いコスト 外部の 隔離環境 (Azure Container Apps Dynamic Sessions) に bash 実行を外注する設計で、Microsoft 公式に "designed to run untrusted code" と明言されているだけあって sandbox 強度的には適した基盤として扱えます。ただ設計を進めてみると、軽い実行でもオーバーヘッドが重い、cold start考慮、並列実行のための特殊な考慮など構造的なコストが重く、Agent 体験を最優先するワークロードには合いませんでした。 (4) Claude Code Bash Sandbox: Hosted Agent と組み合わせて構造的二層防御に Claude Code (= Claude Agent SDK の CLI 部分) の Bash sandbox 機能 は、CLI binary 内に bubblewrap (Linux) を呼び出す実装が組み込まれていて、Bash tool subprocess を OS 層で jail できます。ClaudeAgentOptions.settings 経由で設定を渡すと、 mount namespace で cwd 外を ro,bind に net namespace で外向き通信を構造的に遮断 pid namespace で sibling process 不可視 user namespace で uid 分離 filesystem deny/allow rule で JWT 等の secret を物理マスク これらを OS の namespace 機構で一括して構造的に切ってくれます。 ただ、Bash sandbox を使うためには、上記のように非特権プロセスが syscall で namespace を作れる環境である必要があります。実は、Hosted Agent はマネージドサービスでありながらこの点で相性が良く、VM 境界に信頼をおいているゆえ、namespace を切ることができるようです。 実機で sandbox 有効状態にして、各種検証したログがこちらです。 # 1. federation token の読み出し — denyRead が OS 層で mask $ cat "$EXAMPLE_TOKEN_FILE" # 機微情報を保持する環境変数 (例: federation token のパス) cat: /run/secrets/example-token: No such file or directory # 2. Python 経由で同じファイルを開いてみる — Python でも同様に存在しないことになっている $ python3 -c "open('/run/secrets/example-token').read()" Traceback (most recent call last): File "<string>", line 1, in <module> FileNotFoundError: [Errno 2] No such file or directory: '/run/secrets/example-token' # 3. sibling process の environ を覗く — pid namespace 分離で jail 内の pid しか見えない $ ls /proc | grep -E '^[0-9]+$' 1 2 4 $ cat /proc/123/environ cat: /proc/<span class="s
- 生成AI
- Azure
- セキュリティ
外部イベントがモニタリング対象に与える影響を評価し続けるエージェントの試作
こんにちは。LayerX の Ai Workforce 事業部 FDE部エンジニアのkoseiと申します。 当事業部では、エンタープライズのお客さま向けにAi Workforceというプロダクトを提供しています。 今回はAi Workforceそのものの話ではないですが、関連する一般的なユースケースについて少し試していることを共有します。 組織が大きくなると、多種多様で膨大なアセットをどう活かすか、どう管理し、守り、継続的に価値を出していくのかが重要になります。 ここでいうアセットは、単なるファイルや文書だけではありません。個別の案件やプロジェクト、ノウハウ、実施機関や取引先企業、契約や判断履歴、現時点でのリスク状態なども含まれます。 こうした対象は、一度評価して終わりではなく、外部で起きた出来事をきっかけに、評価や優先順位、活用可能性が変わっていきます。そうなると、人間がすべてを手作業で追い続けるのではなく、エージェントが 今どれがリスクが高まりそうか どれに人が入るべきか どこは一旦据え置いてよいか を常に監視・更新し、人間がすぐにアクションに活かせる状態を作りたくなります。 今回は、そのようなケースで何が重要になってくるのかや肌感を得るため、 「外部イベントをフックに、管理対象の評価を更新していく ambient agent 的なもの」を、小さく作って試してみました。 背景 このような「外部を起点に、管理対象の評価・判断を更新し続ける」ユースケースは、意外と幅があります。 例えば、公募案件の一覧に対して、自社アセットを活かして取りにいけそうな案件はどれかを継続的に監視・評価する、というケースがあります。 他にも、コンプライアンス運用において、法改正や当局ガイダンス、同業他社への行政処分のニュースを受けて、今どのルールは優先的に見直しをした方が良いかを考えるなどがあり得ます。 ただ、ここで難しいのは二次的な影響です。外部イベント（ニュース記事等）に案件名や実施機関名がそのまま出てくるなら話は簡単ですが、実際にはそうならないことのほうが普通です。たとえば、湾岸の情勢の悪化やタンカー被害のニュースは、個別の内陸インフラ案件名を含みません。航空便の大量欠航や移動制限のニュースも、どの島嶼国の空港案件や物流案件に影響するかまでは直接書いてくれません。商品価格や燃料価格の変動も、どの設備案件に効くかを明示してくれるわけではありません。 このあたりはサプライチェーンの文脈では以前からよく議論されているようです。特定の外部イベントがどの調達先や物流網、供給先に波及するのかを把握し、調達不能になるリスクを下げたり、代替調達を素早く打てるようにしたりする、という文脈です。 今回見たかったのも構造としてはかなり近く、違うのは対象が部材や供給網そのものではなく、案件やプロジェクト、その評価状態（リスクがどの程度か）である、という点です。 しかも、外部イベントとして得られる記事が、必ずしも管理対象の文書と意味的に近いとも限りません。たとえば「航空便の大量欠航」という記事に対して、本当に見たいのは航空会社そのものではなく、現地渡航や施工監理が止まりそうな案件、輸送制約で機材搬入が遅れそうな案件のような、もう一段波及した先です。 このとき、単純な対象名一致やベクトル検索だけだと、二次的な影響先までは届きにくいです。そこで今回は、この「二次的な波及」についても試すのにちょうどよい題材として、Knowledge Graph （以後KG）を使用しました。 題材とするユースケース 今回は題材として、World Bank の公開プロジェクト文書と外部ニュースを使いました。複数プロジェクトを横断的に見ているマネージャーや評価機関のような立場を想定して、「外部環境の変化によってどのプロジェクトが危なそうか」「どのプロジェクトに手を入れるべきか」を見たい、というダミーユースケースを置いています。 World Bank のdocumentsデータには、「プロジェクトの関連文書」として、プロジェクトの概要や追加融資の背景が書かれた資料、プロジェクトの基本情報や環境・社会配慮の論点がまとまった資料、環境影響評価のための文書といった資料が多く含まれており、実際の業務におけるユースケースに近い形で実験できるため、今回用いました。 データ出典： The World Bank, Projects & Operations / World Bank Projects API, 取得日：2026年5月20日。 The World Bank, Documents & Reports API, 取得日：2026年5月20日。 World Bank 資料の利用は、Terms of Use for Datasetsに従います。 これらの資料を用いて、KGを構築します。 イベント側のデータとしては、外部ニュースのようなものを想定しています。今回は具体的なソースとして GDELT を使いました。特に、15分ごとに更新される GDELT Event Database という、報道されている情報を元に「誰が、誰に対して、何をしたか」といったメタデータが付与されたイベントデータセットから抽出して利用しました。 データ出典：The GDELT Project（https://www.gdeltproject.org/） 本当は、一定期間で LLM が「リスクが高い」と判定した案件が、結果として本当に危なかったのか、あるいは安定してうまくいったのかまで検証できるとさらに面白かったと思っています。World Bank の案件には第三者機関による評価の仕組みもあるようで、そういったスコアと照らし合わせられると、どの程度当たり外れがあったのかをもう少し定量的に見られたはずです。今回は時間の都合でそこまではできていません。 画面イメージ 今回試作したものの画面は以下になります。 1枚目は各プロジェクトのリスクに関するスコアを集計した全体を俯瞰するダッシュボード的な画面と特にリスクが高く手当が必要なプロジェクトが並んでいる画面です。2枚目は、特定のプロジェクトをクリックして閲覧可能な詳細画面であり、各プロジェクトの具体的なリスク内容等を検討する画面です。 重要な点としては、各値は固定のレポートではなく、外部イベントをきっかけにエージェントが情報収集・判断した結果を集計・反映したものであり、外部イベントが発生するたびに更新されていくということです。 人間はこのモニターを起点に、スコアが大きく変化した案件を深掘りしたり、異常な変化だけを別途検知したりできます。 今回の画面では、実際に LLM が作ったリスク評価結果を使っています。つまり、最終的にやりたかったのは、 人間が一覧で全体感を掴む 変化が大きいものに気づく 必要なときだけ個別案件に入る という運用であり、モニターはそのための入口です。 今回の構成 今回の構成は、大きく分けると 3 段階です。 2と3を繰り返すことで、外部イベントを起点にした判断結果データ（エージェントによるリスク評価）を更新し続ける仕組みです。 まず、World Bank のプロジェクト文書から KG を構築し、各プロジェクトの初期リスク評価を作って DB に保存する その後、イベント(ニュース)を入力にして、KG 上で関連しておりリスク影響がありそうなプロジェクトを見つける プロジェクト文書等の詳細と照らし合わせて、リスク評価の更新を推論する flowchart TB %% ===== データソース ===== subgraph WB["世界銀行プロジェクト（一次データ）"] WB_DOC["プロジェクト文書<br>(PDF/HTML/JSON)"] WB_META["プロジェクトマスタ<br>(ID / 国 / セクター / 金額など)"] end subgraph EXT["外部イベント（ニュース等）"] EV["外部イベント<br>(ニュース等)"] end %% ===== 事前構築（KG + DBの初期評価） ===== subgraph PREBUILD["1. 事前構築（KG構築 + 初期DB構築）"] RELEX["LLMで関係抽出"] KG((("Neo4j ナレッジグラフ"))) PM[("プロジェクトDB<br>(project_id, title, links, ...)")] RISK[("リスクDB<br>(type, prob, impact, rationale, ...)")] WB_DOC --> EVAL_INIT["LLMで初期リスク評価"] --> RISK end %% ===== イベントフックでのKG探索 ===== subgraph EXPLORE["2. イベントフックでのKG探索"] ING["イベント取り込み"] QGEN["KG探索"] JOIN["関連プロジェクト候補の抽出"] end %% ===== リスク評価の更新 ===== subgraph UPDATE["3. リスク評価の更新"] EVAL["LLMでリスク評価<br>(記事 + 根拠パス + 既存状態)"] HIST[("イベント評価履歴DB<br>(event, path, diff, timestamps)")] end %% ===== PREBUILD ===== WB_DOC --> RELEX --> KG WB_META --> PM %% ===== EXPLORE ===== EV --> ING --> QGEN --> JOIN KG --> JOIN %% ===== UPDATE ===== JOIN --> EVAL PM --> EVAL RISK --> EVAL EVAL --> HIST %% ==== overall ==== 1. 事前構築 flowchart TB %% ===== データソース ===== subgraph WB["世界銀行プロジェクト（一次データ）"] WB_DOC["プロジェクト文書<br>(PDF/HTML/JSON)"] WB_META["プロジェクトマスタ<br>(ID / 国 / セクター / 金額など)"] end %% ===== 事前構築（KG + DBの初期評価） ===== subgraph PREBUILD["1. 事前構築（KG構築 + 初期DB構築）"] RELEX["LLMで関係抽出"] KG((("Neo4j ナレッジグラフ"))) PM[("プロジェクトDB<br>(project_id, title, links, ...)")] RISK[("リスクDB<br>(type, prob, impact, rationale, ...)")] EVAL_INIT["LLMで初期リスク評価"] end WB_DOC --> RELEX --> KG WB_DOC --> EVAL_INIT --> RISK WB_META --> PM KGの構築自体は、かなりシンプルに neo4j_graphrag （https://github.com/neo4j/neo4j-graphrag-python）の SimpleKGPipeline を使って構築を始めました。 llm = OpenAILLM(model_name=kg_model) embedder = OpenAIEmbeddings() pipeline = SimpleKGPipeline( llm=llm, driver=driver, embedder=embedder, schema=KG_SCHEMA, on_error="IGNORE", from_file=True, perform_entity_resolution=True, ) await pipeline.run_async( file_path=str(path), document_metadata=metadata, ) このくらいのコード量でスタートできるので、「まずナレッジグラフを構築して動かしてみる」用途ではかなり扱いやすいかと思います。 また、今回は どの組織が実施主体なのか どの施設や設備が関係するのか どの国や制度と結びついているのか などを ノードやリレーションとして設定しておくことで、二次的な波及もLLMが推論に活かすことを期待します。 最終的にはプロジェクトへの影響が見たいので、KG上には、管理対象である「プロジェクト」を表すノードも追加しておき、 そのノードとのリレーションも推論させます。（プロジェクトへの波及の推論に使うため） これにより以下のようなナレッジグラフが得られます（ピンク色の大きめの丸がプロジェクトに対応します） 2. ニュース評価 flowchart TB subgraph EXT["外部イベント（ニュース等）"] EV["外部イベント<br>(ニュース等)"] end subgraph EXPLORE["2. イベントフックでのKG探索"] ING["イベント取り込み"] QGEN["KG探索"] JOIN["関連プロジェクト候補の抽出"] ING --> QGEN --> JOIN end EV --> ING 外部イベントであるニュースが入力されると上記のフローで関連するプロジェクトのリスク評価を更新します。 今回は素朴に、探索の起点としてまず記事本文に近い Chunk を探し、その Chunk から関連エンティティや 管理対象プロジェクトのノードまでのパスを取っています。 3. リスク評価更新 flowchart TB subgraph UPDATE["3. リスク評価の更新"] EVAL["LLMでリスク評価"] HIST[("イベント評価履歴DB<br>(event, path, diff, timestamps)")] end JOIN["関連プロジェクト候補の抽出"] PM[("プロジェクトDB<br>(project_id, title, links, ...)")] RISK[("リスクDB<br>(type, prob, impact, rationale, ...)")] JOIN --> EVAL PM --> EVAL RISK --> EVAL EVAL --> HIST その後、 ニュース本文 KG 上のパス 既存リスク プロジェクト文書 を合わせて LLM に渡し、「このプロジェクトのリスク評価をどう更新すべきか」を判断させる流れにしました。 更新先のデータベースはかなりシンプルで、イメージとしては、 project_id リスク内容 リスクの影響度 リスク発生確度 判定理由 のような項目を持つものです。 実際に作ってみてどうだったか 結論から言うと、今回狙っていたような 外部イベントから KG を通じて 妥当な二次的波及を拾い そのままリスク評価の更新を適切に行う というところまでは、まだ十分に実証できたとは言いづらかったです。 12回分のイベントデータを入力してリスク評価の推移を人手で見た所感ですが、妥当な結果よりも「変化しない」「誤検知」の割合がか
- 生成AI
- Neo4j
- Python
AI時代の新規プロダクト立ち上げ 〜バクラク給与の開発で見えたこと〜
こんにちは。バクラク給与の開発を担当しているakahaneです。 新規プロダクトとしてバクラク給与を立ち上げ、2026年3月にリリースしました。その開発の進め方について振り返ります。 はじめに バクラク給与の立ち上げでは、Claude CodeやCodexなどのコーディングエージェントを積極的に活用しました。 ただし、これは「AIにコードを書かせたら速かった」という話ではありません。 給与計算は、間違いが許されない領域です。計算結果が1円ズレれば、それは従業員の生活に直結する。「それっぽく動くコード」が最も危険な領域とも言えます。 一方で、新規プロダクトの立ち上げは変化の連続です。仕様も設計もプロダクトの形も日々変わる。このフェーズでは、試作・修正・検証のサイクルをどれだけ速く回せるかが勝負になります。 「間違えてはいけない」と「速く試行錯誤したい」。この一見矛盾する要求の中で、コーディングエージェント時代の新規プロダクト立ち上げが実際どのように進んだのかを紹介します。 フィードバックループを「翌スプリント」から「翌日」に変えた 新規プロダクトの立ち上げでは、最初から正解の仕様・設計は存在しません。 バクラク給与でも、初期は「まず動くものを作る」「実際に触れる形にする」「チームやドメインエキスパートと議論できる材料を作る」ことが最優先でした。仮で作った画面を翌日に作り直す。一度決めたデータ構造を、ドメイン理解が進んだことでゼロから見直す。そうしたことが日常的に起きていました。 ここでコーディングエージェントが大きく効きました。 たとえば、ある日の仕様検討会で「この画面の構成を変えるべき」というフィードバックがありました。一見すると画面上の表示変更に見えますが、実際にはAPIのレスポンス構造やフロントの表示ロジックにも影響するほどの変更です。以前なら次のスプリントに回していたような規模感ですが、コーディングエージェントを使うことで、その日のうちに方針を整理し、翌日にはチームにデモできる状態にできました。 こうしたサイクルは、この一度きりではありませんでした。 立ち上げ期には、毎日のように仕様検討会やレビュー会を実施していました。顧客ヒアリングで得たフィードバックも、翌日の別の顧客のヒアリングで意見を伺う。そこでまた反応を見て改善する。そういう短いループを日々回していました。 実装速度が上がることで、チームや顧客との対話の頻度も上がる。仮説を早く形にし、早くぶつけ、早く直す。結果として、プロダクトの解像度を上げるスピードが変わりました。 ただし、速く作れることは、何でも作ってよいという意味ではありません。作るコストが下がったからこそ、「本当に作るべきか」「使われ続けるものか」「将来の開発速度を落とさないか」を、以前よりも強く意識する必要がありました。新規プロダクトにおいては、作らない判断やシンプルに保つ判断も、同じくらい重要です。 note.layerx.co.jp 実務の温度感は、コーディングエージェントには判断できない 給与計算領域では、AIにいきなり実装を依頼してもうまくいきませんでした。 コーディングエージェントに聞けば、給与ドメインに関する一般的な情報はある程度得られます。所得税の計算方法、社会保険料の算出ロジック、基本的な用語の説明。しかし、それだけでは足りません。 実際の日々の業務で、その作業がどのくらい大変なのか。労務担当者がどの部分を特に慎重に確認しているのか。間違えたときにどのくらい影響が大きいのか。なぜ一見面倒に見える確認ステップが必要なのか。こうした現場の温度感は、コーディングエージェントには持ちようがありません。 たとえば、社会保険料の控除ひとつとっても、法令上のルールだけを見れば「翌月徴収」で「端数処理は五捨五超入（50銭以下切り捨て、50銭超切り上げ）」とシンプルに見えます。しかし実務では、慣習的に当月徴収を採用している企業や、法令とは異なる端数処理を用いている企業が少なくありません。こうした現場ごとの運用実態は、法令の条文やインターネット上の情報だけでは把握できず、コーディングエージェントに聞いても出てきません。 また、給与計算そのものだけでなく、計算後のチェックをどう行うかも重要でした。労務担当者は計算結果をただ眺めるのではなく、前月との差分を見て異常値を探す、特定の項目を重点的に確認する、といった独自のチェックフローを持っています。どの画面で何を見れば安心して確定ボタンを押せるのか。こうした確認プロセスは法令に書かれているものではなく、ドメインエキスパートとの議論を通じて初めて見えてきた部分でした。 そのため、AIに実装を任せる前に、労務ドメインエキスパートと一緒に仕様を言語化するプロセスが不可欠でした。そして言語化した仕様をもとに議論を重ね、重要度の濃淡を設計判断に落とし込むこと。それがプロダクトの土台になりました。 note.layerx.co.jp 給与計算ロジックの中心は、あえて人間が書いた 給与計算ロジックの中心部分は、コーディングエージェントの利用をあえて控え、人間が中心となって実装しました。 理由は明確で、この領域ではAIが「それっぽいコード」を書けてしまうこと自体がリスクだからです。 給与計算では、単に数式を書けばよいわけではありません。支給、控除、勤怠、締め日、支給日、月途中入社・退職、休職、端数処理。さまざまな条件が絡む。さらに、「計算結果が合っている」だけでなく、「なぜその金額になったのか」を説明できることも求められます。 コーディングエージェントに正しく実装させようとすると、業務上の前提、計算の意図、例外条件、端数処理、保存すべき計算根拠、将来の拡張可能性を、すべて正確に言語化して渡す必要がある。そして、出てきた実装が正しいかをレビューするには、結局人間がロジックを同じレベルで理解していなければなりません。 であれば、そのコンテキストを作る時間とレビューの時間を考えると、人間が自分で書いたほうが早く、確実でした。 AIが生成するコードの怖さは、エラーになる、動作しないことではなく、それっぽく動作してしまうことにあります。画面上も問題なく見える。しかし、特定の条件で1円ズレている。給与計算では、こうした「動くが正しくない」コードが最も発見しにくく、最もダメージが大きいリスクになります。 テストケースの洗い出しでは、AIが強力なレビュアーになった 一方で、テストケースの作成にはAIを大いに活用しました。 計算ロジックでは、正常系だけでなく、境界値や例外パターンをどれだけ洗い出せるかが品質を左右します。人間だけで考えていると、自分が実装した前提に引っ張られて、どうしても見落としが出る。 そこで、実装したロジックや仕様メモをAIに渡し、「この仕様に対して、漏れやすい境界値や異常系を洗い出して」と依頼しました。「テストコードを書いて」ではなく、テスト観点の網羅性を問う使い方です。 たとえば、月途中入社・退職のテストケースでは、人間が考えた「月初入社」「月末退職」「月途中入社」に対して、AIは「入社日と退職日が同月」「締め日をまたぐ入社」「支給日前日の退職」「休日に重なる場合」といった観点を追加で出してきました。すべてが有効なケースではありませんでしたが、ドメイン上検討すべき観点として有用なものが多くありました。 AIにテスト観点を出させ、人間がドメイン上正しいかを確認し、必要なケースをテストコードに落とし込む。この進め方により、給与計算ロジック周辺でカバレッジ90%以上を達成できました。 AIは実装者としてだけでなく、「自分たちが見落としている観点はないか」を問うレビュアーとして有効でした。 ボトルネックは「コードを書く」から「何を作るか決める」に移った コーディングエージェントを使うことで、実装速度は確実に上がりました。しかし、実装が速くなると、ボトルネックは別の場所に移ります。 以前は「考えたことを形にする」のに時間がかかっていました。今は、形にすること自体は速い。すると、「何を形にすべきか」を決める部分が律速になる。 何を作るべきか。何を作らないか。仕様の曖昧さをどう解消するか。ドメイン上の正しさをどう判断するか。AIが出したコードをどう評価するか。 コードを書く時間は確かに減りました。しかし、それは「よいコンテキストを作る」「AIに適切に依頼する」「出てきたものを評価する」「ドメイン上正しいかを判断する」という時間に置き換わっています。 言い換えると、コーディングエージェントはエンジニアの仕事をなくすのではなく、エンジニアの仕事の重心を変える。手を動かす比重が減り、判断する比重が増える。新規プロダクトの立ち上げでは、この変化の意味は大きいと感じました。 特に重要なのは、実装の前段にある「何を、なぜ、どう作るか」を整理する力です。ドメインエキスパートとの議論を設計に落とす力、仕様の曖昧さを言語化する力、AIが正しく動けるだけの精度で要件を整理する力。コーディングエージェントが強力になるほど、この上流の質がプロダクトの質を決めるようになります。 まとめ 「間違えてはいけない」と「速く試行錯誤したい」。この二つの要求に対して、バクラク給与の立ち上げでたどり着いた答えはシンプルでした。速く回すべきところはコーディングエージェントで速く回し、間違えてはいけないところは人間が責任を持つ。 結果として、バクラク給与は当初のリリース予定より2ヶ月前倒しでリリースすることができました。これはコーディングエージェントの力だけで実現したものではありません。ドメインエキスパートとの仕様言語化、顧客との高速なフィードバックループ、人間が主導した計算ロジックの実装。それらすべてが噛み合った結果です。 実装が速くなった分、エンジニアの仕事の重心は「コードを書く」から「何を作るかを決め、正しさを判断する」に移っています。バクラク給与の新規プロダクト立ち上げではこの変化がより鮮明に見えました。 LayerXの「すべての経済活動を、デジタル化する。」というミッションに共感いただける方、技術の力で社会課題解決に貢献したい方は、ぜひ以下からご応募ください！ jobs.layerx.co.jp
- 生成AI
- プロダクト開発
- LLM
人からAIへのフィードバックデザインパターン
こんにちは。バクラク事業部で機械学習エンジニアをしている伊藤（@sbrf248）です。最近はオンライン上で日々流れてくる情報が膨大なので、頭の整理のため紙とペンをよく使うようになりました。GWには（手の届く範囲で）少し高価なボールペンを買ってみました。 さて、近頃はAI・LLMを組み込んだプロダクトやシステムが当たり前になってきています。 私の携わる「バクラク」でも様々なAIエージェントをプロダクトに組み込み、あらゆるバックオフィス業務の自動化を進めています。 bakuraku.jp AI・LLMを組み込む場合、最初に作ったものがそのまま完成ということはあまりなく、継続的な性能の改善が求められるケースが多くあります。特に、ユーザーごとに体験を最適化するパーソナライズされたシステムの場合は、ユーザーのフィードバックをいかにして収集し活用するかが重要です。 日々重要性が高まってきている「ユーザーのフィードバックをいかにして収集し活用するか」について、先日開催されていたHuman-Computer Interactionの学会であるCHI（CHI2026, CHI2025）の論文を中心に事例を調査してみました。このブログでは、調査した研究事例やポイントを紹介します。 全体像 LLMに限らず、機械学習モデル等を組み込むAIシステムは多々ありますが、ここではLLMを中心に考えます。LLMを組み込んだシステムは、大まかには次のような構成になると思います。 流れとしては、何らかの出力に対してユーザーからのフィードバックがシステムに与えられると、それを使ってシステムの一部が更新され、結果的に出力に反映されます。 更新する対象は、大まかに3種類に分けられます。 モデル自体 プロンプト その他（入力データや前処理、LLMの出力のフィルタ処理など） LLM本体を自前でservingするのは運用コストが大きいため、OpenAIなどのプロバイダが提供するAPIを利用するのが一般的だと思います。また、フィードバックを反映するコストを踏まえると、多くのケースで更新対象はプロンプトやその他の部分になるでしょう。 ここからは、「ユーザーから何らかの形式で与えられたフィードバックをプロンプトやその他の部分に反映し、システムの出力を改善する」問題についての研究事例を見ていきます。 研究事例 Feedback by Design: Understanding and Overcoming User Feedback Barriers in Conversational Agents [1] この論文では、会話エージェントにおけるユーザーのフィードバックの品質について調査しています。 会話エージェントはチャットを使ってAIとやりとりするプロダクトで、代表的なものにChatGPTやClaude Codeなどが挙げられます。ここで、ユーザーのフィードバックは「自然言語」として与えられます。つまり、「〜〜みたいに修正して」のような文章を入力してシステムに送信することで、それがプロンプトなどの形式でLLMに渡され、出力が更新されます。 この論文の著者は、会話エージェントのフィードバックは低頻度・低品質になりやすいと指摘しています。理由は大きく4つ挙げられています。 AIの出力が文脈・目的からずれていく: 会話エージェントが元々あったゴールを維持できず、制約を無視したり別の方向に進んだりした結果、ユーザーが「追加で説明しても直らない」と判断してしまう。 出力を検証するコストが高い: 出力にハルシネーションや存在しない引用があると、ユーザーはまず文章自体の正しさを確認しなければならず、負荷が重くなる。 モデルが曖昧さを確認しないため、ユーザーだけが説明責任を負う: ユーザーの指摘が曖昧でも、モデルが確認質問をせず修正を入れてしまうことがある。そのためユーザーは「何を・どの粒度で・どう直すべきか」を自分で言語化し続ける必要がある。 どの程度の情報を与えればよいかわからない: モデルが重要な点を落としたり、逆に不要な変更を加えたりする。それら1つ1つに対するフィードバックが難しく、「try again」のような最小限の指示になってしまう。 要するに、どこをどう直せばいいのかユーザーにとってわかりづらい状況で、かつ自由形式の入力欄だけが与えられていると、今の出力をより良くするためにどうフィードバックすればいいかをユーザーが考えて言語化する必要があります。これは負荷が大きく、結果として短く曖昧な修正やセッションのリセットなどに退避してしまうため、品質の低下やそもそもフィードバック自体を避けてしまう結果につながってしまいます。 これを踏まえて、論文では出力の一部をハイライトして「この部分が違う」と指摘できるようにする、修正前後の差分を見せる、AIがどのようにフィードバックを解釈したかを明示する、Undo/Redoを用意する、といったインターフェース設計を考案・検証し、体験の改善を確認しています。 この研究から、ユーザーの操作にある程度の型を用意し、その中で試行錯誤しやすい状況を作り出すことで、高品質なフィードバックが期待できるようになると示唆されます。 End User Authoring of Personalized Content Classification [2] この論文では、ユーザーが自身の好みに合わせてYouTubeコメントの分類器を作るというタスクについて、3つのフィードバック方式を実験的に比較しています。 Label System: サンプルとなるコメントが与えられるので、それを分類器の学習に使うかどうかを選択する。分類器は簡単なMLベースのモデルを利用する。 [2] より引用 Rule System: 用意されたインターフェースを使い、コンテンツを分類するルールを作成する。 [2] より引用 Prompt System: LLM分類器のプロンプトを調整（文章の修正やfew-shot exampleの変更）する。 [2] より引用 結果としては、Prompt Systemが最も早く高精度の分類器を作成できました。一方で、参加者はLabel SystemやRule Systemの方が、やることが明確で使いやすいと感じたようです。またRule Systemについては、特定の語句やイベントに基づくフィルタリングという観点では高い精度を出していたようです。 この結果を踏まえて著者は、それぞれのメリットを活かすハイブリッドな手法が適切ではないかと述べています。例えば、少数のLabel Exampleからプロンプトを生成したり、Rule SystemとPrompt Systemを併用した手法などが挙げられています。 この研究からも、プロンプトをユーザーが直接編集するよりは、操作にある程度の制約を設けつつ、ユーザーが迷わない形でフィードバックを送れる設計が良い選択肢となり得ることがわかります。 Promptimizer: User-Led Prompt Optimization for Personal Content Classification [3] この論文は、ユーザーに様々な形態のフィードバック方式を提供しつつ、コンテンツ分類器のプロンプトを改善する手法を提案しています。 [3] より引用 具体的には、ユーザーは初期説明の記述、誤分類された例へのラベル付け、失敗パターンの優先付けなど、複数の粒度のフィードバックを段階的に与えることができます。重要なのは、最終的に出来上がるプロンプトがユーザーにとって読める・解釈可能な形で残ることです。完全自動の最適化だと、内部でプロンプトがどんどんブラックボックス化していき、ユーザーがよくわからないままプロンプトが更新されていく状況に陥ってしまう場合があります。 論文中の実験では、ユーザーは完全自動のプロンプト最適化よりもPromptimizerの方式（人間が途中に介入できる形）を有意に好むという結果が示されています。また、YouTubeのコメント管理ツールへの組み込み実験では、3週間の実利用を通じて、ユーザーがそれぞれの目的に合った多様なフィルタを作り、運用できることが確認されています。 この研究からは、自動最適化を導入する場合でも、ユーザーが過程に関与できる余地と、結果を解釈できる出力を残すことが重要だとわかります。 Preference-Guided Prompt Optimization for Text-to-Image Generation [4] この論文も同様にプロンプト最適化の手法ですが、ユーザーは2つの選択肢からより良いものを選ぶだけというかなり限定的なフィードバック方式です。 [4] より引用 対象タスクはtext-to-imageの画像生成で、ユーザーが画像生成のプロンプトを直接書いて調整するのは負担が大きいという課題に取り組んでいます。画像生成は出力が予測しにくく、頭の中のイメージを文章に落とし込むこと自体が難しい一方で、「2つ並べたらどちらが好みか」は比較的簡単に判断できます。この性質を利用して、ユーザーには2択選好だけを返してもらい、システム側がプロンプトを自動的に更新していきます。 提案手法の特徴は、ユーザーのフィードバックを使って探索方向を狭めていく（exploit）一方で、適度に新しい方向も試す（explore）バランスを取っている点です。選好フィードバックだけでは、初期の好みに引きずられて局所最適に陥りやすいので、このバランスは実用上重要です。実験では、手動でプロンプトを書き換える場合に比べて少ない反復回数・低い認知負荷で満足のいく結果に到達できることが示されています。 ここから言えるのは、「ユーザーに言語化させずに済むフィードバック方式」も有力な選択肢になるということです。タスクによっては、自由記述や明示的なルール記述よりも、選好比較の方がユーザーの認知負荷が小さく、フィードバックを継続的に集めやすくなります。 Data-Prompt Co-Evolution: Growing Test Sets to Refine LLM Behavior [5] この論文は、フィードバックループの中でプロンプトの更新とそれを検証するテストデータの更新を同時に行う手法を提案しています。 [5] より引用 ここで扱っているのは、「プロンプトを直してもそれが過去にうまく動いていたケースを壊していないかわからない」という問題です。 従来の機械学習開発でもありましたが、テストデータを十分に整備せずプロンプトエンジニアリングを進めると、今注目しているサンプルの精度は改善したものの、実は過去問題なかったサンプルの精度が悪化する、といった問題に直面する可能性があります。 論文は、この問題に対して、テストデータとプロンプト指示を一緒に育てていくワークフローを提案しています。具体的には、ユーザーが運用中に見つけたエッジケースをテストセットに追加し、なぜその挙動が望ましいのか・望ましくないのかという根拠を明文化し、修正したプロンプトを成長したテストセットに対して評価する、というループを回します。 この研究の重要な視点は、ユーザーからのフィードバックを「単発の修正要求」で終わらせず、「テストケース＋期待挙動＋根拠」というセットで保存していくところにあります。こうしておくと、後からプロンプトを変更した際にも回帰的に検証でき、改善の積み上げが効きやすくなります。 まとめ ここまで、人間からAIへのフィードバック方式を、研究事例をふまえて紹介しました。個人的には、適切な制約を加えることで、自由記述形式よりもユーザーが使いやすく、かつ高品質なフィードバックが実現できる事例が見られたのが印象的でした。 もちろん前提として、考えているタスクの性質やシステムへの組み込み方によって、最適なフィードバック体験は異なります。その上で、（当たり前のことではありますが、）ユーザーが迷わずにフィードバックでき、それが出力の改善に納得できる形で結びつくような一連の体験を目指すべき、ということは一貫していると感じます。 LLMの表現力が高まっているからこそ、プロダクトを作って提供するだけでなく、使っていただくユーザーと共にプロダクトを磨き込めるような体験を目指していきたいと思います。 最後になりましたが、LayerXではAI・機械学習に携わるエンジニアを募集中です。ユーザー価値を第一に考えたAIエージェントの社会実装に興味のある方は、ぜひご応募ください！ open.talentio.com <a href="https://jobs.layerx.co.jp/opend
- 生成AI
- LLM
- UIデザイン
- UX
品質の言語化のススメー早期テストの原則をClaude Code Agent Skillsで実現する試み
LayerX QAエンジニアの小山です。 昨今、AIコーディングアシスタント（特にClaude Code等）の進化により、コードの実装やテスト追加のスピードが飛躍的に向上しています。しかし、AIにコードを書かせる際に「どこまで厳密なエラーハンドリングが必要か」「テストはどの程度書くべきか」といったことに迷われた経験はないでしょうか？ 今回は、バクラク事業部の品質の定義やテスト戦略などを言語化し、Claude Codeが動く際にリスクの高い箇所を守るように動いてもらい、テストも同時に生成してもらう、早期テストで時間とコストを節約する試みについてご紹介します。 ソフトウェアテストの原則「早期テストで時間とコストを節約する」 筆者はJSTQB FLの公認コースのトレーナーを15年ほどしているのですが、JSTQB FLシラバスの中に「テストの原則」として７つの原則があります。その中の１つとして「早期テストで時間とコストを節約する」というものがあります。 この原則はプロセスの早い段階で欠陥を取り除くと、後半に発生する故障が少なくなり、結果的に品質コストが削減される。そのため早い段階で欠陥を見つけるために静的テストと動的テストの両方をなるべく早い時期に開始すべきであるというものです。 これはテストの実行だけを意味するものではなく、要件のレビューや質問なども含めた活動を意味します。つまりは最もコスパが良いのは欠陥の予防であり、できるだけ早くフィードバックをするアジャイル開発とも親和性が高い原則です。 この原則をClaude Codeが動く時に適用したいと考えました。 skillsに盛り込む判断基準 どうすれば予防ができるのか？を考えると、AIが予防をするための判断基準をいくつか言語化する必要があります。本skillsでは以下の判断基準を持たせるようにしました。 目指す品質 目指す品質を判断するためのリスクと基準 自動テストのスコープ 上記を定義することで、コードを書くときやテストを書くとき、レビューをするときやテストを検討する際にコンテキストに応じてAIが以下のように思考し、動くことができます。 今目指すべき品質のゴールは何か 今守るべきリスクは何か リスクに応じてどのくらいの基準で作るか それぞれの自動テストで担保すべきスコープは何か 目指す品質の言語化 私たちが目指すゴールイメージをAIに伝えるため、目指す品質の言語化を行いました。バクラクは経済をデジタル化するプロダクト群であり、お客様のセンシティブな情報を預かるプロダクト群のため、一定以上の品質の水準をキープする必要があります。加えて高頻度でリリースを行うことも同時に目指しています。品質をキープするためにコーディング規約などさまざまな取り組みをしていますが、その一環としてプロダクトのフェーズごとに異なる「バクラク事業部が目指す品質」を定義しました。定義の内容の具体についてここでの言及は避けますが、プロダクトのフェーズによって変わる品質の側面において何を優先すべきかといった方針を定義しています。市場にリリースしてフィードバックを集めたいプロダクトのフェーズと、すでに運用状態にあるプロダクトのフェーズでは大事にするポイントが違う、ということを言語化しています。 リスクと基準の言語化 目指す品質の言語化はできたのですが、それを適用しようとするとプロダクトごとにカスタマイズをして適用する必要が出てきます。バクラク事業部ではコンパウンド戦略を取っており、複数のプロダクトそれぞれ固有のリスクが存在します。いわゆるseverityの度合いとその影響範囲をまとめたものです。このリスクにおいては特定の期間単位で振り返りながらチームでリスクの定義をアップデートする習慣が既に社内にできています。このプロダクト固有のリスクをプロダクトごとに分けてskills上で定義した上で、カバレッジの基準*1 などを決めました。 自動テストの内容やスコープの言語化 LayerXではテストピラミッド戦略として、自動テストのレイヤーごとにどのような内容を検証し、確認すべきかを定義しています。こちらの言語化は以前からしていたので新しい取り組みではないのですが、詳しくは バクラク事業部のテストピラミッド設計 - LayerX エンジニアブログ をご覧いただければ幸いです。 ※こちらのテストピラミッドについても、テストの責務の内容については更新がされており上記ブログよりも詳細な粒度での言語化ができています。 Claude Codeへの統合：AIが自らフェーズとリスクを判断し適用する 言語化した上記の情報を統合し、Claude Code Agent Skillsとして実装しました。例えばClaude Codeにタスクを依頼すると、Claude Codeは以下のように動作します。 フェーズ判断 タスクの内容から、当該プロダクトがどのようなフェーズにあるプロダクトなのかを判断し、不明な場合はHITL(Human In The Loop)でユーザーに質問する形を取ります。 リスク評価 対象の機能カテゴリなどを参考に、リスクを判断します。この機能関連の開発である旨をAIに伝えることで、当該機能のリスクレベルをAIが評価をして徹底度を判断します。全プロダクトのリスク情報を読み込むとcompaction(コンテキストの肥大化・圧縮による精度低下)を引き起こすリスクがあるため、開発対象のプロダクトのリスクのみを読む仕組みにしています。 基準の適用 判断したフェーズとリスクレベルに基づき、実装方針、テスト戦略（カバレッジ目標など）加えてコーディング規約を自動適用します。（なおコーディング規約については個別に持たせている方が多いため近いうちスコープから外す予定。） なおプロダクトの開発だけでなく、テストの計画・設計や自動テストの整備相談などにも柔軟に対応します。筆者は情報を与えた上でテスト計画を立案してもらったり、リスクの高いポイントの洗い出しをしてもらうといった使い方をしています。個人的には企画や設計の段階で「怖いポイント」を提案してもらう方がフィードバックがさらに早くなるのでおすすめです。 結果 実際にこのスキルがある状態でどのような効果が見込めるのかをskill-creatorのEvalsを使って計測をし、改善効果が見込めることを確認しました。 特定のプロダクトのリスクが高い機能を作る、とした場合にはClaude Codeは自らリスクが高いと判断し、トランザクション管理やロールバック処理、定義した基準のユニットテストカバレッジを目指した堅牢なコードを生成しました。 特定のプロダクトの○○と言う機能を作る、仕様はこのような仕様である、という情報を与えた場合にはnot with skillでのテストカバレッジは65%、with skillでのテストカバレッジは95% という結果になりました。 エンジニアは生成されたコードやテストケースを確認し、動作確認をして妥当性を判断したり、チューニングをしたりすることができます。 もちろん納得がいかない場合は別のプロンプトで動き直すといったトライ&エラーとフィードバックループを高速に回すことができます。 筆者も既にテスト計画を作ってもらったり、自動テストの整備の優先度を決めてもらったりしているのですが、今のところ悪くない実感を得られています。 終わりに AIがコードを書く時代において、人間の重要な役割は「あるべき姿を定義（言語化）すること」へとシフトしつつあります。暗黙知になっている品質の姿を言語化し型に落とし込むことでQuality HarnessとしてAIに組み込み、フィードバックループを更に早めることができるようになっています。言語化をしてみようかな、と少しでも思っていただけたなら幸いです。 モデルの性能向上に伴い、スピードと質がどんどん上がっていく世界はもう近いところにきていると考えています。その世界の中でどういったポイントを抑えることで、より良いプロダクトを作る方向に持っていけるか、今後もQAエンジニアとして真摯に考えていきたいと思います。 LayerX バクラク事業部QAでは、そんな世界を共に楽しめる仲間を募集しています。興味のある方はぜひエントリーいただければ幸いです。本記事についてもカジュアルに話したい方は是非！ 【バクラク】QAエンジニア_ポテンシャル枠 / 株式会社LayerX 【バクラク】QAエンジニア / 株式会社LayerX 【バクラク】シニアQAエンジニア / 株式会社LayerX jobs.layerx.co.jp *1:カバレッジ基準についてはCapers Jones氏のペーパーを参考に設定しています。
- 品質
- 生成AI
- テスト
AIエージェントの成功率をどう引き上げるか。Long-running taskにおけるスケーリング則と検証器の役割
こんにちは！Ai Workforce事業部FDEの恩田（さいぺ）です。 AIエージェントの進化も凄まじく、どんどん長時間のタスクをこなせるようになっています。この分野のベンチマークの第一人者であるMETRでも、最新のClaude Opus 4.6で10時間のタスクが50%の確率で完了できることが示されています（80%だと1時間）。 （出典: https://metr.org/ , 2026/4/7アクセス） とはいえ、長時間に渡るタスクは、ステップ数も膨大です。各ステップの成功確率を上げたり、リトライや失敗の原因を考え、失敗しても復帰できるような仕組みが必要になりそうです。この分野をいくつか読んだので、その中でもおもしろかった論文をピックアップし、紹介します。 100万ステップのタスクをノーミスで解く 最初に紹介するのは2025年11月に公開された Solving a Million-Step LLM Task with Zero Errors (Elliot Meyerson et al.) です。論文のタイトルにもあるように100万ステップもの長さのタスクをLLMで解こうという論文です。これほどステップ数が膨大になると、各ステップの成功確率がほぼ100%でないと、最後まで成功し切ることができません。 そこで、本論文は以下のようなプロセスを考え、スケーリング則を示しています。 （1）最小限にサブタスクへの分解。ただし、適切なサブタスクへの分解は本論文のスコープ外で、個に分解できたタスク列を所与のものとしている （2）サブタスクレベルの投票に基づくエラー訂正 （3）相関エラーを減らすためのレッドフラッグ 特におもしろいのが、セクション3.2「First-to-ahead-by-k Voting and Scaling Laws」です。First-to-ahead-by-k Votingは、1つのステップを複数回実行し、他のどの候補よりも回多くサンプリングされたものを回答とする手法です。 この手法では、各ステップの成功確率について、の場合、このプロセスを通じて正しい候補が選択される確率が計算できます。さらに任意のエラー率 に対して、この投票プロセスが確率で正しい回答をもたらすようなあるが存在することが示せます（つまりを十分小さく取れば、各ステップがほとんど100%と成功するようなが存在する）。 さらに、個のタスクすべてを成功させるために必要ながでスケールするというのがこの論文の一番の見どころです。 導出を簡単に紹介します。まず、以下の定式化、仮定を置きます。 すべてのタスクを完了するために合計ステップが必要 固有のステップあたりの成功率をとする 解析は最悪のケース（確率の正しい候補が確率の単一の代替案と競合する）を仮定 サブタスクをステップに分解可能とする 各サブタスクのアクションを決定するために票の差が必要 このとき、すべてのタスクが成功する確率が計算できます。 （論文より引用） ここで式(10)は、あるサブタスクは個のステップに分解でき、各ステップの成功確率がであることから、全てのステップが成功する確率です。これを図示したのが以下のFigure 3です。100万ステップを高い確率で成功するために、がそこまで大きくならないのは嬉しいですね。 （論文より引用） また、に対するスケーリング則だけでなく、LLMの実行コストも計算できます。 （論文より引用） 特に（サブタスクが個に分解されるので、全個のステップに分解されるワーストケース）でも、以下のようにでスケールします。 （論文より引用） 別の観点として、式(17)は（は単一ステップあたりのLLMのコストなので、は成功するために必要なコストの期待値と見なせる）に対しても線形のオーダーとなっていることもわかります。が最小化されるようなLLMを選択するというのも一つポイントです。 また、を小さくできる点と、コストもで減衰できる点で、単位ステップの成功確率を上げる施策も重要です。この論文では信頼性の低い以下2つの兆候をレッドフラグとして利用することにも言及しています。 （1）過度に長い応答 （2）誤ってフォーマットされた応答 こういった「誤りである確率が著しく高い兆候」を見つけたらリトライしてしまうのもLong-running taskの実装では重要なヒューリスティックになる可能性があります。 検証器に求められる「正誤判定」の質 次に紹介するのは、On the Self-Verification Limitations of Large Language Models on Reasoning and Planning Tasks (Kaya Stechly et al.)です。2024年2月の論文で、検証しているモデルもGPT-4と、現在の最新モデルと性能に大きな差があるので、少し割り引いて結果を解釈する必要があるのですが、内容はとても興味深いです。 先ほどの論文では、各ステップの成功確率を上げるためにFirst-to-ahead-by-k Votingやヒューリスティックな誤り検知を採用していましたが、こちらの論文では、LLMによる自己批判と、信頼できる検証器によるフィードバックでLLMが再考することの効果を検証しています。特に信頼できる検証器とは何なのか、具体例があったほうがわかりやすいので本論文で扱っている3つの題材「Game of 24」、「グラフ彩色」、「STRIPSプランニング」で紹介します。 Game of 24は、4つの数字を括弧と基本的な算術演算（加算、乗算、減算、除算）で組み合わせ、計算結果が24になる式を作る数学パズルです（個人的には車のナンバーを四則演算で10にする問題を暇つぶしでやったりします）。LLMによる自己批判は、提示された式が正しいかをLLMに判断させます。信頼できる検証器は、Pythonで24に等しいかどうかを検証させます。プログラムで計算するだけなので、24に等しいかどうかをbooleanで確実に判定できます。 グラフ彩色問題は、エッジで結ばれた隣接するどの2つの頂点も同じ色にならないように、各頂点にn色のうちの1色を割り当てる問題です。こちらもLLMには同じ色になっていないかを判定させます。信頼できる検証器は、すべてのエッジの色を確認するだけで、Game of 24と同じく機械的な正誤判定が可能です。もし、結ばれている2つの頂点が同じ色であるエッジが一つでも存在すれば不正解と判断できます。 STRIPSプランニング（Blocksworld, Mystery Blocksworld）は、離散的で決定論的な空間で実行できる計画を自動立案するものです。こちらはPDDLという計画立案用の言語を用いて、前提条件に違反することなく初期状態から実行でき、最終的にゴールに到達できる一連のアクションとして記述されます。こちらはアクションを順番に実行し、ゴールに到達できるかを検証しています。 本論文では、これら3つの題材について、n=100で検証を実施しており、結果は以下です。S.P. (Standard Prompting) が標準的なプロンプトで自己批判なしに実行された結果で、ベースラインになるものです。LLM+LLMがLLMによる自己批評です。LLM+Sound Critiqueが上記の「信頼できる検証器」によるもので、B.F. (Binary Feedback)が正解・不正解のフィードバック、F.E.F. (First Error Feedback) が最初にエラーが発生したもののみをフィードバック、A.E.F. (All Error Feedback) が誤りがあったすべてをフィードバックするものです。 （論文より引用） S.P.とLLM+LLMを見比べると、むしろLLMによる自己批判は悪影響となっていることがわかります。GPT-4でモデル自体の性能が低いことも多分に影響していると思われますが、自己批判そのものが正しくない場合、せっかく正しい回答が出力されていたのに批判することでかえって誤りを導いてしまうようです。また、誤解を招くようなフィードバックを生成することもあり、結果的に再考で正解から遠ざかってしまうことがあるとのことでした。 また、B.F., F.E.F, A.E.F.を見ると、二値のみのフィードバックと内容を含めたフィードバックでは、Blocksworld以外ではさほど差はなく、フィードバックが最初のエラーのみと全てのエラーかでも、全てのエラーのほうがむしろ性能が低下していることがわかります。 注意点として、Game of 24とBlocksworldでは、検証器としてのLLMの精度はそれなりに高く、結果としてLLM+LLMの性能低下が低く抑えられたのではと考察されています。これらを踏まえると、LLMかどうかが課題というよりは、正しいか正しくないかを正確に判定できることが重要、かつ、その中身は問わない（具体的なフィードバックであることよりも誤っていることを正しく誤っているとフィードバックできることが重要）ということが言えそうです。 また、反復回数とパフォーマンスについての結果も述べられています。 （論文より引用） 各色ごとに、信頼できる検証器が▲、LLMによる自己批判が●でプロットされていますが、▲が試行を繰り返すことで性能が上がっていくのに対し、●はむしろパフォーマンスが崩壊してしまっており、LLMによる自己批判がマイナスの結果となっています。 相互一致による正しい回答の判定 上記の論文で正しいか正しくないかを正確に判定できることが重要ということがわかりましたが、現実の問題は上記3つの題材のようにルールベースで正しいか判定できない問題もあります。そこで次に紹介したいのが、Mutual Reasoning Makes Smaller LLMs Stronger Problem-Solvers (Zhenting Qi et al.)です。こちらも2024年8月の論文のため、少し古い点は留意が必要なのですが、アイデアがおもしろかったので紹介します。 こちら論文のモチベーションは、LLMというより、SLM（Small Language Model）を活用することにあります。ただ、SLMは多くの試行を繰り返しても、低品質な推論ステップを含む解空間に陥りがちで、どの最終回答が正しいかを判断することは難しいというissueが述べられています。１つ目に紹介した論文のFirst-to-ahead-by-k Votingもを前提としているので、SLMがこの前提を満たせないとなると、複数回実行しても各ステップが正しい回答にたどり着けなくなってしまいます。 論文では、rStarという手法を提案しており、これは推論ステップをモンテカルロ木探索する手法をベースに相互一致プロセスで拡張しています。具体的には、サンプリングされた部分的な推論軌跡を2つ目のSLMに提示し、残りの推論ステップを完了させるよう促し、rStarは相互に一致した回
- 生成AI
- LLM
- AI Agent
- MLOps
Self-Maintainable CI ── Go testの失敗をClaudeで自動修復する仕組み
はじめに LayerX バクラク事業部 Platform Engineering 部 Enabling グループの shibutani です。 CIのテストが落ちたとき、開発者がやることは意外と多いです。ログを読み、原因を特定し、担当者を探し修正依頼 or 自分で修正する。これがrace conditionやflaky testのように再現しにくいものだと、対応はさらに後回しにされがちです。 今回、Go testの失敗を検知したらClaudeが自動でログを分析し、担当チームに通知し、修正PRまで作成する仕組みを構築しました。本記事ではその設計と実装を紹介します。 -race フラグの分離と、その先の課題 出発点はPull Request作成時のCIの速度改善でした。これまではPull Request作成時のCIで -race フラグ付きの go test を実行していましたが、-race フラグはGoのrace detectorを有効にするオプションで、公式ドキュメントによるとメモリ使用量5〜10倍、実行時間2〜20倍のオーバーヘッドが発生します。Pull Requestのたびにこのコストがかかり、開発者のフィードバックループを遅くしていました。 Agentic codingの普及によりPull Requestの量が増えつつある今、CIのthroughputを上げることの重要性は高まっています（参考: ハーネスエンジニアリング：エージェントファーストの世界における Codex の活用）。そこで -race フラグをmainブランチへのpush後のCIに移し、Pull Request作成時のCIは -race なしで高速に実行する構成に変更しました。 しかし、単純に分離するだけでは新たな問題が生まれます。Pull Request作成時のCIで即座にフィードバックされていたrace conditionやflaky testが、mainブランチにマージされて初めて検出されるようになります。なお、バクラクではmainブランチへのマージが即本番デプロイされるわけではなく、QAなどの工程を経てリリースされるため、mainで検出しても本番への影響を防ぐ余地はあります。とはいえ、race conditionは「稀にしか起きない」「再現しにくい」、flaky testは「もう一回走らせたら通る」という性質から、mainブランチで失敗しても対応が後回しにされがちです。放置すればrace conditionは本番で影響の大きいバグとして発現し、flaky testはCIの信頼性を徐々に損ないます。 分離によるCI高速化のメリットを享受しつつ、検知した失敗が放置されない仕組みが必要でした。そこで、失敗の分析・担当チームへの通知・修正PRの作成までを自動化するパイプラインを構築しました。 全体のフロー mainブランチへのpushをトリガーに、以下のフローで動作します。 flowchart TD A[mainへのpush] --> B["go test -race<br/>testwrapper経由"] B --> C{失敗あり？} C -- No --> D[通知なし] C -- Yes --> E[Claudeによる失敗ログ分析] E --> F{"既知のflaky<br/>のみ？"} F -- Yes --> G[通知なし] F -- No --> H[CODEOWNERSからオーナーチームを特定] H --> I[Slackにグループメンション付きで通知] I --> K{"DATA RACE<br/>あり？"} K -- Yes --> L[修正 Draft PR を作成] K -- No --> M["Flaky Mark PR<br/>+ 修正 Draft PR を作成"] ポイントは、すべての失敗を検知しつつ、既知のflaky testによるノイズは通知しないことです。通知の信頼性を保つことで、「またflakyか」と無視される状態を防ぎ、本当に対処が必要な失敗に開発者の注意を集中させます。 testwrapperによるテスト実行 通知の信頼性を保つためには、既知のflaky testと新規の失敗を区別する仕組みが必要です。 go test を直接実行する代わりに、社内で整備している testwrapper というCLIラッパーを経由して実行しています。この仕組みは Tailscaleのtestwrapper/flakytest を参考にしたもので、弊社の @upamuneが Go Conference 2025での発表 で詳しく解説しています。テスト関数内で flakytest.Mark() を呼ぶことで「このテストはflakyである」と宣言し、testwrapperがその情報を検知して自動的に最大3回までリトライします。 func TestSomething(t *testing.T) { flakytest.Mark(t, "https://github.com/org/repo/issues/123") // ... } flakytest.Mark() の第2引数にはTracking IssueのURLを渡します。なぜflaky化されているのか、いつ解消する予定かをIssueで管理する運用です。 既知のflaky testのみで失敗した場合は、testwrapperが自動リトライを試みます。リトライで通ればそのまま成功として扱い、リトライしても失敗が残った場合でもSlack通知やPR作成は行いません。既知のflaky testとして管理されている以上、対応済みと判断するためです。それ以外の失敗が含まれる場合に、次のClaudeによる分析フローに進みます。 Claudeによる分析と修復 テスト失敗を検知したら、Claudeがログ分析から修正PRの作成までを一気通貫で行います。この自動化はGitHub Actionsのカスタムアクションとして実装しており、Anthropic SDKを通じてClaude APIを呼び出しています。 ログの絞り込み CIのログをそのままClaudeに渡すのではなく、関連度の高い部分に絞り込んでからプロンプトに含めています。DATA RACEブロックが検出された場合はそのブロックを優先的に抽出し、そうでない場合は --- FAIL: の前後20行を抽出します。 ログ全体を渡すとコンテキストウィンドウを消費するだけでなく、関係のない情報にClaudeが引きずられるリスクもあります。ノイズの除去が分析精度の向上に直結するため、この前処理は重要です。 オーナーチームへの通知 失敗したテストのパッケージパスからCODEOWNERSを逆引きしてオーナーチームを特定し、GitHubチームとSlackグループのマッピングを通じてグループメンションを送ります。「テストが失敗した → 担当チームに通知が届く」という流れを自動化することで、誰にも気づかれないまま放置されるリスクを減らしています。 SlackへのCI失敗通知の例 失敗種別に応じたPR自動作成 Claudeは失敗の種別に応じて、異なるPRを自動作成します。 DATA RACEが検出された場合、Claudeがソースコードを分析し、race conditionを修正するDraft PRを作成します。 DATA RACEなしだが未マークのテスト失敗の場合は、2種類のPRを作成します。 FlakyをMarkするPR: 該当テストに flakytest.Mark() を追加し、tracking Issueも同時に作成します。このPRをマージすると、次回以降はtestwrapperが自動リトライするようになり、Slackへの通知も止まります。 Flakyを修正するDraft PR: テストの非決定性を除去する修正案をClaudeが生成します。 いずれもDraft PRはエンジニアがレビューするまでマージされません。Claudeが自動でコードを書きますが、最終的な判断は人間が行う設計です。 FlakyをMarkするPRをマージするだけで、そのテストに起因する通知が次回から止まります。これにより、対処すればするほどノイズが減り、通知の信頼性が上がっていく好循環が生まれます。 おわりに 今回構築した仕組みのポイントをまとめます。 -race フラグをmainブランチのCIに分離し、Pull Request作成時のCIの高速化とrace condition検知を両立した testwrapperと flakytest.Mark() で既知のflaky testを自動リトライし、通知のノイズを除去した Claudeによるログ分析・PR自動作成で、検知から修正提案までを自動化した CODEOWNERSの逆引きでオーナーチームにグループメンションし、通知の見落としを防いだ race conditionもflaky testも、放置されがちな問題です。原因の特定が難しく、影響がすぐには見えにくいため、目の前のタスクに押されて後回しになりがちです。この仕組みでは、検知・通知・修正提案を自動化することで対処のハードルを下げ、開発者が本来の開発に集中できる環境を目指しました。
- Go
- CI/CD
- GitHub Actions
- 生成AI
AWS re:Invent 2025現地参加レポート
こんにちは、LayerX バクラク事業部でソフトウェアエンジニアをしている Tomoaki (@tapioca_pudd) です。 2025年12月、ラスベガスで開催された 「AWS re:Invent 2025」 に、LayerXから私を含めた4人のエンジニア（@kani_b, @shirakiy0, @onsd_）で参加してきました。 Keynoteでの発表内容やセッションの解説はすでに多くの記事が出ていますし、オンラインでも視聴可能ですので、今回は「現地参加ならではの体験」を中心にご紹介します。 はじめに AWS re:Invent はAmazon Web Services（AWS）が主催する世界最大級のテックカンファレンスです。新サービスの発表が行われるKeynoteはもちろん、数千を超えるセッション、ワークショップなどが、ラスベガスの街全体を使って行われます。 aws.amazon.com 今回我々はKeynoteや聴講型のセッションは後日オンラインでも視聴できるため、参加型のワークショップを中心に体験してきました。 ゲーム形式のワークショップ AWS re:Inventはセッションだけで今回の場合3122個ありそれを5日間で実施するという、なかなかクレイジーなイベントです。セッションにはいわゆるセミナーぽいやつから、chalk talkと言われる非公開の講義スタイルのセッションや、ゲーム形式のセッションまで色々存在します。 ゲーム形式の参加型のワークショップにもGameDay, Jam, AI Leagueなどいくつか種類があり、今回私はAI LeagueとJamに参加したのでそちらの紹介をしたいと思います。 AWS AI League AWS AI League は、AI技術を用いた競技形式の学習プログラムです。一言で言うと「GameDayのAI版」のようなものですが、AWSのイベントとしては珍しく賞金が用意されており、Kaggleなどのコンペティションに似たかなり本格的な競技です。 AI Leagueの全体像 AWS re:Invent内で3つほどイベントがあり、そのうちの2つは上位に残ると決勝ラウンドに進出でき、賞金やトロフィーがもらえるという仕組みになっています。 私が参加したのは、 "Model Customization Challenge" です。簡単にいうとKaggleのようにモデルを作成し、その性能を競うというものですが、以下のような特徴がありました。 お題： 「ラスベガスの訪問者向けバーチャルアシスタント」の作成 技術要素： 軽量なAmazon Novaモデルをファインチューニングし、特定タスクにおける推論精度で、より大規模なAmazon Nova（ベースモデル）をどれだけ凌駕できるかを競う 制約条件： 今回発表されたAmazon SageMaker AIの新機能 Serverless Customization を利用してモデルを作成すること 競技時間は数時間しかなく、非常にタイトな中にいかにスコアに寄与するような改善を数多くできるかが勝負の分かれ目となるという感じでした。データセットの拡充をしながらファインチューニングを3回ほど回し、最後に最も性能が良かったモデルでハイパーパラメータをチューニングしてモデル作成を2回ほど実行したら時間切れという具合でした。 結果ですがなんと 1位になれました。2位の方は限られた時間で私の倍近くSubmitをしていた強者でしたが、何とか逃げ切りました。 ハイパーパラメータのチューニングはモデルの学習時間にかなり響くので、エポック数などをミニマムにしてデータセットの拡充に時間を多く充てたのが功を奏したかなと思います。 記念にスクショ これから参加する方へのTips： ワークショップの枠として予定されている時間の後も、コンペは数時間続きます。スケジュール表のワークショップ終了時間直後に予定を入れるとコンペに集中できないため、後ろの時間は空けておくことを強くおすすめします！ Grand Finale Model Customization Challengeのイベントでは上位3名によるGrand Finaleが行われました。Expo会場で開催されたGrand Finaleは、陽気な司会者が進行するクイズ大会のようなノリで、Twitchでもライブ配信 されました。 Grand Finaleの様子 こちらはシステムプロンプトのチューニング対決で、AIによる評価 + オーディエンス（人間）の投票 で勝敗が決まる仕組みになっており、エンタメとして非常に完成度が高かったです。 こちらは残念ながら3位と優勝を逃しましたが、緊張感のあるステージでプロンプトエンジニアリングするという稀有な体験ができて非常に面白かったです。 入賞者限定のディナーパーティの様子 予選の優勝とGrand Finale3位の副賞としてAWS クレジットをいただいたり、入賞者限定のディナーパーティに招待いただきました。ここで各国のエンジニアやAWSの中のエンジニアとAgent開発をどれくらいできてるかについて色々話しましたが、グローバルに見ても、大規模にAgentを本番提供できている事例はまだ少なく、まだまだこれからの領域であることを改めて感じました。 AWS Jam AWS Jam とはトラブルシューティングや構築課題を解く実践型イベントです。GameDayが「ターゲットへのリクエスト成功数」などでリアルタイムにスコアが変動するのに対し、Jamは「課題を正しく解く」ことに特化しており、正解すれば誰でも同じスコアが入ります。 JamにはLayerXから参加していた4人でチームを組んで挑みました。JamにもセキュリティやAIなどいろんなジャンルをテーマにしたものがありますが、我々が参加したのは'All In Jam'という全部のジャンルから出題されるというものでした。 60〜70チームが参加する中で 1位を獲得することができました。Jamには「Clue（ヒント）」機能がありますが、使うとポイントが減点されてしまうので、「ヒントは一切使わない」 という方針で取り組んだのが功を奏しました。タイム的には早く全問コンプリートしたチームがありましたが、点数で上回ることができました。 また、1つ課題を解き始めると課題に解くために要した時間のカウントが始まるので、色んな課題をつまみ食いするのではなく、集中して1つの課題をコンプリートしてから次の課題に移るのも大事でした。今回の参加メンバーは皆日頃から色んなAWSのサービスを触っていたので基本的にはそれぞれが並行して課題を解きつつ、詰まった時にはうまく協力することで時間をかけ過ぎることなく1つ1つの課題を完了させることができました。 優勝記念にパシャり All In Jamという名の通り色んなジャンルの課題が出題され、私はメインでML系の課題に取り組みましたが、内容はかなり実践的で学びの多いものでした。Bedrockを利用したchat bot作成などかなり身近なトピックも多かったです。個人的にはBedrockのGuardrailの機能など、まだ実務で利用したことがない機能に触れる機会となりとても勉強になりました。 優勝の特典としてカバンや水筒などのSwagはもちろん、このあと紹介するre:playのVIPのチケットも獲得することができました。 Chalk Talk Chalk Talkは大学の講義のようなスタイルで、AWSの開発者がドキュメントには書いてないようなサービスの仕様などを解説してくれるセッションです。規模は大体30~50人程度で、参加者もフリースタイルで質問をして双方向にディスカッションが行われます。 Chalk Talkの様子（マジでめっちゃ手書き） アクティビティ コンテスト以外でも、re:Inventならではのカルチャーを体感してきました。 re:Play Kaskade re:Inventの名物、巨大な会場を貸し切って行われる打ち上げパーティです。 今年は Beck と Kaskade がゲストアーティストとして登場しました。Jam優勝の副賞として VIPチケット をいただいていたので、快適なVIPエリアから最高のステージを楽しむことができました。 VIPのエリアはもちろんアーティストを間近で見れたり、ちょっと豪華なドリンクや食事が並ばずにゲットできたり、VIPエリア限定のアクティビティもいくつかあり貴重な体験ができました。 VIPなのですごい人がたくさんいて面白い話ができるかも...！なんて期待をしてましたが、お祭り騒ぎで仕事の話などする雰囲気ではなかったので私たちも楽しむことに専念しました。💃 金属バットであらゆるものを破壊できるイベントを楽しむ @kani_b CISO 5K Run 早朝にラスベガスのストリップ（大通り）を封鎖して行われるマラソンです。しっかりタイム計測もされ、完走メダルももらえます。朝のラスベガスの公道を走る爽快感は格別でした。 途中まで一緒に走ってたのに最後@onsd_においていかれました Amazon Fulfillment Center (LAS7) ツアー ラスベガス郊外にあるAmazonの物流拠点（LAS7）の見学ツアーに参加しました。こちらはre:inventとは直接は関係ないのですが、AWSの方々のお陰で参加させていただけることになりました。 LAS7と呼ばれる施設は、アメフトのフィールド15個分。5,000名の従業員とロボットが協働する施設です。 ロボティクスを駆使したオペレーションがとても印象的で、ロボットが棚（Pod）ごと持ち上げて作業員の元へ運んでくる様子や、荷物を梱包する処理は圧巻でした。 また、非常に面白かったのが、作業員のパフォーマンス向上施策です。ピッキングなどの作業結果がリアルタイムでゲームのように表示され、リーダーボードで競えるようになっていました。「楽しみながら生産性を高める」工夫が徹底されており、弊社のAI-BPO事業のヒントにもなると感じました。 記念写真（右端は一緒に参加したカミナシの@toriclsさん） おわりに re:Invent 2025では、新機能のインプットだけでなく、コンペティションという形での「アウトプット」を通じても多くの学びが得られた1週間でした。 特にAI Leagueでは、re:Invent期間中に発表されたばかりの新機能を題材にしており、それを即座にコンペに落とし込むAWSチームの開発スピードとセンスに感銘を受けました。また、Nova ForgeやSageMaker AIのServerless Customizationといった新機能から「モデルのチューニングの民主化」 というトレンドを強く感じ、MLエンジニア以外でも簡単にモデル開発を扱える時代の到来を実感し、よりAWSエコシステムへの期待が高まりました。
- AWS
- MLOps
- 生成AI
- イベントレポート
FDEって何するの？ 現場の泥臭さが「はずみ車」となってプロダクトを強くするリアル
こんにちは。fjm2uです。昨年の11月からAi Workforce事業部のFDE（Forward Deployed Engineer）チームでインターンさせていただいております。 この記事では、Ai Workforce事業部のFDEチームへの応募を検討している方向けに、FDEという仕事の特徴と、インターンとして実際に経験した「現場での課題解決がプロダクト改善につながる」流れを紹介します。 FDEの業務 FDEの詳細は以下の記事でも紹介されていますので、そちらをご参照ください。 note.com blog.allstarsaas.com note.layerx.co.jp 私が理解しているFDEとは、お客様の業務を理解しながら、プロダクトをテコとして短期間で顧客課題の根本解決を行い、その経験で得た知見をプロダクトの改善に繋げる職種です。 そして、そのプロダクト改善がはずみ車となり、次回はもっと早く・深く顧客課題を解決することが可能となります。 FDEに主に求められているのは、 知らないドメインへの業務理解の質（広さ、深さ、スピード） 業務の課題を根本的に解決するための提案力 提案を具体的な実装に落とし込む開発力 チーム内・お客様とのコミュニケーション能力 です。求められる幅が広い職種ですが、だからこそインターンでも日々成長を実感できる環境です。 Ai WorkforceのFDEチームの実態 現在は、FDEチームの中でも開発中心の方・顧客案件中心の方で分かれている印象です。 開発中心の方は、プロダクトでFDEが利用する部分を中心とした開発を担当されています。開発の難易度が高く、実装のボリュームも大きいです。 顧客案件中心の方は、プロダクトを利用してお客様の課題解決を行い、DS（Deployment Strategist：顧客の業務設計や導入支援を担う職種）と一緒にお客様との商談に参加します。この過程でお客様の現場に出向くこともあります。 情報管理は徹底されており、チーム内でもアサインされていない案件のデータなどは見えません。ただ、チーム内の定期ミーティングではプロダクトのTipsや改善の知見が常に共有され、常にフィードバックループが回っています。 Ai Workforce FDEチームで働く魅力 情報の質と透明性が高い 若手でも、意見を出しやすい雰囲気がある 先端技術の動向を踏まえた流動的な事業環境がある 相談しやすい人が多く、OJTで力をつけられる 実際、どんなことをしたのか ここからは、私が参加したトライアル案件を例に、FDEの仕事が実際にどう進むのかを紹介します。 FDEとDSの先輩方と、トライアル案件に参加しました。トライアル案件は、お客様が本番導入の可否を判断するために、プロダクトを実務に近い形で試す取り組みです。 やったことの概要 大量の資料から必要な情報を正確に抽出・分類し、特定形式のレポートとしてまとめるという業務でした。1件あたり数十ページに及ぶ資料もあり、業界の専門知識がないとそもそも着手すら難しい内容です。人手でやると膨大な時間がかかるうえに、分類や判定の判断には業務ドメインへの深い理解が求められるタスクでした。 やったことの詳細 以前に別のFDEの方が作った成果物をベースに、FDEとDSの先輩方と基本3人チームで案件に取り組みました。案件の中心は、精度向上のサイクル（プロンプトを調整し、その結果を評価し、また調整する）の繰り返しでした。 1. 正解データの作成 精度評価の基盤として、受領サンプル全件の正解データを手作業で作成しました。元資料から値を一つ一つ確認し、正解データ自体の不整合も発見・報告し、お客様と認識をすり合わせました。地道な作業ですが、この作業がなければ精度を測ることすらできず、案件の土台として重要でした。 2. プロンプト調整 別のFDEの方が作成したプロンプトを改善しました。資料には専門用語や独特のフォーマットが多く、文脈によって分類結果が変わりうる項目も少なくありません。同じプロンプトでも資料が変わると誤分類が発生しました。不正解パターンを一つずつ分析し、Few-shot例の追加や分類ルールの構造化を繰り返すことで、幅広い資料に対応できるよう調整していきました。 最初の時点で8割以上は正しく処理できている状態から、残りの不正解パターンを一つずつ潰して精度を引き上げていく作業です。最後の数%が最も手強く、この数%とずっと戦っていました。 3. ワークフローの修正・構築 ワークフローとは、Ai Workforce上で構築する処理パイプラインのことです。ノードと呼ばれる処理単位を組み合わせて定義し、LLMによる情報抽出・分類、Pythonによる計算処理などノードにはいくつかの種類があります。プロンプトもノードの中に組み込まれています。 情報抽出ロジックの修正、エラーハンドリング、出力項目名の統一など、案件に合わせたワークフローの修正を行いました。要件に合わせた新しいワークフローも作成しました。 4. 精度評価と自動化の試み プロンプト調整以上に時間がかかったのが精度評価でした。正解データとの照合・集計をすべて手作業で行っていたため、「調整→評価」の1サイクルに大きなコストがかかっていました。案件の途中で自動評価スクリプトの開発に着手しましたが、時間的制約もあり、案件中に使えるレベルには達しませんでした。 この課題感はプロダクトへのフィードバックとしてチーム内に共有しました。そして案件を終えた今、自動で精度評価するための仕組みを作っています。まさにFDEモデルの「現場→プロダクト改善」のループを経験しています。 5. 商談への同席 先輩方と一緒にお客様との定例会に参加しました。 案件を通じての学び 「正しい出力」から「正しい問い」へ 案件参加前の私は、ワークフローの改善は「正しい出力を出すこと」とぼんやり考えていました。しかし正解データを作成する過程で、正解の定義が一意に定まらないケースがありました。そこで「そもそも正解とは何か」をお客様とすり合わせなければ、いくら精度を追っても意味がないことに気づきました。技術だけでなく、ドメイン知識の深さがソリューションの品質を左右することを実感しました。 評価駆動という方法論 案件中の最大の反省は、精度評価の仕組みを後回しにしたことでした。手動で評価していたため、「プロンプトを修正したら再評価」というサイクルのたびに大きな時間を取られ、調整のスピードが上がりませんでした。もし最初に自動評価の仕組みを整えていれば、同じ期間でもっと多くの調整サイクルを回せたはずです。 この経験から、まず評価の仕組みを整えてから開発に入るという方法論を自分の中に持つことができました。ソフトウェア開発におけるTDD（テスト駆動開発）の考え方に近いですが、LLMを使った案件では特に重要だと感じています。通常のソフトウェアは同じ入力に対して同じ出力を返しますが、LLMの出力には揺れがあり、「本当に良くなったのか」を定量的に測れないと、調整が勘になってしまいます。だからこそ、評価の自動化が先に来るべきだったのです。 プロジェクトの中での動き方 3人チームで案件を進める中で、技術以外の動き方も学びました。商談では先輩方にフォローいただきながらチームとして対応し、定例会ではネクストアクションを毎回確認することでプロジェクトを着実に前に進める。こうした「チームの一員としての立ち回り」は、一人で開発しているだけでは得られなかった経験です。 プロダクトがあったからこそ この案件は、プロダクトなしでは到底こなせない難易度でした。LLMの不確実性をプロダクトが吸収してくれること、複雑で長い処理でも安定して動作すること。この2つがあったからこそ、少ない工数で高品質な成果物を出すことができました。 さらに、以前のFDEの方が別案件で得た知見がプロダクトに蓄積されていたおかげで、ゼロからではなく「積み上げ」の上で仕事ができました。記事の前半で書いたはずみ車を、インターンの立場でも実感できた経験でした。 トライアルの結果、お客様から 「作業時間が大幅に削減できそうだ」 という評価をいただきました。自分が関わったプロジェクトでこうしたフィードバックを直接聞けたのは、大きなやりがいでした。 さいごに 1.5ヶ月ほど、学業・プライベートでやる事が多く、お休みをいただいてました。お休みをいただく際も復帰した際も、チームの方々は温かかったです。良い環境だと思います。 復帰してみると、移動等でFDEチームのインターンが私1人になってしまっていて、なんか寂しいので募集要項を貼っておきます。以下からご連絡お待ちしております！ open.talentio.com open.talentio.com
- LLM
- 生成AI
- プロダクト開発
- インターン
OpenClaw-RLで学ぶAgentic RLの報酬設計
はじめに こんにちは！LayerXのバクラク事業部で機械学習エンジニアをしている宇都(@kuto_bopro)です。最近エージェントに関する論文を読んでいると「Self-Evolving」というキーワードを持つ論文をよく目にします。Self-Evolvingは自己進化・自己改善を意味しており、自動で性能が上がっていくAIエージェントの文脈で使われます。 A Survey of Self-Evolving Agents, Figure3より引用 arxiv.org 上記のサーベイ論文で、 Self-Evolving Agentに関して整理されており、エージェントの進化対象(What)はコンテキスト、モデル、ツール、エージェントアーキテクチャと多岐に渡っています。 従来の機械学習では更新対象はモデルパラメータのみでしたが、LLMに対してはそれ以外の選択肢があるのが特徴的です。特にコンテキストに関してはコーディングエージェントを使用する際にAGENTS.mdやSkillsを作成・更新することでAIエージェントの性能を改善することが可能であるため多くの方が馴染み深いのではないかと思います。 一方、Fine Tuningによってモデル自体を更新するアプローチは、実施コストの大きさから現状では選択肢として上がりにくいのが実情です。しかしFine Tuningには、数理的なプロセスを通じてデータから直接学習できること、またコンテキストの肥大化を抑えられることといった利点もあります。 こういった背景も踏まえ、本記事ではAIエージェントのモデルを強化学習で改善するAgentic RLというアプローチについて、OpenClaw-RLというプロジェクトを題材に紹介します。 github.com Agentic RLとは Agentic RL（エージェント型強化学習）とは、AIエージェントが環境と対話しながら、強化学習によって自身の性能を継続的に向上させる手法です。強化学習は、エージェントが環境と試行錯誤を繰り返しながら、得られる報酬が最大になるよう行動を学習していく機械学習の手法であり、近年のLLMの推論能力やエージェント性能の向上を支える中心的な技術となっています。 AIエージェントの振る舞いを強化学習の枠組みで整理すると、次のように定義できます。 状態: コンテキスト（過去の行動・観測の履歴） 行動: エージェントの応答（テキスト生成、ツール利用など） 観測: ユーザーの応答や環境からのフィードバック（エラー情報など） 報酬: 各行動に対するスコアリング OpenClaw-RLのコンセプト コーディングエージェントやパーソナライズエージェントを利用する際、対話中に発生するユーザ応答や環境フィードバックは、個人利用の観点では(メモリ保存を除いて)多くの場合改善には利用されずに捨てられます。 この課題に対してOpenClaw-RLは、対話ログから学習信号を得て、非同期のAgentic RLを実行することで「対話するだけでモデルが賢くなる」という仕組みを設計しています。 なお、名前にある通りAIエージェントとしてOpenClawを動かす想定で設計されたものになっています。OpenClawについては以下を参照ください。 openclaw.ai OpenClaw-RLの概要を表したのがこちらの図です。 OpenClaw-RLの概略図 OpenClawのようなAIエージェントの推論を個人環境やクラウド環境で動かす想定 AIエージェントとの対話を行うと、そのログをリアルタイムに強化学習サーバに連携し非同期で強化学習を行う 更新されたモデルパラメータを学習サーバからAIエージェントが実際に動作する推論環境に連携する 対話ログからどう学習信号を得るか OpenClaw-RLの論文では非同期強化学習や汎用エージェントなどいくつか面白いトピックはありますが、今回はパーソナライズエージェント向けに実際の対話ログからどのように学習信号を取得するかをテーマに紹介します。 事後学習との違い 現在私たちの身の回りで利用されるAIエージェントの多くは事後学習の段階でAgentic RLが行われています。この時よく利用されるのが、正解がある数学タスクやテストやコンパイラによる検証が可能なコーティングタスクに対して強化学習を行うというものです。これはRLVR(Reinforcement Learning with Verifiable Rewards)と呼ばれています。 こういった事後学習で使われるデータセットは、あらかじめ検証環境や報酬が整備されたものです。一方、今回対象とするのはユーザとのインタラクティブなやり取りが含まれる実際の対話ログです。このようなリアルタイムの対話データを用いる場合、ルールベースで明確な正解を定義するのが難しいケースも多く、報酬をどう設計するかが重要なポイントとなります。 OpenClaw-RLの報酬設計 OpenClaw-RLでは２つの学習信号を利用しています。 ①Binary報酬 Binary報酬の概略図 こちらはフィードバックをもとにエージェントの行動の良し悪しを判定する学習信号として機能します エージェントの行動の次に得られた観測（ユーザ応答・環境フィードバック）を評価用LLMに渡す 観測に対し評価用LLMで以下のいずれかを複数回出力させ多数決で報酬を決定 +1: 良い 0: 何もなし -1: 悪い つまりAIエージェントの行動によって発生した観測に対してAIのフィードバックをもとに報酬を生成するというものです。このように検証可能でないタスクに対する報酬設計としてAIのフィードバックによる報酬生成は他の論文でも採用されており有力な手段の1つです。OpenClaw-RLの工夫点として1回のフィードバックだと報酬が不安定になることから多数決を取る方法が採用されています。一方で報酬が評価用LLMの性能に依存する、ユーザ応答のたびに評価用LLMの推論を裏で回す必要があり推論コストがかかるという課題はあります。 ②蒸留報酬 蒸留報酬の概略図 こちらはフィードバック情報そのものを学習信号として利用します エージェントの行動の次に得られた観測（ユーザ応答・環境フィードバック）を評価用LLMに渡す 評価用LLMに観測がエージェントの行動を改善する上で有益かどうかを+1, -1の2値で判定させる※1 有益と判定した場合に以下の2つのモデルを用意する 教師モデル：コンテキストに観測を加えてエージェントの行動を出力 生徒モデル：コンテキストに観測を加えずエージェントの行動を出力(元のエージェントの行動そのもの) 生徒モデルの出力を教師モデルの出力に近づけるように報酬※2を決定 ※1 Binary報酬はエージェントの行動をLLMで評価している一方、蒸留報酬はフィードバックの有益さをLLMで評価という違いがある ※2 厳密にはトークン単位のアドバンテージ ①のBinary報酬はエージェントの応答全体に対して離散的な報酬が与えられますが、蒸留報酬はトークン単位で教師モデルから確率分布の違いに応じたフィードバックが与えられます。そのため、観測に具体的な指示が含まれている場合に、その指示を踏まえた行動をモデルに直接学習させられるという意味で、より密なフィードバックといえます。 余談ですが、通常の蒸留は大きな教師モデルから小さな生徒モデルへ性能を引き継ぐ用途で使われることが多いです。今回の場合はモデル自体は同じで、コンテキストの有無によって教師と生徒を分けています。これは自己蒸留やコンテキスト蒸留と呼ばれる手法の1つで、別モデルを用意しなくて済む手軽さもあり、最近の論文でもよく見かける手法です。 学習時の注意点 ここまでOpenClaw-RLで利用されている報酬について説明しましたが実際にこれらの報酬を元に学習をする上での注意点もあります。その1つがGRPOアルゴリズムはそのまま利用できないという点です。 LLMに対する強化学習のアルゴリズムではGRPOがよく採用されています。GRPOは1つのプロンプトに対して複数の推論（rollout）を実行し相対評価を行うことで、従来主流だったPPOで必要とされていた価値評価モデルを不要にできるのが特徴です。 しかし実際の対話ログを使う場合、ある行動に対して得られるユーザ応答（観測）は1つだけです。LLMの推論自体は裏で複数回実施できるものの、その行動に対する観測は1つしか得られないため、学習に利用可能なrolloutも実質1つとなります。そのため複数のrolloutを前提とするGRPOはそのままでは使えません。OpenClaw-RLでは報酬をそのまま相対評価値として使う簡易的な方法を採用しており、この点については改善の余地がありそうです。 おわりに OpenClaw-RLを通して、対話ログからAgentic RLをする場合の学習信号設計について紹介しました。今回は割愛したのですが、非同期の強化学習によるリアルタイムのモデル更新というコンセプトも面白いなと感じたので興味がある方は原論文も読んでみてください。 arxiv.org 今回はモデル更新を前提とした話題でしたが、多くの場合単純なパーソナライズや性能向上はコンテキスト・メモリ管理の方がシンプルで効果的な場面が多いというのが実情だと思います。ただし冒頭でも挙げた自己進化という方向性は今後のAIエージェント開発においてもますます重要になっていくと思いますし、その選択肢の1つとして今回紹介したAgentic RLも現実的な手段として注目されていくのではないでしょうか。 個人的にも興味のある領域なので引き続き動向をウォッチしていきたいと思います。 最後になりましたが、LayerXでは機械学習エンジニアを募集しております！ ユーザ価値を第一に考えたML/AIエージェントの社会実装を高速に進めておりとても面白い環境です！ 興味ある方はぜひこちらからご応募ください。 open.talentio.com
- 生成AI
- 強化学習
- LLM
言語処理学会第32回年次大会(NLP2026) 参加レポート
こんにちは、Ai Workforce事業部 プロダクト部 FDEグループ エンジニアの堤(@ozro_223) です。この記事は2026年3月9日〜13日に栃木県宇都宮市のライトキューブ宇都宮で開催された 言語処理学会第32回年次大会(NLP2026)の参加レポートです。 LayerXとしては、昨年に引き続きプラチナスポンサーとして協賛させていただき、スポンサーブースの出展と非公式で懇親会を開催しました。 NLP会場告知看板プラチナスポンサーとしてLayerXのロゴが掲載されている様子 スポンサーブースの様子 スポンサー展示では、学生・研究者・企業の方など、多くの方にお立ち寄りいただきました。ありがとうございます。 展示ブースでは、Bakuraku と Ai Workforce の2つのプロダクトを紹介しました。 BakurakuやAi Workforceの開発を通じて私たちが目指すAIエージェント時代のビジョンと、その実現に向けた開発の取り組みをご紹介しました。 また、私はAi Workforce事業部のエンジニアとして、最近話題のFDE（Forward Deployed Engineer）やDS（Deployment Strategist）の役割・働き方について多くお話しました。 ブースの様子 自然言語処理やLLMに深く携わる学生・研究者・エンジニアの方々と直接話せる機会は貴重で、私たちのプロダクトが取り組む課題について、技術的な知見を深く交換できる機会となりました。 懇親会・交流 3月10日の夜はディナー懇親会、3月11日のランチタイムはランチ懇親会をLayerX主催で開催しました。 NLPの研究トレンド、企業でのAIエージェント活用事例、エージェント時代の働き方について、参加者と活発に意見交換しました。 転職理由、社内でのAIエージェント活用方法、フレックスな働き方といった、外部からは見えにくいLayerXの内側についても話せ、会社をより深く知ってもらえる機会となりました。 一般発表 今回聴講した発表のなかから、個人的に面白く、印象に残ったものをピックアップして紹介します。 [P4-1] 訓練不要レビュー生成のための会話形式プロンプト レビュー履歴が少ないユーザーを模倣したレビュー文生成において、過去レビューを1つのプロンプトにまとめて与えるより、user/assistantの対話形式に再構成して与えるほうが、対象ユーザーらしいレビューをより高精度に生成できることを示した論文です。 改めて「何を与えるか」だけでなく「どういう構造で与えるか」が重要だと実感しました。今回はOpenAI APIのChat Completionsを使用して実験をしたと伺いましたが、OpenAIの Responses API は会話状態の保持やマルチターンでの文脈再利用を前提にした設計になっているため、過去履歴参照が重要なユースケースでは、こちらのほうがより効果的になるかもしれないと思いました（既にResponses APIを使用した実験を進めているようでした）。 [B3-4] Lost in the Files：長コンテキスト LLM による複数専門文書からの網羅的情報抽出とその限界 長コンテキスト対応のマルチモーダルLLMに複数のPDFを直接入力した場合、単一文書では高精度に情報抽出できても、複数文書では特に入力列の中間に置かれたファイルの情報が抜け落ちやすく、PDFのファイル入力でも Lost in the Middle に近い現象が起こることを示した研究です。 Ai Workforce は PDF・Excel・Word などのドキュメントを入力として扱うことが多く、この示唆は非常に勉強になりました。これまで OCR → テキスト入力の文脈で Lost in the Middle を意識してきましたが、ファイル入力でも中間ドキュメントの情報が抜けやすいと示された点は重要で、プロダクト設計に活かせる気づきでした。 [B2-3] 機械文としての検出されやすさと文章の品質は両立する LLM生成文の「機械文として検出されやすさ」と「文章品質」は必ずしもトレードオフではなく、両者を同時に高める学習フレームワークD-PUPPETを提案し、その有効性を示した研究です。 機械っぽい表現を検出・修正するだけでは、機械文らしさは下がってもタスク性能まで落ちてしまう可能性がある、という問題意識からスタートしている点がまず面白いと感じました。DPOの学習に品質指標（metrics）の良し悪しも組み込むことで、自然さと性能の両方を同時に改善できると示している点が興味深かったです。 [B2-17] ハルシネーションから学ぶ：内部表現への介入によるハルシネーション抑制 従来は2つのLLMを同時に動かしていたanti-expertによるハルシネーション抑制を、単一モデルの内部表現への介入で実現する in-model anti-expert（IMAE）を提案し、精度を保ちながら推論コストとレイテンシを改善した研究です。 「嘘をつく方向のモデルをあえて作り、そのモデルの出力確率をペナルティとすることでハルシネーションを抑制する」という発想自体を初めて知り、とても勉強になりました。そのアイデアを関心のみで終わらせず、単一モデル化によって実運用しやすい形に最適化している点が特によく、精度だけでなくコストやレイテンシまで含めて改善を目指す姿勢は実務的で非常に参考になりました。 さいごに ChatGPTの登場以降、NLPの分野は加速度的に人気が高まっており、今回のNLP2026も非常に大盛況でした。個人的には、日本語特有の課題に着目したニッチな研究が多い点が、他の学会とは異なる魅力だと感じています。 来年以降も、NLPの益々の発展にLayerXとして引き続き貢献できればと思います。 LayerXのインターンシップや新卒、中途採用にご興味のある方は、下記リンクをご覧いただきぜひお気軽にご応募ください！ jobs.layerx.co.jp また、FDEや新卒スタートアップというキャリアについて興味のある方は是非以下のサイトからカジュアルにお話しましょう！ jobs.layerx.co.jp
- 生成AI
- LLM
- AI Agent
- 自然言語処理
AIエージェントを強くする『合成データ』作成のニッチなTips集
0. はじめに LayerX Ai Workforce事業部でR&Dチームマネージャーの澁井（しぶい）と申します。 実業務でLLMやAIエージェントを活用するときに頻繁に課題になることとして、作ったLLM/AIエージェントシステムを評価するデータが足りない、ということがあります。こうした課題に対処するため、LLMやAIエージェントを用いて合成データを作ることは一般的なプラクティスと言えます。しかし、必要な品質の合成データを大量かつ多様に作ることは相応に難しく、エンジニアリングが伴います。 本テックブログでは、合成データの作り方に関するTips集を紹介します。このTipsが読者の合成データ作成に貢献できると幸いです。 1. 合成データとは何か？ AIエージェント時代に注目される理由 合成データ（Synthetic Data）とは、実データの統計的特性や意味構造を保ちながら、プログラムやモデルによって人工的に生成されたデータのことです。従来は GAN やルールベースの手法が主流でしたが、LLM の登場で状況が一変しました。 AIエージェント時代に注目される理由は3つあります。 第一に、エージェントの評価データが慢性的に不足している点です。ツール呼び出しの成否判定、マルチステップ推論のゴールドラベルなど、エージェント固有のベンチマークは実データだけではカバーしきれないことが多いでしょう。たとえば「契約書の条項抽出」タスクでも、世の中には多様な種別の契約書（売買契約書、ライセンス契約書、業務委託契約書、賃貸借契約書、秘密保持契約書、等々）が多様なフォーマットで存在し、網羅的なパターンの実データを用意することは工数がかかります。合成データであれば網羅的に自動生成できます。 第二に、LLM 自体が合成データの生成器として極めて優秀であるという点です。自然言語の多様性、ドメイン知識の埋め込み、フォーマットの柔軟性――これらを一つのモデルで同時に扱える生成器は LLM 以前には存在しませんでした。 第三に、AIエージェントのアーキテクチャそのものが合成データパイプラインと相性が良い点です。Planner → Generator → Validator のようなマルチエージェント構成は、そのままデータ生成ワークフローに転用できます。つまり「エージェントを作る技術」と「エージェントのためのデータを作る技術」が同一のスキルセットで完結します。 2. Pydantic × LLM で型安全な合成データを生成 合成データの品質を安定させるうえで最も効果的なのが、出力スキーマを Pydantic モデルで厳密に定義し、LLM の出力をバリデーションにかけるパターンです。 2.1 基本構成 from pydantic import BaseModel, Field, field_validator from openai import OpenAI import json class SyntheticTicket(BaseModel): """カスタマーサポートチケットの合成データスキーマ""" ticket_id: str = Field(pattern=r"^TKT-\d{6}$") category: str = Field(description="問い合わせカテゴリ") severity: int = Field(ge=1, le=5) customer_message: str = Field(min_length=20, max_length=500) expected_action: str = Field(description="エージェントが取るべきアクション") requires_escalation: bool 2.2 Responses API の Structured Outputs で型安全を API レベルで保証する 従来は LLM の出力を自前でパースし、バリデーションエラー時にリトライするループを書く必要がありました。しかし OpenAI の Responses API が提供する Structured Outputs 機能を使えば、API 側がスキーマ準拠を保証してくれます。 Pydantic の BaseModel をそのまま text_format パラメータに渡すだけで、レスポンスがパース済みのオブジェクトとして返ってきます。 from pydantic import BaseModel, Field, field_validator from openai import OpenAI client = OpenAI() def generate_ticket(prompt: str) -> SyntheticTicket | None: """Responses API + Structured Outputs による型安全な生成""" response = client.responses.parse( model="gpt-5.2", input=[ { "role": "system", "content": ( "あなたは合成データジェネレータです。" "指示に従い、リアルなカスタマーサポートチケットを生成してください。" ), }, {"role": "user", "content": prompt}, ], text_format=SyntheticTicket, ) # モデルが安全性の理由で拒否した場合のハンドリング if response.output_parsed is None: # refusal が返された場合 for item in response.output: if hasattr(item, "refusal") and item.refusal: print(f"モデルが生成を拒否しました: {item.refusal}") return None return response.output_parsed # 使用例 ticket = generate_ticket( "日本語で、配送遅延に怒っている顧客のチケットを生成してください。" "severity は 4 以上にしてください。" ) if ticket: print(ticket.model_dump_json(indent=2)) 2.3 Tips: スキーマ設計のコツ Field(description=...) を必ず書く: LLM はスキーマの description フィールドを手がかりに出力を生成します。説明が丁寧なほど出力品質が上がります。 Literal 型で選択肢を制限する: category: Literal["billing", "shipping"] のように書くと、JSON Schema 上で enum として表現されるため LLM が逸脱しにくくなります。 ネストモデルを活用する: 複雑なデータは BaseModel をネストして構造化しましょう。フラットな JSON よりも LLM が構造を理解しやすくなります。 model_json_schema() の出力をそのまま渡す: 手書きでスキーマを説明するよりも、Pydantic が生成した JSON Schema を直接プロンプトに含めるほうが正確です。 3. 答えから合成データを作る ― 逆方向生成 合成データ生成でもっとも見落とされがちで、かつ強力なテクニックが逆方向生成です。 3.1 なぜ「答え」を先に作るのか 通常の発想では「ドキュメントを作り、それに対する正解を作る」と考えます。しかし、LLM がドキュメントを生成した後に正解ラベルを抽出しようとすると、ドキュメントの曖昧性によって正解が一意に定まらないケースがあります。 逆方向生成では、先に「処理結果（正解）」を確定させ、その正解が自然に導出されるようなドキュメントを後から合成します。 3.2 具体例: 請求書データの抽出タスク 【Step 1: 正解の定義】 { "vendor_name": "AAAAAAA", "invoice_number": "INV-2025-003847", "total_amount": 1254000, "tax_amount": 114000, "line_items": [ {"description": "クラウド基盤構築費", "quantity": 1, "unit_price": 800000}, {"description": "運用保守（月額）", "quantity": 3, "unit_price": 120000}, {"description": "セキュリティ監査", "quantity": 1, "unit_price": 94000} ] } 【Step 2: 正解に整合するドキュメントの合成】 → LLM に「上記の構造化データが抽出結果として正しくなるような 請求書のテキスト（レイアウト崩れ・表記ゆれを含む）を生成せよ」と指示。 3.3 プロンプト設計のポイント 逆方向生成プロンプトでは、ドキュメントに意図的なノイズを注入する指示が鍵になります。 以下の構造化データから、現実の請求書テキストを生成してください。 制約: - 金額表記は「¥1,254,000」「1,254,000円」「￥1254000」のいずれかをランダムに使用 - 品目名は微妙に異なる表現（例:「クラウド基盤構築」→「クラウドインフラ構築作業」）を含めてよい - 会社名にはふりがなや英語表記を併記するケースを20%の確率で含める - フッターに無関係な定型文（振込先情報、免責事項など）を追加する - 行の順序は元データと異なってもよい このアプローチの利点は「正解ラベルの正確性が保証された状態で、入力側の多様性だけを自由に拡張できる」ことにあります。 3.4 応用: 要約タスクへの適用 要約タスクでは「理想的な要約」を先に定義し、その要約が正当化される元文書を合成します。 Step 1: 要約 = "2025年Q1の売上は前年比12%増。主因はAPAC市場でのSaaS契約増加。" Step 2: → 上記要約の根拠となるような四半期報告書のセクションを生成。 副次的な話題（人事異動、設備投資）も含めて情報量を膨らませる。 4. 異常検知モデル向けに「異常パターン」だけを狙って合成するエージェント設計 4.1 課題: 正常データは豊富だが異常データが極端に少ない 異常検知では、正常:異常 = 99:1 以下の極端な不均衡が一般的です。単純に「異常データを作って」と LLM に頼むと、パターンが単調になりがちでしょう。 4.2 分類体系ドリブンデータ合成 有効なのが、異常パターンの分類体系（Taxonomy）を先に設計し、それに基づいて生成を制御する方法です。そのために以下のように各フェーズでエージェントを用意します。 4.3 Taxonomy Agent による異常カテゴリの自動設計 Taxonomy Agent の役割は、ドメイン知識と正常データの特徴を入力として、「どんな種類の異常がありえるか」を体系的に洗い出すことです。人間が手動でカテゴリを設計するとどうしても既知の異常に偏るため、LLM のドメイン知識を活用して分類木を自動生成させます。もちろん、人間の既知の情報を補足として与えることで、より品質の高い分類木が作れるでしょう。 TAXONOMY_PROMPT = """ あなたは{domain}ドメインの異常検知の専門家です。 以下の正常データの特徴量サマリを分析し、 発生しうる異常パターンの分類木（Taxonomy）を設計してください。 正常データの特徴: {normal_stats} 以下の軸で異常を分類してください: 1. 値の異常（範囲逸脱、統計的外れ値、物理的にありえない値） 2. 時間の異常（頻度変化、周期性の崩壊、時系列の逆転） 3. パターンの異常（通常と異なるシーケンス、欠損パターン） 4. 関係性の異常（フィールド間の相関崩壊、因果関係の逆転） 5. 複合異常（上記の組み合わせ） 各カテゴリについて以下を出力してください: - category_name: カテゴリ名 - description: どのような異常か - subtypes: 具体的なサブタイプ（最低3つ） - generation_hint: この異常を生成する際の具体的な指示
- LLM
- 生成AI
- Pydantic
- データセット
- AIエージェント
DEIM2026参加レポート
こんにちは、機械学習エンジニアの宇都(@kuto_bopro)です。 この記事は2026年2月28日 ~ 3月5日にオンライン・オンサイト（兵庫県神戸市）のハイブリッドにて開催されたDEIM2026 第18回データ工学と情報マネジメントに関するフォーラム（第24回日本データベース学会年次大会）の参加レポートです。 LayerXとしては、昨年に引き続きプラチナスポンサーとして協賛させていただき、企業ブースの展示と技術報告に参加させていただきました。 https://pub.confit.atlas.jp/ja/event/deim2026 今年は 2月28日〜3月2日にオンラインによる一般発表セッションの後、 3月4日と5日に兵庫県神戸市にある神戸国際会議場・展示場で開催されました。 神戸のオンサイトでは、チュートリアルやスポンサーによるランチョンセミナー、インタラクティブセッション (ポスター発表) などが行われました。 DEIM会場告知看板 技術報告 前半日程でオンラインで実施された一般発表セッションでは、技術報告として『AIエージェントによる「業務の自動運転化」に向けた技術的挑戦と実践例』というタイトルで機械学習エンジニアの松村(@yu__ya4)が発表いたしました。 https://pub.confit.atlas.jp/ja/event/deim2026/presentation/8B-05 発表では、「気づいたら仕事が終わっている」という体験を届けるためにLayerXが提供するバクラクで実際に導入されているAIエージェントの開発事例やその実現に向けた技術的な課題についてお話しさせていただきました。 登壇の様子 スポンサー企業展示 展示ブースでは学生や企業の方など多くの方にお立ち寄りいただきました。 LayerXが提供するバクラクとAI Workforceのプロダクト紹介を通して、我々が目指す世界やそのために現在どういう取り組みをしているかというお話をさせていただきました。また学生向けに毎年実施しているサマーインターンシップについても案内をさせていただきました。 ブースの様子 インタラクティブセッション 後半日程のオンサイトではインタラクティブセッションとしてポスター発表が行われていました。会場を見渡すとLLMを扱った研究が多く並んでおり、中には「AIエージェント」をキーワードに掲げる発表も一部あり、研究コミュニティの関心が時代の流れとともに変化しつつあるのを実感しました。 ここでは執筆者である宇都が聴講したポスターセッションから面白かったものをピックアップして紹介します。なおポスター画像は発表者からの承諾を得て撮影・掲載しております。 文書拡張プロンプト最適化に基づく同時更新文書検索 概要 ある文書を更新した際に関連する他の文書も同時更新するための文書検索手法としてLLMによる文書拡張と自動プロンプト最適化を組み合わせた検索手法を提案 面白かった点 今回は日本法とEU法の法改正を題材にした研究でしたが、同時更新文書検索は社内ドキュメント更新など応用範囲も広く面白い題材だなと思いました。 また提案手法に関してもLLMによる文書拡張に留まらず、プロンプトの自動最適化まで踏み込んで取り組んでいる点が印象的でした。 利用しているプロンプト最適化手法についても聞くことができ勉強になりました。 ペルソナRAG: ペルソナ類似性に基づくパーソナライズ仮想レビュー生成 概要 レビュー履歴を元にしたペルソナ情報をLLMによって生成し類似ペルソナのレビュー検索結果を元にユーザのレビュー内容を予測する手法を提案 面白かった点 年齢や性別といったユーザ属性ではなく、ユーザのレビュー履歴からそのユーザが気にする観点や好みを抽出して利用している点が興味深かったです。 レビュー結果の要約などは既存サービスでも増えてきていますが、レビュー内容のパーソナライズ化はあまり見ないため着眼点としても面白いなと思いました。 意味埋め込みを用いた連邦型知識グラフ問い合わせにおける情報源選択 概要 分割された複数の知識グラフからグラフ内のエンティティの意味埋め込みを元に問い合わせに対応する知識グラフを選択する手法を提案 面白かった点 計算量を抑える工夫として、埋め込みで知識グラフをクラスタ化した上でクラスタ重心と問い合わせクエリとの類似度をとっているのは説明を聞いてなるほどと勉強になりました。 知識グラフの検索はLLM時代において重要な技術の1つだと思うので今後の研究が楽しみだなと感じました。 Model Context Protocolを用いた二層知識継承による建築制約を持つ屋内シーン生成の自律的品質保証 概要 自然言語による3Dオブジェクト生成タスクにおいて幾何学的ハルシネーションを改善するためにMCP(Model Context Protocol)と静的・動的の知識データベースを用いた推論手法を提案 面白かった点 3次元の建築物の情報を2次元画像としてLLMに与えるのではなく数値的に検証可能な3次元のjsonオブジェクトとして与える点、ユーザとのやりとりから知識データベースを動的に更新していく点が面白いなと感じました。 本研究で扱っているようにフィードバックループによって利用回数を重ねるごとにどんどん賢くなる仕組みは私たちが取り組む機械学習やAIエージェント開発においても重要な観点だなと再認識しました。 BoF オンサイト1日目の夕方にはBoF(Birds of a Feather)と呼ばれる学生主催のワークショップが開催されていました。 今年は「研究ライフをN倍ブチ上げるためにキミたちはどうしますか」というメインテーマのもと、 各テーブルごとに下記のようなお題が与えられ、テーブル内の学生同士で意見を交わしていました。 教授とのコミュニケーションどうしてる？ 後輩の面倒ってどのくらい見れてる？ AIをどう研究に活用している？ *(その他多数) この時間は食事やお酒も提供されてリラックスした雰囲気の中行われており、学生同士の会話の中には笑い声なども広がっているのが印象的でした。 地元の日本酒も提供されていました ディナー懇親会 オンサイト1日目の夜にはLayerX主催のディナー懇親会を開催しました。事前の申し込みやブース展示で興味を持っていただいた10名以上の学生とLayerX社員で食事をしながら交流をしました。 https://layerx.connpass.com/event/384917 この懇親会では、学生が取り組んでいる研究やコーディングエージェントの活用法について話題が上がり、研究への積極的な取り組みが伺えました。またLayerXへの入社理由やAIエージェント開発の現状、インターンシップの内容など、会社についても興味を持ってもらえる良い機会となりました。 スポンサー賞 オンサイト最終日はスポンサー賞授賞式も行われ、産学連携副委員長を務める松村が司会を担当しました。スポンサー各社が選出した発表チームへ、それぞれ賞の授与が執り行われました。 スポンサー賞授賞式の様子 さいごに 登壇の機会をいただき、LayerXが目指す世界や機械学習技術そしてAIエージェントが切り開く未来について広くお伝えすることができました。 また、企業展示ブースでは多くの方と直接お話しすることができ、非常に有意義な学会参加となりました。 学会の運営に携わってくださった方々に感謝いたします。 来年も開催されるDEIMのますますの発展に、LayerXも引き続き貢献できればと思います。 LayerXのインターンシップや新卒採用にご興味のある方は、下記リンクをご覧いただきぜひお気軽にご応募ください！ jobs.layerx.co.jp
- 生成AI
- LLM
- AIエージェント
- RAG
NLP2026（言語処理学会第32回年次大会）にプラチナスポンサーとして協賛します
こんにちは、バクラク事業部で機械学習エンジニアをしている伊藤です。 LayerXは、NLP2026（言語処理学会第32回年次大会）にプラチナスポンサーとして協賛します。 イベント概要 当社の参加内容 スポンサー展示 懇親会 協賛の背景 おわりに 関連記事 イベント概要 NLP（言語処理学会年次大会）は、言語処理学会 が年に1度開催する、自然言語処理および関連分野の研究発表や交流の場として国内最大規模のイベントです。全国のアカデミアや企業からNLPの研究・開発に従事している人々が集い、研究発表と活発な議論がなされる場です。LayerXからはバクラク事業部・Ai Workforce事業部を含む数名のメンバーで現地会場に参加させていただきます。 項目 内容 開催期間 2026年3月9日（月）〜3月13日（金） 開催場所 ライトキューブ宇都宮（ハイブリッド開催） 主催 一般社団法人 言語処理学会 公式サイト NLP2026 当社の参加内容 スポンサー展示 スポンサー展示では、業務の完全自動運転への取り組みや、LayerXのAI・機械学習に関する技術的な取り組みをご紹介します。P会場26までぜひお立ち寄りください。 NLP2026 展示ブース配置図 懇親会 現地参加の方を対象に、カジュアルに交流できる懇親会を開催します。 ランチ懇親会（学生限定） 日時: 3月10日（火）・3月11日（水）各日 12:50〜13:50 予定 参加費: 無料 定員: 各日 9名（応募多数の場合は抽選） 申し込み: 1日目: LayerXランチ懇親会 NLP2026（3/10）| connpass 2日目: LayerXランチ懇親会 NLP2026（3/11）| connpass ディナー懇親会（学生・社会人対象） 日時: 3月10日（火）19:00〜21:00 予定 参加費: 学生1,000円 / 社会人6,000円 定員: 16名（応募多数の場合は抽選） 申し込み: LayerXディナー懇親会 NLP2026 | connpass 協賛の背景 LayerXでは、広くAI・機械学習技術を活用しつつ、"業務の完全自動運転"を実現すべく複数の事業を推進しています。バクラク事業部では、稟議、経費精算、法人カード、請求書受取・発行、勤怠管理などの業務が「気づいたら終わっている」体験を届けるため、「Bakuraku」で提供されるAIエージェント群を開発、運用しています。Ai Workforce事業部では、エンタープライズ企業が業務ごと・組織ごとに合わせた形で、AIエージェントを「毎日の仕事」に組み込むための汎用AIプラットフォーム「Ai Workforce」を開発、提供しています。 また、我々LayerX の掲げる行動指針である「Bet AI」や「徳」の観点から、アカデミアやOSSコントリビューターの成果から一方的に恩恵を受けるだけでなく、アカデミアや技術コミュニティへの貢献を継続して行っていきたいと考えています。 LayerX行動指針 その上で、国内でも最大級の規模で自然言語処理分野の研究発表、議論、交流がなされるNLPへと協賛することは、今後より社会実装も進み重要度の高まっていくであろう自然言語処理分野の技術発展への貢献となり、自然言語処理を最重要技術の1つとして開発を進めるLayerXにとっても社会にとっても大変有益なことであると考えており、今回プラチナスポンサーとして協賛させていただくこととしました。 おわりに NLPには今回で4回目の協賛となります。当日は多くの方とお話しできることを楽しみにしています。よろしくお願いいたします！ 関連記事 bakuraku.jp speakerdeck.com speakerdeck.com
- 生成AI
- 自然言語処理
- 機械学習