【ITニュース解説】The four colors from my first prompt are still in my app. Almost nothing else is.

AIを活用したアプリ開発は、初期のアイデアがそのまま形になるわけではない。開発の過程では、当初の計画から大きく変化する部分もあれば、意外にも最初の直感が最後まで生き残る部分もある。この記事では、AIと協調しながらアプリを開発する中で、特にアプリの見た目（視覚的アイデンティティ）や多言語対応、そして言葉の選び方がどのように進化し、どのような教訓が得られたのかを解説する。

アプリのブランドカラーは、開発の初期段階で詳しく決められ、その多くが現在まで維持されている。例えば、メインボタン用の明るい紫やリンク用の電気スミレ色、通知用のネオンピンク、ステータス表示用の明るいシアンなど、特定の用途に合わせた具体的な色コードが設定された。その後、AIはより落ち着いた色合いを提案したが、開発者はネオンカラーがライトモードとダークモードの両方で見やすいこと、落ち着いた色が単調に見えるという理由で、提案を却下した。ただし、テキストの視認性に関するAIの指摘は正しく、コントラスト比が不足していたリンクの色はより暗い色に変更された。このように、色の選定は単なる好みの問題ではなく、ユーザーの視認性やブランドの一貫性に直結する重要な決定だ。

フォント選びも同様に進化を遂げた。当初は視覚障がいのある人にも読みやすい「Atkinson Hyperlegible」というフォントが選ばれた。これは、小さな画面や屋外でも一目で内容が理解できるアプリを目指すという目的からだった。しかし、開発が進むにつれて、本文やリスト、小さなラベルにはより高密度な「Inter」フォントが適していると判断され、部分的に変更された。これにより、アプリ内では複数のフォントが使われることになったが、ウェブサイトや印刷物ではさらに異なるフォントが使われており、プロダクト全体でフォントシステムが一貫していないという課題が残った。理想としては、全ての媒体で統一されたフォントシステムを早期に決定すべきだったと振り返られている。

初期のロゴは、三つの輪が絡み合い、中央に小さな星があるデザインだった。これは「友人の輪」を表現したものだったが、アプリのコンセプトが「誰」から「どこ」へと変化したことに伴い、地球儀のような軌道を持つ地図のピンの形へと変更された。このロゴの変更は、言葉でコンセプトを説明するよりも早く、視覚的なイメージがアプリの方向性を示したという点で興味深い。

アプリを複数の言語に対応させる多言語化は、当初の想定以上に複雑な課題だった。開発者はイタリア語、英語、スペイン語、フランス語、ルーマニア語の5ヶ国語に対応させたいと考えていたが、これは単に翻訳作業を依頼するだけでは済まない、より根本的な「アーキテクチャ」の設計問題だと判明した。

まず、AIとのやり取りの中で、AIがサポート言語リストからルーマニア語を削除し、ドイツ語を追加するという予期せぬ変更をした。これは開発者がリストを再確認するまで気づかれず、AIからの情報も常に吟味する必要があることを示唆している。

さらに大きな問題は、アプリ内のテキストがどこに保存され、どのように管理されるかという点だ。初期の画面では、テキストがウィジェットに直接書き込まれており、翻訳が全くされていなかった。その後、固定文字列は言語パネルで管理されることになったが、ダイアログメッセージやスナックバー、カスタムコード内のテキストなど、パネルでは管理できない場所にも多くの文字列が存在した。そのため、一時的に言語パネルにないテキストは共通言語である英語にするというルールが設けられたが、これにより画面内でイタリア語と英語のボタンが混在するなどの不整合が生じた。最終的には、全ての文字列を翻訳する方針に転換し、言語パネルだけでなく、ページ内のフィールドやコンポーネント、カスタムコード内の独自の翻訳テーブルに至るまで、様々な場所に散らばった文字列を管理することになった。これにより、5ヶ国語対応は、実際には4つの異なる場所で文字列を同期させる複雑な作業になった。

多言語対応の品質確保も容易ではなかった。後に行われた言語監査では、「Bienvenido par」（スペイン語とフランス語の混在）や「Pas besoin di rester」（フランス語とイタリア語の混在）のような、異なる言語が混ざり合ってしまう問題や、フランス語で敬称の「vous」と「tu」が混在する不統一が見つかった。これらは、単に翻訳するだけでなく、一貫したルールと細心の注意が必要であることを示している。

コードとは直接関係のない「言葉の選び方」も、アプリのユーザー体験に大きな影響を与えた。例えば、「Wish」という機能名について、英語では名詞としてそのまま使われたが、他の4ヶ国語では「〜したい」という丁寧な動詞形（「Vorrei」など）に変更された。これは、機能名がユーザーに「友達に何かを言う」ような親近感を与えることを目指した結果である。

また、「Ghost mode」や「Vault」といった開発者向けの内部的な名称は、ユーザーにとっては分かりにくいものだったため、「Invisible event」（見えないイベント）や「My events」（自分のイベント）といった、より直感的で具体的な言葉に置き換えられた。

「Tags」という言葉も、「Gruppi」（グループ）に変更された。これは、ユーザーが友人に対して「タグ付けする」という表現よりも「グループにまとめる」という方が自然だと判断されたためだ。

さらに、「orbit to me」というアニメーションの導入部の言葉遊びは、他の言語に翻訳すると意味が失われてしまうため、削除された。このように、文化的な背景や言葉のニュアンスを考慮した言葉選びが、アプリの魅力を左右する重要な要素だと認識されたのである。

この一連の開発を通じて、いくつかの重要な教訓が得られた。まず、ブランドカラーのように、アプリの核となる視覚的要素は開発の早い段階で決定し、その決定理由を明確に記録しておくべきだ。そうすることで、AIが別の提案をしてきた際にも、自信を持って判断し、一貫性を保てる。

次に、アプリだけでなく、ウェブサイトや印刷物など、プロダクトに関連する全ての媒体で一貫したフォントシステムを最初から決めることが望ましい。これにより、ブランド全体の統一感が生まれ、管理も容易になる。

AIは開発を強力に支援するツールだが、その提案を常に盲信してはならない。AIは毎回のように「改善」を提案してくるため、開発者自身がプロダクトの明確なビジョンを持ち、重要な決定はしっかり記録に残す必要がある。そうでなければ、毎週のように同じ議論を繰り返すことになる。

多言語対応は、単なる翻訳作業ではなく、アプリ内の全ての文字列がどこに存在し、どのように管理されるかを事前に設計する「アーキテクチャ」のタスクであるという認識が重要だ。初期段階で文字列管理の構造を考慮することが、後の混乱を避ける鍵となる。

AIが自動生成するリストや情報も、必ず注意深く再確認する習慣が必要だ。例えば、AIがサポート言語リストを勝手に変更した事例のように、重要な情報を見落とす可能性がある。

最後に、多くのバグは、コードの間違いからではなく、言葉の選択や表現の不一致から始まるという発見があった。これは、システムエンジニアリングにおいて、単にコードを書くだけでなく、ユーザーインターフェースにおける言葉遣いや、要件定義における明確なコミュニケーションがいかに重要であるかを示している。このアプリ「orbiTome」は、FlutterFlowとFirebaseを使って一人で開発されており、このような試行錯誤がプロダクトを成長させる上で不可欠だ。