ChatGPT(5.2)と一緒にC++/NASMで自作OSを作っている話
― 設計判断は人間、実装と解析はAI。頼れる相棒として ―
※この記事は「AIにすべて丸投げして楽をしている」という話ではありません。
設計判断・方針決定・検証責任は人間が持ち、実装と観測・解析を ChatGPT（5.2）に委ねている
自作OS開発の実例を、その関係性も含めて記録したものです。
はじめに
私は現在、**C++ と NASM で x86_64 向けの自作OS（JadeKernel）**を開発しています。
そしてこのプロジェクトは、かなり特殊な進め方をしています。
- 実装・コーディングの大部分：ChatGPT（5.2）
- 設計判断・方向性決定・修正適用・QEMU検証：私（人間）
いわば、
AIが実装者兼解析者、人間が設計判断者兼検証者
という役割分担です。
なお補足として、私は「C++がまったく分からない状態でAIに投げている」わけではありません。
C++はある程度習得しており、提示されたコードを読んで設計や副作用を判断したり、差分の適用・検証を回すことはできます。
ただし今回のプロジェクトでは、
私自身がコードを書く役割を意図的に手放し、AIの出力を統合・判断する側に寄せている
というのが実態です。
私は「コードを書いていない」
体感ではなく、事実としてこう言えます。
私は 手でコードを書くことをほぼしていません。
ChatGPT（5.2）が提示したコードを読み、
- 採用するか
- 設計として許容するか
- どの粒度で入れるか
- どこまで巻き戻すか
を判断し、適用・ビルド・起動・ログ観測を行っています。
つまり私は、
- エディタで関数を書く人
ではなく - 設計と結果に責任を持つ人
という立場です。
コード規模について
現在のコードベースは、
- コメントや日本語フォント設定コード（約14,000行）を含めて
- 総行数 50,000行超
になっています。
自作OSとしては珍しくない規模ですが、
個人開発・非公開プロジェクトとしては十分に大きいコード量です。
そして重要なのは、
その大部分を ChatGPT（5.2）が生成しているという点です。
ChatGPT（5.2）は「頼れる相棒」
このプロジェクトにおいて、ChatGPT（5.2）は単なるツールではありません。
- C++ / NASM の実装生成
- 割り込み・タスク・イベント周りの設計案提示
- serial / debugcon / GUIログの解析
- 「今見えている現象から、どこが怪しいか」の切り分け
- 修正案の複数提示（A/B/C案）
観測結果の解析もAIが行っています。
私はログを貼り、
ChatGPT（5.2）がそれを読み、
「次にどこを見るべきか」「何を消すべきか」を提案する。
その提案を 採用するかどうか決めるのが人間。
このやり取りを続けていると、
感覚としては「便利な自動生成ツール」ではなく、
かなり優秀だけど癖のある相棒に近くなってきます。
面白いのは、AIも普通にミスをすること
これは実際に使ってみて、かなり強く感じた点です。
ChatGPT（5.2）は非常に優秀ですが、万能ではありません。
- コード片にゴミが混ざる
- 実装が一部足りていない
- 設計が途中でぶれて、不要な関数や変数を追加する
- 以前に否定した設計を、別の文脈で復活させてくる
こういうことは、普通に起きます。
そのたびに私は、
- 「この変数、どこで使う前提？」
- 「その責務、前に分離したよね？」
- 「この関数、なくても成立しない？」
と疑問を投げ、指摘します。
するとAIは、
- 設計意図を説明し直したり
- 自分の提案を撤回したり
- より単純な形に修正案を出したり
します。
このやり取りがあるからこそ、
設計が少しずつ研ぎ澄まされていく。
AIがミスをするからこそ、人間が設計判断を放棄できない。
逆に言えば、この緊張関係が成立している限り、開発は前に進みます。
設計方針は常にAIと相談して決めている
設計は私が独断で決めているわけではありません。
むしろ毎回、
- 責務をどう分けるか
- どこを観測点にするか
- いま直すべきか、まず可視化すべきか
- 一時的に機能を止めるべきか、粘るべきか
を ChatGPT（5.2）と相談して決めています。
AIに「選択肢とトレードオフ」を整理してもらい、
その中から このプロジェクトとして筋が通る案 を人間が選ぶ。
最終判断は人間、
判断材料の整理と見落とし防止はAI。
この役割分担が崩れると、たぶん開発は破綻します。
いま詰まっている理由（正直な話）
ここ数日、かなりしんどかったです。
- ターミナル（Shell / TerminalWindow）周りを改修した直後
- 入力が通らない／通っているのに表示されない
- 再描画問題と入力問題が絡み合って、原因が見えない
- 同じような修正と観測を何度も繰り返している感覚
正直、「もうやりたくない」と思いました。
でも冷静に考えると、理由ははっきりしています。
見えない状態で、同じ所を殴り続けていた
自作OS開発で、多くの人が一度は引っかかる通過点だと思います。
方針転換：直す前に、見えるようにする
ターミナルが嫌いになったわけではありません。
投げたいのはターミナルそのものではなく、
見えないまま試行錯誤し続ける状態
これです。
いまの方針はこうです。
- Terminal / Shell の修正はいったん止める
- 機能追加もしない
- 入力・イベント経路の透明化を先に完成させる
「直す前に、必ず“どこで死んでいるかが一発で分かる状態”を作る」
この判断も、ChatGPT（5.2）と相談したうえで決めました。
技術メモ：いま何を観測しているか（抜粋）
固定トレース（InputTrace）
1キー入力で経路が分かるようにするための固定文字です。
-
K: キーボードIRQに到達 -
P:Events::post()に入った -
X:accept_input == falseで破棄 -
N: Keyイベントだが route が無く破棄 -
Q: キュー投入＋wake完了 -
D: Shellがdrainで1件取得
ログを読むのではなく、
文字を見るだけで分岐が分かるようにしています。
状態ダンプ
accept_inputroute_key- Shell task の
pending_mask - イベントキューのサイズ
「何が起きたか」ではなく、
いまの状態がどうかを観測します。
このやり方について思うこと
この進め方は、万人向けではありません。
- 自分でコードを書きたい人には向かない
- AIの出力を無批判に信じると危険
- 判断を放棄すると一瞬で破綻する
でも、
- 設計と検証に集中したい
- 巨大なコードベースを一人で抱えたくない
- 自作OSという「しんどい趣味」を、少しでも前に進めたい
そういう人間には、意外と合っています。
少なくとも私は、
ChatGPT（5.2）がいなければ、ここまで来られなかったのは間違いありません。
おわりに
いまはまだ、完成には程遠いです。
むしろ「やっと地雷原の入口が見えてきた」くらい。
でも、
- どこで入力が殺されているか
- なぜ再描画が暴れるか
- 何を先に直すべきか
それを 見える形で判断できる状態 には、確実に近づいています。
AIという相棒は万能ではない。
でも、問いを投げ続ければ、ちゃんと一緒に考えてくれる。
次は、また少し前に進むだけです。