Nani !? を作るときに考えていること（原文）¶

catnose @catnose99 Nani !?を作るときに考えていることこの記事はすべて人間による手打ち入力で書かれています。

Nani !? というAI翻訳ツールを開発する中で考えていることについて、ときどきXでも呟いてるのですが、頭の整理も兼ねて書き出してみることにしました。

ツールとしての立場をわきまえる Naniは業務やコミュニケーションの主役ではありません。あくまでも伝えたいことをスムーズに伝え、知りたいことをスムーズに知るための脇役のツールです。ユーザーの欲しいものを最短で提供し、シュッとその場の出番を終えるのが理想的な役割です。最短で出番を終えられるよう待ち時間を最小限に、負荷なく使えることが大きな方針となります。

すごそうなUIより、楽なUIに開発初期にかなり迷った部分ですが、Naniではあえてチャットらしさを感じられるUIに寄せています。従来の入力↔結果が横並びの翻訳UIを大きく拡張したようなデザインにしておけば、より新時代の翻訳ツールらしさや、「ただのLLMのAPIラッパーではない感」を演出できたと思います。しかし、いくつかの形を試行錯誤していく中で、AIチャットらしさのある上から下へと要素を積んでいくUIが最も直感的で、深堀りしやすく、戻りやすく、取り消しやすく、扱いやすいという結論にいたりました。

スクロールはいいものだスクロールというのは現代のインターネットにおいて、最も負担の小さい操作です。ボタンやリンクを押すという行為は心理的なハードルが大きなものです。ボタンを押せば、画面いっぱいに広告が表示されるかもしれません。想定していたものと違うページが出てくるかもしれません。戻ろうとしても元の位置に戻れないかもしれません（スクロール位置がリセットされるとか）。それに比べてスクロールは安全寄りの操作です。戻りたくなったときにすぐに元の位置に戻ることができます。段階的に情報を拾っていくことができます。人々はたくさんスクロールすることに慣れています。未来感のあるデザインとレイアウトで表現したくなる気持ちが湧くこともよくありますが、一番使いやすくて楽な形を追求していくと、最終的にスクロールを前提とした単純なUIに行き着くことがよくあります。

設定や機能を増やせばユーザーにとっての複雑さも増していく設定項目（プリファレンス）や機能の追加は、コードベースだけでなく、ユーザーにとっての複雑さや認知負荷も高めます。特に新規ユーザーやライトユーザーにはこの影響を受けやすくなります。 AIの進化で複雑なコードベースであっても、ガンガン機能追加することも可能になりました。同時にユーザーにとっての複雑さは顕在化しやすくなりました。 Naniを開発していく中で、トップページのファーストビューにボタンが一個増えるようなものについては、本当にやるべきものか、しばらく寝かせて考えるようにしています。機能追加によるツールとしての価値向上と、増す複雑性、その2つを中長期目線で天秤にかけた意思決定をするのはいつも難しいものです。

デフォルト設定がほとんどの人にとってのベストになるようにほとんどのユーザーは、設定をいじらないままアプリを使い始めます。アプリの挙動に許容範囲以上のストレスを感じたときにようやく設定を探しに行くかもしれませんし、そこで離脱するかもしれません。ユーザーが目的もなく設定を開いて「どれどれどんな設定があるかな」と覗きに来てくれることを前提に設計すべきではありません。デフォルト設定のまま使うことが、ほとんどのユーザーにとって最も快適な体験になるように設計するべきです。ユーザーによって好みが分かれ、それが体験に大きく影響するものであれば、初回のオンボーディングフローの中で選択してもらうというのは一つ有効な手段になります。「どの部分を設定可能にするか」、「デフォルト値をどうするか」、「どこで設定を切り替えられるようにするか」「どのように気づいてもらうか」などの点には毎回のように頭を悩ませています。

操作をブロックしない自分はブロックされない体験が好きです。待ち時間の間にも、他の何かの操作を行いたいのです。 Naniでも、できる限りブロックを行わないようにしています。翻訳が進行しているときも別の翻訳文の入力ができ、中断したくなったらすぐに中断でき、雑に操作してもなんとなくやりたいことができる形が理想的です。

使い方を説明文に頼らない悲しいですが、機能の使い方や注意点について、ていねいで詳しい説明を書いてもほぼ読んでもらえません。もちろん長文による説明が必要になるシーンもあります。それが許容されるような種類の文章もあります。たとえばこの記事は「読み物」という前提があるため、こんなふうに長々と書いていても気合いを入れて読んでもらえたりします。しかし、アプリの中の説明文を読むとき、ユーザーは「早く使い方を理解して、その機能を使いたい」と思っています。説明文を読むことは目的ではなく、追加で課された負荷でしかないのです。個人的なルールとしてスマホで4行を超えるような説明文は基本的に読まれないうえ、その存在だけでややこしいという印象を与える要因になると捉えています。まずは長文を使わずに表現できないか検討し、それでも長文が必要なら、複数の段階に分けて見せたり、強弱をつける（特に大事な一文と、補足文を分けるなど）ことで、少しでも読む負担を抑えられないか考えるようにしています。

汎用性を犠牲にして、ハマると快適な体験に Naniでは翻訳言語の設定のほかに母国語の設定というものがあります。これはUI上の言語でもありますが、同時に文章の言語判定や、翻訳の解説文、次のアクションを提示する際の大きなヒントになります。たとえば設定で母国語: 日本語 + 翻訳言語: 英語としている場合、デフォルトで以下の挙動になります。日本語以外（例: 英語やスワヒリ語）→ 日本語へ日本語 → 英語へ 1の日本語へ翻訳するパターンであれば、ユーザーは原文（英語やスワヒリ語）の内容を把握する目的で翻訳している可能性が高いため、その内容を把握するための追加アクションを提示します（「要約する」など）。 2の他言語に翻訳するパターンであれば、ユーザーは他言語でだれかに文章を伝えたいと考えている可能性が高いため、シーンに応じたニュアンス別の翻訳例を複数提示します。

これは↔で言語切替を行う従来の翻訳UIに比べて、汎用性に欠けている面もあります。たとえば他言語から他言語（例: 中国語 → スペイン語）へと翻訳したい場合には、追加でポチポチと操作してもらう必要があります（これを楽にするためのアップデートは今後やる予定）。しかし、せっかくの個人開発です。自分の考える理想の体験を遠慮なく試していくスタンスで開発しています。

自己満足でも速度にこだわるツールの性質上、翻訳速度のボトルネックは完全にAI関連のAPIの待ち時間ですが、それ以外の部分では10ミリ秒でも速く結果を表示したいという気持ちで開発しています。このあたりのチューニングは自分が好きな作業の一つで、個人的な嗜好から優先順位が高くなっている部分でもあります。作業に煮詰まったときには、息抜きがてらサーバー側のチューニングや、入力遅延の改善や、ショートカットの反応速度の改善などを行っていたりします。新しい機能をつけるときには、既存の別機能の速度に影響がないか、毎回チェックしています。 10ミリ秒を削っても体感的にはほぼ変わりませんが、ビジネス的にはコスパが悪いところにも好きなだけリソースを投入できるのは個人開発の醍醐味です。

主観で作る Naniを開発するうえで最大の指針にしているのは「自分ならどう感じるか」という主観的な感覚です。自分とは違う感覚を持つ人を満足させることは諦め、同じ感覚を持つ人に刺さるものを作ろうと割り切っています。まだ自分でも満足できない部分がたくさん残されており、焦りやもどかしさを感じたりもしますが、じっくり時間をかけてNaniを育てていきたいと思います。