| 接続先デバイス | デバイス側ピン名 | S3 GPIO番号 | 機能 / 備考 |
| I2Sマイク | WS / LRC | 38 | I2S ワードセレクト |
| (入力) | SCK / BCLK | 39 | I2S ビットクロック |
| SD / DATA | 40 | I2S シリアルデータ入力 | |
| タッチパネル | T_DO (MISO) | 41 | SPI MISO (タッチ用) |
| (XPT2046) | T_CLK | 42 | SPI クロック (タッチ用) |
| T_CS | 1 | チップセレクト (タッチ用) | |
| T_DIN (MOSI) | 2 | SPI MOSI (タッチ用) | |
| 液晶本体 | SCLK | 3 | SPI クロック (液晶用) |
| (ILI9341) | MOSI | 45 | SPI MOSI (液晶用) |
| MISO | -1 | (使用しない) | |
| CS | 14 | チップセレクト (液晶用) | |
| DC / RS | 47 | データ/コマンド制御 | |
| RESET | 21 | ハードウェアリセット |
CPUはESP32-S3-N16R8 ちょっともったいない気がする。
完成した Ver 11.2 のプログラムに基づき、納品物としての**「納入仕様書」および、内部構造を解説する「技術資料（ブロック遷移・フロー）」**を作成いたしました。
適用: ESP32 RSS Reader Project 版数: Ver 11.2 (Final Release) 日付: 2025/12/11
本システムは、ESP32マイコンとOLEDディスプレイを用い、インターネット経由でニュース（RSS）を取得・表示する情報端末である。HTTPS通信に対応し、3つのニュースソースを巡回表示する機能に加え、時計・カレンダー機能を有する。また、スマートフォン経由でWi-FiおよびRSS接続先の設定が可能である。
本システムの内部ロジック、状態遷移、およびデータフローについて解説する。
本ソフトウェアは、機能を**「メインアプリ（RSS表示）」と「システム設定モジュール」**に完全に分離したモジュール構造を採用している。
graph TD
subgraph "Hardware Layer"
HW_BTN[Button (GPIO 0)]
HW_OLED[OLED Display]
HW_WIFI[Wi-Fi Module]
HW_FLASH[NVS Memory]
end
subgraph "Software Logic (Ver 11.2)"
BOOT[Boot Loader / Setup]
subgraph "Mode Selector (起動分岐)"
CHECK_BTN{ボタン押下?}
CHECK_DATA{設定データ有?}
CHECK_CONN{接続成功?}
end
subgraph "Module A: System Configurator"
AP_MODE[AP Mode Start]
WEB_SVR[Web Server / Portal]
WAIT_USR[User Input Wait]
SAVE[Save to NVS]
end
subgraph "Module B: Main Application"
INIT_NET[Connect WiFi / NTP]
RSS_FETCH[Fetch RSS (HTTPS)]
RSS_PARSE[Parse XML]
DISP_CTRL[Display Controller]
end
end
%% Flow Connections
HW_BTN --> BOOT
BOOT --> CHECK_BTN
CHECK_BTN -- YES --> AP_MODE
CHECK_BTN -- NO --> CHECK_DATA
CHECK_DATA -- Empty --> AP_MODE
CHECK_DATA -- Exist --> CHECK_CONN
CHECK_CONN -- Fail(x10) --> AP_MODE
CHECK_CONN -- Success --> INIT_NET
AP_MODE --> WEB_SVR --> WAIT_USR --> SAVE --> HW_FLASH
INIT_NET --> RSS_FETCH --> RSS_PARSE --> DISP_CTRL --> HW_OLED
システムは大きく分けて「起動シーケンス」「設定モード」「通常稼働モード」の3つのフェーズで遷移する。
Power ON / Reset
起動待機 (5秒): プログレスバー表示。ボタン押下を監視。
分岐判定:
ボタンON または 設定なし → 設定モードへ (一方通行)
ボタンOFF かつ 設定あり → 通常モードへ
このモードに入ると、電源リセット以外での脱出は不可能（無限ループ待機）。
State 1: 初期化
WDT停止、Wi-Fi設定の強制切断(Disconnect)、APモード起動。
State 2: 待機 (Portal)
State 3: 保存 (Save)
ユーザーがブラウザで「Save」を押下。
データをFlash(Preferences)に書き込み。
システム再起動 (Reboot)。
loop() 関数内で管理されるステートマシン。
State A: START_TOPIC
記事タイトルとソース名を描画バッファにセット。3秒停止。
Next -> V_SCROLLING
State B: V_SCROLLING
1ラインずつ上方向へスクロール。
最終行まで表示したら停止。
Next -> END_TOPIC
State C: END_TOPIC
読み終わった状態で2秒停止。
Next -> H_SCROLLING
State D: H_SCROLLING
画面全体を左へスライドアウト（ワイプ効果）。
次の記事があれば State A へ。
全記事終了なら State E へ。
State E: CLOCK_MODE
アナログ時計/デジタル時計/カレンダーを描画。
20秒経過後、次のRSSサイトへ接続・取得。
取得成功なら State A へ戻る。
OLED初期化: 何よりも先に画面を表示可能にする。
設定ロード: 前回のRSS URL等をメモリから読み込む。
ユーザー入力待機: 画面にバーを表示し、5秒間ボタン入力を監視。
if (Button == LOW) -> executeConfigMode() を呼び出し、終了（戻らない）。
データチェック: RSS設定が空なら executeConfigMode() へ。
Wi-Fi接続試行:
10回リトライしても繋がらなければ executeConfigMode() へ。
繋がれば executeNormalMode() へ。
接続: WiFiClientSecure でHTTPS接続開始。
WDTケア: 通信待ち中も esp_task_wdt_reset() を実行し、再起動を防ぐ。
XML解析:
<item> または <entry> タグを探索。
<title> タグの中身を抽出。
全角/半角文字コードを判別し、画面幅（128px）に合わせて自動改行処理を行う（splitToFitWidth関数）。
リスト化: 表示用構造体 allTopics に格納。
Q: 設定画面でスマホが繋がらない。
A: スマホの「モバイルデータ通信」をOFFにしてから ESP32-RSS-Setup に接続してください。
Q: 画面が「システム起動中」から動かない。
A: 初回起動時やメモリクリア後は、内部でAPモードの起動準備をしています。約10秒ほどで「設定待機中」に切り替わります。
Q: 特定のサイトが表示されない。
銀行の支店長が不正融資を行なっていた。全額回収出来たが、支店長の罪は？また、支店長の行為を本社報告せず黙認した、融資課長に罪はないか？
結論：銀行支店長は「背任罪」または会社法上の「特別背任罪」に問われる可能性が高く、融資課長も黙認・不報告の行為によって共犯や従犯として刑事責任を負う可能性があります。
---
🔎 支店長の罪について
- 背任罪（刑法247条）
他人のために事務を処理する者が、自己または第三者の利益を図る目的で任務に背き、本人（銀行）に財産上の損害を与えた場合に成立します。
- 不正融資は銀行の規定や法令に違反する「任務違背行為」にあたります。
- 全額回収できた場合でも、融資時点で「返済不能の可能性が高い」「担保不足」などがあれば、経済的損害の危険を発生させた時点で背任罪が成立する可能性があります。
取締役や支店長など会社の重要な地位にある者が、会社に損害を与える目的で任務違背行為をした場合に成立します。
- 実際の判例でも、銀行支店長が不正融資を行った事例で懲役刑が科されたケースがあります。
---
👔 融資課長の罪について
- 黙認・不報告の責任
融資課長が不正を認識しながら本社に報告せず黙認した場合、以下の責任が問われ得ます：
- 背任罪の共犯（共同正犯・幇助犯）
不正融資を知りながら黙認することは、支店長の背任行為を助ける「幇助」にあたり得ます。
会社の利益を害する行為を知りながら止めず、報告義務を怠った場合、共犯として処罰対象になる可能性があります。
- 実例として、銀行の支店長と課長代理が不正融資を行い、支店長は実刑、課長代理は執行猶予付き有罪判決を受けたケースがあります。これは「黙認・関与」も刑事責任を問われ得ることを示しています。
---
⚖️ まとめ
- 支店長 → 背任罪または特別背任罪が成立する可能性が高い。
- 融資課長 → 黙認・不報告は共犯や幇助として刑事責任を問われる可能性がある。
- 全額回収できたか否かは重要ではなく、融資時点での「任務違背」と「損害発生の危険性」が判断基準となります。
---
融資課長は、支店長の不正を見抜いて回収に奔走した。但し自己および課員の人事を引き換えに刑事告発せず社内連絡しなかった。
ここでの論点は「融資課長が不正を認識し、回収に奔走したが、刑事告発や社内報告をしなかった」という点です。
---
⚖️ 法的評価のポイント
1. 融資課長の行為のプラス面
- 回収に奔走したこと
実際に損害を最小化・回避した行為は、銀行に対する忠実義務の履行と評価され得ます。
→ 背任罪の「損害発生」要件を弱める事情となり、刑事責任を軽減する可能性があります。
2. マイナス面（不報告・黙認）
- 刑事告発や社内報告をしなかったこと
- 銀行員には内部規程やコンプライアンス上の「報告義務」があります。
- 不正を知りながら報告しないことは「任務違背」と評価される可能性があります。
- 特に「人事を引き換えに黙認した」という点は、自己または第三者の利益を図る目的と解され、背任罪の構成要件に近づきます。
3. 実際の罪の可能性
- 背任罪の共犯・幇助犯
不正融資を止めず、報告しないことで支店長の背任を助けたと評価される可能性。
- 特別背任罪の共犯
会社法上の役職者として、会社に損害を与える行為を黙認した場合に成立し得ます。
- 内部規律上の懲戒処分
刑事責任が軽くても、銀行内部では「重大なコンプライアンス違反」として懲戒解雇や降格の対象となる可能性が高いです。
---
📌 まとめ
- 融資課長は「回収に奔走した」点で銀行の利益を守ったが、
- 「人事を引き換えに告発・報告をしなかった」点で、背任罪の幇助や内部規律違反に問われる可能性がある。
- 実務的には、刑事処分よりも 懲戒処分（降格・解雇） が中心になるケースが多い。
---
通常、マイコン（ESP32）をWi-Fiに繋ぐには、プログラムの中に直接「IDとパスワード」書き込む必要があります。しかし、それでは場所を移動するたびにプログラムを書き換えなければなりません。
このプログラムは、**「スマートフォンのアプリを使って、後からWi-Fiの設定情報をESP32に送り込む」**機能を実装したものです。市販のスマート家電（スマートスピーカーやロボット掃除機など）と同じような初期設定体験を提供します。
さらに、**小型画面（OLED）**を搭載することで、現在何が起きているかを目で見て確認できるようにした、非常に親切な設計になっています。
このプログラムが「有用」である理由は、以下の3つの機能が統合されているからです。
状況が見える化（ステータス表示機能）
カンタン初期化（リセット機能）
仕組みを簡単な図で表すと以下のようになります。
このプログラムがどのように動いているか、専門用語を噛み砕いて解説します。
技術: WiFiProv という公式の強力なライブラリ（道具箱）を使っています。セキュリティ（暗号化）もしっかりしています。
役割: 「交通整理係」です。
動作: プログラムの中で「Bluetoothが繋がった！」「パスワードが間違っていた！」「IPアドレスが取れた！」といった**出来事（イベント）**が発生すると、この係が飛んできて、「じゃあ画面にこう表示しよう」「次はこうしよう」と指示を出します。
コード内の場所: void SysProvEvent(...) という部分がこれに当たります。
このデバイスを使用する際の手順です。
電源を入れると、画面に「Prov（設定待機中）」や「PoP: abcd1234」などが表示されます。
これは「スマホからの連絡を待っている状態」です。
スマホアプリ「ESP BLE Provisioning」を起動します。
デバイスを探し、「PROV_ESP32」を選択します。
合言葉（PoP）として abcd1234 を入力します。
自宅のWi-Fiを選び、パスワードを入力して送信します。
成功すると、ESP32の画面に「Connected!」と表示されます。
IPアドレス（例: 192.168.1.15）も表示され、通信準備完了です。
本体のBOOTボタンを3秒間押し続けます。
画面に「Resetting...」と出て、工場出荷状態（ステップ1）に戻ります。
このプログラムをビルド（書き込み）する際の重要な技術的注意点です。
| 項目 | 設定値 | 理由 |
| Partition Scheme | Huge APP (3MB No OTA) | Wi-FiとBluetoothの両方を使うため、メモリ領域を広く確保する必要があるため。 |
| BLE Handler | HANDLER_NONE | スマホとの通信が完了する前にBluetoothを切断してしまうバグを防ぐため（コード修正済み）。 |
| セキュリティ | Security 1 (PoP使用) | 第三者に勝手に接続されないよう、パスワード（Proof of Possession）を必須にするため。 |
ESP32 Dev Kit C https://amzn.to/4pgjiR7
２０２５年１２月９日修正しました。
ちなみに、スマホソフトは、ESP-BLE-Prov でググったうえで
インストール下さい。 これが必須です。
ご指摘の通り、靖国神社は一般的な「宗教」の定義（特定の教義、開祖、聖典などを持つ組織）に当てはまらない側面があります。
祀られる対象: 靖国神社が祀っているのは、「国のために命を捧げた人々の魂（英霊）」であり、特定の神話上の神々や開祖ではありません。これは、国家への貢献に対する追悼と感謝の施設という側面が非常に強いことを示しています。
教義・開祖の不在: 神道に基づく施設ではありますが、特定の宗派のような厳密な「教義」や「開祖」があるわけではありません。儀式や慣習は神道の形式に則りますが、その目的はあくまで**「慰霊」**です。
日本人の死生観: 日本人の間で広く共有される「祖先を敬う」「戦死者の霊を弔う」という文化的慣習や死生観の上に成り立っており、これが「宗教」という枠を超えた国民的な追悼施設と認識される背景にあります。
「信仰（信じる心、敬う心）」が必ずしも「宗教（Organized Religion）」という形式を伴わない、という日本の特殊性は、外国人の理解を難しくする核心です。
多神教・アニミズム: 日本の信仰の基盤には、特定の神を唯一とする一神教とは異なる、自然や祖霊に神が宿ると考えるアニミズム的・多神教的な神道があります。ここでは、「神」と「信仰」が非常に身近で生活に溶け込んでいます。
「無宗教」という自己認識: 多くの日本人は、特定の宗教団体に所属していないという意味で「無宗教」と自己認識していますが、同時に正月には神社へ行き、葬式は仏式で行い、クリスマスを祝うことに抵抗がありません。これは、**「宗教行事」を「文化的慣習」**として受け入れているためです。
一神教的背景: 欧米社会の基盤には、キリスト教やイスラム教といった一神教の歴史が深く根ざしています。ここでは、「信仰」は多くの場合、特定の教義と組織（教会、モスクなど）に紐づき、「宗教」と「信仰」が密接不可分です。
公私の区別: 彼らにとって「神聖なもの（Sacred）」に関わる行為は基本的に「宗教」に属し、個人生活や国家運営において、宗教の自由や政教分離の原則が厳格に適用されます。そのため、「特定の宗教ではない施設（靖国神社）を国家元首が公的に参拝すること」や、「宗教ではないのに、なぜか国民の多くが敬意を払う場所」という構造は、彼らの政教分離や信仰の自由の概念からすると、解釈が難しいのです。
靖国神社や、日本の「信仰と宗教の関係」は、以下のようにまとめられます。
日本における**「信仰」は、特定の教義に基づく「宗教」というよりも、「文化」「歴史」「祖先への敬意」に強く根ざした「精神的・文化的慣習」**としての側面が強い。
靖国神社は、その日本独自の慣習・死生観に基づき、戦没者に対する国家的な感謝と追悼を目的とした、極めて公共性の高い慰霊施設として機能している。
外国人が理解に苦しむのは、彼らの持つ「宗教」＝「組織、教義、開祖」という定義が、日本の**「宗教の形式を伴わない国民的な敬意・信仰」**という現象に当てはまらないためである。
調べて要点を整理しました。風評は取り除き、確認できる事実とコミュニティ／報道の懸念点を分けて示します（出典を付記）。結論だけ先に言うと：
事実としては――2025年10月にQualcomm が Arduino を買収したと発表され、Arduino／Qualcomm 双方は「ブランドやオープンな方針を維持する」と公式に表明しています。ただし、買収発表の前後で Arduino の利用規約（ToS）／プライバシーポリシーの改定が行われ、コミュニティや複数のメディアがその内容に懸念を表明しています。Arduino は後に「誤解を招いている点を説明する」公式記事も出しています。以下、根拠付きに整理します。
買収発表：Qualcomm が Arduino を買収することを（両社が）公式に発表。買収発表日は 2025年10月7日。発表文では Arduino のブランド／エコシステムを維持する旨を明記しています。(qualcomm.com)
Arduino 側の公式案内（FAQ / Blog）：Arduino の公式サイトに買収についての案内ページと FAQ があり、「Arduino は Qualcomm の一部となった」「今後の方針としてオープンなアプローチとコミュニティ精神を維持する」といった説明が載っています。(arduino.cc)
ToS / プライバシーポリシーの改定：Arduino の利用規約・プライバシーポリシーは最近更新されており、サイト上に最新版が掲載されています（公開日や文面の更新はページで確認可能）。そのポリシー文中で「Arduino は Qualcomm グループの一員である」と明記されています。(arduino.cc)
ToS／プライバシー改定に対する反発：複数の技術メディアやコミュニティ（Ars Technica、TechSpot、Hacker News、Reddit、フォーラムなど）が、改定後の ToS / プライバシー文面の一部に「監視・権利放棄と解釈される可能性のある文言」「逆アセンブルやリバースエンジニアを制限するように読める文言」などがあり、オープンハード／ものづくりコミュニティで強い不安と反発が起きていると報じています。これらは「報道・コミュニティの懸念」であり、**事実としては『懸念が広がっている』**という点は確かです。(アーステクニカ)
Arduino の釈明：コミュニティの反発を受け、Arduino は公式ブログ記事で ToS/Privacy の更新について説明・釈明を出しています（「誤解を招く点を明確にする」「オープンソースの原則を維持する」「AI機能等の導入に伴う説明の追加」などの趣旨）。つまり、Arduino は少なくとも公的には「オープン方針は維持する」と再表明しています。(Arduino Blog)
買収は公式に発表されており進行中／完了の状況は発表に従う（発表日：2025-10-07）。公式発表では「ブランド・オープン方針を維持」と明記。(Arduino Blog)
同時期に ToS／プライバシーの更新があり、コミュニティに不安を生んでいる。その結果、複数の第三者メディアが改定内容を批判的に報じ、Arduino は説明文で応答している。懸念は実在するが、「オープンハードウェア方針が既に消滅した／一方的に変更された」という決定的な事実は、（現時点で）公式に示されていません。(アーステクニカ)
公式 ToS / Privacy の「改定差分」を読む（旧版と新版の具体的文言を比較すると、実際に何が変わったかがわかります）。（必要なら私が差分を抽出します。）(arduino.cc)
Arduino の公式声明（FAQ／Blog）と Qualcomm の発表を参照：両社の公的な約束文を保存しておくと、将来の方針変更の際に参照できます。(qualcomm.com)
コミュニティ動向をウォッチ：重要な変更はコミュニティの実使用やライセンス訴訟、あるいは規制当局の介入（競争法など）により実際の影響が出ることがあるため、フォーラム／主要メディアの継続的な確認が有効です。(TechSpot)
「Arduino グループが Qualcomm に買収されたことでオープンハードウェアのポリシーが即座に消失した」という 断定的な事実は確認できません。公式発表では「オープンなアプローチを維持する」と述べられています。しかし、同時に 利用規約・プライバシーポリシーの改定が行われ、コミュニティや複数メディアが具体的な文言に懸念を示しているのも事実です。したがって「将来どうなるか」は今後の運用（実際の製品ポリシー、ライセンス運用、法的解釈、コミュニティ反応）を見守る必要があります。(Arduino Blog)
懸念事項
ご質問を3点に分けて、風評を排除し一般的な事実とポリシーの概念で回答します。
はい。問題なく続けられます。
Arduino IDE は **オープンソースソフトウェア（LGPL/GPL）**として公開されており、特定企業の所有になったとしても ライセンス自体は遡及して消せないため、今ある IDE を使い続ける法的権利は保たれます。
公式も「エコシステムとコミュニティ精神を維持」と表明している通り、IDE の利用が禁止される・使えなくなるという事実はありません（実運用としても継続されています）。
→ 結論：これからも今までどおり使えます。
はい。構いません。
Arduino は創業から一貫して オープンハードウェアを掲げており：
回路図・設計データ・ピン配置・ブートローダ等の基礎仕様は公開されています（モデルにより公開範囲は異なりますが、互換機が作れないという制限はありません）
互換機・クローンボードは歴史的にも世界中で発表・販売されています
チップ（AVR/ARM/ESP32など）を購入し、Arduinoコア/ブートローダまたはArduino-frameworkで動くボードを発表することは合法
ただし法で必要なものは別物です：
→ ポリシーでNGなのではなく 商標以外はOK、必要な法規対応だけやればOK です。
GitHubで設計公開して発表
→ すべて 合法に続けられます
整理するとこうです：
| 項目 | どこに送られる？ | 誰が見る？ | 何が送信される？ |
|---|---|---|---|
| ボードに書き込むスケッチ（.ino） | ✅あなたのPC → USB → マイコンだけ | ✅あなたとボード所有者だけ | ❌Arduino社には送られない |
| Arduino IDE の起動/利用そのもの | ✅通常は外部送信なし | － | － |
| ライブラリマネージャ等のアクセス | ✅ライブラリ配布サーバーのみ | サーバー管理者（インフラ提供者） | ライブラリの取得ログ程度 |
| クラウド機能（Arduino IoT, Sketch Sync, AI支援等） | ⚠Arduinoクラウド | サービス提供者（Arduino/グループ企業） | アカウント名、プロジェクト名、IP、同期データ等 |
つまり：
あなたのWindowsPC で Arduino IDE を起動
↓ USB経由でコンパイル済バイナリ(.bin/hex)をESP32ボードへ
↓ 書き込まれる（ネットには出ない）
→ 外部にアップロードされていないので記録も発生しません
（＝誰もあなたのコードをクラウド上で閲覧できない）
あなたのArduinoアカウント makotoAxxxx が
プロジェクト "IoT_Reset_Watch_v3" を
Arduinoクラウドに Sketch Sync で保存・アップロード
2025-11-27 16:02 JST
IP: 日本（ISPのグローバルIP）
→ 送られるのはクラウドであなたが同期したプロジェクト・メタデータだけ
（スケッチ本体もクラウドに保存されますが、公開設定しない限りPrivate）
GitHub ユーザー: makoto-Adnis
リポジトリ: Arduino_ESP32_IoTBoard
公開内容: 回路図, ピン互換仕様, スケッチサンプル
→ アップロード先はGitHub、閲覧者はGitHubの利用者全員
| 質問 | 回答 |
|---|---|
| Arduino IDE で開発継続できますか？ | ✅できます |
| チップで互換機作って発表できますか？ | ✅合法（技術はOK、商標は使わない、電波認証は必須） |
| Arduino が私のコードを吸い上げますか？ | ❌USB書き込みだけなら吸い上げません |
あんなことやこんなことしても大丈夫だけど、あーいう事はちょっと
無理ってことかな。
Hailo-8 / Hailo-8L（＝Raspberry Pi AI HAT+ SC1785/SC1775 系に搭載されているNPU）が、**LLM（大規模言語モデル）用途に向かない／高速化が難しい設計上の理由**を、ハードウェア構造・アーキテクチャ・ソフトウェアの観点から具体的に列記します。
---
# 🔧 Hailo-8 / 8L が LLM に不向きな設計上の理由（詳細列挙）
## ① 処理構造が「CNN最適化設計」であり、Transformer 向けではない
* Hailo-8 シリーズは、**畳み込みニューラルネット（CNN）や画像推論タスク**を対象として設計されている。
* そのため内部の計算グラフ最適化・演算ユニット構成が、
* 2D畳み込み (Conv2D)
* BatchNorm / ReLU
* Pooling / Upsampling
などの**画像処理パターン**に特化している。
* 一方 LLM は主に
* 行列積（GEMM）
* Attention（softmax + matmul）
* Embedding lookup
といった**系列データ・高次元テンソルの線形代数演算**が中心であり、Hailo-8 の演算パイプラインでは非効率。
→ 結果として、モデルを NPU にオフロードしても、Attention 部分が実行できず CPU 側に戻され、速度向上が得られない。
---
## ② オンチップメモリが小さく、外部DRAMインタフェースを持たない
* Hailo-8/8L は、**内部 SRAM（数MBクラス）**しか持たず、外部DDRメモリを直接制御できない。
* 一方、LLM では**重みとKVキャッシュが数百MB〜数GB規模**に達するため、オンチップSRAMでは保持不可能。
* 重み・中間テンソルの転送が頻発し、PCIe経由でホストメモリを参照せざるを得ない。
* PCIe経由のデータ転送はレイテンシが大きく、NPU演算ユニットの稼働率が低下する。
→ **メモリ帯域・容量がボトルネック**となり、トークン生成時のストールが発生。
---
## ③ データフローモデルが静的最適化前提で、動的系列長に非対応
* Hailo の推論アーキテクチャは「**コンパイル時に演算グラフを静的に最適化**」する方式。
* Transformer のような LLM は「入力トークン長が動的」「自己注意のマスク形状が可変」といった**ランタイム依存**の構造を持つ。
* そのため、Hailo コンパイラ（Dataflow Compiler）では系列長を固定できず、Attention 部分を展開できない。
* 実際、コミュニティで distil-whisper や BERT 変換を試みた例では、attention層で「Unsupported operator」エラーが発生している。
→ 「固定的な畳み込みネット」以外は最適化しにくく、Transformerモデルではコンパイル不可／部分的実行しかできない。
---
## ④ Attention／Softmax／LayerNorm／Embedding 等の演算ユニットが存在しない
* Hailo-8 は、Conv / FC / Elementwise など基本的な演算ブロックのみ実装。
* LLMで頻出する以下の演算をハードウェア的にサポートしていない：
* **Softmax**（Attention のスコア正規化）
* **Layer Normalization**
* **Embedding Lookup**
* **GELU / SwiGLU 等の非線形活性**
* **KVキャッシュ参照／更新**
* これらはCPU上で逐次処理されるため、実質的にアクセラレータがアイドル状態になる。
→ 結果：**「NPUは一部しか動かない」ため、全体性能はCPU実行と大差なし。**
---
## ⑤ マルチヘッドAttentionや長系列のストリーム処理構造を持たない
* LLMでは「マルチヘッドAttention」による大量の並列行列積を扱う。
* しかし Hailo-8 のアーキテクチャは「多チャネルCNN」の並列化構造であり、**系列方向（時間軸）での並列処理を想定していない**。
* また、LLM生成ではトークンごとに前回の出力（KVキャッシュ）を逐次参照する必要があるが、Hailo-8 にはそのような逐次ストリーム最適化回路がない。
→ **再帰的／逐次的処理に弱い構造**のため、生成型LLMを継続動作させると効率が著しく低下。
---
## ⑥ 演算精度と量子化スキームが LLM に最適化されていない
* Hailo-8 の内部精度は主に INT8 / UINT8 固定点演算。
* LLM は微妙な重み分布とsoftmax正規化を扱うため、**INT8単精度では出力品質が著しく劣化**するケースが多い。
* 通常、LLM量子化は 4bit/5bit/8bit + 専用スケーリングや非線形補正を行う（例：GPTQ、AWQ）。
* Hailo のINT8エンジンではこのような**非線形量子化を扱えず**、精度劣化・不安定な出力が発生する。
→ 実質的に「動作しても結果が破綻」するケースが多い。
---
## ⑦ I/Oとホスト制御が分離され、逐次制御がオーバーヘッドに
* LLM推論は「1トークンごとに逐次推論」する必要がある（1ステップ生成→再入力→次ステップ）。
* Hailo-8 のPCIe経由実行では、毎ステップで NPU呼び出し／メモリ転送／結果取得を繰り返す必要がある。
* これは CNN の「1回入力→1回推論→完結」型と違い、非常にオーバーヘッドが大きい。
* 実行回数が数千トークン規模になると、PCIeレイテンシが支配的になる。
→ **インタフェース設計が逐次生成に不向き。**
---
## ⑧ ソフトウェアスタックが LLM未対応
* Hailo-RT / Hailo-SDK / Hailo-Dataflow-Compiler は TensorFlow Lite / ONNX などを介して CNN/DNN推論をサポートするが、
* HuggingFace Transformers
* llama.cpp / ggml
* MLC LLM / vLLM
等のLLMフレームワーク統合は行われていない。
* 結果として、LLMのトークン生成パイプラインをNPUに統合することが困難。
* 一部レイヤーごとの推論はできても「生成全体を通して高速化」できない。
---
## ⑨ Hailo-10/Hailo-10H で初めて LLM向けアーキテクチャを導入
* Hailo社自身が、Hailo-10シリーズで**外部メモリ接続・Transformers最適化・長系列処理**に対応すると発表。
* つまり、メーカー自身も「Hailo-8世代では LLM は難しい」と認識していることを示唆。
* Hailo-10H はエッジLLM（小型GPT・Whisper等）の運用を公式にサポート予定。
---
