以前ちょっと予告していた「モバイル向け Markdown / HTML リーダー」が完成しました。名前は Jilan です。
これは小さな、しかし日々増え続けるある悩みを解決します。
WeChat やファイルアプリ、グループチャットで AI レポートや Web ベースの PPT、Markdown ドキュメントが送られてきたとき、スマホで開くと真っ白な画面、生のソースコード、崩れたスタイル、またはどのアプリで開けばいいのか全くわからない、という経験があるでしょう。
.md、.markdown、.html、.htm、.txt、さらには Web ページをパッケージ化した ZIP ファイルも、Jilan を使えば iPhone と iPad で直接開くことができます。
ローカルレンダリング、ローカルストレージで、アップロードは不要、アカウント登録もいりません。
末尾に TestFlight のリンクがあります。試してみたい方は直接応募してください。8,000 枠を開放しています。
しかし、リーダーが不足していたからというだけの理由で Jilan を作ったわけではありません。
もっと直接的な理由は、AI がコンテンツ制作に関わるにつれて、私たちがコンテンツを交換するフォーマット自体が変わりつつあると、最近ますます強く感じているからです。
多くのテキストコンテンツは Markdown として作成され、多くのプレゼンテーションコンテンツは HTML として作成されるようになってきています。
Jilan は、この変化がモバイル側に及んだ際に、こぼれ落ちてしまっていた小さなツールなのです。
Markdown は単なるテキストフォーマットではない、AI のデータレイヤーになりつつある
数日前、Obsidian の作者の言葉を見かけましたが、とても的確だと思います。.md は AI のファイルインタラクションにおけるシェリングポイントになりつつある、と。
シェリングポイントとは、誰も強制しなくても、人々が自然と集まる選択肢のことです。
Markdown は今、まさにそんな感じです。
誰も AI が Markdown を使うべきだと決めたわけでも、どこかの標準化委員会が発表したわけでもありません。
しかし実際の使用では、人間が AI に書くときも、AI が人間のために書くときも、最終的には .md ファイルになりがちです。
理由は簡単です。
プレーンテキストなので、モデルが読み書きするのに軽量です。
見出し、リスト、テーブル、コードブロック、リンクを表現するのに十分な構造を持っています。
そして、.docx のような複雑な形式にはなりません。
人間は直接開けますし、AI も直接処理でき、バージョン管理や差分もきれいです。
しかし、もっと重要なのは、Markdown はもはや「エディタの中のテキスト」としてだけ理解されるべきではないということです。
それはむしろ、AI ワークフローにおける基盤データのようなものです。
私は CodePilot でもそのように使っています。
特に複雑な記憶機構はなく、多くの記憶は実際には一連の Markdown ファイルにすぎません。
AI が書き込み、AI が読み取り、そして私自身も開いて編集できます。
さらに、CodePilot のウィジェットは、これらのローカルの Markdown ファイルや記憶をデータソースとして使用できます。
ファイルが変更されると、コンポーネントの表示もそれに合わせて変わります。
この時点で、Markdown はもはや単なる「読むべき記事」ではありません。
それは非常に軽量なローカルデータレイヤーになります。人間が見ることができ、AI が読み取ることができ、ツールがそれに基づいて新しいインターフェースやインタラクションを生成できる。
だからこそ、多くの人が Markdown エディタを磨き続けている方向性は、少し狭いかもしれないと感じています。
本当に面白いのは、よりきれいな編集ボックスを作ることではなく、Markdown をデータとして扱い、新しい読み方、管理方法、そしてヒューマンコンピュータインタラクションの方法を構築することです。
HTML は AI コンテンツの表示レイヤーになりつつある
もう一方の端には HTML があります。この傾向も最近ますます顕著になっています。
先月、私は Web 形式でプレゼンテーションを生成する PPT Skill をオープンソース化しました。
25 日で 10,000 スターを獲得し、その後、オフラインの発表会や展示会、共有セッションで、それを使って作られた PPT を何度も目にしました。
これで一つ確信しました。
多くのシナリオで、人々が求めているのは標準的な .pptx ファイルではなく、すぐに発表でき、理解でき、共有できるプレゼンテーションなのです。
偶然にも、Claude Code チームも最近同じことを話しています。
出力が Markdown ではなく HTML を使うことが増えている理由について、彼らは記事を書いています。
理由は直接的です。HTML は情報密度が高く、視覚的な階層を作りやすく、グラフ、レイアウト、インタラクションの表示に優れており、他の人が開いて読むのも簡単です。
これは私自身の経験と非常に近いものです。
Markdown はコンテンツをまとめるには優れていますが、長くなると読みにくくなります。数千、数万語のレポートを .md ファイルに詰め込んでも、構造が正しくても、人間が実際に消化するのは難しい。
HTML はその逆です。レイアウト、スペース、色、グラフ、インタラクションを使って情報を整理し、より「消費されるもの」のように感じさせることができます。事実を保存するのには向いていませんが、人々が事実を理解するのを助けるのには優れています。
ですから、私はこの二つを分けて考える傾向が強まっています。
Markdown はデータレイヤー、HTML は表示レイヤーです。
基盤となるコンテンツは Markdown で保持します。クリーンで読みやすく、バージョン管理が可能です。
それを人に見せる、発表する、外部と共有する必要があるときに、HTML にレンダリングします。
これは何か大きな新しい標準というわけではなく、AI ワークフローから自然に生まれた役割分担のようなものです。
しかし、このチェーンはモバイルで途切れている
コンテンツはあり、ファイルは送信されます。しかし、問題は最後のステップで発生します。人々はスマホで開くことが多いのです。
デスクトップは問題ありません。ブラウザ、エディタがあり、何があっても VS Code があります。
しかし、モバイルは違います。
特に、AI が生成したレポートや Web PPT、Markdown ドキュメントを WeChat で受け取ったとき、よくある経験は、開けない、ソースコードが表示される、スタイルが崩れている、または複数のアプリを経由しなければならない、といったものです。小さなことですが、とても面倒です。
WeChat のような IM は、基本的にファイルリーダーではありません。
その優先順位はチャット、プレビュー、転送であり、Markdown や HTML ファイルを真剣に開くことではありません。
ブラウザもこのシナリオのために設計されているわけではありません。
デフォルトでは、ブラウザは「リンクをくれたら Web ページを開く」という動作をします。
しかし、相手が送ってくるのはローカルファイルであって、リンクではないことがよくあります。HTML をブラウザに渡すために遠回りをすることはできますが、チェーン全体が長くて不便です。
多くの Markdown ツールも編集やノートテイキングに重点を置いており、誰かから送られてきたファイルを一時的に開くのには必ずしも適していません。
ましてや、インポート、同期、ライブラリ構築、アカウント登録が必要なツールもあります。
HTML にはさらにセキュリティの問題があります。見知らぬファイルにはスクリプトが含まれている可能性があり、デフォルトで実行させたくない場合もあります。
だからこそ、ずっと足りないものがあると感じていました。
スマホでこれらの一般的な AI ワークフローファイルを安全かつ便利に開く方法です。
それが Jilan です。
Jilan は非常にフォーカスしている。開く、読む、保存する
Jilan はエディタにはしませんでしたし、AI にも接続しませんでした。そうそう、CodeX が描いたアプリアイコン、とても可愛いです。褒めておきます。
最初から明確に決めていました。Jilan はたった三つのことだけを行います。開く、読む、保存する。
ファイルを受け取ったら、WeChat やファイルアプリ、システムの共有シートから Jilan を選んで開きます。.md、.markdown、.html、.htm、.txt、そして Web リソースをパッケージ化した .zip ファイルをサポートしています。
すべてのファイルはローカルで処理されます。アップロードもアカウント登録も必要ありません。
Markdown を読むときは、主に長文読書用に調整しました。
フォントサイズ、行間、背景色を変更でき、長いテーブルは横スクロール、見出し構造のあるドキュメントは目次を使ってジャンプできます。
一般的な Obsidian の構文、例えばタスクリスト、Callout、脚注、Frontmatter、タグなども可能な限り互換性を持たせています。
ダークモードとカラーテーマの切り替えもサポートしています。
HTML を読むときは、「制御」により重点を置いています。
システムの WebView を使用してローカルレンダリングを行い、ズーム、縦横切り替え、モバイル/デスクトップモードの切り替えをサポートしています。
動的スクリプトはデフォルトでオフになっています。見知らぬ HTML ファイルにスクリプトが含まれているかどうかは通常わかりません。
そのため、Jilan はデフォルトではスクリプトの実行を想定せず、JS が必要なページに遭遇した場合は手動でオンにすることができます。
ZIP サポートも実際のシナリオに合わせて作られています。
AI がエクスポートする多くの Web ページは、単一の HTML ファイルではなく、index.html と assets フォルダで構成されています。
Jilan は解凍後に自動的にエントリーポイントを見つけ、ローカルの画像や CSS が正常に読み込まれるため、スタイルが失われたり画像が表示されなかったりすることがありません。
一度開いたファイルは自動的にローカル履歴に残ります。次回見返したいときは、アプリ内で見つけることができます。
同じファイルを複数回インポートしても重複は発生せず、重要なものはお気に入りに登録できます。
これが現在の境界です。
クラウド同期、アカウント、編集、AI 統合は行いません。
これらの機能が重要でないからではなく、ビューアはまず「開いて読み終える」という仕事をきちんと果たすべきだからです。
Jilan は最初の二つのものに従っている
振り返ってみると、Jilan は孤立した小さなツールではありません。
先月 PPT Skill を作ったのは、HTML が AI がプレゼンテーションコンテンツを生成するための非常に自然な形式になると信じているからです。
PowerPoint を置き換える必要は必ずしもありませんが、「発表できるものを素早く生成する」ためには、HTML は十分に軽量で、開放的で、モデルが直接生成するのに適しています。
CodePilot を作ったのは、Markdown が AI コラボレーションにおいて非常に自然なデータと記憶の媒体になると信じているからです。
最も美しい形式ではありませんが、人間、モデル、ツールが同時に使用するのに最も簡単な形式です。
Jilan は三番目のステップを扱います。
これらのフォーマットは「生成」されたまま終わってはいけません。人々が実際にそれを開き、読み、保存できなければなりません。
最初の二つは制作に関するもので、Jilan は消費に関するものです。
AI はすでに Markdown と HTML を生成できます。
しかし、これらのファイルがスマホに届いた途端に壊れてしまうのなら、どんなにスムーズな生成体験でも、実際に人の手に届いたとは言えません。
Jilan はそのラストワンマイルを埋めます。
しかし、これで終わりでは決してない
Jilan は現在、最も浅い層だけを埋めています。ファイルを受け取って開くことです。
今後も、いくつかの問題を解決する必要があります。
例えば、管理。
多くの人はすでに、スマホ、クラウドドライブ、チャット履歴、さまざまなアプリのキャッシュに、大量の Markdown ファイルや HTML ファイルを散在させています。
それらに価値がないわけではありませんが、散らばりすぎていて見つけられなかったり管理できなかったりします。
例えば、共有。
Jilan は「他人が送ってくれたものをどうやって見るか」を解決します。
しかし、逆に「自分が HTML ファイルを作ったとき、どうやって他の人が便利に開けるようにするか」もまた面倒な問題です。
ファイルを送っても、相手が開けないかもしれません。リンクを送っても、自分でデプロイ場所を見つけなければなりません。
例えば、クロスデバイス。
スマホで読みかけのものをパソコンで続けて読む、パソコンで生成したレポートをスマホにプッシュして読む、といったことはすべて非常に自然です。
しかし、同期を行うとすぐに、アカウント、クラウド、プライバシー、複雑さという問題に直面します。
Jilan はまだ非常に小さいです。大きな製品としてパッケージ化したいとはあまり思いません。
しかし、それは私が毎日直面するギャップにぴったりとはまります。
AI がコンテンツを生成したけれど、スマホでしっかりと見たいだけなのです。
もしあなたも Markdown や HTML、Web PPT ファイルに頻繁に悩まされているなら、試してみてください。
TestFlight:
この件について、皆さんの考えもぜひ聞かせてください。AI の関与後、ドキュメント、プレゼンテーション、そして読書は、実際にどのようなものになっていくのでしょうか。
