はじめに

仕事の合間に、Windows向けの電子書籍管理・閲覧アプリ「LibroDeck」をAIの支援を受けながら開発しています。
実際に開発していた期間はおよそ7か月です。規模もかなり大きくなり、現在では約27万行のコードを持つアプリになりました。

この開発には、もう一つ個人的な実験テーマがありました。
「AIの従量課金APIを使わず、月額およそ3,000円の範囲だけで、個人開発をどこまでスケールさせられるのか？」というものです。大きな事業計画があって始めたというより、「今のAIを使えば一人でどこまで行けるのだろう」という好奇心から始まりました。
※ここでいう費用には、自分自身の作業時間は含めていません。

そしてここまで開発して強く感じたのは、ある程度以上の規模になると、「AIにコードを書いてもらうこと」より「既存の機能を壊さず変更してもらうこと」の方が難しいということでした。

開発初期には、「このボタンが動かない」「表示がおかしい」「処理が重い」と症状を説明し、そのまま原因の調査と修正をAIへ依頼することも多くありました。小さいうちは、それでもかなりうまくいきます。

ところが機能が増えると、ある場所を直したら別の機能が壊れる、小さなデータでは正常なのに大量のデータでは急に重くなる、AIがもっともらしい原因を提示したものの実測すると別の場所が原因だった、といったことが増えていきました。

そこで途中から、AIへの頼み方そのものを変えることにしました。

この記事では、その過程でどんな失敗をし、どのような開発方法へ変えていったのかを書きます。
そして後になってOpenAIの「Harness Engineering」という記事を読んだとき、自分が失敗するたびに追加してきた仕組みは、かなり近い方向を向いていたのではないかと気付きました。

補足：早期販売につき、しばらく無料期間（9/3 19:00～9/6 24:00）とします。

最初は「症状を伝えて直してもらう」だけだった

AIを使った開発を始めたころの流れは単純でした。
たとえば「フォルダを切り替えたら画面がおかしくなるので直してください」と伝える。するとAIは関係しそうなコードを調べ、原因らしきものを説明し、修正案を出してくれます。
実際、それで直ることもかなり多くありました。
問題は、アプリが大きくなってからです。
一つの画面だけでも、表示、検索、並び替え、複数選択、サムネイル、フォルダ切り替え、グループ化、スタック化、右クリック操作など、さまざまな処理がつながっています。
表面上は一つの不具合でも、裏では複数の状態や処理が関係しています。この状態で「たぶんここが原因だろう」と一か所だけ変更すると、目の前の症状は消えても別の経路を壊すことがありました。

一番怖かったのは「もっともらしい原因」

AIが明らかにおかしな回答をすれば、こちらも警戒できます。
むしろ厄介だったのは、説明として非常に筋が通っている場合でした。
以前、8万件近く登録されているライブラリなのに、画面では5,000件程度しか認識されなくなったことがあります。
表面だけを見れば、データベース、読み込み処理、画面側の表示上限など、いくらでも原因を想像できます。しかし規模の大きなアプリでは、この「想像」をそのまま修正につなげるのは危険でした。
実際には処理経路や絞り込み状態、一定条件で別の処理へ切り替わる箇所などを追いながら、原因を少しずつ絞る必要がありました。
別のときには、サムネイル周辺の処理が遅くなりました。最初からデータベースを疑うこともできますが、実際に計測すると、データ取得後に同じ種類のパス処理が大量に繰り返されている部分へ原因を絞れました。
ここで痛感したのが、「もっともらしい原因」と「確認できた原因」は別物だということです。
これは人間同士の開発でも当然の話です。ただ、AIはもっともらしい説明を非常に速く作れるため、かえって「説明が自然だから正しい」と思い込まないことが重要だと感じました。

「直してください」から「まず証拠を取ってください」へ

そこで、途中から手順を変えました。
以前は、症状を説明して原因を考え、そのまま修正するという流れでした。
それを、症状を説明した後に関係するコードを調べ、必要ならログを追加し、問題を再現し、原因を絞り、修正した場合に影響しそうな場所を確認してから手を入れる流れへ変えました。
遠回りに見えますが、規模が大きくなってからはこちらの方が結果的に速くなりました。
一回の修正で終わらず、「直ったと思ったら別の場所が壊れた」「原因ではない場所を何度も修正した」となる方が、はるかに時間を使うからです。
AIへの依頼も、「直してください」だけではなく、「まず原因を確認してください。情報が足りなければ、原因を切り分けるためのログを追加してください」という形が増えていきました。

「動く」だけでは合格にできなくなった

もう一つ大きかったのが、データ量です。
LibroDeckでは大規模なライブラリも扱えるようにしたかったため、数万件単位のデータを扱うようになりました。
ここでは、1,000件で快適に動いたから大丈夫とは言えません。
ある処理が3万件では問題なくても、10万件になると急に待ち時間が増える。30万件まで増やすと、それまでの処理方法では厳しくなる。そうしたことが実際に起こります。
そのため途中から、3万件、10万件、30万件と段階を分けて性能を確認するようになりました。
機能が正しく動くかだけでなく、データ量が増えたときにも実用的な速度を保てるかを確認対象にしたということです。
AIへ修正を依頼するときも、「正しく動けばよい」だけではなく、「この修正によって、大規模ライブラリ向けの処理を重くしていないか」まで考える必要が出てきました。

毎回全部を確認するのではなく「今回どこが壊れそうか」を考える

機能が増えると、変更するたびにアプリ全体を最初から最後まで手動確認するのは現実的ではありません。
そこで重要になったのが、今回変更した場所から、どこへ影響が広がる可能性があるかを先に考えることでした。
たとえば選択処理を変更したなら、単体選択だけでなく、複数選択、ドラッグ選択、右クリック、グループ化された表示、大量データ時の表示なども確認します。
サムネイル処理を変更したなら、ライブラリ登録直後だけでなく、高速スクロール、大量登録、フォルダ切り替えなども確認します。
こうした確認を毎回ゼロから考えるのも大変なので、繰り返し確認する部分については自動確認用のスクリプトも少しずつ増やしていきました。
するとAIにも、「今回ここを変更したので、この既存確認も必要です」といった形で作業を任せやすくなります。

製品化すると、コードの外まで確認対象になった

2026年6月ごろ、LibroDeckを実際に製品として公開することを考え始めました。
ここから確認対象はさらに広がりました。
アプリが正常に起動するだけでは足りません。インストーラで正常に導入できるか、Windows実機で問題がないか、ウイルス対策ソフトからどう見えるか、必要なファイルが配布物に揃っているか、ライセンスや利用規約に問題がないか、最終的に配布するファイルが確認済みのものと同じか、といったことまで見る必要があります。
自分だけで使うアプリと、人へ渡すアプリでは、「完成」の意味がかなり違うのだと実感しました。

後からHarness Engineeringという言葉を知った
そんな開発を続けている中で、OpenAIが2026年2月に公開した「Harness Engineering」の記事を読みました。
そこでは、AIに単発の指示を与えることだけではなく、AIが仕事を進めやすいように環境を整え、必要な情報や道具を与え、守るべき境界を明確にし、自分で結果を確認できるフィードバックの仕組みを作ることが重視されていました。
読んだとき、自分が失敗するたびに増やしてきた仕組みとかなり近いと思いました。
もちろん、個人開発のLibroDeckとOpenAIの開発規模や方法を同列に語るつもりはありません。
ただ、「AIがもっと賢くなれば全部解決する」という方向ではなく、AIが正しく仕事をしやすく、間違ったときにも自分や人間が気付ける環境を作るという方向へ、失敗を繰り返した結果として自然に近づいていた点がとても興味深く感じられました。

まとめ

AIのおかげで、個人でも以前なら考えにくかった規模のアプリを作りやすくなりました。
一方で、規模が大きくなるほど、コードを生成する能力以上に、変更を安全に積み重ねる仕組みが重要になるとも感じています。
自分の開発で特に効果があったのは、原因を推測したまま直さずまず証拠を取ること、修正前に影響しそうな範囲を考えること、小規模データだけで性能を判断しないこと、繰り返し確認する場所は自動化すること、そして最後はコードだけでなく配布物まで確認対象にすることでした。
AIをより自由に使うためには、AIへの指示を工夫するだけではなく、AIが失敗しにくく、失敗しても気付ける環境を作ることが必要になります。
後からHarness Engineeringという言葉を知って、自分が試行錯誤していたものの輪郭が少し見えたように感じました。

最後に

本記事の題材となった LibroDeck は、Windows向け電子書籍・コミック管理／閲覧アプリとしてEarly Access版を公開しています。
興味を持っていただけた方は、こちらからご覧いただけます。
LibroDeck（BOOTH）: https://libro-deck.booth.pm/items/8628000

Zennでも話の趣旨（開発記ベースに）を変えて投稿しています。
Zenn : https://zenn.dev/xneshuk/articles/525560356a3737