はじめに ども！最近はDifyとGAS系のブログを執筆している龍ちゃんです。本職では、設計の作業をやっています。そちらも知見が貯まったらブログとして放出していく予定ですが、もう少し先ですね。 さて、今回は自分のブログ内でのコラボ企画となります。内容としては「DifyとLINE Botを接続」となります。LINE BotをGASで作成したことがある方であれば、10分程度で実装できる内容なのでぜひ試してみてください。 GASでLINE Botを作ってみたことがない方は、 こちらのブログ を参考に取り組んでみてください。全体感は1時間もあれば、作成することができると思います。 GAS×LINEで作るAIチャットボット 今回の実装ではGASとLINE Botの連携なので、GASパートとDifyパートに分かれています。全体の構成としては、以下のような構成になります。 GASの担当領域は、LINEからのWebhookを受け取りイベントごとに処理を割り振ります。テキストメッセージの場合はDify(API)を実行し、それ以外の場合はMessagingAPIを介してLINEの返答を行います。 Difyの担当領域は、テキストとリプライトークンを受け取り、LLMから出力を生成し、Messaging APIを介してLINEの返答を行います。 まず初めにDifyでワークフローを作成してからGASのソースに入っていきます。 Dify：ワークフロー ワークフローは全体4ステップのシンプルなものになっています。 開始 このノードでは、APIの引数となります。Webhookからの入力はGASで分割するので、LLMに入力するユーザーの入力とLINEの Messaging API を用いたLINEの応答に必要なreply_tokenを設定します。 キー 型 説明 reply_token String LINEのイベントオブジェクトから取得したリプライトークン message String LINEで送信されたテキストメッセージ HTTPリクエスト ここでは、LLMからの出力をMessaging APIを介してLINEに送信しています。HTTPリクエストには、ボディを直接JSONで定義ができます。ヘッダーには、LINE側の設定から取得できる認証情報を埋め込みます。 ヘッダー情報 キー 値 Content-Type application/json; charset=UTF-8 Authorization Bearer {{LINE_TOKEN}} ボディ { "replyToken":"{{開始で受け取ったreply_token}}", "messages":[{ "type":"text", "text":"{{LLMの出力}}" }] } GAS：ソースコード ソースコードの機能としては、ざっくり3つに分割することが可能です。 LINE Webhookからのメッセージイベントを振り分ける処理 Dify APIにアクセスする処理 Messaging APIを介してのLINE応答処理 LINEから取得したチャンネルアクセストークンとDifyにアクセスするためのAPI Keyをコード上部で埋め込む必要があります。 龍ちゃん 本来は！秘密鍵はちゃんと他のユーザーが簡単に覗けない場所に保存しましょうね！ const LINE_TOKEN = "************************"; const DIFY_KEY = "**************************"; //ユーザーがメッセージを送信した時に下記を実行する function doPost(e) { const json = JSON.parse(e.postData.contents); // Webhookイベントは単一で送られてくると仮定して進めます。 // 複数する可能性を考慮して進める必要はあり // <https://developers.line.biz/ja/reference/messaging-api/#webhook-event-objects> const reply_token = json.events[0].replyToken; const messageType = json.events[0].message.type; const messageText = json.events[0].message.text; // 検証で200を返すための取り組み if (typeof reply_token === 'undefined') { return; } switch (messageType) { case "text": // ここでDifyにアクセスする difyAccess(messageText, reply_token) return case "image": case "video": case "audio": case "file": case "location": case "sticker": default: const message = "今回のBOTはテキストメッセージにのみ対応しています。"; replyTextMessage(message, reply_token) return; } } const difyAccess = async (message, reply_token) => { const data = { "user": "gas_LINE_automation", "response_mode": "blocking", 'inputs': { "reply_token": reply_token, "message": message } }; const headers = { 'Authorization': "Bearer " + DIFY_KEY, 'Content-Type': 'application/json' }; const request = { "url": "https://api.dify.ai/v1/workflows/run", "method": "post", "payload": JSON.stringify(data), "headers": headers, "muteHttpExceptions": true }; UrlFetchApp.fetchAll([request]) } const replyTextMessage = async (message, reply_token) => { const request = { "url": "https://api.line.me/v2/bot/message/reply", 'headers': { 'Content-Type': 'application/json; charset=UTF-8', 'Authorization': 'Bearer ' + LINE_TOKEN, }, 'method': 'post', 'payload': JSON.stringify({ 'replyToken': reply_token, 'messages': [{ 'type': 'text', 'text': message, }], }), } UrlFetchApp.fetchAll([request]) } LINEの情報受け取り部分 こちらでは、LINEから送信されてきたメッセージイベントをテキストかそれ以外かを割り振る処理を記載しています。 //ユーザーがメッセージを送信した時に下記を実行する function doPost(e) { const json = JSON.parse(e.postData.contents); // Webhookイベントは単一で送られてくると仮定して進めます。 // 複数する可能性を考慮して進める必要はあり // <https://developers.line.biz/ja/reference/messaging-api/#webhook-event-objects> const reply_token = json.events[0].replyToken; const messageType = json.events[0].message.type; const messageText = json.events[0].message.text; // 検証で200を返すための取り組み if (typeof reply_token === 'undefined') { return; } switch (messageType) { case "text": // ここでDifyにアクセスする difyAccess(messageText, reply_token) return case "image": case "video": case "audio": case "file": case "location": case "sticker": default: const message = "今回のBOTはテキストメッセージにのみ対応しています。"; replyTextMessage(message, reply_token) return; } } Webhookではメッセージイベント以外にも様々なイベント が送付されてきます。特定のイベントの場合の挙動を変更することができます。 注意点 グループチャットにBotを導入した場合はイベント配列に複数のイベントが送付されてくる可能性もあります。イベントを落とさない仕組みが必要です。 参考 Messaging APIリファレンス TextMessageの場合：Dify APIアクセス こちらでは、Dify APIへアクセスを行っています。こちらの詳細は「 Dify入門ガイド：DifyのAPIをGASで使う方法！10分で作るAI連携システム 」で解説しています。 const difyAccess = async (message, reply_token) => { const data = { "user": "gas_LINE_automation", "response_mode": "blocking", 'inputs': { "reply_token": reply_token, "message": message } }; const headers = { 'Authorization': "Bearer " + DIFY_KEY, 'Content-Type': 'application/json' }; const request = { "url": "https://api.dify.ai/v1/workflows/run", "method": "post", "payload": JSON.stringify(data), "headers": headers, "muteHttpExceptions": true }; UrlFetchApp.fetchAll([request]) } TextMessage以外の場合：GASからの返答 こちらでは、GASからMessaging APIを介して送信するサンプルとなります。詳細は 公式リファレンス を参照しましょう。 const replyTextMessage = async (message, reply_token) => { const request = { "url": "https://api.line.me/v2/bot/message/reply", 'headers': { 'Content-Type': 'application/json; charset=UTF-8', 'Authorization': 'Bearer ' + LINE_TOKEN, }, 'method': 'post', 'payload': JSON.stringify({ 'replyToken': reply_token, 'messages': [{ 'type': 'text', 'text': message, }], }), } UrlFetchApp.fetchAll([request]) } 既存実装の問題点・メリット 既存実装で本番運用するには難しい点が何点かあります。GASにおける制限については、「 いまさらGASでLineBotを作る【オウム返し】： GASとLINEの処理の流れと制限事項 」で解説しています。 メリット：ユーザーの入力タイプによって処理を振り分けることができる 今回の実装では、テキストメッセージを対象にしました。LINEでは、テキストメッセージ以外にも画像や動画の入力なども入力可能です。ワークフローを新規で作成するか、入力によって分岐するように設計することで、入力タイプによって別々の処理を実現することが可能です。 メリット：生成AIの精度に注力できる 生成AIの返答部分はDifyに移譲されています。そのため、プロンプトの変更はDify上で変更を加えることができます。LINE BOTのシステム的エラーなのか、Dify側のエラーなのか切り分けることが可能なのでデバックがやりやすいです。 Difyのワークフロータブで、ワークフローの実行を監視することができるので非常に便利です。 問題点：LLMと単発の会話になっている 現状の実装では、LLMとの単発の会話になっています。過去の会話を引き継いでいないので、一つの入力でLLMに完結させたい処理を入力する必要があります。ここは、ワークフローとデータ部分を改修する必要があります。具体的には、以下の対応が挙げられます。 Dify APIにアクセス時に過去の会話を送信する（GAS側でデータを保存） ワークフローの呼び出しユーザーによって過去の情報を取得するノードを追加（Difyからデータを取得） この設計は、データをどこで保存するかなどの要素を検討して決定する必要があります。 ここは、ワークフローではなく チャットフロー を活用することで解消できそうです。 問題点：流出してはいけない秘密鍵がべた書きになっている これは、わかりやすさ重視でサンプルでは秘密鍵をソースコードに直接入力しています。以下のような対応が必要となります。 GAS： プロパティサービス を利用してアクセスすることができる人を制限する Dify： 環境変数 として秘密鍵情報を保護する おわり 今回は、DifyとLINE Botを組み合わせた簡単なチャットボットの実装方法を紹介しました。テキストメッセージに対応したシンプルなワークフローを構築することで、生成AIの返答精度に注力できる環境を整えることができます。今後は過去の会話履歴の管理など、より高度な機能の実装にも挑戦していきたいと思います。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Dify入門ガイド：GAS × Difyを使って10分で作るAI LINE BOT！ first appeared on SIOS Tech. Lab .

こんにちは、サイオステクノロジーの遠藤です。 今回はDifyの機能の一つである「API拡張」についてどんな機能なのかとそのチュートリアルを行って実際の使い方を確認していきます。 では早速始めていきましょう！ API拡張って何？ API拡張に関する公式ドキュメント : API 拡張 DifyのAPI拡張という機能は外部のAPIをシステムプロンプト内で呼び出してシステムプロンプトに埋め込むことができる「外部データツール」として使用したり、端末ユーザーの入力内容とLLM（大規模言語モデル）の出力内容を審査することができる「コンテンツモデレーション」機能を利用することができる機能です。 特に「外部データツール」機能はDifyとしても押しの機能なようで、この機能を利用することで自前の検索能力や内部ナレッジベースなどの外部データをLLMのコンテキストとして使用できるようになります。「外部データツール」を使用することで、クラウドにデータセットをアップロードするのと比べて、プライベートデータセキュリティの確保、カスタム検索、リアルタイムデータの取得などの面で顕著な利点があります。 API拡張を使用するために満たす必要のある仕様 API拡張では外部のAPIをDifyの中で呼び出せる機能ということで、使用するAPIはDifyが定める仕様を満たしている必要があります。以下がAPI拡張で使用するAPIに求められる仕様です。 APIの仕様 このAPI拡張で使用するAPIは以下の仕様を満たす必要があります。 呼び出し方 POST {Your-API-Endpoint} リクエストヘッダー ヘッダー 値 説明 Content-Type application/json リクエスト内容はJSON形式です。 Authorization Bearer {api_key} APIキーはトークン形式で送信されます。 api_key を解析し、提供されたAPIキーと一致するか確認してください。 リクエストボディ { "point": string, // エクステンションポイント、異なるモジュールは複数のエクステンションポイントを含む可能性があります "params": { ... // 各モジュールのエクステンションポイントに渡すパラメータ } } APIレスポンス { ... // APIレスポンスの内容、異なるエクステンションポイントのレスポンスは各モジュールの仕様に従います } 外部データツールで使用可能なAPIのデプロイを行い、Dify上で触ってみる DifyではAPI拡張の仕様に沿ったAPIをデプロイするチュートリアルがあり、今回はまず こちらのチュートリアル に沿ってCloudflare Workersを使用してAPIのデプロイを行ってみます。その後APIをDify上で外部データツールとして扱うまでを試して見ましょう。ちなみに、デプロイされるAPIの内容としてはブレイキング・バッドの名言とその名言を言ったキャラクターが返されるというものになっているようです。 このチュートリアルではnpmが必要となりますので、Node.jsの環境が必要となります。 Tips Cloudflare Workers は、Cloudflare が提供する サーバーレスコンピューティングプラットフォーム です。分散ネットワーク上で JavaScript / TypeScript / WebAssembly コードを実行でき、グローバルに高速なレスポンスを提供できます。安価 & 無料プランがあり、無料プランでは 1日10万リクエスト まで利用可能。 1.API拡張の仕様に沿ったアプリケーションをデプロイするためにご自身のターミナルでGithubからアプリケーションをクローンします。 git clone <https://github.com/crazywoola/dify-extension-workers.git> クローン元 : https://github.com/crazywoola/dify-extensions-worker 2.dify-extention-workersに移動し、wrangler.tomlをwrangler.toml.exampleから作成します。 cd dify-extention-workers cp wrangler.toml.example wrangler.toml 3.bearerトークン用のランダムなトークンを作成します。こちらのトークンですが、Difyアプリケーションでも必要となるものですので、メモしておいてください。 cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 16 | head -n 1 | sort | uniq 4.「3.」で作成した文字列を「2.」で指定されているwrangler.tomlのTOKENに設定します。 name = "dify-extension-example" compatibility_date = "2023-01-01" [vars] TOKEN = "<作成したトークン>" 5.npm installを実行し、必要なパッケージのダウンロードを行います。 npm install 6.npm run deployを実行し、cloudflareにdeployを行います。 npm run deploy 7.ブラウザに移動するので、cloudflareに登録します。私はGoogleアカウントを利用して登録を行いました。 8.ブラウザでAllow Waranger to make changes to your Cloutflare account で「Allow」を選択する。初回実行時、次の手順が表示されるまで少し時間がかかったのでご注意。 9.コンソールでサブドメインを設定する。設定後、yesと回答する What would you like your workers.dev subdomain to be? It will be accessible at https://<subdomain>.workers.dev … <サブドメインを設定> 10.https://dify-extension-example.<サブドメイン名>.workers.dev にアプリがデプロイされる。 https://dash.cloudflare.com/ 　からデプロイされたことが確認出来ます。 こちらもデプロイ処理が走っており、saas上からはデプロイが確認出来ている状況で API を叩いても何も返ってこない時間が５分ほどあったので、その場合には 場合は少し待ってみてください。 11.Difyに移動し、最初からアプリを作成を選択し、「チャットボット」を作成します。 12.右上のユーザーアイコンをクリックし、「設定」をクリックします 13.API拡張のタブをクリックし、API拡張機能を追加を選択します 14.先ほどデプロイしたアプリケーションに関する情報を入れていきます。名前はdify内で使用する識別子なので何でも良いです。APIエンドポイントは先程Cloudflareで作成したAPIパスの末尾に /endpoint を追加したものを設定してください。APIキーは手順「3.」で作成したbearerトークンを入れてください。APIエンドポイントやAPIキーが正しくない場合、Not FoundやUnauthorizedが出ますのでご注意ください。 15.ここまで出来たら、チャットアプリに戻り、「変数」の「APIベースの変数」を選択します。 16.名前と変数名に「breaking_bad_quotes」を設定しAPI拡張機能として先ほど追加したBreakingBadQuotesを選択します。 17.最後にシステムプロンプトを設定します。{{breaking_bad_quotes}}をシステムプロンプトの中に設定すると、作成したAPIをシステムプロンプト内で呼び出して、そのデータを使うことができます。 18.チャットを送ってみると、しっかり条件通りにブレイキング・バッド関係のことを聞いたときのみAPIの内容を利用して回答を生成してくれていることが確認できます。 19.プロンプトログを確認してみると、しっかりAPIの内容がシステムプロンプトに含まれていることが確認できました！ まとめ 今回はDifyのAPI拡張についてその機能とチュートリアルを通じて具体的な使い方を確認しました。API拡張を利用することで、地域に基づいて外部の天気情報を取得してそのデータを元に回答したりみたいなことが行えるようになるので、提供できるソリューションを広げることが出来そうです。今回はチュートリアルを試すまででしたが、API拡張を使用した良さそうなアプリケーションが出来たらまたブログで公開しますので、目を通していただければと思います！ ではまた～ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Dify入門ガイド：API拡張って何？チュートリアルを通じて学んでみよう first appeared on SIOS Tech. Lab .

概要 現在のIT業界では、DXが進む中でコンテナ技術とKubernetesが注目されています。 vSphereなどの仮想化基盤を使用して仮想マシン（以降、VM）を運用している企業も多い中、VMとコンテナを統合管理したいというケースや、VMをコンテナにして既存のコンテナプラットフォームで扱いたいというケースなども出てくるかと思います。 しかし、VMをコンテナ化する際に、仮想化レイヤがハードウェアレベル（VM）とOSレベル（コンテナ）で異なるといった課題があります。今回紹介するOpenShift Virtualization（以降、OCP-Virt）は、既存のOpenShift上でコンテナとVMを統合管理することが出来るため、このような状況に対応することが出来ます。 本記事では、OCP-Virtの基本的な概要からアーキテクチャ、VMの移行ツール、他の仮想化基盤との比較について解説します。 次回の記事では実際にOpenShift Virtualizationを触ってみようと思います。 以前にもSIOS Tech. Labに OpenShift Virtualizationについて記載した記事 があるので良かったらそちらも参考にしてみてください。 前提情報 本記事では、現時点で以下のバージョンを対象としています。 OpenShift v 4.17 OpenShift v4.17.3 Migration Toolkit for Virtualization v2.7 OCP-Virt とは OCP-Virtは、Red Hat OpenShiftのアドオンで、OpenShift Virtualization Operator をインストールすることで利用可能になります。これによって、OCP-Virtで、コンテナ環境上にVMを構成することが可能になり、コンテナとVMを既存のOpenShift上で同時に管理できるようになります。VMをKubernetesで管理することが出来るため、従来の仮想化環境よりも柔軟な運用が可能になります。OCP-Virtが提供する機能としては下記が挙げられます。 Linux および Windows VMの作成と管理 各種コンソールおよび CLI ツールの使用によるVMへの接続 既存のVMのインポートおよびクローン作成 NICおよびVMに割り当てられたストレージディスクの管理 VMのノード間でのライブマイグレーション OCP-Virtのインストールにはハードウェア要件があり、オンプレミスのベアメタルサーバーあるいはAWSのベアメタルインスタンスが必要になります。 OCP-Virt アーキテクチャ OCP-Virtは、Kubernetes環境上でVMの作成・管理を可能にするOSSのKubeVirtを元にして開発されています。KubeVirt は動作する基盤としてKubernetesを使用し、KubernetesのAPIを拡張することで、Kubernetes環境上へのVMの構成を実現しています。 VMを動作させる仕組みとしてはKVMを使用しています。KVMはRHCOS(Red Hat Enterprise Linux CoreOS) のカーネル、QEMU・libvirt はOCPのPodの中で実行しています。 Image Source:  https://tech-lab.sios.jp/archives/42280 ネットワークはCNIを通じて提供され、デフォルトでOVN-Kubernetes CNIを使用しています。Multus を使用することで、VMに追加の外部ネットワークの構成が可能となります。VMのディスクはCSIを通じて提供され、PV(永続ボリューム) を使用します。 OCP-Virt の主要コンポーネントについて説明します。 virt-controller CRDで定義されたVMを監視し、VMを構成するPodをノードに割り当てます。 virt-handler 各Workerノードで実行されるDaemonSetです。DaemonSetは全て(または特定)の各ノードで１つずつ実行されるリソース(Pod)です。ログ収集やモニタリングなど、クラスター全体のサービスを実行する際などに用いられます。 API Serverやvirt-controllerと連携して、Podの作成などの操作を、virt-launcherに指示する役割があります。 virt-launcher libvirtd と連携し、VMの作成や削除を制御します。 Image Source:  https://www.redhat.com/en/blog/building-unified-hybrid-cloud-strategy-red-hat-openshift-virtualization VMの移行ツールの紹介 OCP-Virtでは、既存の利用している仮想化基盤からの移行を支援するためのツールが Migration Toolkit for Virtualization (MTV) Operator として提供されています。MTVは様々な仮想化基盤で稼働する VM を OpenShift 上に移行するツールです。移行元として選択できる Provider は下記になります。 VMware vSphere Red Hat Virtualization OpenStack VMware vSphere によって作成された Open Virtual Appliances (OVA) リモートの OpenShift Virtualization クラスター 移行はVMのコピーのような形式となり、移行プロセス中の移行元VMの停止タイミングを移行プロセス開始時にVMを停止するCold Migrationとカットオーバー段階（VMの移行が済んだ後）にVMを停止するWarm Migrationの2種類のタイプから選択することが出来ます。 移行時のネットワークとストレージのマッピングは下記の様に行います。 ネットワーク オーバーレイネットワークの仮想スイッチに相当するもの同士をマッピングします。 vSphereでは Port GroupとOCP-VirtのNetwork Attachment Definition (NAD)をマッピングします。 Port Group：仮想スイッチ内でVMとの通信に用いられる仮想的なポート NAD：Podをネットワークに接続する方法を定義する CustomResourceDefinition ストレージ 仮想ディスクの格納先に相当するもの同士をマッピングします。 vSphereではDatastoreとOCP-VirtのStorage Classをマッピングします。 Datastore：VMのファイルシステムを格納するための論理的なコンテナ Storage Class：特定のストレージタイプ、アクセスモード、プロビジョニングポリシーなどのストレージの属性を定義したリソース このように、現行の仮想化基盤からの移行方式も用意されているため、OpenShift への移行が簡単になっています。 その他仮想化基盤との比較 SUSE Virtualization (Harvester) Harvesterは、オープンソースのハイパーコンバージドインフラストラクチャ（HCI）ソリューションで、KVMとKubernetesの技術を組み合わせた仮想化基盤になります。コンテナとVMの統合管理を行うといった点ではOCP-Virtと類似しています。HarvesterはRancherとの連携が可能になります。OCP-VirtはOpenShift上に構築されるため、コンテナプラットフォームがRancherかOpenShiftかといった点が違いになります。 VMware vSphere (vSphere) vSphereは、仮想化基盤といえば必ず名前が上がる製品であり、企業環境での広範な採用実績を持っています。幅広いハードウェアとの互換性、高度な機能（vMotion、Storage DRS、High Availabilityなど）、および堅牢なセキュリティを提供します。vSphereは仮想化に関しては非常に高い成熟度を持っていますが、OCP-Virtとの大きな違いはKubernetesネイティブな統合が簡単にできるか否かになります。 Proxmox Virtual Environment (Proxmox VE) Proxmox VEは、KVMとLinux Containers (LXC) をサポートするオープンソースの仮想化基盤です。ビルトインのクラスタリング機能を備えており、簡単にハイアベイラビリティ環境を構築できます。クラスタリングが可能で高可用性を提供できる点はOCP-Virtと類似していますが、Kubernetesネイティブであるか否かといった点が違いになります。 まとめ OCP-Virtの基本的な概要からアーキテクチャ、VMの移行ツール、他の仮想化基盤との比較について解説しました。OCP-VirtはOpenShift のアドオンで、OCP-Virtでコンテナ環境上にVMを構成することが可能になり、コンテナとVMを既存のOpenShift上で統合管理できるようになります。次回の記事では実際にOpenShift Virtualizationを触ってみようと思います。 参考文献 https://docs.redhat.com/ja/documentation/openshift_container_platform/4.17/html/virtualization/about#about-virt https://www.redhat.com/en/blog/building-unified-hybrid-cloud-strategy-red-hat-openshift-virtualization https://docs.redhat.com/ja/documentation/migration_toolkit_for_virtualization/2.7/html/installing_and_using_the_migration_toolkit_for_virtualization/index https://www.vmware.com/products/cloud-infrastructure/vsphere https://www.proxmox.com/en/products/proxmox-virtual-environment/overview OpenShift Virtualization – OpenShift でのVM管理についてご紹介 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Red Hat OpenShift Virtualization とは？ first appeared on SIOS Tech. Lab .

ご挨拶 テック系のブログばかり執筆していたので、いつの間に100本超えて130本になっていました。個人的に結構頑張りましたね。今回は、ブログを書くにあたってお世話になっているNotion AIについて書いていこうと思います。 Notion AIの話 Notion AIの値段とか、使用方法とかは 公式のリンクが丁寧に解説しているの で乗っけておきます。 ここでは、Notion AIをブログを書くにあたってどんな風に使用しているのかについて書いていきます。プロンプトを試す記事としては、最近書いた「 Dify入門ガイド：DifyのAPIをGASで使う方法！10分で作るAI連携システム 」を使用してみます。 ブログの締め これは、ブログのメインを書き終わった後に締めを書くときに使用しています。ブログの「おわりに」のタイトルまで書いて、あとは「続きを書く」でブログを読んで、最後のまとめを書いてくれます。 ほぼ振り返りを書いているので、一時期関係ないことを書いていたりしました。ブログの内容から作成しているのでブログをいい感じに締めてくれます。 ブログの評価・修正点 これは、ブログの第一弾を書き終わった後に使用しています。締めを書いた後に、以下の文をNotion AIに渡します。 誤字脱字などを含めて、ブログの評価をしてください。修正点を以下に箇条書きしてください ここで、Notion AIが褒めてくれなかったら悲しいです。あまりにもひどいブログだと、ここでNotion AIに怒られてから修正点を読み込んで修正します。 こちらのブログで試した際には以下のような返答が返ってきます。 ## 評価と修正点 - **文章の構成：** 全体的に分かりやすく、初心者向けに丁寧な解説がされています。 - **コードの説明：** GASのコード解説が詳細で、パラメーターの説明も充実しています。 - **修正が必要な点：** - 「ワークフローの右上から「公開する」を選択して」の部分で、具体的な場所の説明をより詳しくした方が良いです。 - 「API KEY」と「API key」など、表記の統一が必要です。 - 「streming」は「streaming」の誤字があります。 - 「bloacking」は「blocking」の誤字があります。 - **改善提案：** - エラー処理の具体例があると、より実践的な記事になります。 - APIレスポンスの実際の出力例があると、より分かりやすくなります。 - **総評：** 技術的な内容を分かりやすく解説できており、実用的な記事となっています。上記の修正点を反映することで、さらに質の高い記事になるでしょう。 こちらの修正点を取り込み、時には無視することでブログを修正します。 ブログのタイトル・メタディスクリプション これは、一番最後に使用します。個人的には、これが一番助かっています。以下の文をNotion AIに入力して、選んで修正ですね。 SEOに強いブログのタイトルを考えてください。 タイトルとメタディスクリプションをそれぞれ箇条書きで複数案提示してください 以下のような感じで、出力されます。自分では、絶対つけないようなタイトルを出してもらえるので、誇大広告感をぐっとこらえて付けます。 ## タイトル案 - 「【2024年版】DifyのAPIをGASで使う完全ガイド！初心者でも10分で実装できる方法」 - 「【実践解説】DifyのAPI×GAS連携！エラー対応からパラメーター設定まで徹底解説」 - 「【ステップ解説】DifyのAPIをGASで使う方法！AI連携システムの作り方」 - 「【初心者向け】DifyのAPI×GAS入門！実例で学ぶAI連携の基礎」 ## メタディスクリプション案 - 「DifyのAPIをGoogle Apps Script(GAS)で使用する方法を詳しく解説。APIキーの取得から実装手順、エラー対応まで、初心者でもわかりやすく説明。10分でAI連携システムを構築できます。」 - 「DifyのAPIとGASを連携させる方法を徹底解説。パラメーター設定やエラーハンドリングなど、実践的なコード例を交えながら、AI連携システムの構築手順をステップバイステップで紹介します。」 - 「DifyのAPI活用方法をGAS実装例と共に解説。APIキーの取得から実装、エラー対応まで、現場で使える実践的な知識を提供。AI連携システムを簡単に構築できます。」 みんなも使わない？ ざっと、30分ぐらいは執筆時間が短縮されました。メインのコンテンツや図は自分で用意する必要がありますが、自分で書いたものを入力するのでハルシネーションはあまり起きません。気になるのは、タイトルがカッコよくなりすぎるぐらいです。 これは！1300~1500ぐらいは出す価値あります！！ ぜひ使ってほしいです！そして、活用方法をシェアしてほしいな～って思ってます。 終わり 今回は、Notion AIの活用方法について、特にブログ執筆時の使い方を紹介しました。締めの作成、評価・修正点の確認、そしてSEOを意識したタイトル作成など、様々な場面でNotion AIが執筆をサポートしてくれています。皆さんも是非、Notion AIを活用して、より効率的な執筆ライフを送ってみてください！ Tech系のブログには合っているんですが、若干気持ちの入ったブログには向かないですね。CursorとかGitHub Copilotとか、活用する生成AIもエンジニアの好みが出ますね～ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 実体験：Notion AIでブログ執筆が楽になる！3つの使い方をふんわり解説 first appeared on SIOS Tech. Lab .

始めに ども！Dify系のブログをチーム総出で書いて、眺めているのが楽しくなっている龍ちゃんです。Difyのブログも本数が出ていて続いていますね。 今回は、前回作成した「 Dify入門ガイド：X投稿を自動生成！10分で作るブログPR効率化ワークフロー 」のAPI公開をして、GASからアクセスしていきたいと思います。 アプリの公開方法に関しては、「 Dify入門ガイド：作成したAIアプリ、どう公開する？Web公開・API活用する3つの方法 」で詳しく解説しています ソースコード function sampleFunction() { const headers = { 'Authorization': "Bearer *******************", //api key発行してペースト 'Content-Type': 'application/json' //必須 }; const data = { "user": "*********", // 任意の文字列で可能（監視で表示される） "response_mode": "blocking", // streaming or blocking 'inputs': { // 設定した開始ノードの入力 "URL": "https://tech-lab.sios.jp/archives/45986", "count": 120 } }; const options = { "method": "post", "payload": JSON.stringify(data), "headers": headers, "muteHttpExceptions": true // エラーを平文で返してもらう }; const requestUrl = "https://api.dify.ai/v1/workflows/run"; const response = UrlFetchApp.fetch(requestUrl, options); const responseText = response.getContentText() // 帰ってきたレスポンスを表示 Logger.log(responseText); // レスポンス内容をログに出力 // StatusCodeによって処理分岐 if (response.getResponseCode() === 200) { const responseJson = JSON.parse(responseText); Logger.log(responseJson.data.outputs.text) } else { Logger.log("Error"); // エラー発生時のログ出力 } } Difyで公開したAPIにGASからアクセスをする 詳しい手順とソースコードの解説をしていきます。まだ、Dify上でアプリを作成していない方は、 こちらの記事 を参考にしてアプリを作成してください。 DifyでAPIを公開する ワークフローの右上から「公開する」を選択して、アプリを公開します。 公開後は、下のような画像に代わります。ここからAPIにアクセスするためのAPI KEYを発行します。「APIリファレンスにアクセス」をクリックします。 右上の「APIキー」をクリックして「APIシークレットキー」を発行します。 発行した「API KEY」はDifyにAPIアクセスするのに必要になるので、大事に保管しましょう。もし、流出した場合は再発行して既存のAPIキーを失効させてください。 GASからDify(API)にアクセスする GASからDify（API）アクセス部分はこちらになります。 const headers = { 'Authorization': "Bearer *******************", //api key発行してペースト 'Content-Type': 'application/json' //必須 }; const data = { "user": "*********", // 任意の文字列で可能（監視で表示される） "response_mode": "blocking", // streaming or blocking 'inputs': { // 設定した開始ノードの入力 "URL": "https://tech-lab.sios.jp/archives/45986", "count": 120 } }; const options = { "method": "post", "payload": JSON.stringify(data), "headers": headers, "muteHttpExceptions": true // エラーを平文で返してもらう }; const requestUrl = "<https://api.dify.ai/v1/workflows/run>"; const response = UrlFetchApp.fetch(requestUrl, options); const responseText = response.getContentText() 変更する点としては、「headers」と「data」になります。 muteHttpExceptions はGASの設定パラメーターで、 UrlFetchApp.fetchが失敗した場合はエラーがresponseに格納 されます。 headers：認証のための情報設定 先ほど取得した「API Key」を渡します。 data：APIアクセスに要するコンテンツ情報 以下のようなパラメーターが必要になります。 パラメータ タイプ 説明 user String 必須 APIアクセスしたユーザーを識別する文字列（監視タブで確認できる） response_mode streaming 必須 応答のモード streaming：タイプライターのように出力が可能 blocking：実行完了後に結果を返答する inputs object 必須 開始ノードで設定したObject入力 files array[object] オプション ファイル入力を可能にしている場合のファイル入力 今回は開始ノードに変数として、「URL」と「count」を設定しています。開始ノードに変数を設定していない場合は、空オブジェクトを設定してください。 GASでレスポンスを解析する muteHttpExceptions を True に設定してるので、エラー時も処理は継続します。振り分けのためにステータスコードでの分岐を行っています。 // StatusCodeによって処理分岐 if (response.getResponseCode() === 200) { const responseJson = JSON.parse(responseText); Logger.log(responseJson.data.outputs) } else { Logger.log("Error"); // エラー発生時のログ出力 } Dify（API）のエラーコードとしては、以下のようなものがあります。 ステータスコード メッセージ 説明 400 invalid_param 異常なパラメータ入力 400 app_unavailable アプリの設定が利用できません 400 provider_not_initialize 利用可能なモデル資格情報の設定がありません 400 provider_quota_exceeded モデル呼び出しのクォータが不足しています 400 model_currently_not_support 現在のモデルは利用できません 400 workflow_request_error ワークフローの実行に失敗しました 500 – 内部サーバーエラー レスポンスとしては、 200/400/500 しかありません。ですが、エラーメッセージに情報がのっているので、エラーが出た場合はメッセージを読んで適宜修正を行ってください。 終わり DifyのAPIを使って、GASからアクセスする方法について解説しました。APIアクセスの設定は非常にシンプルで、API KEYを取得して、必要なパラメーターを設定するだけです。これからは、このGASとDify（API）を活用して様々な自動化を実現していきたいと思います。 XのAPIと連携して、ブログのPRを全自動化していくことが目標です。 ではまた～ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Dify入門ガイド：DifyのAPIをGASで使う方法！10分で作るAI連携システム first appeared on SIOS Tech. Lab .

こんにちは、サイオステクノロジーの遠藤です。 みなさん、Difyを利用して生成AIアプリ開発してますか？ノーコード・ローコードでアプリを作成できて、高度なAIアプリを素早く開発できるのが魅力的ですよね。 しかし、Dify上で作成したアプリを実際にどのように公開・活用できるのかについて、具体的な情報が少なく、戸惑うこともあるのではないでしょうか？ そこで本記事では、Difyで作成したアプリを外部に公開し、さまざまな方法で活用する方法を3つ紹介します。 シングルページWebアプリとして公開する 外部のWebアプリに埋め込む Backend APIとして利用する なお今回の記事の内容はクラウド版のDifyをベースに記述しております。Difyをより柔軟に活用したい方は、ぜひ参考にしてください！ では始めていきましょう！ シングルページWebアプリとして公開する １つ目の方法はシングルページWebアプリとして公開する方法です。 この方法は、コミュニティ版を利用して自分で構築しているかクラウド版のDifyを利用しているのかによって公開される場所が変わってきます。 コミュニティ版を利用している場合には、そのDifyアプリケーションが動作しているサーバー上でアプリが動作しますが、クラウドサービスを利用している場合、そのアプリはUdify.appにホストされる仕様になっています。 またこの機能はクラウド版を利用している場合、特に作業をせずともデフォルトで公開されるものとなっています。 ではアプリ画面上でどの用に公開されているか確認していきましょう。 まず公開を試すためにDifyの画面上部の「スタジオ」 >「 最初から作成」 > 「チャットボット」を選択し、簡単なチャットボットを作成しました。手順には作成したアプリだとわかりやすいように以下のようなシステムプロンプトを設定しました。 あなたはコンテキストに基づいてユーザーからの質問に回答するチャットボットです。 コンテキストに基づいて回答できない場合には「コンテキストに基づいて回答が出来ませんでした。質問を変更してください。」と返答してください。 まず手順をいまから公開するアプリケーションに設定するためにアプリケーション作成画面の右上にある「公開する」をクリックします。 そうすると「更新」ボタンがあるのでこれをクリックして今のアプリの状態を公開するアプリへ反映します。更新が完了したら、「アプリを実行」をクリックすれば作成したアプリケーションを開いてくれます。   チャットボットで作成されたアプリケーションだと以下の画像のようなUIでアプリケーションがUdify.appに公開されます。質問に対してお嬢様口調で返答してくれていることからしっかりシステムプロンプトが反映されていることがわかります。   さてこの機能ですが注意点があります。サクッとアプリがデプロイされるのは大変ありがたいのですが、公開URLを知っているだけで特に認証無しでアプリケーションの使用が出来てしまいます。知らない人にこの公開URLを知られるとアプリが使用され、Difyのアプリで設定しているOpenAI等のトークンも使用されてしまうといったことも考えられますので、運用には注意が必要です。 ちなみにデフォルトでオンになっているこの機能ですが、オフにすることも可能です。 オフにするには「スタジオ」左の「監視」タブの「公開URL」の右上にある稼働中のトグルをオフに設定することが出来ます。 公式ガイド : シングルページWebアプリとして公開 外部のWebアプリに埋め込む ２つ目の方法は、外部のWebアプリケーションにiframeやscriptタグで埋め込む方法です。iframeであればiframeタグを埋め込んだ場所にアプリケーションが表示され、scriptタグであれば、Webアプリケーション右下にチャットボタンが現れ、それをクリックすることでアプリケーションを利用できるようになります。 では実際に埋め込む方法を確認していきましょう。 埋め込みを行う方法を確認するには「シングルページWebアプリとして公開する」でも開いた「スタジオ」左の「監視」タブを選択し、「埋め込み」をクリックします。   そうするとウェブサイトに埋め込む方法がポップアップで表示されるので、「チャットアプリをWebサイトに埋め込む方法を選択します」から真ん中のものを選択します。選択するとHTMLコードが表示されるので、右上のコピーボタンを押して自分が掲載したいページのHTMLにコードを追加します。   今回は私はChatGPTにビジネスサイトっぽいHTMLを生成してとお願いをして、そのHTMLにDifyからコピーを行ったHTMLを追加してみました。作成してみると、画面の右下にチャットボタンのようなものが追加されるので、クリックしてみましょう。 クリックしてみると、企業サイトでよく見るようなチャットボットサポートのような表示がされ、質問を投げることができます。質問を行ってみた結果、しっかりお嬢様口調で答えてくれているので作成したアプリケーションが呼び出せていることが確認できました。 ちなみにこちらの方法につきましても、１つ目の方法と同じく公開URLをオンにしていないと使用できないのでご注意ください。 Backend APIとして利用する ３つ目の方法は、Backend APIとして利用する方法です。Difyでは作成したアプリケーションをREST API形式で提供する機能が備わっており、APIを通じて安全に機能を呼び出し視覚的インターフェースでアプリケーションをリアルタイムに設計・運営することが出来ます。 では実際にBackend APIとして利用する方法についてもアプリケーション上で確認していきましょう。 まず今までと同じように作成した「スタジオ」左の「監視」タブを開きましょう。 開けたら、「バックエンドサービスAPI」の中にある「APIキー」をクリックします。 そうするとAPIシークレットがポップアップで出てくるので、「新しいシークレットキーを作成」をクリックします。 そうすると、APIシークレットキーが表示されるのでクリップボードマークをクリックしてコピーをしましょう。 またAPIシークレットキーですが、Difyアプリケーション上でも「APIの悪用を防ぐために、APIキーを保護してください。フロントエンドのコードで平文として使用しないでください。」とあるように管理には気をつけましょう。 ここまでの作業が完了したら、APIの利用方法について確認しましょう。APIの使用はスタジオの左のタブの中にある「APIアクセス」か、バックエンドサービスAPIの中の「APIリファレンス」をクリックすることで見ることが出来ます。 以下の画像は表示されるAPIリファレンスの一部です。使用できるAPIとしては非常に多く、基本のチャットメッセージを送信するAPIに加えて、フィードバックメッセージをエンドユーザーが送ることでアプリケーションの出力を 開発者が期待される出力を最適化させるために使用する「メッセージフィードバック」APIや、現在のメッセージに対する次の質問の提案する「次の推奨質問」APIなどおもしろいAPIが提供されているようです。本ブログではチャットメッセージを送信するAPIの使い方を確認していきます。   では、APIリファレンスを参考にcurlを使用してAPIを叩いてみます。今回は「東京について教えて」というメッセージを送ってみました。 curl -X POST '<https://api.dify.ai/v1/chat-messages>' --header 'Authorization: Bearer｛api-key｝' --header 'Content-Type: application/json' --data-raw '{ "inputs": {}, "query": "東京について教えて", "response_mode": "blocking", "conversation_id": "", "user": "abc-123" }' 結果がUnicodeエスケープシーケンスで表示されるので、分かりづらいですね。Difyアプリケーション上からも確認できるのでそちらでレスポンスを確認してみましょう。 アプリケーション上から確認するには、利用したアプリケーションの左のタブにある「ログ＆アナウンス」から確認することが出来ます。 アプリ上から確認すると、東京について解説してくれている様子が確認できました。   まとめ 今回はでは、Difyで作成したアプリを外部に公開し、さまざまな方法で活用する方法を紹介しました。Difyはノーコード・ローコードで高度なAIアプリを開発できる強力なツールですが、作成したアプリをどのように運用・公開するかが重要なポイントになってきます。 今回紹介した3つの方法を活用すれば、Difyのアプリをより多くのユーザーに届けたり、他のシステムと連携したりすることが可能になります。ぜひ、ご自身のユースケースに合わせて試してみてください！ 今後もDifyを活用したAIアプリ開発について発信していくので、引き続きチェックしていただけると嬉しいです。 ではまた～   ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Dify入門ガイド：作成したAIアプリ、どう公開する？Web公開・API活用する3つの方法 first appeared on SIOS Tech. Lab .

はじめに ども！弊社X「 sios-eng (SIOS Tech Lab) 」の中の人もやっている龍ちゃんです。ブログのイベントの内容をつぶやいたり、時々企画をやっていたりします。企業SNSの運用って難しいですよね。 今回は、Difyを活用して「記事のURLを入力したら、ポスト内容を作成」するワークフローを作成していきたいと思います。 URLからXのPR文作成ワークフロー 作成から動作確認まで10分程度で完了するので、手元の環境で試してみてください。全体感は以下のようなシンプルな感じでまとまります。 ステップとしては、4つです。 開始：URL・文字数上限を入力 WEB SCRAPER：URLからスクレイピングを行ってくれるツール（Dify製ツール） LLM：記事の内容をXの投稿内容に成型 終了：LLMが作成したテキストを出力 開始：変数定義 変数としては、URLと文字数の上限を設定しています。 URL：テキスト（最大45） 文字数：数値 文字数を変数にしておくことで、一つのワークフローでXのポスト内容・メタディスクリプションなどの複数の要件に対応することができます。 WEB Scraper 入力としては、【開始：変数定義】で設定したURLを入力とします。 WEB Scrapeでは、ようやく機能がついています。要約は、次のLLMで行うのでオフでも問題ありません。 LLM：Ｘのポスト内容作成 一番重要なプロンプト部分になります。プロンプトは、後輩の中の人から提供いただきました。 以下はとある技術ブログのコンテンツです。あなたのタスクは、このブログを人々に読みたいと思わせる明るくポップな紹介文を作成することです。以下の条件を必ず守ってください： 1. 紹介文は{{count}}文字以内であること。 2. 紹介文は日本語で書くこと。 3. 紹介文はブログの主な内容やテーマを簡潔に伝えること。 4. 読者が興味を持つようなキャッチフレーズや魅力的な表現を使うこと。 5. 紹介文の後に1行改行を入れること。 6. 紹介文には関連するハッシュタグを1つ含めること。 具体的な紹介文の例： 【ブログ】 プロンプトエンジニアリングの応用編！生成AIの回答に揺れがあるって知ってた？初心者からでもわかりやすく解説しています。 #プロンプトエンジニアリング #駆け出しエンジニアと繋がりたい #プログラミング初心者 以下はブログコンテンツの抜粋です。これを基に紹介文を作成してください： ======== {{text}} ======== 上記の内容を踏まえて、{{count}}文字以内の紹介文を日本語で作成してください。 プロンプト内に、【開始：変数定義】で入力した「count」と【WEB Scrape】で取得した「text」を埋め込んでいます。one-shotで例を与えて生成精度を上げていますね。 終了 最後に出力として、LLMからの出力を取得します。 実際に使ってみる 使用感を試すために以下のブログからポスト内容を作成してみます。 2025-02-04 【Azure】BicepでFunctionsにComosDBの組み込みロールを付与する X:Bot AzureのBicepでCosmosDBとFunctionsを連携させる方法を徹底解説！ハマりがちなポイントも詳しく説明しています。インフラデプロイを簡単にしたい方に必見の内容です！ # AzureTechTips どうでしょうか？意外といい感じです。 もちろん内容の精査は必要ですが、PR文を考える部分は自動化することができそうです。 おわり 今回は、ブログ記事からX（旧Twitter）のPR文を自動生成するワークフローを作成しました。まだまだ改善の余地はありますが、企業SNSの運用効率化の第一歩として、ぜひ試してみてください。みなさんも、Difyを使って独自のワークフローを作ってみましょう！ Xのフォローもよろしくお願いします！！ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Dify入門ガイド：X投稿を自動生成！10分で作るブログPR効率化ワークフロー first appeared on SIOS Tech. Lab .

サイオステクノロジーの織田です。今回は、Dify の監視機能について紹介します。この機能を活用することで、チャットボットの改善を効率的に行うことができます。 Difyの監視機能を用いることで、作成したチャットボットの使用状況を数値として把握することができます。監視機能は各チャットボットを開いた際、画面左のメニューバーの一番下「監視」から遷移できます。今回は、その監視タブに表示される項目を１つずつ紹介していきます。 トータルメッセージ数  一日ごとのチャットボットとおこなった質問の回数を記録します。ユーザーからの質問にチャットボットが応答するごとに１ずつカウントされます。   総会話数 一日ごとのチャットボットが使用された回数を記録します。同じチャット画面で会話する場合、何度質問をしても総会話数は１になります。例えば同一チャットで10回質問すると、トータルメッセージ数は１０で総会話数は１になります。   アクティブユーザ数 一日ごとのチャットボットと会話したユーザ数を記録します。少なくとも一問一答以上のやり取りをしたユーザーが含まれます。   平均セッションインタラクション数 １チャットあたりで交わされたメッセージ数を算出します。つまり、トータルメッセージ数を総会話数で割った値が示されます。例えば、総会話数が２の場合で、それぞれのチャットでのメッセージ数が２と８であれば、平均セッションインタラクション数は５となります。   トークン出力速度 毎秒のトークン出力数を記録しています。モデルによる出力の生成速度およびアプリケーションの使用頻度を間接的に反映します。   ユーザー満足度率 Difyではチャットボットからの応答に「いいね」を送ることができます。ユーザー満足度は1000 メッセージごとの「いいね」数を示します。ユーザーが回答にどれだけ満足しているかが分かります。   トークン使用料 チャットボットが一日ごとに言語モデルにリクエストしたトークンの消費量を記録します。この指標を参照することでコスト管理に役立ちます。 Dify のモニタリング機能は、チャットボットの改善に役立つ強力なツールです。ぜひ活用して、より効果的なチャットボットを構築しましょう！ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Dify入門ガイド：監視機能でチャットボットを改善 first appeared on SIOS Tech. Lab .

はじめに こんにちはサイオステクノロジーの小野です。 前回 はシングルモデルサービング環境の構築を行い、LLMをデプロイする方法を解説しました。今回はHugging Face HubからLLMをダウンロードし、そのLLMをOpenShift AIにデプロイして、LLM APIを利用する方法を解説します。 公開LLM 有名な公開LLM Llama3 Meta社が開発したLLMです。軽量かつ高精度なモデルでオープンでありながらGPT-3.5に匹敵する性能があります。 Mistral Mistral teamが開発したLLMです。Llamaと同様に軽量であるのに加えて、推論が速いという特徴があります。 Deepseek-R1 中国のDeepseek社が開発したLLMです。OpenAIの最新モデルであるo1に匹敵する性能を持っています。今最も流行に乗っているモデルです。 LLMの取得設定 Hugging Face Hubでの操作 Hugging Face Hubとは AIモデル、データセット、AIデモアプリを公開・管理するプラットフォームです。GitHubのAIモデル版のようなイメージです。 モデルの内容 今回はMistral-7B-Instruct-v0.3というLLMをデプロイします。 https://huggingface.co/mistralai/Mistral-7B-Instruct-v0.3 このLLMは70億個のパラメータを持ち、Instruct-tunningと呼ばれる自然な会話ができるようになる調整がされています。 必要な登録 Hugging Face Hubのアカウントを作成してください。Hugging Face Hubのモデルをダウンロードするにはアクセストークンが必要になります。SettingのAccess Tokensを開き、Create new tokenを押下します。 Hugging Face Hubのアクセストークン作成 今回はモデルのダウンロードのみに使用するのでToken typeをReadとしてトークンを作成します。 アクセストークンのToken typeをReadに設定 作成するとトークンの値が表示されます。このトークン値は見れなくなるので必ずメモしておいてください。 Hugging Face Hubのアクセストークンの表示。閉じると見れなくなるのでメモしてください。 アクセストークンが作成できたらMistral-7B-Instruct-v0.3のページを開いてください。モデルにアクセスするには連絡先を共有することに同意が必要と表示されるので、利用規約を読んで納得した上で同意してください。 LLMの利用規約の同意。必ず規約を読んだうえで同意してください。（画像はMistral-7b-Instruct-v0.2ですがv0.3の規約に同意してください） しばらくしたらSettingのGated Repos StatusのMistral-7B-Instruct-v0.3がACCEPTEDとなることを確認します。これでモデルが利用できるようになります。 Gated Repos Statusの項目がACCEPTEDとなれば利用可能になります OpenShift AIでのモデルデプロイ 前提条件 シングルモデルサービング構築済み（前回の記事を参考にしてください） データ接続設定済み（以前の記事を参考にしてください） Hugging Face HubからモデルのダウンロードとS3へのアップロード OpenShift AIのモデルサービングはS3ストレージにモデルファイルを格納して、そこからモデルをデプロイするという流れになります。したがってHugging Face HubのMistral-7B-Instruct-v0.3をダウンロードしてAWSのS3にアップロードします。 どのような方法でアップロードしてもかまいませんが、今回はOpenShiftAIのワークベンチ機能を利用してアップロードする方法について解説します。 別の方法としてはLLMをS3へ簡単にアップロードするツールが存在するので、公式のツールではありませんが、ぜひ確認してみてください。 https://github.com/opendatahub-io-contrib/odh-tec それでは最初にモデルのダウンロードをするために、適当なワークベンチを作成します。モデルデータを保存するS3とのデータ接続と連携するのと、大きなファイルをダウンロードするのでPVのサイズを40GiBに設定してください。 LLMダウンロード用ワークベンチ作成。PVのサイズを40GiBに設定し、モデルを保存するS3ストレージへのデータ接続を設定する。 次にHugging Face Hubの認証を行います。ワークベンチのJupyterLabでhuggingface_hubのライブラリをインストールしてください。 !pip install huggingface_hub インストールできたらHugging Face Hubへログインを行います。tokenにはHugging Face Hubのアクセストークンの値を入れてください。 from huggingface_hub import login login(token='<メモしたトークンの値>') これによりHugging faceからダウンロードが可能になります。次にHugging Face HubからMistral-7B-Instruct-v0.3をダウンロードします。 from huggingface_hub import snapshot_download snapshot_download(repo_id="mistralai/Mistral-7B-Instruct-v0.3", local_dir="./models") ダウンロードが完了したら、データ接続したS3ストレージへアップロードします。 import os import boto3 import botocore aws_access_key_id = os.environ.get('AWS_ACCESS_KEY_ID') aws_secret_access_key = os.environ.get('AWS_SECRET_ACCESS_KEY') endpoint_url = os.environ.get('AWS_S3_ENDPOINT') region_name = os.environ.get('AWS_DEFAULT_REGION') bucket_name = os.environ.get('AWS_S3_BUCKET') if not all([aws_access_key_id, aws_secret_access_key, endpoint_url, region_name, bucket_name]): raise ValueError("One or data connection variables are empty. " "Please check your data connection to an S3 bucket.") session = boto3.session.Session(aws_access_key_id=aws_access_key_id, aws_secret_access_key=aws_secret_access_key) s3_resource = session.resource( 's3', config=botocore.client.Config(signature_version='s3v4'), endpoint_url=endpoint_url, region_name=region_name) bucket = s3_resource.Bucket(bucket_name) def upload_directory_to_s3(local_directory, s3_prefix): num_files = 0 for root, dirs, files in os.walk(local_directory): for filename in files: file_path = os.path.join(root, filename) relative_path = os.path.relpath(file_path, local_directory) s3_key = os.path.join(s3_prefix, relative_path) print(f"{file_path} -> {s3_key}") bucket.upload_file(file_path, s3_key) num_files += 1 return num_files model_dir = "./models" s3_model_dir = "models/mistral" upload_directory_to_s3(model_dir, s3_model_dir) print(f"{model_dir} has been uploaded to {s3_model_dir}")  これによりS3ストレージにLLMをアップロードできます。 S3にアップロードされたLLMのファイル LLMのデプロイ S3にLLMが保存されたので、そのLLMをOpenShiftAIにデプロイします。前回の記事のシングルサービング形式を選択してモデルをデプロイできる状態にしてください。 以下のようにデプロイ設定してください： Model deployment name：test-llm Serving runtime：vLLM ServingRuntime for KServe Number of model server replicas to deploy：1 Model server size：Small Accelerator：NVIDIA GPU Number of Accelerators：1 Make route： Token authentication： Service account name：test-token Connection：モデルが保存されているデータ接続 Path：models/mistral Additional serving runtime arguments：–max-model-len=8192 vLLMのエンジンに渡す引数を設定できます。 デフォルトのままだとメモリが不足してエラーが出るので出力するトークン数を制限します。 詳しくはドキュメント参照してください。 https://docs.vllm.ai/en/latest/serving/engine_args.html デプロイ設定 Statusに がついたらデプロイ完了です。「Internal and external endpoint details」を押下するとAPIのエンドポイントを確認できます。Externalの方にAPIを送ります。 デプロイされたLLM。ステータスに がつけばデプロイ完了。 APIのエンドポイント確認。urlが内部公開されているエンドポイントでExternalが外部公開されているエンドポイント。 またモデルの詳細を開くとAPIのトークンを確認できます。 モデルの詳細を開くとAPIトークンを確認できる APIの検証 デプロイしたLLMに対してAPIリクエストを送り、質問に対して回答することを検証します。 以下のコードを実行します。<APIエンドポイント>にはExternalの方のエンドポイントを入れ、<APIトークンの値>にはAPIトークンの値を入れてください。 import requests import json # URLとヘッダーの設定 url = "<APIエンドポイント>/v1/chat/completions" token = "<APIトークンの値>" headers = { "Content-Type": "application/json", "Authorization": f"Bearer {token}" } # リクエストボディの設定 data = { "model": "test-llm", "messages": [ {"role": "system", "content": "あなたは丁寧なアシスタントです.ユーザーからの質問に回答して下さい"}, {"role": "user", "content": "OpenShiftとは何ですか？"} ] } # POSTリクエストの送信 response = requests.post(url, headers=headers, data=json.dumps(data)) # レスポンスの表示 print(response) formatted_json = json.dumps(response.json(), indent=4, ensure_ascii=False) print(formatted_json) 実行した結果が以下になります。こちらの質問に対して回答してくれることが確認できます。 APIの実行結果。「OpenShiftとは何ですか？」という問いに対して、LLM APIが回答している。 おわりに LLMをデプロイしたことでLLM APIを利用できるようになりました。OpenShift AIを利用してぜひLLMサービスを展開してみてください。 参考 シングルモデルサービングの設定 https://docs.redhat.com/ja/documentation/red_hat_openshift_ai_self-managed/2.16/html/serving_models/serving-large-models_serving-large-models Hugging Face Hubのモデルダウンロード方法 https://huggingface.co/docs/transformers/ja/installation 前回の記事： OpenShift AIのシングルモデルサービング環境を構築してみた ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post OpemShift AIにLLMをデプロイしてみた first appeared on SIOS Tech. Lab .

PSSL に新卒入社しました神﨑です。 ６月から９月までの間、新卒研修の一環としてシステムのチーム開発を行っていました。作成したのは、旬の食材を用いたレシピサイトです。 私も含め計５名の新卒による開発体制で、個人での担当分野としては主に挿入するデータの加工等を行っていました。今回は、知識とデータの前処理等でとても苦労したので、書き残しておこうと思います。 はじめに レシピ検索＋買い物リスト作成アプリを作成しました。 自分の担当部分であるデータの前処理の作業は大部分は記事[1]を参考にしましたが、一部自分たちのシステムに合わせて改変しました。 今回のブログの内容では、楽天レシピから取得するデータのうち、材料名をカテゴリ化するために表記ゆれ等を統一した際に苦労した点等をまとめています。 記号と括弧の処理 取得したレシピデータ（料理に必要な材料）は、以下のように表記ルールなどが定まっていないため、前処理を行いました。 例えば、以下のように☆や■などの記号や（）などで補足説明が追加されているものなど形式が様々なものがありました。 #取得したレシピデータのうち、材料名の一部抜粋 ['なす', 'オクラ', '大根', 'めんつゆ（ストレート）', 'サラダ油'] ['茄子', 'ごま油', '☆生姜のすりおろし', '☆めんつゆ（３倍濃縮）', '☆水', 'ねぎ（小ねぎ等）'] ['ナス', 'サラダ油', 'ポン酢', '花かつお'] まず、材料名の前後にある記号や括弧を消去しました。 例　☆めんつゆ（３倍濃縮）　→　めんつゆ コードは、前述したように[1]の記事を参考にPythonで実装しました。 変更点として、正規表現で記号や空白、括弧、括弧内の文字をまとめて削除パターンとして指定してデータの変換を行いました。 delete_pattern = r'[\u25A0-\u25FF\u2600-\u26FF\uFF0A\u002A\u30FB\u3007]|' \ r'\([a-zA-Z]\)|＜[A-Z]＞|\b[A-Z]\)|\b[A-Z]\.|\b[A-Z] |\([A-Z]' 削除した結果、以下のようになりました。 懸念事項として括弧内にレシピの材料についての補足などが含まれる場合もありますが、今回は目をつぶります。 #取得したレシピデータのうち、材料名の一部抜粋 ['なす', 'オクラ', '大根', 'めんつゆ', 'サラダ油'] ['茄子', 'ごま油', '生姜のすりおろし', 'めんつゆ', '水', 'ねぎ'] ['ナス', 'サラダ油', 'ポン酢', '花かつお'] 表記ゆれ辞書の作成と変換 上記のレシピデータの出力結果から、材料名の一つである「なす」がなす、茄子、ナスなどの表記ゆれを確認したため、材料名について辞書を作成して表記を統一しました。 辞書の作成には、web上に公開されている食材図鑑等を参考に作成しました。 #辞書の抜粋 #見出し語、変換する単語 アスパラガス,アスパラガス,アスパラ,あすぱらがす,あすぱら さやいんげん,さやいんげん,インゲン,サヤインゲン,いんげん,モロッコいんげん,モロッコインゲン,モロッコいんげん,モロッコインゲン うど,うど,ウド,うど えだまめ,えだまめ,枝豆,エダマメ なす,なす,茄子,ナス,なすび,ナスビ,加茂なす,加茂ナス,加茂茄子,賀茂茄子,白茄子,白なす,白ナス,水ナス,水なす,米なす,米ナス,米茄子 変換した結果は以下のようになります。 #取得したレシピデータのうち、材料名の一部抜粋 ['なす', 'オクラ', '大根', 'めんつゆ', '油'] ['なす', 'ごま油', '生姜', 'めんつゆ', '水', 'ねぎ'] ['なす', '油', 'ポン酢', '鰹節'] 反省点 今回は、データの前処理に関してはデータ数を絞って最低限の実装に設定したおかげで、力業で変換しても事前に予定していた工数を大幅に超過することはありませんでしたが、工夫できた点は多々あったと考えています。 例えば、AIに判別させて表記ゆれを統一させたり、大学で少し触った自然言語処理などを使ってみるなど、アナログな手段ではない方法を採用したかったが、時間の見積もりが甘かったため挑戦できませんでした。 もし次回があるのならば、新しい技術を積極的に取り入れていきたいです。 参考 [1]Python 初学者が楽天APIを使って買い物リスト作成アプリを作った（データ加工編） https://qiita.com/yuuauuy1/items/5bb4a53ab15bde354297 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 新卒研修でのチーム開発におけるデータ加工を通して得られた知見について first appeared on SIOS Tech. Lab .

現在クラウドネイティブ技術が発展する中で、様々なアプリケーションの基盤としてKubernetesを中心としたプラットフォームが重要な役割を果たしています。 特に OpenShift、Rancher、VMware Tanzu  などのソリューションは、企業のKubernetes環境を支える主要な選択肢として注目されています。 本記事では、それぞれの特徴や違いを分かりやすく解説します。 1. OpenShift（オープンシフト）とは？ 概要 OpenShift は Red Hat が提供する エンタープライズ向けの Kubernetes プラットフォーム です。 Kubernetes の上に独自の管理機能を加えた「 Red Hat OpenShift Container Platform 」が代表的なソリューションです。 特徴 エンタープライズ向けの機能が充実 OpenShift は Kubernetes をベースにしつつ、開発者や運用者向けのツールが豊富に用意されています。 Red Hat Enterprise Linux（RHEL）との親和性 OpenShift は Red Hat Enterprise Linux CoreOS（RHCOS） を標準OSとして採用しており、Red Hat のエコシステムと深く統合されています。 セキュリティとポリシー管理が強化 デフォルトで Role-Based Access Control（RBAC）やセキュリティ強化 の仕組みが組み込まれており、企業向けのコンプライアンス要件を満たしやすくなっています。 管理コンソールが充実 Web UI や CLI を使って直感的に Kubernetes クラスタを管理でき、開発者と運用チームの負担を軽減します。 こんな人におすすめ エンタープライズ向けの本番環境で Kubernetes を運用したい セキュリティやサポートが充実した Kubernetes 環境を構築したい Red Hat のエコシステムを活用したい 2. Rancher（ランチャー）とは？ 概要 Rancher は SUSE が提供する マルチクラウド対応の Kubernetes 管理プラットフォーム です。 Kubernetes クラスタの統合管理や、オンプレミス・クラウド環境を問わず Kubernetes を一元的に運用できる点が強みです。 特徴 異なる Kubernetes クラスタを一元管理 RKE2 と呼ばれるKubernetesのディストリビューションをベースとしてクラスタ管理やAWS EKS・Azure AKS・Google GKE などの マネージドKubernetes も統合管理できます。 軽量で導入が容易 Rancher は 比較的軽量なアーキテクチャ で、シンプルに Kubernetes 環境を構築できます。 将来的にマルチクラスタ管理を視野に入れた、小規模な状態からの導入をしやすいのも特徴です。 エッジコンピューティングに最適 Rancher を提供しているSUSEは、軽量な Kubernetes ディストリビューションである K3s の開発元でもあります。 マルチクラスタ管理が基本となるエッジコンピューティングや IoT での Kubernetes 運用にも強みを持っています。 GUIベースのシンプルな管理 Kubernetes の運用を GUI でシンプルに行いたい場合、Rancher は適した選択肢となります。 こんな人におすすめ 複数の Kubernetes クラスタを統合管理したい シンプルで軽量な Kubernetes 運用を目指したい エッジコンピューティングや IoT 向けの Kubernetes を利用したい 3. VMware Tanzu（タンズ）とは？ 概要 VMware Tanzu は VMware が提供する Kubernetes ベースのプラットフォーム です。 従来の VMware vSphere 環境と Kubernetes を統合 することで、仮想マシンとコンテナの両方を管理しやすくするのが特徴です。 特徴 VMware vSphere との統合が強力 Tanzu は vSphere を利用する企業にとって Kubernetes を既存インフラに統合しやすい のが最大のメリットです。 VMware の運用管理スキルを持つチームにとって、導入のハードルが低くなります。 Tanzu Kubernetes Grid（TKG） Tanzu は Tanzu Kubernetes Grid（TKG） という Kubernetes ディストリビューションを提供しており、オンプレミス・クラウド両方で統一された運用が可能です。 Kubernetes を仮想マシン環境と併用できる Tanzu は 仮想マシンとコンテナのハイブリッド環境 を構築するのに適しており、段階的なクラウドネイティブ化を進める企業にとって魅力的な選択肢です。 こんな人におすすめ VMware vSphere をすでに利用している 仮想マシンとコンテナを統合的に管理したい まとめ どのプラットフォームも Kubernetes を活用したコンテナ運用を支援しますが、それぞれ得意とする領域が異なります。 OpenShift → エンタープライズ向け Kubernetes、Red Hat 製品と統合 Rancher → マルチクラウド対応、軽量で導入が容易 VMware Tanzu → vSphere と統合、仮想マシンと Kubernetes を併用 今回は主要な３つのKubernetes管理プラットフォームの概要と特徴について記載しましたが、自社の環境や運用ニーズに合わせてプラットフォームの選定の一助となれば幸いです。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post クラウドネイティブ環境を支える主要コンテナプラットフォームの特徴解説 first appeared on SIOS Tech. Lab .

こんにちは、サイオステクノロジーの遠藤です。 AIの活用が進む中で、「もっと便利に使えたらいいのに」と思ったことはありませんか？ たとえば、AIがリアルタイムで情報を検索できたり、計算が得意だったり、画像を生成したりできたら便利ですよね。 そんな機能をDifyで簡単に実現できるのが「ツール機能」です。この記事では、Difyのツール機能について、初めての方にもわかりやすく解説していきます！また実際にGoogle検索を利用したリアルタイムに天気の情報を提供できるAIエージェントを作成してみるところまで行っていきます。では始めていきましょう！ Difyのツール機能とは？ ツール機能を使うと、DifyのAIが外部の情報にアクセスしたり、特定の処理を実行できるようになります。具体的には、 ネット検索 ：最新の情報を取得できる 科学計算 ：複雑な計算を素早く処理 画像描画 ：テキストから画像を生成 といった機能をAIに持たせることができます。 Difyでは、これらのツールを大きく2種類に分けています。 ファーストパーティツール Difyが標準で提供するツール すぐに使えて設定も簡単 カスタムAPIツール 自分で用意したAPIをツールとして組み込める OpenAPI/SwaggerやOpenAIプラグイン規格に対応 つまり、「すぐに使いたいならファーストパーティツール」、「自分のシステムと連携したいならカスタムAPIツール」と覚えておくといいでしょう。 今回はファーストパーティーツールを使用してGoogle検索を利用し、リアルタイムに天気の情報を提供できるAIエージェントを作成してみます！ ツールを使うと何ができる？ Difyのツール機能を活用すると、AIアプリをより高度に進化させることができます。 たとえば、 エージェント型アプリ にツールを組み合わせることで、タスクの推論・分解・実行をAIが自動で行う。 外部システムとの連携 が可能になり、AIがコードを実行したり、特定の情報にアクセスしたりできる。 これにより、「AIがただの質問応答をするだけ」から「実際に作業をこなす」レベルまで発展させられます。 ツール機能を使ってお天気エージェントを作成してみる では実際に、お天気エージェントを作成してみましょう。 まず、Difyの画面上部から「ツール」タブを選択して「Google」ツールを選択しましょう 続いて認証するボタンを押します。 続いてGoogle検索を行うためにSerpAPIキーの取得を行います。取得方法のボタンを押しましょう。 SerpAPIにアカウント登録を行っていきます。私はGoogleでサインインを行いました。 SerpAPIでアカウント登録を行う際には登録したGoogleアカウントへのメール認証と電話番号での認証が必要となります。また、フリープランでの登録だと、ひと月あたり100件しか検索できないのでリクエストを送りすぎるとすぐに使用できなくなってしまうので注意が必要です。 SerpAPIにログインできたら、左のタブから「Api Key」を選択し、Private API Keyを取得しましょう。取得が出来たらDifyの画面に戻ってSerpAPI keyを設定して準備完了です！   ではここからはお天気エージェントの作成に取り掛かりましょう！「スタジオ」タブから「最初から作成」を選択します。 作成画面が表示されたら、アプリの種類を「エージェント」、アプリのアイコンと名前を「Google検索を利用したお天気エージェント」としておきます。 アプリの作成画面に入ったら、ツールの「追加」を選択します。 画面左にツール追加画面が出てくるので、「GoogleSearch」を選択して「追加」を押します。 完了したら、ツールにgoogle_searchが追加されます。 その後手順に以下の文章を設定しましょう。 あなたはGoogle検索を利用して天気の情報をユーザーに対して答えるエージェントです どこの地域の天気情報を求められているのかわかるまでは絶対にgoogle_searchツールは使用しないでください ここまでできれば設定は完了です！左のプレイグラウンドから正しく動作しているか確認しましょう。 「天気を教えて」という質問を投げてみます。 そうすると、手順に書いてあるとおり、場所の確認を行ってくれました。 ログの詳細を見ても、ツールを使用せずに回答文だけを作ってくれているようです。 続いて「八王子の天気を教えて」という質問を送ってみます。 この場合は、回答の上の方に「使用済み google_search」と書いてあるように検索をかけてリアルタイムのお天気を取ってきてくれました！ ログを見てみても、しっかりgoogle_searhツールを使用してくれていることがわかります。 まとめ 今回はDifyのツール機能とはなにかの解説と、実際にファーストパーティツールを利用してお天気AIエージェントを作成する方法について確認しました。DifyはポチポチGIU上からボタンを押していくだけでAIアプリが作成できちゃうので本当にすごいですね。 今回はツール機能の中でも「ファーストパーティツール」を利用したアプリの構築方法をご紹介しましたが、自分で用意したAPIをツールとして組み込める「カスタムAPIツール」の方もまとめてブログにしようと考えているので、そちらも合わせて読んでいただけると喜びます！ ではまた～     ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Dify入門ガイド：「ツール機能」を利用してGoogle検索ができるAIエージェントを開発しよう！ first appeared on SIOS Tech. Lab .

はじめに こんにちはサイオステクノロジーの小野です。 以前の記事 でOpenShift AIのモデルサービング機能を利用してAIモデルを推論APIとして提供する方法を解説しました。今回はOpenShift AIのモデルサービング機能を利用してLLMをデプロイする方法について解説します。 OpenShift AIを利用したLLMデプロイ OpenShift AIはシングルモデルサービング環境を構築することで公開LLMをデプロイすることが可能になります。 公開LLMとは LLMをはじめとしたAIのモデルは公開されて自由にダウンロードできるものがあります。 それらのモデルは利用規約やライセンスに従う限り自由に利用することが可能です。 KServe KServeとはKubernetes上で機械学習モデルを推論・生成サービスとして提供するためのソフトウェアです。KServeはKnativeとIstioを利用して構築されてます。Knativeはモデルをデプロイ、管理するために利用され、IstioはモデルをAPI提供するために利用されます。 vLLM OpenShift AIでデプロイするモデルのランタイムとして vLLM ServingRuntime for KServe があります。 vLLMとはLLMの推論およびサービングを行うためのオープンソースライブラリです。トークン数やメモリ管理設定を行うことができます。また、他のサービングライブラリと比較して高速に推論ができる特徴があります。 OpenShift AI構築 モデルサービングの種類 OpenShit AIでAIモデルをデプロイするには二つの手法があります。一つがマルチモデルサービング形式です。これは、比較的中小規模のAIモデルをデプロイする際に使われます。もう一つはシングルモデルサービング形式です。これは、LLMのような大規模なモデルをデプロイする際に使われます。今回はLLMをデプロイするのでシングルモデルサービングの構築を行います。 必要な前提条件 GPU設定（詳しくは過去の記事を参照してください https://tech-lab.sios.jp/archives/44040 ） Node Feature Discovery Operator NVIDIA GPU Operator 使用インスタンスタイプ：g6.xlarge OpenShift AI：2.16 OpenShift Serverless：1.35.0 OpenShift Service Mesh：2.6.4-0 Red Hat – Authorino (Technical Preview)：1.1.1 デプロイしたLLMサーバーに認証機能をつける場合必須です OpenShift AIでのシングルモデルサービング環境構築 シングルモデルサービングオペレータインストール シングルモデルサービング形式のモデルサーバーを構築するにはOpenShift AIのクラスターを作成する前に3つのオペレータをインストールする必要があります。それぞれのリソースはOpenShiftクラスター構築時に自動的に作成されます。 Authorinoオペレータインストール Operator > OperatorHubでAuthorinoと検索します。「Red Hat – Authorino (Technical Preview)」を選択してインストールを押下します。 Red Hat AuthorinoのOperator 現時点（2025年2月6日）ではバージョン1.1.1をインストールします。 Authorino Operatorのインストール ステータスがSucceededになったらインストール完了です。 ステータスがSucceededになったらインストール完了 Serverlessオペレータインストール Operator > OperatorHubでOpenShift Serverlessと検索します。 「Red Hat OpenShift Serverless」を選択してインストールを押下します。 Red Hat OpenShift ServerlessのOperator 現時点（2025年2月6日）ではバージョン1.35.0をインストールします。 Serverless Operatorのインストール ステータスがSucceededになったらインストール完了です。 ステータスがSucceededになったらインストール完了 ServiceMeshオペレータインストール Operator > OperatorHubでOpenShift Service Meshと検索します。 「Red Hat OpenShift Service Mesh」を選択してインストールを押下します。 Red Hat OpenShift Service MeshのOperator 現時点（2025年2月6日）ではバージョン2.6.4-0をインストールします。 Service Mesh Operatorのインストール ステータスがSucceededになったらインストール完了です。 ステータスがSucceededになったらインストール完了 OpenShift AIオペレータインストール OpenShift AIオペレータのインストールは 以前の記事 を参考にして下さい。今回はバージョン2.16.0をインストールします。 Red Hat OpenShift AIのOperator。今回はバージョン2.16.0を利用する。 OpenShift AIのCR設定 今回はシングルモデルサービング形式の構築をするのでKServeをインストールします。 以下のようにDataScienceClusterのコンポーネントを設定します： spec: components: codeflare: managementState: Managed dashboard: managementState: Managed datasciencepipelines: managementState: Managed kserve: managementState: Managed serving: ingressGateway: certificate: type: OpenshiftDefaultIngress managementState: Managed name: knative-serving kueue: managementState: Managed modelmeshserving: managementState: Managed modelregistry: managementState: Removed registriesNamespace: rhoai-model-registries ray: managementState: Managed workbenches: managementState: Managed trainingoperator: managementState: Removed trustyai: managementState: Managed DataScienceClusterのコンポーネント設定 DataScienceClusterのステータスがPhase：Readyになったら作成完了です。 ステータスがPhase：Readyになったら作成完了 DataScienceProject作成 DataScienceCluster作成が完了したら、OpenShift AIを開いてDataScienceProjectを作成してください。 以前の記事 を参考してください。 シングルモデルサービングサーバ作成 DataScienceProjectが作成できたら、Modelsの項目に移動してください。 シングルモデルサービングの環境が構築できているとSigle-model serving platformの項目があります。これを選択します。 Data Science ProjectのModelsにSingle-model serving platformの項目ができる 右上に「Sigle-model serving enabled」と表示されればシングルモデルサービングのデプロイが可能になります。 右上に「Sigle-model serving enabled」と表示されればシングルモデルサービングが可能になる おわりに 以上の操作により、OpenShift AIにLLMをデプロイする準備が整いました。次回は実際にLLMをデプロイしてAPI利用するところをお見せします。 参考 シングルモデルサービングの設定 https://docs.redhat.com/ja/documentation/red_hat_openshift_ai_self-managed/2.16/html/installing_and_uninstalling_openshift_ai_self-managed/installing-the-single-model-serving-platform_component-install#About-the-single-model-serving-platform_component-install KServeの自動インストール https://docs.redhat.com/ja/documentation/red_hat_openshift_ai_self-managed/2.16/html/installing_and_uninstalling_openshift_ai_self-managed/configuring-automated-installation-of-kserve_component-install vLLM https://docs.vllm.ai/en/latest/index.html ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post OpenShift AIのシングルモデルサービング環境を構築してみた first appeared on SIOS Tech. Lab .

こんにちは、サイオステクノロジーの織田です。今回はDifyでワークフローを構築する方法、ワークフローで使えるブロックの紹介を行っていきます。Difyをまだ導入できていない方は コチラ を参考にやってみてください！ ワークフローの構築方法 Difyで生成AIツールを作成する際、「チャットフロー」と「ワークフロー」の2種類の方法が使えます。チャットフローは簡単な操作で実装することができる反面、詳細な動作を指定することができません。一方、ワークフローは外部データを参照したり条件分岐を行ったりといったことをノーコードで設定することができます。 ワークフローは以下の写真の通り、いくつかのブロックをつなげることで構築します。このブロックそれぞれが「外部情報を参照する」「条件分岐をする」といった役割を分担し、１つのアプリとして機能します。 ブロックの紹介 それでは、ワークフロー中に組み込むことができるブロックを紹介したいと思います。 開始 開始ブロックは、ワークフローの先頭に配置するブロックです。このブロックを使うことで様々な条件でワークフローを開始させられます。例えば、「ユーザがクエリを入力したとき」「毎朝９時になったら」などの条件を設定できます。 どのようなフローを作る際にも必ず最初に配置しましょう。 LLM LLMブロックはGPTやGeminiといったLLMを呼び出すことのできるブロックです。このブロックを使うと、Difyに登録したAIが入力された情報をもとに文章を作ったり、質問に答えたり、情報を要約したりします。AIにどのようなプロンプトを渡すのかも、このブロックで指定することができます。 知識取得 知識取得ブロックを用いることで外部の情報を取り込むことができます。このブロックを使うには、まず事前にデータベースやテキストファイル、pdfなどの資料をDifyにナレッジとして登録します。そして知識取得ブロックで登録したナレッジを指定することで外部情報を読み込んだ上で回答生成をさせることができます。 知識取得を用いることで、LLM単体では応答できないような質問にも答えられるようになります。たとえば、社内規約や仕様書などのクローズドなドキュメントを参照して質問に回答が可能になります。 終了 終了ブロックはワークフローの最後に設置するブロックです。このブロックを設置することで出力文を表示させることもできます。開始ブロックと同じくどのようなフローを作る場合にも必ず最後に設置しましょう。 質問分類器 質問分類器は、ユーザーの質問を自動的に分類するブロックです。私が作成したフローでは、ユーザからの質問が富山県に関連があるか否かを判定させています。そして、判定の結果に応じて次に遷移するブロックが変化します。 このブロックを使うことで、ユーザの質問に応じて適切な処理を走らせることができます。分類条件の設定方法も簡単で、単に「富山県に関係する」とだけ書くだけでOKでした。 IF/ELSE IF/ELSEブロックを使うことで条件分岐を実装できます。例えば、以下ではユーザーからの入力に「富山」が含まれるか否かで条件分岐を設定しています。ユーザの入力に富山が含まれればIFに、含まれなければELSEにつながるブロックに遷移します。 こちらも質問分類器と同じく自然言語で条件を設定できます。また、「OOを含む」という条件以外にも、「XXを含まない」や「OOから始まる」というように色々な条件が設定可能になっています。 イテレーション イテレーションブロックは繰り返し処理のためのブロックです。このブロックを使うことで、同じアクションを複数回行うことができます。リスト内のデータ１つ１つについて同じ処理をしたり、指定した回数同じ処理をしたりといったことに使えます。 コード コードブロックは、PythonやJavaScriptなどのコードを実行するためのブロックです。他のブロックでは対応できない複雑なロジックや外部APIとの連携などを実現できます。たとえば、PythonやJavaScriptでリストを作成すれば、先述のイテレーションがより使いやすくできます。 テンプレート テンプレートブロックは、文字通りテンプレート（事前に用意した文章）を使うための文字列です。 使い方としては、以下のようにエラーメッセージの出力に使えます。また、変数とテンプレートを組み合わせることもできます。テンプレートを使うことで、出力の体裁を整えることができます。 最後に 今回はDifyのワークフロー構築について、利用可能なブロックの紹介も交えながら説明しました。Difyはノーコードで様々なAIツールが作成できる便利なプラットフォームです。今回紹介したブロック以外にも様々なブロックが用意されています。ぜひ色々なブロックを実施に触って、あなただけのオリジナルなワークフローを作ってみましょう！ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Dify入門ガイド：ワークフロー構築＆ブロック紹介 first appeared on SIOS Tech. Lab .

こんにちは、サイオステクノロジーの遠藤です。 生成AIが身近になり、多くの場面で活用されるようになってきました。しかし、「もっと自分の業務に特化した情報をAIに学習させられたら…」「社内のナレッジを活かして、より正確な回答を返せたら…」と思ったことはありませんか？ そんな課題を解決するのが RAG（Retrieval Augmented Generation） という技術です。RAGを活用すると、AIが外部のデータを検索し、その情報をもとに回答を生成できるようになります。これにより、一般的な知識に基づくだけでなく、最新の情報や専門性の高い内容、さらに社内独自のデータに基づいた回答にも対応可能になります。 本記事では、Difyを使ってRAGを簡単に構築する方法を紹介します。具体的な活用例として、就業規則をデータソースとして登録を行い、就業規則に関する質問に答えられるAIアシスタントを作成していきます。それでは、始めていきます！ RAG（Retrieval Augmented Generation）とは？ RAG（Retrieval Augmented Generation）は、事前学習済みの生成AI（例えばGPTなど）に外部データを組み合わせることで、より正確で文脈に沿った回答を生成する技術です。通常の大規模言語モデル（LLM）は、トレーニングデータに基づいて回答を生成しますが、その情報は最新ではなかったり、特定のドメイン知識が不足していることがあります。RAGは、この問題を解決するために、次の3つのステップで情報を処理します。 1. 検索（Retrieval） クエリに関連する外部データ（例えば、企業のナレッジベース、ドキュメント、データベースなど）を検索し、必要な情報を取得します。 2. 拡張（Augmentation） 取得した情報をもとに、言語モデルが回答を生成する前にデータを補強・整理します。これにより、ノイズの少ない、より関連性の高い情報をモデルに提供することが可能になります。 3. 生成（Generation） 補強された情報を活用して、言語モデルが回答を生成します。これにより、より最新かつ信頼性の高い応答が可能になります。 DifyでRAGを実装するには Difyでは ナレッジベース機能 を利用することで、企業の内部文書、FAQ、規格情報をデータソースとして登録し、大規模言語モデル（LLM）が問い合わせる際の情報源として利用することができるようになります。 Dify公式ドキュメントによるとナレッジベース機能を利用することで以下の利点があると挙げられています リアルタイム更新：ナレッジベースの内容はいつでも最新のものに更新することができ、モデルが最新情報を得られるようにします。 高精度：関連する文書を検索することで、LLMは実際の内容に基づき高品質な回答を生み出すことができ、誤情報を減らします。 柔軟性：開発者はナレッジベースの内容をカスタマイズでき、実際のニーズに合わせて知識の範囲を調整できます。 データは以下の３つの方法でアップロードすることが出来ます。いろいろな方法でデータが登録できるのは助かりますね。 長文コンテンツ（TXT、Markdown、DOCX、HTML、JSON、さらにはPDF） 構造化データ（CSV、Excelなど） オンラインデータソース（ウェブサイトからの情報収集、Notionからのデータ取得など） 実際にDifyでRAGアプリを作成してみる RAGに関する事前知識が身についたところで、ここからはDify上でRAGアプリケーションを作成してみましょう！今回は、「楽に」「わかりやすく」を目指して、Difyでできる一番簡単な方法でアプリケーションの作成を行っていきます。 まずはDifyアプリケーション上の「ナレッジ」タブをクリックします。押したら「ナレッジを作成」をクリックしましょう。 そうするとデータを登録する画面に入りますので、「テキストファイルからインポート」を選択してファイルのアップロードを行います。 今回は 厚生労働省が出している モデル就業規則 から解説部分を取り除き、就業時間などのサンプルデータを入れたRAGテスト用就業規則を利用します。 登録するドキュメント : RAGテスト用就業規則 ドキュメントが登録できたら「次へ」を押しましょう。 そうするとドキュメントをどんな設定で登録するかの画面に入ります。今回はインデックス方法から「経済的」を選択してドキュメントの登録を行います。「経済的」は無料で利用可能で、ドキュメント登録用のAIモデルの利用が必要無くなるので、初めてRAGを触る方におすすめです。他にもパラメータがいじれそうな箇所がいっぱいありますが、このあたりのパラメーターをいじると何が変わるの？だったり、インデックス方法で高品質を指定した場合はどのような設定が必要なの？といった話はDify RAG徹底解説のブログを別途作成しようと考えているので、そちらも合わせて読んでいただければと思います。 ナレッジの作成が完了したら、「ドキュメントに移動」をクリックします。 そうすると、ドキュメント一覧に移動することができ、しっかり登録したPDFが登録されたことが確認できます。 ここからは、実際にアプリケーションの作成に入って行きましょう。画面上部の「スタジオ」タブから「最初から作成」を選択します。 アプリの種類として「チャットボット」を選択し、アプリのアイコンと名前で「就業規則RAG」と入力します アプリの作成画面に入ったら、先ほどナレッジベースで登録したドキュメントをデータソースとして使用できるようにコンテキストの「追加」をクリックします。 そうするとポップアップが表示されるので、先程追加したPDFを選択して追加を押します。   それが完了したら、手順に以下のプロンプトを設定しましょう。 あなたはコンテキストに基づいてユーザーからの質問に回答するチャットボットです。 コンテキストに基づいて回答できない場合には「コンテキストに基づいて回答が出来ませんでした。質問を変更してください。」と返答してください。 ここまで完了したら、画面左のプレイグラウンドを利用してアプリが正しく動作しているか確認してみましょう。 まず試しに「Azure OpenAIについて教えて」というpdfに入っていない知識について質問してみました。 そうすると、プロンプトに設定したとおりに「コンテキストに基づいて回答が出来ませんでした。質問を変更してください。」と返答してくれました。   次にPDFに記載のある「有給休暇について教えて」と質問を投げてみます。 そうすると、しっかりPDFの内容を参照して回答を生成してくれ、引用として登録しているPDFが表示されていることを確認することが出来ました！ まとめ 今回のブログでは、RAGとは何か、そしてDifyを使って最もシンプルな方法でRAGアプリケーションを構築する手順を紹介しました。実装の中でも触れましたが、今後は「このパラメータを変更するとどんな影響があるのか？」や「精度を向上させるにはどうすればいいのか？」といった、より深掘りした内容もDify RAG上級編としてまとめていく予定です。そちらもぜひチェックしてみてください！ ではまた～     ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Dify入門ガイド：初心者でもわかる！簡単RAG構築 first appeared on SIOS Tech. Lab .

はじめに ども！Difyを学ぶ時間を捻出する日々な龍ちゃんです。入門ガイド第2弾です。第一弾では「 Dify入門ガイド：初期セットアップ 」と題して、検証環境にアクセスするまでを紹介していました。今回は、Difyで構築することができる基礎的なアプリの種類に関してまとめていきたいと思います。 Difyで作れるアプリ一覧 チャットボット エージェント テキストジェネレーター チャットフロー ワークフロー 初心者向けで特定要件に併せたアプリから、上級ユーザー向け（ちょっと開発者より）で要件に併せたアプリまで様々なアプリを作成することができます。ここでは、基礎的な使い方をする場合の説明を行っていきます。「ワークフロー」や「チャットフロー」については、上級的な使い方なので、できることよりも現状できないことを探したほうが良いです。 龍 今回はDifyをセットアップして5分以内でお試しできるアプリの紹介をしていきます！ チャットボット：対話型のAIアシスタント チャットボットでは、対話型AIアシスタントの構築が簡単に可能です。アプリを開いた時点で、チャットボットの構築自体は完成しています。追加で設定を加えることで、目的に沿ったアプリとして構築することができます。 設定できる項目としては、以下のようなパラメーターがあります。 設定できる項目 説明 モデル 使用することができるLLMを設定 変数 システムプロンプト中に使用することができる変数 チャットシステム中に変数を入力することができるフィールが作成される 手順 システムプロンプトとして、事前にシステムに与えることができるプロンプト コンテキスト 参照することができる知識（項目を追加することでRAGになる！） ビジョン 画像入力を可能とするか 手順はシステムプロンプトとして、チャットの返答に性格や制限を事前情報として与えることができます。（出力を英語限定にする・返答は10代の若者が使う言葉を多用して etc…） Dify内で特に注目な点としては、「コンテキスト」を使用したナレッジベースのチャットボット（RAG）になります。ナレッジとして文章等を登録することで、入力をもとにナレッジを検索して、検索した結果をLLMに対する入力に追加して送信します。 向いているアプリ AIチャットボット 特定の文章・データから情報を検索して回答を生成するチャットボット（FAQ） テキスト生成：特定のデータに基づいてテキストを生成 テキストジェネレーターでは、入力に基づいてテキストを生成するアプリの構築が可能です。右側の画面では、「変数」で設定した入力フィードが表示されます。チャットボットと異なり、自然な応答ではなくユーザーの入力をもとに生成を行うことが主眼となります。 設定できる項目 説明 モデル 使用することができるLLMを設定 変数 システムプロンプト中に使用することができる変数（必須） 接頭辞プロンプト システムプロンプトとして、事前にシステムに与えることができるプロンプト コンテキスト 参照することができる知識（項目を追加することでRAGになる！） ビジョン 画像入力を可能とするか 要約を作成する場合は、変数に要約したい文章を入れる「変数」を作成し、要約の条件を「接頭辞プロンプト」に入力しておきます。これで、フィールドに入力するだけで要約アプリを作成することができます。テキスト生成の方向性を「接頭辞プロンプト」で方向付けます。 向いているアプリ 要約アプリ SNS広報文章作成 エージェント：特定のタスクを自動化 エージェントでは、ユーザーの入力を起点に登録しているツールを使用してアクションを行う（自動化）ことができます。チャットボットと大きく異なる点は、ツールになります。ツールは、LLM単体では実現しない、ネット検索やいろいろの動作をまとめています。こちらをチャットボットから使用することで、LLM単体ではできなかった様々な動作を会話にプラスすることができます。 設定できる項目 説明 モデル 使用することができるLLMを設定 変数 システムプロンプト中に使用することができる変数（必須） 手順 システムプロンプトとして、事前にシステムに与えることができるプロンプト コンテキスト 参照することができる知識（項目を追加することでRAGになる！） ツール エージェントに使用を許可するツール（外部ツールなどのアクション） ビジョン 画像入力を可能とするか Dify起動時に使用することができるツールの中には、ネット検索・チャート作成・時刻取得などがあります。追加で認証することで、外部のツール（Trello・Google・DALL-E etc..）を使用することができ、追加で自作したツールを組み込むことも可能です。 ツールは以下の画面のように表示されるので、起動してみてみると良いかもしれません。 向いているアプリ 特定のタスクを自動化（Difyで提供されているツールでできる範囲） 終わり 以上、Difyで構築することのできるアプリケーションの種類について紹介してきました。チャットボット・テキストジェネレーター・エージェントと、それぞれのアプリケーションには特徴があり、目的に合わせて使い分けることで、効果的なAIアプリケーションを構築することができます。 今回紹介した、初期的なアプリはすべて「ワークフロー」で実装することができます。ですが、覚えることや設定する項目がグンと増えます。今回紹介したもので、満たされなかった場合は「ワークフロー」に移ることをお勧めします。 次回は、実際にRAGを作成する方法についてまとめます。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Dify入門ガイド：5分で作れる簡単アプリまとめ first appeared on SIOS Tech. Lab .

こんにちは、サイオステクノロジーの遠藤です。 今回は、生成AI開発でよく登場する「マルチモーダル」について解説します。このブログでは、まず概要を理解し、その後アプリケーションの作成を通じてより深い理解を目指していきます。それでは始めましょう！ マルチモーダルとは？ マルチモーダルとは 複数の形式（モード）を組み合わせて理解する仕組み のことです。 例えば、人間は普段からマルチモーダルな理解をしています。道を歩いていて信号機を見るとき、目で「赤信号だ」と認識し、同時に耳で信号機の音を聞いて、「今は渡っちゃダメだな」と判断します。これが「視覚」と「聴覚」という複数のモードを使った理解、つまりマルチモーダルな理解になります。 この考え方が生成AIにも使われています。 例えば、画像をアップロードして「これ何？」って質問すると、生成AIがその画像を見て説明してくれます。これは、生成AIが「画像」と「テキスト」という複数の情報を同時に扱うからこそできることとなっています。 マルチモーダルなアプリケーションを作成する 実際にマルチモーダルなアプリケーションを作成するには各社が出している生成AIモデルを利用することが必要となります。 生成AIのモデルは Google社が出しているGeminiやAnthropicが出しているClaudeなどなどいろいろな会社から出ていますが、今回はOpenAI社の提供するサービスを利用します。OpenAI社が出しているサービスのなかでも様々なモデルがあり、自然言語から画像を生成できるDALL・Eや音声からテキストへ変換できるWhisperなど、モデルごとにできることが大きく異なります。 今回のブログでは高性能なチャットモデルを利用できるChatGPTモデルを使用していきます。また、ChatGPTモデルは2022年から様々なバージョンが出ていて、進化を遂げてきています。 今回作成するアプリケーションの概要 概要 今回は以下の画像のようなアプリケーションの作成を行い、「テキスト」「画像」「動画」を理解して対話できるマルチモーダルアプリケーションを作成していきます。また、簡単にWebアプリケーションを構築できるStreamlitというフレームワークを利用して作成を行っていきます。   構築にあたって必要となるもの 今回、アプリケーションの構築をまでご自身で行いたい場合には、事前に以下の環境をご準備して頂く必要があります まずAzureが提供しているOpenAIのAPIを利用するため Azure Open AI のリソース GPT-4o-mini モデルのデプロイ が必要となります。 今回のブログで紹介するコードではAzure OpenAI用のクライアント作成するようなコードになっていますが、そこを書き換えていただければ、OpenAIが出しているAPIを叩く形にカスタマイズしていただくことも可能になっていると思われます。 また今回のコードはStremlitを利用していますので Python実行環境 が必要となります 段階を分けて理解する アプリケーションの実装をこれから行っていくのですが、 【STEP1】テキストを理解させる 【STEP2】画像を理解させる 【STEP3】動画を理解させる の三段階に分けて実装を行うことで理解を深めていきたいと思います。 【STEP1】テキストを理解させる テキストを理解させるための実装を行っていく前に、まずはAzure OpenAIのAPIを利用したリクエストの送り方について確認してみましょう。ChatGPTのAPIを使用するときには、生成AIに尋ねる内容をmessagesという配列に入れて上げる必要があります。 messagesは役割を表すroleと、具体的な尋ねる内容であるcontentから構成されています。生成AIにこちらの正しい意図を認識させるにはこのroleというものが大切になってきます。 roleにはsystem, user, assistantの3種類があります。 systemでは、モデルの振る舞いや性格を決定します。例えば、「タメ口で話して」とrole: systemで設定してあれば、タメ口で話すようになります。 今回のアプリケーションでは、例に設定してある「あなたは画像やテキストにも対応したアシスタントAIです」といった設定をrole : systemでしています。 userはユーザーからの指示や質問を表す役割があります。このroleで設定したcontentの中で尋ねたい内容を設定したり、画像を指定して渡したりといったことが出来ます。 assistantは今回はアプリケーションでは利用していませんが、モデルの応答を表す役割があります。使用方法としてはユーザーと生成AI間の対話履歴も理解させたい場合に、生成AI側の発言であることを示すために使用されます。   では実際に system: あなたは画像やテキストにも対応したチャットアシスタントです。すべての質問に日本語で返答してください。 user : マルチモーダルについて教えて を設定してリクエストを送ってみます。 そうするとレスポンスとして マルチモーダル（Multimodal）は、複数の種類のデータや入力方法を組み合わせて処理・解析・生成するアプローチを指します。 と返ってきました。これでテキストを理解できるアプリケーションの実装が完了しました。 【STEP2】画像を理解させる 続いて画像を扱えるようにアプリケーションを拡張していきます。ChatGPTAPIを利用して画像をリクエストとして送るには、 画像のリンクを渡す Base64でエンコードされた値を渡す の２つの方法があり、今回は２つ目の 「Base64でエンコードされた値を渡す」 を利用して実装していきます。 ここからはpythonコードベースで実装を確認していきます。具体的な実装は以下のようなコードになります。 # 画像をbase64にエンコードする def encode_image(image): return base64.b64encode(image.read()).decode("utf-8") ... # "type":"image_url"でbase64変換した画像を送信する base64_image = encode_image(uploaded_image) messages = [ {"role": "system", "content": "あなたは画像やテキストにも対応したチャットアシスタントです。すべての質問に日本語で返答してください。"}, {"role": "user", "content": [ {"type": "text", "text": user_input}, {"type": "image_url", "image_url": {"url": f"data:image/png;base64,{base64_image}"}} ]} 手順としては、まずは、画像をbase64形式に変換を行います。そしてmessages配列のなかに、base64のデータを入れて渡して上げることでAPIで画像を扱うことができるようになります。注意事項としては、先程までのテキストの扱いではcontentの中でそのままテキストを扱っていたのですが、画像を送る場合には type付けを行い、image_urlというtypeを指定する必要がある点 が注意点となります。 では画像を含めたリクエストについて確認してみましょう。以下のリクエストを送ってみます。 system : あなたは画像やテキストにも対応したチャットアシスタントです。すべての質問に日本語で返答してください。 role :user この画像をもとに物語を考えて + ファンタジーチックな空に浮いている島の画像 そうするとしっかりファンタジーチックな空に浮いている島を認識して以下のようなレスポンスが返ってきました！ 物語: 空中の王国 かつて、 天空に浮かぶ壮大な王国 「アエリオン」 が存在しました。 この王国は、 雲の上に築かれた切り立った岩の上にあり、透き通る滝が流れ落ちる美しい景色が広がっています。 王国の人々は、その美しさを愛し、力強く繁栄していました。 しかし、彼らの幸せは、ある日突然の危機にさらされます。 ある夜、暗い影が空を覆い、不気味な雲が王国を包み込みました。 恐ろしいドラゴン、 「ヴォルクラ」が現れ、王国の秘宝を求めて攻撃を仕掛けました。 人々は恐怖に震え、 滝の音すら聞こえなくなりました。 王国の王子、アレンは、勇気を奮い立たせ、王国を救う決意をしました。 彼は祖父から授けられた古の剣を手に取り、ドラゴンに立ち向かうための旅に出ることにしました。 旅の途中で、アレンは不思議な生き物たちと出会い、彼らから知恵や力を授かります。 その中には、天空を舞う幻の鳥「フェアリーブレード」 がおり、 彼女はアレンに、ドラゴンの弱点を教えてくれました。ドラゴンは月の光を浴びると力を増し、昼間には眠っていることが多いという情報です。 アレンは仲間たちと共に、 計画を練り、 ドラゴンが月明かりで力を失う瞬間を狙うことにしまし た。夜が訪れ、彼は果敢に陰に隠れ、 ドラゴンが居る巣へと近づいていきます。 激しい戦いの末、アレンは見事にドラゴンを打ち倒しました。 平和が戻ったアエリオンでは、王子の勇気を称える祭りが開かれました。人々は再び笑顔を取り戻 し、空中の王国はさらなる繁栄を迎えました。 アレンは、自分の冒険を通じて友情や勇気の大切さを学び、未来の王として王国を支えていくことを誓いました。 そして、王国の上空には、いつまでも流れる壮麗な滝と青空が広がり、 アエリオンは永遠に美しく輝き続けるのでした。 【STEP3】動画を理解させる 動画をリクエストで扱う方法を…  と進んで行きたいのですが、実は今回使用しているGTP-4o-miniのAPIでは直接動画を扱うことが出来ません。だからと言って動画を理解させれないわけではありません。要素に分割することで生成AIに理解させることが出来ます。 動画を構成する要素 動画は、連続した静止画が高速で切り替わることで動いているように見える要素である「映像」と、環境音や話し声とした「音声」から構成されています。 より細かく分解していくと、映像は連続した静止画が高速で切り替わっていると言えるので、複数の画像に分割できると言えます。 また、音声についてですが例えば、人の話している内容等であれば、文字起こしでテキストにすることが出来ます。また環境音など文字起こしできないものであっても、一部の生成AIを利用すれば状況を書き起こし、シチュエーションをテキストにすることが出来ます。 このように動画を要素に分割させて行くことで生成AIに動画を理解させることができるようになります！ちなみにOpenAI社的には今後直接音声や動画をAPIで扱えるようにしていくつもりのようですので、このような分割したりの作業は将来的には必要なくなるかもしれません。 ここまで説明させていただきましたが、今回は準備の関係で音声をテキスト変換して渡す機能までは入れていません。ブログの最後にコードの紹介もするので、例えば、OpenAI社のWhisperモデルを使用して文字起こしを行ったものも渡す機能を追加する変更を加えるなどして音声も認識できるように対応箇所を広げるなどしてさらにマルチモーダルアプリケーションへの理解を深めていただければと思います。 実装を確認 では画像で行ったのと同じようにコードベースでの実装を確認してみましょう。 まず、extract_frames関数を利用してbase64変換したフレーム（静止画）の配列にしています。 そして、map関数で動画を200フレームごとに受け渡しするようにしています。 # 動画をフレームに分割する def extract_frames(video_bytes): with tempfile.NamedTemporaryFile(delete=False) as temp_video_file: temp_video_file.write(video_bytes) temp_video_file_path = temp_video_file.name video = cv2.VideoCapture(temp_video_file_path) base64_frames = [] while video.isOpened(): success, frame = video.read() if not success: break _, buffer = cv2.imencode(".jpg", frame) base64_frames.append(base64.b64encode(buffer).decode("utf-8")) video.release() print(len(base64_frames), "frames read.") return base64_frames ... # AOAIへ200フレームごとにbase64変換した画像を渡す base64_frames = extract_frames(uploaded_video.read()) messages = [ {"role": "system", "content": "あなたは画像やテキストにも対応したチャットアシスタントです。すべての質問に日本語で返答してください。"}, {"role": "user", "content": [ {"type": "text", "text": user_input}, *map(lambda x: {"image": x, "resize": 240}, base64_frames[0::200]), ]} ] ここで、動画や画像を扱うときの注意点です 生成AIを利用するときにはテキストを分割した最小単位であるトークン数に応じてお金がかかるようになるのですが、動画や画像を行っているbase64変換を行ったデータはデータ数が大きいためたくさんのトークンが必要となります。例えば、この後実際に送ってみる動画のリクエストには一リクエストあたり11.5円ほどかかります。コードの中で200フレームごとに受け渡しする処理を入れている理由は、このトークン数への対策になっていて、動画を理解させるためには必ずしも全てのフレームを送って理解させる必要はなく、少し飛ばし飛ばしで見ても生成AIは理解できるようなっています。 では実際に動画を含めたリクエストを送ってみます。 system : あなたは画像やテキストにも対応したチャットアシスタントです。すべての質問に日本語で返答してください。 user : この動画を説明してください + ゴールデンレトリバーが飼い主と遊んでいる動画 document.createElement('video'); https://tech-lab.sios.jp/wp-content/uploads/2025/01/dog.mp4   返ってきたレスポンス この動画では、緑豊かな公園の中で、犬と人間が一緒に散歩している様子が映し出されています。犬はゴールデンレトリバーのようで、飼い主のそばで楽しそうに歩いています。周囲の自然や明るい日差しが感じられ、ほのぼのとした雰囲気が伝わってきます。また、飼い主が犬とコミュニケーションをとりながら進んでいる様子も見られます。全体的に、愛情と絆を感じさせるシーンです。 無事にゴールデンレトリーバーを認識したりだとか、飼い主とコミュニケーションを取っているなど動画を認識できることが確認できました！ 今回作成したアプリケーションのリポジトリ 今回作成したアプリケーションですが、以下のリポジトリで公開しております。 https://github.com/Fumiya-Endo-sti/multi-modal-application READMEに構築方法等が乗っているので自分で動かしてみたい方はその手順に沿って動かして見ていただければと思います。 まとめ 今回は、マルチモーダルを理解するために、アプリケーションの作成を通して理解を深めていきました。今後もマルチモーダルはより多くの場面で採用されて行くと思われますので、これらの進歩に注目し常に最新の情報を取り入れていくことが大切だと感じています。 最後に宣伝になりますが、弊社では生成AIのアプリケーションの開発や導入などのサポートを行っております。提供できるソリューションについて以下のサイトに記載されておりますので、ご興味がございましたらご一読いただければと思います。 https://nextech-solutions.sios.jp/genai/ ではまた～ 参考サイト https://platform.openai.com/docs/guides/vision https://cookbook.openai.com/examples/gpt_with_vision_for_video_understanding https://zenn.dev/headwaters/articles/a3f87b54c25743# ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【生成AI】マルチモーダルってなに？アプリケーションの作成を通じて理解しよう！ first appeared on SIOS Tech. Lab .

こんにちは、サイオステクノロジーの遠藤です。 今回はAzureのBicepを利用してCosmosDBとFunctionsのリソースを作成し、FunctionsのEntra IDに対してCosmosDBの操作が行えるロールを付与する方法について確認します。 Bicepにまだ慣れていない自分としてはいくつかハマったポイントがあったのでその部分に焦点を当てて解説していければと思います。 Azureのコントロール プレーンとデータ プレーン まず今回の本題に入る前にコントロール プレーンとデータ プレーンについて確認します。 Azureの操作は コントロール プレーン と データ プレーン の２つのカテゴリに分類することが出来ます。 まずコントロールプレーンについてですが、サブスクリプション内のリソースを管理するために使用します。 そしてデータ プレーンは、リソースの種類のインスタンスによって公開される機能を使用するために使用します。 Azureが掲載している例だと、 コントロール プレーンを使用して仮想マシンを作成します。 仮想マシンを作成した後は、リモート デスクトップ プロトコル (RDP) などのデータ プレーン操作を通じて、仮想マシンと対話します。 コントロール プレーンを使用してストレージ アカウントを作成します。 ストレージ アカウント内のデータの読み取りと書き込みを行うには、データ プレーンを使用します。 コントロール プレーンを使って Azure Cosmos DB データベースを作成します。 Azure Cosmos DB データベースのデータに対してクエリを実行するには、データ プレーンを使います。 といった形で、リソースの作成といった操作ではコントロールプレーンが必要になり、実際に作成したリソースに対してデータ更新をかけるといった操作を行うにはデータプレーンのロールが必要になります。 今回は、FunctionsのアプリケーションからCosmosDBに対してデータの書き込みを行うといったシチュエーションを考えているため、Functionsに対してCosmosDBの操作を行えるデータプレーンのロールを持たせるといったことを行おうとしています。 ここからが私が少しハマったポイントなのですが、コントロールプレーンはAzureポータル上のRBACで付与することが可能なのですが、少なくとも私が試した限りはCosmosDBのデータプレーンの権限をAzureポータル上から付与したり確認が出来なさそうといったところです。 Microsoft Entra ID を使用して Azure Cosmos DB アカウントのロールベースのアクセス制御を構成する 　の公式ドキュメントでも Q. Azure portal からロールの定義とロールの割り当てを管理することはできますか。 A. ロール管理の Azure portal サポートはまだ利用できません。 となっているので、2025/01/30現在は出来なさそうです。 今回付与するロール CosmosDBで使用できる組み込みロールには以下の２つのロールが用意されています。 ID 名前 含まれるアクション 00000000-0000-0000-0000-000000000001 Cosmos DB 組み込みデータ リーダー Microsoft.DocumentDB/databaseAccounts/readMetadataMicrosoft.DocumentDB/databaseAccounts/sqlDatabases/containers/items/readMicrosoft.DocumentDB/databaseAccounts/sqlDatabases/containers/executeQueryMicrosoft.DocumentDB/databaseAccounts/sqlDatabases/containers/readChangeFeed 00000000-0000-0000-0000-000000000002 Cosmos DB 組み込みデータ共同作成者 Microsoft.DocumentDB/databaseAccounts/readMetadataMicrosoft.DocumentDB/databaseAccounts/sqlDatabases/containers/*Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/items/* データベースの書き込みを行うためには2つ目の「Cosmos DB 組み込みデータ共同作成者」のロールが必要となります。 Bicepを作成する 今回は以下のような形のディレクトリ階層でbicepコードを作成しました。 bicep-sample ├── modules │ └── app │ └── func.bicep │ └── database │ └── cosmos.bicep └── main.bicep まずCosmosDBをデプロイするためのモジュールです。 modules/database/cosmos.bicep param location string param accountName string param databaseName string param containerName string resource cosmosDbAccount 'Microsoft.DocumentDB/databaseAccounts@2024-11-15' = { name: accountName location: location properties: { databaseAccountOfferType: 'Standard' locations: [ { locationName: location failoverPriority: 0 isZoneRedundant: false } ] capabilities: [ { name: 'EnableServerless' } ] } } resource database 'Microsoft.DocumentDB/databaseAccounts/sqlDatabases@2024-11-15' = { name: databaseName parent: cosmosDbAccount properties: { resource: { id: databaseName } } } resource container 'Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers@2024-11-15' = { name: containerName parent: database properties: { resource: { id: containerName partitionKey: { paths: [ '/user_id' ] kind: 'Hash' } } } } output accountName string = cosmosDbAccount.name 次にfunctions用のモジュールですね。こちらは Functionsをデプロイするクイックスタート をベースに作成しました。 cosmosRoleDefinitionIds　以下からロールの付与処理を行っております。ロールを付与するには Microsoft.DocumentDB databaseAccounts/sqlRoleAssignments 　を利用することで付与することが出来ます。このあたりもコントロールプレーンとは書き方が違い、最初は書き方がわからなかったりとハマりやすいポイントだと感じました。 modules/app/func.bicep param location string @description('The name of the function app that you wish to create.') param appName string = 'fnapp${uniqueString(resourceGroup().id)}' @description('Storage Account type') @allowed([ 'Standard_LRS' 'Standard_GRS' 'Standard_RAGRS' ]) param storageAccountType string = 'Standard_LRS' param cosmosDBAccountName string param runtime string = 'node' var functionAppName = appName var hostingPlanName = appName var storageAccountName = '${uniqueString(resourceGroup().id)}azfunctions' var functionWorkerRuntime = runtime resource storageAccount 'Microsoft.Storage/storageAccounts@2022-05-01' = { name: storageAccountName location: location sku: { name: storageAccountType } kind: 'Storage' properties: { supportsHttpsTrafficOnly: true defaultToOAuthAuthentication: true } } resource hostingPlan 'Microsoft.Web/serverfarms@2021-03-01' = { name: hostingPlanName location: location sku: { name: 'Y1' tier: 'Dynamic' } properties: {} } resource func 'Microsoft.Web/sites@2021-03-01' = { name: functionAppName location: location kind: 'functionapp' identity: { type: 'SystemAssigned' } properties: { serverFarmId: hostingPlan.id siteConfig: { appSettings: [ { name: 'AzureWebJobsStorage' value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccountName};EndpointSuffix=${environment().suffixes.storage};AccountKey=${storageAccount.listKeys().keys[0].value}' } { name: 'WEBSITE_CONTENTAZUREFILECONNECTIONSTRING' value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccountName};EndpointSuffix=${environment().suffixes.storage};AccountKey=${storageAccount.listKeys().keys[0].value}' } { name: 'WEBSITE_CONTENTSHARE' value: toLower(functionAppName) } { name: 'FUNCTIONS_EXTENSION_VERSION' value: '~4' } { name: 'WEBSITE_NODE_DEFAULT_VERSION' value: '~14' } { name: 'FUNCTIONS_WORKER_RUNTIME' value: functionWorkerRuntime } ] ftpsState: 'FtpsOnly' minTlsVersion: '1.2' } httpsOnly: true } } var cosmosRoleDefinitionIds = [ '00000000-0000-0000-0000-000000000002' ] var cosmosRoleAssignmentsToCreate = [for cosmosRoleDefinitionId in cosmosRoleDefinitionIds:{ name: guid(func.id, resourceGroup().id, cosmosRoleDefinitionId) roleDefinitionId: cosmosRoleDefinitionId }] resource cosmosDBAccount 'Microsoft.DocumentDB/databaseAccounts@2024-11-15' existing = { name: cosmosDBAccountName } resource cosmosDBRoleAssignment 'Microsoft.DocumentDB/databaseAccounts/sqlRoleAssignments@2023-04-15' = [for cosmosRoleAssignmentToCreate in cosmosRoleAssignmentsToCreate: { name: cosmosRoleAssignmentToCreate.name parent: cosmosDBAccount properties:{ principalId: func.identity.principalId roleDefinitionId: '/${subscription().id}/resourceGroups/${resourceGroup().name}/providers/Microsoft.DocumentDB/databaseAccounts/${cosmosDBAccount.name}/sqlRoleDefinitions/${cosmosRoleAssignmentToCreate.roleDefinitionId}' scope: cosmosDBAccount.id } }] 最後にmain.bicepですね。上記２つのモジュールを呼び出す処理を入れます。 param location string = resourceGroup().location param accountName string param databaseName string param containerName string module cosmosdb 'modules/database/cosmos.bicep' = { name: 'cosmosdbModule' params: { location: location accountName: accountName databaseName: databaseName containerName: containerName } } module api 'modules/app/func.bicep' ={ name: 'apiFunc' params: { location: location cosmosDBAccountName: cosmosdb.outputs.accountName } } 権限が付与できているかの確認方法 では実際にbicepを走らせてみて、デプロイされたFunctionsに対して正しい権限が付与されているかを確認しましょう。 ここも個人的なハマりポイントで、上のほうでも書いていますが私調べではCosmosDBのデータプレーンの権限をAzureポータル上から確認することが出来ませんでした。 以下のazコマンドを実行することでCosmosDBアカウントに対してどのマネージドIDにどのデータプレーンのロールが付与されているかの確認をすることができます。 az cosmosdb sql role assignment list --account-name <cosmosdbアカウント名>--resource-group <リソースグループ名> まとめ 今回はBicepを利用してCosmosDBとFunctionsのリソースを作成し、FunctionsのEntraIDに対してCosmosDBの操作が行えるロールを付与する方法を確認しました。ロールを付与するための書き方がデータプレーンのロール用にしたり、Azureポータル上からは権限の付与が確認ができないなどハマりやすいポイントが多い部分だと思いますので同じく躓いた方の参考になればと思います！ Bicep自体は１コマンドでインフラ一式デプロイを行うことができ、非常に便利に感じているのでこれからも知見をためていきたいと思います。 ではまた～ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【Azure】BicepでFunctionsにComosDBの組み込みロールを付与する first appeared on SIOS Tech. Lab .

こんにちは、サイオステクノロジーの遠藤です。 先日、AzureのAI資格であるAI-102に合格し、Azure AI Engineer Associateに認定されました！ AI-102は比較的新し目の資格のためAZ-104などの鉄板Azure資格に比べて情報が少なく、どのような勉強方法が良いのかといったわからない方が多いと思います。今回はそういった方々に役立つようにまとめていきたいと思います。 はじめに 試験の内容についてですが、試験を受ける際にNDA（秘密保持契約）を結ぶことになるので記載することが出来ません。そのためふわっとした内容になってしまうこととご了承ください。 Azure AI Engineer Associateとは？ Azure AI Engineer AssociateはAzureの認定試験の一つであり、Azure上で提供されているAI関連のサービスに対する知識が問われるAssociateレベルの資格になります。なお、AIに関するAzure試験はExpertレベルがないため、2025年１月の段階では一番難易度の高いAI資格となります。AI-102試験に合格することで認定を受けることが出来ます。 公式ページ : Azure AI Engineer Associate 私の経歴と受験理由 私の経歴としては、2023年にサイオステクノロジーに入社し、各種案件の中などでAzure上でのアプリ構築等に取り組んでおりました。入社する前には他のクラウドプラットフォームを少し使用したことがありましたが、Azureは仕事で初めて触った形ですね。2024年度は生成AIアプリケーション開発メインで取り組んでおりまして、その中でAzureの生成AI サービスを多く使用する経験を積ませていただきました。また、弊社でAzure資格取得を推奨されている流れもあり、自分が業務に関わっている内容のAzure資格を受けてみたいと思い、受験することとしました。ちなみにAzureの試験は初めてで、AIにはFundamentalsレベルのAI-900を飛ばしての受験となりました。 勉強方法と出題内容 弊社にはAzure資格自体に関してはExpertレベルまで取得されている方がたくさんいらっしゃるのですが、AI-102に関しては私が関わりのある方で取得されている方がいらっしゃらなかったので、探り探りの学習でした。最終的な学習方法としては、基本に忠実にということで最初から最後まで公式のMS Learnを利用して学習を進めました。 出題内容としては公式が出している「試験 AI-102: Microsoft Azure AI ソリューションの設計と実装に関する学習ガイド」に記載されていて Azure AI ソリューションを計画して管理する (15 から 20%) コンテンツ モデレーション ソリューションを実装する (10 – 15%) コンピューター ビジョン ソリューションを実装する (15 から 20%) 自然言語処理のソリューションを実装する (30 から 35%) ナレッジ マイニングとドキュメント インテリジェンス ソリューションを実装する (10 から 15%) 生成 AI ソリューションを実装する (10 から 15%) といった内容が出題されます。 ドキュメントインテリジェンスや、生成AIソリューションの実装といった内容は業務の中で進めているものだったため確認程度の学習で済んだのですが、個人的に難しかったと感じたのがコンピューター ビジョン ソリューションと自然言語処理のソリューションを実装するでした。この２つについては試験勉強前は触ったことがなかった＋出題範囲が広く覚えることが多いのセットで学習が辛かったです… 学習方法に話を戻しますが、私が行った学習方法としてはラーニングに沿ってトレーニングの内容について確認していきました。ただ、トレーニングの内容全部を行ったわけではなく、時短のために多くのトレーニングはドキュメント部分だけを読み、そのサービスがどのようなことができるのか、使用する際にどのような注意点があるかを学べるようにすることに留めました。ラボ（ハンズオン）部分に関しては触ったことがなかったVisionやLanguageサービスについてはいくつか行って見た程度です。 トレーニングのドキュメントを読んで概要が頭に入った後はひたすら公式が準備しているプラクティス評価問題集を繰り返し取り組み、完答できるようになることを目指しました。また、問題を問いている中で少しでもわからないところがあったらプラクティス評価の答えについている関連するMS Learnのページに飛び、その内容を理解できるようにドキュメントを読み込んでいくという形で学習を進めていきました。 実際に受けてみての感想 今回MSの試験を初めて受けた＋過去問がない形式の試験を初めて受けたというのもあり、勉強のやり方がわかりませんでした。実際に一回受けてみないとどのような出題形式の試験なのか掴めないと思いますので、まずは一回あまり気負わず受けてみるのがよいかなと感じています。 本試験ではMS Learnを利用できるのですが、これに大きく助けられました。検索によって答えられた部分も多かったので、是非活用してきましょう。あと、試験を受ける前にMS Learnでキーワードを調べる練習をしておくと、本番のときに慌てずに済むと感じました。また、このとき使用できるMS Learnですが、Ctrl + Fが使用できませんでした。私の環境だけだったのかもしれませんが、念の為Ctrl + Fなしでドキュメントを調べる練習をしておいたほうが良いかもしれません。 わからない問題はMS Learnで調べるという進め方をした結果、見返しなしで残り時間３分になりました。MS Learnを使用できることにより検索にたくさん時間をかけれてしまうので、答えられる問題はすく答えるようにするなど時間配分には気をつける必要があると感じました。 おわりに 今回、AI-102試験に合格し、Azure AI Engineer Associateに認定されました。初めてのAzure資格挑戦ということで最初は勉強方法が掴めなかったですが、無事合格することが出来て良かったです！ Azure資格については他にも挑戦したいと考えていて、次はAZ-104合格を目指していきたいと思います。合格したらこの記事と同じように合格体験記として投稿しようと思いますので目を通していただければと思います。 ではまた～ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【AI-102】Azure AI Engineer Associate認定されました！ first appeared on SIOS Tech. Lab .

前回の記事 では、サーバーレスアーキテクチャを実現するためのOpenShift Serverlessについて解説しました。今回は、OpenShift Serverless を実際に構築したいと思います。 Red Hat Developer のチュートリアル を参考にOpenShift Serverlessのサンプルアプリケーションをデプロイ、挙動の確認を行っていきます。 事前準備 下記コマンドを実行して作業端末にkn CLIをインストールします（バージョンは2025/01/22時点）。バージョンとアーキテクチャは作業端末に適切なものを選択してください。 $ curl -Lo kn-linux-arm64 https://github.com/knative/client/releases/download/knative-v1.6.0/kn-linux-arm64 $ chmod +x kn-linux-arm64 $ sudo mv kn-linux-arm64 /usr/local/bin/kn 下記コマンドを実行してインストールの完了を確認します。 $ kn version Version: v20220713-local-bfdc0a21 Build Date: 2022-07-13 09:04:48 Git Revision: bfdc0a21 Supported APIs: * Serving - serving.knative.dev/v1 (knative-serving v0.33.0) * Eventing - sources.knative.dev/v1 (knative-eventing v0.33.0) - eventing.knative.dev/v1 (knative-eventing v0.33.0) 前提条件 OpenShift 4 クラスターが構築済みであること 作業端末に oc CLI がインストール済みであること OpenShift Serverless Operatorをインストール Operatorをインストール OpenShift OperatorHub で Administrator のパースペクティブにいることを確認します。 Web コンソールで [Operators] > [OperatorHub] に移動します。 検索バーに「OpenShift Serverless」と入力して、 OpenShift Serverless をクリックして Install をクリックします。 デフォルトのまま Install をクリックします。 Knative Serving をインストール OpenShift Serverless Operator を使用して Knative Serving をインストールするには、KnativeServing オブジェクトを作成する必要があります。 Knative Serving をインストールします。 OpenShift OperatorHub で Administrator のパースペクティブにいることを確認します。 Web コンソールで [Operators] > [インストール済みのOperator] に移動します。 Web コンソールでknative-serving プロジェクトに移動します。 Knative Serving をクリックします。 Knative Serving の作成をクリックします。 すべての値をデフォルトのままにして、[Create] ボタンをクリックします。 サンプルアプリケーションデプロイ 下記コマンドを実行してプロジェクトを作成します。 $ oc new-project serverless-tutorial 下記コマンドを実行してアプリケーションをデプロイします。Knative はコマンドライン1つでアプリケーションをデプロイすることが出来ます。もちろん、マニフェストファイルでのデプロイも可能です。 $ kn service create greeter \ --image quay.io/rhdevelopers/knative-tutorial-greeter:quarkus \ --namespace serverless-tutorial Warning: Kubernetes default value is insecure, Knative may default this to secure in a future release: spec.template.spec.containers[0].securityContext.allowPrivilegeEscalation, spec.template.spec.containers[0].securityContext.capabilities, spec.template.spec.containers[0].securityContext.runAsNonRoot, spec.template.spec.containers[0].securityContext.seccompProfile Creating service 'greeter' in namespace 'serverless-tutorial': 0.058s The Route is still working to reflect the latest desired specification. 0.088s Configuration "greeter" is waiting for a Revision to become ready. 20.686s ... 20.722s Ingress has not yet been reconciled. 20.765s Waiting for load balancer to be ready 20.956s Ready to serve. Service 'greeter' created to latest revision 'greeter-00001' is available at URL: https://greeter-serverless-tutorial.apps.<ドメイン名> 挙動確認 下記コマンドを実行してデプロイしたリソースを確認します。 $ kn service list NAME      URL                                                                                  LATEST          AGE   CONDITIONS   READY   REASON greeter   https://greeter-serverless-tutorial.apps.<ドメイン名>   greeter-00001   19m   3 OK / 3     True 下記コマンドを実行してリクエストを送った際の pod の増減を確認してみます。上記コマンドで表示された URL に curl やブラウザなどでリクエストを送ります。 $ oc get pod -w NAME READY STATUS RESTARTS AGE greeter-00001-deployment-5677dbb785-lmw27 0/2 Pending 0 0s greeter-00001-deployment-5677dbb785-lmw27 0/2 Pending 0 0s greeter-00001-deployment-5677dbb785-lmw27 0/2 Pending 0 0s greeter-00001-deployment-5677dbb785-lmw27 0/2 ContainerCreating 0 0s greeter-00001-deployment-5677dbb785-lmw27 0/2 ContainerCreating 0 0s greeter-00001-deployment-5677dbb785-lmw27 1/2 Running 0 1s greeter-00001-deployment-5677dbb785-lmw27 2/2 Running 0 1s greeter-00001-deployment-5677dbb785-lmw27 2/2 Terminating 0 108s greeter-00001-deployment-5677dbb785-lmw27 1/2 Terminating 0 2m10s greeter-00001-deployment-5677dbb785-lmw27 0/2 Terminating 0 2m18s greeter-00001-deployment-5677dbb785-lmw27 0/2 Terminating 0 2m19s greeter-00001-deployment-5677dbb785-lmw27 0/2 Terminating 0 2m19s OpenShift GitOps を用いたデプロイ 事前準備 OpenShift GitOps を構築してみた を参考にして下記手順を実施します。 OpenShift GitOps をインストール OpenShift GitOps のログイン Argo CD へのデプロイ権限の付与 プライベートリポジトリの登録 マニフェスト用リポジトリに下記構成を配置します。 app ├── knative_serving.yaml └── kustomization.yaml knative_serving.yaml apiVersion: serving.knative.dev/v1 kind: Service metadata:   name: greeter   namespace: serverless-tutorial spec:   template:     spec:       containers:       - image: quay.io/rhdevelopers/knative-tutorial-greeter:quarkus         livenessProbe:           httpGet:             path: /healthz         readinessProbe:           httpGet:             path: /healthz kustomization.yaml resources: - knative_serving.yaml アプリケーションをデプロイ 下記コマンドを実行して ArgoCD アプリケーションをデプロイします。 $ oc apply -f application.yaml application.argoproj.io/serverless-dev created application.yaml apiVersion: argoproj.io/v1alpha1 kind: Application metadata:   name: serverless-dev   namespace: openshift-gitops spec:   project: default   source:     repoURL: GitHubリポジトリのURL(末尾が .git で終わるURL)     path: app     targetRevision: HEAD   destination:     server: https://kubernetes.default.svc     namespace: serverless-tutorial   syncPolicy:     automated:       prune: true       selfHeal: true デプロイ確認 ArgoCD の画面から ArgoCD アプリケーションが作成されていることを確認します。 デフォルトのビューだとリソースが多すぎるため、今回はビューを変更します。アプリケーションデプロイから少し時間がたった後に確認したため、pod が立っていないことが確認できます。 挙動確認の時と同じようにリクエストを送って pod の増減を確認して完了です。 まとめ Red Hat Developer のチュートリアル を参考にOpenShift Serverlessのサンプルアプリケーションをデプロイ、挙動の確認しました。コンテナイメージさえ用意していれば簡単にサーバレスアプリケーションをデプロイすることが出来ます。ゼロスケールによりリソースの節約が可能になりますが、pod立ち上げの時間があるため、ユースケースに応じて適切に使い分ける必要があります。 参考文献   Red Hat OpenShift Serverlessとは？ OpenShift GitOps を構築してみた https://developers.redhat.com/courses/getting-started-openshift-serverless?source=sso ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post OpenShift Serverless を構築してみた first appeared on SIOS Tech. Lab .