出展の概要 会場の印象 アプトポッドブースの展示 点検・警備ソリューション メーター読み取り 四足歩行ロボット以外の連携：ドローン・ウェアラブルカメラ・サーマルカメラ 通信 リアルタイムデジタルツインソリューション 映像3Dモデル化デモ フィジカルAI 来場者の反応 まとめ こんにちは、クロスインダストリー事業部ソリューション開発グループの影山です。同事業部で製品・ソリューションの開発を担当しています。 この度、株式会社アプトポッドは、2026年7月15日（水）から17日（金）までの3日間、東京ビッグサイト東展示棟で開催された「メンテナンス・レジリエンス 2026」に出展しました。おかげさまで3日間を通して多くの方にブースへお立ち寄りいただきました。ありがとうございました。 https://mente.jma.or.jp/ 今年は、点検・警備、リアルタイムデジタルツイン、フィジカルAIといったトピックにフォーカスして展示を行いました。本記事では、それぞれについてご紹介していきたいと思います。 出展の概要 アプトポッドは産業用IoTミドルウェア「 intdash 」を提供しています。これまで自動車開発や建設機械の領域で導入いただいてきましたが、設備の点検・保全という領域でもintdashの特長を生かせると考え、さまざまなユースケースのデモや事例を展示しました。intdashはマルチモーダルなデータをリアルタイムに扱うことに長けています。カメラ映像、LiDARの点群、ロボットのROSトピック、ガスセンサーの値、既存設備のデータといった、種類も周期もばらばらな大量のデータを、時刻を揃えたままリアルタイムに集めて遠隔から扱いたい、というニーズにマッチします。 www.aptpod.co.jp 今回のデモ全体の構成図 今回の出展では、複数の四足歩行ロボットを動かして点検をデモしたり、同時にドローンの映像をintdashへ転送したりといった実演を通じて、メーカーも種類も異なる機体・センサーを、intdashという1つのデータ基盤の上で運用する様子を、実機と画面でそのままご覧いただきました。 会場の印象 会場を歩いていて印象的だったのは、点検ロボットやドローンを展示しているだけでなく、実際に動かしているブースが非常に多かったことです。人手不足を背景に、インフラ・プラントの点検をいかに自動化・省人化するかというテーマが、実証段階から運用段階へ移りつつあることを感じました。 アプトポッドブースの展示 アプトポッドブースの様子 点検・警備ソリューション 点検や警備の分野では、人手不足が課題になっているというお話をうかがうことが特に多くなっています。よくうかがう課題は、人が現場に行かないと状況が分からないこと、計器の値を人が目視で読む必要があること、定置センサーがない箇所は人が足を運ぶしかないことです。 ブースの前面では、「カメラやセンサーを搭載したロボットが自律的に現場を歩いて移動する」「ロボットが撮影した画像をAIが解析して数値にする」「ロボットからのデータとAIの解析結果を、すべて1つのintdashの画面でリアルタイムに見る」という組み合わせで実演しました。 ブース内には昇降ステップやダミーの計器を配置して簡易的なプラントを模擬し、そのなかを Unitree Go2 や Unitree A2 が走行しました。 デモエリアを歩き回るロボットたち Unitree Go2 では、 パナソニック アドバンストテクノロジー株式会社 様の自律移動ソフトウェア「@mobi」を使い、事前に作成した地図とウェイポイントに沿ってブース内を巡回します。頭部カメラに加えて、背中に3D LiDAR（Livox Mid-360）と360度カメラ（Insta360 X5）、そしてCO2センサーを搭載しました。 adtsd.jpn.panasonic.com Go2の背中。3Dプリンタ製のケースに360度カメラとアンテナ、CO2センサーを載せています Unitree A2 は最近発売された新機種で、防塵防水に対応しており、重いペイロードも搭載できます。今回は自律走行は行わず、intdashを経由した遠隔操縦のデモを行いました。遠隔操縦だけでなく、 株式会社ザクティ 様のPTZカメラの向きを遠隔から操作できるようにし、さらに 理研計器株式会社 様のマルチガスセンサー GX-3R Pro を搭載して、ガスのセンサー値をリアルタイムにintdashへ送りました。PTZカメラを遠隔からパン・チルト・ズームさせて、離れた場所の計器を読みに行く、という使い方ができます。 A2の背中。PTZカメラとマルチガスセンサーを搭載しています product.rikenkeiki.co.jp xacti-co.com ブースの入り口で展示していた Unitree Go2-W は、脚の先が車輪になっているモデルで、こちらには TechShare 社株式会社 様の自律移動パッケージ「Patrobot」を載せています。搭載しているのはCO・アルコールガスセンサーと放射温度計。ガス漏れと発熱という、プラント点検で真っ先に見たい2つを歩きながら測るイメージです。 展示では昇降ステップを並べて段差を作り、ロボットが階段状の障害物を昇り降りする様子もご覧いただきました。 ブース内を自律走行して、メーターの自動読み取りを行うUnitree Go2 techshare.co.jp メーター読み取り アナログ計器は、人が値を目視で読み取って記録する作業が必要です。それを自動化する例として、ロボットのカメラ映像からメーター領域を切り出し、「hakaru.ai」 の認識APIに問い合わせて数値に変換するデモを行いました。 読み取った値は、そのまま intdash の時系列データとして扱えます。intdashへ送ることで、カメラの映像などと並べてメーターの読み取り値を確認できます。また、リアルタイムに見るだけでなく、あとからAPIを利用して回収することもできます。 切り出されたメーター画像と読み取り値。CO2濃度や人物検出数と同じ画面に並びます www.hakaru.ai 四足歩行ロボット以外の連携：ドローン・ウェアラブルカメラ・サーマルカメラ 四足歩行ロボット以外にも、ドローン、ウェアラブルカメラ、サーマルカメラとの連携を展示しました。 ドローンのデモでは、ドローン搭載カメラのライブ映像をintdashへ送り、高所や空中からの確認が可能なことを紹介しました。俯瞰位置に設置したサーマル監視カメラ（EDGEPLANT T1 経由）では、RGB映像とサーマル映像を同時に配信し、温度異常を色で確認できることを紹介しました。 株式会社ザクティ 様のウェアラブルカメラは Raspberry Pi 経由で接続し、ブレ補正された作業者目線の映像を送れることを実演しました。 これらの映像については、サーバー側でYOLOによる人物・物体検出を行い、映像を後処理して検知することも可能であることをデモしました。 ロボット・固定カメラ・人・ドローンという性格の違うデータソースを、intdashで統合して確認できることが、このソリューションの大きな特長の一つです。 ドローンの映像も、ロボットやカメラと同じ画面で確認できます xacti-live.com 通信 各ロボットには回線ボンディングに対応した Peplink MAX BR2 Micro を利用し、混雑した会場内でも2回線を束ねることで安定したモバイル通信を実現しました。 www.caso.co.jp リアルタイムデジタルツインソリューション このエリアでは、施工現場の状況を仮想空間に再現するリアルタイムデジタルツイン基盤をご覧いただきました。画面には現場の3D点群が広がり、その上に車両の走行軌跡が重なります。同じ画面の中に掘削量・盛土量といった土量の数値、地表の断面形状のグラフ、そして車載カメラの映像が並び、すべてが同じ時間軸で再生されます。「現場のいつ・どこで・何が起きていたか」を、後から3D空間ごと巻き戻して確認できる、というイメージです。 3D点群の上に車両の走行軌跡、土量、断面形状、車載カメラ映像が同じ時間軸で並びます 実際に動いている様子は、こちらの動画でご覧いただけます。 www.youtube.com 映像3Dモデル化デモ ブースを iPhoneアプリ intdash Motionで撮影した映像データを、 株式会社Liberaware 様が提供する「 LAPIS 」に連携して点群化し、3Dモデルとして表示しました。 専用の3Dスキャナーだけでなく映像を起点として空間を3D化できるため、設備や現場の状況把握、遠隔からの確認など、さまざまな活用が期待できます。映像を見るだけの監視から、空間として記録・参照する活用へ広がる点が興味深い展示でした。 www.youtube.com フィジカルAI フィジカルAIのエリアでは、これから応用が進んでいくであろうこの分野でも、intdashを活用できそうな事例をご紹介しました。 ロボットやAIを現場で賢く動かすには、大量の現実世界のデータが必要です。一方で、危険な状況やめったに起きない事象は、実環境ではなかなか集められません。そこで、実環境から集めたデータと、シミュレーション環境（Gazeboなど）で生成したデータを、intdash で同じように収集・蓄積する構成をご紹介しました。 あわせて、学習データの収集からアノテーション、モデル開発、実機へのOTAによるモデルデプロイ、そして運用時の遠隔監視・遠隔診断・遠隔制御介入までを一連のパイプラインとして構成する取り組みも、 FastLabel 株式会社様との連携例としてご紹介しました。動画像と関節角度・圧力といったマルチモーダルなデータを、時刻を揃えたまま時系列データベースに蓄積できることが、この構成の前提になっています。 収集したデータを使える形に整えるデータ加工レイヤも重要です。データ収集レイヤであるintdashから必要な時系列データを取得し、解析処理を行ったうえで、運用に必要な形に出力する仕組みが求められます。その一例として、Power BIとintdashを連携させるデモを展示しました。 データ収集レイヤ・加工レイヤ・活用レイヤの3層構成 来場者の反応 ブースでは、プラントや工場の設備保全、倉庫や施設の点検業務のDX推進など、さまざまな立場の方にお立ち寄りいただきました。 四足歩行ロボットによる巡回点検の展示について、反応を多く頂きました。ロボットの導入を考えてはいるものの、まず何から始めればよいのか悩んでいる、という声も多くうかがいました。 「カメラやセンサーはすでに導入しているが、形式も周期もばらばらで突き合わせられない」といった、データのサイロ化に関する課題を挙げられる方もいらっしゃいました。マルチモーダルな時系列データを時刻を揃えて収集するという intdash のアプローチについて、その必要性を実感を持って受け止めていただけたケースも多かったように思います。 まとめ メンテナンス・レジリエンス 2026 にご来場いただき、アプトポッドブースにお立ち寄りいただいた皆さま、誠にありがとうございました。 アプトポッドは、intdash を通じて、現場点検のロボット化・遠隔化、複数のカメラやセンサーを統合したリアルタイム可視化、現場のデジタルツイン化、ロボット・AI開発のためのデータ基盤といった、さまざまな領域で現場のデータ活用を支援してまいります。お困りごとがありましたら、ぜひ お問い合わせフォーム からご連絡ください。

こんな方へ特におすすめ エヴァンゲリオンが好きな方 ローカルLLM（ Ollama ）や Raspberry Pi で、何か動くものを作ってみたい方 LangGraph でマルチエージェントを試したい方 概要 こんにちは。サイオステクノロジーのはらちゃんです！ 今回はOSCの展示ブース用開発として、『新世紀エヴァンゲリオン』の意思決定コンピュータ MAGI を、Raspberry Pi 3台 + ローカルLLM（Ollama）で再現してみました。 ―― 3体の人格が別々のマシンで議論し、多数決で結論を出す その設計や速度チューニング、実機を立ち上げる過程でハマった落とし穴まで、実務にも通じる知見をまとめていきます。 背景 MAGI は、3つの独立したコンピュータ Melchior・Balthasar・Casper が、それぞれ異なる人格で同じ議題を判断し、多数決で結論を出す合議システムです。 これをただの1プログラムで再現するのは簡単です。 でも、それだと何かが違う。「 1エージェント = 1台の独立コンピュータ 」という原作の設定を、そのまま物理的に再現できないだろうか？ 武井さん の協力の元、Raspberry Pi を3台並べることにしました。とはいえ、非力な Raspberry Pi でLLMなんてまともに動くのか、と最初は半信半疑でした。 結論から言うと、役割を割り切って軽量モデルとチューニングを重ねれば、合議AIは十分に動きます。 システム構成｜3台の Pi + 母艦 役割分担はシンプルです。 各Pi は、ただの推論バックエンド。Ollama が待ち受けているだけで、人格ごとのプログラムは書きません。 母艦（オーケストレータ） となる1台のPCが、合議の進行・集計・画面表示を担当します。今回は PC上の WSL2 で Flask + LangGraph を動かしました。 ブラウザ / kiosk UI       ▲ ▼   SSEで投票をリアルタイム配信 母艦 — Flask + LangGraph（合議・集計）       ▲ ▼   イーサネット（各Piのollama :11434） +-----------------+-----------------+-----------------+ | Pi1 Melchior | Pi2 Balthasar | Pi3 Casper | | Ollama | Ollama | Ollama | +-----------------+-----------------+-----------------+ どのPiがどの人格かは、母艦の `.env` にある 各Piの固定IPだけ で決まります。人格ごとの特別なコードは無く、role名で接続先を引くだけ。この割り切りのおかげで、Pi側は「モデルを入れて待ち受ける」だけで済みます。 合議フロー｜LangGraphで組む2ラウンド投票 合議の本体は LangGraph の StateGraph です。1回目で全会一致なら即確定、意見が割れたら「討論」を挟んで再投票する、という2ラウンド構成にしました。 prepare ：開始を通知 3体を並列実行 ：Melchior / Balthasar / Casper が同時に投票（fan-out） 1回目集計 ：賛成が2票以上なら「可決」 分岐 ：全会一致ならそのまま確定。割れたら 討論 → 再投票 → 再集計 finalize ：評決を確定して配信 ここでは「アイス食べたい」をテーマにしています。2:1で可決されました。 各人格には異なる「観点」を与えています。 Melchior ：論理性・合理性・整合性を最重視 Balthasar ：人間要因・感情・受容性を重視 Casper ：現実性・リスク・実務性を重視 ここでは「アイス食べたい」をテーマにしています。クリックで理由が表示されます。 実装のキモ｜小さいモデルに「JSONだけ」返させる 各人格への問い合わせは1つの関数に集約しています。小さいモデルを安定させるコツは、 出力をJSONに固定する こと。 format="json" と temperature=0 を指定し、 role / reason / vote の3項目だけを返させます。 必ずJSONのみで返してください: { "role": "{role}", "reason": "80字以内で簡潔に（必ず日本語で）", "vote": "approve or reject" } 返ってきた文字列は、 ```json のコードフェンスを剥がし、最初の {` から最後の `} までを抜き出してからパースします。理由が80字を超えたら、途中で切れないよう「最後の句読点」で丸める。小さいモデルは文字数指示を守りきれないので、この後処理は必須でした。 Raspberry Pi で待たせない3つの速度チューニング 非力なPiで素直にLLMを動かすと、1票に何十秒もかかります。体感速度を詰めるために効かせた工夫が主に3つ。 1. コンテキスト長を絞る 対応： num_ctx を既定の 4096 から 1024 へ。 根拠： 投票プロンプトは数百字なので、大きな窓は無駄にメモリと時間を食うだけ。 2. 生成トークン数を制限する 対応： num_predict = 128 。 根拠： 理由は80字上限なのでこれで十分。 出力が短いほど速い。 3. モデルをRAMに常駐させる 対応： keep_alive = -1 ＋ 起動時に一度空打ちして先読み。 根拠： 初回質問のコールドロード待ちを消せる。 OLLAMA_NUM_CTX=1024 # 4096 → 1024 OLLAMA_NUM_PREDICT=128 # 理由は80字で足りる OLLAMA_KEEP_ALIVE=-1 # モデルをRAMに常駐 このほか、3体を 並列実行 （直列の約1/3の時間）し、最終要約は LLMを使わず定型文 で組み立てて呼び出しを1パス削減しています。 モデル選定｜0.5Bの罠を、プロンプトで直す 速度優先でまず qwen2.5:0.5b を使ったところ、奇妙な出力に遭遇しました。 理由には「適切だ」と書いてあるのに、投票は reject となっている、つまり reason と vote が食い違うのです。 原因は集計バグではなく、モデルの出力そのものの矛盾でした。しかも当初のプロンプトは vote を reason より先に書かせていたため、モデルは先に投票を決め打ちしてから、後付けで理由を書いていたのです。 そこで、JSONの並びを reason → vote に変更し、「理由を先に書き、それに一致する投票を選べ／矛盾してはならない」と明示。0.5Bのままでも矛盾が大きく減りました。 最終的に qwen2.5:1.5b に上げると、投票と理由の整合性が安定します。おまけに、 num_ctx=1024 のままでも約1300字の長文議題を破綻なく処理できました。 課題｜本当に時間を溶かしたのはネットワークとOllama 正直、アーキテクチャよりも実機3台の立ち上げのほうが遥かに大変でした。同じ轍を踏む人のために残しておきます。 Wi-Fiが突然切れる GUIから静的IPを設定したらWi-Fiが切断。プロファイルからパスワード（PSK）が抜け落ちていました。 解決： プロファイルを削除して nmcli device wifi connect で作り直す。静的化も nmcli でパスワードごと一括指定するのが確実です。 （今回の構成としてはインターネット不要なのでここはスキップできちゃいます。） Ollamaのサービスが壊れる unit is masked → ディレクトリ欠落 → ssh: no key found と、1台だけドミノでおかしくなりました。 解決： 中途半端に直すより、 完全に削除してから install.sh で入れ直す のが最短でした。 母艦からPiに届かない Ollamaの既定は 127.0.0.1 待ち受けで、他マシンから見えません。 解決： OLLAMA_HOST=0.0.0.0:11434 を設定して再起動。 ss -tlnp | grep 11434 で待ち受けが 0.0.0.0 になっているか必ず確認しましょう。 検証｜「意見が割れる議題」で試す 多数決システムの見どころは、票が割れて「討論→再投票」が発動する瞬間です。だから 論理・感情・現実の3視点が対立する議題 を選びます（例：「AIに人事評価を任せるべきか」「延命治療を中止すべきか」）。 面白かったのは頑健性で、 音声入力の変換ミスで議題が多少崩れていても 、3体とも妥当な結論に収束しました。むしろ本番では、コンテキスト長よりも 音声認識の精度のほうが実害リスクが大きい という気づきが得られました。 母艦を起動して [warmup] done が出て、3体の投票がそろい評決が返ってくれば成功です！ ここでは「残業を法律で全面禁止すべき」をテーマにしています。 まとめ 「 Raspberry Pi でLLMなんて動くの？」という半信半疑から始めましたが、役割を割り切って設計し、チューニングを重ねることで、合議AIはしっかり動きました。 MAGI = 3つの人格が多数決で決める合議システム。 「1人格 = 1台の Raspberry Pi 」 を物理的に再現。 構成は 3台のPi（Ollama）+ 母艦（Flask + LangGraph） 。役割は .env のURLだけで振り分けるシンプル設計。 非力なPiでも、 コンテキスト長・生成量・モデル常駐 の3点を絞れば実用的な速度で動く。 小さいモデルの「投票と理由の矛盾」は、 プロンプトの並び替え という小さな工夫で大きく改善できた。 一番の敵はAIではなく ネットワークとサービス管理 。ここを乗り越えれば合議AIは立ち上がる。 今回はイベント会場に向けて軽量・高速に特化させましたが、精度を重視し他のモデルを試していきたいと考えています。 今後も、こうした個人開発を通して得られた知見を、皆さんに共有していきたいと思います！ 宣伝 生成AIを活用する開発として、自分専用のRAGを作ることもやりました。興味がある方はぜひのぞいてみてください。 RAGの作り方｜LlamaIndexで簡単2ステップ RAGの育て方｜LlamaIndexでペルソナ設計 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 32人がこの投稿は役に立ったと言っています。 The post ラズパイ3台でエヴァのMAGIを作る｜ローカルLLMで動く合議AIシステム first appeared on SIOS Tech Lab .

今年も半分が過ぎました。2026年4-6月のサマリーです。 記事数・執筆者数 # この3ヶ月で13本の記事が投稿され、記事数は889になりました。 連載 # AIエージェントとシステムをつなぐMCP入門 # MCP(Model Context Protocol) は AI エージェントが外部サービスと通信するための仕様で、2024年に Anthropic 社によって初版がリリースされました。MCP を使用することで、AI エージェントは外部サービスの機能を効果的に利用できます。MCP の基本から実装まで段階を分けて解説するシリーズです。 /blogs/2026/04/24/mcp-impl_introduction/ 現在は以下の6記事が公開されています。 イントロダクション stdio実装編 StreamableHTTPステートレス実装編 StreamableHTTPステートフル実装編 プロンプト編 リソース編 テーマ別記事 # 認定資格 # /blogs/2026/04/13/google_cloud_all_certified_revenge/ /blogs/2026/04/20/aws_certified_generative_ai_developer/ ペアレンタルコントロール # 上記の AWS・Google Cloud 認定を“W全冠”したエンジニアが、クラウドから降りて自宅のネットワークと格闘した異色の記事です。夜中に学校用タブレットでゲームをする子供との「イタチごっこ」に終止符を打つべく、手持ちの家庭用ルータとRaspberry Piを活用して、MACアドレス制限やサブネット分離、Pi-holeによる独自DNS構築まで、本気の「ガチ構成」を徹夜で組み上げる様子を赤裸々に綴っています。DoH（暗号化DNS）対策などのリアルな課題にも触れられており、ネットワークの基礎を学び直したい方や、同じ悩みを持つITエンジニアの親御さん必見の泥臭くも愛に溢れた実践録です。 /blogs/2026/04/09/home_network_control/ スクラムマスターと AI # チームの対話を支えるスクラムマスターにとって、視覚的な資料作成は欠かせませんが、一方で多大な時間がかかるのが共通の悩み。本記事では、そのボトルネックを AI で突破する実践的な手法を解説しています。ChatGPT を思考のパートナーとして構成を練り上げ、最新の生成 AI ツールでスライドを一気に形にする――単なる「時短術」に留まらず、AI との対話を通じてアイデアを磨き、本来注力すべきファシリテーションやコーチングの質を高めるための「共創のプロセス」を紹介しています。資料作成の重圧から解放され、チームの価値最大化に向き合いたいリーダー・マネージャーにとっても役立つ内容となっています。 /blogs/2026/04/27/ai-presentation/ GitHub # GitHub の Organization 運用において、「機密リポジトリを作りたいが、Basic Permission の設定変更による管理コスト爆発は避けたい」というジレンマ。この記事では、高価なEnterprise プランを契約せずとも、Teams プランの制限下で安全かつ効率的にアクセス権を管理する「ホワイトリスト方式」の戦略を解説しています。全メンバー用の統合チーム作成によるセキュリティ境界の構築から、GitHub API と Actions を組み合わせた「チーム追加漏れを防ぐ自動化スクリプト」の実装まで、管理者の負担を増やさない現場目線のハックを紹介しています。 /blogs/2026/06/24/github-manage-organization-access/ CI/CD 環境で広く使われる GitHub Actions に新たに追加された、単一ワークフロー内でのステップ並行実行機能をいち早く検証した記事です。background 属性を使った非同期実行や、parallel ブロックを使った同時実行の基本構文を解説するだけでなく、Go 言語のクロスコンパイルを用いた実践的なパフォーマンス検証も実施。vCPU コア数やコンテキストスイッチの観点から「期待したほど速くならなかった理由」と、「これまでの Matrix ビルドとどう使い分けるべきか」まで深く考察しており、現場の CI 改善に直結する生きた知見が得られます。はてなブックマークでも注目され、公開直後からアクセスが上昇しました。 /blogs/2026/06/27/github-actions-parallel-steps/ さいごに # 以上、2026年度第1四半期のサマリーでした。投稿数が少なかったため、個別の記事紹介を厚めにしてみました。 よかったら フィード の購読、 X や Bluesky でのフォローもお願いします。 Facebook でも本サイトの注目記事をはじめ豆蔵に関するイベントを紹介しています。 note にも時々本サイト関連の記事が掲載されています。