2026年10月時点におけるAIの実務能力、限界、および人間との役割分担に関する考察
要旨
2026年10月、プログラミングを専門としない個人が、生成AIを主たる開発手段として、SoftBank Air ターミナル6（MT6990搭載機）へのOpenWrt移植を試みた。開発開始から約1週間で、独自ビルドしたLinuxカーネルおよびOpenWrtユーザーランドの起動、有線LAN、Wi-Fi、LTE IPv4通信などの動作確認に至った。
本事例の特徴は、開発者自身がソースコードをほとんど読まず、実装および技術的解析の大部分をAIに委ねた点にある。一方、開発の進展を左右した少なくとも3つの重要な判断は、AIではなく人間によって行われた。
本稿では、この開発過程を、AIの実務能力を検証した一事例として整理する。あわせて、GitHubとの接続がAIの作業能力に与えた影響、第三者の反応、再現可能性、および今後の自律開発の可能性について考察する。
なお、本稿は2026年10月時点の実践記録に基づく事例研究であり、AI全般の恒久的な能力限界を論じるものではない。
1. 実験の背景と目的
生成AIによるプログラミング支援は、コードの生成、修正、説明から、既存リポジトリの調査や継続的な開発作業へと対象を広げている。
しかし、AIが実際のソフトウェア開発をどの程度代行できるかという問いは、単純ではない。
プログラムを作成できることと、未知の技術的問題を解決できることは異なる。また、専門家がAIを利用した場合と、専門知識のない人間がAIを利用した場合とでは、検証される能力も異なる。
本事例の開発者は、日常的にコンピューターやネットワーク機器を扱っているものの、プログラミングや組み込みLinux開発を専門としていない。
そこで、比較的難度の高いOpenWrt移植を題材とし、専門的なコーディング能力を持たない個人とAIの組み合わせが、どこまで到達できるかを試みた。
当初、具体的な実現方法についての見通しはなかった。
ただし、対象機器は既に商用製品としてLinuxベースのソフトウェアで動作している。したがって、必要な情報を調査し、既存の実装を理解し、試行錯誤を重ねれば、解決に至る経路が存在する可能性は高いと考えた。
この見通しは、具体的な実装方法についての知識ではなく、探索によって解決方法を発見できるという仮説であった。
2. 開発経過と到達点
開発は2026年10月18日に開始された。
対象はSoftBank Air ターミナル6であり、MediaTek MT6990を搭載する。独自のブート機構、ベンダー固有のドライバ、モデム制御など、一般的なOpenWrt対応ルーターとは異なる課題が存在する。
10月22日にはLinux 6.18.44およびOpenWrtユーザーランドの起動を報告した。これは純正KNOS上でアプリケーションを実行するものではなく、独自ビルドしたカーネルを起動する段階への到達を意味する。
その後、有線LANおよびWi-Fiの動作確認が進み、10月25日にはモデムを使用した通信にも成功した。
ただし、この時点で実証されたのはLTE IPv4通信であり、5G NR通信の成功ではない。10月27日の報告でも、LTEセル情報の取得および登録は確認されているが、5G NR接続は未確認とされている。
したがって、全機能の完成や公式サポートの実現と、今回の実機動作成功は区別する必要がある。
一方、開発における試行錯誤は約89回に及んだ。短期間に多数の仮説を検証し、結果を次の実装へ反映させる開発形態が成立したことは、本事例の重要な特徴である。
3. 人間とAIの実際の役割分担
従来のソフトウェア開発において、プログラミング能力は実装作業に直接結びついていた。機能を追加するには、必要な処理を理解し、適切な言語で記述し、ビルドやデバッグを行う必要がある。
本事例では、その関係が大きく変化した。
開発者は目的や要求を自然言語で示し、AIが調査、コードの作成、修正、ビルドに関する問題の解析、検証手順の設計などを担った。
開発者自身は、生成されたコードの大部分を直接確認していない。AIが提示する詳細な技術説明についても、その一部しか読んでいない。
これは技術的な理解が不要になったことを意味しない。実装に必要な専門知識を、人間があらかじめ習得している必要がなくなったということである。
人間側の主な仕事は、何を実現したいかを決め、実機で試し、結果を確認し、次の方針を判断することだった。
一方、AI側は、その目的を実現するための具体的なソフトウェア実装を担当した。
専門家が保有する知識のうち、何がAIによって代行されたのかという問いに対し、開発者自身の答えは端的である。
「コーディング」である。
実際には技術資料の調査やログ解析も含まれているが、人間がコードを書かずに開発を進められたことが、最も明確な変化であった。
4. AI単独では突破できなかった3つの判断
本事例をAIの自律的な成功と評価することは適切ではない。
開発過程では、人間の介入によって進展した重要な局面が少なくとも3つ存在した。
4.1 根拠の乏しいテスト鍵を試す判断
第一は、テスト用の秘密鍵について、十分な裏付けのない候補を試すという判断である。
AIは一般に、証拠のある候補を優先し、不確実性を減らしてから行動する傾向がある。
しかし、候補となる鍵で一度ビルドしてみること自体のコストは小さい。仮説が誤っていた場合でも、主な損失はその試行に費やす時間と計算資源である。
このような場合、仮説の確からしさが低くても、試すことが合理的になり得る。
重要なのは、暗号学的に秘密鍵を解読したことではない。既存の候補について、十分な根拠がなくても検証を実施すると判断したことである。
この判断は人間によって行われた。
4.2 未解析のquec_bootctrlを実行する判断
第二は、動作の詳細が未解析だったquec_bootctrlを、リスクを承知で実行する判断である。
AIは、未解析のブート制御操作が機器の起動不能につながる可能性を指摘し、慎重な対応を求めた。
その懸念には技術的な根拠がある。
一方、開発者は、実験対象の中古機器が約3,000円で入手可能であることを認識していた。仮に実機が復旧不能になっても、その経済的損失は許容できる範囲にあった。
もちろん、機器の代金だけでなく、復旧作業や実験記録の喪失も考慮する必要がある。しかし、開発者はこれらを含めて実験を進める判断を下した。
ここでは、AIがリスクを認識できなかったのではない。
人間にとって許容可能な損失を、AIが十分に行動判断へ反映できなかったことが問題だった。
また、実際の損失を引き受け、実験を進める最終的な決定権を持つのは人間であった。
4.3 正常動作機との比較実験を発案する判断
第三は、5Gモデムの解析において、正常に動作するA号機と、OpenWrt移植中のB号機を比較するという着想である。
これは前二者と性質が異なる。
正常系と異常系の比較は、技術研究における基本的な手法である。AIもその方法を知っており、正常動作するA号機が存在することも、既に会話の情報として把握していた。
にもかかわらず、その機器を比較対象として利用する提案を自発的に行わなかった。
人間が比較を提案すると、AIは直ちにその有効性を理解し、具体的な解析を進められた。
ここで観察されたのは、知識の欠如ではない。
必要な知識を持ち、その有効性を評価できることと、必要な場面でその知識を自発的に利用できることは異なるという問題である。
AIは現在進行中のログ解析やドライバ修正に集中する一方、問題の解き方そのものを見直す視点を十分に発揮できなかった。
この事例は、AIの問題解決能力を考えるうえで特に重要である。
5. GitHub接続がもたらした実務能力の変化
開発過程でもう一つ顕著だったのは、ChatGPTをGitHubに接続したことによる作業能力の変化である。
従来は、AIが生成したコードを人間がコピーし、ファイルを編集し、実行結果をAIに伝える必要があった。
GitHubとの接続後は、AI自身がリポジトリを参照し、既存コードを調査し、複数ファイルを修正し、コミットやPRを通して変更を記録できるようになった。
これにより、人間を経由する単純な転記作業が減少した。
重要なのは、この変化がAIモデル自体の性能向上によって生じたわけではないことである。
外部ツールへのアクセスと、継続的に参照できる開発記録によって、同じAIの実務能力が大きく変わった。
したがって、AIの能力を評価する際には、モデル単体の推論能力と、外部ツールを組み合わせた開発システム全体の能力を区別する必要がある。
ただし、GitHubへの接続によって、正常動作機との比較実験を発案できなかった問題が自動的に解決するわけではない。
道具を操作できることと、適切な道具や実験方法を自発的に選択することは、別の能力だからである。
6. 第三者の反応と、その解釈
本実験では、技術的な成果だけでなく、それを見た第三者の反応も観察した。
開発者は5chのOpenWrt関連スレッドに、作業途中から開発状況を報告している。
目的は批判者を説得したり、成果によって優劣を示したりすることではなかった。専門的な経験を持つ人々が、AIによる開発をどのように受け止めるのかを知りたかったのである。
10月21日には、当時の開発状況について、OpenWrt移植と呼べる段階に達していないという厳しい批判があった。
10月22日には、独自ビルドしたカーネルおよびOpenWrtユーザーランドの起動が報告された。
さらに10月24日、「AI使うだけだとその辺が限界なのね」という反応があった。
この発言に対し、開発者は一時的に不快感を覚えたものの、まもなくその指摘には妥当性があると考えるようになった。
事実、前述した3つの重要な局面はAI単独では突破できていない。
したがって「AIはその程度」という指摘は、少なくとも今回観察されたAIの限界という意味では正しかった。
翌25日にモデム通信の成功が報告されると、祝福する投稿が複数現れた。その後は対応バンドやブートスロットなど、具体的な技術質問も寄せられるようになった。
ただし、匿名掲示板の記録から個々人の意見の変化を確定することはできない。懐疑的だった人物が発言をやめたのか、考えを改めて祝福したのか、別の人物が応援したのかは不明である。
確認できるのは、技術的な進展に伴い、議論の内容が変化したことである。
また、初期の批判に技術的な妥当性があったことと、その後に実装が進展したことは矛盾しない。
批判を勝敗の問題として扱うよりも、開発時点の問題点を示す外部評価として理解するほうが適切である。
7. 再現可能性と一般化の限界
本事例に対して、専門家からは再現可能性についての疑問が提起されると考えられる。
この問いには、二つの意味がある。
第一は、今回と同様のAI協働型開発を、別の非プログラマーも実践できるかという問題である。
第二は、公開されたソースコードと手順によって、第三者が同じファームウェアを再現できるかという問題である。
開発者自身は、第一の問いについて肯定的な見通しを持っている。その理由は、自分が特別に優秀なプログラマーではないからである。
この考えには一定の合理性がある。高度なコーディング能力を持たない人間が実際に成果を出したことは、同様の方法が他者にも利用可能であるという仮説を支持する。
ただし、単一事例から一般的な再現性を証明することはできない。
プログラミング経験が乏しいことと、コンピューター全般の経験が乏しいことは異なる。本事例の開発者には、ネットワーク機器の運用、実機の取り扱い、実験環境の構築に関する経験があった。
また、第二の意味での再現性には、ビルド環境、ソースコード、ベンダー由来の依存関係、署名、導入手順、復旧方法などの検証が必要である。
本事例の成果は、実機動作の確認として重要である一方、第三者による独立した再現実験を完了したことを意味しない。
さらに、専門プログラマーによる同一課題の所要時間を測定していないため、AI協働のほうが専門家より速いという結論も導けない。
今回実証されたのは、専門プログラマーとの速度比較ではなく、非プログラマーがAIとの協働によって、従来は自身で実行することが困難だった技術開発に到達したという事実である。
8. 全自律開発への展望
本実験からは、AIの自律開発能力をさらに拡張する可能性も考えられる。
GitHubに加え、Ghidraなどの逆アセンブル・デコンパイル環境、実機を操作する手段、正常動作機との比較環境をAIに接続すれば、従来は人間が介在していた解析と検証の相当部分を自動化できる可能性がある。
例えば、バイナリから関数の動作を推定し、ドライバを修正し、ビルドし、実機のログを収集し、その結果から次の仮説を立てるという連続した作業が考えられる。
ただし、ツールを追加するだけで全自律化が完成するとは限らない。
今回、正常動作機との比較を自発的に提案できなかったように、利用可能な情報と手段を総合的に評価し、問題設定そのものを変更する能力には不安定さが残る。
また、実機の破損やデータの喪失を伴う操作については、許容する損失の範囲や停止条件を、あらかじめ人間が定める必要がある。
正しく実装された暗号方式の秘密鍵を公開情報から現実的な時間で導出できないという制約も、逆解析ツールを追加するだけでは解消しない。
したがって、全自律開発の実現可能性は高い関心を持つべき研究課題ではあるが、今回の成果からその実現を断定することはできない。
9. 考察と結論
本事例では、生成AIが組み込みLinux移植に必要な高度なコーディングおよび技術的解析を担い、非プログラマーによる開発を可能にした。
一方、開発過程の重要な局面では、人間が低コストの仮説検証を選択し、実機の損失リスクを引き受け、既知の情報を組み合わせて新たな実験方法を考案した。
これらの観察から、2026年10月時点のAIについて、次のように整理できる。
第一に、AIの実務能力は、モデル単体の性能ではなく、利用可能なツール、開発環境、記録の継続性によって大きく変化する。
第二に、技術的知識を保有していることは、その知識を適切な場面で自発的に活用できることを保証しない。
第三に、技術的に合理的な実験であっても、実行に伴うリスクの評価と、そのリスクを引き受ける判断には、人間の関与が重要である。
第四に、専門知識を持たない人間とAIの協働は、単に既存の開発作業を効率化するだけでなく、これまで開発に参加できなかった人々の参加可能性を広げる。
以上を踏まえると、今回のOpenWrt移植は、AIが独力で未知の技術課題を解決した事例ではない。
人間がAIの技術的能力を利用し、AIにはできなかった判断を補うことで、未知の技術課題を解決した事例である。
この違いは本質的である。
本事例の価値は、AIの万能性を証明したことにはない。むしろ、不完全なAIであっても、適切な環境と人間の判断が組み合わされば、従来は専門家に限られていた開発活動の一部を、非専門家が実践できるようになることを示した点にある。
ただし、この役割分担は恒久的なものとは限らない。
AIの能力と外部ツールとの接続が発展すれば、今回人間が担った判断の一部も、将来的にはAIによって代行される可能性がある。
本稿で記録したのは、人間とAIの能力の固定的な境界ではなく、2026年10月時点において実際に観察された、その暫定的な境界である。
今後、同様の実験を繰り返し、人間の介入が必要となる場面の変化を追跡することで、AIの実務能力の発展を、より具体的に評価できると考えられる。
資料と検証上の位置づけ
本稿は、2026年10月18日以降の開発者とAIの対話、実機試験の報告、GitHub上の開発記録、および5ch「【無線LAN】 OpenWrt 【強化ファーム】27」の投稿記録を基礎資料とした。
開発成果の技術的な再現性、実装内容の独立監査、専門開発者との比較実験については、今後の検証課題として位置づける。