アプトポッドのブログ - TECH PLAY

TECH PLAY

アプトポッド

アプトポッド の技術ブログ

å…š255ä»¶

日々進歩するAIの自分を凌ぐ優秀さを目の圓たりにしお 早くすべおの仕事を奪っおくれないかなず思っおいるみなさん、 こんにちは、゜リュヌションアヌキテクトの䌊勢です。 AIは文章を曞き、画像を䜜り、コヌドも曞くようになりたした。 次は、珟実䞖界を認識しお自分で考え、身䜓を動かす「フィゞカルAI」の番です。 ただし、ロボットを倏䌑みの自由工䜜で䜜るには、少々お小遣いが足りたせん。 そこで今回は、AIに頭脳を、iPhoneに目ず耳を、ヒトに足を担圓しおもらいたす。 ヒトはAIの指瀺どおりにチェックポむントを呚り、ゎヌルを目指したす。 コヌスは䞖界䞀の乗降者数を誇る巚倧タヌミナル、新宿駅です。 果たしおヒトはフィゞカルAIに進化するのでしょうか。 はじめに フィゞカルAIずは オリ゚ンテヌリングずは REST APIのアップストリヌムずは iPhoneショヌトカットずは 䜜っおみた 党䜓構成 地図 プラグむンintdash REST Plugin 蚭定画面 送受信履歎 iPhoneショヌトカット デヌタ送信 デヌタ取埗 やっおみた Data Visualizerで振り返る おわりに はじめに フィゞカルAIずは フィゞカルAIは、珟実䞖界を認識し、掚論し、行動するAIシステムを指したす。 ロボットや自動運転車のように、センサヌから埗た情報をもずに刀断し、珟実䞖界ぞ働きかける仕組みです。 www.nvidia.com 今回は圹割を次のように分担したす。 フィゞカルAIの圹割 今回の担圓 珟実䞖界を認識する iPhoneカメラ 状況を考えお次の行動を決める サヌバヌサむドAI 珟実䞖界で行動する ヒト ロボットのボディを甚意する代わりに、私が歩きたす。 蚀い換えるず Human in the Loop のLoop郚分がずいぶん倧きく新宿を䞀呚したす。 オリ゚ンテヌリングずは オリ゚ンテヌリングは、地図を読みながら指定されたチェックポむントを順番に巡り、ゎヌルを目指すスポヌツです。 日本オリエンテーリング協会 遞手は地図に蚘されたコヌスず目暙物の情報から、珟圚地や進む方向を刀断したす。 今回はこの 地図を読む次の行動を決める目暙物を確かめる をAIぞ任せたす。 舞台は新宿駅東口から歌舞䌎町、新宿埡苑、新宿駅南口・西口を経お郜庁ぞ向かう党11ポむントのコヌスです。 1 自埋皌働するフィゞカルAIを暡しお、AIから送られおくる指瀺だけを頌りに進みたす。 REST APIのアップストリヌムずは AIずヒトの間にintdashを挟みたす。 intdashにおけるアップストリヌムは、デバむス偎からプラットフォヌム偎ぞデヌタを送信する方向のストリヌムです。 今回はiPhoneから写真を送り、別の゚ッゞからAIの指瀺・目暙物画像・写真の刀定結果を返したす。 REST APIによるアップストリヌムは、HTTPで手軜にデヌタを送信でき、䜎頻床デヌタの送信や簡単な怜蚌に向いおいたす。 tech.aptpod.co.jp iPhoneショヌトカットずは 耇数の操䜜を組み合わせお自動化できるApple玔正アプリです。 カメラで撮圱した画像をAPIぞ送信したり、APIから受け取った結果の衚瀺を画面䞊で組み立おられたす。 AIがアプリを䜜っおくれる時代ずはいえ、専甚アプリで収集デヌタを远加するのはそれなりの開発コストが発生したす。 今回は耇数デヌタの収集を玠早く詊すため、ショヌトカットから利甚できるプラグむンアプリずしお実装したした。既存機胜を掻甚しお実装コストを抑えられたす。 2 䜜っおみた 党䜓構成 今回の構成は次のずおりです。 党䜓構成図 AIがルヌトマップを読み、各区間の移動指瀺ず目暙物画像を準備 intdashを経由しお、次のチェックポむント番号・移動指瀺・目暙物画像をiPhoneぞ送る ヒトが指瀺に埓っお歩きいお珟地で写真を撮る iPhoneから珟地写真をintdashぞ送る AIが目暙物画像ず珟地写真を照合する 䞀臎すれば次のチェックポむントぞ進み、䞍䞀臎なら再挑戊する サヌバヌ偎ではPythonプログラムでAI䞭継凊理を動かしたした。 このプログラムがintdashずAIを぀なぎ、ルヌト案内、写真照合、チェックポむント進行、䌑憩・再開を管理したす。 芁するにAIが「次はあっちです」ず蚀い、私が歩き、AIが「そこです」ず刀定したす。 地図 ルヌトマップにはコヌス、チェックポむント、目暙物の写真をたずめおいたす。 オリ゚ンテヌリングのルヌトマップ 地図画像は最初に䞀床だけAIぞ枡したす。 AIは党区間の移動指瀺を生成し、各チェックポむントの目暙物を切り抜きたす。 生成したルヌト情報ず画像は保存し、レヌス䞭は再利甚したす。 AIは地図をかなり読んでくれたしたが、高架道路の䞊䞋関係や階段の進行方向などは、画像だけでは刀断しにくい郚分がありたす。 そこで確認枈みの情報は補足テキストで枡し、地図の読み違いを枛らしたした。 地図はOpenStreetMapをもずに、オリ゚ンテヌリング囜際仕様を参考に䜜りたした。 3 地図デヌタ © OpenStreetMap contributors を利甚しおいたす。 4 プラグむンintdash REST Plugin iPhoneの「ショヌトカット」からintdash REST APIを䜿えるようにするため、SwiftUIでプラグむンアプリを詊䜜したした。 5 巡回地点で写真などを送りたいずいう芁望があり、詊しに䜜ったものです。 アプリにApp Intentsを組み蟌み、ショヌトカットから呌び出せるようにしたした。 送信する数倀・文字列・画像を送信リストぞ远加する 耇数のデヌタを同じ時刻でたずめお送信する 最新の蚈枬から指定したデヌタを取埗する 蚈枬を完了する 察応する倀は int64 、 float64 、 string 、JPEGです。 そのため、䜍眮情報、歩数、気枩、䜏所、音声認識結果、写真など、ショヌトカットが扱えるさたざたな情報をintdashぞ枡せたす。 蚭定画面 接続先情報、送信゚ッゞUUIDなどを指定したす。 プラグむンの蚭定画面 送受信履歎 蚈枬の䜜成・完了、デヌタID、倀、サむズ、通信時刻、成吊を確認できたす。 ログはJSONずしお曞き出せるので、「ショヌトカットは動いたように芋えるけれど、実際に䜕を送ったのか」を埌から远えたす。 プラグむンの送受信履歎画面 iPhoneショヌトカット ショヌトカット偎では、iPhoneの暙準機胜ずプラグむンを組み合わせたす。 デヌタ送信 珟地写真に加えお、緯床・経床・高床、䜏所、歩数、移動速床、気枩、湿床、䜓感枩床、バッテリヌ残量、音声メモを送信できるようにしたした。 送信したい項目を䞊べ、最埌に「デヌタ送信」を1぀眮きたす。 ショヌトカットがデヌタを集めお、プラグむンがintdashず通信したす。 iPhoneショヌトカットのデヌタ送信 デヌタ取埗 AI偎からは、次のチェックポむント番号、移動指瀺、目暙物画像、写真刀定、刀定信頌床、刀定理由を受け取りたす。 JPEGも実行結果ずしお衚瀺できるため、次の目暙物を確認できたす。 iPhoneショヌトカットのデヌタ取埗 やっおみた それでは、人力フィゞカルAIを起動したす。 AIが最初の指瀺ず目暙物画像を送信し、ヒトが歩き始めたす。 チェックポむントに着いたず思ったら写真を撮圱し、AIぞ送りたす。 AIは目暙物ず写真を照合し、䞀臎ず刀断すれば次の指瀺を返したす。 䌌おいるけれど違う堎所では先ぞ進めたせん。 人間の「たぶんここでしょ」に察しお、AIの方が几垳面です。 途䞭で「暑いのでちょっず䌑憩したい」ず音声メモを送るず、AIは写真刀定を止め、䌑憩ず氎分補絊を案内したす。 「䌑憩が終わった」ず送るず、珟圚の移動指瀺ず目暙物画像をもう䞀床送っお再開したす。 6 スタヌトからゎヌルたでの様子を動画にしたした。 youtu.be 動画の台本案もChatGPTをベヌスにしおいたす。 AIに指瀺されお歩く動画を、AIず盞談しながら線集したした。 7 Data Visualizerで振り返る レヌス䞭に送受信したデヌタを同じ時間軞に䞊べお確認できたす。 intdash Data Visualizerのレヌス党䜓画面 画面には、倧きく分けお次のデヌタを衚瀺しおいたす。 担圓 衚瀺デヌタ わかるこず ヒト+iPhone 緯床・経床・高床 どこを移動したか ヒト+iPhone 歩数・移動速床 い぀歩き、い぀止たったか ヒト+iPhone 気枩・湿床・䜓感枩床 どのような環境だったか ヒト+iPhone バッテリヌ残量 ゎヌルたで持ちそうか ヒト+iPhone 珟地写真・音声メモ 䜕を芋お、䜕を䌝えたか AI チェックポむント番号・移動指瀺 䜕をさせようずしたか AI 目暙物画像 䜕を探させたか AI 写真刀定・信頌床・刀定理由 なぜ次ぞ進めたか AIが送った目暙物画像ず、ヒトが撮った写真を䞊べるず照合の流れがわかりたす。 撮圱写真照合NG 撮圱写真照合OK 信頌床ず理由も残しおいるため、AIが刀断した根拠を埌から確認でき、 途䞭で䜕が起きおいたかをデヌタずしお振り返れたす。 おわりに 今回は、AIにルヌトマップを読たせおオリ゚ンテヌリングをしおみたした。 AIは次の目的地を考え、目暙物を瀺し、珟地写真を刀定したす。 iPhoneは呚囲の情報を集め、指瀺を衚瀺したす。 そしおヒトは歩きたす。 ヒトはフィゞカルAIに進化したのでしょうか。 残念ながら、私の脚力は䞀切アップデヌトされたせんでした。 ただし、AI、スマヌトフォン、通信基盀、そしおヒトを組み合わせるこずで「認識・掚論・行動」のルヌプを珟実䞖界で回せたした。 今回ヒトが担圓した郚分をモビリティやロボットぞ眮き換えるず、巡回点怜のようなシステムぞ぀ながりたす。 珟地から写真やセンサヌデヌタを送り、遠隔のAIが刀断し、次の行動を返す。 今回の自由工䜜は、その小さな暡型です。 フィゞカルAIを掻甚するのに、必ずしも最初から立掟なロボットを甚意しなくおもよいのかもしれたせん。 たずは手の䞭のスマヌトフォンず、自分の身䜓からはじめられたす。 もっずも、次回たでには歩くずころも奪っおほしいずころです。 実際のオリ゚ンテヌリングは、人が密集しおいない開けた堎所で安党に行われたす。乗降者数䞖界䞀の駅近蟺でスプリントレヌスを開催するのは危険ですので、おやめください。今回は呚囲の状況を確認し、亀通ルヌルを守っお歩行しおいたす。 ↩ 拡匵機胜 App Intents を組み蟌んでショヌトカットから呌び出せるようにしおいたす。 ↩ ぀たり、猛暑日の新宿䞀呚を事前にもう䞀回行ったずいうこずです。 ↩ 地図ず䜍眮説明は、 International Specification for Control Descriptions 2018 日本語版 および International Specification for Orienteering Maps 2017-2 日本語版 を参考にしおいたす。ただし、䜜りやすさずAIの読み取りやすさを優先しおカスタマむズしおおり、仕様に則っおいない郚分がありたす。 ↩ 本ツヌルは詊䜜であり、珟圚、公開や提䟛の予定はありたせん。 ↩ 熱䞭症譊戒アラヌトが出おいる日に屋倖を2時間歩き回るのは危険です。実斜する堎合は気象情報ず䜓調を確認し、危険を感じる前に䞭止しおください。この蚘事の詊行条件を再珟しないでください。 ↩ 動画のテロップは癜がヒト、グリヌンがAIの発蚀です。途䞭からグリヌンばかりになるのは、䞻䜓がAIに切り替わっおいく挔出です。 ↩
出展の抂芁 䌚堎の印象 アプトポッドブヌスの展瀺 点怜・譊備゜リュヌション メヌタヌ読み取り 四足歩行ロボット以倖の連携ドロヌン・りェアラブルカメラ・サヌマルカメラ 通信 リアルタむムデゞタルツむン゜リュヌション 映像3Dモデル化デモ フィゞカルAI 来堎者の反応 たずめ こんにちは、クロスむンダストリヌ事業郚゜リュヌション開発グルヌプの圱山です。同事業郚で補品・゜リュヌションの開発を担圓しおいたす。 この床、株匏䌚瀟アプトポッドは、2026幎7月15日氎から17日金たでの3日間、東京ビッグサむト東展瀺棟で開催された「メンテナンス・レゞリ゚ンス 2026」に出展したした。おかげさたで3日間を通しお倚くの方にブヌスぞお立ち寄りいただきたした。ありがずうございたした。 https://mente.jma.or.jp/ 今幎は、点怜・譊備、リアルタむムデゞタルツむン、フィゞカルAIずいったトピックにフォヌカスしお展瀺を行いたした。本蚘事では、それぞれに぀いおご玹介しおいきたいず思いたす。 出展の抂芁 アプトポッドは産業甚IoTミドルりェア「 intdash 」を提䟛しおいたす。これたで自動車開発や建蚭機械の領域で導入いただいおきたしたが、蚭備の点怜・保党ずいう領域でもintdashの特長を生かせるず考え、さたざたなナヌスケヌスのデモや事䟋を展瀺したした。intdashはマルチモヌダルなデヌタをリアルタむムに扱うこずに長けおいたす。カメラ映像、LiDARの点矀、ロボットのROSトピック、ガスセンサヌの倀、既存蚭備のデヌタずいった、皮類も呚期もばらばらな倧量のデヌタを、時刻を揃えたたたリアルタむムに集めお遠隔から扱いたい、ずいうニヌズにマッチしたす。 www.aptpod.co.jp 今回のデモ党䜓の構成図 今回の出展では、耇数の四足歩行ロボットを動かしお点怜をデモしたり、同時にドロヌンの映像をintdashぞ転送したりずいった実挔を通じお、メヌカヌも皮類も異なる機䜓・センサヌを、intdashずいう1぀のデヌタ基盀の䞊で運甚する様子を、実機ず画面でそのたたご芧いただきたした。 䌚堎の印象 䌚堎を歩いおいお印象的だったのは、点怜ロボットやドロヌンを展瀺しおいるだけでなく、実際に動かしおいるブヌスが非垞に倚かったこずです。人手䞍足を背景に、むンフラ・プラントの点怜をいかに自動化・省人化するかずいうテヌマが、実蚌段階から運甚段階ぞ移り぀぀あるこずを感じたした。 アプトポッドブヌスの展瀺 アプトポッドブヌスの様子 点怜・譊備゜リュヌション 点怜や譊備の分野では、人手䞍足が課題になっおいるずいうお話をうかがうこずが特に倚くなっおいたす。よくうかがう課題は、人が珟堎に行かないず状況が分からないこず、蚈噚の倀を人が目芖で読む必芁があるこず、定眮センサヌがない箇所は人が足を運ぶしかないこずです。 ブヌスの前面では、「カメラやセンサヌを搭茉したロボットが自埋的に珟堎を歩いお移動する」「ロボットが撮圱した画像をAIが解析しお数倀にする」「ロボットからのデヌタずAIの解析結果を、すべお1぀のintdashの画面でリアルタむムに芋る」ずいう組み合わせで実挔したした。 ブヌス内には昇降ステップやダミヌの蚈噚を配眮しお簡易的なプラントを暡擬し、そのなかを Unitree Go2 や Unitree A2 が走行したした。 デモ゚リアを歩き回るロボットたち Unitree Go2 では、 パナ゜ニック アドバンストテクノロゞヌ株匏䌚瀟 様の自埋移動゜フトりェア「@mobi」を䜿い、事前に䜜成した地図ずりェむポむントに沿っおブヌス内を巡回したす。頭郚カメラに加えお、背䞭に3D LiDARLivox Mid-360ず360床カメラInsta360 X5、そしおCO2センサヌを搭茉したした。 adtsd.jpn.panasonic.com Go2の背䞭。3Dプリンタ補のケヌスに360床カメラずアンテナ、CO2センサヌを茉せおいたす Unitree A2 は最近発売された新機皮で、防塵防氎に察応しおおり、重いペむロヌドも搭茉できたす。今回は自埋走行は行わず、intdashを経由した遠隔操瞊のデモを行いたした。遠隔操瞊だけでなく、 株匏䌚瀟ザクティ 様のPTZカメラの向きを遠隔から操䜜できるようにし、さらに 理研蚈噚株匏䌚瀟 様のマルチガスセンサヌ GX-3R Pro を搭茉しお、ガスのセンサヌ倀をリアルタむムにintdashぞ送りたした。PTZカメラを遠隔からパン・チルト・ズヌムさせお、離れた堎所の蚈噚を読みに行く、ずいう䜿い方ができたす。 A2の背䞭。PTZカメラずマルチガスセンサヌを搭茉しおいたす product.rikenkeiki.co.jp xacti-co.com ブヌスの入り口で展瀺しおいた Unitree Go2-W は、脚の先が車茪になっおいるモデルで、こちらには TechShare 瀟株匏䌚瀟 様の自埋移動パッケヌゞ「Patrobot」を茉せおいたす。搭茉しおいるのはCO・アルコヌルガスセンサヌず攟射枩床蚈。ガス挏れず発熱ずいう、プラント点怜で真っ先に芋たい2぀を歩きながら枬るむメヌゞです。 展瀺では昇降ステップを䞊べお段差を䜜り、ロボットが階段状の障害物を昇り降りする様子もご芧いただきたした。 ブヌス内を自埋走行しお、メヌタヌの自動読み取りを行うUnitree Go2 techshare.co.jp メヌタヌ読み取り アナログ蚈噚は、人が倀を目芖で読み取っお蚘録する䜜業が必芁です。それを自動化する䟋ずしお、ロボットのカメラ映像からメヌタヌ領域を切り出し、「hakaru.ai」 の認識APIに問い合わせお数倀に倉換するデモを行いたした。 読み取った倀は、そのたた intdash の時系列デヌタずしお扱えたす。intdashぞ送るこずで、カメラの映像などず䞊べおメヌタヌの読み取り倀を確認できたす。たた、リアルタむムに芋るだけでなく、あずからAPIを利甚しお回収するこずもできたす。 切り出されたメヌタヌ画像ず読み取り倀。CO2濃床や人物怜出数ず同じ画面に䞊びたす www.hakaru.ai 四足歩行ロボット以倖の連携ドロヌン・りェアラブルカメラ・サヌマルカメラ 四足歩行ロボット以倖にも、ドロヌン、りェアラブルカメラ、サヌマルカメラずの連携を展瀺したした。 ドロヌンのデモでは、ドロヌン搭茉カメラのラむブ映像をintdashぞ送り、高所や空䞭からの確認が可胜なこずを玹介したした。俯瞰䜍眮に蚭眮したサヌマル監芖カメラEDGEPLANT T1 経由では、RGB映像ずサヌマル映像を同時に配信し、枩床異垞を色で確認できるこずを玹介したした。 株匏䌚瀟ザクティ 様のりェアラブルカメラは Raspberry Pi 経由で接続し、ブレ補正された䜜業者目線の映像を送れるこずを実挔したした。 これらの映像に぀いおは、サヌバヌ偎でYOLOによる人物・物䜓怜出を行い、映像を埌凊理しお怜知するこずも可胜であるこずをデモしたした。 ロボット・固定カメラ・人・ドロヌンずいう性栌の違うデヌタ゜ヌスを、intdashで統合しお確認できるこずが、この゜リュヌションの倧きな特長の䞀぀です。 ドロヌンの映像も、ロボットやカメラず同じ画面で確認できたす xacti-live.com 通信 各ロボットには回線ボンディングに察応した Peplink MAX BR2 Micro を利甚し、混雑した䌚堎内でも2回線を束ねるこずで安定したモバむル通信を実珟したした。 www.caso.co.jp リアルタむムデゞタルツむン゜リュヌション この゚リアでは、斜工珟堎の状況を仮想空間に再珟するリアルタむムデゞタルツむン基盀をご芧いただきたした。画面には珟堎の3D点矀が広がり、その䞊に車䞡の走行軌跡が重なりたす。同じ画面の䞭に掘削量・盛土量ずいった土量の数倀、地衚の断面圢状のグラフ、そしお車茉カメラの映像が䞊び、すべおが同じ時間軞で再生されたす。「珟堎のい぀・どこで・䜕が起きおいたか」を、埌から3D空間ごず巻き戻しお確認できる、ずいうむメヌゞです。 3D点矀の䞊に車䞡の走行軌跡、土量、断面圢状、車茉カメラ映像が同じ時間軞で䞊びたす 実際に動いおいる様子は、こちらの動画でご芧いただけたす。 www.youtube.com 映像3Dモデル化デモ ブヌスを iPhoneアプリ intdash Motionで撮圱した映像デヌタを、 株匏䌚瀟Liberaware 様が提䟛する「 LAPIS 」に連携しお点矀化し、3Dモデルずしお衚瀺したした。 専甚の3Dスキャナヌだけでなく映像を起点ずしお空間を3D化できるため、蚭備や珟堎の状況把握、遠隔からの確認など、さたざたな掻甚が期埅できたす。映像を芋るだけの監芖から、空間ずしお蚘録・参照する掻甚ぞ広がる点が興味深い展瀺でした。 www.youtube.com フィゞカルAI フィゞカルAIの゚リアでは、これから応甚が進んでいくであろうこの分野でも、intdashを掻甚できそうな事䟋をご玹介したした。 ロボットやAIを珟堎で賢く動かすには、倧量の珟実䞖界のデヌタが必芁です。䞀方で、危険な状況やめったに起きない事象は、実環境ではなかなか集められたせん。そこで、実環境から集めたデヌタず、シミュレヌション環境Gazeboなどで生成したデヌタを、intdash で同じように収集・蓄積する構成をご玹介したした。 あわせお、孊習デヌタの収集からアノテヌション、モデル開発、実機ぞのOTAによるモデルデプロむ、そしお運甚時の遠隔監芖・遠隔蚺断・遠隔制埡介入たでを䞀連のパむプラむンずしお構成する取り組みも、 FastLabel 株匏䌚瀟様ずの連携䟋ずしおご玹介したした。動画像ず関節角床・圧力ずいったマルチモヌダルなデヌタを、時刻を揃えたたた時系列デヌタベヌスに蓄積できるこずが、この構成の前提になっおいたす。 収集したデヌタを䜿える圢に敎えるデヌタ加工レむダも重芁です。デヌタ収集レむダであるintdashから必芁な時系列デヌタを取埗し、解析凊理を行ったうえで、運甚に必芁な圢に出力する仕組みが求められたす。その䞀䟋ずしお、Power BIずintdashを連携させるデモを展瀺したした。 デヌタ収集レむダ・加工レむダ・掻甚レむダの3局構成 来堎者の反応 ブヌスでは、プラントや工堎の蚭備保党、倉庫や斜蚭の点怜業務のDX掚進など、さたざたな立堎の方にお立ち寄りいただきたした。 四足歩行ロボットによる巡回点怜の展瀺に぀いお、反応を倚く頂きたした。ロボットの導入を考えおはいるものの、たず䜕から始めればよいのか悩んでいる、ずいう声も倚くうかがいたした。 「カメラやセンサヌはすでに導入しおいるが、圢匏も呚期もばらばらで突き合わせられない」ずいった、デヌタのサむロ化に関する課題を挙げられる方もいらっしゃいたした。マルチモヌダルな時系列デヌタを時刻を揃えお収集するずいう intdash のアプロヌチに぀いお、その必芁性を実感を持っお受け止めおいただけたケヌスも倚かったように思いたす。 たずめ メンテナンス・レゞリ゚ンス 2026 にご来堎いただき、アプトポッドブヌスにお立ち寄りいただいた皆さた、誠にありがずうございたした。 アプトポッドは、intdash を通じお、珟堎点怜のロボット化・遠隔化、耇数のカメラやセンサヌを統合したリアルタむム可芖化、珟堎のデゞタルツむン化、ロボット・AI開発のためのデヌタ基盀ずいった、さたざたな領域で珟堎のデヌタ掻甚を支揎しおたいりたす。お困りごずがありたしたら、ぜひ お問い合わせフォヌム からご連絡ください。
蚈枬デヌタをもっず簡単に掻甚したいみなさん、 こんにちは、゜リュヌションアヌキテクトの䌊勢です。 収集された蚈枬デヌタを取埗・加工しおシステム連携するケヌスが増えおきたした。 今回は自分で実装せず、AI゚ヌゞェントにAPIの仕様を教えお実珟しおみたす。 GeoJSONを生成し、地図サヌビスで可芖化した結果をHTMLずしお公開したす。 はじめに intdash API やりたいこず Codexずは kepler.glずは やっおみた 緯床経床を可芖化 高床・速床を远加 衚瀺レむダヌ远加 写真サムネむルの远加 地図HTMLの公開 感想 うたくいったずころ REST APIの理解、蚈枬取埗 軌跡GeoJSONを調敎 S3でファむル公開 プロゞェクト内を敎理 詊行錯誀したずころ 写真デヌタのサムネむル䜜成 kepler.glでの画像衚瀺 おわりに はじめに intdash API 以前ご玹介した intdash API は保存枈みの蚈枬デヌタをREST APIで扱えたす。 このAPI仕様をAI゚ヌゞェントに理解しおもらいたす。 tech.aptpod.co.jp やりたいこず 䌑みを取っおJR芞備線に乗っおきたした。 JRで䞀番採算が取れない路線で廃線が議論されおいたす。 tetsudokyogikai.net GPS蚈枬デヌタ、駅情報、写真を地図䞊に重ねお、旅の流れを芋えるようにしたす。 デヌタフロヌ 耇数の入力デヌタを元に地図サヌビスで可芖化したす。 地図に茉せたい情報は以䞋です。 intdashのGPS(GNSS)蚈枬デヌタ タむムスタンプ 緯床経床 高床 速床 駅情報 緯床経床 駅名 旅の写真 撮圱時刻 EXIFの緯床経床 サムネむル画像URL 画像キャプション 手䜜業でやるず、API仕様の確認、デヌタ取埗、バむナリデコヌド、S3公開、むンタフェヌス向けの調敎など、地味な䜜業がたくさんありたす。 今回はこの䞀連の䜜業を Codex に䟝頌したした。 Codexずは コヌドの読み曞きやコマンド実行、ファむル生成、API調査などを行えるAI゚ヌゞェントです。 1 今回のポむントは、単にコヌドを曞いおもらうだけではありたせん。 intdash API仕様を確認する 実際にAPIぞ接続しおデヌタ構造を確認する プロトコルのペむロヌド仕様を読んでバむナリをデコヌドする 連携先で扱いやすいGeoJSONを怜蚎する 写真のEXIFを読み、サムネむルを䜜り、S3に公開する AI゚ヌゞェントはこういった「やりたいこずは明確だけど、途䞭に现かい䜜業が倚い」タスクを詊行錯誀し぀぀遂行しおくれたす。 kepler.glずは 䜍眮情報デヌタを地図䞊で可芖化できるWebアプリケヌションです。 GeoJSONやCSVなどをアップロヌドするず、点・線・ポリゎンなどの地理情報をレむダヌずしお衚瀺できたす。 今回生成したGeoJSONをアップロヌドし、HTMLずしお゚クスポヌトしたした。 2 kepler.gl やっおみた 緯床経床を可芖化 今回の䜜業は、最初から现かい仕様をすべお決めおいたわけではありたせん。 たずは、やりたいこずをざっくり䌝えたした。 intdash蚈枬デヌタを元に kepler.glにアップロヌドするためのGeoJSONを生成しおください。 入力デヌタには intdash Motion v2 のGNSS蚈枬デヌタを取埗したす。 intdashのAPI仕様の認蚌、蚈枬、蚈枬デヌタの取埗方法を確認しおください。 察象デヌタぱッゞ ise の日本時間2026/6/23に䜜成された耇数の蚈枬です。 䞀芧衚瀺しお確認させおください。 接続先サヌバヌ環境情報はプロゞェクトの .env に蚘茉しおいたす。 取埗する蚈枬デヌタは以䞋のずおりです。 緯床経床 取埗するデヌタ名は掚定しお候補を提瀺しおください。 2D Vectorペむロヌドフォヌマットで栌玍されおいたす。 緯床ず経床に分けお出力しおください。 蚈枬デヌタには1぀ず぀ タむムスタンプ が付䞎されおいたす。 GeoJSONに出力しおください。 タむムスタンプはYYYY-MM-DD hh:mm:ss.SSS圢匏でラベル属性ずしおも出力しおください。 この時点で䌝えおいたのは、察象デヌタ、API仕様、だいたいの出力むメヌゞです。 初回レスポンス 生成されたGeoJSON 出力されたGeoJSONをkepler.glのデモ画面にアップロヌドするず、早速軌跡が衚瀺されたした。 初回アップロヌド 途䞭で調敎も䟝頌したした。 kepler.glで可芖化できたした。 いく぀か修正しおください。 ・可読性のため、geojsonをむンデントフォヌマットしおください。 ・timestampは日本時間ずいうこずがわかるようにしおください。 ・labelがtime属性ず認識されおいたっおいたす。stringになるようにしおください。 高床・速床を远加 衚瀺項目を远加しおみたした。 3 以䞋の倉曎を加えおください。 ・同蚈枬から、高床・速床の蚈枬デヌタも取埗しお、項目ずしお付䞎しおください。 高床でグラデヌション 速床でグラデヌション 軌跡が北偎に凞になっおいる箇所が高地で䜎速のようです。 衚瀺レむダヌ远加 intdash以倖のデヌタも远加しお衚瀺したす。 kepler.glにアップロヌドするGeoJSONを远加したす。 むンタヌネットからJR芞備線の駅の情報を取埗しおください 緯床経床 駅名 たた、緯床経床のGeoJSONは線ずしお出力するよう倉曎しおください。 駅名レむダヌ远加䞋が北 䜎速だった区間は備埌萜合駅の付近のようです。 写真サムネむルの远加 ロヌカルファむルからのGeoJSON生成も䟝頌したした。 プロゞェクトの photo フォルダに旅の写真を眮いおありたす。 - QVGAサむズのサムネむルを䜜成 - EXIFから撮圱時刻、緯床経床を抜出 - サムネむルをAWS S3にアップロヌド・公開URL取埗 - サムネむルを画像認識しおキャプションを生成 - 撮圱時刻、緯床経床、キャプション、サムネむルURLからGeoJSONを䜜成 このように倚岐にわたる䜜業を䞀手に䟝頌できるのも魅力です。 写真GeoJSONの生成 地図HTMLの公開 最埌に地図の公開を䟝頌したした。 kepler.glからHTMLをダりンロヌドしおプロゞェクトに眮きたした。 S3に配眮しお公開URLを取埗しおください。 たた、プロゞェクト内のフォルダを敎理しお叀い䞍芁ファむルは削陀しおください。 HTMLファむルの公開 今回できた地図HTMLをS3で公開 しおいたす。 公開HTML 3皮類のデヌタを重ねたものです。 4 intdashの走行軌跡 沿線の駅 旅写真のサムネむルずキャプション 軌跡は速床で色分けしおいたす。 「どんなずころで䜕を芋たのか」振り返れる旅の蚘録になりたした。 感想 うたくいったずころ REST APIの理解、蚈枬取埗 CodexによるintdashのREST API仕様・アクセス方法を理解は滞りなく進みたした。 プロゞェクト゚ッゞ蚈枬を具䜓的なUUIDで指定しなかったので、 䜕らかの远加指瀺が必芁になるかず思っおいたのですが、 指瀺に該圓する蚈枬を自動で認識しおくれたした。 たた、蚈枬に含たれるデヌタIDを芋お、緯床経床は gnss_coordinates ず掚定しおくれたした。 実際のデヌタを数件取埗しお、仕様通りのデコヌドができるか、倀が劥圓かを確認しおくれたした。 デヌタIDの確認 gnss_coordinates は 2D Vector ずいう2倀圢匏で栌玍されおいたす。 仕様では、X/YそれぞれがIEEE754 64bit浮動小数点数で、ビッグ゚ンディアンです。 実際のAPIレスポンスでは、デヌタ本䜓は以䞋のようにBase64文字列ずしお返っおきたす。 " data ": { " d ": " QEFVC8tEtA1AYJfd1+VRuw== " } 「Base64をデコヌドしおください」ず明瀺的に指瀺したわけではありたせんが、CodexがAPIレスポンスの圢ず仕様を芋お、 data.d をBase64デコヌドし、16 bytesをビッグ゚ンディアンの double ずしお読む必芁がある、ず解釈しおくれたした。 " features ": [ { " type ": " Feature ", " geometry ": { " type ": " Point ", " coordinates ": [ 132.74583048619192 , 34.66442242483763 ] } , なお、GeoJSONの座暙は [longitude, latitude] の順なので、出力時には入れ替えおもくれたした。このあたりは人間が手でやるず間違えやすいずころです。 軌跡GeoJSONを調敎 最初はGNSSデヌタの緯床経床を点ずしお出力したした。 駅䜍眮の点ずあわせお衚瀺するず芋づらいため、線ずしお衚瀺するよう倉曎したずころ、色分けしやすいように平均高床・平均速床などを付䞎しおくれたした。 " properties ": { " altitude_start ": 198.84193365530137 , " altitude_end ": 196.83770584185308 , " altitude_avg ": 197.8398197485772 , " speed_start ": 0.9940862059593201 , " speed_end ": 0.5033005893230439 , " speed_avg ": 0.748693397641182 } S3でファむル公開 サムネむルずkepler.glのHTMLをAWS S3に配眮したした。 PCに導入枈みのAWS CLIを䜿っおもらいたしたが、アクセス情報はロヌカルのプロファルを䜿うよう指瀺しただけですんなり配眮できたした。 S3のサムネむルファむル プロゞェクト内を敎理 生成物が増えおきたのでプロゞェクト内を敎理したした。 䞍芁になった䞭間ファむルは削陀したした。 リファクタリングも気軜に行えたす。 詊行錯誀したずころ 写真デヌタのサムネむル䜜成 HEICからサムネむルを䜜るずころで少し詰たりたした。 PCに入っおいた ffmpeg で倉換しおもらいたしたが、写真の䞀郚だけが切り抜かれたようなサムネむルになりたした。 最終的には macOSのQuickLookを䜿っお、元写真党䜓からサムネむルを生成する方匏に倉曎したした。 結果ずしお、暪写真は 320x240 、瞊写真は 180x240 のように、写真党䜓を保持したサムネむルになりたした。 サムネむル生成修正 kepler.glでの画像衚瀺 最初は画像URLが単なる文字列ずしお衚瀺されおしたいたした。 そこで、kepler.glのTooltipで画像ずしお扱えるように "<img>-tooltip" ずいうプロパティ名に倉曎したした。 "<img>-tooltip": "https://example.s3.ap-northeast-1.amazonaws.com/xxx.png" サムネむル衚瀺 おわりに 今回の実行結果をTech Blog蚘事を執筆したす。 タむトルは AI゚ヌゞェントが旅の軌跡たずめおくれるUX です。 過去の私の蚘事の章立おを参考にドラフトを䜜成しおください。 https://tech.aptpod.co.jp/entry/2025/10/31/160000 今回は、Codexを䜿っお思い出をたずめるナヌザヌ䜓隓の旅に出かけたした。 やっおいるこず自䜓は、APIからデヌタを取埗しお、GeoJSONにしお、地図に茉せるだけですが、実際には现かい刀断がたくさんありたす。 API仕様のどこを読めばよいか どのデヌタ名が緯床経床なのか バむナリペむロヌドをどうデコヌドするか 連携サヌビスではどういうデヌタ圢匏が扱いやすいか 写真サムネむルが正しく衚瀺されおいるか S3の公開蚭定が正しいか これらをCodexず䌚話しながら進められるため、安心感が䌎いたした。 特に、䞀床衚瀺しおから方匏修正を繰り返せたのが実甚的でした。 AI゚ヌゞェントは、最初から完璧な成果物を䞀発で出すずいうより、状況に合わせお柔軟に調敎する随䌎者でいおもらうのがよさそうです。 5 心匷いから、自然に䞀歩を螏み出せる。そんな景色が芋えおきたした。 今回はVS Codeの拡匵機胜実装を利甚しおいたす。 ↩ 地図サヌビスのAPIによっおは、デヌタ連携もできたす。 ↩ GNSS内の項目は同じタむムスタンプが付䞎されおいるので䞀意に玐付けが可胜です。 ↩ ポむントにカヌ゜ルを圓おおも䞀床では写真が衚瀺されないこずがあるようです。 ↩ 生成AIの回答や生成物には誀りが含たれる可胜性がありたす。API仕様、デヌタ件数、公開蚭定などは実際に確認しながら利甚したす。 ↩
関連ニュヌス 出展の目的 䌚堎の印象 アプトポッドブヌスの展瀺 ベンチ蚈枬デヌタ統合基盀 デヌタ駆動型開発基盀 オペレヌション・デヌタ基盀 intdashの特城 来堎者の反応 䌚堎で気になった技術トレンド SDV デゞタルツむン たずめ こんにちは、アプトポッドの門脇です。 2026幎5月27日氎〜5月29日金にパシフィコ暪浜 ノヌスで開催された「人ずくるたのテクノロゞヌ展2026 YOKOHAMA」に出展したした。 今回、アプトポッドは 「開発珟堎のデヌタを統合、SDV時代の自動車開発をたるごずデヌタで繋ぐ」 をテヌマに、産業向けIoTミドルりェア intdash を䞭心ずした、自動車開発・補造珟堎におけるデヌタ掻甚の取り組みをご玹介したした。 アプトポッドブヌスの様子 関連ニュヌス 人ずくるたのテクノロゞヌ展2026 YOKOHAMA出展のお知らせ 出展の目的 自動車業界では、SDVSoftware Defined Vehicle化の進展により、車䞡開発・評䟡・補造の各プロセスで扱うデヌタがたすたす倚様化・倧容量化しおいたす。 実車、ベンチ、シミュレヌタ、補造蚭備、搬送機など、さたざたな堎所で発生するデヌタをどのように収集し、統合し、掻甚しおいくかは、今埌の開発スピヌドや品質向䞊においお重芁なテヌマです。 今回の展瀺では、こうした課題に察しお、intdashを掻甚したデヌタ基盀のあり方を、以䞋の3぀の゜リュヌション軞でご玹介したした。 ベンチ蚈枬デヌタ統合基盀 デヌタ駆動型開発基盀 オペレヌション・デヌタ基盀 䌚堎の印象 䌚堎では、SDV、AI、デヌタ掻甚、シミュレヌション、補造DXなど、自動車開発の倉化を感じる展瀺が倚く芋られたした。 特に印象的だったのは、個別の車䞡性胜や郚品技術だけでなく、開発プロセス党䜓をどう倉えおいくか、取埗したデヌタをどう掻甚しおいくか、ずいう芖点の展瀺が増えおいた点です。 アプトポッドブヌスの展瀺 アプトポッドブヌスでは、intdashを䞭心に、自動車開発・補造珟堎におけるデヌタ統合・掻甚のナヌスケヌスをご玹介したした。 今回のブヌスでは、ベンチ蚈枬デヌタ統合基盀、デヌタ駆動型開発基盀、オペレヌション・デヌタ基盀の3぀の展瀺テヌマを甚意したした。 䞭でも、実際の蚈枬機噚を䜿っおデヌタ収集・可芖化の流れを確認できる ベンチ蚈枬デヌタ統合基盀 には、倚くの方に足を止めおいただきたした。 ベンチ蚈枬デヌタ統合基盀 ベンチ詊隓や評䟡環境では、耇数メヌカヌの蚈枬機噚や解析ツヌルが䜿われるこずが倚く、デヌタ圢匏や管理方法が分散しおサむロ化しやすいずいう課題がありたす。 今回の展瀺では、ASAM芏栌に準拠した蚈枬デヌタの同期収集ず統合管理を軞に、耇数の蚈枬機噚から埗られるデヌタをメヌカヌを問わず統合し、既存の管理システムや解析ワヌクフロヌぞ接続する流れをご玹介したした。 蚈枬デヌタをリアルタむムに可芖化するデモ 単にデヌタを取埗するだけでなく、取埗埌の管理、怜玢、再利甚、解析自動化たでを芋据えた基盀ずしお、intdashの掻甚可胜性を感じおいただける展瀺になったず思いたす。 耇数の蚈枬機噚・センサヌを接続したデモ構成 デヌタ駆動型開発基盀 SDV時代の車䞡開発では、実車詊隓、ベンチ詊隓、シミュレヌション、AI、モデルベヌス開発などを組み合わせながら、開発サむクルを回しおいくこずが重芁になりたす。 展瀺では、ASAM暙準、生成AI、シミュレヌタヌを組み合わせたデヌタ駆動型の車䞡開発プロセスに぀いおご玹介したした。 蚈枬から怜蚌、モデリングたでを䞀気通貫で支揎するデヌタ基盀ずしお、intdashがどのように掻甚できるかをお䌝えしたした。 オペレヌション・デヌタ基盀 補造・生産・珟堎オペレヌションの領域では、フレキシブル生産、無人化、デゞタルツむン、Physical AI、ROS、フィヌルドバスなど、さたざたな技術が実運甚に近づいおいたす。 䞀方で、珟堎には既存蚭備、搬送機、センサヌ、カメラ、PLCなどが混圚しおおり、デヌタが分断されやすいずいう課題がありたす。 Physical AI、ROS、フィヌルドバスなどを玹介したオペレヌション・デヌタ基盀の展瀺 今回の展瀺では、intdashを掻甚しお搬送機やOT蚭備、各皮センサヌ・フィヌルドバスのデヌタを柔軟に぀なぎ、オペレヌション党䜓を可芖化・最適化しおいくアプロヌチをご玹介したした。 たた、自動運転むけ遠隔監芖のデモでは、車䞡や呚蟺状況を耇数のカメラ映像・デヌタず合わせお確認できる構成をご玹介したした。 自動運転むけ遠隔監芖デモの画面 intdashの特城 intdashは、さたざたなセンサヌ、車茉機噚、゚ッゞデバむス、アプリケヌションを぀なぎ、リアルタむムなデヌタ収集・可芖化・保存・掻甚を支揎する産業向けIoTミドルりェアです。 今回の展瀺でも、耇数デバむス・耇数拠点のデヌタ統合、時刻同期されたデヌタの収集・管理、遠隔監芖、API連携などをご玹介したした。 展瀺しおいた゚ッゞデバむスや呚蟺機噚 自動車開発や補造珟堎では、CAN、センサヌ、カメラ、蚭備、搬送機、シミュレヌタなど、倚様なデヌタが発生したす。 intdashは、それらのデヌタを暪断的に぀なぎ、珟堎の課題解決や開発プロセスの改善に぀なげるための基盀ずしお掻甚できたす。 来堎者の反応 ブヌスでは、車䞡開発、実隓・評䟡、品質管理、研究開発など、さたざたな立堎の方にお立ち寄りいただきたした。 特に反応が倧きかったのは、ベンチ蚈枬デヌタ統合基盀の展瀺です。実際の蚈枬機噚を䜿ったデモ構成だったこずもあり、蚈枬デヌタの収集・同期・可芖化・再利甚ずいったテヌマに぀いお、具䜓的な利甚シヌンをむメヌゞしおいただきやすかったように感じたす。 䌚話の䞭では、「デヌタが分散しおいる」「圢匏が揃わない」「取埗したデヌタを十分に掻甚しきれおいない」ずいった課題が倚く残っおいるこずも感じたした。 䌚堎で気になった技術トレンド 今回の展瀺䌚で個人的に気になったのは、 SDV ず デゞタルツむン です。 SDV 䌚堎では、SDV時代の開発効率を高めるための゜リュヌションが倚く展瀺されおいたした。 デヌタ管理、シミュレヌション、評䟡、解析、゜フトりェア開発環境などを䞀䜓で扱う開発プラットフォヌムずしお提案しおいる展瀺もあり、開発プロセス党䜓を支える基盀ずしお構成されおいる点が興味深かったです。 車䞡機胜が゜フトりェア䞭心になるほど、実車、ベンチ、シミュレヌタ、仮想化環境、AIなどのデヌタをどのように぀なぎ、開発サむクルを効率化するかが重芁になるず感じたした。 デゞタルツむン デゞタルツむンの領域では、車䞡挙動や走行環境を再珟するシミュレヌタに加えお、人の感芚や印象を評䟡するための展瀺も芋られたした。 特に印象的だったのは、感性工孊に特化したドラむビングシミュレヌタです。走行性胜や制埡だけでなく、乗り心地、操䜜感、安心感、違和感ずいった人の感芚に近い領域を評䟡しようずしおいる点が興味深いず感じたした。 デゞタルツむンを掻甚するうえでも、珟実䞖界のデヌタを正しく収集し、シミュレヌションや解析環境に接続するこずが重芁だず感じたした。 たずめ 今回の人ずくるたのテクノロゞヌ展2026 YOKOHAMAでは、SDV時代の自動車開発においお、デヌタを「取る」「芋る」だけでなく、「぀なぐ」「掻甚する」こずの重芁性を改めお感じたした。 アプトポッドブヌスでご玹介した3぀の゜リュヌション軞は、以䞋の動画でもご芧いただけたす。 www.youtube.com www.youtube.com www.youtube.com 自動車開発・補造の珟堎では、今埌も扱うデヌタの皮類や量が増え続けおいきたす。アプトポッドは、intdashを通じお、自動車開発、ベンチ蚈枬、補造珟堎、搬送機・搬送ロボット、デゞタルツむンなど、さたざたな領域のデヌタ掻甚を支揎しおいきたす。 ブヌスにお立ち寄りいただいた皆さた、誠にありがずうございたした。
はじめに 前回の蚘事 では、Webアプリで映像を扱う際の産業甚途におけるリアルタむムコミュニケヌション実珟のための怜蚎ポむントず、intdashずintdash-RTC SDKずいう遞択肢を玹介したした。 芁点をおさらいするず: SFU遞定時はベンダヌ固有の実装に䟝存する点も考慮が必芁 センサヌデヌタずの統合や録画・解析は远加の蚭蚈が必芁になる可胜性 intdashは、産業甚途に適したもう䞀぀の遞択肢 前線では抂芁しか觊れなかったため、実際の䜿甚感に぀いお興味をお持ちいただいた方もいらっしゃるず思いたす。 本蚘事では、intdash-RTC SDKの具䜓的な実装方法をサンプルコヌド付きで解説したす。環境が準備できおいれば、玄30分で動䜜するビデオチャットが完成したすので、ぜひお詊しください。 ラむブラリの抂芁 intdashは映像・音声・センサヌデヌタを統合しお䌝送できるプラットフォヌムです。intdash-RTC SDKは、intdashで扱うデヌタのうち映像・音声をWebアプリから簡単に扱えるようにするラむブラリです。 本ラむブラリは3぀のむンタヌフェヌスで構成されおいたす。 ┌─────────────────────────────────────────────┐ │ MediaConnection │ 統合管理 ├─────────────────────┬──────────────────────── │ MediaSender │ MediaReceiver │ 送受信 └─────────────────────┮───────────────────────┘ | ^ v | ┌─────────────────────────────────────────────┐ │ intdash (iSCP) │ 䌝送 └─────────────────────────────────────────────┘ MediaConnection: 送受信を統合管理。 start() / stop() で接続制埡 MediaSender: ロヌカルメディアをintdashに送信 MediaReceiver: intdashからメディアを受信し、video芁玠に盎接接続 本ラむブラリは、TypeScript 向けのintdash通信ラむブラリ iscp-ts のラッパヌずしおも利甚できたすし、今回のようなアプリケヌションでは接続蚭定を盎接指定するシンプルな䜿い方も可胜です。 実装ステップ 以䞋では、基本的なビデオチャットを実装するサンプルコヌドを5぀のステップに分けお玹介したす。党量は蚘事末尟の「Appendix: サンプルコヌド党文」に再掲しおいたす。 1. ラむブラリのimportずMediaConnectionの䜜成 // 1. ラむブラリのimport import { createMediaConnection } from "@aptpod/intdash-rtc" ; // 2. MediaConnectionの䜜成intdashぞの接続も内郚で行いたす const { mediaConnection } = await createMediaConnection( { address : "your-intdash.example.jp" , // intdash接続アドレス projectUuid : "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" , // intdashプロゞェクトのUUID nodeId : "yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy" , // 送信元自分偎のノヌドUUID enableTLS : true , apiToken : "your_token_here" , // intdash Web Consoleから䜜成したAPIトヌクンOAuth2サむンむンを䜿う堎合はapiTokenを省略 } , { sender : { // 音声に関する蚭定 audio : { codec : "PCM" , // PCM, OPUS, AACをサポヌト } , // 映像に関する蚭定 video : { codec : "H264" , // H264, VP9をサポヌト } , } , receiver : { sourceNodeIds : [ "zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzz" ] , // 通信盞手のノヌドUUID } , } , ); @aptpod/intdash-rtc が今回のintdash-RTC SDKです。これをimportするだけで、intdashを介したビデオチャットが実装できたす @aptpod/iscp-ts は peer dependency ずしお䜵せおむンストヌルが必芁です。 createMediaConnection 関数で、intdashぞの接続ずMediaConnectionの䜜成をたずめお行いたす。第1匕数で接続情報アドレス・プロゞェクトUUID・ノヌドUUID・APIトヌクンを、第2匕数で送受信オプションを指定したす。これらの倀は intdash Web Console から取埗できたす。APIトヌクンは長期間有効な固定トヌクンですが、より安党なワンタむムトヌクンやOAuth2による認蚌も利甚可胜です。送受信オプションは階局化された構造になっおおり、 sender.audio で音声蚭定、 sender.video で映像蚭定、 receiver で受信察象ノヌドを指定したす。コヌデックは型安党な文字列リテラル型で指定でき、蚭定ミスを防ぎたす。 2. ロヌカルメディアの取埗ず衚瀺 // 3. ロヌカルメディアストリヌムの取埗ず蚭定 const localStream = await navigator .mediaDevices. getUserMedia ( { video : true , audio : true , } ); await mediaConnection.sender.setLocalMediaStream(localStream); // ロヌカル映像をvideo芁玠に衚瀺 const localVideoEl = document . getElementById ( "local-video" ) as HTMLVideoElement ; localVideoEl.srcObject = new MediaStream (localStream.getVideoTracks()); localVideoEl.muted = true ; await localVideoEl.play(); getUserMedia でカメラずマむクからストリヌムを取埗し、 setLocalMediaStream で蚭定したす。取埗したストリヌムはそのたたロヌカルのvideo芁玠にも衚瀺できたす。 3. 受信メディアのvideo芁玠ぞの接続 // 4. 受信メディアストリヌムの凊理 const remoteVideoEl = document . getElementById ( "remote-video" , ) as HTMLVideoElement ; mediaConnection.receiver.on( "statechange" , ( state ) => { if (state === "running" ) { // 受信が開始されたら、video芁玠に盎接接続 mediaConnection.receiver.attach(remoteVideoEl); } else if (state === "stopped" || state === "failed" ) { // 受信が停止したら、video芁玠から切断 mediaConnection.receiver.detach(remoteVideoEl); } } ); 受信偎の状態倉化は statechange むベントで監芖したす。 running になったら attach() でvideo芁玠に盎接接続できたす。内郚の倉換凊理デコヌド等はintdash-RTC SDKが凊理するため、意識する必芁がありたせん。 4. 接続開始 // 5. 接続開始running状態たで埅機 await mediaConnection.start( { waitUntil : "running" } ); console . log ( "接続が確立したした" ); start({ waitUntil: 'running' }) で接続を開始し、 running 状態になるたで埅機したす。これにより、接続が完党に確立しおから次の凊理に進めたす。 5. UI操䜜ず停止凊理 // 6. UI操䜜映像・音声の有効/無効切り替え document . getElementById ( "toggle-video" )?. addEventListener ( "click" , async () => { const enabled = await mediaConnection.sender.setVideoEnabled( !mediaConnection.sender.videoEnabled, ); console .log( `映像: ${ enabled ? "有効" : "無効" } ` ); } ); document . getElementById ( "toggle-audio" )?. addEventListener ( "click" , async () => { const enabled = await mediaConnection.sender.setAudioEnabled( !mediaConnection.sender.audioEnabled, ); console .log( `音声: ${ enabled ? "有効" : "無効" } ` ); } ); // 7. 停止凊理クリヌンアップ document . getElementById ( "stop" )?. addEventListener ( "click" , async () => { await mediaConnection. stop (); await mediaConnection.iscpConn. close (); localStream.getTracks(). forEach (( track ) => track. stop ()); console .log( "接続を終了したした" ); } ); setVideoEnabled / setAudioEnabled で映像・音声を個別に制埡できたす。終了時は stop() でメディア凊理を停止し、 iscpConn.close() でintdash接続もクロヌズしたす。内郚のワヌクレットやバッファも自動的にクリヌンアップされたす。 実際の動䜜の確認 このように、WebRTCず遜色ない簡朔さで、intdashを䜿った映像・音声通信を実装できたす。 実際にサンプルアプリを動䜜させた様子が以䞋の動画です。 youtu.be 画面の巊偎がサンプルアプリ「Easy Video Chat」、右偎がintdashに付属する簡易可芖化ツヌル「Edge Finder」です。 サンプルアプリ「Easy Video Chat」には「あなた」巊ず「盞手」右の2぀の映像衚瀺がありたす。今回のデモでは送信元ず受信元のノヌドを同䞀に蚭定しおいるため、巊右に同じ映像が衚瀺されおいたす。巊の「あなた」は getUserMedia で取埗したロヌカル映像をそのたた衚瀺したもの、右の「盞手」はそのロヌカルメディアをintdashぞ送信したあず再床受信しおデコヌド・衚瀺したものです。 実際に二者間で通話する堎合は、盞手偎でも同様にintdashぞの接続ず受信元ノヌドの指定を行うこずで、双方向での映像・音声通話が成立したす。 同時にEdge Finder偎では、送信されたH.264映像フレヌムずPCM音声デヌタが、それぞれ時系列のデヌタポむントずしおintdashに蚘録されおいく様子が確認できたす。 さらなる拡匵性 デヌタの可芖化ずダッシュボヌドのカスタマむズ 動画で玹介した「Edge Finder」はintdashに暙準で付属しおおり、送受信されおいるデヌタをすぐに確認できる簡易ツヌルです。 より高床な可芖化やダッシュボヌドのカスタマむズが必芁な堎合は、匊瀟の可芖化アプリケヌション「VM2M Data Visualizer」をご利甚いただけたす。ノヌコヌドで時系列デヌタのダッシュボヌドを構築でき、映像ずセンサヌデヌタを時刻同期させた再生や、倚圩なりィゞェットを組み合わせた解析画面の䜜成に察応しおいたす。 VM2M Data Visualizer: 耇数の映像ず時系列デヌタを時刻同期しお再生するタむムラむンビュヌ VM2M Data Visualizer: ゲヌゞ・グラフ・レヌダヌチャヌトなど倚圩なりィゞェットを組み合わせたカスタムダッシュボヌド Appendix: サンプルコヌド党文 ここたでステップごずに分割しお玹介しおきたサンプルコヌドの党量を、以䞋に再掲したす。 // 1. ラむブラリのimport import { createMediaConnection } from "@aptpod/intdash-rtc" ; // 2. MediaConnectionの䜜成intdashぞの接続も内郚で行いたす const { mediaConnection } = await createMediaConnection( { address : "your-intdash.example.jp" , // intdash接続アドレス projectUuid : "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" , // intdashプロゞェクトのUUID nodeId : "yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy" , // 送信元自分偎のノヌドUUID enableTLS : true , apiToken : "your_token_here" , // intdash Web Consoleから䜜成したAPIトヌクンOAuth2サむンむンを䜿う堎合はapiTokenを省略 } , { sender : { // 音声に関する蚭定 audio : { codec : "PCM" , // PCM, OPUS, AACをサポヌト } , // 映像に関する蚭定 video : { codec : "H264" , // H264, VP9をサポヌト } , } , receiver : { sourceNodeIds : [ "zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzz" ] , // 通信盞手のノヌドUUID } , } , ); // 3. ロヌカルメディアストリヌムの取埗ず蚭定 const localStream = await navigator .mediaDevices. getUserMedia ( { video : true , audio : true , } ); await mediaConnection.sender.setLocalMediaStream(localStream); // ロヌカル映像をvideo芁玠に衚瀺 const localVideoEl = document . getElementById ( "local-video" ) as HTMLVideoElement ; localVideoEl.srcObject = new MediaStream (localStream.getVideoTracks()); localVideoEl.muted = true ; await localVideoEl.play(); // 4. 受信メディアストリヌムの凊理 const remoteVideoEl = document . getElementById ( "remote-video" , ) as HTMLVideoElement ; mediaConnection.receiver.on( "statechange" , ( state ) => { if (state === "running" ) { // 受信が開始されたら、video芁玠に盎接接続 mediaConnection.receiver.attach(remoteVideoEl); } else if (state === "stopped" || state === "failed" ) { // 受信が停止したら、video芁玠から切断 mediaConnection.receiver.detach(remoteVideoEl); } } ); // 5. 接続開始running状態たで埅機 await mediaConnection.start( { waitUntil : "running" } ); console . log ( "接続が確立したした" ); // 6. UI操䜜映像・音声の有効/無効切り替え document . getElementById ( "toggle-video" )?. addEventListener ( "click" , async () => { const enabled = await mediaConnection.sender.setVideoEnabled( !mediaConnection.sender.videoEnabled, ); console .log( `映像: ${ enabled ? "有効" : "無効" } ` ); } ); document . getElementById ( "toggle-audio" )?. addEventListener ( "click" , async () => { const enabled = await mediaConnection.sender.setAudioEnabled( !mediaConnection.sender.audioEnabled, ); console .log( `音声: ${ enabled ? "有効" : "無効" } ` ); } ); // 7. 停止凊理クリヌンアップ document . getElementById ( "stop" )?. addEventListener ( "click" , async () => { await mediaConnection. stop (); await mediaConnection.iscpConn. close (); localStream.getTracks(). forEach (( track ) => track. stop ()); console .log( "接続を終了したした" ); } ); おわりに 本蚘事では、intdash-RTC SDKを䜿ったビデオチャットの実装方法を芋おきたした。 ポむントのたずめ: WebRTCず同等の簡朔さで、intdash経由のビデオチャットを実装可胜 最初はビデオチャットから始めお、将来はセンサヌデヌタを含むマルチモヌダルシステムぞ拡匵できるのがintdashの匷みです。同じプラットフォヌム、同じSDKで察応できるため、技術遞定で埌悔するリスクを枛らせたす。 「詊しおみたい」「もう少し詳しく知りたい」ずいう方は、ぜひお気軜に お問い合わせ ください。本ラむブラリは珟圚お問い合わせベヌスでの個別提䟛ずなっおいたす。
はじめに WebRTCずいう暙準的な遞択肢 産業甚途での怜蚎ポむント SFUの遞定ず移行コスト センサヌデヌタずの統合 録画・解析システムの構築 intdashずいう遞択肢 Webアプリからintdashを䜿う ― intdash-RTC SDK ナヌスケヌス おわりに はじめに Webアプリケヌションでリアルタむムな映像通信を実装したい。ビデオ通話、遠隔支揎、リアルタむム監芖...。こうしたニヌズは幎々高たっおいたす。 リアルタむムな映像通信を実装するずき、たず候補に挙がるのがWebRTCです。ブラりザ暙準で䜿え、䜎遅延な双方向通信が可胜で、実瞟も豊富。倚くの開発者が最初に怜蚎する遞択肢でしょう。 ただ、産業甚途で本栌的に掻甚するには、远加の怜蚎が必芁になるこずもありたす。本蚘事では、産業甚途での怜蚎ポむントを敎理し぀぀、intdashずいう遞択肢を玹介したす。 WebRTCずいう暙準的な遞択肢 WebRTCWeb Real-Time Communicationは、ブラりザ間で䜎遅延な双方向通信を実珟するための技術です。P2Pによるダむレクトな通信が可胜で、ビデオ䌚議、ラむブカスタマヌサポヌト、オンラむン蚺療など、さたざたなナヌスケヌスで広く採甚されおいたす。 WebRTCの匷み: ブラりザ暙準: 䞻芁ブラりザでネむティブサポヌト、远加プラグむン䞍芁 䜎遅延な双方向通信: P2Pによる盎接接続で、遅延を最小限に抑えた通信を実珟 豊富な実瞟: ビデオ䌚議ツヌルやオンラむン蚺療など、倚くのサヌビスで採甚 SFUベンダヌの充実: Twilio、Agora、時雚堂等、倚くの遞択肢 「暙準芏栌だからベンダヌロックむンされない」ずいう声もよく聞きたす。確かにWebRTC自䜓はRFCで暙準化されたプロトコルです。 産業甚途での怜蚎ポむント WebRTCは汎甚的で優れた技術ですが、産業甚途で本栌的に掻甚するには、远加の怜蚎や工倫が必芁になるこずがありたす。 SFUの遞定ず移行コスト WebRTCの接続方匏P2P vs SFU WebRTCの「暙準」が芏定するのは、䞻にブラりザ間のP2P通信です。 P2Pは1察1の通信に向いおいたすが、参加者が増えるず各端末の送受信負荷が急増するため、倚人数での通信にはSFUSelective Forwarding Unitが必芁になりたす。しかし、SFUは各ベンダヌが独自に実装しおおり、ルヌム管理、認蚌、録画ずいった機胜もベンダヌごずにAPIが異なりたす。 たた、利甚芏暡の拡倧や新たな機胜芁件により、SFUベンダヌの乗り換えが必芁になるこずもありたす。その堎合、ベンダヌ固有のAPIに䟝存した郚分は䜜り盎しになるため、遞定時には将来的な移行コストも考慮に入れおおくず良いでしょう。 センサヌデヌタずの統合 産業甚途では、映像だけでなくセンサヌデヌタも䞀緒に扱いたいケヌスがありたす。たずえば、車䞡の走行映像ずCANデヌタ・GPS、建蚭珟堎の監芖映像ずセンサヌ情報、補造ラむンの映像ず蚭備デヌタ、ずいった組み合わせです。 WebRTCでこれを実珟する堎合、DataChannelを掻甚する方法がありたす。ただし、DataChannelはデヌタの送受信のみを提䟛するため、センサヌデヌタの栌玍フォヌマットや映像ずの時刻同期の仕組みは、自前で定矩・実装する必芁がありたす。 録画・解析システムの構築 「送信した映像を埌から芋返したい」「解析に䜿いたい」ずいう芁件も倚いです。 WebRTCでは、録画や解析の機胜は暙準で提䟛されおいたせん。SFUベンダヌが録画機胜を提䟛しおいる堎合もありたすが、解析・可芖化たで含めたシステムを構築する堎合は、远加の開発が必芁になるこずがありたす。 intdashずいう遞択肢 匊瀟が開発するintdashは、こうした産業甚途のニヌズを想定しお蚭蚈された䌝送プラットフォヌムです。 intdashの匷み: マルチモヌダル察応: 映像、音声、センサヌデヌタを統合しお䌝送可胜 倧容量・䜎遅延: モバむル回線経由でも高頻床デヌタを䌝送可胜 時刻同期が暙準装備: すべおのデヌタに共通の基準時刻でタむムスタンプ 保存・解析・可芖化たで䞀気通貫: サヌバヌに保存し、Data Visualizerでノヌコヌド可芖化・再生が可胜 Webアプリからintdashを䜿う ― intdash-RTC SDK intdashでWebアプリから映像・音声のリアルタむム通信を行う堎合は、intdash-RTC SDKを䜿甚できたす。 intdash-RTC SDKは、intdashを甚いたリアルタむムコミュニケヌションを実装するためのSDKです。 intdashの通信クラむアントをラップしお利甚するこずで、リアルタむムコミュニケヌションの実装をWebRTCのようなシンプルなむンタヌフェむスで実珟できたす。 intdash-RTC SDKは、3぀のむンタヌフェむスで構成されおいたす: MediaConnection: 接続の開始・停止 MediaSender: 映像・音声を送信 MediaReceiver: 映像・音声を受信 さらに、センサヌデヌタの統合や録画・可芖化ずいったintdashの機胜も䜵せお掻甚できたす。 実装の流れは以䞋のずおりです。シンプルなビデオチャットであれば、数十行のコヌドで実装できたす: // 1. intdashに接続 const iscpConn = await iscp.Conn.connect( { address , connector , tokenSource , nodeId } ) // 2. メディア接続を蚭定 const mediaConnection = createMediaConnection(iscpConn, { video : { codec : 'H264' , ... } , audio : { codec : 'PCM' , ... } , receive : { sourceNodeIds : [ 盞手のノヌドID ] } } ) // 3. ロヌカルメディアを送信 const stream = await navigator .mediaDevices. getUserMedia ( { video : true , audio : true } ) await mediaConnection.sender.setLocalMediaStream(stream) // 4. リモヌト映像を衚瀺 mediaConnection.receiver.on( 'statechange' , state => { if (state === 'running' ) mediaConnection.receiver.attach(videoElement) } ) // 5. 接続開始 await mediaConnection.start() 具䜓的な実装方法は埌線で解説したす。 ナヌスケヌス intdash-RTC SDKは、以䞋のようなナヌスケヌスで掻甚できたす。 ビデオ通話・遠隔支揎: 䜜業者同士のリアルタむムコミュニケヌション、技術支揎 遠隔監芖: 珟堎の映像をリアルタむムで確認、必芁に応じおセンサヌデヌタも統合 デヌタ収集: 映像ずセンサヌデヌタを時刻同期しお収集・解析 おわりに Webアプリでリアルタむムな映像通信を実珟するずき、WebRTCは有力な遞択肢です。ビデオ䌚議やラむブ配信など、倚くのナヌスケヌスで実瞟がありたす。䞀方で、産業甚途においおセンサヌデヌタずの統合や録画・解析が求められる堎合は、远加のシステム構築が必芁になるこずがありたす。 intdashは、そうしたニヌズに察応した、WebRTCずは異なるアプロヌチの映像䌝送プラットフォヌムです。Webアプリから利甚する堎合は、intdash-RTC SDKを䜿うこずで、シンプルなむンタヌフェむスでintdashの機胜を掻甚できたす。 次回の蚘事では、intdash-RTC SDKを䜿った具䜓的な実装方法をサンプルコヌド付きで解説したす。「実際どれくらい簡単なの」ずいう疑問にお答えしたすので、ぜひご芧ください。 本ラむブラリは珟圚お問い合わせベヌスでの個別提䟛ずなっおいたす。ご興味のある方は、お気軜に お問い合わせ ください。
開発・怜蚌甚にintdashサヌバヌを動かしたい゚ンゞニアのみなさん、 こんにちは、゜リュヌションアヌキテクトの䌊勢です。 intdashの2025幎版からDockerでサヌバヌ環境を構成できるようになりたした。 補品マニュアルペヌゞで サヌバヌの構築 の1パタヌンずしお AWS EC2䞊のDocker簡易環境 の構築手順を公開しおいたす。 1 今回はその理解を助けるため、各ステップの目的・準備・結果確認を噛み砕いおintdash環境を構築し、サヌバヌのログや蚭定を確認しおみたす。 2 はじめに 党䜓の流れ サヌバヌ構成 AWS CDK 構築手順むメヌゞ 手順前提 ツヌル準備 環境構築 準備 EC2むンスタンス構築 アプリ起動 起動確認 SSLサヌバヌ蚌明曞蚭眮 サヌバヌドメむン名の準備 Let's Encryptで蚌明曞蚭定 メヌルサヌバヌ蚭定 管理者ナヌザヌ蚭定 Google Maps APIキヌ蚭定 蚈枬開始 intdash Motion起動 ログ確認 確認コマンド 蚈枬時のログ確認 WebSocket接続 蚈枬新芏䜜成 アップストリヌム開始 基準時刻受信 デヌタ䌝送 蚈枬停止 負荷確認 AWSコン゜ヌル top コマンド 蚭定 蚭定確認 蚭定倉曎 バック゚ンドログむン詊行回数倉曎 フロント゚ンドロゎ倉曎 おわりに はじめに 党䜓の流れ 党䜓像を捉えられるようにサヌバヌの構成から説明したす。 サヌバヌ構成の説明 EC2䞊にDockerでintdashサヌバヌを構築 ブラりザ・Motionから接続確認 デヌタ送信ずログ確認 負荷・デヌタ・蚭定の確認 サヌバヌ構成 通垞、intdashのサヌバヌサむドは、2皮類のむンスタンスで構成されたす。 3 APIむンスタンス Webサヌバヌ、API、認蚌、デヌタ䌝送、デヌタやメディア管理 DBむンスタンス ナヌザヌ゚ッゞ蚈枬の保存、蚈枬の時系列デヌタの保存 通垞のむンスタンス・サヌビス構成 簡易環境では、1぀のEC2むンスタンスにAPI/DB双方のサヌビスが同居したす。 4 EC2簡易環境 AWS CDK 簡易環境の構築にはAWS CDKAWS Cloud Development Kitを利甚したす。 AWS CDKずはむンフラ構成をコヌドで蚘述したもので、このコヌドは AWS CloudFormation のテンプレヌトに倉換されたす。 AWS CloudFormation は、むンフラ構成を定矩したテンプレヌトで自動的に構築・曎新・削陀するサヌビスです。 CDKで生成したテンプレヌトをもずに CloudFormation がむンフラを構築・曎新・削陀を自動化、状態を管理したす。 構築手順むメヌゞ 構築手順は倧たかに ①〜③むンフラ構築 ④〜⑥アプリ構築 にわかれたす。 構築手順 䜜業甚PC AWS CDKでテンプレヌトを生成しおCloudFormationを起動したす。 AWS CloudFormation テンプレヌトず元にAWSリ゜ヌスを構築したす。 EC2むンスタンス Docker Composeで各サヌビスのコンテナを構成・起動したす。 コンテナ構成定矩から環境倉数を読み蟌みたす。 手順前提 事前に以䞋が必芁です。 䜜業甚PC AWS CLI、およびAWS CDKを実行したす。 マニュアルのコマンドはLinux準拠です。 5 AWSアカりント EC2などのリ゜ヌスが構築されるAWS環境です。 AWS IAMナヌザヌ 䜜成するAWSリ゜ヌスに暩限が付䞎されおいる必芁がありたす。 intdashラむセンス アクティベヌションキヌ intdashサヌバヌを有効化するため、蚭定したす。 intdashラむセンスを契玄するず発行されたす。 サヌバヌドメむン名 サヌバヌにFQDNでアクセスするために必芁です。 今回はAWS Route53で払い出す手順を玹介したす。 ツヌル準備 䜜業甚PCに必芁なツヌルがむンストヌルされおいるか確認したす。 AWS CLI EC2ぞのSSH接続時、AWS CDK実行時の認蚌に䜿いたす。 Node.js Node.js 本䜓のバヌゞョン管理ツヌルです。 npm パッケヌゞを実行ツヌルです。AWS CDKスクリプトを実行したす。 aws --version node -v nvm --version npm --version Node.jsのバヌゞョンが叀かったので最新版をむンストヌルしたした。 AWS CLI、Node.js / npmの確認 環境構築 準備 マニュアルの通り、以䞋を準備したす。 6 AWS CLIの認蚌情報 キヌペア䜜成、AWS CDKデプロむ時の認蚌のために蚭定したす。 AWS CLI認蚌情報 EC2むンスタンス構築 ここからむンフラ構築を始めたす。 たず、䜜業甚PCで実行するデプロむ資材をダりンロヌドしたす。 CDK資材ダりンロヌド むンタラクティブモヌドでAWS CDKのセットアップを開始したす。 セットアップ開始 今回、intdash最新バヌゞョンにあわせおRocky Linux 9むメヌゞを䜿甚したす。 7 rockylinux.org Version: 9.7 Region: ap-northeast-1 Architecture: x86_64 Rocky Linux9.7むメヌゞのAMI IDをコピヌ 確認したRocky Linux 9むメヌゞのAMI IDを指定しおデプロむしたす。 たた、削陀時のElastic IP保持を指定しおいたす。 Elastic IPを確認 生成されたペアキヌを安党な堎所に眮き、 EC2むンスタンスにログむンできるか確認したす。 mv ./intdash-trial-key.pem ~/.ssh ssh -i ~/.ssh/intdash-trial-key.pem rocky@ < Elastic IP > sudo su - intdash ログむン確認 アプリ起動 セットアップが完了するず、すでにintdashサヌバヌが起動しおいたす。 起動確認 ブラりザで https://intdash.<Elastic IP>.nip.io にアクセスしたす。 ログむン画面 ログむンしおProject Consoleが衚瀺されるこずを確認したす。 Project Console画面 もしアクセスできない堎合はログを確認したす。 # ステヌタス確認 sudo systemctl status intdash-trial Docker Composeの党コンテナのログを確認する方法です。 auth-1 などコンテナ名が衚瀺されたす。 # リアルタむム衚瀺 journalctl -u intdash-trial -f # 盎近100行 journalctl -u intdash-trial -n 100 # 盎近10分 journalctl -u intdash-trial --since " 10 minutes ago " 党コンテナログ ログむンできない堎合、Authentication Serviceのログを確認したす。 特定コンテナのログを衚瀺する方法です。 Docker Composeのサヌビス名 auth を指定したす。 cd ~/deployment/ # 盎近100行 docker compose -f docker-compose.yml logs auth | less # 盎近10分 docker compose -f docker-compose.yml logs auth --since 10m | less 特定コンテナログ SSLサヌバヌ蚌明曞蚭眮 このたたではHTTPS通信ができたせん。 ブラりザではアクセスできたすが、今回゚ッゞずしお利甚する intdash Motion でアクセスできたせん。 続きの手順でHTTPS通信できるようにしたす。 SSLサヌバヌ蚌明曞蚭眮前 今回は以䞋のように準備したした。 サヌバヌドメむン名 今回はAWS Route 53で取埗したす。 サヌバヌドメむン名の準備 本蚘事甚に取埗しおいたす。 AWS Route53でドメむン名を賌入したす。最安で$15/幎です。 ドメむン賌入 登録に数分かかりたす。 完了するずVerifyメヌルが届きたす。クリックしたす。 ドメむン登録のVerifyメヌル EC2むンスタンスのIPアドレスを割り圓おるサブドメむンのレコヌドを䜜成したす。 サブドメむンレコヌド䜜成 党䞖界のDNSサヌバヌに登録が開始され、しばらくするず名前解決できたす。 8 dig < サブドメむン名 > 名前解決成功 Let's Encryptで蚌明曞蚭定 EC2むンスタンス䞊でHTTPS通信のための蚌明曞・秘密鍵を生成したす。 Let’s Encrypt の蚌明曞発行ツヌル Certbot をむンストヌルする前に、Rocky Linuxのパッケヌゞ管理コマンド DNFDandified Yum で远加パッケヌゞリポゞトリ EPELExtra Packages for Enterprise Linux をむンストヌルしたす。 sudo dnf install -y epel-release sudo dnf makecache EPELむンストヌル マニュアル通り、Certbot でSSLサヌバヌ蚌明曞ず秘密鍵を発行したす。 SSLサヌバヌ蚌明曞・秘密鍵発行 intdashサヌビス起動の前に、デプロむ資材の環境倉数 FQDN を取埗したサブドメむン名に倉曎したす。 FQDN倉曎 これで intdash Motion でHTTPSアクセスできるようになりたす。 intdash MotionでHTTPSアクセス メヌルサヌバヌ蚭定 マニュアル通りにメヌル蚭定を環境倉数に远加したす。 元の AUTH_SMTP_ADDRESS: " mail:1025 " AUTH_SMTP_HOSTNAME: " auth " はコメントアりトしたす。 9 メヌルサヌバヌず通知メヌル送信元を蚭定 AUTH_SMTP_PASSWORD に蚭定する <Gmail甚のアプリパスワヌド> は Googleアカりント > 2段階認蚌プロセス > アプリ パスワヌド で発行したす。 アプリパスワヌドの発行 管理者ナヌザヌ蚭定 マニュアル通り、管理者ナヌザヌのメヌルアドレスを登録したす。 メヌルアドレス远加 確認メヌル メヌルアドレス確認枈み Google Maps APIキヌ蚭定 Google Maps APIキヌを準備したす。 Map JavaScript APIを有効化したす。 自サむトだけで利甚できるようりェブサむトでアプリケヌションの制限を蚭定しおおきたす。 Google Maps APIキヌ準備 あずはマニュアル通り、Google APIキヌを蚭定したす。 Google Maps APIキヌ蚭定前 Google Maps APIキヌ蚭定埌 蚈枬開始 intdash Motion起動 intdash Motion の蚈枬を起動したす。 アップストリヌムを Edge Finder 、䜜成された蚈枬を Meas Hub で確認したす。 Edge Finderの確認 Meas Hubの確認 ログ確認 確認コマンド 党コンテナのログは journalctl で確認できたす。 journalctl -u intdash-trial -f journalctl -u intdash-trial -n 100 journalctl -u intdash-trial --since " 10 minutes ago " 各テナントのログはDocker Composeの logs コマンドで確認できたす。 cd deployment/ docker compose -f docker-compose.yml logs < container > | less docker compose -f docker-compose.yml logs < container > --since 1h | less なお、本構成では特にDocker Composeのロギング蚭定をしおいたせん。 10 蚈枬時のログ確認 蚈枬起動時のBroker Serivceコンテナのログを確認しおみたす。 docker compose -f docker-compose.yml logs broker -f Broker Serviceコンテナログ WebSocket接続 Motionで蚈枬を開始するず、䞀床WebSocketが切断されたす。 "msg":"Received Disconnect" その埌、改めおWebSocketの接続ログが出力されたす。 "msg":"Received WebSocket:\tua:Motion/49 CFNetwork/3860.400.51 Darwin/25.3.0 referer: remote_ip:xxx.xxx.xxx.xxx:46928 proto:HTTP/1.1" "msg":"Received ConnectRequest request_id:0 protocol_version:2.0.0" "msg":"Authenticated by OAuthToken subject:c82b7aba-b9e1-46a8-a8b4-87c7384ce140" 蚈枬新芏䜜成 "msg":"Received","tenant_id":0,"project_id":"00000000-0000-0000-0000-000000000000","user_id":"c82b7aba-b9e1-46a8-a8b4-87c7384ce140" "path":"/api/v1/projects/00000000-0000-0000-0000-000000000000/measurements" アップストリヌム開始 "msg":"Received UpstreamOpenRequest request_id: 2 session_id: 6fd90f07-0dca-47f0-8419-776b995bc876 qos: unreliable ack_interval: 100ms expiry_interval: 1m0s persist: true" "msg":"Succeeded in opening upstream. id=[4f5442cf-74e3-4f98-9695-0f566f5a3127] qos=[unreliable]","tenant_id":0,"message_track_id":"8565-2830-1198","transport_track_id":"4629-1820-3724" 基準時刻受信 "msg":"Received UpstreamMetadata request_id: 4 metadata: *message.BaseTime" 蚈枬開始からここたでが䞀気に出力されたす。 デヌタ䌝送 継続䞭は以䞋が続きたす。 "msg":"MessageCount rx: 0 [msg/sec] tx: 3 [msg/sec]","tenant_id":0,"message_track_id":"6601-6588-7707","transport_track_id":"1239-5713-3538" .. "msg":"MessageCount rx: 1 [msg/sec] tx: 6 [msg/sec]","tenant_id":0,"message_track_id":"6601-6588-7707","transport_track_id":"1239-5713-3538" 蚈枬停止 Motionで蚈枬を停止するず以䞋が出力されたす。 "msg":"Received UpstreamCloseRequest request_id: 8 stream_id: 4f5442cf-74e3-4f98-9695-0f566f5a3127" stream_id は Succeeded in opening upstream. の id ず䞀臎しおいたす。 負荷確認 運甚でよく確認するサヌバヌ負荷を芋おみたす。 Motion から以䞋のデヌタを5分間ほど送信したす。 わかりやすく負荷を䞊げるために映像デヌタを最倧量で送信しおみたした。 11 映像: H.264 FullHD 30 FPS 8.2 Mbps 音声: PCM IMU GPS 瞬間的に8〜12 Mbps超 AWSコン゜ヌル AWSコン゜ヌルで掚移を確認したす。 AWSコン゜ヌルの確認 CPUが40%、デヌタ受信が40 MB≒ 5.5 Mbpsを超えおいたす。 top コマンド top コマンドでメモリの掚移を確認したす。 top コマンド確認 メモリ䜿甚は 6.5 GBを超えおいたす。 なお、デヌタ栌玍領域 /data が 98 GB ほど䜿われおいたす。 df コマンド確認 蚭定 蚭定確認 秘匿情報や環境固有情報は、デプロむ資材の .env ファむルからDocker Composer蚭定ファむルに䌝播するようになっおいたす。 䟋えば、先ほど蚭定した FQDN は NGINX_SERVER_NAME などに䌝播したす。 docker-compose.yml 蚭定倉曎 では、䞀郚の蚭定を倉曎しおみたしょう。 バック゚ンドログむン詊行回数倉曎 わかりやすい䟋ずしお Authentication Service の蚭定を倉曎したす。 Authentication Service user-password attempt-limit : パスワヌド詊行回数のリミット デフォルト倀: 5 この回数間違えるずナヌザヌはロックされたす。 正しいパスワヌドでもログむンできなくなりたす。 ログむンするにはロック解陀かパスワヌド再発行が必芁です。 Authentication Serviceの項目を持぀ docker-compose.api.yml を線集したす。 パスワヌド詊行回数のリミットを1回に倉曎したす。 サヌビス名、セクション名、蚭定項目を぀なげお項目名を AUTH + _ + USER_PASSWORD + _ + ATTEMPT_LIMIT にしたす。 AUTH_USER_PASSWORD_ATTEMPT_LIMIT : 1 サヌビス auth を再起動したす。 docker compose up -d auth パスワヌド詊行回数の倉曎・再起動 Admin Consoleでナヌザヌ test を䜜り、ログむンを1床倱敗したす。 ログむン倱敗 intdash ナヌザヌで test ナヌザヌを確認するず "ロック䞭" になっおいたす。 ログむン詊行1回倱敗でロック䞭 フロント゚ンドロゎ倉曎 䟋倖ずしお、フロント゚ンドはWebデプロむ資材を盎接曞き換えたす。 今回はData Visualizerのロゎを倉曎しおみたす。 暙準は画面巊䞊に出おくる VISUAL M2M の画像です。 暙準ロゎ 以䞋の蚭定項目を倉曎したす。 VM2M Data Visualizerフロント゚ンド vm2m-2nd-configの蚭定 header logoImgURL : Data Visualzierのヘッダロゎ AWS S3に配眮・公開した 幅200px、高さ56px のPNGファむルを指定したす。 PNGファむルS3配眮 cd deployment/ vi docker/ui-conf/vm2m-data-viz-backend/config/vm2m-2nd-config/vm2m-2nd-config.production.json " header ": { " logoImgURL ": " https://s3.ap-northeast-1.amazonaws.com/<S3_BUCKET_NAME>/docker.png " } , vm2m-2nd-configの線集 Data Visualizerサヌビスを再起動しおData Visualizerを衚瀺したす。 docker compose restart vm2m-data-viz-backend カスタムロゎ おわりに Dockerで開発甚のintdash環境を構築しおみたした。 普段は意識しないサヌビスやDB構造を確認するこずで理解が深たり、 蚭定やログ、パフォヌマンスを芋るこずで運甚むメヌゞが぀きたした。 蚭定項目は他にも倚くあるので、たた別の機䌚にご玹介できればず思いたす。 簡易環境の構築方法ずしおは、これたでAWS マヌケットプレむスにAMIを提䟛しおいたした。コンテナむメヌゞずDocker Composeでの仮想化により、AWS以倖での構築方法ず統合され、バヌゞョン最新化も容易になりたした。 ↩ 構築および運甚手順はintdashの公匏マニュアルをご参照ください。閲芧にはナヌザヌ登録が必芁です。 ↩ 冗長構成では各サヌビスごずにむンスタンスが现分化、たたスケヌルアりトしたす。 ↩ 簡易環境は開発甚途の構成であり、本栌的な運甚には向きたせん。本番環境向けの構成は Kubernetes たたは RPM で構築したす。 ↩ WindowsではWSLのUbuntu環境などで実行できたす。 ↩ 本蚘事では、基本的に公匏マニュアルに沿っお進め、各ステップで「どういう目的で䜕が行われおいるか」「構築結果をどう確認するか」にフォヌカスしお解説したす。 ↩ 利甚するAMI IDはリヌゞョンなどにより異なるため、Rocky Linux公匏サむトで最新のものを確認しおください。 ↩ ICMPポヌトは開けおいないため、pingは通りたせん。 ↩ デフォルトではコンテナ内のSMTPmailコンテナを䜿甚しおいたすが、倖郚SMTPGmail等を利甚するように倉曎したす。 ↩ ログはDockerコンテナが再䜜成されるず消えおしたいたす。必芁に応じお Docker Compose の蚭定で syslog 等で倖郚保存したす。 ↩ なお、Motion偎のWi-Fi垯域を超えおおり、デヌタ量の86.4 %しか送信できおいたせん。 ↩
映像デヌタでデヌタ分析したいみなさん、 こんにちは、システムアヌキテクトの䌊勢です。 特定甚途で映像を解析するAIモデルを䜜るのは倧倉です。 本蚘事では、映像をそのたた解析するのではなく、 生成AIでフレヌムをテキストに芁玄し、CSVずしお分析するアプロヌチを玹介したす。 はじめに 映像のAI解析 コンセプト 映像フレヌムのテキスト芁玄 党䜓構成図 むンストヌル クラむアントラむブラリ OpenAIパッケヌゞ やっおみた ロヌカル線の車窓映像 分析課題 プロンプト デヌタ分析 雪囜の垂バス映像 分析課題 プロンプト デヌタ分析 起動オプション サンプルプログラム説明 芁玄入力デヌタ量・頻床削枛 グリッド画像生成 JPEG圧瞮率指定 キュヌサむズ䞊限指定 トヌクン数超過刀定 OpenAI問い合わせ アップストリヌム おわりに リンク はじめに 映像のAI解析 本ブログでは、事前孊習したAIモデルでの物䜓怜出をご玹介したした。 SDK入門④でYOLOで物䜓怜出・矩圢描画・人数カりントしおいたす。 tech.aptpod.co.jp ただし、これらのAIモデルは事前孊習による開発が必芁です。 軜めのPoCなど利甚シヌンに応じお、本栌的な専甚モデル開発を䌎わず、察象物の怜出や文字読み取りが実珟できるず䟿利です。 コンセプト 本ブログでは、蚈枬結果をChatGPTでデヌタ分析しおきたした。 tech.aptpod.co.jp tech.aptpod.co.jp 数倀や文字列をCSVファむルでChatGPTに䞎え、怜玢や統蚈ができたす。 しかし、映像はバむナリデヌタであるため、単玔に同じ方法は䜿えたせん。 そこで、映像フレヌムをテキストデヌタ化しおCSVでデヌタ分析しおみたす。 映像フレヌムのテキスト芁玄 映像フレヌムをAIモデルに芁玄・蚘述させ、テキストデヌタに倉換したす。 1 OpenAIの chat.completions APIに 映像フレヌムをBase64゚ンコヌドしおリク゚ストしたす。 qiita.com 生成AI掻甚で重芁なのは、すべおを送るのではなく「䜕を送らないか」の蚭蚈です。 粟床・安定性のため、映像フレヌムを間匕き・集玄しおデヌタ量ず頻床を抑えたす。 2 # 工倫 効果 1 映像フレヌムを瞮小 デヌタ量䜎枛 2 前フレヌムずの差分が䞀定以䞊のずきだけ 頻床䜎枛 3 4×4グリッド画像に時系列圧瞮 頻床䜎枛 4 JPEG圧瞮 デヌタ量䜎枛 5 リク゚スト埅ちを2件たでに制限 頻床䜎枛 6 トヌクン数超過したらスキップ 頻床䜎枛 これらは前凊理が必芁なのでintdash SDKを䜿っお実装したす。 3 党䜓構成図 intdash リアルタむムAPIからダりンストリヌムした映像フレヌムを グリッド状に䞊べた画像ず芁玄結果をアップストリヌムしたす。 芁玄結果は、あずでCSVでダりンロヌドしお蚈枬党䜓の分析を行いたす。 党䜓構成図 むンストヌル クラむアントラむブラリ REST API、リアルタむムAPIの䜿い方は SDK入門④ ず同じです。 OpenAIパッケヌゞ 远加でOpenAIラむブラリをむンストヌルしたす。 pip install openai やっおみた ロヌカル線の車窓映像 分析課題 2024幎11月、房総半島を走る久留里線の䞀郚区間久留里駅䞊総亀山駅間が廃止されるず発衚されたした。 利甚客の激枛による䞍採算が理由だそうです。 www.sankei.com 実際に乗車しおきたした。 4 朚曎接駅を出発しお、廃線予定の久留里駅〜終点䞊総亀山駅たでを走る区間です。 5 蚈枬ず芁玄結果を可芖化したした。 6 youtu.be プロンプト 画像を芁玄させるプロンプトを chat.completions APIに枡したす。 あなたは列車のカメラ映像4x4グリッドの時系列画像を芁玄するAIです。 遠景を含む、人物・居䜏・移動・むンフラ管理から人間生掻の兆候を怜出したす。 出力は必ず以䞋のJSON圢匏で返しおください。 { "person": 人物の数 int, "group": 集団の有無 無/有, "view": 芖野 無/狭/äž­/広, "area": ゚リア皮別 垂街地/䜏宅地/蟲地/草地/山野 etc, "building": 䜏宅密床 無/疎/密, "road": 道路幅 無/现/倪, "infra": 蚭備の敎備床 無/荒/敎, "text": 画像から読み取れる文字グリッド巊䞊の時刻は陀く, "description": 芋える颚景の説明 } 有効なJSONのみを出力しおください。 このようなJSONが返っおきたす。 7 { " person ": 3 , " group ": " 無 ", " view ": " 広 ", " area ": " 垂街地 ", " building ": " 疎 ", " road ": " 倪 ", " infra ": " 敎 ", " text ": " 28 ", " description ": " 垂街地の道路沿いにある建物ず車䞡、バむクが芋える颚景。呚囲には草朚が生えおいる。 " } リアルタむムで芁玄した結果をintdashにアップストリヌムしたす。 python ./lesson10/src/analyze_video.py --api_url https://example.intdash.jp --api_token < YOUR_API_TOKEN > --project_uuid < YOUR_PROJECT_UUID > --edge_uuid < YOUR_EDGE_UUID > --openai_key < YOUR_OPENA_KEY > プログラム起動 Data Visualizerでリアルタむム可芖化 以䞋の項目が衚瀺されおいたす 入力デヌタ画面巊䞊 GNSSデヌタ H.264映像 出力デヌタ画面䞭倮・右偎・䞋偎 プレビュヌ画像グリッドを埋めおいる途䞭の画像JPEG 芁玄察象画像グリッドが埋たっお芁玄察象になった画像JPEG 芁玄結果JSON内の項目 デヌタ分析 それでは、分析を行いたす。 課題 ロヌカル線の利甚者数はそんなに少ないのか。 Data Visualizerでデヌタを遞択しおCSVファむルをダりンロヌドしたす。 intdash Motionアプリ GNSSデヌタ グリッド画像の芁玄結果 JSONの各項目 https://example.intdash.jp/vm2m/?playMode=storedData&startTime=2026-01-12T14:54:44.000%2B09:00&endTime=2026-01-12T16:05:04.000%2B09:00 CSVダりンロヌド CSVファむル ChatGPTにCSVファむルをアップロヌドしお、基本情報を確認したす。 ロヌカル線走行䞭のGNSSデヌタ、カメラ映像の芁玄結果のCSVデヌタをアップロヌドしたす。 GNSSデヌタ緯床経床、速床、高床、方䜍、芁玄結果人物数、集団有無、芖界の広さ、゚リア皮別、建物密床、道路広さ、むンフラ敎備床、文字起こし、説明が含たれたす。 課題ロヌカル線の利甚者数はそんなに少ないのか。 のためにデヌタ分析を行いたす。 以䞋を確認しおください。 - 項目の䞀芧 - デヌタ行数 - タむムスタンプ範囲 デヌタの確認 デヌタ項目を敎えたす。 デヌタを敎えおください。 - 芋やすさのため、項目名の"GNSS_"ず"@"以降を削陀しおください。 - 空の倀が含たれたす。GNSSデヌタに぀いおは盎前の倀を䜿甚しお穎埋めforward fillしおください。 たた、 - 分析結果のグラフは英語で、本文は日本語で衚蚘しおください。 デヌタクレンゞング たずはシンプルに聞いおみたす。 怜出した人数の最倧倀、集団を怜出したか、 を教えおください。 人物・集団怜出の結果 グラフや地図で可芖化しおみたす。 人数が 0人 / 1–2人 / 3人以䞊 の時間割合 集団が 無 / 有 の時間割合 をそれぞれグラフにしおください。 人数、集団有無の割合グラフ GNSSの緯床経床デヌタを、PythonのFoliumを䜿っお以䞋をプロットしおください。 以䞋を可芖化しおください。 ・人物怜出箇所・人数 ・集団怜出箇所 人数・集団の地図プロット 怜出されたのはいずれも朚曎接駅発の前半区間であり、廃線予定の久留里駅以南では人物・集団が芋られたせん。 8 ただし、誀怜出の箇所があり、粟床は専甚AIモデルに劣りそうです。 墓石を人間ず間違えおそう 今床は地図䞊に、゚リア皮別を色分けしおプロットしおください。 ゚リア皮別 èµ€ 垂街地 オレンゞ 䜏宅地 緑 草地 濃緑 蟲地 青 山野 久留里駅以南ははっきりず山野が倚いのがわかりたす。 9 同じく、各芁玄結果をプロットしたした。 建物密床 èµ€ 密 濃緑 疎 青 無 道路幅 èµ€ 倪 濃緑 现 グレヌ 他 むンフラ敎備床 濃緑 敎 黒 荒 グレヌ 無 文字起こしの粟床も芋おみたす。 文字起こしできた文字列をリスト化しおください。 文字起こしリスト 沿線に看板などがそれほど倚くはないようです。 耇数行の堎合は改行コヌド付きです。 JPEGの画質を萜ずしおいるため、"俵田"駅の誀字が目立ちたす。 結論 1回の蚈枬では久留里駅以南で"混雑"を確認できなかった。 䞀方で、沿線環境の特城を読み解くのには有効な情報が埗られた。 車窓から広がる自然の眺めは、思わず時間を忘れおしたう魅力がある。 雪囜の垂バス映像 プロンプトを差し替えお別のデヌタ分析を行いたす。 北海道 千歳垂街〜新千歳空枯たでのバス映像です。 分析課題 2026幎1月13日、寒波到来により、積雪による亀通麻痺等が懞念されおいたした。 www.uhb.jp 実際に行っお確認しおきたした。 10 千歳垂街でバスに乗り蟌み、新千歳空枯たで走りたす。 11 蚈枬ず芁玄結果を可芖化したした。 12 youtu.be プロンプト プロンプトをこのように差し替えたす。 あなたは豪雪地垯の垂バスのカメラ映像4x4グリッドの時系列画像を芁玄するAIです。 亀通・積雪・陀雪状態から生掻の支障具合を怜出したす。 出力は必ず以䞋のJSON圢匏で返しおください。 { "person": 人物の数 int, "vehicle": 車䞡の数 int, "view": 芖野 無/狭/äž­/広, "area": ゚リア皮別 垂街地/䜏宅地/郊倖/トンネル/空枯 etc, "depth": 建物・暹朚・車䞊の積雪 無/少/倚, "sidewalk": 歩道の陀雪 未/äž­/枈, "pile": 路肩の堆雪 無/少/倚, "text": 画像から読み取れる文字グリッド巊䞊の時刻は陀く, "description": 芋える颚景の説明 } 有効なJSONのみを出力しおください。 このようなJSONが返っおきたす。 { " person ": 1 , " vehicle ": 1 , " view ": " äž­ ", " area ": " 垂街地 ", " depth ": " 倚 ", " sidewalk ": " äž­ ", " pile ": " 倚 ", " text ": " 消火栓 ", " description ": " 雪が積もった垂街地の道路に、歩道ず車道があり、人の人物ず1台の車が芋える。 " } プロンプト蚭定ファむルを指定しおプログラムを起動したす。 python ./lesson10/src/analyze_video.py --api_url https://example.intdash.jp --api_token < YOUR_API_TOKEN > --project_uuid < YOUR_PROJECT_UUID > --edge_uuid < YOUR_EDGE_UUID > --openai_key < YOUR_OPENA_KEY > --prompt_path ./lesson10/config/snow.txt プロンプト差し替えで起動 プロンプト差し替えで可芖化 デヌタ分析 分析を行いたす。 課題 豪雪地垯の陀雪は行き届いおいるか。 Data Visualizerでデヌタを遞択しおCSVファむルをダりンロヌドしたす。 CSVダりンロヌド CSVファむル ChatGPTにCSVファむルをアップロヌドしお、基本情報を確認したす。 豪雪地域の垂バス走行䞭のGNSSデヌタ、カメラ映像の芁玄結果のCSVデヌタをアップロヌドしたす。 GNSSデヌタ緯床経床、速床、高床、方䜍、芁玄結果人物数、車䞡数、芖界の広さ、゚リア皮別、建物・暹朚・車䞊の積雪状況、歩道の陀雪状況、路肩の堆雪状況、文字起こし、説明が含たれたす。 課題豪雪地垯の陀雪は行き届いおいるか。 のためにデヌタ分析を行いたす。 以䞋を確認しおください。 - 項目の䞀芧 - デヌタ行数 - タむムスタンプ範囲 デヌタの確認 デヌタクレンゞング 今回はいきなりグラフ化しおみたす。 歩道の陀雪状況の割合 をグラフで衚瀺しおください。 歩道の陀雪状況グラフ 文字化けしおいたすが、巊から 未 / äž­ / 枈 の順で䞊んでいたす。 枈 ず刀断されたのは40以䞋、 未 は50%超です。 ただし、陀雪埌も完党に歩道が芋えないケヌスでは画像で癜く芋えるため、刀断の粟床は高くなさそうです。 陀雪状況が刀断が難しそうなケヌス もう少し詳しく芋おみたしょう。 GNSSの緯床経床デヌタを、PythonのFoliumを䜿っお以䞋をプロットしおください。 以䞋を可芖化しおください。 ・歩道の陀雪状況 歩道の陀雪状況のプロット èµ€ 未 オレンゞ 䞭 濃緑 枈 グレヌ 他 垂街や亀差点、空枯構内はおおむね陀雪率が高そうです。 他の項目も可芖化しおみたしょう。 今床は地図䞊に、゚リア皮別を色分けしおプロットしおください。 垂街地/䜏宅地/郊倖/トンネル/空枯 etc で色分けしおください。 ゚リア皮別 èµ€ 垂街地 青 䜏宅地 濃緑 郊倖 玫 トンネル オレンゞ 空枯 ピンク 他 ゚リア皮別ごずの陀雪率を確認しおみたす。 ゚リア別の陀雪状況 未/äž­/枈 を積み䞊げグラフ化しおください。 グラフ内の文蚀は英語に蚳しお衚瀺しおください。 ゚リア別陀雪状況 空枯ず刀断された゚リアは陀雪率が80超、垂街地は郚分的も含めるず70匱です。 郊倖の陀雪率は20に留たっおおり、歩行者が倚い゚リアを優先しお陀雪されおいるのがわかりたす。 トンネルはそもそも積雪がありたせんが、陀雪も 未 ず刀断されおいたす。 トンネル内は 積雪無 か぀ 陀雪未 他の芳点でも芋おみたしょう。 路肩の堆雪ず芖界の広さを組み合わせお、 路肩の堆雪により、芖界を確保できないず思われるポむントをプロットしおください。 芖界確保リスクポむント Data Visualizerで芋るず確かに該圓時刻は倧きな堆雪が映っおおり、歩道の状況がほずんど芋えたせん。 13 該圓時刻の映像 結論 陀雪は限られたリ゜ヌスで極めお効率的に行われおいるこずが䌺える。 倧動脈である空枯は"最優先"で守られおいる。 起動オプション --api_url required サヌバヌURL --api_token required APIトヌクン --project_uuid プロゞェクトUUID省略時は Global Project --edge_uuid required ダりンストリヌム゚ッゞUUID --dst_edge_uuid アップストリヌム゚ッゞUUID --openai_key required OpenAI アクセスキヌ --prompt_path システムプロンプトファむルパス サンプルプログラム説明 耇雑に芋えたすが、 SDK入門④ ず同じく各凊理をシンプルな非同期ステヌゞに分けお䞊列起しおいたす。 クラスアヌキテクチャ 芁玄入力デヌタ量・頻床削枛 グリッド画像生成 フレヌムを瞮小したす。 img = np.frombuffer(frame, dtype=np.uint8).reshape((self._in_h, self._in_w, 3 )) tile_img = cv2.resize( img, (self._tile_w, self._tile_h), interpolation=cv2.INTER_AREA ) 前フレヌムず珟フレヌムの差異が閟倀未満なら、スキップしたす。 ヒストグラム化しお比范しおいたすが、堎合によっおはもっず厳密に刀定する方がいいかもしれたせん。 if self._prev_tile_hist is not None : d = cv2.compareHist(self._prev_tile_hist, cur_h, cv2.HISTCMP_BHATTACHARYYA) if d < self._diff_threshold: return None , False self._prev_tile_hist = cur_h 4x4グリッドに配眮したす。 for i, t in enumerate (self._tiles[: self._grid_size]): c = i % self._cols x0 = c * self._tile_w r = i // self._cols y0 = r * self._tile_h grid[y0 : y0 + self._tile_h, x0 : x0 + self._tile_w] = t JPEG圧瞮率指定 JPEG゚ンコヌドの GStreamer パむプラむンに蚭定しおいたす。 QUALITY = 50 ... quality=QUALITY, キュヌサむズ䞊限指定 self.prompt_queue: asyncio.Queue[ int ] = asyncio.Queue(maxsize=chat_maxsize) トヌクン数超過刀定 try : answer = await asyncio.to_thread(self.chatter.chat, frame) ... except RateLimitError as e: logging.info(f "RateLimitError! {e}" ) await asyncio.sleep( 0.5 ) OpenAI問い合わせ JPEG画像をBase64゚ンコヌドしおリク゚ストに付䞎しおいたす。 MODEL = "gpt-4o-mini" ... image_b64 = base64.b64encode(image).decode( "utf-8" ) messages: list [ChatCompletionMessageParam] = [ { "role" : "system" , "content" : self.system_prompt}, { "role" : "user" , "content" : [ { "type" : "image_url" , "image_url" : { "url" : f "data:image/jpeg;base64,{image_b64}" }, }, ], }, ] resp = self.client.chat.completions.create( model=MODEL, messages=messages, max_tokens= 400 , temperature= 0.3 , response_format={ "type" : "json_object" }, ) アップストリヌム 芁玄結果をアップストリヌムしおいたす。 await self.up.write_data_points( iscp.DataID(name=self.data_name_answer, type = "string" ), iscp.DataPoint( elapsed_time=elapsed_time, payload=payload.encode( "utf-8" ), ), ) await self.up.flush() おわりに SDKを利甚しお映像デヌタをテキスト芁玄、生成AIでデヌタ分析したした。 たた、プロンプトを差し替えお芁玄内容を倉曎できたした。 AI開発が䞍芁になるため、スマヌトメンテや巡回点怜PoCを詊しやすくなりそうです。 今回はむンタヌネット経由でAPI゚ンドポむントを䜿甚しおいたす。 14 生成AI利甚のネットワヌク遅延やトヌクン数に瞛られないため、Ollama などの怜蚎も有効そうです。 tech.aptpod.co.jp tech.aptpod.co.jp リンク 本シリヌズの過去蚘事はこちらからご芧ください。 SDK入門①〜瀟甚車で走ったずこ党郚芋せたす〜 REST APIでデヌタ取埗 SDK入門②〜デヌタ移行ツヌルの䜜り方〜 REST APIでデヌタ送信 SDK入門③〜RTSPで映像配信するぞ〜 リアルタむムAPIでデヌタ取埗 SDK入門④〜YOLOで物䜓怜知しちゃう〜 リアルタむムAPIでデヌタ送信 SDK入門⑀〜iPadでData Visualizerを芋る䌚〜 リアルタむムAPIでキャプチャデヌタ送信 SDK入門⑥〜最速最高床で蚈枬する日〜  AWS LambdaでREST APIデヌタ送信 SDK入門⑊〜蚈枬リプレむツヌルの䜜り方〜  REST APIでデヌタ取埗、リアルタむムAPIでデヌタ送信 SDK入門⑧〜動画アップロヌドツヌルの䜜り方〜 REST APIで映像デヌタ送信 SDK入門⑚〜動画ダりンロヌドツヌルの䜜り方〜 REST APIでデヌタ取埗、ファむル化 今回、モデルはOpenAIの gpt-4o-mini を䜿甚したす。テキストも画像も入力できるマルチモヌダルモデルです。芖芚粟床ではVLMが有利ですが、intdashから映像以倖のデヌタも枡せるこずを想定しお、マルチモヌダルモデルを遞択しおいたす。 ↩ 同時にOpenAIのAPIトヌクン消費量も䜎枛しおいたす。 ↩ サンプルプログラムを GitHub にお公開しおいたす。 ↩ 2024幎2月に蚈枬を行いたした。 ↩ 䞀床収集した蚈枬デヌタを SDK入門⑊〜蚈枬リプレむツヌルの䜜り方〜 でリアルタむムで再アップストリヌムしおいたす。 ↩ 1時間ほどありたす。飛ばしながら芋おください。 ↩ たたに 道路幅:现 のように指定から厩れる堎合がありたす。 ↩ 進行方向右偎の映像のみで刀定しおいたす。巊偎にホヌムある駅が倚かったので実態より少なく怜出されおいるかもしれたせん。 ↩ プロンプトで䞎えた䟋 垂街地/䜏宅地/蟲地/草地/山野 の区分けに匕きずられおそうです。プロンプトの䞎え方次第でもっず有意矩な分類ができるかもしれたせん。 ↩ 吹雪の数日埌の2026幎1月18日に蚈枬を行いたした。 ↩ こちらも蚈枬デヌタを SDK入門⑊〜蚈枬リプレむツヌルの䜜り方〜 で再アップストリヌムしおいたす。 ↩ 16分ほどです。再生速床を調敎などしお芋おください。 ↩ 他の該圓ポむントでは倧きなフェンスが映っおいたりするため、厳密性は高くなさそうです。 ↩ 消費トヌクンの埓量課金です。開発を通じお、長時間デヌタを流しっぱなしにしないように気を぀けお䜿い、$4.40分を消費したした。 ↩
蚈枬䞭の通話蚘録を残したいみなさん、 収集した音声デヌタを分析したいみなさん、 こんにちは、゜リュヌションアヌキテクトの䌊勢です。 運行管理など発話によるコミュニケヌションが必芁な堎面がありたす。 今回は運行モビリティデヌタずあわせお音声を収集できるアプリをご玹介したす。 はじめに 音声通話アプリ開発䞭 やっおみた アプリ利甚 いい点 改善点 ChatGPT解析 CSVダりンロヌド デヌタ分析 おわりに はじめに 音声通話アプリ開発䞭 iPhoneアプリ Speak Cast仮 は音声デヌタを intdash サヌバヌず送受信したす。 1 アプリ画面開発䞭 通話ができるアプリは Zoom / Teams / LINE など色々ありたすが、intdashで他の蚈枬デヌタず時系列をあわせおデヌタ保存できるのが特城です。 䞻に以䞋の機胜を持っおいたす。 音声デヌタ送信PCM、AAC 音声テキスト化・デヌタ送信文節単䜍、文章単䜍 GNSSデヌタ送信緯床、経床、高床、速床 通話先゚ッゞからのデヌタ受信・音声デヌタ、テキストデヌタ ミュヌト自分、通話先゚ッゞごず 音声デヌタ送信蚭定 やっおみた ちょうど瀟甚車での出匵がありたしたので、以䞋の構成で詊したした。 瀟甚車の搭乗者1名 遠隔監芖者3名 党䜓構成図 アプリ利甚 実際のリアルタむム蚈枬ずプレむバック再生のようすです。 youtu.be 䜿っおみた感想です。 いい点 ちゃんず䌚話できおいる 手軜に音声を送受信できおいたす。 蚈枬に残る 過去デヌタずしお再生した際も䌚話ずしおなりたっおいたす。 無音時はデヌタ送信されずに通信量節玄 長時間蚈枬だず嬉しい機胜です。 改善点 テキスト化゚ンゞンの粟床・安定性 通話者の滑舌のせいか文字起こしされたテキストの誀りが目立ちたす。 ゚ンゞンの芋盎しで改善される範囲ず思いたす。 ChatGPT解析 この蚘事は実はここからが本番です。 音声デヌタがテキスト化されるこずで、自然蚀語分析ができるようになりたす。 こちらの蚘事の方法でデヌタ分析を行いたす。 tech.aptpod.co.jp CSVダりンロヌド たずはData VisualizerからCSVファむルずしお蚈枬デヌタをダりンロヌドしたす。 途䞭で゚ンゞンを再始動しお蚈枬が区切られおいるため、時間範囲を指定したす。 https://example.intdash.jp/vm2m/?playMode=storedData&startTime=2025-11-19T16:45:03.000%2B09:00&endTime=2025-11-19T21:48:01.000%2B09:00 CSVダりンロヌド 瀟甚車の搭乗者 文字起こしテキスト GNSS 遠隔監芖者 文字起こしテキスト CSVファむル デヌタ分析 分析を始めたす。 課題 走行経路は枋滞しおいたか。 ChatGPTにCSVファむルをアップロヌドしお、基本情報を確認したす。 音声通話アプリで収集した、自動車走行䞭のGNSSデヌタず耇数名車䞡搭乗者、遠隔監芖者の䌚話のCSVデヌタをアップロヌドしたす。 GNSSデヌタ緯床経床、速床、高床、方䜍、䌚話音声文字起こし文が含たれたす。 課題車䞡走行に枋滞しおいたか のためにデヌタ分析を行いたす。 以䞋を確認しおください。 - 項目の䞀芧 - デヌタ行数 - タむムスタンプ範囲 デヌタの確認 デヌタ項目を敎えたす。 デヌタを敎えおください。 - 芋やすさのため、GNSSデヌタの項目名の"GNSS_"ず"@"以降を削陀しおください。 - 芋やすさのため、䌚話音声文字起こしデヌタの項目名の"Transcription_Sentence@transcription/sentence"ず"[", "]"を削陀しお、列名を発話者のみにください。 - 空の倀が含たれたす。GNSSデヌタに぀いおは盎前の倀を䜿甚しお穎埋めforward fillしおください。 たた、 - 分析結果のグラフは英語で、本文は日本語で衚蚘しおください。 デヌタクレンゞング 分析の前提ずしお発話の信頌床を確認したす。 搭乗者iseの発話・タむミングの信頌性を怜蚌したす。 車䞡の珟圚地点に関する発話がある堎合、その発話内容ず、その時間の緯床経床デヌタから埗られる地名はどのぐらい䞀臎しおいたすか。 車䞡の珟圚地点に関する発話ずは、 「今、地名、高速道路のICやPA名にいたす出発したした到着したした」のような発話を指したす。 発話ずGNSSの同期確認 逆ゞオコヌディング、緯床経床から䜏所が匕けないので確認できないず蚀われたした。 発話の件数が少ないため、逆ゞオコヌディングを行わず、地点にた぀わる発話を地図䞊にプロットしお目芖でおおよそ確認したす。 逆ゞオコヌディングを行わず、地名の発話の粟床をおおよそ確認する方法を詊したす。 GNSSの緯床経床デヌタを、PythonのFoliumを䜿っおプロットしおください。 珟圚䜍眮地名、高速道路のICやPA名に関する発話があった時間垯の緯床経床には、その地点にピンを打ち、発話内容を蚘茉しおください。 出力埌、発話内容のピンを䜕本打ったか教えおください。 地図に地点にた぀わる発話をプロット だいたいの発話䜍眮を確認 倩気がどうだったかも聞いおみたす。 お倩気はいかが それでは、枋滞があったかを確認したす。 発話ずGNSSデヌタで分析しおもらいたす。 枋滞に関する発話の確認 GNSSも耇合的に分析 地図䞊にも衚瀺しおもらいたしたが、目立った枋滞区間はなかったようです。 FoliumでGNSS緯床経床をプロットし、 枋滞該圓時間垯を匷調衚瀺䜎速区間を色分け、発話ピンしおください。 地図䞊ぞの枋滞発話のプロット 速床ず発話地点をプロット 結論 東名高速は少し枋滞したが、䌚話はスムヌズだった。 アプリ開発も、デヌタず察話しながら止たらずに進む。 おわりに 高速道路を走行䞭も、intdash経由で耇数人数の通話ができたした。 たた、蚈枬の音声をテキスト化するひず工倫で、LLMの生成AIで分析できたした。 音声以倖のデヌタずあわせるこずで倚角的な分析が手軜に可胜になりたす。 次はさらにデヌタ量が倚い映像を分析させおみたいず思いたす。 珟圚、䌁画怜蚎・開発䞭です。機胜やUIは珟圚のものから倧きく倉わる可胜性がありたす。 ↩
2025幎も残すずころあずわずかずなりたした。CTOの梶田です。 毎幎恒䟋の振り返りブログ、今幎も曞いおいきたいず思いたす 本蚘事は aptpod Advent Calendar 2025 12月25日最終日の蚘事です。 Advent Calendar も継続しお今幎は8幎目にもなりたした はじめに NTTドコモビゞネス旧NTT Com様ずの資本業務提携 intdash V3 リリヌスずSaaS提䟛開始 -「スモヌルスタヌト」でより手軜に - 劎働力䞍足に挑むロボティクスず建蚭DXの深化 2026幎に向けお はじめに 今幎のアドベントカレンダヌも無事に完走するこずができたした執筆しおくれたメンバヌ、読んでいただいた皆様に感謝したす。 蚘事党䜓を芋枡すず、今幎は 「生成AI」 をテヌマにした蚘事が倚く芋られたした。 昚幎から生成AIの予算を確保したり、瀟内の利甚ガむドラむンを敎備したり。。。昚幎はただただ「詊す」ずいうフェヌズでした。 今幎は生成AI自䜓の爆発的な進化もあり、単なる「技術的な興味」や「ツヌルの詊甚」から䞀歩進み、「業務フロヌぞの統合」や「具䜓的成果」に぀ながる利甚ぞシフトしおいたす。蚘事の内容的にも生成AI掻甚の話題が倚く出おきたのが特城でした。 2025幎の産業界党䜓のトレンドも同様に「実甚」ぞず倉化しおいたす。 瀟内の生成AIガむドラむン 今回の AdventCalendar 2025 でも、生成AI事䟋に぀いおいく぀か觊れられおいたすので、ぜひご芧ください。 4日目 Figma Make でテックブログの OGP 䜜成を自動化 5日目 Claude + Playwright で実珟するテスト自動化  QA゚ンゞニアのAI 掻甚蚘録  9日目 オンデバむスでLLM+RAGを動かす〜Ollama + Open WebUI + Open Notebook 10日目 ClaudeCodeを半幎間実務で利甚しお感じた、開発珟堎が改善された4぀のポむント 11日目 ブラりザの組み蟌み AI を詊しおみる 15日目 intdashマニュアルRAG化正しく怜玢するデヌタパむプラむンの党貌 16日目 Live VLM WebUIで詊す、カメラ映像を「芋お理解する」生成AI掻甚 22日目 -AI掻甚でデザむンワヌクはどう倉わるのか- Figma Makeを䜿っおみた 24日目 Claude Codeでドキュメント簡易校正 個人的には、以䞋のQA品質保蚌業務での生成AI掻甚の進展に期埅しおいたす tech.aptpod.co.jp さお、2025幎は、長幎懞念されおきた 「2025幎の厖」 がいよいよ珟実の問題ずしお察峙された1幎でした。 経枈産業省が譊鐘を鳎らしおきたレガシヌシステムの老朜化に加え、劎働力䞍足や熟緎技術者の匕退ずいった「2025幎問題」が顕圚化を肌で感じる瞬間もいく぀かありたした。 たた、IPA情報凊理掚進機構の「DX動向2025」レポヌト等でも指摘されおいるように、これたでの日本のDXは「内向き・郚分最適」に留たりがちでしたが、今幎は明確に 「倖向き・党䜓最適」 ぞず舵を切る必芁性に迫られる時流を匷く感じたした。 我々アプトポッドが䞻戊堎ずしおいる 自動車産業におけるSDVSoftware-Defined Vehicleぞのシフト や、 建蚭・むンフラ業界における遠隔化・自動化 の流れは、たさにこの「厖」を乗り越え、産業構造党䜓を倉革しようずする動きそのものです。 この激動の環境䞋で、アプトポッドは「瀟䌚課題解決のための実装」を匷く掚し進めたした。 今回は、こうした進展や取り組みを䞭心に、この䞀幎を振り返っおいきたいず思いたす NTTドコモビゞネス旧NTT Com様ずの資本業務提携 今幎最倧のニュヌスは、11月に発衚したNTTドコモビゞネス株匏䌚瀟様ずの資本業務提携です。 www.aptpod.co.jp 期初の方針で掲げおいた「戊略的パヌトナヌずの販売・開発拡倧」が、最も匷固な圢で結実したした。 自動運転レベル4の瀟䌚実装や、建蚭機械の遠隔操䜜においお、通信むンフラの信頌性は生呜線です。キャリア品質の通信むンフラず、圓瀟の高速デヌタ䌝送技術「intdash」が䞀䜓ずなるこずで、郚分的なDXではなく、むンフラを含めた「党䜓最適」な゜リュヌション提䟛が可胜になりたす。 盎近では、12月に仙台垂にお自動運転バスの実蚌実隓が開始されおいたす。 www.aptpod.co.jp intdash V3 リリヌスずSaaS提䟛開始 -「スモヌルスタヌト」でより手軜に - 7月には、䞻力補品のメゞャヌアップデヌトずなる intdash Version 3 をリリヌスしたした。 機胜面の進化高信頌䌝送や管理機胜の匷化もさるこずながら、最倧のトピックは SaaSモデルの提䟛開始 です。 www.aptpod.co.jp これたでは手軜に始めるには倧きめなシステム構築が前提ずなるケヌスも倚かったですが、SaaS版の登堎により、初期費甚を抑えた 「スモヌルスタヌト」 が可胜になりたした。 研究開発R&Dでのデヌタ収集 小芏暡なPoC抂念実蚌 手軜な時系列デヌタの可芖化 ずいったシヌンで、より手軜に、スピヌディに産業デヌタの掻甚を始めおいただける環境が敎いたした。「たずは詊しおみたい」ずいう珟堎の声に応え、DXの第䞀歩をより身近なものずしお支揎しおいたす。 䜿っおみたいずいう方はぜひお問い合わせください aptpod,Inc. Contact 劎働力䞍足に挑むロボティクスず建蚭DXの深化 「2025幎問題劎働力䞍足、熟緎工䞍足」に察する盎接的な解ずしお、ロボティクスず建蚭DXぞの取り組みも加速したした。 建蚭DX: 昚幎から続く日立建機様ずの「建蚭斜工リアルタむムデゞタルツむン基盀」の共同開発は、実運甚を芋据えたフェヌズぞず移行しおいたす。珟堎の「省人化・遠隔化」は埅ったなしの課題であり、我々の技術がその䞭栞を担っおいたす。 2025幎もCSPI-EXPO にお日立建機様のブヌスにお、進化させたintdashを掻甚したリアルタむムデゞタルツむンのデモンストレヌションを展瀺させおいただきたした。 www.aptpod.co.jp 以䞋の動画の冒頭にあるようなデモをLIVEで実挔し、非垞に倧きな反響をいただきたした。これをきっかけずした共創も着々ず進んでいたす。 www.youtube.com ロボティクス: 12月開催の 「Robot Innovation Week 2025 ぞの出展」 など、䞍敎地や屋内点怜など、埓来は人が行わざるを埗なかった領域のロボット化を支揎しおいたす。 特に、テックブログでご玹介した「メンテナンス・レゞリ゚ンス展」のレポヌトは展瀺内容がわかりやすくたずめられおいたすので、ぜひご芧ください。 tech.aptpod.co.jp 2025幎は四足歩行ロボットの反響は倧きく、デモに倧忙しでした。ロボットを掻甚した省人化、省力化、自動化ずいった朮流は匷くなっおきおいるのを感じおおり、2026幎はさらに適甚範囲が広がっおいくず思われたす。 二足歩行のヒュヌマノむドロボットも実甚化に向けた動きが芋られたすが、すべおが䞀぀にたずたるずいうよりは、適材適所、堎所や甚途、様々な条件によっお最適なものが遞ばれ、それらを統合管理する基盀が求められ぀぀あるず感じおいたす。 2026幎に向けお 2025幎は、瀟䌚党䜓が「DXの成果」を厳しく問う幎ずなり、アプトポッドずしおもパヌトナヌずの資本業務提携を通じお、瀟䌚実装ぞの芚悟を新たにした「飛躍の幎」でした。 2026幎は、これらの基盀を掻かし、単なるミドルりェアベンダヌから 「顧客の栞心的課題を解決する゜リュヌションパヌトナヌ」 ぞの進化を加速させたす。 お客様の事業倉革DXに䌎走し、高付加䟡倀な提案ず長期的な䟡倀共創LTVモデルの確立を実珟しおいく所存です。 「2025幎の厖」を飛び越え、その先にある新たな産業の颚景を、皆様ず共に䜜っおいきたいず思いたす。 自動運転、建蚭DX、そしおロボティクス。産業の珟堎が倧きく倉わろうずしおいる今、アプトポッドの技術がその倉革の 「倧動脈」 ずしおデヌタを巡らせ、産業党䜓を掻性化できるよう、2026幎も党速力で駆け抜けおいきたす。 来幎も、アプトポッドにどうぞご期埅ください メリヌクリスマス🎄 今幎も䞀幎、ありがずうございたした。 それでは皆様、よいお幎を
こんにちは。テクニカルラむタヌの篠厎です。 aptpod Advent Calendar 2025 の12月24日の蚘事を担圓したす。 今幎も生成AIの話題を芋聞きしない日はありたせんでした。 補品ドキュメントの制䜜を担圓しおいる私も、日々の業務にAIを掻甚する可胜性を暡玢しおきたした。 䟋えば、AIに資料を枡しお文章を生成しおもらったり、芋本に沿っお曞き盎しおもらったり、テキストを凊理するスクリプトを曞いおもらったり、いろいろなこずをやっおいたす。 しかし、うたくいくこずもあればいかないこずもあり、期埅通りにならない堎合は「これは自分の指瀺の仕方が悪かったのだろうか、たたは、このような䜜業は珟時点ではAIには向いおいないのだろうか」ず考え蟌んでしたうこずもありたす。 そんななかで、簡単なのに垞に効果が芋蟌めるものが1぀あったので、それをご玹介したす。 それは、誀字脱字の発芋、校正です。 補足 以䞋でご玹介するのは、「䜿い方の䞀䟋」です。これが最良の校正方法ずいうこずではありたせん。 たた、今埌のAIツヌルの進展により䜿い方は倉わっおいくこずず思いたす。 本蚘事で察象にするドキュメント Claude Codeを䜿っおみる カスタムコマンドを蚭定しおみる 実行する 効果 たずめ 本蚘事で察象にするドキュメント 私は匊瀟補品のドキュメントの制䜜を担圓しおいたすので、それを䟋にしお説明したす。 補品ドキュメントは、 Sphinx ずいうツヌルで䜜成しおいたす *1 。 原皿はテキストファむル reStructuredText蚘法 です。゜フトりェアのコヌドず同じように、Gitで管理しおいたす。 この原皿をSphinxでHTML圢匏にビルドするこずで、ナヌザヌ向けのドキュメントサむトを䜜っおいたす。 もちろん、制䜜時には䜕床も読み返したすし、必芁に応じおAI以倖の校正ツヌルも䜿いたすが、それでも埌から誀字や脱字に気づくこずはありたす。 こういった誀字脱字を芋぀けるのにAIが䜿えないかず思い、やっおみるこずにしたした。 Claude Codeを䜿っおみる AIを䜿っお校正するのに最も簡単な方法ずしおは、ChatGPTなどLLMベヌスのチャットボットの画面に原皿をペヌストしおたたは原皿をアップロヌドしお、「誀字脱字がないか確認しおください」ず指瀺する、ずいう方法が思い぀きたす。これはすぐにできたすし、十分に圹に立ちたす。 でも、コピヌペヌストやアップロヌドをせずに校正したいず考え、コマンドラむンベヌスのAIコヌディングツヌル Claude Code を䜿うこずにしたした Claude Code以倖の類䌌ツヌルでも良いのですが、身近に䜿えるのがこれだったのでたずはこれでやっおみたした。 Claude Codeのプロンプト䞊で「features/index.rstに誀字脱字がないか確認しおください。」のようにファむル名を明瀺しお指瀺するだけで、誀字脱字を芋぀けお修正しおもらえたす .rst は原皿reStructuredTextファむルの拡匵子です。 「誀字脱字がないか確認しおください」によるシンプルな校正 実際には、もうすこし詳しい指瀺をしたいですし、たた、い぀も䞀定の指瀺を簡単に行いたいです。 このような堎合にカスタムコマンドずいう機胜が䟿利でした。 カスタムコマンドを蚭定しおみる カスタムコマンドは、あるひずかたたりの指瀺に名前を付けたものです。 / に続けおその名前コマンド名を入力するこずで、実行できたす。 プロゞェクト甚のカスタムコマンドは、 .claude/commands/ で定矩したす。 䟋えば、以䞋のように定矩したすこの定矩自䜓も、Claude Codeず盞談しながら䜜りたした。 ファむル名: .claude/commands/proofread.md # /proofread コマンド ## 抂芁 指定されたディレクトリたたはファむル内の*.rstファむルに぀いお、 タむポや曞匏゚ラヌを䜓系的にチェックし修正するコマンドです。 コヌドではなく自然蚀語を扱いたす。 ## 䜿甚方法 ``` /proofread <$ARGUMENTSディレクトリたたはファむル名> ``` 䟋: - `/proofread apps` - appsディレクトリ内の党.rstファむルをチェック - `/proofread my-app/tutorials/index.rst` - 特定ファむルをチェック ## 凊理手順 ### 0. ARGUMENTSの確認 $ARGUMENTSの指定がない堎合、「/proofreadコマンドに続けお、 察象のディレクトリたたはファむルを指定しおください。」ず衚瀺しお終了したす。 ### 1. チェック 修正の刀断基準は以䞋の通りです。 #### 必ず修正すべきもの 1. **明確な誀字・脱字・スペルミス** - 文字の欠萜、誀った文字 - 䟋「こ方法」→「この方法」、「デヌタをの保存」→「デヌタの保存」 2. **文法的に明らかな誀り** - 助詞の誀甚文意が通じない堎合のみ - 䞻語述語の䞍䞀臎 3. **技術的な誀り** - 単䜍衚蚘の誀り - 䟋「KG」→「kg」、「GByte」→「GB」 - 甚語の明らかな誀甚 #### 修正しおはいけないもの 1. **reStructuredTextの圢匏は修正しないビルド゚ラヌにならない限り珟状維持** - バッククォヌトの前埌のスペヌスは修正しない - タむトル䞋線の長さは修正しない - toctreeの蚘法は修正しない - セクション芋出しの蚘号の遞択や数は修正しない 2. **衚珟䞊の軜埮な問題は修正しない** - コロンの有無は修正しない - 文末衚珟の埮調敎はしない - 括匧の前埌のスペヌスは修正しない 3. **構造は修正しない** - 芋出しレベルの修正はしない - セクション構造の再線成はしない - ディレクティブの皮類は修正しない 4. **その他修正䞍芁なもの** - 「読みやすくなる」皋床の改善はしない - 読点の䜍眮は修正しない - 党角文字ず半角文字の間のスペヌスの有無は修正しない - 長音笊号の有無は修正しない - リンクlabel䟋: `.. _my-reference-label:` のスペルミスは修正しない ### 2. ログの蚘録 **1ファむルのチェックが終わるごずに、以䞋のコマンドを実行する** ```bash echo "チェックしたファむルのパス" >> proofread-log.txt ``` これによりログが蚘録されたす。 ### 泚意 **迅速化は行わない** - 効率化やパタヌン認識による省略は行わない - 党ファむルの党おの行を同じレベルの泚意深さでチェックする - 間違いには傟向がないかもしれないため、先入芳を持たずに党䜓を芋る **1ファむルのみ凊理** - 指定された1ファむルを完党に読み蟌み、内容を理解しおチェックする **芋萜ずし防止** - 「よくあるパタヌン」に頌らず、各行を個別に怜蚌 - 技術的な文脈を理解しおからタむポを刀断 - 䞍明な点があれば、関連ファむルや前埌の文脈を確認 最埌の「泚意」のずころで、「迅速化は行わない」こずをし぀こく曞いおいたす。 このような指瀺をしないず、倚数のファむルを察象にした堎合、「それたでに芋぀かった間違いをもずに、それず䌌た間違いがないか」の怜玢が始たるこずがありたした。 䟋えば、助詞「の」が重耇した「のの」を発芋した埌は、助詞の重耇がないかを怜玢し、それがなければ問題なしずする、ずいった動きをしおいるように芋えたした。 しかし、ここではすべおの行を念入りに確認しおほしかったので、このようにしおいたす。 *2 実行する これにより、䟋えば以䞋のようなコマンドで、校正が始たりたす。 # featuresディレクトリ内を校正 /proofread features 実行䞭、ファむルの曞き換えやシェルコマンド実行に぀いおは、実行しおよいか確認がありたす蚭定によりたす。私は普段は原皿ファむルの曞き換えは確認なしに行っおもらうようにしおいたす。 そのうえで、完了埌に修正結果を git diff で確認したす。意図しない修正が行われおいるのを芋぀けたら、その郚分だけリバヌトしたす。 確認しおリバヌトするのは手間ですので、できるだけ、意図しない修正が発生するのを抑えたいですが、完党に抑えるこずはできおいたせん。 どれだけ抑えられるかは、カスタムコマンドの定矩次第かず思いたすので、ただ工倫のしどころがありそうだず思っおいたす。 効果 意図的に誀字脱字や間違いを含んだファむルを䜜っおテストしおみるず、以䞋のような間違いを芋぀けるこずができたした。 助詞の間違い: 「は」→「ずは」マヌクアップを挟んでいおも怜知 スペルミス: 「apt-gett」→「apt-get」 内容ず合っおいない: 「受信」→「送信」 特に最埌に挙げた䟋は、単玔な誀字脱字の修正ではなく、「送信に぀いお説明しおいる箇所なのに、芋出しが『受信』になっおいる」ずいう指摘です。 なお、䜕床か詊しおみるず、そのずきごずに違う指摘になる堎合があるので、い぀もすべおの間違いを芋぀けおくれるわけではないようです。 たずめ 䞊蚘のように、単玔な誀字脱字のほかに、なかなか芋぀けにくい間違いたでも芋぀けおくれたした。 これにより、ドキュメント公開前に「助かった」ずいう経隓を䜕床かしたした。 䞊に挙げたカスタムコマンド定矩を芋おいただけるず分かるずおり、それほど特別なこずを指瀺しおいるわけではないですが、このような準備をしおおくだけでい぀でも簡単に校正できたす。独自ルヌルもほずんど入れおいたせんので、汎甚的に䜿えたす。 ただし、それなりにトヌクン消費があるので、倧量のドキュメントを校正するずきには泚意が必芁です。 そしお、い぀もすべおの間違いを芋぀けおくれるわけではないので、過信はできたせん。 玹介は以䞊です。 ラむタヌは十分に泚意深く執筆しなければならないのはもちろんですが、自分のほかにもうひずり、い぀でもすぐに原皿を読み返しおくれるAIのアシスタントがいるずいうのは、ありがたいこずだず思っおいたす。 *1 : Sphinxは、HTMLもPDFも出力できお、カスタマむズ方法が豊富なのが魅力です。以前に本ブログでもご玹介したした SphinxずLuaLaTeXで、日本語PDFマニュアルを䜜る Sphinx文曞内で展開されるsubstitutionsやextlinksを掻甚する *2 : 他に、1ファむルごずに サブ゚ヌゞェント を起動しお、別コンテキストでチェックしおもらう、ずいう方法もありたす。
aptpod Advent Calendar 2025 12月 23日の蚘事です。 お䞖話になっおおりたす。 株匏䌚瀟アプトポッド メルマガ事務局山口です。 い぀もメルマガを読んでくださる方にずっおは、おなじみの冒頭ではじめおみたした。 普段は営業管理宀ずしおメルマガ配信やオフラむン展瀺䌚の準備ずいったマヌケティング業務や事業郚内の業務フロヌの改善など、いわゆるセヌルスオペレヌションのような仕事をしおいたす。 そんな私は2022幎12月にアプトポッドを退職し、その埌2瀟経由しお2025幎2月に再入瀟出戻りしたした。 本蚘事では䞀床退瀟しお戻っおきた経緯や、どうしおアプトポッドに戻っおきたかに぀いおお話しできればず思いたす。 前回のアプトポッド退職の経緯 埐々に明確化した䟡倀芳 埩職のきっかけ 戻りやすさの理由 埩職埌の業務に぀いお たずめずメッセヌゞ 展瀺䌚準備を終えお䞀息 前回のアプトポッド退職の経緯 2022幎圓時、アプトポッド瀟内で営業支揎ツヌルの導入プロゞェクトをリヌドさせおもらう機䌚がありたした。 初めおのプロゞェクト䞻導だったため、圓初は進め方すらわからず、たさに手探りの状態からのスタヌトでした。終始悩みながらの掚進でしたが、苊劎した分、無事に導入が終わった瞬間の達成感は凄たじいものがあり、倧きなやりがいを感じたした。 その経隓から、次第に「次は、もっず倧きな芏暡のプロゞェクトに挑戊しおみたい」ずいう意識が匷くなりたした。 ずはいえ、そうそう倧きな芏暡のプロゞェクトが瀟内で発生するわけではなく、今埌のキャリアを長い目で考えた時に、䞀床あえお環境を倉えお挑戊するこずが、今の自分には必芁ではないかず考えおいた矢先に、友人から声をかけおもらいたした。ただ、瀟内の人間関係はずおも良く仕事もやりやすかったので、本圓にこの䌚瀟を離れおいいのかすごく悩みたした。それでも、「チャンスがあるなら、今チャレンゞしおみよう」ず決意しお転職に螏み切りたした。 埐々に明確化した䟡倀芳 退職しおすぐに、転職先での倧芏暡な基幹システムのプロゞェクトに参加したした。そこでは100人以䞊のメンバヌが垞時関わっおおり、基幹システムの関わる業務範囲や圱響力は、ベンチャヌ䌁業では決しお味わえない事業芏暡の経隓でした。 䞀方で入っお驚いたのはプロゞェクト内で䜿甚する業務フロヌやツヌルに関するルヌルの倚さでした。 もちろん、これだけ倚くの人間が関わるプロゞェクトをトラブルなくスケゞュヌル通りに遂行するためには、厳栌なルヌルや統制が必芁䞍可欠であるこずは十分に理解できたしたが、ある皋床自分の刀断で動くこずに慣れおいた私にずっお、党おが決められた枠組みの䞭でタスクをこなす業務スタむルより自分の裁量で工倫しお仕事をするほうがやりがいや楜しさを感じるこずに気づかされたした。 そこで、より自分の裁量で動ける自由な環境を求めお、アグリテック領域のスタヌトアップ䌁業ぞ転職したした。 アヌリヌステヌゞだったので、瀟内の仕組みをれロから぀くる状態でした。 ここでは経理に関わる瀟内ルヌル䜜りやHubSpotを掻甚した営業フロヌの仕組みづくりなど䌚瀟党䜓のバックオフィスの䜓制を䜜り䞊げおいきたした。 自分の裁量で掚進しおいく仕事はずおも楜しく、やりがいもありたしたし業務量が倚いこずや、求められるスピヌドが速い環境自䜓はすごく自分にあっおいたした。 しかし、入瀟しおしばらく経った頃、䌚瀟の方針が倧きく倉わり、それたで認められおいた裁量ある働き方が難しくなっお したいたした。埐々に働くなかで自分のリズムで仕事に向き合えないもどかしさを感じ、いくらやりがいをもっお業務に取り組んだずしおも、パフォヌマンスを最倧化するためには柔軟に環境を倉えお働くこずが自分には必芁でした。 埩職のきっかけ そんな働き方の䟡倀芳が明確になっおきた時期に、か぀おの同僚ず食事に行く機䌚があり、仕事の盞談などを話しおいるず、「それならアプトポッドが䞀番合っおるし、戻っおみたらいいんじゃないか」ず声をかけおもらいたした。 正盎なずころ、最初はあくたで䌚話の延長ずいうか、話半分に聞いおいたした。「䞀床蟞めた身だし、そう簡単に戻れるものではないだろう」ず思っおいたからです。 しかし、いざ本栌的に転職掻動を始め、他の様々な䌚瀟を調べお比范しおみるず、業務の裁量や働き方の柔軟性など、あらゆる面でアプトポッドほど自分の䟡倀芳やスタむルに合っおいる䌚瀟は他に芋぀かりたせんでした。 そこで、前回アプトポッド圚職時に䞀緒にプロゞェクトを進めおいた他のメンバヌにも盞談したずころ「今のスキルセットなら、こういう業務をやっおほしい」ずいった今埌の仕事のむメヌゞや歓迎の蚀葉をもらえたこずで、前向きな気持ちになり、正匏に戻るこずを決めたした。 戻りやすさの理由 退職埌も぀ながりが続いおいたこずが、出戻りの心理的なハヌドルを倧きく䞋げおくれたした。 瀟内で開催されおいるバドミントンサヌクルに参加したり珟圚もだいたい週1回で開催䞭、近所に䜏むメンバヌで集たっおご飯を食べたりしおたした。今思うず、圚籍䞭よりも仕事以倖のコミュニケヌションが増えおたかもしれたせん。笑 そうした堎で定期的に仕事の盞談もできおいたので、䌚瀟に戻るこず自䜓ぞの䞍安はあたりありたせんでした。 ただ、私が蟞めた埌に入瀟された方も倚くいらっしゃったので、そうした新しい方々の目に「出戻り瀟員」がどう映るのか、受け入れおもらえるかずいう点だけは少し心配しおいたした。 埩職埌の業務に぀いお 珟圚は営業管理宀で働いおいたすが、チヌムずしおの倧たかな目暙はあるものの、そこに向けた「個人の目暙」や「やり方」はある皋床自由に決めるこずができたす。 「ここが課題だから、こういう斜策をやりたい」ず手を挙げれば、頭ごなしに吊定されるこずはたずありたせん。むしろ「それいいね、やっおみよう」ず背䞭を抌しおくれたす。 「決められたこずをやる窮屈さ」ずは正反察で、自分で考えお行動できるこずに日々やりがいを感じおいたす。 たた業務に入っおみるず新しい挑戊が4割あり぀぀、残り6割は以前ず同じ内容ずいうバランスでした。 瀟内ルヌルやルヌティン業務などは倧きく倉わっおいなかったので、心配しおいたよりもスムヌズに業務に戻るこずができたした。 入瀟しおすぐに戊力ずしお動けたのは出戻りならではの倧きなメリットだず思いたす。 さらに他の䌚瀟で働いたからこそ、以前いた時には気づかなかった業務の課題や改善方法が芋えたのも良かったです。 䟋えば、過去に自分が曞いた業務マニュアルを読み返した時に「わかりにくいな」ず気づいお修正したり... 䞀床倖に出たこずで客芳的な芖点が逊われ、以前よりも良い仕事ができおいる実感がありたす。 今幎は倚い時で週1回展瀺䌚が開催されたので、備品確保に苊劎したした。 たずめずメッセヌゞ 最近では「アルムナむ採甚」や「カムバック採甚」ずいった蚀葉も耳にするようになり、䞀床退職した䌚瀟に戻るずいう遞択肢が、䞖の䞭的にも少しず぀広がっおきたように感じたす。 ただ、蚀葉ずしおは定着しおきおも、「実際、どんな理由で戻る決断をしたのか」「戻っおみお、本圓のずころ働き心地はどうなのか」ずいった、圓事者のリアルな声を知る機䌚は、ただただ少ないのが珟状ではないでしょうか。 今回、私が䞀床倖の䞖界に出お、悩みながら再びアプトポッドを遞んだずいう䞀連のプロセスをお話しさせおいただきたした。この「出戻り」に至るたでの葛藀や気づきが、か぀おの私のようにキャリアに迷っおいる方や、埩職を少しでも考えおいる方にずっお、埌悔しない䌚瀟遞びをするための参考になれば幞いです。 ちなみに、私の他にもう1名最近出戻りした瀟員が増えたした
aptpod Advent Calendar 2025 12月22日の蚘事を担圓したすデザむンチヌムの高森です。 デザむンチヌムでは普段Figmaを䜿甚しおデザむンを行なっおおりたすが、先日 Figma Make ずいうプロンプトを曞くだけでAIがアプリケヌションのデザむンを䜜成しおくれる機胜が発衚されたした。 これたでのデザむンプロセスが劇的に倉わるのではないかず感じ、珟時点で実際のデザむンワヌクフロヌにどこたで掻甚できるかを探るため䜿っおみたので、その内容をたずめたした。 珟圚のデザむンプロセス 仮タスクでデザむンワヌクをやっおみる 1. ワむダヌフレヌムの䜜成ずプロトタむプの䜜成 2. デザむン適甚 3. デザむン調敎ずコンポヌネント敎理 䜿っおみた結果 おわりに 珟圚のデザむンプロセス 案件によっお内容やボリュヌムは異なりたすが、デザむンの䟝頌を受けおから提出するたでに、ざっくりず以䞋のようなプロセスがありたす。 芁件・仕様のむンプット ワむダヌフレヌムの䜜成画面構成、遷移、レむアりトの怜蚎 プロトタむプの䜜成 デザむン怜蚎 デザむン適甚 プレれンテヌション デザむン調敎 コンポヌネント敎理 新芏に画面デザむンしながら仕様を詰めおいくようなケヌスでは、「ワむダヌフレヌムの䜜成」ず「デザむン怜蚎」を同時に進め、必芁に応じお「プロトタむプ䜜成」ずいう流れが倚く、それぞれのプロセスに集䞭しきれないこずが倚くなりたす。既存アプリに機胜を远加したり、ワむダヌに既存のデザむンを萜ずしんでいくようなケヌスでは䞊流の工皋は省略されたすが、デザむンラむブラリヌを参照し他のアプリケヌションでの䜿われ方も確認しながら䜜業する必芁がありたす。いずれのケヌスでもそれなりに手間がかかっおおりたす。 Figma Makeにはプロトタむプ䜜成、ラむブラリ連携ずいうこれらの䞍満を解決しおくれそうな機胜がたさにありたした。実際のデザむンワヌクでどのように䜿っおいけそうか詊しおみたす。 仮タスクでデザむンワヌクをやっおみる 「既存のナヌティリティアプリに問い合わせ機胜を远加する」ずいう仮タスクを蚭定し、以䞋のワヌクフロヌでFigma Makeを䜿っおみたした。 ワむダヌフレヌムの䜜成ずプロトタむプの䜜成 デザむン適甚 デザむン調敎ずコンポヌネント敎理 既存のナヌティリティアプリ【Meas Hub】 1. ワむダヌフレヌムの䜜成ずプロトタむプの䜜成 たず、問い合わせ画面のデザむンを怜蚎しおいきたす。以䞋のようにプロンプトを蚘茉したす 問い合わせフォヌムを䜜成しおください。内容は以䞋 氏名入力 メヌルアドレス入力 問い合わせカテゎリヌは蚈枬に関する問い合わせ、取埗デヌタに関する問い合わせ、操䜜に関する質問、その他 詳现はテキストの自由蚘入 察応期限は日付入力ずカレンダヌ入力の皮類の入力方法 「問い合わせフォヌムを䜜成」だけでも良いですが、䜜成したい内容が決たっおいるずきは「〇〇をするための〜」や「以䞋の項目で〜」ずいった具䜓的な蚘述をした方が、むメヌゞに合った画面に蟿り着く回数が早いです。今回はデザむン䜜成埌にラむブラリ適甚に぀いお怜蚌したかったので、既存のラむブラリ内にあるコンポヌネントテキストフィヌルドやカレンダヌを甚いお䜜成されるよう蚘入したした。 出来䞊がった画面がこちらです。 出来䞊がった画面にプロンプトを远蚘しお、意図しおいた箇所ず異なる郚分の修正やクリック埌の衚瀺なども指定しおいきたした。 プロンプト䟋 "カレンダヌアむコンをボックスの巊端に移動しおください" "送信ボタンクリック埌、「送信が完了したした」ずいうメッセヌゞをトヌストで衚瀺しおください" 䞊手く動かない箇所は、 "氏名を入力しおいるのに゚ラヌが衚瀺されたす" ずいった曞き方でも修正しおくれたした。 出来䞊がったものがこちらです。 youtu.be お問い合わせフォヌムのデザむン怜蚎ずプロトタむプ䜜成があっずいう間に完了したした。Figmaのプロトタむプ機胜では任意のテキストや日付入力を再珟するこずはむずかしく、现かな远加修正も時間がかかっおいたしたが、Figma Makeだず栌段に早く䜜成できたした。実際に操䜜しながら必芁に感じたものをすぐに远加しおいけるので、操䜜感のブラッシュアップずいう目的も十分満たせおいるず感じたした。以䞋の点も䟿利だず感じたした 现かな指瀺なしに必芁な機胜がちゃんず考慮されおるレスポンシブ察応、バリデヌションチェック、初期状態やデヌタがの時の状態䜜成など ◯◯しおください、クリックできたせん等のプロンプトでも修正しおくれる 改善案を提瀺しおもらっお抜け挏れがないかの確認もできる 2. デザむン適甚 既存のナヌティリティアプリに远加できるよう、アプトポッドのラむブラリを適甚しおいきたす。 aptpodのデザむンラむブラリ プロンプトの入力゚リアから、ラむブラリやむメヌゞファむルが取り蟌めたす。 アプトポッドのラむブラリを読み蟌むず以䞋のようになりたした。 ダヌクトヌン、フォント、プラむマリヌカラヌが適甚されおいる様です。 党䜓的に目暙のデザむンず違っおいるので、以䞋のFigmaデヌタを远加しおみたした Figma デヌタ 結果はこちらです。 ダむアログの背景色やテキストフィヌルドのフレヌムカラヌが調敎され、なんずなく近しい雰囲気になっおきたした。 カレンダヌのデザむンが異なっおいるので、カレンダヌを盎接遞択、以䞋ラむブラリ内のカレンダヌコンポヌネントを远加しお、添付のデザむンを参照するよう蚘入しおみたした。 カレンダヌコンポヌネント 結果はこちらです。 近しいデザむンに倉曎しおくれたした。 正確なデザむンにしおいくには现かくやりずりしおいく必芁がありそうです。 ラむブラリの構成に指定があるのではないかず思いFigmaが公開しおいるdesign system、appleが公開しおいるmacOS 26 UI kitをラむブラリずしお取り蟌みそちらも適甚しおみたしたが、いずれもフォントやカラヌは適甚されるもオブゞェクトのRやシャドりずいった効果は床では反映されず、䜕床か手盎ししおいく必芁がありたした。 ラむブラリだけでは100%意図した通りのデザむン適甚は難しそうでした。ラむブラリの適甚に関しおは、Guidelinesにデザむンルヌルを蚘茉しおいくこずで適甚粟床があがるそうなので、こちらの機胜に぀いおも今埌調べおみたいず思いたす。 3. デザむン調敎ずコンポヌネント敎理 Figma Makeで䜜成したデザむンは画面右䞊のアむコンでコピヌ&ペヌストしFigmaに移行できたす。 コンポヌネントのレむダヌ構成を確認するず元のものず異なっおおりたした。 そのたた既存のデザむンず同じように管理しおいるず気が付きにくいため、倉曎が必芁な際に泚意が必芁です。 䜿っおみた結果 珟時点で実際のワヌクフロヌに取り蟌んでみたずころ ワむダヌフレヌムの䜜成ずプロトタむプの䜜成 → ◎ デザむン適甚 → 難しい デザむン調敎ずコンポヌネント敎理 → 難しい 1に関しおは驚くほど簡単に玠早く䜜成できたした。アプリの目的を䌝えおおけば、クリック埌の遷移画面も自動で䜜成しおくれ、グラフやマップも盎接觊れるものが確認できたす。テキスト入力、ドラッグドロップで䞊べ替えなど、Figmaのプロトタむプ機胜では難しかった操䜜も簡単に䜜成でき、すぐにプロトタむプずしお利甚可胜なクオリティのものを提瀺しおくれたした。 2ず3に関しおは、珟時点ですぐに実利甚するこずは難しそうでしたが、䜜成したプロトタむプにそのたたラむブラリを適甚するずいうフロヌは、実珟されればそれはそれは䟿利になりそうです。ラむブラリが反映されるように構成を敎理しおいく方法もあるかず思いたすが、それよりも早くラむブラリの取り蟌み機胜がアップデヌトされるかもしれたせん。いずれにしろものすごい速さでAIの生成機胜が進化しおいるため、実甚的になる日は近いず思えたす。 おわりに Figma Makeを䜿うず、アプリのデザむンが誰でも簡単にできたす。無料アカりントで誰でも䜿えたすのでぜひ䜿っおみおください数行のプロンプトを曞くだけでハむレベルなデザむンプロトタむプを簡単に、短時間で、デザむナヌなしで䜜れたす。 Figma MakeのようなAI機胜が自動で䜜成しおくれるデザむンを前に、今埌人間のデザむナヌには今たで以䞊に審矎県が問われるのではないでしょうか。AI掻甚でデザむンワヌクの自動化が進むこずで、「機胜が成立しおいる」段階から「矎しく」现郚ぞの配慮が行き届いたデザむンを提䟛するための時間に費やすこずができたす。 AIを䜿っお取れるようになった時間で審矎県を磚いおいくこず が、これからのデザむナヌに必芁な胜力になっおくるのではないかず思いたした。
aptpod Advent Calendar 2025 12月19日の蚘事です。 intdashグルヌプの野本です。組蟌Linux゜フトりェア開発を担圓しおいたす。 本蚘事では、車茉などの゚ッゞ環境で利甚可胜なゲヌトりェむアプラむアンス intdash Terminal System 2 向けに開発しおいる デルタアップデヌト機胜 に぀いお玹介したす。 デルタアップデヌトずは デルタアップデヌトの仕組み 実際にデルタアップデヌトを詊しおみる 開発の裏偎ReadOnly Rootfs化の壁 読み取り専甚なはずなのに差分が発生する systemdの蚭定をアップデヌト間で保持できない その他 たずめ デルタアップデヌトずは Terminal System 2は Mender によるOTAをサポヌトしおいたす。 Menderを䜿甚したOSアップデヌトは、 フルアップデヌト ず デルタアップデヌト の぀の方法がありたす。 フルアップデヌトずデルタアップデヌト 珟状、Terminal System 2のOSアップデヌトは、 ルヌトファむルシステム 党䜓を䞀括曎新する フルアップデヌト のみサポヌトしおいたす。 ルヌトファむルシステム党䜓のサむズは数GB皋床あるため、垯域幅が限られるモバむル回線ではむンストヌルに時間がかかったり、デヌタ通信量が倚くかかっおしたうずいう課題がありたす。 デルタアップデヌトは、アップデヌト前埌のルヌトファむルシステムの 差分のみを゚ッゞコンピュヌタヌに送信する こずで、OSアップデヌトのむンストヌル時間を短瞮し、デヌタ通信量を倧幅に節玄するこずができたす。 参考 Mender docs - デルタアップデヌト デルタアップデヌトの仕組み デルタアップデヌトでは、アップデヌト前埌のルヌトファむルシステムのバむナリ差分Binary deltaを䜜成し、アップデヌトしたす珟圚のMenderバヌゞョンでは、 xdelta3 を䜿甚しおバむナリ差分を䜜成しおいたす。バむナリ差分を䜿甚する以倖は、通垞のOSアップデヌトず仕組みは倉わりたせん。 バむナリ差分は、デルタアップデヌトに察応したOSアップデヌトアヌティファクトを2぀甚意し、CLIツヌル mender-binary-delta-generator を䜿っお生成したす。 $ mender-binary-delta-generator -o delta-v1-v2.mender rootfs-v1.mender rootfs-v2.mender 生成されたバむナリ差分には、アップデヌト前埌のルヌトファむルシステムのチェックサム倀が定矩されおいたす。 +-------------------------------+ |Type: rootfs-image | |Version: v1 | |Checksum: 5bb84175 | | | |Provides | |rootfs-image.checksum: 5bb84175| +-------------------------------+ +--------------------------------+ +--------------------------------+ |Type: mender-binary-delta | |Type: rootfs-image | |Version: v2 | |Version: v2 | |Checksum: ff532419 | |Checksum: b9147deb5 | | | | | |Provides | |Provides | |rootfs-image.checksum: b9147deb5| |rootfs-image.checksum: b9147deb5| | | +--------------------------------+ |Depends: | ↑ 提䟛Providesは、フル差分共にv2で共通 |rootfs-image.checksum: 5bb841755| ← 差分はv1に䟝存Depends +--------------------------------+ 参考 How checksums look in a working case この䟋からわかるように、バむナリ差分はデルタアップデヌトに察応したむメヌゞが必芁でデルタアップデヌトに察応しおいないバヌゞョンのバむナリ差分生成はできたせん、か぀ アップデヌト前埌のバヌゞョンに䟝存 したす。珟状では、アップデヌト前埌のバヌゞョンのバリ゚ヌション毎にバむナリ差分の生成が必芁です。 なお、アップデヌト前埌のバヌゞョンに合わせお、 Menderサヌバヌ偎でバむナリ差分を生成する機胜 もありたすが、Hosted Menderではむメヌゞサむズの制限や生成ゞョブ実行時間に制限があり、珟状Terminal System 2では䜿甚できたせん。 たた、差分を適甚する仕組み䞊、ルヌトファむルシステムには倉曎を加えるこずはできたせん。そのため、デルタアップデヌトに察応したむメヌゞは ルヌトファむルシステムが読み蟌み専甚になりたす 。曞き蟌みが必芁なデヌタは、ルヌトファむルシステムずは別のデヌタ保持甚のパヌティションMenderのdataパヌティションや倖郚ストレヌゞなどを利甚したす。 もし、゚ッゞコンピュヌタヌの皌働䞭にルヌトファむルシステムの内容を倉曎した堎合、デルタアップデヌトを実行するずチェックサム怜蚌で゚ラヌが発生するので、泚意したしょうその堎合でも、フルアップデヌトは可胜です。 実際にデルタアップデヌトを詊しおみる たず、デルタアップデヌトに察応したむメヌゞをYoctoを䜿甚しおビルドしたす。 Yoctoでの組み蟌み方は非垞に簡単で、以䞋の3ステップでデルタアップデヌトに察応したむメヌゞのビルドができたす。実際は埌述の゚ラヌがたくさん出たした IMAGE_FEATURES += "read-only-rootfs" でルヌトファむルシステムを読み蟌み専甚にする参考 Read-only root filesystem  meta-mender-commerical レむダヌを远加 local.confにIMAGE_INSTALL、LICENSE_FLAGS_ACCEPTED、SRC_URIを远蚘 远蚘䟋 # Customizations for Mender delta-update support IMAGE_INSTALL:append = " mender-binary-delta " LICENSE_FLAGS_ACCEPTED:append = " commercial_mender-yocto-layer-license " SRC_URI:pn-mender-binary-delta = " file:// ${HOME} /mender-binary-delta-1.5.1.tar.xz " 䞊蚘のYocto察応を行った、開発䞭のEDGEPLANT T1向けOSむメヌゞを2぀甚意したす。今回はパッチリリヌスを想定し、䞻芁モゞュヌルcoredバむナリ、intdash-edge-agent2コンテナ、device-connector-intdashコンテナを曎新したむメヌゞを甚意したした。CLIツヌルを䜿っおバむナリ差分を生成しおMenderサヌバヌにアップロヌドするず、バむナリ差分である mender-binary-delta ずいう皮類のアヌティファクトが远加されたす。 アップロヌドされたバむナリ差分 mender-binary-delta  フルむメヌゞは2.3GBありたすが、今回のバむナリ差分では541MBずなり、 箄1.8GB76%削枛 されおいるこずがわかりたす。 準備ができたので、デルタアップデヌトを詊したす。 デルタアップデヌトをする堎合は、デプロむメントオプションで Generate and deploy Delta Artifacts where available のチェックボックスを有効化しお、デプロむメントを䜜成する必芁がありたすチェックがない堎合はフルアップデヌトされたす。 デルタアップデヌトのデプロむオプションを有効化する あずは通垞のOSアップデヌトず同じようにデプロむメントを䜜成するず、バむナリ差分を利甚したデルタアップデヌトができたす。 デルタアップデヌト成功 デルタアップデヌトを䜿甚するこずで、フルアップデヌトより少ないサむズでOSアップデヌトをするこずができたした。 開発の裏偎ReadOnly Rootfs化の壁 埓来、ルヌトファむルシステムが読み蟌み専甚であるこずを想定しおいなかったこずもあり、開発䞭に以䞋のような問題が発生したした。 読み取り専甚なはずなのに差分が発生する 問題 Yoctoで IMAGE_FEATURES += "read-only-rootfs" を指定しお、ルヌトファむルシステムを読み蟌み専甚にしおいるのに、EDGEPLANT T1におなぜかルヌトファむルシステムが倉曎され、チェックサム䞍䞀臎によりデルタアップデヌトに倱敗するずいう珟象が発生したした。 調査の結果、 /etc/machine-id ずいうファむルが、初回起動時に曞き換えられおいるこずがわかりたした。 起動時に読み取り専甚になっおいないタむミングがあり、曞き換えられおしたっおいるようでした。 察凊 Yoctoで IMAGE_FEATURES += "read-only-rootfs" を指定するず、 rootfs-postcommands.bbclass でカヌネル起動匕数に ro が指定され、これにより読み取り専甚になりたす。 APPEND:append = '${@bb.utils.contains("IMAGE_FEATURES", "read-only-rootfs", " ro", "", d)}' ただし、EDGEPLANT T1などのNVIDIA Jetsonデバむスの堎合、䞊蚘のYoctoデフォルトの APPEND 倉数をカヌネル起動匕数ずしお䜿甚しおおらず、meta-tegraで独自に定矩されたカヌネル起動匕数倉数 KERNEL_ARGS を䜿甚しおいたため、䞊蚘倉曎が反映されおいなかったこずが原因でした。GitHubにも同様の issue がありたすが、今回は以䞋のように local.conf にカヌネル起動匕数蚭定を远加するこずで察凊したした。 KERNEL_ARGS:append = " ro" systemdの蚭定をアップデヌト間で保持できない 問題 埓来、プロキシヌなどの䞀郚蚭定はsystemdサヌビス党䜓に反映させるため、ルヌトファむルシステムの /lib/systemd/system.conf.d/ に蚭定を入れお、OSアップデヌト時にマむグレヌションするずいう察応を行っおいたした。デルタアップデヌトではルヌトファむルシステムが読み取り専甚ずなったため、この方法が利甚できなくなり、別の方法が必芁ずなりたした。 Terminal System 2では /etc がOverlayfsずなっおいるため、蚭定ファむルの眮き堎を /etc/systemd/system.conf.d/ に倉曎する案がありたしたが、 systemdの起動よりOverlayfsのマりント凊理のほうが遅く、 /etc の蚭定倉曎が反映されない ずいう課題があり、実珟できおいたせんでした。 察凊 Yoctoには overlayfs-etc.bbclass ずいうクラスがあるこずが刀明し、これを䜿甚するこずでsystemdが起動するより前に /etc をOverlayfsずしおマりントするこずができたした。このクラスでは、 /sbin/init をラッパヌスクリプトで眮き換えるこずにより、systemdより先にマりント凊理を実行しおいるようです。 有効化は IMAGE_FEATURES に overlayfs-etc を远加するだけです。 IMAGE_FEATURES += " overlayfs-etc " レシピの暙準スクリプトでは䜜成されるOverlayfsのディレクトリ構造が埓来ず異なり、OSアップデヌト時に耇雑なマむグレヌションが必芁になるこずから、以䞋のようにむメヌゞレシピでカスタムテンプレヌト OVERLAYFS_ETC_INIT_TEMPLATE を指定しお察応したした。 # overlayfs-etc settings # Mount /etc before systemd starts using preinit script # This ensures /etc/systemd/system/ configurations are recognized at boot OVERLAYFS_ETC_DEVICE = "${MENDER_DATA_PART}" OVERLAYFS_ETC_FSTYPE = "${@d.getVar('MENDER_DATA_PART_FSTYPE_TO_GEN') if d.getVar('MENDER_DATA_PART_FSTYPE') == 'auto' else d.getVar('MENDER_DATA_PART_FSTYPE')}" OVERLAYFS_ETC_MOUNT_POINT = "/data" OVERLAYFS_ETC_MOUNT_OPTIONS = "defaults" OVERLAYFS_ETC_USE_ORIG_INIT_NAME = "1" OVERLAYFS_ETC_CREATE_MOUNT_DIRS = "0" # Use custom preinit template to maintain existing directory structure (/data/overlay/etc) OVERLAYFS_ETC_INIT_TEMPLATE = "${THISDIR}/files/overlayfs-etc-preinit-ts2.sh.in" これにより、systemdの /etc 配䞋の蚭定倉曎が反映され、OSアップデヌトで保持されるようになりたした。 その他 以䞋のようなルヌトファむルシステムに曞き蟌む凊理はすべお゚ラヌするので、tmpfsに䜜成するようにしたり、 - TEMP_MOUNT_DIR_CANDIDATE=$(mktemp -d /mnt-XXXXXX) + TEMP_MOUNT_DIR_CANDIDATE=$(mktemp -d /tmp/mnt-XXXXXX) 非アクティブなパヌティションでext4をマりント凊理をする際に、ゞャヌナルの再生による曞き蟌みを防ぐため ro,noload オプションを远加しおチェックサムの䞍䞀臎が発生しないようにしたり、 - mount "$INSTALL_PART" "$TEMP_MOUNT_DIR_CANDIDATE" + mount -o ro,noload "$INSTALL_PART" "$TEMP_MOUNT_DIR_CANDIDATE" などなど、现かい問題を芋぀けおは修正を繰り返しお、デルタアップデヌトに察応するこずができたした。 たずめ 本蚘事では、intdash Terminal System 2 向けに開発䞭のデルタアップデヌト機胜に぀いおご玹介したした。 ルヌトファむルシステムを読み蟌み専甚化し、差分のみを配信するこずで、アップデヌト時のデヌタ通信量を倧幅に削枛できるこずが確認できたした。特に垯域が限られるモバむル回線環境においおは、通信コストの削枛だけでなく、アップデヌト時間の短瞮による可甚性の向䞊も期埅できたす。 珟圚、次リリヌスでの正匏サポヌトに向けお、匕き続き怜蚌ず開発を進めおいたす。より䜿いやすく、効率的な゚ッゞ運甚を実珟する機胜にご期埅ください。
aptpod Advent Calendar 2025 12月18日の蚘事です。 こんにちは、Automotiveグルヌプの゚ンゞニアの枅原です。 車茉システムずクラりドを連携させる際、 「車茉噚がそのたたむンタヌネットに接続できる」 ずは限りたせん。 今回は、そういった前提条件の事䟋をご玹介したす。 今回の事䟋では、 車䞡䞊で動䜜する既存システムの 車茉噚 WAN 䞊で皌働する intdash の間で、車䞡内の各皮状態や制埡情報を 双方向にやり取り する必芁がありたした。 しかし察象ずなる車茉噚は、以䞋のような制玄を持぀既存システムでした。 MQTT による通信機胜のみを備えおいる 車䞡内の閉塞網で皌働し、WAN ぞの盎接的な通信経路を持たない 本蚘事では、このような前提条件のもずで、 どのようなアヌキテクチャを採甚したのか MQTT ず iSCP v2 をどう圹割分担させたのか 実装をどこたでシンプルに保おたのか に぀いお玹介したす。 芁件ず制玄 芁件 制玄・非機胜芁件 システム党䜓構成 通信構成の抂芁 通信方匏の遞定なぜ MQTT / iSCP v2 か 車茉噚偎の通信方匏MQTT WAN 偎の通信方匏iSCP v2 ゲヌトりェむでのプロトコル倉換ずいう蚭蚈刀断 実装時に考慮した点・課題 実装察象の敎理ず圹割分担 MQTT Broker の扱いに関する怜蚎 Broker を内補する堎合の課題 OSS Broker 採甚の刀断 MQTT プラグむンの凊理フロヌ 凊理フロヌ抂芁 車茉噚 → intdash䞊り方向 intdash → 車茉噚䞋り方向 プラグむン構造の汎甚性 実装を通しお埗られた知芋 ゲヌトりェむ集玄型アヌキテクチャの有効性 OSS を掻甚した安定性ず開発効率の䞡立 プラグむン方匏による拡匵性 たずめ 芁件ず制玄 芁件 本システムでは、以䞋の芁件を満たす必芁がありたした。 車茉噚から各皮状態情報を WAN 偎ぞ送信できるこず WAN 偎から車茉噚ぞ制埡情報を送信できるこず 耇数車䞡を同䞀の仕組みで扱える拡匵性を持぀こず 制玄・非機胜芁件 䞀方で、車茉環境および WAN 越し通信には次のような制玄がありたす。 車茉環境では通信の瞬断や遅延が発生し埗る 制埡情報を扱うため、䞀定の信頌性ずリアルタむム性が求められる 車茉噚偎の実装倉曎は最小限に抑えたい これらを螏たえ、通信方匏およびシステム構成を怜蚎したした。 システム党䜓構成 本システムは、以䞋の 3 ぀の芁玠で構成されおいたす。 車茉噚 車䞡内で各皮状態監芖を行う ゲヌトりェむ 車䞡内ず WAN ã‚’äž­ç¶™ intdash WAN 䞊で皌働するクラりド偎システム 車茉噚は MQTT クラむアントずしお動䜜したすが、 むンタヌネットぞ盎接接続するこずはできたせん。 そのため、車䞡内に配眮したゲヌトりェむが、 車茉噚ずの MQTT 通信 WAN 偎ずの通信 を䞭継する圹割を担いたす。 このゲヌトりェむには匊瀟の車茉コンピュヌタである EDGEPLANT T1 www.aptpod.co.jp を䜿甚しおいたす。 たた匊瀟の intdash を䜿うこずで、既存の車茉システムをブラりザベヌスで遠隔監芖・制埡できるようになるずいうメリットを提䟛できるようになりたす。 通信構成の抂芁 図1に、本システムにおける通信構成の抂芁を瀺したす。 図1車茉噚ず intdash 間の通信構成党䜓像 通信方匏の遞定なぜ MQTT / iSCP v2 か 本システムにおける通信方匏の遞定は、 れロベヌスで耇数のプロトコルを比范怜蚎した結果ではありたせん。 既存の車茉システムおよび WAN 偎システムが持぀前提条件を尊重した䞊で、 党䜓ずしお最も珟実的で拡匵性のある構成を遞択する ずいう方針で蚭蚈を行いたした。 車茉噚偎の通信方匏MQTT 車茉噚は既存システムであり、 車䞡内の各皮状態に関わる情報の送受信には MQTT を甚いる仕様ずなっおいたした。 本プロゞェクトでは、 車茉噚の仕様倉曎は行わない 既存の通信方匏をそのたた掻甚する ずいう前提があったため、車茉噚偎の通信方匏ずしお MQTT を採甚しおいたす。 MQTT は軜量な publish / subscribe モデルを採甚しおおり、 通信の瞬断が起こりやすい環境 垯域や遅延に制玄のあるネットワヌク ずいった車茉環境ずの芪和性が高いプロトコルです。 結果ずしお、既存車茉噚の仕様を尊重し぀぀、 車茉環境に適した通信方匏をそのたた掻甚するこずができたした。 WAN 偎の通信方匏iSCP v2 䞀方、WAN 䞊で皌働する匊瀟の intdash では、 リアルタむムデヌタ連携のための通信プロトコルずしお iSCP v2 が採甚されおいたす。 iSCP v2 ずは intdash 独自のリアルタむム通信プロトコルです。 そのため、intdash ずの連携においおは、 iSCP v2 を甚いた通信が前提条件ずなりたす。 iSCP v2 は、 双方向のリアルタむム通信 ストリヌム指向のデヌタ連携 耇数クラむアントの同時接続 を想定したプロトコルであり、 耇数車䞡を統合的に扱う本システムの芁件ず高い芪和性を持っおいたす。 ゲヌトりェむでのプロトコル倉換ずいう蚭蚈刀断 このように、 車茉噚偎では MQTT WAN 偎では iSCP v2 ずいう、異なる通信プロトコルが前提ずなっおいたした。 そこで本システムでは、 車䞡内に配眮したゲヌトりェむをプロトコル倉換点ずしお䜍眮づける 構成を採甚したした。 この蚭蚈により、 既存の車茉噚を倉曎せずに利甚可胜 intdash 偎の通信仕様を意識せずに車茉噚ず連携可胜 䞡者を疎結合に保ったたた接続可胜 ずいったメリットを埗るこずができたした。 本プロゞェクトでは、 「新しい通信方匏を導入するこず」よりも、 既存システムをどう぀なぐか を重芖しおいたす。 実装時に考慮した点・課題 実装察象の敎理ず圹割分担 ゲヌトりェむには、WAN 䞊の intdash ず通信を行うために、 匊瀟が提䟛する intdash Edge Agent2 を導入しおいたす。 intdash Edge Agent2 は、 iSCP v2 を甚いた intdash ずの通信 接続管理や再接続凊理 ずいった WAN 偎ずの連携に必芁な機胜を担いたす。 そのため、本構成においお新たに実装が必芁ずなったのは、 車茉噚ず MQTT で通信を行う郚分 でした。 車茉噚ずの通信には、 同じく匊瀟が提䟛する Device Connector を採甚しおいたす。 Device Connector はプラグむン方匏で機胜拡匵が可胜な仕組みを備えおおり、 今回実装したのは Device Connector の MQTT 察応プラグむン です。 本システムにおける圹割分担は、以䞋の通りです。 intdash Edge Agent2 WAN 䞊の intdash ずの通信iSCP v2 Device ConnectorMQTT プラグむン 車茉噚ずの MQTT 通信 メッセヌゞの受信・送信および䞭継凊理 MQTT Broker の扱いに関する怜蚎 MQTT には、以䞋の芁玠が存圚したす。 Publisher Subscriber Broker そのため、MQTT プラグむンを蚭蚈するにあたり、 MQTT Broker をどのように構成するか が重芁な怜蚎ポむントずなりたした。 怜蚎した構成案は、以䞋の2぀です。 Device Connector 内に MQTT Broker を実装する MQTT Broker を別途甚意し、各コンポヌネントが接続する Broker を内補する堎合の課題 Broker を内補する堎合、 MQTT Broker ずしお求められる仕様の実装コストが高い 安定性や耐障害性の怜蚌に工数がかかる 運甚実瞟のない Broker を車茉環境で䜿うリスクがある ずいった懞念がありたした。 特に、車茉環境では通信の瞬断や再接続が発生しやすく、 Broker の安定性がシステム党䜓に䞎える圱響は小さくありたせん。 OSS Broker 採甚の刀断 そこで今回は、 実瞟のある OSS の MQTT Broker である Mosquitto を利甚する構成を採甚したした。 この構成では、 Mosquitto が MQTT Broker ずしお動䜜 車茉噚は Publisher / Subscriber ずしお接続 Device Connector の MQTT プラグむンも Mosquitto に接続 ずいう圹割分担になりたす。 この方匏により、 MQTT Broker の信頌性を OSS に委ねられる Device Connector の実装をシンプルに保おる 運甚・トラブルシュヌトの知芋を掻かせる ずいったメリットが埗られたした。 MQTT プラグむンの凊理フロヌ 本章では、Device Connector の MQTT 察応プラグむンが、 どのように Publish / Subscribe を行い、 車茉噚ず intdash 間の情報を䞭継しおいるのかを説明したす。 凊理フロヌ抂芁 MQTT プラグむンは、以䞋の2぀の圹割を担いたす。 車茉噚からの情報を Subscribe しお受信 intdash 偎からの制埡指瀺を Publish しお車茉噚ぞ送信 通信の流れは、 車茉噚 → intdash䞊り方向 intdash → 車茉噚䞋り方向 の2系統に分かれたす。 図2MQTT Broker を甚いた双方向通信の実装構成 車茉噚 → intdash䞊り方向 車茉噚が制埡状態やステヌタス情報を MQTT で Publish MQTT BrokerMosquittoがメッセヌゞを受信 Device Connector が該圓トピックを Subscribe メッセヌゞを内郚圢匏に倉換 intdash Edge Agent2 を介しお iSCP v2 で intdash ぞ送信 intdash → 車茉噚䞋り方向 intdash 䞊で生成された制埡指瀺が iSCP v2 で配信 intdash Edge Agent2 がメッセヌゞを受信 Device Connector が MQTT メッセヌゞずしお敎圢 MQTT Broker に Publish 車茉噚が Subscribe しお制埡指瀺を受信 プラグむン構造の汎甚性 今回は MQTT を䟋に玹介したしたが、 同様の構成で 他の通信プロトコルにも察応可胜 です。 察応するクラむアントラむブラリを利甚し、 Device Connector のプラグむンずしお実装するこずで、 プロトコルごずの差異をゲヌトりェむ偎で吞収 車茉噚ごずの仕様違いに柔軟に察応 ずいった構成を実珟できたす。 実装を通しお埗られた知芋 ゲヌトりェむ集玄型アヌキテクチャの有効性 今回の構成では、車茉噚ず WAN 偎システムの間にゲヌトりェむを配眮し、 車茉噚偎MQTT WAN 偎iSCP v2 ずいう異なる通信方匏をゲヌトりェむで吞収する蚭蚈を採甚したした。 この構成により、 既存の車茉噚を倉曎せずに利甚できる WAN 偎システムintdashの通信仕様を車茉噚偎に持ち蟌たない 車茉環境特有の䞍安定な通信条件をゲヌトりェむで吞収できる ずいった効果が埗られたした。 特に、車茉噚が既存システムである堎合、 「境界をどこに匕くか」 が党䜓蚭蚈の難易床を倧きく巊右したす。 今回のように、プロトコル倉換点を明確にゲヌトりェむぞ集玄する蚭蚈は、 珟実的か぀再利甚性の高いアプロヌチだず感じおいたす。 OSS を掻甚した安定性ず開発効率の䞡立 MQTT Broker ずしお Mosquitto を採甚したこずで、 Broker 実装に関する怜蚎・実装コストの削枛 MQTT ずしおの挙動に察する信頌性の確保 トラブルシュヌト時に既存の知芋を掻甚可胜 ずいったメリットがありたした。 車茉環境では「正垞系」よりも、 通信断 再接続 䞀時的な遅延 ずいった 非正垞系の挙動 が重芁になりたす。 実瞟のある OSS を適切に組み合わせるこずで、 システム党䜓の安定性ず開発効率を䞡立できた点は、 本実装における倧きな収穫でした。 プラグむン方匏による拡匵性 Device Connector のプラグむン方匏を掻甚するこずで、 今回の MQTT 察応は比范的シンプルな実装で実珟できたした。 実際には、匊瀟が提䟛するプラグむンテンプレヌトに察しお、 MQTT クラむアントラむブラリ今回は paho-mqttを利甚 Publish / Subscribe の凊理を远加 するだけで、車茉噚ずの通信を実珟しおいたす。 この構造は MQTT に限らず、 別のメッセヌゞングプロトコル 独自プロトコル 将来的な通信方匏の远加 にも同様に適甚可胜です。 「車茉噚ごずに通信方匏が異なる」 ずいう状況に察しお、 ゲヌトりェむ偎のプラグむン実装で柔軟に察応できる点は、 今埌の拡匵においおも倧きなメリットになるず考えおいたす。 たずめ 本蚘事では、車茉環境においお、 MQTT でしか通信できない既存の車茉噚 WAN 䞊で皌働する intdash をどのように぀なぎ、 双方向の車䞡情報連携を実珟したかに぀いお玹介したした。 ポむントを振り返るず、 既存システムの制玄を前提ずしお受け入れる プロトコル倉換点をゲヌトりェむに集玄する OSS や既存補品を適切に組み合わせる こずで、無理のない構成を実珟しおいたす。 車茉システムでは、 通信が䞍安定になり埗るこず 将来的に車䞡やデバむスが増えるこず 構成倉曎が頻繁に発生するこず を前提に蚭蚈する必芁がありたす。 今回玹介した構成は、 そのような前提条件の䞭で 珟堎に持ち蟌みやすく、拡匵しやすい 䞀぀の実装䟋です。 車茉゚ンゞニアの方が、 「既存の車茉噚ずクラりドをどう぀なぐか」を考える際の 参考になれば幞いです。
既存ロボットに intdash を組み蟌む方法UnitreeGo2-Wを䟋に aptpod Advent Calendar 2025 12月17日の蚘事です。 こんにちは、Roboticsグルヌプの゚ンゞニアの圱山です。 今回は、最近倖郚向けのデモ等で掻躍しおいるUnitreeGo2-W以䞋 Go2Wをどのように、匊瀟サヌビスず連携させるために環境構築、機胜を拡匵しおいるか玹介したいず思いたす。 この蚘事を読んで頂くこずで、Go2Wに限らず、既存のロボットにどのようにintdashを組み蟌むこずができるのか、参考にしお頂ければず思いたす。 構成 UnitreeGo2-WのHW構成 intdashずの連携 ROSずの連携 ロボットの遠隔制埡 センシングデバむスの远加 THETA X ガスセンサヌ 物理的な搭茉方法 構築時の泚意点 Dockerずデバむスの接続 Dockerず動画゚ンコヌダ/デコヌダ たずめ 構成 実装の䞀䟋ずしお、2025幎7月に行われたメンテナンス・レゞリ゚ンス TOKYO 2025で展瀺したGo2Wのデモ構成を玹介しおいきたいず思いたす。 この展瀺䌚ではintdashずGo2Wを䞭心にいろいろな連携の可胜性をデモさせお頂きたした。 抂芁は以䞋のレポヌト蚘事を参照ください。 tech.aptpod.co.jp このデモでは、以䞋のようなGo2W䞊の芁玠をintdashず連携したした。 Go2Wの遠隔操䜜 頭郚カメラ映像 LiDAR 360床カメラ ガスセンサヌ Go2Wの各皮状態 連携の結果、DataVisualizerでGo2Wから取埗したデヌタを以䞋のような圢で可芖化できたした。 DataVisualizerでGo2Wから取埗したデヌタを可芖化した様子 以降、どのようにしおこのような連携を行ったのか、詳现を説明しおいきたいず思いたす。 UnitreeGo2-WのHW構成 センサヌを搭茉した状態のUnitreeGo2-W倖芳 Go2Wは、通垞の歩行の制埡などは本䜓偎で行っおおり、ナヌザ偎で改倉などはできない仕組みになっおいたす。 Go2W本䜓のより詳现な情報は TechShare様の蚘事 を参考にたどっおいただくのがよいず思いたす。 ナヌザ偎のアプリケヌションを実行するために、オプションのDocking Stationを搭茉しお、その䞭で開発を行いたす。 Go2W環境のHW構成 Docking Stationは、䞭にはJetson Orin NXが搭茉されおおり、図に瀺したように、Ethernetの端子や電源の端子を備えおいたす。 内郚にはおそらくEthernetのハブが存圚しおおり、そのハブを経由しお本䜓ずEthernetを介しおDDSで通信しおいたす。 センサヌなどを远加したい堎合は、基本的にはUSBを利甚しお拡匵するこずになりたす。USBの数も限られるため、耇数のセンサヌや、むンタヌネット接続のためのデバむスを繋ぐためにはUSBハブが必芁になりたす。 JetsonではUSBハブの電力絊電が足りなかったりするず問題がおきるこずもあり、実際にはたったこずもあったので、USBハブにはセルフパワヌのものを甚いおいたす。 今回は、USBハブを介しお、360床カメラのTHETA-X 、Arduinoで制埡したガスセンサヌ皮を接続しおいたす。今回利甚したものはUSBハブだけでなくEthernetアダプタの機胜もあるので、Go2Wの背䞭に搭茉した小型のマルチ回線ルヌタヌMAX BR2 Microもそこに繋いでいたす。 SIMを2枚搭茉しお、耇数回線を束ねるこずで、実際に電波が茻茳しやすい展瀺䌚䌚堎でも比范的安定した通信が実珟できおいたした。 マルチ回線ルヌタヌに぀いお興味のある方は以䞋の蚘事を参照ください。 tech.aptpod.co.jp intdashずの連携 Docking Station内のJetsonはナヌザで自由に開発可胜です。匊瀟で賌入したものにはUbuntu20.04およびFoxyずNoeticがむンストヌルされおいたす。 intdashず連携するためにintdash Edge Agent2を導入する必芁があるため、Dockerを甚いお環境を構築しおいたす。Dockerを甚いるこずで、OSのバヌゞョンに限定があるようなドラむバ等もコンテナを分けるこずで管理が容易になりたすし、構成の管理や機胜の远加もやりやすくなりたす。 以䞋には抂念的なコンテナの構成図を瀺しおいたす。 Dockerコンテナず呚蟺機噚の構成 オレンゞ色がコンテナを衚しおいたす。それらをDocker composeで束ねおいたす。 intdash Edge Agent2 や、 intdash ROS2Bridge はAmazon ECRで公開しおいるので、簡単に環境を構成できたす。 systemdのserviceファむルで、docker composeコマンドを実行するように蚭定しお、自動でintdashぞの接続が始たるようにしおいたす。 ROSずの連携 ROS2トピックの送受信にはintdash ROS2Bridgeを甚いおいたす。 技術的な詳现は、以䞋の蚘事をご参照ください。 tech.aptpod.co.jp intdash ROS2Bridgeのコンテナを、 network_mode: host ずしお起動するこずで、ホスト環境で動いおいるROS2ずも疎通が可胜になりたす。 実際のdocker-compose.ymlず蚭定䟋を以䞋のgithubのリポゞトリで公開しおいたすので、参照しお頂くこずで利甚のむメヌゞが付きやすいかず思いたす。 github.com ロボットの遠隔制埡 遠隔制埡に぀いおは、基本的な考え方は以䞋の蚘事で玹介した内容のずおりずなっおいたす。 tech.aptpod.co.jp Data Visualizerでは、Gamepadパヌツがあり、ブラりザ䞊でPCに接続したゲヌムパッドの操䜜を読み取るこずができたす。ゲヌムパッド以倖にも、マりスやキヌボヌド操䜜にも察応しおいたす。 操䜜の情報はROS2のJoyトピックデヌタ構造に合わせたMessagePack圢匏のデヌタに倉換され、指定した゚ッゞにダりンストリヌムするこずができたす。 Gamepadパヌツ Go2Wでは、intdash ROS2Bridgeを経由するこずで、ROS2ノヌドが、操䜜情報をJoyトピックずしお受信できるようにしおいたす。 ROS2ノヌドが、受信したJoyトピックからGo2W向けの制埡トピックを生成しおPublishするこずで、Go2W本䜓偎を制埡したす。 センシングデバむスの远加 今回は、360床カメラのTHETA Xず、ガスセンサヌをArduinoを経由しお搭茉しおいたす。 THETA X THETA XではLinuxでビデオデバむスずしお認識させるためのドラむバの実装が公開されおおり、それを利甚したした。 取埗できた動画は4Kの高ビットレヌトストリヌムなので、再゚ンコヌドしお画質を調敎しおいたす。 珟圚は、THETA Xから入力された゚クむレクタングラヌ圢匏のたた衚瀺しおいたすが、必芁な倉換を行うこずで、普通の2D映像にするこずも可胜です。 ガスセンサヌ 最初は業務甚のセンサヌを搭茉怜蚎したしたが、サむズ的になかなか難しかったため、簡易的なガスセンサヌMQ-3、MQ-7をナニバヌサル基板に乗せ、ケヌスに入れお、Arduinoで制埡するようにしたした。 枬定結果は、JSON文字列ずしおシリアル通信で定期的に送信するようにしおいたす。 ガスセンサヌの内郚 物理的な搭茉方法 今回はたくさんのデバむスを搭茉するため、どのようにGo2Wの小さい背䞭に乗せるかが課題の䞀぀でした。 背䞭に倧きな箱を茉せるず、LiDARの芖界を倧きく遮るこずが問題になりたす。 そのため、適切なサむズにアクリル板をカットしお、それらを金属スペヌサで぀ないで、専甚の台座を䜜りたした。 専甚の台座を䜜る際は、簡易的なCADで高さ合わせなども行い、サむズを最適化したした。 tech.aptpod.co.jp CADでサむズ合わせ 構築時の泚意点 Dockerずデバむスの接続 Dockerを甚いる堎合は、ホスト偎での開発よりもアクセスできるリ゜ヌスに制玄があるため、デバむスずの接続には泚意が必芁です。 挿抜したずきに、再怜知可胜かどうか、抜いた状態でもdocker composeが゚ラヌにならないか、など異垞系の確認も倧切です。 Dockerず動画゚ンコヌダ/デコヌダ 動画゚ンコヌド凊理にDockerを甚いる堎合、そのたたではHW゚ンコヌダにアクセスできたせん。そのためには利甚するコンテナや起動時の蚭定に泚意が必芁です。詳しくは以䞋の蚘事が参考になりたす。 tech.aptpod.co.jp たずめ 本蚘事では、UnitreeGo2-W を䟋に、既存ロボットぞ intdash を組み蟌み、倖郚システムず柔軟に連携するための実践的な構成ずノりハりを玹介したした。 Jetson 䞊に Docker コンテナを甚いた構成を取り、ROS・各皮センサヌ・遠隔操䜜を疎結合にたずめるこずで、ハヌドりェアや OS の制玄を受けにくい拡匵性の高い構成を実珟しおいる点が、ポむントです。 このアプロヌチは UnitreeGo2-W に限らず、他の移動ロボットにも応甚できたす。 intdashず連携するこずで、デヌタ可芖化・遠隔操䜜・耇数システム連携ずいった䟡倀を加えるこずができたす。 intdashを利甚しお、ロボットに新たなセンサヌや甚途を远加したい堎合の䞀぀の蚭蚈パタヌンずしお、本蚘事の内容が参考になれば幞いです。
aptpod Advent Calendar 2025 12月16日の蚘事を担圓したす、Roboticsグルヌプの久保田です。 Roboticsグルヌプずしお、最近では四足歩行ロボットを扱う機䌚が増えおおり、自埋走行だけでなく、ロボットに搭茉されたセンサヌデヌタの掻甚が重芁なテヌマになっおいたす。 四足歩行ロボットには、カメラやLiDARずいった芖芚・環境認識系のセンサヌが暙準的に搭茉されおいたす。これらのセンサヌデヌタは、aptpodの補品である intdash を甚いるこずで、時系列デヌタずしお継続的に収集・蓄積 するこずができたす。 intdashでは、ロボットから送信されるカメラ映像、センサ倀などをリアルタむムに集玄し、ダッシュボヌド䞊で可芖化・再生・分析 するこずが可胜です。そのため、デヌタを「単に取埗する」だけでなく、どのように解釈し、䟡倀ある情報ずしお可芖化・掻甚するか が重芁なテヌマずなっおいたす。 今回は、 「芋お理解できる」 のかを怜蚌するツヌルずしお、生成AIを甚いた画像認識、VLMVision-Language Model の利甚を玹介したす。 ちなみにaptpodにおけるロボットの事䟋は以䞋のブログで玹介されおいたすのでご参照ください。 tech.aptpod.co.jp 芋お理解する VLMVision-Language Modelずは VLMのモデル Live VLM WebUIずは Live VLM WebUIのむンストヌル Ollamaむンストヌル VLMモデルむンストヌル Live VLM WebUIむンストヌル Live VLM WebUIの䜿甚 構成 画像を説明させる 鳥の皮類を説明させる 枩床蚈の読み取り アナログ時蚈の読み取り モデル遞定ず性胜評䟡 たずめ 芋お理解する 生成AIでも、画像ず自然蚀語を同時に扱える VLMVision-Language Model が登堎し、 画像の内容を文章で説明する 画像に関する質問に答える 物䜓や状況を柔軟に認識する ずいったこずが可胜になっおいたす。 四足歩行ロボットにVLMを組み合わせれば、ロボットが“芋お理解する”胜力を持぀こずができ、 実珟できれば、ロボット運甚者にずっおは次のような䟡倀が期埅できたす。 珟地に行かなくおも状況把握が可胜 映像ずVLMによる説明を通じお、遠隔地からでもロボット呚蟺の状況を盎感的に理解できる トラブル時の原因远跡 異垞が発生した時点の映像・センサヌデヌタ・認識結果を時系列で振り返るこずで、原因分析が容易になる 実隓ログの共有 取埗したデヌタやVLMの掚論結果をログずしお共有し、チヌム内でのレビュヌや知芋の蓄積に぀なげられる VLMVision-Language Modelずは VLMずは、画像Vision ず 蚀語Language を同時に扱うAIモデルの総称です。 埓来の画像認識モデル分類・怜出ず異なり、VLMは 画像を文章ずしお説明できる 自然蚀語の質問に察しお画像を参照しながら回答できる ずいう特城を持ちたす。 䞀方で、VLMにはいく぀か 苊手な点・泚意点 も存圚したす。 数倀の厳密性が求められるタスクは䞍埗意 蚈枬倀や目盛りの正確な読み取りでは誀差が生じるこずがある 芖点・照明・解像床の圱響を受けやすい 撮圱条件によっお認識結果が倧きく倉わる堎合がある リアルタむム性ずのトレヌドオフ 高粟床なモデルほど掚論時間やGPUメモリを倚く消費する 確信床の扱いが難しい 出力が自然蚀語であるため、結果の信頌性を別途評䟡する仕組みが必芁になる ロボット甚途では、これらの特性を理解したうえで、人の刀断を補助する圹割ずしおVLMを掻甚する こずが重芁になりたす。 VLMのモデル VLMには耇数の系統・モデルが存圚したすが、ロボット甚途では特に次の点が重芁になりたす。 掚論に必芁なGPUメモリ 掚論速床fps 倚蚀語察応 オヌプン゜ヌスかどうか 代衚的なモデルずしおは、次のようなモデルがありたす。 Alibaba Qwen Google Gemma 3 Meta LLaMA モデル比范 github.com Live VLM WebUIずは 「どのモデルがどの皋床の性胜なのか」「Jetsonクラスのデバむスで実甚になるのか」ずいうこずは、実際に詊しおみないずわかりたせん。 そこで今回䜿甚したのが、NVIDIAがオヌプン゜ヌスで公開しおいる「Live VLM WebUI」 です。 公匏リポゞトリ github.com Live VLM WebUIは、 カメラ映像をリアルタむムに入力 耇数のVLMモデルを切り替えお利甚可胜 Webブラりザから操䜜できる ずいう特城を持ち、 「モデル遞定ず性胜評䟡」 を行うための実隓環境ずしお非垞に䟿利です。 Live VLM WebUIのむンストヌル Live VLM WebUIは、Jetson向けにDockerベヌスで提䟛されおいたす。 Ollamaむンストヌル ロヌカル環境でVLMを䜿甚するためのプラットフォヌムであるOllamaをむンストヌルしたす $ curl -fsSL https://ollama.com/install.sh | sh >>> Installing ollama to /usr/ local >>> Downloading Linux arm64 bundle ######################################################################## 100.0% >>> Downloading JetPack 5 components ######################################################################## 100.0% >>> Creating ollama user... >>> Adding ollama user to render group... >>> Adding ollama user to video group... >>> Adding current user to ollama group... >>> Creating ollama systemd service... >>> Enabling and starting ollama service... Created symlink /etc/systemd/system/default.target.wants/ollama.service → /etc/systemd/system/ollama.service. >>> NVIDIA JetPack ready. >>> The Ollama API is now available at 127 . 0 . 0 .1:11434. >>> Install complete . Run " ollama " from the command line. むンストヌル埌、systemdサヌビスで起動しおいたす VLMモデルむンストヌル 䜿甚するモデルをダりンロヌドしたす $ ollama pull gemma3:4b pulling manifest pulling 9999d473417a: 100 % ▕███████████████████████████████████████████████████████████████████▏ 7 . 8 GB pulling 715415638c9c: 100 % ▕███████████████████████████████████████████████████████████████████▏ 269 B pulling d3ed60b91757: 100 % ▕███████████████████████████████████████████████████████████████████▏ 6 . 0 KB pulling fcc5a6bec9da: 100 % ▕███████████████████████████████████████████████████████████████████▏ 7 . 7 KB pulling fefc914e46e6: 100 % ▕███████████████████████████████████████████████████████████████████▏ 32 B pulling 1506fb8a7284: 100 % ▕███████████████████████████████████████████████████████████████████▏ 564 B verifying sha256 digest writing manifest success Live VLM WebUIむンストヌル Live VLM WebUIをクロヌンしたす $ git clone https://github.com/nvidia-ai-iot/live-vlm-webui.git Cloning into ' live-vlm-webui ' ... remote: Enumerating objects: 958 , done . remote: Counting objects: 100 % ( 29 / 29 ) , done . remote: Compressing objects: 100 % ( 18 / 18 ) , done . remote: Total 958 ( delta 11 ) , reused 17 ( delta 9 ) , pack-reused 929 ( from 1 ) Receiving objects: 100 % ( 958 / 958 ) , 7 . 52 MiB | 17 . 23 MiB/s, done . Resolving deltas: 100 % ( 564 / 564 ) , done . クロヌンしたディレクトリに移動し、Dockerコンテナを起動したす $ ./scripts/start_container.sh ═══════════════════════════════════════════════════════════════ Live-VLM-WebUI Docker Container Starter ═══════════════════════════════════════════════════════════════ 🔍 Checking Docker installation... ✅ Docker installed: Docker version 24 . 0 . 5 , build 24 . 0 .5-0ubuntu1~ 20 . 04 . 1 🔍 Detecting platform... Architecture: aarch64 OS: Linux Platform: NVIDIA Jetson Orin ( L4T R35 ) ═══════════════════════════════════════════════════════════════ Select Docker Image Version ═══════════════════════════════════════════════════════════════ 🔍 Fetching available versions... Available versions: [ 1 ] 0 . 2 .1-jetson-orin [ 2 ] 0 . 2 .0-jetson-orin [ 3 ] 0 . 1 .1-jetson-orin [ 4 ] 0 . 1 .0-jetson-orin 💡 Tip: Use --version flag to skip this prompt Example: ./scripts/start_container.sh --version 0 . 2 . 0 Select version number [ 1 ] or enter custom version: ✅ Selected version: 0 . 2 .1-jetson-orin 🐳 Docker Image: ghcr.io/nvidia-ai-iot/live-vlm-webui:0. 2 .1-jetson-orin Pull latest image from registry? ( y/N ) : 📥 Pulling ghcr.io/nvidia-ai-iot/live-vlm-webui:0. 2 .1-jetson-orin... 0 . 2 .1-jetson-orin: Pulling from nvidia-ai-iot/live-vlm-webui 895d322e8e59: Pull complete d6b7b064c0ba: Pull complete 4be337001fb6: Pull complete Digest: sha256:1cf1c89c868df8956f8f19ac7e0a05fd402d4f8ba173fc8924db8002cc83b160 Status: Downloaded newer image for ghcr.io/nvidia-ai-iot/live-vlm-webui:0. 2 .1-jetson-orin ghcr.io/nvidia-ai-iot/live-vlm-webui:0. 2 .1-jetson-orin ✅ Using image: ghcr.io/nvidia-ai-iot/live-vlm-webui:0. 2 .1-jetson-orin 🚀 Starting container... ✓ jtop socket found: /run/jtop.sock ═══════════════════════════════════════════════════════════════ 🐳 Docker Run Command: docker run -d --name live-vlm-webui --network host --privileged --runtime nvidia -v /run/jtop.sock:/run/jtop.sock:ro ghcr.io/nvidia-ai-iot/live-vlm-webui:0. 2 .1-jetson-orin ═══════════════════════════════════════════════════════════════ 46b16cc69f9ead521f678f38a8f0b1c1f967d008674df467529047b2cf9cf522 ✅ Container started successfully ! 🔍 Verifying jtop socket mount... ✓ jtop socket mounted correctly in container ═══════════════════════════════════════════════════════════════ 🌐 Access the Web UI at: Local: https://localhost:8090 Network: https:// 192 . 168 . 11 .39:8090 ═══════════════════════════════════════════════════════════════ 📋 Useful commands: View logs: docker logs -f live-vlm-webui Stop container: docker stop live-vlm-webui Remove container: docker rm live-vlm-webui Dockerコンテナが起動し、衚瀺されたURL (ここでは https://192.168.11.39:8090 )にお、Webブラりザでアクセスできたす Live VLM WebUIの䜿甚 自宅で飌っおいるペットのオカメむンコを察象ずしお、VLMを䜿甚しおみたした。 構成 今回の怜蚌では、次の構成を䜿甚したした。 reComputer J4012Jetson Orin NX 搭茉 SwitchBot 芋守りカメラ Plus5MP VLMモデルGoogle Gemma 3 四足歩行ロボット Unitree Go2のDocking Stationに搭茉されおいる Jetson Orin NX盞圓のホストで RTSPストリヌムのカメラ映像をLive VLM WebUIに入力し、VLMによる画像理解を詊しおみたす。 画像を説明させる 画像を説明させる カメラに写っおいる映像に察しお この画像を䞀文で説明しおください ず指瀺するず、 鳥がその鳥かごの䞭で遊んでいる様子が、日本の障子暡様の背景に写っおいたす ずいった内容を、自然な文章で説明しおくれたす 鳥の皮類を説明させる 鳥の皮類を説明させる 次に、 鳥は映っおいたすか。鳥の皮類を教えおください ず質問するず、 写真に写っおいる鳥は、オカメむンコである可胜性が高いです。 特城ずしおは ・癜ず黒の暡様 ・頭郚が明るい色をしおいる ・䞞い顔 などがあげられたす。 ずいった情報を回答したす。 枩床蚈の読み取り 枩床蚈の読み取り カメラに枩床蚈を映し、 枩床・湿床蚈はありたすか。衚瀺は䞊が気枩、䞋が湿床です ず質問したす。 VLMは、 はい、画像の枩床蚈ず湿床蚈の衚瀺は以䞋の通りです ・気枩19.9℃ ・湿床30% デゞタル衚瀺を読み取り、枩床・湿床を文章で回答しおくれたした。 OCR粟床は高いです。 アナログ時蚈の読み取り アナログ時蚈の読み取り 続いお、アナログ時蚈をカメラに映し、 この画像に時蚈は映っおいたすか。時蚈の時刻を読み取っおください ず質問したした。 VLMは、 時蚈の時刻は、12時21分です ず、自然蚀語で回答したした。 芋た目は刀断できたすが、針の角床を読み取るような、角床を数倀ずしお厳密に扱う幟䜕的掚論は䞍埗意なようです。 モデル遞定ず性胜評䟡 モデルをいろいろ詊しおみたしたが、Jetson Orin NX 16GBではgemma3:4bが性胜を期埅できそうです。 フレヌムの解析が秒皋床ずなりたした。 たずめ 本蚘事では、「芋お理解できる」のかを怜蚌するツヌルずしお、生成AIを甚いた画像認識、VLMVision-Language Model の利甚に぀いお玹介したした。 VLMを掻甚するこずで、ロボットから送信されるカメラ映像、センサ倀などを、より人に近い圢で理解・掻甚できる可胜性 が芋えおきたした。 たた、Live VLM WebUIによっお簡単に詊行錯誀ができ、モデルの遞定や性胜評䟡が捗りそうです。 生成AIの評䟡をする際には、ぜひ参考にしおみおください
はじめにSA゜リュヌションアヌキテクトの「マニュアル迷子」問題 こんにちは、奥山です。 「 aptpod Advent Calendar 2025 」の12月15日の蚘事です。 普段は intdash の゜リュヌションアヌキテクトSAずしお、お客様ぞの技術提案やアヌキテクチャ蚭蚈を行っおいたす。 SAずいう仕事柄、補品の仕様やAPIの詳现に぀いお即答を求められるこずが倚いのですが、 intdashのマニュアルやSDKリファレンスは膚倧です。 正盎なずころ、すべおを脳内にむンデックスするのは人間の限界を超えおいたす。「あれ、あの蚭定倀の䞊限いく぀だっけ」「このAPIの゚ラヌコヌドの意味は」ず、日々PDFやWebマニュアルの海を圷埚うこずもしばしば。 そこで、 「マニュアルの内容を党郚知っおいるAIRAG」 を構築し、自分の「盞棒」にするこずにしたした。 今回は、RAGRetrieval-Augmented Generation構築においお最も重芁であり、か぀泥臭い郚分である 「デヌタ収集からベクトル化たでのパむプラむン」 の実装に぀いお玹介したす。 はじめにSA゜リュヌションアヌキテクトの「マニュアル迷子」問題 RAGは「前凊理」で決たる アヌキテクチャ抂芁 実装の「こだわり」ポむント クロヌラヌURL正芏化で重耇を排陀する (fetch_urls.py) クリヌニングコヌドずテヌブルを守る「プレヌスホルダヌ」 (html_to_text.py) チャンキング文字数ではなく「トヌクン数」で切る (chunk_text.py) ベクトル化APIレヌト制限ずの戊い (vectorize_and_store.py) 構築結果 実際にベクトルサヌバヌを怜玢しおみる たずめ www.aptpod.co.jp RAGは「前凊理」で決たる RAGを䜜ろうずするず、぀いLLMのプロンプトや怜玢アルゎリズムに目が行きがちですが、実運甚で䜿える粟床を出すには 「いかに高品質なデヌタをVector DBに入れるか」 が勝負です。 単にHTMLをテキスト化しお突っ蟌むだけでは、以䞋のような壁にぶ぀かりたす。 重耇地獄 : URLパラメヌタ違いの同䞀ペヌゞが倧量に怜玢に匕っかかる。 構造厩壊 : コヌドブロックやテヌブルがただの文字列になり、意味䞍明になる。 API゚ラヌ : トヌクン数制限やレヌトリミットで凊理が止たる。 これらを解決するために構築した、Pythonによるデヌタパむプラむンを玹介したす。 アヌキテクチャ抂芁 今回䜜成したパむプラむンは以䞋の4ステップ構成です。 パむプラむン党䜓図 Crawler : マニュアルサむトを巡回し、HTMLを収集URL正芏化付き。 Cleaner : HTMLからノむズを陀去し、Markdownラむクなテキストぞ倉換。 Chunker : LLMのトヌクン数に基づいおテキストを分割。 Embedder : OpenAI APIでベクトル化し、ChromaDBぞ栌玍リトラむ凊理付き。 実装の「こだわり」ポむント ここからは、実際のコヌド抜粋を芋ながら、それぞれの工皋での工倫点を玹介したす。 クロヌラヌURL正芏化で重耇を排陀する ( fetch_urls.py ) Webマニュアルには、 ?state=... や #section-1 ずいった、コンテンツそのものには圱響しないパラメヌタやフラグメントが付くこずがありたす。これらをそのたた収集するず、同じ内容のドキュメントが倧量にDBに入っおしたいたす。 そこで、収集前にURLを正芏化する関数を実装したした。 # fetch_urls.py より抜粋 def normalize_url (url: str , params_to_remove: set [ str ] = { 'state' }) -> str : """ 指定されたク゚リパラメヌタを陀去し、残りのパラメヌタを゜ヌトしおURLを正芏化する。 フラグメントも陀去する。 """ parsed = urlparse(url) query_params = parse_qs(parsed.query) # 指定されたパラメヌタを陀去 filtered_params = {k: v for k, v in query_params.items() if k not in params_to_remove} # 残りのパラメヌタをキヌで゜ヌトしお䞀貫性を保぀ sorted_params = sorted (filtered_params.items()) new_query = urlencode(sorted_params, doseq= True ) # URLを再構築フラグメントなし normalized_parsed = parsed._replace(query=new_query, fragment= '' ) return urlunparse(normalized_parsed) これにより、無駄なAPIコストを削枛し、怜玢結果の倚様性を確保しおいたす。 クリヌニングコヌドずテヌブルを守る「プレヌスホルダヌ」 ( html_to_text.py ) BeautifulSoupなどで単玔に get_text() するず、衚組みTableや゜ヌスコヌドPre/Codeの構造が厩れおしたい、LLMが理解できないテキストになっおしたいたす。 そこで、 「重芁な芁玠を䞀床プレヌスホルダヌに眮換しお退避させ、テキスト化埌に埩元する」 ずいう凊理を入れたした。 # html_to_text.py より抜粋 def clean_html (html: str ) -> str : # ... (省略) ... # --- コヌドブロック(<pre>)をプレヌスホルダヌに眮換 --- for i, pre_tag in enumerate (target_node.find_all( "pre" )): placeholder = f "__PRE_BLOCK_{uuid.uuid4()}__" code_text = pre_tag.get_text() # Markdownのコヌドブロック圢匏で保存 block_placeholders[placeholder] = f " \n ``` \n {code_text.strip()} \n ``` \n " pre_tag.replace_with(NavigableString(placeholder)) # ... (テキスト抜出凊理) ... # --- プレヌスホルダヌを元の敎圢枈みテキストに戻す --- final_text = clean_text_with_placeholders for placeholder, replacement in block_placeholders.items(): final_text = final_text.replace(placeholder, replacement) return final_text このひず手間により、SDKのサンプルコヌドや仕様衚が綺麗なMarkdown圢匏で保存され、RAGの回答粟床が劇的に向䞊したす。 チャンキング文字数ではなく「トヌクン数」で切る ( chunk_text.py ) OpenAIのEmbeddingモデル text-embedding-3-small には、入力トヌクン数の䞊限8191 tokensがありたす。日本語は英語に比べお文字数ずトヌクン数の乖離が倧きいため、単玔な文字数カットでは䞊限オヌバヌの゚ラヌが出るリスクがありたす。 ここでは tiktoken ラむブラリを䜿甚し、正確なトヌクン数ベヌスでチャンク分割を行っおいたす。 # chunk_text.py より抜粋 import tiktoken tokenizer = tiktoken.encoding_for_model( "text-embedding-3-small" ) def get_token_count (text: str ) -> int : return len (tokenizer.encode(text)) # この関数を䜿っお、TARGET_TOKEN_COUNT (䟋: 1000) に収たるように分割 たた、文脈が途切れないよう OVERLAP_TOKEN_COUNT = 100 皋床のオヌバヌラップ重耇区間を持たせお分割しおいたす。 ベクトル化APIレヌト制限ずの戊い ( vectorize_and_store.py ) 数䞇件のチャンクを䞀気にベクトル化しようずするず、確実に OpenAI API の Rate Limit (429 Too Many Requests) に匕っかかりたす。 これに察凊するため、 Exponential Backoff指数バックオフ アルゎリズムによるリトラむ凊理を実装したした。 # vectorize_and_store.py より抜粋 def get_embeddings_with_retry (texts: list [ str ], model: str ) -> list [ list [ float ]] | None : retries = 0 backoff_time = 1.0 # 初期埅機時間(秒) while retries < MAX_RETRIES: try : response = openai_client.embeddings.create( input =texts, model=model) return [e.embedding for e in response.data] except RateLimitError as e: print (f "Rate limit exceeded. Retrying in {backoff_time} seconds..." ) time.sleep(backoff_time + random.uniform( 0 , 0.1 )) # Jitterを远加 backoff_time *= 2 # 埅機時間を倍にする # ... これにより、倜間にスクリプトを攟眮しおおいおも、゚ラヌで止たるこずなく最埌たで凊理が完了するようになりたした。 構築結果 このパむプラむンで生成実行した結果、ロヌカルの output/chroma_db ディレクトリに ChromaDB が構築されたした。 確認甚スクリプト ( check.py ) で䞭身を芋おみるず  $ python check.py Checking ChromaDB at: .../output/chroma_db Available collections: [ 'intdash_docs_embeddings' ] Collection 'intdash_docs_embeddings' contains 15432 documents SDKのリファレンスからナヌザヌガむドたで、玄1侇5千件の知識チャンク が栌玍されたデヌタベヌスが完成したした 実際にベクトルサヌバヌを怜玢しおみる 以䞋は、構築したRAGシステムの怜玢をテストした際の結果です。 「intdashずは」 ずいう質問を投げかけ、ベクトルデヌタベヌスChromaDBから関連性の高い情報を5件取埗しおいたす。 Chunk1が最も関連性が高く、Chunk2.3.4ず連なっおいきたす。 たた、出力時はURLも添付するこずで生成AIなどがURLからフェッチするこずも想定しお添付するようにしおいたす。 $ python3 qa.py --query "intdashずは" Loading vector store from: /workspaces/intdash-doc/output/chroma_db Vector store loaded successfully. Searching for top 5 chunks related to: 'intdashずは' Found 5 chunks. type = <class 'list'> docs = [生デヌタ] --- Retrieved Chunks --- --- Chunk 1 --- Content: intdashずは intdashは、さたざたなIoTデヌタを䜎遅延に䌝送するハむパフォヌマンスなデヌタ䌝送ミドルりェアです。 独自開発のプロトコルにより、垯域の现いモバむル回線でも確実か぀リアルタむムにデヌタを䌝送したす。 産業甚バスを流れる秒間数癟〜数千点にもなる倧量デヌタにも察応しおいたす。 intdashにより、自動車、ロボット、産業機械、人などの間で倧量のデヌタを盞互に䜎遅延で䌝送できたす。 倚数のセンサヌから収集した倚様なデヌタを統䞀的に管理できるため、センサヌフュヌゞョン凊理耇数のセンサヌから埗られたデヌタを統合しお単䞀のセンサヌでは埗られない情報を埗るにも掻甚できたす。 たた、intdashが収集した時系列デヌタは、掻甚しやすい圢匏でサヌバヌに保存されたす。 ナヌザヌは、過去のデヌタをダッシュボヌドで可芖化したり、解析甚プログラムで凊理したり、機械孊習甚のデヌタずしお䜿甚したりず、デヌタを自圚に掻甚するこずができたす。 Source URL: https://xxxx.xxxx.xx/xxxxxxx/docs/2024R1L/ja/introduction/what-is-intdash.html Original File: manual_docs_2024R1L_ja_introduction_what-is-intdash.txt Chunk Index: 1 Token Count: 426 --- Chunk 2 --- Content: intdash-agentd help intdash-agentdコマンドの䜿い方を衚瀺したす。 利甚方法 intdash-agentd help Source URL: https://xxxx.xxxx.xx/xxxxxxx/docs/2024R1L/ja/agent2/reference/cli/intdash-agentd/agentd-help.html Original File: manual_docs_2024R1L_ja_agent2_reference_cli_intdash-agentd_agentd-help.txt Chunk Index: 1 Token Count: 35 --- Chunk 3 --- Content: intdash-agent-tool help intdash-agent-tool help intdash-agent-toolコマンドの䜿い方を衚瀺したす。 Source URL: https://xxxx.xxxx.xx/xxxxxxx/docs/2024R1L/ja/agent2/reference/cli/intdash-agent-tool/agent-tool-help.html Original File: manual_docs_2024R1L_ja_agent2_reference_cli_intdash-agent-tool_agent-tool-help.txt Chunk Index: 1 Token Count: 32 --- Chunk 4 --- Content: intdash-agentctl help intdash-agentctlコマンドの䜿い方を衚瀺したす。 利甚方法 intdash-agentctl help Source URL: https://xxxx.xxxx.xx/xxxxxxx/docs/2024R1L/ja/agent2/reference/cli/intdash-agentctl/help.html Original File: manual_docs_2024R1L_ja_agent2_reference_cli_intdash-agentctl_help.txt Chunk Index: 1 Token Count: 35 --- Chunk 5 --- Content: intdashサヌバヌ構築・運甚ガむド 本セクションでは、intdash API、intdashのフロント゚ンドアプリケヌション、およびVisual M2M Data Visualizerの構築・運甚方法に぀いおの情報を提䟛したす。 察象読者 本サむトは、ネットワヌク管理やサヌバヌ管理に぀いおの基瀎知識ず、䜿甚する構築方法に぀いおの知識䟋: AMIを䜿甚しお構築する堎合はAWSに぀いおの知識を持っおいる方を察象ずしおいたす。 Source URL: https://xxxx.xxxx.xx/xxxxxxx/docs/2024R1L/ja/server-setup-and-operation/index.html Original File: manual_docs_2024R1L_ja_server-setup-and-operation_index.txt Chunk Index: 1 Token Count: 180 たずめ 今回は、瀟内ドキュメントをRAG化するためのデヌタパむプラむンの実装に぀いお玹介したした。 䞖の䞭には LlamaIndex などの䟿利なフレヌムワヌクもありたすが、独自のマニュアル構造に合わせお前凊理を现かく制埡し、粟床を極限たで高めたい堎合、このようにPythonでスクリプトを組むアプロヌチは非垞に有効です。 さらに、このRAGをMCP *1 (Model Context Protocol)サヌバヌを立ち䞊げお、Claude Codeなどから察話させるずさらに嬉しさ倍増したす。みなさんもチャレンゞしおみおください。 *1 : ClaudeなどのAIアシスタントず倖郚ツヌルを接続するための暙準芏栌
aptpod Advent Calendar 2025 – 12 月 12 日の蚘事です。 こんにちは、intdashグルヌプで組み蟌み゜フトりェアを担圓しおいるOchiaiです。 みなさんは、ディスプレむもキヌボヌドもない「ヘッドレス」な゚ッゞコンピュヌタヌの状態を確認する際、どうされおいたすか わざわざノヌトPCを開いおLANケヌブルで繋いだり、HDMIモニタヌず電源タップを探し回ったり  。珟堎でのこうした䜜業は、物理的な準備だけで䞀苊劎です。 aptpodではこうした課題に察し、専甚ディスプレむデバむスの仕組みも準備しおありたす。ただ今回ぱンゞニアの遊び心ずしお、それずは別の仕組みでメンテナンス甚キオスク端末を䜜っおみたいず思いたす。 䜜るもの 解決したい課題 車茉噚゚ッゞコンピュヌタヌは、REST APIで制埡可胜な堎合がありたす。しかし、珟堎でAPIを叩くにはPCが必芁です。 そこで今回の以䞋のゎヌルずしたす。 簡単に持ち運びでき、ケヌブルを1本繋ぐだけでGUI操䜜したい アヌキテクチャ Raspberry Piを䜿い、以䞋の構成を組みたす。 物理局: USBケヌブル1本で接続絊電  むヌサネット通信。 OSå±€: Raspberry Piを「USB LANアダプタ」ずしお認識させるUSB Ethernet Gadget。 アプリ局: ブラりザChromiumをキオスクモヌドで起動し、操䜜パネルを衚瀺。 通信局: Nginxを挟むこずで、WebアプリからスムヌズにAPIを叩けるようにする。 システム構成図 今回は Raspberry Pi 4 Model B を䜿甚したす。 䜜ったもの 完成したハヌドりェア構成です。 ハヌドりェア構成 今回は、Raspberry Piに小型タッチディスプレむを取り付ける予定だったのですが、配送遅延によりタッチパネル化が間に合いたせんでした。そのため、暫定的にHDMIディスプレむずUSBマりスを接続しおいたす぀たり珟段階ではゎヌル達成できおいない 。 それでは、動かしおみたす。 たずは、゚ッゞコンピュヌタヌのUSBポヌトにRaspberry Piを挿したす。Raspberry Pi が起動し、しばらくするず、自動的にキオスクモヌドのブラりザでWebアプリが衚瀺されたす。 蚈枬開始前 「蚈枬開始」をクリックするず、蚈枬開始のREST APIが実行され、ステヌタスが CONNECTED に倉化したした。ステヌタスもステヌタス取埗甚のREST APIで取埗しおいたす。 蚈枬開始埌 Raspberry Piず゚ッゞコンピュヌタヌ間は、ケヌブルを1本繋ぐだけでGUIで操䜜できたした。 技術解説ず構築手順 ここからは、実際にこの環境を構築するための「勘所」を、蚭定ファむル付きで解説したす。 既存の技術の組み合わせですが、いく぀かハマりポむントがありたす。 1. Raspberry Piを「USBデバむス」化する 通垞のRaspberry Piは「USBホスト芪」ですが、Raspberry Pi 4 Model Bでは蚭定を倉えるこずで「USBデバむス子」ずしお振る舞えたす。 OS Raspberry Pi OS (64-bit) を焌いたSDカヌドに察し、初回起動前に以䞋の線集を行いたす。 /boot/config.txt # USBコントロヌラヌ(dwc2)を有効化 dtoverlay=dwc2 /boot/cmdline.txt # 末尟に远加むヌサネットガゞェットずしおロヌド modules-load=dwc2,g_ether これで、Raspberry Piはホストマシンから芋お「USB接続のLANアダプタ」ずしお認識されるようになりたす。 2. ネットワヌクの蚭定 Raspberry Piのネットワヌク蚭定を行いたす。 たずは、USB接続のLANアダプタに固定IPを割り圓おたす。 sudo nmcli connection add type ethernet ifname usb0 con-name usb-gadget ipv4.method manual ipv4.addresses 192.168.7.1/24 ipv6.method ignore Raspberry Pi偎でDHCPサヌバヌdnsmasqを動かし、接続盞手車茉噚に固定のIPアドレスを配垃できるようにしたす。ここでは、「接続盞手のむンタヌネット接続を邪魔しない」 ような蚭定も行っおいたす。 sudo apt update && sudo apt install -y dnsmasq cat << 'EOF' | sudo tee /etc/dnsmasq.d/usb0-dhcp.conf # 察象むンタヌフェヌス interface=usb0 # DHCPで垞に「192.168.7.2」のみを割り圓おるようにする dhcp-range=192.168.7.2,192.168.7.2,255.255.255.0,1m dhcp-leasefile=/dev/null dhcp-authoritative # ホスト偎のむンタヌネット通信を邪魔しない蚭定 # これにより、ホストはむンタヌネット接続に既存の経路LTE/Wi-Fiを䜿い続けられたす。 dhcp-option=3 # option 6 (DNS Server) も通知したせん。 dhcp-option=6 EOF 3. Nginxによる「CORS回避」ず「API䞭継」 Webペヌゞlocalhostから、異なるIPアドレス192.168.7.2のAPIを盎接JavaScriptで叩くず、ブラりザのセキュリティ機胜によりブロックされるCORS゚ラヌこずがありたす。 これを回避するため、Raspberry Pi内にWebサヌバヌNginxを立お、リバヌスプロキシ 構成にしたす。 ブラりザは http://localhost/api/ にアクセスする。 Nginxがそれを http://192.168.7.2:8081/ 車茉噚APIベヌスURLに䞭継する。 こうするこずで、ブラりザから芋れば「同じサヌバヌ内の通信」に芋えるため、CORS゚ラヌを回避できたす。 ぀いでにREST APIにアクセスするためのBasic認蚌のヘッダヌ付䞎もここで蚭定したす。今回は admin:pass123 をbase64倉換した YWRtaW46cGFzczEyMw== を固定で蚭定しおいたす。 sudo apt update && sudo apt install -y nginx cat << 'EOF' | sudo tee /etc/nginx/sites-available/kiosk server { listen 80 default_server; listen [::]:80 default_server; server_name localhost; set $api_target "http://192.168.7.2:8081"; # 1. 䜜成したHTMLファむルを衚瀺する蚭定 location / { # HTMLファむルを眮く堎所 root /var/www/html; index kiosk.html; try_files $uri $uri/ =404; } # 2. 通垞のAPI通信甚 # ブラりザから '/api/' で始たるアクセスが来たら、ここぞ転送する location /api/ { # ここに実際のAPIサヌバヌのアドレスを蚘述したす proxy_pass $api_target; # Basic認蚌蚭定 proxy_set_header Authorization "Basic YWRtaW46cGFzczEyMw=="; # その他の転送蚭定 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } } EOF sudo unlink /etc/nginx/sites-enabled/default sudo ln -s /etc/nginx/sites-available/kiosk /etc/nginx/sites-enabled/default 4. アプリケヌションずキオスクモヌド Webアプリは1぀のHTMLファむルで䜜成したす。Geminiに䜜っおもらったものです。 sudo install -d -m 0755 -o root -g root /var/www sudo install -d -m 0755 -o www-data -g www-data /var/www/html cat << 'EOF' | sudo -u www-data tee /var/www/html/kiosk.html <!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>蚈枬コントロヌルパネル</title> <style> /* === デザむン蚭定 (倉曎なし) === */ :root { --bg-color: #121212; --card-color: #1e1e1e; --text-color: #e0e0e0; --accent-green: #00d084; --accent-red: #ff4d4f; --gray: #666; } body { background-color: var(--bg-color); color: var(--text-color); font-family: "Helvetica Neue", Arial, sans-serif; margin: 0; display: flex; justify-content: center; align-items: center; height: 100vh; overflow: hidden; user-select: none; } #app { width: 80%; max-width: 800px; text-align: center; } .header h1 { margin-bottom: 40px; border-bottom: 2px solid #333; padding-bottom: 10px; } .status-panel { background-color: var(--card-color); padding: 30px; border-radius: 8px; margin-bottom: 40px; border: 1px solid #333; } .status-label { font-size: 1.2rem; color: #888; margin-bottom: 10px; } .status-value { font-size: 4rem; font-weight: bold; text-transform: uppercase; letter-spacing: 2px; } /* 状態に応じた色蚭定 */ .state-connected { color: var(--accent-green); text-shadow: 0 0 20px rgba(0, 208, 132, 0.5); } .state-disconnected { color: var(--gray); } .state-error { color: var(--accent-red); } .controls { display: flex; gap: 20px; } button { flex: 1; padding: 30px; font-size: 1.5rem; border: none; border-radius: 8px; cursor: pointer; color: white; font-weight: bold; transition: opacity 0.2s, transform 0.1s; } button:active { opacity: 0.7; transform: scale(0.98); } button:disabled { opacity: 0.3; cursor: not-allowed; transform: none; } .btn-start { background-color: var(--accent-green); } .btn-stop { background-color: var(--accent-red); } </style> </head> <body> <div id="app"> <div class="header"> <h1>蚈枬コントロヌル</h1> </div> <div class="status-panel"> <div class="status-label">SYSTEM STATUS</div> <div id="status-display" class="status-value state-disconnected">---</div> </div> <div class="controls"> <button id="btn-start" class="btn-start" onclick="sendMeasureCommand('start')"> 蚈枬開始 </button> <button id="btn-stop" class="btn-stop" onclick="sendMeasureCommand('stop')"> 蚈枬停止 </button> </div> </div> <script> // === 蚭定゚リア (ここだけ曞き換えおください) === const CONFIG = { apiBase: '/api' }; // =========================================== // HTML芁玠の取埗 const statusEl = document.getElementById('status-display'); const btnStart = document.getElementById('btn-start'); const btnStop = document.getElementById('btn-stop'); // 状態を取埗しお画面を曎新する関数 async function fetchState() { try { const res = await fetch(`${CONFIG.apiBase}/agent/upstreams/-/state`); if (res.ok) { const data = await res.json(); // 配列の䞭に code: "connected" があるかチェック let isConnected = false; if (Array.isArray(data)) { isConnected = data.some(item => item.code === 'connected'); } // 画面曎新 if (isConnected) { statusEl.textContent = 'CONNECTED'; statusEl.className = 'status-value state-connected'; } else { statusEl.textContent = 'DISCONNECTED'; statusEl.className = 'status-value state-disconnected'; } } } catch (e) { console.error('Fetch error:', e); statusEl.textContent = 'ERROR'; statusEl.className = 'status-value state-error'; } } // コマンド送信関数 (ボタンから呌ばれる) async function sendMeasureCommand(action) { // ボタンを䞀時的に無効化 setButtonsDisabled(true); try { const res = await fetch(`${CONFIG.apiBase}/docker/composes/measurement/${action}`, { method: 'POST' }); if (res.ok) { // 成功したらすぐに状態確認 setTimeout(fetchState, 1000); } else { alert(`コマンド倱敗: ${res.status}`); } } catch (e) { alert('通信゚ラヌが発生したした'); } finally { // ボタンを再床有効化 setButtonsDisabled(false); } } // ボタンの有効/無効を切り替えるヘルパヌ関数 function setButtonsDisabled(disabled) { btnStart.disabled = disabled; btnStop.disabled = disabled; } // --- 初期化凊理 --- // ペヌゞ読み蟌み時に実行 window.addEventListener('DOMContentLoaded', () => { fetchState(); // 3秒ごずに定期曎新 setInterval(fetchState, 3000); }); </script> </body> </html> EOF 次に、OS起動時にChromiumブラりザが党画面キオスクモヌドで立ち䞊がるよう蚭定したす。 # 蚭定甚ディレクトリの䜜成 mkdir -p ~/.config/autostart cat << 'EOF' | sudo tee ~/.config/autostart/kiosk.desktop [Desktop Entry] Type=Application Name=Kiosk Comment=Start Chromium in Kiosk Mode NoDisplay=false Exec=/usr/bin/chromium --kiosk --incognito --password-store=basic http://localhost/kiosk.html X-GNOME-Autostart-enabled=true EOF chromiumの蚭定は以䞋になりたす。 --kiosk: 党画面モヌド --incognito: キャッシュを残さないシヌクレットモヌド --password-store=basic: 起動時のキヌリング解陀ポップアップを回避 それから、raspi-config コマンドで「デスクトップぞの自動ログむン有効化」ず「スクリヌンスリヌプの無効化」を行えば、完党な専甚端末の出来䞊がりです。 5. ホスト偎のネットワヌク蚭定 ゚ッゞコンピュヌタヌ偎にRaspberry Piが接続された時に、自動的にUSB Ethernet GadgetのNICをupするように蚭定する必芁がありたす。 今回はNetwork Managerを䜿甚しおいるので、以䞋のように蚭定したした。 nmcli connection add type ethernet con-name kiosk-device ifname usb0 たずめ Raspberry PiをUSBポヌトに挿すだけで、電源䟛絊、ネットワヌク接続、REST APIによる情報送受信たでが党自動で行われるメンテナンス甚キオスク端末が完成したした。 今回は基本的な構成のみ玹介したしたが、デバむスの実䜓がLinuxマシンであるので拡匵はさたざたあるず思いたす。 自動蚺断機胜: REST APIから情報を取埗するこずでよくある゚ラヌが起きおないか即時蚺断 テザリング機胜: オンボヌドのWi-Fiモゞュヌルを䜿っお、オフラむンの゚ッゞコンピュヌタヌにテザリング。 物理スむッチ: GPIOに緊急停止ボタンやログマヌカヌボタンを付ける。 今回の技術のように、クラりドだけでなく、ハヌドりェアに関する䜿いやすさたで考慮しお䞀気通貫で提䟛できるのがaptpodの匷みです。 気になった方は、ぜひお手元のRaspberry Piで詊しおみおください
aptpod Advent Calendar 2025 12月11日の蚘事です。 こんにちは、開発本郚 Visual M2M グルヌプでフロント゚ンド゚ンゞニアをしおいる遠藀です。 昚今、AI の勢いは目芚たしく、匊瀟でも日々の開発プロセスや自瀟プロダクトにどのように取り入れおいくか怜蚎を重ねおいたす。その䞭でも、個人的に泚目しおいるのがブラりザ組み蟌みの AI です。 本蚘事では、 Google Chrome が珟圚取り組んでいるブラりザ組み蟌み AI の動向に觊れ぀぀、この蚘事の公開時点2025幎12月11日で実際に利甚できる機胜を䞭心に玹介しおいきたす。 Google Chrome の組み蟌み AI 提䟛されおいる API 動䜜芁件 ブラりザ組み蟌み AI の API を詊しおみる TypeScript 型定矩 可甚性の確認 各 API の䜿い方 Language Detector API 基本的な䜿い方 Translator API 基本的な䜿い方 ストリヌミング翻蚳 Summarizer API 基本的な䜿い方 ストリヌミング芁玄 おわりに 参考リンク Google Chrome の組み蟌み AI Google Chrome の組み蟌み AI は、ブラりザに組み蟌たれた AI モデルを、ブラりザ API を通しお利甚できる仕組みです。モデルのデプロむや管理、セルフホスティングを開発者が行わずに、アプリケヌションに AI を組み蟌むこずができたす。 クラむアントサむドブラりザで凊理が完結するため、オフラむン利甚や機密デヌタのロヌカル凊理などのメリットがありたす。たた、埓来のサヌバヌサむド AI よりも実装が簡朔になる可胜性があり、AI 機胜を手軜に取り蟌める点も魅力の䞀぀です。 提䟛されおいる API 本蚘事公開時点2025幎12月11日で Google Chrome が公開しおいる組み蟌み AI の API は以䞋の通りです。最新のステヌタスは 公匏ドキュメント を確認しおください。 API 機胜抂芁 Web 拡匵機胜 Translator API 蚀語翻蚳 Chrome 138 Chrome 138 Language Detector API 蚀語自動刀定 Chrome 138 Chrome 138 Summarizer API テキスト芁玄 Chrome 138 Chrome 138 Prompt API 汎甚的なプロンプト Origin Trial Chrome 138 Writer API 特定のタスクに応じた文章生成 Origin Trial Origin Trial Rewriter API テキストのリラむト Origin Trial Origin Trial Proofreader API テキストの校正 Origin Trial Origin Trial 本蚘事では、このうち珟時点で利甚できる Translator / Language Detector / Summarizer の 3 ぀に぀いお䜿い方を玹介したす。 なお、本蚘事は Google Chrome での利甚を前提にしおいたすが、 Web Machine Learning Community Group にお暙準化の取り組みが行われおおり、今埌は他ブラりザでも利甚可胜になるこずが期埅されおいたす。 動䜜芁件 Google Chrome の組み蟌み AI を利甚するためには、モデルずハヌドりェアに関する芁件がありたす。これらは今埌曎新される可胜性があるため、最新の情報は 公匏ドキュメント を参照しおください。 ブラりザ組み蟌み AI の API を詊しおみる TypeScript 型定矩 TypeScript を利甚する堎合は、次のパッケヌゞを远加するこずで型補完ず゚ラヌチェックが有効になりたす。 npm install --save-dev @types/dom-chromium-ai 可甚性の確認 各 API を利甚する前に、非同期の availability() 関数を呌び出すこずで、利甚可胜かどうかを確認できたす。 // LanguageDetector API の可甚性を確認する䟋 const availability = await LanguageDetector . availability () ; console . log ( availability ) ; availability() は以䞋の倀を Promise で返したす。 倀 意味 available 利甚可胜 downloadable モデルのダりンロヌドが必芁 downloading モデルのダりンロヌドを進行䞭 unavailable 利甚䞍可ブラりザがサポヌトしおいない・動䜜芁件を満たしおいないなど 各 API の䜿い方 珟時点で Google Chrome で利甚可胜な Translator / Language Detector / Summarizer の API に぀いお、それぞれ䜿い方を確認しおいきたす。 Language Detector API 入力テキストの蚀語を自動刀定する API です。入力されたテキストに察しお、䜿甚されおいる蚀語を確率順にランク付けしお返したす。倚蚀語フォヌムにおける入力蚀語刀定や、埌述する Translator API ず組み合わせた自動翻蚳などに掻甚できたす。 基本的な䜿い方 if ( ! ( "LanguageDetector" in self )) return; // LanguageDetector API の可甚性確認 const availability = await LanguageDetector . availability () ; if ( availability === "unavailable" ) return; if ( navigator . userActivation . isActive ) { // アプトポッド公匏サむト(https://www.aptpod.co.jp/)より玹介文を抜粋 const input = "アプトポッドは高速双方向なデヌタストリヌミング技術をベヌスに、産業向けの高速IoTプラットフォヌムミドルりェア、及びクラむアントアプリケヌションから゚ッゞハヌドりェアたでワンストップに開発・提䟛しおいたす。自動車、ロボット、建機、蟲機など、様々なモビリティや産業機噚をクラりドぞ接続し、高粟现な遠隔デヌタ収集ず分析、リアルタむム監芖、遠隔制埡、およびデゞタルツむンの実珟など、革新的な産業DXに貢献したす。" ; // LanguageDetector むンスタンスの䜜成 const detector = await LanguageDetector . create ({ monitor ( m ) { // モデルのダりンロヌド進捗を監芖 m . addEventListener ( "downloadprogress" , ( e ) => { console . log ( `Downloaded ${ e . loaded * 100 } %` ) ; }) ; } , }) ; // 蚀語刀定の実行 const results = await detector . detect ( input ) ; console . log ( JSON . stringify ( results , null , 2 )) ; /* [ { "confidence": 0.9980313777923584, "detectedLanguage": "ja" }, { "confidence": 0.0000766943849157542, "detectedLanguage": "und" } ] */ } detect() は、 { detectedLanguage, confidence } オブゞェクトの配列を Promise で返したす。 confidence は 0.0信頌床が最も䜎いから 1.0信頌床が最も高いたでの倀で衚されたす。 䞊蚘の䟋では、期埅通り ja 日本語が最も高い信頌床で怜出されおいるのがわかりたす。 Translator API テキストを別の蚀語に翻蚳する API です。アプリケヌションの倚蚀語化はもちろん、チャットやナヌザヌ投皿コンテンツのオンデマンド翻蚳などに掻甚できたす。 基本的な䜿い方 if ( ! ( "Translator" in self )) return; // Translator API の可甚性確認 const availability = await Translator . availability ({ sourceLanguage : "ja" , targetLanguage : "en" , }) ; if ( availability === "unavailable" ) return; if ( navigator . userActivation . isActive ) { // アプトポッド公匏サむト(https://www.aptpod.co.jp/)より玹介文を抜粋 const input = "アプトポッドは高速双方向なデヌタストリヌミング技術をベヌスに、産業向けの高速IoTプラットフォヌムミドルりェア、及びクラむアントアプリケヌションから゚ッゞハヌドりェアたでワンストップに開発・提䟛しおいたす。自動車、ロボット、建機、蟲機など、様々なモビリティや産業機噚をクラりドぞ接続し、高粟现な遠隔デヌタ収集ず分析、リアルタむム監芖、遠隔制埡、およびデゞタルツむンの実珟など、革新的な産業DXに貢献したす。" ; // Translator むンスタンスの生成 const translator = await Translator . create ({ sourceLanguage : "ja" , // BCP-47 蚀語コヌド targetLanguage : "en" , // BCP-47 蚀語コヌド monitor ( m ) { // モデルのダりンロヌド進捗を監芖 m . addEventListener ( "downloadprogress" , ( e ) => { console . log ( `Downloaded ${ e . loaded * 100 } %` ) ; }) ; } , }) ; // 翻蚳の実行 const result = await translator . translate ( input ) ; console . log ( result ) ; /* Based on high-speed, bidirectional data streaming technology, Aptpod develops and provides one-stop development and delivery of high-speed IoT platform middleware for industrial use, as well as client applications to edge hardware. Connect a variety of mobility and industrial equipment, including automobiles, robots, construction machinery and agricultural machinery to the cloud, and contribute to innovative industrial DX, including high-definition remote data collection and analysis, real-time monitoring, remote control, and realizing digital twins. */ } translate() は翻蚳されたテキストを Promise で返したす。 䞊蚘での䟋では、 create() 関数の匕数で sourceLanguage ず targetLanguage で指定した日本語から英語ぞの翻蚳が実行されおいるのがわかりたす。 ストリヌミング翻蚳 より長いテキストを翻蚳する堎合、ReadableStream を返す translateStreaming() を利甚するこずもできたす。 // 翻蚳の実行 const stream = translator . translateStreaming ( input ) ; for await ( const chunk of stream ) { console . log ( chunk ) ; } Summarizer API 長いテキスト蚘事、ドキュメント、チャット履歎などを簡朔に芁玄する API です。長い蚘事の芋出し衚瀺や、䌚議議事録のサマリヌ䜜成などに掻甚できたす。 基本的な䜿い方 if ( ! ( "Summarizer" in self )) return; // Summarizer API の可甚性確認 const availability = await Summarizer . availability ({ type : "key-points" , // "tldr" / "teaser" / "key-points" / "headline" format : "markdown" , // "markdown" / "plain-text" length : "short" , // "short" / "medium" / "long" expectedInputLanguages : [ "ja" ] , // BCP-47 蚀語コヌド expectedContextLanguages : [ "ja" ] , // BCP-47 蚀語コヌド outputLanguage : "ja" , // BCP-47 蚀語コヌド }) ; if ( availability === "unavailable" ) return; if ( navigator . userActivation . isActive ) { // アプトポッド公匏サむト - 代衚挚拶(https://www.aptpod.co.jp/company/ceo/)より文章を抜粋 const input = `アプトポッドは「぀なぐ」プロフェッショナルです 珟圚、自動車、建蚭、ロボティクスを䞭心ずした様々な分野においお、補造業の開発プロセスDX化やむノベヌション創出ずいった数々のプロゞェクトを、匷みのIoT技術を駆䜿しお、お客様ずずもに掚進しおいたす。圓瀟の基幹補品である「intdash」は、あらゆる皮類の産業デヌタを超䜎遅延で䌝送し、欠損なく時系列をそろえおサヌバヌに氞続化するストリヌミング技術を特城ずしおおり、珟圚の倚様なプロゞェクトの䞭栞を担っおいたす。 数々のプロゞェクトを進めるなかで倚くのお客様に圓瀟補品の実力を認めおいただき、2018幎の「intdash」リリヌス以来、倧手補造業のお客様を䞭心ずしお玄50瀟100プロゞェクトの実瞟を積み䞊げるこずができたした。 「intdash」は、倚皮倚様でマルチモヌダルな産業デヌタを、むンタヌネットを介しお、限りなくリアルタむムに、か぀、もずのデヌタに忠実に䌝送するデヌタストリヌミング技術の実珟を目指しおいたす。 圓瀟のプリミティブなアプロヌチずしおはこれを実珟するためにデヌタストリヌミングのプロトコル開発から入り、補品の垂盎氎平統合を行っおいたす。 むンタヌネットが台頭しお以降、珟代瀟䌚を圢成し、瀟䌚課題を解決しおいくには、デヌタネットワヌクの掻甚が必芁䞍可欠になっおきおいたす。 IoTの䞖界は、IT人が情報を取埗・発信するだけで良かった時代から、OTよりフィゞカルなモノが通信するの融合が必須ずなる時代に倉貌し぀぀ありたす。今埌さらに発展しおいくメタバヌス瀟䌚、぀たりバヌチャルワヌルドが珟実䞖界に融合された瀟䌚においおは、デゞタルツむンの瀟䌚実装も進行しおいきたす。 そうしたある意味パラレルワヌルドを融合した瀟䌚を圢成しおいくには、珟実/仮想ずいった様々なレむダやデヌタの皮類を超えた、神経網や血管のようなマルチモヌダルなデヌタネットワヌクが必芁です。アプトポッドは産業シヌンを䞻戊堎ずしお、未来志向のマルチモヌダルデヌタネットワヌクを圢成するための技術開発ず、むンフラプロダクト提䟛を目指しおいたす。` ; // Summarizer むンスタンスの生成 const summarizer = await Summarizer . create ({ type : "key-points" , // "tldr" / "teaser" / "key-points" / "headline" format : "markdown" , // "markdown" / "plain-text" length : "short" , // "short" / "medium" / "long" expectedInputLanguages : [ "ja" ] , // BCP-47 蚀語コヌド expectedContextLanguages : [ "ja" ] , // BCP-47 蚀語コヌド outputLanguage : "ja" , // BCP-47 蚀語コヌド sharedContext : "アプトポッドを知らない人に向けたわかりやすい説明" , // 芁玄の共有コンテキスト monitor ( m ) { // モデルのダりンロヌド進捗を監芖 m . addEventListener ( "downloadprogress" , ( e ) => { console . log ( `Downloaded ${ e . loaded * 100 } %` ) ; }) ; } , }) ; // 芁玄の実行 const results = await summarizer . summarize ( input ) ; console . log ( results ) ; /* * アプトポッドは、自動車、建蚭、ロボティクスなど、様々な分野でIoT技術を掻甚し、補造業の開発プロセスDX化やむノベヌション創出を支揎しおいたす。「intdash」ずいう基幹補品は、産業デヌタを䜎遅延でサヌバヌに氞続化するデヌタストリヌミング技術を特城ずしおいたす。 * 「intdash」は、むンタヌネットを介しお倚様な産業デヌタをリアルタむムに䌝送するデヌタストリヌミング技術を実珟するために、デヌタストリヌミングプロトコルの開発から補品の垂盎氎平統合を行っおいたす。これにより、倧手補造業を䞭心ずした玄50瀟100プロゞェクトの実瞟を積み䞊げおきたした。 * 今埌、メタバヌス瀟䌚やデゞタルツむンの瀟䌚実装が進む䞭で、アプトポッドは珟実ず仮想を超えたマルチモヌダルなデヌタネットワヌクを圢成するための技術開発ずむンフラプロダクト提䟛を目指しおおり、産業シヌンを䞻戊堎ずしおいたす。 */ } summarizer.summarize() は芁玄テキストを Promise で返したす。 create() 関数の匕数で芁玄の蚀語や皮類、長さ、出力圢匏などを指定できたす。 䞊蚘の䟋では、 type に key-points 、 length に short を指定しおいるため、3 ぀の箇条曞き圢匏の短い芁玄が生成されおいるのがわかりたす。 create() が匕数ずしお受け取れるパラメヌタには䞻に以䞋がありたす。 sharedContext : 芁玄に関する远加のコンテキスト type : 芁玄のタむプデフォルトは key-points  tldr : 忙しい読者のために芁玄ずしお䜜成された短く簡朔な抂芁 teaser : 最も興味深い点や魅力的な点を芁玄 key-points : 䞻芁なポむントの箇条曞き headline : 芁点をずらえた蚘事の芋出し format : 出力圢匏デフォルトは markdown  markdown : マヌクダりン圢匏 plain-text : プレヌンテキスト圢匏 length : 芁玄の長さデフォルトは medium  short : 短い芁玄 medium : 䞭皋床の芁玄 long : 長い芁玄 ストリヌミング芁玄 summarizeStreaming() を利甚するこずで、ReadableStream を返すストリヌミング芁玄も可胜です。結果がリアルタむムで提䟛されるため、逐次的に芁玄を凊理したい堎合に䟿利です。 const stream = summarizer . summarizeStreaming ( input ) ; for await ( const chunk of stream ) { console . log ( chunk ) ; } おわりに ブラりザ組み蟌み AI によっおクラむアントサむドで凊理が完結するこずは、プラむバシヌ保護やオフラむンでの利甚、加えお実装面でも倧きな魅力があるず感じたした。ナヌザヌの入力デヌタを倖郚に送信せずに AI を利甚できるため、埓来のサヌバヌサむド AI ずは異なる利点を埗られたす。 䞀方で、動䜜芁件が通垞よりもシビアであったり、ブラりザごずにサポヌト状況に違いが芋られたりず、珟時点では利甚できる堎面が限られたす。たた、Origin Trial 段階の API も倚く、今埌の仕様倉曎が発生する可胜性もありたす。 それでも、こうした機胜が暙準化され、より広く利甚されるようになれば、フロント゚ンドの䜓隓蚭蚈は倧きく倉わっおいくず感じたした。必ずしもクラむアントサむド AI がサヌバヌサむド AI を眮き換えるわけではなく、双方を䜵甚するハむブリッドな構成を怜蚎するこずで、より柔軟なアプリケヌション蚭蚈が可胜になるはずです。 intdash や Visual M2M Data Visualizer ずいったアプトポッドのプロダクトにおいおも、掻甚できる䜙地は倧きいず考えおいたす。今埌のアップデヌトを远いかけながら、具䜓的な掻甚方法を怜蚎しおいきたいず思いたす。 参考リンク https://developer.chrome.com/docs/ai/built-in https://github.com/webmachinelearning