Q&A

ことせかい に寄せられたご意見ご要望について、何らかの理由で実装されなかったご提案について記述しておきます。

目次

はじめに (2019/01)

ことせかい への新機能のご提案、ありがとうございます。 ことせかい は個人が趣味で開発しているアプリとなっております。また、開発者はアイディアをあまり思いつかないような人間ですので、新機能についてはユーザ様からのご提案に頼っている所もございます。いつもありがとうございます。
ただ、このことせかい は「個人が趣味で開発している無料アプリ」であるということを今一度よく考えて頂ければと思います。下記のご意見ご要望への回答を読んで頂けるとわかるかと思いますが、個人制作であり、お金をいただいていないという事が原因で採用できないという問題が多くございます。新機能を思いついてご提案を書くということまでして頂ける方にはお手数までおかけした上で誠に申し訳ないのですが、「ことせかい の開発者は、ことせかい が使いやすくなってユーザが増えたりしても、1ユーザとして使いやすくなるという恩恵以外には恩恵はなく、逆にできることが増える事は不都合の可能性やメンテナンスコストが増えるという問題を生じさせる原因となり、さらにその新機能が評価された結果ユーザが増えることがあったとしてもそれはユーザサポートの手間が増えるだけであり、デメリットの方が大きい」という事をご理解ください。
例えば、開発者 は ことせかい を目で読むためには使っておりませんので、目で読むための機能を積極的にサポートする気はありません。目で読むために ことせかい をお使い頂きたい方には誠に申し訳ないのですが、ことせかい があまり目で読むための仕組みを持っていないのはそういう理由があります。まぁ、ご提案された機能で、簡単に実装できるものについては実装しておりますけれども。
そんな背景があります事をご理解の上、新機能のご提案をしていただければと思います。 また、ことせかい の開発者は褒められるととても喜びます。礼儀正しくお願いなどされても嬉しいと感じます。逆に、「〜はおかしい、〜となるのが当然であるので直すように」といったような思いやりのないお問い合わせを受けると傷つきます。 開発者としましては、それらのご意見ご要望はできるかぎり分け隔てなく評価し、実装するかしないかを決定しようと思っていますが、所詮は人の子ですので褒められたり礼儀正しいご提案の方が採用されやすくなると思います。どうぞお手柔らかにお願いいたします。

読み替え辞書をユーザ間で共有したい (2018/05)

読み替え辞書をクラウド的なものでユーザ間で共有して編集できないかというご提案について。
これは実現したらとても良いものになるとは思うのですが、そのクラウド的な物を維持するのにはお金がかかるので、ことせかい の開発者側としては対応できない案件となります。ことせかい が何らかの形で定常的にお金を生むような形にしていればよかったのかもしれませんがそうはなっていませんし、今から何らかのお金を生む要素を入れるのは多くの人が望まない事ですよね。なので、やる気はありません。ただ、数年間分のサーバ費用にオマケもつけるからやってくれという人が現れたり、自分がサーバ側を管理運営するのでアプリ側はなんとかしてくれという人が現れたり、この無料のサービスをこうやって使うと実現できるんじゃね?というウルトラCを考えついたりしたらあるいは、という気もしなくもありません。(もちろん、その費用が尽きたりサーバ運営をしてくれている人が諦めたりその無料サービスから想定外の使い方しちゃ駄目と怒られたらそこでそのクラウド読み替え辞書共有サービスは終了になりますので、不安定なサービスであるといえます)

何らかの問題で期待しないデータがダウンロードされてしまった章について (2018/05)

これは、例えば小説ではなく、「アクセス数が多いのでエラー」といったものがダウンロードされてしまった、というような場合の事です。 現状では、既にダウンロードして登録されてしまった部分(章)を再ダウンロードする方法はありません。
内部的には HTTP のステータスコードでエラーを返してくれている(200 OK ではない場合、例えば 429 Too many requests を返している)場合であれば、ダウンロードが失敗したとみなして保存せずにダウンロードを終了しています(していない例がありましたら不都合になりますのでお問い合わせフォーム等から教えてください)。逆に、HTTPのステータスコードによるエラー以外で「アクセス数が多いのでエラー」という文字列が取得できてしまう場合(200 OK で取得したデータの場合)には、ダウンロードが失敗したかどうかを判定するのは難しいため、そのままの文字列が保存されてしまいます。これをユーザ様の側で「この章だけ再ダウンロードせよ」という指示を出せるようにしたらよいか、とも思ったのですが、現在の内部データベース仕様ですと「その章」がどんなURLであったのかの情報が不足しており、再ダウンロードすることができないために実現できませんでした(現状では最初にダウンロードしようとした章のURLと、最後にダウンロードしようとした章のURLしか保存されていませんので、10章分読み込んでいた場合には2章から9章までは再ダウンロードすることができない、という状態です)。
なので、「アクセス数が多いのでエラー」といったようなエラーメッセージそのものが保存されてしまっている場合は一旦小説を本棚から削除して、通信環境の良い所で再度ダウンロードしていただく必要があります。
この問題については将来的には対応しようとは思っているのですが、現在の内部データベース形式では上記の理由で無理となります。また、将来的に対応できたとしても、現在既にダウンロード済みのものについて(上記の例だと2章から9章について)はURLを推測できない関係上、対応が不可能な問題となります。予めご了承ください。

縦書き表示について (2018/05)

まず、ことせかい は「読み上げ」アプリですので「目で読む」ための機能については真面目にサポートするつもりはありません。
また、縦書き表示についてのお問い合わせは何度か受けておりますので少し調査してみたことがあるのですが、残念なことに簡単には縦書き表示はできそうにありませんでした。
グダグタと調査したものを書き下しますと、NSAttributedString に NSVerticalGlyphFormAttributeName 辺りを設定すると縦書き表示ができそうなのですが、1行分しか縦書き表示してくれないようであったり、TTTAttributedLabel というライブラリを公開してくれている人が居てそれを使うと良さそうだと思ったら、Label であって TextView ではないのでスクロールできなかったり、UIWebView に CSS で writing-mode: vertical-rl; 辺りを含ませた物を表示させれば綺麗な縦書き表示ができるかと思ったけれど、現在の読み上げ位置をハイライトする方法が一筋縄ではいかなくて断念したり、といった感じです。最後の UIWebView 辺りの仕組みがうまく動くのであれば表示している WebPage をそのまま読み上げさせる事や、挿絵を表示しながらの閲覧もできるようになりそうでいいかなぁとも思ったんですけれども、読み上げアプリとしては読み上げ位置が見えないのはなぁということでお蔵入りになりました。なお、これらは 2,3年前 に調査したものになりますので、今ではもっと良い方法があるかもしれません(その辺りの知識のある方がおられましたら教えていただければ嬉しいです)。
2019/02 追記: 少し調査を進めてみた所、WKWebView を使ってこのくらいまでならできてしまいました。ただ reply の Tweet にもありますようにまだ解決できていない問題がありますのですぐには採用できません。 どこからか対策等を教えて頂ける方が現れないかなぁ(期待のこもった目で)。

スライダーについて (2018/05)

ことせかい の中の色んな所にあるスライダー(左右にスライドして値を入力する奴)なんですけれど、これ、微妙な値を指示したい場合にはちょっと面倒ですよね。そんな時は、スライダーのつまむ所(丸い奴)をタップしたまま(つまむ所が見える状態になるまで)指を下にずらして、そこで指を左右に傾けるような形で位置を調整すると微妙な値もなんとなく入力できます。まぁ正確に0.1づつ動かしたい、みたいなのには使えないのですけれど、覚えておくとちょっと便利な感じです。あ、これは左右への0.1づつとかのボタンを配置するのが面倒だから言っているのではなくてですね、ボタンを配置てしまうとiPhone SEとかの幅の狭い端末だとレイアウトが崩れちゃってちゃんと操作できなくなっちゃうのでボタンを配置できない所があったりするのです。

ルビ表示の改善について (2018/05)

まず、ことせかい は「読み上げ」アプリですので「目で読む」ための機能については真面目にサポートするつもりはありません。
なのですが、簡単に実現できるのに実装しないのだとすると悪い気もしますので、調査してみました。しかし、残念なことにルビの表示を簡単に実現するのは難しいという結論に達しましたため、この機能については見送りました。
ことせかい で小説を表示している画面では、UITextView というコンポーネントを利用しています。このコンポーネントは NSAttributedString という、属性つきの文字を表示する機能があります。この NSAttributedString には CTRubyAnnotation というルビをふるためのそのものの属性があります。なのですが、どうも UITextView はこの CTRubyAnnotation には対応していないようです(設定してみても何も起こりませんでした)。UILabel という別のコンポーネントでは同様にCTRubyAnnotation属性を設定した文字列にルビが振られましたので、多分使い方が間違えているとは思えませんでした。では UILabel を使えばいいではないかと思った人は鋭いかもしれませんが、UILabel ですとスクロールができませんし、範囲選択という概念もありませんので小説の本文を表示するためには使えません。 ではどうするのが良いのかというと恐らくは WKWebView といったような HTML のレンダラを使っての表示にしてしまうのが良いと考えられますが、縦書き表示についての所でも書きましたように、それはそれで解かねばならない問題が解けませんでしたので採用できないという判断になりました。
以上の理由から、ルビの表示の改善については見送らせて頂いています。

読み上げ時の話者について (2018/05)

ことせかい は読み上げアプリですので、読み上げの話者に関して、他の話者を選択できないか、というお問い合わせを受けることがあります。

ことせかい では、iOS の AVSpeechSynthesizer という、Siriさん も使っている音声合成エンジンを利用させて頂いています。これは Appleさん が無償で提供してくれているものになりますので、できるだけお金をかけず運用されている ことせかい としましてはとても使いやすいものとなっています。

同様な無償で利用可能な音声合成エンジンもいくつかあります。例えばAQUEST AquesTalk(一部の方には「ゆっくりの音声」というと馴染みがあるかもしれません)などがあります。 これらの音声合成エンジンは、(人によって評価は別れるのかもしれませんが) AVSpeechSynthesizer と比べてとりたてて良い品質の読み上げを行うようなものはなさそうでした。 また、現在の内部データベース情報では音声合成エンジンを変更するためのデータがなく、別の音声合成エンジンを指定することができません。従って、AquesTalk のような別の音声合成エンジンも利用可能とするためには内部データベースの更新が必要となりますが、これは最悪ダウンロードした小説が消えてしまうというような修正が伴う事になるため、慎重に行う必要があります。 そのため、現在のところはこれら AVSpeechSynthesizer 以外の無償で利用可能な音声合成エンジンを利用できるようにする予定はございません。

さて、ことせかい の開発を開始した頃(多分2014年頃)と比べて、最近は音声合成の技術もかなり進歩してきました。 中でも最近流行りのDeep Learningの技術を利用した音声合成には目を見張る物があります。 例えば Google CLOUD TEXT-TO-SPEECH や、Amazon PollyMicrosoft Bing Speechといったものです。 ただ、これらのサービスは所謂クラウドによるサービス提供を行うもので、利用にはわずかながらとはいえお金がかかります。 ご承知の通り、ことせかい にはお金を生み出す導線がありません。そのため、これらのお金のかかるサービスを利用しようとすると開発者側の持ち出しとなるため、そのままでは利用することは出来ません。

では、クラウドの利用料金をユーザ様から払って頂くような形式にするとどうだろうという考えも思いつきます。 ただ、これは以下に述べますようないくつかの点で問題があり、やりたくありません。

  1. クラウド側の利用料金はとても細かい単位での従量課金制であることがほとんどなのですが、iOS における課金体系にはそのような細かい単位での従量課金というものはございません。 従って、アプリ側での課金は例えば一度に120円分頂いておき、クラウド側の利用料金が120円を超えた辺りでもう一度120円を課金で頂く、というような動作が必要になります。ただ、クラウド側の利用料金はアプリのユーザ単位ではなくアプリ単位で課金されると考えられるため、一人のユーザの利用した利用料金を正確に算出するのは難しいと考えられます。そのため、恐らくは「だいたいこの位使ったのだからこの位のお金がかかっただろう」というざっくりとした推測を働かせる事になると考えられます。また、その推測はどちらかというとユーザ様側の支払う金額の方が多くなるように設定しておかないと、ことせかい の開発者側で赤字になってしまい、サービスが継続できなくなると思われます。
  2. これらのクラウドで提供される音声合成サービスを利用する場合、利用料金の問題が解決したとしても、ネットワークアクセスという問題がつきまといます。ネットワークへのアクセスは常に失敗する可能性があり、失敗からの回復のための実装が必要となり、実験などの検証は恐らく終わりがありません。
  3. ご存知の通り、現在の ことせかい には課金の仕組みはありませんので、新しく課金の仕組みを組み込む必要があります。課金の仕組みはお金に関する事ですので、慎重に組み込む必要があります。ことせかい の開発者は課金の仕組みをアプリに組み込んだ事は一度もなくその辺りの経験が少ないため、この作業にはかなりのコストを見込む必要があります。
  4. クラウド側の従量課金分をアプリ側の課金で補おうとした場合、アプリ側の課金成立時に Apple側 に支払われる 30%分 のアプリ内課金利用料が問題になります。というのは、例えばクラウド側の従量課金で120円分の音声合成を行ったとします。その場合、ことせかい のユーザとしては 120円 だけを払えばいいような気がしますが、これをアプリ内課金で120円を払って支払おうとすると、お金が足りなくて支払うことができません。これは Apple側 で120円の30%の36円が引かれて、84円しか開発者側には手に入らないため、クラウド側でかかった120円に満たないことになります。従って、アプリ内課金でクラウド側の従量課金分を補うためには、その30%分を多く頂く必要が出てきます。恐らくこれは期待されていない動作となるでしょう。

ことせかいの開発者としましては上記のような複雑な仕組みを構築しなければならない上に、さらにお金の問題(多分何かよくない間違え方をすると烈火の如く怒られたり最悪裁判とか警察沙汰になったりする可能性が高い)を抱え込むというコストもリスクも高い案件になります。正直な所、そこまで苦労してこれらの問題を抱え込むだけの利点がありません。

以上の事から、現在のところは問題が多いという理由でこれらの別の音声合成エンジンを利用するというのは難しいと考えています。


小説のお気に入りや本棚のフォルダ分けなど、本棚に関する拡張について (2018/05)

小説をお気に入りに登録したり、フォルダ分けするなどで小説を探しやすくするための機能についてなのですが、これは、現在の内部データベースに保存されている情報だけですと対応が不可能なものが多く、内部データベースの定義を変更して対応しようと思っています。 ただ、その場合は本棚だけではなく他の部分にも影響が及ぶ上に、場合によってはダウンロード済みの小説が見えなくなったりといった問題が発生する可能性があります。そのため、リリース用の枝(branch)ではなく、別の枝で作業しています。 この作業はかなり前から行っているのですが、まだまだ先は長い感じですぐにリリースできるとは思えません。

つまり、本棚に大量の小説を登録していると本棚から小説を探しにくくなっているというのは認識しているのですが、すぐに対応できる状態ではないということになります。 お手数をおかけしますがのんびりお待ち下さい。

Version 2.0.0 以降からは「本棚画面」にて「自作フォルダ順」などのフォルダ分けでの表示に対応致しました。


pixiv小説のシリーズへの対応について(2018/08)

結論から言うとこれは現在の仕組みでは無理そうです。 ことせかい では Web取込時に HTTP GET request の一回で取得できるHTMLから小説の本文や次の章へのリンクを取得しているのですが、このQ&Aを書いている時点では取得されたHTMLにはそのシリーズ小説の別の章へのリンクが含まれていません。 そこまで深く追いかけてはいないのですが、恐らくはページが表示された後に JavaScript による読み込みによってシリーズ小説の別の章へのリンクが生成されているのではないかと思います。ことせかい側 では JavaScript は動作しませんので、そのような仕組みのWebPageの場合は対応できません。 以上の原因により、原理的に対応が不可能な案件と判断されました。

Version 2.0.0 以降からは、上記のような JavaScript による読み込みを行っているようなWebサイト様に対しても本文を抽出することができるような仕組みを導入致しました。ただし、pixiv小説様はHTMLの構造がかなりの高頻度で変化致しますようなので、そのたびに読み込めなくなるような形になっております。読み込めなくなっている事に気づかれましたら、おちついて、礼儀正しく、お問い合わせ頂けますようお願い致します。


読み上げ時の音量(ボリューム)について(2018/10)

読み上げ時の音量が小さいのでもっと大きくできないか、というお問い合わせを何回か受けました。 なのですが、これ以上の音量は出せません。

ことせかい は iOS の提供しております AVSpeechSynthesizer というものを使って読み上げを行っています。 この AVSpeechSynthesizer では AVSpeechUtterance というものの volume プロパティで音量の指定ができるのですが、ことせかいではこの volume プロパティを標準値の 1.0 で利用しています。 という状態なのですが、この volume プロパティで指定できる値の範囲は 0.0 から 1.0 なのです。 つまり、現状で最大音量で発話させています。 ということなのでこれ以上の大きい音量では発話できないのです。 どうしても音量を大きくする必要がある方は外部のスピーカーなどの導入をお考えください。


アルファポリス様について(2018/10)

Web取込 機能で対応していました アルファポリス様 なのですが、先日よりダウンロード時に本文の内容が取得できない状態が発生しております。詳細な確認は行っておりませんので正確な事は言えませんが、今現在確認できている所では本文を JavaScript により遅延読み込みしているために、本文情報がカラの物が取得される、という状態のようでした。 このような遅延読み込みを行うWebサイトについては ことせかい の側では対応が難しいため、アルファポリス様 については ことせかい ではダウンロードができないとお考え頂けますと有り難いです。

Version 2.0.0 以降からは、上記のような JavaScript による読み込みを行っているようなWebサイト様に対しても本文を抽出することができるような仕組みを導入致しました。


iOSの音声合成エンジン側の問題について(末尾がリフレインする、一部の文字を読み上げない等)(2018/10)

ことせかい は iOS の提供しております音声合成エンジンを利用して読み上げを行っています。この音声合成エンジンは Siriさん の発話にも使われているような汎用性のあるものなのですが、一部の文字列について不思議な動作をすることがあります。これらの iOS の音声合成エンジン側の問題からくる不思議な動作については、ことせかい の側からは干渉しづらい問題となりますので対応が難しいです。

今現在確認されている問題は例えば以下のようなものです。

  • 末尾がリフレインする文字列がある。例:「/17歳」
  • 読み上げがされない文字列がある。例:「人の噂も75日」の75
  • 途中で謎の言語話者が憑依したようになる文字列がある。例:「軌跡を描くが、それは全く同じ軌道で描かれた白い軌跡」の「描くが」や「描かれた」の辺り
  • 「あ」の後ろに「、」があると「あ」ではなく「ええあいえむ」と読み上げる事がある。例:「あ、ああ」
  • 「イラつく」を「あいあーるえーつく」(iraつく?)と読み上げることがある。
  • 「ト:Vtuber準備中」を「と、ぶつぅばぁじいあいゆうびぃじてぃあいゆぅ」などと読み上げる事がある。

上記の問題と似たような問題が起きた時に、ことせかい の側で起きている問題なのか、iOS の音声合成エンジンの側で起きている問題なのかを簡易に判定する方法があります。 設定アプリ → 一般 → アクセシビリティ → スピーチ にて、「選択項目の読み上げ」をONにした上で、該当の文字列を範囲選択して出てくる「コピー」といった項目の中にある「読み上げ」を用いて読み上げさせた時は iOS の音声合成エンジンのみの発話になりますので、その読み上げでも同じような問題が起きる場合は iOS の音声合成エンジン側の問題であると考えて頂けると幸いです。(iOS 14 以降ですとこの方法で呼び出されるのは 新型の Siriさん の音声合成エンジンらしく、この方法では確認には使えなくなったようです。なのでお手数をおかけしてしまう事になりますが、iOS 14 以降で確認するためには、ことせかい と同じ音声合成エンジンを使っている他のアプリ(例えば Voicepaper 2 等)を使って発話させてみて、同じように変な発話になるかどうか、を確認するしかなさそうです)

また、これらの問題のうちの一部については、特定の話者(設定 → 声質の設定 → 話者 で設定される話者)のみで発生する事もありました。ですので、話者を変更すると改善する可能性もあります。ただ、例えば O-ren 拡張 のような話者は 設定アプリ → 一般 → アクセシビリティ → スピーチ → 声 → 日本語 からで話者のデータをダウンロードする事ができる場合があり、そのデータをダウンロードされた時期や iOS のバージョンによって動作が変わることが予想されます。ですので、この話者であれば問題は発生しない、という事を言い切れるわけではなさそうです。

一応、これらの問題は ことせかい の側の 設定 → 読みの修正 にて問題の起こる文字列を別の文字列に置き換える事で問題が回避できる事があります。ただ、これらの問題は iOS のアップデートの時に今まで問題が起きていた文字列が問題なくなったり、問題がなかった文字列で問題が起きたりという現象も確認されており、その全てを読み替え辞書に登録するような事は現実的ではなさそうです。ですので、何度も同じ文が出てきて同じように読み上げがおかしくなる、という問題を抱えている時などはこの方法も考慮すると良い位に考えて、当面は「あぁ、何かおかしな読み上げをしているな」とスルーするのが良さそうな気がしなくもありません。


読み上げ時の話者データのダウンロードについて(2018/11)

ことせかい は iOS の提供している音声合成エンジンを使って読み上げを行っています。この音声合成エンジンでは、予め用意されたいくつかの話者を選択して読み上げさせることができます。話者は 設定アプリ → 一般 → アクセシビリティ → スピーチ → 声 → 日本語 で出てくる話者を利用することになります(iOS 13 からは 設定アプリ → アクセシビリティ → 読み上げコンテンツ → 声 → 日本語 か、設定アプリ → アクセシビリティ → VoiceOver → 読み上げ → 声 のどちらかに変わっているようです)。このとき、これらの話者のデータを追加でダウンロードすることもでき、そのダウンロードを行った後に ことせかい を起動すればそれらダウンロードされた話者が選択できるようになります。(なお、話者の選択は ことせかい アプリ内の「設定」→「声質の設定」で出てくる一番上の項目の中の「話者」で指定します)

……というのが通常の使い方なのですが、たまに、この話者の一部または全てが選択できなくなるという症状を訴える方がおられます。そのような状態は開発者の所では再現したことがございませんのであまりよくはわかっていないのですが、どうやら「iOS をアップデートした時」や「設定アプリ でダウンロードされた話者データを削除して再度ダウンロードさせた前後」に ことせかい の側で話者の一部または全てが選択できなくなるという状態になることがあるようです。 この問題は iOS の OS 側の問題になりますので ことせかい の側ではどうしようもありません。

一応、設定アプリによる話者データのダウンロードについて補足しておきます。設定アプリによる話者データはいつの間にか消えている事があるようです。このような場合には、ことせかい 側で今まで選択できていた話者が選択できなくなった、というような症状になる事が考えられます。そのような場合には、念の為設定アプリ側でダウンロードがされていない状態(ダウンロードできる状態)になっていないかを確認していただけますようお願いいたします。なお、設定アプリ側ではダウンロード等のボタンが出ていない場合がございますが、その画面で暫く待っているとダウンロードボタンが表示されたりすることもあるようです。同様に、iOS を再起動した直後はダウンロードボタンが表示されない事があるとも聞きますので、iOS等 を再起動した直後に設定アプリ側の話者データのダウンロードがどうなっているかを確認するような場合にも、暫く待ってから確認すると良いかもしれません。

この問題が改善したという情報としましては、iTunes を使って復元を行ったであるとか、iOS のアップデートをしたであるとか、設定アプリでダウンロードされている話者データを一旦削除してもう一回ダウンロードしたといった事で改善したという話も聞いています。

なのですが、この症状に陥った後、設定アプリ側ではダウンロードされた話者データを削除するためのボタンが出てこないといった症状になってしまって、どうにもできなくなってしまった、という報告も受けています。 さらに酷いことに、そのようなどうにもできなくなってしまった方で、端末を工場出荷状態にまで(完全にリセットして)戻せば、再度話者データがダウンロードできるだろうとしようとしてみた方もおられるのですが、その場合でも削除のボタンもなく、ダウンロードのボタンも無いという状態になったという報告も受けています。 ここまで来ると端末自体を交換する位しかこの症状を直す方法が見当たらないような気もするのですが、さすがにそこまでするのは難しいかと思われます。

ただ、そのようなどうにもならない症状になってしまった方で、ごく少数の方で改善したという報告を受けた方法があります。 それは、ことせかい 側では話者として選択できなくなった(選択肢に出てこなくなった)が、設定アプリ側では話者データがダウンロードされている、という方で、以下の ことせかい のバックアップデータを使って読み上げに使う話者を強制的に目的の話者に上書きするという方法をとることです。 ただ、上記のような設定アプリ側では全てダウンロードされている(またはダウンロードボタンが無い)状態の方でこのバックアップデータで上書きしても改善しなかった方もおられますので確実な方法ではございません事はご了承ください。

以下に、それぞれの話者を読み上げ時の話者に強制的に上書きするための ことせかい のバックアップデータを置いておきます。 (なお、iOS のバージョン毎に話者の識別子が変わっていますので、ご利用中の iOS バージョンに合った物を取得してください)

iOS 16 とそれより新しい iOS
iOS 15 とそれより古い iOS

なお、上記のバックアップデータを用いて話者の設定を上書きした後は、設定 → 声質の設定 内の話者の部分を選択せずに、本棚から本を選んで発話させることでその効果をご確認ください。 設定 → 声質の設定 内の話者の部分を選択してしまいますと、期待されている話者が選択できないリストの中から話者を選択しなければならなくなり、結果的に上書きで設定した話者の設定を期待していない話者でさらに上書きしてしまうことになります。


読み上げ時の速度上限(下限)について(2018/12)

読み上げ時の速度について、今以上の速度で読み上げをしたいというお問い合わせを何件か頂きました。 ことせかい の読み上げ時の速度は 設定 → 声質の設定 にある 速度 で調節できるのですが、ここで指定できる値の範囲がシステム側の上限と下限そのものになりますのでこれ以上の値の設定はできません。

わかる方にわかりやすく書きますと、AVSpeechUtterance の rate プロパティ に設定できます値の 下限(AVSpeechUtteranceMinimumSpeechRate) と 上限(AVSpeechUtteranceMaximumSpeechRate) を指定できるようにしてありますのでこれ以上の範囲を指定してもこの範囲内に丸められてしまいます。

この制限を外そうとしますと、ことせかい が利用している音声合成エンジンを iOS の提供している AVSpeechSynthesizer ではない別のもので、合成された音声をPCM的な物で取り出せるもの(例えばAquesTalk等)に変えて、音声をPCM的に取り出してそこからさらに再生速度を早めるような処理を入れる、などの対策が必要となると考えられます。 ただこの場合は、ことせかい の音声合成エンジン周りが AVSpeechSynthesizer に依存した書き方がされているものを別の音声合成エンジンを使うように書き換えないといけなくなりますし、さらに再生速度を変えるとなると恐らくは読み上げ位置の管理にあたる部分にかなり手を入れないといけなくなりそうです。これらの修正は非常に大変なことが予想されます。 以上の理由により、現状ではそのような再生速度の限界を超える目的の変更を行う予定はありません。


小説読み込み時の内容について、又は小説本文とされる部分の選定基準について(2019/01)

先日、小説家になろう様からの本文読み込みにつきまして、「前書きや後書きが読み込まれなくなったので読み込むようにして欲しい」というお問い合わせを受けました。このお問い合わせについて、以前はその前書きや後書きは読み込まれていたという点と、それらの情報は確かに小説の本文とは違うけれど、完全に違う内容のものとは言えず、小説を掲載しているサイト側の用意した文言というよりは小説に関連している文言であるという点から、含まれていないよりは含まれていた方が良いであろうという事でそれら前書きや後書きについても読み込まれるようにデータベースを書き換えました。 具体的にはhttp://wedata.net/items/816192019-01-21T20:19:34+09:00の変更がそれに当たります。

これに関連して、今度は「先日までは前書きや後書きが含まれなくなったので便利に使っていたが、最近また含まれるようになった」というお問い合わせを受けました。これは前に受けましたお問い合わせと真逆の要求となりますね。 このお問い合わせはそれはそれで確かにその通りという気もするわけなのですが、かといってその要求を飲んで元に戻したとして、また今度は「前書きや後書きが読み込まれなくなったので読み込むようにして欲しい」というお問い合わせが来るようになることは考えられます。

ところで、この問題は前書きや後書きの話にはとどまりません。例えばこのNHK のニュース記事のようなものについて考えてみましょう。この例の場合、執筆時点では本文以外にもタイトルや前書きといった物が取り込まれるようになっています。 しかしよくよく記事をみてみると、個々の写真にはキャプション(例えば最初のキャプションは「自宅でくつろぐニローズさん(中央)」)がついています。これは取り込むべきでしょうか。 また、記事のタイトルの直後にある日付(「2019年1月23日 13時08分」となっているもの)は取り込まれていますが、これは取り込まれるべきでしょうか。 ことせかい はWeb小説の読み上げアプリですのでこのようなWeb上のニュース記事についてまで考慮する必要はないのかもしれませんが、仕組み上利用できるものは利用する人が必ず現れてしまいますので考慮しないわけにはいきません。

上記のような例もありますので、一概に「前書きや後書きを読み込んだり読み込まなかったりするためのON/OFF設定を追加する」というような二択の選択肢を用意してしまうと、前書きや後書きではない日付やキャプションはどう扱えば良いのだろう、という事になってしまいます。 その他に、データベース上で本文部分を示すカラムは一つ(PageElement)しかありませんので前書きや後書きといったカラムを増やすのか、そうだとすると日付やキャプションといったカラムまで将来的に増やさねばならないのかといった事を考えると、簡単には「前書きや後書きを読み込んだり読み込まなかったりするためのON/OFF設定を追加する」という施策は取れないことがわかります。 もちろん、何かステキな方法が見つかってこれらの問題が全て解決できればあるいはなんとかなるかもしれませんけれども。

従いまして、当面の間は本文部分というものはWebサイト様毎に固定の読み込み方をするという運用にしようと思います。という事は、このコラムを書き始めたきっかけである所の「前書きや後書きは含まれる方が良い」のか「前書きや後書きは含まれない方が良い」のかといった事については、どちらか一方を選択した状態にせざるを得ないという事になります。

というわけなので、とりあえずはこのWebPageを書いている ことせかい の開発者である「私」はどのような基準でどの文章を含めたり含めなかったりするのかということの基準を考えてみましたので現時点で考えているそれを以下に表明しておきます。

ことせかいWebページ読み込み用情報における本文部分の設定基準(2019/01)
  • 本文であるのに含まれない、という事が無いように努力する
  • 本文ではないとしても、そのWebページが半機械的に追加したような情報ではなく、書き手がわざわざ追加したものについては含まれるように努力する(前書きや後書きについては含まれるように努力する)
  • 読み上げられる物である事を考慮して、前後の文脈で破綻が少なくなるように努力する(キャプション等は含まれなくするように努力する)
  • 上記の指針にもかかわらず、ユーザより「これは外して欲しい」や「ここは含めて欲しい」という要求が多数(どの程度を多数とするかは「私」の主観によります)寄せられた場合、その項目については個別に対応するように努力する

「〜努力する」と書いてありますのは本文部分を示すために用いている xpath を生成する技術者(つまり私)のスキルと実際のWebページの仕様によっては目的の結果を得られない場合も往々にしてありますので完全を保証はできないという意味で濁した書き方になっています。

ところで、その本文部分がどこである、といった情報を書き込んであるデータベース ことせかいWebページ読み込み用情報wedata様 の成果を利用させていただいておりまして、そこに登録されたデータはパブリックドメインとして公開され、かつどなたでも書き換えが可能なデータベースとなっておりますので、上記の基準では納得行かないという方や、その書き方はよろしくないので俺が美しく書き直してやろうという方や、ここは努力してもできなかったんだなわかるよでもこう書き直せばいいんだよ直しておいてやるから今度から気をつけるんだぜという方などは是非ご自身で書き換えておいていただけますととても助かりますのでよろしくお願いいたします。


なろう検索 タブ等の削除方針について(2019/02)

Version 2.0.0 以降では、「なろう検索」タブは削除され、「Web検索」に変更されました。 以前の「なろう検索」とは勝手が違うとは思いますが、概ね似たような機能を提供できていると思います。 ただ、下記の昔書いた記事上でも告知しておりますように、「なろう検索API」を用いた事による、「更新の無い小説の確認を一気にスキップさせる」という事はできなくなっています。以下に、Version 1.* の頃の泣き言を残しておきます。

最近ずっと、ユーザ様からのお問い合わせ対応について、これをできるだけ減らしたいと考えています。 今現在のユーザ様からのお問い合わせへの対応にかかる時間や労力は無償でできる範囲を遥かに超えていると考えており、正直な所「見返りもなしで何故こんな事をやっているのか全然わかりません」。

私個人としましては、プログラムを書く事自体が楽しいというのと、自分が作ったものを喜んで使ってくれている方がいるというのはとても喜ばしいのですが、お問い合わせの対応がしたくてプログラムを書いているわけではないため、お問い合わせ対応自体は苦痛な部分が大きいです。

もちろん、お問い合わせへの対応時に「便利に使ってもらえてるんだなぁ」と感じたりするといった事での元気を頂いている部分があるのは間違いなく、また、お問い合わせによってアプリの改善のアイディアも頂戴できる事もあり、お問い合わせ対応が全て苦痛だというわけではありません。

しかしながら、お問い合わせというものはユーザ様側が何か不満を持っていて、それについてなんとかして欲しいというのでわざわざ送ってくるものですので、ほぼ例外なく負の感情が含まれています。

お問い合わせ対応というものは、お問い合わせへの対応をするという事が主目的のため、「なるほどここが問題なのですね」という事を理解しなければならないため、必ず負の感情の根本原因を理解する必要があります。つまりどのような書き方をされていても、それがお問い合わせであるならば、そこに負の感情を読み取ってしまうわけです。

そういうわけなのでお問い合わせから負の感情を受け取ってしまう事自体はしかたがないという理解はしていると思うのですが、これを少しずつでも毎日のように受け取っていますと、精神が疲弊してくるようです。恐らく個人差があるのでしょうけれど、私個人としてはこのような業務は向いていないようで、精神的負担が大きいように思います。

そのような理由から、ずっと「お問い合わせを減らすにはどうすればよいのか」という事を考えているわけです。

さて、ことせかい におけるお問い合わせ対応で多いお問い合わせに小説の取り込みに関する事があります。この小説の取り込み時に発生する問題の原因は、小説の取り込まれ方が大きく関係します。この時、「なろう検索 経由での取り込み」なのか「Web取込 経由での取り込み」なのかを確認できないと、問題の特定が難しい場合が多くなります。なのですが、ユーザ様から寄せられるお問い合わせの第一報にはこのどちらからの取り込みであったのかという事を示す情報が書かれていない事が多く、その場合はお問い合わせに対して返信として、「なろう検索 経由での取り込み」と「Web取込 経由での取り込み」のどちらなのかを問い合わせ返すという事が発生します。 この問題は、同じ小説を別の経路で取り込む事ができる事から発生している問題と言えます。 (「なろう検索」経由で取り込まれる小説は、小説家になろう様 で掲載されている小説になりますので、Web取込 機能でも取り込むことが可能です。Web取込 機能の使い方につきましてはWeb取込機能についてを参照してください。なお、小説家になろう様ではサイト内で検索ができますので、今後はそちらを使って検索などをして頂ければと思います。)

つまり、なろう検索 経由での取り込みと Web取込 経由での取り込みでは多少の取扱の違いがあり、 これが違うために、どちらの形式で取り込んだのかを明らかにしていただかないと問題の解析ができないという事になっているわけです。

これは、なろう検索タブの存在はメンテナンスコストが上がるだけでなく、ユーザサポートのコストも上げているという事を示しています。

従いまして、今後、なろう検索 タブを削除することを真剣に考えています。

もちろん、なろう検索 経由でのダウンロードをされた小説については、小説の詳細を参照することで Web取込 で取り込んだ小説以上の情報が得られたり、なろう小説API を利用することで複数の小説について一括して更新確認が行えるために更新チェック時に更新の「ない」小説を迅速に排除できるといったような複数の利点がある事は理解しています。それがあるためにメンテナンスコストを払ってでも なろう検索 タブは維持しておいた方がいいのだろう、と考え、今まで手を出さないでおきました。

そうではあるのですが、上記のようにお問い合わせ対応に対してのコスト増がかなりあるという事実と、お問い合わせ対応自体が ことせかい を開発する元気をかなり失わせている元凶である事を加味しますと、なろう検索 タブの存在をこのままにしておくのは容認できないと考えるようになり始めたという事になります。

従いまして、今後のアップデートにて なろう検索 タブの存在を排除していこうと考えています。 なお、なろう検索 タブの排除だけでなく、ダウンロードされた小説を全て Web取込 で取り込んだものと同様な扱いにすることで上記の なろう検索 経由でのダウンロードによる恩恵自体も排除しませんと、ユーザサポート時の「なろう検索 経由での取り込み」と「Web取込 経由での取り込み」のどちらなのかを問い合わせ返す手順はなくなりませんのでこちらも実行する予定となります。

今まで なろう検索 を便利に使っていただいていた方々には辛い変更になるかとは思いますが、上記のような理由がありますため、ご理解頂ければと思います。

なお、この修正自体はまだ何も作業を行っておりませんので、いつ頃にその修正が行われたバージョンがリリースされるかはわかりません。 場合によってはこの告知への反応によっては時期が前後する可能性もあるかもしれません。

ところで、アプリレビュー欄にレビューと称して不満を書かれる方々は恐らくこの告知文を読んでいない方と同じかそれに近い集合だと思われますので、アプリレビュー欄はかなり酷いことになるのではないかと思うのですが、その書かれるであろう不満に私が耐えられなくなる可能性は否定できないように思っています。その場合は暫く ことせかい から完全に離れて何もみないようにするような対応をすることで精神の安定などを取ろうかとは思いますが、書かれる非難轟々の度合いによっては何もかも嫌になってアプリ自体を終了させる可能性も多少はありそうな気もします。どうしたものですかね。


お問い合わせ対応の縮小やBBS等の設置について(2019/02)

なろう検索 タブ等の削除方針についてに対して、お問い合わせ対応が問題なのであればお問い合わせ対応自体を縮小するであるとか、BBSやユーザフォーラムといったような別の形式での対応を考えてはどうか、というご意見を受けましたので、現時点ではなぜそれらを行っていないのかを表明しておきます。

まず、お問い合わせ対応自体を縮小するという対策ですが、これを行いますと恐らくは AppStore側 のアプリレビューに不満や改善点が書かれるようになると考えています。そうした場合、アプリレビューにデベロッパからの返答という形での「お問い合わせ対応」が発生するわけなのですが、このAppStoreのアプリレビュー上でのお問い合わせ対応は、デベロッパ側からの返答を書き込んでから半日から1日程度の保留期間が設けられており迅速な対応ができませんし、ユーザレビューは本来ユーザサポートの場では無いために色々とユーザサポートには使いにくい面があり、不満を書かれたとしてもそのアプリレビュー上で対応する事はあまり筋がよろしくありません。 それであれば、ご意見ご要望フォームを設置し、そちらに誘導したほうがマシだと考えている、という事になります。

それではそのアプリレビュー側での対応もやめてしまえば良いではないかという話になるのかもしれませんが、これは私がそのような対応を取られたら寂しくなるだろうと考えるため、避けたいです。なお、少し勘違いされていると怖いので一応書いておくのですが、お問い合わせ対応時に寄せられる心無い書き方や一部の攻撃的な書き方、有り体に言うと無礼な書き方でのお問い合わせが問題なのではなく、全てのお問い合わせに対応するために使われる私の時間や労力がその見返り(無償なので実質的な物はなく、元気やアイディアをを頂くといった見返り)に見合わないと考えており、その無礼な書き方の物だけを無視すれば解消するのかというとそういうわけではないという事を改めて表明しておきます。そのような事情から、それらへの対応を縮小するというのはせっかくお寄せ頂いているご意見ご要望を無碍にする事になりますので、何か他にできることがあるのならそちらを優先して実行し、お問い合わせ自体への対応を減らすというのは最終手段にしたいなぁと考えているわけです。(そのような意味では月額制に移行することでユーザ自体の数を減らしてお問い合わせの件数を減らすというのは有効だとも考えてはいます。恐らく誰もそれを望んでいないでしょうから、今の所はやる気はありませんが) また、個々の対応において今の所は実装を見送られる、というような事象について、何度も同様の問い合わせが来る場合にはこのQ&Aに追記していく形でその問い合わせの可能性を減らす努力はしています。当然それを読まずにお問い合わせをしてくる方がおられますが、その場合は「〜は実装を見送っています。詳しくはQ&Aのここを読んで下さい」と返信するだけでよくなります。お問い合わせ対応への返信を書いている時はそのような省力化の元の文を生成するような作業と捉えており、結局はどこかで払う必要のあるコストだと考えているわけです。確かにお問い合わせ対応自体を止めた事は無いわけですのでこの仮説がただしいかどうかは判断できませんが、Q&Aとして公開しました事象に関するお問い合わせの数は減る事がわかっておりますので効果が無いわけではないと考えています。

次に、BBSやユーザフォーラム等を設置することでの省力化について。 こちらは得られる効果がコストに見合わないのではないかと考えています。以下に自分の考えている懸念点をざっと列挙します。

  • 恐らくWebサービスという形になるが、管理運営コストが発生する(無料の範囲で実現不可能であるかもしれないし、無料の範囲にしてもユーザが書き込む情報に対する個人情報の保護周りの遵守に対するコストなど無視できないコストがかかると考えられる)
  • 公の場である事が良いことではあると思われるのだが、公の場であるが故に問い合わせを躊躇する案件があり得る。 例えば何らかの問題が起こる小説があったが、その小説名を公の場では明かしたくないなどといった可能性が考えられる。
  • スクリーンショット等のメディアファイルの投稿が許されるような物でないと問題の特定などに不便が生じる可能性がある。
  • 匿名での参加ができる場合、誹謗中傷対策などのコストが跳ね上がる事が考えられる。
  • 意見や要望などを書き込んだ人はそれに対する反応を確認する事になるが、これに対する通知などを行う事のできるWebサービスはあまりない。
  • BBSやユーザフォーラムにした所で、問い合わせの殆どは開発者側で対応する必要が生じると考えられる。これは、開発者でなければ対応できないような複雑な問い合わせの事ももちろんだが、善意の第三者によるサポートが期待できないという事も含まれる。善意の第三者によるサポートは初めの数ヶ月程度であれば効果があるだろうが、それ以降も継続してサポートされるとは信じられない。給料の出る業務であればまだしも、毎日固定した時間をその対応に割くような人物が居るだろうか。よしんば居たとして私と同じように悩むだけなのではなかろうか。無給でそれを行うのは不健全であると考える。
  • それではBBSやユーザフォーラムを設置する利点とは何だろうか。過去に同じような書き込みがなされている場合にそれを検索して出てきた場合の参照性だろうか。それであれば現状のQ&Aで事が足りるのではなかろうか。ただ、Q&Aを読まないユーザも中には居る。そのようなユーザには善意の第三者による過去ログの提示は効果があるかもしれない。
上記の問題をかなり解決している物として、GitHub の issue があります。GitHub の issue は今回の話題に対する点としては以下のような特徴を持っています。
  • 管理運営コストがほぼかからない。ことせかい は既に GitHub上 のオープンソースソフトウェアプロジェクトであり、issue は既に可動しているし、public repository であるので issue の利用も無料の範囲で可能である。また、ユーザの個人情報の保護周りの事については GitHub側 が担保してくれているため開発者側で考える事は恐らく無い。
  • 新しい issue を作成する時には、過去の issue に似た文字列がある場合に「この issue が関連していそうである」という例示が出る。このため、過去の類似事例を検索や参照せずに問い合わせが行われる可能性をシステム上で減らす事が可能である。
  • メディアファイルの添付をすることができる。
  • 善意の第三者によるフォローも可能である。
  • issue に書き込むためにはユーザ登録が必須であるので、誹謗中傷等への心理的抵抗は大きくなる。
  • 個々のスレッドに対してNotification(通知)のsubscribe(購読登録)ができるので、定期的に新しい反応を確認しにいく必要から開放される手段も提供されている。
ただ、GitHub の issue は以下の問題があります。
  • 基本的に英語で提供されるサービスである。
  • ユーザ登録が必須である。
これらの問題はカジュアルなユーザを退散させるには十二分な問題点であると考えられます。 そもそも、GitHub の issue は可動しており、これに対して issue を立てるような事をしているのは今の所外国のユーザ一人だけです。大多数のユーザである日本人からの投稿は一つもない事が、上記の問題が原因であるにしろ、そうでないにしろ GitHub の issue を設置することにはあまり効果が無い事を示しています。

それでは、GitHub の issue のような機能を持ち、日本語で提供され、ユーザ登録が不要なWebサービスがあれば良いのでしょうか。ただそのようなサービスは私は知りません。とはいえなければ作ることもできるとは思います。ざっとどのような物かを妄想してみましょう。

  • 概ね GitHub の issue のような機能を持つ。つまり、個別の内容毎にissue(スレッド)が立てられ、その中で情報交換が行われ、場合によっては担当者が配置されたりbugやenhancementといったタグがついたりする。もちろん、issueを立てようとした時に、似たような issue があるのでそちらを参照してみるのは如何か?と問われたりする。
  • 明示的なユーザ登録がなくても書き込みを可能にする。これはアプリ内で生成する一意のIDを使うなどで対応できそうな気がする。アプリ外(例えばSafariやPCから使う場合)は別途ユーザ登録をしてもらうなどの対応が必要だと考えられる。
  • 明示的なユーザ登録が無いにしても、アプリ側から使う場合に一意のIDを利用できるとすれば、「問い合わせようと思ったけれど既にissueがあったので問い合わせ自体はしなくてよくなったのだが、issue自体はcloseしていなかったので対応を早めて欲しい」という気持ちを表明するための「そうだね」ボタンのような物があると良いかもしれない。開発者側は「そうだね」が集まっているissueを優先的に対処すれば良くなるかもしれない。
例えばこのような物ができると良いとは思うのですが、何分Webサービスは一つ二つしか作った事がないもので、あんまり得意ではなく、開発自体にはかなり時間を要すると考えられます。それで、出来上がる物が GitHub の issue に毛が生えた位の物だとすると、本当に必要だったものはそれだったのか、GitHub の issue をそのまま使えばよかったのではないか、そもそもWebサービスを管理運営するコストはどうするのか、サーバの運用費用もさることながら、ユーザが書き込みを行う事から個人情報の保護であったり忘れられる権利であったりといった事象への対応のコストも馬鹿にならない、といった事が考えられます。そのため、あまりこのようなWebサービスを作ろうという気分になれていません。

以上のように、お問い合わせの省力化やBBS又はユーザフォーラムの設置といったご提案はありがたいのですが、現時点ではあまり有効だとは考えられておらず、実行はされないものとお考えいただければ幸いです。ただ、もちろん、これらの懸念点を払拭するような何かステキな方法があるのであれば教えて頂けますとありがたいです。

空白などを「アルファ」と読み上げる問題について(2019/11)

この問題は ことせかい アプリ内の「設定」→「iOS 12 で読み上げ中の読み上げ位置表示がおかしくなる場合への暫定的対応を適用する」がONになっている事からくる問題かと思われます。

この問題に対する詳しい情報につきましては、アプリ内の「設定」→「iOS 12 で読み上げ中の読み上げ位置表示がおかしくなる場合への暫定的対応を適用する」をOFFからONにしようとした時に表示されるダイアログをお読みになっていただければ幸いです。

pixiv小説様で読み込めない場合についての暫定的な対応について(2020/07)

Version 2.0.0 以降では ことせかい 本体での pixiv小説様 の読み込みができるようになりました。 そのため、以下に示します暫定的対応は必要なくなりました。 これ以降、下記からリンクされております Siriショートカット はメンテナンスされませんのでご了承下さい。

pixiv小説様に掲載されている小説のうちのいくつかについてはWeb取込機能で取り込む事ができるようになっていると思うのですが、うまく取り込めない(本文が抽出できなかった的なダイアログが出る)物が最近増えてきたようです。 それらうまく取り込むことができない物について調査してみたのですが、現在の ことせかい では取り込む事ができないタイプの情報になっておりました。(解る方にはわかる書き方をしますと、JavaScriptを動作させた後でないとxpathでは文字列として取り出せない形式で保存されているため、取り出すことができない、という事になっています)

この問題に対応するため、それらうまく取り込めない物についての暫定的な対策としてSiriショートカットを作成してみましたのでご案内します。 なお、Siriショートカットがわからないという方が沢山おられそうな気がするのですが、ここで説明するのは大変ですのでテキトーにGoogle検索等で知識を貯めていただければと思います。

今回作成したショートカット「pixiv小説を ことせかい へ読み込む」をiCloudで共有しましたのでSafariで開いて「ショートカットを入手」してください。 (その際「信頼されていないショートカットを追加」できるようにショートカット側の設定を変えるであるとかといった事につきましても、Google検索等で学習して頂けましたら幸いです)

無事に「pixiv小説を ことせかい へ読み込む」がマイショートカットに追加できましたら、その「pixiv小説を ことせかい へ読み込む」の設定で「共有シートに表示」がONになっていて、「共有シートタイプ」がURLになっている事を確認してください。

次に、Safari を使って ことせかい で取り込む事のできない pixiv小説様 のページを開き、本文が表示されている状態にして、画面下部のシェアボタン(四角の上部に上向きの矢印が出ているアイコン)を押して、そこから先程共有シートで表示できるようにした「pixiv小説を ことせかい へ読み込む」を選択します。

以上の操作でSafariのシェアメニューから「pixiv小説を ことせかい へ読み込む」を呼び出しますと、ショートカットが本文等を抽出して ことせかい で使われるバックアップファイルを偽装したファイルを生成して ことせかい へ渡す事で、該当のURLの小説を ことせかい に取り込む、という事をします。

つまり……どう操作すればいいの?という方は、

  1. Safari で https://www.icloud.com/shortcuts/7cf546fc6a8b4d2fbd468e33434732e5 を開く
  2. 「ショートカットを入手」を押す
  3. Siriショートカットアプリが開いて「ショートカットを追加」というダイアログが開くので、下の方までスクロールして「信頼されていないショートカットを追加」を選択する
  4. そのままSiriショートカットアプリ内の下部にある、「マイショートカット」のタブを選択する
  5. 先程追加した「pixiv小説を ことせかい へ読み込む」が表示されているので、その四角の右上にある○の中に「…」みたいな感じのアイコンをタップしてショートカットの中身を閲覧する
  6. 画面上部にある「pixiv小説を ことせかい へ読み込む」の右側辺りにある○の中に「…」みたいな感じのアイコンをタップして設定項目を表示する
  7. 「共有シートに表示」がON、「共有シートタイプ」がURLになっている事を確認する(そうなっていなければそのように設定する)
  8. Safari を開いて、そのままでは取り込む事のできない pixiv小説 のページを開く
  9. 画面下部のシェアボタンを押す
  10. シェアメニューを下の方にスクロールしていって、「アクションを編集…」をタップ
  11. 「その他のアクション」の中にある(はずの)「pixiv小説を ことせかい へ読み込む」の左側にある○の中に+のアイコンをタップしてアクションに「pixiv小説を ことせかい へ読み込む」を追加する
  12. 右上の「完了」をタップ
  13. シェアメニューの上の方に「pixiv小説を ことせかい へ読み込む」が追加されているはずなのでそれをタップ
  14. Siriショートカットの中の「pixiv小説を ことせかい へ読み込む」が開いてなにやらゴニョゴニョと動作しながらpixiv小説の本文部分を取り出して ことせかい の偽装バックアップファイルを生成しているのを眺める
  15. うまく偽装バックアップファイルが生成できたつもりになったら ことせかい に処理が切り替わり、バックアップファイルを上書き追加し始めるのでそれを眺める
  16. うまくいっていれば本棚に目的の小説が追加されている
という事をしてください。一回この手続が終われば今度からはSafariのシェアボタンからの『シェアメニューの上の方にある「pixiv小説を ことせかい へ読み込む」をタップ』する事でうまく取り込むことのできないpixiv小説を取り込むことができるようになる…… はずです。

「はず」と書いてあるのは、このショートカットは暫定的な物であり、近い将来にpixiv小説様側の内部表記が変更されると動作しなくなるような書き方がされておりますため、恐らく近いうちに上記で言っているような動きはしなくなるであろうと推測されるからです。 また、このショートカットは ことせかい で取り込む事ができない形式でHTML内部が記述されているpixiv小説様に対して「しか」動作しませんので、それ以外のWebページに対して適用しても正しく動作は致しません(適用できないURLであった場合には ことせかい 側で取り込む事を試してみるかどうかのダイアログを出すような小細工はしているのですが、それも正しく動作するかは不明ですので、このショートカットを適用する前に ことせかい 側で取り込む事ができるかどうかを試した上でお試しくださいますようお願い致します)。 そのような物になりますのであまり過度な期待はせずにご利用頂けますと幸いです。

2020/7/11 追記: pixiv小説様にログインした状態でないと読むことができない小説については ことせかい 本体でも Siriショートカット でも取得することができない事を確認しました。ログイン周りの問題につきましては(少なくとも現状の)ことせかい では対応が難しいため、誠に申し訳ありませんが非対応とさせていただきます。

2020/11/29 追記: 上記にてリンクしている「pixiv小説を ことせかい へ読み込む」という Siri ショートカット(リンクとしては「iCloudで共有しました」となっている物) ですが、"\r" や "[newpage]" といった物を消していないというのに気づきましたのでそれらを消すようにしたものへと更新しておきました。

なお、恐らく今後もpixiv小説様に限らず現状の ことせかい では取り込むことができない形式のWebサイト様が現れると思われますので、ある程度までは対応が可能になりそうな方法を模索はしているのですが、これはすぐには適用できそうにありませんので手動でテキストファイルとして取り込む事や、アプリ内の「設定」→「開発者に問い合わせる」やサポートサイト下部にあります「ご意見ご要望フォーム」等からお問い合わせ頂けますと幸いです。

(あ、上記のショートカットを書き換えて新しい別のものに対応したので使ってくださいとかだと飛び上がって喜びながらこのQ&Aに追加しますのでそういうのでも良いです!( ゚∀゚)b ゼヒオネガイシマス!
あ、別にそういう事でなくて「このURLだとこちらで紹介されていたショートカットでも取り込めなくなってしまったので動くやつをまた作って欲しいですー」とかでも全然構いませんのでお気軽にご相談くださいね。今回のようにうまいこと対応できるかどうかはわかりませんけれども……(´・ω・`)

小説の編集画面でのカーソル移動ボタンを長押ししてもうまく動かない事がある場合について(2021/06)

Version 2.4.0 以降から、小説の編集画面にカーソル(キーボードを表示している時の入力Caret)を上下左右に動かすボタンが配置されています。 このボタンを長押しするとカーソルが連続で移動するようになっているのですが、時々「指を離した時にしかカーソルが動かない」ようになる事があります。これは何度もカーソル移動をさせていたりすると良く発生するのですが、何故このようになるのかの原因が把握できておりませんため、修正することができません。

このような場合には、少し面倒ですが、指を少しだけずらすとカーソルが動き出す事がありますので、その方法で回避して頂けますと幸いです。

なお、分かる人にはわかるようなわからないような書き方をしますと UILongPressGestureRecognizer でイベントを受け取っているのですが、Tap Down時 に .begin が発生せず、Tap Up時 に .begin.ended の両方が同時に発生する、という挙動になっていて、指をずらすと .changed は発生し続けるという謎の挙動になっています。回避方法がわかる方がおられましたら教えて頂けますと幸いです。

Safari のシェアボタンから「ことせかい へ読み込む」が無くなってしまう事がある場合について(2021/07)

こちらなのですが、iOS(又は iPad OS)を再起動すると直る事があるという話があるので、一度それを試してみて下さい。

読み上げ時に意図されていない発話をする(読み替え設定の確認・音声合成エンジン側の問題かどうかの切り分けなど)(2023/08)

「ある時気づいたら読み上げ方がおかしくなっていた」や、「突然◯◯を読み上げなくなった」といった、発話時に意図されていない発話がされたというお問い合わせをされる方がおられます。 このようなお問い合わせは、「設定タブ」→「読みの修正」で設定されている読み替え設定が原因で起こっている場合が多いです。 もちろんそれ以外の場合もないことは無いのですが、一応、以下のような方法で読み替え設定の問題なのかを確認しておいていただけますと助かります。

まず、読み替え設定によって読み替えられたために発話がおかしくなっているのかどうかを切り分けるために、問題が発生している箇所の前後2行ほどを含んだ状態で範囲選択します。 そして、範囲選択した時に出てくるメニューの中から「読み替え後を確認」を選択します。 すると、範囲選択された部分の読み替え後の文字列を確認することができますので、この画面で意図されていない読み替えが行われていないことを確認します。

もし、この時点で意図されていない読み替えが行われている場合、「設定タブ」→「読みの修正」か、「小説本文画面」の右上にあります「詳細」から「小説の詳細・小説専用設定」画面を開いてそこの「読みの修正」のどちらかまたは両方に、意図されていない読み替えを行う項目が設定されていると思われますので、それらの値を確認してください。 なお、「読みの修正」画面では右上の「虫眼鏡アイコン」のボタンから検索ができますので、そちらから検索することで、問題を起こしている読み替え設定を発見しやすいかもしれません。 なお、検索では読み替え前と読み替え後のそれぞれの文字列について検索を行いますので先程の「読み替え後を確認」の画面からコピーして検索しても良いですし、「小説本文画面」からコピーして検索してもよさそうです。

ただ、正規表現を用いた変換を行うものが悪さをしている場合は発見が難しいので少し特殊な探し方が必要かもしれません。 こちらの方法については簡単な方法を提供しておりませんため、「読み替え後を確認」では確かにおかしな変換になってしまっているけれど、その原因となっている読み替え設定を発見できない、という場合には、お手数をおかけしてしまって申し訳ありませんが以下の項目について添付や記載の上、お問い合わせ下さい(恐らくは特殊なお問い合わせ方法になりますが、アプリ内の「設定タブ」→「開発者に問い合わせる」からメール本文を生成して、そのメールへのファイル添付という形が良さそうに思います)。

  • 「設定タブ」→「バックアップ用データの生成」から「軽量バックアップ~」を選択して作成されたバックアップファイル(または「設定タブ」→「開発者に問い合わせる」から「軽量バックアップファイルを添付する」をONにして問い合わせメールを作成
  • 問題の起こっている小説の「小説本文画面」から右上の「詳細」を選択して出てきた画面の「この小説のバックアップを生成する」を選択して生成された一つの小説の本文を含んだバックアップファイル
  • 問題の起こっている小説の名前、問題の起こっているページ数(何ページ目)、問題の起こっている箇所(おおよその箇所で良いです)、どのように読み上げてほしかったのか、実際に読み上げられたもの、の5点の情報
なお、上記のバックアップファイルには ことせかい に保存されています情報のかなりの部分が含まれますため、こちらに開示できない情報が含まれる場合には送らないでいただけますと助かります。

次に、「読み替え後を確認」で表示された読み替え後の文字列にはおかしな点が無いのに、読み上げ自体はおかしなことになっている場合について。

こちらは、おおよそ iOS の 音声合成エンジン側 の問題かと思われますが、一応その問題であるかどうかを確認するために、以下の手順を行って動作確認をしてみてください。

  1. 「設定アプリ」→「アクセシビリティ」→「読み上げコンテンツ」で、「選択項目の読み上げ」をONにする
  2. ことせかい 側で問題の小説の問題が発生する部分を開き、問題部分の前後2行ほどを含んだ範囲を選択して、出てきたメニューから「読み替え後を確認」を選択して読み替え後の文字列(見た目には問題がなさそうだと判断されているもの)を表示させる
  3. 表示された読み替え後の文字列全てを範囲選択し、出てきたメニューの「読み上げ」を選択して選択項目を読み上げさせる
この手順で読み上げさせた時は、ことせかい 側ではなくシステム側での読み上げになりますので、そちらの読み上げで同様の問題が発生する場合には、恐らくは iOS の提供している音声合成エンジン側の問題と言ってしまって良さそうです。 その場合(iOS の音声合成エンジンの問題であった場合)は、ことせかい の側では対処が難しい事になりますので、この音声合成エンジン側の問題を回避できるような読み替え設定を追加するなどして問題を回避していただけますと助かります。

なお、iOS(や iPad OS)では、システム側で読み替えの設定ができるようになっておりますので、そちらの読み替え設定が効いてしまっている場合があります。そこで、以下の項目も確認していただけますと良いかもしれません。

「設定アプリ」→「アクセシビリティ」→「読み上げコンテンツ」→「読みかた」