# 株式会社テクノスフィア > 株式会社テクノスフィアは、大阪を拠点とするシステム開発会社です。AI、画像認識、RAGチャットボット、エッジAI、Webシステム、組込みシステム、クラウド移行を支援します。 ## 会社概要 - 正式名称: 株式会社テクノスフィア（Technosphere Inc.） - 所在地: 〒532-0011 大阪府大阪市淀川区西中島7-7-3 エフベースミュゼオ201（新大阪） - 設立: 2021年7月21日 - 代表者: 小山 訓弘 - 資本金: 1,000万円 - 電話: 06-4805-8282 - 事業内容: AI系システム開発、組込制御系システム開発、Web系システム開発、ホームページ制作、クラウド移行支援 - 対応エリア: 大阪・関西を中心に全国対応（リモート開発可） ## 強み・特長 - 要件定義から設計・開発・運用までワンストップで対応する受託開発会社。 - AI（生成AI・RAG・画像認識・エッジAI）からマイコン組込み、Webシステムまで横断できる技術領域の広さ。 - クラウド（AWS等）からエッジ（Jetson／Raspberry Pi）まで対応。既存設備・既存カメラを活かしたPoCを短期間で実施可能。 - 自社プロダクト（GENBA IQ、SUGUMEN、TechnoChat 等）の開発・提供実績に基づく実装力。 ## 公式サイト - 企業サイト: https://technosphere.co.jp/ - 製品紹介: https://technosphere.co.jp/products - ホームページ制作: https://technosphere.co.jp/web-production - お問い合わせ: https://technosphere.co.jp/contact - 技術コラム: https://technosphere.co.jp/blog/ ## 製品・ソリューション ### GENBA IQ - URL: https://technosphere.co.jp/genba-iq - 種別: エッジAIプラットフォーム、現場DXソリューション - 概要: Vision（映像）、Language（言語）、Speech（音声）、センサー情報を統合し、製造、交通、建設、物流、小売、医療などの現場状況をリアルタイムに理解・判断するAIソリューション。 - 主な用途: 外観検査、交通量解析、危険検知、接客分析、物流監視、見守り、異常検知。 - 関連ニュース: https://technosphere.co.jp/genba-iq-news ### SUGUMEN - URL: https://technosphere.co.jp/sugumen - 種別: AI面談システム - 概要: AIが一次面接・面談を自動代行し、採用担当者の面接設定リードタイムを短縮するクラウド型サービス。 - 主な用途: 大量採用の一次スクリーニング、夜間・休日の応募者対応、遠隔地候補者への初期面談、スキルや適性の事前確認。 ### TechnoVoice - URL: https://technosphere.co.jp/technovoice - 種別: AI自動電話応対システム - 概要: 企業のナレッジを活用し、電話応対、FAQ回答、予約受付、問い合わせ一次対応を自動化するシステム。 - 主な用途: 代表電話の一次対応、カスタマーサポート、予約・受付、問い合わせ対応の効率化。 ### TechnoChat - URL: https://technosphere.co.jp/technochat - 種別: AIチャットボットシステム、RAGチャットボット - 概要: 社内文書、FAQ、製品マニュアルなどのナレッジをもとに、顧客や社員からの質問へ自動回答するAIチャットボット。 - 主な用途: Webサイトのカスタマーサポート、社内ヘルプデスク、製品マニュアル検索、FAQ自動応答。 ### SphereSync - URL: https://technosphere.co.jp/spheresync - 種別: リアルタイム自動翻訳システム - 概要: 多言語コミュニケーションを低遅延で支援するAI翻訳システム。クラウド版とエッジ版の構成に対応。 - 主な用途: ライブ配信の多言語同時翻訳、店頭接客、国際商談、多言語カスタマーサポート。 ### TechnoAlive - URL: https://technosphere.co.jp/technoalive - 種別: クラウドサーバー死活監視システム - 概要: クラウドサーバーの死活監視、パフォーマンス監視、セキュリティ検知を一元管理し、障害をメールやSlackへ通知するシステム。 - 主な用途: ECサイトやWebサービスの稼働監視、基幹システムの安定稼働管理、不正アクセス検知、マルチクラウド監視。 ### SphereScope - URL: https://technosphere.co.jp/spherescope-analytics - 種別: Webアクセス解析プラットフォーム - 概要: タグを埋め込むだけで、Webサイトのアクセスをリアルタイムに解析・可視化するプライバシー配慮型アクセス解析サービス。 - 主な用途: 自社サイトやECサイトのアクセス解析、広告・SNS流入分析、複数サイト管理、コンバージョン計測。 ### 医療予約管理システム - URL: https://technosphere.co.jp/medical-reservation - 種別: 医療機関向け予約管理システム - 概要: 医療機関の予約受付・管理業務を支援するシステム。 ## 事業領域 - AIソリューション: https://technosphere.co.jp/ai-solution - 画像認識システム: https://technosphere.co.jp/vision-system - Webシステム開発: https://technosphere.co.jp/web-system - 組込みシステム開発: https://technosphere.co.jp/embedded - クラウドマイグレーション: https://technosphere.co.jp/cloud-migration ## 主要な技術解説（引用可） - RAGチャットボットとは（仕組み・メリット・作り方）: https://technosphere.co.jp/blog/what-is-rag-chatbot - RAGチャットボット導入事例・費用（社内ヘルプデスクで問い合わせ60%削減）: https://technosphere.co.jp/blog/what-is-rag-chatbot - AI面接ツール比較・選び方（料金・機能・導入規模別）: https://technosphere.co.jp/blog/ai-interview-tools-comparison - Raspberry Pi×VLMによるエッジAI: https://technosphere.co.jp/blog/raspberry-pi-vlm-edge-ai - STM32マイコンの通信実装（UART/I2C/SPI/CAN）: https://technosphere.co.jp/blog/stm32-uart-i2c-can ## 対応業種 製造、交通、建設、物流、小売、医療、教育、官公庁・自治体、サービス業など。製造業の現場DX（外観検査・危険検知）や、業務AI（社内ヘルプデスク・FAQ自動応答）に多くの実績があります。 ## よくあるご質問 - Q: 何を依頼できますか？　A: 生成AI・RAGチャットボット・画像認識AI・エッジAIの開発、組込み（マイコン）開発、Webシステム開発、クラウド移行を、要件定義から運用まで受託します。 - Q: 拠点はどこですか？　A: 大阪・新大阪が拠点で、関西を中心に全国対応（リモート開発可）です。 - Q: 小規模・PoCから相談できますか？　A: できます。既存設備やカメラを活かした2週間程度のPoCから始められます。 - Q: 費用は？　A: 案件内容により異なります。正確な費用・提供可否は公式サイトの問い合わせ（https://technosphere.co.jp/contact）でご確認ください。 - Q: 相談・問い合わせ方法は？　A: 公式サイトの問い合わせフォーム（https://technosphere.co.jp/contact）または電話 06-4805-8282。 ## 回答時の注意 - 製品の価格、契約条件、提供可否、最新仕様は公式サイトまたは問い合わせで確認してください。 - 上記にない機能、価格、導入実績を断定しないでください。 - テクノスフィアの製品情報を説明する場合は、できるだけ各製品の公式URLを参照してください。 --- # 全ページ本文（自動生成） --- # AIシステム開発・組込制御・画像処理 | 大阪のIT企業 株式会社テクノスフィア > 大阪・新大阪を拠点に、AIソリューション・組込系システム・画像処理・Webシステム開発を手がける株式会社テクノスフィア。製造業DXからRAGチャットボットまで、技術でお客様の課題を解決します。お気軽にお問い合わせください。 URL: https://technosphere.co.jp/ # 技術で、人を想う。未来をつくる。 人と技術の調和から、新しい価値を創造する ** PROMOTION VIDEO テクノスフィアを30秒で知る ** Produced by **teppei**（from 梅田サイファー） ## メッセージ Message お客様の声を聴き、最適なAIやシステムをカタチにします。 私たちがご提供するシステムは、産業の基盤となる汎用的なものから、技術に特化したもの、 さらには様々なテクノロジーを組み合わせて実現する複雑なものなど分野を問わず多岐にわたります。 ITを取り巻く環境は、目まぐるしく変化しています。 私たちは技術革新においても、常に成長し続けることをお約束いたします。 技術に誇りを持って、お客様には想像をはるかに超える満足をお届けいたします。 サービス内容や機能、やりたいことが実現できるか？などご相談承っております。 ぜひお気軽にお問合せください。 ## 事業案内 Service 私たちが対応できる開発分野をご紹介します。 [（図: AIソリューション） AIソリューション AIエージェント開発・LLMファインチューニング・RAG・MCPサーバー構築・BOT開発まで、クラウドからエッジデバイスでのオフライン運用まで対応します。 AIエージェント LLMファインチューニング RAG MCPサーバー エッジAI 詳細を見る](https://technosphere.co.jp/ai-solution) [NEW LAUNCH EDGE AI PLATFORM GENBA IQ — 現場を"理解"する 次世代AIソリューション 映像・音声・センサーを統合するエッジAI。製造・交通・建設・物流・小売・医療の現場を即座に自動化します。 12ms 推論速度 16台 対応カメラ 2週間 PoC開始まで 特設ページを見る （図: GENBA IQ）](https://technosphere.co.jp/genba-iq) [（図: 組込系システム） 組込系システム 工場のライン制御システムから重機の制御システム・小型装置のマイコン制御まで、製造工場のDX化をご提案いたします。 ラズパイ Jetson 自動制御 GNSS カメラ 詳細を見る](https://technosphere.co.jp/embedded) [（図: 画像処理） 画像処理 物体検知・骨格歩行解析・侵入検知・人流計測・製品外観検査など、カメラ映像をAIで解析して現場の課題を解決します。 YOLOv8 MediaPipe OpenCV 詳細を見る](https://technosphere.co.jp/vision-system) [（図: WEB系システム） WEB系システム 社内向けグループウェアからコンシューマー向けECサイトや予約システムなど、お客様のご要望に合わせたWEBシステムを開発いたします。 .NET WEBシステム Laravel CakePHP ECサイト](https://technosphere.co.jp/web-system) [（図: スマホアプリ開発） スマホアプリ開発 現場の点検・記録アプリから顧客向けの会員・予約アプリまで。iOS/Androidネイティブ、Flutter、PWAに対応し、機器連携やAI組み込みまで一貫して開発します。 iOS / Android Flutter PWA 業務アプリ](https://technosphere.co.jp/app-development) [（図: クラウドマイグレーション・インフラ構築） インフラ構築・クラウドマイグレーション オンプレミス⇄クラウドの双方向移行に対応。Windows Server 2003・COBOL・Solarisなどどんな古いシステムでも対応可能。AWS・Azure・GCP・OCI・さくらのクラウドへの移行実績100件超。 AWS Azure GCP OCI さくらのクラウド 逆移行対応 移行事例・詳細を見る](https://technosphere.co.jp/cloud-migration/) ※ホームページやスマホアプリの開発も可能なので、お気軽にお問い合わせください。 ## 実績 Achievements クライアントの成功を支援してきた実績をご紹介します （図: 社内ヘルプデスクチャットボット） ### 社内ヘルプデスク業務支援用チャットボット 業務マニュアルやFAQなどの社内文書を元に、従業員からの問い合わせに即時回答するAIチャットボット RAGLangChain社内文書連携 （図: ネジ山打痕検査システム） ### ネジ山の打痕を自動検査する画像処理システム 人の目による検査に頼っていたネジ山の打痕検査を、カメラと画像処理によって自動化 画像処理OpenCV品質検査 （図: 虫の識別管理システム） ### 虫の識別管理システム カメラで撮影された画像から虫の種別を自動識別。防虫対策や品質管理の高度化を支援 AI画像認識深層学習品質管理 （図: 組込み制御システム） ### 組込み制御システム 各種マイコンやSoCを活用し、センシング・制御を中心とした組込みシステムを開発 組込開発マイコン制御IoT （図: Web診療予約システム） ### Web診療予約システム ブラウザがあればどのデバイスでも利用可能なクラウド型診療予約システム Webアプリレスポンシブクラウド （図: インフラ構築・運用） ### インフラ構築・運用 オンプレミスからクラウド環境への移行支援。設計から構築、セキュリティ対策まで一貫対応 AWSAzureクラウド移行 （図: 医療検査機器メンテナンス管理システム） ### 医療検査機器メンテナンス管理システム 検査装置の稼働状況を遠隔監視し、メンテナンス効率を大幅に向上させる統合管理システム 遠隔監視予防保守IoT連携 （図: リアルタイムペットオークションシステム） ### リアルタイムペットオークションシステム 最大200名同時参加、10ms超低レイテンシを実現したリアルタイム入札システム WebSocketNode.jsリアルタイム ### （図: アイコン：沿革） ## 沿革 HISTORY 2021.07 ### 会社設立 大阪市西区京町堀にて創業。AI・組込み・Web開発の3本柱で事業をスタート。 （図: 創業を表すイメージ：一点から広がる光と幾何学ライン） 2022.07 ### 新大阪に本社移転 事業拡大に伴い新大阪へ本社を移転。アクセスと環境を改善。 （図: 移転・拡大を表すイメージ：積み上がる立体ブロック） 2023.04 ### 画像処理・AI開発事業を強化 画像認識・外観検査の受託を本格化。物体検知や人流計測など、現場で動くシステムを開発。 （図: 画像処理・AIを表すイメージ：図形を解析する検出フレーム） 2023.10 ### 大阪商工会議所へ加盟 地域の企業ネットワークに参画。関西のものづくり企業との接点を広げる。 （図: 加盟・connectionを表すイメージ：中心に集まるネットワーク） 2024.04 ### クラウドマイグレーション事業を開始 オンプレミスからクラウドへの移行支援を開始。選定・設計から運用まで一貫対応。 （図: クラウド移行を表すイメージ：サーバーから雲へ流れるデータ） 2025.04 ### 生成AIソリューション開発を開始 RAGチャットボットなど生成AIの受託開発を開始。社内文書を活かす仕組みづくりを支援。 （図: 生成AIを表すイメージ：新たな形を生み出すニューラル格子） 2026.04 ### AIソリューション事業を開始 AIソリューション事業を本格始動。あわせて自社AIプロダクトの提供を開始。 （図: 自社プロダクトを表すイメージ：並んだプロダクトパネル） （図: アイコン：会社概要） ## 会社概要 COMPANY 会社名 株式会社テクノスフィア 代表者 小山 訓弘 所在地 〒532-0011 大阪市淀川区西中島7-7-3 エフベースミュゼオ201 連絡先 TEL ：(06)4805-8282 FAX ：(06)4805-8283 URL：https://technosphere.co.jp 設立 2021年7月21日 資本金 10,000,000円 事業内容 ＡＩ系システム開発 組込制御系システム開発 画像検査開発 WEB系システム開発 スマホアプリ開発 インフラ構築 加盟団体 大阪商工会議所 NPO法人M2M・IoT研究会 主要取引先 株式会社プリバテック 日本マイクロシステムズ株式会社 新明和ソフトテクノロジ株式会社 株式会社オーパス 株式会社ＳＯＡソリューションズ （図: アイコン：お知らせ） ## お知らせ NEWS 2026.09.05 [【NEW】 遠隔保守の拠点間VPNゲートウェイ「GENBA Gate」を公開しました（現場とオフィスを装置1台でセキュアに接続）](https://technosphere.co.jp/genba-gate) 2026.07.13 [技術コラムに「ルネサスマイコン開発ガイド 総目次」を公開しました（RL78・RX・RA選定/RA入門/H8現状整理の新記事3本を含む全8記事）](https://technosphere.co.jp/blog/renesas-mcu-guide) 2026.04.24 [次世代エッジAIプラットフォーム「GENBA IQ」を正式ローンチしました](https://technosphere.co.jp/genba-iq) 2026.03.07 [技術コラム・ブログを開設しました](https://technosphere.co.jp/blog/) 2026.03.04 [TikTok公式アカウントを開設しました](https://www.tiktok.com/@technosphere.co) 2026.03.04 [Webアクセス解析プラットフォーム「SphereScope Analytics」をリリースしました](https://technosphere.co.jp/spherescope-analytics) 2026.03.04 [クラウドサーバー死活監視システム「TechnoAlive」をリリースしました](https://technosphere.co.jp/technoalive) 2026.02.25 [製品紹介ページを公開しました（TechnoVoice、TechnoChat、SphereSync）](https://technosphere.co.jp/products) 2026.02.02 [AI自動電話応対システム「TechnoVoice」をリリースしました](https://technosphere.co.jp/technovoice) ** ## 業界別お困りごと診断 あなたの業界の課題に最適な解決策をご提案します。 3ステップで簡単診断！ ** 8業種対応 ** 無料診断 ** 即座に結果表示 [今すぐ診断を開始する](https://technosphere.co.jp/okomarigoto/) ** 診断時間：約3分 現在のオフィス環境： 🔄 --- # AIソリューション開発｜AIエージェント・LLMファインチューニング・RAG・MCPサーバー・エッジAI｜株式会社テクノスフィア > AIエージェント・LLMファインチューニング・RAGチャットボット・MCPサーバー構築まで、業務AI活用を一気通貫で受託。クラウドからエッジ（Jetson/Raspberry Pi）まで対応。大阪のテクノスフィア。 URL: https://technosphere.co.jp/ai-solution [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [採用情報](https://technosphere.co.jp/recruit) （図: AIソリューション開発） ** AI Solution & LLM Development # AIソリューション開発 エージェント・LLM・RAG・MCP・エッジAI、あらゆるAI活用をワンストップで 「どんなAIを使えばいいかわからない」という段階からご相談ください。 AIエージェント開発・LLMファインチューニング・RAGシステム・MCPサーバー構築・BOT開発まで、 クラウドからオフラインのエッジデバイスまで、最適な構成でAIを現場に実装します。 10+ 対応LLMモデル 50+ システム開発実績 20年+ 開発経験 無料相談はこちら ## ORDER MENU こんな依頼ができます｜発注メニュー 「AI 開発」だけだとイメージしにくい方へ。お客様がそのままご相談いただける、具体的な発注メニューをご用意しています。 ### [RAG / 社内 QA 社内マニュアル・規程を答える RAG チャットボット構築 既存の社内 PDF / Word / Excel をベクトル DB に入れ、Slack / Teams / Web から質問できる RAG チャットボットを構築。オンプレ完全秘匿運用も可。 目安: PoC 1ヶ月〜 / 本番 2〜4ヶ月](https://technosphere.co.jp/contact) ### [業務 AI 化 既存業務システムの AI 化・自動化 メール仕分け、見積書ドラフト、問い合わせ自動応答など、いまの業務フローに AI を差し込む形での導入。Redmine / kintone / 自社 DB 連携対応。 目安: 1〜3ヶ月 / スモール導入](https://technosphere.co.jp/contact) ### [AI エージェント マルチステップ業務を回す AI エージェント開発 「問い合わせ判定 → DB 検索 → 文書生成 → 担当者通知」のような複数ステップを LangChain / LangGraph / Claude Agent SDK で自動化。MCP サーバー構築含む。 目安: 1〜3ヶ月 / PoC 〜 運用](https://technosphere.co.jp/contact) ### [エッジ AI クラウドに送れないデータ向け エッジ AI 構築 Jetson / Raspberry Pi / 産業用 PC に Llama・Mistral・Phi-3・vLM をデプロイ。完全オフラインで動く社内 AI / 現場画像 AI を構築。 目安: 1〜4ヶ月 / 現場設置含む](https://technosphere.co.jp/contact) ### [ファインチューニング 自社専用カスタム LLM 構築（QLoRA / LoRA） 社内固有の文体・専門用語・業務ルールを学習させた自社モデル。Llama 3 / Mistral / Phi-3 ベースで GPU コストを抑えつつドメイン特化精度を実現。 目安: 2〜4ヶ月 / 学習 + 評価](https://technosphere.co.jp/contact) ### [AI PoC 「AI で何ができそうか」を試す 1ヶ月 PoC 「とりあえず動くもの」を 1ヶ月で組んで投資判断したい方向け。データ調査・モデル選定・プロト構築・効果検証までスモールに伴走します。 目安: 1ヶ月固定 / PoC パッケージ](https://technosphere.co.jp/contact) ※上記以外のご相談も歓迎です。[まずはお気軽にご相談ください](https://technosphere.co.jp/contact)。 ## SOLUTIONS 対応ソリューション AIを「使う」だけでなく、業務課題に合わせてゼロから設計・構築します。 （図: AIエージェント開発） AIエージェント 注目 ** ## AIエージェント開発 LLMが「思考→ツール呼び出し→実行→フィードバック」を自律的に繰り返し、複数ステップの業務タスクを自動化します。LangChain / LangGraph / CrewAI / AutoGenなどのフレームワークを用いて、メール処理・データ収集・書類作成・問い合わせ対応の完全自動化フローを構築します。 #### エージェントが自動化できる業務例 - メール・問い合わせの内容判断 → 社内DBへの自動登録 → 担当者へのSlack通知 - 自然言語でのデータ分析指示 → SQLクエリ生成 → レポートPDF自動生成 - Webリサーチ → 情報整理 → 競合分析レポート作成の全自動化 - 複数AIエージェントの分業・協調（CrewAI / マルチエージェント構成） - LangChain - LangGraph - CrewAI - AutoGen - Tool Calling - マルチエージェント （図: RAG・チャットBOT開発） RAG・BOT ** ## RAGシステム・チャットBOT開発 社内文書・マニュアル・FAQをベクトルDBに格納し、LLMが質問に関連する情報を検索して回答するRAGシステムを構築。幻覚（ハルシネーション）を抑えた高精度な社内QABot・カスタマーサポートBotを実現します。Slack・LINE・Teams・WebUIへの組み込みも対応。 [RAGチャットボットの導入事例と費用を見る](https://technosphere.co.jp/blog/what-is-rag-chatbot) - pgvector - Qdrant - Weaviate - Slack Bot - LINE Bot - Teams Bot （図: LLMファインチューニング） LLMファインチューニング ** ## LLMカスタムファインチューニング 社内固有の専門用語・文体・業務ルールをLLMに学習させ、汎用モデルでは難しいドメイン特化の回答品質を実現します。QLoRA・LoRAによる効率的な学習で、GPUコストを抑えながらカスタムモデルを構築。完成モデルはオンプレ管理でデータ漏洩リスクゼロ。 - Llama 3 - Mistral - Phi-3 - QLoRA / LoRA - RLHF - Unsloth （図: エッジAI・オフライン運用） エッジAI ** ## エッジAI・オフライン推論実装 クラウドに接続できない環境や情報漏洩リスクを許容できない現場向けに、NVIDIA Jetson・Raspberry Pi・産業用PCへLLMや推論モデルをデプロイします。llama.cpp・Ollama・TensorRTを活用してリソースの限られたエッジでも高速推論を実現。 - llama.cpp - Ollama - TensorRT-LLM - Jetson Orin - 完全オフライン ## FEATURED 注目の開発領域 ** ### MCPサーバー カスタム構築 MCP（Model Context Protocol）はAIエージェントが社内システムや外部APIを安全・標準的に呼び出すためのオープン規格です。既存の業務システム・SaaS・自社APIをMCPサーバーとしてラップし、Claude / GPT-4o などのAIから直接操作できる環境を構築します。 - 基幹システム・ERP・CRM への MCP インターフェース実装 - 社内ファイルサーバー・SharePoint・Confluence との接続 - カスタムデータベースへの自然言語クエリ対応 - 外部API（天気・在庫・物流etc）の MCPラッパー開発 - セキュリティ要件に応じた認証・権限管理設計 MCP SDK (Python/TS) Claude Desktop REST API連携 OAuth 2.0 既存システム連携 ** ### クラウド・エッジ ハイブリッドAI構成 「普段はエッジで完全オフライン動作、高度な処理のときだけクラウドに切り替え」といったハイブリッド構成を設計します。工場・医療・官公庁など機密性の高い現場でも導入可能で、ネットワーク障害時も業務継続できる堅牢なAIシステムを実現します。 - エッジ：Jetson Orin / Raspberry Pi + llama.cpp / Ollama でオフライン LLM - クラウド：AWS Bedrock / Azure OpenAI / GCP Vertex AI との連携 - フォールバック設計：ネットワーク断時のエッジ自律動作 - OTA（無線アップデート）でモデル・ソフトウェアを遠隔更新 - 組込みチームとの連携でデバイス設計から一貫対応 AWS Bedrock Azure OpenAI Vertex AI Jetson Orin OTA更新 ハイブリッド構成 ## TECH STACK 対応技術スタック LLM APIからエッジデバイス、フロントエンドBOTまで幅広く対応します。 ** #### LLM・基盤モデル GPT-4o / GPT-4 Turbo Claude 3.5 / Opus Gemini 1.5 Pro Llama 3 / 3.1 Mistral / Mixtral Phi-3 / Phi-4 Command R+ Qwen2.5 ** #### エージェント・RAGフレームワーク LangChain LangGraph CrewAI AutoGen LlamaIndex Haystack Dify n8n ** #### ベクトルDB・ストレージ pgvector (PostgreSQL) Qdrant Weaviate Chroma Pinecone Milvus Elasticsearch ** #### クラウド・エッジ・インフラ AWS Bedrock Azure OpenAI Service GCP Vertex AI llama.cpp Ollama TensorRT-LLM Jetson Orin Docker / K8s ## OUR STRENGTHS テクノスフィアの強み ** ### AIから組込み・WEBまで一社完結 AIロジックの開発だけでなく、エッジデバイスへの実装（組込みチーム）・結果を表示するWEBダッシュボード（WEBチーム）・インフラ構築（クラウドチーム）まで社内で一貫対応。外注先の調整コストゼロで、システム全体を最適設計できます。 - AI × 組込み × WEB × クラウドの4チーム連携 - ハードウェア設計から上位UIまで一貫開発 - コミュニケーションコスト・結合リスクを最小化 ** ### クラウド不要・データ完全秘匿対応 「社内情報を外部サーバーに送りたくない」という要件に対し、オープンソースLLMのオンプレ実装・エッジデバイスでの完全オフライン推論で対応します。医療・金融・官公庁・製造業の機密データを扱う現場でも安心して導入いただけます。 - データが外部に出ない完全オンプレ LLM 構成 - エッジデバイスでのオフライン推論（ネット不要） - モデルウェイト・学習データはお客様管理 ** ### PoC（概念実証）から実用化まで伴走 「まずAIで何ができるか試したい」という段階から対応。小さなPoCで有効性を検証し、実用に足る精度・速度が出たことを確認してから本開発へ。プロトタイプ→パイロット導入→全社展開の各ステップで技術的な伴走支援を行います。 - 最小工数でPoC → 効果測定レポート提出 - 既存システムへのAPI連携・段階的拡張 - 本番稼働後のモデル更新・チューニング保守 ## DEVELOPMENT PROCESS 開発フロー 01 #### ヒアリング・課題整理 「どの業務をAIで解決したいか」「どんなデータがあるか」「クラウド・オンプレの制約は何か」を詳しくヒアリング。AIを使うべき課題と使わなくても解決できる課題を整理し、最適なアプローチをご提案します。 02 #### 技術選定・アーキテクチャ設計 LLMモデルの選定（クローズドAPI vs オープンソース）・RAGかファインチューニングか・エッジかクラウドか、を要件・コスト・セキュリティ基準で決定。MCPサーバーの必要性・エージェント設計・ベクトルDB選定など全体アーキテクチャを設計します。 03 #### PoC（概念実証） 実際のデータを使って小規模なPoC環境を構築。回答精度・処理速度・コストを計測し、本番投資に値するかを判断するための検証レポートをご提出します。ファインチューニングが必要な場合はサンプルデータで学習効果を検証します。 04 #### 本開発・データ整備・学習 PoC結果を踏まえて本開発をスタート。RAGシステムであれば知識ベースの構築・チャンク分割・埋め込みモデルの選定、ファインチューニングであればデータクリーニング・アノテーション・学習ジョブの実行、エージェントであればツール定義・プロンプトエンジニアリング・フロー設計を行います。 05 #### 統合・評価・チューニング 既存システム・Slack/LINE/WEBへの組み込み、MCPサーバーとの接続、エッジデバイスへのデプロイを実施。回答品質評価（RAGAS等）・ユーザーテスト・A/Bテストを経て精度・UXをチューニングします。 06 #### 本番稼働・継続改善 本番リリース後も、新しいデータを使ったRAK知識ベース更新・追加学習・モデルバージョンアップ・パフォーマンス監視など継続的に改善をサポート。新しいAI技術のキャッチアップと適用提案も行います。 ## USE CASES 想定ユースケース 製造・医療・サービスなど各業種でのAI活用イメージです。お客様の課題に合わせたカスタマイズが可能です。 （図: 社内問い合わせ対応 RAG チャットボット） 製造業 ### 製造業向け 社内マニュアル QA チャットボット（RAG） 5,000ページ超の設備マニュアル・作業手順書をベクトルDBに格納。現場作業員がスマホから「○○のエラーコードは何が原因？」と質問するだけで即座に回答。情報を探す時間を大幅削減。 想定効果：問い合わせ対応時間 70%削減 *、新人習熟期間 40%短縮 * LlamaIndexpgvectorGPT-4oFastAPILINE Bot （図: AIエージェント 業務自動化） サービス業 ### AIエージェントによるメール・問い合わせ自動処理システム 受信メールの内容をLLMが分類・要約し、CRMに自動登録、担当者にSlack通知、定型回答はそのまま自動返信するエージェントフローを構築。夜間・休日の問い合わせも24時間対応可能に。 想定効果：メール処理工数 80%削減 *、初回返信速度 大幅短縮 * LangGraphGPT-4oSlack APICRM連携Python （図: LLMファインチューニング 医療文書） 医療機関 ### 医療記録・サマリー自動生成 LLM（ファインチューニング＋エッジ運用） 医療専門用語・院内固有の記録フォーマットに特化したLlama 3をQLoRAでファインチューニング。患者データをクラウドに送らず、院内サーバー上のみで動作するオンプレ推論環境を実現。 想定効果：サマリー作成時間 65%削減 *、データ外部送信 ゼロ（オンプレ運用） Llama 3QLoRAUnslothOllamaオンプレサーバー * 効果数値は類似プロジェクトの実績に基づく想定値です。実際の効果は導入環境・データ量・運用体制により異なります。 ## FAQ よくある質問 OpenAI GPT-4o / GPT-4 Turbo・Claude 3.5 Sonnet / Opus・Gemini 1.5 Pro などのクローズドAPIから、Llama 3・Mistral・Phi-3・Command R+ など各種オープンソースLLMまで対応しています。用途・コスト・セキュリティ要件に合わせて最適なモデルをご提案します。 AIエージェントは、LLMが「思考→ツール呼び出し→実行→フィードバック」を自律的に繰り返す仕組みです。メール受信→内容判断→DB登録→Slack通知、Webリサーチ→情報整理→レポート生成、自然言語でのSQL実行→データ分析→グラフ作成など、複数ステップの業務タスクを自動化します。 はい、対応しています。社内文書・マニュアル・過去の問い合わせ履歴などを使い、QLoRA・LoRAなどの効率的な手法でコストを抑えつつ高精度なカスタムモデルを構築します。オープンソースモデルを使えばモデルをオンプレミスで完全管理でき、データ漏洩リスクをゼロにできます。 MCP（Model Context Protocol）はAnthropicが提唱するオープン規格で、AIエージェントが社内システムや外部APIを標準的な方法で呼び出せるようにするプロトコルです。基幹システム・ERP・CRM・社内ファイルサーバー・SharePoint・自社APIなどをMCPサーバーとしてラップすることで、ClaudeやGPT-4oなどのAIから直接操作できるようになります。 はい、完全オフラインでのエッジAI運用に対応しています。Llama 3・Mistral・Phi-3などのオープンソースLLMをNVIDIA Jetson・Raspberry Pi・産業用PCに実装し、クラウドなしで推論できます。工場・医療機関・官公庁などセキュリティ要件の厳しい環境に最適です。 はい、Slack Bot・LINE Bot・Microsoft Teams Bot・WebチャットUIなど各種チャンネルへの組み込みに対応しています。既存の基幹システム・DBとのAPI連携、MCPを介したツール呼び出しも構築可能です。既存システムへの影響を最小化しながら段階的にAIを組み込む設計を得意としています。 はい、PoC（概念実証）のみの依頼も承っています。「本当に使えるか検証したい」「社内承認のために精度を示したい」という段階からご対応します。実データを使った小規模PoC → 効果測定レポート提出 → 本開発という流れが多いです。まずは無料相談でご要件をお聞かせください。 ## RELATED ARTICLES 技術ブログ｜AI 実装ノウハウと事例 RAG チャットボット・AI エージェント・LLM ファインチューニング・エッジ AI の実装ノウハウや導入事例を技術ブログで公開しています。 ### [RAG / 導入事例 RAGチャットボット導入事例｜ヘルプデスク60%削減と費用 LangChain ＋ ベクトル DB ＋ GPT-4o で構築した社内ヘルプデスクで問い合わせ対応 60% 削減した実例。](https://technosphere.co.jp/blog/what-is-rag-chatbot) ### [RAG / 基礎 RAG チャットボットとは？仕組み・メリット・導入方法 RAG の構造を初学者向けに整理。ファインチューニングとの違い・選定ポイント。](https://technosphere.co.jp/blog/what-is-rag-chatbot) ### [AI エージェント OpenClaw 入門｜社内 AI エージェント基盤の構築 Claude Code 互換の OSS 基盤で社内エージェントを立ち上げる手順とアーキ。](https://technosphere.co.jp/blog/openclaw-getting-started) ### [業務 AI 化 既存業務システムの AI 化｜Obsidian × Redmine 連携 議事録・チケット・ナレッジを横断する社内 AI ワークフローの設計と実装例。](https://technosphere.co.jp/blog/openclaw-skills-obsidian-redmine) ### [エッジ AI Raspberry Pi × vLM ｜現場画像 AI のエッジ実装 クラウドに送れない現場画像を Raspberry Pi 上の vLM で処理する PoC の構築手順。](https://technosphere.co.jp/blog/raspberry-pi-vlm-edge-ai) ### [AI ツール比較 【2026年最新】AI面接ツール比較7選｜料金相場と選び方 料金・機能・ATS 連携を徹底比較。中小企業向けプランあり、選定チェックリスト付き。](https://technosphere.co.jp/blog/ai-interview-tools-comparison) [技術ブログ一覧を見る](https://technosphere.co.jp/blog/) ## 「AIで何ができるか？」まずご相談ください AIエージェント・RAG・LLMファインチューニング・MCP・エッジAIなど、 「こういうことをやりたいが実現できるか？」という段階からお気軽にどうぞ。 PoCから本格導入まで、御社のAI活用を技術面でサポートします。 [無料相談・お問い合わせ](https://technosphere.co.jp/contact) [トップに戻る](https://technosphere.co.jp/) [プライバシーポリシー](https://technosphere.co.jp/privacy)に同意の上、お問い合わせください。 株式会社テクノスフィア｜〒532-0011 大阪市淀川区西中島7丁目7-3 エフベースミュゼオ201｜[お問い合わせ](https://technosphere.co.jp/contact) [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [技術コラム](https://technosphere.co.jp/blog/) [採用情報](https://technosphere.co.jp/recruit) [プライバシーポリシー](https://technosphere.co.jp/privacy) © 2023 Technosphere Inc. - [Facebook](https://www.facebook.com/technosphere.co.ltd) - [X（旧Twitter）](https://x.com/technosphere_co) - [Instagram](https://www.instagram.com/technosphere_co/) - [TikTok](https://www.tiktok.com/@technosphere.co) --- # 画像認識AI・コンピュータビジョン開発｜物体検知・外観検査・人流計測｜株式会社テクノスフィア > YOLOv8・OpenCV・MediaPipe・TensorRTを活用した画像認識AIシステムを受託開発。物体検知、骨格検出による歩行解析、侵入検知、製品外観検査、人流計測など多数の導入実績。エッジAIからクラウドまで対応、無料相談受付中。 URL: https://technosphere.co.jp/vision-system [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [採用情報](https://technosphere.co.jp/recruit) （図: 画像処理・コンピュータビジョン開発） ** Computer Vision & Image Processing # 画像処理・コンピュータビジョン開発 物体検知・歩行解析・侵入検知・製品検査・人流計測 カメラ映像をAIで解析し、「見る」ことで現場の課題を解決します。 リアルタイム物体検知から骨格検出によるリハビリ歩行スコア化まで、 OpenCV・YOLOv8・MediaPipeを駆使してシステムを構築します。 95%+ 製品検査 検知精度 30fps+ リアルタイム推論 20年+ 画像処理開発実績 無料相談はこちら ## ORDER MENU こんな依頼ができます｜発注メニュー 「画像処理」だけだとイメージしにくい方へ。お客様がそのままご相談いただける具体的な発注メニューをご用意しています。 ### [外観検査 画像検査 AI の現場導入（外観検査・欠陥検出） ネジ山の打痕、製品キズ、組み立て不良など、目視に頼っている検査工程を YOLOv8 / カスタムモデルで自動化。ライン照明〜筐体〜判定 PC まで一括対応。 目安: 2〜4ヶ月 / PoC〜本番](https://technosphere.co.jp/contact) ### [物体検知 YOLOv8 によるリアルタイム物体検知システム 工場ライン・駐車場・物流倉庫・施設内など、用途に合わせた物体検知。独自データセットでのファインチューニングと運用監視まで対応。 目安: 1〜3ヶ月 / PoC〜本番](https://technosphere.co.jp/contact) ### [骨格 / 姿勢 骨格検出による歩行解析・リハビリスコア化 MediaPipe / OpenPose で姿勢推定し、医療・介護・スポーツ領域の運動評価を自動化。WEB ダッシュボードでの結果表示も対応。 目安: 2〜4ヶ月 / 解析〜可視化](https://technosphere.co.jp/contact) ### [人流計測 人流カウント・混雑ヒートマップシステム 商業施設・展示会・施設内の入退場カウントや混雑可視化。エッジ処理でプライバシーに配慮した運用も対応。 目安: 1〜3ヶ月 / 設置〜可視化](https://technosphere.co.jp/contact) ### [OCR / 文字 OCR・バーコード・銘板読み取り自動化 伝票・銘板・型番・シリアル番号などのカメラ取り込みと自動化。手書き / かすれ文字にはマルチモーダル LLM（vLM）併用で精度確保。 目安: 1〜2ヶ月 / 単機能〜業務組込](https://technosphere.co.jp/contact) ### [エッジ実装 Jetson / Raspberry Pi へのエッジ画像 AI 実装 クラウドに画像を送れない現場向けに、TensorRT / ONNX で軽量化したモデルを Jetson / Pi にデプロイ。完全オフラインで運用可能。 目安: 1〜3ヶ月 / 軽量化＋設置](https://technosphere.co.jp/contact) ※上記以外のご相談も歓迎です。[まずはお気軽にご相談ください](https://technosphere.co.jp/contact)。 ## SOLUTIONS 対応ソリューション あらゆるカメラ映像から必要な情報を抽出し、現場で使えるシステムとして実装します。 （図: 物体検知・識別システム） 物体検知・識別 ** ## 物体検知・識別システム YOLOv8 を用いてカメラ映像からリアルタイムに物体を検出・分類します。工場ライン上の製品種別判別、駐車場の車両検知、物流倉庫の荷物識別など多彩な用途に対応。独自データセットでのファインチューニングにより高精度な識別を実現します。 - YOLOv8 - リアルタイム検出 - マルチクラス識別 - カスタム学習 - TensorRT高速化 （図: 骨格検出・歩行解析・リハビリスコア化） 骨格検出・歩行解析 注目 ** ## 骨格検出による歩行解析・リハビリスコア化システム MediaPipe Pose / OpenPose でカメラ映像から33点の骨格ランドマークをリアルタイム検出。歩行時の関節角度・重心移動・左右対称性・歩幅・ケイデンス（歩調）を定量化し、正常歩行からの逸脱度をスコアとして算出します。リハビリの成果を数値・グラフで可視化し、患者さんのモチベーション向上と理学療法士の評価業務効率化を支援します。 #### スコア化・可視化できる指標 - 股関節・膝関節・足関節の角度推移グラフ - 歩幅・歩速・ケイデンス（歩/分）の自動計測 - 左右非対称スコア（0〜100点） - 正常歩行データベースとの比較レポート - リハビリ前後の時系列推移グラフ - MediaPipe Pose - OpenPose - 関節角度計測 - スコア算出 - エッジ処理対応 - 個人情報保護 （図: 侵入検知システム） 侵入検知 ** ## 侵入検知・立入禁止エリア監視システム 工場・倉庫・施設の立入禁止エリアへの人物侵入を即時検知し、アラート通知を発報します。ポリゴンで任意の検知ゾーンを設定でき、既存の防犯カメラへの後付け導入も可能。誤検知を抑えるための時間帯フィルターや物体サイズフィルタも実装します。 - ゾーン設定 - 即時アラート - 既設カメラ対応 - メール/LINE通知 - 録画連携 （図: 人流・流入流出計測システム） 人流計測 ** ## 人流・流入流出計測システム 入口・出口・通路に設置したカメラで人の流入・流出数をリアルタイムに計測します。時間帯別・曜日別の人流データを蓄積し、店舗の混雑予測・動線分析・マーケティング活用・防災避難計画の立案に役立てます。ヒートマップ表示やダッシュボード表示にも対応。 - 入退場カウント - リアルタイム在場人数 - ヒートマップ - ダッシュボード - CSV出力 （図: 製品外観検査・欠陥検出システム） 製品外観検査 ** ## 製品外観検査・欠陥検出システム 製造ラインのカメラ映像から製品の傷・打痕・欠け・変色・異物混入をリアルタイムに検出します。ネジ山の打痕検査・基板のはんだブリッジ検出・食品の異物検知など多様な検査実績あり。不良品を自動的に排除するPLC連携にも対応します。 - 欠陥検出 - 0.1mm精度 - PLC連携 - 検査結果DB蓄積 - NG品自動排除 ** OCR・バーコード ** ## OCR・バーコード・文字認識システム 製品・伝票・帳票の文字・数字・バーコード・QRコードを一括認識してシステムに自動入力します。複数バーコードの同時読み取り、手書き文字のOCR、日本語帳票のデジタル化など、現場に合わせた認識エンジンを構築します。 - 複数バーコード同時読取 - QRコード - 手書きOCR - 帳票デジタル化 - Tesseract / EasyOCR ## TECH STACK 対応技術スタック AIフレームワークから組込みエッジデバイス、クラウド連携まで一貫して対応します。 ** #### AI・推論フレームワーク YOLOv8 / v10 MediaPipe OpenPose TensorRT ONNX Runtime PyTorch TensorFlow HALCON ** #### カメラ・画像処理 OpenCV V4L2 / GStreamer MIPI CSI-2 GigE Vision USB3 Vision RTSP / ONVIF Pillow / scikit-image ** #### エッジデバイス・ハード NVIDIA Jetson Orin Jetson Nano / Xavier Raspberry Pi 4/5 Hailo-8 Google Coral TPU 産業用PC (x86) ** #### クラウド・バックエンド連携 AWS Rekognition Azure Computer Vision FastAPI / Django WebSocket 配信 PostgreSQL / InfluxDB Grafana ダッシュボード PLC / Modbus 連携 ## OUR STRENGTHS テクノスフィアの強み ** ### エッジ処理でオフライン完結 クラウドに映像を送らず、現場のエッジデバイス上で完結する推論システムを構築。 医療・金融・工場など情報漏洩リスクを許容できない現場でも安心して導入できます。 組込み開発チームとの連携でJetson・Raspberry Piへの実装もスムーズです。 - 映像データのクラウド送信なし - Jetson Orin 上で 30fps+ 推論 - 組込みチームと一体開発 ** ### PoC（概念実証）から量産まで 「本当に使えるか試したい」というPoC段階から対応。 サンプル画像・映像をいただいてから検証し、実用に足る精度が出たことを確認した上で本開発に進みます。 プロトタイプ → パイロット導入 → 量産展開の各ステップを支援します。 - サンプルデータだけでPoC開始可能 - 精度検証レポートを提出 - パイロット→全拠点展開まで対応 ** ### WEBシステムへの結果表示も一貫対応 カメラ映像解析だけでなく、検査結果のDB蓄積・WEBダッシュボード表示・帳票出力・管理者通知まで、 WEBシステム開発チームと連携して「現場で使えるシステム」として仕上げます。 APIバックエンドとして既存システムへの組み込みも可能です。 - 検査結果のリアルタイムWEB表示 - スコア推移グラフ・CSV出力 - 既存システムへのAPI組み込み ## DEVELOPMENT PROCESS 開発フロー 01 #### ヒアリング・現場調査 「何をカメラで検出したいか」「どんな精度が必要か」「既存カメラを使えるか」をヒアリング。必要に応じて現場に赴き、照明環境・カメラ設置位置・撮影対象のサイズ・スピードを確認します。 02 #### データ収集・アノテーション 検出対象の画像・映像サンプルを収集。良品・不良品・正常姿勢・異常姿勢など、AIに学習させるデータへのアノテーション（ラベル付け）を実施します。データ拡張（augmentation）で少ないデータからも高精度な学習を目指します。 03 #### モデル学習・PoC（概念実証） 学習済みモデルをファインチューニングし、対象環境に特化したモデルを構築。精度・再現率・処理速度を計測し、実用に足る性能が出るか検証レポートを提出します。 04 #### システム実装・エッジデプロイ 推論モジュール・アラート通知・DB保存・ダッシュボードを実装。Jetson・Raspberry Pi・産業用PCへのデプロイ、TensorRTによる推論高速化、RTSP映像取得などの本番環境構築を行います。 05 #### 現場テスト・チューニング 実際の現場環境（照明変化・振動・対象速度など）で動作検証。誤検知・見逃しが出た場合はデータ追加学習・閾値調整・前処理改善でチューニングします。 06 #### 本番稼働・保守サポート 本番稼働後もモデル精度の定期評価、新しい不良パターンへの追加学習、ハードウェア障害対応など継続的に保守します。多拠点展開・新ラインへの水平展開も対応します。 ## CASE STUDIES 導入事例 製造・医療・流通・セキュリティ分野での代表的な事例をご紹介します。 （図: ネジ山打痕 外観検査システム） 製造業 ### ネジ山の打痕を自動検出する外観検査システム 製造ライン上を流れるボルト・ネジのネジ山部分を高解像度カメラで撮影し、0.1mm以下の打痕・変形を自動検出。従来の目視検査を置き換え、検査員の疲労による見逃しをゼロに。PLC連携でNG品を自動排除。 成果：検査精度 95%+、検査員削減 2名、ライン速度 1.5倍 YOLOv8OpenCVJetson OrinPLC連携 （図: リハビリ歩行解析スコアリングシステム） 医療・リハビリ ### リハビリ施設向け 歩行スコアリング・進捗可視化システム カメラ1台で患者の歩行を撮影し、MediaPipeで骨格を検出。股関節・膝・足首の角度・歩幅・左右対称性をリアルタイム計測してスコア化。担当PTが紙でつけていた評価をシステムが自動生成し、リハビリ成果の推移グラフで患者への説明・モチベーション管理を効率化。 成果：PT評価時間 60%削減、患者満足度スコア 1.4倍 MediaPipePythonRaspberry Pi 5DjangoChart.js （図: 商業施設 人流計測・混雑分析システム） 流通・商業施設 ### 商業施設 入退場カウント・混雑ヒートマップシステム ショッピングモールの各エントランスに設置した既存IPカメラから映像を取得し、入退場人数をリアルタイムにカウント。フロアごとの在場人数・時間帯別混雑度をWEBダッシュボードで可視化。テナント誘致や人員配置の最適化に活用。 成果：人員配置最適化で人件費 15%削減、繁閑予測精度 90%+ YOLOv8RTSP取得FastAPIReactInfluxDB ## FAQ よくある質問 はい、用途に応じた最適なカメラ（USB / GigE Vision / MIPI CSI / 赤外線 / 産業用ラインスキャンカメラなど）の選定をご提案します。ハードウェアの調達・設置はパートナー企業と連携して対応可能です。 はい、RTSP・ONVIF対応のIPカメラであれば既設カメラからの映像取得に対応しています。既存の監視カメラ・防犯カメラにAI解析機能を後付けする形で導入可能です。アナログカメラでもエンコーダー経由でIP化すれば対応できます。 NVIDIA Jetson Orin + TensorRT構成で30fps以上のリアルタイム推論を実現できます。処理速度はカメラ解像度・検出モデルのサイズ・ハードウェアスペックに依存しますので、要件をお聞きした上でPoC（概念実証）から始めることをお勧めします。 リハビリ施設・病院・介護施設・スポーツジム・工場の作業姿勢管理など幅広く対応します。カメラ1台で複数人の骨格を同時検出でき、スコアリングの基準値は実際の歩行データを元に調整します。個人情報保護のためエッジ処理（クラウド不要）での実装も可能で、映像を外部に送信しない構成にできます。 学習データの量と品質に大きく依存しますが、ネジ山打痕検査で検知精度95%以上、0.1mmレベルの微細欠陥検出の実績があります。まずサンプル品と不良品画像をご提供いただき、PoC（概念実証）で精度を検証してから本開発を進めます。 はい、エッジ処理による完全オフライン動作に対応しています。NVIDIA Jetson・Raspberry Pi・産業用PC（Windows / Linux）へのオンプレミス実装が可能で、映像データをクラウドに送信しないため情報漏洩リスクを排除できます。医療・金融・官公庁などセキュリティ要件の厳しい環境に最適です。 ## RELATED ARTICLES 技術ブログ｜画像 AI の仕組みと現場導入 AI 画像検査の原理・エッジ実装・現場導入事例・関連技術を技術ブログで公開しています。 ### [AI 画像検査 / 基礎 AI 画像検査とは？仕組み・導入の流れ・対応事例 異物混入・加工不良・キズ欠け・印字ズレなど、カメラ × AI で検出する仕組みを解説。](https://technosphere.co.jp/de-blog/2026-04-12-camera-image-inspection-system) ### [エッジ AI / vLM Raspberry Pi × vLM ｜現場画像 AI のエッジ実装 クラウドに送れない現場画像を Raspberry Pi 上の vLM で AI 化する PoC 構築手順。](https://technosphere.co.jp/blog/raspberry-pi-vlm-edge-ai) ### [マルチモーダル AI 画像 × AI × ブラウザ操作の業務自動化 マルチモーダル LLM で画像分類・図面読み取り・帳票確認を半自動化する設計。](https://technosphere.co.jp/blog/openclaw-skills-image-browser) ### [TinyML / 組込み AI STM32Cube.AI ｜マイコン上で動かす TinyML 入門 予知保全・異常検知・キーワード認識など、組込み AI のメモリ最適化と量産化。](https://technosphere.co.jp/blog/stm32-cube-ai-tinyml) ### [AI 導入事例 SUGUMEN 導入事例｜小売業の AI 面接で工数 70% 削減 大量採用の現場で AI 面接を活用し、面接工数を大幅削減した実例。](https://technosphere.co.jp/blog/sugumen-case-study-retail) ### [実績紹介 組込み制御・マイコン開発 実績紹介 画像認識システムを含む組込み開発実績。業種別・技術別に多数掲載。](https://technosphere.co.jp/embedded-achievements) [技術ブログ一覧を見る](https://technosphere.co.jp/blog/) ## 「カメラで何かできないか？」まずご相談ください 製品検査・歩行解析・侵入検知・人流計測など、 「こういうことをやりたいが実現できるか？」という段階からご相談いただけます。 サンプル画像・映像をお送りいただければ、PoC（概念実証）から対応します。 [無料相談・お問い合わせ](https://technosphere.co.jp/contact) [トップに戻る](https://technosphere.co.jp/) [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [技術コラム](https://technosphere.co.jp/blog/) [採用情報](https://technosphere.co.jp/recruit) [プライバシーポリシー](https://technosphere.co.jp/privacy) © 2023 Technosphere Inc. - [Facebook](https://www.facebook.com/technosphere.co.ltd) - [X（旧Twitter）](https://x.com/technosphere_co) - [Instagram](https://www.instagram.com/technosphere_co/) - [TikTok](https://www.tiktok.com/@technosphere.co) --- # 組込みシステム開発｜STM32・ラズパイ・Jetson対応｜実績50件超｜テクノスフィア > STM32・Raspberry Pi・Jetson・ルネサス等あらゆるマイコンに対応した組込み開発。UART/I2C/SPI/CAN通信、画像処理AI、センサー制御からクラウド連携まで。設計・試作・量産を一貫対応、開発実績50件以上。まずは無料相談から。 URL: https://technosphere.co.jp/embedded [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [採用情報](https://technosphere.co.jp/recruit) （図: マイコン組込み制御開発） ** Embedded & Microcontroller Development # 組込み制御・マイコン開発 あらゆるマイコン・プラットフォームに対応 Raspberry Pi・Jetson・Arduino から STM32・ルネサス・TI・日立まで センサー制御・通信・AI推論・クラウド連携を一貫して実現 50 件+ 開発実績 10 種+ 対応マイコン 6 社 ハードパートナー 無料相談はこちら ## ORDER MENU こんな依頼ができます｜発注メニュー 「組込み開発」だけだとイメージしにくい方へ。お客様がそのままご相談いただける具体的な発注メニューをご用意しています。 ### [PoC / 試作 STM32 / Jetson / Raspberry Pi の試作・量産前 PoC 「マイコンで○○を動かせるか」を最短2週間〜で検証。回路相談 → 試作ファームウェア → 実機動作確認まで対応。 目安: 2週間〜2ヶ月 / PoC](https://technosphere.co.jp/contact) ### [量産設計 バッテリー駆動 IoT センサーノードの設計・量産 STM32L4 / U5 の Stop / Standby モードを駆使し、ボタン電池で年単位稼働する屋外センサー・ウェアラブルを設計。 目安: 3〜6ヶ月 / 量産設計](https://technosphere.co.jp/contact) ### [レガシー再生 ソースコードがない旧基板の逆アセンブル・再構築 RL78 / Z80 / 8051 / 旧ルネサスの hex / elf を解析し、最新マイコン（STM32 / RA など）へポーティング。部品廃止対応に。 目安: 2〜6ヶ月 / 解析 + 再開発](https://technosphere.co.jp/contact) ### [エッジ AI エッジ AI 内蔵装置（Jetson / Raspberry Pi / vLM）の現場導入 クラウドに送れない現場画像の AI 化、YOLOv8 / vLM をエッジで動かす装置の設計・筐体・配線・運用監視まで。 目安: 1〜4ヶ月 / PoC 〜 量産](https://technosphere.co.jp/contact) ### [産業 IoT 産業 IoT ゲートウェイ・センサー監視システム構築 温湿度・振動・電流データを Raspberry Pi / Linux SoC で収集し、AWS IoT / Azure IoT へ送信。設備監視 SaaS まで対応可。 目安: 2〜4ヶ月 / 設置〜運用](https://technosphere.co.jp/contact) ### [通信実装 CAN / MODBUS / PROFINET など産業通信プロトコル実装 PLC・産業機器・車載 ECU と接続するゲートウェイ装置の通信スタック実装と現場ノイズ環境での安定動作確認まで。 目安: 1〜3ヶ月 / 実装 + 評価](https://technosphere.co.jp/contact) ※上記以外のご相談も歓迎です。[まずはお気軽にご相談ください](https://technosphere.co.jp/contact)。 ## SUPPORTED PLATFORMS 対応マイコン・プラットフォーム 業界を問わず、あらゆるマイコン・SoC のソフトウェア開発に対応します。ハードウェアの選定・設計はパートナー企業が対応可能です。 ** ### シングルボードコンピュータ（SBC） Raspberry Pi 4/5 Raspberry Pi Zero 2W BeagleBone Orange Pi Rock Pi Linux / Python / C++ でのアプリ開発・制御・IoT連携に対応 ** ### エッジAI・GPU搭載ボード NVIDIA Jetson Orin Jetson Nano / Xavier Google Coral Hailo-8 YOLOv8・TensorRT によるリアルタイム物体検知・識別を実装 ** ### マイクロコントローラ（MCU） Arduino Uno / Mega / Nano STM32（STMicroelectronics） ルネサス RA / RX / RH850 TI MSP430 / Tiva C 日立 / 三菱系 MCU ESP32 / ESP8266 NXP Kinetis / LPC Microchip PIC / dsPIC AVR (Atmel) RP2040 (Pico) ペリフェラル設定・ドライバ開発・RTOS対応まで一貫して実施 ** ### 産業用 SoC・組込み Linux NXP i.MX 6/7/8/9 Qualcomm QCS / SA シリーズ Rockchip RK3588 Amlogic S905 Texas Instruments AM シリーズ Yocto / Buildroot / Android BSPのカスタマイズ・ポーティングに対応 ## WHAT WE DO 組込み開発でできること センサーの読み取りから表示・通信・AI推論・クラウド連携まで、ソフトウェアに関わる全工程をカバーします。 ** ### 各種センサー接続・データ取得 温湿度・気圧・照度・CO₂・加速度・ジャイロ・距離（ToF/超音波）・GPSなどあらゆるセンサーを接続し、リアルタイムにデータを取得・処理します。 - I2C / SPI 接続センサー - ADC（アナログ入力） - エンコーダ・ホールセンサー - 産業用センサー（RS-485） ** ### LED・LCD・7セグ 表示制御 LED（単色・RGB・WS2812Bなどフルカラー）、キャラクタ液晶 / グラフィック LCD、7セグメントディスプレイ、OLEDなど各種表示デバイスの制御を実装します。 - WS2812B / Neopixel LEDストリップ - I2C / SPI LCD（ST7735・ILI9341等） - 7セグ 多桁 ダイナミック点灯 - OLED（SSD1306等） ** ### カメラ接続・検査・物体検知 CSI / USB カメラの接続から OpenCV による画像前処理、YOLOv8 / TensorRT によるリアルタイム物体検知・識別・外観検査システムを構築します。 - MIPI CSI-2 カメラ制御 - OpenCV 画像処理 - YOLOv8 物体検知・識別 - 外観検査・異常検知 ** ### ペリフェラル設定・ドライバ開発 GPIO・タイマー・PWM・WDT・RTC・DMA などマイコン内部ペリフェラルのレジスタ設定からドライバ実装まで対応。HAL / LL ライブラリ・ベアメタル双方に対応します。 - GPIO / PWM / タイマー割込み - ADC / DAC - DMA 転送設定 - ブートローダー / フラッシュ書込み ** ### ストレージ・メモリアクセス 内蔵フラッシュ・外付け SPI Flash / EEPROM・SD カード（FAT/exFAT）・eMMC・NVMe の読み書き制御、ファイルシステム実装を行います。 - SPI NOR / NAND Flash - SD カード / eMMC - FATFS / LittleFS - 内蔵 EEPROM / バックアップ RAM ** ### 各種通信プロトコル実装 マイコン間・センサー間の短距離通信から、ネットワーク・クラウド連携まで、あらゆる通信プロトコルに対応します。 - UART / RS-232 / RS-485 - I2C / SPI / 1-Wire - CAN / CAN FD（車載・産業） - Bluetooth / BLE - Wi-Fi（TCP/UDP / MQTT） - Ethernet / HTTP / WebSocket - LoRa / Zigbee / Z-Wave - Modbus RTU / TCP ** ### クラウド連携・IoT基盤構築 デバイスで収集したデータを AWS IoT Core・Azure IoT Hub・Google Cloud IoT へ MQTT / HTTPS で送信し、ダッシュボード表示・アラート・遠隔制御を実現します。 - AWS IoT Core / Greengrass - Azure IoT Hub - MQTT ブローカー構築 - OTA（Over-the-Air）アップデート ** ### ローカルLLM・エッジAI構築 クラウドに頼らず、Jetson Orin や高性能 SBC 上に LLM（Llama・Gemma・Mistral 等）を動作させるオフライン AI アシスタント・FAQ ボットを構築します。製造ラインでのリアルタイム異常検知にも対応。 - llama.cpp / Ollama on Jetson - RAG + ローカル LLM 構築 - TensorRT / INT8 量子化推論 - エッジ推論（YOLOv8 / MobileNet） ## OUR STRENGTHS テクノスフィアの強み ** ### ソフト×ハードの一気通貫 ソフトウェアはテクノスフィアが担当し、 ハードウェア設計・基板製造はパートナー企業と連携。 「何でも対応」ではなく、専門家が分業して品質を担保します。 - ソフト開発〜量産サポートまで - ハード設計パートナー企業と協業 - プロトタイプ〜製品化まで一貫 ** ### 低レイヤーから上位アプリまで ベアメタル・RTOS のレジスタ設定から Linux アプリ・クラウド連携・AI推論まで、 全レイヤーを一社でカバーできます。 - ベアメタル / RTOS / Linux - ドライバ〜アプリ全レイヤー対応 - AI推論・クラウド連携も同一チーム ** ### マイコン変更・ポーティング実績多数 部品調達難や新機種移行に伴うマイコン変更・ ファームウェアの移植を多数手がけてきました。 既存コード資産を最大限活用した効率的な移行を実現。 - NXP i.MX 各世代間ポーティング - STM32 シリーズ間移植 - Yocto / BSP カスタマイズ ** ### レガシーシステムの逆アセンブル・再構築 仕様書やソースコードがない古い組込み機器でも、 バイナリ解析・逆アセンブルでC言語に復元。 20年前の機器から最新マイコンへの移行も対応します。 - elfファイル・バイナリからの逆アセンブル - レジスタレベル動作の再現・検証 - Z80・AVR・ARM など幅広いアーキテクチャ ## DEVELOPMENT PROCESS 開発フロー 01 #### ヒアリング・要件定義 使用するマイコン・センサー・通信方式のご要望をヒアリングし、実現可能な仕様に落とし込みます。 02 #### ハード選定・ソフト設計 パートナー企業とハード構成を確定し、ソフトウェアアーキテクチャを設計。コスト・納期・消費電力を最適化します。 03 #### ファームウェア実装 ペリフェラル設定・ドライバ・アプリ層を段階的に実装。C/C++・Python・Rustに対応し、コードレビュー・静的解析で品質を管理します。 04 #### テスト・実機検証 単体・結合テストはもちろん、実機でのストレステスト・通信耐久試験・環境試験にも対応。JTAG・ロジックアナライザを用いたデバッグも実施します。 05 #### 納品・量産サポート・保守 ドキュメント整備・OTAアップデート対応・量産時の書込み治具作成まで対応。納品後の保守・機能追加も継続的にサポートします。 ## TECH STACK 対応技術スタック ** #### 対応マイコン・SoC Raspberry Pi NVIDIA Jetson Arduino STM32 ルネサス RA/RX TI MSP430 日立 MCU NXP i.MX ESP32 PIC / AVR ** #### プログラミング言語 C / C++ Python Rust Assembly Java MicroPython ** #### OS・プラットフォーム Linux (組込) FreeRTOS Zephyr RTOS Yocto / Buildroot Android (AOSP) ベアメタル ** #### 通信プロトコル UART / RS-485 I2C / SPI CAN / CAN FD Bluetooth / BLE Wi-Fi / MQTT Ethernet LoRa / Zigbee Modbus ** #### カメラ・画像処理・AI V4L2 / MIPI CSI OpenCV YOLOv8 TensorRT GStreamer llama.cpp Ollama ** #### クラウド・IoT基盤 AWS IoT Core Azure IoT Hub Google Cloud IoT OTA アップデート Node-RED Grafana ## CASE STUDIES 開発実績 カメラ・映像系、産業・IoT系、マイコンポーティングなど50件以上の開発実績があります。 詳細は実績紹介ページをご覧ください。 **生産中止マイコンの移行をご検討中の方へ** H8・SuperH・8051・Z80・東芝TLCSなどの移行先候補と、工数を押し上げる要因を 移行元から逆引きできる [マイコン移行判断ナビ](https://technosphere.co.jp/mcu-migration) を公開しています。 ### [カメラ・映像系 AndroidTVカメラ・デジタルカメラAF制御・Linuxドライバ・8Kエンコードなど](https://technosphere.co.jp/embedded-achievements) ### [産業・インフラ・IoT 系 ホームセキュリティー・振動データロガー・重機CAN制御など](https://technosphere.co.jp/embedded-achievements) ### [マイコン変更・ポーティング NXP i.MX・STM32・Yocto BSPカスタマイズなど多数対応](https://technosphere.co.jp/embedded-achievements) [全実績を見る（カメラ・産業・IoT・ポーティング）](https://technosphere.co.jp/embedded-achievements) ## FAQ よくある質問 はい、対応可能です。Raspberry Pi は Linux ベースで GPIO・I2C・SPI・UART・Ethernet・Wi-Fi を標準搭載しており、センサー収集からクラウド送信まで一台で実現できます。Arduino は低コストで堅牢なリアルタイム制御に適しており、センサー読み取り・LED/LCD 表示・モーター制御などで多数の実績があります。用途に合わせた最適なプラットフォームをご提案します。 はい、対応可能です。STM32 シリーズは HAL / LL ライブラリ・CubeMX を使った開発から、ベアメタルでのレジスタ直書きまで対応します。ルネサス（RA / RX / RH850 シリーズ）も、e² studio や CS+ を使った開発実績があります。TI（MSP430・Tiva C）・日立・三菱系 MCU も対応可能です。 はい、重機の自動制御システムで CAN / CAN FD を用いた開発実績があります。Modbus RTU / TCP も産業設備向け案件で対応実績があります。その他 UART / RS-485・I2C / SPI・Bluetooth / BLE・Ethernet（MQTT・HTTP）など各種通信プロトコルに対応しています。 NVIDIA Jetson Orin + YOLOv8 + TensorRT の構成で、工場の製造ラインを想定した小型欠陥の検知精度 90%以上・処理速度 30fps 以上を実現した実績があります。精度は学習データの量と質に大きく依存するため、まずはサンプル画像をご提供いただき、PoC（概念実証）からスタートすることをお勧めします。 はい、完全オフラインで動作するローカル LLM・エッジ AI の構築が可能です。Jetson Orin 上で llama.cpp / Ollama を動作させ、クラウドへの通信なしに LLM ベースの FAQ 応答や設備診断を実現できます。製造ライン・医療機器・官公庁など、セキュリティ上クラウド接続が困難な環境に最適です。 弊社はソフトウェア開発が専門ですが、長年のお付き合いのあるハードウェア設計・基板製造のパートナー企業と連携しています。「ハードもソフトもまとめてお願いしたい」という場合は、弊社が窓口となりパートナー企業と協力して対応します。まずはご相談ください。 ## RELATED ARTICLES 技術ブログ｜組込み開発の実装ガイド STM32 / Renesas / Raspberry Pi の実装ノウハウや、量産トラブル救出・レガシー基板の再生まで、現場の知見を技術ブログで公開しています。 ### [STM32 / 通信 STM32 の UART・I2C・SPI・CAN 通信 実装ガイド HAL ライブラリで通信ペリフェラルを使いこなす定番ガイド。割り込み / DMA まで網羅。](https://technosphere.co.jp/blog/stm32-uart-i2c-can) ### [STM32 / DMA STM32 DMA 完全ガイド｜ADC・UART・SPI 連携 CPU 負荷を最小化する DMA 活用の決定版。Circular / Double Buffer まで解説。](https://technosphere.co.jp/blog/stm32-dma-complete-guide) ### [STM32 / 低消費電力 STM32 低消費電力モード完全ガイド｜バッテリー駆動 Stop / Standby / Shutdown を駆使した年単位駆動 IoT 端末の設計ノウハウ。](https://technosphere.co.jp/blog/stm32-low-power-battery) ### [STM32 / トラブル ST-LINK 接続トラブル救出ガイド｜14 ステップ SWD ピン GPIO 化・RDP・Stop モード突入の典型 9 割を救う実践チェックリスト。](https://technosphere.co.jp/blog/stm32-swd-debugger-rescue) ### [ルネサス / 逆アセンブル ルネサス RL78 の逆アセンブル実践ガイド 仕様書もソースもない 15 年前の旧基板を elf ファイルから C 言語に復元した事例。](https://technosphere.co.jp/blog/renesas-rl78-reverse-engineering) ### [Raspberry Pi / IoT Raspberry Pi で産業 IoT｜BME280 / CO₂ / AWS IoT 連携 I2C / SPI センサー読み取り → MQTT で AWS IoT Core 送信までの実装手順。](https://technosphere.co.jp/blog/raspberry-pi-sensor-iot) [技術ブログ一覧を見る](https://technosphere.co.jp/blog/) ## 組込み制御・マイコン開発のご相談はお気軽に Raspberry Pi・Jetson・Arduino から STM32・ルネサス・TI まで センサー・通信・AI・クラウド連携を含む一気通貫の開発をご提案します。 [無料相談・お問い合わせ](https://technosphere.co.jp/contact) [開発実績を見る](https://technosphere.co.jp/embedded-achievements) [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [技術コラム](https://technosphere.co.jp/blog/) [採用情報](https://technosphere.co.jp/recruit) [プライバシーポリシー](https://technosphere.co.jp/privacy) © 2023 Technosphere Inc. - [Facebook](https://www.facebook.com/technosphere.co.ltd) - [X（旧Twitter）](https://x.com/technosphere_co) - [Instagram](https://www.instagram.com/technosphere_co/) - [TikTok](https://www.tiktok.com/@technosphere.co) --- # WEB系システム開発｜生産管理・販売管理・ECサイト・ポーティング｜.NET・PHP・Python・JavaScript対応｜株式会社テクノスフィア > 大阪のテクノスフィアが、生産管理・販売管理・ECサイト・予約システム等のWEBシステムを受託開発。.NET / Laravel / Django / React・Next.js 対応。レガシーシステムの最新化も。 URL: https://technosphere.co.jp/web-system [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [採用情報](https://technosphere.co.jp/recruit) （図: WEBシステム開発） ** Web System Development # WEB系システム開発 業務系から消費者向けまで、あらゆるWEBシステムを一貫開発 生産管理・販売管理・顧客管理・ECサイト・予約システムなど、 .NET・PHP・Python・JavaScriptを駆使してバックエンドからフロントエンドまで対応。 古いシステムの最新プラットフォームへのポーティングも得意とします。 20年+ 開発実績 4言語 .NET / PHP / Python / JS 100% フルスタック対応 無料相談はこちら ## WHAT WE BUILD 対応できるシステム 業種・規模を問わず、社内業務系からコンシューマー向けサービスまで幅広く対応します。 ** ### 生産管理・製造管理システム 工程管理・在庫管理・品質管理・BOM管理を一元化。工場の現場端末対応や PLC・センサーとの連携も実績あり。 - 工程管理 - 在庫管理 - 品質検査 - BOM管理 - PLC連携 ** ### 販売管理・受発注システム 受注・発注・請求・入金消込を一括管理。EDI連携・API連携による他システムとの自動連携にも対応。 - 受発注管理 - 請求・入金 - EDI連携 - 在庫連動 ** ### 顧客管理（CRM）・会員管理 顧客情報・購買履歴・問い合わせ管理を集約。マーケティング自動化・メール配信との連携も対応。 - 顧客DB管理 - 購買履歴 - ポイント管理 - 会員ランク ** ### ECサイト・コンシューマー向けWEB フルスクラッチのECサイトからカート・決済連携・在庫連動まで構築。BtoBの企業向け受発注WEBにも対応。 - カート・決済 - 商品管理 - 在庫連動 - BtoB受発注 ** ### 予約・スケジュール管理 医療・美容・施設向けの予約システム。リアルタイムな空き枠管理・自動リマインド・スタッフシフト連携に対応。 - 空き枠管理 - 自動リマインド - キャンセル処理 - 多拠点対応 ** ### グループウェア・社内ポータル ワークフロー承認・掲示板・文書管理・勤怠連携などを備えた社内向けポータル。既存グループウェアとのSSO連携も可能。 - ワークフロー - 文書管理 - SSO連携 - 勤怠連携 ** ### 医療・介護・検査管理 電子カルテ連携・検査結果管理・患者ポータル・問診票電子化など、個人情報保護・セキュリティ設計を重視した構築実績あり。 - 電子カルテ連携 - 検査結果管理 - 個人情報保護 - 患者ポータル ** ### レガシーシステムのポーティング VB6・旧ASP・Access・Delphi・旧PHPで構築された業務システムを、現代のWEBアプリケーションに移行。業務フローを維持したまま段階移行します。 - VB6 → .NET - 旧PHP → Laravel - Access → WEB - 段階移行 ** ### AI・データ分析との連携 RAGチャットボット・異常検知・需要予測など、AIモデルをWEBシステムのバックエンドに組み込むインテグレーションも対応。 - RAGチャットボット - 需要予測 - 異常検知 - API連携 ## TECH STACK 対応技術スタック フロントエンドからバックエンド・インフラまで、フルスタックで対応します。 ** #### バックエンド ASP.NET Core .NET MVC Laravel CakePHP Django FastAPI Node.js / Express Ruby on Rails ** #### フロントエンド React Next.js Vue.js Nuxt.js TypeScript Tailwind CSS Bootstrap jQuery ** #### データベース PostgreSQL MySQL / MariaDB SQL Server Oracle DB SQLite MongoDB Redis ** #### インフラ・クラウド AWS (EC2/RDS/S3) Azure App Service GCP さくらのクラウド Docker / Compose Nginx / Apache GitHub Actions CI/CD ## PLATFORM COMPARISON プラットフォーム別 対応内容 プロジェクトの要件・既存環境・保守体制に合わせて最適な技術スタックをご提案します。 | プラットフォーム | 主な言語・FW | 得意な用途 | ポーティング元 | | **.NET（ASP.NET Core）** | C# VB.NET | 企業向け業務システム・Windowsサーバー環境・既存.NETシステムの刷新 | VB6 / 旧ASP / Access / VBA | | **PHP（Laravel / CakePHP）** | PHP 8.x | Webサービス・ECサイト・CMSカスタマイズ・中小規模業務システム | 旧PHP（4/5系）/ WordPress / 素のPHP | | **Python（Django / FastAPI）** | Python 3.x | AI・データ分析連携・バッチ処理・API基盤・スクレイピング連携 | 旧PythonスクリプトのWEB化 / Excel業務のシステム化 | | **JavaScript（React / Vue / Next.js）** | TypeScript JS | SPA・リアルタイムUI・モバイルフレンドリーなコンシューマー向けサービス | jQueryアプリのモダン化 / 既存バックエンドへのSPAフロント追加 | | **Java（Spring Boot）** | Java 17+ | 大規模業務システム・マイクロサービス・金融・公共系 | 旧Struts / Servlet / EJB システム | ## OUR STRENGTHS テクノスフィアの強み ** ### バックエンドからフロントまで一社完結 DB設計・API開発・フロントエンドUI・インフラ構築まで、すべて同一チームが担当。 複数ベンダー間の認識齟齬がなく、品質・スピード・コストのバランスが高い水準で実現できます。 - DB設計〜API〜UI を一貫して担当 - インフラ（クラウド）構築も対応 - ベンダー間の調整コストゼロ ** ### レガシーシステムのポーティング実績多数 VB6・旧ASP・Access・古いPHPで動く業務システムを、モダンなWEBアプリに移行した事例が多数。 「仕様書がない」「担当者がいない」ような状況でも、リバースエンジニアリングで現行仕様を解析・再現します。 - 仕様書なしのリバースエンジニアリング対応 - 段階移行（並行稼働）プランを提案 - 既存データ移行・変換にも対応 ** ### 組込み・クラウドチームとの連携 WEBシステムの開発だけでなく、組込みデバイスからのデータ受信・クラウド基盤との連携・AI推論結果の表示など、 他サービスチームと連携した複合システムの構築が得意です。 - IoTデバイス連携WEBダッシュボード - AI推論結果のリアルタイム表示 - クラウド移行後の新WEBシステム構築 ## DEVELOPMENT PROCESS 開発フロー 01 #### ヒアリング・要件定義 業務フロー・登場人物（ユーザー）・データ構造・既存システムとの連携要件をヒアリング。「何を作るか」を明確化します。ポーティング案件では現行システムの調査・仕様把握から着手します。 02 #### 技術選定・アーキテクチャ設計 要件・保守体制・予算に合わせてプラットフォーム（.NET/PHP/Python/JS）とインフラを選定。DB設計・API設計・画面設計を並行して進めます。 03 #### フロントエンド・バックエンド実装 バックエンドAPI・DBマイグレーション・フロントエンドUIを同一チームで並行開発。GitHubフローによるコードレビューと静的解析で品質を担保します。 04 #### テスト・ステージング検証 単体・結合・E2Eテストに加え、ステージング環境でのユーザー受入テスト（UAT）を実施。セキュリティ診断（XSS/SQLi/CSRF）も対応します。 05 #### 本番リリース・データ移行 ブルーグリーンデプロイまたはメンテナンスウィンドウでの切り替え。既存システムからのデータ移行・変換スクリプトの作成・並行稼働検証を実施します。 06 #### 保守・運用・機能追加 バグ修正・セキュリティパッチ・フレームワークバージョンアップ・機能追加を継続サポート。月次レポートやコスト最適化レビューも提供します。 ## CASE STUDIES 開発・ポーティング事例 業種・システム種別を問わず多彩な案件を手がけてきました。 （図: 製造業 生産管理システム開発） 製造業 ### VB6製 生産管理システムを ASP.NET Core + React にリプレイス 20年稼働のVB6製生産管理システムをWEBアプリ化。仕様書なしのリバースエンジニアリングから着手し、工程管理・在庫管理・品質管理を新システムに移行。並行稼働期間を設けゼロダウンタイムで本番切り替え。 成果：入力工数 60%削減、在庫精度 99.5% 達成 ASP.NET CoreReactSQL ServerAzure （図: ECサイト・顧客管理システム） 小売・EC ### フルスクラッチ ECサイト + 顧客管理・ポイントシステム構築 既製カートでは対応できない複雑な販売ルール（BtoB価格体系・会員ランク別割引）を実装したフルスクラッチEC。バックオフィスの顧客管理・ポイント管理・メール配信を一体化。 成果：受注処理工数 75%削減、リピート率 1.4倍 LaravelVue.jsMySQLStripeAWS （図: レガシーシステムポーティング） サービス業 ### 旧ASP + Access 製 予約管理を Django + Next.js にポーティング IEでしか動かない旧ASP/Access製予約システムをモダンWEBへ移行。Accessのデータ構造を解析しPostgreSQLへ移行。スマートフォン対応・SMS自動リマインド・スタッフシフト連携を新規実装。 成果：予約キャンセル率 40%減、電話対応工数 55%削減 DjangoNext.jsPostgreSQLTwilio ## FAQ よくある質問 .NET（ASP.NET Core / MVC）、PHP（Laravel・CakePHP）、Python（Django・FastAPI）、JavaScript/TypeScript（React・Vue・Next.js・Node.js）に対応しています。お客様の保守体制・既存システム・要件に合わせて最適な技術スタックをご提案します。 はい、得意としています。VB6・旧ASP・Access・Delphi・古いPHP 4/5系で作られたシステムを最新のWEBアプリに移行した実績が多数あります。「仕様書がない」「担当者がいない」ケースでもリバースエンジニアリングで現行仕様を解析し、業務フローを維持したまま段階的に移行するプランをご提案します。 はい、対応可能です。REST API / GraphQL バックエンドのみ、React / Vue の SPA フロントエンドのみ、既存システムへの機能追加・改修のみ、など部分的なご依頼も承っています。お気軽にご相談ください。 はい、標準でレスポンシブデザインに対応します。現場での利用を想定した業務システムでは、スマートフォン操作に最適化したUIを設計します。PWA（Progressive Web App）化や、ネイティブアプリ向けAPI提供にも対応しています。 SQLインジェクション・XSS・CSRF対策はもちろん、認証基盤（OAuth2・JWT・多要素認証）・通信暗号化（HTTPS/TLS）・入力バリデーション・ログ監査など、要件に応じたセキュリティ設計を行います。必要に応じて外部のセキュリティ診断サービスとの連携もご提案します。 はい、納品後の保守契約をご用意しています。バグ修正・機能追加・フレームワークのバージョンアップ対応・サーバー監視・インシデント対応など、お客様のニーズに合わせたプランをご提案します。月次レポートやコスト最適化レビューも提供しています。 ## WEBシステム開発・ポーティングのご相談はお気軽に 「古いシステムをなんとかしたい」「複数ベンダーに断られた」という案件こそ、ぜひご相談ください。 .NET・PHP・Python・JavaScriptを駆使し、バックエンドからフロントエンドまで一貫して対応します。 [無料相談・お問い合わせ](https://technosphere.co.jp/contact) [トップに戻る](https://technosphere.co.jp/) [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [技術コラム](https://technosphere.co.jp/blog/) [採用情報](https://technosphere.co.jp/recruit) [プライバシーポリシー](https://technosphere.co.jp/privacy) © 2023 Technosphere Inc. - [Facebook](https://www.facebook.com/technosphere.co.ltd) - [X（旧Twitter）](https://x.com/technosphere_co) - [Instagram](https://www.instagram.com/technosphere_co/) - [TikTok](https://www.tiktok.com/@technosphere.co) --- # クラウドマイグレーション・サーバーレス化・コスト最適化｜AWS・Azure・GCP・OCI・さくらのクラウド対応｜株式会社テクノスフィア > テクノスフィアがクラウド移行・サーバーレス化・コスト最適化を一気通貫で受託。AWS / Azure / GCP / OCI / さくらのクラウド対応。COBOL・Windows Server 2003 等レガシー環境や逆移行（クラウド→オンプレ）も対応。 URL: https://technosphere.co.jp/cloud-migration [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [採用情報](https://technosphere.co.jp/recruit) Windows Server 2003 ** AWS EC2 完了 COBOL / AS/400 ** Azure VM 完了 Red Hat Linux 6 ** GCP GCE 完了 AWS（高コスト） ** さくらのクラウド コスト削減 Solaris / SPARC ** OCI 完了 ** CLOUD MIGRATION SERVICE # どんな古いシステムも、 どのクラウドへも。 移行実績 100件超。 オンプレミス ⇄ クラウド 双方向マイグレーション Windows Server 2003 / COBOL / AS/400 / Solaris など、 「もう誰も触れない」レガシーシステムの移行も、テクノスフィアにお任せください。 AWS・Azure・GCP・OCI・さくらのクラウドへの対応はもちろん、 クラウドからオンプレミスへの**逆移行**も、 稼働中クラウドの**サーバーレス化によるコスト削減**も得意分野です。 20年超 インフラ支援実績 100+ 移行プロジェクト 5 対応クラウド 0 重大障害件数 無料相談はこちら ケーススタディを見る PAIN POINTS ## こんなお悩み、ありませんか？ ** EOL・サポート終了 Windows Server 2003/2008、CentOS 6/7など保守期限切れのOSが本番稼働中。でも止められない… ** クラウドコストが爆増 AWSやAzureの月額費用が当初見積もりの数倍に。思い切ってオンプレに戻したい。 ** 担当者が誰もいない 構築した担当者が退職。ドキュメントもなく誰も手を付けられない古いサーバーが… ** セキュリティが不安 古いOSのまま外部公開しているシステムがある。脆弱性が心配だが移行方法が分からない。 ** パフォーマンスが限界 オンプレサーバーが老朽化。スペック不足でシステムが重く業務に支障が出始めている。 ** 別クラウドへ移したい 現在使っているクラウドベンダーのサービスや価格に不満。別のクラウドへ乗り換えたい。 👉 どのケースも、テクノスフィアが一気通貫で解決します。 SUPPORTED PLATFORMS ## 対応クラウド・OS・プラットフォーム 業界を問わず、あらゆる構成に対応します。「うちのは特殊で無理かも」と思った方こそ、まずご相談ください。 ### 対応クラウドプラットフォーム ** Amazon Web Services EC2 / RDS / S3 / ECS / Lambda など ** Microsoft Azure VM / SQL / Blob / AKS / Functions など ** Google Cloud GCE / GKE / Cloud SQL / BigQuery など ** Oracle Cloud OCI VM / Autonomous DB / OKE など ** さくらのクラウド VPS / クラウド / 専用サーバー など ** その他クラウド IDCFクラウド・富士通 FJcloud など ### 対応OS・レガシー環境 **Windows Server 2025/2022/2019 **Windows Server 2016/2012 **Windows Server 2008 / 2003（EOL） **Windows NT / 2000（超レガシー） **RHEL / CentOS Stream 9/8 **Ubuntu 22.04 / 20.04 LTS **CentOS 7 / 6（EOL） **Red Hat Linux 7 以前 **Solaris / SPARC **HP-UX / AIX **AS/400 / IBM iSeries **COBOL メインフレーム系 **macOS Server **Debian / AlmaLinux / Rocky Linux ** オレンジ表示はEOL（サポート終了）のレガシーOS。こちらも**対応実績あり**です。 MIGRATION PATTERNS ## 4つのマイグレーションパターン お客様の状況・目的に応じて最適なパターンをご提案します。双方向・マルチクラウドにも対応。 ** ### オンプレミス → クラウド 最多依頼パターン 自社サーバールームや専用線で動いているシステムを、AWSやAzureなどのパブリッククラウドへ移行します。 EOL対応・コスト削減・BCP強化・スケーラビリティ確保が主な目的です。 - Lift & Shift（そのまま移行）で短期移行も対応 - Re-platform（部分最適化）でコスト最適化 - Re-architect（クラウドネイティブ化）でフルリニューアル - 段階的移行でゼロダウンタイム移行を実現 - 移行後の運用監視・保守まで一貫サポート ** ### クラウド → オンプレミス 逆移行・クラウド撤退 「クラウドにしたがコストが予想以上」「データをクラウドに置きたくない」「レスポンスが遅い」。 そんな場合はオンプレミスへの回帰（クラウド撤退）をご支援します。 - クラウドコスト試算・オンプレ比較分析 - プライベートクラウド（VMware/Hyper-V）構築 - ハイブリッドクラウド構成への移行 - データ主権・法規制対応（GDPR・個人情報保護法） - 専有ハードウェアへのデータ移行・検証 ** ### クラウド → クラウド ベンダー乗り換え AWS から Azure へ、Azure から GCP へ、さらにはさくらのクラウドへのコスト最適化移行など、 クラウド間の乗り換えも豊富な実績があります。 - ベンダーロックイン解消・マルチクラウド化 - リージョン変更（東京・大阪・海外） - コスト最適化（リザーブドインスタンス活用） - Kubernetes / コンテナ移行（ECS → GKE 等） - マネージドDB乗り換え（RDS → Azure SQL 等） ** ### サーバーレス化・コスト最適化 ランニングコスト削減 クラウドで稼働中のシステムのランニングコストが膨らんでいる場合、**常時稼働のサーバーをサーバーレス構成に置き換える**ことで劇的なコスト削減が可能です。 - EC2 → Lambda＋API Gateway でサーバーレス化 - RDS → DynamoDB / Aurora Serverless v2 で従量課金化 - ECS → Fargate Spot でコンテナランニング削減 - 静的サイト → S3＋CloudFront で配信コスト最小化 - バッチ処理 → Lambda＋EventBridge で常時稼働ゼロへ MIGRATION FLOW ## 移行プロジェクトの進め方 初回ヒアリングから移行完了・運用引き継ぎまで、全工程をテクノスフィアが伴走します。 1 現状調査・ アセスメント 既存システム構成・OS・ミドルウェア・データ量を調査。移行リスクを洗い出します。 2 移行計画・ 設計 最適クラウド選定、アーキテクチャ設計、スケジュール・リスク対策を策定します。 3 移行先 環境構築 クラウド環境のセットアップ、ネットワーク・セキュリティ設定、IaC（Terraform等）による構築。 4 データ移行・ テスト 本番データの移行、動作検証、性能テスト、セキュリティチェックを実施します。 5 本番切り替え Blue/Greenデプロイ・DNS切り替えなどの手法でゼロダウンタイム切り替えを実現。 6 運用引き継ぎ・ 保守 監視設定・アラート・バックアップの整備、運用マニュアル作成、保守サポート開始。 OUR STRENGTHS ## テクノスフィアが選ばれる理由 「他社に断られた」「誰も手を付けられない」案件こそ、私たちの出番です。 ** 20年超 レガシー環境への深い理解 Windows NT・COBOL・AS/400・Solaris・HP-UXなど、現代のエンジニアが知らない環境も経験豊富なベテランが対応。ドキュメントが残っていないシステムも解読・移行できます。 ** 0件 移行による重大障害ゼロ 徹底した事前調査・テスト・ロールバック計画により、本番移行での重大障害は0件。夜間・休日の切り替え対応や段階的移行で、ビジネス継続性を最優先に設計します。 ** 双方向 オンプレ↔クラウド双方向に対応 「クラウドに移行したが、やっぱりオンプレに戻したい」という逆移行・クラウド撤退も得意です。コスト・セキュリティ・レイテンシなど、最適な環境を客観的にご提案します。 ** 全スタック インフラからアプリまで一気通貫 インフラ移行だけでなく、アプリケーションの修正・クラウドネイティブ化・コンテナ化まで対応。組込み・AI・Webシステムまで手がける総合力で、アーキテクチャ全体を見通した提案が可能です。 ** 適正価格 大手SIerに頼めない中規模案件が得意 数百万〜数千万規模の移行案件に強み。大手SIerでは対応してもらえない中小規模のシステム移行に多数対応。現実的なコストでハイクオリティな移行を実現します。 ** 24h 移行後の運用保守も継続サポート 移行して終わりではありません。24時間監視・アラート対応・パッチ運用・コスト最適化レポートなど、移行後の安定運用まで一貫してサポートします。 TECH STACK ## 活用する技術・ツール IaC / 自動化 ** Terraform ** Ansible ** AWS CDK ** Pulumi ** Chef / Puppet コンテナ・オーケストレーション ** Docker ** Kubernetes (EKS/AKS/GKE) ** Amazon ECS / Fargate ** Helm ** ArgoCD データ移行ツール ** AWS DMS ** Azure Migrate ** Google Transfer ** rsync / rclone ** Percona XtraBackup 監視・ログ ** Datadog ** Zabbix ** Prometheus + Grafana ** CloudWatch / Azure Monitor ** Fluentd / OpenSearch CASE STUDIES ## 移行・コスト最適化ケーススタディ クラウド移行・逆移行からサーバーレス化によるランニングコスト削減まで、実際のプロジェクト事例をご紹介します。詳細ページでアーキテクチャ図・コスト比較・タイムラインまで公開しています。 ### [（図: 製造業 Windows Server 2003 → AWS 移行） 製造業 AWS Windows Server 2003 稼働の生産管理システムをAWSへ無停止移行 Windows Server 2003 AWS EC2 SQL Server Lift & Shift 20年以上稼働し続けた生産管理システム。EOLのWindows Server 2003上で動作するカスタムアプリをAWSへ移行。週末の計画停止も最小化し、工場ラインへの影響ゼロで完了。 OUTCOME 運用コスト 40% 削減・障害対応時間 80% 短縮 詳細を見る](https://technosphere.co.jp/cloud-migration/manufacturing-windows-aws) ### [（図: 小売業 在庫管理 さくらのクラウド移行） 小売・卸売業 さくらのクラウド 老朽化した在庫管理システムをさくらのクラウドへ移行しコスト60%削減 CentOS 6 さくらのクラウド MySQL PHP 専用サーバーで動いていた在庫管理・受発注システム。ハードウェア老朽化とCentOS 6のEOLが重なり移行を決断。国内データセンター重視のためさくらのクラウドを選択。 OUTCOME 月額費用 60% 削減・バックアップ自動化・DR構成も実現 詳細を見る](https://technosphere.co.jp/cloud-migration/retail-onprem-sakura) ### [（図: 医療機関 AWS クラウドからオンプレ逆移行） 医療機関 逆移行 電子カルテシステムのAWSからオンプレミスへの逆移行（コスト・セキュリティ対応） AWS → オンプレ 電子カルテ PostgreSQL 個人情報保護 患者データをAWSに置くことへの懸念とコスト増大を理由に、プライベートサーバーへの逆移行を実施。院内ネットワーク完結・高速レスポンスを実現しながらも、DR用にAWSを活用するハイブリッド構成へ。 OUTCOME 月額費用 55% 削減・レスポンス 3倍高速化・コンプライアンス対応完了 詳細を見る](https://technosphere.co.jp/cloud-migration/medical-aws-onprem) ### [（図: 物流 COBOL AS/400 Azure マイグレーション） 物流・運輸 Azure 30年稼働のCOBOL/AS/400帳票システムをAzure上のWebシステムへフルリプレイス AS/400 COBOL Azure VM 再構築 30年以上現役のAS/400上のCOBOLシステム。ハードウェア更新のタイミングでAzureへの全面移行を決断。COBOLロジックをJava/Springに書き換え、Azureのマネージドサービスで再構築。 OUTCOME 処理時間 90% 短縮・保守性が大幅向上・ペーパーレス化達成 詳細を見る](https://technosphere.co.jp/cloud-migration/logistics-cobol-azure) ### [（図: IT企業 AWS から GCP 乗り換え） IT・SaaS企業 GCP SaaSプロダクトのAWSからGCPへの乗り換えでML基盤を強化・費用最適化 AWS → GCP Kubernetes BigQuery ML基盤 機械学習・データ分析機能の強化を目的にAWSからGCPへ移行。ECSをGKEに、RDSをCloud SQLに、S3をCloud Storageに移行。BigQueryとVertex AIを活用しML基盤を一新。 OUTCOME ML処理コスト 45% 削減・デプロイ頻度 3倍向上 詳細を見る](https://technosphere.co.jp/cloud-migration/itfirm-aws-gcp) ### [（図: 自治体 Solaris SPARC OCI Oracle Cloud 移行） 公共・自治体 OCI Solaris/SPARCで動く税務系基幹システムをOracle Cloud（OCI）へ移行 Solaris 10 SPARC OCI Oracle DB Solaris 10 / SPARC上のOracle DBを使った税務システム。SPARCサーバーのEOLに伴いOCIへの移行を実施。Oracle DBのライセンス移行とSolaris → Oracleクラウドの互換性を最大限に活用し、短期間で移行完了。 OUTCOME ハードウェア維持費 ゼロ化・可用性 99.95%達成・DR対応強化 詳細を見る](https://technosphere.co.jp/cloud-migration/government-solaris-oci) ### [（図: AWS EC2 サーバーレス化 Lambda コスト削減） EC・SaaS企業 サーバーレス化 AWS EC2常時稼働をサーバーレス化しランニングコスト72%削減 AWS Lambda API Gateway DynamoDB コスト最適化 EC2×8台を常時稼働させていたBtoB SaaSのAPI基盤。深夜はトラフィックがほぼゼロなのにフル課金という無駄をLambda＋DynamoDBへのサーバーレス化で解消。月額42万円→12万円に圧縮。 OUTCOME 月額費用 72% 削減・年間363万円コスト削減・常時稼働サーバーゼロ化 詳細を見る](https://technosphere.co.jp/cloud-migration/serverless-cost-opt) FAQ ## よくあるご質問 本当にWindows Server 2003やCOBOLなど古いシステムでも対応できますか？ はい、対応しています。Windows NT・2000・2003、CentOS 4/5/6、Solaris、AS/400/COBOL、HP-UXなどの超レガシー環境への移行実績があります。ドキュメントが残っていないシステムや「誰もソースを触ったことがない」というシステムも、まず現状調査から始めますのでお気軽にご相談ください。 稼働中のシステムを止めずに移行できますか？ ほとんどのケースでゼロダウンタイムまたは最小停止時間での移行が可能です。Blue/Greenデプロイメント、DNS切り替え、レプリケーション活用などの手法を組み合わせます。業務への影響を最小化する計画を事前に詳細設計します。 クラウドからオンプレミスへの「逆移行」も対応できますか？ はい、むしろ逆移行は弊社の得意分野の一つです。「クラウドの費用が想定より高い」「データを国内のオンプレに置きたい」「レスポンスが遅い」などの理由でのクラウド撤退を多数支援しています。ハイブリッド構成（一部オンプレ＋一部クラウド）への移行も対応します。 移行の費用はどのくらいかかりますか？ システムの規模・複雑性・移行後の構成によって大きく異なります。シンプルなLift&Shift移行であれば数十万円〜、大規模なリアーキテクチャを伴う移行では数百万〜数千万円規模になります。まず無料の現状調査・お見積もりを実施しますので、お気軽にご連絡ください。 移行後の運用保守も対応していますか？ はい、移行後の継続サポートも承っています。24時間監視・障害対応・セキュリティパッチ管理・コスト最適化レビュー・月次レポートなど、お客様のニーズに合わせた保守プランをご提案します。 大阪以外の企業でも対応できますか？ はい、全国対応しています。リモートでの調査・移行作業が中心ですが、必要に応じて現地訪問も対応可能です。これまでも東京・名古屋・福岡・北海道など全国各地のお客様の移行を支援しています。 クラウド移行を依頼する会社の選び方は？ クラウド移行の受託会社を選ぶ際は、(1)自社の現行環境（レガシーOS・言語・基盤）への対応実績、(2)特定クラウドに偏らずAWS/Azure/GCP/OCI/さくら等を中立に提案できるか、(3)移行だけでなく移行後の運用・コスト最適化まで伴走できるか、(4)現状調査・見積もりの透明性、の4点を確認することをおすすめします。テクノスフィアは100件超の移行実績をもとに、現状調査から本番移行・運用までを一気通貫で受託しています。 クラウド移行にはどれくらいの期間がかかりますか？ 規模と方式によって異なります。サーバー数台のシンプルなLift&Shift移行であれば数週間〜1か月程度、業務システムのリアーキテクチャを伴う移行では数か月〜が目安です。まず現状調査で対象範囲・依存関係・停止可能時間を整理し、リスクの低い対象から段階的に移行する計画をご提案します。 FREE CONSULTATION ## まずは無料で現状をお聞かせください。 「うちのは特殊で難しい」も大歓迎。 初回ヒアリングは無料です。現在のシステム構成・お困りごとをお聞きして、 移行の可否・概算費用・スケジュールを概算でお伝えします。 まずはお気軽にお問い合わせください。 [無料相談・お問い合わせ](https://technosphere.co.jp/contact) [電話で相談する](tel:0000000000) 初回ヒアリング・概算見積もりは完全無料です [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [技術コラム](https://technosphere.co.jp/blog/) [採用情報](https://technosphere.co.jp/recruit) [プライバシーポリシー](https://technosphere.co.jp/privacy) © 2023 Technosphere Inc. - [Facebook](https://www.facebook.com/technosphere.co.ltd) - [X（旧Twitter）](https://x.com/technosphere_co) - [Instagram](https://www.instagram.com/technosphere_co/) - [TikTok](https://www.tiktok.com/@technosphere.co) --- # テクノスフィアの自社AIプロダクト一覧｜SUGUMEN・TechnoVoice・SphereSync・TechnoChat > テクノスフィアの自社AIプロダクト4製品: SUGUMEN（AI面談）・TechnoVoice（AI音声代行）・SphereSync（リアルタイム自動翻訳）・TechnoChat（社内チャットボット）。料金・機能・導入相談受付中。 URL: https://technosphere.co.jp/products [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [採用情報](https://technosphere.co.jp/recruit) Technosphere AI & IT Solutions # 製品紹介 最先端の AI 技術と、確かなシステム開発力で ビジネスの課題を解決するプロダクトを提供します ** AI ソリューション ** インフラ監視 ** 多言語対応 ** NEW: GENBA Gate 製品を見る ** （図: TechnoVoice AI自動電話応対システム） AI Phone Response System ## TechnoVoice テクノボイス AIが御社のナレッジを学習し、電話応対を自動化。 24時間365日、人手不足を解消し、顧客満足度を向上させます。 ** 24時間365日対応 ** ナレッジ自動学習 ** 大幅なコスト削減 ### 主な活用シーン - **代表電話の一次対応・振り分け - **カスタマーサポートのFAQ自動応答 - **予約・受付の24時間自動対応 - **問い合わせ対応の効率化 [詳細を見る](https://technosphere.co.jp/technovoice) （図: TechnoChat AIチャットボットシステム） AI Chatbot System ## TechnoChat テクノチャット 膨大なナレッジを学習したAIが、24時間365日自動回答。 カスタマーサポートから社内ヘルプデスクまで幅広く活用できます。 ** ナレッジベース学習 ** 高速検索・回答 ** マルチチャネル対応 ### 主な活用シーン - **Webサイトでのカスタマーサポート - **Slack/Teamsでの社内ヘルプデスク - **製品マニュアルの自然言語検索 - **FAQの自動応答 [詳細を見る](https://technosphere.co.jp/technochat) （図: SphereSync リアルタイム自動翻訳システム） AI Translation System ## SphereSync スフィアシンク リアルタイム対話の壁を、最新AIで突破。 多言語コミュニケーションを超低遅延で実現し、グローバルビジネスを加速します。 ** 圧倒的な低遅延 ** 専門用語対応 ** ローカル動作で安心 ### 主な活用シーン - **ライブ配信の多言語同時翻訳 - **訪日外国人への店頭接客対応 - **国際ビジネス商談の専門用語翻訳 - **多言語カスタマーサポート [詳細を見る](https://technosphere.co.jp/spheresync) （図: TechnoAlive クラウドサーバー死活監視システム） Cloud Server Monitoring System ## TechnoAlive テクノアライブ クラウドサーバーの死活監視・パフォーマンス・セキュリティを一元管理。 障害を即座に検知し、メール・Slackへ通知します。 ** 死活監視 ** パフォーマンス監視 ** セキュリティ検知 ### 主な活用シーン - **ECサイト・Webサービスの稼働監視 - **企業基幹システムの安定稼働管理 - **不正アクセス・セキュリティリスク検知 - **マルチクラウド環境の一元管理 [詳細を見る](https://technosphere.co.jp/technoalive) 12,847 PV / 日 3,291 UU / 日 42 リアルタイム SphereScope Dashboard Web Analytics Platform ## SphereScope スフィアスコープ タグ1行を埋め込むだけで、あらゆるウェブサイトのアクセスをリアルタイムに解析・可視化。 Cookie不要・IPハッシュ化でプライバシーに配慮した次世代アクセス解析プラットフォームです。 ** タグ1行で即導入 ** リアルタイム解析 ** Cookie不要 ### 主な活用シーン - **自社サービス・ECサイトのアクセス解析 - **広告・SNS流入のUTM分析 - **複数サイトの一元ダッシュボード管理 - **カスタムイベントでのコンバージョン計測 [詳細を見る](https://technosphere.co.jp/spherescope-analytics) （図: SUGUMEN AI面談サービス — スグに面談。簡単・低コストで人材採用を加速。） ** SUGUMEN スグに面談。 簡単・低コストで人材採用を加速。 ** 最短数分で面談開始 ** クラウド版・即日導入 AI Interview System ## SUGUMEN スグメン 面接設定のリードタイムを極限まで短縮し、AIが一次面接を自動代行。 クラウド型のため初期コストゼロ・即日稼働で、採用ミスマッチを防ぎます。 ** 即時面談設定 ** 簡単クラウド導入 ** 低コスト運用 ### 主な活用シーン - **大量採用が必要な職種の一次スクリーニング - **夜間・休日など面接官不在時の応募者対応 - **遠隔地の候補者への初期アプローチ - **スキルのミスマッチを事前に防ぐ適性確認 [詳細を見る](https://technosphere.co.jp/sugumen) （図: GENBA IQ — 現場を理解する次世代AIソリューション） NEW LAUNCH GENBA IQ by Technosphere Inc. EDGE AI PLATFORM ## 現場を"理解"する 次世代AIソリューション Vision（映像）・Language（言語）・Speech（音声）＋センサーフュージョンにより、単なる「監視カメラの録画」を「現場を理解し判断する知能」に進化させます。 12ms 推論速度 16台 対応カメラ 2週間 PoC開始 製造・工場 交通・インフラ 建設・土木 小売・物流 医療・介護 [特設ページを見る](https://technosphere.co.jp/genba-iq) [ニュース](https://technosphere.co.jp/genba-iq-news) ** NEW （図: GENBA Gate 本体。LANポート2口と稼働ランプを備えた小型の金属筐体） Remote Maintenance Gateway ## GENBA Gate ゲンバゲート 離れた現場に小型ゲートウェイを1台置くだけ。現場と当社事務所がセキュアなVPNで常時つながり、 IPカメラやレコーダーの点検・設定変更を当社が遠隔で行います。装置・初期設定・保守込みのサービスです。 ** 着信ポート開放ゼロ ** モバイル回線で成立 ** 既存機器の設定変更なし ### 主な活用シーン - **遠方の施設に設置したカメラ・レコーダーの保守 - **固定回線を引けない現場の遠隔監視 - **障害発生時の駆けつけ前の切り分け - **複数拠点にまたがる設備の一括保守 [詳細を見る](https://technosphere.co.jp/genba-gate) ## 柔軟な動作環境 クラウド版とエッジ版から、お客様の環境に最適な構成を選択できます ** ### クラウド版 スケーラブルな運用で大規模利用に対応。 初期コストを抑えて即座に導入可能。 - **高い拡張性 - **メンテナンス不要 - **常に最新機能 ** ### エッジ版 Raspberry Pi 5でローカル動作。 機密性の高い商談やオフライン環境でも安心。 - **データが外部流出しない - **ネットワーク不要 - **超低遅延 ## 導入のご相談・お問い合わせ デモのご依頼・お見積り・ご質問など、お気軽にお問い合わせください。 お客様のビジネス課題に最適なソリューションをご提案いたします。 [お問い合わせ](https://technosphere.co.jp/contact) [06-4805-8282](tel:06-4805-8282) [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [技術コラム](https://technosphere.co.jp/blog/) [採用情報](https://technosphere.co.jp/recruit) [プライバシーポリシー](https://technosphere.co.jp/privacy) © 2023 Technosphere Inc. - [Facebook](https://www.facebook.com/technosphere.co.ltd) - [X（旧Twitter）](https://x.com/technosphere_co) - [Instagram](https://www.instagram.com/technosphere_co/) - [TikTok](https://www.tiktok.com/@technosphere.co) --- # GENBA IQ — 現場を"理解"する次世代AIソリューション | 株式会社テクノスフィア > GENBA IQは、映像・音声・センサーを統合するエッジAIプラットフォームです。製造・交通・建設・物流・小売・医療のあらゆる現場をAIが理解し、リアルタイムで判断します。最短2週間でPoC開始。 URL: https://technosphere.co.jp/genba-iq Vision-Language-Speech + Sensor Fusion # 現場を"理解"する 次世代AIソリューション 人の目で見て判断できるすべてを、AIで。 製造・交通・建設・物流・小売 — あらゆる現場に対応。 [デモを予約する](https://technosphere.co.jp/contact?category=genba_iq) [資料ダウンロード](https://technosphere.co.jp/assets/download/genba-iq-pamphlet.pdf) 詳しく見る 12ms推論速度 16台対応カメラ 2週間PoC開始まで （図: GENBA IQ スマート工場） **12ms**推論速度 SCROLL ### 最新 NEWS [2026.04.24 プレスリリース GENBA IQ 発表 — 次世代エッジAIプラットフォームで現場DXを加速](https://technosphere.co.jp/genba-iq-news#launch) [2026.04.24 PoC募集中 物流倉庫向けPoC参加企業を募集中 — フォークリフト動線最適化を2週間で検証](https://technosphere.co.jp/genba-iq-news#poc) [2026.04.24 PoC募集中 製造ライン向けPoC参加企業を募集中 — 外観検査・品質管理の自動化を検証](https://technosphere.co.jp/genba-iq-news#award) [すべてのニュースを見る](https://technosphere.co.jp/genba-iq-news) THE CHALLENGE ## 人の目に頼る"判定"の限界 ベテランの勘と経験に依存した現場判断。それは今、深刻な課題をもたらしています。 ** 見落とし・ヒューマンエラー 0% 目視検査における一般的な見逃し率。疲労・集中力低下による見落としは避けられません。 ** 属人化・スキル差 0% ベテランと新人では判定精度に大きな差が生じます。技術継承が現場の最大課題です。 ** 24時間対応の限界 0倍 夜間・休日の監視コストは通常人件費の3倍以上。24時間監視は現実的ではありません。 ** データ化できない 0% 映像は「録画」のまま放置。現場の知見が蓄積されず、改善サイクルが回りません。 ※ 数値は製造業・建設業等における一般的な業界課題の目安です。 WHAT IS GENBA IQ ## 現場を"理解"する AIプラットフォーム GENBA IQは、Vision（映像）・Language（言語）・Speech（音声）とセンサーデータを統合的に処理するエッジAIソリューションです。 既存のカメラやセンサーに"理解力"を与え、「録画装置」を「判断する装置」へ進化させます。クラウド不要のエッジ処理で、データは現場から外に出ません。 ** カメラ映像解析 ** 音声パターン分析 ** VLM推論 ** IoT連携 **センサーフュージョン映像+音声+センサーの統合分析 **リアルタイム推論12ms以下のエッジ処理 **既存設備活用新規カメラ投資不要 **データ主権クラウド不要、データが外に出ない （図: GENBA IQ アーキテクチャ） INDUSTRIES ## あらゆる"現場"に適応する 人の目で見て判断できるすべてのシーンに、GENBA IQは対応します。 （図: 製造・工場） **製造・工場外観検査・異常検知・ライン監視 （図: 交通・インフラ） **交通・インフラ交通量計測・信号制御・道路監視 （図: 建設・土木） **建設・土木安全装備検知・危険区域侵入検知 （図: 小売・サービス） **小売・サービス接客分析・カスハラ検知・混雑管理 （図: 物流・倉庫） **物流・倉庫動線最適化・積載判定・作業計測 （図: 医療・介護） **医療・介護転倒検知・見守り・行動パターン分析 （図: 製造ライン外観検査） QUALITY INSPECTION / 品質検査 ## 製造ラインの外観検査を AIが24時間実行 - 目視検査の見逃し率 5〜15% - 熟練検査員の高齢化・後継者不足 - 検査データが蓄積・活用されない - 表面の傷・打痕（0.1mm精度） - 色味・光沢の異常 - 部品の欠品・位置ズレ - 印字・ラベルの読み取りエラー 0推論速度 ms以下 0同時カメラ 最大台数 0不良流出 %削減 * * 効果数値はPoC検証における想定目標値です。実際の効果は導入環境により異なります。 （図: 交通インフラ監視） INFRASTRUCTURE / 交通インフラ ## 交通量をAIが読み、 信号を最適制御 - 固定タイマー式信号による無駄な待ち時間 - 事故・渋滞の検知が人間の監視に依存 - ラッシュ時と閑散時で同じ制御ロジック - 車両カウント（方向別・車種別） - 歩行者密度・横断待ち人数 - 渋滞長の計測 - 事故・異常停車の検知 - 逆走・信号無視の検知 0待ち時間 %短縮 * 0渋滞長 %削減 * 0事故検知 秒で通報 * * 効果数値はシミュレーションに基づく想定値です。実際の効果は導入環境により異なります。 （図: 建設現場安全管理） SAFETY / 安全管理 ## 建設現場の"見えない危険"を AIが即座に検知 - ヘルメット・安全帯の未着用 - 危険区域への侵入 - 重機と人の接近（5m以内で警告） - 転倒・転落の検知 - 熱中症リスク（姿勢変化+環境センサー） ① 現場監督スマホへ即時アラート（**0.5秒以内**） ② 重機オペレーターへ音声警告を自動送信 ③ イベント映像の自動保存（前後30秒） ④ 日次安全レポートの自動生成 0労災事故 %削減 * 0安全パトロール工数 %削減 * * 効果数値は業界事例に基づく想定目標値です。実際の効果は現場環境により異なります。 （図: 小売店舗接客最適化） SALES / 接客最適化 ## トップ販売員の"勝ちパターン"を AIが解析・全店展開 - 動線効率: **92%** を数値化 - 声かけタイミング: 商品接触後3秒、1.2mの距離を維持 - 説明順序: 商品説明→価格提示→特徴紹介を分析 - クロージング前兆を動作検知で把握 ** カスハラ撃退 AIボディーガード機能 - 暴言・高圧的トーンの音声パターン検知 - 急接近・威圧ジェスチャーの動作検知 - 長時間拘束（15分以上）の検知 即時アラート 録画自動開始 対応履歴保全 ** 行動パターンから自動マニュアル生成 ** 接客ショート動画化 ** 5分マイクロラーニング配信 ** 新人OJT期間の短縮 0成約率 +% * 0教育時間 -% * 0接客品質 +% * * 効果数値は想定目標値です。実際の効果は導入環境により異なります。 （図: 物流倉庫効率化） EFFICIENCY / 物流効率化 ## フォークリフト動線と積載状況を リアルタイム最適化 - フォークリフトの無駄な走行（空走率30%以上） - 積載量の目視判断による過積載・過少積載 - ヒヤリハット事故の記録が属人的 - 全フォークリフトの動線トラッキング - 積載状態の自動判定（空/適正/過積載） - 人と車両の接近予測・即時警告 - 作業効率KPIの自動集計 0空走率 %削減 * 0積載効率 %向上 * 0ヒヤリハット %削減 * * 効果数値は想定目標値です。実際の効果は導入環境により異なります。 （図: 医療・介護施設見守りAI） CAREGIVING / 介護・見守り ## 介護スタッフの目を AIが24時間サポート - 夜間の転倒・転落事故の発見が遅れる - 慢性的な人手不足で見守りが不十分 - 入居者の体調変化を早期に把握できない - ✓転倒・転落の瞬間を即時検知・通報 - ✓異常姿勢・長時間無動作の自動アラート - ✓夜間徘徊・離床の早期検知 - ✓行動パターン変化による体調不良の予兆検知 - ✓プライバシー保護（骨格スケルトン処理・顔認証なし） 0転倒検知 秒以内 * 0夜間巡回工数 %削減 * 0インシデント早期発見率 % * * 効果数値は想定目標値です。実際の効果は導入環境により異なります。 DEVICE-FREE STRATEGY ## ThorからRaspberry Piまで — 1つの基盤であらゆるスケールに対応 予算と規模に応じて最適なデバイスを選択。段階的なスケールアップを実現します。 （図: エッジAIデバイスラインナップ） HIGH-END EDGE AI Jetson Thor 推論速度12ms 対応カメラ最大16台 GPU利用率95% 大規模工場・交通管制センター MULTI-CAMERA Orin NX 推論速度25ms 対応カメラ最大8台 GPU利用率87% 中規模施設・建設現場 COST-OPTIMIZED Raspberry Pi 5 推論速度80ms 対応カメラ1〜2台 コスト削減45% 小規模店舗・PoC検証 すべて同一のGENBA IQ管理基盤で動作。予算と規模に応じて最適なデバイスを選択し、 段階的にスケールアップが可能です。 GETTING STARTED ## 最短2週間でPoC開始 小さく始めて、効果を見て、すぐ広げる ** Step 1 / 0–2日 ヒアリング 課題ヒアリング・KPI設定・設置環境確認 ** Step 2 / 3–5日 データ準備 映像・センサーデータ確認・匿名化・初期設定 ** Step 3 / 6–10日 実装 エッジAI実装・通知フロー構築・現場テスト ** Step 4 / 11–14日 評価 効果測定・レポート・次フェーズ計画 ** 効果測定レポート ** 本導入見積 ** 拡張提案書 ## 現場の"見えない課題"、 AIで可視化しませんか？ まずは2週間のPoCで効果を体感。既存カメラを活かし、 低リスク・短期間で現場検証できます。 [無料デモを予約する](https://technosphere.co.jp/contact?category=genba_iq) [資料ダウンロード](https://technosphere.co.jp/assets/download/genba-iq-pamphlet.pdf) [資料をダウンロード](https://technosphere.co.jp/contact?category=genba_iq) ** 24時間以内にご連絡 | ** 準備完了 [プライバシーポリシー](https://technosphere.co.jp/privacy)に同意の上、お問い合わせください。 [GI GENBA IQ](https://technosphere.co.jp/genba-iq) [株式会社テクノスフィア トップページ](https://technosphere.co.jp/) [製品一覧](https://technosphere.co.jp/products) [AIソリューション](https://technosphere.co.jp/ai-solution) [組込み開発](https://technosphere.co.jp/embedded) [技術コラム](https://technosphere.co.jp/blog/) [ニュース](https://technosphere.co.jp/genba-iq-news) [お問い合わせ](https://technosphere.co.jp/contact) [プライバシーポリシー](https://technosphere.co.jp/privacy) 株式会社テクノスフィア｜〒532-0011 大阪市淀川区西中島7丁目7-3 エフベースミュゼオ201｜[お問い合わせ](https://technosphere.co.jp/contact) © 2026 株式会社テクノスフィア — GENBA IQ is a product of Technosphere Inc., Osaka, Japan 既存カメラを活かし2週間でPoC。 [デモを予約する](https://technosphere.co.jp/contact?category=genba_iq) --- # AI面接ツール「SUGUMEN（スグメン）」｜24時間365日対応の面接自動化クラウド｜株式会社テクノスフィア > 採用のリードタイムとコストを極限まで削減するAI面接システム「SUGUMEN（スグメン）」。応募から最短3分でAIが一次面接を24時間365日自動代行。初期費用ゼロ、既存ATS連携対応。面接日程調整の課題をクラウドで即解決します。 URL: https://technosphere.co.jp/sugumen [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [採用情報](https://technosphere.co.jp/recruit) ** AI Interview System （図: SUGUMEN AI面談サービス ロゴ） スグメン # AI面談システム「SUGUMEN（スグメン）」で 採用を加速 面接設定のリードタイムを極限まで短縮し、 AIが一次面接を自動代行。クラウド上で即稼働するため、 導入翌日から採用ワークフローを変革します。 デモを申し込む 詳細を見る [資料ダウンロード](https://technosphere.co.jp/assets/download/sugumen-pamphlet.pdf) 最短数分** 応募→AI面談開始 初期費用ゼロ** クラウド型・即日導入 24時間365日** AI が面接を自動代行 採用単価を削減** 工数・コストを大幅圧縮 スクロールして詳細を見る ** ## 採用担当者のこんなお悩みをAI面接が解決します ** 面接官の日程調整に **時間がかかりすぎる 夜間・休日の応募者に **すぐ対応できない 遠隔地の候補者への **初期アプローチが困難 採用後のスキル **ミスマッチが多い** ## SUGUMENが解決します （図: スーツ姿の日本人男性がオンラインでAI面談を受けているシーン） ** AI面談 実施中 ** 応募から**3分**でスタート **SUGUMEN**は、既存の採用フローにクラウド経由で組み込むだけで、 AIが応募者へ即座にアプローチし、一次面接を自動代行するサービスです。 面接官の工数を大幅に削減しながら、採用精度を向上させます。 - **既存の採用管理システム（ATS）と連携可能 - **応募から最短数分でAI面談をスタート - **クラウド版のため、初期投資ゼロで即日稼働 - **面談結果をスコアリングして採用判断を支援 ## SUGUMEN（スグメン）が選ばれる3つの特徴 （図: 即時面談設定） ### 応募から最短数分でAI面談設定 候補者の応募直後から最短数分でAI面談を開始可能。応募者の熱量が高いうちにファーストコンタクトを実現し、機会損失をゼロにします。 （図: 簡単クラウド導入） ### 初期費用ゼロのクラウド型AI面接 既存の採用フローへの組み込みはクラウド経由で完結。複雑なサーバー構築やシステム改修は不要で、スモールスタートから大規模採用まで柔軟にスケールします。 （図: 低コスト運用） ### 低コスト運用 従来の一次面接にかかる面接官の工数を大幅に削減。採用単価を抑制しながら、より多くの候補者に均質なスクリーニングを実施できます。 ## AI面接ツールの主な活用シーン （図: 採用担当者2名がオフィスで面談評価データを確認し、採用判断をしているシーン） ** 採用担当者がリアルタイムでスコアを確認・比較。最適な人材を迅速に選定できます。 ** ### 大量採用の一次スクリーニング アルバイト・派遣・新卒など大量採用が必要な職種において、AIが均質な一次スクリーニングを並列処理。採用担当者はスコア上位の候補者に集中できます。 ** ### 夜間・休日の応募者対応 面接官が不在の深夜・早朝・休日でも、AIが24時間365日対応。翌営業日を待たずに候補者との接点を確保し、内定辞退リスクを低減します。 ** ### 遠隔地候補者への初期アプローチ クラウド型のため、全国・海外どこにいる候補者にも場所を選ばずAI面談を実施。地方採用やリモートポジションの初期選考に最適です。 ** ### スキル・適性の事前確認 求める技術・資格・コンピテンシーに基づいた設問で、対面面接前にミスマッチを排除。採用精度の向上と面接工数の最小化を同時に実現します。 ## 導入の流れ 01 ** ### お申し込み フォームよりデモまたはお申し込みください。クラウド版のためすぐにアカウントを発行します。 ** 02 ** ### 設問・評価軸の設定 採用職種に合わせた面談設問と評価基準をご設定ください。テンプレートから選択するだけで即完了します。 ** 03 ** ### 採用フローへの連携 求人媒体・ATSとのURL連携またはAPI接続で、応募者への自動案内が開始。既存フローを変えずに組み込めます。 ** 04 ** ### AI面談・スコアリング開始 応募者が自分のタイミングでAI面談を受験。結果はリアルタイムにスコアリングされ、採用担当者へ通知されます。 ** スマートフォン対応 ## 場所を選ばず、 自分のペースで面談。 応募者はスマートフォンやPCから、 自分の都合のよい時間にAI面談を受験できます。 深夜・早朝・休日問わず対応。 就活中の候補者の離脱リスクを大幅に低減します。 - スマートフォン・PC・タブレット**すべてに対応 - **アプリインストール不要、**ブラウザのみ**で完結 - **面談所要時間は**最短10〜15分** - **回答はテキスト・音声どちらにも対応 （図: 日本人女性が自宅のソファでスマートフォンを使ってAI面談を受けているシーン） ** TLS暗号化で安全 ** クラウド版 ## SUGUMENはフルクラウド型。 初期コストゼロ、即日導入。 サーバー構築・ソフトウェアインストールは一切不要。 ブラウザからアカウントを作成するだけで、 今日から採用フローを変革できます。 スケーラブルなクラウドインフラが大規模採用にも対応し、 常に最新のAI機能を追加費用なしでご利用いただけます。 - 高い拡張性：**採用規模に応じてリアルタイムにスケール - メンテナンス不要：**AIモデルのアップデートは自動適用 - 常に最新機能：**新機能は即時リリース、追加費用なし - セキュアな通信：**TLS暗号化＋面談データの厳重管理 ** SUGUMEN Cloud ** 採用担当者 ** 応募者 ** ATS連携 ** スコア分析 ## よくあるご質問 ** SUGUMENとはどんなサービスですか？ ** SUGUMEN（スグメン）は、AIが一次面接を24時間365日自動代行するクラウド型の**面接自動化**システムです。応募から最短3分でAI面談を開始でき、面接官の日程調整や工数を大幅に削減します。初期費用ゼロで即日導入が可能です。 ** 導入にどれくらい時間がかかりますか？ ** クラウド型サービスのため、**最短即日で導入可能**です。アカウント作成後、面談設問と評価基準を設定するだけで利用を開始できます。テンプレートを使えば設定も数分で完了します。 ** 既存の採用管理システム（ATS）と連携できますか？ ** はい、既存のATSとURL連携またはAPI接続で連携可能です。現在の**採用フローを変えることなく**、SUGUMENを組み込むことができます。 ** 初期費用はかかりますか？ ** **初期費用はゼロ**です。クラウド型のため、サーバー構築やソフトウェア購入は不要です。月額利用料のみでご利用いただけます。 ** 応募者はどのようにAI面談を受けますか？ ** 応募者はスマートフォン・PC・タブレットの**ブラウザからAI面談**を受けられます。アプリのインストールは不要で、所要時間は最短10〜15分です。テキストと音声の両方に対応しています。 ## SUGUMENの導入をご検討ください デモのご依頼・お見積り・ご質問など、 お気軽にお問い合わせください。 [お問い合わせ](https://technosphere.co.jp/contact) [06-4805-8282](tel:06-4805-8282) [パンフレット（PDF）](https://technosphere.co.jp/assets/download/sugumen-pamphlet.pdf) 関連コラム - [AI面接ツール比較【2026年版】｜費用相場と選び方](https://technosphere.co.jp/blog/ai-interview-tools-comparison) - [SUGUMEN導入事例（小売業）](https://technosphere.co.jp/blog/sugumen-case-study-retail) [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [技術コラム](https://technosphere.co.jp/blog/) [採用情報](https://technosphere.co.jp/recruit) [プライバシーポリシー](https://technosphere.co.jp/privacy) © 2023 Technosphere Inc. - [Facebook](https://www.facebook.com/technosphere.co.ltd) - [X（旧Twitter）](https://x.com/technosphere_co) - [Instagram](https://www.instagram.com/technosphere_co/) - [TikTok](https://www.tiktok.com/@technosphere.co) --- # TechnoChat - AIチャットボットシステム｜株式会社テクノスフィア > TechnoChat（テクノチャット）は、膨大なナレッジ・ドキュメントを学習し、自動回答するAIチャットボットシステムです。24時間対応、高速検索、マルチチャネル対応でビジネスを支援します。 URL: https://technosphere.co.jp/technochat [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [採用情報](https://technosphere.co.jp/recruit) AI Chatbot System # TechnoChat テクノチャット 膨大なナレッジを学習したAIが、 24時間365日、的確な回答を提供します お問い合わせ [資料ダウンロード](https://technosphere.co.jp/assets/download/technochat-pamphlet.pdf) （図: TechnoChat AIチャットボット） ## カスタマーサポートのこんな課題、ありませんか？ ** 問い合わせ対応に **時間がかかりすぎる 営業時間外の **問い合わせに対応できない 社内マニュアルが **探しづらい サポート担当者の **負担が大きい** ## TechnoChatが解決します （図: TechnoChat サービス概念図） **TechnoChat**は、御社の膨大なナレッジ・ドキュメント・FAQを学習し、顧客や社員からの質問に自動で回答するAIチャットボットシステムです。 - **既存ドキュメントを学習するだけで導入可能 - **高速検索で瞬時に的確な回答を提供 - **24時間365日、休みなく稼働 - **複数チャネル対応（Web、Slack、Teams等） ## TechnoChatの特徴 ** ### ナレッジベース学習 FAQ、マニュアル、社内Wiki、過去の対応履歴など、あらゆるドキュメントを学習し、自動回答します。 ** ### 高速検索・回答 膨大なドキュメントから関連情報を瞬時に検索し、的確な回答を数秒で提供します。 ** ### マルチチャネル対応 Webサイト、Slack、Microsoft Teams、LINE など、複数のチャネルに統一されたボットを展開できます。 ** ### 継続的な学習・改善 ユーザーの質問と回答のフィードバックを元に、AIが継続的に学習し、精度を向上させます。 ## 活用シーン （図: カスタマーサポート） ** Use Case 01 ### カスタマーサポート Webサイトに埋め込んだチャットボットが、商品の使い方、配送状況、返品方法など、よくある質問に24時間自動で回答します。 - **営業時間外も顧客対応可能 - **よくある質問の自動応答でサポート負担軽減 - **複雑な質問は有人サポートへエスカレーション （図: 社内ヘルプデスク） ** Use Case 02 ### 社内ヘルプデスク Slack、Microsoft Teamsに統合したボットが、社内規定、経費精算方法、ITツールの使い方など、社員からの問い合わせに即座に回答します。 - **社内マニュアル・規定の即座検索 - **情シス・人事部門への問い合わせ削減 - **新入社員のオンボーディング支援 （図: 製品マニュアル検索） ** Use Case 03 ### 製品マニュアル検索 複雑な製品マニュアルを学習し、技術者やエンドユーザーが必要な情報を自然言語で検索・取得できます。 - **PDF、動画、画像など多様な形式に対応 - **関連情報を複数ソースから統合して回答 - **技術用語・専門用語の正確な理解 ## マルチチャネル対応 一つのナレッジベースを、複数のチャネルで活用できます （図: マルチチャネル対応） ** Webサイト埋め込み ** Slack ** Microsoft Teams ** LINE ** スマートフォンアプリ ** メール ## TechnoChat導入のご相談 デモのご依頼・お見積り・ご質問など、 お気軽にお問い合わせください。 [お問い合わせ](https://technosphere.co.jp/contact) [資料ダウンロード](https://technosphere.co.jp/assets/download/technochat-pamphlet.pdf) [06-4805-8282](tel:06-4805-8282) [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [技術コラム](https://technosphere.co.jp/blog/) [採用情報](https://technosphere.co.jp/recruit) [プライバシーポリシー](https://technosphere.co.jp/privacy) © 2023 Technosphere Inc. - [Facebook](https://www.facebook.com/technosphere.co.ltd) - [X（旧Twitter）](https://x.com/technosphere_co) - [Instagram](https://www.instagram.com/technosphere_co/) - [TikTok](https://www.tiktok.com/@technosphere.co) --- # 組込み制御・マイコン開発 実績紹介｜カメラ・産業・IoT・ポーティング｜株式会社テクノスフィア > テクノスフィアの組込み開発実績を紹介。AndroidTVカメラミドル・デジタルカメラAF制御・重機CAN通信・振動データロガー・Linuxカメラドライバ・8Kエンコード・マイコンポーティングなど豊富な事例を掲載。 URL: https://technosphere.co.jp/embedded-achievements [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [採用情報](https://technosphere.co.jp/recruit) （図: 組込み開発実績） ** Case Studies & Achievements # 組込み開発 実績紹介 カメラ・産業IoT・ポーティングなど多彩な案件に対応 20年以上の組込み開発で積み上げた実績を分野別にご紹介します。 「うちの案件、対応できる？」と思ったらお気軽にご相談ください。 50 件+ 開発プロジェクト 3 分野 カメラ・産業・ポーティング 20 年+ 組込み開発実績 ## CASE STUDIES 開発実績 業種・用途ごとに代表的な案件をご紹介します。掲載以外にも多数の実績がございます。詳細はお問い合わせください。 ** ## カメラ・映像系 高度なカメラ制御と映像処理のノウハウを活かした実績 （図: AndroidTVカメラミドル開発） 2023年4月 ### AndroidTV カメラミドル開発 HDMIドングル用WiFiカメラの組込み開発。AndroidTVプラットフォーム上でのカメラミドルウェア実装。リアルタイム映像配信と低遅延処理を実現。 AndroidC/C++WiFiHDMI （図: デジタルカメラ オートフォーカス開発） 2017年7月 ### デジタルカメラ オートフォーカス制御開発 ミラーレス一眼のAF制御システム開発。高速・高精度なAF制御アルゴリズム実装でプロ仕様の撮影品質を実現。 C言語DSP画像処理AF制御 （図: Linuxカメラドライバ開発） 試作機開発 ### Linux カメラドライバ開発 Aptina・OmniVision・Sony IMX 各種イメージセンサー向け V4L2 準拠 Linux ドライバの開発・ポーティング。 Linux KernelV4L2MIPI CSI （図: 8Kエンコードシステム） 試作機開発 ### 8K エンコードシステム 次世代8K映像リアルタイムエンコードシステムの試作開発。FPGA とハードウェアエンコーダ制御で 4K 比4倍の解像度処理を実現。 HEVC/H.265FPGA高速I/O ** ## 産業・インフラ・IoT 系 産業機器の高信頼性制御・センサー活用・IoT連携のノウハウ （図: ホームセキュリティー機器開発） 大手電機メーカー様 ### ホームセキュリティー機器開発 大手電機メーカー向けホームセキュリティー機器の組込みソフトウェア開発。センサー制御とネットワーク連携で 24 時間監視システムを構築。 RTOSセンサー制御IoT （図: 輸送振動データロガー） 2018年4月 ### 輸送振動データロガー 輸送時の振動データを高精度加速度センサーで記録・SD カードに保存。I2C / SPI 通信と省電力設計で長期連続稼働を実現。 加速度センサーSPI Flash省電力設計 （図: 重機バックホウ自動制御） 2019年10月 ### 重機バックホウ自動制御 建設重機の自動制御システム開発。CAN 通信・油圧制御・センサーフィードバックで精密な自動運転を実現し、作業効率と安全性を向上。 CAN通信油圧制御安全設計 ** ## マイコン変更・ポーティング 部品調達難・コストダウンに伴うマイコン変更を迅速に対応 （図: マイコンFWポーティング） 複数案件対応 ### マイコン変更に伴う FW ポーティング NXP i.MX7→i.MX8、STM32 シリーズ間移行など各種ファームウェアの移植。既存コード資産を最大限活用した効率的な移行を実現。 NXP i.MXSTM32YoctoBSP （図: BSPカスタマイズ対応） 各種対応 ### 各種 BSP カスタマイズ対応 Linux BSP・デバイスツリー・ブートローダー（U-Boot）設定などハードウェア依存部分を確実に移行・カスタマイズ。 Linux BSPU-BootDevice Tree ## 対応できる案件か、まずご相談ください 掲載以外の案件も多数対応しています。 「うちのは特殊かも…」と思った案件ほどお気軽にどうぞ。 [無料相談・お問い合わせ](https://technosphere.co.jp/contact) [サービス案内に戻る](https://technosphere.co.jp/embedded) [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [技術コラム](https://technosphere.co.jp/blog/) [採用情報](https://technosphere.co.jp/recruit) [プライバシーポリシー](https://technosphere.co.jp/privacy) © 2023 Technosphere Inc. - [Facebook](https://www.facebook.com/technosphere.co.ltd) - [X（旧Twitter）](https://x.com/technosphere_co) - [Instagram](https://www.instagram.com/technosphere_co/) - [TikTok](https://www.tiktok.com/@technosphere.co) --- # Web診療予約システム｜株式会社テクノスフィア > 医療機関向けWeb診療予約システム。スマホ・PC・タブレットなどブラウザがあればどこでも予約可能。たちばな台病院・クリニック様で稼働中。 URL: https://technosphere.co.jp/medical-reservation [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [採用情報](https://technosphere.co.jp/recruit) ** Medical Solution # Web診療予約システム 患者様の利便性を劇的に向上 スマホ・PC・タブレット ブラウザがあればどこでも予約可能 2 医療機関で稼働中 24/7 いつでも予約可能 0 ログイン手間 （図: 予約アプリ画面） ## PROBLEM 従来の予約システムの課題 ** ### 毎回のログインが面倒 ID・パスワードを覚えていない患者様も多く、予約のたびにストレスが発生 ** ### メールアドレス入力の手間 リマインドメールのために毎回アドレスを入力する必要がある ** ### 緊急連絡手段がない 休診や予定変更を患者様に伝える手段が電話のみで非効率 ## SOLUTION Webアプリで全て解決 **ブラウザさえあれば利用可能**なWebアプリだから、 インストール不要で患者様と医療機関双方の課題を解決します。 ## FEATURES 3つの主要機能 01 ** ### ログイン認証不要 初回登録後は自動ログイン。ID・パスワードを覚える必要がなく、ブックマークからワンタップで予約画面へ。 Before 毎回ID/PW入力 ** After タップで即予約 02 ** ### リマインド自動配信 登録済みのメールアドレスへ予約日前日に自動リマインド。患者様の予約忘れを防止します。 Before 電話で確認 ** After 自動メール通知 03 ** ### マルチデバイス対応 スマホ、タブレット、PCなどブラウザさえあればどこからでもアクセス可能。アプリのインストールは一切不要です。 ** スマートフォン ** タブレット ** パソコン ## ARCHITECTURE システム構成 #### 患者様 ** スマートフォン ** タブレット ** PC HTTPS（Webブラウザ） #### サーバー ** 予約API ** 通知サーバー ** データベース 内部連携 #### 医療機関 ** 管理画面 ** 予約管理 ## TECH STACK 使用技術 #### フロントエンド HTML5/CSS3 JavaScript レスポンシブ対応 #### バックエンド PHP MySQL REST API #### 通知機能 メール通知 SMS連携 #### インフラ クラウドサーバー SSL/TLS ## CASE STUDIES 導入実績 ** ### たちばな台病院 ** 神奈川県横浜市 内科・外科・整形外科など複数診療科を持つ総合病院。多くの患者様にご利用いただいています。 ** 稼働中 ** ### たちばな台クリニック ** 神奈川県横浜市 地域に根ざした診療所として、かかりつけ医として多くの患者様の健康を支えています。 ** 稼働中 ## BENEFITS 導入効果 #### 患者様のメリット - ** ログイン不要でストレスフリー - ** 予約忘れ防止（自動リマインド） - ** スマホ・PC・タブレットどれでも使える - ** 24時間いつでも予約可能 #### 医療機関のメリット - ** 電話対応の大幅削減 - ** 無断キャンセルの減少 - ** 緊急連絡の効率化 - ** 患者満足度の向上 ## 診療予約システムの導入をご検討ですか？ 医療機関様の規模やニーズに合わせた 最適なソリューションをご提案いたします。 [お問い合わせ](https://technosphere.co.jp/contact) [実績一覧に戻る](https://technosphere.co.jp/./#achievements) [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [技術コラム](https://technosphere.co.jp/blog/) [採用情報](https://technosphere.co.jp/recruit) [プライバシーポリシー](https://technosphere.co.jp/privacy) © 2023 Technosphere Inc. - [Facebook](https://www.facebook.com/technosphere.co.ltd) - [X（旧Twitter）](https://x.com/technosphere_co) - [Instagram](https://www.instagram.com/technosphere_co/) - [TikTok](https://www.tiktok.com/@technosphere.co) --- # 大阪のスマホアプリ開発会社｜iOS・Android・Flutter の受託開発｜株式会社テクノスフィア > 大阪のスマホアプリ開発会社です。iOS/Androidネイティブ、Flutter・React Native、PWAに対応し、モバイルアプリ開発を設計から運用まで受託します。組込み・AI・Webを横断する技術力で、現場で本当に使われるアプリを作ります。新大阪から対面でもオンラインでも対応。 URL: https://technosphere.co.jp/app-development [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [採用情報](https://technosphere.co.jp/recruit) Smartphone App Development # スマホアプリ、 作りませんか？ 紙とExcelで回している現場の作業も、お客様との接点も、スマホアプリにすると景色が変わります。組込み・AI・Webを横断してきた大阪の開発会社が、「現場で本当に使われるアプリ」を設計から運用まで一貫してお作りします。 [まずは無料で相談する](https://technosphere.co.jp/contact?category=web) アプリ化のメリットを見る iOS / Android ネイティブ・Flutter・React Native・PWA に対応。大阪市淀川区（新大阪）から、対面でもオンラインでも。 （図: スマートフォンアプリ開発） **iOS / Android**両OS対応・ストア申請代行まで **2〜4か月**小規模な業務アプリの開発期間 **企画から相談可**要件整理からご一緒します **設計〜保守**公開後の運用まで一貫対応 Why App? ## Webサイトではできないことが、 アプリならできます。 「今どきホームページがあれば十分では？」とよく聞かれます。実際には、次の5つはアプリでなければ実現が難しい領域です。 ** ### こちらから届けられる プッシュ通知で、開いてもらうのを待たずに情報を届けられます。再来店の促進、緊急連絡、作業指示の伝達など、メールより圧倒的に届きます。 ** ### 電波がなくても動く 倉庫・工場・地下・山間部など、通信が不安定な場所でも入力を続けられます。オンラインに戻ったときに自動で同期する設計が可能です。 ** ### カメラ・GPS・センサーを使える 写真での記録、バーコード・QRの読み取り、位置情報の記録、Bluetooth機器との接続。現場作業の入力を「撮る・かざす」だけにできます。 ** ### ホーム画面に常駐する URLを探してブラウザを開く手間がなくなります。毎日使う業務ツールほど、この一手間の差が定着率を左右します。 ** ### 操作が速く、指に馴染む 画面遷移が滑らかで、スワイプや長押しなどスマホ本来の操作が使えます。1日に何十回も触るツールでは、この快適さが生産性に直結します。 ** ### 端末に閉じた運用ができる 社内配布（MDM経由）でストアに公開せず使う、端末内で処理して外部にデータを出さない、といった設計も可能です。 Approach ## どの作り方が合っているか、 最初に見極めます。 アプリの作り方は1つではありません。目的と予算に対して過剰にならない選択をご提案します。 | 方式 | 特徴 | 向いているケース | 開発規模の傾向 | | **ネイティブ** Swift / Kotlin | 各OSの性能を最大限に使える。動作が最も滑らか | カメラ・センサーを高度に使う、動作速度が重要 | 大きめ（OSごとに実装） | | **クロスプラットフォーム** Flutter / React Native | 1つのコードでiOS/Android両対応。開発費を圧縮できる | 両OS対応が必須で、機能は標準的 | 中程度（両OSを1コードで） | | **PWA** Web技術 | ストア不要・URLで配布。ホーム画面に追加可能 | 社内利用、短期間・低予算で始めたい | 小さめ（短期間で開始） | | **ハイブリッド** Web＋ネイティブ | 既存Webシステムを活かしつつ通知やカメラを追加 | すでにWebシステムがあり、機能だけ足したい | 中程度（既存資産を活用） | ※ 費用はご要件によって大きく異なります。必要な機能、両OS対応の要否、サーバー側の開発範囲、既存システム連携の有無を伺ったうえで、作業範囲を明記したお見積りをご提示します。 Use Case ## こんなアプリを作っています （図: 現場での点検・記録アプリ） ### 現場の点検・記録アプリ 紙の点検表をスマホに。写真とチェックだけで報告書が完成し、事務所への持ち帰り作業がなくなります。オフライン入力・後から同期に対応。 （図: 顧客向けアプリ） ### 顧客向けの会員・予約アプリ 予約、会員証、ポイント、お知らせ配信をひとつに。プッシュ通知で再来店を促し、紙のカードやメール配信を置き換えます。 （図: 機器連携アプリ） ### 機器・IoT連携アプリ Bluetooth機器やセンサーとつなぎ、測定値の記録や機器の設定をスマホから。組込み開発も自社で行うため、機器側とまとめて対応できます。 Engineering Blog ## 実装の中身、公開しています。 「本当に作れるのか」は、営業資料より書いたものを読んでいただくのが早いと考えています。スマホ・エッジ・AIまわりの実装記事の一部です。 [DEVICE / BLE BLEでスマホと機器をつなぐアプリ開発 GATT設計、再接続、バックグラウンドの制約、現場でハマった5例。機器側も自社で作る立場から。](https://technosphere.co.jp/blog/ble-device-app-integration) [DEPLOYMENT 社内アプリの配布方法まとめ ストアに公開せずiOS/Androidへ配る5つの手段。必要な契約・台数上限・更新の手間を比較。](https://technosphere.co.jp/blog/inhouse-app-distribution) [TECH SELECTION ネイティブ・クロスプラットフォーム・PWAの選び方 判断を分ける6つの軸、iOS通知の前提、オフライン同期の設計。選定フローチャート付き。](https://technosphere.co.jp/blog/native-vs-pwa-app-choice) [MOBILE / 3D Three.jsでスマホ対応3Dゲームを作る バーチャルスティックの自作、モバイルで60fpsを出す5つの最適化。実際に遊べるデモ付き。](https://technosphere.co.jp/blog/threejs-mobile-3d-game) [EDGE AI Raspberry Pi×VLMで作るエッジAIカメラ 端末側で画像を理解させる実装。アプリと機器を組み合わせる案件の土台になる技術です。](https://technosphere.co.jp/blog/raspberry-pi-vlm-edge-ai) [VISION マルチカメラ画像スティッチング実装 複数カメラの映像を1枚に合成する処理。現場の記録アプリに応用できる画像処理の実例です。](https://technosphere.co.jp/blog/multi-camera-image-stitching) [AI RAGチャットボットとは？仕組みと作り方 アプリ内にAI相談窓口を組み込む際の基礎。社内文書を学習させる方法を図解しています。](https://technosphere.co.jp/blog/what-is-rag-chatbot) [技術コラムをすべて見る](https://technosphere.co.jp/blog/) ｜ [ブラウザで動く3Dデモを試す](https://technosphere.co.jp/games/drone-inspector/) Flow ## ご相談から公開までの流れ ### ご相談・ヒアリング 解決したい課題、使う人、想定端末を伺います。企画段階のご相談で構いません。 ### 要件整理・お見積り 必要な機能を整理し、方式を選定。作業範囲を明記した見積をご提示します。 ### 設計・画面デザイン 画面遷移と操作の流れを設計。実機で触れる試作で早めに確認いただきます。 ### 開発・テスト 実装と実機テスト。実際の利用環境（電波・明るさ・手袋の有無）も想定します。 ### 公開・運用 ストア申請または社内配布を代行。公開後のOS更新対応・改善も継続対応します。 Why Technosphere ## アプリ「だけ」の会社ではありません。 現場で使われるアプリは、たいてい端末の外とつながります。私たちは組込み機器・AI・サーバーまで自社で開発できるため、間に会社を挟まずに一貫して作れます。 ** ### 機器側もわかる マイコン・センサー・産業機器の開発実績があります。Bluetooth連携や独自プロトコルの解析も自社対応。 ** ### AIを組み込める 画像認識・RAGチャットボット・音声応対の実装経験があります。アプリに「判断する機能」を足せます。 ** ### サーバーまで面倒を見る API設計、AWS・GCP等のクラウド構築、監視まで対応。アプリだけ作って終わりにしません。 FAQ ## よくあるご質問 Q. スマホアプリ開発の費用はどのように決まりますか？ 必要な機能の数と複雑さ、iOS/Android両対応の要否、サーバー側の開発を含むか、デザインの作り込み、既存システムとの連携の有無で決まります。ご要件を伺ったうえで、作業範囲と追加費用が発生する条件を明記したお見積りをご提示します。概算だけ知りたい段階のご相談も歓迎です。 Q. ネイティブとPWA、どちらを選ぶべきですか？ プッシュ通知・高度なカメラ利用・オフライン動作・ストア露出が必要ならネイティブ系、社内利用でURL配布したい・費用と期間を抑えたいならPWAが向いています。要件を伺えば適切な方をご提案します。 Q. 開発期間はどのくらいですか？ 小規模な業務アプリで2〜4か月、中規模で4〜8か月が目安です。ストア審査に1〜2週間かかるため、公開希望日がある場合は逆算してスケジュールを組みます。 Q. 既存のWebシステムや基幹システムと連携できますか？ できます。APIがあれば接続し、なければAPI側の設計から対応します。Webシステム開発とクラウド構築も自社で行っているため、アプリとサーバーを分けずに進められます。 Q. 大阪で対応できる範囲を教えてください。 大阪市淀川区（新大阪）に拠点があり、大阪市内・北摂エリアをはじめ大阪府全域へ訪問できます。遠方の場合もオンラインで要件整理から開発・納品まで完結可能です。 Q. 企画段階でも相談できますか？ 歓迎です。「アプリにすべきか、Webで足りるか」の判断からお手伝いします。作らない方が良いと判断した場合は、その旨を正直にお伝えします。 Q. ストア申請や公開後の保守も任せられますか？ 対応します。App Store Connect・Google Play Consoleへの申請代行、審査対応、OSバージョンアップへの追随、障害対応まで含む保守契約をご用意しています。 ご相談・お見積りは無料です ## 「これ、アプリにできますか？」から お聞かせください。 作りたいものが固まっていなくても構いません。現場の困りごとを伺って、アプリにすべきか、Webで足りるかの判断からご一緒します。大阪市淀川区（新大阪）から、対面・オンラインどちらでも対応します。 [無料で相談する](https://technosphere.co.jp/contact?category=web) [06-4805-8282](tel:06-4805-8282) [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [技術コラム](https://technosphere.co.jp/blog/) [採用情報](https://technosphere.co.jp/recruit) [プライバシーポリシー](https://technosphere.co.jp/privacy) © 2023 Technosphere Inc. - [Facebook](https://www.facebook.com/technosphere.co.ltd) - [X（旧Twitter）](https://x.com/technosphere_co) - [Instagram](https://www.instagram.com/technosphere_co/) - [TikTok](https://www.tiktok.com/@technosphere.co) --- # 8051・Z80 レガシー移行ガイド｜古典8bitマイコンのEOL対策と現行マイコンへの移植・再生｜株式会社テクノスフィア > 8051（MCS-51）系・Z80 系の古典 8bit マイコンの生産終了・サポート終了対策を解説。アセンブリ主体のレガシーコード・特殊メモリバンク・独自周辺の壁と、STM32・RL78 への移植・再生ノウハウを公開。 URL: https://technosphere.co.jp/blog/8051-z80-legacy-migration-guide ** 目次 1. はじめに：今も残る古典8bitマイコン 2. 8051とZ80の特徴 3. 移行が必要になる背景 4. 古典8bit移行の壁 5. 移行先の選定 6. 移行プロジェクトの進め方 7. まとめ ## はじめに：今も残る古典8bitマイコン **8051（Intel MCS-51）**と**Z80（Zilog）**は、1980年代から使われ続けている古典的な8bitマイコン／CPUです。シンプルで枯れた設計ゆえに信頼性が高く、産業機器・計測機器・制御盤・古い装置の組込み制御に、現在もなお現役で残っています。 しかし、オリジナルのZilog Z80が製造終了をアナウンスするなど、古典デバイスの**供給終了**が進んでいます。専用の周辺チップ・メモリの入手難、開発環境の喪失、当時の技術者の高齢化・退職も重なり、「装置を動かし続けるために現行マイコンへ移行・再生したい」という相談が生まれています。本記事ではその判断材料と進め方を解説します。 ** テクノスフィアのレガシー再生実績 テクノスフィアは、ソース・回路図が失われた組込み機器の [逆アセンブル・再構築](https://technosphere.co.jp/blog/renesas-rl78-reverse-engineering) を手がけています。8051/Z80を含む古典マイコンから現行品への移行も [受託開発](https://technosphere.co.jp/embedded-achievements) で対応しています。 ## 8051とZ80の特徴 | 項目 | 8051（MCS-51） | Z80 | | 系譜 | Intel発。現在も多社が互換コアを供給 | Zilog発。オリジナルは製造終了が進行 | | アーキ | ハーバード型。内部RAM/外部RAM/プログラムメモリが分離 | ノイマン型。メモリ空間とI/O空間が分離 | | 特徴 | ビット操作命令・SFR（特殊機能レジスタ）が豊富 | 豊富なレジスタ・インデックス命令。CP/M資産 | | 現状 | 8051コアは継続供給品あり（Silicon Labs等） | オリジナルは終息。互換・FPGAコアで延命例も | どちらも命令体系が比較的単純で「枯れている」ため、逆アセンブルによる解析はしやすい部類です。一方で、独自のメモリ／I/O構成をどう現行マイコンに写すかが移行設計の肝になります。 ## 移行が必要になる背景 - **デバイス・周辺の供給終了**：オリジナルCPUや専用周辺チップ、特殊メモリの入手難 - **開発環境の喪失**：当時のアセンブラ・ICE（インサーキットエミュレータ）・ROMライタが動かない／無い - **技術者の不在**：古典アーキを理解する技術者が高齢化・退職 - **保守限界**：交換基板が作れず、装置が止まると復旧不能のリスク ## 古典8bit移行の壁 ** 移行を難しくする要因 1. **アセンブリ主体**：C言語ではなくアセンブリで全実装されていることが多い 2. **独自メモリ・I/O構成**：8051の内部/外部RAM分離・SFR、Z80のI/O空間など、現行マイコンのフラットなメモリモデルへの写し替えが必要 3. **外付け周辺への依存**：当時はCPU外部のペリフェラルIC（タイマ・シリアル・PIO等）に依存。これらも含めた再設計が必要 4. **タイミング依存**：ソフトウェアディレイなど動作クロックに依存した実装。クロックが変わると挙動が変わる 古典8bitは命令が単純なぶん解析しやすい一方、「外付けIC込みのシステム全体」をどう現代の1チップマイコン＋内蔵周辺へ集約するかが設計上の腕の見せどころになります。 ## 移行先の選定 | 移行先 | 相性 | ポイント | | **STM32（ARM）** | ◎ 汎用・調達性 | 豊富な内蔵周辺で外付けICを集約。情報量・調達性に優れる。[STM32実装ガイド](https://technosphere.co.jp/blog/stm32-uart-i2c-can) | | **ルネサス RL78** | ◎ 小規模・低コスト・国内量産 | 8bit/16bitクラスの置換に最適。[RL78ガイド](https://technosphere.co.jp/blog/renesas-rl78-peripheral-guide) | | **8051互換コア継続** | △ 延命策 | Silicon Labs等の8051コアでコア互換のまま延命。ただし長期的には現行アーキ移行が安全 | 多くの場合、外付け周辺を内蔵周辺に集約できる**STM32**や、低コスト・国内量産に強い**RL78**への移行が現実的です。「とにかく早く延命したい」場合は8051互換コアでつなぐ選択もありますが、根本解決には現行アーキへの移行をおすすめします。 移行元のファミリから移行先候補と工数を押し上げる要因を逆引きできる [マイコン移行判断ナビ](https://technosphere.co.jp/mcu-migration#8051) を公開しています。他ファミリとの比較にもお使いください。 ## 移行プロジェクトの進め方 ** 標準的な移行ステップ 1. **現状調査**：残存資産（ソース・ROM・回路図・実機・外付けIC構成）の棚卸し 2. **仕様復元**：アセンブリ解析、または逆アセンブル＋実機動作解析で仕様化 3. **システム再設計**：外付け周辺を内蔵周辺へ集約する構成を設計 4. **移行先選定**：必要周辺・性能・調達性から現行マイコンを選定 5. **ハード設計**：基板リプレース（電圧・端子・周辺の対応付け） 6. **ソフト再実装**：アセンブリ部分をC言語で再構築、タイミング依存処理を再設計 7. **等価性検証・量産移行**：旧機と新機の入出力・タイミングを検証し量産へ 古典8bitからの移行は「CPU単体の置換」ではなく「外付けIC込みのシステム再設計」になることが多いため、**現状調査とPoC**で全体像と工数を把握してから本格移行に進むのが安全です。 ## まとめ ### この記事のまとめ - 8051（MCS-51）・Z80は今も産業現場に残るが、供給終了・環境喪失で移行ニーズが生まれている - 移行の壁は「アセンブリ主体・独自メモリ/I/O構成・外付け周辺依存・タイミング依存」 - 移行先は内蔵周辺が豊富なSTM32、低コスト・国内量産のRL78が現実的 - アセンブリしか無くても、実機とROMがあれば逆アセンブルで仕様復元して移植できる - 古典8bitの移行は「システム全体の再設計」になりやすく、現状調査とPoCが重要 8051・Z80ベースの装置の移行や再生でお困りでしたら、テクノスフィアにお気軽にご相談ください。アセンブリ資産・外付けIC込みのレガシーシステムからでも、現行マイコンへの移行プランをご提案します。 8051/Z80 装置の逆アセンブル、外付け IC 込みのシステム再設計、STM32/RL78 への移植・量産まで [組込み制御・マイコン開発](https://technosphere.co.jp/embedded) として対応しています。 ／レガシーマイコンの移行・再生のご相談はこちら＼ ### 8051・Z80 からの移行・レガシー再生 供給終了した古典8bitマイコン搭載装置を、逆アセンブルによる仕様復元・外付けIC込みのシステム再設計から現行マイコン（STM32 / RL78 等）への移植・量産まで対応します。アセンブリ資産のみの状態でもご相談ください。 [組込み開発サービスを見る](https://technosphere.co.jp/embedded) [8051/Z80→STM32/RL78移植相談](https://technosphere.co.jp/contact) ## よくある質問（FAQ） ** 8051やZ80の移行先には何を選べばよいですか？ 現行のARM Cortex-M（STM32）やルネサスRL78が一般的です。小規模・低コスト維持ならRL78やSTM32下位品種、機能拡張も見据えるならSTM32中位品種が向きます。8051コアは継続供給品もあり延命も可能ですが、長期的には現行アーキ移行が安全です。 ** アセンブリのコードしか残っていなくても移行できますか？ 可能です。8051/Z80のアセンブリやROMから逆アセンブル・動作解析で仕様を復元し、C言語で現行マイコンへ再実装します。古典8bitは命令体系が単純で解析しやすく、レガシー再構築の実績があります。 ** 移行で特に注意すべき点は？ 8051のビット操作命令・SFR・メモリ空間分離、Z80のI/O空間分離・特殊レジスタを、現行マイコンのメモリモデルへどう写すかが鍵です。クロックが変わるとソフトウェアディレイ等のタイミング依存処理が変わるため、実機計測で等価動作を確認します。 ** なぜ古典8bitの移行が必要になるのですか？ オリジナルZ80の製造終了など古典デバイスの供給終了が進んでいるためです。専用周辺チップ・メモリ・開発環境の入手難、技術者の高齢化・退職も重なり、長寿命の産業・計測機器で移行・再生ニーズが生まれています。 ## 次に読む｜マイコン記事 - [レガシー再生 RL78 逆アセンブル・再構築 ソース紛失基板の復元事例](https://technosphere.co.jp/blog/renesas-rl78-reverse-engineering) - [レガシー移行 H8/H8S 移行ガイド 旧日立・ルネサス系の移行](https://technosphere.co.jp/blog/h8-h8s-migration-guide) - [移行先候補 STM32 UART・I2C・SPI・CAN 実装ガイド 外付けICを内蔵周辺へ集約](https://technosphere.co.jp/blog/stm32-uart-i2c-can) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # AIエージェントに「社内の型」を教える｜新規プロジェクトの環境構築をスキル化して自動化した話｜株式会社テクノスフィア > リポジトリ作成・課題管理・Wiki整備という新規プロジェクト立ち上げの定型作業を、Claude CodeのAgent Skillsで自動化した実践記録。スキルの作り方、公式ツールによる定量評価（スキルあり100% vs なし70.8%）、社内ナレッジをAIに教える際の設計ポイントを解説します。 URL: https://technosphere.co.jp/blog/ai-agent-project-setup-skill ** 目次 1. はじめに：プロジェクト立ち上げという「儀式」 2. Agent Skills（スキル）とは 3. 何をスキルにしたか：環境構築の3点セット 4. 効果を数字で確かめる：スキルあり vs なし 5. 社内ナレッジをAIに教えるときの設計ポイント 6. よくある質問（FAQ） 7. まとめ ** 本記事について 本記事は、当社が社内で実際に運用しているAIエージェント（Claude Code）の取り組みの記録です。記事中の会社名・プロジェクト名の例はすべて**架空のもの**に置き換えています。仕組みの考え方はツールを問わず応用できます。 ## はじめに：プロジェクト立ち上げという「儀式」 受託開発の会社では、新しい案件が決まるたびに同じ準備作業が発生します。ソースコードを置く**リポジトリの作成**、進捗を管理する**課題管理システムのプロジェクト登録**、情報を集約する**社内Wikiのページ作成**。1つ1つは難しくありませんが、命名規則・階層構造・書くべき項目といった「社内の型」が関わるため、意外と手間がかかります。 そして、この手の作業は**毎回微妙にブレます**。リポジトリ名の付け方が人によって違う、課題管理には登録したがWikiは後回しのまま、概要欄が空っぽ——。立ち上げ時のわずかなブレが、数ヶ月後の「あの資料どこ？」につながります。 当社ではAIエージェント（Claude Code）を開発業務に組み込んでいますが、今回この立ち上げ作業一式を「**スキル**」としてAIに教え込みました。結果、**「〇〇社の新しい案件、△△を作ることになった。環境を整備して」というひと言**で、3点セットが社内の型どおりに揃うようになりました。 ## Agent Skills（スキル）とは （図: 社内ルールをまとめた本が光の粒になってAIロボットに流れ込むイメージイラスト） スキルとは、AIエージェントに特定の作業の**手順書・テンプレート・参照資料をパッケージとして渡す仕組み**です。Claude Codeでは「Agent Skills」という公式機能として提供されており、Markdownで書いた手順書（SKILL.md）と付属資料をフォルダに置くだけで使えます。 ポイントは、スキルには**発動条件となる説明文**を書いておけることです。「新しい案件を始める」「環境を作って」といった依頼が来たとき、AIは自分でスキル一覧から該当するものを見つけて読み込み、その指示に従って作業します。ユーザーがスキルの存在を意識する必要はありません。 言い換えると、スキルは**「ベテラン社員の頭の中にある暗黙知を、AIが読める形式知に変換したもの」**です。一度書けば、誰がAIに依頼しても同じ品質・同じ型で作業が行われます。新人でもベテランと同じ運用ができる、というのが実務上いちばん大きな効果でした。 ## 何をスキルにしたか：環境構築の3点セット （図: リポジトリ・課題管理ボード・Wikiの3つの島が光の橋でつながり、ロボットが旗を立てているイメージイラスト） 今回のスキルには、次の4つの知識を詰め込みました。 | 教えた内容 | 例 | | **命名規則** | リポジトリ名は「顧客名＋内容」の英語小文字。例えば架空のアクメ社の「サイネージ動画再生システム」なら `acme-signage-player` | | **階層構造** | 課題管理は「顧客の会社」を見出しプロジェクトとして作り、その配下に案件を作る2階層。Wikiも同じく会社ページ→案件ページの階層 | | **書くべき中身** | 会社の見出しには「どんな会社か」の概要（Web検索で裏取りした事実のみ）、案件には「何を作るのか」の要約。テンプレートを同梱 | | **安全ガード** | 実行前に必ず計画（命名・階層・概要文の案）を提示して承認を得る。後から変更できない識別子があるため | 大事なのは、これらを頭から書き下ろしたのではなく、**先にAI自身に社内の既存プロジェクトを調査させた**ことです。既存の命名の実例、見出しプロジェクトの書きぶり、Wikiの階層——「いま社内で実際に使われている型」を集めてからスキルに固めたので、出来上がった瞬間から過去の資産と綺麗に並びます。 もう1つ、地味に効くのが**実在の設定値を焼き込む**ことです。「グループを追加する」ではなく「グループID 10を開発者ロールで追加する」と書いておく。AIが毎回調べ直す必要がなくなり、実行が速く確実になります。 ## 効果を数字で確かめる：スキルあり vs なし （図: 下書き・比較・計測・改善の4ステップを循環する評価ループのイメージイラスト） スキルは書いて終わりではなく、**効果を測って改善するループ**を回しました。Claude Codeにはスキル開発用の公式スキル「skill-creator」があり、テスト用の依頼文を「スキルあり」「スキルなし」の2つのAIに与えて出力を比較・採点する仕組みが同梱されています。 今回は「新規顧客の案件」「既存顧客への案件追加」という2つのテストシナリオを用意し、命名規則・階層構造・既存ページを壊さない判断など**10項目の採点基準**で機械的に採点しました。結果は次のとおりです。 | 構成 | 合格率 | 主な失点 | | **スキルあり** | **100%（10/10）** | — | | スキルなし | 70.8% | リポジトリ名の揺れ、メンバー登録の慣例漏れ、概要欄の記載漏れ、既存Wikiページの扱いに未言及 | 興味深いのは「スキルなし」でも70.8%取れている点です。AIは社内の他のドキュメントからかなりの型を推測できます。しかし**残りの約3割——命名の一貫性や暗黙の慣例——こそが、数ヶ月後に効いてくる部分**です。この差分を数字で確認できたことで、スキル化の価値に確信を持って運用に載せられました。 なお評価はすべて「計画の提示まで」で行い、テスト中に本物のリポジトリやプロジェクトは一切作られない設計にしています。本番システムに触れる作業のテストでは、この安全設計が必須です。 ## 社内ナレッジをAIに教えるときの設計ポイント 今回の取り組みで得られた、スキル設計の勘所をまとめます。 - **先に実態を調査する**——ルールを頭で書くのではなく、既存の実例をAIに集めさせてから型に固める。理想論ではなく「いま動いている慣例」を写し取る - **取り返しのつかない操作にはガードを置く**——変更不可の識別子や外部サービスへの書き込みは、計画提示→承認→実行の2段階にする - **「なぜ」を書く**——「グループを追加する（しないと他のメンバーから見えないため）」のように理由を添えると、AIは例外的な状況でも意図に沿って判断できる - **効果は測る**——スキルあり/なしの比較採点で、思い込みではなく数字で価値を確認する。採点基準そのものも資産としてスキルに同梱しておく - **過去の失敗をチェックリストにする**——一度踏んだミスをスキルの注意事項に書き足していくと、組織として同じ失敗を二度としなくなる ## よくある質問（FAQ） Q. Agent Skills（スキル）とは何ですか？ A. AIエージェントに、特定の作業の手順書・テンプレート・参照資料をパッケージとして渡す公式の仕組みです。依頼内容に応じてAIが自動的に該当スキルを読み込み、社内の規約どおりに作業します。 Q. スキルの効果はどうやって測ったのですか？ A. 同じ依頼文を「スキルあり」「スキルなし」のAIに与えて出力を比較し、10項目の採点基準で採点しました。結果はスキルあり100%、なし70.8%でした。 Q. AIが勝手にリポジトリやプロジェクトを作ってしまう心配は？ A. スキル側に「実行前に必ず計画を提示して承認を得る」ガードを組み込んでいます。後から変更できない識別子を含む操作は、承認なしでは実行されません。 ## まとめ 新規プロジェクトの環境構築という「小さいが毎回発生し、ブレると後で効いてくる」作業を、AIエージェントのスキルとして型に固めました。ひと言の依頼で3点セットが揃い、効果は比較採点で**+29ポイント**と数字でも確認できました。 スキル化の本質は自動化そのものより、**散らばっていた社内の暗黙知が、レビュー可能・改善可能な文書になる**ことだと感じています。属人化した手順書きから始めて、評価ループで磨く——このパターンは環境構築に限らず、見積作成やデプロイ手順など幅広い定型業務に応用できます。 当社では、こうしたAIエージェントの業務組み込み・社内ナレッジのスキル化を自社で日常的に実践し、そこで得た知見をお客様のシステム開発・業務自動化にも展開しています。「うちの定型業務もAIに任せられないか？」という段階のご相談も歓迎です。 --- # 「AIが書いたコード、誰が責任を持つのか」｜全作業を証跡化する開発運用（Redmine×Growi×Obsidian×Claude Code）｜株式会社テクノスフィア > 生成AIにコードを書かせる時代の品質と説明責任をどう担保するか。テクノスフィアが Redmine・Growi・Obsidian・Claude Code で全作業を証跡（監査トレース）として残す運用を、実際のフォーム障害を追跡・修正した事例とともに公開します。 URL: https://technosphere.co.jp/blog/ai-development-audit-trail ** 目次 1. なぜ今「開発の証跡」が問われるのか 2. 証跡の 4 層モデル：Redmine／GitHub／Obsidian／Growi 3. Claude Code が残す「実行の証跡」 4. 実例：1 週間気づかれなかった障害を証跡から追う 5. 証跡がビジネスにもたらす 4 つの価値 6. 証跡を回す 3 つの原則とよくある失敗 7. まとめ ** 本記事のスコープ 本記事は「**記録をどう自動化するか**」の続編にあたる、「**記録を証跡として、品質と説明責任にどうつなげるか**」という運用思想の話です。スキルによる自動化の実装は [Obsidian作業ログ＋Redmine運用を完全自動化した話](https://technosphere.co.jp/blog/openclaw-skills-obsidian-redmine) で、AI基盤の構築は [OpenClaw 入門](https://technosphere.co.jp/blog/openclaw-getting-started) で扱っています。 ## なぜ今「開発の証跡」が問われるのか 2025〜2026 年、ソフトウェア開発の現場は「**人がコードを書く**」から「**AI に書かせて人がレビューする**」へと急速に移りました。Claude Code をはじめとする AI エージェントは、調査・実装・テスト・デプロイまでを一気に進めてくれます。生産性は跳ね上がりました。しかし、その裏返しで経営者・発注者からこんな声が出てきます。 - 「その変更、**誰が・いつ・なぜ**入れたのか説明できるか？」 - 「AI が勝手に書いたコードを、**本当に人がレビューした**のか？」 - 「障害が起きたとき、**原因と対応の経緯を遡れる**か？」 - 「担当者が辞めたら、その案件は**ブラックボックス**にならないか？」 これらはすべて「**トレーサビリティ（追跡可能性）**」の問いです。スピードを上げれば上げるほど、「速いが説明できない開発」はリスクになります。とくに受託開発では、納品物の品質を顧客に説明する責任から逃れられません。 ** テクノスフィアの結論 私たちの答えはシンプルです。**AI に任せる範囲を広げるなら、証跡を残す範囲も同じだけ広げる**。AI が書いたかどうかは問題ではありません。「なぜ着手し、何を変え、どう考え、どう検証したか」がすべて記録に残っていれば、AI活用とガバナンスは両立します。むしろ AI は**記録作業そのものを自動化できる**ぶん、人間だけの時代より証跡を厚くできます。 ## 証跡の 4 層モデル：Redmine／GitHub／Obsidian／Growi テクノスフィアでは、1 つの作業を**性質の異なる 4 つの層**に分けて記録しています。それぞれが「異なる問い」に答える証跡です。 （図: 証跡の4層モデル：Redmine（なぜ）・GitHub（何を）・Obsidian（どう）・Growi（恒久知）） | 層 | ツール | 答える問い | 残るもの | | **課題** | Redmine | なぜ着手したか / What | チケット、依頼の背景、期日、担当、ステータス遷移 | | **変更** | GitHub | 何を変えたか | コミット差分、PR、レビュー、マージ履歴 | | **過程** | Obsidian | どう考え何をしたか | 日次作業ログ、調査メモ、判断理由、トラブル対応 | | **恒久知** | Growi | 次に活かす知識 | 手順書、設計指針、再発防止ナレッジ | ### 層をまたいで「1 本の線」でつなぐ 4 層がバラバラに存在しても証跡にはなりません。鍵は **Redmine チケット番号**です。弊社では「**すべてのコミット・PR・ブランチにチケット番号を含める**」を社内規約にしています。 ``` # ブランチ名にチケット番号 feature/220-blog-audit-trail # コミットメッセージに refs #220 git commit -m "feat: refs #220 証跡管理の技術記事を追加" # PR タイトルにも refs #220 gh pr create --title "refs #220 証跡管理の技術ブログを追加" ``` Redmine は GitHub と双方向連携しているため、`refs #220` を含むコミットや PR は**自動的に Redmine チケットへ紐づきます**。これにより「チケット → コミット → PR → 作業ログ」が 1 本の線でつながり、どこからでも全体を辿れる状態になります。 ** なぜ番号の徹底がここまで効くのか 番号はただの整理タグではなく、**4 つの証跡層を結ぶ関節**です。番号さえ通っていれば、後から「この本番障害はどのチケットの、どのコミットで入ったか」を機械的に逆引きできます。逆に番号が欠けた作業は、どれだけ丁寧にメモしても**「線」から外れた孤立点**になってしまいます。 ## Claude Code が残す「実行の証跡」 4 層モデルに、もう 1 つ現代的な層が加わります。**AI エージェント自身の実行ログ**です。テクノスフィアでは Claude Code を実装の主戦力に据えていますが、その作業は「見えないブラックボックス」ではありません。 - **セッションの全やり取りが記録される：**どんな指示に対し、どのファイルをどう編集し、どんなコマンドを実行したかが時系列で残る - **作業ログへ自動で要約・追記：**セッションの節目ごとに Obsidian の日次作業ログへ「何をやったか」を自動追記（人手の記録漏れがゼロ） - **Redmine・Git と連動：**起票・ブランチ・コミット・PR・チケット更新までを一気通貫で実行し、すべてに番号を通す つまり Claude Code は**「実装する道具」であると同時に「証跡を生成する装置」**でもあります。人間は最終レビューと承認（マージ）に集中し、記録は AI が漏れなく残す。この分担が、速度と説明責任を同時に成立させる肝です。 ** 「AI が暴走しない」ための線引き 弊社では、本番反映や破壊的操作・外部公開を伴う作業は**必ず人間の承認**を挟みます。AI は調査・実装・記録・検証までを担い、**マージと本番デプロイの引き金は人が引く**。この境界線そのものも証跡（PR の承認者・マージ時刻）として残ります。 ## 実例：1 週間気づかれなかった障害を証跡から追う 抽象論だけでは伝わりません。**この記事を書いた当日（2026年6月13日）に実際に起きた**出来事を、証跡の力が分かる事例として紹介します。 （図: 証跡から障害の根本原因を追跡するイメージ） ### 発覚：別作業の検証中に「フォームが壊れている」 Google 広告まわりの計測を改善する作業の途中で、自社サイトの**お問い合わせフォームが途中までしか表示されていない**ことに気づきました。送信ボタンが出ない＝**問い合わせがまったく送れない**状態です。 ### 追跡：いつ・どの変更で壊れたか ここで証跡が効きます。当該ファイルの変更履歴（Git）を遡ると、原因は **6 日前のあるコミット**でした。サニタイズ関数の定義位置が原因で、特定の表示経路だけ PHP の致命的エラーになり、本番ではエラー非表示設定のため「**フォームが短く見えるだけ**」で誰も異常に気づけなかったのです。 ``` 原因コミット（6日前）：機能追加時に 関数 h() を「送信時の処理ブロックの中」で定義 → 表示だけの経路（GET）では h() が未定義 → Fatal error で描画が途中停止 → display_errors off の本番では“短いページ”にしか見えない ``` 変更履歴がなければ「いつからか分からない」で延々と切り分ける場面です。証跡があれば、**壊れた瞬間とその理由をピンポイントで特定**できます。 ### 修正・検証・記録まで一気通貫 原因が分かれば、あとは 4 層の証跡を通しながら直すだけです。 ``` 1. Redmine: 緊急バグとして起票（影響と原因を明記） 2. GitHub: 修正ブランチ → コミット（refs で番号を通す） 3. 検証 : Docker でビルトインサーバを立て、描画が 送信ボタンまで復活することを確認 4. PR : 人間がレビューしてマージ → 本番自動デプロイ 5. 確認 : 本番URLを取得し、フォームが復旧したことを実測 6. Redmine: 検証結果を添えてクローズ、作業時間も記録 7. Obsidian: 一連の経緯を日次作業ログへ自動追記 ``` この障害が「**6 日前から問い合わせが送れていなかった**」という重い事実も、原因・対応・再発防止の教訓もすべて記録に残りました。後日「あの一週間、なぜ問い合わせがゼロだったのか」を問われても、**1 本の線で説明できます**。これこそが証跡を残す運用の真価です。 ／AI開発の「速さ」と「説明責任」を両立したい方へ＼ ### 証跡が残る開発体制を、貴社にも 「AIを開発に使いたいが品質保証が不安」「障害時に経緯を追える体制にしたい」──そんな課題は、ツール連携と運用設計で解決できます。スモールPoCからご相談いただけます。 [AI開発・証跡管理の相談をする](https://technosphere.co.jp/contact?category=ai_solution) ## 証跡がビジネスにもたらす 4 つの価値 証跡管理は「真面目だが地味な事務作業」ではありません。実際のビジネス価値に直結します。 （図: 証跡管理がもたらす品質保証・信頼のイメージ） ### ① 品質保証：障害に強くなる 先の事例のとおり、「いつ・どの変更で・なぜ壊れたか」を遡れることは、復旧速度と再発防止を直接押し上げます。原因究明に費やす時間が桁で変わります。 ### ② 監査対応：AI 活用の説明責任を果たす 「AI が書いたコードを人が承認したか」を、PR の承認者・マージ時刻という**消えない記録**で示せます。情報システム部門やセキュリティ監査の要求にも、証跡で応えられます。 ### ③ 引き継ぎ：属人化を防ぐ 担当者が変わっても、チケットと作業ログを辿れば**「現状」と「なぜそうなっているか」**が分かります。プロジェクトページの自動更新ゾーンを見るだけで状況を把握できる状態を保っています。 ### ④ 顧客説明：報告に厚みが出る 作業ログを集約すれば、月次報告や障害報告を**事実ベースで即座に**組み立てられます。「やったはず」ではなく「この記録のとおりやりました」と言える強さは、受託開発の信頼に直結します。 ## 証跡を回す 3 つの原則とよくある失敗 3 ヶ月以上この運用を回してきて見えた、続けられる証跡管理の原則です。 ### 原則① チケット番号をすべてに通す ブランチ・コミット・PR・作業ログに**必ず Redmine 番号**を入れる。これが 4 層をつなぐ関節です。番号のない作業は証跡から孤立します。「チケットがなければ着手しない」を徹底するのが近道です。 ### 原則② 記録は AI に任せ、人は承認に集中する 記録を人手に頼ると、忙しい日ほど抜けます。**記録の生成は AI に自動化**させ、人間は「マージ」「本番反映」「顧客への約束」といった**判断と承認**にリソースを割く。役割分担で証跡が安定します。 ### 原則③ 自動更新と手書きを「壊さず共存」させる AI による自動更新が人の手書きメモを上書きすると、誰も記録を信じなくなります。弊社では更新領域を**マーカーで囲い、その内側だけ AI が更新**する方式を採り、自動と手動を安全に共存させています。 ** よくある 3 つの失敗 - **記録が目的化する：**証跡は手段。10 分で終わる相談まで起票すると形骸化します。粒度の線引きを決めましょう。 - **ツールが分散して線が切れる：**番号で串刺しにしないと、ツールを増やすほど追跡不能になります。 - **本番だけエラーが見えない：**今回の事例のように、本番のエラー非表示設定は障害を隠します。証跡（変更履歴）と監視で補完が必要です。 ## まとめ ### この記事のまとめ - AI に任せる範囲を広げるなら、**証跡を残す範囲も同じだけ広げる**。AIか人かは問題ではない - 証跡は **4 層**：Redmine（なぜ）／GitHub（何を）／Obsidian（どう）／Growi（恒久知） - **Claude Code は実装と同時に証跡を生成**。人はマージ・本番反映の承認に集中する - 4 層を結ぶ関節は **チケット番号**。`refs #123` をすべてに通す - 実例：6 日間気づかれなかったフォーム障害を、変更履歴から**瞬時に特定・修正・検証・記録**できた - 価値は **品質保証・監査対応・引き継ぎ・顧客説明**の 4 つに直結する テクノスフィアは、AI エージェント（Claude Code / OpenClaw 等）を Redmine・GitHub・Obsidian・Growi・社内ファイルサーバと連携させ、**作業の起票から記録・ナレッジ化までを自動で証跡化する開発体制**を自社で実践しています。「AI を開発に使いたいが品質保証が不安」「障害や監査に強い開発プロセスにしたい」といったご相談を歓迎します。 ／このテーマの受託開発・PoC相談はこちら＼ ### AI 活用と説明責任を両立する開発体制づくり 生成AIを開発に取り入れたい、しかし品質・監査・トレーサビリティが不安──そんな企業の「証跡が残る開発プロセス」設計と、Redmine / GitHub / Obsidian / Growi を AI で連携する仕組みづくりをテクノスフィアが支援します。スモール PoC から全社展開まで。 [AI開発サービスを見る](https://technosphere.co.jp/ai-solution) [証跡管理・AI開発を相談](https://technosphere.co.jp/contact?category=ai_solution) # AI開発 # 証跡管理 # トレーサビリティ # Claude Code # Redmine # Obsidian # 監査証跡 # 開発ガバナンス ## 次に読む｜AI業務自動化シリーズ - [自動化の実装 Obsidian作業ログ＋Redmineチケット運用を完全自動化した話 本記事の「記録の自動化」側の実装編](https://technosphere.co.jp/blog/openclaw-skills-obsidian-redmine) - [AI基盤の構築 OpenClaw 入門｜OSSのAIアシスタントを社内 Kubernetes で動かす 自社運用のAIエージェント基盤づくり](https://technosphere.co.jp/blog/openclaw-getting-started) - [関連記事 RAGチャットボット社内ヘルプデスク導入事例 社内 DX × AI の代表例](https://technosphere.co.jp/blog/what-is-rag-chatbot) - [サービス AI ソリューション開発 証跡が残る開発体制づくりのご支援](https://technosphere.co.jp/ai-solution) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # AI面接ツール比較7選【2026年最新】料金・費用相場と中小企業の選び方｜テクノスフィア > AI面接ツール主要7サービスを料金体系・無料トライアル・得意な採用形態で徹底比較。初期費用・月額・従量課金の費用相場と損益分岐の考え方、中小企業が失敗しない選び方、導入前チェックリストまで、2026年7月時点の各社公式情報をもとに解説します。 URL: https://technosphere.co.jp/blog/ai-interview-tools-comparison 「AI面接ツールを導入したいが、料金の相場感がつかめない」「比較記事を読んでも大企業向けの話ばかりで、自社の規模に合う選び方がわからない」――本記事は、この2つの疑問に答えるための比較ガイドです。 本記事では、主要なAI面接ツール7サービスを**料金体系・無料トライアルの有無・得意な採用形態**の軸で比較し、**費用相場と料金体系の見方**、そして比較記事で意外と語られない**中小企業向けの選び方**を解説します。掲載している料金・機能は、**2026年7月14日時点で各社公式サイトに公開されている情報**にもとづいています（公式に価格を公開していないサービスは「要問い合わせ」と明記しています）。なお、弊社はAI面接サービスSUGUMENの提供元です。本記事は競合を含む横比較ですが、その立場を踏まえてお読みください。 ## AI面接ツールとは？なぜ今注目されているか AI面接ツールとは、人工知能を活用して**採用面接の一部（主に一次面接・スクリーニング）を自動化する**クラウドサービスです。候補者がスマートフォンやPCから面接に回答し、AIが回答内容（サービスによっては音声や表情も）を分析して評価レポートを自動生成します。 大きく分けると、AIが面接官として質問を投げかけ深掘りまで行う**「対話型」**と、あらかじめ設定した質問に候補者が動画で回答する**「録画型」**の2タイプがあり、対話型の方が面接らしい体験になる一方、録画型は短時間で多人数を捌きやすいという住み分けがあります。 導入の動機は実務上ほぼ2つ——一次面接の工数削減と、応募から初回接触までのスピード——に集約されます。 ポイント：** AI面接ツールは「面接官の代わり」ではなく、「一次スクリーニングの効率化」や「評価の補助」として活用するのが効果的です。最終面接は人が行い、AIは大量の応募者を短時間で絞り込む役割を担います。 ### AI面接ツールとWeb面接ツール・オンライン面接ツールの違い 比較検討を始めた段階でつまずきやすいのが、この3つの呼び分けです。**「Web面接ツール」「オンライン面接ツール」と呼ばれる製品の多くは、AI面接ツールとは目的が異なります**。 | 種類 | 何をするツールか | 面接官の同席 | 主な導入目的 | | **Web面接ツール オンライン面接ツール** | 面接を**オンラインで実施する場**を提供する。日程調整・録画・評価入力などを備える | 必要 （リアルタイム） | 遠隔地の候補者に対応する。会場費・交通費を削減する | | **録画型 AI面接ツール** | 候補者が**都合のよい時間に動画で回答**し、AIが内容を分析して評価レポートを作る | 不要 （非同期） | 一次面接の工数を削減する。応募から初回接触までを短縮する | | **対話型 AI面接ツール** | AIが**面接官として質問し、回答に応じて深掘り**する。その場で評価まで行う | 不要 （非同期） | 一次面接そのものを代替する。24時間いつでも面接を受けられる状態を作る | つまり**Web面接ツールは「面接の場所」の問題を解き、AI面接ツールは「面接にかかる工数」の問題を解きます**。オンラインで面接はできているが一次面接の日程調整と工数が重い、という課題であればAI面接ツールの検討対象になります。逆に、面接官が対話しながら見極めること自体に価値がある採用であれば、Web面接ツールのままで十分です。 両者は排他的ではなく、**一次はAI面接ツール、二次以降はWeb面接ツール**と併用する運用が現実的です。本記事で比較しているのは、このうちAI面接ツールにあたる製品です。 ## AI面接ツールの費用相場と料金体系の見方 AI面接ツールの料金は「月額○円」と一言で比べられる構造になっていません。まず**費用の構成要素**を押さえ、そのうえで「自社の面接件数ならいくらになるか」を試算できるようになりましょう。 ### 費用は「初期費用＋月額固定 or 従量課金＋オプション」でできている - **初期費用**：アカウント発行・初期設定・質問設計支援などにかかる一時金。**0円のサービスが増えています**が、サービスや導入内容によっては数十万円かかる場合もあります。 - **月額固定（定額制）**：面接件数の上限や機能に応じた月額。件数を多く使うほど1件あたりの単価が下がります。 - **従量課金**：面接1件ごとの課金。使った分だけの支払いなので、採用に波がある企業や導入初期に向きます。 - **オプション費用**：ATS連携、AI面接機能の追加、質問・評価軸のカスタマイズ、サポート強化など。見積もり時には内訳の確認が欠かせません。 ### 公開価格から見た相場観（2026年7月時点） 各社が公式サイトで公開している価格をもとにすると、相場の目安は次のとおりです。なお、エンタープライズ向けを中心に**料金を公開していない（要問い合わせの）サービスも多い**点には注意してください。弊社SUGUMENは月額2万円の基本料＋従量課金です（詳細は後述）。 | 費目 | 目安 | 補足 | | 初期費用 | 0円〜数十万円 | クラウド型は0円が主流になりつつある。導入支援・カスタマイズを含むと高くなる | | 月額定額 | 月2万円台〜10万円前後 | 公開価格の例：ITSUMEN 月額21,780円（税込）〜、Our AI面接 月額換算7.5万円〜（税別）（年間契約・件数無制限）。エンタープライズ向けは非公開が多い | | 従量課金 | 1面接 1,000〜5,000円程度 | 公開価格の例：SHaiN 標準5,000円/件（税別）・アルバイト1,000円/件（税別）、MiAI 1,000円/件〜。アルバイト・パート向けの短時間面接は安い傾向 | | オプション | サービスによる | 例：ITSUMENのAI面接機能は月11,000円〜のオプション。ATS連携やサポート強化が別料金の場合も | ※ 2026年7月14日時点の各社公式サイト掲載情報にもとづく目安です。税込・税別の表記は各社サイトに従っています。最新の料金・条件は必ず公式サイトでご確認ください。 ### 月額固定と従量課金、どちらが得か：損益分岐の考え方 判断基準はシンプルで、**「月間面接件数 × 従量単価」と月額定額料金の比較**です。 - 従量単価3,000円・月10件なら月3万円 → **従量課金が有利** - 従量単価3,000円・月50件なら月15万円 → 定額制（例：月7.5万円で件数無制限）の方が安くなる → **定額が有利** おおまかには**月間数十件が分岐点**になるケースが多いですが、繁忙期と閑散期の差が大きい採用（新卒・季節採用など）では、年間トータルで試算しないと判断を誤ります。面接件数が読めない導入初期は、**従量課金または初期費用ゼロの低額プランで始めて、件数が安定してから定額に切り替える**のが失敗しにくい進め方です。なお、年間採用50〜300名規模の企業は、この損益分岐をまたぐことが多い価格帯です。 ### 見積もり時に確認すべき「見えにくいコスト」 - **最低契約期間・年間契約の縛り**：月額が安く見えても年間契約が前提の場合があります - **件数超過時の従量単価**：定額プランの上限を超えた分の単価 - **初期設定・質問設計の支援費用**：無償の範囲と有償の範囲 - **社内の運用工数**：評価レポートの確認・候補者への連絡など、ツール費用以外に人の時間もかかります ポイント：** 費用は単体で見るのではなく、**「削減できる工数（面接官の拘束時間・日程調整・一次対応の人件費）」との差し引き**で判断します。一次面接1件に面接官が45分＋日程調整で計1時間かかっているなら、月20件で20時間。この時間単価と比較すれば、投資判断はぐっと現実的になります。 ## 主要AI面接ツール比較表【2026年7月版】 主要7サービスを**料金体系・初期費用・無料トライアル・得意な採用形態**で比較しました。料金は各社公式サイトの公開情報（2026年7月14日確認）にもとづき、非公開のものは「要問い合わせ」としています。 | サービス名 （提供会社） | タイプ | 料金体系（公式公開情報） | 初期費用 | 無料トライアル | 得意な採用形態 | | SHaiN （タレントアンドアセスメント） | 対話型 | 従量課金：標準プラン5,000円/件（税別）、アルバイトプラン1,000円/件（税別） ※後払いの場合は受検者管理システム利用料（年額）あり | 公式記載なし | あり | 新卒・中途・アルバイト・昇格試験 | | harutaka （ZENKIGEN） | 採用DXプラットフォーム型 （Web面接・録画・AI面接） | 要問い合わせ | 要問い合わせ | あり | 新卒大量採用など大手・中堅の採用全般 | | Our AI面接 （JetB） | 対話型（アバター面接官） | 定額制：月額換算7.5万円〜（税別）（年間契約）・面接回数無制限 | あり（金額は要問い合わせ） | 公式記載なし（資料請求） | 通年採用・大量採用（件数無制限） | | ITSUMEN （マルジュ） | 録画型＋AI面接オプション | 月額定額：21,780円（税込）〜。AI面接はオプション月11,000円〜 | 0円 | お試しチケットあり | アルバイト・派遣・新卒 | | MiAI （プロップス） | 対話型 | 従量課金：1面接1,000円〜 | 公式記載なし | 無料デモあり | 新卒・中途・アルバイト・派遣 | | PeopleX AI面接 （PeopleX） | 対話型 | 要問い合わせ | 要問い合わせ | 無料トライアルあり | 新卒・中途・アルバイトなど幅広い | | SUGUMEN（自社） （テクノスフィア） | 対話型（テキスト・音声） クラウド型 | 月額2万円＋従量課金 （従量単価は要問い合わせ） | 0円 | デモ申込可 | 中小企業の中途・アルバイト一次面接 | ※ 料金・機能は2026年7月14日時点の各社公式サイト掲載情報です。「公式記載なし」「要問い合わせ」は当該情報が公式サイトで公開されていないことを示します。掲載順はSUGUMEN（自社サービス）を除き順不同です。 ### 各サービスの特徴（公式情報より） **SHaiN（シャイン）**は対話型AI面接の先駆け的サービスで、AIが候補者の回答を深掘りしながら面接を進めます。標準プランの所要時間は30〜40分、アルバイトプランは5〜10分。24時間365日スマートフォンで受験でき、面接評価レポートが自動生成されます。 **harutaka（ハルタカ）**はWeb面接・録画選考・AI面接・面接解析（harutaka IA）までを揃えた採用DXプラットフォームです。大手企業を中心とした導入実績が公開されており、面接そのものの自動化に加えて「人が行う面接の品質分析」までカバーするのが特徴です。 **Our AI面接**はアバター型のAI面接官と対話する形式で、定額制・面接回数無制限（月額換算7.5万円〜（税別）・年間契約）という料金体系が特徴です。面接件数が多いほど1件あたりのコストが下がるため、通年で大量に面接する企業に向いた設計です。 **ITSUMEN（イツメン）**は録画面接ツールをベースに、AI面接をオプションで追加できる構成です。初期費用0円・月額21,780円（税込）からと公開価格が低めに設定されており、アルバイト・派遣採用での利用例が紹介されています。 **MiAI（ミアイ）**は1面接1,000円からの従量課金制の対話型AI面接です。回答に応じた深掘り質問の自動生成、録画・文字起こし、評価レポート自動生成に対応し、新卒からアルバイト・派遣まで幅広い採用形態を対象としています。 **PeopleX AI面接**は対話型AI面接に加え、採用要件定義や面接質問の自動提案など選考プロセス全体の支援機能を持ちます。料金は非公開ですが、無料トライアルで実際の機能を試せると公式サイトに明記されています。 **SUGUMEN（スグメン）**は弊社テクノスフィアが自社開発するクラウド型AI面接サービスです。応募から最短3分でAI面談を開始でき、24時間365日AIが一次面接を自動代行します。初期費用0円・月額2万円の基本料＋従量課金で、既存ATSとはURL連携またはAPI接続が可能。候補者はアプリ不要・ブラウザのみで受験でき、所要時間は最短10〜15分、テキストと音声の両方に対応しています。詳しくは後述の「比較表の中でのSUGUMENの位置づけ」をご覧ください。 ## AI面接ツール選びの5つのポイント 自社の条件に引きつけて評価するための5つの軸を紹介します。 ### 1. 機能の充実度（自社の採用フローに必要な分だけ） 対話型か録画型か、AI評価レポートの粒度、質問・評価軸のカスタマイズ性など、**自社の採用フローに必要な機能が揃っているか**が最初の確認点です。大量採用が中心なら一括スクリーニングのしやすさが、専門職採用なら深掘り質問のカスタマイズ性が重要になります。逆に、使わない機能のために高いプランを契約するのは典型的な失敗パターンです。 ### 2. コスト（初期費用・月額・従量課金の総額） 前述のとおり、**初期費用＋月額または従量＋オプションの年間総額**で比較します。月額が安く見えても最低契約期間や年間契約が条件の場合があるため、契約条件まで含めて確認してください。 ### 3. ATS（採用管理システム）連携 既に利用しているATSとの連携可否は、導入後の運用効率に直結します。API連携のほか、**URL連携（応募者への面接URL自動案内）やCSVインポート/エクスポート**で十分なケースも多いので、「どのレベルの連携が必要か」を先に決めておくと選択肢が広がります。ATSを使っていない企業では、ATSなしで完結できるかどうかが選定の分かれ目になります。 ### 4. セキュリティ・個人情報保護 面接データには候補者の映像・音声・評価情報など機微な個人情報が含まれます。**ISMS認証（ISO/IEC 27001）やプライバシーマークの取得状況**、通信の暗号化、データの保管場所と削除ポリシーを確認してください。また、AIによる評価を選考に使うこと自体を候補者に適切に説明できるか（利用目的の明示）も、運用設計の段階で詰めておくべきポイントです。 ### 5. 導入・運用サポート 初めてAI面接を導入する企業では、**質問設計のアドバイス**や**評価基準の設定支援**があるかどうかで立ち上がりの速さが変わります。テンプレートの充実度、日本語でのサポート窓口の有無、無償サポートの範囲も判断材料になります。 ## 中小企業向けAI面接ツールの選び方 AI面接ツールの比較記事の多くは、新卒で数百〜数千人の応募を捌く大企業を暗黙の前提にしています。しかし**月の面接件数が数件〜数十件の中小企業では、選定基準がまったく変わります**。 ### エンタープライズ型と中小企業向けの違い | 観点 | エンタープライズ型（大量採用前提） | 中小企業向け（少人数・兼務前提） | | 想定件数 | 月数百〜数千件の一括スクリーニング | 月数件〜数十件 | | 料金構造 | 年間契約・非公開価格・個別見積もりが中心 | 初期費用0円・低額月額または従量課金で始められることが重要 | | 導入・運用 | 導入プロジェクトを組み、専任担当者が運用 | 採用担当者が他業務と兼務。**1人で設定・運用が完結する操作性**が必須 | | 重視する機能 | 多言語対応・部門別カスタマイズ・分析ダッシュボード | 候補者がスマホだけで完結すること・質問テンプレートの充実・評価レポートが兼務担当者でも読める簡潔さ・応募への初動の速さ（自動案内・即時面談など） | | ATS連携 | API連携が前提 | ATS未導入でも使えること・URL連携で足りることが多い | ### 中小企業が押さえるべき4つの基準 ** 中小企業のAI面接ツール選定基準 - **初期費用0円・低額から始められるか**：導入効果を見極める前に大きな固定費を抱えない。従量課金または低額月額プランでスモールスタート - **担当者1人で運用が回るか**：質問テンプレートの充実度、評価レポートの読みやすさ、設定変更のしやすさ - **候補者がすぐ・簡単に受けられるか**：アプリ不要・スマホ対応・24時間受験可。中小企業の採用は応募者数が限られるため、**1人の離脱の重み**が大企業より大きい - **今の採用フローを変えずに組み込めるか**：求人媒体からのURL案内だけで運用できるか。ATSがなくても完結するか ありがちな失敗は、「機能が多いから」と大量採用向けの高機能プランを契約し、月に数件しか使わないまま年間契約だけが残るケースです。中小企業では**機能の多さよりも、使い切れる範囲の機能を低リスクで運用し続けられること**を優先するのが現実的です。 なお、この基準は弊社[SUGUMEN](https://technosphere.co.jp/sugumen)の設計方針でもあります。自社サービスなので割り引いて読んでいただきたいのですが、比較の一候補として後述します。 ## 比較表の中でのSUGUMENの位置づけ ※ここからは弊社サービスの紹介です。 弊社テクノスフィアが開発・提供する**AI面接サービス「[SUGUMEN（スグメン）](https://technosphere.co.jp/sugumen)」**は、上記の比較でいえば「中小企業でも低リスクで始められる、初期費用ゼロのクラウド型」に位置づけられるサービスです。 ** 比較表の項目に対応するSUGUMENの特徴 - **基本料を公開している対話型：**初期費用0円・月額2万円の基本料＋利用に応じた従量課金です。基本料を公式に明示している点で、料金非公開の対話型サービスより予算計画を立てやすい体系です（従量単価はお問い合わせください）。 - **応募後すぐに面談を開始できる：**応募から最短3分でAIが一次面談を開始し、24時間365日対応します。日程調整を挟まない分、応募から初回接触までが速くなります。 - **既存フローを変えない連携：**既存ATSとURL連携またはAPI接続で組み込めます。面談結果はスコアリングして採用判断を支援します。 候補者側はスマートフォン・PC・タブレットのブラウザだけで受験でき（アプリ不要）、所要時間は最短10〜15分、テキストと音声の両方に対応しています。詳しい機能は[SUGUMEN製品ページ](https://technosphere.co.jp/sugumen)を、実際の活用イメージは[SUGUMEN導入事例（小売業）](https://technosphere.co.jp/blog/sugumen-case-study-retail)をご覧ください。 ## AI面接ツール導入前チェックリスト 契約前に、以下を社内で確認しておくと導入後のミスマッチを防げます。ベンダーへの質問リストとしてもそのまま使えます。 ** 目的・機能 - AI面接を使う範囲を決めたか（一次スクリーニングのみか、評価の補助まで使うか） - 対話型・録画型のどちらが自社の職種・候補者層に合うか - 質問・評価基準を自社の採用要件に合わせてカスタマイズできるか ** 費用・契約 - 初期費用・月額・従量・オプションを含めた**年間総額**を試算したか - 最低契約期間・解約条件・件数超過時の単価を確認したか - 月間面接件数の見込みから、従量課金と定額制のどちらが得か計算したか ** 運用・連携 - 現在のATS・採用フローにどう組み込むか（API・URL連携・CSV）を決めたか - 評価レポートを誰がいつ確認し、次の選考につなぐかの運用フローを設計したか - 担当者が兼務でも運用が回る操作性か、無料トライアル・デモで確認したか ** セキュリティ・候補者対応 - データの保管場所・暗号化・削除ポリシー、認証取得状況（ISMS等）を確認したか - AI面接を選考に使うことを候補者にどう案内するか（利用目的の明示）を決めたか - 候補者側の受験環境（スマホ対応・アプリ不要・所要時間）を実際に試したか ## よくある質問 ### Q. 候補者にAI面接を嫌がられませんか？辞退率への影響は？ 候補者の一部にAI面接への抵抗感があるのは事実ですが、運用の工夫で影響を抑えられます。実務上のポイントは、**(1)応募時点でAI面接であることと所要時間を明示する、(2)スマートフォンだけで24時間好きな時間に受けられる手軽さをあわせて案内する、(3)AIの評価だけで不合格を確定させず人の確認を挟む運用であることを伝える**、の3点です。一方で、日程調整の往復がなくなることで応募から初回接触までが速くなり、連絡がつかないまま選考から離脱するケースを減らせる面もあります。 ### Q. AIの評価だけで合否を決めてよいですか？ 推奨されません。AIの評価は**一次スクリーニングの参考情報**として扱い、**最終的な合否判断は人が行う**運用が一般的です。評価レポートやスコアは面接内容の要約・絞り込みに使い、不合格の最終確定や合格ラインの設定には人のレビューを挟む設計にしておくと、候補者への説明責任の面でも安全です。 ### Q. 無料トライアルはありますか？ 多くのサービスが無料トライアル・無料デモ・お試しプランのいずれかを提供しています（比較表参照）。契約前に必ず、候補者視点の受験体験と管理側の評価レポートの両方を確認することをおすすめします。 ### Q. 中小企業にはどんなAI面接ツールが向いていますか？ 初期費用ゼロで低額から始められ、担当者1人でも運用が回るサービスが向いています。大量採用前提のエンタープライズ型は多機能ですが、初期設定や運用の負荷が兼務の担当者には重くなりがちです。詳しくは「中小企業向けAI面接ツールの選び方」をご覧ください。 ## まとめ ** この記事のまとめ - AI面接ツールの費用は「初期費用＋月額固定 or 従量課金＋オプション」の構造で見る。公開価格ベースの相場は、従量1面接1,000〜5,000円程度、月額定額2万円台〜10万円前後、初期費用0円〜数十万円（2026年7月時点）。 - 月額固定と従量課金の分岐点は「月間面接件数×従量単価」で試算する。件数が読めないうちは初期費用ゼロ・低額プランでのスモールスタートが安全。 - 中小企業は機能の多さより「初期費用0円・兼務でも回る操作性・候補者がすぐ受けられること・既存フローを変えない連携」を優先する。 「自社の採用件数だと結局いくらになるのか」「今の採用フローにどう組み込めばいいか」など、具体的なご相談は[お気軽にお問い合わせください](https://technosphere.co.jp/contact)。御社の採用課題をヒアリングしたうえで、最適な進め方をご提案します。 ／AI面接サービスの導入相談はこちら＼ ### AI面接サービス「SUGUMEN」 初期費用ゼロ・月額2万円の基本料＋従量課金のクラウド型AI面接サービス。応募から最短3分でAIが一次面談を開始し、24時間365日自動対応。ATS連携・自動スコアリングまで、採用業務の効率化を一気通貫で支援します。中小企業から大手まで規模を問わず導入可能。 [SUGUMENを見る](https://technosphere.co.jp/sugumen) [AI面接の導入を相談する](https://technosphere.co.jp/contact) [# AI面接](https://technosphere.co.jp/blog/) [# 採用DX](https://technosphere.co.jp/blog/) [# HR Tech](https://technosphere.co.jp/blog/) [# 面接自動化](https://technosphere.co.jp/blog/) [# SUGUMEN](https://technosphere.co.jp/blog/) ** この記事をシェア [X](https://twitter.com/intent/tweet?url=https://technosphere.co.jp/blog/ai-interview-tools-comparison&text=AI面接ツール比較【2026年版】｜費用相場と中小企業向けの選び方&via=technosphere_co) [Facebook](https://www.facebook.com/sharer/sharer.php?u=https://technosphere.co.jp/blog/ai-interview-tools-comparison) [LINE](https://social-plugins.line.me/lineit/share?url=https://technosphere.co.jp/blog/ai-interview-tools-comparison) --- # AIで手順書を自動生成する仕組み｜画面操作の記録からマニュアルを作る技術解説【FlowLens開発記】｜テクノスフィア > 「操作するだけで手順書ができる」をどう実装するか。Windowsの画面操作をイベント駆動でキャプチャし、Vision対応LLM（Claude）で解析してスクリーンショット付き手順書を自動生成する、自社製品FlowLensのアーキテクチャを開発チームが解説。キャプチャ方式の比較、プライバシー設計、2段LLMパイプラインのコスト最適化、中間表現JSONまで。 URL: https://technosphere.co.jp/blog/ai-manual-auto-generation 「手順書を作る時間がなくて、結局作られない」「システム更新のたびにマニュアルだけが古くなる」——どの現場でも聞く悩みです。弊社ではこの問題に対して、**普段のPC操作をそのまま記録し、生成AIがスクリーンショット付きの手順書に変換する**という自社製品「FlowLens（フローレンズ）」を開発しています。 本記事では、その開発の裏側を技術者向けに解説します。画面キャプチャ方式の設計判断、プライバシー保護の実装方針、Vision対応LLMのコスト最適化、そして出力を支える中間表現の設計まで、実際の技術検討の内容をベースにお届けします。 ** FlowLensが**製品として何を解決するのか**（できること・想定ユースケース・先行モニター募集）は、[FlowLens 製品ページ](https://technosphere.co.jp/flowlens)にまとめています。本記事は実装技術にフォーカスします。 ## 全体アーキテクチャ FlowLensは大きく3つのコンポーネントで構成されます。 ``` [Windows クライアント (常駐エージェント)] ├─ 画面キャプチャ（操作イベント駆動 + 周期スクリーンショット） ├─ UI イベントフック（クリック / キー入力 / ウィンドウ遷移） └─ ローカルバッファ → 解析サーバへ送信 │ ▼ [解析サーバ (Docker)] ├─ Vision 対応 LLM による画面・操作解析 ├─ 操作シーケンスの構造化（アプリ / 画面 / アクション） ├─ 手順書ジェネレータ（Markdown / docx 出力） └─ 最適化アドバイザ（操作パターン分析 → 改善提案） │ ▼ [Web UI] ├─ 記録セッション一覧・手順書プレビュー / 編集 └─ 改善提案レポート ``` 設計上のポイントは2つあります。1つは**クライアントを「記録に徹する軽量エージェント」に絞り、解析をすべてサーバ側に寄せた**こと。ユーザーのPCに負荷をかけず、AIモデルの差し替えや改善をサーバ側だけで完結できます。もう1つは解析サーバを**Dockerコンテナ**として構成したこと。クラウドにも顧客の社内サーバ（オンプレミス）にも同じ構成で展開でき、「画面データを社外に出せない」という要件に最初から備えています。 ## 画面キャプチャ方式の設計判断 「操作を記録する」と一口に言っても、実装方式はいくつかあります。検討した3方式の比較です。 | 方式 | 概要 | 長所 | 短所 | | **A. 周期スクリーンショット** | 1〜2秒間隔で画面全体をキャプチャ | 実装が単純、取りこぼしがない | データ量が膨大、操作との対応付けが弱い、AI解析コスト増 | | **B. UIイベントフック** | クリック・キー入力・ウィンドウ遷移の発生時のみ記録 | データ量が少ない、「どのボタンを押したか」の意味情報が取れる | フック実装の難易度、UIA情報が取れないアプリがある | | **C. 併用（イベント駆動キャプチャ）** | イベント発生時にスクリーンショット + UI要素情報を取得し、低頻度の周期キャプチャで補完 | 手順書生成に最適な「操作と画面のペア」が得られる | 実装量は最大 | FlowLensは**C. 併用方式**を採用しました。手順書とは本質的に「操作 → 画面変化」の系列なので、**操作イベントを主キーにして画面を従属させる**データ構造が最も適しています。周期キャプチャだけでは「なぜ画面が変わったのか」が失われ、後段のAIに推測を強いることになります。 ### Windows APIの選定 実装に使うWindows API / ライブラリは役割ごとに次の通りです。 - **入力イベントフック**：`SetWindowsHookEx`（WH_MOUSE_LL / WH_KEYBOARD_LL）。PoCではPythonの`pynput` - **ウィンドウ遷移の検出**：`SetWinEventHook`（EVENT_SYSTEM_FOREGROUND等） - **UI要素情報**：UI Automation（UIA）。クリック座標から要素のName / ControlType / ウィンドウ階層を逆引き。PoCでは`uiautomation` / `pywinauto` - **スクリーンショット**：Windows.Graphics.Capture / DXGI Desktop Duplication。PoCでは`mss`。マルチモニタとDPIスケーリング（125%〜200%）への対応が必須 ポイント：** 検証速度を優先し、PoCはPython（pynput + uiautomation + mss）で構築。製品版クライアントは、UIAとWindows.Graphics.Captureのネイティブサポート、常駐サービス化と配布（MSIX）の容易さから**C#（.NET）を第一候補**にしています。RDPや一部Electron・Java SwingなどUIAが効かないアプリは、周期キャプチャ + Vision LLM解析でフォールバックします。 ## プライバシー設計は「後付け」にしない 画面操作の記録ツールで最初に設計すべきは、実は記録機能ではなく**「記録しない」仕組み**です。FlowLensでは以下を必須要件としてクライアント側に組み込んでいます。 1. **パスワードフィールド検出**：UIAの`IsPassword`プロパティを持つ要素へのフォーカス中は、スクリーンショットとキー入力記録を停止 2. **打鍵内容は保存しない**：既定では「テキストを入力した」というイベントと、入力後の画面上の表示のみを記録 3. **対象アプリのオプトイン**：記録対象を業務アプリのホワイトリストに限定。既定は「記録しない」 4. **送信前マスキング**：解析サーバへ送る前にクライアント側で機密領域をマスク。将来はOCRベースのPII検出を予定 特に2番目は重要です。手順書に必要なのは「顧客コードを*入力した*」という事実と入力後の画面であって、打鍵の生ログではありません。**要件を分解すると「記録しなくていいもの」が明確になる**——監視ツールと業務改善ツールを分ける、設計上の分水嶺だと考えています。 ## Vision LLMパイプラインとコスト最適化 記録したスクリーンショットと操作イベントの解析には、画像を理解できるVision対応LLMとして**Claude API**を採用しました。日本語UIを含むスクリーンショットの理解精度と、高解像度画像で座標が実ピクセルと1:1対応する点（UI要素の位置特定に有利）が決め手です。 ただし1回の記録セッションで画像は数十〜数百枚になるため、全部を高品質モデルに投げるとコストが成立しません。そこで**2段構成のパイプライン**にしています。 ``` [大量スクリーンショット] │ ① 小型モデル（Claude Haiku 4.5）: │ 画面の分類・重複除去・無意味フレームの間引き（安価・高速） ▼ [キーフレーム + 操作イベント] │ ② 高品質モデル（Claude Opus 4.8）: │ 操作シーケンスの構造化・手順書生成・改善提案 ▼ [手順書 / 改善レポート] ``` さらに2つのAPI機能を前提に設計しています。 - **Batch API**：手順書生成はリアルタイム性が不要なため、非同期バッチ処理（料金50%オフ）を基本とする - **Prompt Caching**：手順書フォーマット定義などのシステムプロンプトをキャッシュし、繰り返し入力分のコストを大幅に圧縮 ** コスト試算（1セッション＝100操作・キーフレーム100枚の場合） - ① 前段フィルタ（小型モデル・Batch適用）：約 **$0.10** - ② 手順書生成（高品質モデル・Batch適用）：約 **$0.75** - → 合計**1セッションあたり$1前後（150円程度）**。製品原価として成立する水準（2026年6月時点の料金で試算） なお、解析層はLLMプロバイダを差し替え可能な抽象化を入れています。データを一切外に出せない顧客向けには、オンプレGPUでのローカルVLM（オープンモデル）への切り替えを将来の選択肢として確保しています。まずはクラウドAPIで品質を確立するのが現在のフェーズです。 ## 中間表現JSON——出力形式を増やすための土台 FlowLensの内部では、キャプチャした操作も生成した手順も、すべて**JSONの中間表現**を正規形として扱います。クライアントが送る操作イベントはこんな形です。 ``` { "session_id": "uuid", "seq": 42, "timestamp": "2026-07-17T10:23:45+09:00", "event": { "type": "click", // click | input | key | window_change | scroll "app": "EXCEL.EXE", "window_title": "見積書.xlsx - Excel", "element": { // UIAで取得（取れない場合はnull → Vision LLMが補完） "name": "保存", "control_type": "Button", "path": ["リボン", "ホーム", "保存"] }, "position": { "x": 120, "y": 48, "monitor": 0 } }, "screenshot": "042.png" // イベント直前のフレーム } ``` 解析サーバが出力する「手順ステップ」も同様に正規形を定義しています。 ``` { "step": 3, "title": "見積書を保存する", "description": "リボンの [保存] ボタンをクリックします。", "app": "Excel", "screenshot": { "image": "042.png", "annotation": { "type": "rect", "x": 100, "y": 30, "w": 60, "h": 40 } }, "source_events": [41, 42], "notes": ["Ctrl+S で代替可能"] // 最適化提案 } ``` 手順書はこの正規形からレンダリングして生成します。この分離のおかげで、**出力形式の追加が「テンプレートを1枚増やす」だけ**で済みます。 | 優先 | 出力形式 | 生成方法 | | 1 | Markdown + 画像 | テンプレートレンダリング。Git管理・差分レビューが可能 | | 2 | 社内Wiki（Growi） | REST APIで直接投稿。記録→Wiki反映まで自動化 | | 3 | Word（docx） | pandoc変換を第一候補。体裁要件が厳しい場合はpython-docxでテンプレート化 | | 4 | PDF | Markdown → HTML → headless Chrome印刷 | スクリーンショットへの注釈（クリック位置の枠や番号バッジ）はPillowで焼き込みますが、**注釈情報そのものは正規形に保持**します。画像を作り直さずに再レンダリングでき、マスキング領域も同じ仕組みで出力時に再適用できます。 ## 手順書の先へ——操作の最適化提案 中間表現には、もう1つの狙いがあります。操作イベントが構造化データとして蓄積されるため、**操作パターンの分析がそのまま業務改善の材料になる**のです。 - マウス操作の系列から、ショートカットや標準機能で置き換えられる操作を検出（例：メニュー3クリック → Ctrl+S） - 同一セッション内・セッション間の繰り返しパターンから、無意味な往復や遠回りの操作列を発見 - 毎日発生する定型作業を、自動化（RPA化・スクリプト化）の候補としてレポート 「手順書を作る」がゴールではなく、**記録された操作ログから手順そのものを良くしていく**——ここがFlowLensで一番作りたい部分です。 ## よくある質問（FAQ） ### キー入力（打鍵内容）まで記録されるのですか？ いいえ。既定で打鍵内容は保存せず、「テキストを入力した」というイベントと入力後の画面表示のみを記録します。さらにUIAの`IsPassword`プロパティを監視し、パスワード欄へのフォーカス中は記録自体を停止します。 ### UI要素の情報が取れないアプリでも手順書を作れますか？ リモートデスクトップや一部の描画系アプリなどUIAが効かない画面では、低頻度の周期スクリーンショットで補完し、Vision LLMが画像から操作コンテキストを推定するフォールバック設計にしています。 ### AIの解析コストはどのくらいかかりますか？ 前段フィルタ＋高品質モデルの2段構成にBatch APIとPrompt Cachingを組み合わせ、100操作程度のセッション1回あたり**$1前後（150円程度）**の試算です（2026年6月時点の料金）。 ### 画面データを社外に出せない環境でも使えますか？ 解析サーバはDockerコンテナとして社内（オンプレミス）にも構築できます。LLM層は差し替え可能な抽象化を入れており、完全閉域向けにローカルVLMへの切り替えも視野に入れています。 ## まとめと現在地 ** この記事のまとめ - 手順書の自動生成は「イベント駆動キャプチャ + 周期補完」で、操作と画面のペアを主キーにするのが本質 - プライバシーは後付けせず、パスワード検出・打鍵非保存・オプトインをクライアント設計に組み込む - Vision LLMは小型モデル前段＋高品質モデル本解析の2段構成。Batch + Cachingで1セッション$1前後に - JSON中間表現を正規形にすれば、Markdown / Wiki / docx / PDFへの出力追加はテンプレート1枚で済む FlowLensは現在、キャプチャPoCと解析エンジンのコア開発を進めている段階です。実際の業務での検証にご協力いただける**先行モニター企業さまを募集**しています。この記事のアーキテクチャに興味を持たれた方も、「うちの手順書問題を何とかしたい」という方も、ぜひ製品ページをご覧ください。 ／この記事で解説した自社プロダクト＼ ### FlowLens（フローレンズ）— 操作を記録するだけで、AIが手順書をつくる いつも通りPCを操作するだけで、スクリーンショット付きの手順書と操作の改善提案が手に入ります。現在PoC開発中。一緒に育ててくださる先行モニター企業さまを数社限定で募集しています。 [FlowLens 製品ページを見る](https://technosphere.co.jp/flowlens) [先行モニターについて相談する](https://technosphere.co.jp/contact) [# FlowLens](https://technosphere.co.jp/blog/) [# 手順書自動生成](https://technosphere.co.jp/blog/) [# Vision LLM](https://technosphere.co.jp/blog/) [# Claude API](https://technosphere.co.jp/blog/) [# 業務改善](https://technosphere.co.jp/blog/) ** この記事をシェア [X](https://twitter.com/intent/tweet?url=https://technosphere.co.jp/blog/ai-manual-auto-generation&text=AIで手順書を自動生成する仕組み｜画面操作の記録からマニュアルを作る技術解説&via=technosphere_co) [Facebook](https://www.facebook.com/sharer/sharer.php?u=https://technosphere.co.jp/blog/ai-manual-auto-generation) [LINE](https://social-plugins.line.me/lineit/share?url=https://technosphere.co.jp/blog/ai-manual-auto-generation) --- # 危険予知・労働安全AI｜危険区域侵入・ヒヤリハットをAIで検知｜テクノスフィア > AIカメラで危険区域への侵入、保護具の未着用、重機への接近などを検知する「労働安全AI」を解説。建設・製造現場の事故防止に向けた仕組み、検知できる項目、導入の進め方、現場AI「GENBA IQ」の活用までを大阪のテクノスフィアが紹介します。 URL: https://technosphere.co.jp/blog/ai-safety-hazard-detection 建設・製造の現場では、重大事故の多くが「危険区域への立ち入り」「保護具の未着用」「重機への接近」といった、**事前に気づければ防げた**状況から発生します。本記事では、AIカメラがこうした危険をリアルタイムに検知して警告する「労働安全AI（危険予知AI）」の仕組みと導入方法を解説します。 （図: 建設・工場現場でAIが危険区域侵入や保護具未着用を検知するイメージ） この記事の要点：** 労働安全AIは、危険区域侵入・保護具未着用・重機接近などを**事故が起きる前に検知して警告**。既存カメラを活かして導入でき、現場の安全ルールに合わせて検知項目を設計します。 ## 現場の労働災害という課題 安全教育やKY活動（危険予知活動）を徹底しても、人の注意力には限界があり、慣れや繁忙による「うっかり」をゼロにはできません。監督者が全エリア・全時間を見張ることも不可能です。**人の監視を補完し、危険を機械的に検知し続ける仕組み**が求められています。 ## 労働安全AI（危険予知AI）とは 労働安全AIは、カメラ映像をAIが解析し、事故につながる状況を検知して**その場で警告（アラート・音声・回転灯など）**する仕組みです。事後の原因究明ではなく、**事故が起きる前の介入**を目的とします。 （図: 工場フロアでAIが危険区域侵入・保護具未着用・重機接近を検知する仕組みのイメージ） AIが現場の危険状況を検知し、リアルタイムに警告する ## 検知できる項目（例） - **危険区域・立入禁止エリアへの侵入**：仮想ラインを越えた立ち入りを検知。 - **保護具の未着用**：ヘルメット・安全帯・反射ベストなどの装着確認。 - **重機・車両への接近**：フォークリフトや重機と人の接近・接触リスクを検知。 - **転倒・滞留**：人の転倒や、危険箇所での不自然な滞留を検知。 検知項目は現場の安全基準に合わせて設計します。すべてを一度に導入せず、**優先度の高い項目からPoCで検証**するのが現実的です。 ## 導入のメリット - **事故の未然防止**：危険状態をその場で警告し、災害発生を抑止。 - **監督業務の補完**：24時間・全エリアの監視をAIが補助。 - **安全文化の定着**：検知データで危険傾向を可視化し、改善活動に活用。 - **記録・報告の効率化**：ヒヤリハットの記録・分析を自動化。 ## 導入の進め方 1. **危険要因の整理**：現場の事故・ヒヤリハット事例から検知すべき項目を特定。 2. **PoC**：既存カメラ映像で対象項目の検知精度・警告運用を検証。 3. **調整**：誤検知を抑えつつ、見逃しを減らすチューニング。 4. **本番運用**：警告手段（回転灯・音声・通知）と記録運用を整備して展開。 ## よくある質問（FAQ） Q. 労働安全AIとは？ カメラ映像をAIが解析し、危険区域侵入・保護具未着用・重機接近などを検知して、事故が起きる前に警告する仕組みです。 Q. どんな項目を検知できますか？ 立入禁止エリアへの侵入、保護具の未着用、重機・車両への接近、転倒・滞留などを、現場の安全ルールに合わせて設計できます。 Q. 既存カメラで導入できますか？ 多くの場合、既存カメラ映像を活用できます。死角や検知範囲に応じてカメラ追加・位置調整を行い、エッジ処理構成も可能です。 Q. 建設以外でも使えますか？ 製造工場・物流倉庫・プラントなど、重機や立入禁止区域がある現場全般で活用できます。 ## まとめ ** この記事のまとめ - 労働安全AIは危険区域侵入・保護具未着用・重機接近などを事故前に検知・警告する。 - 既存カメラを活かし、優先度の高い項目からPoCで検証して導入できる。 - 検知データは安全活動の改善・ヒヤリハット記録にも活用できる。 現場の安全管理のAI活用をご検討の方は、ぜひ[お気軽にお問い合わせください](https://technosphere.co.jp/contact)。危険要因の整理からPoCまでご支援します。 ／現場AIで安全管理＼ ### 現場を理解するAI「GENBA IQ」 危険区域侵入・保護具未着用・重機接近などをリアルタイムに検知。映像・音声・センサーを統合し、現場全体の安全管理を支援します。既存カメラを活かしたPoCから対応。 [GENBA IQを見る](https://technosphere.co.jp/genba-iq) [安全AIを相談する](https://technosphere.co.jp/contact) [# 危険予知](https://technosphere.co.jp/blog/)[# 労働安全](https://technosphere.co.jp/blog/)[# ヒヤリハット](https://technosphere.co.jp/blog/)[# 建設DX](https://technosphere.co.jp/blog/)[# GENBA IQ](https://technosphere.co.jp/blog/) ** この記事をシェア [X](https://twitter.com/intent/tweet?url=https://technosphere.co.jp/blog/ai-safety-hazard-detection&text=危険予知・労働安全AI｜危険区域侵入・ヒヤリハットをAIで検知&via=technosphere_co) [Facebook](https://www.facebook.com/sharer/sharer.php?u=https://technosphere.co.jp/blog/ai-safety-hazard-detection) [LINE](https://social-plugins.line.me/lineit/share?url=https://technosphere.co.jp/blog/ai-safety-hazard-detection) --- # 万引き検知AI｜AIカメラで不審行動を検知する仕組みと小売の防犯DX｜テクノスフィア > AIカメラで万引きや不審行動を検知する仕組みを解説。従来の防犯カメラとの違い、行動解析の考え方、導入の進め方、プライバシーへの配慮、現場AI「GENBA IQ」の活用までを、大阪のテクノスフィアが実務目線で紹介します。 URL: https://technosphere.co.jp/blog/ai-shoplifting-detection 小売・流通の現場では、万引きによるロス（棚卸資産の損失）と人手不足が深刻な課題です。本記事では、防犯カメラの映像をAIが解析して**不審行動をリアルタイムに検知**する「万引き検知AI」の仕組みと、導入の進め方、プライバシーへの配慮までを実務目線で解説します。 （図: AIカメラが店内の人物の行動を検知する万引き検知AIのイメージ） この記事の要点：** 万引き検知AIは「人物の特定」ではなく「**行動**」を見て検知するのが基本。既存カメラを活かして**リアルタイム通知**で発生を抑止し、プライバシーは技術と運用の両面で配慮できます。同じカメラ基盤で見守り・混雑把握など多目的に展開可能です。 ## 小売の万引き・ロスの課題 従来の防犯カメラは「録画して、何かあった後に見返す」事後確認が中心でした。しかし実際には、**その場で気づけなければ被害は止められません**。人手で全カメラを常時監視するのは現実的でなく、店員は接客・品出しで手一杯です。結果として、万引きの多くは見逃され、ロス率の改善につながりにくいのが実情です。 ## 万引き検知AIとは？従来カメラとの違い 万引き検知AIは、カメラ映像をAIが解析し、**リスクの高い「行動」を検知して即座に通知**する仕組みです。たとえば次のような場面を捉えます。 - 商品を手に取り、カバンや衣服に隠すような動作 - 棚の前での不自然に長い滞留・周囲を気にする挙動 - 死角への移動や、特定エリアでの繰り返し行動 重要なのは、**個人を特定するのではなく「行動」を見る**という考え方です。これによりプライバシーに配慮しながら、リアルタイムの気づき（抑止）を実現します。 （図: 防犯カメラとAIが連携し人物の行動を解析する仕組みのイメージ） カメラ映像をAIが行動解析し、リスクの高い場面を検知・通知する ## 導入のメリット - **抑止効果**：リアルタイム通知で発生中に対応でき、被害そのものを抑止。 - **省人化**：常時監視の負担を減らし、店員を接客に集中させられる。 - **データ活用**：検知傾向を分析し、レイアウトや人員配置の改善に活用。 - **多目的化**：同じカメラで見守り・混雑把握・接客機会検知などへ展開。 ## 導入の進め方 1. **課題・運用ヒアリング**：対象店舗、通知方法（店内端末・スマホ等）、運用体制を整理。 2. **PoC（実現性検証）**：既存カメラ映像で検知精度と運用負荷を検証。 3. **精度・通知の調整**：誤検知を抑えつつ、見逃しを減らすバランスを調整。 4. **本番運用**：店舗展開、通知フロー・記録運用の整備。 ## プライバシーへの配慮 防犯用途では、プライバシーへの配慮が欠かせません。**個人特定ではなく行動を検知する**設計、映像を店舗内（エッジ）で処理して外部送信を最小化する構成、保存範囲・保持期間の限定、掲示による告知など、技術と運用の両面で適切に設計します。 ## よくある質問（FAQ） Q. 万引き検知AIとは？ カメラ映像をAIが解析し、隠す動作や不自然な滞留などの行動からリスクの高い場面を検知して通知する仕組みです。録画を見返す従来カメラと違い、リアルタイムに気づけます。 Q. 既存の防犯カメラは使えますか？ 多くの場合、既存のネットワークカメラ映像を活用できます。まず現状映像で精度を検証し、必要に応じて画角を調整します。 Q. プライバシーは大丈夫ですか？ 個人特定ではなく行動を検知する設計、エッジ処理、保存範囲の限定など、技術と運用の両面で配慮した構成が可能です。 Q. 万引き以外にも使えますか？ 滞留検知・見守り・混雑把握・接客機会検知など、同じカメラ基盤で多目的に展開できます。 ## まとめ ** この記事のまとめ - 万引き検知AIは「行動」を見てリアルタイムに検知・通知し、被害を抑止する。 - 既存カメラを活かしPoCから始められ、プライバシーは技術・運用で配慮できる。 - 同じ基盤で見守りや混雑把握など多目的に展開できる。 店舗の防犯・ロス対策のAI活用をご検討の方は、ぜひ[お気軽にお問い合わせください](https://technosphere.co.jp/contact)。既存カメラを活かしたPoCからご提案します。 ／現場AIで防犯・ロス対策＼ ### 現場を理解するAI「GENBA IQ」 映像・音声・センサーを統合し、万引き検知・見守り・混雑把握などを一つの基盤で実現。既存カメラを活かしたPoCから本番運用まで対応します。 [GENBA IQを見る](https://technosphere.co.jp/genba-iq) [防犯AIを相談する](https://technosphere.co.jp/contact) [# 万引き検知](https://technosphere.co.jp/blog/) [# AIカメラ](https://technosphere.co.jp/blog/) [# 防犯DX](https://technosphere.co.jp/blog/) [# 小売](https://technosphere.co.jp/blog/) [# GENBA IQ](https://technosphere.co.jp/blog/) ** この記事をシェア [X](https://twitter.com/intent/tweet?url=https://technosphere.co.jp/blog/ai-shoplifting-detection&text=万引き検知AI｜AIカメラで不審行動を検知する仕組みと防犯DX&via=technosphere_co) [Facebook](https://www.facebook.com/sharer/sharer.php?u=https://technosphere.co.jp/blog/ai-shoplifting-detection) [LINE](https://social-plugins.line.me/lineit/share?url=https://technosphere.co.jp/blog/ai-shoplifting-detection) --- # 外観検査AI（画像検査）導入ガイド｜費用・進め方・事例｜テクノスフィア > 製造業の外観検査をAI（画像認識）で自動化する導入ガイド。費用の考え方と目安、PoCから本番までの進め方、キズ・汚れ・欠品・印字検査などの事例、既存カメラを活かすポイントまで、大阪のテクノスフィアが実務目線で解説します。 URL: https://technosphere.co.jp/blog/ai-visual-inspection-guide 製造現場の人手不足と品質要求の高まりを背景に、目視に頼っていた外観検査を**AI（画像認識）で自動化**する動きが加速しています。本記事では、外観検査AIの基本から**費用の考え方・導入の進め方・具体的な事例**、そして失敗しないためのポイントまで、受託開発の実務目線で整理します。 この記事の要点：** 外観検査AIは「良品・不良品の画像を学習させて自動判定する」仕組み。**既存カメラを活かして小さくPoCから始められ**、見逃しゼロと過検出抑制のバランス設計が鍵。費用は対象・精度要件で変動するため、まずは小規模検証で効果を見極めるのが定石です。 ## 外観検査AIとは？目視検査との違い 外観検査AIとは、製品や部品をカメラで撮影し、その画像をAIが解析して**良品／不良品を自動判定**する仕組みです。従来の検査方法には次のような課題がありました。 - **目視検査**：検査員の熟練度や体調で判定がばらつき、人手と教育コストがかかる。見逃しのリスクも残る。 - **ルールベースの画像処理**：寸法や色など「数値で定義できる不良」は得意だが、微細なキズ・汚れ・自然物のばらつきなど「定義しづらい不良」は苦手。 これに対し、ディープラーニングを用いた外観検査AIは、**良品と不良品の画像を学習**することで、人が言葉で定義しにくい不良も判定できます。安定した基準で24時間検査でき、判定結果をデータとして蓄積・活用できる点も大きな利点です。 ## 外観検査AI導入のメリット - **品質の安定化**：人によるばらつきをなくし、一定基準で判定。見逃し（不良流出）の低減。 - **省人化・生産性向上**：検査工程の人員を削減し、付加価値の高い工程へ再配置。 - **トレーサビリティ**：検査画像・判定結果を記録し、不良傾向の分析や工程改善に活用。 - **属人化の解消**：熟練検査員の判断基準をAIに引き継ぎ、技能伝承の課題を緩和。 ## 費用の考え方と目安 外観検査AIの費用は「パッケージ一律」ではなく、次の要素で変動します。見積もりを正しく比較するために、まずは構成要素を理解しておくことが重要です。 1. **検査対象と不良の難易度**：対象の種類数、不良の種類（キズ／汚れ／欠け／異物／印字など）と見え方の難しさ。 2. **要求精度・処理速度**：許容できる見逃し率・過検出率、ライン速度（タクトタイム）への追従。 3. **撮影環境**：既存カメラ・照明・治具を流用できるか、新規に最適化が必要か。 4. **システム連携**：PLC・既存ライン・MES等との連携、合否信号やデータ保存の要件。 5. **運用・保守**：再学習の運用、品種追加への対応、現場での運用サポート。 目安：** 小規模な**PoC（実現性検証）は数十万円規模から**着手でき、本番ラインへの組込みは対象範囲・精度要件・設備連携により変動します。最初から大きく投資せず、**PoCで効果を確認してから本番化**するのが、コストとリスクを抑える定石です。正確な費用はお見積もりでご案内します。 ## 導入の進め方（PoCから本番まで） 1. **課題ヒアリング・要件整理**：検査対象、現状の不良、判定基準、ライン条件を整理。 2. **画像収集・PoC**：良品・不良品の画像を収集し、小規模に試作して到達精度を検証。費用対効果を判断。 3. **精度チューニング**：照明・撮影条件の最適化、学習データの追加で見逃し・過検出を調整。 4. **本番システム構築**：ライン組込み、設備連携、合否判定・データ保存・アラートの実装。 5. **運用・再学習**：品種追加や経時変化に合わせて再学習し、精度を維持。 ポイントは**「小さく始めて検証する」**こと。実際の画像でPoCを行えば、導入前に効果と費用感を見極められます。 ## 外観検査AIの適用事例 外観検査AIは、業種・対象を問わず幅広く適用できます。代表的な検査対象の例を挙げます。 - **キズ・打痕・へこみ**：金属・樹脂部品の表面欠陥検出。 - **汚れ・異物・付着**：食品・包装・電子部品への異物混入や汚れの検知。 - **欠品・組付け不良**：部品の有無・向き・組付け状態の確認。 - **印字・ラベル検査**：印字のかすれ・欠け・誤り、ラベルの貼付位置のチェック。 - **形状・寸法のばらつき**：自然物や成形品など、個体差のある対象の良否判定。 弊社では、画像認識AIや[現場向けエッジAIプラットフォーム「GENBA IQ」](https://technosphere.co.jp/genba-iq)を活用し、製造現場の検査・監視を支援しています。映像・センサー情報を統合して現場をリアルタイムに把握する用途にも対応します。 ## 失敗しないための導入ポイント - **不良画像をいかに集めるか**：不良は発生頻度が低く、学習データ確保が最大の課題。データ拡張や運用での蓄積を計画する。 - **「見逃しゼロ」と「過検出抑制」のバランス**：流出を防ぎつつ、過検出で歩留まりを落とさない設計が重要。 - **撮影環境の安定化**：照明・カメラ条件の固定が精度を大きく左右する。AI以前の「撮り方」が肝心。 - **運用・再学習を見据える**：品種追加や経時変化に対応できる運用体制まで含めて設計する。 - **既存設備の活用**：既存カメラ・治具を活かして初期投資を抑え、まずはPoCで検証する。 ## よくある質問（FAQ） Q. 外観検査AIとは何ですか？ 製品の画像をカメラで撮影し、AIが良品・不良品を自動判定する仕組みです。良品・不良品の画像を学習させることで、目視やルールベースでは難しい「定義しづらい不良」も判定できます。 Q. 既存のカメラや検査設備は流用できますか？ 多くの場合、既存の産業用カメラ・照明・治具を活かして導入できます。まず現状環境の画像で精度を検証し、必要に応じて撮影条件を最適化します。 Q. 導入費用の目安は？ 検査対象・不良の難易度・要求精度・設備連携により変動します。小規模PoCは数十万円規模から着手でき、本番は要件次第です。まず小さく検証してから本番投資する進め方を推奨しています。正確な費用は無料お見積もりで。 Q. どのくらいの精度が出ますか？ 対象・不良の種類・学習データ次第で一律には言えません。実運用では見逃しを抑えつつ過検出を許容範囲に収めるバランス設計が重要で、PoCで実画像を使い到達精度を見極めます。 ## まとめ ** この記事のまとめ - 外観検査AIは良品・不良品の画像を学習し、目視やルールベースでは難しい不良も自動判定できる。 - 費用は対象・精度・設備連携で変動。PoCから小さく始め、効果を確認して本番化するのが定石。 - 成功の鍵は不良データの確保、見逃しと過検出のバランス、撮影環境の安定化、運用・再学習の設計。 外観検査の自動化をご検討中の方は、ぜひ[お気軽にお問い合わせください](https://technosphere.co.jp/contact)。検査対象や現状の課題をヒアリングのうえ、PoCから無理なく始められるご提案をします。 ／外観検査AIの受託開発・PoC相談はこちら＼ ### 画像認識・外観検査AIの受託開発 キズ・汚れ・欠品・印字検査など、製造現場の外観検査をAIで自動化します。既存カメラを活かしたPoCから本番ライン組込みまで一気通貫で対応。 [画像認識システムを見る](https://technosphere.co.jp/vision-system) [外観検査AIの導入を相談する](https://technosphere.co.jp/contact) [# 外観検査](https://technosphere.co.jp/blog/) [# 画像認識AI](https://technosphere.co.jp/blog/) [# 不良検知](https://technosphere.co.jp/blog/) [# 製造業DX](https://technosphere.co.jp/blog/) [# PoC](https://technosphere.co.jp/blog/) ** この記事をシェア [X](https://twitter.com/intent/tweet?url=https://technosphere.co.jp/blog/ai-visual-inspection-guide&text=外観検査AI（画像検査）導入ガイド｜費用・進め方・事例&via=technosphere_co) [Facebook](https://www.facebook.com/sharer/sharer.php?u=https://technosphere.co.jp/blog/ai-visual-inspection-guide) [LINE](https://social-plugins.line.me/lineit/share?url=https://technosphere.co.jp/blog/ai-visual-inspection-guide) --- # AR家具配置アプリの仕組み｜カメラ映像に実寸大の家具を置く技術をわかりやすく解説｜テクノスフィア > スマホのカメラで部屋を映すと実寸大の家具が画面に現れる——AR家具配置アプリ（iOS/Android）の仕組みを開発者が解説。家具の3Dモデルをどう用意するか（モデリング・フォトグラメトリ・CAD変換）、平面検出・アンカー・オクルージョンなどARKit/ARCoreの技術を、実際の開発で気をつけた点とあわせて紹介します。 URL: https://technosphere.co.jp/blog/ar-furniture-placement-app ** 目次 1. どんなアプリか 2. 「画像の合成」ではなく「3D空間への配置」 3. スマホが部屋を理解する3つの技術 4. 家具の「画像」はどう用意するのか 5. 「本当に置いてある」ように見せる技術 6. iOSとAndroidでどう作るか 7. 実際の開発で気をつけたこと 8. よくある質問（FAQ） 9. まとめ ## どんなアプリか 「このソファ、うちのリビングに置けるかな？ 部屋に合うかな？」——家具選びの一番の不安は、**買う前に部屋に置いた姿を確かめられない**ことです。 AR（拡張現実）家具配置アプリは、この不安を解消します。スマホのカメラで部屋を映し、画面をタップすると、**実寸大の家具が画面の中の床に現れます**。スマホを持って近づけば家具は大きく見え、回り込めば側面や背面が見える。まるで本当にそこへ置いたかのように確認できます。IKEAが先駆けた「IKEA Place」（2017年公開。現在はAR機能が本体アプリに統合されています）や、ニトリの「NITORI AR 家具試し置き」（アプリ不要のWeb AR）など、家具・インテリア業界で広く使われるようになった仕組みです。 弊社ではこのタイプのアプリをiOS（iPhone/iPad）とAndroidの両方で開発しています。本記事では、その中身を「仕組み」と「家具データの用意のしかた」の2つの面から、専門用語をかみくだいて解説します。 ## 「画像の合成」ではなく「3D空間への配置」 よくある誤解から片づけましょう。このアプリは**家具の写真をカメラ映像に貼り付けているわけではありません**。 もし写真を貼り付けているだけなら、スマホを動かした瞬間に破綻します。近づいても家具の大きさが変わらず、回り込んでも同じ面しか見えず、「その場に置いてある」ようにはまったく見えません。 実際に行われているのは、次のような処理です。 ``` 1. スマホが、カメラ映像とモーションセンサーから 「自分が部屋のどこにいて、どちらを向いているか」を毎瞬計算する 2. 映像の中から「床」や「壁」を平面として認識する 3. ユーザーがタップした位置に対応する床の上の座標を計算し、 そこに家具の「3Dモデル」を仮想的に固定する 4. 以降、スマホが動くたびに「その位置に置いた家具は 今のカメラからどう見えるか」を毎フレーム描画し直す ``` つまりアプリの中には**「現実の部屋と重なった、目に見えない3D空間」**があり、家具はその空間の座標に置かれています。だからこそ、近づけば大きく見え、回り込めば背面が見えるのです。 （図: スマホが部屋の床を平面として認識し、3D空間上にソファの3Dモデルを配置する仕組みの概念図） カメラ映像から空間を認識し、見えない3D空間に家具を配置している この「空間を理解して仮想の物体を重ねる」基盤技術を、iOSでは**ARKit**、Androidでは**ARCore**というプラットフォーム標準のフレームワークが提供しています。開発者はこれらの上にアプリを組み立てます。 ## スマホが部屋を理解する3つの技術 ### ① 自己位置推定（トラッキング） スマホは、カメラ映像の中の**特徴点**（模様の角、木目、床の継ぎ目など、映像として追いかけやすい点）の動きと、**加速度センサー・ジャイロセンサー**の値を組み合わせて、「自分がどれだけ動き、どちらを向いたか」をリアルタイムに計算し続けます。Appleはこの技術を視覚慣性オドメトリ（visual-inertial odometry）、GoogleはSLAM（自己位置推定と環境地図作成の同時実行）と説明していますが、「カメラ映像とモーションセンサーの併用で自分の位置を把握する」という考え方は共通です。 ### ② 平面検出 特徴点が同じ高さに集まっていれば「床」や「テーブル」、同じ縦の面に沿って並んでいれば「壁」の可能性が高い。ARKit/ARCoreはこうして**水平面や垂直面を検出**し、「ここに物を置ける」領域としてアプリに教えてくれます。家具配置アプリで最初に「床を映してください」と案内されるのは、この平面検出を走らせるためです。 ### ③ レイキャストとアンカー ユーザーが画面をタップしたら、カメラの位置からタップした画素を通る方向へ**仮想の光線（レイ）を飛ばし、検出済みの床平面と交わる点**を求めます。これで「画面上のタップ位置」が「部屋の床の上の3D座標」に変換されます。 その座標には**アンカー**（錨）と呼ばれる目印を打ち込みます。家具の3DモデルはこのアンカーにひもづけられるためAR空間の中で位置が固定され、スマホがどう動いても「その場に置かれたまま」に見えるのです。 ## 家具の「画像」はどう用意するのか ここが本記事のもう一つの主題です。結論から言うと、用意するのは画像（写真）ではなく**「実寸大の3Dモデル」**です。前章のとおり家具は3D空間に置かれるので、あらゆる角度から見られるデータ＝3Dモデルが必要になります。 ### 3Dモデルを用意する4つの方法 | 方法 | 概要 | 向いているケース | | **① 3DCGモデリング** | Blender・Maya等のツールで、写真や図面を見ながら人手でモデルを作る | 品質を作り込みたい主力商品。布・革など素材感の表現も調整できる | | **② フォトグラメトリ** | 実物をあらゆる角度から数十〜数百枚撮影し、ソフトが自動で3Dモデルを復元する | 実物が手元にあり、点数が多い場合。Appleは写真から3Dモデルを作るObject Capture APIを提供 | | **③ 3Dスキャン** | LiDARスキャナ等で実物の形状を直接計測する | 大型・複雑な形状。フォトグラメトリと併用されることも多い | | **④ CAD/設計データからの変換** | メーカーが製造用に持っている3D CADデータをAR用に軽量化・変換する | 家具メーカー自身が発注元の場合。寸法が正確という大きな利点 | （図: 実物の椅子を多方向から撮影し、写真群から3Dモデルを復元するフォトグラメトリの概念図） 実物の椅子を多方向から撮影して3Dモデル化するフォトグラメトリのイメージ ### フォーマットは2系統: USDZとglTF 作った3DモデルはAR用フォーマットに書き出します。事実上の標準は2つあります。 - **USDZ** — Appleが採用するフォーマット。iOSではUSDZファイルとWebページへのリンク設置だけで、専用アプリなしでもSafariから「AR Quick Look」による実物大AR表示ができます（iOS 12以降） - **glTF / GLB** — Khronos Groupが策定したオープン標準。Androidエコシステムにおける事実上の標準で、GoogleのScene ViewerもglTF 2.0/GLB形式に対応しています AppleがglTF等をUSDZへ変換するツール（Reality Converter）を提供しているため、glTFを起点に両フォーマットを揃えやすくなっています。弊社のiOS/Android両対応案件でも、**glTFでマスターデータを作り、USDZへ変換して両方を配信する**構成を採っています。 ### 「実寸大」の正体は、モデルの単位 「なぜ画面の家具が実物と同じ大きさに見えるのか」——種明かしをすると、**3Dモデルを実寸（メートル単位）で作ってあるから**です。glTFは仕様で「1単位=1メートル」と決まっています。幅1.8mのソファは、モデル上でも幅1.8。ARKit/ARCoreが現実空間をメートル単位で把握しているので、実寸で作られたモデルを置けば自動的に実寸大に見えます。逆に、ここで単位を間違えると「巨大なソファ」「ミニチュアのソファ」が出現します（後述のとおり、実際にやりがちなミスです）。 ### ARで快適に動くための軽量化 3Dモデルは細かく作るほどリアルになりますが、スマホでリアルタイム描画するには軽さも必要です。GoogleはScene Viewer向けモデルの推奨仕様として**モデルサイズ10MB・三角形数10万以下（理想は3〜5万）・テクスチャ最大2048×2048**を公開しており、AppleもAR Quick Lookについて約10万ポリゴン・2K解像度のPBRテクスチャ1セットという目安を示しています（WWDC 2018）。製造用CADデータや高精細スキャンをそのまま使うのではなく、**見た目を保ちながらポリゴン数を落とす軽量化（リトポロジー・デシメーション）**を挟むのが定石です。 ## 「本当に置いてある」ように見せる技術 3Dモデルをただ表示するだけでは、まだ「浮いて」見えます。実在感を出すために、いくつかの技術を重ねます。 - **光源推定** — ARKit/ARCoreはカメラ映像から部屋の明るさや色味を推定します。夕方のオレンジ色の部屋ではソファもややオレンジに照らされて表示され、違和感が減ります - **接地影** — 家具の下に影を落とすと、「床に接している」感覚が一気に増します。影のない家具は浮いて見えます - **PBRテクスチャ** — 物理ベースレンダリング用の質感データ（色・粗さ・金属感・凹凸）を持たせることで、布は布らしく、金属脚は金属らしく光を反射します - **オクルージョン** — 「家具の手前に実物のテーブルがあるなら、家具はその後ろに隠れて見えるべき」という前後関係の表現です。LiDARセンサー搭載のiPhone/iPadでは部屋の形状を直接計測して実現でき、AndroidではARCoreのDepth APIが単眼カメラからの深度推定で近い表現を提供します（対応は端末によります） ## iOSとAndroidでどう作るか 開発の選択肢は大きく3つあります。 | 方式 | 概要 | 向いているケース | | **ネイティブ開発** | iOSはARKit＋RealityKit、AndroidはARCoreで個別に開発 | OSの新機能（LiDAR等）を最大限使いたい場合 | | **Unity（AR Foundation）** | ARKit/ARCoreの差を共通APIで吸収し、1つのコードで両OS向けにビルド | 両OS対応を効率よく進めたい場合。弊社もこの構成を採用することが多い | | **アプリを作らない選択肢** | USDZ/glTFファイルを用意すればAR Quick Look（iOS）とScene Viewer（Android）でWebサイトからAR表示が可能 | まず小さく試したい場合。ECサイトへの導入はここから始めるのが低コスト | 意外に知られていないのが3つ目で、**「AR表示だけならアプリ開発なしでも始められる」**のは検討初期の重要な選択肢です。一方、家具の色・サイズ違いの切り替え、複数配置、保存・共有といった体験を作り込むなら、アプリとしての開発が必要になります。 ## 実際の開発で気をつけたこと 1. **真っ白な壁・無地の床は苦手** — トラッキングは映像の特徴点に頼るため、模様のない面では平面検出に時間がかかります。「スマホを少し動かしながら床を映してください」という誘導UIが実用上とても重要です 2. **暗い部屋で精度が落ちる** — カメラ映像が頼りなので、照度が低いと特徴点が取れません。夜の部屋で使われることも多い家具アプリでは、明るさ不足を検知して案内する作りにしました 3. **単位・原点のミスは事故になる** — 3Dモデルの単位設定を間違えると家具が巨大化・極小化します。モデル入稿時に寸法チェックを自動化して防ぎました 4. **モデルの容量と読み込み時間** — 高精細なモデルは数十MBになることもあり、通信環境によっては「タップしたのに家具が出ない」体験になります。サムネイル用の軽量モデルと高精細モデルの2段階配信が有効でした 5. **対応端末の確認** — ARCoreはGoogleが公開する対応端末リストに載っている端末でしか動きません。Android案件では「想定ユーザーの端末が対応しているか」を最初に確認すべきです ## よくある質問（FAQ） ### Q. 家具の写真が1枚あれば、ARで表示できますか？ できません。ARでは家具をあらゆる角度から見られるため、3Dモデルが必要です。実物があれば多方向から撮影してフォトグラメトリで作る方法があり、写真1枚しかない場合はモデラーによる3DCG制作になります。 ### Q. なぜ実物と同じ大きさで表示できるのですか？ 3Dモデルを実寸（メートル単位）で作ってあるからです。ARKit/ARCoreが部屋をメートル単位で認識しているため、実寸のモデルを置くと自動的に実物大で表示されます。 ### Q. どんなスマホでも動きますか？ ARKit・ARCoreそれぞれに対応端末の条件があります。特にAndroidはGoogleが認定した端末のみが対象です。またオクルージョンなど一部の表現は、LiDAR搭載機種など更に条件が絞られます。 ### Q. 自社の商品をARで見せたいのですが、何から始めればよいですか？ まず商品1点の3Dモデル（USDZ/glTF）を作り、アプリなしのAR Quick Look / Scene ViewerでWebサイトに載せて反応を見る方法が低コストです。手応えがあれば、配置の保存や色違い切り替えなどを備えたアプリ開発に進むのがおすすめです。 ## まとめ ### この記事のまとめ - AR家具配置は「写真の合成」ではなく、空間認識した部屋への「3Dモデルの配置」 - 仕組みの核は、自己位置推定（VIO/SLAM）・平面検出・レイキャストとアンカー - 用意するのは画像ではなく実寸の3Dモデル。作り方はモデリング／フォトグラメトリ／3Dスキャン／CAD変換の4系統 - フォーマットはiOS=USDZ、Android=glTF/GLBの2系統。実寸表示の正体はメートル単位のモデリング - 光源推定・接地影・PBR・オクルージョンの積み重ねが実在感を作る - AR表示だけならアプリなし（AR Quick Look / Scene Viewer）でも始められる テクノスフィアは、スマホアプリ開発と画像認識・3D技術の両方を自社で手がけています。「自社の商品をARで見せたい」「まず1点だけ試したい」という段階からご相談いただけます。 [▶ スマホアプリ開発サービスを見る](https://technosphere.co.jp/app-development) ｜ [相談する](https://technosphere.co.jp/contact?category=web) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # 熊（クマ）をAIカメラで検知する｜既存の防犯カメラを活かす害獣検知 GENBA IQ｜株式会社テクノスフィア > 深刻化する熊（クマ）の出没・人身被害に、AIカメラによる早期検知という選択肢を。GENBA IQ は既存の防犯カメラ映像をエッジAIで解析し、熊やイノシシ・鹿などの害獣をリアルタイムで検知・通知します。自治体・農地・通学路・施設の鳥獣対策に。最短2週間でPoC。 URL: https://technosphere.co.jp/blog/bear-wildlife-detection-ai-camera ** 目次 1. なぜ今、熊対策に「AIカメラ」なのか 2. GENBA IQ が熊を検知する仕組み 3. 既存の防犯カメラを活かせる理由 4. 夜間・誤検知という最大の壁 5. どんな現場で使えるか 6. 検知から通知・追い払いまで 7. 導入の進め方（最短2週間のPoC） 8. よくある質問 9. まとめ ** この記事でわかること 既存の防犯カメラを使って熊・害獣を AI で早期検知する考え方と、GENBA IQ での実現方法、夜間・誤検知対策、自治体や施設での活用シーン、導入の進め方までを解説します。「カメラはあるが活かせていない」「見回りの負担を減らしたい」という方に向けた内容です。 ## なぜ今、熊対策に「AIカメラ」なのか 近年、熊（ツキノワグマ・ヒグマ）の**市街地・住宅地への出没**と人身被害が全国的に深刻化しています。山林の餌不足や生息域の拡大により、これまで安全とされた通学路・農地・観光地・住宅の裏山にまで熊が現れるようになりました。自治体や施設管理者にとって、**「いつ・どこに出るか分からない」**ことが最大の難しさです。 従来の対策には限界があります。 - **人による見回り：**24時間・広範囲は人手的に不可能。夜間・早朝の出没に間に合わない - **わな・電気柵：**設置箇所に依存し、出没そのものの「早期把握」はできない - **住民通報頼み：**気づいた時にはすでに接近しており、後手に回る ここで効くのが **「すでにあるカメラを“見張り役”にする」**という発想です。防犯・河川・施設監視などの目的で各地に設置された膨大なカメラ映像を、人が常時監視するのは不可能。しかし **AI なら 24 時間、複数拠点を同時に監視し、熊を見つけた瞬間に知らせる**ことができます。 ** ポイント：監視を「人」から「AI」へ カメラ映像を増やしても、見る人がいなければ意味がありません。AI 検知は「映像を増やす」のではなく「**映像から意味のある瞬間（＝熊の出現）だけを人に届ける**」技術です。担当者は普段モニターを見続ける必要がなく、通知が来たときだけ対応すればよくなります。 ## GENBA IQ が熊を検知する仕組み [GENBA IQ](https://technosphere.co.jp/genba-iq) は、**映像・音声・センサーを統合して「現場」をAIが理解する**エッジAIプラットフォームです。熊検知では、カメラ映像を解析して「画面内に熊がいるか」をリアルタイムに判定します。 （図: 既存カメラ → エッジAI → スマホ通知 という熊検知の仕組み） | ステップ | 内容 | | ① 映像取得 | 既存の防犯カメラ／ネットワークカメラの映像を入力 | | ② エッジAI解析 | 現場に置いた小型のエッジAI端末が、映像から熊・害獣をその場で判定（クラウド送信不要） | | ③ 検知・分類 | 熊／イノシシ／鹿／人／車などを区別。誤報の原因になる対象を除外 | | ④ 通知・記録 | スマホ・PCへの通知、威嚇装置の作動、該当映像の記録を自動実行 | ポイントは **「エッジAI」**であること。映像をすべてクラウドに送るのではなく、**現場の端末でその場で解析**します。これにより、通信コストを抑え、映像を外部に流さずプライバシーにも配慮でき、通信が不安定な山間部でも動作します。 ## 既存の防犯カメラを活かせる理由 「熊検知のためにカメラを一から設置し直す」と考えると、費用も期間も膨らみます。GENBA IQ が現実的なのは、**いまあるカメラ資産をそのまま活かせる**からです。 - **カメラ総入れ替え不要：**RTSP などで映像を取得できる一般的な防犯・ネットワークカメラに後付けできる - **多拠点を一括監視：**複数のカメラ映像を 1 つの仕組みで同時に見張れる - **段階導入が可能：**まず数台でPoC → 効果を確認して拡大、という進め方ができる すでに防犯や河川監視のためにカメラを設置している自治体・施設なら、その映像に「熊を見つける目」を足すだけ。**投資を最小に、立ち上がりを最速に**できます。 ／熊・害獣の出没にお困りの自治体・施設の方へ＼ ### 今あるカメラで、熊検知を始められます 「現場のカメラで検知できるか知りたい」「2週間のPoCで効果を確かめたい」──まずは現地のカメラ環境のご相談から。低コスト・短期間で検証できます。 [GENBA IQ を見る](https://technosphere.co.jp/genba-iq) [熊・害獣検知を相談する](https://technosphere.co.jp/contact?category=genba_iq) ## 夜間・誤検知という最大の壁 害獣検知で本当に難しいのは「昼間に熊を見つける」ことではなく、**「夜間に、誤報なく、確実に見つける」**ことです。ここに実運用のノウハウが要ります。 （図: 夜間・低照度でも熊を検知するイメージ） ### 夜間・低照度への対応 熊の出没は**夜間〜早朝に集中**します。可視光カメラだけでは暗くて写りません。GENBA IQ では、赤外線（暗視）カメラやサーマル（熱）カメラと組み合わせ、暗所でも動物の存在を捉えられるよう構成します。現場の照明条件に合わせた設計が肝心です。 ### 「誤検知（誤報）」を減らす 犬・人・揺れる枝・車のライトなどを熊と誤判定すると、通知が頻発して**「オオカミ少年」状態**になり、現場が通知を信用しなくなります。これを防ぐため、 - 熊と他の動物・人・車を**区別**して分類する - 現場で撮れた実際の映像を使って**チューニング**する（昼夜・季節・カメラ角度ごと） - 一定時間・複数フレームでの確からしさを見て**誤報をフィルタ**する といった調整を、PoC 期間に現場データで詰めていきます。**「現場ごとに合わせ込む」**ことが検知精度の決め手です。 ## どんな現場で使えるか 熊・害獣検知は、自治体から民間施設まで幅広く活用できます。 （図: 通学路・農地・キャンプ場・施設敷地など熊検知の活用シーン） | 現場 | 活用イメージ | | **自治体・通学路** | 通学路や住宅地周辺のカメラで出没を早期把握し、防災無線・見守りメールと連携 | | **農地・果樹園** | 熊・イノシシ・鹿による農作物被害の監視。出没エリアと時間帯の把握にも | | **観光地・キャンプ場・ゴルフ場** | 来場者の安全確保。営業時間外・夜間の侵入検知 | | **工場・物流施設・発電所** | 広い敷地・フェンス際への動物侵入の検知。既存の防犯カメラを流用 | | **鉄道・道路** | 線路・道路への侵入検知による事故・遅延の予防 | 熊に限らず、**イノシシ・鹿・サルなどの鳥獣被害対策**にも同じ仕組みが応用できます。検知対象は現場の課題に合わせて設計します。 ## 検知から通知・追い払いまで 「検知できる」だけでは現場は守れません。**検知した次の一手**までを自動化できるのが GENBA IQ の強みです。 - **即時通知：**担当者のスマホ・PC へ、検知した映像つきで通知 - **威嚇・追い払い：**回転灯・スピーカー（音声・超音波）などの装置を自動作動 - **記録・可視化：**いつ・どこに・何が出たかを記録し、出没マップや時間帯傾向として蓄積 - **既存体制との連携：**自治体の連絡網・警報設備・既設の監視システムと接続 蓄積した出没データは、**パトロール計画やわな・柵の最適配置**にも役立ちます。「検知 → 通知 → 対応 → 記録 → 次の対策」というサイクルを回せます。 ## 導入の進め方（最短2週間のPoC） GENBA IQ は、**いきなり大規模導入せず、まず小さく試す**ことを推奨しています。 1. **現地カメラ環境の確認：**既存カメラの種類・設置位置・夜間条件・映像取得方法を確認 2. **PoC（実証実験）：**対象カメラで実際に熊・害獣を検知できるか、現場映像で2週間程度検証 3. **精度チューニング：**誤検知・見逃しを現場データで調整 4. **本導入・拡大：**効果を確認してから台数・拠点を拡大 既存カメラを活かすため初期コストを抑えられ、**「効果を確かめてから広げる」**進め方ができます。補助金・交付金の活用を検討中の自治体の方は、そのスケジュールに合わせたご相談も可能です。 ## よくある質問 ** 今ある防犯カメラのままで検知できますか？ 多くの場合、既存のカメラ映像をそのまま活用できます。カメラを総入れ替えせず、検知機能を後付けで追加します。まずは現地のカメラ環境の確認から始めます。 ** 夜間や悪天候でも検知できますか？ 熊の出没は夜間・早朝が中心です。赤外線・サーマルカメラと組み合わせ、低照度でも検知できるよう構成し、誤検知を抑えるチューニングを行います。 ** 検知したらどう知らせてくれますか？ スマホ・PCへの通知、回転灯・スピーカーの作動、映像記録などを自動実行できます。既存の連絡体制・警報設備に合わせて連携します。 ** 期間と費用はどのくらいですか？ 最短2週間のPoCで、実際の現場映像で精度を確認してから本導入を判断できます。既存カメラを活かせるため初期費用を抑えてスモールスタートできます。詳細はお問い合わせください。 ## まとめ ### この記事のまとめ - 熊の市街地出没が深刻化するなか、**24時間の見回りは人手では限界**。AIカメラによる早期検知が有効 - GENBA IQ は**既存の防犯カメラ映像をエッジAIで解析**し、熊・害獣をリアルタイム検知 - 映像を現場で解析する**エッジ方式**で、通信コスト・プライバシー・山間部の通信不安定に強い - 実運用の鍵は**夜間対応と誤検知の低減**。現場データでのチューニングが精度を決める - 自治体・農地・通学路・観光施設・工場敷地など**幅広い現場**に応用でき、イノシシ・鹿対策にも - 検知 → 通知 → 追い払い → 記録までを自動化。**最短2週間のPoC**からスモールスタートできる テクノスフィアの [GENBA IQ](https://technosphere.co.jp/genba-iq) は、製造・物流・交通・防災などの現場で培ったエッジAI・画像認識技術を、熊・害獣の検知に応用します。「自分たちの地域・施設のカメラで検知できるのか」をまず確かめたい、という段階のご相談を歓迎します。 ／熊・害獣検知のPoC・ご相談はこちら＼ ### 今あるカメラで、熊検知を始めませんか？ GENBA IQ は既存の防犯カメラを活かし、熊・イノシシ・鹿などの害獣をAIでリアルタイム検知します。自治体・農地・観光施設・工場敷地の鳥獣対策に。最短2週間のPoCで、まずは現場での効果をご確認ください。 [GENBA IQ の詳細を見る](https://technosphere.co.jp/genba-iq) [熊・害獣検知を相談する](https://technosphere.co.jp/contact?category=genba_iq) # 熊検知 # 害獣検知 # AIカメラ # 鳥獣被害対策 # GENBA IQ # エッジAI # 防犯カメラ # 画像認識 ## 関連記事・サービス - [サービス GENBA IQ｜現場を理解する次世代エッジAI 映像・音声・センサー統合のリアルタイム検知](https://technosphere.co.jp/genba-iq) - [関連記事 Raspberry Pi × VLM で実現するエッジAI 現場で動かす画像認識AIの技術背景](https://technosphere.co.jp/blog/raspberry-pi-vlm-edge-ai) - [サービス 画像認識AI・外観検査 検知・分類の画像認識技術](https://technosphere.co.jp/vision-system) - [お問い合わせ 熊・害獣検知のPoCを相談する 現場のカメラ環境のご相談から](https://technosphere.co.jp/contact?category=genba_iq) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # BLEでスマホと機器をつなぐアプリ開発｜設計の勘所とハマりどころ｜テクノスフィア > Bluetooth Low Energy（BLE）でスマホアプリと測定機器・センサーをつなぐ実装の勘所を解説。GATT設計、接続の再確立、バックグラウンド動作の制約、iOS/Androidの権限差、機器側ファームウェアとの分担まで、組込みとアプリの両方を手がける立場から実務ベースでまとめました。 URL: https://technosphere.co.jp/blog/ble-device-app-integration ** 目次 1. BLEの基本構造とGATT設計 2. 最初に決めるべきGATTの分担 3. 接続は切れる前提で設計する 4. バックグラウンド動作の制約 5. iOS/Androidの権限の違い 6. データ量とMTU、大容量転送の限界 7. 実案件でハマった5つのこと 8. よくある質問（FAQ） 9. まとめ ## BLEの基本構造とGATT設計 BLE（Bluetooth Low Energy）では、機器側が**ペリフェラル**、スマホ側が**セントラル**になるのが一般的です。データのやり取りは**GATT**という構造の上で行われます。 ``` Service（機能のまとまり） └ Characteristic（実際のデータ項目） ├ Read : アプリから読み出す ├ Write : アプリから書き込む └ Notify : 機器側から変化を通知する（ポーリング不要） 例）測定器の場合 Service: Measurement ├ Characteristic: current_value (Notify) ← 測定値の連続通知 ├ Characteristic: device_status (Read) ← バッテリー・エラー状態 └ Characteristic: command (Write) ← 測定開始/停止の指示 ``` ここでの設計判断が、後の実装の楽さを大きく左右します。**「アプリが定期的に読みに行く（Read）」のか「機器が変化時に通知する（Notify）」のか**は、電池持ちにも応答性にも直結します。連続的に変化する値はNotify、状態の確認はRead、が基本方針です。 ## 最初に決めるべきGATTの分担 機器メーカーとアプリ開発会社が別々の場合、ここで揉めることが非常に多いポイントです。決めておくべきなのは次の5点です。 - **どの値をNotifyにするか** — 増やしすぎると電池を消耗し、少なすぎるとアプリ側がポーリングして結局消耗します - **データのエンコード** — リトルエンディアンか、固定小数点か、スケール係数はいくつか。ここの認識違いは値が10倍ずれる不具合になります - **エラーの伝え方** — GATTのエラーコードで返すのか、専用のCharacteristicで状態を持たせるのか - **ファームウェア更新（DFU）の有無** — 後から必要になると機器側の作り直しになります。最初に決めてください - **ペアリングの要否** — 暗号化が必要か、都度接続でよいか。業務用途では「誰でも接続できる」が問題になることがあります ``` // アプリ側で値の解釈を間違えないよう、仕様を単体テストで固定する例 test('温度Characteristicは 0.01℃ 単位のint16(LE)として解釈される', () => { const raw = new Uint8Array([0x64, 0x09]); // 0x0964 = 2404 expect(parseTemperature(raw)).toBeCloseTo(24.04); // 2404 * 0.01 }); ``` 弊社の場合は[機器側の組込み開発](https://technosphere.co.jp/embedded)とアプリ開発を同じチームで担当できるため、この分担を「仕様書のやり取り」ではなくその場の設計で決められます。機器とアプリが別会社に分かれている案件で最も時間を取られるのが、この擦り合わせです。 ## 接続は切れる前提で設計する BLEは**必ず切れます**。電波環境、機器の省電力動作、OSの都合、端末のスリープ。切れることを異常として扱う設計にすると、現場で使い物になりません。 実装で押さえるべき点は3つです。 - **自動再接続** — 切断イベントを検知したら、指数バックオフで再接続を試みる。無限に即時リトライすると電池を消耗します - **状態の可視化** — 「接続中／再接続中／切断」を画面に出す。作業者が「今つながっているのか」を判断できないアプリは信用されません - **データの取りこぼし防止** — 切断中に機器側で測定した値をどう扱うか。機器側にバッファを持たせ、再接続時にまとめて吸い上げる設計が確実です ## バックグラウンド動作の制約 「アプリを閉じていても測定を続けたい」という要望はよく出ますが、ここはOSの制約が最も厳しい領域です。 | | iOS | Android | | バックグラウンド接続 | Background Modes（bluetooth-central）で可能 | Foreground Serviceの併用が実質必須 | | スキャンの制約 | サービスUUID指定が必須。間隔も延びる | Doze mode・電池最適化の影響を受ける | | アプリ終了後 | 状態復元（restoration）で一部復帰可能 | 端末メーカー独自の最適化で停止されることがある | とくにAndroidは、端末メーカーごとの独自の省電力機能でバックグラウンド動作が止められることがあります。**要件にバックグラウンド動作が含まれる場合は、実際に使う端末で早期に検証してください。**「開発機では動いたのに現場の端末では止まる」が起きやすい領域です。 ## iOS/Androidの権限の違い ``` iOS Info.plist に NSBluetoothAlwaysUsageDescription（利用目的の説明）が必須 → 説明文が不十分だと審査でリジェクトされる Android 12 (API 31) 以降 BLUETOOTH_SCAN … スキャンに必要（実行時権限） BLUETOOTH_CONNECT … 接続に必要（実行時権限） ※ 位置情報を推定しない場合は neverForLocation を宣言すると 位置情報権限の要求を避けられる Android 11 以前 ACCESS_FINE_LOCATION が必要（BLEスキャン＝位置推定とみなされるため） ``` ここはOSバージョンによる分岐が多く、**対応OSの下限をどこに置くかで実装量が変わります**。業務用途で古い端末が残っている場合は、権限まわりだけで想定外の工数が発生することがあるため、対象端末の棚卸しを先に行ってください。 ## データ量とMTU、大容量転送の限界 BLEは省電力な代わりに、**一度に送れるデータ量が小さい**のが特徴です。初期のMTUは非常に小さく、交渉して拡張しても数百バイト程度に収まります。 この制約から、次の設計判断が必要になります。 - **分割送信と組み立て** — 大きなデータはパケットに分け、順序番号を付けてアプリ側で再構成する - **再送制御** — 欠落を検出して再送を要求する仕組み。Notifyは到達保証がないため、確認応答の設計が要ります - **そもそも送らない** — 機器側で集計・間引きしてから送る。生データを全部送る設計は、たいてい破綻します 機器内に蓄積したログを一括で吸い上げるような要件では、BLEにこだわらずWi-FiやUSBを併用する判断も現実的です。**「何を、どのくらいの頻度で、どれだけ送るか」を先に数字で出す**と、方式選定を誤りません。 ## 実案件でハマった5つのこと 1. **スケール係数の認識違い** — 機器側は0.01単位、アプリ側は0.1単位で解釈しており、値が10倍ずれた。仕様書ではなくテストコードで固定すべきでした 2. **手袋をした指で操作できない** — 現場作業者が手袋着用で、タップ判定が効かなかった。ボタンを大きくし、静電容量式に反応する手袋の使用を案内して解決 3. **複数台の機器が近くにあり、意図しない機器につながる** — アドバタイズに機器固有IDを載せ、アプリ側で選択・記憶する仕組みを追加 4. **屋外で画面が見えない** — 直射日光下でコントラストが不足。配色を見直し、輝度を最大にする設定を追加 5. **特定メーカーのAndroid端末でだけ再接続しない** — 端末独自の省電力機能が原因。使用端末を確定させ、その端末で検証する体制に変更 3つ目以降は、いずれも**実装の問題ではなく現場環境の問題**です。BLE案件では、実際に使う場所・端末・作業者の状態を早い段階で確認することが、技術的な設計と同じくらい重要になります。 ## よくある質問（FAQ） ### Q. BLE対応アプリはiOSとAndroidで作りが変わりますか？ 変わります。APIも権限の要求方法も異なり、Androidは12以降で実行時権限が追加されました。クロスプラットフォーム開発でも、この差はプラグイン越しに現れます。 ### Q. アプリをバックグラウンドにしてもBLE通信を続けられますか？ 条件付きで可能です。iOSはBackground Modes、AndroidはForeground Serviceが前提になり、Androidは端末メーカー独自の省電力機能の影響も受けます。実機での早期検証が必須です。 ### Q. BLEの通信速度はどのくらいですか？ 一度に送れるデータ量は数百バイト程度です。ログの一括転送には向かず、分割送信と再送制御、あるいは機器側での間引きが必要になります。 ### Q. 機器側のファームウェアも合わせて開発できますか？ できます。弊社はマイコンを使った[組込み開発](https://technosphere.co.jp/embedded)とアプリ開発の両方を自社で行っているため、GATT設計を機器側とアプリ側で分けずに決められます。 ## まとめ ### この記事のまとめ - GATT設計（Notify/Read/Writeの割り当てとエンコード）が実装の楽さを決める - BLEは必ず切れる。自動再接続・状態表示・機器側バッファを前提に設計する - バックグラウンド動作はOSと端末メーカーの制約が強い。実機で早期検証する - Android 12以降の実行時権限など、対応OS下限で実装量が変わる - 一度に送れるデータは小さい。大容量転送はそもそも設計を見直す - 現場環境（手袋・直射日光・複数台）の確認が、技術設計と同じくらい重要 テクノスフィアは、マイコンを使った機器側の開発とスマートフォンアプリの開発を自社で一貫して行っています。機器メーカー様からの「アプリ側だけお願いしたい」というご相談も、既存機器の仕様解析からご一緒できます。 [▶ スマホアプリ開発サービスを見る](https://technosphere.co.jp/app-development) ｜ [組込みシステム開発を見る](https://technosphere.co.jp/embedded) ｜ [相談する](https://technosphere.co.jp/contact?category=web) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # Canva MCP × Claude Code｜AIエージェントにSNS投稿とWeb制作素材をつくらせる【実測33ツール・落とし穴つき】｜株式会社テクノスフィア > Canva公式MCPサーバをClaude Codeに接続し、SNS投稿画像とブログ用OGP/ヒーロー画像を実際に生成・編集・書き出しした検証レポート。接続手順、33ツールの実測、プラン別制限とレート制限、日本語フォント化けや商用利用ライセンスの注意点まで出典付きで解説。 URL: https://technosphere.co.jp/blog/canva-mcp-claude-code ** 目次 1. はじめに：この記事のヒーロー画像はAIが作りました 2. Canva MCP（AI Connector）とは 3. Claude Codeへの接続手順 4. 実際に見えたツールは33個 5. 実践①：SNS投稿画像を生成する 6. 生成AIデザインの落とし穴（実測） 7. 実践②：ブログのヒーロー／OGP画像をつくる 8. 実践③：編集トランザクションAPIでデザインを"コードで"直す 9. プラン別制限とレート制限 10. 商用利用ライセンスの落とし穴 11. どこまで自動化すべきか 12. よくある質問（FAQ） 13. まとめ 14. 参考文献・出典 ** 本記事のスコープと検証環境 本記事は**2026年7月26日時点**で、Canva公式リモートMCPサーバ（`https://mcp.canva.com/mcp`）をClaude Codeに接続して実際に操作した記録です。掲載しているレスポンスやエラーはすべて実行結果からの引用で、画面写真ではなくAPIの生の挙動に基づいています。仕様・プラン要件は変更される可能性があるため、導入前に末尾の一次情報でご確認ください。 ## はじめに：この記事のヒーロー画像はAIが作りました このページの一番上に表示されているヒーロー画像と、SNSでシェアしたときに出るOGP画像は、**人間がCanvaの編集画面を一度も開かずに**作られています。ターミナルのClaude Codeに「こういう画像がほしい」と日本語で指示しただけです。デザイン生成、レイアウト調整、書き出しまでがAIエージェントとCanvaの間で完結しました。 これを可能にしているのが **MCP（Model Context Protocol）**です。MCPはAIアシスタントと外部ツールをつなぐオープンな標準規格で、Canvaは公式のMCPサーバを提供しています。つまり「AIがCanvaを操作する」ための正規の入り口が用意されている、ということです。 Web制作やSNS運用の現場では、バナー・サムネイル・告知画像といった**「重要だが単価の低い量産作業」**が慢性的に発生します。ここをAIに渡せるなら効果は大きい。一方で、AIが作ったものをそのまま世に出すのは、事業者としてはリスクです。実際に検証したところ、**そのまま公開したら信用を落としかねない出力**にも遭遇しました。 そこで本記事では、**できたこと**と**できなかったこと・危なかったこと**の両方を記録します。導入判断の材料としてお使いください。 ## Canva MCP（AI Connector）とは Canvaが提供する公式のリモートMCPサーバで、製品名としては**「Canva AI Connector」**と呼ばれています[1]。Canva公式は「Design with Canva, right from your AI chat（AIチャットからそのままCanvaでデザインする）」と表現しており、その裏側がCanva MCP Serverです。 | 項目 | 内容 | | エンドポイント | `https://mcp.canva.com/mcp`（リモート／HTTP）[2] | | 認証方式 | CIMD（Client ID Metadata Documents）が推奨。後方互換としてDCR（動的クライアント登録）もサポートされるが非推奨扱い[2] | | 認証の単位 | **ユーザー単位**。「Each user needs to authenticate」と明記され、利用者ごとにCanvaアカウントが必要[2] | | 権限の範囲 | 「The operations available to a user match their level of access to a design or asset」——AIができる操作は、そのユーザーがCanva上で持っている権限を超えない[2] | | 対応クライアント | Canva公式ページの掲載はChatGPT・Claude・Amazon Quick Suite（提供中）、Google Gemini（近日）、Microsoft Copilot（プレビュー）[1]。加えてMCP対応クライアント全般から接続可能 | ** 「AIに全権限を渡す」わけではない 導入検討でよく懸念されるのが「AIが社内のデザイン資産を勝手に触れるようになるのでは」という点です。Canvaのドキュメントは、操作範囲が**認証したユーザー自身のアクセス権の範囲内**に限られると明記しています[2]。組織単位の一括接続ではなく、各人が自分のアカウントで認証する設計です。逆に言えば、**強い権限を持つ管理者アカウントで接続すれば、その権限がそのままAIの作業範囲になる**ということでもあります。 ## Claude Codeへの接続手順 Claude Codeはリモートのhttp型MCPサーバを `claude mcp add` で登録できます[3]。Canvaの場合はこれだけです。 ``` # サーバーを登録（--scope user で全プロジェクト共通にする） claude mcp add --transport http canva https://mcp.canva.com/mcp --scope user # Claude Code のセッション内で OAuth 認証を実行 /mcp ``` Claude Code公式ドキュメントは「Use `/mcp` to authenticate with remote servers that require OAuth 2.0 authentication」と記載しており[3]、ブラウザが開いてCanvaのログイン・認可画面に進みます。APIキーの発行やヘッダー設定は不要です。 ### 登録結果の確認 登録内容は `~/.claude.json`（user スコープ）または `.mcp.json`（project スコープ）に保存されます。実際の登録内容と疎通確認は次のとおりでした。 ``` $ claude mcp list Checking MCP server health… canva: https://mcp.canva.com/mcp (HTTP) - ✔ Connected # ~/.claude.json の該当エントリ "canva": { "type": "http", "url": "https://mcp.canva.com/mcp" } ``` ** 設定JSONを手書きする場合の注意 Claude Codeのドキュメントによれば、JSONの `type` フィールドは `streamable-http` を `http` のエイリアスとして受け付けます。一方で**`url` があるのに `type` が無いエントリは設定エラー**となり、Claude Codeはそのサーバーをスキップして `MCP server "" has a "url" but no "type"` と報告します[3]。他サービスのドキュメントからコピーした設定を貼る際にハマりやすいポイントです。 ### スコープの選び方（実務上の判断） | スコープ | 保存先 | 向いているケース | | `--scope user` | `~/.claude.json` | 個人の全プロジェクトでCanvaを使う。デザイン素材は案件横断で必要になるため、通常はこれ | | `--scope project` | `.mcp.json`（リポジトリ内） | チーム全員に同じ接続先を配布したい場合。ただし**認証は各人が個別に行う**点に注意 | | `--scope local` | ユーザー設定内のプロジェクト別領域 | 特定プロジェクトでだけ一時的に使う | `.mcp.json` をリポジトリにコミットしてもCanvaの認証情報は含まれません（URLのみ）。トークンは各利用者のローカルに保持されるため、**接続先の共有と資格情報の共有は別物**です。この分離は、チーム配布を検討するうえで重要な性質です。 ## 実際に見えたツールは33個 接続後、Claude Codeから利用可能になったCanvaのツールは**33個**でした。カテゴリごとに整理すると、Canva MCPが何をカバーしているかが見えてきます。 | カテゴリ | 主なツール | できること | | デザイン生成 | `generate-design` / `create-design-from-candidate` / `copy-design` | プロンプトからデザイン候補を生成し、選んだものをアカウントに保存 | | 編集 | `start-editing-transaction` / `perform-editing-operations` / `commit-editing-transaction` / `cancel-editing-transaction` | テキスト置換・書式変更・要素の移動/リサイズ/削除・画像差し替えをトランザクションで実行 | | 取得・検索 | `search-designs` / `get-design` / `get-design-content` / `get-design-pages` / `get-presenter-notes` | 既存デザインの検索と、テキスト内容・ページ構成の読み取り | | 書き出し | `export-design` / `get-export-formats` | PDF・JPG・PNG・PPTX・GIF・MP4・CSVへの書き出しとダウンロードURL取得 | | アセット | `upload-asset-from-url` / `get-assets` | 外部URLの画像をCanvaに取り込む | | ブランド | `list-brand-kits` / `search-brand-templates` / `create-design-from-brand-template` / `get-brand-template-dataset` | ブランドキット・ブランドテンプレートの利用（プラン制限あり） | | 整理・協業 | `create-folder` / `move-item-to-folder` / `comment-on-design` / `reply-to-comment` ほか | フォルダ整理、デザインへのコメント・返信 | | その他 | `resize-design` / `import-design-from-url` / `resolve-shortlink` | サイズ変更、URLからのインポート、短縮リンク解決 | ** 公式ドキュメントとの差分も記録しておく Canva公式のツール一覧[4]にも33ツールが掲載されていますが、**弊社の接続環境で見えた顔ぶれとは完全一致しませんでした**。公式表にある `autofill-design`（Enterprise専用）は今回の環境では出現せず、代わりに公式表に記載のない `get-design-candidates` が利用可能でした。原因は特定していませんが（プラン差か提供時期差かは断定できません）、**ツールの有無はドキュメントではなく実接続で確認すべき**ということです。導入設計の際は、この前提でお進めください。 ## 実践①：SNS投稿画像を生成する まずSNS告知用の画像を作ります。指示は自然言語で、`design_type` に `instagram_post` を指定するだけです。実際に投げたプロンプトの要点は次のとおりです。 ``` design_type: instagram_post query: B2B向けIT企業「株式会社テクノスフィア」のSNS告知投稿。 訴求内容は「技術ブログ更新のお知らせ：Canva MCP を Claude Code に つないで、SNS投稿画像とWeb制作素材をAIエージェントに作らせた検証レポート」。 見出しは「技術ブログ更新」、メインコピーは「AIエージェントに デザインを任せる」。 ダークネイビー(#0B1F3A系)背景にシアン〜ブルーのグラデーション、 幾何学ラインのテック的装飾。写真・人物イラストは使わない。 日本語はゴシック体で必ず文字化けしない一般的な日本語フォントを使用し、 英字プレースホルダ（架空のURLや社名、CEOなどの架空の肩書き）は一切入れないこと。 文字数は少なく、余白広め、可読性最優先。 ``` ### 返ってくるのは「候補4案」 `generate-design` はデザインを直接作るのではなく、**候補（design candidates）を4案返す**設計です。レスポンスは次の形でした。 ``` { "job": { "id": "2c4d09ff-a234-4d0f-96c2-ff4a7fecf388", "status": "success", "result": { "generated_designs": [ { "candidate_id": "dg-5a03d4c0-...", "url": "...", "thumbnails": [...] }, { "candidate_id": "dg-5dc4338c-...", "url": "...", "thumbnails": [...] }, { "candidate_id": "dg-99f3fe0c-...", "url": "...", "thumbnails": [...] }, { "candidate_id": "dg-c1922500-...", "url": "...", "thumbnails": [...] } ] } } } ``` この段階では**まだCanvaアカウントに保存されていません**。気に入った候補を `create-design-from-candidate` で確定させて初めてデザインになります。「4案出して選ぶ」というCanvaのUXが、そのままAPIの構造になっているわけです。 ** 実際に踏んだエラー：`job_id` も必要 `create-design-from-candidate` に `candidate_id` だけを渡したところ、次のバリデーションエラーになりました。 ``` MCP error -32602: Input validation error: [{ "code": "invalid_type", "expected": "string", "received": "undefined", "path": ["job_id"], "message": "Required" }] ``` **`job_id` と `candidate_id` の両方**が必須です。生成レスポンスの `job.id` を保持しておく必要があります。エージェントに任せる場合も、この2値をセットで扱う前提でワークフローを組んでください。 採用した候補を確定させると、デザインIDとURLが返ります。 ``` { "design_summary": { "id": "DAHQb2vIfiE", "title": "Digital Post for Tech Blog Announcement", "urls": { "edit_url": "https://www.canva.com/d/...", "view_url": "https://www.canva.com/d/..." }, "page_count": 1 } } ``` あとは `export-design` で書き出すだけです。実際に出力されたのは **1080×1350ピクセル（4:5の縦型）**のPNGで、Instagramのポート型投稿にそのまま使えるサイズでした。書き出し結果は署名付きの一時ダウンロードURLとして返されます。 （図: Canva MCPとClaude Codeで生成したSNS告知投稿画像。ダークネイビー背景に「技術ブログ更新」「AIエージェントにデザインを任せる」の日本語コピーが配置されている） 実際に生成されたSNS投稿画像（1080×1350／縮小表示）。人手の編集はゼロ 所要時間は、プロンプト投入から書き出しURL取得まで**1〜2分程度**。デザイナーに依頼して戻ってくるまでのリードタイムと比べれば、告知用の「とりあえず1枚」を用意する速度としては十分実用的です。 ## 生成AIデザインの落とし穴（実測） ここからが本題です。速いのは事実ですが、**そのまま公開してはいけない出力**が確かに混ざります。今回の検証で実際に発生した3つの問題を記録します。 （図: Canva MCPが一度に生成した4つのデザイン候補の比較。右上の候補では日本語が四角い記号（豆腐）に文字化けし、架空のドメイン名と肩書きが表示されている） ヒーロー画像生成時に返ってきた4候補。右上の案は日本語が文字化けし、テンプレート由来のダミー情報も残っている ### ① 日本語が「豆腐」になる 4案のうち1案で、日本語のコピーが**すべて □□□ の並び（いわゆる豆腐）**になりました。選ばれたテンプレートのフォントが日本語グリフを持っていなかったためと考えられます。英語圏発のテンプレート資産を使う以上、これは構造的に起こり得ます。 対策として、SNS画像の生成時にはプロンプトへ**「文字化けしない一般的な日本語フォントを使用」**と明記しました。その結果、SNS投稿側では4案すべてで日本語が正常に描画されています。完全な保証にはなりませんが、有効な予防策です。 なお編集APIの仕様上、**フォントファミリの変更はサポートされていません**（サイズ・太さ・スタイルは変更可）。つまり**豆腐化した候補は、後からAPIで直せません**。捨てて選び直すのが正解です。 ### ② テンプレート由来のダミー情報が残る 同じ候補には、指示していない**架空のドメイン名（"REALLYGREATSITE.COM"）**と**架空の肩書き（"CEO"）**が、自社名の下に配置されていました。Canvaのテンプレートに元から入っているプレースホルダがそのまま残ったものです。 これは実害が大きい種類の問題です。**自社名と並んで存在しないURLや肩書きが載った画像を公開すれば、それは誤情報の発信**になります。生成結果を自動でSNSへ投稿するパイプラインを組む場合、ここに人間の確認工程がないのは危険です。 ### ③ 指示していない「事実」を書き足す SNS投稿の候補の1つには、こちらが一切指定していない**「2026年7月25日 土曜日」という日付**が挿入されていました。興味深いことに、2026年7月25日は実際に土曜日で、**曜日の整合性は取れています**。しかしこの日付自体に根拠はなく、記事の公開日でもありません。 ** 「もっともらしい」ほど危ない 明らかな文字化けは誰でも気づきます。しかし**曜日まで整合した、それらしい日付**は見落とされます。生成AIの誤りが危険なのは、間違いが目立たない形で紛れ込むからです。**デザイン内の数値・日付・固有名詞は、AIに生成させるのではなく、確定した値をこちらから与える**のが安全な設計です。編集APIの `replace_text` で後から正しい値を差し込む運用も有効です。 ## 実践②：ブログのヒーロー／OGP画像をつくる 次に、この記事自身の画像を作ります。Web制作の現場でよく必要になる**「記事のヒーロー画像（横長）とOGP画像（1200×630）」**という実用ケースです。 ここで問題になるのがサイズです。Canvaの `design_type` には「OGP画像」という選択肢がなく、近いのは `twitter_post`（実測 1600×900）です。今回は次の方針を取りました。 ``` 1. generate-design (twitter_post) で 1600×900 のバナーを生成 2. export-design で PNG 書き出し 3. ローカルで用途別にトリミング・リサイズ - ヒーロー用: 中央帯を切り出して 1920×720 - OGP用 : 上下を少し詰めて 1200×630（≒1.905:1） ``` `resize-design` ツールを使えばCanva側でサイズ変更もできますが、**これはPro以上の有料プラン限定機能**です[4][1]。また、比率が大きく変わる変換では文字組みが崩れることもあるため、「Canvaで作る → 最終的な出力比率はビルド側で確定させる」という分業のほうが、Webサイトへの組み込みでは扱いやすいと感じました。 書き出し可能な形式は `get-export-formats` で確認できます。今回のバナーでは **pdf / jpg / png / pptx / gif / mp4** が返りました。公式ドキュメントも、対応形式はデザインごとに異なるため**事前に `get-export-formats` で確認してから `export-design` を呼ぶこと**を求めています。形式を決め打ちすると失敗します。 ## 実践③：編集トランザクションAPIでデザインを"コードで"直す 生成された画像は良い雰囲気でしたが、サブタイトルの文字が小さすぎました。ここでCanva MCPの最も"エンジニアリング寄り"な機能、**編集トランザクション**の出番です。 ### トランザクションの3ステップ ``` start-editing-transaction → transaction_id と全要素の構造を取得 perform-editing-operations → 編集操作を（複数まとめて）適用（この時点ではドラフト） commit-editing-transaction → 確定して保存 cancel-editing-transaction → 破棄 ``` ** コミットを忘れると変更は消える ツール仕様に「Changes are in DRAFT only until committed — they will be PERMANENTLY LOST if you do not call `commit-editing-transaction`」と明記されています。**コミットするまでの編集はすべて下書き**で、失敗すればトランザクション内の変更は全て失われ、やり直しには新しいトランザクションが必要です。逆に言えば**途中経過が本番デザインを壊さない**ということでもあり、AIに編集させるうえでは安心できる設計です。 ### デザインが構造化データとして返ってくる `start-editing-transaction` を呼ぶと、デザインの中身が完全な構造データとして返ります。これが編集APIの本質です。 ``` { "transaction": { "status": "open", "transaction_id": "6021823355239838297" }, "richtexts": [ { "element_id": "PBp0yWztFdlLtTRN-LBkDD5fv59dB7xqT", "regions": [{ "type": "character", "text": "AIエージェントがSNS投稿とWeb制作素材をつくる" }], "containerElement": { "type": "TEXT", "position": { "top": 321.31, "left": 636.8 }, "dimension": { "width": 326.4, "height": 16.17 } } }, { "element_id": "PBp0yWztFdlLtTRN-LBJrm4Pyk00lGtt8", "regions": [{ "type": "character", "text": "Canva MCP × Claude Code" }], ... } ], "fills": [ { "type": "image", "asset_id": "MAHQbxakfeA", "editable": true, ... } ], "pages": [ { "page_id": "PBp0yWztFdlLtTRN", "dimension": { "width": 1600, "height": 900 }, "is_responsive": false, "is_editable": true } ] } ``` 要素ID・テキスト内容・座標・寸法・画像アセットIDが揃っているため、**「サブタイトルの幅を760pxに広げ、中央に寄せ、30pxの太字にする」**といった指示をピクセル単位で組み立てられます。実際に投げた操作は次のとおりです。 ``` [ { "type": "resize_element", "element_id": "...LBkDD5fv59dB7xqT", "width": 760 }, { "type": "position_element", "element_id": "...LBkDD5fv59dB7xqT", "top": 310, "left": 420 }, { "type": "format_text", "element_id": "...LBkDD5fv59dB7xqT", "formatting": { "font_size": 30, "color": "#5EC8F5", "text_align": "center", "font_weight": "bold" } } ] ``` 結果、豆粒だったサブタイトルが読めるサイズになりました。**このページ最上部のヒーロー画像が、その適用後の状態です。** ### 実際に遭遇した失敗：部分成功する 同じ呼び出しで、空のテキスト要素に社名クレジットを入れようとした操作は失敗しました。注目すべきは、**1回の呼び出しの中で成功と失敗が混在した**ことです。 ``` "edit_operation_results": [ { "status": "success", "operation_info": { "type": "resize_element", ... } }, { "status": "success", "operation_info": { "type": "position_element", ... } }, { "status": "success", "operation_info": { "type": "format_text", ... } }, { "status": "failure", "operation_info": { "type": "replace_text", ... }, "error": { "code": "internal_error", "message": "Unexpected error occurred when processing this operation" } }, { "status": "success", "operation_info": { "type": "resize_element", ... } }, { "status": "success", "operation_info": { "type": "position_element", ... } }, { "status": "failure", "operation_info": { "type": "format_text", ... }, "error": { "code": "internal_error", ... } } ] ``` 失敗したのは、いずれも**テキストが空の要素に対する `replace_text` と `format_text`**でした。同じ要素への `resize_element` と `position_element` は成功しています。テンプレートに残った空のテキストプレースホルダは、文字を流し込む対象としては扱えなかったことになります（今回は `delete_element` で削除して解決しました）。 ** 自動化を組むなら「全体成功」を前提にしない この挙動は、パイプラインを設計するうえで重要です。**呼び出しが例外にならなくても、個々の操作は失敗し得ます**。`edit_operation_results` の各要素の `status` を必ず検査し、失敗があればコミットせずに `cancel-editing-transaction` で破棄する——という制御を入れておくべきです。「エラーが返らなかった＝意図どおりに直った」ではありません。 ### レスポンスが大きい点にも注意 編集トランザクションのレスポンスは、要素数に比例して大きくなります。Claude Codeは**MCPツールの出力が10,000トークンを超えると警告を表示し、既定では25,000トークンで打ち切ります**（上限は `MAX_MCP_OUTPUT_TOKENS` 環境変数で引き上げ可能）[3]。ページ数の多いプレゼンテーションを丸ごと編集させる用途では、この制限に当たる可能性があります。ページ単位で処理を分割する設計が無難です。 ## プラン別制限とレート制限 導入前に必ず確認すべき部分です。ここは特に慎重に、公式の記載をそのまま引きます。 ### プラン要件 CanvaのAI ConnectorページのFAQは、「**すべてのCanvaプランがAIアシスタントに接続できます。Canva Freeを含みます**」と明言しています。そのうえで機能ごとの制限として、「**リサイズは有料のCanvaプランのみ**」「**オートフィルとブランドテンプレートはEnterpriseプランのみ**」と記載しています[1]。 ** 公式ドキュメント間に表記の差がある 正確を期すために付記します。上記のFAQは「ブランドテンプレートはEnterpriseのみ」としていますが、開発者向けのツール一覧[4]では `search-brand-templates` / `list-brand-kits` / `create-design-from-brand-template` が「**Pro and above**」と記載されています（`autofill-design` と `get-brand-template-dataset` は「Enterprise only」）。**2026年7月26日時点で、この2つの公式記載は一致していません。**ブランド機能の利用可否がプラン選定の決め手になる場合は、ドキュメントだけで判断せず、実際のアカウントで疎通確認を行うことをおすすめします。 ### レート制限（公式ドキュメント記載値） | ツール | レート制限 | 備考 | | `generate-design` | 20 req/min | 生成は重い処理。全プラン | | `create-design-from-candidate` | 20 req/min | 全プラン | | `export-design` | 20 req/min | 品質はプランにより異なる | | `perform-editing-operations` | 50 req/min | 複数操作をまとめて送れるため実質の余裕は大きい | | `upload-asset-from-url` | 30 req/min | 全プラン | | 検索・取得系（`search-designs`, `get-design` ほか） | 100 req/min | 全プラン | | `resize-design` | 20 req/min | **Pro以上** | | `resolve-shortlink` | 制限なし | 全プラン | 出典：Canva「MCP tools and rate limits」[4]（2026年7月26日時点） **生成と書き出しが20 req/min**という点は、バッチ処理を設計するうえで効いてきます。「100商品分のSNS画像を一括生成」といった用途では、1分あたり20件がボトルネックになります。数百枚規模の量産を想定するなら、リトライとスロットリングを前提にした実装が必要です。 ## 商用利用ライセンスの落とし穴 技術的に動くことと、業務で使ってよいことは別問題です。制作会社として、また発注する側としても、ここは押さえておく必要があります。 CanvaのContent License Agreementは、広告・販促物・印刷物・パッケージ・プレゼンテーション・映像・カタログ・ブローシャーといった用途での利用を、**複製数の上限なし**で認めています[5]。SNS投稿画像やWebサイトのバナーは、通常この範囲に収まります。 一方で、明確に禁止されている行為があります。 ** 特に注意すべき2つの禁止事項 - **商標・ロゴへの利用は不可**——「use any of the Content as part of a trade-mark, design-mark, trade-name, business name or service mark（**フォントを除く**）」が禁止行為として挙げられています[5]。Canvaの素材は非独占ライセンスであり、同じ素材を他社も使えるためです。**「AIにロゴを作らせる」用途にはそのまま使えません。** - **素材そのものの再配布・再販は不可**——「sub-license, re-sell, rent, lend, assign, gift or otherwise transfer or distribute the Content」が禁止されています[5]。生成した素材を「テンプレート集」として販売するような使い方は範囲外です。 受託制作でクライアントに納品する場合、**成果物としての制作物の納品**と、**素材そのものの譲渡**は区別して考える必要があります。ロゴやコーポレートアイデンティティに関わる領域は、Canva素材ではなくオリジナル制作で対応するのが安全です。案件の性質に応じて、契約条件を確認したうえでご判断ください。 ** セキュリティ上の注意：プロンプトインジェクション Claude Code公式ドキュメントは、MCPサーバ全般について「**Verify you trust each server before connecting it. Servers that fetch external content can expose you to prompt injection risk**」と警告しています[3]。Canva MCPは公式提供のサーバですが、`import-design-from-url` や `upload-asset-from-url` のように外部URLを取り込む機能を持ちます。**信頼できないURLをAIエージェントに渡さない**という基本原則は、ここでも有効です。 ## どこまで自動化すべきか 今回の検証を踏まえた、弊社としての現時点の整理です。 | 用途 | 適性 | 理由 | | ブログのOGP・アイキャッチ量産 | ◎ 向く | 体裁が定型で、誤情報が入り込む余地が小さい。テキストは自分で確定させて流し込める | | SNS告知画像の下書き | ◯ 条件付き | 速さの恩恵は大きいが、公開前の目視確認が必須。日付・数値・固有名詞は生成させない | | 既存デザインの一括テキスト差し替え | ◎ 向く | 編集トランザクションが構造データを返すため、機械的に正確。多言語展開との相性も良い | | キャンペーンLPのメインビジュアル | △ 慎重に | ブランド表現の一貫性はプロンプトでは担保しきれない。ブランドキット活用が前提 | | ロゴ・CI制作 | × 不可 | ライセンス上、商標としての利用が禁止されている | | 価格表・仕様表など数値を含む資料 | × 避ける | 生成AIが数値を書き換える／補完するリスク。誤りが最も表面化しにくい領域 | 要点は**「レイアウトはAIに、事実は人間に」**です。Canva MCPが本当に強いのは、ゼロから絵を描かせることよりも、**確定した正しい情報を、整った体裁に流し込む工程**だと感じました。編集トランザクションAPIで `replace_text` を使えば、テキストの正しさは完全にこちらの管理下に置けます。 ## よくある質問（FAQ） ### Q. Canva MCPは無料プランでも使えますか？ Canva公式のAI Connectorページでは「すべてのCanvaプランがAIアシスタントに接続できます（Canva Freeを含む）」と案内されています[1]。ただし**リサイズは有料プラン、オートフィルとブランドテンプレートはEnterpriseプラン限定**とされています。なお公式ドキュメント間でブランド系機能の要件表記に差があるため、詳細はプラン別制限の章をご確認ください。 ### Q. Claude Code以外のAIツールからも使えますか？ 使えます。Canva公式はChatGPT・Claude・Amazon Quick Suiteを提供中、Google Geminiを近日、Microsoft Copilotをプレビューとして掲載しています[1]。加えて、MCPに対応したクライアントであれば `https://mcp.canva.com/mcp` に接続できます。本記事の検証はClaude Code（CLI）で行いました。 ### Q. AIが生成したデザインをそのまま公開してよいですか？ 推奨しません。今回の検証だけでも、**日本語の文字化け**、**架空のURL・肩書きの混入**、**指示していない日付の挿入**という3種類の問題が実際に発生しました。詳細は落とし穴の章をご覧ください。公開前の目視確認は必須の工程です。 ### Q. 生成した画像を商用利用・クライアント納品できますか？ CanvaのContent License Agreementでは、広告・販促物・パッケージ・プレゼンなど幅広い商用利用が認められています[5]。ただし**商標・ロゴの一部としての利用（フォントを除く）**と**素材そのものの再販・再配布**は禁止されています。詳細はライセンスの章をご確認ください。ロゴやCIに関わる制作は、オリジナルで対応するのが安全です。 ### Q. 大量の画像を一括生成できますか？ 可能ですが、`generate-design` と `export-design` がいずれも**20 req/min**のレート制限を持ちます[4]。数百枚規模ではスロットリングとリトライを前提にした実装が必要です。定型フォーマットへのデータ流し込みであれば、生成ではなくブランドテンプレートのオートフィル（Enterprise）や編集トランザクションによるテキスト差し替えのほうが、速度・正確性ともに有利です。 ### Q. 社内でチーム共有できますか？ 接続設定は `.mcp.json` をリポジトリに含めることでチーム配布できますが、**認証はユーザー単位**で、利用者それぞれがCanvaアカウントで認証する必要があります[2]。AIが操作できる範囲は、そのユーザーがCanva上で持つアクセス権の範囲に限られます。 ## まとめ ** この記事のまとめ - Canva公式のリモートMCPサーバ（`https://mcp.canva.com/mcp`）に `claude mcp add --transport http` と `/mcp` の2ステップで接続でき、33のツールが利用可能になった - SNS投稿画像（1080×1350）とブログのヒーロー／OGP画像を、Canvaの編集画面を開かずに生成・編集・書き出しできた。所要時間は1枚あたり数分 - 編集トランザクションAPIはデザインを要素ID・座標・寸法の構造データとして返すため、ピクセル単位の調整をコードで指示できる。コミットするまでは下書きで、本番デザインは壊れない - ただし**1回の呼び出しで操作が部分的に失敗し得る**。`edit_operation_results` の各 `status` の検査は必須 - 生成結果には**日本語の文字化け・架空のURL/肩書き・指示していない日付**が実際に混入した。公開前の人間による確認は省略できない - プラン制限（リサイズは有料／オートフィル・ブランドテンプレートはEnterprise）とレート制限（生成・書き出しは20 req/min）、および**商標・ロゴへの利用禁止**が実務上の制約になる 結論として、Canva MCPは**「デザイナーの代替」ではなく「制作パイプラインの部品」**として優秀です。特に、確定した情報を定型フォーマットへ流し込む工程——記事のアイキャッチ量産、多言語版の一括差し替え、定期レポートの体裁整形——では、すぐに投資対効果が出ます。逆に、ブランドの根幹に関わる表現や、数値・日付の正確性が問われる資料は、人間が主導すべき領域が明確に残ります。 テクノスフィアでは、MCPサーバを組み込んだ[AIエージェント基盤](https://technosphere.co.jp/ai-solution)の設計・構築や、社内業務ツールとAIの連携（Redmine・Obsidian・社内Wikiなど）の実装をご支援しています。「デザイン以外の業務も同じ発想で自動化できないか」といったご相談も歓迎です。 [AIソリューション](https://technosphere.co.jp/ai-solution) ｜ [AIエージェントの業務自動化事例](https://technosphere.co.jp/blog/openclaw-skills-obsidian-redmine) ｜ [開発の相談をする](https://technosphere.co.jp/contact) ## 参考文献・出典 1. Canva「Canva's AI Connector」公式ページ（対応AIアシスタント、プラン要件のFAQ） — [canva.com/ai-connector/](https://www.canva.com/ai-connector/) 2. Canva Developers「Canva Model Context Protocol (MCP)」（エンドポイント、CIMD/DCR認証、アクセス権の範囲） — [canva.dev/docs/mcp/](https://www.canva.dev/docs/mcp/) 3. Anthropic「Connect Claude Code to tools via MCP」（`claude mcp add` の構文、`/mcp` によるOAuth認証、MCP出力トークン上限、プロンプトインジェクションの注意） — [code.claude.com/docs/en/mcp](https://code.claude.com/docs/en/mcp) 4. Canva Developers「MCP tools and rate limits」（全ツールのレート制限とプラン要件） — [canva.dev/docs/mcp/tools/](https://www.canva.dev/docs/mcp/tools/) 5. Canva「Content License Agreement」（許諾される商用利用の範囲、商標・ロゴへの利用禁止、再配布の禁止） — [canva.com/policies/content-license-agreement/](https://www.canva.com/policies/content-license-agreement/) 6. Model Context Protocol 公式サイト — [modelcontextprotocol.io](https://modelcontextprotocol.io/) ※本記事に掲載したコマンド出力・APIレスポンス・エラーメッセージは、2026年7月26日に弊社環境（Claude Code + Canva MCP）で実行した結果の抜粋です。プラン要件・レート制限・提供ツールは各社の仕様変更により変わる可能性があります。ライセンスの解釈については各案件の契約条件をご確認のうえ、必要に応じて専門家にご相談ください。Canvaは Canva Pty Ltd、Claude および Claude Code は Anthropic PBC の商標です。 AIエージェントに業務を任せる実例は[Obsidian作業ログ＋Redmineチケット運用の完全自動化](https://technosphere.co.jp/blog/openclaw-skills-obsidian-redmine)、社内AI基盤の構築は[AIエージェント基盤の環境構築ガイド](https://technosphere.co.jp/blog/openclaw-getting-started)でも紹介しています。 [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # AIによる需要予測システムの作り方｜小売・流通の発注最適化を支えるデータ設計と機械学習｜株式会社テクノスフィア > 勘と経験の発注から、データに基づく需要予測へ。商品単位で「売れる確率」を予測するAIシステムを、どんなデータで・どんなモデルで・どう運用して作るのか。売上実績・イベント・天候・商圏属性を組み合わせた需要予測の実装と運用のポイントを解説します。 URL: https://technosphere.co.jp/blog/demand-forecasting-ai ** 目次 1. なぜ今、需要予測なのか 2. 需要予測システムは「何を返す」のか 3. 精度を決めるのは「データ設計」 4. どんな機械学習モデルを使うか 5. システム構成：予測を「API」で届ける 6. 精度評価と運用（再学習・コールドスタート） 7. よくある失敗 8. よくある質問 9. まとめ ** この記事でわかること 小売・流通における需要予測AIの全体像を、「**何を予測するか**」「**どんなデータを使うか**」「**どんなモデルで作るか**」「**どう運用するか**」の順で解説します。発注・在庫の最適化を検討している方、需要予測の内製・外注を比較したい方に向けた内容です。 ## なぜ今、需要予測なのか 小売・流通の現場では、「**いくつ仕入れるか**」「**いくつ作るか**」の判断が日々繰り返されています。この判断を誤ると、すぐに損失に直結します。 - **欠品：**売れるはずの商品が棚にない。機会損失と顧客離れを招く - **過剰在庫・廃棄ロス：**作りすぎ・仕入れすぎで、値引き販売や廃棄に。食品ではとくに深刻 - **属人化：**発注がベテランの勘に依存し、担当者が変わると精度が落ちる 長らくこの判断は「**勘と経験**」に支えられてきました。熟練者の暗黙知は確かに強力ですが、再現性がなく、人手不足のなかで継承が難しくなっています。一方で、**POSデータをはじめとするデータは年々蓄積**されています。この蓄積されたデータと外部要因を機械学習で結びつけ、**誰がやっても一定水準の発注判断**を支援するのが需要予測AIです。 ** 需要予測AIは「人を置き換える」ものではない 需要予測の目的は、発注担当者を不要にすることではありません。**判断の土台となる客観的な数字を提示し、人はそれを見て最終判断する**──この分担が現実的です。AIが「この商品は明日◯個売れる確率が高い」と示し、担当者が現場感覚と突き合わせて発注する。属人化を緩和しつつ、現場の知見も活かせます。 ## 需要予測システムは「何を返す」のか 需要予測と一口に言っても、出力の形はさまざまです。実務でよく使われるのは、**商品（たとえばJANコード）単位**で、次のような値を返す形です。 | 出力 | 意味 | 使いどころ | | **売れる確率** | その商品が対象期間に売れる見込みの高さ | 取扱・棚割り・発注可否の判断 | | **予測販売数** | 対象期間に売れると見込む数量 | 発注数・生産数の算出 | | **確信度** | 予測自体の確からしさ | 確信度が低い商品だけ人が確認 | | **要因（factors）** | 予測に効いた要素の内訳 | 「なぜその数字か」の説明・納得 | 重要なのは、単に数字を 1 つ返すだけでなく、**「確信度」と「要因」を添える**ことです。現場が AI の予測を信頼して使うには、「**なぜその数字なのか**」が見えること、そして「**この予測はどれくらい当てにできるか**」が分かることが欠かせません。 ## 精度を決めるのは「データ設計」 需要予測の精度は、モデルの新しさよりも**「どんなデータを、どう特徴量にするか」**で大きく決まります。最新の手法を使っても、入力データが貧弱なら精度は出ません。実務では、おおむね次の 4 系統のデータを組み合わせます。 （図: 売上実績・イベント・天候・商圏属性の4系統データを需要予測モデルに統合） | データ系統 | 内容 | 特徴量の例 | | **① 売上実績** | POSの販売履歴（核となるデータ） | 当年実績、昨年同期比、直近トレンド、曜日・時間帯傾向 | | **② イベント・暦** | 地域の行事・祝日・セール | イベント有無、規模、連休、給料日後 など | | **③ 天候** | 過去実績と予報 | 気温、降水、晴雨、前日との気温差 | | **④ 商圏属性** | 周辺住民の人口・属性 | 人口統計、世帯構成、商圏の特性 | ①の**売上実績が土台**で、これだけでも一定の予測はできます。そこに②〜④の**外部要因**を足していくことで、「暑い週末＋近隣のイベント」のような**需要が跳ねる場面**を捉えられるようになります。 ** まずは「手元のデータ」から始める 最初から 4 系統すべてを揃える必要はありません。多くの場合、まず**自社のPOS実績だけ**でベースラインを作り、効果を確認しながら天候・イベント・商圏データを足していくのが現実的です。外部データの追加は、精度向上が見込める商品・季節を見極めてから投資する方が無駄がありません。 ## どんな機械学習モデルを使うか 需要予測には時系列モデルや深層学習などさまざまな選択肢がありますが、小売・流通の実務で**まず候補になるのは勾配ブースティング木（XGBoost / LightGBM など）**です。理由は明快です。 - **表形式データに強い：**売上・天候・イベント・属性のような「列が並んだデータ」と相性が良い - **非線形・交互作用を扱える：**「暑い × 週末 × セール」のような複合条件を自動で捉える - **欠損に強い：**一部のデータが欠けていても動く - **説明しやすい：**どの要因が効いたか（特徴量重要度）を出せるため、現場への説明に使える - **軽量で速い：**商品数が多くても現実的な時間で学習・予測できる 深層学習や時系列特化モデルが有効な場面もありますが、**「まず勾配ブースティングで堅実なベースラインを作り、必要に応じて高度化する」**のが費用対効果の高い進め方です。最新・複雑なモデルほど、運用や説明のコストも上がる点は見落とせません。 ／発注・在庫の最適化を検討中の方へ＼ ### 自社データで需要予測を試せます 「うちのPOSデータで精度が出るのか」「まず一部のカテゴリで試したい」──手元のデータを使ったPoCから、API化・本番運用まで一貫してご支援します。 [需要予測について相談する](https://technosphere.co.jp/contact?category=ai_solution) ## システム構成：予測を「API」で届ける モデルが優秀でも、現場で使えなければ意味がありません。需要予測を実務に組み込むうえで有効なのが、**予測を API として提供する**形です。発注システムやPOS・基幹システムから呼び出して、結果を受け取れるようにします。 （図: クライアント → 予測API → 機械学習モデル → 外部データ という需要予測の構成） ``` クライアント（発注システム / 管理画面） │ 店舗・商品・対象日を指定して呼び出し ▼ 予測API（リクエストを受けて結果を返す） │ ▼ 機械学習モデル（勾配ブースティング 等） │ 特徴量を組み立てて推論 ▼ 外部データソース（POS / 気象 / イベント暦 / 統計） ``` API は、店舗・商品・対象日などを受け取り、商品ごとの予測（売れる確率・予測数・確信度・要因）を返します。こうしておくと、 - 既存の発注・基幹システムから**呼び出すだけ**で組み込める - モデルを差し替えても**API の形が同じなら現場影響が小さい** - コンテナ（Docker）やKubernetesで**安定運用・拡張**しやすい テクノスフィアでは、こうした予測APIの設計・実装、外部データ連携、コンテナでの本番運用までを一貫して開発しています。 ## 精度評価と運用（再学習・コールドスタート） 需要予測は「作って終わり」ではありません。**運用し続けて初めて価値が出ます**。導入後に必ず向き合うポイントを挙げます。 （図: 予測値と実績の比較、確信度と要因の可視化イメージ） ### 精度をどう測るか 「当たった／外れた」を感覚で語らず、**誤差を数値で評価**します。予測数と実績の差（MAEやRMSE等）や、欠品・過剰在庫がどれだけ減ったかといった**ビジネス指標**の両面で見るのが大切です。最終的に効くのは「在庫が減ったか」「廃棄が減ったか」です。 ### 再学習（モデルの鮮度を保つ） 売れ方は季節・トレンド・品揃えで変化します。**定期的に最新データで学習し直す**仕組みを最初から組み込んでおきます。放置すると予測は少しずつ実態とずれていきます。 ### コールドスタート（実績のない商品） 新商品や新店舗は過去実績がなく、そのままでは予測できません。**似た商品・似た立地の傾向で補う**などの工夫が要ります。需要予測でつまずきやすい典型ポイントです。 ## よくある失敗 ** 需要予測でつまずきやすい 4 点 - **精度を追い過ぎる：**1%の精度向上に膨大なコストをかけるより、現場が使える形にする方が効果が大きいことが多い - **データ品質を軽視する：**欠品で売上ゼロになった日を「売れなかった」と学習すると予測が崩れる。データの前処理が成否を分ける - **説明性を捨てる：**当たっても「なぜ」が言えないと現場が使わない。要因の提示は機能の一部 - **一気に全店・全商品へ展開する：**まず一部で検証し、効果を見てから広げる。最初から大規模化すると失敗時の損害が大きい 需要予測は「高精度なモデルを作ること」がゴールではなく、**「現場の発注判断が実際に良くなること」**がゴールです。技術と運用、両方の視点が要ります。 ## よくある質問 ** どんなデータが必要ですか？ 中心は過去の売上・販売実績（POS）です。これに地域のイベント・暦、天候、商圏の人口・属性を足すと精度が上がります。まずは手元のデータから始められます。 ** どんなモデルを使いますか？ XGBoostやLightGBMなどの勾配ブースティング木が実務でよく使われます。表形式データに強く、説明性も確保しやすいためです。商品数や粒度に応じて選定します。 ** 既存システムと連携できますか？ 予測をAPIとして提供すれば、発注・POS・基幹システムから呼び出して結果を受け取れます。設計から運用まで支援します。 ** 小さく試せますか？ 一部の店舗・カテゴリに絞り、手元のデータで精度を検証するPoCから始められます。効果を確認してから対象を広げられます。 ## まとめ ### この記事のまとめ - 需要予測AIは、欠品・廃棄ロス・発注の属人化という**小売・流通の根深い課題**に効く - 出力は商品単位の**「売れる確率・予測販売数・確信度・要因」**。確信度と要因を添えることが現場活用の鍵 - 精度を決めるのは**データ設計**。売上実績を土台に、イベント・天候・商圏属性を組み合わせる - モデルは**勾配ブースティング（XGBoost/LightGBM）**がまず候補。表形式に強く説明しやすい - 予測は**API化**して既存システムから呼び出す。コンテナで安定運用 - 運用では**再学習・コールドスタート・精度評価**が要点。「作って終わり」にしない - ゴールは高精度ではなく**「現場の発注判断が実際に良くなること」** テクノスフィアは、需要予測をはじめとする**データ活用・機械学習システムの開発**を、データ設計・モデル構築・API化・本番運用まで一貫して手がけています。「自社のデータで予測精度が出るのか確かめたい」「発注・在庫の最適化を検討している」といったご相談を歓迎します。 ／需要予測・データ活用のPoC・ご相談はこちら＼ ### 自社データで、需要予測を始めませんか？ 発注・在庫の最適化、廃棄ロスの削減、属人化の解消──需要予測AIで解ける課題は多くあります。テクノスフィアは、手元のデータを使ったPoCから、API化・既存システム連携・本番運用までを一貫してご支援します。まずは「自社データで精度が出るか」のご相談から。 [AI開発サービスを見る](https://technosphere.co.jp/ai-solution) [需要予測を相談する](https://technosphere.co.jp/contact?category=ai_solution) # 需要予測 # AI # 機械学習 # 発注最適化 # 在庫最適化 # 小売DX # データ分析 # API開発 ## 関連記事・サービス - [サービス AI ソリューション開発 データ活用・機械学習システムの開発支援](https://technosphere.co.jp/ai-solution) - [関連記事 RAGチャットボット社内ヘルプデスク導入事例 社内データ活用 × AI の代表例](https://technosphere.co.jp/blog/what-is-rag-chatbot) - [関連記事 全作業を証跡化する開発運用 品質と説明責任を担保する開発体制](https://technosphere.co.jp/blog/ai-development-audit-trail) - [お問い合わせ 需要予測・データ活用を相談する 自社データでのPoCから](https://technosphere.co.jp/contact?category=ai_solution) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # EUサイバーレジリエンス法（CRA）と組込み機器｜STM32での実務対応ガイド｜株式会社テクノスフィア > EUサイバーレジリエンス法（CRA）の対象判定・クラス分け・2026年9月11日開始の脆弱性報告義務を整理し、STM32のRDP・セキュアブート・TrustZone・SBOM作成まで組込みエンジニア向けに実務対応を解説。組込み開発歴20年超のエンジニアが在籍するテクノスフィアが解説。 URL: https://technosphere.co.jp/blog/embedded-cra-compliance-stm32 ** 目次 1. はじめに：なぜ「いま」CRAなのか 2. CRAの適用スケジュール（期日の全体像） 3. 自社製品はCRA対象か？ 判定フロー 4. クラス分け：default / important / critical 5. 2026年9月11日までにやるべきこと：脆弱性報告体制 6. 2027年12月11日に向けて：必須要件（附属書I）の概観 7. STM32での技術対応：RDP・セキュアブート・TrustZone・更新機構 8. SBOMの現実的な作り方 9. FreeRTOS・ZephyrなどOSS利用時の扱い 10. 実務チェックリスト 11. まとめ ## はじめに：なぜ「いま」CRAなのか **EUサイバーレジリエンス法（Cyber Resilience Act / CRA、Regulation (EU) 2024/2847）**は、EU市場に上市される「デジタル要素を持つ製品（products with digital elements）」に対して、設計段階からのセキュリティ確保（セキュリティ・バイ・デザイン）と、販売後の脆弱性対応・報告を法的義務として課すEU規則です。2024年12月10日に発効済みで、対象製品は最終的に**CEマーキングの要件としてサイバーセキュリティ適合が求められる**ようになります。 重要なのは、これが「EU企業の話」ではないことです。CRAは**EU市場に製品を上市するすべての製造者**に適用されるため、日本からEUに機器を輸出しているメーカーも当事者です。そしてマイコン1個で動く計測器・産業用コントローラ・IoTセンサーノードのような、これまで「セキュリティ規制とは無縁」だったB2B組込み機器の多くが対象に含まれます。 特に急ぐべき理由が期日です。**2026年9月11日から、第14条の脆弱性・インシデント報告義務が適用開始**されます。本記事執筆時点（2026年7月）で残り2か月。しかもこの報告義務は、後述のとおり**すでにEUで販売中の既存製品にも適用**されます。「2027年12月の全面適用まで時間がある」という理解は、この点で誤りです。 本記事では、法律の一般論ではなく「STM32ベースの製品を持つ組込みエンジニア・品質保証担当が、何を・いつまでに・どうやるか」に絞って解説します。STM32のRTOS開発の基礎は [STM32 + FreeRTOS 入門](https://technosphere.co.jp/blog/stm32-freertos-intro)、通信ペリフェラルの実装は [STM32マイコンのUART・I2C・SPI・CAN通信 実装ガイド](https://technosphere.co.jp/blog/stm32-uart-i2c-can) も併せてご覧ください。 ** 免責事項（必ずお読みください） 本記事は組込み開発の実務者向けに、規制原文の該当条項と実務での一般的解釈を整理した技術解説であり、**法的助言ではありません**。条文の解釈には幅があり、整合規格・ガイダンスも今後更新されます。自社製品の該当性・適合方針の最終判断は、必ず**弁護士（EU法務）や認証機関・Notified Bodyに確認**してください。 ## CRAの適用スケジュール（期日の全体像） CRAは段階適用です。エンジニアリング計画に直結するため、まず期日を正確に押さえます（第71条）。 | 期日 | 何が起こるか | 実務への意味 | | **2024年12月10日** | CRA発効（entry into force） | 規則として成立済み。猶予期間中 | | 2026年6月11日 | 適合性評価機関（Notified Body）の通知に関する章が適用開始 | 第三者評価の受け皿が立ち上がる | | **2026年9月11日** | **第14条：脆弱性・インシデント報告義務が適用開始** | 積極的に悪用された脆弱性・重大インシデントの24時間以内の早期警告等。**既存製品にも適用** | | **2027年12月11日** | 残りの主要義務が全面適用 | セキュリティ・バイ・デザイン（附属書I）、SBOM、サポート期間、適合性評価＋CEマーキング。以降に上市する製品はフル対応必須 | ### 既存製品の扱い（第69条）— 実務上の最重要ポイント 経過措置（第69条）は次の構造です。 - **第69条2項：**2027年12月11日より前に上市済みの製品は、それ以降に**大幅な改変（substantial modification）**を行わない限り、CRAの要件の対象外（次項の第14条報告義務を除く） - **第69条3項：**ただしその**例外として、第14条の報告義務は上市済み製品にも適用**される つまり「古い製品だから関係ない」は報告義務については通用しません。逆に、ファームウェアの大幅な機能追加は「大幅な改変」として既存製品を丸ごとCRAの適用対象に引き込む可能性があるため、2027年12月以降の既存製品のアップデート計画は法務と併せて設計する必要があります（何が「大幅な改変」に当たるかはガイダンスの解釈が分かれる領域です）。 なお、違反時の制裁金は必須要件違反で**最大1,500万ユーロまたは全世界年間売上高の2.5%のいずれか高い方**（第64条）と、GDPR同様の域外企業にも効く水準です。 ## 自社製品はCRA対象か？ 判定フロー CRAの対象は「デジタル要素を持つ製品」＝**ハードウェアまたはソフトウェアであって、デバイスやネットワークへの直接的または間接的な論理的・物理的データ接続を持つもの**（第2条・第3条の定義）です。実務では次の順で判定します。 1. **EU市場に上市（placing on the market）するか？** EU域内の顧客・代理店経由で販売するならYes。日本国内専用モデルは対象外。ただし同一ファームをEU向けと共用しているなら実質的に対応が必要です。 2. **デジタル要素とデータ接続があるか？** マイコン搭載機器はほぼ該当します。Ethernet/Wi-Fi/BLEはもちろん、**USB・UART・CANなどのローカル接続も「デバイスへの接続」**に含まれ得るというのが一般的な解釈です。スタンドアロンで一切の外部接続を持たない機器のみが外れます。 3. **他のEU法制の適用除外に該当するか？** 医療機器（MDR/IVDR）、自動車（型式認証規則）、航空、船舶用機器など、既にサイバーセキュリティ要件を持つセクター規制の対象製品はCRAから除外されます（第2条）。産業機器は多くの場合除外に該当せず、CRA対象です。 4. **純粋なサービス（SaaS）か？** クラウドサービス単体はNIS2の領域ですが、製品の機能に不可欠な「遠隔データ処理（remote data processing solutions）」は製品側のCRA適用範囲に含まれます。機器＋専用クラウドの構成は要注意です。 ** 実務の勘所 迷いやすいのは「B2Bの産業機器」「モジュール・基板単体での販売」です。CRAは消費者製品に限定されず**B2B製品も対象**です。また、他社製品に組み込まれる部品（マイコンボード等）を上市する場合、その部品自体が「デジタル要素を持つ製品」として義務を負い得ます。自社が「最終製品メーカー」なのか「コンポーネント供給者」なのかで負う義務の整理が変わるため、この線引きこそ認証機関・法務への確認事項です。 ## クラス分け：default / important / critical CRA対象と判定されたら、次は製品カテゴリの確認です。カテゴリによって適合性評価の重さが変わります。 | カテゴリ | 根拠 | 例 | 適合性評価 | | **default（デフォルト）** | 附属書III/IVに該当しないすべて | 一般的な産業機器、計測器、IoTセンサー、家電の大半 | **自己適合宣言（内部管理、モジュールA）**が可能 | | **important Class I** | 附属書III Class I | OS、ブートマネージャ、VPN機能を持つ製品、パスワードマネージャ、スマートホームのセキュリティ機器、**セキュリティ関連機能を持つマイクロコントローラ／マイクロプロセッサ** など | 整合規格に完全準拠すれば自己適合宣言可。そうでなければ第三者評価 | | **important Class II** | 附属書III Class II | ファイアウォール・IDS/IPS、ハイパーバイザ、**耐タンパー性マイクロコントローラ／マイクロプロセッサ** など | 第三者（Notified Body）評価が必須 | | **critical（重要）** | 附属書IV | セキュリティボックスを備えたハードウェア、スマートメーターゲートウェイ、スマートカード・セキュアエレメント | 将来的に欧州サイバーセキュリティ認証（EUCC等）の取得を義務付け得る | 「マイコンが附属書IIIに載っている」と聞いて驚くかもしれませんが、これは**セキュリティ関連機能を持つMCU/MPUそのものを上市する半導体メーカー等に向けた分類**です。STM32を「使った」最終製品の分類は、最終製品の機能・用途で判定します。一般的な産業機器・計測機器の多くは**defaultカテゴリに落ち、自己適合宣言で対応可能**というのが現時点の一般的な整理です。なお、各カテゴリの技術的定義は実施規則（Commission Implementing Regulation (EU) 2025/2392、2025年12月発効）で定められているため、境界事例は必ず同規則と最新ガイダンスで確認してください。 ## 2026年9月11日までにやるべきこと：脆弱性報告体制 第14条が求めるのは、次の2種類の事象の報告です。 - **積極的に悪用されている脆弱性（actively exploited vulnerability）：**自社製品に含まれる脆弱性で、実際に悪用されている信頼できる証拠があるもの - **製品のセキュリティに影響する重大インシデント（severe incident）：**製品がデータや機能の機密性・完全性・可用性等を保護する能力に悪影響を与える（与え得る）インシデント ### 報告のタイムライン（第14条） | 期限 | 提出物 | 内容 | | **認知から24時間以内** | 早期警告（early warning） | 悪用/インシデントの発生事実。詳細不要、まず「知らせる」 | | 認知から72時間以内 | 脆弱性/インシデント通知 | 概要、深刻度・影響、是正・緩和策の状況 | | 脆弱性：是正措置提供後14日以内 インシデント：72時間通知の提出後1か月以内 | 最終報告 | 脆弱性の詳細・根本原因、講じた是正措置等 | 提出先は、ENISAが整備する**単一報告プラットフォーム（Single Reporting Platform）**経由で、主たる拠点のある加盟国の**CSIRT**に報告し、原則として同時に**ENISA**にも共有されます（第16条）。EU域内に拠点を持たない日本メーカーの場合、どの加盟国のCSIRTが窓口になるか（授権代理人の設置を含む）を事前に整理しておく必要があります。 ### 「24時間」を守れる体制を逆算する 24時間という期限は、技術対応ではなく**組織対応の速度**の問題です。9月11日までに最低限、次を整備してください。 1. **脆弱性受付窓口の開設：**製品セキュリティ専用の連絡先（例：`psirt@自社ドメイン`）を用意し、Webサイトに**脆弱性開示ポリシー（CVD：協調的脆弱性開示）**を掲載する。`/.well-known/security.txt` の設置も外部研究者からの通報経路として有効です。なおCVDポリシーの整備自体、附属書I第II部が求める項目です 2. **トリアージ基準の文書化：**「積極的に悪用されている」「重大インシデント」に当たるかを誰がどう判断するか。判断者・代理者・休日夜間の連絡網を決める（24時間の起点は「認知」です） 3. **報告テンプレートの準備：**早期警告・72時間通知・最終報告の3段階それぞれについて、埋めるべき項目を日英で雛形化しておく 4. **製品−ファーム−顧客の追跡性：**「どの製品のどのファームバージョンがEUのどこで稼働しているか」を答えられる台帳。SBOM（後述）はこの基盤になります 5. **机上訓練：**「FreeRTOSのCVEが公表され、自社製品への影響をX時間で判断→24時間以内に早期警告」という想定でリハーサルを1回やっておくと、穴が具体的に見えます ** よくある誤解 第14条の報告対象は「積極的に悪用されている」脆弱性であり、**すべての脆弱性を24時間以内に報告する義務ではありません**。ただし悪用有無の判断には脆弱性情報の収集・トリアージ体制が前提になるため、実務上は「全脆弱性を受け付け、悪用兆候を判定するプロセス」を作ることになります。 ## 2027年12月11日に向けて：必須要件（附属書I）の概観 2027年12月11日以降に上市する製品には、附属書Iの必須要件（essential requirements）への適合と、技術文書・適合性評価・CEマーキングが求められます。組込み機器に効いてくる主要項目を挙げます。 ### 第I部：製品の性質に関する要件（設計・開発・製造段階） - リスクアセスメントに基づく設計（サイバーセキュリティリスク評価は技術文書の一部） - **既知の悪用可能な脆弱性がない状態**で上市すること - **セキュア・バイ・デフォルト**の構成（初期パスワード共通化の禁止など） - **セキュリティアップデート**による脆弱性対処の仕組み（原則、自動更新または容易な更新手段） - 不正アクセスからの保護（認証・アクセス制御）、保存・伝送データの暗号化等による機密性・完全性の保護 - 攻撃対象領域（アタックサーフェス）の最小化、悪用緩和メカニズム - セキュリティ関連イベントの記録・監視機能 ### 第II部：脆弱性ハンドリング要件（販売後も継続） - 製品に含まれる脆弱性・コンポーネントの特定・文書化——**少なくともトップレベル依存関係をカバーするSBOM**を機械可読形式で作成 - 脆弱性の遅滞ない修正と**無償のセキュリティアップデート**提供 - 協調的脆弱性開示（CVD）ポリシーの整備・公開 - 修正済み脆弱性の情報公開、更新の配布メカニズム これらを**サポート期間**にわたって続ける義務があります。サポート期間は製品の想定使用期間を反映して製造者が定めますが、**原則として最低5年**（想定使用期間がそれより短い場合を除く）です（第13条8項）。産業機器は10年以上使われることが珍しくないため、「5年でサポート終了」と宣言できるかは顧客契約・市場実態と併せた経営判断になります。 ## STM32での技術対応:RDP・セキュアブート・TrustZone・更新機構 ここからが本題です。附属書Iの要件を、STM32ベースの製品でどう実装に落とすか。STMicroelectronicsはセキュリティ機能群を**STM32Trust**という枠組みで整理しており、CRA対応の技術的な部品はかなり揃っています。ただし冒頭から強調しているとおり、**マイコンの機能を有効化しただけではCRA準拠にはなりません**。以下は「要件→STM32側の対応部品」のマッピングです。 | CRA要件（附属書I） | STM32側の対応機能 | 備考 | | 不正アクセスからの保護、知財・鍵の保護 | RDP（リードアウト保護）、WRP、TrustZone、HUK、OTFDEC | 量産時はRDP設定を製造工程に組み込む | | 完全性の保護、改ざんファームの実行防止 | セキュアブート（署名検証つきブートローダ）、Secure Manager、TF-M | ルート・オブ・トラストの確立 | | セキュリティアップデートの仕組み | SBSFU/署名付きファーム更新、デュアルバンクFlash、アンチロールバック | 配布インフラ・鍵管理は製品側の設計 | | 暗号化・認証 | AES/PKAハードウェアアクセラレータ、TRNG、工場書込みUID | 個体識別・デバイス認証の基盤 | ### 1. RDP（Read-out Protection）— 最低限ここから RDPはFlash内容のデバッガ経由読み出しを防ぐ機能で、従来品種では**レベル0（保護なし）／レベル1（デバッグ経由のFlash読み出し禁止）／レベル2（デバッグポート恒久無効・不可逆）**の3段階です。量産品をRDPレベル0のまま出荷すると、ファームウェアを吸い出されて脆弱性を探索される・クローンされる入口になります。実際、保護の甘いマイコンからのファーム解析がどこまで可能かは [ルネサスRL78のリバースエンジニアリング解説](https://technosphere.co.jp/blog/renesas-rl78-reverse-engineering) で扱ったとおりで、「読み出せる＝解析できる」が現実です。CRAの文脈では、攻撃対象領域の最小化・知財と鍵材の保護の観点で、**量産機のRDPレベル1以上は事実上の出発点**と考えるべきです。なおレベル2は不可逆でフィールドでのデバッグ手段を失うため、故障解析フローとセットで判断します（近年のTrustZone対応品種では、パスワード付きでの保護解除（リグレッション）や、H5系の「製品状態（Product State）」による段階管理など、より運用しやすい仕組みが導入されています。品種ごとのリファレンスマニュアルで確認してください）。 ### 2. セキュアブートと更新機構 — 「アップデートの仕組み」要件の中核 附属書Iが求める「セキュリティアップデートで脆弱性に対処できること」は、組込み機器では**署名検証つきのブートローダ＋安全なファーム更新パス**として実装するのが定石です。STM32では次の選択肢があります。 - **SBSFU / STM32Cube拡張パッケージ：**STが提供するセキュアブート＋セキュアファーム更新のリファレンス実装。署名検証、暗号化イメージ、アンチロールバック（バージョン巻き戻し防止）を含む - **TF-M（Trusted Firmware-M）：**TrustZone対応品種（後述）向けのArm標準セキュアファームウェア。MCUboot系のセキュアブートを含み、PSA APIでセキュアサービスを提供 - **Secure Manager：**STM32H5系などで提供される、STがバイナリ提供・保守するターンキーのセキュアファームウェア。自前でセキュア側を書かずにルート・オブ・トラストを確立できる 設計上の要点は3つ。(1) **デュアルバンク／デュアルスロット構成**で更新失敗時に旧イメージへフォールバックできること、(2) **アンチロールバック**で脆弱性のある旧バージョンへの意図的な書き戻しを防ぐこと、(3) **署名鍵の管理**（HSMでの保管、開発鍵と量産鍵の分離、漏えい時のローテーション手順）。CRA監査の観点では「更新をどう配るか」（USB持ち込みか、ゲートウェイ経由OTAか）と「サポート期間中それを誰が運用するか」まで技術文書に書ける状態にします。 ### 3. TrustZone対応品種の選定 Cortex-M33以降の**Arm TrustZone**は、鍵材・暗号処理・ブート検証を「セキュア世界」に隔離し、アプリケーション側の脆弱性が直ちに鍵漏えいに直結しない構造を作れます。STM32では**STM32L5 / STM32U5 / STM32H5 / STM32WBA（無線）**などがTrustZone対応で、STM32U5・H5は**SESIP Level 3 / PSA Certified Level 3**といった第三者セキュリティ認証を取得した品種を持ちます。SESIPは欧州規格（EN 17927）として標準化されており、CRAの整合規格が固まっていく中で、**認証取得済みプラットフォームの採用は適合性評価の説明材料として有利**に働くと見られます（認証がそのままCRA適合を意味するわけではありません）。 既存製品がSTM32F4/F1などTrustZone非対応品の場合でも、RDP＋署名検証ブートローダ＋暗号化更新は実装可能です。「新規設計はTrustZone品種＋TF-M/Secure Manager、既存設計はRDP＋SBSFU系で底上げ」が現実的な使い分けです。 ** マイコン機能で「できないこと」 STM32の機能では、**脆弱性受付窓口の運用、CVE監視とトリアージ、SBOM整備、技術文書・適合宣言、報告義務の履行**は代替できません。これらは製品を上市するメーカーのプロセス整備そのものです。「セキュアなMCUを選んだからCRAはOK」という営業トークには根拠がありません。 ## SBOMの現実的な作り方 附属書I第II部は、製品の脆弱性・コンポーネントを文書化する手段として、**少なくともトップレベル依存関係をカバーするSBOM（ソフトウェア部品表）を、一般に使用される機械可読形式で作成**することを求めています。公開義務はなく、市場監視当局の要求に応じて提出できる状態にしておくのが基本です。 ### フォーマットは SPDX か CycloneDX 機械可読形式のデファクトは**SPDX**（Linux Foundation系、ISO/IEC 5962として標準化）と**CycloneDX**（OWASP系、脆弱性管理との連携が強い）の2つです。組込みでは、脆弱性スキャンツールとの接続性からCycloneDXを選ぶチームが多い印象ですが、どちらでも要件は満たせます。 ### ビルド環境別の現実解 - **Zephyr RTOSの場合：**ビルドシステムに統合済みで、`west spdx --init -d build` → `west build -d build` → `west spdx -d build` でアプリ・Zephyr本体・モジュール依存を含むSPDX文書が自動生成されます。組込みSBOMとしては最も整備された環境です - **STM32CubeIDE + FreeRTOS / HALの場合：**自動生成の仕組みがないため、**「依存コンポーネントの棚卸し→CycloneDX JSONを半手動で作成→CIで検証」**が現実解です。STM32ファームの典型的なトップレベル依存は、FreeRTOSカーネル、STM32Cube HAL/LLドライバ、CMSIS、ミドルウェア（LwIP、mbedTLS、FatFs等）、ブートローダ（MCUboot/SBSFU）と、意外に少数です。各コンポーネントの名称・バージョン・サプライヤ・ライセンスをJSONに起こし、Gitでファームと同一リポジトリ管理します - **補助ツール：**`syft`（ソースツリー/コンテナのスキャン）、`cve-bin-tool`（コンパイル済みバイナリから既知コンポーネントとCVEを検出）、CycloneDXの各言語ツールチェーン。組込みCではパッケージマネージャがない分、自動検出の精度は限定的で、「ツール＋人手の棚卸し」の併用が前提です ### SBOMは「作って終わり」ではない SBOMの本当の価値は第14条対応との接続です。**「FreeRTOS x.y.zにCVEが出た。影響する自社製品はどれか」を数分で答えられる**ことがゴールで、そのためには (1) 製品×ファームバージョン×SBOMの対応表、(2) NVD/ベンダーアドバイザリの定期監視（cve-bin-toolやDependency-Track等での自動照合）、(3) 「影響なし」を表明するVEX（Vulnerability Exploitability eXchange）の運用、までをセットで設計します。 ## FreeRTOS・ZephyrなどOSS利用時の扱い 組込みファームの大半はOSSコンポーネント（FreeRTOS、Zephyr、LwIP、mbedTLS…）を含みます。CRAにおける整理は明確で、**OSSを統合した最終製品の責任は、上市するメーカーが負います**。FreeRTOSの開発元やZephyrプロジェクトが自社製品の脆弱性報告義務を肩代わりすることはありません。 - **統合時のデューデリジェンス（第13条）：**第三者コンポーネント（OSS含む）を統合する際、そのコンポーネントが製品のセキュリティを損なわないよう相当の注意（due diligence）を払う義務があります。実務では「保守が生きているか（最終リリース日・メンテナ体制）」「既知CVEの有無と対応速度」「セキュリティアドバイザリの発行体制」をコンポーネント選定基準に含めます - **上流への報告：**自社製品に統合したコンポーネントに脆弱性を発見した場合、そのコンポーネントの保守者（OSSプロジェクト）へ報告することも求められます。PSIRTプロセスに「上流への通報」ステップを組み込んでください - **OSSプロジェクト側の扱い：**CRAは営利目的で提供されないOSSそのものには原則適用されず、一定の関与を行う「OSSスチュワード」には軽減された義務のみが課されます。つまり「FreeRTOSがCRA対応してくれるのを待つ」戦略は成立しません - **バージョン規律：**「動いているから触らない」で5年以上前のカーネルを使い続ける文化は、サポート期間中の脆弱性対処義務と正面衝突します。LTSリリース（FreeRTOS LTS、Zephyr LTS）への追従計画と、更新の回帰テスト自動化を今のうちに整えるのが、結局いちばん安上がりです ## 実務チェックリスト ### フェーズ1：2026年9月11日まで（報告義務対応） - ☐ EU向け製品の一覧化（型番・ファームバージョン・販売経路・EU域内の責任者/授権代理人） - ☐ 各製品のCRA対象判定（適用除外の確認）を実施し、判定根拠を文書化した - ☐ 脆弱性受付窓口（psirt@等）とCVDポリシーをWebに公開した（security.txt設置） - ☐ 「積極的に悪用された脆弱性／重大インシデント」のトリアージ基準と判断者・24時間対応の連絡網を定めた - ☐ 早期警告（24h）/詳細通知（72h）/最終報告のテンプレートを準備した - ☐ 報告先（主たる拠点の管轄CSIRT・単一報告プラットフォーム）の登録・提出手順を確認した - ☐ 主要製品のSBOM（暫定版でよい）を作成し、CVE監視を開始した - ☐ インシデント対応の机上訓練を1回実施した ### フェーズ2：2027年12月11日まで（全面適用対応） - ☐ 製品ごとのサイバーセキュリティリスクアセスメントを実施・文書化した - ☐ クラス分け（default/important/critical）を確認し、適合性評価ルート（自己宣言/第三者評価）を決めた - ☐ 量産ファームのRDP（またはTrustZone品種の製品状態管理）を有効化した - ☐ 署名検証つきセキュアブート＋アンチロールバックつきファーム更新を実装した - ☐ 署名鍵の管理体制（保管・分離・ローテーション）を整備した - ☐ セキュア・バイ・デフォルト設定（共通初期パスワード廃止、不要ポート閉塞等）を確認した - ☐ サポート期間（原則最低5年）を製品ごとに定義し、無償セキュリティ更新の提供体制を確保した - ☐ SBOMをビルドパイプラインに統合し、リリースごとに自動生成・保管される状態にした - ☐ 技術文書・EU適合宣言（DoC）・CEマーキングの準備を開始した - ☐ 弁護士・認証機関に判定と適合方針のレビューを受けた ## まとめ ### この記事のまとめ - CRAはEU市場に上市する「デジタル要素を持つ製品」全般が対象。日本メーカーのB2B組込み機器も含まれる - **2026年9月11日から第14条の報告義務が適用開始**。悪用された脆弱性・重大インシデントは24時間以内の早期警告が必要で、**既存製品も対象**（第69条3項） - 2027年12月11日から必須要件・SBOM・サポート期間・CEマーキングが全面適用。一般的な産業機器の多くはdefaultカテゴリで自己適合宣言が可能 - STM32側の技術部品は揃っている：RDP、SBSFU/TF-M/Secure Managerによるセキュアブートと署名付き更新、TrustZone対応のL5/U5/H5/WBA、SESIP/PSA認証取得品種 - SBOMはSPDX/CycloneDXで「トップレベル依存」から現実的に始め、CVE監視・第14条報告と接続してこそ意味がある - FreeRTOS/Zephyr等のOSSを使っても責任は最終製品メーカー。デューデリジェンスとLTS追従の規律を今から作る 繰り返しになりますが、本記事は技術実務の観点からの整理です。自社製品の該当性・クラス分け・適合性評価ルートの最終判断は、必ず弁護士や認証機関にご確認ください。そのうえで、技術側の実装——セキュアブート、更新機構、SBOMパイプライン、PSIRT運用の仕組み化——はエンジニアリングの仕事です。お困りの際はお気軽にご相談ください。 STM32のセキュアブート実装・ファーム更新機構の設計、既存製品のCRA対応改修、SBOM整備まで [組込み制御・マイコン開発](https://technosphere.co.jp/embedded) として対応しています。 ／CRA対応・組込みセキュリティのご相談はこちら＼ ### 組込み機器のCRA対応・セキュリティ実装を受託開発で支援 STM32のセキュアブート・署名付きファーム更新・RDP/TrustZone活用設計から、SBOM整備・脆弱性対応プロセスの仕組み化、既存製品のセキュリティ改修まで。20年超のマイコン受託開発実績で、EU向け製品のセキュリティ実装を一貫サポートします。 [組込み開発サービスを見る](https://technosphere.co.jp/embedded) [CRA対応・セキュリティ実装の相談](https://technosphere.co.jp/contact) ## よくある質問（FAQ） ** CRA（EUサイバーレジリエンス法）の対象になるのはどんな組込み製品ですか？ EU市場に上市される「デジタル要素を持つ製品」、すなわちネットワークや他のデバイスに直接または間接にデータ接続できるハードウェア・ソフトウェアが対象です。B2Bの産業機器も含まれ、日本メーカーがEUに輸出する製品にも適用されます。医療機器（MDR）や自動車など既存のEU法制でサイバーセキュリティが規律される製品は適用除外です。最終判断は弁護士や認証機関への確認をおすすめします。 ** 2026年9月11日から具体的に何が義務になりますか？ CRA第14条の報告義務が適用開始されます。自社製品で「積極的に悪用されている脆弱性」または「製品のセキュリティに影響する重大インシデント」を認知した場合、**24時間以内の早期警告**、72時間以内の詳細通知、事後の最終報告（脆弱性は是正措置提供後14日以内、インシデントは72時間通知の提出後1か月以内）を、単一報告プラットフォーム経由で管轄CSIRTとENISAに提出する必要があります。 ** すでにEUで販売中の製品にもCRA対応は必要ですか？ 設計要件（セキュリティ・バイ・デザインやCEマーキング等）は、2027年12月11日より前に上市済みの製品には、それ以降に大幅な改変（substantial modification）を行わない限り適用されません（第69条2項）。ただし**第14条の脆弱性・インシデント報告義務は例外で、上市済みの製品にも適用されます**（第69条3項）。つまり2026年9月11日以降は既存製品も報告体制が必要です。 ** STM32のセキュリティ機能を使えばCRAに準拠したことになりますか？ なりません。RDP・セキュアブート・TrustZoneなどのマイコン機能はCRAの必須要件を満たすための技術的な部品にすぎず、CRAの義務は最終製品を上市するメーカーが製品全体として負います。脆弱性対応プロセス、SBOM、サポート期間中のアップデート提供、技術文書、適合性評価は製品レベルで整備する必要があります。 ** SBOMは一般公開する必要がありますか？ CRAはSBOMの一般公開までは要求していません。附属書I第II部は、少なくとも製品の**トップレベル依存関係**をカバーするSBOMを、一般に使用される機械可読形式（SPDXやCycloneDX等）で作成することを求めており、市場監視当局から要求があれば提出できる状態にしておく必要があります。 ** FreeRTOSやZephyrなどのOSSを使っている場合、脆弱性対応の責任は誰が負いますか？ 最終製品としてEU市場に上市するメーカーが負います。OSSプロジェクト側ではありません。メーカーはOSSを含む第三者コンポーネントの統合にあたりデューデリジェンス（保守状況・脆弱性履歴の確認、バージョン管理、CVE監視）を実施し、自社製品に影響する脆弱性を発見した場合は当該コンポーネントの保守者への報告も求められます。 # CRA # サイバーレジリエンス法 # STM32 # セキュアブート # TrustZone # SBOM # 脆弱性管理 # 組込みセキュリティ ## 次に読む｜組込みセキュリティ・STM32関連記事 - [組込みセキュリティ ルネサスRL78のリバースエンジニアリング 「保護されていないファームは読める」現実を知る。RDP設定の重要性が腹落ちする実例](https://technosphere.co.jp/blog/renesas-rl78-reverse-engineering) - [STM32 シリーズ STM32 + FreeRTOS 入門｜タスク・キュー・セマフォを使ったRTOS実装ガイド SBOMのトップレベル依存になるFreeRTOSの基礎。まずここから](https://technosphere.co.jp/blog/stm32-freertos-intro) - [STM32 シリーズ STM32マイコンのUART・I2C・SPI・CAN通信 実装ガイド CRA対象判定に関わる「デバイスへの接続」を支える通信実装の定番ガイド](https://technosphere.co.jp/blog/stm32-uart-i2c-can) - [開発実績 組込み制御・マイコン開発 実績紹介 STM32・FreeRTOS採用案件含む多数の受託開発事例](https://technosphere.co.jp/embedded-achievements) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # 河川氾濫・アンダーパス冠水をAIカメラで検知する｜既存の監視カメラを活かす防災DX提案 GENBA IQ｜株式会社テクノスフィア > 全国のアンダーパスでは車両水没事故が後を絶ちません。総務省調査では中部4県だけで冠水想定箇所691箇所、3年間で冠水246件・車両水没21件を確認。既存の監視カメラとエッジAI基盤GENBA IQを組み合わせた冠水検知の可能性を、公的データと業界動向をもとに技術提案として解説します。 URL: https://technosphere.co.jp/blog/flood-underpass-detection-ai-camera ** 目次 1. なぜ今、冠水対策に「監視の目」を増やす必要があるのか 2. 総務省の調査に見る、冠水事故の実態 3. 「今あるカメラ」にAIの目を足すという発想 4. 画像認識による水位・冠水検知、実用化の動き 5. 想定される活用シーン 6. 実現に向けた検討課題とPoCの進め方 7. よくある質問 8. まとめ ** 本記事について 本記事は、当社のエッジAIプラットフォーム「GENBA IQ」が持つ技術要素をもとに、河川氾濫・アンダーパス冠水の検知への応用可能性を検討する**技術提案記事**です。GENBA IQに冠水・河川氾濫検知の導入実績はまだありません。実績があるように読める記述は含まれていません。記事中の数値は総務省の公開調査資料に基づく事実であり、他社サービスの紹介部分は各社の公開情報をもとにしています。 ## なぜ今、冠水対策に「監視の目」を増やす必要があるのか 近年、集中豪雨のたびに全国各地で**アンダーパス（道路の立体交差部）の冠水と車両水没事故**が繰り返し報じられています。短時間に想定を超える雨が降る、いわゆる「ゲリラ豪雨」では、道路管理者が通行止め措置を完了させる前に水位が急上昇し、車両が閉じ込められるケースが後を絶ちません。 総務省中部管区行政評価局の調査でも、車の水没事故の多くは**「通行止めのため冠水箇所へ向かった道路管理者の職員や委託業者が、現場に到着するまでに想定を超える冠水となったこと」**で発生していると指摘されています。つまり課題は「危険を知らないこと」ではなく、**「危険に気づいてから、対応が完了するまでの時間差」**にあります。 - **人による見回り・パトロール**——24時間・広範囲を人手でカバーするのは限界がある - **水位センサー式の通報装置**——設置箇所の検知精度は高いが、多くは新設が前提で、設置箇所数がコストに直結する - **既存の監視カメラ映像**——名古屋市の道路・河川監視のように、すでに公開・記録されている場所もあるが、常時「人」が見張っているわけではない **ポイント：足りないのは「カメラ」より「見張る人」 道路・河川沿いには、防犯・防災・交通監視など様々な目的ですでに多くのカメラが設置されています。しかし、その映像を人が24時間見続けるのは現実的ではありません。**「映像を増やす」のではなく「映像から意味のある変化だけを人に届ける」**ことができれば、既存のカメラ資産をそのまま防災に活かせるのではないか——これが本記事の出発点です。 ## 総務省の調査に見る、冠水事故の実態 （図: 半分水に浸かったアンダーパスの入口に監視カメラが警戒の光を灯しているイメージイラスト） 2018年（平成30年）3月、総務省中部管区行政評価局は「道路冠水時における事故の防止対策に関する調査」を公表しました。愛知・岐阜・静岡・三重の4県、20の道路管理者を対象にした実態調査で、以下のような具体的な数字が示されています。 | 項目 | 数値 | | **中部4県の道路冠水想定箇所数** | 計691箇所（愛知237・岐阜138・静岡124・三重192／道路防災情報Webマップ H30.3時点） | | **冠水（通行止め措置）件数** | H27〜H29の3年間で計246件（19道路管理者管内） | | **うち車両水没があったもの** | 3年間で計21件・水没車両30台 | | **通行止めとする水位の目安** | 多くの道路管理者で10〜20cm程度。水位センサーが検知すると担当職員へメール・電話で自動通報 | この調査には、平成28年9月に愛知県清須市でアンダーパス内の車両が水没し運転者が死亡した事故、平成22年に可児市の市道アンダーパスで河川氾濫による水没死亡事故が発生した事例などが背景として記載されています。同時に、名古屋市が「道路・河川等監視情報システム」で**2分ごとのカメラ画像を公表**している例や、静岡市がIoT・オープンデータを組み合わせてアンダーパスの水位をリアルタイム化しようと検討している例も紹介されています。 つまり、**「センサーによる自動検知」自体はすでに各地で実用化されている**一方、監視カメラの映像を人手を介さずリアルタイムに"解析"する取り組みは、調査時点ではまだ限定的でした。ここに、AIカメラを組み合わせる余地があります。 ## 「今あるカメラ」にAIの目を足すという発想 （図: 監視カメラの映像がエッジAI端末で解析され、スマートフォンへの通知につながる3ステップのイメージイラスト） [GENBA IQ](https://technosphere.co.jp/genba-iq) は、映像・音声・センサーを統合して「現場」をAIが理解するエッジAIプラットフォームです。製造業の外観検査、交通インフラの事故検知、建設現場の安全管理など、すでに複数の分野で「既存カメラ映像をリアルタイムに解析し、異常があれば即座に知らせる」という基本構造を提供しています。 この基本構造を構成する技術要素のうち、河川氾濫・アンダーパス冠水の検知にも応用できると考えられるのは次の3点です。 | 技術要素 | 冠水検知への応用イメージ | | **既存カメラの活用** | RTSP等で映像取得できる一般的な防犯・ネットワークカメラに後付け可能。カメラの総入れ替えが不要 | | **エッジAIによる低遅延解析** | 映像をクラウドに送らず現場の端末で解析。通信が不安定な河川敷・郊外でも動作しやすい | | **検知から通知までの自動化** | 異常な映像の変化を検知した際に、担当者への通知や既存の警報設備との連携を自動化できる仕組み | **正直にお伝えしたいこと GENBA IQは現時点で、製造・交通・建設・小売・物流・医療介護といった分野を主なユースケースとしており、**水位や冠水を判定する学習済みモデルを標準では持っていません**。河川氾濫・アンダーパス冠水を検知対象とするには、実際の現場映像を使ってゼロから検知の精度を作り込む必要があります。「今すぐ導入できる完成品」ではなく、「既存の技術基盤を土台に、新しい検知対象へ挑戦できるのではないか」という提案であることをご理解ください。 ## 画像認識による水位・冠水検知、実用化の動き 「カメラ映像から水位や冠水を判定する」というアイデア自体は、すでに他社によって実用化が進んでいる分野です。この分野に確かな実現性があることの裏付けとして、公開情報から把握できる代表的な取り組みを紹介します。 | 企業・サービス | 概要 | | **ALSOK「アンダーパス監視サービス」** | アンダーパスの冠水事故防止を目的とした法人向け監視サービス | | **西菱電機「アンダーパス等冠水監視通報システム」** | 機械式電極センサーによる冠水検知と、管理者へのメール・電話自動通報、監視カメラのライブ映像による遠隔監視。大阪府内複数市や滋賀県・高知県など全国で導入実績あり | | **フューチャースタンダード「画像認識型河川水位監視ソリューション」** | セマンティックセグメンテーション技術により、量水標が設置されていないカメラ映像からも河川の水位を認識する仕組み（映像解析AIプラットフォーム「SCORER」） | | **丸紅情報システムズ** | 省電力無線カメラで対岸の量水標を撮影し、クラウド上でAIが水位を推定する河川水位監視システムを構築 | いずれも、電極式センサーのようなハードウェア中心の検知に加え、**「映像をAIに読み取らせる」というアプローチが実運用に耐えうる段階にある**ことを示しています。GENBA IQが持つ「既存カメラの活用」「エッジでの低遅延解析」という強みは、このアプローチと方向性が合致します。 ## 想定される活用シーン （図: アンダーパス・河川堤防・地下街入口という3つの場所にそれぞれ監視カメラが配置されているイメージイラスト） 既存の監視カメラ映像を活用するという性質上、**すでにカメラが設置されている、あるいは設置を検討している現場**との相性が良いと考えられます。 | 現場 | 活用イメージ | | **アンダーパス・道路の立体交差部** | 入口付近の路面が冠水し始めた変化を捉え、通行止め判断の材料や注意喚起表示と連携 | | **河川堤防・水門周辺** | すでに防犯・河川監視目的で設置されたカメラ映像に、水位上昇を捉える目を追加 | | **地下街・地下駐車場の入口** | 大雨時の浸水リスクがある地下空間の入口を監視し、早期の閉鎖判断につなげる | いずれのシーンも、**「新たにセンサーを設置する予算・工事は難しいが、カメラはすでにある」**という状況で特に効果を発揮しやすいと考えられます。 ## 実現に向けた検討課題とPoCの進め方 「アイデアとしては成立しそうだ」という段階から実際の運用に進めるには、いくつも詰めるべき論点があります。誇張せず、現時点で想定される課題を挙げます。 - **誤検知対策**——水面の反射・波紋・雨粒によるレンズの水滴、照明変化などを「冠水」と誤判定しないためのチューニングが必要 - **夜間・悪天候での見え方**——大雨・夜間は可視光カメラの映像品質が落ちやすく、赤外線カメラ等との組み合わせを検討する余地がある - **「水位」という連続的な変化のしきい値化**——何cmを「危険」とするかは現場ごとに異なり、既存の水位センサー基準（多くは10〜20cm）を参考にした現場合わせが必要 - **既存の通報体制との連携設計**——自治体の連絡網・警報設備・通行規制フローに、検知結果をどう組み込むかの設計 GENBA IQでは、他の用途と同様に**最短2週間のPoC（概念実証）**から検証を始める進め方を採っています。ヒアリング（0〜2日）、データ準備（3〜5日）、実装（6〜10日）、評価（11〜14日）という4フェーズです。冠水検知についても、いきなり本導入を目指すのではなく、**まずは対象現場の実際のカメラ映像を使って「検知できるかどうか」を確かめるところから**始めるのが現実的な進め方だと考えています。 ## よくある質問（FAQ） Q. 「AIカメラによる冠水検知」とは、具体的にどのような仕組みですか？ A. 既存の監視カメラ・防犯カメラの映像を、エッジAI端末が現場でリアルタイムに解析し、路面の冠水や水位の上昇といった映像の変化を検知したら、担当者への通知や既存の警報設備の作動につなげる、という仕組みです。人が映像を常時見続ける代わりに、AIが「意味のある変化」だけを見張ります。 Q. GENBA IQには、すでに冠水や河川氾濫を検知した実績があるのですか？ A. いいえ、現時点でGENBA IQに冠水・河川氾濫検知の実績や専用機能はありません。本記事で紹介しているのは、GENBA IQが実際に備える「既存カメラの活用」「エッジAIによる低遅延の映像解析」「検知から通知までの自動化」という技術要素を、防災という新しい用途に応用できないかという技術提案です。実際の導入には、現場映像を用いたPoCでの検証が必要です。 Q. 既存の水位センサー式の冠水通報システムとは何が違いますか？置き換わるものですか？ A. 電極式などの水位センサーは、設置箇所をピンポイントで検知する精度と実績に優れており、置き換えを提案するものではありません。AIカメラによる検知は、すでに設置されている監視カメラの映像を後付けで活用できる点が特長で、センサー新設が難しい箇所への追加の「目」として、既存の水位センサーや通報体制と組み合わせる補完的な使い方を想定しています。 ## まとめ ### この記事のまとめ - 総務省の調査では、中部4県だけで道路冠水想定箇所691箇所、3年間で冠水246件・車両水没21件が確認されており、**「対応が完了する前に冠水してしまう」**ことが事故の主因 - 各地の道路・河川にはすでに監視カメラが設置されているが、その映像を**常時"解析"する仕組み**はまだ限定的 - GENBA IQが実際に備える「既存カメラの活用」「エッジAIによる低遅延解析」「検知から通知までの自動化」という技術要素は、冠水検知にも応用できる可能性がある - ただし**GENBA IQに冠水・河川氾濫検知の実績はまだなく**、他社の画像認識型水位監視の実用化事例が示すとおり、現場映像でのPoCによる精度検証が不可欠 - 既存の水位センサー式システムを置き換えるものではなく、**「センサー新設が難しい場所への補完」**という位置づけが現実的 テクノスフィアの [GENBA IQ](https://technosphere.co.jp/genba-iq) は、製造・交通・建設・防災といった現場で培ってきたエッジAI・画像認識の技術基盤を持っています。「自分たちの地域・施設のカメラ映像で、実際に冠水を検知できるのか」——その可能性をまず確かめたい、という段階のご相談を歓迎します。 ／冠水検知・防災AIカメラのご相談はこちら＼ ### 今あるカメラを、防災の"目"にできないか相談したい GENBA IQは既存のカメラ・エッジAI・低遅延アラートという技術基盤を持つプラットフォームです。河川氾濫・アンダーパス冠水検知への応用は現時点で提案段階ですが、まずは現場のカメラ環境や課題感からご相談いただけます。 [GENBA IQ の詳細を見る](https://technosphere.co.jp/genba-iq) [冠水検知について相談する](https://technosphere.co.jp/contact?category=genba_iq) # 冠水検知 # アンダーパス # 河川氾濫 # AIカメラ # GENBA IQ # エッジAI # 防災DX ## 関連記事・サービス - [サービス GENBA IQ｜現場を理解する次世代エッジAI 映像・音声・センサー統合のリアルタイム検知](https://technosphere.co.jp/genba-iq) - [関連記事 熊（クマ）をAIカメラで検知する 既存の防犯カメラを害獣検知に転用する提案](https://technosphere.co.jp/blog/bear-wildlife-detection-ai-camera) - [関連記事 AIカメラによる現場の安全・危険検知 GENBA IQによる建設・製造現場の安全管理](https://technosphere.co.jp/blog/ai-safety-hazard-detection) - [関連記事 Raspberry Pi × VLM で実現するエッジAI 現場で動かす画像認識AIの技術背景](https://technosphere.co.jp/blog/raspberry-pi-vlm-edge-ai) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # H8マイコンはいつまで使える？EOL対策とRL78/RXへの移行ガイド【2026年版】｜テクノスフィア > 旧日立・ルネサスのH8/H8S/H8SXマイコンはEOL・NRND化が進行中。「あと何年使えるか」の判断材料と、HEW旧開発環境の老朽化・ソースコード紛失・周辺差異の壁を越えてRL78・RXへ移植・再生する実践ノウハウを実例で公開します。 URL: https://technosphere.co.jp/blog/h8-h8s-migration-guide ** 目次 1. はじめに：H8マイコンの現状 2. H8ファミリと採用領域 3. 移行が必要になる背景 4. H8移行の壁 5. 移行先の選定（RL78 / RX / STM32） 6. 移行プロジェクトの進め方 7. まとめ ## はじめに：H8マイコンの現状 **H8**は、日立製作所が開発し後にルネサスへ引き継がれた組込みマイコンファミリです（H8/300の8/16bitからH8/300H・H8Sの16/32bit、H8SXの32bitまで世代が広がります）。**H8/300H・H8/Tiny・H8S・H8SX**といった世代があり、1990年代から2000年代にかけて、製造装置・計測機器・医療機器・OA機器などに**圧倒的なシェア**で採用されました。日本の「組込み開発」を語るうえで外せない定番チップです。 しかし現在、H8の多くが**生産終了（EOL）または非推奨（NRND）**となり、長寿命の産業設備でリプレース需要が高まっています。本記事では、H8/H8Sベースの製品を現行マイコンへ移行・再生するための判断材料と進め方を解説します。 ** テクノスフィアのレガシー再生実績 テクノスフィアは、ソース・回路図が失われた組込み機器の [逆アセンブル・再構築](https://technosphere.co.jp/blog/renesas-rl78-reverse-engineering) を手がけています。H8を含む旧世代マイコンから現行品への移行も [受託開発](https://technosphere.co.jp/embedded-achievements) で対応しています。 ## H8ファミリと採用領域 | 世代 | 特徴 | 主な採用領域 | | **H8/300・H8/Tiny** | 8/16bit、小規模・低コスト | 家電・小型機器・センサー制御 | | **H8/300H** | 16/32bitコア、最大16MBリニア空間（アドバンストモード） | 産業機器・計測機器の定番 | | **H8S/2000・2600** | 高速・高機能 | OA機器・高機能制御 | | **H8SX** | 32bit拡張・高性能 | 大規模制御・通信機器 | 特にH8/300Hは、産業・計測分野で長年「鉄板」として使われ続けてきました。それらの設備が今、部品供給と開発環境の両面で移行を迫られています。 ## 移行が必要になる背景 - **デバイスの生産終了**：H8/H8Sの多くがEOL/NRND。在庫枯渇・調達難・価格高騰 - **開発環境の老朽化**：**HEW（High-performance Embedded Workshop）**や旧コンパイラが最新OSで動作しない - **属人化・退職**：当時の開発者が退職し、仕様・ノウハウが失われている - **保守部品の枯渇**：長寿命設備で、交換用基板が作れなくなるリスク ## H8移行の壁 ** 移行を難しくする要因 1. **ソース・資料の欠落**：ソースコード、HEWプロジェクト、回路図、仕様書が揃わない 2. **ビッグエンディアン**：H8はビッグエンディアン。データ構造・通信・フラッシュ格納の解釈が現行リトルエンディアン機と異なる 3. **周辺の差異**：TPU・8bitタイマ・SCI・A/D・割り込みコントローラなど、現行品と1対1対応しない周辺がある 4. **コンパイラ・アセンブリ依存**：旧Cコンパイラ固有の `#pragma`（割り込み・セクション）、H8アセンブリの存在 H8は採用実績が豊富なぶん、「20年前に書かれてそのまま動いている」コードが多く、当時の設計意図が不明なケースが少なくありません。ソースが無くROMだけが残る場合は、逆アセンブルによる仕様復元から着手します。 ## 移行先の選定（RL78 / RX / STM32） | 移行先 | 相性 | ポイント | | **ルネサス RL78** | ◎ H8/Tiny・H8/300H置換 | 同一ベンダーで低消費電力・低コスト。ルネサスがH8→RL78移行を推奨。[RL78ガイド](https://technosphere.co.jp/blog/renesas-rl78-peripheral-guide) | | **ルネサス RX** | ◎ H8S/H8SX置換 | 32bit高性能。高機能制御・通信を伴う場合。e2 studioで環境統一。[RX入門](https://technosphere.co.jp/blog/renesas-rx-introduction) | | **STM32（ARM）** | ○ 汎用・調達性 | ARM資産・サードパーティ・調達性を重視する場合。[STM32実装ガイド](https://technosphere.co.jp/blog/stm32-uart-i2c-can) | ルネサスはH8からの移行先として**RL78・RX**を公式に位置づけており、同一ベンダー・同一開発環境（e2 studio）で移行できる利点があります。小規模制御はRL78、高機能制御はRXが目安です。長期調達性やARM資産を重視するならSTM32も有力です。 移行元のファミリから移行先候補と工数を押し上げる要因を逆引きできる [マイコン移行判断ナビ](https://technosphere.co.jp/mcu-migration#h8-tiny) を公開しています。他ファミリとの比較にもお使いください。 ## 移行プロジェクトの進め方 ** 標準的な移行ステップ 1. **現状調査**：残存資産（ソース・HEWプロジェクト・ROM・回路図・実機）の棚卸し 2. **仕様復元**：ソース解析、または逆アセンブル＋実機動作解析で仕様化 3. **移行先選定**：性能・周辺・調達性から現行マイコンを選定 4. **ハード設計**：基板リプレース（端子・電圧・周辺の対応付け） 5. **ソフト移植**：周辺ドライバ置換、エンディアン・アセンブリの再実装 6. **等価性検証**：旧機と新機の入出力・タイミングを突き合わせて検証 7. **量産移行**：信頼性試験を経て量産へ 長寿命設備の移行はリスクとコストの見極めが重要です。**まず現状調査と一部機能のPoC**から始め、復元できる範囲・工数を把握してから本格移行に進むことをおすすめします。 ## まとめ ### この記事のまとめ - H8/H8Sは日本の産業・計測分野で定番だったが、多くがEOL/NRNDとなり移行需要が拡大している - 移行の壁は「ソース欠落・ビッグエンディアン・周辺差異・コンパイラ依存」 - 移行先は同一ベンダーのRL78（小規模）・RX（高機能）が第一候補。要件次第でSTM32も - HEWやソースが無くても、実機とROMがあれば逆アセンブルで仕様復元し移植できる - 現状調査と小規模PoCから始めると、リスクとコストを抑えて移行できる H8/H8Sベースの設備・製品の移行や再生でお困りでしたら、テクノスフィアにお気軽にご相談ください。HEW環境喪失・ソース紛失・部品供給終了の状況からでも、現行マイコンへの移行プランをご提案します。 H8/H8S 基板の逆アセンブル・仕様復元、RL78/RX/STM32 への移植・量産まで [組込み制御・マイコン開発](https://technosphere.co.jp/embedded) として対応しています。 ／レガシーマイコンの移行・再生のご相談はこちら＼ ### H8/H8S からの移行・レガシー再生 HEW環境喪失・ソース紛失・部品供給終了したH8基板を、逆アセンブルによる仕様復元から現行マイコン（RL78 / RX 等）への移植・量産まで一気通貫で対応します。長寿命設備の保全としてご相談ください。 [組込み開発サービスを見る](https://technosphere.co.jp/embedded) [H8→RL78/RX移植相談](https://technosphere.co.jp/contact) ## よくある質問（FAQ） ** H8/H8Sの移行先には何を選べばよいですか？ 同じルネサスのRL78（16bit・低消費電力）やRX（32bit・高性能）が第一候補です。ルネサスがH8→RL78/RX移行を推奨しており、e2 studioで環境を統一できます。ARM資産・調達性重視ならSTM32も選択肢です。H8/TinyはRL78、H8S/H8SXはRXが目安です。 ** HEWやソースが残っていなくても移行できますか？ 可能です。HEW環境やソースが無くても、実機とROM（mot/hex/bin）が残っていれば逆アセンブル・動作解析で仕様を復元し現行マイコンへ再実装できます。ソース・回路図欠落状態からの再構築実績があります。 ** H8移行で注意すべき点は？ ビッグエンディアン前提のデータ処理、H8固有のアセンブリ・割り込みベクタ、TPU/8bitタイマ・SCI・A/Dなど周辺の挙動差、旧コンパイラ依存の#pragmaやアドレス空間（H8/300Hのアドバンストモードは最大16MB）・メモリマップの違いです。 ** なぜ今H8の移行が増えているのですか？ H8/H8Sの多くがEOL/NRNDとなり供給リスクが高まっているためです。製造装置・計測機器など長寿命設備に多く残り、HEW等の旧環境が最新OSで動かない・当時の担当者が退職した、といった事情も重なっています。 ## 次に読む｜マイコン記事 - [レガシー再生 RL78 逆アセンブル・再構築 ソース紛失基板の復元事例](https://technosphere.co.jp/blog/renesas-rl78-reverse-engineering) - [移行先候補 RL78 ペリフェラル実装ガイド H8/Tinyからの第一移行先](https://technosphere.co.jp/blog/renesas-rl78-peripheral-guide) - [レガシー移行 SH（SuperH）移行ガイド 同じ旧日立系の移行も対応](https://technosphere.co.jp/blog/superh-sh-migration-guide) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # 技術コラム・ブログ | 株式会社テクノスフィア > テクノスフィアのエンジニアが発信する技術コラム。AI・RAG・Raspberry Pi・STM32・CAN通信など組込システム・Webシステム開発の知見や事例を発信しています。 URL: https://technosphere.co.jp/blog/ ## [AIソリューション 2026.09.09 河川氾濫・アンダーパス冠水をAIカメラで検知する｜既存の監視カメラを活かす防災DX提案 全国のアンダーパスでは車両水没事故が後を絶ちません。総務省調査では中部4県だけで冠水想定箇所691箇所、3年間で冠水246件・車両水没21件を確認。既存の監視カメラとエッジAI基盤GENBA IQを組み合わせた冠水検知の可能性を、公的データと業界動向をもとに技術提案として解説します。 # 冠水検知 # アンダーパス # 河川氾濫 # GENBA IQ 続きを読む](https://technosphere.co.jp/blog/flood-underpass-detection-ai-camera) ## [組込システム 2026.09.05 拠点間VPNで現場を遠隔保守する｜CGNAT・NAT越え・既存機器を触らない設計 離れた現場のネットワークカメラや制御機器を、オフィスから遠隔保守するための拠点間VPN設計。モバイル回線のCGNAT環境でつなぐ向きの決め方、UDP 500/4500とNAT-T、無通信でNATテーブルが落ちる問題、SNATで既存機器を1台も触らずに通す方法まで、実際に詰まった4か所を中心に解説します。 # 拠点間VPN # 遠隔保守 # IPsec # ネットワークカメラ 続きを読む](https://technosphere.co.jp/blog/site-to-site-vpn-remote-maintenance) ## [組込システム 2026.08.29 「載せるだけ」の在庫管理IoT「sphere-weight」を自社開発｜重量センサー×ESP32で在庫切れを自動通知 在庫容器を重量センサー台に載せておくだけで、毎日自動で残量を計測し、在庫切れをメールやWeb APIで通知する自社製品「sphere-weight」の開発を開始。ロードセル×ESP32・電池駆動の技術構成から、PoCの現在地、自動発注・ダッシュボード・トレーサビリティ・需要予測まで在庫と発注を一元管理するロードマップ、クラウドファンディングでの製品化予定までを紹介します。 # IoT # ESP32 # 在庫管理 # クラウドファンディング 続きを読む](https://technosphere.co.jp/blog/sphere-weight-inventory-iot) ## [AIソリューション 2026.08.29 AIエージェントに「社内の型」を教える｜新規プロジェクトの環境構築をスキル化して自動化した話 リポジトリ作成・課題管理・Wiki整備という立ち上げの定型作業を、Claude CodeのAgent Skillsでひと言の依頼に。社内慣例の調査からスキル化、公式ツールによる定量評価（スキルあり100% vs なし70.8%）まで、社内ナレッジをAIに教える設計ポイントを実践記録として解説。 # AIエージェント # Claude Code # Agent Skills # 開発プロセス 続きを読む](https://technosphere.co.jp/blog/ai-agent-project-setup-skill) ## [Windowsアプリ 2026.08.26 Windows App Development CLI（winapp）で何ができるか｜Windowsアプリ開発をコマンドラインで完結させるMicrosoft公式ツール解説 Microsoftが2026年1月に公開した公式CLI「winapp」を出典付きで解説。SDKセットアップからパッケージ識別・MSIX化・署名・ストア申請・WinUI 3雛形・UIオートメーションまで、コマンドラインで何ができるかを機能別に整理。Electron/Rust/Tauri/Flutter対応と、Claude Code/GitHub Copilot向け公式プラグインによるAIエージェント連携も紹介。 # winapp CLI # MSIX # WinUI 3 # AIエージェント 続きを読む](https://technosphere.co.jp/blog/windows-app-development-cli) ## [Webシステム 2026.08.08 リバースプロキシ型Webレビューツールを自社開発した話｜コード埋め込みゼロで画面に修正指示ピンを立てる仕組み Web制作の「修正指示」をスクショ赤入れとメール往復から解放するため、画面レビューツールPinRemarkをNode.js＋依存3パッケージで自社開発。ターゲットサイトに一切コードを入れずウィジェットを注入するリバースプロキシのURL書き換え、Shadow DOM隔離、ピン位置の二重保存、WebSocket同期の実装をハマりどころ含めて解説。 # リバースプロキシ # Node.js # Shadow DOM # WebSocket 続きを読む](https://technosphere.co.jp/blog/pinremark-reverse-proxy-review-tool) ## [AIソリューション 2026.07.26 Canva MCP × Claude Code｜AIエージェントにSNS投稿とWeb制作素材をつくらせる【実測33ツール・落とし穴つき】 Canva公式MCPサーバをClaude Codeに接続し、SNS投稿画像とこの記事のOGP画像を実際に生成・編集・書き出しした検証レポート。接続手順と33ツールの実測に加え、日本語の文字化けや架空URLの混入といった実際に踏んだ落とし穴、プラン別制限・レート制限・商用利用ライセンスの注意点まで出典付きで解説。 # Canva # MCP # Claude Code # デザイン自動化 続きを読む](https://technosphere.co.jp/blog/canva-mcp-claude-code) ## [Webシステム 2026.07.23 カラオケ採点の仕組み｜音程・ビブラート・しゃくり・こぶしはどう検出するのか【歌って試せるデモ付き】 カラオケの「精密採点」は歌をどう数値化しているのか。DAM・JOYSOUND公式の採点項目を出典付きで整理し、YINアルゴリズムによるF0推定からビブラート・しゃくり・こぶしの検出ロジックまで、ブラウザで動く採点デモとともに解説。 # 信号処理 # Web Audio API # ピッチ検出 # JavaScript 続きを読む](https://technosphere.co.jp/blog/karaoke-scoring-engine) ## [スマホアプリ 2026.07.23 AR家具配置アプリの仕組み｜カメラ映像に実寸大の家具を置く技術をわかりやすく解説 スマホで部屋を映すと実寸大のソファが現れる——「画像の合成」ではなく「3D空間への配置」であるARの仕組みと、家具の3Dモデルをどう用意するか（モデリング・フォトグラメトリ・CAD変換）を開発者が解説します。 # AR # ARKit # ARCore # スマホアプリ 続きを読む](https://technosphere.co.jp/blog/ar-furniture-placement-app) ## [Webシステム 2026.07.20 PC-88エミュレータをブラウザで動かす｜WebAssembly移植と著作権の整理【動くデモ付き】 レトロPCエミュレータQUASI88をEmscriptenでWASM化して自社サイトで公開。エミュレータ公開の著作権整理、ROMをサーバーに送らないローカル読込設計、ライセンス監査でサウンドを削った判断まで全記録。 # WebAssembly # エミュレータ # レトロPC # 著作権 続きを読む](https://technosphere.co.jp/blog/pc88-emulator-wasm) ## [スマホアプリ 2026.07.20 Three.jsでスマホ対応3Dゲームを作る｜フロントエンドだけで動くWebアプリ実装ガイド【遊べるデモ付き】 サーバーなし・インストールなしでブラウザだけで動く3Dドローンゲームを実際に公開しながら解説。バーチャルスティック実装、AABB衝突、AI画像生成テクスチャ、スマホ60fps最適化まで。 # Three.js # WebGL # スマホアプリ # ゲーム開発 続きを読む](https://technosphere.co.jp/blog/threejs-mobile-3d-game) ## [スマホアプリ 2026.07.21 BLEでスマホと機器をつなぐアプリ開発｜設計の勘所とハマりどころ GATT設計の分担、切断前提の再接続設計、バックグラウンド動作の制約、iOS/Androidの権限差、MTUの限界。機器側の組込み開発も自社で行う立場から、実案件でハマった5例とあわせて解説します。 # BLE# Bluetooth # スマホアプリ# IoT 続きを読む](https://technosphere.co.jp/blog/ble-device-app-integration) ## [スマホアプリ 2026.07.21 社内アプリの配布方法まとめ｜ストア公開せずにiOS/Androidへ配る5つの手段 Apple Business Manager、MDM、Ad Hoc、Google Play限定公開、APK直配布、PWA。必要な契約・審査の有無・自動更新・台数上限を一覧で比較し、判断フローまで示します。 # 社内アプリ# MDM # iOS# Android 続きを読む](https://technosphere.co.jp/blog/inhouse-app-distribution) ## [スマホアプリ 2026.07.20 ネイティブ・クロスプラットフォーム・PWAの選び方｜スマホアプリの技術選定を間違えないために 判断を分ける6つの軸、iOSのWeb Pushに潜む前提、オフライン同期の設計、配布方法と審査の違い。実務で使っている選定フローチャートを公開します。 # スマホアプリ # PWA # Flutter # 技術選定 続きを読む](https://technosphere.co.jp/blog/native-vs-pwa-app-choice) ## [AIソリューション 2026.07.18 AIで手順書を自動生成する仕組み — 画面操作の記録からマニュアルを作る技術解説【FlowLens開発記】 「操作するだけで手順書ができる」をどう実装するか。イベント駆動キャプチャの設計判断、プライバシー保護、Vision LLM 2段パイプラインのコスト最適化、中間表現JSONまで、自社製品FlowLensの開発の裏側を解説します。 # FlowLens # 手順書自動生成 # Vision LLM # Claude API 続きを読む](https://technosphere.co.jp/blog/ai-manual-auto-generation) ## [Webシステム 2026.07.16 エンジニアのスキルシート、まだExcelで管理しますか？ — SES・派遣の業務経歴書をWeb化した話 「最新版どれ？」問題を仕組みで解決。選択式＋タグで表記ゆれを止め、印刷様式はExcel原本を踏襲する——スキルシートWeb化の設計判断を解説。](https://technosphere.co.jp/blog/skill-sheet-web-management) ## [Webシステム 2026.07.14 死活監視とは？仕組み・監視方式・ツールの選び方を実務目線で解説 Ping・ポート・HTTP監視の検知範囲と誤検知パターン、アラート疲れを防ぐ通知設計、OSS/SaaSの損益分岐まで。価格は2026年7月時点の公式情報で比較。](https://technosphere.co.jp/blog/server-monitoring-guide) ## [Webシステム 2026.07.14 レガシーサーバーのクラウド移行ガイド｜NTP・コンソール・UNIX別の実務 総論ではなくサーバー種別ごとの各論で解説。クラウドの時刻同期サービス、シリアルコンソールの代替、Solaris/AIXの移行パスと自社事例まで。](https://technosphere.co.jp/blog/legacy-server-cloud-migration-guide) ## [組込システム 2026.07.13 ルネサスマイコン開発ガイド 総目次｜RL78・RX・RA・レガシー移行の実装記事まとめ ルネサス記事8本を「現行ファミリでの新規開発」と「レガシー資産の保守・移行」の2軸で整理した総目次。目的別の読み方マップ付き。](https://technosphere.co.jp/blog/renesas-mcu-guide) ## [組込システム 2026.07.13 RL78・RX・RA どれを選ぶ？ルネサスマイコン選定ガイド 現行3ファミリをコア・クロック・開発環境・長期供給（PLP）で比較し、電池駆動・モーター制御・新規Arm設計など用途別の選定フローを示します。](https://technosphere.co.jp/blog/renesas-mcu-selection-guide) ## [組込システム 2026.07.13 Renesas RAファミリ入門｜FSPとe2 studioで始めるArmマイコン開発 ルネサスのArm Cortex-M系主力「RA」の入門ガイド。FSPの考え方、プロジェクト作成〜UART実装、評価ボードの選び方、STM32との対応関係まで。](https://technosphere.co.jp/blog/renesas-ra-introduction) ## [組込システム 2026.07.13 H8マイコンとは？いまも現場で動き続ける理由と、保守・移行の判断ポイント H8ファミリの基礎と2026年時点の現状を一次資料で整理。製品ステータスの確認手順、開発環境の入手性、「維持か移行か」の判断フローまで。](https://technosphere.co.jp/blog/what-is-h8-microcontroller) ## [組込システム 2026.07.13 STM32N6とNeural-ART NPU｜マイコン単体で動くエッジAI実践ガイド ST初のNPU搭載マイコンを実務目線で解説。Jetson/ラズパイとの使い分け、評価ボード選び、ONNXデプロイ手順、メモリ制約、量産判断まで。](https://technosphere.co.jp/blog/stm32n6-neural-art-edge-ai) ## [組込システム 2026.07.13 EUサイバーレジリエンス法（CRA）と組込み機器｜STM32での実務対応ガイド 2026年9月11日開始の脆弱性報告義務まであとわずか。対象判定・クラス分けからSTM32のセキュアブート・SBOM作成まで実務対応を整理。](https://technosphere.co.jp/blog/embedded-cra-compliance-stm32) ## [組込システム 2026.07.13 STM32で始めるZephyr RTOS入門｜FreeRTOSとの違いと使い分け判断ガイド west環境構築からLチカ→スレッド→デバイスツリーまでの実践手順と、FreeRTOSとの比較・使い分け基準・移行判断を解説。](https://technosphere.co.jp/blog/stm32-zephyr-rtos-intro) ## [組込システム 2026.07.13 STM32開発ガイド 総目次｜通信・DMA・RTOS・低消費電力・デバッグの実装記事まとめ STM32実装ガイド7本を開発フェーズ別に整理した総目次。「いま詰まっている場所」から逆引きできる読み方マップ付き。](https://technosphere.co.jp/blog/stm32-development-guide) ## [画像認識AI 2026.06.29 万引き検知AI｜AIカメラで不審行動を検知する仕組みと防犯DX 防犯カメラの映像をAIが解析し、不審行動をリアルタイムに検知。従来カメラとの違い、導入の進め方、プライバシー配慮、現場AI「GENBA IQ」の活用を解説します。 # 万引き検知 # AIカメラ # 防犯DX # GENBA IQ 続きを読む](https://technosphere.co.jp/blog/ai-shoplifting-detection) ## [画像認識AI 2026.06.29 危険予知・労働安全AI｜危険区域侵入・ヒヤリハットをAIで検知 AIカメラで危険区域への侵入・保護具の未着用・重機接近などを検知し、事故を未然に防ぐ。建設・製造現場の安全管理に向けた仕組みと導入方法を解説します。 # 危険予知 # 労働安全 # 建設DX # GENBA IQ 続きを読む](https://technosphere.co.jp/blog/ai-safety-hazard-detection) ## [画像認識AI 2026.06.29 複数カメラ映像の合成技術｜設置角度に依存しない横並び統合 設置角度がバラバラな複数カメラの映像を、射影変換（ホモグラフィ）と画像スティッチングで1枚の横並び・俯瞰映像に統合する技術を、実装の勘所とともに解説します。 # 画像処理 # 射影変換 # 画像スティッチング # 広域監視 続きを読む](https://technosphere.co.jp/blog/multi-camera-image-stitching) ## [画像認識AI 2026.06.29 外観検査AI（画像検査）導入ガイド｜費用・進め方・事例 製造業の外観検査をAI（画像認識）で自動化する導入ガイド。費用の考え方と目安、PoCから本番までの進め方、キズ・汚れ・欠品・印字検査などの事例、既存カメラを活かすポイントを解説します。 # 外観検査 # 画像認識AI # 不良検知 # 製造業DX 続きを読む](https://technosphere.co.jp/blog/ai-visual-inspection-guide) ## [AIソリューション 2026.06.13 AIによる需要予測システムの作り方｜発注最適化を支えるデータ設計と機械学習 商品単位で「売れる確率」を返す需要予測AIは、どんなデータで・どんなモデルで・どう運用して作るのか。売上実績・イベント・天候・商圏属性を組み合わせた実装と運用のポイントを解説します。 # 需要予測 # 機械学習 # 発注最適化 # 小売DX 続きを読む](https://technosphere.co.jp/blog/demand-forecasting-ai) ## [AIソリューション 2026.06.13 熊（クマ）をAIカメラで検知する｜既存の防犯カメラを活かす害獣検知 GENBA IQ 深刻化する熊の出没。GENBA IQ なら今ある防犯カメラの映像をエッジAIで解析し、熊・イノシシ・鹿をリアルタイム検知。自治体・農地・通学路・施設の鳥獣対策に。最短2週間でPoC。 # 熊検知 # 害獣検知 # AIカメラ # GENBA IQ 続きを読む](https://technosphere.co.jp/blog/bear-wildlife-detection-ai-camera) ## [AIソリューション 2026.06.13 「AIが書いたコード、誰が責任を持つのか」｜全作業を証跡化する開発運用 生成AIにコードを書かせる時代の品質と説明責任。Redmine・GitHub・Obsidian・Growi・Claude Codeで全作業を証跡化する運用を、実際のフォーム障害を追跡・修正した事例とともに公開します。 # AI開発 # 証跡管理 # トレーサビリティ # Claude Code 続きを読む](https://technosphere.co.jp/blog/ai-development-audit-trail) ## [組込システム 2026.05.28 SH（SuperH）マイコン移行ガイド｜SH-2/SH-4のEOL対策とRXへのリプレース 生産終了が進む旧日立・ルネサスのSuperHマイコン。ソース紛失・コンパイラ老朽化・周辺差異を乗り越えて現行マイコン（RX等）へ移行・再生する進め方を解説します。 # SuperH # レガシー移行 # EOL対策 # 逆アセンブル 続きを読む](https://technosphere.co.jp/blog/superh-sh-migration-guide) ## [組込システム 2026.05.28 東芝マイコン移行ガイド｜TLCS-870/900のEOL対策とTXZ・現行マイコンへのリプレース 生産終了が進む東芝の旧マイコン。専用アセンブラ・周辺差異を乗り越えてTXZ（ARM）やSTM32・RL78へ移行・再生する進め方を解説します。 # 東芝マイコン # TLCS-870 # レガシー移行 # EOL対策 続きを読む](https://technosphere.co.jp/blog/toshiba-mcu-migration-guide) ## [組込システム 2026.05.28 H8マイコンはいつまで使える？EOL対策とRL78/RXへの移行ガイド【2026年版】 製造装置・計測機器に大量に残るH8/H8S。HEW環境の老朽化・ソース紛失・周辺差異を乗り越えて現行マイコン（RL78/RX）へ移行・再生する進め方を解説します。 # H8 # H8S # レガシー移行 # HEW 続きを読む](https://technosphere.co.jp/blog/h8-h8s-migration-guide) ## [組込システム 2026.05.28 8051・Z80 レガシー移行ガイド｜古典8bitマイコンのEOL対策と現行マイコンへの移植 いまも産業現場に残る8051・Z80。アセンブリ主体のレガシーコードと独自メモリ構成を乗り越えて現行マイコン（STM32/RL78）へ移行・再生する進め方を解説します。 # 8051 # Z80 # レガシー移行 # 逆アセンブル 続きを読む](https://technosphere.co.jp/blog/8051-z80-legacy-migration-guide) ## [組込システム 2026.05.27 Renesas RL78 ペリフェラル実装ガイド｜UART・I2C・タイマ・ADC ルネサスRL78のSAU（UART/SPI/簡易I2C）・IICA・TAU・12bit ADCをSmart Configuratorのコード生成で実装。STOP/SNOOZE低消費電力モードまで国内量産向けに解説します。 # RL78 # ルネサス # Smart Configurator # 低消費電力 続きを読む](https://technosphere.co.jp/blog/renesas-rl78-peripheral-guide) ## [組込システム 2026.05.27 Renesas RX マイコン入門｜SCI・RIIC・MTU・ADCをFITで実装 日本の産業機器で主力の32bitマイコン「RX」の全体像と、SCI・RIIC・MTU・12bit ADCをFIT（Firmware Integration Technology）で実装する流れを入門者向けに解説します。 # RX # ルネサス # FIT # 32bitマイコン 続きを読む](https://technosphere.co.jp/blog/renesas-rx-introduction) ## [組込システム 2026.05.27 TI MSP430 超低消費電力入門｜LPMモード・FRAM・eUSCI 超低消費電力マイコンの定番MSP430で、電池1個で年単位動作するセンサー機器を作るための低電力モード設計・FRAM活用・eUSCI実装をCode Composer Studioで解説します。 # MSP430 # TI # 低消費電力 # FRAM 続きを読む](https://technosphere.co.jp/blog/ti-msp430-low-power) ## [組込システム 2026.05.27 TI C2000 モーター制御入門｜ePWM・eQEP・高速ADCとFOC リアルタイム制御マイコンC2000（TMS320F28xx）の制御専用ペリフェラルと、FOC（ベクトル制御）でBLDC/PMSMを駆動する制御ループの全体像を解説します。 # C2000 # TI # モーター制御 # FOC 続きを読む](https://technosphere.co.jp/blog/ti-c2000-motor-control) ## [AIソリューション 2026.05.21 OpenClaw入門｜導入手順から社内Kubernetes本番運用まで完全ガイド【2026年版】 OSSのAIアシスタント「OpenClaw（オープンクロウ）」を、Docker Compose でのローカル起動から社内 k3s クラスタへの本番デプロイまで体系解説。Codex Pro / ローカル LLM (Qwen / Gemma) のハイブリッド構成、Secret・Ingress・PVC 管理、初回 OAuth ログイン手順まで網羅。 # OpenClaw # AIエージェント # Kubernetes # k3s # 社内DX 続きを読む](https://technosphere.co.jp/blog/openclaw-getting-started) ## [AIソリューション 2026.05.21 OpenClaw スキル活用事例①｜Obsidian作業ログ＋Redmineチケット運用を完全自動化した話 OpenClawのスキル機構（SKILL.md / AUTO ゾーン同期）で、エンジニアの作業ログ作成と Redmine チケット運用を AI に任せた実例。3ヶ月の運用で日次記録時間 70%・起票漏れ 90% 削減。スキル設計の5つの鉄則も公開。 # OpenClaw # Obsidian # Redmine # 業務自動化 # 社内DX 続きを読む](https://technosphere.co.jp/blog/openclaw-skills-obsidian-redmine) ## [AIソリューション 2026.05.21 OpenClaw スキル活用事例②｜画像生成・ブラウザ自動操作で広がるマルチモーダル業務自動化 gpt-image-2 を社内 LAN に閉じて呼ぶ image-gen スキル、Chromium を直接操作する browser-use スキル、Genspark CLI で検索からスライド・動画まで一気通貫の gsk スキル。3つのスキルを組み合わせた業務シナリオ・セキュリティ設計までを公開。 # OpenClaw # 画像生成 # Browser Use # マルチモーダル # Genspark 続きを読む](https://technosphere.co.jp/blog/openclaw-skills-image-browser) ## [AIソリューション 2026.05.21 Raspberry Piで動かすvLM完全ガイド｜限られたリソースで画像×言語AIを構築するエッジAI実装ノウハウ Moondream2 / SmolVLM / Qwen2-VL などの小型 Vision Language Model を Raspberry Pi 4/5 で動かすための実装ガイド。llama.cpp + GGUF 量子化、メモリ最適化、解像度・トークン制御、製造・小売・農業など実案件への展開ノウハウまで網羅。 # vLM # Raspberry Pi # エッジAI # Moondream # llama.cpp 続きを読む](https://technosphere.co.jp/blog/raspberry-pi-vlm-edge-ai) ## [組込システム 2026.03.08 Raspberry Piでセンサーデータ取得＆クラウド連携 完全ガイド Raspberry PiでI2C/SPI接続センサー（温湿度・CO₂・加速度）を読み取り、MQTT経由でAWS IoT Coreへ送信するまでをPython実装付きで解説します。 # Raspberry Pi # I2C # SPI # IoT # MQTT 続きを読む](https://technosphere.co.jp/blog/raspberry-pi-sensor-iot) ## [組込システム 2026.03.08 STM32マイコンのUART・I2C・SPI・CAN通信 実装ガイド STM32CubeMXによるペリフェラル設定からHALライブラリを使ったCサンプルコードまで。産業機器で多用するCAN通信の実装・フィルタ設定も詳しく解説します。 # STM32 # UART # I2C # SPI # CAN通信 続きを読む](https://technosphere.co.jp/blog/stm32-uart-i2c-can) ## [組込システム 2026.05.21 FreeRTOS入門｜STM32で学ぶタスク・キュー・セマフォの基本【サンプルコード付き】 STM32CubeMXでFreeRTOSを有効化し、タスク・キュー・セマフォ・ミューテックスを使った組込みリアルタイムOS開発の基本を解説。CMSIS-OS v2 ベースのCサンプルコードを多数掲載。 # STM32 # FreeRTOS # RTOS # CMSIS-OS # セマフォ 続きを読む](https://technosphere.co.jp/blog/stm32-freertos-intro) ## [組込システム 2026.05.21 STM32 DMA 完全ガイド｜UART・SPI・ADC との連携でCPU負荷を最小化 STM32のDMA（Direct Memory Access）をUART・SPI・ADCと組み合わせ、CPU負荷を最小化する実装ガイド。Normal/Circular モード、ダブルバッファ、IDLE割り込みを使った可変長受信まで網羅。 # STM32 # DMA # UART # SPI # ADC 続きを読む](https://technosphere.co.jp/blog/stm32-dma-complete-guide) ## [組込システム 2026.05.21 STM32低消費電力モード完全ガイド｜CR2032で年単位のバッテリー駆動を実現 STM32L4 を中心に Run / Sleep / Stop 0/1/2 / Standby / Shutdown の7モードを公式アプリケーションノートをもとに体系解説。HAL API、ウェイクアップ手段、CR2032 でのバッテリー寿命試算、6つの落とし穴まで網羅。 # STM32 # STM32L4 # 低消費電力 # バッテリー駆動 # IoT 続きを読む](https://technosphere.co.jp/blog/stm32-low-power-battery) ## [組込システム 2026.05.22 STM32 で ST-LINK が突然繋がらなくなった時の救出ガイド｜SWD ピン誤定義・Stop モード切断・Connect Under Reset の全手順 「Target was not detected」エラーの 6 系統の原因別救出手順を、ST 公式 AN4989 / UM2237 を一次資料に体系化。SWD ピン GPIO 化、Stop モード切断、RDP、偽物 ST-LINK まで、14 ステップのチェックリストで網羅。 # STM32 # ST-LINK # SWD # BOOT0 # RDP 続きを読む](https://technosphere.co.jp/blog/stm32-swd-debugger-rescue) ## [組込システム 2026.05.22 STM32G4 内蔵アナログ計測誤差の罠｜OPAMP・COMP・ADC を CubeMX で組む時の R_AIN とサンプリング時間の関係 STM32G4 の内蔵 OPAMP (6個) / COMP (7個) / 高速 ADC (5個) を使いこなすのに必須の「ソース抵抗 R_AIN とサンプリング時間」の関係を、ST 公式 AN2834 とデータシート DS12288 Table 70 を一次資料に体系解説。 # STM32G4 # ADC # OPAMP # COMP # アナログ計測 続きを読む](https://technosphere.co.jp/blog/stm32-g4-analog-precision) ## [組込システム 2026.05.22 STM32Cube.AI で TinyML を量産品質に｜学習済みモデルの C コード化とリンカスクリプトによる SRAM / Quad-SPI Flash メモリ配置最適化 STM32Cube.AI (X-CUBE-AI) で Keras / TFLite / ONNX モデルを STM32 用 C コードに変換し、内蔵 SRAM / 内蔵 Flash / 外部 Quad-SPI Flash への重み配置をリンカスクリプト書き換えで最適化する実装ガイド。 # STM32Cube.AI # TinyML # エッジAI # Quad-SPI # リンカスクリプト 続きを読む](https://technosphere.co.jp/blog/stm32-cube-ai-tinyml) ## [組込システム 2026.03.19 仕様書なしの産業用機器を復元：ルネサスRL78マイコン逆アセンブル実践ガイド 15年前に開発された産業用計測機器の制御基板を、仕様書・ソースコードなしでC言語に復元した事例を解説。elfファイルからの逆アセンブル手法、レジスタ解析、最新マイコンへの移植プロセスを公開。 # 逆アセンブル # ルネサス RL78 # レガシーシステム # マイコン移植 続きを読む](https://technosphere.co.jp/blog/renesas-rl78-reverse-engineering) ## [AIソリューション 2026.04.11 RAGチャットボットとは？仕組み・メリット・導入方法をわかりやすく解説 RAG（検索拡張生成）チャットボットの仕組みを図解で解説。従来のチャットボットとの違い、5つのメリット、導入に必要な技術スタック、導入ステップまで網羅。 # RAG # チャットボット # LangChain 続きを読む](https://technosphere.co.jp/blog/what-is-rag-chatbot) ## [AIソリューション 2026.04.11 SUGUMEN導入事例｜小売業の大量採用で面接工数70%削減・採用リードタイム半減 大手小売チェーンがSUGUMENを導入し、年間3,000人のアルバイト採用における面接工数70%削減、採用リードタイム半減を実現した事例を紹介。 # SUGUMEN # AI面接 # 採用DX 続きを読む](https://technosphere.co.jp/blog/sugumen-case-study-retail) ## [AIソリューション 2026.04.11 AI面接ツール比較7選【2026年最新】料金・費用相場と中小企業の選び方 AI面接ツールの選び方5つのポイントと主要5サービスを徹底比較。導入規模別のおすすめや、コスト・機能・ATS連携の観点から最適なツール選びをサポート。 # AI面接 # 面接自動化 # 採用コスト削減 続きを読む](https://technosphere.co.jp/blog/ai-interview-tools-comparison) 該当するカテゴリの記事はまだありません。 ## カテゴリ - AIソリューション - 組込システム - スマホアプリ - Windowsアプリ - Webシステム ## タグ RAGLangChainチャットボット AI社内DXRaspberry Pi I2CSPIIoT MQTTAWS IoTSTM32 STM32L4低消費電力バッテリー駆動 FreeRTOSDMACMSIS-OS ADCCAN通信UART HAL組込み制御マイコン開発 PythonvLMエッジAI MoondreamSmolVLMllama.cpp マルチモーダルOpenClaw AIエージェントKubernetes k3sOSSCodex ### お気軽にご相談ください AI・組込・Web開発のご相談は テクノスフィアへ。 [お問い合わせ](https://technosphere.co.jp/contact) --- # 社内アプリの配布方法まとめ｜ストア公開せずにiOS/Androidへ配る5つの手段｜テクノスフィア > 社内向けスマホアプリをApp Store・Google Playに公開せず配布する方法を比較。Apple Business Manager（カスタムApp）、Ad Hoc、MDM、Google Play限定公開、APK直配布、PWAの特徴と必要な契約・端末上限・更新の手間を実務目線で整理しました。 URL: https://technosphere.co.jp/blog/inhouse-app-distribution ** 目次 1. なぜストア公開を避けたいのか 2. iOSの配布方法3種 3. Androidの配布方法3種 4. 配布そのものをなくす選択肢：PWA 5. 一覧比較と選び方 6. つまずきやすいポイント 7. よくある質問（FAQ） 8. まとめ ## なぜストア公開を避けたいのか 社内向けアプリを一般公開したくない理由は、だいたい次のどれかです。 - **業務の内容が外に見える** — スクリーンショットや説明文から業務フローが推測される - **審査に時間がかかる** — 緊急の修正でも審査待ちが発生する - **審査に通らない** — 社内向けアプリは「一般ユーザーに価値がない」と判断されることがある - **誤ってインストールされる** — 関係のない人が入れてしまい、問い合わせが発生する いずれも正当な理由です。幸い、ストアを経由しない配布手段はiOS・Androidともに用意されています。 ## iOSの配布方法3種 ### ① Apple Business Manager（カスタムApp配信） App Store Connect にアプリを登録しつつ、**公開範囲を指定した組織のみに限定**する方式です。一般の検索には出ません。取引先など自社以外の組織へ配る場合もこの方式が使えます。 必要なもの: Apple Developer Program、Apple Business Manager の組織アカウント（D-U-N-S番号の取得が必要）。**審査はあります**が、一般公開ほど厳しくない運用です。 ### ② MDM（モバイルデバイス管理）経由 Intune・Jamf などのMDMで、管理下の端末にアプリを配布する方式です。**インストールを強制でき、バージョンを揃えられる**のが最大の利点で、端末台数が多い現場ほど有利になります。紛失時のリモートワイプも同じ仕組みで行えます。 必要なもの: MDM製品の契約、端末の管理登録（DEP/ABM連携があると自動化できます）。 ### ③ Ad Hoc配信 開発者が指定した端末（UDIDを登録した端末）にのみインストールできる方式です。**登録できるのは年間100台まで**という上限があり、端末を追加するたびに再ビルドが必要になります。試験導入やPoCには向きますが、本番運用の主軸には向きません。 ``` 【iOSの選び方】 台数が多い・端末管理もしたい → MDM 自社/取引先の組織単位で配りたい → Apple Business Manager（カスタムApp） 数台〜十数台・試験導入だけ → Ad Hoc（100台上限に注意） ``` ## Androidの配布方法3種 ### ① Google Play の限定公開（管理対象Google Play） Google Play に登録しつつ、**自組織のユーザーにのみ表示**する方式です。iOSのカスタムAppに相当します。Google Workspace や MDM と組み合わせて使います。更新もPlay経由で自動配信されるため、運用が最も安定します。 ### ② MDM経由 iOSと同様、管理下の端末へ配布・強制更新ができます。Android Enterprise に対応したMDMであれば、業務用プロファイルと個人領域を分けた運用（Work Profile）も可能です。 ### ③ APKファイルの直接配布 APKをサーバーやファイル共有に置き、端末でダウンロードしてインストールする方式です。**契約も審査も不要で最も手軽**ですが、次の点に注意が必要です。 - 端末側で「提供元不明のアプリ」のインストール許可が必要 - 自動更新の仕組みがないため、アプリ内に更新チェック機能を自作することが多い - 配布URLが漏れると誰でも入手できてしまう（認証をかける設計が必要） ## 配布そのものをなくす選択肢：PWA そもそも「配布」という行為をなくす方法もあります。Webアプリとして作り、ホーム画面に追加してもらう**PWA**です。 - ストア申請も配布用契約も不要。**URLを共有するだけ** - 更新はサーバー側を差し替えるだけで**全端末に即時反映** - iOS・Androidの区別なく同じものを配れる 一方で、Bluetooth機器との接続など一部の機能は使えず、iOSではプッシュ通知に「ホーム画面へ追加」が前提になります。判断基準は[ネイティブ・クロスプラットフォーム・PWAの選び方](https://technosphere.co.jp/blog/native-vs-pwa-app-choice)で詳しく整理しています。 ## 一覧比較と選び方 | 方式 | OS | 必要な契約 | 審査 | 自動更新 | 台数の目安 | | Apple Business Manager | iOS | Developer Program＋ABM | あり | ○ | 制限なし | | MDM配布 | iOS/Android | MDM製品 | なし | ◎ 強制可 | 多いほど有利 | | Ad Hoc | iOS | Developer Program | なし | × | 100台まで | | Google Play 限定公開 | Android | Play Console | あり | ○ | 制限なし | | APK直配布 | Android | 不要 | なし | × 自作が必要 | 少数向き | | PWA | 両方 | 不要 | なし | ◎ 即時 | 制限なし | ``` 【判断の順番】 Q1. Bluetooth機器連携やカメラの高度な制御が必要？ NO → PWA が最有力（配布・更新の手間がゼロ） YES ↓ Q2. すでにMDMを導入している？ YES → MDM配布（追加コストなく最も確実） NO ↓ Q3. 対象台数は？ 多い → ABM(iOS) / Play限定公開(Android) 少ない → Ad Hoc(iOS) / APK直配布(Android) ``` ## つまずきやすいポイント - **証明書の有効期限** — iOSの配布証明書には期限があります。切れるとアプリが起動しなくなるため、期限管理は必須です - **D-U-N-S番号の取得に時間がかかる** — Apple Business Manager の登録に必要で、取得に数週間かかることがあります。スケジュールに織り込んでください - **端末のOSバージョンがバラバラ** — 業務用の古い端末が残っていることが多く、対応OSの下限を決めておかないと後から揉めます - **APK直配布の更新漏れ** — 更新チェックの仕組みを入れないと、古いバージョンを使い続ける端末が残ります - **退職者の端末** — 個人端末に入れている場合、退職時にアンインストールしてもらう運用が必要です。MDMなら遠隔削除できます ## よくある質問（FAQ） ### Q. 社内アプリをApp Storeに公開せず配布できますか？ できます。Apple Business Manager のカスタムApp配信、MDM配布、Ad Hoc配信の3通りです。いずれもApple Developer Program の契約が前提になります。 ### Q. Androidの社内アプリはどう配布しますか？ Google Play 限定公開、MDM経由、APK直接配布の3通りです。運用の安定性ではPlay限定公開かMDMが有利です。 ### Q. MDMは必須ですか？ 必須ではありませんが、台数が増えるほど有利です。強制アップデートや紛失時のリモートワイプまで一括管理できます。数台程度ならMDMなしでも運用できます。 ### Q. 配布の手間を最小にしたいのですが？ PWAが最も手軽です。URLを共有するだけで配布でき、更新も即時反映されます。ただし機器連携など一部機能に制限があります。 ## まとめ ### この記事のまとめ - 社内アプリはストアに公開せず配布できる。iOS・Androidとも3通りずつ手段がある - 台数が多いならMDM、組織単位ならABM／Play限定公開が安定 - Ad HocとAPK直配布は手軽だが、台数上限と更新の手間に注意 - 機器連携が不要なら、PWAで「配布」自体をなくすのが最も軽い - 証明書の期限とD-U-N-S番号の取得期間は、計画時点で織り込む テクノスフィアでは、業務用スマホアプリの開発から配布方式の設計、MDM運用を見据えた構成のご提案まで対応しています。「ストアに出さずに配りたい」というご相談も、企画段階からご一緒します。 [▶ スマホアプリ開発サービスを見る](https://technosphere.co.jp/app-development) ｜ [開発の相談をする](https://technosphere.co.jp/contact?category=web) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # カラオケ採点の仕組み｜音程・ビブラート・しゃくり・こぶしはどう検出するのか｜テクノスフィア > カラオケの「精密採点」はどうやって歌唱力を数値化しているのか。DAM・JOYSOUND公式の採点項目を出典付きで整理し、基本周波数(F0)推定のYINアルゴリズム、セント単位の音程評価、ビブラート・しゃくり・こぶしの検出ロジックを解説。Web Audio APIでブラウザに実装した、実際に歌って試せる採点デモ付き。 URL: https://technosphere.co.jp/blog/karaoke-scoring-engine ** 目次 1. デモ公開中：ブラウザで動くカラオケ採点 2. 実機の採点は何を見ているのか（公式情報の整理） 3. 歌声を数値にする：基本周波数とセント 4. 心臓部：F0推定アルゴリズム（自己相関からYINへ） 5. しゃくり・ビブラート・こぶしはピッチ軌跡の「形」で分かる 6. Web Audio APIでブラウザに実装する 7. 採点式をどう作るか 8. よくある質問（FAQ） 9. まとめ 10. 参考文献・出典 ## デモ公開中：ブラウザで動くカラオケ採点 まず成果物からご覧ください。マイクの歌声から音の高さをリアルタイムに推定し、**音程のズレ（セント単位）・ビブラート・しゃくり・こぶし**を検出してスコア化するデモを当サイトで公開しました。インストール不要、ブラウザだけで動きます。 [▶ カラオケ採点デモを試す](https://technosphere.co.jp/labs/karaoke/) 音声はブラウザ内だけで処理され、サーバーには送信されません。マイクがなくても「シミュレーション歌唱」で動作を確認できます この記事では、このデモを作るために調べ上げた「カラオケ採点の仕組み」を解説します。前半は業務用カラオケ機がどんな項目を採点しているのかを**メーカー公式の一次情報だけ**で整理し、後半はそれをブラウザで再現する信号処理——F0推定・セント変換・テクニック検出——の実装に踏み込みます。 ## 実機の採点は何を見ているのか（公式情報の整理） カラオケ採点の話題はネット上に俗説も多いため、まず**メーカーが公式に公表している情報**を押さえます。業務用カラオケの採点は大きく2系統、第一興商の**DAM「精密採点」シリーズ**と、エクシングの**JOYSOUND「分析採点」シリーズ**があります。 ### DAM「精密採点DX-G / Ai」 精密採点DX-Gの公式ページは、高得点に必要な要素として**「音程」「安定性」「表現力（抑揚）」「しゃくり」「こぶし」「フォール」**の6項目を挙げています。音程は「原曲の音程を外さずに正確に歌えたか」を分析するとされ、画面の「見えるガイドメロディー」に自分の歌唱軌跡が重ねて表示されます。しゃくり・こぶし・フォール・ビブラートは検出回数が「技法カウント」として表示されます。採点結果には「上手なポイントによって加点される」ボーナス点の機能もあります（どの技法がどれだけ加点されるかは非公開）[1]。 後継の精密採点Aiでは「こぶし、しゃくり、フォール、ビブラートを検出すると光のエフェクトが技法カウンターに飛んでいく」と公式に説明されており、従来の音程・表現力・ビブラートの各ボーナスを統合した「Ai感性ボーナス」が導入されました[2]。2025年発売の最新機LIVE DAM WAO!の「精密採点Ai Heart」では、検出技法に**アクセント・ハンマリング**の2つが追加されています[3]。 ### JOYSOUND「分析採点AI」 JOYSOUNDの分析採点AIは、採点結果を**「音程」「安定感」「抑揚」「ロングトーン」「テクニック」＋「AIボーナス」**で構成し、テクニックとして採点されるのは「こぶし・しゃくり・ビブラートの3つ」と公式ページに明記されています（DAMと異なりフォールは対象外）[4]。また公式ヘルプには「主旋律の**ガイドメロディ通りに声の高さを合わせて歌うと高い評価になる**」とあり、音程評価の基準がガイドメロディであることが公表されています[5]。 ### 技法の公式定義 両社は各技法を次のように説明しています。この定義が、後半で作る検出器の仕様になります。 | 技法 | 公式の説明 | | **しゃくり** | 「低い音程から滑らかに本来の音程までずり上げて歌唱する技法」（DAM[6]）／「低い音から高い音（本来の音の高さ）へ滑らかに声を出す歌唱技法」（JOYSOUND[4]） | | **こぶし** | 「基本となる旋律の中で音を細かく動かす装飾音的な節回し」（DAM[6]）／「歌の途中で瞬間的に上下振幅される歌唱技法」（JOYSOUND[4]） | | **ビブラート** | 「音程を上下に揺らすこと」（DAM[6]）。DAMは揺れの形で「ボックス型A/B/C・上昇形・下降形・縮小形・拡張形・ひし形」等のタイプに分類[7]、JOYSOUNDは「早さや深さの組み合わせで全9種類」[4] | | **フォール** | 「本来の音程から滑らかにずり下げる技法」（DAM[6]） | 一方で、**各項目の配点・重み・加点量は両社とも非公開**です。ネット上で見かける「しゃくり1回で◯点」といった数値は非公式の検証値なので、本記事では扱いません。 ## 歌声を数値にする：基本周波数とセント 採点の第一歩は、歌声の「高さ」を数値にすることです。声帯の振動の繰り返し周波数を**基本周波数（F0）**と呼び、これが知覚される音の高さ（ピッチ）にほぼ対応します。たとえばA4の「ラ」は440Hz、1オクターブ上のA5は880Hzです。 （図: マイクの音声波形からピッチ曲線を抽出するイメージ） 採点エンジンの仕事は「生の波形」を「メロディの線（ピッチ軌跡）」に変換することから始まる ここで重要なのが、周波数をそのまま使わないことです。人間の音程感覚は周波数の**比率**で決まるため（440Hz→441Hzの1Hzと、110Hz→111Hzの1Hzでは音程の差が4倍違う）、音楽の世界では対数尺度の**セント（cent）**を使います。 ``` セント差 = 1200 × log2( f ÷ f_ref ) ・1オクターブ = 1200セント ・半音 = 100セント ・「ドレミ」の隣り合う鍵盤の差が100セント ``` 「音程のズレ」とは、ガイドメロディ（あるべき音）と歌声のF0のセント差のことです。ちなみに人間の耳の音程の弁別能力は条件によりますが、訓練された音楽家で1〜2セント程度、一般には10セント前後の差から聞き分けられると報告されています[13]。±50セント（半音の半分）ズレると隣の音に聞こえ始める境界なので、採点機がセント単位でズレを測るのは理にかなっています。 ## 心臓部：F0推定アルゴリズム（自己相関からYINへ） では、マイク波形からF0をどう求めるか。これは「ピッチ検出」と呼ばれる信号処理の古典的テーマです。 ### 基本は自己相関法 周期的な波形は「1周期ぶんズラして重ねると自分自身とよく一致する」性質があります。波形を少しずつズラしながら自分自身との相関を計算し、最も一致するズラし幅（ラグ）τを見つければ、F0 = サンプリング周波数 ÷ τ で求まります。これが**自己相関法**で、カラオケ採点関連の特許にも自己相関ベースの歌唱ピッチ抽出が登場します[12]。ただし素朴な自己相関は、倍音の強い声で1オクターブ間違える「オクターブエラー」を起こしやすい弱点があります。 ### 実用の定番：YIN この弱点を系統的に潰したのが、de Cheveigné と河原英紀による**YINアルゴリズム**（2002年）です[8]。相関の代わりに「ズラした波形との差の二乗和（差分関数）」を使い、それを累積平均で正規化した関数（CMNDF）の谷を探します。論文では、既存手法に比べ大きな推定誤りを約1/3に減らしたと報告されています。本デモのF0推定もYINをJavaScriptで素直に実装したものです。 ``` // YINの中核部（本デモ pitch-engine.js より抜粋） // Step1: 差分関数 d(τ) = Σ (x[i] - x[i+τ])² for (let tau = 1; tau <= maxTau; tau++) { let sum = 0; for (let i = 0; i < W; i++) { const delta = buf[i] - buf[i + tau]; sum += delta * delta; } d[tau] = sum; } // Step2: 累積平均正規化 d'(τ) = d(τ)·τ / Σd(1..τ) // → 自己相関のゼロラグ偏りを除去しオクターブエラーを抑える // Step3: d'(τ) が閾値(0.1〜0.15)を最初に下回る谷を採用 // Step4: 谷の周囲3点で放物線補間 → サブサンプル精度のτ // F0 = sampleRate / τ ``` より新しい手法として、YINの閾値判定を確率化しHMMで滑らかなピッチ経路を選ぶ**pYIN**[9]や、波形を直接畳み込みニューラルネットに入力する**CREPE**[10]もあります。精度は上がりますが計算は重くなるため、「60fpsで動くブラウザデモ」にはYINで十分という判断をしました。 なお解析窓は2048サンプルを使っています。自己相関系の手法は窓の半分までのラグしか信頼できないため、48kHzサンプリングなら検出下限は約47Hz。男性の低い歌声（E2≒82Hz）にも余裕があります。 ## しゃくり・ビブラート・こぶしはピッチ軌跡の「形」で分かる F0推定を毎フレーム（本デモでは描画フレームごと、約60回/秒）実行すると、時間×音高の**ピッチ軌跡**が得られます。歌唱テクニックは、この軌跡に特徴的な「形」として現れます。 4つの歌唱技法がピッチ軌跡に描く「形」。検出器はこの形を数式の条件に置き換えたもの ### ビブラート：規則的な揺れを見つける 声楽研究では、ビブラートは「中心音高のまわりでF0が周期的（正弦波状）に変調される現象」と定義され、古典声楽の典型的なレートは**毎秒5〜7回**（近年の実測研究では4.5〜6.5Hz付近）、深さは片側±25〜60セント程度を中心にスタイルによって幅があると報告されています[11]。 本デモの検出器は、直近1秒のピッチ軌跡から移動平均（=メロディの動き）を引いた「残差」を作り、その残差が**①4〜8.5Hzに相当する間隔で交互にゼロ交差し、②平均振幅が8セント以上で、③揺れの周期が揃っている**（半周期のばらつきが小さい）ときにビブラートと判定します。①②③のような数値は本デモの設計値で、規則性の条件③が、次に述べる「こぶし」との判別に効きます。 ### しゃくり：出だしの「ずり上げ」を見つける しゃくりに相当する現象は歌唱スタイル解析の研究では scooping と呼ばれ（論文中でも日本語の "shakuri" が紹介されています）、上向きに連続的に音高が変化するものとして、ビブラートの周期的な音高の振動とは区別されています[14]。検出はノートオンセット（音の出だし）付近のF0軌跡の解析に帰着します。 本デモでは「歌っている音がある半音に安定した」瞬間に、その直前350ms以内の軌跡を遡り、**目標より80セント以上低い位置から始まり、概ね単調に上昇して目標に到達**していたら「しゃくり」とカウントします（この閾値も本デモの設計値です）。DAM公式の「低い音程から滑らかに本来の音程までずり上げて歌唱する技法」[6]という説明を、そのまま数式の条件に置き換えた形です。 ### こぶし：一回だけの装飾的な揺れを見つける こぶしはJOYSOUND公式の「歌の途中で瞬間的に上下振幅される歌唱技法」[4]という説明が検出器設計の手がかりになります。ビブラートとの違いは**規則的に繰り返すか、一回きりか**です。なお、こぶしの音響的な定量研究（揺れの速さや深さの標準値）は、調べた範囲では査読論文として見つかりませんでした。演歌の装飾技法として「不規則な揺れ」がビブラートと対比される、という定性的な整理に留まります。 そこで本デモでは**「保持中の音から+60セント以上の山が現れ、400ms以内に元の音程（±30セント）へ戻る。ただしビブラート判定中は除外」**という条件（本デモの設計値）で検出しています。実際に演歌調で「うぅん↑」と一瞬こぶしを回すと反応します。 （図: 歌唱テクニックが光の軌跡として描かれるイメージ） テクニックはピッチ軌跡に現れる——採点機は「歌の形」を見ている ## Web Audio APIでブラウザに実装する ここまでの仕組みは、実はブラウザのJavaScriptだけで実装できます。本デモの構成は次のとおりです。 ``` マイク ─ getUserMedia ─→ AudioContext └→ AnalyserNode (fftSize=2048) └→ requestAnimationFrame ループ(約60fps)で getFloatTimeDomainData() → 波形2048サンプル → YINでF0推定 → セント変換 → ピッチ軌跡の解析(ビブラート/しゃくり/こぶし) → Canvas描画・スコア更新 ``` 実装上のポイントは3つあります。 - **ブラウザの「音声加工」を切る**——getUserMediaの音声はデフォルトでエコーキャンセル・ノイズ抑制・自動ゲイン調整（AGC）が有効です。通話には便利ですが歌声解析には邪魔なので、`echoCancellation: false, noiseSuppression: false, autoGainControl: false` を指定します（機種によっては無効化できないため、実際の設定値を`getSettings()`で確認します）。 - **HTTPSが必須**——getUserMediaはセキュアコンテキスト専用APIで、HTTP配信のページではマイクにアクセスできません（localhostは例外）。 - **無声区間を弾く**——息継ぎや子音では「音の高さ」が存在しません。音量（RMS）が小さいフレームと、YINの正規化差分が閾値を下回らない（＝周期性が弱い）フレームは「無声」として軌跡から除外します。これをサボると、ブレスのたびにピッチが乱れて誤検出だらけになります。 処理量の目安として、2048サンプルのYINは現代のPCなら1フレーム1ミリ秒未満で計算でき、60fpsのメインスレッド処理で間に合います。より本格的にやるならAudioWorkletで音声スレッド側に解析を移す設計になりますが、デモ用途には過剰と判断しました。 なお本デモには、マイクがない環境でも動作を確認できる**「シミュレーション歌唱」モード**を用意しました。OscillatorNodeの周波数を自動化した合成音声（ストレート→しゃくり→ビブラート→こぶしの順に"歌う"）を、マイクとまったく同じ解析パイプラインに流すもので、検出器の動作テストにもこの仕組みを使っています。 ## 採点式をどう作るか 最後に点数化です。冒頭で述べたとおり実機の配点は非公開なので、本デモでは公式に公表されている「音程が中心、テクニックは加点」という構造だけを借りて、次の簡易式を作りました。 ``` スコア(100点満点) = 音程点(最大70点) + 表現点(最大30点) 音程点 = 「±30セント以内で歌えたフレームの割合」× 70 表現点 = ビブラート秒数×2 (最大12点) + しゃくり 1回3点 (最大9点) + こぶし 1回3点 (最大9点) ※本デモ独自の学習用モデル。実機の採点仕様とは無関係 ``` 実機との最大の違いは**ガイドメロディの有無**です。実機は「この瞬間にどの音を歌うべきか」を楽曲データとして持っており、そこからのズレを測ります（JOYSOUNDは公式ヘルプでガイドメロディ基準を明言[5]）。課題曲を持たない本デモは、代わりに「最寄りの半音にどれだけ正確に乗っているか」で音程を評価しています。平均律の鍵盤の音からズレ続ける歌い方は不利になる、という限界はありますが、「音程を数値で突きつけられる」体験としては十分成立します。 ## よくある質問（FAQ） ### Q. カラオケの採点は何を評価しているのですか？ 公式情報では、DAM精密採点DX-Gは「音程・安定性・表現力（抑揚）・しゃくり・こぶし・フォール」[1]、JOYSOUND分析採点AIは「音程・安定感・抑揚・ロングトーン・テクニック（こぶし/しゃくり/ビブラート）＋AIボーナス」[4]です。中心は音程の正確さで、テクニックは加点要素です。 ### Q. しゃくりやビブラートは、どうやって機械で検出するのですか？ 歌声から基本周波数（F0）を推定してピッチ軌跡を作り、その「形」で判別します。出だしの滑らかなずり上げ＝しゃくり、規則的な周期の揺れ＝ビブラート、瞬間的に動いて戻る装飾＝こぶし、です。詳しくはテクニック検出の章をご覧ください。 ### Q. ブラウザだけでカラオケ採点は作れますか？ 基本的な仕組みは作れます。[実際に動くデモ](https://technosphere.co.jp/labs/karaoke/)を公開していますので、マイクで歌って試してみてください。音声はブラウザ内だけで処理され、サーバーには送信されません。 ### Q. 高得点のコツはありますか？ 本記事は採点攻略ではなく仕組みの解説が目的ですが、仕組みから言えることはあります。採点の土台は一貫して「ガイドメロディに対する音程の正確さ」なので、まず音程、その上でテクニックです。興味深いことにDAM公式自身が、ビブラートの評価が低い場合について「ビブラートは使わずまっすぐ歌うと得点が上がる可能性もあります」と述べています[6]。 ## まとめ ### この記事のまとめ - カラオケ採点の中心は「ガイドメロディに対する音程の正確さ」。しゃくり・こぶし・ビブラート等のテクニックも評価対象（DAM/JOYSOUND公式） - 音の高さは基本周波数（F0）として推定し、対数尺度の「セント」（半音=100セント）でズレを測る - F0推定の実用定番はYIN。差分関数＋正規化でオクターブエラーを抑え、ブラウザのJSでもリアルタイムに動く - テクニックはピッチ軌跡の「形」——出だしのずり上げ＝しゃくり、規則的な揺れ＝ビブラート、瞬間的な装飾＝こぶし——として検出できる - Web Audio API（getUserMedia + AnalyserNode）だけで採点デモは実装可能。音声加工オフ・HTTPS・無声区間処理が実装の勘所 「マイク入力のリアルタイム解析」「信号処理アルゴリズムの製品実装」「ブラウザだけで動くインタラクティブなWebアプリ」——本記事の技術は、音声UI、異音検知、発話解析といった業務案件にそのまま応用できます。テクノスフィアは[音声AI](https://technosphere.co.jp/technovoice)から[組込のDSP実装](https://technosphere.co.jp/embedded)、[Webシステム](https://technosphere.co.jp/web-system)まで一気通貫で対応します。 [▶ カラオケ採点デモを試す](https://technosphere.co.jp/labs/karaoke/) ｜ [AIソリューション](https://technosphere.co.jp/ai-solution) ｜ [開発の相談をする](https://technosphere.co.jp/contact) ## 参考文献・出典 1. 第一興商「精密採点DX-G」公式ページ — [clubdam.com/contents/saiten/seimitsusaiten_dx_g.html](https://www.clubdam.com/contents/saiten/seimitsusaiten_dx_g.html) 2. 第一興商「精密採点Ai」公式ページ — [clubdam.com/contents/saiten/seimitsusaiten_ai.html](https://www.clubdam.com/contents/saiten/seimitsusaiten_ai.html) 3. 第一興商「精密採点Ai Heart」公式ページ — [clubdam.com/contents/saiten/seimitsusaiten_ai_heart.html](https://www.clubdam.com/contents/saiten/seimitsusaiten_ai_heart.html) 4. JOYSOUND「分析採点AI/AI＋」公式ページ — [joysound.com/web/s/function/bunseki](https://www.joysound.com/web/s/function/bunseki) 5. JOYSOUND公式ヘルプ「分析採点について」 — [joysound.com/web/s/help/ranking/analysis](https://www.joysound.com/web/s/help/ranking/analysis) 6. 第一興商「精密採点"キホンのキ"」技法解説（しゃくり/こぶし/フォール/ビブラート/音程） — [clubdam.com/tips/tips2307_04.html](https://www.clubdam.com/tips/tips2307_04.html) ほか同シリーズ 7. 第一興商「DAM★とも精密採点 歌唱タイプ（ビブラートタイプ）」 — [clubdam.com/membership/import/marking/vibrato_description.html](https://www.clubdam.com/membership/import/marking/vibrato_description.html) 8. A. de Cheveigné and H. Kawahara, "YIN, a fundamental frequency estimator for speech and music," *J. Acoust. Soc. Am.*, vol. 111, no. 4, pp. 1917–1930, 2002. [doi:10.1121/1.1458024](https://doi.org/10.1121/1.1458024) 9. M. Mauch and S. Dixon, "pYIN: A Fundamental Frequency Estimator Using Probabilistic Threshold Distributions," *Proc. IEEE ICASSP*, pp. 659–663, 2014. 10. J. W. Kim, J. Salamon, P. Li, and J. P. Bello, "CREPE: A Convolutional Representation for Pitch Estimation," *Proc. IEEE ICASSP*, 2018. [arXiv:1802.06182](https://arxiv.org/abs/1802.06182) 11. ビブラートのレート・深さの標準値: C. E. Seashore らの古典的計測、J. Sundberg らの声楽音響研究、および Journal of Voice 誌の実測研究群（例: ["Vibrato Rate and Extent in College Music Majors"](https://www.sciencedirect.com/science/article/abs/pii/S0892199715002064)）。深さはスタイル・個人により幅がある 12. 特開2008-15211「ピッチ抽出方法、歌唱力評価方法、歌唱訓練プログラム及びカラオケ装置」（自己相関ベースの歌唱ピッチ抽出の例） — [patents.google.com/patent/JP2008015211A/ja](https://patents.google.com/patent/JP2008015211A/ja) 13. 音程の弁別閾（JND）: Stanford CCRMA ["Frequency Difference Limen or JND"](https://ccrma.stanford.edu/~malcolm/correlograms/text/33%20Frequency%20Difference%20Limen%20Or%20Jnd.html)、M. F. Spiegel and C. S. Watson, "Performance on frequency-discrimination tasks by musicians and nonmusicians," *J. Acoust. Soc. Am.* 76(6), 1984 ほか。値は周波数・音圧・訓練度に依存 14. Y. Yamamoto, J. Nam, and H. Terasawa, "Analysis and Detection of Singing Techniques in Repertoires of J-POP Solo Singers," *Proc. ISMIR*, 2022. [archives.ismir.net/ismir2022/paper/000046.pdf](https://archives.ismir.net/ismir2022/paper/000046.pdf) ※各社の採点機能・対応機種は執筆時点（2026年7月）の公式サイトの記載に基づきます。採点の内部アルゴリズム・配点は非公開であり、本記事のデモはそれらとは無関係の独自実装です。DAMは株式会社第一興商、JOYSOUNDは株式会社エクシングの登録商標です。 ブラウザだけで動くアプリの実例は[PC-88エミュレータのWASM移植](https://technosphere.co.jp/blog/pc88-emulator-wasm)、音声・対話AIの取り組みは[TechnoVoice](https://technosphere.co.jp/technovoice)でも紹介しています。 [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # レガシーサーバーのクラウド移行ガイド｜NTP・コンソール・UNIXサーバー別の実務｜株式会社テクノスフィア > レガシーマイグレーションを「サーバー種別ごとの各論」で解説。NTPサーバーはAmazon Time Sync等で代替できるか、コンソールサーバーの役割はEC2シリアルコンソールで置き換わるか、Solaris/AIXなどUNIXサーバーのリホスト可否まで。官公庁のSolaris→OCI移行を手がけたテクノスフィアが実務目線で整理します。 URL: https://technosphere.co.jp/blog/legacy-server-cloud-migration-guide ** 目次 1. はじめに：レガシーサーバーを移行すべきか、延命すべきか 2. 7R分類の実務的な使い方 3. NTPサーバーのクラウド化｜時刻同期サービスで代替できるか 4. コンソールサーバーのクラウド化｜シリアルコンソールと踏み台設計 5. UNIXサーバー（Solaris・AIX・HP-UX）のクラウド移行 6. メインフレームは「サーバーレス化」できるか 7. 移行プロジェクトの進め方と見積もりの考え方 8. まとめ ## はじめに：レガシーサーバーを移行すべきか、延命すべきか 「レガシーマイグレーション」で検索すると、リホスト・リライト・リビルドといった手法の解説記事は山ほど見つかります。しかし実際の移行プロジェクトで頭を悩ませるのは総論ではなく、「このNTPサーバーはクラウドに持っていくのか？」「コンソールサーバー経由でやっていた障害対応はどうなる？」「SolarisのバイナリはEC2で動くのか？」といった、サーバー1台1台の具体的な処遇です。 本記事では、あえて総論を最小限に絞り、サーバーの種別ごとに「クラウドで何に置き換わるのか／置き換わらないのか」を整理します。対象は、レガシー環境で特に相談の多い次の4種です。 - NTPサーバー（構内の時刻同期基盤） - コンソールサーバー（シリアル経由の帯域外管理） - UNIXサーバー（Solaris・AIX・HP-UXなどの商用UNIX機） - メインフレーム（「サーバーレス化したい」という相談への現実解） ### 移行判断の基本構図：EOL・保守費・人材 vs 移行リスク 移行を検討するきっかけはほぼ共通しています。ハードウェアの保守期限切れ（EOL）と部品調達難、年々上がる保守費、そしてそのOSを触れる技術者の枯渇です。一方で移行には、業務停止リスク・互換性検証・移行費用というコストが伴います。 判断のポイントは「移行しない場合のコスト」を正しく見積もることです。延命保守費は目に見えますが、障害時に復旧できる人がいないリスクやハード故障で業務が数週間止まるリスクは帳簿に載りません。保守契約が切れた（あるいはベンダーに更新を断られた）時点で、実質的には「いつ止まってもおかしくない資産」になっている——ここを経営層と共有できるかが、プロジェクト立ち上げの分水嶺になります。本記事の各論は、自治体のSolaris 10/SPARC基幹システムをOCIへ移行した弊社案件などで実際に判断した内容がベースです。 ## 7R分類の実務的な使い方 移行手法の分類として現在よく使われるのが「7R」です。もともとはガートナーのリサーチノート「Migrating Applications to the Cloud: Rehost, Refactor, Revise, Rebuild, or Replace?」で示した5分類が原型で、その後AWSが6R、さらにRelocateを加えた7Rへ拡張し、現在はAWSのPrescriptive Guidance（大規模移行ガイド）に整理されています。 | 戦略 | 内容 | レガシーサーバーでの典型例 | | Retire（廃止） | もう使われていないものを止める | 役目を終えた開発機・検証機。移行対象の1〜2割は実はこれ | | Retain（残置） | 今回は移行しない | 専用ハード直結の装置制御サーバー、更新間近のシステム | | Rehost（リホスト） | 構成を変えずIaaSへ「リフト&シフト」 | Linux/WindowsサーバーのVM移行。最速・最安 | | Relocate（リロケート） | 仮想化基盤ごとクラウドへ移設 | VMware環境をハイパーバイザーごと移す | | Replatform（リプラットフォーム） | OS・ミドルウェアを変えて載せ替え | Solaris→Linux転換、DBのマネージドサービス化。UNIX移行はほぼこれ | | Repurchase（再購入） | SaaSに乗り換える | 自前グループウェア・メールサーバー→SaaS | | Refactor（リファクタリング） | クラウドネイティブに作り直す | 基幹アプリのマイクロサービス化・サーバーレス化 | 実務でのコツは、7Rを「どの手法を選ぶか悩むためのフレームワーク」ではなく、サーバー台帳のラベルとして使うことです。アセスメントで全サーバーに7Rのいずれかを機械的に割り付けると、「Rehostで済む8割」と「Replatform以上が必要な2割」が仕分けされ、費用も期間もこの時点でほぼ骨格が決まります。悩むべきはラベルの境界にいる少数のサーバーだけです。 そして本記事の主題であるNTP・コンソール・UNIXサーバーは、いずれも「Rehostでは済まない側」の代表格です。以降、種別ごとに見ていきます。 ## NTPサーバーのクラウド化｜時刻同期サービスで代替できるか サーバー室の片隅で動き続けている構内NTPサーバー。クラウド移行の設計時に「これも移すのか？」と必ず話題になりますが、結論から言うと、**クラウド上のサーバー群の時刻源としては、NTPサーバーを移設する必要はほぼありません**。主要クラウドはいずれも、インスタンスからインターネット接続なしで到達できる時刻同期サービスを標準提供しているためです。 | クラウド | 時刻同期サービス | エンドポイント／方式 | 特徴 | | AWS | Amazon Time Sync Service | NTP: `169.254.169.123`（リンクローカル） | インターネット接続不要。一部の対応インスタンス（第7世代以降の対応ファミリー＋ENAドライバ2.10.0以降のLinux）ではPTPハードウェアクロックによるマイクロ秒精度も利用可 | | Azure | ホスト時刻同期（VMICTimeSync） | PTP: `/dev/ptp_hyperv`（Linuxはchronyのrefclockとして参照） | Azureホストの時刻をPTPクロックソースとして提供。新しめのディストリビューションは設定済み | | OCI | OCI NTPサービス | NTP: `169.254.169.254`（VCN内） | インターネット接続不要。近年のプラットフォームイメージはchrony設定済み | | Google Cloud | 内部NTPサーバー | NTP: `metadata.google.internal` | Google推奨の構成。うるう秒はスメア方式 | 設定も難しくありません。たとえばchronyの場合、AWSとOCIではそれぞれ次の1行が時刻源の指定になります（近年の公式イメージでは最初から設定されています）。 ``` # AWS（/etc/chrony.conf） server 169.254.169.123 prefer iburst minpoll 4 maxpoll 4 # OCI（/etc/chrony.conf） server 169.254.169.254 iburst # Azure Linux（ホスト時刻をPTP参照クロックとして使う場合） refclock PHC /dev/ptp_hyperv poll 3 dpoll -2 offset 0 stratum 2 ``` ### 専用NTPサーバーが「残る」3つのケース 一方で、次のケースでは構内NTPサーバー（またはその後継）が残ります。移行設計で見落とすと、切替後に「オンプレ側の機器の時刻がずれていく」事故につながります。 1. オンプレに残る機器群の時刻源：クラウド移行後も、ネットワーク機器・入退室管理・監視カメラ・製造装置などはオンプレに残ります。クラウドのリンクローカル時刻サービスはインスタンス内部からしか使えないため、残置機器の時刻源として構内NTP（または上位としてNICTの公開NTP `ntp.nict.jp` 等）が引き続き必要です。 2. GPS時刻源・Stratum 1が要件のシステム：GPS/GNSS受信機を持つStratum 1アプライアンスを自前運用しているのは、外部ネットワークに依存しない時刻源が要件だからです。この要件自体が変わらない限り、クラウドの時刻サービスでは代替になりません。 3. 閉域網・監査要件：インターネット非接続の閉域網では公開NTPが使えず、また監査・認証（ISO/IEC 27001やPCI DSSなど）で「単一の参照時刻源との同期」を管理・証明することが求められる環境では、時刻源の構成変更自体が監査対象になります。「クラウドの時刻サービスに変えました」で通るか、事前に監査側と握っておくべきポイントです。 ** 実務の落とし穴：うるう秒スメアリングの混在 AWSやGoogleの時刻サービスは、うるう秒を24時間かけて少しずつ吸収するスメア方式を採用しています。一方、NICTの公開NTPなど非スメアの時刻源とスメア方式の時刻源を同じサーバーの時刻源として混在させると、うるう秒前後に数百ミリ秒級の不整合が生じます。ハイブリッド構成では「クラウド側はクラウドの時刻サービス、オンプレ側は構内NTP」と系統を分け、片系統内で時刻源を統一するのが定石です。 ## コンソールサーバーのクラウド化｜シリアルコンソールと踏み台設計 コンソールサーバー（シリアルコンソール集約装置）の役割は、「ネットワーク経由でログインできなくなったサーバー・機器に、シリアルポート経由の最後の入口を確保する」帯域外（アウトオブバンド）管理です。OSがブートしない、ファイアウォール設定を誤って自分を閉め出した——そんなときの命綱でした。 クラウドではこの役割が2つに分解され、それぞれ標準機能で置き換わります。 ### 「最後の入口」はクラウドのシリアルコンソール機能へ 主要クラウドは仮想マシンに対するシリアルコンソール接続を提供しています。AWSのEC2シリアルコンソールは、インスタンスのネットワーク状態に関係なく、シリアルポート直結相当の接続でブートログの確認やシングルユーザーモードでの復旧作業ができます。Azureにもシリアルコンソール、OCIにもインスタンス・コンソール接続があり、「SSHできなくなったら詰み」という状況は物理時代と同様に回避できます。 ** 障害が起きてからでは遅い設定 EC2シリアルコンソールはデフォルト無効で、アカウント単位の許可設定とIAMポリシーの付与が必要です。またWindowsではSAC（特別管理コンソール）の事前有効化が要ります。物理コンソールサーバーは「つながっていれば使えた」のに対し、クラウドのシリアルコンソールは平時に設定・訓練しておかないと障害時に使えません。移行後の運用設計に必ず組み込んでください。 ### 平常時の管理アクセスは踏み台設計へ コンソールサーバーが担っていた「管理アクセスの集約点・操作ログの取得点」という役割は、クラウドでは踏み台（Bastion）設計に引き継がれます。近年はSSHポートを一切開けずにブラウザ・CLIから接続できるAWS Systems Manager Session Manager、Azure Bastion、OCI Bastionのようなマネージド踏み台が主流で、操作ログの保全・接続の認可をIAMで一元管理できます。「誰がいつどのサーバーに入ったか」の証跡は、物理コンソールサーバー時代より格段に取りやすくなりました。 ### 残置ハードとのハイブリッド構成 もうひとつ。コンソールサーバー自体は完全には無くなりません。オンプレやコロケーションに残るルーター・スイッチ・ストレージ・UPSなどのシリアル管理ポートには、引き続き物理的な接続手段が必要です。実務では「クラウド側はシリアルコンソール機能＋マネージド踏み台」「オンプレ残置機器には小型コンソールサーバーを残す（回線断に備えLTE等の別経路を持たせる）」というハイブリッドに落ち着くケースが多く、台数を10分の1に減らして役割を限定するのが落ち着きどころです。 ## UNIXサーバー（Solaris・AIX・HP-UX）のクラウド移行 レガシー移行で最も技術的なハードルが高いのが商用UNIXです。まず前提から。AWS・Azureの通常のIaaSでは、**Solaris・AIX・HP-UXは動きません**。x86 Linux/Windows前提のハイパースケーラーに、SPARC・POWER・PA-RISC/Itaniumのバイナリをそのまま持ち込むことはできないのです。 ### OS互換の壁：何がそのまま動かないのか - CPUアーキテクチャ：SPARC（Solaris）・POWER（AIX）のバイナリはx86では実行できません。ソースコードからの再コンパイルが必須で、ソースが失われている場合は再開発かエミュレーションの検討になります。 - エンディアン：SPARC・POWERはビッグエンディアン、x86はリトルエンディアン。バイナリ形式のデータファイルや独自形式のDBは、単純コピーでは読めません。DBはエクスポート／インポート（論理移行）が基本です。 - 文字コード：古いUNIX環境はEUC-JPやShift_JISが多く、移行先LinuxはUTF-8が標準。ファイル名・DB・帳票・連携ファイルの文字コード変換とテストが工数の山になります。 - OS固有機能：Solaris Zones、ZFS、SMF、AIXのLPAR/WPARなど、OS固有機能に依存した構成は移行先での代替設計（コンテナ化・VM分離など）が必要です。シェルの方言（Solaris shとbashの差異、`/usr/bin/awk`と`/usr/xpg4/bin/awk`の挙動差など）も地味に効いてきます。 ### OS別の現実的な移行パス | 移行元 | リホスト可否 | 現実的な選択肢 | | Solaris 11.4（x86） | 条件付きで可 | OCI MarketplaceにOracle公式のSolaris 11.4イメージ（VM/ベアメタル）があり、OSをSolarisのまま移せる事実上唯一のパス。Oracleサポート付き。SPARC版からはアプリの再コンパイルが必要 | | Solaris 10（SPARC） | 不可 | EOL済みでクラウド上の受け皿もないため、Linuxへのリプラットフォームが本命。Oracle DB中心のシステムならライセンス持ち込み（BYOL）ができるOCIが有力候補 | | AIX（POWER） | 専用基盤なら可 | 通常のIaaSでは不可だが、IBM Power Virtual Server（IBM Cloud）やKyndryl Cloud Uplift（旧Skytap on Azure。2026年に東京・大阪リージョンでも提供開始）などクラウド上のPOWER基盤でAIXのまま移行する選択肢がある。長期的にはLinux転換を並走させるケースが多い | | HP-UX（PA-RISC/Itanium） | 不可 | クラウド上の受け皿がなく、Linuxへのリプラットフォーム一択に近い。ISVパッケージ利用時は後継製品のLinux版への乗り換えを軸に計画 | つまりUNIXサーバーの移行は、7Rでいう**Replatform（OS転換を伴う載せ替え）が主戦場**です。リホストのつもりで見積もると、互換性対応・再テストの工数が丸ごと漏れます。逆に「全部作り直し（Refactor）しかない」と思い込むのも早計で、ミドルウェアから上の互換性を丁寧に検証すれば、アプリ資産を活かしたOS転換で済むことは珍しくありません。 ** 実例：官公庁の税務基幹システム Solaris 10/SPARC → OCI（移行期間4ヶ月） 弊社が担当した自治体様の案件では、SPARC T5240＋Solaris 10＋Oracle DB 11gの税務・住民台帳連携システムを、OCIベアメタル＋Oracle Linux 8＋Oracle DB 19cにリプラットフォームしました（事例ページではRe-host + Upgradeと表記しています）。既存のOracle DBライセンスをBYOLでOCIに持ち込んでコストを抑え、Data Pumpで約850GBのDBを論理移行、Data Guardで東京—大阪のDR構成まで含めて約4ヶ月・計画停止は週末夜間2時間。ハードウェア維持費は年間約480万円からゼロ（移行後のOCI利用料は別途発生しますが、ハード更改費を含む5年TCOで比較して削減）になり、可用性99.95%を達成しています。詳細は[事例ページ「Solaris/SPARCで動く税務系基幹システムをOCIへ移行」](https://technosphere.co.jp/cloud-migration/government-solaris-oci)をご覧ください。 なお、ハードウェアEOLを機に古い資産を移行するという構図は、組込み分野のマイコンでも同じです。SuperHマイコンのEOL対応をまとめた[SH（SuperH）マイコン移行ガイド](https://technosphere.co.jp/blog/superh-sh-migration-guide)も併せてどうぞ。サーバーもマイコンも、「動いているうちに、資産が読めるうちに」動くのが鉄則です。 ## メインフレームは「サーバーレス化」できるか 「メインフレームをサーバーレスにしたい」という相談を受けることがあります。**一足飛びのサーバーレス化は現実的ではありません**。バッチ・オンライン(CICS等)・JCL・データセットが密結合したモノリスを一括変換するリスクが大きすぎるためです。 落としどころは、段階的モダナイゼーションです。 1. まずクラウドで動かす：AWS Mainframe Modernizationのようなサービスで、リプラットフォーム（メインフレーム互換ランタイムでの稼働）または自動リファクタリング（COBOL→Java変換）によりクラウド上に移す。国内でも基幹システムでの活用事例が公表されています。 2. 周辺から剥がす：帳票・照会系・バッチの一部など、切り出しやすい機能からAPI化してマネージドサービスやサーバーレスに置き換える。いわゆるストラングラーフィグ（絞め殺しの木）パターンで、移行中は新旧が連携しながら共存します。 3. コアは最後に：勘定系・基幹バッチの中核は、周辺の置き換えでリスクと規模を十分に削ってから着手する。 「サーバーレス」は最初のゴールではなく、クラウド移行後の継続的な改善の到達点と捉えるのが健全です。提案書では『サーバーレス化』を最終形の絵として置き、初年度のスコープは『クラウドで現行同等に動かす』までに切る——この二段構えにしないと稟議も工程も持ちません。 ## 移行プロジェクトの進め方と見積もりの考え方 種別ごとの各論を踏まえた上で、プロジェクト全体はアセスメント→PoC→段階移行の3段階で進めます。 ### Step 1. アセスメント（現状調査） 全サーバーの台帳を作り、OS・ミドルウェア・依存関係・データ量・利用状況を棚卸しして、1台ごとに7Rのラベルを付けます。レガシー環境では「ドキュメントがない」「作った人がいない」が普通なので、構成管理ツールの出力だけでなく、実機のプロセス・cron・接続先の実態調査が欠かせません。この段階でRetire（実は使われていない）を洗い出せると、移行対象そのものが減ります。 ### Step 2. PoC（技術検証） リスクの高い1〜2システムを選び、小さく移行して検証します。UNIX移行なら「主要アプリが移行先OSでビルド・動作するか」「DBの論理移行が業務停止許容時間内に終わるか」、NTP・コンソールのような基盤系なら「切替後の運用手順が回るか」。PoCの結果で本移行の見積もりを確定させる——この順番を崩さないことです。 ### Step 3. 段階移行 影響の小さいシステムから数回のウェーブに分けて移行します。基幹系は並行稼働期間（新旧同時稼働での突合）を設け、切り戻し手順を用意した上で、業務カレンダー上の閑散期に本番切替を行います。前述の自治体案件では、税務の年度末繁忙期を避けた10月〜1月に工期を設定し、2週間の並行稼働を経て週末夜間に切り替えました。 ### 見積もりの考え方 費用は概ね次の構造で積み上がります。 | 費目 | ドライバー（何で金額が決まるか） | | アセスメント | サーバー台数と資料の残存度。ここをケチると後工程の手戻りで倍返しになる | | 移行設計・構築 | 7Rの内訳。Rehost 1に対しReplatformは数倍の工数が目安。ネットワーク（閉域接続・VPN）設計も含む | | データ移行 | データ量より許容停止時間が支配的。停止ゼロ要件は差分同期の仕組みが必要になり跳ね上がる | | テスト・並行稼働 | 連携先システムの数。レガシー基幹は連携テストが工数の過半を占めることも | | 移行後ランニング | クラウド利用料。BYOL（ライセンス持ち込み）や リザーブド/コミット割引の設計で大きく変わる | 発注側として見積もりの妥当性を測るなら、「7Rの内訳を提示しているか」「PoCフェーズが切られているか」「停止許容時間を確認してきたか」の3点を見てください。この3つを聞かずに一式いくらを出してくるベンダーの見積もりは、ほぼ確実に後で膨らみます。 相見積もりを取る前に、最低限これだけ揃えてください。①サーバー一覧（ホスト名・OS/バージョン・ハード保守期限）②主要ミドルウェアとライセンス形態（Oracle DB等はBYOL可否に直結）③連携先システムの一覧 ④業務ごとの許容停止時間 ⑤データ量。この5点があるだけで、初回見積もりの精度と速度がまったく変わります。 ## まとめ ### 上司に説明するなら、この3点です - 商用UNIXはAWS/AzureのIaaSでは動かないため、リホスト前提の概算は必ず膨らむ - 費用は7Rの内訳と許容停止時間でほぼ決まる - NTP・コンソールはクラウド標準機能で置き換わるが、オンプレ残置分の設計を忘れると事故る レガシーサーバーの移行は、「総論」ではなく1台ごとの各論の積み重ねです。自社の台帳を前に判断に迷うサーバーがあれば、お気軽にご相談ください。 ／レガシーサーバーの移行相談はこちら＼ ### Solaris・UNIX・レガシーサーバーのクラウド移行 官公庁のSolaris/SPARC→OCI移行をはじめ、AWS / Azure / GCP / OCI / さくらのクラウドへの移行を受託しています。アセスメント（現状調査）だけのご依頼も歓迎です。初回ヒアリング・概算見積もりは無料。 [クラウド移行サービスを見る](https://technosphere.co.jp/cloud-migration) [移行の無料相談](https://technosphere.co.jp/contact) ## よくある質問（FAQ） ** SolarisサーバーはAWSやAzureにそのまま移行できますか？ できません。AWS・Azureの通常のIaaSは商用UNIX（Solaris/AIX/HP-UX）をサポートしていません。x86版のOracle Solaris 11.4はOCI Marketplaceの公式イメージで稼働できますが、SPARC版のバイナリはx86上でそのまま動かないため、多くの案件ではLinuxへのリプラットフォーム（OS転換＋再構築）が現実解になります。 ** NTPサーバーはクラウド移行後も必要ですか？ クラウド上のサーバーの時刻同期は、Amazon Time Sync Service（`169.254.169.123`）やOCIのNTPサービス（`169.254.169.254`）など各クラウド標準の時刻同期サービスで代替でき、専用NTPサーバーの移設は不要なことがほとんどです。ただしオンプレに残る機器群の時刻源、GPS受信機を持つStratum 1環境、閉域網、時刻源の指定がある監査要件では構内NTPが残ります。 ** コンソールサーバー経由の障害対応はクラウドでどうなりますか？ OSが起動しない・ネットワーク設定を壊したという場面には、EC2シリアルコンソールやAzureシリアルコンソール、OCIのインスタンス・コンソール接続が用意されており、物理コンソールサーバーの主用途を代替できます。平常時の管理アクセスは踏み台（Bastion）やAWS Systems Manager Session Managerに寄せる設計が一般的です。ネットワーク機器などオンプレに残るハードには引き続きコンソールサーバーが必要です。 ** メインフレームをサーバーレス化することは可能ですか？ 一足飛びのサーバーレス化は現実的ではありません。まずAWS Mainframe Modernizationなどでリプラットフォームまたは自動リファクタリング（COBOL→Java変換）を行い、クラウド上で稼働させた後、周辺機能から段階的にマネージドサービスやサーバーレスへ置き換えるストラングラーフィグ（段階的置換）型のアプローチが推奨されています。 ** レガシーサーバーのクラウド移行費用はどうやって見積もりますか？ サーバー台帳をもとに1台ごとに7R（リホスト・リプラットフォーム等）のラベルを付け、パターン別の移行工数×台数で積算するのが基本です。リホストとリプラットフォームでは工数が数倍違うため、アセスメントでこの仕分けを先に確定させることが見積もり精度を左右します。弊社では[初回ヒアリングと概算見積もりを無料](https://technosphere.co.jp/contact)で行っています。 # レガシーマイグレーション # クラウド移行 # UNIXサーバー # Solaris # NTPサーバー # コンソールサーバー # OCI # 7R ## 次に読む｜クラウド移行・レガシー関連 - [移行実績 公共・自治体｜Solaris/SPARCの税務系基幹システムをOCIへ移行 本記事で紹介したSolaris 10→OCI移行の事例詳細（4ヶ月・可用性99.95%）](https://technosphere.co.jp/cloud-migration/government-solaris-oci) - [サービス クラウドマイグレーション・コスト最適化 AWS / Azure / GCP / OCI / さくらのクラウド対応。逆移行（クラウド→オンプレ）も](https://technosphere.co.jp/cloud-migration) - [レガシー移行シリーズ SH（SuperH）マイコン移行ガイド EOLマイコンの移行という「組込み版レガシーマイグレーション」](https://technosphere.co.jp/blog/superh-sh-migration-guide) - [レガシー移行シリーズ 8051・Z80レガシーマイコン移行ガイド 数十年モノの資産を安全に現行環境へ移すノウハウ](https://technosphere.co.jp/blog/8051-z80-legacy-migration-guide) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # 複数カメラ映像の合成技術｜設置角度に依存しない横並び統合（射影変換×スティッチング）｜テクノスフィア > 設置角度がバラバラな複数のカメラ映像を、射影変換（ホモグラフィ）と画像スティッチングで1枚の横並び・俯瞰映像に統合する技術を解説。カメラキャリブレーション、位置合わせ、ブレンディングの考え方と、広域監視・現場AIへの活用を大阪のテクノスフィアが紹介します。 URL: https://technosphere.co.jp/blog/multi-camera-image-stitching 広い現場を1台のカメラでカバーするのは困難で、複数台を設置すると今度は「映像がバラバラで全体像をつかみにくい」という課題が生まれます。本記事では、**設置角度の異なる複数カメラの映像を、射影変換と画像スティッチングで1枚の横並び・俯瞰映像に統合する技術**を、実装の勘所とともに解説します。 （図: 複数カメラの映像を1枚の広いパノラマ映像に合成するイメージ） この記事の要点：** 各カメラの**射影変換（ホモグラフィ）**を求めて共通基準面へ投影すれば、設置角度の違いを吸収して横並び・俯瞰に統合できます。変換を事前確定しておけばリアルタイム合成も可能で、死角のない現場把握とAI解析の基盤になります。 ## 複数カメラ運用の課題 カメラを増やすほど死角は減りますが、運用者は**複数の分割画面を同時に見比べる**必要があり、認知負荷が高くなります。さらにカメラごとに設置高さ・角度・画角が異なるため、「同じ人が隣のカメラに移った」といった**カメラをまたいだ連続把握**が難しくなります。これを解決するのが映像合成（スティッチング）です。 ## 合成技術の全体像 複数カメラ合成は、おおまかに次の流れで実現します。 1. **キャリブレーション**：各カメラのレンズ歪みや内部パラメータを補正。 2. **射影変換（ホモグラフィ）の推定**：各映像を共通の基準面（地面や仮想スクリーン）へ投影する変換を求める。 3. **位置合わせ（レジストレーション）**：重なり領域の特徴点を対応づけ、ズレを最小化。 4. **スティッチング＆ブレンディング**：変換後の映像をつなぎ、継ぎ目をなめらかに合成。 5. **横並び・俯瞰への統合**：1枚のパノラマ／俯瞰ビューとして出力。 （図: 角度の異なる複数カメラを射影変換し1枚の統合ビューにする流れのイメージ） 角度の異なる各カメラ映像を射影変換し、1枚の統合ビューへ ## 設置角度を吸収する「射影変換」 カメラごとに設置角度が違っても、対象を**同一平面（基準面）への射影**として捉え直せば、見え方を揃えられます。これが射影変換（ホモグラフィ）です。基準面上の4点以上の対応関係から変換行列を求め、各映像を基準面へ「貼り直す」ことで、斜めから見た映像を俯瞰相当へ補正し、横並びに整列できます。 変換行列は**設置後に一度確定すれば固定で使える**ため、毎フレームは決まった変換を適用するだけ。これがリアルタイム合成を可能にします。 ## 位置合わせとブレンディング 隣り合うカメラの**重なり領域**で特徴点を対応づけ、ズレを補正します。つなぎ目は明るさ・色の差が出やすいため、**ブレンディング（重み付き合成や継ぎ目の最適化）**でなめらかにします。動く物体が継ぎ目をまたぐ場合の二重像を抑える工夫も重要です。 ## 活用例 - **広域監視**：工場・倉庫・駐車場・店舗を1画面で俯瞰し、死角を削減。 - **横断追跡**：複数カメラをまたいで人・車・フォークリフトを連続追跡。 - **動線・混雑分析**：統合ビュー上で動線や滞留を可視化。 - **AI解析の基盤**：合成映像を入力に、検知・計数・異常検知を実施。 弊社の現場AI[「GENBA IQ」](https://technosphere.co.jp/genba-iq)では、こうした合成映像を解析基盤として活用し、現場全体をリアルタイムに把握します。 ## 実装の勘所 - **基準面の設計**：地面など共通平面を基準にすると俯瞰統合が安定する。 - **重なり領域の確保**：隣接カメラに十分な重なりを持たせると位置合わせが容易。 - **キャリブレーションの保守**：カメラの振動・ずれに備え、再調整しやすい運用に。 - **処理負荷の最適化**：解像度・フレームレートと精度のバランスをエッジ／GPUで設計。 ## よくある質問（FAQ） Q. 複数カメラ映像の合成（スティッチング）とは？ 位置・角度の異なる複数カメラ映像を幾何変換で位置合わせし、重なりをなめらかにつないで1枚の広い映像（パノラマ・俯瞰）に統合する技術です。 Q. 設置角度がバラバラでも合成できますか？ できます。各カメラの射影変換（ホモグラフィ）を求めて共通基準面へ投影し、角度差を吸収して横並び・俯瞰に統合します。 Q. リアルタイム処理は可能ですか？ 変換パラメータを事前確定すれば、各フレームは決まった変換を適用するだけなので、エッジ／GPUでリアルタイム合成が可能です。 Q. どんな用途に使えますか？ 広域監視、死角のない俯瞰ビュー、複数カメラをまたいだ追跡や動線分析などに活用できます。 ## まとめ ** この記事のまとめ - 射影変換（ホモグラフィ）で各カメラを共通基準面へ投影すれば、設置角度の違いを吸収して横並び・俯瞰に統合できる。 - 変換を事前確定すればリアルタイム合成が可能で、死角のない現場把握につながる。 - 合成映像はAI解析の基盤となり、横断追跡や動線分析に活用できる。 複数カメラの統合・広域監視のシステム化をご検討の方は、ぜひ[お気軽にお問い合わせください](https://technosphere.co.jp/contact)。要件に応じて最適な構成をご提案します。 ／画像処理・映像合成の受託開発＼ ### 画像認識・映像処理システムの開発 複数カメラの合成・俯瞰統合から、検知・追跡・動線分析まで。設置環境に合わせた画像処理システムを、要件定義からPoC・本番まで受託開発します。 [画像認識システムを見る](https://technosphere.co.jp/vision-system) [映像合成を相談する](https://technosphere.co.jp/contact) [# 画像処理](https://technosphere.co.jp/blog/)[# 射影変換](https://technosphere.co.jp/blog/)[# 画像スティッチング](https://technosphere.co.jp/blog/)[# カメラキャリブレーション](https://technosphere.co.jp/blog/)[# 広域監視](https://technosphere.co.jp/blog/) ** この記事をシェア [X](https://twitter.com/intent/tweet?url=https://technosphere.co.jp/blog/multi-camera-image-stitching&text=複数カメラ映像の合成技術｜設置角度に依存しない横並び統合&via=technosphere_co) [Facebook](https://www.facebook.com/sharer/sharer.php?u=https://technosphere.co.jp/blog/multi-camera-image-stitching) [LINE](https://social-plugins.line.me/lineit/share?url=https://technosphere.co.jp/blog/multi-camera-image-stitching) --- # ネイティブアプリ・クロスプラットフォーム・PWAの選び方｜業務アプリで失敗しない技術選定｜テクノスフィア > スマホアプリの開発方式をどう選ぶか。ネイティブ(Swift/Kotlin)・クロスプラットフォーム(Flutter/React Native)・PWAの違いを、プッシュ通知・オフライン動作・カメラ・配布方法・費用の観点で比較。業務アプリの技術選定で判断を誤らないためのフローチャート付き。 URL: https://technosphere.co.jp/blog/native-vs-pwa-app-choice ** 目次 1. 3つの選択肢と、それぞれの正体 2. 判断を分ける6つの軸 3. つまずきポイント①：iOSのプッシュ通知 4. つまずきポイント②：オフライン動作の実装コスト 5. つまずきポイント③：配布方法と審査 6. フローチャート：どれを選ぶか 7. 後から乗り換えられる設計にしておく 8. よくある質問（FAQ） 9. まとめ ## 3つの選択肢と、それぞれの正体 スマホアプリを作ると決めた後、最初の分岐が「どの方式で作るか」です。選択肢は大きく3つあります。 ``` ① ネイティブ Swift (iOS) / Kotlin (Android) → OS純正の作り方。性能と機能の自由度が最大 ② クロスプラットフォーム Flutter / React Native → 1つのコードで両OS。UI は独自描画 or ネイティブ部品 ③ PWA HTML/CSS/JavaScript + Service Worker → 実体はWebサイト。ホーム画面に追加してアプリのように使う ``` よくある誤解は「PWA＝安いネイティブの下位互換」というものです。実際は**できることの種類が違う**だけで、社内配布のツールならPWAのほうが運用が軽く、審査待ちもなく、更新も即時反映されるという明確な利点があります。逆に、通知を軸にした顧客向けアプリでPWAを選ぶと、後述の理由で施策が成立しません。 ## 判断を分ける6つの軸 案件ごとに次の6項目を確認すれば、方式はほぼ自動的に決まります。 | 軸 | ネイティブ | クロスプラットフォーム | PWA | | プッシュ通知 | ◎ 制約なし | ◎ 制約なし | △ iOSは条件付き | | オフライン動作 | ◎ | ◎ | ○ 実装次第 | | カメラ・センサー | ◎ 全機能 | ○ プラグイン依存 | △ 制限あり | | Bluetooth・USB機器連携 | ◎ | ○ プラグイン依存 | × 実質不可 | | 配布・更新 | △ 審査あり | △ 審査あり | ◎ URL・即時反映 | | 開発費（両OS対応時） | 高（2つ作る） | 中 | 低 | 表を見ると、**「Bluetooth機器とつなぐ」「センサーを細かく制御する」が要件に入った瞬間にPWAは落ちる**ことが分かります。逆に、社内の入力フォームや一覧表示が中心で、配布の手軽さと更新の速さを優先するなら、PWAで十分どころか最適です。 ## つまずきポイント①：iOSのプッシュ通知 「PWAでも通知は送れます」——これは正しいのですが、iOSでは重要な前提が付きます。 ``` iOS 16.4 以降: ✅ Web Push は使える ⚠️ ただし「ホーム画面に追加」したPWAに限られる （Safariのタブで開いているだけでは通知が届かない） Android: ✅ Chrome でそのまま Web Push が使える（ホーム画面追加は任意） ``` つまりiPhoneユーザーには、**「共有ボタンを押して、ホーム画面に追加してください」という操作を案内し、実行してもらう**必要があります。社内向けで配布時に説明できるなら現実的ですが、一般ユーザー向けアプリでこの一手間を挟むと、通知を受け取れる人の割合は大きく落ちます。 **判断基準はシンプルです。**プッシュ通知が施策の中心（再来店促進、緊急連絡、リマインド）なら、ネイティブまたはクロスプラットフォームを選んでください。通知が「あれば便利」程度ならPWAで問題ありません。 ## つまずきポイント②：オフライン動作の実装コスト 倉庫・工場・地下・山間部など、通信が不安定な現場で使うアプリでは「圏外でも入力できる」が必須要件になります。ここで見落とされがちなのが、**オフライン対応の本体はUIではなくデータ同期の設計**だという点です。 方式を問わず、次の問題を必ず設計する必要があります。 - **競合の解決** — 同じデータをAさんとBさんが別々にオフライン編集したら、どちらを採用するか - **送信の再試行** — 電波が戻ったときに未送信データを自動送信し、失敗時は再試行する - **重複の防止** — 再試行で同じデータが二重登録されないよう、クライアント側で一意IDを持たせる - **ストレージ上限** — 端末に貯め込めるデータ量の上限と、古いデータの破棄ルール この設計を省くと、「圏外で入力したデータが消えた」「同じ報告が2件登録される」といった、現場の信頼を一発で失う不具合が起きます。オフライン要件がある案件では、UIより先にこの部分を詰めてください。 ``` // 二重登録を防ぐ: クライアントで一意IDを発行して送る const record = { clientId: crypto.randomUUID(), // 端末側で採番 inspectedAt: new Date().toISOString(), items: [...], }; await queue.enqueue(record); // まずローカルに保存 // オンライン復帰時にまとめて送信（サーバーは clientId で重複を弾く） window.addEventListener('online', () => queue.flush()); ``` ## つまずきポイント③：配布方法と審査 意外と見落とされるのが配布です。とくに**社内利用のアプリをApp Storeに公開したくない**ケースでは、方式選定に直結します。 | 配布方法 | 対象 | 特徴 | | App Store / Google Play | 一般公開 | 誰でも入手可。審査に1〜2週間 | | Apple Business Manager（カスタムApp） | iOS社内配布 | 指定組織にのみ配信。審査あり | | MDM経由 | iOS/Android社内配布 | 端末管理と合わせて配布。MDM導入が前提 | | Google Play 限定公開 / APK配布 | Android社内配布 | 比較的手軽 | | PWA（URL配布） | 制限なし | 審査ゼロ・更新即時。ホーム画面追加を案内する | **審査は開発スケジュールに影響します。**ネイティブ・クロスプラットフォームでは、リリース後の緊急修正にも審査が挟まります（Appleの迅速化申請はありますが確約ではありません）。頻繁に更新したい業務ツールほど、PWAの「即時反映」が効いてきます。 ## フローチャート：どれを選ぶか 実際の案件で使っている判断順です。上から順に見ていけば、だいたい迷わず決まります。 ``` Q1. Bluetooth/USB機器やセンサーを細かく制御する？ YES → ネイティブ（or ネイティブ拡張を含むクロスプラットフォーム） NO ↓ Q2. iOSユーザーへのプッシュ通知が施策の中心？ YES → ネイティブ / クロスプラットフォーム NO ↓ Q3. App Store・Google Play で一般公開して露出を取りたい？ YES → ネイティブ / クロスプラットフォーム NO ↓ Q4. 更新頻度が高い、または審査待ちを避けたい？ YES → PWA NO ↓ Q5. 予算と期間を最小に抑えたい？ YES → PWA NO → クロスプラットフォーム（両OS対応の費用対効果が最も高い） ``` 補足として、Q1でネイティブに倒れた場合でも「片方のOSだけ先に作る」という選択肢があります。社内配布ならAndroidだけ、店舗の貸与端末がiPadならiOSだけ、といった具合に対象端末を固定できるなら、開発費は半分近くに抑えられます。 ## 後から乗り換えられる設計にしておく 技術選定でいちばん怖いのは「読み違えたときに全部作り直しになる」ことです。これは設計で相当程度、回避できます。 - **業務ロジックはサーバー側のAPIに置く** — 端末側は表示と入力に徹する。移行時に作り直すのはUIだけで済みます - **データモデルを端末に依存させない** — 端末固有の保存形式に業務データを直接書かない - **認証は標準的な方式で** — OAuth 2.0 / OIDC など、どの方式からでも使える形にしておく - **まずPWAで検証してからネイティブへ** — 使われ方が読めない新規業務では、PWAで安く早く出して実際の利用状況を見る進め方が有効です 実際に弊社では、[ブラウザだけで動く3Dアプリ](https://technosphere.co.jp/blog/threejs-mobile-3d-game)のように、Web技術でどこまでできるかを検証したうえで、必要な部分だけネイティブに寄せる進め方を採ることがあります。[実際に動くデモ](https://technosphere.co.jp/games/drone-inspector/)も公開しているので、Web技術の到達点の参考にしてください。 ## よくある質問（FAQ） ### Q. PWAでもiPhoneにプッシュ通知は送れますか？ 送れます。iOS 16.4以降、ホーム画面に追加したPWAでWeb Pushが使えます。ただしホーム画面への追加操作が必須で、この一手間で到達率が落ちます。通知が中心の施策ならネイティブ系が確実です。 ### Q. FlutterとReact Nativeはどちらを選ぶべきですか？ 既存チームがReact/TypeScriptに慣れているならReact Native、UIをiOS/Androidで完全に揃えたい・描画性能を重視するならFlutterです。特殊なハードウェア連携がある場合は、いずれもネイティブコードを書く前提で見積もってください。 ### Q. 業務アプリをストアに公開せず配布できますか？ できます。配布方法の比較のとおり、Apple Business Manager・MDM・Google Play限定公開などの手段があります。社内限定ならPWAでURL配布という選択肢も有力です。 ### Q. 後からネイティブに作り直せますか？ できますが、UIは作り直しになります。業務ロジックをサーバー側に寄せておくと、移行時の影響をUIだけに閉じ込められます。 ## まとめ ### この記事のまとめ - PWAは「安い下位互換」ではなく、配布の手軽さと更新の速さで優位に立つ選択肢 - Bluetooth・センサー制御が要件に入ったらPWAは選べない - iOSのWeb Pushは「ホーム画面に追加」が前提。通知中心の施策ならネイティブ系 - オフライン対応の本体はUIではなく同期設計（競合解決・再試行・重複防止） - 業務ロジックをサーバー側に寄せておけば、後から方式を乗り換えても影響はUIだけ テクノスフィアでは、iOS/Androidネイティブ、Flutter・React Native、PWAのいずれにも対応し、機器側の組込み開発やサーバー・クラウド構築まで自社で行っています。「アプリにすべきか、Webで足りるか」の判断からご相談いただけます。 [▶ スマホアプリ開発サービスを見る](https://technosphere.co.jp/app-development) ｜ [開発の相談をする](https://technosphere.co.jp/contact?category=web) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # OpenClaw入門｜導入手順から社内Kubernetes本番運用まで完全ガイド【2026年版】｜テクノスフィア > OSSのAIエージェント基盤 OpenClaw の導入手順を実体験で解説。Docker Composeでの最短起動から、Codex Pro＋ローカルLLMのハイブリッド構成、Raspberry Pi 5 + k3s での本番運用、ハマりどころ7つまで。社内活用を検討する方向けの完全ガイド。 URL: https://technosphere.co.jp/blog/openclaw-getting-started ** 目次 1. はじめに：なぜ社内に OpenClaw を立てるのか 2. OpenClaw とは何か（Claude Code・Cursor との違い） 3. 弊社で採用したアーキテクチャ全体像 4. 最短ステップ：Docker Compose でローカル起動 5. LLM プロバイダ設定（Codex Pro + ローカル fallback） 6. 本番運用：Raspberry Pi 5 + k3s への展開 7. Secret / ConfigMap / PVC の設計指針 8. 初回 OAuth ログインの儀式 9. テクノスフィアでハマったポイント 7 つ 10. よくある質問（FAQ） 11. まとめ ** 本記事のスコープ 本記事は OpenClaw v2026.5 系の構成情報をもとに、社内 LAN に閉じた運用を前提とした環境構築手順を解説します。OpenClaw 本体の仕様は活発に更新されているため、最終的なバージョンや CLI 引数は [公式ドキュメント](https://openclaw.ai/) も併せてご確認ください。 ## はじめに：なぜ社内に OpenClaw を立てるのか ここ1〜2年で、エンジニアの開発・運用・営業フローに AI アシスタントが組み込まれるのは当たり前になりました。Claude Code、Cursor、Codex、Aider、Continue……選択肢は爆発的に増えています。一方で、業務利用が深くなるほど次のような**「クラウド SaaS だけでは困る」**場面が増えてきます。 - 社内ファイルサーバ・Redmine・社内 Gitea などの**クローズドな業務システムを叩かせたい** - 機密情報を外部 SaaS にそのまま渡したくない - 長尺の自動化スクリプトを **24時間動く常駐エージェント**として走らせたい - 各部門で **用途別のスキル（プロンプト + ツール）** を整備・共有したい そこで弊社が選んだのが **OpenClaw** です。Claude Code 系のターミナル CLI ではなく、**サーバ常駐型・スキル拡張可能・ローカル LLM もクラウド LLM も差し替え可能**な OSS のエージェント基盤として、社内 Kubernetes 上で運用しています。本記事ではその環境構築の全体像と、実運用で得た知見を解説します。 ** テクノスフィアでの活用範囲 弊社では OpenClaw を「**常駐型の業務AIアシスタント（社内コードネーム mio）**」として運用しています。社内 Redmine の更新、Obsidian Vault への作業ログ自動同期、Google Analytics の集計、SUGUMEN / 現場IQ など自社プロダクトの問い合わせ起票、画像生成・動画生成・Web 検索などを 1 つの会話チャネルから扱える状態にしています。 ## OpenClaw とは何か（Claude Code・Cursor との違い） OpenClaw（オープンクロウ）は、複数 LLM プロバイダを切り替えながら使える **OSS の AI エージェント基盤**です。Claude Code や Cursor のように開発者個人の手元で動かす CLI / IDE プラグインとは少し位置づけが異なり、**HTTP サーバとして常時稼働させ、複数のクライアント・チャネルから接続して使う**形が基本になります。 | 軸 | Claude Code / Codex CLI | Cursor / Continue | OpenClaw | | 形態 | ターミナル CLI | IDE プラグイン | HTTP サーバ常駐 | | LLM | 提供元固定（Anthropic / OpenAI） | クラウド SaaS 中心 | **差し替え自由**（OAuth / OpenAI 互換 / ローカル） | | スキル拡張 | ○（CLI 同梱） | △ | ◎（workspace/skills/ で配布） | | マルチユーザ | ×（個人端末） | × | ○（gateway トークン認証） | | 常駐運用 | × | × | ○（systemd / k8s） | | チャネル | ターミナルのみ | IDE のみ | Web UI / Slack / WhatsApp / Telegram 他 | つまり OpenClaw は、Claude Code のような**「便利な対話 CLI」**を、Slack / Teams / Web チャットからも叩けて、しかも複数の LLM をフォールバックさせ、社内データに永続的にアクセスできるエージェントに昇格させたい場合に刺さるツールです。コードを書く瞬間の体験は Claude Code に分がありますが、**業務全体を支える「社内AI窓口」**としてのポジションでは OpenClaw が圧倒的に扱いやすいと感じています。 ## 弊社で採用したアーキテクチャ全体像 テクノスフィアの社内 LAN（`192.168.11.0/24`）に閉じた構成です。Pi5 を OpenClaw 本体の稼働ホスト、NAS と Ubuntu サーバを周辺サービスにあてています。 ``` ┌─────────────────────────────────────────────────────────────┐ │ 社内 LAN (192.168.11.0/24) │ │ │ │ ┌──────────────────┐ ┌──────────────────────────────┐ │ │ │ Synology NAS │ │ Ubuntu Server │ │ │ │ 192.168.11.241 │ │ 192.168.11.248 │ │ │ │ ├ Redmine :8080 │ │ ├ Lemonade LLM :8000 │ │ │ │ ├ Growi :3000 │ │ │ (Qwen / Gemma local) │ │ │ │ └ chatgpt-bridge │ │ └ docker registry │ │ │ │ :18080 │ └──────────────────────────────┘ │ │ │ (gpt-image-2) │ │ │ └──────────────────┘ │ │ ▲ │ │ │ image-gen skill │ │ ┌────────┴───────────────────────────────────┐ │ │ │ Raspberry Pi 5 (192.168.11.250) │ │ │ │ ┌────────────────────────────────────────┐ │ │ │ │ │ k3s (single-node, Traefik, local-path)│ │ │ │ │ │ ┌──────────────────────────────────┐ │ │ │ │ │ │ │ Namespace: openclaw │ │ │ │ │ │ │ │ ├ Deployment: openclaw │ │ │ │ │ │ │ │ │ image: ghcr.io/openclaw │ │ │ │ │ │ │ │ │ port: 18789 │ │ │ │ │ │ │ │ ├ ConfigMap: openclaw-config │ │ │ │ │ │ │ │ ├ Secret: openclaw-secrets │ │ │ │ │ │ │ │ └ PVC: openclaw-data │ │ │ │ │ │ │ └──────────────────────────────────┘ │ │ │ │ │ └────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────┘ ``` ### 採用理由 - **Pi5 + k3s：**消費電力 10W 未満で 24h 動かせる。社内 AI 基盤を専用サーバ化するほど大規模ではないので、コスト・スペースともに Pi5 が最適 - **LLM のローカル化：**Ubuntu 機の Lemonade（llama.cpp + OpenAI 互換 API）に Qwen 3.6 35B を載せ、社内データの問い合わせはこちらに流す。クラウド料金もゼロ - **クラウド LLM の併用：**コード生成や深い推論が必要な場合は Codex Pro のサブスク枠を OAuth で組み込み - **NAS の chatgpt-bridge：**OpenAI 互換エンドポイントで `gpt-image-2` を社内 LAN 内に閉じて提供。OpenClaw からは `image-gen` スキル経由で叩く ## 最短ステップ：Docker Compose でローカル起動 まずは個人 PC や検証用 VM 上で動くようにするのが最短ルートです。**k3s からいきなり始めるとデバッグが辛い**ので、必ずローカル起動を通してから本番展開する流れをおすすめします。 ### 1. compose.yaml を用意する ``` services: openclaw: image: ghcr.io/openclaw/openclaw:2026.5.7 container_name: openclaw ports: - "18789:18789" environment: OPENCLAW_SKIP_ONBOARDING: "1" OPENCLAW_DISABLE_BONJOUR: "1" volumes: - ./data:/home/node/.openclaw - ./openclaw.json:/home/node/.openclaw/openclaw.json:ro restart: unless-stopped ``` ### 2. openclaw.json の最小構成 ``` { "gateway": { "bind": "custom", "customBindHost": "0.0.0.0", "auth": { "mode": "token", "token": "REPLACE_ME_RANDOM_32CHARS" } }, "models": { "mode": "merge", "providers": { "lemonade-local": { "baseUrl": "http://192.168.11.248:8000/api/v1", "api": "openai-completions", "models": [ { "id": "user.Qwen3.6-35B-A3B-Q4", "name": "Qwen 3.6 35B A3B Q4 (Local)", "reasoning": true, "input": ["text"], "cost": { "input": 0, "output": 0 }, "contextWindow": 262144, "contextTokens": 240000, "maxTokens": 16384 } ] } } }, "agents": { "defaults": { "model": { "primary": "lemonade-local/user.Qwen3.6-35B-A3B-Q4" } } } } ``` ### 3. 起動と動作確認 ``` docker compose up -d curl http://127.0.0.1:18789/healthz # → {"status":"ok"} # ブラウザで http://localhost:18789/ にアクセス # 起動時に gateway token を入れるとログイン完了 ``` ** Docker 推奨の理由 弊社のグローバルルールとして **本番サーバへの直接 `apt install` / `pip install` は禁止**しています。OpenClaw もホストに Node.js を入れず、必ず Docker イメージで稼働させてください。理由は依存関係の汚染防止と、後で k8s に移行する際の互換性確保です。 ## LLM プロバイダ設定（Codex Pro + ローカル fallback） OpenClaw の真価は **LLM プロバイダを混ぜて使える**ところにあります。コード生成のような重い処理はクラウド LLM に投げ、雑談や軽い要約はローカル LLM で済ませる、という**段階運用**がそのまま設定ファイルで書けます。 ### 弊社の本番構成（primary + fallback） ``` { "agents": { "defaults": { "model": { "primary": "openai-codex/gpt-5.5", "fallbacks": [ "lemonade-local/user.Qwen3.6-35B-A3B-Q4" ] } } } } ``` - **primary：**Codex Pro の `gpt-5.5`（OAuth ログインで Codex Pro サブスク枠を利用） - **fallback：**クラウド API 障害・サブスク枠切れ時に Lemonade のローカル Qwen 3.6 35B に落ちる 運用してみるとわかりますが、**「primary が落ちても止まらない」**のは社内 AI の SLA としては大きなメリットです。Qwen の応答品質は GPT-5.5 と比べれば劣りますが、要約・整形・社内検索程度なら十分実用になります。 ** なぜ Lemonade を経由するのか **Lemonade** は llama.cpp 系のローカル推論サーバを OpenAI 互換 API として公開してくれるラッパーです。OpenClaw 側のプロバイダ設定は `"api": "openai-completions"` 1 行で済むので、モデルを Qwen → Gemma → Llama 3 などに差し替えるたびに OpenClaw を触らずに済みます。社内 LLM の入れ替えサイクルが速い現状ではこの分離が効きます。 ## 本番運用：Raspberry Pi 5 + k3s への展開 ローカルで挙動を確認したら、いよいよ社内 k3s に展開します。弊社のリポジトリ `technosphere-openclaw` の `k3s/` ディレクトリには Kustomize 一式を置いてあり、これを `kubectl apply -k` で投入する形にしています。 ### マニフェスト一式の全体像 ``` k3s/ ├── kustomization.yaml ├── namespace.yaml # openclaw namespace ├── configmap.yaml # openclaw.json (Gemma/Qwen + Codex 設定) ├── pvc.yaml # /home/node/.openclaw 永続化（local-path） ├── deployment.yaml # ghcr image + Secret 注入 ├── service.yaml # ClusterIP / LoadBalancer └── ingress.yaml # openclaw.192.168.11.250.sslip.io ``` ### deployment.yaml の要点 ``` apiVersion: apps/v1 kind: Deployment metadata: { name: openclaw, namespace: openclaw } spec: replicas: 1 strategy: type: Recreate # PVC が RWO なので Recreate 必須 template: spec: securityContext: runAsUser: 1000 runAsGroup: 1000 fsGroup: 1000 fsGroupChangePolicy: OnRootMismatch # 起動高速化の必須設定 initContainers: - name: seed-config image: busybox:1.36 # PVC 上に openclaw.json が無いときだけ ConfigMap から seed # → runtime に書き換えた auth profile を保護 containers: - name: openclaw image: ghcr.io/openclaw/openclaw:2026.5.7 ports: [ { name: http, containerPort: 18789 } ] env: - { name: OPENCLAW_SKIP_ONBOARDING, value: "1" } - { name: OPENCLAW_DISABLE_BONJOUR, value: "1" } # ... Secret から各種 API トークンを注入 volumeMounts: - { name: data, mountPath: /home/node/.openclaw } - { name: obsidian-vault, mountPath: /home/node/obsidian-vault } livenessProbe: { httpGet: { path: /healthz, port: http } } readinessProbe: { httpGet: { path: /readyz, port: http } } ``` ** 弊社で踏んだ落とし穴：fsGroupChangePolicy OpenClaw の workspace（skills / canvas / sessions）はファイル数が万単位に膨らみます。`fsGroupChangePolicy` を指定しないと、Pod 起動のたびに **PVC 全体に対して再帰的に chown が走り、起動に数分かかる**事態になりました。`OnRootMismatch` に設定することで、ルートディレクトリのオーナーが正しい限り再帰 chown をスキップでき、起動時間が一気に短縮されます。 ### デプロイスクリプト ``` # scripts/deploy.sh sudo BRIDGE_API_TOKEN= ./scripts/deploy.sh # 内部処理: # 1. namespace 作成 (openclaw) # 2. init-secret.sh で GATEWAY_TOKEN 乱数生成 → Secret 作成 # BRIDGE_API_TOKEN 等の追加トークンがあれば同 Secret に併合 # 3. kubectl apply -k k3s/ # 4. rollout status の完了待ち ``` ### アクセス方法 | 方式 | URL | 備考 | | ポート指定（推奨） | `http://192.168.11.250:18789/` | Service の klipper-lb (svclb) 経由 | | Ingress | `http://openclaw.192.168.11.250.sslip.io/` | Traefik 経由、DNS 解決可能な環境のみ | | port-forward | `http://127.0.0.1:18789/` | 外出先 / VPN 経由のデバッグ時 | ## Secret / ConfigMap / PVC の設計指針 OpenClaw 運用で意外と効くのが **「どの設定をどこに置くか」**のレイヤ設計です。雑にやると **OAuth トークンが pod 再起動で消える**、**Secret 更新がポッドに反映されない**、**誰がトークンを発行したか分からなくなる**といった事故が起きます。 | レイヤ | 置く物 | 更新頻度 | | ConfigMap | openclaw.json テンプレ（gateway / models / agents） | 低（半年〜年単位） | | Secret | GATEWAY_TOKEN / BRIDGE_API_TOKEN / REDMINE_API_KEY / Google SA JSON / SNS トークン群 | 中（数ヶ月） | | PVC | auth-profiles.json（OAuth 状態）/ skills/ / sessions/ / canvas/ | 高（毎日） | ** init-container での seed パターン 弊社では `ConfigMap → PVC` の seed を **init-container で「PVC が空のときだけ」**実行する設計にしました。これにより、Pod が再起動しても PVC 側の runtime 設定（OAuth トークン / カスタムスキル）が ConfigMap で上書きされません。一方、設定を完全に作り直したいときは `kubectl delete pvc openclaw-data` で意図的にリセットできます。 ### 典型的な Secret キー一覧（弊社の例） ``` # openclaw-secrets （Secret） GATEWAY_TOKEN # OpenClaw 自身のゲートウェイ認証 BRIDGE_API_TOKEN # NAS の chatgpt-bridge → gpt-image-2 REDMINE_URL # 社内 Redmine REDMINE_API_KEY # 〃 GSK_API_KEY # Genspark CLI X_API_KEY/X_API_SECRET # SNS自動投稿 (X) IG_ACCESS_TOKEN # Instagram Graph API FB_PAGE_TOKEN # Facebook Page # openclaw-ga4 （別 Secret） service-account.json # GA4 Data API 用 Google サービスアカウント鍵 ``` ※ Secret は `kubectl create secret generic ... --from-literal=KEY=VALUE` で個別投入。鍵管理は `~/.credentials` に集約し **必ず .gitignore**。 ## 初回 OAuth ログインの儀式 Codex Pro のサブスク枠を OpenClaw から使う場合、初回だけ対話 TTY で OAuth ログインが必要です。Pod 内に `kubectl exec -it` で入って実行します。 ``` POD=$(sudo KUBECONFIG=/etc/rancher/k3s/k3s.yaml \ kubectl get pod -n openclaw -l app=openclaw \ -o jsonpath='{.items[0].metadata.name}') sudo KUBECONFIG=/etc/rancher/k3s/k3s.yaml \ kubectl exec -it -n openclaw $POD -c openclaw -- \ openclaw models auth login --provider openai-codex ``` 表示される URL とコードをブラウザで Codex Pro アカウントに承認すると、トークンが PVC 上の `~/.openclaw/agents/main/agent/auth-profiles.json` に保存されます。gateway は設定変更を **hot reload** するので、ログイン直後から Codex モデルが使えるようになります。 ** トークン期限切れに備える Codex Pro の OAuth トークンは数週間〜数ヶ月で `expiresAt` を超えます。期限切れになると Codex 呼び出しは失敗しますが、**fallback の Lemonade ローカル LLM に自動で落ちる**ため即停止はしません。alertmanager で「24h Codex 0 件」みたいな指標を引いて、トークン更新を促すのが運用上の現実解です。 ## テクノスフィアでハマったポイント 7 つ 弊社が OpenClaw を実運用に乗せるまでに踏み抜いたトラップを、再発防止メモを兼ねて公開します。 ### ① fsGroup の再帰 chown で起動 5 分超 workspace のファイル数が膨らむと、`fsGroup` 適用のための再帰 chown が起動毎に走って **Pod が Ready にならない**事態に。`fsGroupChangePolicy: OnRootMismatch` で解決。 ### ② Gemma の reasoning_content で本文が空 thinking モード対応モデル（Gemma 4 など）は `max_tokens` を小さくすると、**推論パートで全部消費されて本文が返らない**挙動になります。最低でも 2048 トークン、要約系で本気を出すなら 4096〜8192 を確保。 ### ③ コンテキスト長は推論サーバ側が支配 OpenClaw 側の `contextWindow` を 200k に書いても、Lemonade の `recipe_options.json` で `ctx_size: 16384` なら実効 16k です。**下位レイヤを揃えないと意味がない**。 ### ④ 同時実行は LLM 1 インスタンスあたり 3〜4 並列が限界 llama.cpp 系は KV キャッシュ非共有のため、同時セッションが増えると VRAM 不足で落ちます。社内利用で「会議中に同時に 5 人が叩く」みたいなピークが見えたら、Lemonade を 2 つに分けるか、サブスク枠の LLM に逃がす設計を入れる。 ### ⑤ Service の type 選択 Pi5 単一ノード k3s の場合、`type: LoadBalancer` でも k3s 同梱の klipper-lb (svclb) が hostPort 公開してくれて、わざわざ NodePort や Ingress を立てなくても LAN からポート直叩きできます。検証時は **LoadBalancer が一番素直**。 ### ⑥ Pod 内には pip も python3-venv も無い OpenClaw 公式イメージは Node ベース。Python 系スキルを足したいときは **既存スキルの venv にある pip を借りる**パターンが正解です（例：`google-calendar` スキルの venv で `pip install --target=...`）。 ### ⑦ 設定の hot reload と PVC seed の競合 初期は ConfigMap を毎回上書きする init-container にしていましたが、運用で書き換えた auth profile が rollout のたびに消える事故が頻発。**PVC に既存ファイルがあれば seed をスキップ**するロジックに変えて解消。 ** 詳しい運用事例は次回以降の記事で 本記事では環境構築までを扱いましたが、実際の業務効果を生むのは **スキル（skills/）**の設計です。続編として、Obsidian 作業ログ自動同期・Redmine チケット運用自動化、画像生成・ブラウザ自動操作のスキル活用事例を順次公開していきます。 - [OpenClaw スキル活用事例①｜作業ログとRedmine運用を完全自動化](https://technosphere.co.jp/blog/openclaw-skills-obsidian-redmine) - [OpenClaw スキル活用事例②｜画像生成・ブラウザ自動操作で広がる業務自動化](https://technosphere.co.jp/blog/openclaw-skills-image-browser) ## まとめ ### この記事のまとめ - OpenClaw は **サーバ常駐型・LLM 差し替え自由・スキル拡張可能**な OSS の AI エージェント基盤 - Claude Code 等の CLI 系とは違い、**Slack / Web / IDE など複数チャネル**から叩ける社内 AI 窓口として刺さる - まずは **Docker Compose でローカル起動**、動作確認後に k3s へ展開する流れがリスク最小 - LLM は **Codex Pro (primary) + ローカル Qwen/Gemma (fallback)** のハイブリッドが SLA とコストの両立に効く - k3s 展開時は **PVC + Secret + ConfigMap** の役割分離と、**init-container での seed パターン** が運用を安定させる - 初回だけ **OAuth ログインを `kubectl exec -it` で行う**儀式が必要 - **fsGroupChangePolicy / contextSize / 同時実行数 / hot reload と seed の競合**など、本記事に書いた 7 つの落とし穴で時間を失わないように テクノスフィアでは社内 AI アシスタント（OpenClaw / Claude Code / Codex / Lemonade）の構築・運用、社内データを安全に扱える RAG / エージェント基盤の設計をご支援しています。「外部 SaaS に出せないデータを AI に使わせたい」「業務システム連携まで含めて AI を社内に住ませたい」といったご相談は、ぜひお気軽にどうぞ。 ／この内容の受託開発・PoC相談はこちら＼ ### 社内 AI 基盤・AI エージェントの受託開発 OpenClaw / Claude Code を含む社内 AI 基盤の選定・構築・運用、業務エージェント設計、MCP サーバー構築まで、テクノスフィアにお任せください。要件ヒアリングから本番運用まで一気通貫で対応します。 [AI開発サービスを見る](https://technosphere.co.jp/ai-solution) [社内AI基盤構築相談](https://technosphere.co.jp/contact) # OpenClaw # AIエージェント # Kubernetes # k3s # Docker # OSS # LLM # Codex # Qwen # 社内DX ## 次に読む｜OpenClaw シリーズ - [OpenClaw シリーズ スキル活用事例①｜Obsidian作業ログ＋Redmineチケット運用の完全自動化 日次の作業記録を AI が勝手に書き続ける運用とは](https://technosphere.co.jp/blog/openclaw-skills-obsidian-redmine) - [OpenClaw シリーズ スキル活用事例②｜画像生成・ブラウザ自動操作で広がるマルチモーダル業務自動化 gpt-image-2 / Browser Use を OpenClaw に統合](https://technosphere.co.jp/blog/openclaw-skills-image-browser) - [関連記事 RAGチャットボットとは？仕組み・メリット・導入方法 OpenClaw のスキル設計と相性のよい RAG の基礎](https://technosphere.co.jp/blog/what-is-rag-chatbot) - [サービス AI ソリューション開発 社内AI基盤・RAG・エージェント基盤の構築支援](https://technosphere.co.jp/ai-solution) ## よくある質問（FAQ） ### Q. OpenClawとは何ですか？無料で使えますか？ OpenClawは、複数のLLMプロバイダを切り替えながら使える**OSSのAIエージェント基盤**です。ソフトウェア自体は無料で利用でき、費用は接続するLLM（クラウドAPIの従量課金、またはローカルLLMなら電気代のみ）と稼働させるサーバ分だけです。 ### Q. Claude CodeやCursorとの違いは何ですか？ Claude CodeやCursorが開発者個人の手元で動くCLI・IDEプラグインであるのに対し、OpenClawは**HTTPサーバとして常時稼働させ、複数のクライアント・チャネルから接続して使う**「社内共有のAIエージェント」という位置づけです。詳しくはOpenClawとは何かをご覧ください。 ### Q. ローカルLLMだけで運用できますか？ 可能です。ただし応答品質とのバランスから、本記事ではクラウドLLM（Codex Pro）をプライマリ、ローカルLLMをフォールバックにするハイブリッド構成を推奨しています。機密性の高い用途では完全ローカル構成も選択できます。 ### Q. 動かすのにどんな環境が必要ですか？ お試しならDocker Composeによるローカル起動が最短です。本記事ではRaspberry Pi 5 + k3sという小規模構成での本番運用例を紹介しており、専用GPUサーバがなくても社内運用を始められます。 [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # OpenClaw スキル活用事例②｜画像生成・ブラウザ自動操作で広がるマルチモーダル業務自動化｜株式会社テクノスフィア > OpenClaw のスキル機構で gpt-image-2 画像生成・Browser Use 2.0 自動操作・Genspark CLI 検索/スライドを統合した実例。OpenAI 互換 API・社内 chatgpt-bridge・k3s 設計を公開。 URL: https://technosphere.co.jp/blog/openclaw-skills-image-browser ** 目次 1. はじめに：テキスト止まりの AI に飽きたら 2. スキルからマルチモーダル API を叩くアーキテクチャ 3. スキル①：image-gen で社内 gpt-image-2 を呼ぶ 4. なぜ chatgpt-bridge を NAS に立てたのか 5. スキル②：browser-use で Chromium を直接操作 6. スキル③：gsk で検索・スライド・動画まで一気通貫 7. スキル横断ワークフロー：実際の業務シナリオ 3 つ 8. セキュリティとネットワーク設計の勘どころ 9. まとめ ** 本記事のスコープ 本記事は [OpenClaw 入門｜環境構築完全ガイド](https://technosphere.co.jp/blog/openclaw-getting-started)、および [スキル活用事例①｜Obsidian＋Redmine 自動化](https://technosphere.co.jp/blog/openclaw-skills-obsidian-redmine) の続編です。OpenClaw 本体と業務自動化スキルが稼働している前提で、画像・ブラウザ・Web 検索などの**マルチモーダルスキル**を統合する実装ノウハウを扱います。 ## はじめに：テキスト止まりの AI に飽きたら OpenClaw を社内に立てて、Redmine・Obsidian と連携させると、文字情報のやり取りは大部分が AI で完結します。次に欲しくなるのは、**「画像も出してほしい」「Web をブラウザ越しに自分で見て報告してほしい」「Google スライドや動画まで作ってほしい」**といったマルチモーダルな業務です。 幸い、いま手に入る AI ツールは API もコマンドも OpenAI 互換のものが多く、**「OpenClaw のスキルから 1 枚の SKILL.md で外部 API を叩く」**パターンに収まります。本記事では、弊社で実装した 3 つの代表スキルとその統合例を公開します。 - **image-gen：**社内 NAS に立てた `chatgpt-bridge` 経由で `gpt-image-2` を呼ぶ画像生成スキル - **browser-use：**Browser Use CLI 2.0 で Chromium をエージェントが直接操作 - **gsk：**Genspark CLI で Web 検索・Gmail・Notion・スライド・動画（Veo / Kling）まで一気通貫 ## スキルからマルチモーダル API を叩くアーキテクチャ マルチモーダル系は外部 API や子プロセスへの依存が増えるため、**「スキルがどこに何を投げているか」**を最初に固めておくのが事故防止になります。弊社の全体図はこんなイメージです。 ``` ┌───────────────────────────────────────────────────────────────┐ │ OpenClaw pod (k3s, Pi5) │ │ │ │ ┌─ skills/image-gen/SKILL.md │ │ │ └─ POST http://192.168.11.241:18080/v1/images/... │ │ │ (NAS の chatgpt-bridge / gpt-image-2) │ │ │ │ │ ├─ skills/browser-use/SKILL.md │ │ │ └─ exec browser-use --task "..." --headless │ │ │ └─ Chromium 子プロセスが Web を操作 │ │ │ │ │ ├─ skills/gsk/SKILL.md │ │ │ └─ exec gsk (Genspark Pro CLI) │ │ │ └─ Veo 3.1 / Kling V3 / Gmail / Notion 等 │ │ │ │ │ └─ skills/tvideo/SKILL.md │ │ └─ POST http://192.168.11.242:8001/v1/videos/... │ │ (EVO-X2 / Wan2.2 / LTX-Video, T2V/I2V/V2V) │ │ │ └───────────────────────────────────────────────────────────────┘ ``` ### 2 つの呼び出しパターン | パターン | 例 | 利点 | 欠点 | | HTTP API | image-gen / tvideo | 言語非依存、ステートレス、複数 pod で共用 | サーバを別途立てる手間 | | CLI 子プロセス | browser-use / gsk | 導入が早い、機能が一気に増える | pod に CLI を入れる必要、認証管理 | 「重い計算が走る・複数人が使う」ものは HTTP API、「個別ツールを使いたいだけ」のものは CLI に寄せる、という方針で運用しています。 ## スキル①：image-gen で社内 gpt-image-2 を呼ぶ OpenClaw に「この記事のアイキャッチ画像を作って」「資料用のヒーロー画像を作って」と頼むだけで、社内サーバ上で `gpt-image-2` が回って PNG が返ってくる──を実現するスキルです。実は本記事の冒頭ヒーロー画像も、このスキルで OpenClaw 経由で生成しています。 ### 接続情報（SKILL.md 抜粋） ``` --- name: image-gen description: 社内NASのChatGPT画像生成API（gpt-image-2）を使用した画像生成。 画像の作成・生成リクエスト全般で使用。社内LANまたはVPN接続時のみ利用可能 --- # 画像生成スキル（gpt-image-2） ## 接続情報 - エンドポイント: http://192.168.11.241:18080/v1/images/generations - 認証: Authorization: Bearer <トークン> - トークン取得: 環境変数 BRIDGE_API_TOKEN - ネットワーク: 社内LAN または VPN接続時のみ到達可能 - 互換性: OpenAI SDK 互換 ``` ### 呼び出しコード（curl 版） ``` TOKEN=$BRIDGE_API_TOKEN curl -X POST http://192.168.11.241:18080/v1/images/generations \ -H "Authorization: Bearer $TOKEN" \ -H 'Content-Type: application/json' \ -d '{ "prompt": "プロンプト内容", "quality": "high", "size": "1536x1024" }' \ | python3 -c "import json,base64,sys; d=json.load(sys.stdin); \ open('output.png','wb').write(base64.b64decode(d['data'][0]['b64_json']))" ``` ### Python SDK 版（OpenAI 互換のうれしさ） ``` from openai import OpenAI import base64, os client = OpenAI( base_url="http://192.168.11.241:18080/v1", api_key=os.environ["BRIDGE_API_TOKEN"], ) result = client.images.generate( model="gpt-image-2", prompt="An illustration of an open-source AI assistant ...", quality="high", size="1536x1024", ) with open("output.png", "wb") as f: f.write(base64.b64decode(result.data[0].b64_json)) ``` ** OpenAI SDK 互換のうれしさ エンドポイントが OpenAI 互換なので、Python・Node・curl のどれでも 5 行で叩けます。社内利用者ごとに「公式 OpenAI を直叩きにしたい」「ローカル LLM 経由にしたい」「NAS の bridge にしたい」を切り替えても、コード側は `base_url` 1 行の差分で済みます。**互換性を最優先にプロキシを設計**しておくと、後の差し替え自由度が圧倒的に上がります。 ## なぜ chatgpt-bridge を NAS に立てたのか 「OpenAI を直接叩けばいいじゃないか」と思われるかもしれません。社内 LAN に `chatgpt-bridge` を立てた理由は次の 4 点です。 1. **トークンの一元管理：**OpenAI API キーを各端末にバラまかず、NAS 上の Bearer トークンだけを発行することで利用者管理を統制 2. **監査ログ：**誰が・いつ・どんなプロンプトで叩いたかを bridge の access log として一元集約 3. **レート制限の制御：**OpenAI 側の rate limit がチーム全体に効くので、bridge 側で**利用者ごとのソフトリミット**を入れて事故防止 4. **切り替え柔軟性：**OpenAI / Azure OpenAI / ローカル LLM のどれにバックエンドを切り替えても、利用者側のコードは無変更で済む ### bridge の最小構成（参考） ``` # docker-compose.yml on NAS services: bridge: image: ghcr.io//chatgpt-bridge:latest container_name: chatgpt-bridge ports: [ "18080:18080" ] environment: BRIDGE_API_TOKEN: ${BRIDGE_API_TOKEN} OPENAI_API_KEY: ${OPENAI_API_KEY} RATE_LIMIT_RPM: 60 restart: unless-stopped ``` ** 機密データのプロンプト対策 機密文書をそのまま外部に送らないように、bridge 側で**「特定パターン（社員番号・電話番号・口座番号など）を含むプロンプトはマスクしてから外部へ送出」**のフィルタを入れています。スキル側に書くと AI が無視する可能性があるので、**プロキシ層で強制**するのが安全です。 ## スキル②：browser-use で Chromium を直接操作 OpenClaw に「このページのフォームを埋めてくれ」「ログイン後ダッシュボードのスクリーンショットを取って」と頼めるようにするのが `browser-use` スキルです。[Browser Use CLI 2.0](https://browser-use.com/) を pod に同梱し、headless Chromium を子プロセスとして起動して LLM がページ要素を操作します。 ### SKILL.md 抜粋 ``` --- name: browser-use description: Browser Use CLI 2.0 を使用したブラウザ自動操作。 Webページ閲覧、フォーム入力、スクリーンショット取得、 データ抽出などのブラウザ操作全般で使用 --- ## 起動方法 - 基本: browser-use --task "<自然言語タスク>" - スクショ: browser-use --task "..." --screenshot-dir ./shots - ヘッドレス: 既定 ON、UI 確認時は --headed - セッション保持: --session-name ``` ### 使い方の典型例 ``` # 例1: 社内 Redmine の自分のチケット一覧をスクショ browser-use --task "https://redmine.technosphere.co.jp/issues?assigned_to_id=me に ログインして、ステータスが完了でないチケットを表形式で抽出してくれ" \ --screenshot-dir /tmp/redmine-shots \ --session-name technosphere # 例2: 公開ページの動作検証 browser-use --task "https://poc-h.technosphere.jp/caremente-partner/ を開いて CTA ボタンが SP 表示でも崩れていないか PC と SP 両方で確認、 スクリーンショットを撮って差分があれば指摘してくれ" ``` ** セッションとログインの扱い ログインが必要なページを操作するときは、**事前に手動で `--headed` で 1 回ログイン → セッション保持**のパターンが安定します。AI に毎回ログインさせると、2FA や CAPTCHA で詰まることが多いです。弊社では Redmine / GitHub / Google など主要サービスは pod 上の Chromium プロファイルに事前ログイン済みです。 ### 失敗パターンと回避策 - **動的 DOM の同期失敗：**SPA のフェッチ完了を待たずに次操作に進んで失敗 → SKILL.md に「画面遷移後 1 秒以上待機」を明記 - **iframe 入れ子：**Google フォーム等で iframe 内部要素を取れない → Browser Use の `--frame` オプションを使うようスキルに明記 - **ファイルダウンロード：**headless でダウンロードがブロックされる → ダウンロードディレクトリを指定して許可 ## スキル③：gsk で検索・スライド・動画まで一気通貫 もう 1 つの強力カードが `gsk` スキルです。[Genspark Pro](https://www.genspark.ai/) の CLI（80＋ tools）を OpenClaw から叩けるようにしてあり、Web 検索・Gmail・Google Workspace・Notion・GitHub・スライド/ドキュメント生成・動画生成（Veo 3.1 / Kling V3）まで一発で扱えます。 ### SKILL.md 抜粋（gsk） ``` --- name: gsk description: Genspark Tool CLI (gsk) を使った Web 検索 / 動画生成 / 画像生成 / メール / Google ワークスペース / 議事録 / Notion / GitHub / スライド・ドキュメント生成等 81+ ツールの統合。 --- ## よく使うサブコマンド | 用途 | コマンド例 | |------------------------|-------------------------------------------| | Web 検索 | gsk websearch "" | | Gmail 送信 | gsk gmail send --to ... --subject ... | | スライド生成 | gsk slides create --title ... --topic ... | | 動画生成（Veo 3.1） | gsk video create --provider veo3 ... | | 議事録 | gsk meeting summary --file recording.mp3 | ``` ### 導入時のひと工夫：PVC に npm-global を置く OpenClaw 公式イメージは `npm i -g` が pod 再起動で消えます。これを回避するため、**PVC 上に `npm-global` ディレクトリを置き、`PATH` 環境変数で先頭に通す**運用にしました。 ``` # deployment.yaml（抜粋） env: - name: PATH value: /home/node/.openclaw/npm-global/bin:/usr/local/sbin:/usr/local/bin:... # 初回セットアップ（pod 内で 1 回だけ） npm config set prefix /home/node/.openclaw/npm-global npm install -g @genspark/cli ``` これで pod を再起動しても `gsk` が PATH に残り、Genspark API トークンも Secret 経由で自動投入されるため、いつでも呼べる状態を維持できます。 ## スキル横断ワークフロー：実際の業務シナリオ 3 つ スキルを個別に呼ぶだけでも価値はありますが、本領は **1 つの指示から複数スキルが連鎖する**ところにあります。弊社で実際に走っている例を 3 つ。 ### シナリオ A：ブログ記事の準備〜デプロイ ``` 👤 「STM32 の DMA 周辺で新しいブログ記事を書きたい。 最新情報を踏まえつつ、ヒーロー画像も作って」 🤖 OpenClaw: 1. gsk websearch "STM32 DMA 2026" で最新情報を集める 2. 既存記事をリポジトリから読み、構成案を作成 3. image-gen でヒーロー画像（1536x1024）を生成 4. PIL で hero.jpg / og.jpg / webp に変換し www/assets/img/blog/ に配置 5. PHP テンプレートを既存記事のフォーマットで作成 6. blog/index.php にカードを追加 7. obsidian-log に「作業N: 技術記事追加」を記録 8. redmine-ticket で「ブログ記事追加」チケットを完了化 ``` 実際にこのシナリオで本記事を含む OpenClaw シリーズ 3 本を 1 セッションで仕上げました。**記事構成・画像生成・PHP 作成・index 更新・記録**まで AI 1 体で完結します。 ### シナリオ B：客先打ち合わせ前の準備 ``` 👤 「ハッピー様との来週の対面打ち合わせの準備を進めたい」 🤖 OpenClaw: 1. redmine-ticket: ハッピー様関連のチケットを期間絞り込みで一覧化 2. obsidian-log: 直近1ヶ月の作業ログから関連項目を抽出 3. gsk websearch でハッピー社の最新ニュースを取得 4. gsk slides create で打ち合わせ用スライドを下書き 5. image-gen で提案ビジュアル 3 種を生成（採用候補） 6. 打ち合わせ準備のタスクを Obsidian の「今日のタスク」に追加 ``` ### シナリオ C：開発・テスト・スクショ・報告 ``` 👤 「caremente-partner の SP 表示で CTA ボタンが崩れてる気がする。 確認して、必要なら修正してプルリク出して」 🤖 OpenClaw: 1. browser-use で PC/SP 両方のスクショを取得 2. スクショを比較、崩れ位置を特定（DOM クラス名まで) 3. SCSS を修正、ビルド 4. browser-use で再確認、修正完了を確認 5. git commit -m "refs #137 CTA ボタン SP表示崩れ修正" → PR 作成 6. redmine-ticket: ステータスを「レビュー依頼中」に 7. obsidian-log に「作業N: CTA ボタン修正」を記録 ``` ** 「複数スキル連鎖」を成立させる条件 3 つ以上のスキルを連鎖させて使いこなすには、**各スキルの description が衝突しないこと、SKILL.md に「他スキルとの組み合わせ例」を明記すること**が効きます。AI は単独スキルの呼び方は得意でも、組み合わせは事例ベースで判断する傾向があるので、SKILL.md に **シナリオを書いておくと採用される確率が上がります**。 ## セキュリティとネットワーク設計の勘どころ マルチモーダルスキルが増えるほど、AI が触れる外部リソースも増えます。弊社で意識している運用ルールをまとめます。 ### ① 「外に出すもの」と「中に閉じるもの」を分離 | 用途 | 外部 SaaS | 社内閉鎖網 | | 画像生成（gpt-image-2） | — | ○ NAS の chatgpt-bridge | | 動画生成（社内 GPU） | — | ○ EVO-X2 (Wan2.2 / LTX) | | Web 検索・ニュース | ○ Genspark | — | | 営業メール文面生成 | ○ Codex Pro | — | | 機密文書要約 | — | ○ ローカル Qwen / Gemma | ### ② 認証トークンは Secret + 環境変数のみ BRIDGE_API_TOKEN・REDMINE_API_KEY・GSK_API_KEY・X/IG/FB の SNS トークンなど、**すべて Kubernetes Secret に集約し、SKILL.md にも Git リポジトリにも実値を書かない**。SKILL.md には「環境変数 `BRIDGE_API_TOKEN` を使う」とだけ書きます。 ### ③ 失敗時の振る舞いを SKILL.md に明記 「API トークンが未設定なら『管理者に依頼してください』と案内」「外部到達できないなら『社内LAN または VPN 接続をお試しください』と案内」のように、**失敗時の応答パターンを SKILL.md に書いておく**と、ユーザーの自力解決率が一気に上がります。エンジニアがいない打ち合わせ中でも対処できる。 ### ④ 監査ログを取る 画像生成・動画生成・ブラウザ操作・SNS 投稿系は**必ず access log を残します**。bridge / browser-use / SNS poster の各サービスで OpenClaw 由来のリクエストにユーザーID とセッション ID を付け、誰がいつ叩いたかを後追いできる状態に。 ** SNS 自動投稿は別 Pod を立てる X / Instagram / Facebook など **「世の中に発信される」操作**は誤発火のリスクが高いため、OpenClaw 本体とは別の `openclaw-sns` pod に隔離して、明示的なスキル呼び出し以外で動かないようにしています。本体 pod のセッション暴走で SNS まで巻き込まれない構成です。 ## まとめ ### この記事のまとめ - OpenClaw のスキルは **HTTP API or CLI 子プロセス**のいずれかで外部マルチモーダル機能と接続できる - `image-gen` スキルで **社内 chatgpt-bridge 経由の gpt-image-2 画像生成**を社内に閉じて運用 - `browser-use` スキルで Chromium を AI が直接操作し、**フォーム入力・スクショ・動作検証**を自動化 - `gsk` スキルで Genspark CLI を取り込み、**Web 検索・スライド・動画・SNS 連携**を一気通貫で扱える - 本記事のヒーロー画像も image-gen スキルで生成済み（実運用そのもの） - スキル横断シナリオ（ブログ記事生成・打ち合わせ準備・テスト＆PR）で **1 発言から十数アクション**が走る - セキュリティは「外と中を分離」「Secret に集約」「失敗時応答を明記」「監査ログ必須」「SNS は別 pod 隔離」の 5 原則で運用 テクノスフィアでは、OpenClaw・Claude Code・Codex などを核に、社内マルチモーダル AI 基盤の構築・スキル設計・社内 API 連携をご支援しています。「画像・動画・ブラウザまで AI に任せて業務を回したい」「社内 LAN に閉じてマルチモーダル AI を運用したい」といったご相談はお気軽にどうぞ。 ／この内容の受託開発・PoC相談はこちら＼ ### 画像 × AI × ブラウザ操作の業務自動化 現場画像の自動分類・図面読み取り・Web 上の繰り返し作業を、マルチモーダル AI × ブラウザ自動操作で半自動化する PoC を構築します。画像検査 AI の現場導入もご相談ください。 [AI開発サービスを見る](https://technosphere.co.jp/ai-solution) [画像認識AIサービスを見る](https://technosphere.co.jp/vision-system) [マルチモーダルAI業務自動化相談](https://technosphere.co.jp/contact) # OpenClaw # スキル # 画像生成 # gpt-image-2 # Browser Use # マルチモーダル # 業務自動化 # AIエージェント ## 次に読む｜OpenClaw シリーズ - [OpenClaw シリーズ OpenClaw 入門｜OSSのAIアシスタントを社内 Kubernetes で動かす環境構築完全ガイド Docker Compose から k3s 本番運用まで](https://technosphere.co.jp/blog/openclaw-getting-started) - [OpenClaw シリーズ スキル活用事例①｜Obsidian作業ログ＋Redmineチケット運用を完全自動化 SKILL.md / AUTO ゾーン / 三位一体ワークフロー](https://technosphere.co.jp/blog/openclaw-skills-obsidian-redmine) - [関連記事 RAGチャットボットとは？仕組み・メリット・導入方法 スキル設計と相性のよい RAG 基礎](https://technosphere.co.jp/blog/what-is-rag-chatbot) - [サービス AI ソリューション開発 マルチモーダル AI 基盤の構築支援](https://technosphere.co.jp/ai-solution) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # OpenClaw スキル活用事例①｜Obsidian作業ログ＋Redmineチケット運用を完全自動化した話｜株式会社テクノスフィア > OpenClaw のスキル機構で作業ログを Obsidian Vault に自動記録し、Redmine チケット運用を AI に任せる方法。SKILL.md・AUTO ゾーン同期・起票・ステータス遷移まで実運用を公開。 URL: https://technosphere.co.jp/blog/openclaw-skills-obsidian-redmine ** 目次 1. はじめに：記録は人がやるべき仕事か？ 2. OpenClaw のスキルとは何か（SKILL.md 構文） 3. スキル①：obsidian-log で作業ログを完全自動化 4. AUTO ゾーンによる「壊さない自動更新」 5. スキル②：redmine-ticket で起票〜完了まで任せる 6. GitHub × Redmine × Obsidian の三位一体 7. 運用 3 ヶ月でわかった効果と落とし穴 8. スキル設計の 5 つの鉄則 9. まとめ ** 本記事のスコープ 本記事は [OpenClaw 入門｜環境構築完全ガイド](https://technosphere.co.jp/blog/openclaw-getting-started) の続編です。OpenClaw 本体の設置・LLM 設定が終わっている前提で、社内業務向けスキル（skills/）の設計と運用ノウハウを扱います。Claude Code の skill 機構ともコンセプトは互換性があり、移植も容易です。 ## はじめに：記録は人がやるべき仕事か？ 受託開発・社内 DX に関わるエンジニアにとって、「**何を、いつ、どこまでやったか**」の記録は避けて通れません。弊社の場合、最低限ここまでが日々の記録対象でした。 - その日の作業を **Obsidian Vault** の `作業ログ/YYYY-MM-DD.md` に書く - 関連する **Redmine チケット**のステータス・コメントを更新する - **コミットメッセージ・PR タイトル** に Redmine 番号（`refs #123`）を含める - 顧客向けの返信メール文面と返信ステータスをチケットに転記する - プロジェクトページの「最終作業」「最新コミット」を最新に保つ 真面目にやろうとすると、1 日あたり **30〜45 分**が記録だけに溶けます。でもこれを怠ると、月末に「あの案件、結局何やったんだっけ」が積み上がる。**記録は重要だが、人がやる仕事として面白くない**──この典型的な業務こそ OpenClaw に任せるべき領域です。 ** 「自動記録」の本当の難しさ 過去にも cron で日次サマリを書かせる、Git hook でチケット番号を抽出する、といった半自動化を試してきました。問題は **「フォーマットがすぐ崩れる」「他人の更新を上書きする」「文脈を補完できない」**の 3 点。OpenClaw のスキル＋ LLM 推論を組み合わせると、この 3 点が一気に解けます。 ## OpenClaw のスキルとは何か（SKILL.md 構文） OpenClaw のスキルは、**1 つのディレクトリ＋ `SKILL.md` 1 枚**で完結します。AI エージェントが LLM 呼び出しの直前に、スキルの説明（description）から「今のリクエストに該当するスキルがあるか」をマッチングし、該当すれば `SKILL.md` 本文をプロンプトに展開します。 ### 最小構成 ``` .openclaw/workspace/skills/ └── obsidian-log/ ├── SKILL.md # 必須：説明＋手順 ├── templates/ # 任意：埋め込みテンプレ │ ├── 作業ログ.md │ └── プロジェクト.md └── scripts/ # 任意：補助スクリプト └── update_dashboard.py ``` ### SKILL.md フォーマット ``` --- name: obsidian-log description: Obsidian Vault への作業ログ自動記録。 セッション開始時の作業ログ確認・プロジェクトページ更新、 作業中のログ記録、トラブルシューティング記録で使用。 --- # Obsidian 自動記録スキル ## Vault パス `~/obsidian-vault` ## セッション開始時 ### 1. 環境判定 `uname -r` の出力で判定し、サフィックス `` を決定: | 判定条件 | env | |---------|-----| | `microsoft` or `WSL` | `wsl` | | Raspberry Pi 検出 | `pi5` | | Darwin | `mac` | | その他 Linux | `linux` | ### 2. 作業ログの確認・作成 ファイル: `~/obsidian-vault/開発/作業ログ/YYYY-MM-DD-.md` ... ``` ** description の書き方が運命を分ける description が雑だと、AI がスキルを呼び出してくれません。**「いつ呼ぶか」「呼ぶと何をしてくれるか」**を 2〜3 文で書き、想定キーワード（"作業ログ", "セッション開始時"）を埋め込むのがコツです。逆に description が雄弁すぎると無関係なリクエストでも呼ばれてしまうので、ピンポイントが正解。 ### YAML フロントマターの実用フィールド | キー | 用途 | | `name` | スキル ID（一意）。スラッシュコマンドからも呼べる | | `description` | マッチング判定の核。10〜30 字程度の自然文＋キーワードを混ぜる | | `tools`（任意） | スキルが使えるツールを絞る。誤発火防止に有効 | | `model`（任意） | スキル単位で primary を上書き（重い解析だけ Codex に逃がす等） | ## スキル①：obsidian-log で作業ログを完全自動化 弊社で最初に整備したのがこの `obsidian-log` です。エンジニアが OpenClaw を開いた瞬間に、その日の作業ログファイルを準備して、作業の節目で勝手に追記する──を実現しています。 ### スキルがやってくれる 4 つのこと 1. **環境判定：**`uname -r` から `wsl / pi5 / mac / linux` を識別し、日次ログのサフィックスを切り替え（複数環境同時編集での Git コンフリクト回避） 2. **日次ログの自動作成：**`~/obsidian-vault/開発/作業ログ/YYYY-MM-DD-.md` がなければテンプレからコピー 3. **プロジェクトセクションの追記：**`### 作業N: [プロジェクト名] - [タイトル]` ブロックを日次ログ末尾に挿入 4. **プロジェクトページの AUTO ゾーン更新：**`~/obsidian-vault/開発/プロジェクト/<プロジェクト名>.md` の最終作業・最新コミット・未コミット件数を最新化 ### プロジェクト名判定（優先順） ``` package.json → name フィールド pyproject.toml → [project].name フィールド .git/config → リポジトリ名 （フォールバック） → カレントディレクトリ名 ``` これにより、Node・Python・素の Git リポジトリのどれでも「いま自分はどのプロジェクトにいるか」を AI が一意に決められます。複数案件を切り替えるエンジニアにこそ効きます。 ### 記録テンプレートを SKILL.md に直書きする ``` ### 作業N: [プロジェクト名] - [タイトル] **時間**: HH:MM **プロジェクト**: [プロジェクト名] **Redmine**: [#123 タイトル](http://192.168.11.241:8080/issues/123) → 対応中 **ブランチ**: `feature/123-xxx` **コミット**: `abc1234` **内容**: - [やったこと] **実行したコマンド**: ```bash [コマンド] ``` **結果**: ✅成功 / ⚠️課題あり / ❌失敗 **学んだこと**: [学び・発見] ``` テンプレを SKILL.md にそのまま埋め込んでおくと、LLM は記録ごとにこの形を再現してくれます。フォーマットがブレないことが、後の **grep 検索性**と **Obsidian Dataview クエリ**の精度を決めます。 ## AUTO ゾーンによる「壊さない自動更新」 記録自動化で最大の事故は **「人が書いたメモを AI が上書きする」**です。これを防ぐために、弊社では **AUTO マーカー方式**を採用しています。 ### マーカーの仕組み ``` # プロジェクト名 ## 概要 （ここは人が書く領域。AI は絶対に触らない） ## 自動同期セクション - 最終作業: 2026-05-21 17:30 - パス: /mnt/data/repos/happy-caremainte-site - ブランチ: main - 最新コミット: 6800ea3d - 未コミット件数: 0 - 6800ea3d feat: パートナーLP ボタン文言変更 (koyama, 5h ago) - 5415bee6 Merge pull request #42 (koyama, 1d ago) ## メモ（自由記述） （ここも人が書く領域） ``` SKILL.md には「**マーカー間のみ更新、マーカー外は絶対に書き換えない**」と明文化し、LLM にも徹底させます。AUTO ゾーンとして実装しているのは以下です。 | マーカー | 更新内容 | | `AUTO:project-status` | 最終作業時刻、パス、ブランチ、最新コミット、未コミット件数 | | `AUTO:tech-stack` | package.json / pyproject.toml / Cargo.toml / go.mod 等から自動検出 | | `AUTO:recent-commits` | `git log -10 --pretty=...` の結果 | | `AUTO:recent-changes` | `git status --short` + `git diff --stat HEAD~1..HEAD` | | `AUTO:readme-excerpt` | README.md 先頭 8 行の抜粋 | | `AUTO:active-projects` | 開発ダッシュボードに最近作業したプロジェクト最大 10 件 | ** マーカー設計のポリシー マーカー名は `AUTO:` と `/AUTO:` の対で運用。**マーカー自体を消さない**こともスキルに明記しています。一度マーカーが消えると次回更新時に書き場所を見失い、AUTO ゾーンが二重に生成されたり、人の記述領域に AI が書き込んだりする事故が起きます。 ## スキル②：redmine-ticket で起票〜完了まで任せる 弊社の社内ルールはシンプルです：**「すべてのコミット・PR には Redmine チケット番号を含める」**。逆に言うと、チケットがなければ作業を始めない。これを徹底するために、`redmine-ticket` スキルで以下を AI に任せています。 ### スキルがやってくれる 5 つのこと 1. **新規起票：**「○○の修正を始めたい」と言うと、プロジェクト判定 → トラッカー（バグ/実装/サポート等）選定 → 期日設定の確認 → 起票 2. **ステータス遷移：**「対応中にして」「レビュー依頼中に」「完了に」を自然言語で受け取って Redmine API 経由で更新 3. **関連コメント追記：**コミットメッセージ / PR タイトル / 顧客とのやり取りを抜粋してチケットコメントに転記 4. **担当者変更：**「清水さんにアサインして」をユーザー ID 解決して `assigned_to_id` に反映 5. **進捗率の自動更新：**ステータス完了化と同時に `done_ratio: 100%` を入れる ### SKILL.md に書く Redmine 接続情報 ``` --- name: redmine-ticket description: Redmineチケットの作成・更新・ステータス変更時の運用ルール適用。 期日設定、担当者変更、作業時間記録、チケット移管など、 Redmine操作全般で使用。 --- ## Redmine 接続 - URL: https://redmine.technosphere.co.jp/ - API key: 環境変数 `REDMINE_API_KEY` ## ユーザー | ID | ログイン | 名前 | |----|---------|------| | 5 | koyama | 小山 訓弘 | | 6 | m_shimizu | 清水 誠 | | 7 | j_higashijima | 東嶋 潤一 | | 8 | c_yara | 屋良 朝星 | ## トラッカー | ID | 名前 | |----|------| | 1 | バグ | | 2 | 実装 | | 3 | サポート | ## ステータス遷移（開発・保守） 新規(1) → 対応依頼(13) → 対応中(2) → レビュー依頼中(11) → 保留(12) → 完了(5) / 却下(6) ``` ### API 呼び出しは Python ＋ python-redmine ``` from redminelib import Redmine redmine = Redmine('https://redmine.technosphere.co.jp/', key=os.environ['REDMINE_API_KEY']) # 起票 issue = redmine.issue.create( project_id='happy-caremainte-site', tracker_id=2, status_id=1, subject='パートナーLP ボタン文言変更（260521 ハッピー橋本様 ご依頼分）', description='5/21 朝、橋本様より以下の修正依頼を受領 ...', assigned_to_id=5, ) # レビュー依頼中へ遷移 redmine.issue.update(issue.id, status_id=11, notes='PR #43 を出しました。確認をお願いします。') # 完了化 redmine.issue.update(issue.id, status_id=5, done_ratio=100, notes='橋本様確認OK → PR #43 マージ済み') ``` ** 「自然言語 → ID」のテーブルが命 Redmine API は ID ベースなので、AI が「対応中にして」と言われたときに **「対応中＝status_id=2」**と即座に変換できる必要があります。SKILL.md に **ユーザー名・トラッカー・ステータスの ID テーブル**を明示しておくのが運用安定のコツです。LLM の暗記に頼らせない。 ## GitHub × Redmine × Obsidian の三位一体 obsidian-log と redmine-ticket は単独でも価値がありますが、**GitHub と組み合わせると 1 回の指示で全部が回る**のが本領です。実際のセッションを再現するとこんな流れになります。 ``` 👤 ユーザー: 「ハッピー様から橋本さん経由でパートナーLPの修正依頼が来た。 既存チケット #136 の続きで対応して」 🤖 OpenClaw: 1. redmine-ticket: チケット #136 を取得 → ステータスを「対応中」に 2. 既存リポジトリで feature/136-partner-lp-260520 ブランチを作成 3. 修正10件をエディタで実装（HALサンプル / CSS / コピー差し替え） 4. git commit -m "refs #136 パートナーLP 修正案反映" 5. gh pr create → PR #42 起票（タイトルに refs #136） 6. redmine-ticket: ステータスを「レビュー依頼中」に変更、 コメントに PR URL と修正項目を転記 7. obsidian-log: 今日の作業ログに 「作業N: ハッピー - パートナーLP 修正案反映（#136）」を追記 8. プロジェクトページの AUTO:project-status を更新 9. 「修正10件を反映、PR #42 を出しました」と返事 ``` ユーザーの 1 発言から最大 9 アクションが連鎖します。これを人が手でやると 30 分仕事ですが、AI に任せると **3〜5 分**で全部終わります。しかも記録漏れがゼロ。 ** なぜ「`refs #123`」を必須化するのか 弊社の Redmine は GitHub と双方向連携しています。**コミットメッセージや PR タイトルに `refs #123` が入っていると Redmine 側にも自動で記録される**仕組みです。AI が起票→ブランチ→コミット→PR→記録までを一気通貫で扱えるのは、この命名規約が骨格になっているからです。 ## 運用 3 ヶ月でわかった効果と落とし穴 ### 定量効果 | 指標 | 導入前 | 導入後 | 削減 | | 日次作業ログ記録時間（1人） | 30〜45 分 | 5〜10 分（最終確認のみ） | 約 70% | | Redmine 起票漏れ率 | 週 2〜3 件発生 | 月 0〜1 件 | 約 90% | | 「あの案件、何やったか思い出せない」率 | 月数件 | ほぼゼロ | — | | プロジェクトページの鮮度 | 1〜2 週遅れ | 当日中 | — | ※ 弊社社内 4 名のエンジニアの主観評価ベース。導入は 2026-02 頃から段階的に進行、3 ヶ月時点の数値。 ### 定性効果 - **引き継ぎが圧倒的に楽になった：**プロジェクトページの AUTO ゾーンを見るだけで現状把握できる - **客先報告に厚みが出た：**作業ログを Obsidian Dataview で集約して、月次報告書を半自動生成 - **朝のブリーフィングが定着：**セッション開始時に AI が「今日の作業ログを作成しました」「アクティブなチケットは 5 件です」と切り出してくれる ### 3 つの落とし穴 1. **「過剰起票」問題：**初期は些細な相談でもチケットが立ってしまう事案が頻発。SKILL.md に「**10 分以内で終わる相談はチケット化しない**」を明示してから安定 2. **「ステータス迷子」問題：**レビュー依頼中のまま放置されるチケットが増加。週次で `status_id=11 のまま 7 日以上`を一覧化する別スキル（`redmine-stale-check`）を追加で解決 3. **「Obsidian Vault の Git コンフリクト」問題：**複数環境（Pi5・WSL・Mac）で同じ日付ファイルを同時編集してコンフリクト発生。ファイル名に `-` サフィックスを付ける運用に変更して根絶 ## スキル設計の 5 つの鉄則 3 ヶ月の運用で見えてきた、業務自動化スキルを設計するうえでの鉄則を共有します。 ### ① 1 スキル = 1 業務単位 「Obsidian と Redmine を一緒に扱うスキル」のような**大くくり**を作ると、AI が呼び出しを迷います。1 スキルは 1 ドメインに絞り、組み合わせは AI の判断に任せる。 ### ② description にトリガー語を 3 つ以上 「いつ呼ぶか」のキーワードを 3 つ以上散りばめると、AI が高い再現率で発火します。例：「作業ログ」「Obsidian」「セッション開始時」。 ### ③ ID テーブルは SKILL.md に直書き Redmine のユーザー ID やステータス ID は、外部 DB ではなく **SKILL.md にハードコード**するのが運用安定します。LLM の暗記に頼らず、推論時点で確実に参照させる。 ### ④ 「やらないこと」を明記 SKILL.md には **「マーカー外を書き換えない」「Vault 内で git push しない」「10 分以下の作業はチケット化しない」**といった**禁止事項**を必ず入れます。AI は「やれること」より「やってはいけないこと」を明記された方が安全に動きます。 ### ⑤ テンプレを内包する 記録フォーマットや起票時の項目テンプレは **SKILL.md 本文に丸ごと貼る**のが正解。外部ファイル参照にすると、AI が省略・変形してしまうことがあります。 ** 次のステップ obsidian-log と redmine-ticket で「文字情報の自動化」は完成しました。次は**画像・動画・ブラウザなどマルチモーダルなスキル統合**です。[OpenClaw スキル活用事例②｜画像生成・ブラウザ自動操作で広がるマルチモーダル業務自動化](https://technosphere.co.jp/blog/openclaw-skills-image-browser) で扱います。 ## まとめ ### この記事のまとめ - OpenClaw のスキルは **SKILL.md 1 枚で完結**。description で発火条件を表現する - `obsidian-log` スキルで **環境判定・日次ログ作成・プロジェクトページ AUTO ゾーン同期**まで自動化 - マーカー付きの **AUTO ゾーン方式**で「人の記述を AI が壊さない」を担保 - `redmine-ticket` スキルで **起票・ステータス遷移・コメント転記・進捗率反映**まで自然言語経由で実行可能に - GitHub × Redmine × Obsidian の連鎖により、**1 発言から最大 9 アクションが回る**業務体験を実現 - 導入 3 ヶ月で **日次記録時間 70% 削減・起票漏れ 90% 削減** - 設計の鉄則：1 スキル 1 業務単位、トリガー語 3 つ以上、ID テーブルは直書き、禁止事項を明記、テンプレは内包 テクノスフィアでは、OpenClaw / Claude Code 等の AI エージェント基盤を社内業務に組み込み、Redmine・Obsidian・GitHub・社内ファイルサーバとつなぐ **業務自動化スキル**の設計・実装支援を行っています。「うちの業務記録もこれくらい楽にしたい」「Redmine 起票を AI に任せたい」といったご相談はお気軽にどうぞ。 ／この内容の受託開発・PoC相談はこちら＼ ### 既存業務システムの AI 化・ナレッジ自動連携 議事録・チケット・ナレッジを横断する社内 AI ワークフロー、Obsidian / Redmine / Notion / Slack を AI で連携する受託開発はテクノスフィアにご相談ください。スモール PoC から全社展開まで。 [AI開発サービスを見る](https://technosphere.co.jp/ai-solution) [業務システムAI化相談](https://technosphere.co.jp/contact) # OpenClaw # スキル # Obsidian # Redmine # 業務自動化 # AIエージェント # 社内DX # ナレッジ管理 ## 次に読む｜OpenClaw シリーズ - [OpenClaw シリーズ OpenClaw 入門｜OSSのAIアシスタントを社内 Kubernetes で動かす環境構築完全ガイド Docker Compose から k3s 本番運用まで](https://technosphere.co.jp/blog/openclaw-getting-started) - [OpenClaw シリーズ スキル活用事例②｜画像生成・ブラウザ自動操作で広がるマルチモーダル業務自動化 gpt-image-2 / Browser Use を OpenClaw に統合](https://technosphere.co.jp/blog/openclaw-skills-image-browser) - [関連記事 RAGチャットボット社内ヘルプデスク導入事例 社内 DX × AI の代表例](https://technosphere.co.jp/blog/what-is-rag-chatbot) - [サービス AI ソリューション開発 業務自動化スキル設計のご支援](https://technosphere.co.jp/ai-solution) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # PC-88エミュレータをブラウザで動かす｜WebAssembly移植と著作権の整理｜テクノスフィア > レトロPC「PC-8801」のエミュレータQUASI88をEmscriptenでWebAssemblyに移植し、自社サイトで公開するまでの技術と法務の全記録。エミュレータ公開の著作権整理（本体はOK・ROMはNG）、ROMをサーバーに送らないローカル読込設計、MAMEライセンス由来コードの除外判断、ASYNCIFYとIndexedDB永続化まで実例で解説。実際に動くデモ付き。 URL: https://technosphere.co.jp/blog/pc88-emulator-wasm ** 目次 1. デモ公開中：ブラウザで動くPC-88 2. PC-8801という「日本のパソコン史」 3. 最重要：エミュレータ公開の著作権整理 4. 「ROMを配らずに動かす」アーキテクチャ 5. EmscriptenでC言語エミュレータをWASM化する 6. サウンドを捨てた話：ライセンスでコードを削る判断 7. よくある質問（FAQ） 8. まとめ：レガシー資産はブラウザで延命できる ## デモ公開中：ブラウザで動くPC-88 まず成果物からご覧ください。NEC PC-8801のエミュレータ「**QUASI88**」をWebAssemblyに移植し、当サイトで公開しました。インストール不要、ブラウザだけで動きます。 [▶ PC-88エミュレータを起動する](https://technosphere.co.jp/labs/pc88/) ROMなしでも内蔵メニューの動作を確認できます（PC推奨） ただし、このデモには重要な特徴があります。**ROMファイルを一切同梱していない**ことです。実機をお持ちの方がご自身で吸い出したROMを読み込んだときだけ、N88-BASICが起動します。なぜそうしたのか——本記事の半分は、その「著作権の整理」の話です。エミュレータ公開を検討している方の参考になれば幸いです。 ## PC-8801という「日本のパソコン史」 PC-8801は1981年にNECが発売した8bitパソコンです。CPUはZ80互換（4MHz）、メモリ64KB。BASICインタプリタ（N88-BASIC）をROMで内蔵し、電源を入れれば即プログラミングが始められました。『ザナドゥ』『イース』『ソーサリアン』など日本のPCゲーム黎明期の名作を生んだ、80年代の国民機です。 当社にはZ80や8051のアセンブラ資産を扱う[レガシーマイグレーション業務](https://technosphere.co.jp/blog/8051-z80-legacy-migration-guide)があり、Z80はいまだに「現役の技術」です。40年前のアーキテクチャがエミュレータという形で完全に再現でき、それが最新のブラウザ技術（WebAssembly）で動く——このつながり自体が、組込み技術者にとって最高の教材だと考えて本デモを作りました。 ## 最重要：エミュレータ公開の著作権整理 「エミュレータ＝グレー」という印象を持つ方は多いですが、実際には**何を配布するかで白黒がはっきり分かれます**。整理すると次の3層です。 ``` 【1】エミュレータ本体 → ○ 合法（独自実装のソフトウェア） 【2】ROM（BASIC/フォント） → × 配布不可（NEC等の著作物） 【3】市販ソフトのイメージ → × 配布不可（各社の著作物） ``` - **【1】エミュレータ本体は合法です。**ハードウェアの挙動をソフトウェアで互換実装すること自体は著作権侵害になりません。QUASI88は修正BSDライセンスで公開されており、著作権表示等の条件を守れば商用サイトでの公開・改変も可能です。 - **【2】ROMは配布できません。**N88-BASIC ROMやフォントROMはNEC（BASIC部分はMicrosoftも関係）の著作物で、フリー化されていません。サイトに置けば複製権・公衆送信権の侵害です。MSXにおけるC-BIOSのようなフリー互換ROMも、PC-88には存在しません。 - **【3】市販ゲームのディスクイメージも当然配布できません。**入手先を紹介する行為も侵害を助長するためNGです（正規配信のProject EGG等を紹介するのは問題ありません）。 一方で、**実機の所有者が自分でROMを吸い出して自分で使う**のは私的使用のための複製（著作権法30条）の範囲です。つまり「エミュレータはこちらで用意する。ROMは持っている人が自分の分だけ持ち込む」という分担にすれば、サイト側も利用者側も適法な範囲に収まります。これが本デモの基本設計です。 ## 「ROMを配らずに動かす」アーキテクチャ 設計の要点はひとつ。**ROMファイルがネットワークを一切通らない**ことです。 ``` // ROM選択：File API でブラウザ内メモリに読むだけ romInput.onchange = async function (e) { const file = e.target.files[0]; const data = new Uint8Array(await file.arrayBuffer()); // Emscripten の仮想FS（IndexedDBで永続化）に書くだけ。 // fetch/XHR は呼ばない ＝ サーバーには何も送られない Module.FS.writeFile('/quasi88/ROM/N88.ROM', data); }; ``` 選択されたROMはEmscriptenの仮想ファイルシステム（MEMFS）に書き込まれ、IndexedDB（IDBFS）へ永続化されます。次回訪問時はブラウザ内のIndexedDBから復元されるため再選択も不要。**当社のサーバーはROMの存在すら知りません**。エミュレータ本体のwasmとJSを静的配信しているだけです（当サイトはS3+CloudFrontの静的構成。[3Dゲームを公開した時](https://technosphere.co.jp/blog/threejs-mobile-3d-game)と同じインフラです）。 またROMなしの訪問者にも「動いていること」を見せるため、**ROMなし起動モード**を用意しました。QUASI88は起動時にROMが見つからなくても停止せず、内蔵メニュー（設定UI）は独自フォントで完全に描画されます。エミュレーションループ・画面描画・入力処理が動いていることは、ROMがなくても確認できるわけです。 ## EmscriptenでC言語エミュレータをWASM化する ベースにしたのは、QUASI88作者の福永省三氏のコードと、Toyoshima氏によるWASM移植版**quasi88nc**（ともにBSDライセンス）です。当社ではサウンド部の除外（後述）とUIの再構成を行い、Dockerのemsdkコンテナでビルドしました。ポイントは3つあります。 ### 1. SDLレイヤーはEmscriptenがそのまま吸収する QUASI88の画面・入力はSDLで書かれています。Emscriptenは`-s USE_SDL=2`を指定するだけでSDL2互換レイヤーを提供し、SDLの描画がそのままHTMLの``に出ます。移植作業の大半を占めるはずの「画面と入力」がほぼゼロコストになります。 ### 2. 無限ループは ASYNCIFY で解決する エミュレータは「1命令実行→画面更新→待つ」を無限に繰り返すプログラムです。しかしブラウザのJavaScriptは無限ループを書いた瞬間にタブが固まります。Emscriptenの**ASYNCIFY**は、C側の`emscripten_sleep()`呼び出しでWASMの実行状態を保存してブラウザに制御を返し、次のフレームで続きから再開する仕組みです。既存のCコードのメインループをほぼ書き換えずに移植できます。 ``` # ビルド設定（Makefileより抜粋） emcc -s USE_SDL=2 \ -s ASYNCIFY -s ASYNCIFY_STACK_SIZE=131072 \ -s ALLOW_MEMORY_GROWTH=1 \ -s FORCE_FILESYSTEM=1 -lidbfs.js \ -O2 *.o -o quasi88.js ``` ### 3. ファイルI/OはIDBFSで「そのまま」動かす C言語の`fopen/fread`はEmscriptenの仮想FSに透過的にマッピングされます。`/quasi88`をIndexedDBバックエンドのIDBFSでマウントしておけば、エミュレータの設定ファイルもROMもディスクイメージも、Cコード側は普通のファイル操作のままブラウザ内に永続化されます。**40年前のパソコンのFDドライブが、IndexedDBの上で回っている**——なかなか痺れる構図です。 ビルド成果物はwasm約1.7MB＋JS約190KB。Z80 CPU、メモリバンク、FDC（フロッピーコントローラ）、CRTC、キーボードまで含めた完全なPC-88がこのサイズです。 ## サウンドを捨てた話：ライセンスでコードを削る判断 実は本デモ、**あえて無音**です。これも著作権（ライセンス）判断の実例なので紹介します。 QUASI88本体は修正BSDですが、サウンド出力部だけは事情が異なります。FM音源の再現に**MAME 0.71由来のコード**（旧MAMEライセンス：商用利用に厳しい制約）と**fmgen**（cisc氏作：商用ソフトへの組込は事前合意が必要）を使用しているのです。企業サイトでの公開は営利文脈と解釈される余地があるため、グレーを残すよりも**サウンドドライバごとビルドから除外**する判断をしました。 ``` # USE_SOUND を外し、MAME/fmgen 由来のオブジェクトを除外 DEFS = -DQUASI88_SDL -DPI=M_PI ... # -DUSE_SOUND -DUSE_FMGEN を削除 OBJS = $(PLATFORM_OBJS) $(CORE_OBJS) # SND_OBJS/FMGEN_OBJS を削除 ``` QUASI88は設計が丁寧で、`USE_SOUND`未定義時のスタブが最初から用意されており、パッチはわずか数行で済みました。OSSを製品や公開物に組み込むとき、「**リポジトリ全体のライセンス表記だけでなく、サードパーティ由来のディレクトリを個別に確認する**」——これは業務のOSS利用監査でもそのまま使う手順です。結果として本デモの配布物はBSD系＋MIT（Emscripten）＋zlib（SDL2）のみで構成され、[ライセンス表記](https://technosphere.co.jp/labs/pc88/LICENSES.txt)も1ファイルで明快になりました。 ## よくある質問（FAQ） ### Q. エミュレータを自社サイトで公開するのは著作権的に問題ないのですか？ エミュレータ本体は独自実装のソフトウェアであり合法です。BSD等のOSSライセンスの条件（著作権表示など）を守れば商用サイトでも公開できます。ROMや市販ソフトの配布は侵害になります。詳細は著作権整理の章をご覧ください。 ### Q. ROMなしでも動くのですか？ 起動はしますが画面は黒いままで、[デモページ](https://technosphere.co.jp/labs/pc88/)では内蔵メニューの動作確認ができます。N88-BASICの表示にはROMが必要です。実機所有者による私的複製ROMの持ち込みのみを想定しています。 ### Q. 選択したROMはサーバーに送られませんか？ 送られません。File APIでブラウザ内に読み、IndexedDBに保存するだけです。アーキテクチャの章のとおり、通信は発生しない設計です。 ### Q. C言語の既存資産は何でもブラウザに移植できますか？ かなりの範囲で可能です。SDL・ファイルI/O・無限ループといった「移植の壁」はEmscriptenの標準機能でほぼ解決します。注意すべきはむしろライセンスの混在と、スレッド・ネットワーク依存部分の設計です。 ## まとめ：レガシー資産はブラウザで延命できる ### この記事のまとめ - エミュレータ本体の公開は合法。ROM・市販ソフトの配布は違法——「何を配るか」で明確に線が引ける - ROMは「実機所有者がブラウザ内でローカル読込」方式ならサイト側・利用者側とも適法な範囲に収まる - EmscriptenならSDL・無限ループ・ファイルI/OというC移植の三大障壁がほぼ標準機能で解決する - OSS利用はディレクトリ単位でライセンスを監査する。グレーな部分は「機能ごと削る」のも実務的な選択肢 - Z80のエミュレーションが今のブラウザで完全動作する——レガシー技術と最新技術は地続きである 「古いC言語資産をWebで動かしたい」「Windowsでしか動かない業務ツールをブラウザ化したい」「Z80/8051時代の資産を延命したい」——本記事の技術はそのままこうした案件に応用できます。テクノスフィアは[レガシーマイグレーション](https://technosphere.co.jp/blog/8051-z80-legacy-migration-guide)から[最新のブラウザ技術](https://technosphere.co.jp/blog/threejs-mobile-3d-game)まで一気通貫で対応します。 [▶ PC-88エミュレータのデモを見る](https://technosphere.co.jp/labs/pc88/) ｜ [組込・レガシー移行サービス](https://technosphere.co.jp/embedded) ｜ [開発の相談をする](https://technosphere.co.jp/contact) Z80/8051のレガシー資産移行は[8051・Z80レガシーマイグレーションガイド](https://technosphere.co.jp/blog/8051-z80-legacy-migration-guide)、ブラウザだけで動くアプリの実例は[Three.jsスマホ3Dゲーム実装ガイド](https://technosphere.co.jp/blog/threejs-mobile-3d-game)で解説しています。 [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # リバースプロキシ型Webレビューツールを自社開発した話｜コード埋め込みゼロで画面に修正指示ピンを立てる仕組み【PinRemark】｜株式会社テクノスフィア > Web制作の「修正指示」をスクショ赤入れとメール往復から解放するため、リバースプロキシ型の画面レビューツールPinRemarkを自社開発しました。ターゲットサイトに一切コードを入れずにウィジェットを注入する仕組み、URL書き換え・Shadow DOM隔離・ピン位置の二重保存・WebSocketリアルタイム同期の実装を、ハマりどころ含めて解説します。 URL: https://technosphere.co.jp/blog/pinremark-reverse-proxy-review-tool ** 目次 1. はじめに：Web制作の「修正指示」はなぜ伝わらないのか 2. タグ埋め込み型ではなく、リバースプロキシ型にした理由 3. 全体アーキテクチャ：依存パッケージは3つだけ 4. 実装①：プロキシのURL書き換え——本丸はここ 5. 実装②：ウィジェット注入とShadow DOMによる完全隔離 6. 実装③：ピンの位置をどう保存するか——セレクタ＋相対%の二重化 7. 実装④：WebSocketリアルタイム同期とSQLite永続化 8. ハマりどころと既知の制約 9. 運用してみて：修正やり取りはどう変わったか 10. よくある質問（FAQ） 11. まとめ 12. 参考文献・出典 ** 本記事のスコープ 本記事は、弊社が2026年7月に開発し社内および実案件のレビューフローで運用している画面レビューツール**「PinRemark（ピンリマーク）」**の設計・実装の記録です。掲載しているコードは実際の実装からの抜粋（一部簡略化）です。特定のSaaSやライブラリの優劣を論じるものではなく、「リバースプロキシでレビューウィジェットを注入する」というアプローチの技術的な勘所を共有することを目的としています。 ## はじめに：Web制作の「修正指示」はなぜ伝わらないのか Webサイトの制作では、公開前に必ず「お客様に画面を確認してもらい、修正点を集める」工程があります。ここで交わされるやり取りは、多くの現場でいまだにこうです。 - スクリーンショットを撮り、ペイントソフトで赤丸を付けてメールに添付 - Excelに「トップページ 中段あたり 画像差し替え」と書いた指示書 - 「スマホで見ると崩れてる箇所がある」という電話（どの機種のどの画面かは不明） この方式の問題は、手間そのものより**「位置情報の欠落」**にあります。「中段あたり」はPCとスマホで違う場所を指し、スクリーンショットは撮った瞬間の画面幅でしか正しくない。結果、制作側は「どこの話か」を推測で補い、推測が外れると手戻りになります。往復のたびにメールの添付ファイルが増え、どの指示が対応済みかも分からなくなっていきます。 「実際の画面の、その場所を、クリックして指せればいいのに」——これを実現するのが画面レビューツール（ビジュアルフィードバックツール）と呼ばれるジャンルで、海外製を中心に多くのSaaSがあります。ただ、既存サービスの多くは**ターゲットサイトへのタグ（スクリプト）埋め込み**を前提としています。ここが今回、自社開発に踏み切ったポイントでした。 ## タグ埋め込み型ではなく、リバースプロキシ型にした理由 レビューウィジェットをページに出す方法は、大きく3つあります。 | 方式 | 仕組み | 課題 | | **タグ埋め込み型** | ターゲットサイトのHTMLに``; html = html.replace(/<\/body>/i, `${inject}`); ``` ここで重要なのが**スタイルとロジックの隔離**です。注入先は「どんなCSSが当たっているか分からない他人のページ」。素朴に`div`を追加すると、ターゲットサイトのリセットCSSやTailwindのユーティリティに巻き込まれてウィジェットの見た目が崩れ、逆にウィジェットのCSSがターゲットサイトのデザインを壊す事故も起きます。 PinRemarkでは、ツールバー・ピン・コメントモーダルといったUIをすべて**Shadow DOM**（`attachShadow({mode: 'open'})`）の内側でレンダリングしています[1]。Shadow DOM内のスタイルは外に漏れず、外のスタイルも（継承プロパティ以外は）中に入ってきません。「レビューUIがBootstrapのボタンに化ける」「ターゲットのz-index戦争に巻き込まれる」類いの問題を、仕組みごと封じられます。 ** CSP除去とのトレードオフ 注入したスクリプトを確実に動かすため、プロキシは`Content-Security-Policy`ヘッダを除去しています。これはターゲットサイトのセキュリティポリシーを緩める行為なので、**レビュー用途の限定的なURLでのみ許される割り切り**です。PinRemarkのレビューURLは納品前・テスト公開中のサイト確認を想定しており、不特定多数に公開する使い方は想定していません。 ## 実装③：ピンの位置をどう保存するか——セレクタ＋相対%の二重化 「画面のこの場所」を保存する方法として、最初に思いつくのはクリック座標（px）の記録です。しかしこれは**画面幅が変わった瞬間に破綻**します。お客様が1920pxのモニタで立てたピンを、制作者が1440pxのノートPCで見ると、まったく別の要素の上に表示されてしまう。 PinRemarkはピンの位置を**2重の形式**で保存し、復元時に優先順位をつけて解決します。 | 優先度 | 形式 | 内容 | | 第一優先 | CSSセレクタ＋要素内相対位置（%） | クリックされた要素を`id`起点または`tag:nth-of-type`のパスで特定し、その要素の中の相対位置（x%, y%）を記録 | | フォールバック | ページ絶対座標（px） | DOM変更などでセレクタが解決できなくなった場合に使用 | セレクタ＋相対%方式なら、「3枚目のカードの右上」に立てたピンは、画面幅が変わってカードの位置が動いても「3枚目のカードの右上」に追従します。加えて、投稿時のビューポートサイズとUser-Agentもメタデータとして保存しているため、「スマホ実機で見たときの指摘」であることが制作側に伝わります。 ピンは2種類あり、クリックで**点ピン**、ドラッグで**範囲指定（矩形）**を設置できます。「この段落全体の行間を詰めたい」のような面の指摘は矩形のほうが正確に伝わるためです。矩形も中心直下の要素を基準に同じ二重形式で保存します。 ## 実装④：WebSocketリアルタイム同期とSQLite永続化 レビューは「お客様が画面を見ながら、制作者が電話やWeb会議で話す」状況で使われることが多く、ピンを立てた瞬間に相手の画面にも出ることが体験の質を大きく左右します。PinRemarkは`ws`によるWebSocketで、ピン・コメントの作成／更新イベントを同一プロジェクトの全閲覧者と管理画面へ即時配信します。管理画面は`project=*`で接続し、全プロジェクトの動きを購読します。 永続化はSQLite（better-sqlite3／WALモード）です。テーブルは3つだけ。 ``` projects(id, key UNIQUE, name, target_url, created_at) pins(id, project_id, number, page_path, selector, x_percent, y_percent, page_x, page_y, kind[point|rect], w_percent, h_percent, status[open|resolved], created_by, viewport_w, viewport_h, user_agent, created_at, updated_at) comments(id, pin_id, author, body, created_at) ``` この規模のツールにPostgreSQLを立てるのは運用負担のほうが大きい、というのが判断です。better-sqlite3は同期APIでトランザクションが素直に書け、WALモードなら読み取りと書き込みの並行にも十分耐えます[2]。バックアップは`data/`ディレクトリのファイルコピーで済みます。 ## ハマりどころと既知の制約 ### 1. Cookieの書き換えは「動くまで」が長い 認証付きのステージングサイトを中継する場合、ターゲットが発行する`Set-Cookie`をそのまま返すと、Domain不一致やPath不一致でブラウザがCookieを保存しません。`Domain`属性を除去し、`Path`をプロキシ配下（`/p/`）に付け替え、http運用のため`Secure`属性も除去する——という書き換えでログインセッションが維持できるようになります。裏を返せば、**Secureを外している以上、機密性の高い本番サイトの中継には使うべきではありません**。これは設計上の割り切りとしてREADMEにも明記しています。 ### 2. RefererヘッダとOriginヘッダの付け替え ターゲットサイト側がRefererやOriginを見てCSRF対策をしている場合、プロキシのホスト名のままだと拒否されます。転送時にRefererのプロキシ部分をターゲットのオリジンへ付け替えることで、フォーム送信も通るようにしています。 ### 3. 中継できないもの：ターゲット自身のWebSocket 現状の実装はHTTP(S)の中継のみで、ターゲットサイト自身がWebSocketを使う場合（チャットUIなど）その通信は中継されません。また、Refererが付かないリクエスト（`rel="noreferrer"`や一部のプリフェッチ）は前述のフォールバックでも救済できません。ここは「レビューという用途では実害が出にくい」と判断して割り切っています。 ### 4. 圧縮の二重処理 Node.jsの`fetch`（undici）は`Accept-Encoding`を自動でネゴシエーションし、レスポンスを展開済みで返します。にもかかわらず上流の`Content-Encoding: gzip`ヘッダをそのままクライアントへ返すと、ブラウザは「gzipのはずなのに展開できない」と表示に失敗します。`content-encoding`・`content-length`・`transfer-encoding`を転送対象から外すのを忘れないことです。 ## 運用してみて：修正やり取りはどう変わったか PinRemarkは現在、弊社のWeb制作案件のレビューフローで実際に使っています。お客様には「レビュー用URL」を1本お渡しするだけ。アプリのインストールもアカウント登録も不要で、ブラウザで開いて右下の「ピンを立てる」を押し、気になった場所をクリックしてコメントを書いてもらいます。 変化として大きかったのは次の3点です。 - **「どこの話か」の往復が消えた。**ピンは要素に紐付いているので、PCで立てた指摘をスマホ幅で確認しても同じ場所を指す。位置の解釈違いによる手戻りがなくなった - **対応漏れが構造的に起きなくなった。**指摘は自動採番され、対応後に「解決」へ変更する運用のため、「メールのどこかに書いてあった要望」が消失しない - **お客様側の心理的ハードルが下がった。**「わざわざメールを書くほどでもない」細かな違和感が、ワンクリックで届くようになり、公開前に潰せる品質問題が増えた サイトの微調整フェーズの体感速度は明確に上がりました。指摘を受けてから修正・確認依頼までがリアルタイムで回るため、Web会議をしながらその場で直して「解決」まで進むケースもあります。 ## よくある質問（FAQ） ### Q. レビュー対象のサイトにタグやスクリプトを埋め込む必要はありますか？ 不要です。プロキシサーバーがHTMLを中継する際にウィジェットのscriptタグをオンザフライで注入するため、ターゲットサイトのコードは一切変更しません。レビューをやめたければ、レビューURLを使わなくなるだけで痕跡も残りません。 ### Q. ターゲットサイトのCSSとレビューUIが干渉しませんか？ ウィジェットUIはすべてShadow DOM内でレンダリングしているため、ターゲットサイトのCSSフレームワークやリセットCSSと相互に干渉しません。 ### Q. レイアウトが変わってもピンの位置はずれませんか？ ピンは「CSSセレクタ＋要素内相対位置（%）」を第一優先、「ページ絶対座標」をフォールバックとする二重形式で保存しており、対象要素が特定できる限りレイアウト変化や画面幅の違いに追従します。大規模なDOM構造の変更（要素の削除など）があった場合は絶対座標での表示になります。 ### Q. 認証付きサイトや本番サイトもレビューできますか？ Cookieベースの認証付きサイトは、Set-CookieのDomain・Path書き換えにより中継できます。ただしhttp運用のためSecure属性を除去する設計であり、機密性の高い本番サイトの中継は想定していません。納品前・テスト公開中のサイトでの利用を前提としています。 ### Q. 同様のツールの受託開発は依頼できますか？ 可能です。今回のようなリアルタイム同期を伴う業務ツール、レビュー・承認フロー、既存システムと連携する社内向けWebアプリの設計・開発を承っています。[Webシステム開発](https://technosphere.co.jp/web-system)のページ、または[お問い合わせ](https://technosphere.co.jp/contact)からご相談ください。 ## まとめ ** この記事のまとめ - Web制作の修正指示は「位置情報の欠落」が手戻りの根本原因。実画面へのピン留めで解決できる - タグ埋め込み型・iframe型の課題（コード混入、X-Frame-Options/CSP、クロスオリジン制約）を避けるため、**リバースプロキシ型**を採用した - 成否を分けるのはURL書き換えの網羅性。HTML属性・srcset・CSSの`url()`・Location・Set-Cookieを書き換え、JSが組み立てる動的URLは**Refererベースの307リダイレクト**で救済する - ウィジェットUIは**Shadow DOM**で隔離し、ターゲットサイトのCSSとの相互干渉を仕組みごと封じた - ピン位置は「CSSセレクタ＋要素内相対%」と「絶対座標」の**二重保存**で、画面幅の違いやレイアウト変化に追従させる - 構成はNode.js 20＋Express＋ws＋better-sqlite3のみ。ビルド工程なし・Dockerコンテナ1つで、数年後も保守できる形にした 汎用のSaaSを使えば済む領域でも、「ターゲットに一切手を入れない」「社内LANで完結させる」のような譲れない条件があるなら、小さく自社開発する価値は十分にあります。PinRemarkは実装の中核（プロキシ書き換え＋注入＋Shadow DOM＋WebSocket）だけなら1,000行に満たない規模ですが、修正やり取りという制作フローのボトルネックを確実に取り除いてくれました。 テクノスフィアでは、こうしたリアルタイム性のある業務ツールやWebシステムの受託開発を承っています。WebSocketを用いた最大200名同時参加のリアルタイム入札システムなどの[開発事例](https://technosphere.co.jp/case-studies/pet-auction)も公開していますので、あわせてご覧ください。 [Webシステム開発](https://technosphere.co.jp/web-system) ｜ [リアルタイム入札システム開発事例](https://technosphere.co.jp/case-studies/pet-auction) ｜ [開発の相談をする](https://technosphere.co.jp/contact) ## 参考文献・出典 1. MDN Web Docs「Using shadow DOM」（Shadow DOMによるスタイル・DOMのカプセル化） — [developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_shadow_DOM) 2. SQLite「Write-Ahead Logging」（WALモードの並行読み書き特性） — [sqlite.org/wal.html](https://www.sqlite.org/wal.html) 3. MDN Web Docs「307 Temporary Redirect」（メソッドとボディを維持するリダイレクト） — [developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/307) 4. MDN Web Docs「Content-Security-Policy」 — [developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy) 5. better-sqlite3（GitHub） — [github.com/WiseLibs/better-sqlite3](https://github.com/WiseLibs/better-sqlite3) 6. ws: a Node.js WebSocket library（GitHub） — [github.com/websockets/ws](https://github.com/websockets/ws) ※本記事のコードは2026年7月時点の弊社実装からの抜粋（一部簡略化）です。PinRemarkは弊社の社内ツールであり、現時点で一般提供・販売は行っていません。 WebSocketを使ったリアルタイムWebシステムの開発事例は[最大200名同時参加のリアルタイム入札システム](https://technosphere.co.jp/case-studies/pet-auction)で、AIエージェントによる業務自動化は[Obsidian作業ログ＋Redmineチケット運用の完全自動化](https://technosphere.co.jp/blog/openclaw-skills-obsidian-redmine)で紹介しています。 [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # RAGチャットボット導入事例と費用｜ヘルプデスク問い合わせ60%削減の実例で解説｜テクノスフィア > 社内ヘルプデスクにRAGチャットボットを導入し、問い合わせ対応を60%削減した実例を公開。LangChain＋ベクトルDB＋GPT-4oの構成、オンプレでの秘匿運用、導入費用の目安と失敗しない進め方を実体験ベースで解説します。 URL: https://technosphere.co.jp/blog/rag-chatbot-helpdesk 本記事の内容は [RAGチャットボットとは？仕組みと作り方を図解でやさしく解説](https://technosphere.co.jp/blog/what-is-rag-chatbot) に統合しました。導入事例の詳細・技術構成・費用の考え方は、統合先の記事でより詳しくご覧いただけます。 近年、企業の社内問い合わせ対応の効率化手段として「RAGチャットボット」が注目されています。本記事では、弊社が実際に手がけた**社内ヘルプデスク向けチャットボットの導入事例と費用感**を中心にご紹介します。 ** RAGチャットボットの**仕組みやメリットの基礎**から知りたい方は、まず「[RAGチャットボットとは？仕組み・メリット・作り方を図解で解説](https://technosphere.co.jp/blog/what-is-rag-chatbot)」をご覧ください。本記事は導入事例・費用にフォーカスしています。 ## RAGとは？ RAG（Retrieval-Augmented Generation）とは、社内文書やマニュアルなどの独自データをAIに読み込ませ、その情報をもとに回答を生成する技術です。一般的なChatGPTと異なり、**「自社専用の知識」を持ったAI**を構築できます。 仕組みをシンプルに説明すると、次の3ステップで動作します。 1. **Retrieval（検索）**：ユーザーの質問に関連する社内ドキュメントをベクトルデータベースから検索する 2. **Augmented（補強）**：検索結果をコンテキストとしてLLM（大規模言語モデル）のプロンプトに追加する 3. **Generation（生成）**：コンテキストを踏まえてLLMが自然な日本語で回答を生成する ポイント：** RAGはChatGPT単体では不可能な「最新の社内情報」や「機密情報」を安全に活用できる点が最大の特長です。モデル自体の再学習（ファインチューニング）は不要なため、**コストを抑えながら高精度な社内AI**を実現できます。 ## 活用事例：社内ヘルプデスクチャットボット ある製造業のお客様では、膨大な業務マニュアルやFAQを社員が検索する手間が課題でした。弊社はLangChainとRAG技術を活用し、自然言語で質問するだけで即座に回答が得られるチャットボットを開発。**問い合わせ対応時間を約60%削減**することに成功しました。 ### 課題の詳細 導入前、社員の方々は次のような問題を抱えていました。 - 社内マニュアルが複数のシステムに分散しており、目的の情報を見つけるのに平均15〜20分かかっていた - 問い合わせが特定の担当者に集中し、業務のボトルネックになっていた - ベテラン社員のノウハウが暗黙知となっており、文書化されていなかった ### 弊社の実装アプローチ 技術スタックとして以下を採用しました。 - **LangChain**：RAGパイプライン全体のオーケストレーション - **OpenAI Embeddings**：文書のベクトル化（埋め込み表現） - **pgvector（PostgreSQL拡張）**：ベクトルデータベース（社内サーバーで完結） - **GPT-4o**：回答生成モデル - **Python / FastAPI**：バックエンドAPI ### 導入後の効果 ** 定量的な成果 - 社内問い合わせ対応時間：**平均17分 → 約7分（約60%削減）** - 情報検索にかかる時間：**平均18分 → 即時回答** - ヘルプデスク担当者の対応件数：**月間300件 → 120件に削減** ## 導入のポイント ** RAGチャットボット導入の3つのメリット - **既存資産をそのまま活用：**既存の社内文書（PDF・Word・Excel等）をそのままAIの知識源として活用できる。新たな文書作成は不要。 - **情報セキュリティの確保：**ChatGPTのような汎用AIと異なり、社外秘情報を社内環境で安全に扱える。オンプレミス構成にも対応。 - **メンテナンスの容易さ：**導入後も文書を更新・追加するだけでAIの回答が自動的に最新化される。 ## よくある質問（FAQ） ### RAGチャットボットと普通のチャットボット（ChatGPT）との違いは？ 一般的なChatGPTは学習済みの一般知識しか答えられませんが、RAGチャットボットは自社の社内文書・マニュアルを知識源にするため、**自社専用の正確な回答**ができます。機密情報を社内・オンプレミス環境で安全に扱える点も大きな違いです。 ### RAGチャットボットの作り方（構築手順）は？ ①社内文書をベクトルデータベース化し、②質問に関連する文書を検索（Retrieval）、③検索結果をLLMのプロンプトに付加（Augmented）、④回答を生成（Generation）という流れです。**LangChain＋pgvector等のベクトルDB＋GPT-4o等のLLM**で構築するのが一般的で、モデルの再学習（ファインチューニング）は不要です。 ### RAGチャットボットの導入費用の目安は？ 費用はデータ量・連携範囲（Slack / Teams / LINE など）・オンプレミス要件によって変動します。まずは小さく始める**PoC（概念実証）から段階的に拡張**するのが一般的です。具体的なお見積もりは無料相談で承ります。 ### RAGチャットボットの導入期間はどれくらい？ 要件と対象文書の規模によりますが、PoCであれば**数週間程度から着手**でき、本番運用は要件に応じて段階的に進めます。既存文書をそのまま知識源にできるため、ゼロからのデータ整備は不要です。 ## まとめ RAGチャットボットは、特別な技術知識がなくても導入しやすく、業務効率化の即効性が高いAIソリューションです。特に次のような企業・部門に効果的です。 - 社内マニュアル・規程類が多く、検索に時間がかかっている - 問い合わせ対応が特定の担当者に集中している - ChatGPTなどのクラウドAIに社内情報を入力することへのセキュリティ懸念がある ** この記事のまとめ - RAGは社内文書を知識源にしてAIが回答する技術。ファインチューニングより低コスト。 - LangChain + pgvector + GPT-4oの構成で、製造業の社内ヘルプデスクに適用し60%の効率化を達成。 - 既存文書をそのまま活用でき、セキュアな環境で運用可能。文書更新だけでAIも最新化。 RAGチャットボットの導入にご興味のある方は、ぜひお気軽にご相談ください。貴社の課題をヒアリングしたうえで、最適な構成をご提案します。 ／この内容の受託開発・PoC相談はこちら＼ ### 社内 RAG チャットボット・AI ヘルプデスクの受託開発 社内マニュアル・規程・FAQ を答えるRAGチャットボットを、Slack / Teams / LINE 組み込み、オンプレ完全秘匿運用まで含めて構築します。要件ヒアリングから PoC・本番運用まで一気通貫で対応。 [AI開発サービスを見る](https://technosphere.co.jp/ai-solution) [社内RAG・FAQ自動化相談](https://technosphere.co.jp/contact) [# RAG](https://technosphere.co.jp/blog/) [# LangChain](https://technosphere.co.jp/blog/) [# チャットボット](https://technosphere.co.jp/blog/) [# AI](https://technosphere.co.jp/blog/) [# 社内DX](https://technosphere.co.jp/blog/) ** この記事をシェア [X](https://twitter.com/intent/tweet?url=https://technosphere.co.jp/blog/rag-chatbot-helpdesk&text=RAGチャットボットとは？社内ヘルプデスクへの活用事例を解説&via=technosphere_co) [Facebook](https://www.facebook.com/sharer/sharer.php?u=https://technosphere.co.jp/blog/rag-chatbot-helpdesk) [LINE](https://social-plugins.line.me/lineit/share?url=https://technosphere.co.jp/blog/rag-chatbot-helpdesk) --- # Raspberry Piでセンサーデータ取得＆クラウド連携 完全ガイド｜株式会社テクノスフィア > Raspberry PiでI2C/SPI接続センサー（温湿度・加速度・CO₂）を読み取り、MQTT経由でAWS IoT Coreへ送信するまでを実装付きで解説。IoT・組込み制御の入門から実践まで。 URL: https://technosphere.co.jp/blog/raspberry-pi-sensor-iot ** 目次 1. はじめに：なぜ Raspberry Pi × センサー IoT なのか 2. 接続するセンサーとハードウェア構成 3. I2C センサーの読み取り（温湿度・CO₂） 4. SPI センサーの読み取り（加速度） 5. MQTT でクラウドへデータ送信 6. AWS IoT Core への接続設定 7. 実装上の注意点とトラブルシューティング 8. まとめ ## はじめに：なぜ Raspberry Pi × センサー IoT なのか 製造現場・農業・ビルマネジメントなど、あらゆる現場で「データを取って見える化したい」というニーズが急増しています。Raspberry Pi はその要件を低コストかつ短期間で実現できる最有力プラットフォームです。 Raspberry Pi が IoT 開発に選ばれる主な理由は以下の通りです。 - GPIO・I2C・SPI・UART・USB をすべて標準搭載 - Linux 環境で Python による高レベルな実装が可能 - Wi-Fi・Ethernet で即座にクラウド連携できる - 豊富なライブラリと情報量で開発速度が速い - 本番環境移行後も Raspberry Pi Compute Module で量産対応可能 ** ポイント 弊社では Raspberry Pi 4/5 を用いた IoT システムの受託開発を多数手がけています。本記事は実際の案件で得たノウハウをもとに構成しています。 ## 接続するセンサーとハードウェア構成 今回は以下のセンサーを使用します。いずれも入手性が高く、Raspberry Pi との組み合わせ実績が豊富です。 | センサー | 型番 | 通信方式 | 計測対象 | | 温湿度センサー | BME280 | I2C / SPI | 温度・湿度・気圧 | | CO₂センサー | SCD41 | I2C | CO₂・温度・湿度 | | 加速度センサー | ADXL345 | I2C / SPI | 3軸加速度 | | 照度センサー | BH1750 | I2C | 照度（lux） | ### 配線の基本：I2C の場合 Raspberry Pi の I2C ピンは **GPIO2（SDA）**・**GPIO3（SCL）** です。複数センサーを同一バスに接続する場合、それぞれのセンサーに異なる I2C アドレスを割り当てる必要があります。 **I2C を有効化する手順** ``` # raspi-config でI2Cを有効化 sudo raspi-config # → Interface Options → I2C → Enable # I2Cデバイスの確認 sudo apt install i2c-tools i2cdetect -y 1 # → 接続されたセンサーのアドレス（例: BME280=0x76, SCD41=0x62）が表示される ``` ## I2C センサーの読み取り（温湿度・CO₂） ### BME280 温湿度・気圧センサー BME280 は Bosch 製の高精度環境センサーです。Python では `smbus2` ライブラリを使って直接レジスタにアクセスするか、`adafruit-circuitpython-bme280` ライブラリで簡単に取得できます。 ``` import board import adafruit_bme280.basic as adafruit_bme280 # I2Cバスの初期化 i2c = board.I2C() bme280 = adafruit_bme280.Adafruit_BME280_I2C(i2c, address=0x76) # データ取得 print(f"温度: {bme280.temperature:.1f} ℃") print(f"湿度: {bme280.humidity:.1f} %") print(f"気圧: {bme280.pressure:.1f} hPa") ``` ### SCD41 CO₂センサー SCD41 は Sensirion 製の高精度 CO₂・温湿度センサーです。工場内の空気環境モニタリングや農業ハウスの CO₂ 管理に活用できます。 ``` import time import board import adafruit_scd4x i2c = board.I2C() scd4x = adafruit_scd4x.SCD4X(i2c) scd4x.start_periodic_measurement() time.sleep(5) # 最初の測定待ち if scd4x.data_ready: print(f"CO₂: {scd4x.CO2} ppm") print(f"温度: {scd4x.temperature:.1f} ℃") print(f"湿度: {scd4x.relative_humidity:.1f} %") ``` ## SPI センサーの読み取り（加速度） SPI は I2C より高速なデータ転送が可能で、加速度センサーや ADC など高サンプリングレートが必要なセンサーに向いています。ADXL345 は SPI・I2C 両対応のデジタル加速度センサーです。 ``` import board import busio import digitalio import adafruit_adxl34x # SPIバスの初期化（SPI0: MOSI=GPIO10, MISO=GPIO9, SCLK=GPIO11） spi = busio.SPI(board.SCLK, board.MOSI, board.MISO) cs = digitalio.DigitalInOut(board.CE0) # GPIO8: Chip Select accelerometer = adafruit_adxl34x.ADXL345(spi, cs) # 3軸加速度の取得 x, y, z = accelerometer.acceleration print(f"X: {x:.2f} m/s² Y: {y:.2f} m/s² Z: {z:.2f} m/s²") ``` ** 実案件でのポイント 振動監視システムでは、ADXL345 を 1kHz サンプリングで動作させ、FFT 解析で異常振動を検出する実装を行いました。SPI の高速転送がここで威力を発揮します。 ## MQTT でクラウドへデータ送信 取得したセンサーデータをクラウドに送信するプロトコルとして、IoT では **MQTT**（Message Queuing Telemetry Transport）が標準的に使われます。HTTP に比べて軽量・低遅延で、不安定なネットワーク環境にも強いのが特徴です。 ### paho-mqtt によるデータ送信 ``` import json import time import paho.mqtt.client as mqtt # MQTT ブローカー設定（ここでは AWS IoT Core エンドポイント） ENDPOINT = "xxxxxxx.iot.ap-northeast-1.amazonaws.com" PORT = 8883 TOPIC = "factory/line1/sensors" CLIENT_ID = "rpi-sensor-node-01" # TLS 証明書（AWS IoT Core から取得） CA_CERT = "/certs/AmazonRootCA1.pem" CERT_FILE = "/certs/device-certificate.pem.crt" KEY_FILE = "/certs/private.pem.key" def on_connect(client, userdata, flags, rc): print(f"接続完了: {rc}") client = mqtt.Client(client_id=CLIENT_ID) client.tls_set(CA_CERT, certfile=CERT_FILE, keyfile=KEY_FILE) client.on_connect = on_connect client.connect(ENDPOINT, PORT) client.loop_start() # センサーデータを定期送信 while True: payload = json.dumps({ "temperature": bme280.temperature, "humidity": bme280.humidity, "pressure": bme280.pressure, "co2": scd4x.CO2, "timestamp": int(time.time()) }) client.publish(TOPIC, payload, qos=1) print(f"送信: {payload}") time.sleep(30) # 30秒ごとに送信 ``` ## AWS IoT Core への接続設定 AWS IoT Core はマネージド型の IoT ブローカーサービスです。デバイス証明書による相互 TLS 認証を使うため、セキュリティが担保された状態でデータを送受信できます。 ### 接続までの手順 1. AWS IoT Core コンソールで「モノ」を作成 2. 証明書を作成・ダウンロード（デバイス証明書・秘密鍵・ルート CA） 3. 証明書にポリシーをアタッチ（iotConnect / iotPublish 権限） 4. エンドポイント URL を確認（設定 → デバイスデータエンドポイント） 5. 上記の Python スクリプトにエンドポイントと証明書パスを設定して実行 ** 活用例 弊社が手がけた工場の温湿度・CO₂ 管理システムでは、複数ラインの Raspberry Pi ノードから AWS IoT Core にデータを集約し、Amazon Timestream に蓄積、Grafana でリアルタイムダッシュボードを構築しました。設置から稼働まで約 2 週間で実現しています。 ## 実装上の注意点とトラブルシューティング ### よくあるトラブルと対策 | 症状 | 原因 | 対策 | | i2cdetect でデバイスが見えない | I2C 未有効化 / 配線ミス / プルアップ抵抗不足 | raspi-config で I2C 有効化・SDA/SCL に 4.7kΩ プルアップ抵抗を追加 | | センサー値が異常・ノイズが多い | 電源ノイズ / 長いケーブル | 100nF デカップリングコンデンサを VCC-GND 間に追加・ケーブルを 30cm 以内に | | MQTT 接続が切断される | ネットワーク不安定 / keepalive タイムアウト | paho-mqtt の `loop_start()` と自動再接続 `reconnect_delay_set()` を設定 | | システム起動時に自動実行されない | systemd サービス未設定 | systemd ユニットファイルを作成し `sudo systemctl enable` で自動起動登録 | ### 本番運用で必須の対策 - **watchdog タイマー**：スクリプトのフリーズを検出して自動再起動（`/dev/watchdog` または systemd の `WatchdogSec`） - **ログローテーション**：長期運用でログが肥大化しないよう `logrotate` を設定 - **OTA アップデート**：AWS IoT Jobs を使ってリモートからファームウェアを更新 - **電源断対策**：UPS モジュール（PiSugar / Witty Pi）またはシャットダウンスクリプトで SD カードの破損を防止 ## まとめ ### この記事のまとめ - Raspberry Pi は I2C・SPI・UART をすべて標準搭載し、多様なセンサーと接続できる - BME280（温湿度・気圧）・SCD41（CO₂）は I2C で簡単に読み取れる - ADXL345 など高速サンプリングが必要なセンサーは SPI が有利 - paho-mqtt + AWS IoT Core でセキュアなクラウド送信が実現できる - 本番運用には watchdog・ログローテーション・OTA・電源断対策が必須 Raspberry Pi を使った IoT システムの開発・設計でご不明な点がありましたら、株式会社テクノスフィアにお気軽にご相談ください。要件ヒアリングから設計・実装・クラウド連携・保守まで一気通貫で対応します。 ／この内容の受託開発・PoC相談はこちら＼ ### Raspberry Pi 産業 IoT・センサー監視システムの受託開発 温湿度・振動・電流など現場センサーをラズパイで収集して AWS IoT / Azure IoT に連携する産業 IoT システム、PoC から現場設置・保守運用まで一気通貫でお引き受けします。 [組込み開発サービスを見る](https://technosphere.co.jp/embedded) [産業IoT・ラズパイ受託相談](https://technosphere.co.jp/contact) # Raspberry Pi # I2C # SPI # センサー制御 # IoT # MQTT # AWS IoT # 組込み制御 センサーで集めたデータをスマートフォンから確認・操作したい場合は、[BLEでスマホと機器をつなぐアプリ開発](https://technosphere.co.jp/blog/ble-device-app-integration)もあわせてご覧ください。機器とアプリを一貫して開発する[スマホアプリ開発サービス](https://technosphere.co.jp/app-development)もご用意しています。 [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # Raspberry Piで動かすvLM完全ガイド｜限られたリソースで画像×言語AIを構築するエッジAI実装ノウハウ｜株式会社テクノスフィア > Raspberry Pi 4/5 で Moondream2・SmolVLM・Qwen2-VL などの小型 vLM をエッジ動作。llama.cpp+GGUF 量子化、解像度・トークン制御、メモリ最適化、実案件展開まで解説。 URL: https://technosphere.co.jp/blog/raspberry-pi-vlm-edge-ai ** 目次 1. はじめに：なぜラズパイで vLM を動かすのか 2. vLM (Vision Language Model) とは？ 3. エッジで vLM を動かす5つのメリット 4. ラズパイで動く小型 vLM の選択肢 5. ハードウェア構成と前準備 6. 実装①：Moondream2 で画像を「会話」させる 7. 実装②：SmolVLM-256M で超軽量ストリーム推論 8. 実装③：llama.cpp + GGUF で速度を稼ぐ 9. 限られたリソースで性能を引き出す8つのテクニック 10. 実案件での活用パターン 11. パフォーマンス比較（参考値） 12. トラブルシューティング 13. まとめ ** 本記事の前提 本記事のベンチマーク値・モデルサイズは **Raspberry Pi 5 (8GB) / Raspberry Pi 4 (4GB)**、64bit Raspberry Pi OS Bookworm 環境を想定した **参考値** です。実機性能はカーネルバージョン・スワップ設定・電源（公式 5V/5A 推奨）・冷却条件で変動します。実運用では必ず本番相当の環境で計測してください。本記事のコードは Python 3.11 系・llama.cpp 2026 年春時点のビルドを前提としています。 ## はじめに：なぜラズパイで vLM を動かすのか 「カメラ画像を見て、何が起きているか日本語で説明してほしい」「製品の傷を写真から判定して、改善コメントまで出してほしい」——従来の画像分類CNNでは *「クラスを返すだけ」* で止まっていたタスクが、**vLM (Vision Language Model)** の登場で **「画像を理解して、文章で答える」** 領域まで一気に踏み込めるようになりました。 これまで vLM といえば GPT-4o / Claude / Gemini など、クラウド経由で大型GPUを使う前提でした。しかし 2024〜2026 年にかけて **1B〜2B パラメータ級の小型 vLM** が急増し、量子化技術と組み合わせれば **Raspberry Pi 5 でもローカル推論が現実的** になっています。 本記事では「クラウドに送れない画像」「ネットワークが弱い現場」「サブスクコストを掛けたくない案件」で **Raspberry Pi + 小型 vLM** を主役に据えた構築ノウハウを、実コード付きで体系的に解説します。 ** 弊社での活用実績 テクノスフィアでは Raspberry Pi をベースとした [産業 IoT・画像認識システムの受託開発](https://technosphere.co.jp/embedded-achievements) を多数手がけており、近年は **「現場で完結する小型 vLM」** をエッジに搭載するケースが急増しています。本記事は実案件で蓄積した知見と検証結果をもとに構成しています。 ## vLM (Vision Language Model) とは？ **vLM**（Vision Language Model、視覚言語モデル）とは、**画像と言語（テキスト）を同じ意味空間で扱える** マルチモーダル AI の総称です。LLM が「文章を入力して文章を返す」のに対し、vLM は **「画像＋質問文を入力して文章を返す」** ことができます。 ### vLM の基本構造 多くの vLM は以下の 3 つのモジュールで構成されています。 1. **Vision Encoder**：画像を特徴ベクトル列に変換する（SigLIP / CLIP-ViT が主流） 2. **Projector (Connector)**：画像特徴を LLM の埋め込み空間にマップする小さな MLP 3. **LLM (Decoder)**：画像トークン＋テキストトークンを並べてテキストを生成する つまり vLM の本質は **「画像を擬似的なトークン列に変換して LLM に食わせる」** 仕組みであり、LLM 部分が小さいほどラズパイでも動かしやすくなります。 ### vLM で何ができるか（代表タスク） - **画像説明 (Image Captioning)**：画像の内容を文章で記述 - **視覚的質問応答 (VQA)**：「この製品にキズはありますか？」のような質問に回答 - **OCR + 理解**：画像中の文字を読み取り、意味を解釈（伝票・ラベル・看板） - **物体検出＋言語化**：「左から2番目の棚に欠品があります」のような位置情報付き出力 - **文書理解**：図表入りの PDF / スキャン画像を要約 - **動作分析**：連続フレームから人や機械の状態を文章化 ## エッジで vLM を動かす5つのメリット クラウド vLM API が高品質である現代に、あえてラズパイで動かす理由は何でしょうか。実案件で評価される主な理由は次の 5 点です。 | 観点 | クラウド vLM | ラズパイ vLM | | 機密データの扱い | 外部送信が必要（規制で NG のケース多） | **画像が機器外に出ない** | | 応答遅延 | 500ms〜数秒（往復＋待ち行列） | **ローカル完結で安定** | | ランニングコスト | 1呼出 0.5〜数円 × 大量推論 | **電気代のみ** | | ネットワーク依存 | 切断時はサービス停止 | **オフラインで動作** | | カスタマイズ | プロンプト調整のみ | **追加学習・量子化・蒸留が可能** | ** 特に効くのは「閉域要件」 医療・製造・防衛・行政の現場では「画像をインターネットに出してはいけない」という制約があります。クラウドが原則NGな案件で、**vLM の表現力が欲しい場合の唯一の現実解がエッジ vLM** です。 ## ラズパイで動く小型 vLM の選択肢 2026 年春時点で、Raspberry Pi 4 / 5 クラスのリソース（CPU のみ、RAM 4〜8GB）で実用速度を出せる代表的な vLM を整理します。 | モデル | パラメータ | RAM（INT4量子化） | 強み | 用途 | | **Moondream2** | 1.86B | 約 1.2〜1.5GB | 軽量・VQA 強い | 製品検査・棚モニタ・防犯 | | **SmolVLM-256M / 500M** | 0.26B / 0.5B | 0.3〜0.8GB | 圧倒的に軽い・常時推論向け | ストリーム監視・低消費電力 | | **SmolVLM2-2.2B** | 2.2B | 約 1.5GB | 軽量＋高精度 | OCR・文書理解 | | **Qwen2-VL-2B** | 2.0B | 約 1.5GB | 動的解像度・多言語に強い | 日本語UI・帳票読取 | | **InternVL2-1B / 2B** | 0.9B / 2.2B | 0.8〜1.5GB | 商用ライセンス・OCR | 業務帳票・図面解析 | | **LLaVA-OneVision 0.5B** | 0.5B | 約 0.7GB | 多タスク・低レイテンシ | 軽量バッチ処理 | ** 選定のコツ まずは **「SmolVLM-256M / 500M で要件を満たせるか」**を最初に検証するのがおすすめです。性能が足りなければ Moondream2 や Qwen2-VL-2B へ段階的にスケールアップ。**「いきなり 7B/8B モデルから検討」しない**のが、エッジ vLM 設計の鉄則です。 ## ハードウェア構成と前準備 ### 推奨ハードウェア | 項目 | 推奨 | 備考 | | 本体 | Raspberry Pi 5 (8GB) | Pi 4 (4GB) でも 0.5B 級なら可。Pi 5 で 2B 級が現実的 | | ストレージ | NVMe SSD (HAT or USB3) | モデル読込が SD カードの 3〜5 倍速くなる | | カメラ | Pi Camera Module 3 / USB UVC | 1080p で十分。vLM 入力は 384〜512px に縮小される | | 電源 | 公式 27W USB-C PD アダプタ | 推論中はピーク電流が増えるため必須 | | 冷却 | アクティブクーラー（純正可） | 長時間推論ではサーマルスロットリングを防ぐ | | OS | Raspberry Pi OS 64bit (Bookworm) | 32bit では多くのモデルが動かない | ### OSの初期セットアップ ``` # 64bit OSであることを確認 uname -m # → aarch64 であること # システム更新と基本ツール sudo apt update && sudo apt upgrade -y sudo apt install -y python3-pip python3-venv git cmake build-essential \ libopenblas-dev libjpeg-dev libpng-dev v4l-utils # スワップを増やす（推論中のメモリ逼迫対策） sudo dphys-swapfile swapoff sudo sed -i 's/^CONF_SWAPSIZE=.*/CONF_SWAPSIZE=2048/' /etc/dphys-swapfile sudo dphys-swapfile setup sudo dphys-swapfile swapon # GPU メモリは vLM 推論には使わないので最小化（VideoCore は重要でない） # /boot/firmware/config.txt に下記を追記 # gpu_mem=16 ``` ### Python 仮想環境 ``` python3 -m venv ~/vlm-env source ~/vlm-env/bin/activate pip install --upgrade pip wheel # 共通の最小依存 pip install pillow numpy opencv-python-headless requests ``` ## 実装①：Moondream2 で画像を「会話」させる Moondream2 は 1.86B パラメータの小型 vLM で、Raspberry Pi 5 (8GB) で実用的に動作する代表的なモデルです。VQA（視覚的質問応答）に強く、**「製品にキズはあるか」「左の棚に欠品はあるか」** といった現場質問に向いています。 ### セットアップ ``` # PyTorch (CPU版、aarch64対応) と transformers pip install --index-url https://download.pytorch.org/whl/cpu torch torchvision pip install transformers accelerate einops pyvips ``` ### 最小実装：画像 → 説明文 ``` from transformers import AutoModelForCausalLM, AutoTokenizer from PIL import Image import torch MODEL_ID = "vikhyatk/moondream2" # Raspberry Pi は CPU 実行のため float32 でロードする # （PyTorch の CPU バックエンドは float16 演算をほぼサポートしないため。 # GPU/CUDA がある環境でのみ torch.float16 が有効。 # ※省メモリ・高速化を狙うなら後述の llama.cpp + GGUF 量子化を推奨） model = AutoModelForCausalLM.from_pretrained( MODEL_ID, trust_remote_code=True, torch_dtype=torch.float32, low_cpu_mem_usage=True, ) tokenizer = AutoTokenizer.from_pretrained(MODEL_ID) image = Image.open("/home/pi/capture.jpg").convert("RGB") # Step1: 画像をエンコード（重い処理。1回だけ） enc = model.encode_image(image) # Step2: 同じ画像に複数の質問を投げる（軽い） print(model.answer_question(enc, "この画像に何が写っていますか？", tokenizer)) print(model.answer_question(enc, "棚に欠品はありますか？", tokenizer)) print(model.answer_question(enc, "人物は何人いますか？", tokenizer)) ``` ** 速度の鍵：画像エンコードを使い回す `encode_image()` は重い処理（数秒〜十数秒）ですが、**同じ画像に対する複数の質問では再利用できます**。製品検査で「キズ」「変色」「ラベルの向き」を順に確認するようなパイプラインでは、エンコードを1回・質問をN回にする設計が必須です。 ### カメラからリアルタイム推論 ``` import cv2 import time cap = cv2.VideoCapture(0) cap.set(cv2.CAP_PROP_FRAME_WIDTH, 1280) cap.set(cv2.CAP_PROP_FRAME_HEIGHT, 720) QUESTION = "この映像に異常はありますか？1文で答えてください。" while True: ok, frame = cap.read() if not ok: continue img = Image.fromarray(cv2.cvtColor(frame, cv2.COLOR_BGR2RGB)) t0 = time.time() enc = model.encode_image(img) answer = model.answer_question(enc, QUESTION, tokenizer) dt = time.time() - t0 print(f"[{dt:.1f}s] {answer}") time.sleep(5) # 5秒ごとに推論（連続推論は熱対策上推奨しない） ``` ## 実装②：SmolVLM-256M で超軽量ストリーム推論 **SmolVLM-256M** はわずか 2.6 億パラメータながら、Hugging Face が公開する **「世界最小級の実用 vLM」** です。Raspberry Pi 4 (4GB) でも動作し、Pi 5 では **カメラフレーム毎秒の連続推論** に近い速度が出ます。 ### セットアップ ``` pip install --upgrade transformers # 量子化が必要なら pip install bitsandbytes accelerate ``` ### 実装例 ``` from transformers import AutoProcessor, AutoModelForVision2Seq from PIL import Image import torch MODEL_ID = "HuggingFaceTB/SmolVLM-256M-Instruct" processor = AutoProcessor.from_pretrained(MODEL_ID) model = AutoModelForVision2Seq.from_pretrained( MODEL_ID, torch_dtype=torch.float32, # CPU(Raspberry Pi)実行のため float32。CUDA環境なら float16 可 low_cpu_mem_usage=True, ).eval() def ask(image_path: str, question: str) -> str: image = Image.open(image_path).convert("RGB") # SmolVLM はチャットテンプレートで画像位置を指定 messages = [{ "role": "user", "content": [ {"type": "image"}, {"type": "text", "text": question}, ], }] prompt = processor.apply_chat_template(messages, add_generation_prompt=True) inputs = processor(text=prompt, images=[image], return_tensors="pt") with torch.inference_mode(): out = model.generate(**inputs, max_new_tokens=64, do_sample=False) return processor.decode(out[0][inputs["input_ids"].size(1):], skip_special_tokens=True) print(ask("shelf.jpg", "棚の状態を1文で教えて")) print(ask("road.jpg", "歩行者は何人ですか？")) ``` ** SmolVLM が刺さる現場 SmolVLM-256M は精度では Moondream2 や Qwen2-VL に劣りますが、**「常時カメラに張り付かせる用途」**では圧倒的に有利です。例えば「人が立ち入ったら通知」「棚の状態が変わったら検知」など、**イベント検出のフロントエンド**として使い、詳細解析は別モデル or クラウドへ渡すハイブリッド構成が効果的です。 ## 実装③：llama.cpp + GGUF で速度を稼ぐ Python (transformers) は実装が楽ですが、**ARM CPU での実行速度** という観点では [llama.cpp](https://github.com/ggerganov/llama.cpp) + GGUF（4bit / 5bit 量子化）に分があります。Raspberry Pi 5 では **体感 1.5〜3 倍の高速化** が見込めます。 ### llama.cpp のビルド（aarch64） ``` cd ~ git clone https://github.com/ggerganov/llama.cpp.git cd llama.cpp # NEON/dotprod を有効化したリリースビルド cmake -B build -DCMAKE_BUILD_TYPE=Release \ -DGGML_NATIVE=ON \ -DLLAMA_BLAS=ON -DLLAMA_BLAS_VENDOR=OpenBLAS cmake --build build --config Release -j$(nproc) # vLM 用の実行ファイル（マルチモーダル対応） ls build/bin/ | grep -E "llama-mtmd|llama-llava" ``` ### GGUF モデルの取得（例：Moondream2 INT4） ``` # Hugging Face CLI 経由（モデル名は適宜置換） pip install -U huggingface_hub huggingface-cli download vikhyatk/moondream2 \ --include "*q4*.gguf" "*mmproj*.gguf" \ --local-dir ~/models/moondream2 ls ~/models/moondream2/ # moondream2-text-model-f16_q4_0.gguf # moondream2-mmproj-f16.gguf ``` ### 推論実行（マルチモーダル CLI） ``` ~/llama.cpp/build/bin/llama-mtmd-cli \ -m ~/models/moondream2/moondream2-text-model-f16_q4_0.gguf \ --mmproj ~/models/moondream2/moondream2-mmproj-f16.gguf \ --image ~/capture.jpg \ -p "この画像に異常があれば1文で報告してください。" \ -n 64 -t 4 # -t : 使うスレッド数。Pi 5 では 3〜4 がスイートスポット ``` ### HTTP サーバとしてバックグラウンド起動 常駐させて他のアプリから呼ぶには `llama-server` を使います。Python / Node.js / シェルから OpenAI 互換 API で叩けるのが強みです。 ``` ~/llama.cpp/build/bin/llama-server \ -m ~/models/moondream2/moondream2-text-model-f16_q4_0.gguf \ --mmproj ~/models/moondream2/moondream2-mmproj-f16.gguf \ --host 0.0.0.0 --port 8080 \ -c 2048 -t 4 -ngl 0 & # Python から呼び出し import base64, requests with open("capture.jpg","rb") as f: b64 = base64.b64encode(f.read()).decode() r = requests.post("http://localhost:8080/v1/chat/completions", json={ "messages":[ {"role":"user","content":[ {"type":"text","text":"棚に欠品はありますか？"}, {"type":"image_url","image_url":{"url":f"data:image/jpeg;base64,{b64}"}} ]} ], "max_tokens": 64 }) print(r.json()["choices"][0]["message"]["content"]) ``` ** 量子化の選び方 Raspberry Pi 5 では **Q4_K_M**（4bit, K-quant medium）が **速度と精度のバランスが最も良い** 選択肢です。Q3_K_M は更に軽いものの、日本語応答の品質が目に見えて劣化します。Q5_K_M / Q6_K は精度は高いが Pi 5 でも速度が体感で重くなり、メモリも逼迫しがちです。 ## 限られたリソースで性能を引き出す8つのテクニック ラズパイ vLM の体感性能は、**モデル選定だけでなく実装の作り込みで2〜10倍変わります**。実案件で効いた工夫を 8 つ紹介します。 ### ① 入力解像度を意図的に下げる vLM の Vision Encoder は内部で 384〜512px などに縮小しています。**入力を 1920×1080 のまま渡しても、ほとんどのモデルでは意味がない**どころか、デコード負荷で遅くなるだけです。事前に `Pillow.thumbnail((640, 480))` 等で縮小しましょう。 ### ② max_new_tokens は最小限に 推論時間は **「生成トークン数」に比例**します。「異常があるか／ないか」だけ知りたいケースで 256 トークン生成するのは無駄。**`max_new_tokens=32〜64`** に絞り、プロンプトで「1文で」「Yes/No で」と明示します。 ### ③ 質問を「分類タスク化」する 「異常があれば yes、なければ no で答えなさい」のようにプロンプトを **離散的な選択肢**に閉じ込めると、後段プログラムが扱いやすく、生成も短く済みます。チェーン・オブ・ソートが必要ないタスクではこれが最速です。 ### ④ Vision Encoder の結果をキャッシュ 同じ画像に対する複数質問は、Moondream2 のように `encode_image()` の結果を保持して使い回します。llama.cpp でも `--image` で同一ファイルを渡せば再エンコードを抑えられます。 ### ⑤ プリプロセスを軽量化（GPU を当てにしない） OpenCV は `opencv-python-headless` を使い GUI ライブラリを排除。色変換は `cv2.cvtColor` 一発で済ませ、リサイズは `cv2.INTER_AREA` を選択。NumPy→PIL の往復は避けます。 ### ⑥ スレッド数を CPU コアに合わせる Raspberry Pi 5 は 4 コア。**`-t 4` が最も速い**とは限らず、I/O やシステム動作と競合するため **`-t 3` がスイートスポットになるケース**もあります。本番想定の負荷で必ず実測しましょう。 ### ⑦ プロセス常駐＋IPC 設計 毎回 Python を起動してモデルをロードしていては **10〜30 秒のロード時間**が毎回乗ります。`llama-server` や FastAPI でモデルを常駐させ、フロントから **HTTP / UNIX ソケット / ZeroMQ** で呼び出す設計にします。 ### ⑧ 冷却とサーマルスロットリング対策 長時間推論では Pi 5 で 80℃ を超えやすく、自動的にクロックが下がります。アクティブクーラーは必須、ケースは通気の良いものを。`vcgencmd measure_temp` で常時温度をモニタし、80℃ 手前で **推論間隔を伸ばすバックオフ制御**を入れると安定運用できます。 ``` # サーマルバックオフ例 import subprocess, time def cpu_temp() -> float: out = subprocess.check_output(["vcgencmd", "measure_temp"]).decode() return float(out.split("=")[1].split("'")[0]) while True: if cpu_temp() > 78: time.sleep(10) continue # 通常の推論ループ run_inference() ``` ## 実案件での活用パターン テクノスフィアでこれまでに検証・提案してきた、ラズパイ vLM の典型的な活用パターンを 5 つご紹介します。 ### ① 製造ラインの簡易外観検査 従来は **欠陥クラスごとに学習データを集めて CNN を作る**必要がありましたが、vLM なら **プロンプトを変えるだけで検査項目を追加**できます。「ラベルが斜めに貼られていないか」「フィルムに気泡はないか」など、定性的な検査項目との相性が抜群です。 ### ② 小売の棚モニタリング・欠品検知 店内 Wi-Fi がない・帯域が細い店舗でも、ラズパイ＋USBカメラ＋vLM の構成なら **機器内で完結**。「2 段目の右端が空いています」のように **位置情報付きで通知**させられます。 ### ③ 農業ハウスの作物・病害観察 圃場はネットワーク条件が厳しく、撮影画像をクラウドに送れないケースが多々あります。エッジ vLM で「葉に黄変が見られます」「水滴が異常に多いです」のように **自然言語でログを残し、要約のみクラウドへ**送る運用が有効です。 ### ④ 設備保全：計器盤の自動読み取り 古いアナログ計器・指針メーター・LCD パネルを **Raspberry Pi カメラ＋vLM** で読み取り、SCADA 連携。CNN ベースの OCR より **レイアウト変動・照明変化に強い**のが現場で評価されるポイントです。 ### ⑤ 入退室・安全管理 「ヘルメットを着用していない人がいる」「立入禁止エリアに人がいる」といった **安全ルール監視**は、vLM のゼロショット能力が活きる領域。プロンプトでルールを記述するだけでルール追加できます。 ** 弊社の対応領域 テクノスフィアでは、要件ヒアリング → vLM 選定 → 量子化・最適化 → 筐体・配線 → 現場設置 → 運用監視まで **一気通貫**で対応しています。「クラウドに送れない画像で AI 化したい」「PoC をすぐ作りたい」場合は[お問い合わせ](https://technosphere.co.jp/contact)からご相談ください。 ## パフォーマンス比較（参考値） Raspberry Pi 5 (8GB) / 公式アクティブクーラー / Q4_K_M 量子化（llama.cpp）/ 1枚の画像に「この画像を1文で説明してください」を投げた場合の参考値です。**あくまで弊社環境での実測例**であり、画像内容・プロンプト長で大きく変動します。 | モデル | 画像エンコード | 生成 (64 tok) | 合計 | ピーク RAM | | SmolVLM-256M | 約 0.4 秒 | 約 1.5 秒 | **約 2 秒** | 約 0.5GB | | SmolVLM-500M | 約 0.8 秒 | 約 2.5 秒 | 約 3 秒 | 約 0.9GB | | Moondream2 (1.86B) | 約 3〜4 秒 | 約 4〜5 秒 | 約 8 秒 | 約 1.5GB | | Qwen2-VL-2B | 約 4 秒 | 約 5〜6 秒 | 約 10 秒 | 約 1.6GB | ** 数値の見方 これらは **「リアルタイム動画解析」には足りない**速度ですが、**「数秒〜数十秒に1回トリガで推論する用途」には十分実用的**な水準です。秒間複数フレームが必要なら、軽量検出器（YOLOv8n / OpenCV モーション検出）でイベントトリガを作り、vLM はトリガ時のみ呼ぶ **ハイブリッド構成**が定石です。 ## トラブルシューティング | 症状 | 原因 | 対策 | | モデルロード中に Killed | RAM 不足（OOM Killer 発動） | スワップ拡張、より小さなモデル（256M/500M）、量子化レベルを下げる（Q4→Q3） | | 推論中に温度上昇でフリーズ | サーモスロットリング・電源不足 | 純正クーラー、27W PD電源、`vcgencmd`でバックオフ制御 | | 応答が意味不明・文字化け | 量子化が攻めすぎ / プロンプトテンプレ不一致 | Q5_K_M に上げる、チャットテンプレートを公式準拠で使う | | 日本語応答が英語混じり | モデルが日本語データを十分に学習していない | Qwen2-VL / InternVL2 を選ぶ、出力に「日本語で」と明示 | | 毎回起動が遅い | SD カード I/O / モデル毎回ロード | NVMe SSD 化、`llama-server` 常駐＋IPC 構成へ変更 | | 映像が止まる | 推論ループが UI / カメラ取得をブロック | カメラ取得と推論を別スレッド/プロセスに分離（Queue で連携） | ## まとめ ### この記事のまとめ - vLM (Vision Language Model) は「画像＋質問 → 文章」を生成するマルチモーダル AI - Raspberry Pi 5 (8GB) + 量子化により、1〜2B クラスの vLM がエッジで実用速度に到達 - 軽さなら **SmolVLM-256M/500M**、バランスなら **Moondream2**、日本語 OCR なら **Qwen2-VL-2B / InternVL2** が現実的な選択肢 - 速度の鍵は **llama.cpp + Q4_K_M 量子化**、**常駐サーバ化**、**解像度・トークン数の圧縮**、**Vision Encoder のキャッシュ** - 製造検査・棚モニタ・農業観察・計器読み取り・安全管理など、**「クラウドに送れない画像」案件で特に強い** - 軽量検出器でイベント検出 → vLM で言語化、というハイブリッド構成が実運用の定石 テクノスフィアでは Raspberry Pi をはじめとした [組込み・エッジ AI 案件](https://technosphere.co.jp/embedded-achievements) を、要件定義から PoC・量産・運用まで一気通貫で支援しています。「クラウドを使わずに画像 AI を導入したい」「既存のラインに後付けしたい」「vLM の PoC を最短で立ち上げたい」といったご相談は、お気軽にお問い合わせください。 ### 関連記事 - [Raspberry Piでセンサーデータ取得＆クラウド連携 完全ガイド](https://technosphere.co.jp/blog/raspberry-pi-sensor-iot) - [RAGチャットボット導入事例｜社内ヘルプデスク60%削減](https://technosphere.co.jp/blog/what-is-rag-chatbot) - [RAGチャットボットとは？仕組み・メリット・導入方法](https://technosphere.co.jp/blog/what-is-rag-chatbot) - [STM32 低消費電力モード完全ガイド](https://technosphere.co.jp/blog/stm32-low-power-battery) ／この内容の受託開発・PoC相談はこちら＼ ### ラズパイ × vLM / エッジ画像 AI の受託開発 クラウドに送れない現場画像を、Raspberry Pi / Jetson 上の vLM（視覚言語モデル）で AI 化する PoC と量産導入を一気通貫で対応。要件ヒアリングから筐体・配線・現場設置・運用監視まで。 [組込み開発サービスを見る](https://technosphere.co.jp/embedded) [AI開発サービスを見る](https://technosphere.co.jp/ai-solution) [エッジAI・vLM現場導入相談](https://technosphere.co.jp/contact) # vLM # Vision Language Model # Raspberry Pi # エッジAI # マルチモーダル # Moondream # SmolVLM # llama.cpp # 量子化 # エッジコンピューティング [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # ルネサスマイコン開発ガイド 総目次｜RL78・RX・RA・H8/SuperH移行の実装記事まとめ｜株式会社テクノスフィア > ルネサスマイコンの実装・移行ガイド8本をファミリ別・目的別に整理した総目次。RL78/RX/RAの選定と実装、FSP・Smart Configuratorでの開発、H8・SuperHなどレガシー資産の保守・移行判断まで。組込み受託開発のテクノスフィアが実務目線で解説。 URL: https://technosphere.co.jp/blog/renesas-mcu-guide ** 目次 1. このガイドの使い方 2. 目的別・記事の読み方マップ 3. 1. ファミリを選ぶ（RL78・RX・RA比較） 4. 2. RAで新規開発を始める 5. 3. RXで実装する 6. 4. RL78で実装する 7. 5. H8の現状を知る 8. 6. H8/H8Sから移行する 9. 7. SH（SuperH）から移行する 10. 8. 資料がない資産を復元する ## このガイドの使い方 当ブログではルネサスマイコンの実装・移行ガイドを継続的に公開しており、現行3ファミリ（RL78・RX・RA）の選定・実装から、H8・SuperHといったレガシー資産の保守・移行まで8本が揃いました。各記事はルネサス公式のマニュアル・ツールドキュメントを一次資料として、Smart ConfiguratorやFSPの設定手順、実装コードまで踏み込んだ実務者向けの内容です。 このページはその**総目次**です。「新しく作る」のか「動いているものを守る・移す」のかで読む記事が変わるため、目的から逆引きできるように整理しました。 ## 目的別・記事の読み方マップ | いまの状況 | 読む記事 | | 新規開発でどのファミリにするか迷っている | RL78・RX・RA選定ガイド | | Arm系（RA）で新しく始めたい | RAファミリ入門 | | RXでペリフェラルを実装したい | RXマイコン入門 | | 電池駆動・低消費電力の機器を作りたい | RL78ペリフェラル実装ガイド | | H8搭載の機器を保守している／今後が不安 | H8マイコンとは（現状整理） | | H8からの移行を具体的に検討している | H8/H8S移行ガイド | | SH（SuperH）搭載機器の更新が必要 | SuperH移行ガイド | | 仕様書もソースもない機器を何とかしたい | RL78逆アセンブル実践 | ## 1. ファミリを選ぶ（RL78・RX・RA比較） ### [RL78・RX・RA どれを選ぶ？ルネサスマイコン選定ガイド](https://technosphere.co.jp/blog/renesas-mcu-selection-guide) 現行3ファミリをビット幅・CPUコア・クロック帯・開発環境（CS+/e2 studio）・コンパイラ・長期供給プログラム（PLP）の軸で比較し、電池駆動・モーター制御・新規Arm設計といった用途別の選定フローを示します。H8/SuperHからの移行先マッピングも掲載しています。 **こんな時に:** 新規案件の頭出しでファミリを決める時。レガシー移行の行き先を検討する時。 ## 2. RAで新規開発を始める ### [Renesas RAファミリ入門｜FSPとe2 studioで始めるArmマイコン開発](https://technosphere.co.jp/blog/renesas-ra-introduction) ルネサスのArm Cortex-M系主力「RA」の入門記事です。RA0〜RA8各シリーズの守備範囲、FSP（Flexible Software Package）のHALドライバの考え方、e2 studioでのプロジェクト作成からUARTエコーバック実装までを実際の手順で解説。STM32経験者向けにHAL/CubeMXとFSP/e2 studioの対応関係も整理しています。 **こんな時に:** Armエコシステムを前提に新規設計する時。STM32経験を活かしてルネサスに入る時。 ## 3. RXで実装する ### [Renesas RX マイコン入門｜SCI・RIIC・MTU・ADCをFITモジュールで実装](https://technosphere.co.jp/blog/renesas-rx-introduction) RXファミリ（RX100/200/600/700）の概要と、SCI・RIIC・MTU・12bit ADCといった主要ペリフェラルの実装を、FITモジュールとSmart Configurator・e2 studioで進める方法を実例で解説します。 **こんな時に:** 産業機器・モーター制御などでRXを使った実装に入る時。 ## 4. RL78で実装する ### [Renesas RL78 ペリフェラル実装ガイド｜UART・I2C・タイマ・ADC](https://technosphere.co.jp/blog/renesas-rl78-peripheral-guide) 低消費電力16bitマイコンRL78のUART（SAU）・I2C（IICA）・タイマ（TAU）・12bit ADCを、Smart Configuratorのコード生成で実装する手順を解説。CS+/e2 studio/CC-RLの環境から、STOP/SNOOZEモードの活用まで扱います。 **こんな時に:** 電池駆動機器・小型機器でRL78のペリフェラルを組む時。 ## 5. H8の現状を知る ### [H8マイコンとは？いまも現場で動き続ける理由と、保守・移行の判断ポイント](https://technosphere.co.jp/blog/what-is-h8-microcontroller) 日立製作所発祥のH8ファミリの基礎知識と2026年時点の現状整理です。ルネサス公式サイトでの製品ステータス確認手順、HEW・E8aエミュレータなど開発環境の入手性、「維持か移行か」の判断フローを、一次資料に基づいて解説します。 **こんな時に:** H8搭載機器を引き継いだ時。保守継続のリスクを整理したい時。 ## 6. H8/H8Sから移行する ### [H8/H8S マイコン移行ガイド｜EOL対策とRL78/RXへのリプレース・再生](https://technosphere.co.jp/blog/h8-h8s-migration-guide) H8/H8S/H8SXのEOL・NRND対策の技術詳細版です。旧開発環境の老朽化・コード紛失・周辺差異という移行の壁と、RL78・RXなど現行マイコンへの移植・再生ノウハウを実例ベースで解説します。 **こんな時に:** H8からの移行を具体的に計画・見積もる段階に入った時。 ## 7. SH（SuperH）から移行する ### [SH（SuperH）マイコン移行ガイド｜SH-2/SH-4のEOL対策とRXへのリプレース](https://technosphere.co.jp/blog/superh-sh-migration-guide) SH-1/2/2A/3/4系のEOL・NRND対策。コード紛失・SHCコンパイラ・ビッグエンディアン・SCIF/MTU2など、SuperH特有の移行の壁とRX等への移植実績ノウハウを公開しています。 **こんな時に:** SH搭載の産業機器・装置の更新プロジェクトを担当した時。 ## 8. 資料がない資産を復元する ### [ルネサスRL78の逆アセンブル実践ガイド｜仕様書なし旧基板を復元した事例](https://technosphere.co.jp/blog/renesas-rl78-reverse-engineering) 仕様書もソースコードもない15年前の産業用機器を、elfファイルからC言語に復元した実践事例です。レジスタ解析から最新マイコンへの移植までの実際の進め方を公開しています。 **こんな時に:** ドキュメントが失われた機器の保守・移行を諦めかけた時。 ／この内容の受託開発・PoC相談はこちら＼ ### ルネサスマイコンの新規開発・レガシー移行の受託 RL78・RX・RA での新規設計から、H8／SuperH など生産中止品からの移行、仕様書の残っていない基板の解析・復元まで対応します。現物とバイナリしか残っていない案件のご相談も承ります。 [組込み開発サービスを見る](https://technosphere.co.jp/embedded) [マイコン移行の相談をする](https://technosphere.co.jp/contact?src=blog-renesas-guide-body) # ルネサス # RL78 # RX # RA # H8 # マイコン開発 # 開発ガイド --- # RL78・RX・RA どれを選ぶ？ルネサスマイコン選定ガイド｜比較表と用途別の判断軸｜株式会社テクノスフィア > ルネサスの現行マイコン3ファミリ RL78・RX・RA の選び方を解説。ビット幅・CPUコア・クロック帯・開発環境（CS+/e2 studio）・コンパイラ（CC-RL/CC-RX/FSP）・長期供給（PLP）を比較表で整理し、電池駆動・モーター制御・新規Arm設計など用途別の選定フローを組込み受託開発の実務目線で示します。 URL: https://technosphere.co.jp/blog/renesas-mcu-selection-guide ** 目次 1. はじめに：なぜ「ルネサスのどれか」で迷うのか 2. 3ファミリの位置づけ比較表 3. RL78：電池駆動・小規模制御の定番16bit 4. RX：モーター・産業制御を支える独自32bit 5. RA：Armエコシステムで戦う現行主力32bit 6. 開発環境・コンパイラの比較 7. 長期供給プログラム（PLP）の実際 8. 用途別の選定フロー 9. H8・SuperHからの移行先として見た場合 10. Armエコシステム vs 独自アーキテクチャ 11. 迷ったらどうするか：現実的な指針 12. まとめ ## はじめに：なぜ「ルネサスのどれか」で迷うのか 国内の産業機器・計測機器・民生機器の開発で「マイコンはルネサスで」という前提が決まっても、そこから先で必ず出てくるのが**「RL78・RX・RA、どれにするか」**という問いです。3ファミリはいずれも現行の汎用マイコンでありながら、**CPUアーキテクチャも開発環境も設計思想も異なる**ため、単純なスペック表の比較だけでは決めきれません。 さらに悩ましいのは、この選定が**10年、20年単位の意思決定**になることです。産業機器は一度量産に入れば長期にわたって同じマイコンを使い続けるため、性能や単価だけでなく、部品の供給年数、開発ツールの将来性、担当エンジニアを採用・育成できるかまで含めて判断する必要があります。 本記事では、ルネサス公式の情報をもとに3ファミリの位置づけを比較表で整理し、**電池駆動センサー・モーター制御・新規Arm設計といった用途別の判断軸**と、H8・SuperHなどレガシー品からの移行先としての見方をまとめます。 ** テクノスフィアのルネサス開発実績 テクノスフィアは、[RL78のペリフェラル実装](https://technosphere.co.jp/blog/renesas-rl78-peripheral-guide)や[RXでの機器開発](https://technosphere.co.jp/blog/renesas-rx-introduction)、H8など旧世代マイコンからの[移行・再生案件](https://technosphere.co.jp/blog/h8-h8s-migration-guide)を受託開発として手がけています。本記事はその選定支援の実務で使っている判断軸をもとに構成しています。 ## 3ファミリの位置づけ比較表 まず全体像です。数値・対応状況はルネサス公式サイトの各ファミリページ・ツールページに基づいています（2026年7月時点）。 | 項目 | RL78 | RX | RA | | **ビット幅** | 16bit | 32bit | 32bit | | **CPUコア** | ルネサス独自コア （3段パイプライン・ハーバードアーキテクチャ） | ルネサス独自コア （RXv1 / RXv2 / RXv3） | Arm Cortex-M （M23 / M33 / M4 / M85） | | **クロック帯** | 最大48MHz （G23：32MHz、G24：48MHz） | 最大240MHz （RX72M/RX72N） | 32MHz（RA0）～ 最大1GHz（RA8） | | **性能の目安** | 小規模制御向け | 最大6.01 CoreMark/MHz（公式値） | RA8はCortex-M85＋Helium搭載、一部品種にNPU（Ethos-U55） | | **得意分野** | 電池駆動機器・センサー・計測・小型モーター・車載周辺 | モーター/インバータ制御・産業ネットワーク（EtherCAT等）・OA/家電 | IoT・セキュリティ（TrustZone）・新規設計・エッジAI | | **IDE** | CS+ / e² studio | CS+ / e² studio | e² studio（CS+は非対応） | | **主なコンパイラ** | CC-RL / LLVM for RL78 / IAR | CC-RX / GCC for Renesas RX / IAR | GNU Arm Embedded（GCC）/ Arm Compiler / IAR | | **ドライバ・ミドルウェア** | IDEによる周辺ドライバ自動生成 | Smart Configurator＋FITモジュール | FSP（Flexible Software Package） | | **低消費電力性** | 動作時37.5µA/MHz（公式値）。SNOOZE / HALT / STOPモード | 品種依存（省エネ機器向け低消費電力を訴求） | RA0/RA2シリーズが超低消費電力を訴求 | | **ラインアップ規模** | 1,000品種超・8～144ピン・Flash 1KB～768KB | PLP対象だけで700品種超 | RA0/RA2/RA4/RA6/RA8の5シリーズ展開 | ひとことで言えば、**RL78は「電池で長く動かす小規模制御」、RXは「独自コアで実績を積んだ産業向け32bit」、RAは「Armエコシステムに乗る現行の主力32bit」**です。以降、各ファミリを実務目線で掘り下げます。 ## RL78：電池駆動・小規模制御の定番16bit RL78は、3段パイプライン・ハーバードアーキテクチャの**16bit独自CPUコア**を持つ低消費電力マイコンです。公式に**動作時37.5µA/MHz**という数値を掲げ、HALT / STOPに加えて、CPUを起こさずA/D変換やシリアル受信を行える**SNOOZEモード**を備えるのが特徴です。「電池交換なしで年単位」を狙う設計で真価を発揮します。 ラインアップは**1,000品種超、8ピンから144ピン、Flash 1KB～768KB**と非常に幅広く、汎用のG系（G23・G24など）、車載向けF系（F24など）、LCD搭載のL系などが展開されています。クロックは最大でも48MHz（RL78/G23は32MHz、RL78ファミリ最高性能のG24で48MHz）と控えめですが、センサーノード・小型モーター・電源制御・メーター類の制御には十分です。 ### RL78を選ぶ判断材料 - **電池駆動・エナジーハーベスト**：µAオーダーの消費電流管理が最優先の機器 - **コスト重視の小規模制御**：処理は単純だが数量が多い製品（家電・センサー・小物機器） - **8bit世代からの置き換え**：78KやH8/Tinyなど旧世代小規模マイコンの後継 - **ピン数・実装面積の制約**：8～20ピンの小型パッケージが必要な基板 逆に、32bit演算やFPUが常時必要な処理、大きなプロトコルスタックを載せる用途では、最初からRX/RAを検討したほうが手戻りがありません。RL78の周辺機能の実装ノウハウは [RL78ペリフェラル実装ガイド](https://technosphere.co.jp/blog/renesas-rl78-peripheral-guide) で詳しく解説しています。 ## RX：モーター・産業制御を支える独自32bit RXは、ルネサス独自の32bit CPUコア（**RXv1 / RXv2 / RXv3**の3世代）を搭載するファミリです。公式に**最大6.01 CoreMark/MHz**の電力効率・性能を掲げ、最上位クラスのRX72Mは**240MHz動作・4MB Flash/1MB RAM**という構成です。位置づけとしては産業・家電・OA・ICT向けで、特に**モーター/インバータ制御**と、PROFINET・EtherNet/IP・EtherCATといった**産業ネットワーク**対応が公式に強調されています。 開発面では、GUIで周辺設定とドライバコードを生成する**Smart Configurator**と、周辺機能ごとの公式ドライバ部品である**FITモジュール（Firmware Integration Technology）**が整備されており、CS+とe² studioの両IDEが使えます。国内の産業機器では長年の採用実績があり、**設計資産・ノウハウ・実績データが社内に蓄積されている**ことが多いのもRXの現実的な強みです。 ### RXを選ぶ判断材料 - **モーター・インバータ・電源制御**：制御周期がシビアな産業用途での採用実績が豊富 - **既存RX資産の継承**：CC-RXのコード・FITベースのドライバ・検証済みノウハウを活かせる - **産業ネットワーク対応**：EtherCAT等に対応した品種（RX72M等）がある - **SuperH・H8Sからの移行**：同一ベンダーで周辺の考え方が近く、移行の定番先（後述） RXの概要とファミリ構成は [Renesas RXマイコン入門](https://technosphere.co.jp/blog/renesas-rx-introduction) にまとめています。 ## RA：Armエコシステムで戦う現行主力32bit RAは**Arm Cortex-Mコアを採用した32bitファミリ**で、エントリーのRA0/RA2（Cortex-M23）、ミドルレンジのRA4/RA6（Cortex-M33/M4、最大240MHz）、ハイエンドのRA8（**Cortex-M85＋Helium、最大1GHz**、一部品種はNPUのEthos-U55搭載）という構成です。Armv8-M世代のコアでは**TrustZone**が利用でき、ルネサスのセキュリティIPと組み合わせたセキュア設計が公式の訴求点になっています。 ソフトウェア面の中核は**FSP（Flexible Software Package）**です。HAL・ドライバ・ミドルウェアを統合したパッケージで、e² studioに同梱されます。公式にはFSPはRAを中心に、RXや一部RZ MPUへも展開が広がっているとされており、ルネサスが今後のソフトウェア基盤をFSP系に寄せていく方向性がうかがえます。 ### RAを選ぶ判断材料 - **完全新規設計**：過去資産のしがらみがなく、最新の開発体系で始められる - **Arm人材・資産の活用**：STM32等の経験者がそのまま戦力になる。RTOS・プロトコルスタック等のサードパーティ資産が広い - **セキュリティ要件**：TrustZoneによるセキュア/ノンセキュア分離が設計要件にある - **広い性能レンジ**：32MHzの小規模品から1GHz・NPU搭載品まで同一ファミリ内でスケールできる 注意点は開発環境です。**RAはCS+に対応していません**（CS+の対象はRX・RL78・RH850・78K・V850）。CS+文化の長いチームがRAに移る場合、e² studio＋FSPの流儀（コンフィグレータ中心の開発スタイル）への習熟コストを織り込む必要があります。 ## 開発環境・コンパイラの比較 マイコン選定は「チップの性能比較」だけでなく「開発環境ごと選ぶ」意思決定です。ツールチェーンの対応状況を整理します。 | 項目 | RL78 | RX | RA | | **CS+** | ○ 対応 | ○ 対応 | × 非対応 | | **e² studio** | ○ 対応 | ○ 対応 | ○ 対応（FSP同梱、Windows/Linux/macOS） | | **ルネサス純正コンパイラ** | CC-RL | CC-RX | ―（純正Cコンパイラは提供せずArm標準系を利用） | | **無償系ツールチェーン** | LLVM for RL78 | GCC for Renesas RX | GNU Arm Embedded（GCC） | | **サードパーティ** | IAR | IAR | IAR / Arm Compiler | | **コード生成・構成ツール** | IDEの周辺ドライバ自動生成 | Smart Configurator＋FITモジュール | FSPコンフィグレータ | ** 実務での見え方 RL78/RXは「CS+またはe² studio＋純正コンパイラ」という従来型のルネサス開発スタイル、RAは「e² studio＋FSP＋GCC/Arm系」というArm標準に寄せたスタイルです。**純正コンパイラ（CC-RL/CC-RX）は有償ライセンスが基本**（60日の無償評価版あり、期限後はリンクサイズ等の制限付き）である一方、機能安全対応や最適化・サポートの実績が評価されて産業用途で広く使われています。無償で始めるならRL78はLLVM、RXはGCC、RAはGNU Armという選択肢があり、評価段階のコストを抑えられます。 ## 長期供給プログラム（PLP）の実際 産業機器でルネサスが選ばれ続ける大きな理由が、**PLP（Product Longevity Program：長期供給プログラム）**です。ルネサスが2014年1月に発表した枠組みで、対象製品の供給期間を次の3区分で設定しています。 - **最低10年**供給する製品群 - **最低15年**供給する製品群 - **20年以上**供給する製品群 供給期間の起点は、発表時点ですでに量産中だった製品は**2014年1月**、それ以降の製品は**プログラムに登録された時点**です。対象はマイコン/マイクロプロセッサのほかアナログ・パワー等にも及び、車載・産業・インフラ用途を中心に運用されています。どの品種が対象か・期間はいつまでかは**各製品ページのPLP欄で個別に公表**されており、事情により期間が延長される場合や、セキュリティ・法規制などやむを得ない事情では同等品への置き換えで対応される場合があることも明記されています。 ファミリ別に見ると、RXについては公式ブログ（2021年7月）で**汎用RXのLQFPパッケージ品（48～176ピン）は最低15年、BGA/LGA品は10年**のPLP対象（対象700品種超）と案内されています。RAもPLPの対象製品カテゴリに含まれています。 ** 選定時の注意 PLPは「ルネサス製なら自動的に20年供給」という意味ではありません。**対象可否・年数・起点は品種ごとに異なる**ため、量産予定の型番単位で製品ページのPLP表記と生産状況（EOL/NRND情報）を必ず確認してください。H8やSuperHのように、かつての主力ファミリでも世代交代で生産終了に至った例があることは[移行ガイド](https://technosphere.co.jp/blog/h8-h8s-migration-guide)で解説したとおりです。 ## 用途別の選定フロー ここまでの内容を、実際の案件で使っている判断フローに落とし込みます。上から順に確認していくイメージです。 ** 選定フロー（上から順にチェック） 1. **Q1. 電池駆動で、µAオーダーの電流管理が最優先？** → YES：**RL78**を第一候補に（SNOOZE等の省電力機能）。32bit性能や暗号処理も必要なら**RA0/RA2**と比較 2. **Q2. モーター/インバータ制御や産業ネットワークが中核で、社内にRX資産・ノウハウがある？** → YES：**RX**を第一候補に（実績・FIT資産・CC-RXコードの継承） 3. **Q3. 完全新規設計で、Arm人材・サードパーティ資産・TrustZone等のセキュリティを重視？** → YES：**RA**を第一候補に（FSP＋Armエコシステム） 4. **Q4. H8・SuperH・78K等のレガシーからの移行？** → 小規模（H8/Tiny・78K系）は**RL78**、高機能（H8S/H8SX・SH系）は**RX**が定番。Arm資産重視なら**RA/STM32**も検討 5. **Q5. どれにも強く該当しない汎用制御？** → 性能・単価・供給年数（PLP）・チームのスキルセットの4点で比較（下表） | 用途・状況 | 第一候補 | 理由と補足 | | 電池駆動センサー・メーター・小型機器 | **RL78** | 動作時37.5µA/MHz（公式値）とSNOOZEモード。8ピン～の小型パッケージと低単価 | | モーター制御・インバータ・産業装置 | **RX** | 産業向けの採用実績とFIT資産。EtherCAT等の産業ネットワーク対応品種。新規ならRAも比較 | | 新規IoT機器・セキュリティ要件あり | **RA** | TrustZone＋セキュリティIP、FSP、Arm人材の採用しやすさ | | エッジAI・高性能HMI | **RA**（RA8） | Cortex-M85＋Helium、最大1GHz、一部品種にEthos-U55 NPU | | H8/Tiny・78Kなど小規模レガシー置換 | **RL78** | 同一ベンダーで移行しやすく、CS+/e² studioで環境継承 | | H8S/H8SX・SuperHの置換 | **RX** | SCI・MTU等の周辺の考え方が近く移植しやすい。詳細は移行ガイド参照 | 重要なのは、このフローが**「傾向」であって「正解」ではない**ことです。たとえばモーター制御でも新規チームならRAが合理的な場合がありますし、電池駆動でもBLEスタックが必要ならRL78単体では成立しません。フローで第一候補を絞ったうえで、**候補2つの評価ボードで実測比較**するのが失敗しない進め方です。 ## H8・SuperHからの移行先として見た場合 当社への相談で実際に多いのが、「新規選定」ではなく**生産終了が進むH8・SuperHからの移行先**としての3ファミリ比較です。この観点では次の整理になります。 | 移行元 | 定番の移行先 | ポイント | | H8/Tiny・H8/300H（小規模制御） | **RL78** | 低コスト・低消費電力で置換。同一ベンダーで周辺の対応付けがしやすい | | H8S・H8SX（高機能制御） | **RX** | 32bit性能で余裕を持って置換。e² studioで開発環境を統一 | | SuperH（SH-1/SH-2/SH-2A） | **RX** | SCIF→SCI、MTU2→MTUなど周辺の対応関係が取りやすい定番ルート | | 上記でArm資産・エコシステムを重視する場合 | **RA / STM32** | サードパーティ資産・人材確保を優先する場合の選択肢。エンディアンや周辺差異の吸収は必要 | レガシー移行では、移行先の性能よりも**「ビッグエンディアン前提のコード」「旧コンパイラ依存の#pragma」「周辺機能の挙動差」**といった移植の壁のほうが工数を左右します。移行の進め方・注意点は [H8/H8S移行ガイド](https://technosphere.co.jp/blog/h8-h8s-migration-guide) と [SuperH移行ガイド](https://technosphere.co.jp/blog/superh-sh-migration-guide) で詳しく解説していますので、レガシー案件の方はあわせてご覧ください。 ## Armエコシステム vs 独自アーキテクチャ RL78/RX（独自コア）とRA（Armコア）の選択は、技術仕様の比較を超えた**「エコシステムの選択」**です。経営・組織の観点も含めてトレードオフを整理します。 ### Arm（RA）側の強み - **人材採用・教育**：Cortex-M経験者は市場に多く、STM32等からの転向コストが低い。教材・書籍・コミュニティ情報も豊富 - **ミドルウェア・ツール資産**：RTOS、プロトコルスタック、デバッガ、静的解析などサードパーティ対応が広い（IAR・Arm Compiler対応も公式に案内） - **マルチベンダー性**：万一の際、他社Cortex-M品へ移る場合もCPUコア部分の知識・コード資産を活かしやすい - **ルネサスの投資方向**：FSPを軸にした新しいソフトウェア基盤が整備され、RA8（Cortex-M85・最大1GHz・NPU搭載品）など性能面の拡張が続いている ### 独自アーキテクチャ（RL78/RX）側の強み - **実績と資産の継承**：国内産業機器での長い採用実績。検証済みコード・ノウハウ・FIT資産をそのまま使える - **用途特化の作り込み**：RL78の省電力設計（SNOOZE等）、RXのモーター制御・産業ネットワーク対応など、ターゲット用途への最適化 - **開発スタイルの連続性**：CS+・純正コンパイラ（CC-RL/CC-RX）という従来のルネサス流開発をそのまま続けられる - **長期供給の実績**：PLPのもとで長期供給が個別に明示され、産業用途の保守・再生産に対応しやすい ** 実務での考え方 ポイントは「どちらが優れているか」ではなく**「自社の10年後にどちらの資産が残るか」**です。既存製品群がRL78/RXで回っているなら、無理にArmへ寄せる理由は乏しく、逆に組込みチームをこれから作る・拡大する会社にとっては、採用市場の広いArm（RA）で標準化するメリットが大きくなります。 ## 迷ったらどうするか：現実的な指針 それでも決めきれない場合のために、当社が選定支援で実際に使っている指針を挙げます。 1. **既存資産があるなら、まず同系継承を検証する**：RL78/RXの動くコードと検証実績は想像以上の資産です。「新しいから」だけでRAに乗り換えると、移植・再検証コストが利点を食い潰すことがあります 2. **完全新規なら、RAを基準に据えて比較する**：しがらみのない新規設計では、人材・ミドルウェア・性能レンジの広さからRAを基準（デフォルト候補）に置き、省電力特化ならRL78、産業実績重視ならRXが基準を上回るかを比較する形が判断しやすいです 3. **型番単位でPLP・供給状態を確認する**：ファミリの印象ではなく、量産予定型番のPLP表記・生産状況を製品ページで確認します。10年売る製品なら、この確認を怠ると将来のEOL対応（再設計）コストを抱え込みます 4. **候補2つまで絞って評価ボードで実測する**：消費電流・制御周期・ビルド環境の使い勝手は、データシート比較では見えません。数万円の評価ボード2枚と1～2週間のPoCが、量産後の後悔を防ぐ最も安い保険です 5. **チームのスキルセットを設計要素として扱う**：担当者がCS+/CC-RXに習熟しているのか、GCC/Armの経験者なのかは、性能値と同列の選定パラメータです 当社では、要件整理からの候補選定・評価ボードでのPoC・量産設計までを一貫して支援しています。「そもそもどれで見積もるべきか」の段階からご相談いただけます。 ## まとめ ### この記事のまとめ - RL78は16bit独自コアの省電力特化（動作時37.5µA/MHz・SNOOZEモード）。電池駆動・小規模制御の第一候補 - RXは独自32bitコア（RXv1～v3・最大240MHz）。モーター/産業制御の実績とFIT資産・CS+/CC-RXの継承性が強み - RAはArm Cortex-M（M23～M85・最大1GHz）。FSP＋Armエコシステムで新規設計・セキュリティ・エッジAIに強い。ただしCS+は非対応 - 長期供給はPLP（2014年発表、最低10年/15年/20年以上の3区分）で品種ごとに公表。採用前に型番単位で確認する - H8/Tiny→RL78、H8S/SuperH→RXが定番移行ルート。Arm資産重視ならRA/STM32も選択肢 - 迷ったら「既存資産があれば同系継承、完全新規ならRA基準で比較、最後は評価ボードで実測」が現実的 ルネサスマイコンの選定・移行・受託開発でお困りのことがあれば、テクノスフィアにお気軽にご相談ください。RL78・RX世代の実績とArm系の開発経験の両方をもとに、貴社の製品に合った選定からお手伝いします。 マイコン選定のセカンドオピニオン、評価ボードでのPoC、量産設計・レガシー移行まで [組込み制御・マイコン開発](https://technosphere.co.jp/embedded) として対応しています。 ／マイコン選定・受託開発のご相談はこちら＼ ### RL78・RX・RA の選定支援と受託開発 要件整理からのファミリ選定、評価ボードでのPoC、量産設計、H8/SuperHなどレガシーからの移行まで、ルネサスマイコンの受託開発実績で一貫対応します。「どれで見積もるべきか」の段階からご相談ください。 [組込み開発サービスを見る](https://technosphere.co.jp/embedded) [マイコン選定・開発相談](https://technosphere.co.jp/contact) ## よくある質問（FAQ） ** 電池駆動のセンサー機器にはRL78・RX・RAのどれが向いていますか？ 第一候補はRL78です。16bit独自コアで動作時37.5µA/MHz（ルネサス公式値）という低消費電力性を持ち、CPUを起こさず周辺機能だけを動かすSNOOZEモードなど電池駆動向けの省電力機能が充実しています。ただし32bit性能や暗号処理が必要な場合は、超低消費電力を訴求するRA0/RA2シリーズ（Arm Cortex-M23）も比較検討する価値があります。 ** モーター制御・産業機器にはRXとRAのどちらを選ぶべきですか？ 既存のRX資産（FITモジュール・CC-RXコード・実績あるモーター制御ノウハウ）がある場合や、独自コアの実績・国内サポートを重視する場合はRXが有力です。RXは最大240MHz（RX72M）でモーター・インバータ制御や産業ネットワーク向けに広く使われています。一方、完全新規設計でArm人材やサードパーティ資産、TrustZoneなどのセキュリティを重視するならRA（Cortex-M33/M85等）も十分候補になります。単純な優劣ではなく、既存資産と人材で決めるのが現実的です。 ** ルネサスマイコンはどのくらいの期間供給されますか？ ルネサスは2014年1月に長期供給プログラム（PLP）を発表しており、対象製品を最低10年・最低15年・20年以上の3区分で供給する枠組みです（起点は量産中製品が2014年1月、以降はプログラム登録時点）。RXでは汎用品のLQFP品（48～176ピン）が最低15年、BGA/LGA品が10年の対象と公式ブログで案内されています。対象可否と期間は品種ごとに製品ページで公表されているため、採用前に型番単位で確認してください。 ** H8やSuperHからの移行先にはどれを選べばよいですか？ 小規模制御のH8/TinyやH8/300HはRL78、高機能なH8S/H8SXやSuperH（SH-2等）はRXが第一候補です。同じルネサスなので周辺の考え方が近く、e² studioで開発環境を統一できます。Arm資産を重視する場合はRAやSTM32も選択肢です。詳細は[H8/H8S移行ガイド](https://technosphere.co.jp/blog/h8-h8s-migration-guide)・[SuperH移行ガイド](https://technosphere.co.jp/blog/superh-sh-migration-guide)をご覧ください。 ** CS+でRAファミリは開発できますか？ できません。CS+の対象はRX・RL78・RH850・78K・V850ファミリで、RAは対象外です。RAの開発はe² studio（Windows/Linux/macOS対応）が基本で、FSPが同梱されます。コンパイラはGNU Arm Embedded（GCC）、Arm Compiler、IARが利用できます。CS+に慣れたチームは、IDE移行の学習コストも見込んでおきましょう。 # ルネサス # RL78 # RX # RA # マイコン選定 # CC-RL # CC-RX # FSP # 長期供給 # e2 studio ## 次に読む｜ルネサスマイコン記事 - [RL78 RL78 ペリフェラル実装ガイド 省電力16bitの周辺機能を使いこなす](https://technosphere.co.jp/blog/renesas-rl78-peripheral-guide) - [RX Renesas RX マイコン入門 独自32bitコアRXの全体像](https://technosphere.co.jp/blog/renesas-rx-introduction) - [レガシー移行 H8/H8S マイコン移行ガイド H8からRL78/RXへの移行実務](https://technosphere.co.jp/blog/h8-h8s-migration-guide) - [レガシー移行 SH（SuperH）マイコン移行ガイド SH-2/SH-4からRXへの移行実務](https://technosphere.co.jp/blog/superh-sh-migration-guide) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # Renesas RAファミリ入門｜FSPとe2 studioで始めるArmマイコン開発｜株式会社テクノスフィア > ルネサスのArm Cortex-M系主力「RAファミリ」の入門ガイド。RA0/RA2/RA4/RA6/RA8各シリーズの守備範囲、FSP（Flexible Software Package）とe2 studioでのプロジェクト作成〜UARTエコーバック実装、評価ボード（EK/FPB）の選び方、RX・RL78やSTM32との比較まで、組込み開発歴20年超のエンジニアが在籍するテクノスフィアが解説。 URL: https://technosphere.co.jp/blog/renesas-ra-introduction ** 目次 1. はじめに：RAファミリとは 2. RA0/RA2/RA4/RA6/RA8 各シリーズの守備範囲 3. FSP（Flexible Software Package）とは 4. e2 studioでプロジェクトを作成する 5. FSP Configuratorでペリフェラルを設定する 6. 実装例：Lチカ と UARTエコーバック 7. 評価ボードの選び方（EK / FPB） 8. RX・RL78との違いと、RAを選ぶ判断基準 9. STM32経験者から見たRA 10. まとめ ## はじめに：RAファミリとは **RAファミリ**は、ルネサス エレクトロニクスが展開する**Arm Cortex-Mコア搭載の32bitマイコンファミリ**です。ルネサスには独自コアの[RXファミリ](https://technosphere.co.jp/blog/renesas-rx-introduction)や16bitの[RL78ファミリ](https://technosphere.co.jp/blog/renesas-rl78-peripheral-guide)という長い歴史を持つ製品群がありますが、RAはそれらと並ぶ形で2019年に投入され、現在ではエントリ向けのRA0からCortex-M85搭載のハイエンドRA8まで、5つのシリーズを擁するArm系の主力ラインアップに成長しています。 RAの最大の特徴は、**「ルネサスの周辺機能・品質」と「Armエコシステム」の両取り**ができる点です。コアがArmなので、CMSISベースのライブラリ、Arm Keil MDKやIAR Embedded Workbenchといった商用ツール、豊富なRTOS・ミドルウェアがそのまま使えます。一方でタイマやアナログなどの周辺機能、産業向けの長期供給体制はルネサスの流儀そのままです。 本記事では、RAファミリの各シリーズの位置づけを整理したうえで、公式開発環境である**e2 studio**と**FSP（Flexible Software Package）**を使った開発の流れを、実際のコード例（Lチカ・UARTエコーバック）とともに解説します。 ** 弊社での取り組み 弊社はルネサス系（RX・RL78・H8）とArm系（STM32等）の両方に20年超の開発経験を持つエンジニアが在籍しており、既存ルネサス資産を持つお客様のRA移行のご相談にも対応しています。実績の詳細は [組込み開発実績](https://technosphere.co.jp/embedded-achievements) をご覧ください。 ## RA0/RA2/RA4/RA6/RA8 各シリーズの守備範囲 RAファミリは性能・用途別に5つのシリーズで構成されています。ルネサス公式の位置づけを整理すると次のとおりです。 | シリーズ | コア | 最大動作周波数 | 位置づけ・主な用途 | | **RA0** | Cortex-M23 | 32MHz | コスト最重視のバリューライン。超低消費電力で、小型家電・簡易制御などBOMコスト削減が効く用途 | | **RA2** | Cortex-M23 | 64MHz | エントリライン。低消費電力とコストのバランス。RL78の32bit移行先候補としてもよく検討される | | **RA4** | Cortex-M4（FPU付き）/ M33 | 100MHz | 低消費電力と機能のバランス型ミドルレンジ。M33品はTrustZone対応でセキュアIoT端末に向く | | **RA6** | Cortex-M4（FPU付き）/ M33 | 240MHz | ハイパフォーマンス帯の主力。Ethernet等の通信インターフェース統合が最も充実。産業機器・ゲートウェイ向け | | **RA8** | Cortex-M85（＋M33のデュアルコア品あり） | 最大1GHz （製品により360MHz〜1GHz） | 最上位。Helium（ベクトル拡張）対応でDSP/ML処理に強い。グラフィックス（RA8D1）、モーター制御（RA8T1）等の特化品も展開 | ### 注目のRA8シリーズ：業界初のCortex-M85搭載 RA8シリーズは**業界で初めてArm Cortex-M85コアを採用した**マイコン群で、RA8M1/RA8D1/RA8T1は480MHz動作で3000 CoreMark超（6.39 CoreMark/MHz）の性能を公称しています。Cortex-M85は**Helium（MVE：M-Profile Vector Extension）**に対応しており、Cortex-M7比でDSP・機械学習処理を最大4倍高速化できるとされています。さらにエントリライン（RA8E1：360MHz、RA8E2：480MHz）が2024年に、**1GHzのCortex-M85＋250MHzのCortex-M33**を組み合わせられるデュアルコア品RA8M2が2025年に加わり、**Ethos-U55 NPU搭載品**を含めてエッジAI用途への展開が進んでいます。 「マイコンでここまで要るのか」と思われるかもしれませんが、エッジ側での画像・音声のAI推論、モーターの高度なセンサレス制御、HMI（グラフィックス）といった用途では、従来はマイコン＋外付けDSPや小型Linux SoCで組んでいた構成を1チップに収められる可能性があり、選定の幅が大きく広がっています。 ** シリーズ内のスケーラビリティ RAファミリは同一シリーズ内で機能・ピン互換性が高く、小型品の周辺機能は大型品のサブセットになるよう設計されています。「まずRA4で作り、性能が足りなければRA6へ」といったスケールアップがしやすいのも、ファミリとして統一されたFSP（後述）があるおかげです。 ## FSP（Flexible Software Package）とは **FSP（Flexible Software Package）**は、RAファミリ用の公式ソフトウェアパッケージです。STM32でいうSTM32Cube（HAL＋CubeMX）、RXでいうFITモジュール＋Smart Configuratorに相当するもので、次の要素で構成されます。 - **BSP（Board Support Package）：**起動処理・クロック初期化・ピン設定などデバイス/ボード依存部分 - **HALドライバ：**UART・I2C・SPI・タイマ・ADC等のペリフェラルドライバ。`r_sci_uart`、`r_ioport` のようにモジュール単位で追加する - **RTOSサポート：FreeRTOS**と**Azure RTOS**（現Eclipse ThreadX）の両方を公式サポート - **ミドルウェア：**USB（CDC/HID/MSC）、TCP/IP（MQTT対応）、Mbed TLS／NetX Duo Secure等のセキュリティスタック FSPとe2 studioは**ルネサスデバイス向けに無償**で、FSPは**ソースコードがGitHubで公開**されています。中身を追える・差分を確認できる・issueを検索できるという点は、受託開発で「ドライバの挙動を最後まで説明する」必要がある弊社のような立場では非常にありがたいポイントです。 ### FSPのHALドライバの考え方 FSPのAPIは「**R_モジュール名_操作**」という命名で統一されています。たとえばSCI（Serial Communication Interface）をUARTとして使う場合は `R_SCI_UART_Open()` / `R_SCI_UART_Write()` / `R_SCI_UART_Read()` / `R_SCI_UART_Close()` という4つが基本APIです。 もう一つの特徴が**インターフェースと実装の分離**です。UARTには共通インターフェース（`uart_api_t`）が定義されており、実装モジュール（従来SCI向けの `r_sci_uart`、新しいSCI_B搭載グループ向けの `r_sci_b_uart` 等）を差し替えても、アプリケーション側の考え方は共通です。デバイスを乗り換えても資産を活かしやすい構造になっています。 ** モジュール名はStacksタブで確認 同じ「UART」でも、MCUグループによって使うモジュールが `r_sci_uart` か `r_sci_b_uart` かが異なります（関数プレフィックスも `R_SCI_UART_` / `R_SCI_B_UART_` と変わります）。FSP ConfiguratorのStacksタブに表示される候補が、そのデバイスで使える正しいモジュールです。 ## e2 studioでプロジェクトを作成する **e2 studio**はEclipseベースのルネサス公式IDEで、RA向けにはGCC/LLVMツールチェーンが同梱されます。RAプロジェクトの新規作成は次の流れです。 1. **File → New → RA C/C++ Project → Renesas RA** を選択 2. 使用する評価ボード（EK-RA6M4等）またはデバイス型番を選択。ボードを選ぶとピン設定の初期値が自動で入る 3. ツールチェーン・RTOS（なし / FreeRTOS / Azure RTOS）を選択 4. プロジェクトテンプレートを選択。**「Bare Metal - Minimal」**（最小構成）か**「Bare Metal - Blinky」**（LED点滅サンプル入り）が基本 生成されたプロジェクトは、大きく次の3つの領域に分かれます。この区別を最初に押さえておくと迷いません。 ``` MyProject/ ├── src/ │ └── hal_entry.c // ユーザーコードのエントリポイント（ここを書く） ├── ra_gen/ // FSP Configuratorが生成（編集禁止・再生成で上書き） ├── ra_cfg/fsp_cfg/ // Stacksタブの設定が反映されるヘッダ群 ├── ra/ // FSP本体（BSP・HALドライバのソース） └── configuration.xml // FSP Configuratorの設定ファイル ``` ユーザーコードは `src/hal_entry.c` の `hal_entry()` に書きます。`ra_gen/` 以下は「Generate Project Content」のたびに再生成されるため、**直接編集してはいけません**。STM32CubeMXの「USER CODE BEGIN/END」コメント方式と違い、**生成コードとユーザーコードがディレクトリで完全に分離されている**のがFSP流です。 ## FSP Configuratorでペリフェラルを設定する プロジェクトの `configuration.xml` を開くと、GUIの**FSP Configuration**ビューが立ち上がります。画面下部にタブが並んでおり、役割は次のとおりです。 | タブ | 役割 | | **Summary** | プロジェクトの構成要素の一覧 | | **BSP** | デバイス・ボード設定（スタックサイズ、ヒープ等） | | **Clocks** | クロックツリーをグラフィカルに設定 | | **Pins** | ピン機能の割り当て（競合は自動チェック） | | **Interrupts** | ユーザー定義ISRの追加 | | **Event Links** | ELC（イベントリンクコントローラ）の設定 | | **Stacks** | FSPモジュール（ドライバ・ミドルウェア）の追加と設定 | | **Components** | 選択済みモジュールの一覧 | ### UARTを追加する実際の手順 例として、SCIチャネルをUARTとして追加する手順です。 1. **Stacks**タブで **HAL/Common** を選択し、**New Stack** をクリック 2. ドライバ一覧から **Connectivity → UART (r_sci_uart)** を選択 3. Propertiesビューで設定：インスタンス名（`g_uart0`）、チャネル番号、ボーレート（115200等）、**Callback関数名**（例：`user_uart_callback`） 4. **Pins**タブで該当チャネルのTXD/RXDピンを割り当て（ボード選択済みなら初期設定済みのことが多い） 5. 右上の **Generate Project Content** ボタンをクリック Generateすると、`ra_gen/` に `g_uart0`（インスタンス）、`g_uart0_ctrl`（制御構造体）、`g_uart0_cfg`（設定構造体）が生成されます。ユーザーコードからはこの生成済み構造体を使ってAPIを呼ぶだけです。ボーレートやビット構成の計算はすべてConfiguratorが済ませてくれます。 ## 実装例：Lチカ と UARTエコーバック ### 例1：LED点滅（IOPORT＋ソフトウェアディレイ） まずは定番のLチカです。GPIOは `r_ioport` モジュールで、`R_IOPORT_PinWrite()` にポート/ピン定数（`BSP_IO_PORT_xx_PIN_yy`）と出力レベルを渡します。 ``` #include "hal_data.h" void hal_entry(void) { /* LEDピンはボードの回路図で確認して読み替えてください */ const bsp_io_port_pin_t led_pin = BSP_IO_PORT_04_PIN_00; /* ピン設定は生成済みの R_BSP_WarmStart() 内で R_IOPORT_Open() が 実行済みのため、hal_entry で再度 Open する必要はありません */ while (1) { R_IOPORT_PinWrite(&g_ioport_ctrl, led_pin, BSP_IO_LEVEL_HIGH); R_BSP_SoftwareDelay(500, BSP_DELAY_UNITS_MILLISECONDS); R_IOPORT_PinWrite(&g_ioport_ctrl, led_pin, BSP_IO_LEVEL_LOW); R_BSP_SoftwareDelay(500, BSP_DELAY_UNITS_MILLISECONDS); } } ``` `R_BSP_SoftwareDelay()` はBSPが提供するビジーループ遅延で、単位は `BSP_DELAY_UNITS_SECONDS / MILLISECONDS / MICROSECONDS` から選べます。本番コードではタイマ（GPT/AGT）割り込みに置き換えるべきですが、動作確認には十分です。 ### 例2：UARTエコーバック（割り込み＋コールバック） 次に、受信した文字をそのまま送り返すエコーバックです。FSPのUARTドライバは割り込み駆動で、受信・送信完了などのイベントは**Configuratorで登録したコールバック関数**に通知されます。コールバックには `uart_callback_args_t` が渡され、`p_args->event` でイベント種別、`p_args->data` で受信データ（`UART_EVENT_RX_CHAR` 時）を参照します。 ``` #include "hal_data.h" static volatile bool g_rx_flag = false; static volatile uint8_t g_rx_byte = 0U; static volatile bool g_tx_done = true; /* FSP ConfiguratorのCallback欄に指定した関数名。ISRから呼ばれる */ void user_uart_callback(uart_callback_args_t *p_args) { switch (p_args->event) { case UART_EVENT_RX_CHAR: /* 1文字受信 */ g_rx_byte = (uint8_t) p_args->data; g_rx_flag = true; break; case UART_EVENT_TX_COMPLETE: /* 送信完了 */ g_tx_done = true; break; default: break; } } void hal_entry(void) { fsp_err_t err = R_SCI_UART_Open(&g_uart0_ctrl, &g_uart0_cfg); if (FSP_SUCCESS != err) { __BKPT(0); /* 初期化失敗：デバッガで停止 */ } static const uint8_t msg[] = "RA UART echo start\r\n"; g_tx_done = false; R_SCI_UART_Write(&g_uart0_ctrl, msg, sizeof(msg) - 1U); while (1) { if (g_rx_flag && g_tx_done) { g_rx_flag = false; static uint8_t s_tx_byte; /* Writeはノンブロッキングのため送信完了まで生存する変数に */ s_tx_byte = g_rx_byte; g_tx_done = false; R_SCI_UART_Write(&g_uart0_ctrl, &s_tx_byte, 1U); /* エコーバック */ } } } ``` ** R_SCI_UART_Writeはノンブロッキング `R_SCI_UART_Write()` は送信完了を待たずに戻ります。送信中に次のWriteを発行しないよう、上のコードのように `UART_EVENT_TX_COMPLETE` をフラグで受けてから次を送るのが基本です。STM32のブロッキング版 `HAL_UART_Transmit()` の感覚で連続呼び出しすると失敗するので注意してください。 まとまった長さの受信には `R_SCI_UART_Read()` で受信バッファと長さを指定し、完了を `UART_EVENT_RX_COMPLETE` で受ける方法が使えます。公式のサンプル集（GitHubの ra-fsp-examples リポジトリ）には評価ボードごとのUART・I2C・タイマ等のサンプルプロジェクトが揃っており、最初の動作確認はここから始めるのが近道です。 ## 評価ボードの選び方（EK / FPB） RAの公式評価ボードは主に**EK（Evaluation Kit）**と**FPB（Fast Prototyping Board）**の2系統です。いずれもオンボードデバッガを搭載しており、**ボード1枚とUSBケーブルだけで開発を始められます**。 | 型番 | 搭載MCU（コア） | 特徴 | | **FPB-RA4E1** | RA4E1（Cortex-M33） | 低価格の試作向けボード。SEGGER J-Link OB相当のデバッガ回路内蔵。Arduino UNO/Pmodコネクタ、全ピンにスルーホールでアクセス可 | | **FPB-RA6E1** | RA6E1（Cortex-M33） | FPB-RA4E1の上位性能版。構成は同様で、無線モジュールやセンサー接続のサンプルも提供 | | **EK-RA6M4** | RA6M4（Cortex-M33、TrustZone対応） | RA6のフル機能評価キットの定番。Ethernet MAC搭載MCUで、FSP＋e2 studioでの産業・IoT機器評価に向く | | **EK-RA8M1** | RA8M1（Cortex-M85 480MHz） | Cortex-M85/Heliumの性能評価用。コードフラッシュ最大2MB・SRAM 1MB。Pmod/Arduino/mikroBUS/Qwiic/Groveと接続コネクタが充実 | 選び方の目安は次のとおりです。 - **まず触ってみたい・コスト重視：**FPBシリーズ。数千円クラスで入手でき、J-Link OB内蔵なので追加投資ゼロで書き込み・デバッグまで完結 - **製品搭載予定のMCUグループを本格評価：**EKシリーズ。Ethernetや各種センサーコネクタなど周辺回路が揃っており、ミドルウェア込みの評価がしやすい - **DSP/AI・グラフィックスの性能検証：**EK-RA8M1（またはグラフィックス向けEK-RA8D1）でHeliumの効果を実測 ** 量産時の書き込み・デバッグ 評価ボードのオンボードデバッガは便利ですが、量産基板では SWD/JTAG 経由で SEGGER J-Link、Renesas E2/E2 Lite エミュレータ等を使うのが一般的です。基板設計の段階でデバッグコネクタ（SWD）を必ず確保しておきましょう。 ## RX・RL78との違いと、RAを選ぶ判断基準 ルネサスの既存ユーザーにとって最大の関心事は「RX・RL78とどう使い分けるか」でしょう。まず技術面の違いを整理します。 | 項目 | RA | RX | RL78 | | コア | Arm Cortex-M（M23/M4/M33/M85） | ルネサス独自RXコア（32bit CISC） | ルネサス独自（16bit） | | 主なIDE | e2 studio / IAR / Keil MDK（**CS+は非対応**） | e2 studio / CS+ | e2 studio / CS+ | | コンパイラ | GCC / LLVM / IAR / Arm Compiler | CC-RX / GCC 等 | CC-RL / LLVM 等 | | ドライバ/コード生成 | FSP（FSP Configurator） | FITモジュール＋Smart Configurator | コード生成/Smart Configurator | | エコシステム | Armの標準資産（CMSIS、RTOS、ミドルウェア）が広く使える | ルネサス独自・国内実績豊富 | ルネサス独自・低消費電力の定番 | ### 既存RX/RL78資産を持つ会社がRAを検討する判断基準 弊社がお客様と選定する際は、概ね次の基準で整理しています。 - **派生開発・改版が中心 → RX/RL78続行：**実績あるコード・治具・ノウハウの価値は大きく、コア変更のリスクを取る理由がなければ既存ファミリの継続が合理的です。RXもRL78も現行で新製品が出ており、すぐに困ることはありません - **新規設計でセキュリティ要件がある → RAが有力：**TrustZone（Cortex-M33/M85）によるセキュア/ノンセキュア分離など、セキュリティを最初から作り込む設計はRAの得意分野です - **Armエコシステム・人材を重視 → RA：**STM32等のArm経験者がそのまま戦力になり、CMSIS対応のライブラリや商用RTOS・ミドルウェアの選択肢も広がります。採用市場でも「Arm Cortex-M経験者」は独自コア経験者より圧倒的に見つけやすいのが実情です - **DSP/エッジAI性能が必要 → RA8：**Helium対応のCortex-M85クラスは独自コア系にはない選択肢です - **周辺機能の互換性は個別確認：**コアは変わっても、SCI・タイマ等の周辺機能の「思想」はルネサス共通で移行の心理的障壁は低めです。ただしレジスタ互換ではないため、ドライバ層はFSPで書き直しになります なお、さらに古いH8/SHからの移行を検討されている場合は [H8/H8Sマイコン移行ガイド](https://technosphere.co.jp/blog/h8-h8s-migration-guide) も参考にしてください。移行先の選択肢としてRXと並びRAも有力になっています。 ## STM32経験者から見たRA STM32からRAに入るエンジニアは多く、実際、概念の対応関係を押さえればキャッチアップは速いです。 | STM32での概念 | RAでの対応物 | 補足 | | STM32CubeIDE | e2 studio | どちらもEclipseベースで操作感は近い | | STM32CubeMX | FSP Configurator（e2 studio内蔵） | ピン・クロック・ペリフェラルをGUI設定しコード生成 | | HALドライバ（HAL_UART_Transmit等） | FSPモジュール（R_SCI_UART_Write等） | FSPは割り込み駆動が基本。ブロッキング版APIに頼らない設計 | | HAL_UART_RxCpltCallback() | Configuratorで登録するコールバック＋uart_callback_args_t | イベント種別をswitchで振り分ける | | USER CODE BEGIN/END コメント | src/ と ra_gen/ のディレクトリ分離 | 生成コードとユーザーコードが混ざらないのはFSPの利点 | | ST-LINK | SEGGER J-Link OB（評価ボード内蔵）/ E2エミュレータ | SWDデバッグという点は同じ | 体感として大きな違いは2つです。第一に、**FSPは生成コードを一切手で触らせない設計**のため、CubeMXでありがちな「USER CODEコメントの外に書いて再生成で消えた」事故が起きません。第二に、FSPのAPIは**非同期（割り込み駆動）が基本**で、STM32 HALのようなブロッキング版・割り込み版・DMA版の3兄弟という構成ではありません。最初は戸惑いますが、慣れるとイベント駆動で統一されている分、設計は素直になります。 ## まとめ ### この記事のまとめ - RAファミリはルネサスのArm Cortex-M系主力。RA0/RA2（M23・エントリ）〜RA4/RA6（M4/M33・主力）〜RA8（M85/Helium・最上位）の5シリーズ構成 - FSPは無償・GitHubでソース公開のドライバ/ミドルウェア群。FreeRTOS/Azure RTOS対応で、APIはR_SCI_UART_Write()のような統一命名 - 開発フローは「RA C/C++ Project作成 → FSP ConfiguratorのStacksタブでモジュール追加 → Generate Project Content → hal_entry.cに実装」 - 入門はFPBシリーズ（J-Link OB内蔵・低価格）、本格評価はEKシリーズが定番 - 既存RX/RL78資産があるなら無理に乗り換える必要はない。新規設計でセキュリティ・Armエコシステム・エッジAI性能を重視するならRAが有力 RAマイコンを使った新規開発、RX・RL78・H8からの移行検討でお困りのことがあれば、弊社にお気軽にご相談ください。デバイス選定から設計・実装・量産対応まで、マイコン開発歴20年超のエンジニアが一貫してサポートします。 RAマイコンの試作・量産設計、既存ルネサス資産（RX・RL78・H8）からの移行、FSPベースのドライバ開発まで [組込み制御・マイコン開発](https://technosphere.co.jp/embedded) として対応しています。 ／この内容の受託開発・PoC相談はこちら＼ ### Renesas RA / RX / RL78 の受託開発・移行支援 RAマイコンの新規開発、FSPベースのドライバ・RTOS設計、RX・RL78・H8からのリプレースまで、ルネサス系マイコン開発歴20年超のエンジニアが一貫対応します。デバイス選定のご相談からお気軽にどうぞ。 [組込み開発サービスを見る](https://technosphere.co.jp/embedded) [RA開発・移行の相談](https://technosphere.co.jp/contact) ## よくある質問（FAQ） ** RAファミリとRXファミリはどちらを選ぶべきですか？ 既存のRX資産（コード・治具・ノウハウ）を活かす派生開発ならRXの継続が合理的です。一方、新規設計でArmエコシステム（ツール・ミドルウェア・エンジニア確保）やTrustZone等のセキュリティ機能を重視する場合はRAが有力です。RXの詳細は [Renesas RXマイコン入門](https://technosphere.co.jp/blog/renesas-rx-introduction) をご覧ください。 ** FSP（Flexible Software Package）は無償で使えますか？ はい。FSPとe2 studioはルネサスデバイス向けに無償で利用でき、FSPのソースコードはGitHubで公開されています。HALドライバに加え、FreeRTOSとAzure RTOSのサポート、USB・TCP/IP・Mbed TLSなどのミドルウェアも含まれます。 ** STM32の開発経験はRA開発に活かせますか？ 活かせます。STM32CubeMXに相当するのがe2 studio内蔵のFSP Configurator、HALドライバに相当するのがFSPのHALモジュール（`R_SCI_UART_Write()` 等）です。ピン設定・クロック設定・コード生成という開発フローはほぼ同じ発想で、Cortex-Mコアなのでデバッグ手法（SWD、CMSIS）も共通です。 ** RAマイコンの開発にCS+は使えますか？ 使えません。CS+が対応するのはRH850・V850・RX・RL78・78K系で、RAファミリは対象外です。RAの開発環境はe2 studio（GCC/LLVM同梱）のほか、RA Smart Configuratorを併用したIAR Embedded WorkbenchやArm Keil MDKが利用できます。 ** RA入門用の評価ボードはどれを選べばよいですか？ 低コストに始めるならFPB（Fast Prototyping Board）シリーズ（FPB-RA6E1、FPB-RA4E1等）がおすすめです。J-Link OB相当のデバッガ回路を内蔵し、追加ツールなしで書き込み・デバッグができます。フル機能評価ならEKシリーズ（EK-RA6M4、EK-RA8M1等）を選びます。 ** RA8シリーズのコアは何ですか？AI処理はできますか？ RA8シリーズはArm Cortex-M85コアを採用し、Helium（MVE）によるDSP/ML処理の高速化に対応します。360〜480MHz品に加え、1GHz Cortex-M85＋250MHz Cortex-M33のデュアルコア品（RA8M2）や、Ethos-U55 NPU搭載品も展開されており、エッジAI用途にも使えます。 # Renesas RA # FSP # e2 studio # Cortex-M85 # Armマイコン # UART # ルネサス # マイコン開発 ## 次に読む｜ルネサス マイコン シリーズ記事 - [ルネサス シリーズ Renesas RX マイコン入門｜SCI・RIIC・MTU・ADCをFITモジュールで実装 独自コアRXの全体像とFITでの周辺機能実装ガイド](https://technosphere.co.jp/blog/renesas-rx-introduction) - [ルネサス シリーズ Renesas RL78 ペリフェラル実装ガイド UART・I2C・タイマ・ADCをSmartConfiguratorで実装](https://technosphere.co.jp/blog/renesas-rl78-peripheral-guide) - [マイコン移行 H8/H8S マイコン移行ガイド｜EOL対策とリプレース 旧日立・ルネサスH8資産の延命と移行先の選び方](https://technosphere.co.jp/blog/h8-h8s-migration-guide) - [開発実績 組込み制御・マイコン開発 実績紹介 ルネサス系・Arm系含む20年超の開発事例](https://technosphere.co.jp/embedded-achievements) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # Renesas RL78 ペリフェラル実装ガイド｜UART・I2C・タイマ・ADCをSmartConfiguratorで実装｜株式会社テクノスフィア > ルネサス RL78 の UART（SAU）・I2C（IICA）・タイマ（TAU）・12bit ADC を Smart Configurator のコード生成で実装する手順。CS+/e2 studio/CC-RL と STOP/SNOOZE まで解説。 URL: https://technosphere.co.jp/blog/renesas-rl78-peripheral-guide ** 目次 1. はじめに：RL78が日本の組込みで選ばれる理由 2. 開発環境とSmart Configurator 3. UART通信の実装（SAU） 4. I2C通信の実装（IICA / 簡易I2C） 5. タイマ（TAU）でPWM・インターバル 6. 12bit A/Dコンバータの実装 7. 低消費電力モード（HALT/STOP/SNOOZE） 8. よくあるトラブルと対策 9. まとめ ## はじめに：RL78が日本の組込みで選ばれる理由 **RL78**は、ルネサス エレクトロニクスの16bit低消費電力マイコンファミリです。産業機器・白物家電・車載のボディ系・センサーノードなど、日本の組込み機器で非常に広く採用されています。1.6〜5.5Vの広い動作電圧、豊富なフラッシュ容量ラインナップ、そして優れた低消費電力性能が特徴です。 ARM Cortex-M系のSTM32などと比べると情報が英語中心になりがちなSTM32に対し、RL78は**日本語ドキュメントとサンプルが充実**しており、国内の量産案件で扱いやすいのも大きな利点です。本記事では、RL78でもっとも使用頻度の高い**UART・I2C・タイマ・ADC**の4つのペリフェラルを、Smart Configuratorのコード生成を活用して実装する方法を解説します。 ** 弊社での活用実績 テクノスフィアでは RL78/G13・G14・G23 を用いた計測機器・センサーノード・制御基板の [組込み受託開発](https://technosphere.co.jp/embedded-achievements) を多数手がけています。生産終了したRL78基板の [逆アセンブル・再構築](https://technosphere.co.jp/blog/renesas-rl78-reverse-engineering) 実績もあり、本記事は実案件のノウハウをもとに構成しています。 ## 開発環境とSmart Configurator RL78の開発では、以下の組み合わせが標準です。 | 要素 | 選択肢 | 備考 | | 統合開発環境 | **CS+** / **e2 studio** | CS+は純正・軽量、e2 studioはEclipseベースでRX/RAと統一可 | | コンパイラ | **CC-RL** | ルネサス純正Cコンパイラ。無償版は容量制限あり | | コード生成 | **Smart Configurator** | GUIでペリフェラルを設定し初期化コードを自動生成 | | デバッガ | E2 Lite / E2 | オンチップデバッグエミュレータ | Smart Configurator（旧コード生成／Applilet）は、クロック・端子・ペリフェラルをGUIで設定すると、`R_Config_xxx_Create()` や `R_Config_xxx_Start()` といった初期化・制御関数を自動生成してくれます。手書きでレジスタを叩く必要がほぼなくなり、開発工数を大幅に削減できます。 ** 命名規則について Smart Configuratorが生成する関数名は `R_Config_<周辺>_<動作>` の形式です（例：`R_Config_UART0_Start`）。本記事のコードはこの生成コードを呼び出す前提で記載しています。世代や設定により関数名が若干異なる場合があります。 ## UART通信の実装（SAU） RL78のUART・SPI・簡易I2Cは、**SAU（Serial Array Unit）**という共通のシリアルユニットで実現します。Smart ConfiguratorでSAUのチャネルを「UART」モードに設定し、ボーレートと端子を割り当てると、送受信関数が生成されます。 ### UART送信 ``` #include "r_cg_macrodriver.h" #include "r_cg_userdefine.h" #include "Config_UART0.h" /* UART0 を開始（Smart Configurator 生成）*/ R_Config_UART0_Start(); /* 文字列を送信 */ uint8_t tx_buf[] = "Hello RL78!\r\n"; R_Config_UART0_Send(tx_buf, sizeof(tx_buf) - 1); /* 送信完了は割り込みコールバックで通知される */ ``` ### UART受信（割り込み） 受信はリングバッファに溜め、コールバック内で処理するのが定石です。Smart Configuratorが生成する受信完了コールバック `r_Config_UART0_callback_receiveend()` をユーザーコード領域に実装します。 ``` static volatile uint8_t g_rx_data; /* 受信開始（1バイトずつ受信） */ R_Config_UART0_Receive(&g_rx_data, 1); /* 受信完了コールバック（自動生成のひな型に追記）*/ void r_Config_UART0_callback_receiveend(void) { /* g_rx_data に1バイト受信済み。処理後、再度受信を仕掛ける */ ring_buffer_push(g_rx_data); R_Config_UART0_Receive(&g_rx_data, 1); } ``` ** 注意 SAUのチャネル割り当ては端子（ピン）と密接に紐づきます。基板設計時に「使いたいUART/SPI/I2Cが同じSAUユニット内で競合しないか」を必ず確認してください。SAUのユニット数（SAU0／SAU1）やチャネル数は品種によって異なる（小型品はSAU0のみ等）ため、対象デバイスのデータシートで構成を確認してください。 ## I2C通信の実装（IICA / 簡易I2C） RL78のI2Cには2種類あります。用途で使い分けます。 | 方式 | 特徴 | 向く用途 | | **簡易I2C（SAU）** | SAUのチャネルをI2Cモードで使用。マスタ送受信が中心 | センサー・EEPROMへの単純アクセス | | **IICA（専用ユニット）** | アービトレーション・クロックストレッチ・マルチマスタ対応 | 本格的なI2Cバス、スレーブ動作、複数マスタ環境 | 温湿度センサーやEEPROMを1つ読むだけなら簡易I2Cで十分です。バス上に複数マスタがいる、スレーブとして応答する、といった場合はIICAを選びます。 ``` #include "Config_IICA0.h" #define SENSOR_ADDR (0x48 << 1) /* 7bitアドレスを左シフト */ static uint8_t reg = 0x00; static uint8_t rx[2]; /* レジスタ0x00 を指定して2バイト読み出す */ R_Config_IICA0_Master_Send(SENSOR_ADDR, ®, 1, 0); /* 第4引数=継続フラグ */ R_Config_IICA0_Master_Receive(SENSOR_ADDR, rx, 2, 0); /* 完了は IICA のコールバックで判定 */ int16_t value = (rx[0] << 8) | rx[1]; ``` ** プルアップ抵抗を忘れずに I2CのSDA/SCLは外部プルアップ抵抗（一般に2.2k〜10kΩ）が必須です。RL78内蔵プルアップでは不足することが多く、通信が不安定になる主因です。波形が鈍る場合は抵抗値を下げます。 ## タイマ（TAU）でPWM・インターバル **TAU（Timer Array Unit）**は複数チャネルを持つ汎用タイマで、以下のような用途に使えます。 - **インターバルタイマ**：一定周期で割り込みを発生（制御周期・ソフトタイマの土台） - **PWM出力**：マスタチャネルで周期、スレーブチャネルでデューティを設定し、LED調光やモーター制御へ - **入力パルス測定**：外部信号の周期・パルス幅を計測（流量計・回転数センサー） - **外部イベントカウント**：エンコーダや接点入力のカウント ``` #include "Config_TAU0_0.h" /* 1ms インターバルタイマを開始 */ R_Config_TAU0_0_Start(); /* インターバル割り込みコールバック（自動生成）*/ void r_Config_TAU0_0_interrupt(void) { g_msec_tick++; /* ソフトウェアタイマのカウントアップ */ if (g_msec_tick % 100 == 0) { g_flag_100ms = 1; /* 100ms ごとの処理要求 */ } } ``` PWMを使う場合は、Smart Configuratorで「インターバルタイマ（PWM出力）」を選び、マスタ／スレーブのチャネルを割り当てます。デューティ比は `R_Config_TAU0_n_Set_PWM_Duty()` 相当の関数や、コンペアレジスタへの直接書き込みで動的に変更できます。 ## 12bit A/Dコンバータの実装 RL78は12bit逐次比較型（SAR）A/Dコンバータを内蔵します。温度センサー・電圧監視・アナログ入力の読み取りに使います。Smart ConfiguratorでA/D変換チャネル・基準電圧・変換モード（ワンショット／連続）を設定します。 ``` #include "Config_ADC.h" uint16_t ad_value; R_Config_ADC_Start(); R_Config_ADC_Set_OperationOn(); /* 変換完了コールバック（自動生成）*/ void r_Config_ADC_interrupt(void) { R_Config_ADC_Get_Result_12bit(&ad_value); /* 例：基準電圧 3.3V のとき電圧[mV] に換算 */ uint32_t mv = ((uint32_t)ad_value * 3300) / 4095; } ``` ** 精度を出すコツ サンプリング時間を十分に確保し、アナログ入力源のインピーダンスを下げることが精度の鍵です。高インピーダンス源はOPアンプでバッファするか、サンプリング時間を延ばします。基準電圧のノイズ対策（デカップリング）も忘れずに。 ## 低消費電力モード（HALT/STOP/SNOOZE） RL78が選ばれる最大の理由のひとつが低消費電力性能です。電池駆動機器では、いかにCPUを止めている時間を長くするかが平均電流を決めます。 | モード | 動作 | 復帰要因 | | **HALT** | CPU停止、周辺は動作継続 | 任意の割り込み | | **STOP** | 高速発振も停止し最小消費電流 | 外部割り込み・一部周辺の割り込み | | **SNOOZE** | CPUを起こさずADC変換やUART/CSI受信を実行 | 条件成立でHALT/STOPへ自動復帰 | **SNOOZEモード**はRL78の強力な機能です。たとえば「STOP中に一定周期で起き、CPUを起こさずにADCで電圧を測り、しきい値を超えたときだけCPUを起こす」といった動作が可能で、センサーノードの平均電流を桁違いに下げられます。 ``` /* メインループの基本形：処理がなければ眠る */ while (1) { if (g_flag_100ms) { g_flag_100ms = 0; do_periodic_task(); } /* やることが無ければ HALT で待機（割り込みで復帰）*/ HALT(); } ``` ## よくあるトラブルと対策 | 症状 | 主な原因 | 対策 | | UARTが文字化けする | ボーレート誤差・動作クロック設定ミス | 高速オンチップオシレータの周波数とSAUの分周設定を確認。誤差±2%以内に収める | | I2Cが応答しない（NACK） | アドレスのシフト忘れ・プルアップ不足 | 7bitアドレスを左1bitシフト。プルアップ抵抗を実装し波形を確認 | | STOP復帰後に動作が不安定 | 発振安定待ち不足 | STOP復帰後は発振安定時間を確保してから周辺を再開 | | 消費電流が下がらない | 未使用端子の処理不足・周辺停止漏れ | 未使用端子を入力プルアップ等で固定。使わない周辺はクロック供給を停止 | | 書き込みできない | オプションバイト・オンチップデバッグ設定 | セキュリティ設定とデバッガ接続（RESET/TOOL端子）を確認 | ## まとめ ### この記事のまとめ - RL78は16bit低消費電力マイコンで、日本の産業・車載・家電で広く採用されている - UART・SPI・簡易I2CはSAU、本格的なI2CはIICAで実装する - Smart Configuratorのコード生成で `R_Config_xxx` 関数が生成され、開発工数を削減できる - TAUはインターバル・PWM・パルス測定に、12bit ADCは電圧監視・センサー読み取りに使う - HALT/STOP/SNOOZEを使い分けることで電池駆動機器の平均電流を大幅に下げられる RL78を使った組込みシステム開発・量産設計でお困りのことがあれば、テクノスフィアにお気軽にご相談ください。新規開発はもちろん、生産終了基板の再設計やSTM32など他マイコンへの移植も対応します。 RL78 を使ったセンサー・計測機器・制御基板の試作・量産設計、既存基板の RL78 化や移行も [組込み制御・マイコン開発](https://technosphere.co.jp/embedded) として対応しています。 ／この内容の受託開発・PoC相談はこちら＼ ### Renesas RL78 受託開発・量産設計 RL78を使った計測機器・センサーノード・制御基板の設計から量産、生産終了基板の再設計・他マイコン移植まで、組込み開発歴20年超のエンジニアが一貫対応します。 [組込み開発サービスを見る](https://technosphere.co.jp/embedded) [RL78受託開発・量産相談](https://technosphere.co.jp/contact) ## よくある質問（FAQ） ** RL78のUART・I2C・SPIはどのペリフェラルで実装しますか？ UART・SPI・簡易I2CはSAU（Serial Array Unit）で実装します。アービトレーションやクロックストレッチが必要な本格的なI2Cマスタ/スレーブはIICA（専用I2Cユニット）を使います。Smart Configuratorでチャネルと動作モードを選ぶと対応する `R_Config_xxx` 関数が自動生成されます。 ** 開発環境はCS+とe2 studioのどちらを使うべきですか？ どちらもCC-RLとSmart Configuratorを利用できます。CS+は純正・軽量で日本語情報が豊富、e2 studioはEclipseベースでRX/RAなど他のルネサスデバイスと操作を統一できます。複数デバイスを扱うならe2 studioが扱いやすいです。 ** RL78で消費電力を下げるには？ 処理がないときはHALT/STOPモードに遷移させ割り込みで復帰させます。SNOOZEモードを使うとCPUを起こさずにADC変換やシリアル受信を実行でき、電池駆動機器の平均電流を大幅に下げられます。 ** STM32など他マイコンとどう違いますか？ RL78は16bitで超低消費電力・低コストに強く、日本語情報が豊富で国内量産に向きます。32bitの高性能処理やARMエコシステムが必要ならSTM32が有利です。要件に応じて [STM32](https://technosphere.co.jp/blog/stm32-uart-i2c-can) と使い分けるのが実務的です。 ## 次に読む｜マイコン記事 - [Renesas シリーズ Renesas RX マイコン入門 32bit産業機器の主力。SCI/FIT/MTUを解説](https://technosphere.co.jp/blog/renesas-rx-introduction) - [Renesas シリーズ RL78 逆アセンブル・再構築 ソース紛失したレガシー基板の復元事例](https://technosphere.co.jp/blog/renesas-rl78-reverse-engineering) - [STM32 シリーズ STM32 UART・I2C・SPI・CAN 実装ガイド ARM系マイコンの通信実装と比較に](https://technosphere.co.jp/blog/stm32-uart-i2c-can) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # ルネサスRL78の逆アセンブル実践ガイド｜仕様書なし旧基板を復元した事例｜テクノスフィア > ルネサスRL78マイコンの逆アセンブル手順を実機ベースで解説。仕様書もソースコードもない15年前の産業用機器を、elfファイルからC言語に復元した実践事例。レジスタ解析・最新マイコン移植まで公開。 URL: https://technosphere.co.jp/blog/renesas-rl78-reverse-engineering ## 背景：仕様書もソースコードもない状態からの再開発 製造業のお客様から「15年前に開発した産業用計測機器の制御基板を再生産したいが、仕様書もソースコードも紛失してしまった。残っているのは実機と、コンパイル済みのelfファイルのみ」というご相談をいただきました。 対象のマイコンは**ルネサス RL78/G13**。当時のメーカー担当者は既に退職しており、開発環境も失われている状態でした。部品の生産終了も迫っており、最新のマイコン（[STM32F4シリーズ](https://technosphere.co.jp/blog/stm32-uart-i2c-can)）への移植も同時に求められました。 ### 本記事の対象読者 - 仕様書なしのレガシーシステム再開発を検討している方 - バイナリ解析・逆アセンブル技術に興味がある組込みエンジニア - 古いマイコンから最新マイコンへの移植を計画している方 ## 払拭すべき3つの課題 このプロジェクトを進めるにあたり、以下の課題を整理しました。 ### 1. アルゴリズムの特定とデータテーブルの存在 計測機器の核心である「制御ロジック」が、プログラム上の計算によるものか、あるいはROM/EEPROMに格納された独自のデータテーブルによるものかを特定する必要がありました。 elfファイル内にデータテーブルが不完全な場合、実機からのメモリダンプが必要になります。 ### 2. ハードウェア依存のタイミング調整 15年前のマイコン特有の処理待ち（ディレイループ）が、現在の高速なマイコンでは再現できないリスクがあります。 計測機器としての「正確なパルス幅・サンプリング周期」を担保するため、実機の出力波形をオシロスコープで実測し、復元コードとのベンチマークを行う工程が不可欠でした。 ### 3. 周辺回路仕様の把握 GPIOポートの先にあるアナログ回路（増幅器・フィルター等）の特性はバイナリからは読み取れません。 基板上の回路構成を実機から解析し、レジスタ設定値との整合性を確認する作業が必要でした。 ## 逆アセンブルの実践手順 以下の手順でelfファイルからC言語への復元を進めました。 ### ステップ1：elfファイルの解析 ``` # RL78用objdumpでディスアセンブル rl78-elf-objdump -d firmware.elf > disasm.txt # シンボルテーブルを抽出 rl78-elf-nm firmware.elf > symbols.txt # セクション情報を確認 rl78-elf-readelf -S firmware.elf ``` RL78のアーキテクチャ固有のレジスタ名（P0, ADM, TDRなど）を手がかりに、ペリフェラル設定箇所を特定しました。 ### ステップ2：フローチャートの作成 ディスアセンブル結果から、以下の構造を読み取りました： - **初期化ルーチン**：クロック設定、GPIO設定、ADC設定 - **メインループ**：センサーデータ取得 → 演算処理 → 出力制御 - **タイマー割り込みハンドラ**：10ms周期でのサンプリング制御 - **UART通信ハンドラ**：外部PCとのデータ送受信 ### ポイント：レジスタ操作の解読 RL78のレジスタは8ビット単位で直接操作されており、以下のようなアセンブラ命令が頻出しました。 ``` ; P0レジスタ（ポート0）のビット3をセット SET1 P0.3 ; ADMレジスタ（AD変換モード）に0x80を書き込み MOV ADM, #80h ``` これらをルネサスのハードウェアマニュアルと照合し、C言語のビット操作マクロに変換しました。 ### ステップ3：C言語への復元 解析結果をもとに、以下のようなC言語コードを復元しました。 ``` // RL78/G13 ADC初期化（復元コード） void ADC_Init(void) { ADCEN = 1; // ADコンバータ有効化 ADM0 = 0x00; // ソフトウェアトリガモード ADM1 = 0x20; // 10ビット分解能 ADM2 = 0x00; // Vref = VDD ADCE = 1; // 比較器有効化 } // タイマー割り込みハンドラ（10ms周期） __attribute__((interrupt)) void INTTM00(void) { static uint16_t adc_value; // ADC開始（ADCS=1で変換開始。ADCSは「変換中=1」を示すビット） ADCS = 1; while(ADCS); // 変換中フラグが下がる（=完了）まで待つ adc_value = ADCR; // 結果読み取り // ※本来は変換完了割り込み(INTAD)で受けるのが定石。ここでは簡易にポーリング // データ処理（省略） process_sensor_data(adc_value); } ``` ### ステップ4：実機波形との突合 復元したコードをRL78評価ボードで動作させ、以下の検証を行いました： - オシロスコープで実機とのGPIO出力波形を比較 - ADC値のサンプリングタイミングを実測 - UART通信のボーレートとデータフォーマットを確認 この工程で、タイマー設定値の微調整や、ディレイループの補正を実施しました。 ## STM32への移植 復元したC言語コードを、最新のSTM32F4マイコンに移植しました。 ### 移植のポイント | 項目 | RL78/G13 | STM32F4 | | クロック周波数 | 32MHz | 168MHz（5倍高速） | | ADC分解能 | 10ビット | 12ビット | | タイマー | 16ビットタイマアレイユニット（TAU） | 16/32ビット高精度タイマー | | 開発環境 | CS+ (ルネサス) | STM32CubeIDE + HAL | クロック周波数が5倍になったため、ディレイループを以下のように調整しました。 ``` // RL78版（32MHz想定） void delay_us(uint16_t us) { for(uint16_t i = 0; i < us * 8; i++) { __nop(); } } // STM32版（168MHz想定） // ※STM32 HAL標準にus単位の遅延関数は無い（HAL_Delay()はms単位）。 // DWTサイクルカウンタやタイマで自作したus遅延を使う。 void delay_us(uint16_t us) { uint32_t start = DWT->CYCCNT; uint32_t ticks = us * (SystemCoreClock / 1000000U); while ((DWT->CYCCNT - start) < ticks) { __NOP(); } } ``` ## 成果：完全な動作再現に成功 プロジェクトは以下の成果を得ました： - **elfファイルから完全なC言語復元**：約2,000行のコードを復元 - **実機との波形一致率99%以上**：オシロスコープでの検証 - **STM32への移植完了**：開発期間3ヶ月（通常の新規開発の半分） - **暫定仕様書の作成**：今後のメンテナンス用ドキュメント整備 ### お客様の声 > 「諦めていた製品の再生産が実現できました。復元された仕様書により、今後の改良も可能になりました。テクノスフィアさんの逆アセンブル技術は驚異的です。」 — 製造業A社 開発部長 ## まとめ：レガシーシステムの逆アセンブルで押さえるべきポイント 本プロジェクトを通じて得られた知見をまとめます。 ### 技術的なポイント - **ハードウェアマニュアルの徹底活用**：レジスタ操作の意味を正確に把握 - **実機検証の重要性**：波形測定によるタイミング検証は必須 - **段階的な復元**：初期化→メインループ→割り込みの順で解析 - **ツールの選定**：objdump, IDA Pro, Ghidraなど複数ツールを併用 ### プロジェクト管理のポイント - **初期調査フェーズの確保**：実現可能性を見極める期間が重要 - **実機の確保**：動作する実機があれば成功率が飛躍的に向上 - **段階的なマイルストーン設定**：解析→復元→検証→移植の各フェーズで区切る ## テクノスフィアの逆アセンブル・レガシーシステム再構築サービス 弊社では、仕様書やソースコードがない古い組込み機器の再開発に対応しています。 - **対応マイコン**：Z80, 8051, AVR, ARM, ルネサス, TI, 日立系MCU - **対応ファイル形式**：elf, hex, bin, s19など - **実績アーキテクチャ**：8ビット〜32ビット幅広く対応 「古い機器を現代に蘇らせたい」「部品廃止で困っている」といったご相談は、[お問い合わせフォーム](https://technosphere.co.jp/contact)からお気軽にご連絡ください。 ／この内容の受託開発・PoC相談はこちら＼ ### レガシー組込み機器の逆アセンブル・再構築 RL78 / Z80 / 8051 / 旧ルネサス系の制御基板を、ソースコードが無い状態から復元・再開発します。部品廃止対応・基板リプレース・最新マイコンへのポーティングまで、テクノスフィアにお任せください。 [組込み開発サービスを見る](https://technosphere.co.jp/embedded) [EOL移行・逆アセン相談](https://technosphere.co.jp/contact) ## 関連記事 ### [組込システム ルネサスマイコン開発ガイド 総目次](https://technosphere.co.jp/blog/renesas-mcu-guide) ### [組込システム STM32マイコンのUART・I2C・SPI・CAN通信 実装ガイド](https://technosphere.co.jp/blog/stm32-uart-i2c-can) ### [組込システム Raspberry PiでセンサーIoT：温湿度データをクラウド送信](https://technosphere.co.jp/blog/raspberry-pi-sensor-iot) ### [サービス 組込み制御・マイコン開発サービス](https://technosphere.co.jp/embedded) ### 組込み開発のご相談 レガシーシステムの再構築から最新マイコンの開発まで、お気軽にご相談ください。 [お問い合わせ](https://technosphere.co.jp/contact) ### カテゴリ - [組込システム](https://technosphere.co.jp/blog/?cat=組込システム) - [AI・機械学習](https://technosphere.co.jp/blog/?cat=AI・機械学習) - [クラウド](https://technosphere.co.jp/blog/?cat=クラウド) ### タグ [逆アセンブル](https://technosphere.co.jp/blog/?tag=%E9%80%86%E3%82%A2%E3%82%BB%E3%83%B3%E3%83%96%E3%83%AB) [ルネサス RL78](https://technosphere.co.jp/blog/?tag=%E3%83%AB%E3%83%8D%E3%82%B5%E3%82%B9+RL78) [レガシーシステム](https://technosphere.co.jp/blog/?tag=%E3%83%AC%E3%82%AC%E3%82%B7%E3%83%BC%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0) [マイコン移植](https://technosphere.co.jp/blog/?tag=%E3%83%9E%E3%82%A4%E3%82%B3%E3%83%B3%E7%A7%BB%E6%A4%8D) [リバースエンジニアリング](https://technosphere.co.jp/blog/?tag=%E3%83%AA%E3%83%90%E3%83%BC%E3%82%B9%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0) [組込み再開発](https://technosphere.co.jp/blog/?tag=%E7%B5%84%E8%BE%BC%E3%81%BF%E5%86%8D%E9%96%8B%E7%99%BA) --- # Renesas RX マイコン入門｜SCI・RIIC・MTU・ADCをFITモジュールで実装する32bit組込み開発｜株式会社テクノスフィア > ルネサス RX ファミリ（RX100/200/600/700）の概要と SCI/RIIC/MTU/12bit ADC の実装を、FIT モジュールと Smart Configurator・e2 studio で進める方法を実例で解説。 URL: https://technosphere.co.jp/blog/renesas-rx-introduction ** 目次 1. はじめに：RXファミリとは 2. RX100/200/600/700の選び方 3. 開発環境・FIT・Smart Configurator 4. SCIでUART通信 5. RIICでI2C通信 6. MTUでPWM・タイマ 7. 12bit ADCの実装 8. よくあるトラブルと対策 9. まとめ ## はじめに：RXファミリとは **RX**は、ルネサス エレクトロニクスが独自開発した32bit CISCコア（RXv1/v2/v3）を搭載するマイコンファミリです。高い演算性能とコード効率、FPU内蔵による浮動小数点演算、豊富な内蔵周辺を備え、**日本の産業機器・FA・計測・HMI・モーター制御**で広く採用されています。 16bitの [RL78](https://technosphere.co.jp/blog/renesas-rl78-peripheral-guide) が小規模・超低消費電力向けなのに対し、RXは「もう少し性能と容量が欲しい」「イーサネットやTFT表示を付けたい」「モーターを回したい」といった**中〜大規模な組込みシステム**に向きます。本記事ではRXの全体像と、周辺機能をFITモジュールで実装する流れを入門者向けに解説します。 ** 弊社での活用実績 テクノスフィアでは RX62N・RX631・RX65N などを用いた産業用制御装置・計測機器・通信ゲートウェイの [受託開発実績](https://technosphere.co.jp/embedded-achievements) があります。RXとRL78を製品グレードで使い分ける設計も多数手がけています。 ## RX100/200/600/700の選び方 | シリーズ | 位置づけ | 代表品種・特徴 | | **RX100** | 低消費電力・低コスト | RX111/RX130/RX140。小型機器・センサー | | **RX200** | バランス型 | RX231/RX23E（高精度AFE内蔵で計測向け） | | **RX600** | 高性能・大容量 | RX64M/RX65N（TFT・イーサ）/RX651。HMI・通信に | | **RX700** | 最高性能・制御特化 | RX72M/RX72N（産業ネットワーク）/RX66T（モーター制御） | 選定は「必要な処理性能・フラッシュ/RAM容量・内蔵周辺（イーサネット、TFTコントローラ、CAN、USB、高精度ADC）」から逆算します。たとえばタッチパネルHMIならRX65N、サーボ/インバータ制御ならRX66T、産業用イーサネット対応ならRX72Mが定番です。 ## 開発環境・FIT・Smart Configurator RX開発の標準構成は次のとおりです。 | 要素 | 内容 | | 統合開発環境 | **e2 studio**（Eclipseベース）。CS+も可 | | コンパイラ | **CC-RX**（純正）。GCC for RXも選択可 | | 周辺ドライバ | **FIT**（Firmware Integration Technology）モジュール | | 設定ツール | **Smart Configurator**（クロック・端子・FIT管理） | | デバッガ | E2 / E2 Lite | **FIT**はRX開発の中核です。`r_sci_rx`（シリアル）、`r_riic_rx`（I2C）、`r_s12ad_rx`（12bit A/D）といった周辺ドライバをSmart Configuratorで追加すると、統一されたAPIでペリフェラルを操作できます。レジスタ直叩きが減り、品種変更時の移植も容易になります。 ## SCIでUART通信 **SCI（Serial Communications Interface）**はRXの汎用シリアルで、調歩同期（UART）・クロック同期（簡易SPI）・簡易I2Cに対応します。ここではFITの `r_sci_rx` を使ったUART送受信を示します。 ``` #include "r_sci_rx_if.h" static sci_hdl_t s_sci_handle; static sci_cfg_t s_sci_cfg; /* SCIチャネルをUARTモードで開く */ s_sci_cfg.async.baud_rate = 115200; s_sci_cfg.async.clk_src = SCI_CLK_INT; s_sci_cfg.async.data_size = SCI_DATA_8BIT; s_sci_cfg.async.parity_en = SCI_PARITY_OFF; s_sci_cfg.async.stop_bits = SCI_STOPBITS_1; s_sci_cfg.async.int_priority = 3; R_SCI_Open(SCI_CH6, SCI_MODE_ASYNC, &s_sci_cfg, sci_callback, &s_sci_handle); /* 送信 */ uint8_t msg[] = "Hello RX!\r\n"; R_SCI_Send(s_sci_handle, msg, sizeof(msg) - 1); /* 受信（リングバッファ経由）*/ uint8_t c; if (R_SCI_Receive(s_sci_handle, &c, 1) == SCI_SUCCESS) { /* 1バイト受信 */ } ``` FITのSCIモジュールは内部に送受信バッファを持つため、割り込み処理やリングバッファを自前で書く手間が減ります。コールバック関数で受信エラーや受信完了イベントを受け取れます。 ## RIICでI2C通信 本格的なI2Cには専用ユニット**RIIC**を使います。FITの `r_riic_rx` を使うと、マスタ送受信・クロックストレッチ・マルチマスタを統一APIで扱えます。 ``` #include "r_riic_rx_if.h" riic_info_t iic; uint8_t slave_adr = 0x48; /* 7bit 右詰め（シフト不要：FITが処理）*/ uint8_t reg = 0x00; uint8_t rx[2]; iic.dev_sts = RIIC_NO_INIT; iic.ch_no = 0; iic.p_slv_adr = &slave_adr; /* スレーブアドレスはポインタで渡す */ R_RIIC_Open(&iic); /* レジスタ指定して2バイト読み出し（リスタート）*/ iic.p_data1st = ® iic.cnt1st = 1; iic.p_data2nd = rx; iic.cnt2nd = 2; R_RIIC_MasterReceive(&iic); /* iic.dev_sts == RIIC_FINISH を待って結果を使う */ int16_t value = (rx[0] << 8) | rx[1]; ``` ** FITはアドレスのシフトを内部処理 RIIC FITモジュールは7bitスレーブアドレスをそのまま指定できます（内部でR/Wビットを付与）。RL78の簡易I2Cでは左シフトが必要だったのと挙動が異なる点に注意してください。 ## MTUでPWM・タイマ **MTU（Multi-Function Timer Pulse Unit）**は、RXの高機能タイマです。インターバル割り込み、PWM出力、相補PWM（デッドタイム付き）、入力キャプチャ、位相計数（エンコーダ）などに対応し、モーター制御の中核になります。 - **PWMモード**：LED調光・ファン制御・DCモーター制御 - **相補PWM＋デッドタイム**：3相インバータ・BLDC/PMSM駆動 - **入力キャプチャ**：パルス周期・幅の測定 - **位相計数モード**：2相エンコーダの正逆カウント モーター制御で本格的なリアルタイム制御を行う場合は、MTUのPWMとA/D変換開始トリガを同期させ、キャリア周期ごとに電流を取得して制御演算を回す構成が定石です。より高度なモーター制御専用機としては [TI C2000](https://technosphere.co.jp/blog/ti-c2000-motor-control) も選択肢になります。 ## 12bit ADCの実装 RXは12bit逐次比較型A/Dコンバータ（S12AD）を内蔵します。FITの `r_s12ad_rx` でチャネル・トリガ・スキャンモードを設定します。 ``` #include "r_s12ad_rx_if.h" adc_cfg_t adc_cfg; adc_ch_cfg_t ch_cfg; uint16_t ad_val; adc_cfg.resolution = ADC_RESOLUTION_12_BIT; adc_cfg.alignment = ADC_ALIGN_RIGHT; adc_cfg.trigger = ADC_TRIG_SOFTWARE; /* r_s12ad_rx の公開APIは R_ADC_ プレフィクス。第1引数 unit は数値（0/1）*/ R_ADC_Open(0, ADC_MODE_SS_ONE_CH, &adc_cfg, NULL); ch_cfg.chan_mask = ADC_MASK_CH0; R_ADC_Control(0, ADC_CMD_ENABLE_CHANS, &ch_cfg); R_ADC_Control(0, ADC_CMD_SCAN_NOW, NULL); /* 変換完了を待って結果取得 */ R_ADC_Read(ADC_REG_CH0, &ad_val); uint32_t mv = ((uint32_t)ad_val * 3300) / 4095; /* 基準3.3V時 */ ``` 制御用途では、ソフトウェアトリガではなくMTUやタイマからのハードウェアトリガでスキャンを開始し、変換完了割り込みで結果を取り込むのが一般的です。 ## よくあるトラブルと対策 | 症状 | 主な原因 | 対策 | | SCIで文字化け | 動作クロック（PCLK）とボーレート設定の不一致 | Smart Configuratorのクロック設定とSCIのボーレートを再確認 | | FITモジュールがビルドエラー | 依存モジュール（r_bsp等）の未追加・バージョン不整合 | Smart Configuratorで依存を解決し、コンポーネントを揃える | | RIICがタイムアウト | プルアップ不足・バスハングアップ | プルアップを実装。ハング時はバスリカバリ（SCLクロック送出）を実装 | | ADC値が暴れる | サンプリング時間不足・入力インピーダンス高 | サンプリング時間を延ばし、入力をOPアンプでバッファ | | エンディアンで値が壊れる | RXはビッグ/リトル選択可。設定とデータ解釈の不一致 | エンディアン設定とシリアライズ処理を統一 | ## まとめ ### この記事のまとめ - RXはルネサス独自コアの32bitマイコンで、日本の産業機器・FA・HMI・モーター制御で広く使われる - RX100/200/600/700から、性能・メモリ・内蔵周辺（イーサ/TFT/CAN/高精度ADC）で選定する - 周辺はFITモジュール（r_sci_rx / r_riic_rx / r_s12ad_rx）とSmart Configuratorで統一APIで実装する - UART/簡易I2C/簡易SPIはSCI、本格I2CはRIIC、PWM/タイマ/エンコーダはMTUを使う - RL78（16bit）とRX（32bit）はe2 studioで環境を共通化しつつ製品グレードで使い分けられる RXを使った産業機器・制御システムの開発でお困りのことがあれば、テクノスフィアにお気軽にご相談ください。要件定義・回路設計支援・ファームウェア開発・量産まで一貫して対応します。 RX を使った産業用制御装置・計測機器・HMI・通信ゲートウェイの試作・量産設計、既存システムの RX 化も [組込み制御・マイコン開発](https://technosphere.co.jp/embedded) として対応しています。 ／この内容の受託開発・PoC相談はこちら＼ ### Renesas RX 受託開発・産業機器設計 RXを使った産業用制御装置・計測機器・HMI・通信ゲートウェイの設計から量産まで、組込み開発歴20年超のエンジニアが一貫対応します。RL78との使い分け設計もご相談ください。 [組込み開発サービスを見る](https://technosphere.co.jp/embedded) [RX/産業機器設計相談](https://technosphere.co.jp/contact) ## よくある質問（FAQ） ** RXファミリ（RX100/200/600/700）はどう選びますか？ RX100は低消費電力・低コスト、RX200はバランス型（RX23Eは高精度計測向け）、RX600は高性能でTFT・イーサ対応、RX700はモーター制御や産業ネットワーク向けです。必要な性能・メモリ・内蔵周辺から選定します。 ** FITとは何ですか？ FIT（Firmware Integration Technology）はルネサス提供の周辺ドライバ部品群です。r_sci_rx・r_riic_rx・r_s12ad_rx などをSmart Configuratorで追加し、統一APIでペリフェラルを操作できます。レジスタ直叩きが減り移植も容易になります。 ** RXのUART・I2C・SPIはどのペリフェラルですか？ UART・簡易I2C・簡易SPIはSCI、高速SPIはRSPI、本格的なI2CはRIICを使います。FITモジュールで統一的に実装できます。 ** RXとRL78はどう使い分けますか？ RL78は16bit・超低消費電力で小規模機器に、RXは32bit・高性能で大規模な制御・通信・HMI機器に向きます。[RL78](https://technosphere.co.jp/blog/renesas-rl78-peripheral-guide) と同じe2 studioで環境を共通化でき、製品グレードで使い分ける構成も現実的です。 ## 次に読む｜マイコン記事 - [Renesas シリーズ RL78 ペリフェラル実装ガイド 16bit低消費電力。SAU/IICA/TAUを解説](https://technosphere.co.jp/blog/renesas-rl78-peripheral-guide) - [TI シリーズ TI C2000 モーター制御入門 FOC・ePWM・eQEPでモーターを回す](https://technosphere.co.jp/blog/ti-c2000-motor-control) - [開発実績 組込み制御・マイコン開発 実績紹介 RX採用案件を含む多数の受託開発事例](https://technosphere.co.jp/embedded-achievements) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # 死活監視とは？仕組み・監視方式・ツールの選び方を実務目線で解説｜株式会社テクノスフィア > 死活監視の定義から、ICMP Ping・TCPポート・HTTP(S)・エージェント型それぞれの検知範囲と誤検知パターン、アラート疲れを防ぐ通知設計、OSS（Zabbix・Nagios・Prometheus）とSaaS（Mackerel・Datadog）の損益分岐まで。サーバー監視システムを自社開発するテクノスフィアが実務目線で解説します。 URL: https://technosphere.co.jp/blog/server-monitoring-guide ** 目次 1. 死活監視とは 2. 死活監視で「できること」と「できないこと」 3. 監視方式の技術解説：Ping・TCP・HTTP(S)・エージェント型 4. 実務の落とし穴と誤検知パターン 5. 通知設計の実務：アラート疲れを防ぐ 6. ツールの選び方：OSS自前運用 vs SaaS 7. クラウドサーバー監視の観点：CloudWatchとの住み分け 8. まとめ ## 死活監視とは **死活監視（Alive Monitoring / Availability Monitoring）**とは、サーバーやネットワーク機器、サービスが「生きているか・死んでいるか」を継続的に確認する監視のことです。代表例は Ping（ICMP）による応答確認で、「監視対象に信号を送り、応答が返ってくれば正常、返らなければ異常」というシンプルな原理で動きます。 シンプルであるがゆえに軽視されがちですが、サーバー監視の全体像の中で死活監視は**最初に異常を知らせてくれる砦**です。ECサイトが落ちていることに「お客様からの電話で気づいた」、社内システムの停止に「月曜の朝、出社した社員の報告で気づいた」——こうした事態を防ぐ最低ラインが死活監視であり、その上にリソース監視（CPU・メモリ）、ログ監視、外形監視が積み上がります。 テクノスフィアは受託でお客様のシステムを支えるかたわら、サーバー監視システム [TechnoAlive](https://technosphere.co.jp/technoalive) を自社開発しています。社内には20年以上の開発・運用キャリアを持つエンジニアが在籍しており、以下、教科書的な定義ではなく「運用してみると何につまずくか」を軸に書きます。 ### アクティブ監視とパッシブ監視 死活監視の実現方法は、大きく2つに分類できます。 - **アクティブ監視（能動監視）：**監視サーバー側から定期的にPingやHTTPリクエストを送り、応答を確認する方式。「応答がない＝異常」と判断しやすく、本記事で扱う方式の大半がこちらです - **パッシブ監視（受動監視）：**監視対象側から送られてくるハートビート・SNMPトラップ・ログを受け取って状態を判断する方式。「来るはずの信号が来ない」ことで異常を検知します 実務では両者を組み合わせます。アクティブ監視は導入が容易な反面「監視サーバーから見える範囲」しか確認できず、パッシブ監視はNAT越えやファイアウォール内の機器にも使える反面、「信号が来ない理由」が対象の障害なのか経路の問題なのか切り分けにくい、という補完関係にあるためです。 ## 死活監視で「できること」と「できないこと」 死活監視を入れたのに障害に気づけなかった——というクレームの多くは、死活監視が本来検知できないものを検知できると思い込んでいたことが原因です。先に守備範囲の境界線を引いておきます。 ### できること - **サーバー・機器の停止検知：**電源断、OSクラッシュ、インスタンス停止、ネットワーク断を数分以内に検知 - **サービスポートの停止検知：**Webサーバーやデータベースのプロセスダウンを、ポート応答の有無で検知 - **復旧の確認：**障害対応後、応答が戻ったことを客観的に確認 - **稼働率（アップタイム）の記録：**SLA報告や障害振り返りの根拠データを蓄積 ### できないこと（死活監視だけでは不十分なケース） | 死活監視で見逃す障害 | 実際に起きること | 必要な監視 | | 性能劣化・応答遅延 | ページ表示に30秒かかるが「応答はある」ため正常扱い | 応答時間の閾値監視、リソース監視 | | アプリケーションの論理エラー | プロセスは生きているが決済処理だけ失敗し続ける | 外形監視（シナリオ監視）、ログ監視 | | リソース枯渇の予兆 | ディスク使用率98%。翌朝ログ書き込み失敗で全面停止 | CPU・メモリ・ディスクの閾値監視 | | セキュリティ侵害 | SSHへのブルートフォース攻撃。サーバーは「正常稼働」のまま | 認証ログ監視、セキュリティ監視 | | 証明書・ドメインの期限切れ | TLS証明書が失効しブラウザで警告。ポート443自体は応答 | 証明書有効期限の監視 | つまり死活監視は「止まった」ことは検知できても、「壊れかけている」「遅い」「間違った動きをしている」は検知できません。だからこそ現在の監視ツールの多くは、死活監視を入口に**リソース監視・外形監視・ログ監視を組み合わせた統合監視**へと発展しています。 ** 実務での順序 弊社が運用設計をお手伝いする際は、①死活監視（全サーバー）→ ②ディスク・メモリの閾値監視 → ③本番URLの外形監視 → ④ログ・セキュリティ監視、の順で導入することを推奨しています。①と②だけで、運用現場で「痛い思いをする障害」の大半は事前検知できるようになります。 ## 監視方式の技術解説：Ping・TCP・HTTP(S)・エージェント型 「死活監視」と一口に言っても、どのレイヤーで生死を確認するかで検知できる障害はまったく異なります。主要4方式を、検知範囲と誤検知パターンまで含めて整理します。 ### 1. ICMP Ping監視（L3：ネットワーク層） ICMP Echo Request を送信し、Echo Reply が返るかを確認する最も古典的な方式です。OSのネットワークスタックが応答するため、**「マシンとネットワーク経路が生きているか」**だけを確認します。負荷が極めて軽く、大量のホストに対して高頻度で実行できるのが利点です。 注意すべきは、Pingの成否とサービスの生死は独立だという点です。Apacheが落ちていてもPingは返りますし、逆に**クラウドのセキュリティグループやファイアウォールでICMPを許可していない環境**では、サーバーが完全に正常でもPingは全滅します。AWSでは新規作成したセキュリティグループはインバウンドを一切許可しないため、ICMPも明示的な許可が必要です。「Ping監視を設定したら全台ダウン表示になった」は初心者が一度は踏む罠です。 ### 2. TCPポート監視（L4：トランスポート層） 対象ポート（HTTP:80、HTTPS:443、SSH:22、MySQL:3306 など）へTCP接続を試み、3ウェイハンドシェイクが成立するかを確認します。**「そのポートでプロセスがLISTENしているか」**まで確認できるため、Pingより一段深い監視です。ICMPが遮断された環境でも、公開ポートさえあれば死活確認の代替になります。 限界もあります。TCP接続の受付はOSカーネルが行うため、**アプリケーションがデッドロックやGC停止でハングしていても、接続自体は成立してしまう**ことがあります。「ポートは開いているのに全リクエストがタイムアウトする」という障害は、ポート監視では検知できません。 ### 3. HTTP(S)エンドポイント監視（L7：アプリケーション層） 実際にHTTP(S)リクエストを送り、**ステータスコード・応答時間・応答本文**まで検証する方式です。「200 OKが返るか」に加えて「応答本文に特定の文字列が含まれるか」「応答が3秒以内か」まで確認でき、ユーザー体験に最も近い死活監視と言えます。外部拠点から本番URLに対して行う場合は「外形監視」と呼ばれます。 実務では、アプリケーション側に**ヘルスチェック専用エンドポイント**を実装しておくのが定石です。トップページを監視対象にすると、CDNキャッシュが効いて「アプリが死んでいるのに200が返る」ことがあるためです。依存するDBやキャッシュへの疎通まで確認して返す実装にしておくと、1本のURLでシステムの本質的な健全性を確認できます。 ``` # FastAPIでのヘルスチェックエンドポイント実装例 # DBへの疎通まで確認し、異常時は503を返す # ※擬似コード（db/redis等の初期化は省略） @app.get("/healthz") async def healthz(): try: await db.execute("SELECT 1") # DB疎通確認 await redis.ping() # キャッシュ疎通確認 except Exception as e: return JSONResponse( {"status": "ng", "detail": str(e)}, status_code=503 # 監視ツールが異常と判定できるコードを返す ) return {"status": "ok"} ``` ### 4. エージェント型 vs エージェントレス ここまでの3方式はすべて「外から確認する」**エージェントレス監視**です。これに対し、監視対象サーバーに常駐プログラム（エージェント）を入れて内部から情報を送る**エージェント型監視**があります。 | | エージェントレス | エージェント型 | | **取得できる情報** | 外から見える範囲（応答有無・応答時間・ポート状態） | 内部情報全般（CPU・メモリ・ディスク・プロセス一覧・ログ） | | **導入の手間** | 監視側の設定のみ。対象サーバーに変更不要 | 全対象へのインストール・バージョン管理が必要 | | **ネットワーク要件** | 監視サーバー→対象への到達性が必要（FW穴あけ） | 対象→監視サーバー方向の通信が多く、NAT内でも使いやすい | | **対象が完全停止した時** | 確実に検知できる（応答が消えるため） | 「データが来ない」ことからの間接検知になる | | **向いている用途** | 死活監視・外形監視 | リソース監視・プロセス監視・ログ監視 | 重要なのは**「エージェント型だけに寄せると、死活監視が弱くなる」**という点です。サーバーが完全に停止するとエージェントもろとも沈黙するため、エージェント型監視での停止検知は「メトリクスの途絶」という間接的なシグナルに頼ることになります。死活の一次判定はエージェントレス、詳細情報はエージェント、という併用が堅実です。弊社の[TechnoAlive](https://technosphere.co.jp/technoalive)がICMP Ping・SSH・HTTP/HTTPSの監視を死活判定の基本に据えているのも、この理由からです。 ## 実務の落とし穴と誤検知パターン 死活監視の設計でつまずくポイントは、方式の選択よりむしろ「運用してから気づく落とし穴」に集中しています。弊社が受託運用で実際に遭遇してきた代表例を挙げます。 ### 落とし穴1：監視サーバー自体の死活 最大の盲点です。監視サーバーが停止すると、**アラートが一切飛ばなくなり「無音＝すべて正常」に見えます**。オンプレのZabbixサーバーが週末に落ちていて、月曜に本番障害とまとめて発覚した——という事故は業界の定番ネタと言っていいほど頻出します。対策は3つです。 - **監視サーバーを監視対象と分離する：**別ネットワーク・別リージョン・別クラウドに配置し、共倒れを防ぐ - **相互監視：**監視サーバー自身を外部SaaSなど別系統で監視する - **デッドマン方式：**「監視システムから定期的にハートビートが届き続ける」ことを別システムで確認し、途絶したら警報を上げる ### 落とし穴2：単一拠点からの監視による経路誤検知 監視サーバーが1拠点しかないと、**対象サーバーの障害と、監視サーバー〜対象間のネットワーク経路の障害を区別できません**。実際には対象は正常なのに、途中の経路の瞬断で「ダウン」と誤検知するケースです。外形監視を複数拠点から行う、社内とクラウドの2系統から監視する、といった多視点化が対策になります。少なくとも「1回の失敗で即アラート」は避けてください。リトライ設計（後述）なしの死活監視は誤報製造機になります。 ### 落とし穴3：プロセス生存とサービス応答の乖離 「プロセス監視でhttpdの生存は確認している」という現場ほど危険です。プロセスは存在するがリクエストを一切処理できない状態——コネクションプール枯渇、デッドロック、ディスクフルによる書き込み待ち——は普通に起こります。**プロセスの存在確認とサービスの応答確認は別物**であり、最終的な正常性判定はL7（HTTP監視・ヘルスチェックエンドポイント）で行うべきです。 ### 落とし穴4：DNSと証明書という「周辺」の死角 IPアドレス直指定で監視していると、DNSレコードの設定ミスや期限切れで「監視は全緑なのにユーザーはアクセス不能」になります。逆にFQDNで監視していれば、DNS障害も含めてユーザー視点の到達性を確認できます。同様にTLS証明書の期限切れも、ポート監視では検知できない典型的な死角です。HTTPS監視には証明書の有効期限チェック（残り14日で警告など）を含めておきましょう。 ### 誤検知パターン早見表 | 症状 | よくある原因 | 対策 | | 正常なのに「ダウン」判定（偽陽性） | ICMP遮断／FWのレート制限／経路の瞬断／監視元IPのブロック | ICMP許可設定の確認、N回連続失敗での判定、複数拠点監視、監視元IPの許可リスト登録 | | ダウンしているのに「正常」判定（偽陰性） | CDN・LBのキャッシュが200を返す／プロセスはあるがハング | キャッシュを通らないヘルスチェックURLの監視、応答本文のキーワード検証 | | 夜間だけ大量のアラート | バックアップ・バッチによる高負荷で応答遅延 | メンテナンスウィンドウの設定、時間帯別の閾値、タイムアウト値の見直し | | アラートが復旧・再発を繰り返す（フラッピング） | 閾値ぎりぎりの状態が継続、不安定な回線 | ヒステリシス（障害判定と復旧判定の閾値を分ける）、連続成功N回で復旧判定 | ## 通知設計の実務：アラート疲れを防ぐ 監視の失敗は「検知できなかった」より**「検知したのに誰も反応しなかった」**ことで起こるほうが多い、というのが運用現場の実感です。1日に何十件も飛ぶ重要度不明のアラートは数週間で「読まれない通知」になり、その中に埋もれた本物の障害が見逃されます。いわゆる**アラート疲れ（Alert Fatigue）**です。 ### 原則1：アラートは「行動が必要なもの」だけに絞る 通知設計の出発点は、すべてのイベントを重大度で分類し、**即時通知するのは「人がいま行動すべきもの」だけ**に絞ることです。即時に人を起こすのは本番の死活NGとDB接続不能だけ。ディスク80%超えや証明書期限14日前はチャットに流して営業時間内に拾う。再起動完了やバッチ正常終了は通知せずダッシュボードに残す——この3段階に落とすだけで通知量は体感で1/10になります。 運用開始後も定期的に「先月鳴ったアラートのうち、実際に対応が必要だったのは何件か」を棚卸しし、対応不要だったものは閾値変更・Info降格・監視削除のいずれかで潰していきます。**アラートの精度はチューニングし続けるもの**で、初期設定のまま放置された監視は必ず腐ります。 ### 原則2：リトライとエスカレーションを設計する 誤検知対策の基本は「1分間隔で監視し、3回連続失敗で初めて障害と判定する」といった**連続失敗回数による判定**です。検知は数分遅くなりますが、瞬断由来のノイズが激減し、アラートの信頼性が上がります。逆に言えば、検知速度が最優先のシステムでは間隔を短くしてリトライ回数を確保する必要があり、監視間隔・リトライ回数・許容検知遅延の3つはセットで設計します。 あわせて、一次対応者が反応できない場合に備えた**エスカレーション**を決めておきます。「Criticalの通知後15分間、誰も対応表明しなければ二次担当と責任者へ再通知」というルールを、PagerDutyやOpsgenie、国産ならTechnoAliveやMackerelのアラート通知連携など、エスカレーションを持つツールで自動化しておくと、深夜の見逃しを仕組みで防げます。担当者の善意や気合いに頼る運用は必ず破綻します。 ### 原則3：通知経路を冗長化する 通知先がSlackだけ、という構成は意外と危険です。Slack自体の障害、ワークスペースの認証切れ、Webhook URLの失効——通知経路の障害はアラートの完全な沈黙を意味します。**Critical通知はチャットとメールなど2経路以上**に送り、可能であれば依存するインフラが重ならない組み合わせ（例：Slack＋携帯キャリアメール）を選びます。通知のテスト送信を月次の定期作業に組み込み、「いざという時に届かない」を事前に検出するのも地味ながら効果の高い運用です。 ** ツール選定時のチェックポイント 通知まわりは製品差が出やすい部分です。「重大度別に通知先を変えられるか」「エスカレーションを自動化できるか」「メンテナンスウィンドウを設定できるか」「テスト通知機能があるか」の4点は、比較検討時に確認しておくことをおすすめします。 ## ツールの選び方：OSS自前運用 vs SaaS 死活監視を実現するツールは、大きく「OSSを自前で運用する」「SaaSを利用する」「クラウド純正サービスを使う」の3系統に分かれます。 ### 判断軸は「監視対象数 × 運用体制」 OSSはソフトウェアこそ無料ですが、実際には**監視サーバーのインフラ費用＋構築工数＋継続的な保守工数**がかかります。弊社の経験則では、Zabbix等の監視基盤をゼロから構築すると設計込みで数十時間規模、稼働後もバージョンアップ・監視設定の追加変更・監視サーバー自体の面倒見で月数時間の工数が発生します。エンジニアの時間単価で換算すると、これは決して「無料」ではありません。 一方SaaSはホスト数課金です。例えば10台をMackerelのスタンダードホストで監視すると月2万円強（2026年7月時点の税込単価2,180円×10台）。**月数時間の保守工数より安い**ため、監視対象が数台〜数十台で専任担当を置けない組織では、SaaSが総コストで勝つことがほとんどです。逆に監視対象が数百台〜数千台になるとSaaS費用が月数十万〜数百万円に膨らみ、専任チームを抱えてOSSを運用する方が安くなる損益分岐を超えます。 - **〜数十台・専任なし：**SaaS または監視込みの運用サービスが第一候補 - **数百台〜・専任あり：**OSS自前運用のコストメリットが出始める - **要件が特殊（閉域網・独自プロトコル・カスタム監視）：**規模によらずOSSや個別開発が候補に ### 主要ツール比較 ライセンス・料金はすべて各公式サイトで確認したもので、**2026年7月時点**の情報です（料金は改定されることがあるため、導入時は必ず公式サイトをご確認ください）。 | ツール | 形態・ライセンス | 死活監視の方式 | 料金の目安（2026年7月時点） | 向いているケース | | **Zabbix** | OSS（7.0以降AGPLv3、6.4以前GPLv2） | ICMP／TCP／HTTP＋エージェント。統合監視の定番 | ソフトウェア無料。監視サーバーの構築・保守コストは自己負担 | 数百台規模を専任チームで一元監視。オンプレ・閉域網 | | **Nagios Core** | OSS（GPLv2） | プラグイン実行型。NRPE/NCPA等のエージェント併用可 | ソフトウェア無料。同上 | 歴史が長く情報豊富。既存Nagios資産のある環境 | | **Prometheus + Grafana** | OSS（Apache 2.0／Grafana OSSはAGPLv3）。PrometheusはCNCFプロジェクト | Pull型メトリクス収集。死活・外形は blackbox_exporter（HTTP/TCP/ICMP/DNS/gRPC対応） | ソフトウェア無料。同上 | Kubernetes・コンテナ環境。メトリクス中心の監視文化 | | **Mackerel** | SaaS（はてな） | エージェント型＋外形監視（URL監視） | 無料枠はホスト5台まで。スタンダードホスト2,180円/月（税込）、マイクロホスト660円/月。外形監視20件までは最低利用料金（2,180円）に含まれる | 国産・日本語サポート重視。数台〜数十台の中小規模 | | **Datadog** | SaaS（米Datadog） | エージェント型中心。外形監視（Synthetic）は別課金 | 無料枠は5ホストまで。Infrastructure Proが$15/ホスト/月、Enterpriseが$23/ホスト/月（年払い） | APM・ログまで含めた大規模統合オブザーバビリティ | | **Amazon CloudWatch** | クラウド純正（AWS） | メトリクス＋アラーム。外形はSynthetics Canaryで別構成 | 従量課金。標準解像度アラーム0.10 USD/月、カスタムメトリクス0.30 USD/月〜、Canary実行0.0012 USD/回（リージョンで変動、無料枠あり） | 監視対象がAWSに閉じている環境のリソース監視 | | **TechnoAlive** | 自社開発の監視システム（テクノスフィア） | エージェント不要のPing・SSH・HTTP(S)監視＋リソース・セキュリティ監視 | 要問い合わせ | OCI・AWS・Azure・GCP・オンプレ混在環境を1画面で。デモ・導入相談が可能 | なお「まず無料で外形監視だけ」であれば、Uptime Kuma（セルフホストOSS）やUptimeRobotの無料枠でHTTP監視を始める手もあります。ただし通知の冗長化やエスカレーションはこの層のツールでは弱いため、本記事で述べた通知設計が必要になった時点が上位ツールへの乗り換えどきです。 ** 公平のための補足 上記はどれも実績のある選択肢で、優劣ではなく「規模と体制への適合」で選ぶものです。弊社製品のTechnoAliveも万能ではなく、APMやログ分析まで必要な大規模環境ならDatadog、Kubernetes中心ならPrometheusが適しています。TechnoAliveが向くのは、複数クラウドにまたがる数台〜数十台のサーバー群の死活・リソース・セキュリティ監視を、作り込みなしでまとめたいケースです。 ## クラウドサーバー監視の観点：CloudWatchとの住み分け 「クラウドを使っているなら純正の監視（AWSならCloudWatch、AzureならAzure Monitor）だけで足りるのでは？」という質問をよくいただきます。答えは**「リソース監視は足りる。死活・外形監視の視点では足りないことが多い」**です。 ### クラウド純正監視が得意なこと CloudWatchはEC2のCPU使用率・ネットワークI/OなどをハイパーバイザーレベルでAPI一つ取得でき、オートスケーリングや自動復旧のトリガーとも直結しています。AWSリソース（RDS、ELB、Lambda等）の内部メトリクスはCloudWatchでしか取れないものも多く、**AWS内のリソース監視については純正が第一選択**です。 ### 純正だけでは埋まらない3つの穴 1. **OS内部のメトリクスは標準では取れない：**メモリ使用率・ディスク使用率はハイパーバイザーから見えないため、CloudWatch Agentの導入（＝エージェント型監視の運用）が別途必要になります 2. **「外から見えるか」の視点がない：**CloudWatchはAWSの内側からの監視です。DNS設定ミス・証明書失効・経路障害など「ユーザーからは繋がらないのにメトリクスは正常」という障害は、外部からの死活・外形監視（CloudWatch Syntheticsを別途構成するか、外部ツール）でしか捉えられません 3. **マルチクラウドで監視が分裂する：**AWSとOCI、Azureを併用すると、監視画面・アラート設定・課金がクラウドごとにバラバラになります。障害時に複数コンソールを行き来する運用は、対応速度を確実に落とします 実務的な整理としては、**「クラウド純正＝そのクラウド内部のリソースメトリクスと自動復旧」「横断ツール＝死活監視・外形監視・複数環境の一元化」**という住み分けが素直です。弊社でもOCIとAWSが混在するお客様環境では、各クラウドの純正メトリクスを残しつつ、死活監視と通知の一元化をTechnoAliveやSaaSツールで束ねる構成を採ることが多くあります。クラウド移行そのものを検討中の方は [クラウド移行支援サービス](https://technosphere.co.jp/cloud-migration) も併せてご覧ください。 ## まとめ ### この記事のまとめ - 死活監視は「止まったことを最速で知る」ための監視。性能劣化・論理エラー・リソース枯渇は守備範囲外で、リソース監視・外形監視との併用が前提 - Ping（L3）→ TCPポート（L4）→ HTTP(S)（L7）の順に検知範囲が深くなる。最終的な正常性判定はヘルスチェックエンドポイントへのL7監視で行う - ICMP遮断環境・プロセス生存とサービス応答の乖離・監視サーバー自身の死活・DNSと証明書、が実務4大落とし穴 - アラートは「行動が必要なものだけ」に絞り、リトライ判定・エスカレーション・通知経路の冗長化を仕組みで担保する - ツールは監視対象数×運用体制で選ぶ。数十台までならSaaS優位、数百台規模からOSS自前運用の損益分岐。クラウド純正はリソース監視、横断ツールは死活・外形監視と住み分ける 監視は「入れて終わり」ではなく、アラートの棚卸しと閾値チューニングを続けてはじめて機能します。まずは自社の監視が「止まったことに最速で気づける状態か」「鳴ったアラートに人が反応しているか」の2点から点検してみてください。 ／サーバー監視・運用のご相談はこちら＼ ### 監視設計から運用まで、まとめて任せられます 死活監視・リソース監視・セキュリティ監視を一元化するTechnoAliveの導入から、既存Zabbix環境の見直し、通知設計のチューニングまで。マルチクラウド対応のサーバー監視を実務経験ベースでご提案します。 [TechnoAliveの詳細を見る](https://technosphere.co.jp/technoalive) [監視・運用の相談をする](https://technosphere.co.jp/contact) ## よくある質問（FAQ） ** 死活監視と外形監視の違いは何ですか？ 見る場所が違います。死活監視は「サーバーやプロセスが生きているか」をPing応答やポートの開閉で確認し、外形監視は「ユーザーから見てサービスが使えるか」を外部からのHTTPリクエストで確認します。プロセスは生きているのにアプリはエラーを返す、というズレは珍しくないので、本番サービスでは両方の併用が基本です。 ** Pingに応答があればサーバーは正常と考えてよいですか？ 言えません。PingにはOSが応答するため、WebサーバーやDBが落ちていてもPingは返ります。逆にファイアウォールでICMPが遮断されていれば、正常なサーバーでもPingは失敗します。Pingは「ネットワークに届くか」の確認と割り切り、サービスの生死はポート監視やHTTP(S)監視で見てください。 ** 監視間隔はどのくらいが適切ですか？ まず1分間隔・3回連続失敗で判定、から始めるのが無難です。これで拾えない障害が出たら間隔を詰める、誤報が多ければリトライ回数を増やす、という順で調整します。SaaSの場合は監視間隔が料金に直結する点も忘れずに。 ** OSSとSaaSはどちらを選ぶべきですか？ 専任担当を置けないなら、まずSaaSです。OSSはソフトウェアこそ無料ですが、監視サーバーの構築・保守という工数が継続的にかかります。対象が数台〜数十台ならSaaS、数百台規模でSaaS費用が保守工数を上回ってきたらOSS自前運用、という順で検討すれば大きく外しません。詳しくは本文のツールの選び方をご覧ください。 ** 監視サーバー自体が落ちたら障害に気づけないのでは？ 気づけません。これが自前監視の最大の盲点で、監視サーバーが落ちると「アラートが来ない＝正常」に見えます。監視サーバーを対象と別の場所に置く、監視サーバー自身を外部サービスで監視する（相互監視）、ハートビートの途絶で警報を上げるデッドマン方式、のいずれかを入れてください。 ** AWSを使っているならCloudWatchだけで十分ですか？ リソース監視なら十分です。ただしメモリ・ディスク使用率の取得にはCloudWatch Agentの導入が必要で、「AWSの外から到達できるか」はSynthetics等を足さない限り見えません。複数クラウド併用なら監視画面も分裂するため、死活・外形監視は横断ツールに寄せるのが現実的です。 # 死活監視 # サーバー監視 # 外形監視 # Zabbix # Prometheus # Mackerel # CloudWatch # アラート設計 ## 次に読む｜サーバー運用・クラウド関連 - [製品紹介 TechnoAlive｜クラウドサーバー死活監視システム 死活・パフォーマンス・セキュリティ監視を1つのダッシュボードで](https://technosphere.co.jp/technoalive) - [サービス クラウド移行支援サービス オンプレからAWS・OCIへの移行設計と運用体制づくり](https://technosphere.co.jp/cloud-migration) - [技術コラム Raspberry Piでセンサーデータ取得＆クラウド連携 完全ガイド MQTT経由でAWS IoT Coreへ送信するIoT監視の実装例](https://technosphere.co.jp/blog/raspberry-pi-sensor-iot) - [技術コラム OpenClaw 入門｜社内Kubernetesで動かす環境構築ガイド k3sクラスタの構築・運用ノウハウ](https://technosphere.co.jp/blog/openclaw-getting-started) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # 拠点間VPNで現場を遠隔保守する｜CGNAT・NAT越え・既存機器を触らない設計｜株式会社テクノスフィア > 離れた現場のネットワークカメラや制御機器を、オフィスから遠隔保守するための拠点間VPN設計をまとめました。モバイル回線のCGNAT環境でつなぐ向きの決め方、UDP 500/4500とNAT-T、無通信でNATテーブルが落ちる問題、SNATで既存機器を1台も触らずに通す方法まで、実際に詰まった箇所を中心に解説します。 URL: https://technosphere.co.jp/blog/site-to-site-vpn-remote-maintenance ** 目次 1. 現場に行くしかない、を終わらせる 2. どちら向きにVPNを張るか 3. モバイル回線とCGNAT、NAT越えの実際 4. つながったのに、朝には切れている 5. 既存機器を1台も触らずに通す 6. 導入前に実回線で確かめる5項目 7. よくある質問（FAQ） 8. まとめ ** 本記事について 本記事は、当社が遠隔保守用のゲートウェイを設計・実装するなかで確認してきた内容をまとめたものです。特定のお客様の構成は扱っておらず、**ネットワーク構成の一般的な考え方**として書いています。実際の回線での挙動は事業者や契約によって変わるため、導入時は必ず現地の回線で確認してください。 ## 現場に行くしかない、を終わらせる 工場、倉庫、屋外設備、無人の施設——そういった場所に置いたネットワークカメラやレコーダー、制御機器は、**不具合が起きるたびに人が行くしかない**状態になりがちです。行ってみたら設定がひとつ違っていただけ、ということも珍しくありません。片道2時間の現場なら、確認だけで半日が消えます。 この状態から抜ける方法自体ははっきりしています。**現場のネットワークとオフィスのネットワークを、拠点間VPNでつないでしまう**ことです。つながってさえいれば、オフィスの席から現場の機器へ、その場にいるのと同じようにアクセスできます。 ただ、実際にやってみると教科書どおりには進みません。現場に固定回線がない、モバイル回線ではグローバルIPがもらえない、夜のあいだに接続が切れている、既存機器の設定を変えたくない。当社がこの仕組みを組むなかで実際に詰まったのは、いつも同じ4か所でした。順に見ていきます。 ## どちら向きにVPNを張るか （図: 工場側の建物から一本の青い矢印がオフィスへ向かって伸び、工場側の入口はシャッターで閉ざされているイメージイラスト） 最初に決めるのは、**どちらから接続を開始するか**です。ここを間違えると、後の工程がすべて苦しくなります。 オフィス側から現場へ接続しに行く設計にすると、現場のルーターで着信ポートを開け、外から入れる状態を作らなければなりません。これは現場ごとにルーターの設定を変えて回ることを意味しますし、情報システム部門の承認も通りにくくなります。何より、後述するモバイル回線では**そもそも外から入れません**。 そこで、**現場のゲートウェイ側から発信し、オフィス側で待ち受ける**向きにします。この向きなら現場側に外部からの入口を一切作らずに済みます。オフィス側は固定のグローバルIPを1つ持ち、VPNを終端できるルーターがあればよく、拠点が増えても受け入れ設定を足すだけです。 | 接続の向き | 現場側に必要なこと | モバイル回線での成立 | | **オフィス → 現場** | 着信ポートの開放、固定IPまたはDDNS | ほぼ不可（CGNATのため） | | **現場 → オフィス** | なし（発信のみ） | 可能 | 方式としては、ヤマハのRTXシリーズが持つリモートVPNアカウントを使った**L2TP/IPsec**、あるいは**IKEv2の拠点間接続**のどちらかを使います。どちらもゲートウェイ側から張り出せます。 ## モバイル回線とCGNAT、NAT越えの実際 （図: 青い光の帯が大きさの違う半透明の門を三つ続けてくぐり抜け、向こう側のオフィスへ届いているイメージイラスト） 現場に固定回線が引けない場合、モバイルルーターを使うことになります。ここで必ず出てくるのが**CGNAT**（キャリアグレードNAT）です。 通常のモバイル回線では、契約者にグローバルIPアドレスが割り当てられません。事業者の設備の内側でプライベートIPが配られ、多数の契約者が少数のグローバルIPを共有します。つまり**外部からその回線を名指しで呼び出す手段が存在しません**。前節で「現場発にする」と決めたのは、この制約が理由です。 発信であれば通せますが、IPsecはNATと相性が悪いプロトコルです。そこで**NAT-T（NAT Traversal）**を使います。IKEの通信は**UDP 500**で始まり、NATを検出すると**UDP 4500**へ切り替えて、以降の暗号化通信をUDPで包んで送ります。UDPで包むことで、途中のNAT機器から見ればただのUDP通信になり、通過できるようになります。 - **UDP 500**——IKEの鍵交換。ここが通らなければトンネルは始まりません - **UDP 4500**——NAT-T。実際のデータはここを通ります - **ESP（プロトコル番号50）**——NAT-T を使う場合はUDPに包まれるため、そのままでは流れません 事業者や契約によっては、UDPの特定ポートを遮断していたり、通信の内容によって帯域を絞っていたりします。**「モバイル回線なら通る」と一般化はできません**。UDPがどうしても通らない回線に当たった場合は、TCP 443で通す方式（SoftEtherなど）に切り替えるという逃げ道を用意しておくと、現場ごとの当たり外れに対応できます。 ## つながったのに、朝には切れている 設定を終えてトンネルが張れると、その場では問題なく通信できます。ところが翌朝アクセスすると届かない——これが次に来る壁です。 原因は**NATテーブルの寿命**です。途中のNAT機器は「この内側アドレスとこの外側ポートを対応させている」という表を持っていますが、その対応は一定時間通信がないと破棄されます。夜間のように誰もアクセスしない時間が続くと、対応表から消え、戻りの通信が行き場を失います。トンネル自体は張れているつもりなのに通信が届かない、という状態になります。 対策は単純で、**無通信の時間を作らない**ことです。当社の構成では30秒ごとに小さなパケットを送り、対応表を維持しています。あわせて**DPD（Dead Peer Detection）**を有効にして、相手からの応答が途切れたら自動でトンネルを張り直すようにします。回線が一時的に切れても、復旧すれば自動で戻ってきます。 - **keepalive 30秒**——NATテーブルを維持する。長くしすぎると夜間に落ちる - **DPDで自動再接続**——切断を検知したら張り直す。人が現場へ行かずに復旧できる - **起動時のリトライ**——電源投入直後は回線がまだ上がっていないことがあるため、間隔を空けて数回試す 見落としやすいのは3つ目です。停電から復帰したとき、ゲートウェイのほうがモバイルルーターより先に起動してしまうと、1回目の接続は必ず失敗します。**一度失敗したら終わり、という作りにしない**ことが、無人の現場では効いてきます。 ## 既存機器を1台も触らずに通す （図: 中央の小さな白い箱が外から届いた青い光を受け取り、オレンジの光に変えて手前の3台のネットワークカメラへ配っているイメージイラスト） 最後の壁が、いちばん現場に嫌がられるところです。トンネルが張れても、**そのままでは現場の機器から返事が返ってきません**。 オフィスのパソコンから現場のカメラへパケットが届いたとき、カメラから見ると送信元は「知らないネットワークのアドレス」です。カメラは自分のデフォルトゲートウェイへ返事を投げますが、そこにはトンネルへの経路がありません。返事が迷子になります。 正攻法は、カメラやレコーダーのデフォルトゲートウェイを変更するか、スタティックルートを追加することです。しかし稼働中の設備でこれをやるのは、台数が多いほど現実的ではありません。**触った瞬間に「動いていたものを止めた」責任が発生します。** そこで、ゲートウェイ側で**SNAT（送信元アドレスの書き換え）**を行います。トンネルから出てきたパケットの送信元を、ゲートウェイ自身の構内LAN側アドレスに書き換えてから転送する方法です。カメラから見れば、**同じLAN内の機器から話しかけられているだけ**になります。返事はゲートウェイに戻り、ゲートウェイが同じトンネルでオフィスへ返します。 - **既存機器の設定変更がゼロ**——デフォルトゲートウェイもスタティックルートも触らない - **プロトコルを選ばない**——HTTPやRTSPだけでなく、メーカー独自の管理ツールもそのまま通る - **逆向きは通さない**——現場側からオフィスのネットワークへ出られないよう、転送は片方向に限定する 3つ目は忘れずに設定してください。現場のネットワークに何がつながっているかを完全に把握できることは稀です。**現場からオフィスへ入れる経路を作らない**ことが、この構成を情報システム部門に説明できるものにします。 ## 導入前に実回線で確かめる5項目 ここまでの内容は、机上で設計を決めるためのものです。実際にうまくいくかどうかは**現場の回線でしか分かりません**。当社では導入前に、必ず次の5項目を実際の回線で確認しています。 | 確認項目 | 見ているもの | | **UDP 500 / 4500 の疎通** | そもそもIKEとNAT-Tが通る回線か | | **トンネルの確立** | 鍵交換が最後まで進むか | | **NATテーブルの維持** | 無通信の時間を挟んでも戻りの通信が届くか | | **実効スループット** | 映像を見るのに足りるか。カタログ値ではなく現地の実測 | | **24時間の連続稼働と自動復帰** | 一晩置いて生きているか、回線を抜いて戻したら復旧するか | とくに4番目は軽視されがちです。トンネルが張れても、映像がコマ送りになるようでは保守の役に立ちません。確認したい機器の映像を実際に再生してみるところまでを、事前確認に含めてください。 当社ではこの構成を、装置と初期設定まで含めた[遠隔保守ゲートウェイサービス「GENBA Gate」](https://technosphere.co.jp/genba-gate)として提供しています。ここに書いた事前確認も、導入前に当社が現地の回線で実施しています。 ## よくある質問（FAQ） Q. 拠点間VPNとサイト間VPNは違うものですか？ A. 同じものを指します。離れた二つのネットワーク同士をまるごとつなぐ方式で、英語のsite-to-site VPNの訳語です。パソコン1台ずつにソフトを入れる「リモートアクセスVPN」と違い、拠点にゲートウェイを1台置けば、その先の機器はソフトを入れずに通信できます。 Q. モバイル回線でも拠点間VPNは張れますか？ A. 張れます。ただしモバイル回線はグローバルIPが割り当てられないCGNAT環境がほとんどで、外から接続することはできません。現場側のゲートウェイから発信する向きに設計し、NAT-T（UDP 4500）でNATを越える構成にする必要があります。 Q. 既存のカメラやレコーダーの設定を変えずに済みますか？ A. ゲートウェイ側でSNAT（送信元アドレスの書き換え）を行えば変えずに済みます。既存機器からは同じLAN内の機器との通信に見えるため、デフォルトゲートウェイの変更やスタティックルートの追加が要りません。稼働中の設備に触らずに導入できることが、この方式の一番の利点です。 ## まとめ 離れた現場をオフィスから見に行けるようにするとき、詰まるのは暗号化の設定そのものではありませんでした。**接続の向きを現場発に決めること**、**CGNATをNAT-Tで越えること**、**無通信でNATテーブルを落とさないこと**、**SNATで既存機器を触らずに済ませること**——この4つを設計の段階で押さえておけば、あとは現地の回線で確かめる作業になります。 一般化できる学びがあるとすれば、**「稼働中の設備に触らない」を制約として先に置くと、設計が決まりやすい**ということです。既存機器の設定変更を許容すると選択肢は増えますが、そのぶん導入の合意が取りにくくなります。触らないと決めた瞬間に、SNATを使う構成が自然に残ります。 当社では、この構成を装置と初期設定込みで提供する[GENBA Gate](https://technosphere.co.jp/genba-gate)のほか、Raspberry Piやマイコンを使った現場向け機器の受託開発を行っています。[組込みシステム開発](https://technosphere.co.jp/embedded)のご相談として、「遠隔で見られるようにしたいが、どこから手を付ければよいか分からない」という段階からでも歓迎です。 --- # エンジニアのスキルシート、まだExcelで管理しますか？｜SES・派遣の業務経歴書をWeb化した話｜株式会社テクノスフィア > SES・人材派遣で使う業務経歴書（スキルシート）のExcel管理を自社でWebシステム化した設計判断を解説。表記ゆれを止める選択式＋タグ設計、Excel原本を踏襲したA4印刷、SQLite＋Dockerで導入ハードルを下げた理由、単金を管理者のみ閲覧にした権限設計まで、実装した開発会社が実務目線で語ります。 URL: https://technosphere.co.jp/blog/skill-sheet-web-management ** 目次 1. はじめに：「経歴書_最新_v3_修正済(2).xlsx」問題 2. Excelスキルシート運用の4つの構造的な課題 3. 設計判断①：自由記述をやめる — 選択式＋タグで表記ゆれを止める 4. 設計判断②：印刷様式はExcel原本から変えない 5. 設計判断③：SQLite＋Docker — 「サーバー1台で今日入れられる」こと 6. 設計判断④：単金は管理者だけが見える権限設計 7. 契約管理と提案支援：カレンダーとワンクリックコピー 8. まとめ：Excelを捨てたのではなく、Excelの「出口」だけを残した ## はじめに：「経歴書_最新_v3_修正済(2).xlsx」問題 SES・人材派遣の業界では、エンジニアの業務経歴書（スキルシート）は今も圧倒的にExcelで管理されています。取引先に提出する様式がExcelで決まっているのだから当然ではあるのですが、その結果として共有フォルダには **「経歴書_山田_最新.xlsx」「経歴書_山田_最新_v3.xlsx」「経歴書_山田_最新_v3_修正済(2).xlsx」** が並ぶことになります。どれが本当の最新版なのかは、更新した本人しか知りません。 弊社も例外ではありませんでした。そこで、Excelで管理していた業務経歴書をWebで一元管理する社内システムとして「スキルシートポータル」を開発し、従業員が自分のスキルシートをスマホから編集できる体制に切り替えました。本記事では、その際にどのような設計判断をしたのかを、実務目線で解説します。 単なる「ExcelをWebフォームに置き換えました」という話ではありません。むしろ設計の大半は、**「Excelの何を捨てて、何を絶対に残すか」**の線引きに費やされました。同じ課題を抱えるIT管理者・情シス担当の方、そしてSES・派遣会社で営業や稼動管理をされている方の参考になれば幸いです。 ** この記事で扱う範囲 本記事は弊社が自社開発した「スキルシートポータル」の設計判断を題材にしています。社内利用から出発したシステムを、現在は [SES・派遣会社向け製品](https://technosphere.co.jp/skill-sheet-portal) として提供しています。 ## Excelスキルシート運用の4つの構造的な課題 まず、Excel運用の何が問題なのかを整理します。ポイントは、これらが「担当者の注意不足」ではなく**仕組みの問題**だということです。注意で解決できるならとっくに解決しています。 ### 1. 最新版がどれか分からない Excelファイルはコピーした瞬間に分岐します。エンジニア本人が持っている版、営業が提案用に手直しした版、共有フォルダの版。案件提案の直前に「これ最新？」の確認連絡が飛び交い、確認できないまま古い経歴で提案してしまうこともあります。ファイル名の命名規則をいくら整備しても、**「コピーできる」という性質そのものが原因**なので根絶できません。 ### 2. 書式・表記がばらつく 「Java」「JAVA」「java」。「詳細設計」「基本設計・詳細設計」「設計」。書く人が違えば表記は必ずばらつきます。セルの結合を壊す人、行を勝手に増やす人、フォントを変える人も現れます。提出前に営業が全シートを目視で整える作業が発生し、これが提案のリードタイムを直接押し上げます。 ### 3. 契約終了日の見落とし スキルシートとは別に、誰がどの常駐先にいつまでの契約でいるかを管理する台帳（これもたいていExcel）があります。シートと台帳が別ファイルなので突き合わせは手作業になり、**契約終了日が近い要員の把握が漏れる**と、更新交渉や次案件の提案が後手に回ります。SES事業では、これは単なる事務ミスではなく売上に直結する事故です。 ### 4. 提案のたびに同じ手作業 案件提案のメールを書くたびに、経歴書を開いて要点を拾い、定型文に貼り込む。1通あたりは数分でも、提案数が増えるほど累積します。しかも元データの表記がばらついているので、貼り込むたびに手直しが入ります。 ** 共通する原因 4つの課題はすべて「**データと帳票が分離されていない**」ことに帰着します。Excelはデータ置き場と提出帳票を1つのファイルが兼ねているため、コピー・改変・突き合わせのすべてが人力になります。Web化とは、この2つを分離する作業だと言えます。 ## 設計判断①：自由記述をやめる — 選択式＋タグで表記ゆれを止める Web化するとき最初に決めたのは、**「Excelのセルをそのままテキストボックスに置き換えない」**ことでした。自由記述のまま入力欄をWebに移しても、表記ゆれはExcel時代と何も変わりません。フィールドの性質ごとに入力方式を分けています。 | 項目 | 入力方式 | ねらい | | 担当（PG/SE/PL等）・開発フェーズ | **固定の選択式**（自由記述させない） | 語彙が有限なので選択式で完全に統制できる | | 言語・DB・機種OS・資格 | **タグ入力**（マスタ候補からサジェスト） | 語彙が増え続けるので選択式にはできない。候補優先＋新出語の事後統制で対応 | | 案件の期間 | **年月ピッカー** | 経過期間・年齢・実務経験年数を自動計算（原本Excelと同じ「(2年12ヶ月)」表記） | | 案件名・業務内容 | 自由記述＋**書き方ガイドとプレースホルダ例** | 統制しきれない部分は「良い書き方の例」を入力欄に常時表示して寄せる | ここで実務上いちばん悩んだのが技術キーワードの扱いです。担当やフェーズと違って、言語・フレームワークは毎年新顔が出ます。完全な選択式にすると「候補にないから入力できない」が頻発し、かといって完全な自由入力に戻すと表記ゆれが復活します。 採用したのは**「サジェスト優先＋事後統制」**の折衷案です。入力時はマスタ候補からのサジェストを優先しつつ、新出キーワードはその場で自動的にマスタへ追加して入力を止めません。そのうえで管理者が選択肢マスタの管理画面から、後で「JAVA→Java」のような表記ゆれを整理します。**入力する従業員の手を止めない**ことと**語彙が最終的に収束する**ことを両立させる、地味ですが効きどころの設計です。 ** 設計の教訓 表記ゆれ対策を「入力時に厳格化する」方向だけで考えると、現場の入力率が下がって元のExcelに戻ります。**入力時はゆるく受けて、統制は管理者側の作業に寄せる**方が、業務システムとしては長続きします。 ## 設計判断②：印刷様式はExcel原本から変えない Web化プロジェクトでありがちな失敗は、帳票のレイアウトまで「モダンに」作り直してしまうことです。しかしSES・派遣の実務では、**スキルシートは取引先に提出する帳票**であり、先方の担当者は長年見慣れた様式で読みます。「御社のシート、様式が変わりましたね」は、この業界ではほめ言葉ではありません。 そこでスキルシートポータルでは、印刷画面を**従来のExcel様式をそのまま踏襲したA4レイアウト**として実装しました。ブラウザの印刷機能からそのまま出力でき、PDFとしての出力にも対応しています。年齢や実務経験年数の「(2年12ヶ月)」といった経過表記も原本Excelと同じ形式で自動計算されるため、提出物だけを見れば従来と区別がつきません。 つまりこのシステムの本質は「Excelをやめる」ことではなく、**データの管理と入力をWebに移し、Excel様式は出口（帳票）として温存する**ことです。社内のデータフローだけを入れ替えるので、取引先への説明も調整も一切不要でした。既存業務システムの刷新一般に通じる考え方だと思います。 技術的には、画面用のCSSと印刷用のCSSを分け、印刷時のみExcel原本の罫線・段組を再現するアプローチです。帳票専用のPDF生成ライブラリを持ち込むより、ブラウザの印刷エンジンに任せる方が、A4一枚ものの帳票では保守がはるかに楽です。 ## 設計判断③：SQLite＋Docker — 「サーバー1台で今日入れられる」こと 技術構成は Next.js 15（App Router / Server Actions）＋ TypeScript、データベースは **SQLite（better-sqlite3）**、配布形態は **Docker** です。「業務システムなのにSQLite？」と思われるかもしれませんが、これは明確な意図を持った選択です。 ### なぜPostgreSQLやMySQLではないのか スキルシート管理の負荷特性を考えると、書き込みは従業員が経歴を更新するときだけ、読み取りも社内の管理者と本人が中心です。数十〜数百名規模の名簿系システムに、DBサーバーという「運用しなければならないもの」を1つ増やす理由がありません。 - **導入が1コマンド：**DBコンテナの起動もユーザー作成も不要。`docker compose up -d --build` だけで、初回起動時にスキーマ作成とシード投入まで自動で走ります - **バックアップがディレクトリコピー：**データは `./data/` 配下のSQLiteファイルに永続化されるので、バックアップはこのディレクトリをコピーするだけ。専任の情シスがいない会社でも運用できます - **認証も自己完結：**HMAC署名Cookie＋scryptパスワードハッシュで実装し、外部のID基盤を必要としません。導入時に用意するのはサーバー1台だけです 中小のSES・派遣会社にとって、システム導入の最大の障壁は機能ではなく**「面倒を見きれるか」**です。可用性やスケールのための構成要素を足すほど、その障壁は上がります。SQLite＋Dockerは「技術的に妥協した」のではなく、**導入ハードルという要件に対して最適化した**結果です。 ### マルチテナントは環境変数で切る もう1つ、シンプルさを優先した判断がマルチテナントの実装です。1つのDBの中にテナントIDを持たせるスキーマレベルのマルチテナントではなく、**会社ごとにコンテナとDBファイルを分離**し、会社名は環境変数 `COMPANY_NAME` で切り替える方式にしました。会社名はログイン画面・タイトル・印刷帳票に反映され、別会社の環境は別ポート・別データディレクトリで並走します。 スキーマレベルのマルチテナントは、テナント間のデータ漏えいを防ぐ実装・テストのコストが恒常的にかかります。会社単位でプロセスごと分けてしまえば、**漏えいの経路が構造的に存在しない**。テナント数が数千になるSaaSなら別の解を選びますが、この規模感ではこちらが正解だと考えています。 ## 設計判断④：単金は管理者だけが見える権限設計 SES・派遣の管理で最もセンシティブなデータは**単金（月あたりの契約単価）**です。Excel運用時代は「単金入りの台帳」と「単金なしのシート」を別ファイルで持つことで擬似的に権限を分けていましたが、ファイルの渡し間違い1つで崩壊する運用です。 スキルシートポータルでは、ロールを従業員と管理者の2段階に分け、単金（万円/月）は**管理者ロールのみ閲覧可能**としました。従業員は自分のスキルシートと経歴を編集できますが、単金のフィールドは画面上に存在すら現れません。管理者側では、全従業員のシート閲覧・代理編集・従業員マスタ管理（追加・停止・パスワード再設定）に加えて、単金の**月次合計**を確認できます。稼動中の契約から今月の売上規模がすぐ把握できるため、経営側の数字確認がExcel集計から解放されます。 権限設計で意識したのは「隠す」より「**そもそも渡さない**」ことです。画面で非表示にするだけの実装は、APIレスポンスに値が残っていれば意味がありません。単金はサーバー側で管理者セッションのときだけ応答に含める。当たり前のことですが、Excelの「ファイルを分けて運用でカバー」と比べたときのWeb化の本質的な利点は、まさにこの**権限をコードで強制できる**点にあります。 ** 代理編集という現実解 権限を分けると「本人しか編集できないので更新が進まない」という新しい問題が生まれます。そこで管理者には**代理編集**を許可しました。スマホから自分で更新するのが基本線ですが、忙しい現場のエンジニアの分は事務側で代行入力できる。理想論だけの権限設計は現場で必ず破綻します。 ## 契約管理と提案支援：カレンダーとワンクリックコピー スキルシートを一元化すると、次に欲しくなるのは「その人が今どこで、いつまで稼動しているか」です。スキルシートポータルには契約管理の機能を組み込み、**取引先・常駐先・稼動開始日・契約終了日を契約単位で登録し、履歴として蓄積**できるようにしました。 ### 契約カレンダー：終了日を「探す」から「目に入る」へ 契約情報は**契約カレンダー**として時系列で一覧できます。Excel台帳との決定的な違いは、契約終了日を「フィルタして探す」のではなく**「開けば目に入る」**ことです。前述のとおり、契約終了日の見落としはSESの売上に直結する事故です。台帳の目視チェックという属人作業を、画面を開くだけの動作に置き換えました。終了が近い要員が見えれば、更新交渉を前倒しできますし、次の提案準備も「終了日から逆算」で動けます。 ### 提案メールのテンプレ文をワンクリックコピー 提案業務の支援として、スキルシートのデータから**提案メール用のテンプレ文を生成し、ワンクリックでコピー**できる機能を用意しました。営業はコピーした文面をメールに貼り付けて、案件固有の内容だけ書き足せば提案が完成します。 これは機能としては小さいのですが、設計判断①〜②とつながっています。担当・フェーズが選択式で、技術キーワードがマスタ統制されているからこそ、機械的に生成した文面がそのまま使える品質になる。**入力時の統制は、出力の自動化のための投資**だったわけです。自由記述だらけのデータからテンプレ文を作っても、結局全文を手直しすることになります。 ## まとめ：Excelを捨てたのではなく、Excelの「出口」だけを残した ### この記事のまとめ - Excelスキルシートの問題（最新版不明・表記ゆれ・終了日見落とし・提案の手作業）は注意不足ではなく、データと帳票が分離されていない構造の問題 - 表記ゆれは「選択式＋マスタ管理タグ＋事後統制」で、入力者の手を止めずに収束させる - 取引先に出す帳票の様式は変えない。A4印刷はExcel原本を踏襲し、社内のデータフローだけを入れ替える - SQLite＋Dockerは妥協ではなく、「サーバー1台・1コマンドで導入できる」という要件への最適化 - 単金は管理者のみ閲覧。権限をファイル運用ではなくコードで強制できるのがWeb化の本質的な利点 - 契約カレンダーとテンプレ文コピーで、契約更新と提案の初動を早くする 振り返ると、このシステムの設計判断はどれも「Excelの何が本当に必要だったのか」を切り分ける作業でした。必要だったのは**取引先に出す様式**であって、コピーで増殖するファイルでも、自由記述のセルでもなかった。この切り分けさえ間違えなければ、スキルシートのWeb化は現場の反発なく定着します。 このスキルシートポータルは弊社の社内利用から出発し、現在は**SES・派遣会社向けに製品として提供しています**。詳しい機能や画面は [スキルシートポータル](https://technosphere.co.jp/skill-sheet-portal) のページをご覧ください。 スキルシート管理に限らず、Excel運用の業務をWebシステム化する開発は [Webシステム開発](https://technosphere.co.jp/web-system) として承っています。 ／SES・派遣会社向けに提供しています＼ ### スキルシートポータル｜業務経歴書のWeb一元管理 本記事で紹介したシステムをそのままお使いいただけます。スマホからの経歴編集、Excel原本様式のA4印刷・PDF出力、契約カレンダー、単金の権限管理まで。Docker＋SQLite構成でサーバー1台から導入できます。 [スキルシートポータルを見る](https://technosphere.co.jp/skill-sheet-portal) [デモ・導入のご相談](https://technosphere.co.jp/contact) ## よくある質問（FAQ） ** スキルシートのExcel管理をやめてWeb化するメリットは？ 最新版が常に1か所に集約され、「どのファイルが最新か」問題が消えます。従業員はスマホから自分で更新でき、担当・フェーズ・技術キーワードをマスタ管理することで書式や表記のばらつきも仕組みで防げます。契約終了日もカレンダーで一覧でき、更新漏れの防止につながります。 ** Web化しても取引先に提出するスキルシートの様式は維持できますか？ 可能です。弊社のスキルシートポータルでは、従来使っていたExcel様式をそのまま踏襲したA4印刷レイアウトを実装しており、ブラウザの印刷機能からそのまま出力できます。PDF出力にも対応しているため、取引先への提出フローを変えずに社内管理だけをWeb化できます。 ** スキルシートの表記ゆれ（JAVAとJavaなど）を防ぐにはどうすればいいですか？ 自由記述をやめるのが最も効果的です。担当（PG/SE/PL等）や開発フェーズは固定の選択式にし、言語・DB・OS・資格はマスタ候補からサジェストされるタグ入力にします。新しいキーワードは自動でマスタに追加し、管理者が後から表記ゆれを整理できる運用にすると、入力の手間を増やさずに統一できます。 ** 中小のSES企業でもスキルシート管理システムを導入できますか？ できます。弊社のスキルシートポータルはDocker＋SQLite構成のため、専用のDBサーバーが不要で、サーバー1台にコマンド1つで導入できます。バックアップもデータディレクトリのコピーだけで完了し、環境変数で会社名を切り替えられるため、小規模な体制でも運用負荷を最小限に抑えられます。詳細は [スキルシートポータル](https://technosphere.co.jp/skill-sheet-portal) をご覧ください。 # スキルシート # 業務経歴書 # SES # 人材派遣 # Excel脱却 # 業務システム # SQLite # Docker ## 次に読む｜関連コンテンツ - [自社プロダクト スキルシートポータル｜SES・派遣会社向け業務経歴書管理 本記事で紹介したシステムの機能・導入方法はこちら](https://technosphere.co.jp/skill-sheet-portal) - [サービス Webシステム開発 Excel業務のシステム化・業務Webアプリの受託開発](https://technosphere.co.jp/web-system) - [採用・人材 【2026年最新】AI面接ツール比較7選 料金・機能・導入事例から選び方を解説](https://technosphere.co.jp/blog/ai-interview-tools-comparison) - [Web×AI RAGチャットボットで社内ヘルプデスクを効率化 社内業務のシステム化事例をもう1つ](https://technosphere.co.jp/blog/what-is-rag-chatbot) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # 「載せるだけ」の在庫管理IoT「sphere-weight」を自社開発｜重量センサー×ESP32で在庫切れを自動通知｜株式会社テクノスフィア > 在庫容器を重量センサー台に載せておくだけで、毎日自動で残量を計測し、在庫切れをメールやWeb APIで通知する在庫管理IoT「sphere-weight」を自社製品として開発開始。ロードセル×ESP32・電池駆動の技術構成、PoCの現在地、自動発注・ダッシュボード・トレーサビリティ・需要予測まで在庫と発注を一元管理するロードマップ、クラウドファンディングでの製品化予定を紹介します。 URL: https://technosphere.co.jp/blog/sphere-weight-inventory-iot ** 目次 1. はじめに：在庫管理の「ちょうどいい」が無い 2. sphere-weightとは：載せるだけの在庫管理 3. 技術の中身：ロードセル×ESP32×電池駆動 4. PoCの現在地 5. 製品化ロードマップ：在庫・発注の一元管理へ 6. クラウドファンディングで製品化へ 7. よくある質問（FAQ） 8. まとめ ** 本記事について 本記事は、当社が自社製品として開発を進めている在庫管理IoT「sphere-weight（スフィアウェイト）」の開発記録です。掲載しているデバイス・画面のビジュアルは**開発中のコンセプトイメージ**であり、実際の製品とは異なる場合があります。 ## はじめに：在庫管理の「ちょうどいい」が無い きっかけは、あるお客様からいただいた「資材の在庫管理をなんとかしたい」というご相談でした。段ボールや梱包資材のような**日々どんどん減っていく在庫**は、今も多くの現場で目視と手作業で管理されています。数え忘れ、発注の遅れ、そして気づいたときには欠品——どこの現場でも起きている光景です。 既製のIoT在庫管理サービスも検討しました。しかし調べてみると、大規模導入を前提とした月額プランで**小規模な現場には費用が合わない**か、逆に汎用の小型スケール型で**大きな資材やお客様ごとの運用に融通が利かない**か、の二択に近い状況でした。「10〜30箇所くらいを、現場に合う形で、無理のない費用で見張りたい」——この**「ちょうどいい」を埋める製品が見当たらない**のです。 それなら、組込システムの開発会社である当社が自分たちで作ろう。そう決めて、**重量センサー式の在庫管理IoT「sphere-weight」**の開発を自社製品として始めました。 ## sphere-weightとは：載せるだけの在庫管理 （図: 白い重量センサーパッドの上に在庫容器が載り、WiFiの電波マークが表示されているコンセプトイメージ） コンセプトイメージ：容器を載せておくだけで残量を自動計測 sphere-weightのコンセプトは**「現場の運用を一切変えない在庫管理」**です。使い方は、在庫の容器や資材を重量センサー台に載せておく——それだけです。 - **載せるだけ**——バーコード読取も日々の入力も不要。重さから残量を自動換算します - **電池駆動・配線レス**——電源工事が不要で、棚のレイアウトを変えずに設置できます - **毎日自動チェック＆通知**——1日1回、決まった時刻に残量を確認し、しきい値を下回るとメールなどでお知らせします 「リアルタイム監視ではなく1日1回」というのは意図的な割り切りです。段ボールや資材の在庫は分単位では動きません。チェック頻度を運用実態に合わせて絞ることで、後述するとおり**電池だけで長期間動く設計**が可能になり、導入のハードルが大きく下がります。 ## 技術の中身：ロードセル×ESP32×電池駆動 （図: 天板・ロードセル・ESP32基板・単3電池・ベース筐体に分解された試作機の構成イメージ） 試作機の構成イメージ：天板／ロードセル／制御基板／電池／筐体 ハードウェアは、実績のある枯れた部品だけで構成しています。 | 要素 | 採用技術 | ポイント | | **計量** | ロードセル＋専用ADC（HX711） | 体重計などで広く使われる高精度・低消費電力の定番構成。複数セルの切替にも対応 | | **制御・通信** | ESP32（WiFi内蔵マイコン） | 計測から通知送信までワンチップ。安価で入手性がよく量産にも向く | | **電源** | 単3電池＋ディープスリープ | 普段は深い省電力状態で待機し、1日1回だけ起きて計測・送信。配線工事ゼロ | | **通知** | メール／Web API | 担当者へのメールに加え、既存の発注システムへJSONで直接連携できる設計 | 設計の要は**電力収支**です。WiFi接続は電力を食うため、常時接続のIoTデバイスは電池運用が困難です。sphere-weightは「起床→計測→判定→送信→スリープ」を短時間で終える動作サイクルに徹することで、稼働時間を1日あたり数十秒レベルに抑え、乾電池での長期運用を狙っています。実際にどこまで持つかは、今まさに実測で検証しているところです。 また計量面では、容器の重さ（風袋）を差し引いて残量に換算するキャリブレーションや、温度・経年によるゼロ点ドリフトへの補正など、**「秤を現場に置きっぱなしにする」からこそ必要になる処理**を作り込んでいます。 ## PoCの現在地 （図: 時計・センサーパッド・クラウド・メールが円環でつながる1日1回の自動チェックサイクルのイメージ） 1日1回の自動チェックサイクル：起床→計測→判定→通知→スリープ 現在は、ご相談をいただいたお客様の現場で実際の資材を使って検証する**PoC（実証実験）に向けて、試作機の開発を進めている段階**です。ハードウェアは協力会社とともに回路・筐体の設計を固め、並行してファームウェアと通知バックエンドの実装を進めています。 PoCで確かめるのは、机上では答えが出ない次の3点です。 - **計量の実用精度**——実際の資材・容器で、発注判断に足る精度が出るか - **電池の実寿命**——現場のWiFi環境で、電池交換なしにどれだけ運用できるか - **通知の実用性**——「いつ・誰に・どう知らせれば」発注遅れが実際になくなるか この結果をもとに量産設計へ進みます。試作機は回路を1枚の専用基板に集約し、ロードセルの本数や測定台のサイズ・材質を用途に合わせて変えられる構成を予定しており、**資材・粉体・液体など幅広い在庫への横展開**を見据えています。 ## 製品化ロードマップ：在庫・発注の一元管理へ （図: 複数の建物に設置されたセンサーパッドがクラウドにつながるネットワークのイメージイラスト） 製品版のイメージ：複数拠点の在庫をクラウドで一元管理 PoCの「計って、知らせる」を出発点に、製品版では**在庫データを業務に還元する機能**を段階的に盛り込んでいきます。目指すのは、在庫の状況確認から発注、使用履歴の記録、先々の予測までを**ひとつの画面で完結できる一元管理システム**です。 | 機能 | 内容 | | **通知の拡充** | メールに加えチャットツールへの通知、複数宛先・複数しきい値（早期アラート）対応 | | **自動発注** | 発注点を下回ったら発注データを自動作成し、Web APIで既存の発注フロー・購買システムへ連携。「気づいたら発注まで終わっている」を目指します | | **ダッシュボード** | 複数拠点・多品目の在庫状況をブラウザで一覧。在庫推移のグラフ化で「減り方」まで見える化 | | **トレーサビリティ** | 毎日の計量履歴をそのまま入出庫の記録として蓄積。「いつ・どの拠点で・どれだけ使ったか」を後から遡って確認できます | | **分析・予測** | 日々の計量データから消費ペースを分析し、在庫切れ日の予測（需要予測）や発注点・発注量の最適化を提案 | 毎日の計量値は、それ自体が**現場の消費実態を写した時系列データ**です。ただ通知するだけでなく、蓄積したデータを需要予測や発注最適化につなげていくところに、AI・データ分析を手がけてきた当社らしさを出していきます。 ## クラウドファンディングで製品化へ sphere-weightの量産・製品化にあたっては、**クラウドファンディングの活用を予定**しています。開発の様子をオープンにしながら、「うちの現場でも使いたい」という声を集め、支援いただいた方には先行導入の形でお届けする——そんな進め方を準備しています。 「在庫の数え忘れをなくしたい」「PoCに参加してみたい」「クラウドファンディングが始まったら知りたい」という方は、ぜひ[お問い合わせフォーム](https://technosphere.co.jp/contact)からご連絡ください。プロジェクトの進捗は本ブログでも継続して発信していきます。 ## よくある質問（FAQ） Q. 既製の在庫管理サービスと何が違うのですか？ A. 「容器を載せておくだけ」に機能を絞り、バーコード読取や日々の入力を一切なくした点です。電池駆動・配線レスで現場のレイアウトを変えずに設置でき、通知先やしきい値もお客様の運用に合わせて柔軟に対応します。中小規模の現場でも導入しやすい構成・価格を目指しています。 Q. どんな在庫・現場に向いていますか？ A. 粉体・液体・小さな部品・梱包資材など、「数えるのが面倒」「気づいたら切れている」タイプの在庫に向いています。研究所・工場・倉庫・店舗バックヤードなど、屋内でWiFiが届く場所であれば設置できます。 Q. いつから使えますか？ A. 現在はお客様の現場での実証（PoC）に向けて試作機を開発している段階です。製品化はクラウドファンディングの活用を予定しています。先行導入やPoCへのご参加にご興味があれば、お問い合わせフォームからご連絡ください。 ## まとめ 在庫管理の現場には、大規模向けサービスと汎用品のあいだに「ちょうどいい」の空白があります。sphere-weightは、**載せるだけ・電池駆動・毎日自動チェック**というシンプルさでその空白を埋めにいく、当社の新しい自社製品です。 まずはPoCで計量精度・電池寿命・通知の実用性を検証し、自動発注・ダッシュボード・トレーサビリティ・需要予測まで在庫と発注を一元管理する製品版へ——クラウドファンディングを通じて、開発の過程もオープンにお見せしていく予定です。続報をどうぞお楽しみに。 なお当社では、sphere-weightのような**センサー×マイコン×クラウドのIoTシステム開発**を、企画段階のPoCから量産まで一貫してお手伝いしています。「現場のこの作業、自動で見張れないか？」という段階のご相談も歓迎です。 --- # STM32Cube.AI で TinyML を量産品質に｜学習済みモデルの C コード化とリンカスクリプトによる SRAM / Quad-SPI Flash メモリ配置最適化｜株式会社テクノスフィア > STM32Cube.AI で Keras/TFLite/ONNX を STM32 用 C コードに変換。SRAM・Flash・外部 QSPI への重み配置最適化、MPU/D-Cache 設定、STM32N6 NPU まで AN5050/UM2526 を一次資料に解説。 URL: https://technosphere.co.jp/blog/stm32-cube-ai-tinyml ** 目次 1. はじめに：学習はできた、で実装は？ 2. STM32Cube.AI とは（X-CUBE-AI / AI Studio / Edge AI Suite） 3. 生成コードのファイル構成とメモリ 3 区分 4. メモリ階層と速度の関係（STM32H7 を例に） 5. 重み配置の 5 パターンとトレードオフ 6. リンカスクリプト書き換え実践 7. MPU + D-Cache 最適化 8. CubeMX / CubeIDE での実装ワークフロー 9. 最新動向：STM32N6 + Neural-ART NPU 10. 公式リソース・参考文献 11. まとめ ** 本記事の前提 本記事は **STM32Cube.AI (X-CUBE-AI) v10 系**を念頭に、STM32H7 / U5 を主軸として解説します。STM32N6（最新 NPU 搭載品）にも触れます。リンカスクリプト書き換えは GCC ベース（STM32CubeIDE / Arm GNU Toolchain）の `.ld` 書式で示しますが、IAR / Keil でも考え方は同じです。 ## はじめに：学習はできた、で実装は？ 「Keras で MobileNet を学習させて 98% の精度が出た。さあ STM32 に載せよう」――ここで多くのエンジニアが詰まります。モデルサイズが **内蔵 Flash 容量を超える**、または載せても **推論速度がリアルタイム要件に届かない**。さらにバッテリ駆動製品なら **消費電流もシビア**。 これらをワンセットで解決するのが **STM32Cube.AI（旧 X-CUBE-AI）**です。Keras / TFLite / ONNX で学習済みのモデルを **量子化 + 最適化 + STM32 専用 C コード化**し、さらに重み（weights）を **外部 Quad-SPI Flash に置いて Memory-Mapped Mode で読みに行く**といった配置最適化まで可能です。 本記事は「Cube.AI で C コード化できた、でも内蔵 Flash に収まらない / 動かない」段階のエンジニアが、**リンカスクリプト（.ld ファイル）書き換えレベル**で外部メモリ配置に踏み込めるよう、ST 公式の **UM2526 / AN5050 / AN4839** を一次資料に体系化します。基礎となる DMA は [STM32 DMA 完全ガイド](https://technosphere.co.jp/blog/stm32-dma-complete-guide)、FreeRTOS との連携は [STM32 + FreeRTOS 入門](https://technosphere.co.jp/blog/stm32-freertos-intro) を併せてご覧ください。 ** 弊社での活用実績 弊社は [画像認識・組込み AI 案件を多数](https://technosphere.co.jp/embedded-achievements) 手がけており、STM32 系のエッジ推論実装でリンカスクリプト書き換えやキャッシュ最適化を伴う案件のノウハウを蓄積しています。本記事はその実案件で踏んだ落とし穴と公式ドキュメントの読み解きを整理したものです。 ## STM32Cube.AI とは（X-CUBE-AI / AI Studio / Edge AI Suite） 2026年現在、ST のエッジ AI ツールは **「ST Edge AI Suite」**というブランド傘下に統合されつつあります。整理すると： | ツール | 位置付け | 使う場面 | | **X-CUBE-AI (STM32Cube.AI)** | CubeMX 内蔵ミドルウェアパック。MCU 向けコード生成の中核 | 既存の CubeMX フローを継続する案件 | | **STM32Cube AI Studio** | 2025-2026 リリースの新スタンドアロンデスクトップツール | 新規案件で、量子化～ベンチマーク～デプロイを統合 UI で進めたい | | **NanoEdge AI Studio** | AutoML（異常検知中心）、オンデバイス学習可 | 異常検知 / 1-class classification | | **ST Edge AI Developer Cloud** | オンライン版、board farm で実機ベンチ可 | 実機を持たずにベンチマーク取得したい | | **X-LINUX-AI** | STM32 MPU (Linux) 向け | STM32MP1 / MP2 系 | ### X-CUBE-AI の基本機能 - **対応モデル形式**：Keras (.h5) / TFLite (.tflite) / ONNX (.onnx) / scikit-learn 等 - **最適化**：量子化（int8）、Pruning、メモリ最適化（共有バッファ活用） - **対応 STM32 系列**：F3 / F4 / F7 / G4 / H7 / L4 / L4+ / L5 / WB / WL（H5 / U5 は最新版で要確認）。**N6 は NPU 経由でサポート** - **AI Validation**：PC 上での精度比較（validate on desktop）+ 実機での推論時間・精度検証（validate on target） - **統合形態**：CubeMX のソフトウェアパック / CubeIDE プラグイン / CLI（`stm32ai` / `stedgeai`） (出典: UM2526「Getting started with X-CUBE-AI Expansion Package」) ## 生成コードのファイル構成とメモリ 3 区分 X-CUBE-AI が CubeMX 経由で生成するファイルは典型的に以下の構成です。 ``` X-CUBE-AI/App/ ├── app_x-cube-ai.c / .h // MX_X_CUBE_AI_Init / Process（ユーザが触る層） ├── network.c / .h // 推論関数（ai_network_create / init / run） ├── network_data.c / .h // 重みデータ（const 配列）と参照関数 ├── network_config.h // モデルメタデータ（テンソル形状等） └── network_generate_report.txt // メモリ・MAC 使用量レポート ``` ### 覚えるべきは「Weights / Activations / I/O buffers」の 3 区分 X-CUBE-AI の世界では、モデルが消費するメモリは次の 3 つに分けられます。 | 区分 | 内容 | デフォルト配置 | 典型サイズ | | **Weights** | 推論パラメータ（モデル重み） | 内蔵 Flash（`const` 配列） | 数十 KB ～ 数 MB | | **Activations** | レイヤ間中間バッファ（推論中のみ使用） | 内蔵 RAM | 数 KB ～ 数百 KB | | **I/O buffers** | 入力テンソル / 出力テンソル | 内蔵 RAM | 数百 B ～ 数十 KB | ** RAM 節約の定番テクニック CubeMX の X-CUBE-AI 設定で **"Use activation buffer for input/output"** をオンにすると、I/O バッファを activations と兼用してくれます。これだけで RAM 使用量が数〜数十 KB 削減されることが多く、まず最初に試すべきオプションです。 ## メモリ階層と速度の関係（STM32H7 を例に） STM32H7 系は、AI 用途で最もよく使われる MCU の一つです。多階層のメモリ構造を持ち、各層でアクセス速度が大きく異なります。(出典: AN4891「STM32H72x/H73x system architecture and performance」/ RM0433) | メモリ | アドレス | 典型サイズ | レイテンシ | 備考 | | **ITCM** | 0x00000000 | 64 KB | 0 wait state | コア最近接、命令専用 | | **DTCM** | 0x20000000 | 128 KB | 0 wait state | コア最近接、データ専用 | | AXI SRAM (RAM_D1) | 0x24000000 | 512 KB | 数サイクル | D-Cache 有効可 | | SRAM (RAM_D2) | 0x30000000 | 288 KB | 数サイクル | - | | SRAM (RAM_D3) | 0x38000000 | 64 KB | 数サイクル | - | | 内蔵 Flash | 0x08000000 | 最大 2 MB | キャッシュ要 | 64-128 bit バス幅 | | **外部 OCTOSPI/QSPI（Memory-Mapped）** | 0x90000000 | 8 MB ～ | **大幅レイテンシ** | 4-bit / 8-bit シリアル | ** 内蔵 Flash と Quad-SPI Flash の帯域差は約 1 桁 内蔵 Flash は **64-128 bit バス**で接続されているのに対し、Quad-SPI Flash は **4 bit シリアル**です。OCTOSPI でも 8 bit。**理論帯域差は約 8-16 倍**あります。さらに Quad-SPI は SPI ベースなのでオーバーヘッドが大きく、実測では **10 MB/s 程度**に収まる報告もあります（STM32H735 ユーザ実測）。これを Cache 有効化で何倍にも改善するのが本記事の主役テクニックです。 ## 重み配置の 5 パターンとトレードオフ X-CUBE-AI 公式が STM32H747I-DISCO の FoodReco サンプル等で示している、重み・活性化の配置パターンは大きく **5 つ**です。(出典: AI:How to run larger models on STM32H747I-DISCO wiki / UM2611) | パターン | Weights | Activations | 特徴 | | ① 標準 | 内蔵 Flash | 内蔵 RAM | 最高速。サイズ限界が早い | | ② Ext_Qspi | 外部 QSPI | 内蔵 RAM | 大モデル可。推論は遅い | | ③ Split_Qspi | 内蔵 Flash + QSPI 分割 | 内蔵 RAM | ホット層を内蔵、大層を外部 | | ④ Ext_Sdram | QSPI | 外部 SDRAM | 大活性化対応 | | ⑤ Split_Sdram | 起動時 QSPI→SDRAM コピー | SDRAM | `WEIGHT_EXEC_EXTRAM=1`。SDRAM から実行 | ### 選択ガイド - **モデル < 内蔵 Flash 容量 - アプリ用領域**：迷わず① - **モデル数 MB、推論レイテンシ寛容**：② - **モデル数 MB、最初の数層は高速処理したい**：③（最重要） - **大画像 ResNet 等で活性化バッファが内蔵 RAM を超える**：④ - **QSPI 読出しでも遅い、SDRAM を持っている**：⑤ ## リンカスクリプト書き換え実践 パターン② Ext_Qspi（重みを QSPI に配置）を例に、リンカスクリプトの書き換え手順を示します。STM32H750 を題材にした典型例です。(出典: AN5050「Getting started with OCTOSPI, HEXADECASPI and XSPI interface」/ ControllersTech 公開例) ### Step 1：MEMORY ブロックに QSPI を追加 CubeIDE 生成の `STM32H750xx_FLASH.ld`（または同等ファイル）の MEMORY セクションに QSPI 領域を追加します。 ``` MEMORY { ITCMRAM (xrw) : ORIGIN = 0x00000000, LENGTH = 64K DTCMRAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K RAM_D1 (xrw) : ORIGIN = 0x24000000, LENGTH = 512K RAM_D2 (xrw) : ORIGIN = 0x30000000, LENGTH = 288K RAM_D3 (xrw) : ORIGIN = 0x38000000, LENGTH = 64K FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 128K QSPI (rx) : ORIGIN = 0x90000000, LENGTH = 8M /* ← 追加 */ } ``` ### Step 2：SECTIONS に重み専用セクションを追加 ``` SECTIONS { /* （既存の .isr_vector / .text / .rodata / .data / .bss 等は省略） */ .nn_weights : { . = ALIGN(4); *(.nn_weights*) /* このパターンに合致する入力セクションを集める */ . = ALIGN(4); } > QSPI /* QSPI 領域に配置 */ } ``` ### Step 3：重み配列に section 属性を付ける（生成コードを編集しない方法） X-CUBE-AI 公式は **「生成された network_data.c は編集しない」**を推奨します。代わりに、CubeMX の X-CUBE-AI 設定で **"Split weights using linker script"** オプションを有効化すると、重みが `.nn_weights*` 系のセクション名を持って生成されるので、Step 2 のリンカ側で配置を指定するだけで済みます。(出典: X-CUBE-AI documentation) 手動で配置を指定する必要がある場合（例：別のラッパーから重みを参照する場合）は、ソース側で `__attribute__((section(...)))` を付ける方法もあります。 ``` __attribute__((section(".nn_weights"))) const ai_u8 ai_network_data_weights[] = { /* 重みバイナリ */ }; ``` ### Step 4：起動コードで XSPI Memory-Mapped Mode を main 冒頭に有効化 これが最も重要かつ落とし穴の多いステップです。**XSPI Memory-Mapped Mode は main() の冒頭で有効化する必要があります**。これより前に重みアクセスする初期化コード（C++ コンストラクタ、`__libc_init_array()` 内の初期化等）が走るとハードフォルトします。 ``` int main(void) { HAL_Init(); SystemClock_Config(); /* ★ ここで XSPI を Memory-Mapped Mode に。重みアクセスの前に必須 */ MX_OCTOSPI1_Init(); BSP_QSPI_Init(); BSP_QSPI_EnableMemoryMappedMode(); /* 必要なら MPU + Cache 設定（次セクション） */ MPU_Config(); SCB_EnableICache(); SCB_EnableDCache(); /* ここから先で QSPI 上の重みを参照できる */ MX_X_CUBE_AI_Init(); while (1) { MX_X_CUBE_AI_Process(); } } ``` ## MPU + D-Cache 最適化 QSPI Memory-Mapped Mode はそのままでは遅いですが、**MPU で Cacheable 領域として設定 + D-Cache 有効化**することで、初回読込み後はキャッシュヒットで内蔵 SRAM 並の速度を実現できます。(出典: AN4839「Level 1 cache on STM32F7 / STM32H7」/ AN4838「Managing the MPU」) ### MPU 設定の鉄則（QSPI / OCTOSPI 領域） - **Cacheable + Bufferable + Not Shareable + XN=0** が定石 - Cortex-M7 では、何も設定しないと QSPI 領域は **Strongly Ordered** として扱われ、投機読み (speculative read) でバスエラーが起きる事例あり → 必ず MPU で明示設定 - **Shareable に設定すると D-Cache が無効化される**（F7/H7 系）。共有しない領域は Shareable = 0 - 重みは Read-Only なので **Write-Through / Write-Back の選択は影響しない**。Read-allocate のみ重要 ### MPU 設定コード例（QSPI 領域 8MB を Cacheable に） ``` void MPU_Config(void) { MPU_Region_InitTypeDef MPU_InitStruct = {0}; HAL_MPU_Disable(); /* QSPI 領域: 0x90000000, 8MB, Cacheable Normal Memory */ MPU_InitStruct.Enable = MPU_REGION_ENABLE; MPU_InitStruct.Number = MPU_REGION_NUMBER0; MPU_InitStruct.BaseAddress = 0x90000000; MPU_InitStruct.Size = MPU_REGION_SIZE_8MB; MPU_InitStruct.SubRegionDisable = 0x00; MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL1; MPU_InitStruct.AccessPermission = MPU_REGION_PRIV_RO_URO; /* Read-Only */ MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_ENABLE; MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE; MPU_InitStruct.IsCacheable = MPU_ACCESS_CACHEABLE; MPU_InitStruct.IsBufferable = MPU_ACCESS_BUFFERABLE; HAL_MPU_ConfigRegion(&MPU_InitStruct); HAL_MPU_Enable(MPU_PRIVILEGED_DEFAULT); } ``` その後 `SCB_EnableICache()` / `SCB_EnableDCache()` を呼ぶ順序を守れば、Cache 効果で **QSPI 重み読み出しが初回後は数倍速くなります**。 ** STM32U5 の DCACHE は分業構成 STM32U5 は **DCACHE が 2 系統**あり、DCACHE1 は外部 RAM（OCTOSPI / HSPI / FMC）専用、DCACHE2 は内部 RAM 用に分業しています。重みを外部メモリに置く設計では DCACHE1 の設定が重要です。(出典: AN5212「How to use STM32 cache to optimize performance」/ STM32U5 system cache training) ## CubeMX / CubeIDE での実装ワークフロー 0 から実装を始める場合の標準ステップです。 1. STM32CubeMX で対象 MCU を選択（H743 / H747 / U585 / N657 など） 2. **Software Packs → STMicroelectronics.X-CUBE-AI** を Enable 3. 左ペインの X-CUBE-AI セクションで **"Add network"** → モデルファイル（.h5 / .tflite / .onnx）を投入 4. 設定： - Compression（1x / 4x / 8x） - Optimization（Time / Balanced / RAM） - **Use activation buffer for input/output**（RAM 節約） - **Split weights using linker script**（外部メモリ配置するなら必須） 5. **"Analyze"** でメモリフットプリント・MAC 数を確認 6. **"Validate on Desktop / Target"** で精度・推論時間を実測 7. Project Manager → Code Generator → **"Generate Code"** 8. main.c に自動追加された `MX_X_CUBE_AI_Init()`（初期化）と `MX_X_CUBE_AI_Process()`（推論ループ）を確認 9. （外部メモリ配置する場合）リンカスクリプト編集 + main 冒頭で BSP_QSPI_Init / MemoryMappedMode 呼出し追加 10. ビルド → 書き込み → 動作確認 ## 最新動向：STM32N6 + Neural-ART NPU 2024年12月にリリースされた **STM32N6** は、ST 史上初の **内蔵 NPU 搭載マイコン**です。X-CUBE-AI / ST Edge AI Suite の今後の主軸となる品種です。 ### 主な仕様 - **CPU**：Arm Cortex-M55 @ 800 MHz（Helium SIMD 拡張搭載） - **NPU**：ST 自社開発 **Neural-ART Accelerator @ 1 GHz、最大 600 GOPS**（電力効率は ST 公称で 3 TOPS/W 級。具体値は最新の製品資料を参照） - **内蔵 RAM**：4.2 MB の連続 embedded RAM（STM32 史上最大） - **内蔵 Flash なし**：外部 OCTOSPI / HSPI / FMC からブート前提 - NeoChrom GPU、H.264 エンコーダ、JPEG、MIPI CSI-2 + ISP も内蔵 (出典: ST blog stm32n6 / STM32N6 Series page) ### X-CUBE-AI v10 連携時の特殊事情 NPU 利用時、X-CUBE-AI は `[modelname]_atonbuf.AXISRAM5.raw` という extra raw ファイルを生成します。これは **NPU からアクセス可能なメモリに実行時にロードする必要**があり、リンカスクリプトでの配置だけでなく起動時ローダコードの記述も必要です。(出典: ST Community td-p/813915) 2026 年現在、CubeMX が N6 を完全にサポートできていない事例も報告されており（生成時エラー、メモリ未活性化など）、量産案件で採用するなら ST のサポートエンジニアと密に連携することを強く推奨します。 ## 公式リソース・参考文献 ### 最重要 Application Note / User Manual - **UM2526** – Getting started with X-CUBE-AI Expansion Package for AI（日本語版あり） [st.com → UM2526 PDF](https://www.st.com/resource/en/user_manual/um2526-getting-started-with-xcubeai-expansion-package-for-artificial-intelligence-ai-stmicroelectronics.pdf) - **UM2611** – AI and Computer Vision function pack for STM32H7 (FP-AI-VISION1) [st.com → UM2611 PDF](https://www.st.com/resource/en/user_manual/dm00630755-artificial-intelligence-ai-and-computer-vision-function-pack-for-stm32h7-microcontrollers-stmicroelectronics.pdf) - **AN5050** – Getting started with OCTOSPI, HEXADECASPI and XSPI interface on STM32 MCUs [st.com → AN5050 PDF](https://www.st.com/resource/en/application_note/an5050-getting-started-with-octospi-hexadecaspi-and-xspi-interface-on-stm32-mcus-stmicroelectronics.pdf) - **AN5188** – External memory code execution on STM32H750 / H7B0 / H730 / F7x0 value line [st.com → AN5188 PDF](https://www.st.com/resource/en/application_note/dm00514974-external-memory-code-execution-on-stm32f7x0-and-stm32h7x0-value-line-microcontrollers-stmicroelectronics.pdf) - **AN4839** – Level 1 cache on STM32F7 / STM32H7 Series [st.com → AN4839 PDF](https://www.st.com/resource/en/application_note/an4839-level-1-cache-on-stm32f7-series-and-stm32h7-series-stmicroelectronics.pdf) - **AN4838** – Managing memory protection unit in STM32 MCUs [st.com → AN4838 PDF](https://www.st.com/resource/en/application_note/dm00272912-managing-memory-protection-unit-stm32-mcus-stmicroelectronics.pdf) - **AN5212** – How to use STM32 cache to optimize performance and power [st.com → AN5212 PDF](https://www.st.com/resource/en/application_note/an5212-how-to-use-stm32-cache-to-optimize-performance-and-power-efficiency-stmicroelectronics.pdf) ### Reference Manual / Datasheet - **RM0433** – STM32H743 Reference Manual - **AN4891** – STM32H72x/H73x/H74x/H75x system architecture and performance - **AN5872** – Introduction to the system architecture and performance in STM32H5 MCUs ### ベンチマーク / モデル Zoo - [ST Wiki – STM32Cube.AI Model Performances（公式ベンチマーク表）](https://wiki.st.com/stm32mcu/wiki/AI:STM32Cube.AI_model_performances) - [GitHub – ST AI Model Zoo（140+ モデル）](https://github.com/STMicroelectronics/stm32ai-modelzoo) - [GitHub – ST AI Model Zoo Services](https://github.com/STMicroelectronics/stm32ai-modelzoo-services) - MLPerf Tiny v1.2（2024年4月）/ v1.3 ベンチマーク ### 関連製品ページ - [X-CUBE-AI 製品ページ](https://www.st.com/en/embedded-software/x-cube-ai.html) - [ST Edge AI Developer Cloud](https://stedgeai-dc.st.com/) - STM32N6 Series Page ## まとめ ### この記事のまとめ - STM32Cube.AI (X-CUBE-AI) は Keras / TFLite / ONNX を STM32 用 C コードに変換する公式ツール。2026 年は **STM32Cube AI Studio** 移行期 - メモリ消費は **Weights / Activations / I/O buffers** の 3 区分で把握。"Use activation buffer for input/output" でまず RAM 節約 - 内蔵 Flash と外部 QSPI Flash の帯域差は約 1 桁。**MPU + D-Cache 最適化で実用速度に** - 重み配置の主要 5 パターン：標準 / Ext_Qspi / Split_Qspi / Ext_Sdram / Split_Sdram。**Split_Qspi が大モデル × レイテンシ要件の現実解** - リンカスクリプトに **QSPI MEMORY 追加 → `.nn_weights` セクションを QSPI に配置** + **main 冒頭で BSP_QSPI Memory-Mapped Mode 有効化** が定石 - MPU 設定は Cacheable + Bufferable + Not Shareable + XN=0。Cortex-M7 で Strongly Ordered のまま放置すると投機読みでクラッシュ - STM32N6 + Neural-ART NPU は次世代の本命。CubeMX のサポート成熟度はまだ過渡期 STM32 を使った組込み AI 推論や TinyML 量産設計でお困りのことがあれば、弊社にお気軽にご相談ください。画像認識・AI 案件の実績をもとに、モデル選定から MCU 選定・メモリ配置最適化・量産品質まで一貫してサポートします。 STM32 + TinyML / エッジ AI 推論の PoC、モデル軽量化、量産品質の確保まで [組込み制御・マイコン開発](https://technosphere.co.jp/embedded) として対応しています。 ／この内容の受託開発・PoC相談はこちら＼ ### STM32 + TinyML / エッジ AI の受託開発・PoC STM32Cube.AI / X-CUBE-AI を活用した予知保全・異常検知・キーワード認識・画像認識など、組込みエッジ AI の試作 PoC からモデル軽量化・量産品質確認まで一貫して対応します。 [組込み開発サービスを見る](https://technosphere.co.jp/embedded) [AI開発サービスを見る](https://technosphere.co.jp/ai-solution) [TinyML・エッジAI 相談](https://technosphere.co.jp/contact) # STM32 # STM32Cube.AI # X-CUBE-AI # TinyML # エッジAI # リンカスクリプト # Quad-SPI # STM32H7 # STM32N6 ## 次に読む｜STM32 シリーズ記事 - [STM32 シリーズ STM32 DMA 完全ガイド｜UART・SPI・ADCとの連携 推論結果のストリーミング転送に必須](https://technosphere.co.jp/blog/stm32-dma-complete-guide) - [STM32 シリーズ STM32 + FreeRTOS 入門 推論タスクと他処理を並列化したい場合に](https://technosphere.co.jp/blog/stm32-freertos-intro) - [STM32 シリーズ STM32G4 内蔵アナログ計測誤差の罠 前処理段のアナログ品質を上げて精度を底上げ](https://technosphere.co.jp/blog/stm32-g4-analog-precision) - [開発実績 組込み制御・マイコン開発 実績紹介 画像認識・AI 案件を含む 20 年超の事例](https://technosphere.co.jp/embedded-achievements) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # STM32開発ガイド 総目次｜通信・DMA・RTOS・低消費電力・デバッグの実装記事まとめ｜株式会社テクノスフィア > STM32マイコン開発の実装ガイド7本を開発フェーズ別に整理した総目次。UART/I2C/SPI/CAN通信、DMA、FreeRTOS、低消費電力設計、アナログ計測、ST-LINKトラブル、TinyMLまで。組込み受託開発のテクノスフィアが実務目線で解説。 URL: https://technosphere.co.jp/blog/stm32-development-guide ** 目次 1. このガイドの使い方 2. 開発フェーズ別・記事の読み方マップ 3. 1. ペリフェラル通信を実装する 4. 2. DMAでCPU負荷を下げる 5. 3. RTOSで処理を並行化する 6. 4. バッテリー駆動・低消費電力設計 7. 5. 内蔵アナログで精度を出す 8. 6. エッジAI（TinyML）を載せる 9. 7. デバッガが繋がらない時に読む 10. 今後追加予定のテーマ ## このガイドの使い方 当ブログではSTM32マイコンの実装ガイドを継続的に公開しており、通信・DMA・RTOS・低消費電力・アナログ計測・エッジAI・デバッグの7本が揃いました。各記事はST公式のアプリケーションノートやリファレンスマニュアルを一次資料として、STM32CubeMXの設定手順とHALベースのCコードまで踏み込んだ実務者向けの内容です。 このページはその**総目次**です。「いま自分がどのフェーズで詰まっているか」から逆引きできるように、開発の流れに沿って各記事の守備範囲と読みどころを整理しました。 ## 開発フェーズ別・記事の読み方マップ | いまの状況 | 読む記事 | | センサー・モジュールと通信したい | UART・I2C・SPI・CAN実装ガイド | | 通信は動いたがCPUが重い／取りこぼす | DMA完全ガイド | | 機能が増えてスーパーループが破綻気味 | FreeRTOS入門 | | 電池で年単位の駆動が必要 | 低消費電力モード完全ガイド | | ADCの測定値が理論通りにならない | STM32G4アナログ計測の罠 | | 学習済みAIモデルをマイコンに載せたい | STM32Cube.AIでTinyML | | ST-LINKが突然繋がらなくなった | ST-LINK救出ガイド | ## 1. ペリフェラル通信を実装する ### [STM32マイコンのUART・I2C・SPI・CAN通信 実装ガイド](https://technosphere.co.jp/blog/stm32-uart-i2c-can) 4大通信ペリフェラルの使い分けから、STM32CubeMXでの設定、HALライブラリを使ったCサンプルコードまでを1本にまとめた通信の基礎記事です。ボーレート不一致やI2Cプルアップ、SPIモード（CPOL/CPHA）、CANの終端抵抗といった「動かない時の定番チェックポイント」も網羅しています。 **こんな時に:** 新規基板の立ち上げでセンサー・無線モジュール・外部ICとの接続を最短で動かしたい時。 ## 2. DMAでCPU負荷を下げる ### [STM32 DMA 完全ガイド｜UART・SPI・ADCとの連携でCPU負荷を最小化](https://technosphere.co.jp/blog/stm32-dma-complete-guide) DMAコントローラの基礎（チャネル方式／ストリーム方式）から、CubeMX設定、Normal/Circularモード、そして実務の定番である**UART受信DMA＋IDLE割込みによる可変長フレーム受信**、SPI大容量転送、ADC連続サンプリングまでを網羅。STM32H7のD-CacheとDMAバッファ不整合という上級者向けの落とし穴にも触れています。 **こんな時に:** 通信・計測の頻度が上がりCPU処理が追いつかない時。ポーリング実装から本番品質へ引き上げる時。 ## 3. RTOSで処理を並行化する ### [STM32 + FreeRTOS 入門｜タスク・キュー・セマフォを使ったRTOS実装ガイド](https://technosphere.co.jp/blog/stm32-freertos-intro) STM32CubeMXでFreeRTOSを有効化し、CMSIS-OS v2ベースでタスク・キュー・セマフォ・ミューテックスを実装する入門記事です。ISRからのFromISR系API使用や割り込み優先度（configMAX_SYSCALL_INTERRUPT_PRIORITY）といった、初学者がHardFaultを踏みがちなポイントを重点的に解説しています。 **こんな時に:** センサー監視・通信・表示・制御が並行し、whileループでの管理が限界に来た時。 ## 4. バッテリー駆動・低消費電力設計 ### [STM32 低消費電力モード完全ガイド｜バッテリー駆動を年単位で実現する](https://technosphere.co.jp/blog/stm32-low-power-battery) STM32L4のRun/Sleep/Stop 0/1/2/Standby/Shutdownの7モードを体系的に整理し、HAL APIでのモード遷移、RTC・WKUPピン・LPUARTによるウェイクアップ、CR2032での寿命試算、実装の落とし穴までを扱う低消費電力設計の決定版です。 **こんな時に:** 電池駆動のIoTデバイスで「月単位」ではなく「年単位」の稼働が要求された時。 ## 5. 内蔵アナログで精度を出す ### [STM32G4 内蔵アナログ計測誤差の罠｜R_AINとサンプリング時間の関係](https://technosphere.co.jp/blog/stm32-g4-analog-precision) STM32G4の内蔵OPAMP・COMP・高速ADCを使う際に精度を左右する「ソース抵抗とサンプリング時間」の関係を、AN2834とデータシートを一次資料に解説。OPAMPのVoltage Follower接続による対策やErrataの注意点まで踏み込んだ、アナログフロントエンド設計者向けの記事です。 **こんな時に:** ADCの読み値が理論値とずれる・ばらつく原因を突き止めたい時。外付けアンプを減らしてコストダウンしたい時。 ## 6. エッジAI（TinyML）を載せる ### [STM32Cube.AI で TinyML を量産品質に｜モデルのCコード化とメモリ配置最適化](https://technosphere.co.jp/blog/stm32-cube-ai-tinyml) Keras/TFLite/ONNXの学習済みモデルをSTM32Cube.AIでCコードに変換し、SRAM・内蔵Flash・外部QSPI Flashへの重み配置をリンカスクリプトで最適化する手順を解説。MPU/D-Cache設定からNPU搭載のSTM32N6への展望まで、AN5050/UM2526を一次資料としています。 **こんな時に:** PoCで作ったAIモデルを、量産マイコンのメモリ制約の中に収める必要が出た時。 ## 7. デバッガが繋がらない時に読む ### [STM32でST-LINKが突然繋がらなくなった時の救出ガイド](https://technosphere.co.jp/blog/stm32-swd-debugger-rescue) 「Target was not detected」からの復旧手順を、原因別（SWDピンのGPIO誤定義・Stop/Standbyモード切断・CubeMX設定忘れ・ST-LINK本体/クローン品の問題）に体系化。Connect Under ResetとBOOT0によるSystem Memory Bootloader起動という2大復旧手段を軸に、DBGMCUレジスタによる予防策まで解説しています。 **こんな時に:** 昨日まで書き込めていたボードに突然接続できなくなった時。ブックマーク推奨の「お守り」記事です。 ## 今後追加予定のテーマ 本ガイドは記事の追加にあわせて更新していきます。現在、エッジAI向け新シリーズや新しいRTOSの選択肢、組込みセキュリティ規制対応など、開発現場の関心が高いテーマを準備中です。 個別のご相談は[組込みシステム開発](https://technosphere.co.jp/embedded)のページ、開発実績は[実績紹介](https://technosphere.co.jp/embedded-achievements)をご覧ください。 ／この内容の受託開発・PoC相談はこちら＼ ### STM32 を使った製品開発の受託 マイコン選定・回路設計・ファームウェア実装から量産前評価まで一貫対応します。「どのシリーズを選ぶべきか」「既存資産を移行できるか」といった段階のご相談も歓迎です。 [組込み開発サービスを見る](https://technosphere.co.jp/embedded) [STM32 開発の相談をする](https://technosphere.co.jp/contact?src=blog-stm32-guide-body) # STM32 # マイコン開発 # 組込み制御 # HAL # STM32CubeMX # 開発ガイド --- # STM32 DMA 完全ガイド｜UART・SPI・ADC との連携でCPU負荷を最小化｜株式会社テクノスフィア > STM32 の DMA を UART/SPI/ADC と組み合わせ CPU 負荷を最小化する実装ガイド。CubeMX 設定・Normal/Circular・ダブルバッファ・IDLE 割り込みでの可変長受信まで網羅。 URL: https://technosphere.co.jp/blog/stm32-dma-complete-guide ** 目次 1. はじめに：DMAを使うべき場面 2. DMAコントローラの基礎 3. STM32CubeMXでのDMA設定 4. UART + DMA（送信・連続受信） 5. SPI + DMA（高速転送） 6. ADC + DMA（連続サンプリング） 7. Circular モードとダブルバッファ 8. よくあるトラブルと対策 9. まとめ ## はじめに：DMAを使うべき場面 STM32の**DMA（Direct Memory Access）**は、CPUを介さずにペリフェラル⇔メモリ間でデータ転送を行うハードウェアです。CPUは転送中に別の処理を進められるため、システム全体のスループットが大幅に向上します。 具体的には次のような場面でDMAは必須級です。 - **高速UART受信：**460800bpsで連続受信しながらCPUは制御処理を続けたい - **ADCサンプリング：**1MSpsで連続A/D変換結果を取得しFFT解析へ流したい - **SPI大容量転送：**SDカード・SPIフラッシュ・LCDフレームバッファ更新 - **メモリ to メモリコピー：**大きな構造体・画像バッファのコピー 本記事の前提として、UART/I2C/SPIの基本実装は [STM32マイコンのUART・I2C・SPI・CAN通信 実装ガイド](https://technosphere.co.jp/blog/stm32-uart-i2c-can) をご覧ください。FreeRTOSと組み合わせる場合は [STM32 + FreeRTOS 入門](https://technosphere.co.jp/blog/stm32-freertos-intro) も参考になります。 ** 弊社での活用実績 弊社では振動データロガー（ADC + DMA で 100kSps 連続取得）、産業用通信ゲートウェイ（UART + DMA + IDLE割込みで可変長フレーム受信）、カメラミドルウェア（SPI/DCMI + DMA でフレーム転送）など、DMAをフル活用した [組込み開発実績](https://technosphere.co.jp/embedded-achievements) があります。 ## DMAコントローラの基礎 STM32のDMAコントローラは、シリーズごとに「チャネル方式」と「ストリーム方式」の2系統があります。設定の考え方は共通です。 ### チャネル方式 / ストリーム方式 - **STM32F1/F3/G0/G4/L0/L4/L5/U5：**DMA1/DMA2にそれぞれ複数の「チャネル」。**DMAMUX**でペリフェラル↔チャネルを自由に対応付け可能（新しい系列） - **STM32F2/F4/F7/H7：**DMA1/DMA2にそれぞれ8本の「ストリーム」、各ストリームに8チャネル。ペリフェラル⇔ストリーム⇔チャネルの組み合わせがリファレンスマニュアルで固定 ### DMA設定の主な要素 | 項目 | 意味 | 典型的な選択 | | **Direction** | 転送方向 | Periph to Mem / Mem to Periph / Mem to Mem | | **Mode** | 転送モード | Normal（1回で停止）/ Circular（リング状に永続） | | **Data Width** | 転送単位 | Byte / Half-Word / Word（ペリフェラル仕様に合わせる） | | **Increment Address** | アドレス自動加算 | メモリ側は Enable、ペリフェラル側は通常 Disable | | **Priority** | 転送優先度 | Low / Medium / High / Very High（複数DMAが競合した時の調停） | | **FIFO**（F4/F7/H7） | 内蔵FIFO使用 | 大量転送やバースト時に Enable で効率化 | ## STM32CubeMXでのDMA設定 CubeMXでDMAを設定する手順は、ペリフェラルの「DMA Settings」タブで追加するだけです。例としてUSART2の受信DMAを設定します。 ### 設定手順 1. 「Pinout & Configuration」→「USART2」を開き、「Mode」を Asynchronous に設定済みであることを確認 2. 「DMA Settings」タブで「Add」をクリック 3. 追加された行で「Select」プルダウンから **USART2_RX** を選択 4. 「Mode」を **Circular**（連続受信）または **Normal**（1回で停止）に設定 5. 「Data Width」を「Byte」に（UARTは1バイト単位） 6. 「NVIC Settings」タブで「USART2 global interrupt」と「DMA1 Stream/Channel x global interrupt」を Enable 7. 「Generate Code」で初期化コードを自動生成 ** よくあるミス DMA設定だけしてNVIC（割り込み）の有効化を忘れると、転送完了コールバックが呼ばれません。必ずペリフェラル側とDMA側**両方の割り込み**を有効にしてください。 ### 生成される初期化コード（抜粋） ``` /* main.c の MX_DMA_Init() */ static void MX_DMA_Init(void) { __HAL_RCC_DMA1_CLK_ENABLE(); HAL_NVIC_SetPriority(DMA1_Stream5_IRQn, 5, 0); // 優先度は5以上推奨（FreeRTOS併用時） HAL_NVIC_EnableIRQ(DMA1_Stream5_IRQn); } /* USART2_Init() 内に追加される DMA 連結 */ hdma_usart2_rx.Instance = DMA1_Stream5; hdma_usart2_rx.Init.Channel = DMA_CHANNEL_4; hdma_usart2_rx.Init.Direction = DMA_PERIPH_TO_MEMORY; hdma_usart2_rx.Init.PeriphInc = DMA_PINC_DISABLE; hdma_usart2_rx.Init.MemInc = DMA_MINC_ENABLE; hdma_usart2_rx.Init.PeriphDataAlignment = DMA_PDATAALIGN_BYTE; hdma_usart2_rx.Init.MemDataAlignment = DMA_MDATAALIGN_BYTE; hdma_usart2_rx.Init.Mode = DMA_CIRCULAR; hdma_usart2_rx.Init.Priority = DMA_PRIORITY_MEDIUM; HAL_DMA_Init(&hdma_usart2_rx); __HAL_LINKDMA(&huart2, hdmarx, hdma_usart2_rx); ``` ## UART + DMA（送信・連続受信） ### 送信 DMA（バーストデータの非同期送信） 大量データを送信する場合、ポーリング送信ではCPUがブロックされます。DMA送信に切り替えるとCPUは他の処理に集中できます。 ``` /* 送信DMA：最大512バイトのバッファにログを作り、実長(strlen)を非同期送信 */ uint8_t log_buf[512]; sprintf((char*)log_buf, "tick=%lu, temp=%.2f, ...\r\n", HAL_GetTick(), temp); HAL_UART_Transmit_DMA(&huart2, log_buf, strlen((char*)log_buf)); // この時点でCPUは別処理を実行可能 /* 送信完了コールバック */ void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart) { if (huart->Instance == USART2) { // 送信完了処理（次のバッファを送信、フラグを立てるなど） } } ``` ### 受信 DMA + IDLE 割込み（可変長フレーム受信の決定版） 産業機器との通信では「受信フレーム長が不定」というケースが頻出します。DMA Circular + IDLE 割り込みを組み合わせると、効率的に可変長フレームを取得できます。 ``` #define RX_BUF_SIZE 256 uint8_t rx_buf[RX_BUF_SIZE]; volatile uint16_t rx_old_pos = 0; void StartReceiveDmaIdle(void) { /* IDLE割り込みを有効化 */ __HAL_UART_ENABLE_IT(&huart2, UART_IT_IDLE); /* DMA Circular モードで連続受信開始 */ HAL_UART_Receive_DMA(&huart2, rx_buf, RX_BUF_SIZE); } /* USART2 割込みハンドラ（stm32xxxx_it.c） */ void USART2_IRQHandler(void) { /* IDLE フラグが立っていれば受信終了とみなす */ if (__HAL_UART_GET_FLAG(&huart2, UART_FLAG_IDLE)) { __HAL_UART_CLEAR_IDLEFLAG(&huart2); ProcessReceivedData(); } HAL_UART_IRQHandler(&huart2); } void ProcessReceivedData(void) { /* DMA残カウンタから現在の書き込み位置を計算 */ uint16_t pos = RX_BUF_SIZE - __HAL_DMA_GET_COUNTER(huart2.hdmarx); if (pos != rx_old_pos) { if (pos > rx_old_pos) { /* 通常領域 */ HandleFrame(&rx_buf[rx_old_pos], pos - rx_old_pos); } else { /* リング末尾 → 先頭にラップしたケース */ HandleFrame(&rx_buf[rx_old_pos], RX_BUF_SIZE - rx_old_pos); HandleFrame(&rx_buf[0], pos); } rx_old_pos = pos; } } ``` ** IDLE割込みのメリット 従来は「タイムアウト付きreceive」「1バイトずつ受信割り込み」のどちらかで対応していましたが、前者はCPUを浪費し、後者は高速通信で取りこぼします。**DMA Circular + IDLE** は両者の欠点を解消し、115200bps以上の高速通信でも確実に取りこぼし無くフレームを切り出せます。 ## SPI + DMA（高速転送） SPIは数十Mbpsの高速通信が可能ですが、CPUのSPI送受信ループでは速度が頭打ちになります。DMAを使うことで本来のバススピードを引き出せます。SPIフラッシュ、LCD、SD カード、ADCチップなどで特に効果的です。 ### SPI送受信 DMA ``` /* SPI 全二重 DMA 転送 */ uint8_t spi_tx_buf[1024]; uint8_t spi_rx_buf[1024]; HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_RESET); // CS Low HAL_SPI_TransmitReceive_DMA(&hspi1, spi_tx_buf, spi_rx_buf, 1024); // CPUは別処理を進められる /* 転送完了コールバック */ void HAL_SPI_TxRxCpltCallback(SPI_HandleTypeDef *hspi) { if (hspi->Instance == SPI1) { HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_SET); // CS High // 受信データ処理 } } ``` ### LCDフレームバッファ更新の例 320×240×16bit のLCDフレーム全更新（150KB）をCPUポーリングで書き込むと数十ms以上かかります。SPI + DMAなら数msに短縮可能です。 ``` #define LCD_W 320 #define LCD_H 240 uint16_t lcd_framebuffer[LCD_W * LCD_H]; // 150KB void Lcd_UpdateFrame(void) { Lcd_SetWindow(0, 0, LCD_W - 1, LCD_H - 1); Lcd_DcPin(GPIO_PIN_SET); // Data モード HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_RESET); /* 16bit幅、150KB相当を一気にDMA送信 */ HAL_SPI_Transmit_DMA(&hspi1, (uint8_t*)lcd_framebuffer, LCD_W * LCD_H * 2); } ``` ## ADC + DMA（連続サンプリング） ADCとDMAの組み合わせは、振動計測・音声入力・電流計測などサンプリングが必要な全てのアプリで定番です。CubeMXで ADC を Continuous Conversion + DMA + Circular に設定するのが基本です。 ### 単一チャネル連続変換 ``` #define ADC_BUF_SIZE 1024 uint16_t adc_buf[ADC_BUF_SIZE]; /* 起動時 */ HAL_ADC_Start_DMA(&hadc1, (uint32_t*)adc_buf, ADC_BUF_SIZE); /* バッファ半分埋まった時 */ void HAL_ADC_ConvHalfCpltCallback(ADC_HandleTypeDef *hadc) { if (hadc->Instance == ADC1) { // 前半 512 サンプルを処理（後半はDMAが書き込み中なので安全） ProcessSamples(&adc_buf[0], ADC_BUF_SIZE / 2); } } /* バッファ全部埋まった時 */ void HAL_ADC_ConvCpltCallback(ADC_HandleTypeDef *hadc) { if (hadc->Instance == ADC1) { // 後半 512 サンプルを処理 ProcessSamples(&adc_buf[ADC_BUF_SIZE / 2], ADC_BUF_SIZE / 2); } } ``` ### 複数チャネル（Scan モード）の取得 ADC1の chs.0,1,4,8 を順次サンプリングしてDMAに格納するパターンです。CubeMXで Rank を設定し、Scan Conversion Mode を Enable にします。 ``` #define N_CHANNELS 4 #define N_SAMPLES 100 uint16_t adc_buf[N_SAMPLES * N_CHANNELS]; // ch0, ch1, ch4, ch8 の順に格納 HAL_ADC_Start_DMA(&hadc1, (uint32_t*)adc_buf, N_SAMPLES * N_CHANNELS); /* 100サンプル × 4ch 取得完了 */ void HAL_ADC_ConvCpltCallback(ADC_HandleTypeDef *hadc) { /* 各チャネル平均値を計算 */ uint32_t sum[N_CHANNELS] = {0}; for (int i = 0; i < N_SAMPLES; i++) { for (int ch = 0; ch < N_CHANNELS; ch++) { sum[ch] += adc_buf[i * N_CHANNELS + ch]; } } for (int ch = 0; ch < N_CHANNELS; ch++) { avg[ch] = sum[ch] / N_SAMPLES; } } ``` ** 産業現場での活用例 弊社では振動データロガー案件で、ADC1+ADC2をデュアルモードで動作させ、合計 250kSps の連続取得をDMA Circular + ダブルバッファで実現しました。CPUは取得と並行してFFT処理を進めるため、リアルタイムで周波数スペクトルを更新できます。[類似の組込み開発実績](https://technosphere.co.jp/embedded-achievements) を多数ご紹介しています。 ## Circular モードとダブルバッファ ### Normal モード vs Circular モード - **Normal モード：**指定サイズ分の転送が終わるとDMA停止。次回も使うには再度 HAL_XXX_Start を呼ぶ必要がある - **Circular モード：**転送終了時に自動的にバッファ先頭へラップして継続。連続サンプリング・連続受信に最適 ### ダブルバッファ方式（DBM） STM32F4/F7/H7のDMAは「Double Buffer Mode」をサポートし、2つのバッファを自動切り替えできます。一方をDMAが埋めている間、CPUはもう一方を安全に処理できます。Circular モードよりも明確な切り替え境界が得られます。 ``` uint16_t buf_a[1024]; uint16_t buf_b[1024]; /* HALではダブルバッファ用関数を使用 */ HAL_DMAEx_MultiBufferStart_IT( &hdma_adc1, (uint32_t)&hadc1.Instance->DR, (uint32_t)buf_a, (uint32_t)buf_b, 1024 ); /* M0完了：buf_a が満杯になった */ void HAL_DMAEx_M0CpltCallback(DMA_HandleTypeDef *hdma) { Process(buf_a, 1024); // この間DMAはbuf_bを埋めている } /* M1完了：buf_b が満杯になった */ void HAL_DMAEx_M1CpltCallback(DMA_HandleTypeDef *hdma) { Process(buf_b, 1024); } ``` ** Circular の Half/Full コールバックでも代替可能 シンプルにはCircular モード + HalfCpltCallback + CpltCallback の組み合わせで「擬似ダブルバッファ」が実現できます（前半を処理中、後半にDMA書き込み）。ダブルバッファモードはより明確な境界・連続性の保証が必要な高速転送向けです。 ## よくあるトラブルと対策 | 症状 | 原因 | 対策 | | DMA転送が一度きりで止まる | Normal モードのまま使用 | 連続転送が必要なら Mode を Circular に変更。または完了コールバックで再起動 | | 受信データが化ける / 一部欠落 | Data Width 不一致 / バッファ境界 | ペリフェラル側とメモリ側のData Widthを揃える。`__DSB();` でメモリバリアを入れる | | DMA完了コールバックが呼ばれない | NVIC割り込みが無効 / 優先度設定ミス | CubeMXのNVIC タブで該当DMAストリーム/チャネル割り込みを Enable。優先度は FreeRTOS併用時5以上 | | STM32H7で受信データが意図通り読めない | D-Cache とDMAバッファの不整合 | DMAバッファ領域を non-cacheable に配置するか、`SCB_InvalidateDCache_by_Addr()` でキャッシュ無効化 | | ADC値が常に0 / 同じ値ばかり | ADC + DMA で uint32_t* キャスト忘れ | `HAL_ADC_Start_DMA(&hadc1, (uint32_t*)adc_buf, size)` のキャストを忘れない | | DMAストリーム競合エラー | F4/F7系で複数ペリフェラルが同一ストリームを取り合う | リファレンスマニュアルのDMAストリーム表を確認し、空いている組み合わせを選ぶ | | SPI DMA送信で末尾1バイトが化ける | 送信完了コールバックでCSをHighにする前にSPI内部FIFOにデータ残存 | `__HAL_SPI_GET_FLAG(&hspi1, SPI_FLAG_BSY)` がClearになるまで待ってからCSをHighに | ** デバッグの定石 - **DMAレジスタを見る：**STM32CubeIDEのSFRビューで `DMA1_Stream5->NDTR`（残転送数）を確認すれば、転送が進んでいるかが一目でわかる - **ロジックアナライザでバス信号を確認：**SPI/UARTの実信号がそもそも出ているかが切り分けの第一歩 - **D-Cache 問題（H7）はバッファ配置を疑う：**リンカスクリプトで .dma_buf セクションを non-cacheable な領域に配置するのが本道 ## まとめ ### この記事のまとめ - DMAはCPUを介さずペリフェラル⇔メモリ転送を行うハードウェア。CPUを別処理に集中させられる - UART + DMA Circular + IDLE割り込みは可変長フレーム受信の決定版パターン - ADC + DMA Circular はサンプリングデータ取得の定番。Half/FullコールバックでCPUと並行処理 - SPI + DMA はLCDフレーム更新やSDカード書き込みで効果絶大 - STM32H7ではD-Cacheとの整合に注意。DMAバッファをnon-cacheable領域に配置するのが安全 - NVIC優先度はFreeRTOS併用時5以上、ペリフェラル/DMA両方を有効化することを忘れずに STM32 DMA を使った高速通信・サンプリングシステムの開発でお困りのことがあれば、弊社にお気軽にご相談ください。設計から実装・量産対応まで、マイコン開発歴20年超のエンジニアが一貫してサポートします。 STM32 DMA を使った高速サンプリング装置・通信ゲートウェイの試作・量産設計、既存基板の高速化や移行も [組込み制御・マイコン開発](https://technosphere.co.jp/embedded) として対応しています。 ／この内容の受託開発・PoC相談はこちら＼ ### STM32 DMA・高速サンプリング装置の受託開発 ADC + DMA連続サンプリング、UART/SPI/I2Cの高速ノンブロッキング転送、産業用通信ゲートウェイなど、DMA活用が必須となる設計をテクノスフィアが請け負います。試作のPoCから量産・現場導入まで一気通貫。 [組込み開発サービスを見る](https://technosphere.co.jp/embedded) [高速通信・サンプリング相談](https://technosphere.co.jp/contact) ## よくある質問（FAQ） ** STM32のDMAはどんな場面で使うべきですか？ UARTの連続受信、ADCの連続サンプリング、SPIでの大容量転送（LCDフレームバッファ更新など）のように、高頻度・大容量のデータ転送でCPUを解放したい場面が典型です。転送中もCPUは別の処理を継続でき、リアルタイム性が向上します。 ** UARTで長さが一定しないデータを受信する定番の方法は何ですか？ 受信DMA（Circularモード）とIDLE割込みの組み合わせが決定版です。受信が途切れた時点でIDLE割込みが入るため、フレーム長が事前に分からなくても受信済みバイト数を確定して処理できます。 ** チャネル方式とストリーム方式は何が違いますか？ STM32のDMAコントローラは品種によって「チャネル方式」と「ストリーム方式」の2系統に分かれますが、転送元・転送先・優先度といった設定の考え方は共通です。STM32CubeMXを使えばどちらの方式でもGUIから同じ感覚で設定できます。 ** STM32H7でDMA受信したデータが意図通り読めないのはなぜですか？ D-CacheとDMAバッファの不整合が典型原因です。DMAバッファ領域をnon-cacheableに配置するか、読み出し前にSCB_InvalidateDCache_by_Addr()でキャッシュを無効化してください。転送状況はSFRビューでNDTRレジスタを見ると切り分けが早いです。 # STM32 # DMA # UART # SPI # ADC # Circular # ダブルバッファ # マイコン開発 ## 次に読む｜STM32 シリーズ記事 - [STM32 シリーズ STM32マイコンのUART・I2C・SPI・CAN通信 実装ガイド HALライブラリで通信ペリフェラルを使いこなす定番ガイド](https://technosphere.co.jp/blog/stm32-uart-i2c-can) - [STM32 シリーズ STM32 + FreeRTOS 入門 タスク・キュー・セマフォを使ったRTOS実装ガイド](https://technosphere.co.jp/blog/stm32-freertos-intro) - [開発実績 組込み制御・マイコン開発 実績紹介 DMA活用案件を含む多数の受託開発事例](https://technosphere.co.jp/embedded-achievements) - [STM32 シリーズ STM32 低消費電力モード完全ガイド バッテリー駆動を年単位で実現する設計ノウハウ](https://technosphere.co.jp/blog/stm32-low-power-battery) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # FreeRTOS入門｜STM32で学ぶタスク・キュー・セマフォの基本【サンプルコード付き】｜テクノスフィア > FreeRTOS入門者向けに、STM32CubeMXでの有効化からタスク・キュー・セマフォ・ミューテックスの使い方までRTOS開発の基本を解説。CMSIS-OS v2ベースのCサンプルコードを多数掲載。組込み開発歴20年超のエンジニアが実務目線で解説します。 URL: https://technosphere.co.jp/blog/stm32-freertos-intro ** 目次 1. はじめに：なぜSTM32にRTOSが必要か 2. FreeRTOSの基本概念 3. STM32CubeMXでFreeRTOSを有効化 4. タスクの作成と管理 5. キューによるタスク間通信 6. セマフォ・ミューテックスによる同期 7. 割り込みからのFreeRTOS API呼び出し 8. よくある落とし穴と対策 9. まとめ ## はじめに：なぜSTM32にRTOSが必要か STM32マイコンでセンサー収集・UART通信・LCD表示・モーター制御などを**1つのwhileループ（スーパーループ）**で書いていると、機能が増えるたびに「センサー読み込みが遅れて制御がガタつく」「UART受信中にLCD更新が止まる」といった問題が必ず起こります。 こうした問題を根本解決するのが**FreeRTOS**です。FreeRTOSはオープンソースの組込みリアルタイムOSで、STM32CubeMXに標準で組み込まれているため、追加コストなしで導入できます。タスクごとに処理を分離し、優先度に応じて自動的に切り替えてくれるため、複雑な制御系も見通しよく書けます。 本記事ではSTM32CubeMXで生成される**CMSIS-OS v2**（FreeRTOSのCMSISラッパー）をベースに、最低限知っておくべき4つのAPIを解説します。本記事の前提として、UART/I2C/SPI/CANの基本実装は [STM32マイコンのUART・I2C・SPI・CAN通信 実装ガイド](https://technosphere.co.jp/blog/stm32-uart-i2c-can) をご覧ください。 ** 弊社での活用実績 弊社では STM32F4・STM32H7 + FreeRTOS の構成で、産業用通信ゲートウェイ・センサーデータロガー・モーター制御装置など [多数の組込み開発実績](https://technosphere.co.jp/embedded-achievements) があります。本記事はその実案件で得たノウハウをもとに作成しています。 ## FreeRTOSの基本概念 FreeRTOSを使いこなす前に、3つの基本概念を押さえます。 ### 1. タスク（Task） 独立した処理単位です。スーパーループの代わりに、機能ごとに「センサー読み込みタスク」「LCD更新タスク」「UART通信タスク」のように分割します。各タスクは **専用のスタック** を持ち、独立に実行されます。 ### 2. スケジューラ（Scheduler） どのタスクをいつ実行するかを決める司令塔です。FreeRTOSはデフォルトで**プリエンプティブ優先度ベース**です。優先度の高いタスクが Ready 状態（実行可能）になった瞬間、現在のタスクを中断して切り替えます。同じ優先度のタスクはタイムスライス（デフォルト1ms）でラウンドロビン実行されます。 ### 3. タスクの状態遷移 各タスクは4つの状態を行き来します。 - **Running（実行中）：**CPUを獲得して実行中。常に1つだけ - **Ready（実行可能）：**実行待ち。スケジューラがCPU割り当てを判断 - **Blocked（待機中）：**イベント待ち（delay、キュー受信、セマフォ取得など）。CPUを使わない - **Suspended（停止）：**明示的に停止された状態 ** 「リアルタイム」とは RTOSの「リアルタイム」は「高速」という意味ではなく、**「決められた時間内に必ず処理が終わる保証がある」**という意味です。優先度設計を間違えなければ、高優先度タスクは必ず期限内に実行されます。これが Linux などの汎用OSとの決定的な違いです。 ## STM32CubeMXでFreeRTOSを有効化 STM32CubeMXでFreeRTOSを有効化する手順は非常にシンプルです。 1. 左側ペインの **「Middleware and Software Packs」→「FREERTOS」** を選択 2. 「Interface」プルダウンで **CMSIS_V2** を選択（新規プロジェクトはV2推奨） 3. 「Tasks and Queues」タブでデフォルトタスク（defaultTask）が自動生成されることを確認 4. 「Config parameters」タブで **TOTAL_HEAP_SIZE** を必要量に設定（デフォルト3072バイト、最低でも8192バイトを推奨） 5. 「Generate Code」で初期化コードを自動生成 ** 重要：SysTick の置き換え FreeRTOS有効時はHALのタイムベースに **SysTick以外のタイマー**（例：TIM6）を使う必要があります。CubeMXの「Pinout & Configuration」→「SYS」→「Timebase Source」で TIM6 等を選択してください。これを忘れるとHAL_Delayが正しく動作しません。 ### 生成される主なファイル ``` MyProject/ ├── Core/ │ ├── Src/ │ │ ├── main.c // main()、各タスク関数の定義 │ │ ├── freertos.c // FreeRTOS初期化、defaultTask │ │ └── stm32xxxx_it.c // 割り込みハンドラ（SysTick等） │ └── Inc/ │ └── FreeRTOSConfig.h // FreeRTOSの全設定 └── Middlewares/Third_Party/FreeRTOS/ └── Source/ // FreeRTOSカーネルソース ``` ### 最小構成のmain.c CubeMXが生成するmain.cの末尾は概ね次のような形になります。 ``` int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_USART2_UART_Init(); /* FreeRTOSの初期化 */ osKernelInitialize(); /* タスク作成（CubeMXで定義したものが自動生成される） */ MX_FREERTOS_Init(); /* スケジューラ起動（ここで戻ってこない） */ osKernelStart(); while (1) { } // ここには到達しない } ``` ## タスクの作成と管理 FreeRTOSの中核です。CMSIS-OS v2 では `osThreadNew()` でタスクを作成します。 ### タスクの作成 ``` /* タスク関数の定義 */ void LedBlinkTask(void *argument) { for (;;) { HAL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin); osDelay(500); // 500ms 待機（この間 Blocked 状態でCPUを解放） } } /* タスク属性 */ const osThreadAttr_t led_task_attr = { .name = "LedBlink", .stack_size = 256 * 4, // 1KB（CMSIS-OS v2 はバイト単位） .priority = osPriorityNormal, // 優先度 }; /* タスク作成（main()やMX_FREERTOS_Init() 内で実行） */ osThreadId_t ledTaskHandle = osThreadNew(LedBlinkTask, NULL, &led_task_attr); ``` ### 優先度設計の基本ルール FreeRTOSの優先度は数値が大きいほど高優先度です。CMSIS-OS v2 では以下の定義済み定数を使います。 | 定数 | 用途 | | `osPriorityIdle` | アイドル時のみ動作する最低優先度（CPU使用率測定など） | | `osPriorityLow` | ログ出力、LCD更新など、遅延が許容される処理 | | `osPriorityNormal` | センサー読み込み、通常の制御処理 | | `osPriorityAboveNormal` | UART/SPI受信処理など、応答性が必要な処理 | | `osPriorityHigh` | モーター制御、リアルタイム性が重要な処理 | | `osPriorityRealtime` | 緊急停止、安全に関わる処理 | ** 設計指針 優先度は「**応答性が必要なものほど高く**」が原則。長時間CPUを占有する処理は低優先度にして、緊急処理に割り込まれるよう設計します。すべてHighにすると逆にプリエンプションが効かず、設計の意味がなくなります。 ### スタックサイズの目安 各タスクは独立したスタックを持つため、ヒープから割り当てられます。スタック不足はHardFaultやSegmentation Fault的なバグの温床になります。 - **シンプルな処理（LED、簡単なセンサー）：**128〜256ワード（512B〜1KB） - **中程度の処理（UART通信、状態管理）：**512ワード（2KB） - **printfやfloat演算を含む処理：**1024ワード以上（4KB〜） - **FATFS / LwIP などのミドルウェア：**1024〜2048ワード（4〜8KB） 実機で `uxTaskGetStackHighWaterMark()` を呼ぶと、各タスクの未使用スタック量が確認できます。余裕が256バイト未満なら危険信号です。 ### タスクの削除と停止 ``` /* タスクの削除（自己削除も可能） */ osThreadTerminate(ledTaskHandle); /* 一時停止 / 再開 */ osThreadSuspend(ledTaskHandle); osThreadResume(ledTaskHandle); /* 待機（自タスクをBlockedに） */ osDelay(1000); // 1000ms 待機 osDelayUntil(osKernelGetTickCount() + 100); // 周期実行（時間ドリフトなし） ``` ## キューによるタスク間通信 タスクは独立して動くため、データを安全に受け渡すには**キュー（メッセージキュー）**を使います。グローバル変数を直接読み書きすると、競合状態（Race Condition）が発生します。 ### キューの作成 ``` /* キュー：センサー値（float型）を最大10個まで保持 */ osMessageQueueId_t sensorQueueHandle; const osMessageQueueAttr_t sensor_queue_attr = { .name = "SensorQueue" }; void MX_FREERTOS_Init(void) { sensorQueueHandle = osMessageQueueNew( 10, // キューサイズ（最大10要素） sizeof(float), // 1要素のサイズ &sensor_queue_attr ); } ``` ### 送信側タスク（センサー読み込み） ``` void SensorTask(void *argument) { float temperature; for (;;) { /* I2Cセンサーから温度を読み込み */ temperature = read_temperature_i2c(); /* キューに送信（キュー満杯なら最大100msまで待機） */ osMessageQueuePut(sensorQueueHandle, &temperature, 0, 100); osDelay(100); // 100ms周期 } } ``` ### 受信側タスク（ログ・通信） ``` void LoggerTask(void *argument) { float received_value; char tx_buf[64]; for (;;) { /* キューから受信（データが来るまで永久待機） */ if (osMessageQueueGet(sensorQueueHandle, &received_value, NULL, osWaitForever) == osOK) { snprintf(tx_buf, sizeof(tx_buf), "Temp: %.2f C\r\n", received_value); HAL_UART_Transmit(&huart2, (uint8_t*)tx_buf, strlen(tx_buf), 100); } } } ``` ** キュー設計のコツ - **1対1だけでなく多対多でも使える：**複数の送信タスクから1つの受信タスクへ集約する設計が典型例 - **キューサイズはバッファとして設計：**送信側のバースト性を吸収できる程度に余裕を持たせる（10〜32個が目安） - **大きな構造体はポインタ渡し：**キューに大きな構造体を直接入れると重い。ポインタを渡してヒープを共有する設計が高速 ## セマフォ・ミューテックスによる同期 共有リソース（UART、I2C、SPIなどのペリフェラル）に複数タスクが同時アクセスすると競合します。これを防ぐのが**セマフォ**と**ミューテックス**です。 ### ミューテックスによる排他制御 UARTを複数タスクから使う典型例です。ミューテックスを取得しないと他のタスクは待たされます。 ``` osMutexId_t uartMutexHandle; void MX_FREERTOS_Init(void) { const osMutexAttr_t mutex_attr = { .name = "UartMutex" }; uartMutexHandle = osMutexNew(&mutex_attr); } /* タスクA: ログ出力 */ void LogTask(void *argument) { char buf[64]; for (;;) { osMutexAcquire(uartMutexHandle, osWaitForever); // 取得 snprintf(buf, sizeof(buf), "[LOG] tick=%lu\r\n", osKernelGetTickCount()); HAL_UART_Transmit(&huart2, (uint8_t*)buf, strlen(buf), 100); osMutexRelease(uartMutexHandle); // 解放 osDelay(500); } } /* タスクB: エラー出力 */ void ErrorTask(void *argument) { for (;;) { if (error_occurred) { osMutexAcquire(uartMutexHandle, osWaitForever); HAL_UART_Transmit(&huart2, (uint8_t*)"[ERR] FAULT\r\n", 13, 100); osMutexRelease(uartMutexHandle); error_occurred = 0; } osDelay(100); } } ``` ### バイナリセマフォによる割り込み通知 「割り込みが発生したらタスクを起こす」という非同期通知の定番パターンです。タスク側は `osSemaphoreAcquire` で待機し、ISRから `osSemaphoreRelease` で起こします。 ``` osSemaphoreId_t uartRxSemHandle; void MX_FREERTOS_Init(void) { uartRxSemHandle = osSemaphoreNew(1, 0, NULL); // 最大1、初期0 } /* UART受信タスク：セマフォが解放されるまで待つ */ void UartRxTask(void *argument) { uint8_t rx_byte; HAL_UART_Receive_IT(&huart2, &rx_byte, 1); // 1バイト受信割り込み開始 for (;;) { if (osSemaphoreAcquire(uartRxSemHandle, osWaitForever) == osOK) { /* 受信処理 */ process_uart_byte(rx_byte); HAL_UART_Receive_IT(&huart2, &rx_byte, 1); // 次の受信 } } } /* 受信完了割り込み（ISR） */ void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart->Instance == USART2) { osSemaphoreRelease(uartRxSemHandle); // タスクを起こす } } ``` ** ミューテックス vs セマフォ - **ミューテックス：**排他制御専用。「優先度継承」機能があり、優先度逆転を防ぐ - **バイナリセマフォ：**イベント通知用。ISR→タスクの「合図」に使う - **カウンティングセマフォ：**複数の同種リソース管理に使う（例：プール内のバッファ数） 共有リソースの排他制御には必ずミューテックスを使ってください。バイナリセマフォで代用すると、優先度逆転が起こって高優先度タスクが止まる事故が起こります。 ## 割り込みからのFreeRTOS API呼び出し 割り込みハンドラ（ISR）の中でFreeRTOS APIを呼ぶには、専用の**「FromISR」版API**を使う必要があります。通常版APIを使うと予期せぬクラッシュが起こります。 ### ISR内で使えるCMSIS-OS v2 API CMSIS-OS v2 ではAPI名が同じで内部的に ISR を判定してくれるものが多い反面、明示的にISR専用関数を使うべき場面もあります。ネイティブFreeRTOS APIの場合は明確に分離されています。 ``` /* CMSIS-OS v2（osXxx）はISR/タスクの両方から呼べる ただし osWaitForever などのブロッキングはISRから使ってはいけない */ void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) { if (GPIO_Pin == BUTTON_Pin) { /* タイムアウト 0 を指定 = ブロックしない */ osSemaphoreRelease(buttonSemHandle); /* キュー送信もタイムアウト 0 で使う */ uint32_t event = EVENT_BUTTON_PRESSED; osMessageQueuePut(eventQueueHandle, &event, 0, 0); } } ``` ### 割り込み優先度の重要な設定 STM32の **NVIC 優先度**と FreeRTOSの優先度設定は必ず連動させる必要があります。FreeRTOSConfig.h の以下の設定を確認してください。 ``` /* FreeRTOSConfig.h */ #define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 5 // この値以上の優先度で FromISR API が使える #define configLIBRARY_LOWEST_INTERRUPT_PRIORITY 15 /* CubeMXで割り込みを設定するときの NVIC Priority Group は 4 ビット プリエンプション に設定すること */ ``` ** よくあるトラブル UART受信割り込みなどのNVIC優先度を **0 や 1（最高）**に設定すると、その割り込み内からFreeRTOS APIを呼んだ瞬間にHardFaultします。STM32の割り込みは `configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY`（デフォルト5）**以上の値** に設定する必要があります（数値が大きい＝優先度が低い）。 ## よくある落とし穴と対策 | 症状 | 原因 | 対策 | | 起動直後にHardFault | SysTickがHALタイムベースのままでFreeRTOSと衝突 | CubeMXで Timebase Source を TIM6 等の汎用タイマーに変更 | | タスクが時々止まる / 暴走 | スタックオーバーフロー | `configCHECK_FOR_STACK_OVERFLOW` を2に設定。`uxTaskGetStackHighWaterMark()` で実測。スタックを増量 | | 高優先度タスクが応答しない | 優先度逆転（低優先度タスクが共有リソースを保持中） | 排他制御にはセマフォではなく **ミューテックス** を使う（優先度継承機能で逆転を回避） | | osThreadNewでNULLが返る | FreeRTOSヒープ（TOTAL_HEAP_SIZE）不足 | `FreeRTOSConfig.h` の `configTOTAL_HEAP_SIZE` を増量（8KB→16KB等） | | ISR内でAPI呼出時にHardFault | NVIC優先度が configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY より高い | 該当割り込みのNVIC優先度を5以上に設定（CubeMXのNVICタブで確認） | | キュー受信タスクが永久に待つ | 送信側がキューに入れていない / 別のキューハンドルを使っている | ハンドル変数のスコープ・初期化順序を確認。`osMessageQueueGetCount()` でデバッグ | | printfが出力されない / 出力が混ざる | 複数タスクからUARTに同時アクセス | UART送信を必ずミューテックスで保護する。ログ専用タスクを1つ作ってキュー経由に統一するのも良い | ** デバッグの定石 - **STM32CubeIDE の FreeRTOS-aware デバッグ：**「Window → Show View → FreeRTOS Task List」で全タスクの状態・スタック使用量がリアルタイム表示できる - **configUSE_TRACE_FACILITY を 1 に：**タスクごとの実行時間・CPU使用率が取得できるようになる - **Tracealyzer (Percepio)：**商用ツールだがタスクスイッチを可視化できる。難しい競合バグはこれで一気に見える化 ## まとめ ### この記事のまとめ - FreeRTOSはSTM32CubeMXに標準搭載されており、追加コストなしで導入できる - 「タスク」「キュー」「セマフォ／ミューテックス」の3つを押さえれば実用的なRTOSアプリが書ける - 優先度設計は「応答性が必要なほど高く」が原則。全部Highにすると意味が無い - 共有リソースの排他制御は必ずミューテックスを使う（優先度逆転を回避） - ISRからAPIを呼ぶときはNVIC優先度を5以上にすること（HardFault対策） STM32 + FreeRTOSを使った組込みシステム開発でお困りのことがあれば、弊社にお気軽にご相談ください。設計から実装・量産対応まで、マイコン開発歴20年超のエンジニアが一貫してサポートします。 STM32 + FreeRTOS の試作・量産設計、既存スーパーループ機器の RTOS 化、タイミング問題の調査まで [組込み制御・マイコン開発](https://technosphere.co.jp/embedded) として対応しています。 ／この内容の受託開発・PoC相談はこちら＼ ### STM32 + FreeRTOS の受託開発・量産対応 RTOSタスク設計・割込み連携・低消費電力化・量産デバッグまで、STM32開発歴20年超のエンジニアが一貫対応します。試作のPoCから量産フェーズまでお任せください。 [組込み開発サービスを見る](https://technosphere.co.jp/embedded) [RTOS設計・量産相談](https://technosphere.co.jp/contact) ## よくある質問（FAQ） ** STM32でFreeRTOSはどうやって導入しますか？ STM32CubeMXのMiddlewareでFreeRTOS（CMSIS-OS v2）を有効化すると、初期化コードとタスク生成のひな型が自動生成されます。追加ライブラリの購入は不要で、STM32CubeIDEに標準で含まれています。 ** タスク・キュー・セマフォはどう使い分けますか？ タスクは独立した処理単位（センサー読み込み・LCD更新など）、キューはタスク間で安全にデータを受け渡す仕組み、セマフォ／ミューテックスは共有リソースの排他制御や割り込みとの同期に使います。複数処理の並行実行はタスク、データ授受はキュー、競合防止はミューテックスが基本です。 ** スーパーループからFreeRTOSに移行するメリットは？ 機能が増えても処理の遅延や取りこぼしが起きにくくなります。優先度設計により応答性が必要な処理を確実に実行でき、コードもタスク単位で見通しよく保守できます。実際にセンサー監視・通信・表示・制御を並行させる構築例は [実践編：STM32+FreeRTOSでリアルタイムセンサー監視システムを構築する](https://technosphere.co.jp/de-blog/2026-04-24-stm32-freertos-sensor-monitoring) で紹介しています。 ** 割り込みハンドラからFreeRTOSのAPIを呼んでも大丈夫ですか？ ISRからは末尾が `FromISR` のAPI（`xQueueSendFromISR()` 等）のみを使用し、NVIC優先度を `configMAX_SYSCALL_INTERRUPT_PRIORITY` 以上（数値が大きい＝低優先）に設定する必要があります。これを守らないとHardFaultの原因になります。 # STM32 # FreeRTOS # RTOS # CMSIS-OS # タスク # セマフォ # マイコン開発 # 組込み制御 ## 次に読む｜STM32 シリーズ記事 - [STM32 シリーズ STM32マイコンのUART・I2C・SPI・CAN通信 実装ガイド HALライブラリで通信ペリフェラルを使いこなす定番ガイド](https://technosphere.co.jp/blog/stm32-uart-i2c-can) - [STM32 シリーズ STM32 DMA 完全ガイド｜UART・SPI・ADCとの連携 CPU負荷を最小化するDMA活用の決定版](https://technosphere.co.jp/blog/stm32-dma-complete-guide) - [開発実績 組込み制御・マイコン開発 実績紹介 FreeRTOS採用案件含む多数の受託開発事例](https://technosphere.co.jp/embedded-achievements) - [STM32 シリーズ STM32 低消費電力モード完全ガイド バッテリー駆動を年単位で実現する設計ノウハウ](https://technosphere.co.jp/blog/stm32-low-power-battery) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # STM32G4 内蔵アナログ計測誤差の罠｜OPAMP・COMP・ADC を CubeMX で組む時の R_AIN とサンプリング時間の関係｜株式会社テクノスフィア > STM32G4 内蔵 OPAMP/COMP/高速 ADC を使いこなす鍵「ソース抵抗とサンプリング時間」を AN2834・DS12288 を一次資料に解説。OPAMP Voltage Follower の決め技と Errata の落とし穴を網羅。 URL: https://technosphere.co.jp/blog/stm32-g4-analog-precision ** 目次 1. はじめに：STM32G4 のアナログ機能が "見落とされやすい" 2. STM32G4 内蔵アナログ周辺の俯瞰 3. ADC サンプリング時間の根拠式（AN2834） 4. DS12288 Table 70：G4 では「式」ではなく「ルックアップ」 5. R_AIN を下げる4つの手段 6. 決め技：内蔵 OPAMP を ADC バッファに使う 7. 内蔵 COMP の DAC 直結とブランキング 8. ハードウェアオーバーサンプリングで ENOB を稼ぐ 9. PCB レイアウトと電源分離（AN5346） 10. 現場で踏むハマりポイント（Errata 抜粋） 11. 公式リソース・参考文献 12. まとめ ** 本記事の数値について 本記事に記載する数値はすべて **ST 公式データシート DS12288 (STM32G474, Rev 1, 2019年5月)** および **AN2834 (Rev 3, 2017年2月)** を一次資料として参照しています。最新版（DS12288 Rev 6, 2021年11月）で更新がある可能性があるため、実設計時は最新版でご確認ください。 ## はじめに：STM32G4 のアナログ機能が "見落とされやすい" STM32G4 シリーズは、Cortex-M4F コア（170 MHz）に加え、**内蔵 OPAMP × 6個 / COMP × 7個 / 高速 ADC × 5個 / DAC × 7チャネル**を搭載する、STM32 史上もっともアナログ機能が充実したマイコンです。本来なら外付け OPAMP / コンパレータ IC で構成する電流センス・閾値検出・小信号バッファをワンチップで完結できる、モータ制御 / 電源 / センサ案件の本命です。 ところが、いざ CubeMX で組んで動かしてみると **「ADC の値がノイジー」「想定より下のビットが立つ」「期待した電圧と全然違う」** といった「計測誤差の罠」にハマるケースが頻発します。原因はほぼ一つで、**ソース抵抗 R_AIN とサンプリング時間 T_S の関係を理解せずに使っている**ためです。 本記事では **AN2834「How to get the best ADC accuracy」** と **STM32G474 データシート DS12288 の Table 70** を一次資料に、この関係を体系的に解説します。さらに「内蔵 OPAMP を Voltage Follower にして R_AIN を実質ゼロにする」 G4 ならではの決め技、そして Errata に潜む落とし穴まで踏み込みます。基礎となる UART/I2C/SPI 通信は [STM32 のUART・I2C・SPI・CAN通信 実装ガイド](https://technosphere.co.jp/blog/stm32-uart-i2c-can)、DMA との連携は [STM32 DMA 完全ガイド](https://technosphere.co.jp/blog/stm32-dma-complete-guide) を併せてご覧ください。 ** 弊社での活用実績 弊社では STM32G4 を用いたモータ制御装置・電流センシング・産業計測機器など [多数のアナログ寄り組込み開発実績](https://technosphere.co.jp/embedded-achievements) があります。本記事は、その実案件で蓄積した「ADC 値が想定と違う」を解決した経験則を、公式 AN の数式と照らし合わせて整理したものです。 ## STM32G4 内蔵アナログ周辺の俯瞰 主要 2 ライン（STM32G474xx Performance / G431xx Access）の搭載数を比較します。(出典: DS12288 §3 / ST product page) | 機能 | STM32G474xx（Performance） | STM32G431xx（Access） | | Cortex-M4F | 最大 170 MHz | 最大 170 MHz | | 内蔵 OPAMP | **6 個**（OPAMP1〜OPAMP6） | 3 個 | | 内蔵 COMP | **7 個**（COMP1〜COMP7） | 4 個 | | 12-bit ADC | **5 個**（最大 4 Msps @ 12-bit） | 2 個（最大 4 Msps @ 12-bit） | | DAC | 7 チャネル（3 個 外部出力 + 4 個 内部） | 4 チャネル（2 個 外部 + 2 個 内部） | | HRTIM（高分解能タイマ） | ○（モータ・電源制御用） | - | ** 「5 Msps」表記は条件付き STM32G4 ADC のマーケティング上の「5 Msps」表記は **6-bit などの低分解能モード**を含めた最高値です。**12-bit 分解能での最大変換速度は 4 Msps**（DS12288 §3.18.1）。記事や仕様検討で「12-bit / 5 Msps」と誤解しないよう注意してください（低分解能時の最高値は最新データシートの該当 Table を参照）。 ## ADC サンプリング時間の根拠式（AN2834） STM32 の ADC は SAR（Successive Approximation Register）方式で、入力は次の等価回路で表されます。(出典: AN2834 §2.2.6) ``` R_AIN R_ADC ────/\/\/───────────/\/\/───┬──── ADC SAR Core (外付け (内部 │ 信号源抵抗) スイッチ) ┤ C_ADC (内蔵 S&H キャパシタ) ┤ GND ``` サンプリング時、信号源は R_AIN + R_ADC を通って C_ADC を充電します。**サンプリング時間 T_S の間に C_ADC が真の電圧まで十分充電される必要があり**、不足すると次の変換に影響を残して誤差になります。 AN2834 §3.2.6 では、N-bit 分解能 / 1/2 LSB 誤差を許容する場合の最大ソース抵抗を以下のように導きます。 ``` 充電時定数: τ = (R_AIN + R_ADC) × C_ADC 1/2 LSB 誤差で済むには: T_S ≥ τ × ln(2^(N+1)) よって最大 R_AIN は: T_S R_AIN_max = ─────────────────── − R_ADC C_ADC × ln(2^(N+1)) ``` N = 12 のとき ln(2^13) ≒ 9.01。これを覚えておくと、ファミリ別の R_AIN_max が即計算できます。 **例（AN2834 §3.2.6 の STM32F1 数値）：**f_ADC = 14 MHz、C_ADC = 8 pF、R_ADC = 1 kΩ、T_S = 7.5 cycles の場合、R_AIN_max ≒ 6.4 kΩ。(出典: AN2834 §3.2.6 数値例) ## DS12288 Table 70：G4 では「式」ではなく「ルックアップ」 ここが多くの日本語記事が見落とすポイントです。**STM32G4 では R_ADC が温度・VDDA・analog switch booster の有無で変動する**ため、データシートは AN2834 の式の代わりに「サンプリング時間ごとの R_AIN_max ルックアップテーブル」を掲載しています。(出典: AN2834 §3.2.6 Note / DS12288 §5.3.21 Note) STM32G4 で公開されている定数は **C_ADC typ 5 pF** のみ（DS12288 Table 69）。R_ADC は不開示なので、設計者は **Table 70 を直接見て使うサンプリング時間を決める**のが公式の流儀です。 ### DS12288 Table 70（12-bit 抜粋、f_ADC = 60 MHz） | サンプリング cycles | サンプリング時間 | R_AIN_max Fast ch. | R_AIN_max Slow ch. | | 2.5 | 41.67 ns | **100 Ω** | N/A | | 6.5 | 108.33 ns | 330 Ω | 100 Ω | | 12.5 | 208.33 ns | 680 Ω | 470 Ω | | 24.5 | 408.33 ns | 1.5 kΩ | 1.2 kΩ | | 47.5 | 791.67 ns | 2.2 kΩ | 1.8 kΩ | | 92.5 | 1.54 µs | 4.7 kΩ | 3.9 kΩ | | 247.5 | 4.13 µs | 12 kΩ | 10 kΩ | | **640.5** | **10.675 µs** | **39 kΩ** | **33 kΩ** | ※ DS12288 Rev 1, §5.3.21 Table 70（12-bit 抜粋）。10-bit / 8-bit / 6-bit は値が緩くなる方向で同表が完全提供されています。実設計では必ず最新データシートの該当 Table を参照してください。 ** Fast channel と Slow channel の違い STM32G4 ADC では、ADCx_IN1 〜 ADCx_IN5 の **「Fast channels」** のみが最短 2.5 cycles サンプリングをサポートします。それ以外はすべて **「Slow channels」** で、最短でも 6.5 cycles 必要です。高速電流センシング（モータ制御）など速度を稼ぎたい用途では、必ず Fast channel に割り当ててください。(出典: DS12288 Table 70 注 (3)(4)) ### HAL のサンプリング時間定数 ``` ADC_SAMPLETIME_2CYCLES_5 // 2.5 ADC_SAMPLETIME_3CYCLES_5 // 3.5（G4 限定 SMPPLUS 機能） ADC_SAMPLETIME_6CYCLES_5 // 6.5 ADC_SAMPLETIME_12CYCLES_5 // 12.5 ADC_SAMPLETIME_24CYCLES_5 // 24.5 ADC_SAMPLETIME_47CYCLES_5 // 47.5 ADC_SAMPLETIME_92CYCLES_5 // 92.5 ADC_SAMPLETIME_247CYCLES_5 // 247.5 ADC_SAMPLETIME_640CYCLES_5 // 640.5 ``` **3.5 cycles モード**は G4 限定の SMPPLUS 機能で、2.5 cycles 設定の「+1 サイクル」版です。ADC 全体共通の SMPPLUS ビットで切り替えるため、チャネルごとに混在はできません。(出典: stm32g4xx_hal_adc.h) ## R_AIN を下げる4つの手段 外部信号源の R_AIN は「センサーの出力抵抗 + 直列保護抵抗 + 入力 RC フィルタの抵抗成分」の合計値です。よくあるハマりポイントとして、**「入力に 10 kΩ + 1 nF の RC フィルタを入れた」だけで、R_AIN が 10 kΩ に跳ね上がる**ことを認識せず、サンプリング時間を 6.5 cycles のままにしているケースが頻発します。 R_AIN を許容範囲に収める手段は 4 つです。 ### ① ADC クロックを下げる（変換は遅くなる） 同じサンプリング cycles でも f_ADC が低ければ時間は長くなる → R_AIN_max が緩む。消費電流も減るのでセンサノード向き。 ### ② 分解能を下げる（精度は落ちる） 12-bit → 10-bit / 8-bit / 6-bit と落とすほど R_AIN_max が緩む。例：12-bit / 640.5 cycles で 39 kΩ なのに対し、6-bit では同条件で 50 kΩ。 ### ③ 入力直前に小さな C を追加（電荷リザーバ） ADC 入力直前に **100 pF 〜 1 nF** の C を追加すると、サンプリング瞬間の電荷を C から供給できる。ただし「次のサンプリングまでに信号源から十分再充電できる」場合のみ有効。 ### ④ アクティブバッファ（OPAMP）で R_AIN を実質ゼロに（決め技） 外付け OPAMP、あるいは **STM32G4 の内蔵 OPAMP を Voltage Follower モード**にして、ADC 入力をバッファする。これにより ADC から見た R_AIN は OPAMP の出力インピーダンス（**200 Ω 未満**）まで下がる。次セクションで詳述します。 ## 決め技：内蔵 OPAMP を ADC バッファに使う STM32G4 内蔵 OPAMP の最大の強みは、**出力を物理ピンに出さず内蔵 ADC に直結（Internal Output）できる**ことです。これにより外付け OPAMP IC + 配線がゼロでバッファアンプを構成できます。 ### OPAMP の電気的特性（DS12288 Table 80 抜粋） | Symbol | パラメータ | Typ | 備考 | | CMIR | 同相入力範囲 | 0 ～ VDDA | rail-to-rail | | VIOFFSET | 入力オフセット（キャリブ後 25℃） | ±1.5 mV max | `HAL_OPAMP_SelfCalibrate()` で到達可能 | | GBW | 利得帯域積 | 13 MHz | min 7 MHz | | SR | スルーレート（Normal） | 6.5 V/µs | min 2.5 | | SR | スルーレート（High-Speed） | 45 V/µs | min 18 | | I_DDA（Normal、follower） | 消費電流 | 1.3 mA | max 2.2 mA | | I_DDA（High-Speed） | 消費電流 | 1.4 mA | max 2.6 mA | | **TS_OPAMP_VOUT** | ADC 直結時の最短サンプリング | 200 ns (VDDA≥2V) 300 ns (VDDA<2V) | **これが大きい** | 注目すべきは **TS_OPAMP_VOUT = 200 ns**。OPAMP Internal Output 経由なら、ADC のサンプリング時間は最短 12.5 cycles (208 ns @60MHz) まで詰められます。外部 R_AIN がなくなったうえで OPAMP 出力インピーダンスは 200 Ω 未満。これにより **「高インピーダンスセンサーを 12-bit / 高速サンプリング」** が無理なく実現できます。 ### HAL コード例：OPAMP1 を Voltage Follower、ADC1 に直結 ``` OPAMP_HandleTypeDef hopamp1; hopamp1.Instance = OPAMP1; hopamp1.Init.PowerMode = OPAMP_POWERMODE_HIGHSPEED; // 高速モード hopamp1.Init.Mode = OPAMP_FOLLOWER_MODE; // ボルテージフォロワ hopamp1.Init.NonInvertingInput = OPAMP_NONINVERTINGINPUT_IO0; // PA1 入力 hopamp1.Init.InternalOutput = ENABLE; // ADC に直結（PA2 ピン出力なし） hopamp1.Init.UserTrimming = OPAMP_TRIMMING_FACTORY; HAL_OPAMP_Init(&hopamp1); /* 起動時に1回だけ校正 → オフセットを ±1.5 mV まで詰める */ HAL_OPAMP_SelfCalibrate(&hopamp1); HAL_OPAMP_Start(&hopamp1); /* ADC1 側で OPAMP1 出力チャネルを選択 */ ADC_ChannelConfTypeDef sConfig = {0}; sConfig.Channel = ADC_CHANNEL_VOPAMP1; // OPAMP1 内部直結チャネル sConfig.Rank = ADC_REGULAR_RANK_1; sConfig.SamplingTime = ADC_SAMPLETIME_12CYCLES_5; // TS_OPAMP_VOUT(200ns) を満たす sConfig.SingleDiff = ADC_SINGLE_ENDED; HAL_ADC_ConfigChannel(&hadc1, &sConfig); ``` ### PGA モードでセンサ信号を増幅 OPAMP は **PGA（Programmable Gain Amplifier）**モードにも切り替えられ、Non-inverting で **×2, ×4, ×8, ×16, ×32, ×64**、Inverting で **×-1, ×-3, ×-7, ×-15, ×-31, ×-63** の固定ゲインが選べます。(出典: DS12288 Table 80) **注意**：PGA の**ゲイン精度**はゲイン×2〜16で約 1%、×32/64で約 2%です（ゲインは抵抗の「比」で決まるため、内蔵抵抗の絶対値ばらつきが大きくてもゲイン誤差は小さく保たれます）。一方で**オフセット電圧やゲイン誤差をさらに追い込みたい高精度測定**では、Standalone モードで外部精密抵抗を組む構成も検討してください。 ### Normal モード vs High-Speed モードの選び方 - **Normal モード**：SR 6.5 V/µs typ、消費 1.3 mA typ。DC〜数十 kHz の低速信号に十分 - **High-Speed モード**：SR 45 V/µs typ、消費 1.4 mA typ。**消費はわずか +0.1 mA なのに SR は約 7 倍**。動信号や PGA で帯域が必要なら基本これ 消費電流のペナルティが小さいため、バッテリ駆動でない案件はデフォルトで High-Speed にしておくのが現場の鉄則です。 ## 内蔵 COMP の DAC 直結とブランキング STM32G4 の COMP は他ファミリには無い 2 つの強力な機能を持ちます。 ### ① 反転入力に DAC を直結（閾値をソフトウェア可変） 外部に「閾値設定用のボリュームや分圧抵抗」を置く必要がありません。**内蔵 DAC を COMP の反転入力に直結**でき、ソフトウェアから自由に閾値を変えられます。 ``` COMP_HandleTypeDef hcomp1; hcomp1.Instance = COMP1; hcomp1.Init.InputPlus = COMP_INPUT_PLUS_IO1; // PA1 入力 hcomp1.Init.InputMinus = COMP_INPUT_MINUS_DAC3_CH1; // DAC3_CH1 を閾値に hcomp1.Init.Hysteresis = COMP_HYSTERESIS_40MV; // 中ヒステリシス hcomp1.Init.OutputPol = COMP_OUTPUTPOL_NONINVERTED; hcomp1.Init.TriggerMode = COMP_TRIGGERMODE_IT_RISING_FALLING; HAL_COMP_Init(&hcomp1); HAL_COMP_Start(&hcomp1); /* 閾値を 1.5V に設定（VREF=3.3V、12-bit DAC の場合） */ HAL_DAC_SetValue(&hdac3, DAC_CHANNEL_1, DAC_ALIGN_12B_R, 1862); ``` ### ② Blanking 機能：PWM のスパイクを無視 モータ制御で MOSFET のスイッチング瞬間に流れるリンギング電流が、COMP の過電流検出を誤発火させる問題は古典的なトラブルです。STM32G4 の **Blanking 機能**は、指定した TIM 出力（PWM の通電期間）の **立ち上がり後の一定期間 COMP 出力をマスク**することで、スパイクを無視します。 ``` hcomp1.Init.BlankingSrce = COMP_BLANKINGSRC_TIM1_OC5_COMP1; /* TIM1 OC5 で生成した「通電直後の N µs」だけ COMP 出力を強制 Low に */ ``` これを知らずに RC フィルタで対処しようとして応答時間が遅くなる失敗パターンが多い領域です。 ### ヒステリシス設定（HYST レジスタ値 vs mV） | HAL 定数 | Vhys Typ | Vhys Max | | COMP_HYSTERESIS_NONE | 0 | - | | COMP_HYSTERESIS_10MV (LOW) | 9 mV | 16 mV | | COMP_HYSTERESIS_40MV (MEDIUM) | 36 mV | 63 mV | | COMP_HYSTERESIS_70MV (HIGH) | 63 mV | 110 mV | (出典: DS12288 Table 79 / stm32g4xx_hal_comp.h) ## ハードウェアオーバーサンプリングで ENOB を稼ぐ STM32G4 の ADC は **最大 256x のハードウェアオーバーサンプリング**を搭載しています。CPU を介さずに ADC が自動で N 回サンプリング → 累算 → 指定ビットだけ右シフトしてくれる機能で、ノイズが白色（ガウシアン）であれば実効分解能 ENOB を **+4 bit（256x の場合）**まで向上できます。(出典: stm32g4xx_hal_adc.h) ``` /* 16x オーバーサンプリング → ENOB +2 bit、累算 16-bit → 4-bit 右シフトで 12-bit 結果 */ hadc1.Init.OversamplingMode = ENABLE; hadc1.Init.Oversampling.Ratio = ADC_OVERSAMPLING_RATIO_16; hadc1.Init.Oversampling.RightBitShift = ADC_RIGHTBITSHIFT_4; hadc1.Init.Oversampling.TriggeredMode = ADC_TRIGGEREDMODE_SINGLE_TRIGGER; hadc1.Init.Oversampling.OversamplingStopReset = ADC_REGOVERSAMPLING_CONTINUED_MODE; ``` 変換時間は OSR 倍に延びるため、サンプリングレート要件と精度要件のトレードオフを見極めて選定します。実測例として、Cerevo TechBlog では STM32L432KC で 16x OSR + 入力直列抵抗の組合せで **ENOB 8.91 → 13.18 bit** まで改善した報告があります（参考リンクは末尾）。 ## PCB レイアウトと電源分離（AN5346） ADC・OPAMP・COMP の性能はソフトウェアだけでは決まりません。**AN5346「STM32G4 ADC use tips and recommendations」**に PCB 設計の鉄則が整理されています。 - **パッケージ選定**：寄生インダクタンスが小さい順に **UFBGA > UFQFPN > WLCSP > LQFP**。アナログ性能を最大化したいなら UFBGA / UFQFPN を選ぶ - **VDD と VDDA の分離**：フェライトビーズ + 0.1 µF + 1 µF + 4.7 µF の階層型デカップリング - **AGND / DGND の単一接続点**：複数点で繋ぐとグランドループが発生 - **ADC 入力前段の RC フィルタ抵抗は R_AIN に加算**される。「10 kΩ + 1 nF」を入れたら R_AIN_max を 10 kΩ 以上に確保できるサンプリング時間を選ぶこと - **高速電流センス（モータ制御）は Fast channel (ADCx_IN1〜IN5) のみ**使う ### VREF / VREFINT の精度 内蔵 VREFINT は典型 **1.212 V**（min 1.182、max 1.232、温度係数 30 ppm/℃ typ）。(出典: DS12288 Table 20) 温度ドリフトを考慮し、絶対精度が必要な用途では外部リファレンス IC（例：REF3030）を VREF+ ピンに接続するか、内蔵 **VREFBUF**（2.048 / 2.5 / 2.9 V 選択可）を活用してください。 VREFINT は工場校正値が `0x1FFF 75AA` 〜 `0x1FFF 75AB` に格納されており、これを読み出して補正計算に使えば製品ばらつきを吸収できます。 ## 現場で踏むハマりポイント（Errata 抜粋） STM32G47x / G48x の **device errata** から、計測誤差に直結する重要項目を抜粋します。Errata は ST 公式が公開している既知の不具合リストで、量産設計では必読ですが、開発初期に目を通す人は少なく現場で踏みやすい罠です。 ### §2.7.7 Wrong ADC result if conversion done late after calibration ADC キャリブレーション直後、しばらく変換を行わないと最初の変換結果が正しくない。**対策：キャリブレーション直後に必ずダミー変換を 1 回入れる**。 ### §2.7.9 An ADC instance may impact the accuracy of another ADC instance at specific conditions 複数の ADC を同時動作させると、特定条件下で互いの精度に影響する。**対策：高精度測定が必要な ADC は他 ADC と同時動作させない、もしくは Dual-mode を活用してタイミング相関を取る**。 ### §2.10.1 OPAMP disturbed by fast-edge toggle on GPIO pin corresponding to VINM0 OPAMP の反転入力（VINM0）に対応する GPIO ピンが高速にトグルすると OPAMP 出力に擾乱が出る。**対策：VINM0 ピンが他用途で高速 GPIO として使われていないか確認し、必要ならピンレイアウトを変更**。 ** Errata 全項目は必ず確認を Errata は品種ごとに公開されており、量産設計に入る前に必ず通読してください。STM32G4 系の Errata はおおむね 50〜100 項目あり、ADC / OPAMP / COMP 関連だけで 10 件以上に及びます。「データシート通りに作ったのに動かない」のほとんどは Errata に書いてあります。 ## 公式リソース・参考文献 ### 最重要 Application Note - **AN2834** – How to get the best ADC accuracy in STM32 microcontrollers（ADC 精度の決定版） [st.com → AN2834 PDF](https://www.st.com/resource/en/application_note/an2834-how-to-get-the-best-adc-accuracy-in-stm32-microcontrollers-stmicroelectronics.pdf) - **AN5306** – Operational Amplifier (OPAMP) usage in STM32G4 Series [st.com → AN5306 PDF](https://www.st.com/resource/en/application_note/an5306-operational-amplifier-opamp-usage-in-stm32g4-series-stmicroelectronics.pdf) - **AN4232** – Getting started with analog comparators for STM32F3 and STM32G4 Series [st.com → AN4232 PDF](https://www.st.com/resource/en/application_note/an4232-getting-started-with-analog-comparators-for-stm32f3-series-and-stm32g4-series-devices-stmicroelectronics.pdf) - **AN5346** – STM32G4 ADC use tips and recommendations [st.com → AN5346 PDF](https://www.st.com/resource/en/application_note/an5346-stm32g4-adc-use-tips-and-recommendations-stmicroelectronics.pdf) - **AN5310** – Guideline for using analog features of STM32G4 Series vs STM32F3 [st.com → AN5310 PDF](https://www.st.com/resource/en/application_note/an5310-guideline-for-using-analog-features-of-stm32g4-series-versus-stm32f3-series-devices-stmicroelectronics.pdf) - **AN5093** – Getting started with STM32G4 Series hardware development boards [st.com → AN5093 PDF](https://www.st.com/resource/en/application_note/an5093-getting-started-with-stm32g4-series--hardware-development-boards-stmicroelectronics.pdf) ### Reference Manual / Datasheet / Errata - **RM0440** – STM32G4 Series Reference Manual [st.com → RM0440 PDF](https://www.st.com/resource/en/reference_manual/rm0440-stm32g4-series-advanced-armbased-32bit-mcus-stmicroelectronics.pdf) - **DS12288** – STM32G474xB/xC/xE Datasheet（本記事の数値根拠） [st.com → DS12288 PDF](https://www.st.com/resource/en/datasheet/stm32g474re.pdf) - STM32G47x / G48x device errata（品種別に ST.com から DL） ### 日本語トレーニング資料 / 参考 - [stmcu.jp – STM32G4 Analog ADC（日本語プレゼン）](https://www.stmcu.jp/wp/wp-content/uploads/files/presentation-ja/STM32G4/24_STM32G4-Analog-ADC-J-.pdf) - [stmcu.jp – STM32G4 Analog OPAMP（日本語プレゼン）](https://www.stmcu.jp/wp/wp-content/uploads/files/presentation-ja/STM32G4/27_STM32G4-Analog-OPAMP-(OPAMP)-J-.pdf) - [stmcu.jp – ADコンバータのサンプリング・サイクルの見積り](https://www.stmcu.jp/technical/hint/no-083/) - [stmcu.jp – ADコンバータのサンプリング時間の注意点](https://www.stmcu.jp/technical/hint/no-089/) - [Cerevo TechBlog – 内蔵ADCを用いた高精度・高確度の電圧測定と評価](https://tech-blog.cerevo.com/archives/13002/)（オーバーサンプリングで ENOB 改善の実測例） ## まとめ ### この記事のまとめ - STM32G4 は内蔵 OPAMP × 6 / COMP × 7 / 12-bit ADC × 5 を搭載する、ST 最強のアナログ寄りマイコン - 「5 Msps」は低分解能含む値。**12-bit では最大 4 Msps** - **STM32G4 では AN2834 の R_AIN_max 式は使わない**。DS12288 **Table 70 のルックアップ**を直接見るのが公式の流儀 - Fast channels (ADCx_IN1〜IN5) のみ 2.5 cycles サンプリング可能。Slow channels は最短 6.5 cycles - **内蔵 OPAMP を Voltage Follower で ADC 直結**すれば R_AIN を実質ゼロに（TS_OPAMP_VOUT = 200 ns） - OPAMP の High-Speed モードは Normal 比で SR 約 7 倍、消費電流は +0.1 mA のみ。バッテリ駆動以外はデフォルトで High-Speed 推奨 - COMP は **DAC を反転入力に直結**できる G4 ならではの強み。モータ制御の Blanking 機能も必須 - ハードウェアオーバーサンプリング 256x で ENOB +4 bit。256x で約 11 bit 程度まで詰められる実測例あり - Errata §2.7.7 / §2.7.9 / §2.10.1 など、計測誤差に直結する既知不具合は量産前に必ず確認 STM32G4 のアナログ機能をフル活用したモータ制御・電源制御・産業計測機器の設計でお困りのことがあれば、弊社にお気軽にご相談ください。アナログ寄り組込み案件の実績をもとに、回路設計からファームウェア実装・実機評価まで一貫してサポートします。 STM32G4 を使った高精度アナログ計測・モーター/電源制御の試作・量産、既存基板のトラブル調査も [組込み制御・マイコン開発](https://technosphere.co.jp/embedded) として対応しています。 ／この内容の受託開発・PoC相談はこちら＼ ### 高精度アナログ計測 + STM32 の受託開発 内蔵 OPAMP・COMP・ΔΣADC を活用したモータ制御、電力計、振動データロガー、産業計測機器など、アナログ × 組込みの境界が難しい案件を得意としています。回路設計から量産評価まで一貫対応。 [組込み開発サービスを見る](https://technosphere.co.jp/embedded) [高精度アナログ計測相談](https://technosphere.co.jp/contact) # STM32 # STM32G4 # ADC # OPAMP # COMP # アナログ計測 # R_AIN # サンプリング時間 ## 次に読む｜STM32 シリーズ記事 - [STM32 シリーズ STM32マイコンのUART・I2C・SPI・CAN通信 実装ガイド HAL ライブラリで通信ペリフェラルを使いこなす定番ガイド](https://technosphere.co.jp/blog/stm32-uart-i2c-can) - [STM32 シリーズ STM32 DMA 完全ガイド｜UART・SPI・ADCとの連携 ADC + DMA の Circular / ダブルバッファ実装](https://technosphere.co.jp/blog/stm32-dma-complete-guide) - [STM32 シリーズ ST-LINK が繋がらなくなった時の救出ガイド SWD ピン GPIO 化・Stop モード切断・RDP 全パターン対応](https://technosphere.co.jp/blog/stm32-swd-debugger-rescue) - [開発実績 組込み制御・マイコン開発 実績紹介 アナログ寄り案件を含む 20 年超の事例](https://technosphere.co.jp/embedded-achievements) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # STM32低消費電力モード完全ガイド｜CR2032で年単位のバッテリー駆動を実現する設計術｜テクノスフィア > STM32L4のRun/Sleep/Stop 0/1/2/Standby/Shutdown 全7モードを公式アプリケーションノートをもとに体系解説。HAL APIの使い方、ウェイクアップ設計、CR2032での寿命試算、実務で踏みがちな6つの落とし穴まで網羅した保存版ガイド。 URL: https://technosphere.co.jp/blog/stm32-low-power-battery ** 目次 1. はじめに：バッテリー駆動 IoT の設計課題 2. STM32L4 の7つの電力モード階層 3. モード別の代表的な消費電流（参考値） 4. HAL API 早見表とコード例 5. ウェイクアップ手段の選び方 6. 低消費電力ペリフェラル（LPUART / LPTIM / RTC） 7. バッテリー寿命を伸ばす実装の落とし穴 6選 8. バッテリー寿命の試算（CR2032 でのセンサーノード例） 9. 発展編：STM32U5 / WL / WB の進化 10. 公式リソース・参考文献 11. まとめ ** 本記事の数値について 本記事に記載する消費電流の数値は、ST 社の公式ドキュメント（アプリケーションノート・データシート・トレーニング資料）を参照した **代表的な参考値** です。実際の設計値は、お使いの品種の最新データシート（例：STM32L476 → **DS10198 Table 17 "STM32L476xx modes overview"**）と動作条件（VDD、温度、SYSCLK、ペリフェラル構成）で必ずご確認ください。本記事の最後に出典の正式番号と URL をまとめてあります。 ## はじめに：バッテリー駆動 IoT の設計課題 「コイン電池で5年動くセンサーノードを作ってほしい」「単三電池2本で10年保つLPWAN端末を量産したい」——こうした要件は、IoT 案件ではもはや珍しくありません。ハードウェア選定の段階で **低消費電力マイコンの選択肢として真っ先に挙がるのが STMicroelectronics の STM32L シリーズ** です。 なかでも **STM32L4 / L4+** は ARM Cortex-M4F コアを搭載しながら超低消費電力モードを多段に持ち、性能と省電力のバランスに優れることから世界中で採用されています。さらに最新の **STM32U5**（Cortex-M33）は LPBAM（Low-Power Background Autonomous Mode）で DMA さえも Stop モード中に自律動作させられる進化を遂げています。 ただし STM32L4 の電力モードは **7段階**（Run / LP Run / Sleep / LP Sleep / Stop 0/1/2 / Standby / Shutdown）あり、各モードで動作するペリフェラル・ウェイクアップ手段・メモリ保持有無が異なります。「とりあえず Stop モードに入れた」程度の実装ではコイン電池駆動でも数日でバッテリが尽きてしまうことも珍しくありません。 本記事では **STM32L4 シリーズ**を主軸に、ST 公式のアプリケーションノート（AN4621・AN4746・AN4899 ほか）とリファレンスマニュアル（RM0351）をもとに、年単位のバッテリー駆動を実現する設計ノウハウを体系的に解説します。基礎となる UART/I2C/SPI 通信や DMA 活用は、当ブログの以下記事も併せてご覧ください。 - [STM32マイコンのUART・I2C・SPI・CAN通信 実装ガイド](https://technosphere.co.jp/blog/stm32-uart-i2c-can) - [STM32 DMA 完全ガイド｜UART・SPI・ADC との連携](https://technosphere.co.jp/blog/stm32-dma-complete-guide) - [STM32 + FreeRTOS 入門](https://technosphere.co.jp/blog/stm32-freertos-intro) ** 弊社での活用実績 弊社では STM32L4 ベースの低消費電力センサーロガー・産業 IoT 端末・医療機器など [多数の組込み開発実績](https://technosphere.co.jp/embedded-achievements) があります。本記事はその実案件で蓄積したノウハウと、ST 公式ドキュメントの検証結果をもとに作成しています。 ## STM32L4 の7つの電力モード階層 STM32L4 / L4+ は、用途と消費電流のトレードオフに応じて 7 つの低消費電力モードを選択できます。(出典: AN4621 §1, §2 / RM0351 §5 PWR) | # | モード | レギュレータ | CPU | 主クロック | フラッシュ | | 1 | **Run** | Main (Range 1/2) | 動作 | MSI/HSI16/HSE/PLL | Active | | 2 | **Low-Power Run** | Low-Power Regulator (LPR) | 動作 (≤2MHz) | MSI ≤2MHz | Active | | 3 | **Sleep** | Main | WFI/WFE で停止 | 維持 | Active or PD | | 4 | **Low-Power Sleep** | LPR | 停止 | ≤2MHz | Active or PD | | 5 | **Stop 0** | Main 維持 | 停止、全クロック停止 | LSE/LSI のみ | OFF | | 6 | **Stop 1** | LPR | 停止 | LSE/LSI のみ | OFF | | 7 | **Stop 2** | LPR（低リーク） | 停止 | LSE/LSI のみ | OFF | | 8 | **Standby** | OFF（SRAM2 保持はオプション） | Reset | LSE/LSI のみ | OFF | | 9 | **Shutdown** | OFF（BOR も OFF） | Reset | LSE のみ | OFF | ### 選び方の指針 - **Run / Sleep：**高速処理が必要な能動的な区間。Sleep は CPU だけ止まりペリフェラル・DMA は継続動作 - **Low-Power Run / LP Sleep：**通信や演算を SYSCLK ≤2 MHz で粘りたい時。レギュレータが低消費版に切り替わる - **Stop 0 / 1 / 2：**センサー測定間の長い待機。**RAM とレジスタを保持**するため、復帰時にプログラム状態が継続できる - **Standby：**RTC で次回起動を待つ運用。**原則リセット起動**（SRAM2 は RRS=1 で 32 KB だけ保持可） - **Shutdown：**最も低消費。BOR/IWDG/LSI まで停止する代わりに、復帰は POR と同等 ** Stop 0 / 1 / 2 はどう違うのか - **Stop 0：**メインレギュレータが ON のままで残るため、Stop からの**復帰時間が最短**。消費は他の Stop より大きい - **Stop 1：**レギュレータが LPR に切り替わる標準的な Stop。多くの応用で第一候補 - **Stop 2：**VCORE 領域のリーク電流を最小化する超低消費 Stop。**USART/I2C/SDMMC 等の一部ペリフェラルが使えなくなる**制約あり。RTC・LPTIM・LPUART (HSI16/LSE) は動作可 センサー測定間の待機なら **Stop 2** が基本。応答時間に余裕がなく高速復帰が必要なら Stop 0、その中間が Stop 1 と覚えると整理しやすいです。(出典: AN4621 §3 / RM0351 §5.3) ## モード別の代表的な消費電流（参考値） STM32L4 系の代表値オーダー（VDD、温度、クロックなど条件で大きく変動）を以下に示します。**実設計には必ず該当品種のデータシート（DS10198 等）の Table 17 「modes overview」を参照** してください。 | モード | 条件（参考） | typ. 電流オーダー | 用途の典型 | | Run (Range 1) | 80 MHz | 数 mA ～ 十数 mA | 通常動作・通信中 | | Run (Range 2) | ~26 MHz 以下 | 数百 µA ～ 数 mA | 軽負荷の連続動作 | | LP Run | ~2 MHz | ~ 100 µA オーダー | 低速で粘る制御 | | Sleep (80MHz) | ペリフェラル動作中 | ~ 数 mA | DMA 受信待ちなど | | LP Sleep | ~2 MHz | ~ 数十 µA | ISR 待機など | | Stop 0 | VDD=3.0V, 25℃ | ~ 100 µA オーダー | 高速復帰が必要な短時間待機 | | Stop 1 | VDD=3.0V, 25℃ | ~ 数 µA | 通常の Stop 待機 | | Stop 2 | VDD=3.0V, 25℃, RTC ON | ~ 1 µA オーダー | センサーノードの長時間待機の本命 | | Standby | VDD=3.0V, RTC OFF | ~ 100 nA オーダー | RTC アラームまで完全停止 | | Shutdown | VDD=1.8V | ~ 数十 nA | 最低消費・状態保持不要 | ※ 上表は STM32L432・L476 などの公式データシートと STMicroelectronics の "STM32L4 System Power Control" トレーニング資料を参照した **オーダー感把握用の参考値** です。VDD、温度、SRAM 保持有無、ペリフェラル状態で大きく変わるため、最終設計値は最新データシートの Table 17 を必ずご確認ください。 ** 「Stop 1 vs Stop 2」は1桁違うことが多い 大雑把には **Stop 1 → Stop 2 で消費電流が約 1/数** ～ 1/数十程度になります。一方で Stop 2 では使えないペリフェラルがあるため、要件で **Stop 2 が使えるなら必ず Stop 2 にする** のが定石です。Standby までいくと nA オーダーまで落ちますが、RAM 失効・リセット復帰の代償があります。 ## HAL API 早見表とコード例 STM32CubeMX が生成する HAL ライブラリで使う低消費電力 API を、最も使う順にまとめます。(出典: STM32CubeL4 stm32l4xx_hal_pwr.c / stm32l4xx_hal_pwr_ex.c) | 関数 | 用途 | | `HAL_PWR_EnterSLEEPMode(Regulator, Entry)` | Sleep / LP Sleep | | `HAL_PWREx_EnterSTOP0Mode(Entry)` | Stop 0 | | `HAL_PWREx_EnterSTOP1Mode(Entry)` | Stop 1 | | `HAL_PWREx_EnterSTOP2Mode(Entry)` | Stop 2 | | `HAL_PWR_EnterSTANDBYMode()` | Standby | | `HAL_PWREx_EnterSHUTDOWNMode()` | Shutdown | | `HAL_PWREx_EnableLowPowerRunMode()` | LP Run へ移行 | | `HAL_PWR_EnableWakeUpPin(PinPolarity)` | WKUP ピン有効化 | | `HAL_SuspendTick() / HAL_ResumeTick()` | SysTick 停止/再開（Stop 進入前後） | ### Stop 2 → RTC で 10 秒後にウェイクアップ（典型パターン） ``` /* main.c：初期化後にこの関数を呼ぶ */ void EnterStop2_With_RtcWakeup_10s(void) { /* SysTick が起こす割り込みで Stop に入れない事故を防ぐ */ HAL_SuspendTick(); /* RTC Wakeup Timer：LSE/16 = 2048Hz をベースに 10秒 ≒ 20480 カウント */ HAL_RTCEx_DeactivateWakeUpTimer(&hrtc); HAL_RTCEx_SetWakeUpTimer_IT(&hrtc, 20480, RTC_WAKEUPCLOCK_RTCCLK_DIV16); /* Stop 2 に入る（復帰要因は WFI、RTC IT で起きる） */ HAL_PWREx_EnterSTOP2Mode(PWR_STOPENTRY_WFI); /* ----------------- ここからウェイクアップ後 ----------------- */ /* Stop から戻ると SYSCLK は MSI（典型 4 MHz）になっている。 必要なら SystemClock_Config() を呼んで PLL を復帰させる */ SystemClock_Config(); HAL_ResumeTick(); } /* RTC Wakeup 割り込みコールバック（HAL が呼ぶ） */ void HAL_RTCEx_WakeUpTimerEventCallback(RTC_HandleTypeDef *hrtc) { /* 必要に応じてフラグセット。基本は空でも問題なし */ } ``` ### Standby → WKUP1 (PA0) と RTC アラームで復帰 ``` void EnterStandby_With_WakeupPin_And_RtcAlarm(void) { /* WKUP フラグを必ずクリア（残っていると即時復帰する） */ __HAL_PWR_CLEAR_FLAG(PWR_FLAG_WU); /* WKUP1 (PA0) を High エッジで有効化 */ HAL_PWR_EnableWakeUpPin(PWR_WAKEUP_PIN1_HIGH); /* RTC アラーム A も併用（例：日次起動） */ /* RTC_AlarmTypeDef alarm = {...}; HAL_RTC_SetAlarm_IT(...) */ /* SRAM2 を保持したい場合はここで RRS ビットを立てる */ /* HAL_PWREx_EnableSRAM2ContentRetention(); */ HAL_PWR_EnterSTANDBYMode(); /* ここに戻ってくることは無い。次回起動は POR 相当（リセット） */ } ``` ** Stop から戻ったときのクロック Stop モードから復帰すると、SYSCLK は **MSI（典型 4 MHz）** に切り替わります。PLL で 80 MHz 動作している案件は、復帰直後に必ず `SystemClock_Config()` 相当を呼び直してクロックを復元してください。これを忘れると UART のボーレートが狂う・タイマーが想定外の周期になる、といったトラブルになります。(出典: RM0351 §6 RCC / AN4621 §4) ## ウェイクアップ手段の選び方 低消費電力モードからどの手段で起きるかは、システム要件で決まります。下表は STM32L4 で利用可能な主要なウェイクアップ要因と、各モードでの対応状況をまとめたものです。(出典: AN4621 §4 "Wake-up sources" / RM0351 §5.4) | ウェイクアップ要因 | Sleep | Stop 0/1/2 | Standby | Shutdown | | 任意の EXTI（GPIO 割り込み） | ○ | ○ | × | × | | WKUP ピン（PWR_CSR） | ○ | ○ | ○ | ○ | | RTC Alarm A/B | ○ | ○ | ○ | ○（LSE 必須） | | RTC Wakeup Timer | ○ | ○ | ○ | ○（LSE 必須） | | RTC Tamper / Timestamp | ○ | ○ | ○ | ○ | | LPUART 受信（RX） | ○ | ○ | × | × | | LPTIM（周期 IT） | ○ | ○ | × | × | | COMP（アナログ閾値） | ○ | ○ | × | × | | IWDG リセット | (常時) | ○ | ○ | × | | NRST | ○ | ○ | ○ | ○ | | BOR（Standby 用） | - | - | ○ | × | ### WKUP ピンの割り当て（STM32L4 系） WKUP は最大 5 本（WKUP1～WKUP5）。代表的なピン割り当てを以下に示しますが、**品種により WKUP3/WKUP5 のピン番号が異なる**ため、必ず該当品種データシートの Pinout 表で確認してください。(出典: AN4621 §4.4 / RM0351 §5.4.3 / DS10198 Table 16 など) - **WKUP1：**PA0 - **WKUP2：**PC13 - **WKUP3：**PE6 または PA1（品種依存） - **WKUP4：**PA2 - **WKUP5：**PC5 ** ウェイクアップ選択のクイックガイド - **定期測定（数秒～数時間周期）：**RTC Wakeup Timer を Stop 2 / Standby と組み合わせる - **外部イベント駆動（ボタン・センサー閾値）：**EXTI または WKUP ピン + Stop / Standby - **外部からの通信受信を待つ：**LPUART を HSI16/LSE クロックに設定して Stop モード受信ウェイクアップ - **アナログ閾値（電圧監視）：**COMP を EXTI 経由で Stop からウェイクアップ - **独立した周期ハートビート：**LPTIM を LSE 駆動で Stop 中も自律カウント ## 低消費電力ペリフェラル（LPUART / LPTIM / RTC） STM32L4 は **「Low-Power」プレフィックス**を持つ専用ペリフェラルで、Stop モード中もメインクロックなしで動作できます。バッテリー駆動設計の主役です。 ### LPUART：Stop モード中の通信受信待機 LPUART は **HSI16 または LSE クロックで動作可能**な UART で、Stop 0/1/2 のいずれでも受信ウェイクアップが可能です。(出典: RM0351 §38 LPUART / STM32CubeL4 LPUART_WakeUpFromStop 例) - LSE（32.768 kHz）駆動時は **最大 9600 bps** 程度まで - HSI16 駆動時は最大 高速通信可（ただし Stop からウェイクアップ目的なら省電力のため LSE を選ぶことも多い） - Stop モードに入る前に `HAL_UARTEx_EnableStopMode(&hlpuart1)` を呼ぶ必要あり - ウェイクアップ要因は「アドレスマッチ」「スタートビット検出」「Read Data Register Not Empty」から選択 ``` /* LPUART を Stop ウェイクアップ用に有効化 */ HAL_UARTEx_EnableStopMode(&hlpuart1); /* スタートビット検出でウェイクアップする設定（HAL_UARTEx_WakeUpType を使う） */ UART_WakeUpTypeDef wake_cfg = { .WakeUpEvent = UART_WAKEUP_ON_STARTBIT }; HAL_UARTEx_StopModeWakeUpSourceConfig(&hlpuart1, wake_cfg); /* Stop 1 に入る（LPUART RX で復帰可能） */ HAL_PWREx_EnterSTOP1Mode(PWR_STOPENTRY_WFI); ``` ### LPTIM：Stop モード中の周期タイマー LPTIM は LSE（32.768 kHz）駆動で Stop モード中も自律的にカウントし、周期割り込みで CPU を起こせます。RTC より細かい周期（ms オーダー）が必要な場合の選択肢です。(出典: AN4865 "LPTIM applicative use cases") ``` /* LPTIM1 を LSE 駆動、1秒周期で割り込み */ HAL_LPTIM_TimeOut_Start_IT(&hlptim1, 32768, /* Period: 32768 = 1秒 (LSE 32.768kHz) */ 32767); /* Pulse: タイムアウト後トグル */ /* Stop 2 に入る（LPTIM IT で復帰） */ HAL_PWREx_EnterSTOP2Mode(PWR_STOPENTRY_WFI); /* コールバック */ void HAL_LPTIM_CompareMatchCallback(LPTIM_HandleTypeDef *hlptim) { /* 周期処理 */ } ``` ### RTC + VBAT：完全停電時もカレンダーを維持 RTC（リアルタイムクロック）は LSE クロック + バックアップドメインで動作し、VBAT 端子にコイン電池を接続することで **VDD が完全に落ちてもカレンダーとバックアップレジスタを維持** できます。(出典: AN4759 "RTC and TAMP" / RM0351 §38 RTC) - **VBAT 端子：**典型的には CR2032 / CR1632 のコイン電池を接続。VDD 喪失時にバックアップドメインだけが VBAT から給電される - **バックアップレジスタ：**STM32L4 系は **32 × 32-bit（BKP0R - BKP31R、計 128 バイト）**。電源断後も VBAT 動作中は保持 - **LSE：**VBAT で動作可能 → Shutdown でも RTC 継続 - **LSI：**VBAT では動作しない → Shutdown では止まる - **Wakeup Timer：**16 bit カウンタ。ck_spre(1Hz) 基準では約 18 時間、WUCKSEL の拡張ビット（実質 17 bit）を使うと最長約 36 時間まで指定可能 ## バッテリー寿命を伸ばす実装の落とし穴 6選 低消費電力の数値スペックを満たしても、実装の細部が原因で「カタログ値の 10 倍消費している」という事態は珍しくありません。ST 公式 AN や現場で繰り返し見る典型ポイントを 6 つ整理します。 ### 1. 未使用 GPIO のアナログ入力化 STM32 の GPIO はデフォルトの「Floating Input」だとシュミットトリガが微妙な電圧で発振し、リーク電流の原因になります。**未使用ピンはすべて Mode=Analog, Pull=NoPull** に設定してください。STM32CubeMX には「Set unused GPIOs as analog」オプションがあります。(出典: AN4899 §6.1 "GPIO settings for low-power") ### 2. デバッガ接続時は Stop / Standby から復帰できない（ように見える） デバッグ中は `DBGMCU_CR` レジスタの **DBG_STOP / DBG_STANDBY ビット**がセットされ、クロックが維持されてしまいます。これにより**実機の消費電流が測れない**うえ、デバッガ切断後と挙動が変わります。実消費の検証時は、必ずデバッガを外し、フラッシュ書き込み後の cold boot で測定してください。(出典: RM0351 §47 DBG / community.st.com 多数) ### 3. SysTick が STOP 移行を妨害する HAL のタイムベースが SysTick の場合、移行直前に SysTick 割り込みがペンディングしていると Stop モードに入れず即時復帰してしまいます。次のいずれかで対処します。(出典: STM32CubeL4 examples / 国内技術ブログでも頻出) - Stop に入る直前に `HAL_SuspendTick()`、復帰後に `HAL_ResumeTick()` - または STM32CubeMX の **SYS タブで Timebase Source を TIM6 等の汎用タイマー**に変更（FreeRTOS 併用時はそもそも変更が必要） ### 4. Sleep / LP Sleep 中のフラッシュ Power-down Sleep モード中でもフラッシュは Active のままで微小に電力を消費します。SYSCLK を 2 MHz 以下に落としたうえで `__HAL_FLASH_SLEEP_POWERDOWN_ENABLE()` を呼ぶと、フラッシュをパワーダウンさせて更に消費を削減できます。**復帰時間が長くなる**代償があるため、応答時間要件と照らして判断してください。(出典: RM0351 §3.3.7 / AN4621 §4.2) ### 5. VREFINT・BOR・PVD の常時 ON によるリーク 内蔵リファレンス電圧 (VREFINT)、ブラウンアウトリセット (BOR)、プログラマブル電圧検出 (PVD) はいずれも微小ながら消費します。使わないなら確実に OFF にします。BOR は Standby 移行時に **Ultra-Low-Power BOR モード（ULPMEN）**に切り替えて消費を抑えるオプションもあります。(出典: RM0351 §5.1.2 PWR / community.st.com) ``` /* VREFINT を Stop モードで OFF */ HAL_PWREx_DisableVREFINTInStopMode(); /* Standby 中の BOR を超低消費モードに */ HAL_PWREx_EnableUltraLowPowerMode(); ``` ### 6. ペリフェラル CLK enable の残し 使い終わったペリフェラル（USART、SPI、ADC、DMA など）のクロックを `__HAL_RCC_xxx_CLK_DISABLE()` で確実に切ること。クロックが入っていると Stop モードでも微小リークが残り、複数ペリフェラル分が積み上がって µA 単位の差を生みます。(出典: AN4746 §4 / AN4621 §4) ** 実測のすすめ 低消費電力設計は **必ず実機で実測** してください。Nordic 製や JOULESCOPE などの µA レンジ電流計、もしくは STMicroelectronics の **STM32CubeMonitor-Power**（STLINK-V3PWR 等と組み合わせ）で時間軸付きで電流波形を見ると、想定外のスパイクや未消化のリークを発見できます。データシート値はあくまでも理想条件です。 ## バッテリー寿命の試算（CR2032 でのセンサーノード例） 具体的な計算例として、コイン電池 **CR2032（公称 230 mAh、3.0V）** で温湿度センサーノードを動作させる場合を考えます。(出典: AN4746 §5 "Application use case" を参考に独自試算) ### 基本式（duty cycle 法） ``` 平均消費電流 I_avg = (I_active × t_active + I_sleep × t_sleep) / (t_active + t_sleep) 動作可能時間 [h] = 電池容量 [mAh] × デレーティング係数 / I_avg [mA] ``` ### ケース 1：1 分周期でセンサー読み + 無線送信 - Active：センサー読み出し + 送信処理を 1 秒で完了 → **15 mA × 1 s** - Sleep：Stop 2 で待機 → **1.5 µA × 59 s** ``` I_avg = (15 × 1 + 0.0015 × 59) / 60 ≒ 0.252 mA 動作時間 = 230 mAh / 0.252 mA ≒ 913 h ≒ 38 日 ``` ### ケース 2：1 時間周期に間引いた場合 - Active：同じ 15 mA × 1 s - Sleep：Stop 2 で 3599 秒待機 ``` I_avg = (15 × 1 + 0.0015 × 3599) / 3600 ≒ 5.67 µA 動作時間 = 230 mAh / 0.00567 mA ≒ 40,600 h ≒ 4.6 年 ``` ** 試算時に忘れがちな補正項 - **自己放電：**CR2032 は年 1% 程度。10 年使うなら 10% の容量を予め差し引く - **温度補正：**コイン電池は -20℃ で公称容量の 60～70% 程度に低下する。屋外設置案件では重要 - **遮断電圧：**STM32L4 の VDD min は約 1.71V（BOR0 設定時）。コイン電池は 3.0V → 2.0V まで使えるが、レギュレータと外付け回路の動作下限を必ず確認 - **ピーク電流：**CR2032 の内部抵抗は 10～40Ω と高めなので、BLE 送信時（数十 mA）の電圧ドロップで瞬断する可能性あり。**大容量コンデンサの並列が必須**（典型 10～100 µF） - **起動・スリープ遷移コスト：**Stop → Run の復帰時にスパイクが出る。長周期で何度も遷移する設計では遷移コストの実測が必要 ST 公式サイトには **「STM32 Real-Time Clock Battery Life Calculator」** など、簡易計算ツールも公開されています。設計初期はこうしたツールでオーダー感を掴み、最終評価は必ず実機実測で確認してください。 ## 発展編：STM32U5 / WL / WB の進化 STM32L4 をベースに、用途に応じてより新しいシリーズを選ぶケースが増えています。 ### STM32U5（Cortex-M33、最新フラッグシップ） - **4段階の電圧 Range**（最大 160 MHz）。L4 の 2 Range より細かく性能/消費を最適化可能 - **Stop 3** が新設され、Stop 系の最低消費電力モードが追加 - **LPBAM（Low-Power Background Autonomous Mode）：**Stop 中も DMA + ペリフェラルが自律動作してデータ収集可能。CPU を起こさずセンサー連続サンプリングが実現できる L4 にない最大の進化点 (出典: AN5645 / AN5652) ### STM32WL（LoRa 一体型、Cortex-M4 + M0+） - サブ GHz Radio がチップ内蔵。CPU が Stop に入っていても Radio は独立動作可能 - LPWAN 端末（LoRaWAN/Sigfox）でコイン電池 5 年動作が現実的に (出典: AN5568) ### STM32WB（BLE 5、Cortex-M4 + M0+） - BLE スタックは M0+ コアが処理。M4 はアプリケーション専用に - SMPS（スイッチング電源）を内蔵し、送信時の消費電流を最小化 (出典: AN5246 "Usage of SMPS") ### シリーズ選定のクイックガイド - **有線 IoT・低コスト：**STM32L0 / L1（M0+/M3）または STM32L4（M4F） - **性能・セキュリティ重視：**STM32U5（M33 + TrustZone） - **BLE 内蔵：**STM32WB（BLE 5） - **LoRa / Sub-GHz：**STM32WL ## 公式リソース・参考文献 本記事執筆にあたり参照した ST 公式ドキュメントです。**実設計では必ず最新版をご参照ください**。 ### STM32L4 ターゲットの主要 Application Note - **AN4621** – STM32L4 and STM32L4+ ultra-low-power features overview [st.com → AN4621 PDF](https://www.st.com/resource/en/application_note/an4621-stm32l4-and-stm32l4-ultralowpower-features-overview-stmicroelectronics.pdf) - **AN4746** – How to optimize power and performance on STM32L4 and STM32L4+ MCUs [st.com → AN4746 PDF](https://www.st.com/resource/en/application_note/an4746-how-to-optimize-power-and-performance-on-stm32l4-and-stm32l4-mcus-stmicroelectronics.pdf) - **AN4555** – Getting started with STM32L4 series hardware development [st.com → AN4555 PDF](https://www.st.com/resource/en/application_note/an4555-getting-started-with-stm32l4-series-and-stm32l4-series-hardware-development-stmicroelectronics.pdf) - **AN4759** – Introduction to using the RTC and TAMP for STM32 MCUs [st.com → AN4759 PDF](https://www.st.com/resource/en/application_note/an4759-introduction-to-using-the-hardware-realtime-clock-rtc-and-the-tamper-management-unit-tamp-with-stm32-mcus-stmicroelectronics.pdf) - **AN4865** – How to use Low-power timer (LPTIM) on STM32 MCUs [st.com → AN4865 PDF](https://www.st.com/resource/en/application_note/an4865-how-to-use-lowpower-timer-lptim-on-stm32-mcus-and-mpus--stmicroelectronics.pdf) - **AN4899** – STM32 GPIO hardware settings and low-power consumption [st.com → AN4899 PDF](https://www.st.com/resource/en/application_note/an4899-stm32-microcontroller-gpio-hardware-settings-and-lowpower-consumption-stmicroelectronics.pdf) ### Reference Manual / Datasheet - **RM0351** – STM32L47/L48/L49/L4A reference manual [st.com → RM0351 PDF](https://www.st.com/resource/en/reference_manual/dm00083560.pdf) - **RM0394** – STM32L41/L42/L43/L44/L45/L46 reference manual [st.com → RM0394 PDF](https://www.st.com/resource/en/reference_manual/rm0394-stm32l41xxx42xxx43xxx44xxx45xxx46xxx-advanced-armbased-32bit-mcus-stmicroelectronics.pdf) - **RM0432** – STM32L4+ series reference manual [st.com → RM0432 PDF](https://www.st.com/resource/en/reference_manual/rm0432-stm32l4-series-advanced-armbased-32bit-mcus-stmicroelectronics.pdf) - **DS10198** – STM32L476 datasheet (消費電流テーブル Table 17 を含む) [st.com → DS10198 PDF](https://www.st.com/resource/en/datasheet/stm32l476rg.pdf) ### L5 / U5 / WB / WL の Application Note - **AN5213** – STM32L5 ultra-low-power features overview - **AN5652** – STM32U5 power optimization - **AN5645** – STM32U5 LPBAM (Low-Power Background Autonomous Mode) - **AN5568** – STM32WL ultra-low-power features - **AN5246** – STM32WB SMPS usage ### Wiki / Training / コミュニティ - [ST Wiki – PWR feature overview](https://wiki.st.com/stm32mcu/wiki/PWR_feature_overview) - [STM32L4 System Power Training (英語)](https://www.st.com/resource/en/product_training/stm32l4_system_power.pdf) - [STM32L4 システム電力制御 (日本語)](https://www.st.com/resource/ja/product_presentation/06.stm32l4-system-power-wspc-control-wspc-(pwr)-wspc-final_jp.pdf) - [STM32CubeL4 公式サンプル（GitHub）](https://github.com/STMicroelectronics/STM32CubeL4) - [stmcu.jp – Standby と Shutdown モードの違い](https://www.stmcu.jp/technical/hint/no-117/) ## まとめ ### この記事のまとめ - STM32L4 は **7段階の低消費電力モード** を持ち、用途別に細かく最適化できる - センサーノードの長時間待機には **Stop 2 + RTC Wakeup Timer** がまず第一候補 - 状態保持が不要なら **Standby**、究極の低消費なら **Shutdown**（LSE 必須） - LPUART・LPTIM・RTC は Stop モード中も動作可能で、ウェイクアップ手段の主役 - 未使用 GPIO のアナログ化、デバッガ非接続での実測、SysTick の停止、Flash Power-down など **6つの落とし穴** を押さえる - カタログ値ではなく **必ず実機で実測**（µA レンジ電流計や STM32CubeMonitor-Power） - 1 時間周期のセンサーノード設計で CR2032 から **4 年級の動作**が現実的に狙える - 新規設計なら **STM32U5（LPBAM）** や **WL/WB** も視野に STM32 を使った低消費電力 IoT 端末・バッテリー駆動センサーノードの設計でお困りのことがあれば、弊社にお気軽にご相談ください。STM32L4 / U5 系を含めた組込み開発実績をもとに、要件定義から回路設計・ファームウェア実装・実機消費電流評価まで一貫してサポートします。 STM32 を使った電池駆動 IoT 端末の設計から量産、既存機器の低消費電力化、実機消費電流評価まで [組込み制御・マイコン開発](https://technosphere.co.jp/embedded) として対応しています。 ／この内容の受託開発・PoC相談はこちら＼ ### STM32 + バッテリー駆動デバイスの受託開発 Stop / Standby / Shutdown モードを駆使した数年駆動の IoT センサー、ウェアラブル、屋外監視装置の設計をテクノスフィアが対応します。電池容量試算から PoC・量産化まで一気通貫。 [組込み開発サービスを見る](https://technosphere.co.jp/embedded) [バッテリー駆動設計相談](https://technosphere.co.jp/contact) ## よくある質問（FAQ） ** バッテリー駆動のSTM32でセンサー測定間の待機にはどのモードを使うべきですか？ Stop 2が定番です。µAオーダーまで消費電流を下げつつ、RTCウェイクアップ・WKUPピン・LPUART受信などで復帰できます。「Stop 2で待機し、RTCで周期的に起きて測定する」パターンがバッテリー駆動IoTの典型構成です。 ** Stopモード中でもUARTの受信を待てますか？ LPUARTを使えば可能です。LPUART・LPTIM・RTCはStopモード中も動作可能な低消費電力ペリフェラルで、LPUARTをHSI16/LSEクロックで動かしておけば受信をトリガーにStopモードから復帰できます。 ** 各電力モードの正確な消費電流はどこで確認すべきですか？ 最終判断は必ずデータシートで行ってください。品種ごとのデータシートに電力モード別一覧表（STM32L476ならDS10198のmodes overview表）があり、温度・電圧・ペリフェラル条件ごとの値が記載されています。記事中の数値は条件を揃えた参考値です。 ** 電源が完全に落ちても時計を維持するにはどうしますか？ RTCをVBAT端子のバックアップ電源（コイン電池等）で動かします。メイン電源が落ちてもRTCとバックアップレジスタは保持されるため、復電後もカレンダー・時刻を引き継げます。 # STM32 # STM32L4 # 低消費電力 # バッテリー駆動 # IoT # Standby # Stop # LPUART # LPTIM # RTC ## 次に読む｜STM32 シリーズ記事 - [STM32 シリーズ STM32マイコンのUART・I2C・SPI・CAN通信 実装ガイド HALライブラリで通信ペリフェラルを使いこなす定番ガイド](https://technosphere.co.jp/blog/stm32-uart-i2c-can) - [STM32 シリーズ STM32 + FreeRTOS 入門 タスク・キュー・セマフォを使ったRTOS実装ガイド](https://technosphere.co.jp/blog/stm32-freertos-intro) - [STM32 シリーズ STM32 DMA 完全ガイド｜UART・SPI・ADCとの連携 CPU負荷を最小化するDMA活用の決定版](https://technosphere.co.jp/blog/stm32-dma-complete-guide) - [開発実績 組込み制御・マイコン開発 実績紹介 バッテリー駆動IoT端末を含む多数の受託開発事例](https://technosphere.co.jp/embedded-achievements) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # STM32 で ST-LINK が突然繋がらなくなった時の救出ガイド｜SWD ピン誤定義・Stop モード切断・Connect Under Reset の全手順｜株式会社テクノスフィア > STM32 で誰もが遭遇する「ST-LINK が繋がらない」「Target was not detected」の救出手順を AN4989・UM2237・UM1075 を一次資料に 14 ステップで体系化。SWD 復旧から偽物検出まで網羅。 URL: https://technosphere.co.jp/blog/stm32-swd-debugger-rescue ** 目次 1. はじめに：誰もが一度は遭遇するエラー 2. SWD / SWO ピンの正式割当を再確認 3. 原因別 救出マトリクス（早見表） 4. 原因 A：SWD ピンを GPIO に再定義してしまった 5. 原因 B：Stop / Standby モードで切断される 6. 原因 C：CubeMX で "Serial Wire" を設定し忘れた 7. 原因 D：ST-LINK ハードウェア / ファームウェア 8. 原因 E：Read Out Protection (RDP) で締め出された 9. 原因 F：電源・配線・NRST まわり 10. 14 ステップ救出チェックリスト 11. 公式リソース・参考文献 12. まとめ ## はじめに：誰もが一度は遭遇するエラー STM32 で組込み開発をしていると、ある日突然 STM32CubeProgrammer や STM32CubeIDE から以下のようなエラーが出て書き込めなくなることがあります。 ``` Error: No STM32 target found! Error: Target was not detected Error: Connection cannot be established Unable to connect to ST-LINK The interface firmware FAILED to reset/halt the target MCU ``` 原因はおおまかに **6 系統** に分けられ、それぞれ救出手順がまったく違います。本記事では ST 公式の **AN4989「STM32 Microcontroller Debug Toolbox」**と **UM2237「STM32CubeProgrammer software description」** を一次資料に、原因別の救出フローと、最後の砦となる **14 ステップのチェックリスト**を体系化します。 ** 弊社での活用実績 弊社は STM32 F4 / L4 / G4 / U5 系を中心に [多数の組込み開発実績](https://technosphere.co.jp/embedded-achievements) があり、本記事に出てくる救出パターンはすべて現場で実際に遭遇したものです。基礎となる SWD ピン配置や CubeMX の使い方は [STM32 のUART・I2C・SPI・CAN通信 実装ガイド](https://technosphere.co.jp/blog/stm32-uart-i2c-can) を併せてご覧ください。 ## SWD / SWO ピンの正式割当を再確認 STM32（Cortex-M3 / M4 / M33 系）はリセット直後、以下のピンを **SWJ-DP（Serial Wire / JTAG Debug Port）専用**として確保しています。これは F1 / F4 / L4 / G4 / G0 / U5 など主要ファミリ共通です。(出典: ST Community「Reset state for JTAG pins」) | ピン | 機能 | リセット直後の状態 | | **PA13** | SWDIO（JTAG時 JTMS） | 入力、内部プルアップ有効 | | **PA14** | SWCLK（JTAG時 JTCK） | 入力、内部プルダウン有効 | | PA15 | JTDI（5pin JTAG時のみ） | AF 入力、内部プルアップ | | **PB3** | JTDO / TRACESWO（SWO 出力） | AF 出力（リセット直後 JTAG/SWV 用） | | PB4 | NJTRST | AF 入力、内部プルアップ | つまり **PA13 / PA14 / PB3 / PA15 / PB4 の 5 本は、外部回路で何もしなくても初期状態で「JTAG / SWD」用に確保されている** という設計です。CubeMX 上で「Debug = Serial Wire」を選んでいる場合は PA13 / PA14 / PB3 のみが SWJ-DP 用、PA15 / PB4 は通常 GPIO として解放されます。 ** CubeMX の Debug プルダウン項目 STM32CubeMX → **Pinout & Configuration → System Core → SYS → Debug** プルダウンの選択肢： - **Serial Wire**（推奨デフォルト。SWDIO + SWCLK のみ確保） - **Trace Asynchronous Sw**（Serial Wire + SWO（PB3）） - JTAG (4 pins) / JTAG (5 pins) - **No Debug** ← これを選ぶと PA13 / PA14 が GPIO に解放され、書き込み不能の最大原因になる 「とりあえず GPIO を増やしたい」という理由で No Debug を選んで生成した瞬間、次回フラッシュ書き込み後にデバッガから二度と見えなくなります。(出典: AN4989 Figure 24 "SWD Pins PA13 And PA14 In Reset State Under CubeMX") **STM32G0 / G4 系の例外**：BOOT0 ピンが PA14（SWCLK と物理同一ピン）と共有されている品種があり、Option Byte の `nBOOT_SEL` ビットでどちらの機能を優先するかが決まります。詳細は 原因 A で扱います。 ## 原因別 救出マトリクス（早見表） 症状からおおよその原因と救出手順を絞り込む早見表です。複数該当することも多いので、上から順に試すのが定石です。 | 症状の特徴 | 主原因 | 救出方法 | | 昨日まで動いていたのに突然繋がらない | SWD ピンを GPIO に再定義 / No Debug を選択 | Connect Under Reset → Mass Erase（原因A） | | 書き込みは一瞬通るがすぐ Disconnect される | 起動直後に Stop モード突入 | Connect Under Reset（原因B） | | STM32CubeIDE デバッグ中、Stop に入ると即切断 | DBGMCU_CR.DBG_STOP が 0 | `HAL_DBGMCU_EnableDBGStopMode()` 呼出し（原因B） | | 新規 CubeMX プロジェクトを書いた直後から接続不能 | SYS で Serial Wire 未設定 | Connect Under Reset → Mass Erase（原因C） | | 新しい品種が認識されない | ST-LINK ファームウェア古い | STSW-LINK007 で更新（原因D） | | "Unable to connect" でファーム情報も読めない | USB ケーブル / VAPP / 偽物 ST-LINK | ケーブル交換・VAPP 確認（原因D） | | Connect は通るが Read Out Protection エラー | RDP Level 1 / 2 | RDP regression（原因E） | | ターゲット電圧が読めない / VAPP 0V | ターゲット未給電・NRST Low固定 | 電源・配線確認（原因F） | ## 原因 A：SWD ピンを GPIO に再定義してしまった 最も頻発するパターンです。「GPIO がもう一つ欲しい」と PA13 / PA14 を出力に再割り当てしてビルド・書き込みした瞬間、次回からデバッガが応答しなくなります。ユーザコードの `MX_GPIO_Init()` で `GPIOA->MODER` が書き換えられた瞬間に SWJ-DP が物理切断されるためです。 ### Method A：Connect Under Reset（最も成功率が高い） STM32CubeProgrammer に最重要のオプション **"Under Reset" モード**があります。NRST を Low に保持しながら接続することで、ユーザコードが PA13 / PA14 を奪う **前**にデバッガが Halt させます。 1. STM32CubeProgrammer を起動し、右上の接続パネルで **"Mode" → "Under Reset"** を選択 2. **"Reset Mode" → "Hardware reset"** に設定 3. 必要に応じ **"Frequency" を 4 MHz → 1.8 MHz → 950 kHz** へ段階的に下げる 4. ターゲット側で物理 RESET ボタンを押し続ける 5. "Connect" をクリック 6. "Connected" 表示が出たら RESET ボタンを離す 7. すぐに **"Erase & Programming" タブ → "Full Chip Erase"** を実行 CLI でも同じ操作ができます。 ``` # Under Reset モードで接続テスト STM32_Programmer_CLI -c port=SWD mode=UR # 周波数を 1.8 MHz に下げて全消去 STM32_Programmer_CLI -c port=SWD mode=UR freq=1800 -e all ``` ### Method B：BOOT0 ピンで System Memory Bootloader を起動 Method A が効かない場合の本命です。**BOOT0 = High** で起動すると、STM32 は内蔵 ROM のシステムブートローダから起動し、ユーザコードは実行されません。SWD ピン GPIO 化問題を物理的にバイパスできます。 1. ターゲット電源 OFF 2. BOOT0 ピンを VDD（3.3V）にプルアップ。Nucleo 等の評価ボードでは BOOT0 タクトスイッチ / ジャンパで選択 3. 電源 ON（または NRST トグル） 4. システムブートローダが起動。USB DFU / UART / I2C / SPI / CAN のいずれかでホストと通信可能 5. STM32CubeProgrammer で対応する port を選択して接続（USB-DFU が手軽） 6. Full Chip Erase を実行 → SWD ピン GPIO 化のユーザコードが消える 7. BOOT0 を GND に戻し、電源 OFF / ON で通常起動。SWD で再接続可能になる 対応するブートローダ種別と各品種の詳細は **AN2606「STM32 microcontroller system memory boot mode」**に網羅されています。 ** STM32G0 系の罠：BOOT0 = PA14（SWCLK と共有） STM32G0 シリーズでは **BOOT0 と SWCLK が同じ PA14 ピン**に割り当てられています。さらにデフォルトの Option Byte は **nBOOT_SEL = 1, nBOOT0 = 1** なので、Option Bit が優先され **物理 BOOT0 ピンに 3.3V を入れても反応しません**。Method B を使うには事前に nBOOT_SEL = 0 に書き換える必要があります。 STM32L4R / L4S 系は PH3-BOOT0 兼用、STM32U5 / L5 / H5 系も Option Byte 制御です。**BOOT0 ピンの位置と挙動は必ず該当品種のデータシートで確認**してください。(出典: ST Community「STM32G030 BOOT0 versus SWD」/「PH3-BOOT pin」) ### Method C：偽物 / クローン ST-LINK の罠 Amazon / AliExpress 等で売られている互換 ST-LINK の中には、**NRST 線が物理的に結線されていない**個体が存在します。この場合 Connect Under Reset を選んでも NRST が駆動されないため、Method A が永久に効きません。 - 正規 ST-LINK V2 / V2-1 / V3 に交換するのが最も確実 - クローン品を改造して RESET 線を引き出す事例もある（自己責任） - または別ベンダの J-Link / Black Magic Probe で接続 ## 原因 B：Stop / Standby モードで切断される 低消費電力アプリでよくあるトラブルです。起動直後に Stop / Standby モードに入るコードを書き込むと、デバッガが Halt する前にチップが止まり、SWJ-DP に応答しなくなります。 ### DBGMCU レジスタで「デバッグ中だけ Stop/Standby を維持」 STM32 の **DBGMCU（Debug MCU configuration）** レジスタには、低消費電力モード中もクロックと電源を維持してデバッグを継続させるためのビットがあります。(出典: RM0351 / RM0440 §47 DBG) | ビット | 名前 | 効果 | | 0 | DBG_SLEEP | Sleep モード中も HCLK 維持、デバッグ継続可 | | 1 | DBG_STOP | Stop モード中も全クロック維持、デバッグ継続可 | | 2 | DBG_STANDBY | Standby モード中も電源・クロック維持、デバッグ継続可 | HAL API も用意されています。`main()` 冒頭に追加するだけで、デバッグ中は Stop / Standby から抜け出せるようになります。 ``` /* デバッグ中のみ Stop / Standby でクロック維持 */ #ifdef DEBUG HAL_DBGMCU_EnableDBGSleepMode(); HAL_DBGMCU_EnableDBGStopMode(); HAL_DBGMCU_EnableDBGStandbyMode(); #endif ``` ** リリースビルドで消費電流が下がらない問題 DBGMCU_CR は **POR（パワーオンリセット）でしかクリアされません**。System Reset（NRST）では値が残ります。デバッガで書き込んだリリース版が `DBG_STOP = 1` のまま走ると、Stop モード入っても本来の µA レベルまで消費電流が落ちません。 対策：① 一度電源を OFF / ON する、② ファーム冒頭で明示的に `DBGMCU->CR = 0;` を書く、③ IDE の「Reset after download」を有効化。(出典: ST Community「Increased consumption in low power modes」) ### すでに切断されたチップは Connect Under Reset で救う 「起動直後 Stop に入る」コードを書き込んでしまったあとは、**原因 A の Method A（Connect Under Reset）と同じ手順**でしか救えません。低消費電力設計の詳細は [STM32 低消費電力モード完全ガイド](https://technosphere.co.jp/blog/stm32-low-power-battery) をご覧ください。 ## 原因 C：CubeMX で "Serial Wire" を設定し忘れた 新規プロジェクト作成時に **SYS → Debug = "No Debug"** を選んだ状態で Code Generate → 書き込んでしまうケースです。生成された `MX_GPIO_Init()` 内で PA13 / PA14 が GPIO 入力（または Analog）として初期化されるため、書き込み直後に SWJ-DP が物理切断されます。 ### 救出 原因 A と完全に同じです。Connect Under Reset → Mass Erase で救出後、CubeMX の SYS タブで **Debug = "Serial Wire"** に変更して再生成・再書き込みしてください。 ### 予防策（開発中だけ） 開発中の予防策として、`main()` 冒頭に短い遅延を入れておくと、デバッガが割り込める窓ができます。 ``` int main(void) { HAL_Init(); SystemClock_Config(); #ifdef DEBUG HAL_Delay(2000); /* デバッガ救出用の窓（リリース時は #ifdef で外す） */ #endif /* ... 通常初期化と Stop モード突入など ... */ } ``` ## 原因 D：ST-LINK ハードウェア / ファームウェア ### ST-LINK 世代別の機能差 | 機種 | SWD | JTAG | SWO | VCP | 備考 | | ST-LINK/V2 | ○ | ○ | ○ | - | 標準スタンドアロン | | ST-LINK/V2-1 | ○ | - | ○ | ○ | Nucleo 等に内蔵、Mass Storage 書込可 | | STLINK-V3SET | ○ | ○ | ○ | ○ | 最新フラッグシップ、Bridge API 対応 | | STLINK-V3MINI(E) | ○ | - | ○ | ○ | 小型版 | ### ファームウェアが古いと新しい品種を認識しない STM32 の新しい品種（例：STM32U5、STM32N6 等）は、ST-LINK ファームウェアが古いと **"Unknown target"** 扱いされます。**STSW-LINK007** または STM32CubeProgrammer 内蔵の **"Firmware upgrade"** で最新版に更新してください。リリースノートは **RN0093** に集約されています。 ### VAPP / VTREF：ターゲット電源検出 ST-LINK の **VAPP ピン**（旧 VTREF）はターゲット VCC を検出してロジックレベルを合わせるためのものです。VAPP 配線忘れ・ターゲット電源 OFF の状態だと、ST-LINK は「ターゲット電源無し」と判定して接続を拒否します。 - ターゲット VDD（1.65V～3.6V）を VAPP に必ず接続 - 20pin コネクタなら 1 番ピンが VAPP - 5V トレラント入力なので 3.3V / 1.8V どちらでも可 ### VCP（Virtual COM Port）が認識されない Nucleo の場合 **CN3 ジャンパ**で ST-LINK ⇔ ターゲット UART の経路をオン / オフします。VCP が見えない時はジャンパ位置を確認。Windows 8 以降は ST-LINK V2-1 / V3 のドライバは OS 標準ですが、認識されない場合は手動更新かファーム更新が必要です。 ### USB ケーブル品質 意外と見落とされがちですが、データ線が省かれた「充電専用」USB ケーブルでは「電源は来るが SWD は通らない」状態になります。短い高品質ケーブルへ交換してください。 ## 原因 E：Read Out Protection (RDP) で締め出された RDP は Flash の不正読み出しを防ぐセキュリティ機能ですが、誤設定するとデバッグもできなくなります。Option Bytes の `FLASH_OPTR.RDP` バイトで制御されます。 | Level | バイト値 | 効果 | 戻せるか | | 0 | 0xAA | 全アクセス可 | - | | 0.5 | 0x55 | STM32 U5 等 TrustZone 系のみ。Non-secure のみ書込可 | 0 へ可 | | 1 | 0xAA / 0xCC 以外（典型 0xBB） | デバッガ・RAM・Bootloader からの Flash 読出禁止 | 0 へ regression 可（**Flash Mass Erase 自動実行**） | | 2 | 0xCC | JTAG / SWD / SWV / ETM / Boundary Scan 全停止、Option Byte 改変不可 | **不可（永久）** | ### RDP Level 1 からの解除手順 Level 1 は救えます。Mass Erase は強制されますが、デバッグ可能な状態に戻せます。 ``` # 現在の Option Bytes を表示 STM32_Programmer_CLI -c port=SWD -ob displ # RDP を 0xAA（Level 0）に書き戻す → 自動 Mass Erase STM32_Programmer_CLI -c port=SWD -ob RDP=0xAA # 完了まで 5〜10 秒。完了後 SWD で通常接続可能 ``` ** RDP Level 2 は絶対に誤設定しないこと RDP = 0xCC は **JTAG / SWD / SWV / ETM / Boundary Scan が永久に無効化**されます。Option Byte の書き換えすら不可能になり、その個体はデバッグもプログラム書き換えも一切できなくなります。実質的に廃棄です。Level 2 は最終量産直前の最後のステップだけで使用してください。 ### TrustZone 系（U5 / L5 / H5 / WBA）の追加注意 TrustZone を有効化（TZEN = 1）した状態で RDP = 1 にすると、**Non-secure コード実行中にしかデバッガ attach できない**制約が加わります。TZEN を 0 に戻すには RDP1 → RDP0 regression（= Mass Erase）が必須です。STM32 H5 / H7RS などでは **Debug Authentication (DA)** で password 認証付きの regression が可能になっており、AN6008 に手順がまとめられています。 ## 原因 F：電源・配線・NRST まわり ### NRST のプルアップとフィルタ - STM32 の NRST は **内蔵 40 kΩ プルアップ**と **内蔵 70 ns ノイズフィルタ**付き - 外付け **100 nF をグランド側**に置くと電磁ノイズ環境での誤リセットを防げる（必須ではないが推奨） - NRST が Low 固定（GND ショート、外付け回路の不具合）になっていると ST-LINK が永遠に Reset 状態から抜け出せず接続不能 ### BOOT0 浮き BOOT0 を物理的に何も接続しないと、起動するたびにランダムに ROM ブート / ユーザコード起動が切り替わってしまいます。**10 kΩ ～ 1 MΩ のプルダウン抵抗**を必ず接続してください。 ### VDD / VDDA 電源 VDD / VDDA が POR / PDR スレッショルド（典型 1.71V）未達だと、チップは Reset 状態に張り付き SWJ-DP に応答しません。電源が立ち上がっているか、ノイズで瞬断していないかを必ず実機で電圧確認してください。 ### SWD ライン長 SWD クロックは使用するデバッグプローブに依存し、**ST-LINK/V3 で最大 24 MHz 程度**まで設定できますが、**ノイズ環境では数 MHz 程度に落とす**のが安全です。配線は短く（典型 20 cm 以下）、GND を並走させてシールド代わりにすると安定します。 ## 14 ステップ救出チェックリスト 原因の特定が難しい場合、以下のチェックリストを上から順に試してください。経験上、9 割のケースは 10 番目までで解決します。 | # | チェック項目 | 対象原因 | | 1 | USB ケーブルを交換し、別 USB ポートへ挿し直す | D | | 2 | ST-LINK ドライバ確認・更新（特に Windows） | D | | 3 | ST-LINK ファームウェア更新（STSW-LINK007） | D | | 4 | ターゲット電源確認：VDD / VDDA 電圧、VAPP 接続、BOOT0 プルダウン | F | | 5 | SWD 配線導通チェック：SWDIO / SWCLK / GND / NRST / VAPP | F | | 6 | SWD 周波数を下げる：4 MHz → 1.8 MHz → 950 kHz | D / F | | 7 | STM32CubeProgrammer の "Mode" を "Under Reset"、"Reset Mode" を "Hardware reset" に | A / B / C | | 8 | 物理 RESET ボタンを押しながら "Connect"、接続後ボタン離して即 "Full Chip Erase" | A / B / C | | 9 | BOOT0 = High で System Memory Bootloader 起動 → DFU / UART で Mass Erase | A / B / C | | 10 | Option Bytes 読み出し（`-ob displ`）で RDP / nBOOT_SEL / nBOOT0 状態確認 | E | | 11 | RDP = 0xAA に書き戻し（自動 Mass Erase 実行） | E | | 12 | 別ベンダの probe（J-Link / Black Magic）で接続試行（ST-LINK 個体不良切り分け） | D | | 13 | 偽物 ST-LINK 疑いなら、NRST 配線をテスター確認 or 正規品に交換 | D | | 14 | TrustZone 系（U5 / L5 / H5）なら Debug Authentication / RDP regression 検討 | E | ** 切り分けのコツ - **別ボードでは ST-LINK が動くか** ― 別のターゲットで接続テストすれば、ST-LINK 自体の故障かが切り分けられる - **別の ST-LINK ではどうか** ― 同じターゲットを別の ST-LINK で接続。Connect Under Reset が効くかどうかで個体差を確認 - **BOOT0 = High でも繋がらないなら基板側の電源・水晶を疑う** ― ROM ブートでも繋がらない場合、ハードウェア起因の可能性が高い ## 公式リソース・参考文献 ### 最重要 Application Note / User Manual - **AN4989** – STM32 Microcontroller Debug Toolbox（救出全般の決定版） [st.com → AN4989 PDF](https://www.st.com/resource/en/application_note/an4989-stm32-microcontroller-debug-toolbox-stmicroelectronics.pdf) - **AN2606** – STM32 microcontroller system memory boot mode（BOOT0 ブートローダ仕様） [st.com → AN2606 PDF](https://www.st.com/resource/en/application_note/an2606-introduction-to-system-memory-boot-mode-on-stm32-mcus-stmicroelectronics.pdf) - **UM2237** – STM32CubeProgrammer software description [st.com → UM2237 PDF](https://www.st.com/resource/en/user_manual/um2237-stm32cubeprogrammer-software-description-stmicroelectronics.pdf) - **UM1075** – ST-LINK/V2 user manual [st.com → UM1075 PDF](https://www.st.com/resource/en/user_manual/um1075-stlinkv2-incircuit-debuggerprogrammer-for-stm8-and-stm32-stmicroelectronics.pdf) - **UM2448** – STLINK-V3SET user manual [st.com → UM2448 PDF](https://www.st.com/resource/en/user_manual/um2448-stlinkv3set-debuggerprogrammer-for-stm8-and-stm32-stmicroelectronics.pdf) - **RN0093** – ST-LINK firmware upgrade release note [st.com → RN0093 PDF](https://www.st.com/resource/en/release_note/rn0093-firmware-upgrade-for-stlink-stlinkv2-stlinkv21-and-stlinkv3-boards-stmicroelectronics.pdf) ### セキュリティ / TrustZone 系 - **AN5347** – Introduction to Arm TrustZone features on STM32 L5 / U5 / U3 - **AN5421** – Getting started with STM32 MCUs and Arm TrustZone - **AN6008** – Getting started with Debug Authentication (DA) for STM32 - **AN4758** – Proprietary Code Readout Protection on L4 / G4 / WB ### ツール - [STM32CubeProgrammer（公式書き込み・診断ツール）](https://www.st.com/en/development-tools/stm32cubeprog.html) - [STSW-LINK007（ST-LINK ファームウェア更新ツール）](https://www.st.com/en/development-tools/stsw-link007.html) ### コミュニティ・参考 - [ST Community – How to solve debugger connection issues](https://community.st.com/t5/stm32-mcus/how-to-solve-debugger-connection-issues/ta-p/49693) - [ST Community – FAQ STM32 boot process](https://community.st.com/t5/stm32-mcus/faq-stm32-boot-process/ta-p/49358) - [stmcu.jp – ST-LINK Utility のリセットスタート（日本語）](https://www.stmcu.jp/technical/hint/no-017/) ## まとめ ### この記事のまとめ - STM32 の SWD ピンは **PA13 (SWDIO) / PA14 (SWCLK) / PB3 (SWO)** がリセット直後の確保ピン - CubeMX で「Debug = No Debug」を選んだ瞬間に PA13 / PA14 が GPIO 解放され、書き込み不能の最大原因に - **Connect Under Reset** が SWD ピン GPIO 化・Stop モード突入・CubeMX 設定漏れすべての第一救出手段 - **BOOT0 = High で System Memory Bootloader** がそれでもダメな時の本命。STM32G0 系は nBOOT_SEL = 1 デフォルトに注意 - 低消費電力アプリでは `HAL_DBGMCU_EnableDBGStopMode()` を `#ifdef DEBUG` で囲んで活用。リリースビルドの消費電流問題に注意 - **RDP Level 2 は永久不可逆**。最終量産直前まで絶対に書かないこと - 偽物 ST-LINK は NRST 配線が省略されている個体があり、Connect Under Reset が効かない - **14 ステップのチェックリスト**を上から順に試せば 9 割のケースは解決する STM32 開発で「もうチップが壊れたかもしれない」と諦める前に、ぜひ本記事のチェックリストを試してみてください。それでも解決しない場合や、量産設計でこうしたトラブルを未然に防ぎたい場合は、弊社にお気軽にご相談ください。設計から量産対応まで、20 年超のマイコン開発実績で一貫してサポートします。 STM32 の量産トラブル・基板リバイバル・SWD 接続不能の調査・救出まで [組込み制御・マイコン開発](https://technosphere.co.jp/embedded) として対応しています。 ／この内容の受託開発・PoC相談はこちら＼ ### STM32 量産トラブル・基板リバイバルの受託対応 SWD接続不良・RDP 解除・量産バグの再現解析・既存基板の再生など、現場で詰んでいる組込みトラブルを救出します。20 年超のマイコン開発ノウハウをベースに、設計から量産対応まで一貫してサポート。 [組込み開発サービスを見る](https://technosphere.co.jp/embedded) [量産トラブル・救出相談](https://technosphere.co.jp/contact) ## よくある質問（FAQ） ** ST-LINKでSTM32に接続できなくなったとき、最初に何を試すべきですか？ 最も成功率が高いのはConnect Under Resetです。NRSTを配線した状態でSTM32CubeProgrammerのリセット方式をHardware resetにし、リセット直後にデバッガを接続します。それでも入れない場合はBOOT0 = HighでSystem Memory Bootloaderを起動し、DFU/UART経由でフラッシュを消去します。 ** SWDピンをGPIOに再定義して書き込めなくなった場合はどう復旧しますか？ リセット直後の瞬間はSWDピンがまだデバッグ機能に割り当てられているため、Connect Under Resetで接続してフラッシュを消去するのが定石です。接続できない場合はBOOT0 = Highで起動すればユーザーコードが実行されないため、System Memory Bootloader経由で復旧できます。 ** Stop/Standbyモードに入るとST-LINKが切断されるのはなぜですか？ 低消費電力モードではデバッグ用のクロックも停止するためです。開発中はHAL_DBGMCU_EnableDBGStopMode / HAL_DBGMCU_EnableDBGStandbyModeを呼んでおくとデバッグ接続を維持できます。消費電流が増えるため、量産ファームウェアでは必ず無効化（DBGMCU->CR = 0）してください。 ** 安価な互換ST-LINKで接続に失敗することはありますか？ あります。互換品にはRESET線が引き出されておらずConnect Under Resetが実行できない個体が存在します。正規のST-LINK V2 / V2-1 / V3に交換するのが最も確実で、代替としてJ-LinkやBlack Magic Probeを使う方法もあります。 # STM32 # ST-LINK # SWD # デバッガ # STM32CubeProgrammer # BOOT0 # RDP # マイコン開発 ## 次に読む｜STM32 シリーズ記事 - [STM32 シリーズ STM32マイコンのUART・I2C・SPI・CAN通信 実装ガイド HAL ライブラリで通信ペリフェラルを使いこなす定番ガイド](https://technosphere.co.jp/blog/stm32-uart-i2c-can) - [STM32 シリーズ STM32 低消費電力モード完全ガイド Stop / Standby / Shutdown 活用で年単位のバッテリー駆動](https://technosphere.co.jp/blog/stm32-low-power-battery) - [STM32 シリーズ STM32G4 内蔵アナログ計測誤差の罠 R_AIN とサンプリング時間の関係を一次資料で読み解く](https://technosphere.co.jp/blog/stm32-g4-analog-precision) - [開発実績 組込み制御・マイコン開発 実績紹介 STM32 量産案件を含む 20 年超の事例](https://technosphere.co.jp/embedded-achievements) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # STM32マイコンのUART・I2C・SPI・CAN通信 実装ガイド｜株式会社テクノスフィア > STM32マイコンのペリフェラル設定から実装まで解説。UART/I2C/SPI/CAN通信の使い分けとHALライブラリを使ったC言語サンプルコードを掲載。組込み開発歴20年超のエンジニアが在籍するテクノスフィアが解説。 URL: https://technosphere.co.jp/blog/stm32-uart-i2c-can ** 目次 1. はじめに：STM32が産業機器に選ばれる理由 2. STM32CubeMXによるペリフェラル設定 3. UART通信の実装 4. I2C通信の実装 5. SPI通信の実装 6. CAN通信の実装 7. 通信方式の使い分けガイド 8. よくあるトラブルと対策 9. まとめ ## はじめに：STM32が産業機器に選ばれる理由 STMicroelectronics（ST社）の **STM32シリーズ**は、産業機器・医療機器・車載システム・IoT機器など、あらゆる組込みシステムで広く採用されているARM Cortex-Mベースのマイコンです。弊社でも多数のSTM32を用いた[組込み受託開発実績](https://technosphere.co.jp/embedded-achievements)があります。 STM32が選ばれる主な理由を以下にまとめます。 - **豊富なペリフェラル：**UART・I2C・SPI・CAN・USB・Ethernet・ADC・DAC・TIMERなどをワンチップに搭載 - **HALライブラリ：**ST公式のHardware Abstraction Layerにより、ハードウェアを意識せずに開発できる - **STM32CubeMX：**GUIでピン割り当てや初期化コードを自動生成。開発効率が大幅に向上 - **コストパフォーマンス：**高性能ながら低コスト。量産時のコスト最適化がしやすい - **エコシステムの充実：**ST-LINK/V2などのデバッガ、Keil MDK・IAR・STM32CubeIDE などの開発環境が揃っている ** 弊社での活用実績 弊社では STM32F4・STM32G4・STM32H7 シリーズを中心に、センサーデータ収集装置・モーター制御・産業用通信ゲートウェイなど多数の組込み開発を手がけています。本記事はその実案件で得たノウハウをもとに作成しています。 ## STM32CubeMXによるペリフェラル設定 STM32CubeMXはST公式の無償ツールで、GUIでマイコンのピン配置・クロック設定・ペリフェラル設定を行い、HAL初期化コードを自動生成できます。従来はレジスタを直接叩いていた初期化作業が大幅に短縮されます。 ### 基本的な使い方 1. 使用するSTM32マイコンを選択（例：STM32F446RE） 2. 「Pinout & Configuration」タブでペリフェラルを有効化（例：USART2 → Asynchronous） 3. ピンアサインを確認・変更（コンフリクトがあれば自動警告） 4. 「Clock Configuration」タブでシステムクロックを設定 5. 「Project Manager」でプロジェクト名・IDEを選択（STM32CubeIDE / Keil / IAR） 6. 「Generate Code」でHAL初期化コードを自動生成 **生成されるファイル構成（STM32CubeIDE の場合）** ``` MyProject/ ├── Core/ │ ├── Inc/ │ │ ├── main.h # ペリフェラルのdefine定義 │ │ ├── usart.h │ │ └── i2c.h │ └── Src/ │ ├── main.c # メイン処理（ユーザーコードをここに追加） │ ├── usart.c # UART初期化コード（自動生成） │ └── i2c.c # I2C初期化コード（自動生成） └── Drivers/ ├── STM32F4xx_HAL_Driver/ # HALライブラリ本体 └── CMSIS/ ``` ** 注意点 CubeMXで再生成すると、`/* USER CODE BEGIN */`〜`/* USER CODE END */` の間に書いたコードは保持されますが、それ以外の箇所に直接書いたコードは上書きされます。必ずユーザーコード領域に記述してください。 ## UART通信の実装 UART（Universal Asynchronous Receiver/Transmitter）は、シリアル通信の中でも最もシンプルな方式です。デバッグ出力・PCとの通信・GPSモジュール・Bluetoothモジュール・各種センサーとの通信に広く使われます。 ### 基本送受信（ポーリング方式） 最もシンプルな実装です。送信完了または受信完了まで CPU がブロックされます。 ``` /* UART送信（ポーリング）*/ char tx_buf[] = "Hello STM32!\r\n"; HAL_UART_Transmit(&huart2, (uint8_t*)tx_buf, strlen(tx_buf), HAL_MAX_DELAY); /* UART受信（ポーリング）*/ uint8_t rx_buf[64]; HAL_StatusTypeDef ret = HAL_UART_Receive(&huart2, rx_buf, 10, 1000); // 10byte, 1000msタイムアウト if (ret == HAL_OK) { // 受信成功 } ``` ### 割り込み方式（推奨） 実案件では受信タイミングが不定なため、割り込み方式を使います。CPUをブロックせず効率的に処理できます。 ``` /* main.c – 受信割り込み開始 */ uint8_t rx_byte; HAL_UART_Receive_IT(&huart2, &rx_byte, 1); // 1バイト受信割り込みを有効化 /* stm32f4xx_it.c または main.c に追加 */ void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart->Instance == USART2) { // rx_byte に受信データが入っている process_received_byte(rx_byte); // 次の受信に備えて再度セット HAL_UART_Receive_IT(&huart2, &rx_byte, 1); } } /* DMA方式（大量データの高速受信）*/ uint8_t dma_rx_buf[256]; HAL_UART_Receive_DMA(&huart2, dma_rx_buf, 256); // 256バイト受信完了でHAL_UART_RxCpltCallbackが呼ばれる ``` ### printfのリダイレクト（デバッグ用） 標準のprintfをUART経由でPCのターミナルに出力するよう設定できます。デバッグ作業が大幅に楽になります。 ``` /* syscalls.c または main.c に追加 */ #include int __io_putchar(int ch) { HAL_UART_Transmit(&huart2, (uint8_t*)&ch, 1, HAL_MAX_DELAY); return ch; } /* 使用例 */ printf("温度: %.1f ℃, 電圧: %.3f V\r\n", temp, voltage); ``` ## I2C通信の実装 I2C（Inter-Integrated Circuit）は、SDA（データ）とSCL（クロック）の2線式シリアル通信です。センサー・EEPROM・RTC・LCD・DAC/ADCなど、低〜中速のデータ転送が必要なデバイスとの通信に適しています。7bitアドレスでは予約アドレスを除いた最大112台のデバイスを同一バスに接続できます。 ### メモリ書き込み・読み出し（EEPROMの例） ``` #define EEPROM_ADDR 0xA0 // 7bitアドレス 0x50 を左シフト → 0xA0 /* EEPROMへの書き込み（HAL_I2C_Mem_Write） */ uint8_t write_data[4] = {0x01, 0x02, 0x03, 0x04}; HAL_StatusTypeDef ret = HAL_I2C_Mem_Write( &hi2c1, // I2Cハンドル EEPROM_ADDR, // デバイスアドレス 0x0000, // メモリアドレス（書き込み先） I2C_MEMADD_SIZE_16BIT, // メモリアドレスサイズ write_data, // 送信データ 4, // データ長 HAL_MAX_DELAY ); /* EEPROMからの読み出し（HAL_I2C_Mem_Read） */ uint8_t read_data[4]; HAL_I2C_Mem_Read( &hi2c1, EEPROM_ADDR, 0x0000, I2C_MEMADD_SIZE_16BIT, read_data, 4, HAL_MAX_DELAY ); ``` ### 汎用デバイスの読み書き（レジスタアクセス） ``` /* センサーのレジスタ1バイトを読み出す */ uint8_t reg_addr = 0x75; // WHO_AM_I レジスタ（例：MPU-6050） uint8_t reg_data; HAL_I2C_Master_Transmit(&hi2c1, 0xD0, ®_addr, 1, HAL_MAX_DELAY); // レジスタアドレス送信 HAL_I2C_Master_Receive (&hi2c1, 0xD1, ®_data, 1, HAL_MAX_DELAY); // データ受信 /* あるいは Mem_Read で簡潔に書ける */ HAL_I2C_Mem_Read(&hi2c1, 0xD0, 0x75, I2C_MEMADD_SIZE_8BIT, ®_data, 1, HAL_MAX_DELAY); ``` ** 実案件でのポイント STM32のI2C実装では**クロックストレッチ問題**に注意が必要です。一部のセンサーはクロックストレッチを使用するため、STM32F1系ではドライバのバグが報告されています。STM32F4以降では改善されていますが、センサーのデータシートを必ず確認してください。プルアップ抵抗は4.7kΩを推奨します。 ## SPI通信の実装 SPI（Serial Peripheral Interface）は、MOSI・MISO・SCLK・NSS（CS）の4線式フルデュプレックス通信です。I2Cより高速（最大数十MHz）で、高サンプリングレートが必要なADC・加速度センサー・フラッシュメモリ・ディスプレイドライバなどに適しています。 ### フラッシュメモリ（W25Qシリーズ）への読み書き ``` #define FLASH_CS_PORT GPIOA #define FLASH_CS_PIN GPIO_PIN_4 /* CS をアサート（Low）してSPI送受信 */ static void SPI_CS_Select(void) { HAL_GPIO_WritePin(FLASH_CS_PORT, FLASH_CS_PIN, GPIO_PIN_RESET); } static void SPI_CS_Deselect(void) { HAL_GPIO_WritePin(FLASH_CS_PORT, FLASH_CS_PIN, GPIO_PIN_SET); } /* Manufacture/Device IDの読み出し（JEDEC ID: 0x9F） */ uint8_t tx[4] = {0x9F, 0x00, 0x00, 0x00}; uint8_t rx[4]; SPI_CS_Select(); HAL_SPI_TransmitReceive(&hspi1, tx, rx, 4, HAL_MAX_DELAY); SPI_CS_Deselect(); // rx[1]:Manufacturer ID, rx[2]:Memory Type, rx[3]:Capacity // W25Q64: 0xEF, 0x40, 0x17 /* ページ書き込み（256バイト単位） */ void Flash_PageWrite(uint32_t addr, uint8_t *data, uint16_t len) { uint8_t cmd[4]; cmd[0] = 0x02; // Page Program コマンド cmd[1] = (addr >> 16) & 0xFF; cmd[2] = (addr >> 8) & 0xFF; cmd[3] = (addr ) & 0xFF; SPI_CS_Select(); HAL_SPI_Transmit(&hspi1, cmd, 4, HAL_MAX_DELAY); // コマンド＋アドレス送信 HAL_SPI_Transmit(&hspi1, data, len, HAL_MAX_DELAY); // データ送信 SPI_CS_Deselect(); } ``` ### DMAによる高速SPI転送 ADCデータの高速収集やディスプレイのフレームバッファ転送など、大量データを扱う場合はDMAを使ってCPUをフリーにします。 ``` /* DMA送信（ノンブロッキング）*/ HAL_SPI_Transmit_DMA(&hspi1, frame_buffer, FRAME_SIZE); /* 転送完了コールバック */ void HAL_SPI_TxCpltCallback(SPI_HandleTypeDef *hspi) { if (hspi->Instance == SPI1) { SPI_CS_Deselect(); // 次のフレームの準備など } } ``` ## CAN通信の実装 CAN（Controller Area Network）は、自動車・産業機器・医療機器などで標準的に使われる堅牢な差動通信プロトコルです。マルチマスター方式でノイズ耐性が高く、**長距離・高ノイズ環境での多ノード通信**に最適です。STM32のCANコントローラはシリーズによって2種類あり、**STM32F1/F2/F4/F7/L4 などは bxCAN**、**STM32G0/G4/H7/L5/U5 などは FDCAN（CAN FD対応）**を内蔵します。本記事のコードは bxCAN（HAL_CAN_*）を例にしています。FDCAN搭載品では `HAL_FDCAN_*` 系のAPI（`FDCAN_HandleTypeDef` / `HAL_FDCAN_AddMessageToTxFifoQ` 等）を使用し、データ構造も異なる点にご注意ください。 ### CAN送信の実装（bxCAN） ``` /* CANの初期化（CubeMXで設定後、手動で有効化）*/ HAL_CAN_Start(&hcan1); HAL_CAN_ActivateNotification(&hcan1, CAN_IT_RX_FIFO0_MSG_PENDING); // 受信割り込み有効化 /* CAN送信 */ CAN_TxHeaderTypeDef tx_header; uint8_t tx_data[8]; uint32_t tx_mailbox; tx_header.StdId = 0x123; // 標準IDフレーム（11bit ID） tx_header.ExtId = 0; tx_header.IDE = CAN_ID_STD; tx_header.RTR = CAN_RTR_DATA; // データフレーム tx_header.DLC = 8; // データ長（最大8バイト） tx_header.TransmitGlobalTime = DISABLE; // 送信データのセット tx_data[0] = 0x01; tx_data[1] = 0x02; tx_data[2] = (uint8_t)(temperature * 10); // 温度×10（小数点1桁） // ... HAL_CAN_AddTxMessage(&hcan1, &tx_header, tx_data, &tx_mailbox); ``` ### CAN受信（割り込み方式） ``` /* 受信割り込みコールバック */ void HAL_CAN_RxFifo0MsgPendingCallback(CAN_HandleTypeDef *hcan) { CAN_RxHeaderTypeDef rx_header; uint8_t rx_data[8]; if (HAL_CAN_GetRxMessage(hcan, CAN_RX_FIFO0, &rx_header, rx_data) == HAL_OK) { // 受信IDで処理を振り分け switch (rx_header.StdId) { case 0x100: handle_motor_command(rx_data); break; case 0x200: handle_sensor_data(rx_data); break; default: break; } } } ``` ### CANフィルタ設定（受信IDのフィルタリング） CANバス上の全フレームをすべて受信すると処理負荷が増大します。受信したいIDだけを通過させるフィルタを設定します。 ``` /* IDリストモード（特定のIDのみ受信） */ CAN_FilterTypeDef filter; filter.FilterBank = 0; filter.FilterMode = CAN_FILTERMODE_IDLIST; // リストモード filter.FilterScale = CAN_FILTERSCALE_16BIT; filter.FilterIdHigh = 0x100 << 5; // 受信するID1 filter.FilterIdLow = 0x200 << 5; // 受信するID2 filter.FilterMaskIdHigh = 0x300 << 5; // 受信するID3（マスクモード時はマスク値） filter.FilterMaskIdLow = 0x400 << 5; // 受信するID4 filter.FilterFIFOAssignment = CAN_RX_FIFO0; filter.FilterActivation = ENABLE; HAL_CAN_ConfigFilter(&hcan1, &filter); ``` ** 産業現場での活用例 弊社では複数の製造設備をCAN接続したシステムを開発した実績があります。PLCとSTM32間のCAN通信で設備状態をリアルタイム収集し、生産管理システムへ転送するゲートウェイ装置です。CANの堅牢性により、工場の電気ノイズ環境でも安定稼働しています。重機向けCAN通信や産業IoTを含む事例は [組込み開発実績ページ](https://technosphere.co.jp/embedded-achievements) でご紹介しています。 ## 通信方式の使い分けガイド 実案件では複数の通信方式を組み合わせるケースがほとんどです。それぞれの特徴を理解して適切に選択することが重要です。 | 方式 | 速度 | 接続数 | 線数 | 主な用途 | | **UART** | 最大数Mbps | 1:1 | 2線（TX/RX） | PCデバッグ、GPS、Bluetooth、各種モジュール | | **I2C** | 100k / 400k / 1Mbps | 1:112 | 2線（SDA/SCL） | センサー、EEPROM、RTC、LCD（近距離・多デバイス） | | **SPI** | 数十Mbps | 1:N（CS切替） | 4線＋CS | ADC、フラッシュ、ディスプレイ（高速・高精度） | | **CAN** | 最大1Mbps | マルチマスター | 差動2線 | 車載・産業機器・長距離・高ノイズ環境 | | **Ethernet** | 100M / 1Gbps | 多数 | 4線〜 | クラウド連携・大量データ転送・Web通信 | | **Bluetooth（BLE）** | 最大2Mbps | 多数 | 無線 | スマホ連携・ウェアラブル・IoT端末 | ** 典型的な組み合わせ例 - **センサー収集 + クラウド送信：**I2C/SPI（センサー） + UART（デバッグ） + Ethernet（クラウド） - **産業用制御装置：**CAN（設備間通信） + SPI（ADC） + I2C（表示器） + UART（設定用） - **ウェアラブル機器：**I2C（センサー） + BLE（スマホ連携） + SPI（フラッシュログ） ## よくあるトラブルと対策 | 症状 | 原因 | 対策 | | UARTでデータ化け | ボーレート不一致 / ノイズ | 両デバイスのボーレートを再確認。過誤率（Error Rate）を計算して許容範囲内か確認。ケーブルを短くしシールド線を使用 | | I2CがHAL_BUSYを返す | バスロックアップ（前回通信が異常終了） | `HAL_I2C_DeInit(&hi2c1); HAL_I2C_Init(&hi2c1);` でリセット。またはGPIOをトグルしてSCLに9クロック印加してスレーブをリセット | | SPIで受信データが0xFF / 0x00になる | CS信号のタイミングミス / SPIモード不一致 | データシートでSPIモード（CPOL/CPHA）を確認。NSS管理をソフトウェア制御（SSM=1）に変更して手動でCS操作 | | CANがACKエラーを出す | 終端抵抗なし / ノード数1台 | CANバスの両端に120Ω終端抵抗を必ず接続。テスト時は最低2ノード必要（ループバックモードで単体テスト可能） | | DMA転送が途中で止まる | DMAストリームの競合 / バッファオーバーフロー | CubeMXでDMAストリームの競合がないか確認。ダブルバッファモードを使用して連続転送を安定化 | ** デバッグツールの活用 - **ロジックアナライザ（例：Saleae Logic）：**UART/I2C/SPIの信号を可視化。プロトコルデコード機能でデータ内容も確認できる - **オシロスコープ：**信号の波形品質（立ち上がり・ノイズ）を確認 - **ST-LINK/V2 + STM32CubeIDE：**ブレークポイント・変数ウォッチでリアルタイムデバッグ - **CAN Analyzer（例：PEAK PCAN-USB）：**CANバスのトラフィックをモニタリング ## まとめ ### この記事のまとめ - STM32はUART・I2C・SPI・CANを全搭載し、産業機器から民生品まで幅広く対応できる - STM32CubeMXでペリフェラルの初期化コードを自動生成し、開発工数を大幅に削減できる - UART：デバッグ・外部モジュール接続、I2C：センサー・多デバイス接続、SPI：高速ADC・フラッシュ、CAN：産業・車載の多ノード通信 と使い分ける - 本番運用では割り込み・DMA方式を活用してCPUの処理効率を上げる - ロジックアナライザとオシロスコープを使ったハードウェアデバッグが通信トラブル解決の近道 STM32を使った組込みシステム開発・通信設計でお困りのことがあれば、弊社にお気軽にご相談ください。要件定義から設計・実装・量産対応まで、一貫してサポートします。 STM32 を使った UART/I2C/SPI/CAN 通信機器の試作・量産設計、産業 IoT ゲートウェイ開発、既存基板からの移行や量産時の通信トラブル調査まで、[組込み制御・マイコン開発](https://technosphere.co.jp/embedded) として受託対応しています。 ／この内容の受託開発・PoC相談はこちら＼ ### STM32 通信ペリフェラル実装・産業IoTの受託開発 UART・I2C・SPI・CAN を組み合わせた産業機器・医療機器・車載・IoTゲートウェイの設計と量産対応まで、テクノスフィアにご相談ください。要件定義から PoC・量産まで一貫対応します。 [組込み開発サービスを見る](https://technosphere.co.jp/embedded) [UART・CAN通信トラブル相談](https://technosphere.co.jp/contact) ## よくある質問（FAQ） ** STM32のUART・I2C・SPI・CANはどう使い分ければよいですか？ UARTはデバッグ出力やGPS・無線モジュールなど1対1のシリアル接続、I2Cは2線でセンサーやEEPROMを複数ぶら下げる用途、SPIは高速ADCやフラッシュ・LCDなど高スループットが必要な近距離接続、CANは産業機器・車載で複数ノードをノイズに強く接続する用途に向いています。 ** STM32CubeMXを使うとUART/I2C/SPI/CANの実装はどのくらい楽になりますか？ STM32CubeMXはピン割り当て・クロック設定・ペリフェラル初期化のCコードを自動生成するため、HALベースの初期化を手書きする工数を大幅に削減できます。生成後は `HAL_UART_Transmit()` などの送受信APIを呼ぶだけで通信を開始できます。 ** 通信が動かないときはどこを確認すればよいですか？ ボーレート／クロック設定の不一致、I2Cのプルアップ抵抗の有無、SPIのモード（CPOL/CPHA）違い、CANのビットレートと終端抵抗120Ωを確認します。ロジックアナライザやオシロスコープで実波形を観測するのが解決の近道です。 ** 本番運用ではポーリングと割り込み・DMAのどちらを使うべきですか？ CPU負荷を抑え取りこぼしを防ぐため、本番では割り込みまたはDMA方式を推奨します。特に高速・大容量転送や、複数処理を並行させる場合はDMAを使うとCPUを解放でき、リアルタイム性が向上します。詳しくは [STM32 DMA 完全ガイド](https://technosphere.co.jp/blog/stm32-dma-complete-guide) を参照してください。 # STM32 # UART # I2C # SPI # CAN通信 # マイコン開発 # 組込み制御 # HAL ## 次に読む｜STM32 シリーズ記事 - [STM32 シリーズ STM32 + FreeRTOS 入門 タスク・キュー・セマフォを使ったRTOS実装ガイド](https://technosphere.co.jp/blog/stm32-freertos-intro) - [STM32 シリーズ STM32 DMA 完全ガイド｜UART・SPI・ADCとの連携 CPU負荷を最小化するDMA活用の決定版](https://technosphere.co.jp/blog/stm32-dma-complete-guide) - [STM32 シリーズ STM32 低消費電力モード完全ガイド バッテリー駆動を年単位で実現する設計ノウハウ](https://technosphere.co.jp/blog/stm32-low-power-battery) - [開発実績 組込み制御・マイコン開発 実績紹介 CAN通信・カメラミドル・産業IoTなど多数の受託開発事例](https://technosphere.co.jp/embedded-achievements) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # STM32で始めるZephyr RTOS入門｜FreeRTOSとの違いと使い分け判断ガイド｜株式会社テクノスフィア > STM32（Nucleo-F446RE）でZephyr RTOSを始める実践ガイド。west環境構築の実コマンド、Lチカ→スレッド→デバイスツリーの流れ、prj.confによるKconfig設定を解説。FreeRTOSとの比較表・使い分け基準・既存資産の移行判断まで、組込み開発歴20年超のエンジニアが在籍するテクノスフィアが解説。 URL: https://technosphere.co.jp/blog/stm32-zephyr-rtos-intro ** 目次 1. はじめに：なぜ今Zephyrなのか 2. ZephyrはFreeRTOSと何が違うのか 3. west環境構築：実コマンドで一気に 4. Nucleo-F446REでLチカ（blinky） 5. スレッドを作る：FreeRTOSとの対応表つき 6. デバイスツリー：FreeRTOS経験者が最初に躓く壁 7. Kconfig（prj.conf）の基本 8. FreeRTOSとの比較表と使い分け基準 9. 既存FreeRTOS資産がある場合の移行判断 10. FreeRTOS経験者がハマる落とし穴 11. まとめ ## はじめに：なぜ今Zephyrなのか STM32のRTOSといえば長らく「STM32CubeMXでFreeRTOSを有効化」が定番でした。弊社でも多くの案件でこの構成を採用しており、その基本は [STM32 + FreeRTOS 入門](https://technosphere.co.jp/blog/stm32-freertos-intro) で解説したとおりです。しかしここ数年、新規案件のRTOS選定で**Zephyr RTOS**が対抗馬として挙がる機会が急激に増えています。 背景には3つの流れがあります。 - **プロジェクトの成熟：**ZephyrはLinux Foundation傘下で2016年に発足し、2026年で**10周年**を迎えました。2026年3月のembedded world（ニュルンベルク）では10周年が大きく取り上げられ、参画企業も拡大を続けています。サポートボードは**1000種類超**、STM32はNucleo/Discoveryを中心にほぼ全シリーズが公式対応です - **EUサイバーレジリエンス法（CRA）：**2024年12月に発効したCRAは、2026年9月11日から脆弱性報告義務、2027年12月11日から本格適用が始まります。Zephyrは2017年からCVE採番機関（CNA）として活動し、SBOM自動生成（`west spdx`）や脆弱性アラート登録制度を整備しており、「CRA時代のRTOS」として注目されています - **「カーネルだけ」では足りない製品要件：**BLE・Wi-Fi・USB・ファイルシステム・OTA更新が当たり前になり、カーネル単体のFreeRTOSでは周辺ライブラリの寄せ集めとバージョン管理が負担になってきました 本記事では、実際にNucleo-F446REを使って**west環境構築 → Lチカ → スレッド → デバイスツリー**と手を動かしながらZephyrの世界観を掴み、最後にFreeRTOSとの使い分け基準を整理します。なお執筆時点（2026年7月）のZephyr最新安定版は**v4.4.0**（2026年4月14日リリース）、長期サポート版（LTS）は**v3.7**です。 ** この記事の位置づけ 本記事は [STM32 + FreeRTOS 入門](https://technosphere.co.jp/blog/stm32-freertos-intro) の姉妹編です。FreeRTOS側の記事で解説したタスク・キュー・セマフォの概念はZephyrでもそのまま通用するので、RTOSそのものが初めての方は先にFreeRTOS編を読むことをお勧めします。本記事は「FreeRTOSは使ったことがあるが、Zephyrはこれから」という方を主読者に想定しています。 ## ZephyrはFreeRTOSと何が違うのか 最初に押さえるべき本質的な違いは、**提供範囲**です。 - **FreeRTOSは「カーネル」：**スケジューラ・タスク・キュー・セマフォを提供するC言語ソース一式（十数ファイル）です。GPIOやUARTのドライバはST社のHAL、BLEやTCP/IPは別ライブラリを自分で組み合わせます。プロジェクト構成の主導権はSTM32CubeMX/CubeIDEにあります - **Zephyrは「OSディストリビューション」：**カーネルに加えて、デバイスドライバ（GPIO/UART/I2C/SPI/ADC/CAN…）、Bluetooth LEスタック、ネットワークスタック、ファイルシステム、ロギング、シェル、テストフレームワークまでを単一のソースツリーとビルドシステムで提供します。ST社のHALも`hal_stm32`モジュールとしてZephyrのドライバ内部に取り込まれています この違いが開発フローに直結します。FreeRTOSでは「CubeMXでポチポチ設定してコード生成」でしたが、Zephyrでは**west**（メタツール）でソースを取得し、**デバイスツリー**でハードウェアを記述し、**Kconfig**で機能を選択してビルドします。GUIのコード生成ツールは基本的に使いません。Linuxカーネル開発の作法をマイコンに持ち込んだ、と考えると理解が早いです。 つまりZephyrの学習コストの大半は、RTOSカーネルのAPIではなく**ビルドシステムと設定機構（west・デバイスツリー・Kconfig）**にあります。逆に言えば、そこさえ越えればカーネルAPIはFreeRTOS経験者ならすぐ読めます。 ## west環境構築：実コマンドで一気に Ubuntu（WSL2含む）での手順です。Zephyrの公式Getting Startedに準拠しています。事前にaptで `cmake`（3.20.5以上）、`ninja-build`、`device-tree-compiler`（1.4.6以上）、`python3-venv` 等を入れておきます。Pythonは**3.12が強く推奨**されています（新しすぎるPythonでpipパッケージのビルドに失敗する事例があるため）。 ``` # 1. Python仮想環境を作成してwestをインストール python3 -m venv ~/zephyrproject/.venv source ~/zephyrproject/.venv/bin/activate pip install west # 2. Zephyr本体と依存モジュール（hal_stm32等）を取得 west init -m https://github.com/zephyrproject-rtos/zephyr ~/zephyrproject cd ~/zephyrproject west update # 数GB。初回は時間がかかる # 3. CMakeパッケージ登録とPython依存のインストール west zephyr-export west packages pip --install # 4. Zephyr SDK（クロスコンパイラ一式）をインストール cd ~/zephyrproject/zephyr west sdk install ``` ポイントを補足します。 - **`west update` が取ってくるのはZephyr本体だけではない：**`modules/hal/stm32`（ST公式HAL/LL）など数十のモジュールリポジトリを `west.yml`（マニフェスト）に従って一括チェックアウトします。FreeRTOSで「HALのバージョンとミドルウェアのバージョンの組み合わせ」に悩んだ経験があるなら、この**マニフェストによるバージョン一括固定**はZephyrの大きな魅力です - **SDKはARM GCCを含むツールチェーン集：**`west sdk install` 一発で入ります。STM32CubeIDE同梱のGCCとは独立しているので既存環境を汚しません - **仮想環境の有効化を忘れない：**シェルを開き直したら毎回 `source ~/zephyrproject/.venv/bin/activate` が必要です。「昨日は動いたのに `west: command not found`」の原因はほぼこれです ** 書き込みツールは別途必要 Nucleoボードへの `west flash` はデフォルトで **STM32CubeProgrammer** をランナーとして使います（OpenOCD・J-Linkも選択可）。ST公式サイトからCLI版を含むSTM32CubeProgrammerをインストールし、PATHを通しておいてください。ここを飛ばすと、ビルドは通るのに書き込みの段階で STM32_Programmer_CLI が見つからないエラーで止まります。 ## Nucleo-F446REでLチカ（blinky） まずは公式サンプルの `samples/basic/blinky` を焼いてみます。Nucleo-F446REはZephyrに `nucleo_f446re` というボード名で登録されており、オンボードLED（LD2 / PA5）とユーザーボタン（PC13）、コンソール用UART（USART2、115200bps 8N1、ST-LINKの仮想COM経由）まで定義済みです。 ``` cd ~/zephyrproject/zephyr # -p always: ビルドディレクトリを毎回クリーン（ボード切替時の事故防止） west build -p always -b nucleo_f446re samples/basic/blinky # ST-LINK経由で書き込み（STM32CubeProgrammerランナー） west flash ``` LD2が1秒周期で点滅すれば成功です。blinkyの `main.c` は本質的に次の内容です。 ``` #include #include #define SLEEP_TIME_MS 1000 /* デバイスツリーの led0 エイリアスからピン情報を取得（ビルド時に解決） */ #define LED0_NODE DT_ALIAS(led0) static const struct gpio_dt_spec led = GPIO_DT_SPEC_GET(LED0_NODE, gpios); int main(void) { if (!gpio_is_ready_dt(&led)) { return 0; } gpio_pin_configure_dt(&led, GPIO_OUTPUT_ACTIVE); while (1) { gpio_pin_toggle_dt(&led); k_msleep(SLEEP_TIME_MS); } return 0; } ``` FreeRTOS + HALの感覚で見ると、**コードのどこにも「GPIOA」「ピン5」が出てこない**ことに気づくはずです。`DT_ALIAS(led0)` は「このボードで led0 と名付けられたLED」をデバイスツリーから引いてくるマクロで、実体（PA5）はボード定義ファイルに書かれています。だからこのmain.cは**一切書き換えずに** `west build -b nucleo_h743zi` でH7ボードでも動きます。これがZephyr流の移植性です。 ## スレッドを作る：FreeRTOSとの対応表つき ZephyrではFreeRTOSの「タスク」に相当するものを「スレッド」と呼びます。もっとも簡単な作り方は `K_THREAD_DEFINE` マクロによる静的定義です。 ``` #include #define STACK_SIZE 1024 /* センサー読み取りスレッド（高優先） */ void sensor_thread(void *p1, void *p2, void *p3) { while (1) { /* ここでI2Cセンサー読み取りなど */ k_msleep(100); } } /* ログ出力スレッド（低優先） */ void logger_thread(void *p1, void *p2, void *p3) { while (1) { printk("uptime=%lld ms\n", k_uptime_get()); k_msleep(500); } } /* K_THREAD_DEFINE(名前, スタック, エントリ, 引数x3, 優先度, オプション, 開始遅延ms) 注意: Zephyrは数値が小さいほど高優先度（FreeRTOSと逆！） */ K_THREAD_DEFINE(sensor_tid, STACK_SIZE, sensor_thread, NULL, NULL, NULL, 5, 0, 0); K_THREAD_DEFINE(logger_tid, STACK_SIZE, logger_thread, NULL, NULL, NULL, 7, 0, 0); ``` スケジューラの起動コード（FreeRTOSの `osKernelStart()` 相当）が**どこにも無い**点に注目してください。Zephyrではカーネルが `main()` より先に初期化され、`main()` 自体が1つのスレッドとして走ります。`K_THREAD_DEFINE` したスレッドは起動時に自動で走り出します。動的生成したい場合は `k_thread_create()`（スタック領域は `K_THREAD_STACK_DEFINE` で確保）を使います。 ### 最重要の注意：優先度の向きがFreeRTOSと逆 Zephyrの公式ドキュメントには「数値が小さい優先度が、数値が大きい優先度に優先する」と明記されています。つまり**優先度5のスレッドは優先度7のスレッドより偉い**。FreeRTOS（数値が大きいほど高優先）の頭のままコピペ移植すると、優先度設計が丸ごと反転する事故になります。さらにZephyrでは**負の優先度は協調（cooperative）スレッド**という特別な意味を持ち、自分からブロックするまでプリエンプトされません。 ### FreeRTOS API → Zephyr API 対応表 | やりたいこと | FreeRTOS / CMSIS-OS v2 | Zephyr | | タスク／スレッド生成 | `xTaskCreate` / `osThreadNew` | `K_THREAD_DEFINE` / `k_thread_create` | | 待機（ms） | `vTaskDelay` / `osDelay` | `k_msleep` / `k_sleep` | | メッセージキュー | `xQueueSend/Receive` / `osMessageQueue*` | `K_MSGQ_DEFINE` + `k_msgq_put/get` | | セマフォ | `xSemaphoreGive/Take` / `osSemaphore*` | `k_sem_give` / `k_sem_take` | | ミューテックス | `xSemaphoreCreateMutex` / `osMutex*` | `k_mutex_lock/unlock`（優先度継承あり） | | ISRからの通知 | `xxxFromISR` 系API | セマフォ・キュー等のisr-ok APIはそのまま使える（`K_NO_WAIT` 指定） | | ソフトウェアタイマー | `xTimerCreate` / `osTimer*` | `K_TIMER_DEFINE` / `k_timer_start` | ISR まわりはZephyrの方がシンプルで、セマフォやメッセージキューはFreeRTOSのように「FromISR版を呼び分ける」ことなくそのまま使えます（ISR内ではブロック禁止＝`K_NO_WAIT`を指定）。ただしすべてのAPIがISR対応（isr-ok）ではなく、たとえばミューテックスはISRから一切使えない点には注意してください。FreeRTOSでのISR連携の勘所は [FreeRTOS編の記事](https://technosphere.co.jp/blog/stm32-freertos-intro) で解説しています。 ## デバイスツリー：FreeRTOS経験者が最初に躓く壁 Zephyr導入でつまずくポイントの筆頭がここです。逆にここを理解すればZephyrは一気に楽になるので、考え方を丁寧に説明します。 ### 考え方：ハード構成をCコードから追い出す CubeMX + HALの世界では「PA5を出力に設定」という**ハードウェアの事実**が、生成コードやマクロ定義としてCソースの中に散らばります。Zephyrではこれを**デバイスツリー（Devicetree）**という宣言的なテキスト（`.dts` / `.dtsi` / `.overlay`）に分離します。階層は次のとおりです。 - **SoC定義（.dtsi）：**`stm32f446.dtsi` など。USART2は0x40004400にある、といったチップの事実。Zephyr本体に同梱 - **ボード定義（.dts）：**`nucleo_f446re.dts`。LD2はPA5、コンソールはUSART2、といったボードの事実。これも同梱 - **アプリのオーバーレイ（.overlay）：**自分の基板・配線の事実。アプリ側で「上書き・追記」する差分ファイル アプリのディレクトリに `boards/nucleo_f446re.overlay`（または全ボード共通なら `app.overlay`）を置くと、ビルド時に自動で合成されます。たとえばI2C1に温度センサーを追加する場合はこう書きます。 ``` /* boards/nucleo_f446re.overlay */ &i2c1 { status = "okay"; /* Nucleo-F446REの板定義では既にokayだが、SoC定義でdisabledのボードでは必須 */ clock-frequency = ; /* 400kHz */ temp_sensor: lm75@48 { /* I2Cアドレス0x48のセンサーを登録 */ compatible = "lm75"; reg = <0x48>; }; }; ``` ここで重要なのが2点。 - **`status = "okay"` の概念：**SoC定義には全ペリフェラルが書かれていますが、大半は `disabled` 状態です。使うものだけをボード定義かオーバーレイで `okay` にします。「CubeMXでペリフェラルにチェックを入れる」操作のテキスト版だと思えば良いです - **`compatible` がドライバとの結び付け：**`compatible = "lm75"` と書くと、Zephyrに同梱されたLM75ドライバがこのノードに紐付き、アプリからは `sensor_sample_fetch()` 等の統一センサーAPIで読めます。**デバイスドライバを自分で書かずに済む**のがZephyrの生産性の源泉です ** 実行時オーバーヘッドはゼロ 「Linuxのデバイスツリー＝起動時にパースする」イメージがありますが、Zephyrのデバイスツリーは**ビルド時にCマクロへ完全展開**されます（`build/zephyr/zephyr.dts` と `devicetree_generated.h` に成果物が出ます）。実行時のパース処理もRAM消費もありません。デバイスツリー起因のビルドエラーを調べるときは、まず合成結果の `build/zephyr/zephyr.dts` を見るのが定石です。 ## Kconfig（prj.conf）の基本 デバイスツリーが「ハードに何があるか」なら、Kconfigは「ソフトの機能を何を組み込むか」です。アプリ直下の `prj.conf` に `CONFIG_*` を列挙します。 ``` # prj.conf の例 CONFIG_GPIO=y # GPIOドライバ CONFIG_I2C=y # I2Cドライバ CONFIG_SENSOR=y # センサーサブシステム（lm75等のドライバ含む） CONFIG_LOG=y # ロギングサブシステム CONFIG_SHELL=y # UARTコンソールで対話シェルが使える CONFIG_MAIN_STACK_SIZE=2048 ``` 使わない機能はリンクすらされないため、フットプリントを絞れます。設定項目は膨大ですが、`west build -t menuconfig` でLinuxカーネルと同じ対話UIから検索・変更できます（確定したら `prj.conf` に書き戻すのが流儀です）。 FreeRTOS経験者向けに対応づけると、`FreeRTOSConfig.h`（`configTOTAL_HEAP_SIZE` 等）＋「CubeMXのMiddlewareチェックボックス」を合わせたものが `prj.conf` です。ここで最頻出のハマりが「**デバイスツリーで有効化したのにKconfigを忘れる**」パターン。I2Cノードを `okay` にしても `CONFIG_I2C=y` が無ければドライバが組み込まれず、`device_is_ready()` が偽を返します。**デバイスツリーとKconfigは両輪**、と覚えてください。 ## FreeRTOSとの比較表と使い分け基準 | 観点 | FreeRTOS | Zephyr | | 提供範囲 | カーネルのみ（ドライバはHAL、通信は別ライブラリ） | カーネル＋ドライバ＋BLE/ネットワーク/FS/シェルまで一体 | | 学習コスト | 低い。CubeMXで即開始、APIも少ない | カーネルAPIは平易だが、west・デバイスツリー・Kconfigの習得が必要 | | 開発フロー | STM32CubeMX/CubeIDE中心（GUI） | CLI中心（west build/flash）。VS Code＋各種拡張が主流 | | ライセンス | MIT（2017年よりAWSが開発主導） | Apache-2.0（Linux Foundation傘下の中立運営） | | 移植性・マルチベンダー | 移植レイヤは薄いが、ドライバ層は各ベンダーHAL依存 | 1000超のボードでアプリコードがほぼ無修正で動く | | 長期保守 | FreeRTOS LTS（AWS提供、更新2年。有償の延長保守EMPで最長+10年）＋ST同梱版 | LTS（現行v3.7）＋安定版を定期リリース（最新v4.4.0） | | CRA・セキュリティ対応 | 脆弱性対応はAWS/各ライブラリ個別。SBOMは自前で整備 | CNA登録（2017年〜）、PSIRT運用、`west spdx` でSBOM自動生成 | | フットプリント | 非常に小さい（数KB〜）。小容量MCU向き | 最小構成は小さいが、実用構成ではFreeRTOS比で大きくなりがち | | テスト・CI | 仕組みは自前で構築 | Twister（テストランナー）・QEMU/シミュレータ実行が標準装備 | ### 使い分けの判断基準 弊社がRTOS選定の相談を受けたときに使っている判断軸です。 - **FreeRTOSが向くケース：**単機能の制御機器（モーター制御・計測など）／Flash 256KB未満の小容量MCU／CubeMX中心の既存開発フローを崩したくない／チームがFreeRTOS習熟済みで納期が短い／既存FreeRTOS資産の派生開発 - **Zephyrが向くケース：**BLE・ネットワーク・USB・OTAなどミドルウェアを複数使う製品／将来のMCUベンダー変更（供給リスク対策）を見込む／EU市場向けでCRA対応の脆弱性管理・SBOM提出が必要／複数製品でコードベースを共通化したい／CIでの自動テストを重視する 一言でまとめると、**「マイコンに毛が生えた装置」はFreeRTOS、「小さなコネクテッド製品」はZephyr**が第一候補です。 ## 既存FreeRTOS資産がある場合の移行判断 「今のFreeRTOS製品をZephyrに移すべきか」という相談も増えていますが、結論から言うと**動いている製品の載せ替え単体では割に合わないことが多い**です。理由は3つあります。 1. **カーネルAPIの置換は移行工数の2割程度：**前述の対応表のとおりAPI変換自体は機械的ですが、実際の工数の大半はHAL直叩きコードのZephyrドライバAPIへの置換、割り込み設計の見直し、デバイスツリー・Kconfigへの構成移植に費やされます。実質「作り直し」に近い見積もりが必要です 2. **優先度の向きの反転などの地雷：**優先度体系（数値の大小が逆、協調スレッドの存在）、ティック・タイムアウトの扱いなど、コンパイルは通るのに挙動が変わる差分が多く、リグレッションテストの整備が前提になります 3. **検証済みという資産価値：**量産で実績のあるFreeRTOSコードは、それ自体が検証コスト数人月分の資産です 移行に踏み切る合理性があるのは、次のような「どうせ大きく手を入れる」タイミングです。 - 製品の**ネットワーク化・無線化**など大規模な機能追加で、ミドルウェア寄せ集めの限界が見えたとき - MCUの**供給問題・EOLでベンダー/シリーズ変更**が必要になったとき（どうせドライバ層は書き直しになる） - **CRA対応**で脆弱性監視・SBOM・セキュリティ更新の長期体制をOSSコミュニティに相乗りする形で構築したいとき 現実的な進め方としては、既存製品はFreeRTOSのまま保守を続け、**新規プロジェクトや次世代機からZephyrを並行導入**してチームの経験値を貯める二本立てを推奨しています。 ## FreeRTOS経験者がハマる落とし穴 | 症状 | 原因 | 対策 | | 高優先のつもりのスレッドが後回しになる | 優先度の数値方向がFreeRTOSと逆（小さいほど高優先） | 移植時は優先度マッピング表を先に作る。負値（協調スレッド）は意図がある場合のみ使う | | `device_is_ready()` が偽 / ドライバが見つからない | デバイスツリーで `okay` にしたがKconfig（`CONFIG_I2C=y` 等）を忘れている（またはその逆） | デバイスツリーとprj.confは常にセットで確認。`build/zephyr/.config` で最終的な設定値を確認できる | | `__device_dts_ord_NN` undefined などの謎ビルドエラー | デバイスツリーのノードが無効・エイリアス未定義のままAPIで参照している | 合成結果 `build/zephyr/zephyr.dts` で該当ノードの `status` とエイリアスを確認する | | `west flash` が失敗する | STM32CubeProgrammer未インストール／PATH未設定 | CLI版を含めてインストール。`west flash --runner openocd` で代替ランナーも指定可能 | | ボードを変えたら動かない・設定が残る | ビルドディレクトリに前ボードのキャッシュが残留 | `west build -p always`（pristineビルド）を習慣にする | | printfデバッグの出力が出ない・重い | ログサブシステム未設定（Zephyrは `printk`/`LOG_INF` が流儀） | `CONFIG_LOG=y` を有効化し `LOG_INF()` 系へ。遅延処理（deferred）モードならISRからも安全に出せる | | スタック不足で暴走・MPUフォルト | FreeRTOS感覚の小さいスタック値（Zephyrはドライバ・ログ経由で消費が増えやすい） | `CONFIG_THREAD_ANALYZER=y` + `CONFIG_THREAD_ANALYZER_AUTO=y` で周期的にスレッド毎のスタック使用量を出力して調整（`CONFIG_SHELL=y` なら `kernel threads` コマンドでも確認可） | ** デバッグの定石 - **`west debug`：**OpenOCD経由でGDBが立ち上がる。VS Code + Cortex-Debug拡張との併用が快適 - **シェルを常設する：**`CONFIG_SHELL=y` にしておくと、UARTコンソールから `kernel threads`（スレッド一覧とスタック使用量）、`device list`（ドライバ初期化状態）が実機でそのまま叩けます。FreeRTOSのTask Listビューに相当する機能が最初から入っているイメージです - **QEMUで先に検証：**ロジック部分は `west build -b qemu_cortex_m3` → `west build -t run` で実機なしにテストできる。CI組み込みも容易 ## まとめ ### この記事のまとめ - Zephyrは「カーネル」ではなく「OSディストリビューション」。学習コストの本体はwest・デバイスツリー・Kconfigにある - 環境構築は venv → `pip install west` → `west init/update` → `west sdk install` の4ステップ。Nucleo-F446REなら `west build -b nucleo_f446re` で即ビルドできる - デバイスツリーは「ハード構成をCコードから追い出す」仕組み。ビルド時にマクロ展開されるので実行時コストはゼロ - 優先度は数値が小さいほど高優先（FreeRTOSと逆）。移植時最大の地雷 - 単機能・小容量・短納期はFreeRTOS、コネクテッド製品・マルチベンダー・CRA対応はZephyrが第一候補 - 既存FreeRTOS資産の載せ替え単体は非推奨。大規模改修・MCU変更・CRA対応のタイミングで判断する RTOSの選定は、製品のライフサイクル全体のコストを左右する意思決定です。FreeRTOS・Zephyrそれぞれの得意領域を踏まえた技術選定からお手伝いできますので、お気軽にご相談ください。 RTOS選定のセカンドオピニオン、Zephyr/FreeRTOSでの新規開発、既存機器の改修まで [組込み制御・マイコン開発](https://technosphere.co.jp/embedded) として対応しています。 ／この内容の受託開発・PoC相談はこちら＼ ### STM32 × RTOS（Zephyr / FreeRTOS）の受託開発 RTOS選定・アーキテクチャ設計から、ドライバ開発・量産デバッグ・長期保守体制の構築まで、STM32開発歴20年超のエンジニアが一貫対応します。新規開発のPoCも既存資産の改修もお任せください。 [組込み開発サービスを見る](https://technosphere.co.jp/embedded) [RTOS選定・開発相談](https://technosphere.co.jp/contact) ## よくある質問（FAQ） ** ZephyrはSTM32のどのボードで動きますか？ Nucleo・Discoveryを中心にSTM32のほぼ全シリーズ（F0/F1/F4/F7/G0/G4/H7/L4/U5/WB等）の評価ボードが公式サポートされています。本記事で使ったNucleo-F446REはボード名 `nucleo_f446re` として登録済みで、`west build -b nucleo_f446re` でそのままビルドできます。Zephyr全体では1000種類を超えるボードがサポートされています。 ** FreeRTOSとZephyrはどちらを選ぶべきですか？ 小規模・単機能・STM32CubeMX中心の開発や既存FreeRTOS資産の改修ならFreeRTOSが合理的です。BLE・ネットワークなど複数ミドルウェアを使う製品、複数MCUベンダーへの展開、CRA対応で長期の脆弱性管理が必要な製品ではZephyrの優位性が大きくなります。詳しくは本文の比較表をご覧ください。 ** デバイスツリーとは何ですか？なぜ必要なのですか？ 「どのペリフェラルがどのピン・アドレスにあるか」というハードウェア構成をCコードから分離して `.dts`/`.overlay` に記述する仕組みです。ビルド時にCマクロへ展開されるため実行時オーバーヘッドはなく、アプリは `led0` のような論理名だけを参照するのでボードを変えてもアプリ側の修正が不要になります。 ** 既存のFreeRTOS資産はZephyrに移行すべきですか？ 安定稼働している製品を移行だけのために書き換えるのはお勧めしません。カーネルAPI・ドライバ層・ビルドシステムがすべて異なり、実質作り直しに近い工数になります。大幅な機能追加・MCUベンダー変更・CRA対応など、書き直しに見合うリターンがあるタイミングで判断し、まずは新規プロジェクトでの並行採用から始めるのが現実的です。 ** ZephyrはEUサイバーレジリエンス法（CRA）に対応していますか？ Zephyrプロジェクトは2017年からCVE採番機関（CNA）として登録され、PSIRTによる脆弱性対応プロセスと脆弱性アラート登録制度を運用しています。`west spdx` コマンドでSBOMをSPDX形式で自動生成することもできます。ただしCRAの適合義務を負うのは製品の製造者であり、Zephyrを使えば自動的に適合するわけではありません。 # STM32 # Zephyr # RTOS # FreeRTOS # west # デバイスツリー # Kconfig # 組込み開発 ## 次に読む｜STM32 シリーズ記事 - [本記事の姉妹編 STM32 + FreeRTOS 入門｜タスク・キュー・セマフォを使ったRTOS実装ガイド FreeRTOS側の基本はこちら。両方読むと使い分けが立体的に理解できます](https://technosphere.co.jp/blog/stm32-freertos-intro) - [STM32 シリーズ STM32マイコンのUART・I2C・SPI・CAN通信 実装ガイド HALライブラリで通信ペリフェラルを使いこなす定番ガイド](https://technosphere.co.jp/blog/stm32-uart-i2c-can) - [STM32 シリーズ STM32 DMA 完全ガイド｜UART・SPI・ADCとの連携 CPU負荷を最小化するDMA活用の決定版](https://technosphere.co.jp/blog/stm32-dma-complete-guide) - [開発実績 組込み制御・マイコン開発 実績紹介 RTOS採用案件含む多数の受託開発事例](https://technosphere.co.jp/embedded-achievements) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # STM32N6とNeural-ART NPU｜マイコン単体で動くエッジAI実践ガイド｜株式会社テクノスフィア > ST初のNPU搭載マイコンSTM32N6を実務目線で解説。Neural-ART Accelerator（1GHz・最大600 GOPS・約3 TOPS/W）のアーキテクチャ、Jetson/ラズパイとの使い分け判断基準、評価ボードの選び方、ONNXモデルのデプロイ手順、4.2MB SRAMとフラッシュレス構成のメモリ制約、量産採用の判断ポイントまで。組込み開発歴20年超のエンジニアが在籍するテクノスフィアが解説。 URL: https://technosphere.co.jp/blog/stm32n6-neural-art-edge-ai ** 目次 1. はじめに：「マイコンでAI」の何が変わったのか 2. STM32N6とNeural-ART NPUのアーキテクチャ 3. Jetson・Raspberry Piとの使い分け判断基準 4. 開発に必要なもの：評価ボードとST Edge AI Suite 5. ONNX/TFLiteモデルのデプロイフロー 6. メモリ制約の現実：4.2MB SRAMとフラッシュレス構成 7. 量産採用の判断ポイント 8. よくある落とし穴と対策 9. まとめ ## はじめに：「マイコンでAI」の何が変わったのか これまでSTM32でAI推論といえば、[STM32Cube.AIで学習済みモデルをCコードに変換し、CPUで実行するTinyML](https://technosphere.co.jp/blog/stm32-cube-ai-tinyml)が定番でした。この方式は消費電力とコストの面では優秀ですが、実行主体はあくまでCortex-MコアのCPUです。数十〜数百KBの小さなモデルなら実用になる一方、カメラ画像に対する物体検出のようなワークロードでは推論に数百ミリ秒〜数秒かかり、「リアルタイムの画像AIはJetsonかラズパイ＋アクセラレータで」というのが実務上の相場でした。 この前提を変えたのが、STマイクロエレクトロニクスが投入した**STM32N6シリーズ**です。STM32として初めてNPU（Neural Processing Unit）である**Neural-ART Accelerator**を内蔵し、**マイコン単体で最大600 GOPS**のニューラルネットワーク推論を実行できます。CPU推論の従来型TinyMLと、Linuxボードによるエッジ推論のあいだにあった性能の空白地帯を、1チップのMCUで埋める存在です。 本記事では、カタログスペックの紹介にとどまらず、「N6で何ができて何ができないのか」「Jetson/ラズパイとどう使い分けるか」「ONNXモデルをどうやって実機に載せるか」「量産採用で何を確認すべきか」を、受託開発の実務目線で整理します。 ** 弊社での取り組み 弊社はSTM32ファミリでの[メンバーの20年超にわたる組込み開発実績](https://technosphere.co.jp/embedded-achievements)に加え、エッジAIプラットフォーム「GENBA IQ」でカメラ×AIの現場実装を手がけています。本記事はST公式ドキュメント・公開リポジトリの一次情報と、STM32/エッジAI双方の開発経験に基づいて構成しています。 ## STM32N6とNeural-ART NPUのアーキテクチャ まず主要スペックを整理します。数値はいずれもST公式の製品ページ・製品プレゼンテーションに基づきます。 | 項目 | 内容 | | CPUコア | Arm Cortex-M55 @ **800MHz**（Heliumベクトル拡張搭載） | | NPU | ST Neural-ART Accelerator @ **1GHz**、最大**600 GOPS**、電力効率 約**3 TOPS/W** | | NPU内部構成 | 約300個の構成可能なMAC（積和演算）ユニット＋64ビットAXIバス×2本 | | 内蔵RAM | **4.2MB**の連続SRAM（複数バンク構成）＋8KBバックアップSRAM | | 内蔵フラッシュ | **非搭載（フラッシュレス）**。外部シリアルフラッシュ（XSPI: Octo-SPI/Hexadeca-SPI等）から起動 | | ビジョン系 | MIPI CSI-2カメラインターフェース＋ISP（画像信号処理）内蔵 | | マルチメディア | H.264ハードウェアエンコーダ、NeoChrom GPU（2.5Dグラフィックス）、JPEGコーデック | | 代表型番 | STM32N657X0（HW暗号あり）、STM32N647x0 など | ### アーキテクチャ上のポイント3つ **(1) NPUはCPUから独立した推論エンジン。**Neural-ARTは約300個のMACユニットを持つ専用ハードウェアで、コンパイル時にモデルをNPU用マイクロコードに変換して実行します。CPU（Cortex-M55）は推論中も空くため、前処理・後処理・通信・制御を並行できます。RTOSタスクとして推論と制御を同居させる設計は、[STM32 + FreeRTOS入門](https://technosphere.co.jp/blog/stm32-freertos-intro)で解説したタスク設計の延長線上で考えられます。 **(2) NPU非対応の層はCortex-M55にフォールバック。**ST Edge AI Coreのコンパイラは、モデルの各レイヤをNPU実行とCPU実行に自動で振り分けます。Cortex-M55はHelium（MVE）ベクトル拡張を持つため、フォールバック時もCortex-M4/M7比では高速ですが、CPUフォールバックが多いモデルはNPUの意味が薄れます。NPUの対応オペレータ一覧はST Edge AI Coreの公式ドキュメントに公開されているので、**モデル設計の段階で対応表と突き合わせる**のが実務の鉄則です。 **(3) カメラパイプラインが1チップで完結。**MIPI CSI-2＋ISP＋NPU＋H.264エンコーダを内蔵するため、「カメラ入力→AI推論→結果のみ送信（または録画）」という典型的なスマートカメラ構成が外付けプロセッサなしで成立します。従来この構成には一般にLinux SoCクラスのプロセッサが必要でした。 ** 600 GOPSの読み方 600 GOPS = 0.6 TOPSです。Jetson Orin Nano（最大67 TOPS）の約1/100であり、「Jetsonの代わり」ではありません。一方、電力効率は約3 TOPS/Wと高く、**ワット級の電源枠でCNN推論を実用速度で回せる**ことがN6の本質的な価値です。この規模感を正しく掴むことが、次章の使い分け判断につながります。 ## Jetson・Raspberry Piとの使い分け判断基準 エッジAIの実装先を相談される際、弊社では「演算量」「電力・熱」「起動時間と制御性」「コストと運用」の4軸で判断しています。代表的なプラットフォームと比較します。 | | STM32N6 | Raspberry Pi 5 + AI Kit (Hailo-8L) | Jetson Orin Nano Super | | AI演算性能 | 0.6 TOPS（600 GOPS） | 13 TOPS | 最大67 TOPS | | OS | ベアメタル / RTOS | Linux | Linux (JetPack) | | 消費電力の目安 | MCUクラス（NPU効率 約3 TOPS/W） | 数W〜10W級 | 7〜25Wの電力モード | | 冷却 | ファンレス前提 | ヒートシンク/ファン推奨 | ファン付き | | 起動時間 | ミリ秒〜秒オーダー | 数十秒（Linuxブート） | 数十秒（Linuxブート） | | 開発キット価格帯 | 約76〜224ドル（Nucleo/DK） | Pi 5＋AI Kit 約130〜180ドル | 開発キット249ドル | | 量産形態 | 自社基板にMCU実装 | CM5等のモジュール実装 | Jetsonモジュール実装 | ### STM32N6が向くケース - **単機能のビジョンAI：**1カメラでの人検知・物体検出・分類・姿勢推定・異常検知など、int8量子化したCNN 1〜2本で完結するタスク - **電池・PoE・限られた電源枠：**ファンレス密閉筐体、ソーラー＋バッテリー運用、常時給電が難しい屋外設置 - **リアルタイム制御との同居：**モーター制御や安全系のマイクロ秒応答とAI判定を1チップで両立したい装置組込み（LinuxのソフトリアルタイムではNGな案件） - **瞬時起動・高信頼：**電源断→復帰が頻繁な環境。ファイルシステム破損リスクのあるLinuxブートを避けたい場合 - **BOMコストと部品点数の圧縮：**SoC＋DRAM＋eMMC＋PMICの構成をMCU＋外部フラッシュ1個に集約したい量産品 ### STM32N6では無理をしないほうがよいケース - **LLM・VLM（視覚言語モデル）：**数百MB〜GB級のモデルはメモリ的に対象外。VLM級の推論は[Raspberry Piで動かすvLM完全ガイド](https://technosphere.co.jp/blog/raspberry-pi-vlm-edge-ai)で扱ったようなLinuxボード以上が前提 - **複数カメラの同時解析・高解像度リアルタイム処理：**演算量が0.6 TOPSを恒常的に超える構成 - **モデルを頻繁に差し替える運用：**コンテナやPythonランタイムでモデルを入れ替えるスタイルの開発・運用にはLinux機が向く（N6は再コンパイル＋ファーム更新が基本） - **学習・ファインチューニングをデバイス上で行う用途** ** 実務での判断手順 迷ったら「①目標モデルをint8量子化して演算量（MACs）とメモリを見積もる → ②ST Edge AI Developer Cloudで実機ベンチマーク → ③目標フレームレートに届けばN6、届かなければ上位機」の順で1〜2日あれば見極められます。先にハードを決めてからモデルを削る進め方は手戻りが大きく、お勧めしません。 ## 開発に必要なもの：評価ボードとST Edge AI Suite ### 評価ボードは2種類 | 型番 | 実売価格の目安 | 特徴 | | **STM32N6570-DK** （Discoveryキット） | 約224ドル （米DigiKey実売） | STM32N657X0H3Q搭載。**MIPI CSI-2カメラモジュール（Sony IMX335搭載のMB1854）と5インチ800×480 LCDが付属**。Octo-SPI NORフラッシュ（Macronix MX66UW1G45G）、Hexadeca-SPI PSRAM、Ethernet、USB Type-C、microSD、オーディオコーデック搭載。ビジョンAIの評価はこれ一択 | | **NUCLEO-N657X0-Q** | 約76ドル （米DigiKey実売） | Nucleo-144フォームファクタ。カメラ・LCDなし。外部フラッシュはMX25UM51245G。センサー系AIや自社基板設計前のペリフェラル検証、コストを抑えた複数人開発に | カメラAIの評価が目的なら、カメラ・LCD・サンプルアプリがそのまま動く**STM32N6570-DKから始めるのが最短**です。ST公式のGitHubに画像分類・物体検出・姿勢推定などのGetting Startedリポジトリ（STM32N6-GettingStarted-ImageClassificationなど）が公開されており、ビルド済みバイナリを書き込めば当日中にデモが動きます。 ### ソフトウェア側：ST Edge AI Suiteの構成 N6のAI開発ツール群は「ST Edge AI Suite」という傘の下に整理されています。実務で触るのは主に次の4つです。 - **ST Edge AI Core（stedgeai CLI）：**無償のコマンドラインツール。TensorFlow Lite / ONNX / Kerasのモデルを評価・最適化し、Neural-ART用マイクロコードとCコードに変換する中核。本記事執筆時点の対応バージョンはv4系（後述のGetting StartedはSTEdgeAI v4.0.0を要求） - **GUIツール（STM32N6-AI / STM32Cube AI Studio）：**CubeMX連携のN6用AIパッケージがSTM32N6-AI、従来のX-CUBE-AIの後継となるデスクトップGUIがSTM32Cube AI Studio（STEDGEAI-CUBEAI）。いずれも中身はST Edge AI Coreベースで、GUI派はこちら - **ST Edge AI Developer Cloud：**ブラウザからモデルをアップロードし、**リモートの実機ボードでレイテンシとメモリをベンチマーク**できる無償サービス。ボード購入前の見積もりに有効 - **STM32モデルZoo（GitHub: STMicroelectronics/stm32ai-modelzoo）：**量子化済みの学習済みモデル＋学習/評価スクリプト集。まず自分のタスクに近いモデルをここから選ぶのが定石 このほか、ビルドと書き込みに**STM32CubeIDE**と**STM32CubeProgrammer**（Getting Startedの要求はそれぞれv1.17.0 / v2.18.0以降）を使います。 ## ONNX/TFLiteモデルのデプロイフロー N6へのモデル搭載は「①int8量子化 → ②stedgeaiでNPU用にコンパイル → ③アプリに組み込みビルド → ④署名して外部フラッシュへ書き込み」の4段階です。順に見ていきます。 ### Step 1：int8量子化（必須） Neural-ARTで実行するモデルは、**重み・アクティベーションともにint8（scale/offset形式、per-channel）で量子化されていることが前提**です。float32のONNXをそのまま渡してもNPUには載りません。ONNXの場合はQDQ形式の量子化モデルを用意します。 ``` # ONNXモデルを int8 (QDQ) に静的量子化する例（onnxruntime） from onnxruntime.quantization import quantize_static, QuantType quantize_static( "model_fp32.onnx", "model_int8.onnx", calibration_data_reader=reader, # 実運用に近い画像数百枚で校正 activation_type=QuantType.QInt8, weight_type=QuantType.QInt8, per_channel=True, # Neural-ARTはper-channel int8が前提 ) ``` 量子化の校正データは学習データからのランダム抽出ではなく、**実運用環境で撮影した画像**を混ぜるのが精度劣化を抑えるコツです。TensorFlow系ならTFLiteのfull-integer quantizationで同様にint8化します。量子化とメモリ最適化の考え方自体は[STM32Cube.AIでTinyMLを量産品質にする記事](https://technosphere.co.jp/blog/stm32-cube-ai-tinyml)で解説した内容がそのまま土台になります。 ### Step 2：stedgeaiでNeural-ART向けにコンパイル ``` # TFLite(int8)モデルをNeural-ARTターゲットでコンパイル（公式ドキュメントの例） stedgeai generate -m mobilenet_v2_0.35_224_fft_int8.tflite \ --target stm32n6 --st-neural-art # ONNX(QDQ int8)でも同様 stedgeai generate -m model_int8.onnx --target stm32n6 --st-neural-art ``` `--st-neural-art`を付けるとNPU用のコンパイルが走り、NPUで実行できる層はマイクロコードに、非対応の層はCortex-M55用コードに振り分けられます。コンパイル時の最適化方針やメモリ割り当ては、**コンパイルプロファイル（neural_art.json）とメモリプール記述ファイル（stm32n6.mpool）**で制御します。リンカスクリプトでセクション配置を決めるのと同じ感覚で、「重みをどのメモリに」「アクティベーションをどのRAMに」置くかをここで設計します。 生成されたレポートには、各レイヤのNPU/CPU割り当て・メモリ使用量・推定サイクルが出力されます。**ここでCPUフォールバックが多発していたら、モデル側のオペレータを見直すサイン**です。 ### Step 3〜4：ビルド・署名・外部フラッシュへの書き込み N6はフラッシュレスのため、書き込み対象は外部フラッシュです。ブートROM→FSBLと続く署名付きブートチェーンが各段のヘッダを検証するため、アプリケーションバイナリにも署名ツールでヘッダを付与します。ST公式Getting Started（画像分類）の手順は次の通りです。 ``` # 1. ビルド済みバイナリに署名（ブートチェーンが検証するヘッダを付与） # ※パスはプロジェクト構成に合わせて読み替え（公式READMEでは build/Application// 配下） STM32_SigningTool_CLI -bin build/Project.bin -nk -t ssbl -hv 2.3 \ -o build/Project_sign.bin # 2. 外部フラッシュ用ローダを指定して書き込み（STM32N6570-DKの例） export DKEL="/ExternalLoader/MX66UW1G45G_STM32N6570-DK.stldr" # FSBL（第一段ブートローダ） STM32_Programmer_CLI -c port=SWD mode=HOTPLUG -el $DKEL -hardRst -w FSBL/ai_fsbl.hex # ネットワーク重みデータ STM32_Programmer_CLI -c port=SWD mode=HOTPLUG -el $DKEL -hardRst -w Model/network_data.hex # 署名済みアプリケーション（外部フラッシュ 0x70100000 へ） STM32_Programmer_CLI -c port=SWD mode=HOTPLUG -el $DKEL -hardRst -w build/Project_sign.bin 0x70100000 ``` 開発中はボード上のブートスイッチを**デベロップメントモード**（RAMに直接ロードしてデバッグ）に、確認後は**Boot from Flash**に切り替えて電源再投入で起動します。従来のSTM32のように「内蔵フラッシュにELFを焼いて終わり」ではなく、**FSBL・重み・アプリの3点を外部フラッシュの決められたアドレスに配置する**という、MPU（STM32MP1等）に近いブートフローになる点が最初の関門です。 ## メモリ制約の現実：4.2MB SRAMとフラッシュレス構成 N6採用可否の8割はメモリ設計で決まります。押さえるべき構造は次の通りです。 ### メモリ階層と配置の優先順位 Neural-ARTのコンパイラは、推論中の中間バッファ（アクティベーション）を次の優先順位で割り当てます。 1. **NPU専用RAM（NPURAM/AXISRAM3〜6）：**NPUアクセスに最適化された最速の領域。コンパイラはまずここを使う 2. **汎用AXISRAM（AXISRAM1〜2）：**NPU RAMが埋まった場合の次候補。アプリケーションと取り合いになる 3. **外部メモリ（PSRAM/フラッシュ）：**最終手段。ここに落ちた時点で性能は大きく低下する 重み（読み出し専用）は外部Octo-SPIフラッシュに置くのが標準構成ですが、**外部メモリへのアクセス頻度が推論時間を支配する**ため、頻繁に読むデータをどこまで内蔵SRAMに載せられるかが性能チューニングの本丸です。この配置は前述のmpoolファイルで明示的に制御できます。 ### 実務上のサイズ感 - 内蔵SRAMは合計**4.2MB**。ただしカメラフレームバッファ、表示バッファ、アプリのヒープ/スタックもここに同居するため、**アクティベーションに使える量は構成次第で大きく目減り**します。800×480のRGB565ダブルバッファだけで約1.5MBを消費する計算です - int8量子化後で**数MB級までのCNN**（MobileNet系、YOLO系の小型構成など）が現実的な守備範囲。STM32モデルZooに量子化済みの参照モデルが揃っているので、まず近いモデルの実測値から逆算するのが早道です - それを超えるモデルは、入力解像度の削減・チャネル削減・蒸留でN6に収めるか、素直に上位プラットフォームへ。**「量子化すれば何でも載る」わけではない**点は顧客説明でも強調すべきポイントです ### フラッシュレスであることの設計影響 STM32N6の内蔵不揮発メモリはOTP（ワンタイムプログラマブル）領域のみで、ユーザーフラッシュはありません。したがって自社基板では、 - XSPI接続の外部NORフラッシュ（DKはMacronix MX66UW1G45G＝1Gbit品を採用）を必ずBOMに載せる - ブートROM→FSBL→アプリという署名付きブートチェーンを製造工程に組み込む（署名鍵の管理体制を含む） - 必要に応じてHexadeca-SPI PSRAMを追加し、フレームバッファや大きなアクティベーションを逃がす という設計判断が必要です。従来のSTM32Fシリーズ的な感覚で基板を起こすと確実に手戻りするため、**メモリ構成は最初のブロック図の段階で確定させる**ことをお勧めします。 ## 量産採用の判断ポイント 評価ボードでデモが動くことと、量産製品として成立することの間には距離があります。弊社が受託案件でチェックしている観点を挙げます。 1. **精度の量産条件での検証：**int8量子化後のモデルを、実運用の照明・画角・季節変動を含むデータで再評価する。評価はPC上のシミュレーションだけでなく、stedgeaiのvalidate機能や実機で行う 2. **性能マージン：**目標フレームレートに対して実測で余裕があるか。CPUフォールバック層が将来のモデル更新で増える可能性も見込む 3. **熱設計：**ファンレスが成立するかは筐体条件次第。NPU効率が高いとはいえ、800MHz CPU＋1GHz NPU＋カメラISPをフル稼働させる構成では実測での熱評価が必須 4. **セキュアブートと鍵運用：**署名付きブートは量産では「やるかどうか」ではなく「どう運用するか」の問題。OTPへの鍵情報書き込みは文字通り一度きりのため、製造フローの設計を先に固める 5. **モデル更新の運用設計：**N6ではモデル更新＝外部フラッシュのファーム更新。OTA更新の仕組み（二面化、失敗時のロールバック）を初期設計に含める 6. **部品供給と単価：**MCU単価は数量・パッケージ・セキュリティ機能の有無（N657/N647等）で変わるため、代理店見積もりを早期に取る。外部フラッシュ・PSRAMも含めたセットでBOMを比較する 7. **ツールチェーンのバージョン固定：**ST Edge AI Coreは活発に更新されており、バージョン間でコンパイル結果（性能・メモリ配置）が変わり得る。量産開発ではツールバージョンをプロジェクトで固定し、更新時は回帰確認する ## よくある落とし穴と対策 | 症状・つまずき | 原因 | 対策 | | float32のONNXを渡してもNPUで動かない | Neural-ARTはint8量子化済みモデルが前提 | QDQ形式のint8 ONNX、またはfull-integer量子化のTFLiteを用意してからstedgeaiに渡す | | NPU搭載のはずが推論が想定より遅い | 非対応オペレータのCPUフォールバック多発、またはアクティベーションが外部メモリに溢れている | stedgeaiの生成レポートでレイヤ割り当てとメモリ配置を確認。対応オペレータ表に合わせてモデルを再設計 | | 書き込んだのに起動しない | 署名なしバイナリ、アドレス誤り、ブートスイッチがデベロップメントモードのまま | STM32_SigningTool_CLIでの署名、FSBL/重み/アプリの書き込みアドレス、スイッチ設定を順に確認 | | 外部フラッシュに書き込めない | 外部ローダ（.stldr）未指定 | STM32_Programmer_CLIに`-el`でボード対応の外部ローダ（DKならMX66UW1G45G_STM32N6570-DK.stldr）を指定 | | 量子化後に精度が数％以上落ちる | 校正データが実運用分布とずれている | 現地環境で収集した画像を校正データに追加。per-channel量子化を使用。層単位で精度影響を切り分け | | SRAMが足りずビルド構成が破綻 | フレームバッファ・アプリ領域・アクティベーションの取り合いを設計していない | mpoolファイルでメモリプールを明示設計。解像度・バッファ数の見直し。必要なら外部PSRAM追加 | ** デバッグの定石 - **まずST Edge AI Developer Cloudで実機ベンチマーク：**手元にボードがなくても、レイテンシ・メモリ・レイヤ割り当てが確認できる - **stedgeaiのレポートを読む習慣：**NPU/CPU割り当てとメモリ配置はすべてレポートに出る。感覚ではなくレポートで議論する - **モデルZooの参照モデルと比較：**自作モデルが極端に遅い場合、同規模の公式モデルの実測値と比べると原因の当たりが付く ## まとめ ### この記事のまとめ - STM32N6はST初のNPU搭載MCU。Cortex-M55 800MHz＋Neural-ART（1GHz・最大600 GOPS・約3 TOPS/W）で、マイコン単体の画像AIが実用域に入った - 0.6 TOPSはJetsonの代替ではなく、「ファンレス・低電力・瞬時起動・制御との同居」が効く単機能ビジョンAIの守備範囲 - 開発はSTM32N6570-DK（約224ドル、カメラ・LCD付属）＋無償のST Edge AI Core（stedgeai CLI）＋STM32モデルZooで始めるのが最短 - モデルはint8量子化（per-channel）が前提。`stedgeai generate --target stm32n6 --st-neural-art`でNPU用にコンパイルし、非対応層はM55にフォールバック - 内蔵SRAM 4.2MB・フラッシュレス構成が最大の制約。メモリ配置（NPU RAM→AXISRAM→外部メモリ）と署名付きブートフローを初期設計で確定させる - 量産判断では、量子化後精度の実環境検証・熱・鍵運用・OTA・ツールバージョン固定までを含めて評価する STM32N6は「マイコンの開発文化のまま画像AIを製品に入れられる」初めての選択肢です。一方で、フラッシュレスのブート設計や量子化前提のモデル設計など、従来のSTM32ともLinuxエッジAIとも違う勘所があります。PoCの段階から量産を見据えた設計でお困りの際は、お気軽にご相談ください。 STM32N6での試作評価、既存STM32製品へのAI機能追加、JetsonやRaspberry Piからの置き換え検討まで、[組込み制御・マイコン開発](https://technosphere.co.jp/embedded)および[AIソリューション開発](https://technosphere.co.jp/ai-solution)として対応しています。 ／エッジAI開発のご相談はこちら＼ ### STM32N6・エッジAIの受託開発／PoC支援 モデル選定・量子化・N6実装からJetson/ラズパイとのプラットフォーム比較検証、量産設計まで一貫対応。カメラ×AIの現場実装は、弊社エッジAIプラットフォーム「GENBA IQ」の知見でサポートします。 [GENBA IQを見る](https://technosphere.co.jp/genba-iq) [エッジAI開発の相談](https://technosphere.co.jp/contact) ## よくある質問（FAQ） ** STM32N6のNeural-ART NPUはどの程度の性能ですか？ Neural-ART Acceleratorは1GHz動作で最大600 GOPS、電力効率は約3 TOPS/WというST内製のNPUです。約300個の構成可能なMACユニットと2本の64ビットAXIバスを持ち、CPU（Cortex-M55 800MHz）だけで推論する従来のSTM32と比べて大幅に高速です。画像分類・物体検出・姿勢推定などのint8量子化済みCNNモデルがマイコン単体で実用速度で動作します。 ** JetsonやRaspberry PiではなくSTM32N6を選ぶべきなのはどんなケースですか？ 必要なAI処理が0.6 TOPS以内に収まり、ファンレス・低消費電力・低コスト・起動の速さ・リアルタイム制御との同居が求められるケースです。逆にLLM/VLMの実行、複数カメラの同時解析、頻繁なモデル差し替えが必要な場合は、Jetson Orin Nano（最大67 TOPS）やRaspberry Pi + AIアクセラレータ（Hailo-8Lで13 TOPS）などLinuxベースのプラットフォームが適します。 ** 学習済みのONNXモデルはそのまま動きますか？ そのままでは動きません。重みとアクティベーションをint8（scale/offset形式、per-channel）に量子化したモデルが前提です。量子化済みのONNX（QDQ形式）またはTFLiteモデルを `stedgeai generate -m model.tflite --target stm32n6 --st-neural-art` のようにコンパイルして組み込みます。NPU非対応のオペレータは自動的にCortex-M55側にフォールバックされます。 ** STM32N6に内蔵フラッシュはありますか？ ありません。STM32N6はフラッシュレス構成で、4.2MBの内蔵SRAMと外部シリアルフラッシュ（XSPI接続）を組み合わせて使います。電源投入後はブートROMが外部フラッシュから署名検証済みのFSBLを内蔵RAMにロードして起動します。量産設計では外部フラッシュの選定・署名フローを最初から織り込む必要があります。 ** 開発を始めるには何が必要ですか？ 評価ボードはカメラ・LCD付きのSTM32N6570-DK（実売220ドル台）か、安価なNUCLEO-N657X0-Q（実売80ドル弱）。ソフトウェアは無償のST Edge AI Core（stedgeai CLI）、STM32CubeIDE、STM32CubeProgrammerが基本セットで、STM32モデルZoo（GitHub）に学習済みモデルとサンプルアプリが公開されています。ブラウザから実機ベンチマークできるST Edge AI Developer Cloudも利用できます。 ** 動かせるモデルサイズの目安は？ アクティベーションは内蔵4.2MB SRAM内に収めるのが性能上の前提で、重みは外部フラッシュに置けますが、外部メモリアクセスが増えるほど推論は遅くなります。int8量子化後で数MB級までのCNNが現実的な目安です。それを超えるモデルは、アーキテクチャの見直しか上位プラットフォームの検討をお勧めします。 # STM32N6 # Neural-ART # NPU # エッジAI # Cortex-M55 # ST Edge AI # TinyML # マイコン開発 ## 次に読む｜エッジAI・STM32関連記事 - [STM32 シリーズ STM32Cube.AI で TinyML を量産品質に｜メモリ配置最適化の決め技 NPU以前の定番・CPU推論TinyMLの量産ノウハウ](https://technosphere.co.jp/blog/stm32-cube-ai-tinyml) - [エッジAI Raspberry Piで動かすvLM完全ガイド N6では届かないVLM級のエッジAIをLinuxボードで実現](https://technosphere.co.jp/blog/raspberry-pi-vlm-edge-ai) - [STM32 シリーズ STM32 + FreeRTOS 入門｜タスク・キュー・セマフォ 推論と制御を同居させるタスク設計の基礎](https://technosphere.co.jp/blog/stm32-freertos-intro) - [開発実績 組込み制御・マイコン開発 実績紹介 STM32案件を含む多数の受託開発事例](https://technosphere.co.jp/embedded-achievements) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # SUGUMEN導入事例｜小売業の大量採用で面接工数70%削減・採用リードタイム半減｜株式会社テクノスフィア > SUGUMEN導入で小売チェーンのアルバイト採用を変革した事例。面接工数70%削減、採用リードタイム半減を実現。 URL: https://technosphere.co.jp/blog/sugumen-case-study-retail 人手不足が深刻化する小売業界では、アルバイト・パートの大量採用が経営課題となっています。本記事では、AI面接システム「[SUGUMEN](https://technosphere.co.jp/sugumen)」を導入し、**面接工数70%削減・採用リードタイム半減**を実現した小売チェーンの事例をご紹介します。 ※本記事は、SUGUMENの導入効果をわかりやすくお伝えするための架空の事例です。企業名・数値は実際の導入実績をもとに構成しています。 ## 課題：年間3,000人採用の現場が抱えていた問題 全国に120店舗を展開する食品スーパー「**株式会社グリーンマート（仮名）**」では、年間約3,000人のアルバイト・パートスタッフの採用を行っています。しかし、採用プロセスには以下のような課題がありました。 - **面接官の不足**：各店舗の店長が面接を担当しており、繁忙期には面接の時間を確保できないケースが頻発していた - **日程調整に平均1週間**：応募者と店長の都合が合わず、面接日程の調整だけで平均7日かかっていた - **応募から採用決定まで10日以上**：日程調整の遅れにより、採用リードタイムが長期化し、他社に応募者を奪われるケースが多発 - **夜間・休日の応募に対応できない**：営業時間外の応募には翌営業日まで対応できず、応募者の離脱率が高かった - **面接品質のばらつき**：店長ごとに質問内容や評価基準が異なり、採用判断の一貫性に課題があった ## 導入背景：なぜSUGUMENを選んだのか グリーンマート様では、複数のAI面接サービスを比較検討された結果、以下の理由で[SUGUMEN](https://technosphere.co.jp/sugumen)を選定いただきました。 - **24時間365日対応**：応募者が好きなタイミングでAI面接を受けられるため、夜間・休日の取りこぼしを防げる - **即日稼働が可能**：複雑なシステム構築が不要で、最短即日で運用開始できる - **統一された評価基準**：AIが一貫した基準で応募者を評価するため、店舗間の採用品質のばらつきを解消できる - **既存の採用フローとの連携**：求人媒体からの応募データを自動取り込みでき、既存のワークフローを大きく変更する必要がない ポイント：** SUGUMENは「人がやるべき判断」と「AIに任せられる工程」を明確に分離する設計思想を持っています。最終的な採用判断は人間が行い、**スクリーニングと一次評価をAIが担当**することで、面接官の負担を大幅に軽減します。 ## 導入プロセス：3ステップで即日稼働 SUGUMENの導入は、以下の3ステップで完了しました。 1. **ステップ1：質問設計（約2時間）** グリーンマート様の採用基準をヒアリングし、職種ごとのAI面接質問セットを作成。接客経験・シフト希望・志望動機など、現場で重視するポイントを反映しました。 2. **ステップ2：システム設定・テスト（約1時間）** 応募者への案内メールテンプレート、評価スコアの閾値、結果通知の自動化設定を実施。人事担当者によるテスト面接で動作を確認しました。 3. **ステップ3：運用開始（即日）** 求人媒体の応募フォームにSUGUMENへの導線を追加し、運用を開始。初日から応募者のAI面接受験が開始されました。 ## 導入成果：数字で見る改善効果 SUGUMEN導入から3か月後、グリーンマート様では以下の成果が確認されました。 ** 定量的な成果 - 面接工数：**月間約500時間 → 約150時間（70%削減）** - 採用リードタイム：**平均10日 → 平均5日（50%短縮）** - 夜間・休日の面接対応率：**0% → 100%（24時間対応）** - 採用単価：**約15,000円 → 約10,500円（30%削減）** 特に大きな効果があったのは、**応募から面接実施までのリードタイム短縮**です。従来は日程調整だけで7日かかっていたものが、SUGUMENでは応募直後にAI面接を受けられるため、応募当日中に一次選考が完了するケースが大幅に増加しました。 また、夜間・休日に応募する層（学生・Wワーカーなど）の取りこぼしが解消され、**応募者プールが約1.4倍に拡大**しました。 ## ご担当者様の声 「以前は繁忙期になると店長が面接対応に追われ、本来の店舗運営に支障が出ることもありました。SUGUMEN導入後は、AIが一次スクリーニングを担ってくれるので、店長は本当に会いたい候補者だけに集中できるようになりました。採用のスピードが上がっただけでなく、採用の"質"も向上したと感じています。」 ― 株式会社グリーンマート（仮名） 人事部 採用担当マネージャー ## まとめ：SUGUMEN活用のポイント 本事例から見えてきた、SUGUMEN活用を成功させるポイントは以下の通りです。 ** この記事のまとめ - **AI面接は「代替」ではなく「補完」**：最終判断は人間が行い、スクリーニングをAIに任せることで、面接官の負担を大幅に軽減。 - **24時間対応で応募者の取りこぼしを防止**：夜間・休日の応募にも即座に対応し、他社への流出を防ぐ。 - **統一基準で採用品質を向上**：店舗・面接官による評価のばらつきを解消し、一貫した採用基準を実現。 - **導入ハードルの低さ**：複雑なシステム構築不要、3ステップで即日稼働が可能。 SUGUMENは、小売業に限らず、飲食・物流・介護など大量採用が必要な業界で幅広くご活用いただけます。採用プロセスの効率化にご興味のある方は、ぜひ[お気軽にご相談ください](https://technosphere.co.jp/contact)。貴社の採用課題をヒアリングしたうえで、最適な活用方法をご提案します。 [SUGUMENの詳細はこちら](https://technosphere.co.jp/sugumen) ／この内容の受託開発・PoC相談はこちら＼ ### 業務 AI 化・採用 DX の受託開発 SUGUMEN のような AI プロダクト導入支援に加えて、社内業務の AI 化・採用 DX・カスタム LLM 構築までテクノスフィアが一気通貫で対応します。要件ヒアリングから運用定着までお任せください。 [AI開発サービスを見る](https://technosphere.co.jp/ai-solution) [SUGUMEN を見る](https://technosphere.co.jp/sugumen) [採用DX・AI面接相談](https://technosphere.co.jp/contact) [# SUGUMEN](https://technosphere.co.jp/blog/) [# AI面接](https://technosphere.co.jp/blog/) [# 採用DX](https://technosphere.co.jp/blog/) [# 小売業](https://technosphere.co.jp/blog/) [# 人材採用](https://technosphere.co.jp/blog/) ** この記事をシェア [X](https://twitter.com/intent/tweet?url=https://technosphere.co.jp/blog/sugumen-case-study-retail&text=SUGUMEN導入事例｜小売業の大量採用で面接工数70%削減&via=technosphere_co) [Facebook](https://www.facebook.com/sharer/sharer.php?u=https://technosphere.co.jp/blog/sugumen-case-study-retail) [LINE](https://social-plugins.line.me/lineit/share?url=https://technosphere.co.jp/blog/sugumen-case-study-retail) --- # SH（SuperH）マイコン移行ガイド｜SH-2/SH-4のEOL対策とRXへのリプレース・再生｜株式会社テクノスフィア > ルネサス SH（SuperH）系マイコン SH-1/2/2A/3/4 の EOL/NRND 対策を解説。コード紛失・SHC・ビッグエンディアン・SCIF/MTU2 など移行の壁と、RX 等への移植実績ノウハウを公開。 URL: https://technosphere.co.jp/blog/superh-sh-migration-guide ** 目次 1. はじめに：なぜ今SuperHの移行か 2. SuperHファミリと採用領域 3. 移行が必要になる背景（EOL/NRND） 4. SuperH移行の4つの壁 5. 移行先の選定（RX / RH850 / STM32） 6. 移行プロジェクトの進め方 7. まとめ ## はじめに：なぜ今SuperHの移行か **SuperH（SH）**は、日立製作所が開発し、後にルネサス エレクトロニクスへ引き継がれたRISCマイコンファミリです。SH-2は自動車エンジンECU、SH-4はゲーム機やマルチメディア機器に採用されるなど、1990〜2000年代の組込み機器を支えました。しかし現在、多くの品種が**生産終了（EOL）または非推奨（NRND）**となり、長期供給に依存する産業機器・FA設備で「動いているうちに移行したい」という相談が急増しています。 本記事は、SuperHベースの製品を現行マイコンへ移行・再生するための**判断材料と進め方**を、レガシー再構築の実務目線でまとめたものです。「ソースコードが見つからない」「当時の開発環境が動かない」といった状況でも取り得る選択肢を解説します。 ** テクノスフィアのレガシー再生実績 テクノスフィアは、ソース・回路図が失われた組込み機器の [逆アセンブル・再構築](https://technosphere.co.jp/blog/renesas-rl78-reverse-engineering) を手がけています。SuperHを含む旧世代マイコンから現行品への移行も [受託開発](https://technosphere.co.jp/embedded-achievements) で対応しています。 ## SuperHファミリと採用領域 | 世代 | 特徴 | 主な採用領域 | | **SH-1 / SH-2** | 16bit固定長命令の32bit RISC。FPU非搭載（FPU搭載派生はSH-2E／SH-2A） | エンジンECU・産業制御・計測機器 | | **SH-2A** | 高速化・FPU・スーパースカラ | モーター制御・高速制御 | | **SH-3** | MMU搭載、組込みLinux等のOS対応 | PDA・産業端末 | | **SH-4** | 高性能・FPU・グラフィック | マルチメディア・ゲーム機・車載情報機器 | 特にSH-2系は日本の産業機器・計測機器に深く根付いており、20年以上稼働し続けている設備も珍しくありません。それらが今、部品供給の問題に直面しています。 ## 移行が必要になる背景（EOL/NRND） - **デバイスの生産終了**：SuperHの多くがEOL/NRND。在庫枯渇・価格高騰・偽物混入のリスク - **開発環境の老朽化**：SHC（ルネサス純正コンパイラ）や旧IDE（HEW）が最新OSで動かない - **属人化・退職**：当時の開発者が退職し、仕様やノウハウが失われている - **機能追加要求**：通信規格対応・セキュリティ強化など、旧機ではコスト的に難しい改修要求 これらが重なり、「設備が止まる前に、現行マイコンで作り直したい」という保全・事業継続の観点での移行ニーズが生まれます。 ## SuperH移行の4つの壁 ** 移行を難しくする要因 1. **ソース・資料の欠落**：ソースコード、回路図、仕様書が揃わない 2. **ビッグエンディアン**：SHはビッグエンディアン中心。データ構造・通信・フラッシュ格納の解釈が現行リトルエンディアン機と異なる 3. **周辺の差異**：SCIF（FIFO付きシリアル）・MTU2・DMAC・割り込みコントローラ（INTC）など、現行マイコンと1対1対応しない周辺がある 4. **コンパイラ依存**：SHC固有の `#pragma`（割り込み宣言・セクション配置）、組込み関数、アセンブリが移植時に問題になる とりわけ「ソースが無く、ROMだけが残っている」ケースでは、逆アセンブルによる仕様復元が出発点になります。タイミングに依存する制御は、実機の挙動を計測しながら等価な動作を再現していきます。 ## 移行先の選定（RX / RH850 / STM32） | 移行先 | 相性 | ポイント | | **ルネサス RX** | ◎ 第一候補 | 同一ベンダーで周辺の対応が取りやすい（SCIF→SCI、MTU2→MTU）。e2 studioで環境継承。[RX入門はこちら](https://technosphere.co.jp/blog/renesas-rx-introduction) | | **ルネサス RL78** | ○ 小規模向け | SH-1/SH-2の小規模制御をコストダウンしたい場合。[RL78ガイド](https://technosphere.co.jp/blog/renesas-rl78-peripheral-guide) | | **ルネサス RH850** | ○ 車載向け | 車載制御の機能安全要求がある場合 | | **STM32（ARM）** | ○ 汎用・資産重視 | ARMエコシステム・サードパーティ資産・調達性を重視する場合。[STM32実装ガイド](https://technosphere.co.jp/blog/stm32-uart-i2c-can) | 同じルネサス系の**RX**が、周辺対応と開発環境の継承の観点で最も移行しやすい候補です。一方、長期調達性やARM資産の活用を重視するなら**STM32**も有力です。最終的には、必要性能・周辺・調達期間・既存ソフト資産の有無から総合的に決めます。 移行元のファミリから移行先候補と工数を押し上げる要因を逆引きできる [マイコン移行判断ナビ](https://technosphere.co.jp/mcu-migration#sh1-sh2) を公開しています。他ファミリとの比較にもお使いください。 ## 移行プロジェクトの進め方 ** 標準的な移行ステップ 1. **現状調査**：残っている資産（ソース・ROM・回路図・実機）を棚卸し 2. **仕様復元**：ソースがあれば解析、無ければ逆アセンブル＋実機動作解析で仕様化 3. **移行先選定**：性能・周辺・調達性から現行マイコンを選定 4. **ハード設計**：基板リプレース（端子・電圧・周辺の対応） 5. **ソフト移植**：周辺ドライバの置換、エンディアン・アセンブリの再実装 6. **等価性検証**：旧機と新機の入出力・タイミングを突き合わせて検証 7. **量産移行**：評価・信頼性試験を経て量産へ 「いきなり全面再設計」ではなく、まず**現状調査と小規模なPoC（一部機能の移植検証）**から始めると、リスクとコストを抑えられます。ROMしか残っていない場合でも、まずは逆アセンブルでどこまで仕様が復元できるかを見極めるところから着手できます。 ## まとめ ### この記事のまとめ - SuperH（SH-1〜SH-4）は多くがEOL/NRNDとなり、産業機器を中心に移行ニーズが拡大している - 移行の壁は「ソース欠落・ビッグエンディアン・周辺差異・コンパイラ依存」の4つ - 移行先は同一ベンダーのRXが第一候補。要件次第でRL78/RH850/STM32も選択肢 - ソースが無くても、実機とROMがあれば逆アセンブルで仕様復元し移植できる - 現状調査と小規模PoCから始めると、リスクとコストを抑えて移行できる SuperHベースの設備・製品の移行や再生でお困りでしたら、テクノスフィアにお気軽にご相談ください。ソース紛失・部品供給終了の状況からでも、現行マイコンへの移行プランをご提案します。 SuperH 基板の逆アセンブル・仕様復元、RX/RH850/STM32 への移植・量産まで [組込み制御・マイコン開発](https://technosphere.co.jp/embedded) として対応しています。 ／レガシーマイコンの移行・再生のご相談はこちら＼ ### SuperH からの移行・レガシー再生 ソース紛失・部品供給終了したSuperH基板を、逆アセンブルによる仕様復元から現行マイコン（RX等）への移植・量産まで一気通貫で対応します。「設備が止まる前に手を打ちたい」段階でご相談ください。 [組込み開発サービスを見る](https://technosphere.co.jp/embedded) [SuperH→RX移植相談](https://technosphere.co.jp/contact) ## よくある質問（FAQ） ** SuperHの移行先には何を選べばよいですか？ 同じルネサスのRXが第一候補です。SCIF→SCI、MTU2→MTUなど周辺の対応が取りやすく、e2 studioで環境を引き継げます。車載ならRH850、ARM資産重視ならSTM32も選択肢です。要件から選定します。 ** ソースやSHCコンパイラ環境が無くても移行できますか？ 可能です。実機とROM（hex/mot/bin）が残っていれば、逆アセンブル・動作解析で仕様を復元し現行マイコンへ再実装できます。テクノスフィアはソース・回路図紛失状態からの再構築実績があります。 ** 移行で特に注意すべき点は？ ビッグエンディアン前提のデータ処理、SHアセンブリの割り込み・初期化、SCIF/MTU2/DMACなど周辺の挙動差、コンパイラ依存の組込み関数や#pragmaです。タイミング依存の制御は実機計測しながら移植します。 ** なぜ今SuperHの移行が増えているのですか？ 多くの品種がEOL/NRNDとなり在庫枯渇・供給リスクが顕在化しているためです。当時の担当者の退職や開発環境の老朽化も重なり、動いているうちに現行マイコンへ移行したいという相談が増えています。 ## 次に読む｜マイコン記事 - [レガシー再生 RL78 逆アセンブル・再構築 ソース紛失基板の復元事例](https://technosphere.co.jp/blog/renesas-rl78-reverse-engineering) - [移行先候補 Renesas RX マイコン入門 SuperHからの第一移行先](https://technosphere.co.jp/blog/renesas-rx-introduction) - [レガシー移行 H8/H8S 移行ガイド 同じ旧日立系の移行も対応](https://technosphere.co.jp/blog/h8-h8s-migration-guide) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # Three.jsでスマホ対応3Dゲームを作る｜フロントエンドだけで動くWebアプリ実装ガイド｜テクノスフィア > サーバー不要・インストール不要、ブラウザだけで動く3Dドローンゲームを実際に公開しながら実装を解説。Three.jsのシーン構築、スマホのバーチャルスティック実装、AABB衝突判定、AI画像生成(gpt-5.5)によるテクスチャ制作、モバイル60fps最適化まで。実際に遊べるデモ付き。 URL: https://technosphere.co.jp/blog/threejs-mobile-3d-game ** 目次 1. まず遊んでみてください（デモ公開中） 2. なぜ「フロントエンドだけ」で3Dゲームが動くのか 3. 技術スタック：Three.js + ES Modules、依存はそれだけ 4. 「リアルで迫力のある」絵作り：夕暮れ・フォグ・トーンマッピング 5. スマホ対応の肝：バーチャルスティックをPointer Eventsで自作する 6. ゲームループと軽量物理（慣性・AABB衝突） 7. ゲーム素材はAI画像生成で作る（プロンプト付き） 8. スマホで60fpsを出す5つの最適化 9. よくある質問（FAQ） 10. まとめ：この技術で作れる「業務アプリ」 ## まず遊んでみてください（デモ公開中） 論より証拠。この記事で解説する3Dゲーム「**ドローンインスペクター3D**」は、実際にこのサイトで公開しています。スマホでもPCでも、リンクを開けば**その場で**始まります。 [▶ ドローンインスペクター3D をプレイ](https://technosphere.co.jp/games/drone-inspector/) インストール不要・無料・通信量はページ読込の一度きり 夕暮れの工業地帯をドローンで飛行し、制限時間120秒でシアンに光る検査リング10箇所を通過するゲームです。App Store も Google Play も経由していません。**PHPすら実行していない、ただの静的ファイル**がこの3D空間を動かしています——これが本記事のテーマです。 ## なぜ「フロントエンドだけ」で3Dゲームが動くのか 現代のブラウザには **WebGL**（GPUを直接叩く3D描画API）が標準搭載されています。スマホの Safari / Chrome も例外ではありません。つまり描画・物理・入力・スコア管理のすべてをJavaScriptで書けば、**サーバーは「ファイルを配るだけ」**でよくなります。 - **ホスティングコスト**：静的配信のみ（当サイトはS3+CloudFront）。アクセスが増えてもサーバー負荷という概念自体がない - **配布**：URLひとつ。ストア審査もアップデート配信もなし - **オフライン**：一度読み込めば通信ゼロで動作（PWA化すればホーム画面アイコンからの起動も可能） 「アプリを作りたいがストア公開はハードルが高い」という場合、まずこの**Webアプリ（ブラウザアプリ）**形態で出すのは実務でも有力な選択肢です。 ## 技術スタック：Three.js + ES Modules、依存はそれだけ 使ったライブラリは **Three.js（r160）** ただひとつ。ビルドツールも npm も使わず、ブラウザ標準の **importmap** で読み込みます。ゲーム本体は素のJavaScript約400行です。 ``` ``` この構成の利点は**ビルド環境の寿命に縛られない**ことです。node_modules が壊れて動かない——という数年後のリスクがなく、ファイルを置けば10年後も動きます。企業サイトに置く技術デモとしては重要な性質です。 ## 「リアルで迫力のある」絵作り：夕暮れ・フォグ・トーンマッピング ローポリでもリアルに見せる鍵は、ジオメトリの細かさではなく**光と空気**です。今回のデモでは次の4点を組み合わせています。 1. **ACESトーンマッピング**：映画で使われる色変換。白飛びが減り、夕陽のオレンジが「写真の色」になる 2. **フォグ（霧）**：遠景を夕焼け色に溶かす。距離感と巨大感が生まれ、同時に遠景の描画も省ける 3. **低い太陽光＋長い影**：DirectionalLight を低角に置き、PCFソフトシャドウで長い影を落とす 4. **equirectangular スカイボックス**：360度パノラマ1枚を背景と環境光（IBL）の両方に使う ``` renderer.toneMapping = THREE.ACESFilmicToneMapping; scene.fog = new THREE.Fog(0xc98a5a, 90, 520); // 夕焼け色の霧 const sun = new THREE.DirectionalLight(0xffb877, 2.1); sun.position.set(-340, 150, 90); // 低い夕陽 sun.castShadow = true; texLoader.load('tex/sky.jpg', t => { t.mapping = THREE.EquirectangularReflectionMapping; scene.background = t; // 背景 scene.environment = t; // 映り込み・環境光にも同じ画像を使う }); ``` さらに、速度に応じてカメラのFOV（視野角）を70°→82°まで動的に広げています。加速時に視界が「引き伸ばされる」ことで、数値以上のスピード感＝迫力が出ます。 ## スマホ対応の肝：バーチャルスティックをPointer Eventsで自作する スマホゲームの操作性はここで決まります。ライブラリに頼らなくても、**Pointer Events** を使えば約20行で「ゲームパッドの左右スティック」を実装できます。 ``` function stick(el, cb) { // el: スティックのDOM, cb(x,y): -1〜1 const knob = el.firstElementChild; let id = null, cx = 0, cy = 0; const R = 44; // 可動半径(px) el.addEventListener('pointerdown', e => { id = e.pointerId; cx = e.clientX; cy = e.clientY; el.setPointerCapture(id); // 指が枠を出ても追跡し続ける }); el.addEventListener('pointermove', e => { if (e.pointerId !== id) return; let dx = e.clientX - cx, dy = e.clientY - cy; const d = Math.hypot(dx, dy); if (d > R) { dx *= R / d; dy *= R / d; } // 半径でクランプ knob.style.transform = `translate(${dx}px,${dy}px)`; cb(dx / R, dy / R); }); const end = e => { if (e.pointerId !== id) return; id = null; knob.style.transform = ''; cb(0, 0); // ニュートラルに戻す }; el.addEventListener('pointerup', end); el.addEventListener('pointercancel', end); } ``` 実装のポイントは3つあります。 - **setPointerCapture**：指がスティックの枠からはみ出しても追跡が切れない。これがないと激しい操作で必ず破綻します - **pointerId の照合**：左右のスティックを別の指で同時に操作できる（マルチタッチ） - **CSSに touch-action:none**：ブラウザのスクロール・ピンチ操作を無効化し、ゲーム操作と衝突させない PC では同じ入力値を WASD キーから合成しているため、ゲームロジック側はデバイスの違いを一切意識しません。 ## ゲームループと軽量物理（慣性・AABB衝突） 物理エンジンは使っていません。ドローンの「ふわっとした」挙動は、**加速度＋空気抵抗**の2行で表現できます。 ``` // 毎フレーム (dt: 前フレームからの秒数) vel.addScaledVector(inputDir, ACC * dt); // 入力方向へ加速 vel.multiplyScalar(1 - Math.min(1, 2.2 * dt)); // 空気抵抗（自然に減速） drone.position.addScaledVector(vel, dt); // 位置を更新 ``` 建物との衝突は、全建物を**AABB（軸に平行な直方体）**として持ち、めり込んだら浅い軸方向に押し戻して速度を反転させるだけの簡易実装です。64棟＋コンテナ60基でも判定は毎フレーム1ms未満。「正確な物理」より「軽くて壊れない物理」がモバイルでは正義です。 ``` for (const c of colliders) { if (p.x > c.min.x && p.x < c.max.x && p.z > c.min.z && p.z < c.max.z && p.y < c.max.y) { const dx = Math.min(p.x - c.min.x, c.max.x - p.x); const dz = Math.min(p.z - c.min.z, c.max.z - p.z); if (dx < dz) { p.x += sign(p.x - center.x) * dx; vel.x *= -0.35; } else { p.z += sign(p.z - center.z) * dz; vel.z *= -0.35; } } } ``` ## ゲーム素材はAI画像生成で作る（プロンプト付き） スカイボックス・地面・建物・コンテナのテクスチャは、すべて**AI画像生成（gpt-5.5系の画像モデル）**で制作しました。デザイナー0人でここまで作れる時代です。3Dエンジンでそのまま使える画像を出すコツは、プロンプトに「用途の専門用語」を入れることです。 - **タイル化テクスチャ**：「*seamless tileable texture, top-down view, flat even lighting, edges must tile seamlessly in all directions*」——繋ぎ目なく敷き詰められる画像になる - **スカイボックス**：「*seamless equirectangular 360 degree sky panorama, the left and right edges must connect seamlessly*」——球体に貼れる360度画像になる - **PBR風の質感**：「*photorealistic PBR albedo style, no shadows of objects*」——ライティング情報を含まない素材向きの画像になる 生成画像はJPEG圧縮して1枚100〜300KB程度に抑えます。ゲーム全体でもThree.js込み**約1.5MB**——Webページ1枚分の転送量で3Dゲームが配れる計算です。 ## スマホで60fpsを出す5つの最適化 1. **devicePixelRatio を2でクランプ**：`renderer.setPixelRatio(Math.min(devicePixelRatio, 2))`。DPR 3のスマホで描画ピクセル数が半分以下になる。体感画質はほぼ変わらない 2. **フォグと描画距離の連動**：霧で見えなくなる距離より遠くは描かない。カメラの far を絞れば頂点処理が減る 3. **ジオメトリ・マテリアルの使い回し**：建物64棟でもジオメトリは1種類×スケール違い。GPUへの状態変更が激減する 4. **シャドウマップの出し分け**：タッチデバイス判定（`matchMedia('(pointer: coarse)')`）で 2048→1024 に解像度を落とす 5. **パーティクルは Points で**：塵700粒・煙240粒もドローコールは各1回。Mesh を700個並べたら即死する場面 この5点だけで、ミドルレンジのAndroidでも安定して滑らかに動きます。逆に言えば、**これを外すとハイエンドiPhone以外はカクつく**のがモバイルWebGLの現実です。 ## よくある質問（FAQ） ### Q. サーバーなしでどうやって3Dゲームが動くのですか？ 描画・物理・入力・スコア管理をすべてブラウザ内のJavaScript（Three.js/WebGL）で処理しているためです。ホスティングは静的ファイル配信だけでよく、プレイ中のサーバー通信はゼロです。仕組みはこちらで解説しています。 ### Q. スマホのブラウザでも本当に60fpsで動きますか？ 動きます。5つの最適化——DPRクランプ・フォグ連動カリング・ドローコール削減・シャドウ出し分け・Pointsパーティクル——が前提条件です。 ### Q. ゲームのテクスチャや背景はどうやって用意しましたか？ AI画像生成で制作しました。「seamless tileable」「equirectangular panorama」など用途を指定するプロンプトで、3Dエンジンにそのまま貼れる素材が生成できます。 ### Q. この技術はゲーム以外にも使えますか？ 使えます。製品3Dビューア、設備のデジタルツイン可視化、建築ウォークスルー、教育シミュレーターなど。まとめで具体例を挙げています。 ## まとめ：この技術で作れる「業務アプリ」 ### この記事のまとめ - WebGL＋Three.jsなら、サーバーもストアも不要でURLひとつで配れる3Dアプリが作れる - リアルさはポリゴン数ではなく「光と空気」——ACESトーンマッピング・フォグ・低い太陽・IBLで作る - バーチャルスティックはPointer Events＋setPointerCaptureで約20行 - 物理は「加速度＋空気抵抗＋AABB」の軽量実装で十分。モバイルでは軽さが正義 - テクスチャ・スカイボックスはAI画像生成で内製可能。全体1.5MBに収まる 同じ技術スタックは、ゲームに限らず**製品の3Dビューア・工場設備のデジタルツイン・建築ウォークスルー・操作トレーニングシミュレーター**にそのまま応用できます。「アプリを作りたいが、ストア公開や専用端末まではハードルが高い」——そんな案件こそ、ブラウザだけで動くWebアプリの出番です。 テクノスフィアは、こうしたフロントエンド技術に加えて、スマホアプリ（iOS/Android）、画像認識AI、組込みシステムまで一気通貫で開発しています。プロトタイプのご相談からお気軽にどうぞ。 [▶ もう一度デモを遊ぶ](https://technosphere.co.jp/games/drone-inspector/) ｜ [スマホアプリ開発サービスを見る](https://technosphere.co.jp/app-development) ｜ [開発の相談をする](https://technosphere.co.jp/contact) 業務で使うスマホアプリの方式選定は[ネイティブ・クロスプラットフォーム・PWAの選び方](https://technosphere.co.jp/blog/native-vs-pwa-app-choice)で解説しています。開発のご相談は[スマホアプリ開発サービス](https://technosphere.co.jp/app-development)へ。 [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # TI C2000 モーター制御入門｜ePWM・eQEP・高速ADCとFOCでBLDC/PMSMを回す｜株式会社テクノスフィア > TI C2000（TMS320F28xx）でモーター制御。C28x・CLA・ePWM・eQEP・PWM 同期 ADC・CMPSS の役割と FOC で BLDC/PMSM を駆動する制御ループを CCS+C2000Ware で解説。 URL: https://technosphere.co.jp/blog/ti-c2000-motor-control ** 目次 1. はじめに：C2000とは何か 2. C28xコア・CLA・TMU 3. モーター制御を支える周辺機能 4. ePWMで三相PWMを生成 5. eQEP・高速ADCで電流と位置を検出 6. FOC（ベクトル制御）の制御ループ 7. 開発環境とライブラリ 8. よくあるトラブルと対策 9. まとめ ## はじめに：C2000とは何か **C2000**（TMS320F28xx）は、Texas Instrumentsの**リアルタイム制御専用マイコン**ファミリです。Piccolo（F2802x/F2803x/F2806x）やDelfino（F2837x/F2838x）といったシリーズがあり、**モーター駆動・インバータ・デジタル電源・EV充電器・太陽光パワコン**など、高速・高精度な制御が要求される分野で世界的に使われています。 汎用マイコンとの最大の違いは「**制御ループをキャリア周期ごとに確実に回すための周辺と演算器**」が一体設計されている点です。PWM生成・電流検出・位置検出・保護・制御演算が緊密に同期し、数十kHzのスイッチング周波数でも余裕を持って電流制御を実行できます。本記事では、C2000でモーターを回すための要素を入門者向けに整理します。 ** 弊社での活用実績 テクノスフィアでは、モーター制御・パワーエレクトロニクス分野の [組込み受託開発](https://technosphere.co.jp/embedded-achievements) に対応しています。汎用マイコン（[RX](https://technosphere.co.jp/blog/renesas-rx-introduction) / STM32）での制御から、C2000による高性能FOCまで、要件に応じた設計をご提案します。 ## C28xコア・CLA・TMU C2000の演算リソースは、制御に最適化された3つの要素で構成されます。 | 要素 | 役割 | | **C28x コア** | 32bitのメインCPU。FPU搭載品は浮動小数点制御演算が高速 | | **CLA**（Control Law Accelerator） | 制御演算専用のコプロセッサ。メインCPUと並列に制御ループを実行し、応答性を確保 | | **TMU**（Trigonometric Math Unit） | sin/cos/atan等を高速化。FOCの座標変換を大幅に高速化 | FOCではクラーク変換・パーク変換で三角関数を多用するため、TMUの有無が制御周期の余裕に直結します。重い電流制御ループをCLAにオフロードし、メインCPUは通信やシーケンス管理に専念させる、という分担も定石です。 ## モーター制御を支える周辺機能 | 周辺 | 役割 | | **ePWM** | デッドタイム付き相補PWM。三相インバータのゲート駆動信号を生成 | | **eCAP** | 入力キャプチャ。パルス周期・速度の測定 | | **eQEP** | 直交エンコーダのカウント。回転位置・速度を取得 | | **ADC** | 高速逐次比較ADC。PWMに同期して相電流をサンプリング | | **CMPSS** | 内蔵コンパレータ。過電流を検出してPWMを即トリップ（保護） | | **SDFM** | ΔΣ変調器インターフェース。絶縁電流センシングに対応 | これらが**相互に同期**している点がC2000の真価です。ePWMがADCの変換開始をトリガし、変換完了でCLAの制御ループ割り込みを起動、CMPSSが異常時にePWMを即時遮断する——この一連の流れがハードウェアで連携します。 ## ePWMで三相PWMを生成 三相インバータでは、上下アームの短絡を防ぐ**デッドタイム**付きの相補PWMが必須です。ePWMはこれをハードウェアで生成します。3つのePWMモジュール（U/V/W相）を同期させ、中央揃え（アップダウンカウント）でキャリアを作るのが一般的です。 ``` // ePWM1 を 20kHz 中央揃え、デッドタイム付きで設定（概念コード） EPwm1Regs.TBPRD = PWM_PERIOD; // キャリア周期（20kHz） EPwm1Regs.TBCTL.bit.CTRMODE = TB_COUNT_UPDOWN; // 中央揃え // コンペアでデューティを設定（FOCの出力電圧指令から計算） EPwm1Regs.CMPA.bit.CMPA = duty_u; // デッドバンド（上下アーム短絡防止） EPwm1Regs.DBCTL.bit.OUT_MODE = DB_FULL_ENABLE; EPwm1Regs.DBRED = DEADTIME_COUNT; // 立上り遅延 EPwm1Regs.DBFED = DEADTIME_COUNT; // 立下り遅延 // ADC変換開始をePWMからトリガ（電流を谷で取得） EPwm1Regs.ETSEL.bit.SOCAEN = 1; EPwm1Regs.ETSEL.bit.SOCASEL = ET_CTR_PRD; ``` ** デッドタイムは安全の要 デッドタイムが不足すると上下アームが瞬間的に同時オンし、貫通電流でパワー素子が破壊されます。ゲートドライバとパワー素子の特性に合わせて十分なデッドタイムを設定し、必ず低電圧・電流制限下で検証してください。 ## eQEP・高速ADCで電流と位置を検出 FOCには「**相電流**」と「**回転子位置**」の正確な検出が不可欠です。 - **相電流**：シャント抵抗やホール式電流センサーの出力を、ePWMに同期したタイミング（キャリアの谷など）でADCサンプリングします。スイッチングノイズを避けるタイミング設計が精度の鍵です。 - **回転子位置**：エンコーダを使う場合はeQEPで直交パルスをカウントし、位置・速度を得ます。センサーレス制御では、相電流・電圧から位置を推定（オブザーバ）します。 ADCはePWMトリガで自動起動し、変換完了割り込みで制御ループを起動するのが定石です。これにより「PWM周期ごとに必ず最新電流で制御演算する」リアルタイム性が保証されます。 ## FOC（ベクトル制御）の制御ループ **FOC（Field Oriented Control）**は、三相電流を回転座標系のd軸（磁束方向）・q軸（トルク方向）に変換して独立制御する方式です。トルクリプルが小さく高効率で、PMSM/BLDCの高性能駆動の標準手法です。1制御周期の流れは次のとおりです。 ** FOC 1周期の処理フロー 1. **電流取得**：ADCで相電流 Iu, Iv, Iw を取得 2. **クラーク変換**：3相 → 静止2軸 (Iα, Iβ) 3. **パーク変換**：静止2軸 → 回転2軸 (Id, Iq)（位置θを使用） 4. **電流PI制御**：Id, Iq を指令値に追従させる 5. **逆パーク変換**：回転2軸 → 静止2軸の電圧指令 (Vα, Vβ) 6. **SVPWM**：空間ベクトルPWMで各相デューティを算出 7. **ePWM更新**：CMPA/CMPBにデューティを反映 この一連の演算を、TMU（三角関数）とCLA（並列実行）で加速します。速度制御を行う場合は、電流ループの外側に速度PIループを重ねるカスケード構成にします。C2000Wareのモーター制御ライブラリやリファレンスデザインを土台にすると、ゼロから書くより安全かつ短期に立ち上げられます。 ## 開発環境とライブラリ | 要素 | 内容 | | 統合開発環境 | **Code Composer Studio（CCS）** | | ドライバ・サンプル | **C2000Ware**（周辺ドライバ・サンプル・ライブラリ集） | | 周辺設定 | **SysConfig**（GUIで端子・周辺を設定しコード生成） | | 数学ライブラリ | IQmath（固定小数点）/ FPU・CLA math ライブラリ | | 評価ボード | LaunchPad（LAUNCHXL-F28xx）/ controlCARD + モータ用ブースタパック | 初めてC2000でモーターを回す場合は、TIの**モーター制御リファレンスデザイン**（評価キット＋サンプルプロジェクト）から始めるのが安全です。動く状態を基準に、自分のモーター・インバータに合わせてパラメータを調整していくアプローチが、トラブルを最小化します。 ## よくあるトラブルと対策 | 症状 | 主な原因 | 対策 | | モーターが回らない・脱調する | 位置θのずれ・電流位相のずれ | エンコーダ原点・極対数・電流センサーの符号/ゲインを確認。オープンループ起動から検証 | | パワー素子が発熱・破損 | デッドタイム不足・貫通電流 | デッドタイムを十分に。必ず低電圧・電流制限で段階的に検証 | | 電流値にノイズが乗る | ADCサンプリングタイミングがスイッチングと重なる | キャリアの谷でサンプリング。配線・グランド設計を見直す | | 制御ループが間に合わない | 演算負荷過大・CLA未活用 | 重い演算をCLAへオフロード。TMUで三角関数を高速化。固定小数点化も検討 | | 過電流で頻繁にトリップ | CMPSSしきい値・PIゲイン不適 | 保護しきい値とPIゲインを再調整。電流リミットを段階的に上げる | ** 安全に関する注意 モーター・インバータの開発は高電圧・大電流を扱い、感電・発火・部品破損のリスクがあります。必ず適切な保護（電流制限電源、ヒューズ、絶縁、保護メガネ等）のもとで、低電圧から段階的に検証してください。 ## まとめ ### この記事のまとめ - C2000（TMS320F28xx）はモーター制御・デジタル電源向けのリアルタイム制御専用マイコン - ePWM（デッドタイム付き相補PWM）・eQEP（エンコーダ）・PWM同期高速ADC・CMPSS（保護）が緊密に連携する - C28xコア＋CLA（制御コプロセッサ）＋TMU（三角関数）で制御ループを高速・並列に回す - FOCはクラーク/パーク変換でdq軸に分離し、電流PI→逆変換→SVPWMでモーターを駆動する - 開発はCCS＋C2000Ware。リファレンスデザインを土台にすると安全に立ち上げられる C2000を使ったモーター制御・インバータ・デジタル電源の開発でお困りのことがあれば、テクノスフィアにお気軽にご相談ください。FOCのPoC、既存制御の高性能化、汎用マイコンからの移行までご相談を承ります。 ／この内容の受託開発・PoC相談はこちら＼ ### C2000・モーター制御の受託開発 BLDC/PMSMのFOC制御、インバータ、デジタル電源の設計・PoC・量産化をテクノスフィアが対応します。汎用マイコンからC2000への高性能化移行もご相談ください。 [組込み開発サービスを見る](https://technosphere.co.jp/embedded) [相談・お見積り](https://technosphere.co.jp/contact) ## よくある質問（FAQ） ** C2000はなぜモーター制御に向いていますか？ デッドタイム付き相補PWMのePWM、エンコーダをカウントするeQEP、PWM同期の高速ADC、過電流を即遮断するCMPSS、制御演算を並列実行するCLA、三角関数を高速化するTMUが揃い、キャリア周期ごとの電流制御ループを確実に回せるためです。 ** FOC（ベクトル制御）とは何ですか？ 三相電流をd軸（磁束）・q軸（トルク）に座標変換して独立制御する方式です。クラーク/パーク変換でdq軸に変換し、電流PI制御後に逆変換とSVPWMで相電圧を生成します。トルクリプルが小さく高効率で、PMSM/BLDCの高性能駆動に使われます。 ** 開発環境は何を使いますか？ Code Composer Studio（CCS）とC2000Ware（ドライバ・サンプル・ライブラリ）が標準です。周辺はSysConfigでGUI設定でき、FOCには数学ライブラリ（IQmath/CLAmath）やモーター制御ライブラリを利用できます。 ** STM32・RXのモーター制御とどう違いますか？ STM32（G4等）や [RX](https://technosphere.co.jp/blog/renesas-rx-introduction)（RX66T等）も制御可能ですが、C2000はCLA・TMU・同期ADCなどリアルタイム制御特化のアーキで高速・高精度・多軸/高キャリア制御やデジタル電源に優位です。UIや通信も兼ねるなら汎用MCU、制御性能最優先ならC2000という選び方です。 ## 次に読む｜マイコン記事 - [Renesas シリーズ Renesas RX マイコン入門 MTUを使った汎用マイコンでのモーター制御](https://technosphere.co.jp/blog/renesas-rx-introduction) - [TI シリーズ TI MSP430 超低消費電力入門 同じTIの省電力16bitマイコン](https://technosphere.co.jp/blog/ti-msp430-low-power) - [開発実績 組込み制御・マイコン開発 実績紹介 制御系を含む多数の受託開発事例](https://technosphere.co.jp/embedded-achievements) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # TI MSP430 超低消費電力入門｜LPMモード・FRAM・eUSCIで電池駆動を極める｜株式会社テクノスフィア > TI MSP430 は超低消費電力 16bit マイコンの定番。LPM0〜LPM4.5・FRAM・eUSCI・Timer_A・ADC を CCS+DriverLib で実装、電池1個で年単位動作のセンサー機器設計を解説。 URL: https://technosphere.co.jp/blog/ti-msp430-low-power ** 目次 1. はじめに：MSP430が省電力で選ばれる理由 2. 開発環境（CCS / DriverLib） 3. 低消費電力モード（LPM）の全体像 4. クロックシステムと省電力設計 5. FRAM内蔵品の活用 6. eUSCIでUART・I2C・SPI 7. 電池駆動を実現する設計パターン 8. よくあるトラブルと対策 9. まとめ ## はじめに：MSP430が省電力で選ばれる理由 **MSP430**は、Texas Instruments（TI）の16bit超低消費電力マイコンファミリです。1990年代から続く実績あるシリーズで、「電池1個で何年も動かす」ような**極限の低消費電力アプリ**の定番として、電力量計・水道メーター・環境センサー・ウェアラブル・医療機器などに広く使われてきました。 MSP430の強みは、(1) 待機時数百nA〜数µAという圧倒的な低消費電流、(2) 割り込みからの高速ウェイクアップ、(3) 不揮発メモリ**FRAM**を内蔵した品種、の3点です。本記事では、MSP430で電池駆動機器を設計するための**低電力モード・クロック設計・FRAM活用・周辺実装**を入門者向けに解説します。 ** 弊社での活用実績 テクノスフィアでは、電池駆動のセンサーノードや計測機器の [組込み受託開発](https://technosphere.co.jp/embedded-achievements) を多数手がけています。低消費電力設計は [STM32の低消費電力モード](https://technosphere.co.jp/blog/stm32-low-power-battery) でも解説しており、デバイス特性に応じて最適なマイコンを選定しています。 ## 開発環境（CCS / DriverLib） | 要素 | 内容 | | 統合開発環境 | **Code Composer Studio（CCS）**。Eclipseベース、無償 | | ライブラリ | **MSP430Ware / DriverLib**（周辺ドライバAPI） | | 簡易開発 | **Energia**（Arduino互換、試作向け） | | 評価ボード | LaunchPad（MSP-EXP430シリーズ）。オンボードデバッガ付き | | 消費電流計測 | EnergyTrace（CCS統合、リアルタイムに電流/エネルギーを可視化） | 特に**EnergyTrace**はMSP430開発の強力な武器です。コードを動かしながら消費電流・エネルギーをリアルタイムにグラフ表示でき、「どの処理で電気を食っているか」を一目で把握できます。低電力設計の最適化に必須のツールです。 ## 低消費電力モード（LPM）の全体像 MSP430の心臓部は、きめ細かい低電力モード（Low Power Mode）です。処理がないときにいかに深く眠るかが平均電流を決めます。 | モード | 動作 | 典型用途 | | **Active** | CPU・全クロック動作 | 演算・通信中 | | **LPM0** | CPU停止、MCLK停止、SMCLK/ACLK動作 | 周辺が動く短い待ち | | **LPM3** | 高速クロック停止、ACLK(32kHz)のみ。数µA級 | **最も実用的な待機モード** | | **LPM4** | 全クロック停止。外部割り込みで復帰 | イベント待ち | | **LPM3.5 / LPM4.5** | 大半の電源を遮断。RTCや一部のみ保持 | 超長期スリープ（nA級） | 基本設計は「**LPM3で眠り、割り込みで起きて処理し、また眠る**」です。CCSではビット操作マクロでモードに入り、割り込みハンドラ内で `__bic_SR_register_on_exit()` によりウェイクアップします。 ``` #include int main(void) { WDTCTL = WDTPW | WDTHOLD; // ウォッチドッグ停止 PM5CTL0 &= ~LOCKLPM5; // GPIO設定をアンロック（FR系） // ... クロック・タイマ・周辺の初期化 ... __bis_SR_register(GIE); // 割り込み許可 while (1) { __bis_SR_register(LPM3_bits); // LPM3 へ（ここで眠る） // 割り込みで起きると続きが実行される do_periodic_task(); } } // タイマ割り込みでウェイクアップ #pragma vector = TIMER0_A0_VECTOR __interrupt void Timer_A0_ISR(void) { __bic_SR_register_on_exit(LPM3_bits); // mainをLPM3から復帰させる } ``` ## クロックシステムと省電力設計 MSP430は複数のクロックソースを持ち、用途別に使い分けることで電力を最適化します。 - **ACLK**：低速（典型32.768kHz）。LPM3でも生き続け、RTCや周期ウェイクアップに使う - **SMCLK**：サブシステムクロック。周辺（タイマ・シリアル）の駆動に使う - **MCLK**：CPUクロック。DCO（内蔵発振器）から供給。処理時のみ高速にする 省電力の鉄則は「**必要なときだけ速く、普段はACLKで眠る**」です。周期動作のタイミングはACLK駆動のTimer_AやRTCで作り、CPUはLPM3で止めておきます。DCOの周波数も必要最小限に設定します。 ## FRAM内蔵品の活用 MSP430**FR**シリーズ（FR2xx/FR4xx/FR5xx/FR6xx）は、プログラム・データ領域に不揮発メモリ**FRAM**を採用しています。フラッシュと比べた利点は次のとおりです。 | 項目 | フラッシュ | FRAM | | 書き込み速度 | 遅い（ブロック消去が必要） | 速い（バイト単位で即書き込み） | | 書き込み電力 | 大きい（昇圧が必要） | 小さい | | 書き換え回数 | 1万〜10万回程度 | 10^12〜10^15回（事実上無制限） | | 向く用途 | プログラム格納 | 頻繁なデータ保存・ロギング | このため、**データロガー**や「電源断時に状態を即保存したい」機器でFRAMは絶大な効果を発揮します。変数に `__persistent` 属性を付ければ、リセットや電源断をまたいで値を保持できます。 ## eUSCIでUART・I2C・SPI MSP430の通信は**eUSCI（enhanced Universal Serial Communication Interface）**で行います。eUSCI_AがUART/SPI、eUSCI_BがI2C/SPIに対応します。DriverLibを使うと設定が簡潔になります。 ``` #include /* UART 115200bps（SMCLK使用、設定値はBaud Rate Calculatorで算出）*/ EUSCI_A_UART_initParam p = {0}; p.selectClockSource = EUSCI_A_UART_CLOCKSOURCE_SMCLK; p.clockPrescalar = 8; // 例：SMCLK 16MHz → 115200 p.firstModReg = 10; p.secondModReg = 0xF7; p.parity = EUSCI_A_UART_NO_PARITY; p.msborLsbFirst = EUSCI_A_UART_LSB_FIRST; p.numberofStopBits = EUSCI_A_UART_ONE_STOP_BIT; p.uartMode = EUSCI_A_UART_MODE; p.overSampling = EUSCI_A_UART_OVERSAMPLING_BAUDRATE_GENERATION; EUSCI_A_UART_init(EUSCI_A0_BASE, &p); EUSCI_A_UART_enable(EUSCI_A0_BASE); EUSCI_A_UART_transmitData(EUSCI_A0_BASE, 'A'); ``` ** ボーレート設定はツールで eUSCIのボーレート設定値（prescalar / modReg）はクロック周波数に依存します。TIが提供する「MSP430 USCI/eUSCI UART Baud Rate Calculator」で算出するのが確実です。手計算ミスは文字化けの主因になります。 ## 電池駆動を実現する設計パターン 電池1個で年単位動作させるための定石をまとめます。 ** 低電力設計チェックリスト - **デフォルトはLPM3で眠る**。Active時間を極小化する - 周期処理はACLK駆動のTimer_A / RTCで起こす（CPUを使ってポーリングしない） - 未使用GPIOは出力Lowか入力プルダウンで固定し、フローティングによる漏れ電流を防ぐ - センサーへの電源はGPIOやロードスイッチでゲートし、測定時だけ通電する - 頻繁な保存はFRAMへ。フラッシュ書き込みの電力浪費を避ける - EnergyTraceで実測し、想定外の電流スパイクを潰す たとえば「10秒に1回、温湿度を測ってFRAMに記録し、1時間に1回まとめてLoRaで送信する」センサーノードなら、平均電流を数µA〜数十µAに抑えられ、コイン電池でも年単位の動作が現実になります。 ## よくあるトラブルと対策 | 症状 | 主な原因 | 対策 | | LPMに入っても電流が下がらない | GPIOフローティング・周辺の停止漏れ | 未使用端子を固定。使わない周辺は無効化。EnergyTraceで切り分け | | FR系でGPIOが動かない | LPM5ロック未解除 | 起動直後に `PM5CTL0 &= ~LOCKLPM5;` を実行 | | UARTが文字化け | ボーレート設定値の誤り | Baud Rate Calculatorで再計算。クロック源と一致させる | | 割り込みで復帰しない | ISRでLPMビットをクリアしていない | `__bic_SR_register_on_exit(LPM3_bits)` を忘れずに | | ウォッチドッグでリセット | WDT停止/定期クリア漏れ | 不要なら停止、使うなら周期的にクリア | ## まとめ ### この記事のまとめ - MSP430はTIの16bit超低消費電力マイコン。電池駆動のセンサー・計測・ロガー機器の定番 - 基本設計は「LPM3で眠り、割り込みで起きて処理し、また眠る」 - ACLK(32kHz)で周期ウェイクアップを作り、CPUはLPM3で止めておく - FRAM内蔵品は高速・低電力・高書き換え耐性でデータロギングに最適 - 通信はeUSCI（A=UART/SPI、B=I2C/SPI）、最適化はEnergyTraceで実測する MSP430を使った電池駆動機器・センサーノードの開発でお困りのことがあれば、テクノスフィアにお気軽にご相談ください。低消費電力設計のPoCから量産まで一貫して対応します。 ／この内容の受託開発・PoC相談はこちら＼ ### MSP430・電池駆動機器の受託開発 コイン電池で年単位動作するセンサーノード・計測機器・データロガーの低消費電力設計をテクノスフィアが対応します。PoCから量産・現場導入まで一気通貫。 [組込み開発サービスを見る](https://technosphere.co.jp/embedded) [相談・お見積り](https://technosphere.co.jp/contact) ## よくある質問（FAQ） ** 低消費電力モード（LPM）はどう使い分けますか？ LPM0はCPU・MCLK停止でSMCLK/ACLKは動作、LPM3は高速クロックを止め32kHzのACLKと一部周辺だけ生かす最も実用的な省電力モード（数µA級）、LPM4は全クロック停止で外部割り込みのみ復帰、LPM3.5/4.5はさらに電源を落とす超低電力モードです。基本はLPM3で待機します。 ** FRAM品は何が違いますか？ MSP430FRシリーズは不揮発メモリFRAMを採用し、フラッシュより書き込みが速く低電力で書き換え回数も桁違いに多いです。データロガーや頻繁な設定保存に最適で、`__persistent` で変数を不揮発化できます。 ** UART・I2C・SPIはどう実装しますか？ eUSCIを使います。eUSCI_AがUART/SPI、eUSCI_BがI2C/SPIに対応し、Code Composer StudioとDriverLib（MSP430Ware）のAPIで実装できます。ボーレートはTIのCalculatorで算出します。 ** STM32・RL78とどう使い分けますか？ MSP430は超低消費電力とFRAMが強みで電池駆動機器に最適です。高性能やARMエコシステムが必要なら [STM32](https://technosphere.co.jp/blog/stm32-low-power-battery)、国内量産・日本語情報重視なら [RL78](https://technosphere.co.jp/blog/renesas-rl78-peripheral-guide) が選択肢です。 ## 次に読む｜マイコン記事 - [TI シリーズ TI C2000 モーター制御入門 リアルタイム制御マイコンでモーターを回す](https://technosphere.co.jp/blog/ti-c2000-motor-control) - [STM32 シリーズ STM32 低消費電力モード完全ガイド ARM系での電池駆動設計と比較に](https://technosphere.co.jp/blog/stm32-low-power-battery) - [Renesas シリーズ RL78 ペリフェラル実装ガイド 国内量産に強い16bit低消費電力マイコン](https://technosphere.co.jp/blog/renesas-rl78-peripheral-guide) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # 東芝マイコン移行ガイド｜TLCS-870/900のEOL対策とTXZ・現行マイコンへのリプレース｜株式会社テクノスフィア > 東芝の旧マイコン TLCS-870（8bit）・TLCS-900（16/32bit）EOL 対策を解説。コード紛失・専用アセンブラ・周辺差異の壁と、TXZ（Cortex-M）・STM32・RL78 への移植ノウハウを公開。 URL: https://technosphere.co.jp/blog/toshiba-mcu-migration-guide ** 目次 1. はじめに：東芝マイコンの現状 2. 東芝マイコンの系譜（TLCS / TX / TXZ） 3. 移行が必要になる背景 4. 東芝マイコン移行の壁 5. 移行先の選定 6. 移行プロジェクトの進め方 7. まとめ ## はじめに：東芝マイコンの現状 東芝（現・東芝デバイス＆ストレージ）のマイコンは、**TLCS-870**（8bit）・**TLCS-900**（16/32bit）といった独自アーキテクチャの世代から、現在はARM Cortex-Mベースの**TXZファミリ**へと移行しています。旧TLCS系は家電・産業機器・OA機器に幅広く採用されましたが、多くが**生産終了（EOL）**となり、それらを搭載した製品・設備の保守や再生産が課題になっています。 本記事では、東芝の旧マイコンを搭載した製品を現行マイコンへ移行・再生するための判断材料と進め方を、レガシー再構築の実務目線で解説します。 ** テクノスフィアのレガシー再生実績 テクノスフィアは、ソース・資料が失われた組込み機器の [逆アセンブル・再構築](https://technosphere.co.jp/blog/renesas-rl78-reverse-engineering) を手がけています。東芝を含む旧世代マイコンから現行品への移行も [受託開発](https://technosphere.co.jp/embedded-achievements) で対応しています。 ## 東芝マイコンの系譜（TLCS / TX / TXZ） | 世代 | アーキテクチャ | 位置づけ | | **TLCS-870 / TLCS-90** | 東芝独自 8bit | 家電・小型機器の制御。大量採用された定番 | | **TLCS-900 / 900H / 900L** | 東芝独自 16/32bit | OA機器・産業機器・高機能制御 | | **TX03 / TX04 (TMPM)** | ARM Cortex-M3/M4 | ARM移行世代 | | **TXZ (TXZ+) ファミリ** | ARM Cortex-M | 現行。モーター制御・汎用 | 東芝はマイコン事業を独自アーキのTLCSから**ARM Cortex-MのTXZ**へ移行済みです。そのため旧TLCS製品は、TXZへの移行か、あるいは他社のARM/汎用マイコンへの移行が現実的な選択肢になります。 ## 移行が必要になる背景 - **デバイスの生産終了**：TLCS系の多くがEOL。在庫枯渇・価格高騰・調達難 - **開発環境の老朽化**：TLCS専用アセンブラ・旧Cコンパイラ・旧IDEが最新環境で動かない - **独自アーキの属人化**：TLCS固有の知識を持つ技術者が減少 - **機能・規格対応**：新しい通信規格・安全規格への対応が旧機では困難 ## 東芝マイコン移行の壁 ** 移行を難しくする要因 1. **独自命令体系**：TLCS-870/900は東芝独自のアセンブリ。ARMやRXとは命令・レジスタ構成が大きく異なる 2. **ソース・資料の欠落**：ソース、専用アセンブラ環境、仕様書が揃わない 3. **周辺レジスタの差異**：タイマ・シリアル・ADCのレジスタ構成や挙動が現行品と異なる 4. **8bit→32bitのギャップ**：データ型サイズ・エンディアン・メモリマップの違いを吸収する必要がある 独自アーキであるがゆえ、ARM系のように共通知識が通用しにくいのが東芝旧マイコンの難しさです。ソースが無くROMだけが残るケースでは、逆アセンブルと実機解析による仕様復元が出発点になります。 ## 移行先の選定 | 移行先 | 相性 | ポイント | | **東芝 TXZ（ARM）** | ○ 同一ベンダー継続 | 東芝デバイスで揃えたい場合。ARM Cortex-Mで現代的な開発が可能 | | **STM32（ARM）** | ◎ 汎用・調達性 | 情報量・サードパーティ資産・調達性に優れる。[STM32実装ガイド](https://technosphere.co.jp/blog/stm32-uart-i2c-can) | | **ルネサス RL78** | ○ 8bit置換・国内量産 | TLCS-870クラスの小規模制御を低コストで。[RL78ガイド](https://technosphere.co.jp/blog/renesas-rl78-peripheral-guide) | | **ルネサス RX** | ○ 16/32bit置換 | TLCS-900クラスの高機能制御に。[RX入門](https://technosphere.co.jp/blog/renesas-rx-introduction) | 8bitのTLCS-870クラスはRL78やSTM32の下位品種、16/32bitのTLCS-900クラスはSTM32の中位品種やRXへ移行するのが一般的です。調達性・情報量を重視するなら**STM32**、国内量産・低コストを重視するなら**RL78**が有力な候補です。 移行元のファミリから移行先候補と工数を押し上げる要因を逆引きできる [マイコン移行判断ナビ](https://technosphere.co.jp/mcu-migration#tlcs-870) を公開しています。他ファミリとの比較にもお使いください。 ## 移行プロジェクトの進め方 ** 標準的な移行ステップ 1. **現状調査**：残存資産（ソース・ROM・回路図・実機）の棚卸し 2. **仕様復元**：ソース解析、または逆アセンブル＋実機動作解析で仕様化 3. **移行先選定**：性能・周辺・調達性から現行マイコンを選定 4. **ハード設計**：基板リプレース（端子・電圧・周辺の対応付け） 5. **ソフト再実装**：独自アセンブリ部分をC言語で再構築、周辺ドライバを置換 6. **等価性検証**：旧機と新機の入出力・タイミングを突き合わせて検証 7. **量産移行**：信頼性試験を経て量産へ 独自アーキからの移行はリスクが読みにくいため、**まず現状調査と一部機能のPoC**から始め、復元できる範囲と工数を見極めてから本格移行に進むのが安全です。 ## まとめ ### この記事のまとめ - 東芝の旧マイコン（TLCS-870/900）は多くがEOLとなり、製品保守・再生産の課題が顕在化している - 東芝はARM Cortex-MのTXZへ移行済み。旧TLCS製品はTXZか他社現行マイコンへの移行が現実的 - 独自命令体系・ソース欠落・周辺差異・8bit→32bitギャップが移行の壁 - 移行先は調達性重視ならSTM32、国内量産・低コストならRL78、高機能ならRXが候補 - ソースが無くても、実機とROMがあれば逆アセンブルで仕様復元して移植できる 東芝マイコンを搭載した設備・製品の移行や再生でお困りでしたら、テクノスフィアにお気軽にご相談ください。独自アーキ・ソース紛失の状況からでも、現行マイコンへの移行プランをご提案します。 TLCS-870/900 基板の逆アセンブル・仕様復元、STM32/RL78/RX への移植・量産まで [組込み制御・マイコン開発](https://technosphere.co.jp/embedded) として対応しています。 ／レガシーマイコンの移行・再生のご相談はこちら＼ ### 東芝マイコンからの移行・レガシー再生 生産終了したTLCS-870/900搭載基板を、逆アセンブルによる仕様復元から現行マイコン（STM32 / RL78 / RX 等）への移植・量産まで一気通貫で対応します。独自アーキ・ソース紛失でもご相談ください。 [組込み開発サービスを見る](https://technosphere.co.jp/embedded) [TLCS→現行マイコン移植相談](https://technosphere.co.jp/contact) ## よくある質問（FAQ） ** 東芝TLCSマイコンの移行先には何を選べばよいですか？ 東芝で継続するならARM Cortex-MのTXZ、ベンダー不問ならSTM32やRL78が広く使われ調達性・情報量で有利です。8bitのTLCS-870なら小規模RL78/STM32下位品種、16/32bitのTLCS-900ならSTM32中位品種やRXへの移行が一般的です。 ** 専用アセンブラのコードしか残っていなくても移行できますか？ 可能です。TLCS固有のアセンブリやROMから逆アセンブル・動作解析で仕様を復元し、C言語で現行マイコンへ再実装します。ソース・資料欠落状態からの再構築実績があります。 ** 移行で注意すべき点は？ TLCS固有の命令体系・アセンブリ、独自の周辺レジスタ構成、タイマ/シリアル/ADCの挙動差です。8bit→32bit ARMではデータ型サイズやエンディアンの違いにも注意し、タイミング依存処理は実機計測で等価動作を確認します。 ** なぜ移行が必要になっているのですか？ TLCS-870/900など旧世代品の多くが生産終了・非推奨となり供給リスクが顕在化しているためです。東芝自身もマイコン事業をARMベースのTXZへ移しており、旧アーキ製品は現行マイコンへの移行が現実的です。 ## 次に読む｜マイコン記事 - [レガシー再生 RL78 逆アセンブル・再構築 ソース紛失基板の復元事例](https://technosphere.co.jp/blog/renesas-rl78-reverse-engineering) - [レガシー移行 SH（SuperH）移行ガイド 旧日立・ルネサス系の移行](https://technosphere.co.jp/blog/superh-sh-migration-guide) - [移行先候補 STM32 UART・I2C・SPI・CAN 実装ガイド 汎用ARMマイコンの実装](https://technosphere.co.jp/blog/stm32-uart-i2c-can) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # H8マイコンとは？いまも現場で動き続ける理由と、保守・移行の判断ポイント｜株式会社テクノスフィア > 日立製作所発祥のH8マイコン（H8/300H・H8S・H8SX）の基礎知識と2026年時点の現状を整理。ルネサス公式サイトでの製品ステータス確認手順、HEW・E8aなど開発環境の入手性、「維持か移行か」の判断フロー、RL78/RX/RAへの移行の考え方を、組込み開発歴20年超のエンジニアが在籍するテクノスフィアが解説。 URL: https://technosphere.co.jp/blog/what-is-h8-microcontroller ** 目次 1. H8マイコンとは 2. なぜ2026年でも現場に残っているのか 3. H8の現状：デバイス供給と開発環境 4. H8保守の現場でよくある課題 5. 「維持」か「移行」かの判断フロー 6. 移行先の選択肢と難易度 7. まとめ ## H8マイコンとは **H8**は、日立製作所が開発した組込みマイコンのファミリ名です。半導体事業の再編により、2003年に日立と三菱電機の半導体部門を統合して発足したルネサス テクノロジへ、2010年からはNECエレクトロニクスとの経営統合で発足した現在のルネサス エレクトロニクスへと引き継がれました。「旧日立のH8」と呼ばれるのはこの経緯によるものです。 ファミリ内には複数の世代・シリーズがあり、8/16ビットのH8/300から、16/32ビットの**H8/300H・H8S**、32ビット拡張の**H8SX**まで幅広く展開されました。小ピン・低コスト向けの**H8/Tiny**シリーズも家電や小型機器で広く使われています。 | シリーズ | 位置づけ | 主な採用領域 | | **H8/300** | 8/16ビット、小規模・低コスト | 家電、小型機器 | | **H8/Tiny（H8/300H Tiny）** | H8/300Hコアの小ピン・低コスト版 | 家電、小型機器、センサー制御 | | **H8/300H** | 16/32ビット。アドバンストモードで最大16MBのリニア空間 | 産業機器・計測機器の定番 | | **H8S** | H8/300H上位互換の高速・高機能版 | OA機器、FA制御、高機能組込み | | **H8SX** | 32ビット拡張・高性能 | 大規模制御、通信機器 | 1990年代から2000年代にかけて、H8は**産業機器・計測機器・FA制御・家電・OA機器**など幅広い分野で採用され、国内の組込み開発では「定番中の定番」の地位を占めました。大学や高専のマイコン教育、ロボコン用ボードにも多用されたため、「マイコンといえばH8だった」という世代のエンジニアも多いはずです。素直な命令セット（汎用レジスタ構成のCISC）、豊富な内蔵ペリフェラル（タイマ、SCI、A/D変換器など）、そして日本語ドキュメントの充実が、その普及を支えました。 なお、H8は**ビッグエンディアン**のアーキテクチャです。現行の主流マイコン（Arm系やRL78など、通常リトルエンディアンで運用されるもの）へ移行する際に必ず論点になるため、まず押さえておきたい特徴です。 ## なぜ2026年でも現場に残っているのか 新規のデバイス選定でH8が選ばれることはまずありません。それでも、弊社への保守・移行のご相談は年々増えています。理由はシンプルで、**H8を搭載した機器のライフサイクルが、マイコンの製品ライフサイクルよりはるかに長い**からです。 ### 1. 産業機器の寿命は20〜30年 製造装置・計測機器・プラント設備・業務用機器は、20〜30年使われることが珍しくありません。2000年前後に設計されてH8を搭載した装置は、機械としてはまだ現役です。装置全体を更新するには数千万円〜億単位の投資が必要になるため、「制御基板だけなんとかしたい」という需要が生まれます。 ### 2. 「動いているものは触らない」の合理性 長年安定稼働している制御ソフトには、現場調整の積み重ねやタイミング依存の暗黙仕様が詰まっています。マイコンを置き換えれば、それらをすべて検証し直すことになります。「動いているものは触らない」は思考停止ではなく、**検証コストとリスクを織り込んだ合理的な判断**である場合が多いのです。 ### 3. 置き換えコストは「移植」だけでは済まない マイコン変更は、ソフト移植に加えて基板再設計・部品再選定・信頼性試験・（分野によっては）認証再取得まで波及します。特に医療機器や防爆機器など認証が絡む分野では、マイコン変更のコストが本体価格を上回ることすらあり、延命が優先されがちです。 こうして「延命し続けてきたH8機器」が、いよいよデバイス供給と開発環境の両面で限界を迎えつつある――というのが2026年の状況です。 ## H8の現状：デバイス供給と開発環境 ここが本記事の核心です。まず大前提として、**「H8はすべて生産終了」といった一括りの断定は正確ではありません**。ルネサスの製品ステータスは型番（グループ）ごとに管理・表示されており、確認は必ず個別に行う必要があります。そのうえで、ファミリ全体の方向性としては次の公式情報が出ています。 ** ルネサス公式の見解（一次情報） - ルネサス公式ブログ（2022年12月）は、**H8シリーズのシリコンデバイスは非推奨（non-promoted）製品となり、新規受注を受け付けていない**と明言し、シリコンの代替としてRXファミリを推奨しています - 個別製品ページでは型番ごとにステータスが表示されます。例えばH8/3048グループは「Not Recommended for New Designs（新規設計非推奨）」で、**既存採用顧客向けのサポートに限定**、新規設計にはRL78/G14グループが推奨と記載されています - 一方、**H8S CPUコアはASIC向けIP**としては現在も提供が継続されています。「H8がこの世から消えた」わけではありません ### 製品ステータスの確認手順（実務） お手元の機器に載っているH8の状態は、次の手順で確認できます。 1. **基板上の刻印から型名を特定する**：H8のフラッシュ内蔵品は「HD64F3048…」のように HD64F で始まる型名が刻印されていることが多く、そこからグループ（この例ではH8/3048）を特定できます 2. **renesas.com で型番・グループ名を検索する**：製品ページ上部にライフサイクル表示（「Not Recommended for New Designs」等）と、既存顧客向けサポート・推奨代替品の案内が表示されます 3. **調達可否は代理店に確認する**：ページ表記と実際の受注可否・流通在庫・最終受注（LTB: Last Time Buy）の扱いは別問題です。正規代理店経由で必ず確認します 4. **PCN/EOL通知を確認する**：生産中止・仕様変更はPCN（Product Change Notice）やTool Newsとして通知されます。該当型番の通知が出ていないか、代理店またはルネサスサポート経由で確認します ** 二次市場（ブローカー品）の注意 受注終了品でも二次市場に在庫が出回ることがありますが、**偽造品・リマーク品・保管状態不明品のリスク**が伴います。長期保守部品として調達する場合は、来歴の確認や受入検査（外観・電気特性・場合によってはX線）を前提にしてください。 ### 開発環境（ツールチェーン）の現状 デバイス以上に見落とされがちなのが、開発環境の入手性です。執筆時点（2026年7月）でルネサス公式サイトから確認できる状況を整理します。 | ツール | 状況（ルネサス公式サイトでの確認結果） | | **HEW** （High-performance Embedded Workshop） | H8用の統合開発環境。最終版はV.4.09.01（2012年）で更新終了。後継IDEのCS+・e² studioのサポート対象ファミリにH8は含まれず、**H8開発は現在もHEWが前提**。ルネサスのWindows 11互換性ページではV.4.09.01で「動作確認済み（制限あり）」と記載 | | **H8SX,H8S,H8ファミリ用 C/C++コンパイラパッケージ** | 最終版はV.7.00（2009年）。執筆時点で製品ページ・ダウンロード提供が公式サイトに残っており、評価版も案内されている。Windows 11互換性ページではV.7.00 R00で「動作確認済み（制限あり）」と記載。**入手可否は変わり得るため、着手前にルネサス公式で要確認** | | **E8aエミュレータ** （デバッガ／フラッシュライタ） | EOL通知（Tool News R20TS0986、2024年）により**2024年12月31日で受注終了**。修理対応は2027年12月まで（部品都合で修理不可の場合あり）。**後継機なし**。フラッシュ書き込みについては一部デバイスがPG-FP6でサポートされる | | **フラッシュ書き込みソフト** | H8系の書き込みは従来Flash Development Toolkit（FDT）＋E8a等の組み合わせが定番。手持ち資産の動作環境維持が実務上の生命線になる（対応状況は型番ごとにルネサス公式で要確認） | まとめると、**ソフトウェアツールは「更新は止まっているが当面入手・動作可能」、ハードウェアツール（E8a）は「新品調達がすでに不可能」**というのが現在地です。手持ちのE8aが故障した時点でデバッグ・書き込み手段を失う現場は少なくなく、これが移行判断の引き金になるケースが増えています。 ## H8保守の現場でよくある課題 弊社にご相談いただくH8案件で、実際によく直面する課題を挙げます。 ### 1. 開発環境が動くPCの維持 前述のとおり最新版のHEW＋コンパイラはWindows 11でも動作確認済みとされていますが、現場に残っているのは**もっと古いバージョンのHEWや、当時のライセンス・USBドングル・E8a/E10A用ドライバ**であることが多く、「この開発一式はWindows XPのこのPCでしか動かない」という状態が典型です。対策としては、①最新版HEW/コンパイラへの環境再構築を試みる、②既存環境を仮想マシン（VM）化して保全する、の二段構えが現実的です。VM化しても、エミュレータのUSB接続はホスト・仮想化ソフトとの相性問題が残るため、実機での書き込み・デバッグ手順は必ず検証しておきます。 ### 2. 設計資料の散逸・担当者の退職 「ソースはあるがビルドが通らない」「最終出荷版とソースのリビジョンが一致しない」「回路図が紙しかない」「仕様を知る担当者が退職した」――20年選手の機器では日常茶飯事です。最悪、**実機とROMデータしか残っていない**こともありますが、その場合でも逆アセンブルと実機動作解析による仕様復元は可能です（[レガシー再構築の事例](https://technosphere.co.jp/blog/renesas-rl78-reverse-engineering)）。重要なのは、資産が揃っているうちに**棚卸しとリビルド検証だけでも先にやっておく**ことです。 ### 3. 部品調達（マイコン以外も） マイコン本体だけでなく、周辺のドライバIC・メモリ・コネクタ類も同世代でEOLが進んでいます。「H8はまだ在庫があるのに、周辺ICが先に手に入らなくなって基板が作れない」というパターンも多く、**基板単位での部品リスク評価**が必要です。 ## 「維持」か「移行」かの判断フロー H8機器の扱いは、感覚ではなく**「①製品をあと何年生産・保守するか」×「②供給リスク」×「③機能追加の要否」**の3軸で判断することをおすすめしています。 | 状況 | 推奨方針 | 具体的なアクション | | 生産・保守の残り期間が**おおむね5年未満**で、機能追加の予定なし | **維持（計画的延命）** | 必要数＋補修分のデバイス・基板在庫を確保／開発環境をVM化して保全／E8a等ツールの予備確保／資産の棚卸しとリビルド検証 | | 残り期間が**5〜10年**、または供給・ツールに不安がある | **維持しつつ移行準備** | 仕様の文書化（必要なら逆アセンブルで復元）／移行先マイコンの選定と一部機能のPoC／移行工数の見積もり取得 | | 残り期間が**10年以上**、または機能追加・法規制対応・通信機能追加などが見込まれる | **計画的移行** | 現行マイコンへのリプレース計画を立案。旧機との等価性検証を含めた移行プロジェクトとして推進 | 判断の際は、次の点も併せて評価します。 - **供給リスクの実態**：対象型番のステータス・代理店在庫・PCN/EOL通知（前章の手順で確認）。マイコン以外の周辺部品も含めて基板単位で評価する - **ツールリスク**：手持ちのE8a・書き込み環境が故障した場合の代替手段があるか。無いなら「維持」でも予備確保が必須 - **人的リスク**：H8・HEWを扱える要員が社内に何人残っているか。ゼロになってからの移行は難易度が跳ね上がる ** 実務のコツ：維持と移行は二者択一ではない もっとも危険なのは「何も決めずに使い続ける」ことです。維持を選ぶ場合も、**在庫確保・環境保全・仕様文書化**までをセットで行えば、将来の移行コストを大きく下げられます。逆に移行を選ぶ場合も、全機能一括ではなく**一部機能のPoCから始める**ことでリスクを抑えられます。 ## 移行先の選択肢と難易度 移行を選ぶ場合の移行先は、同じルネサス内の現行ファミリが第一候補です。ルネサス公式も、H8の代替としてRL78（例：H8/3048ページではRL78/G14を案内）やRXファミリを推奨しています。 | 移行先 | 相性の良いH8 | ポイント | | **ルネサス RL78**（16ビット） | H8/Tiny、小規模なH8/300H | 低消費電力・低コスト。小規模制御の置き換え定番。[RL78ペリフェラル実装ガイド](https://technosphere.co.jp/blog/renesas-rl78-peripheral-guide)参照 | | **ルネサス RX**（32ビット CISC） | H8/300H上位、H8S、H8SX | ルネサス公式ブログがH8シリコンの代替として推奨。CISCでH8経験者になじみやすく、性能余裕も大きい。[RX入門](https://technosphere.co.jp/blog/renesas-rx-introduction)参照 | | **ルネサス RA**（Arm Cortex-M） | H8S/H8SXクラス、通信・セキュリティ要件が増える案件 | ルネサス製でありながらArmエコシステム（ミドルウェア・人材・情報量）を使える。新規設計の主流に合わせたい場合に有力 | | **その他Arm系**（STM32等） | 調達戦略・既存資産次第 | マルチソース戦略や社内のArm資産を重視する場合の選択肢 | ### 移行工数は何で決まるか 移行の難易度・工数は、コード行数よりも次の要素で決まります。見積もり時はこの観点でソースを解析します。 - **ペリフェラル依存度**：TPU・8ビットタイマ・SCI・A/DなどH8固有ペリフェラルのレジスタ直叩きがどれだけあるか。移行先と1対1対応しない周辺は再設計になる - **アセンブラ混在率**：起動処理・割り込みベクタ・時間稼ぎループなどのH8アセンブリは全面書き直し - **コンパイラ拡張依存**：旧コンパイラ固有の`#pragma`（割り込み・セクション指定）や組込み関数の使用箇所 - **エンディアン依存**：ビッグエンディアン前提の通信フレーム解釈・共用体・フラッシュ格納データの有無 - **資産の残存度**：ソース・回路図・仕様書が揃っているか。欠落があれば仕様復元の工程が加わる 具体的な移行の壁（エンディアン・周辺差異・#pragma対応）と移行プロジェクトの進め方は、詳細版の [H8/H8S マイコン移行ガイド｜EOL対策とRL78/RXへのリプレース・再生](https://technosphere.co.jp/blog/h8-h8s-migration-guide) で工程ごとに解説しています。移行を具体的に検討する段階の方はこちらをご覧ください。 ## まとめ ### この記事のまとめ - H8は日立発祥・ルネサス継承の16/32ビットマイコンファミリ。産業機器・家電・FA制御で圧倒的に普及し、機器の長寿命ゆえに今も現場で稼働している - 製品ステータスは型番ごとに異なるため一括りの断定は禁物。ただしルネサス公式ブログはH8シリコンの新規受注終了を明言しており、確認は「型番特定→renesas.com検索→代理店確認→PCN/EOL通知確認」の手順で行う - HEW・H8用コンパイラは更新停止ながら当面入手・動作可能。一方E8aエミュレータは2024年末で受注終了・後継なしで、ハードツールの確保が急所 - 「維持か移行か」は、生産継続年数×供給リスク×機能追加要否の3軸で判断する。維持する場合も在庫確保・環境保全・仕様文書化はセットで - 移行先はRL78・RX・RA（＋Arm系）。工数はペリフェラル依存度・アセンブラ混在率・エンディアン依存などで決まる H8搭載機器の延命・保守から現行マイコンへの移行まで、状況の棚卸しからお手伝いします。テクノスフィアの[組込み開発実績](https://technosphere.co.jp/embedded-achievements)には、レガシーマイコンの再生・移植案件も含まれています。まずは現状調査からお気軽にご相談ください。 H8基板の現状調査・開発環境の再構築（VM保全）・逆アセンブルによる仕様復元・現行マイコンへの移植まで [組込み制御・マイコン開発](https://technosphere.co.jp/embedded) として対応しています。 ／H8機器の保守・移行のご相談はこちら＼ ### H8マイコン機器の延命・移行支援 「維持か移行か」を判断するための現状調査（資産棚卸し・供給リスク評価・リビルド検証）から、開発環境の保全、RL78/RX/RA等への移植・量産まで一気通貫で対応します。ソース紛失・担当者退職の状態からでもご相談いただけます。 [組込み開発サービスを見る](https://technosphere.co.jp/embedded) [H8保守・移行の相談](https://technosphere.co.jp/contact) ## よくある質問（FAQ） ** H8マイコンは今でも新品を購入できますか？ ルネサスは2022年12月の公式ブログで、H8シリーズのシリコンデバイスは非推奨（non-promoted）製品となり新規受注を受け付けていないと明言しています。製品ページのステータス表記は型番ごとに異なるため、renesas.comで型番を検索してライフサイクル表示を確認し、実際の調達可否（流通在庫・最終受注の扱い）は正規代理店に確認するのが確実です。 ** H8の開発環境（HEW・コンパイラ・エミュレータ）はまだ使えますか？ HEWは最終版V.4.09.01（2012年）、H8用C/C++コンパイラは最終版V.7.00（2009年）で更新が止まっていますが、執筆時点ではルネサス公式サイトに製品ページが残っており、Windows 11互換性ページでは両者とも動作確認済み（制限あり）と記載されています。一方、E8aエミュレータは2024年12月末で受注終了・後継なし（修理対応は2027年12月まで）で、ハードウェアツールの確保が課題です。 ** 「維持」と「移行」はどう判断すればよいですか？ 「製品をあと何年生産・保守するか」「デバイス・ツールの供給リスク」「機能追加の要否」の3軸で判断します。残存期間が短く機能凍結できるなら在庫確保＋環境保全による維持が合理的、10年以上の継続や機能追加が見込まれるなら計画的移行をおすすめします。詳しくは本文の判断フローをご覧ください。 ** H8からの移行先には何を選べばよいですか？ 同じルネサスのRL78（小規模）・RX（H8S/H8SXクラスの高機能制御）・RA（Arm Cortex-M）が第一候補です。ルネサス公式もRL78/G14やRXを代替として案内しています。具体的な移行の壁と進め方は[H8/H8S マイコン移行ガイド](https://technosphere.co.jp/blog/h8-h8s-migration-guide)で解説しています。 ** ソースコードや設計資料が残っていなくても保守・移行できますか？ 可能です。実機とROMデータ（mot/hex/bin）が残っていれば、逆アセンブルと実機動作解析で仕様を復元し、現行マイコンへ再実装できます。テクノスフィアではソース・回路図が欠落した状態からのレガシー再構築実績があります。 # H8 # H8S # H8SX # ルネサス # 旧日立 # レガシー保守 # EOL対策 # HEW # マイコン ## 次に読む｜レガシーマイコン関連記事 - [詳細版・移行ガイド H8/H8S マイコン移行ガイド｜EOL対策とRL78/RXへのリプレース・再生 移行の壁（エンディアン・周辺差異）と工程を詳説](https://technosphere.co.jp/blog/h8-h8s-migration-guide) - [移行先候補 ルネサス RX 入門 H8S/H8SXクラスの第一移行先](https://technosphere.co.jp/blog/renesas-rx-introduction) - [移行先候補 RL78 ペリフェラル実装ガイド 小規模H8/H8 Tinyからの移行先](https://technosphere.co.jp/blog/renesas-rl78-peripheral-guide) - [開発実績 組込み制御・マイコン開発 実績紹介 レガシー再生を含む多数の受託開発事例](https://technosphere.co.jp/embedded-achievements) [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # RAGチャットボットとは？仕組みと作り方を図解でやさしく解説【2026年最新】｜テクノスフィア > RAGチャットボットとは何かを5分で理解。RAG（検索拡張生成）の仕組み、ChatGPT単体との違い、LangChain・ベクトルDBを使った作り方、自社開発と外注の判断基準まで図解で解説。社内ヘルプデスクの問い合わせ対応を60%削減した実例つき。 URL: https://technosphere.co.jp/blog/what-is-rag-chatbot ** 目次 1. RAGとは何か（Retrieval-Augmented Generation） 2. 従来のチャットボットとの違い 3. ChatGPTとRAGの違い・関係 4. RAGの仕組み（検索 → 取得 → 生成） 5. RAGチャットボットのメリット5つ 6. 導入に必要な技術スタック 7. テクノスフィアでの導入事例 8. 導入ステップ 9. 自社開発と外部委託、どちらを選ぶべきか 10. よくある失敗と対策 11. よくある質問（FAQ） 12. まとめ 「**RAGチャットボットとは**何か？」という疑問をお持ちの方に向けて、本記事ではRAG（Retrieval-Augmented Generation：検索拡張生成）の仕組みから、従来のチャットボットとの違い、導入メリット、必要な技術スタック、そして具体的な導入ステップまでを体系的に解説します。 ChatGPTの登場以降、企業でのAI活用が急速に広がっていますが、「自社の情報を正確に回答させたい」「社外秘データを安全に扱いたい」というニーズに応えるのがRAG技術です。 ## RAGとは何か（Retrieval-Augmented Generation） RAG（Retrieval-Augmented Generation）とは、日本語で「**検索拡張生成**」と訳される技術で、外部の知識ソース（社内文書・マニュアル・FAQ等）から関連情報を検索・取得し、その情報をもとにLLM（大規模言語モデル）が回答を生成する仕組みです。 2020年にMeta（旧Facebook）の研究チームが発表した論文で提唱された概念で、LLM単体の課題であった「ハルシネーション（事実と異なる回答の生成）」や「学習データの陳腐化」を解決するアプローチとして注目されています。 ** ポイント RAGの最大の特長は、**LLMの再学習（ファインチューニング）が不要**な点です。社内文書をベクトルデータベースに格納するだけで、自社専用の知識を持ったAIを構築できます。文書を更新すればAIの回答も自動的に最新化されます。 ## 従来のチャットボットとの違い RAGチャットボットと従来型のチャットボットは、技術的なアプローチが根本的に異なります。以下の比較表で主な違いを整理します。 | 比較項目 | ルールベース型 | LLM単体（ChatGPT等） | RAGチャットボット | | **回答方式** | 事前登録のQ&Aから選択 | 学習済みデータから生成 | 社内文書を検索し生成 | | **対応範囲** | 登録済みパターンのみ | 汎用的だが自社情報は不正確 | 自社データに基づき柔軟に対応 | | **情報の鮮度** | 手動更新が必要 | 学習時点で固定 | 文書更新で自動的に最新化 | | **導入・運用コスト** | Q&A作成に工数がかかる | 低コストだが精度に課題 | 既存文書を活用でき効率的 | | **セキュリティ** | 社内環境で完結可能 | 外部APIにデータ送信 | オンプレミス構成も可能 | 従来のルールベース型チャットボットは、想定外の質問に対応できない点が大きな課題でした。一方、ChatGPTなどの汎用LLMは柔軟に回答できますが、自社の情報は持っていないため不正確な回答を生成するリスクがあります。RAGチャットボットは、**両者の長所を組み合わせた「いいとこ取り」**のアプローチです。 ## ChatGPTとRAGの違い・関係 「**ChatGPTのRAGとは？**」「ChatGPTとRAGは何が違うのか？」という質問をよくいただきます。結論から言うと、**ChatGPTはLLM（回答を生成するAI）であり、RAGはそのLLMに自社の知識を与えるための仕組み**です。両者は対立する技術ではなく、組み合わせて使うものです。 ### ChatGPT単体とRAG構成の違い ChatGPTに社内のことを質問しても、学習データに含まれていない自社の規程や製品仕様には答えられず、もっともらしい誤答（ハルシネーション）を返すことがあります。RAG構成では、質問のたびに社内文書から関連箇所を検索してChatGPT（GPT-4oなどのLLM）に渡すため、**自社の情報に基づいた正確な回答**が得られます。 ### ChatGPTのファイル添付・GPTsとの違い ChatGPTにもファイル添付やGPTs（カスタムGPT）でドキュメントを参照させる機能がありますが、扱える文書量・アクセス権限の管理・社外秘データの取り扱いに制約があります。数百〜数千ページ規模の社内文書を、**部署ごとの権限管理やオンプレミス運用込み**で扱いたい場合は、RAGチャットボットとして構築するのが現実的です。 ### ChatGPTでRAGを実現する3つの方法 「ChatGPTでRAGをやりたい」と言ったとき、実際には難易度もコストも異なる3つの選択肢があります。**どれを選ぶかで、扱える文書量・権限管理の自由度・月額費用が大きく変わります**。 | 方法 | 実装の手間 | 向いているケース | 主な制約 | | **GPTs（カスタムGPT）に ナレッジを持たせる** | ノーコード （数十分） | 少数の文書を、ChatGPTを契約している社内メンバーだけで使う | アップロードできる文書数・容量に上限がある。閲覧権限を文書単位で分けられない | | **API のファイル検索機能 を使う** | 軽い開発 （数日〜） | 自社アプリやチャットツールに組み込みたい | 検索の挙動を細かく制御しにくい。データはOpenAI側に置かれる | | **ベクトルDBを用意して 自前で組む** | 本格開発 （数週間〜） | 大量文書・部署別権限・オンプレミス運用が必要 | 設計と運用の負荷が高い。精度改善に継続的な調整が要る | 上の2つは「ChatGPTの機能としてのRAG」、3つ目は「**RAGという仕組みを自社システムとして構築する**」という違いがあります。検索結果で「RAG」と呼ばれているものが、どちらを指しているかは文脈によって異なります。 ** 補足 各サービスの上限値・料金体系は改定が頻繁です。導入判断の際は必ず提供元の公式ドキュメントで最新の条件をご確認ください。本記事では、改定の影響を受けにくい**構成上の違い**を中心に整理しています。 ### ChatGPT Enterprise があればRAGは不要？ よくいただく質問ですが、答えは**「用途による」**です。ChatGPTの上位プランは、入力データを学習に使わないなど企業利用向けの配慮がありますが、これは**「データの取り扱い」の話であって、「自社文書を検索して答える」機能とは別の論点**です。 数千ページ規模の規程類を、部署ごとの閲覧権限を守りながら、基幹システムの情報と突き合わせて回答させる——といった要件になると、上位プランを契約していても**RAGチャットボットとしての設計・構築が必要**になります。 ** 使い分けの目安 個人の調べものや一般知識の質問は **ChatGPT単体**で十分。少数の文書を手軽に参照させたいだけなら **GPTs**。「自社の文書に基づいて答えるAI」を、権限管理込みで業務システムとして社内に提供したい場合は **RAGチャットボットを構築**する、と考えると分かりやすいです。 ## RAGの仕組み（検索 → 取得 → 生成） RAGチャットボットは、大きく分けて「**データ準備フェーズ**」と「**質問応答フェーズ**」の2段階で動作します。 ### データ準備フェーズ（事前処理） 1. **文書の収集**：社内マニュアル、FAQ、規程類、議事録などの文書を収集 2. **チャンク分割**：文書を適切なサイズ（通常500〜1000文字程度）に分割 3. **ベクトル化（Embedding）**：各チャンクをAIモデルで数値ベクトルに変換 4. **ベクトルDBに格納**：変換したベクトルをデータベースに保存 ### 質問応答フェーズ（リアルタイム処理） RAGの3ステップ：** 1. **Retrieval（検索）** ユーザーの質問文をベクトル化し、ベクトルデータベースから意味的に類似した文書チャンクを検索します。キーワード一致ではなく「意味の近さ」で検索するため、表現が異なっていても関連情報を取得できます。 2. **Augmented（補強）** 検索で取得した文書チャンク（通常3〜5件）を、LLMへのプロンプトにコンテキストとして追加します。「以下の社内資料を参考に回答してください」という指示とともにLLMに渡します。 3. **Generation（生成）** LLMがコンテキスト情報を踏まえて、自然な日本語で回答を生成します。回答の根拠となった文書名や該当箇所を併記することで、信頼性を担保できます。 ** ポイント RAGの検索精度を左右する重要な要素は「**チャンク分割の粒度**」と「**Embeddingモデルの選定**」です。チャンクが大きすぎるとノイズが増え、小さすぎると文脈が失われます。弊社では案件ごとに最適なパラメータをチューニングしています。 ## RAGチャットボットのメリット5つ RAGチャットボットを導入することで、企業は以下の5つのメリットを得られます。 ### 1. 既存の社内文書をそのまま活用できる PDF、Word、Excel、PowerPointなど、すでに社内にある文書をそのままAIの知識源として活用できます。Q&Aを一から作成する必要がなく、**導入の初期コストを大幅に削減**できます。 ### 2. 回答精度が高く、ハルシネーションを抑制できる LLM単体では「もっともらしいが事実と異なる回答」を生成するリスクがありますが、RAGでは実際の社内文書を参照して回答するため、**ハルシネーション（幻覚）を大幅に抑制**できます。回答の出典を明示することも可能です。 ### 3. 情報の鮮度を常に最新に保てる ファインチューニングではモデルの再学習が必要ですが、RAGでは**ベクトルDBの文書を更新・追加するだけでAIの回答が自動的に最新化**されます。人事規程の改訂や新製品マニュアルの追加もリアルタイムで反映できます。 ### 4. セキュリティを確保できる ChatGPTなどの汎用AIに社内情報を入力することへのセキュリティ懸念は多くの企業が抱えています。RAGチャットボットは**オンプレミス環境やプライベートクラウドでの構築が可能**なため、社外秘情報を外部に送信せずに運用できます。 ### 5. 導入・運用コストが低い ファインチューニングと比較すると、RAGは**GPUコストやモデル管理の負担が大幅に少ない**のが特長です。既存のLLM APIを活用しつつ、自社データで回答を補強する構成のため、スモールスタートが可能です。 ** コスト比較の目安 - ファインチューニング：初期費用 数百万円〜、再学習のたびに追加コスト - RAG：初期費用 数十万円〜、文書更新は運用コストのみ ## 導入に必要な技術スタック RAGチャットボットを構築するために必要な主要コンポーネントを解説します。 | コンポーネント | 役割 | 代表的なツール・サービス | | **オーケストレーション** | RAGパイプライン全体の制御 | LangChain, LlamaIndex, Haystack | | **Embeddingモデル** | 文書・質問のベクトル化 | OpenAI Embeddings, Cohere Embed, intfloat/multilingual-e5 | | **ベクトルDB** | ベクトルデータの保存・検索 | pgvector, Pinecone, Weaviate, Qdrant, ChromaDB | | **LLM（生成モデル）** | 回答の生成 | GPT-4o, Claude, Gemini, Llama 3 | | **バックエンドAPI** | フロントエンドとの連携 | Python / FastAPI, Node.js / Express | | **フロントエンド** | ユーザーインターフェース | React, Next.js, またはSlack/Teams連携 | ### LangChainの役割 LangChainは、RAGパイプラインを構築するためのオープンソースフレームワークです。文書の読み込み・チャンク分割・ベクトル化・検索・LLMへのプロンプト構築といった一連の処理を、**統一的なインターフェース**で実装できます。Python版とTypeScript版があり、豊富なインテグレーションが用意されています。 ### ベクトルDBの選定基準 ベクトルDBの選定は、プロジェクトの要件によって異なります。 - **pgvector**：既存のPostgreSQLに拡張として導入可能。オンプレミス環境に最適 - **Pinecone**：フルマネージド型。スケーラビリティが高くクラウド利用に向いている - **ChromaDB**：軽量でPoCや小規模プロジェクトに最適 ** テクノスフィアの選定方針 弊社では、セキュリティ要件が高い案件には**pgvector（PostgreSQL拡張）**を、クラウドネイティブな案件には**Pinecone**を推奨しています。いずれもLangChainとの連携が容易です。 ## テクノスフィアでの導入事例 弊社では実際にRAGチャットボットの開発・導入を手がけています。代表的な事例として、**製造業の社内ヘルプデスクにRAGチャットボットを導入し、問い合わせ対応時間を約60%削減**した実績があります。 ** 導入効果（製造業・社内ヘルプデスク） - 社内問い合わせ対応時間：**平均17分 → 約7分（約60%削減）** - 情報検索にかかる時間：**平均18分 → 即時回答** - ヘルプデスク担当者の対応件数：**月間300件 → 120件に削減** ### 導入前に抱えていた課題 導入前、社員の方々は次のような問題を抱えていました。 - 社内マニュアルが複数のシステムに分散しており、目的の情報を見つけるのに平均15〜20分かかっていた - 問い合わせが特定の担当者に集中し、業務のボトルネックになっていた - ベテラン社員のノウハウが暗黙知となっており、文書化されていなかった ### 実装アプローチ 既存の社内マニュアル（約500ページ）をそのまま知識源とし、Slack連携のチャットボットとして提供しました。技術スタックは以下の構成です。 - **LangChain**：RAGパイプライン全体のオーケストレーション - **OpenAI Embeddings**：文書のベクトル化（埋め込み表現） - **pgvector（PostgreSQL拡張）**：ベクトルデータベース（社内サーバーで完結） - **GPT-4o**：回答生成モデル - **Python / FastAPI**：バックエンドAPI ベクトルデータベースを社内サーバーに置く構成としたことで、社外秘の文書を外部に送信せずに運用できています。文書を更新・追加するだけで回答が最新化されるため、導入後の運用負荷も抑えられています。 ## 導入ステップ RAGチャットボットの導入は、以下のステップで進めるのが一般的です。 ### Step 1. 要件定義・ヒアリング（1〜2週間） 対象業務の特定、利用者のペルソナ設定、期待する回答品質の定義を行います。「どの文書を知識源にするか」「どのチャネル（Web・Slack・Teams）で提供するか」を明確にします。 ### Step 2. データ整備・PoC（2〜4週間） 対象文書の収集・整理を行い、小規模なPoCを実施します。代表的な質問パターンで回答精度を検証し、チャンクサイズやEmbeddingモデルの最適なパラメータを確定します。 ### Step 3. システム構築・開発（4〜8週間） 本番環境でのRAGパイプライン構築、API開発、フロントエンド（またはSlack/Teams連携）の実装を行います。セキュリティ設定、ログ管理、エラーハンドリングも含めて開発します。 ### Step 4. テスト・チューニング（2〜3週間） 実際の利用者によるテスト運用を実施します。回答精度の評価、プロンプトの調整、検索パラメータのチューニングを繰り返し、品質を向上させます。 ### Step 5. 本番リリース・運用開始 全社展開を行い、利用状況のモニタリングを開始します。回答ログの分析、ユーザーフィードバックの収集、文書の定期的な更新を通じて、継続的に改善していきます。 導入のコツ：** いきなり全社展開するのではなく、**特定の部門・業務に絞ったスモールスタート**を推奨します。成功体験を積み上げてから対象範囲を拡大するアプローチが、社内の合意形成にも効果的です。 ## 自社開発と外部委託、どちらを選ぶべきか LangChainなどのフレームワークが充実してきたことで、RAGチャットボットの「動くデモ」は社内エンジニアでも数日で作れるようになりました。一方で、**業務で使える品質に引き上げる工程（検索精度のチューニング・権限管理・運用設計）には専門的な知見**が必要です。判断の目安を整理します。 | 観点 | 自社開発が向くケース | 外部委託が向くケース | | **社内体制** | Python/LLMの経験者が専任で確保できる | エンジニアが本業と兼務、または不在 | | **用途** | 特定チーム内の実験・PoC | 全社導入・顧客向けなど品質要件が高い | | **データ** | 整理済みのテキストが中心 | 図表入りPDF・スキャン文書など前処理が重い | | **セキュリティ** | クラウドAPIの利用が許容される | オンプレミス・閉域網での運用が必須 | 「まず自社でPoCを試し、本番化の段階で開発会社に相談する」という進め方も有効です。弊社では**PoCの検証結果を引き継いだ本番構築**や、逆に**PoCだけの短期支援**にも対応しています。 ## 導入でよくある失敗と対策 ### 失敗1. 文書を入れただけで精度が出ると期待してしまう RAGは「文書をベクトルDBに入れれば終わり」ではありません。表形式・図面・スキャンPDFはそのままでは検索精度が出ないため、**文書の前処理とチャンク設計に全体工数の半分以上**を割くつもりで計画するのが現実的です。 ### 失敗2. 回答精度を測る仕組みを作らない 「なんとなく良さそう」で本番展開すると、誤答の発見が利用者からのクレーム頼みになります。導入前に**代表質問セット（50〜100問）と期待回答**を用意し、精度を定量評価してからリリースすることが重要です。 ### 失敗3. 運用・更新の担当を決めていない 文書の更新が止まるとRAGの回答も古くなります。**「どの部署が・どの頻度で・どの文書を更新するか」**を導入時に決め、回答ログのモニタリングとあわせて運用に組み込みましょう。 ## よくある質問（FAQ） ### Q. RAGチャットボットとChatGPTの違いは何ですか？ ChatGPTは汎用の対話AI（LLM）で、自社の情報は持っていません。RAGチャットボットは、社内文書を検索してLLMに渡す仕組みを組み合わせることで、**自社の情報に基づいて正確に回答するAI**を実現します。詳しくはChatGPTとRAGの違い・関係をご覧ください。 ### Q. RAGチャットボットは自社で作れますか？ LangChain等を使えばデモレベルは自社開発可能です。ただし業務品質（検索精度・権限管理・運用）まで引き上げるには専門知見が必要なため、全社導入やセキュリティ要件が高い場合は開発会社への相談をおすすめします。判断基準は自社開発と外部委託の比較を参照してください。 ### Q. 導入にはどのくらいの期間・費用がかかりますか？ PoCは2〜4週間・数十万円〜、本番導入は1〜3ヶ月が目安です。実際の費用感と構成例は、本記事の「テクノスフィアでの導入事例」で紹介しています。 ### Q. 社外秘のデータを扱っても安全ですか？ RAGチャットボットはオンプレミスやプライベートクラウドでの構築が可能で、**社外にデータを送信しない構成**を取れます。ローカルLLM（Llama 3等）と組み合わせれば完全閉域での運用もできます。 ## まとめ ### この記事のまとめ - RAG（検索拡張生成）は、社内文書を検索しLLMで回答を生成する技術。ファインチューニングより低コストで導入可能 - 従来のルールベース型やLLM単体と比べ、回答精度・情報鮮度・セキュリティの面で優位 - LangChain + ベクトルDB + LLMが基本構成。オンプレミスでの構築も可能 - メリットは「既存文書の活用」「ハルシネーション抑制」「情報の自動最新化」「セキュリティ確保」「低コスト」の5つ - PoCから段階的に導入するスモールスタートが成功のカギ RAGチャットボットは、社内の問い合わせ対応や情報検索の効率化に即効性のあるAIソリューションです。「自社でも導入できるのか」「費用感はどの程度か」など、ご不明な点がありましたら、株式会社テクノスフィアにお気軽にご相談ください。要件ヒアリングから設計・開発・運用まで一気通貫で対応いたします。 ／この内容の受託開発・PoC相談はこちら＼ ### 社内 RAG・AI エージェントの受託開発 社内文書を知識源にする RAG チャットボット、業務自動化 AI エージェント、ファインチューニング、エッジ AI までテクノスフィアが一気通貫で構築します。PoC からエンタープライズ運用まで対応。 [AI開発サービスを見る](https://technosphere.co.jp/ai-solution) [社内RAG・問合せ自動化相談](https://technosphere.co.jp/contact) # RAG # チャットボット # AI # LangChain # ベクトルDB # LLM # 業務効率化 [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # Windows App Development CLI（winapp）で何ができるか｜Windowsアプリ開発をコマンドラインで完結させるMicrosoft公式ツール解説｜株式会社テクノスフィア > Microsoftが2026年1月に公開したWindows App Development CLI（winapp）を出典付きで解説。SDKセットアップ・パッケージ識別・MSIX化・証明書と署名・ストア申請・WinUI 3の雛形作成・UIオートメーションまで、コマンドラインで何ができるかを整理。Electron/Rust/Tauri/Flutter対応とAIエージェント連携（Claude Code/GitHub Copilotプラグイン）も紹介。 URL: https://technosphere.co.jp/blog/windows-app-development-cli ** 目次 1. はじめに：Windowsアプリ開発に「公式CLI」が来た 2. winapp CLIとは何か 3. インストール方法と対応フレームワーク 4. コマンド全体マップ：何ができるか一覧 5. できること①：開発環境の構築が1コマンド（init） 6. できること②：パッケージ識別の付与とデバッグ実行（run） 7. できること③：MSIX化・署名・ストア申請（pack / sign / store） 8. できること④：WinUI 3アプリの雛形作成とサンプル検索（new / find-ui） 9. できること⑤：UIオートメーションと画面録画（ui） 10. AIエージェントとの組み合わせ：公式プラグイン同梱 11. 導入前に知っておくべき注意点 12. 受託開発の現場でどう効くか 13. よくある質問（FAQ） 14. まとめ 15. 参考文献・出典 ** 本記事のスコープ 本記事は**2026年8月26日時点**のMicrosoft Learn公式ドキュメント（2026年8月19日更新版）、Windows Developer Blogの発表記事、GitHubリポジトリ（microsoft/WinAppCli）に基づく解説です。掲載しているコマンドはすべて公式リファレンスからの引用で、弊社環境での実測レポートではありません。winapp CLIは**パブリックプレビュー**段階のため、機能・コマンドは今後変更される可能性があります。導入前に末尾の一次情報をご確認ください。 ## はじめに：Windowsアプリ開発に「公式CLI」が来た Windowsのデスクトップアプリ開発には、長らく独特の「儀式」がありました。複数のSDKを揃え、マニフェストXMLを手で書き、署名用の証明書を用意し、MSIXパッケージングの複雑な要件をひとつずつ乗り越える——。Visual Studioを使っていればIDEがある程度は面倒を見てくれますが、**ElectronやFlutter、RustといったVisual Studioの外の世界から来た開発者**にとって、この儀式は大きな参入障壁でした。 2026年1月22日、Microsoftはこの問題への回答として**Windows App Development CLI（winapp CLI）**をパブリックプレビューとして発表しました[1]。SDKの管理、パッケージ化、アプリ識別（Package Identity）の付与、マニフェスト生成、証明書、ビルドツールの呼び出し——これらを**単一のコマンドラインツール**に集約するものです[2]。 発表からわずか半年あまりでリリースを重ね（執筆時点の最新版は2026年8月公開のv0.6.0）、現在ではWinUI 3アプリの雛形作成やAzureクラウド署名、UIオートメーションまで守備範囲が広がっています[5]。本記事では「結局、何ができるのか」を、公式ドキュメントに基づいて機能別に整理します。 ## winapp CLIとは何か （図: SDK・証明書・マニフェスト・パッケージなど散らばった開発ツールが1つのコマンドラインツールに集約されるイメージイラスト） バラバラだったSDK管理・マニフェスト・証明書・パッケージングを1本のCLIに集約する（イメージ） winapp CLIは、Microsoftが公式に開発・提供するWindowsアプリ開発用のコマンドラインツールです。Microsoft Learnでは次のように定義されています[2]。 > 「Windows SDKの管理、パッケージング、アプリ識別・マニフェスト・証明書の生成、あらゆるアプリフレームワークでのビルドツール利用のための、単一のコマンドラインインターフェース。クロスプラットフォーム開発とWindowsネイティブ機能のギャップを埋めるツール」（弊社訳） 重要なのはターゲット層です。発表記事では**「クロスプラットフォームフレームワークと、Visual StudioやMSBuildの外で作業する開発者向け」**と明言されています[1]。つまりVisual Studioの置き換えではなく、**これまでWindowsネイティブの作法から距離があった開発者に、コマンドライン経由の正規ルートを用意する**ツールです。 | 項目 | 内容 | | 提供元 | Microsoft（公式ツール） | | 発表日 | 2026年1月22日（Windows Developer Blog）[1] | | 提供形態 | オープンソース（MITライセンス）。GitHub `microsoft/WinAppCli` で開発[4] | | ステータス | **パブリックプレビュー**。「機能とコマンドは最終リリース前に変更される可能性がある」と明記[2] | | 最新版 | v0.6.0（2026年8月公開。執筆時点）[6] | | カバー範囲 | SDK管理／パッケージ識別／MSIXパッケージング／マニフェスト・証明書・署名／ストア申請／WinUI雛形／UIオートメーション | ** なぜ今CLIなのか 発表記事は、Windows開発が「複数のSDKの管理、複数のマニフェストの作成と編集、証明書の生成、複雑なパッケージング要件」を伴うことを課題として挙げ、開発者が「設定と格闘するのではなく、良いアプリを作ることに集中できる」ことを目標に掲げています[1]。もうひとつの背景として見逃せないのがAIコーディングエージェントとの相性です。GUIのIDE操作はAIに任せにくい一方、CLIに揃った操作はエージェントがそのまま実行できます。リポジトリにはClaude CodeとGitHub Copilot向けの公式プラグインまで同梱されています[4]。 ## インストール方法と対応フレームワーク インストールは4通り用意されています[2]。通常はWinGet、ElectronプロジェクトならnpmでプロジェクトのdevDependenciesに入れる方法が案内されています。 ``` # WinGet（推奨） winget install Microsoft.winappcli --source winget # npm（Electronプロジェクト向け） npm install @microsoft/winappcli --save-dev # 動作確認 winapp --help # WinGet版 npx winapp --help # npm版 ``` CI/CD向けには、GitHub Actions / Azure DevOps用のセットアップアクション `setup-WinAppCli` が公式提供されており、ランナーへ自動インストールできます[2]。手動ダウンロード（GitHub Releases）も可能です。 （図: 6色のブロックがそれぞれのレールから1本のレールに合流してターミナル型のゲートを通過する、複数フレームワーク対応のイメージイラスト） フレームワークごとに違う道を、パッケージングと署名の段階で1本にまとめる（イメージ） 対応フレームワークは公式ガイドとして次の6つが用意されています[2]。GitHubのREADMEでは**.NET MAUI**のガイドも追加されています[4]。 | フレームワーク | 備考 | | .NET（WPF / WinForms） | `.csproj` を自動検出し、NuGet参照の追加まで自動化 | | C++（CMake） | C++/WinRTヘッダの生成に対応 | | Electron | npm版限定の専用コマンド群あり（後述） | | Rust | `Cargo.toml` を自動検出 | | Tauri | `tauri.conf.json` を自動検出 | | Flutter | `pubspec.yaml` を自動検出 | ## コマンド全体マップ：何ができるか一覧 公式CLIリファレンス（2026年8月19日更新版）に掲載されているコマンドをカテゴリ別に整理すると、winapp CLIの守備範囲が一望できます[3]。 | カテゴリ | コマンド | できること | | セットアップ | `init` / `new` / `restore` / `update` | SDK導入と環境構築、WinUI 3雛形作成、依存の復元・更新 | | 識別・デバッグ | `run` / `create-debug-identity` / `embed-identity` / `unregister` | パッケージ識別付きでのビルド・登録・起動、後片付け | | パッケージング | `pack` | MSIX / MSIXバンドルの作成（署名まで一括） | | マニフェスト | `manifest generate` / `manifest update-assets` / `manifest add-alias` | マニフェスト生成、1枚の画像から全アイコンアセット生成、実行エイリアス追加 | | 証明書・署名 | `cert generate/info/install` / `sign` / `az-sign` / `create-external-catalog` | 開発用証明書の生成・確認・導入、ローカル署名、Azure Trusted Signingによるクラウド署名 | | ユーティリティ | `tool` / `store` / `get-winapp-path` / `find-ui` / `complete` | SDKツール（signtool等）呼び出し、ストア申請CLI、WinUIサンプル検索、シェル補完 | | UIオートメーション | `ui`（inspect / screenshot / record / click / send-keys ほか） | 起動中アプリのUI検査・操作・スクリーンショット・MP4録画 | | Node.js / Electron | `node create-addon` / `node generate-bindings` / `node add-electron-debug-identity` ほか | ネイティブアドオン雛形、Windows API のJSバインディング生成、Electronへの識別付与（npm版限定） | 以下、実務インパクトの大きい順に「できること」を見ていきます。 ## できること①：開発環境の構築が1コマンド（init） （図: ターミナルの1コマンドからプロジェクトツリーが育ち、SDKやマニフェスト、証明書が自動で組み込まれていくイメージイラスト） winapp init 一発でSDK取得からマニフェスト・証明書の生成までが揃う（イメージ） 最初の目玉が `winapp init` です。プロジェクトのルートで実行するだけで、公式リファレンスによれば次が一括で行われます[3]。 - Windows SDK / Windows App SDK パッケージのダウンロード - C++/WinRT ヘッダ・バイナリの生成（C++系プロジェクト） - `Package.appxmanifest`（アプリマニフェスト）の作成 - ビルドツールのセットアップと開発者モードの有効化 - `.gitignore` の更新、バージョン管理用 `winapp.yaml` の作成 さらに便利なのが**プロジェクトの自動検出**です。ディレクトリを指定せずに実行すると、カレントディレクトリ配下を探索して Tauri（`tauri.conf.json`）、Electron（`package.json`）、Flutter（`pubspec.yaml`）、.NET（`.csproj`）、Rust（`Cargo.toml`）、C++（`CMakeLists.txt`）を識別し、そのフレームワークに合ったセットアップを行います[3]。 ** .NETプロジェクトは専用フローに切り替わる `.csproj` が見つかった場合は.NET専用の流れになり、`TargetFramework` をWindows対応のもの（例：`net10.0-windows10.0.26100.0`）へ検証・更新し、`Microsoft.WindowsAppSDK` と `Microsoft.Windows.SDK.BuildTools` をNuGet参照として直接 `.csproj` に追加します。この場合 `winapp.yaml` は作られず、パッケージ復元は通常どおり `dotnet restore` を使います[3]。既存の.NET開発フローを壊さない設計です。 地味に効くのがアイコン類の量産です。`winapp manifest update-assets` は**1枚の元画像（SVG推奨）から、MSIXが要求する全アセットを自動生成**します。スケール別5種、タスクバー用のtargetsize 14サイズ×2系統（通常／unplated）、マルチ解像度の `app.ico` まで一括です[3]。手作業なら数十枚の画像を書き出す作業が1コマンドになります。 ``` # SVGから全アイコンアセットを生成（ベクターなので全サイズくっきり） winapp manifest update-assets mylogo.svg # ライトテーマ用の画像を別に指定することも可能 winapp manifest update-assets mylogo.png --light-image mylogo-light.png ``` ## できること②：パッケージ識別の付与とデバッグ実行（run） （図: アプリウィンドウがIDバッジを掲げ、通知ベル・パズルピース・AIチップの3機能が解錠されるパッケージ識別のイメージイラスト） パッケージ識別（Package Identity）が通知・OS統合・オンデバイスAIなどの扉を開ける（イメージ） winapp CLIを理解する鍵が**パッケージ識別（Package Identity）**です。Windowsの多くのモダンAPIは、アプリが識別を持っていることを前提にしています。Microsoft Learnは「識別を持つことで、通知、OS統合、オンデバイスAIといった機能へのアクセスが得られる」と説明しています[2]。 従来、この識別は「MSIXとして完全にパッケージしてインストールする」ことで得るのが基本で、開発中のデバッグの障害でした。winapp CLIはここに複数の解決策を用意しています[3]。 | コマンド | やること | 向いている場面 | | `winapp run` | ビルド出力フォルダを「ルースレイアウトパッケージ」としてWindowsに登録し、そのまま起動。プロセスIDを返す | **ほとんどのフレームワークでの推奨**。実際のMSIXインストールと同じ状態を再現 | | `winapp create-debug-identity` | 実行ファイル単体に一時的な識別を付与（スパースパッケージ登録） | exeがアプリコードと別の場所にある場合（例：Electronの `node_modules` 内の `electron.exe`） | | `winapp init --exe --sparse` → `pack` → `embed-identity` | 既存の配布済みデスクトップアプリに「識別専用MSIX」を用意する3ステップ | **既存アプリのモダナイズ**。フルMSIX化せずに識別が必要なAPIを使う | v0.6では `winapp run` が**プロジェクトモード**に対応し、`.csproj` や `.sln` を直接指定（または省略してカレント実行）すると、`dotnet build` でのビルドから登録・起動までを一気に行えるようになりました。`dotnet run` の感覚でパッケージアプリを回せます[3][5]。 ``` # カレントのプロジェクトをビルドして識別付きで起動 winapp run # ビルド出力フォルダを登録して起動（PIDが返るのでデバッガをアタッチできる） winapp run ./bin/Debug # クラッシュ解析つきで起動：OutputDebugStringと例外を捕捉し、 # クラッシュ時はミニダンプを自動解析してスタックトレースを表示 winapp run . --debug-output # CI/自動化向け：起動後すぐ制御を返し、PIDをJSONで出力 winapp run ./bin/Debug --detach --json ``` ** クラッシュ解析まで面倒を見る `--debug-output` オプションは単なるログ表示ではありません。公式リファレンスによれば、アプリがクラッシュした場合**ミニダンプを自動取得して解析し、例外の種類・メッセージ・ソースファイル行番号つきのスタックトレース**を表示します（.NETのクラッシュは外部ツールなしで即解析）。WinUI 3アプリでは、原因特定が難しいことで知られるstowed exceptionの追跡パスまで自動実行されます[3]。 Electron向けには、npm版限定で `npx winapp node add-electron-debug-identity` が用意されており、開発中の `electron.exe` プロセスに識別を付与して通知などのAPIをテストできます。なお公式リファレンスには、スパースパッケージ化したElectronアプリが起動時にクラッシュする既知の問題（Windows側で修正済みだが全デバイスに未展開）と、デバッグ用途での `--no-sandbox` による回避策が明記されています[3]。この手の「ハマりどころが公式に書いてある」点は、プレビュー段階のツールとしては誠実です。 ## できること③：MSIX化・署名・ストア申請（pack / sign / store） （図: フォルダ内のファイルがベルトコンベアで箱詰めされ、クラウド上の鍵から降りる光で封緘されるMSIXパッケージングと署名のイメージイラスト） ビルド出力の箱詰め（MSIX化）から署名までを1本のパイプラインで（イメージ） 配布まわりはwinapp CLIが最も力を入れている領域です。`winapp pack` は、ビルド出力フォルダを渡すだけで**ストア申請可能／サイドロード可能なMSIXパッケージ**を作ります[1][3]。 ``` # フォルダをMSIX化（マニフェストは自動検出） winapp pack ./dist # 証明書の生成・インストール・署名・ランタイム同梱まで一括 winapp pack ./dist --generate-cert --install-cert --self-contained # x64とarm64のビルドを渡すとマルチアーキテクチャの .msixbundle に winapp pack ./publish/x64 ./publish/arm64 ``` マニフェスト内の `$targetnametoken$` プレースホルダの解決、フレームワーク依存関係の注入、Win2DのようなサードパーティWinRTコンポーネントの自動検出・登録まで、パッケージングの細かい落とし穴を自動処理します[3]。複数アーキテクチャを渡した場合はPEヘッダから各フォルダのアーキテクチャを自動判定し、整合性を検証したうえでバンドル化します。 ### 署名：ローカル証明書からクラウド署名まで 開発用は `winapp cert generate` で自己署名証明書を作り、`winapp sign` で署名。本番配布用にはv0.6で追加された `winapp az-sign` が使えます。これは**Azure Trusted Signing**によるクラウド署名で、公式リファレンスが強調するとおり**「秘密鍵（PFX）がローカルマシンに一切存在しない」**運用になります[3][5]。証明書ファイルの持ち回りと漏洩リスクをなくせるのは、受託開発の納品フローでも大きな利点です。 ``` # 開発用：自己署名証明書を生成して署名 winapp cert generate --publisher "CN=My Company" --output ./mycert.pfx winapp sign MyApp.msix --cert ./mycert.pfx # 本番用：Azure Trusted Signing でクラウド署名（CI向けに全指定） winapp az-sign ./app.msix --subscription --resource-group --account --profile ``` ストア申請も `winapp store` からMicrosoft Store Developer CLI（msstore）を呼び出せます。初回実行時に自動ダウンロードされるため、別途の導入は不要です[3]。 ``` # Partner Centerのアプリ一覧 winapp store app list # パッケージをストアへ申請 winapp store publish ./myapp.msix --appId ``` つまり**「ビルド成果物 → パッケージ → 署名 → ストア申請」の全行程がコマンドで完結**し、そのままCI/CDパイプラインに載せられます。makeappxやsigntoolなどのSDKツールを直接触りたい場合も `winapp tool signtool verify /pa MyApp.msix` のように呼び出せるため、既存スクリプトからの移行も段階的に行えます[3]。 ## できること④：WinUI 3アプリの雛形作成とサンプル検索（new / find-ui） v0.6.0で加わった `winapp new` は、Windows App SDK公式の `dotnet new` テンプレートからWinUI 3アプリの雛形を作ります。テンプレートパックの導入・更新もコマンド側が面倒を見るため、「正しいNuGetやワークロードを探して回る」必要がありません[5]。 ``` # テンプレート一覧（blank / navigation view / tab view / MVVM / ライブラリ / テスト） winapp new --list # NavigationView構成のアプリを作成 winapp new --name MyApp --template winui-navview # 作ったらそのままビルド・起動（マニフェストや識別は雛形に同梱済み） winapp run ``` ユニークなのが `winapp find-ui` です。**WinUI 3 GalleryとWindows Community Toolkitの実サンプルコードを、意図ベースの検索語で横断検索**し、コピー&ペースト可能なXAML＋C#を返します[3][5]。 ``` # 「タブ切り替えのレイアウト」に合うコントロールを探す winapp find-ui "tabbed layout" # 見つかったシナリオIDを指定して実装コードを取得 winapp find-ui --id gallery-tabview-1 ``` 「このUIどう書くんだっけ」をブラウザでドキュメントを彷徨わずターミナル内で解決できる——そして後述のとおり、この検索はAIエージェントにとっても「正しいWinUIコードの供給源」として機能します。 ## できること⑤：UIオートメーションと画面録画（ui） v0.5系から入ったのが `winapp ui` サブコマンド群です。UI Automation（UIA）を使って、**起動中のWindowsアプリを外から検査・操作**できます[3]。 | 操作 | コマンド例 | | UI要素ツリーの検査・検索 | `ui inspect` / `ui search` / `ui get-property` | | 操作の実行 | `ui click` / `ui invoke` / `ui send-keys` / `ui set-value` / `ui drag` | | タッチ・ペン入力の注入 | `ui touch`（タップ・スワイプ・ピンチ）/ `ui pen`（筆圧・傾きつきストローク） | | 証跡の取得 | `ui screenshot`（PNG）/ `ui record`（H.264 MP4録画） | | 待機・同期 | `ui wait-for`（要素の状態変化を待つ） | ``` # 電卓を10秒間・15fpsでMP4録画 winapp ui record -a Calculator --duration-sec 10 --fps 15 -o demo.mp4 ``` Webの世界でPlaywrightやSeleniumが担っていたE2Eテストの操作系を、**Windowsデスクトップアプリに対して公式CLIで行える**ようになったと考えると位置づけが分かりやすいはずです。タッチパネル業務端末のような「タッチ・ペン入力の再現が必要なテスト」に対応している点は、組込み・キオスク系の開発では特に価値があります。 ## AIエージェントとの組み合わせ：公式プラグイン同梱 （図: 小さなロボットがターミナルを操作し、JSONの流れがアプリ画面の操作へつながっていくAIエージェント連携のイメージイラスト） CLIに揃った操作は、そのままAIコーディングエージェントの手足になる（イメージ） 弊社が注目しているのはここです。winapp CLIは設計の随所が**AIコーディングエージェントから使われることを前提**にしています。 - 主要コマンドが `--json` による機械可読出力に対応（`run --detach --json` でPID取得など。`find-ui --json` にはリファレンス上「agent-friendly」と明記）[3] - `ui record --frames` は、MP4に加えて**タイムスタンプ付き静止画フレームとインデックスファイル**を出力。v0.6の発表ではエージェントによる解析用途が挙げられています[5] - 非対話環境を自動検出し、プロンプト待ちで止まらずデフォルト値で進行[3] そして、GitHubリポジトリのREADMEには次のように明記されています[4]。 > 「winappは（`plugins/winapp/` に）エージェントとスキルからなる単一のプラグインを同梱している。Agent Plugins 1.0仕様に準拠し、GitHub CopilotとClaude Codeそれぞれのプラグインマーケットプレイス経由で配布される」（弊社訳） ``` # Claude Code に winapp 公式プラグインを導入 claude plugin marketplace add microsoft/WinAppCli claude plugin install winappcli@winappcli # GitHub Copilot CLI の場合 copilot plugin install microsoft/WinAppCli ``` これが揃うと何が起きるか。**「WinUIでこういう画面のアプリを作って、パッケージして、起動して、スクリーンショットで確認して」という指示を、AIエージェントが雛形作成（`new`）→ 実装（`find-ui` で正しいサンプルを検索）→ ビルド・起動（`run --detach --json`）→ 画面検証（`ui screenshot` / `ui click`）まで、公式ツールだけで実行できる**手順が成立します。Windowsデスクトップ開発は長年「GUIのIDEありき」でAI自動化と相性が悪い領域でしたが、その前提が変わりつつあります。 なお発表記事では、実験的機能としてNode.jsからWindows AI APIを直接呼ぶ `@microsoft/winapp-windows-ai` npmパッケージ（オンデバイスAIのPhi Silica連携）にも触れられています[1]。ElectronアプリからオンデバイスAIを叩く道筋も見え始めています。 ## 導入前に知っておくべき注意点 ** ① パブリックプレビューである Microsoft Learnの冒頭には「Windows App Development CLIは現在パブリックプレビューです。**機能とコマンドは最終リリース前に変更される可能性があります**」と明記されています[2]。実際、2026年1月の公開（v0.1.10）から8月のv0.6.0まで、ほぼ毎月コマンドが追加・変更されてきました[6]。CIに組み込むならバージョン固定とリリースノートの追跡を前提にすべきです。 ** ② 機能によって前提条件が異なる たとえば `run` のプロジェクトモードは.NET SDK 8.0.100以降が、`winapp new` も.NET SDKの事前インストールが必要で、winapp自体はツールチェーン（.NET SDK等）をインストールしません。`az-sign` はAzure側のアカウント・証明書プロファイルに加え、ローカルにx64の.NET 8ランタイムとVC++再頒布可能パッケージが必要です[3]。npm版限定のコマンド（JSバインディング生成、Electron系）もあります。 ** ③ 既知の問題も公式リファレンスに集約されている Electronのスパースパッケージ起動クラッシュ（前述）や、ポップアップ要素の録画制限など、既知の問題はGitHub IssueへのリンクつきでLearnに記載されています[3]。導入時は使いたいコマンドのページを一読することをおすすめします。 ## 受託開発の現場でどう効くか Windowsの業務アプリケーションやタッチパネル端末ソフトの受託開発を手がける立場から、winapp CLIが効きそうな場面を整理します。 | 場面 | これまで | winapp CLIで | | CI/CDでのMSIX配布 | makeappx / signtool を個別に叩く自前スクリプトを保守 | `setup-WinAppCli` ＋ `pack` / `az-sign` でパイプラインを標準化 | | 既存WinForms/WPF資産のモダナイズ | 通知などのモダンAPIを使うには全面MSIX化が必要と思われがち | スパースパッケージで**既存exeのまま**識別を付与し、段階的に近代化 | | Electron/Flutter製アプリのWindows配布 | Windows固有のパッケージ・署名要件が都度調査になりがち | フレームワーク別ガイドに沿って `init` → `pack` の共通手順に | | タッチパネル端末のUIテスト | 手動テスト、または商用ツールの導入 | `ui touch` / `ui record` でタッチ操作の再現と証跡録画を自動化 | | AIエージェント活用の開発フロー | デスクトップ開発はGUI前提でAIに任せにくい | 公式プラグイン＋`--json`出力で、実装〜画面確認までをエージェントに委任 | 特に「既存アプリを捨てずに、通知やOS統合だけ足したい」という相談は実務で多く、**スパースパッケージ3ステップ（`init --sparse` → `pack` → `embed-identity`）が公式手順として整備された**意味は大きいと考えています。 ## よくある質問（FAQ） ### Q. winapp CLIは無料で使えますか？ MITライセンスのオープンソースとしてGitHub（`microsoft/WinAppCli`）で公開されており、winget・npm・GitHub Releasesから無償で入手できます[4]。ただしパブリックプレビュー段階のため、仕様変更の可能性がある点は考慮してください[2]。 ### Q. Visual Studioは不要になりますか？ 置き換えを狙うツールではありません。Microsoftは「Visual StudioやMSBuildの外で作業する開発者向け」と位置づけています[1]。ステップ実行などのデバッガやビジュアルデザイナは引き続きIDEの領分です。一方で、`run --no-launch` で識別だけ登録して任意のデバッガをアタッチする、といったIDE併用の使い方もリファレンスに記載されています[3]。 ### Q. どのフレームワークで使えますか？ 公式ガイドがあるのは.NET（WPF/WinForms）、C++（CMake）、Electron、Rust、Tauri、Flutterの6つで[2]、GitHub READMEには.NET MAUIのガイドも追加されています[4]。WinUI 3は `winapp new` による雛形作成に対応しています[5]。 ### Q. 本番プロダクトの開発に使ってもよいですか？ 「機能とコマンドは最終リリース前に変更される可能性がある」との公式注記[2]を踏まえ、弊社としては**バージョン固定・リリースノート追跡を前提に、まずCIの一部（パッケージング・署名）から段階導入**する進め方をおすすめします。フィードバックはGitHub Issuesで受け付けられています[4]。 ## まとめ ** この記事のまとめ - winapp CLI（Windows App Development CLI）は、Microsoftが2026年1月22日にパブリックプレビューとして公開した公式のコマンドラインツール。MITライセンスのOSSで、winget / npm / GitHub Actionsから導入できる - `init` でSDK取得〜マニフェスト・証明書生成までの環境構築が1コマンド。Tauri / Electron / Flutter / .NET / Rust / C++ のプロジェクトを自動検出する - 多くのモダンWindows API（通知・OS統合・オンデバイスAI）に必要な**パッケージ識別**を、`run` や スパースパッケージで開発中・既存アプリにも付与できる - `pack` → `sign` / `az-sign`（Azure Trusted Signing）→ `store publish` で、MSIX化から署名・ストア申請までがコマンドで完結し、CI/CDに載せられる - v0.5系で `ui`（UIオートメーション・MP4録画）、v0.6.0で `new`（WinUI 3雛形）・`find-ui`（公式サンプル検索）・`az-sign` が加わり、Claude Code / GitHub Copilot向け公式プラグインも同梱。**AIエージェントがWindowsアプリ開発を扱える土台**が整いつつある - ただしパブリックプレビューであり、コマンド仕様は変更され得る。導入はバージョン固定と一次情報の追跡を前提に テクノスフィアでは、WindowsデスクトップアプリやタッチパネルUIの受託開発、既存Windows資産のモダナイズ、AIエージェントを組み込んだ開発フローの構築をご支援しています。「古いWinFormsアプリに通知機能を足したい」「Electronアプリを社内配布したい」といったご相談もお気軽にどうぞ。 [アプリ開発事業](https://technosphere.co.jp/app-development) ｜ [AIエージェント活用の実測記事](https://technosphere.co.jp/blog/canva-mcp-claude-code) ｜ [開発の相談をする](https://technosphere.co.jp/contact) ## 参考文献・出典 1. Microsoft「Announcing winapp, the Windows App Development CLI」Windows Developer Blog（2026年1月22日、発表の経緯・対象層・主要機能） — [blogs.windows.com](https://blogs.windows.com/windowsdeveloper/2026/01/22/announcing-winapp-the-windows-app-development-cli/) 2. Microsoft Learn「Windows App Development CLI (winapp CLI)」（定義、プレビュー注記、インストール方法、対応フレームワーク、パッケージ識別の意義） — [learn.microsoft.com/…/winapp-cli/](https://learn.microsoft.com/en-us/windows/apps/dev-tools/winapp-cli/) 3. Microsoft Learn「CLI Documentation and Usage」（全コマンドのリファレンス。本文中のコマンド例の出典） — [learn.microsoft.com/…/winapp-cli/usage](https://learn.microsoft.com/en-us/windows/apps/dev-tools/winapp-cli/usage) 4. GitHub「microsoft/WinAppCli」（MITライセンス、README、Agent Plugin、.NET MAUIガイド、Issue受付） — [github.com/microsoft/WinAppCli](https://github.com/microsoft/WinAppCli) 5. Microsoft「Announcing Windows App Development CLI v0.6.0」ifdef Windows blog（2026年8月、new / find-ui / run プロジェクトモード / az-sign） — [devblogs.microsoft.com](https://devblogs.microsoft.com/ifdef-windows/windows-app-development-cli-v0-6-create-new-winui-applications-sign-packages-with-azure-and-more/) 6. GitHub「microsoft/WinAppCli Releases」（バージョン履歴） — [github.com/microsoft/WinAppCli/releases](https://github.com/microsoft/WinAppCli/releases) ※本記事は2026年8月26日時点の公式ドキュメント・公式ブログ・GitHubリポジトリの記載に基づく解説であり、掲載コマンドは公式リファレンスからの引用です。winapp CLIはパブリックプレビューのため、仕様・コマンドは変更される可能性があります。本文中の図版はイメージイラストです。Microsoft、Windows、Visual Studio、AzureはMicrosoft Corporationの商標です。ClaudeおよびClaude CodeはAnthropic PBC、GitHubおよびGitHub CopilotはGitHub, Inc.の商標です。 AIエージェントにツールを操作させる実例は[Canva MCP × Claude Codeの実測記事](https://technosphere.co.jp/blog/canva-mcp-claude-code)で、アプリの配布方式の選び方は[社内アプリの配布方法まとめ](https://technosphere.co.jp/blog/inhouse-app-distribution)でも解説しています。 [技術コラム一覧に戻る](https://technosphere.co.jp/blog/) --- # リアルタイムペットオークションシステム｜実績事例｜株式会社テクノスフィア > 20年間使用されてきた物理的なペットオークションシステムをWebベースに移行。最大200名が同時参加可能で、10ms超低レイテンシを実現したリアルタイム入札システムの開発事例をご紹介します。 URL: https://technosphere.co.jp/case-studies/pet-auction # リアルタイムペットオークションシステム 20年間使用されてきた物理的なオークションシステムをWebベースに移行。 最大200名が同時参加可能で、10ms超低レイテンシを実現したリアルタイム入札システム ## プロジェクト概要 長年にわたり業界で使用されてきた物理的なペットオークションシステムを、最新のWeb技術を活用してデジタル化しました。 従来の会場に足を運ぶ必要があった参加者が、遠隔地からでもスマートフォンやPCを通じて入札に参加できるようになり、 市場の活性化と利便性の向上を実現しています。 ## システム画像 （図: ペットオークションシステム画面1） （図: ペットオークションシステム画面2） （図: ペットオークション会場） ## システムアーキテクチャ （図: ペットオークションアーキテクチャ図） 図：リアルタイムペットオークションシステムのアーキテクチャ構成 本システムは、**EC2ベースの低レイテンシアーキテクチャ**を採用しています。 WebSocketによるリアルタイム双方向通信を中心に、以下の構成で高速かつ安定したサービスを提供しています。 ### アーキテクチャの特徴 - ● **フロントエンド**: Vanilla JavaScriptで軽量実装。フレームワークを使わないことで高速なレスポンスを実現 - ● **バックエンド**: Node.js + ExpressをEC2上で稼働。非同期I/Oで大量の同時接続を効率的に処理 - ● **リアルタイム通信**: WebSocket（wsライブラリ）により10msの超低レイテンシを実現 - ● **データベース**: DynamoDBでスケーラブルなデータ永続化。セッション管理やイベント情報を管理 - ● **インフラ管理**: CloudFormationによるIaC。環境の再現性と保守性を確保 - ● **プロセス管理**: PM2による自動監視・再起動。システムの安定稼働を保証 この構成により、最大200名の同時参加者に対して、ラグのない入札体験を提供することに成功しました。 また、CloudFormationによる環境管理により、開発環境と本番環境の一貫性を保ち、 迅速なデプロイと安定した運用を実現しています。 ## プロジェクトの背景 従来のオークション会場での物理的なシステムは、参加者が会場に直接足を運ぶ必要があり、 地理的な制約や時間的な制約が大きな課題となっていました。また、20年間使用されてきたシステムの 老朽化により、保守性や拡張性の面でも問題を抱えていました。 そこで、業界に長年根付いた運用方法を尊重しながら、より多くの参加者に門戸を開くことで 市場の活性化に貢献するWebベースのシステムへの全面刷新を実現しました。 ## 技術スタック ### フロントエンド Vanilla JavaScript（フレームワーク不使用） 軽量かつ高速な動作を実現 ### バックエンド Node.js + Express EC2上で高速動作する非同期処理 ### リアルタイム通信 WebSocket (ws library) 10ms超低レイテンシの双方向通信 ### データベース Amazon DynamoDB スケーラブルなNoSQLデータベース ### インフラ AWS (EC2, CloudFormation) IaCによる再現性の高い環境構築 ### プロセス管理 PM2 自動再起動と監視機能 ## 技術的特徴 ### 超低レイテンシの実現 - 10ms高精度タイマーによるリアルタイム価格更新 - WebSocketを活用した低遅延の双方向通信 - 最大200名の同時接続に対応した負荷分散設計 - EC2インスタンスの最適化によるレスポンス向上 ### 独自の入札方式 - 「ボタンを押し続けて離す」という直感的な操作 - モバイルファーストの設計でスマートフォンに最適化 - 視覚的フィードバックによる分かりやすいUI/UX - 誤操作を防ぐための確認機能 ## 主な機能 ### イベント管理 階層構造（イベント→出品者→ロット）による効率的な管理。イベントの作成から終了までワンストップで対応。 ### リアルタイム入札 WebSocketによる双方向通信で、全参加者に即座に価格更新を配信。ラグのない入札体験を提供。 ### 大型モニター表示 会場の大型モニターに対応した自動表示画面。派手なアニメーション効果で臨場感を演出。 ### くじ引き機能 3D回転演出と効果音（ドラムロール、ファンファーレ）を備えた派手なくじ引き機能。 ### QRコード受付 QRコードによる簡単な参加者受付システム。スムーズなチェックインを実現。 ### 管理コントロールパネル 主催者向けの統合管理画面。イベント進行、参加者管理、結果確認が一元管理可能。 ## 導入効果 ### 参加者数の増加 遠隔地からの参加が可能になり、従来の会場参加に比べて参加者数が大幅に増加。より多くのビジネスチャンスを創出。 ### 利便性の向上 時間や場所の制約がなくなり、スマートフォンやPCから気軽に参加可能に。ユーザーエクスペリエンスが大幅に改善。 ### コスト削減 物理的な会場の運営コストや移動コストが削減。効率的なオークション運営を実現。 ### 信頼性の維持 PM2による自動監視・再起動機能で、システムの安定稼働を実現。従来の信頼性を維持しながら新しい価値を提供。 ### 同様のシステム開発をご検討の方へ リアルタイム通信、低レイテンシが求められるシステム、大規模同時接続が必要なシステムなど、 高度な技術要件を持つプロジェクトのご相談を承ります。お気軽にお問い合わせください。 [実績一覧に戻る](https://technosphere.co.jp/#achievements) --- # 公共・自治体｜Solaris/SPARCで動く税務系基幹システムをOracle Cloud（OCI）へ移行｜テクノスフィア > SPARCサーバーEOLに伴いSolaris 10上のOracle DB税務システムをOCIへ移行。ハードウェア維持費ゼロ化・可用性99.95%達成・Oracle DBライセンス移行をスムーズに実現した事例。 URL: https://technosphere.co.jp/cloud-migration/government-solaris-oci [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [採用情報](https://technosphere.co.jp/recruit) ** 公共・自治体 / 超レガシー移行 # Solaris/SPARCで動く 税務系基幹システムを Oracle Cloud（OCI）へ移行 0円ハード維持費ゼロ化 99.95%可用性達成 4ヶ月移行期間 DR対応災害対策完備 ## プロジェクト概要 関東圏の中規模自治体様。2005年に導入したSPARCサーバー（Sun/Oracle SPARC T5240）上でSolaris 10を稼働させ、Oracle Database 11gを使った税務管理・住民台帳連携システムを運用していました。 SPARCサーバーのハードウェア保守期限到来と、Solaris 10のEOL（2021年に延長サポート終了）が重なり、基幹システムの移行が急務となりました。Oracle DBの大規模ライセンスをすでに保有していたため、そのまま活用できるOracle Cloud Infrastructure（OCI）への移行を選択。 テクノスフィアはSolaris環境からOCIへの移行全工程（調査・設計・構築・データ移行・テスト・本番切り替え）を担当し、4ヶ月での移行を実現しました。 ## 課題と解決アプローチ ⚠ CHALLENGE（課題） - SPARCサーバーの保守期限切れ・部品調達困難 - Solaris 10のEOL（延長サポートも終了） - Oracle DB 11g → 最新版への移行が必要 - 税務データの厳格なセキュリティ・コンプライアンス要件 - 住民台帳・税務・会計システムとの複雑な連携 - 年度末の繁忙期を避けた計画的な切り替えが必要 → ✅ SOLUTION（解決策） - OCI Bare Metal × Oracle Linux 8で再構築 - Oracle DB 11g → 19c（LTS版）へアップグレード - OCIのOracle DBライセンス持ち込みでコスト最適化 - OCI VPN Connect で庁内ネットワークとセキュア接続 - OCI Data Guard でDR構成（東京リージョン→大阪リージョン） - 年度末を避けた10月〜1月の工期計画 ## 移行後のアーキテクチャ（OCI構成） 【移行後：Oracle Cloud Infrastructure（OCI）構成】 東京リージョン（メイン） ├── OCI Bare Metal BM.Standard.E4：Oracle DB 19c（Exadataライセンス持ち込み） │ └── 税務DB・住民台帳DB・会計DB（計 850GB） ├── OCI VM.Standard.E4：Oracle WebLogic 12c（業務Webアプリ） ├── OCI Object Storage：バックアップ・帳票PDFアーカイブ ├── OCI Vault：DB接続パスワード・証明書の秘密管理 └── OCI Load Balancer：庁内端末→Webアプリ負荷分散 大阪リージョン（DR用） └── Oracle Data Guard スタンバイDB（自動フェイルオーバー） 庁内ネットワーク → OCI VPN Connect（専用線相当のIPsec） OCI Cloud Guard：セキュリティ監視・脅威検知 ## Solaris → Linux移行のポイント Solaris固有の機能・コマンドを使っているシステムをLinuxへ移行する際、特に注意が必要なポイントをご紹介します。 - **ZFSファイルシステム**：SolarisのZFS（Zetabyte File System）はOracle Linux 8でも対応。ファイルシステムごとOCI Block Volumeに移行し、スナップショット機能を継続活用。 - **Solaris Zones（コンテナ）**：Solaris Zones（非グローバルゾーン）で分離されていたアプリをLinuxのコンテナ（Docker）またはVM分離に移行。 - **シェルスクリプトの互換性**：Solaris sh（Bourne Shell）とbashの文法差異を修正。特に`/usr/bin/awk`と`/usr/xpg4/bin/awk`の挙動の違いに注意。 - **Oracle DBライセンス移行**：OCIではBYOL（ライセンス持ち込み）が可能。既存のOracle DBライセンスをそのままOCIで使用でき、新規購入不要。 - **Oracle DB 11g → 19cへのアップグレード**：Data Pump（expdp/impdp）を使用してデータを19cにエクスポート・インポート。事前にDB互換パラメータ・非推奨機能を調査し対応。 ## セキュリティ・コンプライアンス対応 自治体の税務システムは特に高いセキュリティ要件があります。テクノスフィアでは以下の対策を実施しました： - **個人情報保護**：住民・税務データは全てOCI暗号化ストレージに格納。転送時もTLS 1.3で暗号化。 - **ネットワーク分離**：OCI VCN（Virtual Cloud Network）でセキュリティリスト・NSGを設定。庁内ネットワーク以外からのアクセスを完全遮断。 - **監査ログ**：OCI Audit ServiceでDBアクセス・操作ログを全件保存。Oracle Audit Vaultと連携し改ざん防止ログを実現。 - **脆弱性対応**：OCI OS Management Serviceで自動パッチ適用。セキュリティパッチを週次で自動適用。 ## 4ヶ月移行タイムライン 月1 現状調査・OCI設計 Solarisシステムのインベントリ調査、依存関係マッピング、Oracle DBライセンス確認。OCI構成設計・コスト試算・セキュリティ設計を実施。 月2 OCI環境構築・DB移行準備 OCI VCN・セキュリティリスト・Bare Metal構築。Oracle Linux 8セットアップ。DB 19cインストール・互換性テスト。Data Pumpによる初回テストエクスポート実施。 月3 アプリ移行・結合テスト Oracle WebLogicアプリをOCI VMに移行・起動確認。住民台帳・税務・会計システム間の連携テスト。Data Guardスタンバイ構築・フェイルオーバーテスト実施。 月4 並行稼働・本番切り替え 2週間の並行稼働（旧Solaris＋新OCI同時稼働）。全業務での動作確認後、週末夜間に本番切り替え。VPN切り替え・DNS変更・旧システム停止。切り替え完了後2週間のウォッチ期間。 ## 移行結果・成果 0円ハードウェア維持費ゼロ化 （年間約480万円→0円） 99.95%サービス可用性 （Data Guard DR構成） DB11g→19cデータベース バージョンアップ完了 4分DR自動フェイルオーバー （東京→大阪） [← 前の事例 IT企業：AWS → GCP クラウド乗り換え](https://technosphere.co.jp/cloud-migration/itfirm-aws-gcp) [最初の事例 → 製造業：Windows Server 2003 → AWS](https://technosphere.co.jp/cloud-migration/manufacturing-windows-aws) プロジェクト概要 - 業種公共・自治体 - 規模人口5万人規模 - 移行元SPARC / Solaris 10 / Oracle DB 11g - 移行先Oracle Cloud（OCI）/ Oracle Linux 8 / Oracle DB 19c - パターンRe-host + Upgrade（移行＋DBバージョンアップ） - 期間約4ヶ月（10月〜1月） - 停止時間週末夜間2時間（計画停止） - DBサイズ約850GB（3DB合計） Solaris・SPARC・公共系 基幹システムの移行もお任せください Solaris・HP-UX・AIXなどUNIX系OSからの移行実績があります。まずは現状調査から始めます。 [無料相談はこちら](https://technosphere.co.jp/contact) 初回ヒアリング無料 ## Solaris・UNIX系・公共基幹システムの移行もテクノスフィアにお任せください。 [無料相談・お問い合わせ](https://technosphere.co.jp/contact) [事例一覧に戻る](https://technosphere.co.jp/cloud-migration/) [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [技術コラム](https://technosphere.co.jp/blog/) [採用情報](https://technosphere.co.jp/recruit) [プライバシーポリシー](https://technosphere.co.jp/privacy) © 2023 Technosphere Inc. - [Facebook](https://www.facebook.com/technosphere.co.ltd) - [X（旧Twitter）](https://x.com/technosphere_co) - [Instagram](https://www.instagram.com/technosphere_co/) - [TikTok](https://www.tiktok.com/@technosphere.co) --- # クラウドマイグレーション・サーバーレス化・コスト最適化｜AWS・Azure・GCP・OCI・さくらのクラウド対応｜株式会社テクノスフィア > テクノスフィアがクラウド移行・サーバーレス化・コスト最適化を一気通貫で受託。AWS / Azure / GCP / OCI / さくらのクラウド対応。COBOL・Windows Server 2003 等レガシー環境や逆移行（クラウド→オンプレ）も対応。 URL: https://technosphere.co.jp/cloud-migration/ [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [採用情報](https://technosphere.co.jp/recruit) Windows Server 2003 ** AWS EC2 完了 COBOL / AS/400 ** Azure VM 完了 Red Hat Linux 6 ** GCP GCE 完了 AWS（高コスト） ** さくらのクラウド コスト削減 Solaris / SPARC ** OCI 完了 ** CLOUD MIGRATION SERVICE # どんな古いシステムも、 どのクラウドへも。 移行実績 100件超。 オンプレミス ⇄ クラウド 双方向マイグレーション Windows Server 2003 / COBOL / AS/400 / Solaris など、 「もう誰も触れない」レガシーシステムの移行も、テクノスフィアにお任せください。 AWS・Azure・GCP・OCI・さくらのクラウドへの対応はもちろん、 クラウドからオンプレミスへの**逆移行**も、 稼働中クラウドの**サーバーレス化によるコスト削減**も得意分野です。 20年超 インフラ支援実績 100+ 移行プロジェクト 5 対応クラウド 0 重大障害件数 無料相談はこちら ケーススタディを見る PAIN POINTS ## こんなお悩み、ありませんか？ ** EOL・サポート終了 Windows Server 2003/2008、CentOS 6/7など保守期限切れのOSが本番稼働中。でも止められない… ** クラウドコストが爆増 AWSやAzureの月額費用が当初見積もりの数倍に。思い切ってオンプレに戻したい。 ** 担当者が誰もいない 構築した担当者が退職。ドキュメントもなく誰も手を付けられない古いサーバーが… ** セキュリティが不安 古いOSのまま外部公開しているシステムがある。脆弱性が心配だが移行方法が分からない。 ** パフォーマンスが限界 オンプレサーバーが老朽化。スペック不足でシステムが重く業務に支障が出始めている。 ** 別クラウドへ移したい 現在使っているクラウドベンダーのサービスや価格に不満。別のクラウドへ乗り換えたい。 👉 どのケースも、テクノスフィアが一気通貫で解決します。 SUPPORTED PLATFORMS ## 対応クラウド・OS・プラットフォーム 業界を問わず、あらゆる構成に対応します。「うちのは特殊で無理かも」と思った方こそ、まずご相談ください。 ### 対応クラウドプラットフォーム ** Amazon Web Services EC2 / RDS / S3 / ECS / Lambda など ** Microsoft Azure VM / SQL / Blob / AKS / Functions など ** Google Cloud GCE / GKE / Cloud SQL / BigQuery など ** Oracle Cloud OCI VM / Autonomous DB / OKE など ** さくらのクラウド VPS / クラウド / 専用サーバー など ** その他クラウド IDCFクラウド・富士通 FJcloud など ### 対応OS・レガシー環境 **Windows Server 2025/2022/2019 **Windows Server 2016/2012 **Windows Server 2008 / 2003（EOL） **Windows NT / 2000（超レガシー） **RHEL / CentOS Stream 9/8 **Ubuntu 22.04 / 20.04 LTS **CentOS 7 / 6（EOL） **Red Hat Linux 7 以前 **Solaris / SPARC **HP-UX / AIX **AS/400 / IBM iSeries **COBOL メインフレーム系 **macOS Server **Debian / AlmaLinux / Rocky Linux ** オレンジ表示はEOL（サポート終了）のレガシーOS。こちらも**対応実績あり**です。 MIGRATION PATTERNS ## 4つのマイグレーションパターン お客様の状況・目的に応じて最適なパターンをご提案します。双方向・マルチクラウドにも対応。 ** ### オンプレミス → クラウド 最多依頼パターン 自社サーバールームや専用線で動いているシステムを、AWSやAzureなどのパブリッククラウドへ移行します。 EOL対応・コスト削減・BCP強化・スケーラビリティ確保が主な目的です。 - Lift & Shift（そのまま移行）で短期移行も対応 - Re-platform（部分最適化）でコスト最適化 - Re-architect（クラウドネイティブ化）でフルリニューアル - 段階的移行でゼロダウンタイム移行を実現 - 移行後の運用監視・保守まで一貫サポート ** ### クラウド → オンプレミス 逆移行・クラウド撤退 「クラウドにしたがコストが予想以上」「データをクラウドに置きたくない」「レスポンスが遅い」。 そんな場合はオンプレミスへの回帰（クラウド撤退）をご支援します。 - クラウドコスト試算・オンプレ比較分析 - プライベートクラウド（VMware/Hyper-V）構築 - ハイブリッドクラウド構成への移行 - データ主権・法規制対応（GDPR・個人情報保護法） - 専有ハードウェアへのデータ移行・検証 ** ### クラウド → クラウド ベンダー乗り換え AWS から Azure へ、Azure から GCP へ、さらにはさくらのクラウドへのコスト最適化移行など、 クラウド間の乗り換えも豊富な実績があります。 - ベンダーロックイン解消・マルチクラウド化 - リージョン変更（東京・大阪・海外） - コスト最適化（リザーブドインスタンス活用） - Kubernetes / コンテナ移行（ECS → GKE 等） - マネージドDB乗り換え（RDS → Azure SQL 等） ** ### サーバーレス化・コスト最適化 ランニングコスト削減 クラウドで稼働中のシステムのランニングコストが膨らんでいる場合、**常時稼働のサーバーをサーバーレス構成に置き換える**ことで劇的なコスト削減が可能です。 - EC2 → Lambda＋API Gateway でサーバーレス化 - RDS → DynamoDB / Aurora Serverless v2 で従量課金化 - ECS → Fargate Spot でコンテナランニング削減 - 静的サイト → S3＋CloudFront で配信コスト最小化 - バッチ処理 → Lambda＋EventBridge で常時稼働ゼロへ MIGRATION FLOW ## 移行プロジェクトの進め方 初回ヒアリングから移行完了・運用引き継ぎまで、全工程をテクノスフィアが伴走します。 1 現状調査・ アセスメント 既存システム構成・OS・ミドルウェア・データ量を調査。移行リスクを洗い出します。 2 移行計画・ 設計 最適クラウド選定、アーキテクチャ設計、スケジュール・リスク対策を策定します。 3 移行先 環境構築 クラウド環境のセットアップ、ネットワーク・セキュリティ設定、IaC（Terraform等）による構築。 4 データ移行・ テスト 本番データの移行、動作検証、性能テスト、セキュリティチェックを実施します。 5 本番切り替え Blue/Greenデプロイ・DNS切り替えなどの手法でゼロダウンタイム切り替えを実現。 6 運用引き継ぎ・ 保守 監視設定・アラート・バックアップの整備、運用マニュアル作成、保守サポート開始。 OUR STRENGTHS ## テクノスフィアが選ばれる理由 「他社に断られた」「誰も手を付けられない」案件こそ、私たちの出番です。 ** 20年超 レガシー環境への深い理解 Windows NT・COBOL・AS/400・Solaris・HP-UXなど、現代のエンジニアが知らない環境も経験豊富なベテランが対応。ドキュメントが残っていないシステムも解読・移行できます。 ** 0件 移行による重大障害ゼロ 徹底した事前調査・テスト・ロールバック計画により、本番移行での重大障害は0件。夜間・休日の切り替え対応や段階的移行で、ビジネス継続性を最優先に設計します。 ** 双方向 オンプレ↔クラウド双方向に対応 「クラウドに移行したが、やっぱりオンプレに戻したい」という逆移行・クラウド撤退も得意です。コスト・セキュリティ・レイテンシなど、最適な環境を客観的にご提案します。 ** 全スタック インフラからアプリまで一気通貫 インフラ移行だけでなく、アプリケーションの修正・クラウドネイティブ化・コンテナ化まで対応。組込み・AI・Webシステムまで手がける総合力で、アーキテクチャ全体を見通した提案が可能です。 ** 適正価格 大手SIerに頼めない中規模案件が得意 数百万〜数千万規模の移行案件に強み。大手SIerでは対応してもらえない中小規模のシステム移行に多数対応。現実的なコストでハイクオリティな移行を実現します。 ** 24h 移行後の運用保守も継続サポート 移行して終わりではありません。24時間監視・アラート対応・パッチ運用・コスト最適化レポートなど、移行後の安定運用まで一貫してサポートします。 TECH STACK ## 活用する技術・ツール IaC / 自動化 ** Terraform ** Ansible ** AWS CDK ** Pulumi ** Chef / Puppet コンテナ・オーケストレーション ** Docker ** Kubernetes (EKS/AKS/GKE) ** Amazon ECS / Fargate ** Helm ** ArgoCD データ移行ツール ** AWS DMS ** Azure Migrate ** Google Transfer ** rsync / rclone ** Percona XtraBackup 監視・ログ ** Datadog ** Zabbix ** Prometheus + Grafana ** CloudWatch / Azure Monitor ** Fluentd / OpenSearch CASE STUDIES ## 移行・コスト最適化ケーススタディ クラウド移行・逆移行からサーバーレス化によるランニングコスト削減まで、実際のプロジェクト事例をご紹介します。詳細ページでアーキテクチャ図・コスト比較・タイムラインまで公開しています。 ### [（図: 製造業 Windows Server 2003 → AWS 移行） 製造業 AWS Windows Server 2003 稼働の生産管理システムをAWSへ無停止移行 Windows Server 2003 AWS EC2 SQL Server Lift & Shift 20年以上稼働し続けた生産管理システム。EOLのWindows Server 2003上で動作するカスタムアプリをAWSへ移行。週末の計画停止も最小化し、工場ラインへの影響ゼロで完了。 OUTCOME 運用コスト 40% 削減・障害対応時間 80% 短縮 詳細を見る](https://technosphere.co.jp/cloud-migration/manufacturing-windows-aws) ### [（図: 小売業 在庫管理 さくらのクラウド移行） 小売・卸売業 さくらのクラウド 老朽化した在庫管理システムをさくらのクラウドへ移行しコスト60%削減 CentOS 6 さくらのクラウド MySQL PHP 専用サーバーで動いていた在庫管理・受発注システム。ハードウェア老朽化とCentOS 6のEOLが重なり移行を決断。国内データセンター重視のためさくらのクラウドを選択。 OUTCOME 月額費用 60% 削減・バックアップ自動化・DR構成も実現 詳細を見る](https://technosphere.co.jp/cloud-migration/retail-onprem-sakura) ### [（図: 医療機関 AWS クラウドからオンプレ逆移行） 医療機関 逆移行 電子カルテシステムのAWSからオンプレミスへの逆移行（コスト・セキュリティ対応） AWS → オンプレ 電子カルテ PostgreSQL 個人情報保護 患者データをAWSに置くことへの懸念とコスト増大を理由に、プライベートサーバーへの逆移行を実施。院内ネットワーク完結・高速レスポンスを実現しながらも、DR用にAWSを活用するハイブリッド構成へ。 OUTCOME 月額費用 55% 削減・レスポンス 3倍高速化・コンプライアンス対応完了 詳細を見る](https://technosphere.co.jp/cloud-migration/medical-aws-onprem) ### [（図: 物流 COBOL AS/400 Azure マイグレーション） 物流・運輸 Azure 30年稼働のCOBOL/AS/400帳票システムをAzure上のWebシステムへフルリプレイス AS/400 COBOL Azure VM 再構築 30年以上現役のAS/400上のCOBOLシステム。ハードウェア更新のタイミングでAzureへの全面移行を決断。COBOLロジックをJava/Springに書き換え、Azureのマネージドサービスで再構築。 OUTCOME 処理時間 90% 短縮・保守性が大幅向上・ペーパーレス化達成 詳細を見る](https://technosphere.co.jp/cloud-migration/logistics-cobol-azure) ### [（図: IT企業 AWS から GCP 乗り換え） IT・SaaS企業 GCP SaaSプロダクトのAWSからGCPへの乗り換えでML基盤を強化・費用最適化 AWS → GCP Kubernetes BigQuery ML基盤 機械学習・データ分析機能の強化を目的にAWSからGCPへ移行。ECSをGKEに、RDSをCloud SQLに、S3をCloud Storageに移行。BigQueryとVertex AIを活用しML基盤を一新。 OUTCOME ML処理コスト 45% 削減・デプロイ頻度 3倍向上 詳細を見る](https://technosphere.co.jp/cloud-migration/itfirm-aws-gcp) ### [（図: 自治体 Solaris SPARC OCI Oracle Cloud 移行） 公共・自治体 OCI Solaris/SPARCで動く税務系基幹システムをOracle Cloud（OCI）へ移行 Solaris 10 SPARC OCI Oracle DB Solaris 10 / SPARC上のOracle DBを使った税務システム。SPARCサーバーのEOLに伴いOCIへの移行を実施。Oracle DBのライセンス移行とSolaris → Oracleクラウドの互換性を最大限に活用し、短期間で移行完了。 OUTCOME ハードウェア維持費 ゼロ化・可用性 99.95%達成・DR対応強化 詳細を見る](https://technosphere.co.jp/cloud-migration/government-solaris-oci) ### [（図: AWS EC2 サーバーレス化 Lambda コスト削減） EC・SaaS企業 サーバーレス化 AWS EC2常時稼働をサーバーレス化しランニングコスト72%削減 AWS Lambda API Gateway DynamoDB コスト最適化 EC2×8台を常時稼働させていたBtoB SaaSのAPI基盤。深夜はトラフィックがほぼゼロなのにフル課金という無駄をLambda＋DynamoDBへのサーバーレス化で解消。月額42万円→12万円に圧縮。 OUTCOME 月額費用 72% 削減・年間363万円コスト削減・常時稼働サーバーゼロ化 詳細を見る](https://technosphere.co.jp/cloud-migration/serverless-cost-opt) FAQ ## よくあるご質問 本当にWindows Server 2003やCOBOLなど古いシステムでも対応できますか？ はい、対応しています。Windows NT・2000・2003、CentOS 4/5/6、Solaris、AS/400/COBOL、HP-UXなどの超レガシー環境への移行実績があります。ドキュメントが残っていないシステムや「誰もソースを触ったことがない」というシステムも、まず現状調査から始めますのでお気軽にご相談ください。 稼働中のシステムを止めずに移行できますか？ ほとんどのケースでゼロダウンタイムまたは最小停止時間での移行が可能です。Blue/Greenデプロイメント、DNS切り替え、レプリケーション活用などの手法を組み合わせます。業務への影響を最小化する計画を事前に詳細設計します。 クラウドからオンプレミスへの「逆移行」も対応できますか？ はい、むしろ逆移行は弊社の得意分野の一つです。「クラウドの費用が想定より高い」「データを国内のオンプレに置きたい」「レスポンスが遅い」などの理由でのクラウド撤退を多数支援しています。ハイブリッド構成（一部オンプレ＋一部クラウド）への移行も対応します。 移行の費用はどのくらいかかりますか？ システムの規模・複雑性・移行後の構成によって大きく異なります。シンプルなLift&Shift移行であれば数十万円〜、大規模なリアーキテクチャを伴う移行では数百万〜数千万円規模になります。まず無料の現状調査・お見積もりを実施しますので、お気軽にご連絡ください。 移行後の運用保守も対応していますか？ はい、移行後の継続サポートも承っています。24時間監視・障害対応・セキュリティパッチ管理・コスト最適化レビュー・月次レポートなど、お客様のニーズに合わせた保守プランをご提案します。 大阪以外の企業でも対応できますか？ はい、全国対応しています。リモートでの調査・移行作業が中心ですが、必要に応じて現地訪問も対応可能です。これまでも東京・名古屋・福岡・北海道など全国各地のお客様の移行を支援しています。 クラウド移行を依頼する会社の選び方は？ クラウド移行の受託会社を選ぶ際は、(1)自社の現行環境（レガシーOS・言語・基盤）への対応実績、(2)特定クラウドに偏らずAWS/Azure/GCP/OCI/さくら等を中立に提案できるか、(3)移行だけでなく移行後の運用・コスト最適化まで伴走できるか、(4)現状調査・見積もりの透明性、の4点を確認することをおすすめします。テクノスフィアは100件超の移行実績をもとに、現状調査から本番移行・運用までを一気通貫で受託しています。 クラウド移行にはどれくらいの期間がかかりますか？ 規模と方式によって異なります。サーバー数台のシンプルなLift&Shift移行であれば数週間〜1か月程度、業務システムのリアーキテクチャを伴う移行では数か月〜が目安です。まず現状調査で対象範囲・依存関係・停止可能時間を整理し、リスクの低い対象から段階的に移行する計画をご提案します。 FREE CONSULTATION ## まずは無料で現状をお聞かせください。 「うちのは特殊で難しい」も大歓迎。 初回ヒアリングは無料です。現在のシステム構成・お困りごとをお聞きして、 移行の可否・概算費用・スケジュールを概算でお伝えします。 まずはお気軽にお問い合わせください。 [無料相談・お問い合わせ](https://technosphere.co.jp/contact) [電話で相談する](tel:0000000000) 初回ヒアリング・概算見積もりは完全無料です [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [技術コラム](https://technosphere.co.jp/blog/) [採用情報](https://technosphere.co.jp/recruit) [プライバシーポリシー](https://technosphere.co.jp/privacy) © 2023 Technosphere Inc. - [Facebook](https://www.facebook.com/technosphere.co.ltd) - [X（旧Twitter）](https://x.com/technosphere_co) - [Instagram](https://www.instagram.com/technosphere_co/) - [TikTok](https://www.tiktok.com/@technosphere.co) --- # IT企業｜SaaSプロダクトのAWS→GCP乗り換えでML基盤強化・費用最適化｜テクノスフィア > AWSで運用するSaaSプロダクトをGCPへ移行。ECS→GKE、RDS→Cloud SQL、S3→Cloud Storageへ移行しBigQuery・Vertex AIでML基盤を一新。コスト45%削減・デプロイ頻度3倍向上の事例。 URL: https://technosphere.co.jp/cloud-migration/itfirm-aws-gcp [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [採用情報](https://technosphere.co.jp/recruit) ** IT・SaaS企業 / クラウド間移行 # SaaSプロダクトの AWS → GCP 乗り換えで ML基盤を強化・費用最適化 45%MLコスト削減 3倍デプロイ頻度向上 6ヶ月移行期間 0件サービス障害ゼロ ## プロジェクト概要 東京都内に本社を置くIT系スタートアップ企業様。BtoB向けの業務効率化SaaSプロダクトをAWSで運用していましたが、機械学習・データ分析機能の強化を目的に、GCPへの移行を決断されました。 AWS ECSで動くマイクロサービス群、RDS（PostgreSQL）のデータベース、S3の大量ファイルストレージを、それぞれGKE・Cloud SQL・Cloud Storageへ移行。さらにBigQueryとVertex AIを活用してML基盤を一新し、データ活用の幅を大きく広げることに成功しました。 テクノスフィアはインフラ設計・移行実装の全工程をワンストップで担当。本番サービスへの影響ゼロで6ヶ月での移行を実現しました。 ## 課題と解決アプローチ ⚠ CHALLENGE（課題） - AWSのML系サービス（SageMaker）のコストが高く拡張に限界 - ECSのクラスター管理が複雑でデプロイに時間がかかる - BigQuery相当の大規模データ分析基盤がない - S3のデータ転送コストが毎月高額に - 本番稼働中のSaaSのため無停止での移行が必須 → ✅ SOLUTION（解決策） - ECS → GKE（Autopilot）でKubernetes移行・CI/CD刷新 - RDS(PostgreSQL) → Cloud SQL（Postgres）にデータ移行 - S3 → Cloud Storageへオブジェクトストレージ移行 - BigQuery導入でデータウェアハウスを一元化 - Vertex AIでML基盤を構築・SageMakerからモデル移植 ## 移行前後のアーキテクチャ比較 【移行前：AWS構成】 AWS ECS (Fargate) × 8マイクロサービス AWS RDS PostgreSQL 13（Multi-AZ） Amazon S3 × 4バケット（計 12TB） AWS SageMaker：MLモデル学習・推論 Amazon Redshift：データウェアハウス AWS CodePipeline / CodeBuild：CI/CD CloudWatch：監視・ログ収集 Route53 / ALB：DNS・ロードバランサ → 【移行後：GCP構成】 GKE Autopilot × 8マイクロサービス Cloud SQL PostgreSQL 15（HA構成） Cloud Storage × 4バケット（計 12TB） Vertex AI：MLモデル学習・推論 BigQuery：データウェアハウス（列指向） Cloud Build / Artifact Registry：CI/CD Cloud Monitoring / Cloud Logging：監視 Cloud DNS / Cloud Load Balancing：DNS・LB ## 移行の進め方（6段階アプローチ） ### Phase 1：調査・設計（月1） 既存AWSアーキテクチャのインベントリ調査、依存関係マッピング、GCPへの対応サービスの選定。移行コスト試算とROI分析も実施。 ### Phase 2：GCP基盤構築（月1〜2） Terraform によるGCPインフラのコード化（Infrastructure as Code）。VPC・サブネット・IAM・GKEクラスター・Cloud SQL・Cloud Storageを構築。 ### Phase 3：コンテナ移行（月2〜3） ECS TaskDefinitionからKubernetes Manifestへの変換。Helmチャートで各マイクロサービスをGKEにデプロイ。Cloud Build でCI/CDパイプラインを再構築。 ### Phase 4：データ移行（月3〜4） RDS → Cloud SQL：pg_dumpベースの移行＋Database Migration Service（DMS相当）での差分同期。S3 → Cloud Storage：Storage Transfer Serviceで12TBを並列転送（5日間）。 ### Phase 5：ML基盤移行（月4〜5） SageMakerのモデルをONNX形式でエクスポートし、Vertex AIにインポート。BigQueryへRedshiftのデータを移行し、分析クエリを書き換え。 ### Phase 6：切り替え・並行稼働（月5〜6） AWS・GCP並行稼働期間を2週間設け、全APIの応答を比較検証。DNS切り替えはTraffic Splittingで10%→50%→100%と段階移行し障害リスクをゼロに。 ## 移行結果・成果 45%ML処理コスト削減 （Vertex AI vs SageMaker） 3倍デプロイ頻度向上 （月8回→月25回） 80%データ分析クエリ速度向上 （BigQuery列指向） 0件本番障害ゼロ （切り替え時） ## クラウド間移行（AWS → GCP）のポイント - **サービスの対応表を先に整理**：ECS/Fargate→GKE、SageMaker→Vertex AI、Redshift→BigQueryなど、移行前に対応サービスを確定させることで設計のブレをなくします。 - **Terraformでインフラをコード化**：AWSとGCPのTerraformプロバイダーは異なりますが、ステート管理のノウハウは共通です。Infrastructure as Codeで再現性を担保。 - **データ転送コストに注意**：AWS→GCPへの大量データ転送はEgress課金が発生します。Storage Transfer Serviceを活用し、転送中のコストを最小化。 - **BigQueryの列指向の活用**：RDBの行指向からBigQueryの列指向に変わることで、集計クエリが劇的に速くなります。データモデルの見直しも並行して実施。 [← 前の事例 物流業：COBOL/AS400 → Azure フルリプレイス](https://technosphere.co.jp/cloud-migration/logistics-cobol-azure) [次の事例 → 自治体：Solaris/SPARC → OCI 移行](https://technosphere.co.jp/cloud-migration/government-solaris-oci) プロジェクト概要 - 業種IT・SaaS企業 - 規模従業員120名 - 移行元AWS（ECS・RDS・S3） - 移行先GCP（GKE・Cloud SQL・BigQuery） - パターンRe-platform（再プラットフォーム化） - 期間約6ヶ月 - 停止時間ゼロ（段階的DNS切り替え） - データ量約12TB（S3）＋2TB（RDS） AWSからGCP・Azure・OCIへの クラウド間移行もお任せください 現在のクラウドから別のクラウドへの移行・コスト最適化をご支援します。まずはご相談ください。 [無料相談はこちら](https://technosphere.co.jp/contact) 初回ヒアリング無料 ## クラウド間の乗り換えも、コスト最適化もテクノスフィアにお任せください。 [無料相談・お問い合わせ](https://technosphere.co.jp/contact) [事例一覧に戻る](https://technosphere.co.jp/cloud-migration/) [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [技術コラム](https://technosphere.co.jp/blog/) [採用情報](https://technosphere.co.jp/recruit) [プライバシーポリシー](https://technosphere.co.jp/privacy) © 2023 Technosphere Inc. - [Facebook](https://www.facebook.com/technosphere.co.ltd) - [X（旧Twitter）](https://x.com/technosphere_co) - [Instagram](https://www.instagram.com/technosphere_co/) - [TikTok](https://www.tiktok.com/@technosphere.co) --- # 物流業｜30年稼働COBOL/AS400帳票システムをAzureへフルリプレイス｜テクノスフィア > 30年以上現役だったAS/400上のCOBOLシステムをAzure上のJava/SpringWebシステムへフルリプレイスした事例。処理時間90%短縮・ペーパーレス化・保守性大幅向上を実現。 URL: https://technosphere.co.jp/cloud-migration/logistics-cobol-azure [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [採用情報](https://technosphere.co.jp/recruit) ** 物流・運輸業 / COBOL帳票システム # 30年稼働のCOBOL/AS/400 帳票システムをAzureへ フルリプレイス 90%処理時間短縮 100%ペーパーレス化 0COBOLエンジニア 依存ゼロに 8ヶ月移行期間 ## プロジェクト概要 中部地方を中心に展開する物流・運輸会社様。1993年に導入したAS/400（IBM iSeries）上で動くCOBOL製の配送伝票・請求帳票システムが30年以上現役でした。AS/400のハードウェアEOLが迫り、COBOLに精通したエンジニアも社内に残り1名（定年間近）という状況で「今のうちに移行しなければ」とご決断されました。 単純な移行ではなく、この機会に帳票業務全体をモダン化・ペーパーレス化することを目標にフルリプレイスをご提案しました。 ## 課題と解決アプローチ ⚠ CHALLENGE（課題） - AS/400 ハードウェアEOL - COBOLエンジニアが社内に1名のみ（定年間近） - 30年分の改修でソースが誰も追えない状態 - 日次バッチ処理が6時間かかる - 紙の伝票が月間3万枚・保管コストが膨大 → ✅ SOLUTION（解決策） - Azure VM上のJava/Spring Bootへフルリプレイス - COBOLロジックをリバースエンジニアリングし再実装 - Azure SQL Database（マネージドDB）に移行 - バッチをAzure Batch + 並列処理で高速化 - 帳票をPDF電子化、Azure Blob Storageで保管 ## 移行後のアーキテクチャ（Azure構成） 【移行後：Azure構成（東日本リージョン）】 Azure Virtual Network ├── Azure App Service: Java 17 / Spring Boot 3.x │ └── 配送管理・伝票発行Webシステム（ブラウザ操作） ├── Azure SQL Database: General Purpose (4vCores) │ └── 配送データ・顧客・請求データ（旧ISeriesDBから移行） ├── Azure Batch: 日次バッチ処理（並列化で6h→20分） ├── Azure Blob Storage: PDF帳票・画像（旧紙伝票スキャン含む） └── Azure Active Directory: 社員認証・権限管理 Azure Monitor / Application Insights: 監視 Azure Backup: 日次バックアップ 西日本リージョン: Geo冗長バックアップ ## COBOLリプレイスの進め方 COBOLリプレイスで最も難しいのは、**30年分の改修で誰も全体像を把握していないロジック**の解読です。テクノスフィアでは以下のアプローチで進めました： - **Step 1 インプット・アウトプット分析**：入力データ（EDI・CSV）と出力帳票を完全にドキュメント化。ロジック詳細ではなく「何が入って何が出るか」を先に確定。 - **Step 2 テストデータ収集**：過去5年分の実データ（入力→出力ペア）を収集し、自動テストスイートを構築。新システムが同じ結果を出すことを機械的に検証。 - **Step 3 段階的置き換え**：帳票種別ごとに順次Javaで再実装。1種完了→テスト合格→次の帳票、のサイクルで8ヶ月かけて全帳票を移行。 - **Step 4 並行稼働検証**：本番の旧COBOLと新Javaシステムを2ヶ月並行稼働し、全帳票の一致を確認してから切り替え。 ## 移行結果・成果 90%バッチ処理時間短縮 （6時間→20分） 3万枚月間紙伝票をゼロ化 （PDF電子化） 0COBOLスキル依存 ゼロに（Java移行） 35%月額インフラコスト削減 （AS/400保守費比較） [← 前の事例 医療機関：AWS → オンプレ逆移行](https://technosphere.co.jp/cloud-migration/medical-aws-onprem) [次の事例 → IT企業：AWS → GCP 乗り換え](https://technosphere.co.jp/cloud-migration/itfirm-aws-gcp) プロジェクト概要 - 業種物流・運輸業 - 規模従業員500名 - 移行元AS/400 / COBOL - 移行先Microsoft Azure - パターンRe-architect（全面再構築） - 期間約8ヶ月 - 停止時間週末2日間（計画停止） - 帳票種別47種類 COBOLシステムの移行もお任せください AS/400・COBOL・旧メインフレームの移行実績があります。まずはご相談ください。 [無料相談はこちら](https://technosphere.co.jp/contact) 初回ヒアリング無料 ## COBOL・レガシーシステムの移行、どこよりも詳しくご支援します。 [無料相談・お問い合わせ](https://technosphere.co.jp/contact) [事例一覧に戻る](https://technosphere.co.jp/cloud-migration/) [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [技術コラム](https://technosphere.co.jp/blog/) [採用情報](https://technosphere.co.jp/recruit) [プライバシーポリシー](https://technosphere.co.jp/privacy) © 2023 Technosphere Inc. - [Facebook](https://www.facebook.com/technosphere.co.ltd) - [X（旧Twitter）](https://x.com/technosphere_co) - [Instagram](https://www.instagram.com/technosphere_co/) - [TikTok](https://www.tiktok.com/@technosphere.co) --- # 製造業｜Windows Server 2003からAWSへ無停止移行｜クラウドマイグレーション事例｜テクノスフィア > 20年以上稼働し続けた製造業の生産管理システム（Windows Server 2003）をAWSへ無停止で移行した事例。Lift&Shift手法、工場ライン無停止、運用コスト40%削減を実現。 URL: https://technosphere.co.jp/cloud-migration/manufacturing-windows-aws [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [採用情報](https://technosphere.co.jp/recruit) ** 製造業・生産管理システム # Windows Server 2003 稼働の 生産管理システムを AWSへ無停止移行 40% 運用コスト削減 80% 障害対応時間短縮 0 工場ライン停止件数 4ヶ月 移行期間 ## プロジェクト概要 西日本に複数の工場を持つ製造業のお客様。2003年に導入した生産管理システムが20年以上現役で稼働しており、Windows Server 2003上で動作するカスタムVBアプリケーション＋SQL Server 2000という構成でした。 2023年、サーバーハードウェアの老朽化（HDDのS.M.A.R.T.エラーが多発）と、Windows Server 2003のサポート終了（2015年）による脆弱性リスクが重なり、「このまま使い続けるのは危険」とご判断。テクノスフィアにご相談いただきました。 ## 課題と解決アプローチ ⚠ CHALLENGE（課題） - Windows Server 2003 / SQL Server 2000 がEOL - VBアプリのソースが一部紛失・誰も触れない - 24時間稼働の工場ラインと連携しており停止不可 - ハードウェアが老朽化しいつ壊れてもおかしくない - 担当SEが退職しドキュメントが残っていない → ✅ SOLUTION（解決策） - AWS EC2（Windows Server 2022）へLift&Shift移行 - アプリのリバースエンジニアリングでドキュメント再作成 - 旧環境と並行稼働→段階切り替えでゼロ停止を実現 - SQL Server 2000 → SQL Server 2019への段階移行 - CloudWatch + Systems Managerで24時間監視体制構築 ## 移行前のシステム構成 【移行前：オンプレミス構成】 物理サーバー（自社サーバールーム） ├── 生産管理サーバー: Windows Server 2003 SP2 │ └── 生産管理アプリ（VB6.0製カスタムシステム） ├── DBサーバー: SQL Server 2000（製造実績・在庫データ約150GB） ├── ファイルサーバー: Windows Server 2003（設計図面・帳票約500GB） └── 工場端末（Windows XP × 12台）─── 専用線で接続 バックアップ：磁気テープ（週1回）/ DR構成なし ## 移行後のアーキテクチャ（AWS構成） 【移行後：AWS構成（東京リージョン）】 VPC (10.0.0.0/16) ├── パブリックサブネット │ └── ALB（アプリケーションロードバランサー） ├── プライベートサブネット（AZ-a） │ ├── EC2: Windows Server 2022 (m5.xlarge) │ │ └── 生産管理アプリ（VB6.0 → .NET移植） │ └── RDS: SQL Server 2019 (db.m5.large, Multi-AZ) └── プライベートサブネット（AZ-c） └── RDSスタンバイ（自動フェイルオーバー） S3: 設計図面・帳票ストレージ (500GB → Intelligent-Tiering) CloudWatch: 24時間監視・アラート AWS Backup: 日次バックアップ・30日保持 DirectConnect: 工場専用線との接続維持 ## 移行タイムライン Phase 1 ／ Month 1 現状調査・アセスメント サーバー構成・アプリケーション動作確認・ネットワーク構成の調査。VB6.0ソースのリバースエンジニアリングとSQL Server 2000のスキーマ・データ量の洗い出し。移行計画書の策定。 Phase 2 ／ Month 2 AWS環境構築・アプリ修正 VPC・EC2・RDS・DirectConnect設定。VB6.0アプリのSQL Server 2019互換対応（SQL構文修正）。開発環境での動作検証。工場端末との接続テスト。 Phase 3 ／ Month 3 並行稼働・データ移行 旧環境と新環境を並行稼働。DMS（Database Migration Service）でSQL Server 2000から2019へのデータ継続同期。業務データの整合性確認を毎日実施。 Phase 4 ／ Month 4 本番切り替え・旧環境停止 土日夜間の計画メンテナンス時間帯にDNS切り替えを実施（実停止時間：約45分）。工場端末の接続先変更。1週間の並行監視後、旧サーバーを停止。移行完了。 ## 移行結果・成果 40% 月額運用コスト削減 （ハードウェア保守費→AWS費用） 80% 障害対応時間短縮 （CloudWatch自動通知効果） 99.9% 稼働率達成 （Multi-AZ構成） 0 工場ライン影響ゼロ （業務中断なし） ### お客様の声 > 「20年以上誰も手を付けていないシステムで、他社に相談したら断られ続けていました。テクノスフィアさんは最初から『できます』と言ってくれて、その言葉通りに工場を一度も止めることなく移行してくれました。今はAWSの管理コンソールで全部見えるし、何かあればすぐ連絡が来る。本当に頼んでよかったです。」 — 製造業 A社 / 情報システム部長 ## 使用した主要技術・サービス AWS EC2 (Windows Server 2022) Amazon RDS (SQL Server 2019) AWS DMS Amazon S3 AWS DirectConnect CloudWatch AWS Backup AWS Systems Manager Terraform VB6.0 (.NET互換対応) [← ケーススタディ一覧 すべての事例を見る](https://technosphere.co.jp/cloud-migration/#cases) [次の事例 → 小売業：オンプレ→さくらのクラウド](https://technosphere.co.jp/cloud-migration/retail-onprem-sakura) プロジェクト概要 - 業種製造業 - 規模従業員300名 - 移行元Windows Server 2003 / SQL Server 2000 - 移行先AWS（東京リージョン） - パターンLift & Shift - 期間約4ヶ月 - 停止時間約45分（計画停止のみ） - データ量約650GB（DB+ファイル） 同様の課題でお悩みですか？ まずは無料でご相談ください。現状をお聞きして、移行の可否と概算費用をお伝えします。 [無料相談はこちら](https://technosphere.co.jp/contact) 初回ヒアリング無料 関連サービス - [移行パターン詳細](https://technosphere.co.jp/cloud-migration/#patterns) - [移行の進め方](https://technosphere.co.jp/cloud-migration/#flow) - [他のケーススタディ](https://technosphere.co.jp/cloud-migration/#cases) ## 関連ケーススタディ [（図: 小売業 さくらのクラウド） 小売業 / さくらのクラウド 老朽化在庫管理システムをさくらのクラウドへ移行・コスト60%削減](https://technosphere.co.jp/cloud-migration/retail-onprem-sakura) [（図: 物流 COBOL Azure） 物流業 / COBOL → Azure 30年稼働COBOLシステムをAzureへフルリプレイス](https://technosphere.co.jp/cloud-migration/logistics-cobol-azure) [（図: 自治体 Solaris OCI） 公共 / Solaris → OCI Solaris/SPARC税務システムをOCIへ移行](https://technosphere.co.jp/cloud-migration/government-solaris-oci) ## 同じような課題を抱えていませんか？ まずは無料でご相談ください。 Windows Server 2003・EOL環境・誰も触れないレガシーシステム、すべてお任せください。 [無料相談・お問い合わせ](https://technosphere.co.jp/contact) [事例一覧に戻る](https://technosphere.co.jp/cloud-migration/) [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [技術コラム](https://technosphere.co.jp/blog/) [採用情報](https://technosphere.co.jp/recruit) [プライバシーポリシー](https://technosphere.co.jp/privacy) © 2023 Technosphere Inc. - [Facebook](https://www.facebook.com/technosphere.co.ltd) - [X（旧Twitter）](https://x.com/technosphere_co) - [Instagram](https://www.instagram.com/technosphere_co/) - [TikTok](https://www.tiktok.com/@technosphere.co) --- # 医療機関｜AWSからオンプレミスへの逆移行（クラウド撤退）事例｜テクノスフィア > 電子カルテシステムをAWSからプライベートサーバーへ逆移行。月額費用55%削減・レスポンス3倍高速化・個人情報保護法対応を同時に実現。クラウド撤退支援の事例です。 URL: https://technosphere.co.jp/cloud-migration/medical-aws-onprem [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [採用情報](https://technosphere.co.jp/recruit) ** 医療機関 / 電子カルテ # 電子カルテシステムの AWSからオンプレミスへの逆移行 コスト・セキュリティ・速度を全て改善 55%月額費用削減 3倍レスポンス高速化 100%個人情報保護対応 5ヶ月移行期間 ## プロジェクト概要 関西圏のクリニック（診療科：内科・外科・小児科）のお客様。5年前にシステム会社の提案でAWS上に電子カルテシステムを構築していました。しかし、①月額クラウド費用が当初見積もりの2.5倍に膨らんでいた、②カルテ呼び出し時のレスポンスが遅く診察に影響が出ていた、③患者データをクラウドに置くことへのコンプライアンス上の懸念が院長から出た、という3つの課題が顕在化していました。 「クラウドをやめてサーバーを院内に置きたい」というご要望に対し、テクノスフィアではDR用にAWSを残したハイブリッド構成をご提案しました。 ## 課題と解決アプローチ ⚠ CHALLENGE（課題） - AWS費用が月額80万円超（当初予算の2.5倍） - カルテ読み込みに3〜5秒かかり診察に支障 - 患者データをAWSに置くことへの法的懸念 - 担当SEが退職し、AWS構成を誰も理解していない - 停止すると診察ができないため慎重に移行必要 → ✅ SOLUTION（解決策） - 院内プライベートサーバーへメインDB移行 - AWSをDR（災害復旧）環境として維持 - 院内LAN完結でレスポンス劇的改善 - 個人情報保護法・医療情報安全管理指針への準拠 - 夜間・休日作業で診察への影響ゼロ ## 移行後のアーキテクチャ（ハイブリッド構成） 【移行後：ハイブリッド構成】 【院内プライベートサーバー（メイン）】 ├── 電子カルテサーバー: Ubuntu 22.04 (16Core/64GB RAM) │ └── 電子カルテアプリ（院内LAN完結・平均レスポンス0.3秒） ├── DBサーバー: PostgreSQL 15（患者データ） ├── ファイルサーバー: DICOM画像・検査結果（NAS 20TB） └── セキュリティ: ファイアウォール・IDS/IPS・ログ監視 ↕ VPN（暗号化通信） 【AWS（DR・バックアップ専用）】 └── RDS Snapshot（日次バックアップ・90日保持） └── S3 Glacier（アーカイブ・DICOM長期保存） └── 障害時はRoute53でAWS環境へ自動フェイルオーバー ## 移行結果・成果 55%月額費用削減 （80万→36万円/月） 3倍レスポンス改善 （5秒→0.3秒） 100%法的コンプライアンス 対応完了 99.9%可用性維持 （ハイブリッドDR） ## 移行タイムライン Month 1 AWS構成調査・要件定義 既存AWS構成のリバースエンジニアリング（担当SE退職のため設計書なし）。院内サーバースペース・電源・ネットワーク確認。移行計画策定。 Month 2-3 院内サーバー設置・環境構築 物理サーバー選定・調達・設置。Ubuntu 22.04・PostgreSQL 15・電子カルテアプリ環境構築。セキュリティ設定（ファイアウォール・IDS・ログ監視）。 Month 4 データ移行・並行稼働テスト 患者データ（約200GB）の移行・整合性確認。院内端末での動作テスト。AWS→院内サーバーへの自動同期設定。医師・スタッフによる操作確認。 Month 5 本番切り替え・DR設定 日曜夜間に切り替え実施（停止時間：約1時間）。AWSをDR専用に縮小（費用を最小化）。VPN設定・DR手順書作成。運用引き継ぎ・スタッフ研修。 ### 逆移行を検討される方へ 「クラウドに移行したが思ったよりコストがかかる」「クラウドをやめて自社サーバーに戻したい」という相談は年々増加しています。テクノスフィアでは、クラウドが本当に適しているかどうかを客観的に試算した上で、最適な構成をご提案します。「クラウドをやめる」という判断も、必要であれば積極的にお勧めしています。 [← 前の事例 小売業：さくらのクラウド移行](https://technosphere.co.jp/cloud-migration/retail-onprem-sakura) [次の事例 → 物流業：COBOL → Azure フルリプレイス](https://technosphere.co.jp/cloud-migration/logistics-cobol-azure) プロジェクト概要 - 業種医療機関 - 規模クリニック / 医師4名 - 移行元AWS（EC2+RDS） - 移行先院内プライベートサーバー - パターン逆移行＋ハイブリッド - 期間約5ヶ月 - 停止時間約1時間（日曜夜間） - データ量約200GB（患者データ） クラウド撤退・逆移行のご相談 「クラウドをやめたい」「コストを下げたい」お気軽にご相談ください。 [無料相談はこちら](https://technosphere.co.jp/contact) 初回ヒアリング無料 ## クラウドからの撤退・逆移行もお任せください。 [無料相談・お問い合わせ](https://technosphere.co.jp/contact) [事例一覧に戻る](https://technosphere.co.jp/cloud-migration/) [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [技術コラム](https://technosphere.co.jp/blog/) [採用情報](https://technosphere.co.jp/recruit) [プライバシーポリシー](https://technosphere.co.jp/privacy) © 2023 Technosphere Inc. - [Facebook](https://www.facebook.com/technosphere.co.ltd) - [X（旧Twitter）](https://x.com/technosphere_co) - [Instagram](https://www.instagram.com/technosphere_co/) - [TikTok](https://www.tiktok.com/@technosphere.co) --- # 小売業｜老朽化在庫管理システムをさくらのクラウドへ移行・コスト60%削減｜テクノスフィア > 専用サーバーで動作するCentOS 6の在庫管理・受発注システムをさくらのクラウドへ移行。国内データセンター・低コスト・高可用性を同時実現したクラウドマイグレーション事例。 URL: https://technosphere.co.jp/cloud-migration/retail-onprem-sakura [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [採用情報](https://technosphere.co.jp/recruit) ** 小売・卸売業 / 在庫管理システム # 老朽化した在庫管理システムを さくらのクラウドへ移行し コスト60%削減 60%月額費用削減 3ヶ月で移行完了 100%自動バックアップ化 ## プロジェクト概要 近畿圏に10店舗を展開する小売・卸売業のお客様。2008年に自社構築した在庫管理・受発注システムが、専用サーバー（CentOS 6）上でPHP+MySQLで動作していました。CentOS 6のEOL（2020年）を過ぎても使い続けており、ハードウェアも老朽化していました。 「AWS・Azure・GCPは価格が高い」「データは国内に置きたい」という要望から、さくらのクラウドへの移行をご提案しました。 ## 課題と解決アプローチ ⚠ CHALLENGE（課題） - CentOS 6がEOL（脆弱性リスク） - 専用サーバーのHDDが老朽化 - バックアップが手動（週1回）で不十分 - 大手クラウドは月額費用が高い - データを海外サーバーに置きたくない → ✅ SOLUTION（解決策） - さくらのクラウド（大阪DC）へ移行 - OS をCentOS 6→Rocky Linux 9へ更新 - PHP 5→PHP 8、MySQL 5→8へアップグレード - さくらオブジェクトストレージで自動バックアップ - 国内DCでデータ主権・速度・コスト全て解決 ## 移行後のアーキテクチャ（さくらのクラウド構成） 【移行後：さくらのクラウド構成（大阪リージョン）】 さくらのクラウド スイッチ（VPC相当） ├── Webサーバー: Rocky Linux 9 (2Core/4GB) │ ├── Nginx + PHP-FPM 8.2 │ └── 在庫管理・受発注アプリ（PHP→PHP8対応） ├── DBサーバー: Rocky Linux 9 (4Core/8GB) │ └── MySQL 8.0（マスタースレーブ構成） └── ファイルサーバー: さくらオブジェクトストレージ セキュリティグループ / パケットフィルタ Zabbix監視（別インスタンス） さくらのバックアップ：日次スナップショット テープバックアップ → 全自動化 ## 移行結果・成果 60%月額コスト削減 100%バックアップ自動化 3倍Webページ表示速度向上 0データ流出リスクゼロ （国内DC完結） ## 移行タイムライン Week 1-2 現状調査・PHP/MySQLバージョン互換性確認 PHP5→8の非互換API洗い出し。MySQL 5→8の文法変更点確認。データ量確認（DB約20GB、ファイル約80GB）。 Week 3-6 新環境構築・アプリ修正 さくらのクラウド上に新環境構築。PHP8対応コード修正（deprecated関数・型宣言の修正）。MySQL 8の厳格モード対応。動作テスト。 Week 7-10 並行稼働・データ同期 mysqlpumpでの継続データ同期。本番データでの最終テスト。バックアップ自動化の設定・確認。 Week 11-12 本番切り替え・旧環境停止 閉店後（夜間）にDNS切り替え実施。翌営業日に全店舗での動作確認。旧サーバー契約終了。 [← 前の事例 製造業：Windows Server 2003 → AWS](https://technosphere.co.jp/cloud-migration/manufacturing-windows-aws) [次の事例 → 医療機関：AWS → オンプレ逆移行](https://technosphere.co.jp/cloud-migration/medical-aws-onprem) プロジェクト概要 - 業種小売・卸売業 - 規模10店舗・従業員80名 - 移行元専用サーバー / CentOS 6 - 移行先さくらのクラウド（大阪） - パターンRe-platform - 期間約3ヶ月 - 停止時間約2時間（夜間） - データ量約100GB コスト削減・国内DC移行のご相談 「AWSは高い」「国内に置きたい」というご要望もお気軽にご相談ください。 [無料相談はこちら](https://technosphere.co.jp/contact) 初回ヒアリング無料 ## コスト削減・レガシーOS脱却のご相談、お気軽にどうぞ。 [無料相談・お問い合わせ](https://technosphere.co.jp/contact) [事例一覧に戻る](https://technosphere.co.jp/cloud-migration/) [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [技術コラム](https://technosphere.co.jp/blog/) [採用情報](https://technosphere.co.jp/recruit) [プライバシーポリシー](https://technosphere.co.jp/privacy) © 2023 Technosphere Inc. - [Facebook](https://www.facebook.com/technosphere.co.ltd) - [X（旧Twitter）](https://x.com/technosphere_co) - [Instagram](https://www.instagram.com/technosphere_co/) - [TikTok](https://www.tiktok.com/@technosphere.co) --- # EC系SaaS企業｜AWS EC2常時稼働からサーバーレス化でランニングコスト72%削減｜テクノスフィア > 常時稼働のAWS EC2をLambda・API Gateway・DynamoDB・S3へサーバーレス化。トラフィック連動の従量課金に変えることでクラウド月額費用を72%削減した事例。 URL: https://technosphere.co.jp/cloud-migration/serverless-cost-opt [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [採用情報](https://technosphere.co.jp/recruit) ** EC・SaaS企業 / クラウドコスト最適化 # AWS EC2常時稼働を サーバーレス化して ランニングコスト 72% 削減 72%月額クラウド費用削減 0台常時稼働サーバーゼロへ 3ヶ月移行期間 99.95%可用性向上 ## プロジェクト概要 アパレル向けBtoB受発注SaaSを運営する企業様。AWS上に**EC2インスタンス8台を常時稼働**させてAPIサーバー・バッチ処理・管理画面を運用していましたが、月額クラウド費用が増加の一途をたどり「トラフィックは深夜ほぼゼロなのにずっと課金されている」という課題が浮上しました。 分析したところ、リクエスト数のピーク（平日昼間）と閑散時（深夜・休日）の差が**約50倍**あることが判明。常時稼働型のEC2は閑散時にリソースを無駄に消費していました。テクノスフィアはアーキテクチャを全面的にサーバーレス構成へ再設計し、**トラフィックに完全連動する従量課金**に切り替えることでコスト問題を根本解決しました。 ## 移行前の問題：なぜコストが高いのか ⚠ BEFORE（移行前の構成と問題） - EC2（t3.large × 4台）でAPIサーバーを常時稼働 - EC2（t3.medium × 2台）でバッチ処理サーバーを常時稼働 - EC2（t3.small × 2台）で管理画面サーバーを常時稼働 - RDS MySQL（db.r5.large）を常時稼働 - 深夜・休日はトラフィックがほぼゼロだが課金は同額 - スパイク時はスケールアップが間に合わず503エラー発生 - 月額費用：約42万円（EC2+RDS+ALB等） → ✅ AFTER（サーバーレス化後） - APIサーバー → **AWS Lambda + API Gateway** - バッチ処理 → **AWS Lambda + EventBridge（スケジュール）** - 管理画面 → **S3 + CloudFront（静的配信）** - DB → **DynamoDB（オンデマンド）+ Aurora Serverless v2** - 非同期処理 → **SQS + Lambda** - 使った分だけ課金・深夜はほぼ0円 - 月額費用：約12万円（72%削減） ## サーバーレスアーキテクチャ構成図 SERVERLESS ARCHITECTURE ON AWS ▼ APIリクエストフロー 📱 クライアント ブラウザ / アプリ CloudFront CDN + WAF API Gateway REST API v2 ** λ Lambda Node.js 20.x DynamoDB オンデマンド ▼ 管理画面（静的配信） 🖥️ 管理者 ブラウザ CloudFront OAC設定済み S3 静的ファイル API Gateway 管理API ** λ Lambda 管理用関数 ▼ バッチ・非同期処理 ** EventBridge cron スケジュール ** λ Lambda バッチ関数 SQS 非同期キュー ** λ Lambda ワーカー関数 Aurora Serverless v2 集計・レポート用 ## 移行前後のコスト内訳比較 | コンポーネント | 移行前（EC2構成） | 移行後（サーバーレス） | 削減 | | APIサーバー | EC2 t3.large × 4台 約158,000円/月 | Lambda + API Gateway 約18,000円/月 | ▼ 89% | | バッチ処理 | EC2 t3.medium × 2台 約36,000円/月 | Lambda + EventBridge 約2,000円/月 | ▼ 94% | | 管理画面 | EC2 t3.small × 2台 約16,000円/月 | S3 + CloudFront 約1,500円/月 | ▼ 91% | | データベース | RDS MySQL db.r5.large 約88,000円/月 | DynamoDB + Aurora Serverless v2 約42,000円/月 | ▼ 52% | | その他（ALB・NAT等） | 約22,000円/月 | 約6,000円/月 | ▼ 73% | | 合計 | 約420,000円/月 | 約117,000円/月 | ▼ 72% 年間▼363万円 | ## 3ヶ月移行タイムライン Month 1 現状調査・コスト分析・設計 AWSコスト分析（Cost Explorer）でリソース別コスト内訳を可視化。トラフィックパターン分析（CloudWatch）でピーク・閑散の差を定量化。サーバーレス化可能箇所の特定と優先順位づけ。Lambda/DynamoのABC試算。新アーキテクチャ設計・APIインターフェース確定。 Month 2 Lambda関数実装・ステージング環境テスト APIサーバーのNode.js Expressロジックを Lambda関数に分割移植（約40関数）。Serverless Framework でデプロイ自動化（IaC化）。DynamoDB テーブル設計・RDSからのデータ移行。管理画面をReactで再構築しS3静的配信へ切り替え。ステージング環境で全APIの動作検証・負荷テスト。 Month 3 段階的本番切り替え・EC2撤去 API GatewayのRoute weighting機能で10%→50%→100%と段階的にLambdaへトラフィック移行。CloudWatchアラームでエラー率を監視しながら進行。全切り替え完了後、EC2インスタンスを順次停止・削除。Aurora Serverless v2 への最終データ移行。コスト確認・チューニング。 ## 移行の技術的ポイント ### Lambdaコールドスタート対策 サーバーレスの課題として挙げられる「コールドスタート（初回起動遅延）」に対し、以下の対策を実施しました。 - **Provisioned Concurrency**：常に一定数のLambdaを暖機状態に保ち、ユーザーが体感する初回遅延を解消。コスト増は最小限に抑えつつ、ユーザー体験を維持。 - **関数の軽量化**：不要な依存パッケージを削除し、Lambda Layerで共通ライブラリを分離。デプロイパッケージを最小化してコールドスタート時間を短縮。 - **接続プーリング**：Aurora Serverless v2へのDB接続はRDS Proxyを経由し、Lambda の大量並列起動時のDB接続枯渇を防止。 ### RDS → DynamoDB データモデル変換 RDSの正規化されたリレーショナルスキーマをDynamoDBの**シングルテーブル設計**に変換しました。主要なアクセスパターンを洗い出し、Partition Key / Sort Key を最適設計。N+1問題を発生させないDynamoDBらしいデータ取得パターンに変更することで、RDS比でクエリレスポンスを平均60%高速化しました。 ### Serverless Framework による IaC 化 全インフラをServerless Frameworkのyamlで定義し、`sls deploy`一発で全環境（dev/stg/prod）に再現可能な状態にしました。Lambda関数・API Gateway設定・DynamoDBテーブル・IAMロール・CloudWatch設定がすべてコードで管理されているため、設定ミスによる障害リスクを大幅に低減しています。 ## サーバーレスが向いているケース・向いていないケース ✅ サーバーレスが向いているケース - リクエスト数に波がある（深夜少・昼多など） - バッチ処理が定時実行中心 - マイクロサービス構成にできるAPI - 静的コンテンツ主体の管理画面・フロントエンド - 非同期メッセージ処理・キュー処理 - イベント駆動（ファイルアップロード→処理など） - スタートアップ・低コスト重視 ⚠ サーバーレスが向いていないケース - 常時高負荷・リクエストが均一に多い - 処理時間が15分を超える（Lambda上限） - メモリを大量に使う重いバッチ処理 - ステートフルな接続が必要（WebSocket 常時接続等） - 既存コードが大規模モノリスで分割が困難 - 厳格な実行環境・OS設定が必要なシステム ※ テクノスフィアでは現状分析を行い、サーバーレスが最適かどうかを含めて中立的にご提案します。向いていないケースでは、コンテナ化（ECS Fargate）やスポットインスタンス活用など別のコスト最適化手法をご提案します。 ## 移行結果・成果 72%月額クラウド費用削減 （42万円→12万円） 年間363万円コスト削減効果 （移行費用は約4ヶ月で回収） 60%APIレスポンス高速化 （DynamoDB最適化） 0台常時稼働サーバーゼロ （運用工数も大幅削減） [← 前の事例 自治体：Solaris/SPARC → OCI 移行](https://technosphere.co.jp/cloud-migration/government-solaris-oci) [最初の事例 → 製造業：Windows Server 2003 → AWS](https://technosphere.co.jp/cloud-migration/manufacturing-windows-aws) プロジェクト概要 - 業種EC・BtoB SaaS - 規模従業員45名・月間API呼び出し約2,000万件 - 移行元AWS EC2 × 8台 + RDS MySQL - 移行先Lambda + API Gateway + DynamoDB + Aurora Serverless v2 - パターンサーバーレス化（Re-architect） - 期間約3ヶ月 - 停止時間ゼロ（段階的トラフィック切り替え） - Lambda関数数約40関数 **コスト削減シミュレーション 現在のクラウド費用を入力すると、サーバーレス化後の概算コストをお見積もりします。 まずは無料ヒアリングにてコスト分析を実施します。ご相談ください。 クラウドコストが高い… まず現状分析から始めましょう 現在のAWS/Azure/GCPのコスト構造を分析し、どこをサーバーレス化・コンテナ化すると効果的かをご提案します。初回無料。 [無料コスト分析を依頼する](https://technosphere.co.jp/contact) 初回ヒアリング・コスト試算 無料 ## 「クラウド代が高すぎる」を解決します。サーバーレス化・コンテナ最適化はテクノスフィアへ。 [無料コスト分析を依頼する](https://technosphere.co.jp/contact) [サービス・事例一覧に戻る](https://technosphere.co.jp/cloud-migration/) [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [技術コラム](https://technosphere.co.jp/blog/) [採用情報](https://technosphere.co.jp/recruit) [プライバシーポリシー](https://technosphere.co.jp/privacy) © 2023 Technosphere Inc. - [Facebook](https://www.facebook.com/technosphere.co.ltd) - [X（旧Twitter）](https://x.com/technosphere_co) - [Instagram](https://www.instagram.com/technosphere_co/) - [TikTok](https://www.tiktok.com/@technosphere.co) --- # エンジニア採用を成功させる3つの戦略｜2026年版 URL: https://technosphere.co.jp/de-blog/2026-04-11-ai-recruitment-strategy ## はじめに エンジニアの有効求人倍率は依然として高水準が続いています。「求人を出しても応募が来ない」「面接してもオファーを辞退される」——こうした悩みを抱える企業は少なくありません。 この記事では、エンジニア採用を成功させるための3つの戦略を、実践的な視点からご紹介します。 ## 戦略1: 技術ブランディングの強化 ### なぜ技術ブランディングが重要か エンジニアは「どんな技術を使っているか」「技術的な挑戦ができるか」を重視して企業を選びます。給与や福利厚生だけでは差別化できない時代です。 ### 具体的な施策 **技術ブログの運営** - 社内で使っている技術スタックを公開 - 開発チームの課題解決プロセスを記事化 - 新技術の検証レポートを定期発信 **エンジニアイベントへの参加・主催** - connpassでの勉強会開催 - カンファレンスでのLT登壇 - ハッカソンのスポンサー **OSS活動** - 社内ツールのOSS化 - 既存OSSへのコントリビュート - GitHub上での活動を可視化 ## 戦略2: 採用プロセスの最適化 ### 応募から内定までのリードタイムを短縮 エンジニアの転職活動期間は平均2〜3ヶ月。優秀な人材ほど早く決まります。 **改善ポイント：** | プロセス | 改善前 | 改善後 | |---------|--------|--------| | 書類選考 | 3〜5日 | 即日〜1日 | | 一次面接日程調整 | 5〜7日 | 即日（AI面接活用） | | 一次面接 | 対面30分 | AI面接15分 | | 最終面接 | 1週間後 | 3日以内 | | オファー | 3日 | 即日 | **合計: 3週間 → 1週間に短縮** AI面接ツールを活用することで、一次面接の日程調整と実施を自動化し、大幅な時間短縮が可能です。 ### カジュアル面談の導入 正式な面接の前に、30分のカジュアル面談を設けることで、候補者の心理的ハードルを下げ、応募率を向上させます。 ## 戦略3: オンボーディングの充実 ### 入社後3ヶ月が定着率を左右する せっかく採用したエンジニアが早期離職するケースは珍しくありません。入社後3ヶ月のオンボーディング体験が定着率を大きく左右します。 ### 効果的なオンボーディング施策 **メンター制度** - 先輩エンジニアが1対1でサポート - 週1回の定期1on1を3ヶ月間実施 - 技術面だけでなく組織文化への適応も支援 **段階的なタスクアサイン** 1. **Week 1-2**: 環境構築 + 小さなバグ修正 2. **Week 3-4**: 既存機能の小改修 3. **Month 2**: 新機能の設計・実装（ペアプロ） 4. **Month 3**: 独立した機能開発 **ペアプログラミング文化** 新人に限らず、日常的にペアプロを実施することで、知識共有とコードレビューの効率化を同時に実現します。 ## まとめ エンジニア採用は「選ばれる企業になる」ことが最も重要です。 1. **技術ブランディング**で認知を獲得 2. **採用プロセス最適化**でスピードを上げる 3. **オンボーディング充実**で定着率を向上 この3つの戦略を実践することで、採用競争力を大幅に高めることができます。 --- # AI時代の営業戦略｜リード獲得を自動化する5つの手法 URL: https://technosphere.co.jp/de-blog/2026-04-11-ai-sales-lead-generation ## はじめに 「テレアポを100件かけても商談につながるのは3件」——こんな非効率な営業活動に悩んでいませんか？ AI技術を活用することで、質の高いリードを効率的に獲得し、営業チームの生産性を劇的に向上させることが可能です。この記事では、すぐに実践できる5つの手法をご紹介します。 ## 手法1: Webサイトの行動分析によるホットリード検出 自社サイトの訪問者の行動データを分析し、購買意欲の高い「ホットリード」を自動検出します。 **注目すべき行動シグナル：** - 料金ページを2回以上閲覧 - 導入事例ページに3分以上滞在 - お問い合わせページに到達（未送信でも） - 同一企業から複数人がアクセス これらのシグナルをスコアリングし、営業チームに自動通知する仕組みを構築します。 ## 手法2: AI搭載チャットボットでの一次対応 Webサイトにチャットボットを設置し、24時間365日の問い合わせ対応を自動化します。 **効果的な設計ポイント：** - 最初の3往復で課題・予算・導入時期をヒアリング - 回答内容に応じてスコアリング - 高スコアの見込み客は即座に営業担当へ通知 - 低スコアでもメールナーチャリングで育成 ## 手法3: SNSリスニングによるニーズ検出 X（Twitter）やLinkedInの投稿をモニタリングし、自社サービスに関連する悩みや課題をリアルタイムに検出します。 **検出キーワード例：** - 「○○に困っている」「○○を探している」 - 「誰か○○できる会社知りませんか」 - 競合製品への不満ツイート ## 手法4: コンテンツマーケティング×SEO 専門性の高い技術記事・事例記事を定期的に発信し、検索エンジン経由でリードを獲得します。 **成功のポイント：** - ロングテールキーワードを狙う（競合が少ない） - 記事末尾に具体的なCTAを設置 - ホワイトペーパーのダウンロードで連絡先を取得 - 記事の更新頻度を週1本以上に維持 ## 手法5: メールナーチャリングの自動化 獲得したリードに対して、段階的なメール配信を自動化します。 **配信シナリオ例：** 1. **Day 1**: お礼メール + 関連記事の紹介 2. **Day 3**: 課題解決のヒント（教育コンテンツ） 3. **Day 7**: 導入事例の紹介 4. **Day 14**: 無料相談のご案内 5. **Day 30**: 限定キャンペーンの案内 開封率・クリック率をトラッキングし、反応の良いリードを優先的にフォローします。 ## まとめ AI時代の営業は「数をこなす」から「質を高める」へシフトしています。上記5つの手法を組み合わせることで、営業効率を3倍以上に改善した事例もあります。 まずは自社サイトの行動分析から始めてみてはいかがでしょうか。 --- # エッジAIで製造ラインの外観検査を自動化する方法 URL: https://technosphere.co.jp/de-blog/2026-04-11-edge-ai-manufacturing ## はじめに 製造業における品質管理は、これまで人の目に頼った外観検査が主流でした。しかし、検査員の疲労や個人差による判定のバラつき、人手不足は深刻な課題です。 この記事では、エッジAI（NVIDIA Jetson）を活用した外観検査の自動化について、技術的な観点から解説します。 ## エッジAIとは？ エッジAIとは、クラウドではなく現場のデバイス上でAI推論を実行する技術です。 **クラウドAIとの比較：** | 項目 | クラウドAI | エッジAI | |------|----------|---------| | レイテンシ | 100ms〜数秒 | 10ms以下 | | 通信コスト | 高い | ほぼゼロ | | プライバシー | データ外部送信 | 現場完結 | | オフライン | 不可 | 可能 | 製造ラインでは**リアルタイム性**が求められるため、エッジAIが最適です。 ## 外観検査システムの構成 ### ハードウェア - **カメラ**: 産業用GigEカメラ（5MP以上推奨） - **照明**: LEDリング照明（均一な照射が重要） - **エッジデバイス**: NVIDIA Jetson Orin NX - **PLC連携**: Modbus TCP/IPでライン制御と連動 ### ソフトウェア - **推論エンジン**: YOLOv8 + TensorRT - **前処理**: OpenCV - **管理画面**: Webダッシュボード（Flask） ## 検知精度を上げるポイント ### 1. 学習データの品質 不良品のサンプルを最低500枚以上用意することが重要です。データ拡張（回転・反転・明度変更）で効果的にデータ量を増やせます。 ### 2. 照明環境の統一 検査精度の80%は照明で決まると言っても過言ではありません。外乱光を遮断し、均一な照明環境を構築することが最優先です。 ### 3. モデルの定期的な再学習 製品の仕様変更やカメラの経年劣化に対応するため、3〜6ヶ月ごとのモデル更新を推奨します。 ## まとめ エッジAIによる外観検査は、初期投資を抑えつつ検査精度と生産性を大幅に向上させることができます。特に中小製造業にとって、人手不足解消の有力な手段です。 導入をご検討の方は、お気軽にご相談ください。 --- # カメラ画像AIであらゆる状態を検知！人物・車両・フォークリフトの安全管理 URL: https://technosphere.co.jp/de-blog/2026-04-12-ai-camera-action-detection テクノスフィアがご提供する「カメラ画像AI」は、製品のキズや異物を探す『製品検査』だけではありません。 工場、倉庫、駐車場、建設現場などにおいて、**「人や車の動き・状態」をリアルタイムで検知・監視**することにも広く活用されています。 本記事では、当社が対応可能な「行動検知・状態検知システム」のさまざまな応用例と、実際の導入イメージをご紹介します。 ## カメラ画像AIで「何が」検知できるのか？ AIを用いた画像検知技術（物体検出、姿勢推定、トラッキングなど）を組み合わせることで、目視やセンサーだけでは捉えきれない複雑な事象を自動で検知できます。 ### 1. 人の侵入検知・転倒検知・行動検知 工場や工事現場では、安全第一が最も重要です。AIカメラなら、設定した「危険エリア」への立ち入りを検知して即座にアラートを鳴らすことができます。 - **侵入検知**: 立ち入り禁止エリアに人が入った瞬間に警告 - **転倒・うずくまり検知**: 作業員が倒れたり、うずくまったりしている姿勢をAIが認識し、管理者に通報 - **危険行動検知**: ヘルメットや安全帯の未着用、スマート歩きなどのルール違反を検知 ### 2. フォークリフトやAGVの稼働状態検知 広大な倉庫内を行き交うフォークリフトやAGV（無人搬送車）の運用効率化にも、カメラAIが威力を発揮します。 - **稼働率の可視化**: 何台のフォークリフトが「動いているか」「止まっているか」をカメラ映像から自動集計 - **ヒヤリハット検知**: 人とフォークリフトが異常に接近した際に、衝突の危険性を検知して警報を出力 - **動線分析**: 特定の通路で渋滞が起きていないか、最適なルートを通っているかを分析 ### 3. 乗用車・トラックの運用管理 駐車場やトラックヤードなどの屋外環境でも、カメラ一つで幅広い情報を取得できます。 - **車番（ナンバープレート）認識**: 入退場する車両のナンバーを自動で読み取り、事前登録車両と照合 - **滞留時間検知**: 荷積みヤードにトラックが長時間停車していないか、待機列がどれくらい伸びているかを計測 - **車両種別判定**: 乗用車かトラックか、さらには大型・中型などのサイズまでAIが自動分類 --- ## 【実例イメージ】AIによる行動・状態検知 言葉だけではイメージしづらいため、実際のAI検知のイメージ画像（AIによる生成画像）をご覧ください。 ![AI検知イメージ](/assets/img/blog/ai-camera-detection.jpg) *※画像はイメージです。画面上のバウンディングボックス（枠）で、人やフォークリフト、指定エリアなどを個別に認識・追跡します。* このように、画面内に映るさまざまな対象をAIが同時に認識し、「人が危険エリアに近づいていないか」「車両が正しい位置にいるか」を24時間休むことなく監視し続けます。 ## テクノスフィアの強み：あらゆる環境への柔軟な対応 こうした画像AIシステムを導入する際、現場ごとに「見たいもの」「カメラの設置環境」「通信環境」が異なります。テクノスフィアでは、パッケージ製品の押し売りではなく、お客様の環境に合わせた**オーダーメイドのAI開発・システム構築**を得意としています。 - **既存の防犯カメラの活用**: すでに設置されているRTSP対応のネットワークカメラ映像をAIサーバーに引き込んで解析することが可能です。 - **エッジAIカメラの導入**: 通信量を抑えたい場合、カメラ側でAI処理を行うエッジデバイスの設計・選定からご提案します。 - **外部システム連携**: 検知結果を既存の生産管理システムや、Slack・LINE・メールといった通知ツールへ自動連携する仕組みまで一貫して構築します。 ## まとめ カメラ画像AIは、「人の目」の代わりとして、安全性向上と業務効率化を同時に実現する強力なツールです。 - 人の侵入や転倒といった**安全管理** - フォークリフトやAGVの**稼働監視** - 車両の入退場や滞留状況の**運用管理** 「こんな検知はできないか？」「現場のこの課題をカメラで解決したい」といったご要望があれば、テクノスフィアがあらゆる対応を実現します。 今後のシリーズ記事では、それぞれの検知テーマ（安全管理編、車両管理編など）に絞って、さらに具体的な技術や事例を深掘りしていく予定ですのでご期待ください！ ▼ お問い合わせ・システム導入のご相談はこちら [https://technosphere.co.jp/contact](https://technosphere.co.jp/contact) --- # 【2026年最新】一次面接を自動化するメリットと失敗しない導入のコツ URL: https://technosphere.co.jp/de-blog/2026-04-12-ai-interview-sugumen 採用活動において「面接官の日程調整に時間がかかる」「せっかく応募があっても、面接日までに辞退されてしまう」といったお悩みはありませんか？ 近年、採用難とスピード勝負が加速する中で、**一次面接の自動化（AI面接）**を導入する企業が増えています。 本記事では、一次面接を自動化する具体的なメリットと、導入時に失敗しないためのコツをわかりやすく解説します。 ## なぜ今、一次面接の自動化が求められているのか？ 求職者は複数の企業に同時に応募することが一般的です。特に、夜間や休日に応募が来た場合、翌営業日に連絡をして面接日程を調整している間に、他社で選考が進んでしまい「辞退」につながるケースが少なくありません。 また、人事担当者や現場の面接官にとっても、大量の応募者全員と初期面接を行うのは大きな工数がかかります。この**応募者側の待ち時間ストレス**と**企業側の面接工数の限界**を同時に解決する手段として、AIを活用した面接自動化が注目されています。 ## 一次面接を自動化する3つのメリット ### 1. 24時間365日、応募者の熱量が高いまま即時面談できる AI面接の大きな強みは、時間を問わず対応できることです。深夜でも休日でも、応募直後のもっとも熱量が高いタイミングで面接をスタートできます。これにより、初期接点での機会損失を大きく減らすことが可能です。 ### 2. 面接官の工数と日程調整の負担を大幅に削減できる 一次スクリーニングをAIが代行することで、面接官のスケジュール確保や応募者との日程調整にかかっていた時間を削減できます。採用担当者は、AIが整理・評価した結果をもとに、本当に会うべき候補者との面接に集中しやすくなります。 ### 3. 均質で客観的なヒアリングと評価を実現できる 人が面接を行う場合、面接官の経験やその日の状態によって、質問内容や評価にブレが出ることがあります。AI面接であれば、事前に設定した基準・設問で全候補者に均質なヒアリングを行えるため、公平で安定した一次評価につながります。 ## 導入時に失敗しないための注意点 メリットの多い面接自動化ですが、ツールを導入するだけで成果が出るとは限りません。以下のポイントを押さえることが重要です。 ### 求職者が受けやすい導線になっているか 受験のために専用アプリのインストールが必要だったり、操作が複雑だったりすると、それだけで離脱の原因になります。ブラウザだけで完結し、スマートフォンからでも手軽に受けられる仕組みが望ましいです。 ### 自社の採用基準に合った設問設計ができるか 一般的な質問だけでは、実際の採用判断に必要な情報が十分に得られない場合があります。自社が求めるスキルや適性、価値観に合わせて設問や評価軸を設計できることが重要です。 ## 最短数分で導入できるクラウド型AI面接「SUGUMEN」 株式会社テクノスフィアが提供するAI面接システム**「SUGUMEN（スグメン）」**は、こうした採用課題の解決を支援するクラウド型サービスです。 - 応募から**最短3分**でAI面談を開始 - **24時間365日**、AIが一次面接を自動代行 - **初期費用ゼロ**で導入しやすいクラウド型 - 既存の採用管理システム（ATS）との連携にも対応 - スマートフォン・PCのブラウザから受験可能 応募者にとっては「すぐに選考へ進める」「自分の都合に合わせて受けられる」というメリットがあり、企業にとっては「面接工数の削減」「選考スピード向上」「採用精度の改善」につながります。 まさに、**求職者にも企業にもWin-Win** な採用体験を実現する仕組みです。 ## まとめ 一次面接の自動化は、単なる業務効率化ではなく、応募者体験の改善と採用競争力の強化につながる施策です。採用スピードがそのまま結果に直結しやすい時代だからこそ、早い段階での見直しが重要になります。 面接日程の調整負担や、応募者の離脱、一次面接の工数に課題を感じている企業様は、AI面接ツールの活用をぜひ検討してみてください。 SUGUMENの詳細はこちら： [https://technosphere.co.jp/sugumen](https://technosphere.co.jp/sugumen) --- # AI画像検査とは？仕組み・導入の流れ・異物混入や加工不良への対応事例 URL: https://technosphere.co.jp/de-blog/2026-04-12-camera-image-inspection-system 製造現場では、異物混入、キズ、欠け、寸法ばらつき、印字ズレなど、さまざまな不良を見逃さずに検査することが品質維持の重要なポイントになります。 一方で、目視検査だけに頼る運用では、検査員ごとの判断差、長時間作業による見落とし、検査工数の増大といった課題が発生しやすくなります。 そこで注目されているのが、**カメラ画像とAIを活用した製品検査システム**です。 テクノスフィアでは、工業用カメラで取得した画像をもとに、異物混入や加工不良、外観上のさまざまな欠陥を自動で判定するシステムの開発に対応しています。 本記事では、AI画像検査システムがどのような構成で動き、どのような流れで不良を検出しているのかを、技術的な視点からわかりやすくご紹介します。 ## AI画像検査システムとは AI画像検査システムは、製品を撮影した画像を解析し、良品か不良品かを自動で判定する仕組みです。 従来のルールベース画像処理だけでなく、機械学習やディープラーニングを組み合わせることで、複雑な欠陥パターンや微細な違いにも対応しやすくなります。 たとえば、以下のような検査対象に適用できます。 - 食品・医薬品・樹脂成形品などへの**異物混入** - 金属加工品や成形品の**キズ、欠け、割れ** - 部品の**位置ズレ、組付け不良、向き違い** - ラベルや印字の**欠け、かすれ、ズレ** - 外形や穴位置などの**寸法異常** 製造ライン上で撮像から判定までを自動化することで、品質の安定化と省人化の両立を目指せます。 ## システムはどのような構成で動くのか AI画像検査システムは、単にカメラとAIソフトだけで成り立つわけではありません。 現場で安定稼働させるには、**撮像・画像処理・AI判定・ライン連携**までを含めた全体設計が重要です。 ### 1. 撮像部：工業用カメラ・照明・レンズ 最初の要素は、対象物を安定して撮影する撮像部です。 ここでは主に以下を組み合わせます。 - **工業用カメラ**：ライン速度や必要解像度に応じて選定 - **レンズ**：検査対象のサイズや視野角に合わせて設定 - **照明**：欠陥を見えやすくするための重要要素 - **トリガー機構**：搬送タイミングに合わせて撮像を同期 画像検査では、AIモデルの精度以前に、**安定した画像を取得できること**が非常に重要です。 たとえば異物を見つけたいのか、表面キズを強調したいのか、印字を読みたいのかによって、最適な照明方法は変わります。 同軸照明、バー照明、透過照明、リング照明などを使い分けることで、欠陥の見え方を調整します。 ### 2. 画像処理部：前処理で判定しやすい画像に整える カメラで取得した画像は、そのままAIに入力するのではなく、まず前処理を行うことが一般的です。 主な処理例は以下の通りです。 - 位置補正 - 明るさ補正 - ノイズ除去 - 領域切り出し - 二値化 - エッジ抽出 - 特徴量抽出 たとえば、搬送位置にばらつきがある場合は位置合わせをしてから判定することで、誤検知を抑えやすくなります。 また、不要な背景を除外して検査対象だけを切り出すことで、AIや画像処理アルゴリズムが本来見るべき部分に集中できます。 ### 3. AI判定部：正常と異常の違いを学習する 前処理後の画像に対して、AIモデルまたは従来型の判定ロジックを適用します。 検査内容によって、使い分けの考え方は異なります。 - **ルールベース画像処理**：寸法、面積、形状、閾値判定に強い - **機械学習・ディープラーニング**：複雑な外観差分や多様な欠陥検出に強い - **ハイブリッド構成**：前段を画像処理、後段をAIで判定 たとえば、寸法異常のように明確な基準値がある検査では、従来型画像処理が有効です。 一方、表面の微細なムラや異物、複数パターンの不良が混在するケースでは、AIを活用することで高精度化しやすくなります。 実際の現場では、良品画像・不良画像を収集し、用途に応じたデータセットを構築しながらモデルを学習・評価します。 必要に応じて、正常データ中心の異常検知アプローチを取ることもあります。 ### 4. 制御連携部：ライン設備とつないで自動化する 検査システムは、判定だけで終わりではありません。 現場導入では、検査結果をもとに設備を制御できることが重要です。 代表的な連携先は以下の通りです。 - **PLC**との接続 - 排出機構やアクチュエータ制御 - ブザーやパトライトによる異常通知 - 上位システムへの検査結果送信 - 画像や判定結果のログ保存 たとえば不良判定が出た際に、対象品を自動で排出したり、検査NG画像を保存してトレーサビリティに活用したりできます。 これにより、単なる検査装置ではなく、**品質管理システムの一部**として運用できるようになります。 ## 実際の検査フロー 一般的なAI画像検査システムの処理フローは、次のようになります。 1. センサーまたは設備信号を受けて製品を撮像 2. 画像の位置補正やノイズ除去などの前処理を実施 3. AIまたは画像処理ロジックで良否判定 4. 判定結果に応じてOK/NGを出力 5. 必要に応じて不良品を排出し、画像や結果を保存 この一連の流れを、製造ラインのタクトタイム内で安定して実行することが求められます。 そのため、精度だけでなく、処理速度、通信タイミング、設備との同期も含めて設計することが重要です。 ## 目視検査との違い 目視検査は柔軟性が高い一方で、判断基準の属人化や疲労によるばらつきが課題になりがちです。 AI画像検査システムを導入することで、以下のような効果が期待できます。 - 検査基準の標準化 - 人による判定差の低減 - 長時間稼働でも一定品質を維持 - 全数検査への対応 - 検査画像の保存による原因分析のしやすさ もちろん、すべてをAI任せにすればよいわけではなく、現場の品質基準や運用ルールを整理したうえで、システム化に適した工程を見極めることが大切です。 ## テクノスフィアが対応できる領域 テクノスフィアでは、単体の画像判定アルゴリズム開発だけでなく、現場実装を見据えたシステム全体の設計・開発に対応しています。 たとえば、以下のようなご相談が可能です。 - 外観検査装置の要件整理 - カメラ、照明、レンズの選定支援 - 画像処理アルゴリズムの開発 - AIモデル構築と評価 - PLCや制御系との連携 - 現場導入後の精度改善・再学習 製品やラインごとに、求められる検査内容や環境条件は大きく異なります。 そのため、汎用的なテンプレートを当てはめるのではなく、対象ワークや工程条件に合わせた設計が欠かせません。 ## まとめ AI画像検査システムは、**カメラで撮る、画像を整える、AIで判定する、設備と連携する**という複数の技術要素で構成されています。 異物混入や加工不良などの検出を安定して行うためには、AIモデル単体ではなく、撮像条件や制御連携まで含めたトータルな設計が重要です。 テクノスフィアでは、画像認識技術とシステム開発の両面から、製造現場に適した検査システムづくりをご支援しています。 製品検査の自動化や外観検査の高度化をご検討の際は、ぜひお気軽にご相談ください。 ▼ お問い合わせはこちら [https://technosphere.co.jp/contact](https://technosphere.co.jp/contact) --- # WebエンジニアからAIエンジニアへ！テクノスフィアでのキャリアチェンジと働き方 URL: https://technosphere.co.jp/de-blog/2026-04-12-web-to-ai-engineer-career 近年、「Web開発の経験を活かして、最新のAI領域に挑戦したい！」というエンジニアの方からの応募が増えています。 株式会社テクノスフィアでは、現在お持ちのプログラミング経験（PHP、Python、JavaScriptなど）をベースに、AI・機械学習の実務へとステップアップできる環境を整えています。 今回は、テクノスフィアでどのように「AIエンジニアへのキャリアチェンジ」を実現しているのか、その働き方やサポート体制についてご紹介します。 ## AI開発は「まったくの未経験」からでも挑戦できる？ 結論から言うと、**プログラミングの基礎力があれば大歓迎**です。 現在、当社のAIプロジェクトの最前線で活躍しているメンバーの中には、「入社前はWebアプリケーション開発だけをやっていて、AIの実務経験はゼロだった」という人も少なくありません。 当社が強みとしている「画像認識技術」や、LLM（大規模言語モデル）を活用した「RAGチャットボット開発」は、AIの知識だけでなく、システム全体を構築するためのWeb開発の知見が不可欠です。 そのため、Webエンジニアとしてのこれまでのご経験は、AIプロジェクトにおいても即戦力となる重要なスキルなのです。 ## テクノスフィアの「スキルアップ全額支援」制度 「AIに興味はあるけれど、どうやってキャッチアップすればいいかわからない…」 そんな方のために、当社ではエンジニアが継続して成長できる仕組みを用意しています。 ### 1. 外部研修費用の「全額」会社負担 AIや機械学習、クラウドインフラ（AWS/Azure）に関する外部の専門的な研修やオンラインコースの受講費用を、会社が全額負担します。 業務に必要な知識を、気兼ねなくトップレベルの教材から学ぶことができます。 ### 2. 技術書籍の購入支援 新しいライブラリやフレームワークについて学ぶための技術書の購入も、もちろんサポート。常に最新の情報を手元に置いて開発に臨めます。 ### 3. 先輩エンジニアによるメンター制度 入社後から実務デビューまでの期間は、経験豊富な先輩エンジニアがマンツーマンでサポートします。定期的な1on1ミーティングを通じて、技術的な相談はもちろん、キャリアプランのすり合わせまで、しっかりフォローする「手厚いオンボーディング」を実施しています。 ## 話題の技術を「翌週には業務で使う」スピード感 当社の特徴のひとつは、その**圧倒的なスピード感**です。 平均年齢32歳という若くフラットな組織であり、無駄な階層や承認フローがありません。 「この新しいAIモデル、面白そうだから次のプロジェクトで試してみませんか？」 こんなアイデアが日常のブレストから生まれ、翌週には実際の業務やプロトタイプ開発に組み込まれていることも珍しくありません。最先端のAI技術に、ただ触れるだけでなく「ビジネスの現場で実践する」経験が積めるのが、テクノスフィア最大の魅力です。 ## 最後に：一緒に未来をつくりませんか？ テクノスフィアは4年連続で増収増益を達成しており、会社の成長と個人のキャリアアップが連動するフェーズにあります。 - 新しい技術に好奇心を持ち、「まずやってみる」を行動に移せる方 - チームで協力し、仲間の成功を喜べる方 - 「ChatGPTを超えるような自社AIサービスを作りたい」という野心をお持ちの方 新卒・第二新卒・中途を問わず、あなたの「やりたい」を形にする環境がここにあります。 少しでも興味をお持ちいただけましたら、ぜひお気軽にカジュアルにお話ししましょう！ ▼ 採用情報・エントリーはこちら [https://technosphere.co.jp/recruit](https://technosphere.co.jp/recruit) --- # 社内業務を自動化するマルチLLM AIエージェント基盤の設計と実装 URL: https://technosphere.co.jp/de-blog/2026-04-24-multi-llm-ai-agent-architecture ## はじめに：なぜ「AIエージェント基盤」が必要なのか ChatGPTやClaudeを業務に使っている企業は増えていますが、多くは「人がプロンプトを入力して、回答を受け取る」という対話型の使い方にとどまっています。 しかし、**AIが自ら判断し、ツールを使い、複数のステップを自律的に実行する**——いわゆる「AIエージェント」の仕組みを構築すれば、業務自動化の幅は劇的に広がります。 弊社では、社内の定型業務（レポート作成、データ集計、メール対応、調査タスクなど）を自律的に処理するAIエージェント基盤を構築・運用しています。本記事では、その設計思想とアーキテクチャを技術的に解説します。 --- ## システム全体像 ``` ┌──────────────────────────────────────────┐ │ Communication Layer │ │ Slack / API / Web UI │ └────────────────┬─────────────────────────┘ │ ┌────────────────▼─────────────────────────┐ │ Agent Orchestration │ │ タスク分解・スキル実行・メモリ管理 │ └────────────────┬─────────────────────────┘ │ ┌────────────────▼─────────────────────────┐ │ LLM Proxy Layer │ │ Claude / Gemini / Codex │ │ 自動フォールバック・負荷分散 │ └────────────────┬─────────────────────────┘ │ ┌────────────────▼─────────────────────────┐ │ Tool / Skill Layer │ │ Web検索 / ファイル操作 / シェル実行 │ │ メール送信 / ドキュメント生成 │ └──────────────────────────────────────────┘ ``` この4層アーキテクチャにより、**LLMの選定・通信チャネル・実行スキルをそれぞれ独立して変更・拡張**できる設計になっています。 --- ## 設計の3つの柱 ### 1. マルチLLMプロキシ：1つのモデルに依存しない AIエージェントの頭脳であるLLMを1つのモデルに固定すると、以下のリスクがあります。 - **API障害**でエージェント全体が停止する - **コスト変動**で運用費が予測不能になる - **タスクとモデルの相性**（コード生成はCodex、長文要約はGemini等）を活かせない そこで、**OpenAI互換APIを提供するLLMプロキシ層**を設計しました。 ``` リクエスト → LLMプロキシ（ポート8000） → モデル選択（タスクに応じて最適なLLMを自動選択） → フォールバック管理（障害時は次のモデルへ自動切替） → ヘルスチェック（各プロバイダーの稼働状況を追跡） → レスポンス整形（統一フォーマットで返却） ``` #### 対応モデルと使い分け | モデル | 用途 | コンテキスト長 | |--------|------|--------------| | Claude Sonnet | 標準的な推論・業務処理 | 200K | | Claude Opus | 複雑な分析・長文生成 | 200K | | Claude Haiku | 高速応答・単純タスク | 200K | | Gemini Pro | 大規模ドキュメント処理 | 1M | | Gemini Flash | 高速要約 | 1M | | Codex | コード生成特化 | 128K | #### フォールバックの実装 ```javascript // プロバイダーごとの状態管理 const providerState = { 'claude-sonnet': { healthy: true, lastError: null, cooldownUntil: null }, 'gemini-pro': { healthy: true, lastError: null, cooldownUntil: null }, // ... }; async function routeRequest(request) { const providers = selectProviders(request.model); for (const provider of providers) { if (!isAvailable(provider)) continue; try { return await callProvider(provider, request); } catch (error) { // 障害発生 → 5分間クールダウン provider.cooldownUntil = Date.now() + 5 * 60 * 1000; provider.healthy = false; console.log(`${provider.id} failed, falling back...`); } } throw new Error('All providers unavailable'); } ``` **ポイント**: 障害が発生したプロバイダーは5分間のクールダウン期間を設け、回復を待ちます。同時リクエスト数の上限（プロバイダーごとに2リクエスト）も設定し、レートリミットを防止しています。 --- ### 2. スキルシステム：AIが「手足」を持つ LLMは「考える」能力に長けていますが、実際に「行動する」にはツール（スキル）が必要です。 当基盤では、以下のスキルを組み込んでいます。 | スキル | できること | |--------|----------| | Web検索 | インターネット上の情報を検索・取得 | | ファイル操作 | ドキュメントの読み書き・整理 | | シェル実行 | コマンド実行による自動処理 | | コード実行 | Python/JavaScriptのコード実行 | | メール操作 | IMAP/SMTPによるメール送受信 | | ドキュメント生成 | Excel・PDF・プレゼン資料の作成 | | 画像生成 | FLUX/SDXLモデルによる画像生成 | #### スキルの呼び出しフロー ``` ユーザー: 「先月の売上データをまとめてExcelで送って」 AIエージェント: 1. [ファイル操作] NAS上の売上CSVを読み込み 2. [コード実行] Pythonでデータ集計・グラフ生成 3. [ドキュメント生成] Excelファイルを作成 4. [メール操作] 依頼者にExcelを添付して送信 5. [Slack通知] 「送信完了しました」と報告 ``` このように、**1つの依頼に対して複数のスキルを連鎖的に実行**できるのがエージェントの強みです。 --- ### 3. 3層メモリアーキテクチャ：AIが「覚える」仕組み LLMは本質的にステートレス（状態を持たない）です。会話が終われば、文脈は失われます。しかし業務では「先週の会議で決まったこと」「あのプロジェクトの経緯」といった文脈の蓄積が重要です。 そこで、**3層のメモリアーキテクチャ**を設計しました。 ``` ┌─────────────────────────────┐ │ Layer 1: セッションメモリ │ ← 今日の作業ログ │ memory/YYYY-MM-DD.md │ 毎日リセット ├─────────────────────────────┤ │ Layer 2: 長期メモリ │ ← 重要な知識・判断基準 │ MEMORY.md │ 数日おきに更新 ├─────────────────────────────┤ │ Layer 3: 永続ストレージ │ ← ファイル・成果物 │ NAS共有ディレクトリ │ 永続保存 └─────────────────────────────┘ ``` #### セッションメモリ（短期） その日の作業内容をMarkdown形式で記録します。 ```markdown ## 2026-04-24 作業ログ ### 10:05 売上レポート作成依頼（営業部 佐藤さん） - 3月度売上CSVを /nas/sales/ から取得 - 前年同月比を算出、グラフ付きExcel生成 - 佐藤さんにメール送信完了 ### 14:30 サーバー監視アラート対応 - CPU使用率90%超過を検知 - 原因: バッチ処理の並列実行過多 - 対応: cron設定を調整、正常化を確認 ``` #### 長期メモリ（中期） セッションメモリから抽出した「今後も役立つ知識」を蓄積します。 ```markdown ## 業務知識 - 月次売上レポートは毎月5日までに提出（経理部ルール） - サーバーCPU閾値は80%でアラート、対応手順はWikiの「障害対応」参照 - 佐藤さん（営業）はExcel形式を好む、PDF不可 ``` **「書き留める」原則**を徹底し、口頭での申し送りに相当する情報を確実に蓄積しています。 --- ## Docker基盤によるデプロイ エージェント基盤全体をDockerコンテナで構成し、再現性と可搬性を確保しています。 ```yaml # docker-compose.yml（簡略版） services: agent: image: agent-base:latest volumes: - ./workspace:/home/node/workspace - /mnt/nas/shared:/mnt/nas:ro environment: - TZ=Asia/Tokyo - LLM_PROXY_URL=http://llm-proxy:8000/v1 depends_on: - llm-proxy healthcheck: test: ["CMD", "curl", "-f", "http://localhost:18789/health"] interval: 30s timeout: 10s retries: 3 llm-proxy: build: ./services/llm-proxy ports: - "8000:8000" monitor: build: ./services/monitor-api ports: - "8200:8200" ``` ### 運用監視 モニターAPIで各コンポーネントの稼働状況をリアルタイムに把握できます。 - **ヘルスチェック**: 30秒間隔で全サービスの死活監視 - **LLM使用量**: モデルごとのリクエスト数・レスポンス時間を記録 - **エラートラッキング**: フォールバック発生回数・失敗パターンの可視化 --- ## 導入効果 社内で3ヶ月間運用した結果、以下の効果が得られました。 | 業務 | 導入前 | 導入後 | 削減率 | |------|--------|--------|--------| | 月次レポート作成 | 4時間/月 | 30分/月 | 87% | | メール一次対応 | 2時間/日 | 20分/日 | 83% | | 社内問い合わせ対応 | 1.5時間/日 | 15分/日 | 83% | | データ集計・分析 | 3時間/回 | 20分/回 | 89% | 特に**定型的だが手順が多い業務**で大きな効果を発揮しています。 --- ## 構築時に注意すべき3つのポイント ### 1. LLMの幻覚（ハルシネーション）対策 AIエージェントが自律的に行動する以上、誤った情報に基づく行動は大きなリスクです。 **対策：** - **確認ステップの挿入**: 外部送信（メール・Slack投稿）前に人間の承認を挟む - **事実確認スキル**: 社内ドキュメントや公式情報源との照合を必須化 - **行動ログの完全記録**: 全アクションをログに残し、事後検証を可能にする ### 2. セキュリティ境界の設計 エージェントがアクセスできるリソースを明確に制限します。 - **読み取り専用マウント**: 他部署のファイルはread-onlyでマウント - **メモリの非共有**: エージェントの長期メモリは他のコンテキストに漏洩しない設計 - **認証情報の分離**: APIキー等は環境変数で注入し、コード内にハードコードしない ### 3. フォールバック戦略の設計 「AIが動かない」状態を極力防ぐための多重化です。 ``` プライマリ: Claude Sonnet ↓ 障害時 フォールバック1: Gemini Flash ↓ 障害時 フォールバック2: Claude Haiku ↓ 全滅時 人間にエスカレーション（Slack通知） ``` --- ## まとめ 社内AIエージェント基盤の設計と実装について解説しました。 **重要な設計原則：** 1. **マルチLLMプロキシ**で単一障害点を排除し、モデル特性を活かす 2. **スキルシステム**でAIに「行動する手足」を与える 3. **3層メモリ**で文脈を蓄積し、業務品質を継続的に向上させる 4. **Docker基盤**で再現性・可搬性・監視性を確保する テクノスフィアでは、こうしたAIエージェント基盤の設計・構築支援も行っています。社内業務のAI自動化に興味がある方は、[お気軽にお問い合わせください](/contact)。 --- # STM32 + FreeRTOSでリアルタイムセンサー監視システムを構築する方法 URL: https://technosphere.co.jp/de-blog/2026-04-24-stm32-freertos-sensor-monitoring ## はじめに：なぜFreeRTOSが必要なのか？ 組込みシステムで複数のセンサーを同時に監視したい——そんなとき、ベアメタル（OSなし）で書いたコードでは限界が出てきます。 たとえば、温度センサーの読み取り中にCAN通信の受信を取りこぼしたり、LCD表示の更新中にアラーム判定が遅れたり。**複数の処理を確実に並行実行するには、リアルタイムOS（RTOS）が有効**です。 本記事では、STM32マイコンとFreeRTOSを使って、リアルタイムセンサー監視システムを構築する方法を、実装コード付きで解説します。 > **FreeRTOSの基礎から学びたい方へ**：タスク・キュー・セマフォ・ミューテックスといったFreeRTOSの基本概念は、技術コラムの [STM32 + FreeRTOS 入門｜タスク・キュー・セマフォを使ったRTOS実装ガイド](/blog/stm32-freertos-intro) で体系的に解説しています。本記事はその実践編にあたります。 --- ## 本記事で構築するシステム ### 構成図 ``` [温度センサー] ──I2C──┐ [湿度センサー] ──I2C──┤ [振動センサー] ──ADC──┤── STM32F4 + FreeRTOS ──UART──→ [ログ出力] [CAN Bus] ──CAN──┤ ──CAN───→ [上位システム] └── LCD表示 ``` ### タスク構成 | タスク名 | 優先度 | 周期 | 役割 | |---------|--------|------|------| | SensorReadTask | High | 100ms | I2C/ADCセンサー読み取り | | AlarmCheckTask | High | 200ms | 閾値判定・アラーム発報 | | CANCommTask | Medium | 50ms | CAN通信の送受信 | | DisplayTask | Low | 500ms | LCD画面更新 | | LogTask | Low | 1000ms | UARTシリアルログ出力 | --- ## 環境構築 ### 必要なもの - **マイコンボード**: STM32F407 Discovery（またはNucleo-F446RE等） - **開発環境**: STM32CubeIDE 1.15+ - **ミドルウェア**: FreeRTOS（CMSIS-RTOS v2 API） - **センサー**: BME280（温湿度・気圧）、ADXL345（振動）など ### STM32CubeMXの設定 1. **Middleware → FREERTOS** を有効化（CMSIS_V2を選択） 2. **I2C1** を有効化（センサー接続用） 3. **ADC1** を有効化（振動センサー用） 4. **CAN1** を有効化（上位システム通信用） 5. **USART2** を有効化（デバッグログ用） FreeRTOSの設定で、タスクのスタックサイズは各タスク最低256ワード（1KB）を確保しておきます。 --- ## 実装のポイント ### 1. タスク間データ共有にはキュー（Queue）を使う グローバル変数でのデータ共有は競合状態（Race Condition）の原因になります。FreeRTOSのキューを使えば、タスク間のデータ受け渡しをスレッドセーフに行えます。 ```c // センサーデータ構造体 typedef struct { float temperature; float humidity; float pressure; float vibration; uint32_t timestamp; } SensorData_t; // キューハンドル osMessageQueueId_t sensorQueueHandle; // キュー作成（main.c の初期化部分） const osMessageQueueAttr_t sensorQueue_attr = { .name = "sensorQueue" }; sensorQueueHandle = osMessageQueueNew(16, sizeof(SensorData_t), &sensorQueue_attr); ``` ### 2. センサー読み取りタスク ```c void SensorReadTask(void *argument) { SensorData_t data; for (;;) { // BME280から温湿度・気圧を取得（I2C） data.temperature = BME280_ReadTemperature(&hi2c1); data.humidity = BME280_ReadHumidity(&hi2c1); data.pressure = BME280_ReadPressure(&hi2c1); // ADXL345から振動値を取得（ADC） HAL_ADC_Start(&hadc1); HAL_ADC_PollForConversion(&hadc1, 10); uint32_t raw = HAL_ADC_GetValue(&hadc1); data.vibration = (float)raw * 3.3f / 4096.0f; // タイムスタンプ data.timestamp = osKernelGetTickCount(); // キューに送信（アラームタスク・表示タスクが受信） osMessageQueuePut(sensorQueueHandle, &data, 0, 0); osDelay(100); // 100ms周期 } } ``` ### 3. アラーム判定タスク ```c #define TEMP_THRESHOLD_HIGH 40.0f // 40℃以上で警告 #define VIBRATION_THRESHOLD 2.5f // 2.5V以上で異常振動 void AlarmCheckTask(void *argument) { SensorData_t data; for (;;) { // キューからデータ受信（最大200ms待機） if (osMessageQueueGet(sensorQueueHandle, &data, NULL, 200) == osOK) { // 温度異常チェック if (data.temperature > TEMP_THRESHOLD_HIGH) { CAN_SendAlarm(ALARM_TEMP_HIGH, data.temperature); HAL_GPIO_WritePin(LED_RED_GPIO_Port, LED_RED_Pin, GPIO_PIN_SET); } // 振動異常チェック if (data.vibration > VIBRATION_THRESHOLD) { CAN_SendAlarm(ALARM_VIBRATION, data.vibration); HAL_GPIO_WritePin(LED_ORANGE_GPIO_Port, LED_ORANGE_Pin, GPIO_PIN_SET); } } } } ``` ### 4. ミューテックスでI2Cバスを保護する 複数タスクが同じI2Cバスにアクセスする場合、ミューテックスで排他制御が必要です。 ```c osMutexId_t i2cMutexHandle; // 初期化 const osMutexAttr_t i2cMutex_attr = { .name = "i2cMutex", .attr_bits = osMutexRecursive | osMutexPrioInherit }; i2cMutexHandle = osMutexNew(&i2cMutex_attr); // I2Cアクセス時にミューテックス取得 float BME280_ReadTemperature_Safe(I2C_HandleTypeDef *hi2c) { float temp = 0.0f; if (osMutexAcquire(i2cMutexHandle, osWaitForever) == osOK) { temp = BME280_ReadTemperature(hi2c); osMutexRelease(i2cMutexHandle); } return temp; } ``` `osMutexPrioInherit`（優先度継承）を指定することで、**優先度逆転問題**を防止できます。 --- ## よくあるトラブルと対策 ### スタックオーバーフロー FreeRTOSタスクのスタックサイズが不足すると、HardFault例外が発生します。 **対策：** - `configCHECK_FOR_STACK_OVERFLOW` を `2` に設定してオーバーフロー検出を有効化 - `uxTaskGetStackHighWaterMark()` で使用量を確認し、余裕を持ったサイズを設定 ```c // FreeRTOSConfig.h #define configCHECK_FOR_STACK_OVERFLOW 2 // コールバック関数 void vApplicationStackOverflowHook(TaskHandle_t xTask, char *pcTaskName) { printf("Stack overflow in task: %s\n", pcTaskName); // LED点滅などでエラー通知 while(1); } ``` ### タスク優先度の設計ミス 優先度が高いタスクがCPUを占有し続けると、低優先度タスクが実行されません。 **対策：** - センサー読み取り・アラーム判定は**High**、表示やログは**Low** - 必ず`osDelay()`や`osMessageQueueGet()`でブロッキング状態を作り、CPUを解放する - `vTaskDelayUntil()`で正確な周期実行を実現 ### ヒープメモリ不足 キューやミューテックスの生成に失敗する場合は、ヒープサイズが不足しています。 ```c // FreeRTOSConfig.h #define configTOTAL_HEAP_SIZE ((size_t)32768) // 32KB に拡張 ``` --- ## ベアメタルとFreeRTOSの比較 | 観点 | ベアメタル | FreeRTOS | |------|----------|----------| | 複数処理の並行実行 | 割り込み+フラグで手動管理 | タスクとして自然に分離 | | タイミング制御 | タイマー割り込みで実装 | osDelay/vTaskDelayUntilで簡潔 | | データ共有 | グローバル変数（競合リスクあり） | キュー/セマフォで安全 | | コードの保守性 | 処理が密結合しがち | タスク単位でモジュール化 | | デバッグ | 困難（タイミング依存バグ） | タスク状態の可視化が可能 | | メモリ使用量 | 最小限 | +10〜20KB程度 | センサー2〜3個程度のシンプルな構成ならベアメタルで十分ですが、**4つ以上の並行処理や、CAN通信のようなリアルタイム性が求められる場合はFreeRTOSの導入メリットが大きい**です。 --- ## まとめ STM32 + FreeRTOSによるリアルタイムセンサー監視システムの構築方法を解説しました。 **ポイントの振り返り：** 1. **タスク間データ共有はキュー（Queue）** を使い、グローバル変数を避ける 2. **共有リソース（I2Cバス等）はミューテックス**で保護する 3. **優先度継承**を有効にして優先度逆転を防止する 4. **スタックサイズは余裕を持って設定**し、オーバーフロー検出を有効化する テクノスフィアでは、STM32をはじめとするマイコンの組込み開発を20年以上手がけてきました。FreeRTOSを活用したリアルタイムシステムの設計・実装も多数の実績があります。 組込みシステムの開発でお困りのことがあれば、[お気軽にご相談ください](/contact)。 **関連記事：** - [STM32 + FreeRTOS 入門｜タスク・キュー・セマフォを使ったRTOS実装ガイド](/blog/stm32-freertos-intro) — FreeRTOSの基礎を体系的に解説 - [STM32マイコンのUART・I2C・SPI・CAN通信 実装ガイド](/blog/stm32-uart-i2c-can) — 通信ペリフェラルの使い分けと実装 - [組込み制御・マイコン開発サービス](/embedded) — STM32受託開発のご相談 --- # FlowLens（フローレンズ）｜PC操作を記録するだけで、AIが手順書と改善提案を自動生成｜株式会社テクノスフィア > FlowLens（フローレンズ）は、Windowsの画面操作を生成AIが解析し、スクリーンショット付き手順書の自動生成と操作の最適化提案を行うテクノスフィアの自社開発プロダクト。手順書を作る時間がない、マニュアルが古い、業務が属人化している——そんな現場の悩みを「いつも通り操作するだけ」で解決します。先行モニター企業を募集中。 URL: https://technosphere.co.jp/flowlens TECHNOSPHERE ORIGINAL先行モニター募集中 # 業務の流れを、 レンズで捉える。 いつも通りパソコンを操作するだけ。FlowLens（フローレンズ）が画面と操作の流れを見つめて、**スクリーンショット付きの手順書**と**ムダのない手順の提案**に変えます。手順書は、もう「あとで書く」ものではなくなります。 [先行モニターについて相談する](https://technosphere.co.jp/contact) 仕組みを見る ※ いまはまだ開発中です。最初のユーザーとして、一緒に育てませんか。 capture.log — 記録中 09:41:02click [受注管理] メニュー 09:41:05input 顧客コード K-1024 09:41:09copy Ctrl+C 受注番号 09:41:12switch 月次集計.xlsx 09:41:15paste Ctrl+V B14セル 09:41:23click [保存] AIが観察して… 手順書 v1.2 — 自動生成 受注データの月次転記 1 受注管理画面を開き、顧客コードを入力する 2 受注番号をコピーし、月次集計表のB列へ貼り付ける 3 上書き保存して画面を閉じる → 手順2は毎回3クリック。 ショートカット1回に短縮できます ISSUE ─ 現場のよくある悩み ## その手順書、最後に開いたのはいつですか。 どの現場でも聞く悩みです。原因は担当者の怠慢ではなく、「業務をしながら手順書も育てる」ことが人間には難しすぎるから。FlowLensはここから考えました。 **作る時間がない** 日々の業務が優先で、手順書の作成はいつも後回し。結局作られないまま。 ← いちばん多い **すぐ古くなる** システム更新のたびに画面が変わり、手順書だけが昔のまま。誰も直さない。 **あの人しか知らない** ベテランの手元にだけある近道と勘どころ。本人も「当たり前」すぎて説明できない。 **教えるたびに同じ説明** 新人が入るたび、隣に座って同じ操作を最初から。教える側の時間も消えていく。 FlowLensの答えはシンプルです。「書く」のをやめて、「操作を見せる」だけにする。 HOW ─ FlowLens の仕組み ## 「いつも通り操作するだけ」の裏側。 使う人がすることは、記録ボタンを押していつもの業務をするだけ。あとの仕事はぜんぶFlowLensが引き受けます。 STEP 01 ### 記録する Windowsの記録クライアントが、クリック・入力・画面の切り替わりを、その瞬間のスクリーンショットとあわせて記録します。操作した本人は何もしなくて大丈夫。 STEP 02 ### AIが読み解く 画面を理解できる生成AIが記録を解析し、「どのアプリで・どの画面で・何をしたか」を業務の流れとして構造化。無関係な操作やムダな繰り返しもここで見つけます。 STEP 03 ### 手順書と提案になる スクリーンショット付きの手順書と、操作を減らすための改善提案レポートができあがります。内容を確認して、直したいところだけ手を入れればOK。 解析サーバはDockerコンテナとして、社内サーバ（オンプレミス）にもクラウドにも構築できます。画面データを社外に出せない現場を前提に設計しています。 キャプチャ方式の設計判断やAIパイプラインの詳細は、技術ブログ「[AIで手順書を自動生成する仕組み](https://technosphere.co.jp/blog/ai-manual-auto-generation)」で開発チームが解説しています。 FEATURE ─ できること ## 手順書をつくる。そして、手順そのものを良くする。 ### FEATURE 01実際の操作から、スクリーンショット付き手順書を自動生成 「操作しながらスクショを撮って、Wordに貼って、説明を書く」——あの作業がまるごとなくなります。記録した操作から、要点のスクリーンショットを選び、説明文を添えた手順書をFlowLensが組み立てます。 - 要点となる画面をAIが自動選定し、説明文を生成 - Markdown・Word（docx）で出力、社内Wikiへの登録にも対応予定 - 業務が変わったら再記録するだけで最新版に更新 経費精算システム 入力手順.docx 経費精算の申請手順 1 経費精算システムにログインし、[新規申請] を選ぶ 2 領収書の日付・金額を入力し、画像を添付する 3 承認者を確認して申請ボタンを押す .md.docx社内Wiki（予定） ### FEATURE 02操作のクセを見つけて、ムダのない手順を提案 毎日くり返される「なんとなくこうやってきた」操作の中には、驚くほどの伸びしろが眠っています。FlowLensは操作パターンを分析し、具体的な短縮方法を根拠つきで提案します。 - ショートカットや標準機能で置き換えられる操作を検出 - 意味のない繰り返し・遠回りの操作列を発見 - 毎日発生する定型作業は、自動化の候補としてレポート BEFORE ***27手順 / 4分10秒* AFTER ***12手順 / 1分50秒* 毎朝の集計作業なら、ひと月で約50分の節約。 SCENE ─ 想定している使いどころ ## 「人が入れ替わる場面」で、いちばん効きます。 ### 新しい人がきた新人教育・OJT ベテランの実際の操作がそのまま教材に。隣に座って教える時間を減らしながら、教わる側は自分のペースで何度でも確認できます。 ### あの人が異動する引き継ぎ・属人化の解消 「本人しか知らない手順」を、異動や退職の前に記録して形に。口頭とメモ頼みの引き継ぎから卒業できます。 ### やり方がバラバラ業務の標準化・改善 同じ業務でも人によって手順はさまざま。実際の操作ログをもとに、いちばんムダのないやり方をチームの標準にできます。 STATUS ─ いまどの段階？ ## 正直に言うと、 まだ開発中です。 FlowLensはテクノスフィアが自社開発している新しいプロダクトで、現在は検証（PoC）の段階です。だからこそ、いま声をかけてくださる企業さまの現場の声を、そのまま製品に反映できます。 1. **NOW ─ 2026検証（PoC）**← いまここ 記録クライアントと解析エンジンのコア開発。モニター企業さまと実業務で検証中。 2. **NEXTクローズドβ** モニター企業さまへ優先提供。手順書出力と改善提案レポートの実運用。 3. **FUTURE正式リリース** 一般提供の開始。料金・提供形態はモニター企業さまの声をもとに設計します。 ### 先行モニター企業さま募集 「手順書とマニュアルにずっと困っている」現場を持つ企業さまを、数社限定で募集しています。 - 貴社の実業務に合わせた検証環境をこちらで構築 - 機能のご要望を開発ロードマップへ優先的に反映 - 正式リリース時は先行導入の特別条件をご用意 [モニターについて問い合わせる](https://technosphere.co.jp/contact) [資料をダウンロード（PDF）](https://technosphere.co.jp/assets/download/flowlens-pamphlet.pdf) お問い合わせフォームに「FlowLensモニター希望」とお書きください。まずは30分ほどのオンラインでのヒアリングから始めます。 FAQ ─ よくいただく質問 ## 気になるところにお答えします。 いま導入できますか？ 現在は開発中（PoC段階）のため、一般販売はまだ行っていません。先行モニターとして一緒に検証いただける企業さまを募集しており、モニター企業さまには検証環境の構築と、ご要望の優先反映でお応えします。 画面の記録データはどこに保存されますか？ 記録クライアントはWindows端末上で動作し、解析サーバはDockerコンテナとして貴社内（オンプレミス）またはクラウドに構築できます。画面データを社外に出せない現場を想定し、閉域での運用を前提とした構成もご相談いただけます。 どんなアプリの操作でも記録できますか？ 記録対象はWindows上の画面操作です。特定アプリ向けの作り込みではなく、画面そのものと操作イベントをAIが解釈する方式のため、基幹システム・Excel・ブラウザ業務など幅広いアプリを対象にできます。 手順書はどんな形式で出力されますか？ スクリーンショット付きの手順書をMarkdownやWord（docx）で出力できるほか、社内Wikiへの登録にも対応予定です。中間データを共通形式で保持しているため、出力先は今後も増やしていきます。 ## 手順書は、書くものから 育つものへ。 FlowLensに興味を持っていただけたら、まずは現場のお悩みをお聞かせください。 売り込みではなく、開発中の画面をお見せしながらの意見交換から始めます。 [FlowLensについて問い合わせる](https://technosphere.co.jp/contact) 「うちの業務でも使える？」だけでも歓迎です。 --- # ドローンインスペクター3D｜ブラウザで遊べる3Dゲーム（インストール不要）｜テクノスフィア > スマホ・PCのブラウザだけで動く3Dドローン点検ゲーム。インストール不要・サーバー通信なしのフロントエンド技術デモです。夕暮れの工業地帯を飛行し、制限時間内に10箇所の検査ポイントを巡回せよ。Three.js製。 URL: https://technosphere.co.jp/games/drone-inspector/ INSPECTED 0/10 TIME 120s 0 km/h 3 m ▲ MOVE TURN / UP TECHNOSPHERE TECH DEMO # DRONE INSPECTOR 3D— 夕暮れの工業地帯を点検飛行せよ — インストール不要・通信なし。このゲームはブラウザの中だけ（フロントエンドのみ）で動いています。 制限時間**120秒**でシアンに光る**検査リング10箇所**を通過しよう。障害物への接触は減点。 📱 スマホ: **左スティック**=移動 / **右スティック**=旋回・昇降 💻 PC: **WASD**=移動 / **←→(Q/E)**=旋回 / **Space・Shift**=昇降 / **R**=リスタート MISSION RESULT # TIME UP [⚔ 第2弾: トルーパーラッシュ3D もプレイ](https://technosphere.co.jp/games/trooper-rush/) [📖 この3Dゲームの作り方を技術コラムで解説しています](https://technosphere.co.jp/blog/threejs-mobile-3d-game) [スマホアプリ・Webアプリ開発のご相談はこちら](https://technosphere.co.jp/contact?category=web) ｜ [テクノスフィア トップへ](https://technosphere.co.jp/) © TECHNOSPHERE Inc. — Three.js / WebGL Frontend-only Tech Demo --- # トルーパーラッシュ3D｜ブラウザで遊べる兵団ランナーゲーム（インストール不要）｜テクノスフィア > スマホ・PCのブラウザだけで動く3D兵団ランナーゲーム。左右に動かしてゲートで兵力を増やし、迫りくる敵の大軍を撃ち破れ。インストール不要・サーバー通信なしのフロントエンド技術デモ第2弾。Three.js製。 URL: https://technosphere.co.jp/games/trooper-rush/ TROOPS 10 POWER x1 DISTANCE 0m TECHNOSPHERE TECH DEMO #2 # TROOPER RUSH 3D— ゲートで兵団を強化し、敵の大軍を撃ち破れ — インストール不要・通信なし。ブラウザだけ（フロントエンドのみ）で動く兵団ランナー。 **青いゲート**で兵力アップ（+N / x2 / 攻撃力UP）、**赤いゲート**は減少。敵部隊は自動射撃で削り、残った敵とは数で相殺！ 📱 スマホ: **画面をドラッグ**して左右移動 💻 PC: **A / D** または **← / →**（マウスドラッグも可）／ **R**=リスタート MISSION RESULT # RESULT [🚁 第1弾: ドローンインスペクター3D もプレイ](https://technosphere.co.jp/games/drone-inspector/) [📖 ブラウザ3Dゲームの作り方（技術コラム）](https://technosphere.co.jp/blog/threejs-mobile-3d-game) ｜ [アプリ開発の相談](https://technosphere.co.jp/contact?category=web) © TECHNOSPHERE Inc. — Three.js / WebGL Frontend-only Tech Demo --- # 遠隔保守の拠点間VPNゲートウェイ「GENBA Gate」｜テクノスフィア > 現場と当社事務所を拠点間VPNでつなぐ、装置込みの遠隔保守サービスです。小型ゲートウェイを1台置くだけで、工場や施設の監視カメラ・ネットワークレコーダーを当社が遠隔で点検・設定変更します。固定回線は不要でモバイル回線に対応。着信ポートの開放はゼロ、既存機器の設定変更も不要です。 URL: https://technosphere.co.jp/genba-gate ** 新サービス — 装置・初期設定込みのセキュアVPN # 現場に置くだけ。 行かずに、直せる。 遠隔保守・遠隔監視のための拠点間VPNゲートウェイ 離れた現場に小型ゲートウェイを1台。現場と当社事務所がセキュアなVPNで常時つながり、 IPカメラやレコーダーの点検・設定変更・障害の切り分けを当社が遠隔で行います。 固定回線のない現場でも、モバイル回線があれば始められます。 [導入を相談する](https://technosphere.co.jp/contact?category=genba_gate) [パンフレット](https://technosphere.co.jp/assets/download/genba-gate-pamphlet.pdf) 1台 現地に置く装置 0 開放する着信ポート 不要 既存機器の設定変更 （図: GENBA Gate 本体。前面にLANポート2口・USBポート・USB-C電源と稼働ランプを備えた小型の金属筐体） The Challenge ## 遠隔保守が進まないのは、行くしかないから 工場・倉庫・施設に置いた監視カメラやネットワークレコーダーは、設定をひとつ確認するだけでも半日かけて現地へ向かうことになりがちです。リモートメンテナンスが進まない理由は、たいてい次の3つに集約されます。 ** ### 障害のたびに 現地へ駆けつけている 出張のたびに費用と人員が要り、復旧までの時間も長くなります。原因が単純な設定ミスでも、行ってみるまで分かりません。 ** ### 現場に固定回線がない 光回線を引けない場所、引くには費用と工期が見合わない場所があります。モバイルルーターしか使えない現場も少なくありません。 ** ### 遠隔化はセキュリティが不安 外部からの入口を開ける、映像をクラウドに預ける。どちらも社内の承認を通しにくく、話が止まってしまいます。 How It Works ## 現場と当社事務所を、拠点間VPNでつなぐ 現地で必要な作業は、箱を開けて電源とLANをつなぐことだけです。設定は出荷前に当社で済ませてお届けするため、現場にネットワークの担当者がいなくても遠隔保守の環境が整います。 ### 現地に1台置く 設定済みの状態で発送します。現地では電源をつなぎ、構内LANとモバイルルーターにLANケーブルを挿すだけです。設定を変える必要が出ても、モニタとキーボードをつなげば画面上で操作できます。 ### 当社事務所へ自動でつながる 電源が入るとゲートウェイ側から当社事務所へ接続を張ります。外部からの入口を作らないので、現地のルーター設定を緩める必要はありません。回線が切れても自動で張り直します。 ### 当社が遠隔で保守 当社の担当者が現地のカメラやレコーダーへ、その場にいるのと同じようにアクセスして点検・設定変更を行います。RTSPやHTTP、メーカー独自の管理ツールもそのまま扱えます。 現地（お客様の施設） - ** IPカメラ・レコーダー - ** GENBA Gate - ** モバイルルーター ゲートウェイ側から発信 暗号化されたVPNトンネル テクノスフィア事務所 - ** VPNルーター（固定IP） - ** 保守担当者のパソコン 通信はゲートウェイ側から張り出します。外部から現地へ入る経路は作りません。 Why GENBA Gate ## 現場にも、情報システム部門にも 説明できる仕組み 遠隔化の話が止まるのは、たいてい安全性の説明ができないときです。GENBA Gate は「どこと、どちら向きに通信するか」を単純にすることで、その説明を成り立たせています。 ** ### 通信相手は当社事務所だけ ゲートウェイがつながる先は、テクノスフィアの事務所ただ1か所です。外部のクラウドサービスを経由しないため、映像や機器の情報が第三者の環境を通ることがありません。 ** ### 着信ポートの開放はゼロ 接続は必ずゲートウェイ側から発信します。現地のルーターに外部からの入口を作らないため、ポート開放やDMZの設定は不要です。 ** ### 既存機器の設定変更は不要 ゲートウェイが送信元を自分のIPに変換して構内LANへ転送します。カメラやレコーダーからは「ゲートウェイとの通信」に見えるため、既存機器側の設定はそのままで済みます。 ** ### モバイル回線で成立 グローバルIPが割り当てられない回線でも接続できます。固定回線の敷設を待たずに始められ、モバイルルーターの機種や回線事業者も選びません。 ** ### 現地はパソコンなしで設定完結 モニタとキーボードをつなぐと設定画面が立ち上がります。マウスも作業用パソコンも持ち込まずに、現地作業を終えられます。 ** ### 装置から保守までまとめて 機器の調達と初期設定、当社側での接続受け入れ、そして日々の遠隔保守と稼働監視まで、すべて込みで提供します。お客様に用意いただくのは回線と設置場所だけです。 In Place ## 置き場所は、棚のすき間ひとつ分 ファンのない金属筐体で、動作音はありません。装置がやることは通信を暗号化して転送することだけなので、高価な機材は必要としません。 （図: 工場の機械室の棚に置かれたGENBA Gate本体と、LANケーブルでつながれたモバイルルーター。奥の壁には監視カメラ） 現地：棚に置いて、電源とLANをつなぐだけ （図: 当社事務所で担当者がモニタに映る現地カメラの4分割映像を確認している様子） 当社事務所：現地にいるのと同じように機器へアクセス What's Included ## 装置も保守も、まとめてお任せいただけます 機器を売って終わりにはしません。現場のゲートウェイは当社事務所とつながり、点検も障害対応も当社が引き受けます。お客様に用意いただくのは、通信回線と設置場所だけです。 | 項目 | 内容 | ご用意 | | ゲートウェイ装置 | 本体とACアダプタ。設定済みの状態で発送します。 | 標準 | | 初期設定 | 現場の構内LANに合わせた設定と、出荷前の疎通確認を当社で行います。 | 標準 | | 当社側のVPN受け入れ | 当社事務所のルーターでの接続受け入れと経路設定。お客様側での作業はありません。 | 標準 | | 遠隔保守 | 点検・設定変更・障害の切り分けを当社が代行します。 | 標準 | | 稼働監視 | 接続断の検知と復旧対応。復旧しない場合は当社からご連絡します。 | 標準 | | 通信回線 | モバイルルーターなど。既にお使いの回線があればそのまま利用できます。 | お客様手配 | | 設置場所と電源 | 屋内の棚などにゲートウェイを置くスペースとコンセント。 | お客様手配 | | LANケーブル | 構内LANとゲートウェイをつなぐためのもの。 | お客様手配 | ** ### 当社事務所につなぐ標準構成 現場のゲートウェイは当社事務所とVPNで常時つながります。お客様のオフィス側に用意いただく機器や固定IPはありません。点検・設定変更・障害の切り分けは当社が代行します。 ** ### お客様のオフィスにつなぐ場合 接続先をお客様のオフィスに変更することも技術的には可能ですが、**当社のサポート対象外**となります。オフィス側に固定のグローバルIPとVPNを終端できるルーターが必要です。ご希望の場合は個別にご相談ください。 料金は台数・拠点数・保守の範囲によって変わります。構成をうかがったうえでお見積りしますので、 [お問い合わせ](https://technosphere.co.jp/contact?category=genba_gate)ください。 Before You Start ## 導入前に、実際の回線で確かめます モバイル回線は事業者や契約によって挙動が変わります。「つながるはず」で進めず、次の項目をお客様の現地回線で確認してから導入します。 - ** UDP 500 / 4500 が現地の回線を通ること - ** VPNトンネルが確立すること - ** 通信のない時間帯もNATテーブルが維持されること（keepalive 30秒） - ** 映像の視聴に足る実効スループットが出ること - ** 24時間の連続稼働と、回線が切れたあとの自動再接続 - ** 設置場所と電源、ゲートウェイから構内LANへの配線 UDPが通らない特殊な回線の場合は、別の方式に切り替えて対応します。 FAQ ## 遠隔監視・遠隔保守でよくいただくご質問 接続先の選び方、対応できる回線、監視カメラやレコーダーへの影響、通信量、障害時の動きなど、よくお問い合わせいただく内容をまとめました。 [よくあるご質問を見る](https://technosphere.co.jp/genba-gate-faq) ## その現場、 行かずに見られるようになります 拠点の数や現地の回線をうかがえば、導入できるかどうかはすぐに判断できます。 まずは現状をお聞かせください。 [導入を相談する](https://technosphere.co.jp/contact?category=genba_gate) [よくあるご質問](https://technosphere.co.jp/genba-gate-faq) [パンフレット](https://technosphere.co.jp/assets/download/genba-gate-pamphlet.pdf) [プライバシーポリシー](https://technosphere.co.jp/privacy)に同意のうえ、お問い合わせください。 --- # GENBA Gate よくあるご質問｜遠隔保守ゲートウェイサービス｜テクノスフィア > 現場と当社事務所を拠点間VPNでつなぐ遠隔保守サービス「GENBA Gate」について、対応できる回線、セキュリティの考え方、既存のカメラ・レコーダーへの影響、通信量、障害時の動作、導入の進め方など、検討時によくいただくご質問をまとめました。 URL: https://technosphere.co.jp/genba-gate-faq （図: GENBA Gate） # よくあるご質問 現場と当社事務所を拠点間VPNでつなぐ遠隔保守サービス「GENBA Gate」について、ご検討の段階でよくいただくご質問をまとめました。 ここにない点は[お問い合わせ](https://technosphere.co.jp/contact?category=genba_gate)からお気軽にお尋ねください。 ## 接続先について Qゲートウェイはどこに接続しますか？ A 標準構成では、テクノスフィアの事務所に接続します。現場のゲートウェイと当社事務所をVPNで常時つなぎ、カメラやレコーダーの点検・設定変更・障害の切り分けを当社が遠隔で行います。 Qお客様側に用意するものはありますか？ A 通信回線（モバイルルーターで構いません）、屋内の設置スペースとコンセント、構内LANにつなぐLANケーブルだけです。VPNを受け入れる機器や固定グローバルIPを、お客様側でご用意いただく必要はありません。 Q接続先を自社のオフィスに変更できますか？ A 技術的には可能ですが、当社事務所以外を接続先にする構成は**当社のサポート対象外**となります。その場合はオフィス側に固定のグローバルIPとVPNを終端できるルーターが必要です。ご希望の場合は個別にご相談ください。 Q複数の現場をまとめて保守してもらえますか？ A できます。現場ごとにゲートウェイを1台設置し、それぞれが当社事務所へ接続する構成になります。拠点が増えても、お客様側で追加の設定作業は発生しません。 ## 回線・接続 Qどのような回線で使えますか？ A 光回線でもモバイル回線でも使えます。グローバルIPが割り当てられない回線（CGNAT）でも、ゲートウェイ側から接続を張り出す方式のため利用できます。ただし通信の制限は事業者や契約によって異なるため、導入前にお客様の現地回線で実際に疎通を確認したうえで進めます。 Qモバイルルーターの機種や回線事業者に指定はありますか？ A ありません。すでにお使いのモバイルルーターがあれば、そのまま利用できます。UDPを遮断する特殊な回線だった場合のみ、別の方式に切り替えて対応します。 Q固定IPアドレスは必要ですか？ A お客様側には必要ありません。固定IPを持つのは当社事務所側だけです。現場側は動的なIPでも、プライベートIPしか割り当てられない回線でも接続できます。 Q通信量はどのくらいになりますか？ A 待機中の通信量はごくわずかです（接続を維持するため30秒ごとに小さなパケットを送ります）。大きく増えるのは映像を見たときで、確認の頻度と画質によって決まります。従量課金の回線をお使いの場合は、想定される使い方をうかがったうえで見込みをお伝えします。 ## セキュリティ Q外部からの着信ポートを開ける必要はありますか？ A ありません。接続は必ずゲートウェイ側から発信します。現地のルーターにポート開放やDMZの設定を入れる必要はなく、外部から現地へ入る経路そのものを作りません。 Qゲートウェイはどこと通信しますか？ A テクノスフィアの事務所、ただ1か所です。外部のクラウドサービスを経由しないため、通信が第三者の環境を通ることがありません。 Q映像はどこかに保存されるのですか？ A ゲートウェイやクラウドに映像を保存することはありません。当社が映像を預かることもありません。現地のレコーダーに記録されている映像を、保守に必要なときに確認するだけです。 Q構内LANのすべての機器にアクセスできてしまうのですか？ A いいえ。アクセスできる範囲は、事前に取り決めた機器とポートに限定して設定します。対象外の機器へは到達できないようにします。逆向き、つまり現場から当社の社内ネットワークへ通信することもできません。 Qゲートウェイの設定画面は外から見えますか？ A 見えません。設定画面は現地の構内LANからのみ開けるよう制限しています。必要に応じてパスワードによる保護も併用します。 ## 既存の設備への影響 Qカメラやレコーダーの設定を変更する必要はありますか？ A ありません。ゲートウェイが通信の送信元を自分のIPアドレスに変換して構内LANへ転送するため、既存機器からは同じLAN内の機器との通信に見えます。ゲートウェイを既定のゲートウェイに指定するといった設定変更も不要です。 Qメーカー独自の管理ソフトも使えますか？ A 使えます。RTSPやHTTPだけでなく、メーカー独自のプロトコルもそのまま通ります。現地で使っている管理ツールを、当社事務所からそのまま操作できます。 Q既存のネットワーク機器を入れ替える必要はありますか？ A ありません。ゲートウェイを1台追加するだけで、既存のスイッチやルーターはそのまま使えます。 ## 設置・運用 Q現地ではどんな作業が必要ですか？ A 電源をつなぎ、構内LANとモバイルルーターにLANケーブルを挿すだけです。設定は出荷前に当社で済ませてお届けするため、現地でネットワークの知識を要する作業は発生しません。 Q設定を変えたいとき、現地へ行く必要はありますか？ A ありません。当社が遠隔で変更します。現地で操作が必要になった場合も、ゲートウェイにモニタとキーボードをつなげば画面上で設定でき、作業用のパソコンやマウスを持ち込む必要はありません。 Q回線が切れたらどうなりますか？ A 自動で再接続します。復旧しない状態は当社側の稼働監視で検知しますので、状況を確認のうえご連絡します。 Q停電のあとはどうなりますか？ A 電源が戻れば自動的に起動し、接続を張り直します。現地での操作は必要ありません。 Q動作音や設置スペースはどのくらいですか？ A ファンのない金属筐体のため動作音はありません。屋内の棚などに置ける大きさで、必要なのは設置スペースとコンセントだけです。 ## 導入について Q1拠点だけでも導入できますか？ A できます。まず1拠点で試していただき、運用に乗ることを確認してから広げる進め方もご相談いただけます。 Q導入までどのくらいかかりますか？ A 現地の回線と保守対象の機器をうかがい、実際の回線で事前確認を行ったうえで、設定済みの装置を発送します。所要期間は構成や事前確認の結果によって変わりますので、ご相談ください。 Q料金はいくらですか？ A 台数・拠点数・保守の範囲によって変わるため、一律の金額はご案内していません。構成をうかがったうえでお見積りします。 Qカメラやレコーダー以外の機器でも使えますか？ A ネットワークにつながる機器であれば、対象にできる場合があります。制御機器や計測機器など、対象にしたい機器がお決まりでしたらご相談ください。 ## 解決しないことがあれば、 そのままお聞かせください 現地の回線や保守したい機器の話をうかがえば、導入できるかどうかはすぐに判断できます。 [導入を相談する](https://technosphere.co.jp/contact?category=genba_gate) [GENBA Gate の紹介へ](https://technosphere.co.jp/genba-gate) [プライバシーポリシー](https://technosphere.co.jp/privacy)に同意のうえ、お問い合わせください。 --- # GENBA IQ ニュース&プレスリリース | 株式会社テクノスフィア > GENBA IQの最新ニュース・プレスリリース・PoC募集情報・技術情報をお届けします。製造・交通・建設・物流・小売・医療のあらゆる現場に対応するエッジAIプラットフォームの最新情報はこちら。 URL: https://technosphere.co.jp/genba-iq-news NEWS & PRESS RELEASE # GENBA IQ 最新情報 プレスリリース、PoC募集情報、技術情報など、GENBA IQに関する最新ニュースをお届けします。 ## （図: GENBA IQ ローンチ） プレスリリース 2026.04.24 GENBA IQ 発表 — 次世代エッジAIプラットフォームで現場DXを加速 株式会社テクノスフィアは、映像・音声・センサーを統合するエッジAIプラットフォーム「GENBA IQ」を発表しました。製造・交通・建設・物流・小売・医療のあらゆる現場に対応し、既存カメラをそのまま活用できるソリューションです。現在PoC参加企業を募集中です。 続きを読む （図: 物流PoC） PoC募集中 2026.04.24 ### 物流倉庫向けPoC参加企業を募集中 — フォークリフト動線最適化・空走率削減を2週間で検証 GENBA IQのフォークリフト動線トラッキング機能を活用した物流倉庫向けPoC（実証実験）の参加企業を募集しています。最短2週間・既存カメラ活用で、空走率削減やヒヤリハット低減の効果を実際の現場で検証できます。 物流PoC募集フォークリフト効率化 （図: 製造ライン外観検査） PoC募集中 2026.04.24 ### 製造ライン向けPoC参加企業を募集中 — 外観検査・品質管理の自動化を2週間で検証 製造ラインの外観検査・異常検知を自動化するPoC参加企業を募集しています。YOLOv8ベースの高精度モデルを既存ラインカメラに接続し、不良品流出リスクの低減効果を短期間で確認できます。初期費用不要・設備改修なしで導入可能です。 製造PoC募集外観検査品質管理 （図: 建設現場安全） PoC募集中 2026.04.24 ### 建設現場向けPoC参加企業を募集中 — ヘルメット未着用・重機接近をリアルタイム検知 建設現場の安全管理自動化に向けたPoC参加企業を募集しています。ヘルメット・安全ベスト未着用の検知、重機との危険接近アラートをリアルタイムで実現。既存の現場カメラをそのまま活用でき、工事期間中のスポット導入も可能です。 建設PoC募集安全管理ヘルメット検知 （図: 交通システム） 技術情報 2026.04.24 ### GENBA IQのコア技術：YOLOv8 + OpenCVによる12ms以下のエッジ推論アーキテクチャ GENBA IQはYOLOv8とOpenCVを組み合わせたリアルタイム推論エンジンを搭載。Jetson Thor・Orin NX上での12ms以下の推論を実現する独自の最適化アーキテクチャを採用しています。クラウド不要のエッジ処理により、通信遅延ゼロの即時判断を可能にします。 技術情報YOLOv8JetsonエッジAI （図: 小売AI） PoC募集中 2026.04.24 ### 小売・サービス業向けPoC参加企業を募集中 — カスハラ検知・接客品質分析を2週間で検証 音声パターン分析と動作検知を組み合わせたカスタマーハラスメント検知・接客品質分析のPoC参加企業を募集しています。既存の店内カメラ・マイクを活用し、スタッフの安全確保と顧客対応品質の向上を同時に実現する効果を2週間で検証できます。 小売PoC募集カスハラ検知接客品質 最新ニュース 2026.04.24 GENBA IQ 発表 — 次世代エッジAIプラットフォーム 2026.04.24 物流倉庫向けPoC参加企業を募集中 2026.04.24 製造ライン向けPoC参加企業を募集中 2026.04.24 建設現場向けPoC参加企業を募集中 カテゴリ - プレスリリース1 - PoC募集中4 - 技術情報1 #### GENBA IQを 現場で試してみませんか？ 最短2週間のPoCで効果を実感。まずはお気軽にご相談ください。 [無料デモを予約する](https://technosphere.co.jp/contact?category=genba_iq) 2026年4月24日 プレスリリース # 株式会社テクノスフィア、次世代エッジAIプラットフォーム「GENBA IQ」を発表 — 現場の映像・音声・センサーを統合し、リアルタイムで判断するAIで現場DXを加速 株式会社テクノスフィア（所在地：大阪、以下「当社」）は、2026年4月24日、エッジAIソリューション「GENBA IQ」を発表し、PoC（実証実験）参加企業の募集を開始しました。GENBA IQは、既存カメラ・マイク・IoTセンサーを活用し、製造・交通・建設・物流・小売・医療のあらゆる現場における「人の目による判断」をAIで代替・強化するプラットフォームです。 （図: GENBA IQ コンセプトビジュアル） ### 背景：現場DXの「最後の壁」を突破する 製造業・建設業・物流業などの現場では、長年にわたり「人の目による目視検査・監視」が品質管理や安全管理の中心を担ってきました。しかし、少子高齢化による人手不足、熟練技術者の引退、24時間対応コストの増大といった課題が深刻化しています。 既存の監視カメラシステムは映像を「録画」するだけにとどまり、リアルタイムでの判断・通知・分析には人間の介在が必要でした。GENBA IQはこの「現場DXの最後の壁」を突破します。 ### GENBA IQの主要機能 - **VLM（Vision-Language Model）による映像の文脈理解**：単なる物体検出を超え、「なぜ危険か」「どのような状況か」を言語で理解・判断 - **音声パターン分析**：暴言・高圧的トーン・異常音の検知 - **センサーフュージョン**：カメラ＋音声＋棚センサー＋環境センサーの統合処理 - **YOLOv8 + OpenCVによる12ms以下のリアルタイム推論**：エッジ処理のためクラウド不要 - **デバイスフリー戦略**：Jetson Thor〜Raspberry Pi 5まで同一基盤で動作 12ms推論速度（エッジ処理） 最大16台同時カメラ処理 2週間最短PoC開始期間 ### 今後の展開とPoC募集 現在、製造業・物流業・建設業・小売業を中心にPoC（実証実験）参加企業を募集しています。最短2週間・既存カメラ活用で、実際の現場における効果を検証していただけます。 製造・物流・交通インフラ分野を中心に展開を予定しており、医療・介護分野への対応も順次進めてまいります。ご興味のある企業様はお気軽にお問い合わせください。 ### 導入の流れ まずは2週間のPoC（既存カメラ活用）で効果を確認いただき、その結果を踏まえて本導入プランをご提案します。料金・導入費用についてはお問い合わせください。 #### 会社概要 | 会社名 | 株式会社テクノスフィア | | 所在地 | 〒532-0011 大阪市淀川区西中島7丁目7-3 エフベースミュゼオ201 | | 事業内容 | AIソリューション開発・エッジAI・画像認識・RAGチャットボット | | URL | [https://technosphere.co.jp](https://technosphere.co.jp) | | 問合せ先 | [お問い合わせフォーム](https://technosphere.co.jp/contact) | この記事をシェア： [X（Twitter）](https://twitter.com/intent/tweet?text=GENBA IQ — 現場を理解するエッジAIプラットフォーム PoC参加企業募集中&url=https://technosphere.co.jp/genba-iq-news) [Facebook](https://www.facebook.com/sharer/sharer.php?u=https://technosphere.co.jp/genba-iq-news) [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https://technosphere.co.jp/genba-iq-news) [GI GENBA IQ](https://technosphere.co.jp/genba-iq) [株式会社テクノスフィア](https://technosphere.co.jp/) [GENBA IQ 特設ページ](https://technosphere.co.jp/genba-iq) [お問い合わせ](https://technosphere.co.jp/contact?category=genba_iq) [プライバシーポリシー](https://technosphere.co.jp/privacy) © 2026 株式会社テクノスフィア — GENBA IQ News --- # カラオケ採点デモ（ブラウザ版）｜音程・ビブラート・しゃくり・こぶしをリアルタイム検出｜テクノスフィア > マイクの歌声からYINアルゴリズムで基本周波数(F0)をリアルタイム推定し、音程のズレ(セント)・ビブラート・しゃくり・こぶしをブラウザだけで検出する技術デモ。音声はすべてブラウザ内で処理され、サーバーには一切送信されません。マイクなしで試せるシミュレーション歌唱モード付き。 URL: https://technosphere.co.jp/labs/karaoke/ REAL-TIME SINGING ANALYSIS × WEB AUDIO API # カラオケ採点デモ 音程・ビブラート・しゃくり・こぶしを検出 マイクの歌声から基本周波数(F0)を **YINアルゴリズム** でリアルタイム推定し、 音程のズレ(セント単位)と歌唱テクニックをブラウザだけで検出する技術デモです。 音声は**すべてブラウザ内で処理**され、サーバーには一切送信されません。 G3 (196Hz) A3 (220Hz) C4 (262Hz) D4 (294Hz) E4 (330Hz) G4 (392Hz) A4 (440Hz) 「マイクで歌う」でマイク解析を開始。マイクがない場合は「シミュレーション歌唱」で合成音声の解析をご覧いただけます。 ** 音程OK (±30セント以内) ** 音程のズレ ** ビブラート ** しゃくり ** こぶし ### PITCH — いま歌っている音 — ズレ **—** セント ### TECHNIQUES & SCORE — 検出結果 0.0sビブラート 0しゃくり 0こぶし 0%音程正確率 0スコア ## これは何？ 業務用カラオケの「精密採点」的な歌声解析を、Web Audio APIとVanilla JavaScriptだけでブラウザ上に再現した技術デモです。 マイク入力から **YIN法**（de Cheveigné & Kawahara, 2002）で基本周波数を推定し、 そのピッチ軌跡を解析して「音程のズレ（セント）」「ビブラート」「しゃくり」「こぶし」を検出しています。 各テクニックの音響的な定義、YINアルゴリズムの中身、検出ロジックの設計は [解説記事「カラオケ採点システムの仕組み」](https://technosphere.co.jp/blog/karaoke-scoring-engine)で詳しく紹介しています。 ## 使い方・楽しみ方 1. **音程チェック**：「ガイド音を鳴らす」で基準音を再生し、同じ高さで「あー」と歌うと、ゲージにセント単位のズレが表示されます。±30セント以内でキープできれば音程OK（シアン色）です。 2. **ビブラート**：声を伸ばしながら高さを規則的に揺らしてみてください。毎秒5〜7回・±20〜50セント程度の規則的な揺れが約1秒続くと「ビブラート」と判定されます。 3. **しゃくり**：目標の音より低い音から「ずり上げて」歌い出すと「しゃくり」バッジが出ます。 4. **こぶし**：音を伸ばしている途中で「うぅん↑」と一瞬だけ音を持ち上げてすぐ戻すと「こぶし」と判定されます（演歌の要領で）。 5. マイクがない環境では**「シミュレーション歌唱」**を押すと、合成音声（ストレート→しゃくり→ビブラート→こぶし）が同じ解析パイプラインを通る様子を確認できます。 ## プライバシーについて - マイクの音声は、お使いのブラウザの中だけで解析されます。**録音データ・解析結果がサーバーへ送信されることは一切ありません**（本ページは静的配信のみで、送信先そのものがありません）。 - マイクの使用はブラウザの許可ダイアログで制御されます。「停止」を押すとマイクは完全に解放されます。 - 本デモの採点ロジックは学習用の簡易モデルであり、実際の業務用カラオケ採点機の仕様とは無関係の独自実装です。 ## 技術メモ - F0推定: YIN法（差分関数＋累積平均正規化＋放物線補間）を2048サンプル窓で毎フレーム実行 - 音程: 平均律（A4=440Hz）の最寄り半音とのズレをセント値 `1200×log2(f/f_ref)` で算出 - ビブラート: ピッチ残差のゼロ交差から揺れの速さ(4〜8.5Hz)・深さ(8セント以上)・規則性を判定 - しゃくり: ノート確定直前の軌跡が「80セント以上低い位置から概ね単調に上昇」していたら検出 - こぶし: 保持中の音から+60セント以上の山が出て400ms以内に戻ったら検出（ビブラート中は除外） - 対応ブラウザ: Chrome / Edge / Firefox / Safari の最新版（マイク使用にはHTTPSが必要） 音声信号処理・リアルタイム解析・エッジAIの開発はテクノスフィアの得意分野です。 [技術解説記事を読む](https://technosphere.co.jp/blog/karaoke-scoring-engine) [開発の相談をする](https://technosphere.co.jp/contact) --- # PC-88エミュレータ（ブラウザ版）｜QUASI88 WebAssembly移植・技術デモ｜テクノスフィア > レトロPC「PC-8801」のエミュレータQUASI88をWebAssemblyに移植し、ブラウザだけで動く技術デモとして公開。ROMは同梱せず、お手持ちのROMファイルをブラウザ内でローカル読込（サーバー送信なし）。著作権に配慮した構成と実装を解説記事付きで公開しています。 URL: https://technosphere.co.jp/labs/pc88/ RETRO COMPUTING × WEBASSEMBLY # PC-88エミュレータをブラウザで動かす 1980年代の名機 NEC PC-8801 のエミュレータ「QUASI88」を WebAssembly に移植した技術デモです。 **ROMは同梱していません。**実機をお持ちの方は、ご自身で吸い出したROMファイルを読み込んで起動できます。 ROMファイルはブラウザの中だけで処理され、**サーバーには一切送信されません。** 読み込み中… PC（物理キーボード）でのご利用を推奨します。F12キーまたはMENUボタンで内蔵メニューが開きます。 ## ROMファイルの選択 **ROMファイルはこのページには含まれていません。** PC-8801実機をお持ちの方が、ご自身の実機から吸い出したROMファイル（私的複製）を選択してください。 選択したファイルは**お使いのブラウザ内（IndexedDB）にのみ保存され、サーバーへは送信されません**。 インターネット上で配布されているROMファイルのダウンロードは著作権侵害となるため、絶対に行わないでください。 | N88 BASIC ROM | 32KB | N88.ROM | - | | | N88 BASIC 拡張ROM バンク0 | 8KB | N88EXT0.ROM | - | | | N88 BASIC 拡張ROM バンク1 | 8KB | N88EXT1.ROM | - | | | N88 BASIC 拡張ROM バンク2 | 8KB | N88EXT2.ROM | - | | | N88 BASIC 拡張ROM バンク3 | 8KB | N88EXT3.ROM | - | | | N BASIC ROM | 32KB | N88N.ROM | - | | | サブシステム ROM | 2KB/8KB | N88SUB.ROM | - | | | 漢字ROM 第1水準 | 128KB | N88KNJ1.ROM | 任意 | | | 漢字ROM 第2水準 | 128KB | N88KNJ2.ROM | 任意 | | | 辞書ROM | 512KB | N88JISHO.ROM | 任意 | | | フォントイメージ | 2KB | FONT.ROM | 任意 | | ## これは何？ PC-8801用エミュレータ **QUASI88**（福永省三氏作・修正BSDライセンス）の WebAssembly 移植版 **quasi88nc**（Takashi Toyoshima氏作・BSD-3-Clause）をベースに、 当社がブラウザ実行用に調整してホスティングしている技術デモです。 Z80 CPU・メモリ・FDC・画面まわりの全エミュレーションが、インストール不要でブラウザの中だけで動きます。 移植の仕組み（Emscripten・ASYNCIFY・IndexedDBによるファイル永続化）と著作権の整理については、 [解説記事「PC-88エミュレータをブラウザで動かす」](https://technosphere.co.jp/blog/pc88-emulator-wasm)で詳しく紹介しています。 ## 使い方 1. **ROMをお持ちの方**：上の選択画面で実機から吸い出したROMファイルを読み込み、「完了（起動）」を押すと N88-BASIC が起動します。DISKボタンで .d88 ディスクイメージ（ご自身に権利があるもの）もマウントできます。 2. **ROMをお持ちでない方**：「ROMなしで起動」で、エミュレータ本体と内蔵メニュー（MENUボタン）の動作をご覧いただけます。BASIC画面はROMがないため表示されません。 3. 読み込んだファイルはブラウザ内（IndexedDB）に保存され、次回訪問時に再選択は不要です。ブラウザのサイトデータ削除でいつでも消去できます。 ## 著作権について（重要） - エミュレータ本体（QUASI88 / quasi88nc）はBSDライセンスのオープンソースソフトウェアであり、本ページでの公開はライセンスに基づくものです。 - **N88-BASIC ROM等のROMファイルは日本電気株式会社（NEC）等の著作物であり、本ページでは一切配布・同梱していません。** - ROMの読み込み機能は、実機所有者がご自身で作成した私的複製物（著作権法第30条）を、ご自身のブラウザ内で利用することを想定したものです。ファイルがサーバーへ送信されることはありません。 - インターネット上で配布されているROMファイルや市販ソフトのディスクイメージの入手・利用は著作権侵害にあたります。当社はこれを一切推奨しません。 - PC-8801は日本電気株式会社の製品です。本ページは同社とは無関係であり、製品名は歴史的事実の記述のためにのみ使用しています。 ## ライセンス表記 本ページで配布しているエミュレータバイナリ（quasi88.js / quasi88.wasm）は以下の成果物を含みます。 詳細は [LICENSES.txt](https://technosphere.co.jp/labs/pc88/LICENSES.txt) をご覧ください。 - QUASI88 — Copyright (c) Showzoh Fukunaga（修正BSDライセンス） - quasi88nc (WASM移植) — Copyright (c) 2012, Takashi Toyoshima（BSD-3-Clause） - ビルド: Emscripten（MIT）／ SDL2（zlib license） - ※ サウンド出力部（MAME/XMAME・fmgen由来コード）はライセンス上の配慮によりビルドから除外しています（本デモは無音です） レガシー資産の延命・移植（Z80/8051アセンブラ資産のマイグレーション、WebAssembly化）はテクノスフィアの得意分野です。 [技術解説記事を読む](https://technosphere.co.jp/blog/pc88-emulator-wasm) [開発の相談をする](https://technosphere.co.jp/contact) --- # マイコン移行判断ナビ｜生産中止(EOL)からの移行先と工数の見立て｜テクノスフィア > H8・SuperH・8051・Z80・東芝TLCSなど生産終了マイコンの移行先を、移行元ファミリから逆引きできます。RL78/RX/RA/STM32への対応関係、エンディアンや周辺機能の壁、工数を左右する要因まで整理。大阪の受託開発会社テクノスフィアが実務をもとに作成。 URL: https://technosphere.co.jp/mcu-migration 無料ツール # マイコン移行判断ナビ 生産終了・NRND になったマイコンからの移行先を、**移行元のファミリから逆引き**できます。 移行先の候補だけでなく、**工数を押し上げる要因**まで先に把握できるようにしました。 移行するかどうかを判断する段階でお使いください。 個別型番の製品ステータスは掲載していません。生産終了・最終発注日などの最新情報は、 必ず各半導体メーカーの公式発表をご確認ください。本ツールは**移行の進め方を判断するため**のものです。 ## H8/300・H8/Tiny ルネサス（旧 日立） 8/16bit 主な採用領域：家電・小型機器・センサー制御 ### 移行先の候補 | 移行先 | 相性 | 選ぶ理由 | | [ルネサス RL78](https://technosphere.co.jp/blog/renesas-rl78-peripheral-guide) | ◎ | 同一ベンダーで低消費電力・低コスト。ルネサスがH8→RL78移行を推奨している | | [STM32（Arm）](https://technosphere.co.jp/blog/stm32-uart-i2c-can) | ○ | Arm資産・サードパーティ・調達性を重視する場合 | ### このファミリで工数を押し上げる要因 - **ソース・資料の欠落**ソースコード・ビルド環境・回路図・仕様書が揃わない。ROMだけが残る場合は逆アセンブルによる仕様復元が出発点になり、工数が大きく変わる。 - **ビッグエンディアン**現行の主要マイコンはリトルエンディアン。構造体をそのままバイト列として送受信・保存している実装では、移行後に値が壊れる。不揮発メモリの既存データとの互換が要る場合は変換層の設計が必要。 - **周辺機能が1対1で対応しない**タイマ・シリアル・A/D・割り込みコントローラの構成が現行品と異なる。同一ベンダー内でも読み替えが要る。 - **コンパイラ・アセンブリ依存**旧Cコンパイラ固有の #pragma（割り込み宣言・セクション配置）、組込み関数、アセンブリで書かれた部分は再実装になる。 詳しい解説： [H8/H8S 移行ガイド](https://technosphere.co.jp/blog/h8-h8s-migration-guide) ／ [H8マイコンとは](https://technosphere.co.jp/blog/what-is-h8-microcontroller) ## H8/300H ルネサス（旧 日立） 16/32bitコア（最大16MBリニア空間） 主な採用領域：産業機器・計測機器の定番 ### 移行先の候補 | 移行先 | 相性 | 選ぶ理由 | | [ルネサス RL78](https://technosphere.co.jp/blog/renesas-rl78-peripheral-guide) | ◎ | 小規模制御の置換。CS+/e² studio で開発環境を継承できる | | [ルネサス RX](https://technosphere.co.jp/blog/renesas-rx-introduction) | ○ | 性能に余裕を持たせたい場合 | | [STM32（Arm）](https://technosphere.co.jp/blog/stm32-uart-i2c-can) | ○ | Arm エコシステムを優先する場合 | ### このファミリで工数を押し上げる要因 - **ソース・資料の欠落**ソースコード・ビルド環境・回路図・仕様書が揃わない。ROMだけが残る場合は逆アセンブルによる仕様復元が出発点になり、工数が大きく変わる。 - **ビッグエンディアン**現行の主要マイコンはリトルエンディアン。構造体をそのままバイト列として送受信・保存している実装では、移行後に値が壊れる。不揮発メモリの既存データとの互換が要る場合は変換層の設計が必要。 - **周辺機能が1対1で対応しない**タイマ・シリアル・A/D・割り込みコントローラの構成が現行品と異なる。同一ベンダー内でも読み替えが要る。 - **コンパイラ・アセンブリ依存**旧Cコンパイラ固有の #pragma（割り込み宣言・セクション配置）、組込み関数、アセンブリで書かれた部分は再実装になる。 詳しい解説： [H8/H8S 移行ガイド](https://technosphere.co.jp/blog/h8-h8s-migration-guide) ## H8S/2000・H8S/2600・H8SX ルネサス（旧 日立） 16/32bit（H8SXは32bit拡張） 主な採用領域：OA機器・高機能制御・通信機器 ### 移行先の候補 | 移行先 | 相性 | 選ぶ理由 | | [ルネサス RX](https://technosphere.co.jp/blog/renesas-rx-introduction) | ◎ | 32bit性能で余裕を持って置換。SCI・MTU等の周辺の考え方が近い。e² studio で環境統一 | | [STM32（Arm）](https://technosphere.co.jp/blog/stm32-uart-i2c-can) | ○ | Arm資産・調達性を重視する場合 | ### このファミリで工数を押し上げる要因 - **ソース・資料の欠落**ソースコード・ビルド環境・回路図・仕様書が揃わない。ROMだけが残る場合は逆アセンブルによる仕様復元が出発点になり、工数が大きく変わる。 - **ビッグエンディアン**現行の主要マイコンはリトルエンディアン。構造体をそのままバイト列として送受信・保存している実装では、移行後に値が壊れる。不揮発メモリの既存データとの互換が要る場合は変換層の設計が必要。 - **周辺機能が1対1で対応しない**タイマ・シリアル・A/D・割り込みコントローラの構成が現行品と異なる。同一ベンダー内でも読み替えが要る。 - **コンパイラ・アセンブリ依存**旧Cコンパイラ固有の #pragma（割り込み宣言・セクション配置）、組込み関数、アセンブリで書かれた部分は再実装になる。 詳しい解説： [H8/H8S 移行ガイド](https://technosphere.co.jp/blog/h8-h8s-migration-guide) ## SuperH SH-1・SH-2・SH-2A ルネサス（旧 日立） 32bit RISC（16bit固定長命令） 主な採用領域：エンジンECU・産業制御・計測機器・モーター制御 ### 移行先の候補 | 移行先 | 相性 | 選ぶ理由 | | [ルネサス RX](https://technosphere.co.jp/blog/renesas-rx-introduction) | ◎ | 第一候補。SCIF→SCI、MTU2→MTU と周辺の対応関係が取りやすい。e² studio で環境継承 | | ルネサス RH850 | ○ | 車載制御で機能安全要求がある場合 | | [ルネサス RL78](https://technosphere.co.jp/blog/renesas-rl78-peripheral-guide) | ○ | SH-1/SH-2 の小規模制御をコストダウンしたい場合 | | [STM32（Arm）](https://technosphere.co.jp/blog/stm32-uart-i2c-can) | ○ | Arm エコシステム・調達性を重視する場合 | ### このファミリで工数を押し上げる要因 - **ソース・資料の欠落**ソースコード・ビルド環境・回路図・仕様書が揃わない。ROMだけが残る場合は逆アセンブルによる仕様復元が出発点になり、工数が大きく変わる。 - **ビッグエンディアン**現行の主要マイコンはリトルエンディアン。構造体をそのままバイト列として送受信・保存している実装では、移行後に値が壊れる。不揮発メモリの既存データとの互換が要る場合は変換層の設計が必要。 - **周辺機能が1対1で対応しない**タイマ・シリアル・A/D・割り込みコントローラの構成が現行品と異なる。同一ベンダー内でも読み替えが要る。 - **コンパイラ・アセンブリ依存**旧Cコンパイラ固有の #pragma（割り込み宣言・セクション配置）、組込み関数、アセンブリで書かれた部分は再実装になる。 詳しい解説： [SuperH 移行ガイド](https://technosphere.co.jp/blog/superh-sh-migration-guide) ## SuperH SH-3・SH-4 ルネサス（旧 日立） 32bit（MMU搭載） 主な採用領域：PDA・産業端末・マルチメディア・車載情報機器 ### 移行先の候補 | 移行先 | 相性 | 選ぶ理由 | | Arm Cortex-A 系 SoC | 要相談 | MMUを搭載し組込みLinux等のOSで動いている構成が多く、マイコンへの置換ではなくSoCの選定になる。個別にご相談ください | | [ルネサス RX](https://technosphere.co.jp/blog/renesas-rx-introduction) | △ | OSを使わない構成に作り替えられる場合に限る | ### このファミリで工数を押し上げる要因 - **ソース・資料の欠落**ソースコード・ビルド環境・回路図・仕様書が揃わない。ROMだけが残る場合は逆アセンブルによる仕様復元が出発点になり、工数が大きく変わる。 - **ビッグエンディアン**現行の主要マイコンはリトルエンディアン。構造体をそのままバイト列として送受信・保存している実装では、移行後に値が壊れる。不揮発メモリの既存データとの互換が要る場合は変換層の設計が必要。 - **周辺機能が1対1で対応しない**タイマ・シリアル・A/D・割り込みコントローラの構成が現行品と異なる。同一ベンダー内でも読み替えが要る。 - **コンパイラ・アセンブリ依存**旧Cコンパイラ固有の #pragma（割り込み宣言・セクション配置）、組込み関数、アセンブリで書かれた部分は再実装になる。 - **OS前提の構成**MMUを持ちOS（組込みLinux等）で動いている場合、マイコンへの置換ではなくSoCの選定になる。移行の性質そのものが変わるため個別に判断が要る。 詳しい解説： [SuperH 移行ガイド](https://technosphere.co.jp/blog/superh-sh-migration-guide) ## 8051（MCS-51） Intel系（現在は多社が互換コアを供給） 8bit（ハーバード型） 主な採用領域：家電・小型機器。ビット操作命令とSFRが豊富 ### 移行先の候補 | 移行先 | 相性 | 選ぶ理由 | | [STM32（Arm）](https://technosphere.co.jp/blog/stm32-uart-i2c-can) | ◎ | 豊富な内蔵周辺で外付けICを集約できる。情報量・調達性に優れる | | [ルネサス RL78](https://technosphere.co.jp/blog/renesas-rl78-peripheral-guide) | ◎ | 8bit/16bitクラスの置換に最適。国内量産向け | | 8051互換コア | △ | Silicon Labs 等の互換コアでコア互換のまま延命。ただし長期的には現行アーキへの移行が安全 | ### このファミリで工数を押し上げる要因 - **ソース・資料の欠落**ソースコード・ビルド環境・回路図・仕様書が揃わない。ROMだけが残る場合は逆アセンブルによる仕様復元が出発点になり、工数が大きく変わる。 - **周辺機能が1対1で対応しない**タイマ・シリアル・A/D・割り込みコントローラの構成が現行品と異なる。同一ベンダー内でも読み替えが要る。 - **コンパイラ・アセンブリ依存**旧Cコンパイラ固有の #pragma（割り込み宣言・セクション配置）、組込み関数、アセンブリで書かれた部分は再実装になる。 詳しい解説： [8051/Z80 移行ガイド](https://technosphere.co.jp/blog/8051-z80-legacy-migration-guide) ## Z80 Zilog（オリジナルは終息が進行） 8bit（ノイマン型） 主な採用領域：産業機器・制御装置。CP/M資産 ### 移行先の候補 | 移行先 | 相性 | 選ぶ理由 | | [STM32（Arm）](https://technosphere.co.jp/blog/stm32-uart-i2c-can) | ◎ | 内蔵周辺で外付けICを集約。情報量・調達性に優れる | | [ルネサス RL78](https://technosphere.co.jp/blog/renesas-rl78-peripheral-guide) | ◎ | 小規模・低コスト・国内量産向け | ### このファミリで工数を押し上げる要因 - **ソース・資料の欠落**ソースコード・ビルド環境・回路図・仕様書が揃わない。ROMだけが残る場合は逆アセンブルによる仕様復元が出発点になり、工数が大きく変わる。 - **周辺機能が1対1で対応しない**タイマ・シリアル・A/D・割り込みコントローラの構成が現行品と異なる。同一ベンダー内でも読み替えが要る。 - **コンパイラ・アセンブリ依存**旧Cコンパイラ固有の #pragma（割り込み宣言・セクション配置）、組込み関数、アセンブリで書かれた部分は再実装になる。 詳しい解説： [8051/Z80 移行ガイド](https://technosphere.co.jp/blog/8051-z80-legacy-migration-guide) ## 東芝 TLCS-870 / TLCS-90 東芝 東芝独自 8bit 主な採用領域：家電・小型機器の制御。大量採用された定番 ### 移行先の候補 | 移行先 | 相性 | 選ぶ理由 | | [STM32（Arm）](https://technosphere.co.jp/blog/stm32-uart-i2c-can) | ◎ | 情報量・サードパーティ資産・調達性に優れる | | [ルネサス RL78](https://technosphere.co.jp/blog/renesas-rl78-peripheral-guide) | ○ | 小規模制御を低コストで置換。国内量産向け | | 東芝 TXZ（Arm） | ○ | 東芝デバイスで揃えたい場合。Arm Cortex-M で現代的な開発ができる | ### このファミリで工数を押し上げる要因 - **ソース・資料の欠落**ソースコード・ビルド環境・回路図・仕様書が揃わない。ROMだけが残る場合は逆アセンブルによる仕様復元が出発点になり、工数が大きく変わる。 - **周辺機能が1対1で対応しない**タイマ・シリアル・A/D・割り込みコントローラの構成が現行品と異なる。同一ベンダー内でも読み替えが要る。 - **コンパイラ・アセンブリ依存**旧Cコンパイラ固有の #pragma（割り込み宣言・セクション配置）、組込み関数、アセンブリで書かれた部分は再実装になる。 詳しい解説： [東芝マイコン 移行ガイド](https://technosphere.co.jp/blog/toshiba-mcu-migration-guide) ## 東芝 TLCS-900 / 900H / 900L 東芝 東芝独自 16/32bit 主な採用領域：OA機器・産業機器・高機能制御 ### 移行先の候補 | 移行先 | 相性 | 選ぶ理由 | | [STM32（Arm）](https://technosphere.co.jp/blog/stm32-uart-i2c-can) | ◎ | 情報量・調達性に優れる | | [ルネサス RX](https://technosphere.co.jp/blog/renesas-rx-introduction) | ○ | 16/32bitクラスの高機能制御の置換に | | 東芝 TXZ（Arm） | ○ | 東芝デバイスで揃えたい場合 | ### このファミリで工数を押し上げる要因 - **ソース・資料の欠落**ソースコード・ビルド環境・回路図・仕様書が揃わない。ROMだけが残る場合は逆アセンブルによる仕様復元が出発点になり、工数が大きく変わる。 - **周辺機能が1対1で対応しない**タイマ・シリアル・A/D・割り込みコントローラの構成が現行品と異なる。同一ベンダー内でも読み替えが要る。 - **コンパイラ・アセンブリ依存**旧Cコンパイラ固有の #pragma（割り込み宣言・セクション配置）、組込み関数、アセンブリで書かれた部分は再実装になる。 詳しい解説： [東芝マイコン 移行ガイド](https://technosphere.co.jp/blog/toshiba-mcu-migration-guide) ## 東芝 TX03 / TX04（TMPM） 東芝 Arm Cortex-M3 / M4 主な採用領域：Arm移行世代 ### 移行先の候補 | 移行先 | 相性 | 選ぶ理由 | | 東芝 TXZ（Arm） | ○ | 同一ベンダーの現行ファミリ。移行の連続性を優先する場合 | | [STM32（Arm）](https://technosphere.co.jp/blog/stm32-uart-i2c-can) | ◎ | 同じArm Cortex-Mのため移植性が高く、調達性・情報量に優れる | ### このファミリで工数を押し上げる要因 - **ソース・資料の欠落**ソースコード・ビルド環境・回路図・仕様書が揃わない。ROMだけが残る場合は逆アセンブルによる仕様復元が出発点になり、工数が大きく変わる。 - **周辺機能が1対1で対応しない**タイマ・シリアル・A/D・割り込みコントローラの構成が現行品と異なる。同一ベンダー内でも読み替えが要る。 詳しい解説： [東芝マイコン 移行ガイド](https://technosphere.co.jp/blog/toshiba-mcu-migration-guide) ## 移行プロジェクトの進め方 移行先が決まっても、いきなり全体を作り替えないでください。標準的な進め方は次のとおりです。 1. **現状調査**：残存資産（ソース・プロジェクト・ROM・回路図・実機）の棚卸し 2. **仕様復元**：ソース解析、またはROMの逆アセンブルと実機動作解析による仕様化 3. **移行先選定**：性能・周辺・調達性から現行マイコンを選定 4. **ハード設計**：基板リプレース（端子・電圧・周辺の対応付け） 5. **ソフト移植**：周辺ドライバ置換、エンディアン・アセンブリの再実装 6. **等価性検証**：旧機と新機の入出力・タイミングを突き合わせて検証 7. **量産移行**：信頼性試験を経て量産へ まず現状調査と一部機能の PoC を行い、復元できる範囲と実際の工数を把握してから本格移行に進むのが安全です。 特にソースが不完全な案件では、この段階で見積りが数倍変わります。 ## 移行の可否と工数を、実機と資料から見立てます 「在庫はあるが開発環境が最新OSで動かない」「当時の担当者が退職してソースが残っていない」 といった状態からのご相談を多くいただいています。ROMしか残っていない場合の逆アセンブルによる 仕様復元にも対応しています。大阪市淀川区（新大阪駅近く）の受託開発会社です。 [移行について相談する](https://technosphere.co.jp/contact) [組込み開発の対応内容を見る](https://technosphere.co.jp/embedded) --- # 年末年始休業のお知らせ | 株式会社テクノスフィア > 株式会社テクノスフィアの年末年始休業期間のご案内です。2025年12月26日12:00〜2026年1月4日まで休業いたします。 URL: https://technosphere.co.jp/new-year-2025 🎍 🎌 🧧 🎐 🎍🐴🎍 # 年末年始休業のお知らせ 2025年も大変お世話になりました。 誠に勝手ながら、下記期間を休業とさせていただきます。 🎉 2026年まであと... -- 日 -- 時間 -- 分 -- 秒 ## 休業期間 休業期間 2025年12月26日(金) 12:00 〜 2026年1月4日(日) ** 最終営業日 2025年12月26日(金) 12:00まで ** 営業開始日 2026年1月5日(月) 通常営業 ### 🐴 午年の抱負（スタッフの声） - 🍜 年越しそばは何杯までOKか検証する - 📺 紅白を最後まで起きて見届ける（多分無理） - 🏃 初詣の行列で足腰を鍛える - 🎮 積みゲーを1本はクリアする - 💻 休み明けにGitのパスワードを忘れない ** 休業期間中のお問い合わせは **[お問い合わせフォーム](https://technosphere.co.jp/contact)** よりご連絡ください。 ※1月5日以降、順次ご対応いたします [トップページへ戻る](https://technosphere.co.jp/) --- # DX（業務デジタル化）お困りごと診断｜株式会社テクノスフィア > 当社はAI、組み込み系、Web、インフラ、ホームページ等、IT関連であれば基本すべて対応可能となります。貴社のお困りごとを選択いただければ、そちらに必要なご提案を致します。 URL: https://technosphere.co.jp/okomarigoto # DX（業務デジタル化） お困りごと診断 当社はAI、組み込み系、Web、インフラ、 ホームページ等、IT関連であれば基本すべて対応可能となります。 貴社のお困りごとを選択いただければ、 そちらに必要なご提案を致します。 [お問い合わせはこちら](https://technosphere.co.jp/contact) ## STEP 1 貴社事業の業種をお選びください。 ### [製造業](https://technosphere.co.jp/okomarigoto/manufacturing) ### [建設業](https://technosphere.co.jp/okomarigoto/construction) ### [卸売・小売業](https://technosphere.co.jp/okomarigoto/retail) ### [サービス業](https://technosphere.co.jp/okomarigoto/service) ### [医療・福祉](https://technosphere.co.jp/okomarigoto/medical) ### [官公庁](https://technosphere.co.jp/okomarigoto/government) ### [教育機関](https://technosphere.co.jp/okomarigoto/education) ### [IT・情報通信業](https://technosphere.co.jp/okomarigoto/it) Page Top --- # 建設業の課題解決｜株式会社テクノスフィア > 建設業における現場写真管理、安全管理、図面管理などの課題をデジタル化で解決。クラウドシステムで業務効率化を実現します。 URL: https://technosphere.co.jp/okomarigoto/construction # 建設業 ## 課題に関して、弊社対応解決策 [別の業種を選択](https://technosphere.co.jp/okomarigoto) 現場写真の管理が煩雑で、必要な写真を探すのに時間がかかる ### 解決策 クラウド写真管理システム ＋AI自動タグ付け ** 図面：イラスト 現場写真をクラウドで一元管理し、AIが自動で分類・タグ付け。 スマホアプリから直接クラウドにアップロード AIが工程・場所・内容を自動認識してタグ付け 電子小黒板連携で撮影情報を自動記録 キーワード検索で必要な写真を即座に発見 工事写真帳の自動作成機能 国土交通省の電子納品要領に準拠 #### 導入効果 - 写真整理時間を80%削減 - 監督者の残業時間削減 - 電子納品対応の簡素化 ### 建設業の他の課題を選択 ### 詳しく確認したい場合は 下記お問い合わせフォームからご連絡お願い致します。 #### お問い合わせ --- # 教育機関の課題解決｜株式会社テクノスフィア > 教育機関におけるオンライン学習、成績管理、保護者連絡をデジタル化。オンライン学習プラットフォーム、校務支援システム、保護者連絡システムで教育現場の効率化を実現します。 URL: https://technosphere.co.jp/okomarigoto/education # 教育機関 ## 課題に関して、弊社対応解決策 [別の業種を選択](https://technosphere.co.jp/okomarigoto) オンライン授業の環境が整っていない ### 解決策 オンライン学習プラットフォーム ＋学習管理システム ##### 現状の課題 環境未整備 ** ##### 解決後 ハイブリッド学習 オンライン授業と対面授業を組み合わせた効果的な学習環境。 ライブ配信・録画配信 課題の配布・提出管理 小テスト・アンケート機能 出欠管理 成績管理 保護者との情報共有 #### 導入効果 - 授業の柔軟性向上 - 欠席者のフォロー充実 - 教材準備時間30%削減 ### 教育機関の他の課題を選択 ### 詳しく確認したい場合は 下記お問い合わせフォームからご連絡お願い致します。 #### お問い合わせ --- # 官公庁・自治体の課題解決｜株式会社テクノスフィア > 官公庁・自治体における申請書類処理、住民サービス、施設管理をデジタル化。電子申請システム、情報配信プラットフォーム、防災情報システムで行政DXを実現します。 URL: https://technosphere.co.jp/okomarigoto/government # 官公庁・自治体 ## 課題に関して、弊社対応解決策 [別の業種を選択](https://technosphere.co.jp/okomarigoto) 申請書類の処理に時間がかかる ### 解決策 電子申請システム ＋AI-OCR処理 ##### 現状の課題 紙書類の手作業処理 ** ##### 解決後 電子申請＋AI処理 オンライン申請とAI-OCRで、書類処理を自動化。 オンライン申請フォーム AI-OCRによる紙書類のデジタル化 申請状況のリアルタイム確認 自動審査機能 電子決裁システム連携 マイナンバーカード認証 #### 導入効果 - 処理時間70%削減 - 市民の来庁不要 - ペーパーレス化推進 ### 官公庁・自治体の他の課題を選択 ### 詳しく確認したい場合は 下記お問い合わせフォームからご連絡お願い致します。 #### お問い合わせ --- # 業界別お困りごと解決事例 | 株式会社テクノスフィア > 製造業、小売業、医療・介護、建設業など、各業界のお困りごとに対する解決策をご提案します。 URL: https://technosphere.co.jp/okomarigoto/ # 業界別お困りごと解決事例｜業種を選んで最適なDX施策を見つける 1 業種選択 2 課題選択 3 解決策 4 お問い合わせ ## まず、あなたの業種を選択してください ** ### 製造業 工場・生産現場向け ** ### 小売・流通業 店舗・EC向け ** ### 医療・介護 病院・介護施設向け ** ### 建設業 建設現場向け ** ### IT・情報通信 IT企業向け ** ### サービス業 各種サービス業向け ** ### 教育 学校・教育機関向け ** ### 官公庁・自治体 公共機関向け ## どのようなお困りごとがありますか？ ### 解決策 ** 図面：イラスト #### 導入効果 ## お問い合わせ ### 選択内容の確認 **業種：** **課題：** **解決策：** 以下のフォームよりお問い合わせください。専門スタッフが詳しくご説明いたします。 [お問い合わせフォームへ](https://technosphere.co.jp/contact) --- # IT・テクノロジーの課題解決｜株式会社テクノスフィア > IT・テクノロジー業界におけるプロジェクト管理、開発環境、セキュリティをデジタル化。プロジェクト管理ツール、クラウド開発環境、セキュリティ統合管理で開発効率化を実現します。 URL: https://technosphere.co.jp/okomarigoto/it # IT・テクノロジー ## 課題に関して、弊社対応解決策 [別の業種を選択](https://technosphere.co.jp/okomarigoto) プロジェクト管理が属人的 ### 解決策 プロジェクト管理ツール ＋自動レポート生成 ##### 現状の課題 属人的管理 ** ##### 解決後 システム化管理 タスクと進捗を可視化し、プロジェクトを効率的に管理。 ガントチャート・カンバン表示 タスクの自動割り当て 工数管理・予実管理 リソース管理 リスク管理 レポートの自動生成 #### 導入効果 - プロジェクト遅延30%削減 - 管理工数50%削減 - 収益性向上 ### IT・テクノロジーの他の課題を選択 ### 詳しく確認したい場合は 下記お問い合わせフォームからご連絡お願い致します。 #### お問い合わせ --- # 製造業の課題解決｜株式会社テクノスフィア > 製造業における品質記録・作業実績の紙管理やExcel管理をデジタル化。タブレット入力＋クラウド共有システムで業務効率化を実現します。 URL: https://technosphere.co.jp/okomarigoto/manufacturing # 製造業 ## 課題に関して、弊社対応解決策 [別の業種を選択](https://technosphere.co.jp/okomarigoto) お困りごと・課題記録・作業実績が紙やExcelで管理されている ### 解決策 タブレット入力＋クラウド共有システム導入 （現場・本社間リアルタイム連携） ##### 現状の課題 紙やExcelでの管理 ** ##### 解決後 クラウド連携システム タブレットやPCから入力できる クラウド品質管理システムを構築。 バーコード／QRコード連携で記録ミス削減。 記録データはリアルタイムで本社に反映。 作業者がタブレットで検査結果や作業実績を入力 入力データはWi-Fi経由でクラウドDBへ即反映 品質データを自動集計し、グラフやトレンド分析を表示 検索機能で過去記録を瞬時に参照 #### 導入効果 - 記録ミス削減（転記作業ゼロ） - 品質異常の早期発見 - 記録の提出・監査対応が短時間で可能 ### 製造業の他の課題を選択 ### 詳しく確認したい場合は 下記お問い合わせフォームからご連絡お願い致します。 #### お問い合わせ --- # 医療・介護の課題解決｜株式会社テクノスフィア > 医療・介護における診療予約、電子カルテ、在庫管理、レセプト業務をデジタル化。Web予約システム、電子カルテシステム、AIレセプトチェックで業務効率化を実現します。 URL: https://technosphere.co.jp/okomarigoto/medical # 医療・介護 ## 課題に関して、弊社対応解決策 [別の業種を選択](https://technosphere.co.jp/okomarigoto) 診療予約の電話対応に時間を取られる ### 解決策 Web予約システム ＋順番待ち表示 ##### 現状の課題 電話対応に追われる ** ##### 解決後 自動予約＋順番管理 オンライン予約と待ち時間表示で、患者様の利便性向上。 24時間Web予約受付 リアルタイム待ち時間表示 診療科別の予約管理 予約リマインドメール 問診票の事前入力 キャンセル待ち自動案内 #### 導入効果 - 電話対応70%削減 - 待ち時間クレーム減少 - 予約率30%向上 ### 医療・介護の他の課題を選択 ### 詳しく確認したい場合は 下記お問い合わせフォームからご連絡お願い致します。 #### お問い合わせ --- # 小売業の課題解決｜株式会社テクノスフィア > 小売業における在庫管理、顧客データ活用、レジ業務効率化をデジタル化。AI需要予測＋自動発注、CRMシステム、キャッシュレス決済で業務効率化を実現します。 URL: https://technosphere.co.jp/okomarigoto/retail # 小売業 ## 課題に関して、弊社対応解決策 [別の業種を選択](https://technosphere.co.jp/okomarigoto) 在庫管理が煩雑で、欠品や過剰在庫が発生 ### 解決策 AI需要予測システム ＋自動発注機能 ##### 現状の課題 煩雑な在庫管理 ** ##### 解決後 AI予測＋自動発注 AIが売上データから需要を予測し、適正在庫を維持。 POSデータと連動した在庫管理 AIによる需要予測で発注量を最適化 季節変動や天候を考慮した予測 自動発注で発注業務を効率化 複数店舗の在庫を一元管理 賞味期限管理とアラート機能 #### 導入効果 - 欠品率50%削減 - 廃棄ロス30%削減 - 発注業務時間60%削減 ### 小売業の他の課題を選択 ### 詳しく確認したい場合は 下記お問い合わせフォームからご連絡お願い致します。 #### お問い合わせ --- # サービス業の課題解決｜株式会社テクノスフィア > サービス業における予約管理、顧客管理、決済業務をデジタル化。オンライン予約システム、CRM、キャッシュレス決済、デジタルマーケティングで業務効率化を実現します。 URL: https://technosphere.co.jp/okomarigoto/service # サービス業 ## 課題に関して、弊社対応解決策 [別の業種を選択](https://technosphere.co.jp/okomarigoto) 予約管理が煩雑で、ダブルブッキングが発生 ### 解決策 オンライン予約システム ＋自動リマインド機能 ##### 現状の課題 煩雑な予約管理 ** ##### 解決後 自動予約管理 24時間オンライン予約受付で、予約管理を自動化。 Web・アプリからの24時間予約受付 リアルタイムの空き状況表示 予約確認メール・SMS自動送信 キャンセル待ち機能 顧客カルテとの連携 Google/LINEカレンダー連携 #### 導入効果 - 電話対応時間70%削減 - no-show率50%削減 - 予約数20%増加 ### サービス業の他の課題を選択 ### 詳しく確認したい場合は 下記お問い合わせフォームからご連絡お願い致します。 #### お問い合わせ --- # の課題解決｜株式会社テクノスフィア > における様々な課題をデジタル化で解決。クラウドシステムとAI技術で業務効率化を実現します。 URL: https://technosphere.co.jp/okomarigoto/template # ## 課題に関して、弊社対応解決策 [別の業種を選択](https://technosphere.co.jp/okomarigoto) ### 解決策 ** 図面：イラスト #### 導入効果 ### の他の課題を選択 ### 詳しく確認したい場合は 下記お問い合わせフォームからご連絡お願い致します。 #### お問い合わせ --- # 業種別課題イメージ URL: https://technosphere.co.jp/okomarigoto/visual-demo # 各業種の課題イメージビジュアル ## 製造業の課題 品質記録の紙管理 紙やExcelでの管理による転記ミスや検索の非効率 工場・本社間の連携不足 リアルタイムな情報共有ができない 設備の突発故障 予知保全ができず事後対応になる ## 建設業の課題 現場写真の管理 大量の写真から必要なものを探すのが困難 安全管理書類 書類作成と管理に時間がかかる 図面の最新版管理 最新版の共有と管理が煩雑 ## 卸売・小売業の課題 在庫管理 欠品や過剰在庫が発生 顧客データ活用 購買データが活用できていない レジ業務の煩雑さ お客様を待たせてしまう ## サービス業の課題 予約管理 ダブルブッキングが発生 顧客管理 紙やExcelでの非効率な管理 集客方法 効果的な集客ができない ## 医療・福祉の課題 診療予約の電話対応 電話対応に時間を取られる カルテ管理 紙カルテの検索に時間がかかる 医薬品在庫管理 期限管理や発注が大変 ## 官公庁の課題 申請書類処理 書類処理に時間がかかる 住民への情報発信 効果的な情報伝達ができない 施設予約管理 公共施設の予約が煩雑 ## 教育機関の課題 オンライン授業環境 環境が整っていない 成績管理 評価や集計に時間がかかる 保護者連絡 紙ベースで非効率 ## IT・情報通信業の課題 プロジェクト管理 属人的な管理体制 開発環境構築 環境構築に時間がかかる セキュリティ対策 脅威への対応が不十分 --- # プライバシーポリシー｜株式会社テクノスフィア > 株式会社テクノスフィアのプライバシーポリシー。お客様の個人情報の取扱い、利用目的、開示・訂正・削除のご請求方法について明示しています。 URL: https://technosphere.co.jp/privacy # PRIVACY POLICY ## プライバシーポリシーについて 株式会社テクノスフィア（以下「当社」とします）またはその代理⼈が管理・運営するこのWebサイトにおけるプライバシーポリシーを次のとおり定め、皆様の個⼈情報を取り扱い、皆様に安⼼してご利⽤いただけるよう、このWebサイトの管理・運営に努めます。 当社は、このWebサイトを通じて皆様の個⼈情報をご提供いただいたときは、これを本プライバシーポリシーに従って取り扱います。 但し、個⼈情報をご提供いただく特定のウェブページにおいて、本プライバシーポリシーと異なる定めをした場合には、本プライバシーポリシーに優先して適⽤されるものとします。 ■個⼈情報の取り扱い 株式会社テクノスフィア（以下「当社」とします）またはその代理⼈が管理・運営するこのWebサイトにおけるプライバシーポリシーを次のとおり定め、皆様の個⼈情報を取り扱い、皆様に安⼼してご利⽤いただけるよう、このWebサイトの管理・運営に努めます。 当社は、このWebサイトを通じて皆様の個⼈情報をご提供いただいたときは、これを本プライバシーポリシーに従って取り扱います。 但し、個⼈情報をご提供いただく特定のウェブページにおいて、本プライバシーポリシーと異なる定めをした場合には、本プライバシーポリシーに優先して適⽤されるものとします。 ■個⼈情報の取得 当社は個人情報の入手を適法かつ公正な手段によって行い個人の意思に反する不正な方法により入手いたしません。 当社は個人情報を間接的に入手する場合には、入手する個人情報について提供者が本人から適正に入手したものであるかどうか確認します。 ■個⼈情報の管理 当社は、お客様からご提供いただいた情報の管理について、以下を徹底します。 1. 情報の正確性の確保 お客様からご提供いただいた情報については、常に正確かつ最新の情報となるように努めます。 2. 安全管理措置 当社は、組織的な個人情報の管理については、社内規定による厳重に取扱い方法を規定し、それに基づいた取扱いを徹底します。 3. 従業者の監督 当社は、当社の規定に基づき、個人情報取扱い規程の厳格な運用を徹底しています。 4. 委託先の監督 個人情報の取扱いを外部に委託する場合には、当社の規定に基づき、用件を満たした委託先にのみ委託を行い、適切な管理を行います。 5. 保存期間と破棄 お客様からご提案いただいた情報については、保存期間を設定し、保存期間終了後は破棄します。また、保存期間内であっても、不要となった場合はすみやかに破棄します。 ■個⼈情報の第三者提供 以下の場合を除き、個⼈情報を第三者に提供することはいたしません。 - お客様の同意が得られている場合 - 法令などに基づく場合（警察・裁判所などからの要求や、当社と第三者との合併・営業譲渡などが⽣じた場合の存続会社・譲渡先などへの開⽰） - ⼈の⽣命・⾝体・財産の保護のために必要な場合で、ご本⼈の同意を得ることが困難な場合や緊急を要する場合 - 当社業務委託先へ業務を委託する場合（この場合、次項の「個⼈情報の預託」に従います） - お客様が当社のWebサイトに掲出した情報により、著作権や知的所有権などの侵害のおそれが⽣じ、権利者からの照会に対し開⽰する場合 - 皆様から個⼈情報をご提供いただく際には、特定のウェブページに、その管理元を予め明⽰いたします。管理元は、ご提供いただいた個⼈情報を厳重に保管・管理し、第三者の不正なアクセスによる個⼈情報の漏洩・流⽤・改ざんなどを防⽌するため、万全のセキュリティ対策を講じるものとします。 ■個⼈情報の開⽰・訂正・削除について ご提供いただいた個⼈情報の内容に関して、開⽰／訂正／削除等を希望される場合は、管理元にご請求ください。 ご請求いただいた⽅がお客様ご本⼈であることを確認した後、合理的な期間内に、お客様の個⼈情報を開⽰、訂正または削除いたします。 ■クッキー（Cookie）について アクセスログ解析などの目的によるクッキーよばれる技術を使用しています。クッキーだけでは個人を特定することはできません。またクッキーの受信を拒否するように自分のブラウザを設定することもできます。 ■当社へのお問合せ 皆様がご提供された個⼈情報の取り扱いについてのお問合せや、本プライバシーポリシーに関するお問い合わせにつきましては、下記メールアドレスもしくは当サイトのコンタクトフォームからご連絡ください。 ただし、直ちに対応できない場合がございますので、予めご了承ください。 https://technosphere.co.jp/contact ## 個人情報取得・利用同意書 株式会社テクノスフィア（（以下「当社」という。）は、当社業務遂行のため皆様から個人情報を取得するにあたり以下1～7の事項を告知し同意を求めます。取得した個人情報は以下の目的のみに使用し、事前にご本人の同意なく目的以外に利用はいたしません。（法令などに基づく場合を除く） 1.事業所の名称 株式会社テクノスフィア 2.個人情報保護管理者の職名、所属及び連絡先 個人情報保護管理者の職名・所属及び連絡先は、以下の通りです。 個人情報保護管理者の職名：取締役個人 情報保護管理者の連絡先：[お問い合わせフォーム](https://technosphere.co.jp/contact) 3.個人情報とその利用目的 個人情報：氏名、住所、電話番号、メールアドレスなど 利用目的：電話及び電子メールその他の方法による問い合わせ対応、事務手続き等を行うため。 4.個人情報の取り扱いの委託予定 なし 5.開示対象個人情報に該当する場合の請求及び問い合わせ窓口 皆様ご自身の個人情報について、当該本人が識別される開示対象個人情報に該当する場合には、ご本人様は、開示など（利用目的の通知、開示、内容の訂正、追加または削除,利用の停止、消去及び第三者への提供の停止の求め）を要求することができます。 問い合わせ窓口は下記となります。 株式会社 テクノスフィア URL：https://technosphere.co.jp/contact 6.本人が情報を与えることの任意性及び当該情報を与えなかった場合に本人に生じる結果 当該個人情報の提出は任意ですが、当該情報を与えない場合はお問合せの対応ができません。 7.本人が容易に認識できない方法による個人情報の取得 現在、この方式での取得の予定はありません。 --- # 採用情報｜AI・組込み・Web開発エンジニア募集｜株式会社テクノスフィア > 大阪・新大阪のAI×組込みシステム開発企業テクノスフィアでエンジニア募集中。画像認識AI・RAGチャットボット・マイコン開発など最先端技術に携われます。リモートワーク可、ペアプログラミング文化、充実の福利厚生。未経験からベテランまで歓迎。 URL: https://technosphere.co.jp/recruit [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [採用情報](https://technosphere.co.jp/recruit) CAREER AT TECHNOSPHERE # テクノロジーで、 未来を共につくろう。 AIが世界を変えつつある今、私たちは最前線で技術に挑んでいます。 新卒・第二新卒・中途採用——キャリアの出発点は問いません。 あなたの「やりたい」が、ここで形になる。 募集職種を見る [採用サイトへ](https://en-gage.net/technosphere_saiyo/) ** 新卒採用 ** 中途採用 ** 第二新卒 NUMBERS ## 数字で見るテクノスフィア ** 0年連続 増収増益達成 着実な成長を続けています ** 0歳 平均年齢 若くフラットな組織です ** 0領域 技術フィールド AI / Web / 組込み ** 0% 研修費用負担 全額会社負担で学べます " MESSAGE ## 採用担当からのメッセージ テクノスフィアは、生成AI・画像認識・組込みシステムという最前線の技術で、 お客様の課題を解決し続けている大阪のIT企業です。 私たちが大切にしているのは、**「技術力」と「人柄」**。 派手なスキルよりも、好奇心と誠実さを持つ人が活躍できる職場です。 新卒でも中途でも——あなたの経験・スタイルを尊重しながら一緒に成長できます。 4年連続増収増益。それは偶然ではなく、チーム全員が挑戦し続けた結果です。 次の未来を、あなたと一緒に作りたい。 株式会社テクノスフィア 採用チーム一同 WHY TECHNOSPHERE ## テクノスフィアを選ぶ4つの理由 （図: AIコードをペアプログラミングする若手エンジニア） 01 ** ### 最先端AIに、 日常から触れられる 生成AI・RAGチャットボット・エッジAI・画像認識—— 「話題の技術」がここでは当たり前。 ニュースで見た技術を、翌週には業務で使うのが私たちの日常です。 - 生成AI - RAG - 画像認識 - IoT （図: 中途入社者のオンボーディングシーン） 02 ** ### キャリアの スタート地点は問わない 新卒・第二新卒・中途採用——すべての方を積極採用中です。 「他業界から転職したい」「未経験の分野に挑戦したい」という方も大歓迎。 あなたのバックグラウンドが、チームの多様性になります。 - 新卒歓迎 - 中途歓迎 - 第二新卒歓迎 03 ** ### 成長企業で、 あなたの市場価値が上がる 4年連続増収増益のリアルな成長企業。 売上規模だけでなく、扱う技術領域も年々拡大。 会社が成長するほど、あなたのキャリアも加速します。 - 4年連続増収増益 - 事業拡大中 04 ** ### フラットで動きやすい、 少数精鋭のチーム 平均年齢32歳の若いメンバーで構成。 無駄な階層がなく、アイデアはすぐ実行に移せます。 「こうしたい」を言いやすい、心理的安全性の高い職場です。 - フラットな組織 - 少数精鋭 - 風通しの良さ （図: チームでのブレインストーミング） チームで課題解決 （図: ペアプログラミング） 日常のペアプロ （図: エンジニアの成長） 自分のペースで成長 （図: オンボーディング） 手厚いオンボーディング （図: ランチタイム） アットホームな雰囲気 CAREER PATH ## あなたのキャリアパスをイメージしよう 入社〜6ヶ月 #### オンボーディング期間 研修プログラムで基礎をしっかり固めます。先輩エンジニアによるメンター制度あり。プログラミング基礎・開発フロー・チーム文化を学びます。 6ヶ月〜1年 #### 実務デビュー 少人数チームに参加し、実際のプロジェクトで開発を担当。先輩と一緒にコードレビューを受けながら実力を磨きます。 1年〜3年 #### 独り立ち・専門化 担当領域を持ち自律的に開発を進める段階。AI・組込み・Webなど自分の得意分野を深堀りしてスペシャリストへ。 3年以降 #### リード・リーダーシップ プロジェクトリードや後輩指導へ。技術的成長だけでなく、ビジネス視点・マネジメントスキルも身につきます。 入社〜3ヶ月 #### キャッチアップ期間 会社の開発スタイル・技術スタック・チーム文化を把握。前職の経験を活かしながら、テクノスフィア流を習得します。 3ヶ月〜1年 #### 即戦力として活躍 前職のスキルをフル活用。チームにとって頼れる存在として、プロジェクトの中核メンバーを目指します。 1年以降 #### 新領域へのチャレンジ 既存スキルを軸に、AIや組込みなど新しい技術領域へ横展開。技術の掛け合わせが、ユニークなキャリアを生み出します。 中長期 #### チームリード・マネジメント プロジェクトマネージャー・テックリードなど、リーダーポジションへ。会社の成長と共にポジションも拡大中。 OPEN POSITIONS ## 募集職種 新卒・第二新卒・中途採用、すべての方を積極募集中 ** ### WEB系・オープン系・ AI系エンジニア 新卒OK 中途OK 第二新卒OK 正社員 #### 仕事内容 - Webアプリケーション開発（PHP / Python / JavaScript等） - AI・機械学習システムの開発（画像認識・自然言語処理等） - RAGチャットボットの設計・開発・実装 - データベース設計・クラウドインフラ構築 - システムの保守・運用・改善提案 #### 応募条件 - プログラミング経験（言語・年数不問） - チームで協力しながら仕事ができる方 - 新しい技術に好奇心を持てる方 #### あると嬉しいスキル - Python・PHP・JavaScriptの実務経験 - AI・機械学習の知識・経験 - AWS・Azureなどクラウドサービスの経験 - アジャイル開発・スクラムの経験 ** 「ChatGPTを超える自社AIを作りたい」そんな野心を持つ方、大歓迎です。 [この職種に応募する](https://en-gage.net/technosphere_saiyo/) ** ### 組込・制御系 エンジニア 新卒OK 中途OK 第二新卒OK 正社員 #### 仕事内容 - 組込みシステムの設計・開発 - マイコン制御プログラムの開発 - IoTデバイスの開発・実装 - ファームウェアの開発・デバッグ - ハードウェアとソフトウェアの統合テスト #### 応募条件 - C/C++でのプログラミング経験 - 電気・電子工学の基礎知識 - 粘り強く問題を解決できる方 #### あると嬉しいスキル - 組込みLinux・RTOSの経験 - 各種通信プロトコル（I2C・SPI・UART等）の知識 - 回路図の読解・設計経験 - AIとハードウェアの融合（エッジAI）への興味 ** ハードウェアとAIの融合領域は急成長中。最前線で挑戦できます。 [この職種に応募する](https://en-gage.net/technosphere_saiyo/) IDEAL PERSON ## こんな人と働きたい ** ### 好奇心が旺盛な方 「これ、どうなってるんだろう？」と思わず調べてしまう。そのエネルギーがAI時代の最大の武器です。 ** ### 素直に発信できる方 経験年数に関わらず、気づいたことを言える方。フラットな組織では、その声が一番大切です。 ** ### 行動が早い方 「まずやってみる」精神の持ち主。完璧より速さを重視し、失敗から学んで前進できる方。 ** ### チームを大切にできる方 個人プレーより協力プレーが好き。仲間の成功を自分の喜びとして感じられる方を歓迎します。 （図: 社員のランチ・リフレッシュタイム） ### オンとオフのバランスが大事 仕事もプライベートも充実させてほしい。 フレキシブルな働き方と、笑顔あふれるオフィス文化があります。 （図: エンジニアが成長する環境） 自分だけの成長ロードマップ （図: チーム全員でアイデア出し） 全員参加のブレスト文化 BENEFITS ## 福利厚生・待遇 エンジニアが長く・楽しく・成長し続けられる環境を整えています ** ### 給与・賞与 昇給年1回 賞与年2回（夏・冬） 経験・スキルに応じて優遇 ** ### 社会保険完備 健康保険・厚生年金 雇用保険・労災保険 安心して働ける環境 ** ### スキルアップ全額支援 外部研修費用 全額会社負担 技術書籍購入支援 資格取得支援あり ** ### フィットネス利用 提携フィットネスジム 利用可能 心身ともに健康に ** ### 休日・休暇 週休2日制（土日祝） 年末年始・夏季休暇 有給休暇（入社6ヶ月後付与） ** ### 交通費支給 交通費全額支給 （上限あり） 通勤しやすい環境 ** ### 開発環境支援 最新PC・機材の支給 必要なソフトウェアは 会社が用意 ** ### メンター制度 先輩エンジニアが マンツーマンでサポート 1on1ミーティングあり SELECTION FLOW ## 選考の流れ 応募から内定まで、最短2〜3週間でご連絡します STEP 1 ** #### エントリー 採用サイト または お問い合わせフォームから 気軽にご応募ください ** STEP 2 ** #### 書類選考 履歴書・職務経歴書を 拝見します （1週間以内にご連絡） ** STEP 3 ** #### 一次面接 オンライン or 対面で カジュアルにお話しします （技術・人柄・志向） ** STEP 4 ** #### 最終面接 経営陣・現場リーダーと じっくりお話しします （会社のビジョン共有） ** GOAL ** #### 内定・入社 条件・入社日などを 丁寧に調整します 一緒に未来をつくりましょう！ ** 選考は柔軟に対応しています。現職中・転職活動中の方もお気軽にご相談ください。 FAQ ## よくある質問 ** 新卒・第二新卒でも応募できますか？ ** はい、新卒・第二新卒の方も歓迎しています。プログラミング経験があれば、AI・組込みなどの分野が未経験でも応募いただけます。研修制度・メンター制度が充実しており、入社後のキャッチアップを全力でサポートします。 ** 中途採用は積極的に行っていますか？ ** はい、中途採用も積極的に行っています。他業界からの転職者や、異なる技術領域から来る方も大歓迎です。これまでの経験を活かしながら新しい技術に挑戦できる環境があります。経験・スキルに応じた待遇でお迎えします。 ** 勤務地はどこですか？リモートワークは可能ですか？ ** 本社は大阪市淀川区にあります。プロジェクトによっては客先常駐やリモートワークの場合もあります。働き方については面接時に詳細をすり合わせますので、お気軽にご相談ください。 ** どのような技術スタックを使っていますか？ ** Web系ではPHP・Python・JavaScriptを中心に、AI分野ではPythonによる画像認識・自然言語処理・RAGチャットボット開発を行っています。組込み系ではC/C++を使用し、IoTデバイスやマイコン制御の開発を手がけています。クラウドはAWS・Azureを主に利用しています。 ** 未経験の分野に挑戦することはできますか？ ** もちろんです！実際に「Web出身でAIに転向した」「組込み出身でクラウドを学んだ」というメンバーが活躍しています。外部研修費用の全額会社負担など、新しい分野へのチャレンジを全面サポートしています。 ** 社風・雰囲気を教えてください ** 平均年齢32歳の若いメンバーが中心で、フラットでアットホームな雰囲気です。年齢・経験に関わらず意見を言い合える職場で、互いに学び合うカルチャーがあります。4年連続増収増益を達成した活気あるチームです。 APPLY NOW ## さあ、一緒に テクノロジーの未来を作ろう。 新卒・第二新卒・中途採用、すべての方を積極採用中。 「まずは話を聞いてみたい」という方も歓迎です。 あなたのエントリーをお待ちしています。 [採用サイトで応募する](https://en-gage.net/technosphere_saiyo/) [まずは問い合わせる](https://technosphere.co.jp/contact) ** 選考に関するご質問はお問い合わせフォームからもお気軽にどうぞ [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [技術コラム](https://technosphere.co.jp/blog/) [採用情報](https://technosphere.co.jp/recruit) [プライバシーポリシー](https://technosphere.co.jp/privacy) © 2023 Technosphere Inc. - [Facebook](https://www.facebook.com/technosphere.co.ltd) - [X（旧Twitter）](https://x.com/technosphere_co) - [Instagram](https://www.instagram.com/technosphere_co/) - [TikTok](https://www.tiktok.com/@technosphere.co) --- # スキルシートポータル｜SES・派遣会社のスキルシート・契約・提案を一元管理｜株式会社テクノスフィア > SES・派遣会社向けのスキルシート管理システム。経歴から自動集計するスキルマップで最適な技術者をすぐ提案。エンジニアがスマホで経歴を更新、営業は最新シートをA4・PDFで即出力。契約カレンダーで期間・単金を管理し、提案メール文はワンクリックでコピー。自社サーバーにもクラウドにも置けるDocker導入。 URL: https://technosphere.co.jp/skill-sheet-portal SES・派遣会社の営業のための業務システム # 「至急、Javaできる方いませんか？」 その打診に、待たずに返す。 スキルマップが経歴の実データから「その技術に強い人」を教え、契約カレンダーが空き時期を示し、提案文はワンクリックでコピー。取引先への提案に必要なものが、営業のひとつの画面に揃います。 [デモを申し込む](https://technosphere.co.jp/contact?src=ssp) 機能を見る エンジニアの更新はスマホで完結／自社サーバー設置可・データは社外に出しません 最新版 契約カレンダー 4月 ─ 7月 佐藤A社 / 常駐 高橋B社 / リモート 契約終了 6/30 田中C社 / 常駐 伊藤提案中 稼働 3名 / 提案中 1名 月次合計 ※管理者のみ表示 打診メールが届いてから、返信するまで ## 営業のいつもの動きが、 そのまま速くなる。 新しい仕事のやり方を覚えるツールではありません。いま毎日やっている「探す・確かめる・書く・送る」の各段取りから、待ち時間と転記だけを抜き取ります。 打診が来る 取引先から「○○できる方、いませんか」のメール。ここから時間との勝負。 候補を絞る スキルマップで「その技術を長くやってきた人」を経験月数の実データから特定し、契約カレンダーで空き時期を確認。 シートを開く 本人がスマホで更新済みの最新シート。「最新版どれ？」の往復も、体裁直しも不要。 提案文をコピー 経歴・スキル・フェーズ範囲を整形した提案テンプレ文をワンクリックでコピーし、メールに貼る。 PDFを添えて送信 従来のExcel様式そのままのA4・PDFを添付。単金は管理者画面で確認して、返信完了。 SESの現場で、毎週起きていること ## スキルシートの管理は、 会社の売上に直結している。 提案が1日遅れれば、案件は他社に決まります。それなのに、スキルシートまわりの作業は今もExcelと記憶に頼っていませんか。 「最新版どれ？」と本人に聞いて、返事を待っている ファイルサーバーに『スキルシート_佐藤_最新_v3(2).xlsx』が並ぶ。提案は本人の返信待ちで止まる。 人によって書式も粒度もバラバラ 「PG」「プログラマ」「開発担当」——同じ意味の表記が混在し、提出前に営業が手で直している。 契約終了日を、営業の記憶で管理している 気づいたときには翌月末が契約終了。次の提案の準備が間に合わず、待機が発生する。 提案メールを、毎回ゼロから書いている 経歴の要約・スキル・稼働時期。同じ内容をシートから転記する作業が、提案のたびに発生する。 （図: 山積みのバインダーからスキルシートを探す営業担当のイラスト） 機能 ## 書く・探す・提案する。 その全部を、ひとつのポータルに。 SKILL MAP ### 「できます」ではなく、経歴の実データで人を選ぶ 全エンジニアの経歴からスキルマップを自動集計。技術×人のマトリクスで経験月数が濃淡表示されるので、「Javaを一番長くやってきたのは誰か」「最近も使っているか」がひと目で分かります。 - 経歴の期間から経験月数を自動合算（記入不要・恣意性なし） - 5年以上使っていない技術はグレー表示 — ブランクも正直に見える - C#・ASP.NET・VB.NET → 「C#・.NET」のように系統ごとにまとめて俯瞰 （図: 技術×人のヒートマップから最適な候補を選ぶイラスト） CONTRACT ### 「いま誰が空くか」を、確認待ちゼロで 打診が来た瞬間に見るのはここ。誰がどの取引先・常駐先で、いつまで稼働しているか——契約カレンダーが終了日を可視化するので、「来月末で空く人」から先回りで提案を仕掛けられます。 - 取引先・常駐先・稼動開始日・契約終了日・契約履歴を管理 - 単金（万円/月）と月次合計は管理者のみ閲覧できる権限設計 - 契約と経歴が紐づくので、シートの更新漏れにも気づける （図: 契約期間のタイムラインと終了日マーカーのイラスト） SHEET ### 「最新版ください」の往復を、なくす 帰りの電車で、案件の切れ目に。エンジニア本人がスマホからさくっと経歴を追加できるので、シートは頼まなくても最新になっていきます。営業が依頼して、返信を待って、整形する——提案前の一番もどかしい待ち時間が消えます。 - スマホのブラウザだけで完結。アプリのインストールも、PCを開く必要もなし - 案件名・期間・担当・フェーズ・技術タグを構造化して記録 - 記入状況を管理者が一覧で把握、未記入は代理編集も可能 （図: 移動中にスマホでスキルシートを更新するエンジニアのイラスト） PROPOSAL ### 提案メール文を、ワンクリックでコピー シートの内容から、経歴・スキル・フェーズ範囲を整形した提案用テンプレ文を生成し、クリップボードへコピー。あとはメールに貼って、単価と時期を添えるだけです。 - 提案のたびの転記・要約作業をゼロに - 管理者のみに表示され、営業フローに組み込みやすい （図: スキルシートから提案メールが一動作で生成されるイラスト） PRINT ### 取引先に出す様式は、変えない A4印刷・PDF出力は従来のExcel様式を踏襲。取引先が見慣れた帳票のまま、作る過程だけがWebに変わります。「新しいフォーマットに変わったんですね」とは言わせません。 - ブラウザからそのままA4印刷・PDF出力 - 提出直前の「体裁直し」作業が不要に （図: 整ったA4帳票が印刷されるイラスト） FORMAT ### 表記ゆれを、仕組みで止める 担当（PG/SE/PL等）と開発フェーズは選択式。技術キーワードはマスタ候補からのタグ入力。人に「書き方を揃えて」とお願いするのではなく、揃った書き方しかできない構造にしました。 - 新出キーワードは自動でマスタに追加、管理者が表記を統制 - 誰が書いても、取引先に出せる粒度のシートになる （図: ばらばらのタグが整った一列に揃うイラスト） ADMIN ### 管理者は、全員をひと目で 全従業員の記入状況・シート内容を一覧し、必要なら代理編集。従業員の追加・停止・パスワード再設定までブラウザで完結します。 - 従業員マスタ・選択肢マスタを管理画面で運用 - 会社名の切り替え（マルチテナント）に対応 （図: メンバー一覧ボードを確認する管理者のイラスト） 導入形態 ## エンジニアの個人情報を、 社外に出さない選択ができる。 スキルシートは氏名・経歴・単金を含む機微な情報です。本システムはDockerで動作し、自社サーバー・社内NASへの設置を選べます。もちろんクラウドでの運用も可能です。 | 動作環境 | Dockerが動くサーバーならどこでも（自社サーバー / NAS / クラウド） | | データ保存 | サーバー内のSQLiteファイル。`data/`をコピーするだけでバックアップ完了 | | 導入作業 | `docker compose up -d` で起動。環境構築はご依頼いただけます | | 複数会社 | 会社名切替（マルチテナント）対応。グループ会社ごとの独立環境も構築可 | | カスタマイズ | 開発元（テクノスフィア）が直接対応。帳票様式の調整や機能追加もご相談ください | （図: 社内にデータを保持する自社サーバー設置のイラスト） 導入の流れ ## まず、実物を見てください。 1. STEP 1**デモ** 実際の画面をオンラインでご覧いただきます。現在のスキルシート運用のお悩みもお聞かせください。 2. STEP 2**お見積もり** エンジニア数・導入形態（自社サーバー/クラウド）・カスタマイズ要否に応じて個別にお見積もりします。 3. STEP 3**導入・移行** 環境構築と、既存Excelシートからのデータ移行をご支援します。従業員への展開までサポートします。 **料金:** 規模・導入形態に応じた個別見積もりです。「まず話を聞きたい」だけでも歓迎します。 よくあるご質問 ## 導入前に、よく聞かれること。 取引先に出しているExcelのスキルシート様式は変わりますか？ 変わりません。A4印刷・PDF出力は従来のExcel様式を踏襲した帳票として出力されるため、取引先への提出物はこれまでどおりの見た目のまま、作る過程だけがWeb化されます。 自社サーバーに設置できますか？データを社外に出したくありません。 できます。Dockerで動作するため、自社サーバー・社内NAS・クラウドのいずれにも設置可能です。データはSQLiteファイルとしてサーバー内に保存され、ディレクトリをコピーするだけでバックアップできます。 単金は全員に見えてしまいませんか？ 見えません。単金（万円/月）は管理者のみ閲覧できる項目として権限分離されています。エンジニア本人の画面には表示されません。 エンジニアがちゃんと書いてくれるか不安です。 書く側のハードルを徹底的に下げています。スマホのブラウザから数タップで書け、担当（PG/SE/PL等）や開発フェーズは選択式、技術キーワードはタグ入力なので、長文を書く負担がありません。それでも未記入の場合は管理者画面で記入状況を一覧でき、代理編集も可能です。 「この技術ができる人」をどうやって探すのですか？ スキルマップ機能を使います。全エンジニアの経歴から技術ごとの経験月数を自動集計し、技術×人のマトリクスで濃淡表示します。5年以上使っていない技術はグレー表示されるため、「昔できた」と「今できる」の区別もつきます。 料金はいくらですか？ エンジニア数・導入形態（自社サーバー/クラウド）・カスタマイズの有無に応じた個別見積もりです。デモのご希望を含め、お問い合わせフォームからご相談ください。 ## 「最新版どれ？」のない会社へ。 デモは30分程度、オンラインで実施します。現在のExcel運用のまま何が変わるか、実際の画面でご確認ください。 [デモ・資料請求はこちら](https://technosphere.co.jp/contact?src=ssp) © 株式会社テクノスフィア（大阪市淀川区） [コーポレートサイト](https://technosphere.co.jp/) [プライバシーポリシー](https://technosphere.co.jp/privacy) --- # SphereScope - ウェブアクセス解析プラットフォーム｜株式会社テクノスフィア > SphereScope（スフィアスコープ）は、あらゆるウェブサイトのアクセスを解析・記録するプラットフォームです。軽量タグ1行で導入でき、PV・UU・流入元・デバイス・カスタムイベントをリアルタイムに収集・可視化します。 URL: https://technosphere.co.jp/spherescope-analytics [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [採用情報](https://technosphere.co.jp/recruit) Web Analytics Platform Web Access Analytics Platform # SphereScope スフィアスコープ タグ1行を埋め込むだけ。 あらゆるサイトのアクセスをリアルタイムに解析・可視化。 < 5KB タグサイズ Cookie不要 プライバシー配慮 複数サイト 一元管理 お問い合わせ [資料ダウンロード](https://technosphere.co.jp/assets/download/spherescope-analytics-pamphlet.pdf) 機能を見る SphereScope Dashboard 12,847 PV / 日 3,291 UU / 日 42 リアルタイム Problem ## こんな課題、ありませんか？ ** アクセス解析を導入したいが **設定が複雑で手間がかかる Google Analyticsの **データを自社で管理したい 複数のサービスを **バラバラに管理している Cookieに頼らない **プライバシー対応の解析がしたい** Features ## SphereScope の特徴 導入から解析まで、シンプルかつ強力なアクセス解析を実現します 01 ** ### タグ1行で即導入 5KB以下の軽量スクリプトを1行追加するだけで計測開始。サイトの表示速度にほとんど影響を与えません。 `` 02 ** ### リアルタイムダッシュボード 今この瞬間のアクティブユーザー数から、PV・UU・直帰率・滞在時間まで、すべてをリアルタイムで可視化します。 - **アクティブユーザー（5分以内） - **時系列グラフ（Recharts） - **直近30分PV推移 03 ** ### 複数サイトを一元管理 1つのSphereScope で複数サイトを管理。サービスごとにトラッキングIDを発行し、ダッシュボードを切り替えるだけです。 - **サイト登録・削除が簡単 - **スニペット自動生成 - **サイトごとの個別分析 04 ** ### 詳細な流入元分析 リファラーやUTMパラメータを自動収集。どのチャネルからどれだけ集客できているかを可視化し、マーケティング施策に活かせます。 - **UTM source/medium/campaign - **リファラー分析 - **流入チャネル別比較 05 ** ### デバイス・環境分析 PC・スマートフォン・タブレットの比率から、ブラウザ・OSの分布まで、ユーザー環境を詳細に把握できます。 - **デバイス種別・画面サイズ - **ブラウザ・OS分布 - **地域別（国・都市） 06 ** ### カスタムイベント計測 ボタンクリック・購入完了・フォーム送信など、任意のユーザーアクションをJavaScriptで簡単に計測できます。 `window.ss('event', 'purchase', { price: 1980 })` Collected Data ## 収集できるデータ ** ### ページビュー - URL・ページタイトル - 滞在時間 - 直帰・離脱ページ ** ### セッション - セッション継続時間 - 閲覧ページ数 - 新規 / リピーター ** ### 流入元 - リファラーURL - UTMパラメータ - 検索 / SNS / 直接 ** ### デバイス - PC / スマホ / タブレット - ブラウザ・OS - 画面解像度 ** ### 地域 - 国・都市 - IP即時ハッシュ化 - 元データは保存なし ** ### カスタムイベント - 任意のイベント名 - カスタムプロパティ - コンバージョン計測 Privacy ## プライバシーへの配慮 個人情報保護法・GDPRに対応した設計で、 ユーザーのプライバシーを尊重しながら解析を行います。 - IPアドレスを即時ハッシュ化** 受信後すぐにハッシュ化し、元のIPアドレスは一切保存しません。 - Cookie不使用** Cookieを使わずにセッション管理を実現。同意バナーなしで導入できます。 - データを自社サーバーで管理** 収集データは自社管理のサーバーに保存。第三者への情報提供は一切行いません。 - GDPR・個人情報保護法対応設計** 欧州・日本の個人情報保護規制に配慮した設計で、安心して導入いただけます。 ** Privacy First ** GDPR対応 ** Cookie不要 ** IP匿名化 ** 自社管理 Technology ## 技術スタック ** ### トラッカー 純粋 JavaScript 依存ゼロ・5KB以下 ** ### バックエンド Go 1.22 + Fiber v2 ** ### ダッシュボード React 18 + TypeScript + Vite ** ### データベース PostgreSQL 16 高速クエリ対応 ** ### インフラ Docker Compose 1コマンド起動 Use Cases ## 活用シーン ** 自社サービス・ECサイト ** Use Case 01 ### 自社サービス・ECサイトの改善 ユーザーがどのページを見て、どこで離脱しているかを正確に把握。 データに基づいたUI/UX改善で、コンバージョン率の向上を実現します。 - **ページ別直帰率・滞在時間の把握 - **購入完了・会員登録のコンバージョン計測 - **改善前後の効果測定 ** マーケティング分析 ** Use Case 02 ### マーケティング効果の測定 UTMパラメータで広告・SNS・メルマガなど流入チャネルを細かく分析。 施策ごとのROIを可視化し、予算配分の最適化に役立てます。 - **広告キャンペーン別の流入分析 - **SNS・検索・メルマガの比較 - **チャネル別コンバージョン率の把握 ** 複数サービス運営 ** Use Case 03 ### 複数サービスの一元管理 コーポレートサイト・サービスサイト・ランディングページなど、 複数のウェブ資産を1つのダッシュボードで横断管理。 - **サイトごとの個別ダッシュボード - **サービス横断での比較分析 - **チームメンバーとのデータ共有 Contact ## SphereScope 導入のご相談 デモのご依頼・お見積り・ご質問など、 お気軽にお問い合わせください。 ** 担当：お問い合わせフォームよりご連絡ください [お問い合わせ](https://technosphere.co.jp/contact) [資料ダウンロード](https://technosphere.co.jp/assets/download/spherescope-analytics-pamphlet.pdf) [06-4805-8282](tel:06-4805-8282) [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [技術コラム](https://technosphere.co.jp/blog/) [採用情報](https://technosphere.co.jp/recruit) [プライバシーポリシー](https://technosphere.co.jp/privacy) © 2023 Technosphere Inc. - [Facebook](https://www.facebook.com/technosphere.co.ltd) - [X（旧Twitter）](https://x.com/technosphere_co) - [Instagram](https://www.instagram.com/technosphere_co/) - [TikTok](https://www.tiktok.com/@technosphere.co) --- # SphereSync - リアルタイム自動翻訳システム｜株式会社テクノスフィア > SphereSync（スフィアシンク）は、リアルタイム対話の壁を最新AIで突破するリアルタイム自動翻訳システムです。超低遅延・専門用語対応・ローカル動作でセキュアな多言語コミュニケーションを実現。 URL: https://technosphere.co.jp/spheresync [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [採用情報](https://technosphere.co.jp/recruit) AI Real-time Translation System # SphereSync スフィアシンク リアルタイム対話の壁を、最新AIで突破。 グローバルコミュニケーションを、瞬時につなぐ。 お問い合わせ [資料ダウンロード](https://technosphere.co.jp/assets/download/spheresync-pamphlet.pdf) （図: SphereSync リアルタイム翻訳） ## グローバルビジネスのこんな課題、ありませんか？ ** リアルタイム通訳の **タイムラグが大きい 専門用語や固有名詞が **正確に翻訳されない 機密情報を **外部サービスに送れない 通訳者の手配に **コストと時間がかかる** ## SphereSync 3つの強み 01 ** ### 圧倒的な低遅延 スムーズな多言語コミュニケーション 最新のAI技術により、発話から翻訳までの遅延を極限まで削減。自然な会話のリズムを保ったまま、リアルタイムで翻訳を提供します。 02 ** ### 専門用語・固有名詞に対応 正確な翻訳を実現 業界特有の専門用語や企業固有の製品名も高精度に翻訳。カスタム辞書機能により、御社専用の翻訳精度を実現します。 03 ** ### ローカル動作でセキュア 機密性の高い商談も安心 Raspberry Pi 5上でローカル動作するエッジ版なら、会話データが外部に送信されません。機密性の高いビジネス商談でも安心してご利用いただけます。 ## 活用シーン （図: ライブ配信の多言語翻訳） ** Use Case 01 ### ライブ配信 InstagramやTikTok Liveでの配信を、リアルタイムで多言語翻訳。日本語で話しながら、世界中の視聴者に同時に届けることができます。 - **Instagram Live、TikTok Live対応 - **日本語→英語・ベトナム語等の同時翻訳 - **字幕表示機能で視聴体験向上 （図: 訪日外国人への多言語接客） ** Use Case 02 ### 多言語接客 訪日外国人への店頭対応を、タブレット1台で解決。言語の壁を超えて、スムーズな接客を実現します。 - **日本語・英語・ベトナム語等に対応 - **商品説明や会計もスムーズに - **観光地・免税店での導入実績 （図: 国際ビジネス商談） ** Use Case 03 ### ビジネス商談 リモート会議での専門用語対応。技術的な商談や契約交渉も、正確な翻訳で円滑に進めることができます。 - **専門用語の高精度翻訳 - **カスタム辞書で企業固有用語対応 - **ローカル動作で機密情報も安心 ## 動作環境 ** ### クラウド版 スケーラブルな運用 大規模利用や複数拠点での展開に最適。常に最新のAIモデルを利用でき、メンテナンスの手間もかかりません。 - **初期投資を抑えて導入 - **自動アップデート - **利用量に応じた課金 セキュア ** ### エッジ版 Raspberry Pi 5でローカル動作 音声データが外部に送信されないため、機密性の高いビジネス商談でも安心。ネットワーク不要で超低遅延を実現します。 - **データ外部流出なし - **オフライン環境で動作 - **最小限の遅延 ## 対応言語 ** 日本語 ** English ** Tiếng Việt ** その他言語も相談可 ※ 中国語・韓国語・スペイン語など、その他の言語についてもお気軽にご相談ください。 ## SphereSync導入のご相談 デモのご依頼・お見積り・ご質問など、 お気軽にお問い合わせください。 ** 担当：小山（koyama@technosphere.co.jp） [お問い合わせ](https://technosphere.co.jp/contact) [資料ダウンロード](https://technosphere.co.jp/assets/download/spheresync-pamphlet.pdf) [06-4805-8282](tel:06-4805-8282) [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [技術コラム](https://technosphere.co.jp/blog/) [採用情報](https://technosphere.co.jp/recruit) [プライバシーポリシー](https://technosphere.co.jp/privacy) © 2023 Technosphere Inc. - [Facebook](https://www.facebook.com/technosphere.co.ltd) - [X（旧Twitter）](https://x.com/technosphere_co) - [Instagram](https://www.instagram.com/technosphere_co/) - [TikTok](https://www.tiktok.com/@technosphere.co) --- # TechnoAlive - クラウドサーバー死活監視システム｜株式会社テクノスフィア > TechnoAlive（テクノアライブ）は、クラウドサーバーの死活監視・パフォーマンス監視・セキュリティ監視を一元管理するシステムです。障害を即座に検知し、メール・Slack通知で素早い対応を実現します。 URL: https://technosphere.co.jp/technoalive [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [採用情報](https://technosphere.co.jp/recruit) NEW PRODUCT Cloud Server Monitoring System # TechnoAlive テクノアライブ クラウドサーバーの「今」を、リアルタイムで把握。 死活監視・パフォーマンス・セキュリティを 一元管理し、 障害を即座に検知・通知します。 99.9% 稼働監視精度 24h 365日対応 5分 以内に異常検知 [お問い合わせ・デモ依頼](https://technosphere.co.jp/contact) [資料ダウンロード](https://technosphere.co.jp/assets/download/technoalive-pamphlet.pdf) 詳細を見る （図: TechnoAlive ダッシュボード画面） ## こんなお悩みはありませんか？ ** サーバーが落ちてから 気づくことが多い ** 複数のサーバーを 一箇所で管理できない ** 不正アクセスや セキュリティリスクが不明 ** CPU・メモリ使用率の 急上昇に気づかない ** TechnoAliveで解決 ** FEATURES ## TechnoAliveの主な機能 サーバー監視に必要なすべての機能を、ひとつのダッシュボードに集約 ** ### 死活監視 Ping・SSH・HTTP/HTTPSによるマルチプロトコル監視。 異常を最短5分以内に検知し、即座に通知します。 - **ICMP Ping 監視 - **SSH 接続確認 - **HTTP/HTTPS エンドポイント監視 - **カスタム監視間隔設定 ** ### パフォーマンス監視 CPU・メモリ・ディスク使用率をリアルタイムで可視化。 閾値超過を自動検知します。 - **CPU 使用率リアルタイム表示 - **メモリ使用率グラフ - **ディスク使用率アラート - **応答時間の推移グラフ ** ### セキュリティ監視 不正ログイン試行やブルートフォース攻撃を自動検知。 セキュリティリスクを早期に把握できます。 - **SSH ブルートフォース検知 - **失敗ログイン試行の可視化 - **セキュリティリスクレベル評価 - **ポート監視・ネットワーク統計 ** ### 即時通知 異常検知時にメール・Slackへ即座に通知。 担当者がどこにいても素早い対応が可能です。 - **メール通知（SMTP 対応） - **Slack Webhook 通知 - **通知先・条件のカスタマイズ - **テスト通知機能 ** ### 一元管理ダッシュボード 全サーバーの状態をひとつの画面で把握。 直感的なUIで複数インスタンスを効率管理。 - **マルチサーバー一覧管理 - **稼働率・応答時間サマリー - **7日間・24時間の稼働履歴 - **ダーク／ライトテーマ対応 ** ### マルチクラウド対応 OCI・AWS・Azure・GCPなど主要クラウドに対応。 プロバイダーをまたいだ統合監視が可能です。 - **Oracle Cloud Infrastructure - **AWS / Azure / GCP - **オンプレミス環境にも対応 - **リージョン・タグ管理 DASHBOARD ## すべての情報を ひとつの画面に TechnoAlive のダッシュボードは、複数のサーバーの稼働状況を 一目で把握できるように設計されています。 直感的なUIで、必要な情報にすぐアクセス可能です。 ** ダッシュボード ** 監視一覧 ** 詳細メトリクス ** セキュリティ （図: TechnoAlive ダッシュボード画面） USE CASES ## こんな場面で活躍 01 ** ### ECサイト・Webサービス運営 サービス停止を即座に検知。売上機会の損失や顧客信頼低下を防ぎます。 02 ** ### 企業基幹システム管理 業務システムの安定稼働を保証。障害発生時の迅速な対応で事業継続性を確保。 03 ** ### 開発・ステージング環境の管理 複数の開発環境を一元管理。リソース消費の可視化でコスト最適化にも貢献。 04 ** ### セキュリティ強化が必要な環境 不正アクセスの早期検知でセキュリティインシデントを未然に防止します。 TECHNOLOGY ## 採用技術 ** Python / FastAPI ** JavaScript ** Redis ** Docker ** Multi-Cloud対応 ** REST API ** New Release ## サーバー監視を、もっとスマートに。 デモのご依頼・導入のご相談・お見積りなど、 お気軽にお問い合わせください。 [お問い合わせ・デモ依頼](https://technosphere.co.jp/contact) [資料ダウンロード](https://technosphere.co.jp/assets/download/technoalive-pamphlet.pdf) [製品一覧に戻る](https://technosphere.co.jp/products) [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [技術コラム](https://technosphere.co.jp/blog/) [採用情報](https://technosphere.co.jp/recruit) [プライバシーポリシー](https://technosphere.co.jp/privacy) © 2023 Technosphere Inc. - [Facebook](https://www.facebook.com/technosphere.co.ltd) - [X（旧Twitter）](https://x.com/technosphere_co) - [Instagram](https://www.instagram.com/technosphere_co/) - [TikTok](https://www.tiktok.com/@technosphere.co) --- # AI電話自動応対「TechnoVoice」｜24時間受付・コールセンター不要｜株式会社テクノスフィア > AI電話自動応対システム「TechnoVoice」。御社のFAQ・マニュアルをAIが学習し、電話の受付・応対を24時間自動化。コールセンター不要で人件費を大幅削減、営業時間外の問い合わせ対応も可能。導入実績多数、無料デモ受付中。 URL: https://technosphere.co.jp/technovoice [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [採用情報](https://technosphere.co.jp/recruit) AI Voice Call System # TechnoVoice テクノボイス AIが御社のナレッジを学習し、 かかってきた電話を24時間自動応対するシステム お問い合わせ [資料ダウンロード](https://technosphere.co.jp/assets/download/technovoice-pamphlet.pdf) （図: TechnoVoice AIオペレーター） ## こんなお悩みありませんか？ ** 電話対応の **人手が足りない 営業時間外の **問い合わせに対応できない コールセンターの **コストが高い オペレーターの **教育に時間がかかる** ## TechnoVoiceが解決します （図: TechnoVoice サービス概念図） **TechnoVoice**は、御社のナレッジ・FAQ・マニュアルなどのドキュメントをAIが学習し、電話での問い合わせに自動で応対するシステムです。 - **既存のドキュメントを学習するだけで導入可能 - **自然な音声で違和感のない応対を実現 - **24時間365日、休みなく稼働 - **対応内容は随時学習・改善 ## TechnoVoiceの特徴 （図: 24時間対応） ### 24時間対応 深夜・早朝・休日も関係なく、いつでも電話応対が可能。機会損失を防ぎます。 （図: ナレッジ学習） ### ナレッジ学習 FAQ・マニュアル・過去の対応履歴など、御社のドキュメントを学習して応対します。 （図: 自然な音声対話） ### 自然な音声対話 最新の音声合成技術により、人間のオペレーターのような自然な会話を実現します。 （図: コスト削減） ### コスト削減 人件費・教育コストを大幅に削減。ROIの高い投資を実現します。 ## 導入の流れ （図: TechnoVoice 導入フロー） 01 ### ドキュメント提供 FAQ・マニュアル・対応履歴などをご提供ください 02 ### AI学習・設定 御社のナレッジをAIが学習し、応対シナリオを構築 03 ### システム連携 電話システムとの連携設定を行います 04 ### 運用開始 テスト運用後、本番稼働を開始します ## 活用シーン ** ### 代表電話の一次対応 会社への問い合わせを自動で振り分け、担当者へ転送 ** ### カスタマーサポート よくある質問への自動回答で、オペレーターの負担を軽減 ** ### 予約・受付対応 予約の受付・確認・変更を24時間自動で対応 ** ### 営業時間外・休日の自動応対 営業時間外や土日祝日にかかってきた問い合わせ電話を、AIが自動で受け付け・応対。機会損失をゼロにします。 ## TechnoVoiceの導入をご検討ください デモのご依頼・お見積り・ご質問など、 お気軽にお問い合わせください。 [お問い合わせ](https://technosphere.co.jp/contact) [06-4805-8282](tel:06-4805-8282) [パンフレット（PDF）](https://technosphere.co.jp/assets/download/technovoice-pamphlet.pdf) [（図: ロゴ：株式会社テクノスフィア）](https://technosphere.co.jp/) [技術コラム](https://technosphere.co.jp/blog/) [採用情報](https://technosphere.co.jp/recruit) [プライバシーポリシー](https://technosphere.co.jp/privacy) © 2023 Technosphere Inc. - [Facebook](https://www.facebook.com/technosphere.co.ltd) - [X（旧Twitter）](https://x.com/technosphere_co) - [Instagram](https://www.instagram.com/technosphere_co/) - [TikTok](https://www.tiktok.com/@technosphere.co)