モバイル文書の直接取り込みからOpenClawへ：iOSからRaspberry Piへの健康ワークフロー

r/openclawの開発者が、モバイルiOSクライアントから直接Raspberry Pi上で動作するローカルOpenClawインスタンスにドキュメントをプッシュする実験的なパターンを文書化しました。目的は、検査結果や処方箋などのドキュメントをスマートフォンでスキャンし、クラウド仲介者や手動アップロードなしでOpenClawに送り込み、下流処理を行うことです。

アーキテクチャ概要

このシステムは2層アプローチを使用しています：スマートフォンがキャプチャ層として機能し、OpenClawが処理層として機能します。モバイルクライアントは完全にローカルでプライバシー保護を重視して設計されており、クラウド依存や外部AIサービスはありません。Apple OCR（Vision）とオンデバイスインテリジェンスを抽出と検索に使用し、生のドキュメントと抽出されたコンテンツは、明示的にOpenClawにプッシュされるまでデバイス上に保持されます。

ペアリングと設定

QRコードベースのペアリングフローにより、手動設定を回避します。QRペイロードは、OpenClawマシン上で生成されたbase64エンコードされたJSONブロブで、次の構造を持ちます：

{ "url": "wss://", "bootstrapToken": "", "hooksToken": "", "agentId": "", "hookPath": "/hooks/rkive" }

hooksTokenはiOSキーチェーンに保存され、非機密設定はローカルストレージに保存され、wss://URLはプッシュリクエストのためにhttps://に変換されます。

データフロー

iPhoneモバイルクライアントは、Bearerトークン（{hooksToken}）とbase64エンコードされたPDFを含むJSONペイロードを添えて、/hooks/rkiveにPOSTリクエストを送信します。これはOpenClawインスタンス（Raspberry Pi、ローカルネットワークまたはVPN上）に到達し、ingest_rkive.py変換スクリプトを実行します。このスクリプトは元のPDFをhealth-records/originals/に保存し、インデックスレコードをhealth-records/index.jsonlにアップサートし、チャンク化されたアセンブリと中止時のクリーンアップを処理します。専用の健康エージェントはその後、下流処理を管理します：OCR → 検証 → 構造化出力。

主要な設計判断

• OpenClaw内の専用エージェント： マルチエージェント設定には、ドキュメント取り込み、検証、下流構造化を担当する専用の健康エージェントが含まれており、健康関連のワークフローを分離しています。
• 専用エンドポイント： agentIdを介した動的ルーティングではなく、/hooks/rkiveのような固定エンドポイントを使用することで、決定論的ルーティングを確保し、誤った分類を回避し、サーバー側ロジックを簡素化します。

下流ワークフローと未解決の課題

下流ワークフローは進行中の作業です。Apple OCRは100%の精度で信頼できないとされているため、計画では、ユーザーの信頼できるAIワークフローを使用してOpenClaw内でクリーンなマークダウンにテキストを再抽出し、コンテンツ検証のための人間による検証ステップ、FHIRスタイルのリソースへの構造化抽出、縦断的データセットへの追加、健康インサイトの提供を行います。

著者はコミュニティフィードバックのために2つの未解決の質問を提起しています：1）このパターンが実際の定期的な使用において有用と感じられるか、それとも摩擦が大きすぎるか、2）人々がOpenClawに個人健康記録を取り込んだ後に何をしてほしいか、縦断的イベントタイムライン、ギャップの検出（例：見逃されたフォローアップ）、定期的な要約などのアイデアを提案しています。