こんにちは、平林です。
スキャンしたプリントにタイピングで書き込めるWebアプリ「かみなりノート」を、v0.4.0にアップデートしました。
https://kaminari-note.netlify.app
きっかけは、2026/8/19の学びプラネットの勉強会でいただいた3つの質問です。「消しゴム機能はありますか」「URLを入れたらリンクになりますか」「全画面表示はできますか」。この質問をもとに検討して、翌日の夜にはかみなりノートアップデートを公開しました。
今回の記事では、何が変わったかの紹介だけでなく、利用者の意見や質問からどうやってアプリを育てていくのか、その開発のプロセスを書いてみたいと思います。生成AIの登場で、このプロセスは特別なものではなくなりつつあります。プログラマーではない私が、ユーザーの声を聞き、観察し、それを道具に活かしていく——その実際です。まず、タイトルの「声（Views）」という言葉に込めた意味から始めます。
「声（Views）」という考え方
「声（Views）」は、子どもの権利条約からきている言葉です。条約の第12条は、子どもが自分に関係することについて意見を表明し、その意見が正当に重視される権利——意見表明権を定めています。日本語で「意見を聞く」と言うと、「あなたの意見は何ですか」と問いかけて、言葉で返ってくるものを思い浮かべがちです。けれども、条約の原文で「意見」にあたる語は views。一人ひとりの子どもの視点から見た物事の見え方や考え方、いわばその人が見ている日常の景色のことです。
アプリ開発に置き換えると、利用者の声（Views）は「消しゴムはありますか」という質問の形をしたものだけではありません。描いた線を2本指でつまんで動かそうとする手の動き。テキストがずれて、直そうとしてうまくいかないときの表情。道具を使っているとき、その人が見ている景色のすべてが「声」です。今回の修正は、質問からだけでなく、これまでデジタルノートを子どもと一緒に使ってきた経験の中で観察していたことから取り組んだものです。
この記事でくり返し出てくる「観察」は、この意味での——言葉にならない声を受け取る——仕事のことです。
プロセスの出発点：「ここがちょっとな」を言語化する
開発は要望を聞くことから始まりますが、要望をそのまま実装することは、ありません。出発点は、使っている場面の観察から「ここがちょっとな」と感じる引っかかりを言語化することです。これには観察が必要です。いくつか実例を挙げます。
1：文字の大きさを毎回変えるのは大変
子どもがPDFに文字を入力するとき、自分が入れたい大きさに文字サイズを変えるには一手間かかるので、慣れが必要です。これは子どもと一緒に活動をしている中で観察していることです。では初期値を固定すればいいかというと、そうではない。読み込むプリントによって、入れたい文字の大きさは変わります。細かい書き込み欄のワークシートと、大きなマスの連絡帳では、ちょうどいい文字サイズが違う。
そこで、かみなりノートはPDFを読み込んだときにそのPDFの主要な文字サイズを推定して、入力の文字サイズの初期値にするようにしました。「毎回変えるのが大変」の正体は「初期値がプリントに合っていない」だったわけです。
2：縦書き・横書きを毎回切り替えるのは大変
テキストの縦書き・横書きも同じでした。毎回切り替えるのは大変。でも考えてみると、実は「毎回」変えたいわけではない。変えたいのは、読み込んだPDFが縦書きの文書か横書きの文書かに対応してです。だから、PDFを読み込んだときに文書の向きを判別して、入力の向きの初期値をそちらに合わせる。切り替えの操作を速くするのではなく、切り替え自体を減らす方向の解決です。
3：入れたテキストがずれる——2つの発想を区別する
テキストボックスを入れたとき、思った場所から少しずれて、直したくなる。でも直すにはツールの切り替えに一手間かかり、うまくいかないとちょっとイライラします。この「ちょっとな」には、2つの解決の発想があります。
- テキストを動かしやすくする（ずれたときの対処を楽にする）
- そもそも思ったところにテキストが入るようにする（ずれが起きないようにする）
順番としては❷が先です。観察してみると、ずれの正体は「タップした位置がテキストボックスの角になっていて、文字がいつも指の右下（縦書きなら左下）に現れる」ことでした。v0.4.0では、タップした指の位置が1文字目の書き始めになるよう基準を変えました。ペン先を紙に置く感覚です。
そのうえで❶もやります。ずれ以外の理由で動かしたいことはあるからです。文字・線・図形のどれも、ツールを持ち替えずその場でつかんで動かせるようにしました。マウスを乗せると黄色いふちと「つかめる手」のカーソルが出ます。
【かみなりノートのスクリーンショット：テキストボックスの上にマウスを乗せると黄色いふちと「つかめる手」のカーソルが出ている様子を示している】
実装を改善のサイクルをくるくると回せるのが、バイブコーディングの楽しさであり、意義だと思います。
4：全画面表示——ニーズがぶつかるとき
かみなりノートは左側にノートとタブが表示されているスタイルのノートです。これは一覧性があって便利なのですが、ノート部分がせまくなるというデメリットがあります。これに対して、「全画面表示はできますか」という要望は、大学で学んでいるメンバーからのニーズでした。これは子どものニーズとぶつかるかなという懸念から、導入するかを一旦検討しました。全画面になると、画面から「消えたもの」を認識する力が必要になるからです。うっかり全画面に入ってしまった子は、戻る手がかりを見つけることができず、困ってしまいます。
似たことは市販のアプリでも起きています。たとえばノートアプリの閲覧モードと編集モードの切り替えで、いま自分がどちらのモードにいるか分からなくなって混乱する場面を、テクノロジーが得意でない人によく見かけます。
かみなりノートでは、入口と出口を非対称にすることで両方のニーズに応えました。入口の「ぜんがめんにする」はメニューの中——わざわざ開かないと触れない場所に。出口の「ぜんがめんをやめる」ボタンは、全画面中ずっと見える場所に。入りにくく、出やすく。うっかり入る事故は防ぎ、入ってしまっても帰り道が必ず目の前にある形です。
この「入りにくく、出やすく」という非対称の設計は、私の発明ではありません。AI（ClaudeCode）に調査してもらったところ、いろいろな分野で百年以上使われてきた安全設計の古い原則と同じ形をしているそうです。非常口の扉は、外からは開けにくく、中からはバーを押すだけで開きます。製造業には、危険な操作をそもそも起こしにくくする「ポカヨケ」の考え方があり、認知科学では「強制機能」と呼ばれています。じつはブラウザの全画面機能そのものも、入るには利用者の明示的な操作が必要で、出るのはEscキーひとつ——同じ思想で設計されています。
私がやったのは、子どもの行動を観察して「全画面は、見えていないものを認識しにくい人にとって、非常口のない部屋になる」と気づき、この古い原則と同じ発想で開発を進めたことでした。
【かみなりノートのスクリーンショット：左はメニューに「ぜんがめんにする」という設定が表示されている。右は全画面表示の様子で、右上に「ぜんがめんをやめる」というボタンが表示されている】
採用しない、という判断
3つの質問のうち、消しゴム機能とURLのリンク化は入れませんでした。
消しゴムを入れなかった理由は、操作の問題だけではありません。かみなりノートは、そもそも手書きでノートを取るためのアプリではない——これが開発の思想です。快適に手書きするための開発はせず、テキストで入力しやすいことに振り切る。ペンや図形は、囲みや線を引くための脇役です。
一般的なノートアプリなら、線を少しずつ消したり、ストローク全体をひと撫でで消したりできる消しゴムは有益な機能です。でもそれを実装するには、線を細かく分割して管理する仕組みをアプリが抱え込むことになり、学校で使われている低価格な端末では動きが遅くなる代償を払います。脇役の機能のために、主役の「サクサク入力できること」を遅くしない。「線を選んで削除する」で用が足りる以上、消しゴムは入れない、という判断でした。
リンク化は、このアプリを「文書を作るアプリ」の方向に引っ張ってしまうので、こちらも見送りました。
かみなりノートの軸は「紙のプリントに書き込む動作を速く・楽にする」。機能を足すかどうかの物差しを1本持っておくと、要望のひとつひとつに一貫した判断ができます。
このプロセスを、生成AIがまわしてくれる
ここまでのプロセスを整理するとこうなります。
- 使っている場面を観察して「ここがちょっとな」を言語化する
- 要望の正体を探る（対処か、原因の除去か。誰のニーズと誰のニーズがぶつかっているか）
- 作って、実際の端末で確かめて、直す
このうち1と2は、支援の現場にいる人がいちばん得意なことです。子どもがどこでつまずくかの観察は、プログラミングの知識とは独立した、専門家が担える／担うべき仕事です。そして3について——かつては専門家に依頼するしかなかった部分を、いまは生成AIとの対話でまわせるようになりました。
今回のv0.4.0では、テスト版を作って手元の端末で確かめる往復を1日で9回やっています。質問が出た翌日にアプリが変わる。観察できる人が、その観察をそのまま道具に変えられる時代が始まっています。
もうひとつ、子どもの権利の文脈で大事にされているのは、声は「聴かれる」だけでは足りず、「正当に重視される」ことまで含む、という点です。聴きっぱなしにしない。翌日にアプリが変わるということは、自分の声が確かに受け止められたことが、声を出した本人の目に見えるということです。生成AIがもたらした開発の速さは、たんなる効率の話ではなく、声への応答を目に見える形にするという意味で、声（Views）を仕組みに活かす実践の道具になると考えています。
この話の続きを、オンライン講座で
この「生成AIと読み書きサポート」について、2026年8月23日（日）にオンライン講座を開きます。
私から、読み書きサポートにAIをどう位置づけるかの全体像を。OCR・音声認識の飛躍的な向上、ChatGPT/Geminiの音声モード、NotebookLM、AIレコーダー、そして今回書いたような指導者が自分でウェブアプリを作る「バイブコーディング」の世界まで、実際のツールの画面をご覧いただきながらお話しします。
また、ゲストに飯野由里子さんをお招きして、米国司法省による障害を持つアメリカ人法（ADA）第2編の改訂について解説してもらう予定です。情報アクセシビリティは、制度設計の影響を大きく受けます。アメリカでの大きな流れをキャッチし、ディスレクシアのある子どもだけでなく、さまざまなマイノリティの子どもたちの教育に、情報技術を活かしていきましょう。
指導者のためのAI活用講座「生成AIと拓く、読み書きサポートのこれから」
- 日時：2026年8月23日（日）10:00〜12:00
- 形式：オンライン（Zoom）＋あとから配信（Vimeo・共有から1ヶ月）
- 参加費：3,500円
- 申込：https://0823aitoyomikaki.peatix.com/
リアルタイムで参加できない方も、あとから配信でご覧いただけます。「AIが話題になっているけれど、何がポイントなのか分からない」という方こそ、ぜひ。
v0.4.1までの変更まとめ
- メニューから全画面表示（入りにくく、出やすい非対称設計）
- 文字・線・図形を、ツールを持ち替えずその場でつかんで動かせる（ホバーで「つかめる」表示）
- 新しい文字を意図したところに入れられるように「照準」を設置
- 2本指で触ると直線が量産されるバグを修正
- 細い線のまわりに見えない「当たり帯」——少しずれて触っても選べる
技術的な補足：仕組みの開示
この記事で紹介した「読み込んだファイルに応じて入力の初期値を合わせる」仕組みは、特定の誰かに独占されるべきものではないと考えています。そこで、仕組みを具体的に書き残しておきます。日付つきで公開された文書は特許制度上の「先行技術」になるので、あとから誰かが同じ仕組みを特許で囲い込むことを防ぐ意味もあります（防衛的公開）。実装はすべてブラウザ標準のAPIとオープンソースのライブラリ（pdf.js）でできます。
文字サイズの初期値：PDFを読み込んだとき、pdf.jsのgetTextContentで先頭5ページ分のテキスト情報を取得します。各テキスト断片の変形行列（transform）から描画サイズを計算し（90度回転して配置された縦書きOCR由来の文字列にも対応）、文字数で重み付けした中央値を求め、8〜96ptの範囲に丸めて、そのノートの入力文字サイズの初期値にします。大きな見出しに引っ張られないよう、平均ではなく中央値を使うのがポイントです。検出できる文字が少ないPDF（画像だけのスキャンなど）では従来の既定値に戻します。
縦書き・横書きの判別：同じテキスト情報のうち、書字方向が「上から下」と宣言されている文字列、または変形行列が±90度の回転を示す文字列（行列の縦成分が横成分より大きい）を数えて、文書が縦書きかどうかを判別し、入力の向きの初期値にします。OCRソフトによっては縦書きを「90度回転した横書き」として記録するため、宣言と回転の両方を見るのが実務上のポイントです。
タップ位置と1文字目：新しいテキストを作るとき、タップした点を「1文字目の書き始め」として扱います。書き進む方向（横書きなら右、縦書きなら下）にはタップ点から書き始め、それと直交する方向（横書きの上下・縦書きの左右）はタップ点が中央に来るように配置します。ペン先を紙に置く位置の感覚に合わせた、これも非対称の座標決めです。
照準（1文字目の予告枠）：もじツール中、ポインタ位置に1文字分の破線枠を追従表示します。枠の位置・大きさの計算は、テキストを実際に作成する処理と同一の関数を共有しており、予告と結果が構造的に一致します。文字の入力中も表示を続け、空白のクリック＝「今の箱を確定して、予告の場所に次の箱を作る」という連続入力の道標を兼ねます。表示はマウス操作時のみです（タッチには照準を合わせる局面がないため）。
ーーー
それでは、また。
（文責：平林ルミ）
コメントを投稿するにはログインしてください。