みなさんこんにちは！AI戦略推進グループ (AIXG) の岸波と申します。入社後はAIXGの自然言語処理 (NLP) チームに所属し、現在は主にNLPに関する研究開発や社会実装に取り組んでいます。

私たちのチームでは、約3カ月間にわたる実践的なNLP講習会を昨年から社内で開催しています。

そして先月、第2期（2年目）が無事に一区切りを迎えました。

このブログでは、私たちが継続して取り組んでいるこの講習会の内容や特徴についてご紹介します。ブログを通して、「フューチャーではこんな取り組みも行っているんだな」「こんな成長環境があるんだな」ということをぜひ知っていただけたら嬉しいです！

講習会実施のきっかけ

最近では、AIエージェントや大規模言語モデル (LLM) の話題を聞かない日はないほど、私たちの日常生活や仕事でも幅広く活用されています。

当社のNLPチームでも、AIエージェントやLLMを中心としたNLPの技術を応用するプロジェクトに日々取り組んでいます。チームには、学生時代からNLPを専門に研究してきたメンバーもいれば、別の領域から新たにNLPにチャレンジしているメンバーもおり、バックグラウンドはさまざまです。

NLPチームのメンバーとしてプロジェクトを進めていくにあたり、技術の根本から理解し、これまでの分野の流れや概況をつかんでおくことは非常に重要です。さまざまなタスクやアプローチを基礎から理解しておくことで、実際のプロジェクトで課題が発生した際に「この課題はこのNLPタスクの枠組みに近いかもしれない」「この課題なら、この手法が有効かもしれない」と、自身の引き出しを増やすことができます。

そのような狙いから、基礎から最先端の実装までを一貫して学ぶことができる実践型のNLP講習会を社内で企画・実施しています。

講習会の全体像

本講習会は、大きく4種類のカリキュラムで構成しており、全体で約3カ月間かけて実施しています。

• NLPプログラミングの基礎
• 教科書の輪読
• LLMやAIエージェントの実践チュートリアル
• 自由課題

カリキュラムは大学の研究室などで新規配属者向けに行われている勉強会※も参考にしながら、当社の実業務での応用を見据えて作成しました。

これらのカリキュラムは業務の一環として、しっかりと時間を確保して取り組んでいます。日頃は自習として実装や教科書理解を進めつつ、週次で講義ミーティングを実施して全員で議論する時間を取っています。

※ 特にTohoku NLP Groupで開催されている自然言語処理基礎勉強会や、プログラミング基礎勉強会を参考にさせていただきました。

NLPプログラミングの基礎

指定の教材を活用しながら実際に手を動かし、NLPに関する実装力を身につけるカリキュラムです。

Pythonでの基本的なテキスト処理から、NLP特有のライブラリの使い方、機械学習の基礎、APIを利用したLLMの扱いなどを学びます。これらは実際のプロジェクトでNLPの技術を利用したアプローチを実装する際にも活かせる実践的なコーディングスキルです。

教科書の輪読

指定の教科書を受講メンバーで読み進め、NLPに関するタスクの一般的なアプローチや、現在のLLMを支える技術の根幹などの理解を深めます。

あわせて、教科書の題材に関する最新技術や応用例も紹介し、実際のプロジェクトでの応用イメージもつかんでもらいながら進めます。

LLMやAIエージェントの実践チュートリアル

実際にローカルLLMを特定のタスクのデータでファインチューニングしたり、AIエージェントを構築したりといった応用的なチュートリアルを実施します。

実装コードを追いながら実際に動かすことで、学習や推論過程などをブラックボックスにせず、1つ1つ理解しながら学びます。

自由課題

最後は集大成として、参加者それぞれが自由なテーマを設定し、アプローチ検討から実装、評価実験、分析を1周することに挑戦します。

ここまで学んだ知識をフル活用して各自がゼロから作り上げるため難易度は高いですが、実際のプロジェクトに近い形で、特定の課題に対する試行錯誤の一連の流れを経験できます。

↓自由課題のテーマ例

講習会の特徴

本講習会は、カリキュラムを単なる自習や座学で終わらせず、参加メンバー全員が技術を深く、そして楽しみながら学べるような特徴や雰囲気があります。

手厚いメンター制

各カリキュラムには、過去の講習会受講メンバーやその領域に知見を持ったメンバーがメンターとしてサポートする体制をとっています。

メンターは受講メンバーが実装したコードへのコメントや、理解に困ったポイントへの解説などを行います。

さらに、自身の知見や経験に基づいて教材にはない情報を補足することで、より理解が深まり幅広い知識を得ることができます。特に過去に受講したメンバーがメンターを務めるシステムは、ただ受講して終わるのではなく、次は自身が育てる・サポートする側に回るという良いサイクルに繋がっています。

実際のプロジェクトとの接続

週次の講義ミーティングでは、メンターから実際のプロジェクトでの応用例なども紹介してもらっています。

これによって、今学んでいることの意義・価値を感じながら進めることができ、受講メンバーのモチベーション維持に繋がっています。

質問しやすく柔軟に学べる環境

現在は比較的少人数で進めていることもあり、全体として質問しやすい雰囲気で進んでいます。

また、講義ミーティングは録画してアーカイブ化されているため、各自のプロジェクトの業務状況に合わせて柔軟にキャッチアップできる形をとっています。

受講者からの声

講習会を完走したメンバーからは以下のような声をいただいており、過去の受講メンバーもすでにNLPに関するプロジェクトの第一線で活躍しています。

• 「これまでよく理解できていなかった部分が講習を通じてクリアになりました。概要レベルの知識から一歩踏み込み、実際のモデルの学習プロセスや論文内のアーキテクチャの意味が少しずつ紐解けるようになったと感じています。」
• 「日々の業務にて『なんとなく』の理解で進めていたところが講習会に参加することで明確になり、自分のナレッジとして正しく蓄積できたと感じています。また、自由課題では、普段の業務で触れている技術と向き合いながら進めることで、技術的な価値や困難をより実感でき、日々の業務にも生かすことができるような経験ができました。」
• 「これまで触れてこなかった分野で仕事をするにあたっての基礎知識吸収の場として参加させていただき、自然言語処理の統計的手法や機械学習など、様々な知識を吸収できました。基礎知識が身に付いたことにより、日々の業務の理解度が向上したとともに、実際のプロジェクトでも複数の手段を検討できており、成果物の品質向上にも寄与していると感じています。」

おわりに

昨年から実施している講習会ですが、多くの方々からのご協力のもと今年も開催できました。

受講メンバーからも好評で、今後もさらにアップデートしながら継続的に実施していきたいと思っています。また、特徴でも触れたように「学んだメンバーが次に教える側に回る」という良いサイクルを次回以降も回し続けることで、個人の成長にとどまらず、チーム全体の技術力向上に繋げていきたいと考えています。

AIXGでは、このように社員の成長をチーム全体で後押しし、最先端の技術を楽しみながらキャッチアップしていける環境も大切にしています。

そして、ともに自然言語処理の実社会応用を推進していく方も募集しています！ ご興味を持っていただいた方、ぜひAIXGで一緒に働きましょう！

• 新卒採用 : https://www.future.co.jp/recruit/recruit/rec-fresh/
• キャリア採用 : https://www.future.co.jp/recruit/recruit/rec-career/

はじめに

フューチャーでFutureVuls（脆弱性管理SaaS）の開発に携わる棚井です。2026年7月14日に AWS Certified Generative AI Developer - Professional (AIP-C01) を受験し、794点/1000点（合格ライン750点）で一発合格しました。

受けた動機はシンプルで、生成AIの知識武装です。

前回の AWS Certified Advanced Networking - Specialty の合格体験記 の最後に、「設計から障害調査までをAIが担うようになっても、その出力の妥当性を自分で見極められるように、知識をアップデートし続けたい」と書きました。書いておいて何ですが、そのAIを、当時の私はノリと雰囲気で使っていただけです。

（上の画像は 雰囲気ジェネレータ で生成しました）

Claude CodeもPerplexityも、仕事でも仕事以外でも毎日のように使っています。ただ正直なところ、その多くは勘で動かしているだけで、内側で何が起きているかは分かっていません。

RAGやファインチューニングにしても、概念としては知っているものの、いざ設計や実装のレベルになると手が止まります。AIにまるごと渡せば、いい感じに処理してくれるので、それ以上を深掘りする機会がありませんでした。それほど、手軽にAIを使えるようになったのだとも言えます。

ちょうどAWSから、生成AIアプリ開発に振り切ったProfessionalの新しい認定が出たので、これを言い訳のきかない締め切りにして学び直すことにしました。

試験の概要

AIP-C01 は、AWSの認定のなかで初のProfessionalレベルのAI/生成AI専門資格です。これまでAIまわりの認定は、基礎の AI Practitioner (AIF-C01) とAssociateの Machine Learning Engineer (MLA-C01) が中心でした。かつては Machine Learning - Specialty (MLS-C01) という Specialty もありましたが、こちらは廃止済みです。AIP-C01は、これらに続く開発者向けの上位の資格です。

対象がはっきりしているのが特徴です。MLの研究者やデータサイエンティスト向けではなく、基盤モデル（FM）をアプリや業務ワークフローに組み込んで本番投入する開発者に振ってあります。モデルを一から訓練する話やデータエンジニアリングはスコープ外で、RAG、プロンプト管理、エージェント、コスト最適化、セキュリティ、評価といった、作って運用する側のテーマが並びます。FutureVulsのようなSaaSを作っている人間には、業務の延長にある内容でした。

試験概要は次のとおりです（2026年7月時点、公式ページ・試験ガイドより）。

コンテンツ分野と出題比率は以下です。分野1と分野2だけで合わせて57%を占めるので、ここを落とすと苦しくなります。

学習方法

新しい試験で日本語の一次情報がまだ少なく、対策の順番から自分で決める必要がありました。効いたのは次の4つです。

1. Perplexityで計画を立て、「モデル評議会」で弱点を特定する

まず Perplexity と壁打ちして学習計画を立てました。Perplexityにしたのは、新しい情報を踏まえて回答してほしいからです。AIP-C01は出たばかりで、学習ブログの蓄積に頼りきれません。試験ガイドや公式ドキュメントを裏取りしながら答えてくれる相手として、分からないところはすべてPerplexityに聞きました。

面白かったのが、Perplexity Maxプランのモデル評議会という機能です。同じ問いを複数のモデルに投げて、それぞれの見解を突き合わせられます。最初にSkill Builderの無料の20問セットを解いたところ、正答率は45%でした。この結果（分野別スコアと解答時間）をそのままモデル評議会にかけて、傾向を分析させました。返ってきた指摘がこれです。

3モデルが揃って注目しているのが「不正解の方が平均解答時間が短い」点です。これは”迷って外した”というより、”知らないので即決で外した”傾向を示唆し、対策としては演習を闇雲に回すより、まず概念と選定基準（いつどれを選ぶか）をインプットしてから演習に入った方が伸びが速いパターンです。

知らないから即答で外している、という見立ては、耳が痛いくらい当たっていました。実際、20問のドメイン別正答率は分野4と分野5がともに0%でした。ここでいきなり過去問を回しても意味がないと割り切り、まず概念と選定基準を頭に入れてから演習に入る、という順番に切り替えました。この切り替えで、演習の伸び方が変わりました。

2. 書籍でエージェント実装を押さえる

AIエージェント周りの概念のインプットに、書籍『Amazon Bedrock AgentCore実践入門 Strands Agentsで構築するAIエージェント』（AWS深掘りガイド）を読みました。AgentCore（エージェントの実行基盤）とStrands Agents（モデル駆動のエージェントSDK）は、まさに分野2（実装と統合）の中心です。

この領域は新しく、日本語でまとまった情報が少ないので、一冊で通して学べたのは効率がよかったです。ただし後述するとおり、配点最大の分野1（RAG・モデル選定・データ管理）や分野5（評価・トラブルシューティング）はこの本の守備範囲外なので、そこは別教材で補う前提で読むのがよさそうです。

3. AWS Skill Builderで演習を回す

演習は AWS Skill Builder の月額サブスクリプション（29 USD）を契約しました。やった順番はこうです。

• Official Practice Question Set（無料・20問）… 最初の腕試し
• Domain 1〜5 Practice … 分野ごとの演習。弱かった分野4と分野5を優先的に
• Official Pretest … 本番形式の公式模試で最終確認

分野別に演習できるのが今回はありがたく、モデル評議会に指摘された弱点を狙い撃ちできました。正解を選べたかだけでなく、誤答の選択肢がなぜ誤りかまで説明できるかを毎回確認しました。この試験は選択肢がどれもそれっぽいので、消去法の根拠を言葉にできないと本番で崩れます。

4. Udemyで本番の長文に慣れる

仕上げに Udemyの対策講座 の問題を回しました。Udemyの演習には、過去2回の合格体験記（AWS Certified Security - Specialty・AWS Certified Advanced Networking - Specialty）でもお世話になっていて、今回も頼りにしました。

ひとつ補足すると、このAIP-C01の講座は執筆時点でサブスクリプションの対象外で、追加料金を払って個別に購入する必要がありました。追加の出費にはなりましたが、解説が丁寧で量も多く、日本語で学べるAIP-C01の対策教材がまだ限られるなかでは貴重でした。

Professionalの問題文は状況設定が長く、要件（レイテンシのSLA、予算、データの機密性など）を読み落とすと一発で外します。数をこなして、長文から何を最適化したい問題なのかを早く抜き出せるようにしました。

試験勉強で得た学び

私はもともとAI領域の知識が足りませんでした。とはいえ体系立てて学び直したわけではなく、問題演習で知らない自然言語処理の用語に出くわすたびに、そこで立ち止まって、理解できるまでAIと壁打ちする、という進め方です。この試験は用語の暗記ではなく判断を問うので、特に効いた知識を、いつどれを選ぶかの選定基準として整理します。

知識をどう入れるか：RAG・ファインチューニング・継続事前学習・プロンプト

分野1で最頻出、そして基本となるのがこの4つの使い分けです。社内ドキュメントの内容を答えさせたい、と言われて反射でファインチューニングと答えると、たいてい外れます。

軸はこうです。知識の鮮度ならRAG、振る舞いならファインチューニング、ドメイン知識の底上げなら継続事前学習。特に、ラベル付きならファインチューニング、非ラベルの大量データなら継続事前学習、という判別は問題文の一語で正解が変わるので気をつけました。原則は、安いプロンプトやRAGで足りないかを先に確かめてからカスタマイズに進むこと。コスト意識が正解の根拠になる問題が多いです。

同じファインチューニングでも、かけるコストには幅があります。モデルの重みをすべて更新するフルファインチューニングは重い一方で、LoRA（Low-Rank Adaptation）のように、元のモデルは凍結したまま小さなアダプター（低ランク行列）だけを学習する手法もあります。パラメータ効率のよいファインチューニング（PEFT）と呼ばれる考え方で、全体を再学習せずに振る舞いを調整できるぶん、計算コストを大きく抑えられます。

チャンキングと埋め込み、RAGの検索品質

RAGの精度は、検索の前工程でほとんど決まります。ドキュメントをどう分割（チャンキング）し、どう埋め込むかです。

flowchart LR
    A[ドキュメント] --> B["チャンキング
固定長 / 階層型 / セマンティック"]
    B --> C["埋め込みモデル
Titan Text Embeddings 等"]
    C --> D[("ベクトルストア
OpenSearch Serverless 等")]
    E[ユーザーの質問] --> F["ハイブリッド検索
セマンティック + キーワード"]
    D --> F
    F --> G["リランカー
上位の適合率を上げる"]
    G --> H[LLMで回答生成]

Amazon Bedrock の Knowledge Bases では、チャンキングを固定長・階層型・セマンティック・分割なし・Lambdaによるカスタムから選べます。技術マニュアルや法務文書のように入れ子構造のものは、親チャンクで文脈を保ちつつ小さな子チャンクで検索する階層型が効きます。見出しのない長文の記事や調査レポートのように、構造は平坦でも話題が移っていくものは、意味のまとまりで区切るセマンティックが向きます。隣り合う文の埋め込みの類似度が下がったところを境界にするので、話題の途中でチャンクが切れにくくなります。細かすぎると文脈が切れ、粗すぎるとノイズが混ざるので、この加減を文書の性質で判断させるのが出題パターンでした。

地味に効いたのが、取り込み時とクエリ時の埋め込みモデルは同じでなければならない、という制約です。当たり前のようで、選択肢に紛れ込ませてくる引っかけがありました。

ハイブリッド検索とリランカー：再現率と適合率

セマンティック検索は言い換えに強い一方で、型番や固有名詞、略語のように完全一致してほしい語に弱いです。脆弱性管理でいう CVE-2026-XXXXX のようなIDがまさにそれで、意味が近いだけでは拾えません。そこでキーワード検索を組み合わせるのがハイブリッド検索です。

ここで役割を混同しないことが大事でした。

ハイブリッド化は漏れなく拾うための再現率対策、リランカーは上位を精度よく絞るための適合率対策で、別のレイヤーの話です。リランカーが再現率を上げると誤解していると、選択肢で足をすくわれます。ちなみにハイブリッド検索が使えるかどうかは、選ぶベクトルストアに左右されます。Bedrock Knowledge Basesでは当初OpenSearch Serverlessが中心でしたが、その後Aurora PostgreSQLなど対応先が広がりました。こうした実装の制約もセットで問われました。

推論パラメータ：TemperatureとTop-Pはどちらか一方で調整する

出力を制御するパラメータも、名前を知っているだけでは足りず、効果と使いどころまで問われます。

引っかかったのは、TemperatureとTop-Pはどちらもランダム性を制御するので、両方を同時に動かさず、どちらか一方で調整する、という点です。多様性を出すために両方を上げる、という選択肢を正解に見せてくる問題がありました。長さペナルティやTop-Kのように、モデルによって使えたり使えなかったりするパラメータもあり、モデルごとに公開されているパラメータが違う前提で読む必要があります。

Bedrock Agents・AgentCore・Strands Agents、そしてMCP

分野2の山場が、エージェントまわりの三者の区別です。ここは書籍が効きました。

flowchart TB
    S["Strands Agents
モデル駆動のエージェントSDK（開発）"]
    subgraph AgentCore["Amazon Bedrock AgentCore（運用基盤）"]
        R["Runtime
microVMで隔離実行"]
        M["Memory（短期/長期記憶）"]
        G["Gateway
API/LambdaをMCPツール化"]
        I["Identity（Cognito/Auth0連携）"]
        O["Observability（トレース）"]
    end
    S -->|デプロイ| R
    S -->|ツール接続| G

• Strands Agents … オープンソース（Apache-2.0）のエージェントSDK。LLM自身に推論・計画・ツール選択を任せるモデル駆動で、少ないコードでツールを使うエージェントを組めます。作る側の道具です。
• Amazon Bedrock AgentCore … フレームワークに依存しない実行基盤。作ったエージェントを隔離実行（Runtime）し、記憶（Memory）、認証（Identity）、可観測性（Observability）、ツール接続（Gateway）を後から足せます。動かす側の道具です。
• Bedrock Agents … Bedrock内で完結する、マネージドな簡易エージェント機能です。

紛らわしいのは名前の近さですが、役割のレイヤーが違います。Strandsはエージェントを組み立てるSDK、AgentCoreはそれを本番で動かす実行基盤で、補完関係にあります。ただしAgentCoreはフレームワークに依存せず、Strands以外で作ったエージェントも動かせるので、両者は必ずセットというわけではありません。Bedrock Agentsは、これらを自分で組み合わせる代わりにBedrockにまかせるマネージドな選択肢です。この違いで見分けると、三者を混ぜてくる問題にも対応できます。特に注目したのが、AgentCoreのGatewayが既存のAPIやLambdaをMCP（Model Context Protocol）のツールとして公開できる点です。エージェントが外部の道具を使うための共通規格としてMCPが使われていて、この考え方が後半の話につながります。

試験勉強を通しての所感

ユースケースを自分のサービスに引き寄せて考えられる

対策のなかでは、さまざまなユースケースの説明が出てきます。それをひたすら追ううちに、自分が担当するサービスのどこに、どう展開できるかが具体的に見えてくるのが面白く、勉強しながらメモを取り続けました。

メモにはこんな走り書きが並びます。

• このユースケース、うちのあの機能にRAGでそのまま使えそう
• 呼び出すモデルは固定でなくてよく、軽い処理と重い処理で動的に切り替える（ルーティングする）制御もできる
• モデルの評価には、LLM-as-a-judge に加えて、迷うエッジケースは人が判定し、両者を組み合わせるハイブリッドもある

どれも、言われてみれば確かにそうだ、とうなずけるものばかりでした。生成AIの実装経験は浅くても、アプリ開発の勘所があれば、こうした学びは設計に生きます。

PII対応で、法律と実装がつながった

試験を通して、PII（個人を特定できる情報）の扱いが何度も出てきました。実は先日、個人情報保護士認定試験にも合格し、その体験記を書きました。そこで学んだ法律や制度を、いざサービスに実装する段になると、Amazon Bedrock GuardrailsのPIIフィルタ、テキストから個人情報を検出するAmazon Comprehend、S3上の機微データを見つけるAmazon Macieといったサービスが要ります。

制度として知っていたことと、それをどう実装するかが、一本の線でつながりました。コンプライアンスを要件から実装まで通して考えられるようになったのは、今回の思わぬ収穫です。

試験結果の振り返り

スコアは794点、合格ラインの750点を44点上回っての合格でした。

分野別の評価はこうです。

正直に書くと、最後まで分野5（テスト、検証、トラブルシューティング）が埋まりきりませんでした。弱点だった分野4・5のうち、分野4は個別Practiceで持ち直しましたが、分野5は薄いまま本番に臨みました。モデル評価やLLM-as-a-judge、RAGの検索と生成を分けて診断する話は書籍でも手薄で、公式ドキュメントを直接あたる必要がありました。配点が11%と小さいことに救われた面はあります。

本番の進め方も少し書いておきます。試験時間の180分は、見直しまで含めて目一杯使いました。時間にゆとりは決してなく、最後まで押し気味でした。もう1つ、数問だけ日本語では文意を取りにくい設問があり、その場で英語に切り替えて読み直しました。技術的な内容は英語の原文のほうが素直に読めることもあるので、少しでも迷ったら切り替えるのは有効な手でした。

44点差での合格です。数字のうえでは少し上回っていますが、手応えとしてはぎりぎりでした。効いたのは、配点の大きい分野1と分野2を固めきれたことです。埋めきれなかった分野5は割り切り、重い分野から順に押さえる。この判断が、合否を分けたのだと思います。

おわりに

生成AIの知識武装という当初の目的は、ひとまず果たせました。勘や雰囲気で動かしていたものを、内側で何が起きているかを踏まえて扱えるようになったのは、大きな収穫です。

学んでいて感じたのは、SaaSに求められるものが変わりつつあることです。先日、日経クロステックに「フリーは『AIが使いやすい』SaaSを目指す、CAIO直下に新組織」（2026年7月13日、有料会員限定）という記事が出ました。freee共同創業者でCAIOの横路隆氏の言葉として、こう紹介されています。

SaaSのあり方も、これまでは人が使いやすいプロダクトを目指してきましたが、これからはAIエージェントが使いやすいものにする必要があります。

SaaSを作る側にいる自分にとって、この指摘は他人事ではありません。プロダクトを使うのが人だけでなくAIエージェントにもなるなら、エージェントが叩ける口、つまりMCPサーバーを備えていることは、もう前提に近いはずです。画面を磨くのと同じ手間を、AIエージェント向けの入り口にもかける必要があります。

折しも、私のいるFutureVulsチームでは、7月17日に FutureVuls MCP Server をリリースしました。「いつものAIエージェントに、“脆弱性管理”を」というものです。試験勉強では、AgentCore GatewayがまさにMCPを軸にしているのを見ました。作る側に回るいま、その中身を理解したうえで判断できるのは大きいです。

今回の試験では、AWSのAIエコシステムの知識と、設計に落とし込める自然言語処理の知識が身につきました。これからは両方をフル活用して、サービス開発につなげていきます。

とはいえ、AWSのサービスは日々増えていきます。そのキャッチアップとして、ランチタイムのウェビナー「もぐもぐ AWS」に毎日参加しています。30分で最新のサービス動向を追えるのがちょうどよく、毎回いい刺激をもらっています。

次に何を受けるかは迷っていますが、AIエージェントの運用が本格化するほど、それを支えるインフラやセキュリティの知識がまた要るはずです。受かったら、また書きます。

参考

• AWS Certified Generative AI Developer - Professional（公式ページ）
• AIP-C01 試験ガイド

AI戦略推進グループ（AIXG）の松岡です。

2026年6月8日（月）〜12日（金）、群馬県高崎市のGメッセ群馬にて人工知能学会全国大会（JSAI2026）が開催されました。フューチャーからもメンバが現地参加しましたので、その様子をレポートします。

一昨年のJSAI2024参加レポートに続き、今年もゴールドスポンサーとして現地参加してきました。

人工知能学会全国大会とは

人工知能学会全国大会（JSAI）は、日本最大規模のAI関連学会の1つで、研究者・技術者・ビジネスパーソンが一堂に会するイベントです。

今年のJSAI2026は、2026年6月8日（月）〜12日（金）の5日間、Gメッセ群馬（群馬県高崎市）にてハイブリッド形式（現地＋オンライン）で開催されました。学会設立40周年の大会となります。

参加者数は集計の結果5,278名（現地4,296名、遠隔982名）、発表件数は1,397件で、いずれも過去最多を記録しました。

プログラムは口頭発表・ポスター発表・企画セッション・チュートリアルなど多岐にわたり、40周年という節目にふさわしく、AI研究の歩みを振り返るとともに、社会実装・Physical AI・AI倫理など多様な領域へと広がる現在のAI研究の全体像を俯瞰できる大会でした。

スポンサーブース

フューチャーは今年もスポンサーブースへ出展しました。ブースではポスターを掲示し、AIXGが手がけるAIの社会実装案件を紹介しました。

研究の最先端を追うだけでなく、実ビジネスの現場にAIをどう組み込んでいくかというフューチャーならではの取り組みを来場者に伝えることができました。

グッズとしてペットボトルホルダーとトートバッグを配布しました。トートバッグは特にデザインのセンスが良いと好評で、多くの方に喜んでいただけました。

ブースには人工知能学会で初めてフューチャーを知った人たちから社名は聞いたことがある、社員に知り合いがいるといった人たち、インターンの選考を受けている学生に内定者と幅広くたくさんの方にお越しいただきました。

セッション聴講

ここからは、特に印象に残ったセッション・発表について各メンバからご紹介します。

[4H1-OS-4a-04]ツンデレな心的状態理解を促すロボットの視線モデルの提案

日常空間で普及しつつある対話ロボットにおいて、視線の動きは相手の感情や意図を推測する非言語情報として、円滑なコミュニケーション領域で重要視されています。

円滑なサービス提供に向けて対話の流れや意図に合わせて視線制御をすることでスムーズに伝達できることが理想ですが、実際には顔追従や発話権に合わせた注視切替などに偏ってしまい、ロボット自身の「心境変化」といった内的状態を十分に表出するには至っていません。

本研究では、先行研究で提案されている相手の視線を入力としてエネルギーを逐次最小化する視線モデルに対して「ツンデレ（最初は照れ隠しで視線を回避するが、心を開くとアイコンタクトが増える状態遷移）」の概念を導入し、会話に応じて視線の動きを段階的に変化させる視線モデルを提案しました。

提案の視線モデルの有効性を検証するために、常時対話相手を注視する条件と先行研究の視線モデルに基づいて対話相手を注視する条件と比較した結果、提案モデルによって視線変化の理由理解と心境変化の知覚を有意に向上させることが明らかになりました。

対話ロボットが普及する中で、「ツンデレ」というサブカルチャーの概念を状態遷移モデルとして真面目に実装し、視線1つでロボットの「心」を表現するに至った点が面白くこちらの発表を取り上げました。(加藤)

[2E5-GS-10o-02] 時系列データ解釈のためのマルチモーダルLLM設計と自動車の運転挙動説明への応用

トヨタ自動車とNABLASによる発表をご紹介します。

車速・加速度・操舵角といった車載の時系列データは、可視化やタスクごとの個別モデル構築に人手を要し、解釈にも専門知識が必要でした。本研究はこの課題に対し、時系列エンコーダと射影（プロジェクション）層を組み合わせ、抽出した時系列特徴を直接LLMへ入力する新アーキテクチャ Time-Series Language Model（TSLM） を提案しています。

構成は画像分野のVLM（LLaVA）に着想を得ており、時系列基盤モデル MOMENT で走行データから特徴量を抽出し、2層のMLP（射影層） でLLMの埋め込み空間へ写像、LLM（Qwen3-4B-Instruct-2507）へテキスト指示とともに入力して運転挙動の説明文を生成します。特に、エンコーダとLLMの重みは凍結し、学習するのは射影層のMLPのみ という点が特徴で、少ない計算資源で学習でき、モデルの置き換えも容易という利点があります。

データセットは実車走行データ（カムリ・クラウンで一般道・高速道路を走行）から構築し、8系列を0.1秒周期で記録して10秒ごとに区切っています。教師となる説明文はグラフ画像をVLMに読ませて生成させ、約2万件の時系列⇔テキストのペアを自動的に用意したとのことです。

評価では、時系列を折れ線グラフの画像に変換してVLMで処理するベースラインと比較し、LLM as a Judge（1〜10点）で説明文の質を測定。提案手法TSLMは平均 6.82点 とベースラインの 4.86点 を上回り、時系列を画像化せず直接LLMへ取り込むアプローチの有効性が示されました。

時系列を「画像化してから読ませる」のではなく専用エンコーダで特徴量化して直接渡す発想が新鮮で、学習対象を射影層だけに絞った軽量・転用性の高い設計も実務的でした。センサーやログなど時系列を扱う社会実装案件への応用可能性を感じる発表でした。(岩城)

[4G1-OS-23-04] ReMIND：大規模言語モデルのモジュラー統合によるセレンディピティ創発

新しいアイデア創発にLLMを利用することは昨今珍しい話ではありませんが、新規性と、アイデアの論理的整合性を両立させることは簡単ではありません。

本研究ではリアルの人間がレム睡眠の際にアイデアを創発することに着想を得たLLMフレームワークReMINDの提案をしています。

人間はレム睡眠の間に、記憶や知識をランダムに組み合わせて「ひらめき」を生み出し、起きている間にそれを「整合性のあるアイデア」へと収束させています。

本フレームワークはこの仕組みを着想源としており、wake、dream、judge、re-wake の4ステップで構成されています。

• wake（覚醒状態）：Temperature を低く設定し、ベースラインとなる堅実で安定した応答を生成します。
• dream（睡眠状態）：Temperature を高く設定し、普段は結びつかない概念同士を掛け合わせた、自由で意外性のある応答を生成します。
• judge（評価）：生成されたアイデアに対して粗く評価し、有望な候補を抽出します。
• re-wake（再覚醒・収束）：抽出した候補を再度 wake（低Temperature）に入力し、最終的なアイデアとして綺麗に再構成した上で出力します。

複数のプロンプト条件、モデル、およびパラメータを対象に、LLM as a judgeにより評価しました。その結果、新規性のあるアイデアの出現自体は確率的なものにとどまる側面はあるものの、本フレームワークのように「構造化された探索」と「選択的な統合」を組み合わせることで、限られた試行回数の中でもその出現確率を向上させられることが示されました。

深層学習という手法に起因する、現在のAIにおける『純粋な創造性』の構造的ジレンマに対抗するアプローチとして非常に面白い研究でした。

また、本研究を発表された佐藤純先生は、神経科学をはじめとする生物科学をご専門とされており、その知見を彷彿とさせるフレームワークの着想は、大変興味深いものでした。

[3N1-GS-8a-03]実会話の雰囲気を伝えるロボット行動生成

人間の会話にある「言葉には表れない全体の雰囲気」を、2台のコミュニケーションロボットで再現しようと試みた非常に興味深い発表でした。

本セッションでは、会話の雰囲気は「発話内容」「音声韻律」「ジェスチャ」の統合的な制御によって作られるという仮説に基づいて研究が進められています。

最新のLLMに漫才の会話データを読み込ませて発話の役割ごとの声の制御や、絶妙な「発話間の間」の取り方を推定させているそうです。

さらに、テキストの指示からロボットの関節の動きまで生成して連動させています。一見無機質に思われがちなロボットとのやりとりですが、提案された生成システムを用いて人間の漫才を再現したところ、間の取り方や身振りが統合され、人間同士のやり取りにかなり近い雰囲気が醸し出されていました。

この研究が進めば、将来的にロボットとのやり取りが人間にとってごく自然なものになるのではないかと、大きな期待が膨らむセッションでした。(松岡)

さいごに

基盤モデル・生成AI研究の盛況は今年も続いていましたが、様々な業界におけるRAGやAIエージェントの活用など「実務への適用」を重視した発表が増え、研究コミュニティ全体が社会実装フェーズへ移行しつつある印象でした。

マルチモーダルAIの広がりや、発表・企業ブースでのロボットに関する出展の増加からはPhysical AIへの関心の高まりも感じられ、AIが現実世界に根ざした技術として進化していることを改めて実感しました。

AIXGではAIの社会実装に一緒に取り組む仲間を募集しています。新卒・キャリアともに採用中ですので、ご興味のある方はぜひご覧ください。

• 新卒採用
• キャリア採用

データエンジニアリング連載 の3本目です。今回の担当は棚井です。

はじめに: Fableが帰ってきた

ついに、Claude Fable 5の利用が再開されました。6月に発表されたばかりのモデルだったのが、6月12日に米国政府の輸出規制がかかって全ユーザー向けにアクセスが止まっていたところからの復帰です（Anthropic: Redeploying Claude Fable 5）。6月30日に規制が解除され、7月2日から再開されたという経緯です。使えなくなっていたモデルが戻ってきて、正直やったぜと思いました。

ただし、トークン消費量の多さとは別に、押さえておきたい注意点があります。Fable 5は、ZDRではなく30日のデータ保持が必須という仕様です。同じClaudeでも、他の多くのモデルはZDR下で会話内容を残さないサービス仕様ですが、Fable 5はこの点が異なります。同じサービス・同じAPIキーでも、どのモデルを呼ぶかでデータ保持のルールが変わることがありますので、それならば主要モデルのデータ保持の扱いを一度横断で整理しておこう、と思ったのが今回のきっかけです。

テーマは、生成AIをデータ基盤やアプリに組み込むときに毎回引っかかる「入力したデータがプロバイダ側にどれだけ残るのか」です。いわゆるデータ保持期間（Data Retention）と、ZDR（Zero Data Retention、ゼロデータ保持）です。2026年7月2日時点の各社公式ドキュメント・利用規約を一次情報として整理しました。

また最近、セキュリティチェック項目に「AIの利用可否」と「データ保持の有無」について問われる機会が増えてきました。ここでつまずきやすいのが「学習に使われない」と「サーバに残らない」を同じものと扱ってしまう点です。この2つを分けずに「APIなら安全」と判断すると、監査で足をすくわれます。

先に、5サービスの要点を表でまとめます。今回は「API/エンタープライズ利用」を前提に取り上げます（個人向けアプリは別ポリシーなので、必要な範囲でのみ触れます）。細かい根拠は各節で扱うので、ここでは全体像だけ押さえてください。

便宜的に3つのレイヤに分けて考える

実際のデータ保持のメカニズムは、サービスごとに細かい差分があります。その差分を一度に並べると読みづらいので、ここでは説明のための便宜的なグルーピングとして、次の3つの軸を使います。公式な規格や定義ではなく、あくまでこの記事での整理軸です。

同じ②の中でも、サービスによっては「不正利用監視用の保持」と「デバッグ/運用ログ」で期間が違ったり、ZDRを有効にしても特定の機能だけ②が残ったりします。その細かい差分は各節で拾います。まずはこの3つを分けて見る、というところを押さえておいてください。

エンタープライズ向けの主要API（OpenAI / Anthropic / Google Gemini API）は、①の学習利用がデフォルトでオフです。各社が規約で明記しています（Homula: エンタープライズLLMのデータ主権）。

問題は②です。学習には使わないが、Abuse Monitoring（不正利用監視）のために入出力を最大30日ほど保存する、というのが多くのサービスのデフォルトになっています。「入れたデータが一切残らない環境」ではない、という認識のズレはここから来ます。

③のZDRは、その②の保存をやめる仕組みです。ただし後述のとおり、ZDRを有効にしても保存が残る例外が各社にあります。「魔法の全消し設定」だと思っていると危ないです。

ZDRの定義としては、XIMIX（NTTインテグレーション）の説明が端的でした。ZDRとは「ユーザーが入力したプロンプトやAIが生成した回答データを、サービス提供者側のサーバに一切保存せず、処理直後に破棄すること」であり、「学習に利用しない」より厳格なアプローチだとしています（XIMIX: 生成AI時代のゼロデータリテンション）。ただし、ZDRの具体的な定義はサービスごとに異なります。各サービスの定義は、それぞれが公開している情報で確認してください。

OpenAI（GPT / Codex / API）

OpenAIはエンドポイント単位の保持挙動を表で公開していて、ここが一番細かく追えます（OpenAI: Data controls in the OpenAI platform）。

API経由のデータは、2023年3月以降、明示的にopt-inしない限りモデル学習に使われません。Abuse Monitoring目的のログは全APIで生成され、最大30日保持されます（法令上より長期の保持を求められる場合を除く）。このログにはprompts / responsesや分類器の出力などのメタデータが含まれえます。

ZDRやMAM（Modified Abuse Monitoring）は、Eligible customers（適格な顧客）が事前承認と追加要件への同意を経て使えます。組織またはプロジェクト単位です。ZDR有効時、/v1/responses と /v1/chat/completions の store パラメータは、リクエストで true を指定してもfalse扱いに固定されます。

モデル単位で挙動が変わるところ

テキストモデルは、同じエンドポイントを使う限り保持挙動も同じです。テキスト側に「モデルを変えたらZDR可否が変わる」という差は見当たりません。公式のData controlsページで明示されているモデル単位の差は、画像生成モデルの間にあります。

画像生成でdall-e系を選ぶとZDRから外れます。同じ「OpenAIで画像を作る」でも、gpt-image系に寄せるかどうかで結論が反転します（OpenAI: Data controls in the OpenAI platform）。

エンドポイント単位のZDR対象可否

モデル以上に効いてくるのがエンドポイントの違いです。主要なものを抜粋します。

出典はOpenAI公式のData controlsページです。

OpenAIのZDRがしっかり効くのは、chat/completionsやresponsesで、余計な機能を付けずに推論だけをシンプルに実行する場合です。拡張キャッシュのような便利機能を足すほど、その分ZDRの対象から外れる部分が出てきます。Codexも同様で、内部でどのエンドポイント・機能を叩くかで保持挙動が変わるので、「Codexだから安全」ではなく利用エンドポイント単位で判断してください。

データレジデンシー（保存先リージョン）については、対象エンドポイントで欧州/米国を明示選択できるオプションがあります（OpenAI: ビジネスデータのプライバシー）。

Anthropic（Claude / Claude Code）

Anthropicは個人向けと法人向けでポリシーページが分かれています。そしてここが今回の主題そのもので、同じClaudeでもモデルによってZDR可否が違います。

再開したFable 5とMythos 5の保持要件

Claude Fable 5とClaude Mythos 5は「Covered Models」に指定されていて、30日のデータ保持が必須です。ZDRは選べません（Anthropic: API and data retention）。Claude APIでは、この30日保持を満たさないZDR組織からのリクエストは 400 invalid_request_error を返します。この30日要件はどのプラットフォームでも同じで、Bedrock、Google Cloud、Microsoft Foundry経由でも保持データは各クラウドプロバイダの環境内に残ります。
冒頭で触れたとおり、Fable 5は再開直後です。戻ってきたばかりのタイミングだからこそ、ここで30日保持の要件を改めて確認しておきましょう。それ以外のClaudeモデルは、ZDR下で会話内容をデフォルト保持しません。同じアカウント・同じAPIキーでも、Fable 5 / Mythos 5を呼ぶかどうかでデータ保持のルールが変わってきます。この点を運用ルールに落とし込んでください。

個人向けプラン

個人向け（Claude Free / Pro / Max、およびそのアカウントで使うClaude Code）の保持は次のとおりです。会話削除時、履歴からは即時、バックエンドからは30日以内に削除されます。モデル改善を許可した場合、de-identified形式で最長5年、学習パイプラインに保持されえます（設定を有効にした後の新規・再開チャットに適用）。Usage Policy違反時は入出力を最長2年、trust & safetyの分類スコアを最長7年保持します。Incognito chatsはモデル改善に使われません（Anthropic: How long do you store my data?）。

特に注意したいのが、モデル改善を許可した状態の保持期間です。プライバシー設定はいつでも変更できますが、デフォルトの学習利用可否は利用時点の設定を自分で確認してください。業務データを個人向けプランに入れる行為は、会社の管理下にないAI利用、いわゆる「シャドーAI」にあたります。個人向けプランは学習利用や保持期間のデフォルトが法人向けと異なるため、業務データは法人向けプランで扱い、個人向けプランには入れないよう徹底してください。

法人向けプランとZDR契約

法人向け（Anthropic API、Claude Team / Enterprise）は学習利用がデフォルトでオフです。ここで注目したいのがClaude Codeで、同じClaude Codeでも、どの経路で動かすかでログの保持が変わります。

APIキー（Anthropic API）で動かすClaude Codeは、APIの保持ルールに従います。会話コンテンツ（プロンプトとClaudeの出力）はデフォルトで保持されず、バックエンドに残る場合も受領・生成から30日以内に自動削除されます（Files APIなどユーザー管理下の長期保持、ZDR等の別途合意、Usage Policy執行、法令対応は例外）（Anthropic: API and data retention、Anthropic: How long do you store my organization’s data?）。

一方、Team / Enterpriseで使う場合は、その組織のデータポリシーに従います。会話やプロジェクトを保存して継続できる製品では、保存したデータが製品内に残ります。Enterpriseプランではカスタムデータ保持期間を設定でき、最小は30日です。設定しなければ無期限保持になります。削除は指定日のUTC 0時に実行され、監査ログに記録されます（Anthropic: Configure custom data retention for Enterprise plans）。

ZDR契約の対象は、Messages APIなどの適格なAnthropic API、法人向けの組織APIキーで使う製品（APIキー経由のClaude Codeを含む）、そしてEnterpriseプランのClaude Codeです。Teamプランや個人向けのClaude Codeは対象外になります。ZDR時、Anthropicは法令遵守や不正・危害対策に必要な場合を除き、入出力を保存しません。ただし、入出力そのものではなく、コンテンツが利用規約に反していないかを判定する安全性チェック（User Safety分類器）の結果だけは、規約違反への対応のために残ります。承認制で組織単位、申請はSales Team経由です。HIPAA対応サービス／BAA（Business Associate Agreement）には構成上の制約があり、たとえばWeb検索機能にはBAAが適用されません（Anthropic: ZDR agreement — supported products）。

Google（Gemini API）

GoogleはGemini Developer APIでZDRドキュメントを公開しています。ドキュメントはモデル別のZDR可否を列挙しておらず、保持の可否はモデルではなく使う機能側で差が出る構造です。

有料サービスでは、プロンプト（システム指示・キャッシュ・画像/動画/ドキュメント等のファイルを含む）や回答は製品改善に使われません。Abuse Monitoring目的では、Prohibited Use Policy違反検出に限りプロンプト・回答を一定期間ログ記録します。ZDR承認が下りると、ログ記録前にユーザーコンテンツと識別可能メタデータ（IPアドレス、GoogleアカウントID等）がクリアされ、サニタイズ済みレコードとしてマークされます。

ZDRを有効にしても残る、または無効化できない機能があります。

出典はGoogle AI for Developers: Zero data retention in the Gemini Developer APIです。

実務で一番のハマりどころはGroundingです。Google検索・Maps連携を使うと、ZDR契約下でもプロンプト・文脈・出力が30日保存され、これはオプトアウトできません。「精度を上げたいからGrounding ON、でもZDRだから安心」という構成は成立しません。外部知識を足す機能とZDRが両立しないのは、OpenAIのCode Interpreterやキャッシュと同じ構造です。片方が立てば片方が崩れると覚えておくと応用が効きます。

Preferred Networks（PLaMo API）

国内のAPI勢のなかで、ZDRを正面から掲げているのがPLaMoです。現行モデルはplamo-3.0-prime（262kコンテキストのフラッグシップ）、plamo-3.0-prime-beta（2026年7月31日で提供終了）、plamo-2.2-prime（2026年9月30日で提供終了）です（PLaMo API ドキュメント）。

保持と学習の扱いは、どのプランを選ぶかで変わります。プラン比較表ではStandardプランの「ZDR（入力データの非保持）」欄に「入力データを学習に利用しない」と記載され、Freeプランは同欄が「―」で対象外です。Standardプランの特徴欄には「入力したデータを保存せず、モデル学習にも使わない」とも明記されています（PLaMo API プラン）。利用規約側では、有償サービスのコンテンツを「本サービス、新サービス又はAIモデルの開発若しくは改善の目的で、閲覧又は利用することはありません」と定める一方、Freeプラン及び無償サービスのコンテンツは同目的で「閲覧又は利用する場合があります」としています。あわせて「当社は利用者に対して本コンテンツを保存する義務を負いません」とも定めています（PLaMo API 利用規約）。規約は個人情報保護法（APPI）の遵守を明記し、無償サービスでの個人データ入力を禁止するなど、国内のコンプラ要件を意識して作られているのが分かります。

Sakana AI（Fugu）

SakanaのFuguは、受け取ったリクエストを内部でいくつかの小さな作業に分け、それぞれを外部のフロンティアモデル（OpenAI / Anthropic / Google等）に振り分けて処理させるサービスです。たとえば、難しい推論が必要な部分と単純な整形で済む部分を、それぞれ得意なモデルへ自動で割り振ります。こうして複数のモデルを束ねて使い分ける仕組みを、オーケストレーション型と呼びます（Sakana Fugu Terms of Service）。入力は外部LLMへ転送され、各プロバイダのポリシーが適用されます。ここが保持を考えるうえで効いてきます。

学習利用については、ContentをTraining Use（再学習・ファインチューニング含む）に利用しうるとしています。コンソールでopt-out可能ですが遡及しません。保持については、入力・出力の保存義務を負わないと定めています。加えて、Contentを基に学習したモデルの重み・外部ベンダーの一時キャッシュ・監査ログについても、削除義務を負わないと明記しています。品質・安全性向上のため人間レビュアーがContentを注釈・処理する場合があり、フィルタで個人・機密情報のレビューを完全には制限できないとも書いています。金融個人データについては別途「金融個人データ保護指針」（2025年6月施行）で安全管理措置を定めますが、保持期間・学習利用・ZDRの具体的記載はありません。

現時点のFuguはZDRを掲げるサービスではありません。オーケストレーション型なので、データ保持は「Sakana自身」と「転送先の外部LLM」の二重で評価する必要があります。機密データを入れる用途では、この二重評価をやりきれるかがそのまま採否の判断になります。

横断比較表（2026年7月時点）

「API/エンタープライズ利用」を前提とした比較です（個人向けアプリは別ポリシー）。モデル固有の差がある行は「主なモデル差」に書きました。

各セルの出典は本文の該当節を参照してください。

実務でどう判断するか

整理して見えてきた勘所は4点です。

1. 「学習しない」と「保存しない」は別物です。エンタープライズAPIは学習利用こそデフォルトオフですが、Abuse Monitoring目的の保持（多くは30日）は別に走っています。

2. ZDRは全消し設定ではありません。OpenAIのキャッシュやCode Interpreter、GoogleのGrounding、AnthropicのUser Safety分類スコアなど、ZDRを有効にしても残るものが各社にあります。機能単位で棚卸ししてください。

3. 同じサービスでも、選んだモデルで結論が変わります。Claude Fable 5 / Mythos 5はZDR契約下でも30日保持が必須、OpenAIはdall-e系がZDR不可・gpt-image系が可です。実際に叩くモデルまで落として確認してください。

4. デフォルトの保持挙動はサービスやプランで真逆になることがあります。同じAnthropicでも素のAPIは非保持、Team / Enterpriseはカスタム設定しない限り無期限で、PLaMoも有償Standardは非保持・無償Freeは対象外です。ZDRも各社とも承認制・上位契約前提なので、全業務に引くのは過剰です。データを分類し、極秘データを扱う経路には確実にZDRを当てるのが現実的です。

セキュリティレビューでは、AIサービスについて「①学習利用 ②保持期間 ③ZDR可否と例外 ④利用モデル ⑤リージョン/契約要件（承認制か・BAA/DPA〈データ処理契約〉有無）」の5点を、最低限のチェック項目として確認すべきだと思われます。モデルが1つ増えても、この5軸に当てはめれば整理できます。今回のFable 5のように同じサービスでもモデルで結論が変わることがあるため、④利用モデルは独立した観点として持っておくとよいでしょう。

各社ポリシーは改定が速い領域です。この記事の数値も、実務判断の前には必ず一次情報で再確認してください。

参考（主な一次情報）

• OpenAI: Data controls in the OpenAI platform / Enterprise privacy at OpenAI
• Anthropic: API and data retention / How long do you store my data? / How long do you store my organization’s data? / Custom data retention for Enterprise / ZDR agreement — supported products
• Google: Zero data retention in the Gemini Developer API
• Preferred Networks: PLaMo API ドキュメント / PLaMo API プラン / PLaMo API 利用規約
• Sakana AI: Fugu Terms of Service / 金融個人データ保護指針

はじめに

こんにちは。フューチャーアーキテクト 製造・エネルギーサービス事業部の柴田です😌 見真の心で本質を探求しています!

BigQuery上のデータに対して、外部APIを呼び出すことなく、クエリ内でGeminiによるテキスト生成やデータ解析する手順をまとめました。サービスに対する対応の手間を減らすために、エラー発生時の推奨アクションを提示しています。

普段のGemini利用と異なる利用料金などについても整理しています。

事前準備

BigQueryとVertex AIを連携させるための設定とモデルを作成します。

全体の構成図

モデル利用のためには、次の設定が必要です。

• 外部接続
• 外部接続で呼び出すモデル

構成図は以下の通りです。

graph LR
    %% ノードの定義とラベル
    Query[SQL クエリ
ML.GENERATE_TEXT]

    subgraph BQ_RemoteModel [BQリモートモデル gemini_model]
        direction TB
        Model_Config[モデル設定]
        Connection[外部接続 vertex_ai_conn
認証の通り道]
    end

    VertexAI[Vertex AI Gemini API]

    %% フローの定義
    Query -->|モデルを指定
Connection情報をロード| BQ_RemoteModel

    %% 認証とAPI呼び出しのフロー (ここがデータの通り道)
    Connection -->|セキュアに通信
API呼び出し| VertexAI

    %% スタイリング（Google Cloudカラーをイメージ）
    classDef bq fill:#e0f7fa,stroke:#01579b,stroke-width:1px,color:#01579b;
    classDef conn fill:#ffccbc,stroke:#bf360c,stroke-width:1px,color:#bf360c,stroke-dasharray: 5 5;

    class Query,BQ_RemoteModel,Model_Config bq;
    class Connection conn;

外部接続（Connection）の作成

BigQueryコンソールの「データ 追加」 > 「Vertex AI」のデータソースを選択（vertex aiで検索）

外部データへのアクセスで、BiqQueryフェデレーションを選択します。

以下のように、外部データソースとの接続を作成します。

• 接続タイプ：Vertex AI リモートモデル、リモート関数、BigLake, Spanner（Cloud リソース）
• 接続ID：用途が分かりやすい名前にする（接続名なので*_connという命名を推奨）
• ロケーションタイプ：任意のリージョンを選択
• 分かりやすい名前：日本語OKなので利用方法が明確な名前にします
• 説明：より詳細な説明

作成した接続はBigQueryコンソールの「接続」で確認できます。

リモートモデルの定義

BigQueryから外部のGemini APIを呼び出すための、設定情報（メタデータ）を登録します。
以下のCREATE OR REPLACE MODELクエリを実行してモデルを作成します。
BigQuery内に、Geminiを呼び出すためのモデルを定義します。これは1度だけ実行すればOKです。

CREATE OR REPLACE MODEL プロジェクト名.データセット名.モデル名
REMOTE WITH CONNECTION プロジェクト名.リージョン.先ほど作成した接続ID
OPTIONS (
-- 利用したいGeminiのエンドポイントを指定（例:gemini-2.5-flash, gemini-2.5-pro）
endpoint = '使用するモデル'
);

参考：クエリの具体例は以下の通りです。

CREATE OR REPLACE MODEL `project_id.logexplorer.gemini_model`
REMOTE WITH CONNECTION `project_id.asia-northeast1.logexplorer_ai_conn`
OPTIONS (
endpoint = 'gemini-2.5-flash'
);

クエリを実行すると、指定したデータセットの直下にモデルが作成されます。

モデルの利用

作成したモデルを利用して推論します。ここでは実際のクエリ例を示します。特定の処理で発生したエラーログをBigQueryにリアルタイムで取り込ませている状態で、このようなプロンプトでエラーに対する推奨アクションをAIに教えてもらおうとしています。

あなたは優秀なクラウドデータエンジニアです。
以下のエラーメッセージから原因を推測し、解決のための具体的な「推奨対応方法」を150文字以内で提示してください。
【対象ファイル】：対象ファイル名
【エラーメッセージ】：エラーメッセージ

以下の例はstatus_tag が ‘error’ のログを抽出し、Geminiに推奨アクションを推論させるというクエリです。

-- ====================================================================
-- 目的: status_tag が 'error' のログを抽出し、Geminiに推奨アクションを推論させる
-- ====================================================================
SELECT
	timestamp_jst,
	service_name,
	target_file,
	status_tag,
	message,
-- JSONレスポンスからテキスト部分のみを抽出（回答の本文のみを取り出す必須処理）
JSON_VALUE(ml_generate_text_result, '$.candidates[0].content.parts[0].text') AS recommended_action
FROM ML.GENERATE_TEXT(
-- ==================================================================
-- モデルの指定
-- 事前に CREATE MODEL で作成した、Vertex AI（Gemini）を呼び出すためのモデルを指定します。
-- ==================================================================
	MODEL project_id.logexplorer.gemini_model,
(
-- ================================================================
-- 1. AIに渡すためのデータ（プロンプト）を準備するサブクエリ
-- ================================================================
SELECT
	timestamp_jst,
	service_name,
	target_file,
	status_tag,
	message,
	CONCAT(
	'あなたは優秀なクラウドデータエンジニアです。\n',
	'以下のエラーメッセージから原因を推測し、解決のための具体的な「推奨対応方法」を150文字以内で提示してください。\n\n',
	'【対象ファイル】', IFNULL(target_file, '不明'), '\n',
	'【エラーメッセージ】\n', IFNULL(message, 'なし')
	) AS prompt
FROM
	project_id.logexplorer.logexplorer_errors
WHERE
	status_tag = 'error'          -- 指定条件：エラーのみを対象
	AND message IS NOT NULL       -- メッセージが空のものは除外（APIの無駄撃ち防止）
ORDER BY
	timestamp_jst DESC
),
-- ==================================================================
-- 2. モデルの推論パラメータ設定
-- ==================================================================
STRUCT(
0.0 AS temperature,       -- 0.0にすると回答が固く・決定的になる（エラー分析に適している）
300 AS max_output_tokens  -- 出力される最大トークン数（コスト上限のストッパー）
)
);

利用料金を押さえるためのポイント

これまでの手順で各レコードに対してGeminiを実行できますが、好き放題に利用すると料金が膨らんでいきコストを圧迫してしまいます。

なので、ここでは利用料金を抑えるための解決方法の例を紹介しますす。

Geminiの料金体系（Gemini 2.5 2025年4月29日現在）

• トークン数の比例して課金される（日本語の場合は１文字２トークン）
• 入力・出力の合計トークン数で課金額が決まる

利用料金を抑える方法の例

1. 用途におけるモデルの選択
   上記の表が示すように、FlashとProでは利用料金が3倍以上変わります。普段使いではとりあえず一番性能がいいものを選びがちですが、コストに直結するため複雑な推論を必要としない場合などにはFlashや古いバージョンのモデルを利用します。
2. 同じ質問を何度もしない
   一度推論した結果（プロンプトと回答のセット）はBigQueryのテーブルに保存し、次回以降は JOIN で過去の回答を使い回す。
3. バッチ内重複排除
   2.とやや共通していますが、1回のスケジュール実行内で同じエラーが複数ある場合、GROUP BY や ROW_NUMBER() を使って代表の1件だけをGeminiに投げ、結果を他の行にコピーする。

さいごに

以上、BigQuery内で直接Geminiを実行する方法の紹介でした。

普段Gemiiniに何かを聞くときは料金を気にしないと思いますが、システムに組み込むときにはちゃんと事前にコストを計算しないと、思わぬ請求額へと膨れ上がってしまう可能性があります。特に入力プロンプトは長くなりがちですが、ここは料金にかなり大きく効いてきます。

これからのデータエンジニアリングにとっても、AIを組み込むことが必須になっていますので、その助力になれば幸いです。

参考

• BIqQueryでのAI実行方法
  https://docs.cloud.google.com/bigquery/docs/generate-text?hl=ja
• Vertex AIの料金
  https://cloud.google.com/vertex-ai/generative-ai/pricing?hl=ja
• モデル一覧（実装時に必要なモデルIDを確認できる）
  https://console.cloud.google.com/vertex-ai/model-garden?hl=ja

はじめまして！フューチャー株式会社の田中裕真と申します。

私は2025年10月に新卒として入社し、2026年2月にAIXG(AI戦略推進グループ)のNLPチームに配属されました。配属からちょうど2ヶ月が経ち、これまでのゆったりとした生活から一変して、忙しくも目まぐるしく新しい情報が得られ、知的好奇心を満たしながら働く充実した毎日を送っています。

大学院での研究ではAIの性能調査などを通じてAI自体には触れていたものの、自然言語処理（NLP）分野はあまり経験がありませんでした。現在はNLP関連のキャッチアップを進めながら、チャットシステムの構築業務に携わっています。

本記事では、2026年3月9日(月)〜3月13日(金)にかけて栃木県宇都宮市で開催された言語処理学会第32回年次大会 (NLP2026) の参加報告をお届けします。

当社はプラチナスポンサーとして協賛し、総勢8名がオンサイトで参加しました。スポンサーブースでの企業紹介や、メンバーによる研究発表など、非常に活気あふれる5日間となりました。

言語処理学会とは

言語処理学会は、自然言語処理（NLP）分野における国内最大の学会で、毎年3月に開催されています。第32回となる今年の年次大会は、栃木県宇都宮市でのオンサイト開催とオンライン配信のハイブリッド形式で行われました。

今回の大会は、事前＋直前参加登録者が2236人（歴代2位）に上り、当日参加者を合わせると歴代1位の参加者数を記録しました。さらに、発表件数は797件（歴代1位）、スポンサー数は100団体（歴代2位）と過去最大級の規模となりました。生成AIや大規模言語モデル（LLM）の社会実装が急速に進む中、産学問わず非常に多くの研究者が集い、基礎研究から応用事例まで幅広い議論が交わされる熱気のある学会です。NLP初学者の私にとっても、最前線の研究トレンドを直接肌で感じることができる非常に貴重な機会となりました。

スポンサーブースの様子

企業ブースでは、NLP関連の過去の導入事例や、そのほかのAIXG担当領域について紹介しました。連日多くの方々に足を運んでいただき、NLPの社会実装に関するディスカッションや、学生の皆さんとの交流で大いに盛り上がりました。

今回はノベルティとして眼鏡やディスプレイを拭ける「クロス」と折りたたみ可能な「トートバッグ」を用意しご好評をいただきました。

祝・若手奨励賞受賞！

本大会では、同じAIXGメンバーである藤井の主著論文『TimeMachine-bench: LLMは「あの日」のコードを最新環境に適応できるか？』が、見事若手奨励賞に選出されました！
当論文の背景や解説については、著者の藤井自身が執筆したブログ記事が公開されておりますので、ぜひ併せてご覧ください。

• 【著者解説】NLP2026 若手奨励賞受賞論文 “TimeMachine-bench” を著者が解説する

投稿論文の紹介

当社は、NLP2026において著者・共著者を含めて合計4件の論文を投稿しました。

本章ではこれらの4件の論文について簡単に紹介します。

• [B8-1]UI-Redline-bench: 赤入れ指示によるWebUIコード修正ベンチマーク
  この論文では、WebUI開発における、スクリーンショットに直接手書きで修正指示を書き込む「赤入れ」プロセスに着目し、視覚的指示に基づくコード修正タスクのベンチマーク「UI-Redline-bench」を構築しています。人間にとって直感的な形式の指示に対するVLM（視覚言語モデル）の処理能力に焦点を当て、VLMを活用した開発作業の能率向上への寄与を目指すものです。
  　既存研究が主に言語的指示を扱っているのに対し、本研究は図形や文字を使って描きこまれた視覚的指示を扱う点が特徴です。著者らが視覚的指示を描きこみ作成した、計350件のHTML/CSSコード修正データセットにより、GPT-5等の主要なVLMの視覚的指示に基づくコード修正能力を検証しました。
  検証の結果、GPT-5等は全体として高い修正能力を示した一方で、矢印を使って示された離れた位置に、概形で描かれたUIを実装する事例では、修正に失敗する傾向が見られました。この結果から、今後VLMの空間推論能力の強化が不可欠であると言えます。具体的には、矢印の指し示す位置を正しく認識する、個々の図形を意味のあるまとまりとしてグループ化するなど、空間的に分散した視覚的指示を統合するタスクの必要性が示唆されています。（肥合）
• [B8-3]TimeMachine-bench: LLMは「あの日」のコードを最新環境に適応できるか？
  この論文は本学会において若手奨励賞に選出されました！こちらの技術ブログで詳しく説明されていますので、ぜひご覧ください。
• [B9-19]WikiOriginQA: 知識の起源を組み込んだ文化的バイアス分析用QAデータセットの自動構築
  この論文では、LLMの性能における文化的バイアスを検証するためのQAデータセットと、その自動構築手法を提案しています。LLMの学習データは、英語をはじめとした使用者の多い主要な言語に偏っています。そのため、主要言語圏の知識は良く知っている一方で、マイナーな言語圏の知識は適切に扱えないという文化的バイアスが起こることが知られています。しかし、既存の手法では該当する文化に詳しい協力者を必要とするため、多言語・多文化にわたる調査用データセットの構築は困難でした。そこで本論文では、「ある文化に特有の知識は、その文化と関係の深い言語において最も早くドキュメント化される」という仮説に基づき、文化的知識と言語の結びつきをWikipediaの記事作成日を用いて表現することで、文化的知識を問うQAデータセット「WikiOriginQA」を自動構築しました。
  WikiOriginQAを用いた実験の結果、先行研究と同様にLLMの性能における英語圏の文化へ偏重傾向が確認され、これにより、多様な文化におけるバイアス検証を人手を介さずに行う上で、本手法が有効であることが示唆されました。（羽根田）
• [C9-20]項の復元は必要か？日英機械翻訳における省略された項の扱いの分析
  この論文では、主語や目的語等の述語の項が省略されやすい日本語のような言語 (pro-drop言語) から英語への機械翻訳において、従来重視されてきた「省略された項の同定および復元」が本当に必要かという問題に対し、その必要性を実証的に検証しています。
  具体的には、LLM (GPT-4o) を用いた日英翻訳を対象に、省略項の同定 (ゼロ照応解析) の成否と翻訳品質の関係、および翻訳時に項がどの程度復元されるかを分析しています。また、省略項が復元されなかった場合の構文選択なども含め、多角的な事例分析が行われています。
  その結果、GPT-4oは省略項の同定が困難な事例や項を復元せずに訳した場合においても文意が伝達できる翻訳が行えていました。ただし、項の同定が困難な事例では復元を避ける傾向が見られるなど項の同定可否に伴って翻訳の性質には差が見られました。しかし、省略項を復元しない場合、GPT-4oは述語の名詞化や受動態などを用いることで構文的に自然な翻訳が行えていました。これらの結果から、項の同定・復元は必須ではなく、日英翻訳において最先端のLLMには項の省略はもはや主要な障壁ではないことが示唆されました。 (野末)

社員が選ぶNLP2026の注目論文の紹介

ここからは、NLP2026に参加したメンバーが各自の視点で「これは面白い！」「業務に活かせそう！」と感じたイチオシの論文やセッションを3件ピックアップして紹介します。

• [P8-20] 多言語文埋め込みの意味と言語の分離のための損失関数の分析
  日本語や英語など、言語が違っても似た意味の文同士が近くなるようにベクトル化する「多言語文埋め込み」は、情報検索や機械翻訳の品質推定など幅広い領域で使われています。
  この技術では「言語によらず」意味の近さが反映されることが理想ですが、実際には言語情報に引っ張られてクラスタが分離してしまい、言語横断的なタスクでの性能低下を招くことが知られています。そのため先行研究では、文埋め込みを「意味表現」と「言語表現」に分離し、意味表現のみを用いる手法が提案されてきました。
  この分離のための学習手法（損失関数の設計）には、各要素内で完結する「要素内制約」と、両者に跨る「要素間制約」が存在しますが、これらが分離にどう寄与するかは十分に分かっていませんでした。本研究でこれらを比較した結果、従来のエンコーダ由来モデル（LaBSEなど）では両者の併用が有効な一方、近年のデコーダ由来モデル（Gemini Embeddingなど）では「要素間制約」のみを用いる方が高い性能を示すことが明らかになりました。
  　LLMベースのモデルが普及する中で、従来のモデルとは適した学習アプローチが異なることを実証した事実は興味深いと考え、こちらの発表を取り上げました。（森下）
• [Q3-10] マルチモーダルかつ長い文脈の処理が求められる語用論的推論ベンチマーク
  大規模言語モデル（LLM）や大規模視覚言語モデル（VLLM）において、言語の辞書的な意味ではなく文脈依存の意味を理解するための「語用論的推論能力」の向上は社会実装を目指すうえで重要な課題です。この研究では、特にマルチモーダルかつ長期文脈の処理が必要な設定における語用論的推論のベンチマークを提案しています。
  特徴として、漫画データを題材として採用し、著者が人手で問題・選択肢を作成することで計101問の多肢選択式QAデータセットを構築しています。実際にVLLMと人間による評価実験を行った結果、最新のVLLMであっても正解率は人間を大きく下回り、語用論的推論能力には課題が残っていることが示されました。
  マルチモーダル・長期文脈の処理が必要な設定として漫画を活用している点や、評価実験を通して昨今著しい性能向上が見られるVLLMの弱点を浮き彫りにした点が非常に興味深く、挙げさせていただきました。(岸波)
• [B6-7] クロスコーダーを用いた脳と言語モデルにおける内部表現の特徴量比較
  本研究は、ポッドキャスト聴取時の脳活動（fMRIデータ）と言語モデル（LM）の内部表現を「クロスコーダー」という手法で比較し、両者の情報処理における類似点や相違点を検証した論文です。従来の研究では、LMの表現から脳応答を予測するエンコーディングモデルが主流でしたが、これはLMから脳への一方向的な写像に留まり、予測の根拠となる要因を人間が理解できる形で抽出できない（解釈性が低い）という課題がありました。
  本手法では、脳応答とLM表現の両方を同一のスパース（疎）な潜在空間に写像し、そこからそれぞれの表現を再構成するプロセスを学習します。この仕組みにより、抽出された特徴量が脳とLMのどちらに強く寄与しているかを定量的に評価することが可能になりました。実験の結果、「場所」に関する描写は脳とLMで共通して表現されている一方、「負の情動」は脳側に、フィラー（言いよどみ）などの「口語表現」はLM側に特有の反応として抽出されました。
  fMRIの解像度の限界や、因果関係の特定といった課題はあるものの 、AIの内部表現と人間の理解を直接比較し、その差を数値で示せる点は非常に画期的です。知性の在り方を定量的に議論できる可能性に興味を惹かれ、本論文を取り上げました。（田中）

会場の様子・オフタイムのエピソード

オンサイト参加ならではの、現地の雰囲気やエピソードも少しご紹介します。

最も印象的だったのは、学会オープニングでの出来事です。全プログラム終了後に「重要な注意事項」と銘打たれたスライドで宇都宮餃子の正しい食べ方のレクチャーがありました。開催地である宇都宮ならではの粋な計らいに、会場全体が温かい笑いと拍手に包まれました。

また、天候に関しては驚きの連続でした。開催2日目には、3月であるにもかかわらずなんと大雪に見舞われました。会場周辺の道も真っ白に雪が積もり、ある意味で非常に記憶に残る学会となりました。

一方で、天気の良いお昼時には会場の外にキッチンカーが出店しており、日差しを浴びながら外でランチを楽しむこともできました。

おわりに

NLP初学者としての参加でしたが、日々の業務に直結する知見や、LLMの最新動向など、膨大なインプットを得ることができました。何より、最前線で活躍する研究者やエンジニアの熱量に直接触れることができ、「自分もさらに技術を磨いていこう」と強くモチベーションを刺激されました。

現在、AIXGのNLPチームでは、以下のような環境・制度を整え、NLPの基礎・応用技術開発を積極的に推進しています。

• 大学との共同研究
• 社会人博士制度
• 新規参画者への教育プログラム
• GPUクラスタ

こうした環境のもと、ともに働くメンバーを積極的に募集しています！

学生の皆様へ
夏季インターンやアルバイトについては、4月20日 (月) に下記のウェブサイトから募集を開始いたします。
また、博士課程向けのResearch Internは通年募集中です。

https://www.future.co.jp/recruit/summer_intern/2026/

昨年のインターンシップ参加者へのインタビューもぜひご確認ください。

https://future-architect.github.io/articles/20260323a/

新卒・キャリア採用について
NLP分野における社会実装のニーズは拡大し続けており、自然言語処理の力で顧客のビジネス課題を解決していく仲間を求めています。少しでも興味を持っていただけた方は、ぜひ以下の採用リンクからご応募をお待ちしております！

• 新卒採用 : https://www.future.co.jp/recruit/recruit/rec-fresh/
• キャリア採用 : https://www.future.co.jp/recruit/recruit/rec-career/

こんにちは。Strategic AI Group (SAIG) の藤井です。

この度、3/9 (月) 〜 3/13 (金) に栃木県は宇都宮市で開催された言語処理学会第32回年次大会 (NLP2026) において、光栄なことに主著論文 TimeMachine-bench: LLMは「あの日」のコードを最新環境に適応できるか？ が若手奨励賞に選出されました。
論文の審査を担当いただきました関係者の皆様にこの場をお借りして感謝いたします。

本記事では、当該論文、およびその拡張版であるEACL2026 (Main Conference) 採択論文 TimeMachine-bench: A Benchmark for Evaluating Model Capabilities in Repository-Level Migration Tasks (3/24 〜, モロッコ・ラバトにて開催) を著者として解説します。

背景

研究や業務でプログラムを書く人であれば、誰しもがこんな経験をしたことがあるのではないでしょうか？

あれ、昨日までは動いていたのに… 何もしてないのに壊れたー！

我々 (あるいはAI) が日頃書くプログラムは、その多くが外部のライブラリに依存しています。例えば、 transformers や pytorch、openai といったライブラリにお世話になっている人も多いのではないでしょうか？

しかし、ソフトウェアというものは常に進化しています。

これには、より便利な機能を追加するといったポジティブな側面はもちろん、セキュリティ脆弱性や、サポート切れ (EOL) への対応といったものも含まれます。そして、そのような進化は時として「破壊的変更」(breaking changes) をもたらします。

すなわち、なんらかの関数が削除されたり、取りうる引数が変わるなど、引き続き使い続けるためには、それらを利用する側のコードにも修正が必要になるような変更が度々発生します。そうした変更は「利用者の望む望まざるに関わらず」依存ライブラリのどこかで突然発生しうることから、冒頭に述べたような (我々は)「何もしてないのに壊れたー！」が生み出される原因となるわけです。

このような「不可抗力」的な性質も相まって、ユーザコードを新たな環境に適応させるタスクである「ソフトウェアマイグレーション」はエンジニアの悩みの種となっています🌱。

さて、世はLLM時代。

もはや人間が一からコードを書くことは少なくなった今、LLMは「マイグレーション」もそつなくやってのけるのでしょうか？
本研究はそんな疑問から出発しました。

先行研究のギャップ

static vs. dynamic

数年前には短い関数の補完すらままならなかったCode LLMsも、今や日頃の開発パートナーとして欠かせない存在となっています。

このような急速なモデルや手法の進化を支えているのが、モデルの性能を評価するベンチマークの存在です。初めはHumanEvalやMBPPといった関数レベルのコード補完タスクが中心でしたが、それらが徐々に解けるようになり、現在ではエンジニアの日常業務を模したより実世界的なタスクにフォーカスが移行しています。例えば、現在Code LLMs評価のデファクトであるSWE-benchは、GitHubのissueを読み、issueに記載された問題を解決するためのパッチを作成するという非常に実用的な課題を対象としています。

しかしながら、そうした先行研究はソフトウェアのある重要な側面を軽視してきました。それが冒頭に述べた「進化」です。

言葉の使われ方が時を経て変化するように、ある機能を実現するために正しいプログラムもバージョンの変遷とともに変化します。近年では、このように「進化」する環境におけるコード生成・マイグレーション能力にも注目が集まってきています。

一方で、それらの先行研究はしばしばスケーラブルではなく、タスクの内容も「新旧の対応を知っているかを問う一問一答」のような形式となっており、現実的なマイグレーションタスクのベンチマークとしては不足感が否めない状況にありました。

手法の限界

では、なぜそのような課題が生じるのか。

これは、主に先行研究がどのようにタスクを作成していたか、という手法の限界による部分が大きいと考えます。例えば、ある先行研究 では、バージョンごとのソースコードを収集し、その差分から破壊的変更が発生したバージョン (例えばpandasのv2.0で df.append() が削除された) を特定することで、Q. pandas v2.0 では？ df = [WRITE_HERE] といった問題を作るといった方法を取っています。また、他の研究 では、ライブラリのドキュメンテーションをデータソースとして取り扱っています。

しかしながら、このような手法こそが先に述べた2つの欠点をもたらす元凶となっています。

例えばソースコードの差分を比較する場合、その解析コストは「ライブラリ数×バージョン数」の速さで増大します。世の中に (Pythonに限定しても) 数十万と存在するライブラリに対して、そのような解析をすることは現実的ではなく、事実、先行研究でも対象は主要な300ライブラリに限定されています。

また、ドキュメンテーションを用いる方法では、そもそも世の中の多くのライブラリは十分なドキュメントが整備されていないという点にも留意が必要です。

さらに、個々の破壊的変更の情報から、多段階のエラー解決や複数ファイルの修正を含むリポジトリレベルの課題をボトムアップに作成することは困難であることから、タスクは必然的に局所的、シングルステップのいわば「一問一答」と呼べるものに限定されていました。

TimeMachine-benchの提案

コアアイデア

さて先行研究では、マイグレーションを「あるバージョンで動いていたものが、別のあるバージョンでは動かなくなった」ものを探すというように「バージョン」のカットで捉えていました。

しかし、これは少し視点を変えれば、それまで正しく動いていたものが「ある日を境に」動かなくなるという「時系列」の問題に読み替えることができます。つまり、過去のある日の (を再現した) 環境では正しく動作するが、今はもう動かない、といったものを、日付の指定のみで抽出できる、ということです。そうすれば、「どのライブラリの、どのバージョンが犯人か」を知らずとも、ライブラリごとの解析をすることなく、マイグレーションタスクを構築できるのではないか？というのが本研究のコアアイデアです。

では、どのように過去の環境を再現するのか？

ここに本ベンチマークが “TimeMachine-bench” たる所以があります。

まず、Pythonのパッケージマネージャである pip がどのように依存関係を解決するかを簡単に説明すると、pip は pip install ... でインストールのリクエストを受けると、Pythonの公式パッケージリポジトリである PyPI (The Python Package Index) にパッケージのメタデータをリクエストします。このメタデータには、当該ライブラリのバージョン情報と各バージョンが要求する依存ライブラリのバージョン情報などが含まれており、 pip は受け取ったメタデータを元に、バージョン指定子の条件 (==や>=など) や他ライブラリとの整合性を判断して最終的にインストールするバージョンを確定します。

ここで、もしPyPIが例えば 2025年7月までのリリース情報しか持っていない としたらどうなるでしょうか？この場合、pip は2025年7月までにリリースされていたライブラリのバージョンと、それらが依存するライブラリの、同じく2025年7月までのバージョン情報をもとに、最終的にインストールするバージョンを決定します。

つまり、所定のカットオフ日以降の情報をフィルタしたパッケージリポジトリを経由すれば、 pip の依存関係アルゴリズムや環境構築手順に一切のテコ入れをせずとも、あたかもその時点にいるかのように (タイムトラベルしたかのように) 過去の環境を再現できるわけです。

本研究ではこのアイデアの具現化に際して、pypi-timemachine という素晴らしいOSSを活用させていただきました。具体的には、環境構築の際 PIP_INDEX_URL (パッケージメタデータの問い合わせ先) を公式のPyPIサーバではなく、dockerで構築したローカル環境のタイムマシンサーバに向けることで、PyPIへのリクエストをプロキシし、過去の指定日における環境の (ほぼ*) 厳密な再現を実現しました。

データセットの構築

先述のアイデアのもと、本研究では The Stack v2 から、ユニットテストが実装されているPythonリポジトリを選定のうえ「2つの異なる断面 (日付) でテストを実行し、テスト結果が Pass → Failとなるものを抽出する」 全自動のパイプライン を構築しました。
全自動であるというのは、すなわちデータセットの「継続的な更新が可能である」ということです。

評価データが学習データに混入することで評価の妥当性が失われる「データ汚染」が深刻な課題となる昨今、このような “ライブ” なパイプラインには大きな意味があります。

さらに、本研究では人手の検証により「所与の環境下で解けることを保証した」100件のサブセット (Verified) を構築しました。
「所与の環境下で解ける」ものに限定した背景として、もしLLM (エージェント) に環境へのテコ入れを許容すると、任意のマイグレーションタスクはダウングレードにより (テストを通すだけであれば) 解決できる、ということが挙げられます。
しかしながら、そのようなショートカットが、マイグレーション本来の目的に即していないことは火を見るより明らかです。
一方で、自動パイプラインにより抽出されたリポジトリの中には、ダウングレード以外での解決が本質的に困難なものも一定数含まれます。

例えば、当該リポジトリが依存するサードパーティライブラリの実装において、バグの修正、あるいは何らかの仕様変更により計算誤差が生じるようなケースです。今回は、モデルに安易なショートカットの選択肢を与えず、コードの修正によってマイグレーションに対応する能力を評価するため、Verifiedサブセットで評価することとしました。

なお、Verifiedサブセットの構築にあたっては、問題の解決に必要な最小限の修正 (Gold Edit)、および人が解決までに要した時間に応じた問題の難易度 (Easy: 〜15分, Medium: 〜1時間, Hard: 〜2時間) のアノテーションを行いました。

以下は実際の問題の例となります。

この問題では pandas のアップデートに関連して複数のランタイムエラーが発生しますが、1つのエラーを解決することで初めてその背後に隠蔽されていた別の不具合が顕在化するという多段の構造になっており、マイグレーションを対象とした既存のベンチマークとの違いが見て取れます。
また、データセット中に含まれるエラー関連ライブラリは numpy や flask といったメジャーなものはもちろん、 pysnmp のように特定のドメインでのみ用いられるものなど多岐に渡っており、日付ベースの環境構築 (タイムマシン) の優れたスケーラビリティが確認できます。

現在の到達点

本研究では、最終的にタスクを解決できたか (pass@1) に加えて、人手のアノテーション (Gold Edit) と比較して無駄のない修正ができたか (prec@1) 、という2つの観点からモデルの性能を評価しました。
マイグレーションの本質は新環境への適応であり、コード品質の改善を目的とする「リファクタリング」とは本質的に役割が異なります。

両者を同時に行うことは変更の意図を不明瞭にし、レビューコストの増大や予期せぬバグの混入のリスクを増大させることから、「環境に適応するための最小限の変更」を特定する能力についても評価することとしました。

実験では、4つのプロプライエタリモデル、および7つのオープンモデルを評価しました。ファイルの探索や多段の問題解決を要する「リポジトリレベル」のマイグレーションタスクについては標準的なアプローチが確立されていないことから、今回はSWE-benchに対する解法の1つであるSWE-Agentを参考に、10種のツールからなるReActエージェントをベースラインとしました。

モデルは最初の入力として、環境における各ライブラリのバージョンと初期のエラーログを受け取り、10種のツールを駆使しながらエラーの解決を目指します。最大で100回のLLM呼び出し (≒100回のツール利用)、10回のテスト実行の制限を設定し、この制限内でどれだけタスクを解決できたかを評価しました。

以下がTimeMachine-bench-Verifiedにおける11モデルの評価結果です。
※ Easy, Medium, Hardは各難易度の正解数、および正解率 (括弧内)

この表を見てまず目につくのは、Claude Sonnet 4の99.0%という高いタスク解決率でしょう。また、オープンモデルの躍進も注目に値します。特に、Qwen3-Coder-480Bは前世代のフラグシップモデルであるClaude 3.5 Sonnet v2やGPT-4oに匹敵、もしくはそれらを上回るスコアを記録しました。

従来ベンチマーク化されてこなかった「リポジトリレベル」のマイグレーションという (モデルにとって) 未知のタスクにおいて、これだけのスコアを達成したということは、モデルが単に既存のベンチマークを暗記しているのではなく、実用的なエンジニアリングタスクに対して一定の汎化性能を有することを示す結果であると考えられます。

しかし、手放しでは喜べない懸念点もいくつか残されています。

まず、無駄のない修正という観点では、最もスコアの高いClaude Sonnet 4でさえ、20%以上 (prec@1 = 78.0%) の、課題解決に寄与しない修正を行なっているという点が挙げられます。これは一部のモデルではより顕著であり、例えばGPT-5は91.0%と高いタスク解決率を達成する一方で、その修正の約45%は過剰な修正であったことが確認できます。

また、タスクの難易度に着目すると、唯一の例外であるgpt-oss-120bを除いては、難易度の上昇に伴いタスク解決率が低下する一貫した傾向が見られました。特にHardの問題ではClaude系列を除くモデルの解決率が50%未満に留まるなど、人間にとって難しい問題は多くのLLMにとっても依然難しいということが示されました。

マイグレーションは解決済みなのか？

先に述べたような課題こそあれ、99%という高いスコアを見れば当然このような疑問が浮かぶでしょう。

しかしながら、我々は、この課題はまだ「解決済みとはほど遠い」と考えています。

その理由として、まずひとつにVerifiedサブセットの構築方法に起因する選択バイアスが挙げられます。人手での検証は安易なショートカットの除外というポジティブな側面 (信頼性) と引き換えに、人間が (妥当な時間で) 解ける程度の難易度に限定してしまうという欠点も持ち合わせています。すなわち、実世界の問題はHardや、2時間よりもずっと長くかかるが不可能ではないようなUltra-Hardの問題をより多く含むということです。

また、今回はダウングレードを禁じ手としましたが、真に有用なエージェントは、然るべき状況では (ダウングレードが唯一の正解であるような状況では)、選択的にダウングレードするといった判断も行いながら問題を解決することが期待されます。
そのため、この結果はマイグレーションタスクが99%解決されたことを保証するものではなく、「人間が短時間で対処可能な」課題に対する一定の自動化の可能性を示すものと解釈するのが妥当だと考えています。

また、個々の事例を分析すると99%という数字の裏に隠れたトリックも見えてきます。

以下の問題では pysnmp.hlapi パッケージに定義されていた定数が、他の場所に移動したことに伴って発生するimportエラーを解決することが期待されます。ここで、Claude Sonnet 4はいくつか候補として考えられるパスを試したのち、それらがいずれも不正解であることがわかると、最終的には図のようにtry-exceptブロックのネストとダミー変数の定義によりエラーをバイパスするという手段を選択しました。

この例は、モデルとデータ、双方に残る信頼性の課題を浮き彫りにするものです。

まず、モデルの側面として、このように「意味的な正しさよりもテストの通過を優先する」選択をすることはpass rateへの過度な最適化の弊害と考えられます。無理にハックしてでも進むのではなく、自身の限界を正しく認識し「ここでは立ち止まる (あるいは人間に助けを求める) べきだ」という判断を下すことのできる高度なメタ認知能力の獲得は、今後のLLM開発における大きな課題であると考えられます。データの側面としては、このようなハックを見抜けないテストケースの危うさが挙げられます。

今回のケースではインポートされた定数がどのように使われるか、といった挙動をチェックするテストケースが定義されておらず、それゆえ、このような回答が「見かけ上は」正しいと判断されてしまいました。

これは、本研究で構築したデータセットが、GitHubリポジトリに紐づく既存のテストケースに依存していること、および (人間が書いた) それらのテストケースが往々にして不足していることに起因します。ユニットテスト自動生成 (UTG) のような技術を統合することで、より頑健、かつチャレンジングなベンチマークの構築を目指すことは、今後の有力な方向性のひとつだと考えています。

後日談

今回の話は、SWE-benchの下に名前を載せるという意気込みで取り組みました。

その意味では、手法のピースがはまり、初めてモデルに解かせた際「あまりにも解けてしまった」ことには、モデルの進化に対する驚きとともに、なんとも言えない悔しさが入り交じる複雑な心境を抱かずにはいられませんでした。

先に述べたようなテストの穴を塞ぐ、大規模な人手検証を通して難易度の高い (人間にとって時間のかかる) 問題のみを集める、といった方法でこのタスク成功率は70%, いや50%にもできたかもしれません。

しかし、たとえこのデータセットの寿命は出た瞬間に尽きていたとしても、この方法論を早く世に出すことにこそ意味があると考え、このように公開するに至りました。

果たして近い世の中、コンテナ開発のように、コードも「壊れたら使い捨て」「メンテナンスよりもスクラッチで作り直し」という時代になるのかもしれません。

しかし、実際のプロジェクトでは (望ましくないことではありますが) 検討段階で漏れていた仕様がコードのみに反映されているといった不一致や、そもそも「コードこそが仕様書」であることも少なくありません。
仕様とコードの自由な往来が達成されるまでの間においては、人間はこの厄介な業務と付き合っていくことになるでしょう。

本研究が、マイグレーション、バージョンや時系列を扱うCode LLMs研究の道標となり、より実用的で信頼できるLLMの実現に向けた議論を加速させる一助となれば、著者としてこれほど嬉しいことはありません。

おわりに

今回は、NLP2026にて若手奨励賞を受賞した自著論文 “TimeMachine-bench” について、裏話も含めてじっくりと解説させていただきました。

改めまして、論文の審査を担当いただきました皆様に、この場をお借りして感謝申し上げます。

この記事を読んで興味を持っていただけましたら、ぜひオリジナルの方もご一読いただけますと幸甚です。引き続き、本分野における研究の発展とその社会還元に貢献していきたいと思います。

ここまでお読みいただきありがとうございました！

フューチャーではともに働くメンバーを募集しています。

ご興味を持っていただいた方は、ぜひ キャリア採用サイト からのご応募をお待ちしております。

はじめに

はじめまして。2023年4月に新卒入社し、流通サービス事業部に所属している高橋です。

これまで主にシステム構築フェーズを経験してきましたが、直近ではデータ分析プロジェクトに分析メンバーとして携わりました。

本記事では、データ分析のプロジェクトを進める中で「実務上どのようなポイントで悩みやすいのか」「分析をスムーズに進めるために何に気を配るべきか」といった視点で、自分なりの学びをまとめました。

本プロジェクトにおけるデータ分析の位置付け

データ分析において最も重要なことは、単に「分析すること」ではなく、「解決すべき課題に対して、どの領域で、どのような分析をするか」という事前の設計にあります。

今回の取り組みは、ある領域で実績のあるシステムを異なるビジネスドメインへ適応させ、オペレーションの効率化を目指すものでした。この最適化を実現するためには、前述した「設計」の精度が成否を分ける鍵となります。

そのため、本プロジェクトは大きく分けて次の2つの要素で構成されていました。

1. 既存ロジックの新領域における適応可能性の検証
2. 検証の効果を正しく評価するための「分析対象」の選定

特に「2」については、単に手元のデータを処理するのではなく、「ビジネスインパクトがどこにあるのか」「どのデータを抽出して評価すべきか」をゼロから検討する必要があり、データ分析を通じた意思決定が強く求められるパートでした。

なぜ「分析対象の選定」が重要だったのか

結論から述べると、拠点によって状況が正反対であり、全てのデータをひとまとめに集計すると本来解決すべき 「歪み」が平均化されて見えなくなってしまうからです。

本プロジェクトの背景には、複数の拠点を展開するビジネスモデル特有の「需要と供給のミスマッチ」という課題がありました。

• 高需要拠点：商品の売れ行きは好調な一方、在庫不足による機会損失が発生している
• 低需要拠点：商品があまり売れず、余剰在庫がコストを圧迫している

仮に、これら「不足」と「余剰」のデータを一括りで分析してしまうと、数値上は過不足が相殺され、あたかも「ちょうど良い状態」であるかのような結果が出てしまいます。

こうした不均衡を解消し、実効性の高い改善を実現するためには、全方位を漠然と分析するのではなく、「どこを分析対象として定義し、どのデータで課題を可視化すべきか」という設計が、プロジェクトの成否を分けるポイントとなりました。

「検証対象」定義の難しさと学び

本プロジェクトにおいて、対象となる店舗や商品群の大枠は早い段階で決まっていました。

しかし、実務レベルで「検証の切り口をどう定義するか」という点には、想像以上に丁寧な検討が必要でした。単に「どこを分析するか」だけでなく、どのデータを用い、どの条件で切り出すのが検証として最も意味があるのか。この「切り出し方」の定義をいかに精密に行うかが、今回の大きな学びとなりました。

試行錯誤の中で見えてきた、検証対象の定義や分析において欠かせない視点を、4つのポイントで詳しくお伝えします。

1. データ構造の早期合意

初期の検証段階ではスピードが重視されますが、使用するデータの定義や粒度の合意を後回しにすることはリスクが伴います。

「このデータを使う前提で進めて良いか」という認識合わせが不十分だと、後続の工程で大きな修正コストが発生してしまいます。

本格的なデータ分析に着手する段階で、どのデータをどの粒度で使うかをクイックに合意しておくことの大切さを痛感しました。

2. データ分析におけるターゲットの定義と対象範囲の設定

限られた期間で成果を検証するためには、膨大なデータの中から「どこを対象とするか」を戦略的に決める必要があります。

今回は、漠然と課題を探すのではなく、規模感や変動率などのデータに基づき、ビジネスへの影響が最も大きい領域を分析によって特定しました。

実効性を証明するため、以下の2軸で対象を絞り込んでいます。

• 高インパクト領域の特定
  • 全体の成果への貢献度が高く、改善が直接的な利益向上につながりやすい領域を抽出
• 検証の妥当性の確保
  • 十分なデータ量が確保でき、分析結果の有効性を正しく評価できるセグメントを定義

このように、分析を通じて「どの範囲で検証するのが最も効果的か」という合意形成の根拠を作ることが、プロジェクト初期における極めて重要なステップであると学びました。

3. 分析意図の明確化

分析を進める際、複数の条件を組み合わせてデータを段階的に絞り込んでいく作業が発生しました。

ここで重要だったのは、単なる計算作業として進めるのではなく、「なぜこの条件で絞り込むのか」という分析意図を正しく理解することでした。

実務において特に意識すべきだと感じたのは、以下の2点です。

• データの「業務的な意味」を定義する
  • 「この条件で抽出されたデータは、実務上のどのような状況を表現しているのか」という背景を常に意識する
• 判断軸を明確化する
  • 単に数字を示すのではなく、「どの数値を用いて意思決定を行うか」を、関係者と合意しながら進める

「何のために算出しているのか」という意図が抜けると、アウトプットは「ただの結果報告」に終わってしまいます。

分析工程の全ステップにおいて、ビジネス的な意味付けを徹底することが、精度の高い検証には不可欠だと実感しました。

4. 分析結果は「計算結果」ではなく「意図」を出力

分析結果として出力する成果物は、単なる数値の羅列では不十分です。

「何のための数値か」「どの条件で絞られたものか」がひと目で伝わらなければ、意思決定の判断材料にはなりません。

例えば、特定の対象を抽出する場合、以下のように「数値が絞り込まれていくプロセス」をセットで提示することが重要です。

具体例：新商品プロモーションの対象選定

単に「対象は150件です」と報告するのではなく、絞り込みのステップに「意図」を添えて出力します。

このように、数値の関係性が ① ＞ ② ＞ ③ となるプロセスを明示することで、読み手は「なぜこの150件なのか」という根拠を即座に理解できます。

「プロセス」が信頼を生む

単に「結果は150件です」とだけ伝えるのと、「1,000件の全体像からノイズを除き、戦略対象である150件に絞り込みました」と伝えるのとでは、情報の信頼性が全く異なります。

「分析資料は単なる計算結果の提示ではなく、意図を表現するための成果物である」という意識を持つことは、読み手の疑問を先回りして解消し、スムーズな意思決定を促す鍵になると実感しました。

さいごに

今回のプロジェクトでは…

• 検証対象をどう定義するか
• どのデータを活用し、何を判断の軸にするか

…といった、分析以前の設計部分に多くの学びがありました。

データ分析というと手法やロジックに注目が集まりがちですが、実務ではむしろ…

• データ構造の合意
• インプットデータの整理
• 分析意図の共有

…といった「土台」となる部分が、プロジェクトの成否を左右することを強く感じました。

本記事が、データ分析に携わる方の参考になれば幸いです。

参考

詳細なデータ分析手法や実装面については、下記に記載されておりますので、あわせてご覧ください。

• データ分析でプロジェクトをリードした話
• システム開発からデータ分析へ。やってみて気づいた技術選定と実装のポイント

はじめまして。2023年10月にキャリア入社した篠原です。

これまではシステム開発がメインでしたが、最近データ分析の業務に関わらせていただく機会がありました。そこで求められる成果物、注力すべきポイント、そして技術選定の観点など、従来のシステム開発とは異なる部分が多く、様々な気づきがありました。

自身の振り返りも兼ねて、その知見を共有したいと思います。

なお、データ分析の目的と流れについてはこちらの過去記事も併せてご覧ください。

データ分析で求められるものと意識すること

会社や組織が意思決定を行う上で様々な手法がありますが、データを用いた定量的分析は重要な判断材料となります。

• 「どこに施策を打つのが効果的だろうか」
• 「施策を打った結果、どのような効果があったのか。その結果を元に今後の動きを考えたい」

こうした問いがある際、「正確さ」はもちろんですが、次のアクションへ繋げるために「スピード」も重要になる場面が多いです。これらの問いに正確かつスピーディーに答え、提案するには、分析そのものに全力を注ぐべきであり、ツール選定や環境構築、分析の実装における「不安定な要素」は極力取り除くべきです。

実際にデータ分析を通して、これらの不安要素を取り除くために気をつけるべき点をお話しします。

検証環境:

OS: Ubuntu 22.04.5 LTS (WSL使用)
CPU: i7-1255U
RAM: 16GB
Python: 3.10
pandas: 2.0.2
PostgreSQL: 17.4

分析で使用するツール（言語）の特徴を理解して使い分ける

データ分析に使用される技術としては Python (pandas)、R、RDB (PostgreSQL、SQL) などが挙げられます。

これらは「分析ができる」という点は共通していますが、得意分野が異なるため、状況に応じて使い分けることが重要だと感じました。代表として Python と RDBの特徴を比較します。

※なお、PythonでTB級などのさらに大規模なデータを扱う場合は、DaskやPySparkといった分散処理ライブラリの利用が選択肢に入ります。今回はローカル環境（メモリ16GB程度）で完結する規模の分析を前提としていることと、DaskやPySparkにもある一定のキャッチアップが必要ということも考慮し、既にメンバーの経験があるpandasを使用しています。

以上の特徴を踏まえて、pandas と RDB は下記のように使い分けると分析がスムーズでした。

• RDB を使用すべき場面
  • 分析対象や期間が定まっておらず、大容量データに対して探索的に分析する場面
  • 詳細な分析の前に、大規模なマスタやトランザクションデータを結合し、中間データを準備する場面
• pandas を使用すべき場面
  • データの準備が整ってからの、詳細な加工や分析が必要な場面。
  • データ規模が小さく、複雑な結合が不要な場面。
  • 可視化や機械学習へのパイプラインとして使用する場面。

データ型については、pandasでCSVを読み取る場合も、dtypeで型を指定できますが、多くのカラムに対しての指定する場合、小規模の分析の場合でもコード数が増えやすいです。

m_product_df = pd.read_csv(
    "data/m_products.csv",
    dtype= {"product_id" : str}
)

t_sales_df = pd.read_csv(
    "data/t_sales.csv",
    dtype={
        "product_id": str,
        "quantity" : int,
    },
)

merge_df = pd.merge(
    t_sales_df,
    m_product_df,
    how="left",
    on="product_id",
)

merge_df

そのため、型定義が重要かつ、複雑な局面はなるべくRDBで実装をする方が、考慮すべき点も少ないと感じました。

当初は「早く結果を出したいので、慣れている pandas を使おう」という判断で進めていましたが、大規模データの分析では考慮すべき点が増え、かえって時間がかかってしまうことがありました。

また、小規模な分析であれば Excel の方が直観的に操作でき、可視化まで完結する場合もあります。分析を始める前に、チーム内で適切な技術やツールを検討することをお勧めします。

これまでの分析の流れを図示しておく

分析業務では詳細な設計書を作成する時間は確保しにくいですが、データの流れを図示してチーム内で共有することをお勧めします。

データ分析では、分析した結果を基に話し合いそれを受けてさらに詳細な分析や、別角度からの分析を重ね最終的な結論を出すというパターンが多いと思います。

ER図としては複雑ではなくとも、仕様変更や追加の要望が来る頻度は高く、それが重なってくると今までの経緯が抜け落ちやすくなり、「この値は何のために出すんだっけ？」と目的がわからなくなってしまうこともあります。

それを防ぐためにも簡易的な図示でも良いので、これまでの分析の経緯と決定事項、PGのデータの流れを記載しておくことは非常に有効と考えます。図の体裁の善し悪しは重要でなく、メンバー全員が1つの図を指しながら、今までの決定事項と立ち位置を理解して次のアクションを考えることが重要です。

処理速度に固執しすぎず、一般的に速くなる技法を持っておく

分析コードやクエリの実装において、パフォーマンスは重要です。システム開発同様、処理が遅すぎると業務に影響が出ます。

しかし、データ分析のコードは「毎日頻繁に実行される」とは限らず、「1回きりの実行」になることも多々あります。

パフォーマンスチューニングは突き詰めるとキリがありません。全ての処理を限界まで高速化しようとすると膨大な工数がかかってしまいます。そのため、「これをやっておけば間違いなく速くなる」という定石テクニックの適用にとどめ、特に1回きりの分析であればそれ以上の深追いはしないという割り切りが重要です。

その技法を一通り実装し、それでも許容できないほど遅ければ初めて追加のチューニングを検討する。このスタンスが、工数とパフォーマンスのバランスとして最適解だと感じました。

内容はpandasに寄っていますが、その技法を一部ご紹介させていただきます。

1. 取得するカラムは必要なもののみに絞る

取得するカラムを絞ることの必要性は、SQLだけではなく、pandas でも同様です。

pandas は読み取ったデータをメモリ上に展開し、処理の過程で新たな変数を生成します。そのためメモリが枯渇しやすい傾向にあります。速度面だけでなく、メモリ使用量の観点からもカラムの絞り込みは意識すべきです。

例えば、5000万レコード・20カラムのデータを全件読み込むと、以下のようにメモリ不足でプログラムは落ちることがあります。

import psutil
import time
import pandas as pd


def measure_time(func):
    """関数実行完了までに要した時間を出力"""

    def wrapper(*args, **kwargs):
        start = time.time()
        result = func(*args, **kwargs)
        elapsed = time.time() - start
        print(f"  Result Time: {elapsed:.4f} sec")
        return result

    return wrapper


def print_memory_status(label=""):
    """メモリ状況を出力"""
    mem = psutil.virtual_memory()

    # byteをGBに変換
    total_gb = mem.total / (1024**3)
    available_gb = mem.available / (1024**3)
    used_gb = total_gb - available_gb
    percent = mem.percent

    print(f"[{label}] RAM Status:")
    print(f"  Total:     {total_gb:.2f} GB")
    print(f"  Used:      {used_gb:.2f} GB ({percent}%)")
    print(f"  Available: {available_gb:.2f} GB")


@measure_time
def read_big_data():
    """巨大データの読み取り"""
    print_memory_status(label="BEFORE LOAD")
    try:
        # 全カラム読み込み
        df = pd.read_csv("data/t_sales.csv")
        print_memory_status(label="AFTER LOAD")
    except MemoryError:
        print("メモリ枯渇")
        print_memory_status(label="ON CRASH")
    except Exception as e:
        print(f"Crashed: {e}")


# 実行
read_big_data()
# -> メモリ枯渇でクラッシュ

usecols を使用して必要なカラムのみ読み込むことで、メモリを節約できます。

# 時間やメモリ計測の関数やラッパーは省略
@measure_time
def read_big_data():
    print_memory_status(label="BEFORE LOAD")
    try:
        df = pd.read_csv(
            "data/t_sales.csv",
            usecols=["user_id", "product_id", "quantity", "sale_date"],
        )
        print_memory_status(label="AFTER LOAD")
    except Exception as e:
        print(f"Crashed: {e}")


read_big_data()

出力結果（例）:

[BEFORE LOAD] RAM Status:
  Total:     11.68 GB
  Used:       7.68 GB (65.8%)
  Available:  4.00 GB
[AFTER LOAD] RAM Status:
  Total:     11.68 GB
  Used:       9.52 GB (81.5%)
  Available:  2.16 GB
  Result Time: 31.3573 sec

2. ループ処理は避け、集約関数を活用する

pandas において、for ループによる行ごとの処理は非常に低速です。

以下は、10万レコードのデータに対して product_id ごとの集計する比較です。

【for文を用いて行う場合】 実行時間: 約91.37秒

# merge_df: 結合済みの元データ

result_df = merge_df[
    [
        "product_id",
        "product_name",
        "category",
    ]
].drop_duplicates()


start = time.time()
for index, row in result_df.iterrows():
    # 現在実施中のproduct_idのレコードを出力する
    product_id = row["product_id"]
    target_df = merge_df[merge_df["product_id"] == product_id]

    # 売上合計を算出
    result_df.loc[
        result_df["product_id"] == product_id,
        "total_quantity",
    ] = target_df["quantity"].sum()

    # 売上回数を算出
    result_df.loc[
        result_df["product_id"] == product_id,
        "sale_count",
    ] = len(target_df)

    # ギフト注文の回数を算出
    gift_count = len(target_df[target_df["is_gift"] == "t"])
    result_df.loc[
        result_df["product_id"] == product_id,
        "gift_count",
    ] = gift_count

elapsed = time.time() - start
print(f"  Result Time: {elapsed:.4f} sec")

result_df

【集約関数 (groupby) と merge を用いて行う場合】 実行時間: 約0.06秒

result_df = merge_df[
    [
        "product_id",
        "product_name",
        "category",
    ]
].drop_duplicates()


start = time.time()


# 売上合計を算出
quantity_df = merge_df.groupby(["product_id"])["quantity"].sum().reset_index()
result_df = pd.merge(
    result_df,
    quantity_df,
    on="product_id",
    how="left",
)


# 売上回数を算出
count_df = merge_df.groupby(["product_id"]).size().reset_index(name="sale_count")

result_df = pd.merge(
    result_df,
    count_df,
    on="product_id",
    how="left",
)


# ギフト注文の回数を算出
gift_count_df = (
    merge_df[merge_df["is_gift"] == "t"][["product_id"]]
    .groupby(["product_id"])
    .size()
    .reset_index(name="gift_count")
)


result_df = pd.merge(
    result_df,
    gift_count_df,
    on="product_id",
    how="left",
)

elapsed = time.time() - start
print(f"  Result Time: {elapsed:.4f} sec")

result_df

pandas は Python の構文（for文やif文）を使っても実装できますが、集約関数を用いた計算は圧倒的に高速です。

チームメンバーが pandas に不慣れで groupby を自由に扱えなくても、多少の時間を割いてでも扱えるようになることはデータ分析では重要となります。

出力すべき粒度を意識する

分析の実装に没頭すると、目の前のデータ処理にリソースが割かれ、本来の目的と逸れて分析してしまうこともあり得ると思います。

これを防ぐために、常に「出力すべき粒度（分母）」の認識合わせを行うことをお勧めします。

具体例として、「クーポンを発行すべき商品」を選定するケースを考えます。

• 売れている商品は、さらにクーポンを発行して販促する。
• 全く売れていない商品も、試験的にクーポンを発行して効果を見る。

この方針に対し、単に売上データだけを集計してしまうと、落とし穴があります。

# 売上データ(sale_df)のみをベースに集計
# クーポンで売れた個数を算出
sale_df.loc[
    sale_df["coupon_code"].notna(),
    "coupon_sale_qty",
] = sale_df["quantity"]

# 集約
sale_df_g = (
    sale_df.groupby(["product_id"])
    .agg(
        total_qty=("quantity", "sum"),
        mean_price=("unit_price", "mean"),
        total_coupon_sale_qty=("coupon_sale_qty", "sum"),
    )
    .reset_index()
)

# 四捨五入
sale_df_g["mean_price"] = sale_df_g["mean_price"].round().astype(int)

# どの程度がクーポンで売れたかの割合を算出
sale_df_g["coupon_sale_ratio"] = (
    100 * (sale_df_g["total_coupon_sale_qty"] / sale_df_g["total_qty"])
).round()
# 結果の出力
sale_df_g.sort_values(
    by=[
        "coupon_sale_ratio",
        "total_qty",
    ],
    ascending=[
        True,
        True,
    ],
).head(10)

出力結果:

この結果には、「一度も売れていない商品」が含まれていません。売上テーブルには実績があるデータしか存在しないためです。

これでは、「全く売れていない商品にクーポンを発行してみる」という施策の対象が抜け落ちてしまいます。

正しくは、「全商品マスタ」を主軸（左側）に置き、そこに売上データを結合（Left Join）する必要があります。

# 検証対象とすべき粒度の全データの枠（商品マスタ）を作成
result_df = m_product_df[["product_id", "regular_price"]].drop_duplicates()

# （中略：売上データの集計処理）

## 結合（商品マスタを左側にLeft Join）
result_df = pd.merge(
    result_df,
    sale_df_g,
    how="left",
    on="product_id",
)

# 売上がない商品は、0埋めなどで処理
result_df = result_df.fillna(0)

# （後略）

出力結果（マスタ主軸）:

このようにマスタを主軸にすることで、売上実績がない商品もリストアップされました。これにより、「売れていない商品群」を正しく把握し、施策検討のテーブルに乗せることができます。

この意識を持って実装すると、コードの構成は自然と出力すべき粒度のベースリストを作成し、そこに各指標を順次結合していくという形になると思います。

このスタイルの利点は、第三者が見ても「最終的に何の粒度で集計したいのか」が一目瞭然であることです。また、分析項目の追加要望があった際も、複雑な加工を経た変数の状態を追いかける必要は無く、常にこの「ベースリスト」に対して新たな計算結果を結合するだけで済むため、変更に強く拡張性の高いコードになります。

話を聞くと単純なことかもしれませんが、いざ分析に入ると陥りやすい内容となりますので、ぜひ意識をしてみてください。

まとめ

データ分析での業務を振り返り気づいた、品質高くスピーディーに結果を出すために技術的に留意すべきことをまとめました。

システム開発とは異なり、事前に入念なインフラやPGの設計がされているわけではなく、その状況下で大量データを分析し、より一層スピーディーに結果を出すことは難しいと感じるかもしれません。

そういった場合でも、焦ってすぐに分析に取り掛かるのではなく一度立ち止まり、現在は何を知りたい場面か・何を出力すべきか・そのために何を使用すべきかを、考えてから動くことが結果を出す近道だと感じました。

参考

• Dask Docs
• pandas Docs
• PySpark Docs

はじめまして。フューチャー株式会社の肥合と申します。私は2025年1月に入社し、現在はStrategic AI Group (SAIG) に所属し、主に自然言語処理 (NLP) に関する業務に携わっております。

2025年9月17日（水）から9月19日（金）にかけて開催されたYANS2025に参加しましたので、その様子をご報告します。当社はプラチナスポンサーとして参加しており、スポンサーブースでの会社紹介やポスター・チュートリアルの聴講などを行いました。

言語処理若手シンポジウム (YANS) とは

YANSは、NLPおよびその関連分野の研究発表が行われるシンポジウムです。若手の相互交流や研究推進をはかり、培われた研究開発の成果が実社会に応用されることを奨励し、学問および産業の進歩発展に貢献する目的で、年に1回開催されています。例年、ハッカソンやチュートリアル、ポスター発表等様々なプログラムが開催されています。

今年で20回目の開催となる本シンポジウムは静岡県のアクトシティ浜松にて開催されました。「研究と実装をつなぐ自然言語処理」をキーワードとして、自然言語処理分野の研究から実社会への実装をつなぐことをテーマに実施されました。参加・発表ともに過去最多の570名の参加と257件の発表となったとのことで、会場は大盛況でした。

スポンサー参加

フューチャーはプラチナスポンサーとして参加し、主にスポンサーブースでの会社紹介をしました。ブースに来られた方々に、当社のNLPやAI関連の取り組みについてご紹介させていただきました。

ノベルティとしてパンフレットと当社のロゴ入りの扇子を配布させていただいたのですが、ご好評いただき、扇子が早々に品切れとなりました。当社の取り組みについて多くの方に知っていただく機会になったと思います。改めてブースに足を運んでくださった皆様に感謝申し上げます。

スポンサー賞

当社のスポンサー賞には [S4-P18] CEFRに基づく文難易度を連続的に制御可能なテキスト平易化 の発表を選定させていただきました。この研究は、テキストの難易度を連続値で制御できる平易化モデルを提案するものです。従来手法は目標の難易度を段階的（離散的）にしか指定できませんでした。本手法では難易度をベクトルの長さで表現し、連続値で制御します。

選定理由は以下の通りです。

まず「LLMの出力品質をコントロールしたい」というモチベーションが非常に明確で分かりやすい点を高く評価しました。さらに、先行研究が離散的な制御に留まっていた中で、それを連続値で扱えるようにした技術的な新規性も素晴らしく、「子供新聞の見出し作成」といった具体的な応用例にも大いに期待が持てます。発表当日は丁寧な導入から分かりやすく解説いただき、その真摯な発表姿勢も受賞を決定づける大きな要因となりました。

副賞として、開催地にちなみ、浜松うなぎと浜松餃子を贈呈させていただきました。

発表紹介

スポンサー賞の他に、当社から参加したメンバーが特に面白いと感じた発表をいくつか紹介します。

[S4-P10] 大規模言語モデルにおける文化理解のニューロンレベル分析

この研究では、大規模モデルの文化理解のメカニズムについて分析しています。文化理解に寄与するニューロンを特定し、メカニズムを分析しています。

文化全体の理解に寄与するニューロン（文化全体ニューロン）、特定の文化理解に寄与する（個別文化ニューロン）を特定し、分析しています。実験の結果、文化全体ニューロンについては、マスクすると文化ベンチマークの精度が低下することが示されています。また、個別文化ニューロンについては、マスクするとその文化の問題に対する精度が低下するだけではなく、地理的・歴史的に近い文化の問題の精度低下も大きいことが示されています。（例：メキシコ文化のニューロンをマスクすると、歴史的に関係のあるスペインの問題も精度が大きく低下）

個別文化ニューロンに関する実験が特に興味深く、様々な観点からも検証しており、今後の展開に期待ができる研究だと思いました。

[S4-P27] 物語性が大規模言語モデルの記憶再生に与える影響の検証

この研究では、人間の記憶研究においてストーリー性のある文章は干渉に強く、要素の羅列は干渉に脆弱という背景から、文章の物語性に着目し、LLMにおいても物語性の違いによって記憶保持能力に差が生まれるのかを検証しています。

実験では小説風の高物語性の文、箇条書き形式の低物語性の文のいずれかを提示したうえで、その文について場所や時間などに関する質問の回答を生成するQAタスクを用意し、意味のない文を与えるなどの干渉条件の元でQA性能がどう変化するかを調査しています。

実験の結果、高物語性の文を提示すると人間同様に干渉に対して頑健であり、一方で低物語性の文では干渉に弱いことが示されています。物語性というユニークな着眼点で実際に人間と同様の傾向が見えるという興味深い結果が得られており、また実験設定やデータセットの拡張によってさらなる知見獲得の可能性を秘めていることから、今後の展開に期待できる発表だと感じました。

[S4-P33] 視覚言語モデルを活用したWebフロントエンドコード生成におけるデザイン忠実度の改善

この研究では、入力画像のデザインを忠実に反映したWebサイトを生成するためのVLM学習手法を検討しています。
従来より、Webサイト画像と当該サイトを生成するコードのペアを用いた教師あり学習は提案されてきましたが、本研究では生成コードのレンダリング結果を視覚的に正解と比較することで、デザイン忠実度の改善を図っています。

具体的にはGRPO (Group Relative Policy Optimization) を用いて、配色や要素の位置が正解と似ている生成結果を選好するように最適化することで、モデルの生成するコードがどのように変化するかを検証しています。

昨今、Code LLMsのケイパビリティは急速に拡大していますが、デザインに関する部分は未だ、比較的苦手としている印象があります。
これに対する1つの理由としては、正しさの評価が困難である、という点が挙げられます。実際に、本研究では、テキスト要素に着目した結果、それ以外の箇所における忠実性の低下が見られたことも触れられています。忠実性をどのようにモデリングするか、今後の展開に期待できる研究だと感じました。

[S1-P13] 多目的問題でのGRPOにおける報酬ハッキングの緩和について

この研究は、GRPOで複数報酬を最適化する場合の課題である報酬ハッキングの緩和に取り組んだものです。GRPOは、文章生成モデルの学習において、複数の候補を生成し、報酬関数で点数づけして、相対的な良し悪しで学習をすすめる強化学習の一種です。GRPOの課題として、複数の報酬関数を適用する際に、一部の報酬だけに過剰に最適化し、 他の報酬を犠牲にしてしまう報酬ハッキングがあります。この研究では、各報酬関数の正規化によって、バランスの良い学習に寄与するMO-GRPOを提案しています。

機械翻訳タスクでの評価実験において、読みやすさの評価指標 (jReadability) と翻訳の評価指標 (BLEURT) を報酬関数とした訓練をした結果、GRPOではjReadabilityが向上、BLEURTが低下した一方、提案手法では両方の指標でバランスの取れたスコアを達成し、評価用の別指標 (GPT-Eval) でも高精度となりました。
複数の観点で同時に良くしたいという状況は普遍的なもので、そこに取り組んだシンプルかつ実用的な研究だと考え、この研究を挙げさせていただきました。

おわりに

YANS2025は、過去最多の参加者・発表件数の、非常に密度の高いシンポジウムでした。ポスターセッションをはじめ、会場の各所で活発な議論が交わされており、大変良い刺激を受けることができました。ポスター発表で議論させていただいた皆様はもちろんのこと、スポンサーブースや懇親会などの企画で交流させていただいた皆様、そしてこの盛況な場を準備・運営してくださった運営・委員の皆様にも心より感謝申し上げます。今後もぜひ、このような活気ある場に参加し続けていきたいと考えています。

現在SAIGではともに働くメンバーを募集しています。特にNLP分野における社会実装のニーズは根強く、多くの仲間を必要としているところです。キャリア採用ページではシニアNLPエンジニアをはじめ、NLPリサーチエンジニア及びNLPエンジニアも同じく絶賛募集中です。条件等応相談ですので、我こそはという方は是非先のリンクよりご応募をお待ちしております。

ほかにも幅広く新卒採用およびキャリア採用を募集中です。興味のある方は是非一緒に働きましょう。よろしくお願いします！

はじめに

SAIGの小橋です。最近、間違って冷凍庫のドアを開けたまま外出してしまい、中身が全部解凍されてしまったので凹んでいます。

さて、今回は、AIと社会格差について、論文を読んで記事を書きたいと思います。

GPT-5がリリースされた際、#keep4o という運動が起きました。旧モデルのGPT-4oは暖かさや共感力があったが、新しいGPT-5は冷淡で機械的だと、一部ユーザーから批判の声が上がりました。

それに関連してこの論文を思い出しました。ただ、腰を据えて読んだことが無かったので、これを機に読むことにしました。

• The AI Gap: How Socioeconomic Status Affects Language Technology Interactions

概要と注意点

この論文では、1000人にアンケートを実施して収集したデータを分析し、個人のSES（社会経済的状況）とAIの使い方には関連性があることを示しています。

今回のSESは、IT企業でよく登場するSES契約（System Engineering Service）の話ではなく、「社会経済的地位」の意味です。分かりやすくいうと、「SESが高い」とは、高学歴・高収入で良い暮らしをしている人を指します。

注意点として、私が気になった箇所を特に注目して掘り下げて考察しています。全体の概要を知りたい人は、先に他の記事を読んだ方がいいかもしれません。例えばこちらの記事などがあります。

• AI格差は今、どうなっているのか？　収入や地位、教育などの違いで生成AIの活用方法、プロンプトがどう違うのか　1000人を対象に「AIギャップ」を調査（生成AIクローズアップ） | テクノエッジ TechnoEdge

AIを活用した論文の読み方

私は研究開発職ではないので、論文を日常的に読んでいるわけではなく、いきなり論文を頭から読んでいくのはちょっと大変です。そこでAIの力を借りて、alphaXivというツールを使うことにしました。

会員登録が必要ですが、無料で論文をブログ記事として読むことができます。しかも、英語だけではなく、日本語に変換した記事も読むことができます。（原文の日本語訳はありません）

またこのサイト上ではLLMのチャットボットのシステムがあり、論文の内容について質問すると原文を適宜参照して答えてくれます。いわば、論文を取り込んだnotebookLMのようなものです。便利な世の中ですね。

なお、以下の文章中では、alphaXivのチャットボットの回答が一部含まれています。

調査におけるデータ収集方法

まず私が気になったのは、著者らがどうやってデータを収集したかという点です。

著者らは、Prolificというクラウドソーシングサイトを使って回答を収集しました。

サイトを見ると、（特定の成果物を作成してもらうタイプのクラウドソーシングではなくて）データ収集に特化したサイトのようです。つまり仕事を発注する側は何らかのアンケート（データ収集用フォーム）を準備して回答者を募集します。受注者はそのアンケートに回答して報酬を得るという形だと思います。

研究者たちは、Prolificを通じてデータを収集したことにより、偏りや歪みが生じた可能性があると考えています。この点については、論文の「制限事項」の章に説明があります。

• 対象者が広い集団を代表していると言えるか: この研究は、Prolificプラットフォームの米国および英国のクラウドワーカーに限られているため、広い人口を代表していない可能性があります。社会経済的地位に関して、Prolificの利用者は中流階級から下流階級に偏っていると研究者たちは予測しています。
• 言語技術への親和性: クラウドワーカーは一般の人口と比較して、技術、特に言語技術に詳しい可能性が高く、そのため言語技術をより頻繁に利用している傾向があるかもしれません。

SESとは何か、どのように測定したか

次に私が気になったのは「回答者のSESをどのように測定したか」という点です。結論から言うと、Macarthurスケールというものを使用していて、「自分の社会経済的地位を1〜10の中で評価してください」という質問をしています。

SESはSocioeconomic Statusの略で、日本語では「社会経済的地位」と訳されます。論文では、SESを個人またはグループの社会経済的な位置を指すと定義しています。具体的には、個人の経済的、社会的、文化的な資本の関数であり、収入、教育、職業、富といった要素がSESに影響を与えると説明されています。

SESの測定方法としては、Macarthurスケールを使用しています。下図の通り、参加者にはしごの絵を見せて、「自身は、社会経済的はしごの1から10までの間でどの位置に該当するか?」という質問をしています。
その後、1〜3と答えた人を低SES、4〜7を中SES、8〜10を高SESと分類しています。

この方法は結構意外でした。学歴や年収などの客観的な指標を聞くのかと想像していましたが、「主観的な質問1問だけで良い」と考えて、SESを測定するというのはいい加減な手法ではないかと思いました。ただ、調べてみるとMacarthurスケールはよく使われる手法らしいです。

著者らもこの手法の限界については気づいていて、以下の通り述べています。「我々はSESを測定する上でマッカーサスケールを使用しました。主観的な尺度は曖昧さや偏りが生じやすい傾向があります。しかしながら、自分自身のSESに対する認識が行動や態度に重要な役割を果たすことも認識しているため、このため本調査ではこの尺度を用いることにしました」

なお学歴や趣味などもアンケートで収集していますが、SESを分類する際には使用していません。完全に蛇足ですが、趣味の選択肢に “Visit to stately homes” という項目があるのが不思議でした。イギリスなどにある昔からの貴族の屋敷を訪問することを指しているようですが、もっと一般的な「travel」のような項目が無いのに、こんな特定の項目があるのはなぜ……?

SESとプロンプトの長さの関係

それでは分析の方に移りましょう。論文中の分析は大きく分けて「言語関連の技術の使用状況について」「プロンプトの言語学敵分析（長さや語彙など）」「プロンプトのクラスタリングによる内容分析」「ユーザーがAIをどう認識しているか」の4つです。

ここでは特に興味深い2つの側面に焦点を当てて考察してみたいと思います。まず最初に、プロンプトの長さとSESの関係について見ていきましょう。次に、AIとの日常会話とSESの関係についても触れます。

社会階層が高い人々ほどプロンプトが短く簡潔になるらしいです。プロンプトの平均単語数は以下の通りです。

• 低SES層: 27.0語
• 中SES層: 22.3語
• 高SES層: 18.4語

この違いは、統計的に有意であると書かれています。この違いは、高SES層の個人がより広い語彙を持ち、少ない単語で自分自身を表現できることに起因するのではないかと研究者たちは推測しています。

調査方法への疑問

一見納得できる結果のようですが、立ち止まって考えてみると、この具体的な数値（20〜30単語）が私個人の実感と全く合致しないのでどうも腑に落ちません。

著者らはこの論文のcontributionとして

The first dataset of real prompts annotated with fine-grained sociodemographic information, including SES

と述べていますが、この内容がどこまで「リアル」なのかは注意すべきでしょう。正確な（実際に入力したものと全く同じ）プロンプトではないと推測されます。

第一に、自分が望む回答を得るために質問をどんどん具体的にしていったら語数は増えていき、上記に全く収まらないのではないでしょうか。例えば論文中には「Create a cover letter for a new role as a communication manager」という例が載っています。これをそのまま入力してもChatGPTなどは回答を出力しますが、その内容が自分の職歴に合致しているとは限りません。したがって回答の精度を上げるためには自分の職業内容や応募先の職務内容を入力するのが望ましく、そうするとプロンプトの語数は30単語どころではなくなります。

第二に、ある種の質問は対象となる文章が必要なので、明らかにプロンプトが長くなります。具体的には翻訳、要約、文章校正などです。「以下の文章を翻訳してください。（翻訳対象の文章）」というプロンプトの場合、ゆうに数百語、数千語になる可能性があります。要約や文章校正についても同じです。先の例であれば「カバーレターを書いてみたがこれでよいかレビューしてください」のようなプロンプトならば語数は多くなります。

このアンケートでは、回答者にプロンプトを入力してもらう際に「できれば、会話から直接コピーペーストしてください（Perferably, copy and paste the questions directly from the conversation.）」と依頼しています。したがって回答者はその場でプロンプトを書くこともできるし、コピーペーストもできます。しかし、上記の点を考えると、本当のプロンプトを入力したにしては平均単語数が少なすぎます。回答者は正確なプロンプトをコピー＆ペーストする代わりに、回答者が改めて一から新しくプロンプトを書いた可能性があるのではないでしょうか。

また、前処理についての記載を調べました。例えば極端に長いプロンプトを除外するなどの処理をしれから平均長を計算したのかとも予想しましたが、前処理について何ら記載はありませんでした。論文の記載を見る限り、特に前処理をせずにアンケートの回答結果をそのまま用いたようです。

SESと日常会話の関係

低SES層のユーザーは、生成AIを人間のように扱い、一般的な会話をしているという結果も見られました。その内容を詳しく見ていきましょう。

まず、アンケートでは、どのような用途でチャットボットを使用したかを質問しています。低SES層の方が利用割合が高かった主な項目は以下の2つです。

• Generic conversation（一般的な会話）
• QA on general knowledge（一般的な知識についての質問と回答）

この結果の解釈は慎重に行う必要があります。まずアンケートの結果はプロンプトに基づいたものではなく自己申告であるため、回答バイアスの影響が考えられます。例えば、高SES層の方々は実際には「一般的な会話」をしていても、見栄を張って「一般的な会話はしていない」と回答をした可能性も否定できません。
また、「一般的な会話」が具体的にどのようなものを指すのか知りたかったですが、論文中に具体的なプロンプト例が示されていません。なお、今回のプロンプトの分類はアンケートに基づいた結果であり、実際のプロンプトの内容分析はクラスタリングを使用しており、両者が別々に実施されていることにも留意する必要があります。

次に、「ユーザーがAIをどう認識しているか」についてです。Anthropomorphism（擬人化）という単語は論文中に登場し、4種類の条件を満たす割合を求めています。4種類のうち「Phatic expression（挨拶的表現）」については「thank, thanks, please, hi, hello」を含むプロンプトの割合を計算しています。これが低SES層のほうが使用率が高かった（統計的に有意ではない）ようです。

ただ、前述の通り、分析対象は正確なプロンプトではないと考えられます。そのため、この分析の妥当性には疑問が残ります。
仮に実際のプロンプトからコピーペーストせずに自分で改めてプロンプトを書く場合、「thank you」や「hello」などの挨拶的表現は真っ先に省略される可能性が高いでしょう。「挨拶的単語の使用割合」について有意義な議論をするためには、ユーザーが実際に入力したプロンプトを一字一句正確に収集する必要があります。この点で調査方法に課題があるため、この分析結果の解釈には慎重になるべきだと考えます。

2つの点について分析結果を見てきましたが、この分析では生成AIとの会話内容の一側面しか分からないでしょう。例えば極端な例として、ChatGPT（4o）と結婚した人のニュースがありました。本論文は、AIに人格を与えたり、回答のスタイルを大きく調整するような話には全く言及していないことには注意が必要です。

AIの性能評価は一面的な尺度だけを見ている?

ここまで論文の分析内容を見てきましたが、調査方法や結果の解釈には慎重に検討すべき点がいくつかあることがわかりました。最後に、論文の議論の部分で特に興味深い指摘があったので、それを紹介して締めくくりたいと思います。

高SES層のユーザーが行うような、言い換え、要約、数学的問題解決といったタスクは「ground-truth（正解）のある評価」には適している。一方で、低SES層のユーザーがより頻繁に行うようなタスクは、人間の好みによる評価に大きく依存しているため、既存のベンチマークでの評価が不十分です。将来の研究では、全てのSES層を代表するような現実的なシナリオに対してモデルの性能をベンチマークすることに焦点を当てるべきだと、著者らは述べています。

確かに、例えば私が「技術ブログを書いているけど、なかなか書き終わらないしもう疲れてきた」と弱音を吐いた場合に、AIが「もう少しだけ頑張ってみましょう」と励ますのが正解なのでしょうか。それとも、「そうですね、疲れているならば今日はもう寝て、続きは明日にしましょう」と休憩を促すのが正解なのか、これは難しい問題です。時と場合によって正解は変わりえるからです。（AIの回答が当初の予想と違うものだったけど結果的にOK、という場合さえあります）

この指摘は、AIの性能評価のあり方について考えさせられます。現在のAIの性能は、「数学オリンピックの問題を何%解けたか」といった、いわゆる「ground-truth（正解）のある評価」で語られがちです。しかし、AIの良し悪しを判断する材料は、それだけで十分なのでしょうか。

大学院や専門家レベルの難問を解く能力よりも、人間と楽しく会話できる能力の方が重要だという側面もあるはずです。正解のあるタスクの評価だけでは、こうした側面を見逃してしまうかもしれません。その結果として、例えば「GPT-4oがおべっかばかりで気持ち悪い」と批判されたり、「GPT-5のモデルが冷淡すぎるから以前のバージョンに戻してほしい」と言われたりするような問題に繋がっていくのかもしれない、と感じました。

おわりに

この記事では、論文をきっかけに、社会経済的地位（SES）とAIの使われ方の関係、そして現在のAI性能評価のあり方について考えてきました。特にAIの性能評価というテーマは、今後どのように発展していくのか興味深いところです。単純な正解・不正解だけでなく、ground-truth（正解）のない問題に対してどのような評価指標を設計していくのか。これは、これからのAI開発における大きな課題と言えるでしょう。

記事の冒頭で触れた「#keep4o」の運動を思い返すと、今回の論文が示唆するテーマとの繋がりが見えてきます。GPT-4oに「暖かさや共感力」を見出したのは誰だったのか。人が生成AIに何を求め、そのニーズが個人の属性によってどう変わるのか。今回読んできた論文は、これらの問いの一部に答えているに過ぎません。今後、この分野のさらなる研究が登場することを待ちたいと思います。

（論文を読んでいて気づいたのですが、このアンケート結果はhuggingfaceに公開されているようです。せっかくの自由研究ならそのデータを使って何か分析すれば良かった……）

はじめに

こんにちは。Strategic AI Group (SAIG) の藤井です。

GENIAC第2期事業にて採択された「日本語とソフトウェア開発に特化した基盤モデルの構築」プロジェクトに関する取り組み紹介、全2編の後編です。

前編では、開発したモデルの概要や開発の流れ、プロジェクト進行における反省点をご紹介しました。後編では、モデルの技術的特徴に関するより込み入った内容や、取り組みの中では明らかに出来なかった今後の検討課題・オープンクエスチョンを共有します。

改めて、本プロジェクトで開発したモデル Llama-3.1-Future-Code-Ja-8B はHugging Faceにて公開しております。

商用利用も可能な許容的ライセンスで公開しておりますので、ぜひ幅広く試して (遊んで) いただけると嬉しいです。

モデル学習における気づき・学び

今回のモデル開発では、① 継続事前学習、② 教師ありファインチューニング、③ 選好最適化 の3つのフェーズで学習しました。

ここでは、モデル学習における気づきや学びを、フェーズの順に紹介していきます。

継続事前学習

Fill-in-the-Middle (FIM) は学習時間のオーバーヘッド、性能低下ともに最小限

今回のモデル学習では Fill-in-the-Middle (FIM) と呼ばれる学習手法を導入しました。

ここで、LLMの (継続) 事前学習では、所定のコンテキスト長まで複数のドキュメントをつなぎ合わせ、詰め込んだものを1つのシーケンスとして学習することが一般的です(この操作は packing と呼ばれます)。

この時、1つの詰め込みシーケンスから prefix, middle, suffix の分割を作成する方法を “Context-level FIM”、元のドキュメント境界を尊重し、ドキュメント内で各分割を作成する方法を “Document-level FIM” と呼びます。

“Document-level FIM” は、各ドキュメントを事前に分割 → 順序を入れ替えておく処理で完結するため、実装が容易であり、学習時のオーバーヘッドも発生しませんが、packingの際に各分割が異なるシーケンスに分散してしまう可能性があることから、精度面では “Context-level FIM” に軍配が上がることが論文中で述べられています。そのため、今回はMegatron LM上に “Context-level FIM” の実装を追加して学習を進めることとしました。

Megatron LMを用いる場合、前処理の段階でコーパスはtokenize (トークン化) されます。packingの処理は、前処理済の トークンID を所定のコンテキスト長まで取得する形で実現されるため、テキストを任意の箇所で3分割するためには、一度detokenizeして文字列に戻した上で改めてtokenizeする という処理が必要になります。このように、学習時に追加の処理が加わることとなるため、学習速度の低下が懸念されたのですが、今回の開発環境 (p5.48xlarge × 4ノード) では速度面の影響はほとんど見られませんでした。

また、論文でも FIM-for-free と呼ばれているように、FIMの導入前後で一般的なLeft-to-Right生成タスクの到達点が顕著に下がるような現象は確認されませんでした。しかしながら、リソース制約により厳密な比較実験ができておらず、確かなことはまだ分からないというのも事実です。

↓ FIM導入前後のスコアの比較 (NIILC)

桃色がFIM導入後、その他の線は導入前のもの (※ ただし、桃色線とそれ以外では学習データの総量、組成も異なる）。
FIM導入後 (桃色線) の到達点は、学習データの組成が類似するFIM導入前のモデル (青・橙線) と同等以上をキープしている。

事前学習時に学んだ “嫌な形質” は増強するのは簡単だが、取り除くのは困難

継続事前学習では、学習データに適用するフィルタを段階的に実装して、出力の定量・定性的な変化を確認していきました。

その過程で、特に初期のモデルに特徴的な傾向として # TODO: implement this function 等、ユーザに追記を促すような出力が顕著に増加する、(それに起因してか) 出力の平均長が学習前より短くなる現象が確認されました。Web上には教育目的で書かれたソースコードも多く存在しており、上記以外にも Write your solution, Implement me 等の派生が多数見られます。しかし、ソフトウェア開発 (コーディング) を支援するLLMにおいて、このような出力が望ましいケースというのはそう多くありません。

そのため、今回は学習データから数百万件のソースコードをサンプリングし、考えられる表現パターンを grep で洗い出した上で、いずれかの表現とマッチする場合には「ドキュメントごと」学習対象外とする対応を取ることとしました。しかしながら、そのような厳格な対応を取ってなお、# TODO: implement this function 問題は完全には解決しませんでした。

学習データで数百万件に1度と出現しない程度の頻度でありながら、そのような表現が生成されてしまう理由として、今回は「継続」事前学習であったことが考えられます。今回、学習に用いたトークン数 (約290B) は決して小さくありませんが、それでもLlama-3.1の事前学習におけるトークン数 (15T) と比較すると極めて小規模です。

手元の学習データにない入力に対して # TODO... を出力するよう、モデルが既に学んでしまっていたとすれば、仮に手元の学習データで出現数を0に抑えられたとて生成を抑制できません。Next Token Predictionでモデルが学習するのは、手元のデータセットに対する Do’s であり、Don’ts の抑制はここでは困難である (選好最適化で対応するか、スクラッチからの学習時に徹底的に綺麗にするべき) というのは学びでした。

教師ありファインチューニング

LLMによる疑似データ生成はモデルが既に知っているタスクにbiasedな可能性が高い

今回の取り組みでは、 Magpie の手法を適用することで、ソフトウェア開発に特化したinstructionを「より優れたモデルから引き出して」学習しました。

この時、instructionを生成するための (システム) プロンプトは論文のAppendixに記載のものをベースとしたのですが、オリジナルのプロンプトを愚直に用いた場合では生成されるinstructionの多く (7割以上) がPythonに関するものとなってしまいました。

そのため、今回は The user will ask you a wide range of coding questions about the {language} programming language. のように、ユーザがアシスタントに求める役割として、関連するプログラミング言語を明示することでタスクに多様性を持たせることとしました。

このような「偏り」が存在する理由としては、Code LLMに関する既存の評価ベンチマークが極めてPythonに寄っているということが挙げられます。この状況は望ましくありませんが、そうなってしまっている以上、既存のモデルの多くがPythonに力を入れているのは当然であり、それらから抽出されるinstructionもまたPythonに偏ってしまいます。

さらに、この「偏り」はプログラミング言語の分布に限った話ではなく、生成されるタスクの種類についても同様に考えられます。今回の取り組みの過程で調査していて驚いたことですが、to code (生成する対象がコード) では様々なベンチマークが提案されている一方、コードを説明する・レビューをするなどの to 自然言語 のタスクには、ほとんどといって良いほどベンチマークが存在しません。

また、to code のタスクにおいても、純粋なコード生成 (補完) のベンチマークは多数存在する一方で、言語間翻訳などは盛んには取り組まれていない印象です。これには、評価方法が確立されていない、データの作成が困難であるなど様々な要因が考えられ、一朝一夕解決するようなものではないのですが「富める者は富み」の状況になってしまっていることは間違いないでしょう。

実際に、前編に記載のように、今回学習したモデルはベースライン (Llama 3.1-8B) と比較して高いコード補完性能を実現していますが、その一方でバグフィックス (HumanEvalFix) や仕様変更対応 (CanItEdit) に関するベンチマークではLlamaと同等の性能に留まってしまいました。

LLMの生成する疑似データには偏りが存在することを認識したうえで、より明示的なタスク誘導を入れる、他のスキーム (Evol-Instruct など) と組み合わせる、Human-in-the-Loopを検討するなど柔軟な対応が求められそうです。

選好最適化

モデルベースのフィードバックでは報酬スコアのノイズに関する一定の考慮が必要

今回、各instructionに対し4件のresponseを生成し、それぞれを報酬モデル (Llama-3.1-Nemotron-70B-Reward-HF) で評価することで、DPO用の学習データを作成しました。この時、正例 chosen については「最もスコアの高いものを選択する」で基本的に問題ないと思われますが、負例 rejected の選び方についてはいくつかのバリエーションが考えられます。

検証では、① 最もスコアが近いもの (＝2位) ② 最もスコアが遠いもの (≒4位) ③ chosen 以外からランダム選択 の3つのパターンで学習し、各モデルのベンチマーク性能 (コード補完性能) を確認しました。その結果、② スコアが遠いもの と ③ ランダム選択 の優劣はまちまちであるものの、① スコアが近いもの では他の設定を明確に下回るケースが多く見られました。

モデルベースの報酬は採点基準に沿った加点法ではないため、あるresponseがより高いスコアを獲得したとからいって、必ずしもそのresponseがユースケースに沿って「より優れている」ことを意味しません。コード生成を例にあげると、responseが満たすべき観点の1つには「機能的に正しく動作すること」があげられますが、モデルベースの報酬は「コードとは一切関係しない何らかの観点で優れている」ことを機能的正確性よりも重く評価する可能性があります。特にスコアの近い出力どうしのペアでは、このような非本質的観点による良さの逆転 (ノイズ) により良い学習シグナルが得られなかったことが考えられます。

↓ DPO時のペア選択法によるスコアの違い (予備実験)
青線 (②) と 赤線 (③) の優劣はタスク依存だが、緑線 (①) は明確にスコアが低い傾向。

モデル評価における気づき・学び

続いて、モデル評価における気づきや学びを紹介していきます。

また、ここでは「今後の」モデル開発における有力な方向性にも触れたいと思います。

コード補完タスクの評価は「怪しい」

不穏な見出しですが、HumanEval, MultiPL-Eなどのコード補完タスクについては「同一の環境で比較実行した結果」以外の結果は比較不能だと思った方が良い、という話になります。

これには、temperature (サンプリング温度) などハイパーパラメータの問題もありますが、より大きな問題としてsanitizeの問題が挙げられます。コード補完の評価では、補完対象の関数 (やメソッド) のみを評価するため、モデル出力の不要な部分を後処理で削除する手順があり、この処理はsanitizeと呼ばれます。例えば Code Generation LM Evaluation Harness のHumanEvalでは、\nclass, \ndef 等いくつかのストップワードを定義し、これらが出現したら補完対象の関数は閉じているだろう (切り詰めてもよいだろう) という判断をしています。

一方で、プログラミング言語によってはこのような単純な文字列マッチでは対応が難しいこともあります。

これに対して EvalPlus では、より正確な評価に向けて、AST (抽象構文木) を用いた高度なsanitize処理を実装するなどの対応を取っています。

しかしながら、問題は sanitize処理が統一されていない という点です。たとえ同じ評価ベンチマークを用いていても、異なる処理を実装したライブラリで評価した結果を直接的に比較することは適切ではありません。さらにいえば、同一のライブラリであっても開発の過程で処理が変化している場合があり、より厳密にはcommit hashのレベルまで統一されて初めて比較可能となります。

実際に、主要なオープンソースモデルについて手元の環境で評価した際、公称値とは10ポイント以上異なるようなケースも確認されました。

日本語 × ○○ に強いモデル構築は、特化モデルへの日本語学習が確かな方向性？

ソフトウェア開発タスク (特にコーディング) 特化のQwen2.5-Coder (以後Qwen) と、汎用モデルであるLlama 3.1 (以後Llama) を比較すると、しばしば、”英語タスク指示におけるLlamaのスコア” < “日本語タスク指示におけるQwenのスコア” であることが分かりました。

これはつまり、汎用モデルを起点に 日本語 × ○○ に強い、今回で言えば 日本語 × ソフトウェア開発 に強いモデルを目指そうとすると、もともと英語で出来ていたレベル以上の性能を日本語で達成しなければならない、というハードモードになってしまいます。

殊にCode LLMに関しては、Claude, GPT, Qwenをはじめとして世界中のモデルプロバイダがしのぎを削ってその性能を競い合っています。このような背景において、世界一のソフトウェア開発データを作ることは困難ですが、日本のLLM開発者・研究者にとって、世界一の日本語データを作ることはこの苦難と比べれば幾分容易いと言えます。

また、今回Python以外にも多くのプログラミング言語で評価したことで、<10B (7～9B) の比較的小規模なモデルでは継続学習時に見ていない言語を忘れがちであるのに対し、70B等の大規模モデルでは学習していないことがビハインドになりにくいということも見えてきました。

これらの観測を踏まえると、コーディングや数学など、ドメインに特化した大規模モデルを起点に高品質な日本語を学習し、それらの蒸留を通して小規模モデルを作成することが有望な方向性であるように感じます。

今後の検討課題

ここでは、今回の取り組みの中では明らかに出来なかった今後の検討課題、今後明らかにしていくべきオープンクエスチョンに触れたいと思います。

(継続) 事前学習においてlinterやformatterを活用すべきか

PythonのPEP 8のように、プログラミング言語にはしばしば「こう書くべき」を定義したコーディング規約が存在します。linterやformatterは、ルール・スタイルに従わない不適切なコードの検知や修正をするツールであり、LLMの学習データに適用すれば自然と (一般的な) ベストプラクティスに沿った良いコードを出力することが期待されます。

しかしながら、実際の利用シチュエーションを想定すると「綺麗なコードしか見たことがない」というのは問題です。例えば、構文エラーについて一切知らないモデルは、構文エラーを含む入力に対して「バグを修正してください」というリクエストには応えられないでしょう。

「知らない」は回避しつつ、望まない出力は「出さない」を実現するために、静的解析ツールを含めた諸々のフィルタリングルールを如何に組み込むべきか、という点はさらなる検討が必要と考えます。

LLMで作成したデータを (継続) 事前学習 から取り込むべきか

今回、継続事前学習のフェーズでは、GitHubやCommonCrawlに由来するウェブ上の生データのクリーニングに注力し、instruction tuningで用いるようなタスク指示と応答のデータや、LLMで作成したデータ (疑似データ) は用いませんでした。

しかし、このような「LLM時代のデータ」を事前学習時に混ぜておくことが、”ベースモデル” のタスク遂行性能の向上につながることも明らかになっています。ここで疑問に上がるのは、この「タスク遂行性能の向上」が、SFT以降で獲得される能力の先取りに過ぎないのか、SFT (DPO) 後の最終到達点を上げるポテンシャルを有するものなのか、ということです。

今回の取り組みから得られたベースモデルのコード補完性能は、純粋なウェブ上のデータのクリーニングで到達できる性能としてはアッパーバウンドに近いと考えています。主要なオープンソースモデルを評価した結果、同規模のモデルで比較すると、Llama, gemma系のベースモデルのスコアは今回の学習モデルと同等 ～ やや学習モデルの方が優れている程度である一方、Qwen系のベースモデルはベースモデルのスコアが非常に高いことが分かりました。このことから、おそらくLlama, gemma系とQwen系はベースモデルに対するスタンスが異っており、Qwenはより早期から積極的に疑似データを採用していると推察されます。

instructモデルの性能で比較した時、コード補完タスクにおいては多くのケースでQwen系が優れています。

しかしながら、Llama, gemma系はベース → instructの伸び率がQwen系と比較して顕著に高く、ベースモデルでの両者の差ほど最終性能には差がないというのも事実です。また、最終性能の差は (SFT以降の) 事後学習データの差にも起因します。

仮に同じ事後学習データを用いたとして、事前学習時から疑似データを見た方が良いのか？は未だ明らかになっておらず、今後の調査に値すると考えます。

おわりに

さて、ここまで2回に分けて「日本語とソフトウェア開発に特化した基盤モデル」Llama-3.1-Future-Code-Ja-8B の開発に関する取り組みをご紹介してきました。

本記事の内容が、LLMを作る・使う多くの方々に少しでも響いてくれたなら嬉しいです。

フューチャーではともに働くメンバーを募集しています。
自然言語処理 (NLP) 分野では基礎研究から最先端技術の社会実装まで、幅広いキャリアパスの選択肢をご用意しています。
ご興味を持っていただいた方は、ぜひ キャリア採用サイト からのご応募をお待ちしております。
また、本取り組みに関して詳細を聞きたい、フューチャーのNLP, AIの取り組みについて気軽に聞きたいという方は、以下もご活用ください。

• 本取り組みについての問い合わせ : pj-geniac at future.co.jp
• SAIG NLPチームへの問い合わせ : gr-saig-llm at future.co.jp

ご覧いただきありがとうございました！

はじめに

こんにちは。Strategic AI Group (SAIG) の藤井です。

GENIAC第2期事業にて採択された「日本語とソフトウェア開発に特化した基盤モデルの構築」プロジェクトについて、開発の過程で得られた知見や学び、今後の課題を共有します。

みなさまご存じの通り、生成AI技術を取り巻く状況は日進月歩であり、殊にコーディングをはじめとしたソフトウェア開発ドメインでは、(人間を含む) 環境のフィードバックを受けながら自律的に問題を解決するエージェントなど日夜新たなツールが登場しています。その意味で「ソフトウェア開発×基盤モデル」は血の海であり、どのような方針・立ち位置を取るかという部分に非常に頭を悩ませました。

本稿は前後編の2本立てで、前編は開発したモデルの概要や開発の流れ、プロジェクト進行における反省点について、後編ではモデルの技術的特徴に関するより込み入った内容や、今後明らかにすべきオープンクエスチョンなど次のチャレンジャーに向けたメッセージを著したいと思います。

本プロジェクトで開発したモデル Llama-3.1-Future-Code-Ja-8B はHugging Faceにて公開しています。

開発のベースとした Llama-3.1 モデルに起因するもの以外では、利用に際する条件など設けておりませんので、ぜひ幅広く試していただけると開発者冥利に尽きます。

GENIACプロジェクトについて

GENIAC (Generative AI Accelerator Challenge) は、経済産業省、および国立研究開発法人新エネルギー・産業技術総合開発機構 (NEDO) が実施する日本国内の生成AI開発力強化プロジェクトです。

これまでに2024年2月に開始した第1期、同年10月に開始した第2期の2サイクルが完了し、フューチャーは第2期公募において「日本語とソフトウェア開発に特化した基盤モデルの構築」のテーマで採択されました。

開発の背景

これまで、日本語に強みを持つとされたモデルでは、コーディングやそれを包含するソフトウェア開発のタスクにあまりスポットが当てられてきませんでした。

しかしながら、日本語で記載した仕様に沿って関数を設計するなど、国内では日本語をコンピュータと人間の橋渡しに使いたいというニーズは根強いと考えられます。また、コーディングに特化した大規模言語モデル (Code LLM) の文脈では、従来コードの途中までが与えられた状態での後方補完 (code completion) タスクが活発に取り組まれてきましたが、ソフトウェア開発においてはコードを理解して自然言語を生成するようなタスク、例えばコードレビューなども対象となり得ます。

そのようなタスクにおいて、自然な日本語を扱えることはメリットであり「日本語」と「ソフトウェア開発」の双方において強味を持つモデルの構想に至りました。

開発の流れ

前述のとおり、本プロジェクトは2024年10月に開始し、翌年4月までの6か月間をメインに実施しました。

大規模言語モデル (LLM) の学習は主に、① 事前学習 ② 教師ありファインチューニング ③ 選好最適化 の3つの段階に分かれます。

なお、今回はスクラッチ (ランダムな初期値) からの学習ではなく、Meta社の Llama-3.1 8B モデルの重みをベースに学習したため、ステップ①は「継続」事前学習 (continual pretraining) となります。

今回のモデル開発では、結果的に2/3以上の期間を継続事前学習、その後各1ヶ月程度で後続のフェーズを検討するというスケジュールとなりました。

プロジェクト体制

GENIACでは週次・月次での事務局への進捗報告をはじめ、対社内外のやり取りが多く発生します。今回のプロジェクトでは社内事務局を設置することで、開発者がモデル開発に専念できる体制を整えていただけたのが良かったと感じます。しかしながら、開発側も決して潤沢なリソースがある状況ではありませんでした。特に、継続事前学習パートでは手を動かせる定常メンバが一人という状況にあり、打てる試行錯誤の数としても限られてしまったと感じます。

GENIACコミュニティでは採択事業者向けのイベントがしばしば企画されるのですが、第2期ではMeta社やAnthropic社など生成AI領域をリードする企業を訪問する米国視察イベントもありました。参加された方から伺ったところでは、そのような企業は数百人～数千人という規模でモデルを開発しているようです。各組織の限られたメンバーに知見が閉じているような状況ではいけない、というのも、今回開発したモデルの許容的ライセンスでの公開、および本記事の執筆に至った経緯です。

各フェーズの概要

各フェーズの取り組みをダイジェストにてご紹介します。

より詳しい内容については、ぜひ後編をご覧ください。

フェーズ1 : 継続事前学習

ウェブ上のソースコード、日英テキストのデータクリーニングに注力し、ソースコード約205Bトークン、日英テキスト約86Bトークンの混合データで継続事前学習しました。

LLMの学習でしばしば見られるloss spikeは発生せず、以下のように安定した学習曲線で推移しました。

データクリーニングでは非常に多くの困難がありましたが、GitHub由来のソースコードのみでも、堅実なフィルタリングルールの設計でベースモデルから一定のコード補完精度向上が見られるというのは学びでした。

フィルタの実装には、tree-sitter-language-pack, lizard といったOSSの静的解析ツールも積極的に採用したのですが、前者が内部で依存するparser (構文解析器) が数百万件に一件レベルで踏むバグで退勤前に仕込んだ処理が翌朝コケているのには参りました。

また、今回のモデル学習では、通常のNext Token Predictionに加えて、Fill-in-the-Middle (FIM) と呼ばれる学習手法を採用しました。

FIMとは「途中補完」を意味しますが、これはIDE上でカーソルの前後「双方」の文脈を考慮してカーソルの後ろ側を補完するかのように、前後の文脈から中間部分を予測するタスクとなります。

フェーズ2 : 教師ありファインチューニング (SFT)

今回のモデル開発では、基本的な指示追従・汎用的なタスク遂行能力の獲得にはモデルマージを活用し、ソフトウェア開発関連タスクに特化したinstruction-tuningデータセットのみを用いて学習しました。

モデルマージ手法にも多種多様なものが提案されていますが、今回は Task Arithmetic と呼ばれるシンプルな手法を採用しました。この手法では、あるモデルと、そのモデルを何らかのタスクでファインチューニングしたモデルの2つのモデルに対して、ファインチューニング前後のパラメータの差分 (タスクベクトル) を「そのタスクを解く能力」と考えます。

そして、任意のモデルにこの「タスクベクトル」を足し合わせることで、後天的に (再学習することなく) 当該タスクを解く能力を身につけることを期待します。
今回は、継続事前学習後のモデルに「Llama 3.1 8B と Llama 3.1 8B Instruct の差分」を足し合わせることで、一定の指示追従能力が獲得されることを確認しました。

instruction-tuningデータの作成には Magpie と呼ばれる手法を用いています。

Magpieについて簡単に説明すると、本来LLMの推論では “システムプロンプト” と “ユーザプロンプト” に続いて【アシスタントここから生成】 (※イメージ) のようなトリガーが与えられ、システムはAIアシスタントとしての応答を生成します。これを “システムプロンプト” に続けて【ユーザここから生成】と渡すことでユーザが聞きそうな指示文をモデル自身から引き出してしまおう、という考え方になります。

テクニカルな話をすれば、通常、SFTでは最後のアシスタント応答部分以外にはlossを流さないため、モデルはユーザ指示部分のNext Token Predictionを学習しておらず、Magpieが成立する理由は謎なのですが、シードデータを要することなく「無」から大量に、かつ定性的にも妥当な学習データを生成できる手法として今回の採用に至りました。

Magpieのデータ作成は比較的スケールし、Llama 3.3 70B Instruct で1万件のinstructionを作成後、各4件のresponseを生成するケースでは10 (H100) GPU時間以内で実現できます。 (執筆時点でAWS東京リージョンにおける p5.48xlarge = H100×8 のオンデマンド単価は$68.80ですので、100ドル未満で1万件のデータを生成できるということになります)最終的に、今回の取り組みでは約1,200万件のinstruction-tuningデータを用いて学習しました。

なお、マージ直後のモデルについて、対話形式の入力では問題なくターンを終えることができましたが、FIM形式の入力では途中補完として妥当な出力を始めた後、必要な内容の出力が終わっても生成を止められないという現象が見られました。今回のモデル開発では、SFTの学習データにFIM形式のデータを少量混ぜることで対話能力とFIMを両立させることができました。

フェーズ3 : 選好最適化

前述のMagpieで作成したinstruction-tuningデータセットの一部を用いて DPO (直接選好最適化) を行いました。

DPOではある入力 prompt に対して、良い出力 chosen と悪い出力 rejected のペアを用いて、chosen を出力しやすく、 rejected を出力しにくくするように重みを更新します。今回は作成したinstruction1件に対して4件のresponseを生成しましたが、各responseに Llama-3.1-Nemotron-70B-Reward-HF で報酬 (良さのスコア) を付与し、最もスコアの高いものを chosen、最もスコアの低いものを rejected として学習しました。

当初、DPOにはSFT用のデータと重複しないよう100万件のinstructionを取り分けて進めていましたが、コード補完ベンチマークのスコアをモニタリングした結果、学習初期にピークを迎えた後にスコアが低下する傾向が認められたため、最終的には10万件にサンプリングして学習することとしました。

モデルの評価

ここでは、開発したモデルについて、いくつか特徴的な評価結果に触れ、そこから考えられる強み・可能性について考察したいと思います。

評価結果の完全な表は Hugging Faceのモデルページ をご参照ください。

以下は、日本語タスク指示文を含むコード補完ベンチマークの評価スコアです。

表中のスコアは pass@1 という評価指標によるもので、「1度の生成で単体テストを通過する “機能的に正しい” コードを生成できる割合の期待値」です。この表の結果から、主要なプログラミング言語において、開発したモデルのコード補完性能は学習元の Llama-3.1-8B-Instruct を大きく上回り、同規模のオープンソースモデルの中では高い水準にあることが分かります。

しかしながら、ドメイン特化モデルである Qwen2.5-Coder との比較では劣後しており、コーディングタスクにおいて、当該モデルが非常に強力であることを改めて実感しました。

代わって、以下は日本語を生成するタスクの評価スコアとなります。

ここで「日本語を生成する」とは、”A”, “B”, … , “ポジティブ”, “ネガティブ” のようなラベルではなくフリーフォームでの生成が求められるものと考えます。

表中には質問応答 (NIILC)、要約 (XL-Sum)、翻訳 (WMT)と性質の異なる3つのタスクのスコアを記載しました。

各タスクの評価指標については割愛しますが、いずれも「高いほど良い」指標であり、これらのタスクについてもまた、開発したモデルは学習元のモデルと比較して高い性能を達成していることがわかります。また、ここで特筆すべき点としてQwen系のモデルのパフォーマンスが相対的に低く留まっているという点が挙げられます。

これらの結果を総括すると、今回開発したモデルは 高度なコード理解と日本語の生成の双方が求められるようなタスク 、すなわちコードレビューや仕様書の逆生成において光る可能性があるのではないかと考えています。

プロジェクト進行における反省点

試行錯誤の回数を増やすために

今回、モデルの学習には Megatron-LM を用いましたが、評価のためにはチェックポイントをHuggingface Transformersで扱える形式に変換 → 評価スクリプトを実行という手順を踏む必要がありました。

Megatronのチェックポイントはインスタンスに備え付けのNVMeストレージに一時保存後、自動的にs3にアップロードされるよう設定を組んでいたのですが、変換・評価については自動化の構成検討まで手が回らず期間を通して手動実行することとなってしまいました。毎回の作業はさほど大きくはないのですが、何度も発生することによるチリツモの影響、評価スコアが早く見えることによる判断早期化への期待から、腰を据えて学習に取り掛かる前に自動評価を整備すべきだったと感じます。

より小規模なモデルを用いる、学習途中で打ち切って判断するというのも魅力的なオプションに見えますが、個人的にはあまりおすすめしません。

というのも、学習初期は低空飛行であっても、最後まで伸びてこないかといえば必ずしもそうとは限りませんでした。小規模モデルや学習初期の観測だけでも、あるデータやハイパーパラメータが明確に「良い」ということは言えるかもしれません。しかしながら、それらが「良くない」、芽が出ない設定であるということは本番と同等の設定で、できるだけ最後まで学習して判断すべきだと感じました。そのためにも、繰り返し発生する定型作業の省力化は特に意識しておきたいポイントです。

↓ ベースモデル学習時の評価曲線
学習序盤ではベースライン (黄破線) を下回っている。

モデルに「色」を持たせるために

今回の開発において頭を悩ませた点のひとつが 「基盤モデルに何を求めるか」 です。

ここまで読んでいただいた方は薄々お気づきかと思われますが、今回のモデルが「これまでのモデルに出来なかった新たな領域 (タスク) 」に強みを持つかといえばそれはNoです。

先述の通り、ソフトウェア開発においてコーディングタスクは氷山の一角に過ぎず、Code LLMの切り込む余地はまだまだ残されているはずです。しかしながら、レビュータスクひとつを例にとっても、基盤モデルが持っていて嬉しい特徴とは何か、というのは突然ひらめくものではありませんでした。もちろん、社内で日々行われるレビューの情報をin-outに学習すれば、社内で使う分にはそれらしいレビューを生成できるかもしれません。

一方で、レビューの方法、仕様書の書き方などは、全世界的に標準が定まっているものではなく、それらに対するある1つの「方言」である社内 (組織内) 標準はファインチューニングで学ぶべき特徴に思われます。そのため、今回は「日本語」や「ソフトウェア開発」の領域でこれまでデファクトとして評価されてきたベンチマークを評価指標に定めて開発を推し進めていくこととなりました。

しかし、このようなタスクを想定した時、基盤モデルにできることはないのか、といえばこれもNoであると考えます。目下モデル開発の終了を受けて、今回のモデルを含めた複数のLLMを社内のコードレビュー補助に使えないかという実応用の検討が進んでいます。その過程で実際にどのような使い方が想定されるのかを見れば、例えば「指摘に該当する行番号を指摘内容と合わせて出力したいのだな」といったニーズをくみ取ることができ、パッチファイルのようなデータを重く学習するなど一定の工夫は取れたと思われます。石橋を叩いて渡る慎重さも必要ですが、殊にLLM時代においては、 積極的なアルファ・ベータテストとFBを回していくべきだった と考えます。

おわりに

今回は「日本語とソフトウェア開発に特化した基盤モデル」Llama-3.1-Future-Code-Ja-8B の開発について、その概観をお伝えしました。

個人としても、組織としても初めての基盤モデル開発プロジェクトであり、振り返ってみると反省すべき点も多かったと感じます。
しかし、こうして書き起こしてみると、どうすればより価値のあるものを作れるか、半年間1つのモデルと向き合うことで得られた学びも多々あったと実感しました。

フューチャーではともに働くメンバーを募集しています。

自然言語処理 (NLP) 分野では基礎研究から最先端技術の社会実装まで、幅広いキャリアパスの選択肢をご用意しています。
ご興味を持っていただいた方は、ぜひ キャリア採用サイト からのご応募をお待ちしております。

後編では、より詳細な技術的特徴・工夫や、今回の取り組みでは明らかに出来なかった今後の検討課題などをご紹介できればと思いますので、もしよろしければそちらもぜひご覧ください。
ありがとうございました！

こんにちは！Energy Transformation Groupの大前七奈です。

機械学習モデルを本番環境で運用する際、スケーラビリティや管理のしやすさは重要です。MLflowのFastAPIによるデプロイは手軽ですが、大規模運用には不向きな場合があります。

本記事では、MLflowで管理されたモデルを、Kubernetes上で動作する高機能なMLモデルサービング基盤KServeにデプロイする方法を解説します。ローカル環境でKubernetesを簡単に扱えるminikubeを用いた構築手順から、Google Kubernetes Engine (GKE) へのデプロイ、さらにはCI/CDへの応用まで、実践的なMLOpsの構築方法を詳しく紹介します。

バージョン

本記事で利用を想定しているツールのバージョンは以下の通りです。

• minikube: v1.36.0
• mlflow: v3.1.1
• kserve: v0.13.0

なぜFastAPIでなく、Kubernates?

MLflowの公式サイトでも以下のように書かれています。

MLflow provides an easy-to-use interface for deploying models within a FastAPI-based inference server. You can deploy the same inference server to a Kubernetes cluster by containerizing it using the mlflow models build-docker command. However, this approach may not be scalable and could be unsuitable for production use cases. FastAPI is not designed for high performance and scale (why?), and also manually managing multiple instances of inference servers is backbreaking.

端的にいうと、MLflowのFastAPIによるモデルデプロイは手軽ですが、本番環境には不向きです。FastAPIは大規模な利用を想定しておらず、スケーラビリティやサーバー管理に課題があるためです。

minikubeとKubernatesの関係

Kubernates (k8s) は、コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するためのオープンソースプラットフォームです。本番環境で広く使われていますが、学習や開発のために手元で動かすには、セットアップが複雑です。

そこで登場するのが minikube です。minikubeは、自分のPC（Windows, macOS, Linux）上に、仮想的に単一ノードのKubernatesクラスタを簡単に構築できるツールです。Kubernatesの機能を学習したり、アプリケーションをデプロイしてテストしたりするのに最適です。つまり、「minikubeは、Kubernatesを手軽に試すためのローカル環境構築ツール」だと理解すると分かりやすいでしょう。

スケーラブルにモデル公開できるのがKserve

KServeはKubernetes上で動作する、本番環境向けの高度なMLモデルサービング基盤です。サーバーレスでの自動スケールやカナリアリリースといった機能を提供し、単純なデプロイ方法では難しい拡張性や安定性を実現します。

前項で話したMLflowの標準デプロイ機能は本番の大規模な負荷には向いていませんので、そこで、MLflowでバージョン管理されたモデルを、本番のサービング基盤としてKServeにデプロイするという連携が極めて有効です。これにより、開発・管理はMLflow、本番運用はKServeと、両者の強みを活かした堅牢なMLOpsを構築できます。

以下は本番環境のGKEにデプロイしたあとの利用されるイメージです。

構築手順(MacOS版)

1. PCにツールをインストール

brew install minikube  # クラスタ構築用
brew install kubectl  # Kubernates操作用

2. pipでmlflowをインストール

pip install mlflow

3. ベストモデルの訓練後、MLserverでローカルテスト

GCPで訓練する場合、直接にステップ５へ飛ばしていただいてOKです。

# ローカルのPort1234で推論サーバーを立ち上げる
mlflow models serve -m models:/{my_model_id} -p 1234 --enable-mlserver

# テスト
curl -X POST -H "Content-Type:application/json" --data '{"inputs": [[14.23, 1.71, 2.43, 15.6, 127.0, 2.8, 3.06, 0.28, 2.29, 5.64, 1.04, 3.92, 1065.0]]}' http://127.0.0.1:1234/invocations

{"predictions": [-0.03416275504140387]}

3. ローカルクラスタにkserveをインストール

minikube start
kubectl apply -f https://github.com/kserve/kserve/releases/download/v0.13.0/kserve.yaml

4. ローカルDockerとminikubeでテストデプロイ

KServeにモデルをデプロイするための定義ファイル（マニフェスト）を用意します。以下がDockerを利用したときの書き方となります。

apiVersion: "serving.kserve.io/v1beta1"
kind: "InferenceService"
metadata:
  name: "my-model"
  namespace: "mlflow-kserve-test"
spec:
  predictor:
    containers:
      - name: "my-model"
        image: "{docker_user_name}/my-model"
        ports:
          - containerPort: 8080
            protocol: TCP
        env:
          - name: PROTOCOL
            value: "v2"

以下のコマンドでデプロイできます。

# イメージをビルド、Dockerにプッシュする
mlflow models build-docker -m models:/{my_model_id} -n my-model --enable-mlserver
docker push my-model

# kubectlの接続先を確認
kubectl config current-context
> minikube

# ローカルminikubeで定義ファイルを適用する
kubectl create namespace mlflow-kserve-test
kubectl apply -f inferenceservice.yaml -n mlflow-kserve-test

# エンドポイントのURLを確認
kubectl get inferenceservice mlflow-model -n mlflow-kserve-test

5. GCSにアップロード、Google Kubernate Engine(GKE)へデプロイ

CLI経由してGKEにも直接にデプロイできます。Kserve定義ファイルの書き方は少々先のものと異なります。

apiVersion: "serving.kserve.io/v1beta1"
kind: "InferenceService"
metadata:
  name: "my-model"
  namespace: "mlflow-kserve-test"
spec:
  predictor:
    model:
      modelFormat:
        name: mlflow
      protocolVersion: v2
      storageUri: "gs://{gcp_project_id}-models/artifacts"

定義ファイルを用意できましたら、必要なモデルArtifactをGcloud Storageにアップロードし、デプロイします。GKEがGCSからモデルをダウンロードして推論サーバーを構築してくれます。

# MLflowで生成されたモデルartifactsをGCSにアップロード
gsutil cp -r models/{model_id} gs://{gcp_project_id}_mlflow_models/

# GKEクラスタを作成
gcloud container clusters create my-model
> Creating cluster my-model in asia-northeast1-a... Cluster is being configured...⠏

# Kserveをインストールする
kubectl apply -f https://github.com/kserve/kserve/releases/download/v0.13.0/kserve.yaml

# kubectlの接続先を確認
kubectl config current-context
> gke_research-426801_asia-northeast1-a_my-model

# GKEで定義ファイルを適用する
kubectl create namespace mlflow-kserve-test
kubectl apply -f inferenceservice.yaml -n mlflow-kserve-test

# エンドポイントのURLを確認
kubectl get inferenceservice mlflow-model -n mlflow-kserve-test

以上がデプロイの流れとなりました！

さらなる発展として、deploy_gke.shのbashスクリプトを、GitHub actionsに組み込めば、リポジトリに新しいモデルがプッシュされたら、自動でGCSにアップロードされ、KServeにデプロイされます。これは、MLOpsにおけるCI/CD（継続的インテグレーション/継続的デリバリー）の基本的な流れです。

あとがき

前職(メーカのデータサイエンティスト)の経験上、モデルのバージョン管理やデプロイ管理が非常に煩雑な印象でしたが、記事を通じてMLflowのモデル管理ダッシュボードの便利さ・kubernateへのデプロイドの手軽さなどMLOps周りのエコシステムをしっかり体感できて感動しました。

また、現在主にデータ基盤構築プロジェクトのアーキテクトとしてつとめていますが、データを使ってモデルを構築したあとのMlOpsを触る機会がなく、今回記事を書かせてもらうのを機に、触りたかったGKEを触れてとても大満足でした。今回の記事は、書き手にとってブログ記事を書く価値と意義を改めて体感できた一本です。

番外編

番外編１：minikubeとkind：なにか違うの？

kind (Kubernetes IN Docker) もminikubeと同様にローカルでKubernatesクラスタを構築するツールですが、いくつかの違いがあります。

番外編２：kubeflowとMLflow：なにか違うの？

どちらもMLOps（機械学習基盤）のための強力なツールですが、スコープと目的が異なります。

一言でいうと、MLflowが「実験とモデル」の管理ツールであるのに対し、Kubeflowは「ML全体のワークフロー」をKubernates上で動かすための基盤です。 今回の構成では、Kubernates上でモデルをサービングする部分にKServeを使い、モデル管理の部分でMLflowの思想を取り入れています。

参考

• Develop ML model with MLflow and deploy to Kubernetes | MLflow
• Kubeflow: How to Install and Launch Kubeflow on your Local Machine | Towards Data Science
• TensorFlow Extended、Vertex AI Pipelines、Cloud Build を使用した MLOps のアーキテクチャ
• Kserve | GKE AI Labs

はじめに

初めまして、製造エネルギー事業部の板垣です。先日アコギを購入し学生時代ぶりにギター再燃中です。

春の入門祭り2025の15本目の記事ですが、技術ブログの投稿自体が初めてなためやや緊張しています。温かく見守っていただけますと幸いです。

Amazon QuickSightの入門記事です。最近、業務で触れる機会があったので、これから入門される方々の取っ掛かりとなるような内容になるようまとめます。

QuickSightとは

QuickSightは、AWSが提供しているBI（Business Intelligence）サービスです。

BIで表示するデータの接続先には、AWS内の各種サービス（S3やRDSなど）に加え、企業のデータベースや外部サービス（Google BigQuery、Snowflakeなど）幅広く選択できます¹。目的に応じて、AWS内外のデータを収集／整形し、様々な情報を可視化できます。

QuickSightには様々なユーザを追加できます。AWSのルートユーザやIAMユーザだけでなく（企業の開発者やベンダーなど想定）や、例えばメール招待によって外部ユーザ（企業の経営者や顧客などを想定）を追加ことができます。各ユーザには個別のロールを付与できます。利用費はロール毎に異なり、2025年5月時点のロール別の料金は以下のようになっていました²。

また、Enterprise版ではグループや名前空間といった権限管理周りの仕組みが用意されているため、多様なユースケースに対応できます。

さっそく触ってみる

データを「収集／整形／可視化」する部分のみに注目すると、QuickSightは以下のような要素で構成されています。

各要素の正確な説明はドキュメントに記載されていますが、ここではざっくりなイメージで説明しています。

また、図中の「テンプレート」については後ほど説明します。

1. データソース：QuickSightと外部データとの窓口。外部データにアクセスするための設定などを定義して利用します
2. データセット：可視化の目的に応じて加工されたデータ集合。データ集合どうしを組み合わせて利用が可能です
3. 分析：データセットを元に様々なビジュアル（グラフや指標など）を作成しまとめたものです
4. ダッシュボード：名前の通りですが、分析で可視化した内容を参照だけできるようにしたものです
5. SPICE：可視化を効率的に実現するためのQuickSight専用の機構。データセットで定義されたデータを保持したり（外部データへの直接問い合わせなどが無くなる）、分析やダッシュボードの内部で走る計算を効率的に実現しているようです。SPICEは「Super-fast, Parallel, In-memory Calculation Engine」の略です

ここではQuickSightの画面上での利用イメージを説明するため「データソース／データセットの準備からダッシュボードの公開まで」の一連の流れを順に説明します。

なお、作業するには作成者または管理者相当のロール権限が必要になりますのでご注意ください。ちなみに今回は、管理者ロールで実施しています。

0. アカウントの作成とユーザの登録

ダッシュボード作成の前に、QuickSightアカウントとユーザの登録が必要です（既に完了していればこちらの手順はスキップ可能です）。

AWSアカウントがない場合はAWSアカウントを作成した上で、以下のようにAWSのコンソール画面から検索することでQuickSightのアカウント作成画面へ遷移できます。

アカウント作成画面に進むと以下のような画面になる想定です（2025年5月時点）。

そのまま「QuickSightにサインアップ」へ進むと、アカウント作成に必要な情報を求めらるので入力して進めましょう。

Lambdaのような他のAWSリソースと異なり、QuickSightアカウントはAWSアカウントに1つしか作ることができません。アカウントを複数の方が利用する場合などは、アカウント名などの設定内容については予め相談しておくと良いと思います（もちろん後から変更可能な設定もあります）。

入力を終え、無事作成が完了するとQuickSightの画面に遷移できます。

アカウント作成後は、同じAWSアカウント内のルートユーザやIAMユーザであればそのままコンソール画面からログインできます（初回ログイン時だけ確認のためのダイアログ画面は表示されます）。

また前述の通り外部のユーザも管理者からの招待を受けることでログイン可能です。いずれも初回のログイン以降、ユーザロールに応じて前述したような料金が発生しますのでユーザの管理は気を付ける必要があります。

1. データソース／データセットを準備する

自身のユーザでQuickSightにログインした後、以下の画面に遷移するので画面左側のデータセット項目を選択した後、右上にある「新しいデータセット」を押します。

データソース（新規または既存）を選択する画面に遷移するので、目的のデータソースを選択し、必要があれば設定（データベースなら接続先の設定など）を行います。

ここでは単純な「ファイルのアップロード」による方法で新規データセットを作成します。取り込むデータは、2014年4月から2025年3月までの東京の日別の平均気温で、気象庁のページからダウンロードし、整形したものです。

データソースの各種設定が最後まで進むと以下のようなダイアログが出るため「データの編集/プレビュー」に進みます。

進むと以下のような画面に遷移します。ここで、この後の作業のために画像の「計算フィールドを追加」からデータの取込元に存在しない項目（日付）を用意します。

計算フィールドは、既存のデータ項目と演算子、専用の関数などを利用することでデータセットに新しいデータ項目を追加できる仕組みです。

計算フィールドの編集画面で、項目名と以下の計算式を入力し画像右上の「保存」で追加します。

計算式の詳しい説明はQuickSightのユーザガイドなどが参考になりますが、表計算アプリ（ExcelやGoogleスプレッドシートなど）を利用されたことのある方であれば、セルに入力する計算式のようなイメージに近いかと思います。

parseDate(concat(toString({年}), "/", toString({月}), "/", toString({日})), "yyyy/MM/dd")

完了すると以下の画面に戻るので画像右上の「保存して公開」を押します。

最初のデータセット一覧画面に戻り、新しくデータセットが作成されていればデータセットの準備は完了です。

2. 分析を作成する

用意したデータセットを元に分析を作成します。

先ほどのデータセット一覧画面に新しく作成されたデータセットの右端から「分析の作成」に進みます。

分析は以下のような画面で作成することになります。画像左側に見えているのが先ほど準備したデータセットです（見てわかる通り計算フィールドはここからでも追加可能です）。今回は特に実施していませんが、複数のデータセットを分析に追加も可能です。

試しに、先ほど準備した計算フィールド（日付）と平均気温を使ってグラフを作成してみます。

ビジュアル（折れ線グラフや円グラフなど、表示したいグラフの種類）を選択し、データセットから表示する項目を選択することで簡単にグラフを描画できます。

適宜見た目を整え、準備したデータセットを元に、目的に応じた内容を分析に用意していきます。

今回は最終的に以下のようになりました。気温の表示期間をユーザが自由に調整できるよう「コントロール（画像上側に見える入力パラメータのような欄）」という機能を利用していますが、他にも様々な機能があるので実際に触ってみると面白いかと思います。

3. ダッシュボードを公開する

ダッシュボードの公開は簡単です。先ほど作成した分析の画面から右上にある「公開」ボタンからダッシュボードを公開できます。

以下の一覧画面でも作成されたことが確認できます。

分析なども同じですが、作成したダッシュボードは、QuickSightの他ユーザやグループなどへ共有できます。

もう少し踏み込んでみる

他のAWSサービスと同様にQuickSightではいくつかのAPIが提供されており、付随してCLI（Command Line Interface）や各種SDKも整備されています。

これらを利用することで他サービスとの連携や、QuickSightの各種リソースのコード管理などができます。既にTerraformやCloudFormationなどに代表されるIaC（Infrastructure as Code）ツールも充実してきているようです³。

APIを利用することで、より高度なユースケースを実現できるようになります。ここでは、APIのみで利用可能なQuickSightの仕組み（テンプレート）を題材に、CLIの利用例をご紹介します。使用したAWS CLIのバージョンは以下の通りです。

$ aws --version
aws-cli/2.17.33 Python/3.11.9 Linux/5.15.153.1-microsoft-standard-WSL2 exe/x86_64.ubuntu.22

例：テンプレートで同じ見た目のダッシュボードを作成する

QuickSightにはテンプレートという仕組みがあり、これを利用することで既存の分析やダッシュボードの雛形を同一のQuickSightアカウント内や別のQuickSightアカウントに共有できます（公式ではカプセル化／抽象化するなどと表現されていました）。

共有されたテンプレートとそのスキーマを満たすデータセットを元に、既存のものと同じ（表示しているデータの中身だけ異なる）分析やダッシュボードを作成できます。例えば、開発環境に用意した分析やダッシュボードを本番環境に同じ見た目のものを作成したい、といった場面で利用できると思います。

AWS CLIを利用して先ほどを作成した東京の平均気温をテンプレートとして、別地点（北海道宗谷岬）で同じ見た目のダッシュボードを作成してみます⁴。

テンプレートを作成するために、先ほど作成したデータセットと分析のARNをCLIを使って取得しておきます。

# データセットのARNを取得する例
$ aws quicksight list-data-sets \
  --aws-account-id ${AWS_ACCOUNT_ID} \
  --query 'DataSetSummaries[?Name==`tokyo_kion_2014-2024`].Arn' \
  --output text \
  --profile ${AWS_PROFILE}

arn:aws:quicksight:ap-northeast-1:${AWS_ACCOUNT_ID}:dataset/${DATA_SET_ID}

# 分析のARNを取得する例
$ aws quicksight list-analyses \
  --aws-account-id ${AWS_ACCOUNT_ID} \
  --query 'AnalysisSummaryList[?Name==`tokyo_kion_2014-2024 analysis`].Arn' \
  --output text \
  --profile ${AWS_PROFILE}

arn:aws:quicksight:ap-northeast-1:${AWS_ACCOUNT_ID}:analysis/${ANALYSIS_ID}

取得したARNを元に以下の形式のファイルを用意します。

{
  "SourceAnalysis": {
    "Arn": "{先ほど取得した分析のARN}",
    "DataSetReferences": [
      {
        "DataSetPlaceholder": "kion-data-set",
        "DataSetArn": "{先ほど取得したデータセットのARN}"
      }
    ]
  }
}

作成したファイルを元にテンプレートを作成できます。

以下のコマンドでは指定していませんが、--permissionオプションを利用することで、指定先（本番環境など）へテンプレートの参照権限を付与できます。

作成されたテンプレートは、describe-templateのAPIなどから確認できます。

$ aws quicksight create-template \
  --aws-account-id ${AWS_ACCOUNT_ID} \
  --template-id kion-template \
  --name 'Kion Template' \
  --source-entity file://${PWD}/template_source_entity.json \
  --profile ${AWS_PROFILE}

続いて、テンプレートを元に別地点（北海道宗谷岬）のデータを同じように表示するダッシュボードを作成します。

作成のため以下の形式のファイルを用意します。説明は省略していますが、あらかじめ別地点のデータセットを用意しておく必要があります。

{
  "SourceTemplate": {
    "DataSetReferences": [
      {
        "DataSetPlaceholder": "kion-data-set",
        "DataSetArn": "{別地点（北海道宗谷岬）の平均気温のデータセットのARN}"
      }
    ],
    "Arn": "{先ほど作成したテンプレートのARN}"
  }
}

また、作成されたダッシュボードをQuickSightの画面上で閲覧するために既存のダッシュボード（東京の平均気温）から同じ権限情報を取得しておきます。

以下で指定しているダッシュボードのIDは、describe-dashboardのAPIなどから確認できます。

$ aws quicksight describe-dashboard-permissions \
  --aws-account-id ${AWS_ACCOUNT_ID} \
  --dashboard-id ${ダッシュボードのID} \
  --query 'Permissions' \
  --profile ${AWS_PROFILE} > permissions.json

作成したテンプレートと用意した情報を元に、別地点のダッシュボードは以下のように作成します。

$ aws quicksight create-dashboard \
  --aws-account-id ${AWS_ACCOUNT_ID} \
  --dashboard-id soyamisaki-kion-dashboard \
  --name '宗谷岬の平均気温' \
  --permissions file://${PWD}/permissions.json \
  --source-entity file://${PWD}/dashboard_source_entity.json \
  --profile ${AWS_PROFILE}

QuickSightの画面を見ると作成したダッシュボードが追加されていることがわかります（グラフのタイトルに「東京」となっていますが元のダッシュボードをそのままテンプレートに利用したためです。わかりづらいですが表示しているデータは別地点の情報になっています）。

作成されたダッシュボードは一番初めに作った見た目と同じであることがわかります。

まとめ

QuickSightを入門しようと検討されている方向けの内容をまとめました。後半はやや難しくなりましたが、これからQuickSightを使いこなす上でも必要な内容かと思っています。

ここまで読んでくださりありがとうございました。

初めての寄稿でうまく書けたか不安ではありますが良い経験となりました。これからも機会があれば挑戦していきたいなと思っています。

参考

• ワークショップ :: Amazon QuickSight ハンズオン
• QuickSightで作成した分析を、テンプレート機能を使って別アカウントへ配布してみる

はじめに

こんにちは、SAIG/MLOpsチームでインターンをしていた菅野です。

データ処理やデータ管理を効率化できるAzure Data FactoryとAzure Purviewを検証しました。

背景

MLOpsとは

近年、チャットボットによる問い合わせ対応や、ECサイトのレコメンデーションなど機械学習を用いたサービスが増えるとともに、これらのシステムを効率的に運用することが重要になってきました。

そこで重要になってくるのがMLOps（Machine Learning Operations）です。MLOpsは、機械学習（ML）プロジェクトのライフサイクルを管理・効率化するために、DevOpsの原則を適用する概念です。機械学習のプロジェクトにおいて、モデルの作成・学習は全体の一部であり、他の作業が大きな割合を占めています。下記の画像はビジネスにおける機械学習に関して書かれた有名な論文から引用したものです。モデル作成はシステムの一部であり、モデル作成以外が大きな割合を占めていることが分かります。MLOpsは、そのような周辺の作業を含めた、機械学習プロジェクト全体の作業を効率化し、コスト削減をするためのものです。

▲ 「Hidden Technical Debt in Machine Learning Systems」(D.scully らNIPS 2015)より引用

本記事ではMLOpsを推進するためのツールとして、Azure Data FactoryとAzure Purviewについて検証します。

RAG(Retrieval Augmented Generation)

様々なタスクをこなせる便利な生成AIですが、こなすことができないタスクもあります。それは学習データに含まれていない情報に基づく回答を生成することです。

生成AIは公開されているテキストデータを基に訓練されており、そこに含まれていない情報に関しては知識を持っていません。例えば、自社の社内規定や議事録について質問しても正しく回答ができません。

この課題を解決するためによく用いられる手法が RAG(Retrieval Augmented Generation) です。RAGを用いることで、生成AIが社内情報などに基づいた回答できるようになります。

RAGには、検索フェーズと生成フェーズの2段階が存在します。

• 検索フェーズ: 生成AIにない知識を補うために、自社に蓄積された社内情報や外部の最新情報を取得します。
  1. ユーザーが質問を入力
  2. 入力された質問に関する情報を検索
  3. 検索結果データを取得
• 生成フェーズ: 検索フェーズで取得した文章と、ユーザーの質問文の2つを生成AIに入力することで回答を生成します
  4. ユーザーの質問と3で取得した検索結果データを生成AIに入力
  5. 入力されたデータをもとに、生成AIが回答を作成
  6. 作成された回答をユーザーに出力

▲ RAGとは？仕組みと導入メリット、使用の注意点をわかりやすく解説

このようなRAGシステムを導入するにあたって、課題となるのは検索フェーズの精度です。入力された質問に関連する情報を検索する際の精度が、RAGシステムの品質に直結します。そこで本記事では、優秀な検索エンジンと噂の、Azureサービスで提供されているAzure AI Searchを用いてRAGシステムを運用することを想定します。

また、Azure AI Searchで効率的な検索するためには事前にチャンキングや、エンベディングなどの前処理を行いインデックスに登録しておく必要があります。

インデックスの詳細は以下のサイトを参照してください。

• 検索インデックスの概要 - Azure AI Search | Microsoft Learn
• 基本概念から理解するAzure AI Search - Azure OpenAI Serviceとの連携まで - 電通総研 テックブログ

Azure AI Searchを用いたRAGにおける課題

優秀な検索エンジンであるAzure AI Searchですが、RAGを実現する際に2つ課題があります。

1. Azure AI Searchが非Azureサービスとの連携に弱い
   Azure AI Searchは、インデクサーというコンポーネントを用いて、データの読み込みからインデックスに登録するまでを自動化できます。これにより手作業でAzure AI Searchにデータを登録する必要がなくなり運用コストを抑えることができます。

   

2. どのような前処理を経て、Azure AI Searchに登録されたのかわからない
   Azure AI Searchのインデックスに登録するためには、チャンキングや、テキストをベクトルに変換するエンベディングなどの前処理が必要になります。しかし現状のシステムだと、どのような前処理を経てAzure AI Searchに保存されたのかがわからなく、正確性が担保できません。

目的

上記の課題を解決することが本検証の目的となります。本記事では、Azure Data FactoryとAzure Purviewを用いて、課題解決を目指します。

1. Azure Data Factoryを用いて、複数データソースからAzure AI Searchに登録
   多様なデータベースと連携ができるAzure Data Factoryを用いて、Azure AI Searchが連携できないデータベースと連携し、前処理を行ったうえで、Azure AI Searchに保存します。またAzure Data Factoryの自動トリガー機能やアラート機能を活用してコスト削減する。
2. Azure Purviewを用いて、リネージ管理
   どのデータを基に、どのような前処理を経て、どのファイルに保存したのかを記録し管理することをリネージ管理といいます。このリネージ管理をAzure Purviewの機能を用いて実現します。

ツールの紹介

今回検証するAzure Data FactoryとAzure Purviewについて紹介します。

Azure Data Factoryとは

Azure Data Factoryは、Microsoftが提供するクラウド型のデータ統合サービスで、オンプレミスにあるデータやクラウド上にあるデータを効率的に移動・変換・統合が可能です。Azure Data Factoryを利用することで、異なるデータソースからのデータを収集・統合・変換して、機械学習モデルの訓練や評価に必要な形式に整えることができます。

▼参考：Azure Data Factory とは何ですか。

Azure Purviewとは

Azure Purviewは、オンプレおよびクラウドに散在しているデータを管理し、統制する「データガバナンス」ソリューションです。主に、データの保護、データソースを跨いだデータ検索、データがどのように処理されたのかを管理するデータリネージの機能などがあります。本検証では特にデータリネージ機能について検証します。

• Microsoft Purview の詳細 | Microsoft Learn

Azure Data FactoryとAzure Purviewでできること

Azure Data Factoryを用いることで、様々なデータソースからデータを取得して処理を行うことができます。

またAzure Data FactoryとAzure Purviewを組み合わせることで、データ処理とデータ管理にかかる人的コストを削減ができます。

1. コスト削減

Azure Data Factoryでは、インフラの管理やメンテナンスが不要です。また、データ処理を自動化することで、エンジニアが定期的にプログラムを実行する手間を省くことができます。さらにAzure Purviewを用いることで、どのデータからどのようなプロセスを経て作成されたかなどのリネージ管理をおこなうことができます。データの正確性を担保することでデータの再利用がしやすくなり、再びデータ処理などをする手間がなくなります。

2. データの一元化

Azure Data Factoryは多様なデータソース（オンプレミスやクラウド、構造化データや非構造化データ）をサポートしており(参考：対応しているデータソース)、簡単にデータを取り込み、統合ができます。一度登録したデータソースであれば、すぐに呼び出して使うことができます。また、Azure Purviewを用いることでデータソースを跨いだデータの検索、参照できます。

3. 可視化

Azure Data FactoryとAzure Purviewにはビジュアルインターフェースがあり、データ処理のフローやデータ依存関係を視覚的に管理できます。これにより、処理の流れやデータの関係性を素早く理解ができます。

検証

本記事で検証したAzureのUIは2024年9月時点でのものです。

Azure Data FactoryとAzure Purviewの利用手順

初期設定

Azure Data FactoryとAzure Purviewで作業を始めるための設定の流れです。

1. Azureポータルでリソースを作成
   以下のリソースを作成します。

   • Azure Data Factory
   • Azure Purview
   • キーコンテナ
   • ストレージアカウント

2. Azure Purviewでコレクションを作成
   Azure Purviewでは、コレクションごとに管理します。コレクションには複数のデータソースを登録でき、またアクセス制御などもコレクションごとに行えます。

   

3. Azure Data FactoryとAzure Purviewの接続
   Azure Purviewの「管理」画面から「系列接続」を選び、Azure Data Factoryの項目で設定します。

   

4. ストレージアカウントとAzure Purviewの接続
   キーコンテナを使用して接続します

   1. キーコンテナのアクセス権限を編集します
      • アクセス制御画面で自分のAzureアカウントにキーコンテナ管理権限を付与
      • アクセスポリシー画面でAzure Purviewリソースに「シークレットのアクセス許可」の「取得」権限を付与
   2. ストレージアカウントでアクセスキーを発行し、キーコンテナに登録します
   3. Azure Purviewでソースメニューの適切なコレクションから「登録」アイコンを選択し、新しいAzure Blobデータソースを登録します
   

Azure Data Factoryによるデータソースの登録

以下の手順で登録します。

Azure Data Factoryによるパイプライン作成

Azure Data Factoryは、データセット、パイプライン、データフローという3つの要素から構成されます。

• データセット：各種データサービスとの連携を設定します
• パイプライン：データ処理全体の流れを記載します
• データフロー：実際にデータ処理を行います。パイプラインから呼び出します

パイプラインとデータフローには以下のアクティビティがあります。アクティビティとは、プログラミングにおける関数のようなもので、アクティビティ内に行いたい処理を記載し、それらを呼び出すことでデータ処理を行います。一度作成したアクティビティは再利用可能で、他のパイプラインやデータフローに使用できます。アクティビティに用意されていない複雑なデータ処理を行いたい場合は、Azure関数やDataBricksを呼び出すことで、コードベースによるデータ処理も行うことができます。

Azure Data Factoryに慣れるため、以下のようなパイプラインを作成しました。

1. 特定のディレクトリからファイル名の一覧を取得します
2. 取得したファイル名を変数に設定してデータフローに渡します
3. データフローを呼び出します
4. データを読み込みます
5. 不要なカラムを削除します
6. 「male」や「female」などの文字カテゴラルデータを数字に変換します
7. 変換後のデータを保存します

パイプラインで設定した変数やデータは、データフロー内で使えません。使いたい場合は、データフローのパラメーターに渡す必要があります。具体例を説明します。

まず、データフロー側でパラメーターを設定します。

次に、パイプライン側からデータフローのパラメーターに変数を設定します。

Azure Data FactoryとAzure Purviewの動作確認

作成したパイプラインを用いて、Azure Data FactoryとAzure Purviewの機能を確認します。

作成したパイプラインの処理結果

作成したパイプラインをKaggleのtitanicデータに対して、実行してみると正しくデータ処理を行えていることが確認できました。

パイプラインの自動トリガー

Azure Data Factoryで作成したパイプラインは、様々な方法で実行させることができます。

• API/SDKを使用した実行
  .NET SDK、Azure PowerShell、REST API、Python SDKを使用してパイプラインを実行できます。(参考)
• スケジュール
  日時に関する条件をトリガーにパイプラインを実行できます。
• ストレージイベント
  ファイルの追加/削除などのストレージに関する条件をトリガーにパイプラインを実行できます。
• カスタムイベント
  自分で作成したトリガー条件によってパイプラインを実行できます。

今回はストレージイベントを使用して、指定したディレクトリにファイルが追加されたらパイプラインを実行するようにしました。3ステップで簡単に設定できます。

ディレクトリにファイルを追加すると、設定したしたトリガーによってパイプラインが実行されていることがわかります。

リネージ管理

接続しておいたAzure Purviewから、リネージを確認してみます。

test-inputが、Data flow 1で処理されて、test-outputに保存されていることが確認できます。

Data flow 1の処理内容が知りたいときは、「Azure Data Factoryで開く」をクリックすることで確認しに行けます。

Azure AI Searchのインデックスに登録

使い方が分かったところで、Azure Data Factoryを用いて、Azure AI Searchのインデックスにフューチャー技術ブログのテキストを登録してみようと思います。

初期設定

Azure AI Searchのインデックス登録のために、以下のリソースを作成します。

• Azure Open AI
  作成したリソース内でテキストエンベディングのを行うモデルをデプロイします。今回はtext-embedding-ada-002モデルを使用します。
• Azure AI Search

手法

今回は以下の流れでテキストデータをAzure AI Searchインデックスに登録します。

1. フューチャー技術ブログからテキストデータを取得/保存
2. テキストファイルからテキストデータを取得
3. Azure OpenAIでベクトル化
4. 文章、タイトル、ベクトル等をAzure AI Searchインデックスに登録する

また 2~3 の処理をAzure Data Factory内で行うことで、Azure AI Searchに保存する処理までを自動化します。

Azure Purviewによって各データ処理を監視することで、リネージを管理します。

AI Searchインデックスに登録するパイプラインは以下のようになります。

1. フューチャー技術ブログからテキストデータを取得/保存

Databricksを用いて、フューチャー技術ブログの情報を取得し、Azure Blobストレージに保存します。

Azure Data FactoryのWebアクティビティを用いて、フューチャー技術ブログの情報を取得もできますが、Databricksを用いました。

2. テキストファイルからテキストデータを取得

まず、「Get Metadata」アクティビティを用いて、ディレクトリ内のファイル名を配列として取得します。データセットを指定することで、そのデータセットに関する情報を取得できます。今回は以下の3つを取得します。

• アイテム名(ディレクトリ名)
• 子項目(ディレクトリ内の各ファイル情報)

次に「ForEach」アクティビティを作成し、取得したファイル名それぞれに対して処理できるようにします。

「ForEach」アクティビティ→設定→項目に以下のように記載することで「ForEach」アクティビティ内で取得した配列を扱えるようになります。

@activity('「Get Metadata」アクティビティ名').output.childItems

最後に、「ForEach」アクティビティ内に「参照」アクティビティを作成して、テキストデータを取得します。

ソースデータセットと値を下記のように設定します。

取得したテキストデータは@{activity(‘Lookup1’).output}という変数に格納されます。

3. Azure OpenAIでベクトル化

読み取った文章をAPI経由でAzure OpenAIに渡してベクトル化します。

1. 「Web」アクティビティを作成:

   • UIから指定すると動作が不安定な場合があるので、JSONを直接編集することをお勧めします

2. テキストのエンベディングモデルを作成:

   • Azure OpenAIのリソースからエンベディングモデルをデプロイします
   • 今回は text-embedding-ada-002 を使用します

3. URLの指定規則:

   • 以下の形式に従います

   https://<OpenAIのリソース名>.openai.azure.com/openai/deployments/<デプロイしたモデル名>/embeddings?api-version=<APIのバージョン>

4. inputにエンベディングしたい文章を指定:

   • 作成した「Web」アクティビティのjsonのtypePropertiesの箇所を以下のように編集します
   • 取得したテキストデータはbody→inputに設定されています

   "typeProperties": { "method": "POST", "headers": { "api-key": "YOUR API KEY", "Content-Type": "application/json" }, "url": "https://OpenAIのリソース名.openai.azure.com/openai/deployments/OpenAIの中でデプロイしたモデル名/embeddings?api-version=APIのバージョン", "body": { "input": "@{activity('<アクティビティ名>').output.firstRow.Prop_0}", "model": "text-embedding-ada-002" } }

4. 文章、タイトル、ベクトル等をAzure AI Searchインデックスに登録

Azure OpenAIから作成したベクトルや、本文をAPIを経由してAzure AI Searchに保存します。

1. 「Web」アクティビティを選択

   • api-key、URL、本文を指定します

2. URLの指定規則

   • 以下の形式に従います

   https://Azure AI Searchのリソース名-free.search.windows.net/indexes/Azure AI Search内のインデックス名/docs/index?api-version=your api version

3. 本文に登録したいデータを設定
   Azure AI Searchのインデックスに登録したい情報を設定します。
   今回は、ファイル名、id、文章、ベクトル化した文章を設定しました。idには記号を設定できないため、ファイル名から記号を取り除いたものを設定しています。任意に設定してください。

   "@search.action": "upload", "file_name": "@{item().name}", "id": "@{concat(base64(replace(replace(replace(replace(item().name, '/', '_'), '-', '_'), '.', '_'), ' ', '_')), '_', formatDateTime(utcNow(), 'yyyyMMddTHHmmssZ'))}", "content": "@{activity('<アクティビティ名>').output.firstRow.Prop_0}", "content_vec": "@{activity('<アクティビティ名>').output.data[0].embedding}"

動作確認

Azure AI Searchのインデックスを見てみます。ファイル名や文章、ベクトルが正しく保存されていることがわかります。このインデックスを用いてRAGを実現できます。

Azure Purviewによるリネージ管理

Azure Purviewを用いたリネージ管理は今回実現できませんでした。考えられる原因は以下です。

• Azure PurviewがAzure AI Searchに対応していない
• APIで行った処理はAzure Purviewで追跡できない

解決策として、前処理を行った後のベクトル等のデータを一度どこかのストレージに保存することなどが考えられます。

まとめ

今回の検証では以下を行いました。

• Azure Data FactoryとAzure Purviewの利用手順の確認
• Azure Data Factoryを用いたデータ処理の自動化
• Azure Purviewを用いたリネージ管理
• テキストファイルからAzure AI Searchのインデックスに自動登録

また検証を通してそれぞれのツールに対して感じたことは以下です。

Azure Data Factory

• メリット
  • 幅広いデータソースとの連携
  • 作成したアクティビティの再利用
  • 自動トリガーやアラート機能などの周辺機能
• デメリット
  • アクティビティとして用意されていない処理を行いたい時に不便

Azure Purview

• メリット
  • リネージ管理が便利
  • データソースを跨いだ検索やタグ付けが優秀(未検証)
• デメリット
  • 軽く導入するには費用が高い点
  • Azure Data Factory側で、適切な設定をしないとリネージ管理されない点

展望

インターン期間の関係で検証しきれなかった点があるので記載いたします。

• Azure Data Factory内のwebアクティビティを用いて、Webサイトからテキストを抽出できるか
• Azure Data Factoryから、リンクサービスとしてAzure AI Searchに登録ができるか
• Azure Purviewを用いて、AI Searchインデックスのリネージ管理を実現できるか

またAzure Data FactoryとAzure Purview以外の検証事項について以下があります。

• Azure AI Searchのセマンティックランカー/ハイブリッド検索
• 適切なチャンク分けを行い、Azure AI Searchに登録
• Azure AI Searchの検索精度

感想

Engineer Campに参加させていただき、これまで触れてこなかったAzureサービスに初めて触れることができ、とても新鮮な体験となりました。普段プログラムを作成して行っている処理を、驚くほど簡単に実現できることに衝撃をうけ、クラウドサービスがこれほど流行している理由が理解できました。

また、1ヶ月のインターンを通じて、開発から発表まで一通りの業務を行う中で、相談の重要性やプレゼンテーションの構成方法、スモールスタートを意識した課題解決のアプローチなど、多くの貴重な学びを得ることができました。資料作成スキルなど、自身の課題も浮き彫りになり、成長すべき点を具体的に認識できたことも大きな収穫でした。

非常に有意義な時間を過ごさせていただき、ありがとうございました。

はじめまして、製造エネルギー事業部に所属している岡田と申します。現在、〆切に追われて出張先へ向かう飛行機の中で焦って本稿を書いています>_<

私は2020年4月に新卒で入社し、一貫してシステムの構築～保守というシステム構築における王道パターンのキャリアを歩んできました。

しかし、昨年1年間は「データを駆使して仕事を進める」という少しいままでと色の違う経験をしました。この記事では、その中で得た知見や工夫した点を、「春の入門祭り2025」にあわせて共有します。

データ分析の目的

当たり前ですが、データ分析の目的は「分析すること」ではなく「達成したい目的(課題)に対してデータの観点からアシストをすること」と捉えていますす。

クライアントが「〇〇したいが、何故かできない」のような状況の際に、データという観点からどのようなアシストができるのかを見つけるツールのようなイメージです。そのため、分析自体になにか価値があるというわけではなく、分析によって実現したいことへ近づけた際に初めて分析の価値が生まれます。

たとえば、スーパーを運営しているクライアントから「利益率を上げたいが、これ以上上がる見込みがない。投資する余力はあるが、どこに投資していいのかがわからない。」という相談を受けたとします。

そのとき、（スーパーのデータに全てアクセスできると仮定したとき）読者のあなたはどのような分析が出来るでしょうか？

• 各レジの単位時間あたりの売上を見て、偏りがあれば偏らせないような施策を打つ
• 廃棄している商品の割合を商品別に出し、廃棄が多い商品は早めに割引する施策を打つ
• レジ員ごとの単位時間あたりの処理数を出し、効率が悪いレジ員はクビを(ry

…などなど、データという観点から業務のボトルネックとなっている箇所を特定し、そこに対してなんらかのアプローチを打つことで利益率を上げることが出来るでしょう。

データ分析による施策の効果見積もり

また、データ分析はボトルネックの特定だけではなく、複数の施策案があったとき、どの施策がどの程度の効果があるかを見積もることもできます。

すごく簡単な例で例えると、「100人の従業員を今より2時間早く帰社させたときに、人件費はどれだけ削減出来るか？」という問いがあった際は、100人それぞれの時給単価×2時間を合計するような20行ほどのSQLを書けば分すぐに見積もることができます。

このように、現在の実績データをもとに、将来どの程度の効果がかるのかを見積もり数値化出来ることもデータ分析の面白いところかもしれません。

机上の空論と現場とのすり合わせ

ここまでの話は、データ上のみの話で、いわば机上の空論です。

では、机上の空論による改善案を実際に現場に実行させようとするとどうなるでしょうか？現場からは非難の嵐になるでしょう。現場の実情は、データから見えることとは大きく違う可能性があります。

そのため、データによって出た案をまずは現場の方々に見せ、認識があっているかを事前にすり合わせます。現場の方々との感覚をすり合わせながら軌道修正した案を実行することで、現場の方々も納得しながら高い効果を発揮できるようになります。

んで、実際に分析ってどうやるの？

ここまでは、データ分析における前提や、進め方について記載しました。

• データ分析というものになんとなく興味があるが、実際なにをどうするのかイメージがついていない
• とりあえずデータは手元にあり、なんか面白い分析をやってみたい

…のような方に、超簡単にできるデータ分析のワザを記載します。

これを読んだら今日からあなたもデータ分析マスターです。

1.調査するデータの構造を理解する

まずは、入口にして一番大事なところです。

最初にデータを扱う際は、まずデータの構造について自身が腹落ちするまで理解する必要があります。

最初に1から100まで完璧に理解をする必要はありませんが、最低でも主要テーブルと、主要テーブルの中のプライマリーキー、フォーリンキー（外部キー）、主要な属性項目については頭に叩き込んでおきましょう。また、カラム（横軸）だけではなく、レコード（縦軸）の発行の粒度についても理解が出来るとなお可です。

これらが十分に理解できたとき、データ分析を始める下地は十分整っていることでしょう。

2.実際にSQLで、調査したいデータを出力する

前工程である程度テーブル構造について理解ができたら、まずは試しにデータを出してみましょう。

最初は簡単に、1つのトランをそのままselectしてくるのでも構いません（ただし、全selectはデータ量によっては障害を起こす可能性もあるのでlimit句や日付指定等で、過剰なデータを要求しないよう気をつけてください。）

ただし、Excelは100万行程度までしか受け付けられないため、大きなデータのときはあらかじめ観点を絞って集約関数やウィンドウ関数等を用いてデータ量を圧縮してから出力しましょう。

3.Excelに貼り付けて、自由に分析する

次は、A5ERやDBeaverなどのクライアントツールで出力された結果をコピーし、Excelにそのまま貼り付けます。
（今回は、適当に用意した表を用いて説明をします）。

貼り付けた直後にCTRL+Tを押すとテーブルとなり、リボンのテーブルデザインから「ピボットテーブルで集計」を押してみましょう。

表をテーブルに変換

「ピボットテーブルで集計」を押し、ピボットテーブル化。

作成先をテーブルを新規シートではなく、表のすぐ右隣にしておくと便利。

そうすると準備完了です。ピボットテーブルで横軸・縦軸をそれぞれ設定し、「値」のところは適当な項目を設定し右クリックで「個数」「合計」など、好きなものを選択してもらえれば、自由に分析結果を出すことができます。

「種類」を列に、「年齢」を行にドラッグし、値を種類の個数とすると、犬と猫の年齢別の数が出てきます。

この例だとサンプルが少なすぎて傾向等は見えませんが、データ量が大きくなると相関やボリュームゾーンが見えてくるようになります。

最後に、グラフを出してみましょう。（性別のカラムを追加しました）

今回は、犬と猫それぞれで性別にどのような偏りがあるかを見てみましょう。

行を種類、列を性別とし、リボンの「ピボットグラフ」から「100％積み上げ縦棒」を選択すると、犬と猫それぞれの性別の割合を示すグラフが出てきます。

こうグラフ化することで、「犬はメスの割合が多いのか～」ということがわかると思います。
（※データは適当に作成したため、現実世界におけるオスメスの割合とは一致しません）

さて、ここまでの分析操作ができれば、今日からあなたもクライアントや上司から一目置かれるデータ分析マスターです。

おわりに

今回は、入門者向けにデータ分析に関する簡単なやり方を記載してみました。

私も最初は「自分にデータ分析なんて出来るんだろうか」とモヤモヤしていましたが、やってみると楽しく、統計の勉強を進めるキッカケにもなったので、興味のある方は是非挑戦してみてください。

手元にデータがあれば、ぜひ簡単なところからデータ分析を始めてみませんか？

こんにちは。フューチャーのサマーインターン2024 Engineer Campに参加した、羽根田です。

インターンに参加した経緯・実際に取り組んだ内容・学会参加の後日談を、インターン体験記としてまとめます。

概要

ここからは、私のインターン参加記を時系列順にまとめていきます。

私は就活の一環として本インターンに応募し、自身の研究における専門性を活かすために「自然言語処理に関する研究開発」というテーマで参加しました。業務としてはサーベイから実験といった基礎研究に取り組み、最終的にインターンの成果を国内学会で発表できました。

詳細はそれぞれの章にまとめていきますので、気になるところだけでも読んでいただければと思います。

応募から参加まで

大学院修士1年の夏、私はこのインターンに参加しました。

大学院生としての研究生活には少しづつ慣れてきたものの、多くのM1の方と同じように、私もまた迫りくる「就活」の二文字に背中を焼かれているような状況でした。しかし、2年後の春にはどこかの企業で働いているということの想像があまりにもつかず、とにかくこのあたりのイメージを固めたいという気持ちからインターンを探し始めました。

こういった経緯もあり私はEngineer Campだけでなく、様々なインターンに乱れ撃つように応募をしていました。

私の中でのインターン先の条件としては次の2つがありました。

• 自分の自然言語処理分野へのスキルや興味を活かせること
• 2週間以上の、ある程度長期間取り組めるものであること

1つ目は私が自然言語処理の研究室に所属しており、せっかくならそこで培ったスキルがどの程度活かせるのか試してみたいという気持ちから。2つ目に関しては、比較的長期間腰を据えて参加できるものの方が自分の今後の成長につながるのではないか、という考えからです。

とはいえこの2つを満たせるインターンはそう多くありません。

さて次はどの企業のインターンに応募しようかと考えていたころ、ふと、春先に参加した言語処理学会にて「フューチャー」という企業がポスター発表をしていたことを思い出しました。この発表が面白かったこともあり、「ITコンサルも言語処理をやっているんだなあ」という意外さとともに私のなかで印象に残っていました。

早速調べてみるとフューチャーのサマーインターン募集ページを発見。

20種類近い、かなり幅広い分野のテーマで実施しており、その中には私の希望する自然言語処理分野のテーマもありました。

大規模言語モデル（LLM）を含む自然言語処理 （NLP） 技術を活用した様々な問題の解決に、メンターとなる社員と共に挑戦していただきます。国際会議を含めた論文出版、特許取得を狙う基礎研究寄りのタスクから、実社会のデータを活用したモデル構築、実際に多くの方に使われるシステム開発まで幅広いプロセスに携わっていただきます。実際に取り組むタスクについてはご本人の希望・適性に応じて相談の上で決定します。

という若干ふわっとした概要に一抹の不安を抱きながらも、とりあえず応募してみることにしました。

インターン本番

無事に選考を通過し、晴れてインターンに参加できることとなりました。

1ヵ月の長期インターンということもあり、不安な気持ちもありましたが、当初の希望通り「自然言語処理に関する研究開発」での参加ということで、かなり前向きな気持ちで臨むことができていました。

ここからは実際の業務内容をメインに、1ヵ月間の具体的な過ごし方をまとめていきたいと思います。

初日

Engineer Campは基本的にはリモートで行われたのですが、顔合わせや手続きのために初日と最終日は大崎のオフィスに出社しました。緊張で目を回しそうな私を、いかにも”TOKYO”といった雰囲気の洒落たエントランスがお出迎え。ここから4週間のインターン生活がスタートしました。

初日はまず全体説明からはじまりました。業務で用いるパソコンのセットアップや業務内容・契約の確認などを済ませているうちにあっという間にお昼休憩の時間となりました。ランチタイムでは自分以外のインターン生や社員の方とも交流しました。

午後はセキュリティ講習から業務再開となり、その後受け入れ先の自然言語処理チームのメンターの方との顔合わせがありました。メンターの方々は温厚な雰囲気で話しやすく、ほっとしたことをよく覚えています。その後、オフィス内の見学やパソコンのセットアップの続きをしているうちにあっという間に終業となりました。

余談ですがオフィス内にはカフェスペースやボルダリングスペース（なぜ？）などがあり、かなり面白かったです。

第1週

1週目は基本的に、今後の活動の方針決めや環境構築などをして過ごしました。

私の参加したテーマは「自然言語処理に関する研究開発」であり、かなり研究寄りの業務でした。そのためまずはメンターの方々から提示された研究アイデアをもとに、この1か月間取り組むテーマを決定しました。

テーマに関しては、基本的には提示されたものの中から選ぶ形でしたが、あくまでインターン生の興味関心が重視されていました。メンターの方と一緒にアイデアを形にしていく感覚が強く、インターンとしては特徴的な進め方だったと思います。

話し合いの結果、私は「LLMを用いた文字数カウント・文字数制御」というテーマに取り組むこととなりました。

第2週

2週目はまず、既存研究のサーベイをすることから始まりました。

私のチームはインターン生1人に対しメインメンターが1人付くという形で業務を進めることになっており、学生とメンターが3組、計6名で構成されていました。基本的にはメインメンターの方と密にやり取りをしつつ、時々チーム全体での報告会をしながら、各々の研究を進めていきます。

そのため毎朝メインメンターの方とミーティングをする機会がありました。朝のミーティングでは、前日の進捗報告→次にやることを決定するというサポートを丁寧にしていただけるため、手が止まってしまうことや何をすればいいかわからなくなってしまうということはほとんどありませんでした。

万が一そうなってしまった場合でも、Slackを通じてメンターの方とはいつでもコミュニケーションが取れるため、すぐに救助を要請できました。

また、毎日の朝会では、業務の話以外に雑談をすることもありました。雑談は普段のコミュニケーションがより円滑になるだけでなく、社員の方の生の声が聞けるため、就職先選びという文脈においても貴重な話を聞くチャンスでした。

サーベイ結果のまとめ方のフィードバックや、研究のアイデア出しなどをもらいながら、2週目の段階で簡単な予備実験まで進めることができました。

この時期には私もかなりインターン生活に慣れており、大きなトラブルなどもなく、業務を進めることができていました。始業10分前まで布団に入っているほど慣れてしまっていたときもあるほどでした。

第3週

3週目ではいよいよ本格的に実験を進めることになりました。

基本的にはPythonでコードを書き、結果をメンターの方に共有しつつ、次の実験に向けて調整していくという流れで業務が進行していきました。2週目のサーベイからこの週の実験に至るまでは特に「研究」という色が濃かったと思います。個人的には一番熱中して作業に取り組むことができた期間でした。

一方で、ただ実験をしていればよい、というわけではありませんでした。最終週にインターン参加者とメンターの参加する成果発表会が控えていたためです。そのため、インターンの研究として明確にゴールを見据えて作業することが求められていました。

当然、1ヵ月という限られた期間での研究業務であるため、ある程度結果を出しつつ、最終の着地点を調整することは容易でありませんでした。しかしメンターの方と密にやり取りをしながら計画的に作業を進めることができたため、全体を通じて見通し良く作業ができたように思います。

最終週の発表会に向けてスライド作成を始めながら、この週の業務を終えました。

第4週

最終週は発表会への準備とインターンの締め作業とで慌ただしく過ぎていきました。

発表会用のスライドに関しても、メンターの方のフィードバックをもらいながら作業に取り組みました。フューチャーは会社の文化としてプレゼン能力を重視していることもあり、スライド作成についても多くの学びを得ることができました。

発表会当日は他のインターン参加者の発表も聞くことができました。改めてバラエティ豊かなテーマ展開だなと感じつつ、他のインターン生の発表ぶりはかなり良い刺激になりました。

最終日は大崎のオフィスに出社し、振り返りや後片付けなどを行い、私のインターンとしての研究業務は終了となりました。

その他

毎週、通常の業務の他にいくつかイベントもありました。

1つ目は、人事の方との週次面談です。

インターン業務に関する相談をはじめ、就活全般のアドバイスをもらうことができます。やはりプロとは恐ろしいもので、私が進路についてフワフワとしか考えていなかったことは瞬時に見抜かれました。即席の自己分析会が開催され、そこで進路について一緒に考えてもらいました。

2つ目は社員の方による講義です。

スライドの作り方やプレゼンの仕方、プロジェクトの進め方といった講義が開かれました。社員の方ならではの貴重なお話が聞ける機会だったと思います。長期インターンであることに加えリモートでの作業であったため、どうしても慣れすぎてしまうタイミングはありました。ですが、こういったイベントがスパイスのように時折挟まれるため、全体としては業務がダレにくくなっていたように感じました。

1日のスケジュール

• 10:00～11:00　メインメンターとの朝会
  　進捗を報告し、ネクストアクションを決定します。
• 11:00～12:00　午前中の作業
  　私の場合は、朝会の振り返りをしながら午後に取り組む作業をより明確に分割して整理したりしていました。
• 12:00～13:00　お昼休憩
  　お昼ご飯です。仮眠を取ったりした日もありました。また、休憩タイミングは任意に選べるので、休憩前の業務時間を長めに取る日もありました。
• 13:00～18:30　午後の作業
  　実験を回したりサーベイをしたりなど、午後は腰を据えて時間のかかる作業に取り組んでいました。
• 18:30～19:00　整理など
  　翌日の朝会に向けて資料や結果をまとめたり、日報を書いたりして過ごしました。勤務時間の申請をして退勤となります。

後日談：アルバイトとしての研究継続～学会まで

さて、ここからはインターンの後のお話をさせていただこうと思います。

インターン終了後、私はアルバイトとして契約し、インターン時のテーマに関して引き続き研究業務に取り組むこととなりました。インターン後にアルバイトとして雇用されることは珍しいケースではなく、私以外にも何人かの方が継続してフューチャーで仕事をしているようです。

アルバイトとしての業務ではインターンの際に取り組んだテーマをさらに深堀りつつ、3月に行われる言語処理学会年次大会での発表を目標に、論文の執筆に取り組みました。インターン期間中にしっかりと方向性を定めた実験ができていたこともあり、比較的スムーズに論文を完成させることができました。

学会では長崎でポスター発表し、インターンから始まった研究をきちんと締めることができたと感じています。

自分がフューチャーの存在を知ることになった学会発表を、今度は自分がフューチャーの一員として行うことができたというのも感慨深いものがありました。

インターンを通して

就職のイメージ固め、という理由から始まった私のインターン生活ですが、こうして振り返ってみると、とても多くのものを得られたように感じます。

まず普段の研究とは少し違ったコミュニケーションのスキルを学ぶことができました。メンターの方との認識の齟齬が生じないような伝え方の工夫や、非同期テキストコミュニケーションを効率的に活用することなど、適切な情報伝達の重要性を感じました。

また、個人的には「制限時間」の存在が作業の進め方に見通しを持たせてくれたとも感じています。

今回のインターンは1ヵ月という制限時間の中で結果をまとめる必要がありました。もちろん毎日の業務も規定された勤務時間内に行う必要があります。この制限時間によって、1ヵ月なら最終的なゴールはここにして…なら今週中にここまで進めたいから…それなら今日はここまで…と逆算して計画を立てるクセをつけられたと感じています。

他にもサーベイ→実験→まとめのサイクルといった研究的なスキルや、インターン生の友人やメンターの方といった人とのつながりなど、多くのものを得ることができました。

改めて全体を通して大きく成長できた期間だったと思います。

さいごに

今回は私が参加したフューチャーのEngineer Campについて、実際の業務内容や参加者としての感想などをまとめてみました。

改めて、今回受け入れていただいたメンターの皆さん、大変お世話になりました。

最後にこの記事がインターン先を考えている方にとって少しでも参考になるところがあれば嬉しく思います。

ここまで読んでいただき、ありがとうございました。

はじめに

はじめまして。フューチャー株式会社の松岡と申します。私は2024年7月に当社に入社し、現在はStrategic AI Group（SAIG）の一員として大規模言語モデル（LLM）の社会実装に取り組んでいます。私自身、LLMは大学院時代の専門領域ではありませんでしたが、LLMに興味を持ち、SAIGに所属しています。現在はNLP畑出身の専門家の方々と日々の業務と技術の研鑽に取り組んでいます。

そんな私が、2025年3月10日（月）〜3月14日（金）において長崎出島メッセにて開催されました言語処理学会第31回年次大会（NLP2025）に初参加してきました。

当社はプラチナスポンサーとして参加しており、私含めてSAIG7名がオンサイトで参加し、スポンサーブースで会社を紹介し、ポスターを発表しました。

私は社会人1年目の新参者であるにもかかわらず、SAIG内部で参加者を募集している際に「私も参加したい」と声を上げたところ、参加できることとなりました！！快く送ってくださったSAIGの方々には感謝してもしきれません。

言語処理学会とは

言語処理学会はNLP分野における国内最大の学会で、毎年3月に開催されています。年次大会は今年で31回目となります。口頭発表は5会場に加えポスター発表2会場の合計7会場に分かれ実施され、最終日にはワークショップと盛りだくさんの内容です。

参加者数は当日登録含まない一日目時点で2248名、発表件数777件、スポンサー数103団体と、過去最大の参加者数、発表件数、スポンサー数であり、参加していて非常に活気がある学会でした。

実際に参加をしてみて、独特だなと思ったのはslackの運用です。NLP2025ではslackのワークスペースを独自に開設しており、聞きたい発表のチャンネルに入ることで、そちらから質問できました。発表内容に関する議論も積極的に行われており、その議論から知見も多く得られたと同時に言語処理学会の熱気を感じ取ることができました。

スポンサーブース

企業ブースを出展しAI案件実績を紹介し、人材を募集しました。当社をご存じなかった方々にもアピールでき、研究についてや案件内容に用いた技術についてのディスカッションなど、大変盛り上がりました。

主に学生の方へ向けては、会社紹介のパンフレットと共にノベルティとしてトートバッグを配布しながら、会社についての紹介をしました。たくさんの方々に来ていただき、大盛況でした。

投稿論文の紹介

当社は、NLP2025において著者・共著者を含めて合計5件の論文を投稿しました。

本章ではこれらの5件の論文について簡単に紹介します。

[P2-13]「数」に着目したLLMの多言語能力の検証

この論文では、大規模言語モデル（LLM）の多言語能力を、LLMに単語や文の文字数を数えさせるカウントタスクと、指定した文字数で文を生成させる生成長制御タスクの2つの「数」に着目したタスクによって検証しました。

文字列カウントタスクでは、単語のカウントは高い精度を示しましたが、文のカウントでは精度の低下が確認されました。

生成長制御タスクでは、ヨーロッパ言語はヨーロッパ言語の指示で生成させる方が、アジア言語はアジア言語の指示で生成させる方が精度が高い傾向が見られました。また、中国語と日本語を生成させた場合、生成結果の平均長が指定した50文字よりも短くなる傾向がありました。さらに、日本語で指示を与えた場合、英語、スペイン語、ポルトガル語の生成結果が著しく長くなる現象が確認されました。

[P2-24] Wikipediaリダイレクト情報を活用したエンティティベース質問応答データセットの構築

この論文では、大規模言語モデル（LLM）がエンティティをどのように記憶しているかを調査するために、Wikipediaのリダイレクト情報を活用した新しい質問応答データセットRedirectQAを提案しています。

RedirectQAでは複数の表層を考慮に入れることが可能であることが特徴で、LLMがエンティティ自体を記憶しているのか、それとも特定の表層を記憶しているのかをより詳細な分析が可能です。

また、Pythiaの12Bモデルを用いて、作成したデータセットを用いて、LLMの記憶がエンティティではなく表層に紐づいているかを評価しました。

その結果、LLMは代表的な表層を記憶している場合でも、必ずしもすべてのリダイレクト表層を記憶しているわけではないことが示されました。また、表記揺れのような表層の差異が小さい場合には、記憶が紐づきやすい傾向があることも示唆されました。

[Q6-9] 日本語によるコード生成能力の正確な評価に向けて

この論文では、日本語によるコード生成能力の正確な評価を目的として、複数のプログラミング言語に対応したコード生成ベンチマークであるMultiPL-Eを日本語化することで、JavaおよびC++の評価データセットJMultiPL-Eを構築しました。そして、Llama-3.1-8B-Instruct（Llama）とLlama 3.1-8Bに対して日本語で継続事前学習したLlama-3.1-Swallow-8B-Instruct-v0.1（Swallow）という2つのLLMモデルを用いて、日本語でのPython、Java、C++のコード生成能力と継続事前学習がコード生成能力に与える影響を調査しました。

日本語で継続事前学習したSwallowでは、日本語と英語の指示文によるスコア差の縮小が確認されました。また、SwallowはJavaおよびC++において、Llamaよりも高い日本語でのコード生成能力を示しました。

[Q8-18]新聞ドメインにおける大規模言語モデルの継続事前学習と下流タスクデータ量の関係

この論文では、大規模言語モデルを特定のドメインに適応させるための継続事前学習の有無と教師ありファインチューニング（SFT）に用いるデータ量が性能に与える影響について、新聞ドメインの見出し生成タスクを対象に分析しています。

分析では新聞記事として信濃毎日新聞株式会社が自社で執筆した紙面記事の本文、見出しを用いて、Llama-3.1-Swallow8B-v0.1、新聞記事本文で継続事前学習したモデル、日本語Wikipediaで継続事前学習したモデルの3つのモデルに対して見出し生成タスクへのSFTを行い、性能を評価しました。

評価の結果、SFTの学習データ量によらず基本的に新聞記事本文で継続事前学習したモデルの性能が高いことを確認しました。特に、SFTの学習データが50件など極端に少ない場合に継続事前学習の効果が大きい可能性が示唆されました。

[D9-4] MQM-Chat:対話翻訳のための多次元品質指標

この論文では、従来の翻訳評価指標では捉えきれない、曖昧さ、流行語、対話の不整合性などの問題に対処するための、対話翻訳における特有の課題を評価するための新しい指標「MQM-Chat」が提案されています。

MQM-Chatは、誤訳、省略・追加、用語・固有名詞の誤り、不自然なスタイル、曖昧さ、流行語、対話の不整合性という7つのエラータイプで構成されており、特に最後の3つのエラータイプ（曖昧さ、流行語、対話の不整合性）が、対話翻訳に特化した新しい分類です。

提案されたMQM-Chatを用いて、5つの機械翻訳モデルによる中英・日英の対話翻訳を評価した結果、MQM-Chatは既存のMQMよりも詳細なエラー分類を提供し、標準MQMでは捉えきれなかった対話特有の問題を明確に識別できることが示されました。

社員が選ぶNLP2025イチオシ論文の紹介

本章では、NLP2025で発表された論文の中で、NLP2025に参加した7名の社員が選んだイチオシの論文を簡単に紹介します。

[Q2-4]llm-jp-judge:日本語LLM-as-a-Judge評価ツール

この論文では、LLMの応答を自動評価するLLM-as-a-Judgeという手法を、日本語LLMに対して統一的に扱うためのツール「Llm-jp-judge」の提案と、評価ツールを用いた評価とメタ評価との比較を実施しています。

興味深かったのは、人によって評価する場合と、評価ツールを用いるLLM（gpt-4o）による評価の比較において、LLMの方が評価を高くつける傾向にあることが示されているということです。にもかかわらず、相関値を比較してみると正確性を除き、すべての評価指標で高い相関を得られていることが結果で示されていました。

LLMの自動評価ツールが注目されている中、人間よりも高い評価をつけるとはいえ、高い相関性を持つことが判明したことは今後の自動評価ツールの開発において非常に良い知見であると考え、こちらの発表を取り上げました。（松岡）

[Q2-13]架空語に対するLLMの知ったかぶりの自動評価

この研究では尤もらしい架空語を生成しLLMにその意味を答えさせることで、LLMが引き起こす幻覚を分析しています。

架空語の生成では実際に存在しそうな尤もらしい架空語を生成する手法を提案しており、LLMの幻覚を誘発しやすい設定での実験を可能にしています。実験では尤もらしい架空語ほどLLMによる捏造が発生しやすいことを示しており、さらに追加実験ではRAGに近い設定で架空語に対する挙動を分析しており、たとえ架空語の意味をLLMに与えたとしても既存の知識に依存して幻覚が発生してしまう、という興味深い結果が得られています。

RAGなどの文脈において専門用語などのLLMにとって未知の単語を扱うケースは頻繁に発生し、その影響を分析することは非常に重要なタスクだと考えられるため、こちらの発表を取り上げさせていただきました。（神戸）

[P7-1]対照学習を用いたhallucination検出手法

LLMの出力に対するhallucination検出タスクにおいて、対照学習を用いて検出モデルを学習することで検出精度を向上させた研究です。

hallucinationを含む文章には入力文章と矛盾する情報などが含まれることから、入力文章とは乖離する埋め込み表現を持っていると仮定し、入力文章と正例（hallucinationのない文章）との埋め込みを近づけ、負例（hallucinationを含む文章）との埋め込みを遠ざけるようなtriplet lossと、通常の分類問題のlossを組み合わせることで検出器を学習しています。
既存のデータセットを用いた評価の結果、特にQAタスク・要約タスクにおけるhallucination検出精度が大きく向上したようです。

LLMのhallucinationは未だ課題であるなかで、埋め込み表現に着目したアプローチで大幅な精度向上を実現していることや、特に応用範囲の広いQA・要約タスクで効果が高いことから実用的にも重要な知見であると考え挙げさせていただきました。（岸波）

[Q3-25]VLMによるソフトウェア図表の理解に関する予備調査

この研究では、ソフトウェア開発におけるVLMの活用を目指し、ソフトウェア図表理解能力を評価するベンチマーク「JSWEMU」を開発しました。

このベンチマークは、図表の画像と設問で構成されており、描画スタイル、図表の種類ごとにVLMの図表理解能力を評価できます。
実験では、描画スタイルの正答率への影響は限定的で、図表の種類やモデルにより理解能力に差が生じるという興味深い結果が得られています。

VLMの得意/不得意な領域が見えてくれば、実際の開発での活用に一歩近づくのではないかと思います。ソフトウェア開発での実応用に向けて意義のある研究だと思い、この研究を挙げさせていただきました。（加藤）

[D1-5]テキストの埋め込み表現に基づくデータ増強を用いたX（旧Twitter）における日本語の皮肉検出

皮肉検出のための新しいデータ増強手法の研究です。

皮肉は感情分析誤りの原因となるため、検出が必要ですが、分類器の学習に十分な規模の日本語皮肉データの収集は困難です。そこで、少数のサンプルを基に、類似データを作るデータ増強が有効です。

従来の増強手法は、文章の意味を表す埋め込みにノイズを加えるといった方法で微妙に異なるサンプルを作りますが、皮肉文においては「君はおめでたい人だ」を「君は喜ばしい人だ」のように変えると皮肉らしさがなくなるように、繊細なニュアンスを損なう可能性があります。そこで提案手法では、皮肉らしさに影響を与えない部分を特定し、その埋め込みにノイズを加えることで、ニュアンスを保ったままデータを増強する手法を提案しました。増強後データを利用して学習したモデルは、従来手法より高精度となりました。

この研究は、レビュー分析やコミュニケーション円滑化など実社会での応用に加え、皮肉という言語現象の理解にも貢献する、意義深いものだと考え、挙げさせていただきました。（肥合）

[ワークショップ1] podnikáníゴရှウ≫的聲音毎回強いメッセージを提供するかどうか模案まれたပေမယယယ့် ตอน ไป のこと歓通だった。

言語モデルを破壊しそうなタイトルですが…最終日のワークショップで非常に盛り上がった発表です。

こちらの研究では、翻訳のタスクのおいて“どう見てもおかしいのに評価値だけがなぜか高い”評価指標ハック文を作成するため、ベクトル検索の文脈等で問題となるhubnessに着目しています。

この発表では、ある評価指標においてあらゆる入力文でスコアが高くなるような翻訳文のベクトル表現（hubベクトル）を学習 → 文埋め込みから文に復元するような「文エンコーダの逆関数」を学習し、エンコードした際にhubベクトルに近くなるような自然（？）言語文を復元するという手順を踏んでいます。

得られた文を初期解として1単語ずつ評価値をより高くできるように置換すると、タイトルのようにまったく意味をなさないにも関わらず、翻訳コンペティションの上位サブミッションにも匹敵するスコアが出てしまうのは驚きです。

ワークショップ内の別の発表で、LLMベースの翻訳評価は“この翻訳はプロの翻訳家が作成したものです”と入れるだけで過大評価するといった報告もされていましたが、このようなモデルベース評価の脆さは昨今注目されるllm-as-a-judgeに対しても警鐘を鳴らす実りある内容だと感じました。（藤井）

[P1-19] ニューラルかな漢字変換システム Zenzai

高性能かつ高速なニューラルかな漢字変換システムを考案した研究です。

通常かな漢字変換システムは統計的機械学習に基づいています。時折ニューラルネットワークを用いたモデルが提案され精度面で統計モデルを上回ることがあるものの、実行時の速度的な観点から中々実用に至りませんでした。
この問題に対して、本研究ではニューラル言語モデルの推論時に、投機的デコーディングを併用することで推論を高速化し、実用に耐えうるレベルの速度と精度を両立しました。

投機的デコーディングは本来数十B〜数百Bクラスの大規模言語モデルの推論を高速化する手法として提案されましたが、それを遥かに小さいかな漢字変換モデルに対して適用したという点が興味深く、これによりニューラルかな漢字変換モデルが実用レベルとなった点は大きな貢献だと考えています。（森下）

さいごに

NLPの学会初参加だったのですが、非常に多くの知見を得ることができました、特に研究の熱気に当てられ自分もさらに技術の探求を頑張らねばとやる気を新たにしています。

NLP2025は大学院時代の研究分野から垣根を大きく超えた先の分野ではありましたが、数多くの研究を見ることができ、とても良い刺激になりました。

現在SAIGではともに働くメンバーを募集しています。特にNLP分野における社会実装のニーズは根強く、多くの仲間を必要としているところです。キャリア採用ページではNLPシニアエンジニアをはじめ、NLPリサーチエンジニア及びNLPエンジニアも同じく絶賛募集中です。条件等応相談ですので、我こそはという読者の方は是非先のリンクよりご応募をお待ちしております。

ほかにも幅広く新卒採用およびキャリア採用を募集中です。興味のある方は是非一緒に働きましょう。よろしくお願いします！

米国時間の2025年1月15日に「Google AI の優れた機能を Google Workspace の Business プランと Enterprise プランに組み込むことを決定しました」でもアナウンスされた Gemini が、ついに当社内でも利用が始まりました。Chatbot Arena で常連の Gemini モデルが業務で使えるようになり、とても熱い展開なのでブログ化しました。

はじめに

こんにちは。tanai（棚井龍之介） です。

先日、ある企業さんのオフィスへ訪問した際に、「ウチでは、〇〇（←誰もが知っている生成AIサービス）は、全員にアカウントが支給されているよ」という話を伺い、とても羨ましいなと思っていました。私の場合、業務外で ChatGPT Plus、Felo Pro、Gemini Advanced、Mapify Pro を中心に課金して、他サービスもお試し利用しながら生成 AI ライフを送っています。

これらのツールが業務内で使えたら、どれほど効率化できるのだろうかと考えていたところ、ついに社内で Geminiの利用がスタート しました。Gemini Advanced と同様なので、「1.5 Pro with Deep Research」「2.0 Pro Experimental」「2.0 Flash Thinking Experimental」などの AI モデルが業務で使えるようになりました。各モデルの使い方はインターネット上でいくらでも見つかりますので、その利用例に追加する形で、私の利用例を説明します。

上手な AI の使い方を、AI に質問する

「上手な AI の使い方を、AI に質問する」というのが、AI を手軽に活用する方法だと思います。

例えば、「1.5 Pro with Deep Research」は、プロンプトで与えた特定のトピックに対して、インターネット上の情報を収集してレポートを生成してくれる機能です。「プロンプトを与える」ということは、Few-shotプロンプティング や Chain-of-Thoughtプロンプティング などの「プロンプトエンジニアリング」のノウハウがあると、より良いアウトプットが得られます。しかしながら、これらのテクニックを習得せずとも 「2.0 Flash Thinking Experimental」に「1.5 Pro with Deep Research へ投げるプロンプトを生成してもらう」 ことも可能です。

実践例: トレンド分析

「マイクロサービスのトレンド」を調査して欲しい場合、以下のフローとなります。

• 「2.0 Flash Thinking Experimental」に投げたプロンプト

マイクロサービスのトレンドについて「1.5 Pro with Deep Research」に調査してもらうプロンプトを作成してください。

↓

• 回答

はい、承知いたしました。「1.5 Pro with Deep Research」にマイクロサービスのトレンド調査を依頼するためのプロンプトを作成します。以下プロンプト案です。

---

**プロンプト:**

**宛先:** 1.5 Pro

**依頼事項:** マイクロサービスに関する最新トレンドの深掘り調査

**調査目的:**

マイクロサービス技術は、現代のソフトウェア開発において重要なアーキテクチャパターンとして広く採用されています。本調査の目的は、マイクロサービスに関する最新のトレンドを詳細に把握し、今後の技術選定や戦略策定に役立てるための知見を得ることです。特に、技術的な進化、アーキテクチャの変遷、運用方法の進化、ビジネスへの影響など、多角的な視点からトレンドを深く理解することを目指します。

**調査範囲と内容:**

以下のテーマに焦点を当て、マイクロサービスのトレンドを深掘り調査してください。各テーマにおいて、現状、背景、具体的な事例、将来展望を含めて分析し、詳細なレポートとしてまとめてください。

1.  **技術トレンド:**
    *   **コンテナ技術とオーケストレーション:** Kubernetes、Docker Swarm、Nomadなどの最新動向、進化、ベストプラクティス
    *   **サーバーレスマイクロサービス:**  AWS Lambda、Azure Functions、Google Cloud Functionsなどの利用状況、ユースケース、アーキテクチャパターン
    *   **サービスメッシュ:** Istio、Linkerd、Consul Connectなどの導入状況、メリット・デメリット、運用課題と解決策
    *   **APIゲートウェイ:**  最新のAPIゲートウェイ技術、進化、セキュリティ、パフォーマンス最適化
    *   **イベントドリブンアーキテクチャ (EDA):**  Kafka、RabbitMQなどのメッセージング技術を活用したマイクロサービス間連携のトレンド、設計パターン
    *   **GraphQL:**  マイクロサービスにおけるGraphQLの採用状況、REST APIとの比較、ユースケース
    *   **バックエンド・フォー・フロントエンド (BFF):**  BFFパターンの最新動向、具体的な実装例、メリット・デメリット
    *   **マイクロサービスフレームワーク・言語:**  Spring Boot、Micronaut、Quarkus、Go、Rustなど、最新のフレームワークや言語の利用トレンド、選定基準

2.  **アーキテクチャトレンド:**
    *   **モノリシックからマイクロサービスへの移行:**  移行戦略、成功事例、アンチパターン、段階的移行のアプローチ
    *   **マイクロサービスアーキテクチャの進化:**  分散トレーシング、サービスディスカバリ、サーキットブレーカーなどの実装パターンの成熟度、新たなアーキテクチャパターンの出現
    *   **マルチクラウド・ハイブリッドクラウド環境でのマイクロサービス:**  異なるクラウド環境でのマイクロサービス展開の課題とソリューション、ベストプラクティス
    *   **エッジコンピューティングとマイクロサービス:**  エッジ環境におけるマイクロサービス活用、ユースケース、アーキテクチャ設計

3.  **運用トレンド:**
    *   **DevOpsとマイクロサービス:**  CI/CDパイプラインの進化、自動化、インフラストラクチャ・アズ・コード (IaC) の活用
    *   **マイクロサービスモニタリング:**  分散トレーシング、ログ集約、メトリクス収集・分析の最新ツールと手法、可観測性 (Observability) の重要性
    *   **セキュリティ:**  マイクロサービスにおけるセキュリティ対策の進化、APIセキュリティ、認証・認可、コンテナセキュリティ
    *   **Fault Toleranceとレジリエンス:**  サーキットブレーカー、リトライ、バルクヘッドなどの実装パターン、障害回復性の向上

4.  **ビジネス・組織トレンド:**
    *   **マイクロサービス導入の目的と効果:**  ビジネス上のメリット、導入事例、ROI (投資対効果) の評価
    *   **組織構造とマイクロサービス:**  マイクロサービス導入に伴う組織文化、チーム編成、DevOps組織への変革
    *   **マイクロサービス成熟度モデル:**  導入フェーズ、成熟度段階、成熟度向上のためのステップ
    *   **マイクロサービス関連のコミュニティとエコシステム:**  主要なコミュニティ、イベント、オープンソースプロジェクト、ベンダーの動向

**調査方法:**

*   技術系ニュースサイト、技術ブログ、業界レポート、カンファレンス資料、学術論文、ベンダー資料など、信頼性の高い情報源を幅広く参照してください。
*   GitHub、Stack Overflowなどの開発者向けプラットフォームでの議論やトレンドも分析に含めてください。
*   必要に応じて、専門家へのインタビューやアンケート調査も検討してください。
*   定量的なデータ（統計情報、導入率、成長率など）と定性的なデータ（専門家の意見、事例分析など）をバランス良く収集し、分析してください。

**成果物:**

以下の内容を含む詳細な調査レポートを提出してください。

*   **エグゼクティブサマリー:**  調査全体の概要と主要なトレンドを簡潔にまとめたもの
*   **詳細レポート:**  上記の調査範囲と内容に基づいて、各テーマの詳細な分析、現状、背景、具体的な事例、将来展望を記述したもの
*   **主要トレンド一覧:**  調査結果から明らかになった主要なトレンドをリスト形式でまとめたもの
*   **提言・示唆:**  調査結果を踏まえ、今後のマイクロサービス技術の活用や戦略策定に関する提言や示唆

**その他:**

*   調査の過程で疑問点や不明点があれば、遠慮なく質問してください。
*   必要に応じて、調査の進捗状況を報告してください。
*   レポートは、技術者だけでなく、ビジネスサイドの担当者にも理解しやすいように、専門用語を適切に解説し、図表やグラフを効果的に活用してください。

**期待する成果:**

この調査を通じて、マイクロサービス技術の最新トレンドを深く理解し、技術戦略、アーキテクチャ設計、運用方法、組織変革など、多岐にわたる領域での意思決定に役立つ知見が得られることを期待しています。

---

**プロンプトのポイント:**

*   **明確な指示:** 宛先、依頼事項、調査目的、調査範囲と内容、調査方法、成果物、納期などを具体的に記述し、1.5 Proが何をすべきかを明確に指示しています。
*   **詳細な調査範囲:**  技術トレンド、アーキテクチャトレンド、運用トレンド、ビジネス・組織トレンドの4つのカテゴリに分け、さらに具体的な調査項目をリストアップすることで、調査の焦点を絞り込んでいます。
*   **深掘り調査の要求:**  各トレンドについて、現状だけでなく、背景、具体的な事例、将来展望を含めた分析を要求することで、「Deep Research」にふさわしい深さのある調査を促しています。
*   **具体的な成果物:**  エグゼクティブサマリー、詳細レポート、主要トレンド一覧、提言・示唆など、具体的な成果物の形式と内容を指定することで、期待するアウトプットを明確にしています。
*   **ビジネス視点の包含:**  ビジネス・組織トレンドの調査項目を含めることで、技術トレンドだけでなく、ビジネスへの影響や組織変革といった視点もカバーしています。
*   **表現:**  丁寧な言葉遣いを心がけ、依頼する姿勢を示しています。

このプロンプトを「1.5 Pro」に渡すことで、期待されるレベルの高いマイクロサービストレンド調査が実施されることを期待しています。

↓

• 「1.5 Pro with Deep Research」に「依頼事項 ~ 期待する成果」までを投下する

実際にどのような調査レポートが出力されるかは、読者みなさんの Gemini 環境で試してみてください！

以下2パターンの

• 自力でプロンプトを作成して、1.5 Pro with Deep Research に投げた場合のアウトプット
• 「プロンプトの作成自体を 2.0 Flash Thinking Experimental に依頼して」その結果を 1.5 Pro with Deep Research に投げた場合のアウトプット

を比較すると、後者の手法により「高度なプロンプトエンジニアリングの知識がなくても」低コストでレベルの高いプロンプトが作成できます。「プロンプト自体をAIに作らせる」ことも Tips の1つとして試してみてください。

おわりに

Gemini が社内利用可能となったので、勢いでブログを執筆しました。

生成 AI サービスは、各ツールやモデルごとに「得意領域」がありますので、それらの「強みを組み合わせる」ことで、より効率的にアウトプットが得られると感じています。また、本ブログの「上手な AI の使い方を、AI に質問する」のように、知っていれば誰でも試せる ことが多くあると思いますので、「Gemini の Note 公式アカウント」などの活用事例が参考になります。

今後は、Geminiを活用して、ストーリーラインの草案作成、メール返信文の作成、アウトプットの校正など、さまざまな業務を効率化していきたいと考えています。また、冒頭で「ウチでは、〇〇（←誰もが知っている生成AIサービス）は、全員にアカウントが支給されているよ」と記載したように、業務内で「どの言語モデルが利用できるのか？」が、今後は重要なポイントになると思いました。

読んでほしい人

• Transformerを知っていて、その理解を深めたい人
• 大規模言語モデル (LLM: Large Language Model) がどのようにして推論しているのかを知りたい人

触れている内容

• ユーザが質問をして、Transformerが回答を生成するまでの一連(end-to-end)の処理
• Transformerの仕組みについて広く浅く

触れていない内容

• 学習時に行われる処理（MaskやDropoutなど）
• Pythonなどのプログラミング言語を用いたTransformerの実装方法

最初に「構成図」で理解する

まずは元論文「Attention Is All You Need」から引用したTransformerの構成図を図1に示します。

とても簡潔ですが、図からは理解できない内容が多々あるかと思います。そのため、少しだけ具体化した構成図を図2に示します。できるだけ見やすく作りたかったのですが、どうしても複雑になる箇所があるため、拡大して見ていただければと思います。図2の補足ですが、EmbeddingやLinear、Layer Normalization、Softmaxは行方向（＝各Tokenのベクトル方向）に対して行われる処理であることに注意してください。

次に「処理フロー」で理解する

前章で示した構成図だけでは説明が不十分であるため、次は処理フローの側面から理解を深めていただこうと思います。図2と照らし合わせながら読み進めていただくと理解しやすい気がします。

※以下の処理フローの「3-1-2～4」や「6-3-2～4」で出てくるQ,K,VはそれぞれQuery,Key,Valueのことです。図3に図2の構成図内のどれがQ,K,Vなのかを示します。

1.質問を入力

2.エンコードのための前処理
　├ 1.Tokenizerで質問をTokenに変換(Tokenization)
　├ 2.変換したTokenの潜在表現を抽出(Input Embedding)
　└ 3.時系列情報を付与(Positional Encoding)

3.質問をエンコード
　├ 1.「2の結果」を用い、質問に含まれる単語間の関連度を算出(Multi-Head Attention)
　| 　├ 1.ヘッド数分、各Tokenのベクトル方向に次元を分割
　| 　├ 2.Q,K,Vの3つに複製し、それぞれ線形変換(Linear)
　| 　├ 3.「Q」と「転置したK」で行列積をとり(MatMul)、確率に変換(Softmax)
　| 　├ 4.「3-1-3の結果」と「V」で行列積をとり(MatMul)、Tokenに重みづけをする
　|　 └ 5.分割した行列を結合し、線形変換(Linear)
　├ 2.「2の結果」と「3-1の結果」の和を取り（Residual Connection）、各Tokenのベクトル方向に正規化(Layer Normalization)
　├ 3.各Tokenに対し、ベクトル間の潜在表現を抽出する(Feed Forward)
　| 　├ 1.線形変換で次元を拡張(Linear)
　| 　├ 2.非線形変換(ReLU)
　| 　└ 3.線形変換で次元を元に戻す(Linear)
　├ 4.「3-2の結果」と「3-3の結果」の和を取り（Residual Connection）、各Tokenのベクトル方向に正規化(Layer Normalization)
　└ 5.「3-1」~「3-4」の処理をN回分ループ

4.生成中の文章を入力（最初は生成の開始を表す文字(BOS: Beginning of Sequence)を入力）

5.デコードのための前処理（「2-1」~「2-3」と同じ）

6.回答をデコード（生成）
　├ 1.「5の結果」を用い、生成中の回答に含まれる単語間の関連度を算出(Multi-Head Attention)（「3-1-1」~「3-1-5」と同じ）
　├ 2.「5の結果」と「6-1の結果」の和を取り（Residual Connection）、各Tokenのベクトル方向に正規化(Layer Normalization)
　├ 3.「6-2の結果」と「3の結果」を用い、質問と生成中の回答の対応関係を算出(Multi-Head Attention)
　| 　├ 1.「3」の出力と「6-2」の出力に対し、ヘッド数分、各Tokenのベクトル方向に次元を分割
　| 　├ 2.「6-2の出力」をQとし、「3の出力」をK,Vとしてそれぞれ線形変換(Linear)
　| 　├ 3.「Q」と「転置したK」で行列積をとり(MatMul)、確率に変換(Softmax)
　| 　├ 4.「6-3-3の結果」と「V」で行列積をとり(MatMul)、Tokenに重みづけをする
　| 　└ 5.分割した行列を結合し、線形変換(Linear)
　├ 4.「6-2の結果」と「6-3の結果」の和を取り（Residual Connection）、各Tokenのベクトル方向に正規化(Layer Normalization)
　├ 5.各Tokenに対し、ベクトル間の潜在表現を抽出する(Feed Forward)（「3-3」と同じ）
　├ 6.「6-4の結果」と「6-5の結果」の和を取り（Residual Connection）、各Tokenのベクトル方向に正規化(Layer Normalization)
　├ 7.「6-1」~「6-6」の処理をN回分ループ
　├ 8.各Tokenのベクトル方向の次元を表現可能な単語数に増加させ(Linear)、確率に変換(Softmax)
　└ 9.生成中の最交尾のTokenに対し、最も確率の高いTokenを次に生成する単語とする

7.生成の終了を表す文字（EOS: End of Sequence）が生成されるか、生成Token数が上限になるまで「4」~「6」を繰り返す。

最後に「各処理の深掘り」で理解する

これまで「構成図」と「処理フロー」で見てきましたが各段階の処理を深ぼる説明がありませんでした。そのため、最後にTransformerで利用されている処理を軽く解説します。本章で触れるのは以下の処理です。

• トークナイザ(Tokenizer)
• 潜在表現(Latent Representation)
  • 埋め込み(Embedding)
  • 線形/全結合(Linear/Fully Connected)
• 位置符号化(Positional Encoding)
• 注意機構(Attention)
  • マルチヘッド注意機構(Multi-Head Attention)
  • スケール化内積注意機構(Scaled Dot-Product Attention)
    • 自己注意(Self-Attention)
    • 相互注意(Cross-Attention)
• 正規化(Normalization)
  • レイヤー正規化(LN:Layer Normalization)
• 活性化関数(Activation Function)
  • ReLU:Rectified Linear Unit
• 出力関数(Output Function)
  • Softmax

トークナイザ(Tokenizer)

Transformerは入力された文章（自然言語）のまま扱うことができません。

代わりに「Token」というものを扱います。Tokenとは文章を「Subword」に分割したものを指します。例えば日本の首都は？が入力された場合、[日本, の, 首都, は, ？]のように単語単位(Subword)に分割し、[1234, 654, 58295, 219, 179]のように 各自然言語に対応する ID に変換します。

この処理を行うものが「Tokenizer」であり、「Word Piece」や「BPE: Byte Pair Encoding」が有名です。「Learn about language model tokenization」ではGPT4やGPT4oのTokenizerのデモができます。

このサイトのTokenizerはBPEベースの「Tiktoken」というモデルを利用しています。

埋め込み(Embedding)

Tokenizerで得たTokenの潜在表現を抽出します。例えば[1234, 654, 58295, 219, 179]のようなTokenを[[1.0, 0.2, ..., 0.3], [0.4, 0.2, ..., 1.0], [0.2, 0.2, ..., 0.1], [0.5, 0.3, ..., 0.7], [0.9, 0.2, ..., 0.1]]のように、各Tokenの値をD次元に拡張します。そうすることで、類似した意味を持つTokenを同じ方向や、同じ大きさのベクトルとして表現できます。

Embeddingは事前に学習された重みを利用することもあります。

線形/全結合(Linear/Fully Connected)

学習可能なパラメータを利用して入力した潜在表現を変換します。学習可能なパラメータの数は調整でき、この調整次第で変換後の次元数を増減させることができます。

位置符号化(Positional Encoding)

Embeddingで得られた潜在表現には 時系列情報がありません。これは[日本, の, 首都, は, ？]と[の, 首都, ？, 日本, は]が同じ文章と言っているようなものです。そのため、時系列の意味合いを持つ値を各潜在表現に加算することで時系列情報を付与します。

Embeddingで得られた潜在表現に悪影響を及ぼさない大きさで、相対的な変化を持たせやすい値を加算する必要があります。元論文では以下の式で算出される値を加算しています。sinとcosの1波長は2πであるため、「pos = 2π*10000」が一意の位置情報を付与できるToken数の上限であることがわかります。

マルチヘッド注意機構(Multi-Head Attention)

次で説明する「Scaled Dot-Product Attention」をN個に分割して処理するための機構です。

Embeddingで各TokenをD次元に拡張しますが、分割がない場合、1点の尺度でToken間の関連度を求めることになります。Multi-Head Attentionを導入し、D次元をN個に分割して並列で処理させることで、N点の尺度でToken間の関連度を求めることができるようになります。

これがMulti-Head Attentionの強みです。各ヘッドの次元数は「D/ヘッド数」です。

スケール化内積注意機構(Scaled Dot-Product Attention)

トークン間の類似度を内積で求めます。はじめに、QとKで行列積をとり、Dの平方根で除算します。Dの平方根を除算している理由はQとKの行列積の値を標準化するためです。

行列積の値はDの値が大きくなるほど最大値が大きくなります。それだと学習が進まなくなるため、Dの平方根を除算して学習の安定化をしています。次に、除算した行列とVで行列積をとり、後で説明するSoftmax関数に通すことでトークン間の類似度が確率分布で求まります。

Transformerでは「自己注意(Self-Attention)」と「相互注意(Cross-Attention)」が登場します。Self-AttentionとはEncoderとDecoderで登場し、「Q」と「K」と「V」に同じ行列を与える方法です。Cross-AttentionとはDecoderでのみ登場する「Q」と「KとV」で異なる行列を与える方法です。

レイヤー正規化(LN:Layer Normalization)

各Tokenのベクトル方向に正規化行う手法です。正規化手法には他にもBatch NormalizationやInstance Normalizationなどありますが、入力長が可変のTransformerではInstance Normalizationが有効です。

ReLU:Rectified Linear Unit

非線形変換する関数です。0以下の入力を0にするだけのシンプルな関数です。ReLUの傾きは0か1なので、層を増やしても勾配を消失させにくい特性があります。（最近は活性化関数として使われることが少なくなりましたが、Sigmoid関数は傾きの範囲が0~0.25で、層が増えると勾配が0になってしまう「勾配消失問題」が発生します。）

Softmax

行列の和が1.0(100%)になるように確率分布に変換します。Transformerではvocab size分の単語が生成対象として存在しています。eで計算している理由は、出力がマイナスにならないことや微分してもeのままであること、値の強調（＝非線形な変化）が可能なことがあります。

おわりに

Transformerの仕組みを「構成図」「処理フロー」「各処理の深掘り」で解説してきました。今回は推論の処理の理解を深めることができましたが、学習時の理解はまだできておりません。今後は学習時の理解も深め、続編を出したいなと思っています。少しでも皆様のTransformerの理解を深めることへの手助けになれば幸いです。

はじめまして。Strategic AI Group (SAIG) の神戸です。

2024.09.04(水)から09.06(金)にかけて開催されたYANS2024に参加したのでその様子をご報告します。

当社はプラチナスポンサーとしてSAIGから7名のメンバーが学会に参加し、スポンサーブースでの会社紹介やポスター・チュートリアルの聴講に加え、今年度はフューチャーから1件のポスター発表も行いました。

言語処理若手シンポジウム（YANS）とは

YANSは自然言語処理、およびその関連分野の研究発表が行われるシンポジウムです。2024年で19回目の開催となる本シンポジウムは大阪の梅田スカイビルにて開催されました。

本シンポジウムではポスター発表だけでなく、分野交流ハッカソンや招待講師によるチュートリアル、参加者がスポンサーブースを回るスポンサーツアーなど様々なプログラムが開催されました。

「ことばがつむぐ、新たなつながり ～分野の境界を超えて～」という本シンポジウムのスローガンにもある通り、自然言語処理だけでなく関連する周辺分野のポスター発表やチュートリアルも行われていました。

公式の発表によれば今年度の参加人数は411人と、前年度の300人を大きく上回る参加者数となっています。発表件数も前年度に比べ56件多い196件と過去最多の発表件数となっており、現地でもその盛況ぶりを感じることができました。

スポンサーブース

スポンサーブースでは自然言語処理に関する取り組みだけでなくAIに関する取り組み全般を紹介しました。自然言語処理に関する取り組みはもちろん、それ以外のAIに関する取り組みについても興味を持って聞いて下さる参加者の方が多く、当社の取り組みについて多くの方に知っていただく機会になったと思います。

ブースに来ていただいた参加者の方にはノベルティとしてパンフレットとトートバッグを配布させていただきました。ノベルティは多めに用意していたのですが、ブースに足を運んで下さった参加者の方が想定よりも多く、シンポジウム2日目の午前中には配り終えてしまいました。改めてブースに足を運んでくださった皆様に感謝申し上げます。

スポンサー賞

当社のスポンサー賞には [S4-P25] 日本語の単語を対象とした複数時期の意味変化パターン分析 の発表を選定させていただきました。選定理由は以下の通りです。

本研究は日本語の単語の意味や使われ方が年代とともにどのように変化したのかを分析する手法を提案しています。 意味変化の仕方をクラスタリングすることで、コロナ禍で使われ方が変わった単語のグループが表出するなど興味深い結果が得られており、今後の発展に期待が持てます。 また、聴講者からの質問に対する補足資料の提示をタブレットを用いて行うなど、発表に対する十分な準備ができている点も高く評価しました。

副賞として「九州産黒毛和牛A5ランク ITADAKIセット」を送付させていただきました。

当社の発表

今年のYANSでは、フューチャーからも1件発表しました。

現在当社で自然言語処理の研究開発に関するアルバイトをお願いしているNAIST 西田さんとの共同研究成果です。

フューチャーでは基礎から応用まで幅広く研究開発を進めており、今後も様々な学会でその成果を公表していきます。

[S4-P34] 大規模言語モデルの知識は何に由来して記憶されるか？

西田 悠人 (NAIST/フューチャー), 岸波 洋介 (フューチャー), 藤井 諒 (フューチャー), 森下 睦 (フューチャー)

大規模言語モデル (LLM) は「『ハムレット』の著者は誰ですか？」のような事実に関する知識が必要な質問に答えられることがあります。これまで、LLMがどのような事実知識を記憶しているかについて研究が行われており、「訓練データ中の頻度が低い知識ほど記憶しにくい」「有名ではない知識ほど記憶しにくい」ということが知られていました。では、頻度と有名度のどちらがLLMの記憶により寄与しているのでしょうか？本研究では、記憶の強さと知識の頻度や有名度との相関を比較することで、LLMの記憶の主要因を調査しました。実験の結果、我々の直観に反して、知識のカテゴリごとにみると頻度よりも有名度と記憶の相関のほうが優勢であることが明らかになりました。このことは、ある知識が有名かどうかをLLMが暗黙的に理解している可能性を示唆しました。

第一著者コメント

今回のYANSでは、始まりたての萌芽的な研究を発表させていただきました。発表を聞きに来てくださった参加者の皆様から、さまざまな質問やコメントをいただき、今後の研究の方向性についてより明確になりました。改めて、発表に足を運んでくださった皆様に感謝申し上げます。

発表紹介

スポンサー賞の他に、当社から参加したメンバーが特に面白いと感じた発表をいくつか紹介します。

[S1-P38] 指示数増加による大規模言語モデルの指示追従性能への悪影響
この研究では、大規模言語モデルが追従できるプロンプト内の指示数について調査しています。

個々の指示は単純な場合でも、数が増えるごとに追従できなくなるという問題が大規模言語モデルには見られます。この問題に対し、指示に追従できているか各指示ごとにフィードバックを行い回答を修正する手法が提案されています。提案手法によって指示追従性が改善するという結果を示しており、プロンプト中の指示の位置によって追従性が変わるのか、指示数がさらに増えた場合でも追従性が落ちないようにするために改善することは可能かなど、今後の発展が期待される研究だと感じました。（加藤）

[S3-P08] Attentionに基づく大規模言語モデルのHallucination検出手法の検討
こちらの研究では、先行研究においてハルシネーション (幻覚) 発生時特有のAttentionパターンが存在する可能性が示唆されていることから、LLMのAttention情報を特徴量としてハルシネーション検出器を学習する手法を提案しています。

本手法によって構築される検出器は、検出予測時のAttention情報を確認することで検出対象文におけるハルシネーション発生個所が特定できるというメリットがあります。生成AIの活用が広がるなかでハルシネーションの検出は非常に重要な技術であり、検出箇所まで特定できる本手法は応用可能性が高いと考えられます。

現状の検出精度には改善の余地があるものの、特徴量の改善や外部知識の利用など今後の方向性も十分に検討されており、これからの発展が期待される研究だと感じました。(岸波)

[S1-P17] ゲームの台詞を題材としたキャラクターらしさを構成する要素の検討
この研究では、既存キャラクターを模した対話システムにおけるそのキャラクターらしさを構成する要素を評価しています。

ユーザから得られた自由記述評価を元に、対応する「らしさ」を構成する要素へとラベル付け・スコアリングを行い、その結果からキャラクター再現において優先すべき特性を考察しています。先行研究や文献からキャラクターらしさの構成要素候補が大量に挙げられていますが、そのすべてが「らしさ」を等しく述べているわけではない、性格を反映した発話であってもケースバイケースで「らしさ」への影響の大小があるという考察は、ノベルゲーム、ソーシャルゲームの一プレイヤーとして納得感がありました。

サイバーエージェントさんでは「[S2-P27] 『IDOLY PRIDE』におけるライブスコアを用いたアイドル埋め込み評価手法の検討」も発表されており、こちらはゲームのバランス調整のたたきにLLMを活用されている旨の発表がありました（こちらも面白かったです）。自然言語処理の知見がゲームの現場でこう使われているのかと興味深く感じました。(佐藤)

[S4-P21] LLMはなぜ算数が苦手なのか？ Transformerの外挿能力に関する分析
この研究では、言語モデルが与えられた例からタスクの入出力の関係性を捉え、追加の学習なしでタスクに適応する能力である In Context Learning (ICL) を、コントロールされた四則演算の設定で検証しています。

人間であれば5桁の数字どうしの計算ができれば、6桁どうしの計算にも簡単に汎化できますが、GPT-2のような言語モデルは学習時に見ていない未知の桁数どうしの足し算をほとんど解けないということを明らかにしています。

また、数字の1つ1つが独立したトークンになっていると正解率が上がるというようにトークナイズの仕方によってタスク遂行能力に大きな差が生まれる、未知の桁数の問題では例の中の同じ桁数の問題にアテンションが張られている = なんらか違うことまでは理解できていそう、などとても興味深く示唆に富んだ良い研究だと感じました。

ポスターで述べられていた四則演算以外の問題への展開はもちろん、より表現力の高い大きなモデルではどうなのか？突然 “腑落ち” して四則演算のルールを学ぶことがあるのか？など、様々な方向性から今後の展開に期待できます。(藤井)

[S4-P14] SubRegWeigh: サブワード正則化による高速アノテーション補正
こちらの研究ではデータセット中のアノテーションミスを特定しその悪影響を軽減する “アノテーション補正”に関する新しい手法を提案しています。

従来の手法ではアノテーションミスを検出するために複数のモデルを使用して検出しなければならなかったため多くの時間を必要としていたところ、こちらの研究では複数のモデルを使用する代わりに複数のサブワード系列、つまり複数のテキストの区切り方のパターンで1つのモデルに学習をさせることでアノテーションミスの検出を高速に行えるようになっています。複数のモデルによる推論を、単一モデルによる複数のサブワード系列に対する推論に置き換えるアイデアが非常に面白いと感じました。実験では従来手法に比べ高速なアノテーション補正ができるようになったことだけでなく後段タスクの精度改善も確認されており、今後のさらなる展望が期待される発表だと感じました。(神戸)

「目指せ国際会議！」セッション

国際会議経験者を招き、国際会議に関するライトニングトーク (LT) およびパネルディスカッションを行うセッションが行われました。

今回ご招待を頂き当社から森下が「国際会議でやるべきこと3選」というタイトルでLTを行いました。

1回目の国際会議では（あまり）会議のレベルを気にせず、まずはどこでも良いので投稿し発表する経験を積むことの大切さをお伝えさせていただきました。

全発表者の資料は以下に掲載されています。

https://yans.anlp.jp/entry/yans2024report#%E7%9B%AE%E6%8C%87%E3%81%9B%E5%9B%BD%E9%9A%9B%E4%BC%9A%E8%AD%B0

おわりに

私自身が約1年半ぶりの自然言語処理系の学会への参加だったため、LLMが台頭し始めて以降の自然言語処理の動向はほとんど把握できておりませんでした。今回のシンポジウムでLLMに関する研究の雰囲気を掴むことができましたし、LLM以外の研究も依然活発に行われていることを知ることができ、良い刺激を得られました。

Futureでは一緒に働くメンバーを募集しています。特に最近ではNLPに関する採用にも力を入れており、NLPエンジニア、NLPリサーチエンジニア、シニアNLPエンジニアの募集も行っております。条件等は応相談ですので、興味を持っていただけた方は是非採用ページの内容をご確認ください。

他にも新卒採用やキャリア採用を幅広く行っておりますので、多くの方からのご応募をお待ちしております。

みなさまと一緒に働ける日を心待ちにしております！

フューチャーアーキテクト物流サービス事業部の引網康暁です。現在、お客様の物流DXのご支援や、物流関連法改正に伴うCLO（Chief Logistics Officer：物流統括管理者)ご支援のコンサルティングを行っています。

物流DXの実践のためには、サプライチェーン上のデータの「可視化」やAIも活用した「最適化」が不可欠と考えており、コンサルタントとして自らの知識を高めておく必要があります。その一環として、2024年8月に行われたE資格2024#2を受験して合格しましたので、その体験記を綴ってみたいと思います！

E資格とは

E資格とは、日本ディープラーニング協会（JDLA）が認定するAI人材に関する資格のうち、エンジニアを対象とした資格で、ディープラーニングの理論を理解し、適切な手法を選択して実装する能力や知識を認定する資格となっています。

試験範囲（シラバス）は、機械学習のベースとなる数学から、機械学習・深層学習のモデルや手法、モデルを実装するための環境構築に至るまで、とても幅広い内容が問われます。さらに、理論のみならず、PyTorchまたはTensorFlowを利用した実装も含まれますので、Pythonの基礎的なコーディングスキルも求められます。

1. 数学的基礎（確率・統計、情報理論）
2. 機械学習（機械学習の基礎）
3. 深層学習の基礎（順伝播型ネットワーク、深層モデルのための最適化、深層モデルのための正則化、畳み込みニューラルネットワーク、リカレントニューラルネットワーク、Transformer、汎化性能向上のためのテクニック）
4. 深層学習の応用（画像認識、物体検出、セマンティックセグメンテーション、自然言語処理、生成モデル、深層強化学習、様々な学習方法、深層学習の説明性）
5. 開発・運用環境（エッジコンピューティング、分散処理、アクセラレータ、環境構築）

E資格受験の「資格」を取得する必要があります

E資格受験のハードルが高い理由の1つでもあるのですが、E資格を受験するにあたっては、事前にJDLAの認定プログラムを過去2年以内に履修し、修了試験に合格しておく必要があります。つまり、E資格受験のための「資格」を事前に取得しなければなりません。私はコストパフォーマンスの良さげな認定プログラムを選択し（G検定合格者割引が受けられました）、2024年3月から受講を開始しました（すなわち、受験勉強期間は6か月でした）。

プログラムによって内容は異なるようですが、私が選択した認定プログラムは、オンラインでの動画講義（約25時間）を受講した上で、テスト（約400問）のクリアとコーディング課題（4問）の提出が修了の要件でした。

まず、オンラインでの動画講義ですが、いわゆる予備校みたいな感じの「ココが試験に出ますよ！」とか「ココは暗記しましょう！」のようなノリを勝手に期待していたのですが、全く違いました（自分の勘違い）。。。講義は試験範囲の基礎的な知識を一通り、均して説明するという内容でしたので、私の場合、単に講義を受講するだけでは、E資格本番の合格は難しかったと思います。なお、テストとコーディング課題は、ネットを漁ったり、ChatGPTも駆使したりして、なんとか6月に認定プログラムを修了できました。正直なところ、この認定プログラムの修了だけでも「やりきった感」が出てしまったほどです。

受験勉強本番

さて、認定プログラムを修了し、E資格の受験資格を得て、ようやくスタート地点に立てました。ここからが受験勉強の本番となります。私は、以下の4つをバイブルとして勉強を進めました。

• ゼロから作るDeep Learning
  「赤本」と呼ばれる、受験生必須の参考書です。この本は、フレームワークを一切使わずにディープラーニング（特に画像認識）をゼロから実装する！という、言わずと知れた名著です。私の場合、この本を精読しながら、そして、ただ単に読み込むだけでなく、コーディング（写経）して実際に手を動かしながら、2回転しました。
• ゼロから作るDeep Learning2（自然言語処理編）
  こちらも同じく「赤本」と呼ばれる参考書で、word2vec、RNN、LTSMから、ChatGPTを生み出したTransformerの基盤技術であるAttentionまでが本当に分かりやすく解説されています。私はこの本の精読を2回転しました（写経はしていない）
• ディープラーニングE資格エンジニア問題集
  こちらは「黒本」と呼ばれる問題集で、私が勉強していた時期では唯一の問題集でした（E資格は過去問が公表されていません）。この「黒本」も受験生必須アイテムの1つで、「やらない」という選択肢はありません。私の場合、それこそ過学習を覚悟に7回転しました。実装問題はコードを写経したり、計算問題は式を自分で展開したりすることで、ようやく血肉になりました。何より手を動かすことが重要でした。

• JDLA公式例題
  上記の「黒本」は発刊された時期がちょっと古いところが難点で、最新の試験範囲（シラバス）に対応できていない箇所があります（シラバスはしばしば更改されます）。そこで、認定プログラムを修了したタイミングで修了者に共有されたJDLA公式例題を何度か解き、問題演習の足りない箇所を補いました。

受験日当日から合格発表まで

受験にあたって、試験問題に関する守秘義務について誓約をしましたので、今回のブログでも、当日の試験問題については一切触れることができないこと、ご了承ください。試験はCBT（Computer Based Test）方式で、120分間で多肢選択式の約100問を解きます。見直し時間を考えると、1問をだいたい1分間で解いていかないといけないので、かなり時間にシビアな試験です。また、テストセンターの入場にあたっては、参考書や問題集は一切持ち込めませんし、ズボンのポケットの中身やメガネの裏までチェックされたセキュリティ面もとても印象的でした。

当日の自分の感触としては、「できた！」という問題が5割くらい、「ちんぷんかんぷん」という問題が2割くらい、「多分こっちだと思うけど。。」という問題が3割くらいで、あまり手応えが無かったというのが実感です。その分、3週間後に無事に合格のメールを受け取ったときは本当にうれしかったです！ 結果的に、各分野ともに7～8割くらいが正答だったようで一安心しましたが、問題数の多くを占める深層学習の出来が合否を決める試験であるように思いました。

おわりに

私の場合、E資格受験を考え始めて、実際に「黒本」を目にした時の感想は「とっても難しい。。（絶句）」というものでした。それでも、認定プログラムを修了し、問題集や参考書を手を動かしながら解き進めることで、なんとか合格できました。この合格体験記がE資格取得に関心のある方に参考になれば幸いです。

お読みいただいてありがとうございました。

みなさんはじめまして。フューチャー株式会社の佐良と申します。

普段はStrategic AI Group (SAIG)の一員として、主にAI-OCRサービス事業を中心に携わっています。

この度は、2024年8月6日(火)〜8月9日(金)において熊本城ホールにて開催されました第27回 画像の認識・理解シンポジウム(MIRU2024)に参加してきたので、その様子を報告します。

当社はシルバースポンサーとして、SAIGから7名が参加しました。
学会期間中は発表の聴講に加えて、スポンサーブースを出展し、学会に参加している学生や他企業の方々と交流しました。

画像の認識・理解シンポジウムとは

画像の認識・理解シンポジウム（MIRU）は、画像の認識と理解技術に関する国内最大規模の会議です。今回の開催で27回目となり、ポスター発表件数も629件と過去最多となっていました。

個人的な感想としては、口頭発表が1つの会場のみで実施されていたため、興味のある発表の時間が被って聞き逃すといったことがなく非常に助かりました。

スポンサーブース

スポンサーブースでは、画像処理に関わる案件にとどまらず、SAIGで取り組んできた様々なAI案件を中心に実績を紹介しました。

ブースにお越しいただいた方々には、当社がITコンサルティング会社であるという強みを活かして、画像処理だけでなく幅広い分野での実績があることに興味を示してくださる方が多かったです。

発表聴講

参加メンバーのそれぞれが聴講した発表の中で印象に残ったものについていくつか紹介します。

[OS-1E-09] Human-drawable and Interpretable Adversarial Attack

この研究では、人間が解釈可能な敵対的攻撃を得るために、人間が落書きとして再現しても誤分類を発生させるような敵対的攻撃の生成手法を提案しています。

従来の敵対的攻撃に関する研究では敵対的攻撃の解釈性よりも、どれだけ誤認識を引き起こせるか・どれだけ知覚しづらい攻撃かに主眼を置いており、結果として画像分類器が何故誤分類したかの理由について洞察を得ることが難しいという課題がありました。
本研究では、”敵対的落書き”と命名された人間がフリーハンドで再現可能な攻撃手法を提案しています。”敵対的落書き”はベジェ曲線の集合であり、入力画像にベジェ曲線の集合を重ねたものをモデルの入力とし、モデルが入力画像をターゲットクラスに誤分類するようにクロスエントロピー損失をとり、これを元にベジェ曲線のパラメータを最適化しています。本研究内の実験では、敵対的攻撃を成功させるために最適化されたベジェ曲線の集合を人間が真似して同じクラスの別画像に落書きをしたところ、モデルが同様の誤認識をすることを確認しました。

ユニークなアプローチで解釈性のある敵対的攻撃を実現したところが非常に興味深かったです。落書きもシンプルなもののみで構成されているため、敵対的攻撃が成功したものを人間が洞察し特徴を把握することを可能としていました。人間が再現して同じ誤りを引き起こすことに成功していることから、モデルの解析にも応用可能な技術と感じました。(勝村)

[IS-2-051]:Symmetry breaking in parallelized MLP-Mixer

多層パーセプトロンのみを用いて、Attentionと同等の精度を出したMLP-Mixerの重みの対称性の破れと精度の関係についての研究です。
Hopfield-NetworkはCNNなどにみられるfeed-fowardなモデルではなく、実際の脳を模した神経学的なモデルです。
古典的なHopfield-Networkは解析的な解をもち、重み(相互作用)は単純な計算で求まります。これに対し、モダンなHopfield-Networkを3層重ねたものは解析的でない、非自明な解をもちます。この研究では、非自明かつ最もシンプルなネットワークとして、このモデルに着目しています。

通常、パーセプトロン間のエネルギー関数(コスト関数)の相互作用は、対称性をもちます。それに対し、今回のモデルには対称性を壊すようなパラメータを導入し、対称性の破れ具合と精度の関係性を調べています。

その結果、対称性の破れていないモデルでは精度があまり出ないことが分かりました。

つまり、今回のParallelized　MLP-Mixierの精度において対称性の破れが寄与しているという考察が得られます。これは、実際の脳のニューロンの相互作用が、対称性を持たないことに対してもコンシステントな結果であり、非常に面白いです。(発表者から聞いたのですが、ちゃんとしたソースは見つからず・・・)(市村)

[IS-2-150]:非言語依存なフォントスタイル変換へ向けて

未学習のフォントスタイルを用いて、未学習フォントを変換する手法を提案した研究です。学習済のフォントスタイルで未学習・学習済のフォントを変換する手法は、過去に研究されていましたが、変換元・変換先両方で未学習の手法は提案されていませんでした。

この研究では、フォントのスタイルの特徴を抽出するモデルと、フォントの生成部分をわけ、スタイル抽出分を工夫したことに新規性があります。

まず、第一段階としてスタイル抽出器にフォントが同じか異なるかを判定するモデルを結合し、事前学習します。その後、フォントの言語依存性を無くすために、後続に言語を判定するモデルを結合させ、学習を進めます。この時に言語情報が学習されるため、逆勾配を特徴抽出器にかけ、言語とは関係ないスタイルの本質を学習します。

この手法を用いることで、未学習スタイルで未学習フォントを変換することに成功しています。実際に画像を構成する要素として、いくつか軸が考えられますが、本質的に学習したい軸とそれ以外を分けて学習をするときに広く使える手法と考えられます。シンプルな構成ながらも発想が素晴らしい研究です。(市村)

[OS-1B-05] SimGlue: スケールや回転変化の大きい画像ペアに対するTransformerを用いた特徴点マッチング

特徴点マッチングによる画像内のパターン抽出において、特徴点の特徴ベクトルを座標系を正規化したうえで求めることで、スケールや回転角の大きく異なるようなケースにおいても高精度な特徴点マッチングを可能とする手法を提案する研究でした。

従来の Transformer 系の位置エンコーディングは特徴点の位置座標に基づいており、スケールや回転角が大きく異なるとマッチすべきふたつの特徴点に対応する特徴ベクトルに全く異なる位置関係がエンコーディングされてしまい、マッチングに失敗するという問題点がありました。

そこでこの研究では、特徴点集合の座標の情報のみから回転中心、回転角、スケールを求め、それらを用いて正規化してから位置エンコーディングを行うことで上記の問題を回避していました。オブジェクトが画像のどこにどの向きで置かれているか、といったような問題はそこまで突飛でもないように思うので、これに対する古典的な手法としてどのようなものがあるのか、およびこの研究の手法がそのような問題にどの程度強いのか、などは気になりましたが、シンプルでありながらかなり妥当な手法に感じました。画像内から完全一致でなくとも似ているパターンを抽出する、といったような問題は様々なところで頻出かつバリエーションも豊富なので、方針や手法など参考になる部分の多い研究と感じました。(久保田)

[IS-1-079] 馬術における動作認識手法の比較と評価

本研究では、馬術競技における動作認識の課題を明らかにし、既存の人間動作認識手法を馬術に適用する試みを行いました。

馬術競技では運動の正確性が採点に重要であり、コンピュータによる動作認識が有用ですが、既存の手法は人間を対象としており、馬を主体とする馬術には適用が難しいです。

本研究では、馬術のデータセットを作成し、RGB画像、オプティカルフロー画像、関節位置ヒートマップの3つのモダリティを用いて動作認識の性能を評価しました。その結果、RGB画像とオプティカルフロー画像は同程度の精度を示したが、関節位置ヒートマップはやや精度が劣ることが判明しました。また、馬が正面または後ろを向いている場合や四肢部分にノイズがある場合に認識が失敗しやすいことが分かりました。今後は、これらの課題を解決することで、実用的なモデルの構築が期待されています。

馬術という新しい領域において人間の動作認識に用いられている既存のモデルを用い評価した興味深い研究であると感じました。正面から見た際に四肢が重なって見えるなど、人間とは異なる馬ならではの課題を明確にできたこと、独自でデータセットを作成したことも高く評価できる部分だと思います。(長山)

[IS-2-038] 演奏音復元のための手書き邦楽譜文字認識

独自文字や記号が使用される手書き邦楽譜における文字認識の精度向上を目指し、物体検出技術を応用して文字を認識する研究です。
対象のデータは、数字・漢数字・記号といった異なる属性の文字を含んでいることから，手法としては多ラベル分類モデルと物体検出モデル（YOLOv8）を用いた二段階の文字認識を提案しています。

YOLOv8の単体手法と比較しても、本研究で提案している二段階での文字認識が数値的にも上回る結果となっています。まずは種類を大別することにより、各文字の種類のデータの偏りが減ったことが考えられ、後にそれらに特化したモデルで判別することへの恩恵があったと感じました。

全体的なスループットにどう影響するか等は気になりますが、複雑で難しいタスクにおいて、異なる属性で大別してからより特化したもので読みに行くという手法は有用だと感じました。(鈴木)

[IS-2-111] Erasing Scene Text with Foundation Models

風景画像に映り込んだ文字領域を特定し、その領域を修正することで、文字を自然に削除する研究です。タスクとしては大きく2つに分かれており、（1）文字領域の特定、（2）特定箇所の修正によって構成されています。文字領域の特定においては、文字を囲う bounding boxの特定後、segmentationモデルを利用し、より正確な文字のストロークに沿ったマスクを取得することで、より忠実に背景領域の情報を保持します。修正フェーズでは、拡散モデルベースの手法を複数比較しています。

実験結果のうち興味深かったのが、この修正フェーズでのモデルごとの挙動の違いでした。単純に文字領域を消去し、代わりに背景と同色系に置換するモデルもあれば、その領域が文字領域であることを理解し、別の文字(っぽい形)を生成するモデルも存在しています。

文字に限らず、コンテキスト情報をコントロールした画像生成・変換手法の扱いを考える良い例になる研究であると感じました。(菅野)

[IS-1-182] Cross-Lingual Learning in Multilingual Scene Text Recognition

この研究では、STR（Scene Text Recognition）における、CLL（Cross-Lingual Learning）について、CLLの一般的な洞察がSTRのタスクにも適用されるかを広域的な実験を通じて調査しています。

一般的に、CLLでは(1)高リソース言語と低リソース言語を共同学習することで、低リソース言語の性能が低下する可能性がある、(2)共同学習は類型論的に類似した言語間で最も効果的に機能する可能性がある、という2つの洞察が存在します。しかしながら、本研究では複数の言語を用いたCLLを広域的に実験することで、これらの一般的な洞察がSTRには適用されないことが示されていました。

また実験を通じて、言語間の形状的類似性についてもSTRのCLLでは重要ではなく、真に重要であるのは言語の種類ではなく学習に用いる高リソース言語のデータ量であることが示されています。

直観的には言語の文字の形状が似ていることが学習にはポジティブに働きそうに感じていましたが、本研究ではそうではないと示されており非常に興味深かったです。また、言語情報を取り入れることができるようなマルチモーダルなモデルだとどのような結果になるのかも気になりました。(佐良)

おわりに

本記事では、MIRU2024の参加記録を執筆させていただきました。

私自身が学生時代は自然言語処理の研究に携わっていたこともあり、画像処理系の学会に参加するのは今回が初めてだったのですが、興味が引かれる研究がたくさんあり、非常に楽しい学会期間を過ごすことが出来ました！

発表の中では、近年のLLMの発展の影響もあり、画像処理+言語処理のマルチモーダルな研究も多く見られた印象があります。LLMとのシナジーで画像処理分野の研究がどのような方向に発展をしていくのか非常に楽しみです。

SAIGでは技術と業務の両輪でAIの実社会応用を推進していく仲間を募集しています。
興味のある方、ぜひ一緒に働きましょう！

新卒採用 : https://www.future.co.jp/recruit/recruit/rec-fresh/
キャリア採用 : https://www.future.co.jp/recruit/recruit/rec-career/

熊本グルメも堪能しました。↓写真は馬肉

Slack のカスタム絵文字を AI で遊びました。

前書き

夏の自由研究連載 2023 の「Sentence-Transformers を使って YouTube 動画のセリフを検索する」では、テキストのセマンティック検索や文字資料に対して Q＆A に注目してデモしました。しかし Sentence-Transformers は、テキストだけではなく、画像や音声など異なる情報の組み合わせ、いわゆる マルチモーダル(multi-modal) AI のモデルです。

そのため、同一のモデルで、文字と画像を意味的な関連性を利用して、同一のベクトル空間に埋め込み(Embedding)することで、数学の計算（ベクトルの cosine 距離など）で近似度の評価が実現できます。

テキストと画像を検索のインプットとアウトプットの組み合わせで、以下の応用場面を例として挙げられます。

今回は、前回割愛した画像に関するセマンティック検索について実践します。入力として Slack のカスタム絵文字を扱います。

仕事上でもよく使われる Slack では、ユーザが小さな画像もしくは画像化した文字をカスタム絵文字として自由にアップロードできます。ドアが開けっぱなしに思えますが、現在我々使っている Slack ワークスペースに、5000 個以上のカスタム絵文字が存在し、また日々増え続けており、重複や類似の絵文字がたくさん存在します。

また、アップロード時に絵文字の名称を指定する必要がありますが、一意であれば良いので少し雑な命名も多いです。名前での検索しても、使いたい絵文字はなかなか見つからないこともしばしばです。

例えば、↓ 最初のaから始まる絵文字を紹介します。具体例を見れば雰囲気がわかると思います。

Name	Icon
applied
approve_done
ara
arara
arch_alert_mentioin
arch_todo
ari
ari_1
ari_あり
ari2
arigataya
arigatogozaimasu
arigatou
ariyori
aroha
aruaru
arunomi
asaka_朝霞
asakai
aserazudeok
ashita
ashita_hennshinshimasu
ashitore
asu
asu_onegai_shimasu
at_mark
atchannel_yamero
atesaki_saisettei_alert_mentioin
atode
atodekakuninsimasu
atsui
attention

それになんとかしたい気持ちで、絵文字の重複検知、便利に使いたい絵文字を意味で検索できるために、セマンティック検索の AI 技術を応用してみました。

データの準備

まずは、ローカルでデータを扱うように、Slack カスタム絵文字をクローリングでダウンロードします。

絵文字を表示するときブラウザから投げだした API を fetch 句で拾って、以下になります。
（クレデンシャル情報やヘッダーなどを xxxx に書き換えています）。

fetch("https://edgeapi.slack.com/cache/xxxx/emojis/list?fp=ba&_x_num_retries=0", {
  "headers": {
    "content-type": "text/plain;charset=UTF-8",
    ...
    },
  "referrerPolicy": "no-referrer",
  "body": "{\"token\":\"xxxx\",\"count\":100,\"marker\":\"compliance_warning_コンプラ\",\"enterprise_token\":\"xxxx\"}",
  "method": "POST",
  "mode": "cors",
  "credentials": "include"
});

レスポンスがページネーションされて、100 件ずつ取っていることが分かりました。

その挙動をシミュレートする Python のスクリプトを作って、全量の絵文字名と URL を yaml ファイルに保存します。

from requests import Session
import yaml


list_emojis_url = (
    "https://edgeapi.slack.com/cache/xxxx/emojis/list?fp=ba&_x_num_retries=0"
) # ブラウザ上コピーした実のfetch句のURLに合わせる
cookie_string = '<ログイン処理が面倒なので、ブラウザのクッキー情報を引っ張ってくる>'
token = "xxxx" # こちらもブラウザの情報を引っ張る
s = Session()
for cookie in cookie_string.split("; "):
    name, value = cookie.split("=", 1)
    s.cookies.set(name, value)

marker = "_doing" # 1個目の絵文字名称
while True:
    json_data = {
        "token": token,
        "enterprise_token": token,
        "count": 100,
        "marker": marker,
    }

    response = s.post(url=list_emojis_url, json=json_data).json()

    with open("results.yaml", "a") as f:
        yaml.dump(response["results"], f)
    marker = response.get("next_marker")
    if marker is None:
        break

保存した yaml ファイルは以下のような形になります。
（うちの場合、5000+要素、約 770 KB）

- name: _doing
  updated: 1642723962
  value: https://emoji.slack-edge.com/T01310927L1/_doing/15ac6e3e64ce0764.png
- name: -sherlock-holmes-costume
  updated: 1720678172
  value: https://emoji.slack-edge.com/T01310927L1/-sherlock-holmes-costume/0d46d4d059e8f066.png
- ...

yaml に記載してあった value を URL として、name を保存先のファイル（拡張子は URL を尊重する）として、ローカルにダウンロードします。

import os

import requests
import yaml


def read_yaml_result(filename):
    with open(filename) as input_data:
        return yaml.safe_load(input_data)


def download_image(file_path, url):
    try:
        response = requests.get(url)
        response.raise_for_status()
        with open(file_path, "wb") as file:
            file.write(response.content)
        print(f"Downloaded {file_path}")
    except requests.exceptions.RequestException as e:
        print(f"Failed to download {name}: {e}")


if __name__ == "__main__":
    input_file_name = "results.yaml"

    output_directory = "images"
    os.makedirs(output_directory, exist_ok=True)

    skip = True

    for item in read_yaml_result(input_file_name):
        name = item["name"]
        url = item["value"]
        if skip and name == "simple_smile":
            skip = False
        if skip:
            continue
        _, ext = os.path.splitext(url)
        file_path = os.path.join(output_directory, f"{name}{ext}")
        download_image(file_path, url)

ファイルを正しくダウンロードできたことが確認できました。

画像データのベクトル化

Sentence-Transformers のこのページをベースとして参考して、画像をベクトルに Embedding しておきます。

※ ファイル数が多すぎますので、デモ用で 1000 ファイルのみ処理します。

import os

from PIL import Image
from sentence_transformers import SentenceTransformer

# Set the path to your images directory
images_dir = "images"

# Set a maximum number of images to process
max_images = 1000

# Load the model
model = SentenceTransformer("clip-ViT-B-32")

# Get the list of image file paths
image_files = [os.path.join(images_dir, file) for file in os.listdir(images_dir)][
    :max_images
]


# Load images and compute embeddings
images = []
image_labels = []
for image_file in image_files:
    images.append(Image.open(image_file))
    base, ext = os.path.splitext(os.path.basename(image_file))
    image_labels.append(base)

img_emb = model.encode(images)

print(img_emb)
print(img_emb.shape)

実行結果です。

$ python3 visualize.py
[[ 0.3558431  -0.4127885  -0.38162816 ...  0.8868538  -0.24081565
   0.11687451]
 [ 0.35159412 -0.22937642 -0.28752807 ...  0.7736969  -0.5258111
   0.40994892]
 [ 0.23833637 -0.2584821  -0.3712055  ...  0.89749026  0.03570646
  -0.2068485 ]
 ...
 [ 0.17339917 -0.16685665  0.13446489 ...  0.87421316 -0.18107425
   0.39892197]
 [ 0.17150897  0.18003528 -0.40643013 ...  0.9075323  -0.35873666
   0.00515198]
 [-0.26825747 -0.1587921   0.04072791 ...  0.9843429  -0.40589246
   0.00923938]]
(1000, 512)

“clip-ViT-B-32”モデルで、1000 個の画像データをそれぞれ 512 次元のベクトルに変換できました。

そのベクトルを使って、画像間の距離計算、分類、検索など、色々なことができます。

その多次元のベクトルを主要要素を抽出して 2 次元に圧縮して、画面上に描画する方法を ChatGPT 先生に教えてもらいました。

たくさんオプションが教えられていますが、1 個目の TSNE でも良いでしょう。

早速描画してみましょう。

import matplotlib.pyplot as plt
from sklearn.manifold import TSNE

# Apply t-SNE to reduce dimensions to 2D
# Choosing a perplexity value appropriate for the dataset size
perplexity_value = min(30, len(img_emb) - 1)
# perplexity_value = 50
tsne = TSNE(n_components=2, perplexity=perplexity_value, random_state=0)
reduced_embeddings = tsne.fit_transform(img_emb)

num_clusters = 5  # Specify the number of clusters
kmeans = KMeans(n_clusters=num_clusters, random_state=0)
cluster_labels = kmeans.fit_predict(reduced_embeddings)


# Plot the reduced embeddings
plt.figure(figsize=(15, 9))
plt.scatter(reduced_embeddings[:, 0], reduced_embeddings[:, 1], alpha=0.5)

# Optional: Annotate points with image labels
for i, label in enumerate(image_labels):
    plt.text(
        reduced_embeddings[i, 0],
        reduced_embeddings[i, 1],
        label,
        fontsize=8,
        alpha=0.6,
        fontname="YuMincho", # 日本語ファイル名を化けないようにフォントの設定
    )

plt.title("t-SNE Visualization of Image Embeddings")
plt.xlabel("t-SNE Dimension 1")
plt.ylabel("t-SNE Dimension 2")
plt.grid(True)
plt.show()

うんん、なるほどの感じですね。多すぎてみにくいですね。
ある程度集団化（クラスタ）になっている傾向が見えます。

空間的分類クラスタ

plotly を利用して、3D でも描画しようと思います。
今回は、クラスタを明らかにするため、K-means を使って、適当に 7 色でクラスタに塗りましょう。

from sklearn.cluster import KMeans
import plotly.express as px


num_clusters = 7  # Specify the number of clusters
kmeans = KMeans(n_clusters=num_clusters, random_state=0)
cluster_labels = kmeans.fit_predict(reduced_embeddings)


fig = px.scatter_3d(
    x=reduced_embeddings[:, 0],
    y=reduced_embeddings[:, 1],
    z=reduced_embeddings[:, 2],
    color=cluster_labels,  # Color points by cluster
    text=image_labels,  # Labels for each point
    labels={"x": "Component 1", "y": "Component 2", "z": "Component 3"},  # Axis labels
    title="3D t-SNE Visualization of Image Embeddings with Clusters",
    color_continuous_scale=px.colors.qualitative.G10,  # A color scale for discrete colors
)

さっきのポケモンシリーズのクラスタを左になるように回転しておきました。

結果はブラウザ上で閲覧しています。ズームや回転の操作はこんな感じです。

ファイル名の表示を隠して、細かく 20 分類(num_clusters = 20)にしてみたら、こんな感じです。

画像で画像を検索

近似画像を検索する手法は、データと同じくクエリ用の画像の特徴ベクトルを計算(Embedding)し、既存データのベクトルの類似度(今回のモデルは cosine 距離)を計算し、類似度高い順で結果を取得するという流れです。

query_emb = model.encode(Image.open("images/白旗.png"))
# query_emb = model.encode(Image.open("images/天才.png"))

# Compute cosine similarity between the query embedding and each image embedding
similarities = model.similarity(query_emb, img_emb).reshape((-1,))

# Get the indices of the most similar images
k = 5  # Number of nearest neighbors you want to find
top_k_indices = reversed(np.argsort(similarities)[-k:])

# Retrieve the top k similarities and corresponding images
top_k_similarities = similarities[top_k_indices]

# Print the results
for i, (index, score) in enumerate(zip(top_k_indices, top_k_similarities)):
    print(
        f"Rank {i + 1}: Image Name: {image_files[index]}, Similarity Score {score:.4f}"
    )

結果例 1

クエリ画像:
images/白旗.png

ヒットした Top5 の画像:

Rank 1: Image Name: images/pose_seiza_man.png, Similarity Score 0.8798
Rank 2: Image Name: images/mushiba.png, Similarity Score 0.8741
Rank 3: Image Name: images/ganka.png, Similarity Score 0.8697
Rank 4: Image Name: images/リーゼント.png, Similarity Score 0.8454
Rank 5: Image Name: images/しゃちく.png, Similarity Score 0.8415

今回のクエリ画像は、全体の 5000+の画像から選択した 1000 件に含まれていないため、Top1 がクエリ画像自身をヒットしていないです。

上位の 3 個のヒットは同一キャラクタのことが分かりますね。
4 番目のヤンキー少年と 5 番目のしゃちくさんは混入していますね。
真面目の青い服の青年の B サイド のことでしょう。ww

結果例 2

クエリ画像:
images/天才.png

ヒットした Top5 の画像:

Rank 1: Image Name: images/さすが.png, Similarity Score 0.9758
Rank 2: Image Name: images/tomi.png, Similarity Score 0.9647
Rank 3: Image Name: images/katatore.png, Similarity Score 0.9639
Rank 4: Image Name: images/肉.png, Similarity Score 0.9570
Rank 5: Image Name: images/作業中.png, Similarity Score 0.9537

近似度みんな高い(0.95 以上)です。画像の中の文字の意味が理解していない様子です。

印鑑系丸くて赤い文字が特徴でしょう。ただ、最後の「作業中」は丸くもないですけど。

肩トレの「レ」や「肉」文字の外側、ちょっと丸くなっている感が見えているのでしょう。

文字で画像を検索

上記画像から画像の検索と似たように、同じモデルで、文字列も同様な Embedding 処理ができます。
ちょっと微修正したら、文字で画像を検索することが実現可能です（マルチモーダルのスゴさ）

ちなみに、日本語でも検索できるようにしたい場合は、多言語対応の“clip-ViT-B-32-multilingual-v1”モデルを使ったほうがいいそうです。

ただ、画像の Embedding は“clip-ViT-B-32”のままを使用するのが正しいです。

model2 = SentenceTransformer("clip-ViT-B-32-multilingual-v1")

query_emb = model2.encode("ポケモンボール")
# query_emb = model2.encode("上は赤、下は白、球体")
# query_emb = model2.encode("ビーチボール")
# query_emb = model2.encode("ビール")

# Compute cosine similarity between the query embedding and each image embedding
similarities = model.similarity(query_emb, img_emb).reshape((-1,))

ただ、文字が画像の中身を抽象的な名称では、あまりヒットしなく、画像の形状や色、物体の表現のほうがヒットしやすいです。

例えば、以下具体の結果例:

クエリ文字: "ポケモンボール"
Rank 1: Image Name: images/おっとっと.png, Similarity Score 0.2725
Rank 2: Image Name: images/images.png, Similarity Score 0.2725
Rank 3: Image Name: images/anpn_アンパンチ.png, Similarity Score 0.2682
Rank 4: Image Name: images/piyo_mushin.png, Similarity Score 0.2675
Rank 5: Image Name: images/piyo-mushin.png, Similarity Score 0.2675

以下の色や形状の表現ならヒットします（ただ、近似度 0.26 は高くないです）。

クエリ文字: "上は赤、下は白、球体"
Rank 1: Image Name: images/monster_ball.png, Similarity Score 0.2619
Rank 2: Image Name: images/ポンパ君_スクロール.gif, Similarity Score 0.2521
Rank 3: Image Name: images/redmine.png, Similarity Score 0.2512
Rank 4: Image Name: images/alert.gif, Similarity Score 0.2495
Rank 5: Image Name: images/spiderman2.jpg, Similarity Score 0.2492

ただし、下記の特定な名称では、またヒットします。
おそらく、当時の訓練用のデータに依存していることでしょう。

クエリ文字: "ビーチボール"
Rank 1: Image Name: images/monster_ball.png, Similarity Score 0.2570
Rank 2: Image Name: images/おっとっと.png, Similarity Score 0.2544
Rank 3: Image Name: images/images.png, Similarity Score 0.2544
Rank 4: Image Name: images/panda_マスク.png, Similarity Score 0.2543
Rank 5: Image Name: images/piyo_mushin.png, Similarity Score 0.2541

最後に、みんなが大好きな「ビール」でテストしてみましょう。

クエリ文字: "ビール"
Rank 1: Image Name: images/alphabet-white-b.png, Similarity Score 0.2633
Rank 2: Image Name: images/nomuzo.png, Similarity Score 0.2517
Rank 3: Image Name: images/アカン.png, Similarity Score 0.2511
Rank 4: Image Name: images/ega.png, Similarity Score 0.2438
Rank 5: Image Name: images/やっつけ.jpg, Similarity Score 0.2433

また笑い話になりますが、トップでヒットしたのは「ビー」の部分でした！
2 番目はひよこちゃんがビール持っているし、「あ缶」はまあまあ缶ビールに関連しているでしょう。
4 番目は芸能人の手のジェスチャーが間違えてビールを持っているように間違えたかなと思います。最後のやっつけは？ 言われてみれば、その背景がビールのと泡の色や状態にちょっと似ているかもしれません。

また、今回のデモでは、1 個のクエリベクトルに対して、全データ(1000 個)のベクトルとの近似度(Cosine Similarity)が計算して、ソートをかけてしまいました。もし事前にインデックスを立てたり、近似な結果も許されたりする場合、k-近傍法(k-NN)のもっと効率的なアルゴリズムもあります（割愛）

まとめ

2023年の記事の続きとして、事前訓練された(pre-trained)マルチモーダル(multi-modal)の AI モデルを使った画像処理を実践してみました。

Slack のカスタム絵文字のデータを利用して、関連性によってクラスタ化して、可視化グラフを書いてみました。
人間の好みが関与したデータとして、ベクトル空間上で、均一にランダムの分散するではなく、集団化（クラスタ化）で分布していることが直感的に分かりました。

また、セマンティック検索について、検証の結果は指標化までできていませんが、直感的に、

• 「画像 → 画像」の検索は、なんとなく精度が悪くなく
• 「文字 → 画像」の検索はすぐには実用化とはちょっと微妙

そして、近似データや重複データの検知や排除する手法として、他の領域へも応用できそうだと思います。