パソコンがない。それでも資産運用アプリを作りたかった【AI運用#3資産運用編①】

第3部　資産運用編　

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

* AI開発が速くなった本当の理由
* iPhoneだけで開発を続ける中で生まれた設計思想
* AIを役割ごとに使い分けるようになった経緯
* Claude・ChatGPT・Geminiを連携させる発想
* 競馬ツール開発の経験が、なぜ投資ツール開発へつながったのか
* 「予測」ではなく「検証」を重視するようになった理由

1. AIが速くなった理由＝コード≠設計だった。

前回までの話でこのときは
投資ツールを作ろうと考えていた。

具体的には資産運用の最適化アプリだ。
資産運用アプリの開発を始めた頃、
私には一つだけ絶対条件があった。

「iPhone一本で快適に動くこと」

パソコンを持っていない。

開発環境はiPhone一台だけだ。

ただ、
iPhoneで実際に処理を走らせたことはなかった。

だからこそ、
疑問があった。

手元のiPhoneのスペックで、
果たしてこの処理量を
捌き切れるのだろうか。

重くなってから考えるより、
最初から軽くなる設計を選んだ方がいい。

そう思って調べていくと、
役割分担にはもう一つ大きな意味があることを
知った。

UIの中で重い計算をしない、
ということだ。

画面を表示する役割と、
計算する役割は分ける。

複雑な計算はWorkerへ渡す。

処理を分散することで、
iPhoneのような限られた環境でも
快適に動作させられる可能性がある。

スロット期待値計算ツールや
電気設備計算ツールで
巨大なコードを分割してきた経験が、
ここでも役立った。

もう一つ感じたことがある。

アーキテクチャを最初にしっかり決めておくと、
開発が進んでも思想がぶれにくい。

逆に、
土台が曖昧なまま開発を続けると、
その場しのぎの修正ばかりになってしまう。

まず構造を決める。

その上でコードを書く。

この順番を意識するようになった。



しかし、
別の問題も出てきた。

詳細設計書であるDesign.mdは、
開発が進むたびに更新が必要になる。

ファイルが増える。

仕様が変わる。

細かな修正が入る。

更新のたびに気になることがあった。

トークンの消費量が、
ほとんど変わらないのだ。

本来は設計を整理することで
AIへ渡す情報を軽くするはずだった。

しかし修正のたびに
設計書を書き直していると、
結果的にトークン消費量は
以前とさほど変わらない。

軽くするための作業が、
重さを生んでいる。

そこで考えた。

もっと更新頻度が少なく、
全体像だけを把握できる資料は
作れないだろうか。

それがSystem Map.mdだった。

目的は単純だ。

AIにコードを全部読ませる前に、
まず全体構造を理解させること。

どのフォルダがあり、
どのファイルがあり、
それぞれがどんな役割を持っているのか。

それを一枚で
把握できるようにした。

人間でも、
初めて見るシステムは
地図があった方が理解しやすい。

AIも同じだった。



System Mapを作ることで、
もう一つ大きな変化が起きた。

以前は、
Project内にある90以上のファイルを
ほぼ全部読み込ませていた。

しかし
System Mapを見ながら、
今回の修正に何が必要かを
判断できるようになった。

「今回必要なファイルだけをProjectへ登録する」
という運用も始めた。

すると、
90以上あったProjectファイルは
10ファイル前後まで減らせることがわかった。

必要最小限の情報だけを
AIへ渡す。

この方が、
圧倒的に軽く、
そして正確だった。



さらにProjectには、
プロジェクト全体へ適用される指示を
書く場所がある。

ここへArchitect Principleを
書き込むようにした。

これは詳細設計ではなく、
「このプロジェクトは何を大切にするのか」
「どんな原則を守るのか」
という憲法のような存在だ。

この原則を最初に持たせることで、
細かな実装が変わっても、
AIの判断基準はぶれにくくなった。

この頃から考えが変わっていた。

情報は多いほど良いと思っていた時期は、
コードも全部渡す、
設計書も全部渡す、
履歴も全部渡す、という運用だった。


しかし
実際には逆だった。


AIに必要なのは
大量の情報ではない。

必要な情報を、
必要なタイミングで渡すことだった。

AI開発とはコードを書く技術ではなく、
情報を設計する技術なのだと、
この頃から考えるようになった。

2.iPhoneだけで開発環境を組み上げる

Project機能を使うようになり、
Claudeでの開発はかなり安定してきた。

しかし
もう一つ大きな課題が残っていた。

生成したコードをどう管理するか、
だ。

Claudeが生成したコードは、
そのままチャットに置いておくだけでは
管理できない。

どうすればiPhoneだけで
ファイルとして保存し、
整理できるか。

AIに聞いた。

iPhoneという環境を伝えた上で、
最適なやり方を教えてほしいと頼んだ。

出てきたのがKodexだった。

この開発を通じて知ったツールの多くが、
そういうAIきっかけだった。

Claudeで生成したコードをコピーし、
Kodexで拡張子を付けて保存する。

JavaScriptなら.js、
Markdownなら.md。

こうして一つずつ
ファイルとして保存していった。

コードの冒頭には
「どのフォルダへ保存するか」
が書かれていたため、
保存場所に迷うことはほとんどなかった。



保存したコードは、
iPhoneの「ファイル」アプリで管理した。

UI、
Worker、
Components、
Utilities。

フォルダごとに整理していくと、
それぞれが何の役割を持っているのかが
少しずつ理解できるようになった。

最初は一つの巨大なコードにしか
見えなかったものが、
ファイル単位で眺めることで
ソフトウェア全体の構造が
見えるようになっていった。

次は
GitHubへの連携だった。

第1章で躓いたあの問題が、
また目の前に立ちはだかった。

iPhoneから直接GitHubへ
ファイルをアップロードするのは、
想像以上に扱いづらかった。

またAIに聞いた。

iPhoneだけという環境を前提に、
一番使いやすい方法を教えてほしいと。

出てきたのがWorking Copyだった。

Working Copy経由でGitHubへPushする。

この流れが私にとっては
最も分かりやすかった。

ようやく
「ローカルで作る」
から
「GitHubで管理する」
という開発者らしい流れが
少し見えてきた気がした。



GitHubへPushすれば、
その先はVercelで公開できる。

GitHubは保管庫、
Vercelは公開場所。

そんなイメージだった。

しかし、Pushすることにはまだ慎重だった。

Vercelには期限がある。
費用もかかる。

公開した以上、
中途半端なものは出せない。

自分の中で
「修正することがない」
と確認できるまでは、
GitHubへ上げるつもりはなかった。

ツールとしての出口は見えた。

ただ、
その扉を開けるタイミングは、
まだ来ていなかった。

Project機能のおかげで
新規チャットへ移れば軽くなることはわかった。

しかし開発が進むにつれ、
また別の問題が現れた。

Project内のファイル数が
90近くまで増えてしまったのだ。

新しいチャットを作っても、
以前ほど軽くならない。

ClaudeはProject内のファイル全体を
参照しながら回答しているため、
チャットは新しくても
Project自体が巨大化していた。



不要なファイルを外すと
動作は改善した。

しかし今度は
別の不安が生まれる。

本当にそのファイルを
外していいのか。

設計思想まで
失われないか。

軽くすることと
引き継ぎを維持することは、
常にトレードオフだった。


この頃には、
情報の扱い方についての考えが
はっきりと固まっていた。

不要な情報は持たせない。

必要な情報だけを渡す。

90ファイルが10ファイルになって
はじめてそれが証明された。

AI開発とはコードを書く技術だけではなく、
AIが迷わない情報量を設計する技術でもある。

そう実感として言えるようになったのは、
この時期からだった。

3. コード開発だけではなかった。AIの使い方そのものが変わった。

Project機能やMarkdownを使いながら、
AIによるコード開発を
効率化することばかり考えていた。

しかしある時、
一つのことに気づいた。

この考え方は、
コード開発だけの話ではない。

もっと幅広く
使えるのではないか。



当時、
私は毎日の出来事をChatGPTへ音声入力し、
日記を書き続けていた。

期間にすると約2か月ほどになる。

その日にあったこと。
感じたこと。
仕事。
育児。
考えたこと。

それらを音声で話し、
ChatGPTが文章として
整理してくれる。

そんな使い方を続けていた。

最初は非常に満足していた。

しかしある日、
過去の日記を読み返していて
ふと引っかかることがあった。

固有名詞の表記が
前と変わっている。

漢字の使い方が
自分のものではない。

文章としては成立している。

しかし、
「これは自分が書いた文章ではない」
という感覚が、
じわじわと広がった。

チャットが長くなるにつれ、
AIの出力の質が
明らかに変わっていた。

コード開発と同じだった。

チャットが長くなるほど、
AIの精度が少しずつ落ちていく。

そこで私は、
コード開発で使っていた方法を
試してみた。

日記用のProjectを作る。

そして日記を書く時の基本ルールを
Architectとして
Markdownにまとめた。

どんな文体にするのか。
どんな温度感で書くのか。
どんな表現を避けるのか。
何を大切にするのか。

そうした基本方針を
Projectへ登録した。

すると、
新しいチャットになっても
以前とほぼ同じ雰囲気の日記を
書けるようになった。

毎回AIに
説明し直す必要が
ほとんどなくなったのだ。

さらに試してみると、
この方法は日記だけではなかった。

子育ての相談、
家庭の出来事、
仕事の相談、
長期的に続けるテーマ。

それぞれ専用のProjectを作り、
Architectや必要な情報を
Markdownで管理する。

するとどのProjectでも、
毎回ゼロから説明し直す必要が
なくなっていった。

コード開発だけの工夫だと思っていたものが、
日常生活でも同じように
使えることがわかった。

後になって調べると、
これはRAG
（Retrieval-Augmented Generation）
という考え方に近いことを
していたのだと知った。

もちろん厳密には
同じ技術ではない。

しかし
「AIに全部覚えさせる」
のではなく
「必要な情報を必要な時に参照させる」
という発想は共通していた。

当時の私は
RAGという言葉すら
知らなかった。

ただ試行錯誤の中で、
自然とその運用方法を
作っていた。

AIを使いこなすということは、
プロンプトを書く技術ではなく、
情報を設計し
必要な時に取り出せる環境を作る技術なのだと、
この頃から考えるようになった。

4. AI同士を連携させる発想

ここまで試行錯誤を続ける中で、
実際の運用はClaudeだけで
完結していたわけではなかった。

設計、
プロンプト、
必要なファイルの選定、
システムマップの整理。

これらは主にChatGPTと
一緒に考えてきた。

そして実際のコード生成は
Claudeが担当する。

そんな役割分担が
自然と出来上がっていった。


ChatGPTとClaudeでは
Project機能の仕様は異なる。

しかし考え方は同じだった。

ProjectにはArchitect Principle、
Design、
System Map、
Historyという
4つのMarkdownファイルを
整理して登録した。

するとChatGPTも
プロジェクト全体の思想を
理解した上で
考えてくれるようになった。

単にコードを見るだけではなく、
「なぜこの設計になっているのか」
「これまでどんな経緯で
ここまで来たのか」
という背景も踏まえて
提案してくれるようになったのだ。

特に効果を感じたのが
Historyだった。

過去にどんな判断をしたのか。
なぜその設計を選んだのか。
何を失敗したのか。

これらを残しておくことで、
以前と同じ議論を
繰り返すことが少なくなった。

AIも過去の判断を踏まえた
提案ができるようになった。

結果として、
プロジェクト全体の方向性が
ぶれにくくなった。

ChatGPTはClaudeほど
利用制限に悩まされることは
少なかった。

しかしClaudeで生成した
大量のコードを丸ごと貼り付けて
評価させるような使い方をすると、
やはり徐々に重くなっていく。

ChatGPTでも、
情報を持たせ過ぎれば
同じ問題が起きた。

AIが違っても、
限界の構造は同じだった。


Architect、
Design、
System Map、
History。

これらを情報源として
整理しておけば、
新しいチャットになっても
以前とほぼ同じ前提条件で
議論を続けられる。

ClaudeでもChatGPTでも。

AIは違っても、
プロジェクトの土台は変わらない。

この運用方法によって、
どちらのAIを使っても
設計思想がぶれることは
ほとんどなくなった。

面白かったのは、
AI同士がお互いを
補完し始めたことだ。

ChatGPTが今回の修正に必要なファイルを
5つに絞って提案してくる。

そのままClaudeにProjectを渡して
コードを生成させると、
「この処理には、
もう一つこのファイルが必要ではないか」
という指摘が返ってくる。

ChatGPTが削った部分を、
Claudeが拾い直す。

どちらか一方だけでは
気づかなかったことが、
二つを組み合わせることで
見えてくる。

そんな場面が
少しずつ増えていった。


最初は
「どのAIが一番優秀なのか」
という視点で見ていた。

しかし実際には違った。

最初の頃、
Geminiに何でも頼ろうとして崩れた。

今は違う。

設計はChatGPT、
コード生成はClaude。

それぞれの特性に合わせた
役割を与えている。

重要なのは、
最強のAIを探すことではない。

AI同士が同じ設計思想を共有し、
それぞれの得意分野を活かすこと。

その設計こそが、
AI運用の本質だと
今は思っている。

💡 今回得られた設計思想

* コードより設計を先に考える
* 制約は設計を磨く
* AIは一人で使うより、役割分担した方が強い
* AIに記憶させるのではなく、設計に記憶させる
* 予測を信じるのではなく、自分で検証できる仕組みを作る