MyDictly

Firebase Console（Android アプリ jp.langbridge の設定）に、共通リリース鍵（CN=nzw）の SHA-1・SHA-256 フィンガープリントを追加登録し、更新された google-services.json をアプリに反映した。

v1.3.7（2026-07-12）で debug 鍵から共通リリース鍵へ署名を移行した際、update.json の notice は埋めたが、Firebase Console への新しい鍵の SHA-1 登録は行っていなかった。Android の Google Sign-In（Credential Manager）は、アプリの署名証明書を Firebase/Google 側に登録済みのフィンガープリントと照合して認証するため、未登録のままでは認証が成立しない。

厄介なのは失敗の出方で、「このアプリは認証できない」という直接のエラーにはならず、ユーザーが何もしていないのに canceled（キャンセルされた）という結果だけが返る。2026-10-02、APK 版でログインボタンを押すと即座に失敗する、という報告で発覚した。

SHA-1 登録後、リリース鍵で再ビルドした APK で確認したところ、以前は即座に失敗していたログインが、正規の Google サインイン画面（アカウント選択）まで進むようになった。

iOS は Bundle ID + URL Scheme ベースで認証しており SHA-1 の概念が無いため、元々この問題の影響を受けていない。Web 版も対象外（Firebase Authentication の「承認済みドメイン」という別の仕組みを使う）。

PDIC 形式の辞書ファイルを取り込めるようにした。ただし取り込んだ語は単語帳（DictionaryEntry）に流し込まず、引くためだけの参照辞書として別に保持する。

検索結果には「辞書」欄として出るが、マイ単語一覧には現れず、習熟度もお気に入りも持たない。単語カードに混ぜて出題することはできるが、その結果は保存しない。

「自前辞書を持たない」という初期の判断は、外部辞書 API が使える前提で成り立っていた。実際には API の URL が未設定だと辞書欄が丸ごと無反応になり、オフラインでは何も引けない。

一方で単純に辞書を取り込んで単語帳に入れる案は破綻する——単語帳の保存は単一 JSON なので、数万〜数百万語を流し込めば読み書きのたびに全体を舐めることになる。

そこで「辞書は資産として持つが、単語帳のデータモデルには入れない」と線を引いた。PDIC を選んだのは、形式自体がソート済みインデックス＋固定長ブロックというランダムアクセス向けの構造で、全件をメモリに載せずに引けるため。

加えて日本語圏の個人作成辞書がこの形式で多く流通している。

10 万語規模の辞書でも、二分探索で触れた見出語だけを復号するので 17 回程度の比較で引ける。単語帳側のデータ量は辞書を入れても増えない。

代償として、辞書の語には習熟度が付かない——覚えたい語は単語帳へ手で登録し直す必要があり、ここは今後の課題として残した。

PDIC/Unicode 辞書の文字符号化である BOCU-1（Unicode UTS #6）のデコーダを、リファレンス実装（C）から Dart へ移植した。

デコードのみ実装し、エンコーダは往復テスト用にテストコード側へ置いた。

pub.dev に Dart 実装が存在しなかった。辞書対応を諦めるか、仕様を読んで書くかの二択で、後者を選んだ。

判断材料は分量よりも「検証できるか」で、UTS #6 にはテストベクタがあり、エンコーダを書けば往復テストで正しさを機械的に確かめられる。

仕様が固定されていて後から変わらない領域なので、一度書けば保守コストはほぼ発生しないとも見た。

辞書を原本のまま読めるようになった——取り込み時に独自形式へ変換しないため、変換の待ち時間もディスクの二重消費も発生しない。

BOCU-1 の「0x00〜0x20 の大半を出力しない」「バイト列の大小がコードポイントの大小と一致する」という性質が、そのまま終端判定と二分探索に使えている。

Excel（.xlsx）と CSV / TSV の取り込みを追加するにあたり、取り込み元ごとの処理を作らず、すべてを List<List<String>> の行列へ落としてから共通の ImportRowsUseCase に通す形にした。

ファイルの種類は拡張子ではなく中身のバイト列で判別する。

列マッピング・重複判定・取り込みセッションの記録は、元がスプレッドシートでも Excel でも同じ扱いでよい。取り込み元ごとに分岐を増やすと、この 3 つが経路の数だけ複製される。

拡張子を捨てたのは実地の事情で、配布サイトによっては .dic が download_file.php のような名前で落ちてくるうえ、iOS の「ファイル」App 経由でも拡張子が当てにならない。

取り込み元が 2 つ増えても、列マッピング画面と重複判定は 1 実装のまま。

判別をバイト列に寄せた副産物として、名前が壊れたファイルでも正しく振り分けられ、旧形式の .xls だけは「読めない」と明示的に案内できるようになった。

表示名を LangBridge から MyDictly へ変更し、アイコンも刷新した。

変えたのは表示名だけ（ホーム画面・ストア表示・Web manifest・Google Sheets への書き出し名）で、バンドル ID jp.langbridge・配布 URL・GitHub リポジトリ名は据え置いている。

v1.4.0 で反映した。

LangBridge という名前を持つアプリ・サービスが他に複数あり、ストアでも検索でも自分のアプリを指し示せなくなっていたのが発端。

候補は「自分の辞書」という意味を軸に選んだが、辞書＝Jisho を織り込んだ案は日本語を知らない人に一切伝わらないため落とした。

最終的に dictionary の一般的な短縮である "dict" と、Bitly / Calendly と同じ -ly を組み合わせ、日本語話者以外でも意味が取れる形にした。

一方で識別子まで変えると APK 直配布のアップデート経路と Firebase 連携が切れ、既存ユーザーが更新を受け取れなくなる。

だから「見える名前」と「動かす名前」を分け、変更は前者に限定した。

名前の重複は解消し、既存ユーザーはアップデート経路を保ったまま改名版を受け取れる。

配布ファイル名は MyDictly.apk へ切り替えたが、バンドル ID とリポジトリ名（lang-bridge）は旧名のまま残り、対外的な名前が二重に存在する状態は当面許容している。

軽量なまま、任意の言語ペアで実用的な検索・学習を提供。アプリの主戦場を明確にした。

※ この判断は v1.4.0 で一部撤回した。外部 API の URL が未設定だと辞書欄が丸ごと無反応になり、オフラインでは何も引けないという穴が実際に効いたため。

ただし撤回したのは「辞書を持たない」の部分だけで、辞書は単語帳とは別枠の参照専用として持つことにした（上の v1.4.0 のエントリを参照）。