Voice Of The World（VOTW）開発記の最終回（第6回）です。
- 前回のエントリ：多言語読み上げブラウザVOTWをAndroid向けに作った話(5)
- Google Playにて配信中：Voice Of The World(GooglePlay)
本当は先月頭には公開しているはずだった記事なんですが、後述のiOS版のバタバタで、すっかり遅くなってしまいました。
AIエージェントを「実用的な相棒」にする
今回のエントリを最終回に据えるにあたり、何を書こうか少し迷いました。最新AIを使った一般的なコード生成やリファクタリングの話なら、すでに先輩諸兄が役に立つ記事をたくさん書いておられるからです。
ですので今回は、「個人開発というシチュエーションにおいて、VOTWの開発・運用にAIをどう役立てたか」という、少し泥臭い、でもリアルなお話をしたいと思います。
第1回でも触れましたが、VOTWは前身となるアプリが存在し、「AIの力を借りればメンテナンスコストを下げられそう」という動機で再始動したプロジェクトです。個人開発である以上、リソースには以下の厳しい制約がありました。
- 継続的なOS対応の負担：既存コードの仕様は把握しているが、毎年のように変わるAndroid（やiOS）のAPIバージョンアップに追従するコストが高い。
- 翻訳コストの壁：海外展開したいが、プロの翻訳者に依頼する予算はない。かといって従来の機械翻訳では品質に不安が残る。
- 広報・ストア資材の不足：ストア公開用のスクリーンショットなどを、著作権を気にせず見栄え良く用意したい。
- マルチプラットフォーム展開：できればiOS版も出したい。
AIは、これらの「個人開発あるある」な壁を驚くほどあっさりと越えさせてくれました。
1. ツール系アプリの「難民化」を防ぐための継続メンテナンス
スマートフォン向けアプリを継続的に提供することは、モチベーションの維持という観点から非常に困難です。特に無料アプリの場合、無報酬のまま長期間メンテナンスを続けるのは至難の業といっていいと思います。作るのは楽しいので、最初は頑張るのですが。
ゲーム系アプリであれば、ユーザーが一通り遊んで飽きた頃に「アプリの旬」が終わりますが、息の長いツール系アプリは事情が異なります。
作者のモチベーション低下や環境の変化でメンテナンスが止まり、OSのバージョンアップで動かなくなる。類似アプリが豊富なジャンルなら乗り換えられますが、ユニークで代替のきかないアプリの場合、ヘビーユーザーが「難民化」してしまう事態がちょくちょく見られます。手に馴染んだツールからの移行は、ユーザーにとっても苦痛だからです。
個人的には、AIのアシストによって「バグの一次調査や修正コードの提案」「最新API追従のためのコード提案」のコストが劇的に下がることは、結局はアプリの寿命を延ばし、アプリ難民問題を解決しうる重要なピースだと思っています。
2. GeminiとClaudeに「相互レビュー」させる多言語翻訳
VOTWは読み上げの自動言語判別に8ヶ国語対応しているため、UIも今回8ヶ国語に対応させました。
業務系アプリならプロに依頼するのが当然ですが、個人開発ではそうもいきません。そこで、一定の品質を担保するために、GeminiとClaude Codeで日本語と各国語の対訳表を作り、互いに相互レビュー（クロスチェック）させるという手法をとりました。
また、単に「翻訳して」と投げるのではなく、エンジニアリングの観点から以下のレビューポイントをプロンプトの指示に組み込みました。
💡 AIへの翻訳指示（レビューポイント）
- 用語の統一：UIで使っている用語と、ヘルプテキストの用語を厳密に統一すること（例：UIが「OK」なら、ヘルプで「決定」と訳さない）。アプリ全体を通して揺れがないか確認すること。
- フォーマット文字列の考慮：日本語の語順を前提とした直訳（文字列の単純連結）を避けること。
- 例：日本語の「9:00 まで」は、英語では「until 9:00」となる。言語ごとに動的なフォーマット文字列（
%sなど）を適切に定義してAPIを使用すること。
この辺りの細かい調整も、AI相手なら「何度でも文句を言ってやり直しができる」のが最大のメリットですね。
3. 著作権フリーの「デモ用コンテンツ」を生成する
VOTWはブラウザアプリなので、GooglePlay向けのスクリーンショットを用意する際に「画面に何を表示させるか」で困りました。実際のWebコンテンツは他人の著作物なので勝手に使えません。
そこで、公開用のデモコンテンツ自体をAIに作ってもらうことにしました。Claude Codeへのオーダーは以下の通りです。
「誰も傷つけずにクスッと笑えるコンテンツで、著作権の心配がない、和洋の昔話のパロディニュースを作って！」
すると、以下のような見出しを提案してくれました。
🇯🇵 日本語版の例
- 浦島太郎、竜宮城での滞在期間をめぐり乙姫と法廷闘争。時効が争点に。
- 一寸法師、身長差別撤廃を訴え都庁前でデモ。打ち出の小槌の管理問題も浮上。
- かぐや姫、月への帰還から数百年ぶりに地球再訪。「物価が高すぎる」とコメント。
- 笠地蔵、無断設置で市から撤去命令。地元住民が保存運動。
- 花咲か爺さん、隣人との境界線トラブルで調停中。枯れ木の所有権が焦点。
🇺🇸 英語版の例
- Goldilocks Faces Charges After Bear Family Files Restraining Order.
- Humpty Dumpty's Family Sues Royal Engineers for Negligence.
- Big Bad Wolf Appeals Conviction, Claims Houses Were "Structurally Unsound."
「盗用を疑われるリスクを最低限にするために昔話をベースにする」というのは、おちゃらけているようで実は非常に実用的なポイントです。
AIは見出しだけでなく、記事本文からRSSフィードのデータまでノリノリで生成してくれました。これはストア画像だけでなく、検証用テストデータのジェネレータとしても強力な武器になります。
（ちなみに、ストアページの紹介文自体の多言語翻訳もAIの助けを借りて準備しています）
4. そしてiOS版への移植 〜あえてAIに「制約」をかける〜
Android版は私が手でゼロから書いたコードがベースなので、内部の実装や動作仕様は完璧に把握しています。
「iOS版も作ってみたいなあ」と思い立ち、Android版のコードをまるごとClaude Codeに食わせてみたところ、驚くべきスピードで移植が進みました。
手順としては以下の通りです。
- 箱作り：まずはUIの画面遷移だけを移植してもらい、空っぽの画面を行き来できるようにする。
- 機能実装（ルールによる制御）：ここが一番のキモです。
実はAIに「機能も動くようにして」とだけ丸投げすると、気を利かせて SwiftUIのパラダイムに馴染むように大幅なリファクタリングをしてしまい、元の構造から大きく逸脱したコードを生成 しようとします。
それを防ぐため、AIに対して強力なルール（ハーネス）を課しました。
💡 iOS移植時にAIへ与えたルール
「クラス単位で忠実に移植すること。SwiftUIにそのまま持っていくと著しく非効率になる構造の場合のみ、ユーザー（私）の確認をとった上で設計すること。その場合も、極力元のクラス構造と命名規則を維持すること。」
AndroidとiOSの最大のアーキテクチャの違いは、Android版では機能の本体をほぼ Service クラスに置き、UIとはIPC通信をしていた点です。iOSではこれをUIクラスの裏側に置く形になりましたが、上記のルールを敷いたおかげで各機能をクラス単位で移植でき、「自分の理解が追いつく設計粒度」に収めることができました。
（最初からFlutterなどで書いていれば考えなくてよかった問題かもしれませんが……）
そんなこんなでiOS版も実装が終わり、今まさにApp Storeへの公開準備をしているところです。この記事が公開される頃にはストアに並んでいるはずだったのですが、Appleの手続きが詰まっていて待ちぼうけ状態です。
日本のDeveloper Supportチームによると、2026/8現在、米国ファイナンスチームに舞い込むサポート問い合わせが限界を軽く超えているそうで、全く回っていないようです。
日本のサポートチームも積極的にエスカレーションしてくれているのですが、公開はしばらくお預けになりそうです。
終わりに
全6回にわたって、多言語読み上げブラウザVOTWの開発記をお送りしました。
アプリの構造も、提供する機能も「レガシー」そのものかもしれません（今ならクラウドベースの強力なAI音声もありますし）。
しかし、「クラウドやサブスクリプションに依存せず、端末本体の機能だけでそこそこ便利に使い倒せるアプリ」という方向性には、まだまだ戦える隙間（ニッチ）があると思っています。クラウドベースのサブスクビジネスはすでに激しいレッドオーシャンですから。
連載の中でご紹介した技術トピック（MediaSessionのハックなど）が、どこかで誰かのアプリ開発の役に立てば、こんなに嬉しいことはありません。
それでは、また何かの記事でお目にかかりましょう。最後までお付き合いいただき、ありがとうございました！