こんにちは、VポイントマーケティングAIエンジニアの三浦諒一です。エージェントハーネスを使っていると、いろいろなAgent Skillsを読み込ませて作業を行うことがたくさんあります。その中には開発向けのものだけでなく、ドキュメントを書いたりデザインを作るようなSkillsもあるかと思います。組織の中でどんどん増えていくSkillsの管理は結構難しい問題です。どこか一か所に集約し、検証の上承認が下りたSkillsを特定のユーザーに公開する、そういった仕組みもこれから求められていくと思います。DatabricksのUnity GatewayではAIだけでなく、MCPやSkillsを管理することが可能です。learn.microsoft.comUnity Gatewayを通じてSkillsを登録すると、Unity Catalog配下に管理されます。他のテーブルと同様にユーザーやグループに使用権限を付与することが可能になります。登録したSkillsはUnity Gatewayを通じてローカル環境で利用することが出来ます。今回はローカル環境で作成したSkillsをUnity Gatewayを通じてDatabricksのUnity Catalog配下に登録し、ローカル環境の別のプロジェクトから登録したSkillsを取得し、利用するまでの流れを実際に試してみたのでまとめてみたいと思います。※なおUnity Gateway Skillsは現在ベータ版となっているため、この記事で紹介した内容は今後変更される可能性が高い点をご承知ください。Unity Gateway Toolをインストールする以下のドキュメントの手順に従って進めていきます。最初にUnity Gatewayを操作するためにUnity Gateway Toolをインストールします。learn.microsoft.com作業を進めるためにはDatabricks CLIがv1.0.0より新しいバージョンになっている必要があるため、もしそれよりも古いバージョンの場合は、以下のように一度削除して再度インストールして最新の状態にしておきます。sudo rm '/usr/local/bin/databricks'curl -fsSL https://raw.githubusercontent.com/databricks/setup

こんにちは、VポイントマーケティングAIエンジニアの三浦 諒一です。最近Claude CodeやCodexに代表されるようなエージェントハーネスについて興味があって色々と調べていました。その中で読んだ論文で特に印象に残ったのが「Don't Blame the Large Language Model: How Agent Harness Evolution Shapes Coding Agent Quality」というタイトルのもので、エージェントのコーディングタスクの品質をLLMではなく複数のエージェントハーネスや、同一エージェントハーネスの異なるバージョン間で比較を行なっている内容でした。arxiv.org同じエージェントハーネス(Qwen Code)なのにそのバージョンによって品質やパフォーマンスが異なる品質は変わらないのにパフォーマンスが変異している点が検証されていて、これからはLLMだけでなくどのハーネスを使うのかとか異なるハーネスを組み合わせてみる、といったアプローチが必要になりそうだな、と考えさせられる内容でした。※論文の内容について、一部訂正させていただきました。(2026/09/09)以前このブログでも取り上げさせていただいたDatabricksのOmnigentは複数のハーネスに対し共通のインターフェースを提供したり、タスクを分担させるオーケストレーションなどを行う、ハーネスの1つ上のレイヤーとして機能します。techblog.vpoint.co.jpOmnigentには複数のハーネスをオーケストレーションする「Polly」と「Debby」という2つのエージェントが実装されています。「Debby」はClaude CodeとCodexを呼び出して、お互いに意見を出させ、議論させることができるエージェントです。omnigent.ai一方「Polly」はコーディングエージェントで、タスクをサブタスクに分解し、複数のコーディングエージェントに分担して作業を行います。特にレビューの際には異なるモデルベンダーのエージェントに任せるといった動作もします。omnigent.ai私のプライベートな環境ではCodexとAntigravityが利用できるため、今回はDatabricksのOmnigentのWeb UIを使ってPollyからCodexとAntigravi

こんにちは、VポイントマーケティングAIエンジニアの三浦 諒一です。最近SnowflakeのCortex Agentの開発に取り組んでいます。様々な構造化テーブルを参照して回答することが出来るAgentの開発を目指しているのですが、Agentが構造化データを参照する際に使用する「Query structured data」Toolの仕様について少し気になった点があったので調べてみようと思いました。さらに仕様を理解することでAgentのパフォーマンスの改善にもつなげることが出来たので、この記事でご紹介したいと思います。現在のQuery structured data Toolの仕様Cortex AgentのQuery structured data Toolの設定はSnowsightからだとAgentの「Configuration」-「Tools」を開いて「+ Add semantic view」をクリックすると行うことが出来ます。Query structured dataの設定気になったのはこのToolの挙動です。SnowflakeではSemantic viewを元に、自然言語でSQLを生成できる「Cortex Analyst」というサービスがあるのですが、Query structured data Toolの中でSQL生成を「Cortex Analystが行う」のか、「Agent自身が行う」のか、どっちなんだろう、と疑問に感じました。実際「+ Add semantic view」をクリックすると「Add tool: Cortex Analyst」という画面が表示されるので、Cortex Analystを呼び出すToolのようにも思えます。Query structured data Toolの設定画面この仕様についてSnowflakeのドキュメントを探ってみたところ、今年の4月に公開された「Apr 13, 2026: Improved SQL generation in Cortex Agents」というドキュメントに答えが書かれていました。docs.snowflake.comドキュメントによると、以前はSQL生成をCortex Analystに委譲する動作だったようですが、現在はSemantic viewの情報をもとにAgentがSQLを生成する動作に変わったよう

こんにちは、VポイントマーケティングAIエンジニアの三浦諒一です。この前の私のブログの記事でCopilot Studioで開発したエージェントの会話ログをApplication InsightsとEvent Hubsを通じてDatabricksに収集する仕組みについてご紹介しました。techblog.vpoint.co.jp会話のログは収集するだけでなく、どれだけエージェントがユーザーの質問に対して正しくかつ安全な内容で答えることが出来ているのかを継続的に評価し、問題があればどこで問題が発生したのかを追えるようにしておくことが重要です。Databricksに会話のログが格納されているのであれば、それを実現する手段としてMLflowを使うことが出来ます。現在MLflowは機械学習ワークフローを対象とした機能群とLLMやエージェントを対象にした機能群に大きく分けることが出来、今回対象となるのはLLMとエージェントをサポートする機能群です。その中にはLLMによるエージェントの回答結果の品質を評価(Evaluate)する機能があり、これを使用することで回答結果の品質をチェックするだけでなく、チェックした結果を画面上で確認できるようになります。たとえば以下のように、回答の丁寧さ(politeness), 質問との関連性(relevance), 危険な内容やセンシティブな情報が含まれていないか(safety)といった軸で評価をして可視化をすることが可能です。エージェントの回答をMLflowで評価今回の記事ではDatabricksにCopilot Studioのデータを格納した後にMLflowで評価を実施するところまでまとめてみました。全体像の振り返りと今回のスコープ全体像は以下のようになっています。ログの収集から評価までのフロー全体図前回はこの中のうちLakeflow Declarative PipelinesでSilverレイヤのデータを作るところまで行いました。今回は引き続きLakeflow Declarative Pipelinesを使ってユーザーの入力とエージェントの回答で構成されるGoldレイヤーのテーブルの作成を行います。その後にNotebookを用いてGoldレイヤーに格納されたユーザーとエージェントのやり取りのデータを取得し、MLflowの機能でDatabric

こんにちは、VポイントマーケティングAIエンジニアの三浦諒一です。MicrosoftのCopilot Studioを使うとTeamsやCopilot Chatで利用できるカスタムエージェントを簡単に開発し、公開することができます。普段からMicrosoft 365で作業をしているとそこで生成されたナレッジを参照したエージェントを作ることが可能です。このようなプラットフォームで誰もが高機能なエージェントを作ることが出来るようになってきている中で、最近必要性を感じているのは「どのエージェントがどのように使われて、それによってどれだけの効果を生み出すことが出来ているのか」を把握し、それによって得られた知見を活かしたり、あるいは改善を行っていくことです。これを実現するためにはユーザーがエージェントを利用したログを「分析機能が整った場所」に集約する必要があります。「分析機能が整った場所」としてDatabricksを選択した場合にCopilot Studioのエージェントからどのようにデータを収集するのかについて実現方法を調べ、実際に動作検証をしてみました。構成Copilot Studioのエージェントからログを収集し、Databricksのテーブルに格納するまでの構成を以下の図のように組んでみました。Copilot Studioで作成したエージェントのログをDatabricksに格納する構成Application InsightsはAzure Monitorに含まれるアプリケーション監視サービスです。エージェントと接続してログを収集します。Azure Event Hubsはリアルタイムデータ配信サービスで、収集したログの配信を行います。Event HubsはApache Kafkaプロトコルに対応しており、DatabricksはKafkaをストリーミングデータソースとして指定できるため、Event Hubsから配信されたデータを取り込むことが可能です。そのままだと分析がしづらいため、DatabricksのLakeflow Declarative Pipelinesでブロンズからシルバー層へのデータ加工処理を実行します。設定手順エージェントとApplication Insightsの接続まずCopilot StudioのエージェントとApplication Insightsの接

こんにちは、VポイントマーケティングAIエンジニアの三浦 諒一です。私はあまりこれまでデータベースの設計には関わることはなかったのですが、未加工の状態のデータが存在するブロンズレイヤーと、アプリやBIツールが参照するゴールドレイヤーの間に位置するシルバーレイヤーの設計の重要性は日々の業務の中でも感じることがたくさんあります。例えば数値情報の取り扱いが異なるテーブル間で統一されていなかったり、カラム名が異なるテーブル間でブレがあったりすると、それだけでもゴールドレイヤーの構築に悪影響を与えてしまいます。最近ソフトウェアの開発にコーディングエージェントを使うことが増えてきましたが、変数名の付け方などは人がやるよりもエージェントに任せた方が統一感が出ていいかも、と考えることがありました。もしかしたらシルバーレイヤーの構築もエージェントにサポートしてもらうことでより統一されたものになるのかもしれません。そんな中見つけたのがDatabricksが発表した「Vibe Data Modeling」というエージェントです。www.databricks.comこのエージェントは自然言語で表現したビジネス情報をもとに、それをデータで表現するためのデータモデル(データベースの設計書)を作成してくれる機能を持っています。Notebookが公開されていて、それを使って実際にデータモデルを作成し、さらにテーブルやMetrics Viewの構築、サンプルデータの作成まで行うことが可能になっています。今回はVibe Data Modelingエージェントと生成されるデータモデルについて調べてみましたNotebookの場所Vibe Data Modelingエージェントを利用できるNotebookは以下のリポジトリから取得することができます。github.commodel-agent/agentに格納されているdbx_vibe_modelling_agent.ipynbというNotebookが該当するNotebookで、Databricksで開いて実行することでエージェントを動作させることが可能になっています。とりあえず動かして様子を見てみるまずは動かして何が起こるのか見てみようと思い、Notebookをダウンロードしてきて実行を試してみました。実行の手順は、Databricks Serverles

こんにちは、VポイントマーケティングAIエンジニアの三浦諒一です。私は最近MicrosoftのCopilot Studioでどんなエージェントが出来るのかいろいろと調査をしています。Copilot Studioはローコードでエージェントを開発できるプラットフォームで、様々なツールや外部エージェントと連携、ナレッジを参照したカスタムエージェントを作ることが出来ます。さらにTeamsやWebアプリなどのチャネルに公開することが可能です。Copilot Studioで作成したエージェントをTeamsで呼び出す普段からMicrosoft環境で作業をしているのであれば、Copilot Studioでかなり柔軟にエージェントが開発できると思います。さて、このCopilot StudioでExcelで作成された表形式のデータを分析するエージェントを作れないかな、と考えていました。それもできるだけ労力をかけずに、です。今回はこれを実現するためにMicrosoft Fabricの自然言語でデータ分析ができる「Fabricデータエージェント」をCopilot Studioのカスタムエージェントから呼び出してみる、といったことを試してみました。※一部の環境ではCopilot StudioのUIが以下のようになっています。今回の検証はこの新しいUIではなく、「New experience」をオフにして表示されるUIで行っています。右上の「New experience」をオフにしたUIで検証しています。設定チームや組織でSharePointにExcelファイルを格納し、表形式でデータを管理している、といったケースは結構あるのではと思います。そこでSharePointに格納したExcelファイルをFabricのLakehouseに取り込んでそれを分析できるFabricデータエージェントを構築、そのデータエージェントをCopilot Studioのカスタムエージェントから外部エージェントとして呼び出す、という構成をとりました。今回使用するデータは「UCI ML Wine Data Set」というワインの成分で構成されたデータセットです。Pythonの機械学習ライブラリ「scikit-learn」にもサンプルデータとして搭載されているもので、そちらを少し加工して使用しました。SharePointの

こんにちは、VポイントマーケティングAIエンジニアの三浦です。最近私はAIエージェントを作ることに加えてAIエージェントにどのようにデータを提供するのか、といったテーマについて考えることが増えてきました。そのためにはおそらく2つの戦略があるように感じています。一つはデータそのものをAIエージェント向けに加工する、といったアプローチです。これはローデータをエージェントのコンテキストに入れられるよう解釈したり要約してテキストデータに変換するイメージです。もう一つはデータはそのままにして、そのデータをどう解釈しどう分析するのかといった指示書を用意するアプローチです。この2つはどちらか片方を選択するのではなく、両方が必要だと考えています。2つ目のアプローチにおいて、データの説明や集計方法等「データの扱い方」を定義するのがセマンティックレイヤーで、Snowflakeでは「Semantic View」で実装することが出来ます。以前は「Semantic Model」を使っていたのですが、現在はSemantic Viewを使うことが推奨されています。docs.snowflake.comSemantic Modelはステージに格納したYAMLファイルでしたが、Semantic Viewはスキーマオブジェクトとして特定のスキーマ配下で管理出来、アクセス権などの細かい権限設定が可能です。また、「派生メトリクス」といった機能もサポートされているとのことです。実は今社内でこのSemantic Viewを使って対応しようとしているプロジェクトがあり、推奨される設定方法などを調査していました。その中でこちらのSnowflakeの公式ガイドが内容が意外なノウハウが含まれていて面白かったです。www.snowflake.com今回の記事ではこのガイドの内容をベースにSnowflakeのSemantic Viewを作る際に留意する点をまとめてみたいと思います。Semantic View設計の原則Semantic Viewを作るときに原則となる考えです。エンジニアやデータベースの観点で作る・・・のではなく、エンドユーザー視点で考えることが重要です。具体的にはSemantic Viewを記述するときにはテーブル名を使うのではなく業務用語を使ったり、自分がビジネスユーザーにデータを説明するんだったらどうやっ

こんにちは、VポイントマーケティングAIエンジニアの三浦諒一です。関東も梅雨明けしたようです。梅雨が明けた途端、ものすごく暑くなりました。体調管理に気を付けないとですね。今回はSnowflakeの話を書きたいと思います。Snowflake CoWork最近Snowflakeの「Snowflake CoWork」という機能を触っています。Snowflake CoWorkは以前は「Snowflake Intelligence」という名称でしたが今年のSummitで名称変更されたそうです。Snowflake CoWorkではSnowflakeで作成したエージェントを呼び出して会話形式で作業を行うことが出来ます。入力としてファイルを渡すこともできますし、会話の途中で生成されたグラフや表などを「アーティファクト」として保存してメンバーとシェアすることが可能です。Snowflake CoWorkたとえばHugging Faceで公開されている以下のSpotifyの楽曲データセットを取り込んで作成した楽曲おすすめエージェントを作ってみました。huggingface.coCoWorkを使えばすぐにこのエージェントを呼び出して使用することが出来ます。これまでフロントは自分で作ってAPIでエージェントを呼び出す、といったことをしていましたが、その必要もなくすぐに使えるのが便利です。CoWorkからエージェントを呼び出して楽曲リストを表示会話の中でおすすめ楽曲リストがテーブル形式で表示されたのですが、これを「保存」しておくと、アーティファクトに登録され、いつでも確認し、共有することが出来るようになります。テーブルをアーティファクトに格納CoWorkで呼び出すエージェントは、「Cortex Agents」で作ることが出来ます。Cortex Agentsでエージェントを作るCortex Agentsでは、構造化・非構造化データのいずれも対象として分析をし、回答するエージェントを作成することが出来ます。Cortex Agentsでエージェントを作る際のベストプラクティスがこちらのドキュメントで説明されています。www.snowflake.comこのドキュメントの中でエージェントの精度や効率性に特に関わると考えられるのが「Importance of Cortex Agent instructio

こんにちは、VポイントマーケティングAIエンジニアの三浦諒一です。この前外に出たら蝉の鳴き声が聞こえてきました。気温も高くなってきたし、そろそろ夏がやってきたようです。今年はAIエージェントの年！と言いたくなるほど毎日AIエージェントのことについて考えている気がします。色々なAIエージェントを使ったり作ったりしているのですが、それらの利用状況をどこか一箇所にまとめたいな、と思っていてその環境としてDatabricksを検討しています。以前はコーディングエージェントのログをDatabricksに記録する、といったことを試していて、その内容はこちらの記事にまとめています。techblog.vpoint.co.jp今回はノーコード・ローコードAIエージェント開発プラットフォームDifyで開発したAIエージェントのログをDatabricksに記録する、といったことにチャレンジしてみました。さらにログを格納した後、Databricksの機能を使って品質チェックをしたり、コーディングエージェントGenie Codeを使って利用状況を可視化するダッシュボードも作ってみました。Databricks側の事前準備Difyのログを取り込むためにDatabricks側の事前準備が必要です。まずDifyのワークフローに対してMLflowのExperimentsを作成します。Databricksのワークスペースを開き、AI/ML関連メニューの「Experiments」を選択、「GenAI apps & agents」を開き新しいExperimentを作成します。Experimentの作成画面で「GenAI apps & agents」を選ぶ作成後、Experimentを開きます。そのページのURLの「experiments/」の次に続く数字列があとで使う「実験ID」になるので控えておきます。また、DifyのワークフローからDatabricksに接続する際に使うパーソナルアクセストークンも発行しておきます。OAuth認証が推奨されていますが、今回は検証のため、スピードを優先した対応を取りました。トークンに付与する権限スコープは「mlflow」だけでOKです。Difyで作ったワークフローのログをDatabricksに送信する設定Difyで作成したワークフローをDatabricks MLflowのE

こんにちは、VポイントマーケティングAIエンジニアの三浦 諒一です。もう7月なのですが、今のところ東京は雨の日が多く、梅雨らしい天候が続いています。こんなに梅雨らしい梅雨は、なんだか久しぶりな気がしています。今年のDatabricksの年次のイベント「DATA＋AI SUMMIT」のキーノートの動画が公開されていたので見てみました。AIエージェントを本格的に利用するために必要なデータや基盤に関するアップデートが多く、とても興味深かったのですが、その中で「試してみたい！」と真っ先に思ったのが「Omnigent」です。OmnigentとはOmnigentはDatabricksが開発したAIエージェントの「メタハーネス」で、オープンソースで公開されています。メタハーネスって初めて聞いたのですが、実際に使ってみて感じたのは「Claude Code」や「Codex」といった様々なコーディングエージェント(Omnigentでは「ハーネス」と呼んでいます)の上に存在するレイヤのようなもので、それぞれのコーディングエージェントが持つ機能を共通のインターフェースでアクセスできるようにするようなイメージだと感じました。Omnigentにはさらにチームメンバーとコラボレーションできる機能も備わっていて、コーディングエージェントとのセッションにアクセスできるWebUIを起動したり、セッションをチームメンバーにシェアして共同作業するといったことが出来るようです。Omnigentはオープンソースですが、DatabricksではフルマネージドなOmnigentがベータ版で提供されています。Databricks上でWebUIをホスティングしたり、基盤モデルとしてUnity AI Gatewayのエンドポイントを利用することが可能です。今回はDatabricksのOmnigentの導入から使ってみるところまで試してみた内容をまとめたいと思います。環境私は最初勘違いしていたのですが、Omnigentはコーディングエージェントと同じローカル環境で動作します。「クラウドサンドボックス」というサーバー側で動かす機能もあるようですが、主な用途はローカル環境に存在するコーディングエージェントへの共通インターフェースを提供することです。私は普段Databricks Appsの開発環境としてAzure VMを使って

こんにちは、VポイントマーケティングAIエンジニアの三浦諒一です。AIエージェントが人に代わって商品を選択して購入まで済ませてくれる「エージェンティックコマース」について興味があって調べています。特に気になっているのが「AIエージェントがどういう基準で商品を選ぶんだろう？」というテーマです。人が自分で商品を選ぶ場合は自分が欲しいと思ったり興味を持ったものや、その中でさらに価格が安かったり評価が高かったりするものを選ぶと思います。でももしAIエージェントが自分の代わりに商品を選ぶようになったら、同じような基準で判断するのでしょうか？このテーマについて扱ったとても興味深い論文を最近読みました。今回は、その中でも特に私が面白いと感じた検証内容をご紹介します。参照論文Title: Authors: Submitted On: arXiv URL: https://arxiv.org/abs/2508.02630論文の概要ユーザーがAIエージェントに商品購入を任せると、どんな市場を形成するのかに焦点を当てた研究です。今のECサイトは人が利用することを想定した作りになっています。商品を売る側は、ECサイトを運営するプラットフォームのスポンサーとなることで人の目に留まりやすい場所に自社の商品を表示してもらったり、「おすすめ」のようなバッチやタグを付与することがありますが、これらはAIエージェントが商品を探すようになったら今と同じ販促効果を示すことができるのでしょうか？また、AIエージェントのバックエンドで動くモデル(LLM)の学習プロセスを鑑みると、同じカテゴリー内の商品でもブランドの露出度によって選択の偏りが発生する可能性も考えられます。露出が高く、インターネット上に多数のデータが存在するブランドが優先され、ニッチなブランドが選択されなくなる。人が買い手であれば競争力があったブランドなのにAIエージェントが市場に参入すると全く選択されなくなってしまう可能性も考えられます。モデルも単一ではありません。OpenAI、Anthropic、Googleなどのプロバイダが提供する異なるモデルをバックエンドに持つAIエージェントは、それぞれ果たして同じような商品選択傾向を見せるのでしょうか？また、同じプロバイダのモデルでもバージョンが変わるとその傾向は変わるのかもしれません。もし変わるとす

こんにちは、VポイントマーケティングAIエンジニアの三浦 諒一です。だんだん暑くなってきました。最近夏の日差しが本当に強いので、今年はちゃんと外出するときは日焼け止めをつけるように習慣づけようと思っています。さて、普段いろいろなAIエージェントを使っていますがふと「このエージェントが自分のことをもっとよく知ってくれたら、もっといいアウトプットを出してくれるんじゃないか」と考えました。私たちも仕事で何か資料を作る時、自分が伝えたいことだけでなく伝える相手のことを意識して作ることは多いと思います。それと同じでAIエージェントも私たち依頼者のことを知った方がより良い成果物を作ってくれるのでは・・・と思いました。そこで「自分はこんな人だよ」を説明する特徴文(ペルソナ文)を作り、同じタスクを指示する際にそのペルソナ文を与えた場合とそうでない場合で成果物にどんな違いが生まれるのかを試してみようと思いました。今回使用したエージェントはOpenAIのCodex CLIで、モデルはgpt-5.5 lowを使用しました。設定タスク今回は「資料作成」にフォーカスしたタスクを10個選んでみました。以下の10個です。私におすすめの小説を探して、その良さを伝えるHTMLファイルを作成して。私におすすめの日本の音楽を探して、その良さを伝えるHTMLファイルを作成して。SnowflakeとDatabricksの違いを説明するためのHTMLファイルを作成して。各種コーディングエージェントの特徴とそれぞれの良い点悪い点をまとめたHTMLファイルを作成して。今年のDatabricksのサミットDATA+AI SUMMIT2026でリリースされた内容をまとめたHTMLファイルを作成して。私におすすめの日本酒を探してその良さを伝えるHTMLファイルを作成して。私が今年始めるといい習慣はなんでしょうか？HTMLファイルに提案内容をまとめてください。海外の人と英語で会話できるための私にとっての最短ルートを提案してほしい。提案内容はHTMLファイルにまとめて。2026年以降のAIはどのようになると考えられますか？HTMLファイルにまとめてください。私にとっておすすめの今晩の夕飯の献立を考えて、レシピも含めてHTMLファイルにまとめて。カルチャーからテクノロジー、今晩の献立まで色々とピックアップしてみました。ペルソ

はじめにテクノロジー戦略本部セキュリティ部部長の松井と申します。当社では今期、新たにセキュリティ部を設置し、私が本部長と兼務する形でその業務を担うことになりました。クラウドへの移行が進む当社にとって、セキュリティの強化はもはや単なる施策ではなく、事業継続を支える経営課題そのものだと考えています。一方で、この領域を主導できる専門人材を確保することは、非常に難しく、その解決策を検討してまいりました。本記事では、我々がこの構造的な課題をどう整理し、なぜクラウドセキュリティ基盤として「Wiz」への投資を意思決定したのか、その判断の道筋を共有させていただきます。同じ論点に向き合う方の一助になれば幸いです。クラウドシフトに伴うセキュリティリスクの拡大ここ数年、当社のシステムは着実にクラウドへ移行してきました。クラウドがもたらすスピードと柔軟性は、事業の競争力に直結しています。しかし同時に、守るべき領域は静かに、そして確実に広がり続けます。一つの設定、一つの権限が、意図せず外部への入口になり得る。これは個別の過失というより、クラウドという仕組みが構造的に内包する性質です。つまり、セキュリティの強化は「やったほうがよい取り組み」ではなく、クラウド活用を前進させる以上は避けて通れない要請でした。セキュリティ部の設置は、その要請に対して組織としての必然的な対応でした。ただ、部を置くことと、運用を継続的に機能させることはまったく別物です。これを確実に機能する部門とするための取り組みが必要です。構造的な課題 ― 「人」に依存する運用の限界立ち上げに際してまず直面したのは、単なる人手不足では片付かない、構造的な課題でした。クラウドセキュリティを統括できる専門人材は、採用市場に極めて乏しい仮に採用できても、市場の需給から定着・維持のハードルは高い結果として運用が特定個人に依存し、「見る・判断する・改善する」というサイクルそのものが回らない各種調査でも、必要な人材を確保できないと回答する企業が大半を占めます。これは当社固有の問題ではなく、業界全体が同じ制約の中にある、という認識です。加えて、各クラウドが備える標準的なセキュリティ機能だけでは、マルチクラウドを横断したリスクの関連性分析や、攻撃経路の可視化までは踏み込めません。守りの巧拙を一人の専門人材の練度に委ね続けることは、属人化という別のリス

こんにちは、VポイントマーケティングAIエンジニアの三浦諒一です。最近CodexやClaude、Github Copilotなどのコーディングエージェントを使っていると、本当にたくさんのツールを呼び出してタスクを解こうとしている様子が伺えます。そのおかげで複雑なタスクをコーディングエージェントに任せることができるのですが、一方でこのターンでいったい何をしたのかが振り返りにくくなってきているな、と感じるようにもなりました。もしかしたら自分が把握していないところで外部と通信をしていたり、意図していないファイルを変更してるかもしれません。さらに、もしコーディングエージェントを大勢で利用していくことを考えるとコーディングエージェントが「何を実行したのか」を振り返ることができないと色々と困る点も出てきてしまいます。そんな課題を解決するアイデアとして、DatabricksのMLflowを利用する方法を今回試してみました。コーディングエージェントとしてCodex CLIを使ったのですが、この方法によってCodex CLIでコーディングエージェントとやりとりした内容やツールの実行履歴などを自動的に記録することが出来るようになります。この検証では学習用途で無料で使用できるDatabricks Free Editionを利用しました。本番運用の環境ではありませんが、ちょっと試してみたい、という用途であれば最適な環境だと思います。www.databricks.comセットアップセットアップは以下を見ながら進めました。mlflow.orgまた、今回はDatabricksでホストされているMLflow Serverを使用します。Databricks CLIを使うとトークンを書かずに認証することが出来るので、事前に入れておきました。docs.databricks.comまず、MLflow用のCodex CLI統合パッケージをインストールします。npm install -g @mlflow/codexCodex CLIで開発を行うプロジェクトフォルダ内で以下を実行すると、MLflowトレーシングの設定が開始されます。mlflow-codex setupいくつか対話形式で設定を進めます。MLflowトレーシングの設定の対象範囲はデフォルトの"Project"で進めました。? Where shoul

こんにちは、VポイントマーケティングAIエンジニアの三浦 諒一です。2026年度 人工知能学会全国大会がはじまりましたね！私も初日に会場であるGメッセ群馬に行ってきました。現地ならではの体験をしたかったので、主にポスターセッションを中心に見て回りました。面白そうな内容がたくさんあり、これからじっくり論文を読んでみたいと思っています。また、私たちも共同研究論文の発表という形で今回の人工知能学会全国大会に関わることが出来ました。ぜひこちらの記事もご覧ください。techblog.vpoint.co.jpさて、先日リリースされたAnthropic社のモデルClaude Opus4.8のベンチマークの結果を見ていたのですが、そもそもこれらのベンチマークってどんな内容なんだろう？と疑問を持ちました。www.anthropic.com「SWE-Bench Pro」, 「Terminal-Bench 2.1」, 「Humanity's Last Exam」, 「OSWorld-Verified」, 「GDPval-AA」, 「Finance Agent v2」というベンチマークの結果が載っていますが、この中でコード生成の性能を測るのに使われているのが「SWE-Bench Pro」で、Opus4.8は69.2%という結果が出ています。今回はこのSWE-Bench Proを理解するために、そもそもエージェントのコーディング性能ってどうやって測定するのかを含め、調べたことをまとめていきます。正しいコードが作れたことをどう評価する？そもそもエージェントが生成したコードが正しいかどうかをどうやって評価するのでしょうか。2021年にOpenAIが出した論文「Evaluating Large Language Models Trained on Code」にはそのためのアプローチが述べられています。arxiv.orgこの論文では「HumanEval」という、Pythonの関数をDocStringから生成することができるかを測定するベンチマークについて述べられています。コードの評価は一般的なテキストの評価とは異なる観点が必要です。たとえば一般的なテキストの評価であれば、正解のテキストと生成されたテキストがどれだけ似ているかとか、一致している部分がどれだけあるのかといった観点で測定出来ますが、コード

松尾研究所との共同研究論文について、プレスリリースが掲載されました。詳しくはこちらをご覧ください。www.vpoint.co.jp

はじめにこんにちは、VポイントマーケティングAIエンジニアの三浦諒一です。5月19日から20日に米国で開催されたGoogleのイベント「Google I/O 2026」の基調講演の様子がYouTubeに公開されており、その内容がとても面白くて未来を感じる内容だったので、今回はどんなことが発表されたのか、それを見てどんな風に感じたのかをまとめてみたいと思います。今回はYouTubeで公開されている「Google I/O 2026」の基調講演の動画「Google I/O '26 Keynote」を参照して記事を書いています。www.youtube.comオープニングで紹介された内容Ask Maps/Ask YouTubeGoogle Mapsで場所を調べたりYouTubeで動画を検索する際に会話形式で検索ができるようになります。例えばAsk YouTubeでは「バランスバイクの乗り方を知ってる3歳の子供に自転車の乗り方を教えるにはどうしたらいい？」といった質問を与えると関連した動画を探してくれるだけでなく、役に立つTipsも生成されていました。さらに動画の中の特に関連が強いシーンにすぐにジャンプできるようになっていました。Docs Live音声入力でGoogle Docsを作ることが出来るサービスです。かなり大雑把な音声入力でもAIがいい感じにまとめてくれるみたいで、「この内容を含めて」「あ、やっぱりこれも入れて」のように頭に浮かんだアイデアをそのままポンポンと投げ込みながら資料作成ができるようなイメージでした。また、Google DriveなどのGoogleの他のサービスの情報も参照してくれるそうです。AI ProとUltraユーザー向けにこの夏にリリースされるそうです。TPU8t/TPU8iTPUの第8世代TPU8tとTPU8iが発表されました。TPU8tは事前学習用途に、TPU8iは推論用途に最適化されているそうです。検索エンジンを作ってきたGoogleとしてはレイテンシをかなり重視しているようで、TPU8iによって高速にAIが応答を生成する(毎秒約1,500トークン！)様子が紹介されていました。Gemini Omniの発表マルチモーダルモデルOmniが発表されました。Omniは「世界モデル」と呼ばれていて現実世界の物理法則を理解しているそうです。今のところ画像編

Vポイントマーケティング TECH LABのTech Blogが、ITフリーランス向けサイト「レバテックフリーランス」で紹介されました。本ブログがフリーランスエンジニアの皆様のお役に立てれば幸いです。タイトル新技術から開発の舞台裏まで！エンジニアの学びを支えるブログ記事URLhttps://freelance.levtech.jp/guide/detail/211857/freelance.levtech.jpレバテックフリーランス｜トップページhttps://freelance.levtech.jp/

UCPのサンプル実装を見て実装ポイントをまとめてみる(Create Checkout編)こんにちは、VポイントマーケティングAIエンジニアの三浦です。最近Googleのエージェンティックコマースの共通プロトコルUniversal Commerce Protocol(UCP)のサンプルプログラムを読んでいます。「これ、どういう意味なんだろう？？」と色々立ち止まりながら読み進めているのですが、自分の理解を深めるためにも実装ポイントを少しずつまとめていきたいな、と思っています。実装サンプルは"Flower Shop"という架空の花屋ECのUCP Merchant Serverとしての実装例を表しています。以下のレポジトリで公開されています。github.comこの中で読んでいるのはPythonのRESTの実装です。ディレクトリはsamples/rest/pythonが対象になります。まずはこのUCP MerchantのUCPプロファイルを把握し、ビジネスロジックのうち、Checkoutセッションを開始するcreate_checkoutについて見ていきます。/.well-known/ucpで公開されるUCPプロファイルを見てみようUCP Merchantは/.well-known/ucpで自分のUCPにおける情報(profile)を公開します。このprofileには、利用できるtransport、対応できるcapabilityやpayment handlerなどが含まれます。エージェントやクライアントはここを見て、このUCP Merchantとのやり取りの仕方を知ることができます。このエンドポイントの実装はserver/routes/discovery.pyのget_merchant_profileが対応していて、その中身を見ると同一フォルダ内にあるdiscovery_profile.jsonの中身を読んでレスポンスで返していることが分かります。このJSONファイルを見てみると、services、capabilities、payment_handlersで公開されるprofileの情報が定義されています。まずservicesですが、以下のようになっています。... "services": { "dev.ucp.shopping": [ { "version": "2026-

こんにちは、VポイントマーケティングAIエンジニアの三浦です。私はプライベートではJetson AGX Orinの開発者キットにリモートで接続してCodex CLIでコーディングをしたりしています。Jetson AGX Orinは小型でありながらGPUを使ったリアルタイムの映像処理が得意なエッジデバイスで、IoTの領域で力を発揮します。最近は開発サーバーとして活躍してもらっていますが、久しぶりにカメラを使った何か面白いことをやってみたいな、と考えました。以前JetsonでUSBカメラを接続して、Pythonのプログラムからアクセスして画像を取得する、といったことをやったことがあったのですが、Codexで画像を取得するスクリプトを実行するAgent SKillを作ればCodexが目の前の状態を把握したうえでタスクをこなしてくれるような、Codexに「見る力」を与えることができるんじゃないか・・・と思いました。実際にやってみるとCodexからカメラにアクセスするスクリプトを単純に呼び出すだけでは実現が難しいことがわかりました。その辺りも含めて今回の記事でまとめてみたいと思います。CodexをインストールしたJetson AGX OrinにUSBカメラを接続skill-creatorを使って作ってみるCodexにはAgent Skillを自然言語で作成できるskill-creatorというスキルがあらかじめ組み込まれています。これを使って以下のように指示を出して作成をしてみました。$skill-creator いま接続しているUSBカメラから画像を取得することができるSkillを作って。すると以下のような構成のSkillが生成されました。CAPTURE-USB-CAMERA├── agents│ └── openai.yaml├── references│ └── troubleshooting.md├── scripts│ ├── __pycache__│ └── capture_usb_camera.py└── SKILL.mdagents/openai.yamlって見慣れないな、と思って調べたところ、Codex Appでの表示に関する設定のようでした。このSkillのコアはscripts/capture_usb_camera.pyでmain()の中身を見るとカメラデ

こんにちは、VポイントマーケティングAIエンジニアの三浦です。先日久しぶりに映画館に映画を見に行きました。やっぱり大きな画面と迫力のある音響で作品を見ると没入感があっていいなと思いました。それと、映画館の雰囲気ってちょっと日常から離れた感じがして好きです。さて、私はエージェントを使っていろいろとアプリケーションの開発をしています。自分しか使わないアプリだったら仕様を決めた後はコードを全てエージェントに書いてもらう、といったことも増えてきました。そんな風に開発したアプリのソースコードをいざ読んで理解しようとしてもコードの量が膨大でなかなか手が付けられず、そのことについて最近課題に感じていました。普段自分自身が使い慣れた開発言語やフレームワークであればまだなんとかなりますが、それ以外だとそもそもどこから手を付けたらいいのかすら分からなかったりします。それらの対策としてコードを解説するMarkdownのドキュメントをエージェントに書いてもらうのですが、関数の呼び出しがあちこちに散らばっているような構造だとドキュメントだけでは理解しづらいこともあります。「こういうのって実はグラフ構造になっていると理解しやすいんじゃないかな」と思い、「コードベースのナレッジグラフ化」という観点で調査していたのですが、これはいいな、と思ったツールに出会いました。Graphifyというツールです。graphify.netGraphifyはプロジェクト内に存在するコードをはじめ、ドキュメント、画像、動画等のファイルからナレッジグラフを構築し、コーディングエージェントが参照できるようにするツールです。プロジェクトをナレッジグラフにすることでエージェントがファイルを開いて読むよりもより効率にかつ正確にプロジェクト全体を把握できるようになります。色々なコーディングエージェントに対応していて、Claude CodeはもちろんCodexやGemini CLI、Github Copilot CLIでも使うことが可能です。私はプライベートではCodex, 業務ではGithub Copilot CLIを使っていますが、どちらでも動かすことができました。今回の記事ではこのGraphifyについて導入の仕方や使い方、ナレッジグラフをどのように構築しているのかをまとめてみたいと思います。Graphifyを導入するGra

はじめにこんにちは、VポイントマーケティングAIエンジニアの三浦です。今年のゴールデンウィークに思い切ってスマートフォンを買い換えました。前の機種はもうだいぶ長いこと使っていたので、新しい機種になって「画面がスムーズに動く・・・！」など、いろいろスマートフォンの進化に感動しています。さて、前回MCP Serverの認可について調べたことをまとめました。techblog.vpoint.co.jp前回の記事はどちらかというと概念に近い内容だったのですが、もう少し具体的な内容もまとめたいなと考えて、MCPのドキュメントの「Security Best Practices」というタイトルのページを最近読んでいました。modelcontextprotocol.ioこのドキュメントではMCPサーバーの認可の仕様において、実装をおざなりにするとどのようなリスクが発生しうるのかがまとめられています。今回はこの中からMCPサーバーで起こりうる「混乱した代理問題」と「トークンパススルー」という問題と、それを防ぐためにMCPサーバーにどのような実装が求められるのかについて調べてみたことをまとめてみたいと思います。混乱した代理問題(Confused Deputy Problem)混乱した代理問題は、権限を持たないクライアントがその権限を持つプログラム(代理人)にアクセスして指示を出すことで、本来できないはずの操作が可能になってしまうというコンピュータセキュリティにおける脆弱性の一種です。この問題がMCPサーバー、特にサードパーティのAPIへの橋渡しをするMCPプロキシサーバーとして動作するときに発生する可能性があります。具体的には以下の条件が揃ったときに混乱した代理問題が発生してしまいます。MCPサーバーがサードパーティAPIと静的なクライアントIDで接続しているMCPサーバーがMCPクライアントに「動的クライアント登録」を許可しているサードパーティAPIの認可サーバーがユーザーの同意をユーザーのブラウザに同意クッキーで保存し同意画面を省略できるMCPサーバーがサードパーティAPIに接続する前にリクエストを送ってきたクライアントの検証処理を実装していないこの時以下のフローで攻撃者は攻撃が可能になってしまいます。ユーザーが正規のクライアントでMCPサーバーを通じてサードパーティAPIを利用でき

こんにちは、VポイントマーケティングＡＩエンジニアの三浦です。最近既存のAPIをMCPを使ってAI Agentに提供できるようにするにはどうしたらいいのか調べていました。どんな機能を提供するのかを考えるのはもちろんなのですが、どうやって安全に機能を提供できるのかについてもしっかりと理解しておく必要があると思っています。そういった理由から、最近MCP(Model Context Protocol)のドキュメントの認可(Authorization)仕様のページを読んでいます。modelcontextprotocol.ioこのドキュメントではMCPの認可におけるMCPクライアント, MCPサーバー, 認可サーバーそれぞれの実装における要件が説明されています。この中で特に今回はMCPサーバーを開発し、HTTPベースで提供するうえで開発者が知っておかなければならない要件に注目して読み進めています。今回の記事では全ての内容をまとめることは出来ていませんが、これまで読み進めた中で重要な点を自分の勉強をかねてまとめてみたいと思います。MCPの認可フローの大まかな流れまず今回の認可フローはMCPサーバーをHTTPベースで提供する場合に推奨されるものです。STDIOで使用するMCPサーバーの場合は資格情報は環境変数などから取得することが想定されています。MCPクライアントが接続したいMCPサーバーにトークンなしでアクセスするMCPサーバーは401 Unauthorizedを返すMCPクライアントはMCPサーバーのレスポンスのWWW-AuthenticateヘッダかWell-Known URI経由でMCPサーバーのProtected Resource Metadataを取得してどの認可サーバーを使うのかを判断するMCPクライアントはその認可サーバーのメタデータを取得して、認可エンドポイントやトークンエンドポイント、PKCE対応などを確認する事前登録済みのclient_idを使うか、Client ID Metadata Documentsを使うか、必要なら動的クライアント登録を使ってクライアント登録するMCPクライアントは PKCEを使い、resourceパラメーターと必要なscopeを付けて認可を開始するユーザーがブラウザー上で認可すると、MCPクライアントは認可コードを受け取るMCPク

こんにちは、VポイントマーケティングAIエンジニアの三浦諒一です。前回Claude Codeのエージェントループ、コンテキスト管理、Agent Skills機能をアプリで利用できるようになるClaude Agent SDKの記事を書きました。techblog.vpoint.co.jp前回の記事ではClaude Agent SDKのバックエンドLLMをDatabricksのFoundation Model APIsで提供されているものを使用する構成を紹介しましたが、今度はもう少し踏み込んで開発したエージェントをDatabricks Appsで動かすことが出来るかどうかを確認してみました。確認してみた結果、Claude Agent SDKを使って開発したエージェントをDatabricks Appsで動かすことが出来ることが分かりました。特にAgent Skillsを組み込んだエージェントも動かすことが出来たので、この構成を応用すれば色々なエージェントをDatabricks Appsで提供することが出来そうだと感じました。今回開発したエージェントアプリ今回Databricks Appsで動かせるか確認するために開発したのが自然言語でGIFアニメーションを作ることが出来るエージェントです。GIFアニメをチャット形式で生成出来ます。バックエンドはPythonのClaude Agent SDKを使っているのですが、さらに"slack-gif-creator"というAnthropicのAgent Skillsを組み込むことで高品質なGIFアニメを生成することが実現出来ています。github.com構成システムの構成をまとめると以下の図のようになります。構成図Databricks Appsにデプロイするフォルダに使用するAgent Skillsを含めておき、Claude Agent SDKが使用出来るようにしておきます。Claude Agent SDKはバックエンドのLLMにDatabricks Foundation Model APIsで提供されている"databricks-claude-opus-4-5"を使用しています。開発の流れ開発はGithub Copilotをコーディングエージェントとして使用して行いました。以下のAgent Skillsを使用しました。slack-gi

こんにちは、VポイントマーケティングAIエンジニアの三浦諒一です。あっという間に桜の時期が過ぎて、いつの間にか気温が高くなってきました。外で体を動かすときなんかはもうTシャツだけで十分なくらいです。アプリケーション開発にClaude CodeやGithub Copilot、Codexなどを活用しているのですが、それ以外にもドキュメントを書いてもらったり調査をしたりといった用途でもこれらのエージェントがとても便利だと感じるようになりました。ただこういったエージェントは便利な反面扱う側も気を使わなければいけないことがあります。使うツールに制限をかけるとか、動作するための専用環境を用意するなどです。こういったハードルを軽減しながらこれらのエージェントのメリットを誰もが受けられるようにしたいな、と考えていました。そんな中、Claude Agent SDKというライブラリがあることを知り、これを使えば自分が実現したいと思っていたことが実現出来そうな可能性を感じました。今回の記事はClaude Agent SDKの使い方を中心にまとめてみました。バックエンドのLLMをDatabricksでホストされたものを利用することで今後社内展開がしやすくなるように意識した内容になっています。Claude Agent SDKとはClaude Agent SDKとはAnthropicが公開しているカスタムエージェントを開発するためのSDKです。code.claude.comAgent SDKを使うと、Claude Codeでも採用されている以下の特徴を持ったエージェントを開発することが出来るようになります。Claude Codeと同様のToolが使用出来るToolの実行結果と評価、再実行を繰り返すAgentic LoopContextの管理たとえばAgent SDKでは以下のToolをすぐに利用することが出来ます。 Tool 説明 Read 作業ディレクトリ内の任意のファイルを読み取る Write 新しいファイルを作成する Edit 既存のファイルに対してピンポイントな編集を行う Bash ターミナルコマンド、スクリプト、git操作を実行する Monitor バックグラウンドで実行中のスクリプトを監視し、各出力行をイベントとして処理する Glob パターン指定（例: **/*.ts, src/

こんにちは、VポイントマーケティングAIエンジニアの三浦です。先日ChatGPTやClaudeで動作するUI付きのアプリケーションが開発できるMCP Appsという仕組みについてご紹介しました。techblog.vpoint.co.jpこの記事の後にもMCP Appsについて継続して調べていて、"ext-apps"というMCP Appsのデモアプリがまとめられたリポジトリも眺めたりしていました。github.comデモアプリの中で地図を表示させるものがあるのですが、この地図を表示できることを利用して何か自分でもアプリを作ってみたいな、と思いました。考えてみた結果、ChatGPTで世界地図を見ながら世界中の国のことを知ることが出来る世界地図勉強アプリを作ってみることにしました。世界地図勉強アプリChatGPTの中で「地図の勉強をしたい」と発言すると、操作可能な世界地図を表示してくれます。世界地図が開きます世界地図を眺めながら、「ここってどこの国なんだろう？」と気になった地点の国名や基本的な情報を調べることが出来ます。世界地図で気になるポイントの国名や基本情報を確認できます。その国の情報を詳しく知りたければそのままChatGPTに聞いて調べてもらうことが出来ます。ChatGPTが詳しく調査してくれます。使ってみると意外と楽しくて、「地図のこのめっちゃギザギザしてるとこってこの国だったんだ！」とか「じゃあこの国の名物料理ってなんだろう？」みたいなことをたくさん知ることが出来ました。ポイントこのアプリで特に大事なポイントはChatGPTとアプリの役割の切り分けです。以前Agent Skillsのベストプラクティスについて調べていた時に、「Claudeはすでに非常に賢い」というコア原則が書かれていたのを思い出し、念頭に置きました。platform.claude.com私も今は知らないことがあればChatGPTに教えてもらっています。Web検索機能も備わっているため、インターネットに公開されている情報であればかなり的確に情報を教えてくれると感じています。この世界地図学習アプリのコンセプトは、「気になる国を見つけて、その国についてもっと詳しく調べる」が出来ることです。ユーザーが「気になる国」を世界地図を眺めながら見つけることが出来るようにすることがアプリの役目、そして「気になる国

はじめにこんにちは、VポイントマーケティングAIエンジニアの伊藤です。「なぜこの商品がおすすめされたか？」は、ユーザーにとってもモデルの開発者にとっても（商品の購入を任されたAIやコーディングを任されプロンプトによって自分のことを"この分野に詳しいデータサイエンティスト"だと思い込まされているAIにとっても）重要ですよね、たぶん。この記事では、実際の小売の購買履歴データでRecVAE（推薦モデル）を学習し、Captumを使ったIntegrated Gradients（IG）で推薦根拠を可視化した実験を紹介します。※ 本記事で扱う購買履歴データは、個人を特定できない形に匿名化・統計処理された分析用データを使用しています。RecVAEとIntegrated GradientsとはRecVAE（推薦モデル）RecVAEは変分オートエンコーダ（VAE）をレコメンドに応用したモデルです。入力：ユーザーの購買履歴（各商品を「買った/買ってない」の二値ベクトル）出力：各商品の購入確率（推薦スコア）「このユーザーが買いそうな商品」をスコアで予測するため、スコア上位の商品をレコメンド候補として提示します。「この時代にTransformerベースではなくVAEベース？」と思われた方もいらっしゃられるかと思いますが、必ずしも最新のモデルが最適とは限らないらしいです。クックパッドさんの RecBole を用いてクックパッドマートのデータに対する50以上のレコメンドモデルの実験をしてみた という記事では、特定の評価条件下において、RecVAEがTransformerベースのモデルを上回る結果が報告されています。実際に私も、今回扱ったデータセットおよび評価設定の範囲内でRecBoleを用いたモデル比較を行い、本実験では RecVAE の方が BERT4Rec より高い精度を示したため、RecVAEを採用しました。Integrated Gradients（IG）Integrated Gradientsは購買ベースのXAI手法で、Captum（PyTorch公式のモデル解釈ライブラリ）に実装されています。基本的なアイデアは、「ベースライン（何も買っていない状態）から実際の購買履歴に至るまでの経路に沿って勾配を積分する」というものです。これにより、各入力特徴量（＝各商品の購入有無）がモデルの出力に対

Databricks Japan主催のコミュニティ貢献認定プログラムで、プレスリリースにも掲載されておりますので、prtimes.jp※プレスリリースでは旧社名「CCCMKホールディングス（CCCMKHD）」を使用していますが、本ブログでは4月1日付で社名変更後の「Vポイントマーケティング株式会社」と表記します。

こんにちは、VポイントマーケティングAIエンジニアの三浦です。いつの間にか近所の並木道の桜が満開になっていました。朝早くの、少し肌寒い時間に見に行くのが好きです。AIを使った開発で最近必ずと言っていいほどAgent Skillsを活用しています。Agent SkillsはAIにやってほしいワークフローをまとめたもので、Agent Skillsとして定義しておけば必要な時にいちいち指示を出すことなくAIがそのワークフローを定められた手順に従って実行してくれるようになります。Github CopilotでAgent Skillsを導入する方法は以前こちらの記事でまとめています。techblog.vpoint.co.jpAgent Skillsは自分で作成するだけでなく、公開されている便利なAgent Skillsを自分のプロジェクトに取り込むことでAI開発を効率化することが出来ます。最近Databricksが公開しているAgent Skillsを使ってみたのですが、Github Copilotを使ってデータセットの内容のレポートを作成したり、データを可視化できるダッシュボードアプリをDatabricks Appsにデプロイするといったことが出来てとても便利でした。今回はDatabricks Agent Skillsでどんなことが出来るのかを実際に試したことを交えながらご紹介したいと思います。Databricks Agent SkillsDatabricks Agent Skillsは以下で公開されていますgithub.com2026/03/30現在、以下の5つのSkillがあります。(README.mdのAvailable Skillsにはdatabricks-appsしか言及されていませんが、リポジトリのskillsフォルダには含まれています。)databricksdatabricks-appsdatabricks-jobsdatabricks-lakebasedatabricks-pipelinesこの中でDatabricks CLIの操作に関連しているものがdatabricksSkillで、このSkillは他のSkillを使う際に必要になる必須のSkillです。あとはLakeflow Jobsを開発する際はdatabricks-jobsを、Lakebaseを操作す