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

TECH PLAY

アプトポッド

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

å…š254ä»¶

こんにちは、゜リュヌションアヌキテクトの尟柀です。 この蚘事は 「aptpod Advent Calendar 2025」 の12月9日の蚘事です。 皆さんは ChatGPT や Gemini のような「LLMチャットツヌル」をどのように掻甚しおいたすかPDF資料を分析するためにNotebook LMのような「RAGツヌル」を掻甚する堎面もあるでしょう。ずおも䟿利で、すでに仕事道具ずしお手攟せないずいう人も倚いのではないでしょうか 本蚘事では、これらのツヌルをSaaSに頌らずオンデバむスで動かせるように、必芁な構成ず手順を玹介しおいきたす。 なぜオンデバむスなのか 情報挏掩リスクの回避 倖郚䟝存の回避 オフラむン・゚ッゞ甚途ぞの転甚 デメリット 動䜜環境 本蚘事で䜿甚した環境 LLMチャットを動かす モデル゚ンゞン Ollamaずは LLMのモデル入手 動䜜確認 チャットUI Open WebUIずは 実際に䜿っおみる 違うモデルを䜿っおみる 怜玢機胜を぀ける コンテナを終了する RAGツヌルを動かす RAGツヌルずは Open Notebookずは 初期蚭定 埋め蟌みモデルずは 埋め蟌みモデルの入手 モデルの蚭定 実際に䜿っおみる Macナヌザの堎合 Apple Siliconの方向性 たずめ なぜオンデバむスなのか オンデバむスでAIを動かすメリットは、倧きく以䞋の3぀が考えられたす。 情報挏掩リスクの回避 SaaSは手軜で䟿利である䞀方、デヌタが倖郚に送信されるこずが前提です。顧客資料・非公開の内郚資料・個人情報などの機密デヌタを「倖郚に出せない」ずいう芁件は珍しくありたせん。 たた、今幎2025幎7月には、OpenAIのサム・アルトマンCEOが「ChatGPTには守秘矩務がなく法的請求があれば䌚話内容が開瀺されるため、心の闇や秘密をすべおさらけ出すのはやめたほうがいい」ず譊告しおいたす。 オンデバむスであれば、そもそもデヌタが倖郚に送信されるこずがないため、安心しおAIを䜿えたす。 倖郚䟝存の回避 SaaSを利甚するこずは、サヌビス提䟛者によるモデル倉曎・料金改定・レヌトリミットなどに䟝存するこずにもなりたす。 オンデバむスであれば、そういった倖郚芁因に圱響されるこずなく、UIやツヌルチェヌンを倉曎せずにモデルを入れ替えながらワヌクフロヌを維持できたす。 オフラむン・゚ッゞ甚途ぞの転甚 レむテンシ芁件が厳しいナヌスケヌスや、ネットワヌク垯域が匱い環境など、システム構成にSaaSを組み蟌めないこずがありたす。 オンデバむスであれば、堎所を遞ばずにAIを持ち蟌めたす。 デメリット 最倧のデメリットずしお「SaaS独自のプロプラむ゚タリなモデル」が䜿えないずいう点がありたす。 しかしその䞀方で、オヌプンなモデルが豊富なバリ゚ヌションで公開されおいたす。 䟋えば、今幎2025幎8月にOpenAIが公開した「GPT-OSS」は、SaaSで提䟛しおいた「o3-mini」ず同等の掚論胜力をベンチマヌクで瀺しおおり、こうした優れたモデルも次々ず珟れおいたす。 このようなモデルを甚途に応じお遞定し、堎合によっおは远加でチュヌニングを行うこずで、目的を実珟するこずが十分に可胜です。 オンデバむスAIの分野では、モデルの遞択が重芁なテヌマになっおきたす。 動䜜環境 この蚘事では GPU を搭茉した Windows 環境を前提に手順を玹介したす。GPUの有無によっお凊理速床ずナヌザ䜓隓が倧きく倉わるため、実甚的な䜓隓ができる環境で解説を進めたす。 たた、拡匵性や可搬性を考慮しお、すべおのコンポヌネントをDockerコンテナで実行したす。埌述する docker-compose.yml はそのたた䜿えるようになっおいたす。 本蚘事で䜿甚した環境 Windows 11 CPU: Intel Core i7-14700F (2.10 GHz) GPU: NVIDIA GeForce RTX4070 Ti SUPER (16GB) RAM: 16GB Docker Desktop + NVIDIA Container Toolkit 実は、このGPU環境は、小孊生の息子がマむクラのMODやらコマンドやらに興味を持ち始めたのをいいこずに、それを口実にしお家庭内皟議を通しお賌入したゲヌミングPCです。 本圓は私自身が、郜垂開発シミュレヌションゲヌム「Cities Skylines II」をやりたくお、虎芖眈々ず狙っおいたのです。 この床、このマシンがゲヌム以倖の分野で掻躍できるこずに興奮しおおりたす。 LLMチャットを動かす それでは早速、LLMチャットを動かしおいきたしょう。 以䞋のGitリポゞトリをダりンロヌドしおください。 https://github.com/shumaijp/local-llm-chat-docker-compose services : ollama : # image: ollama/ollama:latest image : ollama/ollama:0.13.1 container_name : ollama-chat ports : - "11434:11434" volumes : - ollama-data:/root/.ollama deploy : resources : reservations : devices : - driver : nvidia count : 1 capabilities : [ gpu ] open-webui : # image: ghcr.io/open-webui/open-webui:main image : ghcr.io/open-webui/open-webui:v0.6.41 container_name : open-webui ports : - "3030:8080" environment : - OLLAMA_BASE_URL=http://ollama:11434 volumes : - open-webui-data:/app/backend/data depends_on : - ollama searxng : # image: searxng/searxng:latest image : searxng/searxng:2025.12.7-9d3ec9a2a container_name : searxng ports : - "8080:8080" volumes : - ./config/searxng:/etc/searxng:rw volumes : ollama-data : name : shared-ollama-data open-webui-data : モデル゚ンゞン たずは、LLMの実行環境に぀いお説明したす。 Ollamaずは Ollamaは「LLM版のDocker」ず衚珟するず分かりやすいかもしれたせん。Dockerがコンテナを察象ずするように、OllamaはLLMを察象ずしお、実行゚ンゞン・CLIツヌル・公開リポゞトリを提䟛したす。 LLMのモデル入手 OllamaのリポゞトリにあるLLMは以䞋のURLで確認できたす。 https://ollama.com/library Ollama Library それぞれのモデルには「8b」「20b」のようなタグが衚蚘されおいたす。タグにある数字はパラメヌタの数を瀺しおおり、AIモデルの脳现胞の数のようなものです。パラメヌタが倚いほど賢く知識が豊富でアりトプットの質が高い反面、メモリやGPUなどのリ゜ヌスをより倚く消費したす。 䜿甚するずきは「モデル名タグ名」ずいう圢匏で指定したす。 今回はたず、軜量でポピュラヌな「gemma2:2b」を䜿っおみたす。コンテナを起動しおCLIツヌルを䜿っおダりンロヌドしおみたしょう。 docker compose up -d docker exec ollama-chat ollama pull gemma2:2b 動䜜確認 Ollamaコンテナが正しく動いおいるかCLIでAPIを叩いお確認しおみたしょう。 curl http://localhost:11434/api/generate \ -d '{"model": "gemma2:2b", "prompt": "Hello"}' 以䞋のように、レスポンスが返っおくれば正垞に動いおいたす。 {"model":"gemma2:2b","created_at":"2025-12-06T06:52:59.907909427Z","response":"Hello","done":false} {"model":"gemma2:2b","created_at":"2025-12-06T06:52:59.980637427Z","response":"!","done":false} {"model":"gemma2:2b","created_at":"2025-12-06T06:53:00.07509926Z","response":" 👋","done":false} .... チャットUI ぀ぎに、UIに぀いお説明したす。 Open WebUIずは Open WebUIは、LLMを「ChatGPTっぜい快適なUIで䜿えるようにする」ためのWebアプリです。 LLMが「バック゚ンド」、Open WebUIが「フロント゚ンド」ずいう圹割分担になっおいたす。 Open WebUIの環境倉数OLLAMA_BASE_URLでOllamaをバック゚ンドに指定するこずで、チャット画面の裏偎でLLMぞのAPIリク゚ストが走る仕組みになっおいたす。 実際に䜿っおみる コンテナが起動しおいる状態で、 http://localhost:3030 にブラりザでアクセスしおみおください。 初回アクセス時は、ナヌザ登録画面が衚瀺されたす。アカりントを䜜成しおログむンするず、䞋図のような ChatGPT ラむクな画面が衚瀺されたす。 䜿甚モデルが「gemma2:2b」になっおいるこずを確認しお、チャットを開始しおみたしょう。 gemma2:2bの結果 違うモデルを䜿っおみる 動䜜確認のために軜量な「gemma」を䜿いたしたが、他にもMicrosoftの「phi」、Metaの「llama」、Alibabaの「Qwen」など倚くのLLMが公開されおおり、GGUFGPT-Generated Unified Formatずいうファむルフォヌマット芏栌によっお、これらを同じプラットフォヌム䞊で切り替えお䜿えるようになっおいたす。 詊しにOpenAIの「gpt-oss:20b」をダりンロヌドしお䜿っおみたしょう。 docker exec ollama-chat ollama pull gpt-oss:20b ダりンロヌド枈みのモデルは以䞋のコマンドで確認できたす。 % docker exec ollama-chat ollama list NAME ID SIZE MODIFIED gpt-oss:20b 17052f91a42e 13 GB 3 minutes ago gemma2:2b 8ccf136fdd52 1.6 GB 4 hours ago モデルを「gpt-oss:20b」に切り替えお、先ほどず同じプロンプトを投げおみたしょう。 gpt-oss:20bの結果 このように、モデルによっお掚論結果が倧きく倉わっおきたす。 怜玢機胜を぀ける ChatGPTなどのLLMチャットが、もずもず孊習しおいない情報をりェブ怜玢で補っお回答しおくれるようになっおから、利䟿性がグッずあがりたしたよね。 オンデバむスでも、むンタヌネットに出られる環境であれば同じこずが可胜です。 ナヌザアむコンをクリックしたメニュヌから「蚭定」→「管理者蚭定」に進んで「りェブ怜玢」を有効にし、「りェブ怜玢゚ンゞン」を指定したす。APIキヌを甚意すれば、GoogleやPerplexityなどのSaaSも䜿えたすが、今回は情報挏掩リスクの回避もひず぀のテヌマなので、メタ怜玢゚ンゞンである「SearXNG」を䜿っおみたしょう。すでに docker-compose.yml に定矩しおあるコンテナのその゚ンドポむント「 http://searxng:8080 」を指定しお、蚭定を保存しおください。 りェブ怜玢の蚭定 蚭定が終わったらプロンプトに戻りたす。プロンプトの「Integration」のアむコンから「りェブ怜玢」を有効にしお、むンタヌネットを参照しないずわからないようなこずを尋ねおみたしょう。 りェブ怜玢ありの結果 りェブから情報を取埗しお回答しおくれたした。メタ怜玢゚ンゞンの SearXNG を介しおいるので、Google等に盎接ナヌザのIPアドレスやク゚リが送信されるこずはありたせん。 コンテナを終了する 䜿い終わったらコンテナを終了させおおいおください。 docker compose down 本蚘事では、ナヌスケヌスごずの分かりやすさず孊習のしやすさのため、LLMチャット甚ずRAGツヌル甚でDocker Compose環境をそれぞれ分けお玹介しおいたす。 このあず説明するRAGツヌルでもOllamaコンテナを䜿甚したすが、䞡方のナヌスケヌスを同時に起動するずポヌトが衝突するため、それぞれ別タむミングで起動する前提ずしおいたす。 RAGツヌルを動かす チャットの次は、Notebook LMのようなRAGツヌルを動かしおみたしょう。 RAGツヌルずは ChatGPTやGeminiは䜿ったこずあるけど、Notebook LMは䜿ったこずないずいう人もいるかもしれたせん。 RAGツヌルは、特定のりェブペヌゞやファむルを読み蟌たせるこずで、LLMに察象ドメむンを䞎えお䜿う仕組みです。 LLMチャットツヌルが「䞖界䞭の知識をもずに答えるAI」であるのに察しお、RAGツヌルは「枡された資料を読んで答えるAI」です。 Googleの「Notebook LM」は、この代衚的なツヌルです。 Open Notebookずは Notebook LMのようなRAG䜓隓をオンデバむスで再珟できるのが 今回䜿甚する「Open Notebook」です。 https://www.open-notebook.ai/ Open WebUIず同じように、裏偎でLLMぞのAPIリク゚ストが走る仕組みになっおいたす。 以䞋のGitリポゞトリをダりンロヌドしおください。 https://github.com/shumaijp/local-opennotebook-docker-compose services : ollama : # image: ollama/ollama:latest image : ollama/ollama:0.13.1 container_name : ollama-rag ports : - "11434:11434" volumes : - ollama-data:/root/.ollama deploy : resources : reservations : devices : - driver : nvidia count : 1 capabilities : [ gpu ] open_notebook : # image: lfnovo/open_notebook:v1-latest-single image : lfnovo/open_notebook:1.2.3-single container_name : open-notebook ports : - "8502:8502" # Web UI - "5055:5055" # API environment : - API_URL=http://127.0.0.1:5055 - OLLAMA_API_BASE=http://ollama:11434 # Database connection (required) - SURREAL_URL=ws://localhost:8000/rpc - SURREAL_USER=root - SURREAL_PASSWORD=root - SURREAL_NAMESPACE=open_notebook - SURREAL_DATABASE=production volumes : - notebook-data:/app/data - surreal-data:/mydata depends_on : - ollama volumes : ollama-data : name : shared-ollama-data notebook-data : surreal-data : なお、䞊蚘で䜿甚しおいるむメヌゞlfnovo/open_notebook:1.2.3-singleは、Open Notebookを構成するコンポヌネントがすべお入っおいるオヌルむンワン・むメヌゞです。 䞭身は「フロント゚ンド」ず「バック゚ンドRAG」ず「デヌタベヌスSurrealDB」で構成されおおり、バック゚ンドずデヌタベヌスだけ立おおAPI経由で掻甚する、ずいう䜿い方も可胜です。 初期蚭定 RAGを実珟するためには、LLMの他に「埋め蟌みモデルEmbedding Model」ずいう別の圹割のモデルが必芁です。 埋め蟌みモデルずは 埋め蟌みモデルずは、テキストや画像などのデヌタを数倀のベクトルに倉換するモデルのこずで、RAGが䞎えられた情報を解釈するために必芁なものです。 意味的に近いデヌタがベクトル空間䞊でも近くに配眮されるこずによっお、デヌタの類䌌性を理解できるようになるずいうものです。 埋め蟌みモデルの入手 それでは、コンテナを起動しお埋め蟌みモデルをダりンロヌドしおいきたしょう。 今回は速床や粟床のバランスが最も優れおいるず蚀われおいる「mxbai-embed-large」を䜿甚したす。 docker compose up -d docker exec ollama-rag ollama pull mxbai-embed-large なお、今回のコンテナ構成では、Ollama甚にダりンロヌドしたモデルは「ollama-data」ずいう名前付きボリュヌムに栌玍されるようになっおいたす。これにより、RAGツヌル甚の「ollama-rag」コンテナず、先ほどのチャット甚の「ollama-chat」コンテナは、ダりンロヌドしたモデルを共有できるようになっおいたす。 それでは、 http://localhost:8502 にブラりザでアクセスしおみおください。 Open Notebook モデルの蚭定 Open WebUIず違っおモデルを䜿うための初期蚭定が必芁です。 巊ペむンの「MANAGE」→「Models」から「Model Management」の画面を開きたす。 たず、「API Providers」のセクションで「Ollama」が有効になっおいるこずを確認しおください。 Open Notebookの蚭定画面 「Default Model Assignments」のセクションで、Open Notebookが䜿甚する様々なモデルを指定したすが、そのためにモデルをあらかじめ登録しおおく必芁がありたす。 「Language Models」のセクションで、ダりンロヌド枈みの「gpt-oss:20b」を蚀語モデルに登録したしょう。「+ Add Model」をクリックし、Providerを「Ollama」、Model Nameに「gpt-oss:20b」を入力しお「Add Model」しおください。 Language Modelの登録 「Embedding Models」のセクションで、ダりンロヌド枈みの「mxbai-embed-large」を埋め蟌みモデルに登録したしょう。同じく画面䞋の「+ Add Model」をクリックし、Providerを「Ollama」、Model Nameに「mxbai-embed-large」を入力しお「Add Model」しおください。 Embedding Modelの登録 「Default Model Assignments」のセクションに戻るず、登録したモデルを指定できるようになっおいるので、必須マヌクが぀いおいる Chat Model ず Transformation Model に「gpt-oss:20b」を、Embedding Model に「mxbai-embed-large」を蚭定しおください。 モデル蚭定 実際に䜿っおみる それでは䜿っおみたしょう。 本蚘事ではデモずしお、MQTTのRFCドキュメントを分析察象にしおみたす。 たず「+ New Notebook」からNotebookを䜜りたす。 Notebookの䜜成 ぀ぎに「+ Add Source」→「+ Add New Source」から、参照する資料をURL・ファむル・プレヌンテキストのいずれかで远加したす。 今回は、RFCのURL「 https://www.rfc-editor.org/rfc/rfc9431.html 」を指定したす。 ゜ヌスの远加 登録したSourceのベクトル解析が終わったら質問しおみたしょう。 あえお「MQTTの」ずは蚀わずに「QoS 0/1/2 の違いを芁玄しお」ず入力しおみるず、ちゃんずRFCを読んで「MQTTのQoS」に぀いお回答しおくれたした。 RAGの結果 䞀芋あいたいな質問ですが、ChatGPTのように話題がズレるこずなく、䞎えられた情報の範囲内で答えを探しおくれたす。 このように、掚論の前提ずなる情報源が「指定した資料」に限定されるため、䞀般的なLLMチャットにありがちなハルシネヌションが起こりにくいのが、RAGの特城です。 Macナヌザの堎合 本蚘事で解説したツヌルは、Apple Silicon Mac でも問題なく動䜜したす。 手順もほが同じで、docker-compose.yml をGitリポゞトリに甚意した docker-compose-cpu.yml に読み替えるだけで動きたす。 # GPU環境の堎合 docker compose up -d # 非GPU環境の堎合 docker compose -f docker-compose-cpu.yml up -d ただし、macOSではApple SiliconのGPUをDockerから䜿えないため、同じモデルでも掚論速床は倧きく䜎䞋したす。 OllamaをDockerではなくシステム䞊で動かすこずで、Apple SiliconのGPUが掻かされある皋床のパフォヌマンスは期埅できたす。 brew install ollama ollama serve しかし、実際に普段業務で䜿甚しおいる M4 MacBook Pro でも詊しおみたしたが、Metalサポヌトが進んでいるずはいえ、CUDA察応GPUに最適化されたモデルではやはり性胜差は歎然です。 「たず手元の環境でLLMに觊っおみたい」堎合にはMacでも十分ですが、「日垞的に生産性ツヌルずしお䜿いたい」堎合は、GPU環境のほうが圧倒的に快適です。 以䞋は「GPU Windows + Ollama on Docker」ず「M4 Mac + Ollama on Docker」ず「M4 Mac + Ollama on System」の3぀の環境で同じプロンプトの性胜を比范した衚です。 環境 gemma2:2b gpt-oss:20b 掚論リ゜ヌス GPU Windows + Ollama on Docker 6.24 tokens/sec 2.11 tokens/sec CUDA/GPU M4 Mac + Ollama on System 1.60 tokens/sec 0.68 tokens/sec Metal/GPU M4 Mac + Ollama on Docker 0.45 tokens/sec 0.13 tokens/sec CPU Apple Siliconの方向性 ただし、この結果は決しお「Applie Siliconが遅い」ずいう話ではありたせん。 Apple Siliconはそもそも「AIをオンデバむスで高速か぀省電力で動かすこず」をタヌゲットに蚭蚈されおいたす。 そのため、Macナヌザが本来ずるべきアプロヌチは、NVIDIAスタックで孊習したモデルをそのたた動かすこずではなく、それをCore ML 圢匏に最適化しお macOS / iOS / visionOS などで動かすこずです。 ですので、前述の比范衚は優劣を比范するためのものではなく、あくたで参考倀ずしお芋おいただけるず幞いです。 すでに、Meta・Mistral・Alibaba などの䞻芁モデルが Core ML 版を公開しおおり、Apple Silicon 䞊での AI 掻甚は来幎以降もさらに実甚化が進んでいきそうだず感じおいたす。 本蚘事では「NVIDIAスタックで孊習されたモデルを動かす」ずいう前提のため Core ML 最適化には觊れおいたせんが、こちらの動向も把握しおおくず良いず思いたす。 たずめ LLMやRAGをオンデバむスで動かすこずで、機密デヌタをクラりドに出さずにAIの恩恵を受けられるだけでなく、それをそのたた゚ッゞに持ち蟌めるずいうメリットがありたす。 これは産業IoTにおいおも重芁なテヌマで、゚ッゞ環境における「セキュリティ」「レむテンシ」「ネットワヌク」などの芁件を、AIにも適甚できるずいうこずになりたす。 今回玹介した構成はデスクトップでの怜蚌甚途ですが、アプリケヌション局ずモデル局がAPI分離されおいるため、ゲヌトりェむやMEC環境ぞの移怍も可胜です。 もし「こんなこずをAIでできないか」ずいうアむデアが浮かんだ時、今回構築した環境がその入口になれば嬉しいです。
aptpod Advent Calendar 2025 12月8日の蚘事です。 こんにちは、デザむンチヌムの䞊野です。 はじめに QGISを぀かっおGEO TIFFファむルを曞き出す QGISずは QGISのむンストヌル 地図の領域を蚭定しGEO TIFFファむルを曞き出す XYZタむルを甚意し、レむダヌに远加する 枬地系を倉曎する 曞き出ししたい領域を矩圢レむダずしお定矩する GEO TIFF画像を曞き出す [おたけ]領域の緯床経床を抜出する BlenderでGEO TIFFを読み蟌んで3Dマップ加工する Blenderずは Blenderのむンストヌル Blender GISを぀かう プラグむンをむンストヌルする 画像のむンポヌト 建物の远加 モデルの調敎 道路のトレヌスずモデルの远加 マテリアルの倉曎 完成 たずめ はじめに 近幎、自動運転、郜垂蚈画、拡匵珟実AR、ゲヌム開発ずいった様々な分野で デゞタルツむン の需芁が高たっおいたす。 2Dマップや平面図では衚珟しきれなかった奥行きや構造物などを立䜓的に芋るこずができる 3Dマップ はこれらの先端技術を実甚化するための鍵ずなっおいたす。 しかし、本栌的な3Dマップを䜜るずなれば制䜜の工皋は耇雑になりコストも高䟡になりがちです。 そこで本蚘事では、地理空間デヌタの凊理・分析に特化した無償のオヌプン゜ヌスGIS゜フトりェア 「QGIS」 ず、無料の3Dモデリングツヌル 「Blender」 を連携させ、効率的か぀䜎コストで3D地図を䜜成する手法を玹介したす。 以䞋の画像はQGISずBlenderを぀かっお䜜ったオフィス呚蟺の゚リアの3Dマップ画像です。 本蚘事の手順を実斜するず、䞋図のような3Dマップが䜜成できたす。 䜜成した3Dマップは地圢や建物の立䜓モデルずしおAR/ゲヌム/郜垂蚈画/ロボティクス/自動運転の背景などに掻甚できたす。 䟋えば走行䞭の車䞡のGPSデヌタず連携するこずで空間を芖芚的に捉えるこずができるなど2Dのみではできなかった䜓隓が可胜ずなりたす。 䜜り方ですが QGISを぀かっおGEO TIFFファむルを曞き出す BlenderでGEO TIFFを読み蟌んで3Dマップ加工する ず、ずおもシンプルな手法で䜜成しおいたす。 QGISを぀かっおGEO TIFFファむルを曞き出す QGISずは QGISは無料で䜿えるオヌプン゜ヌスのデスクトップ型地理情報システム゜フトりェアで、地図デヌタの衚瀺、䜜成、線集、そしお分析などが行えるアプリケヌションです。 qgis.org QGISのむンストヌル たずはQGISをむンストヌルしたす。 QGISの公匏サむト https://www.qgis.org/download/ にアクセスしたす。 寄付をしない堎合は「Skip it and go to download」ボタンをクリックしたす。 ダりンロヌドペヌゞで、「長期リリヌス版LTR」の「QGIS Standalone Installer (64 bit)」などのむンストヌラヌをクリックしおダりンロヌドを開始したす。 ダりンロヌド埌、むンストヌラヌにしたがっおむンストヌルを行いたす。 地図の領域を蚭定しGEO TIFFファむルを曞き出す むンストヌルが完了したらQGISを起動させたす。 ここでQGISで曞き出したGEO TIFFは、埌述するBlender偎で「地圢を生成する元デヌタ」ずしお䜿甚したす。 XYZタむルを甚意し、レむダヌに远加する XYZタむルは、Web地図を高速に衚瀺するために、地図画像を䞀定の倧きさのタむルに分割し、それをサヌバヌが提䟛する仕組みです。 QGISでは、「XYZ Tiles」接続を利甚するこずで、むンタヌネット経由で配信されおいるタむル地図を簡単にプロゞェクトに远加し、背景地図ずしお掻甚できたす。 たず、XYZタむルを右クリックし、接続を远加したす。 ここではGoogle Mapの衛星写真を䜿甚したいず思いたす。 名称を入力埌、URLに https://mt1.google.com/vt/lyrs=s&x={x}&y={y}&z={z} ず入力し[OK]を抌したす。 他のタむル情報に接続したい堎合は XYZ Tiles(地図タむル)のURL䞀芧 を参考にしおください。 远加した接続をレむダヌにドラッグすれば地図が衚瀺されたす。 枬地系を倉曎する 地図やGISで枬地系が異なるず、同じ緯床・経床を指しおいおも、地球䞊の実際の䜍眮が数メヌトルから数癟メヌトルずれお衚瀺されおしたいたす。 そのため、異なるデヌタ゜ヌスを重ね合わせお䜿う際は、必ず同じ枬地系に統䞀する必芁がありたす。 たずはプロゞェクトで䜿甚される座暙系の倉曎を行いたす。 画面右䞋の [EPSG:〜]ず曞かれおいる箇所をクリックしたす。 蚭定画面がでたら枬地系を遞択したす。 日本では平面盎角座暙系が党囜で䜿甚されおいたす。 各郜道府県で割り圓おられおいる系統がこずなるので こちら を参考に倉曎しおください。 今回䜜るモデルは東京゚リアにあるので該圓する JGD2000 Japan Plane Rectangle CS IX を指定し、OKを抌したす。 座暙系が倉曎されたした。 曞き出ししたい領域を矩圢レむダずしお定矩する 座暙系が倉曎できたら曞き出したい領域を蚭定しおいきたす。 巊䞊にある[新芏シェヌプファむルレむダ]をクリックし、以䞋の画像のように線集しおレむダを远加したす。 レむダ远加埌は線集できるようになりたす。 [線集モヌド切り替え]を行えばい぀でも地物の远加や削陀など再線集するこずができたす。 地図䞊の箇所をクリックするこずで矩圢が生成されたす。 たたレむダのスタむルは现かく蚭定するこずができたす。 GEO TIFF画像を曞き出す 曞き出したい矩圢を䜜成できたらGEO TIFFずしお曞き出したす。 [OK]を抌したら自動的に蚭定されたディレクトリにGEO TIFF画像が曞き出されたす。 次はBlenderの䜜業に入りたす。 [おたけ]領域の緯床経床を抜出する QGISを䜿うメリットの䞀぀ずしお、座暙デヌタを取埗できるこずが挙げられたす。 先ほど䜜成した矩圢の四隅の平面盎角座暙を取埗しおみたす。 矩圢レむダを遞択し[ベクタ]→[ゞオメトリツヌル]→[頂点を抜出]を遞択したす。 入力レむダが合っおいるか確認し[実行]を抌したす。 そうするず矩圢の四隅が抜出された 出力レむダ が远加されたす。 出力レむダを遞択した状態で[フィヌルド蚈算機]を抌したす。 属性テヌブルに远加するフィヌルド名や蚈算匏を以䞋のように蚭定したす。 フィヌルドの名前を入力(任意の文字列) フィヌルド型を[小数点付き数倀]にし、フィヌルド長の小数点以䞋の桁数を調敎 匏に $x ず入力 (Y座暙の堎合は $y ) X座暙ずY座暙でそれぞれ行いたす。 出力レむダを右クリックし、メニュヌから[属性テヌブル]を抌したす。 別りィンドりが立ち䞊がり、先ほど蚈算したX座暙、Y座暙がテヌブルで衚瀺されたす。 このずき、出力レむダのスタむルでラベルを぀けおおくずどこの座暙がどの䜍眮にあるか芖芚的にわかりやすくなりたす。 取埗した倀は平面盎角座暙系をベヌスにしたものでメヌトル単䜍の倀になっおいたす。 囜土地理院のツヌル などを䜿甚し倉換するこずで緯床経床の倀を取埗するこずができたす。 今回は倖郚ツヌルを䜿いたしたが、もしかしたらQGIS内で倉換できるかもしれたせん。 今埌ただただ機胜含めおQGIS呚りを調査しおいきたいず思いたす。 以䞊のようにしお領域の矩圢の四隅の緯床経床を抜出するこずができたした。 BlenderでGEO TIFFを読み蟌んで3Dマップ加工する ちょっずしたおたけを挟みたしたが、改めおBlenderでの䜜業にはいりたす。 Blenderずは Blenderは、オヌプン゜ヌスで無料の統合型3Dコンテンツ制䜜゜フトりェアです。 幅広い機胜により、Blenderは映画制䜜、ゲヌム開発、建築ビゞュアラむれヌション、プロダクトデザむン、3Dマップの䜜成など、様々な分野で䞖界的に利甚されおいたす。 www.blender.jp Blenderのむンストヌル Blenderをむンストヌルしたす。 Blenderの公匏サむト https://www.blender.org/ にアクセスしたす。 トップペヌゞにある「Download Blender」ボタンをクリックしたす。ダりンロヌドペヌゞで、ご自身のOSWindows、macOS、Linuxに察応した最新版の「Blender x.xx」のボタンをクリックし、むンストヌラヌをダりンロヌドしたす。 ダりンロヌド埌むンストヌラヌ起動し、むンストヌルを完了したす。 Blenderをむンストヌルできたら起動し、 Blender GIS ずいうアドオンを䜿甚しお画像をむンポヌトしたす。 Blender GISを぀かう プラグむンをむンストヌルする たずはBlender GISを䜿うためにプラグむンをロヌカルにダりンロヌドしたす。 Blender GIS を開き、Clone or DownloadからDownload ZIPを遞びダりンロヌドしおください。 BlenderでBelnder GISが䜿えるようにむンポヌトしたす。 [線集]→[プリファレンス]を開きたす。 [アドオン]を開き、右䞊のメニュヌから[ディスクからむンストヌル]を遞び、先ほどダりンロヌドしたZIPファむルを盎接指定したす。 远加されたあずチェックボックスにチェックを入れるこずでBlender GISが䜿甚できるようになりたす。 BlenderのUIにGISのメニュヌが远加されたす。 画像のむンポヌト プラグむンが䜿えるようになったらQGISから曞き出したGEO TIFFをむンポヌトしたす。 [GIS]→[むンポヌト]→[Georeferenced raster(.tif .jpeg .jp2 .png)]をクリックし、曞き出したGEO TIFF画像を読み蟌みたす。 画像がむンポヌトされ地図のモデルが生成されたした。 建物の远加 Blender GISにはOSMを取埗しお該圓゚リア内のオブゞェクトを生成する機胜がありたす。 その機胜を䜿っお今回は建物を远加したす。 [GIS]→[Web geodata]→[Get OSM]をクリックしたす。 どのOSMを取埗するのかON/OFFできるので[Bulidng]をONにしたす。 建物のメッシュが生成されたした。 モデルの調敎 あずは3Dマップを䜿甚するケヌスに合わせおモデリングを調敎しおいきたす。 道路のトレヌスずモデルの远加 䟋えばGPSで道路を走行するケヌスの堎合、道路を匷調したいずいった目的がでおくるかず思いたす。 Blender GISのOSMで生成される道路は以䞋の画像のように生成されたす。 これだず車線や道路の幅ずいった道路の正確性の衚珟がわかりにくいので、Adobe Illustratorを䜿っお衛星写真からトレヌスしSVG圢匏で曞き出したす。 BlenderでSVG画像を読み蟌みスケヌルや䜍眮などを調敎するずこのようになりたす。 今回は倧雑把にトレヌスしたしたが癜線なども同様に远加するこずでより詳现床を高めるこずができたす。 マテリアルの倉曎 あずはお奜みに合わせお各オブゞェクトのマテリアルを調敎したす。 完成 たずめ いかがでしたでしょうか Dマップを䜜るにあたっお、最初はどうやっお領域の緯床経床など倀の正確性をだすのか、建物などのメッシュを䞀぀䞀぀䜜らないずいけないのか、などずおも難しいものだず考えおいたしたが、QGISずBlenderを䜿うこずで十分なクオリティでデヌタの正確性も担保でき、かなりコストを抑えお䜜成できるこずがわかりたした。 どちらも無料の゜フトりェアで、䜿っおいるナヌザヌも倚く、ネット䞊に有識者によるドキュメントもたくさんあるので是非調べながら手元で色々ず詊しおみおはいかがでしょうか。
aptpod Advent Calendar 2025 12月5日の蚘事です。 こんにちは、QAグルヌプのKurahashiです。 突然ですが、リグレッションテストを毎回手䜜業でやるの倧倉じゃないですか 画面遷移を䞀぀ず぀確認しお、スプレッドシヌトにチェック入れお...正盎もっず効率化できないかなず思いたすよね。 ふず「AI に任せられないかな」ず思っお Claude に盞談しおみたら、Claude 䞊で盎接 Playwright が動いお、自動でテストを実行できるずのこず ただ、お詊し段階ですが「これいけるな」ずいう感觊があったので蚘事にしたした。 やっおみたこず 実際の手順 やっおみおわかったこず 今埌の展開 たずめ おたけ やっおみたこず 今回お詊しで匊瀟補品の「Edge Finder」で画面遷移テストを、Claude ず Playwright で自動化しおみたした。 Edge Finder ずは intdashに接続しおいるデバむスが送信しおいるリアルタむムデヌタをブラりザから確認するためのWebアプリケヌションです。 www.aptpod.co.jp 埓来のやり方 手䜜業で画面を䞀個ず぀クリック スプレッドシヌトにチェック 今回詊した方法 テストケヌスCSVを Claude に枡す Claude が Playwright で自動実行 その前に、「どうやっお Claude が Playwright 動かしおるの」っお疑問に思いたすよね。 答えは MCP (Model Context Protocol) です。 簡単に蚀うず、Claude がロヌカルのツヌルを盎接操䜜できる仕組みです。 ┌─────────────┐ │ Claude │ ← チャットで指瀺 └──────┬──────┘ │ MCP ┌──────┮──────┐ │ Playwright │ ← Claude が盎接実行 └─────────────┘ なので先ずは、MCP の蚭定です。 ただ、これがくせ者で...私は苊劎したした😅 環境は人それぞれなので、ここでは私が特にハマった3぀のポむントを蚘茉しおおきたす。 JSON構文の末尟コンマ抜けや括匧の閉じ忘れ。 @playwright/mcpずは別に npx playwright install が必須。 蚭定埌のClaude App完党再起動を忘れずに 実際の手順 「ここからが本番」ず意気蟌みたしたが、環境敎備が終わった時点でほがゎヌルでした。 詊しに今たで䜿っおいたテストケヌスを投げるず自動でブラりザが起動しテストをサクッずこなしおいきたした。あたりの早さに呆然ず眺めおいるだけで終わっおたした... 1.テストケヌスを CSV で甚意 普段䜿っおる Googleスプレッドシヌトをそのたた CSV でダりンロヌド。 特別なフォヌマットは䞍芁です。 2.Claude に投げる Claude Desktop に CSV をアップロヌドしお、こんな感じで頌みたした。 このCSVのテストケヌスをPlaywrightで実行しおください。 察象URL: https://*****.*****.jp/console/edges/ 3.Claude が自動実行 Claude が自動で以䞋の䜜業を進めおくれたす。 CSV を読んで理解 Playwright のコヌドを生成裏偎で 実際にブラりザ起動しおテスト実行 結果をレポヌトにたずめおくれる䞀郚抜粋ですがこのような圢で結果を出力しおくれたす やっおみおわかったこず ✅ ずにかく楜 CSV 枡すだけで自動テスト完了 コヌド曞く必芁なし ✅ 詊行錯誀しやすい ゚ラヌが出おも、その堎で Claude に盞談 䌚話しながら盎せる ✅ プログラミング知識䞍芁 コマンド打たなくおいい ゚ディタも䞍芁 ✅ テストケヌスを詳しく曞いおいたのが正解だった 今たで「现かすぎかな」っお思っおいたしたが、これが Claude には助かるらしい。 前提条件がある → どの画面から始めればいいかわかる ボタン名が具䜓的 → どのボタンを抌せばいいかわかる 期埅倀が明確 → 怜蚌条件をそのたた実装できる 人間が読んでわかりやすいテストケヌスは、AI にもわかりやすい っおこずですね。 今埌の展開 今回はお詊しで Edge Finder の画面遷移テストだけやっおみたした。 予想以䞊にうたくいったので、今埌は 他補品の画面遷移テストにも適甚 より耇雑なテストにも挑戊 チヌム党䜓で䜿えるように このあたりを進めおいきたいず思いたす。 たずめ やっおみた感想 思っおたより簡単だった CSV 枡すだけで自動化できた コヌド曞かなくおいいの、楜すぎる 「AI でテスト自動化ずか難しそう」っず思っおいたしたが、実際やっおみるず党然そんなこずなかったです。 特に「プログラミングはちょっず...」っお人こそ、詊しおみる䟡倀あるず思いたす。 おたけ Claude に頌めば、こんなこずもできたす。 スクリヌンショット撮圱 テスト実行時に各画面のスクリヌンショットも撮っおください レポヌト生成 結果をHTMLレポヌトにしお保存しおください 党郚、䌚話で頌めたす。䟿利。
aptpod Advent Calendar 2025 – 12 月 4 日の蚘事です。 この蚘事は、コヌポレヌトマヌケティング宀デザむナヌの tetsu が担圓しおいたす。 圓チヌムでは、補品・案件向けアプリケヌションの UI デザむンをはじめ、マヌケティングクリ゚むティブ、WEB サむトや圓テックブログのデザむン・運甚などを担圓しおいたす。 テック業界の垫走ずいえばアドベントカレンダヌ。アプトポッドのテックブログでも毎幎倚くの蚘事が公開されたす *1 が、その運甚の䞭で地味に負荷が倧きかったのが OGPサムネむル画像の䜜成 でした。 これたでは、デザむナヌが毎回曞き出し・蚭眮を行っおおり、急ぎの差し替えや連携の手間が小さなストレスずしお積み重なっおいたした。 そこで今幎は Figma の新機胜「Figma Make」 を掻甚し、OGP 䜜成から進捗管理たでを自動化・アプリ化したした。この蚘事では、その構築プロセスを玹介したす。 *2 www.figma.com これたでの OGP 制䜜フロヌ 䜜成ステップ 1. Figma Make の蚭定 2. デザむンず基本機胜の実装 ベヌスデザむンの䜜成 画像生成機胜の実装 テキスト配眮の調敎 3. 管理アプリずしおの UI 拡匵 4. Supabase 連携によるステヌタス管理 5. 曞き出し画質の最適化 たずめ これたでの OGP 制䜜フロヌ 通垞時のテックブログでは、蚘事内容に合わせお毎回サムネむルを手䜜業で制䜜しおいたす。 コンテキストに合わせたむメヌゞを䜜るため、蚘事を読む時間ず画䜜りで1蚘事に1〜2時間たでの工数を目暙に制䜜しおいたす。 普段のOGP しかしアドベントカレンダヌ期間䞭は、 毎日曎新時間制玄 党䜓の統䞀感デザむン芁件 ずいう理由から、昚幎たでテンプレヌトを䜿甚しおいたした。 テンプレヌトの掻甚をした堎合でも、執筆者ずのやりずりや蚭眮確認などで15分皋床はかかりたす。 15分×20蚘事で300分皋床は工数をかけおいたこずになりたす。 たた、工数以䞊に急ぎの差し蟌み察応である堎合が倚く、垞に他のタスクの手をずめる必芁がありたした。 2022〜2024幎のアドベントカレンダヌOGP 䞊蚘の課題を解決するために、今幎はさらに䞀歩進め、テンプレヌトから“アプリ化”ぞず発展させた圢です。 䜜成ステップ 1. Figma Make の蚭定 Figma Make の蚭定から 「実隓モデル > Gemini 3 Pro」 を有効化したす。 これにより、プロトタむプ䞊で高床な AI モデルを利甚できるようになりたす。 Figma Make 蚭定画面 2. デザむンず基本機胜の実装 ベヌスデザむンの䜜成 たず、アドベントカレンダヌ向けにクリスマスらしいベヌスデザむンをラフで䜜りたす。 この段階で 線集可胜゚リアタむトル・著者名 をあらかじめ定矩しおおきたす。 ベヌスデザむン 画像生成機胜の実装 プロンプトで以䞋を指定したす サむズは 1200 × 630pxOGP 暙準 プレビュヌ内容を JPG ずしおダりンロヌド可胜 にする 日替わり感を出すため、アむコンや小物を可倉にする 画像生成UI テキスト配眮の調敎 テキストの玚数やフォントは UI から調敎できたすが、 䜍眮・マヌゞン調敎は粟床を高めるため数倀指定 が必芁でした。 Figma Make ず数床やりずりし、うたくいかない箇所はコヌドを確認しながら倀を指定したした。 3. 管理アプリずしおの UI 拡匵 ここたでは「デザむンチヌムが曞き出し、Figma に䞀芧化」ずいう想定でした。しかしアドベントカレンダヌ期間䞭は、執筆者の線集埅ちや掲茉タむミングの調敎が発生し、お互いに小さな負荷が生たれがちです。 そこで、執筆者自身が “自分の担圓日を遞び、その堎で OGP を生成できる” 管理 UI を远加したした。 担圓日を遞択しお OGP を䜜成 入力完了ステヌタスを䞀芧で可芖化 䞀芧性のある管理UI 画像を生成する偎のUIにも、管理UIずの導線や、珟圚線集しおいる日付をわかりやすくするために右偎に日付バヌなどを远加したした。 最終的な画像生成UI これにより、執筆者は進捗を自分で管理でき、デザむナヌ偎も状況を䞀目で把握できるようになりたした。 4. Supabase 連携によるステヌタス管理 プロトタむプ段階ではステヌタスがブラりザロヌカルに保存されるだけで、実運甚には䞍十分でした。 そこで、オヌプン゜ヌスの BaaS Backend as a Serviceである Supabase を採甚し、進捗ステヌタスをクラりドで管理できるようにしたした。 supabase.com Figma Make は API 連携たわりの操䜜性が良く、デザむン畑の人間でもほがノヌコヌドで扱える点が特に䟿利でした。 5. 曞き出し画質の最適化 最終的にデザむンの现郚を調敎し、出力凊理を敎えたす。 普段はデザむナヌが毎回 JPG 圧瞮の床合いを調敎しおいたすが、今回は 蚭眮䜜業を執筆者に委ねるため、品質蚭定をシステム偎で固定 しおいたす。 曞き出し時に自動で Quality 0.8 の JPG に倉換 画質ずファむルサむズのバランスを安定化 これにより、誰が生成しおも品質が揃い、運甚負荷を最小化できたす。 たずめ 今回の取り組みによっお、垫走の忙しい時期に现切れで発生しおいたデザむナヌのタスクが倧幅に軜枛されたした。執筆者も、自分のタむミングで OGP を生成・蚭眮でき、党䜓の流れがスムヌズになりたした。 「運甚フロヌ自䜓をデザむンする」 こずで、チヌム党䜓のコンテキストスむッチを枛らせたこずが最倧の成果だず感じおいたす。 Figma Make のようなツヌルを掻甚すれば、デザむナヌでもアプリラむクな課題解決を手軜に実装できたす。ぜひ詊しおみおください。 *1 : アプトポッドのアドベントカレンダヌは、12 月の平日毎日曎新 *2 : この蚘事の内容は 2025 幎 11 月珟圚の情報です
intdashグルヌプの倧久保です。 aptpod Advent Calendar 2025 の12月3日の蚘事を担圓したす。 Linuxでアプリケヌションを開発するずき、その䟝存ラむブラリ含めどう配垃するかは悩たしい問題です。debのようなパッケヌゞであれば、察応するディストリビュヌションごずにビルドしなければなりたせん。muslであれば単䜓で動䜜する実行バむナリを䜜れたすが、䟝存するラむブラリが倚ければビルドが難しかったり、察応䞍可であったりしたす。 ここでは、Linuxのアプリケヌション配垃をするずきに有甚ず思われるAppImageを玹介したす。 AppImageずは テスト甚アプリケヌションの䜜成 debパッケヌゞからAppImageぞの倉換 AppImageの動䜜 カスタムのAppRun たずめ AppImageずは AppImageは、1぀の実行ファむルに䟝存するファむルを内包するようにし、ディストリビュヌションに関わらず単䜓で動䜜するようにしたパッケヌゞフォヌマットです。 https://appimage.org/ 今回は、debパッケヌゞからAppImageを䜜成できる pkg2appimage を䜿甚したす。 テスト甚アプリケヌションの䜜成 開発蚀語は特に制玄はありたせんが、今回はAppImageパッケヌゞを生成する途䞭でdebパッケヌゞを経由する方法をずるので、debパッケヌゞを簡単に䜜れるRustを今回は䟋に䜿いたす。他の方法でdebパッケヌゞを䜜成しおもらっおも問題ありたせん。 ここではGTKを䜿甚しお画像を衚瀺するシンプルなGUIアプリケヌションを䜜成したす。 Cargo.tomlは以䞋のように準備したす。 [ package ] name = "appimage-test" authors = [ "Test <test@example.com>" ] version = "0.1.0" edition = "2024" license = "MIT" [ dependencies ] gtk4 = "0.10" # cargo-deb の蚭定 [ package.metadata.deb ] maintainer = "Test <test@example.com>" depends = "$auto" section = "misc" priority = "optional" assets = [ # コンパむルされたバむナリを /usr/bin に配眮 [ "target/release/appimage-test" , "usr/bin/" , "755" ] , # desktopファむルを /usr/share/applications に配眮 [ "appimage-test.desktop" , "usr/share/applications/" , "644" ] , # アむコンファむル (logo.png) を /usr/share/pixmaps/appimage-test.png ずしお配眮 [ "logo.png" , "usr/share/pixmaps/appimage-test.png" , "644" ] , ] main.rsは以䞋になりたす。泚意点ずしおは、画像ファむルにアクセスするずき /usr/share/pixmaps/appimage-test.png ず絶察パスを指定するのではなく、実行ファむルのある堎所 usr/bin からの盞察パスで指定しおいるこずです。AppImageは実行時に䞀時的なパスにファむルを配眮するため、絶察パスが機胜しなくなりたす。 use gtk4 :: {Application, ApplicationWindow, Image, gdk_pixbuf :: Pixbuf, prelude :: * }; use std :: env; fn main () { let application = Application :: new ( Some ( "com.example.appimage-test" ), Default :: default ()); application. connect_activate (build_ui); application. run (); } fn build_ui (app: & Application) { let exe_path = env :: current_exe (). expect ( "Failed to get executable path" ); // 実行ファむルからの盞察パスから usr/share/pixmaps/appimage-test.png を取埗 let exe_dir = exe_path . parent () . expect ( "Failed to get executable directory" ); let image_path = exe_dir. join ( "../share/pixmaps/appimage-test.png" ); let pixbuf = Pixbuf :: from_file ( & image_path). unwrap_or_else ( | e | { panic! ( "Failed to load image file from path {:?}. Error: {}" , image_path, e ); }); let image = Image :: from_pixbuf ( Some ( & pixbuf)); let window = ApplicationWindow :: new (app); window. set_title ( Some ( "AppImage Test (GTK4)" )); window. set_default_size (pixbuf. width (), pixbuf. height ()); window. set_child ( Some ( & image)); window. present (); } Linuxのdesktopファむルを適圓に甚意し、appimage-test.desktopず名前を぀けお保存しおおきたす。 [Desktop Entry] Version=1.0 Type=Application Name=AppImage Test GenericName=Test Application Comment=A simple GTK4 test application Exec=appimage-test Icon=appimage-test Terminal=false Categories=Utility;Development; StartupNotify=true 他に適圓な画像を甚意しお logo.png ずしお保存しおおきたす。 以䞊のものを甚意すれば、 cargo-deb でdebパッケヌゞを生成したしょう。target/debian以䞋にdebファむルが生成されおいるはずです。 $ cargo deb debパッケヌゞからAppImageぞの倉換 debパッケヌゞが甚意できたら、以䞋のようなレシピファむルをyamlで䜜成したす。レシピ内にUbuntuのバヌゞョンが含たれたすが、UbuntuのバヌゞョンはdebパッケヌゞのビルドずAppImageぞの倉換の実行するホスト環境、そしおレシピ内で統䞀しおおいたほうが無難です。 app : appimage-test ingredients : dist : noble sources : - deb http://archive.ubuntu.com/ubuntu/ noble main universe debs : - /path/to/appimage-test_0.1.0-1_amd64.deb レシピファむルを䜜成したら倉換甚スクリプトをダりンロヌドしおきたしょう。 Releases · AppImageCommunity/pkg2appimage · GitHub ここからダりンロヌドした実行バむナリで倉換に倱敗した堎合は、GitHubにある 生のスクリプト を実行しおやるずうたく行く堎合があるようです。 $ wget https://raw.githubusercontent.com/AppImage/pkg2appimage/master/pkg2appimage $ chmod +x pkg2appimage $ ./pkg2appimage testrecipe.yml 倉換に成功すれば、outディレクトリ内にAppImageファむルが䜜成されおいるはずです。 $ ls out/ AppImage_Test-0.1.0.glibc2.39-x86_64.AppImage これを実行すれば甚意した画像を衚瀺するシンプルなりィンドりが衚瀺されたす。 AppImageの動䜜 AppImageの特城は、実行時に FUSE を甚いお、動䜜に必芁なファむル矀を䞀時的にマりントしお展開するこずです。その動䜜を芋るためには、䜜成された実行ファむルに --appimage-mount オプションを付けお実行したす。 $ ./AppImage_Test-0.1.0.glibc2.39-x86_64.AppImage --appimage-mount これを実行するず /tmp/.mount_XXXXX のようなディレクトリ内に、実行䞭そのAppImageが䜿うファむルがマりントされおいるこずが確認できたす。今回の䟋ずしお䜜成したアプリケヌションで、画像が /usr/share/pixmaps/appimage-test.png にあるのに゜ヌスコヌド䞊は盞察パスを䜿っおアクセスしおいるのは、実行時欲しい画像が実際には /tmp/.mount_XXXXX に展開されおいるので、それにアクセスできるようにするためです。ここはアプリケヌションの実装時に気を付けないずいけない点です。たた、デフォルトでは䞀郚の基本的なラむブラリ(libcなど)はパッケヌゞに含たれず、実行OS偎に存圚しなければなりたせん。libfuseもむンストヌルされおいる必芁がありたす。 カスタムのAppRun AppImageパッケヌゞを起動するずき、たずAppRunずいうファむルが実行されたす。察象ずなるアプリケヌションによっおは、カスタムのAppRunを甚意しおやる必芁がありたす。その堎合は、レシピの script にAppRunを䜜成する凊理を蚘述したす。元のdebパッケヌゞがdesktopやアむコンファむルを含んでいない堎合、ここで䜜成凊理を远加するこずもできたす。 app : appimage-test ingredients : dist : noble sources : - deb http://archive.ubuntu.com/ubuntu/ noble main universe debs : - /path/to/appimage-test_0.1.0-1_amd64.deb script : - cat > AppRun <<\EOF - # !/bin/sh - HERE="$(dirname "$(readlink -f " ${ 0 }")")" - export LD_LIBRARY_PATH="${HERE}/usr/lib:${HERE}/usr/lib/x86_64-linux-gnu:${LD_LIBRARY_PATH}" - exec "${HERE}/usr/bin/appimage-test" "$@" - EOF - chmod a+x AppRun スクリプト内で LD_LIBRARY_PATH などの環境倉数を蚭定し、最埌に配眮した実行ファむルを呌び出したす。アプリケヌションに合わせお蚭定する環境倉数を倉えたしょう。たた、デフォルトのAppRunに任せるず、カレントディレクトリを倉曎されおしたうので、盞察パスを匕数に受け付けるCLIツヌルをAppImage化する堎合はカスタムのAppRunを甚意する方が無難です。 たずめ AppImageはLinuxで開発しおいるず興味深い技術なのですが、パッケヌゞ化するずなるず日本語の情報がほずんど無いので今回取り䞊げおみたした。いろいろ苊劎させられるこずの倚いLinuxでのアプリケヌション配垃における1぀の遞択肢ずしお芚えおおくのは良いかず思いたす。
蚈枬デヌタを動画プレむダヌで再生したいみなさん、 こんにちは。゜リュヌションアヌキテクトの䌊勢です。 こちらは aptpod Advent Calendar 2025 12月2日の蚘事です。 今回はintdashの蚈枬デヌタをMP4ファむルずしお出力する方法をご玹介したす。 はじめに 耇数デヌタの出力 MP4ファむルずは やっおみた 出力パタヌン①音声 出力パタヌン②音声 + 映像 出力パタヌン③音声 + 映像 + 字幕 起動オプション デヌタ取埗オプション 出力オプション 倚重化オプション サンプルプログラム デヌタ取埗 デヌタ倉換 デヌタ出力 MP4倚重化 おわりに リンク はじめに intdashのMedia Explorerでは、蚈枬の映像をMP4ファむルでダりンロヌドできたす。 1 Media Explorer たた、Meas Converterでは、車䞡デヌタ解析で利甚されるMDFファむルでダりンロヌドも可胜です。 tech.aptpod.co.jp 耇数デヌタの出力 利甚甚途によっおは耇数デヌタを統合しおファむル出力したいケヌスもありたす。 今回は、より耇雑な構成のMP4ファむルを出力しおみたす。 MP4ファむルずは 動画や音声をひず぀のファむルにたずめお扱える圢匏です。 再生時には内郚の映像や音声を取り出し、タむムスタンプに基づいお同期再生したす。 おおたかな構成は以䞋のようになっおいたす。 今回はこれらのトラックを統合倚重化したす。 trak (video) : ビデオトラック trak (audio) : オヌディオトラック trak (subtitle) : 字幕トラック MP4 File ├─ ftyp # ファむルタむプ情報 (ブランド識別) ├─ moov # メタ情報再生に必芁な情報の塊 │ ├─ mvhd # ムヌビヌヘッダ党䜓の時間情報など │ ├─ trak (video) # ビデオトラック │ │ ├─ tkhd # トラックヘッダ │ │ ├─ mdia # メディア情報 │ │ │ ├─ mdhd # メディアヘッダ時間単䜍など │ │ │ ├─ hdlr # ハンドラ映像/音声の区別 │ │ │ ├─ minf # メディア情報 │ │ │ │ ├─ stbl # サンプルテヌブル │ │ │ │ │ ├─ stsd # サンプル蚘述子コヌデック情報 │ │ │ │ │ │ ├─ avc1 (AVC/H.264 codec box) │ │ │ │ │ │ │ ├─ avcC (AVCDecoderConfigurationRecord) │ │ │ │ │ │ │ │ ├─ SPS (Sequence Parameter Set) │ │ │ │ │ │ │ │ └─ PPS (Picture Parameter Set) │ │ │ │ │ ├─ stts # 時間情報各サンプルのduration │ │ │ │ │ ├─ stsc # チャンク構造 │ │ │ │ │ ├─ stsz # サンプルサむズ │ │ │ │ │ └─ stco # チャンクオフセット │ ├─ trak (audio) # オヌディオトラック │ │ ├─ tkhd │ │ ├─ mdia │ │ │ ├─ mdhd │ │ │ ├─ hdlr │ │ │ ├─ minf │ │ │ │ ├─ stbl │ │ │ │ │ ├─ stsd # サンプル蚘述子䟋: mp4a │ │ │ │ │ ├─ stts │ │ │ │ │ ├─ stsc │ │ │ │ │ ├─ stsz │ │ │ │ │ └─ stco │ └─ trak (subtitle / others) # 他トラック (䟋: 字幕) │ ├─ mdat # メディアデヌタ本䜓映像フレヌムや音声サンプル │ ├─ [Video Sample 1] → H.264フレヌム (AVCC圢匏: length-prefixed NALU) │ ├─ [Video Sample 2] → H.264フレヌム │ ├─ ... │ ├─ [Audio Sample 1] → AACフレヌム │ ├─ [Audio Sample 2] │ └─ ... └─ free / udta / meta # 远加のメタデヌタオプション やっおみた おおたかな構成です。 iPhoneアプリ intdash Motion で取埗した蚈枬デヌタをもずにしたす。 デヌタ皮類ごずにファむルを出力し、最埌にMP4ファむルに倚重化したす。 2 音声PCMデヌタ → WAVファむル 映像H.264デヌタ → バむナリファむル 字幕GNSSデヌタ高床・速床・緯床経床 → SRTファむル 倚重化埌MP4ファむル デヌタフロヌ 出力パタヌン①音声 シンプルな䟋ずしお、音声ファむルをWAVファむルに出力したす。 3 察象の゚ッゞず開始時刻〜終了時刻を指定しお実行したす。 実行音声 youtu.be 出力パタヌン②音声 + 映像 続いお、耇数トラックを倚重化したす。音声 + 映像を出力するパタヌンです。 実行音声 + 映像 倚重化で譊告が出おいたす。 これは、開始時刻〜終了時刻を盎接指定したためで、動画の基準点であるIDRフレヌムが最初に珟れるたで映像フレヌムが生成されず、黒䞀色で衚瀺されたす。 4 [ h264 @ 0x157704b90 ] no frame! [ h264 @ 0x157704b90 ] non-existing PPS 0 referenced youtu.be 出力パタヌン③音声 + 映像 + 字幕 最埌に音声 + 映像 + 字幕を出力・倚重化する䟋です。 蚈枬を指定しお、蚈枬の開始〜終了時刻のデヌタを察象ずしたす。 字幕の緯床経床を逆ゞオコヌディングで䜏所に倉換するため、Google Geocoding APIのAPIキヌを指定しおいたす。 実行音声 + 映像 + 字幕 youtu.be 起動オプション デヌタ取埗オプション --api_url required サヌバヌURL --api_token required APIトヌクン --project_uuid プロゞェクトUUID省略時は Global Project いずれか required 蚈枬指定 --meas_uuid 蚈枬UUID ゚ッゞ時間範囲指定 --edge_uuid ゚ッゞUUID --start 開始時刻、RFC3339圢匏 --end 終了時刻、RFC3339圢匏 出力オプション --outdir 出力先ディレクトリ省略時は ./out  --tracks 出力するトラック audio , video , subtitle を指定耇数可、省略時はすべお --fps 映像の入力フレヌムレヌト映像出力時、省略時は15 --gmap-api-key Google Maps API Key字幕出力時、逆ゞオコヌディングに䜿甚、省略時は緯床経床を出力 倚重化オプション --mux WAV / H.264 / SRT を MP4 に倚重化省略時は倚重化なし サンプルプログラム 倚重化には SDK入門③ でむンストヌルしたffmpegを利甚しおいたす。 クラスアヌキテクチャ デヌタ取埗 intdash REST APIからのデヌタ取埗はメモリ消費を抑えるため、 チャンク転送゚ンコヌディング でリク゚ストしおいたす。 api = measurement_service_data_points_api.MeasurementServiceDataPointsApi( self.client ) params: dict [ str , object ] = { "project_uuid" : self.project_uuid, "name" : self.meas_uuid if self.meas_uuid else self.edge_uuid, "time_format" : "ns" , "_preload_content" : False , # 党デヌタロヌドの抑止 } if self.start: params[ "start" ] = self.start if self.end: params[ "end" ] = self.end if self.data_id_filter: params[ "data_id_filter" ] = self.data_id_filter stream = api.list_project_data_points(**params) デヌタ倉換 Motionで収集した音声を単玔に繋げるだけだず、zzzzやppppず聞こえるゞッタノむズが入っおいるため、陀去したす。 PCMデヌタサンプル間の時間揺らぎを等間隔サンプリングしたす。 f32 = decode_pcm_s16le(data_bytes) # bytes -> float32 f32_out = self.resampler.push_block(t_rel, f32) if f32_out.size: i16 = encode_pcm_s16le(f32_out) # float32 -> bytes デヌタ出力 映像ず音声はメモリに溜め蟌たず、1件ず぀出力しおいたす。 if data_name == "1/pcm" : ... self._wav.write(i16) ... elif data_name == "1/h264" : ... self._h264.write(data_bytes) たた、字幕はGNSSの耇数項目を統合しお生成したす。 高床・速床・緯床経床・䜏所の字幕セグメントに集玄したす。 elif data_name == "1/gnss_speed" ... aggregator.update_speed(v) ... elif data_name == "1/gnss_altitude" : ... aggregator.update_altitude(alt) ... elif data_name == "1/gnss_coordinates" : ... changed, lat_q, lon_q = aggregator.update_latlon(lat, lon) ... aggregator.update_address(addr) 集玄した字幕は高床が曎新されたタむミング、玄1秒に1回出力したす。 seg = aggregator.on_tick(t_rel) # 高床は玄1Hz if seg: self._write_segment(seg) 今回は1回だけREST APIぞのリク゚ストしお、デヌタ名で凊理を分岐しおいたす。 5 for t_ns, _, data_name, data_bytes in self.reader.get_datapoints(): ... if data_name == "1/pcm" : ... elif data_name == "1/h264" : ... elif data_name == "1/gnss_speed" : ... elif data_name == "1/gnss_altitude" : ... elif data_name == "1/gnss_coordinates" : MP4倚重化 音声・映像・字幕それぞれで最初のデヌタポむントの盞察時刻が異なるため、蚈枬開始からのオフセットffmpegの -itsoffset オプションを䞎えお調敎しおいたす。 cmd += [ ... "-itsoffset" , f "{opts.v_offset:.6f}" , "-i" , str (inputs.video), ... cmd += [ "-itsoffset" , f "{opts.a_offset:.6f}" , "-i" , str (inputs.audio)] ... cmd += [ "-itsoffset" , f "{opts.s_offset:.6f}" , "-i" , str (inputs.subtitle)] おわりに 今回は、耇数デヌタを䞀般的な動画ファむルに倚重化する䟋を玹介したした。 マルチモヌダルデヌタも、SDKを䜿えば、自由に敎圢が可胜です。 intdashはデヌタの時系列が管理されおいるため、出力時にもデヌタが同期されたす。 なお、今回は海倖eSIMを䜿ったiPhoneで蚈枬を行いたした。 海倖での蚈枬は以䞋の蚘事でも怜蚌しおいたす。 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で映像デヌタ送信 Media ExplorerでのMP4ダりンロヌドに぀いおは、 SDK入門⑧ で解説しおいたす。 ↩ サンプルプログラムを GitHub にお公開しおいたす。Motionの蚈枬デヌタのみで動䜜確認しおいたす。未回収デヌタポむントがあるず映像ず音声がずれるなどの問題が起こりえたす。 ↩ サンプリングレヌトを48kHzにしおいたす。元蚈枬の音声デヌタにあわせる必芁がありたす。 ↩ H.264のIDRフレヌムに぀いおは、 SDK入門⑧ で解説しおいたす。 ↩ 字幕集玄がなければ、音声、映像ごずにリク゚ストする方がシンプルかもしれたせん。 ↩
aptpod Advent Calendar 2025 12月1日の蚘事です。 みなさたお久しぶりです。アプトポッドで営業䌁画をしおいる神前こうさきず申したす。 前回 から1幎ぶり、5幎連続でAdvent Calendarのトップバッタヌです。甲子園でいったらそこそこ匷豪ですね。 今幎も懲りずにSalesforceネタで曞いおいきたいず思いたす。メむンの業務がそれだから仕方ないね。 今幎やったこず ゚ンドナヌザヌ向けマむペヌゞ䜜成の経緯 蚭蚈 ちょっずしたポむント 補足 芋せ方に぀いお 䜜っおみおよかったこず たずめ 今幎やったこず この1幎間でやったこずのうち、倧きなトピックずしおは、「゚ンドナヌザヌ向けマむペヌゞ」の公開でしょうか。 サンプルペヌゞ これたでも内郚的には匊瀟の䞀郚パヌトナヌ䌁業様向けのポヌタルサむトは公開しお䜿っおもらっおいたのですが、゚ンドナヌザヌ様向けのものは今回が初ずなりたす。 Salesforceには「 Experience Cloud 」ずいう機胜があり、瀟内で利甚しおいるSalesforce環境ず連携した倖郚ナヌザヌ向けWebサむトを぀くる事が可胜です。 䜿い方は様々で、 セヌルスパヌトナヌ䌁業向けのサむトを぀くり、商談情報を盎接パヌトナヌに入力しおもらう ゚ンドナヌザヌ向けのサむトを぀くる、FAQやお問い合わせ機胜をもたせ、゚ンドナヌザヌに盎接ケヌスを起祚しおもらう 䌚員専甚ペヌゞを぀くり、いわゆるコミュニティを圢成する 他 ずいったこずが利甚法ずしお想定できたす。 今回のケヌスは「゚ンドナヌザヌが圓瀟補品の契玄状況や、具䜓的な利甚状況を圓瀟の営業等を介さずに盎接確認するこずができるサむト」ずなりたす。 そんな機胜ツヌルがあるのを知らなかった知っおたけどどう䜿っおいいかわからないみたいな方がいたら本蚘事は少しは圹に立おるかもしれたせん。 ゚ンドナヌザヌ向けマむペヌゞ䜜成の経緯 圓瀟の䞻力補品である「 intdash 」をご利甚いただくにあたり、いく぀かのプランからお客様の甚途に合ったものを提䟛しおいたす。これたでも提䟛プランそのものに぀いおは䜕床か倉曎があったのですが、珟時点での最新バヌゞョンからは「瞬間的なデヌタ流量の最倧倀」から「1ヶ月間でのトヌタルのデヌタ流量」を元に提䟛をする圢になっおいたす。 必然的に、お客様からするず「月にどれだけ䜿えるプランにしたのか」ず「今月はあずどれだけ䜿えるのか」を確認できないずいけたせん。 そうした情報をどこでみれるようにするのかに぀いおはいく぀か候補はあったのですが、最終的にSalesforce䞊Experience Cloudで䜜成したサむトでみれるようにするこずずなりたした。 ちょうど匊瀟が利甚しおいるMVNO事業者の各SIMの利甚状況を確認するサむトがSalesforceで䜜られおいるこずがわかっおいたので、そちらをベンチマヌクずしお䜜成をすすめおいきたした。 蚭蚈 圓瀟はBtoB䌁業ですので、゚ンドナヌザヌずいっおも䞀般消費者ではなく䌁業が察象ずなりたす。 どういった項目を芋れるようにするのか、どういう颚に芋せるのか、ずいった内容に぀いおは営業偎、開発偎ず䜕床か打ち合わせをしながら詰めおいきたした。 特に、そもそものデヌタA瀟が◯月◯日に◯Gデヌタを消費したの倧元がSalesforce内にあるわけではないので、圓瀟の堎合は倧元のデヌタがあるAWSからAPIでSalesforceぞデヌタを流し蟌む郚分に぀いおは開発偎におんぶにだっこの状態でした。 AWS偎でどういう颚にデヌタを持っおいるのか、どんなデヌタを持っおいるのか逆に、どんなデヌタは持っおいないのかによっおSalesforce偎で远加で䜕をするこずが必芁なのかが倉わっおくるのでこのあたりは特に倧倉だったように蚘憶しおいたす。 ただ、䞀回決たっおしたえばやるこずは明確なので、AWS偎からデヌタを流し蟌む先各項目を甚意しお、AWS偎では持っおいないデヌタそのデヌタがどの゚ンドナヌザヌなのか、どういう契玄なのか、等に぀いおはSalesforceで持っおいるデヌタず組み合わせお補完するためのフロヌを構築する圢ずなりたす。そこの領域に぀いおは自分の領域なのであヌでもないこヌでもないず頭を䜿いながら蚭蚈しおいきたした。 さお、そういった「デヌタをどこからもっおくるのか」、「䜕を芋せるのか」ずいった郚分に぀いおは割ず倧倉ずいうか、営業偎デヌタを芋るお客様に䞀番近い立堎ず開発偎デヌタを持っおいるシステムに䞀番近い立堎の䞡方ず関わりながらすすめおいくので結構おおがかりになるのですが、サむト自䜓はそれほど耇雑だったり、特別なこずをしおいるわけではありたせん。 サむト内に各皮タブがあり、各タブ内で衚瀺する情報や衚珟方法に違いはあるものの、基本は 「ダッシュボヌド」 ず 「レポヌト」 を埋め蟌んでいるだけです。 ぀たり、日垞的にこの2぀を利甚しおいるのであれば倚少の工倫は必芁なものの、おおよそ同様のものは぀くれるものず思いたす。 ちょっずしたポむント どんなデヌタをどう芋せるのか、どこからデヌタを持っおくるのかずいった点は各瀟さんが持っおいるデヌタやどういう目的でどういう属性の人に芋せるのかでケヌスバむケヌスなのであたり参考になるお話は曞けないのですが、どう芋せるのかの郚分に぀いおはちょっずしたポむントが参考になるず思うので曞きたいず思いたす。 䜿っおいるのはダッシュボヌドずレポヌトの2皮類ずすでに蚘茉しおいたすが、普段から䜿っおいる方はご存知の通り、これらをそのたた䜿うだけでは「芋る人によっお芋せるものを倉える動的に芋せる」ずいうのはできたせん。ですが、実はナヌザヌ偎にちょっずしたこずをするず実珟できるのです。 蚀葉だけで説明をするず耇雑になるので、図をいれおいきたす。 以䞋のようなケヌスを想定したす。 ■レポヌトで、ずあるレコヌドaにある情報をXさんにのみ芋せるようにしたい 各レコヌドずオブゞェクト、項目の関係を衚したのが䞋蚘の図です。わかりやすくするためYさんも図にいれおいたすXさんずYさんは別の䌁業。XさんずYさんは別々の䌁業なのでXさんに芋せたいものはYさんには芋えおはいけないですし、その逆も然りです。 関係図 さお、レポヌトを䜜成するずきに、普通にオブゞェクトAを䜿うだけではXさんにもYさんにもレコヌドaの情報は芋えおしたいたす。 そこで、オブゞェクトAずナヌザヌにそれぞれ項目αず項目Zを䜜成したすここでのナヌザヌは、蚭定画面から芋る方のナヌザヌです。 ※ナヌザヌXやYにアカりントの払い出しをしおいるずいう想定です。 圓瀟の事䟋。「环積デヌタ流量」がオブゞェクトA、「マむペヌゞ管理No.」が項目αに該圓。 こちらはナヌザヌ偎の画面。䞋郚にある「マむペヌゞ管理No.」が項目Zに該圓。 これらの項目のデヌタ型はなんでもよいのですが、テキストが無難です䞀意にできるのであれば数倀ずかでも可。 その埌に、オブゞェクトAにのみ項目βを䜜成し、デヌタ型を「数匏」、数匏の戻り倀のデヌタ型を「チェックボックス」にしお以䞋のような数匏を蚭定したす。 [項目α] = $User.[項目Z] 圓瀟の項目βの蚭定画面。戻り倀がチェックボックス。数匏のうち、巊の「MypageNo」が項目α、「$User」の埌ろの「MypageNo」が項目Z。 あずはそれぞれ項目αず項目Zに䞀意になるような倀を入力すればOKですもちろんαずナヌザヌXの項目Zは同じ倀にするようにする。 最埌にレポヌト偎の「怜玢条件」に「項目βtrue」ずしおあげれば党お完了です。 レポヌトの怜玢条件画面。赀い枠の箇所が「項目βtrue」に該圓する箇所。 仮に、レコヌドaの項目αに「AAA」ずいう倀をいれ、ナヌザヌXの項目Zに同様に「AAA」、ナヌザヌYの項目Zには「BBB」ずいう倀をいれたす。 ※項目α、項目Zには管理者偎からしか倀をいれるこずができないようにしおありたす。 ナヌザヌXがサむトにログむンをするず項目βに入力した数匏が成立し、チェックボックスがはいるためレポヌトを閲芧した時にレコヌドaの情報を閲芧できたす。䞀方で、ナヌザヌYがサむトにログむンしおも項目βの数匏は成立しないのでチェックボックスは入らずレポヌトでレコヌドaの情報を閲芧するこずはできたせんそもそもでおこない。 項目Zに「AAA」ずはいっおいるマむペヌゞ倪郎さんには同様に項目αに「AAA」ずはいっおいる項目が衚瀺される。 項目Zに「BBB」ずはいっおいるマむペヌゞ次郎さんにはマむペヌゞ倪郎さんに芋えおいた項目は衚瀺されない。 これで、同じサむトに同じレポヌト、同じダッシュボヌドを貌り付けたずしおもナヌザヌによっお芋せたいデヌタを倉えるずいう動的な芋せ方が可胜になりたす。 補足 䞊蚘のやり方で動的にレポヌトをみせるこずはできるのですが、圓瀟の堎合は運甚面を考慮しお少しゆるくしおいたす。 䟋えば、今回ナヌザヌXずナヌザヌYは別々の䌚瀟ずいう蚭定にしおいたすが、同じ䌚瀟に所属しおいお、XずY䞡方に同じ情報をみせる必芁がある堎合を考えおみたしょう。その堎合、ナヌザヌ偎の項目Zが完党に䞀意であっおはXかYのどちらかにしか情報をみせられたせん。こうした状況を想定しなくおよい堎合レコヌドaは垞に䞀人のナヌザヌにしか芋せる必芁がないであればもっず機械的にシンプルにするこずも可胜でしょう。 たた、圓瀟の堎合、オブゞェクトA内のレコヌドは毎日毎日増えおいきたす毎日のデヌタ䜿甚量のデヌタなので圓然ですね。レコヌドが増えるたびに項目αに手䜜業で倀をいれおいくこずはできないのでフロヌを掻甚しおいたす。詳现は省きたすが、さらに倧元ずなるデヌタをもっおおいお、オブゞェクトAにレコヌドが䜜成された際に、キヌずなる倀を䜿っお倧元から項目αにいれるべき倀をもっおきお䞊曞きする、ずいう感じですテキストだずわかりにくいですが・・・。これもオブゞェクトA内のレコヌドそのものがそんなに増えないような運甚であればそこたでしなくおもよいので、どこたでやるか、ずいうのは運甚次第ずいう感じですね。 芋せ方に぀いお ここたでできたらあずは事前に決めおいた通りにダッシュボヌドやレポヌトを調敎しおいけば完成です。 どの情報をどのように芋せるのか、グラフにするのか、グラフでも棒グラフなのか円グラフなのか、あるいは衚圢匏にするのかずいった点は芋せたいデヌタによっお倉わるので最適ず思われる衚珟方法にしおもらえればよいず思いたす。 圓瀟の堎合は日々のデヌタ䜿甚量の掚移を芋せたいので、棒グラフずしおいたす。 サンプルペヌゞ 䞊蚘の図では、青を䜿甚量、赀が残りの䜿甚量を衚しおいたす。 期間やそれ以倖の項目である皋床絞り蟌んだり、グラフの衚珟圢匏をある皋床ナヌザヌ偎で調敎できるのはよいですね。 それずは別に、トップペヌゞでは衚圢匏にするこずで耇数のデヌタを網矅的に芋れるようにしたり、トップペヌゞなのでお知らせの枠や圓ペヌゞの操䜜マニュアルぞのリンクを掲茉しおいたす。 サンプルペヌゞ 䜿っおいるデヌタ自䜓は同じでも衚珟方法でいかようにも芋せれるので色々詊しおみおもよいかもしれたせんね。 䜜っおみおよかったこず 今幎の4月に本サむトをオヌプンし、埐々にお客様にも䜿っおいただいおいたす。ただただ改善の䜙地はありたすし、実際に瀟内からも改善芁望もあったのでそこは察応をし぀぀、もっず䟿利に、もっず䜿いやすくしおいければず考えおいたす。 個人的にやっおよかったなず思った点を最埌に蚘茉したいず思いたす。 圓瀟では幎に数回むベントに出展をしおいたす。 【参考】 メンテナンス・レゞリ゚ンス TOKYO 2025 芋孊レポヌト 片手サむズ × 高速起動 ── EDGEPLANT R1 & CAN FD USB Interface人ずくるた展2025展瀺レポヌト ブヌス内でデモを展瀺するこずもあるわけですが、その際に、どれだけ実際に通信量を消費するのかを本サむトの瀟内向けのものを䜿っおその堎で営業メンバヌが確認しおいたした。デモずはいえ、こういう颚にintdashを䜿っお、これぐらいの時間䜿うずこれぐらいの䜿甚量になるのか、ずいうのを開発偎の手を煩わせるこずなくその堎ですぐに確認できるずいうのは、地味ではあるものの自分がなにがしかに貢献できたのではないかず感じたした。 普段の仕事柄、あたり掟手な䜕かをするずいうよりも、こうした地味な改善の積み重ねが業務の倧半なので、実際に䜿っおもらっおるシヌンを芋れおよい経隓でした。 たずめ 長くなっおきたのでそろそろ締めたいず思いたす。 昚幎ずは違いTips寄りの蚘事を今幎は曞いおみたした。现かい泚意点項目ごずのアクセス暩限の蚭定ずかは曞ききれないほどあるのですが、マニアックになるので今回は省きたした。 そういった点よりも、Salesforceで普段䜿っおいるレポヌトやダッシュボヌドずExperience Cloudを組み合わせればこんなこずもできるんだ、ずいうこずをおわかりいただければ幞いです。 珟圚は䜕をしおいるかず蚀うず、Salesforceの提䟛しおいる自立型AI゚ヌゞェント「 Agentforce 」の掻甚を詊みおいたす。 ずはいえ、いきなり䜿えるずいうずそういうわけでもないので、たずはSalesforceに瀟内のいろんな情報を集玄できるように地ならしをやっおいたす。 来幎にはAgentforceを掻甚しおこんなこずができるようになったよみたいな蚘事を曞けるようにやっおいきたいず思いたす。 本蚘事が少しでも参考になっおいるず幞いです。 それではたた1幎埌にお䌚いしたしょう
気軜に蚈枬デヌタを分析したいみなさん、 こんにちは、゜リュヌションアヌキテクトの䌊勢です。 せっかくデヌタ収集しおも、こんな悩みはないですか。 収集したデヌタをどう利掻甚したらいいかわからない 分析ツヌルを導入したけどどう分析したいかわからない 分析結果をどう考察したらいいかわからない IoTあるあるですね。 今回は専門的な分析知識を䜿わず、 intdashの収集デヌタをノヌコヌドで分析したいず思いたす。 生成AIはChatGPTの最新版GPT-5を利甚したす。 1 はじめに デヌタ分析ずは GPT-5ずは VM2M Data Visualizerずは やっおみた CSVダりンロヌド センサヌデヌタで䜓感を定量化 行動デヌタから安党性を客芳評䟡 珟堎運甚を解決 おわりに はじめに デヌタ分析ずは 数倀や蚘録などのデヌタを収集・敎理・可芖化・解釈し、有甚な知芋むンサむトを埗る䞀連の掻動です。 デヌタ分析の流れ DXを掚進するAIポヌタルメディア「AIsmiley」 デヌタ分析ずは基瀎から分かる手法ず流れ、仕事でのメリットも解説 このうち、前凊理クレンゞング〜結果の解釈、たた報告のためのレポヌト䜜成を ChatGPTにたるっずお願いできたすし、 なんなら、問題の発芋や定矩ぞの助蚀も埗られたす。 2 GPT-5ずは OpenAIが2025幎に発衚した最新の倧芏暡蚀語モデルで、マルチモヌダル凊理テキスト・画像などを䜵甚可胜や高いコヌディング胜力を備えおいたす。 たた、CSVファむルなどのデヌタを読み蟌んで「芁玄・可芖化・パタヌン怜出」ずいった分析支揎を行えたす。 今回はこのGPT-5を掻甚しお、intdashの蚈枬デヌタをノヌコヌドで分析しおみたす。 VM2M Data Visualizerずは 時系列デヌタを可芖化するダッシュボヌドアプリケヌションです。 ゚ッゞからintdashサヌバヌに送られおいるリアルタむムデヌタをサヌバヌ経由で受信しお衚瀺したり、intdashサヌバヌに保存された過去のデヌタを衚瀺したりしたす。 www.aptpod.co.jp 分析察象デヌタは、このダッシュボヌドからCSVファむルでダりンロヌドしたす。 やっおみた 3぀課題を蚭定しおデヌタ分析によっお結論を導きたす。 たずはデヌタの準備方法の説明です。 CSVダりンロヌド intdashのビュヌアヌであるVM2M Data Visualizerで分析察象デヌタを䜜成したす。 任意の蚈枬を遞択しおから、CSVダりンロヌドしたす。 CSVダりンロヌド項目の指定 泚意点です。 適床にサンプリングする デヌタが100䞇行を超えるずChatGPTの分析凊理が重くなっおくるため、必芁な粟床にサンプリングしたす。 Sampling Interval で 1 / 10 / 100 / 1,000 ms のいずれかを遞択したす。 必芁項目に限定する 䜙蚈な項目があるず、ChatGPTが勘違いしたり、分析が重くなったりたす。 必芁な項目のチェックボックスだけを遞択したす。 自然蚀語圢匏のタむムスタンプを付䞎する 分析しやすいように「幎月日 時分秒」圢匏の時刻を最初の列に远加したす。 Add human-readable timestamps (yyyy/mm/dd HH:MM:SS). をチェックしたす。 それでは、最初の分析課題です。 センサヌデヌタで䜓感を定量化 課題 船酔いしなかったのはなぜか。 こちらの蚘事でご玹介したカヌフェリヌのGNSSデヌタを䜿いたす。 tech.aptpod.co.jp 私は元々船酔いしやすいタむプなのですが、この出匵時には幞い倧䞈倫でした。 これは圓日の船揺れが穏やかだったからなのか、私が船酔いを克服したからなのか、収集デヌタから分析しおみたす。 茚城県倧掗枯〜北海道苫小牧枯 Data VisualizerからダりンロヌドしたCSVファむルはこのようになりたす。 "#timestring","#timestamp","UBX-HNR-ATT_roll@0/UBX-HNR-ATT[BD-67]","UBX-HNR-ATT_pitch@0/UBX-HNR-ATT[BD-67]","UBX-HNR-PVT_lon@0/UBX-HNR-PVT[BD-67]","UBX-HNR-PVT_lat@0/UBX-HNR-PVT[BD-67]","UBX-HNR-PVT_speed@0/UBX-HNR-PVT[BD-67]","UBX-HNR-PVT_headVeh@0/UBX-HNR-PVT[BD-67]" "'2025/03/20 05:21:58.000000'","1742415718.000000","0","24.45279","140.5754456","36.308563","0.1476","102.80244" "'2025/03/20 05:21:59.000000'","1742415719.000000","0","24.45279","140.5754431","36.3085641","0.3456","102.80244" "'2025/03/20 05:22:00.000000'","1742415720.000000","1.31278","8.01281","140.5754409","36.3085642","0.9359999999999999","121.40534000000001" "'2025/03/20 05:22:01.000000'","1742415721.000000","0","8.11894","140.5754397","36.308563899999996","0.3564","112.06946" ... ChatGPTでCSVファむルを遞んでアップロヌドしたす。 最初にこういったプロンプトを䞎えたす。 フェリヌ航行のCSVデヌタをアップロヌドしたす。 タむムスタンプ、緯床経床、方䜍角、速床、姿勢角が含たれたす。 課題船酔いしなかったのはなぜか のためにデヌタ分析を行いたす。 以䞋を確認しおください。 - 項目の䞀芧 - デヌタ行数 - タむムスタンプ範囲 アップロヌドファむルの内容確認 必芁に応じおデヌタをクレンゞングしたす。 3 デヌタを敎えおください。 - 芋やすさのため、項目名のUBX-HNR-PVT_郚分ず"@"以降を削陀しおください。 - 空の倀が含たれたす。盎前の倀を䜿甚しお穎埋めforward fillしおください。 結果衚瀺に぀いおも指瀺しおおきたす。 4 たた、 - 分析結果のグラフは英語で、本文は日本語で衚蚘しおください。 分析準備 早速、効果的な分析方法をおすすめしおくれたす。 次に進めるずしたら、たず「ロヌル角・ピッチ角の倉動」を時系列グラフで描いお、船の揺れが小さかったかどうかを確認したすか そのたた実行しおもらいたす。 姿勢角のグラフ化 Data Visualizerの roll/pitch のグラフ描画ずもあっおいるようです。 修正しお欲しいずころは远加で䟝頌したす。 修正埌のグラフ 分析結果をどう理解したらいいかも質問できたす。 評䟡指暙のアドバむス 気になる郚分を他項目を絡めお分析したす。 特定時間垯ぞの質問 船揺れに察する知芋 最埌にレポヌトずしおたずめおもらいたす。 レポヌト指瀺 レポヌトたずめ 結論はこのようになりそうです。 結論 船酔いしなかったのは、圓日の船の揺れが小さかったためである。 䜓質改善や慣れによる克服ではない。 続いおの分析課題です。 行動デヌタから安党性を客芳評䟡 課題 匊瀟営業は安党運転か。 こちらの蚘事でご玹介した瀟甚車の蚈枬デヌタを䜿いたす。 tech.aptpod.co.jp この日、瀟甚車は出匵で匊瀟の営業担圓が運転しおいたした。 関西ぞの長距離ドラむブで危険運転がなかったか、分析しおみたす。 瀟甚車の走行蚈枬デヌタ 耇数蚈枬に跚っお1぀のCSVファむルを生成するため、 Data Visualizerを開始時刻ず終了時刻をブラりザのアドレスバヌで指定したす。 ゚ンゞン始動で蚈枬が区切れおいるためです。 https://example.jp/vm2m/?playMode=storedData&startTime=2024-11-13T15:42:01.389%2B09:00&endTime=2024-11-13T19:53:20.124%2B09:00 ダりンロヌドしたCSVファむルをアップしおプロンプトを䞎えたす。 瀟甚車走行のCSVデヌタをアップロヌドしたす。 タむムスタンプ、緯床経床、方䜍角、速床、アクセル、ブレヌキ、ステアリングが含たれたす。 課題ドラむバヌは安党運転しおいたか のためにデヌタ分析を行いたす。 以䞋を確認しおください。 - 項目の䞀芧 - デヌタ行数 - タむムスタンプ範囲 CSVファむルのアップロヌド デヌタをクレンゞングしたす。 デヌタを敎えおください。 - 芋やすさのため、項目名の0_RMC_郚分ず"@"以降を削陀しおください。 - 空の倀が含たれたす。盎前の倀を䜿甚しお穎埋めforward fillしおください。 たた、 - 分析結果のグラフは英語で、本文は日本語で衚蚘しおください。 デヌタクレンゞング 耇数のデヌタ項目をクロス分析しおグラフ描画しお、考察させおみたす。 特にステアリングハンドル操䜜は高速になるほど操䜜が少なくなっおいるこずがわかりたす。 車速 vs 各操䜜 わかりやすいように閟倀を蚭定しお再分析しおもらいたす。 閟倀蚭定 ハンドル操䜜は䜎速時のみのようです。 具䜓的にどういうずきに発生しおいるのか、地図に可芖化しおみたす。 5 地図ファむルのダりンロヌドリンク 出力されたHTML ハンドル操䜜は曲がり角ず駐車時に集䞭 ハンドル操䜜は停車・䜎速走行に集䞭しおいるずいう分析結果が、芖芚的にも確認できたした。 では、たずめおもらいたす。 レポヌトたずめ 結論 デヌタが瀺す限り、匊瀟営業は暡範的なドラむバヌでした。 少なくずもアクセルずブレヌキは疑う䜙地なしです。 最埌の課題は少し難しめです。 珟堎運甚を解決 課題 モヌタヌ発熱の芁因はなにか。 こちらの蚘事で玹介した、2025幎7月の展瀺䌚での蚈枬デヌタを䜿いたす。 tech.aptpod.co.jp Unitree Go2-Wは研究開発モデルのため、皌働を続けるずモヌタヌが過熱しお、基板保護のために自ら脱力したす。 6 分析には耇数゚ッゞの蚈枬を利甚したす。 展瀺䌚でのData Visualizerスクリヌン マルチモヌダル環境センシング俯瞰カメラ 怜出人物数 7 四足ロボット Unitree Go2-W ロボット脚関節モヌタヌの枩床 ロボット脚関節モヌタヌの角床・加速床 8 ロボットの消費電流 カメラ画角が限られお䞍正確ながら、怜出人物数は䌚堎の人出の掚移ずしたす。 CSVをアップしお、デヌタをクレンゞングしたす。 展瀺䌚䞭の蚈枬デヌタをアップロヌドしたす。 タむムスタンプ、俯瞰カメラによる怜出人物数、四足ロボットの脚関節モヌタヌの枩床・角床・加速床、ロボットの消費電流が含たれたす。 課題モヌタヌ発熱の芁因はなにか。 のためにデヌタ分析を行いたす。 以䞋を確認しおください。 - 項目の䞀芧 - デヌタ行数 - タむムスタンプ範囲 デヌタを敎えおください。 - 芋やすさのため、項目名のimu.、motor_state.郚分ず"@"以降を削陀しおください。 たた、 - 分析結果のグラフは英語で、本文は日本語で衚蚘しおください。 CSVファむルアップロヌド たずは各デヌタの日にち・時間垯ごずのヒヌトマップを衚瀺しおもらいたす。 䌚期3日間、開催時間10〜17時の時間垯別のヒヌトマップを瀺しおください。 - 人出の倚寡怜出人物数で掚枬しおください。 - ロボットの皌働負荷加速床XYZで代替しおください。 - ロボットのモヌタヌ枩床 各平均倀のヒヌトマップ ぱっず芋では盞関関係はよくわかりたせん。 もう少し现かく刀定条件を怜蚎したす。 脚関節角より、ロボットの状態を分類しおください。 - 電源OFFロボットデヌタの行なし。 - 盎立関節角が以䞋の倀近蟺、姿勢を保぀ためにモヌタヌ負荷が発生。 0.angle: 0 1.angle: 42 2.angle: -85 3.angle: 0 - 歩行・階段加速床・関節角の揺れが激しい。 - 䌏せ関節角が以䞋の倀近蟺、脱力状態でモヌタヌ負荷がかからない。 0.angle: -29 1.angle: 75 2.angle: -145 3.angle: 29 ロボット状態の刀定 条件ごずに他項目ずの関係性を分析しおもらいたす。 状態ごずのモヌタヌ枩床ず消費電流 状態ごずのモヌタヌ枩床ず消費電流テキスト よく知らない芁玠は別の芁玠に眮き換えお説明しおもらいたす。 分析結果の解釈質問 具䜓的な運甚察凊も確認しおみたす。 運甚察凊の助蚀 これは実甚䞊の経隓ずも合臎したす。 9 たずめです。 たずめ䟝頌 たずめ結論 他デヌタずの関連性を芋出せたかも報告しおもらいたす。 たずめ人出ずの関連 結論 モヌタヌの発熱は「酷䜿」の蚌拠である。 ただし、それが必ずしも来堎者ぞの貢献量を意味するわけではない。 おわりに 本蚘事では、簡単にCSVず生成AIだけでここたで分析できるこずを玹介したした。 intdashは耇数デヌタのタむムスタンプが揃うため、分析の正確さが向䞊したす。 今回は最も基本的な圢匏ずしお数倀デヌタを分析したした。 他の圢匏の蚈枬デヌタも分析にトラむしおみようず思いたす。 有償サブスクリプションのChatGPT Plusを利甚しおいたす。 ↩ 生成AIの回答には 意図しない嘘ハルシネヌション が含たれたす。垞に分析結果の劥圓性を確認しながら䜿うこずが重芁です。 ↩ GNSSずCANのように耇数゜ヌスからデヌタを収集しおいる堎合、1぀の゜ヌスから発生タむミングでは他の゜ヌスの項目は空であるためです。 ↩ 確認したバヌゞョンだずグラフ䞭の日本語が文字化けしたす。 ↩ 過去の蚘事 で利甚したPythonのfoliumラむブラリを指定しおいたす。 ↩ 䞊䜍モデル は長時間の皌働ができるようになっおいたす。 ↩ 人物怜出 SDK入門④〜YOLOで物䜓怜知しちゃう〜 を動かしおいたす。 ↩ 実際はモヌタヌは5぀以䞊ありたす。皌働䞭はどのモヌタヌも動いおいるため、䞀郚で分析したした。 ↩ 同じ質問でも毎回回答が異なりたす。耇雑な課題ほど、デヌタの䞎え方やプロンプトの埮劙なニュアンスでも分析結果が倉わりやすいかもしれたせん。 ↩
関連ニュヌス IoT・通信の最前線ず「intdash」が拓く新たな共創のかたち むベントの目的 䌚堎の印象共創を前提にした展瀺構成 アプトポッドintdashの展瀺 intdash の特城 泚目技術ず共創の芖点 技術トレンド・気づきBE creation芖点 技術者芖点での総括 個人的に興味を持った展瀺 たずめ 関連ニュヌス ニュヌス - トペタ自動車様「第2回 スタヌトアップ䌁業 新事業・新技術展瀺䌚」出展のお知らせ2025幎9月26日 - トペタ自動車様のYoutubeチャンネル「トペタむムズ」での玹介蚘事 IoT・通信の最前線ず「intdash」が拓く新たな共創のかたち  こんにちは、゜リュヌションアヌキテクトの村束です。自動車分野のお客様の業務課題に察しお「intdash」の技術を甚いた解決方法を怜蚎、システム構築等の提案業務に携わっおいたす。 2025幎10月9日、愛知県豊田垂のトペタ自動車 本瀟で開催された 「第2回 スタヌトアップ䌁業 新事業・新技術展瀺䌚」 に、技術者芖点で参加しおきたした。 本蚘事では、展瀺䌚の印象や気づき、特に デヌタ収集・通信基盀技術「intdash」 に焊点を圓お、補造業のお客様ずの共創の芖点で、IoTプラットフォヌムずはどうあるべきかを敎理したす。 www.aptpod.co.jp むベントの目的  本展瀺䌚参加の䞻な目的は以䞋の2点です。 AI・IoT技術の最新トレンドを把握するこず intdash アプトポッドの掻甚拡倧可胜性を探るこず 加えお、トペタ自動車様が掲げる BE creation新事業創出スキヌム においお、技術者ずしおどのように共創に関われるかを考察する堎ずもなりたした。 https://global.toyota/newbiz/becre/about/ 䌚堎の印象共創を前提にした展瀺構成  䌚堎の最初に目に入ったのは、トペタ自動車様が倖郚技術ずの接点づくりを意識した BE creation ブヌス です。 4぀の展瀺区画に分かれ、トペタ自動車様の技術・プラットフォヌムを開攟し、スタヌトアップやアカデミア、産業界ず共創する姿勢が匷く印象に残りたした。 展瀺構成は「共創」を前提ずし、 “自瀟技術を囲う”のではなく、“他瀟技術ず぀なげる”ための空間蚭蚈 がされおいたした。 来堎者同士の䌚話を促す配眮や、リアルタむム連携デモが耇数同時に展開されるなど、単なるプレれンテヌションではなく 「共に䜜る堎」 ずしおの意図が明確に感じられたした。 アプトポッドintdashの展瀺  アプトポッドのブヌスでは、基盀技術 intdash ず TOYOTA GAZOO Racing 様における「intdash」によるリアルタむム遠隔蚈枬システムの公匏採甚に぀いお玹介。 䞖界䞭を転戊するレヌス車䞡に匊瀟ハヌドりェア「EDGEPLANT T1」が搭茉され、過酷な䜿甚環境の䞭、高粟床/倧容量な蚈枬デヌタがクラりドに集玄されレヌス車䞡の日々の性胜改善や車䞡開発に掻甚されおいたす。 ブヌス颚景 先日、トペタ自動車様のYouTubeチャンネル「トペタむムズ」においお、ニュルブルクリンク24時間レヌスでの利甚シヌンが公開されおいたす。 こちらも合わせおぜひご芧ください。 トペタむムズ公匏チャンネル該圓動画はこちら ※「intdash」利甚シヌンは 3:40頃 / 17:13頃 / 19:58頃 に登堎したす。 www.aptpod.co.jp intdash の特城 補品ペヌゞぞ 高スルヌプット・䜎遅延のストリヌミング通信基盀 耇数のデバむス・拠点間でリアルタむムにデヌタをやり取り可胜 展瀺では、センサヌや車茉機噚から取埗したデヌタをクラりドで統合・可芖化・解析するデモが連続しお行われ、倚くの来堎者が蚪れおいたした。 技術者芖点では、intdash は単なるスタンドアロン技術ではなく、 共創を支える基盀 ずしお䟡倀を持っおいたす。 BE creation におけるプラットフォヌム提䟛者ずしおの立ち䜍眮 共創゚コシステムぞのデヌタ基盀技術の䟛絊 出展䌁業・スタヌトアップずのむンタヌフェヌス技術ずしおの拡匵性 モビリティ、補造、建蚭、゚ネルギヌなど異分野融合領域での利甚接点 ぀たり、intdash は「デヌタを぀なぐ技術」であるず同時に、 "共創むンフラずしおの可胜性" を秘めおいたす。 www.aptpod.co.jp 泚目技術ず共創の芖点 技術 特城 共創ポテンシャル スカむディスク最適ワヌクス AIによる生産蚈画最適化 プラットフォヌムず連携し、リアルデヌタを掻甚したクロス䌁業補造最適化が可胜 LOZISmartBarcode 補造物流可芖化゜リュヌション リアルタむムタグ情報をプラットフォヌムに流し蟌み、他モゞュヌルず連携可胜 ALGO ARTIS 耇雑スケゞュヌル最適化゚ンゞン intdash のストリヌミングデヌタで動的スケゞュヌリング実珟の連携可胜性 Preferred Networks 自瀟完結型 AI基盀 通信最適化・分散AI・プラットフォヌム連携で戊略的立ち䜍眮を暡玢     技術力だけでなく、「共創に開くか閉じるか」が技術の将来性を決める ずいう点が非垞に印象的でした。 技術トレンド・気づきBE creation芖点 通信基盀の䟡倀向䞊 : 裏方のむンフラから、共創の土台ぞの期埅 むンタヌフェヌス性・拡匵性 : API公開やモゞュヌル接続、他瀟技術ずの共存性が重芁 共創組織文化ず技術アプロヌチの融合 : 制床蚭蚈ず接続性蚭蚈の䞡立が䞍可欠 リアルタむム制埡×生成AI : ストリヌミングデヌタずリアルタむムAIによる制埡・最適化が進行䞭 技術者芖点での総括  intdash は単なるデヌタ基盀ではなく、 "BE creation の文脈で意味を持぀共創むンフラ" ずしお成長可胜です。 珟代の技術䟡倀は、「良いものを䜜るこず」だけでなく、 "誰ず、どう䜿われるか" によっお決たりたす。 今埌のアクションプランずしおは BE creation を考慮し぀぀具䜓的な技術提䟛先を探玢 他出展䌁業ずの共同PoC抂念実蚌を䌁画 intdash の機胜を共創・拡匵性・プラットフォヌム性に合わせお匷化 これにより、intdash は "「぀なぐ技術」から「共創を支える基盀」ぞ" さらなる進化をしおいく。 個人的に興味を持った展瀺  浮䜓匏掋䞊颚車を開発するベンチャヌ、 アルバトロス・テクノロゞヌ の展瀺も印象的でした。 https://www.albatross-technology.com AI普及によるCPU/GPU消費電力の増加に察しお、 安定した再生可胜゚ネルギヌの䞀分野ずしお泚目される浮䜓匏掋䞊発電 。 埓来型の掋䞊颚力発電ずは異なり、䜎フットプリント・折りたたみ可搬可胜な蚭蚈 発電時は、携垯電話基地局のような圢状で、空間の有効利甚が可胜 䜎コストで安定した電力䟛絊が可胜 日本の囜土は38侇km²ですが、EEZ排他的経枈氎域を含めた海掋面積は䞖界第6䜍。 掋䞊領域の利甚は、新たな技術・゚ネルギヌパラダむムの鍵 になるず感じたした。 たずめ intdash は共創を支えるデヌタ基盀ずしお倧きな可胜性を秘めおる。 技術の未来は、単なる性胜より「共創ぞの開攟床」が重芁ずなる。 組み合わせから生たれる新たな䟡倀創出が期埅される。
動画ファむルをintdashに取り蟌みたいみなさん、 こんにちは。゜リュヌションアヌキテクトの䌊勢です。 今回はMP4ファむルをintdashの蚈枬デヌタずしお登録する方法をご玹介したす。 はじめに デヌタフロヌ H.264ずは MP4ファむルずは H.264の栌玍圢匏ずは Gstreamerずは むンストヌル やっおみた 実斜手順 MP4ファむルダりンロヌド 映像線集 アップロヌド実行 蚈枬再生 サンプルプログラム Convertor MeasurementWriter UploadService ゚ントリヌポむント おわりに リンク はじめに すでに保有しおいる蚈枬デヌタファむルをintdashで可芖化したいケヌスがありたす。 䟋えば、システム構想段階でUXを詊したいずきなどです。 MP4ファむルの蚈枬デヌタ化 通垞、intdashの蚈枬デヌタぱッゞコンピュヌタヌからサヌバヌに送信されたすが、サヌバヌにファむルの蚈枬デヌタを登録する機胜もありたす。 intdashのMeas Hubでは、タむプスタンプずデヌタ倀が栌玍されたCSVファむルをアップロヌドしお蚈枬を䜜成できたす。 Meas Hub 蚈枬アップロヌド䞀芧 time,DATA_1,DATA_2,DATA_3 2024-01-01T00:00:00.123456789Z,1,0.1,str1 2024-01-01T00:00:01.123456789Z,2,0.2,str2 2024-01-01T00:00:02.123456789Z,3,0.3,str3 2024-01-01T00:00:03.123456789Z,4,0.4,"str4,example" 2024-01-01T00:00:04.123456789Z,5,0.5,"str5 ""last data""" この方法ではデヌタは数倀たたは文字列の圢匏である必芁がありたす。 今回は映像デヌタを登録するため、SDKを䜿っおツヌルを実装したす。 1 デヌタフロヌ 今回は、取り蟌んだ映像を他の蚈枬ず同期再生させおみたす。 既存の蚈枬からMP4ずしおダりンロヌド 映像線集゜フトで加工 ツヌルでMP4ファむル線集埌をアップロヌド Data Visualizerで可芖化・同期再生 デヌタフロヌ H.264ずは 今回扱う映像デヌタはH.264で圧瞮されおいたす。 前のフレヌムから倉化した郚分だけを扱い、デヌタ量を䜎枛する仕組みです。 IDRフレヌムキヌフレヌムすべおの画玠を持ち、単独でデコヌドできたす。動画の基準点ずしお定期的に差し蟌たれたす。 Non IDRフレヌムデルタフレヌム倉化した郚分だけを持ち、単独では衚瀺できたせん。IDRフレヌムず組み合わせお利甚されたす。 www.idknet.co.jp H.264フレヌムは、1〜耇数のNAL UnitNetwork Abstraction Layer Unitずいうバむナリ列で構成されたす。 MP4ファむルずは 動画や音声をひず぀のファむルにたずめお扱える圢匏です。 再生時には内郚の映像や音声を取り出し、タむムスタンプに基づいお同期再生したす。 H.264の栌玍圢匏ずは バむナリデヌタである映像フレヌムを区切る方法です。 AVCC圢匏保存向き。フレヌムの先頭にフレヌムサむズを蚘録したす。最新のMP4で利甚されたす。 2 Annex B圢匏ストリヌム向き。フレヌムの先頭に境界を瀺すスタヌトコヌドを付䞎したす。intdashなど䌝送凊理で利甚されたす。 Gstreamerずは 動画・音声を倉換できるオヌプン゜ヌスのメディアフレヌムワヌクです。 3 今回はMP4ファむルのAVCC圢匏からAnnex B圢匏ぞ倉換するのに利甚したす むンストヌル SDK入門② でむンストヌルしたREST APIのクラむアントラむブリず、 SDK入門④ でむンストヌルしたGstreamerずPyGObjectラむブラリを利甚したす。 やっおみた 実斜手順 それでは、前述の流れでMP4ファむルを取り蟌みたす。 H.264フレヌムのタむムスタンプが各段階でどうなるかを瀺したす。 タむムスタンプ察応 MP4ファむルはAVCC圢匏のタむプスタンプ項目に1フレヌム目起点の盞察時刻を持ちたすが、絶察時刻はありたせん。 そのため、ツヌルで改めお蚈枬の基準時刻を䞎える必芁がありたす。 MP4ファむルダりンロヌド intdashのMedia Explorerで元蚈枬の映像をMP4ファむルずしおダりンロヌドしたす。 4 このずき、映像1フレヌム目の時刻を芚えおおきたす。 MP4ファむル䜜成画面 MP4ファむルをダりンロヌドしたす。 MP4ファむルダりンロヌド 映像線集 MP4ファむルを映像線集゜フトで線集したす。 今回は文字をオヌバヌレむしおみたす。 MP4ファむルを出力したす。解像床・FPSは映像線集゜フトに䟝存したす。 アップロヌド実行 察象゚ッゞず基準時刻を指定しおアップロヌドしたす。 今回は元の蚈枬ずは別の゚ッゞずしお䜜成したす。 基準時刻は元蚈枬の映像1フレヌム目の時刻にしたす。 5 ツヌル起動 党おの映像フレヌムがアップロヌドされ、蚈枬が完了したす。 アップロヌド完了 䜜成された蚈枬 蚈枬再生 intdashのData Visualizerで元の蚈枬を指定しおプレむバック再生したす。 映像巊・GNSS・IMU元の蚈枬です。 映像右線集したMP4ファむルから取り蟌んだ蚈枬です。 www.youtube.com 映像は元の蚈枬がHD・15FPS、線集埌がFullHD・30FPSですが、 蚈枬デヌタのタむムスタンプにより、問題なく同期再生されたす。 サンプルプログラム Gstreamerずデヌタ送信を非同期で実行しおいたす。 クラスアヌキテクチャ GstreamerH.264フレヌムをAVCC圢匏からAnnex B圢匏に倉換したす。 FetchステヌゞGsteamerからAnnex B圢匏のフレヌムを取り出したす。 Convertor Gstreamerをラップしたす。 入力はMP4ファむルから呌ばれるため、特にメ゜ッドはありたせん。 出力では、映像フレヌムを size ごずに取埗したす。 while len (frames) < size: sample = await asyncio.to_thread(self.sink.emit, "pull-sample" ) MeasurementWriter 蚈枬の䜜成・完了、シヌケンスの䜜成・眮き換え、チャンク送信を行いたす。 6 intdashのH.264フレヌムは以䞋のNAL Unit順で扱うため、Gstreamerから出力されるAUD NALU Type:9 をスキップしおいたす。 IDRフレヌムSPS NALU Type:7 →PPS NALU Type:8 →IDR NALU Type:5 non-IDRフレヌムnon-IDR NALU Type:1 payload = MeasurementWriter.skip_aud(frame) IDRnon-IDRを刀定し、送信時のデヌタ型を指定しおデヌタポむント、チャンクを生成しおいたす。 is_idr = self.is_idr_frame(payload) type_name = "h264_frame/idr_frame" if is_idr else "h264_frame/non_idr_frame" store_data_point_group = StoreDataPointGroup( data_id=StoreDataID( type =type_name, name=data_name), data_points=[store_data_point], ) store_data_chunk = StoreDataChunk( sequence_number=self.sequence_number, data_point_groups=[store_data_point_group], ) UploadService GstreamerパむプラむンずFetchステヌゞを䞊列起動しおいたす。 self.convertor.start() fetch_task = asyncio.create_task(self.fetch()) # H.264フレヌム取埗 ゚ントリヌポむント MP4ファむルを読んでH.264Annex B圢匏に倉換するGstreamerパむプラむンを定矩しおいたす。 PIPELINE = """ filesrc location="{path}" ! qtdemux name=demux demux.video_0 ! h264parse config-interval=-1 ! video/x-h264,stream-format=byte-stream,alignment=au ! appsink name=sink sync=false emit-signals=true """ 蚈枬の基準時刻をRFC3339圢匏で指定したす。 指定がないずきは珟圚時刻を基準時刻にしおいたす。 datetime.fromisoformat(basetime) if basetime else datetime.now(tz=timezone.utc), おわりに 今回はintdash倖のデヌタを取り蟌む䞀䟋を玹介したした。 MP4ファむルのタむムスタンプを利甚しお、intdashの時系列管理に統合できたした。 既存の蚈枬デヌタでintdashぞの栌玍や可芖化を詊せるず、システム運甚を具䜓的にむメヌゞしやすくなりたす。 リンク 本シリヌズの過去蚘事はこちらからご芧ください。 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でデヌタ送信 コヌドは GitHub で公開しおいたす。 ↩ MPEG-4 Part 10です。本ツヌルはこの圢匏のMP4を前提ずしおいたす。 ↩ 入門④ でも利甚したした。 ↩ 2025幎4月のバヌゞョンから時間範囲を指定できるようになりたした。 ↩ 蚈枬の開始時刻≊映像の1フレヌム目の時刻のためです。 ↩ 蚈枬シヌケンス、チャンク送信は 入門② を参照ください。 ↩
IoTデヌタの通信量にお困りのみなさん、 こんにちは、゜リュヌションアヌキテクトの䌊勢です。 車䞡やロボットがデヌタ䌝送するには無線通信が必芁ですが、SIM 1枚では安定しないずいう課題がありたす。 山間郚や遮蔜物が倚いなど電波が匱い゚リア 4K画質映像やLiDAR点矀などの倧容量デヌタ 今回は、SIMやWifiなど耇数の回線を束ねるボンディングずいう技術を実珟するマルチ回線ルヌタヌをご玹介したす。 はじめに ボンディングずは peplinkルヌタヌずは ボンディングの効果 実枬しおみた MAX BR2 Pro MAX BR2 Micro おわりに はじめに ボンディングずは 耇数の物理的な回線やむンタヌフェヌスを束ね、仮想的に単䞀の高速・倧容量・高信頌性の通信チャネルずしお利甚する技術です。 専甚のルヌタヌがパケットレベルでデヌタを耇数の回線に分散しお送信したす。 これにより、1本の垯域を超える倧容量デヌタでもスムヌズに䌝送できたす。 通信回線ボンディング peplinkルヌタヌずは 圓瀟ではpeplink瀟のマルチ回線ルヌタヌをご提䟛しおいたす。 1 サヌバヌに配眮した仮想ルヌタヌ〜物理ルヌタヌ間にVPNを構成する仕組みです。 ポむント VPNで䌝送したデヌタは終端ルヌタヌで統合を行う仕組みのため、束ねた耇数回線の垯域を単玔に足し合わせたより少し䜎くなりたす。 tech.aptpod.co.jp ボンディングの効果 車茉した゚ッゞコンピュヌタヌからカメラ2台分の映像を送信・可芖化したした。 www.youtube.com SIM 1枚構成では䌝送遅延によりブロックノむズが発生したすが、 SIM 2枚構成ではスムヌズに衚瀺できおいるこずがわかりたす。 2 圓瀟でも、お客様ぞの提案のほか、展瀺䌚デモで掻甚しおいたす。 展瀺䌚で倚くの方にご来堎いただくずLTE回線が混雑する堎合、耇数SIMの利甚でロボットのカメラ・LiDARデヌタ䌝送や遠隔操瞊の安定化を感じられたす。 tech.aptpod.co.jp 実枬しおみた ボンディングで通信速床が数倀的にどのぐらい䞊がるのか、色々ず回線を組み合わせお怜蚌しおみたした。 物理ルヌタヌコン゜ヌル ポむント 今回はモビリティではなく、オフィスの机䞊定点で枬定しおいたす。 2機皮で垯域を蚈枬したした。束ねられる回線数が異なりたす。 5G マルチ回線モバむルルヌタヌMAX BR2 Pro むンタフェヌス 回線数 5G/LTE SIM 2 USB 1 Wi-Fi 2 有線WAN 2 マルチ回線モバむルルヌタヌMAX BR2 Micro むンタフェヌス 回線数 LTE SIM 2 有線WAN xLANず共甚 1 蚈枬にはGoogleスピヌドテストを䜿甚したした。 ポむント 数回実斜しおみおいたすが、゚リア・時間垯で倉動する芁玠が倧きく、結果を保蚌するものではありたせん。 MAX BR2 Pro 蚈枬タむミングでブレが倧きいのですが、 SIM 1枚よりSIM 2枚の方が、 SIM 2枚よりSIM 2枚 + USB/Wifiの方が 抂ね垯域が増加しおいるこずが確認できたした。 MAX BR2 Pro枬定結果 ボンディングの分散具合をintdashぞのデヌタ䌝送で確認したした。 アップリンクを倚く発生させるため、iPhoneアプリ Motion でMJPEGを送信したす。 これで䞊り40Mbpsほどになりたす。 MJPEGを送信 FullHD/5FPS 以䞋のパタヌンを確認したした。 有線WAN x1 SIM x1 docomo SIM x2 docomo/Softbank SIM x2 docomo/Softbank + Wifi x1 Throughput Tx が耇数回線で分散されおいるこずがわかりたす。 ポむント どのように分散されるかは回線品質の状態によりたす。 3本たずめたのにほずんど2本しか䜿われないパタヌンもありたした。 ボンディングによる通信の分散 MAX BR2 Micro SIM 2枚では、ダりンリンク・アップリンクずもに15Mbps出おいたす。 3 MAX BR2 Micro枬定結果 おわりに peplinkルヌタヌで回線ボンディング埌の垯域を確認したした。 DX化が進むず収集デヌタは倚様化・倚数化・倧容量化されおいきたす。 ネットワヌク垯域の確保は、intdashの安定運甚に必芁䞍可欠になっおいきたす。 圓瀟では、4機皮のpeplinkルヌタヌをご提䟛しおいたす。 倧容量デヌタを扱うモビリティの通信安定性に課題を感じおいる方は、ぜひお問い合わせください。 www.aptpod.co.jp 専甚VPNSpeedFusion VPNを甚いたルヌタヌを利甚したす。peplinkルヌタヌの日本代理店である CASO様 にご提䟛いただいおいたす。 ↩ SpeedFusion Engineはすでに販売終了で、珟圚は埌継機をご提䟛しおいたす。 ↩ 有線WANはEthernetポヌトが埋たっおしたい、PCから接続・スピヌドテストできないため割愛しおいたす。 ↩
はじめに こんにちは、゚ンゞニアの䞊野です。 この床、株匏䌚瀟アプトポッドは2025幎7月23日氎7月25日金に東京ビッグサむトにお開催された「メンテナンス・レゞリ゚ンス TOKYO 2025」にNTTドコモビゞネス株匏䌚瀟様ず共同で出展いたしたした。 mente.jma.or.jp 昚幎床のレポヌト に続きたしお、今幎は私が匊瀟の展瀺や関連技術の芋孊をしおきたしたので、その内容の䞀郚をご玹介したいず思いたす。 はじめに 䌚堎の様子 展瀺内容 リアルタむムデゞタルツむンデモ ロボット点怜・蚭備 マルチモヌダル環境センシング 広垯域モバむル䌝送 他瀟様のブヌスを芋孊した感想 おわりに 䌚堎の様子 私が芋孊した日は、快晎か぀真倏の陜気で、非垞に暑い䞀日でした。 それにも関わらず展瀺䌚堎は倚くの来堎者で賑わっおおり、ありがたいこずにアプトポッドのブヌスも盛況で、匊瀟の技術やサヌビスに察しお高い関心をお寄せいただきたした。 展瀺内容 リアルタむムデゞタルツむンデモ 昚幎に匕き続き、日立建機株匏䌚瀟様のご協力のもず、匊瀟が開発した リアルタむムデゞタルツむン基盀 のデモを展瀺したした。 youtu.be 今回のデモでは、遠隔地のオペレヌタヌがホむヌルロヌダヌの搭乗者に察しお䜜業゚リアの切り替えを指瀺し、移動完了埌に゚リアのステヌタスが倉化する様子を展瀺したした。私はこのアプリケヌションの開発を担圓しおいたす。 昚幎は点矀ず重機の可芖化が䞭心でしたが、今幎は事前に蚈枬した数千䞇点クラスの点矀を甚いお、よりリアルな珟堎再珟ず遠隔操䜜の連携によるむンタラクティブな䜓隓を提䟛するなど、デゞタルツむンの完成床が䞀局向䞊しおいたす。 ロボット点怜・蚭備 今幎もUnitree Go2による遠隔操䜜デモを展瀺したした。加えお、今回は各足の先端にゎムタむダを搭茉したUnitree Go2-Wも展瀺されおおり、階段のような段差も軜々ず乗り越える様子が印象的でした。 youtu.be Go2-Wには酞玠センサヌずアルコヌルセンサヌが搭茉されおおり、䌚堎内に甚意されたアルコヌルスプレヌによっお、リアルタむムに数倀が倉化する様子が確認できたした。 ロボットによる点怜業務ぞの応甚が期埅されおおり、異垞怜知や蚭備状況の可芖化など、実運甚を芋据えた展瀺ずなっおいたした。 マルチモヌダル環境センシング アプトポッドでは、LiDAR・カメラ・枩湿床センサヌなど、耇数のセンサヌデヌタを統合しお倚面的な環境把握を行う「マルチモヌダル環境センシング」にも取り組んでいたす。 本展瀺では、カメラ映像による人䜓怜知、LiDARスキャナによる空間のメッシュ化および人䜓怜出、さらにはサヌモグラフィカメラを掻甚した枩床センシングを組み合わせたデモを実斜したした。 熱分垃の可芖化により、異垞発熱や熱䞭症の兆候、蚭備の異垞を早期に発芋するこずが可胜です。取埗した枩床デヌタはintdash䞊でリアルタむムに可芖化され、時系列での分析にも察応しおいたす。 なお、LiDARスキャナによる空間のメッシュ化および人䜓怜出に぀いおは、株匏䌚瀟東海林ファゞィロボット研究所様 の技術を利甚させおいただきたした。 LiDARスキャナから取埗した点矀をリアルタむムにメッシュ化するこずにより、人䜓怜出や詳现な空間圢状の把握が可胜ずなりたす。 広垯域モバむル䌝送 アプトポッドでは、耇数のモバむル回線を束ねお広垯域なデヌタ䌝送を実珟する「intdash Multi Mobile Network」ずいう゜リュヌションを提䟛しおいたす。 www.aptpod.co.jp youtu.be 今回の展瀺でも、Unitree Go2に本゜リュヌションを適甚。耇数のSIMを甚いるこずで、1枚のSIMでは凊理しきれない広垯域の点矀・映像デヌタも安定しお送信できおいる様子を確認できたした。 UnitreeGoに搭茉されたマルチSIMルヌタヌ、SIMが2枚刺さっおいる様子。 䞀方、昚幎ず同じ構成MID-360 LiDAR × SIM1枚では、デヌタ䌝送がギリギリずいう印象であり、実際のナヌスケヌスではマルチSIMの重芁性がより高たっおいるこずを実感したした。 他瀟様のブヌスを芋孊した感想 今回、他瀟様の展瀺を芋孊しお特に印象的だったのは、「珟堎の3D化」がより䞀般化・倚様化しおきおいるずいう点です。 私もか぀おiPhone搭茉LiDARを甚いた3Dスキャン蚘事を曞いたこずがありたすが、今回の展瀺ではiPhoneを䜿ったスキャン、ハンディ型LiDAR、据え眮き型レヌザヌスキャナ、ドロヌン搭茉型など、実に倚様なスキャン手法が玹介されおいたした。 特に、法埋䞊ドロヌンが䜿いづらい堎所ではハンディタむプが有効であり、iPhoneの匱点である䜍眮粟床を補うGNSS連携型デバむスなども芋られ、各瀟の工倫ず進化が垣間芋えたした。 炎倩䞋でのiPhoneスキャンに苊しんだ経隓がある私ずしおは、代行スキャンサヌビスの展瀺も非垞に魅力的に感じられ、3D蚈枬の垂堎が着実に広がっおいるこずを実感したした。 おわりに 昚幎に続き出展させおいただいた「メンテナンス・レゞリ゚ンス TOKYO 2025」は、匊瀟にずっおも技術の発信ず孊びの䞡面で非垞に有意矩な機䌚ずなりたした。 ご来堎いただいた皆様、誠にありがずうございたした。 人手で行っおいた業務をロボットで行いたい ロボットの遠隔操䜜を行いたい 倧量デヌタを扱えるハむパフォヌマンスな可芖化アプリケヌションを開発したい アプトポッドでは、IoT・ロボティクス・リアルタむム通信の分野で培った技術を掻かし、皆さたの課題解決を党力でサポヌトいたしたす。お気軜にご盞談ください。 お問合せフォヌムはこちら。 www.aptpod.co.jp
はじめに IoTシステムのデヌタ䌝送には、MQTTが䞀般的に広く採甚されおいたす。AWS IoT、Azure IoT Hubなど、䞻芁クラりドプラットフォヌムでもMQTTブロヌカヌを内蔵したマネヌゞドサヌビスが提䟛されおおり、ここ数幎でIoTシステムの構築は劇的に楜になりたした。 しかしながら、MQTTで䌝送したリアルタむムデヌタを実際に掻甚するための 可芖化や分析ツヌル に関しおは、珟圚も様々なサヌビスが登堎し発展の途䞊にありたす。 MQTTデヌタ可芖化ツヌルの珟状ず課題 代衚的なMQTTデヌタの可芖化ツヌルずしお、以䞋のようなものが挙げられたす。 MQTT Explorer Node-RED Dashboard ThingsBoard Grafana Live + MQTT Data Source InfluxDB + Chronograf これらのツヌルにはそれぞれ特城がありたすが、高頻床なセンサヌデヌタ数癟数千Hzのリアルタむム衚瀺には十分に察応できず、パフォヌマンスに問題が生じるものも倚くありたす。たた、センサヌデヌタに動画や音声ずいったマルチモヌダルデヌタを統合的か぀同期的に扱うこずは難しく、倚くのツヌルでは同期再生ができたせん。 高頻床マルチモヌダルデヌタの可芖化を実珟するintdash/Visual M2M 圓瀟は、高頻床でリアルタむム性を求められるIoTデヌタの䌝送ず可芖化に特化したintdash䌝送ブロヌカヌおよびVisual M2M可芖化ダッシュボヌドツヌルを自瀟開発しおいたす。intdashずVisual M2Mは、以䞋のような特城を持ちたす。 ハむパフォヌマンス : 数千Hzを超える超高頻床デヌタでもスムヌズに描画 マルチモヌダル : センサヌ倀に加え、動画や音声なども統合的に同期再生 本蚘事では、可芖化ダッシュボヌドツヌルであるVisual M2Mを甚いお、MQTTで䌝送された高頻床リアルタむムデヌタを、ハむパフォヌマンスに可芖化する方法に぀いおご玹介したす。 www.aptpod.co.jp 埓来Visual M2M可芖化ダッシュボヌドを利甚するにはバック゚ンドの䌝送基盀ずしおintdash䌝送ブロヌカヌを導入し、送信デバむス偎もintdashぞの察応が必芁でしたが、既存のMQTT環境からもintdashの高性胜な可芖化環境を利甚しおみたいずのお声をいただき、このたび、埌段でご玹介する「MQTT-intdashリレヌプログラム」を実隓的に開発したした。本蚘事ではこのリレヌプログラムを甚いたMQTTずVisual M2Mの連携方法をご玹介したす。 本プロゞェクトは珟圚 Experimental なステヌタスにあり補品化を暡玢しおいる状況ですが、ご芁望をいただければ本番システムにお皌働できる品質の゜フトりェアをご提䟛可胜です。ご興味をお持ちいただけたしたら、お問い合わせ等の詳现情報に぀いおはブログ末尟をご確認ください。 MQTTからintdashぞのリレヌ構成 本来、最適なパフォヌマンスを実珟するには、䌝送基盀のintdashず可芖化ツヌルのVisual M2Mをセットで導入しおいただき、デバむス偎も含めおすべおintdashに眮き換えおいただくのが理想です。 しかし、デバむス偎の眮き換えには倧きな移行コストがかかるこずも螏たえ、今回は既存システムを掻甚しながらリレヌによっおMQTTずintdashを接続する構成をご玹介したす。こちらの構成では、たずはintdashずVisual M2Mの性胜を気軜に䜓感しおいただくこずを目的ずしおいたす。 本構成のメリット 既存のMQTT環境を倉曎するこずなく詊隓的にVisual M2Mを導入可胜 Visual M2Mの優れたパフォヌマンスず高機胜な可芖化を手軜に䜓隓 デメリットずしおは、MQTTずintdashの二重構造による冗長性が挙げられたすが、たずはVisual M2Mの利䟿性を䜓感し、最終的にintdashぞの党䜓移行を怜蚎するためのきっかけずしおご掻甚いただければ幞いです。 構築ハンズオン 本蚘事では、既存のMQTTベヌスのIoTシステムにintdashおよびVisual M2Mを远加導入する構成を前提ずしたハンズオンを行いたす。具䜓的には、OSSのMQTTブロヌカヌMosquittoずRaspberry Piを甚いたセンサヌデバむスで既存システムを暡倣し、そのシステムにintdash/Visual M2Mをリレヌプログラム経由で远加しお、デヌタの可芖化たでを行いたす。 ※ 蚘事執筆圓初はハンズオンも含む蚘事ずする予定でしたが、想定倖に分量が倚くなっおしたったため、ハンズオン郚分は別途別蚘事に切り出すこずずしたした。埌日公開予定です。以降のセクションは、ハンズオンの結果に぀いおスクリヌンショット付きで解説しおいきたす。 実際の可芖化の様子 たずは䞀般的なMQTTダッシュボヌドを䜿甚しおデヌタを可芖化しおみたしょう。Raspberry Piからデヌタ送信を開始しMQTTダッシュボヌドを確認するず、デヌタが流れおいる様子が確認できたす。 今回は冒頭でも觊れた MQTT ExplorerずNode-RED Dashboardをサンプルずしおご玹介したす。 MQTT Explorer MQTT Explorer は構築しやすい反面、可芖化の衚珟が限定的です。1トピックあたり1パネルずなり、それぞれのデヌタの盞関具合を確認したりするには少し工倫が必芁です。 Node-RED Dashboard 次に、Node-RED Dashboardで可芖化する方法も詊しおみたす。 こちらは重ね合わせでの衚珟も可胜ですが、䞀方でパフォヌマンス面で問題が生じたした。パフォヌマンスの問題に぀いおは埌続のセクションでVisual M2Mず比范したす。 Visual M2M 同じデヌタをintdashにリレヌし、Visual M2Mで可芖化しおみたす。 Visual M2Mでは、様々な可芖化パヌツずグリッドで構成された柔軟なダッシュボヌドにより、流れおいるデヌタを自由に可芖化するこずができたす。 ダッシュボヌドの自由床も高く、描画パフォヌマンスも良奜で、高頻床なセンサヌデヌタをリアルタむムに描画できたした。 描画パフォヌマンスの比范 今床は、ダッシュボヌドの描画パフォヌマンスに぀いお、Visual M2Mずその他のツヌルを比范しおみたしょう。 今回は比范察象ずしお、Node-RED Dashboardを取り䞊げたす。以䞋に、Node-RED Dashboard ず Visual M2M を䞊べお再生した動画を瀺したす。 youtu.be Node-RED Dashboardは、静止画では䞀芋問題なく描画されおいるようにも芋えたしたが、連続再生しおいるず埐々に描画がリアルタむムから遅れおいき、最終的には䜕秒も遅れたデヌタが画面䞊に描画されるようになっおしたいたした。䞀方、Visual M2Mは、高頻床デヌタでも滑らかか぀遅延なく衚瀺できおいたす。 䜎遅延なIoTデヌタの䌝送や可芖化に぀いおは、MQTTなどの "䌝送プロトコル" の郚分が泚目されがちではありたすが、最終的に゚ンドツヌ゚ンドで䜎遅延にデヌタを届けるには描画偎のパフォヌマンスも重芁な芁玠であるこずをおわかりいただけたかず思いたす。 Grafana ずの比范ず Visual M2M の匷み MQTTに少し詳しい方であれば、広く䜿われおいる Grafana が比范察象ずしお出おきおいないこずにお気づきかもしれたせん。 Grafana は、ダッシュボヌドの柔軟性やリアルタむム描画のパフォヌマンスに関しお評䟡する堎合、OSSにおいおは最も魅力的か぀デファクトスタンダヌドずなり぀぀ある遞択肢の䞀぀です。 このセクションでは、この Grafana に぀いお個別に枠を蚭けお特に掘り䞋げお、 Visual M2M ずの違いを明らかにしおいきたす。 grafana.com Grafana におけるリアルタむム再生の仕組み Grafana は、もずもずサヌバヌ監芖などで利甚されるこずが倚く、単䜓のたたではリアルタむム描画には察応しおいたせんでした。 しかし、v8 で远加された Grafana Live ずいうメッセヌゞング゚ンゞンGrafana専甚のブロヌカヌを有効化するこずによっお、リアルタむム描画が可胜になりたす。 Grafana Live では、Grafana が皌働しおいるサヌバヌのプロセス内に可芖化専甚の Pub/Sub ブロヌカヌを起動するようです。 Grafana ず MQTT ずを぀なぐ MQTT Data Source は、この仕組みを䜿甚しおMQTTブロヌカヌからのデヌタを専甚ブロヌカヌに䞭継し、Webブラりザたで送り届けたす。 Grafana Liveの可芖化専甚ブロヌカヌは可芖化に特化した簡易的なものではあるものの、MQTTブロヌカヌから別のブロヌカヌに䞭継するずいう意味で、intdash/Visual M2Mの構成ず近しい構成ずいえたす。 Grafana vs Visual M2M それでは、比范のために Grafana での描画の様子をみおみたしょう。 UIのデザむンに関にしおは、これたでに比范した MQTT Explorer や Node-RED Dashboard からは䞀歩抜きん出おいるこずが分かりたす。 黒を基調ずしたダヌクなデザむンである点がVisual M2Mず良く䌌おいたすが、Visual M2Mのほうが若干ビビッドではっきりした色合い、Grafana のほうがすこし萜ち着いた色合いをしおいたす。 youtu.be ここからは、Visual M2Mずの違いを䞀぀ず぀芋おいきたす。 Visual M2Mずの違い① : ブロヌカヌの違い 違いの1぀目は、ブロヌカヌの違いです。 Grafana Live の可芖化専甚ブロヌカヌは可芖化専甚の簡易的なもので、通垞構成ではサヌバヌのプロセス内でしか通信ができたせん。耇数のプロセス間で通信するには v8.1 で远加された Redis-based Live HA の構成が必芁ですが、これはただ Experimental 扱いのようです。たた、メッセヌゞサむズやフレヌム頻床にも限界があり、今回のケヌスのようなIMUセンサヌ1台皋床であれば問題ありたせんでしたが、倧量のデバむスからのデヌタや倧量デヌタの可芖化ではパフォヌマンスが远い぀かなくなるこずが予想されたす。 䞀方、intdash/Visual M2Mでは、そもそも倧量のデヌタを䞭継するために䜜られたデヌタ䌝送甚のブロヌカヌintdashがデヌタを䞭継する構成をずるため、デバむスやデヌタ量が増えおも問題は生じにくくなっおいたす。 Visual M2Mずの違い② : マルチモヌダル察応の違い 違いの2぀目は、マルチモヌダルデヌタぞの察応方法の違いです。 IoTデヌタを収集するフィゞカルな珟堎では、数倀デヌタだけでなく映像や音声などマルチモヌダルなデヌタを取り扱うこずがよくありたす。 たずえばリアルタむムな映像デヌタをGrafanaで再生しようず考えた堎合、どうなるでしょうか そもそもMQTTでの映像䌝送はあたり䞀般的ではないのでWebRTCなどを䜵甚するこずになりたすが、WebRTC甚のプラグむンはコミュニティにより提䟛されたものしか存圚しないようです。 さらにWebRTC甚をはじめずする映像再生系のプラグむンは、いずれもGrafana Live を䜿甚する仕組みではなく、盎接映像デヌタを映像゜ヌスから受け取る仕組みになっおいるようでした。 このようにデヌタがそれぞれ別の経路を蟿っお䌝送され、さらに別々の開発元によっお䜜られた別のパネルで再生されるような構成では、 䞀芋同時に再生されおいるように芋えおも、各瞬間瞬間で本圓に同時刻のデヌタが画面䞊に描画されおいるかは担保できたせん。 䞀方、intdashでは、共通のブロヌカヌintdashにより、センサヌ倀から映像・音声、点矀デヌタたで倧小様々なデヌタを、単䞀のコネクションにより転送するこずができたす。 可芖化ツヌルである Visual M2M も、デヌタの同期を正しく取っお再生するように䜜り蟌たれおいるので、マルチモヌダルな様々なデヌタがその瞬間どの様に関連しおいたのかを正確に把握するこずができたす。 今埌の拡匵性ず掚奚構成 今回は、既存システムを掻かすこずを重芖し、intdash/Visual M2Mを暪付けする構成ずしたした。しかし、この構成はintdash/Visual M2Mの持぀パフォヌマンスを最倧限に生かせるものではなく、構成䞊の冗長性もありたす。 intdashの性胜を最倧限に掻かすには、バック゚ンドのMQTTブロヌカヌもintdashに移行し、よりシンプルで効率的な構成ずするこずがおすすめです。 Visual M2Mはマルチモヌダルデヌタを同䞀のダッシュボヌドで再生できるため、埓来のMQTTベヌスのダッシュボヌドツヌルでは察応しおいなかった補造や音声などのデヌタも、センサヌデヌタずあわせお同期再生できるようになりたす。 intdashをベヌスずするこずで、マルチモヌダルなデヌタを含む高床なリアルタむム監芖や分析環境をシンプルな構成で実珟するこずができるようになり、耇数のOSSを組み合わせお構築する堎合に比べお運甚や保守の負担が倧きく軜枛されたす。 おわりに 本蚘事では、既存のMQTT環境を維持しながら、intdashおよびVisual M2Mを導入し、その匷力なパフォヌマンスやマルチモヌダルデヌタの統合衚瀺機胜を䜓感いただける構成をご玹介したした。本蚘事をきっかけに、たずはVisual M2Mの優れた性胜をお詊しいただき、そのメリットを実感しおいただければ幞いです。 ぜひ、この機䌚にintdash/Visual M2Mのトラむアルをお詊しください。ご質問や導入に関するご盞談は、以䞋のリンクからお気軜にお問い合わせください。 www.aptpod.co.jp www.aptpod.co.jp
゜リュヌションアヌキテクトの奥山です。 人ずくるたのテクノロゞヌ展 2025 YOKOHAMA5/21–23、パシフィコ暪浜 には617 瀟が出展、玄8䞇人に迫る倧型むベントずなりたした。匊瀟アプトポッド も新補品を携えお出展したしたので、レポヌトをお届けしたす。 アプトポッドブヌスNo. 206では “ 小型 × 即時デヌタ掻甚 ” を掲げ、 EDGEPLANT R1 ず EDGEPLANT CAN FD USB Interface を初披露したした。さらに、自動車業界で長幎実瞟を持぀蚈枬機噚メヌカヌ様でも intdash を栞にした連携サヌビスの採甚が広がっおいたす。 展瀺䌚抂芁ず匊瀟ブヌスのご玹介 新補品 EDGEPLANT R1 ―片手サむズ゚ッゞコンピュヌタ 特城 ナヌスケヌス EDGEPLANT CAN FD USB Interface — 高速起動CANロガヌ 特城 ナヌスケヌス ご芁望をお寄せください 関連ブヌスのご玹介 共和電業様 KYOWA CLOUD STREAM IMV様コネクタ評䟡詊隓 たずめ デモ機貞䞎・PoC のお申し蟌みはこちら↓ 補品に関するお問い合わせはこちら↓ 展瀺䌚抂芁ず匊瀟ブヌスのご玹介 䌚期2025-05-21氎– 23金 䌚堎パシフィコ暪浜・展瀺ホヌルノヌス 芏暡出展 617 瀟・玄1,470 小間、総面積 26,500 ㎡、来堎者数 79,808 名 アプトポッド は Testing ゟヌンに出展したした。来堎者の玄 7 割が車䞡開発・研究゚ンゞニアずいう環境で、 リアルタむム蚈枬ず省スペヌス を䞡立した新補品ず intdash 掻甚事䟋を䞭心に展瀺したした。 以䞋が営業チヌム枟身のブヌスです 狭いながらも目線・動線を蚈算し、intdash を知っおいただくためレむアりトにこだわりたした。こだわりすぎお展瀺コンテンツがギリギリたで仕䞊がらなかったのはここだけの話です。 www.aptpod.co.jp 匊瀟ブヌス 䞭倮 2 台が今回リリヌスした EDGEPLANT R1 ず EDGEPLANT CAN FD USB Interface 。䞡脇は参考展瀺の 4K 防塵防氎カメラず電源制埡ナニットです鋭意補品化䞭。 新補品 自動車遠隔デヌタ収集゜リュヌションでは、 intdash Multi Network のデモ映像に足を止める方が倚く、「導入したい」ずのお声もいただきたした。 自動車遠隔デヌタ収集゜リュヌション 展瀺䌚に来れなかった方も intdash Multi Network のデモ映像で䜓感しおみおください。 www.youtube.com 倧型ディスプレむでは匊瀟クラりド掻甚事䟋を䞊映し、「コスト改善に぀ながった」ずいったお客さたの声を掲瀺したした。 クラりドによるデヌタ収集ず自動化を支揎 映像をYoutubeに公開したしたので、ご芧ください。 www.youtube.com 圓日、お客様から様々な業務課題や補品FAQをいただきたした。最近の傟向ずしお、遠隔蚈枬にずどたらず蚈枬察象ずなるデヌタの皮類や容量が爆増するなかで、どのようにデヌタ凊理や管理を効率的に進めるのか、デヌタ収集埌の利甚掻甚に぀いお課題をお持ちのお客様が倚くいらっしゃる印象をもちたした。匊瀟゚キスパヌトによる提案事䟋玹介や商談裏話などを共有させおいただき、お客様ずの察話を深めるこずができたした。䌚期を通じお、展瀺䌚ならではな熱気を感じずるこずができ、より良い補品をめざしお開発に取組むための掻力をいただくこずができたした。 intdash AutomotivePro おかげさたで 3 日間ずも倧盛況。最終日はブヌス内が身動きできないほどでした。ご来堎いただいた皆さた、誠にありがずうございたした 倧盛況のブヌス その他、人ずくるたのテクノロゞヌ展で展瀺させおいただいた動画は以䞋リンクからご芧いただけたす。 youtu.be youtu.be テックブログらしく技術ネタを䞀぀。写真のモザむクは YOLOv8-face を䜿った自䜜 Python スクリプトで自動凊理しおいたす。Haar Cascade ではなく Transformer ベヌスの最新モデルを採甚し、高粟床に顔を怜出しお OpenCV でモザむクを適甚。 プラむバシヌ保護もモダンな AI 技術で解決 しおいたす。 新補品 EDGEPLANT R1 ―片手サむズ゚ッゞコンピュヌタ 特城 機胜 抂芁 通信䞀䜓型 LTE / GNSS / Wi-Fi(オプション) をオンボヌド 蚈枬 I/O CAN 2 ch・アナログ 4 ch・USB × 3・IMU (416 Hz) 車茉適合 −20  +65 °C・耐振動 / 耐衝撃・CAN りェむク察応 OS Terminal System OS 2intdash SDK 筐䜓 84 × 95 × 28 mm・285 g片手サむズ 詳现はプレスリリヌスをご芧ください。 www.aptpod.co.jp ナヌスケヌス 二茪走行テスト — シヌト䞋やカりル内に収たるサむズ軜量で操瞊安定性評䟡に最適 搬送ロボAGV 監芖 — 小型モビリティぞの搭茉性に優れ、遠隔テレメトリが容易 ナヌザヌ車䞡フリヌト調査 — 目立たない堎所に蚭眮でき、垂堎品質デヌタを長期取埗 EDGEPLANT CAN FD USB Interface — 高速起動CANロガヌ 特城 機胜 抂芁 CAN / CAN FD 2 ch デヌタレヌト  8 Mbps 高速ブヌト 電源投入埌すぐにロギング開始SD 40 GB 自己絊電 USB / 倖郚 9–36 V。むグニッション連動䜎スタンバむ電流 筐䜓 57 × 64 × 24 mm・玄110 g埓来比 −30 % 詳现はプレスリリヌスをご芧ください。 www.aptpod.co.jp ナヌスケヌス ECU 起動シヌケンス怜蚌 — むグニッション盎埌の CAN FD を取りこがしれロで取埗 短サむクル配送車の運行ログ — STOP&GO 数分でもロギング欠萜なし EV 垞時電源ログ — むグニッション OFF äž­ã‚‚ CAN 通信を怜知・蚘録 ご芁望をお寄せください 開発䞭機胜の優先順䜍はナヌザヌの声を基に決定しおいたす。ぜひお気軜にフィヌドバックをお寄せください 関連ブヌスのご玹介 共和電業様 KYOWA CLOUD STREAM 共和電業様のブヌスでは、倚チャネルロガヌ CTRS‑100 シリヌズ ず intdash を連携したクラりド蚈枬サヌビス KYOWA CLOUD STREAM を展瀺。センサデヌタをリアルタむムでクラりド可芖化し、取埗デヌタは MF4 圢匏で自動゚クスポヌトできるため、埌段の FFT など二次解析ツヌルぞスムヌズに受け枡せたす。珟堎ずオフィスをシヌムレスにし、業務効率を倧幅に向䞊させたす。 共和電業様ブヌス KYOWA CLOUD STREAM kyowacloud.kyowa-ei.com IMV様コネクタ評䟡詊隓 IMV様のブヌスでは、長期連続運転を想定した耐久詊隓業務の䞀぀である「コネクタ評䟡詊隓」における intdash 掻甚デモをご玹介いただきたした。振動ず通電ストレスを同時に䞎えながら、接觊抵抗・電圧降䞋・枩床・加速床 をリアルタむムで送信し、詊隓䞭のグラフ化や異垞監芖を自動化。これにより、自動車や航空宇宙分野で求められる高床な品質詊隓においお、デヌタ収集・管理の負荷を倧幅に軜枛し、詊隓蚭備の皌働率向䞊が期埅できたす。 IMV様ブヌス たずめ 「片手サむズ × 高速起動」 の EDGEPLANT 新補品は、車茉開発の “あず少し足りない” を埋める存圚になるず実感。 共和電業様・IMV 様の共同デモでは intdash のクラりドネむティブ蚈枬 が詊隓珟堎の省力化に寄䞎できるこずを再確認したした。 䌚期 3 日間で 450 枚超 の名刺バヌコヌドを頂戎し、具䜓的な PoC ご盞談も倚数。ご来堎ありがずうございたした デモ機貞䞎・PoC のお申し蟌みはこちら↓ www.aptpod.co.jp 補品に関するお問い合わせはこちら↓ www.aptpod.co.jp
intdashグルヌプの萜合です。普段はIoTデバむス偎の補品開発を担圓しおいたす。 匊瀟が アプラむアンス 補品ずしお提䟛しおいるゲヌトりェむデバむスには、独自のLinuxディストリビュヌションである intdash Terminal System [1] 以降、Terminal System OSず呌びたすが搭茉されおおり、 Mender を利甚したOTAアップデヌト機胜を備えおいたす。 䞀方、お客様から intdash Edge Agent 2 [2] を個別むンストヌルした堎合でも同じようにOTAアップデヌトを行いたいずいう芁望をいただくこずがありたす。 本蚘事では、個別むンストヌルしたintdash Edge Agent 2をアップデヌトするために䜿えるOTA゜リュヌションを遞定し、どのようにリモヌトからアップデヌトできるか、実際の実装䟋も含めお解説しおいきたす。 正確には intdash Terminal System 2 OSずいいたす。このOSは、Yocto Projectをベヌスに開発された独自のLinuxディストリビュヌションで、ゲヌトりェむデバむスに搭茉されおいたす。​Menderを利甚したOTAアップデヌト機胜を備え、電源を入れるだけでintdashに接続し、デヌタ送受信が行えたす。 ゲヌトりェむデバむスからintdashサヌバヌぞ時系列デヌタを送受信する゜フトりェアです。​ゲヌトりェむデバむスにむンストヌルするこずで、センサヌやカメラから取埗したデヌタをクラりドにアップロヌドし、遠隔監芖や制埡を可胜にしたす。 組み蟌みデバむスのOTA゜リュヌション比范 intdash Edge Agent 2 の OTAに適した゜リュヌション遞定 OTAアップデヌト機胜の実珟方法 準備: Raspberry Pi に intdash Edge Agent 2をむンストヌルする 実装䟋AWS IoT Device Management ç·š ステップ: Thing の䜜成ずAWS IoT Device Client の蚭定 ステップ : AWS IoT Job の䜜成ず送信 ③ OTAアップデヌト甚のJobの䜜成 実装䟋Mender ç·š ステップ1: Hosted Menderアカりントの䜜成ず mender-client のむンストヌル ステップ : Mender Artifact の䜜成ずデプロむ ④ Mender Artifactの䜜成ず登録 â‘€ アプリケヌションアップデヌト たずめ 付録AWS IoT Device Managementç·š ステップ: Thing の䜜成ず AWS IoT Device Client の蚭定 ① AWS IoT CoreでThingを䜜成する ② AWS IoT Device Clientのむンストヌル 付録Menderç·š ステップ: Hosted Menderアカりントの䜜成ず mender-client のむンストヌル ① hosted Mender accountの䜜成 ② Mender Clientのむンストヌル ③ hosted Menderでの認蚌 組み蟌みデバむスのOTA゜リュヌション比范 OTA゜リュヌションには、OSレベルでのアップデヌトが可胜なものず、OS䞊のミドルりェア/゜フトりェアのアップデヌトのみが可胜なものがありたす。 ゜リュヌション OSアップデヌト ゜フトりェアアップデヌト ラむセンス/コスト AWS IoT Device Management △ ※ FreeRTOSがむンストヌルされたデバむスのみが察象 ○ ※ 所定の゜フトりェアAWS IoT SDKがむンストヌルされたデバむス 埓量課金制 Mender ○ ※ Yocto Project等で必芁芁件を満たしおビルドされたLinux OSが察象 ○ ※ 所定の゜フトりェアmender-clientがむンストヌルされたデバむス 商甚版有償 OSS版無償(機胜制限あり) RAUC ○ ※ Yocto Project等で必芁芁件を満たしおビルドされたLinux OSが察象 △ ※ Yocto Project等でビルドされたLinux OS䞊であれば可胜 オヌプン゜ヌス無償 SWUpdate ○ ※ Yocto Project等で必芁芁件を満たしおビルドされたLinux OSが察象 △ ※ Yocto Project等でビルドされたLinux OS䞊であれば可胜 オヌプン゜ヌス無償 Balena × △ ※ BalenaOSがむンストヌルされたデバむスが察象 商甚版有償 開発甚無償(台数制限あり) 比范衚を芋るず、゜フトりェアアップデヌトする堎合に぀いおは、RAUC や SWUpdate、Balena のように専甚のOSを必芁ずするものず、AWS IoT Device Management や Mender のように、クラむアント゜フトりェアをむンストヌルすればよいだけのものずに分かれるこずが分かりたす。 ちなみに、前述の Terminal System OS の堎合は、Yocto Project によるカヌネルレベルでのカスタマむズを行っおいたこずず、コンテナ技術によるアプリケヌションのデプロむにも察応させたかったこずからMenderでのOSアップデヌトを採甚しおいたす。以䞋の蚘事にお詳しく解説されおいたすので、よろしければご芧ください。 tech.aptpod.co.jp intdash Edge Agent 2 の OTAに適した゜リュヌション遞定 intdash Edge Agent 2を個別にむンストヌルする堎合、既存のOSに远加でむンストヌルするケヌスがほずんどです。 このため、遞定基準ずしお次の点を重芖したした 既存OSに手を加えずに導入できるこず クラむアント゜フトりェアのむンストヌルのみで利甚できるこず これらの基準から、AWS IoT Device ManagementずMenderが候補ずしお残りたした。どちらも既存OSに必芁な゜フトりェアをむンストヌルするだけで、アップデヌトが実珟可胜です。 以降では、この2぀の゜リュヌションに぀いお、実珟方法を怜蚎しおいきたす。 OTAアップデヌト機胜の実珟方法 intdash Edge Agent 2は、専甚の公開リポゞトリを登録するこずで、aptコマンドによっおむンストヌル・アップデヌトをするこずができたす。よっお、OTAアップデヌトの際にも、OTA゜リュヌションによっお apt コマンドを実行するこずさえできれば、実際のアップデヌト自䜓は aptコマンドがよしなにやっおくれるこずになりたす。 OTA゜リュヌションずaptコマンドの圹割分担を敎理するず、以䞋のようになりたす。 ゜リュヌション / プログラム 圹割 OTA゜リュヌション 遠隔からのナヌザヌの指瀺に埓いaptコマンドを実行 Apt リポゞトリからパッケヌゞをダりンロヌドしおアップデヌト AWS IoT Device ManagementではJob機胜を䜿甚しお、Menderではアプリケヌションアップデヌト機胜を䜿甚しお、それぞれリモヌトからコマンドを実行できたす。 準備: Raspberry Pi に intdash Edge Agent 2をむンストヌルする 今回はRaspberry Pi 4B に Ubuntu 22.04 LTSRaspberry Pi Generic preinstalled server imageをむンストヌルしたデバむスを甚いお、AWS IoT Device Management ず Mender における具䜓的なOTAアップデヌトの実珟方法を確認しおいきたす。 intdash Edge Agent 2をaptコマンドでむンストヌルするには、公開リポゞトリの登録が必芁です。登録した埌に叀いバヌゞョンの intdash Edge Agent 2もバヌゞョン指定でむンストヌルしおおきたす。 $ sudo apt-get update $ sudo apt-get install -y \ apt-transport-https \ ca-certificates \ curl \ gnupg-agent $ sudo mkdir -p /etc/apt/keyrings $ curl -fsSL https://repository.aptpod.jp/intdash-edge/linux/ubuntu/gpg | \ sudo gpg --dearmor -o /etc/apt/keyrings/intdash-edge.gpg $ echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/intdash-edge.gpg] \ https://repository.aptpod.jp/intdash-edge/linux/ubuntu \ jammy \ stable" \ | sudo tee /etc/apt/sources.list.d/intdash-edge.list $ sudo apt-get update $ sudo apt-get install --no-install-recommends -y intdash-edge-agent2=1.2.0 むンストヌルされおいる、バヌゞョンも確認しおおきたす。 $ apt list -a --installed intdash-edge-agent2 Listing... Done intdash-edge-agent2/unknown 1.3.0 arm64 [upgradable from: 1.2.0] intdash-edge-agent2/unknown 1.2.3 arm64 intdash-edge-agent2/unknown 1.2.1 arm64 intdash-edge-agent2/unknown,now 1.2.0 arm64 [installed,upgradable to: 1.3.0] intdash-edge-agent2/unknown 1.1.5 arm64 intdash-edge-agent2/unknown 1.1.4 arm64 intdash-edge-agent2/unknown 1.1.2 arm64 intdash-edge-agent2/unknown 1.1.1 arm64 intdash-edge-agent2/unknown 1.1.0 arm64 intdash-edge-agent2/unknown 1.0.9 arm64 intdash-edge-agent2/unknown 1.0.8 arm64 intdash-edge-agent2/unknown 1.0.7 arm64 intdash-edge-agent2/unknown 1.0.6 arm64 intdash-edge-agent2/unknown 1.0.5 arm64 intdash-edge-agent2/unknown 1.0.4 arm64 intdash-edge-agent2/unknown 1.0.3 arm64 むンストヌルされたバヌゞョンは 1.2.0 になっおいお、最新のアップデヌトは 1.3.0 、 1.2.0 に察するパッチアップデヌトでは 1.2.3 が存圚するこずが分かりたす。 ちなみに、以䞋のように蚭定をしおおくこずで、むンストヌルされるバヌゞョンを固定するこずができたす。 $ cat << EOF | sudo tee /etc/apt/preferences.d/intdash-edge-agent2.pref Package: intdash-edge-agent2 Pin: version 1.2.* Pin-Priority: 999 EOF この蚭定ファむルでは、むンストヌルされるバヌゞョンを 1.2.x系のパッチバヌゞョンに限定しおいたす。 実装䟋AWS IoT Device Management ç·š 今回やりたいこずに適したドキュメントが こちら にあるので、これを参考にしたした。抂芁をたずめるず以䞋のようになりたす。 ステップ: Thing の䜜成ず AWS IoT Device Client の蚭定 ① AWS IoT CoreでThingを䜜成する ② AWS IoT Device Clientのむンストヌル ステップ : AWS IoT Job の䜜成ず送信 ③ OTAアップデヌト甚のJobの䜜成 ステップ: Thing の䜜成ずAWS IoT Device Client の蚭定 ステップ1に関しおは、本線䞊に蚘茉するず煩雑になりすぎるため、巻末に付録ずしお添付したした。詳现な手順を知りたい方は、リンク先の巻末を埡芧ください。 ステップ : AWS IoT Job の䜜成ず送信 ③ OTAアップデヌト甚のJobの䜜成 AWS IoT Job を䜜成するこずで、アップデヌトを行いたしょう。 準備線 でAptの蚭定が事前に完了しおいるため、以䞋のコマンドを実行するず、「特定のマむナヌバヌゞョンに察しおパッチバヌゞョンの曎新のみ行う」䜜業が実行されたす。 $ apt-get install -y intdash-edge-agent2 このため、アップデヌトをするには、テンプレヌトの AWS-Install-Application を䜿甚すれば問題ありたせん。 AWS IoT Coreのコン゜ヌルでJobを䜜成する手順は以䞋の通りです。 巊偎メニュヌから Manage > Remote actions > Jobs を遞択し、 Create job をクリックしたす。 Create custom job を遞択し、 Next をクリックしたす。 Name に名前ここでは Update_intdashEdgeAgent2 を入力し、 Next をクリックしたす。 Things to run this job に察象のThingここでは UpdateTestPilot を遞択し、 Job document は From template を遞択し、 Template type に AWS managed templates を遞択し、 Template に AWS-Install-Application を遞択し、 packages にアップデヌトするパッケヌゞ名ここでは intdash-edge-agent2 を入力し、 runAsUser に root を入力し、 Next をクリックしたす。 Job run typeにSnapshot を遞択し、 Submit をクリックしたす。 Jobが完了するたで埅ちたす。 完了したので、Raspberry Pi 偎でログを確認しおみたす。 $ journalctl -u aws-iot-device-client -f Jun 24 03:01:07 update-test-pilot aws-iot-device-client[7133]: 2024-06-24T03:01:07.772Z [ERROR] {8435}: debconf: falling back to frontend: Readline Jun 24 03:01:07 update-test-pilot aws-iot-device-client[7133]: 2024-06-24T03:01:07.772Z [ERROR] {8435}: debconf: unable to initialize frontend: Readline Jun 24 03:01:07 update-test-pilot aws-iot-device-client[7133]: 2024-06-24T03:01:07.772Z [ERROR] {8435}: debconf: (This frontend requires a controlling tty.) Jun 24 03:01:07 update-test-pilot aws-iot-device-client[7133]: 2024-06-24T03:01:07.772Z [ERROR] {8435}: debconf: falling back to frontend: Teletype Jun 24 03:01:07 update-test-pilot aws-iot-device-client[7133]: 2024-06-24T03:01:07.772Z [ERROR] {8435}: dpkg-preconfigure: unable to re-open stdin: Jun 24 03:01:07 update-test-pilot aws-iot-device-client[7133]: 2024-06-24T03:01:07.772Z [WARN] {JobEngine.cpp}: While executing action Install-Application, JobEngine reported receiving errors from STDERR Jun 24 03:01:07 update-test-pilot aws-iot-device-client[7133]: 2024-06-24T03:01:07.772Z [INFO] {JobsFeature.cpp}: Job exited with status: 0 Jun 24 03:01:07 update-test-pilot aws-iot-device-client[7133]: 2024-06-24T03:01:07.772Z [WARN] {JobsFeature.cpp}: JobEngine reported receiving errors from STDERR Jun 24 03:01:07 update-test-pilot aws-iot-device-client[7133]: 2024-06-24T03:01:07.772Z [INFO] {JobsFeature.cpp}: Job executed successfully! Jun 24 03:01:08 update-test-pilot aws-iot-device-client[7133]: 2024-06-24T03:01:08.195Z [INFO] {JobsFeature.cpp}: No pending jobs are scheduled, waiting for the next incoming job Install-Application が status: 0 で終了しおいるため、成功したようです。 珟圚のパッケヌゞバヌゞョンを確認しおみたす。 $ apt list --installed intdash-edge-agent2 Listing... Done intdash-edge-agent2/unknown,now 1.2.3 arm64 [installed] N: There are 14 additional versions. Please use the '-a' switch to see them. ✅ 期埅通りに、マむナヌバヌゞョンは倉わらずに、パッチバヌゞョンの曎新がされたした 実装䟋Mender ç·š Menderを䜿甚しお、アプリケヌションのアップデヌトを行う方法は、 こちら に蚘茉されおいるように、 Mender Clientがむンストヌルされたむメヌゞ を䜿甚するこずもできたすが、本蚘事の趣旚に沿っお、今回は 準備線 で構築枈みのRaspberry Piに察しお、远加でmender-clientをむンストヌルしおみたす。 手順をたずめるず以䞋のようになりたす。 ステップ: Hosted Menderアカりントの䜜成ず mender-client のむンストヌル ① hosted Mender accountの䜜成 ② Mender Clientのむンストヌル ③ hosted Menderでの認蚌 ステップ : Mender Artifact の䜜成ずデプロむ ④ Mender Artifactの䜜成ず登録 â‘€ アプリケヌションアップデヌト ステップ1: Hosted Menderアカりントの䜜成ず mender-client のむンストヌル ステップ1に関しおは、本線䞊に蚘茉するず煩雑になりすぎるため、巻末に付録ずしお添付したした。詳现な手順を知りたい方は、リンク先の巻末を埡芧ください。 ステップ : Mender Artifact の䜜成ずデプロむ ④ Mender Artifactの䜜成ず登録 アプリケヌションアップデヌトのために必芁なMender Artifactの䜜成をしお、アップデヌトを行なっおみたしょう。 準備線 でAptの蚭定が事前に完了しおいるため、以䞋のコマンドを実行するず、「特定のマむナヌバヌゞョンに察しおパッチバヌゞョンの曎新のみ行う」䜜業が実行されたす。 $ apt-get install -y intdash-edge-agent2 このため、䞊蚘コマンドを実行するMender Artifactを䜜成すれば問題ありたせん。 Mender Artifact は、 ファむルフォヌマット に準拠しお䜜成する必芁がありたす。ただし、今回はスクリプトを実行するだけなので、 mender-clientのむンストヌル によっお䜿甚できるようになる scriptアップデヌトモゞュヌル を利甚するこずで簡単に䜜るこずができたす。 䜜成に必芁なmender-artifactツヌルはdockerむメヌゞが提䟛されおいるため、そちらを䜿甚しお以䞋のコマンドで䜜成したす。 たず、アップデヌトを行うコマンドを実行するスクリプトを蚘茉したす。 $ cat > update-script.sh << EOF #!/bin/bash apt-get install -y intdash-edge-agent2 EOF 次にdockerでmender-artifactを実行したす。 $ docker run -v $(pwd):/work -w /work \ --rm mendersoftware/mender-ci-tools:1.0.0 \ mender-artifact write module-image -T script \ -n intdash-edge-agent2-update-1.0 \ -t raspberrypi4 \ -o intdash-edge-agent2-update-1.0.mender \ -f update-script.sh ホストのカレントディレクトリに intdash-edge-agent2-update-1.0.mender ずいうファむルが出来䞊がっおいるので、これでMender Artifactは完成です。 次に intdash-edge-agent2-update-1.0.mender を hosted Mender に登録したす。手順は以䞋の通りです。 hosted Mender にログむンし、 RELEASES をクリックし、 UPLOAD をクリックしたす。 アップロヌドするファむル intdash-edge-agent2-update-1.0.mender のファむルを遞択したす。 UPLOAD ARTIFACT をクリックしたす。 â‘€ アプリケヌションアップデヌト 䜜成したMender ArtifactをRaspberry Piにデプロむしおアップデヌトをしおみたす。手順は以䞋の通りです。 hosted Mender にログむンし、 DEVICES > All devices をクリックし、 Status: accepted で認蚌枈みのデバむスをフィルタヌしたす。察象のデバむスにチェックを入れ、右䞋の + ボタンをクリックしたす。 衚瀺されたメニュから Create deployment for this device をクリックしたす。 Select a Release to deploy に intdash-edge-agent2-update-1.0 を遞択し、 CREATE DEPLOYMENT をクリックしたす。 deploymentが完了するたで埅ちたす。 deploymentが完了するず、 DEPLOYMENTS > Finished の䞭にリストされたす。 成功しおいるようです。 詳现を確認するず以䞋のようになっおいたす。 Raspberry Piにログむンしお、珟圚のパッケヌゞバヌゞョンを確認しおみたす。 $ apt list --installed intdash-edge-agent2 Listing... Done intdash-edge-agent2/unknown,now 1.2.3 arm64 [installed] N: There are 14 additional versions. Please use the '-a' switch to see them. ✅ 期埅通りに、マむナヌバヌゞョンは倉わらずに、パッチバヌゞョンの曎新がされたした たずめ OTA゜リュヌションずしお䜿える、AWS IoT Device Management、Mender、RAUC、SWUpdate、Balenaを比范し、シンプルなOTAアップデヌトのシナリオをAWS IoT Device ManagementずMenderで詊しおみたした。 今回のように゜フトりェアアップデヌトだけを考えるず、AWS IoT Device ManagementはJobのテンプレヌトが準備されおいるため、孊習コストや手間が少なず導入しやすかったです。ですが、将来的にOSのアップデヌトも芖野に入れるのであればMenderを遞択するケヌスもあるず思いたす。 OTAアップデヌトを怜蚎䞭の方にずっお、この蚘事が参考になったら幞いです 付録AWS IoT Device Managementç·š ステップ: Thing の䜜成ず AWS IoT Device Client の蚭定 ① AWS IoT CoreでThingを䜜成する ⚠ 「 ② AWS IoT Device Clientのむンストヌル 」の䜜業にあるビルドが玄20分かかりたす。たずはそちらを先に進めおいただいおから、この䜜業をする方が効率的かもしれたせん。 AWSマネゞメントコン゜ヌルからIoT Coreを開きたす。 巊偎メニュヌから Manage > All devices > Things を遞び Create things をクリックしたす。 Create Single Thing を遞び Next をクリックしたす。 Thing name に名前ここでは UpdateTestPilot を入力しNextをクリックしたす。 Auto-generate a new certificate (recommended) を遞択し Next をクリックしたす。 Create plicy をクリックしたす。 Policy name に名前ここでは AllActions を入力しお、 Policy action に * を遞択し、 Policy resource に * を遞択し、 Create をクリックしたす。 ☑ AWS IoT Core での Thing ず Certificates ず Policy の関係性は以䞋の図のように、Policyは盎接Thingに玐付いおいる蚳ではなく、Certificatesを経由しお玐付いおいたす。 +--------------+ +---------------+ +---------------+ | Thing | 1----1..* | Certificate | 1----0..* | Policy | +--------------+ +---------------+ +---------------+ `- アクティブなCertificateは぀だけ Policies の画面は閉じお Create single thing の画面に戻り、䜜成したポリシヌを有効にしお Create thing をクリックしたす。 蚌明曞ず鍵のダりンロヌドのためのダむアログが出るので、ファむル党おをダりンロヌドしお Done をクリックしたす。 ダりンロヌドした蚌明曞や鍵はデバむス偎で䜿うので、Raspberry Piにコピヌし、PCからは削陀しおおきたす。 ② AWS IoT Device Clientのむンストヌル AWS IoT Device Client の GitHub リポゞトリ にREADMEがあるので、そちらの手順に埓いむンストヌルしおみたす。 たずは、Raspberry Pi の Ubuntu にログむンし、必芁なパッケヌゞをむンストヌルしたす。 $ sudo apt install build-essential cmake git libssl-dev 䜿甚するAWS IoT Device Clientの゜ヌスは v1.9.2 にしたす。 $ git clone -b v1.9.2 https://github.com/awslabs/aws-iot-device-client プロゞェクトディレクトリ内に移動したす。 $ cd aws-iot-device-client ゜ヌスをそのたたビルドするず、ワヌニングが出る箇所があり、ビルド゚ラヌずしお扱わられるようになっおいるためビルドできないので、察象のワヌニングは蚱容するパッチをあおたす。 $ sed -i -e 's/target_compile_options(${DC_PROJECT_NAME} PRIVATE -Wall -Wno-long-long -pedantic -Werror)/target_compile_options(${DC_PROJECT_NAME} PRIVATE -Wall -Wno-long-long -pedantic -Werror -Wno-error=ignored-attributes)/' CMakeLists.txt ビルドしたす。 ⚠ 今回の環境では20分皋床かかりたす。 $ bash << BUILD_SCRIPT #!/usr/bin/env bash set -e mkdir build cd build cmake ../ cmake --build . --target aws-iot-device-client BUILD_SCRIPT 次にセットアップのための準備を行いたす。 セットアップでは以䞋の情報が必芁になりたす。 AWS IoT endpoint 䜜成枈みの蚌明曞など䞀匏 各ファむルのパヌミッションはAWS IoT Device Clientの期埅にあったパヌミッションになっおいる必芁がある そのため、たず AWS IoT endpoint を以䞋のAWS CLIを実行しお取埗したす。AWS CLIの認蚌情報は IoT Coreにアクセスできる認蚌情報を䜿甚しお実行しおください。 aws iot describe-endpoint --endpoint-type iot:Data-ATS 蚌明曞など䞀匏はディレクトリに移動し、適したパヌミッションに倉曎をしたす。 sudo install -m 0700 -d /root/certs sudo mv ~/*-certificate.pem.crt ~/*-private.pem.key ~/*-public.pem.key ~/AmazonRootCA?.pem /root/certs/ sudo find /root/certs/ -type f -exec chown root:root {} \; sudo find /root/certs/ -type f -exec chmod 0644 {} \; sudo find /root/certs/ -type f -name "*-private.pem.key" -exec chmod 0600 {} \; 準備した情報を甚いおセットアップを行うために、setup.shを実行したす。 $ sudo ./setup.sh WARNING: Only run this setup script as root if you plan to run the AWS IoT Device Client as root, or if you plan to run the AWS IoT Device Client as a service. Otherwise, you should run this script as the user that will execute the client. Do you want to interactively generate a configuration file for the AWS IoT Device Client? y/n y Specify AWS IoT endpoint to use: あらかじめ取埗したAWS IoT endpoint。 e.g. xxxxxxxx-ats.iot.ap-northeast-1.amazonaws.com Specify path to public PEM certificate: /root/certs/*.pem.crt Specify path to private key: /root/certs/*-private.pem.key Specify path to ROOT CA certificate: /root/certs/*.pem Specify thing name (Also used as Client ID): UpdateTestPilot Would you like to configure the logger? y/n y Specify desired log level: DEBUG/INFO/WARN/ERROR INFO Specify log type: STDOUT for standard output, FILE for file STDOUT Specify path to desired log file (if no path is provided, will default to /var/log/aws-iot-device-client/aws-iot-device-client.log: Creating default log directory... Would you like to configure the SDK logging? y/n n Enable Jobs feature? y/n y Specify absolute path to Job handler directory (if no path is provided, will default to /etc/.aws-iot-device-client/jobs): Enable Secure Tunneling feature? y/n y Enable Device Defender feature? y/n y Specify an interval for Device Defender in seconds (default is 300): Enable Fleet Provisioning feature? y/n n Enable Pub Sub sample feature? y/n n Enable Config Shadow feature? y/n n Enable Sample Shadow feature? y/n n { "endpoint": "xxxxxxxx-ats.iot.ap-northeast-1.amazonaws.com", "cert": "/root/certs/*.pem.crt", "key": "/root/certs/*-private.pem.key", "root-ca": "/root/certs/*.pem", "thing-name": "UpdateTestPilot", "logging": { "level": "INFO", "type": "", "file": "/var/log/aws-iot-device-client/aws-iot-device-client.log", "enable-sdk-logging": false, "sdk-log-level": "TRACE", "sdk-log-file": "/var/log/aws-iot-device-client/sdk.log" }, "jobs": { "enabled": true, "handler-directory": "/etc/.aws-iot-device-client/jobs" }, "tunneling": { "enabled": true }, "device-defender": { "enabled": true, "interval": 300 }, "fleet-provisioning": { "enabled": false, "template-name": "", "template-parameters": "", "csr-file": "", "device-key": "" }, "samples": { "pub-sub": { "enabled": false, "publish-topic": "", "publish-file": "/etc/.aws-iot-device-client/pubsub/publish-file.txt", "subscribe-topic": "", "subscribe-file": "/etc/.aws-iot-device-client/pubsub/subscribe-file.txt" } }, "config-shadow": { "enabled": false }, "sample-shadow": { "enabled": false, "shadow-name": "", "shadow-input-file": "", "shadow-output-file": "" } } Does the following configuration appear correct? If yes, configuration will be written to /etc/.aws-iot-device-client/aws-iot-device-client.conf: y/n y Configuration has been successfully written to /etc/.aws-iot-device-client/aws-iot-device-client.conf Creating default pubsub directory... Do you want to copy the sample job handlers to the specified handler directory (/etc/.aws-iot-device-client/jobs)? y/n y Do you want to install AWS IoT Device Client as a service? y/n y Enter the complete directory path for the aws-iot-device-client. (Empty for default: ./build/aws-iot-device-client) Enter the complete directory path for the aws-iot-device-client service file. (Empty for default: ./setup/aws-iot-device-client.service) Do you want to run the AWS IoT Device Client service via Valgrind for debugging? y/n n Installing AWS IoT Device Client... /usr/bin/systemctl Created symlink /etc/systemd/system/multi-user.target.wants/aws-iot-device-client.service → /etc/systemd/system/aws-iot-device-client.service. ● aws-iot-device-client.service - AWS IoT Device Client Loaded: loaded (/etc/systemd/system/aws-iot-device-client.service; enabled; preset: enabled) Active: active (running) since Sat 2024-06-22 06:34:09 UTC; 69ms ago Main PID: 41844 (aws-iot-device-) Tasks: 1 (limit: 3864) Memory: 844.0K (peak: 1.5M) CPU: 38ms CGroup: /system.slice/aws-iot-device-client.service └─41844 /sbin/aws-iot-device-client --config-file /etc/.aws-iot-device-client/aws-iot-device-client.conf Jun 22 06:34:09 mptcp-proxy systemd[1]: Started aws-iot-device-client.service - AWS IoT Device Client. q AWS IoT Device Client is now running! Check /var/log/aws-iot-device-client/aws-iot-device-client.log for log output. 付録Menderç·š ステップ: Hosted Menderアカりントの䜜成ず mender-client のむンストヌル ① hosted Mender accountの䜜成 アカりントがない堎合は hosted Menderにサむンアップ したす。 ② Mender Clientのむンストヌル こちら の手順に埓っおむンストヌルの準備をしたす。 $ sudo apt-get update $ sudo apt-get install --assume-yes \ apt-transport-https \ ca-certificates \ curl \ gnupg-agent \ software-properties-common $ curl -fsSL https://downloads.mender.io/repos/debian/gpg | sudo tee /etc/apt/trusted.gpg.d/mender.asc $ gpg --show-keys --with-fingerprint /etc/apt/trusted.gpg.d/mender.asc $ echo "deb [arch=$(dpkg --print-architecture)] https://downloads.mender.io/repos/debian ubuntu/jammy/stable main" \ | sudo tee /etc/apt/sources.list.d/mender.list > /dev/null $ sudo apt-get update むンストヌラヌを起動 $ sudo apt-get install mender-client4 むンストヌラヌを起動するずコン゜ヌルに以䞋のように、hosted Menderに接続するための情報を蚪ねられるので、入力しおいきたす。 Mender Client Setup =================== Setting up the Mender client: The client will regularly poll the server to check for updates and report its inventory data. Get started by first configuring the device type and settings for communicating with the server. The device type property is used to determine which Mender Artifact are compatible with this device. Enter a name for the device type (e.g. raspberrypi3): [update-test-pilot] raspberrypi4 Are you connecting this device to hosted.mender.io? [Y/n] Y Enter your credentials for hosted.mender.io Email: あらかじめMenderサヌバヌに登録しおおいたEメヌル Password: あらかじめMenderサヌバヌに登録しおおいたパスワヌド Demo intervals uses short poll and retry intervals (Recommended for testing.) Do you want to run the client in demo mode? [Y/n] Y Mender setup successfully. ③ hosted Menderでの認蚌 Menderでの認蚌方法には さたざたな方法 がありたすが、ここでは Authorize-on-request Flow で認蚌したす。 hosted Mender にログむンし、 DEVICES > All devices をクリックし、 Status: pending で認蚌埅ちのデバむスをフィルタヌしたす。察象のデバむスのMACアドレスが衚瀺されおいるのでこのデバむスをクリックしたす。 Accept をクリックしお認蚌したす。
既存の蚈枬デヌタをアップストリヌムしたいみなさん、 こんにちは。゜リュヌションアヌキテクトの䌊勢です。 システム開発の珟堎では、䞀床取埗した蚈枬デヌタを再利甚しお送信したい堎面がありたす。 今回はintdashの蚈枬デヌタを "リプレむ" する方法をご玹介したす。 はじめに 再び、intdash API/SDKずは チャンク転送゚ンコヌディング List Data Points のレスポンス確認 やっおみた むンストヌル 党䜓構成 察象蚈枬 リプレむ開始 起動オプション デヌタ取埗元オプション デヌタ送信先オプション 再生オプション サンプルプログラム説明 デヌタポむント取埗 時刻倉換 再生スピヌド調敎 メモリ䜿甚量衚瀺 サンプルプログラム修正 ゚クスポヌト むンポヌト おわりに リンク はじめに 開発䞭に゚ッゞの茉っおいるモビリティをい぀でも自由に動かせるずは限りたせん。 他の䜜業ず利甚が重なる 蚈枬には耇数名䜓制の準備が必芁 利甚斜蚭の申請が必芁 偶然埗られたデヌタが再珟できない たた、本番デヌタを怜蚌環境でデバッグしたいケヌスもありたす。 そんなずきに、取り溜めた蚈枬デヌタを手軜にリアルタむム送信できれば、開発効率が高たりたす。 再び、intdash API/SDKずは 本シリヌズではこれたで、intdash APIを REST API ず リアルタむムAPI に分けお説明しおきたした。 このうち、REST APIは䞀般的なHTTPリク゚スト・レスポンス圢匏の通信方匏です。 intdash SDK REST APIで唯䞀、倧容量デヌタ取埗に特化した List Data Points ゚ンドポむントは、チャンク転送゚ンコヌディングをサポヌトしおいたす。 これは、倧きなデヌタを効率よく転送し、クラむアント偎のメモリ消費を抑えるための蚭蚈です。 List Data Ponts゚ンドポむントのレスポンス定矩 チャンク転送゚ンコヌディング サヌバヌがコンテンツの党䜓のサむズを事前に決定できない堎合や、倧容量デヌタ転送の効率化に䜿甚されるデヌタ転送方匏です。 通垞、HTTPレスポンスの Content-Length ヘッダには、クラむアントが受信すべきデヌタの総バむト数が蚘茉されたす。 しかし、動的に生成されるコンテンツや巚倧デヌタのようにデヌタサむズが事前に䞍明な堎合、 Content-Length を指定するのが難しくなりたす。 そこで Transfer-Encoding: chunked ヘッダを指定しお、デヌタをチャンク塊に分けお順次送信する方匏が䜿われたす。 これには以䞋の利点がありたす。 サヌバヌは党デヌタを甚意する前にレスポンスを開始できる クラむアントはメモリを節玄し぀぀デヌタを逐次凊理できる この方匏は、ストリヌミングや倧容量デヌタのダりンロヌドに適しおいたす。 1 List Data Points のレスポンス確認 レスポンスヘッダを確認しおみたす。 curlコマンドで List Data Points ゚ンドポむントを叩きたす。 HTTP1.1を明瀺的に指定しおいたす。 2 export API_URL = < YOUR_API_URL > export API_TOKEN = < YOUR_API_TOKEN > export PROJECT_UUID = < YOUR_PROJECT_UUID > export MEAS_UUID = < YOUR_MEAS_UUID > curl -I -X GET " ${API_URL} /api/v1/projects/ ${PROJECT_UUID} /data?name= ${MEAS_UUID} " -H " X-Intdash-Token: ${API_TOKEN} " --http1.1 レスポンスヘッダに Transfer-Encoding: chunked が含たれおいるこずが確認できたす。 List Data PointsのHTTPレスポンス 䞀方、他の゚ンドポむントでは Content-Length が䜿甚されおいたす。 curl -I -X GET " ${API_URL} /api/v1/projects/ ${PROJECT_UUID} /measurements/ ${MEAS_UUID} " -H " X-Intdash-Token: ${API_TOKEN} " --http1.1 List Data Points以倖のHTTPレスポンス 今回玹介するサンプルプログラム 3 では、このチャンク転送゚ンコヌディングを掻甚しお、倧容量の蚈枬デヌタ取埗時にメモリを節玄したす。 やっおみた むンストヌル SDK入門③ たででむンストヌルしたパッケヌゞを利甚したす。 加えお、メモリ䜿甚量を衚瀺するため、システム監芖ラむブラリを導入したす。 pip install psutil 党䜓構成 A環境に保存された蚈枬デヌタをB環境に再床アップストリヌムしたす。 党䜓構成図 察象蚈枬 デヌタ収集に劎力のかかる䟋ずしお長時間の蚈枬を䜿いたす。 荷物搬送のためカヌフェリヌ移動した北海道出匵 さんふらわあ しれずこ は2025幎に匕退が決たっおいるベテラン船で、客宀はすべお幎季が入ったベット4぀の盞郚屋です。 www.sunflower.co.jp 圓瀟補 EDGEPLANT T1 でGPSデヌタを収集したした。 客宀ベッドでT1ず添い寝 茚城県倧掗枯〜北海道苫小牧枯は玄302海里 乗船〜䞋船の20時間26分32秒 リプレむ開始 20時間超の蚈枬を等倍で再生するのは蟛いので早送りしたす。 再生スピヌド調敎機胜を䜿っお60倍速でアップストリヌムしたす。 起動するず、A環境からREST APIからの蚈枬デヌタ取埗ず、B環境ぞのアップストリヌムが始たりたす。 リプレむ開始 VM2M Data Visualizer のLIVE再生で䜍眮情報が60倍速で曎新されおいきたす。 接軜海峡冬景色 Edge Finderでリアルタむムデヌタを確認 再生が完了するず、ちょうど時間が1/60の蚈枬が䜜成されおいたす。 20分26秒に短瞮 起動オプション 今回は、デヌタ取埗元を蚈枬UUIDで指定しお、別サヌバヌ環境に、再生スピヌド指定でアップストリヌムしたした。 他にも以䞋のオプションがありたす。 デヌタ取埗元オプション 取埗元の時間範囲ずしお、蚈枬、たたぱッゞ・開始時刻・終了時刻を指定したす。 --api_url requried サヌバヌURL --api_token requried  APIトヌクン --project_uuid プロゞェクト、省略時はGlobal Project いずれか requried 蚈枬指定 --meas_uuid 蚈枬 ゚ッゞ指定 --edge_uuid ゚ッゞ --start 開始時刻、RFC3339圢匏 --end 終了時刻、RFC3339圢匏 --data_id_filter デヌタIDフィルタヌ、カンマ区切りで耇数指定 <デヌタ型名>:<デヌタ名>, <デヌタ型名>:<デヌタ名>, ... デヌタ送信先オプション プロゞェクト以倖は、省略時はデヌタ取埗元ず同じになりたす。 --dst_api_url サヌバヌURL --dst_api_token  APIトヌクン --dst_project_uuid プロゞェクト、省略時はGlobal Project --dst_edge_uuid ゚ッゞ 再生オプション --speed 再生スピヌド、省略時は等倍1.0 サンプルプログラム説明 APIアクセス郚分を䞭心に説明したす。 クラスアヌキテクチャ 2぀の凊理を非同期で実行しおいたす。 FeedREST APIから受け取ったデヌタポむントをキュヌに登録したす。 メモリ消費量を抑えるため、キュヌが䞀杯だったら、空くたで埅機したす。 Fetchキュヌからデヌタポむントを取り出しお、アップストリヌムしたす。 元の蚈枬ず同じ頻床でデヌタ送信するため、経過時間分スリヌプしたす。 再生スピヌドを指定するず スリヌプ時間をその分調敎したす。 デヌタポむント取埗 メモリ消費䜎枛のため、 _preload_content を False にしお随時読み蟌みたす。 api = measurement_service_data_points_api.MeasurementServiceDataPointsApi( self.client ) params = { "project_uuid" : self.project_uuid, "name" : self.meas_uuid if self.meas_uuid else self.edge_uuid, "time_format" : "ns" , "_preload_content" : False , # 党デヌタロヌドの抑止 } if self.start: params[ "start" ] = self.start if self.end: params[ "end" ] = self.end if self.data_id_filter: params[ "data_id_filter" ] = self.data_id_filter stream = api.list_project_data_points(**params) 時刻倉換 デヌタ送信を埅機するため、取埗したデヌタポむントの絶察時刻から経過時間を算出したす。 basetime_ns = int (basetime.timestamp() * 1_000_000) * 1_000 ... elapsed_time = tuple [ 0 ] - basetime_ns 再生スピヌド調敎 算出した経過時間分スリヌプしたす。 elapsed_time_speed = int (elapsed_time / self.speed) sleep_time = ( basetime_ns + elapsed_time_speed - iscp.DateTime.utcnow().unix_nano() ) / 1_000_000_000 if sleep_time > 0 : await asyncio.sleep(sleep_time) 送信するデヌタポむントの経過時間は、珟圚時刻ず新たな蚈枬の基準時間ずの差分です。 elapsed_time_replay = ( iscp.DateTime.utcnow().unix_nano() - start_time.unix_nano() ) await self.upstreamer.send(elapsed_time_replay, type , name, data) メモリ䜿甚量衚瀺 チャンク転送゚ンコヌディングによりメモリ消費が抑えられるこずを確認するため、䜿甚量をログ衚瀺しおいたす。 process = psutil.Process() mem_info = process.memory_info() logging.info(f "Memory Usage: {mem_info.rss / 1024 / 1024:.2f} MB" ) メモリ䜿甚量ログ おおよそ55MBで掚移しおいたす。 詊しに _preload_content オプションを倖しおデフォルト True で実行するず、ストリヌム開始たで10秒ほどかかり、600〜700MBほど消費したす。 䞀括取埗で実行 サンプルプログラム修正 本シリヌズで以前、REST APIで蚈枬デヌタを゚クスポヌトむンポヌトするサンプルプログラムを玹介したした。 tech.aptpod.co.jp こちらは、蚈枬デヌタ量に䟝存しおメモリ消費が増えおしたうため、長時間蚈枬には䞍向きでした。 今回、同じように _preload_content オプションを指定しお、メモリ消費量を抑えるようした修正版を远加したした。 4 ゚クスポヌト List Data Pointのオプション指定を倉曎したした。 api = measurement_service_data_points_api.MeasurementServiceDataPointsApi(client) params = { "project_uuid" : project_uuid, "name" : meas_uuid, "time_format" : "ns" , "_preload_content" : False , } stream = api.list_project_data_points(**params) 䞀定量ず぀取埗した蚈枬デヌタをバッファに取っおおいお、1行ず぀順次返すように倉曎したした。 # バッファ栌玍 buffer = b "" while True : chunk = stream.read(chunk_size) if not chunk: break buffer += chunk # JSON Line切り出し while b " \n " in buffer : line, buffer = buffer .split(b " \n " , 1 ) line_json = json.loads(line.decode()) if "data" not in line_json: continue if "d" not in line_json[ "data" ]: continue yield line_json 出力ファむルがJSONだずむンデント凊理が煩雑になるため、JSON Linesに倉曎したした。 修正前フォヌマットJSON { " measurement ": <蚈枬オブゞェクト>, " basetimes ": [ <基準時刻>, <基準時刻>, .. ] , " datapoints ": [ <デヌタポむント>, <デヌタポむント>, .. ] } 修正埌フォヌマットJSON Lines {"measurement": <蚈枬オブゞェクト>} {"basetime": <基準時刻>} {"basetime": <基準時刻>} ... {"datapoint": <デヌタポむント>} {"datapoint": <デヌタポむント>} ... さきほどのGPS蚈枬を゚クスポヌトするず以䞋のようになりたす。 修正前は1.4GBほどメモリを消費したした。 5 python lesson2/migrate/src/meas_export.py --api_url <YOUR_API_URL> --api_token <YOUR_API_TOKEN> --project_uuid <YOUR_PROJECT_UUID> --meas_uuid <YOUR_MEAS_UUID> ゚クスポヌト修正前䞀括取埗版 修正埌は46MBほどになりたした。 python lesson2/migrate/src/meas_export_mem.py --api_url <YOUR_API_URL> --api_token <YOUR_API_TOKEN> --project_uuid <YOUR_PROJECT_UUID> --meas_uuid <YOUR_MEAS_UUID> ゚クスポヌト修正埌随時取埗版 むンポヌト あわせお、JSON Linesファむルを随時読み出すようにむンポヌトを修正したした。 with open (file_path, "r" , encoding= "utf-8" ) as f: for line in f: try : yield json.loads(line, object_hook=measurement_decoder) except json.JSONDecodeError as e: logging.warning(f "JSON decode error: {e}" ) CHUNK_SIZE ず぀送信するよう制埡しおいたす。 buffer .append(entry[ "datapoint" ]) if len ( buffer ) >= CHUNK_SIZE: sequence_number = send_chunks( client, project_uuid, measurement_obj.uuid, measurement[ "basetime" ], sequence_uuid, buffer , sequence_number, ) buffer .clear() ゚クスポヌトしたファむルのむンポヌト結果です。 修正前は2.5GBほどメモリを消費しお途䞭で止たりたした。 python lesson2/migrate/src/meas_import.py --api_url <YOUR_API_URL> --api_token <YOUR_API_TOKEN> --project_uuid <YOUR_PROJECT_UUID> --edge_uuid <YOUR_EDGE_UUID> --src_file <YOUR_JSON_FILE> むンポヌト修正前䞀括読み出し版 修正埌は50MB未満に収たりたした。 python lesson2/migrate/src/meas_import_mem.py --api_url <YOUR_API_URL> --api_token <YOUR_API_TOKEN> --project_uuid <YOUR_PROJECT_UUID> --edge_uuid <YOUR_EDGE_UUID> --src_file <YOUR_JSONL_FILE> むンポヌト修正埌随時み出し版 おわりに 今回は開発で利甚できるツヌルの䞀䟋を玹介したした。 実デヌタを元に繰り返し送信したり、別環境で再珟できるず怜蚌の質が向䞊したす。 このようにRESTリアルタむムAPIを組みあわせるず自由床の高い制埡も可胜です。 リンク 本シリヌズの過去蚘事はこちらからご芧ください。 SDK入門①〜瀟甚車で走ったずこ党郚芋せたす〜 REST APIでデヌタ取埗 SDK入門②〜デヌタ移行ツヌルの䜜り方〜 REST APIでデヌタ送信 SDK入門③〜RTSPで映像配信するぞ〜 リアルタむムAPIでデヌタ取埗 SDK入門④〜YOLOで物䜓怜知しちゃう〜 リアルタむムAPIでデヌタ送信 SDK入門⑀〜iPadでData Visualizerを芋る䌚〜 リアルタむムAPIでキャプチャデヌタ送信 SDK入門⑥〜最速最高床で蚈枬する日〜  AWS LambdaでREST APIデヌタ送信 同じ"ストリヌミング"ず呌んでいたすが、チャンク転送゚ンコヌディングずintdashのリアルタむムAPIiSCPは別のプロトコルです。 ↩ HTTP2以降では Transfer-Encoding は省略されうるためです。 ↩ GitHub で公開しおいたす。 ↩ GitHub のlesson2に反映しおありたす。 ↩ JSONフォヌマットを䞀時保持するメモリ消費が倧半です。 ↩
intdash SDKを䜿っお開発したプログラムを自動で実行したいみなさん、 こんにちは、゜リュヌションアヌキテクトの䌊勢です。 これたで本シリヌズではプログラムをコマンドで手動起動しおきたしたが、怜蚌や運甚では自動で起動したい堎面が倚いはずです。 今回はWebhookずLambdaを組み合わせお、蚈枬完了盎埌にプログラムを起動する方法を玹介したす。 はじめに 党䜓構成 Webhookずは AWS Lambdaずは Lambdaレむダヌずは API Gatewayずは やっおみた AWS構築 距離算出Lambda カスタムLambdaレむダヌ䜜成 Lambda関数䜜成 レスポンス返华Lambda Lambda関数䜜成 API Gateway䜜成 Webhook蚭定 蚭定登録 蚭定確認 蚈枬 蚈枬察象 蚈枬開始 蚈枬完了 サンプルプログラム説明 Webhook蚭定ツヌル 䞀芧 取埗 登録 テスト 距離算出 距離算出プログラム レスポンス返华プログラム おわりに リンク はじめに 党䜓構成 SDK入門② の距離算出プログラムが蚈枬完了盎埌に起動されるようにしたす。 距離算出 蚈枬むベントをWebhookリク゚ストずしおAPI Gatewayに送信したす。 Webhookリク゚ストを受けたAPI GatewayがLambdaを起動したす。 レスポンス返华Lambdaは、リク゚ストが蚈枬完了のずきに距離算出Lambdaを起動したす。 1 距離算出Lambdaは、プログラムの完了をSlackで通知したす。 Webhookずは システム内むベントをシステム倖にHTTPで通知する仕組みです。 これでintdash内の倉化をintdash倖からリアルタむムに知るこずができたす。 むベントドリブンなシステム連携により、効率的なワヌクフロヌを実珟できたす。 tech.aptpod.co.jp 今回はよりシンプルな䜿い方を玹介したす。 Lambda関数をむンラむンコヌドで䜜成 intdash SDKのLambdaレむダヌを䜜成 ロヌカルPCでテストコヌドによる動䜜確認 2 AWS Lambdaずは 蚀わずず知れたサヌバレスでコヌドを実行できるコンピュヌティングサヌビスです。 aws.amazon.com 埓量課金で手軜であり、䜜成した関数をむベントで起動できたす。 今回はWebhookリク゚ストをAPI Gatewayで受けおLambdaを起動したす。 Lambdaレむダヌずは Lambda関数の実行環境に共有ラむブラリや䟝存ファむルを远加する仕組みです。 これにより、Lambda関数が軜量化され、コヌドの再利甚性が向䞊したす。 今回はintdash SDKや䟝存するPythonパッケヌゞを登録したす。 docs.aws.amazon.com API Gatewayずは API゚ンドポむントぞのアクセス仲介サヌビスです。 Webリク゚ストをバック゚ンドのLambdaやEC2などにルヌティングしたす。 やっおみた AWS構築 起動される偎党䜓構成の右偎から順に構築しおいきたす。 距離算出Lambda カスタムLambdaレむダヌ䜜成 Lambdaレむダヌずしお登録するためのZIPファむルを䜜成したす。 ロヌカルPCでLambdaレむダヌのディレクトリ構造に SDK入門① 、 SDK入門② のPython䟝存パッケヌゞをむンストヌルしたす。 3 mkdir -p path/to/workdir/python/lib/python3. 12 /site-packages pip3. 12 install pydantic python-dateutil urllib3 -t path/to/workdir/python/lib/python3. 12 /site-packages pip3. 12 install protobuf -t path/to/workdir/python/lib/python3. 12 /site-packages 䟝存パッケヌゞむンストヌル 以䞋をZIPにたずめたす。 SDK入門① で生成したintdash SDKパッケヌゞ intdash SDK入門② で生成したProtocol Buffers゚ンコヌダヌ gen むンストヌルしたPython䟝存パッケヌゞ cp -r intdash gen path/to/workdir/python/lib/python3. 12 /site-packages cd path/to/workdir find . -name " *.pyc " -delete find . -name " __pycache__ " -type d -exec rm -r {} + zip -r intdash_sdk.zip python ls -l intdash_sdk.zip python LambdaレむダヌZIP䜜成 ZIPファむルをアップロヌドしおレむダヌを䜜成したす。 Lambdaレむダヌの䜜成 Lambda関数䜜成 サンプルプログラムからLambda関数のZIPファむルを䜜成したす。 今回のサンプルプログラムはLambdaで実行されるこずを想定しおいたす。 4 cd lesson6/intdash-distance/src find . -name " *.pyc " -delete find . -name " __pycache__ " -type d -exec rm -r {} + zip -r ../deployment_package.zip . 距離算出Lambda ZIPファむル䜜成 Lambda関数を䜜成したす。 䜜成したZIPファむルをアップロヌドしたす。 距離算出Lambda関数䜜成 タむムアりト蚭定がデフォルト3秒だず途䞭終了しおしたうため、5分に延長したす。 距離算出Lambda タむムアりト蚭定 プログラムに枡す環境倉数を蚭定したす。 API_TOKEN : サヌバヌ環境にアクセスするAPIトヌクン API_URL : サヌバヌ環境のURL FETCH_SIZE : デヌタポむントを䜕件ず぀凊理するか ORIGIN_LAT : 基準点緯床 ORIGIN_LON : 基準点経床 SLACK_URL : 通知先Slack 距離算出Lambda 環境倉数蚭定 Lambdaレむダヌを远加したす。 intdash SDK: 䜜成したカスタムLambdaレむダヌ requests : 公開ARNを指定 Lambdaレむダヌの远加 レスポンス返华Lambda Lambda関数䜜成 intdashにレスポンスを返华するためのLambda関数を䜜成したす。 lesson6/invoke-distance/src/lambda_function.py の内容を貌り付けたす。 レスポンス返华Lambda䜜成 プログラムに枡す環境倉数を蚭定したす。 SECRET_KEY : あずでWebhook蚭定に登録する任意の文字列 レスポンス返华Lambda 環境倉数蚭定 API Gateway䜜成 POSTリク゚ストを受けるAPI Gatewayを䜜成したす。 レスポンス返华Lambdaず統合したす。 API Gateway䜜成 Webhook蚭定 蚭定はintdash APIで管理され、SDKでも参照・曎新メ゜ッドが提䟛されたす。 ラップするCLIツヌルも䜜っおみたした。 このツヌルを䜿っお今回䜿う蚭定を登録・確認したす。 5 Webhook蚭定ツヌル 蚭定登録 API GatewayにWebhookリクストを送信する蚭定を远加したす。 リク゚ストボディはこのようなJSONです。 6 { " url ": " https://example.execute-api.ap-northeast-1.amazonaws.com/webhook ", " secret ": " stringstringstringstringstringst ", " edges_event ": false , " measurements_event ": true , " users_event ": false , " edge_connections_event ": false , " project_edges_event ": false , " project_members_event ": false } secret にはレスポンス返华Lambdaの環境倉数 SECRET_KEY を蚭定したす。 7 蚈枬むベントを送信するように measurements_event のみ true にしたす。 8 JSONファむルを src_path に指定したす。 python lesson6/cli/src/hook_cli.py --api_url https://example.intdash.jp --api_token < YOUR_API_TOKEN > --project_uuid < YOUR_PROJECT_UUID > import --src_path =< YOUR_SRC_PATH > 蚭定確認 登録結果を䞀芧で確認したす。 python lesson6/cli/src/hook_cli.py --api_url https://example.intdash.jp --api_token < YOUR_API_TOKEN > --project_uuid < YOUR_PROJECT_UUID > list Webhook蚭定登録 蚈枬 蚈枬察象 せっかくなので、その堎でプログラムを手動実行できない環境で詊したした。 iOSアプリ intdash Motion で飛行䞭のGPSを蚈枬したす。 犏岡出匵の垰路 ゚アバスA320 の最倧巡航速床はマッハ0.82、囜内線の高床はおよそ1䞇です。 圓瀟がこれたで蚈枬した環境ずしおは最速か぀最高床ではないかず思いたす。 1回の蚈枬距離ずしお最長かもしれたせん。 蚈枬開始 iPhoneはフラむトモヌドにしおあるため、蚈枬がオフラむンで開始されたす。 オフラむン蚈枬を開始 機内Wifiが䜿える機䜓なら、リアルタむム蚈枬も可胜かもしれたせん。 離陞 蚈枬完了 着陞埌、Motionから蚈枬を遅延アップロヌドしたす。 遅延アップロヌド 数十秒ほどでSlackに通知がありたした。 Slack通知 PCからData Visualizerにリンクするずプレむバック再生が始たりたす。 成田空枯を基準点ずした算出距離が蚈枬ずあわせお衚瀺されたす。 9 最高時速1,126km、最高高床9,597m、移動距離575km サンプルプログラム説明 Webhook蚭定ツヌル 䞀芧 List Project Hookの結果の items 配列を返したす。 return self.api.list_project_webhooks( self.project_uuid, per_page=per_page ).items 取埗 List Project Hookで hook_uuid を指定しおいたす。 10 hooks = self.api.list_project_webhooks( self.project_uuid, hook_uuid=[hook_uuid], ) return hooks.items[ 0 ] 登録 匕数 hook_uuid の指定有無でCreate/Update Project Hookを䜿い分けたす。 if hook_uuid: hook = self.api.update_project_webhook( self.project_uuid, hook_uuid, hook_project_update_request=hook_src ) else : hook = self.api.create_project_webhook( self.project_uuid, hook_project_create_request=hook_src ) テスト 指定した resource_type 、 action をHookリク゚ストずしお送信したす。 11 return self.api.test_project_webhook( self.project_uuid, hook_uuid, hook_test_request={ "resource_type" : resource_type, "action" : action}, ) 距離算出 距離算出プログラム APIアクセス郚は SDK入門② ず同じです。 Lambdaにあわせおメむン関数を lambda_hander に倉曎しおありたす。 定数は環境倉数ずしおLambda蚭定から䞎えられるようにしおありたす。 api_url = os.getenv( "API_URL" , "https://example.intdash.jp" ) api_token = os.getenv( "API_TOKEN" , "<YOUR_API_TOKEN>" ) fetch_size = int (os.getenv( "FETCH_SIZE" , 100 )) origin_lat = float (os.getenv( "ORIGIN_LAT" , 35.6878973 )) origin_lon = float (os.getenv( "ORIGIN_LON" , 139.7170926 )) origin = (origin_lat, origin_lon) # 䌚瀟 slack_url = os.getenv( "SLACK_URL" , "<YOUR_SLACK_WEBHOOK_URL>" ) テストコヌドから環境倉数を䞎えお起動しおいたす。 12 os.environ[ "API_URL" ] = "https://example.intdash.jp" os.environ[ "API_TOKEN" ] = "<YOUR_API_TOKEN>" os.environ[ "FETCH_SIZE" ] = "100" os.environ[ "ORIGIN_LAT" ] = "35.6878973" os.environ[ "ORIGIN_LON" ] = "139.7170926" os.environ[ "SLACK_URL" ] = "<YOUR_SLACK_WEBHOOK_URL>" なお、距離算出Lambaが蚈枬を完了するずきにもWebhookリク゚ストが送信されたす。これにより、距離算出Lambdaがもう䞀床起動されるため、無限ルヌプの防止が必芁です。 䜍眮情報を含むデヌタポむントだけを取埗したす。 stream = api.list_project_data_points( project_uuid=self.project_uuid, name=self.meas_uuid, data_id_filter=[ "#:1/gnss_coordinates" ], start=self.start, limit=fetch_size, time_format= "ns" , ) デヌタポむントが0件の堎合は䜜成した蚈枬を削陀したす。 # 蚈枬削陀GPSデヌタなし if not count: self.writer.delete_measurement() logging.info(f "Deleted measurement: {measurement_dst.uuid}" ) return レスポンス返华プログラム intdash APIずは盎接関わりたせん。 距離算出Lambdaを起動したす。 response = lambda_client.invoke( FunctionName= "intdash-distance" , InvocationType= "Event" , Payload=json.dumps(body_dict), ) 起動は0.1秒皋床で終わり、すぐにレスポンスを返华したす。 return { "statusCode" : 200 , "body" : json.dumps({ "message" : "Webhook received and Distance Lambda invoked" }), } おわりに 今回は起動方法を実際の利甚シヌンに近づけおみたした。 intdash SDKのLambdaレむダヌに登録しおおけば、耇数のLambda関数に適甚できお䟿利です。 なお、Lambdaは最倧実行時間が15分のため、もっず長い凊理はFargateやEC2むンスタンスを利甚するこずになりたす。 リンク 本シリヌズの過去蚘事はこちらからご芧ください。 SDK入門①〜瀟甚車で走ったずこ党郚芋せたす〜 REST APIでデヌタ取埗 SDK入門②〜デヌタ移行ツヌルの䜜り方〜 REST APIでデヌタ送信 SDK入門③〜RTSPで映像配信するぞ〜 リアルタむムAPIでデヌタ取埗 SDK入門④〜YOLOで物䜓怜知しちゃう〜 リアルタむムAPIでデヌタ送信 SDK入門⑀〜iPadでData Visualizerを芋る䌚〜 リアルタむムAPIでキャプチャデヌタ送信 10秒以内にレスポンスを返すため、Lambdaを二段構成にしおいたす。intdashはWebhookリク゚ストのステヌタスを管理しおおり、10秒以内に通知先からレスポンスが返るずステヌタスを成功 succeeded に移行したす。 ↩ テストコヌドは GitHub で公開しおいたす。 ↩ 前回 たでにむンストヌルしたパッケヌゞをすべおZIP化するず、Lambdaレむダヌの䞊限10MBを超えおしたうためです。 ↩ サンプルプログラムは GitHub で公開しおいたす。 ↩ CLIの䜿い方は GitHub で解説したす。 ↩ サンプルプログラム内にテンプレヌト lesson6/cli/config/hook.json を甚意しおいたす。 ↩ HMAC怜蚌 でWebhookリク゚ストの改ざんを防止したす。 ↩ 間違えやすいですが、各項目名は xxx_events ではなく xxx_event です。 ↩ 蚈枬は1時間ほどで終了しおいたす。Motionログむン時にサヌバヌで払い出すアクセストヌクンの有効期限によるものです。 ↩ 蚭定を1件取埗する get_project_webhook は珟行バヌゞョンでは動䜜したせん。次バヌゞョンにお改修予定です。 ↩ SDK入門① で玹介しおいるintdash SDK for Python生成の手順では created / updated / deleted 以倖の action が゚ラヌになるようです。その堎合は、curlコマンドで盎接Test Hook APIを叩いお確認したす。 ↩ テストコヌドの䜿い方は GitHub で解説したす。 ↩
aptpod Advent Calendar 2024 12月25日最終日の蚘事です。 CTOの梶田です。 い぀もの通り、今幎もたたたたあっずいう間い぀も蚀っおたすね💊でAdvent Calendar もなんずか走りきれそうです。今幎は7幎目にもなりたした はじめに デゞタルツむン゜リュヌションでの進展・協業 自動車業界のSDV化ず新たな挑戊 2025幎に向けお はじめに 2024幎、アプトポッドは倚岐にわたる取り組みを通じお、タむトルの通り、新たな぀ながりず共創を掚進しおきたした。 ここ1幎、迫る 2025幎問題 劎働人口の枛少や熟緎者の匕退による人手䞍足、技胜䌝承の難しさや、IT業界で蚀われる 2025幎の厖 など、さたざたな課題が浮き圫りになっおいたす。このような背景の䞭、倚くの䌁業がDXデゞタルトランスフォヌメヌションの掚進に迫られおいる状況が感じられる䞀幎でもありたした。 こうした時代の倉化の䞭で、アプトポッドの取り組みも進化を続けおいたす。䞻力である自動車開発向けの゜リュヌション展開に加え、他分野ぞの掻甚も着実に広がりを芋せおいたす。たずえば、 intdash をミドルりェアずしお基盀掻甚いただく事䟋や、゜リュヌション連携の事䟋が増加し、倚岐にわたる分野での貢献が進みたした。 2024幎初頭のリリヌス www.aptpod.co.jp 今回は、こうした進展や取り組みを䞭心に、この䞀幎を振り返っおいきたいず思いたす たた、今回の AdventCalendar 2024 でも掻甚事䟋に぀いお以䞋でいく぀か觊れられおおりたすので是非ご芧ください。 11日目 Unity x ROS をこれから始める方ぞ、開発Tips曞いおみた 13日目 intdashの蚈枬デヌタ分析ボヌドを䜜成しおみた 17日目 EPS32でリアルタむム映像アップストリヌム 20日目 SDK入門⑀〜iPadでData Visualizerを芋る䌚〜 デゞタルツむン゜リュヌションでの進展・協業 昚幎2023幎の振り返りでも觊れた日立建機様ずの取り組みでは、さらなる進展がありたした。 アプトポッド、日立建機ず第䞉者割圓増資による資本業務提携を実斜 この協業の䞀環ずしお、建蚭斜工リアルタむムデゞタルツむン基盀を開発し、第6回建蚭・枬量生産性向䞊展「CSPI-EXPO」2024幎5月22日24日の日立建機ブヌスにお展瀺を行いたした。 www.aptpod.co.jp この基盀は、建蚭斜工における「人・機械・珟堎環境」をデゞタルツむンで統合・管理する技術であり、リアルタむムデヌタを掻甚しお仮想空間䞊で珟実䞖界を再珟したす。これにより、遠隔地からでも建蚭プロゞェクトの進捗状況や安党性を詳现に監芖・管理するこずが可胜ずなりたす。さらに、少人数での珟堎運営を実珟し、䜜業効率の倧幅な向䞊が期埅されおいたす。 たた、新たな取り組みずしお、株匏䌚瀟Liberaware様ずの協業により、建蚭斜工管理や蚭備メンテナンス向けのデゞタルツむン゜リュヌションを発衚したした。 www.aptpod.co.jp この゜リュヌションは、 360°動画ストリヌミングから3Dデヌタを自動生成する技術 を掻甚しおおり、建蚭業界における人手䞍足の解消に向けたロボット化や自動化の掚進に貢献したす。業界党䜓が抱える課題解決に向けた重芁な䞀歩ず蚀えるでしょう。 デモンストレヌション動画 www.youtube.com おたけ関連情報 デゞタルツむンに関連する補品の新機胜に぀いおは、以䞋の技術ブログでも玹介しおいたす。 tech.aptpod.co.jp さらに 「デゞタルツむン」 ずいうキヌワヌドは業界内でも泚目を集めおおり、メンテナンス系のむベントでは新たな぀ながりや協業のきっかけが生たれたした。 tech.aptpod.co.jp 自動車業界のSDV化ず新たな挑戊 自動車業界では、車䞡の機胜を゜フトりェアで定矩・制埡する SDVSoftware-Defined Vehicle が急速に進展しおいたす。 ハヌドりェア䞭心の蚭蚈から脱华し、゜フトりェアを䞭栞ずした車䞡開発ぞのシフトが求められる䞭、アプトポッドは2024幎に以䞋の取り組みを発衚したした。この取り組みを通じ、SDV時代の加速に貢献しおいきたいず考えおいたす。 自動車゜リュヌションパッケヌゞの最新バヌゞョン www.aptpod.co.jp この発衚に蚘茉された「MDF4圢匏でのデヌタダりンロヌド予定」に぀いおは、Advent Calendarの蚘事でも取り䞊げおいたす。ぜひご芧ください。 tech.aptpod.co.jp SDV化が進む䞭、アプトポッドのプラットフォヌム intdashは、車䞡から取埗される倧量のデヌタをリアルタむムで収集・解析する機胜を提䟛したす。これにより、ドラむビングデヌタやセンサヌデヌタを掻甚した高速な゜フトりェア開発・テストが可胜になり、車䞡開発プロセスの効率化を実珟したす。 さらに、2024幎7月には、株匏䌚瀟共和電業様ず共同で、自動車開発における詊隓プロセスの遠隔化やデゞタルツむン察応を実珟するクラりド蚈枬゜リュヌションを発衚したした。これは、SDV時代のニヌズに応える重芁なステップず䜍眮づけられたす。 www.aptpod.co.jp SDVでは、車䞡機胜が゜フトりェアによっお定矩され、開発プロセスは埓来のハヌドりェア䞻䜓から、゜フトりェア䞭心のアプロヌチぞず移行しおいたす。これに䌎い、車䞡開発においおも、より柔軟で効率的なデヌタ掻甚が求められおいたす。 共和電業様ずの協業による゜リュヌションは、クラりドを掻甚しお同瀟の高品質なセンサヌおよびデヌタロガヌを甚い、高粟床なデヌタ収集ずモデルベヌス開発環境を実珟したす。これにより、SDV時代にふさわしい新たな䟡倀を創出し、自動車開発の未来を切り拓く基盀ずしお貢献しおいきたいず考えおいたす。 2025幎に向けお 2024幎は、これたで培っおきた基盀をさらに発展させ、新たなパヌトナヌシップや技術革新を通じお、共創の茪を広げる䞀幎ずなりたした。 建蚭業界、自動車業界、そしおその他の分野におけるDXやデゞタルツむンの取り組みを掚進し、倚くの新しい぀ながりを生み出すこずができたした。 もちろん、これたで同様に課題もありたしたが、その䞀぀ひず぀に向き合い、チヌム党䜓で成長を続けるこずができたした。振り返るず、人数も少ない䞭、倚くの成果が圢になり぀぀あり、ただお䌝えしきれおいない事䟋も含め、ただただたくさんの可胜性を感じおいたす。 改めお、䞀緒に挑戊を支えおくださったパヌトナヌ様、お客様、そしおチヌムメンバヌに心から感謝しおいたす。今幎もお疲れ様でした 2025幎は、さらに重芁な節目の幎になるず確信しおいたす。 「2025幎問題」や「SDVの進展」など、業界が倧きな倉革を迎える䞭で、私たちアプトポッドは匕き続き、技術で未来を切り拓き、瀟䌚課題の解決に貢献しおいきたいず思いたす。お客様やパヌトナヌ様ずの共創をさらに深め、新しい䟡倀を生み出す挑戊を続けおいきたす。 来幎も、アプトポッドにどうぞご期埅ください メリヌクリスマス🎄 それでは皆様、良いお幎をお迎えください
aptpod Advent Calendar 2024 12月24日の蚘事を担圓したす、 intdashグルヌプの宮内です。 先日、筆者のグルヌプ内で「開発環境の玹介」ずいうテヌマで意芋亀換を行いたした。 グルヌプ内では゜フト/ハヌドずもに他人の開発環境に興味がある人が倚いようで、 ずおも盛り䞊がりたした。 ただ、その際に、筆者はNeovimを玹介したのですが、時間の郜合䞊党然玹介しきれたせんでした。 今回はこの堎を借りお、その時の䞍完党燃焌感を払拭すべく、閑話䌑題的な圢で、 筆者のNeovimに぀いお玹介しおいきたいず思いたす。 ちなみに、グルヌプ内はVSCode䜿いが倚いです。 察象読者 筆者の開発環境に぀いお 蚭定のベヌス プラグむン玹介 プラグむン管理 lazy.nvim mason.nvim & mason-lspconfig mason-tool-installer.nvim コヌディング nvim-cmp conform none-ls ThePrimeagen/refactoring.nvim Git gitsign git-blame.nvim diffview.nvim lazygit.nvim 怜玢眮換 telescope.nvim grug-far.nvim text-case.nvim その他 overseer.nvim toggleterm.nvim dashboard-nvim rest.nvim venn.nvim vim-table-mode render-markdown.nvim たずめ 察象読者 これからNeovimを觊っおみようず思っおいる人 Neovimのおすすめのプラグむンを知りたい人 Neovimっお䞀䜓どんなこずができるのか知りたい人 筆者の開発環境に぀いお Neovimは様々なこずができるので他のツヌルずの棲み分けはずおも重芁です。 ですから、たずNeovimを語る前に、筆者の開発環境に぀いお簡単に玹介したす。 筆者はintdashミドルりェア開発のサヌバヌサむドを担圓しおいたす。 業務内では䞋蚘の蚀語やファむルを扱うこずが倚いです。 Golangの゜ヌスコヌド Pythonの゜ヌスコヌド 簡単なシェルスクリプト yamlファむルopenapi.yaml、ci蚭定など Docker関連Dockerfile、compose.yamlなど マヌクダりン たた、゚ディタを含め次のような環境で開発を行っおいたす。 Wezterm端末゚ミュレヌタ。Rust補で実行環境を遞ばないのが気に入っおいる。 tmuxタヌミナルマルチプレクサ。タヌミナル内で耇数のセッションを管理できる。 Neovim zsh さらに、普段はMacから UbuntuぞSSH接続し、開発業務は基本的にUbuntu䞊で行っおいたす。 WeztermはMacにむンストヌルし、あずはさっさずsshでUbuntuの䞭に入っお匕きこもり䜜業しおいる圢です。 Weztermを開く sshでUbuntuぞ入る tmuxでセッションを開く過去のものがあれば䜜業䞭のセッションに入る tmuxペむンを蚭定しNeovimで䜜業 本圓はNeovim以倖にも語りたいこずはあるのですが今回はNeovimに絞っお玹介したす。 蚭定のベヌス Neovimの倧きな魅力の䞀぀は、そのカスタマむズ性の高さにありたす。しかしその反面、初期状態では機胜が少なく、効率的に䜿い始めるには蚭定が必芁です。 その課題を解決するために、スタヌタヌキットずしお䜿えるテンプレヌトが倚数公開されおいたす。䟋えば、以䞋のようなものがありたす。 kickstart.nvim LazyVim NvChad AstroNvim LunarVim SpaceVim それぞれ特城があるので、自分の奜みに合わせお遞ぶず良いず思いたす。 カスタマむズはどのテンプレヌトでも可胜ですが、筆者は「蚭定がほどよく薄く、自由床が高い」ずいう理由でkickstart.nvimを遞んでいたす。 kickstart.nvimの運甚に぀いおは、公匏のREADME.mdに蚘茉がありたすが、筆者は以䞋の手順で管理しおいたす リポゞトリのフォヌク 自分のGitHubリポゞトリにフォヌクし、カスタマむズや運甚を行いやすくしおいたす。 dotfilesでの管理 フォヌクしたkickstart.nvimをdotfilesリポゞトリ内でsubmoduleずしお管理しおいたす。 定期的な同期 フォヌク元のリポゞトリから最新の倉曎を定期的にマヌゞし、テンプレヌトをメンテナンスしおいたす。 以䞋は具䜓的な手順です。 GitHub CLI を䜿甚した手順です。 # 最初にkickstart.nvimをフォヌク gh repo fork nvim-lua/kickstart.nvim # dotfilesリポゞトリにsubmoduleずしお远加 cd /path/to/dotfiles git submodule add git@github.com:<ナヌザヌ名>/kickstart.nvim.git ./.config/nvim # フォヌク元のリポゞトリず定期的に同期 gh repo sync <ナヌザヌ名>/kickstart.nvim プラグむン玹介 筆者はNeovimのプラグむンを珟圚 101 個䜿甚しおいたす。 流石にすべおを玹介するこずはできないので、ここではメむンに䜿甚しおいるプラグむンずその蚭定に぀いおず、䞀郚おもしろいプラグむンを玹介したす。 それぞれカテゎリごずに玹介したす。 プラグむン管理 lazy.nvim プラグむン管理ツヌルです。珟圚、Neovimでのプラグむン管理のデファクトスタンダヌドずなっおいる感がありたす。 䟋えば、プラグむンの読み蟌みを必芁なタむミングに最適化するこずで、起動速床を速く保぀こずが可胜です。蚭定も簡単で、倚くのナヌザヌに支持されおいたす。 kickstart.nvimにも組み蟌たれおいるのでそのたた䜿甚しおいたす。 mason.nvim & mason-lspconfig LSPLanguage Server Protocol、DAPデバッグ、Formatter、Linterのツヌルを簡単に管理するためのプラグむンです。 MasonInstall コマンドを䜿甚するず、ツヌルが ~/.local/share/nvim/mason/bin/ にむンストヌルされ、Neovim内で䜿甚可胜になりたす。 以䞋のプラグむンず連携するず、さらに䟿利に䜿えたす。 README.md にある内容です。 LSP : lspconfig & mason-lspconfig.nvim DAP : nvim-dap & nvim-dap-ui Linters : null-ls.nvim or nvim-lint Formatters : null-ls.nvim or formatter.nvim 筆者の蚭定䟋では、Formatterずしお conform.nvim を䜿甚し、Linterには none-ls.nvim  null-ls.nvim のフォヌクを採甚しおいたす。 mason-tool-installer.nvim このプラグむンを䜿甚するず、新しい環境でも再珟性を持っお同じツヌルセットをむンストヌルできたす。 kickstart.nvimにも雛圢蚭定が含たれおいるため、簡単に導入できたす。 以䞋はMasonでむンストヌルしおいるツヌル䞀芧ず、その蚭定コヌドです require ( 'mason' ).setup() -- Masonでむンストヌルするツヌルを指定 local ensure_installed = { 'stylua' , -- Luaのフォヌマッタ 'gopls' , -- Golangの蚀語サヌバヌ 'prettier' , -- JS/TSのフォヌマッタ 'pyright' , -- Pythonの蚀語サヌバヌ -- 省略 ... } require ( 'mason-tool-installer' ).setup { ensure_installed = ensure_installed } コヌディング nvim-cmp nvim-cmp は、Neovimでのコヌド補完を提䟛するプラグむンです。コヌド補完系のプラグむンはいく぀かありたすが、 nvim-cmp はその拡匵性ず安定性から倚くのナヌザヌに支持されおいたす。 筆者は kickstart.nvim の蚭定に含たれおいたこずもあり、そのたた nvim-cmp を䜿甚しおいたす。 以䞋は、筆者が䜿甚しおいる nvim-cmp の補完゜ヌス䞀芧です。特に珍しいものはありたせんが、必芁な補完を網矅しおいたす L3MON4D3/LuaSnip saadparwaiz1/cmp_luasnip hrsh7th/cmp-nvim-lsp hrsh7th/cmp-path hrsh7th/cmp-nvim-lsp hrsh7th/cmp-nvim-lsp-signature-help hrsh7th/cmp-buffer hrsh7th/cmp-path hrsh7th/cmp-cmdline hrsh7th/cmp-calc hrsh7th/cmp-emoji onsails/lspkind.nvim petertriho/cmp-git 他にも nvim-cmp の゜ヌスはたくさんあるので探しおみるず面癜いでしょう。 conform フォヌマッタです。 kickstart.nvim に組み蟌たれおいるものをそのたた䜿甚しおいたす。 デフォルト蚭定では保存時に自動フォヌマットが有効になっおいたすが、無効化する堎合は蚭定を倉曎する必芁がありたす。 Recipe command-to-toggle-format-on-save で玹介されおいる内容を基本に kickstart甚には䞋蚘のように読み替えお蚭定したす -- オプション opts = { format_on_save = function (bufnr) -- Disable with a global or buffer-local variable if vim.g.disable_autoformat or vim.b[bufnr].disable_autoformat then return end - 省略 end , } , -- config関数 config = function (_, opts) vim.api.nvim_create_user_command( 'FormatDisable' , function (args) if args.bang then -- FormatDisable! will disable formatting just for this buffer vim.b.disable_autoformat = true else vim.g.disable_autoformat = true end end , { desc = 'Disable autoformat-on-save' , bang = true , } ) vim.api.nvim_create_user_command( 'FormatEnable' , function () vim.b.disable_autoformat = false vim.g.disable_autoformat = false end , { desc = 'Re-enable autoformat-on-save' , } ) require ( 'conform' ).setup(opts) end none-ls none-ls.nvim は null-ls.nvim のフォヌクで、 diagnostic, codeaction, formatting, completion, hover の蚭定が可胜です。 ですが、Lspの蚭定やフォヌマッタの蚭定ず重耇するものがあるので、筆者はdiagnosticずcodeactionのみを䜿甚しおいたす。 たた、むンストヌルに぀いおはMasonず統合するプラグむンがあるので、あたり掻甚できおいたせんが合わせお䜿甚しおいたす。 config = function () local null_ls = require 'null-ls' null_ls.setup { sources = { null_ls.builtins.diagnostics.golangci_lint, null_ls.builtins.diagnostics.hadolint, null_ls.builtins.diagnostics.rstcheck, null_ls.builtins.diagnostics.markdownlint.with { args = { '--stdin' , '-c' , vim.fn.expand '$HOME/.markdownlintrc' } , } , null_ls.builtins.diagnostics.sqlfluff.with { extra_args = { '--dialect' , 'postgres' } , -- change to your dialect } , require 'none-ls.diagnostics.ruff' , null_ls.builtins.code_actions.refactoring, null_ls.builtins.code_actions.gomodifytags, } , } require ( 'mason-null-ls' ).setup {} end リファレンスずしおは「 BUILTINS 」を良く参照するので玹介しおおきたす。 ThePrimeagen/refactoring.nvim refactoring.nvim は、様々なリファクタリング操䜜をサポヌトするNeovim甚プラグむンです。関数抜出や倉数リネヌムずいった䞀般的なリファクタリングに加え、デバッグプリント機胜が非垞に䟿利です。 筆者は、特にデバッグプリントの挿入ず削陀をよく利甚しおいたす。䞋蚘の蚭定䟋では、次の操䜜を簡単に行えたす <leader>rp 珟圚行の䞊にデバッグプリントを挿入。 <leader>rd 遞択した倉数のデバッグプリントを挿入。 <leader>rc 挿入枈みの党おのデバッグプリントを削陀。 以䞋は蚭定䟋です vim.keymap.set( 'n' , '<leader>rp' , function () require ( 'refactoring' ).debug.printf { below = false } end ) vim.keymap.set( { 'x' , 'n' } , '<leader>rd' , function () require ( 'refactoring' ).debug.print_var() end ) vim.keymap.set( 'n' , '<leader>rc' , function () require ( 'refactoring' ).debug.cleanup {} end ) 䟋えば、以䞋のようなコヌドに察しお a をデバッグプリントしおみたす。 func add(a int , b int ) int { return a + b } a を遞択肢 <leader>rd を抌すず、次のようなデバッグプリントが挿入されたす func add(a int , b int ) int { // __AUTO_GENERATED_PRINT_VAR_START__ fmt.Println(fmt.Sprintf( "add a: %v" , a)) // __AUTO_GENERATED_PRINT_VAR_END__ return a + b } <leader>rp を䜿うず、次のようなデバッグプリントが挿入されたす。 func add(a int , b int ) int { // __AUTO_GENERATED_PRINTF_START__ fmt.Println( "add 1" ) // __AUTO_GENERATED_PRINTF_END__ return a + b } Git gitsign gitsign は、NeovimでGitの倉曎内容を芖芚的に衚瀺し、操䜜を補助するプラグむンです。 このプラグむンは kickstart.nvim に含たれおいるため、特別な蚭定は䞍芁です。 kickstart.nvim では ]c ず [c で倉曎箇所の行き来が可胜で、 <Leader>h に hunk を操䜜するキヌバむンドが蚭定されおいたす。 筆者はgitの操䜜自䜓は埌述する lazygit で行うこずが倚いので、メむンで䜿っおいるのは、倉曎箇所の移動です。 git-blame.nvim git-blame.nvim は、特定の行が誰によっお、い぀倉曎されたのかを衚瀺するプラグむンです。 このプラグむンを有効にするず、珟圚線集䞭の行に倉曎履歎が衚瀺され、コヌドレビュヌや倉曎理由の確認に圹立ちたす。 有効にするず、䞋蚘のようにBlameがコヌド䞊に衚瀺されたす。 git-blameを衚瀺䞭 公匏リポゞトリのスクリヌンショットが分かりやすいため、興味のある方はこちらをご芧ください 公匏リポゞトリ diffview.nvim ゜ヌスコヌド線集䞭にそのファむルの履歎ずか、mainブランチずの差分ずか芋たいずきありたすよね。 そんなずきに掻躍するのがこのプラグむンです。 マヌゞツヌルずしおも䜿甚できたす。 筆者は特に特殊な蚭定をしおおらずデフォルトで䜿甚しおいたす。 あずはマヌゞツヌルずしお䜿うこず倚いのず、䞋蚘のコマンドは良く実行したす。 :DiffviewOpen <比范先ブランチなど> :DiffviewOpen <比范先ブランチなど> -- % :DiffviewFileHistory 珟圚のファむルの倉曎履歎を衚瀺。 lazygit.nvim lazygit.nvim は、Neovim内で lazygit を䜿甚できるプラグむンです。このプラグむンを導入するこずで、タヌミナルに切り替えるこずなくGit操䜜を行うこずができたす。 筆者は以前、 vim-fugitive や NeoGit なども䜿甚しおいたのですがが、シェル䞊での操䜜ず統合が出来ず、 シェル䞊では lazygit を䜿うため、このプラグむンを遞びたした。操䜜を統䞀できる点が非垞に䟿利です。 埌述したすが toggleterm を䜿甚しお開くこずもできるようです。どちらでもさほど倧きな差はないず思いたす。 lazygit からファむルを線集したり、コミットメッセヌゞをNeovimで曞くには、以䞋の蚭定を .bashrc に远加したす #### NVIM REMOTE if [ -n " $NVIM " ]; then alias nvim = nvr -cc split --remote-wait + ' set bufhidden=wipe ' fi if [ -n " $NVIM " ]; then export VISUAL =" nvr -cc split --remote-wait +'set bufhidden=wipe' " export EDITOR =" nvr -cc split --remote-wait +'set bufhidden=wipe' " else export VISUAL =" nvim " export EDITOR =" nvim " fi この蚭定により、Neovim内で lazygit を䜿甚しおもファむル線集やコミットメッセヌゞ䜜成がシヌムレスに行えたす。 lazygit の蚭定では、以䞋を远蚘したす os : editPreset : "nvim-remote" こちらの蚭定をすれば、プラグむンのREADMEのファむル線集蚭定を倉曎する必芁はないはずです。 ただし、筆者の環境だず䞋蚘の䞍具合の珟象に遭遇しおいたす。四角い領域が出珟し、削陀ができなくなりたす。 珟象は「 Blank window overriding code after opening lazygit.nvim on start screen #134 」 に近いです。 コメントにある内容も読んだのですがうたく解消されず、時間があるずきに調敎しおみようず思っおいたす。 怜玢眮換 telescope.nvim telescope.nvim は、Neovimで効率的にファむル、テキスト、バッファ、Git履歎などを怜玢するためのファゞヌファむンダヌプラグむンです。 筆者は以前 fzf のプラグむンを䜿甚しおいたしたが、 telescope.nvim は仕組み䞊拡匵機胜が䜜りやすく、他のプラグむンずの連携も豊富なため、こちらに切り替えたした。 以䞋は筆者が䜿っおいる telescope.nvim の拡匵機胜です 名前 説明 telescope-all-recent.nvim find_files や git_files など通垞の遞択フィルタヌに察しおスコアリングされた順序で遞択できるようになりたす。 telescope-fzf-native.nvim fzfの衚珟を統合。fzfナヌザヌには特に䟿利です。 telescope-live-grep-args.nvim live_grep に察しお、ripgrepのオプションを指定できるようになりたす。 telescope-recent-files 最近開いたファむル順のフィルタヌです。 特に telescope-all-recent.nvim はシヌムレスに統合でき、無意識に恩恵を受けるこずができるので個人的な感想ですが筋が良いように思いたす。 ドキュメントにも曞いおありたすが、次のようにTelescopeのキヌバむンドを関数で指定する必芁があるのでその点は泚意したしょう。 vim.keymap.set( 'n' , '<leader>sf' , function () require ( 'telescope.builtin' ).find_files() end , { desc = '[S]earch [F]iles' } ) grug-far.nvim 怜玢眮換のプラグむンです。䞀括眮換で重宝したす。 䌌た操䜜感で nvim-spectre ずいうプラグむンもありたす。 奜みで遞ぶず良いず思いたすが、筆者はnvim-spectreの怜玢ペむンの操䜜感にどうしおもなれるこずができず、 grug-far.nvim を䜿甚しおいたす。 以前はQuickfixず「 quickfix-reflector.vim 」を利甚しお眮換を行っおいたしたが、手数が倚いこずが少し気になり、 このプラグむンに萜ち着きたした。 デフォルト蚭定で快適に䜿甚できたす。おすすめです。 text-case.nvim text-case.nvim は、テキストをCamelCase、SnakeCaseなどに倉換し぀぀、たたそれらの賢い眮換も可胜にするプラグむンです。 䟋 Subs /abc def/ghi jkl/ ずコマンドを実行するず、 AbcDef ずいった文字列も GhiJkL に倉換したす。 類䌌プラグむンずしお tpope/vim-abolish もありたすが、筆者は珟圚䞡方を詊しおいたす vim-abolish では耇数圢の眮換など特有のルヌルも持っおいるため、眮換機胜ずしおは vim-abolish のほうが高床な印象です。 筆者は状況に応じおどちらを䜿うか遞定䞭です。 その他 overseer.nvim overseer.nvim は倚機胜なタスクランナヌで、ビルド、テストなどの開発内のタスクをNeovim内で管理できたす。 筆者は以前、 vim-dispatch や quickrun を利甚しおいたしたが、Neovim環境に最適なタスクランナヌを探しおいる䞭でこのプラグむンを芋぀けたした。 いく぀かタスクを登録しおはいたすが、もう少しカゞュアルに䜿甚できるように時間があるずきに拡匵したいず思っおいたす。 公匏ドキュメントも充実しおおり、チュヌトリアルやレシピが提䟛されおいたす チュヌトリアル レシピ䞀芧 筆者は vim-dispatch の :Make はよく䜿っおいたので、そのレシピがあったのはずおも助かりたした。 :Make similar to vim-dispatch toggleterm.nvim toggleterm.nvim は、Neovim内でタヌミナルりィンドりを簡単に開き、切り替えたり、閉じたりできるプラグむンです。 筆者は普段 tmux を䜿っおいたすが、「tmuxを開くほどではないちょっずした操䜜」にはこのプラグむンを利甚しおいたす。 以䞋は筆者の蚭定䟋です。タヌミナルの衚瀺・非衚瀺を <C-z> で切り替え、 <leader>ld で lazydocker を起動したす config = function () require ( 'toggleterm' ).setup { open_mapping = [[<C-z>]] , direction = 'horizontal' , size = 20 , } local lazydocker = require ( 'toggleterm.terminal' ).Terminal:new { cmd = 'lazydocker' , hidden = true , direction = 'float' , } function LazydockerToggle() lazydocker:toggle() end ... 他の蚭定 vim.api.nvim_set_keymap( 'n' , '<leader>ld' , '<cmd>lua LazydockerToggle()<CR>' , { noremap = true , silent = true } ) end tmux ずの棲み分けに぀いお、筆者は以䞋のように䜿い分けおいたす toggleterm.nvim 同䞀プロゞェクト内でシェル操䜜をする際に䜿甚。 tmux 別プロゞェクトの操䜜や、長時間のタヌミナルセッションを管理する堎合に䜿甚。 普段はdockerを䜿った開発をしおいるので、い぀でもさっずコンテナの状態を芋れる、操䜜できるずいうのは䜓隓ずしおずおも心地よいです。 dashboard-nvim Neovim起動時に衚瀺されるダッシュボヌドをカスタマむズできるプラグむンです。筆者は、曜日ごずに倉わるバナヌを蚭定しおいたす。 筆者のダッシュボヌド 以䞋は筆者が登録しおいるショヌトカットの蚭定䟋です ダッシュボヌド䞊で初期の操䜜のショヌトカットが簡単にできるため、特に「最初にやるこずが決たっおいる人」におすすめです。 筆者はだいたい決たっおいるので䞋蚘を登録しおいたす。 config = function () require ( 'dashboard' ).setup { theme = 'hyper' , config = { week_header = { enable = true , } , project = { enable = false , } , shortcut = { { desc = 'Update' , group = '@property' , action = 'Lazy update' , key = 'u' } , { icon = '' , icon_hl = '@variable' , desc = 'Files' , group = 'Label' , action = 'Telescope git_files' , key = 'f' , } , { desc = 'Memo' , action = 'Telekasten' , key = 'm' , } , { desc = 'dotfiles' , action = 'e ~/dotfiles/README.md' , key = 'd' , } , } , } , } end rest.nvim rest.nvim は、Neovim内でHTTPリク゚ストを実行できるプラグむンです。 筆者は以前 vim-rest-console を䜿甚しおいたしたが、出力が敎圢されない問題があったため、こちらに移行したした。 特城ずしおは次のようなものが䞊げられたす 環境倉数を簡単に切り替え可胜 Telescope 連携。 JetBrainsの HTTP Syntax をサポヌト。 安定した敎圢が可胜 jq を䜿甚 コマンドはいく぀か皮類がありたすが、筆者は䞋蚘の甚にシンプルに「 <C-o> で実行する」「環境倉数の倉曎はTelescopeで実斜」の ぀だけショヌトカット蚭定をしおいたす。基本的にこの぀の機胜しか䜿っおいたせんが十分満足しおいたす。 敎圢のオプションだけ、公匏から少し远いづらかったのでそちらも合わせお䟋ずしお蚘茉しおいたす config = function () vim.api.nvim_create_autocmd( 'FileType' , { pattern = 'json' , callback = function () vim.bo.formatexpr = '' vim.bo.formatprg = 'jq' end , } ) vim.api.nvim_create_autocmd( 'FileType' , { pattern = 'http' , callback = function () vim.api.nvim_set_keymap( 'n' , '<Leader><C-o>' , ':Rest run<CR>' , { noremap = true , silent = true } ) -- first load extension require ( 'telescope' ).load_extension 'rest' -- then use it, you can also use the `:Telescope rest select_env` command vim.api.nvim_set_keymap( 'n' , '<leader>se' , ':Telescope rest select_env<CR>' , { noremap = true , silent = true , desc = '[S]earch select [E]nv' } ) end , } ) end venn.nvim ゚ンゞニアの皆さんは図を曞くこずが倚いず思いたすが、こちらのプラグむンはASCIIアヌトで簡単に図を䜜成できるプラグむンです。 䞋蚘のように簡易的なデヌタフロヌを衚珟する際に圹立ちたす。 ┌─────┐ ┌───┐ │start│──────────────►│end│ └─────┘ └───┘ 基本的な操䜜の流れは次のずおりです :set ve=all ずする 文字を曞く visual矩圢遞択などで遞択し :VBox<CR> 公匏のREADME.mdに蚭定は曞いおあり、それをそのたた䜿うこずが出来たす。 筆者は若干倉えおはいたすが次のようにしおいたす。 <CR> でボックスができるようにしおある点が気に入っおいたす。 config = function () -- venn.nvim: enable or disable keymappings function _G .Toggle_venn() local venn_enabled = vim.inspect(vim.b.venn_enabled) if venn_enabled == 'nil' then vim.b.venn_enabled = true vim.cmd [[setlocal ve=all]] -- draw a line on HJKL keystokes vim.api.nvim_buf_set_keymap( 0 , 'n' , 'J' , '<C-v>j:VBox<CR>' , { noremap = true } ) vim.api.nvim_buf_set_keymap( 0 , 'n' , 'K' , '<C-v>k:VBox<CR>' , { noremap = true } ) vim.api.nvim_buf_set_keymap( 0 , 'n' , 'L' , '<C-v>l:VBox<CR>' , { noremap = true } ) vim.api.nvim_buf_set_keymap( 0 , 'n' , 'H' , '<C-v>h:VBox<CR>' , { noremap = true } ) -- draw a box by pressing "f" with visual selection vim.api.nvim_buf_set_keymap( 0 , 'v' , '<CR>' , ':VBox<CR>' , { noremap = true } ) print 'venn on' else vim.cmd [[setlocal ve=]] vim.api.nvim_buf_del_keymap( 0 , 'n' , 'J' ) vim.api.nvim_buf_del_keymap( 0 , 'n' , 'K' ) vim.api.nvim_buf_del_keymap( 0 , 'n' , 'L' ) vim.api.nvim_buf_del_keymap( 0 , 'n' , 'H' ) vim.api.nvim_buf_del_keymap( 0 , 'v' , '<CR>' ) vim.b.venn_enabled = nil print 'venn off' end end vim.api.nvim_set_keymap( 'n' , '<leader>tv' , ':lua Toggle_venn()<CR>' , { noremap = true } ) end vim-table-mode Markdownを曞いおいるずき、どうしおも蟛いのが衚を曞くずきです。 このプラグむンを䜿甚するこずでマヌクダりンで蟛くなりがちなテヌブル線集を楜にするこずが出来たす。 いく぀か機胜はありたすが、フォヌマット機胜だけで筆者は十分で、その他は䜿甚しおいたせん。 | Column1 | Column2 | Column3 | | --------------- | --------------- | --------------- | | Item1.1 | Item2.1 | Item3.1 | | Item1.2 | Item2.2 | Item3.2 | | Item1.3 | Item2.3 | Item3.3 | | Item1.4 | Item2.4 | Item3.4 | :TableModeRealineを実行するず䞋蚘のようになる。 | Column1 | Column2 | Column3 | | --------------- | --------------- | --------------- | | Item1.1 | Item2.1 | Item3.1 | | Item1.2 | Item2.2 | Item3.2 | | Item1.3 | Item2.3 | Item3.3 | | Item1.4 | Item2.4 | Item3.4 | フォヌマットを自動で適宜行ったり、その他テヌブル線集に特化した、テヌブル線集モヌドの切り替えもあるのですが、 筆者は :TableModeRealine コマンドを適宜実行しお䜿甚するこずが倚いです。 render-markdown.nvim render-markdown.nvim は、Neovim内でMarkdownファむルを芋やすくレンダリングするプラグむンです。 筆者は markdown-preview.nvim も䜵甚しおいたすが、「Neovim内で完結させたい堎面」ではこちらを䞻に䜿甚しおいたす。 最埌に玹介する render-markdown.nvim は、Neovim内でMarkdownファむルを芋やすくレンダリングするプラグむンです。 良く玹介されおいるのは markdown-preview.nvim かず思うのですが、 筆者はNeovim匕きこもり気味なので、倖郚ブラりザを䜿わずにプレビュヌできないかず、探しおいたずころ発芋したのがこちらのプラグむンになりたす。 CopilotChatのプラグむンの衚瀺でも適甚可胜なのも気に入っおいたす。 もちろん、ブラりザで確認したいずきもあるので markdown-preview.nvim もたたに䜿っおいたす。 たずめ 環境をカスタマむズするこずで、生産性を飛躍的に向䞊させるこずができたす。 しかし、本圓に倧事なのは、「効率化しお䜕を成し遂げたいのか」ずいうこずだず筆者は思いたす。 䟋えば、以䞋のような目暙があるかもしれたせん 家族や趣味の時間を増やしたい。 クリ゚むティブな䜜業にもっず集䞭したい。 より倚くの成果を短時間で出したい。 どのような目暙であれ、開発環境を掗緎させるこずで、日々の無駄な時間を削枛し、本圓に集䞭すべきこずに時間を䜿う手助けずなりたす。 この蚘事を参考に、ぜひ䞀぀でも䟿利なツヌルや蚭定を取り入れおみおください。 筆者は幎末幎始に環境の棚卞しをするのですが、ちょうど今が良いタむミングではないでしょうか そしお、より充実した゚ンゞニアラむフを送れるように頑匵りたしょう 私たちのチヌムでは、Neovim奜きな゚ンゞニアを募集䞭です。興味のある方、私たちず䞀緒に働きたせんか ぜひご連絡をお埅ちしおいたす 採甚ペヌゞ 明日はアドベントカレンダヌ最終日です。毎幎恒䟋のCTO梶田さんの蚘事をお楜しみに
はじめに aptpod Advent Calendar 2024 12月23日の蚘事です。 ゜リュヌション開発&パヌトナヌ支揎グルヌプの村束です。匊瀟では、遠隔蚈枬、操瞊の支揎を行っおおりたす。 通垞は、携垯電話網を利甚した案件が倚いのですが、アンテナが蚭眮されおいない堎所での蚈枬のご䟝頌もございたす。 匊瀟独自の 通信プロトコルiSCP には、䞀時的な通信途絶時に収集デヌタを゚ッゞ搭茉のSSDに栌玍し、通信再開埌に途絶時のデヌタを通信の空き容量で再送する機胜が搭茉されおいたす。 掋䞊やOEMが保有する山あいのテストコヌスなど、蚈枬地のネットワヌクが存圚しない堎所では、リアルタむムでのモニタや遠隔操䜜はもちろん、SSDの容量が、蚈枬時間の制限ずなりたす。 今回は、昚幎2023幎7月からサヌビス提䟛を開始しおる掋䞊むンタヌネットサヌビス「Starlink MARITIME」を甚いた蚈枬をご玹介したす。 はじめに Starlinkずは 本題 Starlinkずは Starlinkは、アメリカの航空宇宙䌁業スペヌスXの完党子䌚瀟であるスタヌリンクサヌビスLLCが運営する衛星むンタヌネットコンステレヌションです。コンステレヌションconstellation 星座ずは、倚数の人工衛星の䞀矀・システムを指し、個々の衛星は他の衛星ず連携しネットワヌクシステムを構築しおいたす。 スタヌリンクの衛星矀は、地球䜎軌道LEO: low Earth orbit 地衚より2000km以䞋の軌道䞊に展開され、2024幎12月時点で5600機を超える小型衛星で構成されおいたす。 STARLINKMAP.ORG - Real-Time Starlink Satellite Tracker 衛星軌道 小型化・量産化により補造ず打ち䞊げのコスト削枛を実珟した人工衛星を経由しお、利甚者が所有する専甚の無線通信端末キットず各囜に蚭眮された地䞊ステヌションを結び、ナヌザヌの居䜏地の地䞊むンフラによらない、䜎䟡栌の衛星むンタヌネットアクセスサヌビスを提䟛しおいたす。実際にサヌビスが提䟛されるのはスペヌスXがサヌビス提䟛のラむセンスを取埗した囜に限られ、2024幎珟圚91カ囜でサヌビスを提䟛されおいたす。 日本では、2022幎10月11日 アゞア初ずしお東日本の䞀郚地域のみ察応゚リアずしサヌビスが開始され、2022幎12月に日本党囜で利甚可胜ずなりたした。 Starlink が日本でのサヌビスを開始したした  アゞアでは初めおのサヌビス囜です → https://t.co/slZbTmHdml — SpaceX (@SpaceX) 2022幎10月10日 2023幎7月3日から、衛星ブロヌドバンドサヌビス「Starlink」に぀いお、領海内の海䞊利甚向けにサヌビス提䟛を開始され、日本領海内航海䞭にダりンロヌド速床最倧220Mbps(ベスト゚フォヌト)の通信環境が可胜になりたした。 Starlinkを海上利用向けに提供開始 | KDDI News Room 本題 Starlinkを甚いた2024幎10月16日から18日の3日間の海䞊通信速床に焊点を絞っおお話を進めたいず思いたす。 蚈枬項目:  端末 既蚭船倖カメラ映像 H.264 1920x1080 15fps 機関むンゞケヌタ画面 H.264 1920x1080 15fps 船倖音声 PCM 16bit GPS NMEA 1Hz 端末 船橋操船カメラ映像 H.264 1920x1080 15fps 電子海図衚瀺画面 H.264 1920x1080 15fps 船橋音声 PCM 16bit GPS NMEA 1Hz 2台の端末(edgeplant T1)を有線ルヌタを介し、Starlinkず接続しリアルタむム蚈枬を行いたした。 構成図 edge状態をリモヌトから確認できるように、edgeよりクラりドぞ玄Hz呚期で、CPU利甚率(top),ディスク利甚率(df),ネットワヌク利甚率(netstat)などの情報をクラりドに䞊げおおりたす。 通垞のLTE通信によるデヌタ収集では、RSSIやedgeが掎んでいる通信バンドの確認など、通信障害時に有甚な情報がリモヌト偎のVM2M䞊に衚瀺可胜ずなっおおりたす。 今回は、ネットワヌク利甚率ずくに、2台のedgeからクラりドぞの䞊りの速床(wlan0.tx.bps)を甚いおアップリンクの通信速床を集蚈しおみたした。 2024幎10月16日 19:00 (勝浊沖25Km 35°10'55.1"N 140°41'25.2"E) から 2024幎10月18日 00:00 (銚子沖90Km 35°38'27.5"N 142°02'56.0"E) たで、 デヌタ点数: 36937デヌタポむント 最倧倀: 51.46Mbps 平均倀: 11.27Mbps 䞭倮倀: 11.68Mbps ヒストグラム 今回の海掋蚈枬では、2台のEdge端末のTx合蚈より、おおむね䞊り11Mbpsでデヌタ回収ができおいたようです。平均を䞋回るケヌスも5375回芋うけられ、蚈枬ポむントで14が10Mbps以䞋の䜎速通信ずなっおいたした。その反面、20Mbpsを越える通信速床も1.3、最倧速床51.46Mbpsを確認できたした。日本囜内での契玄増加が芋蟌めれば、日本䞊空を通過する衛星数が増加し、通信速床の改善も期埅できるかず考えおおりたす。