ITスキル0の男がiPhoneだけでアプリを作る④ 【AI運用#2開発編】

第2部　開発編

📖 今回の記事で分かること

* AIとの長期開発で起きたContext崩壊
* 引き継ぎ資料（Architect・Design）が必要になった理由
* AIより設計を管理する発想へ至った経緯
* 自分なりのAI長期運用スタイルが完成するまで

6.2000行の壁

コードが長くなるほど、
完成に近づいていると思っていた。

スロット期待値計算ツールも、
電気設備計算ツールも、
最終的にはどちらも2000行規模になっていた。

プログラミング未経験だった自分が、
AIを使うだけで
ここまで動くものを作れた。

それは事実として、
小さくない自信になっていた。

しかしその頃から、
別の問題が出始めた。

Claudeが重くなった。

チャットを続けるうちに、
レスポンスが遅くなる。

しばらくやり取りを続けると
利用制限に達する。

無料プランでは
5時間待たなければ
続きが書けない。

最初は、もどかしかった。

早く設計を進めたかった。

こんなに待つなら
課金してしまおうかとも思った。

しかし続けるうちに、
5時間という制限に
慣れてきた。

無料で使っている以上、
そういうものなのだろう。

そう割り切ってから、
逆に時間の使い方が決まった。

朝7時過ぎに実行して、
昼休憩の12時にまた再開する。

17時過ぎにまた実行して、
22時にまた動かす。

その待ち時間の間に、
次は何をどう設計すれば
改善できるか、
頭の中でゆっくりと考えた。

ChatGPTとも相談した。

そう考えると、
5時間の待ち時間は
思ったほどストレスではなかった。

コードが長くなるほど、
完成に近づいていると思っていた。

スロット期待値計算ツールも、
電気設備計算ツールも、
最終的にはどちらも2000行規模になっていた。

プログラミング未経験だった自分が、
AIを使うだけで
ここまで動くものを作れた。

それは事実として、
小さくない自信になっていた。

しかしその頃から、
別の問題が出始めた。

Claudeが重くなった。

チャットを続けるうちに、
レスポンスが遅くなる。

しばらくやり取りを続けると
利用制限に達する。

無料プランでは
5時間待たなければ
続きが書けない。

最初は、もどかしかった。

早く設計を進めたかった。

こんなに待つなら
課金してしまおうかとも思った。

しかし続けるうちに、
5時間という制限に
慣れてきた。

無料で使っている以上、
そういうものなのだろう。

そう割り切ってから、
逆に時間の使い方が決まった。

朝7時過ぎに実行して、
昼休憩の12時にまた再開する。

17時過ぎにまた実行して、
22時にまた動かす。

その待ち時間の間に、
次は何をどう設計すれば
改善できるか、
頭の中でゆっくりと考えた。

ChatGPTとも相談した。

そう考えると、
5時間の待ち時間は
思ったほどストレスではなかった。

原因を調べていくと、
少しずつわかってきた。

問題は2000行という数字ではなかった。

2000行すべてを一度に
AIへ理解させようとしていたことが
問題だった。

突然2000行のコードを渡されても、
全体を一瞬で把握するのは
人間でも難しい。

どこがUIなのか、
どこが計算処理なのか、
どこがデータ管理なのか。

役割を把握しなければ読めない。

AIも同じだった。

ならば、役割ごとに分ければいい。

UIはUI。

計算処理は計算処理。

データ管理はデータ管理。

それぞれを別々のファイルとして管理する。

今となっては当たり前の話かもしれないが、
当時の私はその発想自体を
持っていなかった。

身に染みてわかることがあった。

スロットのデータ参照機能が、
いつの間にか
丸ごと消えていたことがある。

ケーブル計算ツールでも
同じことが起きた。

自分では何も触っていない。

なのに、
あるはずのものがない。

一つのファイルにすべてを詰め込んでいると、
AIが修正する際に
何を残して何を消すか、
判断しきれなくなる。

コードが長くなるほど
設計も曖昧になる。

AIの理解も追いつかなくなる。

ならば、
分けるしかない。

そう納得するのに
時間はかからなかった。

調べていくと、
コンポーネントという考え方があることを
知った。

画面を作るもの、
計算を担当するもの、
データを扱うもの。

それぞれをフォルダ単位で整理し、
役割ごとに分けて開発する。

コードを分けることが目的ではなく、
責任を分けることが目的だった。

電気設備の現場で言えばわかりやすい。

分電盤の中で、
ブレーカーと配線とスイッチの役割を
ぐちゃぐちゃに混在させる人はいない。

それぞれが独立した場所に整理されているから、
点検も修理もできる。

ソフトウェアの世界では
これを「責務分離」と呼ぶらしい。

教科書からではなく、
「消えていたデータ参照機能」
を見て辿り着いた。

踏み切れない不安もあった。

それまで私は、
Claudeのアーティファクト上で
一つのアプリとして動くことを
確認しながら開発していた。

コードを細かく分割すると、
その場ですぐ動作確認できなくなるのでは
ないか。

本当に元どおり動くのか。

むしろ壊れてしまうのではないか。

ただ、
一つのファイルにまとめることの
弊害は身に染みてわかっていた。

分けた方がいい。

その納得が、
不安より少しだけ大きかった。

7.引継ぎという問題

重くなる原因がわかったことで、
一つ解決策に気づいた。

新規チャットを立ち上げれば、
コンテキストがリセットされる。

長く続いたチャットほど
AIが読む情報量は増え、
処理が重くなる。

ならば定期的に
新規チャットへ移ればいい。

実際、
新しいチャットで開発を始めると驚くほど軽い。

レスポンスも速くなる。

「これで解決だ」と思った。

しかしすぐに別の問題が出てきた。

新規チャットということは、
Claudeにとっては初対面だった。


それまで何百回とやり取りしてきた内容も、
設計思想も、
ファイル構成も、
すべて消えてしまう。

記憶を継承させない限り、
Claudeは何も覚えていない。


それはわかっていた。


しかし実際にゼロに戻ると、
別の不安が浮かんできた。

AIだけで大規模なプロジェクトを
進めることには、
構造的な限界があるのではないか。


引き継ぎをしたとして、
本当に漏れなく伝えられるのか。

ファイルを跨ぐということは、
コード間のどこかに
ズレが生まれるのではないか。

軽くなった代わりに、
別の不安が入ってきた。



そこで考えたのが、
AIへの引き継ぎ書を作る
という方法だった。

プロジェクト概要、
設計思想、
フォルダ構成、
これまでの経緯、
次にやること。

これらをまとめ、
新しいチャットの冒頭で読み込ませる。

今から振り返れば当たり前のやり方だが、
当時はAIに対して引き継ぎ書を書くという
発想自体が新鮮だった。

ただ、
新しい疑問も生まれた。

本当にこれで引き継げているのか、
という問いだ。

AIは引継ぎ書を読んでいる。

しかし、
細かな判断基準、
なぜその設計にしたのか、
以前の議論の流れ。

そういった背景は、
どうしても抜け落ちる。

毎回、
「本当に同じプロジェクトとして
続いているのか」という不安が消えなかった。

時間が経つと、
また別の問題が出てきた。

コンポーネント化を進めるにつれて、
ファイルが増えていった。

20ファイル、
30ファイル、
40ファイルと積み上がっていくと、
新規チャットを立ち上げるたびに
大量のファイルを説明し直さなければならない。

軽くなった意味が薄れてしまう。

結果、
また同じチャットで開発することが
増えていった。

重くなることはわかっている。
利用制限も来る。

それでも、
引き継ぎの手間を考えると
同じチャットの方が開発しやすかった。

しかし今度は、
チャットが長くなりすぎる。

昔の議論をAIが何度も参照する。

設計思想が少しずつ曖昧になる。

以前決めたことを忘れる。

コンテキストそのものが
劣化していくような感覚だった。

どちらを選んでも
別の問題が発生する。

二、三回それが続いた時、
Claudeも忘れるのか、
と思った。

アプリ作成に限界を感じて、
一時、諦めかけた。

8.設計思想の管理

投資ツールの開発を始めた頃、
ようやくClaudeの「Project」機能の
存在を知った。

たまたま見つけたものだった。

それまで私は
引継ぎ書だけを頼りにしていた。

フェーズに一区切りがついたら
チャットを切り替える。

その都度、
これまでの経緯をまとめたものを
Claudeに読み込ませる。

なるべく同一チャットで開発を続け、
重くなっても
そのまま生成し続けた。

整合性が合っているかどうか、
常に不安と隣り合わせだった。

そんな中で、
Project機能を見つけた時は
正直、かなり感動した。

ファイルそのものを
Projectに保存できる。

毎回書き直す必要がなくなる
可能性があった。　



運用方法を大きく変えた。

引継ぎ書だけでなく、
生成したコードもすべて
Project内へ保存することにした。

修正するたびに更新する。
新しいファイルができたら追加する。

最終的には60ファイル近いコードが
Project内に保存されるようになった。

変化は明確だった。

新規チャットを開くたびに感じていた不安が、
大きく減った。

Claudeは実際のコードを参照しながら
回答してくれる。

文章だけの引き継ぎ書より、
コードそのものが設計書になっていた。

ただ、
Project機能ですべてが
解決したわけではなかった。

Project内のファイルは共有される。

しかし、
チャットそのものは共有されない。

以前どんな議論をして、
なぜその設計を選び、
どんな経緯で今の構成になったのか。

そういった「思考の流れ」は
新規チャットのたびに失われる。


コードは読めても、
設計意図まで完全には伝わらない。

引継ぎ書そのものは、
結局必要だった。


引き継ぎ書を改善していく中で、
もう一つの考え方を知った。

ArchitectとDesignの責務分離だ。

最初はどちらも
同じような設計書だと思っていた。

最初のうちは
一つのファイルにまとめていた。

しかし仕様が変わるたびに
両方を書き直す必要があり、
それが思いのほか重かった。

どちらに何を書けばいいのか、
毎回迷った。

分けてみると、
ようやく役割の違いがわかった。

Architectは
プロジェクト全体の土台を書く場所だ。

何を目指すのか、
どんな思想で作るのか、
どのような原則を守るのか。

一方Designは、
各コンポーネントの役割、
ファイル構成、
実装方針といった
具体的な仕様を書く場所だ。

「なぜ作るのか」と
「どう作るのか」を
分けて管理する。

仕様が変わってもArchitectは触らない。
Designだけを直せばいい。

それがわかってから、
更新の手間が大きく減った。

この考え方を取り入れると、
新規チャットでも
設計思想が大きくぶれにくくなった。


そしてもう一つ、
思わぬ発見があった。

Markdownという形式だ。

Wordのような文書しか
触ったことがなかった私には、
最初は戸惑いがあった。

`#` を打てば見出しになる。
`-` を打てばリストになる。

装飾ボタンも、
フォント設定も、
何もない。

「これだけでいいのか」

拍子抜けするほど簡単だった。

しかし保存してAIに渡してみると、
Wordよりもずっと正確に
内容を読んでくれた。

容量も軽い。

引き継ぎ書のために使い始めたMarkdownが、
気づけば
設計書も履歴も思想管理も
すべて担うようになっていた。

振り返ると、
この頃から開発の考え方が変わっていた。

最初はAIにコードを書いてもらうことが
目的だった。

しかし今は違う。

重要なのは
AIが迷わない環境を作ることで、
そのための設計を作ることだった。

コードを書くことよりも、
AIが正しく開発を続けられる
仕組みを作る方が重要なのだと、
この頃から思うようになっていた。

9.自分の現在地

少し自信がついてきた頃、
ふと疑問が浮かんだ。

AIを使う人間として、
今の自分はどのくらいの位置にいるのか。

ChatGPTに率直に聞いてみた。

返ってきた答えは、
意外だった。

プロンプトを書くだけの段階は
すでに超えている。

実際に動くツールを作り、
設計し、
改善を繰り返している段階に入っている。

しかし、
まだ越えられていない壁があると
言われた。

「作る」
と
「世の中に公開する」
の間にある壁だ。

確かにその通りだった。

コードはある。
ツールも動く。

しかし誰にも使われていない。

ここを越えて初めて
次のステージに進めると感じた。

あわせて、
自分が作ろうとしているものの
難易度も聞いてみた。

おおよそこういうイメージだと言われた。

電気設備計算ツールが
最も基礎的な水準。

次が
スロット期待値計算ツール。

さらに上が
リアルタイムデータを扱う投資ツール。

そして最も難しいのが
競馬予測ツールだった。



最初は競馬とスロットを
同じような延長線上で考えていた。

しかし
実際には全く違う。

競馬では
出走馬、オッズ、馬場状態、過去成績、
血統、騎手、枠順と、
開催日ごとに変わる
大量の動的データを扱う必要がある。

静的な計算ツールとは
難易度がまるで違う。

あの頃、
何が起きているかわからないまま
ただ裏切られたと思っていた。

それがようやく、
構造の問題だったとわかった。

データが動的すぎた。

検証できる仕組みがなかった。

崩れて当然だった。

少し遅れて、
そういう理解が来た。

苦さというより、
日々少しずつ構造が見えてくる、
その楽しさに近い感覚だった。



そこで次の目標を決めた。

いきなり競馬ツールに挑戦するのではなく、
その前に一段階上げる。

投資ツールだ。

約3年前からNISAで資産運用を続けている。

オルカン、
S&P500、
NASDAQ、
金。

長期投資では
何を買うかより、
どの割合で持つかの方が重要になる。

しかし自分に合った配分を
考えるのは意外と難しい。

シミュレーションしたい。

リスクを見たい。

リバランス後の比率も知りたい。

そういうツールが、
探しても見当たらなかった。



振り返ると、
これまで作ってきたツールは
すべて同じ理由だった。

電気設備計算ツールも、
スロット期待値計算ツールも、
市場にあるものを
真似したかったわけではなかった。

自分が日常で使いたいものを
作っていただけだ。

だから次も同じだった。

欲しいものを、
自分で作る。

💡 今回得られた設計思想

* コードではなく設計を管理する
* AIより情報設計を整える
* 引き継ぎ資料もシステムの一部
* AIを管理する側へ回る