【連載#1】Raspberry Pi × FlutterでフィジカルAI：動くデモから使える形へ（全体像と設計の型）
【連載#1】Raspberry Pi × FlutterでフィジカルAI：動くデモから使える形へ（全体像と設計の型）
この連載について（狙い）
この連載では、Raspberry Pi と Flutter を使って、カメラ入力から推論、ダッシュボード表示、そしてGPIOによる出力までを一つの作品として作ります。初回から設計も扱いますが、狙いは難しい理屈ではなく、手を動かして最後まで完成させることです。
単にAIモデルを動かすのではなく、実際に動かす場所で必要になりがちな要素を、最小構成で一通り押さえます。
- 現実世界の入力（照明変動・ブレ・設置条件）
- エッジ上の推論（計算資源・熱・遅延）
- 状態表示（今どうなっているかを見せるUI）
- 機械の行動（GPIO出力、状態機械で誤作動抑制、安全設計）
- 使い続けるための仕組み（自動起動、ログ、切り分け、更新手順）
フィジカルAIとは何か（この連載での定義）
本連載では、フィジカルAIを次の閉ループとして定義します。
- センシング：カメラ等で物理世界を観測
- 推論：観測データから状態を推定（分類/検出など）
- アクション：人または機械が行動できる形に変換（UI/通知/GPIO制御）
- 使い続ける：落ちない・追える・直せる（ログ、復旧、更新）
重要なのは、モデル精度だけではなく「使う人が安心して動かせる形になっているか」です。
このため、序盤から安定して動かす条件や責務分割を前提に組み立てます。
なぜフィジカルAIは難しいのか（論点整理）
机上で動いても、実際に動かす場所では破綻しやすい理由がいくつかあります。
- 入力が不安定：照明、反射、ブレ、汚れ、個体差
- 計算資源が限定：GPU前提が使えない、熱で性能が落ちる
- リアルタイム性：平均よりも安定した遅延が重要
- 見える化不足：状態が分からないと使い続けられない
- 使い続ける工夫が必要：再起動復帰、ログ、切り分けが必須
この連載は、これらを後回しにせず、章立ての中で順に潰します。
完成形（この連載で作るもの）
最終的な完成形は、次の構成です。
-
Raspberry Pi（エッジ）
- カメラ入力取得
- 軽量推論（TFLite等を想定）
- FastAPIで推論結果と状態を配信（REST＋リアルタイム）
- GPIOでLED/ブザー等の機械出力（状態機械＋安全設計込み）
- ログ・スナップショット保存（再現性）
-
Flutter Web（UI）
- 状態監視（死活、遅延、温度など）
- 推論結果の一覧とライブ表示（オーバーレイ）
- 自動/手動、停止/解除などの運用操作
全体アーキテクチャ図
Raspberry Pi上でカメラ入力を前処理し、TFLiteで推論し、その結果をFastAPIで配信します。Flutterは状態を表示し、操作はAPI経由でPi側のGPIO制御に反映します。
アーキテクチャ（最小構成・責務分割）
フィジカルAIは差し替えが前提です。モデルもUIも変わるため、責務で分けます。パーツを分けておくと、後からカメラやモデルだけ交換しても全体が崩れません。工作で言えば、基板ごと作り直さずに部品交換で済む状態を作ります。
- Camera：フレーム取得（Pi Camera/USB）
- Inference：推論（モデル差し替え可能）
- API：配信（UI・外部連携の境界）
- UI：可視化・操作（意思決定を支援）
- Actuator：機械出力（GPIO）
- Ops：ログ、復旧、自動起動、更新
データフロー（基本形）
- カメラからフレーム取得
- 推論（ラベル/スコア/bboxなど）
- APIで配信（JSON + 必要ならストリーム）
- UI表示／状態機械が必要に応じて機械出力
- ログ保存（原因追跡と改善に使う）
連載の設計方針（書籍化前提の固定ルール）
この連載では、各回の末尾に次を固定で入れます。
- チェックリスト：その回でできるようになること
- よくあるつまずき：詰まりやすい点と回避策
- 次回の前提：次回に進む前に整っているべき状態
また、序盤から以下を「安定して動かす条件」として扱います。
- 起動時OFF（安全側）
- 異常時OFF（フェイルセーフ）
- ログで追える（原因が分かる）
- 再起動で復帰（止まりっぱなしにしない）
- 安定遅延優先（ピークより安定）
リポジトリ雛形（この形で固定）
まずは、章としても流用しやすい形を確定します。
physical-ai-rpi/
backend/
app/
main.py
core/
services/
requirements.txt
README.md
frontend/
physical_ai_dashboard/
lib/
pubspec.yaml
README.md
docs/
architecture.md
scripts/
dev.ps1
dev.sh
- backend：推論・API・ログ・機械出力（GPIO）
- frontend：Flutter Web ダッシュボード
- docs：書籍化時にそのまま使う設計資料
- scripts：属人性を排除する実行手順
14章構成（この連載の全体ロードマップ）
本連載は 14章 で進めます。機械アクション（GPIO／状態機械／安全設計）を独立章にして、フィジカルAIとしての輪郭を明確にします。
1.フィジカルAI入門（本記事）
2.Raspberry Pi セットアップ標準化
3.カメラ入力パイプライン（安定取得）
4.推論基盤（軽量モデルで動かす）
5.推論API（FastAPI）
6.リアルタイム配信（映像＋結果ストリーミング）
7.Flutterダッシュボード①（状態監視・結果一覧）
8.GPIO入門（LED/ブザーで機械を動かす）
9.状態機械（誤作動を潰す）
10.安全設計（フェイルセーフ／非常停止／監査ログ）
11.Flutterダッシュボード②（ライブ＋オーバーレイ＋制御UI）
12.ログとスナップショット（再現性）
13.自動起動と運用（systemd、更新、死活）
14.性能最適化と応用パターン（横展開できる型）
次回予告（第2章）
次回は Raspberry Pi を「動く」ではなく運用前提で標準化します。
SSH、時刻、ネットワーク、最低限のセキュリティまで整備し、現場に置ける地盤を作ります。
Discussion