# ロボット安全性の最新研究と法規制動向

## エグゼクティブサマリー

ロボット安全性の論点は、従来の「機械安全」中心から、**人間と空間を共有するロボットの運用安全、AIモデルの挙動保証、サイバーセキュリティ、そして市販後監視**を含む総合的なガバナンスへ急速に拡張している、というのが2021–2026年の最大の変化である。学術レビューでは、協働ロボットや移動ロボットの安全確保は、物理設計だけでは足りず、**人間要因、認知負荷、データ品質、監視、継続改善**までを扱う多層的アプローチが必要だという点でほぼ収斂している。Giallanza らは危険源分析に「**integrate the human factor**」が必要だと整理し、Khan らは HRC 安全に「**multi-layered approaches**」が必要だと要約する。Belzile らは、移動ロボットについては標準とリスク評価の文献が依然「**rather limited**」だと指摘しており、ここが今の実装上のボトルネックである。 citeturn28view1turn12search0turn28view5

法規制では、**EU が最も体系的**で、AI Act、Machinery Regulation、Cyber Resilience Act、Product Liability Directive などを組み合わせて、ロボットを「AI」「機械」「デジタル要素を持つ製品」として多層的に規律しつつある。AI Act は 2024年8月施行、全面適用は原則 2026年8月だが、製品安全法制に埋め込まれた高リスクAIの適用は 2027年8月が基準で、調和規格の遅れを受けて 2025–2026年に実施時期調整の提案も動いている。米国はこれと対照的に、OSHA・NIST・FDA・NHTSA の**分散的なセクター別ガバナンス**で対応している。日本は既存の労働安全衛生・自動運転・医療機器制度の上に、2025年のAI法とその指針整備を重ねる形で前進している。中国と英国は、包括法よりも**標準化・製品安全・情報表示・部門別監督**を強める方向が目立つ。 citeturn29view0turn32view0turn29view2turn21search9turn29view11turn31view1turn35view0turn40search1turn7search2turn36view0turn41view1turn31view2

国際規格では、**ISO 10218-1/-2 の2025年改訂**が最重要である。協働ロボットの考え方は ISO/TS 15066 の内容を 10218 シリーズへ取り込む方向が明示され、サービスロボットでは ISO 31101:2023 が「安全な運用」の管理システム要求を定め、次期 ISO/FDIS 13482 は個人向けからより広いサービスロボット安全へ射程を広げている。AI と機能安全の接続でも、ISO/IEC JTC 1/SC 42 で ISO/IEC CD TS 22440-1 が開発中であり、IEEE では fail-safe 設計の IEEE 7009-2024、アルゴリズムバイアスの IEEE 7003-2024 が公開済みである。採用状況を見ると、米国では ANSI/A3 R15.06-2025 が ISO 10218:2025 を国内採用し、中国では GB/T 20867.1-2024 と GB/T 45502-2025 が発効、日本は ISO 31101 を主導した。つまり、**規格競争の中心は「設計安全」から「運用安全＋AIガバナンス＋サイバー統合」へ移っている**。 citeturn9search0turn15search0turn29view8turn29view9turn15search12turn10search0turn10search2turn29view5turn29view6turn29view7turn14search8

企業実務では、自動車分野の Waymo や Mobileye が**安全ケース**や**形式モデル**を公表して先行し、製造分野では Universal Robots などが「cobot そのものは安全の代替ではなく、アプリケーションごとのリスクアセスメントが必須」という実務線を明確にしている。医療では Intuitive と FDA の動きを見ると、性能実証だけでなく、**人間工学、訓練、サイバーセキュリティ、実臨床での継続監視**が安全の中心に移っている。家庭用AIロボットでは、物理安全に加え、プライバシー・データ保護・在宅空間での社会的に適切な挙動が競争条件化しているが、公開された正式な「安全ケース」はまだ少なく、ここは今後の制度・市場の空白である。 citeturn16search0turn16search1turn16search2turn16search10turn16search3turn25search0turn35view1turn35view2turn17search0turn17search16

政策的にみると、短期では**適合・文書化・監査コストの上昇**、中期では**安全ケース、SBOM、データガバナンス、人間監督の標準実装化**、長期では**規制適合能力そのものが研究開発・市場参入の優位**になる公算が大きい。実務者には、機能安全とAIガバナンスとサイバーを単一の品質・安全マネジメント系に統合し、前市場試験だけでなく市販後監視まで設計に含めることが重要である。政策立案者には、調和規格と試験法の整備、事故報告・再学習・アップデートのルール化、そして中小企業が使えるテンプレート型安全ケースや評価基盤の整備が最重要課題である。 citeturn29view1turn32view0turn35view1turn40search2turn26search1turn27search1

## 学術論文とレビュー

過去5年の学術文献を俯瞰すると、安全研究の重心は、**協働ロボットの接触安全**から、**移動ロボットの状況依存リスク**、**医療ロボットのライフサイクル管理**、**AIを含む説明可能な安全保証**へ広がっている。2021年の HRC 系統レビューは既に、工場協働における安全措置の多様化と、単純な隔離型保護からの移行を示していた。2023年のスマート製造レビューも、HRC 実装の中核要件として柔軟性・効率だけでなく安全と持続可能性を挙げている。2024–2026年の文献では、これに加えて人間信頼、認知工学、データ品質、実環境モニタリングが安全の前提条件として位置づけられる。 citeturn12search3turn12search15turn28view1turn12search14turn12search0

重要レビューと論文を整理すると、第一に、Giallanza らの 2024年レビューは、HRC の危険源分析とリスク評価に人間要因を埋め込むことを重視し、レビュー対象論文が**“integrate the human factor”** の必要性を繰り返し示していると結論づけた。第二に、Haney らの 2024年レビューは、自律移動ロボットに対する安全知覚と信頼の研究を整理し、実安全と知覚安全のギャップが導入障壁になると示した。第三に、Marcus らの Nature Medicine 2024 は医療ロボット評価に IDEAL フレームワークを適用し、長期監視は**“collaborative, transparent and inclusive consortiums”**へ移行すべきだと提案した。第四に、Adesiji らの 2025/2026年系統レビューは、包括的リスク評価枠組みと安全モデルの必要性を強調した。第五に、Khan らの 2026年レビューは、HRC 安全をハードウェア、制御、認知、倫理まで含む**“multi-layered approaches”**として整理した。第六に、Belzile らの 2025年論文は建設現場の移動ロボット安全に対して、現行規格では覆いきれないシナリオを補う定量的リスク評価枠組みを提案している。 citeturn28view1turn13search2turn28view3turn12search5turn12search0turn28view5

| 文献 | 年 | 領域 | 要点 | 実務上の示唆 |

|---|---:|---|---|---|

| Arents ら, *Human–Robot Collaboration Trends and Safety Aspects* | 2021 | 製造HRC | 193本規模のレビューで、協働レベルごとに安全措置を整理。HRC の安全は単純な停止機能ではなく、タスク・環境依存であることを示した。 citeturn12search3 | 共同作業設計では「ロボットの安全機能」ではなく「作業セル全体の設計」が必要。 |

| Othman ら, *Human–Robot Collaborations in Smart Manufacturing Environments* | 2023 | スマート製造 | HRC を支える技術群を整理し、安全を柔軟性・持続可能性と並ぶ導入要件として扱う。 citeturn12search15 | 安全は productivity trade-off ではなく導入前提条件。 |

| Giallanza ら, *Occupational health and safety issues in HRC* | 2024 | 労働安全衛生 | 危険源分析・リスク評価に人間要因統合が不可欠で、専門家依存型評価には限界があると整理。 citeturn28view1 | HAZOP/FMEA だけでなく、人間行動・負荷・誤使用を組み込むべき。 |

| Haney ら, *Safety perception and trust during human-AMR interaction* | 2024 | AMR/HRI | 実安全だけでなく、予測可能な挙動と信頼形成が重要と整理。 citeturn13search2 | 導入時のUX設計、挙動説明、表示・音・速度制御が重要。 |

| Marcus ら, *IDEAL framework for surgical robotics* | 2024 | 医療ロボット | 開発・比較評価・長期監視の臨床評価フレームを提示。 citeturn28view3 | 承認後の registry と real-world evidence を前提に設計すべき。 |

| Adesiji ら, *Safety considerations in deployment of robotic systems* | 2025/2026 | 横断レビュー | 包括的リスク評価、アルゴリズム、安全機能、障害物回避等の重要性を整理。 citeturn12search5turn12search14 | 安全要件は設計時だけでなく現場実装時に再評価すべき。 |

| Belzile ら, *From Safety Standards to Safe Operation with Mobile Robotic Systems Deployment* | 2025 | 移動ロボット | 建設現場を例に、既存規格の空白を埋める定量的評価枠組みを提案。 citeturn28view5 | 非定型環境では ODD と現場危険源を結びつける独自評価が必要。 |

| Khan ら, *A Systematic Review of Safety-Driven Approaches in HRC Systems* | 2026 | HRC/AI | ハード・制御・認知・倫理を接続する安全分類を提示。 citeturn12search0turn12search6 | AI搭載HRCでは物理安全と倫理・運用統治を分離できない。 |

学術的な合意点は比較的明確である。まず、**安全はライフサイクル特性**であり、設計審査だけで完結しない。次に、**人間監督は残るが、曖昧な“人が見るから安全”では不十分**で、役割分担・介入条件・情報提示を明示しなければならない。さらに、**移動ロボット、家庭ロボット、医療ロボットは、工場ロボットよりも ODD が不安定で、リスク評価と市販後監視の重要性が高い**。このため、今後の研究の本丸は、接触力制御単体ではなく、実環境ログ、近接挙動、アップデート後検証、サイバー攻撃耐性を組み込んだ“継続的安全保証”にあるといえる。これは学術レビューと医療・自動運転の規制文書の方向性とも一致している。 citeturn28view1turn13search2turn28view3turn35view1turn26search1

## 法規制・ガイドラインの動向

主要地域の制度を比較すると、**EU は包括・予防型、米国は分散・実務型、日本は既存法制＋基本法型、中国は標準・表示・部門監督型、英国は部門別リスクベース型**と整理できる。以下の表は 2024–2026年の主要な動きを比較したものである。 citeturn29view0turn31view1turn35view0turn7search2turn41view1

```mermaid

timeline

    title 近年の主要な法改正・提案

    2023 : EU Machinery Regulation 2023/1230 採択

         : ISO 31101 発行

    2024 : EU AI Act 発効

         : EU Cyber Resilience Act 採択

         : EU Product Liability Directive 発効

         : 中国 GB/T 20867.1-2024 公布

         : 米国 NHTSA が AV STEP を提案

    2025 : 日本 AI法 公布・全面施行

         : EU AI Act 禁止事項適用開始

         : 英国 Product Regulation and Metrology Act 2025 成立

         : 中国 生成AI生成合成内容標識办法 公布

         : 中国 GB/T 45502-2025 公布

         : 米国 ANSI/A3 R15.06-2025 公表

    2026 : EU 高リスクAI実装時期を巡る調整提案継続

         : 英国 HSE が cobot 共同ガイダンス策定プロジェクト開始

         : 中国 自動驾驶系统安全要求 の強制国家標準案が進行

```

| 地域 | 現状 | 2024–2026年の重要動向 | 含意 |

|---|---|---|---|

| 日本 | 産業用ロボットは労安衛則・特別教育で運用。AI 横断では 2025年 AI法が成立し、指針整備が進行。自動運転は MLIT が性能・冗長性・安全評価を明確化。 citeturn37search0turn37search1turn7search2turn29view3turn36view0 | AI法は 2025年6月公布・9月全面施行。MLIT の 2025年レベル4ガイドラインは冗長構成、安全評価、交通参加者も含む安全確保を明示。 citeturn7search2turn7search8turn36view0 | 日本は既存の機械・道路・医療制度に AI 基本法を上乗せする構造。事業者は“法遵守”よりも“指針適合＋説明責任”の比重が高い。 |

| EU | AI Act が AI を、Machinery Regulation が機械を、CRA が製品サイバーを、PLD が損害賠償を規律。高リスクAIには適合性評価、品質管理、人間監督、頑健性、サイバー要件が課される。 citeturn29view0turn32view0turn29view2turn21search9turn29view11 | AI Act は 2024年8月発効。禁止事項は 2025年2月から、GPAI 義務は 2025年8月から。高リスク製品組込みAIは 2027年8月基準で、調和規格の遅れにより 2025–2026年に時間軸調整提案が進行。Machinery Regulation は 2027年1月適用。 citeturn32view0turn8search7turn8search8 | 最も包括的。ロボット企業は AI・機械・サイバー・責任法を横断して適合設計する必要がある。 |

| 米国 | OSHA、NIST、FDA、NHTSA が分担する分散型。OSHA はロボット危険認識と OTM を提示、NIST は AI RMF を任意指針として整備、FDA は AI医療機器と医療サイバー、NHTSA は ADS 透明性・事故報告を強化。 citeturn38view0turn34search8turn34search10turn35view0turn35view1turn40search2 | NHTSA は 2024–2025年に AV STEP を提案し、2025年改正 Standing General Order を発効。FDA は 2025年に AI-enabled device lifecycle draft、2026年に human factors 情報提出の最終ガイダンスを公表。 citeturn40search1turn40search5turn35view0turn25search9 | 包括法はないが、実務的には最も細かな sector guidance が蓄積。証拠文書・事故報告・市販後対応が重い。 |

| 中国 | ロボットは国家標準と部門別規制が中心。工業ロボット安全、サービスロボット情報セキュリティ、生成AI表示、智能网联汽车安全要求の標準化が並行。 citeturn29view6turn29view7turn41view1turn24search12 | GB/T 20867.1-2024 は 2025年3月施行、GB/T 45502-2025 は 2025年10月施行。2025年の《人工智能生成合成内容标识办法》は顕示・隠示標識を規定。2026年には自動驾驶系统安全要求の強制国家標準案が進む。 citeturn29view6turn29view7turn41view1turn24search12 | 物理安全と情報安全を同時に強める方向。規格主導の実装適合が重要。 |

| 英国 | HSE の goal-setting 型安全法制と、製品安全更新権限を与える 2025年法が中心。AI そのものは sectoral regulation 路線。 citeturn31view0turn31view1 | Product Regulation and Metrology Act 2025 は新技術対応のための更新権限を整備。HSE は 2026年に cobot 向け初の共同産業ガイダンス作成を開始。OPSS は 2024年に AI consumer product safety 研究の更新を公表。 citeturn31view0turn31view2turn31view3turn31view4 | 実装支援型のガイダンスが増えるが、EUのような包括適合性制度には至っていない。 |

| 国際機関 | UNECE は車両系ロボットで最も具体的。UN R155/156/157 がサイバー、ソフト更新、自動運転機能をカバー。ISO/IEC/IEEE は横断的な技術規範を整備。 citeturn11search0turn11search1turn11search2turn10search0turn15search12 | UN R155 は vehicle cybersecurity、R156 は software update management system、R157 は ALKS における安全実証を要求。 citeturn11search28turn11search0turn11search1turn11search26 | 特に自動車・道路ロボットでは、国家法より国際ルールと型式認証の影響が大きい。 |

EU の特徴は、AI Act がロボットを単独で規制するのではなく、**「安全コンポーネントとしての AI」**を既存の製品安全法制に接続した点にある。高リスク AI システムは、リスク管理、データ品質、文書化、透明性、人間監督、正確性、サイバーセキュリティ、頑健性を満たし、適合性評価を受ける必要がある。医療分野では MDR/IVDR と AI Act の**同時かつ補完的適用**が明示され、品質マネジメントや市販後監視の統合が求められている。 citeturn32view0turn39view5turn33view0

日本では、産業用ロボットの安全確保は依然として労働安全衛生規則と特別教育が基盤であり、危険防止措置の運用面は継続して重要である。一方で AI 法制は 2025年に大きく進み、内閣府は AI法の下で基本計画・適正性確保指針・AI戦略本部を整備している。2025年の MLIT ガイドラインは、レベル4自動運転について、**冗長構成、危険事象認知、危機回避制御、交通参加者を含めた安全確保**を明文化しており、ロボット安全論が「単体機械」から「社会システム」に拡張したことを示している。 citeturn37search0turn37search1turn7search2turn36view0

米国は、統一ロボット安全法があるというより、**用途ごとの証拠と監督**を積み上げる構造である。OSHA はロボット危険認識を、NIST は AI RMF の Govern/Map/Measure/Manage を、FDA は AI-enabled 医療機器の lifecycle と SPDF を、NHTSA は ADS の事故報告・透明性制度を強めている。これは実務的には柔軟だが、企業側には部門横断のコンプライアンス統合能力が必要になる。これは EU と違う形の高コスト構造である。 citeturn38view0turn34search2turn35view0turn35view1turn40search1turn40search2

## 産業基準・企業実務・安全レポート

産業界の実務は、規制文書よりも一歩先に、**安全ケース、形式方法、リスクベース設計、運用時モニタリング**へ進んでいる。自動車・自動運転では Waymo が Safety Framework と Safety Case を明示的に公開し、Mobileye は Responsibility-Sensitive Safety を「機械が安全に運転するとは何か」の形式モデルとして提示している。製造では Universal Robots が、協働用途では foreseeable misuse を含むリスク評価が必要であり、「cobot そのものが安全の全部ではない」と明確にしている。これは最新規格の方向性と整合的で、企業実務がすでに**安全を“製品機能”ではなく“システム証明”として扱い始めている**ことを示す。 citeturn16search0turn16search4turn26search1turn16search1turn16search16turn16search2turn16search10

| 分野 | 企業・文書 | 主な安全アプローチ | 評価 |

|---|---|---|---|

| 自動車・ロボタクシー | Waymo *Safety Framework / Safety Case* citeturn16search0turn16search4turn16search12 | 公開された Safety Framework と Safety Case、readiness criteria、論文ベースの evidence 評価。 | 規制当局・市民への説明可能性が高い。ロボット企業の将来形に近い。 |

| 自動車・ADAS/ADS | Mobileye *RSS / Safety Methodology* citeturn16search1turn16search9turn16search17 | 5つの安全ルールと安全エンベロープを形式化。 | 「安全の定義」を明文化する強みがあるが、社会的受容性・責任配分の議論と不可分。 |

| 製造・cobot | Universal Robots *Risk Assessment / Safety FAQ* citeturn16search2turn16search22turn16search18 | 衝突、誤使用、傷害重篤度、回避可能性を含むアプリケーション単位のリスク評価。 | 工場現場では最も実務的。導入担当者教育と測定の重要性が明確。 |

| 物流・AMR | Amazon Robotics / Amazon Science *functional safety certification for AMR* citeturn17search12turn18search2turn18search17 | AMR の機能安全認証可能性、倉庫内人間共存設計、自由走行ロボットの実装研究。 | AMR 安全の制度空白を企業側が先に埋めようとしている。 |

| サービスロボット | Starship *robots and road users / accessibility*、SoftBank Robotics *security considerations* citeturn18search3turn18search18turn18search1 | 歩行者・道路利用者との相互作用、安全優先の横断判断、サービスロボットのデータ・遠隔アクセス安全。 | サービスロボットでは物理安全と情報安全が同格で扱われ始めている。 |

| 医療ロボット | Intuitive Surgical Annual Report / FDA safety communications citeturn16search3turn16search19turn25search0turn25search4 | 患者安全・訓練・臨床エビデンス・風評リスク・回収リスクの管理。 | 医療ロボットでは訓練と市販後監視が安全の核心。 |

| 家庭用AIロボット | iRobot data security / Amazon Astro 関連公開情報 citeturn17search0turn17search16turn17search4 | 暗号化、在宅ナビゲーション、近接・駐機行動の HRI 研究。 | 家庭用は正式安全ケース公開が少なく、プライバシー・社会的受容が先行論点。 |

医療ロボットでは、規制・企業・学術の焦点がほぼ一致している。FDA は AI-enabled device lifecycle draft でライフサイクル管理を求め、サイバーガイダンスでは**“Cybersecurity is Part of Device Safety”** を明示し、人間工学文書では use-related risk の最小化を目標とする。Intuitive の年次報告でも患者安全や訓練不足に関するレピュテーション・訴訟・規制リスクが強く意識されている。つまり、医療ロボットの安全は、機械精度だけでなく、**ユーザインタフェース、臨床訓練、セキュリティ、アップデート、報告義務**の束として管理されている。 citeturn35view0turn35view1turn35view2turn16search3turn25search0

家庭用AIロボットとサービスロボットでは、まだ自動車や医療ほど成熟した公開安全資料は多くない。しかし、その代わりに、**プライバシーと情報安全を安全概念の中に含める**傾向が明確である。iRobot は暗号化・データ保護を前面に出し、SoftBank Robotics は商用サービスロボットで remote access management や data security を説明し、英国 OPSS の研究も AI consumer products の安全論点を市場・概念・リスク・規制の更新として整理している。ここでは「物理的にぶつからないこと」だけでは、もはや安全と呼べない。 citeturn17search0turn18search1turn31view3turn31view4

## 国際規格と採用状況

国際規格の最新動向を一言でいえば、**「設計安全」中心の規格群が、「運用安全」「AIガバナンス」「サイバー統合」を含む体系へ再編されつつある」**ということである。最重要の変化は、ISO 10218-1:2025 および ISO 10218-2:2025 が公表され、協働ロボット関連では ISO/TS 15066 の内容が 10218 シリーズへ取り込まれる方向が明示された点である。これにより、cobot 安全は単独 TS の“補足”ではなく、**工業ロボット安全の本流**へ位置づけ直された。サービスロボットでは ISO 31101:2023 が運用側の安全管理システム要求を定め、ISO/FDIS 13482 は personal care robot を超えた service robot safety への更新として進んでいる。 citeturn9search0turn15search0turn15search5turn29view8turn15search2turn29view9

| 規格・文書 | 最新状況 | 主な対象 | 採用・位置づけ |

|---|---|---|---|

| ISO 10218-1:2025 / -2:2025 | 発行済み。協働ロボットの考え方をシリーズに統合。 citeturn9search0turn15search0 | 産業用ロボット本体、ロボットアプリケーション・セル | 2025年改訂版が世界的基準。米国は ANSI/A3 R15.06-2025 として採用。 citeturn29view5 |

| ISO/TS 15066:2016 | 依然有効だが、内容の一部は 10218 系へ統合。 citeturn15search5turn15search18 | 協働ロボットの安全要求・痛覚閾値など | 今なお実務参照が多いが、今後は 10218 系との一体運用が中心。 |

| ISO 31101:2023 | 発行済み。 service robot application service の安全管理システム要求。 citeturn14search7turn14search8 | サービス事業者の運用安全 | 日本主導色が強く、運用者責任を規格化した点で画期的。 |

| ISO/FDIS 13482 | 開発中。サービスロボット安全へ拡張。 citeturn15search2turn29view9 | 個人向け・商用を含む service robots | 家庭用・介護・商用ロボットの規格空白を埋める本命。 |

| IEC 61508 系 | 現行の機能安全基盤。IEC も robotics safety で中核と位置付け。 citeturn9search1turn9search15 | E/E/PE 安全関連システム | ロボット固有規格ではないが、機能安全の共通土台。 |

| IEC 80601-2-77 / -2-78 | FDA 認知済み規格として運用。 citeturn25search14turn25search17turn14search15 | 手術支援ロボット、リハビリ医療ロボット | 医療ロボットの安全・必須性能の国際基盤。 |

| ISO/IEC CD TS 22440-1 | 開発中。AI と機能安全の接続。 citeturn15search12 | AI systems と functional safety | 今後の AI 搭載ロボット規格の中核候補。 |

| IEEE 7009-2024 / 7003-2024 / 2846-2022 | 発行済み。 citeturn10search0turn10search2turn10search3 | fail-safe 設計、アルゴリズムバイアス、ADS モデル仮定 | ISO/IEC を補完するガバナンス・倫理・形式モデル側の規範。 |

| UNECE UN R155 / 156 / 157 | 発効済み・改訂継続。 citeturn11search0turn11search1turn11search2turn11search13 | 車両サイバー、ソフト更新、自動車線維持 | 車両ロボティクスでは事実上の国際ルール。 |

採用状況にも差がある。米国では ANSI/A3 R15.06-2025 が ISO 10218:2025 を国内採用し、Part 3 で use of industrial robot cells を追加した。中国では工業ロボット安全の GB/T 20867.1-2024 が 2025年3月に、サービスロボット情報安全の GB/T 45502-2025 が 2025年10月に施行される。日本は JIS ベースの知見を使い ISO 31101 を主導し、EU は AI Act の下で harmonised standards を整備する方針だが、2026年時点で**規格策定の遅れが実施スケジュールに影響**している。つまり、標準の「有無」だけでなく、「調和規格が法令適合性の presumption をいつ与えるか」が実務の論点になっている。 citeturn29view5turn29view6turn29view7turn14search8turn29view1turn32view0

## リスク評価・安全設計と実装課題

安全設計の実務は、**本質安全設計・保護方策・情報提供**という古典的三層に、**安全ケース、冗長化、機能安全、サイバー統合、市販後監視**を接続する形に進化している。特に AI を含むロボットでは、単発のリスクアセスメントだけでは、学習データの偏り、アップデート後の挙動変化、遠隔接続、運用現場の変更に追随できない。このため、NIST AI RMF の Govern/Map/Measure/Manage、FDA の SPDF、Waymo/AVSC の safety case assessment は、いずれも**継続的安全保証**を前提にしている。 citeturn34search2turn34search8turn35view1turn26search1turn27search1

```mermaid

flowchart TD

    A[用途定義とODD設定] --> B[危険源同定]

    B --> C[リスク分析]

    C --> D[リスク評価]

    D --> E[安全要求割当]

    E --> F[設計対策]

    F --> G[検証と妥当性確認]

    G --> H[安全ケース作成]

    H --> I[運用開始]

    I --> J[監視・ログ・事故報告]

    J --> K[アップデート評価]

    K --> B

```

実務上の代表的手法は次のように整理できる。まず**フェイルセーフ**は、危険状態検出時に安全側へ遷移させる基本原則であり、IEEE 7009-2024 が自律・半自律システム向けの technical baseline を与えている。次に**冗長化**は、自動運転ガイドラインや UNECE 車両規則でも重視され、故障時でも安全機能を維持する構成として扱われる。第三に**安全ケース**は、主張・根拠・証拠を明示する説明構造で、Waymo や AVSC では評価方法まで公開が始まった。第四に**サイバーセキュリティ統合**は、医療では SPDF、車両では UN R155/156、EU では CRA の形で、もはや安全の外部条件ではなく安全要件そのものとなっている。 citeturn10search0turn36view0turn11search0turn11search1turn26search1turn27search1turn35view1turn21search9

最大の実装課題は四つある。第一に、**人間要因の形式化が難しい**。学術レビューでも、専門家依存型の危険源評価は HRC では限界があるとされ、認知負荷・驚き・過信・誤使用の扱いが未成熟である。第二に、**移動ロボットやサービスロボットの ODD が揺れる**。工場セルと違い、床状態、障害物、人流、照明、通信、家庭内レイアウトが頻繁に変わる。第三に、**アップデート後保証の不足**である。ソフト更新、学習モデル更新、クラウド連携は性能改善と同時に安全再評価を必要とする。第四に、**サイバーと安全の組織分断**で、現場では security team と safety team が別組織にあることが多く、脅威モデリングと危険源分析が統合されていない。これが実装遅延の主要因である。 citeturn28view1turn28view5turn31view4turn35view1turn11search1

この文脈では、**安全ケース**の価値が高い。安全ケースは、規則や試験項目のチェックリストでは説明できないシステム全体像、境界条件、データ制約、更新管理を、監査可能な形で表現できるからである。とくに高自律ロボットでは、十分性を「規格適合＝安全」と単純化しにくく、”どの主張が、どの証拠で、どの不確実性を残しているか”を構造化できる点が重要である。今後は、ロボット分野でも UL 4600 型の claim-based assurance に近い考え方が広がる可能性が高い。これは Waymo と AVSC の公開文書が先行的に示している。 citeturn26search1turn27search0turn27search8

## 影響・見通し・提言

短期では、法規制と規格更新は**開発速度をやや鈍らせる**。EU AI Act の適合性評価、FDA の AI-enabled device lifecycle 文書、NHTSA の事故報告、英国や中国の情報表示・製品安全更新は、いずれも文書化・試験・監査・ログ管理の負担を増やすからである。しかし中期では、これらはむしろ**市場拡大の条件**になる可能性が高い。なぜなら、人と空間を共有するロボットは、導入先の安全担当者・保険者・規制当局・消費者の信頼がなければ大規模普及しないからである。2025年の IFR 統計でも、産業ロボット設置台数は高水準を維持し、サービスロボット・医療ロボットも増勢にあるが、この普及の持続には安全・セキュリティ・責任の説明可能性が不可欠である。 citeturn35view0turn40search2turn31view3turn41view1turn19search4turn19search5

中期の見通しとしては、**規格と法令の接続**がさらに強まる。EU では harmonised standards が presumption of conformity の鍵であり、医療では MDR/IVDR と AI Act の補完が明示され、米国でも ANSI/A3 R15.06-2025 や FDA 認知規格が実務基盤になる。中国でも国家標準のスピード感が速く、英国でも HSE の共同ガイダンスづくりが始まった。これらを総合すると、2026–2030年は「ロボットをつくる能力」よりも、「**安全・法務・セキュリティを統合して市場投入する能力**」が差別化要因になる公算が大きい。これは研究にも影響し、論文の novelty だけでなく、データ統制、評価再現性、アップデート後保証、市販後監視への接続が求められるようになる。 citeturn29view1turn33view0turn29view5turn31view2turn29view6

長期では、ロボット規制は大きく三つの軸へ収斂すると考えられる。第一に**用途横断の AI/データガバナンス**、第二に**製品安全・機械安全・機能安全**、第三に**アップデート・サイバー・責任法**である。家庭用AIロボット、介護、公共空間 AMR、自動運転、医療ロボットは形が違っても、この三軸の束に包摂されていく可能性が高い。長期的な勝者は、単に高性能なモデルや低価格ハードを持つ企業ではなく、**証拠・監査・更新・事故対応を継続運用できる企業**になる。 citeturn21search9turn29view11turn35view1turn26search1turn32view0

実務者向けの提言は明確である。第一に、**安全、品質、セキュリティ、法務を単一プロセスで回す**こと。HARA/FMEA と脅威分析、SBOM、ログ、アップデート審査を一本化すべきである。第二に、**ODD と misuse を仕様書に書き切る**こと。第三に、**安全ケースを社内レビュー用にでも先に作る**こと。第四に、**人間監督の設計**を後工程に回さないことで、表示・速度・停止・引継ぎ・アラート・教育を user interface として扱うべきである。第五に、**市販後監視を研究段階から考える**ことで、遠隔ログ、near-miss、故障モード、再学習判定基準を最初から設計しておく必要がある。 citeturn34search2turn35view1turn35view2turn26search1turn16search2

政策立案者向けには、次の優先順位を勧めたい。第一に、**事故・ヒヤリハット・ソフト更新後不具合の共通報告枠組み**を整えること。第二に、**中小企業でも使える標準テンプレート**として、安全ケース、リスクアセスメント、SBOM、AI データシート、ヒューマンファクタ試験のひな型を提供すること。第三に、**国際規格と国内認証の往復を簡素化**すること。第四に、**規制サンドボックスと市販後監視を連動**させること。第五に、家庭用・サービスロボットについて、物理安全とプライバシー・サイバーを一体評価する枠組みを作ることである。現時点で最も制度的空白が大きいのは、この家庭・公共空間のロボットである。 citeturn40search2turn31view3turn29view1turn17search0turn18search1

## 主要出典リスト

以下は、本報告の判断に特に重い一次・公式ソースである。ユーザーの希望どおり、英日両言語の公式・一次情報を優先している。

| 種別 | 出典 | 年 | 主な用途 |

|---|---|---:|---|

| 日本政府 | 内閣府「人工知能関連技術の研究開発及び活用の推進に関する法律（AI法）」 citeturn7search2turn7search8 | 2025 | 日本の AI 基本法制 |

| 日本政府 | 経産省・AI事業者ガイドライン関連資料 citeturn29view3 | 2025–2026 | 日本の AI ガバナンス実務 |

| 日本政府 | 国土交通省「レベル4自動運転車の安全性確保に関するガイドライン」 citeturn36view0turn39view1 | 2025 | 自動運転ロボットの安全要求 |

| EU | European Commission「AI Act」および FAQ/標準化ページ citeturn29view0turn32view0turn29view1 | 2024–2026 | EU AI 規制の中核 |

| EU | Machinery Regulation 2023/1230、Cyber Resilience Act 2024/2847、Product Liability Directive 2024/2853 citeturn29view2turn21search9turn29view11 | 2023–2024 | 機械・サイバー・責任法 |

| EU | MDCG 2025-6 / AIB 2025-1 *Interplay between MDR/IVDR and the AI Act* citeturn33view0turn39view5 | 2025 | 医療ロボットと AI Act の接続 |

| 米国 | NIST AI RMF 1.0 / Playbook / AIRC citeturn34search8turn34search2turn34search10 | 2023–2026 | AI リスク管理の基本枠組み |

| 米国 | FDA AI-enabled device lifecycle draft、Cybersecurity guidance、Human Factors guidance citeturn35view0turn35view1turn35view2 | 2024–2026 | 医療ロボット・AI 医療機器安全 |

| 米国 | NHTSA AV STEP / Standing General Order / Automated Vehicle Safety citeturn40search1turn40search2turn40search6 | 2024–2025 | ADS/車両ロボットの監督 |

| 中国 | SAMR/国標委 GB/T 20867.1-2024、GB/T 45502-2025 citeturn29view6turn29view7 | 2024–2025 | 工業・サービスロボット安全と情報安全 |

| 中国 | CAC「人工智能生成合成内容标识办法」 citeturn41view1 | 2025 | AI 生成物の表示義務 |

| 英国 | HSE「AI に対する規制アプローチ」「cobot 共同ガイダンス」 citeturn31view1turn31view2 | 2025–2026 | 英国の sectoral safety approach |

| 英国 | Product Regulation and Metrology Act 2025 / OPSS AI product safety research update citeturn31view0turn31view3turn31view4 | 2024–2025 | 英国の製品安全更新 |

| ISO/IEC | ISO 10218:2025、ISO 31101:2023、ISO/FDIS 13482、ISO/IEC CD TS 22440-1 citeturn9search0turn15search0turn29view8turn29view9turn15search12 | 2023–2026 | 国際標準の最新動向 |

| IEEE | IEEE 7009-2024、7003-2024、2846-2022 citeturn10search0turn10search2turn10search3 | 2022–2024 | fail-safe・バイアス・ADS モデル仮定 |

| UNECE | UN R155/R156/R157 citeturn11search0turn11search1turn11search2turn11search26 | 2021–2025 | 車両ロボットの国際規則 |

| 学術レビュー | Giallanza ら 2024、Haney ら 2024、Marcus ら 2024、Adesiji ら 2025/2026、Khan ら 2026、Belzile ら 2025 citeturn28view1turn13search2turn28view3turn12search14turn12search0turn28view5 | 2024–2026 | 学術的な合意と未解決論点 |

| 産業界 | Waymo、Mobileye、Universal Robots、Intuitive、Amazon Robotics、Starship、SoftBank Robotics、iRobot の公式資料 citeturn16search0turn16search1turn16search2turn16search3turn17search12turn18search3turn18search1turn17search0 | 2021–2026 | 企業実務と公開安全アプローチ |

太平洋ゴミベルトの精密座標調査報告

# 太平洋ゴミベルトの精密座標調査報告

## エグゼクティブサマリー

本調査で最も重要だったのは、「太平洋ゴミベルトそのもの」や「その内部での漂流デブリ観測・回収活動」に結びつく**明示的な緯度経度**を、一次・公式ソースからどこまで落とし込めるか、という点でした。結論から言うと、公開ウェブ上で即検証できた高信頼の座標は、**The Ocean Cleanup の 2016 年 C-130 航空調査の航路端点、2018 年の System 001 配備予定点、2019 年の Maker Buoy 配備点、2018–2019 年の System 001 運用・観測点、2024 年の System 03 再配備点**に集中していました。これらは大きく見ると、**北緯 30–34 度・西経 141–148 度付近**に集まり、GPGP の平均中心が **約 32°N, 145°W** にあるという The Ocean Cleanup の説明とも整合します。citeturn11view0turn42view0turn14view3turn24view0turn22search0

一方で、**「検出された個々のプラスチック片・漁網 1 点ごとの GPS」**は、論文本文にはほとんど載っていません。むしろ本文側は、**正確な曳網座標やステーション情報は Figshare・補足資料・Supplementary Table にある**と記しており、公開 HTML / PDF テキストから直接拾えるのは、キャンペーン座標、航路端点、配備点、運用点が中心でした。したがって、本報告の表は厳密に言うと、**「公開ソースに明示された、GPGP 調査・回収・運用に紐づく精密座標」**の集成です。citeturn42view0turn16view0turn21view0

GPGP の広がりについては、NOAA/NCEI に登録された 2001–2012 年の東部太平洋表層プラスチック・データセットが、北太平洋亜熱帯循環内の**集積帯を 25–41°N, 130–180°W** と定義しています。さらに 2024 年の Environmental Science & Technology 論文は、SCUD モデルに基づく**「Eastern Garbage Patch」の主集積矩形を 30–35°N, 135–145°W** と描いており、The Ocean Cleanup の平均中心 **32°N, 145°W** と合わせると、**広域の作業用バウンディング・ボックス**と、**現場キャンペーンが密集するコア領域**の二層で捉えるのが最も妥当です。citeturn35view0turn29view0turn43view2turn11view0

また、**NASA/NOAA の公的な軌道衛星画像で、拡散した GPGP 本体がそのまま見える公開例**は、今回確認できませんでした。公式ソースが用いている主手法は、**表層ネット曳網、航空 RGB/LiDAR/SWIR、漂流ブイ、運用システム、モデル**です。The Ocean Cleanup 自身も、GPGP の規模推定に **652 回の表層ネット曳網と 2 回の航空調査**を用いたと説明しており、2018 年論文本文でも航空調査・曳網・ジオリファレンス処理が詳細に記載されています。したがって、各座標に付した「衛星」リンクは、**主として海面コンテキスト確認用**であり、デブリ本体の可視確認用途ではありません。citeturn11view0turn42view0

## 調査方針と証拠の扱い

本報告では、座標の性質を三つに分けて扱っています。**高信頼**は、論文・公式 PDF・公式投稿に**明示的に印字された点座標**で、かつ GPGP の観測・配備・調査に直接結びつくものです。**中信頼**は、明示座標であっても、**個別デブリの GPS ではなく、調査 transect の端点、船位、運用点、あるいは近似配備点**に留まるものです。**低信頼**は今回は極力避け、代わりに本文のパターン分析で「領域境界」や「平均中心」として扱いました。citeturn42view0turn12view0turn24view0turn35view0

各行の「リンク」は、**Google Maps の通常表示**と、**Google の衛星レイヤー表示**です。海上のため、表示されるのはほぼ海面コンテキストのみです。公式視覚証拠としては、The Ocean Cleanup の GPGP 解説ページ・2019 年の鯨観測ページ・2018 年 EIA 図版・2024 年 EST 論文図版の方が有用でした。2018 年 EIA の図版は、カリフォルニア沖西方に置かれた当時の仮配備点を示し、2024 年 EST 図版は、東部パッチを 30–35°N, 135–145°W の赤枠として描いています。citeturn43view1turn43view2turn40view0

## 明示的に公開された座標一覧

### 直接公開された調査・配備・運用座標

| 緯度 | 経度 | 日付 | 主体 / ソース | 検出・取得方法 | デブリ / 対象 | リンク | 信頼度 | 根拠 |

|---:|---:|---|---|---|---|---|---|---|

| 33.5000 | -141.4000 | 2016-10-02 | Lebreton et al. 2018, *Scientific Reports* DOI: 10.1038/s41598-018-22939-w citeturn42view0 | C-130 航空調査の西端点 | 浮遊プラ大型片を含む航空 survey 領域。本文では bundled net, loose net, container, rope, buoy/lid, unknown を記録。citeturn42view0 | [地図](https://www.google.com/maps?q=33.5,-141.4) · [衛星](https://www.google.com/maps?q=33.5,-141.4&t=k) | 中 | 端点は明示されているが、個別デブリ点ではなく transect 端点。 |

| 33.5000 | -134.9000 | 2016-10-02 | 同上 citeturn42view0 | C-130 航空調査の東端点 | 同上 | [地図](https://www.google.com/maps?q=33.5,-134.9) · [衛星](https://www.google.com/maps?q=33.5,-134.9&t=k) | 中 | 同上。 |

| 30.1000 | -143.7000 | 2016-10-06 | 同上 citeturn42view0 | C-130 航空調査の南西端点 | 同上 | [地図](https://www.google.com/maps?q=30.1,-143.7) · [衛星](https://www.google.com/maps?q=30.1,-143.7&t=k) | 中 | transect 端点。 |

| 32.9000 | -138.1000 | 2016-10-06 | 同上 citeturn42view0 | C-130 航空調査の北東端点 | 同上 | [地図](https://www.google.com/maps?q=32.9,-138.1) · [衛星](https://www.google.com/maps?q=32.9,-138.1&t=k) | 中 | transect 端点。 |

| 31.3800 | -145.3800 | 2019-05-15 | Sainte-Rose et al. 2023 / The Ocean Cleanup PDF citeturn14view3turn22search12 | Maker Buoy BP042 配備 | 漂流物アナログとしての drifter | [地図](https://www.google.com/maps?q=31.38,-145.38) · [衛星](https://www.google.com/maps?q=31.38,-145.38&t=k) | 高 | 配備点が論文本文に明示。 |

| 33.6500 | -142.6600 | 2019-06-26 | 同上 citeturn14view3turn22search12 | Maker Buoy BP002 配備 | 漂流物アナログとしての drifter | [地図](https://www.google.com/maps?q=33.65,-142.66) · [衛星](https://www.google.com/maps?q=33.65,-142.66&t=k) | 高 | 配備点が論文本文に明示。 |

| 31.5000 | -141.5000 | 2018-07-02 公表 | The Ocean Cleanup 2018 EIA Table 2-2 citeturn12view0turn23search3turn43view1 | 配備予定位置の近似値 | 東部 GPGP の buoyant plastic 回収システムの予定配備点 | [地図](https://www.google.com/maps?q=31.5,-141.5) · [衛星](https://www.google.com/maps?q=31.5,-141.5&t=k) | 中 | 明示座標だが「approximate deployment coordinates」。 |

| 31.5283 | -141.0725 | 2018-10-13 | *Protected Species Observations* PDF citeturn24view0 | OCS1 towing 時の船位 | OCS1 が収集を試みた buoyant plastic 域の運用点 | [地図](https://www.google.com/maps?q=31.528333,-141.0725) · [衛星](https://www.google.com/maps?q=31.528333,-141.0725&t=k) | 中 | 座標は明示だが、デブリ個別点ではなく船位。 |

| 30.7498 | -143.9105 | 2018-10-19 | 同上 citeturn24view0 | OCS1 operation 時の船位 | 同上 | [地図](https://www.google.com/maps?q=30.749833,-143.9105) · [衛星](https://www.google.com/maps?q=30.749833,-143.9105&t=k) | 中 | 同上。 |

| 30.4017 | -145.0672 | 2018-11-17 | 同上 citeturn24view0 | OCS1 operation 時の船位 | 同上 | [地図](https://www.google.com/maps?q=30.401667,-145.067167) · [衛星](https://www.google.com/maps?q=30.401667,-145.067167&t=k) | 中 | 同上。 |

| 29.8650 | -147.9600 | 2024 年公式投稿 | The Ocean Cleanup 公式 X 投稿 citeturn10search1turn22search0turn41search11 | System 03 再配備点 | cleanup system が再び GPGP に展開された位置 | [地図](https://www.google.com/maps?q=29.865,-147.96) · [衛星](https://www.google.com/maps?q=29.865,-147.96&t=k) | 中 | 座標は明示だが、今回取得した結果では投稿日表示が欠ける。 |

| 32.0000 | -145.0000 | 複数年平均 | The Ocean Cleanup GPGP page citeturn11view0 | モデル化された平均中心 | GPGP 平均中心 | [地図](https://www.google.com/maps?q=32,-145) · [衛星](https://www.google.com/maps?q=32,-145&t=k) | 中 | 「average patch center」であり個別観測点ではない。 |

### 運用ログ由来の補助座標

以下は、2018–2019 年の *Protected Species Observations* PDF に載る**船位・観測努力ログ**から拾えた、GPGP 運用域の補助座標です。価値は高いものの、**個別デブリ GPS ではなく、System 001 展開中の船位 / effort position** と理解すべきです。citeturn24view0

| 緯度 | 経度 | 日付 | ソース | 方法 | デブリ / 対象 | リンク | 信頼度 | 根拠 |

|---:|---:|---|---|---|---|---|---|---|

| 31.0782 | -143.0962 | 2018-10-15 | *Protected Species Observations* Appendix C citeturn24view0 | 観測 effort 船位 | OCS1 展開域の補助座標 | [地図](https://www.google.com/maps?q=31.078167,-143.096167) · [衛星](https://www.google.com/maps?q=31.078167,-143.096167&t=k) | 中 | effort position。 |

| 30.8555 | -143.8370 | 2018-10-17–18 | 同上 citeturn24view0 | 観測 effort 船位 | 同上 | [地図](https://www.google.com/maps?q=30.8555,-143.837) · [衛星](https://www.google.com/maps?q=30.8555,-143.837&t=k) | 中 | effort position。 |

| 30.8015 | -143.8887 | 2018-10-17–18 | 同上 citeturn24view0 | 観測 effort 船位 | 同上 | [地図](https://www.google.com/maps?q=30.8015,-143.888667) · [衛星](https://www.google.com/maps?q=30.8015,-143.888667&t=k) | 中 | effort position。 |

| 27.5212 | -145.4112 | 2018-12-26–31 | 同上 citeturn24view0 | 観測 effort 船位 | 同上 | [地図](https://www.google.com/maps?q=27.521167,-145.411167) · [衛星](https://www.google.com/maps?q=27.521167,-145.411167&t=k) | 中 | effort position。 |

| 27.9157 | -145.8735 | 2018-12-26–31 | 同上 citeturn24view0 | 観測 effort 船位 | 同上 | [地図](https://www.google.com/maps?q=27.915667,-145.8735) · [衛星](https://www.google.com/maps?q=27.915667,-145.8735&t=k) | 中 | effort position。 |

| 27.9097 | -145.8727 | 2019-01-01–08 | 同上 citeturn24view0 | 観測 effort 船位 | 同上 | [地図](https://www.google.com/maps?q=27.909667,-145.872667) · [衛星](https://www.google.com/maps?q=27.909667,-145.872667&t=k) | 中 | effort position。 |

| 24.7592 | -152.7592 | 2019-01-01–08 | 同上 citeturn24view0 | 観測 effort 船位 | 同上 | [地図](https://www.google.com/maps?q=24.759167,-152.759167) · [衛星](https://www.google.com/maps?q=24.759167,-152.759167&t=k) | 中 | effort position。 |

| 27.7820 | -146.3760 | 2019-01-03 | 同上 citeturn24view0 | 観測 effort 船位 | 同上 | [地図](https://www.google.com/maps?q=27.782,-146.376) · [衛星](https://www.google.com/maps?q=27.782,-146.376&t=k) | 中 | effort position。 |

| 26.6652 | -148.5095 | 2019-01-05–06 | 同上 citeturn24view0 | 観測 effort 船位 | 同上 | [地図](https://www.google.com/maps?q=26.665167,-148.5095) · [衛星](https://www.google.com/maps?q=26.665167,-148.5095&t=k) | 中 | effort position。 |

| 26.0277 | -149.8008 | 2019-01-05–06 | 同上 citeturn24view0 | 観測 effort 船位 | 同上 | [地図](https://www.google.com/maps?q=26.027667,-149.800833) · [衛星](https://www.google.com/maps?q=26.027667,-149.800833&t=k) | 中 | effort position。 |

| 25.5327 | -150.7807 | 2019-01-07 | 同上 citeturn24view0 | 観測 effort 船位 | 同上 | [地図](https://www.google.com/maps?q=25.532667,-150.780667) · [衛星](https://www.google.com/maps?q=25.532667,-150.780667&t=k) | 中 | effort position。 |

注記として、これら補助座標は**「その座標でデブリが見えた」ことを直接証明するものではありません**。ただし、System 001 が実際に GPGP で運用されていた最中の official effort position であり、**時系列上の drift / operation footprint を再構成するには実務上有用**です。citeturn24view0

## 空間パターンと海流との関係

公開されている明示座標を地理的に並べると、最も濃いクラスターは**北緯 30–34 度・西経 141–148 度**にあります。2016 年の航空 transect 端点、2018 年 EIA の近似配備点、2018–2019 年の System 001 の運用点、2019 年の Maker Buoy 配備点の多くが、この帯の中か、そのすぐ周縁に乗っています。したがって、**「公開一次ソースで最も座標密度が高い GPGP コア」は、少なくとも 30–34°N, 141–148°W 付近**と見るのが妥当です。citeturn42view0turn12view0turn14view3turn24view0

その一方、広域のバウンディング・ボックスはもっと大きいです。NOAA/NCEI の 2001–2012 年データセットは、東部太平洋の 2500 超の plankton net tows から、北太平洋亜熱帯循環内の集積帯を**25–41°N, 130–180°W**と要約しています。さらに 2024 年 EST 論文は、SCUD モデルで**Eastern Garbage Patch を 30–35°N, 135–145°W**の赤矩形として置き、そのすぐ西側に Western Garbage Patch、中央に Subtropical Convergence Zone を示しています。The Ocean Cleanup の一般解説は、これをならした平均位置として**約 32°N, 145°W**を挙げています。これらを合わせると、**広域 envelope = 25–41°N, 130–180°W、コア領域 = 30–35°N, 135–145°W、平均中心 = 32°N, 145°W**という三段階整理が最もしっくりきます。citeturn35view0turn29view0turn43view2turn11view0

この配置は海流構造とも整合的です。2024 年 EST 論文は、東部パッチが**北に North Pacific Current、東に California Current、南に North Equatorial Current、西に Kuroshio Current**で囲まれる北太平洋亜熱帯循環の中で高濃度化すると説明しています。NOAA/NCEI のメタデータも、集積帯が**表層海流の収束中心**に対応すると述べています。つまり、GPGP は「固定された島」ではなく、**循環場の内部に形成される、時間変動を伴う高濃度海域**です。citeturn29view0turn35view0

The Ocean Cleanup も、GPGP の位置と形は季節・年々変動すると明記しており、平均中心は 32°N, 145°W でも、実際の調査や運用点は 2018–2019 年の OCS1 ログが示すように**27–31°N, 145–150°W 方向へ南西寄りに広がる**ことがあります。今回の運用ログ補助座標がこの帯に伸びているのは、その変動性を具体的に示すものです。citeturn11view0turn24view0

公式図版を二つ挙げると、2018 年 EIA の地図は、当時の東部 GPGP 配置候補が**カリフォルニア西方の 31.5°N, 141.5°W 近辺**に置かれていたことを視覚化しています。2024 年 EST の図版は、研究船 SO268/3 の横断観測と、**30–35°N, 135–145°W の赤い矩形**を同じ図面に載せています。両図版を合わせると、**2018 年の工学配備想定と 2024 年の海洋観測モデル設定が、かなり近い空間を指している**ことが分かります。citeturn43view1turn43view2turn12view0turn29view0

日本語ソースでは、東京大学の 2021 年解説が、**日本近海西岸から北太平洋移行域を経て GPGP に運ばれる輸送**を説明し、JAMSTEC の 2024 年解説は、**北太平洋ゴミベルト下の水柱・深層にもプラスチックが分布する**ことを紹介しています。これらは座標リストの提供元ではありませんが、**日本語で得られる一次研究ベースの文脈情報**として有用でした。citeturn27search1turn27search2

## 視覚証拠とリンク

今回確認できた「視覚証拠」は、軌道衛星画像よりも、**航空画像・船上写真・図版**が中心でした。The Ocean Cleanup の GPGP ページは、Mega Expedition、Aerial Expedition、System 03 の船上写真や研究装置写真を集約しており、2019 年の “Whales likely impacted …” ページは、**2016 年航空調査の 2 本の transect と、デブリ近接を示す図**を含みます。2018 年論文本文も、RGB カメラで毎秒撮影した航空画像を**31 個の約 10 km² モザイク**にまとめ、そこから debris positions を記録したと書いています。citeturn11view0turn40view0turn42view0

代表リンクを、直接 URL 付きでまとめると以下です。

| 種類 | リンク | 用途 |

|---|---|---|

| 公式総説 | [The Ocean Cleanup GPGP page](https://theoceancleanup.com/great-pacific-garbage-patch/) | GPGP の平均中心、サイズ、遠征写真、研究の要約 |

| 査読論文 | [Lebreton et al. 2018, Scientific Reports](https://doi.org/10.1038/s41598-018-22939-w) | 2015 船舶曳網・2016 航空調査・1.6 million km² 推定 |

| 鯨とデブリ図版 | [Whales likely impacted by Great Pacific Garbage Patch](https://theoceancleanup.com/updates/whales-likely-impacted-by-great-pacific-garbage-patch/) | 2016 航空調査図と例示写真 |

| 深層フォールアウト | [Egger et al. 2020, Scientific Reports](https://doi.org/10.1038/s41598-020-64465-8) | Honolulu–Rosarito transect の水柱プロファイル |

| ネウストン比較 | [Egger et al. 2021, Frontiers](https://doi.org/10.3389/fmars.2021.626026) | 2015 / 2019 Manta trawl と NPGP 内外比較 |

| 漂流ブイ | [Sainte-Rose et al. 2023 / JMSE](https://www.mdpi.com/2077-1312/11/1/68) | 2019 Maker Buoy 配備点 |

| NOAA データセット | [NOAA NCEI Accession 0211008](https://www.ncei.noaa.gov/archive/accession/0211008) | 2001–2012 の東部太平洋表層プラスチック CSV/Excel |

| 2024 横断観測 | [Rynek et al. 2024, EST](https://doi.org/10.1021/acs.est.3c05039) | 北太平洋横断観測と東部パッチ矩形 |

| 2018 EIA PDF | [The Ocean Cleanup EIA 2018 PDF](https://assets.theoceancleanup.com/app/uploads/2019/04/TOC_EIA_2018.pdf) | 配備想定位置と曳航ルート図 |

| 2018–2019 運用ログ | [Protected Species Observations PDF](https://assets.theoceancleanup.com/app/uploads/2019/06/Protected-Species-Observations-The-Ocean-Cleanup-Report-Final.pdf) | GPGP 運用中の正確な船位ログ |

| 2024 運用投稿 | [System 03 coordinate post](https://x.com/TheOceanCleanup/status/1820839531748220961) | 明示的な日時不完全だが座標が明記された公式投稿 |

上のリンク群は、いずれも**一次研究・公式機関・公式運用記録**を優先して選んでいます。citeturn35view0turn12view0turn24view0turn14view3turn11view0turn40view0turn29view0turn22search0

## 主要観測の時系列

2001–2012 年には SEA/NOAA の長期曳網データが後に NCEI に整理され、集積帯の広域 envelope を定義しました。2015 年には The Ocean Cleanup が 30 隻・652 表層ネットの Mega Expedition を実施し、2016 年には C-130 による 2 本の航空 transect を行いました。2018 年後半には System 001 の GPGP 配備と、水柱プラスチックの 5 ステーション観測が行われ、2019 年には 2 基の Maker Buoy が精密座標で配備されました。さらに 2024 年には System 03 の再配備座標が公式投稿で示されました。citeturn35view0turn11view0turn42view0turn21view0turn14view3turn22search0

```mermaid

timeline

    title GPGP の主要観測・調査

    2001-2012 : SEA/NOAA の 2,500 超の表層 net tows

              : 広域集積帯 25–41°N, 130–180°W を定義

    2015-07 to 2015-09 : Mega Expedition

                       : 30 vessels / 652 surface nets

    2016-10-02 : C-130 Aerial Expedition transect 1

               : 33.5°N, 141.4°W → 134.9°W

    2016-10-06 : C-130 Aerial Expedition transect 2

               : 30.1°N, 143.7°W → 32.9°N, 138.1°W

    2018-09 to 2019-01 : System 001 GPGP deployment and observer logs

    2018-11 to 2018-12 : Honolulu → Rosarito 5-station water-column plastic profiling

    2019-05-15 : Maker Buoy BP042 deployed at 31.38°N, 145.38°W

    2019-06-26 : Maker Buoy BP002 deployed at 33.65°N, 142.66°W

    2024 : System 03 redeployed at 29°51.9'N, 147°57.6'W

```

## 不確実性と検証提案

最大のギャップは、**個々の debris object の緯度経度が、本文テキストではほとんど展開されていない**ことです。Lebreton et al. 2018 は、曳網の詳細情報が **Figshare** にあると明記し、Egger et al. 2021 は**各 Manta trawl の座標・日付・昼夜・海況・距離は Supplementary Material にある**と書き、Egger et al. 2020 も**各ステーションの座標と濾水量は Supplementary Table S1** にあると述べています。つまり、最終的な精密 GIS 化には、**本文だけでなく補足データ本体の回収が必須**です。citeturn42view0turn16view0turn21view0

そのため、検証と拡張の優先順位は明確です。第一に、**Lebreton et al. 2018 の Figshare データ**を回収して、2015 年の各 tow 開始・終了座標と、可能なら 2016 年航空モザイクの地理情報を取得すること。第二に、**Egger et al. 2021 の Supplementary Material**と **Egger et al. 2020 の Supplementary Table S1** を直接取得して、2019 年 NPM3 と 2018 年深層フォールアウト観測の各ステーションを GIS 化すること。第三に、**NOAA NCEI Accession 0211008** を CSV/Excel で落として、2001–2012 年の網羅的 tow point を再現することです。NCEI ページはデータが HTTPS / CSV / Excel で提供されると明記しています。citeturn35view0turn33view0

さらに、今回の The Ocean Cleanup の一般ページは、全参加船に GPS トラッカーを載せ、**各 tow の正確な位置が post-processing で確認された**と説明しています。したがって、研究部門に直接問い合わせられるなら、**2015 Mega Expedition towing log、2016 Aerial Expedition georeferenced mosaic database、2019 NPM3 tow coordinates、2024/2025 ADIS hotspot outputs、System 03 operational track**の提供可否を尋ねるのが最も効率的です。citeturn11view0turn42view0

NOAA 側では、NCEI の dataset point of contact がページに明記されており、さらに NOAA の Marine Microplastics portal は**CSV / JSON / GeoJSON / GIS-based map**でデータ提供すると記しています。したがって、再現性の高い検証フローとしては、**NCEI 0211008 のダウンロード → North Pacific 範囲での抽出 → GPGP broad box / core box へのクリップ → The Ocean Cleanup campaign coordinates との重ね合わせ**が最も堅実です。citeturn33view0turn39search12

最後に、今回の表のうち **System 001 の protected species observer 由来座標**は、あくまで**運用 proxy**であって、個別デブリ採取点ではありません。逆に言えば、**厳密な「debris item GPS」一覧を作るには、まだ補足データ取得の一手が必要**です。本報告はその前段として、**公開ソースから即検証できる精密座標と、その信頼度・用途の境界**を明確にしたものです。citeturn24view0turn42view0turn16view0turn21view0 

🚀DDA で弾道作り DDA（デジタル微分解析器）は、始点と終点を一定刻みで補間し、加算だけで直線や弾道の座標列を生成する手法。固定小数点実装に向きます。

 コンピュータグラフィックスにおいて、デジタルディファレンシャルアナライザ（DDA）は、始点と終点の間の区間にわたって変数を補間するために使用するハードウェアまたはソフトウェアです。DDAは、直線、三角形、多角形のラスタライゼーションに使用されます。DDAは非線形の関数に拡張することができ、例えば、遠近感のあるテクスチャマッピング、2次曲線、ボクセルのトラバースなどに使用されます。

https://en.wikipedia.org/wiki/Digital_differential_analyzer_(graphics_algorithm)

DDA方式は、浮動小数点演算または整数演算を使用して実装することができます。ネイティブの浮動小数点実装では、補間値（座標x、y、深度、色成分など）および出力結果ごとに1回の加算と1回の丸め演算が必要です。この処理は、高速な加算と丸め演算が可能なFPUが利用できる場合にのみ効率的です。
固定小数点整数演算では、1回の出力サイクルあたり2回の加算が必要で、小数部のオーバーフローが発生した場合には、さらに1回の加算と減算が必要となる。分数部オーバーフローの確率は、補間開始値/終了値の比mに比例する。
DDAはハードウェア実装に適しており、スループットを最大化するためにパイプライン化することができる。

DDA – Digital Differential Analyzer line algorithm C++ Code - Educative SiteDDA - Digital Differential Analyzer line algorithm C++ Code - Educative SiteDDA - Digital Differential Analyzer line algorithm C++ Code Leducativesite.com

DDA Line generation Algorithm in Computer Graphics - GeeksforGeeksA Computer Science portal for geeks. It contains well writtenwww.geeksforgeeks.org

DDA（Digital Differential Analyzer）は、コンピュータグラフィックスで使用される線画アルゴリズムで、指定した2つの端点間の線分を生成する。これは、2つの端点のx座標とy座標の増分差を使って線を描くシンプルで効率的なアルゴリズムです。
DDA線生成アルゴリズムに関わるステップは以下の通り：
線分の2つの端点、(x1,y1)と(x2,y2)を入力する。
端点のx座標とy座標の差をそれぞれdxとdyとして計算。
直線の傾きを m = dy/dx として計算する。
直線の初期点を(x1,y1)とする。
直線のx座標をループし、毎回1ずつ増加させ、対応するy座標を方程式y = y1 + m(x - x1)を使って計算する。
計算された(x,y)座標のピクセルをプロットする。
終点(x2,y2)に達するまでステップ5と6を繰り返す。
DDAアルゴリズムは比較的簡単に実装でき、計算効率も高いため、リアルタイムアプリケーションに適しています。しかし、縦線を扱えない、浮動小数点演算が必要でシステムによっては処理速度が遅くなるなどの制限がある。それにもかかわらず、コンピュータ・グラフィックスで線を生成するための一般的な選択肢であり続けている。

MSXとNMRA

 MSXは1983年に提唱された8ビットパソコンの共通規格である。複数メーカーが同一規格のハードウェアを製造し、ソフトウェア資産を共有できることを特徴としていた。日本、オランダ、スペイン、ブラジルなどで普及し、ゲーム開発やプログラミング教育の入口として利用された。現在の商業市場としてのMSXは極めて小さいが、文化圏としては継続している。

愛好家市場の持続性を考える際には、利用者数よりも再生産活動の有無が重要になる。鉄道模型市場はその代表例である。米国の専門誌『Model Railroader』は1934年創刊以来発行が続いている。National Model Railroad Association（NMRA）は1935年設立で、現在も会員組織として活動している。市場規模は限定的であっても、雑誌、規格、イベント、コミュニティが継続することで文化圏が維持されている。

MSXにも同様の特徴が見られる。MSXdevは2003年から続くMSX向けゲーム開発コンテストであり、2026年大会では50本の新作ゲームが公開された。これは保存活動だけでなく、新規制作活動が継続していることを示している。また、MSX Resource Centerをはじめとするコミュニティサイトでは、技術情報の共有やソフトウェア公開が続けられている。

近年はMSX0やMSX3 Projectといった新しい取り組みも進められている。これらは1980年代の環境をそのまま再現することだけを目的とせず、現代のネットワーク環境や小型コンピュータとの接続を試みている。愛好家市場では、新規参入者の入口を維持することが重要であり、こうした活動は文化継承の基盤として機能している。

愛好家市場を評価する際には、市場規模や成長率だけでは実態を把握しにくい。継続的なイベント開催、新作の供給、情報発信、後継者育成といった活動が重要な指標となる。MSXは商業市場としては縮小したが、新作ゲーム開発、コミュニティ運営、規格継承の活動が現在も続いている。こうした点から見ると、MSXはレトロコンピューティング文化の一分野として維持されており、愛好家市場の持続性を観察する事例として位置付けることができる。

https://www.trains.com/mrr/

Model Railroader (MR) is an American magazine about the hobby of model railroading. Founded in 1934 by Al C. Kalmbach, it is published monthly by Firecrown Media of Chattanooga, Tennessee. Commonly found on newsstands and in libraries, it promotes itself as the oldest magazine of its type in the United States, although it is the long-standing competitor to Railroad Model Craftsman, which - originally named The Model Craftsman - predates MR by one year.

もつれ現象としてハルシネーションをとらえた例はありますか？

 AIハルシネーションそのものを、物理的な量子もつれ現象として説明する信頼できる主流研究は、現時点では見つかりませんでした。

ただし、かなり近い周辺領域はあります。
それは 量子認知 quantum cognition と LLM言語における量子的構造 quantum structure in AI language です。ここでは、概念の組み合わせが古典確率では説明しにくく、Bell 不等式違反や Hilbert 空間モデルで扱える、という議論があります。しかしこれは、LLMのハルシネーション原因を「物理的な量子もつれ」とするものではありません。量子認知の説明でも、量子形式の使用は基本的に数理モデルであり、脳やAI内部に微視的な量子過程があることを前提しない、とされています。

見つかった最も近い例

1. LLMの概念結合に Bell 不等式違反を見た研究

2025年の arXiv 論文 Identifying Quantum Structure in AI Language は、ChatGPT と Gemini を対象に概念結合テストを行い、Bell 不等式の有意な違反を報告しています。著者らは、これはテストされた概念に「quantum entanglement」が存在することを示す、と述べています。さらに、大規模テキスト中の語の分布にも Bose-Einstein 型の統計が見られると主張し、AI言語にも「量子的構造」が現れると論じています。

ただし、これは ハルシネーション研究ではありません。対象は「LLMが概念をどう組み合わせるか」であり、「なぜ嘘を生成するか」ではありません。したがって、ユーザーさんの問いに対しては「かなり近いが、ハルシネーションそのものではない」と評価するのが妥当です。

2. 量子認知における概念もつれ

Aerts と Sozzo の 2011年論文 Quantum Structure in Cognition は、複数の概念が結合すると「entanglement」が自然に現れるとし、Bell 不等式を構成して被験者実験で違反を示した、と報告しています。これは「概念A」と「概念B」を独立成分として合成できず、結合概念が非分解的なふるまいをする、という意味での量子もつれモデルです。

2013年の Quantum Entanglement in Concept Combinations では、概念結合データを標準的な量子理論規則でモデル化し、状態だけでなく測定や時間発展も entangled として扱う枠組みを提示しています。これもAIハルシネーションそのものではありませんが、「意味の結合が古典的な合成でなく、量子もつれ的に振る舞う」という理論的前史として重要です。

3. LLM圧縮への「generalized quantum entanglement」

2024年の SEE: Sememe Entanglement Encoding は、Transformer系モデル圧縮に「generalized quantum entanglement」を用いると述べています。低次元の意味素 sememe から高次元の単語埋め込みを再構成する、という圧縮手法です。

ただし、これも ハルシネーション説明ではありません。量子もつれ的な数理をモデル圧縮に使う例であって、LLMが事実誤認を生成する理由を量子もつれで説明しているわけではありません。

標準的なハルシネーション説明との違い

OpenAI の 2025年論文・解説では、ハルシネーションは「モデルが不確実なときに推測し、もっともらしいが誤った文を出す現象」と定義され、原因は主に 事前学習で真偽ラベルなしに言語分布を学ぶこと と、評価が不確実性の表明より推測を報いること に置かれています。ここでは量子もつれは説明原理として使われていません。

したがって、厳密に言うと現状はこうです。

区分	ハルシネーション説明か	量子もつれか	評価
物理的量子もつれでAIハルシネーションを説明	ほぼ該当例なし	はい	主流研究としては確認できず
量子認知で概念結合を説明	いいえ	数理モデルとしてはい	関連は深いが別問題
LLMの概念結合に Bell 不等式違反を見る研究	いいえ	数理的には近い	ハルシネーション研究ではない
semantic entanglement / disentanglement 系	はい	いいえ	前回広げすぎた範囲
OpenAI等の標準的説明	はい	いいえ	統計・評価制度・不確実性の問題

まとめ

「ハルシネーション＝量子もつれ」とする信頼できる研究例は、現時点ではかなり乏しいです。
一方で、LLMの概念結合や意味生成が量子認知的な Bell 不等式違反を示す という研究は出ています。ここから慎重に言えるのは、次の範囲までです。

AIハルシネーションを直接の量子もつれ現象と見るのは、まだ根拠が薄い。
しかし、LLMの意味空間や概念結合に量子認知的な非古典構造があるなら、ハルシネーションを「古典的な事実検索の失敗」だけでなく、「文脈・概念・測定条件に依存する意味生成の破綻」として再記述する研究余地はある。

つまり、これはまだ「実証済みの説明」ではなく、量子認知からハルシネーション論へ橋を架けられるかもしれない未開拓領域です。

SPDXはライセンス名を標準化した識別子で記す規格

 SPDXはライセンス名を標準化した識別子で記す規格で、表記ゆれを無くし依存関係収集やNOTICE自動化を容易にします。導入は、リポジトリ直下にLICENSE、各ソース先頭へSPDXヘッダ、依存ライセンスを識別子へ正規化、NOTICEをテンプレ化し生成、の順が最短。識別子は単一「MIT」、選択「GPL-2.0-or-later OR MIT」、併用「BSD-2-Clause AND MIT」、例外「… WITH …」を用います。NOTICEは再配布時に帰属が必要な依存のみ列挙し、著作権表示と必須文言を抜粋。自動化はロックファイルから依存を列挙し、識別子・著作権者・NOTICE要否を抽出してテンプレに差し込みます。運用では識別子変換表を整え、本文同梱要件と配布モデルを確認。SBOM出力やREUSE準拠も有効です。

SPDX – Linux Foundation Projects Sitespdx.dev

SPDXSPDX is an open standard for communicating SBOM information,github.com

Q1. SPDXとは何ですか？
ソフトウェアのライセンス名を統一ルールで書くための“共通表記”です。

Q2. 何が便利になりますか？
表記ゆれが無くなり、ライセンス確認や配布時の書類作成が楽になります。

Q3. まず何をすれば良いですか？
プロジェクトにLICENSEファイルを置き、各ソースの先頭に識別子を入れます。

Q4. 識別子って何ですか？
MITやApache-2.0のような短い決まり文句です。正式名ではなく識別子を書きます。

Q5. 書き方の例はありますか？
SPDX-License-Identifier: MIT の一行をファイル先頭のコメントに入れます。

Q6. 複数のライセンスが選べる場合は？
ORでつなぎます。例 GPL-2.0-or-later OR MIT。

Q7. 両方の条件を守る必要がある場合は？
ANDでつなぎます。例 BSD-2-Clause AND MIT。

Q8. 例外付きとは何ですか？
特定の追加条件がある場合です。WITHで書きます。

Q9. NOTICEとは何ですか？
配布物に同梱する「著作権表示のまとめ」です。必要な帰属文を一覧にします。

Q10. いつNOTICEが必要ですか？
再配布する時に、著作権表示や免責文の掲示が求められるライセンスを含む場合です。

Q11. MITやBSDでもNOTICEは要りますか？
基本は著作権表示の維持が必要です。NOTICEにまとめると分かりやすいです。

Q12. 依存ライブラリはどう扱いますか？
それぞれのライセンスを調べ、識別子で記録し、必要な表示だけNOTICEに載せます。

Q13. 社外公開しない社内利用でも必要ですか？
確認が容易になるため有益です。将来の公開や配布に備えられます。

Q14. ライセンス本文は同梱が必要ですか？
多くの場合は必要です。LICENSEフォルダなどにまとめて入れます。

Q15. 迷った時はどうすれば良いですか？
公式のSPDXライセンス一覧で識別子を確認し、配布条件はガイドや法務に相談します。

Q16. 導入の最小セットは何ですか？
LICENSE設置、各ファイルの識別子、必要に応じたNOTICEの三点です。

Q17. 既存プロジェクトへの導入は難しいですか？
段階的で大丈夫です。新規ファイルから識別子を入れ、主要部分から順に整備します。

Q18. ミスでよくあることは？
識別子の綴り違い、選択と併用の混同、LICENSE未同梱、NOTICEの過不足です。

Q19. 自動化はできますか？
できます。依存情報を集めてNOTICEの下書きを作る簡単なスクリプトでも十分役立ちます。

Q20. これで法的リスクは無くなりますか？
SPDXは表記の標準化です。最終的な適法性は配布形態と各ライセンスの要件確認が必要です。

👓SWIFTでCannot assign to property: 'self' is immutableとはどういう意味ですか？

 Cannot assign to property: 'self' is immutable というエラーメッセージはSwiftで見られるもので、これはオブジェクトのプロパティや自身の値を変更しようとした際に、そのオブジェクトが不変（immutable）であることを示しています。具体的には、以下のような状況でこのエラーが発生することが一般的です：

1. 構造体のインスタンスが定数として宣言されている場合: Swiftの構造体は値型であり、インスタンスが定数（let で宣言された）として作成された場合、そのプロパティは変更できません。

2. 関数やメソッド内でのselfの不変性: 値型（例えば構造体）のメソッド内で、self 自体を変更しようとした場合にもこのエラーが発生します。これを回避するためには、メソッドを mutating として宣言する必要があります。

3. このエラーは、Swiftの値型と参照型の基本的な特性に関連しています。値型のインスタンスは、不変性が保証されている場合にはその状態を変更することができません。これに対し、参照型（例えばクラス）の場合、定数としてインスタンスを宣言しても、そのプロパティを変更することが可能です。

SwiftUIのビューは構造体であるべきで、それはデフォルトで不変であることを意味します。これが私たち自身のコードであれば、値を変更することをSwiftに伝えるためにmutatingを使用してメソッドをマークすることができますが、SwiftUIでは計算されたプロパティを使用するため、それを行うことはできません。
プログラムの実行中にプロパティの値を変更したい場合は、次のように@Stateを使用してマークする必要があります：

https://www.hackingwithswift.com/quick-start/swiftui/how-to-fix-cannot-assign-to-property-self-is-immutable

Amazon.co.jp: iOS/macOS UIフレームワーク SwiftUIプログラミング eBook : 掌田津耶乃: Japanese BooksAmazon.co.jp: iOS/macOS UIフレームワーク SwiftUIプログラミング eBook : 掌田津耶amzn.to