タブレット用の楽器アプリをたくさん作ってみた

タブレットで使いやすい楽器アプリを作りたいと思いました。 一般的にはピアノの鍵盤が最もよく使われますが、タブレット上ではあまり使い勝手がよくありません。 新たな楽器のあり方を色々と模索して、以下のようなアプリを作ってみました。

• 4x4pad - 4x4 grid MPE MIDI controller
• Celltone - Grid MPE MIDI controller with Janko-Piano layout
• Isotone - Grid MPE MIDI controller optimized for chords
• Hexatone - Hexagonal MPE MIDI controller with Wicki-Hayden layout
• Glisstone - Hexagonal MPE MIDI controller optimized for glissando

タブレットとピアノの相性が悪い

まずはピアノがどうにも使い勝手が良くない原因を言語化するとともに、新しい楽器を作るのにどれくらい余地があるのか考えてみました。 色々と考えていて思ったのは、 (1) 手の構造をきちんと考えているか、 (2) 和音をどうするか、 (3) 子供から大人まで使えるか、 (4) 白鍵グリッサンド、黒鍵グリッサンド、白黒グリッサンドをどうするか、 あたりが重要ということでした。 そして大半のものは 1で躓くことに気付きました。 まず手は広げて使うならいいのですが、狭めた状態で複雑なことをするのは意外と難しいです。 他にも大人は横方向に 20cm、縦方向に 15cm くらい広げて使うのが適切で、 指を体と垂直にしながら使わないと非常に苦しく縦の操作に弱いことがわかり、 そして親指と中指は 20cm ほど離れていることもわかります。 これらのことから、ピアノの鍵盤はある程度縦幅がないと押せないし、 横方向に動かすことを基本として考えないといけないことがわかります。 特に和音は指に横方向の動き以外が絡むと非常に再現が難しいことに気付きます。

タブレット上のピアノは特に親指の問題が大きいです。 親指を駆使しようとするとタブレットの大半の面積を必要としてしまいますし、 スマホはまったく使い物にならなくなります。 スマホやタブレットはせいぜい指3本、ほとんどのケースでは指2本しか考慮していません。 その理由は親指と小指を考慮するにはスマホだと画面が小さ過ぎるからです。 タブレットなら指4本がギリギリ使えます。 親指を駆使するピアノの UI はタブレットに根本的に合っていません。 仮に親指を使わないとしても、タブレット上でピアノをきちんと使うには 24鍵盤が必要で、 横幅を取ってしまうため鍵盤が小さくなり、和音を打鍵しづらい問題が発生します。 さらに、縦方向の小さなピアノで指4本で和音を実現しようとすると指の何本かで鍵盤を1つ飛ばすような形を作ることになるのですが、 これがめちゃくちゃ難しいことに気が付きます。4本指をただ横方向に広げることはできないのです。 さらにタブレットでは高低差を表現できないので黒鍵盤のグリッサンドはできません。 ここまで考察を進めると、タブレットにピアノは向かない気がしてきます。

指を曲げるときの動きも考えて見ました。 4本指は横方向への動きに極めて弱いですが、縦方向なら強いことに気付きます。 そのため運指は縦方向への動きを絡めるとスムーズに動かせます。 ドレミ(ファ)の次は上か下方向にスライドして(ファ)ソラシとするとスムーズです。 さらに気付いたことは、そもそもたくさんの指を使おうとするから大変になるということです。 これはボタンの中間点を押したときに和音を出せれば解決できそうです。

同型鍵盤と平面充填

次にピアノの歴史を見ながら、より良い配列を考えてみました。 これは以下のページがとても参考になります。

流行れ！同型鍵盤 (Isomorphic Keyboard)

アコーディオン配列には3つ大きな欠点があって、 (1)まずは配置に柔軟性が出てしまう問題があります。 一般的な方式だけで3つもあります。一応 Cシステム が標準らしい。 (2) 打鍵のしやすさを考慮して 16 ボタンが 1セットになっており若干ボタンの数が増えます。 2列用意すると 32ボタン。かなり多いです。 (3) 横列が 4ボタンなので自動的に縦列が 8ボタンになります。 とんでもなくスペースを取ります。

改良するなら六角形ボタンのクロマティック方式だと和音を作りやすいです。 これは明らかに四角形より優れています。 ちなみに四角形や六角形だときれいな平面充填図形を作れますが、 他にも三角形、凸五角形、複数種類の形状を利用することが考えられます。 三角形は結構考えたのですが、思ったより気持ちの良い配列がありませんでした。 和音に弱くて実用的ではない感じです。 1パターンだけ良いものはあったのですが、若干もやもや感が残る配列でした。 あと三角形だと誤爆の可能性がかなり高くなるのでそこもマイナスポイントです。

六角形にこだわらない複数種類の形状は以下のようなものがあります。 アリかも知れませんがハードウェアでもソフトウェアでも作るのが難しくなりそう。

• 万華鏡の世界　～平面充填とペンシルパズル～
• 平面敷詰図形
• 平面充填 - 大人になってからの再学習

個人的に最も良いと思ったは、多角形にこだわらない方法です。 わかりやすいのが T字ブロックです。

　　□□□□□□□□
　■■□□■■□□
■■■■■■■■

T字ブロックの良いところは、ほぼピアノと同じ形状で実現でき、 白グリッサンド・黒グリッサンド・白黒グリッサンドをすべて再現できる利点があります。 ただ横幅が長くなってしまうので、やはりタブレットでは限界を感じます。 これをドーナッツ型にするなども考えたのですが、ドーナッツ型の UI はかっこいいだけで手の構造と一致しないので打鍵感は微妙です。 タブレットだと複数段にするほうが明らかに演奏しやすいのですよね。 すべてのグリッサンドに対応して効率的な和音操作ができる形状はあるでしょうか。 今のところ浮かんでいません。

作ってみた

検討した成果を活かして、まずはコンパクトなグリッド配列の 4x4pad を作りました。 4x4 の MIDI コントローラーはすでに様々なものがあるので、 それを使いやすくしただけではあります。 このUI はほどほどに和音を打てるだけで、シレファなどの和音が押せない問題があります。

和音をきちんと押せて演奏らしい演奏ができるためには、最低24音が必要です。 とはいえ 4x4pad を縦方向に伸ばすと 縦に 8ボタン必要で、 白鍵盤と黒鍵盤の間が大きいので、これは微妙です。 私が一番良さそうと思った配列はヤンコピアノでした。普通のピアノとほぼ変わりません。 Wicki-Hayden Layout も割と良いのですが、黒鍵盤の位置に違和感が残ります。 黒鍵盤を左右に寄せるとどうしても白鍵盤との距離が遠くなってしまうので、 距離を短くしようと考えていたら、それヤンコピアノだよねと気付きました。 ただヤンコピアノはタブレット上では和音に弱い問題があります。

そこで色々考えているうちに、縦方向を一列増やすと面白いかもと思いました。 縦方向を一列増やすと音楽理論的に非常にきれいな配列ができます。 指の本数を考慮すると物理キーボードでは横に配列を伸ばしたほうがまず正解です。 ただタブレットは二本指で使うことが多いので、意外と打ちやすく、 また音楽理論的に綺麗なので打鍵に一貫性が生まれて覚えやすいです。 それぞれ Celltone (ヤンコピアノ配列)、Isotone (独自配列) として公開しました。

ヤンコピアノよりは Wicki-Hayden Layout のほうが和音は強いので、 Wicki-Hayden Layout も実装してみようと思いました。 最初は Wicki-Hayden Layout を左右に配置すれば打ちやすいと思ったのですが、 正六角形なので縦方向に使っていない空間がたくさんできてしまって微妙でした。 横方向もタブレットだとやや小さい問題があります。 だから Wicki-Hayden Layout は縦方向に伸ばしているし、 オルガンは斜めの配列が多いんだなと気付かされました。 Wicki-Hayden Layout は左右の手が重なるように演奏するので、ちょっと人を選ぶ感じがします。 より良い配列がないか考えた結果、一本指で滑らかなグリッサンドができる配列を思い付きました。 これはなかなかおすすめです。 Hexatone (Wicki-Hayden 配列)、Glisstone (独自配列) として公開しました。

実装に関しては、複数のボタンを同時に押せるように工夫しています。 普通はできないのですが、まず inset: -10% とすると 10% ぶん外側に判定が作れます。 これを利用すると透明なボタンの重なりを作ることができるので、 それを document.elementsFromPoint() でチェックします。 余白の判定にポインターが乗ったとき、重なり合ったボタンの両方にイベントを送信します。

ハードウェアを購入すると 10万円以上する MPE MIDI Controller がゼロ円で実現できました。遊んでみてね！

MPE (MIDI Polyphonic Expression) に対応した同型鍵盤型 MIDI コントローラー Hexatone、Glissatone を作った

MPE (MIDI Polyphonic Expression) に対応した同型鍵盤型 MIDI コントローラー Hexatone、Glisstone を作りました。 演奏しやすい配列で 2つアプリを作りました。 また以前公開した楽器アプリにも改良を加えて、Aftertouch に対応しました。

Hexatone

Glisstone

Celltone と Isotone を作ったときには MPE のことをよくわからず作り始めましたが、 規格に準拠しようとして作ろうとすると、やはり MPE はちょっと仕様が足りないかもと思うようになりました。 MPE は CC#74 と Pitch Bend、Channel Pressure のみで構成されています。 ピアノのような楽器を演奏しようとすると、鍵盤を叩く音によって音の大きさが変わります。 このとき普通は CC#11 を使うと思いますが、MPE の仕様には CC#11 が含まれていません。 CC#74 で代替はできるんですが、楽器によっては CC##11 とはかなり音が違います。 Aftertouch もなかなか難しい仕様で、規格に準拠しようとすると音量は大きくすることにしか使えないんですね。小さくはできない。 以上のことから、MPE の正式仕様だけでは音量を小さくすることができません。 それはちょっとなーということで、規格範囲外の CC#11 で普段は操作するようにしています。 さらに CC#11 を使いたいときと、CC#74 を使いたいときで切り替えられるようにもしておきました。 もやもやが残りますが、非推奨だけど規格違反ではないし、動くから良いか。

配列に関しては、これまで作っていたグリッド型では和音にそれほど強くないことを感じていました。 一番強いのは六角形のクロマトーン型で、既存のものだと Wicki-Hayden Layout が一番洗練されています。 アコーディオンの配列はグリッサンドに弱すぎる上に、配列の種類が多すぎるのが問題点です。 ただ色々考えているうちに Wicki-Hayden Layout よりもっとグリッサンドに強い配列があることに気付いたので、実装してみました。 Celltone は Wicki-Hayden Layout の配列を応用しています。 Glisstone は一本指で 2音階ぶん綺麗にグリッサンドできる新配列です。 個人的にはなかなか良いと思いますが、いかがでしょうか。

MPE (MIDI Polyphonic Expression) に対応したグリッド型 MIDI コントローラー Celltone、Isotone を作った

MPE (MIDI Polyphonic Expression) に対応した グリッド型 MIDI コントローラー Celltone、Isotone を作りました。 演奏しやすい配列で 2つアプリを作りました。 ついでに以前作った 4x4pad も MPE に対応させておきました。

Celltone

Isotone

タブレットで手軽に遊べる楽器アプリの配列を考えているとき、 いまさらながら MPE (MIDI Polyphonic Expression) を知りました。 知らなかったんかい、というレベルの話ですが…。 MPE はピッチベンドや音量をノート単位で管理して、表現力を高めることができます。 MIDI 2.0 を使うと MPE がなくても同様の仕組みを実現でき、同時打鍵数の制約がなくなります。 ただファイルサイズが大きくなる問題や、現状では拡張子が不安定な問題などがあります。 MPE は MIDI 1.0 の延長線上で作れるので、現状では MPE のほうが安定しそうです。 ちなみに MPE の実装を MIDI 2.0 に拡張するのは簡単そうです。ID をイベントに付与するだけかな。 Midy では MPE をサポートしていないかったので、実装してみました。

ただ MPE って音量の標準的な扱いがいまいちわからないんですよね。仕様的には Channel Pressure を想定しているのかな。 でも Channel Pressure は色々なエフェクトを盛り合わせにできるから、エフェクトを追加したい時にむしろ困る気がするんだよなあ。 私は CC11 で音量を調整しています。規約違反というほどではないし、いつでも実装は変えられるから、まあ良いかなと。 (本当はリリース後に直すのを忘れていたことに気付いたんですがね…。 いまのバージョンでも実害は何もなく、また Channel Pressure のほうに小ミスがあるように感じたので、次リリースでは直すかも知れません)。 Midy もだいぶ成長して、新しい仕様にサクッと追随できるくらいになってきました。

MPE を考慮した配列も同時に再検討しました。 ボタンを押す位置がすごく重要になるので、演奏は割と難しい気がします。 まずは指の位置でボリュームを変えられると良いのはすぐわかります。 また隣の鍵盤に触れたとき次の音を出せると嬉しいでしょう。 前は noteOn で処理していましたが、表現力を高くするには鍵盤の概念をもっと緩くして、 隣り合う鍵盤に近づいたときはピッチベンドで変化させると良いのでしょう。 このピッチベンドを主体に考えると、グリッサンドに強い配列が良いことになります。 ピアノ型の UI は縦方向の動きを音量、横方向をピッチベンドと考えると 操作しやすいかと思ったのですが、実際の製品を見るとすべてピッチベンドで実装してそう。 一番欲しいのは鍵盤ごとの音量調整かと思っていたけど、そうでもないのかな。 クロマトーン型の UI だとボタンごとの境界で距離に応じたピッチベンド、 ファーストタッチの位置で音量設定ができます。 縦方向に移動するときは横方向を音量に、横方向に移動するときは縦方向を音量にします。 アフタータッチで音量を変えにくいのは若干課題ですが、 タッチ位置を変えつつ連続タッチすれば一応は大丈夫そうかな。

配列に関しては、既存のものだと Janko-Piano がグリッサンドにまあまあ強くて良さそうです。 Celltone は Janko-Piano の配列を応用しています。これは普通のピアノとほとんど一緒なので演奏しやすいです。 Isotone は Janko-Piano が 2x6 なのに対して、3x4 に変更したらどうなるのだろうかと試行錯誤して作った配列です。 音程変化ボタンが増えすぎてしまうのが難点ですが…。ペダル用のボタンにしたりしても良いのかも知れませんね。 Isotone はタブレットのように 2本指で扱うことをメインに考えると、割と演奏しやすいです。 和音が非常に押しやすい配列になっており、指の数を増やしにくいタブレットではかなり有力だと思っています。 他にも様々な UI を既に考えてあるので今後作っていきます。

UI に関してはボタンとボタンの間に空間を用意しました。 空間部に触れながら指をスライドさせたときピッチベンドと音量変更が同時に変更できます。 まずはこの空間には gap を用意することでボタンとの違いを明示するようにしました。 gap がある程度大きくないとピッチベンドが効きすぎて音量だけ変更したいニーズに対応できないので、 一般的な MIDI コントローラーよりすこし空間を大きく設定しています。 ちなみにすべての場所でピッチベンドと音量変更が動いてしまうと、 音が変化しすぎて不便なだけなので、ボタンの中をスライドしても変化しません。 UI としてはこれ以上簡単にするのは難しいと思う。 感圧式タッチパネルなら音量を設定しやすいけど、ハードが高いので専用機器以外で主流になることはもうないでしょう。

ROLI Seaboard の初期発売は 2015年で、後続製品は今も MPE デバイスで一番面白そうに見えます。 現行製品と対等のアプリを作れるようになってきて、ようやく少し追いつけてきた感じ。 タブレットで実現できたことで、10万円近く掛かるデバイスを無料で遊べるようになりました。

手軽に遊べる楽器アプリ 4x4pad を作った

小中学生が遊べる楽器アプリを作りたいと思いました。 MIDI を使えば 200種類以上の楽器に強弱を付けて再生ができます。 タブレットでピアノの形状を模倣しても使いにくいので、もっとシンプルなものが必要です。 そこで実験的に作ってみたのが 4x4pad です。 4x4pad を使うと、子供向けの楽曲なら私でも簡単に演奏することができました。 なかなか良い。

4x4pad

作ってみて思ったのですが、昔は iOS に 3D Touch があったので pressure が得られたのですが、 今は廃止され pressure は常に 0 を返却します。Android も筆圧センサー搭載モデルは少ない。 同じようなことをするには width/height から pressure を推定するくらいしかないですが、 これは不安定で事実上使い物になりません。 最近は pressure を使ったアプリを作っていなかったので、今さら気付きました。 3D Touch を考慮した実装は入れてありますが、使えるデバイスは少ないのが不満です。 タブレットの楽器アプリは色々限界あるなあと思いました。 まあ昔から音ゲーを作るなどの用途でも様々な障害があってタブレットには苦労してきましたが…。

そんな訳で音の強弱は設定の Expression くらいでしか付けられませんが、 色々な音を出して合奏するには適したアプリになっていると思います。 ただボタンを配置するだけではなく、1つの指で複数のボタンを押せるようにしてあるので、和音が作りやすいですし、指を動かすだけでスムーズに音が鳴ります。 今回は MIDI コントローラーでよく使われる 4x4 グリッドを利用して作ってみましたが、 本当はもっと色々な配列を考えています。 いくつか楽器アプリを作ってみるつもりなので、そのうち配列などについての考察記事を投稿します。

4x4 グリッドの MIDI コントローラーは山ほどありますが、 どれも設定が必要で面倒臭すぎるので、設定なしで使える UI にしているのも、他と少し違うところです。 といっても MIDI コントローラーで遊んだことはなくて説明書などを見ながら言っているので、間違ってたらすまん。 選択しているドラムをグリッドに表示したりするともっとユーザーフレンドリーかなあ。

Web 上で使える Timidity++ っぽい MIDI プレイヤーを作った

Timidity++ っぽい MIDI プレイヤーを作りました。 前回に引き続き、Midy の機能確認やバグ潰しが目的で作ったアプリですが、 割と人気の UI ではあるので使い道もあるかも知れません。 本当は紹介のためにスクリーンレコーダーで録画してみたのですが、 Web Audio API がうまく録音できなかったです。音なしだと面白くないので動画は特になし。

Timidy

私も割と好きな UI ですが Velocity は鍵盤の色で表現するほうが良いと思っていたので、 64〜191 の間で色を調整して表示しました。これだけでだいぶコンパクトにできます。 それ以外は Timidity++ とだいたい同じですが、簡易的なミキサーアプリとしても使えるようにしています。 スライダーがありきたり過ぎるので改良しようかとも思ったのですが…、 面倒すぎてデフォになりました。スライダーは弄ろうとするとなかなか大変です。

実装では鍵盤をどう光らせるかで多少悩みました。 Web Audio API でやろうとすると、ended event はありますが、started event がないので、意外と難しいです。 AudioBufferSource.start() と同じタイミングで動くようにタイマーを設定すると、 タイマーの数が 2倍になってしまって速度の問題が出てきてしまいます。 Web Audio API を使ったタイマーだと負荷が大きくなってしまうので、 requestAnimationFrame() で描画タイミングと同期しながら、 noteOn などの時間を監視して光らせるのがおそらく一番効率が良いです。 鍵盤を光らせるには Midy 内部で処理するイベントのタイムラインを見ながら処理します。

Midy の再生開始判定と、@marmooo/midi-player の判定は微妙に違っています。 @marmooo/midi-player は再生ボタンを押したときにサウンドフォントの読み込みもします。 このへんの処理をどうすれば楽にできるかを考えていて少しだけハマったので、 再生ボタンを押したときから isPlaying = true な変数を持つように実装を加えたところ、 割と簡単に GUI 拡張を作れるようになりました。 GUI 側でも isPlaying の状態を持つことで、再生の終了判定も容易になりました。 最近の Chrome は AudioContext をつけっぱなしにすると CPU をかなり消費するようになったので、こまめに AudioContext を ON/OFF しています。 Chrome の AudioContext の CPU 負荷はバグとしか思えないので、 そのうち直っているかも知れませんが。

最後に鍵盤を鳴らす実装をしていると、グリッサンドに耐えられない問題が発生しました。 事前にすべてをキャッシュするのも手と思ったのですが、 keyRange/velRange と 2つパラメーターがあるのでちょっとメモリが心配です。 そこで await で音声波形をデコードする前にスケジューリング配列に追加してしまうことで、 問題なく再生できるとわかりました。 ただこれだけだと処理時間が少ないことで運良く実行できているだけだと思うので、 スケジューリング配列に登録するとき note に pending 状態を付けて、 pending 中に noteOff が発生したときは、noteOn の処理内で noteOff も実行するようにしました。 これならリアルタイムな割り込みが発生しても問題なく処理できるはずです。

ここまでの実装で Timidy は動くようになったので公開としましたが、色々と余地はあります。 例えば midy 0.4.0 の noteOn は、SF2 modulation に渡す状態配列や noteOff と整合性を保つために await を付けて処理していますが、波形のデコードが 〜50ms で、 状態配列 (256 x 32bit = 1KB) のコピーが 〜0.02ms であることから、 noteOn から noteOff までの間に状態配列と SF2 modulation に変化がなければ、 await せず状態をコピーしながら処理でき、Worker で並列処理で高速化可能のはずです。 面倒そうだけど並列処理すればグリッサンドに対してより頑強になるはずです。 これもそのうち検証しようとは思いますが、まずはイベント数を減らすほうが確実とは思います。

GM2 MIDIミキサー Humidy を作った

MIDI Player/Synthesizer ライブラリ Midy の実装がだいぶ進んできて、 GM2 の再生も安定してできるようになってきました。 まだ細かい実装不足やバグ、再生負荷の課題はあると思うのですが、そろそろ実用段階に入ってきています。 そこでバグ潰しも兼ねて、GM2 の機能をすべて使える MIDI Mixer アプリ Humidy を作ってみました。

Humidy

GM2 は仕様がかなり大きいので、機能をすべて使ったアプリとか見たことないんですが、実際のところどうなんでしょう。 ちなみにすべての機能を本気で使おうとすると UI が複雑になり過ぎるので省略している箇所はありますが、ライブラリからはもちろんすべて使えます。 なるべくシンプルに作ったつもりですが、複雑な機能は簡単な UI にはしにくいので、 普段は表示しないように押し込み、設定項目も無理やり減らしています。

名前は Timidity++ のもとになった英単語で timidity があって、 同じように midi が出現するもう一つの英単語として humidity があるので、 humidity と Midy をもじって Humidy としました。

Midy は自分に合わせて作っているので作りやすいのは当たり前とはいえ、 かなり短いコードで音楽ミキサーアプリを作ることができました。なかなかいい感じ。 動的サウンドフォント、動的 fetch プログラムチェンジ、GM2 なども動くようになったので、いよいよライブラリとしても完成度が高まってきました。 もう少し高速化したらすべての MIDI ライブラリは Midy に移行できそう。 速度も激ヤバ MIDI 以外なら問題になることはないので、もう実用レベルと思います。 激ヤバ MIDI は瞬間的なイベント数の負荷がブラウザの限界に達して死ぬので、イベント数を減らす処理をこれから入れていきます。

MIDI はサウンドフォント周りをもっと設定できたら面白そうなので、 もう少し色々改良したいなと思っています。個人的に気になるのはリバーブです。 MIDI はサウンドフォントで Reverb Effects Send を決め打ちしますが、 そこで決め打ちすると楽器によってはリバーブ効果がわからなくなります。 現実のリバーブは Reverb Effects Send のように楽器によって効果が決まるのではなく、 周波数に応じてリバーブの効果が変わる (低音ほど消える) はずなので、 音響理論で考えると微妙な気もして、設定できたほうが嬉しい機会もあると思いました。 開発者以外でこれに悩む人はいるのかという疑問はありますが、 MIDI プレイヤーをゼロから実装していると、こういう細かいところが気になってきます。

バグ潰しのために、さらに何種類かアプリを作ってみる予定です。

中学理科一問一答・中学社会一問一答を作った

中学理科一問一答と中学社会一問一答を作りました。 きちんと教科書を使って作っているので、教科書準拠の重要語句を手軽にチェックできます。 苦手分析もしっかりできるので、学校・塾・家庭でも使いやすいんじゃないかな。 中学理科は計算問題を含めていないので語句・公式の確認に使えるくらいですが、それだけでも多くの人に使い道があると思います。 四択問題で簡単なので、正答率は8割以上が目安なんじゃないかな。 間違った問題は復習が必要です。

中学理科一問一答

中学社会一問一答

重要語句の意味や事実は静的なので、AI 生成することで作ってみました。 穴埋め問題は AI が最も得意とする分野なので、精度も非常に高いことが期待できます。 とはいえ融通が効かず 10分前に話した内容をすぐ忘れる AI さんに作ってもらうのは大変でした。 それでも人間が作るより 100倍くらいはコストが低いと思いますし、 100倍楽なのだから頑張ろうと思って作りました。 いかに安定して生成させるか、いかに質を安定させるか、 いかに選択問題として使えるようにするか、いかにメンテできるようにするかが重要になります。 AI さんの知識量は凄いですが、行動は物忘れが激しいため細かい指定をしても守ってくれません。 テストをきちんと書くことが大切だなと思いました。 結構色々なチェックをしているので、問題がクソなケース以外はかなり除外できていると思います。 問題がクソかどうかはたくさんプレイしてみてわかることなので完璧は難しいですが、 ある程度は自分でもプレイしてみて確認はしています。 このへんの開発の手間具合は、1年経ったらまた状況は違うんでしょうが、現状は AI があってもやはり大変です。

アプリとして公開できるようにするためには、かなりチェックが必要でしたが、 それでも一度作ってしまえば、メンテコストは低いし、生成コストも、チェックのコストも低いのが良いところです。 違う問題を作ってと言えば、他の問題も作れます。 人間にこれをやらせると、個人開発では絶対無理だし、集団でもとんでもなく時間が掛かります。 人間や過去問をベースとして作るよりAI で作ったほうが、一般性も網羅性も高くなる利点はあるので、結構良い AI の利用例かなと思います。 ただ社会はかなり安定して問題を作れる一方で、 理科は AI さんも知識不足な気がするので、問題はだいぶ自作しました。 社会は割と安定して出力できるものの、やはり致命的なミスがたまにあったりするので、日頃の確認が必要です。

近年は高校受験や大学受験の問題を見ても、一問一答そのものが問題として出てくる機会はなくなっていますが、 知識確認には依然として有用です。 問題を解いた後に、どれくらい他のことを言えるか考えてみたり、使い道はたくさんあります。 人気の問題集とかを見ても、結局は一問一答の延長線である問題のほうが多いので、 実質的にはみんな今も使っている状態と思います。

そういえば AI で作れるよなー、くらいの気持ちで作ってみましたが、なかなか良いんじゃないかと思います。 他のアプリもまったく確認せず作り始めたのですが、いくつかはあるみたいですね。 まあ AI 生成ドリルとか、塾用のとか色々あるもんな。 でもなんというかすぐに使えるものはなかなかないし、実際欲しいのはすぐ使えるものなので、まあ良いかなという気持ちです。 今のところ中学社会一問一答・中学理科一問一答という名前にしていますが、 今後の実装レベルによっては名前を変えるかも知れません。