開発の記録
AURA というアプリが、なぜ生まれ、どうやって作られたのか。 技術の知識がなくても読めるように書きました。
第1章 なぜ作ったのか
目の前に文字が浮かぶ眼鏡
Even G2 というスマートグラスを持っています。 普通の眼鏡に見えますが、レンズに小さな文字を表示できる。 歩きながら、電車の中で、スマホを取り出さずに情報が読める道具です。
これでニュースを読みたい、と考えました。
そこで GNews というアプリを作りました。 自宅のミニPCに記事を集めるプログラムを置き、眼鏡がそこから記事を受け取る。 実際に動き、毎日の通勤で使えるものになりました。
でも、家のパソコンが必要だった
問題は構成でした。
眼鏡 ← スマホ ← 自宅のミニPC（記事を集める本体）
記事を集めているのは自宅のパソコンです。 外出先から使うには、特別なネットワーク（Tailscale）で自宅に繋ぐ必要がありました。
自分だけなら我慢できます。 でも、他の人に配ることはできません。「まず自宅にサーバーを用意してください」では、誰も使えない。
スマホの中だけで完結する記事リーダーが必要でした。
そしてもう一つ
RSS リーダーというのは、ニュースサイトやブログの更新をまとめて読むための道具です。 何十ものサイトを毎日巡回する代わりに、新しい記事だけが一覧で流れてくる。 情報を追う人にとっては、新聞の配達に近い存在です。
長年こうした道具を使ってきましたが、 「自分が読みたいように読める」ものが、なかなか見つかりませんでした。
眼鏡のために作る必要があったリーダーを、 そのまま自分が毎日使いたいものとして作る。 2つの動機が、AURA という1つのアプリに合流しました。
「ないなら作る」
ここで多くの人は諦めます。アプリを作るのは専門職の仕事だからです。
ただ、状況が変わっていました。 AI にプログラムを書かせる道具（Claude Code）が使えるようになっていたのです。
設計を考え、指示を出し、出てきたものを実機で確かめ、違っていたら直させる。 プログラムの1行1行を自分で書かなくても、何を作るかを決めて、正しく作られているか判断できれば、 形にできる時代になっていました。
こうして AURA の開発が始まりました。
第2章 どんなアプリか
基本の考え方
AURA は「同期サーバーを持たない RSS リーダー」です。
多くのリーダーは、クラウド上のサービスと連携します。 複数の端末で既読を同期でき便利ですが、そのぶんアカウント登録が要り、 自分が何を読んでいるかを事業者に預けることになります。
AURA はそれをしません。 購読リストも既読も、すべて端末の中にあります。当方のアカウントもサインイン画面もありません。
「同期できない」のは不便でもありますが、誰にも見られないという安心と引き換えです。 はじめはそちらを選びました。
のちに 端末間の同期（AURA Plus・任意）を足しました。ただし当方のサーバーは作っていません。 保存先は利用者ご自身の Google ドライブのアプリ専用フォルダで、当方はデータを受け取りません。 使うときだけ Google にサインインします。使わなければ、上に書いたとおり端末の中だけで完結します。
できること
記事を集める
- RSS / Atom の URL を入れて購読
- キーワードを登録して、Google ニュースの検索結果を購読
- 日本国内の配信元 103 件から選んで追加（探さなくていい）
- OPML ファイルで他のリーダーから引っ越し
読む
- 一覧の見せ方が3種類（リスト / 大きなカード / 雑誌）
- 未読 / すべて / 保存 の3つの見え方
- 記事の全文を先に取り込んで、通信のない場所でも読める
- 端末内の全文検索
整理する
- フォルダで購読をまとめ、画面上部のタブで切り替え
- 既読・保存の管理
- 古い記事の自動削除（溜まりすぎない）
眼鏡で読む
- Even G2 に記事を送り、眼鏡のレンズで読める
- 眼鏡で読んだ記事は、スマホ側でも既読になる
第3章 どうやって作ったのか
全部 AI に書かせた
AURA のプログラムは、一行も手書きしていません。 すべて AI（Claude Code）が書きました。
ただし「アプリを作って」と頼めば出てくるわけではありません。 実際の進め方はこうでした。
1. 何を作るか決める どんな画面で、どう操作して、どんなデータを持つか。ここは人間が決めます。
2. 指示書を書く 「この画面にこういう機能を」と文章で伝える。曖昧だと、違うものが出てきます。
3. AI が実装する プログラムを書き、ビルドし、エミュレータ（PC上の仮想スマホ）で自分で動かして確かめる。
4. 実機で確認する 出来上がったものを実際のスマホに入れて使う。ここは人間にしかできません。
5. 違っていたら直させる 「ここが使いにくい」「こう動いてほしい」と伝えて、また 2 に戻る。
この往復を、数え切れないほど繰り返しました。
段階を切って進めた
いきなり全部作ろうとすると、必ず破綻します。 なので、5つの段階に分けました。
| 段階 | できるようになること |
|---|---|
| M1 | URL を貼れば記事が読める |
| M2 | 放置で新着が入り、既読が残る |
| M3 | フォルダ分け、OPML の入出力 |
| M4 | 見た目の3テーマ、一覧の3モード |
| M5 | 検索、初回案内、公開の準備 |
とくに M2 が最初の山でした。 M1 は動きますが、既読も自動更新もないので実用になりません。 M2 まで来て初めて「放っておけば新着が溜まり、読んだものは消える」= 日常的に使える道具になります。
第4章 苦労したこと
ここからが、この記録の本題かもしれません。 作っている最中に何度も壁にぶつかりました。いくつか紹介します。
4-1. 「読んでいないのに既読になる」
RSS リーダーで最悪のバグです。読み逃しに直結します。
調べると、原因が3つありました。しかも全部別物でした。
原因1: 設定が最初から効いていなかった
「スクロールで既読にする」という設定があります。オフにできるはずでした。 ところがプログラムの作りが悪く、オフにしても常にオンのまま動いていた。 画面上はオフに見えるので、触っただけでは絶対に分かりません。
原因2: タブを切り替えると既読になる
フォルダのタブを切り替えたとき、画面のスクロール位置がそのまま引き継がれる仕組みでした。 すると「前の一覧の何番目まで見た」という情報が、新しい一覧に流れ込み、 新しい一覧の先頭が読まれたことにされていた。
原因3: 記事を素早くめくると既読になる
記事は左右にスワイプでめくれます。 このとき、次の記事を素早く出すため、指を置いた時点で隣の記事を準備する仕組みになっていました。 その準備の段階で既読になっていたので、通り過ぎただけの記事まで既読に。
3つとも直しました。 このとき効いたのが、次の「ログ機能」です。
4-2. 原因が見えない ― そこでログを作った
不具合が起きても、スマホの中で何が起きているかは見えません。 推測で直そうとして、何度も外しました。
そこで アプリの中に記録係を置くことにしました。 設定画面に「Debug」というタブを作り、アプリの動作を記録して読めるようにした。
これを入れた直後に、大物が見つかりました。
キーワード購読（Google ニュース検索）の記事が、全文を取れずに失敗していた。 125件のうち 119件が失敗していたのに、それまで誰も気づいていませんでした。
原因は、Google ニュースの記事リンクが中継ページを指していたこと。 そこには本文が11文字しか書かれていない。本物の記事は別の場所にありました。
中継ページから本当の記事の場所を割り出す処理を追加したところ、 成功6件 → 25件、失敗119件 → 4件。
見えないものは直せない。記録を取ることが、いちばんの近道でした。
4-3. 文字化け ― 1バイトの異物で全滅する
一部のサイトの記事が、意味不明な文字列になっていました。
æ±äº¬ãf»å¤§é˜ªãŠã™ã™ã‚ã€...
日本語が読めない状態です。
原因を調べると、文字コードの判定の仕方に問題がありました。
コンピュータは文字を数字で扱います。その対応表が「文字コード」です。 日本語には複数の方式があり（UTF-8、Shift_JIS など）、 どれで書かれているかを間違えると、全部の文字が化けます。
AURA の判定は「変換に失敗した文字がいちばん少ない方式を選ぶ」という作りでした。 もっともらしく聞こえますが、致命的な欠陥がありました。
欧米向けの方式（Latin-1）は、どんなデータでも「失敗ゼロ」を返すのです。 中身が正しいかは関係なく、とにかく変換だけはできてしまう。 だから常にそれが「最も失敗が少ない」と判定されて勝ってしまう。
結果、日本語の文書に異物が1バイト混ざるだけで、全文が欧米方式で読まれて全滅していました。
さらにもう1つ問題がありました。 記事を解析する部品が、渡された文字列をもう一度バイトに戻して読み直す作りだった。 このとき元の宣言が残っていると、二重に変換されて壊れる。
両方直して、化けは解消しました。 すでに化けた状態で保存されていた記事も、設定画面から一括で修復できるようにしました。
4-4. 消した記事が毎回戻ってくる
これは、指摘されるまで誰も気づかなかった無駄です。
AURA には「古い記事を自動削除する」仕組みがあります。放っておくと際限なく溜まるからです。
ところが、削除した記事を次の更新でまた取り込んでいました。 配信元にはまだ記事が載っているので、「新しい記事だ」と判断して入れ直す。そしてまた削除する。
実測したところ、こうなっていました。
更新1回目 → 新着 597件 更新2回目 → 新着 597件 更新3回目 → 新着 597件 記事の総数 → ずっと 675件のまま
毎回597件を入れては消していたわけです。
害は通信量だけではありませんでした。 読み終えた記事が未読に戻るのです。入れ直した記事は「新品」として扱われるので、既読の情報が消える。 さらに、全文の先読みも毎回やり直しになっていました。
対処として「墓標」の仕組みを入れました。 削除した記事の情報を小さく記録しておき、次の取り込みで「これは一度消したもの」と分かるようにする。
更新後 → 削除済み 597件は取り込まない → 新着 0件
無駄が止まりました。
4-5. 眼鏡の画面で文字がはみ出す
スマートグラスの画面は非常に小さく、横 576 ピクセルしかありません。 文字が1文字でも多いと、画面の外に消えます。
ところが、パソコンで確認したときは収まっているのに、実機だとはみ出す。 何度直しても再発しました。
原因は「文字の幅の数え方」でした。
パソコンのブラウザでは、漢字は英字のちょうど2倍の幅です。 ところが眼鏡では 1.75倍でした。この差が積み重なって、行の端でずれる。
さらに、こういう記号のことを見落としていました。
▶ ● ★
これらを「英字1文字分」として数えていたのですが、 実際の眼鏡では漢字と同じ幅で表示されていた。だから記号の付いた行だけはみ出していたのです。
数え方を実測に合わせて直したところ、全画面が収まりました。
4-6. 指示が曖昧だと、違うものができる
これは技術の問題ではなく、進め方の失敗です。
画面の作りについて、細かい仕様を渡さないまま「いい感じに」と伝えたことがありました。 AI は仕様がなければ自分で判断するしかありません。 結果、想定と違うものができあがり、作り直しになりました。
何を作るかを具体的に決めるのは、人間の仕事です。 そこを曖昧にしたまま任せると、必ず手戻りします。
以降は、画面の構成・寸法・文字の大きさまで決めてから渡すようにしました。
第5章 工夫したこと
「見えないものは直せない」という原則
不具合の原因を推測で決めつけると、たいてい外します。 AURA の開発で繰り返し効いたのは、まず実測することでした。
- Debug ログを入れたら、その日のうちに大物のバグが見つかった
- 「文字がはみ出す」は、実際に幅を数えて初めて原因が分かった
- 「記事が戻ってくる」は、更新を3回して数字を並べたら一目で分かった
「たぶんこうだろう」で直した箇所は、ほぼ全部また壊れました。
誤った結果を出すくらいなら、出さない
記事の全文を自動で取り出す機能があります。 ところが広告やランキングを本文と間違えて取ってくることがありました。
ゲーム系サイトの記事を開いたら、本文の代わりに Amazon の売れ筋ランキングが出ていた、 ということが実際にありました。
そこで「取り出した結果が本当に本文か」を検証する仕組みを入れました。
- 記事の見出しに出てくる言葉が、本文にどれくらい含まれているか
- リンクだらけになっていないか（広告やランキングはリンクが多い）
検証に落ちたら、無理に表示せず「取得しない」を選ぶようにしました。 間違った本文を見せるより、要約だけの方がずっとましだからです。
実測では、本物の記事は見出しとの一致率が 75〜90%、 ランキングは 21〜37% と、はっきり差が出ました。
色は「役割」で管理する
AURA の画面には、色を直接書き込んでいません。
「この部分は背景」「ここは本文の文字」「ここは目立たせる色」と役割で指定し、 役割ごとの実際の色をテーマ別に持っています。
こうしておくと、明るいテーマ / 暗いテーマ / 真っ黒テーマ の切り替えが、 色の対応表を差し替えるだけで済みます。
さらに、プログラムの中に色を直接書いたらビルドを失敗させる仕組みも入れました。 うっかり書いてしまうと、その場で気づけます。
色の見やすさは数字で決めた
文字と背景の明るさの差（コントラスト比）には、国際的な基準があります。 読みやすさの目安として 4.5 以上が推奨されています。
AURA のブランド色を決めるとき、見た目の好みだけで選ばず、この数値を測りました。
最初に候補にしていた明るい金色は、白背景で 2.25 しかなく不合格。 暗い色に変えて 5.81 を確保しました。
最終的に選んだのは「墨と朱」です。 画面の大部分は無彩色にして、目立たせたい一点だけ朱色を使う。
理由は、RSS リーダーが「長時間、文字を読む道具」だからです。 彩度の高い色を画面に置くと、読んでいる間ずっと視界の端で主張し続ける。 無彩色にすれば、視線が記事そのものに集中します。
第6章 スマートグラスとの連携
AURA の目玉機能です。ただ、実現までに調査が必要でした。
眼鏡に文字を出す方法は1つしかなかった
調べた結果、Even G2 に何かを表示するには、 メーカー公式のアプリ（Even Hub）を経由するしかないと分かりました。 自作アプリから眼鏡を直接操作する手段は提供されていません。
つまり、こうするしかない。
AURA（記事を持っている） ↓ 何らかの方法でデータを渡す Even Hub の小さなプログラム ↓ 眼鏡
問題は「何らかの方法」です。AURA と Even Hub は別々のアプリなので、 データを直接やり取りできません。
端末の中に小さなサーバーを立てる
検討した結果、こういう方法にたどり着きました。
AURA が、自分の中に小さなサーバーを立てる。
普通、サーバーはインターネットの向こう側にあるものですが、 同じ端末の中にも立てられます。外には一切出ない、閉じた通信です。
Even Hub 側のプログラムが、そこに記事を取りに来る。
ただ、これが本当に動くかは分かりませんでした。 セキュリティの制限で塞がれている可能性があったからです。
そこで、先に確かめました。 検証用の小さなサーバーを用意し、眼鏡側から繋がるかだけを試した。
結果は成功。記録にはこう残っています。
HIT GET /rss/summary Origin= http://127.0.0.1:45453 → 200
繋がる、と確定した上で本実装に入りました。 「たぶん動くだろう」で作り始めていたら、無駄になっていたかもしれません。
眼鏡での見せ方
眼鏡の画面は緑一色で、しかも4段階の濃さしか出せません。 文字も10行程度しか入りません。スマホと同じ見せ方はできない。
そこで役割を分けました。
- 眼鏡: 何が届いているかを確認し、気になったものに印を付ける
- スマホ: じっくり読む
眼鏡で「保存」した記事を、後でスマホで読む。この流れを主に想定しています。
写真も出せるようにした
眼鏡は緑の4段階しか表示できません。写真は無理だと思っていました。
ですが、ディザリングという古典的な技法があります。 細かい点の粗密で、中間の濃さを錯覚させる。新聞の写真が網点でできているのと同じ原理です。
3つの方式を比較し、実際に画像を変換して見比べました。
結果、Floyd-Steinberg 法（誤差拡散）が圧倒的に良かった。 風景も人物も判別でき、提灯に書かれた「修雲館」の文字まで読めました。
ただ、この変換は重い処理でした。1枚あたり0.6秒近くかかる。 計算方法を工夫したところ 5倍速になり、しかも出力は1ピクセルも変わらないことを確認できました。 見た目を犠牲にせず速くできた形です。
第7章 今後
近いところ
Google Play で公開した（2026-10） 2026 年 10 月 27 日に、製品版を Google Play で配信しはじめました。
実際に使いながら直す 毎日使えば、想定していなかった不便が見えてきます。そこを潰していく段階です。
その先
眼鏡での体験をもっと良く 現在は「記事を読む」ところまでです。 新着が届いたら眼鏡にそっと知らせる、といった使い方も考えられます。
他の端末 スマートウォッチなど、画面の小さな機器にも同じ考え方が応用できます。
変えないこと
同期サーバーを持たないという方針は変えません。
便利さと引き換えに、自分が何を読んでいるかを誰かに預けることになる。 それを避けるために選んだ設計です。
引っ越しが必要なときは OPML ファイルで持ち出せます。 それで十分だと考えています。
おわりに
AURA は、スマートグラスで記事を読みたい、という思いつきから始まりました。
プログラムを書いた経験はありません。 でも「どんな道具が欲しいか」は分かっていたし、「これは違う」という判断はできた。 AI がプログラムを書き、人が方向を決める。その組み合わせで形になりました。
作っている途中で何度も間違えました。 指示が曖昧で作り直しになったり、推測で直して外したり、 「できた」と報告されたものが実は無かったこともありました。
そのたびに戻って、実測して、直す。 特別なことはしていません。確かめてから進む、それだけでした。
このアプリが、誰かの役に立てば嬉しく思います。
開発: 黒猫福家本舗