はじめに
世の中で「AIエージェントによるコーディング」が大きな話題になっています。
アプリ開発の経験がほとんどない私は、「本当に自分に一から作れるのだろうか？」とドキドキしながらも、話題の Claude Code を相棒に据えてアプリケーション制作への挑戦を始めました。
GeminiとChatGPTも安い方のプランを契約しているので、他のAIエージェント系ツールも使おうと思えば使えましたが、今回は好奇心から話題のClaude Codeを契約してみました。
「せっかく挑戦するなら、五目並べのような教材用のアプリではなく、自分が一時期ハマっていて思い入れのあるものを作りたい」
そんなモチベーションから選んだテーマは、趣味のTRPG（テーブルトークRPG）で愛用していたオープンソースのセッションツール**「ユドナリウム（Udonarium）」および派生ツール「ユドナリウムリリィ」**のリプレイスです。
まだプライベートリポジトリで、セキュリティリスクがないか怯えながら精査している段階ですが、実装の手前までなんとかたどり着いたので、知識ゼロの私が見よう見まねで進めた「実装前の準備プロセス」を記録として共有します。
対象読者
- AIエージェント（Claude Code等）を使った開発プロセスに興味がある方
- アプリ開発未経験からWebアプリケーションを作ってみたい方
- 既存のOSSをリプレイス・モダナイズして勉強したい方
1. 既存OSS（ユドナリウム）の設計から学ぶ
ユドナリウムはMITライセンスの素晴らしいOSSです。今回の開発の目的は、単に真似をすることではなく、「普段使っているツールがどのような仕組みで作られているのかを学び、最新のアプリケーション開発の知識を少しでも習得したい」という勉強の意味合いが大きいです。
(※形になったら、元のライセンスに基づいて派生作品として公開する前提で進めています)
まずは Claude Code に既存リポジトリのコードを読み込ませ、「どのような設計になっているのか」「初心者の自分が一から作るならどうアプローチすべきか」を洗い出してもらいました。
驚いた点：TRPGの特性を踏まえたブラウザ間のP2P設計
ユドナリウムの最大の特徴である「サーバーにデータを持たせないブラウザ間のP2P通信」という、TRPGの特性を捉えた素晴らしい設計思想を学びました。
サーバーにデータを上げることは著作権の都合上よろしくないので、ユーザー同士でデータ交換を行うことでデータ侵害を行わない設計になっています。
モダナイズへの挑戦：XMLからProtocol Buffers（Protobuf）へ
一方で、人数ややり取りが増えると全体的に通信負荷やメモリの使用量が上がるという課題も見えてきました（公式のIssueでもOOM（メモリ不足）が起きているという内容を見かけました）。そこで、AIと相談しながら以下の改善案を立てました。
- 変更内容: 元の設計で使われていたXMLを Protocol Buffers（Protobuf） へ変更
- メリット: データサイズが小さく・速く・シンプルに扱えるようになるため、通信量を削減して全体を軽量化できる
初心者の自分にとっては非常に画期的な発見で、設計を読み解くだけでも大きな学びになりました。
2. インフラエンジニア視点でのセキュリティ防衛策
アプリ開発については右も左も分からない状態ですが、普段インフラの仕事の一部で脆弱性対応をしている中で「最近はOSSライブラリのセキュリティリスク（サプライチェーン攻撃など）が増えている」という話だけは耳にしていました。
「AIに勧められるがまま、よく分からないライブラリをたくさん入れてしまうのが一番怖い」
そう思った私は、最初にClaudeへ以下のルールを提示しました。
⚠️ AIへの指示ルール
- 信頼性の高いライブラリのみを厳選して提案すること
- 導入するときは必ず「なぜそれを使うのか」を初心者にも分かるように説明すること
この防衛線を張ったおかげで、今のところ仕組み的にも無駄なライブラリが入っていない、非常にシンプルな構成を維持できていると考えてます。
裏でセカンドオピニオンAIにリポジトリをチェックさせたり、脆弱性チェックを行ったり、最近のPR（プルリクエスト）を見たりして不審なものがないかは一応チェックしています。ただ、そもそも「枯れた（十分に検証され安定した）ライブラリ」がメインで導入されていたので、現時点ではリスクはないと判断しました。
将来的には、レンタルサーバーなどにデプロイして色々な人に使ってもらったり、ブラウザだけでなく専用アプリ版も作れたらいいな、と夢を膨らませています。
3. マルチAI（Gemini / ChatGPT）のセカンドオピニオン活用
開発の知識がほとんどないため、Claude Codeの言っていることが本当に正しいのか、私には判断できません。また、Claudeとのやり取りだけでトークン（費用や制限）を消費してしまうのももったいないと感じました。（結構Opusを使っていたので、Claude Codeを存分に使うにはちょっとお財布事情が……笑）
そこで、裏でGeminiやChatGPTを「セカンドオピニオン」として併用することにしました。
| AIエージェント | 主な役割 |
|---|---|
| Claude Code（メイン） | 全体の設計、ドキュメント作成、実装フェーズの構築 |
| Gemini / ChatGPT（サブ） | 「これってどういう意味？」「リスクや懸念点はない？」の解説・翻訳役 |
明確な線引きはなく肌感覚での使い分けですが、知識がない状態だからこそ、複数のAIから違う見え方を教えてもらうことで、「なぜそうしていくのが良いのか」の理解が少しずつ深まっていきました。
このマルチAI体制で、以下の項目を一つずつ壁打ちしていきました。
- モダンなサーバーサイド／クライアントサイドの構成
- 技術的に問題となるポイントの洗い出し
- 開発手順、ルール、テスト戦略、GitHubでの管理方法
- CI/CD導入、ドキュメント管理、実装前に決めるべきことの網羅
4. 矛盾のない「詳細設計」の落とし込み
壁打ちが一通り終わった後、すべての要件をドキュメント一式にまとめ、「矛盾がないか」「リスクのある設計になっていないか」「拡張性が損なわれていないか」をAIに確認してもらいました。
さらに、いざ実装するときに毎回分厚いドキュメントを読み直して迷子にならないよう、実装のステップを細かく分けて、そのステップごとに必要な情報だけをまとめた「詳細設計」を作ってみました。
正直、自分にはまだこれらを正確にレビューする知識はありません。ですが、複数のAIにクロスチェックしてもらい「全体のデザインとして整合性は取れているよ」と言ってもらえたので、ひとまずは安心して次へ進むことにしました。
おわりに（まずは一歩、進んでみます）
ここまでが、知識ゼロの私が見よう見まねで進めてきた「実装前の準備」のすべてです。
ただAIに「作って」と丸投げするのではなく、既存の素晴らしい設計を学び、分からないことは別のAIに聞き、慎重にロードマップを作る。この準備のプロセス自体が、私にとっては本当に良い勉強になっています。
今回は練習と勉強を兼ねた挑戦です。完璧を求めすぎて立ち止まってしまうよりは、せっかくAIが一緒に作ってくれたこの設計図を信じて、まずは一歩、実装のフェーズへ進んでみようと思います！
最後まで読んでいただきありがとうございました。進捗があれば、また記事にしたいと思います。