はじめに
2026年10月、SoftBank Air ターミナル6へのOpenWrt移植を始めました。
対象機種はMediaTek MT6990を搭載した、5G通信機能を持つホームルーターです。一般に配布されているOpenWrtの対応機種ではなく、カーネル、ブート構成、ネットワークドライバ、モデム制御など、独自に調査しなければならない部分が多数あります。
私はカーネル開発の専門家ではありません。今回の作業ではChatGPTとCodexを利用し、ソースコードの調査、修正、ビルド、実機検証を進めています。
10月18日に着手し、20日にはLinuxカーネルの起動、24日までに有線LANとWi-Fiの動作確認、25日にはLTEによるIPv4通信に到達しました。
ただし、これはOpenWrtの移植が完成したという意味ではありません。
実際には、動作する部分と動作しない部分が混在し、いったん成功した機能についても別の構成で再現できない問題が残っています。正式に配布可能なファームウェアも完成していません。
今回の経験を通じて考えたいのは、AIを利用した開発がどこまで可能になったのか、そして何が依然として難しいのかという問題です。
1. 移植対象と現在の到達点
SoftBank Air ターミナル6は、一般的なLinux PCとは異なり、SoC固有の初期化処理や周辺デバイスの制御にメーカー由来の実装を必要とします。
今回の開発では、Linux 6.18系をベースとしてOpenWrtのユーザーランドを起動し、各種ドライバを組み合わせて動作確認を進めました。
2026年10月29日時点の主要な結果を整理すると、次のようになります。
| 項目 | 確認状況 |
|---|---|
| Linux 6.18.44 | 実機起動成功 |
| OpenWrtユーザーランド | procd、シェル等の動作確認 |
| 有線LAN | リンク確立、パケット通信成功 |
| Wi-Fi 2.4/5GHz | AP動作、通信確認 |
| Wi-Fi 6GHz | AP起動を確認 |
| Wi-Fi 7 EHT/MLO | 完全な機能検証は未達 |
| LTE IPv4 | ping、DNS、TLS通信成功 |
| 5G NR通信 | 未確認 |
| モデムIPv6 | 未確認 |
| コールドブート再現性 | 検証不足 |
| 完全な独立ビルド | 未達 |
| 一般配布可能なファームウェア | 未完成 |
これらの結果は、実験用個体で確認したものです。
とくに重要なのは、実機で動作したことと、公開したソースコードから第三者が同じ動作を再現できることは別問題だという点です。
後者を実現するには、必要なソース、カーネル設定、Device Tree、ビルド環境、依存するファームウェアなどを整理する必要があります。
公開リポジトリでは、動作確認済みの項目と未完成の項目を分けて記載しています。
2. AIは実際に何を担当したのか
今回の開発では、単にChatGPTへソースコードの生成を依頼したわけではありません。
ChatGPTをGitHubと接続し、既存のソースコードや開発記録を参照させながら、問題の分析、パッチの作成、コミット、テストの追加などを進めました。
実際のカーネルビルドには、別途用意したLinux環境やGitHub Actionsのセルフホストランナーを利用しています。
一方、実機へのSSH接続、UARTログの取得、デバイスの状態確認などは、Codexによる操作や人間の作業を通じて実施しました。
役割を整理すると、以下のようになります。
| 担当 | 主な作業 |
|---|---|
| ChatGPT | ソース調査、設計、仮説生成、パッチ作成、ログ分析 |
| GitHub | コード管理、変更履歴、Issue、検証記録 |
| ビルド環境 | クロスコンパイル、静的検査、回帰テスト |
| Codex | 実機への接続、コマンド実行、ログ取得 |
| 人間 | ハードウェア準備、作業方針、安全判断、結果の評価 |
ChatGPTからGitHubを直接操作する構成にすると、すべてのコード修正をCodex経由で行う必要がなくなります。
このため、実機操作にCodexの利用枠を集中させることができ、AIの利用量に制約がある個人開発でも作業を継続しやすくなりました。
しかし、AIを複数組み合わせたからといって、それぞれのAIが自動的に共通の作業状態を理解するわけではありません。
どのソースを変更したのか、どのカーネルを起動しているのか、実機に何が反映されているのか。その対応関係を維持する仕組みが必要でした。
GitHubはコードの保存場所であると同時に、AIが作業を引き継ぐための外部記憶装置として機能しています。
3. AIの能力が最もよく表れた問題：LTE通信とDMA
今回、特に印象的だったのが5Gモデムの制御です。
Linuxからモデムを利用するには、単にネットワークインターフェースを作ればよいわけではありません。
MediaTek系のモデムでは、CCCIによる制御通信、モデムの起動シーケンス、各種サービスとの連携、DMAを利用したデータ転送など、複数の要素が関係します。
開発中、一見すると通信できそうな状態まで到達したことがありました。
SIMはREADY、ネットワークへの登録も成功し、データ接続も確立しています。
ところが、IPv4パケットは返ってきません。
調査すると、送信カウンタは増加しているのに、受信カウンタは増加しない状態でした。
SIM READY
↓
LTE HOME
↓
PDN確立
↓
ネットワークIF生成
↓
TX > 0
RX = 0
↓
IPv4通信失敗
ここで重要なのは、制御系の成功とデータ転送系の成功を分けて考える必要があることです。
AIとの調査では、カーネルソース、デバイスの初期化処理、DMA関連レジスタの状態、実機ログなどを突き合わせて原因を絞り込みました。
結果として、Ethernet初期化に伴うリセット処理と、モデム通信に必要なMED関連DMA状態との関係が問題になっていることが分かりました。
Stage 9BではDMA状態を手動で復元することで双方向IPv4通信に成功し、Stage 10では関連するDMA状態を保持する修正によって、手動復元なしで通信できるようになりました。
確認したのは、ping、DNS名前解決、証明書検証を伴うHTTPS通信です。
これは確かな進展でした。
ただし、この修正は特定のカーネル構成と実機条件に依存しています。汎用的なMediaTekドライバの修正として妥当かどうかは、別途検証する必要があります。
さらに、その後の別構成でのモデム検証では、ハンドシェイクの途中から例外状態 md1:5 に遷移する問題が発生しています。
現在は既存ドライバの解析を続けながら、新たなモデムドライバ実装も検討しています。
一度通信できたことは事実ですが、通信機能を完成させたことにはなりません。
この一連の作業には、AIによる開発の可能性と限界がよく表れていると思います。
4. 限界その1：AIは未知のハードウェアを本当に理解しているわけではない
AIはLinuxカーネルの既存コードや技術資料をもとに、非常に多くの仮説を提案できます。
類似するSoCのドライバを調査したり、APIの変更点を推定したり、古いカーネルから新しいカーネルへの移植方法を考えたりする作業は得意です。
しかし、似たような実装が存在することは、その実装が対象機器でも正しいことを意味しません。
今回のモデム調査でも、MediaTek T700、T900などの関連実装を参照しました。
CCCIのメッセージ構造やプロトコルには共通点がありますが、接続インターフェース、レジスタ配置、DMA制御、初期化順序などをそのまま流用できるとは限りません。
同じメーカーのモデムだからという理由だけでコードを移植すると、コンパイルは成功しても実機では動作しない可能性があります。
AIは、既知の実装の間にある共通点を見つけることができます。
しかし、公開資料が存在しないハードウェア固有の事実を、コード生成だけで確定させることはできません。
この問題は、カーネルドライバに限らないでしょう。
公開されているAPIの上でアプリケーションを開発する場合と、資料の乏しいハードウェアを制御する場合とでは、AIが利用できる情報の量が大きく異なります。
未知の部分が増えるほど、もっともらしい仮説と実際の動作の間に距離が生まれます。
5. 限界その2：AIは誤った仮説を自信を持って提示する
今回の開発では、AIが提案した修正が期待どおりに動作しないことも少なくありませんでした。
これは単にコードの文法を間違えるという話ではありません。
ソースコードとして整合性があり、コンパイルも成功し、論理的には説明できる。それでも、実機では動かない場合があります。
たとえば、カーネルモジュールであれば、対象カーネルの正確なビルド設定、Module.symvers、エクスポートシンボル、ABI、ロード時の依存関係などが問題になります。
コンパイルできることと、実際に稼働しているカーネルへ正常にロードできることは異なります。
さらに、モジュールがロードできたとしても、デバイスが正常に初期化され、通信できる保証はありません。
AIとの対話では、こうした段階を飛ばして「実装できた」「対応した」と評価してしまう危険があります。
実際、今回の作業でも、静的検査やビルドの成功と実機動作を厳密に区別する必要がありました。
そこで、開発記録では次の区分を使用しています。
| 分類 | 意味 |
|---|---|
| FACT | ログ、実測、再現試験などで確認した事実 |
| INFERENCE | 確認済みの事実から導いた推論 |
| HYPOTHESIS | 検証前の仮説 |
| UNKNOWN | 現在の情報では判断できない事項 |
この区分は有効でした。
AIの回答に根拠があるのか、それとも仮説にすぎないのかを、明示的に確認できるからです。
もちろん、こうしたルールを設定しただけでAIの誤認識がなくなるわけではありません。
それでも、仮説を事実として積み重ねてしまう危険は減らせます。
6. 限界その3：長期開発ではコンテキストが崩れる
OpenWrt移植のような開発では、同時に複数の問題を扱います。
ブートローダ、Device Tree、Ethernet、Wi-Fi、モデム、ビルド設定などが相互に依存し、それぞれの作業で異なる実験用イメージや修正版が作られます。
さらに、今回の開発では複数の実機とA/Bブートスロットを使用しています。
ある実験で確認した事実が、別の実験用イメージでも成立するとは限りません。
長い対話を続けていると、AIが以前の構成を現在の構成と取り違えたり、別の実験で得た結果を混同したりすることがあります。
これは人間側にとっても難しい問題です。
たとえば、「前回は動いたはず」という情報だけでは、どのカーネル、どのrootfs、どのスロット、どの修正を使用したかが分かりません。
そのため、今回はGitHubのIssue、Pull Request、コミット、SHA-256、テスト結果などを利用して、実験の条件と結果を保存するようにしました。
重要なのは、AIの記憶に頼るのではなく、AIが再確認できる記録を作ることです。
コンテキストウィンドウが大きくなっても、長期にわたる開発履歴のすべてを常に正しく保持できるとは限りません。
AIを長期開発に使う場合、情報の保存だけでなく、どの記録を現在の正本とするかを管理する必要があります。
7. 限界その4：実機検証をAIに任せても、検証の負担は消えない
AIの大きな利点は、実装と修正の速度です。
しかし、組み込み機器の開発では、コードが完成してから確認しなければならない事項が数多くあります。
正常に起動するか、通信できるか、再起動後も維持されるか、電源断から復帰できるか、異常状態で安全に停止するか。
これらはソースコードを読むだけでは証明できません。
AIエージェントに実機操作を任せることはできますが、作業の安全性を保証するには、操作可能な範囲、停止条件、復旧方法を事前に定義する必要があります。
今回の開発では、ブート領域の書き換えやモデムの状態変更など、失敗した場合に機器の復旧が困難になる操作も対象になりました。
そのため、読み取り専用の調査と、状態変更を伴う実験を明確に区別しています。
実験では原則として、変更前の状態、実行した操作、変更後の状態、観測結果、合否判定を記録しています。
同じ失敗を根拠なく繰り返さないことも重要です。
AIが提案した修正をそのまま実行し、失敗したらまた別の修正を試すという方法では、いつの間にか実機の状態が分からなくなってしまいます。
また、ブートローダの署名検証、個体固有の無線校正情報、メーカー由来のファームウェアなど、技術的に動かせても自由に配布できるとは限らないものがあります。
この問題もコード生成だけでは解決できません。
実験用のファームウェアを動かすことと、安全で再現可能なファームウェアを第三者へ提供することの間には、大きな隔たりがあります。
8. 限界その5：実装の高速化は、検証の高速化と同義ではない
今回、AIを利用することで、以前なら調査だけで相当な時間がかかったと思われる作業を進められました。
Linuxカーネルの巨大なソースツリーを検索し、構造体や関数の関係を追い、ドライバの差分を整理し、検証用スクリプトを作成する。
こうした作業をAIに任せられる利点は非常に大きいと感じています。
一方で、コードの生成速度が上がると、検証すべきコードの量も増えます。
特に注意したいのが、自動テストの扱いです。
モックや合成データを使用したテストが100件成功しても、それだけで実機のドライバが動作することにはなりません。
逆に、実機で一度成功しても、それだけでは別の個体や起動条件での再現性を証明できません。
ここには、異なる種類の検証があります。
| 検証段階 | 分かること | まだ分からないこと |
|---|---|---|
| 静的検査 | 文法や一部の整合性 | 実機動作 |
| コンパイル | 指定環境でのビルド成立 | ロード・起動の成否 |
| 合成テスト | 想定条件下のロジック | 実ハードウェアの挙動 |
| 実機単発テスト | 特定条件下での成功 | 再現性・安定性 |
| 反復・異常系テスト | 条件を変えた場合の挙動 | 未試験条件の安全性 |
| 第三者による再現 | 手順と成果物の再現可能性 | すべての運用条件での品質 |
OpenWrt公式の開発ガイドでも、デバイス追加にはDevice Treeやボード固有の設定、イメージ生成処理などの整備が必要とされています。
単にLinuxが起動しただけでは、公式の対応機種として十分ではありません。
OpenWrt Wiki: Adding a new device
今回、コードを書けることと、完成した製品として提供できることの距離を改めて認識しました。
9. AIによって人間の役割はどう変わるのか
ここまでAIの限界を取り上げてきましたが、従来の開発と比べて変化していないという話ではありません。
むしろ、かなり大きな変化が起きていると思います。
従来、専門外の人がLinuxカーネルのドライバ開発に取り組むには、関連する技術や既存コードを理解するまでに大きな学習コストが必要でした。
もちろん、AIを利用しても学習は必要です。
ただし、すべての知識をあらかじめ習得してから作業を始める必要はなくなりました。
実際の問題に直面した時点で、関連する概念を調べ、ソースを読み、仮説を立て、実験するという進め方が可能になっています。
その結果、個人が挑戦できる開発対象の範囲は確実に広がっていると感じます。
一方、人間の役割がなくなったわけではありません。
今回の開発で特に重要だったのは、AIが提示した回答を理解し、どこまで信用できるかを判断することでした。
失敗したときに同じ方法を繰り返すのか、別の仮説を検討するのか、いったん実験を停止するのか。
技術的な判断だけでなく、機器の破損リスクや、成果物を公開する際の責任も考える必要があります。
つまり、AIによってコードを書く能力への依存は減りつつありますが、何を検証し、何を完成と判断するかという能力の重要性は、むしろ高まっているように思います。
10. AI開発の現在地点
今回のOpenWrt移植を通じて、AIはすでに単なるコード補完ツールではないと感じました。
既存ソースの調査から始まり、設計、実装、ビルド、ログ分析、修正案の作成まで、一連の開発プロセスに参加できます。
GitHubなどの外部システムと接続することで、長期の開発作業を継続することも可能です。
その一方で、AIは現実のハードウェアを直接理解しているわけではありません。
実機の状態を観測できるのは、センサー、ログ、測定器、あるいは実機を操作するエージェントを通じてです。
得られた情報が不完全であれば、そこから導く結論も不確かになります。
さらに、AIが生成したコードの妥当性は、コンパイル結果や自動テストだけでは保証できません。
今回のLTE通信のように、複数の状態が正常に見えても、実際のデータ転送が成立しないことがあります。
AIは仮説を立て、修正案を作り、検証方法を考えることができます。
しかし、仮説を大量に生成できることと、仮説が正しいことは別です。
ここが現在のAI開発における重要な境界だと考えています。
おわりに
SoftBank Air ターミナル6へのOpenWrt移植は、まだ完成していません。
Linuxの起動、有線LAN、Wi-Fi、LTE IPv4通信など、いくつかの機能は動作しました。しかし、モデムの完全な対応、ブートの再現性、独立したビルド環境、一般配布可能なファームウェアなど、解決すべき課題が残っています。
今回の経験から分かったのは、AIの進歩によって、個人が取り組める技術開発の範囲が大きく広がったということです。
同時に、実装の速度が上がっても、検証の重要性が小さくなるわけではありません。
専門家でなければ着手することさえ難しかった領域に、専門外の個人が参加できるようになりつつあります。
ただし、そこで得られた結果を正しく評価し、他者が再現できる形にするには、依然として相応の知識と労力が必要です。
AIは開発への参入障壁を下げました。しかし、完成を証明するための基準まで下げたわけではありません。
これが、今回のOpenWrt移植を通じて得た、2026年時点のAI開発についての私なりの結論です。
今後も開発を続けながら、成果だけでなく、失敗と未解決の問題を含めて記録していきたいと思います。